Using a Satellite on a Link? The discussion continues with descriptive data.
As often is the case, there were many and varied arguments for and against assigning a Satellite on a Link in Data Vault.
It would be helpful to put these arguments in the context of a more formal decision-making guide so that modelers can clearly see when a particular decision makes the most sense.
In the first part of this two-part article, I have outlined the background of the discussion from Diego Pasión's point of view, his approach to modeling decisions and how he presents these rules in his ‘Diego Guide.’
This second part deals with the descriptive attributes of a relationship.
The descriptive attributes
Table of Contents
“The physical Data Vault model (DV) would change again if the information model / logical data model (LDM) shown here, would change,” says Diego, the well-known coach of FastChangeCo's DMCE team.
Figure 1 - Business model, employee - department
“This can be, as already mentioned, adding descriptive relationship attributes,” explains Diego.
“An example is when following applies to the relationship between ‘Employee’ and ‘Department’:
Sophie's work start date (‘Work Begin Date’) in a new department B will be in three months in the future.
Sophie will then take on the role of a data modeler (‘Assignment’) for three months (time period: ‘Work Begin Date’, ‘Work End Date’).”
Diego presents the revised business data model / information model with the new information to his audience:
[Figure 2 - Information model, Employee - Employee Works in Department (bitemporal) - Department]
Diego looks around as he shows the LDM to the audience.
“The relationship between ‘Employee’ and ‘Department’ now has descriptive context, and to accommodate this the data modeler has added an associative entity to the LDM.
This new object contains the descriptive attributes of the relationship: ‘Work Begin Date’, indirectly the duration (time period: ‘Work Begin Date’, ‘Work End Date’) and ‘Assignment’.
Like other attributes, the business time period describes the relationship or the ‘normal’ entity.”
Enhancement of the 'Diego Guide'
Diego reminds the group of what he said earlier:
“If you always start from the business data model, which is generally recommended,” says Diego, “then when you instantiate a LDM into a physical DV model the entity ‘automatically’ becomes a Hub with a Satellite, and a relationship becomes a Link without a Satellite.”
The audience nods in agreement.
“If we apply our guidelines to this information model,” Diego continues, “then the associative entity in the physical data model becomes a Hub, and a Satellite and not a Satellite on the Link, right?”
Again, the audience nods in agreement. Diego thinks about his statement for a moment.
“We need to make a small addition, the 4th rule, in the guide.” Diego continues. “According to the current guidelines, the associative entity, with its two relationships, would lead to two links in the physical data model. But that would not aligns to the LDM.”
“What do you mean, Diego?”
“An associative entity and the ‘two associated relationships’ are one relationship in the true sense. It’s one relationship with descriptive attributes. That's why we data modelers in LDM need the associative entity trick.
In the DV, we implement this special relationship in such a way that one Link, one Hub and one Satellite are created from the associative entity.”
“Diego, can you please show us an example again?”
With the help of the modified guide, Diego creates a DV model from the LDM he showed earlier, and explains his approach.
“As previously shown, the entities ‘Employee’ and ‘Department’ are each used to physically model one Hub (rule 1) and one Satellite (rule 2). The relationship ‘works in’ previously existing in the LDM was further developed into an associative entity ‘Employee Works In Department’ based on the descriptive attributes.”
In the 'Diego Guide' the following simple rules apply:
- Entity attribute(s) (Identifying - How to get one and only one record): Becomes the business key in the Hub
- Entity attribute(s) (Describe, Measure - What is important about an entity?): Becomes context attribute(s) in the Satellite
- Relationship (What is the reason for a relationship between two entities?): Becomes a Link
- Associative entity (relationship with descriptive attributes or a many-to-many relationship): The entity becomes one Hub and one Satellite (rule 1 and 2), the ‘two’ or more relationships become one Link.
“As a result, the 4th rule now applies. The physical DV model changes in that the existing link between the two hubs is extended by one additional Hub with one Satellite.”
[Figure 3 - Data Vault model, Employee - ‘Associative entity’ Link - Department]
“The task of the ‘Hub Employee Works In Department’ and its Satellite is to map the original ‘many-to-many’ relationship with its the descriptive attributes correctly.”
For comparison, Diego again shows the previous DV model with the one-to-many relationship:
Figure 4 - Data Vault data model, employees - ‘one-to-many’-Link - department
Final thoughts
“Thanks Diego, that's really helpful. This is a clear way to explain when Link-Satellites make sense.”
“By the way, the 4th rule also applies to many-to-many relationships, regardless of whether these relationships have descriptive attributes or not. This is because a many-to-many relationship must finally always be resolved by an associative entity,” adds Diego.
“We as a team should include this guideline in our Data Vault modeling rules,” everyone agrees.
Diego is happy that his approach is appreciated. This way, he can help the audience as a mentor and coach.
Then Diego remembers that he has something to mention about naming conventions in LDM. But that's another story. More on that in the next article in the series. Be sure to check back.
So long,
Dirk