Generation Data Vault

FOKUSARTIKEL
Generierung von Tabellen und Mappings für Data-Vault-Modelle
Generation Data Vault
DWH-Projekte erfordern ein flexibles und dennoch stabiles Datenmodell. Genau hier erreicht die Modellierungsmethode Data Vault gegenüber anderen Methoden eine deutlich höhere Punktzahl. Diese Art der Modellierung stellt
dank ihrer hohen Flexibilität sowohl bei Erweiterungen und als auch bei der Trennung in fachliche Datentypen eine
ideale Grundlage für DWH-Initiativen dar.
In den letzten Jahren hat sich mit „Data Vault“ eine neue
DWH-Modellierungsmethode profiliert, die für zentrale Speicher- und Integrationsschichten eine Alternative zu
klassischen Modellierungsmethoden darstellt. Data Vault
bietet ein einfaches Grundmodell mit wenigen Basiskonzepten, das es erlaubt, massiv parallelisierbare Ladeprozesse zu
nutzen. Die strukturelle Entkopplung der Daten ermöglicht
eine agile und einfache Erweiterbarkeit des Datenmodells
und des Data Warehouse.
Die Besonderheit, die Data Vault von den Klassikern der
Modellierung – der dritten Normalform (3NF) und den dimensionalen Modellen (Sternschema, Snowflake-Schema)
– unterscheidet, besteht darin, dass bei der Modellierung
alle zu einem Objekt gehörenden Daten in drei Kategorien
unterteilt und strikt getrennt voneinander abgelegt werden.
In die erste Kategorie gehören Informationen, die einem
Objekt seine Identität geben, der sogenannte Business-Key.
Diese Schlüsselinformationen (grau in Abbildung 1) werden
in Hubs abgelegt. Attribute, die ein Objekt grundlegend beschreiben, fallen in die zweite Kategorie, die Satelliten. Diese sind in Abbildung 1 gelb markiert. Die dritte Kategorie
bilden die Informationen, welche die Relationen zwischen
zwei oder mehr Objekten beschreiben. Informationen dieser
Art werden in „Links“ geschrieben und sind in Abbildung 1
orange hinterlegt.
Abbildung 1 veranschaulicht das Vorgehen am Beispiel
einer Kundentabelle. Diese ist einmal in einer vereinfachten
dritten Normalform und einmal als Data Vault modelliert.
Jede Tabelle enthält nur Attribute aus einer der drei genannten Kategorien. Das Feld „Zeitstempel“ steht in der Abbildung synonym für jede Art zeitlicher Abgrenzung. Diese
kann sowohl einfach mit nur einem Ladezeitstempel erfolgen als auch komplexer mit zwei Feldern für eine „von/bis“
Abgrenzung.
Klare Trennung von Identitäten,
Eigenschaften und Beziehungen
Abb. 1: Datenmodelle im Vergleich
Eine Tabelle in der dritten Normalform ist bereits redundanzfrei und wird in der Modellierung mit Data Vault durch
drei Tabellen ersetzt. Werden die Abhängigkeiten der Tabelle KUNDE betrachtet, müssen erst die referenzierten Tabellen KUNDENTYP und RECHNUNGSTYP aktualisiert
worden sein, bevor die Beladung von Tabelle KUNDE erfolgen kann.
Genau diese im 3NF erhöhte Komplexität im WorkflowProzess bildet die Basis für die wesentlichen Vorteile von
Data Vault, mit dem dieser Schwierigkeitsgrad wieder reduziert wird. Denn was bei kleinen Modellen noch überschaubar ist, wird in komplexen Modellen schnell unübersichtlich
und damit fehleranfällig. Die Verteilung auf mehrere Tabellen löst dieses Problem. Das Data-Vault-Modell ist immer
auf die gleiche Weise zu laden und die Beladung ist dazu
noch sehr einfach zu parallelisieren, da es weder physikalische noch logische Abhängigkeiten zwischen Objekten der
jeweils gleichen Kategorie gibt (eine Ausnahme wäre eine
Link-auf-Link-Verbindung, die durchaus erlaubt ist).
Abbildung 2 zeigt, wie sich die Abhängigkeiten der Ladeprozesse bei Data Vault gestalten. Durch die Verwendung
von Hash-Keys anstelle von IDs in der Version 2.0® von
Data Vault werden diese Abhängigkeiten sogar noch weiter
reduziert. Sofern die benötigten Hash-Keys bereits beim
Extract-Prozess des ETL-Tools erzeugt werden (möglicherweise beim Beladen der Staging Area sogar dort persistiert),
lässt sich die Beladung eines Core Warehouse noch weiter
ONLINE THEMENSPECIAL DATA VAULT MODELING
01
FOKUSARTIKEL
Ladeprozesse für Data Vault
parallelisieren, da entsprechende
Look-ups für Keys beim Beladen abhängiger Tabellen nicht
mehr notwendig sind.
beschrieben. Des Weiteren werden technische Spezifikationen
der Lieferung von einem technischen Analysten identifiziert.
Dimensionen
Ist das Sheet ausgefüllt, kann
anschließend der Export (1a) geInkrementell erweiterbar
startet werden. Für die GenerieSatelliten der Links
Neben der guten Möglichkeit,
rung der Mappings im späteren
Ladeprozesse zu parallelisieren,
Verlauf werden außer den DDLs
und der entkoppelten Abhängigfür die Data-Vault-Datentabellen
Satelliten der Hubs
Links
keiten bietet diese strikte Trenweitere Dateien aus dem Sheet
nung der fachlichen Datentypen
heraus erzeugt (1b). Dabei hanweitere Vorteile gegenüber der
delt es sich um SQL-Skripte
Hubs
herkömmlichen Modellierung.
zum Erstellen der benötigten
Muss ein solches Datenmodell
Staging-, Error- und ValidieStaging
erweitert werden, weil zum Beirungstabellen. Diese beinhalten
spiel Daten aus einem weiteren
Tabellendefinitionen, die ebenQuellsystem integriert werden Abb. 2: Ladeprozesse
falls im Excel-Sheet festgelegt
sollen oder sich die Anforderunwurden, sowie einige weitere
gen ändern, müssen keine bestehenden Tabellen modifiziert technische Attribute. Die SQL-Skripte können anschließend
werden. Stattdessen werden bei jedem weiteren Inkrement auf der Datenbank ausgeführt und eingespielt werden. Au„nur“ Tabellen hinzugefügt (siehe Abbildung 3). Liefert das ßerdem werden Definitionsdateien kreiert, die technische
neu angebundene System beispielsweise weitere Informa- Beschreibungen der Anbindung ans Quellsystem sowie die
tionen zum KUNDEN, wird hierfür einfach ein weiterer Tabellendefinitionen für die Quelltabellen/Quelldateien und
Satellit angelegt, der den gleichen Hub referenziert. Eine die Zieltabellen enthalten. Ergänzend folgen dann noch Daweitere Anpassung des Modells ist nicht erforderlich.
teien für die technischen Attribute der Zieldatenbank sowie
Auch der Einfluss auf die Beladungsprozesse ist mini- Tabellendefinitionen und technische Attribute für die Fehmal. Lediglich die Beladung des Kunden-Hubs muss um lertabelle ebenso wie die Validationstabelle. Als Letztes
eine Quelle ergänzt werden. Da Hubs immer auf dieselbe ergibt sich daraus noch die MAV-Staging-Parameterdatei.
Weise geladen werden, werden hier je nach ETL-Werkzeug Um mit MapGen (Informatica Kommandozeilenbefehl) das
konfigurierbare Templates verwendet, sodass diese Anpas- finale Mapping auf Basis der MAV-Files zu generieren, besung im besten Fall nur eine Änderung der Konfiguration nötigt man neben dem eigentlichen MAV Staging Template
erfordert. Im Falle von Generatoren (siehe nächsten Ab- auch ein Parameter-File für den MAV. Dieses Parameterschnitt) wären mit dieser „Konfiguration“ bereits fast alle File wird ebenfalls aus dem entsprechenden Excel-Sheet
notwendigen Arbeiten erledigt.
generiert.
Für das Generieren des Mappings über das MAV Template ist es notwendig, dass die Quell- und Zieldefinitionen in
Generierung von Tabellen und ETL-Mappings
einem Format vorliegen, das dem ETL-Tool bekannt ist. DaDie idealtypische Trennung in fachliche Datentypen sorgt für werden die unter 1b erzeugten Dateien verarbeitet und
nicht nur für eine höhere Verständlichkeit und Wartbarkeit in entsprechenden Ordnern abgelegt. Diese Formatierung
des Modells an sich, sondern sie ist auch prädestiniert dafür, viele Arbeitsschritte bei der
Erstellung eines Data Warehouse zu automaErweiterung um
Sat 2 zu
tisieren. Gerade das hohe Maß an Gleichföreinen Satelliten
Hub 1
migkeit der Tabellen in Bezug auf ihre Struktur
fördert diesen Gedanken und führt in logischer
Konsequenz in Richtung eines Generators soSat 1 zu
Hub 1
wohl zum Erstellen von DDL-Skripten zwecks
Ursprünglicher
Hub 1
Zustand
Erzeugung der benötigten Tabellen als auch
Sat
1 zu
Hub 2
Link 1
Hub 2
der Generierung von ETL-Mappings zu deren
Sat 1 zu
Befüllung. Abbildung 4 verdeutlicht diesen
Hub 3
Hub 3
Gedanken unter Einbeziehung von Informatica
Powercenter als ETL-Werkzeug und Excel sowie Java beziehungsweise Mapping Architect
Erweiterung
for Visio (MAV) als Informationsquellen.
um eine neue
Sat 1 zu
Hub 4
Entität
Link 2
Zu Beginn steht hier das Ausfüllen eines
Hub 4
Schnittstellen-Template durch Business-Analysten unter Hinzuziehung technischer Analysten. In diesem Template sind die Felder,
Feldgrößen und Feldtypen der Datenlieferung Abb. 3: Erweiterbarkeit
02
ONLINE THEMENSPECIAL DATA VAULT MODELING
Fakten
FOKUSARTIKEL
und Ablage geschieht mit
der entwickelten JavaApplikation namens Java
Create Definition (2).
Die Erstellung des
MAV Template muss einmalig und in mehreren
Schritten durchgeführt
werden. Als Erstes wird
ein
Beispiel-Mapping
im ETL-Tool (Informatica PowerDesigner) entwickelt und exportiert.
Dieses Mapping wird anschließend in den „Mapping Architect for Visio“
importiert und angepasst.
Die Anpassungen beinhalten die Parametrisierung von dynamischen
Inhalten sowie RegelDefinitionen. Anschließend wird aus dem MAV
Abb. 4: Automatische Generierung von Tabellen und Mappings
Template das Informatica
PowerCenter MappingTemplate aus Visio Programm „publiziert“ (3), was einer tifier, in den Hub geschrieben. Sobald das Template erstellt
und parametrisiert wurde, kann eine Parameter-XML-Datei
Speicherung des Template als XML-Datei entspricht.
Über MapGen, eine Informatica Konsolen-Applikation, erstellt werden. Diese beinhaltet die konfigurierbaren Elewerden mit Hilfe des MAV Template und des entsprechen- mente wie Tabellen- und Spaltennamen sowie Expressions
den Parameter-File die Mappings für den Staging- und Va- und muss für jeden Hub erstellt beziehungsweise generiert
lidierungs-Layer generiert (4). Die aus MapGen generierten werden.
Für die Befüllung der Hub-Satelliten sind zusätzliche
Informatica Mappings werden in das Informatica RepositoSchritte notwendig. Auch hier werden die Quelldaten sery importiert und für die Datenbeladung verwendet.
lektiert und der künstliche Schlüssel (und ebenfalls der
Hash-Wert auf den Business-Key) automatisiert generiert,
Konklusion
der dann als Fremdschlüssel auf den Hub verwendet wird.
Zusammenfassend lässt sich festhalten, dass für die Ge- Zusätzlich ist eine Deltaerkennung notwendig, da nur generierung dieser ETL-Mappings und DDLs mehrere Teil- änderte Datensätze in die Satelliten geschrieben werden
sollen. Auch dafür ist der Einsatz eines Hash-Mechanisschritte notwendig sind, die wie folgt aufgebaut sind:
1. Erfassung der Schnittstellenbeschreibung in einem Ex- mus sinnvoll. Ansonsten muss jedes Attribut einzeln mit
cel-Sheet-Template (Erfassungs-Sheet) und Generierung den bereits vorhandenen Datensätzen verglichen werden.
Im Falle neuer oder geänderter Datensätze werden die
von Dateien (VBA-Sheet) für die nächsten Teilschritte
Werte mit einem neuen Gültigkeitsdatum eingefügt. Da
2. Import der Datenbankobjekte
3. Generierung der ETL-Quellen und -Ziele mit dem Java die Anzahl der Attribute in den Satelliten dynamisch ist,
muss die Generierung hier entsprechend flexibel gestaltet
Tool DefinitionCreate
werden. Über die Parameter-XML-Datei werden pro Hub4. Generierung der ETL-Mappings mit MapGen
Satellit die entsprechenden Parameterwerte zur Generie5. Import der ETL-Mappings ins Repository
Um die Mappings für das Data-Vault-Datenmodell generie- rung übergeben.
Im Prinzip sind Links ähnlich aufgebaut wie Hubs,
ren zu können, müssen dafür MAV Templates erstellt werden. Benötigt werden diese für die Tabellentypen Hub, Hub allerdings besteht hier die Dynamisierung in der unterschiedlichen Anzahl der Fremdschlüssel. Dies ist mit InSatelliten, Links und Link Satelliten.
Ein Hub-MAV-Template beinhaltet als ersten Schritt formatica Mapping Architect for Visio nicht so ohne Weidie „Distinct“-Selektion der Business-Keys aus der Da- teres zu bewerkstelligen. Somit ist es notwendig, je ein
tenquelle. Der neue künstliche Schlüssel wird immer auf Template für zum Beispiel Links mit zwei, drei oder vier
die gleiche Weise durch Einsatz eines Hash-Mechanismus Fremdschlüsseln zu erstellen. Für jeden dieser Typen muss
aus dem Business-Key gebildet. Anschließend erfolgt über differenziert die Parameter-XML-Datei zur Generierung
einen Look-up die Prüfung, ob der Business-Key-Hash im erstellt werden.
Für die Link-Satelliten hingegen ist es wieder ausHub bereits existiert oder neu eingefügt werden muss. Im
Falle neuer Daten werden diese, angereichert mit techni- reichend, ein einziges Template zu erstellen, unabhängig
schen Attributen wie Ladezeitpunkt, Quellsystem und Iden- davon, wie viele Fremdschlüssel vorliegen. Der Fremd-
ONLINE THEMENSPECIAL DATA VAULT MODELING
03
FOKUSARTIKEL
schlüssel auf den Link wird durch das Zusammenfügen der
verschiedenen Business-Keys und entsprechendes Hashing
erreicht. In der Parameter-XML-Datei muss der Parameter
für den künstlichen Schlüssel entsprechend gefüllt werden.
Um die Parameter-XML-Dateien nicht manuell erstellen
zu müssen, bietet es sich an, diese ebenfalls zu generieren.
Die Data-Lineage-Daten für die verschiedenen Data-VaultTabellen können in einer Datenbanktabelle oder einer (Excel-)Datei abgelegt werden. Wird eine Oracle-Datenbank
verwendet, besteht die Möglichkeit, über XML-Query die
entsprechenden Parameter-XML-Dateien zu erstellen. Alternativ können diese auch mittels ETL-Mappings generiert
werden.
Fazit
Durch den Einsatz von Generatoren zur Generierung von
Mappings im ETL-Tool können einheitliche Entwicklungstätigkeiten wie die Befüllung der Hubs, Satelliten und Links
optimiert werden. Die Erstellung des Data Lineage Excel
Sheet ist mit wesentlich geringerem Aufwand verbunden als
die Implementierung durch ein großes Entwicklerteam und
kann zudem vom Analysten in der Konzeptionsphase vorgenommen werden. Ein weiterer Vorteil besteht bei Fehlerkorrekturen, Änderungen im Lademechanismus oder Datentypänderungen. Anstatt alle Mappings manuell anzupassen,
können diese mit geänderten Lineage-Informationen neu
generiert werden. Auch im Testbereich verringert sich der
Aufwand enorm. Müssen bei klassischen Entwicklungen
alle manuell erstellten Mappings getestet werden, entfällt
dies bei den generierten. Die erstellten Templates können
per Unit-Test überprüft und somit aufwandsarm qualitätsgesichert werden.
Leider funktioniert diese Methode lediglich von der
Quelle bis zum Raw Data Vault. Sobald komplexe BusinessRegeln im ETL-Umfeld ins Spiel kommen, verhindern diese
meist eine hohe Konformität, welche die wesentliche Voraussetzung für den Einsatz von Generatoren ist. Den weiteren Datenstrom in Richtung Data Marts wird man daher
in klassischer Entwicklung gestalten müssen. Vieles spricht
aber dennoch dafür, den initial höheren Aufwand zur Erstellung der Generatoren in Kauf zu nehmen, um bei zukünftigen Entwicklungen, Fehlerkorrekturen oder Re-Tests Zeit
und somit finanzielle Mittel einzusparen.
Ganz allgemein gilt aber, dass die Verwendung der DataVault-Modellierungsmethode der wesentliche Schlüssel für
die Erstellung und den Einsatz eines solchen Generators ist.
Die Designkonformität der einzelnen Tabellentypen unter
Data Vault macht diesen Einsatz erst sinnvoll. In jeder anderen Modellierungsmethode wäre der Aufwand auch mit dem
Einsatz von Generatoren – falls überhaupt sinnvoll – deutlich höher und meistens budgettechnisch nicht vertretbar.
Der Einsatz von Generatoren für den beschriebenen
Zweck wurde auch unter Verwendung des ODI (Oracle Data
Integrator) im realen Projekt­umfeld getestet und lieferte bezüglich Aufwand und Entwicklungsgeschwindigkeit ebenso
gute Ergebnisse wie mit Informatica PowerCenter, die ebenfalls im realen Umfeld erarbeitet wurden. Der GeneratorAnsatz bei der Data-Vault-Modellierung ist also generisch
und unabhängig vom ETL-Tool, sofern dieses die Generierung von Mappings unterstützt. Die Quintessenz lautet demzufolge: Bei der DWH-Entwicklung können die Generatoren von der Quelle über die Staging Area bis zum Raw Data
Vault verwendet und sinnvoll eingesetzt werden.
[ Literatur ]
Linstedt, D.: Super Charge your Data Warehouse. 2011
Hultgren, H.: Modeling the Agile Data Warehouse with
Data Vault. New Hamilton 2012
Data Vault 2.0 Bootcamp: danlinstedt.com,
learndatavault.com
Michael Klose und Markus Kollas sind Senior Solution Architekten für BI bei der CGI Deutschland Ltd. & Co.,
­Sulzbach/Taunus. E-Mail: michael.klose@cgi.com
04
ONLINE THEMENSPECIAL DATA VAULT MODELING
Der Artikel erschien erstmals in BI-Spektrum 2/2015.