Teilen über

Leitfaden zu m:n-Beziehungen

  • Artikel

Dieser Artikel zielt auf Sie als Datenmodellierer ab, der mit Power BI Desktop arbeitet. Hier werden drei verschiedene m:n-Modellierungsszenarios beschrieben. Außerdem erhalten Sie eine Anleitung, wie Sie Ihre Modelle entsprechend entwerfen können.

Anmerkung

Eine Einführung in Modellbeziehungen wird in diesem Artikel nicht behandelt. Wenn Sie sich bisher noch wenig mit Beziehungen, ihren Eigenschaften und ihrer Konfiguration beschäftigt haben, sollten Sie zuerst den Artikel Modellieren von Beziehungen in Power BI Desktop durchlesen.

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.

Es gibt drei verschiedene Arten von m:n-Beziehungen. Sie können in folgenden Szenarios auftreten:

Herstellen von Beziehungen zwischen m:n-Dimensionen

Das klassische Viele-zu-viele-Szenario bezieht sich auf zwei Entitäten, zum Beispiel Bankkunden und Bankkonten. Berücksichtigen Sie, dass Kunden mehrere Konten haben können, und Konten können mehrere Kunden haben. Wenn einem Konto mehrere Kunden zugeordnet sind, werden diese üblicherweise als Inhaber eines Gemeinschaftskontos bezeichnet.

Die Modellierung dieser Entitäten ist einfach. In einer Dimensionstabelle werden die Konten gespeichert, und in einer anderen Dimensionstabelle werden die Kunden gespeichert. Wie für Dimensionstabellen charakteristisch, gibt es in jeder Tabelle eine Spalte mit einem eindeutigen Bezeichner (ID). Um die Beziehung zwischen den beiden Tabellen zu modellieren, ist eine dritte Tabelle erforderlich. Diese Tabelle wird üblicherweise als Überbrückungstabelle bezeichnet. In diesem Beispiel ist es ihre Aufgabe, eine Zeile für jede Kunde-Konto-Zuordnung zu speichern. Ein interessanter Hinweis: Wenn diese Tabelle nur Bezeichnerspalten enthält, wird sie als faktenlose Faktentabelle bezeichnet.

Hier ist ein vereinfachtes Diagramm der drei Modelltabellen.

Diagramm mit drei Modelltabellen. Der Entwurf wird im folgenden Absatz beschrieben.

Die erste Tabelle heißt Accountund enthält zwei Spalten: AccountID und Account. Die zweite Tabelle heißt AccountCustomerund enthält zwei Spalten: AccountID und CustomerID. Die dritte Tabelle heißt Customerund enthält zwei Spalten: CustomerID und Customer. Zwischen den Tabellen bestehen keine Beziehungen.

Es wurden zwei 1:n-Beziehungen hinzugefügt, um die Tabellen aufeinander zu beziehen. Hier ist ein aktualisiertes Modelldiagramm der zugehörigen Tabellen. Es wurde eine Faktentabelle mit dem Namen Transaction hinzugefügt. Es zeichnet Kontotransaktionen auf. Die Überbrückungstabelle und alle Bezeichnerspalten wurden ausgeblendet.

Abbildung, die ein Modelldiagramm aus vier Tabellen zeigt. Es wurden 1:n-Beziehungen hinzugefügt, um alle Tabellen aufeinander zu beziehen.

Um zu beschreiben, wie die Verteilung des Beziehungsfilters funktioniert, wurde das Modelldiagramm so geändert, dass die Tabellenzeilen angezeigt werden.

Diagramm mit den Modelltabellen und deren Zeilen. Die Zeilendetails für die vier Tabellen werden im folgenden Absatz beschrieben.

In der folgenden Aufzählung sind die einzelnen Zeilen der vier Tabellen dargestellt:

  • Die Tabelle Account enthält zwei Zeilen:
    • AccountID 1 steht für Account-01
    • AccountID 2 steht für Account-02
  • Die Tabelle Customer enthält zwei Zeilen:
    • CustomerID 91 steht für Customer-91
    • CustomerID 92 steht für Customer-92
  • Die Tabelle AccountCustomer enthält drei Zeilen:
    • AccountID1 ist verbunden mit CustomerID91
    • AccountID1 ist verbunden mit CustomerID92
    • AccountID2 steht in Verbindung mit CustomerID92
  • Die Tabelle Transaction enthält drei Zeilen:
    • Date January 1 2019, AccountID1, Amount100
    • Date February 2 2019, AccountID2, Amount200
    • Date3. März 2019, AccountID1, Amount-25

