Clear all

DV Anti-pattern: loading business keys into Satellites

Posts: 638
Topic starter
Honorable Member
Joined: 2 years ago

A common argument among practitioners is why not load business keys into satellite tables? 

There are a few considerations I can think of:

1. Hubs offer the passive integration between source systems, replicating the business key into a satellite creates an unnecessary maintenance point.

2. Attributes on a satellite (unlike business keys in a hub) are untreated, no casing is applied and therefore the business key may differ if source A has upcased all of its content and source B has lowcased all of its content but have the same business key. 

3. Satellites with business keys means that habits will develop where hubs are not "joined" on to retrieve the business key. 

4. A data vault based on natural keys rather than hash-keys would have the business keys available on satellites anyway, provided that all natural keys are short and represented by a single column this actually might work! In reality many combinations of composite columns make up a business key and therefore performance and distribution is better served using hash keys.

5. where do you stop adding business keys? If a source provides two or more sets of business keys then this source contains a relationship and that content should be loaded into a link and the rest of the content loaded in to a satellite off a link. Applying the anti-pattern however means it is ok to load all these keys into the satellite!

6. Not following the DV standards I feel introduces these complexities and workarounds that will turn the DV into a store of implementation debt --- a symptom of a future legacy system.


Interested to hear your take on this.

3 Replies