Model semantyczny i miary DAX z AI: najpierw kontekst

„Napisz mi marżę w DAX” wygląda jak wygodne zlecenie dla AI. Zanim jednak zajmę się formułą, potrzebuję ustalić, co oznaczają kwoty w tabeli, jak połączono dane i jakie filtry ma uwzględniać wynik. Bez tego nawet krótka miara pozostawia najważniejsze decyzje poza rozmową.

Zaczynam od opisu modelu semantycznego Power BI, czyli tabel, relacji i obliczeń używanych przez raport. Następnie zapisuję definicję miary i dopiero z takim kontekstem proszę AI o DAX. W piątym tygodniu Analizy z AI łączymy właśnie te elementy: model, obliczenia oraz kontrolę jakości.

Przejdźmy przez przykład sprzedaży, w którym przygotowuję przychód, koszt, marżę procentową i udział przychodu. Formuły opieram na dokumentacji Microsoft Learn; ich odbiór w Twoim raporcie wymaga zgodności z opisanym modelem.

Opisz znaczenie jednego wiersza

Przyjmuję, że tabela Sprzedaz zawiera pozycje opłaconych zamówień. Każdy wiersz oznacza jedną pozycję, a KwotaNetto i Koszt są kwotami całej pozycji po uwzględnieniu liczby sztuk. W tym przykładzie wszystkie kwoty zapisujemy w jednej walucie, a zwroty rozpatrujemy poza zakresem ćwiczenia.

Ten opis rozstrzyga, co można sumować. Jeżeli w rzeczywistym źródle masz cenę jednostkową, potrzebujesz innej definicji obliczenia. Jeżeli kwota całego zamówienia powtarza się przy każdej pozycji, najpierw porządkujesz strukturę danych. Sama nazwa kolumny „sprzedaż” nie wystarcza do wyboru formuły.

W zaleceniach Microsoftu dotyczących schematu gwiazdy tabela faktów przechowuje zdarzenia lub obserwacje, a wymiary służą do filtrowania i grupowania. Dla naszego przypadku wybieram tabelę sprzedaży oraz osobne tabele produktów i dat. Dzięki temu opisuję oddzielnie wartości do podsumowania i cechy, według których oglądam wynik.

Ustal relacje przed tworzeniem miar

W tabeli Produkty jeden wiersz opisuje jeden produkt. ProduktID jest unikalnym kluczem. W Kalendarz jeden wiersz opisuje dzień, a Data jest unikalna. W sprzedaży identyfikatory produktów i daty powtarzają się przy kolejnych pozycjach zamówień.

Ustawiam dwie aktywne relacje: Produkty[ProduktID] do Sprzedaz[ProduktID] oraz Kalendarz[Data] do Sprzedaz[Data]. Obie mają kardynalność jeden do wielu i pojedynczy kierunek filtrowania od wymiaru do sprzedaży. Łączone kolumny mają zgodne typy, a daty w tym przykładzie nie zawierają godzin.

Dokumentacja relacji Power BI opisuje propagację filtrów między tabelami. To właśnie relacja pozwala wyborowi produktu ograniczyć sprzedaż uwzględnioną w obliczeniu. Dlatego przekazuję AI również kierunek i aktywność relacji. Lista nazw tabel nie opisuje całej drogi filtra.

Przed pracą nad DAX sprawdzam unikalność kluczy wymiarów i dopasowanie kluczy sprzedaży. Nie traktuję narysowanej linii między tabelami jako potwierdzenia jakości danych. W zleceniu zapisuję wynik tej kontroli, a wykryte braki kieruję do poprawy w danych źródłowych lub przygotowaniu danych.

Przygotuj kontekst do rozmowy z AI

Poniższy opis wklejam do Claude lub innego narzędzia dopuszczonego przez firmę. To specyfikacja przykładu, którą możesz zastąpić nazwami własnych tabel. Szczególną uwagę poświęcam ostatnim zdaniom: określają, co ma się stać po użyciu filtrów raportu.

Przygotuj miary DAX dla Power BI Desktop.

