The Data Definition Mapping Register
describes the relationship/ mappings between the architecture layers, entity classes and attribute classes, and provides the instantiated mapping of those three concepts (interfaces, entities and attributes).
To retrieve the current state of each element of the Data Definition Mapping Register
, i.e., all the metadata related to that element, you can use the i-refactory REST API or the views available in the Data Definition Mapping Register
.
View: [acm_datadefmap].[applicable_architecture_layer_mapping]
id
: identifier of the mappingarchitecture_layer_id_source
: the identifier of [acm_datadef].[architecture_layer] sourcearchitecture_layer_id_target
: the identifier of [acm_datadef].[architecture_layer] targetView: [acm_datadefmap].[applicable_entity_class_mapping]
id
: identifier of the mappingapplicable_architecture_layer_mapping_id
: the identifier of the [acm_datadefmap].[applicable_architecture_layer_mapping]
applicable_entity_class_id_source
: the identifier of [acm_datadef].[applicable_entity_class]
sourceapplicable_entity_class_id_target
: the identifier of [acm_datadef].[applicable_entity_class]
targetView: [acm_datadefmap].[attribute_class_mapping]
id
: identifier of the mappingapplicable_entity_class_mapping_id
: the identifier of [acm_datadefmap].[applicable_entity_class_mapping]
applicable_attribute_class_id_source
: the identifier of [acm_datadef].[applicable_attribute_class]
sourceapplicable_attribute_class_id_target
: the identifier of [acm_datadef].[applicable_attribute_class]
targetView: [acm_datadefmap].[interface_mapping]
id
: identifier of the mappinginterface_id_source
: the identifier of [acm_datadef].[interface]
sourceinterface_id_target
: the identifier of [acm_datadef].[interface]
targetapplicable_architecture_layer_mapping_id
: the identifier of [acm_datadefmap].[applicable_architecture_layer_mapping]
owner_interface_id
: the identifier of [acm_datadef].[interface]
View: [acm_datadefmap].[entity_mapping]
id
: identifier of the mappinginterface_mapping_id
: the identifier of [acm_datadefmap].[interface_mapping]
entity_id_source
: the identifier of [acm_datadef].[entity] sourceentity_id_target
: the identifier of [acm_datadef].[entity] targetapplicable_entity_class_mapping_id
: the identifier of [acm_datadefmap].[applicable_entity_class_mapping]
View: [acm_datadefmap].[attribute_mapping]
id
: identifier of the mappingentity_mapping_id
: the identifier of [acm_datadefmap].[entity_mapping]
attribute_id_source
: the identifier of [acm_datadef].[attribute]
sourceattribute_id_target
: the identifier of [acm_datadef].[attribute]
targetapplicable_attribute_class_mapping_id
: the identifier of [acm_datadefmap].[applicable_attribute_class_mapping]
ordinal_nbr
: the sequence number of the attributemapping_type_code
: type of the mapping-- Select details of entity mappings
SELECT entity_mapping.id
, entity_mapping.interface_mapping_id
, interface.name
, entity_1.name
, entity_2.name
, entity_mapping.entity_id_source
, entity_mapping.entity_id_target
, entity_mapping.applicable_entity_class_mapping_id
, entity_mapping.acm_exists_ind
, entity_mapping.acm_last_created_dt
, entity_mapping.acm_start_dt
, entity_mapping.acm_end_dt
, entity_mapping.acm_record_ind
, entity_mapping.acm_modifier_id
, entity_mapping.acm_entity_id
FROM ACME.acm_datadefmap.entity_mapping entity_mapping
JOIN ACME.acm_datadef.interface interface
ON entity_mapping.interface_mapping_id = interface.id
JOIN ACME.acm_datadef.entity entity_1
ON entity_mapping.entity_id_source = entity_1.id
JOIN ACME.acm_datadef.entity entity_2
ON entity_mapping.entity_id_target = entity_2.id
;
The main purpose of the Logical Validation Layer (LVL) is to transform the data received from external data sources to fit into the logical data model structure. It is also responsible for validating deliveries. The Logical Validation Layer is also known as the Historical Staging In (HSTGIN) Layer.
A schema is a set of database objects, such as tables, views, triggers, stored procedures, etc. In some databases a schema is called a namespace
. A schema always belongs to one database. However, a database may have one or multiple schema's. A database administrator (DBA) can set different user permissions for each schema.
Each database represents tables internally as <schema_name>.<table_name>
, for example tpc_h.customer
. A schema helps to distinguish between tables belonging to different data sources. For example, two tables in two schema's can share the same name: tpc_h.customer
and complaints.customer
.
A Physical Data Model (PDM) represents how data will be implemented in a specific database.
{note} The i-refactory uses four PDMs: technical staging model, logical validation model, central facts model and generic access model. Each one of these models is implemented as an additional database, which is used to store data from external and internal data sources.