Good Practices - Logical Validation Model
In this section you find the good practices related to the logical validation model. We advise you to apply these good practices when you create a logical validation model.
Consider business requirements changes in the near future
Consult your data architect to get aligned on the level of normalization
Delete Helper
When you make a mistake in defining a Helper, it is advisable to delete the object and start from scratch to avoid missing dependency links.
Order of attributes in a composite key
In the logical validation model, it is advisable that the order in which you select the composite key matches the order of attributes in the data source. This is important because the data will be sorted according to the composite key. If the order is not the same, then this will have a negative impact on the performance.
Use domain types
It is good practice to use domain types instead of a datatype. This is especially convenient when multiple attributes need to adhere to the same datatype and values. If the datatype or enumeration changes, you only have to adjust one domain instead of several attributes.
Use of enumeration types and reference data
When you have an entity with an attribute whose values are restricted to a list of possible values:
-
if you don't expect changes on the list of possible values of the attribute or you have no intention to track any additional information about the attribute then you should use an enumeration constraint to restrict the values of the attribute (or domain).
-
if you expect changes on the list of possible values of the attribute and you have the intention to track information about these changes then you should have another entity, called reference entity, with an attribute whose values will be used as reference. To check if the value of the attribute is valid then you create a foreign key relationship between the original entity and the reference entity.
As an alternative to the first option, you can implement the enumeration constraint by means of a value expression.
{example} In our example, consider that a Nation belongs to a Region, and a region corresponds to one of the following continents: Asia, Africa, North America, South America, Europe, and Australia. If this list of values is static then Region_Name could be an attribute of Nation restricted by an enumeration constraint with the names of the continents .
However, suppose that during a period of time there will be no orders from Asia. This means that Asia is no longer a possible value for region and it should be removed from the enumeration constraint. If you use an enumeration constraint to validate the possible values of region, it wouldn't be possible to keep track of this change. To avoid this, you create an entity, called Region, with an attribute for the name of the region and a foreign key relationship between its primary key (Nbr) and the attribute Region Nbr of the entity Nation. Doing this, it is possible to keep track of the changes on the values of region and check if the region assigned to a nation is valid.
Use naming conventions for business rules
It is a good practice to use naming conventions for a business rule and it's helper (if applicable).
- You can give the business rule and the set constraint helper identical names and codes. This makes it easier to identify which business rule and helper belong together.
In the following example you can find the Business rule in the left window, and the helper in the right window.
- If the model contains a lot of business rules, you can add prefixes to the business rule to categorize the constraint. Examples of prefixes:
- tpc: Indicates a tuple or a record constraint
- spc: Indicates a specialized model constraint, such as mutual exclusive or complete subtypes
- omc: Indicates a constraint not in the above categories, a so called 'other model constraint'. In most cases this is a set constraint
- In addition, you can add the entity name, constraint type and number, and a short description of the constraint in the constraint 'name'. This way you can easily search for the constraint and see at a glance which entity it is associated with and what it does. In the 'code' you can enter the much shorter constraint type and number.
Example of a record constraint
Use strong data types as defined in the logical data model
Using strong data types improves data quality. It may result in data type conversion errors when the source data is inconsistent.
Know the difference between functional date, valid time, and transaction time
We can distinguish three types of time:
- Functional date or time: a point in time date
- Valid time: when a certain fact can change over time and you need to capture when that fact is valid in the real world
- Transaction time: indicates when a fact is stored in the (source) system
Use constraints to check valid timelines
If you use a bi-temporal entity, it is important to do some sanity checks: