Wskazówki dotyczące aktywnej i nieaktywnej relacji

Ten artykuł jest przeznaczony dla Ciebie jako modeler danych pracujący 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.

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.

Aktywne relacje

Ogólnie rzecz biorąc, zalecamy definiowanie aktywnych relacji zawsze wtedy, gdy jest to możliwe. Rozszerzają zakres i potencjał sposobu, w jaki model może być używany przez autorów raportów i użytkowników pracujących z pytaniami i pytaniami.

Rozważmy przykład modelu importu zaprojektowanego 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 (Lotnisko), która jest tabelą wymiarów przechowując jeden wiersz na lotnisko. 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 (Lotnisko) tabeli Airport (Lotnisko). W projekcie schematu gwiazdy tabela Airport (Lotnisko ) jest opisana jako wymiar odgrywania roli. W tym modelu dwie role to lotnisko odlotu i lotnisko przylotu.

Chociaż ten projekt dobrze sprawdza się w przypadku projektów schematów relacyjnych gwiazd, nie dotyczy modeli usługi Power BI. Jest to spowodowane tym, że relacje modelu są ścieżkami propagacji filtru, a te ścieżki muszą być deterministyczne. Aby uzyskać więcej informacji na temat zapewniania, że ścieżki propagacji filtru są deterministyczne, zobacz Rozwiązywanie niejednoznaczności ścieżki relacji. W związku z tym — jak opisano w tym przykładzie — jedna relacja jest aktywna, a druga jest nieaktywna (reprezentowana przez linię przerywaną). W szczególności jest to relacja z kolumną ArrivalAirport , która jest aktywna. Oznacza to, ż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 (Lotnisko ) w celu automatycznego izolowania szczegółów lotów dla lotniska odlotu. Ponieważ wymagania dotyczące raportowania obejmują filtrowanie (lub grupowanie) według portów lotniczych odlotu i przylotu w tym samym czasie, potrzebne są dwie aktywne relacje. Tłumaczenie tego wymagania na projekt modelu usługi Power BI oznacza, że model musi mieć dwie tabele lotniska.

Oto ulepszony projekt modelu.

Model ma teraz dwie tabele lotnisk: Lotnisko odlotu i Lotnisko przylotu. Relacje modelu między tymi tabelami a tabelą Flight są aktywne. Zwróć również uwagę, że nazwy kolumn w tabelach Lotnisko odlotów i Lotnisko przylotu są poprzedzone słowem Odlot lub Przylot.

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

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

Uwaga

W przypadku modeli importu dodatkowa tabela spowodowała 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 na potrzeby importowania modelowania . Jednak w tym przykładzie wymóg posiadania tylko aktywnych relacji zastępuje te zalecenia.

Ponadto często tabele wymiarów zawierają małe liczby wierszy względem 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 metodologia refaktoryzacji modelu z pojedynczej tabeli wymiarów odgrywających rolę do projektu z jedną tabelą na rolę.

1. Usuń wszystkie nieaktywne relacje.

2. Rozważ zmianę nazwy tabeli wymiarów odgrywających rolę, aby lepiej opisać jej rolę. W tym przykładzie tabela Airport (Lotnisko) jest powiązana z kolumną ArrivalAirport tabeli Flight (Lot), więc jej nazwa została zmieniona na Lotnisko przylotu.

3. Utwórz kopię tabeli odgrywanej przez rolę, podając jej nazwę, która odzwierciedla jego rolę. Jeśli jest to tabela Importuj, zalecamy zdefiniowanie tabeli obliczeniowej. Jeśli jest to tabela DirectQuery, możesz zduplikować zapytanie Power Query.

   W tym przykładzie tabela Lotnisko odlotów została utworzona przy użyciu poniższej 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 tym przykładzie wszystkie kolumny są poprzedzone słowem Odlot lub Przylot. Te nazwy zapewniają, że wizualizacje raportów domyślnie będą miały etykiety samoopisujące i niejednoznaczne. Usprawnia to również środowisko pytań i odpowiedzi, dzięki czemu użytkownicy mogą łatwo pisać swoje pytania.

