DAX w Power BI – 10 najważniejszych funkcji do tworzenia miar i zaawansowanych analiz

Wprowadzenie: po co DAX w Power BI i jak czytać przykłady miar

Suma sprzedaży odpowiada na pytanie „ile sprzedaliśmy?”, ale nie wystarcza, gdy chcesz sprawdzić udział produktu w przychodach, porównać wynik z poprzednim rokiem albo obliczyć średnią wartość zamówienia. Do takich obliczeń w Power BI służy DAX, czyli Data Analysis Expressions — język formuł działający na danych w modelu. Pozwala zapisać regułę biznesową raz, a następnie wykorzystywać ją na kartach, wykresach i w innych wizualizacjach.

W tym artykule skupiamy się na miarach DAX. Miara wyznacza wynik podczas korzystania z raportu, z uwzględnieniem między innymi wybranego okresu, kategorii produktu czy regionu. Dzięki temu ta sama definicja sprzedaży może pokazywać wartość dla całej firmy lub tylko dla wybranego segmentu. Nie trzeba tworzyć osobnego obliczenia dla każdego widoku danych.

Warto od razu rozdzielić trzy zadania. Power Query służy przede wszystkim do pobierania i przygotowywania danych, na przykład poprawiania typów czy łączenia źródeł. Kolumna obliczeniowa DAX wyznacza wartość dla poszczególnych wierszy i może służyć choćby do ich kategoryzacji. Miara odpowiada natomiast na pytanie analityczne w aktualnym widoku raportu. Wybór między nimi zależy więc od tego, czy przygotowujesz dane, opisujesz rekordy, czy obliczasz wskaźnik.

Przykłady miar najlepiej czytać od ich celu, nie od nazwy funkcji. Najpierw ustal, co ma oznaczać wynik: przychód, liczbę klientów, udział procentowy czy zmianę w czasie. Następnie sprawdź, z jakich danych korzysta obliczenie. Przed znakiem równości znajduje się nazwa miary, a za nim — jej definicja. Odwołanie do kolumny zwykle zawiera nazwę tabeli oraz nazwę kolumny w nawiasach kwadratowych. Odwołanie do innej miary zapisuje się w nawiasach kwadratowych, bez konieczności podawania tabeli.

Nazwy tabel, kolumn i miar w przykładach trzeba dopasować do własnego modelu. Równie ważne jest znaczenie danych: kwota netto nie jest tym samym co brutto, a pojedynczy wiersz sprzedaży nie zawsze oznacza całe zamówienie. Jeżeli przykład wykorzystuje wcześniej zdefiniowaną miarę, należy ją najpierw utworzyć. Zależnie od ustawień regionalnych edytor może też wymagać przecinków lub średników jako separatorów argumentów.

Poprawna składnia to dopiero początek. Każdą nową miarę warto sprawdzić na niewielkim, znanym fragmencie danych i porównać wynik z oczekiwaniem biznesowym. Taki sposób pracy pozwala korzystać z przykładów świadomie — jako wzorców obliczeń, a nie formuł do bezrefleksyjnego kopiowania.

Kontekst w DAX prostym językiem: kontekst filtra vs kontekst wiersza

Ta sama miara może pokazywać inną wartość na karcie, inną przy kategorii produktu, a jeszcze inną po wybraniu roku na fragmentatorze. Nie oznacza to, że zmienia się jej definicja. Zmienia się kontekst obliczenia, czyli warunki, w których DAX wyznacza wynik. Rozróżnienie kontekstu filtra i kontekstu wiersza pomaga zrozumieć, dlaczego poprawna formuła nie zawsze daje oczekiwaną liczbę. W Cognity często spotykamy się z pytaniami o wpływ kontekstu na wyniki miar podczas szkoleń, dlatego wyjaśniamy to również na blogu.

Kontekst filtra: które dane biorą udział w obliczeniu?

Kontekst filtra określa zakres danych dostępnych dla obliczenia. Tworzą go między innymi fragmentatory, filtry wizualizacji, strony i raportu oraz pola umieszczone na osiach wykresu czy w wierszach macierzy. Filtry mogą też docierać do innych tabel przez relacje w modelu.