Sehen wir uns an, was passiert, wenn das Modell abgefragt wird.

In der folgenden Abbildung sind zwei Tabellenvisuals dargestellt, die die Spalte Amount der Tabelle Transaction zusammenfassen. Im ersten Visual wird nach Konto gruppiert. Die Summe der Spalten Amount ergibt somit den Kontostand (Account Balance). Das zweite Visual ist nach Kunde gruppiert. Die Summe der Spalten Amount ergibt somit das Guthaben der einzelnen Kunden (Customber Balance).

Diagramm mit zwei Tabellenvisualisierungen, die nebeneinander angeordnet sind. Die visuellen Elemente werden im folgenden Absatz beschrieben.

Das erste Tabellenvisual (Account Balance) enthält zwei Spalten: Account und Amount. Es zeigt das folgende Ergebnis an:

  • Der Guthabenbetrag auf Account-01 ist 75.
  • Der Guthabenbetrag auf Account-02 ist 200.
  • Der Gesamtwert beträgt 275.

Das zweite Tabellenvisual (Customer Balance) enthält zwei Spalten: Customer und Amount. Es zeigt das folgende Ergebnis an:

  • Customer-91 hat ein Guthaben von 275.
  • Customer-92 hat ein Guthaben von 275.
  • Der Gesamtwert beträgt 275.

Ein kurzer Blick auf die Tabellenzeilen und die Kontostandsdarstellung zeigt, dass das Ergebnis für jedes Konto und den Gesamtbetrag korrekt ist. Das liegt daran, dass jede Kontozuordnung zu einer Weitergabe der Filter auf die Tabelle Transaction für das jeweilige Konto führt.

Beim Visual „Customer Balance“ ist jedoch anscheinend ein Fehler aufgetreten. Jeder Kunde in dieser Darstellung hat den gleichen Saldo wie der Gesamtsaldo. Dieses Ergebnis könnte nur korrekt sein, wenn jeder Kunde ein gemeinsamer Kontoinhaber jedes Kontos wäre. Das ist in diesem Beispiel nicht der Fall. Es gibt ein Problem, das mit der Weitergabe der Filter zu tun hat. Sie erfolgt nicht durchgängig bis zur Tabelle Transaction.

Wenn Sie sich die Richtungen der Beziehungsfilter ausgehend von der Tabelle Customer bis hin zur Tabelle Transaction genauer ansehen, erkennen Sie, dass die Beziehung zwischen der Tabelle Account und der Tabelle AccountCustomer in die falsche Richtung weitergegeben wird. Die Filterrichtung für diese Beziehung muss auf Bothfestgelegt werden.

Diagramm, das zeigt, dass das Modell aktualisiert wurde. Sie filtert jetzt in beide Richtungen.

Abbildung mit zwei gleichen Berichtsvisuals nebeneinander. Das erste Visual hat sich im Gegensatz zum zweiten nicht geändert.

Erwartungsgemäß hat sich am Visual „Account Balance“ nichts geändert.

Das Visual „Customer Balance“ zeigt nun jedoch ein anderes Ergebnis:

  • Customer-91 hat ein Guthaben von 75.
  • Customer-92 hat ein Guthaben von 275.
  • Der Gesamtwert beträgt 275.

Das Visual „Customer Balance“ zeigt nun ein korrektes Ergebnis an. Sehen Sie sich die Filterrichtungen noch einmal genau an, und versuchen Sie nachzuvollziehen, wie die Guthaben der einzelnen Kunden berechnet wurden. Machen Sie sich dabei auch bewusst, dass sich der Gesamtwert des Visuals auf alle Kunden bezieht.

