Das Datenmodell vor dem Diagramm: Star-Schema fürs Controlling

Wenn ein Dashboard langsam ist, widersprüchliche Zahlen zeigt oder sich nicht erweitern lässt, liegt die Ursache fast nie im Visual. Sie liegt im Datenmodell darunter. Und das häufigste Anti-Pattern ist die eine breite Tabelle, in die alles hineingequetscht wurde.

Die Ausgangslage

Ein Controlling-Bericht wurde auf einer einzigen, sehr breiten Tabelle aufgebaut. Ein flacher Export, in dem Kennzahlen, Perioden, Organisationsmerkmale und Stammdaten nebeneinander standen. Anfangs funktioniert das. Mit der zweiten Anforderung. „können wir das auch nach Region filtern, und im Vorjahresvergleich?". Beginnt es zu bröckeln: Filter wirken nicht wie erwartet, Summen stimmen je nach Aufriss nicht, und jede Erweiterung fühlt sich an wie ein Eingriff am offenen Herzen.

Das Problem: flache Tabelle vermischt Fakten und Attribute

Eine flache Tabelle wirft zwei Dinge durcheinander, die getrennt gehören: messbare Ereignisse (Fakten) und beschreibende Merkmale (Dimensionen). Daraus folgt:

• Filter sind mehrdeutig, weil dasselbe Attribut in vielen Zeilen wiederholt vorkommt.
• Time Intelligence (YTD, Vorjahr) braucht eine saubere Kalenderdimension. Die in der flachen Tabelle fehlt.
• Jede neue Kennzahl oder Dimension bedeutet, die breite Tabelle umzubauen, statt etwas hinzuzufügen.

Die Lösung: Star-Schema

Im Star-Schema steht in der Mitte eine (oder wenige) Faktentabelle mit den messbaren Werten. Drumherum liegen Dimensionen mit den beschreibenden Merkmalen, jeweils über eine M:1-Beziehung verbunden:

Die Vorteile sind unmittelbar: Filter propagieren eindeutig von der Dimension in die Fakten, eine als Datumstabelle markierte Kalenderdimension macht Time Intelligence robust, und Erweiterungen sind additiv. Eine neue Dimension wird angehängt, nicht eingebaut.

Die Stolperfallen

1. Die Dimension muss auf ihrem Schlüssel eindeutig sein. Das ist die Regel, an der es am häufigsten scheitert. Wird eine Dimension aus einer Bewegungs- oder Ende-Faktquelle gebaut (etwa eine Vertragsdimension aus einer „Vertragsende"-Tabelle), ist der Schlüssel nicht eindeutig. Die Beziehung fächert auf und liefert pro Schlüssel mehrere Attributwerte im Visual. Dimensionen kommen aus einem dedizierten Stamm­datensatz, nicht aus einem Ereignis-Fakt. Schnelltest: Gibt es einen Schlüssel mit mehr als einer Zeile in der Dimension?

2. Logik gehört nicht in die Fakten. Sortierhilfen, relative Flags („aktueller Monat") und Kalenderlogik liegen in der Kalenderdimension, nicht als berechnete Spalten in der Faktentabelle.

3. Namenskonventionen früh festlegen. Neue Spalten konsistent benennen (z. B. PascalCase), aus dem Warehouse übernommene Spalten so lassen, wie sie kommen. Uneinheitliche Benennung rächt sich, sobald mehrere Modelle dieselben Dimensionen teilen.

Das Takeaway

„Datenmodell vor Diagramm" ist keine Stilfrage, sondern die Reihenfolge, die über Performance, Konsistenz und Erweiterbarkeit entscheidet. Ein sauberes Star-Schema. Zentrale Fakten, eindeutige Dimensionen, eine Kalenderdimension. Macht spätere Anforderungen zu einfachen Ergänzungen statt zu Umbauten. Und es verhindert die stille Doppelzählung, die aus aufgefächerten Dimensionen entsteht. Wer hier eine Stunde mehr investiert, spart sie später vielfach zurück.