Jeśli wybierzesz rok 2025, a w macierzy pokażesz sprzedaż według kategorii, miara przy każdej kategorii będzie obliczana dla przecięcia tych ograniczeń: wybranego roku i konkretnej kategorii. Warto więc pytać nie tylko „co liczy miara?”, lecz także „dla jakiego zestawu danych jest teraz liczona?”.

Kontekst wiersza: którego rekordu dotyczy obliczenie?

Kontekst wiersza wskazuje aktualnie przetwarzany rekord. Występuje przede wszystkim w kolumnach obliczeniowych oraz podczas działania iteratorów, które wykonują wyrażenie kolejno dla poszczególnych wierszy. Pozwala na przykład odczytać ilość i cenę z tej samej pozycji sprzedaży, aby obliczyć jej wartość.

Ważne rozróżnienie: kontekst wiersza sam w sobie nie filtruje tabeli do bieżącego rekordu. Udostępnia wartości tego rekordu, ale nie sprawia automatycznie, że każda agregacja zostanie ograniczona do niego. Również wiersz widoczny w macierzy nie jest kontekstem wiersza w rozumieniu DAX — kategoria wyświetlana w takim wierszu tworzy kontekst filtra dla miary.

Przejście kontekstu: kiedy bieżący wiersz staje się filtrem?

Przejście kontekstu polega na przekształceniu kontekstu wiersza w kontekst filtra. Dzięki temu wartości identyfikujące aktualnie przetwarzany wiersz mogą ograniczyć dane używane przez obliczenie. Takie przejście zachodzi przy użyciu CALCULATE w istniejącym kontekście wiersza. Następuje też automatycznie, gdy w tym kontekście wywołujesz miarę modelu.

Na tym etapie wystarczy zapamiętać trzy pytania diagnostyczne: jakie filtry obowiązują, czy obliczenie przetwarza aktualnie konkretny wiersz i czy nastąpiło przejście kontekstu? To pozwala trafniej szukać przyczyny nieoczekiwanego wyniku, zamiast od razu zmieniać samą formułę.

Funkcje do modyfikacji kontekstu filtrów: CALCULATE, FILTER, ALL/REMOVEFILTERS, VALUES

Ta sama miara sprzedaży może pokazywać wynik dla wybranej kategorii, wszystkich kategorii albo tylko produktów spełniających określony warunek. Nie trzeba za każdym razem od nowa definiować obliczenia. W DAX można zmienić zestaw filtrów, w którym jest ono wykonywane. Służy do tego przede wszystkim CALCULATE, a pozostałe omawiane funkcje pomagają wskazać, które ograniczenia zastosować, usunąć lub uwzględnić.

W przykładach przyjmujemy, że istnieje już miara [Sprzedaż], a tabela 'Produkt' jest połączona z danymi sprzedażowymi aktywną relacją umożliwiającą ich filtrowanie.

CALCULATE — oblicz miarę po zmianie filtrów

CALCULATE oblicza wyrażenie w zmodyfikowanym kontekście filtra. Pierwszym argumentem jest obliczenie, na przykład istniejąca miara, a kolejnymi — warunki lub instrukcje zmieniające filtry.

Sprzedaż czerwonych produktów =
CALCULATE(
    [Sprzedaż],
    'Produkt'[Kolor] = "Czerwony"
)

Ta miara wyznacza sprzedaż czerwonych produktów, zachowując pozostałe ograniczenia raportu, na przykład wybrany okres czy region. Istotna jest jednak zasada: warunek przekazany do CALCULATE domyślnie zastępuje istniejący filtr na tej samej kolumnie. Jeśli fragmentator koloru wskazuje niebieski, powyższa miara nadal obliczy wynik dla czerwonego. Gdy potrzebne jest przecięcie nowego warunku z dotychczasowym wyborem, można użyć KEEPFILTERS.

FILTER — wybierz elementy spełniające warunek

FILTER przyjmuje tabelę, sprawdza warunek dla każdego jej wiersza i zwraca tabelę zawierającą wyłącznie pasujące wiersze. Sam nie oblicza sumy ani nie zmienia wyniku istniejącej miary. Dopiero wykorzystanie zwróconej tabeli jako argumentu CALCULATE pozwala zastosować ją do filtrowania obliczenia.

Funkcja przydaje się szczególnie wtedy, gdy kwalifikacja elementu zależy od wyniku miary, a nie tylko od wartości zapisanej w kolumnie. Przykładem jest sprzedaż produktów, z których każdy osiągnął wynik powyżej 10 000 w aktualnie analizowanych warunkach:

Sprzedaż produktów powyżej progu =
CALCULATE(
    [Sprzedaż],
    FILTER(
        VALUES('Produkt'[ProduktID]),
        [Sprzedaż] > 10000
    )
)

Warunek jest tutaj oceniany osobno dla każdego identyfikatora produktu. Po wyborze miesiąca próg odnosi się więc do sprzedaży w tym miesiącu, a nie automatycznie do całej historii. Funkcja VALUES dostarcza listę identyfikatorów do sprawdzenia.

Przy prostym warunku, takim jak konkretny kolor, zwykle lepiej przekazać porównanie bezpośrednio do CALCULATE. Nie warto filtrować całej tabeli transakcji, jeśli wystarczy warunek na jednej kolumnie lub niewielka lista produktów — rozwiązanie będzie czytelniejsze i często wydajniejsze.

ALL i REMOVEFILTERS — usuń wybrane ograniczenia

Obie funkcje mogą usuwać filtry wewnątrz CALCULATE. REMOVEFILTERS wyraża ten zamiar wprost, natomiast ALL ma również zastosowanie jako funkcja zwracająca tabelę. REMOVEFILTERS nie zwraca tabeli do dalszego przetwarzania.

Sprzedaż bez filtra kategorii =
CALCULATE(
    [Sprzedaż],
    REMOVEFILTERS('Produkt'[Kategoria])
)

Miara ignoruje filtr na kolumnie kategorii, ale nadal uwzględnia pozostałe ograniczenia, na przykład datę, region czy kolor produktu. W tym miejscu użycie ALL('Produkt'[Kategoria]) da taki sam efekt.

Takie obliczenie może stanowić punkt odniesienia przy analizie udziału kategorii w sprzedaży. Trzeba jednak precyzyjnie określić zakres usuwanych filtrów: usunięcie filtra z jednej kolumny nie oznacza usunięcia wszystkich filtrów dotyczących produktów. Jeśli raport ogranicza również markę, wynik nadal będzie dotyczył tej marki.

VALUES — pobierz unikalne wartości widoczne w bieżącym wyborze

Dla argumentu będącego kolumną VALUES zwraca jednokolumnową tabelę jej unikalnych wartości, uwzględniając aktualne filtry. Nie usuwa ich samodzielnie i nie zwraca pojedynczej wartości tylko dlatego, że często używa się jej w definicjach miar.

W przykładzie z progiem sprzedaży VALUES('Produkt'[ProduktID]) ogranicza sprawdzanie do produktów dostępnych w bieżącym kontekście. To podstawowa różnica względem ALL: VALUES zachowuje aktualny wybór, a ALL może go znieść dla wskazanej kolumny lub tabeli. Wybór między nimi powinien wynikać z pytania biznesowego: czy analizujemy elementy objęte filtrami użytkownika, czy potrzebujemy szerszego zbioru odniesienia?

Agregacje i iteratory: DISTINCTCOUNT, SUMX — kiedy miara, a kiedy kolumna?

Liczba wierszy w tabeli sprzedaży nie musi oznaczać liczby zamówień, a pomnożenie sumy ilości przez sumę cen nie daje wartości sprzedaży. Dlatego przed napisaniem miary warto ustalić, co dokładnie ma być liczone i na jakim poziomie: unikalne identyfikatory, wartości z gotowej kolumny czy wyniki obliczeń wykonanych osobno dla każdego wiersza.

DISTINCTCOUNT — licz unikalne wartości, nie rekordy

Funkcja DISTINCTCOUNT zlicza różne wartości we wskazanej kolumnie. Przydaje się do obliczania liczby klientów, zamówień lub sprzedanych produktów, gdy ten sam identyfikator występuje w wielu rekordach. Jeśli każde zamówienie zajmuje kilka wierszy — po jednym na pozycję — zwykłe zliczenie rekordów zawyży liczbę zamówień.

