Thought Leadership
Ein ideales Data Warehouse integriert schnell und korrekt neue Daten, reagiert flexibel auch auf große inhaltliche Änderungen, ist auditfähig und kann schnell von monatlicher Beladung auf mehrfach tägliches Laden umsteigen.
Die von Dan Linstedt geschaffene Methode Data Vault verspricht diese Vorteile umzusetzen und nutzt dabei spezielle normalisierte Datenmodelle und eine dazu passende komplette Architektur für ein Data Warehouse.
Der Bereich Business Intelligence ist massiv im Wandel. Data Vault – mit seinen massiven Nutzenversprechen – ist eines der Themen, die diesen Wandel treiben. Dabei dreht sich Data Vault vor allem um das Thema der Datenintegration, die Daten werden zunächst stark normalisiert abgelegt und anschließend für die Auswertung wieder als Star-Schema zusammengeführt.
Trennen von Schlüssel, Attributen und Beziehungen führt zu stabilen Modellen
Im Unterschied zu bisherigen Ansätzen, bei denen die Daten in der 3. Normalform abgelegt wurden, werden die Daten bei Data Vault in Kategorien eingeteilt. Schlüssel bekommen eine eigene Entität, die sogenannten Hubs.
Beziehungen zwischen zwei Geschäftsobjekten sind immer ein Link. Ein Link verknüpft ein oder mehrere Hubs bzw. Links. Somit wird von vorneherein jede Beziehung als m:n-Beziehung in einer eigenen Beziehungsentität abgelegt. Eine spätere Änderung in der Kardinalität der Beziehung führt nicht zu einer Änderung im Datenmodell.
Beschreibende Attribute werden in Satelliten abgelegt. Ein Satellit ist immer einem Hub bzw. einem Link zugeordnet und wird monotemporal historisiert. Ein sehr vereinfachtes Modell eines Einkaufs – ein Auftrag besteht aus einem Kunden, der ein Produkt bei einem Mitarbeiter kauft – sieht in der 3. Normalform wie folgt aus:
In Bild 2 sind die Attribute schon farblich gekennzeichnet und werden nun auf Hubs, Links und Satelliten aufgeteilt:
Alle Entitäten erhalten Standardattribute, wie die Quelle (ReordSrc), den Ladezeitpunkt (LoadDate) und – bei Satelliten – das Ende der Gültigkeit (LoadEndDate). Wenn zu diesem Modell neue Daten hinzugefügt werden, verändern diese das bestehende Modell nicht. Neue Attribute zu bestehenden Hubs kommen in neue Satelliten. Ganz neue Geschäftsobjekte werden per Link angefügt. Somit müssen die bestehenden Prozesse auch nicht erneut getestet werden, sie sind von den Änderungen nicht betroffen.
Standardisierung bringt Automation
Für die Befüllung eines Hubs, Links oder Satelliten braucht es jeweils nur ein Statement. Alle drei werden immer auf dieselbe Art befüllt, nur die Namen von Tabellen und Attributen ändern sich. Damit kann dieser Teil komplett automatisiert werden und so die Entwicklung erheblich beschleunigt werden, neue Daten können sehr schnell dem Data Warehouse hinzugefügt werden. Es wird einfach, von einem System zunächst einmal alle Daten zu übernehmen.
Die Ladezyklen der Quellen sind unabhängig voneinander
Ein Hub besteht im Wesentlichen nur aus der Schlüsselinformation. Damit kann er aus jedem System befüllt werden und es ist möglich, Daten in unterschiedlichen Zyklen zu laden. Es fehlen dann lediglich die Satellitendaten zu diesem Schlüssel. Dies kann durch die Verwendung von Defaults ausgeglichen werden. Was bedeutet das praktisch?
Die Firma Transport AG hat ein System, in dem Kunden online ihre Zufriedenheit ausdrücken und sich dort mit der Kundennummer identifizieren. Das System ist absichtlich schmal, d.h. es werden nur die Kundennummer und drei Merkmale zur Zufriedenheit geliefert. Diese Daten werden mehrfach täglich geladen und die Zufriedenheit der Kunden ausgewertet. Das Kundensystem wird aber nur wöchentlich geladen. Es können also Kunden ihre Zufriedenheit ausdrücken, die noch nicht im Data Warehouse sind. In diesem Fall wird der Link zum Kunden und der Hub des Kunden geladen, die Satellitendaten kommen dann erst mit den wöchentlichen Daten, bis dahin werden Standardwerte für den Kunden in die Auswertung geladen. Die Ladezyklen pro Quelle können also unabhängig voneinander bestimmt und auch jederzeit geändert werden.
Datenintegration nach fachlichen Gesichtspunkten schafft Stabilität
Die Wahl des Schlüsselbegriffs für einen Hub ist von zentraler Bedeutung. In Data Vault wird als Schlüsselbegriff immer der sogenannte Business Key verwendet. Ein Business Key ist ein Schlüssel mit dem sich die Fachabteilung untereinander über ein konkretes Objekt unterhält. Verwendet die Fachabteilung die Kundennummer, die Rechnungsnummer oder die Materialnummer, um sich über ein konkretes Objekt zu verständigen, dann ist dieser Schlüssel stabil. Auch bei Systemänderungen wird dieser Schlüssel erhalten bleiben, denn er ist zentraler Bestandteil der Arbeitsweise im Fachbereich. Sind die Daten über mehrere Systeme verteilt, findet sich dieser Schlüssel meist in allen beteiligten Systemen wieder.
Star-Schema kann per Views aus dem Data Vault virtualisiert werden
Die Daten direkt auf einem Data Vault Modell auszuwerten ist auf Grund vieler ‚joins‘ nicht empfehlenswert. Besser ist die Darstellung in einem Star-Schema. Die Transformation von Hub, Link und Satelliten in ein solches Star-Schema, die Darstellung in Fakten und Dimensionen ist nur eine einfache Selektion (das Thema Daten konsolidieren wird weiter unten aufgegriffen).
Hubs und Satelliten sind wie Dimensionen: Informationen zu einem Schlüsselbegriff. Während Links mehrere Schlüssel verknüpfen und dort die Daten zur Transkation stehen und somit alle Informationen für eine Faktentabelle beinhalten. Das lässt sich in einem einfachen select ausdrücken und kann über Views virtualisiert werden.
Schnelle Bereitstellung von Daten in der gelieferten Qualität verändert die Fachbereichskommunikation
Die bisherigen Schritte erlauben eine schnelle Bereitstellung der Daten. Die Data Vault Schicht ist automatisiert und über Views können die Daten schnell in gewohnter Form mit den üblichen Werkzeugen dem Fachbereich präsentiert werden.
Diese Daten sind jedoch noch nicht konsolidiert. Alle Probleme in der Datenqualität werden offensichtlich. Das verändert die Kommunikation mit dem Fachbereich erheblich. Die Daten werden schnell und in der gelieferten Qualität dem Fachbereich dargestellt. Jetzt kann über notwendige Konsolidierungen anhand von konkreten Fällen in den Daten gesprochen werden.
Die Entscheidung, ob diese Änderung in den operativen Quellsystemen oder im Data Warehouse passiert, wird für den Fachbereich leichter, da sie die Zusammenhänge besser erkennen können. Auch die alte Frage ‚Was wollt ihr denn?‘ und die Gegenfrage ‚Was habt ihr denn?‘ kann damit umgangen werden; die Daten werden zunächst einfach bereitgestellt. Der Aufwand hierfür bleibt durch die Automatisierung erst einmal gering.
Konsolidieren der Daten in einer eigenen Schicht reduziert den Wartungsaufwand
Die Konsolidierung der Daten erfolgt in einer eigenen Schicht, oberhalb des Data Vault und vor dem Star Schema des Data Mart. Diese Schicht wird Business Vault genannt. Die Ergebnisse der Konsolidierung werden im Business Vault ebenfalls in Hub, Link und Satellit gespeichert. Damit die Daten nicht noch einmal kopiert werden müssen, wird dies im Schema der Data Vault Schicht abgelegt. Denn nicht immer müssen Daten konsolidiert werden und so können konsolidierte und unkonsolidierte Daten ohne Probleme gemeinsam ausgewertet werden. Die Data Mart Schicht wird aufgeteilt in einen Raw Mart für die unkonsolidierten Daten und einen Information Mart für die korrekten und verwendbaren Daten.
Die Regeln zur Konsolidierung sind ‚soft rules‘, d.h. diese Regeln ändern sich über die Zeit, weil sich die Voraussetzungen ändern oder neue Erkenntnisse neue Anforderungen schaffen. In dem die Konsolidierung an dieser Stelle vorgenommen wird, müssen nur die konsolidierten Daten und der Data Mart neu geladen werden. Die Ladeschicht und der Data Vault sind nicht betroffen, dass reduziert Laufzeiten und potentielle Fehlerquellen.
Trennen der Konsolidierung schafft den ‚single point of facts‘
Zudem erlaubt diese Architektur, verschiedenen Abteilungen unterschiedliche Konsolidierungen bereitzustellen. Das Data Warehouse wird vom ‚single point of truth‘ zum ‚single point of facts‘. Im Konfliktfall kann die unterschiedliche Berechnung dargestellt und auf die gleichen Daten zurückgeführt werden. Idealerweise kann so der Konflikt im Fachbereich gehalten werden. Eine gemeinsame Sicht kann so nach und nach für die relevanten Bereiche entstehen, ohne dass jemand vorher die relevanten Bereiche festlegen muss.
Dies reduziert den Aufwand für Abstimmungen, kann im Zeitablauf jedoch zu mehr Änderungen führen. Diese Änderungen betreffen jeweils nur die Konsolidierung der Daten und/oder den Abgriff der Daten im Data Mart, der Aufwand bleibt lokal begrenzt und steht in direkter Relation zu den Anforderungen.
Separation of concerns in der Architektur schafft Eindeutigkeit und Orientierung
Aus den bisher geschilderten Schritten ergibt sich eine Architektur, in der jede Schicht eine klare Aufgabe hat. Das schafft Orientierung: im Änderungsfall sind die Orte für die einzelnen Transformationsschritte klar. Diese Eindeutigkeit erspart langes Suchen in der bisherigen Implementierung und reduziert so den Wartungsaufwand.
In der Staging Area werden die ‚Hard Rules‘ zu Anwendung gebracht. Das sind typischerweise Konsolidierungen, die sich nicht oder nur sehr selten ändern, wie die Transformation von Datentypen. Zudem wird neben der Deltabildung auch die Vorbereitung für die Lademuster des Data Vault getroffen. Meist handelt es sich hierbei um das Anfügen der fachlichen Schlüssel zu den technischen Schlüsseln des operativen Quellsystems.
Bis auf den Business Vault können alle anderen Schichten automatisiert oder über Views virtualisiert werden. Damit werden die Standardaufgaben schnell und einfach. Der Aufwand konzentriert sich auf die komplexen Transformationen und ist somit dem Management und den Stakeholdern einfacher darstellbar.
Immer komplettes Laden der Daten sorgt für Nachverfolgbarkeit
Die Data Vault Schicht ist eine exakte Abbildung der Ladedaten und die Manipulation der Daten erfolgt nur im Business Vault. Auf dieser Basis kann mit wenigen technischen Metadaten sichergestellt werden, dass für jeden Satz hinterlegt ist, wie dieser Satz im Data Warehouse verwendet wurde, ob er bis zur Auswertung gelangt ist und wenn nicht bis zu welcher Stelle dieser Satz geladen wurde.
Sätze verschwinden nicht mehr im Ladeprozess bei Konsolidierungen, es werden immer alle Sätze vollständig verarbeitet. Neben dem Vertrauen in die eigenen Daten schafft dies auch die Möglichkeit zum Audit über die Ladeprozesse. Eine Prüfung auf Korrektheit der Ladeprozesse wird sehr einfach.
Alter Wein in neuen Schläuchen?
Nicht alles aus dem Data Vault ist neu. Viele Teile sind bekannt und werden schon seit Jahren verwendet. Wirklich neu und sehr beeindruckend ist die konsequente Umsetzung, wie jedes Detail bis zu Ende durchdacht ist und alle Teile passgenau ineinandergreifen.
Weiterführende Informationen:
- Buch: Daniel Linstedt, Michael Olschinke, „Building a scalable data warehouse with data vault 2.0“
- Buch: Daniel Linstedt, „Supercharge your Data Warehouse“
- www.datavaultusergroup.de
Michael Müller, Dipl.-Inf. (FH), ist Geschäftsfeldleiter BI bei der MID GmbH und beschäftigt sich seit 2000 mit Business Intelligence, Data Warehousing und Data Vault. Seine Schwerpunktthemen sind Architekturen, Modellierung und modellgetriebene Automation für Business Intelligence.
