Some of the latest guidance from the DVEE consortium:
Data Vault: Elimination of Link Satellites
For most of the history of Data Vault, there have been Satellites (context) associated directly with Links (relationships). Over the past five years there have been active discussions concerning whether or not Link Satellites (LSATs) are innately part of the Ensemble pattern. As of 2017, the DVEE voted to provide the guidance that LSATs should not be used; they are not a part of the pattern. The reason for this new direction is based in the understanding that Links are only relationships, and as such, they do not have meaning by themselves. To assign meaning (descriptive context) to something that, by definition is not something (Person, Place, Thing, Event), is outside of the pattern.
For more information, and to join the conversation, visit: End of Link Satellites on LinkedIn.
Data Vault: Eliminate Link-to-Link Relationships
The idea of Link:Link relationships has commonly been viewed as something to avoid. There are issues of agility and an impact on the simple, repeatable patterns associated with Link-to-Link relationships. The move to eliminate them all together began at the beginning of this decade and there has been little discussion as most practitioners agree with this guidance. What is somewhat new and interesting is the understanding that overloading the meaning of a Link may be the root cause. So just as with the more recent elimination of the LSAT, the elimination of L:L relationships stems from an understanding that a Link is just a relationship and so not something by itself. To relate a Hub to an instance of something that, by definition is not something (Person, Place, Thing, Event), is outside of the pattern.
Data Vault: Keyed-Instance Hub
With the elimination of the LSAT and the Link-to-Link relationships, arose the topic of the Keyed-Instance Hub. So in those cases where you do want to attach a Satellite (assign meaning / descriptive context) to a Link, or if you want to relate another Hub to an instance of a Link, then that Link must be something (Person, Place, Thing, Event) and so it needs to have an identity. Identities, instances, keys, within the Data Vault Ensemble pattern, are represented by Hubs. So the Link needs to have a Hub representation. A Keyed-Instance Hub is a Hub that represents a logical 1:1 relationship with a Link, such that the grain of key represented by that Link, can be described (Satellites) or associated (Links) to other concepts in the model. For more information see this video lesson: https://youtu.be/ATjl3Ms9NrM
Data Vault: Eliminate of Multi-Active Satellites
When we come across scenarios where we need to capture multiple concurrently-active variations of certain context attributes, a situation where there is a named array of sets of values, there is a tendency to be drawn to typing this context in a single Satellite. The next effect is changing the key of the Satellite table to include a third part ("type" for example). As we now understand, the key of a Satellite should always be limited to a two part key (Hub SID plus Load Date/Time). When we add a third part to the key, it is no longer based on the same key grain as the Hub to which it is attached. This means that all Multi-Valued (Multivalued), Multi-Active and Multi-Variant (Multivariant) Satellites are outside of the pattern. This means that the benefits we seek to experience from applying this pattern will not be fully realized (agility, incremental build, etc.).