Przyjmijmy, że tabela Sprzedaz zawiera pozycje zamówień, a kolumna IDZamowienia identyfikuje zamówienie. Miara może wyglądać tak:

Liczba zamówień = DISTINCTCOUNT('Sprzedaz'[IDZamowienia])

Wynik uwzględni filtry raportu, na przykład wybrany miesiąc lub kategorię produktu. Trzeba jednak pamiętać, że liczby unikalnych wartości nie są addytywne. Zamówienie obejmujące produkty z dwóch kategorii zostanie policzone w każdej z nich, lecz w wyniku łącznym tylko raz. Suma końcowa w tabeli Power BI może więc różnić się od sumy widocznych wierszy — i nie jest to błąd.

Warto również sprawdzić kompletność identyfikatorów: DISTINCTCOUNT traktuje pustą wartość BLANK jako jedną z odrębnych wartości.

SUMX — najpierw oblicz wartość wiersza, potem zsumuj

SUMX jest iteratorem: przechodzi przez wiersze wskazanej tabeli, oblicza dla każdego podane wyrażenie, a następnie sumuje wyniki. To właściwy wybór, gdy agregacja wymaga wcześniejszego działania, na przykład pomnożenia ilości przez cenę jednostkową.

Wartość sprzedaży =
SUMX(
    'Sprzedaz',
    'Sprzedaz'[Ilosc] * 'Sprzedaz'[CenaJednostkowa]
)

Dla pozycji „2 sztuki po 50 zł” oraz „3 sztuki po 20 zł” miara zwróci 160 zł. Najpierw obliczy 100 zł i 60 zł, a dopiero potem je doda. Mnożenie sum kolumn dałoby 5 × 70 zł, czyli nieprawidłowe 350 zł.

Jeżeli tabela zawiera już poprawnie wyliczoną wartość każdej pozycji, wystarczy zwykłe SUM tej kolumny. SUMX warto stosować wtedy, gdy rzeczywiście potrzebne jest obliczenie wyrażenia dla poszczególnych wierszy, a nie jako domyślny zamiennik sumowania.

Miara czy kolumna obliczeniowa?

O wyborze decyduje przeznaczenie wyniku, nie sama funkcja. W Cognity omawiamy wybór między miarą a kolumną obliczeniową zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.

Miara sprawdza się przy wskaźnikach prezentowanych na kartach, wykresach i w tabelach, które mają reagować na wybór użytkownika. Oba powyższe przykłady najlepiej zapisać właśnie jako miary.

Kolumna obliczeniowa ma sens, gdy potrzebujesz wartości przypisanej do każdego rekordu, na przykład kategorii wartości pozycji używanej na osi wykresu lub w fragmentatorze. W modelu importowanym jej wyniki są zapisywane w modelu i przeliczane podczas odświeżania; nie zmieniają się pod wpływem kliknięcia fragmentatora.

Jeśli iloczyn ilości i ceny służy wyłącznie do obliczenia łącznej sprzedaży, miara z SUMX pozwala uniknąć dodatkowej przechowywanej kolumny. Jeśli wynik na poziomie rekordu ma być dalej wykorzystywany do grupowania lub filtrowania danych, warto rozważyć kolumnę. Nie twórz jej jednak tylko po to, by natychmiast zsumować wartości — zwiększa to rozmiar modelu, choć nie zawsze daje korzyść analityczną.

Relacje i praca między tabelami: RELATED i RELATEDTABLE

W modelu Power BI dane potrzebne do obliczenia często znajdują się w różnych tabelach. Tabela Sprzedaz może przechowywać pozycje sprzedaży i identyfikatory produktów, a tabela Produkty — ich nazwy, kategorie oraz inne cechy. RELATED i RELATEDTABLE pozwalają wykorzystać istniejące relacje, zamiast ręcznie wyszukiwać dopasowania po identyfikatorach. Nie tworzą jednak relacji ani nie naprawiają błędów w modelu.

RELATED — jedna wartość z powiązanej tabeli

