Linia relacji jest przerywana - relacja nieaktywna i funkcja USERELATIONSHIP

Power BI - Model danych i relacje

Linia relacji jest przerywana - relacja nieaktywna i funkcja USERELATIONSHIP

W skrócie

Druga linia między tabelą faktów a tabelą dat jest na diagramie modelu przerywana, a wizualizacje dalej liczą po pierwszej dacie. Relacja nieaktywna pojawia się w Power BI wtedy, gdy tabela faktów ma dwie daty, na przykład datę zwrotu i datę zakupu albo datę zamówienia i datę wysyłki. Pokazujemy na zwrotach Nordvelli, dlaczego tak jest, jak napisać miarę z USERELATIONSHIP i kiedy lepsza jest druga tabela dat.

Jak to wygląda w praktyce

Na diagramie modelu (Widok modelu) dwie tabele łączą dwie linie: ciągła to relacja aktywna, przerywana to nieaktywna. W oknie Zarządzanie relacjami kolumna Stan pokazuje, która jest nieaktywna. W modelu Nordvelli FaktZwroty łączy się z DimKalendarz po DataZwrotu (aktywna) i po DataZakupu (nieaktywna).

Według dokumentacji Microsoft Power BI Desktop dopuszcza w danej chwili tylko jedną aktywną relację między dwiema tabelami, więc zanim zaznaczysz Aktywuj tę relację w drugiej, trzeba wyłączyć pierwszą. Komunikat o tej sytuacji brzmi: „Istnieje już aktywna relacja między elementami FaktZwroty i DimKalendarz. Aby uaktywnić tę relację, najpierw zdezaktywuj istniejącą relację.” (w angielskiej wersji: „An active relationship already exists between FaktZwroty and DimKalendarz. To make this relationship active, deactivate the existing relationship first.”). Skutek w liczbach: tabela z rokiem z DimKalendarz i sumą WartoscZwrotu pokazuje dla 2022 roku -2 309 610,35 zł, czyli zwroty przyjęte w 2022. Zwroty z zakupów zrobionych w 2022 to -2 497 448,50 zł, ale tej liczby wizualizacja sama nie pokaże.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Dlaczego tak się dzieje

Według dokumentacji Microsoft między dwiema tabelami modelu może istnieć tylko jedna aktywna ścieżka propagacji filtra, bo ścieżki muszą być jednoznaczne. Dwie relacje FaktZwroty z DimKalendarz dałyby dwie drogi dla tego samego filtra roku: po dacie zwrotu i po dacie zakupu. Dlatego przy tworzeniu drugiej relacji pole Aktywuj tę relację jest już odznaczone. Nieaktywna relacja przenosi filtry tylko wtedy, gdy wyrażenie DAX ją wywoła. Druga przyczyna przerywanej linii to ścieżka przez inne tabele, którą opisujemy w poście o niejednoznacznej ścieżce między tabelami.

Różnica między datami nie jest kosmetyczna. Z 2714 zwrotów Nordvelli 1262 mają zakup w innym miesiącu niż zwrot, a 222 w innym roku. W styczniu 2025 zwroty według daty zwrotu to -453 076,67 zł, a według daty zakupu -279 830,20 zł. Zwroty są w danych zapisane ze znakiem minus.

Co zrobić krok po kroku

1. Znajdź nieaktywną relację. Otwórz Widok modelu i najedź kursorem na przerywaną linię albo ją zaznacz, żeby zobaczyć połączone kolumny. Pełną listę daje karta Modelowanie, przycisk Zarządzanie relacjami: kolumna Stan pokazuje, które relacje są nieaktywne.
2. Zdecyduj, która data jest główna, i zostaw jej relację aktywną. Nie przełączaj aktywności tylko po to, żeby jedna wizualizacja zadziałała: po aktywowaniu relacji po DataZakupu wszystkie miary na FaktZwroty i wszystkie filtry kalendarza zaczną liczyć po dacie zakupu.
3. Dla drugiej daty napisz miarę z USERELATIONSHIP. Zaznacz FaktZwroty w panelu Dane, kliknij Nowa miara i wpisz formułę. USERELATIONSHIP włącza relację po DataZakupu tylko na czas liczenia tej miary i według dokumentacji Microsoft zastępuje wtedy aktywną relację między tymi tabelami. Na Nordvelli miara daje dla 2022 roku -2 497 448,50 zł, dla 2025 -3 665 013,08 zł.

   Wartosc zwrotow wg daty zakupu =
   CALCULATE(
       SUM(FaktZwroty[WartoscZwrotu]),
       USERELATIONSHIP(FaktZwroty[DataZakupu], DimKalendarz[DataID])
   )

