Power BI: Beziehungen und Kardinalität für schnelle Reports

Beziehungen und Kardinalität in Power BI steuern, wie Filter zwischen Tabellen fließen. Falsch gesetzt gehören sie zu den häufigsten Ursachen langsamer Reports. Nutzen Sie Eins-zu-viele-Beziehungen in einem Sternschema, halten Sie Filter standardmäßig in einer Richtung und verbinden Sie über numerische Schlüssel mit niedriger Kardinalität. Dieser Leitfaden erklärt, warum Beziehungen die Performance beeinflussen, welche vier Kardinalitätstypen es gibt und welche konkreten Fehler Reports ausbremsen.

Warum Beziehungen die Performance beeinflussen

Power BI nutzt die VertiPaq-Engine, eine spaltenorientierte Speicher-Engine für schnelle Aggregation. Bei jedem Laden eines Visuals wendet Power BI Filter an, durchläuft die Beziehungen zwischen den Tabellen, baut den resultierenden Filterkontext auf und führt die DAX-Abfrage hinter dem Visual aus. Ist eine Beziehung ineffizient, durchsucht dieser Durchlauf mehr Daten als nötig.

Ineffiziente Beziehungen zeigen sich meist als langsame Slicer-Interaktionen, lange Ladezeiten von Visuals, hohe CPU-Last bei Aktualisierung oder Interaktion und Measures, die korrekte Zahlen liefern, sich aber träge anfühlen. Das meiste davon geht auf Kardinalität oder Beziehungsrichtung zurück, die unten behandelt werden.

Die vier Kardinalitätstypen

Kardinalität beschreibt, wie Zeilen einer Tabelle mit Zeilen einer anderen zusammenhängen.

1. Eins-zu-viele (1:*). Der empfohlene Standard. Ein Produkt gehört zu vielen Verkaufszeilen. Dimensionstabellen bleiben klein, Faktentabellen bleiben groß und optimiert, und Filter wandern sauber von der Dimensionsseite zur Faktenseite.

2. Viele-zu-eins (*:1). Dieselbe Beziehung wie Eins-zu-viele, von der anderen Tabelle aus beschrieben. Die Performance ist gleich. Nur die Blickrichtung ändert sich.

3. Viele-zu-viele (*:*). Oft die langsamste Option. Power BI muss Mehrdeutigkeit zur Abfragezeit mit zusätzlicher Join-Logik auflösen. Das vergrößert den Auswertungsraum, erschwert die Filterweitergabe und kann unerwartete Summen erzeugen. Vermeiden Sie sie, außer die Daten haben wirklich keine andere Form, etwa zwei Faktentabellen ohne gemeinsame Dimension.

4. Eins-zu-eins (1:1). Selten das richtige Design. Eine Eins-zu-eins-Beziehung zwischen zwei Tabellen bedeutet meist, dass beide Tabellen zu einer zusammengeführt werden sollten.

Wie Kardinalität die Performance intern beeinflusst

Eine Spalte mit hoher Kardinalität hat viele eindeutige Werte. Eine Spalte Country oder Product Category hat niedrige Kardinalität. Eine Spalte Transaction ID oder ein Zeitstempel hat sehr hohe Kardinalität. Hohe Kardinalität bei einem Beziehungsschlüssel bedeutet ein größeres komprimiertes Wörterbuch, mehr Speicherverbrauch und langsamere Joins. VertiPaq komprimiert eine Spalte nach der Zahl ihrer verschiedenen Werte, und eine Spalte mit wenigen Wiederholungen komprimiert schlecht. Beziehungen über Schlüssel mit niedriger Kardinalität laufen am besten.

Sternschema: die Grundlage schneller Modelle