6. Rozważ dodanie opisów do tabel odgrywających rolę. (W Okienko Pola — opis jest wyświetlany w etykietce narzędzia, gdy autor raportu umieści kursor nad tabelą. Dzięki temu możesz przekazać autorom raportów wszelkie dodatkowe szczegóły propagacji filtru.

Nieaktywne relacje

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

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

• Model sprzedaży zawiera tabelę Sales (Sprzedaż) zawierającą dwie kolumny dat: OrderDate (Data zamówienia) i ShipDate (Data wysyłki)
• Każdy wiersz w tabeli Sales rejestruje jedno zamówienie
• Filtry dat są prawie zawsze stosowane do kolumny OrderDate , która zawsze przechowuje prawidłową datę
• Tylko jedna miara wymaga propagacji filtru daty do kolumny ShipDate , która może zawierać wartości BLANKs (do momentu wysłania zamówienia)
• Nie ma potrzeby jednoczesnego filtrowania (lub grupowania według) okresu zamówienia i 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 (Data zamówienia) i ShipDate (Data wysyłki) odnoszą się do kolumny Date (Data) tabeli Date (Data). W tym modelu dwie role tabeli Date (Data) to data zamówienia i data wysyłki. Jest to relacja z kolumną OrderDate , która jest aktywna.

Wszystkie sześć miar — z wyjątkiem jednej — musi filtrować według kolumny OrderDate . Miara Orders Shipped (Wysłane zamówienia) musi jednak filtrować według kolumny ShipDate (Data wysyłki).

Oto definicja miary Orders (Zamówienia). Po prostu zlicza wiersze tabeli Sales w kontekście filtru. Wszystkie filtry zastosowane do tabeli Date będą propagowane do kolumny OrderDate .

Orders = COUNTROWS(Sales)

Oto definicja miary Orders Shipped (Zamówienia wysłane). Używa funkcji JĘZYKA DAX USERELATIONSHIP , która aktywuje propagację filtru dla określonej relacji 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 projekt modelu obsługuje tworzenie następującego projektu raportu.

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

Zwróć uwagę, że fragmentator kwartału zawiera element BLANK. Ten element fragmentatora jest wyświetlany w wyniku rozszerzenia tabeli. Chociaż każdy wiersz tabeli Sales ma datę zamówienia, niektóre wiersze mają datę wysyłki BLANK — te zamówienia nie zostały jeszcze wysłane. Rozszerzenie tabeli uwzględnia również nieaktywne relacje, a więc zestawy BLAN Mogą pojawiać się z powodu zestawów BLAN Po stronie wielu relacji lub z powodu problemów z integralnością danych.

Uwaga

Filtry zabezpieczeń na poziomie wiersza są propagowane tylko za pomocą aktywnych relacji. Filtry zabezpieczeń na poziomie wiersza nie będą propagowane dla nieaktywnych relacji, nawet jeśli funkcja UseRelationship zostanie jawnie dodana do definicji miary.

Zalecenia

Podsumowując, zalecamy definiowanie aktywnych relacji zawsze, gdy jest to możliwe, zwłaszcza gdy role zabezpieczeń na poziomie wiersza są definiowane dla modelu danych. Rozszerzają zakres i potencjał sposobu, w jaki model może być używany przez autorów raportów i użytkowników pracujących z pytaniami i pytaniami. Oznacza to, że tabele wymiarów odgrywające rolę 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ę. Ten projekt można wziąć pod uwagę, gdy:

• Nie ma potrzeby jednoczesnego filtrowania wizualizacji raportów według różnych ról
• Funkcja JĘZYKA DAX USERELATIONSHIP służy do aktywowania określonej relacji dla 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
• Omówienie schematu gwiazdy i znaczenia usługi Power BI
• 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