Stosowanie relacji wiele do wielu w programie Power BI Desktop

W przypadku relacji z kardynalnością wiele-do-wielu w programie Power BI Desktop można łączyć tabele używające kardynalnościwiele do wielu. Można łatwiej i intuicyjnie tworzyć modele danych zawierające co najmniej dwa źródła danych. Relacje z kardynalnością wiele-do-wielu są częścią większych możliwości modeli złożonych w programie Power BI Desktop. Aby uzyskać więcej informacji na temat modeli złożonych, zobacz Używanie modeli złożonych w programie Power BI Desktop

Screenshot of a many-to-many relationship in the Edit relationship pane.

Jaka jest relacja z kardynalnością wiele do wielu rozwiązuje

Zanim relacje z kardynalnością wiele-do-wielu staną się dostępne, relacja między dwiema tabelami została zdefiniowana w usłudze Power BI. Co najmniej jedna z kolumn tabeli biorących udział w relacji musiała zawierać unikatowe wartości. Często jednak żadna kolumna nie zawiera unikatowych wartości.

Na przykład dwie tabele mogły mieć kolumnę z etykietą CountryRegion. Wartości CountryRegion nie były jednak unikatowe w żadnej tabeli. Aby połączyć takie tabele, trzeba było utworzyć obejście problemu. Jednym z obejść może być wprowadzenie dodatkowych tabel z wymaganymi unikatowymi wartościami. W przypadku relacji z kardynalnością wiele-do-wielu można łączyć takie tabele bezpośrednio, jeśli używasz relacji z kardynalnością wiele-do-wielu.

Używanie relacji z kardynalnością wiele-do-wielu

Podczas definiowania relacji między dwiema tabelami w usłudze Power BI należy zdefiniować kardynalność relacji. Na przykład relacja między kolumnami ProductSales i Product —przy użyciu kolumn ProductSales[ProductCode] i Product[ProductCode]— będzie zdefiniowana jako wiele-1. W ten sposób definiujemy relację, ponieważ każdy produkt ma wiele sprzedaży, a kolumna w tabeli Product (ProductCode) jest unikatowa. Podczas definiowania kardynalności relacji jako wiele-1, 1-wielu lub 1-1 usługa Power BI ją weryfikuje, więc kardynalność wybrana jest zgodna z rzeczywistymi danymi.

Przyjrzyj się na przykład prostego modelu na poniższej ilustracji:

Screenshot of ProductSales and Product table in Relationship view.

Teraz wyobraź sobie, że w tabeli Product są wyświetlane tylko dwa wiersze, jak pokazano poniżej:

Screenshot of a Product table visual with two rows.

Załóżmy również, że tabela Sales (Sprzedaż) zawiera tylko cztery wiersze, w tym wiersz dla produktu C. Z powodu błędu integralności referencyjnej wiersz produktu C nie istnieje w tabeli Product .

Screenshot of a Sales table visual with four rows.

Wartości ProductName i Price (z tabeli Product ) wraz z łączną ilością dla każdego produktu (z tabeli ProductSales) będą wyświetlane w następujący sposób:

Screenshot of a Visual displaying the product name, price, and quantity.

Jak widać na poprzedniej ilustracji, pusty wiersz ProductName jest skojarzony ze sprzedażą produktu C. Ten pusty wiersz odpowiada następującym zagadnieniom:

  • Wszystkie wiersze w tabeli ProductSales, dla których w tabeli Product nie ma odpowiedniego wiersza. W tym przykładzie występuje problem z integralnością referencyjną, jak widzimy w przypadku produktu C.

  • Wszystkie wiersze w tabeli ProductSales , dla których kolumna klucza obcego ma wartość null.

Z tych powodów pusty wiersz w obu przypadkach odpowiada sprzedaży, w której wartości ProductName i Price są nieznane.

Czasami tabele są łączone przez dwie kolumny, ale żadna kolumna nie jest unikatowa. Rozważmy na przykład te dwie tabele:

  • Tabela Sales (Sprzedaż) zawiera dane sprzedaży według wartości State (Stan), a każdy wiersz zawiera kwotę sprzedaży dla typu sprzedaży w tym stanie. Stany obejmują urząd certyfikacji, WA i TX.

    Screenshot of a Sales table displaying sales by state.

  • Tabela CityData zawiera dane dotyczące miast, w tym populacji i stanu (takich jak CA, WA i Nowy Jork).

    Screenshot of a Sales table displaying city, state, and population.

Kolumna State znajduje się teraz w obu tabelach. Rozsądnie jest chcieć zgłosić zarówno łączną sprzedaż według stanu, jak i całkowitą populację każdego stanu. Istnieje jednak problem: kolumna State nie jest unikatowa w żadnej tabeli.

Poprzednie obejście

Przed wydaniem programu Power BI Desktop z lipca 2018 r. nie można utworzyć bezpośredniej relacji między tymi tabelami. Typowym obejściem było:

  • Utwórz trzecią tabelę zawierającą tylko unikatowe identyfikatory stanów. Tabela może być dowolna lub wszystkie:

    • Tabela obliczeniowa (zdefiniowana przy użyciu wyrażeń analizy danych [DAX]).
    • Tabela oparta na zapytaniu zdefiniowanym w Edytor Power Query, które może wyświetlać unikatowe identyfikatory pobrane z jednej z tabel.
    • Połączony pełny zestaw.
  • Następnie należy powiązać dwie oryginalne tabele z nową tabelą przy użyciu typowych relacji wiele-1 .

Możesz pozostawić widoczną tabelę obejścia. Możesz też ukryć tabelę obejścia, aby nie była wyświetlana na liście Pola . Jeśli ukryjesz tabelę, relacje wiele-1 będą często ustawiane tak, aby filtrować w obu kierunkach i można użyć pola State z dowolnej tabeli. Drugie filtrowanie krzyżowe będzie propagowane do drugiej tabeli. Takie podejście przedstawiono na poniższej ilustracji:

Screenshot of a hidden State table in Relationship view.

Wizualizacja, która wyświetla kolumnę State (z tabeli CityData) wraz z łączną liczbą ludności i łączną sprzedażą, zostanie wyświetlona w następujący sposób:

Screenshot showing a table with State, Population, and Sales data.

Uwaga

Ponieważ stan z tabeli CityData jest używany w tym obejście, tylko stany w tej tabeli są wymienione, więc TX jest wykluczony. Ponadto, w przeciwieństwie do relacji Wiele-1 , podczas gdy wiersz sumy zawiera wszystkie kolumny Sales (w tym tx), szczegóły nie zawierają pustego wiersza obejmującego takie niedopasowane wiersze. Podobnie żaden pusty wiersz nie obejmuje kolumny Sales , dla której istnieje wartość null dla wartości State.

Załóżmy, że dodajesz również miasto do tej wizualizacji. Chociaż populacja na miasto jest znana, sprzedaż wyświetlana dla pozycji Miasto po prostu powtarza wartość Sales dla odpowiedniego stanu. Ten scenariusz zwykle występuje, gdy grupowanie kolumn nie jest powiązane z miarą zagregowaną, jak pokazano poniżej:

Screenshot of a table showing State and city population and sales.

Załóżmy, że zdefiniujesz nową tabelę Sales (Sprzedaż) jako kombinację wszystkich stanów w tym miejscu i udostępnimy ją na liście Pola . Ta sama wizualizacja będzie wyświetlać stan (w nowej tabeli), łączną populację i łączną sprzedaż:

Screenshot of a visual showing State, population, and sales visual.

Jak widać, tx — z danymi sprzedaży , ale nieznanymi danymi populacji i Nowym Jorkiem — ze znanymi danymi populacji , ale bez danych sprzedaży — zostaną uwzględnione. To obejście nie jest optymalne i ma wiele problemów. W przypadku relacji z kardynalnością wiele-do-wielu wynikowe problemy są rozwiązywane zgodnie z opisem w następnej sekcji.

Aby uzyskać więcej informacji na temat implementowania tego obejścia, zobacz Wskazówki dotyczące relacji wiele do wielu.

Używanie relacji z kardynalnością wiele-do-wielu zamiast obejścia

Możesz bezpośrednio powiązać tabele, takie jak opisane wcześniej, bez konieczności uciekania się do podobnych obejść. Teraz można ustawić kardynalność relacji na wiele-do-wielu. To ustawienie oznacza, że żadna tabela nie zawiera unikatowych wartości. W przypadku takich relacji nadal możesz kontrolować, która tabela filtruje drugą tabelę. Możesz też zastosować filtrowanie dwukierunkowe, w którym każda tabela filtruje drugą.