Model w trybie Import:
- Sprzedaz: Data (data bez godziny), ProduktID (liczba całkowita),
  KwotaNetto i Koszt (liczby, kwoty całej pozycji w jednej walucie).
  Wiersz to pozycja opłaconego zamówienia. Bez zwrotów.
- Produkty: ProduktID (unikalna liczba całkowita),
  Nazwa i Kategoria (tekst).
- Kalendarz: Data (unikalna data bez godziny),
  Rok i Miesiac (liczby całkowite).

Aktywne relacje jeden do wielu, filtrowanie pojedyncze:
Produkty[ProduktID] -> Sprzedaz[ProduktID]
Kalendarz[Data] -> Sprzedaz[Data]
Nie ma innych relacji. Każdy klucz sprzedaży ma dopasowanie.

Przychod: suma KwotaNetto. Koszt laczny: suma kolumny Koszt.
Marza procentowa: (Przychod - Koszt laczny) / Przychod.
Udzial przychodu: Przychod w bieżącym kontekście podzielony
przez Przychod wszystkich produktów przy zachowaniu dat.
Mianownik udziału usuwa także wybór kategorii produktu.
Zerowy albo pusty mianownik oznacza BLANK.

Podaj każdą miarę osobno. Wyjaśnij filtry licznika i mianownika.
Wypisz przypadki do sprawdzenia. Nie dopisuj kolumn ani relacji.

Do takiego opisu dokładam uzgodnione definicje firmowe. Spory o to, które zamówienia liczymy, rozwiązuję przed pisaniem obliczeń, zgodnie z podejściem z tekstu o definicjach KPI. W odpowiedzi AI sprawdzam każdą nazwę pola i każde dodatkowe założenie.

Zbuduj podstawę z małych miar

W Power BI Desktop wybieram polecenie tworzenia nowej miary i dodaję każdą definicję oddzielnie. Microsoft opisuje miary jako obliczenia, których wyniki reagują na interakcje z raportem. Zaczynam od dwóch sum, żeby móc później oglądać osobno składniki marży.

Przychod = SUM('Sprzedaz'[KwotaNetto])

Koszt laczny = SUM('Sprzedaz'[Koszt])

SUM sumuje liczby w podanej kolumnie. W tym przykładzie zgodność formuły z zadaniem wynika z wcześniejszego założenia o kwotach całej pozycji. Przy odbiorze proszę więc o porównanie sumy z uzgodnionym źródłem, dla tego samego okresu i produktów.

Nazwę Koszt laczny wybrałam celowo: różni się od kolumny Koszt. Zgodnie z zasadami nazw DAX kolumna i miara w tej samej tabeli nie mogą mieć identycznej nazwy. Kolumnę wskazuję wraz z tabelą, a istniejącą miarę przez jej nazwę w nawiasach kwadratowych.

Podstawowe miary zachowuję także w raporcie kontrolnym. Przy rozbieżności marży sprawdzam osobno przychód i koszt. Łatwiej wtedy ustalić, czy problem dotyczy danych, zakresu filtra, czy definicji wskaźnika.

Zapisz marżę razem z obsługą mianownika

Marza procentowa =
DIVIDE([Przychod] - [Koszt laczny], [Przychod])

Nadaję mierze format procentowy. Definicja oznacza różnicę sum przychodu i kosztu podzieloną przez sumę przychodu w bieżącym kontekście. Na poziomie produktu i całego raportu stosujemy tę samą regułę. Nie zlecam uśredniania gotowych procentów z poszczególnych pozycji, bo przyjęta definicja wymaga ilorazu zagregowanych kwot.

W przykładach stosuję standardowe separatory DAX: przecinek między argumentami. Jeśli Twój edytor wymaga separatorów lokalnych, sprawdź opcje regionalne Power BI Desktop i dopasuj zapis do wybranego ustawienia.

Microsoft zaleca DIVIDE, gdy mianownik może być zerem albo wartością pustą. Bez trzeciego argumentu funkcja zwraca wtedy BLANK. W mojej specyfikacji zostawiam tę pustą wartość. Zero procent ma konkretne znaczenie biznesowe, więc nie używam go jako automatycznego zamiennika braku podstawy do obliczenia.

