Data Vault Modeling: Hubs, Links und Satellites erklärt

Dein Star-Schema sah beim Launch super aus. Achtzehn Monate später: 14 Source-Systeme speisen es, drei Teams streiten über die Customer-Dimension, und ein Change-Request für eine neue Quelle erzwingt den Umbau von vier Fact-Tabellen. Kimball passt für stabile Domänen. Dafür war es nicht gebaut.

Data Vault ist eine Modellierungs-Methode speziell für Enterprise-Warehouses mit vielen Quellen, häufigen Changes und harten Audit-Anforderungen. Hier ist, was es ist, wie es funktioniert und wann du es einsetzt.

TL;DR

Die drei Kern-Konstrukte

Data Vault hat drei fundamentale Bausteine. Wer sie versteht, hat die Methode.

1. Hubs — Business Keys

Ein Hub repräsentiert eine Business-Entität (Kunde, Produkt, Order) und speichert nur den Business-Key — den Identifier, den das Business nutzt, unabhängig vom Source-System.

-- Data Vault 2.0 Hub: Customer
-- (Standard SQL / Snowflake-Dialekt)
CREATE TABLE hub_customer (
    hub_customer_hk   VARCHAR(32) NOT NULL,   -- MD5- oder SHA-256-Hash des Business-Keys
    customer_id       VARCHAR(50) NOT NULL,    -- Roher Business-Key
    load_date         TIMESTAMP   NOT NULL,    -- Erstmaliger Load-Zeitpunkt
    record_source     VARCHAR(100) NOT NULL,   -- Welches System lieferte den Key
    CONSTRAINT pk_hub_customer PRIMARY KEY (hub_customer_hk)
);

Regeln:

• Hubs werden nie geändert, nur eingefügt (insert-only)
• Hash-Key ist deterministisch: gleicher Business-Key → immer gleicher Hash
• Keine deskriptiven Attribute — die gehören in Satellites

2. Links — Beziehungen

Ein Link repräsentiert eine Beziehung zwischen zwei oder mehr Hubs. Eine Order, von einem Kunden platziert? Das ist ein Link zwischen Hub_Customer und Hub_Order.

-- Data Vault 2.0 Link: Order placed by Customer
CREATE TABLE link_customer_order (
    link_customer_order_hk   VARCHAR(32) NOT NULL,  -- Hash aller Parent-Hub-Keys
    hub_customer_hk          VARCHAR(32) NOT NULL,  -- FK -> hub_customer
    hub_order_hk             VARCHAR(32) NOT NULL,  -- FK -> hub_order
    load_date                TIMESTAMP   NOT NULL,
    record_source            VARCHAR(100) NOT NULL,
    CONSTRAINT pk_link_customer_order PRIMARY KEY (link_customer_order_hk)
);

Regeln:

• Links sind auch insert-only
• Link-Hash-Key entsteht aus allen beteiligten Hub-Keys
• Links modellieren Fakten über Beziehungen (eine Order gehört zu einem Kunden), keine Business-Attribute

3. Satellites — deskriptive Attribute

Satellites speichern alle deskriptiven, sich ändernden Daten um einen Hub oder Link. Customer-Name, E-Mail, Adresse — alles in einem Satellite hängend an Hub_Customer.

-- Data Vault 2.0 Satellite: Customer-Attribute aus CRM
CREATE TABLE sat_customer_crm (
    hub_customer_hk   VARCHAR(32) NOT NULL,
    load_date         TIMESTAMP   NOT NULL,
    load_end_date     TIMESTAMP,              -- NULL = aktuelle Zeile
    hash_diff         VARCHAR(32) NOT NULL,   -- Hash aller Attribut-Werte
    first_name        VARCHAR(100),
    last_name         VARCHAR(100),
    email             VARCHAR(200),
    country           VARCHAR(50),
    record_source     VARCHAR(100) NOT NULL,
    CONSTRAINT pk_sat_customer_crm PRIMARY KEY (hub_customer_hk, load_date)
);

Regeln:

• Satellites sind die einzigen Tabellen, die Historie tracken (Type-2-SCD by default)
• Pro Source-System ein eigenes Satellite — CRM-Daten mischen sich nie mit ERP-Daten
• hash_diff ermöglicht effiziente Change-Detection beim Load

Die Data-Vault-Architektur