W programie Power BI Desktop kardynalność jest domyślnie ustawiona na wiele-do-wielu , gdy żadna tabela nie zawiera unikatowych wartości kolumn relacji. W takich przypadkach komunikat ostrzegawczy potwierdza, że chcesz ustawić relację i że zmiana nie jest niezamierzonym efektem problemu z danymi.

Na przykład podczas tworzenia relacji bezpośrednio między tabelami CityData i Sales — gdzie filtry powinny przepływać z cityData do sales — program Power BI Desktop wyświetla okno dialogowe Edytowanie relacji :

Screenshot of the Edit relationship dialog box with Cardinality and Cross filter direction highlighted.

Wynikowy widok Relacja będzie następnie wyświetlać bezpośrednią relację wiele-do-wielu między dwiema tabelami. Wygląd tabel na liście Pola i ich późniejsze zachowanie podczas tworzenia wizualizacji są podobne do tego, gdy zastosowano obejście. W obejście dodatkowej tabeli, która wyświetla odrębne dane stanu, nie jest widoczna. Jak opisano wcześniej, zostanie wyświetlona wizualizacja przedstawiająca dane State(Stan), Population (Populacja) i Sales (Sprzedaż):

Screenshot of a State, Population, and Sales table.

Główne różnice między relacjami z kardynalnością wiele-do-wielu i bardziej typowe relacje Wiele-1 są następujące:

  • Wyświetlane wartości nie zawierają pustego wiersza, który odpowiada za niedopasowane wiersze w innej tabeli. Ponadto wartości nie uwzględniają wierszy, w których kolumna używana w relacji w drugiej tabeli ma wartość null.

  • Nie można użyć RELATED() funkcji, ponieważ może być powiązany więcej niż jeden wiersz.

  • ALL() Użycie funkcji w tabeli nie powoduje usunięcia filtrów, które są stosowane do innych, powiązanych tabel przez relację wiele do wielu. W poprzednim przykładzie miara zdefiniowana w tym miejscu nie spowoduje usunięcia filtrów dla kolumn w powiązanej tabeli CityData:

    Screenshot of a script example. The example is, Sales total = Calculate(Sum('Sales'[Sales]), All('Sales')).

    Wizualizacja przedstawiająca dane stanu, sprzedaży i sprzedaży spowoduje wyświetlenie tej grafiki:

    Screenshot of a table visual showing State, Sales, and Sales total resulting from the formula.

Mając na uwadze powyższe różnice, upewnij się, że obliczenia używające ALL(<Table>)wartości , takie jak % sumy końcowej, zwracają zamierzone wyniki.

Rozważania i ograniczenia

Istnieje kilka ograniczeń dotyczących tej wersji relacji z kardynalnością wiele-do-wielu i modelami złożonymi.

Następujących źródeł live Połączenie (wielowymiarowych) nie można używać z modelami złożonymi:

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Semantyczne modele usługi Power BI
  • Azure Analysis Services

Podczas nawiązywania połączenia z tymi wielowymiarowymi źródłami przy użyciu trybu DirectQuery nie można nawiązać połączenia z innym źródłem DirectQuery ani połączyć go z zaimportowanymi danymi.

Istniejące ograniczenia dotyczące używania trybu DirectQuery nadal mają zastosowanie w przypadku używania relacji z kardynalnością wiele-do-wielu. Wiele ograniczeń dotyczy teraz tabeli w zależności od trybu przechowywania tabeli. Na przykład kolumna obliczeniowa w zaimportowanej tabeli może odwoływać się do innych tabel, ale kolumna obliczeniowa w tabeli DirectQuery nadal może odwoływać się tylko do kolumn w tej samej tabeli. Inne ograniczenia dotyczą całego modelu, jeśli jakiekolwiek tabele w modelu są zapytaniem bezpośrednim. Na przykład funkcje Quick Szczegółowe informacje i Q&A są niedostępne w modelu, jeśli jakakolwiek tabela w niej ma tryb przechowywania zapytania bezpośredniego.

Aby uzyskać więcej informacji na temat modeli złożonych i trybu DirectQuery, zobacz następujące artykuły: