cognity: Power BI średniozaawansowany – najważniejsze funkcje DAX w codziennej analizie danych

Wprowadzenie: po co DAX w codziennej analizie i poziom „średniozaawansowany”

DAX w Power BI to język, który pozwala przejść od prostego raportowania do świadomej analizy danych. Gdy same wykresy i podstawowe sumy przestają wystarczać, właśnie DAX umożliwia tworzenie logiki biznesowej: liczenie wskaźników, porównywanie wyników, kontrolowanie sposobu filtrowania oraz budowanie miar, które reagują na wybory użytkownika w raporcie. W praktyce oznacza to mniej ręcznej obróbki danych poza modelem i większą elastyczność już na etapie analizy.

W codziennej pracy DAX przydaje się wtedy, gdy trzeba odpowiedzieć na pytania bardziej złożone niż „jaka jest suma sprzedaży”. Analityk często potrzebuje obliczyć marżę, udział procentowy, wynik narastająco, wartość za wybrany okres, porównanie rok do roku albo wynik tylko dla określonej grupy produktów czy klientów. Takie potrzeby pojawiają się regularnie w raportach operacyjnych, controllingowych, sprzedażowych i finansowych. DAX nie służy więc wyłącznie do zaawansowanych modeli — jest bardzo praktycznym narzędziem w zwykłej, powtarzalnej analizie.

Poziom średniozaawansowany można rozumieć jako moment, w którym użytkownik zna już podstawy Power BI, potrafi zbudować model danych, utworzyć proste miary i rozumie, że wynik na wizualizacji zależy od filtrów. Na tym etapie nie chodzi jeszcze o najbardziej złożone techniki, lecz o swobodne korzystanie z najważniejszych mechanizmów DAX w realnych scenariuszach biznesowych. To poziom, na którym zaczyna się świadome projektowanie obliczeń, a nie tylko kopiowanie pojedynczych formuł.

Warto też odróżnić DAX od innych elementów pracy z danymi w Power BI. Power Query służy głównie do przygotowania i przekształcania danych przed załadowaniem ich do modelu, natomiast DAX działa już na danych znajdujących się w modelu i odpowiada za obliczenia analityczne. Innymi słowy: jedno narzędzie porządkuje dane, drugie pomaga je interpretować. To rozróżnienie jest kluczowe, bo wiele problemów można rozwiązać na różne sposoby, ale nie każdy sposób będzie równie wygodny, wydajny i czytelny.

Na poziomie średniozaawansowanym szczególnie istotne staje się rozumienie, że DAX nie jest tylko zbiorem funkcji. To przede wszystkim sposób myślenia o danych w modelu: o filtrach, relacjach, agregacjach i zależnościach między tabelami. Dobra miara nie tylko zwraca poprawny wynik, ale także zachowuje się przewidywalnie w różnych kontekstach raportu. Właśnie dlatego znajomość najważniejszych funkcji DAX powinna iść w parze ze zrozumieniem logiki ich działania.

• DAX pomaga budować wskaźniki biznesowe, które trudno uzyskać samymi domyślnymi agregacjami.
• Umożliwia dynamiczną analizę zależną od filtrów, segmentatorów i układu wizualizacji.
• Pozwala pracować na logice modelu, a nie tylko na pojedynczych kolumnach z danymi.
• Wspiera codzienną analizę w raportach sprzedażowych, finansowych i operacyjnych.
• Na poziomie średniozaawansowanym najważniejsze jest nie tylko pisanie formuł, ale rozumienie, dlaczego zwracają taki, a nie inny wynik.

DAX bywa postrzegany jako trudny, ponieważ na pierwszy rzut oka wiele formuł wygląda podobnie, a mimo to daje różne rezultaty. W rzeczywistości największym wyzwaniem nie jest zapamiętanie składni, lecz zrozumienie zasad działania modelu i kontekstu obliczeń. Kiedy te podstawy stają się jasne, DAX zaczyna być narzędziem bardzo praktycznym: pozwala pisać krótsze, bardziej trafne i łatwiejsze do utrzymania obliczenia.

Dla użytkownika średniozaawansowanego kluczowe jest więc opanowanie tych funkcji i wzorców, które najczęściej pojawiają się w codziennej pracy. Nie chodzi o znajomość całego języka, ale o pewne poruszanie się po jego najważniejszych obszarach i świadome dobieranie rozwiązań do konkretnego celu analitycznego.

Kontekst wiersza vs kontekst filtra: jak myśleć o miarach i kolumnach obliczeniowych

Jednym z najważniejszych momentów w nauce DAX na poziomie średniozaawansowanym jest zrozumienie, że ten sam wzór może zwracać inny wynik zależnie od kontekstu obliczeń. W praktyce najczęściej spotykamy dwa podstawowe rodzaje kontekstu: kontekst wiersza i kontekst filtra. To właśnie one decydują o tym, czy lepiej użyć kolumny obliczeniowej, czy miary.

Kontekst wiersza oznacza, że formuła jest liczona dla konkretnego rekordu. DAX „patrzy” wtedy na pojedynczy wiersz i może odwoływać się do wartości z jego kolumn. Taki sposób działania jest typowy przede wszystkim dla kolumn obliczeniowych. Jeśli chcemy wyliczyć wartość przypisaną na stałe do każdego wiersza, na przykład marżę dla pojedynczej transakcji, flagę spełnienia warunku albo połączony opis z kilku pól, zwykle myślimy właśnie w kategoriach kontekstu wiersza.

