Es gibt wenig Literatur zum Thema „Data Vault“ – und noch weniger von der Art, die das Thema im Ganzen und in sich schlüssig darstellt. Daher bin ich vor ein paar Jahren mit großem Interesse auf dieses Buch von Herrn Hultgren gestoßen. „Endlich mal ein komplettes Buch zum Thema“, dachte ich. Ich wurde nicht enttäuscht, wenn auch Fragen offen blieben – so viel vorab. Aber nun zum Buch im Detail.
Hultgren unterscheidet sich in angenehmerweise von den sehr technisch orientierten Ausführungen, die es bis dato von Dan Linstedt gab. Mein Einstieg in die Data Vault Thematik waren die „Series 1 – 5“, die Dan damals im Web veröffentlichte. Das Buch von Hultgren erläutert in den ersten Kapiteln, was ein Data-Vault (DV) ausmacht, die drei Kern-Entitätstypen werden erklärt – das sind natürlich die Grundlagen, die in ein solches Buch gehören. Insbesondere für Data-Vault-Beginners wird im Kapitel „The colours of Data-Vault“ das Prinzip der De-Komposition erklärt – von Hultgren auch „Ensemble Modeling“ genannt. Mit Hilfe von 3-farbig eingefärbten Entitäten wird anschaulich der Zerlegungsprozess erklärt. Somit erschließen sich dem Leser schnell die Unterschiede zur 3NF-Modellierung.
Hultgren erklärt weniger mit welcher SQL-Syntax welcher Entitätstyp beladen wird. Er erläutert vielmehr die grundsätzliche Herangehensweise der Enterprise-Data-Warehouse-Modellierung. Mir hat das Buch damals geholfen, auf meine Frage, „wie fange ich es grundsätzlich an?“. Als Beispiel nenne ich die HUB-Modellierung. Man könnte denken, dies sei die am einfachsten zu modellierende DV-Komponente. Hultgren erklärt, warum oftmals genau das Gegenteil der Fall ist. Was genau ist ein „natural“ (ein echter) Business-Key? Wie finde ich dies heraus? Gut gefallen haben mir dabei klare Statements zu den Fragen, ob bzw. wie weit man in der Modellierung von Hubs Super-Typing betreiben sollte oder nicht.
Analog stellt sich gleiche Frage für die Link-Modellierung. Hultgren erklärt das Prinzip der „Unit-of-work“ zur Validierung von „natural relationships“. Erklärt werden auch der „Same-As-Link“ und der „Hierachical-Link“, beides rekursive Beziehungen. Zum Thema LINK gibt es mehrere Anwendungsbeispiele, erstmalig habe ich hier den Terminus „Unit-of-work“ kennengelernt. Es geht darum, die „korrekten“ (natural) Links zu modellieren. Er empfiehlt auf rawVault Ebene alle Links der Sourcen aufzunehmen (Auditierbarkeit) und für das businessVault die „natürlichen“ Beziehungen im Kontext eines unternehmensweiten Zielbildes für die Datenintegration vorzugeben. Er plädiert dafür, sich an den betrieblichen Prozessen zu orientieren, um die „echten“, „natürlichen“ Beziehungen zu identifizieren.
Ebenfalls anschaulich erklärt – die korrekte Modellierung von transaktionalen Events: „An Event always requires a Hub“. Die Erklärung hierzu hat mich sehr an die Ausführungen von Kimble („The Data Warehouse Toolkit“) erinnert, in dem er erklärt, dass der Bon-Key einer Sales-Transaction als De-Generated-Key in die Faktentabelle mit aufzunehmen ist.
Ein weiteres Kapitel lautet „Key-Alignment“. Ziemlich spannendes Thema, leider nur ein paar kurze Erläuterungen. Diese gaben mir in einem Projekt jedoch entscheidene Impulse, bestimmte Modellierungsgrundsätze nochmal zu überdenken und entsprechende Richtlinien für die Modellierung abzuleiten. Das Bespiel Person (im rawVault) und Customer (im busVault) erklärt die Problematik sehr anschaulich – und passte zufällig gerade zum aktuellen Projekt. Auch gut, die Idee, einen „Layer-Connecting-Link“ zu erzeugen zwecks Data-Lineage-Analysen.
Im Kapitel „Reference-Tables“ erläutert der Autor seine Definition von Reference-Tables. Sehr gut gefallen hat mir dabei der Design-Ansatz der „Hub-based“-Reference-Tables. D.h. auch für Lookup-Tables werden Data-Vault-Standard-Kostrukte verwendet, um einheitliche Ladeprozesse verwenden zu können und das Modell konsistent zu halten im Sinne der „Lesbarkeit“. Im rawVault wird Redundanz vermieden und die Dimensionen können unterschiedliche zeitliche Sichtweisen abbilden (AS-WAS, AS-OF).
Hultgren erklärt, warum den Relationships im Data Vault grundsätzlich eine m:n Kardinalität zugrunde liegt. Auch dies ist ein Effekt der Dekomposition – jenes Grundprinzip des Data Vault, das ursächlich ist für die Robustheit des Datenmodells gegenüber Re-Engineering-Anfälligkeiten.
In den „Special Topics“ widmet sich Hultgren typischen Fragestellungen der Modellierung für den jeweiligen Entitätstyp. Diese Kapitel empfand ich damals als sehr hilfreich. Als Beispiel nenne ich die HUB-Modellierung. Im Modellierungsprozess steht die Identifizierung von „Core-Business-Concepts“, wie Hans Hultgren die fachlichen Geschäftsobjekte der realen Welt nennt, an erster Stelle. Werden diese „falsch“ modelliert, so ist der Rest des Modells in Folge natürlich auch nicht zu gebrauchen oder muss bald einem Re-Engineering unterworfen werden. Ein Beispiel für die Schwierigkeiten der HUB-Modellierung: Angenommen ein unternehmensweit akzeptierter Business-Key, der einen „Kunden“ repräsentiert, wird benötigt für die Modellierung des HUBs „KUNDE“. Was, wenn über diesen Key im Unternehmen kein Konsens besteht? Möglicherweise verwenden verschiedene Abteilungen unterschiedliche Keys, um einen Kunden (in der jeweiligen Abteilungssicht) zu identifizieren. Fachanwender müssen Ihre fachlichen Objekte mit „Ihren“ Keys identifizieren können, sonst sind die Daten für sie nicht auswertbar. Hultgren beschreibt hierfür verschiedene Lösungsansätze, drei davon möchte ich kurz vorstellen.
Lösung 1): Ein Business-Key wird als „Central-Business-Key“ bestimmt und ein entsprechender Hub nach „Schema F“ modelliert. Die „alternativen Business-Keys“ werden in einem separaten SAT modelliert, der keine Historie speichert (Type-1). Historie wird hier nicht benötigt. Ein Business-Key ist unveränderlich – sonst ist er als solcher nicht zu gebrauchen.
Lösung 2): Alle Business-Keys werden in der einen Business-Key-Spalte eines HUBs als eigene Instanzen gespeichert. Es wird einmalig festgelegt, dass alle Kontext-Informationen der SATs nur auf einen Typ der Business-Keys referenzieren („Central-Business-Key“). Die logische Verbindung dieses Business-Keys zu den alternativ gespeicherten Business-Keys erfolgt über einen Same-As-Link.
Lösung 3): Für jeden alternativen Business-Key werden separate HUBs und LINKs modelliert. Diese Hubs sind „weak“, sie haben keinerlei Kontext-Information. Die zusätzlichen Enitäten erzeugen einen gewissen Overhead (zusätzliche Tabellen und Beladeprozesse und verlängerte Join-Pfade) und zählt daher nicht zu Hultgren’s präferierten Lösungen.
Wie eine Data-Mart-Schicht vom Data-Vault aus beladen wird, ist aus meiner Sicht, eine sehr spannende Frage, über die ich bisher noch überhaupt keine Lektüre irgendwo gefunden habe. Leider behandelt auch Hultgren diesen Thema nur oberflächlich. In meinem aktuellen Data-Vault-Projekt setzen wir eine bi-temporale Historisierung im businessVault um. Die „Bestückung“ der historisierten Dimensionen muss unterschiedlichen Anforderungen des Business genügen. Ich habe hierzu Use-Cases definiert für die zeitlichen Sichtweisen auf Fakten im multidimensionalen Kontext, also AS-WAS, AS-IS, AS-OF. Einen ähnlichen „Input“ würde ich in jedem Buch, das Data Vault im Detail erklären will, erwarten.
Bezüglich Didaktik, Layout und Schreibstil gibt es sicherlich bessere Bücher – nicht aber im Themenbereich Data Vault. Insgesamt empfehle ich dieses Buch für jeden, der einen Einstieg in das Thema „Data Vault“ sucht. Der Leser erhält viele Antworten auf typische Fragen, die sich während des Modellierungsprozesses stellen. Prima!
