Anti-pattern: Adding Relationship Temporality to a Non-historised LINK

Non-historised Links represent data can not change or be deleted, for e.g. Stock Trades, Medical Test results etc. This data, once recorded, should not change. As such, there is no need to capture the End date of these. If you find yourself having the need to add the End Date to a LINK table, then it must be a Historized Link.

Anti-pattern: Excluding the Dependent Child in the generating the LINK Hashkey

If your LINKs have Dependent Childs, for e.g. Order Line Item as show below, it is crucial that the Order Line Item is included the LINK Hashkey.

If the Dependent Child is not included the generation of the LINK Hashkey, the JOINs to the LINK table will not be easy.

Anti-pattern: Using Historized Links to store Transactional data that does not change

Transactional Data that does not change e.g. sensor data, stock trades, call center call data log, medical test results, event logs etc. should reside in a Non-historized Link (NHL) aka. Transaction Link. There is no point in using a Historized Link to store data that can not change.  All of the attributes of the Transaction can be stored within the NHL. Here is an example:

 

Note that the PATIENT_HK, LOCATION_HK, COVID_TEST_ID, and LOAD_DATE form the Unique Key for the Non-historized Link. The descriptive attributes are stored in the Non-historized Link instead of a SAT hanging from the Link.

"Non-historised links are used when the data in the source should not be modified at any time"