Kontekst filtra działa inaczej. Nie dotyczy jednego rekordu, lecz zbioru danych, który pozostał po zastosowaniu filtrów z raportu, relacji modelu, segmentatorów, osi wykresu czy zaznaczeń użytkownika. To naturalne środowisko pracy dla miar. Miara nie zapisuje wyniku w każdym wierszu tabeli, tylko oblicza go dynamicznie dla aktualnie widocznego fragmentu danych. Dzięki temu ta sama miara może pokazać inną wartość dla całego roku, inną dla jednego miesiąca, a jeszcze inną dla wybranego produktu lub regionu.

Najprościej można to zapamiętać tak:

• kolumna obliczeniowa odpowiada na pytanie: „co policzyć dla tego konkretnego wiersza?”
• miara odpowiada na pytanie: „co policzyć dla aktualnie przefiltrowanego zbioru danych?”

Ta różnica ma bardzo praktyczne konsekwencje. Kolumny obliczeniowe są liczone podczas odświeżania modelu i przechowywane w danych. To oznacza, że ich wynik jest stabilny, ale zwiększa rozmiar modelu. Miary są obliczane dopiero w momencie użycia w wizualizacji, więc są bardziej elastyczne i lepiej nadają się do analiz zależnych od wyborów użytkownika.

W codziennej pracy warto przyjąć prostą zasadę: jeśli wynik ma reagować na filtry w raporcie, najczęściej potrzebna będzie miara. Jeśli wynik ma być cechą pojedynczego rekordu i ma dać się wykorzystać jak zwykła kolumna, częściej właściwa będzie kolumna obliczeniowa.

Początkujące i średniozaawansowane osoby często mylą te dwa podejścia, bo oba korzystają z DAX, ale służą do czegoś innego. Typowy błąd polega na próbie zapisania logiki agregacji w kolumnie obliczeniowej albo odwrotnie — oczekiwaniu, że miara „zapamięta” wynik dla każdego wiersza. W Cognity często spotykamy się z pytaniami na ten temat podczas szkoleń, dlatego postanowiliśmy przybliżyć go również na blogu.

• kolumna obliczeniowa dobrze sprawdza się przy klasyfikacji, oznaczeniach i przeliczeniach na poziomie rekordu,
• miara jest lepsza do sum, średnich, udziałów, wskaźników i porównań widocznych w raportach.

Warto też pamiętać, że kontekst filtra może pochodzić z wielu miejsc jednocześnie. Użytkownik może wybrać rok w segmentatorze, produkt na wykresie i dodatkowo ograniczyć dane filtrem strony. Miara bierze to wszystko pod uwagę i zwraca wynik dla tak zawężonego zbioru. To właśnie dlatego DAX jest tak silnym narzędziem analitycznym — pozwala budować obliczenia reagujące na sposób eksploracji danych.

Z kolei kontekst wiersza jest bardziej „lokalny”. Skupia się na pojedynczym rekordzie i nie daje jeszcze pełnej odpowiedzi na pytania analityczne typu: ile wynosi sprzedaż w wybranym okresie, jaki jest udział kategorii w całości albo jak zmienia się wynik po zastosowaniu filtra. Do takich zadań potrzebne jest myślenie w kategoriach filtra i agregacji.

Dla osoby pracującej z Power BI najważniejsze jest więc nie tylko poznanie funkcji DAX, ale też właściwe zadanie sobie pytania przed napisaniem formuły: czy chcę policzyć coś dla pojedynczego wiersza, czy dla aktualnie wybranego zbioru danych? Ta decyzja bardzo często przesądza o poprawnym projekcie modelu i o tym, czy raport będzie działał intuicyjnie, szybko i zgodnie z oczekiwaniami użytkownika.

CALCULATE w praktyce: zmiana kontekstu, typowe wzorce i najczęstsze pułapki

CALCULATE to jedna z najważniejszych funkcji DAX, ponieważ pozwala zmienić kontekst obliczenia. W praktyce oznacza to, że ta sama miara może zwracać różne wyniki zależnie od tego, jakie filtry zostaną dodane, usunięte albo zastąpione wewnątrz wyrażenia. To właśnie dzięki CALCULATE tworzy się większość miar biznesowych używanych na co dzień: sprzedaż dla wybranego roku, wynik dla konkretnej kategorii, udział procentowy w całości czy wartość z pominięciem części filtrów raportu.

Najprościej myśleć o tej funkcji tak: najpierw definiujesz, co chcesz policzyć, a potem określasz, w jakim kontekście ma to być policzone. Sama agregacja, na przykład SUM lub DISTINCTCOUNT, często nie wystarcza. Dopiero CALCULATE daje kontrolę nad tym, jakie dane mają wejść do obliczenia.

Sprzedaż 2024 =
CALCULATE(
    SUM(Sales[Amount]),
    'Date'[Year] = 2024
)

W powyższym przykładzie miara liczy sumę sprzedaży, ale tylko dla rekordów spełniających dodatkowy warunek. To podstawowy i najczęściej spotykany sposób użycia tej funkcji.

Co dokładnie robi CALCULATE

W praktyce CALCULATE służy do kilku typowych działań:

• dodawania filtrów do istniejącego kontekstu,
• nadpisywania filtrów już obecnych w raporcie,
• usuwania części filtrów, aby policzyć wartość odniesienia,
• wymuszenia innego sposobu obliczenia niż ten wynikający z bieżącego widoku wizualizacji.

To sprawia, że CALCULATE jest centralnym narzędziem przy budowie miar analitycznych. Bez niej raport zwykle ograniczałby się do prostych sum i średnich zależnych wyłącznie od klikniętych filtrów.

Najczęstsze zastosowania w codziennej analizie

To właśnie w takich scenariuszach widać przewagę DAX nad prostym przeciąganiem pól na wykres. Miara oparta o CALCULATE nie tylko zlicza dane, ale realizuje konkretną logikę analityczną.

Typowe wzorce

Jednym z najczęstszych wzorców jest liczenie wartości dla konkretnego warunku biznesowego:

