Wie entstand Data Vault

Bei einem Kunden hatte ich eine spannende Diskussion über die Frage woher eigentlich Data Vault kommt. Woher im Sinne von: Ist es vom Himmel gefallen oder wurde Data Vault aus anderen Modellierungsarten abgeleitet. Ein naheliegender Gedanke ist, dass Data Vault aus dem Anchor Modeling entstanden ist. Nein, das nicht. Anchor Modeling wurde zum ersten Mal in einem Data Warehouse im Jahr 2004 bei einer Versicherung eingesetzt. Dazu aber später ein anderer Blogpost.

Wie bereits beschrieben, hat Dan Linstedt in den 90ern des letzten Jahrhunderts Data Vault erfunden, daran geforscht und es entwickelt. Bis zur Veröffentlichung im Jahr 2001 hat er rund zehn Jahre seiner Zeit in diese Modellierungsmethode investiert.

Was sind die Prinzipien hinter Data Vault? Worauf hat Dan Linstedt aufgebaut? Die Grundgedanken, die hinter Data Vault stecken sind nicht neu. Jedoch die Kombination daraus macht Data Vault so faszinierend.
Als Zutaten dienten dabei die Hub and Spoke Architektur, die 2. und 3. Normalform (2NF, 3NF) gewürzt mit etwas dimensionaler Modellierung.

Heruntergebrochen auf die Standards der Modellierung ergibt sich ein interessantes Bild:

• HUB – Ausgehend von einer Dimension des SCD-Typs II untersuchte Dan Linstedt die Primary Key Attribute:
  • wiederholende Business Keys
  • die Skalierung
  • die Tatsache, dass bei jedem neuen Datensatz (Historisierung) der Surrogate Key (als Sequenz) sich ändert

Ihm war klar, dass er eine 1:1 Beziehung zwischen Business Key und dem Surrogate Key braucht, um einen stabilen Zustand zu erreichen. So kam es, dass die Dimension des SCD-Typs II in zwei Teile gesplittet wurde: in Business Key und Kontext.

• LINK – Für eine Many-To-Many Beziehung. Direkt der 3NF entnommen.
  Man könnte dazu auch sagen, ein Link ist eine Factless-Fact-Tabelle. Tatsächlich verwendet Dan Linstedt aber die Methodik der 3NF für den Link.
• SATELLITE – Ausgehend von einer Dimension des SCD-Typs II untersuchte Dan Linstedt WARUM diese so viele Probleme verursacht: Beim Laden, der Komplexität, beim Abgleichen usw.
  So zeigte sich, dass die dimensionalen Daten im Laufe der Zeit Änderungen unterliegen. Diese Änderungen führen hauptsächlich zu den Problemen, die beim Snowflaking, umfangreiche Spalten (zu viele Attribute) usw. entstehen.
  Dadurch und abgeleitet aus der Studie der Inverted Index Trees (Eine Studie aus der Zeit als Dan Linstedt linguistic processing and high volume text data parsing studierte) kam es zu den Satelliten (Umkehrung der Beziehung Surrogate Key und Business Key im Vergleich zu klassischen Dimension).

Für Dan Linstedt bot, als Ergebnis seiner Forschungen, nur die Hub & Spoke Architektur die Möglichkeit für unbegrenztes Wachstum.

Neben den Aspekten der Modellierung führten auch die Probleme im ETL Design zu dem neuen Weg der Modellierung.
So gut wie jedes Enterprise Data Warehouse, das er zuvor gesehen hatte brauchte jedes Zielobjekt im EDW je einen Ladeprozess zum Laden von historischen und für aktuelle Daten sowie einen generell initialen Ladprozess (Initial Load). In der Regel unterschieden sich all diese Ladeprozesse und es gab keine Möglichkeiten diese zu standardisieren.

(Wer kennt das nicht. Ich habe das auch schon so oft gesehen und auch so implementiert.)

Die Lösung für dieses Dilemma war zweistufig:

1. Bei jedem Ladeprozess waren die Business Rules anders, unterschieden sich grundlegen. Die Business Rules nicht mehr an einer Stelle, sondern an zwei verschieden Stellen im Ladeprozess auszuführen führte zum Ziel: Hard (Data type (Domain) alignment, Normalisierung) und Soft Business Rules (ändern das Korn oder den Inhalt der Daten).
2. Auslagern der Relationen: Eine Historisierung von Daten „bricht“ immer die Parent-Child Beziehung auf, die in einem EDW Datenmodel modelliert wurde. Hier ermöglichte der Link als Many To Many Objekt, dass das Data Vault Model unabhängig und zukunftsfähig wurde und weniger anfällig gegenüber Änderungen ist.

Darüber hinaus führten Anforderungen an das EDW, wie z.B.

• Kostenreduktion bei der Maintenance und der Verwaltung
• Minimierung von Auswirkungen auf das Datenmodell durch Änderungen

neben den oben genannten Punkten ebenfalls zum Satelliten. Schlussendlich führten Performanceaspekte

• zum Load-End-Date,
• zu Hilfs-Konstrukten wie Point-In-Time (PIT)- und Bridge-Tabellen.

Das soll es in dieser Zusammenfassung gewesen sein.