Visual Data Vault
Im folgenden Artikel wird anhand eines Visual Data Vault-Beispiels beschrieben, wie Links dargestellt werden können. Mit dem Erscheinen von Data Vault 2.0, das den Data Vault 1.0-Standard um Architektur- und Prozessdefinitionen erweitert, standardisierte Dan Linstedt auch die bei der Modellierung verwendeten Data Vault-Symbole. Auf Basis dieser standardisierten Symbole wurde die Modellierungssprache Visual Data Vault (VDV) entwickelt, die von EDW Architekten zur Erstellung von Data Vault-Modellen eingesetzt werden kann.
Als unsere Gründer das Buch schrieben, benötigten sie einen visuellen Ansatz, um die Konzepte von Data Vault darzustellen. Zu diesem Zweck entwickelten sie eine grafische Modellierungssprache, die sich auf die logischen Aspekte von Data Vault konzentriert. Die entsprechenden Microsoft Visio-Schablonen sowie ein ausführliches Whitepaper stehen unter www.visualdatavault.com kostenlos zum Download bereit.
In diesem Artikel:
Links im Visual Data Vault
n einem früheren Newsletter haben wir beschrieben, wie Hubs in der Buchhaltungsbranche modelliert werden. In diesem Newsletter erklären wir die Funktion von Standard-Links und wie die Modellierung im Bankensektor funktioniert.
Links verbinden einzelne Hubs in einem Data Vault-Modell und repräsentieren entweder Transaktionen oder Beziehungen zwischen Geschäftsobjekten. Geschäftsobjekte sind im Geschäftsbetrieb miteinander verknüpft – kein Geschäftsobjekt steht vollständig isoliert da. Stattdessen sind sie durch operative Geschäftsprozesse miteinander verbunden, die Geschäftsobjekte zur Ausführung ihrer Aufgaben verwenden. Die folgende Abbildung zeigt einen Link, der zwei Hubs miteinander verbindet (ein Standard-Link muss mit mindestens zwei Hubs verknüpft sein), wie das folgende Diagramm zeigt:
Der Link in der obigen Abbildung referenziert zwei Hubs: Account und Customer. Der Verbindungs-Pfeil sollte gelesen werden als: „(das Hub) Customer wird verwendet von (dem Link) Account to Customer“. Die zweite Referenz unterscheidet sich leicht, da die Verbindung zwischen dem Account-Hub und dem Link durch die Bedeutung eines Kredit- bzw. Schuldkontos überschrieben wird. Das ist erforderlich, wenn dem Modell mehrere Bedeutungsebenen hinzugefügt werden sollen oder wenn mehrere Verbindungen zu demselben Hub bestehen. Die Hash Keys der jeweiligen Hubs – die jedes Geschäftsobjekt eindeutig über ein berechnetes Attribut identifizieren – werden mit identischem Attributnamen in die Link-Entität übernommen.
Ein Link bildet eine Many-to-Many-Beziehung ab und bietet dadurch hohe Flexibilität, da Änderungen an den Geschäftsregeln kein Re-Engineering erfordern. Die Granularität wird durch die Anzahl der referenzierten Hubs ausgedrückt und ist somit gut dokumentiert.
Ein Link enthält alle Hash Keys der verbundenen Hubs (logische Fremdschlüssel), ein Load Date, das angibt, wann die Beziehung erstmals im Data Warehouse ankommt, die Record Source (Quelle der Daten) sowie den Link Hash Key (logischer Primärschlüssel). Dieser wird aus den Business Keys der Hubs berechnet (nicht aus den Hash Keys – never hash a hash!) und folgt einem Insert-Only-Lademuster.
Links erhöhen die Flexibilität des Data Vault-Modells erheblich, da sich neue Links leicht hinzufügen oder Beziehungstypen bestehender Links anpassen lassen. Reaktionen auf Änderungen im Geschäftsmodell erfolgen somit deutlich schneller. Um neue Funktionalitäten zu integrieren, müssen lediglich neue Hubs erstellt und per Link mit bestehenden Hubs verbunden werden. In der Regel wird ein Standard-Satellit an den Link angebunden, der beschreibenden Daten zur Beziehung zwischen den Hubs enthält.
Eine weitere gängige Art von Link ist der Non-Historized Link (auch bekannt als Transactional Link), der ausschließlich Transaktionen enthält und keinen Satelliten benötigt – das bedeutet, dass das Ladeverfahren vollständig Insert-Only ist. Mehr zum Nutzen von NH-Links finden Sie in einem früheren Newsletter dieses Jahres.
Fazit
Zusammenfassend lässt sich sagen, dass die Modellierungssprache Visual Data Vault einen standardisierten und effektiven Ansatz zur Darstellung komplexer Beziehungen und Transaktionen im Bankensektor. Durch die Verknüpfung von Geschäftsobjekten über Links entsteht eine klare und logische Struktur, die reale Geschäftsprozesse widerspiegelt. Diese Methodik verbessert nicht nur die Verständlichkeit von Datenmodellen, sondern unterstützt auch eine effiziente Datenverwaltung und -abfrage – und ist damit ein unverzichtbares Werkzeug für Architekten von Enterprise Data Warehouses.
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