Kimball Data Modelling - Fakten & Dimensionen meistern

Was hinter dem Kimball-Ansatz fachlich steckt

Ich sehe den Ansatz als pragmatische Antwort auf eine einfache Frage: Wie kommen Fachanwender schnell zu verlässlichen Analysen, ohne ein monolithisches Modell abwarten zu müssen? Der Kern ist dimensional modelling: Messungen werden in Faktentabellen gespeichert, der fachliche Kontext in Dimensionstabellen. Die Kimball Group beschreibt das als bus-orientierte Architektur, die auf Geschäftsprozessen und gemeinsam genutzten Dimensionen aufbaut.

Der Unterschied zu rein normalisierten Designs liegt nicht in der Disziplin, sondern im Ziel. Kimball will Abfragen vereinfachen, Kennzahlen konsistent machen und Daten so schneiden, dass BI-Tools ohne komplizierte Join-Ketten arbeiten können. Genau deshalb passt der Ansatz so gut zu Reporting, Dashboarding und Self-Service-Analyse. Als Nächstes lohnt sich der Blick auf die Bausteine, aus denen dieses Modell tatsächlich besteht.

Die Bausteine eines guten Sternschemas

Ein dimensionales Modell wirkt auf den ersten Blick schlicht, ist aber präziser als viele komplexe Normalformen.

Grain zuerst ist die Regel, die ich am strengsten halte. Wenn eine Faktentabelle etwa jede Verkaufsposition pro Artikel, Kunde und Tag beschreibt, dann darf später keine Monatsaggregation stillschweigend in dieselbe Tabelle rutschen. Genau an dieser Stelle entstehen sonst Berichte, die formal laufen, fachlich aber nicht mehr stimmen. Die Stabilität des Sternschemas hängt also weniger an hübschen Diagrammen als an disziplinierter Granularität, und daraus folgt direkt die Frage nach dem eigentlichen Entwurfsprozess.

So entwerfe ich ein Warehouse nach Kimball Schritt für Schritt

Der Entwurf ist weniger Kunst als Reihenfolge. Ich gehe in der Praxis meist so vor:

1. Geschäftsprozess festlegen - etwa Verkäufe, Retouren, Lieferungen oder Servicefälle.
2. Grain definieren - eine Zeile pro Verkaufsposten, pro Lagerbewegung oder pro Support-Ticket-Status.
3. Dimensionen bestimmen - also Zeit, Produkt, Kunde, Region, Vertriebskanal, Mitarbeiter und ähnliche Beschreibungsebenen.
4. Fakten auswählen - Mengen, Umsätze, Rabatte, Laufzeiten, Kosten oder Statuswechsel.
5. Historie bewusst modellieren - bei veränderlichen Stammdaten oft als Type-2-Dimension mit neuer Zeile, neuem Surrogatschlüssel und drei Zusatzspalten: Gültig-von, Gültig-bis und Current-Flag.

Diese Reihenfolge ist wichtig, weil sie verhindert, dass das Modell von Berichtsanforderungen oder ETL-Zufällen dominiert wird. Die Kimball Group betont seit Jahren genau diese Inkrementalität: erst den Prozess, dann die passenden Dimensionen und Fakten, nicht umgekehrt. Wenn ich das sauber halte, bleibt das Warehouse erweiterbar, ohne dass jedes neue Fachthema einen Umbau auslöst. Damit ist der Weg dorthin klar, aber noch nicht die Frage beantwortet, warum sich der Aufwand im Alltag tatsächlich lohnt.

Warum der Ansatz im Analysealltag so gut funktioniert

Der größte Vorteil ist aus meiner Sicht nicht nur die Geschwindigkeit, sondern die Verständlichkeit. Analysten, Fachbereiche und BI-Tools sprechen im Sternschema über dieselben Begriffe, weil die Dimensionen bereits fachlich formuliert sind. Dadurch werden Kennzahlen robuster, Drill-downs leichter und Self-Service-Berichte weniger fehleranfällig.

• Schnellere Abfragen - Sternschemata reduzieren die Join-Komplexität gegenüber stark normalisierten Modellen.
• Konsistente KPIs - conformed dimensions verhindern, dass Kunde, Produkt oder Region je nach Bericht anders gezählt werden.
• Saubere Historie - Type-2-Dimensionen bewahren, was zum Zeitpunkt des Ereignisses gültig war.
• Inkrementelle Lieferung - ein Data Mart pro Geschäftsprozess kann früh produktiv gehen, ohne auf ein Gesamtmodell zu warten.
• Bessere Governance - fachliche Definitionen liegen nicht verstreut in einzelnen Reports, sondern im Modell selbst.

