DatenWG Library · thema
Sternschema
Ein Sternschema erlaubt unabhängiges Filtern über mehrere Dimensionen, ohne dass sich die Filter gegenseitig stören. (Stand 2026-01) Bei geringer Datenmenge und einfachen Measures zeigte sich in eigenen Tests kein signifikanter Performance-Unterschied zwischen Flat Table und Sternschema. (Stand 2026-01) Das 1988 entwickelte Modell mit separaten Tabellen für Kunden, Lieferanten und Artikel sowie einer zentralen Tabelle mit Schlüsseln und Kennzahlen wie Rechnungssumme und Provision entsprach im Nachhinein einem Sternschema. (Stand 2026-05)
Aliase
Star Schema Faktentabelle Dimensionstabelle Fakten und Dimensionen Star-Schema
Kernaussagen
- Das 1988 entwickelte Modell mit separaten Tabellen für Kunden, Lieferanten und Artikel sowie einer zentralen Tabelle mit Schlüsseln und Kennzahlen wie Rechnungssumme und Provision entsprach im Nachhinein einem Sternschema.
- Die ersten Veröffentlichungen zum Sternschema stammen aus der Mitte der 1990er-Jahre.
- Ralph Kimball veröffentlichte Mitte der 1990er-Jahre ein Buch, in dem er forderte, Data Warehouses stets mit einem Sternschema beziehungsweise dimensionaler Modellierung aufzubauen.
- Zwischen Ralph Kimball und Bill Inmon entstand ein langjähriger Grundsatzstreit darüber, ob Data Warehouses dimensional per Sternschema oder relational in dritter Normalform modelliert werden sollten.
- Im Mittelstand wird die Aufteilung zwischen Sternschema und relationaler Modellierung nach Einschätzung von Peter Gluchowski anders gehandhabt als in Großunternehmen.
- Peter Gluchowski schätzt, dass sich das Sternschema in größeren Unternehmen eher auf der Data-Mart-Ebene findet als auf der Ebene des Kern-Data-Warehouse.
- Eine KI hat aus einer hochgeladenen CSV-Datei automatisch ein Sternschema samt Notebook erstellt.
- Ein Meeting-Teilnehmer empfand die vorherige Flat Table als einfacher als das neu eingeführte Sternschema.
- Power BI ist technisch eng mit Analysis Services verbunden, weshalb aus dieser Perspektive ein Sternschema die passende Modellierung ist.
- Ein Sternschema erlaubt unabhängiges Filtern über mehrere Dimensionen, ohne dass sich die Filter gegenseitig stören.
- Ab einem gewissen Datenvolumen sollte in Power BI ein Sternschema verwendet werden, um Performance-Probleme zu vermeiden.
- Bei Benchmark-Tests mit künstlich generierten Testdaten wie der Kontoso-Datenbank komprimiert ein Sternschema teils schlechter als erwartet, weil reale Kundenverteilungen von Testdaten abweichen.
- Bei geringer Datenmenge und einfachen Measures zeigte sich in eigenen Tests kein signifikanter Performance-Unterschied zwischen Flat Table und Sternschema.
- Bei einem Ist-Budget-Vergleich mit unterschiedlicher Granularität von Kunde und Produkt sowie täglicher und monatlicher Frequenz wird eine flache Tabelle mit Field Parameters schnell unübersichtlich, während ein Sternschema die Zusammenführung vereinfacht.
- Jasmin empfiehlt, für einmalige und eng begrenzte Auswertungen im Fachbereich eine Flat Table in Excel zu nutzen, für wiederkehrende Analysen aber ein Datenmodell zu bauen, weil Datenfehler darin schneller auffallen.
- DirectQuery unterstützt laut den Sprechern bei Quellen wie Snowflake oder Databricks kein Sternschema.
- Bei komplexeren Aufgaben wie dem Aufbau eines Sternschemas wird vermutet, dass mehr Instructions dem MCP-Assistenten helfen würden, das gewünschte Ergebnis zuverlässiger zu erzielen.
- Wächst ein Report zu einem Standard-Reporting mit zusätzlichen Dimensionen und unterschiedlicher Granularität, führt das meist Richtung eines dimensionalen Modells beziehungsweise Sternschemas.
- Von Flat Tables wird abgeraten, außer für sehr eng fokussierte Auswertungen in einem begrenzten Bereich.
- Das Sternschema mit einer zentralen Faktentabelle und umgebenden Dimensionen wird von den Sprechern als bevorzugter Modellierungsansatz in Power BI favorisiert.
- Eine gut modellierte Dimensionstabelle wie eine Artikeltabelle lässt sich über mehrere Themenbereiche wie Produktion, Einkauf und Lagerbestand hinweg wiederverwenden.
- Über Role-Playing-Dimensionen lässt sich ein einmal modelliertes Objekt wie Kunde in mehreren Rollen, etwa als Liefer-, Rechnungs- und Auftragskunde, wiederverwenden, ohne die Kundendaten mehrfach zu pflegen.
- Wird eine One-Big-Table per Inner Join aus einem dimensionalen Modell erzeugt, fallen Kunden ohne zugehörige Transaktionen aus der Analyse heraus, während sie im Sternschema in der Dimension erhalten bleiben.
- Sobald ein Modell mehr als eine Faktentabelle mit unterschiedlichen Dimensionen oder Granularitäten enthält, werden die benötigten DAX-Formeln in einer One-Big-Table deutlich komplexer als im Sternschema.
- Sobald mehrere Faktentabellen für einen Drill-Across kombiniert werden sollen oder unternehmensweit standardisierte Dimensionen benötigt werden, ist ein dimensionales Modell mit Sternschema vorzuziehen.
- Dem KI-Agenten wurden bei der Modellgenerierung explizite Vorgaben mitgegeben, darunter das Vermeiden von Snowflake-Dimensionen, Beziehungen möglichst in eine Richtung und geschäftsfreundliche statt technische Tabellennamen.
- Die Custom-Engine benötigt laut Brian Bønk keine Datenmodellierung und kein Sternschema, während Power BI für die beste Performance ein Sternschema braucht.
- Für Dimensionsschlüssel wird ein sprechender Schlüssel gegenüber einem Hash bevorzugt, sofern keine technischen Gründe wie fehlende deterministische Sortierung bei verteilten Architekturen dagegensprechen.
- Für ein unternehmensweites Data Warehouse wird empfohlen, eine Standard-Kalendertabelle einmal zu laden und zu persistieren, statt sie für jedes Datenmodell neu zu erzeugen.
- Das Datenmodell für die Finanzberichterstattung basiert auf einer Faktentabelle mit den Buchungen aus dem Hauptbuch.
- Die Mapping-Tabelle zwischen Konten und Berichtszeilen ist strukturell eher eine Bridge-Tabelle im Kimball-Sinn als eine klassische Faktentabelle mit Kennzahlen.
Dokumente
- BI Thinkers Talk - Data Modeling - Fabric Data Days Edition [EN]
- BI Thinkers Talk - Data Modelling - Fabric Data Days Edition
- Denken in Tabellen
- Power BI von A bis Z — Einsteiger-Guide (End-to-End)
- 27 Jahre in 10 Minuten - Peter Gluchowski beim Daten-WG Offsite
- Starting with Microsft Fabric the Skills you need
- Datenmodellierung ist Governance
- Daten-WG Deep Dive Financial Reporting - part 5
- Fabric Planning unboxing
- Daten-WG Deep Dive Financial Reporting - part 6
- Power BI vs. Qlik
- BI Thinkers Talk nr.68
- Daten-WG Deep Dive Financial Reporting
- Microsoft Fabric — Einsteiger-Guide
- Realtalk zu Self Service mit Power BI
- Daten-WG Deep Dive Financial Reporting - part 7
- Daten-WG BI Thinkers Talk nr.66
- BI Thinkers Talk nr.75
- Mythos Data Vault und richtig große Modelle
- Data Binning and Lorenz Curve in DAX | Alberto Ferrari & Michael Tenner, Berlin Power BI User Group
- Why Passion Beats Niche
- Prinzipien oder Paragrafen
- Dein erstes Dashboard — Power-BI-Praxis-Pfad
- Daten-WG Deep Dive Financial Reporting pt.4
- Daten-WG Special: Power BI vs. Qlik
- Unboxing MCP Server for Power BI Modelling
- Daten-WG Thinkers Talk n61
- BI Thinkers Talk nr.69
- BI Thinkers Talk nr.67
- BI Thinkers Talk nr.71
Nachbarthemen
- DirectQuery
- Datenmodellierung
- Data Vault
- Performance
- Power BI
- Reporting
- Power Query
- DAX
- Microsoft Fabric
- Excel
- Lakehouse
- Visualisierung
- SQL
- Direct Lake
- Planung
Hinweise
Kernaussagen und Beziehungen sind maschinell erzeugt und nicht redigiert. Heuristische Kanten zählen Erwähnungen, keine Bedeutung. Bei Widersprüchen gilt das Video.