OpenRIMS - Database Cleaning Part 1: Difference between revisions

From OpenRIMS Wiki
Jump to navigation Jump to search
(New Page)
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= Purpose =
= Purpose =
              The OpenRIMS-RP database contains configuration and user-defined data. The configuration data is defined by Supervisor. This data intends to manage electronic forms and workflows of applications. The user-defined data is data collected using electronic forms of applications and workflows.
The OpenRIMS-RP database contains configuration and user-defined data. The configuration data is defined by Supervisor. This data intends to manage electronic forms and workflows of applications. The user-defined data is data collected using electronic forms of applications and workflows.


              Before the database will become production it is necessary to define the primary configuration data. Because the configuration data is particular for a country, this data should be created and tested on the sandbox or demo installation of OpenRIMS-RP.
Before the database will become production it is necessary to define the primary configuration data. Because the configuration data is particular for a country, this data should be created and tested on the sandbox or demo installation of OpenRIMS-RP.


              While testing, the test data will be created. Thus, to prepare a production database it will be necessary to clean up all user-defined data that was created while testing, presenting, and, possible, learning.
While testing, the test data will be created. Thus, to prepare a production database it will be necessary to clean up all user-defined data that was created while testing, presenting, and, possible, learning.


For the current release, there is no special defined software to clean up the database, because it is an on-time operation.
For the current release, there is no special defined software to clean up the database, because it is an on-time operation.


= Pre-conditions =
= Prerequisites =
·       MySQL Workbench is installed


·       Connection to the database is established
* MySQL Workbench is installed
* Connection to the database is established
* Connection rights to the pdx2 database allow at least select, delete, insert, execute, update, show view
* The below cleaning script


·       Connection rights to the pdx2 database allow at least select, delete, insert, execute, update, show view
The conceptual model[1] of the OpenRIMS-RP database is a forest of data trees built upon a relation logical model using the MySQL database engine.


= The approach =
The stored procedure “print_tree” allows selecting all branches of a data tree from the root or any node.
              The conceptual model[1] of the OpenRIMS-RP database is a forest of data trees built upon a relation logical model using the MySQL database engine.


              The stored procedure “print_tree” allows selecting all branches of a data tree from the root or any node.
Any tree in this forest is a configuration or user-defined data, but not both. The clean database assumed the absence of user-defined data. To remove the user-defined data all data trees that contain user-defined data should be removed.


              Any tree in this forest is a configuration or user-defined data, but not both. The clean database assumed the absence of user-defined data. To remove the user-defined data all data trees that contain user-defined data should be removed.
To remove a data tree, it will be enough to remove the data tree root using the “remove_branch” stored procedure.
 
Thus, it will be necessary to recognize all roots of user-defined data and remove them by the “remove_branch” stored procedure.  
 
Currently, there are no SQL queries to select roots of the user-defined-data roots, however, SQL queries to select roots of the configurations have been developed for Administrative features implementations.
 
The approach is to select all roots of configurations and, then, subtract them from the whole roots. This is described in detail in the sections just below the "Generate cleaning script" here:.
 
= Generate cleaning script =
Login to MySQL CLI or Workbench.
 
Select you OpenRIMS database and open a new query.
SELECT concat('call remove_branch(',c.ID, ');', '-- ', c.Identifier) as 'sql'
 
FROM tree_userdefined c
'''This script may run for a long time!'''
 
The results table created is the actual cleaning script. Now "Select All" from the table, copy and then paste into a New Query.
 
Click Run/Execute.
 
'''This script will also run for a long time!'''


To remove a data tree, it will be enough to remove the data tree root using the “remove_branch” stored procedure.
After the script has executed please login to OpenRIMS as administrator and verify that the script has cleaned the workflows.


              Thus, it will be necessary to recognize all roots of user-defined data and remove them by the “remove_branch” stored procedure.  
The easiest way is to go to the Application Tracker of Monitor as verify that table is empty.


              Currently, there are no SQL queries to select roots of the user-defined-data roots, however, SQL queries to select roots of the configurations have been developed for Administrative features implementations.
