Wskazówki dotyczące aktywnej i nieaktywnej relacji

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 aktywnych lub nieaktywnych relacji modelu. Domyślnie aktywne relacje propagują filtry do innych tabel. Nieaktywna relacja propaguje jednak filtry tylko wtedy, gdy wyrażenie języka DAX aktywuje (używa) relacji.

Notatka

Wprowadzenie do relacji modelu nie jest omawiane w tym artykule. Jeśli nie jesteś całkowicie zaznajomiony z relacjami, ich właściwościami lub sposobem, jak je skonfigurować, zalecamy najpierw przeczytanie artykułu Model relacji w Power BI Desktop.

Ważne jest również, aby mieć zrozumienie projektowania schematu gwiazdy. Aby uzyskać więcej informacji, zobacz Zrozumienie schematu gwiazdy i znaczenie dla Power BI.

Aktywne relacje

Ogólnie rzecz biorąc, zalecamy definiowanie aktywnych relacji zawsze wtedy, gdy jest to możliwe. Rozszerzają zakres i potencjalne możliwości wykorzystania modelu przez autorów raportów oraz użytkowników pracujących z Q&A.

Rozważmy przykład modelu Import zaprojektowany do analizowania wydajności lotów linii lotniczych (OTP). Model ma tabelę Flight, która jest tabelą faktów , przechowującą jeden wiersz na lot. Każdy wiersz rejestruje datę lotu, numer lotu, lotniska odlotu i przylotu oraz czas opóźnienia (w minutach). Istnieje również tabela Airport, która jest tabelą wymiarów i przechowuje po jednym wierszu dla każdego lotniska. W każdym wierszu opisano kod lotniska, nazwę lotniska i kraj lub region.

Oto częściowy diagram modelu dwóch tabel.

Istnieją dwie relacje modelu między tabelami Flight i Airport. W tabeli Flight kolumny DepartureAirport i ArrivalAirport odnoszą się do kolumny Airport tabeli Airport. W projekcie schematu gwiazdy tabela Airport jest opisana jako wymiar odgrywający rolę . W tym modelu dwie role to lotnisko odlotu i lotnisko przylotu.

Chociaż ten projekt dobrze sprawdza się w przypadku relacyjnych projektów schematu gwiazdy, nie działa zbyt dobrze w odniesieniu do modeli Power BI. Dzieje się tak, ponieważ relacje modelu są ścieżkami propagacji filtru, a te ścieżki muszą być deterministyczne. Aby uzyskać więcej informacji o tym, jak zapewnić deterministyczność ścieżek propagacji filtru, zobacz dotyczące rozwiązywania niejednoznaczności ścieżek relacji. W związku z tym, jak pokazano w tym przykładzie, jedna relacja jest aktywna, a druga nieaktywna (co ilustruje linia przerywana). W szczególności jest to relacja z aktywną kolumną ArrivalAirport, co oznacza, że filtry zastosowane do tabeli Airport są automatycznie propagowane do kolumny ArrivalAirport tabeli Flight.

Ten projekt modelu nakłada poważne ograniczenia dotyczące sposobu raportowania danych. W szczególności nie można filtrować tabeli Airport, aby automatycznie odizolować informacje o locie dla określonego lotniska odlotu. Ponieważ raporty muszą jednocześnie filtrować (lub grupować) według portów lotniczych odlotów i przylotów , wymagane są dwie aktywne relacje. Tłumaczenie tego wymagania na projektowanie modelu usługi Power BI oznacza, że model musi mieć dwie tabele lotnisk.

Oto ulepszony projekt modelu.

Model ma teraz dwie tabele lotnisk: Departure Airport i Arrival Airport. Każda relacja modelu między tymi tabelami a tabelą Flight jest aktywna. Zwróć również uwagę, że nazwy kolumn w tabelach Departure Airport i Arrival Airport są poprzedzone wyrazem Odlot lub Arrival.

Ulepszony projekt modelu obsługuje tworzenie następującego projektu raportu.

Strona raportu filtruje według Melbourne jako lotnisko odlotu, a tabela wizualna grupuje według lotnisk przylotów.

Notatka

W przypadku modeli importu dodanie innej tabeli wymiarów spowodowało zwiększenie rozmiaru modelu i dłuższy czas odświeżania. W związku z tym jest to sprzeczne z zaleceniami opisanymi w artykule Techniki redukcji danych dotyczące modelowania importu. Jednak w tym przykładzie wymóg posiadania tylko aktywnych relacji zastępuje te zalecenia.

Ponadto tabele wymiarów często przechowują niewielką liczbę wierszy w porównaniu do liczby wierszy tabeli faktów. Dlatego zwiększone rozmiary modelu i czasy odświeżania prawdopodobnie nie będą zbyt duże.

Metodologia refaktoryzacji

Oto metoda refaktoryzacji modelu z jednej tabeli wymiaru pełniącej rolę do schematu z jedną tabelą na rolę.

1. Usuń wszystkie nieaktywne relacje.

2. Rozważ zmianę nazwy tabeli wymiarów dla odgrywania ról, aby lepiej opisać jego rolę. W przykładzie w tym artykule tabela Airport jest powiązana z kolumną ArrivalAirport tabeli Flight, więc zmieniono jej nazwę na Arrival Airport.

