Modellieren von Beziehungen in Power BI Desktop

Dieser Artikel richtet sich an Modellierer von Importdaten, die mit Power BI Desktop arbeiten. Es geht um ein wichtiges Thema beim Entwurf von Modellen, das von essenzieller Bedeutung für die Bereitstellung intuitiver, präziser und optimaler Modelle ist.

Eine ausführlichere Erläuterung zum optimalen Modellentwurf, einschließlich Tabellenrollen und Beziehungen, finden Sie unter Informationen zum Sternschema und der Wichtigkeit für Power BI.

Zweck von Beziehungen

Eine Modellbeziehung gibt auf die Spalte einer Modelltabelle angewendete Filter an eine andere Modelltabelle weiter. Filter werden so lange weitergegeben, wie ein Beziehungspfad verfolgt werden kann, woraus die Weitergabe an mehrere Tabellen resultieren kann.

Beziehungspfade sind deterministisch, d. h., Filter werden immer auf die gleiche Weise und ohne zufällige Variation weitergegeben. Beziehungen können jedoch deaktiviert werden, oder ihr Filterkontext wird durch Modellberechnungen geändert, die bestimmte DAX-Funktionen verwenden. Weitere Informationen finden Sie weiter unten in diesem Artikel im Thema Relevante DAX-Funktionen.

Hier erfahren Sie anhand eines animierten Beispiels, wie Beziehungen Filter weitergeben.

In diesem Beispiel besteht das Modell aus vier Tabellen: Category, Product, Year und Sales. Die Tabelle Category bezieht sich auf die Tabelle Product und die Tabelle Product auf die Tabelle Sales. Die Tabelle Year bezieht sich auch auf die Tabelle Sales. Alle Beziehungen sind 1:n-Beziehungen (Näheres hierzu erfahren Sie später in diesem Artikel).

Eine – möglicherweise von einem Power BI-Kartenvisual generierte – Abfrage fordert die Gesamtverkaufsmenge für Verkaufsaufträge an, die für eine einzelne Kategorie, Cat-A, und für ein einzelnes Jahr, CY2018, getätigt wurden. Aus diesem Grund sehen Sie, dass Filter auf die Tabellen Category und Year angewendet werden. Der Filter für die Tabelle Category wird an die Tabelle Product weitergegeben, um zwei Produkte der Kategorie Cat-A zu isolieren. Anschließend werden die Filter der Tabelle Product an die Tabelle Sales weitergegeben, um zwei Verkaufszeilen für diese Produkte zu isolieren. Diese zwei Verkaufszeilen stellen die Verkäufe von Produkten der Kategorie Cat-A dar. Die kombinierte Menge beträgt 14 Einheiten. Gleichzeitig wird der Filter der Tabelle Year weitergegeben, um die Tabelle Sales weiter zu filtern. Daraus resultiert nur eine Verkaufszeile für Produkte, die der Kategorie Cat-A zugewiesen sind und im Jahr CY2018 bestellt wurden. Der von der Abfrage zurückgegebene Mengenwert beträgt 11 Einheiten. Beachten Sie Folgendes: Wenn mehrere Filter auf eine Tabelle angewendet werden (wie z. B. auf die Tabelle Sales in diesem Beispiel), ist es immer eine AND-Operation, die erfordert, dass alle Bedingungen erfüllt sind.

Anwenden von Sternschema-Entwurfsprinzipien

Wir empfehlen Ihnen die Anwendung der Sternschema-Entwurfsprinzipien, um ein Modell mit Dimensions- und Faktentabellen zu erstellen. Es ist üblich, Power BI einzurichten, um Regeln zu erzwingen, die Dimensionstabellen filtern, damit Modellbeziehungen diese Filter effizient an Faktentabellen weitergeben können.