== SQL Description of the cleaning process ==


              The approach is to select all roots of configurations and, then, subtract them from the whole roots.
=== '''Do NOT run the below scripts individually!''' ===
They are for educational purpose only but might assist in troubleshooting.


= Roots of configurations =
=== Roots of configurations ===
              The data tree roots as well as all data tree nodes are recorded in the “concept” table. All roots can be selected using the “tree_roots” view.
The data tree roots as well as all data tree nodes are recorded in the “concept” table. All roots can be selected using the “tree_roots” view.


              This view is a result of SQL query
This view is a result of SQL query


SELECT
SELECT
Line 75: Line 98:
These configurations will not be extended until the next version of OpenRIMS-RP software.
These configurations will not be extended until the next version of OpenRIMS-RP software.


= Authorities and users =
=== Authorities and users ===
              All users are branches of a tree. The root of this tree is “user.data”.
              All users are branches of a tree. The root of this tree is “user.data”.


Line 90: Line 113:
where clo.ID is null and c.Active and c.Identifier in ('organization.authority', 'user.data')
where clo.ID is null and c.Active and c.Identifier in ('organization.authority', 'user.data')


= Workflow definitions =
=== Workflow definitions ===
              Workflow definitions allow control user’s application processing.
              Workflow definitions allow control user’s application processing.


Line 192: Line 215:
)
)


= Dictionaries =
=== Dictionaries ===
              Dictionaries contains pre-defined classifiers used by data input forms. Each dictionary is a tree.
              Dictionaries contains pre-defined classifiers used by data input forms. Each dictionary is a tree.


Line 205: Line 228:
where clo.ID is null and c.Active and c.Identifier like 'dictionary.%'
where clo.ID is null and c.Active and c.Identifier like 'dictionary.%'


= Resources =
=== Resources ===
              The definition of a resource consists of:
              The definition of a resource consists of:


Line 230: Line 253:
where clo.ID is null and c.Active and c.Identifier='configuration.resources'
where clo.ID is null and c.Active and c.Identifier='configuration.resources'


= Files, uploaded to resources =
=== Files, uploaded to resources ===
The resource files are stored in a tree for each resource. The root URL is defined in the resource data configurations. A data configuration of a resource is a uniform data configuration.  Thus, it is necessary:
The resource files are stored in a tree for each resource. The root URL is defined in the resource data configurations. A data configuration of a resource is a uniform data configuration.  Thus, it is necessary:


Line 450: Line 473:
)
)


= Configurations of data =
=== Configurations of data ===
              Configurations of data intends to manage on-screen forms for configurations and user-defined data  For each form the configuration allows to assign:
              Configurations of data intends to manage on-screen forms for configurations and user-defined data  For each form the configuration allows to assign:


Line 475: Line 498:
where clo.ID is null and c.Active and c.Identifier in ('configuration.data')
where clo.ID is null and c.Active and c.Identifier in ('configuration.data')


= Configurations of reports =
=== Configurations of reports ===
              Configurations of internal reports intend to define parameters to execute internal reports. For each report configuration is a branch in a tree with root URL “report.configuration”
              Configurations of internal reports intend to define parameters to execute internal reports. For each report configuration is a branch in a tree with root URL “report.configuration”


Line 488: Line 511:
where clo.ID is null and c.Active and c.Identifier in ('report.configuration')
where clo.ID is null and c.Active and c.Identifier in ('report.configuration')


= Tiles =
=== Tiles ===
              Tiles is a system dictionary “dictionary.system.tiles”
              Tiles is a system dictionary “dictionary.system.tiles”


= Legacy Data =
=== Legacy Data ===
              The legacy data may be placed to one or more trees. The URLs of the roots should be clarified for the installation. For Nepal database URLs are “system.import.legacy.data”, “legacy.pharmacies” and “legacy.ws”.
              The legacy data may be placed to one or more trees. The URLs of the roots should be clarified for the installation. For Nepal database URLs are “system.import.legacy.data”, “legacy.pharmacies” and “legacy.ws”.