Udział sprzedaży wymaga jawnego zakresu

Przy udziale przychodu zapisuję szczególnie dokładnie mianownik. Chcę porównać bieżący wybór produktów ze wszystkimi produktami w tym samym okresie. W opisanym modelu filtry produktów i kategorii pochodzą z Produkty, a filtry okresu z Kalendarz.

Udzial przychodu =
DIVIDE(
    [Przychod],
    CALCULATE(
        [Przychod],
        REMOVEFILTERS('Produkty')
    )
)

CALCULATE oblicza wyrażenie w zmodyfikowanym kontekście filtra, a REMOVEFILTERS usuwa filtry wskazanej tabeli lub kolumn. Tutaj usuwam je z całej tabeli Produkty. Obejmuje to również kategorię. Filtr kalendarza pozostaje częścią obliczenia.

Z tej definicji wynika ważne kryterium odbioru: wybór kategorii nie powinien zawężać mianownika do tej kategorii. Jeżeli biznes oczekuje udziału wewnątrz wybranej kategorii, potrzebuje innej specyfikacji. Proszę AI o wyjaśnienie tej różnicy przed zmianą formuły. Słowo „udział” samo nie wybiera zakresu porównania.

Przeczytaj propozycję AI przed wklejeniem

W przeglądzie formuły zaczynam od zakresu usuwanych filtrów. REMOVEFILTERS() bez wskazanej tabeli usuwa filtry szerzej niż użyte tutaj REMOVEFILTERS('Produkty'). Taka zamiana zmienia umowę dotyczącą mianownika, w tym zachowania okresu. Proszę więc model o wskazanie konkretnego argumentu, który odpowiada za każdy wymóg ze specyfikacji.

Następnie sprawdzam, skąd pochodzą pola użyte na wizualizacji. W tym ćwiczeniu nazwę produktu biorę z Produkty, a rok i miesiąc z Kalendarz. Przy wyborze miesiąca wskazuję również rok, żeby okres był jednoznaczny. Jeżeli odpowiedź AI zakłada filtr bezpośrednio na kolumnie tabeli sprzedaży, porównuję ten pomysł z podanym modelem i wyjaśniam rozbieżność.

Na końcu proszę o listę zmian względem poprzedniej wersji. Szczególnie interesują mnie nowe kolumny, dodatkowe warunki i zamiana wartości pustej na zero. Każdy taki element oceniam wobec zadania. Dzięki temu przyjmuję określoną zmianę obliczenia, a historia rozmowy pokazuje, po co została wprowadzona.

Opis miary również podlega odbiorowi. Jeśli formuła usuwa kategorię, a objaśnienie obiecuje udział w kategorii, poprawiam tę sprzeczność przed przekazaniem raportu. Dokumentacja ma opisywać to samo obliczenie, które widnieje w edytorze DAX.

Odbierz miarę w kilku kontekstach

Do kontroli przygotowuję tabelę wizualną z produktem, przychodem, kosztem i obiema miarami procentowymi. Dodaję filtry z wymiarów. Sprawdzam kolejno pojedynczy produkt, kategorię, wybrany okres oraz sumę całkowitą. Dla każdego widoku zapisuję, które dane powinny wejść do licznika i mianownika.

Osobno uwzględniam przypadek zerowego przychodu oraz okres bez danych. Zestawiam zachowanie z ustaloną obsługą BLANK. Jeśli wynik jest inny od oczekiwanego, wracam do konkretnego przypadku, zamiast prosić ogólnie o „lepszy DAX”. Metodę takiego odbioru rozwijam w artykule o sprawdzaniu wyników AI.

Do dokumentacji odkładam definicję biznesową, formułę, opis filtrów i listę sprawdzonych przypadków. Dzięki temu kolejna osoba rozumie, dlaczego miara usuwa kategorię z mianownika i dlaczego przy braku przychodu zostaje pusta. To materiał, z którym można bezpiecznie rozpocząć następną zmianę raportu.