Data-Vault-Modellierung für skalierbare und auditierbare Data Warehouses

Positionierung

Data Vault ist eine Modellierungsmethode für Data Warehouses, die besonders dann ihre Stärken ausspielt, wenn viele Quellsysteme angebunden werden, sich Anforderungen häufig ändern und lückenlose Nachvollziehbarkeit gefordert ist. Ich setze Data Vault seit vielen Jahren in großen Data-Warehouse-Projekten ein – im öffentlichen Sektor, in der Versicherungswirtschaft und im Handel – und kombiniere die Methode gezielt mit klassischen dimensionalen Modellen für die Auswertung.

Mein Ansatz ist pragmatisch. Data Vault ist kein Selbstzweck und nicht für jedes Projekt die richtige Wahl. Wo die Methode passt, entfaltet sie jedoch eine enorme Wirkung: Sie macht ein Data Warehouse erweiterbar, ohne bestehende Strukturen aufzubrechen, sie erlaubt eine hochgradig parallele Beladung und sie hält fest, woher jeder einzelne Datensatz stammt und wann er geladen wurde. Genau diese Eigenschaften sind in regulierten Umgebungen oft entscheidend.

Über die Jahre habe ich Data Vault in sehr unterschiedlichen Ausprägungen kennengelernt – vom klassischen On-Premises-Data-Warehouse auf SQL Server bis hin zu cloudbasierten Plattformen mit Delta Lake. Diese Bandbreite hat mir gezeigt, dass die Methode nicht an eine bestimmte Technologie gebunden ist, sondern ein Denkmuster darstellt: Trenne Schlüssel, Beziehung und Beschreibung, halte jede Lieferung revisionssicher fest und leite die Auswertung daraus ab. Dieses Denkmuster bleibt stabil, während sich die Werkzeuge darunter weiterentwickeln – ein wesentlicher Grund für die Langlebigkeit gut gebauter Data-Vault-Lösungen.

Die Methode geht auf Dan Linstedt zurück und hat sich in den vergangenen zwei Jahrzehnten zu einem etablierten Standard für unternehmensweite Data Warehouses entwickelt. Mit Data Vault 2.0 kamen Hash-Keys, klare Konventionen für die Beladung und eine Brücke zu agilen Vorgehensweisen hinzu. Genau diese moderne Ausprägung setze ich ein: Hash-Keys für eine parallele Beladung, eine konsequente Trennung von Raw und Business Vault sowie eine metadatengetriebene Generierung der Strukturen und Ladeprozesse. So bleibt das Data Warehouse auch dann beherrschbar, wenn die Zahl der Quellen und Tabellen über die Jahre stark wächst.

In meiner Beratung lege ich Wert darauf, Data Vault nicht als Ideologie zu verkaufen, sondern als Werkzeug mit klaren Stärken und Schwächen. Ich erkläre, welche Probleme die Methode löst, welchen Preis sie hat und wo ihre Grenzen liegen. Diese Ehrlichkeit ist mir wichtig, weil ein falsch eingesetztes Data Vault einem Projekt ebenso schaden kann wie ein überdehntes Star-Schema. Die Kunst liegt darin, die Methode dort einzusetzen, wo sie ihre Stärken wirklich ausspielt.

Warum Data Vault?

Klassische dimensionale Modelle nach Kimball oder normalisierte Modelle nach Inmon sind bewährt, stoßen aber an Grenzen, wenn ein Data Warehouse über Jahre wächst, ständig neue Quellen aufnimmt und gleichzeitig revisionssicher bleiben muss. Jede neue Quelle, jede neue Beziehung und jedes neue Attribut bedeutet in einem reinen Star-Schema oft umfangreiche Anpassungen an bestehenden Tabellen – mit entsprechendem Test- und Regressionsaufwand.

Data Vault begegnet diesem Problem mit einer strikten Trennung von Struktur und Inhalt. Neue Quellen werden über zusätzliche Satellites angebunden, neue Beziehungen über zusätzliche Links – ohne dass bestehende Strukturen verändert werden müssen. Das Modell wächst additiv. Diese Eigenschaft, in der Data-Vault-Welt als „Auditability and Adaptability“ bekannt, ist der Hauptgrund, warum ich die Methode in langlebigen Enterprise-Data-Warehouses einsetze.

• Erweiterbarkeit: neue Quellen und Attribute additiv anbinden, ohne Bestehendes zu brechen
• Auditierbarkeit: jeder Satz trägt Herkunft (Record Source) und Ladezeitpunkt
• Parallelität: Hubs, Links und Satellites lassen sich unabhängig und gleichzeitig laden
• Historisierung: Änderungen werden lückenlos und revisionssicher festgehalten
• Trennung der Verantwortung: Rohdaten im Raw Vault, Geschäftslogik im Business Vault

