Unit of Work im Data Vault

Was ist die Unit of Work?

Die Unit of Work ist ein grundlegendes Konzept bei der Data-Vault-Modellierung. Sie beschreibt das Prinzip, alle zusammenhängenden Business Keys aus einem Quellsystem gemeinsam in einer einzigen Link-Struktur zu erfassen. Dadurch wird sichergestellt, dass die in den Rohdaten abgebildeten Beziehungen in Ihrem Raw Data Vault vollständig und unverfälscht erhalten bleiben.

Stellen Sie es sich wie ein Puzzle vor, bei dem alle Teile zusammengehören: Wenn Sie die Teile ohne eine klare Strategie für das spätere Zusammensetzen voneinander trennen, riskieren Sie, das ursprüngliche Gesamtbild zu verlieren – oder schlimmer noch, ein Bild zu erzeugen, das in der Realität nie existiert hat.

Die Kernfrage: Was passiert, wenn Sie Links aufteilen?

Die zentrale Frage aus unserer Data-Vault-Friday-Session lautete:

„Es wäre gut, das Thema Unit of Work noch einmal aufzugreifen. Welche Informationen verliere ich, wenn ich breitere Links in kleinere Paare aufteile (DrivingKey -> Key1/Key2 etc)? Ich kann mir ein technisches Setup vorstellen, bei dem ich mehrere Links und Effectivity Satellites nutze und in der Lage sein sollte, zu jedem beliebigen Zeitpunkt dieselben Ergebnisse zu erzielen… Welche Informationen gehen genau verloren, wenn ich Links aufteile?“

Das Risiko beim Aufteilen von Links: Ein Praxisbeispiel

Beginnen wir mit einem einfachen Beispiel, um das Problem zu veranschaulichen:

Stellen Sie sich eine Beziehung zwischen drei Geschäftsentitäten vor – Customer, Store und Product. Customers betreten Stores und kaufen Products. Wenn Sie diese Beziehung als einen einzelnen Link modellieren, der alle drei Hubs (Customer, Store, Product) umfasst, erhalten Sie ein präzises und unverfälschtes Bild dieser Transaktion.

Nehmen wir nun an, Sie entscheiden sich dafür, diesen Link in zwei kleinere Links aufzuteilen:

• Customer -> Store
• Customer -> Product

Auf den ersten Blick mag das unproblematisch erscheinen. Wenn Sie jedoch versuchen, den ursprünglichen Datensatz durch das Verknüpfen (Joinen) dieser beiden Links zu rekonstruieren, erzeugen Sie möglicherweise neue Kombinationen, die es in Wirklichkeit nie gegeben hat. Zum Beispiel:

• Customer A hat Store K besucht und Product X gekauft (valide)
• Customer A hat Store L besucht (ebenfalls valide), aber wenn Sie dies mit Product X verknüpfen, entsteht eine falsche Beziehung: Customer A hat Product X in Store L gekauft (was tatsächlich nie stattgefunden hat).

Dieses Phänomen, bei dem durch Joins neue, künstliche Datensätze generiert werden, führt zu Dateninkonsistenzen. Sie führen damit Beziehungen ein, die im Quellsystem nicht existierten. Genau darin liegt das wesentliche Risiko beim Aufteilen von Links.

Der Jedi-Test: Überprüfung Ihres Modells

Um solche Probleme zu vermeiden, empfiehlt Michael die Anwendung des sogenannten Jedi-Tests (Star-Wars-Fans dürfen sich freuen!).

Der Jedi-Test ist eine einfache, aber wirkungsvolle Validierungsmethode: Versuchen Sie, den ursprünglichen Quelldatensatz aus Ihrem Data-Vault-Zielmodell exakt zu rekonstruieren. Wenn Sie die ursprünglichen Zeilen genau reproduzieren können – nicht mehr und nicht weniger –, ist Ihr Modell optimal. Entstehen dabei zusätzliche oder fehlende Zeilen, liegt ein Modellierungsproblem vor.

Dieser Test stellt sicher, dass Ihre Links korrekt modelliert sind und beim Aufteilen weder Daten verloren gehen noch inkorrekte Beziehungen entstehen.

Driving Keys und Unit of Work

Ein Szenario, bei dem das Aufteilen von Links unausweichlich zu Problemen führt, ist der Einsatz von Driving Keys. Driving Keys sind eine Teilmenge von Business Keys, die eine Beziehung eindeutig identifizieren.