RELATED pobiera pojedynczą wartość z powiązanego wiersza, najczęściej ze strony „jeden” relacji jeden-do-wielu. Załóżmy, że Produkty[ProduktID] zawiera unikalne identyfikatory i jest połączone aktywną relacją z Sprzedaz[ProduktID]. Dla każdej pozycji sprzedaży można wtedy odczytać kategorię odpowiadającego jej produktu.

Przykładowa kolumna obliczeniowa w tabeli Sprzedaz:

Kategoria produktu = RELATED(Produkty[Kategoria])

Funkcja potrzebuje kontekstu wiersza: musi wiedzieć, dla której pozycji ma odnaleźć produkt. Dlatego działa w kolumnie obliczeniowej, a w mierze można jej użyć na przykład wewnątrz iteratora przetwarzającego kolejne wiersze. Samo wpisanie RELATED(Produkty[Kategoria]) jako definicji miary nie zapewnia takiego kontekstu.

Ten przykład pokazuje mechanizm, ale do grupowania sprzedaży według kategorii zwykle nie trzeba kopiować kategorii do tabeli sprzedaży. Lepiej użyć bezpośrednio pola z tabeli Produkty. RELATED jest szczególnie przydatne wtedy, gdy cecha z innej tabeli stanowi składnik obliczenia wykonywanego dla konkretnego wiersza.

RELATEDTABLE — zbiór powiązanych wierszy

RELATEDTABLE zwraca tabelę, a nie pojedynczą wartość. Typowe zastosowanie to przejście od jednego produktu do wielu powiązanych pozycji sprzedaży. Otrzymany zbiór można następnie policzyć lub wykorzystać w dalszym obliczeniu.

Przykładowa kolumna obliczeniowa w tabeli Produkty:

Liczba pozycji sprzedaży = COUNTROWS(RELATEDTABLE(Sprzedaz))

Dla każdego produktu formuła liczy odpowiadające mu wiersze tabeli Sprzedaz. To liczba pozycji, niekoniecznie liczba zamówień — jedno zamówienie może obejmować kilka wierszy. Jako kolumna obliczeniowa wynik jest wyznaczany podczas przeliczania modelu i nie reaguje na fragmentatory raportu. Jeśli licznik ma zmieniać się po wyborze daty czy regionu, właściwym rozwiązaniem będzie miara. Przy poprawnej relacji zwykłe zliczenie wierszy sprzedaży często wystarczy, ponieważ filtr produktu dotrze do tej tabeli automatycznie.

Jak relacje wpływają na wynik?

Poprawna składnia DAX nie gwarantuje poprawnej analizy. Przed użyciem obu funkcji sprawdź przede wszystkim:

• Kardynalność i unikalność klucza. W opisanym układzie każdy identyfikator w tabeli Produkty musi wskazywać jeden produkt. Relacja wiele-do-wielu nie jest prostym zamiennikiem takiego modelu.
• Aktywność relacji. Nieaktywne połączenie nie zacznie uczestniczyć w obliczeniu tylko dlatego, że użyjesz RELATED lub RELATEDTABLE.
• Kierunek filtrowania. W typowym modelu filtr przechodzi od produktów do sprzedaży. To pozwala kategorii produktu ograniczać wyniki miar sprzedażowych. Pobieranie cechy produktu przez RELATED nie wymaga włączenia filtrowania dwukierunkowego.
• Kompletność dopasowań. Jeśli identyfikator ze sprzedaży nie ma odpowiednika w tabeli produktów, RELATED może zwrócić pustą wartość. W raportach takie pozycje mogą pojawić się pod pustą kategorią, mimo że nadal zwiększają łączną sprzedaż.

Najprostsze rozróżnienie brzmi: RELATED służy do pobrania cechy powiązanego rekordu, a RELATEDTABLE — do pracy na zbiorze powiązanych rekordów. W obu przypadkach punktem wyjścia jest poprawnie zaprojektowana relacja, nie sama formuła.

Inteligencja czasowa: DATEADD i SAMEPERIODLASTYEAR