Jemand, der mit den Modellbeziehungen nicht vertraut ist, könnte zu dem Schluss kommen, dass das Ergebnis falsch ist. Sie könnten fragen: Warum ist die Gesamtbilanz für Customer-91 und Customer-92 nicht gleich 350 (75 + 275)?

Damit diese Frage beantwortet werden kann, müssen Sie verstanden haben, wie m:n-Beziehungen funktionieren. Für die Guthaben einzelner Kunden können die Guthabenbeträge mehrerer Konten addiert werden, und die einzelnen Guthaben der Kunden selbst sind deshalb nicht additiv.

Leitfaden für die Herstellung von m:n-Beziehungen zwischen Dimensionen

Wenn zwischen Dimensionstabellen eine m:n-Beziehung besteht, können Sie den folgenden Leitfaden befolgen:

  • Fügen Sie jede durch eine m:n-Beziehung verbundene Entität als Modelltabelle hinzu, und achten Sie darauf, dass sie eine ID-Spalte enthält.
  • Fügen Sie eine Verbindungstabelle hinzu, um zugeordnete Entitäten zu speichern.
  • Erstellen Sie zwischen den drei Tabellen 1:n-Beziehungen.
  • Legen Sie eine bidirektionale Beziehung fest, damit Filter auf Faktentabellen weitergegeben werden können.
  • Wenn fehlende ID-Werte nicht akzeptabel sind, deaktivieren Sie die Is Nullable-Eigenschaft – die Datenaktualisierung wird fehlschlagen, wenn auf fehlende Werte zugegriffen wird.
  • Blenden Sie die Überbrückungstabelle aus, wenn sie keine weiteren Spalten oder Measures enthält, die für die Berichterstellung erforderlich sind.
  • Blenden Sie alle ID-Spalten aus, die nicht für die Berichterstellung geeignet sind (z. B. wenn die Spalten Ersatzschlüsselwerte speichern).
  • Wenn eine ID-Spalte nicht ausgeblendet werden sollte, achten Sie darauf, dass sie sich auf der „1“-Seite der Beziehung befindet. Die „n“-seitige Spalte sollten Sie immer ausblenden. Das liegt daran, dass Filter, die auf die „1“-Seite angewendet werden, besser funktionieren.
  • Um Verwirrung und Missverständnissen vorzubeugen, können Sie Erklärungen für die Benutzer Ihres Berichts hinzufügen, z. B. Erläuterungen in Textfeldern oder QuickInfos für Visualheader.

Es empfiehlt sich nicht, m:n-Beziehungen zwischen Dimensionstabellen direkt herzustellen. Für diese Art von Design muss eine Beziehung mit einer m:n-Kardinalität eingerichtet werden. Konzeptionell kann es erreicht werden, aber es impliziert, dass die zugehörigen Spalten doppelte Werte enthalten können. Es ist ein durchaus gängiger Designansatz. Die hier vorliegenden Dimensionstabellen beinhalten jedoch eine ID-Spalte. Dimensionstabellen sollten die ID-Spalte immer als „1“-Seite einer Beziehung verwenden.

Herstellen von m:n-Beziehungen zwischen Fakten

Bei einem weiteren Typ eines m:n-Szenarios sollen zwei Faktentabellen aufeinander bezogen werden. Zwei Faktentabellen können direkt miteinander verknüpft werden. Diese Entwurfstechnik kann für schnelle und einfache Datenerkundung nützlich sein. Um jedoch klar zu sein, empfehlen wir in der Regel diesen Entwurfsansatz nicht. Es wird später in diesem Abschnitt erklärt, warum.

Sehen wir uns ein Beispiel an, das zwei Faktentabellen umfasst: Order und Fulfillment. Die Order Tabelle enthält eine Zeile pro Bestellzeile, und die Fulfillment Tabelle kann null oder mehr Zeilen pro Bestellzeile enthalten. Zeilen in der tabelle Order stellen Verkaufsaufträge dar. Zeilen in der tabelle Fulfillment stellen Bestellartikel dar, die versendet wurden. Mit einer m:n-Beziehung werden die OrderID-Spalten in den einzelnen Tabellen aufeinander bezogen. Filter werden dabei nur von der Tabelle Order weitergegeben (was bedeutet, dass die Tabelle Order die Tabelle Fulfillment filtert).

