Star-Schema bezeichnet einen Aufbau für Auswertungs-Datenbanken, in dem eine zentrale Fakten-Tabelle (die Kennzahlen wie Umsatz oder Menge speichert) mit mehreren Dimensionstabellen (die den Kontext wie Zeit, Produkt, Kunde beschreiben) verbunden ist. Der Aufbau stammt aus der dimensionalen Modellierung nach Ralph Kimball und ist wegen weniger Verknüpfungen, breiter Kontext-Tabellen und guter Verständlichkeit für Analyse-Werkzeuge der Standard-Fall für Auswertungs-Modelle in einem Data Warehouse (zentrale Auswertungs-Datenbank) oder Lakehouse-Gold-Layer (kuratierte Auswertungs-Schicht).
Was ist ein Star-Schema?
Ein Star-Schema ist ein Bauplan für den Teil einer Datenbank, in dem Kennzahlen ausgewertet werden. Im Zentrum steht die Fakten-Tabelle: sie enthält die Zahlen, die gemessen werden (Umsatz, Menge, Dauer, Klicks) und je einen Verweis (Fremdschlüssel) in die zugehörigen Kontext-Tabellen. Die Dimensionstabellen halten diesen Kontext, in dem die Kennzahlen entstehen: Zeit, Produkt, Kunde, Filiale, Vertriebskanal. Sie sind flach und breit gebaut (denormalisiert). Das heißt: Hierarchie-Ebenen wie Kategorie, Warengruppe und Sortiment leben als eigene Spalten in derselben Dimensionstabelle, statt in getrennten, per Schlüssel verknüpften Zusatz-Tabellen.
Das Entity-Relationship-Diagramm dieser Struktur sieht aus wie ein Stern: die Fakten-Tabelle in der Mitte, die Dimensionen als Zacken darum herum. Daher der Name.
Der Begriff geht auf Ralph Kimball zurück, der die dimensionale Modellierung in den 1990er-Jahren gegen Bill Inmons stärker normalisiertes 3NF-Data-Warehouse positioniert hat. Motivation für das Muster: klassische BI-Werkzeuge (Cognos, BusinessObjects, später Power BI, Tableau, Looker) und OLAP-Cubes profitieren von wenigen Joins, verständlicher Semantik und einer aggregationsfreundlichen Struktur. Analysten sollen Kennzahlen nach beliebigen Dimensionen slice-and-dice können, ohne komplexe SQL-Kaskaden zu schreiben.
Das Muster bleibt auf modernen Plattformen wie Snowflake, BigQuery, Databricks SQL, Azure Synapse und Redshift der Standardfall für BI-Auswertungen. Im Lakehouse-Kontext wird ein Star-Schema typischerweise als Gold-Layer über einer Bronze- und Silver-Schicht aufgebaut, mit denselben Kimball-Regeln und angepasster technischer Umsetzung (Delta Lake, Iceberg, Surrogatschlüssel über Identity-Spalten). Historisierung von Dimensionsattributen wird über Slowly Changing Dimensions abgebildet.
Abgrenzung zu Snowflake-Schema, Galaxy-Schema, One Big Table und 3NF
Der Begriff wird in Diskussionen häufig mit vier verwandten Modellierungsmustern verwechselt: mit dem Snowflake-Schema als normalisierter Variante, mit dem Galaxy-Schema als Mehr-Fakten-Aufbau, mit One Big Table als denormalisiertem Gegenextrem und mit dem 3NF-DWH nach Inmon.
| Muster | Kernunterschied zum Star-Schema |
|---|---|
| Snowflake-Schema | Dimensionen sind normalisiert: Hierarchie-Ebenen wandern in getrennte, per Fremdschlüssel verknüpfte Tabellen. Weniger Speicher-Redundanz, mehr Joins, gleiche Grundidee wie Star. |
| Galaxy-Schema (Fact Constellation) | Mehrere Fakten-Tabellen teilen sich Conformed Dimensions. Orthogonale Achse: ein Galaxy-Modell kann Star- oder Snowflake-förmige Dimensionen enthalten. |
| One Big Table (OBT) | Alle Attribute liegen denormalisiert in einer breiten Tabelle ohne getrennte Dimensionen. Typisches Lakehouse-Muster mit Column-Store und semantischer Schicht darüber. Gegenextrem zum Star-Schema. |
| 3NF-DWH (Inmon) | Transaktionsnahes, normalisiertes Kernmodell auf Basis der dritten Normalform ohne dimensionale Auswertungs-Struktur. Oft als integrierende Basisschicht unter einem Star-Layer. |
| Data Vault | Hub-Link-Satellite-Muster für historisierungsfreundliche Rohdaten. Bildet die Basisschicht für abgeleitete Star-Schemata und ersetzt kein dimensionales Auswertungsmodell. |
Die wichtigste Abgrenzung verläuft zum Snowflake-Schema. Beide Muster stammen aus der Kimball-Familie und teilen dieselbe Grundstruktur; sie unterscheiden sich ausschließlich im Normalisierungsgrad der Dimensionen. Star spart Joins auf Kosten von Speicher-Redundanz, Snowflake dreht diesen Trade-off um.
Beispiel: Handels-Warehouse mit vier Dimensionen
Ein Handelsunternehmen führt ein Data Warehouse mit einer Fakten-Tabelle fact_verkauf und vier Dimensionen. Die Fakten-Tabelle enthält pro Kassenzeile Fremdschlüssel und Kennzahlen:
| verkauf_sk | datum_sk | filiale_sk | produkt_sk | kunde_sk | menge | umsatz |
|---|---|---|---|---|---|---|
| 1001 | 20260712 | 42 | 4711 | 908 | 2 | 4,98 |
Die Dimensionen sind flach und denormalisiert:
| Dimension | Attribute (Auszug) |
|---|---|
| dim_datum | datum_sk, datum, kalenderwoche, monat, quartal, jahr, wochentag |
| dim_filiale | filiale_sk, filial_nr, filialname, region, land |
| dim_produkt | produkt_sk, produkt_id, produktname, kategorie, warengruppe, sortiment |
| dim_kunde | kunde_sk, kunden_nr, segment, plz, ort |
Eine Abfrage „Monatsumsatz pro Sortiment und Region" braucht drei Joins (Fakten-Tabelle mit dim_datum, dim_filiale, dim_produkt) und liest die Attribute direkt aus den flachen Dimensionsspalten, ohne über weitere Hierarchie-Tabellen zu springen. Der typische Ort im Lakehouse ist die Gold-Schicht mit kuratierten Auswertungsmodellen; Bronze und Silver bleiben ereignis- und transaktionsnah.
Star-Schema im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Cluster-Vertiefung: Delta-Umsetzung, Surrogatschlüssel, Liquid Clustering, Power BI
Dimensionale Modellierung im LakehouseEntscheidungs-Frame Kimball, Data Vault, 3NF, Wide-Table
Data Warehouse auf DatabricksWarehouse-Layer im Lakehouse, in dem Star-Schemata umgesetzt werden
Snowflake-Schemanormalisierte Variante des Star-Schemas
Data WarehouseArchitektur-Kontext, in dem dimensionale Modelle leben
Slowly Changing DimensionsHistorisierungs-Muster für Dimensionen im Star-Schema
Delta LakeSpeicher-Format, auf dem Star-Schemata im Lakehouse umgesetzt werden