Leitfaden für aktive und inaktive Beziehungen

Dieser Artikel zielt auf Sie als Datenmodellierer ab, der mit Power BI Desktop arbeitet. Sie erhalten Hinweise, wann Sie aktive oder inaktive Modellbeziehungen erstellen sollten. Standardmäßig propagieren aktive Beziehungen Filter auf andere Tabellen. Inaktive Beziehungen dagegen geben Filter nur dann weiter, wenn die Beziehung über einen DAX-Ausdruck aktiviert (verwendet) wird.

Anmerkung

Eine Einführung in Modellbeziehungen wird in diesem Artikel nicht behandelt. Wenn Sie nicht vollständig mit Beziehungen, deren Eigenschaften oder deren Konfiguration vertraut sind, empfehlen wir Ihnen, zuerst den Artikel Modellbeziehungen in Power BI Desktop zu lesen.

Außerdem sollten Sie mit dem Sternschemadesign gut vertraut sein. Weitere Informationen finden Sie im Artikel Informationen zum Sternschema und der Wichtigkeit für Power BI.

Aktive Beziehungen

Im Allgemeinen wird empfohlen, aktive Beziehungen nach Möglichkeit zu definieren. Aktive Beziehungen erweitern den Umfang und das Potenzial der Nutzung Ihres Modells durch Berichtsautoren und durch Benutzende, die mit Q&A arbeiten.

Betrachten wir ein Beispiel eines Importmodells zum Analysieren der Pünktlichkeit von Flügen. Das Modell enthält die Tabelle Flight. Hierbei handelt es sich um eine Faktentabelle, in der ein Flug pro Zeile gespeichert wird. Jede Zeile zeichnet das Flugdatum, die Flugnummer, die Abflug- und Ankunftsflughäfen sowie jede Verzögerungszeit (in Minuten) auf. Darüber hinaus enthält es die Tabelle Airport. Hierbei handelt es sich um eine Dimensionstabelle, in der pro Zeile ein Flughafen gespeichert wird. Jede Zeile beschreibt den Flughafencode, den Flughafennamen und das Land oder die Region.

Nachfolgend ist ein Teil eines Modelldiagramms der beiden Tabellen dargestellt.

Es gibt zwei Modellbeziehungen zwischen den Tabellen Flight und Airport. In der Flight-Tabelle beziehen sich die Spalten DepartureAirport und ArrivalAirport auf die Airport-Spalte der Airport-Tabelle. In einem Design mit Sternschema wird die Tabelle Airport als Dimension mit unterschiedlichen Rollen beschrieben. In diesem Modell sind die beiden Rollen Abflugflughafen und Ankunftsflughafen.

Dieses Design eignet sich zwar gut für relationale Starschemadesigns, funktioniert aber nicht gut für Power BI-Modelle. Das liegt daran, dass Modellbeziehungen Pfade für die Filterverteilung sind und diese Pfade deterministisch sein müssen. Weitere Informationen zum Sicherstellen, dass Filterverteilungspfade deterministisch sind, finden Sie unter Auflösen der Beziehungspfadmehrdeutigkeit. Daher – wie in diesem Beispiel dargestellt – ist eine Beziehung aktiv, während die andere inaktiv ist (dargestellt durch die gestrichelte Linie). Die Beziehung zur Spalte ArrivalAirport ist die aktive Beziehung. Das bedeutet, dass auf die Tabelle Airport angewendete Filter automatisch auf die Spalte ArrivalAirport der Tabelle Flight übertragen werden.

Dieser Entwurf des Modells legt schwerwiegende Einschränkungen darüber fest, wie die Daten gemeldet werden können. Insbesondere ist es nicht möglich, die Tabelle Airport zu filtern, um Flugdetails für einen Abflugflughafen automatisch zu extrahieren. Da Berichte nach Abflug- und Ankunftsflughäfen gleichzeitig gefiltert (oder gruppiert) werden müssen, sind zwei aktive Beziehungen erforderlich. Das Übersetzen dieser Anforderung in ein Power BI-Modelldesign bedeutet, dass das Modell über zwei Flughafentabellen verfügen muss.

Hier sehen Sie das verbesserte Modelldesign.

Das Modell enthält jetzt zwei Flughafentabellen: Departure Airport und Arrival Airport. Jede Modellbeziehung zwischen diesen Tabellen und der Flight Tabelle ist aktiv. Beachten Sie auch, dass die Spaltennamen in den Tabellen Departure Airport und Arrival Airport dem Wort Abflug oder Ankunftvorangestellt sind.

Der verbesserte Modellentwurf unterstützt das Generieren des folgenden Berichtsdesigns.

Die Berichtsseite filtert Melbourne als Abflughafen heraus, und das Tabellenvisual führt eine Gruppierung nach Ankunftsflughäfen durch.

Anmerkung

Bei Importmodellen hat das Hinzufügen einer weiteren Dimensionstabelle zu einer erhöhten Modellgröße und längeren Aktualisierungszeiten geführt. Dies widerspricht den im Artikel Verfahren zur Datenreduktion für die Importmodellierung beschriebenen Empfehlungen. In dem Beispiel setzt jedoch die Anforderung, nur aktive Beziehungen zu haben, diese Empfehlungen außer Kraft.

Darüber hinaus ist es üblich, dass Dimensionstabellen im Vergleich zu Faktentabellen niedrige Zeilenanzahlen aufweisen. Das Modell ist deshalb wahrscheinlich nicht übermäßig größer, und die Aktualisierungszeiten sind nicht übermäßig länger.

Methodik der Umgestaltung

Nachfolgend wird eine Methodik zum Umgestalten eines Modells von einer einzelnen Dimensionstabelle mit unterschiedlichen Rollen zu einem Entwurf mit einer Tabelle pro Rolle vorgestellt.

1. Entfernen Sie alle inaktiven Beziehungen.

2. Erwägen Sie eine Umbenennung der Dimensionstabelle mit unterschiedlichen Rollen, um ihre Rolle besser zu beschreiben. Im Beispiel in diesem Artikel bezieht sich die Airport Tabelle auf die ArrivalAirport Spalte der Flight Tabelle, sodass sie in Arrival Airportumbenannt wird.

3. Erstellen Sie eine Kopie der Rollenspieltabelle und geben Sie ihr einen Namen, der ihre Rolle widerspiegelt. Wenn es sich um eine Importtabelle handelt, empfehlen wir, eine berechnete Tabelle zu erstellen. Wenn es sich um eine DirectQuery-Tabelle handelt, können Sie die Power Query-Abfrage duplizieren.

   Im Beispiel wurde die Departure Airport Tabelle mithilfe der folgenden berechneten Tabellendefinition erstellt.

   Departure Airport = 'Arrival Airport'
   

4. Erstellen Sie eine aktive Beziehung, um die neue Tabelle zuzuordnen.

5. Erwägen Sie, die Spalten in den Tabellen umzubenennen, damit sie ihre Rolle genau widerspiegeln. Im Beispiel in diesem Artikel erhielten alle Spalten das Präfix Departure oder Arrival. Diese Namen stellen sicher, dass visuelle Berichte standardmäßig selbstbeschreibende und nicht mehrdeutige Beschriftungen aufweisen. Außerdem wird die Erfahrung mit Q&A verbessert, wodurch Benutzer problemlos präzise Fragen formulieren können.

6. Erwägen Sie das Hinzufügen von Beschreibungen zu Tabellen mit mehreren Rollen. (Im Bereich Daten wird eine Beschreibung in einer QuickInfo angezeigt, wenn ein Berichtsautor mit dem Cursor auf die Tabelle zeigt.) Auf diese Weise können Sie zusätzliche Details zur Filterweitergabe für Ihre Berichtsautoren bereitstellen.

Inaktive Beziehungen

Unter bestimmten Umständen können inaktive Beziehungen besondere Anforderungen an die Berichterstattung erfüllen.

Berücksichtigen Sie unterschiedliche Modell- und Berichterstellungsanforderungen:

• Ein Vertriebsmodell enthält die Tabelle Sales mit zwei Datenspalten: OrderDate und ShipDate.
• Jede Zeile in Tabelle Sales zeichnet eine einzelne Bestellung auf.
• Datumsfilter werden fast immer auf die OrderDate Spalte angewendet, die immer ein gültiges Datum speichert.
• Nur ein Measure erfordert die Weitergabe des Datumsfilters in der Spalte ShipDate, die (bis zum Versand der Bestellung) LEERE Werte enthalten kann.
• Es ist nicht erforderlich, eine gleichzeitige Filterung (oder Gruppierung) nach Zeiträumen für Auftrags- und Versanddaten durchzuführen.