Line 504: Line 527:
where clo.ID is null and c.Active and c.Identifier in ('legacy.pharmacies', 'legacy.ws', 'system.import.legacy.data')
where clo.ID is null and c.Active and c.Identifier in ('legacy.pharmacies', 'legacy.ws', 'system.import.legacy.data')


= Put it all together =
=== Put it all together ===
Create two database views:
Create two database views:


Line 737: Line 760:
               `tree_configurations`)
               `tree_configurations`)


= Generate cleaning script =
SELECT concat('call remove_branch(',c.ID, ');', '-- ', c.Identifier) as 'sql'
FROM tree_userdefined c
              This script may run a long time.
----[1] sciencedirect.com/topics/computer-science/conceptual-data-model
----[1] sciencedirect.com/topics/computer-science/conceptual-data-model

Latest revision as of 17:02, 23 July 2024

Purpose

The OpenRIMS-RP database contains configuration and user-defined data. The configuration data is defined by Supervisor. This data intends to manage electronic forms and workflows of applications. The user-defined data is data collected using electronic forms of applications and workflows.

Before the database will become production it is necessary to define the primary configuration data. Because the configuration data is particular for a country, this data should be created and tested on the sandbox or demo installation of OpenRIMS-RP.

While testing, the test data will be created. Thus, to prepare a production database it will be necessary to clean up all user-defined data that was created while testing, presenting, and, possible, learning.

For the current release, there is no special defined software to clean up the database, because it is an on-time operation.

Prerequisites

  • MySQL Workbench is installed
  • Connection to the database is established
  • Connection rights to the pdx2 database allow at least select, delete, insert, execute, update, show view
  • The below cleaning script

The conceptual model[1] of the OpenRIMS-RP database is a forest of data trees built upon a relation logical model using the MySQL database engine.

The stored procedure “print_tree” allows selecting all branches of a data tree from the root or any node.

Any tree in this forest is a configuration or user-defined data, but not both. The clean database assumed the absence of user-defined data. To remove the user-defined data all data trees that contain user-defined data should be removed.

To remove a data tree, it will be enough to remove the data tree root using the “remove_branch” stored procedure.

Thus, it will be necessary to recognize all roots of user-defined data and remove them by the “remove_branch” stored procedure.

Currently, there are no SQL queries to select roots of the user-defined-data roots, however, SQL queries to select roots of the configurations have been developed for Administrative features implementations.

The approach is to select all roots of configurations and, then, subtract them from the whole roots. This is described in detail in the sections just below the "Generate cleaning script" here:.

Generate cleaning script

Login to MySQL CLI or Workbench.

Select you OpenRIMS database and open a new query.

SELECT concat('call remove_branch(',c.ID, ');', '-- ', c.Identifier) as 'sql'
FROM tree_userdefined c

This script may run for a long time!

The results table created is the actual cleaning script. Now "Select All" from the table, copy and then paste into a New Query.

Click Run/Execute.

This script will also run for a long time!

After the script has executed please login to OpenRIMS as administrator and verify that the script has cleaned the workflows.

The easiest way is to go to the Application Tracker of Monitor as verify that table is empty.

SQL Description of the cleaning process

Do NOT run the below scripts individually!

They are for educational purpose only but might assist in troubleshooting.

Roots of configurations

The data tree roots as well as all data tree nodes are recorded in the “concept” table. All roots can be selected using the “tree_roots” view.

This view is a result of SQL query

SELECT

      `concept`.`ID` AS `ID`,

      `concept`.`Identifier` AS `Identifier`

   FROM

      `concept`

       LEFT JOIN `closure` `clos` ON `clos`.`childID` = `concept`.`ID`  AND (`clos`.`Level` <> 0)

   WHERE

      ISNULL(`clos`.`ID`) and `concept`.`Active` -- only roots

Each data tree root is defined by unique field “Identifier”.

The data configuration trees are:

1.     Authorities and users

2.     Workflows

3.     Dictionaries

4.     Resources

5.     Files uploaded to resources

6.     Configurations of data

7.     Configurations of reports

8.     Tiles

9.     Legacy data

These configurations will not be extended until the next version of OpenRIMS-RP software.

Authorities and users

              All users are branches of a tree. The root of this tree is “user.data”.

All authorities are branches of a tree “organization.authority”.

              The SQL query to select roots:

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('organization.authority', 'user.data')

Workflow definitions

              Workflow definitions allow control user’s application processing.

              The definition of a workflow is stored in a tree. The root URL is “configuration.”URL of a workflow”, e.g., “configuration.application.retail.site.owned.pvt”. All root URLs can be gotten from lifecycle dictionaries:

·       dictionary.guest.deregistration

·       dictionary.guest.amendments

·       dictionary.guest.applications

·       dictionary.guest.renewal

·       dictionary.shutdown.applications

·       dictionary.host.applications

The SQL query to select all root URL’s from the life cycle dictionaries is:

SELECT distinct concat('configuration.',val.Label)

FROM concept c

join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=3

join concept var on var.ID=clo1.childID and var.Identifier='applicationurl'

join closure clo2 on clo2.parentID=var.ID and clo2.Level=1

join concept val on val.ID=clo2.childID and val.Identifier='EN_US'

left join closure clo on clo.childID=c.ID and clo.Level<>0

where

clo.ID is null and

c.Identifier in (

'dictionary.guest.deregistration',

'dictionary.guest.amendments',

'dictionary.guest.applications',

'dictionary.guest.renewal',

'dictionary.shutdown.applications',

'dictionary.host.applications'

)


              The SQL to select all workflow definition roots is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in (

                                             -- query for workflow definition URLs from the lifecycle dictionaries

                                             SELECT distinct concat('configuration.',val.Label)

                                             FROM concept c

                                             join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=3

                                             join concept var on var.ID=clo1.childID and var.Identifier='applicationurl'

                                             join closure clo2 on clo2.parentID=var.ID and clo2.Level=1

                                             join concept val on val.ID=clo2.childID and val.Identifier='EN_US'

                                             left join closure clo on clo.childID=c.ID and clo.Level<>0

                                             where

                                             clo.ID is null and

                                             c.Identifier in (

                                             'dictionary.guest.deregistration',

                                             'dictionary.guest.amendments',

                                             'dictionary.guest.applications',

                                             'dictionary.guest.renewal',

                                             'dictionary.shutdown.applications',

                                             'dictionary.host.applications'

                                             )

)

Dictionaries

              Dictionaries contains pre-defined classifiers used by data input forms. Each dictionary is a tree.

              By the agreement, all URLs of dictionaries should start with “dictionary.”. Thus, SQL is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier like 'dictionary.%'

Resources

              The definition of a resource consists of:

1.     Resource definition

2.     Data configuration

3.     Dictionary

4.     Stored files

The data configuration and dictionary are common configuration trees,  that can be gotten by the appropriate SQLs (see above and below)

Resource definitions are branches of the root URL “configuration.resources”.

The SQL is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier='configuration.resources'

Files, uploaded to resources

The resource files are stored in a tree for each resource. The root URL is defined in the resource data configurations. A data configuration of a resource is a uniform data configuration.  Thus, it is necessary:

1.     Select URLs of data configurations for all resources

2.     Select data configurations for all resources, using data configuration URLs

3.     Select URLs of file trees from the data configurations

4.     Select file trees, using the URLs

URLs of data configurations for all resources

SELECT item.Label

FROM concept c

join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

join concept lang on lang.ID=clo1.childID and lang.Identifier='EN_US'

join closure clo2 on clo2.parentID=lang.ID and clo2.`Level`=1

join concept item on item.ID=clo2.childID

left join closure clo on clo.childID=c.ID and clo.`Level`<>0

where

clo.ID is null and

item.Active and

c.Active and

c.Identifier='configuration.resources'


Data configurations for all resources:

SELECT conf.ID, conf.Identifier