Die folgende Abbildung zeigt das Modelldiagramm des Datenmodells für die Verkaufsanalyse von Adventure Works. Sie zeigt ein Sternschema mit einer einzelnen Faktentabelle für die Umsätze. Bei den anderen vier Tabellen handelt es sich um Dimensionstabellen, die die Analyse von Verkaufsmaßnahmen nach Datum, Bundesstaat, Region und Produkt unterstützen. Beachten Sie die Modellbeziehungen, die alle Tabellen verbinden. Diese Beziehungen verteilen Filter (direkt oder indirekt) auf die Tabelle mit den Umsätzen.

Getrennte Tabellen

Es ist ungewöhnlich, dass eine Modelltabelle nicht mit einer anderen Modelltabelle verknüpft ist. Eine solche Tabelle in einem gültigen Modellentwurf wird als getrennte Tabelle bezeichnet. Eine getrennte Tabelle ist nicht für die Weitergabe von Filtern an andere Modelltabellen vorgesehen. Sie akzeptiert stattdessen „Benutzereingaben“ (möglicherweise mit einem Datenschnittvisual), sodass der Eingabewert auf sinnvolle Weise für Modellberechnungen verwendet werden kann. Stellen Sie sich beispielsweise eine getrennte Tabelle vor, in die ein Bereich von Währungswerten mit Wechselkursen geladen wird. Solange ein Filter angewendet wird, um nach einem einzelnen Kurswert zu filtern, kann dieser Wert von einem Measureausdruck verwendet werden, um Verkaufswerte zu konvertieren.

Der What-if-Parameter von Power BI Desktop ist ein Feature, das eine getrennte Tabelle erstellt. Weitere Informationen finden Sie unter Erstellen und Verwenden eines Was-wäre-wenn-Parameters (What if) zum Visualisieren von Variablen in Power BI Desktop.

Beziehungseigenschaften

In einer Modellbeziehung ist eine Spalte in einer Tabelle mit einer Spalte in einer anderen Tabelle verknüpft. (Es gibt einen speziellen Fall, in dem diese Anforderung nicht gilt, und zwar nur bei mehrspaltigen Beziehungen in DirectQuery-Modellen. Weitere Informationen finden Sie im Artikel zur DAX-Funktion COMBINEVALUES.)

Datentypen für Spalten

Der Datentyp für die Spalte "from" und "to" der Beziehung sollte identisch sein. Beziehungen, die für DateTime-Spalten definiert sind, verhalten sich möglicherweise nicht wie erwartet. Die Engine, die Power BI-Daten speichert, verwendet nur DateTime-Datentypen. Die Datentypen Date (Datum), Time (Uhrzeit) und Date/Time/Timezone Datum/Uhrzeit/Zeitzone) sind zusätzlich implementierte Power BI-Formatierungsbausteine. Alle modellabhängigen Objekte werden in der Engine weiterhin als DateTime angezeigt (z. B. Beziehungen, Gruppen usw.). Wenn ein Benutzer also Date (Datum) auf der Registerkarte Modeling (Modellierung) für solche Spalten auswählt, werden sie trotzdem nicht mit demselben Datum registriert, da der Zeitanteil der Daten von Analysis Services noch berücksichtigt wird. Erfahren Sie mehr darüber, wie Date/Time-Typen behandelt werden. Um dieses Verhalten zu korrigieren, aktualisieren Sie die Datentypen der Spalten im Power Query-Editor, um den Zeitanteil aus den importierten Daten zu entfernen, damit die Werte bei der Verarbeitung der Daten durch die Engine gleich angezeigt werden.

Kardinalität

Jede Modellbeziehung wird durch einen Kardinalitätstyp definiert. Es gibt vier Kardinalitätstypoptionen, die die Dateneigenschaften der „von“- und „zu“-verknüpften Spalten darstellen. Die „one“-Seite bedeutet, dass die Spalte eindeutige Werte enthält; die „many“-Seite bedeutet, dass die Spalte doppelte Werte enthalten kann.

Die vier Optionen, zusammen mit ihren Kurzschreibweisen, werden in der folgenden Aufzählung beschrieben:

• 1:n (1:*)
• Viele-zu-einer (n:1)
• Eins-zu-eins (1:1)
• m:n (*:*)

Wenn Sie in Power BI Desktop eine Beziehung erstellen, erkennt der Designer den Kardinalitätstyp automatisch und legt ihn fest. Power BI Desktop fragt das Modell ab, um zu ermitteln, welche Spalten eindeutige Werte enthalten. Bei Importmodelle verwendet der Designer interne Speicherstatistiken. Bei DirectQuery-Modellen sendet er Abfragen zur Profilerstellung an die Datenquelle. Manchmal können dabei aber in Power BI Desktop Fehler auftreten. Das kann passieren, wenn Tabellen noch mit Daten geladen werden müssen oder wenn Spalten, von denen Sie erwarten, dass sie doppelte Werte enthalten, derzeit eindeutige Werte enthalten. In beiden Fällen können Sie den Kardinalitätstyp aktualisieren, sofern alle Spalten der 1-Seite eindeutige Werte enthalten (oder noch Datenzeilen in die Tabelle geladen werden müssen).

Kardinalität 1:n (Eins-zu-Viele) (und n:1 (Viele-zu-Eins))

Die Kardinalitätsoptionen1:n und n:1 sind im Wesentlichen identisch und auch die gängigsten Kardinalitätstypen.

Beim Konfigurieren einer 1:n- oder n:1-Beziehung wählen Sie den Wert aus, der der Reihenfolge entspricht, in der Sie die Spalten verknüpft haben. Überlegen Sie, wie Sie die Beziehung zwischen der Tabelle Product und der Tabelle Sales mithilfe der in beiden Tabellen vorhandenen Spalte ProductID konfigurieren würden. Der Kardinalitätstyp wäre 1:n, da die Spalte ProductID in der Tabelle Product eindeutige Werte enthält. Wenn Sie die Tabellen in umgekehrter Richtung verknüpfen würden – Sales zu Product – wäre die Kardinalität n:1.

Kardinalität 1:1 (Eins-zu-Eins)

Eine 1:1-Beziehung bedeutet, dass beide Spalten eindeutige Werte enthalten. Dieser Kardinalitätstyp ist nicht gängig und weist aufgrund der Speicherung redundanter Daten eher auf einen suboptimalen Modellentwurf hin.

Weitere Informationen zur Verwendung dieses Kardinalitätstyps finden Sie im Leitfaden zu 1:1-Beziehungen.

Kardinalität m:n (Viele-zu-Viele)

Eine m:n-Beziehung bedeutet, dass beide Spalten doppelte Werte enthalten können. Dieser Kardinalitätstyp wird selten verwendet. Er ist in der Regel nützlich, wenn komplexe Modellanforderungen entworfen werden. Sie können sie verwenden, um viele Fakten mit vielen Fakten zu verknüpfen oder Fakten mit größerem Aggregationsintervall zu verknüpfen. Wenn z. B. Verkaufszieldaten auf Produktkategorieebene gespeichert werden und die Produktdimensionstabelle auf Produktebene gespeichert wird.

Hinweise zur Verwendung dieses Kardinalitätstyps finden Sie unter Leitfaden zu m:n-Beziehungen.

Kreuzfilterrichtung

Jede Modellbeziehung wird mit einer Kreuzfilterrichtung definiert. Ihre Auswahl bestimmt die Richtungen, in denen die Filter weitergegeben werden. Die möglichen Kreuzfilteroptionen sind vom Kardinalitätstyp abhängig.

Einzelne Kreuzfilterrichtung bedeutet „einzelne Richtung“ und Beide bedeutet „beide Richtungen“. Eine Beziehung, die in beide Richtungen filtert, wird häufig als bidirektional beschrieben.

Bei 1:n-Beziehungen verläuft die Kreuzfilterrichtung immer von der „Eins“-Seite und optional von der „Viele“-Seite (bidirektional). Bei 1:1-Beziehungen verläuft die Kreuzfilterrichtung immer von beiden Tabellen aus. Schließlich kann bei m:n-Beziehungen die Kreuzfilterrichtung von einer der Tabellen oder von beiden verlaufen. Beachten Sie: Wenn der Kardinalitätstyp eine „Eins“-Seite enthält, werden Filter immer von dieser Seite weitergegeben.

Wenn die Kreuzfilterrichtung auf Beide festgelegt ist, wird eine andere Eigenschaft verfügbar. Diese kann eine bidirektionale Filterung anwenden, wenn Power BI Sicherheitsregeln auf Zeilenebene (RLS) erzwingt. Weitere Informationen zur Sicherheit auf Zeilenebene finden Sie unter Einschränken des Datenzugriffs mit Sicherheit auf Zeilenebene (RLS) für Power BI Desktop.

Sie können die Kreuzfilterrichtung der Beziehung ändern, einschließlich der Deaktivierung der Filterweitergabe, indem Sie eine Modellberechnung verwenden. Hierzu wird die DAX-Funktion CROSSFILTER verwendet.

Denken Sie daran, dass bidirektionale Beziehungen negative Auswirkungen auf die Leistung haben können. Außerdem kann der Versuch, eine bidirektionale Beziehung zu konfigurieren, zu mehrdeutigen Filterweitergabe-Pfaden führen. In diesem Fall kann Power BI Desktop die Beziehungsänderung möglicherweise nicht committen, sodass Sie eine Fehlermeldung erhalten. Manchmal kann Power BI Desktop Ihnen jedoch ermöglichen, mehrdeutige Beziehungspfade zwischen Tabellen zu definieren. Die Auflösung von Beziehungspfad-Mehrdeutigkeiten wird später in diesem Artikel beschrieben.

Sie sollten die bidirektionale Filterung nur bei Bedarf verwenden. Weitere Informationen finden Sie im Leitfaden zu bidirektionalen Beziehungen.

Diese Beziehung aktivieren

Zwischen zwei Modelltabellen kann nur ein einziger aktiver Filterweitergabe-Pfad vorhanden sein. Es ist jedoch möglich, zusätzliche Beziehungspfade einzuführen, obwohl Sie diese Beziehungen als inaktiv festlegen müssen. Inaktive Beziehungen können nur während der Auswertung einer Modellberechnung aktiviert werden. Hierzu wird die DAX-Funktion USERELATIONSHIP verwendet.

Im Allgemeinen wird empfohlen, nach Möglichkeit aktive Beziehungen zu definieren. Sie erweitern den Umfang und das Potenzial, wie Berichtsautoren Ihr Modell verwenden können. Die ausschließliche Verwendung von aktiven Beziehungen bedeutet, dass Dimensionstabellen mit unterschiedlichen Rollen in Ihrem Modell dupliziert werden sollten.

Unter bestimmten Umständen können Sie jedoch eine oder mehrere inaktive Beziehungen für eine Dimensionstabelle mit unterschiedlichen Rollen definieren. Erwägen Sie diesen Entwurf in den folgenden Fällen:

• Es gibt keine Anforderung, dass Berichtsvisuals gleichzeitig nach unterschiedlichen Rollen filtern müssen.
• Sie verwenden die DAX-Funktion USERELATIONSHIP, um eine bestimmte Beziehung für relevante Modellberechnungen zu aktivieren.

Weitere Informationen finden Sie unter Aktive und inaktive Beziehungen im Vergleich – Leitfaden.

Referenzielle Integrität voraussetzen

Die Eigenschaft Referenzielle Integrität voraussetzen ist nur für 1:n- und 1:1-Beziehungen zwischen zwei DirectQuery-Speichermodustabellen verfügbar, die zur selben Quellgruppe gehören. Sie können diese Eigenschaft nur aktivieren, wenn die Spalte auf der Seite „Viele” keine NULLen enthält.

Wenn sie aktiviert ist, werden die beiden Tabellen von nativen Abfragen, die an die Datenquelle gesendet werden, mit einem INNER JOIN statt eines OUTER JOIN verknüpft. Die Abfrageleistung wird mit Aktivierung dieser Eigenschaft somit generell verbessert, obwohl dies von den Besonderheiten der Datenquelle abhängt.

Aktivieren Sie diese Eigenschaft immer, wenn zwischen den beiden Tabellen eine Fremdschlüsseleinschränkung für Datenbanken vorhanden ist. Selbst wenn keine Fremdschlüsseleinschränkung vorhanden ist, sollten Sie die Aktivierung der Eigenschaft in Betracht ziehen, sofern Sie sicher sind, dass die Datenintegrität gegeben ist.

Relevante DAX-Funktionen

Es gibt mehrere DAX-Funktionen, die für Modellbeziehungen relevant sind. Jede Funktion wird in der folgenden Aufzählung kurz beschrieben:

• Die Funktion RELATEDruft den Wert der „1:“-Seite einer Beziehung ab. Sie ist nützlich, wenn Berechnungen aus verschiedenen Tabellen einbezogen werden, die im Zeilenkontext ausgewertet werden.
• Die Funktion RELATEDTABLEruft den Wert der „:n“-Seite einer Beziehung ab.
• USERELATIONSHIP: Ermöglicht einer Berechnung, eine inaktive Beziehung zu verwenden. (Technisch ändert diese Funktion die Gewichtung einer bestimmten inaktiven Modellbeziehung, was dazu beiträgt, ihre Verwendung zu beeinflussen.) Das ist nützlich, wenn Ihr Modell eine Rollenspiel-Dimensionstabelle enthält, und Sie entscheiden, inaktive Beziehungen aus dieser Tabelle zu erstellen. Sie können diese Funktion auch verwenden, um die Mehrdeutigkeit in Filterpfaden zu lösen.
• CROSSFILTER: Ändert die Kreuzfilterrichtung der Beziehung (in „einzeln“ oder „beide“) oder deaktiviert die Filterweitergabe (keine). Sie ist nützlich, wenn Sie Modellbeziehungen während der Auswertung einer bestimmten Berechnung ändern oder ignorieren müssen.
• COMBINEVALUES: Verbindet zwei oder mehr Textzeichenfolgen zu einer einzigen Textzeichenfolge. Der Zweck dieser Funktion besteht darin, Mehrspaltenbeziehungen in DirectQuery-Modellen zu unterstützen, wenn Tabellen zur selben Quellgruppe gehören.
• TREATAS: Wendet das Ergebnis eines Tabellenausdrucks als Filter auf Spalten aus einer nicht verknüpften Tabelle an Sie ist hilfreich in komplexeren Szenarien, wenn Sie während der Auswertung einer bestimmten Berechnung eine virtuelle Beziehung erstellen möchten.
• Übergeordnete und untergeordnete Funktionen sind eine Familie verwandter Funktionen, mit denen berechnete Spalten generiert werden können, um eine Über-/Unterordnungshierarchie einzurichten. Anschließend können Sie dann diese Spalten verwenden, um eine Hierarchie mit festen Ebenen zu erstellen.

Beziehungsauswertung

Modellbeziehungen werden aus der Perspektive der Auswertung entweder als regulär oder eingeschränkt klassifiziert. Es handelt sich nicht um eine konfigurierbare Beziehungseigenschaft. Sie wird tatsächlich vom Kardinalitätstyp und der Datenquelle der beiden verknüpften Tabellen abgeleitet. Es ist wichtig, den Auswertungstyp zu verstehen, da eine Kompromittierung der Datenintegrität Auswirkungen auf die Leistung oder sonstige Konsequenzen haben könnte. Diese Auswirkungen und die Konsequenzen für die Integrität werden in diesem Thema beschrieben.

Zuerst ist eine Modellierungstheorie erforderlich, um Beziehungsauswertungen vollständig verstehen zu können.

