top of page
Suche

Flat Table vs. Sternschema

Neulich in einem Projekt bin ich innerlich kurz zusammengezuckt. Aus Databricks kam eine breite Flat Table, sauber vorbereitet, mit Berechnungen und Szenarien. In Power BI sollte sie visualisiert werden. Erst lief alles, dann kamen die bekannten Fragen: unsaubere Zeitachse, Wunsch nach mehr Dynamik, flexiblere Filter. Am Ende war klar: mit der Flat Table kommen wir hier nicht weiter. Also haben wir ein Sternschema gebaut.


Ein paar Wochen später, anderes Meeting, anderes Thema – Performance, Zusammenarbeit zwischen Databricks und Power BI – und dann der Satz:„Mit dem Sternschema habt ihr das doch unnötig kompliziert gemacht, vorher war es viel einfacher.“


Das war kein böser Kommentar. Aber er zeigt perfekt, worum es hier eigentlich geht.



Flat Table vs. Sternschema: Deine Perspektive entscheidet

Wir alle argumentieren aus unserer technischen Sozialisation heraus. Ich sehe ein Sternschema und denke an saubere Semantik, Skalierbarkeit, weniger DAX-Schmerzen.

Jemand anderes sieht dasselbe Modell und denkt an mehr Tabellen, mehr Abhängigkeiten, mehr Erklärungsbedarf.


Das ist kein Wissensproblem, sondern ein Erfahrungsproblem.Du hältst das für sinnvoll, was deine Probleme bisher gelöst hat. Und genau deshalb ist diese Diskussion so emotional – sie greift Identität an, nicht nur Architektur.


Wo gehört der semantische Layer eigentlich hin?

Ein zentraler Konfliktpunkt ist die Frage: Wo entsteht Bedeutung – im Data Warehouse oder im analytischen Modell?


Aus der Analysis-Services- und Power-BI-Welt kommend ist für mich klar: Aggregationen, Filterlogik und Kontext gehören in ein Modell, das dafür gebaut ist. Ich rechne nicht alles vor, weil ich zur Laufzeit flexibel bleiben will.


Wer aus SQL, Databricks oder klassischem DWH kommt, denkt oft genau andersherum. Dort wird Semantik vorbereitet, Views werden gebaut, Aggregationen materialisiert. Das BI-Tool ist dann „nur Visualisierung“. Austauschbar. Kontrollierbar.


Beide Sichtweisen sind in sich konsistent. Sie sind nur unterschiedlich verteilt.


Warum Flat Tables so attraktiv wirken

Flat Tables haben einen riesigen Vorteil: sie sind universell nutzbar.Power BI, Tableau, Excel, irgendwas von SAP – alles kann damit umgehen. Keine Beziehungen, keine Modelllogik, keine Abhängigkeit von einer bestimmten Engine.


Dazu kommt: Excel-Prägung. Viele Fachbereiche kennen ausschließlich flache Tabellen. Filtern, sortieren, Pivot bauen. Beziehungen zwischen Tabellen existieren dort faktisch nur als sichtbare Spalten, die per Lookup hineingezogen wurden.


Ein Modell mit Beziehungen fühlt sich dagegen abstrakt an. Man muss vertrauen, statt sehen.

Und Vertrauen ist im Zweifel schwerer als eine breite Tabelle.


Flat Tables sind nur am Anfang einfach

Die Ironie ist: Flat Tables sind oft nur dann einfach, wenn die Fragen simpel bleiben. Sobald Dynamik ins Spiel kommt, wird es schnell komplex.


Typische Beispiele: Ist vs. Budget mit unterschiedlicher Granularität, tägliche Ist-Daten vs. monatliche Plandaten, Kunde vs. Kundengruppe, Produkt vs. Produktgruppe, Umschalten per Field Parameters, saubere Zeitlogik.


Im Sternschema ist das meist Modellarbeit. Im Flat Table endet man schneller bei zusätzlichen Spalten, künstlichen Hierarchien, Sonderlogik in DAX und virtuellen Tabellen.


Das kann man alles machen. Aber die Frage ist: willst du das dauerhaft?


Der eigentliche Mehrwert ist nicht Performance

Wir argumentieren gern mit Kompression, Speicherverbrauch und Geschwindigkeit. Und ja, oft ist im Verleich Flat Table vs. Sternschema Sternschema besser. Aber nicht immer. Und vor allem: nicht immer sichtbar. Gerade bei kleineren Datenmengen oder untypischen Testdaten greifen diese Effekte kaum. Dann heißt es schnell: „Bei uns ist das gar kein Problem.“


Deshalb glaube ich:Das stärkste Argument für ein gutes Modell ist nicht Performance, sondern Einfachheit.


Zeig, wie schnell DAX explodiert, wenn Semantik fehlt. Zeig, wie wenig Code nötig ist, wenn das Modell sauber ist. Das verstehen Anwender sofort.


Skalierung passiert schleichend – und dann tut es weh

Was oft unterschätzt wird: Flat Tables skalieren schlecht organisatorisch. Nicht technisch, sondern strukturell. Viele Nutzer greifen auf dieselben Daten zu, wollen aber leicht andere Sichten. Ergebnis: Views, Kopien, Varianten, Redundanz. Änderungen werden aufwendig, Konsistenz wird fragil.


Ein zentrales Modell wirkt anfangs schwerer, aber es verhindert genau das. Einmal modellieren, viele Fragen beantworten. Das ist kein Governance-Argument. Das ist Wartbarkeit.


Kosten, Limits und Realität im Service

Spätestens wenn Lizenzgrenzen ins Spiel kommen, wird das Thema real. Power BI Pro, Premium, Speicherlimits, Ressourcen im Service – das alles existiert unabhängig davon, wie sauber dein Desktop läuft. Was lokal funktioniert, kann im Service plötzlich scheitern:„Visual has exceeded available resources.“


Deshalb ist mein pragmatischer Ansatz:erst Daten reduzieren, dann modellieren, dann optimieren.Nicht alles laden, nur weil es existiert. Nicht alles behalten, nur weil es historisch da ist.

Mein Fazit: es ist meistens „sowohl als auch“

Ich glaube nicht an Dogmen. Ich glaube an Kontext.

Ein einmaliger, enger Use Case? Flat Table kann reichen. Ein zentrales Thema mit vielen Fragen, Nutzern und Perspektiven? Dann wird ein Modell zur Investition in Beweglichkeit.

Wichtig ist: Rede nicht über Motoren, wenn jemand Auto fahren will. Zeig Nutzen, nicht Architektur.


Und wenn du die Gegenposition wirklich verstehen willst, such dir jemanden, der Flat Tables aus Überzeugung und Praxis nutzt – nicht aus Gewohnheit. Erst dann wird die Diskussion ehrlich.

Nicht als Lagerkampf.Sondern als Lernen auf beiden Seiten.

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page