Im thinkBI Podcast ging es zuletzt um das Sternschema als Grundform analytischer Modellierung. Daraus ergibt sich die nächste, eigentlich wichtigere Frage: Was tun wir mit den Fällen, in denen die klare Grundregel nicht mehr ganz ausreicht? Genau dort wird Datenmodellierung interessant.
Denn ein gutes Modell ist nicht deshalb gut, weil es jede Regel dogmatisch durchzieht. Es ist gut, weil es Grundregeln kennt und seine Ausnahmen bewusst behandelt. Die Folge macht das an mehreren Sonderfällen sichtbar: sehr kleine Dimensionen mit Status- oder Ja-Nein-Ausprägungen, transaktionsnahe Beleginformationen, Many-to-many-Beziehungen und Kennzahlen, die erst im Moment der Auswertung wirklich sinnvoll werden.
Die Grundregel bleibt einfach
Die Ausgangsregel des Sternschemas ist klar: Dimensionen liefern Kontext, Fakten liefern Zahlen. Dimensionstabellen beschreiben, was etwas ist, in welchen Kategorien es gelesen werden kann und über welche Merkmale es ausgewertet wird. Faktentabellen enthalten die Bewegungen, Transaktionen und Kennzahlen, die analysiert werden sollen.
Das ist die Ordnung, an der sich viele analytische Modelle orientieren. Sie ist nicht kompliziert, aber tragfähig. Genau deshalb lohnt es sich, die Abweichungen davon nicht als Schwäche zu behandeln, sondern als Test für Modellreife. Denn sobald ein Modell zu viele kleine Sondertabellen erzeugt oder eine Information nur noch technisch abbildet, aber analytisch nichts mehr trägt, wird die Grundidee wieder unscharf.
Kleine Dimensionen sind nicht automatisch gute Dimensionen
Ein erster Sonderfall sind sehr kleine Dimensionen. Wenn es im Kern nur um wenige Statuswerte, Ja-Nein-Kombinationen oder ähnlich knappe Ausprägungen geht, ist eine eigene Dimension oft nicht die beste Lösung. Dann entsteht schnell eine Vielzahl kleiner Tabellen, die für sich genommen korrekt aussehen, dem Modell aber mehr Komplexität als Nutzen bringen.
Genau hier setzt die Idee der Junk Dimension an. Verschiedene Statusfelder werden in einer größeren Dimension zusammengeführt, damit sie gemeinsam gefiltert und ausgewertet werden können. Das Ziel ist nicht, mehr Tabellen zu schaffen, sondern die verstreuten Statusinformationen in eine Modellform zu bringen, die sich analytisch sinnvoll verknüpfen lässt.
Nicht jede fachliche Information verdient automatisch ihre eigene Tabelle. Die wichtigere Frage ist, ob das Modell dadurch klarer, einfacher und besser nutzbar wird.
Wenn Trennung künstlich wird
Ein zweiter Sonderfall ist die Degenerated Dimension. Hier geht es um Informationen, die sehr nah an der Transaktion liegen und im Grunde keinen eigenen, auswertbaren Dimensioncharakter entwickeln. Wenn für jeden Fakt nahezu ein eigener Dimensionsschlüssel existiert, lohnt sich die Auslagerung in eine separate Dimension oft nicht.
Dann bleibt die Information im Fakt. Nicht aus Bequemlichkeit, sondern weil eine eigene Dimension das Modell nur künstlich aufblasen würde. Der Gedanke ist einfach: Wenn eine Information fast 1:1 an den Fakt gebunden ist, braucht sie keine zusätzliche analytische Bühne.
Das ist ein wichtiger Gegenakzent zu Modellierungsansätzen, die aus jeder eindeutigen Nummer sofort eine eigene Dimension machen. Nicht alles, was eindeutig ist, muss auch eine eigene Struktur bekommen. Manchmal ist die Faktentabelle der sauberere Ort.
Wenn die Beziehung wichtiger ist als die Zahl
Noch interessanter wird es bei Many-to-many-Beziehungen. Hier reicht die normale Logik von einer Dimension zu einem Fakt nicht mehr aus, weil mehrere fachliche Zuordnungen gleichzeitig eine Rolle spielen. In solchen Fällen kann eine Factless Fact sinnvoll sein.
Sie trägt nicht in erster Linie eine eigene Zahl, sondern die Beziehung selbst. Das Beispiel mit einem gemeinsamen Konto macht den Punkt gut sichtbar: Wenn zwei Personen als Kontoinhaber geführt werden, bedeutet das nicht, dass sich der Kontostand verdoppelt. Die Beziehung ist da, die Zahl bleibt dieselbe. Genau deshalb ist mehrfaches Zählen hier falsch.
Dasselbe gilt in Unternehmen, wenn etwa Vertriebsmitarbeiter und Kunden in mehr als einer fachlichen Beziehung zueinanderstehen und der Umsatz nicht einfach verdoppelt oder willkürlich aufgeteilt werden darf. Die Factless Fact hält die Zuordnung sichtbar, ohne die Zahl künstlich zu verfälschen. Sie zeigt die Verbindung, nicht die doppelte Menge.
Hier liegt eine der wichtigsten strukturellen Klarstellungen der Folge: Nicht jede Faktentabelle muss Werte tragen. Manchmal trägt sie vor allem Zusammenhang. Und gerade dieser Zusammenhang verhindert spätere Interpretationsfehler.
Kennzahlen gehören nicht immer in die Tabelle
Der letzte große Punkt betrifft Kennzahlen, die sich erst aus dem Nutzungskontext ergeben. Prozentwerte, Anteile am Gesamt oder ähnliche relationale Kennzahlen sollte man nicht blind in die Faktentabelle schreiben. Denn ihr Wert hängt davon ab, welche Filter der Nutzer setzt, welchen Zeitraum er betrachtet und welche Vergleichsmenge gerade relevant ist.
Solche Kennzahlen gehören typischerweise zur Laufzeit berechnet. Erst dann kennt das Modell den tatsächlichen Kontext. Würde man sie vorher festschreiben, würde man eine scheinbar präzise Zahl speichern, die in vielen Nutzungssituationen gar nicht mehr stimmt.
Gleichzeitig zieht die Folge die Grenze nicht unnötig streng. Alles, was sich schon beim Laden sinnvoll vorbereiten lässt, sollte auch dort vorbereitet werden. Die Grundhaltung ist klar: So viel Komplexität wie möglich nach unten ziehen, so viel Dynamik wie nötig im Bericht lassen. Das entlastet das Frontend, macht Berechnungen robuster und hält die Logik näher an der Quelle.
Ausnahme ist nicht Beliebigkeit
Die eigentliche Pointe liegt deshalb nicht in den einzelnen Sonderfällen, sondern in der Ordnung dahinter. Ein gutes Datenmodell folgt einfachen Regeln. Aber es weiß auch, wann die Regel zu grob wäre. Dann wird nicht improvisiert, sondern gezielt ummodelliert.
Das ist wichtig, weil BI schnell dogmatisch werden kann. Wer nur noch nach Schema baut, verliert den Blick für die fachliche Situation. Wer dagegen jede Abweichung als Sonderfall behandelt, verliert wiederum die Struktur. Die tragfähige Position liegt dazwischen: Regelwerk im Kern, begründete Ausnahme am Rand.
So betrachtet sind Junk Dimension, Degenerated Dimension, Factless Fact und Laufzeitberechnung keine exotischen Randthemen. Sie sind Prüfsteine für die Qualität eines Modells. Sie zeigen, ob ein Datenmodell wirklich verstanden hat, was es beschreiben soll.
Vielleicht ist genau das die ruhigste Zuspitzung dieser Folge: Ein gutes Datenmodell ist nicht das Modell mit den wenigsten Sonderfällen. Es ist das Modell, das seine Sonderfälle sauber beherrscht.
🎧 Die komplette Folge findest du im thinkBI Podcast.
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/
