Datenmodellierung für das agile Data Warehouse
Die Anforderungen an ein modernes Data Warehouse sind schnell aufgezählt: Daten sollen schnell und korrekt integrierbar sein und auch auf große inhaltliche Änderungen soll flexibel reagiert werden können. Die von Dan Linstedt geschaffene Methode Data Vault verspricht diese Vorteile umzusetzen.
In der Vergangenheit hat die Diskussion vorwiegend zwischen Befürwortern der dimensionalen Modellierung und denen der normalisierten Modellierung stattgefunden. Aber in den letzten Jahren scheint die von Dan Linstedt geschaffene Methode des Data Vault eher die gewünschten Anforderungen an ein modernes DWH erfüllen zu können.
Ein Blick zurück
Bei vielen großen Data-Warehouse-Implementierungen wird oft die Modellierung anhand der dritten Normalform präferiert. Übrigens entspricht das den Vorstellungen von Bill Inmon, einer der „Urväter“ des Data-Warehouse-Konzeptes. Die Normalform hatte das Ziel, ein umfassendes, unternehmensweites Datenmodell für das Core Data Warehouse aufzubauen. Neben dem zeitaufwändigen Aufbau ist insbesondere die Weiterentwicklung des Datenmodells mit hohem Aufwand und langen Projektlaufzeiten verbunden.
Stattdessen schlägt Ralph Kimball im Gegensatz zu Inmon bereits seit mehr als 20 Jahren den Aufbau eines dimensionalen Datenmodells für das Core Data Warehouse vor. Entsprechend dazu ist es mit einer Star- oder Snowflake-Modellierung Daten in Dimensions- und Faktentabellen organisiert. Relativ nahe am Verständnis der fachlich Anwendenden gelingt sowohl der erstmalige Aufbau als auch die iterative Weiterentwicklung relativ schnell.
Wenngleich als wesentlicher Kritikpunkt an der dimensionalen Modellierung für das Core Data Warehouse die mangelnde Robustheit gegenüber Änderungen an den Quellsystemen gilt. Ebenso kritisiert wird die Geschäftslogik, die in der Regel umfangreiche und aufwendige Modifikationen im Datenmodell mit sich bringt, weshalb heute die dimensionale Modellierung daher vorwiegend auf der Ebene der Data Marts genutzt wird.
Das Konzept des Data Vault verspricht die Nachteile der klassischen Modellierungsmethoden zu überwinden. Dies liegt an der Grundidee des Ansatzes, Informationen im Data Warehouse so aufzuteilen, dass eine einfache Integration und Historisierung der Daten möglich ist. So ist das Modell zudem ohne Migration der bestehenden Tabellen erweiterbar.
Elemente eines Data Vault
Im Gegensatz zu den bisherigen Ansätzen, die die Daten in der 3. Normalform ablegen, werden bei der Data-Vault-Modellierung alle zu einem Geschäftskonzept, zum Beispiel Kunde oder Produkt, gehörenden Informationen in drei Kategorien eingeteilt und in drei Typen von Datenbanktabellen abgelegt.
Hubs
In diesem Sinne gehören zur Kategorie Hub alle Informationen, welche ein Geschäftskonzept eindeutig beschreiben, das heißt ihm seine Identität geben (zum Beispiel Kundennummern bei Kunden). Somit repräsentieren Hubs die Kernobjekte der jeweiligen Geschäftslogik. Sie dienen der Identifikation der fachlichen Entitäten und beinhalten zusätzlich zu einem fachlichen Schlüssel einen künstlichen Primärschlüssel (Surrogatschlüssel). Darüber hinaus enthalten sie technische Attribute wie Informationen über das Quellsystem oder das Ladedatum. Demnach lässt sich ein Hub als eine Liste von eindeutigen Geschäftsschlüsseln beschreiben, welche als Integrationspunkt für Daten aus verschiedenen Quellen dienen.
Links
In die Kategorie Link sind alle Arten von Beziehungen zwischen Geschäftskonzepten, zum Beispiel Zuordnung eines Produktes zu einem Hersteller, abgelegt. Das heißt, Links werden zur Verknüpfung zwischen (zwei oder mehreren) Hubs verwendet und nutzen hierfür die Surrogatschlüssel. Beziehungen in einem Data Vault werden immer als n:n-Beziehungen modelliert und in einer eigenen Beziehungsentität abgelegt. Schließlich führt eine zukünftige Änderung in der Kardinalität der Relation daher nicht zu einer Änderung des Datenmodells.
Satelliten
Die Kategorie Satellite beinhaltet alle Attribute, die ein Geschäftskonzept oder eine Beziehung beschreiben (zum Beispiel Name oder Alter eines Kunden). Ein Hub oder Link kann mehrere Satelliten haben. Das heißt auch bei den Satelliten sind zusätzlich die Angaben zur Datenquelle und Ladezeit festgehalten. Das Ladedatum ist zusammen mit der Hub-Referenz der Primärschlüssel der Tabelle. Infolgedessen ist eine komplette Historisierung der Datensätze möglich.
Trennung zwischen Hubs, Links und Satellites
Die Verknüpfung der einzelnen Entitäten basiert dabei immer auf einer Modellierung über Links, die auf Hubs verweisen. Zwischen den einzelnen Hubs ist innerhalb von Data Vault eine direkte Verbindung nicht erlaubt. Ebenso untersagt sind Fremdschlüssel in einem Satellite, welche auf einem fremden Hub zeigen.
Die strikte Trennung zwischen Hubs, Links und Satellites und die Einhaltung der vorgegebenen Regeln ist wesentlich für die flexible Integration von Daten aus mehreren Quellsystem und die Erweiterbarkeit des Datenmodells.
Werden zu einem bestehenden Datenmodell neue Daten hinzugefügt, verändern diese das bestehende im Rahmen von Data Vault Modell nicht. Werden neue Attribute zu einem existierenden Hub hinzugefügt, so werden diese in neue Satelliten abgelegt. Komplett neue Geschäftsobjekte werden per Link angefügt. Dies hat den Vorteil, dass der Test bestehender Prozesse entfällt, da diese von den Änderungen nicht betroffen sind.
Die Anforderungen an ein modernes Data Warehouse sind rasch aufgezählt: Daten sollen schnell und korrekt integrierbar sein und auch auf große inhaltliche Änderungen soll flexibel reagiert werden können. Die von Dan Linstedt geschaffene Methode Data Vault verspricht diese Vorteile umzusetzen.
In der Vergangenheit hat die Diskussion vorwiegend zwischen Befürwortern der dimensionalen Modellierung und denen der normalisierten Modellierung stattgefunden. Aber in den letzten Jahren scheint die von Dan Linstedt geschaffene Methode des Data Vault eher die gewünschten Anforderungen an ein modernes DWH erfüllen zu können.
ETL-Prozesse für Data Vault
Die strikte Trennung zwischen Hubs, Links und Satellites ist wesentlich für die Integration von Daten aus mehreren Quellen und die Erweiterbarkeit des Datenmodells.
Denn der Ladeprozess der Daten basiert auf einheitlichen und einfachen Mustern. Die entsprechenden ETL-Prozesse bestehen aus Key Lookups, INSERT-Statements auf Hubs, Links und Satelliten, sowie aus spezifischen Deltaermittlungen. Wobei die verschiedenen Tabellen eines Typs dabei unabhängig voneinander geladen werden, sodass eine parallelisierte Ausführung möglich ist.
Hierzu besteht der gesamte Beladungsprozess aus drei Schritten:
- Sämtliche Hubs werden parallel geladen
- Alle Links und Hub Satellites werden parallel geladen
- Alle Link Stellites werden parallel geladen
Hingegen ist die Extraktion von Daten in dimensionale Data Marts komplexer als das Beladen des Data Vaults. Denn um eine Dimensions- oder Faktentabelle zu beladen, müssen zum Teil mehrere Hubs, Links und Satellites zusammengeführt werden. Weiterhin entsteht eine zusätzliche Herausforderung in diesem Kontext vor allem beim Laden von Slowly Changing Dimension des Typ 2. Für Hubs mit mehreren Satelliten bedeutet dies, dass zuerst alle Gültigkeitsintervalle ermitteln werden müssen, welche sich durch die Verknüpfung der Gültigkeiten der einzelnen Satelliten ergeben.
Die Speicherung der Gültigkeitsintervalle erfolgt in einer weiteren Satellite-Tabelle. Hierin werden die unterschiedlichen Ladezeitpunkte mit der zugehörigen Gültigkeit verknüpft. Ist dieser Schritt umgesetzt, lassen sich die jeweils gültigen Versionen der einzelnen Satellites ermittelten und die Dimensionstabellen korrekt befüllen.
Die ETL-Prozesse für die einzelnen Strukturelemente (Hubs, Links und Satellites) sind ansonsten nach einem gleichen Muster aufgebaut. Demzufolge entsteht eine wiederkehrende Logik für die Ladeprozesse des Data Vaults. Ebenso lassen sie sich relativ einfach über geeignete Generatoren implementieren. Anschließend erleichtert dies spürbar den Anpassungsprozess bei Strukturänderungen in großen Data Warehouses. Aufgrund der einheitlichen Regeln für die Modellierung und die Ladestrecken, lässt sich in der Praxis beobachten, dass sich Tabellen und ETL-Prozesse vergleichsweise einfach generieren lassen.
Vorteile von Data Vault in der Praxis
Der effiziente Umgang mit der zunehmenden Datenflut wird für Unternehmen immer mehr zum zentralen Erfolgsfaktor. Innerhalb kürzester Zeit ändern sich die Anforderungen der verschiedenen Fachabteilungen und an die Datenbasis. Somit müssen große Datenmengen aus unterschiedlichsten, teilweise unstrukturierten Datenquellen erfasst und zu entscheidungsrelevanten Informationen für Fachabteilungen und Geschäftsführung aufbereitet werden.
Daher wird es für IT-Abteilungen immer schwieriger, schnell und flexibel auf dieses Datenwachstum zu reagieren und neue Datenquellen in bestehende Data Warehouses zu integrieren. Datenmodelle müssen sich den Erfordernissen von Big Data anpassen. Sobald zum Beispiel Daten aus Social Media oder Informationen von Kundenkarten oder Smart-Metering-Systemen integriert werden, ist nachvollziehbar, dass dies nur mit agilen Modellierungsmethoden möglich sein kann.
Folglich zielt das Konzept des Data Vault darauf ab, einen Ansatz bereitzustellen, der in der Lage ist diesen Entwicklungen zu begegnen und Komplexität zu reduzieren. Daher ist die Methode besonders für Data Warehouses geeignet, bei denen häufig Strukturerweiterungen vorgenommen werden müssen und für Projekte, bei denen von Anfang an ein agiles Vorgehen gewählt wird. Ziel der Modellierung mit Data Vault sind effizient erweiterbare Data Warehouses.
Zuletzt sind die Erfahrungen aus unseren Projekten im Bereich Data Vault größtenteils als positiv zu beschreiben. Insbsonders, da mit dem Ansatz der Prozess der Datenmodellierung verbessert werden kann. Somit können für Unternehmen die folgenden Vorteile entstehen:
- Reduktion von Komplexität
- Automatisierung von Prozessen
- Schneller Ladeprozesse
- Historisierung vereinfacht Rückverfolgbarkeit
- Skalierbarkeit ermöglicht flexibles Wachstum
Folgerichtig empfiehlt sich Data Vault vor allem bei drei Anwendungsfällen: Für Unternehmen, die
- innerhalb von kurzer Zeit sehr große Datenvolumen laden müssen, oder
- eine agile Entwicklung von anstreben, oder
- im Rahmen einer bereits existierenden Silo-Architektur ein vorgelagertes Core Data Warehouse implementieren möchten.