Für moderne Plattformen gilt das genauso wie für klassische Warehouses: Der Ansatz ist nicht altmodisch, sondern strukturiert. Gerade wenn Teams viele Dashboards, Metriken und operative Entscheidungen auf denselben Daten aufbauen, zahlt sich die disziplinierte Trennung von Messwert und Kontext schnell aus. Das heißt aber nicht, dass jede Umsetzung automatisch gut wird, denn die typischen Schwachstellen sind ziemlich vorhersehbar.

Wo die Methode an Grenzen stößt und welche Fehler ich oft sehe

Die häufigsten Probleme sind nicht spektakulär, aber teuer. Sie beginnen fast immer mit einem unklaren Grain oder mit Dimensionen, die zu früh zu stark zerlegt werden. Wenn ich im Review schon nach wenigen Minuten erklären muss, ob eine Zeile einen Auftrag, eine Position oder einen Statuswechsel beschreibt, ist das Modell noch nicht belastbar.

• Gemischte Granularität - Tages-, Monats- und Ereignisebene in einer Faktentabelle führen fast immer zu Dubletten oder falschen Aggregationen.
• Zu viele einzelne Mini-Dimensionen - viele kleine Flags gehören oft besser in eine Junk-Dimension als in ein Bündel isolierter Tabellen.
• Schlechte Historisierung - Änderungen an Kunde oder Produkt werden überschrieben, obwohl fachlich ein Verlauf nötig wäre.
• NULLs statt Default-Zeilen - unbekannte oder noch nicht geladene Dimensionen gehören technisch sauber behandelt, nicht improvisiert.
• Viele-zu-viele-Beziehungen ohne Bridge Table - mehrwertige Dimensionen brauchen eine explizite Brückentabelle, sonst wird die Auswertung fachlich unsauber.
• Centipede-Fact-Designs - wenn eine Faktentabelle von zu vielen hierarchisch getrennten Dimensionen abhängt, wird das Modell unnötig schwer und langsam wartbar.

Mein pragmatischer Maßstab ist einfach: Wenn das Modell die Fachlogik nicht mehr erklärt, sondern versteckt, ist es zu weit vom Kimball-Gedanken entfernt. Genau deshalb lohnt sich ein Vergleich mit alternativen Warehouse-Stilen, bevor man sich auf eine Architektur festlegt.

Kimball gegen stark normalisierte Warehouses

Ich behandle das selten als Glaubensfrage. Beide Ansätze können korrekt sein, aber sie optimieren auf unterschiedliche Ziele. Für Analyse und Reporting gewinnt meist das dimensional aufgebaute Modell, während ein stark normalisiertes Warehouse eher dort punktet, wo zentrale Harmonisierung und maximale Modellreinheit im Vordergrund stehen.

Meine Daumenregel ist nüchtern: Wenn der primäre Wert in der Auswertung liegt, starte ich dimensional. Wenn zuerst die unternehmensweite Harmonisierung gelöst werden muss, kann ein stärker normalisierter Layer sinnvoll sein, bevor später analytische Schichten darauf aufsetzen. Die Architektur folgt also nicht der Mode, sondern der Frage, was das Team in den nächsten 12 bis 24 Monaten wirklich liefern muss.

Die drei Entscheidungen, die ich bei neuen Modellen nie aufschiebe

Wenn ich ein neues Warehouse oder einen neuen Data Mart beginne, sichere ich zuerst drei Dinge ab: die fachliche Granularität, die historische Behandlung der Dimensionen und die Liste der gemeinsam genutzten Dimensionen. Diese drei Punkte wirken unspektakulär, entscheiden aber darüber, ob ein Modell nach sechs Monaten noch erweiterbar ist oder bei der ersten Fachanfrage auseinanderfällt.

• Grain schriftlich festhalten - am besten in einem Satz, den Fachbereich und Technik gleichermaßen verstehen.
• Historienlogik festlegen - Type 1 für reine Korrekturen, Type 2 für fachlich relevante Verläufe.
• Conformed dimensions versionieren - wenn eine gemeinsame Dimension sich ändert, muss die Bedeutung über alle Fakten hinweg stabil bleiben.
• Messwerte prüfbar machen - jede Kennzahl braucht eine klare fachliche Definition, nicht nur eine Spalte im Modell.