Im thinkBI Podcast ging es zuletzt darum, wie Sternschema und Bus-Matrix analytische Klarheit schaffen. Die nächste sinnvolle Frage lautet deshalb: Was passiert eigentlich, wenn wir davon abweichen? Genau darüber lohnt es sich zu sprechen, denn viele Missverständnisse in BI entstehen nicht an der Kennzahl, sondern an der Form des Modells.
Oberflächlich wirkt die Frage nach Snowflake-Schema, One Big Table oder Galaxy-Modell technisch. Tatsächlich geht es um etwas Grundsätzlicheres: Welchem Zweck folgt ein Datenmodell überhaupt? Wer diese Frage nicht sauber beantwortet, baut Analyse schnell in der Logik des Vorsystems. Und genau dort beginnen die Probleme.
Wenn Struktur nur aus Tabellen abgeleitet wird
Das sichtbare Thema ist zunächst einfach. Es gibt verschiedene Modellierungsformen. Das Star-Schema ist bekannt. Das Snowflake-Schema verzweigt Dimensionen weiter. One Big Table bündelt möglichst alles in einer breiten Tabelle. Ein Galaxy-Modell beschreibt mehrere Faktenbereiche, die gemeinsam ein größeres analytisches Modell bilden.
Technisch kann man all das bauen. Die wichtigere Frage ist aber, was man sich damit einkauft.
Das Snowflake-Schema verspricht zunächst Ordnung durch Zerlegung. Statt eine Dimension breiter zu machen, wird sie weiter aufgeteilt. Ein Verkäufer kann dann etwa nicht direkt in einer Kundendimension aufgehen, sondern als eigene Dimension an die Kundendimension angebunden werden. Das kann Wiederverwendbarkeit schaffen und dafür sorgen, dass auch Werte sichtbar bleiben, die in einer direkt eingebetteten Struktur sonst verschwinden würden.
Gleichzeitig wächst aber die Komplexität des Modells. Beziehungen werden schwerer lesbar. Verknüpfungsreihenfolgen werden relevanter. Die Modelllogik ist nicht mehr so unmittelbar erkennbar wie im klassischen Stern. Aus analytischer Sicht ist das kein kleiner Preis, denn ein Modell soll nicht nur korrekt sein. Es soll auch verständlich bleiben.
Die breite Tabelle löst Verknüpfungen, aber nicht Bedeutung
Am anderen Ende steht die One Big Table. Ihr Versprechen ist Vermeidung von Komplexität. Keine Beziehungslogik, keine Frage nach Join-Pfaden, keine Unsicherheit darüber, wie Tabellen zusammenhängen. Alles steht in einer großen Struktur bereit.
Das klingt pragmatisch. Oft ist es das auch, zumindest kurzfristig. Nur verschiebt sich das Problem.
Denn mit der breiten Tabelle verschwindet nicht nur Modellkomplexität. Es verschwindet auch Kontext. Wenn Produkt, Kunde, Verkäufer, Datum und Bewegungsdaten nur noch Spalten einer großen Tabelle sind, ist ihre Rolle nicht mehr durch das Modell selbst geklärt. Dann muss jede Spalte einzeln verstanden, interpretiert und eingeordnet werden.
Genau das ist analytisch riskant. Eine Dimension ist nicht nur ein technischer Container. Sie hält einen fachlichen Zusammenhang zusammen. Wer von einer Kundendimension spricht, macht damit bereits sichtbar, dass hier ein bestimmtes Objekt mit bestimmter Bedeutung beschrieben wird. In einer One Big Table ist dieser Zusammenhang schwächer ausgeprägt. Das Modell wird einfacher im Zugriff, aber ärmer in seiner semantischen Führung.
Das eigentliche Problem liegt tiefer als die Modellform
Damit kommen wir zur wichtigeren Unterscheidung: transaktionale Systeme und analytische Systeme verfolgen unterschiedliche Zwecke.
In operativen Vorsystemen sind Datenmodelle darauf ausgelegt, einzelne Datensätze sauber zu schreiben, zu ändern und konsistent zu halten. Deshalb sind sie häufig normalisiert. Themen werden in einzelne Tabellen zerlegt, damit Änderungen lokal möglich bleiben. Wenn sich etwa der Name eines Verkäufers ändert, soll er an einer Stelle angepasst werden und danach überall konsistent erscheinen. Diese Logik ist richtig, solange das System tägliche Prozesse effizient unterstützen soll.
Analyse folgt aber einer anderen Logik. Dort geht es nicht primär darum, einzelne Datensätze laufend zu aktualisieren. Es geht darum, große Mengen stabil zu lesen, auszuwerten und in wiederkehrende Perspektiven zu bringen. Genau deshalb dürfen analytische Modelle sich andere Strukturen leisten. Sie dürfen Zusammenhänge denormalisieren, Dimensionen größer machen und Fakten zentral bündeln, weil ihr Ziel nicht Schreibökonomie ist, sondern Erkenntnisfähigkeit.
Das ist keine technische Feinheit. Das ist ein Perspektivwechsel. Wer analytische Modelle nach der Logik normalisierter Vorsysteme baut, übernimmt unbemerkt einen Zweck, den Analyse gar nicht hat.
Gute BI-Modelle sind auf Lesen optimiert
Hier liegt die Stärke des Star-Schemas. Nicht weil es dogmatisch immer richtig wäre, sondern weil es einen guten Kompromiss schafft. In der Mitte stehen die Fakten. Darum herum liegen die Dimensionen als stabile Kontexträume. Das Modell macht damit sichtbar, was gemessen wird und in welchen Perspektiven diese Messung gelesen werden kann.
Genau diese Lesbarkeit ist entscheidend. Sie hilft bei Performance. Sie hilft bei Wiederverwendbarkeit. Vor allem aber hilft sie dabei, dass Menschen ein Modell verstehen können, ohne bei jeder Analyse erst die versteckten Beziehungen rekonstruieren zu müssen.
Das Snowflake-Schema kann in einzelnen Fällen sinnvoll sein. One Big Table kann pragmatische Vorteile haben. Auch mehrere Faktenbereiche in einem größeren Gesamtmodell sind selbstverständlich legitim. Problematisch wird es erst dort, wo die Modellform den eigentlichen Zweck verdeckt. Dann bauen wir entweder zu nah an der Quellsystemlogik oder zu flach in Richtung bloßer Tabellennutzung.
Beides ist eine Verfehlung der analytischen Aufgabe.
Modellierung heißt, dem Datenmodell einen Zweck zu geben
Deshalb lohnt sich die ruhigere Zuspitzung dieser Folge: Die Frage ist nicht zuerst, welches Muster moderner oder einfacher wirkt. Die Frage ist, welche Form dem Zweck der Analyse dient.
Ein transaktionales System muss Veränderungen effizient abwickeln. Ein analytisches System muss Zusammenhänge belastbar lesbar machen. Dafür braucht es andere Prioritäten, andere Datenbanken, andere Speicherlogiken und vor allem eine andere Modellierungsentscheidung.
BI ist an dieser Stelle keine Kopie des Vorsystems. BI ist eine bewusste Umformung. Sie löst Beziehungen auf, verdichtet Kontexte in Dimensionen und ordnet Bewegungsdaten so, dass Analyse nicht nur möglich, sondern verständlich wird.
Vielleicht ist genau das die wichtigste Klarstellung: Ein gutes Analysemodell ist nicht jenes, das dem Quellsystem am ähnlichsten bleibt. Es ist jenes, das seinem eigenen Zweck am konsequentesten folgt.
🎧 Die komplette Folge findest du im thinkBI Podcast.
thinkBI Essentials
Kernaussagen
- Analytische Datenmodelle dürfen nicht nach der Logik transaktionaler Vorsysteme gebaut werden, weil sie einem anderen Zweck dienen.
- Die Modellform ist keine rein technische Entscheidung, sondern legt fest, wie verständlich, wiederverwendbar und lesbar Analyse später wird.
- Eine One Big Table reduziert Verknüpfungen, schwächt aber oft die semantische Ordnung von Objekten und Kontexten.
- Ein Snowflake-Schema kann Wiederverwendbarkeit erhöhen, erkauft das aber mit mehr struktureller Komplexität.
- Das Star-Schema ist oft stark, weil es Kennzahlen und Kontexträume so ordnet, dass Analyse fachlich klar und praktisch nutzbar bleibt.
Begriffe aus diesem Beitrag
Transaktionales System
Ein transaktionales System ist auf das Schreiben, Ändern und konsistente Halten einzelner Datensätze ausgelegt. Seine Modelllogik folgt operativen Prozessen und ist deshalb nicht automatisch für analytische Auswertungen geeignet.
Analytisches Datenmodell
Ein analytisches Datenmodell ist darauf ausgelegt, Daten stabil lesbar, auswertbar und wiederverwendbar zu machen. Es priorisiert Verständnis, Kontext und Performance für Analyse statt Pflegeeffizienz einzelner Datensätze.
One Big Table
One Big Table bezeichnet eine Modellform, in der viele fachliche Inhalte in einer breiten Tabelle zusammengeführt werden. Sie vereinfacht den Zugriff kurzfristig, macht aber Rollen, Objekte und Kontexte oft weniger klar erkennbar.
Snowflake-Schema
Ein Snowflake-Schema ist eine stärker verzweigte Form analytischer Modellierung, bei der Dimensionen weiter aufgeteilt werden. Das kann bestimmte Strukturen sauberer abbilden, erhöht aber die Komplexität von Beziehungen und Lesbarkeit im Modell.
Weiterdenken
- Wo übernehmen wir in diesem BI-Modell gerade noch unbemerkt die Logik des Vorsystems?
- Welche Modellvereinfachung macht den Zugriff leichter, schwächt aber den fachlichen Kontext?
- Verwandtes Thema: Star-Schema als Lesestruktur für Analyse
- Verwandtes Thema: Normalisierung, Denormalisierung und Modellzweck
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