Sprzedaż online =
CALCULATE(
    SUM(Sales[Amount]),
    Sales[Channel] = "Online"
)

Inny bardzo popularny przypadek to liczenie udziału w całości, gdzie trzeba usunąć część filtrów z bieżącego widoku:

Udział kategorii =
DIVIDE(
    SUM(Sales[Amount]),
    CALCULATE(SUM(Sales[Amount]), ALL(Product[Category]))
)

Taka konstrukcja pozwala porównać wynik dla bieżącej kategorii z wartością policzoną szerzej, bez ograniczenia do pojedynczej kategorii. To klasyczny przykład użycia CALCULATE do budowy miar porównawczych.

Często spotyka się też miary, które mają działać „pomimo” wybranego filtra w raporcie. Wtedy CALCULATE służy do przywrócenia szerszej perspektywy, na przykład całego roku, wszystkich produktów albo całego portfela klientów.

Najważniejsza praktyczna różnica: zwykła agregacja vs CALCULATE

To rozróżnienie jest kluczowe. Jeżeli wynik ma być po prostu sumą widocznych danych, zwykła agregacja często wystarczy. Jeżeli jednak wynik ma być liczony według dodatkowych zasad, zwykle potrzebny jest właśnie CALCULATE.

Najczęstsze pułapki

• Niezrozumienie, że CALCULATE może nadpisywać filtr – jeśli w raporcie użytkownik wybierze jeden rok, a miara wewnątrz CALCULATE wymusza inny, wynik będzie zgodny z miarą, a nie z intuicją użytkownika.
• Mylenie filtrowania raportu z filtrowaniem w miarze – filtr ustawiony na wizualizacji i filtr wpisany w CALCULATE nie zawsze działają tak samo z perspektywy końcowego wyniku.
• Zbyt rozbudowane warunki w jednym miejscu – im więcej logiki zostanie umieszczone bezpośrednio w CALCULATE, tym trudniej później zrozumieć, dlaczego miara zwraca dany wynik.
• Używanie CALCULATE tam, gdzie nie jest potrzebny – nie każda miara wymaga zmiany kontekstu; czasem prostsza formuła będzie czytelniejsza i łatwiejsza do utrzymania.
• Błędne oczekiwania wobec wyniku sumarycznego – wartość w wierszu szczegółowym i w totalu nie zawsze zachowuje się tak, jak w Excelu. CALCULATE działa w kontekście całego elementu wizualizacji, a nie jako proste sumowanie widocznych komórek.

Jak pracować z CALCULATE bez komplikowania modelu

W codziennej pracy najlepiej zaczynać od prostego schematu: najpierw utworzyć podstawową miarę, a dopiero później opakować ją w CALCULATE, jeśli naprawdę trzeba zmienić kontekst. Dzięki temu formuły są bardziej czytelne i łatwiejsze do testowania.

Sprzedaż = SUM(Sales[Amount])

Sprzedaż dla aktywnych =
CALCULATE(
    [Sprzedaż],
    Customer[Status] = "Active"
)

Takie podejście upraszcza rozwój modelu i pozwala szybciej wychwycić, czy problem wynika z samej agregacji, czy z logiki filtrowania. W praktyce CALCULATE najlepiej traktować nie jako „trudną funkcję techniczną”, ale jako narzędzie do sterowania perspektywą obliczeń. To właśnie ono sprawia, że miary w Power BI zaczynają odpowiadać realnym pytaniom biznesowym, a nie tylko prezentować surowe sumy danych.

Kluczowe grupy funkcji DAX z przykładami: agregacje i iteratory (SUMX/AVERAGEX)

W codziennej pracy z Power BI jedną z najważniejszych umiejętności jest rozróżnienie między prostymi agregacjami a iteratorami. Obie grupy funkcji służą do liczenia wartości, ale działają w inny sposób i sprawdzają się w innych scenariuszach analitycznych.

Najprościej mówiąc: funkcje takie jak SUM, AVERAGE, MIN czy MAX liczą bezpośrednio na kolumnie, natomiast iteratory, np. SUMX i AVERAGEX, najpierw przechodzą po kolejnych wierszach tabeli, wykonują obliczenie dla każdego z nich, a dopiero potem zwracają wynik końcowy.

Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności, ponieważ na pierwszy rzut oka funkcje agregujące i iteratory mogą wyglądać podobnie, choć w praktyce prowadzą do zupełnie innych rezultatów biznesowych.

Agregacje: szybkie i czytelne obliczenia na jednej kolumnie

Podstawowe funkcje agregujące są najlepszym wyborem wtedy, gdy wynik można uzyskać przez policzenie jednej, istniejącej kolumny. To najprostszy i zwykle najbardziej czytelny sposób budowy miary.

• SUM – sumuje wartości w kolumnie,
• AVERAGE – oblicza średnią,
• MIN i MAX – zwracają odpowiednio najmniejszą i największą wartość,
• COUNT / COUNTROWS – służą do zliczania.

Przykład prostej miary:

Sprzedaż = SUM(Sales[Amount])

Taka definicja jest wystarczająca, jeśli w modelu istnieje już kolumna Amount zawierająca poprawnie wyliczoną wartość sprzedaży dla każdego rekordu.

Iteratory: gdy trzeba policzyć coś „wiersz po wierszu”

Iteratorów używa się wtedy, gdy samo zsumowanie jednej kolumny nie wystarcza. Typowy przypadek to sytuacja, w której wartość końcowa powstaje dopiero z obliczenia wykonywanego na każdym wierszu osobno, na przykład:

• ilość × cena,
• wartość po rabacie,
• średnia z wyrażenia, a nie z gotowej kolumny,
• obliczenia ważone.

