Datenmodellierung mit Data Vault & ETL in die Data Vault Tabellen and in die Data Mart Dimensionen

Datenmodellierung mit Data Vault & ETL in die Data Vault Tabellen and in die Data Mart Dimensionen

Rate This
  • Comments 4

Um was geht es?

Data Vault ist eine Modellierungsmethode für das Datenmodell eines Data Warehouse und dort insbesondere für die zentrale Schicht geeignet, die häufig als Core bezeichnet wird. Alternativen zu Data Vault sind unter anderem das rein dimensionale Datenmodell (Snowflake/Star Schema) oder die Modellierung in 3. Normalform mit Kopf- und Versionstabellen. Die Modellierung des Core mit Hilfe der Data Vault Methode ist in großen Teilen sehr ähnlich wie die von mir häufig angewendete Modellierungsmethode mit Hilfe von Kopf- und Versionstabellen (siehe auch unser Buch http://www.amazon.de/Data-Warehousing-mit-Oracle-Intelligence/dp/3446425624). Ich möchte die Modellierung mit Data Vault anhand eines sehr einfachen Beispiels erläutern und ein besonderes Augenmerk auf die Abfragelogik, aus Data Vault Strukturen heraus in dimensionale Strukturen hinein, lenken. Diese ist leider nicht ganz so trivial, aber auch nicht viel komplizierter als bei Kopf- und Versionstabellen.

Data Vault wurde 1993 von Dan Linstedt (http://danlinstedt.com/) "erfunden" und weiterentwickelt. Weitere Informationen hier:
http://datavaultacademy.com
http://hanshultgren.wordpress.com
http://en.wikipedia.org/wiki/Data_Vault_Modeling
http://blog.trivadis.com/b/danischnider/archive/2013/04/30/data-vault-modeling.aspx
http://blog.trivadis.com/b/danischnider/archive/2013/10/06/data-vault-challenge-workshop.aspx
http://hanshultgren.wordpress.com/2013/05/27/head-version-modeling/

Ich freue mich über Feedback und kritische Anmerkungen!

Logisches Datenmodell

Das Resultat der logischen Datenmodellierung ist meist ein ADAPT oder Entity Relationship (ER) Diagramm.

Beide Diagramme für dieses sehr einfache Beispiel führen zum selben Data Vault Datenmodell, welches im nächsten Abschnitt beschrieben wird.

Data Vault Datenmodell

Das Data Vault Datenmodell kann aus einem dimensionalen Datenmodell oder aus Entity Relationship Modellen (ER Modell) abgeleitet werden. Dabei wird in drei Tabellentypen unterschieden:

Hub-Tables
Aus dem oben dargestellten logischen Datenmodell  wird pro Hierarchiestufen bzw. Entität eine Hub-Table (Blau) abgeleitet. In diesem Fall zwei Stück, nämlich für Produkt und ProductSubcategory, welche neben den Standardspalten die natürlichen Schlüsseln (Business Key oder Natural Key), eine Spalte für den Timestamp und eine für die Source enthalten. Die beiden zuletztgenannten sind Bestandteil jeder Data Vault Tabelle und geben an, wann ein Datensatz in die Tabelle eingefügt wurde und aus welchem Quellsystem diese stammen. Pro Hierachiestufe bzw. pro Entität exisitert im Data Vault Datenmodell eine Hub-Table.

Link-Tables
Die Link-Tables (rot) dienen zur Abbildung von Beziehungen zwischen zwei oder mehreren Hub-Tables. Sie enthalten Referenzen auf den Primärschlüssel der Hub-Tables. Link-Tables können (müssen aber nicht) Satallite-Tables haben um weitere Informationen zur Beziehung (z.B. Gewichtungsfaktoren) zu speichern. Durch diese Art der Modellierung wird die Kardinalität bewusst nicht durch das Datenmodell eingeschränkt.

Satellite-Tables
Pro Hub-Table (und optional auch pro Link-Table) existiert mindestens eine Satellite-Table (gelb) zur Aufnahme der eigentlichen Attribute, ausgenommen des natürlichen Schlüssels. Im Extemfall kann für jedes (!) Attribut eine eigene Satellite-Table definiert werden. Sinnvoller erscheint jedoch eine Gruppierung nach der Änderungshäufigkeit. Zum Beispiel:
- COR_PROD_S01: Attribute die sich normalerweise gar nicht ändern
- COR_PROD_S02: Attribute die sich nur selten ändern
- COR_PROD_S03: Attribute die sich sehr häufig ändern

Blau: Hubs
Gelb: Satelliten
Rot: Links

Zusammenfassung:

  • Die Hub-Table und die zugehörigen Satellite-Tables resultieren aus einer Hierarchiestufe oder aus einer Entität.
  • Beziehungen, auch 1:n Beziehungen, werden als separate Tabelle, der Link-Table modelliert.
  • Link-Tables referenzieren niemals die Satellite-Tables sondern immer zwei oder mehr Hub-Tables. Bei Link-Tables sind Satellite-Tables optional. Sie werden nur dann benötigt, wenn zusätzliche Attribute zur Beziehung selbst benötigt werden (z.B. Gewichtungsfaktoren, Status)

ETL into Data Vault

Hier nur die Grundlogik je Tabellentyp:

  • Hub-Tables:
    • Einfügen noch nicht geladener Products bzw. ProductSubCategories
  • Link-Tables:
    • Einfügen von noch nicht vorhanden Beziehungen zwischen Products und ProductSubCategories
    • Einfügen von geänderten Beziehungen zwischen Products und ProductSubCategories
  • Satellite-Table:
    • Einfügen noch nicht geladener Products, ProductSubCategories und Beziehungen zwischen Products und ProductSubCategories (in diesem Fall gibt es für die Link-Table keine Satellite-Table)
    • Einfügen von geänderten Products, ProductSubCategories und Beziehungen zwischen Products und ProductSubCategories (bezüglich der Attribute, welche in der jeweiligen Satellite-Table gespeichert werden)

Wie man sieht, gibt es keine Updates wodurch die Logik sehr einfach gehalten ist und das Laden recht effizient erfolgen kann.

View Layer (Core)

Um die Abfragen auf die Data Vault Tabellen zu vereinfachen, kann für jede Entität und für jede Beziehung zwischen den Entitäten eine View definiert werden. Insbesondere die View für die Entität Product ist interessant, weil darin die unabhängig voneinander historisierten Satellite-Tables COR_PROD_S01 bis COR_PROD_S03 miteinander kombiniert werden. Gleichzeitig werden in den Views aus der Spalte DWH_TIMESTAMP das Gültigkeitsintervall DWH_VALID_FROM und DWH_VALID_TO abgeleitet.

View Layer (Mart)

Sollen die verschiedenen Entitäten aus dem Core zusammengeführt werden, um sie zum Beispiel in denormalisierte Dimensionstabellen zu laden, kann dies ebenfalls über Views erfolgen. Die View in diesem Beispiel kombinert die beiden Entitäten Product und ProductSubCategory.

Da die einzelnen Entitäten in den Satellite-Tables im Core vollständig, und vor allen Dingen unabhängig voneinander historisiert werden, müssen die Daten für die dimensionale Speicherung (egal ob Star oder Snowflake)  etwas aufwändiger transformiert werden. Aus dem DDL-Script für diese View (siehe Anhang) ist ersichtlich, dass die Core-Views (siehe oben) verwendet werden.

Anhang

Im Anhang befindet sich ein Implementierungsvorschlag für Tabellen und Views für das DWH Layer Core:

  • DDL Scripts für Views auf die Data Vault Tables (datavault_core_*.sql)
  • DDL Script für eine View, welche die Dimension Product, bestehend aus den Levels Product und ProductSubCategory (datavault_mart_*.sql)
  • SQL Developer Datamodeler Datenmodell (SQL_Developer_Datamodeler_Datavault_Beispiel.zip)
Attachment: DataVault Examples v1.2.zip
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Post
  • Hi Claus,

    Seems really interesting your post ! Would you be able to write it english too?

    Cheers,

    Philippe Bourgeois

  • Sehr geehrter Herr Jordan,

    wir haben festgestellt, dass Data Vault in Deutschland zwar noch ein recht "junges Pflänzchen" ist - aber doch an einigen Orten schon sprießt. Austausch in der deutschen Data Vault Community gibt es jedoch bisher noch recht wenig. Auf der letzten Data Modeling Zone in Hannover entstand daher der Wunsch, eine deutschsprachige Data Vault User Group zu gründen.

    Die 1. Tagung (quasi die konstituierende Sitzung) der DDVUG findet am 24. Juni 2014 in München statt. Als Ehrengast konnten wir Dan Linstedt, den Autor und Erfinder von Data Vault, gewinnen. Ziel der Gruppe ist ein lebhafter interaktiver Austausch der Data Vault User im deutschsprachigen Raum.

    Die Tagung findet parallel zur TDWI-Konferenz in der selben Messe-Halle statt (MOC München). Die DDVUG ist keine Veranstaltung des TDWI - jedoch haben die Teilnehmer der DDVUG in den Pausen, sowie vor und nach der Tagung Gelegenheit, die Ausstellungsfläche der TDWI-Konferenz zu besuchen, auf der nahezu alle im deutschsprachigen Raum vertretenen BI-Anbieter ausstellen.

    Ich würde mich freuen, wenn wir Sie auch als Teilnehmer auf der DDVUG begrüßen dürften.

    Viele Grüße

    Christian Hädrich

  • Hallo Klaus

    Ich finde den Ansatz sehr spannend und elegant, sehe aber das Probleme, dass Löschoperationen nicht möglich sind. D. h. ein Eintrag endet erst, wenn ein neuer eingefügt wird. Wie gehst Du damit um?

    Viele Grüsse

    David

  • Hallo David,

    aus meiner Sicht ist das etwas abhängig davon, was gelöscht wird.

    Löscht man z.B. eine Auftragsposition, so kann man das dadurch darstellen, dass man den Link zwischen Auftrag und Position löscht.

    Um aber z.B. die Löschung eines Kunden abzubilden, würde ich im Satelliten ein Gültig-Feld setzen. Wird der Kunde im Quellsystem gelöscht, so wird das Feld auf 0 gesetzt.

    Hoffe, dass du das meintest.

    Grüße Thomas

Page 1 of 1 (4 items)
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Post