Wskazówki dotyczące relacji dwukierunkowych

Ten artykuł jest przeznaczony dla Ciebie jako modeler danych pracujący z programem Power BI Desktop. Zawiera on wskazówki dotyczące tworzenia relacji modelu dwukierunkowego. Relacja dwukierunkowa to relacja, która filtruje w obu kierunkach.

Uwaga

Wprowadzenie do relacji modelu nie zostało omówione w tym artykule. Jeśli nie znasz całkowicie relacji, ich właściwości lub sposobu ich konfigurowania, zalecamy najpierw przeczytanie artykułu Relacje modelu w programie Power BI Desktop .

Ważne jest również, aby zrozumieć projekt schematu gwiazdy. Aby uzyskać więcej informacji, zobacz Omówienie schematu gwiazdy i znaczenia usługi Power BI.

Ogólnie rzecz biorąc, zalecamy zminimalizowanie użycia relacji dwukierunkowych. Mogą one negatywnie wpływać na wydajność zapytań modelu i potencjalnie dostarczać mylące środowiska dla użytkowników raportu.

Istnieją trzy scenariusze, w których filtrowanie dwukierunkowe może rozwiązać określone wymagania:

• Relacje modelu specjalnego
• Elementy fragmentatora "z danymi"
• Analiza wymiarów do wymiarów

Relacje modelu specjalnego

Relacje dwukierunkowe odgrywają ważną rolę podczas tworzenia następujących dwóch specjalnych typów relacji modelu:

• Jeden do jednego: wszystkie relacje jeden do jednego muszą być dwukierunkowe — nie można skonfigurować w inny sposób. Ogólnie rzecz biorąc, nie zalecamy tworzenia tych typów relacji. Aby zapoznać się z pełną dyskusją i alternatywnymi projektami, zobacz Wskazówki dotyczące relacji jeden do jednego.
• Wiele do wielu: w przypadku łączenia dwóch tabel wymiarów wymagana jest tabela pomostowa. Aby zapewnić propagację filtrów w tabeli mostkowej, wymagany jest dwukierunkowy filtr. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące relacji wiele-do-wielu (Powiązanie wymiarów wiele-do-wielu).

Elementy fragmentatora "z danymi"

Relacje dwukierunkowe mogą dostarczać fragmentatory, które ograniczają elementy do miejsca, w którym istnieją dane. (Jeśli znasz tabele przestawne i fragmentatory programu Excel, jest to domyślne zachowanie podczas określania źródła danych z modelu semantycznego usługi Power BI lub modelu usług Analysis Services). Aby wyjaśnić, co to znaczy, należy najpierw rozważyć poniższy diagram modelu.

Pierwsza tabela nosi nazwę Customer (Klient) i zawiera trzy kolumny: Country-Region(Region), Customer (Klient) i CustomerCode (Kod klienta). Druga tabela nosi nazwę Product (Produkt) i zawiera trzy kolumny: Color (Kolor), Product (Produkt) i SKU (SKU). Trzecia tabela ma nazwę Sales i zawiera cztery kolumny: CustomerCode, OrderDate, Quantity i SKU. Tabele Customer (Klient) i Product (Produkt) są tabelami wymiarów, a każda z nich ma relację jeden do wielu z tabelą Sales (Sprzedaż). Każda relacja filtruje w jednym kierunku.

Aby ułatwić opisanie sposobu działania filtrowania dwukierunkowego, diagram modelu został zmodyfikowany w celu wyświetlenia wierszy tabeli. Wszystkie przykłady w tym artykule są oparte na tych danych.

Uwaga

Nie można wyświetlić wierszy tabeli na diagramie modelu programu Power BI Desktop. W tym artykule wykonano obsługę dyskusji z jasnymi przykładami.

Szczegóły wiersza dla trzech tabel zostały opisane na następującej liście punktowanej:

• Tabela Customer (Klient) zawiera dwa wiersze:
  • CustomerCode CUST-01, Customer-1, Country-Region Stany Zjednoczone
  • CustomerCode CUST-02, Customer-2 , Country-Region Australia
• Tabela Product (Produkt) zawiera trzy wiersze:
  • SKU CL-01, T-shirt produktu , kolor zielony
  • SKU CL-02, Product Jeans, Color Blue
  • SKU AC-01, Product Hat, Color Blue
• Tabela Sales (Sprzedaż) zawiera trzy wiersze:
  • OrderDate 1 stycznia 2019, CustomerCode CUST-01, SKU CL-01, Quantity 10
  • OrderDate 2 lutego 2019, CustomerCode CUST-01, SKU CL-02, Quantity 20
  • OrderDate 3 marca 2019 r., CustomerCode CUST-02, SKU CL-01, Quantity 30

Teraz rozważ następującą stronę raportu.

Strona składa się z dwóch fragmentatorów i wizualizacji karty. Pierwszy fragmentator dotyczy kraju i ma dwa elementy: Australia i Stany Zjednoczone. Obecnie jest to fragmentowane przez Australię. Drugi fragmentator jest przeznaczony dla produktu i ma trzy elementy: Kapelusz, Dżinsy i T-shirt. Nie wybrano żadnych elementów (co oznacza, że żadne produkty nie są filtrowane). Wizualizacja karty wyświetla liczbę 30.

Gdy użytkownicy raportu wycinek według Australii, możesz ograniczyć fragmentator Product (Produkt ), aby wyświetlić elementy, w których dane odnoszą się do australijskiej sprzedaży. Chodzi o to, aby pokazać elementy fragmentatora "z danymi". To zachowanie można osiągnąć, konfigurując relację między tabelą Product (Produkt) i Sales (Sprzedaż), aby filtrować w obu kierunkach.

Fragmentator Product zawiera teraz pojedynczy element: T-shirt. Ten element reprezentuje jedyny produkt sprzedany klientom australijskim.

Najpierw zalecamy, aby dokładnie rozważyć, czy ten projekt działa dla użytkowników raportu. Niektórzy użytkownicy raportu uważają, że środowisko jest mylące. Nie rozumieją, dlaczego elementy fragmentatora są dynamicznie wyświetlane lub znikają podczas interakcji z innymi fragmentatorami.

Jeśli zdecydujesz się pokazać elementy fragmentatora "z danymi", nie zalecamy konfigurowania relacji dwukierunkowych. Relacje dwukierunkowe wymagają większego przetwarzania i mogą negatywnie wpływać na wydajność zapytań — zwłaszcza w miarę wzrostu liczby relacji dwukierunkowych w modelu.

Istnieje lepszy sposób na osiągnięcie tego samego wyniku: Zamiast korzystać z filtrów dwukierunkowych, można zastosować filtr na poziomie wizualizacji do fragmentatora Produkt .

Rozważmy teraz, że relacja między tabelą Product i Sales nie będzie już filtrować w obu kierunkach. Do tabeli Sales (Sprzedaż) dodano następującą definicję miary .

Total Quantity = SUM(Sales[Quantity])

Aby wyświetlić elementy fragmentatora Product "z danymi", po prostu musi być filtrowane według miary Total Quantity przy użyciu warunku "nie jest puste".

Analiza wymiarów do wymiarów

Inny scenariusz obejmujący relacje dwukierunkowe traktuje tabelę faktów, na przykład tabelę mostkową. Dzięki temu obsługuje analizowanie danych tabeli wymiarów w kontekście filtru innej tabeli wymiarów.

Korzystając z przykładowego modelu w tym artykule, rozważ, jak można odpowiedzieć na następujące pytania:

• Ile kolorów zostało sprzedanych australijskim klientom?
• Ile krajów/regionów kupiło dżinsy?

Oba pytania można odpowiedzieć bez podsumowywania danych w tabeli faktów pomostowych. Wymagają one jednak, aby filtry były propagowane z jednej tabeli wymiarów do drugiej. Po propagacji filtrów za pośrednictwem tabeli faktów podsumowania kolumn tabeli wymiarów można osiągnąć przy użyciu funkcji JĘZYKA DAX DISTINCTCOUNT i ewentualnie funkcji JĘZYKA DAX MIN i MAX .

Ponieważ tabela faktów zachowuje się jak tabela pomostowa, możesz postępować zgodnie ze wskazówkami dotyczącymi relacji wiele do wielu, aby powiązać dwie tabele wymiarów. Wymaga skonfigurowania co najmniej jednej relacji do filtrowania w obu kierunkach. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące relacji wiele-do-wielu (Powiązanie wymiarów wiele-do-wielu).

Jednak zgodnie z opisem w tym artykule ten projekt prawdopodobnie będzie mieć negatywny wpływ na wydajność, a konsekwencje środowiska użytkownika związane z elementami fragmentatora "z danymi". Dlatego zalecamy aktywowanie filtrowania dwukierunkowego w definicji miary przy użyciu funkcji JĘZYKA DAX CROSSFILTER . Funkcja CROSSFILTER może służyć do modyfikowania wskazówek filtru — a nawet wyłączania relacji — podczas obliczania wyrażenia.

Rozważmy następującą definicję miary dodaną do tabeli Sales (Sprzedaż). W tym przykładzie relacja modelu między tabelami Customer i Sales została skonfigurowana do filtrowania w jednym kierunku.

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

Podczas obliczania wyrażenia miary Różne kraje sprzedane relacja między tabelami Customer (Klient ) i Sales (Sprzedaż ) jest filtrem w obu kierunkach.

W poniższej tabeli przedstawiono statystyki dla każdego sprzedanego produktu. Kolumna Quantity to po prostu suma wartości ilości. Kolumna Different Countries Sold (Sprzedaż w różnych krajach) reprezentuje odrębną liczbę wartości kraju-region dla wszystkich klientów, którzy kupili produkt.

Powiązana zawartość

Aby uzyskać więcej informacji związanych z tym artykułem, zapoznaj się z następującymi zasobami:

• Relacje modelu w programie Power BI Desktop
• Omówienie schematu gwiazdy i znaczenia usługi Power BI
• Wskazówki dotyczące relacji jeden do jednego
• Wskazówki dotyczące relacji wiele do wielu
• Wskazówki dotyczące rozwiązywania problemów z relacjami
• Pytania? Spróbuj zadać Społeczność usługi Power BI
• Sugestie? Współtworzenie pomysłów na ulepszanie usługi Power BI