Udostępnij za pośrednictwem


Wskazówki dotyczące relacji dwukierunkowych

Ten artykuł jest przeznaczony dla Ciebie jako modeler danych, który współpracuje 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. Dzieje się tak, ponieważ mogą one negatywnie wpływać na wydajność zapytań modelu i być może stwarzać mylące wrażenia dla użytkowników raportu.

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

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 uzyskać pełną dyskusję i alternatywne wzorce projektowe, zobacz wskazówki dotyczące relacji jeden do jednego w sekcji .
  • wiele-do-wielu: w przypadku łączenia dwóch tabel wymiarów wymagane jest tabeli pomostowej. 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 .

Opcje fragmentatora "z danymi"

Relacje dwukierunkowe mogą dostarczać filtry, które ograniczają opcje do tych miejsc, gdzie istnieją dane. (Jeśli znasz tabele przestawne i slicery programu Excel, takie zachowanie jest domyślne przy określaniu źródła danych z modelu semantycznego usługi Power BI lub modelu Analysis Services). Aby wyjaśnić, co to znaczy, najpierw rozważ poniższy diagram modelu.

Diagram przedstawiający model zawierający trzy tabele. Projekt został opisany w poniższym akapicie.

Pierwsza tabela ma nazwę Customer. Zawiera trzy kolumny: Country-Region, Customeri CustomerCode. Druga tabela ma nazwę Producti zawiera trzy kolumny: Color, Producti SKU. Trzecia tabela ma nazwę Salesi zawiera cztery kolumny: CustomerCode, OrderDate, Quantityi SKU. Tabele Customer i Product to tabele wymiarów, a każda z nich ma relację jeden do wielu z tabelą Sales. 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.

Diagram przedstawiający, że model wyświetla teraz wiersze tabeli. Szczegóły wiersza opisano w poniższym akapicie.

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

  • Tabela Customer ma dwa wiersze:
    • CustomerCode CUST-01, CustomerCustomer-1, Country-RegionStany Zjednoczone
    • CustomerCode CUST-02, CustomerCustomer-2, Country-RegionAustralia
  • Tabela Product zawiera trzy wiersze:
    • SKU CL-01, Productkoszulka, Colorzielony
    • SKU CL-02, ProductDżinsy, ColorNiebieski
    • SKU AC-01, ProductHat, ColorBlue
  • Tabela Sales zawiera trzy wiersze:
    • OrderDate 1 stycznia 2019 r., CustomerCodeCUST-01, SKUCL-01, Quantity10
    • OrderDate 2 lutego 2019, CustomerCodeCUST-01, SKUCL-02, Quantity20
    • OrderDate 3 marca 2019 r., CustomerCodeCUST-02, SKUCL-01, Quantity30

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

Diagram przedstawiający stronę raportu zawierającą trzy wizualizacje. Szczegółowe informacje opisano w poniższym akapicie.

Strona składa się z dwóch fragmentatorów i wizualizacji karty. Pierwszy fragmentator jest oparty na polu Country-Region i ma dwie opcje: Australia i Stany Zjednoczone. Obecnie jest to fragmentowane przez Australię. Drugi fragmentator opiera się na polu Product i ma trzy opcje: 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 sortują według Australii, możesz ograniczyć filtr produktu do wyświetlania opcji, w których dane odnoszą się do australijskiej sprzedaży. Oznacza to wyświetlanie opcji fragmentatora "z danymi". To zachowanie można osiągnąć, ustawiając relację między tabelami Product i Sales, aby filtrować w obu kierunkach.

Diagram przedstawiający model, w którym relacja między tabelami Product (Produkt) i Sales (Sprzedaż) jest teraz dwukierunkowa.

Fragmentator produktu zawiera teraz jedną opcję: T-shirt. Ta opcja reprezentuje jedyny produkt sprzedany klientom australijskim.

Diagram przedstawiający stronę raportu zawierającą trzy wizualizacje z wywołanym produktem. Szczegółowe informacje opisano w poniższym akapicie.

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 to doświadczenie jest mylące, ponieważ nie rozumieją, dlaczego opcje fragmentatora dynamicznie pojawiają się lub znikają podczas interakcji z innymi fragmentatorami.

Jeśli zdecydujesz się wyświetlić opcje 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 osiągnięcia tego samego wyniku: Zamiast używać filtrów dwukierunkowych, można zastosować filtr na poziomie wizualizacji do samego fragmentatora produktu.

Rozważmy teraz, że relacja między tabelami Product i Sales przestaje filtrować w obu kierunkach. Poniższa definicja miary została dodana do tabeli Sales.

Total Quantity = SUM(Sales[Quantity])

Aby wyświetlić opcje fragmentatora produktu "z danymi", po prostu należy go filtrować według miary Total Quantity przy użyciu warunku "nie jest puste".

Diagram przedstawiający, że panel Filtry dla fragmentatora Produkt teraz filtruje według wartości Łączna ilość (Total Quantity) i nie jest pusty.

Analiza wymiarów do wymiarów

Inny scenariusz obejmujący relacje dwukierunkowe traktuje tabelę faktów jak tabela pomostowa . Dzięki temu umożliwia analizowanie danych z 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?

Na oba pytania można odpowiedzieć bez podsumowania danych w pomocniczej tabeli faktów. Wymagają one jednak, aby filtry były propagowane z jednej tabeli wymiarów do drugiej. Podczas propagacji filtrów za pośrednictwem tabeli faktów można uzyskać podsumowanie kolumn tabeli wymiarów, korzystając z funkcji języka DAX DISTINCTCOUNT, a także prawdopodobnie z funkcji języka DAX MIN i MAX.

Ponieważ tabela faktów zachowuje się jak tabela pomostowa, możesz zastosować wytyczne dotyczące 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.

Jednak zgodnie z opisem w tym artykule ten projekt prawdopodobnie spowoduje negatywny wpływ na wydajność, a konsekwencje środowiska użytkownika związane z opcjami fragmentatora "z danymi". Dlatego zalecamy aktywowanie filtrowania dwukierunkowego w definicji miary przy użyciu funkcji JĘZYKA DAX CROSSFILTER . Możesz użyć funkcji CROSSFILTER, aby zmodyfikować kierunki filtrowania — a nawet wyłączyć relację — podczas obliczania wyrażenia.

Rozważmy następującą definicję miary dodaną do tabeli Sales. 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 oceny miary Different Countries Sold, relacja między tabelami Customer i Sales jest filtrowana w obu kierunkach.

W poniższej tabeli przedstawiono statystyki dla każdego sprzedanego produktu. Kolumna Quantity jest po prostu sumą wartości ilościowych. Kolumna Different Countries Sold reprezentuje unikalną liczbę wartości kraj-region dla wszystkich klientów, którzy kupili produkt.

Diagram przedstawia dwa produkty wymienione w wizualizacji tabeli. W kolumnie Różne kraje sprzedaży, dżinsy to 1, a koszulka to 2.

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