Właśnie tutaj pojawia się SUMX lub AVERAGEX. Litera X oznacza, że funkcja iteruje po tabeli i liczy podane wyrażenie dla każdego wiersza.

Przykład:

Sprzedaż Netto = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

Ta miara nie sumuje jednej kolumny. Zamiast tego dla każdego wiersza tabeli Sales wylicza Quantity * UnitPrice, a następnie sumuje wszystkie wyniki.

SUM czy SUMX? Najważniejsza różnica

W praktyce decyzja często sprowadza się do jednego pytania: czy wynik już istnieje w kolumnie, czy trzeba go dopiero obliczyć?

Typowe zastosowania w codziennej analizie

Agregacje sprawdzają się w raportach, gdy potrzebujesz szybko pokazać:

• łączną sprzedaż,
• średnią wartość zamówienia z gotowej kolumny,
• maksymalny koszt,
• liczbę rekordów lub transakcji.

Iteratory są przydatne, gdy analizujesz:

• sprzedaż liczona jako iloczyn ilości i ceny,
• marżę liczona na poziomie pojedynczego wiersza,
• średnią ważoną,
• wskaźniki wymagające własnego wzoru dla każdego rekordu.

Przykład praktyczny: średnia prosta a średnia liczona z wyrażenia

Różnica między AVERAGE i AVERAGEX dobrze pokazuje, że podobnie brzmiące funkcje nie zawsze dają ten sam rezultat.

Średnia Marża = AVERAGE(Sales[MarginPercent])

Ta miara liczy średnią z wartości zapisanych w kolumnie MarginPercent.

Średnia Wartość Pozycji = AVERAGEX(Sales, Sales[Quantity] * Sales[UnitPrice])

Tu średnia liczona jest nie z kolumny, ale z wyrażenia wyliczanego osobno dla każdego rekordu. To zupełnie inny mechanizm i często inny wynik biznesowy.

Na co zwracać uwagę przy wyborze funkcji

• Zaczynaj od prostszej funkcji – jeśli wystarczy SUM, nie ma potrzeby od razu używać SUMX.
• Sięgaj po iterator, gdy logika obliczenia zależy od pojedynczego wiersza.
• Dbaj o czytelność miar – zbyt rozbudowane wyrażenia warto dzielić na prostsze elementy.
• Pamiętaj o znaczeniu modelu danych – nawet poprawna funkcja może dać mylący wynik, jeśli dane wejściowe nie są przygotowane właściwie.

Dla użytkownika średniozaawansowanego to jedna z kluczowych kompetencji w DAX: rozpoznać, kiedy wystarczy zwykła agregacja, a kiedy potrzebne jest liczenie „po wierszach”. Właśnie ta różnica bardzo często decyduje o poprawności miary i o tym, czy raport odpowiada na realne pytania biznesowe.

Analiza czasu (Time Intelligence): TOTALYTD, SAMEPERIODLASTYEAR, DATEADD i wymagania dot. tabeli dat

Analiza czasu w DAX pozwala szybko odpowiadać na bardzo typowe pytania biznesowe: ile wynosi wynik narastająco od początku roku, jak wygląda porównanie do analogicznego okresu rok wcześniej oraz jak przesunąć analizowany okres o miesiąc, kwartał lub rok. To właśnie tutaj najczęściej wykorzystuje się funkcje z grupy Time Intelligence, takie jak TOTALYTD, SAMEPERIODLASTYEAR i DATEADD.

Najważniejsze jest jednak to, że funkcje czasowe działają poprawnie tylko wtedy, gdy model danych ma dobrze przygotowaną tabelę dat. Bez niej nawet poprawnie zapisane formuły mogą zwracać niepełne albo mylące wyniki.

Do czego służą najczęściej używane funkcje czasowe

TOTALYTD – wynik narastająco od początku roku

TOTALYTD to jedna z najczęściej używanych funkcji w raportach zarządczych i operacyjnych. Jej zadaniem jest policzenie wartości od początku roku do aktualnie analizowanego dnia, miesiąca albo innego punktu na osi czasu.

Typowy przykład to sprzedaż narastająco od stycznia do bieżącego miesiąca. Dzięki temu użytkownik nie patrzy tylko na pojedynczy miesiąc, ale widzi także, jak wynik buduje się w trakcie całego roku.

Sprzedaż YTD =
TOTALYTD(
    [Sprzedaż],
    'Kalendarz'[Data]
)

W praktyce ta funkcja jest wygodna wtedy, gdy potrzebujesz klasycznego wskaźnika Year-To-Date i nie chcesz ręcznie budować logiki filtrowania dat.

SAMEPERIODLASTYEAR – porównanie do analogicznego okresu rok wcześniej

SAMEPERIODLASTYEAR zwraca zbiór dat odpowiadający temu samemu okresowi w poprzednim roku. To bardzo wygodne przy analizie typu rok do roku, ponieważ pozwala zestawić np. sprzedaż z marca bieżącego roku ze sprzedażą z marca roku poprzedniego.

Sprzedaż rok temu =
CALCULATE(
    [Sprzedaż],
    SAMEPERIODLASTYEAR('Kalendarz'[Data])
)

Ta funkcja sprawdza się szczególnie dobrze w raportach, gdzie użytkownik wybiera miesiące, kwartały lub zakresy dat i oczekuje prostego porównania z analogicznym okresem poprzedniego roku.

Warto pamiętać, że nie chodzi tu o „poprzednie 12 miesięcy”, tylko o ten sam okres przesunięty o jeden rok wstecz.

DATEADD – elastyczne przesuwanie okresu

DATEADD działa bardziej uniwersalnie niż SAMEPERIODLASTYEAR, bo pozwala przesuwać daty o wybraną liczbę dni, miesięcy, kwartałów lub lat. Dzięki temu można tworzyć porównania nie tylko rok do roku, ale również miesiąc do miesiąca czy kwartał do kwartału.

