Data Vault: Hubs, Links, Satelliten im Data Warehouse

Data Vault lohnt sich, wenn mehrere Quellsysteme dieselben Kunden, Aufträge und Rechnungen liefern und frühere Stände nachweisbar bleiben müssen. Mit einer Quelle und wenigen Berichten ist das Muster zu schwer. Dann genügen saubere Tabellen in der mittleren Schicht und ein Star Schema darüber.

Ein Data & AI Berater bekommt die Frage selten so gestellt. Meist ist der Vault längst gebaut, und das Team, das ihn entworfen hat, arbeitet an anderem. Der Auftrag lautet dann: prüfen, ob der Vault in der mittleren Schicht hält. Dahinter stehen meist zwei Sorgen. Ein Monatswert hat sich nachträglich geändert, und niemand kann den alten Stand zeigen. Oder eine neue Quelle soll dazu, und keiner weiß, was die Anbindung berührt.

Der Berater antwortet darauf nicht mit einer Meinung zum Muster. Er liest zuerst, was gebaut ist: jede Tabelle, jede Sicht und den Code dazwischen. Dafür genügt eine Rolle, die nur lesen darf. Erst danach lässt sich sagen, ob Schlüssel und Historie tragen.

Als Erstes ordnet er den Vault in die Schichten ein. In der Medallion-Architektur ist der Vault nach verbreiteter Lesart die Silber-Schicht: Staging liegt darunter, die Marts liegen darüber. Dem Team stellt er dazu die fünf Fragen der Tabelle. Sie zeigen, ob das Muster zur Lage passt oder mehr Aufwand macht, als es abnimmt.

Hubs, Links und Satelliten sind die drei Tabellenarten der Data-Vault-Modellierung. Ein Hub hält die Geschäftsschlüssel eines Objekts, zum Beispiel jede Kundennummer genau einmal. Ein Link hält eine Beziehung zwischen Hubs: welcher Kunde welchen Auftrag erteilt hat. Ein Satellit hält die Eigenschaften dazu und jeden Stand, den sie je hatten.

Die Trennung hat einen Grund. Schlüssel ändern sich selten, Beziehungen manchmal, Eigenschaften laufend. Liegt alles in einer breiten Tabelle, ändert jede neue Spalte die Tabelle und alles, was aus ihr liest. Im Vault kommt eine neue Quelle als neuer Satellit dazu. Der Hub bleibt, wie er ist.

Entwickelt hat das Muster Dan Linstedt, öffentlich beschrieben hat er es Anfang der 2000er-Jahre. Seither trägt jede Zeile zwei Angaben: wann sie geladen wurde und aus welcher Quelle sie stammt. Data Vault 2.0 folgte 2013 und ersetzte laufende Nummern durch Hash Keys. Ein Hash Key wird aus dem Geschäftsschlüssel berechnet. Deshalb muss kein Ladelauf auf einen anderen warten, um einen Schlüssel nachzuschlagen. Die aktuelle Fassung des Standards heißt Data Vault 2.1.

Beim Lesen beginnt der Berater mit den Hubs. An ihnen hängt alles andere: Ein Satellit ohne Hub hat keinen Schlüssel, ein Link ohne Hub verbindet nichts. Welche Nummer einen Kunden bezeichnet, klärt er mit dem Fachbereich, denn das steht in keinem Code. Die Tabelle zeigt, was jeder Baustein mindestens trägt.

In den Raw Vault gehört, was die Quelle liefert. In den Business Vault gehört, was daraus für alle berechnet wird. Der Raw Vault ändert keinen Wert. Er ordnet die Lieferung nach Schlüssel, Beziehung und Eigenschaft und hält fest, wann sie kam. So lässt sich jede Zahl bis zur Lieferung zurückverfolgen.

Der Business Vault liegt darüber. Hier stehen die Rechenregeln, die mehrere Marts brauchen: die Umrechnung in eine Währung, die Gültigkeit von und bis, der Abgleich zweier Kundennummern. Er wird sparsam gebaut. Was nur ein Bericht braucht, gehört nicht hinein.