Ein Import- oder DirectQuery-Modell bezieht sämtliche Daten entweder aus dem Vertipaq-Cache oder der Quelldatenbank. In beiden Fällen kann Power BI bestimmen, ob die „Eins“-Seite einer Beziehung vorhanden ist.

Ein zusammengesetztes Modell kann jedoch Tabellen enthalten, die unterschiedliche Speichermodi (Import, DirectQuery oder Dual) bzw. mehrere DirectQuery-Quellen verwenden. Jede Quelle, einschließlich des Vertipaq-Caches der importierten Daten, wird als Quellgruppe betrachtet. Modellbeziehungen können dann als quellgruppenintern oder quellgruppenübergreifend klassifiziert werden. Eine quellgruppeninterne Beziehung bezieht sich auf zwei Tabellen innerhalb einer Quellgruppe, während sich eine quellgruppenübergreifende Beziehung auf Tabellen aus zwei Quellgruppen bezieht. Beachten Sie, dass Beziehungen in Import- oder DirectQuery-Modellen immer quellgruppenintern sind.

Im Folgenden sehen Sie ein Beispiel für ein zusammengesetztes Modell.

In diesem Beispiel besteht das zusammengesetzte Modell aus zwei Quellgruppen: einer Vertipaq-Quellgruppe und einer DirectQuery-Quellgruppe. Die Vertipaq-Quellgruppe enthält drei Tabellen und die DirectQuery-Quellgruppe zwei Tabellen. Eine quellgruppenübergreifende Beziehung hat den Zweck, eine Tabelle in einer Vertipaq-Quellgruppe mit einer Tabelle in einer DirectQuery-Quellgruppe zu verknüpfen.

Reguläre Beziehungen

Eine Modellbeziehung ist regulär, wenn die Abfrage-Engine die „Eins“-Seite der Beziehung bestimmen kann. Sie hat die Bestätigung, dass die Spalte der „Eins“-Seite eindeutige Werte enthält. Alle quellgruppeninternen 1:n-Beziehungen sind reguläre Beziehungen.

Im folgenden Beispiel gibt es zwei reguläre Beziehungen, die beide mit R gekennzeichnet sind. Zu den Beziehungen gehören die 1:n-Beziehung, die in der Vertipaq-Quellgruppe enthalten ist, und die 1:n-Beziehung, die in der DirectQuery-Quelle enthalten ist.

Für Importmodelle, bei denen alle Daten im Vertipaq-Cache gespeichert werden, erstellt Power BI zum Zeitpunkt der Datenaktualisierung für jede reguläre Beziehung eine Datenstruktur. Die Datenstrukturen bestehen aus indizierten Zuordnungen aller „Spalte-zu-Spalte“-Werte, und sie sollen das Verknüpfen von Tabellen zur Abfragezeit beschleunigen.

Zur Abfragezeit ermöglichen reguläre Beziehungen eine Tabellenerweiterung. Die Tabellenerweiterung führt zum Erstellen einer virtuellen Tabelle, indem die nativen Spalten der Basistabelle einbezogen und dann in verknüpfte Tabellen erweitert werden. Bei Importtabellen erfolgt die Tabellenerweiterung in der Abfrage-Engine, für DirectQuery-Tabellen in der nativen Abfrage, die an die Quelldatenbank gesendet wird (sofern die Eigenschaft Referenzielle Integrität voraussetzen nicht aktiviert ist). Die Abfrage-Engine bearbeitet dann die erweiterte Tabelle, wendet Filter an und führt eine Gruppierung nach den Werten in den Spalten der erweiterten Tabelle durch.

Bei 1:n-Beziehungen erfolgt die Tabellenerweiterung von der „Viele“ (n)- zur „Eins“ (1)-Seite mithilfe der LEFT OUTER JOIN-Semantik. Wenn kein übereinstimmender Wert in der „Viele“- und „Eins“-Seite vorhanden ist, wird der „Eins“-Seiten-Tabelle eine leere virtuelle Zeile hinzugefügt. Dieses Verhalten gilt nur für reguläre Beziehungen, nicht für eingeschränkte Beziehungen.