Wichtig ist mir die ehrliche Einordnung: Data Vault erzeugt mehr Tabellen und mehr Joins als ein schlankes Star-Schema. Für ein kleines, stabiles Reporting mit wenigen Quellen wäre das Overkill. Seine Stärke zeigt die Methode bei Komplexität, Wandel und Compliance-Anforderungen – und genau dort empfehle und implementiere ich sie.

Ein weiterer, oft entscheidender Vorteil ist die Fähigkeit, fehlerhafte oder verspätete Lieferungen sauber abzubilden. Weil der Raw Vault jede Lieferung mit Ladezeitpunkt und Herkunft festhält, lässt sich auch im Nachhinein nachvollziehen, welche Daten wann verfügbar waren. Korrekturen aus den Quellen werden als neue Versionen angefügt, nicht als Überschreibungen – die ursprüngliche Lieferung bleibt sichtbar. In Audits und bei regulatorischen Nachweispflichten ist genau diese Lückenlosigkeit Gold wert, weil sich jede Zahl bis zur Originallieferung zurückverfolgen lässt.

Auch der häufig genannte Gegensatz zwischen Inmon und Kimball löst sich mit Data Vault auf elegante Weise. Data Vault ist weder das eine noch das andere, sondern eine eigene Integrationsschicht, die beide Welten bedienen kann: Sie integriert und historisiert wie ein Inmon-Core und liefert die Grundlage für beliebig viele Kimball-Marts. Diese Rolle als neutrale, langlebige Integrationsschicht ist der eigentliche Platz von Data Vault in einer modernen Datenarchitektur.

Die Bausteine: Hub, Link, Satellite

Data Vault kommt mit drei zentralen Bausteinen aus. Ihre Klarheit ist die eigentliche Stärke der Methode: Jeder Tabellentyp hat genau eine Aufgabe, und aus der Kombination dieser drei Typen lässt sich jedes noch so komplexe Modell aufbauen.

Das Data-Vault-Kernmodell: Hubs halten Geschäftsschlüssel, Links verbinden Hubs zu Beziehungen, Satellites tragen die beschreibenden, historisierten Attribute.

Diese strikte Rollenverteilung ist der eigentliche Trick der Methode. In klassischen Modellen vermischen Tabellen oft Schlüssel, Beziehungen und Attribute – was sie schwer veränderbar macht. Data Vault zerlegt diese drei Aspekte konsequent in eigene Tabellentypen. Dadurch betrifft eine Änderung an den Attributen einer Quelle nur deren Satellite, eine neue Beziehung nur einen neuen Link und ein neues Geschäftsobjekt nur einen neuen Hub. Bestehende Strukturen bleiben unberührt. Genau diese Lokalität von Änderungen macht das Modell so robust gegenüber dem unvermeidlichen Wandel der Quellsysteme.

Hub – der Geschäftsschlüssel

Ein Hub repräsentiert ein zentrales Geschäftsobjekt – etwa Kunde, Produkt, Vertrag oder Konto. Er enthält ausschließlich den fachlichen Geschäftsschlüssel (Business Key), einen daraus abgeleiteten Hash-Key als Surrogat, den Ladezeitpunkt und die Datenquelle. Bewusst enthält ein Hub keine beschreibenden Attribute: Er ist die stabile, dauerhafte Liste aller jemals gesehenen Geschäftsschlüssel eines Objekttyps.

Link – die Beziehung

Ein Link modelliert eine Beziehung zwischen zwei oder mehr Hubs – etwa „Kunde hat Vertrag“ oder „Bestellung enthält Produkt“. Auch der Link enthält keine beschreibenden Attribute, sondern nur die Hash-Keys der beteiligten Hubs, einen eigenen Link-Hash-Key, Ladezeitpunkt und Quelle. Beziehungen werden in Data Vault grundsätzlich als many-to-many modelliert – das macht das Modell robust gegenüber späteren Änderungen der Kardinalität.

Satellite – die beschreibenden Attribute

Der Satellite trägt die eigentlichen beschreibenden und veränderlichen Attribute eines Hubs oder Links – etwa Name, Adresse, Status oder Betrag. Er ist der Ort der Historisierung: Ändert sich ein Attribut, wird ein neuer Satz mit neuem Ladezeitpunkt angefügt, der alte bleibt erhalten. Über einen Hash-Diff lässt sich effizient erkennen, ob sich überhaupt etwas geändert hat. Ein Hub kann mehrere Satellites haben – etwa getrennt nach Quellsystem oder nach Änderungsfrequenz.

Das Aufteilen der Attribute auf mehrere Satellites ist eine bewusste Entwurfsentscheidung. Häufig trenne ich nach Quellsystem, damit jede Quelle ihren eigenen, unabhängig beladbaren Satellite bekommt und sich Änderungen einer Quelle nicht auf die anderen auswirken. Eine andere sinnvolle Trennung verläuft entlang der Änderungsfrequenz: Selten veränderliche Stammdaten gehören in einen anderen Satellite als häufig wechselnde Statusinformationen. So bleibt die Historie schlank, weil nicht bei jeder kleinen Änderung der gesamte Attributsatz dupliziert wird.