4. Unikaj dwóch błędów. USERELATIONSHIP użyta poza argumentem filtra daje „Funkcji USERELATIONSHIP można używać tylko w funkcji CALCULATE.” (w angielskiej wersji: „USERELATIONSHIP function can only be used in the CALCULATE function.”). Według dokumentacji działa też w CALCULATETABLE i funkcjach takich jak TOTALYTD. Kolumny, między którymi nie ma relacji, dają „W funkcji USERELATIONSHIP można używać tylko dwóch odwołań do kolumn uczestniczących w relacji.” (w angielskiej wersji: „USERELATIONSHIP function can only use the two columns references participating in relationship.”). Dokumentacja dodaje, że funkcja zwraca błąd, gdy dla tabeli, której dotyczy relacja, zdefiniowano zabezpieczenia na poziomie wiersza (RLS, czyli reguły ograniczające wiersze widoczne dla użytkownika).
5. Postaw obie miary obok siebie w tabeli z polem Rok z DimKalendarz. Na Nordvelli 2023 to -2 963 550,81 zł według daty zwrotu i -3 062 674,88 zł według daty zakupu, 2026 to -1 818 192,67 zł i -1 420 097,44 zł. Nazwa miary mówi, po której dacie liczy, więc odbiorca nie pomyli kolumn.
6. Gdy raport ma filtrować po obu datach naraz, na przykład rok zwrotu w wierszach i rok zakupu w kolumnach, USERELATIONSHIP nie wystarczy, bo w danej mierze działa jedna relacja. Dokumentacja Microsoft zaleca wtedy osobną tabelę dla każdej roli daty: usuń nieaktywną relację, w widoku tabeli na karcie Narzędzia tabel kliknij Nowa tabela i wpisz kopię kalendarza, a potem połącz FaktZwroty[DataZakupu] z jej kolumną DataID aktywną relacją. Nazwy kolumn kopii poprzedź słowem zakupu. To wzorzec do dostosowania: model rośnie o drugą tabelę dat.

   Kalendarz zakupu = DimKalendarz

Jak sprawdzić, że problem zniknął

Suma obu miar dla całego okresu musi być taka sama, bo to te same zwroty rozłożone w czasie inaczej. Na Nordvelli obie dają -14 022 095,44 zł z 2714 zwrotów. Różnice mają się pojawić tylko w rozbiciu na lata i miesiące. Gdy miara z USERELATIONSHIP pokazuje to samo co miara zwykła w każdym roku, sprawdź, czy relacja w funkcji wskazuje właściwe kolumny.

Dla każdej dodatkowej daty w faktach decyduj od razu: miara z USERELATIONSHIP, gdy druga data potrzebna jest w kilku miarach, albo tabela roli, gdy ma filtrować całe wizualizacje. Gdy kopia kalendarza ma służyć funkcjom inteligencji czasowej, oznacz ją jako tabelę dat tak samo jak DimKalendarz, o czym piszemy w poście o oznaczaniu tabeli dat i w lekcji o YTD i porównaniach rok do roku.

Źródła i sposób sprawdzenia

• Microsoft Learn: Active vs inactive relationship guidance (źródło)
• Microsoft Learn: USERELATIONSHIP function (DAX) (źródło)
• Microsoft Learn: Model relationships in Power BI Desktop (Make this relationship active) (źródło)
• Sprawdzone zapytaniami DAX na modelu Nordvelli: relacje FaktZwroty z INFO.VIEW.RELATIONSHIPS, miary według daty zwrotu i zakupu w latach i miesiącach, błędy USERELATIONSHIP.

Zachowanie programu sprawdziliśmy w Power BI Desktop 2.157 (wydanie z sierpnia 2026 r.) z polskim interfejsem, a przykłady na modelu sieci Nordvella z bezpłatnego kursu Power BI. Microsoft wydaje nową wersję Power BI Desktop co miesiąc, więc nazwy przycisków i limity usługi mogą się zmieniać. Aktualne wartości podaje dokumentacja Microsoft Learn.

Wróć do listy: 131 najczęstszych pytań i problemów związanych z Power BI