Diagramm eines Modells mit den beiden Tabellen: „Order“ und „Fulfillment“.

Die Beziehungskardinalität wird auf Many-to-many festgelegt, damit das Speichern doppelter OrderID-Spaltenwerte in beiden Tabellen unterstützt wird. In der Order-Tabelle können doppelte ID-Werte vorhanden sein, da ein Auftrag mehrere Zeilen aufweisen kann. In der Tabelle Fulfillment sind doppelte ID-Werte zulässig, da Aufträge aus mehreren Auftragspositionen bestehen können, und die einzelnen Auftragspositionen durch mehrere einzelne Lieferungen erfüllt werden können.

Sehen Sie sich nun die Tabellenzeilen genauer an. Wie Sie in der Tabelle Fulfillment sehen, können Auftragspositionen durch mehrere einzelne Lieferungen erfüllt werden. (Wenn eine Auftragsposition nicht angezeigt wird, bedeutet das, sie wurde noch nicht erfüllt.)

Abbildung, die die Tabellenzeilen im Modell zeigt. Im folgenden Absatz werden die einzelnen Zeilen der zwei Tabellen näher erläutert.

In der folgenden Aufzählung werden die Details zu den Zeilen der zwei Tabellen erläutert:

  • Die Tabelle Order hat fünf Zeilen:
    • OrderDate January 1 2019, OrderID1, OrderLine1, ProductIDProd-A, OrderQuantity5, Sales50
    • OrderDate January 1 2019, OrderID1, OrderLine2, ProductIDProd-B, OrderQuantity10, Sales80
    • OrderDate February 2 2019, OrderID2, OrderLine1, ProductIDProd-B, OrderQuantity5, Sales40
    • OrderDate February 2 2019, OrderID2, OrderLine2, ProductIDProd-C, OrderQuantity1, Sales20
    • OrderDate March 3 2019, OrderID3, OrderLine1, ProductIDProd-C, OrderQuantity5, Sales100
  • Die Fulfillment-Tabelle enthält vier Zeilen:
    • FulfillmentDate January 1 2019, FulfillmentID50, OrderID1, OrderLine1, FulfillmentQuantity2
    • FulfillmentDate2. Februar 2019, FulfillmentID51, OrderID2, OrderLine1, FulfillmentQuantity5
    • FulfillmentDate2. Februar 2019, FulfillmentID52, OrderID1, OrderLine1, FulfillmentQuantity3
    • FulfillmentDate1. Januar 2019, FulfillmentID53, OrderID1, OrderLine2, FulfillmentQuantity10

Sehen wir uns an, was passiert, wenn das Modell abgefragt wird. Unten sehen Sie ein Tabellenvisual, in dem die Mengen der Aufträge und der Erfüllungen nach der Spalte OrderID der Tabelle Order verglichen werden.

Abbildung mit einem Tabellenvisual mit drei Spalten: „OrderID“, „OrderQuantity“ und „FulfillmentQuantity“.

Das Visual stellt ein korrektes Ergebnis dar. Die Nützlichkeit des Modells ist jedoch eingeschränkt, da Sie nur nach der Order Tabelle OrderID Spalte filtern oder gruppieren können.

Leitfaden für die Herstellung von m:n-Beziehungen zwischen Fakten

Prinzipiell wird davon abgeraten, zwei Faktentabellen mithilfe einer m:n-Kardinalität direkt aufeinander zu beziehen. Der Hauptgrund dafür ist, dass das Modell keine Flexibilität in der Art und Weise bietet, wie die visuellen Elemente des Berichts gefiltert oder gruppiert werden. Im Beispiel können Visuals nur nach der Spalte OrderID der Tabelle Order gefiltert oder gruppiert werden. Ein weiterer Grund bezieht sich auf die Qualität Ihrer Daten. Wenn es bei Ihren Daten Integritätsprobleme gibt, werden bei der Abfrage manchmal einige Zeilen ausgelassen. Das liegt daran, dass es sich um eine m:n-Kardinalität und eine beschränkte Beziehung handelt.