Sprzedaż miesiąc wcześniej =
CALCULATE(
    [Sprzedaż],
    DATEADD('Kalendarz'[Data], -1, MONTH)
)

To dobra opcja wtedy, gdy logika porównania ma być bardziej elastyczna. Jeśli celem jest klasyczne zestawienie z tym samym okresem rok wcześniej, SAMEPERIODLASTYEAR bywa prostsze i czytelniejsze. Jeśli jednak potrzebujesz różnych przesunięć czasu, DATEADD daje większą swobodę.

Podstawowe różnice między TOTALYTD, SAMEPERIODLASTYEAR i DATEADD

• TOTALYTD liczy wartość narastająco od początku roku.
• SAMEPERIODLASTYEAR służy do porównania z analogicznym okresem poprzedniego roku.
• DATEADD pozwala przesuwać okres o wskazaną liczbę jednostek czasu i jest bardziej uniwersalne.

Najprościej można to ująć tak: TOTALYTD odpowiada na pytanie „ile mamy od początku roku?”, SAMEPERIODLASTYEAR na pytanie „ile było w tym samym okresie rok temu?”, a DATEADD na pytanie „co się stanie, jeśli przesuniemy analizowany okres w czasie?”.

Dlaczego tabela dat jest obowiązkowa

Funkcje Time Intelligence opierają się na spójnej osi czasu. Dlatego model powinien zawierać osobną tabelę kalendarza, a nie tylko kolumnę dat w tabeli faktów. Tabela dat powinna być kompletna i obejmować wszystkie dni w analizowanym zakresie.

W praktyce dobra tabela dat powinna spełniać kilka podstawowych warunków:

• zawierać ciągły zakres dat, bez brakujących dni,
• mieć unikalną kolumnę daty,
• być oznaczona jako tabela dat w modelu,
• pozostawać w relacji z tabelami zawierającymi dane transakcyjne,
• zawierać przydatne atrybuty, np. rok, miesiąc, numer miesiąca, kwartał.

Jeśli w danych występują tylko dni sprzedażowe, a brakuje dni bez transakcji, analiza czasu może działać niepoprawnie. To jeden z najczęstszych powodów, dla których wynik YTD albo porównanie do poprzedniego roku wydaje się „dziwne”, mimo że formuła wygląda poprawnie.

Najczęstsze zastosowania w codziennej analizie

• sprzedaż narastająco od początku roku,
• porównanie bieżącego miesiąca do tego samego miesiąca rok wcześniej,
• analiza zmian miesiąc do miesiąca,
• porównanie wyników kwartalnych i rocznych,
• budowa prostych wskaźników dynamiki na bazie przesuniętych okresów.

W codziennym użyciu te funkcje są szczególnie wartościowe dlatego, że pozwalają szybko budować miary zrozumiałe dla odbiorcy biznesowego. Zamiast ręcznie filtrować zakresy dat, można odwołać się do gotowych mechanizmów DAX i uzyskać bardziej przewidywalne, powtarzalne wyniki.

Relacje i model: USERELATIONSHIP oraz praca z wieloma ścieżkami filtrowania

Na poziomie średniozaawansowanym DAX przestaje być tylko językiem do liczenia prostych miar, a zaczyna być narzędziem do świadomej pracy z modelem danych. W praktyce bardzo wiele wyników zależy nie tylko od samej formuły, ale od tego, jak filtry przechodzą między tabelami oraz która relacja jest aktywna w danym momencie.

To szczególnie ważne w raportach, gdzie jedna tabela faktów zawiera kilka dat, kilka identyfikatorów lub kilka możliwych powiązań z wymiarami. Typowy przykład to sytuacja, w której w jednej tabeli występuje zarówno data zamówienia, jak i data wysyłki. Model zwykle pozwala mieć tylko jedną aktywną relację między tymi samymi tabelami, a pozostałe pozostają nieaktywne. Właśnie wtedy pojawia się zastosowanie funkcji USERELATIONSHIP.

Aktywna i nieaktywna relacja – najważniejsza różnica

W modelu Power BI relacja aktywna jest używana automatycznie podczas filtrowania i obliczeń. Relacja nieaktywna istnieje w modelu, ale nie bierze udziału w liczeniu, dopóki nie zostanie jawnie wskazana w formule.

Dzięki temu można budować kilka miar opartych na tych samych danych, ale liczonych według różnych relacji, bez konieczności duplikowania tabel.

Do czego służy USERELATIONSHIP

USERELATIONSHIP pozwala tymczasowo uaktywnić wskazaną relację w obrębie konkretnego obliczenia. Najczęściej używa się jej wewnątrz CALCULATE, aby powiedzieć modelowi: „na potrzeby tej miary korzystaj z innego połączenia niż domyślne”.

Sprzedaż wg daty wysyłki =
CALCULATE(
    [Sprzedaż],
    USERELATIONSHIP('Kalendarz'[Data], 'Sprzedaż'[DataWysyłki])
)

Taka miara nie zmienia całego modelu. Zmienia jedynie sposób filtrowania w ramach jednego obliczenia. To bardzo praktyczne rozwiązanie, gdy użytkownik chce porównywać wyniki według różnych dat lub różnych ról tej samej tabeli wymiaru.

Kiedy warto użyć USERELATIONSHIP

• gdy tabela faktów ma kilka kolumn dat i każda odpowiada innemu etapowi procesu,
• gdy jedna tabela wymiaru może pełnić kilka ról,
• gdy nie chcemy przebudowywać modelu tylko po to, by policzyć alternatywną wersję tej samej miary,
• gdy potrzebna jest kontrola nad tym, która relacja ma działać w konkretnej analizie.

