Am Ende sieht jede gut gebaute Datenplattform für ihre Nutzer gleich aus: Kennzahlen und ihre Blickwinkel, verständlich benannt, schnell abfragbar. Ob darunter Kimball, Data Vault 2.0 oder ein Mittelweg liegt, erkennt im Dashboard niemand.
Entschieden wird eine Ebene tiefer, bei einer Frage, die weniger technisch ist, als sie klingt: An welcher Stelle wird aus mehreren Quellsystemen eine gemeinsame Sicht, und wie oft muss diese Arbeit wiederholt werden, wenn sich etwas ändert? Kimball erledigt sie im Transformationscode, bei jeder Quelländerung erneut. Data Vault 2.0 verankert sie einmal im Datenmodell und bezahlt dafür mit zusätzlichen Schichten. Dazwischen liegt ein Hybridansatz, der Kimballs dimensionales Modell mit Architektureigenschaften kombiniert, für die sonst Data Vault steht, und den viele Teams bauen, ohne ihn so zu nennen. Diese Wahl ist eine Grundsatzentscheidung: Im laufenden Betrieb ist der Wechsel des Fundaments teuer, im Greenfield kostet er nichts. Aus unseren Projekten wissen wir, dass diese Entscheidung selten bewusst getroffen wird und Teams sie Jahre später teuer nachholen.
Warum diese drei Ansätze
Die Frage hat zwei Achsen, und die drei Wege besetzen sie unterschiedlich. Auf der Modellachse, also welches Datenmodell die Integration trägt, gibt es zwei etablierte Standards mit ausgereifter Methodik und breiter Praxiserfahrung: Kimball und Data Vault 2.0. Der Hybridansatz gibt auf dieser Achse Kimballs Antwort, dimensional mit konformierten Dimensionen. Auf der Architekturachse übernimmt er dagegen Eigenschaften, für die sonst Data Vault steht: quellgetrennte, historisierte Persistenz, Änderungsabsorption am Rand, additive Erweiterung um neue Quellen. Kimballs Modell plus Data Vaults Änderungsarchitektur, ohne dessen Modellobjekte, daher der Name. Gemeint ist damit nicht die klassische Hybrid-Architektur der Kimball-Literatur, bei der ein normalisiertes 3NF-Warehouse die dimensionale Presentation Area speist, sondern die quellmodulare Bauform unterhalb eines konformierten Sternschemas. Eine eigene Spalte verdient er, weil sich seine praktischen Eigenschaften deutlich von beiden Standards unterscheiden und weil er in vielen Projekten faktisch entsteht, ohne dass ihn jemand so nennt. Keiner der drei Wege ist pauschal der richtige, die Entscheidung folgt aus dem Kontext, den die Entscheidungsmatrix am Ende zusammenfasst.
Ein Wort zu One Big Table, denn das Muster wird im Lakehouse-Umfeld regelmäßig als Alternative genannt: breite, flache Tabellen statt Sternschema, mit dem Argument, dass Joins auf spaltenorientierten Engines teurer seien als Redundanz. Das Muster beantwortet aber eine andere Frage. Es beschreibt, wie Daten an einen einzelnen Konsumenten ausgeliefert werden, nicht, wie mehrere Quellen integriert werden. Eine breite Tabelle ohne modellierte Schicht darunter bedeutet, dass jede Quelländerung ungebremst auf das Konsumobjekt durchschlägt. Als Ableitung aus einem Sternschema, etwa für ML-Features oder ein einzelnes Dashboard, sind breite Tabellen dagegen völlig legitim. Sie sind eine Konsumform, kein Fundament.
Die übrigen Ansätze sind keine echte Alternative für moderne Setups: Ein vollnormalisiertes Inmon-Warehouse ist als Integrationsschicht auf einem Lakehouse wegen der Join-Tiefe und des fehlenden Tooling-Ökosystems praktisch verdrängt, Anchor Modeling bleibt eine akademische Nische. Und eine Abgrenzung nach oben: Alle drei Ansätze modellieren strukturierte Quelldaten. Für Dokumente, Embeddings und Vector Search braucht eine AI-fähige Plattform eigene Bausteine, die von dieser Entscheidung unberührt bleiben.
Drei Wege, ein Ziel
Am konkreten Fall wird der Unterschied sichtbar. Zwei ERP-Instanzen liefern dasselbe Geschäftsobjekt: Die Standorte arbeiten teils auf erp_a, teils auf erp_b, und beide Systeme liefern Lieferbelege. Beide kennen dasselbe Material, aber unter verschiedenen Schlüsseln und mit verschiedenen Attributen.
Kimball hält den Silver Layer bewusst quellnah: je Quelle bereinigte, historisierte Tabellen in der Struktur der Quelle, sonst nichts.
Dass die Silber-Tabellen je Quelle getrennt bleiben, ist Kimballs Staging-Prinzip: Jede Tabelle spiegelt genau eine Quelle. Ob sie dabei technische Quellnamen tragen oder fachlich benannt sind, etwa erp_a_delivery_header statt des kryptischen Originalnamens, ist Namenskonvention und ändert nichts am Ansatz. Eine gemeinsame delivery_header über beide Systeme hinweg wäre dagegen bereits Integration, denn dafür müssten Schlüssel gemappt und Attributkonflikte entschieden werden, und diese Arbeit gehört bei Kimball in den einen Transformationsschritt zwischen Silber und Gold. Dort passiert alles zugleich: Formung, Schlüssel-Mapping, Harmonisierung, Vereinigung der Quellen und der Aufbau der konformierten Dimensionen. Dieser Code ist der Ort, an dem die Plattform ihre Quellen versteht, und er wächst mit jeder Quelle.
Der Hybridansatz behält genau diese Silber-Basis und schiebt eine Stufe dazwischen: je Quelle geformte Objekte in Zielstruktur. Wichtig ist, was diese Stufe nicht ist: kein Integrationslayer. Es wird nichts über Quellen hinweg zusammengeführt, kein Schlüssel zwischen Systemen gemappt, keine Attributentscheidung zwischen Quellen getroffen. Die Stufe formt, je Quelle isoliert: Header und Position zum Geschäftsobjekt joinen, technische Felder ablegen, Granularitäten festlegen, auf Fakt- und Dimensionsform bringen, noch mit den Schlüsseln der jeweiligen Quelle.
Ob diese Stufe fertige Sternform liefert wie oben oder zunächst gejointe Geschäftsobjekte je Quelle, etwa ein erp_a_delivery aus Header und Position, ist eine Designvariante derselben Idee. Die bereinigte Basis bleibt in beiden Fällen stehen, weil Persistenz und Formung zwei verschiedene Aufgaben sind: Die Basis trägt Historie und Audit je Quelle, die geformten Objekte sind eine strukturelle Sicht darauf und können als Views umgesetzt werden.
Der Unterschied zu Kimball liegt nicht auf der Modellachse, das Datenmodell bleibt dimensional, und auch nicht darin, dass eine Schicht vor dem Sternschema existiert, die hat Kimball als Staging auch. Der Unterschied ist, wie viel Formung materialisiert wird: Bei Kimball erledigt der Gold-Schritt Formung und Integration zusammen, beim Hybrid ist die Formung je Quelle vorgezogen und isoliert testbar, und Gold schrumpft auf die dünne semantische Reststufe, Schlüssel mappen, vereinigen, konformieren. Die geformten Objekte wirken dabei als stabile Schnittstellen: Ändert eine Quelle ihre Struktur, wird die Änderung im Modul dieser Quelle absorbiert, solange dessen Ausgabe gleich bleibt, und Union und Mapping bleiben unberührt. Das Muster ist kein Sonderweg: Der offizielle dbt-Leitfaden beschreibt genau diese Schichtung als Staging, Intermediate und Marts und benennt den Kern der Arbeit als Übergang von quellkonformen zu geschäftskonformen Daten. Derselbe Leitfaden zieht allerdings eine Grenze, die auch Kimballs Presentation Area zieht: Zwischenmodelle sind nicht für Endnutzer gedacht. Wer die quellgeformten Objekte als quellreine Sichten öffnet, verlässt an dieser Stelle bewusst die reine Lehre und übernimmt die Verantwortung, dass daraus keine unkonformierten Insellösungen entstehen. Und eine ehrliche Einschränkung gehört dazu: Liefert je Geschäftsobjekt ohnehin nur eine Quelle, fallen Kimball und Hybrid praktisch zusammen. Der Unterschied wird erst real, wenn mehrere Quellen dasselbe Objekt liefern und die Integration tatsächlich anfällt.
Data Vault 2.0 materialisiert die Integration als eigene modellierte Schicht im Silber.
Der Hub ist die eine Stelle, an der beide Quellen auf dieselbe Geschäftsidentität gemappt werden. Die Satellites halten die Quellversionen verlustfrei und historisiert nebeneinander, der Business Vault entscheidet, welche Sicht gilt. Wie die Bausteine im Detail funktionieren und was sie kosten, haben wir im Artikel Data Vault 2.0 auf Azure Databricks beschrieben; hier interessiert nur die Position im Vergleich.
Alle drei Wege enden im selben Gold: einem konformierten Sternschema. Der Unterschied liegt vollständig davor.
Wo die Integrationslogik lebt
Zwei Arbeiten verschwinden in keinem der drei Ansätze. Das Schlüssel-Mapping, also die Feststellung, dass Material 4711 in erp_a dasselbe ist wie MAT-4711 in erp_b. Und die Survivorship-Entscheidung: Beide Quellen liefern eine Materialbezeichnung, eine muss gewinnen. Die Ansätze unterscheiden sich nicht darin, ob diese Logik existiert, sondern wo sie liegt und wie oft sie geschrieben wird.
Bei Kimball liegt sie im Transformationscode und ist von außen unsichtbar. Für den Start ist das der schnellste Weg, denn es entsteht kein einziges Objekt, das nicht direkt der Auswertung dient. Der Preis zeigt sich später: Der Code, der Mapping, Survivorship und Konformierung zugleich erledigt, ist ein Monolith. Jede neue Quelle und jede Quelländerung heißt, diesen Monolithen anzufassen und vollständig zu testen.
Beim Hybrid liegt sie als dünne, sichtbare Stufe im Gold, gestützt auf modulare Silber-Objekte. Neue Quelle heißt: ein neues Silber-Modul plus eine Erweiterung der Union, das Bestehende bleibt unberührt. Läuft ein Quellsystem aus und ein Nachfolger kommt, können beide Welten parallel existieren, jede mit ihren eigenen quellgeformten Objekten. Die Additivität, die Data Vault über neue Satellites und Links erreicht, bekommt der Hybrid auf der Strukturseite fast geschenkt. Was er nicht bekommt: Die Integration wird je konsumierendem Objekt implementiert. Das Material-Mapping steckt in der Union von fact_delivery, noch einmal in dim_material und bei jedem weiteren harmonisierten Objekt wieder. Bei zwei Quellen und einer Handvoll Objekte ist das unerheblich, bei vielen Quellen und vielen Objekten ist es die Stelle, an der Definitionen auseinanderlaufen.
Bei Data Vault 2.0 wird die Integration einmal je Geschäftsobjekt deklariert. Der Hub trägt das Schlüssel-Mapping, die Satellites bewahren beide Quellversionen, der Business Vault fällt die Survivorship-Entscheidung zentral. Jeder Information Mart, der auf dem Hub aufbaut, erbt diese Integration, statt sie zu wiederholen. Data Vault macht die Integrationslogik also nicht kleiner. Es erzwingt, dass sie genau einmal existiert und dass die Eingangsdaten erhalten bleiben, gegen die man sie prüfen kann.
Auf einen Satz gebracht: Kimball vergräbt die Integration im Code, der Hybrid implementiert sie je Objekt, Data Vault deklariert sie einmal im Modell.
Die Grenzen des Hybridansatzes
Der Hybrid wirkt wie der bequeme Mittelweg, hat aber drei Grenzen, die über seine Eignung entscheiden. Wo sein Nutzen nicht anfällt, etwa bei einer Quelle je Geschäftsobjekt, ist der monolithische Kimball-Weg schlicht billiger.
Die erste ist Logik-Drift. Die quellgeformten Objekte heißen fact und dim und laden damit dazu ein, Geschäftslogik aufzunehmen, eine berechnete Kennzahl hier, eine Statusableitung dort. Sobald das passiert, lebt dieselbe Logik in zwei Schichten, einmal je Quelle und einmal harmonisiert im Gold, und nichts im Modell verhindert, dass die Versionen auseinanderlaufen. Die Regel, die den Hybrid trägt, ist deshalb einfach und muss vom Team eingehalten werden: Die quellgeformte Stufe bleibt rein strukturell, Geschäftslogik lebt genau einmal, im Schritt nach Gold. Data Vault erzwingt genau diese Trennung strukturell, denn die Raw Vault ist per Definition nie fachlich interpretiert. Beim Hybrid ist sie eine Konvention.
Die zweite ist die Historisierung. Sie gehört an genau eine Stelle, auf die bereinigten Quelltabellen der Basis, quellgeformte Sternobjekte und Gold leiten sich als jeweils aktuelle Sicht daraus ab. Ob einzelne Gold-Dimensionen zusätzlich eine SCD-Historie tragen, ist wie bei Kimball eine Frage des Use Cases, kein Muss. Wichtig ist nur, nicht zwei konkurrierende Zeitachsen parallel zu pflegen, eine in den quellgeformten und eine in den konformierten Dimensionen, denn das Zusammenführen getrennt gepflegter Verläufe mit korrekten Gültigkeitsintervallen ist genau die Aufgabe, die Data Vault mit PIT-Tabellen strukturell löst und die man sich im Hybrid nicht freiwillig einhandeln sollte.
Die dritte ist die Skalengrenze. Weil das Schlüssel-Mapping je Gold-Objekt wiederholt wird, wächst der Pflegeaufwand mit dem Produkt aus Quellen und harmonisierten Objekten. Aus unseren Projekten heraus trägt der Hybrid bis etwa vier bis fünf strukturell verschiedene Quellsysteme; darüber ist die einmal deklarierte Integration von Data Vault die verlässlichere Wahl. Und eine Beobachtung aus der Praxis als Warnung: Plattformen, die bei den quellgeformten Sternen stehen bleiben und die Konformierung in Semantikmodelle und Berichte verlagern, haben die Integration nicht gespart, sondern unsichtbar gemacht, mit den Folgen, die wir in Business-Logik im BI-Tool beschrieben haben.
Was bei der Modellierung auf Azure Databricks zu beachten ist
Die Medallion-Schichtung von Azure Databricks gibt die Zuordnung vor, entscheidet die Frage aber nicht. Die Dokumentation beschreibt den Gold Layer als die Schicht, in der für Reporting und Analytics dimensional modelliert wird, und verortet den Beginn der Datenmodellierung im Silver Layer. Genau dort trennt sich, was Medallion offenlässt: ob im Silber bereinigte Quelltabellen, quellgeformte Sternobjekte oder ein Vault liegen. Dass eine Plattform Bronze, Silber und Gold hat, ist noch kein Datenmodell, das haben wir in Medallion ist kein Datenmodell ausgeführt.
Ein Einwand kommt auf Azure Databricks verlässlich: Delta Time Travel historisiere doch bereits, ein historisiertes Silber sei deshalb überflüssig. Das verwechselt zwei Dinge. Time Travel ist an Aufbewahrungsfristen gebunden, standardmäßig sieben Tage für die Datendateien und 30 Tage für das Transaktionslog, und die Dokumentation rät ausdrücklich davon ab, die Tabellenhistorie als langfristige Archivlösung zu verwenden. Time Travel ist ein Betriebswerkzeug für Rollbacks und kurzfristige Vergleiche je Tabelle. Fachliche Historisierung, also die Frage, welche Materialbezeichnung am Jahresultimo galt, gehört in das Datenmodell, in welchem der drei Ansätze auch immer.
Für die Umsetzung selbst ändert die Wahl wenig an den Werkzeugen: Alle drei Wege laufen auf Delta Lake, werden über Unity Catalog governt und lassen sich mit dbt oder Lakeflow Declarative Pipelines bauen. Für den Data-Vault-Weg nimmt das dbt-Paket datavault4dbt, das Databricks als Plattform unterstützt, einen großen Teil der Generierungsarbeit für Hubs, Links, Satellites und PIT-Tabellen ab.
Ein Blick nach vorn gehört in diese Entscheidung ebenfalls: Mit Unity Catalog Metric Views verlagert Databricks die Definition von Geschäftskennzahlen in die Plattform, als zentral definierte, wiederverwendbare Metriken über den Gold-Strukturen. Je mehr Konsum über solche deklarierten Metriken läuft, und je mehr davon durch AI-Werkzeuge wie natürlichsprachige Abfragen entsteht, desto mehr wird das konformierte Sternschema zur einzigen Stelle, an der Integration physisch stattfinden muss, und desto teurer wird jede Harmonisierung, die stattdessen verstreut in BI-Tools liegt. Ein sauber modelliertes, dokumentiertes Gold ist damit zugleich die beste Schnittstelle für LLM-gestützte Analytik, denn ein Assistent kann niemanden fragen, was ein kryptisches Quellfeld bedeutet.
Entscheidungsmatrix: wann welcher Ansatz
Die Wahl folgt aus dem Kontext, nicht aus einer Methodenpräferenz. Die Kriterien lassen sich als Geschäftsfragen stellen:
| Kriterium | Kimball | Hybrid | Data Vault 2.0 |
|---|---|---|---|
| Wie viele Quellsysteme, wie verschieden? | Wenige Quellsysteme, etwa 1 bis 3, mit ähnlichen Strukturen, zum Beispiel Module desselben Systems | Mehrere Quellsysteme bis etwa 4 bis 5, auch strukturell verschieden, aber klar voneinander abgrenzbar | Viele Quellsysteme, ab etwa 4 bis 5, mit fundamental unterschiedlichen Datenmodellen, die dieselben Geschäftsobjekte verschieden definieren |
| Wie oft ändern sich Quellen, stehen Migrationen an? | Quellen sind stabil, Änderungen sind selten, planbar und mit den Quellteams abgestimmt | Änderungen kommen regelmäßig vor, betreffen aber jeweils eine Quelle, typisch ist eine anstehende Systemablösung mit Parallelbetrieb von Alt und Neu | Häufige, unkoordinierte Schema-Änderungen aus mehreren Richtungen, gegebenenfalls mehrere Migrationen gleichzeitig |
| Welche Anforderungen bestehen an Historisierung und Audit? | Aktuelle Daten genügen, Rückblicke sind die Ausnahme und werden je Dimension bewusst als SCD entworfen | Historie wird einmal auf den bereinigten Quelltabellen mitgeschrieben und reicht für Nachvollziehbarkeit und Reprocessing aus | Vollständige, quellübergreifend integrierte Historie ist Pflicht, etwa für Audits mit Point-in-Time-Rekonstruktion über alle Objekte |
| Wer nutzt die Plattform, mit wie vielen Sichten? | Abteilungseigene Plattform, zum Beispiel für Supply Chain oder Finance, mit einer geltenden Business-Interpretation | Eine Abteilung oder wenige eng verbundene Teams; einzelne Konsumenten brauchen zusätzlich die ungemischte Sicht eines einzelnen Quellsystems, und die quellgeformten Objekte liefern genau diese Sicht ohne Mehraufwand | Zentrale Plattform über mehrere Abteilungen hinweg, die dieselben Geschäftsobjekte unterschiedlich interpretieren und harmonisiert brauchen |
| Welche Kompetenz braucht das Team? | Dimensionale Modellierung ist seit Jahrzehnten der akzeptierte Standard, das Wissen ist im Team und am Markt breit verfügbar | Dasselbe dimensionale Wissen genügt; dazu kommt Konventionstreue, denn die Trennung von struktureller und fachlicher Schicht hält kein Werkzeug ein, nur das Team | Erfahrung ist wegen der Komplexität wichtig, Fehler im Hub- oder Link-Design sind teuer; die Umsetzung gehört generiert, etwa mit datavault4dbt, von Hand ist sie zu aufwendig und fehleranfällig |
| Wie schnell muss das erste Ergebnis stehen? | Erste Auswertungen stehen am schnellsten, weil ausschließlich Objekte entstehen, die direkt der Auswertung dienen | Kaum langsamer als Kimball, denn die zusätzliche Stufe ist rein strukturell und weitgehend schematisch; dafür ist das Wachstum um neue Quellen von Anfang an vorbereitet | Höchster Initialaufwand, weil Raw Vault und Business Vault vor dem ersten Mart stehen; er amortisiert sich über Laufzeit und Quellenzahl |
Die Bewertung je Kriterium ist unsere Einschätzung aus Projekten, keine Messung. Sie ersetzt nicht die Prüfung am konkreten Ist-Stand aus Quellen, Volatilität, Audit-Anforderungen und Team.
14 Fragen, drei bis vier Minuten. Sie erhalten eine begründete Ersteinschätzung mit den Abwägungen, die dazugehören.
Fazit
Kimball, der Hybrid und Data Vault 2.0 liefern am Ende dasselbe Sternschema. Sie unterscheiden sich darin, wo die Integrationslogik lebt: im Transformationscode, als sichtbare Stufe je Gold-Objekt oder einmal deklariert im Modell. Kimball ist die pragmatische Wahl bei wenigen, stabilen Quellen und einer abteilungseigenen Plattform. Der Hybrid, dimensional im Modell und quellmodular in der Architektur, trägt, wenn Quellen sich quellweise ändern und Migrationen absehbar sind, verlangt aber Konventionstreue bei der Trennung von Struktur und Geschäftslogik. Data Vault 2.0 lohnt sich, wenn viele heterogene Quellen, häufige Änderungen und harte Historisierungspflichten zusammenkommen. Es gibt keine pauschal richtige Wahl, die Entscheidung folgt aus dem Kontext. Im Greenfield kostet sie nichts, im laufenden Betrieb ein Vielfaches. Deshalb gehört sie an den Anfang.
Falls Sie gerade vor genau so einer Implementierung stehen, kommen Sie gerne auf uns zu. Wir unterstützen Sie beim Aufbau moderner Data- und AI-Plattformen auf Azure Databricks.
Erstgespräch vereinbaren