FROM concept c

join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

join concept conf on conf.ID=clo1.childID

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null

and c.Active

and c.Identifier in ('configuration.data')

and conf.Identifier in (

                              -- URLs of data configurations for all resources

                              SELECT item.Label

                              FROM concept c

                              join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

                              join concept lang on lang.ID=clo1.childID and lang.Identifier='EN_US'

                              join closure clo2 on clo2.parentID=lang.ID and clo2.`Level`=1

                              join concept item on item.ID=clo2.childID

                              left join closure clo on clo.childID=c.ID and clo.`Level`<>0

                              where

                              clo.ID is null and

                              item.Active and

                               c.Active and

                               c.Identifier='configuration.resources'

)            

URLs of file trees from the data configurations

SELECT asm.Url

              FROM concept c  -- roots of configurations (right table on the screen)

   -- variables for configurations (left table on the screen)

              join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

              join concept conf on conf.ID=clo1.childID

              join closure clo2 on clo2.parentID=conf.ID and clo2.Level='1'

              join concept var on var.ID=clo2.childID and var.Identifier <> '_LITERALS_' and var.Active

   -- get only files (documents) from the configuration variables

              join assembly asm on asm.conceptID=var.ID and asm.Clazz='documents'

   -- roots

              left join closure clo on clo.childID=c.ID and clo.Level<>0

              where clo.ID is null

               and c.Active

               and c.Identifier in ('configuration.data')

               and conf.Identifier in (

                                             -- URLs of data configurations for all resources

                                             SELECT item.Label

                                             FROM concept c

                                             join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

                                             join concept lang on lang.ID=clo1.childID and lang.Identifier='EN_US'

                                             join closure clo2 on clo2.parentID=lang.ID and clo2.`Level`=1

                                             join concept item on item.ID=clo2.childID

                                             left join closure clo on clo.childID=c.ID and clo.`Level`<>0

                                             where

                                             clo.ID is null and

                                             item.Active and

                                              c.Active and

                                              c.Identifier='configuration.resources'

               )

File trees:

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in

(

       -- URLs of file trees from the data configurations

       SELECT asm.Url

       FROM concept c  -- roots of configurations (right table on the screen)

  -- variables for configurations (left table on the screen)

       join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

       join concept conf on conf.ID=clo1.childID

       join closure clo2 on clo2.parentID=conf.ID and clo2.Level='1'

       join concept var on var.ID=clo2.childID and var.Identifier <> '_LITERALS_' and var.Active

  -- get only files (documents) from the configuration variables

       join assembly asm on asm.conceptID=var.ID and asm.Clazz='documents'

  -- roots

       left join closure clo on clo.childID=c.ID and clo.Level<>0

       where clo.ID is null

        and c.Active

        and c.Identifier in ('configuration.data')

        and conf.Identifier in (

                                      -- URLs of data configurations for all resources

                                      SELECT item.Label

                                      FROM concept c

                                      join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

                                      join concept lang on lang.ID=clo1.childID and lang.Identifier='EN_US'

                                      join closure clo2 on clo2.parentID=lang.ID and clo2.`Level`=1

                                      join concept item on item.ID=clo2.childID

                                      left join closure clo on clo.childID=c.ID and clo.`Level`<>0

                                      where

                                      clo.ID is null and

                                      item.Active and

                                       c.Active and

                                       c.Identifier='configuration.resources'

        )

)

Configurations of data

              Configurations of data intends to manage on-screen forms for configurations and user-defined data  For each form the configuration allows to assign:

·       Form layout on a screen

·       Data input fields, i.e., text, numeric, dates, logical

·       Data input components, i.e., dictionaries, registers, resource downloads, etc.

·       Data validation rules

              Details may be found here (MSH, 2022)

              For each data form the configuration is a branch in the tree with URL “configuration.data”

The SQL is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('configuration.data')

Configurations of reports

              Configurations of internal reports intend to define parameters to execute internal reports. For each report configuration is a branch in a tree with root URL “report.configuration”

