Data Vault: mehr Agilität im Data Warehouse Teil 1: Konzept und Definition

0

Data Vault

Mehr Agilität durch Data Vault

Unternehmen müssen ihr Geschäft in immer kürzeren Zyklen transformieren und sich permanent den Marktbedürfnissen anpassen. Data Warehouse-Verantwortliche stehen deshalb unter Druck, für agile Datenstrukturen sorgen zu müssen. Dafür sind bestehende Data Warehouses aber häufig zu schwerfällig, zu komplex oder zu teuer. Eine gute Lösung, um mit bestehenden Architekturen moderne Anforderungen abzudecken, ist Data Vault. In dieser Blogserie, die auf dem gleichnamigen Whitepaper basiert, diskutiere ich das Konzept und seine Einsatzmöglichkeiten für Data Warehouses.

Data Vault ist eine Modellierungstechnik, die es ermöglicht, die Architektur und die Methodik des Data Warehouse (DWH) bedarfsgerecht an sich wandelnde Anforderungen anzupassen. Es liefert eine Antwort auf viele Herausforderungen, mit denen DWH-Architekten und -Verantwortliche derzeit konfrontiert werden. Data Vault erlaubt es, zielgerichtete Entwicklungen voranzutreiben bzw. die Time-to-Market zu verkürzen und die Nachteile klassischer Modellierungsmethoden zu überwinden.

Ihren Ursprung nahm die Data Vault-Modellierung bereits in den 1990er Jahren, Dan Linstedt gilt als ihr „Erfinder“. Erste Veröffentlichungen zu Data Vault gab es zu Beginn der 2000er. Die Vorteile sind eine hohe Flexibilität bei Erweiterungen, eine bitemporale, vollständige Historisierung der Daten und eine starke Parallelisierung von Datenladeprozessen.

Bei Data Vault liegt der Fokus auf den Bedürfnissen von Unternehmen, denn das Konzept ermöglicht flexible, aufwandsarme Anpassungen eines Data Warehouse. Es vereint Aspekte der rationalen Datenbankmodellierung mit der dritten Normalform (3NF) sowie dem Sternschema und wird von unterschiedlichen Autoren als hypernormalisierte oder Ensemble-Modellierung bezeichnet. Wenn sich Architekten mit einer DWH-Modernisierung oder einem agilen DWH beschäftigen, werden sie früher oder später auf Data Vault stoßen.

Data Vault und Data Vault 2.0

Wie jedes Datenmodell, so hat sich auch Data Vault über die Jahre weiterentwickelt. Während man bei Data Vault den Fokus auf das Modell an sich legte, werden bei Data Vault 2.0 der gesamte Entwicklungsprozess sowie die Architektur betrachtet. Version 2.0 besteht aus den Komponenten Methode (Implementierung), Architektur sowie Modell. Der ganzheitliche Ansatz hat den Vorteil, dass sich bei der Entwicklung alle Aspekte von Business Intelligence-Systemen mit zugrunde liegendem Data Warehouse berücksichtigen lassen.

Die Data Vault-Architektur

Die Architektur von Data Vault besteht im Wesentlichen aus drei Schichten (Layer):

  • Staging Layer: Diese Schicht sammelt die Rohdaten aus den Quellsystemen, etwa CRM oder ERP, ein.
  • Data Warehouse Layer: Wird diese Schicht als Data Vault-Modell modelliert, beinhaltet sie:
    Raw Data Vault: speichert die Rohdaten.
    Business Data Vault: beinhaltet harmonisierte und transformierte Daten auf Basis von Geschäftsregeln (optional).
    Metrics Vault: speichert Laufzeitinformationen (optional).
    Operational Vault: speichert die Daten, die direkt aus operativen Systemen in das Data Warehouse fließen (optional.)
  • Information Mart Layer: Diese Schicht modelliert Daten als Star-Schema und/oder anderen Modellierungsverfahren. Sie stellt Informationen für die Analyse und das Berichtswesen zur Verfügung.

Die Hauptkomponenten des Data Vault-Modells

Data Vault unterteilt bei der Modellierung alle zum Objekt gehörenden Informationen in drei verschiedene Kategorien – im Unterschied zu Klassikern der Modellierung der dritten Normalform (3NF). Diese Informationen werden anschließend strikt getrennt voneinander abgelegt. Die funktionalen Bereiche lassen sich in Data Vault in sogenannten Hubs, Links und Satelliten abbilden.

Hubs sind der Schlüssel zum Geschäft

Der Hub stellt das Herzstück des Kerngeschäfts (core business concept) wie Kunde, Verkäufer, Verkauf oder Produkt dar. Die Hub-Tabelle wird um den Business Key (Vertrags- oder Kundennummer) herum gebildet, wenn zum ersten Mal eine neue Instanz dieses Business Keys im Data Warehouse eingeführt wird. Der Hub enthält keine beschreibenden Informationen und keine FKs. Er besteht nur aus dem Business Key, mit einer im Warehouse erzeugten Sequenz von ID- oder Hash-Schlüsseln, Ladedatum/Zeitstempel und der Datensatzquelle.

Links repräsentieren alle Beziehungen

Ein Link stellt Beziehungen zwischen den Business Keys her. Jeder Eintrag in einem Link modelliert n-m Beziehungen einer beliebigen Anzahl von Hubs. Diese allgemeine Form der Modellierung von Beziehungen erlaubt es dem Data Vault, flexibel auf Änderungen in der Business Logik der Quellsysteme, wie zum Beispiel Änderungen in der Kordialität von Beziehungen, zu reagieren. Genau wie der Hub enthält der Link keine beschreibenden Informationen. Er besteht aus den Sequenz-IDs der Hubs, auf die er sich bezieht, sowie einer im Warehouse generierten Sequenz-ID, einem Ladedatum/Zeitstempel und einer Datensatzquelle.

Satelliten liefern den gesamten Kontext

Der Satellit enthält die beschreibenden Informationen (Kontext) für einen Business Key, der in einem Hub gespeichert ist, oder einer Beziehung, die in einem Link gespeichert ist. Satelliten funktionieren „insert only“, das bedeutet, dass die komplette Datenhistorie im Satelliten abgespeichert ist. Es können mehrere Satelliten zur Beschreibung eines einzelnen Business Key (oder einer Beziehung) verwendet werden. Ein Satellit kann jedoch nur einen Schlüssel (Hub oder Link) beschreiben.

Im nächsten Beitrag beschreibe ich die Vorteile des Data Vault-Konzepts. Wenn Sie nicht so lange warten möchten, können Sie sich das Whitepaper „Data Vault“ herunterladen.

Diese Artikel könnten Sie auch interessieren:

Tags: , ,

Stefan Müller - Director Big Data Analytics
Nach mehreren Jahren Tätigkeit im Bereich Governance & Controlling und Sourcing Management ist Stefan Müller bei it-novum gelandet, wo er den Bereich Big Data Analytics aufgebaut hat. Stefans Herz schlägt für die Möglichkeiten, die die BI-Suiten von Pentaho und Jedox bieten, er beschäftigt sich aber auch mit anderen Open Source BI-Lösungen. Seine Begeisterung für Business Open Source im Bereich Datenintelligenz gibt Stefan regelmäßig in Fachartikeln, Statements und Vorträgen weiter.
Webprofile von Stefan: Twitter, LinkedIn, XING