In this section you can find how to update an existing generic data access (GDAL) model from the central facts model, and how to add auxiliary relations to it.
If the central facts model is changed, you need to update the generic access model as well. In the following, we describe several types of updates that can happen in the central facts model and how they can be implemented in the corresponding generic data access model.
Changes to the model structure/relation attributes affects both the physical storage of the central facts layer data and the generic data access model. Example of these changes are:
To implement the changes in the generic data access model:
Tools > Mapping Editor...
Apply
. The related Context entities will be added to the generic access model and the mapping will be automatically set. Object Browser
the new entity. Drag the new entity to the model area.
i-refactory > Create References from CFPL
. This wil recreate the relations between this entity and other entities, based on the central facts model. {tip} If your change affects a reasonable part of your Model - about one third -, consider creating your generic access model from scratch.
{info} You can't add a Key Root to the generic access model.
To implement the inclusion of an attribute to a context in the central facts model in the generic data access model:
Tools > Mapping Editor...
If you've added a foreign key link between a Context and an Anchor in the central facts model, you need to do additional steps:
Tools > Mapping Editor...
i-refactory > Create References from CFPL
.{warning} Never drag IDs and metadata to a generic access entity.
To implement the update of an attribute in a context in the central facts model in the generic data access model:
Tools > Mapping Editor...
Delete
. {warning} Never drag IDs and metadata to a generic access entity.
To implement the deletion of an anchor, a context or an attribute in the central facts model in the generic data access model:
To implement the deletion of a relationship in the central facts model in the generic data access model:
{warning} Never delete IDs and metadata from a generic access entity.
After you've created and checked the generic data access model:
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.