Die Tabellenerweiterung wird auch für quellgruppeninterne 1:1-Beziehungen durchgeführt, jedoch mithilfe der FULL OUTER JOIN-Semantik. Dieser Join-Typ stellt sicher, dass, falls nötig, auf beiden Seiten leere virtuelle Zeilen hinzugefügt werden.

Leere virtuelle Zeilen sind tatsächlich unbekannte Elemente. Unbekannte Elemente stellen Verstöße gegen die referenzielle Integrität dar, wobei für den Wert der „Viele“-Seite kein entsprechender „Eins“-Seiten-Wert vorhanden ist. Idealerweise sollten diese leeren Zeilen nicht vorhanden sein. Sie können durch Bereinigung oder Reparatur der Quelldaten entfernt werden.

Hier sehen Sie nun anhand eines animierten Beispiels, wie die Tabellenerweiterung funktioniert.

In diesem Beispiel besteht das Modell aus drei Tabellen: Category, Product und Year. Die Tabelle Category ist mit einer 1:n-Beziehung mit der Tabelle Product verknüpft, und die Tabelle Product ist mit einer 1:n-Beziehung mit der Tabelle Sales verknüpft. Die Tabelle Category enthält zwei Zeilen, die Tabelle Product drei Zeilen und die Tabelle Sales fünf Zeilen. Es gibt auf beiden Seiten aller Beziehungen übereinstimmende Werte, was bedeutet, dass keine Verletzungen der referenziellen Integrität vorliegen. Eine erweiterte Tabelle zur Abfragezeit wird angezeigt. Die Tabelle besteht aus den Spalten aller drei Tabellen. Es handelt sich tatsächlich um eine denormalisierte Perspektive der in den drei Tabellen enthaltenen Daten. Der Sales-Tabelle wird eine neue Zeile hinzugefügt, und sie verfügt über einen Produktionsbezeichnerwert (9), für den es keine Übereinstimmung in der Product-Tabelle gibt. Dies ist ein Verstoß gegen die referenzielle Integrität. In der erweiterten Tabelle enthält die neue Zeile (leere) Werte für die Tabellenspalten Category und Product.

Eingeschränkte Beziehungen

Eine Modellbeziehung ist eingeschränkt, wenn keine garantierte „Eins“-Seite vorhanden ist. Eine eingeschränkte Beziehung kann aus zwei Gründen entstehen:

• In der Beziehung wird ein m:n-Kardinalitätstyp verwendet (auch wenn eine oder beide Spalten eindeutige Werte enthalten).
• Die Beziehung ist quellgruppenübergreifend (was überhaupt nur bei zusammengesetzten Modellen der Fall sein kann).

Im folgenden Beispiel gibt es zwei eingeschränkte Beziehungen, die beide mit L gekennzeichnet sind. Zu den beiden Beziehungen gehören die in der Vertipaq-Quellgruppe enthaltene m:n-Beziehung sowie die quellgruppenübergreifende 1:n-Beziehung.

Bei Importmodellen werden für eingeschränkte Beziehungen nie Datenstrukturen erstellt. In diesem Fall löst Power BI Tabellenverknüpfungen zur Abfragezeit auf.

Tabellenerweiterungen werden nie für eingeschränkte Beziehungen durchgeführt. Tabellenverknüpfungen werden mithilfe der INNER JOIN-Semantik erzielt. Aus diesem Grund werden keine leeren virtuellen Zeilen hinzugefügt, um Verletzungen der referenziellen Integrität zu kompensieren.

Es gelten noch anderen Einschränkungen in Bezug auf eingeschränkte Beziehungen:

• Die Spaltenwerte der „Eins“-Seite können nicht mit der DAX-Funktion RELATED abgerufen werden.
• Das Erzwingen von RLS unterliegt Topologieeinschränkungen.

Auflösen der Beziehungspfad-Mehrdeutigkeit