Michael erläutert, dass die Aufteilung von Komponenten eines Driving Keys fast immer das Prinzip der Unit of Work verletzt. Wenn Sie einen Driving Key zerlegen, gefährden Sie die Integrität Ihrer Beziehungsdaten. Daher sollten alle Hub-Referenzen aus derselben Quelle stets gemeinsam in einem Unit-of-Work-Link innerhalb des Raw Data Vault abgebildet werden.

Er betont, dass er selbst zwar kein Verfechter von Driving Keys ist (und von einer gewissen „Hassliebe“ spricht), es jedoch Anwendungsfälle gibt, in denen sie notwendig sind. Wenn dies der Fall ist, müssen Sie zwingend darauf achten, sie nicht aufzuteilen.

Die sicherste Lösung: Links im Raw Data Vault zusammenhalten

Die bewährte Best Practice lautet: Belassen Sie alle Hub-Referenzen aus derselben Quelltabelle zusammen in einem einzigen Link – dem Unit-of-Work-Link.

Dieser Ansatz garantiert, dass die vollständige Beziehung exakt so erfasst wird, wie sie im Quellsystem vorlag. Sie können diese Beziehungen später im Business Vault jederzeit aufteilen, wenn dort Transformationen und zusätzliche Geschäftsregeln greifen. Der Raw Data Vault hingegen dient als Ihre vertrauenswürdige, unveränderliche Single Source of Truth.

Indem Sie die Unit of Work im Raw Data Vault wahren, beugen Sie Dateninkonsistenzen vor und gewährleisten, dass Sie nachgelagert jederzeit korrekte und verlässliche Datenstrukturen aufbauen können.

Was tun, wenn ein Link aufgeteilt werden muss?

Gelegentlich erfordern technische Restriktionen die Aufteilung eines Links. Beispielsweise wenn:

• Ihr Datenbanksystem die Anzahl der Hub-Referenzen limitiert, die in einen zusammengesetzten Index aufgenommen werden können.
• Deskriptive Daten auf unterschiedlichen Granularitätsebenen vorliegen, die einen breiten Link unpraktikabel machen.

In solchen Fällen empfiehlt Michael folgende Vorgehensweisen:

1. Behalten Sie den Unit-of-Work-Link als Basis-Link bei.
2. Erstellen Sie zusätzliche Links, um spezifische Granularitätsanforderungen abzubilden (z. B. Customer -> Product, Customer -> Store, etc.).
3. Wenn Sie Links aufteilen, stellen Sie sicher, dass alle fehlenden Beziehungen ebenfalls erfasst werden. Wenn Sie beispielsweise Customer -> Store and Customer -> Product, modellieren, benötigen Sie gegebenenfalls auch Store -> Product, um das vollständige Beziehungsgeflecht zu erhalten.

Diese ergänzenden Links ermöglichen es Ihnen, den ursprünglichen Datenbestand bei Bedarf exakt wiederherzustellen, erhöhen jedoch die Systemkomplexität. Mehr Links bedeuten mehr Entitäten, mehr Joins und potenziell geringere Abfragegeschwindigkeiten. Daher betont Michael die Bedeutung eines schlanken Modells und rät dazu, Links wann immer möglich zusammenzuhalten.

Effizienzüberlegungen

Unter Performance-Gesichtspunkten führen weniger Links mit mehr Hub-Referenzen in der Regel zu schnelleren Abfragen. Sie reduzieren die Anzahl der Joins und vereinfachen das Datenmodell. Mehr Links erhöhen dagegen die Komplexität und die Fehleranfälligkeit.

Die Abwägung ist daher eindeutig: Einfachheit und Effizienz durch einen Unit-of-Work-Link stehen der Flexibilität durch zusätzliche Links gegenüber – letzteres jedoch auf Kosten höherer Komplexität und operationeller Risiken.

Fazit und Empfehlungen

Zusammenfassend gilt:

• Halten Sie Hub-Referenzen aus derselben Quelle im Raw Data Vault stets gemeinsam in einem Unit-of-Work-Link.
• Führen Sie den Jedi-Test durch, um auszuschließen, dass Datenbeziehungen verloren gehen oder fälschlicherweise generiert werden.
• Müssen Links getrennt werden, dokumentieren und verwalten Sie diese sorgfältig und stellen Sie sicher, dass sämtliche notwendigen Beziehungen erhalten bleiben (auch solche, die auf den ersten Blick nicht offensichtlich sind).
• Verlagern Sie komplexe Aufteilungen und Transformationen in den Business Vault, da Anpassungen dort vorgenommen werden können, ohne den gesamten Datensatz neu laden zu müssen.

Eine sauber strukturierte Unit of Work stellt sicher, dass Ihr Data Vault ein robustes und verlässliches Fundament für Analytics, Reporting und Data-Science-Initiativen bleibt.

Video ansehen