In this section we provide details about how metadata is represented and stored in the i-refactory metadata repository.
i-refactory has a metadata repository that stores metadata about deployed data models, data deliveries, delivery agreements, tenants, data logistics tasks and database connections.
The i-refactory metadata repository is a SQL server database whose schema follows the UAM approach. This means that the metadata is represented using hubs, links and satellites, and it is possible to keep the history of the metadata. For example, when a new version of an existing model is created and its metadata is inserted into the repository, the existing metadata is versioned and the old versions of the model will still be available through point-in-time queries. Hence only the actual updates are added to the metadata repository.
{warning} The i-refactory metadata repository should be maintained and updated only through the front-end or with api-calls.
The metadata in the metadata repository is organized into 5 thematic registers/schemas:
Data Connection Register
The tables within those schemas follow a naming convention depending on the role they play within the metadata data model. In particular:
{info} Metadata about physical data models, including mappings between models, are automatically generated using the option 'Generate DDL and metadata' available in Power Designer. To insert the generated metadata in the corresponding registers, the metadata needs to be imported to the i-refactory server (using the i-refactory Web App or the API). Based on the imported metadata, the i-refactory can execute the data logistics tasks necessary to process a data delivery from the moment that it is received in the Technical Layer until the moment when the delivered data will be available through the Generic Data Access Layer.
Metadata regarding physical data models, i-refactory architecture layers and interfaces are stored in the Data Definition Register. Objects from the Data Definition Register, such as tables, views, stored procedures and functions, belong to the schema acm_uam_datadef
and can be queried via pre-defined views and functions available in the following schemas:
{info} The model version and the model author can be specified in the model properties dialog in Power Designer, and they will be exported to the metadata repository (columns
release_author
andrelease_version
of the CRUD view acm_api.interface). Furthermore, the columnrelease_dt
contains the timestamp at which the metadata export script is deployed.
Metadata regarding mappings between schemas are stored in the Data Definition Mapping Register. Objects from the Data Definition Mapping Register, such as tables, views, stored procedures and functions, belong to the schema acm_uam_datadefmap
and can be queried via pre-defined views and functions available in the following schemas:
Metadata regarding data deliveries, delivery agreements and tenants are stored in the Data Delivery Register. Objects from the Data Deliver Register, such as tables, views, stored procedures and functions, belong to the schema acm_uam_datadel
and can be queried via pre-defined views and functions available in the following schemas:
i-refactory handles the data logistics through load tasks (a logical unit of work where data is transferred from a source entity to a target entity) and batches (set of data load tasks executed as a logical group, often the loading process of data from on layer to another layer). The metadata regarding data logistics tasks are stored in the Data Logistics Register. Objects from the Data Deliver Register, such as tables, views, stored procedures and functions, belong to the schema acm_uam_datalog
and can be queried via pre-defined views and functions available in the following schemas:
Metadata regarding database and tedious (driver) connections are stored in the Data Connection Register. Objects from the Data Connection Register, such as tables, views, stored procedures and functions, belong to the schema acm_uam_datacon
and can be queried via pre-defined views and functions available in the following schemas:
{info} The tedious connection information isn't stored in a separate table, it is stored as a JSON in the driver_connection_attributes field of the connection table.