Anstatt Faktentabellen direkt aufeinander zu beziehen, sollten Sie lieber ein Sternschema verwenden. Dies bedeutet, dass Sie Dimensionstabellen hinzufügen. Diese Dimensionstabellen werden dann mithilfe von 1:n-Beziehungen mit den Faktentabellen verbunden. Dieser Designansatz ist robust, da er flexible Berichterstellungsoptionen effizient bereitstellt. Sie können mithilfe einer der Dimensionstabellenspalten filtern oder gruppieren und Spalten einer verknüpften Faktentabelle zusammenfassen.

Betrachten wir eine bessere Lösung.

Abbildung eines Modells mit sechs Tabellen: „OrderLine“, „OrderDate“, „Order“, „Fulfillment“, „Product“ und „FulfillmentDate“.

Beachten Sie die folgenden Entwurfsänderungen:

  • Das Modell verfügt nun über vier zusätzliche Tabellen: OrderLine, OrderDate, Productund FulfillmentDate.
  • Die vier zusätzlichen Tabellen sind alles Dimensionstabellen, die über 1:n-Beziehungen mit den Faktentabellen verbunden sind.
  • Die OrderLine Tabelle enthält die OrderLineID Spalte, die den mit 100 multiplizierten OrderID-Wert sowie den OrderLine Spaltenwert ( eine ID für jede Bestellzeile) speichert.
  • Die Tabellen Order und Fulfillment enthalten nun eine OrderLineID Spalte, und sie enthalten nicht mehr die OrderID- und OrderLine Spalten.
  • Die Fulfillment-Tabelle enthält jetzt die OrderDate- und ProductID-Spalten.
  • Die FulfillmentDate Tabelle weist nur eine Beziehung zur Fulfillment Tabelle auf.
  • Alle ID-Spalten sind ausgeblendet.

Wenn Sie sich die Zeit nehmen, das Sternschemadesign zu übernehmen, entstehen Ihnen dadurch die folgenden Vorteile:

  • Ihre Berichtsvisuals können nach jeder eingeblendeten Spalte der Dimensionstabellen gefiltert oder gruppiert werden.
  • Ihre Berichtsvisuals können Zusammenfassungen jeder eingeblendeten Spalte der Faktentabellen erstellen.
  • Filter, die auf die Tabellen OrderLine, OrderDateoder Product angewendet werden, werden für beide Faktentabellen übernommen.
  • Alle Beziehungen sind 1:n-Beziehungen und damit reguläre Beziehungen. Datenintegritätsprobleme werden nicht maskiert. Weitere Informationen zur Beziehungsauswertung finden Sie unter Modellbeziehungen in Power BI Desktop.

Herstellen von Beziehungen zwischen Fakten mit höherer Granularität

Dieses Viele-zu-Viele-Szenario unterscheidet sich sehr von den beiden anderen Szenarien, die bereits in diesem Artikel beschrieben wurden.

Betrachten wir ein Beispiel mit vier Tabellen: Date, Sales, Productund Target. Bei den Tabellen Date und Product handelt es sich um Dimensionstabellen, und sie werden über 1:n-Beziehungen auf die Faktentabelle Sales bezogen. Soweit entspricht das dem Sternschemadesign. Die Target Tabelle ist jedoch noch nicht mit den anderen Tabellen verknüpft.

Diagramm mit einem Modell aus vier Tabellen: Datum, Vertrieb, Produkt und Ziel.

Die Target Tabelle enthält drei Spalten: Category, TargetQuantityund TargetYear. In den Tabellenzeilen wird eine Granularität für Jahr und Produktkategorie angezeigt. Mit anderen Worten: Ziele , die verwendet werden, um die Umsatzleistung zu messen, werden jedes Jahr für jede Produktkategorie festgelegt.

Abbildung, die die Faktentabellen „Sales“ und „Target“ zeigt. Die Faktentabelle „Target“ enthält drei Spalten: „TargetYear“, „Category“ und „TargetQuantity“.

Da die Target-Tabelle Daten auf einer höheren Ebene als die Dimensionstabellen speichert, kann keine Eins-zu-Viele-Beziehung erstellt werden. Nun, es ist wahr für nur eine der Beziehungen. Sehen wir uns an, wie die Target Tabelle mit den Dimensionstabellen verknüpft werden kann.