Neben diesen drei Kernbausteinen kennt Data Vault einige nützliche Sonderformen. Effectivity Satellites halten fest, in welchem Zeitraum eine Beziehung gültig war – etwa, wann ein Kunde welchem Vertrag zugeordnet war. Multi-Active Satellites bilden mehrwertige Attribute ab, etwa mehrere Telefonnummern zu einem Kunden. Und Reference-Tabellen halten Code-Listen und Stammdaten, die nicht historisiert werden müssen. Diese Erweiterungen setze ich gezielt ein, ohne das Modell unnötig zu überladen.

Hash-Keys und ihre Vorteile

Ein zentrales Konzept moderner Data Vaults sind Hash-Keys. Statt fortlaufender Surrogatschlüssel, die zentral vergeben werden müssen, wird aus dem Geschäftsschlüssel ein deterministischer Hash-Wert berechnet – etwa mit SHA-256 über HASHBYTES im SQL Server. Dieser Ansatz hat mehrere entscheidende Vorteile für die Beladung.

• Hash-Keys lassen sich berechnen, ohne vorher in eine Lookup-Tabelle zu schauen
• Hubs, Links und Satellites können dadurch vollständig parallel und unabhängig geladen werden
• Der gleiche Geschäftsschlüssel ergibt systemübergreifend immer denselben Hash-Key
• Hash-Diffs über beschreibende Attribute erkennen Änderungen effizient

Der Preis dafür ist ein höherer Speicherbedarf und etwas mehr Rechenaufwand beim Hashen. In der Praxis überwiegen jedoch die Vorteile bei der Beladung deutlich, gerade bei großen, parallel zu verarbeitenden Datenmengen. Wichtig ist eine saubere Normalisierung der Schlüssel vor dem Hashen – also einheitliche Groß-/Kleinschreibung, Trimmen von Leerzeichen und ein definierter Trenner zwischen zusammengesetzten Schlüsseln –, damit derselbe fachliche Schlüssel zuverlässig denselben Hash ergibt.

Bei der Wahl des Hash-Verfahrens wäge ich zwischen Kollisionssicherheit und Speicherbedarf ab. SHA2_256 liefert eine praktisch kollisionsfreie 32-Byte-Darstellung und ist mein Standard für sicherheitskritische Umgebungen. Wo Speicher und Performance besonders kritisch sind und das Kollisionsrisiko fachlich vertretbar bleibt, kommt gelegentlich ein kürzeres Verfahren in Betracht. Diese Entscheidung treffe ich nicht pauschal, sondern abhängig vom Datenvolumen, von den Compliance-Anforderungen und von der erwarteten Lebensdauer des Data Warehouse.

Datenmodell und DDL

Wie sieht ein Data-Vault-Modell konkret aus? Das folgende Beispiel zeigt die DDL für einen Hub, einen Satellite und einen Link am Beispiel von Kunde, Vertrag und ihrer Beziehung. Die Struktur ist bewusst einheitlich gehalten – diese Gleichförmigkeit ist die Grundlage für die spätere Generierung und Automatisierung.

Auffällig sind die wiederkehrenden Metadatenspalten. Jede Tabelle führt einen Ladezeitpunkt und eine Record Source mit, jeder Satellite zusätzlich einen Hash-Diff und ein optionales LoadEndDate. Diese Spalten sind kein Beiwerk, sondern das Rückgrat der Auditierbarkeit: Sie beantworten zu jedem Datensatz die Fragen, woher er stammt, wann er geladen wurde und ob er der aktuelle Stand ist. Weil diese Spalten in jeder Tabelle gleich heißen und gleich funktionieren, lassen sich generische Ladeprozeduren schreiben, die jeden Hub, jeden Link und jeden Satellite nach demselben Schema verarbeiten.

-- HUB: haelt ausschliesslich den Geschaeftsschluessel + Metadaten
CREATE TABLE rv.Hub_Customer (
    Customer_HK     binary(32)    NOT NULL,   -- Hash-Key (SHA2_256)
    Customer_BK     varchar(50)   NOT NULL,   -- Business Key
    LoadDate        datetime2(3)  NOT NULL,   -- Ladezeitpunkt
    RecordSource    varchar(100)  NOT NULL,   -- Herkunft (Audit)
    CONSTRAINT PK_Hub_Customer PRIMARY KEY (Customer_HK)
);