3. Utwórz kopię tabeli odgrywania ról, nadając jej nazwę, która odzwierciedla jej rolę. Jeśli jest to tabela importu, zalecamy utworzenie tabeli obliczeniowej. Jeśli jest to tabela DirectQuery, możesz zduplikować zapytanie Power Query.

   W tym przykładzie tabela Departure Airport została utworzona przy użyciu następującej definicji tabeli obliczeniowej.

   Departure Airport = 'Arrival Airport'
   

4. Utwórz aktywną relację, aby powiązać nową tabelę.

5. Rozważ zmianę nazw kolumn w tabelach, aby dokładnie odzwierciedlały swoją rolę. W przykładzie w tym artykule wszystkie kolumny są poprzedzone wyrazem Odlot lub Przyjazd. Te nazwy zapewniają, że wizualizacje raportów domyślnie będą miały etykiety samoopisowe i jednoznaczne. Usprawnia również środowisko Q&A, dzięki czemu użytkownicy mogą łatwo pisać dokładne pytania.

6. Rozważ dodanie opisów do tabel do gier fabularnych. (W okienku Dane opis jest wyświetlany w etykietce narzędzia, gdy autor raportu najecha kursorem na tabelę). Dzięki temu można przekazać innym szczegółom propagacji filtru autorom raportów.

Nieaktywne relacje

W określonych okolicznościach nieaktywne relacje mogą zaspokoić określone potrzeby raportowania.

Rozważ różne wymagania dotyczące modelu i raportowania:

• Model sprzedaży zawiera tabelę Sales zawierającą dwie kolumny dat: OrderDate i ShipDate.
• Każdy wiersz w tabeli Sales rejestruje jedną kolejność.
• Filtry dat są prawie zawsze stosowane do kolumny OrderDate, która zawsze przechowuje prawidłową datę.
• Tylko jedna miara wymaga propagacji filtra daty do kolumny ShipDate, która może zawierać puste wartości (do momentu wysłania zamówienia).
• Nie ma potrzeby jednoczesnego filtrowania (lub grupowania) zamówień i w okresach dla daty wysyłki.

Oto częściowy diagram modelu dwóch tabel.

Istnieją dwie relacje modelu między tabelami Sales i Date. W tabeli Sales kolumny OrderDate i ShipDate odnoszą się do kolumny Date tabeli Date. W tym modelu dwie role tabeli Date to data zamówienia i data wysyłki. Relacja z kolumną OrderDate jest aktywna.

Wszystkie sześć miar, z wyjątkiem jednej, musi być filtrowane według kolumny OrderDate. Miara Orders Shipped musi jednak filtrować według kolumny ShipDate.

Oto definicja miary Orders. Po prostu zlicza wiersze tabeli Sales w kontekście filtru. Wszystkie filtry zastosowane do tabeli Date są propagowane do kolumny OrderDate.

Orders = COUNTROWS(Sales)

Oto definicja miary Orders Shipped. Używa funkcji USERELATIONSHIP języka DAX, która aktywuje propagację filtru dla określonej relacji, ale tylko podczas obliczania wyrażenia. W tym przykładzie jest używana relacja z kolumną ShipDate.

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

Ten model umożliwia tworzenie następującego projektu raportu.

Strona raportu filtruje według kwartału 2019 Q4. Wizualizacja tabeli grupuje według miesiąca i wyświetla różne statystyki sprzedaży. Miary Orders i Orders Shipped generują różne wyniki. Każda z nich używa tej samej logiki podsumowania (zlicza wiersze tabeli Sales), ale ma różną propagację filtru tabeli Date.

Zwróć uwagę, że fragmentator kwartału zawiera opcję BLANK. Ta opcja fragmentatora jest wyświetlana w wyniku rozszerzenia tabeli . Chociaż każdy wiersz tabeli Sales ma prawidłową datę zamówienia, niektóre wiersze mają pustą datę wysyłki — te zamówienia nie zostały jeszcze wysłane. Rozszerzenie tabeli uwzględnia również nieaktywne relacje, dlatego mogą pojawić się wartości BLANKs po wielu stronach relacji (lub z powodu problemów z integralnością danych).

Uwaga

Filtry zabezpieczeń na poziomie wiersza są propagowane tylko za pomocą aktywnych relacji. Filtry RLS nigdy nie są propagowane dla nieaktywnych relacji, nawet jeśli funkcja DAX USERELATIONSHIP jest używana przez definicję miary.

Zalecenia

Zalecamy definiowanie aktywnych relacji zawsze, gdy jest to możliwe, zwłaszcza gdy role RLS (zabezpieczeń na poziomie wiersza) są definiowane dla modelu danych. Rozszerzają zakres i potencjał użycia Twojego modelu przez autorów raportów oraz użytkowników pracujących z Q&A. Oznacza to, że tabele wymiarów pełniące różne role powinny być zduplikowane w modelu.

W określonych okolicznościach można jednak zdefiniować jedną lub więcej nieaktywnych relacji dla tabeli wymiarów odgrywających rolę. Takie podejście można wziąć pod uwagę, gdy:

• Nie ma potrzeby jednoczesnego filtrowania wizualizacji raportów według różnych ról.
• Funkcja DAX USERELATIONSHIP służy do aktywowania określonej relacji na potrzeby odpowiednich obliczeń modelu.

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
• Zrozumienie schematu gwiazdy i jego znaczenie dla Power BI
• wskazówki dotyczące rozwiązywania problemów z relacjami
• Pytania? Spróbuj zapytać społeczność Fabric
• Sugestie? Wnoszenie pomysłów na poprawę Fabric