Der Berater prüft hier die Richtung, weil sie über die Herkunft jeder Zahl entscheidet. Der Business Vault liest aus dem Raw Vault und nie aus Staging. Die Marts lesen aus dem Vault und nie an ihm vorbei. Steht eine Umrechnung zusätzlich in einem Mart, gibt es sie zweimal. Irgendwann rechnen beide Stellen verschieden.

Historie entsteht, weil ein Satellit nie überschreibt, und ein Stichtag ist eine Abfrage auf diese Historie. Ändert sich das Zahlungsziel eines Kunden, schreibt der Ladelauf eine neue Zeile mit neuem Ladezeitpunkt. Die alte Zeile bleibt stehen.

Ein Ende der Gültigkeit steht nicht in der Tabelle. Es ergibt sich aus der nächsten Zeile desselben Schlüssels und wird in einer Sicht berechnet. Die jüngste Zeile bekommt dort ein festes Datum in ferner Zukunft. Dieses Datum ist überall dasselbe, sonst passen zwei Sichten nicht zueinander. Die Tabelle zeigt das an drei Zeilen eines Satelliten, alle Werte sind Beispielwerte. Welches Zahlungsziel am 30. September 2026 galt, beantwortet die zweite Zeile. Die Sicht dazu steht als Beispiel unter der Tabelle.

Bei zwei Satelliten beantwortet eine Sicht die Frage nach dem Stichtag. Bei vielen wird die Abfrage unübersichtlich, weil jeder Satellit eigene Zeiträume hat. Dafür gibt es Point-in-Time-Tabellen: Sie merken sich je Schlüssel und Stichtag, welche Zeile jedes Satelliten gilt. Bridge-Tabellen halten entsprechend einen Weg über mehrere Hubs und Links fest. Beide sind berechnet und gehören deshalb in den Business Vault.

Zwei Sätze gibt der Berater dem Team dazu mit. Ein vergangener Stichtag zeigt nie den heutigen Wert. Und die erste Befüllung ist ein Ausgangsstand, keine beobachtete Historie: Was davor geschah, kennt der Vault nicht.

In Snowflake ist ein Vault eine Reihe gewöhnlicher Tabellen, in die der Ladelauf nur einfügt. Snowflake beschreibt Data Vault im eigenen Blog genau so: als Muster ohne Update und ohne Delete. Das passt zur Historie. Was nie geändert wird, lässt sich jederzeit nachrechnen.

Den Hash Key berechnet eine Funktion aus dem Geschäftsschlüssel. Hier liest der Berater im Code zuerst nach, weil ein abweichender Schlüssel alles Weitere trennt. Snowflake bietet dafür unter anderem SHA1_BINARY, SHA2_BINARY und MD5_BINARY. Der Standard schreibt keinen Algorithmus vor. Er verlangt, dass die Wahl im ganzen Warehouse dieselbe ist: gleiche Funktion, gleiche Schreibweise, gleiches Trennzeichen, gleicher Ersatz für leere Werte. Weicht ein Ladelauf davon ab, bekommt derselbe Kunde zwei Schlüssel.

Die Anleitungen von Snowflake laden den Raw Vault mit Streams und Tasks. Ein Stream merkt sich, welche Zeilen in Staging neu sind. Ein Task prüft den Stream nach Zeitplan und lädt nur, wenn etwas dazukam. Ein Insert in mehrere Tabellen füllt dabei Hub, Link und Satellit in einer Anweisung. Für Business Vault und Marts genügen zunächst Sichten. Soll ein Ergebnis gespeichert vorliegen, hält eine Dynamic Table es nach einer vorgegebenen Verzögerung aktuell.

Eines nimmt Snowflake dem Team nicht ab. Primär- und Fremdschlüssel lassen sich angeben, auf Standardtabellen erzwingt Snowflake sie aber nicht. Ein Hub kann denselben Schlüssel also zweimal enthalten, ohne dass ein Ladelauf scheitert. Welche Prüfungen das auffangen, steht in Datenintegrität im Data Warehouse. Die Angaben folgen der Dokumentation und den Anleitungen von Snowflake, Stand November 2026.

Einen guten Vault erkennt man an wenigen Regeln, die sich am Code prüfen lassen. Eine Regel ist ein Satz mit Zielwert. Der Berater schreibt sie nicht aus dem Lehrbuch ab. Er liest zuerst, welche Muster das Team selbst verwendet, und schlägt daraus Regeln vor. Ein Zielwert bleibt ein Vorschlag, bis das Team ihn bestätigt.