The SQL is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('report.configuration')

Tiles

              Tiles is a system dictionary “dictionary.system.tiles”

Legacy Data

              The legacy data may be placed to one or more trees. The URLs of the roots should be clarified for the installation. For Nepal database URLs are “system.import.legacy.data”, “legacy.pharmacies” and “legacy.ws”.

The SQL is

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('legacy.pharmacies', 'legacy.ws', 'system.import.legacy.data')

Put it all together

Create two database views:

tree_configurations:

-- 1.        Authorities and users

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('organization.authority', 'user.data')

union

-- 2.        Workflows

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in (

                                             -- query for workflow definition URLs from the lifecycle dictionaries

                                             SELECT distinct concat('configuration.',val.Label)

                                             FROM concept c

                                             join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=3

                                             join concept var on var.ID=clo1.childID and var.Identifier='applicationurl'

                                             join closure clo2 on clo2.parentID=var.ID and clo2.Level=1

                                             join concept val on val.ID=clo2.childID and val.Identifier='EN_US'

                                             left join closure clo on clo.childID=c.ID and clo.Level<>0

                                             where

                                             clo.ID is null and

                                             c.Identifier in (

                                             'dictionary.guest.deregistration',

                                             'dictionary.guest.amendments',

                                             'dictionary.guest.applications',

                                             'dictionary.guest.renewal',

                                             'dictionary.shutdown.applications',

                                             'dictionary.host.applications'

                                             )

)

union

-- 3.        Dictionaries

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier like 'dictionary.%'


union

-- 4.        Resources

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier='configuration.resources'


union

-- 5.       Files uploaded to resources

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in

(

              -- URLs of file trees from the data configurations

              SELECT asm.Url

              FROM concept c  -- roots of configurations (right table on the screen)

   -- variables for configurations (left table on the screen)

              join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

              join concept conf on conf.ID=clo1.childID

              join closure clo2 on clo2.parentID=conf.ID and clo2.Level='1'

              join concept var on var.ID=clo2.childID and var.Identifier <> '_LITERALS_' and var.Active

   -- get only files (documents) from the configuration variables

              join assembly asm on asm.conceptID=var.ID and asm.Clazz='documents'

   -- roots

              left join closure clo on clo.childID=c.ID and clo.Level<>0

              where clo.ID is null

               and c.Active

               and c.Identifier in ('configuration.data')

               and conf.Identifier in (

                                             -- URLs of data configurations for all resources

                                             SELECT item.Label

                                             FROM concept c

                                             join closure clo1 on clo1.parentID=c.ID and clo1.`Level`=1

                                             join concept lang on lang.ID=clo1.childID and lang.Identifier='EN_US'

                                             join closure clo2 on clo2.parentID=lang.ID and clo2.`Level`=1

                                             join concept item on item.ID=clo2.childID

                                             left join closure clo on clo.childID=c.ID and clo.`Level`<>0

                                             where

                                             clo.ID is null and

                                             item.Active and

                                              c.Active and

                                              c.Identifier='configuration.resources'

               )

)

union

-- 6.        Configurations of data

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('configuration.data')


union

-- 7.        Configurations of reports

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('report.configuration')


union

-- 8.        Tiles are a dictionary


-- 9.        Legacy data

SELECT c.ID, c.Identifier

FROM concept c

left join closure clo on clo.childID=c.ID and clo.Level<>0

where clo.ID is null and c.Active and c.Identifier in ('legacy.pharmacies', 'legacy.ws', 'system.import.legacy.data')


tree_userdefined:

SELECT c.*

   FROM

              `concept` `c`

       LEFT JOIN `closure` `clo` ON `clo`.`childID` = `c`.`ID`

           AND (`clo`.`Level` <> 0)

   WHERE

      ISNULL(`clo`.`ID`) AND `c`.`Active`

           AND NOT  `c`.`ID` IN (SELECT

              `tree_configurations`.`ID`

           FROM

               `tree_configurations`)


[1] sciencedirect.com/topics/computer-science/conceptual-data-model