In this section you find the good practices related to the technical staging model. We advise you to apply these good practices when you create a technical staging model.
It is advisable to add foreign key relationships to the technical model, but this is not a mandatory requirement.
A foreign key relationship visually shows the relationships between different entities. This helps to define the roles of the attributes in the technical model more explicitly because attributes that implement a relationship gain more meaning. Adding this relationship information also captures the knowledge identified in the process of source system analysis, doing so makes this knowledge transferable to others.
It is advisable to add primary keys to the technical model. The primary key in a technical model is not enforced, but it is used in the transformation process to the logical model. The primary key is stored as metadata and is not physically implemented in the corresponding database table.
Adding primary keys to a model improves load performance to the next layer. If a primary key is defined on a technical table and the primary key corresponds to the primary key on a logical table (based on the mappings on attributes), then no unique sorting is applied during the transformation from the technical table to the logical table. This can save a substantial amount of time, because unique sorting of supplied data is a "resource intensive" process.
{Warning} If more than one record per unique key is supplied in a delivery, than this will lead to the loss of all records that occur more than once on this key during the constraint validation. If the constraint validation is not applied, it will lead to errors when loading to the logical table.
It is advisable adhere to the source format as much as possible. Apply the names and datatypes of the physical data source model to the technical model.
When you use the names of entities and attributes from the data source in the technical model, you keep track of the origin of the data. You should do this even when names of entities and attributes have no meaning. This won't be a problem because these entities and attributes are mapped to entities and attributes from the logical validation model which employs meaningful terms. If your source model uses strong datatypes you also ease the process of transforming datatypes when you map from the technical model to the logical validation model. This reduce the risk of validation errors when processing data from this source system.
It is advisable to implement calculations on the source data in the Technical Staging Layer (TSL) instead of implementing them in the Logical Validation Layer (LVL).
Implementing calculations in the LVL would be more complex because the LVL contains temporal data.
It is advisable to use a helper entity in the technical model to implement calculations that can be done within the context of the current delivery.
Calculations that use entities outside of the current delivery, or that use historical versions of the data, must be implemented as a Business Rule Helper in the fact model instead.
If you add a helper instead of a computed column, all computations are decoupled from the technical model that represents the source system data. This increases transparency since we isolate a transformation from the data delivered. Adding a helper also clearly list all computations separately while a computed column is hidden and can easily be overlooked.
It is advisable to use a strong typing approach when data types from the data source are known and correspond to data types from the logical validation model, and to use weak typing for unknown source data types
When a technical model is strongly typed and there is a match between the data types from the technical model and the logical validation model, then fewer data types transformations are required in the LVL.
{warning} The risk of strong typing is that loading external data to a strongly typed technical model can lead to loading errors. For example, if there is a date type with a 'non-applicable' possible field, then this cannot be converted to date. Use strong data typing just when there are no doubts about which data types are used in the data source.
It is advisable to use only string data types in the technical model when the external data supplier uses file-based data sources.
String data types do not block other data types. Suppose the constraint validation rules are enabled in the i-refactory. Then, an attempt is made to convert a weak data type into the strong pre-defined data type, such as a string into a date, when transforming raw data from the technical to the logical format. If this proves impossible, you have three options: reject the delivery, empty attribute values, or reject records. In addition, a detailed log is kept of all transformation errors that have occurred.
{warning} If the constraint validation rules are not enabled, then the database will handle the conversion. This results in loading errors and/or information loss in case of data conversion errors.