Porównanie sprzedaży z poprzednim miesiącem lub analogicznym okresem ubiegłego roku wymaga czegoś więcej niż odjęcia dwóch wartości. Trzeba jeszcze wskazać właściwy zakres dat. W DAX służą do tego m.in. DATEADD i SAMEPERIODLASTYEAR. Obie funkcje pozwalają tworzyć miary porównawcze, które reagują na wybór okresu w raporcie — bez wpisywania konkretnych miesięcy czy lat do formuły.

Tabela dat — warunek poprawnych porównań

Poniższe przykłady korzystają z klasycznej inteligencji czasowej, w której argumentem funkcji jest kolumna dat. Przygotuj osobną tabelę kalendarza, np. 'Kalendarz', zamiast opierać obliczenia bezpośrednio na datach transakcji. W tabeli sprzedaży ten sam dzień może występować wielokrotnie, a dni bez sprzedaży mogą w ogóle nie występować.

Aby taki kalendarz prawidłowo obsługiwał analizę czasu:

• Kolumna dat musi zawierać unikatowe wartości, bez pustych pozycji i bez luk — po jednym wierszu dla każdego kolejnego dnia. Najprościej użyć typu danych Data.
• Kalendarz powinien obejmować pełne lata oraz okresy potrzebne do porównań, w tym poprzedni rok.
• W Power BI należy oznaczyć go jako tabelę dat, wskazując właściwą kolumnę.
• Potrzebna jest aktywna relacja jeden do wielu między kalendarzem a analizowaną datą w tabeli faktów, np. datą sprzedaży. Filtry kalendarza muszą docierać do danych sprzedażowych.

Na osiach wykresów i w fragmentatorach używaj pól z kalendarza, takich jak rok, miesiąc i data. Jeżeli dane transakcyjne zawierają godzinę, do relacji z kalendarzem przygotuj kolumnę zawierającą samą datę — wartości z godziną inną niż północ nie dopasują się do dat dziennych.

DATEADD — przesunięcie okresu o wybrany interwał

DATEADD przesuwa daty z bieżącego kontekstu o wskazaną liczbę dni, miesięcy, kwartałów lub lat. Ujemna liczba oznacza przesunięcie wstecz, dodatnia — w przyszłość. To elastyczne rozwiązanie do porównań miesiąc do miesiąca, kwartał do kwartału i rok do roku.

Zakładając, że masz już miarę [Wartość sprzedaży], porównawczą wartość dla okresu przesuniętego o miesiąc wstecz obliczysz tak:

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

Funkcja nie oznacza automatycznie „całego poprzedniego miesiąca”. Przesuwa zakres wynikający z aktualnego wyboru dat. Gdy analizujesz fragment miesiąca, porównanie również dotyczy przesuniętego zakresu, z uwzględnieniem reguł dopasowania dat. Przy użyciu kolumny dat nieciągły wybór okresów może spowodować błąd DATEADD.

SAMEPERIODLASTYEAR — porównanie z ubiegłym rokiem

SAMEPERIODLASTYEAR ma węższe zastosowanie: zwraca daty odpowiadające bieżącemu okresowi rok wcześniej. Jest czytelnym wyborem do standardowych analiz rok do roku, np. porównywania sprzedaży w tych samych miesiącach kolejnych lat.

Sprzedaż rok wcześniej =
CALCULATE(
    [Wartość sprzedaży],
    SAMEPERIODLASTYEAR('Kalendarz'[Data])
)

W tym wariancie pracy z kolumną dat odpowiada przesunięciu DATEADD('Kalendarz'[Data], -1, YEAR). Wybierz SAMEPERIODLASTYEAR, gdy chcesz jasno wyrazić porównanie roczne; DATEADD — gdy potrzebujesz innego interwału lub liczby okresów.

Obie funkcje zwracają zestaw dat, a nie kwotę ani procent zmiany. Dopiero użycie go w CALCULATE pozwala obliczyć miarę dla przesuniętego okresu. Pamiętaj też, że pełny kalendarz nie gwarantuje kompletności danych: jeśli bieżący miesiąc jest jeszcze niezamknięty, porównanie jego części z pełnym miesiącem ubiegłego roku może prowadzić do mylących wniosków.