Geprüft wird auf einem Graphen. Ein Notebook liest die Definitionen aller Tabellen und Sichten aus Snowflake, mit einer Rolle, die nur lesen darf. ABIS baut aus diesem Export einen Graphen und verfolgt die Tabellen des Vaults wie jedes andere SQL. So zeigt die Data Lineage, welche Sicht aus welchem Satelliten liest und was eine Änderung am Hub trifft. ABIS liest dabei nur Definitionen, keine Datensätze, und führt in Snowflake nichts aus.

Hubs, Links und Satelliten erkennt ABIS nicht von selbst. Welche Tabelle was ist, ergibt sich aus den Namensregeln des Teams, und das Team bestätigt die Zuordnung. Eine Regel wie „jeder Hub trägt Hash Key und Geschäftsschlüssel“ ist dann eine Abfrage auf dem Graphen, geschrieben für dieses Projekt. Derselbe Code liefert dabei immer dasselbe Ergebnis.

Die Regeln der Tabelle gehören zur zweiten Messung, der am Code. Wie daraus ein Score wird, zeigt Datenqualität messen am Beispiel: 81 von 100 Punkten, 19 Punkte bis zum Ziel. Ob ein Geschäftsschlüssel in den Daten eindeutig ist, prüft die erste Messung mit einer Zählung im Warehouse. Jeder Verstoß ist zunächst eine These. Ob ein Hub ohne Satellit ein Fehler ist oder Absicht, entscheidet das Team.

Beides, an verschiedenen Stellen. Data Vault führt in der mittleren Schicht zusammen und hält die Historie. Das Star Schema liegt darüber und ist zum Lesen gebaut: Fakten in der Mitte, Dimensionen außen. Ein Bericht liest aus dem Star Schema und nie aus dem Vault. Die Tabelle unter der Kurzantwort stellt beide gegenüber.

Der Grund ist die Zahl der Verknüpfungen. Eine Frage an den Vault braucht Hub, Link und mehrere Satelliten, dazu die Gültigkeit je Satellit. Das ist Arbeit für eine Sicht im Mart und nicht für jede Person, die einen Bericht baut. Microsoft empfiehlt das Star Schema zudem für Semantikmodelle in Power BI. Wie beide Seiten zusammenkommen, zeigt Power BI × Snowflake.

An der Übergabe prüft der Berater zwei Dinge. Jede Dimension hat einen Ersatzschlüssel (Surrogate Key), eine Gültigkeit und ein Kennzeichen für den aktuellen Stand. Und die Fakten verknüpfen über diesen Ersatzschlüssel, nicht über Kennung und Zeitraum. So zeigt ein Auftrag vom März die Kundendaten vom März.

Data Vault ordnet Daten, richtig macht es sie nicht. Ein falscher Wert aus der Quelle steht danach historisiert und nachvollziehbar im Vault, aber weiter falsch. Snowflake ist in diesem Kapitel das Beispiel: Muster und Regeln gelten für jedes Warehouse, das SQL spricht. Überall bleiben sechs Grenzen.

• Mehr Tabellen, mehr Verknüpfungen. Aus einem Objekt werden drei oder mehr Tabellen. Ohne feste Lademuster oder einen Generator wächst der Aufwand mit jeder Quelle.
• Der Geschäftsschlüssel ist eine Fachentscheidung. Welche Nummer einen Kunden über zwei Systeme hinweg bezeichnet, legt kein Werkzeug fest. Das entscheidet der Fachbereich.
• Die erste Befüllung ist keine Historie. Der Vault kennt nur, was seit dem ersten Ladelauf kam.
• ABIS erkennt die Bausteine nicht von selbst. Welche Tabelle Hub, Link oder Satellit ist, kommt aus Namensregeln, die das Team bestätigt. Die Regeln sind Abfragen für das Projekt.
• Geprüft ist der Code, wie er ausgerollt ist. Was die Leserolle nicht sieht, fehlt im Graphen.
• Löschen braucht ein eigenes Verfahren. Ein Muster, das nur einfügt, kennt kein Löschen. Wer Daten auf Verlangen entfernen muss, regelt das gesondert.