Star vs. Snowflake Schema in Power BI: Was ist schneller?

Ein Sternschema schneidet in Power BI fast immer besser ab als ein Snowflake Schema. Filter erreichen die Faktentabelle über eine einzige Beziehung statt über eine Kette, das Modell enthält weniger Tabellen und Schlüsselspalten, und DAX bleibt einfacher. Auch Microsofts eigene Modellierungsempfehlung rät dazu, Snowflake-Dimensionstabellen in den meisten Fällen zu einer Tabelle zusammenzufassen.

Was ist ein Sternschema

Ein Sternschema hat zwei Arten von Tabellen:

• Faktentabellen enthalten Ereignisse und ihre Zahlen, etwa Verkaufszeilen mit Menge und Umsatz.

• Dimensionstabellen enthalten die beschreibenden Spalten, nach denen Sie filtern und gruppieren, etwa Produkt, Kunde und Datum.

Beispielstruktur

Eine Faktentabelle Sales mit diesen Spalten:

• DateKey

• ProductKey

• CustomerKey

• Quantity

• Revenue

Darum herum die Dimensionstabellen:

• Date

• Product (mit Kategorie und Unterkategorie als Spalten)

• Customer (mit Region als Spalte)

Jede Dimension ist über eine Eins-zu-viele-Beziehung direkt mit der Faktentabelle verbunden.

Wichtige Merkmale

• Flache Dimensionstabellen.

• Eine Beziehung zwischen jeder Dimension und der Faktentabelle.

• Filter legen einen Schritt zurück.

Was ist ein Snowflake Schema

Ein Snowflake Schema normalisiert Dimensionen in mehrere verbundene Tabellen. Statt einer Tabelle Product haben Sie drei: Product, Product Subcategory und Product Category. Product ist mit der Faktentabelle verbunden. Subcategory ist mit Product verbunden und Category mit Subcategory.

Wichtige Merkmale

• Normalisierte Dimensionen, in denen jedes Attribut einmal gespeichert ist.

• Ketten von Beziehungen zwischen Dimensionstabellen.

• Mehr Tabellen und mehr Schlüsselspalten.

Snowflakes sind in relationalen Data Warehouses verbreitet, wo sie Speicher sparen und Aktualisierungen vereinfachen. In einem Power-BI-Modell sieht die Abwägung anders aus.

Wie Power BI Datenmodelle verarbeitet

Jedes Visual sendet eine Abfrage an das Semantic Model. In einem Import-Modell speichert die VertiPaq-Engine jede Spalte komprimiert im Arbeitsspeicher. Ein Filter auf eine Dimensionsspalte wird über die Beziehungen weitergereicht, bis er die Faktentabelle erreicht, und die Engine aggregiert dann die verbleibenden Faktenzeilen.

Daraus folgen zwei Dinge:

• Jede Beziehung, die ein Filter durchläuft, bedeutet zusätzliche Arbeit.

• Jede Tabelle enthält Schlüsselspalten, die nur Beziehungen dienen und Arbeitsspeicher belegen.

Leistungsvergleich: Sternschema vs. Snowflake Schema

Warum ein Sternschema in Power BI besser abschneidet

1. Weniger Beziehungen pro Filter

In einem Sternschema läuft ein Filter auf Category einmal: von Product zu Sales. In einem Snowflake läuft er von Category zu Subcategory, von Subcategory zu Product und dann von Product zu Sales. Microsoft weist darauf hin, dass längere Filterketten weniger effizient sein können als ein Filter auf einer einzelnen Tabelle.

2. Weniger Tabellen und Schlüsselspalten

Laut Microsofts Empfehlung lädt ein Snowflake-Design mehr Tabellen, was für Speicher und Leistung weniger effizient ist. Jede zusätzliche Tabelle bringt Schlüsselspalten mit, die nur für die Beziehung existieren. Kategorienamen, die auf jeder Produktzeile wiederholt werden, lassen sich in VertiPaq gut komprimieren, weil die Spalte nur wenige unterschiedliche Werte hat.

3. Einfacherer Filterkontext

In einem Sternschema liegen alle Attribute eines Produkts in einer Tabelle, sodass ein Measure, das einen Filter aufheben oder ändern soll, nur eine Tabelle anfasst. In einem Snowflake kann derselbe Filter über mehrere Tabellen ankommen, und Measures müssen alle berücksichtigen. Alle Produktfilter aufzuheben ist in einem Sternschema zum Beispiel ein einziges REMOVEFILTERS ( 'Product' ). In einem Snowflake müssen Sie auch Subcategory und Category zurücksetzen.

4. Bessere Bedienbarkeit

Mit einer flachen Product-Tabelle können Sie eine einzige Hierarchie aus Category, Subcategory und Product bauen. Report-Autoren sehen eine Tabelle statt dreier, von denen zwei nur einen Schlüssel und einen Namen enthalten können. Weniger verwirrende Auswahl bedeutet weniger schlecht gebaute Visuals.

Wann ein Snowflake Schema akzeptabel sein kann

Ein Snowflake ist nicht immer falsch. Er kann sinnvoll sein, wenn:

• eine Dimension sehr groß ist und eine übergeordnete Ebene viele breite Spalten trägt, sodass es mehr kostet, sie in jeder Zeile zu wiederholen, als eine zusätzliche Beziehung zu halten.

• Fakten in unterschiedlicher Granularität gespeichert sind. Zum Beispiel können Zielwerte je Produktkategorie mit einer Tabelle Category verbunden sein, während Verkäufe mit Product verbunden sind.

• das Modell klein ist, die Geschwindigkeit kein Problem darstellt und es die Wartung erleichtert, die Struktur des Warehouses nachzubilden.

Testen Sie auch dann eine abgeflachte Version. In den meisten Modellen ist sie die bessere Wahl.

Best Practice: Dimensionen für Power BI abflachen

Behalten Sie die normalisierte Struktur im Warehouse, wenn sie dort sinnvoll ist. Flachen Sie sie auf dem Weg in Power BI ab.

In Power Query abflachen

Sind Product, ProductSubcategory und ProductCategory getrennte Abfragen, erstellen Sie die flache Tabelle mit zwei Merges. Wählen Sie im Power Query Editor Start > Neue Quelle > Leere Abfrage, nennen Sie die Abfrage Product Flat, öffnen Sie den Erweiterten Editor und fügen Sie ein:

let
    Source = Product,
    MergedSubcategory = Table.NestedJoin(Source, {"ProductSubcategoryKey"}, ProductSubcategory, {"ProductSubcategoryKey"}, "Subcategory", JoinKind.LeftOuter),
    ExpandedSubcategory = Table.ExpandTableColumn(MergedSubcategory, "Subcategory", {"SubcategoryName", "ProductCategoryKey"}),
    MergedCategory = Table.NestedJoin(ExpandedSubcategory, {"ProductCategoryKey"}, ProductCategory, {"ProductCategoryKey"}, "Category", JoinKind.LeftOuter),
    ExpandedCategory = Table.ExpandTableColumn(MergedCategory, "Category", {"CategoryName"}),
    RemovedKeys = Table.RemoveColumns(ExpandedCategory, {"ProductSubcategoryKey", "ProductCategoryKey"})
in
    RemovedKeys

Die Abfrage verweist namentlich auf die anderen drei Abfragen. Klicken Sie mit der rechten Maustaste auf Product, ProductSubcategory und ProductCategory und deaktivieren Sie jeweils Laden aktivieren, damit sie den Merge speisen, aber nur Product Flat ins Modell geladen wird. Ein Left Outer Join behält Produkte ohne Unterkategorie.

In der Quelle abflachen

Ist die Quelle eine SQL-Datenbank, erledigt eine View dasselbe und lässt sich sauber falten:

CREATE VIEW dbo.vDimProduct AS
SELECT
    p.ProductKey,
    p.ProductName,
    s.SubcategoryName,
    c.CategoryName