-- SATELLITE: beschreibende, historisierte Attribute zum Hub
CREATE TABLE rv.Sat_Customer (
    Customer_HK     binary(32)    NOT NULL,
    LoadDate        datetime2(3)  NOT NULL,
    LoadEndDate     datetime2(3)  NULL,       -- offen = aktueller Stand
    HashDiff        binary(32)    NOT NULL,   -- Aenderungserkennung
    RecordSource    varchar(100)  NOT NULL,
    CustomerName    varchar(200)  NULL,
    City            varchar(100)  NULL,
    Segment         varchar(50)   NULL,
    CONSTRAINT PK_Sat_Customer PRIMARY KEY (Customer_HK, LoadDate)
);

-- LINK: Beziehung zwischen zwei Hubs (Kunde <-> Vertrag)
CREATE TABLE rv.Lnk_Customer_Contract (
    Cust_Contract_HK binary(32)   NOT NULL,   -- Hash ueber beide BKs
    Customer_HK      binary(32)   NOT NULL,
    Contract_HK      binary(32)   NOT NULL,
    LoadDate         datetime2(3) NOT NULL,
    RecordSource     varchar(100) NOT NULL,
    CONSTRAINT PK_Lnk_Customer_Contract PRIMARY KEY (Cust_Contract_HK)
);

Auffällig ist die strikte Einheitlichkeit: Jeder Hub, jeder Satellite und jeder Link folgt demselben Bauplan. Genau diese Gleichförmigkeit erlaubt es, das Modell und die Ladeprozeduren später aus Metadaten zu generieren.

Die Berechnung der Hash-Keys und des Hash-Diffs geschieht beim Laden. Das folgende Beispiel zeigt, wie aus dem normalisierten Geschäftsschlüssel und den beschreibenden Attributen die Hash-Werte gebildet werden.

-- Hash-Key aus normalisiertem Business Key, Hash-Diff aus den Attributen.
-- UPPER + TRIM sorgen fuer eine kanonische, stabile Darstellung.

SELECT
    HASHBYTES('SHA2_256',
              UPPER(LTRIM(RTRIM(s.CustomerId)))                  ) AS Customer_HK,
    HASHBYTES('SHA2_256',
              CONCAT_WS('|',
                        UPPER(LTRIM(RTRIM(ISNULL(s.CustomerName,'')))),
                        UPPER(LTRIM(RTRIM(ISNULL(s.City,'')))),
                        UPPER(LTRIM(RTRIM(ISNULL(s.Segment,'')))) )) AS HashDiff,
    s.CustomerId  AS Customer_BK,
    s.CustomerName, s.City, s.Segment,
    SYSUTCDATETIME() AS LoadDate,
    'CRM'            AS RecordSource
FROM stg.Customer AS s;

CONCAT_WS mit einem definierten Trenner verhindert, dass sich Attributgrenzen verschieben. ISNULL stellt sicher, dass NULL-Werte den Hash nicht unkontrolliert verändern.

Parallele Beladung des Raw Vault

Der eigentliche Vorteil von Data Vault zeigt sich bei der Beladung. Weil Hash-Keys ohne Lookups berechnet werden, hängen Hubs, Links und Satellites beim Laden nicht voneinander ab. Sie können vollständig parallel geladen werden – ein enormer Vorteil bei großen Datenmengen und engen Ladefenstern.

Parallele Beladung: Hubs, Links und Satellites werden unabhängig voneinander geladen. Jeder Ladeschritt ist idempotent und schreibt nur neue oder geänderte Sätze.

Die Ladelogik je Baustein ist einfach und immer gleich. Ein Hub bekommt nur Schlüssel, die er noch nicht kennt. Ein Link bekommt nur Beziehungen, die er noch nicht kennt. Ein Satellite bekommt einen neuen Satz nur dann, wenn sich der Hash-Diff gegenüber dem letzten bekannten Stand geändert hat. Alle drei Schritte sind idempotent: Ein erneuter Lauf mit denselben Daten ändert nichts.

Diese Einfachheit hat einen tieferen Grund. Weil keine Reihenfolge zwischen den Bausteinen eingehalten werden muss, entfällt die komplizierte Abhängigkeitssteuerung, die klassische Ladeprozesse so fehleranfällig macht. In einem Star-Schema muss eine Dimension geladen sein, bevor die zugehörige Faktentabelle ihre Surrogatschlüssel nachschlagen kann. In Data Vault gibt es diese Lookup-Abhängigkeit nicht: Jeder Baustein berechnet seine Hash-Keys selbst. Das vereinfacht die Orchestrierung erheblich und erlaubt es, die Last über viele parallele Ströme zu verteilen, ohne in Reihenfolgekonflikte zu geraten.

-- HUB-Beladung: nur neue Geschaeftsschluessel einfuegen.
INSERT INTO rv.Hub_Customer (Customer_HK, Customer_BK, LoadDate, RecordSource)
SELECT DISTINCT s.Customer_HK, s.Customer_BK, s.LoadDate, s.RecordSource
FROM   stg.Customer_Hashed AS s
WHERE  NOT EXISTS (SELECT 1 FROM rv.Hub_Customer AS h
                   WHERE h.Customer_HK = s.Customer_HK);

-- SATELLITE-Beladung: neuen Satz nur bei geaendertem Hash-Diff.
INSERT INTO rv.Sat_Customer
       (Customer_HK, LoadDate, HashDiff, RecordSource, CustomerName, City, Segment)
SELECT s.Customer_HK, s.LoadDate, s.HashDiff, s.RecordSource,
       s.CustomerName, s.City, s.Segment
FROM   stg.Customer_Hashed AS s
WHERE  NOT EXISTS (
         SELECT 1
         FROM   rv.Sat_Customer AS sat
         WHERE  sat.Customer_HK = s.Customer_HK
           AND  sat.LoadEndDate IS NULL          -- aktueller Stand
           AND  sat.HashDiff    = s.HashDiff );  -- unveraendert -> nichts tun

Das Muster ist für Hub, Link und Satellite nahezu identisch. Diese Wiederholbarkeit ist der Grund, warum sich Data-Vault-Ladeprozesse besonders gut generieren und automatisieren lassen.

Die Link-Beladung folgt demselben Prinzip. Auch ein Link bekommt nur Beziehungen, die er noch nicht kennt; sein Hash-Key wird aus den beteiligten Business Keys berechnet. Da Beziehungen in Data Vault grundsätzlich als many-to-many modelliert werden, gibt es beim Link kein Update und kein Löschen – nur ein additives Einfügen neuer Beziehungen. Soll die zeitliche Gültigkeit einer Beziehung abgebildet werden, geschieht das über einen zugehörigen Effectivity Satellite.

-- LINK-Beladung: nur neue Beziehungen zwischen Kunde und Vertrag einfuegen.
INSERT INTO rv.Lnk_Customer_Contract
       (Cust_Contract_HK, Customer_HK, Contract_HK, LoadDate, RecordSource)
SELECT DISTINCT
       s.Cust_Contract_HK, s.Customer_HK, s.Contract_HK, s.LoadDate, s.RecordSource
FROM   stg.Contract_Hashed AS s
WHERE  NOT EXISTS (SELECT 1 FROM rv.Lnk_Customer_Contract AS l
                   WHERE l.Cust_Contract_HK = s.Cust_Contract_HK);

Der Link-Hash-Key wird beim Hashen der Staging-Daten aus den normalisierten Business Keys von Kunde und Vertrag gebildet. So entsteht für jede Kombination genau ein stabiler, parallel berechenbarer Schlüssel.

Ein häufig unterschätzter Vorteil dieser Idempotenz ist die Robustheit im Fehlerfall. Bricht ein Ladelauf mitten in der Verarbeitung ab, lässt er sich einfach erneut starten – bereits geladene Sätze werden nicht doppelt geschrieben, fehlende werden ergänzt. Es gibt keinen halb beladenen, inkonsistenten Zustand, der erst mühsam bereinigt werden müsste. Gerade in Umgebungen mit engen Ladefenstern und hohem Datenvolumen ist diese Eigenschaft Gold wert, weil sie den Wiederanlauf trivial macht und nächtliche Eingriffe überflüssig.

Raw Vault, Business Vault und PIT-Tabellen

In der Praxis trenne ich den Vault in zwei Bereiche. Der Raw Vault nimmt die Rohdaten genau so auf, wie sie aus den Quellen kommen – ohne fachliche Interpretation, dafür vollständig auditierbar. Der Business Vault enthält darauf aufbauend abgeleitete Strukturen, in denen Geschäftslogik umgesetzt wird: berechnete Satellites, gewichtete Beziehungen oder vereinheitlichte Schlüssel über mehrere Quellen hinweg.

Ein typisches Beispiel für Business-Vault-Logik ist die Vereinheitlichung von Geschäftsobjekten, die in mehreren Quellsystemen unterschiedlich geführt werden. Derselbe Kunde kann im CRM eine andere Kennung haben als im Abrechnungssystem. Im Raw Vault bleiben beide Kennungen unverändert erhalten; im Business Vault führt eine Same-As-Link- oder Mapping-Logik sie zu einer einheitlichen Sicht zusammen. Ändert sich später die Regel, nach der zusammengeführt wird, lässt sie sich aus dem unveränderten Raw Vault heraus neu berechnen – ein Sicherheitsnetz, das in einfacheren Architekturen schlicht fehlt.

Diese Trennung ist wichtig, weil sie Rohdaten und Interpretation auseinanderhält. Ändert sich eine Geschäftsregel, betrifft das nur den Business Vault – der Raw Vault als revisionssichere Wahrheit bleibt unangetastet. Sollte sich später herausstellen, dass eine Regel anders hätte lauten müssen, lässt sie sich aus dem Raw Vault heraus neu berechnen, ohne dass Information verloren gegangen ist.

PIT- und Bridge-Tabellen

Da ein Hub mehrere Satellites haben kann und Satellites unterschiedlich oft aktualisiert werden, ist die Abfrage eines konsistenten Standes zu einem bestimmten Zeitpunkt aufwändig. Hier helfen Point-in-Time-Tabellen (PIT) und Bridge-Tabellen. Eine PIT-Tabelle hält je Geschäftsschlüssel und Stichtag die passenden Satellite-Ladezeitpunkte vor und reduziert so die Zahl der Joins drastisch. Bridge-Tabellen bündeln häufig benötigte Link-Pfade. Beide sind reine Performance-Hilfsstrukturen und lassen sich jederzeit aus dem Vault neu aufbauen.

Die Trennung von Raw und Business Vault hat auch organisatorische Vorteile. Sie erlaubt es, die Verantwortung sauber zu schneiden: Ein Team kann sich um die zuverlässige, quellnahe Beladung des Raw Vault kümmern, während die Fachbereiche gemeinsam mit Entwicklern die Geschäftslogik im Business Vault gestalten. Weil der Raw Vault unveränderlich die Wahrheit aus den Quellen hält, können Geschäftsregeln experimentell erprobt, verworfen und neu berechnet werden, ohne dass je Information verloren geht. Diese Entkopplung von Rohdaten und Interpretation reduziert das Risiko folgenschwerer Fehler erheblich.

-- Eine PIT-Tabelle haelt je Geschaeftsschluessel und Stichtag den passenden
-- Satellite-Ladezeitpunkt vor und reduziert spaeter die Zahl der Joins.

INSERT INTO bv.Pit_Customer (Customer_HK, SnapshotDate, Sat_Customer_LoadDate)
SELECT  h.Customer_HK,
        cal.SnapshotDate,
        (SELECT MAX(s.LoadDate)
         FROM   rv.Sat_Customer AS s
         WHERE  s.Customer_HK = h.Customer_HK
           AND  s.LoadDate   <= cal.SnapshotDate)  AS Sat_Customer_LoadDate
FROM    rv.Hub_Customer AS h
CROSS JOIN ref.SnapshotCalendar AS cal
WHERE   cal.SnapshotDate >= '2020-01-01';

Eine Abfrage muss dann nicht mehr über alle Satellite-Versionen suchen, sondern joint direkt über die in der PIT-Tabelle hinterlegten Ladezeitpunkte – das beschleunigt zeitpunktbezogene Auswertungen erheblich.

Der zusätzliche Aufwand für PIT- und Bridge-Tabellen ist gut investiert. Ohne sie müssten Auswertungen für jeden Stichtag dynamisch das passende Satellite-Fenster ermitteln, was bei vielen Satellites und großen Historien teuer wird. Weil sich diese Hilfsstrukturen vollständig aus dem Vault ableiten lassen, können sie bei Bedarf jederzeit neu aufgebaut werden – etwa nach einer Strukturerweiterung oder einer Korrektur im Business Vault. Sie sind reine Beschleuniger und tragen keine eigene Wahrheit.

Vom Vault zum Star-Schema

Ein Data Vault ist hervorragend für die Integration und Historisierung von Daten geeignet – aber er ist nicht das Modell, mit dem Fachanwender oder BI-Werkzeuge gern arbeiten. Für die Auswertung leite ich aus dem Vault dimensionale Modelle nach Kimball ab: Star-Schemas mit Faktentabellen und Dimensionen, die intuitiv verständlich und für Werkzeuge wie Power BI optimiert sind.

Die Schichten im Überblick: Quellen, Staging, Raw Vault, Business Vault und die ableitende Information-Mart-Schicht mit Star-Schemas für die Auswertung.

Dieser Ansatz verbindet das Beste aus beiden Welten. Der Vault sorgt für Integration, Historisierung und Auditierbarkeit, das Star-Schema für Verständlichkeit und Performance in der Auswertung. Aus einem Hub mit seinen Satellites wird eine Dimension – häufig als Slowly Changing Dimension Typ 2, um die im Vault gespeicherte Historie sichtbar zu machen. Aus Links und ihren Satellites werden Faktentabellen.

-- Aus Hub + Satellite wird eine dimensionale Sicht mit Gueltigkeitszeitraum.
-- Die im Vault gespeicherte Historie wird zu SCD2-Versionen im Star-Schema.

CREATE OR ALTER VIEW im.DimCustomer AS
SELECT
    h.Customer_HK                              AS CustomerKey,
    h.Customer_BK                              AS CustomerBk,
    s.CustomerName, s.City, s.Segment,
    s.LoadDate                                 AS ValidFrom,
    LEAD(s.LoadDate) OVER (PARTITION BY h.Customer_HK
                           ORDER BY s.LoadDate) AS ValidTo,
    CASE WHEN s.LoadEndDate IS NULL THEN 1 ELSE 0 END AS IsCurrent
FROM rv.Hub_Customer  AS h
JOIN rv.Sat_Customer  AS s ON s.Customer_HK = h.Customer_HK;

Über die Fensterfunktion LEAD wird aus den aufeinanderfolgenden Ladeständen elegant ein Gültig-von/Gültig-bis-Intervall gebildet – ohne dass die Historie im Vault dupliziert werden muss.

Der große Reiz dieser Trennung liegt in ihrer Flexibilität auf der Auswertungsseite. Aus demselben Vault lassen sich beliebig viele, fachlich unterschiedliche Marts ableiten – ein Mart für das Controlling, einer für den Vertrieb, einer für eine regulatorische Meldung. Jeder Mart sieht genau die Sicht, die er braucht, und kann unabhängig von den anderen weiterentwickelt werden. Stellt sich heraus, dass ein Mart anders geschnitten sein muss, wird er aus dem Vault neu abgeleitet, ohne dass die zugrunde liegenden Rohdaten berührt werden. Diese Entkopplung von Integration und Auswertung ist einer der größten praktischen Gewinne der Methode.

Schichtenmodell der Gesamtarchitektur

Im Gesamtbild fügt sich Data Vault in eine klar geschichtete Architektur ein. Die Quellen werden in eine Staging-Schicht geladen, dort werden die Hash-Keys berechnet, anschließend wird der Raw Vault befüllt. Der Business Vault setzt die Geschäftslogik um, und aus beiden entsteht die Information-Mart-Schicht mit den auswertbaren Star-Schemas.

• Staging: Rohdaten aus den Quellen, Berechnung der Hash-Keys und Hash-Diffs
• Raw Vault: revisionssichere Integration in Hubs, Links und Satellites
• Business Vault: abgeleitete Strukturen, Geschäftslogik, vereinheitlichte Schlüssel
• Information Marts: Star-Schemas und Sichten für BI-Werkzeuge
• Querschnitt: Metadaten, Orchestrierung, Logging und Tests über alle Schichten

Diese Schichtung ist nicht starr, sondern dient als Leitplanke. Je nach Projekt fällt der Business Vault umfangreicher oder schlanker aus, manche Marts werden materialisiert, andere bleiben Sichten. Entscheidend ist, dass jede Schicht eine klare Aufgabe hat und dass die revisionssichere Wahrheit im Raw Vault unangetastet bleibt.

Querschnittsthemen ziehen sich durch alle Schichten. Eine zentrale Orchestrierung steuert, in welcher Reihenfolge und mit welcher Parallelität die Schichten beladen werden. Ein durchgängiges Logging mit Batch-IDs macht jeden Lauf nachvollziehbar. Und automatisierte Tests sichern sowohl die Beladung des Vault als auch die Ableitung der Marts ab. Diese Querschnittsfunktionen sind kein Beiwerk, sondern entscheiden über die Betreibbarkeit des gesamten Data Warehouse. Ich plane sie deshalb von Beginn an mit ein, nicht erst, wenn die ersten Probleme im Betrieb auftauchen.

In der Cloud lässt sich dieses Schichtenmodell unmittelbar auf moderne Plattformen übertragen. Die Staging-Schicht entspricht dann oft einer Bronze-Ebene im Data Lake, Raw und Business Vault liegen als Delta- oder Parquet-Strukturen vor, und die Information Marts werden in einem performanten Auswertungsspeicher bereitgestellt. Die Methode bleibt dieselbe, nur die darunterliegende Technologie wechselt. Diese Unabhängigkeit von der konkreten Plattform ist ein weiterer Grund, warum sich Data Vault für langfristig gedachte Data Warehouses bewährt: Das Modell übersteht auch einen Technologiewechsel.

Automatisierung und Metadaten

Die größte Stärke von Data Vault im Betrieb ist seine Gleichförmigkeit. Weil jeder Hub, jeder Link und jeder Satellite demselben Bauplan folgt, lassen sich sowohl die Tabellenstrukturen als auch die Ladeprozeduren aus Metadaten generieren. Statt Hunderte von Prozeduren von Hand zu schreiben, pflege ich eine Metadaten-Beschreibung der Quellen, Schlüssel und Attribute – und erzeuge daraus DDL und Ladelogik.

Dieser metadatengetriebene Ansatz hat mehrere Vorteile. Er reduziert den Implementierungsaufwand drastisch, er erzwingt Konsistenz über alle Bausteine hinweg und er macht das Anbinden neuer Quellen zu einer Konfigurationsaufgabe statt zu einem Programmierprojekt. Werkzeuge wie Datenmodellierungs-Tools – etwa PowerDesigner, mit dem ich in mehreren DWH-Projekten gearbeitet habe – unterstützen diesen Ansatz, ebenso selbst entwickelte Generatoren auf Basis der Metadatentabellen.

Die Generierung umfasst dabei nicht nur die Tabellen, sondern den gesamten Lade-Stack: die DDL für Hubs, Links und Satellites, die Berechnung der Hash-Keys, die idempotenten Ladeprozeduren und die Einträge in die Steuerungstabellen, die den parallelen Ablauf orchestrieren. Im Idealfall genügt es, eine neue Quelle in den Metadaten zu beschreiben und den Generator laufen zu lassen, um eine vollständig integrierte, getestete Anbindung zu erhalten. Dieser Hebel verwandelt Aufgaben, die sonst Tage dauern, in eine Sache von Stunden.

Eine metadatengetriebene Architektur verändert auch die Art, wie ein Team arbeitet. Das Anbinden einer neuen Quelle wird zu einer wohldefinierten Aufgabe: Quelle beschreiben, Geschäftsschlüssel und Attribute zuordnen, generieren, testen. Statt jeder Entwickler seinen eigenen Stil einbringt, erzwingt der Generator eine einheitliche, geprüfte Umsetzung. Das senkt die Einarbeitungszeit neuer Teammitglieder und macht das Data Warehouse unabhängiger von einzelnen Personen – ein wichtiger Aspekt für die langfristige Betreibbarkeit.

Die Metadaten selbst werden so zum wertvollen Aktivposten. Sie dokumentieren, welche Quellen angebunden sind, welche Geschäftsschlüssel verwendet werden und wie die Attribute auf Satellites verteilt sind. Diese Beschreibung ist gleichzeitig technische Dokumentation und Bauplan. Ändert sich eine Quelle, wird die Metadaten-Beschreibung angepasst und der betroffene Teil neu generiert – Modell, Ladelogik und Dokumentation bleiben so automatisch konsistent. Genau diese Konsistenz von Hand zu wahren ist in großen Data Warehouses kaum möglich.

Vorgehen in der Zusammenarbeit

Ein Data-Vault-Projekt beginnt mit der fachlichen Modellierung: Welche Geschäftsobjekte gibt es, welche Geschäftsschlüssel identifizieren sie, welche Beziehungen bestehen? Diese Fragen kläre ich gemeinsam mit den Fachbereichen, denn die Geschäftsschlüssel sind das Fundament des gesamten Modells. Erst danach folgen die technische Umsetzung und die Automatisierung.

• Analyse: Geschäftsobjekte, Schlüssel und Beziehungen mit den Fachbereichen klären
• Modellierung: Hubs, Links und Satellites entwerfen, Raw- und Business-Vault abgrenzen
• Umsetzung: DDL und Ladelogik metadatengetrieben generieren und testen
• Marts: auswertbare Star-Schemas für die BI-Werkzeuge ableiten
• Betrieb: parallele Beladung, Monitoring, Tests und Dokumentation

Mir ist wichtig, Data Vault nicht dogmatisch, sondern angemessen einzusetzen. Nicht jede Tabelle muss durch den vollen Vault laufen; manche Referenzdaten lassen sich einfacher direkt führen. Diese pragmatische Abwägung – wo lohnt sich der Vault, wo nicht – ist Teil meiner Beratung und spart dem Auftraggeber unnötigen Aufwand.

In der Praxis arbeite ich gern iterativ. Statt das gesamte Modell vorab bis ins letzte Detail zu entwerfen, beginne ich mit den zentralen Geschäftsobjekten und ihren wichtigsten Beziehungen und erweitere das Modell schrittweise. Weil Data Vault additiv wächst, ist dieses Vorgehen risikoarm: Jede Erweiterung kommt hinzu, ohne Bestehendes zu gefährden. So entsteht früh ein lauffähiges Data Warehouse, das mit jedem Sprint mehr Quellen und mehr fachliche Tiefe gewinnt – und die Fachbereiche sehen bereits während der Entwicklung erste Ergebnisse.

Typische Leistungen im Data-Vault-Projekt

Rund um die Data-Vault-Modellierung übernehme ich je nach Projektphase unterschiedliche Aufgaben – von der fachlichen Modellierung über die Implementierung bis zum Betrieb. Dabei füge ich mich in bestehende Teams und Werkzeuglandschaften ein und arbeite eng mit Architekten, Entwicklern und Fachbereichen zusammen, damit das Ergebnis nicht nur technisch sauber, sondern auch fachlich tragfähig und langfristig betreibbar ist.

• Fachliche Modellierung von Hubs, Links und Satellites
• Abgrenzung von Raw Vault und Business Vault
• Hash-Key-Strategie mit HASHBYTES und kanonischer Schlüsselnormalisierung
• Metadatengetriebene Generierung von DDL und Ladeprozeduren
• Parallele, idempotente Beladung des Vault
• PIT- und Bridge-Tabellen für performante Auswertungen
• Ableitung dimensionaler Modelle (Star-Schema, SCD2) für die BI-Schicht
• Migration bestehender DWH-Strukturen in ein Data-Vault-Modell
• Tests, Logging, Monitoring und Dokumentation des Vault

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zur Data-Vault-Modellierung