Bidirektionale Beziehungen können mehrere – und somit mehrdeutige – Filterweitergabepfade zwischen Modelltabellen einführen. Bei der Auswertung von Mehrdeutigkeiten wählt Power BI den Filterweiterleitungspfad gemäß seiner Priorität und Gewichtung aus.

Priority

Prioritätsebenen definieren eine Abfolge von Regeln, die Power BI zum Auflösen von Beziehungspfad-Mehrdeutigkeiten verwendet. Die erste Regelübereinstimmung legt den Pfad fest, dem Power BI folgen wird. In jeder der folgenden Regeln wird der Flow von Filtern von einer Quelltabelle zu einer Zieltabelle beschrieben.

1. Ein Pfad, der aus 1:n-Beziehungen besteht.
2. Ein Pfad, der aus 1:n- oder n:n-Beziehungen besteht.
3. Ein Pfad, der aus n:1-Beziehungen besteht.
4. Ein Pfad aus 1:n-Beziehungen von der Quelltabelle zu einer Zwischentabelle besteht, gefolgt von n:1-Beziehungen von der Zwischentabelle zur Zieltabelle.
5. Ein Pfad aus 1:n- oder n:n-Beziehungen von der Quelltabelle zu einer Zwischentabelle besteht, gefolgt von n:1- oder n:n-Beziehungen von der Zwischentabelle zur Zieltabelle.
6. Jeder beliebige andere Pfad.

Wenn eine Beziehung in allen verfügbaren Pfaden enthalten ist, wird sie aus allen Pfaden entfernt.

Weight

Jede Beziehung in einem Pfad hat eine Gewichtung. Standardmäßig ist jede Beziehungsgewichtung gleich, es sei denn, es wird die USERELATIONSHIP-Funktion verwendet. Die Pfadgewichtung ist das Maximum aller Beziehungsgewichte entlang des Pfads. Power BI verwendet die Pfadgewichtung, um Mehrdeutigkeit zwischen mehreren Pfaden in derselben Prioritätsstufe aufzulösen. Es wählt keinen Pfad mit niedrigerer Priorität aus, sondern den Pfad mit der höheren Gewichtung. Die Anzahl der Beziehungen im Pfad wirkt sich nicht auf die Gewichtung aus.

Sie können die Gewichtung einer Beziehung mithilfe der USERELATIONSHIP-Funktion beeinflussen. Die Gewichtung wird durch die Schachtelungsebene des Aufrufs dieser Funktion bestimmt, wobei der innerste Aufruf die höchste Gewichtung erhält.

Betrachten Sie das folgende Beispiel. Das Product Sales-Maß weist der Beziehung zwischen Sales[ProductID] und Product[ProductID] eine höhere Gewichtung zu, gefolgt von der Beziehung zwischen Inventory[ProductID] und Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Leistungspräferenz

In der folgenden Liste sind die Beziehungen nach ihrer Filterweitergabe-Leistung von der höchsten bis zur niedrigsten sortiert:

1. quellgruppeninterne 1:n-Beziehungen
2. m:n-Modellbeziehungen, die mit einer Zwischentabelle erzielt werden und mindestens eine bidirektionale Beziehung beinhalten
3. M:n-Kardinalitätsbeziehungen
4. quellgruppenübergreifende Beziehungen

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Ressourcen:

• Informationen zum Sternschema und dessen Wichtigkeit für Power BI
• Leitfaden zu 1:1-Beziehungen
• Leitfaden zu m:n-Beziehungen
• Aktive und inaktive Beziehungen im Vergleich – Leitfaden
• Leitfaden zu bidirektionalen Beziehungen
• Leitfaden zur Problembehandlung bei Beziehungen
• Video: Worauf Sie bei Power BI-Beziehungen achten sollten
• Haben Sie Fragen? Stellen Sie Ihre Frage in der Power BI-Community.
• Vorschläge? Einbringen von Ideen zur Verbesserung von Power BI