flowchart LR
    S1[CRM-System]
    S2[ERP-System]
    S3[Web-Events]

    subgraph RawVault["Raw Vault"]
        direction TB
        HC[Hub Customer]
        HO[Hub Order]
        HP[Hub Product]
        LCO[Link Customer-Order]
        LOP[Link Order-Product]
        SCcrm[Sat Customer CRM]
        SCerp[Sat Customer ERP]
        SO[Sat Order Details]
    end

    subgraph BizVault["Business Vault"]
        PIT[PIT-Tabellen]
        Bridge[Bridge-Tabellen]
    end

    subgraph Mart["Information Mart"]
        DimC[Dim Customer]
        FactO[Fact Orders]
    end

    S1 --> HC & SCcrm
    S2 --> HC & SCerp & HO & SO
    S3 --> LCO
    HC & HO --> LCO
    HO & HP --> LOP
    RawVault --> BizVault --> Mart

• Source-Systeme laden unabhängig in den Raw Vault — keine Cross-System-Dependencies.
• Der Business Vault ergänzt computed Attributes und Point-in-Time-Strukturen.
• Information Marts exponieren optimierte dimensionale Modelle für BI-Tools.

Point-in-Time-Tabellen (PIT)

Mehrere Satellites an einem Hub erzeugen ein Performance-Problem: Joins über fünf Satellites, um den Customer-Stand zu einem Zeitpunkt zu rekonstruieren, brauchen komplexes SQL. PIT-Tabellen lösen das.

-- PIT-Tabelle: Customer-Stand zu einem Datum
-- (Standard SQL / Snowflake-Dialekt)
CREATE TABLE pit_customer AS
SELECT
    snap.snapshot_date,
    h.hub_customer_hk,
    -- Für jedes Satellite: jüngstes load_date <= snapshot_date
    MAX(CASE WHEN s_crm.load_date <= snap.snapshot_date THEN s_crm.load_date END)
        AS sat_crm_load_date,
    MAX(CASE WHEN s_erp.load_date <= snap.snapshot_date THEN s_erp.load_date END)
        AS sat_erp_load_date
FROM hub_customer h
CROSS JOIN (
    SELECT DISTINCT CAST(load_date AS DATE) AS snapshot_date FROM sat_customer_crm
) snap
LEFT JOIN sat_customer_crm s_crm
    ON h.hub_customer_hk = s_crm.hub_customer_hk
    AND s_crm.load_date <= snap.snapshot_date
LEFT JOIN sat_customer_erp s_erp
    ON h.hub_customer_hk = s_erp.hub_customer_hk
    AND s_erp.load_date <= snap.snapshot_date
GROUP BY snap.snapshot_date, h.hub_customer_hk;

PIT-Tabellen werden vorberechnet und bei jedem Load neu gebaut. Sie machen Downstream-Satellite-Joins trivial — ein Join pro Satellite über das PIT-aufgelöste load_date.

Hash-Key-Generierung

Hash-Keys müssen deterministisch und über alle Loads konsistent sein. In der Praxis: entweder MD5 (128 Bit) oder SHA-256 (256 Bit) auf dem upper-cased und getrimmten Business-Key.

# Python — deterministische Hash-Key-Generierung
import hashlib

def generate_hub_hk(business_key: str) -> str:
    # Normalisieren: uppercase, whitespace strip
    normalized = str(business_key).upper().strip()
    return hashlib.md5(normalized.encode("utf-8")).hexdigest()

def generate_link_hk(*hub_hks: str) -> str:
    # Sortierte Hub-Keys verknüpfen für Reihenfolge-Unabhängigkeit
    combined = "||".join(sorted(hub_hks))
    return hashlib.md5(combined.encode("utf-8")).hexdigest()

# Beispiel
customer_hk = generate_hub_hk("CUST-00123")
order_hk = generate_hub_hk("ORD-98765")
link_hk = generate_link_hk(customer_hk, order_hk)

Manche Teams bevorzugen SHA-256, um Collision-Risiken in sehr großen Datasets zu minimieren. Beides funktioniert — sei nur in deinem ganzen Vault konsistent.

Data Vault 2.0 — Erweiterungen

Dan Linstedts Data Vault 2.0 (ca. 2013) ergänzte die Original-Methode um mehrere Konstrukte:

Für die meisten Teams am Anfang: erst Hubs, Links, Satellites. PIT-Tabellen, wenn Query-Performance zum Problem wird. Der Rest kommt später.

Warum Data Vault im Enterprise?

1. Auditierbarkeit ist eingebaut. Jede Zeile trägt load_date und record_source. Du kannst „was sagte unser CRM am 3. März 2022 um 14:32 über Kunde X?" immer beantworten — eine Frage, an der Kimball-Star-Schemas zerbrechen.

