In this section you can find how to generate a generic data access (GDAL) model from the central facts model, and how to add auxiliary relations to it.
Perform the next two steps to generate a GDAL model.
i-refactory > Generate > Generic Data Access Layer Model
{tip} Assign a meaningful name to the new physical diagram, such as: [model name] + GDAL.
The generated generic data access model contains the following:
acm_start_dt
.When you generate a GDAL model, the default mapping is read/write. This means that the GDAL model is also a CRUD model. If there are only batch deliveries and no CRUD operations, you can change the data access type of the GDAL model to read-only
. This will generate less triggers and stored procedures for the generic data access layer.
Tools > Mapping Editor...
properties
in the mapping editor Data Source Properties
, change the Access type
to:
{warning} Do not change to data access type to
Write-only
When the logical model contains composite and overlapping keys, some of the subset constraints of the logical model may be lost in the central facts model. This has to do with the fact that all composite natural keys of the logical model are replaced by surrogate keys in the central facts model.
To enforce the subset constraints that have been lost as a result of this "surrogation process", it is necessary to add Auxiliary columns (columns with stereotype Auxiliary
) and Auxiliary Subset References (relationships with stereotype Auxiliary Subset
) to the generated GDAL model.
We distinguish between an Independent Auxiliary Relation and a Dependent Auxiliary Relation:
You need to add the Auxiliary Relations to entities in a certain order:
To summarize: follow the dependency tree top-down, from the top independent entity to the bottom dependent entity. For each entity, generate auxiliary relationships for dependent relationships first and then for independent relationships.
If you want to correct or remove the relations: follow the path in reverse.
{info} i-Refactory server uses the metadata of the auxiliary subset references to generate a OASI Business Key perspective (oasi_bk) to better match the logical data model. The auxiliary columns in the
oasi_bk
views correspond to the parent business key columns.In a normal generated GDAL view, the foreign key refers to the surrogate key. To get the business key, you have to join the foreign key of the child entity to the parent entity on the surrogate key. In the
oasi_bk
view this is already done.
Click here to see an example why auxiliary relations are needed.
Dependent
)i-refactory > Create auxiliary references for dependent relations
Order Nbr
is added to Order Line Items
. Right click on an entity with independent relations (red lines with the text Independent
).
Select i-refactory > Create Auxiliary Relations for Independent Relations
In the example below, you see a dependent entity (Stable Dependent Entity)with independent relations. Order Line Items
has an independent relation with Part Supplier
(red line with the text independent
). If you add the independent auxiliary relation to the Order Line Items
, the composite business key (Supplier Nbr
and Part Nbr
) is added to the entity.
In the example below, you see a independent entity Order
with only independent relations. In the Stable Independent Entity Order
you can see two attributes have been added:
If the auxiliary relations are generated, you can check if the business keys are correctly generated.
Check if the foreign keys from the logical validation model are generated in the entity. They are indicated with a <fk>
behind the attribute.
Check if the primary keys from the logical validation model are generated in the entity as an alternative key. There are two ways to do this:
<ak>
bethind the attribute.{warning} If there are more auxiliary keys in the alternative key than in the Anchors of the central facts model, you need to check if you've followed the execution order of generating auxiliary keys correctly.
i-refactory > Remove auxiliary Artefacts
{warning} If you get the error message "Cannot remove auxiliary artefacts. References to these artefacts exist.", check if there are other dependent relations from this entity. If this is the case: remove the auxiliary artefacts of the bottom entity first.
Optionally you can adjust the lay-out:
After you've created and checked the generic data access model: