Visuelles Beispiel einer Data-Vault-Modellierung
Durch die Ergänzung von Architektur- und Prozessdefinitionen in Data Vault 2.0 hat Dan Linstedt die Data-Vault-Modellierung standardisiert.
Basierend auf diesen standardisierten Symbolen wurde die Visual-Data-Vault-Modellierungssprache entwickelt, die Enterprise-Data-Warehouse-Architekten zur Erstellung von Data-Vault-Modellen nutzen können.
Die Autoren des Buches „Building a Scalable Data Warehouse“, die auch die Gründer von Scalefree sind, benötigten einen visuellen Ansatz, um die Data-Vault-Konzepte im Buch darzustellen.
Zu diesem Zweck entwickelten sie die grafische Data-Vault-Modellierungssprache, die sich auf die logischen Aspekte von Data Vault konzentriert.
Die Microsoft-Visio-Stencils und ein detailliertes Whitepaper stehen auf www.visualdatavault.com zum kostenlosen Download zur Verfügung.
Hubs in Visual Data Vault
Business-Keys spielen in jedem Unternehmen eine wichtige Rolle, da Geschäftstransaktionen und Beziehungen zwischen Geschäftsobjekten auf sie verweisen.
Immer wenn ein Unternehmen Geschäftsobjekte identifiziert und nachverfolgt, kommen Business-Keys in allen Geschäftsprozessen zum Einsatz.
Dies ist einer der Gründe, warum Data Vault auf den Business-Keys basiert. In der Data-Vault-Modellierung werden Business-Keys in Hub-Entitäten gespeichert.
Die Herausforderung besteht darin, die Business-Keys zu identifizieren, die ein Geschäftsobjekt eindeutig repräsentieren. Das kann ein einzelner Business-Key sein, aber auch ein Composite-Key oder ein Smart-Key.
Die erste Abbildung zeigt einen Hub mit nur einem Business-Key-Attribut:
Hier reicht das Attribut „Invoice Number“ aus, um die Rechnung zu identifizieren. Es ist kein weiteres Attribut erforderlich (wie beispielsweise das Rechnungsjahr).
In anderen Fällen ist es nicht so einfach, wie das folgende Diagramm zeigt:
In diesem Data-Vault-Modellierungsfall wird der Buchhalter durch ein „Country Code“-Attribut (wie den ISO2-Code) und ein „Employee Number“-Attribut identifiziert.
Ein Attribut allein würde nicht ausreichen, um den Buchhalter zu identifizieren: Die „Employee Number“ an sich könnte sich länderübergreifend überschneiden und nur eine lokale Bedeutung haben (die „Employee Number“ 10006 könnte in mehreren Ländern verwendet werden und in jedem Land einen anderen Buchhalter identifizieren).
Daher wird der lokale Schlüssel um den „Country Code“ erweitert, um den Buchhalter eindeutig zu identifizieren. Bitte beachten Sie, dass der „Country Code“ in den Quelldaten enthalten sein muss, damit dies ein gültiges Modell in Data Vault ist (letztendlich modellieren wir Quelldaten im Raw Data Vault, nicht das Zielmodell des Fachbereichs).
Ein weiteres Beispiel erweitert dieses Konzept zu einem sogenannten Smart-Key:
Hier besteht die IBAN, die zur internationalen Identifizierung von Bankkonten dient, aus vier physischen Elementen:
- Country Code
- Checking number
- Account number
- Bank Identifier code
Um einen Smart-Key zu modellieren (einen Schlüssel, der aus mehreren Teilen oder Schlüsseln besteht), fügen Sie dem Hub einen Smart-Key und anschließend Business-Keys hinzu, um die einzelnen Segmente des Smart-Keys zu identifizieren.
Wie Sie in der obigen Abbildung sehen können, ähnelt das logische Symbol eines Smart-Keys dem eines Business-Keys. Die Symbole unterscheiden sich jedoch geringfügig, und die Form deutet auf einen Stapel hin.
In diesem Data-Vault-Modellierungsbeispiel wird jeder Business-Key als einzelnes Attribut in der Hub-Entität modelliert. Die Kombination identifiziert ein Geschäftsobjekt im Unternehmen. Die „Checking Number“ wird eigentlich nicht modelliert, da sie keinen geschäftlichen Nutzen hat (außer der Funktion als technische Prüfsumme).
Es ist jedoch nicht falsch, wenn Sie diese ebenfalls dem Modell hinzufügen.