Największą zaletą tego podejścia jest zachowanie porządku w modelu. Zamiast tworzyć obejścia i dodatkowe kopie danych, można oprzeć logikę na miarach, które jasno pokazują intencję analityczną.

Wiele ścieżek filtrowania – skąd biorą się problemy

Drugim ważnym zagadnieniem jest praca z wieloma ścieżkami filtrowania. Problem pojawia się wtedy, gdy filtr może przejść z jednej tabeli do drugiej więcej niż jedną drogą. Taka sytuacja bywa niejednoznaczna i może prowadzić do błędów modelowania, nieoczekiwanych wyników albo trudnych do wyjaśnienia zależności między wizualizacjami.

Najczęstsze źródła takich sytuacji to:

• relacje dwukierunkowe użyte bez wyraźnej potrzeby,
• wiele tabel pośrednich łączących te same obszary modelu,
• łączenie faktów z faktami zamiast przez wspólne wymiary,
• kilka relacji opisujących podobny kontekst biznesowy.

W codziennej analizie warto myśleć o modelu tak, aby filtrowanie było możliwie jednokierunkowe i przewidywalne. Im mniej alternatywnych dróg dla filtra, tym łatwiej rozumieć wyniki i utrzymywać raport.

Praktyczne podejście do modelu

W większości przypadków najlepiej sprawdza się model, w którym tabele wymiarów filtrują tabele faktów, a nie odwrotnie. Pozwala to uniknąć nadmiernej złożoności. Jeśli potrzebna jest alternatywna logika, zwykle bezpieczniej wprowadzić ją w miarze, na przykład przez USERELATIONSHIP, niż rozszerzać model o kolejne aktywne zależności.

Na co uważać

• USERELATIONSHIP działa w miarach, ale nie „naprawia” źle zaprojektowanego modelu.
• Zbyt wiele relacji i ścieżek filtrowania utrudnia interpretację wyników.
• Relacje dwukierunkowe są przydatne tylko w wybranych scenariuszach; nadużywane często komplikują analizę.
• Jeżeli wynik miary wydaje się nielogiczny, problem może leżeć nie w formule, ale właśnie w modelu i kierunku propagacji filtrów.

Dla analityka średniozaawansowanego kluczowa jest świadomość, że DAX i model danych działają razem. Funkcja USERELATIONSHIP daje precyzyjną kontrolę nad alternatywną relacją, a umiejętność rozpoznawania wielu ścieżek filtrowania pomaga budować raporty stabilne, czytelne i łatwiejsze do rozwijania.

Filtrowanie i warunki: FILTER, ALL/ALLEXCEPT, IF, SWITCH oraz obsługa pustych wartości (BLANK/COALESCE)

W praktycznej pracy z DAX bardzo często nie wystarcza zwykłe sumowanie czy liczenie rekordów. Codzienna analiza danych wymaga także świadomego sterowania filtrowaniem, porównywania warunków i bezpiecznego reagowania na brak danych. To właśnie w tym obszarze szczególnie przydają się funkcje FILTER, ALL, ALLEXCEPT, IF, SWITCH, BLANK oraz COALESCE.

Ich znaczenie jest duże, ponieważ pozwalają budować miary bardziej odporne na zmiany kontekstu raportu. Dzięki nim można przygotować obliczenia, które pokazują wynik tylko dla wybranych przypadków, ignorują część filtrów, zachowują określony poziom agregacji albo zwracają czytelniejsze wartości wtedy, gdy dane są niepełne.

FILTER – gdy zwykły filtr to za mało

Funkcja FILTER służy do tworzenia warunkowego zbioru danych. Najprościej mówiąc, pozwala wskazać, które wiersze mają zostać uwzględnione w dalszym obliczeniu. Jest przydatna wtedy, gdy filtr ma być bardziej precyzyjny niż proste zaznaczenie wartości w raporcie.

Typowe zastosowania obejmują:

• ograniczenie obliczeń do rekordów spełniających konkretny warunek,
• analizę tylko wybranych typów transakcji, statusów lub zakresów wartości,
• budowanie miar, które działają według logiki biznesowej, a nie tylko według filtrów ustawionych przez użytkownika.

Warto pamiętać, że FILTER nie jest po prostu „ładniejszą wersją filtrowania”. Używa się go wtedy, gdy trzeba jawnie opisać warunek działania miary. W codziennej analizie szczególnie pomaga przy bardziej złożonych scenariuszach, w których wynik ma zależeć od kilku kryteriów jednocześnie.

ALL i ALLEXCEPT – kontrola nad kontekstem filtrowania

Jednym z częstszych zadań analitycznych jest pokazanie wyniku na tle całości, niezależnie od części filtrów ustawionych w raporcie. Tutaj ważną rolę odgrywa ALL, które usuwa filtry z wybranego zakresu danych. Dzięki temu można obliczyć na przykład udział procentowy kategorii w całkowitej sprzedaży albo porównać wynik bieżącego wyboru z pełnym zbiorem.

ALL stosuje się wtedy, gdy celem jest:

• zignorowanie filtrów dla całej tabeli lub wybranej kolumny,
• wyliczenie wartości odniesienia, takiej jak suma globalna,
• budowa wskaźników udziału, rankingu lub porównań do całości.

Z kolei ALLEXCEPT działa bardziej selektywnie. Pozwala usunąć większość filtrów, ale zachować te, które są kluczowe dla analizy. Jest to przydatne, gdy wynik ma być liczony na określonym poziomie szczegółowości, na przykład w obrębie jednej grupy, regionu czy segmentu, przy jednoczesnym pomijaniu pozostałych ograniczeń.

Najprostsza intuicja jest taka:

• ALL – usuń filtry, aby spojrzeć szerzej,
• ALLEXCEPT – usuń filtry, ale zostaw wybrane osie analizy.