Die meisten schnellen Power-BI-Modelle folgen einem Sternschema: Dimensionstabellen (Product, Customer, Date, Region), die über Eins-zu-viele-Beziehungen mit einer zentralen Faktentabelle (Sales oder Transactions) verbunden sind. Ein Sternschema hält die Filterung einseitig, die Abfragepläne vorhersehbar und DAX einfach, weil jede Berechnung demselben Filterpfad von der Dimension zum Fakt folgt. Unser Leitfaden zu Sternschema vs. Snowflake Schema zeigt, wann sich ein Snowflake-Aufbau mit den zusätzlichen Beziehungsschritten lohnt.

Beziehungsrichtung: einfach oder beide

Beziehungen in Power BI filtern standardmäßig in eine Richtung, von der Dimensionstabelle zur Faktentabelle. Einseitige Filterung ist schneller und ihr Verhalten leichter nachzuvollziehen, weil ein Filter genau einen Weg nehmen kann.

Bidirektionale Beziehungen lassen Filter in beide Richtungen fließen. Sie sind manchmal für Brückentabellen oder bestimmte Analysemuster nötig. Sie weiten aber die Filterweitergabe über das Modell aus, können ungewollte Filterpfade erzeugen und verlangsamen dadurch Berechnungen. Aktivieren Sie bidirektionale Filterung nur für die Beziehung, die sie braucht, nicht als Standard.

Fehler, die Reports ausbremsen

• Fakt-zu-Fakt-Beziehungen. Zwei Faktentabellen müssen selten direkt verbunden sein. Führen Sie die Beziehung stattdessen über eine gemeinsame Dimensionstabelle.

• Beziehungen über Textspalten. Textschlüssel komprimieren und joinen langsamer als numerische. Nutzen Sie einen numerischen Ersatzschlüssel wie ProductKey = 1001, statt über ProductName zu verbinden.

• Doppelte Schlüssel in einer Dimensionstabelle. Ein Dimensionsschlüssel, der nicht eindeutig ist, bricht die Eins-zu-viele-Annahme, auf die sich Power BI stützt, und erzwingt weniger effiziente Joins. Halten Sie Dimensionsschlüssel eindeutig.

• Viele-zu-viele als Standard. Eine Viele-zu-viele-Beziehung deutet meist auf eine fehlende Dimension hin. Prüfen Sie eine Brückentabelle, eine Aggregationstabelle oder lösen Sie die Struktur schon in der Datenquelle auf.

Kardinalität senken

• Teilen Sie eine Zeitstempel-Spalte in getrennte Spalten für Datum und Uhrzeit, statt eine Datetime-Spalte mit hoher Kardinalität zu behalten.

• Nutzen Sie numerische Ersatzschlüssel für Joins statt Textschlüssel.

• Entfernen Sie Spalten, die Sie in Visuals oder Measures nicht nutzen. Jede Spalte erhöht, was VertiPaq durchsucht.

• Aggregieren Sie vor dem Laden auf die Granularität, auf der Sie wirklich berichten, in SQL, Databricks oder Ihrem Data Warehouse, wenn Details auf Transaktionsebene nicht nötig sind.

• Führen Sie unnötige Snowflake-Dimensionen in die Hauptdimensionstabelle zusammen, um Beziehungsketten zu verkürzen.

Ein langsames Measure wird oft schnell, sobald das zugrunde liegende Modell behoben ist. DAX wertet den Filterkontext aus, den die Beziehungen erzeugen. Ein einfacheres, saubereres Modell führt daher meist zu einfacherem, schnellerem DAX. Unseren Leitfaden zur DAX-Performance-Optimierung nutzen Sie, um die DAX-Seite abzustimmen, sobald das Modell selbst in gutem Zustand ist. Die Best Practices zur Datenmodellierung enthalten die breitere Checkliste.

Assume Referential Integrity und Aktivierung von Beziehungen

Zwei Einstellungen an Beziehungen beeinflussen Performance und Korrektheit.

Assume Referential Integrity

Diese Einstellung gibt es bei DirectQuery-Beziehungen. Sie sagt Power BI, dass jeder Schlüssel in der Faktentabelle einen passenden Wert in der verbundenen Dimensionstabelle hat. Dadurch kann Power BI SQL mit INNER JOIN statt OUTER JOIN erzeugen und durchsucht weniger Daten. Aktivieren Sie sie nur, wenn die referenzielle Integrität tatsächlich gilt. Haben manche Faktenzeilen keine passende Dimensionszeile, kann die Aktivierung diese Zeilen aus den Ergebnissen entfernen.