2. Neue Source-Systeme ohne Touch existierender Tabellen. Neues ERP? Neues Satellite an Hub_Customer. Existierende Pipelines bleiben. Das ist der zentrale Architektur-Vorteil.

3. Parallel-Loading. Hubs, Links, Satellites haben innerhalb eines Load-Zyklus keine Load-Order-Dependencies. Stark parallelisierbares ETL.

4. Konflikte werden sauber behandelt. CRM sagt: Kunde wohnt in Deutschland. ERP sagt: Frankreich. Im Star-Schema gewinnt eine Source. In Data Vault: beide in separaten Satellites — der Konflikt ist explizit, nicht versteckt.

Wann Data Vault NICHT die richtige Wahl ist

• Kleine, stabile Domänen mit 1–2 Source-Systemen — Overhead nicht gerechtfertigt. Nimm Kimball.
• Teams ohne dediziertes Data Engineering — Data Vault braucht disziplinierte Tools und Modeling-Expertise.
• Ad-hoc-Analytics-Plattformen — wenn der primäre Output explorative Dashboards sind, ist die Mart-Layer-Pflicht reiner Reibungsverlust.
• „Time to first Dashboard" ist das Hauptkriterium — Raw-Vault-Querying in BI-Tools geht meist nicht ohne Mart-Layer. 4–8 Wochen Extra-Arbeit.

Tooling

Die meisten modernen Data-Vault-Implementierungen nutzen dbt für den Transformations-Layer. Bibliotheken wie datavault4dbt und AutomateDV (vormals dbtvault) liefern Macros, die Hub/Link/Satellite-Loads aus YAML-Configs generieren — drastisch weniger Boilerplate.

Häufige Fehler

1. Business-Logic im Raw Vault. Der Raw Vault ist source-treu — lade, was die Source liefert, ohne Transformation. Business-Rules gehören in Business Vault oder Mart.

2. Beziehungen als Hub-Attribute. „Customer hat eine preferred_region-FK" — diese Beziehung gehört in ein Link, nicht in ein Satellite-Attribut.

3. Ein einziges Riesen-Satellite pro Hub. Splitte Satellites nach Source-System und Rate-of-Change. Häufig wechselnde Daten (Session-Daten) gehören nicht zusammen mit langsam-änderlichen Attributen (Customer-Name) — sonst gibt's Historien-Inflation.

4. Inkonsistente Hash-Key-Generierung. Wenn dein Python-Loader und deine dbt-Macros für denselben Business-Key unterschiedliche Hashes erzeugen, baust du lautlos doppelte Hubs. Standardisiere Hash-Generation in einer geteilten Library.

FAQ

Wann lohnt Data Vault gegenüber Kimball im DACH-Mittelstand?

Sobald du mehr als 3–4 Source-Systeme hast, regulatorisch (Bafin, MaRisk, DSGVO mit echten Audit-Anforderungen) gefordert wirst oder häufig neue Systeme integrieren musst. Bei stabilen, kleineren Setups bleibt Kimball schneller im Output.

Kann ich Data Vault auf BigQuery oder Snowflake bauen?

Ja, beide Plattformen sind gut geeignet. Snowflake mit dbt + AutomateDV ist eine sehr verbreitete Kombination. BigQuery funktioniert ebenfalls, mit Augenmerk auf Partitionierungs-Kosten bei Type-2-Satellites.

Wie verhält sich Data Vault zum Medaillon-Modell (Bronze/Silver/Gold)?

Raw Vault ≈ Bronze (source-treu), Business Vault ≈ Silver (computed Rules, Historie aufgelöst), Mart ≈ Gold (Business-ready). Beide Modelle ergänzen sich gut.

Was kostet ein Data-Vault-Setup im Vergleich?

Initial-Aufwand 4–8 Wochen Modeling und Tooling-Setup; danach amortisiert sich der Aufwand bei jedem neuen Source-System (vs. Star-Schema-Refactoring). Tooling-Lizenzen meist analog zu deinem dbt+Warehouse-Stack — keine spezifischen Data-Vault-Lizenzkosten.

Fazit

Data Vault tauscht Query-Einfachheit gegen Architektur-Resilienz. Für Enterprise-Warehouses mit vielen Quellen, häufigen Changes und Audit-Anforderungen lohnt sich der Tausch fast immer.

Für kleinere, stabile Domänen: Kimball. Für große, evolvierende, multi-source Enterprise-DWHs: Data Vault ist die Methode, die für dein Problem designt wurde.

Stand: 14. Mai 2026. Tooling-Stati prüfen — AutomateDV und datavault4dbt aktiv. Hash-Algorithmen je nach Datenmenge auswählen.