Star Schema im Lakehouse: Fact Tables, Dimensionen und Power BI
Fact Tables, Dimensionen, Surrogatschlüssel und PK/FK-Constraints für Kimball-Modelle auf Delta Lake.
Die Kernaussagen auf einen Blick.
- Star Schema im Lakehouse bleibt Kimball-Modellierung, wird aber anders umgesetzt: mit Identity-Spalten für Surrogatschlüssel, informativen PK/FK-Constraints und Liquid Clustering auf häufig genutzten Fact-Keys.
- Die vier Kimball-Fact-Typen bleiben auch im Lakehouse relevant: Transaction, Periodic Snapshot, Accumulating Snapshot und Factless. Welche Variante passt, hängt vom Grain, dem Workload und der Änderungsfrequenz ab.
- Typische Fehler sind fehlende PK/FK-Constraints, zu fein geschnittene Dimensionen mit vielen kleinen Dateien und SCD-Updates ohne klaren Betriebsplan.
- Mein Vorschlag: Erst Grain und Fact-Typ pro Datenprodukt festlegen. Danach Surrogatschlüssel über Identity-Spalten, PK/FK-Constraints deklarieren und Liquid Clustering auf die häufigsten Filterspalten legen. Snowflake Schema nur dort nutzen, wo große Hierarchien oder getrennte Ownership es wirklich rechtfertigen.
Inhaltsverzeichnis
Warum Star Schema im Gold-Layer anders gebaut wird
Die Modellentscheidung ist gefallen: Star Schema im Gold-Layer. Power BI passt gut dazu, die Kennzahlen sind stabil, die Dimensionen sind fachlich klar und die Änderungsfrequenz bleibt überschaubar. Die Auswahl gegen Wide-Tables und Data Vault steht, das Datenprodukt ist skizziert. Danach beginnt die eigentliche Umsetzungsfrage: Wie sieht ein Star Schema auf Delta konkret aus, wenn Kimball-Regeln erhalten bleiben sollen, aber Delta-Features sinnvoll genutzt werden?
Ein Team erzeugt Surrogatschlüssel über eine externe Sequence, weil es aus Oracle so bekannt ist, und läuft dann in Concurrency-Probleme. Ein anderes lässt Primary Keys und Foreign Keys weg, weil Delta sie nicht erzwingt, und Power BI und Semantik-Layer müssen Beziehungen dann manuell oder über Heuristiken ableiten. Ein drittes legt dim_customer fein an, mit täglichen SCD-Type-2-Updates auf viele Attribute, und produziert Millionen kleiner Delta-Files.
Welche Fact-Typen gibt es und wann wähle ich welchen? Wie lege ich Surrogatschlüssel in Delta an, ohne globale SEQUENCE? Werden informative PK/FK-Constraints vom Optimizer und Semantik-Layer tatsächlich gelesen? Wie bleibt ein Star Schema mit häufig geänderten Dimensionen performant, ohne in Small Files zu laufen?
Wie sich Star Schema gegen Wide-Tables und Data Vault positioniert, klären wir im Überblick zur Datenmodellierung im Lakehouse.
Was ist ein Star Schema?
Ein Star Schema im Lakehouse ist ein dimensionales Modell nach Kimball, umgesetzt auf Delta-Tabellen. Es verbindet eine oder mehrere Faktentabellen mit Dimensionstabellen für Filter, Gruppierungen und fachliche Beschreibung. Die Faktentabelle enthält Kennzahlen und Fremdschlüssel auf die Dimensionen, die Dimensionen enthalten die beschreibenden Attribute. Zwischen Fact und Dimension besteht eine 1:n-Beziehung. Die Dimension ist dabei die 1-Seite der Beziehung, die Faktentabelle die n-Seite.
Der klassische Kontext ist Ralph Kimballs dimensionale Modellierung aus den 1990ern. Sie ist für OLAP und Data-Warehouse-Abfragen gebaut worden und in Kimballs Data Warehouse Toolkit systematisch beschrieben. Microsoft übernimmt diesen Ansatz in seiner Power-BI-Modellierungs-Guidance explizit als empfohlenes Modell für semantische Modelle.
Im Lakehouse ändern sich vor allem die Betriebs- und Optimierungsfragen. Speicher ist günstig, Compute elastisch, und drei Delta-Features übernehmen Aufgaben, die klassisch das Modell selbst leisten musste: Liquid Clustering optimiert Fact-Zugriffe auf beliebige High-Cardinality-Keys, Deletion Vectors machen SCD-Updates ohne File-Rewrites möglich, Column Mapping erlaubt Schema-Evolution ohne viele kleine Delta-Files anzufassen. Die Grundstruktur bleibt Fact plus Dimension. Die technische Umsetzung folgt den Delta-Regeln.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Fact-Typen gibt es im Star Schema?
Kimball unterscheidet vier typische Arten von Faktentabellen. Sie bleiben auch im Delta-Kontext relevant. Die Auswahl hängt davon ab, welche Fragen das Datenprodukt beantworten soll und wie häufig sich Daten ändern.
| Fact-Typ | Workload-Signal | Delta-Anpassung | Beispiel-Use-Case |
|---|---|---|---|
| Transaction Fact | jedes Geschäftsereignis wird einmal geschrieben, nie geändert | Liquid Clustering auf date_key und den häufigsten Dimension-Key | Vertriebstransaktionen, Klick-Events, Zahlungen |
| Periodic Snapshot Fact | Zustandsmessung in festen Intervallen (Tag, Woche, Monat) | Cluster auf snapshot_date_key, MERGE nach Ladefenster | Lagerbestand, Konto-Saldo, Kundenstatus |
| Accumulating Snapshot Fact | ein Prozess mit mehreren Meilensteinen wird pro Zeile fortgeschrieben | Deletion Vectors reduzieren MERGE-Kosten, Cluster auf process_id | Bestellprozess, Antrag, Ticket-Lifecycle |
| Factless Fact | Beziehung oder Ereignis ohne Kennzahl | oft klein, kein Clustering nötig | Kunden-Login-Events, Produkt-Kampagnen-Assignment, Bridge-Tables |
Der Transaction Fact ist der häufigste Typ. Ein einfacher fact_sales sieht in Delta so aus:
order_id und line_id sind die Business-Keys aus dem Quellsystem und werden als Degenerate Dimensions direkt in der Fact-Table geführt. Die Fremdschlüssel zeigen auf die Dimension-Surrogatschlüssel. Der Grain ist eine Bestellposition. Wenn sich der Grain ändert, ändert sich das Modell.
Periodic Snapshots passen dort, wo Zustände regelmäßig gemessen werden, ohne dass ein einzelnes Geschäftsereignis dahintersteht. Accumulating Snapshots sind seltener, passen aber im Prozess-Analytics-Kontext (Bestell-Lifecycle, Antrags-Dauer). Factless Facts werden häufig für n:m-Beziehungen, Berechtigungen, Zuordnungen oder reine Ereignisse ohne Kennzahl genutzt.
Wie werden Dimensionen im Gold-Layer modelliert?
Bei Dimensionen gibt es vier Muster, die auch im Lakehouse wichtig bleiben.
Conformed Dimensions
Sorgen dafür, dass mehrere Facts dieselbe fachliche Definition nutzen – dim_customer und dim_date gelten für Sales, Marketing und Support gleich. Im Delta eine Tabelle pro fachlicher Dimension, in Unity Catalog als geteiltes Asset mit klarer Ownership.
Junk Dimensions
Bündeln mehrere kleine Status- oder Flag-Felder in einer Dimension, etwa order_status, payment_status und channel in einer dim_order_flags. Reduziert die Zahl kleiner Delta-Tables und hält die Fact-Table lesbar.
Degenerate Dimensions
Fachliche Kennungen wie Bestellnummer oder Rechnungsnummer, die ohne separate Dim-Table direkt in der Faktentabelle bleiben. Im Modell-Diagramm als „Degenerate“ markiert, damit der Semantik-Layer sie als Filter erkennt.
Role-Playing Dimensions
Dieselbe Dimension mehrfach an eine Fact gebunden – dim_date liefert order_date, ship_date und delivery_date. Wird einmal materialisiert und über mehrere Fremdschlüssel referenziert; Power BI trennt die Rollen über Alias-Tabellen.
Für Dimensionen mit Änderungshistorie ist die Slowly-Changing-Dimension-Entscheidung ein eigenes Thema. Wie SCD Type 1, 2 und die Delta-Muster mit MERGE und Deletion Vectors aussehen, zeigen wir im Überblick zu Slowly Changing Dimensions in Delta.
Wie plane ich das Datenprodukt-Portfolio? Die Enterprise Bus Matrix
Bis hierhin haben wir jedes Datenprodukt einzeln betrachtet: Grain wählen, Fact-Typ festlegen, Dimensionen dranhängen. Das ist die Bottom-Up-Sicht. Sobald aber ein zweiter Fact denselben Kunden, dasselbe Produkt oder dieselbe Zeitdimension nutzt, entscheidet die Enterprise Bus Matrix darüber, ob die beiden Facts fachlich zusammenpassen oder nebeneinander eigene Wahrheiten aufbauen.
Die Enterprise Bus Matrix ist Kimballs Planungswerkzeug: eine Matrix mit Business-Prozessen in den Zeilen und Conformed Dimensions in den Spalten. Jede Zeile ist ein potenzieller Fact (Vertriebstransaktion, Versand, Support-Ticket, Kampagnen-Response), jede Spalte ist eine geteilte Dimension (dim_date, dim_customer, dim_product, dim_store). Ein Häkchen in einer Zelle heißt: dieser Fact nutzt diese Dimension.
| Business-Prozess | dim_date | dim_customer | dim_product | dim_store |
|---|---|---|---|---|
| Vertriebstransaktion | ✓ | ✓ | ✓ | ✓ |
| Versand | ✓ | ✓ | ✓ | |
| Support-Ticket | ✓ | ✓ | ||
| Kampagnen-Response | ✓ | ✓ | ✓ |
Der praktische Wert der Matrix liegt darin, Zuständigkeiten früh zu klären. Bevor eine neue Fact Table gebaut wird, sollte klar sein: Welche Conformed Dimensions gibt es bereits? Welche müssen erweitert werden? Und welche müssen neu modelliert werden?
Sobald mehrere Facts dieselbe dim_customer nutzen, entsteht der eigentliche Nutzen. Auswertungen über mehrere Prozesse hinweg werden konsistenter, Sales und Support arbeiten mit derselben Kundensicht, und Änderungen am Kundenschema müssen nur einmal umgesetzt werden statt in mehreren separaten Modellen.
Die Matrix ist deshalb kein einmaliges Dokument, sondern Teil des laufenden Modellierungsprozesses. Neue Anforderungen aus dem Business werden zuerst als weitere Fact-Zeile ergänzt und gegen die bestehenden Dimensionen geprüft. Das Galaxy Schema ist anschließend die technische Umsetzung davon im Delta-Gold-Layer: mehrere Fact Tables teilen gemeinsame Dimensionen.
Im Unity Catalog werden diese Conformed Dimensions als gemeinsame Assets geführt und über PK/FK-Constraints mit den jeweiligen Facts verbunden. Die Matrix bleibt die planerische Sicht darüber und zeigt, welche Facts welche Dimensionen nutzen.
Wie funktionieren Surrogatschlüssel in Delta?
Der Surrogatschlüssel ist der technische Schlüssel einer Dimensionszeile. Er ist unabhängig vom Kundenschlüssel oder Produktcode aus dem Quellsystem und bleibt auch stabil, wenn sich Quellsysteme ändern.
Für SCD Typ 2 ist das wichtig, weil ein Kunde mehrere historische Versionen haben kann. Der Business-Key beschreibt den Kunden, der Surrogatschlüssel beschreibt die konkrete Version dieses Kunden. Die Fact-Tabelle verweist deshalb auf den Surrogatschlüssel und damit auf den jeweils gültigen Stand.
In Delta können Surrogatschlüssel über GENERATED ALWAYS AS IDENTITY erzeugt werden. Der Datentyp ist BIGINT, andere Typen sind nicht erlaubt. Die Databricks-Dokumentation zu Identity-Spalten hält drei Eigenschaften fest, die das Design mitbestimmen: Werte sind monoton wachsend, aber nicht strikt zusammenhängend (Lücken sind möglich); Identity-Spalten deaktivieren Concurrent Writes auf der Tabelle, weil die Reservierung des nächsten Blocks eine Serialisierung braucht; Partitionierung auf Identity-Spalten ist nicht erlaubt.
Ein typisches dim_customer sieht so aus:
customer_key ist der Surrogatschlüssel für Fact-Joins, customer_bk (Business-Key aus dem Quellsystem) bleibt als eigene Spalte für Change-Detection und Lineage erhalten. Der attribute_hash steuert SCD-Type-2-Trigger. Ohne diese Trennung ist keine sinnvolle Historisierung möglich.
Aus klassischen DWH-Umgebungen mit Oracle oder DB2 kommt oft die Erwartung einer globalen Sequenz über alle Dimensionen. In Delta ist der Surrogatschlüssel meist pro Tabelle gedacht und wird beim INSERT vergeben; für Fact-Joins zählt seine Eindeutigkeit innerhalb der Dimension.
Warum PK/FK-Constraints trotz fehlender Erzwingung wichtig sind
Databricks unterstützt informative PRIMARY KEY- und FOREIGN KEY-Constraints auf Unity-Catalog-Tabellen. Sie werden nicht erzwungen, sind aber für Optimizer und Semantik wichtig. PK, FK und UNIQUE sind rein informational, Delta prüft beim INSERT weder Duplikate noch Referenz-Integrität. Sie sind trotzdem wertvoll, weil mehrere Konsumenten diese Metadaten nutzen können.
Der Databricks-SQL-Optimizer kann diese Informationen für bestimmte Optimierungen nutzen, etwa um Joins zu vereinfachen. Databricks AI/BI und Genie ziehen die Constraints aus dem Unity Catalog, um Fact-Dimension-Beziehungen automatisch als Semantik zu erkennen; ohne PK/FK sind Genie-Antworten auf einem Star Schema erratbar, mit PK/FK werden sie deterministisch. Für Power BI helfen klare Beziehungen und Constraints, das semantische Modell sauberer aufzubauen.
SQL-Optimizer
Nutzt PK/FK-Metadaten, um Joins zwischen Fact und Dimension zu vereinfachen und Ausführungspläne gezielter zu wählen.
Databricks AI/BI & Genie
Liest die Constraints aus dem Unity Catalog und erkennt Fact-Dimension-Beziehungen automatisch als Semantik – ohne PK/FK bleiben Antworten erratbar.
Power BI
Baut aus klaren PK/FK-Beziehungen ein saubereres semantisches Modell, statt Beziehungen manuell oder heuristisch abzuleiten.
Deklarations-Muster: PK auf jedem Surrogatschlüssel der Dimension, FK auf jeder Fact-Fremdschlüsselspalte. Zusätzlich empfiehlt sich NOT NULL auf allen Fremdschlüsseln, damit der Optimizer inner-join-freundlich planen kann.
Ohne Constraints verliert das Modell wichtige Informationen für Semantik-Layer und Dokumentation. Der technische Aufwand ist gering, der Nutzen für Verständlichkeit, Beziehungen und spätere Nutzung ist deutlich höher.
Wann braucht ein Star Schema Aggregate Facts und Bridge Tables?
Zwei Ergänzungen sind im Gold-Layer besonders wichtig: Aggregate Facts und Bridge Tables.
Aggregate Fact Tables sind voraggregierte Faktentabellen auf einem gröberen Grain. Statt Roh-Transactions auf Positions-Ebene wird täglich pro Kunde und Produkt aggregiert. Materialized Views können solche Aggregate bereitstellen und abhängig vom Setup automatisch aktualisieren. Wenn Query Rewrite greift, können Abfragen von Materialized Views profitieren, ohne dass Nutzer direkt auf die Aggregattabelle zugreifen müssen. Aggregate rechnen sich, sobald ein Dashboard die Roh-Fact regelmäßig scannt und die Latenz nicht mehr passt.
Bridge Tables lösen n:m-Beziehungen zwischen zwei Dimensionen. Wenn ein Vertriebsmitarbeiter mehreren Regionen zugeordnet ist oder ein Produkt in mehreren Kategorien, entsteht eine Bridge-Table mit den beiden Surrogatschlüsseln und optional einem Gewichtungsfaktor. Bridge Tables sind technisch oft Factless Facts. Sie lösen n:m-Beziehungen auf und können optional Gewichtungen enthalten.
Beide Muster sind im Delta unproblematisch. Aggregate profitieren von Liquid Clustering auf den Aggregations-Keys, Bridges brauchen wegen ihrer Größe meist kein Clustering.
Was ist der Unterschied zwischen Star Schema und Snowflake Schema?
Der Unterschied liegt darin, wie stark die Dimensionen normalisiert werden. Star-Schema hält jede Dimension denormalisiert in einer Tabelle: dim_product enthält product_category und product_subcategory als Spalten. Snowflake-Schema zerlegt dieselbe Dimension in drei verbundene Tabellen (dim_product, dim_product_subcategory, dim_product_category), die per Fremdschlüssel verknüpft sind. Fakt bleibt gleich, die Dimensions-Seite wird zum verzweigten Baum.
Im klassischen DWH wurde Snowflake Schema oft mit Speicherersparnis begründet: normalisierte Dimensionen reduzieren Redundanz. Im Delta Lake ist Speicher meist nicht der entscheidende Grund. Wichtiger sind Ownership, Hierarchien und Wartbarkeit.
Star Schema wählen, wenn
- Die Dimension bleibt überschaubar groß und wird von einem Team gepflegt
- Power BI, Databricks AI/BI oder Genie sollen kurze, eindeutige Filterpfade nutzen
- Speicherersparnis ist kein entscheidendes Kriterium
Snowflake Schema wählen, wenn
- Die Dimension hat mehrere Millionen Zeilen mit einer tiefen Hierarchie
- Einzelne Hierarchie-Ebenen werden fachlich getrennt von unterschiedlichen Quellsystemen gepflegt, etwa Hersteller- vs. Ausstattungsdaten
- Getrennte Ownership macht eine normalisierte Struktur wartbarer als eine große denormalisierte Tabelle
Snowflake Schema ist ein Werkzeug für den Sonderfall. Bei großen Hierarchie-Dimensionen mit getrennter Ownership passt die Normalisierung, in allen anderen Fällen bleibt das Modell ein Star Schema. Ein Galaxy Schema ist die logische Erweiterung: mehrere Fact Tables teilen gemeinsame Conformed Dimensions. Im Gold-Layer ist das der Regelfall in wachsenden Datenprodukt-Portfolios.
Wie beeinflussen Liquid Clustering, Deletion Vectors und Small Files das Star Schema?
Klassische Star-Schema-Optimierung setzt stark auf Join-Strategien, Statistiken und saubere Dimensionen. Auf Delta kommen drei weitere Betriebshebel dazu: Liquid Clustering, Deletion Vectors und der Umgang mit vielen kleinen Dateien.
Liquid Clustering ersetzt in vielen neuen Delta-Setups klassische Partitionierung oder Z-Ordering. Es akzeptiert bis zu vier Clustering-Keys und kommt gut mit High-Cardinality-Spalten wie customer_key oder date_key zurecht, ohne dass Cluster-Änderungen die Tabelle neu schreiben. Wir empfehlen, die Cluster-Keys nach den häufigsten Filter-Queries zu wählen. Für Fact-Tables sind das meistens customer_key und date_key in Kombination.
Small Files entstehen besonders schnell bei fein modellierten Dimensionen mit vielen Änderungen. Eine dim_customer mit vielen SCD-Typ-2-Attributen kann bei täglichen Updates schnell viele kleine Dateien erzeugen. Auch mit Deletion Vectors, die MERGE-Kosten senken, hilft das nur bedingt, wenn jeder Update eine neue Version schreibt.
Deletion Vectors können MERGE-Operationen günstiger machen, weil geänderte oder gelöschte Zeilen nicht sofort physisch neu geschrieben werden müssen. Besonders relevant ist das für SCD Type 2, wo regelmäßig bestehende Datensätze geschlossen und neue Versionen ergänzt werden. Das Muster behandeln wir im SCD-Überblick genauer.
Für Star Schemas gilt: Deletion Vectors sind vor allem dann interessant, wenn Dimensions- oder Fact-Tabellen regelmäßig per MERGE aktualisiert werden. Wenn eine Tabelle nur append-only beschrieben wird, bringen sie kaum zusätzlichen Nutzen. Wie Liquid Clustering im Detail arbeitet, klären wir im Überblick zu Liquid Clustering.
Warum Star Schema in Power BI weiter sinnvoll bleibt
Power BI Import Mode funktioniert besonders gut mit sauber aufgebauten Star Schemas. Fact-Tabellen enthalten viele Schlüsselspalten mit niedriger Kardinalität, die VertiPaq sehr effizient komprimieren kann. Wenn dagegen viele Dimensionsattribute direkt in die Fact-Tabelle kopiert werden, kann das Import-Modell schneller wachsen und schwerer wartbar werden.
Microsoft empfiehlt für Power BI deshalb ausdrücklich das Star Schema: Dimensionen filtern und gruppieren, Fact-Tabellen liefern die Kennzahlen. Dieses Muster passt gut zu Power BI und bleibt auch in Databricks SQL verständlich. Auch Junk Dimensions, Degenerate Dimensions und Role-Playing Dimensions lassen sich sauber abbilden.
Auch Databricks AI/BI und Genie profitieren von klaren Beziehungen zwischen Facts und Dimensionen. Wenn Primary- und Foreign-Key-Constraints im Unity Catalog gepflegt sind, kann Genie die Modellstruktur besser verstehen. Ohne diese Informationen müssen Joins eher geraten werden, was bei mehreren möglichen Beziehungen schnell zu falschen oder unklaren Ergebnissen führt.
Wie Power BI konkret an ein Delta-Star-Schema angebunden wird, klären wir im Überblick zur Power-BI-Integration auf Databricks.
Grenzen von Star Schema im Lakehouse
Ein Star Schema skaliert im Gold-Layer nicht automatisch nur deshalb, weil es auf Delta liegt.
Identity-Spalten als Engpass
Delta serialisiert INSERTs auf Tabellen mit GENERATED ALWAYS AS IDENTITY. Bei hoher Ladefrequenz auf eine Fact-Table wird das spürbar – ein Ausweg ist, parallele Loads in einer Vorstufe zu sammeln und die Faktentabelle kontrolliert im Batch zu schreiben.
Fehlende PK/FK-Constraints
Ohne Constraints müssen Beziehungen in Power BI manuell modelliert werden, in Databricks AI/BI wird die Semantik nachgepflegt und Genie liefert unschärfere Antworten. Der ETL-Aufwand für Constraints ist gering – sie wegzulassen verschenkt Nutzen ohne echten Vorteil.
Small Files bei häufigen SCD-Updates
Auch mit Deletion Vectors muss der Compaction-Scheduler stehen. Eine tägliche Ladung von 100.000 Änderungen auf dim_customer ohne OPTIMIZE erzeugt nach drei Monaten ein Performance-Problem, das kein Query-Tuning mehr behebt.
Snowflake Schema nur bei getrennter Ownership
Aus DWH-Reflex angelegte Snowflake-Dimensionen produzieren Extra-Joins ohne Nutzen. Die Trennung passt erst, wenn Ownership oder Hierarchietiefe sie fachlich erzwingen.
Aggregate Facts ersetzen kein Basis-Star-Schema
Aggregate für schnellere Queries kaschieren oft ein Grain-Problem oder eine fehlende Cluster-Strategie auf der Basis-Fact. Erst Cluster tunen, dann Aggregate.
Star-Schema-Design bleibt Modellierungsarbeit. Delta-Features helfen, ersetzen aber keine saubere Grain-, Key- und Constraint-Entscheidung.
Fazit
Star Schema im Gold-Layer lohnt sich, wenn Grain, Fact-Typen, Surrogatschlüssel und Constraints sauber definiert sind.
Erst dann sollten Delta-spezifische Betriebsfragen wie Liquid Clustering, Deletion Vectors oder attribute_hash-Trigger dazukommen.
Besonders relevant ist das bei Migrationen vom klassischen DWH ins Lakehouse. Kimball-Muster lassen sich nicht einfach übernehmen, ohne die Delta-Betriebslogik mitzudenken. Auch Plattformen mit Power BI, Databricks AI/BI und Genie profitieren von klaren Fact-Dimension-Beziehungen und gepflegten PK/FK-Constraints.
Wer mit einer ersten Faktentabelle und wenigen Dimensionen startet, braucht meist noch kein Snowflake Schema und keine ausgebaute Aggregate-Strategie. Wichtiger sind ein sauberer Grain, stabile Schlüssel und verständliche Beziehungen. Optimierung auf Vorrat lohnt sich hier selten.
Mein Vorschlag: Erst pro Datenprodukt Grain und Fact-Typ festlegen, dann Surrogatschlüssel und PK/FK-Constraints deklarieren. Danach Liquid Clustering auf die wichtigsten Filterspalten setzen und Snowflake Schema nur dort nutzen, wo große Hierarchien sonst schwer wartbar werden.
So entsteht ein Star Schema, das Power BI, Databricks AI/BI und Genie zuverlässig interpretieren können und im Delta-Betrieb nicht unnötig teuer wird.
Erst pro Datenprodukt Grain und Fact-Typ festlegen, dann Surrogatschlüssel und PK/FK-Constraints deklarieren. Danach Liquid Clustering auf die wichtigsten Filterspalten setzen und Snowflake Schema nur dort nutzen, wo große Hierarchien sonst schwer wartbar werden.
FAQ
Ein Star Schema im Gold-Layer ist ein dimensionales Modell nach Kimball, das auf Delta-Tabellen umgesetzt wird: eine oder mehrere Fact Tables mit numerischen Kennzahlen und Fremdschlüsseln, umgeben von Dimensionstabellen mit beschreibenden Attributen. Die Grundstruktur bleibt klassisch. Die technische Umsetzung nutzt Delta-Bausteine wie Identity-Spalten für Surrogatschlüssel, informative PK/FK-Constraints und Liquid Clustering auf Fact-Keys.
