Das Data Vault-Konzept mit Beispiel

Die Data Vault Methode und ihre wichtigsten Elemente

In diesem Artikel wird die Data Vault Methode zunächst grundsätzlich vorgestellt und der Modellierungsansatz anhand eines Fallbeispiels erläutert.

Ein Data Vault Modell besteht aus den folgenden drei Komponenten:

Data Vault-Element	Beschreibung
	Hubs enthalten die Business Keys bzw. die natürlichen Schlüssel wie z.B. Rechnungsnummer, Kundennummer oder Mitarbeiternummer. Es sind aber keine beschreibenden Attribute enthalten.
	Links dienen zur Abbildung von Beziehungen zwischen Hubs und enthalten somit nur Fremdschlüsselattribute auf Hubs.
	Satellites enthalten beschreibende Attribute wie beispielsweise Kundeninformation oder Produktbeschreibungen und werden Hubs oder Links zugeordnet.

Einfaches Szenario für den Einsatz eines Data Vault

Zur Veranschaulichung der Grundaspekte der Modellierung dient das folgende Fallbeispiel. Die fiktive „Agentur Diamond“ ist eine große Event-Agentur, welche außergewöhnliche Produkte und Events zur Freizeitgestaltung vertreibt und so ihre Kunden „spezielle Momente“ erleben lässt. Das Produktportfolio reicht vom Fallschirmspringen, über Rennwagenfahren bis hin zum Candle-Light Dinner. Das Unternehmen erwirtschaftete im letzten Jahr einen Umsatz von 125 Mio. € und beschäftigt 250 Mitarbeiter.

Die grundlegende Systemlandschaft

Die Agentur betreibt zur Abwicklung der operativen Prozesse eine klassische Enterprise Resource Management (ERP)-Lösung. Darauf aufbauend wird zum Lieferantenbeziehungsmanagement eine Supplier Relationship Management (SRM) -Lösung eingesetzt. Die Kundenprozesse werden durch ein Customer Relationship Management (CRM)-System unterstützt. Die Events werden den Kunden über einen Webshop präsentiert, welcher auch das Bestellwesen im Front-End abwickelt.

Sämtliche Daten werden in das Data Warehouse integriert. Die analytischen Anwendungen stellen ein klassisches Standard-Reporting zur Verfügung. Darüber hinaus werden verschiedene Data Mining-Anwendungen eingesetzt. Beispielsweise wird das Kaufverhalten durch Warenkorbanalysen analysiert und Assoziationsregeln aus dem Datenbestand extrahiert. Das Produktportfolio und die Präsentation im Shop werden basierend auf diesen Analysen optimiert.

Überblick über das Modellierungs-Szenario

Wie oben dargestellt, basiert das Data Warehouse der Agentur Diamond auf dem Data Vault Architekturansatz. Das Fallbeispiel greift einen Aspekt des Kundenmanagements auf und verdeutlicht die Data Vault-Modellierungsmethodik und zeigt, wie Änderungen im Modell aufgenommen werden. Zur Veranschaulichung werden daher folgende drei Iterationen durchlaufen:

1. Das Grundmodell wird in der ersten Iteration erstellt.
2. Aufgrund einer Änderung in einem der Quellsysteme muss in der zweiten Iteration das Data Vault Modell angepasst werden.
3. In der dritten Iteration wird aufgrund einer Spezifikationslücke das Data Vault Modell ergänzt.

Ausgehend vom Grundmodell werden im Beispiel somit die wesentlichen Auslöser für Anpassungen aufgegriffen und gezeigt, wie die Veränderungen im Data Vault Modell aufgenommen werden.

Iteration 1

Im ersten Schritt sollen die Kunden, als wichtigste Akteure der Agentur Diamond, im Datenmodell erfasst werden:

• Kunden weisen Attribute wie Vorname und Name auf und sind eindeutig einer Region zugeordnet. Die Kunden und die entsprechenden regionalen Zuordnungen werden im ERP-System zentral gepflegt.
• Leider sind die Zuordnungen der Kunden zu den Kundenbetreuern zurzeit nicht in den operativen Systemen hinterlegt. In den Auswertungen wird aber schon seit einiger Zeit dieser Zusammenhang nachgefragt, da bei den Kundenbetreuern keine Transparenz über den Kundenbestand herrscht.
• Ein Change-Request zur Bereitstellung der Funktionalität „Kunde zu Kundenbetreuer zuordnen“ im CRM-System wurde beauftragt.