FROM dbo.DimProduct AS p
LEFT JOIN dbo.DimProductSubcategory AS s
    ON s.ProductSubcategoryKey = p.ProductSubcategoryKey
LEFT JOIN dbo.DimProductCategory AS c
    ON c.ProductCategoryKey = s.ProductCategoryKey;

Importieren Sie die View als Tabelle Product.

Best Practices für die Leistung von Power-BI-Modellen

• Bilden Sie jeden Geschäftsprozess als Faktentabelle mit einheitlicher Granularität ab.

• Verbinden Sie jede Dimension direkt mit den Faktentabellen.

• Vermeiden Sie Viele-zu-viele-Beziehungen, wo eine saubere Dimension oder Brückentabelle reicht.

• Nutzen Sie standardmäßig Filterung in eine Richtung. Siehe Kreuzfilterrichtung.

• Entfernen Sie Spalten, die niemand im Report nutzt.

• Nutzen Sie eine eigene Datumstabelle.

• Verbinden Sie über ganzzahlige Surrogatschlüssel.

Welche Beziehungstypen es gibt und was sie kosten, lesen Sie in Power-BI-Beziehungen und Kardinalität. Weitere Modellierungsregeln finden Sie in unseren Best Practices für die Datenmodellierung.

Sternschema und DAX-Leistung

Ein Sternschema macht DAX kürzer und berechenbarer:

• Filter auf Produktattribute liegen in einer Tabelle, sodass CALCULATE-Modifikatoren nur eine Tabelle anfassen.

• RELATED erreicht eine Dimensionsspalte von der Faktentabelle aus in einem Schritt.

• Measures können eine Spalte filtern, statt eine Tabelle zu iterieren, was die Engine günstiger verarbeitet.

Ein sauberes Modell macht aus einem Measure, das mehrere Filtermodifikatoren brauchte, oft ein einfaches SUM.

Welches Schema Sie in Power BI nutzen sollten

Nutzen Sie für Power-BI-Modelle ein Sternschema. Flachen Sie Snowflake-Dimensionen in Power Query oder in der Quelle ab und behalten Sie einen Snowflake nur aus einem konkreten Grund von der Liste oben, etwa bei Fakten in anderer Granularität. Sind Ihre Reports aus anderen Gründen langsam, behandelt unser Leitfaden zur Power-BI-Performance die übrigen Ebenen.

FAQ: Sternschema vs. Snowflake Schema in Power BI

Ist ein Sternschema in Power BI Pflicht?

Nein. Power BI akzeptiert jede Zusammenstellung von Tabellen und Beziehungen. Ein Sternschema ist Microsofts empfohlenes Design, weil es die beste Mischung aus Geschwindigkeit, Modellgröße und Bedienbarkeit bietet.

Macht ein Snowflake Schema Reports immer langsam?

Nein. Ein kleines Snowflake-Modell kann schnell genug sein. Der Aufwand wächst mit der Zahl der Tabellen in jeder Kette und mit der Größe des Modells, und ein Snowflake verhindert unabhängig von der Geschwindigkeit Hierarchien, die über Tabellen reichen.

Kann ich in Power BI einen Snowflake in ein Sternschema umwandeln?

Ja. Führen Sie die übergeordneten Tabellen in Power Query mit der untergeordneten zusammen, wie im Beispiel oben, und deaktivieren Sie das Laden der übergeordneten Abfragen. Ist die Quelle eine Datenbank, erledigt eine View, die die Tabellen verbindet, dasselbe, bevor die Daten in Power BI ankommen.

Verbessert ein Sternschema die DAX-Leistung?

Meistens. Filter durchlaufen weniger Beziehungen, und Measures brauchen weniger Filtermodifikatoren. Die größten DAX-Gewinne kommen aber weiterhin daher, wie jedes Measure geschrieben ist. Ein Sternschema ist also die Grundlage, nicht die ganze Lösung.

Quellen

• Understand star schema and the importance for Power BI - Microsoft Learn

• Model relationships in Power BI Desktop - Microsoft Learn