With the advent of Data Vault 2.0, which adds architecture and process definitions to the Data Vault 1.0 standard, Dan Linstedt standardized the Data Vault symbols used in modeling. Based on these standardized symbols, the Visual Data Vault (VDV) modeling language was developed, which can be used by EDW architects to build Data Vault models. When our founders wrote the book, they, required a visual approach to model the concepts of Data Vault in the book. For this purpose, they developed the graphical modeling language, which focuses on the logical aspects of Data Vault. The Microsoft Visio stencils and a detailed white paper are available on www.visualdatavault.com as a free download.
LINKS IN VISUAL DATA VAULT
In June this year we published another newsletter how hubs are modeled in the accounting industry. In this Newsletter we explain the function of standard links and how the modeling in the banking industry works.
Links connect individual hubs in a Data Vault model and represent either transactions or relationships between business objects. Business objects are connected in business. No business object is entirely separate from other business objects. Instead, they are connected to each other through the operational business processes that use business objects in the execution of their tasks. The image below shows a link that connects two hubs (a standard link has to have at least two connections).as the following diagram shows:
The link in in the image above references two hubs: Account and Customer. The connector (the arrow) should be read as “(the hub) Customer is used by (the link) Account to Customer.” The second reference is a little different because the name of the connection between the Account hub and the link is overwritten by the meaning of a credit or a debt Account. This is necessary in cases where the model requires more meaning or when multiple connections are required to the same hub. The hash keys of each hub, which identify each business object unique by one calculated attribute, are replicated into the link entity by using the same attribute name.
A link represents many-to-many relationships and therefore they provide flexibility because changes to the business rules don’t require re-engineering and the granularity is expressed by the number of referenced hubs and is thus well documented.
The link contains all hash keys of the related hubs (logical foreign keys), a load date when the relationship arrives the data warehouse for the first time, the record source where the data comes from, and the link hash key (logical primary key) which is calculated from the business keys of the hubs (not from the hash keys – never hash a hash!) and follows an insert-only loading pattern.
Links greatly improve the flexibility of the Data Vault model, because it is easy to add links or modify the relationship type of existing links. It takes less time to respond to changes in the business. To add new functionality, you only need to add new hubs and connect them via links to existing hubs. Usually a standard satellite is attached to the link, which contains the descriptive data of the relationship between the hubs.
Another common kind of link is the Non-Historized Link (also known as Transactional Link) which contains transactions only and does not need a Satellite, what means that the loading pattern is a complete insert-only approach. Read more about the value of NH-Links in an earlier Newsletter this year.
How to Get Updates and Support
Please send inquiries and feature requests to [email protected].
For Data Vault training and on-site training inquiries, please contact [email protected] or register at www.scalefree.com.
To support the creation of Visual Data Vault drawings in Microsoft Visio, a stencil is implemented that can be used to draw Data Vault models. The stencil is available at www.visualdatavault.com.
Hi, I am trying to better understand the visual.
From the name it makes sense that the link just connects a customer with an account he has “interacted”, as no more info is provided by the link itself (or the explanation).
Looking at the model and the explicit indication of “credit” and “debt” I wonder what is the use / interest of those notes, as in the end the link provides a single “role” and the fact that an account is a credit or debit (or it has been used for a credit / debit operation) is buried in the (eventual) satellite.
In the case where you want to record a movement for a customer from one account (with debit role) to another (with credit role), the Link would have: LnkHKey, CustomerHKey, DebitAccHKey, CreditAccHKey, LD, RS.
I was wondering then how would you visually model it?
Would it look the same as this post or would it be different?
I would have used the visual model with two connections for the case of the link with two roles.
Would it not be more clear ?
BR, Roberto Zagni
Hi Roberto,
The shown model is a logical model and tells us that the account related to the customer can be a credit or debit account. How the data in the background looks like can be different. The “kind” of account could be in a descriptive attribute (part of the Satellite on the Account Hub or the Link) in case an account can be either a credit or a debit account, could be driven by an additional identifier that the link data has to be extended by this key (or the satellite – which becomes a multi-active satellite then), could be driven by two different keys (as you described), or any other scenario.
Related to your question, you would model it the same way. There is still just one customer, one account, but the kind of relationship can be different.
BR,
Marc Finger