Bezpieczne miary i obsługa braków: DIVIDE oraz COALESCE

Marża procentowa, średnia wartość zamówienia czy realizacja celu wymagają ustalenia, co ma pokazać raport, gdy brakuje danych lub mianownik wynosi zero. DIVIDE zabezpiecza dzielenie, a COALESCE pozwala wskazać wartość zastępującą pusty wynik. Funkcje te rozwiązują różne problemy, dlatego warto stosować je świadomie, zamiast automatycznie zamieniać każdy brak na zero.

DIVIDE — dzielenie z kontrolą mianownika

DIVIDE dzieli licznik przez mianownik, a gdy mianownik jest zerem lub wartością pustą, zwraca wynik alternatywny. Domyślnie jest nim BLANK, czyli wartość pusta w DAX. Można również wskazać stałą wartość zastępczą, na przykład zero. To wygodniejsze i czytelniejsze niż samodzielne sprawdzanie mianownika przy każdym obliczeniu wskaźnika.

Funkcja sprawdza się szczególnie wtedy, gdy mianownik zależy od wyborów użytkownika raportu. Po ograniczeniu danych do wybranego produktu lub miesiąca przychód, liczba zamówień albo wartość celu mogą wynosić zero. DIVIDE pozwala obsłużyć taką sytuację bez prezentowania nieskończoności lub niepoprawnego wyniku dzielenia. Nie rozstrzyga jednak, czy biznesowo właściwą odpowiedzią jest zero, czy brak wartości.

Przykładowo marża procentowa przy zerowym przychodzie zwykle powinna pozostać pusta. Wyświetlenie 0% sugerowałoby, że wskaźnik został poprawnie wyliczony i rzeczywiście wyniósł zero. Podobnie brak zdefiniowanego celu sprzedażowego nie musi oznaczać zerowej realizacji celu.

COALESCE — wartość zastępcza dla pustego wyniku

COALESCE zwraca pierwszą ze wskazanych wartości, która nie jest BLANK. Najczęściej służy do zastąpienia pustego wyniku miary zerem, ale może również wybierać między kilkoma wynikami według ustalonej kolejności. Nie zabezpiecza samego dzielenia i nie jest ogólną funkcją obsługi błędów. Reaguje na wartość pustą; istniejące zero pozostawia bez zmian.

Typowym zastosowaniem jest karta pokazująca liczbę zarejestrowanych zgłoszeń. Jeżeli brak rekordów rzeczywiście oznacza brak zgłoszeń, zero będzie czytelniejsze niż pusty element. Inaczej należy potraktować sytuację, w której dane nie zostały jeszcze załadowane — zastąpienie braku zerem mogłoby sugerować, że pomiar jest kompletny.

Kiedy łączyć DIVIDE i COALESCE?

Obie funkcje można połączyć, gdy trzeba najpierw bezpiecznie obliczyć iloraz, a następnie zastąpić jego pusty wynik. Nie zawsze jest to konieczne: jeśli chodzi wyłącznie o zerowy lub pusty mianownik, wystarczy odpowiedni wynik alternatywny w DIVIDE. COALESCE przydaje się wtedy, gdy wartość zastępcza ma dotyczyć pustego wyniku całej miary, niezależnie od przyczyny jego powstania.

Przed zamianą BLANK na zero warto też sprawdzić wizualizacje. Tabele i macierze zwykle pomijają grupy, dla których wszystkie miary są puste; po wprowadzeniu zer mogą pokazać więcej pozycji. Najważniejsza pozostaje jednak interpretacja: zero oznacza konkretny wynik, a brak wartości może oznaczać brak danych lub brak możliwości obliczenia wskaźnika.

Typowe błędy i optymalizacja DAX: relacje, kontekst, kolumny i wydajność

Nieprawidłowy wynik miary nie zawsze oznacza błąd w formule. Przyczyną może być relacja, która nie przenosi filtra, nieunikalny klucz albo obliczenie wykonywane na innym poziomie szczegółowości, niż zakładasz. Zanim rozbudujesz wyrażenie DAX, sprawdź model i warunki, w których miara jest obliczana. To często pozwala uniknąć skomplikowanych formuł, które jedynie maskują źródło problemu.