To rozróżnienie ma duże znaczenie przy projektowaniu raportów menedżerskich, gdzie użytkownik oczekuje nie tylko wartości bieżącej, lecz także kontekstu porównawczego.

IF i SWITCH – logika warunkowa w miarach

W DAX bardzo często trzeba wprowadzić logikę typu „jeśli spełniony jest warunek, pokaż jedną wartość, w przeciwnym razie inną”. Do tego służy IF. To podstawowa funkcja warunkowa, wykorzystywana przy prostych decyzjach logicznych, na przykład do oznaczania przekroczenia progu, klasyfikowania wyników albo ukrywania wartości niespełniających kryteriów.

IF najlepiej sprawdza się wtedy, gdy:

• warunek jest prosty i jednoznaczny,
• logika ma dwa główne warianty,
• chcemy szybko sterować tym, co użytkownik zobaczy w wizualizacji.

Gdy warunków robi się więcej, czytelniejszym rozwiązaniem bywa SWITCH. Funkcja ta jest szczególnie wygodna przy wielu możliwych scenariuszach, na przykład przy przypisywaniu etykiet, poziomów oceny, przedziałów lub stanów biznesowych. Zamiast budować długie, zagnieżdżone konstrukcje warunkowe, można uporządkować logikę w bardziej przejrzysty sposób.

W praktyce można przyjąć prostą zasadę:

• IF – do prostych decyzji warunkowych,
• SWITCH – do wielu wariantów i bardziej uporządkowanej klasyfikacji.

Dobrze zaprojektowana logika warunkowa poprawia nie tylko poprawność obliczeń, ale też czytelność całego modelu i raportu.

BLANK i COALESCE – jak radzić sobie z pustymi wartościami

W raportach Power BI puste wartości są czymś naturalnym. Mogą wynikać z braku danych, niedopasowania relacji, niepełnego zakresu czasu albo z samej logiki miary. W DAX pusty wynik nie zawsze oznacza zero, dlatego warto odróżniać BLANK od wartości liczbowej.

BLANK oznacza brak wyniku. Czasem jest to pożądane, ponieważ pozwala nie pokazywać informacji tam, gdzie nie mają sensu. Dzięki temu wizualizacje są czystsze i mniej mylące. W wielu przypadkach lepiej zwrócić pustą wartość niż sztuczne zero, które mogłoby sugerować, że dane istnieją, ale ich wartość faktycznie wynosi zero.

Z drugiej strony w raportach biznesowych często potrzebna jest bardziej przyjazna prezentacja. Wtedy pomocna jest funkcja COALESCE, która pozwala zastąpić pusty wynik inną wartością, najczęściej zerem albo innym domyślnym rezultatem. To rozwiązanie poprawia odbiór raportu i ułatwia dalsze obliczenia lub interpretację wskaźników.

Najważniejsze praktyczne rozróżnienie wygląda tak:

• BLANK – świadomy brak wyniku,
• COALESCE – sposób na podmianę pustej wartości na bardziej użyteczną z punktu widzenia raportu.

Umiejętne używanie pustych wartości ma duże znaczenie dla jakości analizy. Pozwala uniknąć sytuacji, w których użytkownik błędnie interpretuje brak danych jako wynik równy zero.

Jak myśleć o tych funkcjach w codziennej pracy

W codziennych zastosowaniach te funkcje najlepiej traktować jako zestaw narzędzi do kontroli logiki analitycznej:

• FILTER – wybiera dane według określonych warunków,
• ALL – usuwa filtry, aby zbudować punkt odniesienia,
• ALLEXCEPT – zachowuje tylko wybrane filtry,
• IF – wprowadza prostą decyzję warunkową,
• SWITCH – porządkuje bardziej rozbudowaną logikę wyboru,
• BLANK – sygnalizuje brak wyniku,
• COALESCE – zamienia pustą wartość na wynik domyślny.

Na poziomie średniozaawansowanym kluczowe jest nie tyle zapamiętanie samych nazw funkcji, ile zrozumienie, po co są używane. Większość codziennych miar biznesowych opiera się właśnie na tym, że trzeba odpowiednio zawęzić dane, kontrolować wpływ filtrów, zastosować warunek i zdecydować, co pokazać wtedy, gdy danych brakuje. To jeden z najbardziej praktycznych obszarów DAX, ponieważ bezpośrednio wpływa na to, czy raport odpowiada na realne pytania użytkowników.

8. Biblioteka praktycznych miar, wydajność i domknięcie pracy z DAX

Na poziomie średniozaawansowanym największą różnicę robi nie znajomość pojedynczych funkcji, ale umiejętność budowania własnej, uporządkowanej biblioteki miar. W codziennej analizie danych oznacza to zestaw sprawdzonych obliczeń, które można wielokrotnie wykorzystywać w raportach, dashboardach i analizach ad hoc. Dobrze przygotowane miary przyspieszają pracę, ułatwiają utrzymanie modelu i zmniejszają ryzyko rozbieżności w interpretacji wyników.

Taka biblioteka nie musi być rozbudowana od początku. W praktyce najlepiej zacząć od kilkunastu najczęściej używanych obliczeń, które odpowiadają na codzienne pytania biznesowe: ile sprzedaliśmy, jaka była średnia wartość, jak wynik zmienia się w czasie, jaki jest udział w całości, jaki wynik uznajemy za poprawny po odfiltrowaniu braków lub wartości pustych. Poniżej znajduje się zestaw typów miar, które najczęściej stanowią rdzeń praktycznej pracy z DAX.