Aktivierung von Beziehungen

Power BI erlaubt zwischen zwei Tabellen jeweils nur eine aktive Beziehung. Die aktive Beziehung gibt Filter automatisch weiter. Eine inaktive Beziehung existiert weiter, braucht aber USERELATIONSHIP, um in einem bestimmten Measure aktiviert zu werden:

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(Sales[ShipDate], DateTable[Date])
)

Das ist das übliche Muster, wenn eine Faktentabelle zwei Datumsspalten hat, etwa Bestelldatum und Lieferdatum, die beide mit derselben Datumstabelle verbunden sind. Eine Beziehung bleibt als Standard aktiv (Bestelldatum). Die andere wird nur in den Measures aktiviert, die nach Lieferdatum filtern müssen.

Ein anschauliches Vorher-Nachher-Muster

Dieses Beispiel ist anschaulich gemeint, kein gemessenes Kundenergebnis. Ein Modell mit mehreren Viele-zu-viele-Beziehungen und überall bidirektionalen Filtern lädt in der Regel langsamer als dasselbe Modell, das als Sternschema neu gebaut wurde, mit einseitigen Filtern und numerischen Ersatzschlüsseln. Der Umbau macht nicht nur DAX einfacher zu schreiben. Er entfernt die zusätzliche Join-Logik und die Filterpfade, durch die die Engine pro Visual mehr Arbeit hatte. Deshalb zählen Beziehungs- und Kardinalitätsdesign bei einem langsamen Report meist mehr als das Umschreiben von DAX.

Fazit

Bei der Performance von Power BI geht es selten nur um Hardware oder Datenmenge. Häufiger liegt das eigentliche Problem in den Beziehungen, der Kardinalität oder der Modellstruktur. Wenn Sie saubere Eins-zu-viele-Beziehungen entwerfen, Schlüssel mit hoher Kardinalität minimieren und den Prinzipien des Sternschema folgen, kann die VertiPaq-Engine mit voller Effizienz arbeiten, noch bevor Sie DAX abstimmen.

Bei CaseWhen beginnen wir Performance-Arbeit damit, den Datenfluss durch die Beziehungen zu prüfen, nicht damit, zuerst Measures umzuschreiben. Diese Prüfung umfasst typischerweise die Architektur des Datenmodells, eine Kardinalitätsprüfung der Beziehungsschlüssel, den Umbau der Beziehungen zu einem Sternschema und die Vereinfachung von DAX, sobald das Modell selbst stimmt.

FAQs

Was ist Kardinalität in Power BI?

Kardinalität legt fest, wie Zeilen zweier Tabellen zusammenhängen, etwa Eins-zu-viele oder Viele-zu-viele. Die passende Kardinalität einer Beziehung verbessert, wie effizient Power BI darüber filtern und aggregieren kann.

Warum sind Viele-zu-viele-Beziehungen in Power BI langsam?

Sie bringen Mehrdeutigkeit mit, die Power BI zur Abfragezeit mit zusätzlicher Join-Logik auflöst. Das erhöht die Arbeit der Engine für jedes Visual, das die Beziehung berührt.

Welcher Beziehungstyp ist für die Performance am besten?

Eins-zu-viele-Beziehungen in einem Sternschema, bei dem Dimensionstabellen in eine zentrale Faktentabelle filtern.

Beeinflusst die Beziehungsrichtung die Performance?

Ja. Einseitige Filterung von der Dimension zum Fakt ist schneller und berechenbarer als bidirektionale Filterung, die ausweitet, wie weit sich ein Filter durch das Modell ausbreitet.

Quellen

• Relationships in Power BI Desktop - Microsoft Learn

• USERELATIONSHIP function (DAX) - Microsoft Learn