Herstellen von Beziehungen zwischen Zeiträumen mit höherer Granularität

Die Beziehung zwischen den Tabellen Date und Target sollte eine 1:n-Beziehung sein. Das liegt daran, dass die TargetYear Spaltenwerte Datumswerte sind. In diesem Beispiel speichert jede TargetYear Spalte das erste Datum des Zieljahrs.

Tipp

Beim Speichern von Fakten mit einer höheren Zeitgranularität als Tag stellen Sie den Spaltendatentyp auf Datum ein (oder Ganze Zahl, wenn Sie Datumsschlüssel verwenden). Speichern Sie in der Spalte einen Wert, der den ersten Tag des Zeitraums darstellt. Beispielsweise wird ein Jahreszeitraum als 1. Januar des Jahres aufgezeichnet, und ein Monatszeitraum wird als erster Tag dieses Monats aufgezeichnet.

Es muss jedoch darauf geachtet werden, dass Filter auf Monats- oder Datumsebene ein aussagekräftiges Ergebnis erzeugen. Ohne spezielle Berechnungslogik können visuelle Berichtselemente berichten, dass Zieldaten buchstäblich der erste Tag jedes Jahres sind. Die Zusammenfassung für alle anderen Tage und Monate (mit Ausnahme des Januars) ergeben als Sollmenge LEER.

Im folgenden Matrixvisual sehen Sie, was geschieht, wenn sich ein Berichtbenutzer die Monate eines Jahres ansehen möchte. Das Visual fasst die Spalte TargetQuantity zusammen. (Die Option Elemente ohne Daten anzeigen wurde für die Matrixzeilen aktiviert.)

Abbildung eines Matrixvisuals, das für das Jahr 2020 eine Sollmenge von 270 angibt. Nach Datum ergeben sich falsche Werte.

Um dieses Verhalten zu vermeiden, empfehlen wir Ihnen, die Zusammenfassung Ihrer Faktendaten mithilfe von Maßnahmen zu steuern. Eine Möglichkeit, die Zusammenfassung zu steuern, ist es, LEER zurückzugeben, wenn Zeiträume niedrigerer Ebenen abgefragt werden. Eine andere Möglichkeit, die mit komplexeren Funktionen und Operatoren der DAX-Bibliothek definiert wird, ist es, Werte in den Zeiträumen niedrigerer Ebenen zuzuteilen.

Sehen Sie sich die folgende Measuredefinition an, die die DAX-Funktion ISFILTERED verwendet. Es wird nur ein Wert zurückgegeben, wenn die Spalten Date und Month nicht gefiltert sind.

Target Quantity =
IF(
    NOT ISFILTERED('Date'[Date])
        && NOT ISFILTERED('Date'[Month]),
    SUM(Target[TargetQuantity])
)

Das folgende Matrixvisual verwendet das Measure Target Quantity. Hier sehen Sie, dass alle Sollmengen für Monate LEER sind.

Abbildung, das zwei Matrixvisuals zeigt. Das erste enthält die Sollmenge 270 für den ersten Monat von 2020, während das zweite leer ist.

Herstellen von Beziehungen mit höherer Granularität (kein Datum)

Wenn eine Beziehung einer Spalte ohne Datum aus einer Dimensionstabelle zu einer Faktentabelle hergestellt werden soll, und sie eine höhere Granularität als die Dimensionstabelle hat, ist ein anderer Designansatz erforderlich.

Die Category Spalten (aus den Tabellen Product und Target) enthalten doppelte Werte. Es gibt also keine „1“-Seite für eine 1:n-Beziehung. In diesem Fall müssen Sie eine m:n-Beziehung erstellen. Die Beziehung sollte Filter in eine einzige Richtung weitergeben, nämlich von der Dimensionstabelle auf die Faktentabelle.

Abbildung eines Modells der Tabellen „Target“ und „Product“. Die beiden Tabellen sind über eine m:n-Beziehung verbunden.

Sehen Sie sich nun die Tabellenzeilen genauer an.

Abbildung eines Modells mit den beiden Tabellen „Target“ und „Product“. Die beiden Spalten „Category“ sind über eine m:n-Beziehung verbunden.

In der tabelle Target gibt es vier Zeilen: zwei Zeilen für jedes Zieljahr (2019 und 2020) und zwei Kategorien (Bekleidung und Zubehör). In der Tabelle Product gibt es drei Produkte. Zwei gehören zur Kategorie Bekleidung, und einer gehört zur Kategorie Accessoires. Eine der Kleidungsfarben ist grün, und die verbleibenden beiden sind blau.

Eine grafische Gruppierung einer Tabelle nach der Spalte Category aus der Tabelle Product erzeugt das folgende Ergebnis. Das Visual kommt jedoch zum richtigen Ergebnis. Im Folgenden erfahren Sie nun, was geschieht, wenn die Sollmenge nach der Spalte Color der Tabelle Product gruppiert wird.

Diagramm mit zwei Tabellen-Visualisierungen. Die erste Tabelle gruppiert nach Kategorie und die zweite Tabelle gruppiert nach Farbe. Das zweite visuelle Element erzeugt ein falsches Ergebnis.

Das visuelle Element erzeugt eine Falschdarstellung der Daten. Was geschieht hier?

Ein auf die Spalte Color der Tabelle Product angewendeter Filter führt zu zwei Zeilen. Eine der Zeilen ist für die Kategorie "Kleidung" und der andere für die Kategorie "Zubehör". Diese zwei Kategoriewerte werden als Filter an die Tabelle Target weitergegeben. Das heißt, da die Farbe Blau von Produkten aus zwei Kategorien verwendet wird, werden diese Kategorien zum Filtern der Sollwerte genutzt.

Um dieses Verhalten, wie bereits früher beschrieben, zu vermeiden, empfehlen wir Ihnen, die Zusammenfassung Ihrer Faktendaten mithilfe von Maßnahmen zu steuern.

Betrachten Sie die folgende Maßnahmendefinition. Wie Sie sehen können, werden alle Spalten aus der Tabelle Product, die sich unter der Kategorieebene befinden, auf Filter überprüft.

Target Quantity =
IF(
    NOT ISFILTERED('Product'[ProductID])
        && NOT ISFILTERED('Product'[Product])
        && NOT ISFILTERED('Product'[Color]),
    SUM(Target[TargetQuantity])
)

Das folgende Tabellenvisual verwendet das Measure Target Quantity. Hier sehen Sie, dass alle Sollmengen für Farbe LEER sind.

Abbildung, die zweit Tabellenvisuals zeigt. Das erste gruppiert nach Kategorie und das zweite nach Farbe. Das zweite Visual gibt korrekt das Ergebnis LEER aus.

Das endgültige Modelldesign sieht wie folgt aus.

Abbildung eines Modells mit den Tabellen „Date“ und „Target“, die über eine 1:n-Beziehung miteinander verbunden sind.

Leitfaden für das Herstellen von Beziehungen zwischen Fakten mit höherer Granularität

Wenn Sie eine Dimensionstabelle mit einer Faktentabelle verknüpfen müssen und die Faktentabelle Zeilen mit einer höheren Granularität als die Zeilen der Dimensionstabelle speichert, halten Sie sich an folgende Anleitung:

  • Für Datumsangaben in einer Faktentabelle mit höherer Granularität
    • Speichern Sie in der Faktentabelle das erste Datum des Zeitraums.
    • Erstellen Sie eine 1:n-Beziehung zwischen der Tabelle „Date“ und der Faktentabelle.
  • Für andere Fakten mit höherer Granularität
    • Erstellen Sie eine m:n-Beziehung zwischen der Dimensionstabelle und der Faktentabelle.
  • Für beide Typen
    • Steuern Sie die Zusammenfassung mit Measurelogik. Wenn für das Filtern oder Gruppieren Spalten aus niedrigeren Ebenen von Dimensionstabellen verwendet werden, sollte LEER zurückgegeben werden.
    • Blenden Sie Spalten aus Faktentabellen aus, die zusammengefasst werden können. So wird sichergestellt, dass die Faktentabelle nur mithilfe von Measures zusammengefasst werden kann.

Verwandte Inhalte

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