Złe relacje: najpierw sprawdź drogę filtra

Jeżeli wybór kategorii lub klienta nie zmienia wyniku, sprawdź, czy między odpowiednimi tabelami istnieje aktywna relacja i czy jej kierunek umożliwia propagację filtra. Zweryfikuj również unikalność klucza po stronie „jeden”, zgodność typów danych oraz obecność kluczy z tabeli faktów w tabeli wymiaru. Brak dopasowania może powodować pojawienie się pustej kategorii na wizualizacji.

Nie ustawiaj relacji dwukierunkowych ani wiele-do-wielu wyłącznie po to, żeby wynik zaczął wyglądać poprawnie. Takie rozwiązania bywają uzasadnione, ale mogą wprowadzać niejednoznaczne ścieżki filtrowania i utrudniać diagnostykę. W typowym modelu analitycznym czytelnym punktem wyjścia jest schemat gwiazdy z wymiarami filtrującymi tabelę faktów.

Niepoprawny kontekst: testuj wynik, nie tylko składnię

Formuła zaakceptowana przez edytor może nadal odpowiadać na inne pytanie biznesowe niż zamierzone. Testuj miarę na niewielkim, znanym wycinku danych: dla jednego produktu, jednego okresu i kilku transakcji. Następnie dodawaj filtry pojedynczo. Łatwiej wtedy ustalić, który wybór zmienia wynik w nieoczekiwany sposób.

Suma końcowa w wizualizacji nie musi być sumą widocznych wierszy. Power BI oblicza miarę ponownie w kontekście tej sumy. Ma to znaczenie zwłaszcza przy procentach, średnich i liczbie unikalnych klientów. Zanim uznasz taki wynik za błąd, ustal, czy oczekujesz ponownego obliczenia wskaźnika dla całości, czy rzeczywistego dodania wyników poszczególnych pozycji. W Cognity łączymy teorię z praktyką – dlatego te zagadnienia rozwijamy także w formie ćwiczeń na szkoleniach.

Kolumna zamiast miary: koszt niewłaściwego wyboru

Jeżeli wynik ma reagować na fragmentatory i filtry raportu, zwykle potrzebujesz miary. Kolumna obliczeniowa sprawdza się natomiast wtedy, gdy potrzebna jest wartość przypisana do każdego wiersza, na przykład kategoria używana do grupowania. W modelu importowanym jej wartości są przechowywane w modelu i przeliczane podczas przetwarzania danych, a nie po kliknięciu fragmentatora.

Tworzenie wielu kolumn „na zapas” zwiększa rozmiar modelu i może wydłużać odświeżanie. Z kolei miary nie przechowują wyników dla każdego wiersza, lecz wymagają obliczeń podczas obsługi zapytań. Wybór powinien wynikać z zastosowania, nie z założenia, że jedno rozwiązanie zawsze jest szybsze.

Wydajność: mierz przed zmianą formuły

Zacznij od Analizatora wydajności w Power BI. Pozwala on wskazać wolne wizualizacje i rozróżnić czas zapytania od czasu renderowania. Dopiero potem optymalizuj konkretną miarę lub model.

• Ogranicz zbędną iterację. Jeśli wystarcza zwykła agregacja kolumny, nie zastępuj jej obliczeniem wykonywanym osobno dla każdego wiersza.
• Przetwarzaj tylko potrzebne dane. Usuwaj nieużywane kolumny i analizuj zasadność przechowywania pól o dużej liczbie unikalnych wartości.
• Unikaj powielania złożonych wyrażeń. Zmienne poprawiają czytelność i mogą ograniczyć ponowne obliczenia, ale nie gwarantują przyspieszenia każdej miary.
• Porównuj w tych samych warunkach. Zachowaj identyczne filtry i zakres danych, uwzględnij wpływ pamięci podręcznej, a po każdej zmianie sprawdź zarówno czas wykonania, jak i poprawność wyniku.

Minitab a Excel – które narzędzie lepiej sprawdzi się w analizie jakości? 17 października 2026

Claude vs ChatGPT vs Microsoft Copilot – które AI wybrać do firmy? 15 października 2026