Das oben beschriebene Szenario wird in der Iteration 1 wie folgt im Data Vault-Modell abgebildet:

• Die Business-Objekte Kunde und Region werden im als Hubs modelliert. In den Hubs werden lediglich die künstlichen Schlüssel („Hub ID“), die unternehmensweit eindeutigen Businessschlüssel („Kunden Nummer“ und „Region Nummer“), die Ladezeitstempel und die liefernden Quellsysteme gespeichert.
• Die Satellitentabellen umfassen die beschreibenden Attribute der Quellsysteme und bilden die vollständige Historie im Data Warehouse ab. Es werden der Fremdschlüssel zum Hub („Kunde ID“ bzw. „Region ID“), der Ladezeitstempel und die Datenquelle in den Satellitentabellen hinterlegt.
• Die Relation zwischen Kunde und Region wird als Link Kunde/Region modelliert. Die Tabelle enthält neben dem künstlichen Schlüssel „Link ID“ die Fremdschlüssel („Kunde ID“ und „Region ID“) der Hub-Tabellen Hub Kunde und Hub Region.

Für die erste Iteration ergibt sich das folgende konzeptionelle Modell:

Iteration 2

• Die CRM-Abteilung hat ganz Arbeit geleistet: Der Change-Request zur Bereitstellung der Funktionalität „Kunde zu Kundenbetreuer zuordnen“ wurde umgesetzt, getestet und befindet sind bereits im CRM-Produktionssystem!
• Das Data Warehouse Modell kann um die Beziehung zwischen Kunde und Kundenbetreuer erweitert werden.

In der Iteration 2 wird die Beziehung zwischen Kunde und Kundenbetreuer wie folgt ergänzt:

• Das Business-Objekt Kundenbetreuer wird als Hub ergänzt.
• Die Satellite-Tabelle Kundenbetreuerdetails enthält die beschreibenden Attribute des Kundenbetreuers.
• Die Zusätzliche Link-Tabelle „Link Kunde/Kundenbetreuer“ bildet die Relation zwischen dem Kunden und dem zugeordneten Kundenbetreuer ab.

Durch Ergänzung der beschriebenen Entitäten ergibt sich für die Iteration 2 das folgende Modell:

Iteration 3

Den Anwendern ist aufgefallen, dass im Data Warehouse Modell das Bundesland mit entsprechender Landeshauptstadt nicht auffindbar ist. Das Data Warehouse Modell muss um diese Attribute der Region ergänzt werden. In der Iteration 3 werden die fehlenden Attribute wie folgt zum Modell hinzugefügt:

→ Das Business-Objekt Bundesland wird als Satellit ergänzt und an den Hub Region angehängt.

Nach der dritten Iteration sieht das Modell wie folgt aus:

Zusammenfassung

Am Beispiel der Agentur Diamond wurde gezeigt, dass aus der Anwendung des Data Vault-Modellierungsansatzes eine hohe Flexibilität resultiert: In der Regel können Anpassungen in den Anforderungen, wie beispielsweise die Aufnahme von zusätzlichen Attributen ohne strukturelle Anpassung an bestehenden Tabellen erfolgen. Neue Attribute können über zusätzliche Satelliten realisiert werden. Bei klassischer 3NF-Modellen sind bei derartigen Veränderungen in der Regel Strukturanpassungen an Tabellen erforderlich und bestehende Daten zu migrieren. Die gezeigte, additive Erweiterung hat eine minimale Auswirkung auf das Gesamtsystem. Damit einhergehend ist auch ein minimaler Regressionstest nach erfolgter additiver Anpassung.

Aufgrund der Verwendung weniger Modellierungsmuster sind Datenbewirtschaftungsprozesse standardisiert. ETL-Prozesse können konfigurativ geändert oder generiert (in-factory Generator Gen²) werden. Das gezeigte iterative Vorgehen wird durch agile Methoden im Entwicklungsprozess unterstützt: Agilität ist integraler Bestandteil der Data Vault Methode!