• Suma wartości – podstawowa miara do zliczania przychodu, kosztu, ilości lub marży. To najczęściej pierwszy punkt odniesienia dla dalszych analiz.
• Liczba rekordów – przydaje się do oceny skali danych, liczby transakcji, zamówień, zgłoszeń czy klientów występujących w danym zakresie.
• Liczba unikalnych elementów – używana wtedy, gdy istotna jest liczba różnych klientów, produktów, dokumentów lub kategorii, a nie liczba wszystkich wierszy.
• Średnia – pomaga ocenić przeciętną wartość zamówienia, średni koszt, średnią liczbę dni lub inne wielkości opisujące typowy poziom zjawiska.
• Minimum i maksimum – przydatne do wychwytywania skrajnych wartości, kontroli jakości danych i szybkiego sprawdzania zakresu analizowanej miary.
• Udział procentowy w całości – jedna z najczęściej używanych miar menedżerskich. Pozwala ocenić, jaki procent całości stanowi region, produkt, kanał sprzedaży lub segment klientów.
• Wynik narastająco – użyteczny przy analizie postępu miesiąc do miesiąca, realizacji planu, przychodów od początku roku lub kumulacji kosztów.
• Zmiana względem poprzedniego okresu – pokazuje dynamikę zmian i pomaga szybko ocenić, czy wynik rośnie, spada czy pozostaje stabilny.
• Odchylenie od planu lub budżetu – kluczowe w controllingu i raportowaniu zarządczym, bo pokazuje nie tylko wynik, ale też jego relację do celu.
• Marża lub wskaźnik rentowności – miary relacyjne są ważne tam, gdzie sama wartość bezwzględna nie wystarcza do oceny efektywności.
• Miara warunkowa – stosowana wtedy, gdy wynik ma być liczony tylko dla wybranych przypadków, na przykład aktywnych klientów, zamkniętych spraw lub danych spełniających określone kryteria.
• Miara z obsługą pustych wartości – bardzo praktyczna w codziennej pracy, ponieważ poprawia czytelność raportu i ogranicza błędne interpretacje wyników.

Warto zauważyć, że poszczególne miary różnią się nie tylko zastosowaniem, ale też sposobem myślenia o wyniku. Jedne odpowiadają na pytanie o wartość całkowitą, inne o relację, tempo zmiany, udział, średni poziom albo wynik po spełnieniu warunku. Na tym etapie ważniejsze od zaawansowanej składni jest rozpoznanie, który typ miary najlepiej odpowiada na konkretne pytanie biznesowe.

Dobrym nawykiem jest także standaryzacja miar. Oznacza to spójne nazewnictwo, logiczne grupowanie i unikanie tworzenia wielu niemal identycznych wersji tego samego obliczenia. Dzięki temu raport pozostaje czytelny, a model łatwiej rozwijać. W praktyce dobrze działa podejście, w którym najpierw powstają miary bazowe, a dopiero na nich buduje się miary pochodne, takie jak procent udziału, dynamika czy odchylenie od planu.

Drugim ważnym obszarem jest wydajność. Nawet poprawna miara może działać zbyt wolno, jeśli model danych jest zbyt ciężki albo obliczenia są budowane bez dbałości o prostotę. W codziennej pracy warto pamiętać o kilku zasadach, które zwykle dają szybki efekt.

• Twórz miary zamiast nadmiarowych kolumn obliczeniowych tam, gdzie wynik ma być liczony dynamicznie w kontekście raportu. Ogranicza to rozmiar modelu i ułatwia zarządzanie logiką.
• Upraszczaj logikę – jeśli da się osiągnąć ten sam wynik prostszym wyrażeniem, zazwyczaj warto wybrać prostsze rozwiązanie.
• Ograniczaj liczbę niepotrzebnych obliczeń – rozbudowane warunki, zagnieżdżenia i wielokrotne przeliczanie tych samych elementów mogą spowalniać raport.
• Dbaj o jakość modelu danych – dobrze zaprojektowane relacje i przejrzysta struktura modelu mają bezpośredni wpływ na szybkość działania miar.
• Pracuj na właściwym poziomie szczegółowości – nie każdy raport wymaga liczenia wszystkiego na najniższym możliwym poziomie danych.
• Eliminuj zbędne pola z modelu – im mniej nieużywanych kolumn i obiektów, tym łatwiej utrzymać wydajność i porządek.
• Sprawdzaj zachowanie miar w różnych filtrach – miara powinna być nie tylko szybka, ale też przewidywalna i spójna w różnych widokach raportu.
• Stosuj spójne miary bazowe – budowanie kolejnych wskaźników na tych samych fundamentach zmniejsza ryzyko błędów i przyspiesza rozwój modelu.

W praktyce efektywna praca z DAX to połączenie trzech elementów: zrozumienia logiki obliczeń, świadomego projektowania miar i dbałości o wydajność. Średniozaawansowany użytkownik nie musi znać każdej funkcji, aby tworzyć dobre analizy. Ważniejsze jest to, by wiedzieć, jak dobierać właściwe wzorce, jak nazywać i porządkować miary oraz jak sprawdzać, czy wynik rzeczywiście odpowiada na potrzebę biznesową.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Właśnie w tym obszarze wsparcie merytoryczne i praktyczne podejście mają największe znaczenie. Cognity pomaga opanować DAX w sposób nastawiony na realne zastosowania analityczne: od zrozumienia logiki miar, przez budowanie powtarzalnych wzorców, po rozwijanie umiejętności potrzebnych w codziennym raportowaniu i analizie danych. Dzięki temu DAX przestaje być zbiorem trudnych funkcji, a staje się narzędziem do szybszego i trafniejszego podejmowania decyzji na podstawie danych.

Prompt engineering w praktyce: jak pisać prompty, które dają powtarzalne wyniki 13 lipca 2026

cognity: Power BI średniozaawansowany – jak tworzyć zaawansowane modele danych i relacje między tabelami 11 lipca 2026