Hier ist ein Diagramm eines Teilmodells der beiden Tabellen.

Es gibt zwei Modellbeziehungen zwischen den Tabellen Sales und Date. In der Sales-Tabelle beziehen sich die OrderDate- und ShipDate-Spalten auf die Date-Spalte der Date-Tabelle. In diesem Modell lauten die zwei Rollen für die Tabelle Date: order date und ship date. Die Beziehung zur Spalte OrderDate ist die aktive Beziehung.

Alle sechs Measures – mit Ausnahme von einem – müssen nach der Spalte OrderDate gefiltert werden. Das Measure Orders Shipped muss jedoch nach der Spalte ShipDate gefiltert werden.

Nachfolgend ist das Measure Orders definiert. Es werden einfach die Zeilen der Tabelle Sales innerhalb des Filterkontextes gezählt. Alle Filter, die auf die Date Tabelle angewendet werden, werden auf die OrderDate Spalte übertragen.

Orders = COUNTROWS(Sales)

Nachfolgend wird das Measure Orders Shipped definiert. Sie verwendet die DAX-Funktion USERELATIONSHIP, die die Filterweitergabe für eine bestimmte Beziehung jedoch nur während der Auswertung des Ausdrucks aktiviert. In diesem Beispiel wird die Beziehung zur Spalte ShipDate verwendet.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Dieser Modellentwurf unterstützt das Generieren des folgenden Berichtsdesigns.

Die Berichtsseite filtert nach Quartal 2019 Q4. Das Tabellenvisual führt eine Gruppierung nach Monat durch und zeigt verschiedene Vertriebsstatistiken an. Die Measures Orders und Orders Shipped führen zu unterschiedlichen Ergebnissen. Sie verwenden jeweils die gleiche Zusammenfassungslogik (Zählen der Zeilen der Tabelle Sales), aber eine unterschiedliche Weitergabe der Date-Tabellenfilter.

Beachten Sie, dass der Slicer „Quarter“ ein LEERES Element enthält. Dieser Slicer wird als Ergebnis einer Tabellenerweiterung angezeigt. Während jede Sales-Tabellenzeile ein gültiges Auftragsdatum enthält, ist das Versanddatum in einigen Zeilen LEER – diese Bestellungen wurden noch nicht versendet. Bei der Tabellenerweiterung werden auch inaktive Beziehungen berücksichtigt, sodass LEERE Werte aufgrund von LEEREN Werten auf der n-Seite der Beziehung (oder aufgrund von Datenintegritätsproblemen) auftreten können.

Anmerkung

Sicherheitsfilter auf Zeilenebene (RLS) werden nur über aktive Beziehungen weitergegeben. RLS-Filter werden für inaktive Beziehungen nicht weitergegeben, auch dann nicht, wenn die DAX-Funktion USERELATIONSHIP von einer Measuredefinition verwendet wird.

Empfehlungen

Es wird empfohlen, wann immer möglich aktive Beziehungen zu definieren, insbesondere, wenn RLS-Rollen für Ihr Datenmodell definiert sind. Sie erweitern den Umfang und das Potenzial, wie Ihr Modell von Berichtsautoren sowie Benutzern, die mit Q&A arbeiten, verwendet werden kann. Dies 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. Sie können diesen Ansatz berücksichtigen, wenn:

• Es ist nicht erforderlich, Berichtsvisuals gleichzeitig nach unterschiedlichen Rollen zu filtern.
• Sie verwenden die USERELATIONSHIP DAX-Funktion, um eine bestimmte Beziehung für relevante Modellberechnungen zu aktivieren.

Verwandte Inhalte

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

• Modellieren von Beziehungen in Power BI Desktop
• Informationen zum Sternschema und dessen Wichtigkeit für Power BI
• Leitfaden zur Problembehandlung bei Beziehungen
• Fragen? Stellen Sie Ihre Frage in der Fabric Community
• Anregungen? Einbringen von Ideen zur Verbesserung von Fabric