DWH-Modellierung mit Data Vault - Home: DOAG e.V. · DWH-Modellierung mit Data Vault in Kombination mit ODI 12c - Erfahrungen aus der Praxis Claus Jordan Senior Consultant DOAG-Konferenz
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution-Engineering und der Erbringung von IT-Services mit Fokussierung auf und Technologien im D-A-CH-Raum.
Unsere Leistungen erbringen wir aus den strategischen Geschäftsfeldern:
Trivadis Services übernimmt den korrespondierenden BetriebIhrer IT Systeme.
Die zentrale Komponente des Data Warehouses – in unserer Architektur das Core – wird bei diesem Modellierungsansatz als Data Vault bezeichnet. Ein Data Vault besteht aus drei verschiedenen Strukturen, die als Tabellen implementiert werden:
Hubs enthalten ausschliesslich die Business Keys der fachlichen Entitäten sowie einen künstlichen Schlüssel, der von Links und Satellites referenziert wird. Beschreibende Attribute werden nie in Hubs abgespeichert, sondern in Satellites ausgelagert.
Links beschreiben Beziehungen zwischen Entitätstypen (Hubs) und erlauben generell die Definition von n-zu-n- Beziehungen zwischen verschiedenen Hubs. Auf eine fachliche Abbildung der Kardinalitäten (1:1, 1:n, n:n) wie in der klassischen relationalen Datenmodellierung wird hier verzichtet.
Satellites umfassen sämtliche beschreibenden Attribute von Entitätstypen oder Beziehungen in versionierter Form. Ein Satellite wird via Fremdschlüsselbeziehung einem Hub oder einem Link zugeordnet. Pro Hub/Link können mehrere Satellites definiert werden.
Relativ Hoch ����.. weil pro Entität zwei oder mehr Tabellen, plus eine oder mehrere Tabelle für jede Beziehung zwischen Entitäten, notwendig sind. Dies ermöglicht jedoch, gerade bei „breiten Entitäten“ (z.B. Mitarbeiter), eine gezielte Gruppierung von Attributen und erleichtert somit die Übersicht. Pro Tabelle resultiert ein ETL-Prozess.
ETL-Komplexität für das Laden aus Cleanse in Core
Gering ☺☺☺☺.. zumal keine performanceintensiven Updates notwendig sind. D.h. Datensätze werden nur dann eingefügt, wenn tatsächlich Änderungen an den betreffenden Attributen vorkommen.
ETL-Komplexität für das Laden aus Core in Data Marts
Mittel bis hoch ��������
.. aufgrund der Transformation vom normalisierten in das denormalisierte Datenmodell (Star- / Snowflake), und vor allen Dingen wegen der Bildung von neuen Gültigkeitsintervallen bei der Verknüpfung von unabhängig versionierten Stammdatenentitäten. Diese Logik kann beispielsweise in Datenbank-Views implementiert werden. Dadurch ist der Zugriff ähnlich einfach wie im dimensionalen Datenmodell und stellt somit kein KO-Kriterium dar.
Hoch ☺☺☺☺.. aufgrund fehlender Referenzen zwischen Entitäten, die jeweils unanabhängig voneinander erweitert oder angepaßt werden können.
Datenredundanz / Datenvolumen
Gering ☺☺☺☺.. durch Normalisierung (geringe Datenredundanz) und Splittung der Attribute, welche zu einer einer Hub-Table gehören, in mehrere Satellitentabellen
Parallelisierbarkeit Hoch ☺☺☺☺.. sowohl bei der Implementierung als auch im laufenden Betrieb beim Laden der Daten. Sämtliche Hub-Tables können parallel implementiert / geladen werden. Dasselbe gilt für alle Link-Tables und für die Satellite-Tables (jeweils Voraussetzung sind die Hub-Tables)
Historisierung / Nachvollziehbarkeit
Sehr hoch ☺☺☺☺.. weil standardmäßig in den Satellite-Tables der DWH-Schicht Core jede Änderung historisiert wird und sei sie noch so gering.
� Hub-Tables:Welche Datensätze sind neu? Diese Datensätze einfügen (Insert)
� Link-Tables: Lookup zu den Hub-TablesWelche Datensätze sind neu? Diese Datensätze einfügen (Insert)
� Satellite-Tables:Lookup zur Hub-Table bzw. zu den Link-Tables Welche Datensätze sind neu oder haben sich geändert (Dabei werden nur die Attribute der zu ladenden Satellite-Tabelle berücksichtigt)? Diese Datensätze einfügen (Insert)
� Durch die mehrschichtige Architektur des HR Data Warehouse sind Datenströme und Transformationen sehr gut nachvollziehbar. Außerdem sind die Mappings dadurch wenig komplex.
� Das Data Vault Datenmodell ist ideal ..� .. wenn eine lückenlose Historisierung der Daten erwünscht ist� .. wenn wenig Datenredundanz und damit hohe Datenkonsistenz
notwendig ist� .. wenn der Aufwand für das Hinzufügen neuer Entitäten, Attribute und
Beziehungen möglichst klein sein soll� .. wenn rückwirkende Änderung von Stamm- und Bewegungsdaten
jederzeit möglich sein sollen� .. Wenn parallel entwickelt werden soll
� Mit den Knowledge Modulen von ODI können alle möglichen Ladestrategien und Sonderfälle effizient abgebildet werden