Denormalizacja vs agregacje: jak zmniejszyć kardynalność i przyspieszyć model (bez utraty szczegółu)

1. Kardynalność w modelu danych: definicja i dlaczego jest kluczowa w VertiPaq

Kardynalność to liczba unikalnych wartości w kolumnie. Jeśli kolumna ma 10 milionów wierszy, ale tylko 12 różnych wartości (np. miesiąc), jej kardynalność jest niska. Jeśli niemal każdy wiersz ma inną wartość (np. identyfikator transakcji), kardynalność jest bardzo wysoka.

W praktyce kardynalność jest jednym z najważniejszych parametrów jakości modelu analitycznego, bo wpływa na to, jak „ciężkie” są kolumny w pamięci i jak sprawnie silnik może je przetwarzać podczas zapytań. W modelach tabularnych opartych o VertiPaq często nie jest problemem sama liczba wierszy, tylko właśnie to, ile różnych wartości trzeba efektywnie przechować i filtrować.

Warto rozróżnić dwa powiązane pojęcia:

• Kardynalność kolumny (ile ma różnych wartości) – kluczowa dla rozmiaru przechowywania i kosztu pracy na tej kolumnie.
• Kardynalność relacji (1:* vs *:*) – ważna dla logiki modelu i sposobu propagacji filtrów, ale w kontekście „odchudzania” modelu najczęściej źródłem problemów jest wysoka kardynalność konkretnych kolumn.

Dlaczego to takie ważne w VertiPaq? VertiPaq działa kolumnowo: przechowuje dane w postaci kolumn i mocno je kompresuje. Kompresja jest najskuteczniejsza wtedy, gdy wartości w kolumnie często się powtarzają. Wysoka kardynalność oznacza, że powtórzeń jest mało, a więc:

• trudniej uzyskać dobrą kompresję, co zwiększa rozmiar modelu w pamięci,
• rośnie koszt operacji takich jak filtrowanie i grupowanie, bo silnik ma „więcej” unikalnych wartości do rozważenia,
• mogą pojawić się wąskie gardła w zapytaniach, zwłaszcza gdy raporty intensywnie tną dane po wysokokardynalnych atrybutach.

Typowe przykłady niskiej i wysokiej kardynalności pomagają szybko ocenić ryzyko:

• Niska kardynalność: status (np. 5 wartości), typ dokumentu, miesiąc, kraj, segment, flaga Tak/Nie.
• Średnia kardynalność: produkt (dziesiątki tysięcy), klient (setki tysięcy), kod pocztowy.
• Wysoka kardynalność: ID transakcji, numer faktury, timestamp do sekundy/milisekundy, długie opisy tekstowe, e-mail, GUID.

Wysoka kardynalność nie jest z definicji „błędem” — czasem jest nieunikniona (np. klucze techniczne). Problem pojawia się wtedy, gdy takie kolumny są masowo obecne w tabelach faktów, używane do filtrów w raportach albo przechowywane w formie, która sztucznie zwiększa liczbę unikalnych wartości (np. nadmierna szczegółowość czasu, niespójne formaty tekstu, różnice w wielkości liter, zbędne warianty zapisów).

Najważniejsza intuicja: jeśli chcesz przyspieszyć model bez utraty szczegółu, zacznij od identyfikacji kolumn o najwyższej kardynalności i odpowiedz na pytania:

• Czy ta szczegółowość jest realnie potrzebna do analiz i filtrów?
• Czy użytkownicy muszą ciąć dane po tej kolumnie, czy wystarczy ją wyświetlać?
• Czy wartości da się ujednolicić lub przenieść do innego miejsca w modelu tak, by zachować możliwość „zejścia do detalu”, ale nie obciążać rdzenia obliczeń?

To podejście porządkuje dalsze decyzje projektowe: kiedy spłaszczać dane, kiedy budować podsumowania i jak ograniczać „koszt” wysokokardynalnych atrybutów, nie rezygnując z analitycznej głębi.

Jak VertiPaq przechowuje dane: kodowanie słownikowe, kompresja i wpływ kardynalności na rozmiar modelu

Silnik VertiPaq (wykorzystywany m.in. w modelach tabelarycznych) jest magazynem kolumnowym. Oznacza to, że zamiast przechowywać dane „wierszami” jak w klasyjnych bazach transakcyjnych, przechowuje je „kolumnami”. Ta różnica ma ogromne znaczenie dla kompresji, bo wartości w obrębie jednej kolumny są zwykle bardziej podobne do siebie niż wartości w kolejnych kolumnach tego samego wiersza.

W praktyce rozmiar modelu i szybkość skanowania danych zależą w dużym stopniu od tego, jak dobrze poszczególne kolumny dają się skompresować. A to jest silnie powiązane z kardynalnością (liczbą unikalnych wartości) oraz charakterem danych w kolumnie. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Kodowanie słownikowe: „tekst na liczby” (i nie tylko)

Jednym z fundamentów działania VertiPaq jest kodowanie słownikowe. Zamiast zapisywać w pamięci powtarzające się wartości wprost (np. nazwy miast, kategorie, statusy), silnik buduje dla kolumny słownik unikalnych wartości, a w danych właściwych przechowuje jedynie odwołania do tego słownika.

• Słownik rośnie wraz z liczbą unikalnych wartości. Im wyższa kardynalność, tym większy słownik.
• Dane kolumny stają się w dużej mierze sekwencją kodów. Te kody mogą być małe (gdy unikalnych wartości jest mało) albo większe (gdy wartości unikalnych jest dużo), co wpływa na zużycie pamięci.

To dlatego kolumny o niskiej kardynalności (np. „Tak/Nie”, „Status”, „Miesiąc”) są zwykle bardzo „tanie” pamięciowo, nawet przy ogromnej liczbie wierszy. Z kolei kolumny o bardzo wysokiej kardynalności (np. identyfikatory, unikalne numery dokumentów, długie teksty) mogą stać się jednym z głównych źródeł rozrostu modelu.

Kompresja kolumnowa i segmenty: dlaczego rozkład wartości ma znaczenie

VertiPaq nie tylko mapuje wartości na kody, ale również stosuje techniki kompresji typowe dla danych kolumnowych. Dane w kolumnach są wewnętrznie organizowane w segmenty (porcje danych), a kompresja działa najlepiej wtedy, gdy w segmentach występują długie ciągi powtarzalnych lub „bliskich sobie” kodów.

Wysoka kardynalność zwykle utrudnia kompresję, bo:

• w segmentach pojawia się więcej różnych wartości, więc trudniej o długie powtórzenia,
• kody muszą reprezentować większy zakres wartości,
• rośnie narzut na struktury wspierające filtrowanie i skanowanie (np. informacje o rozkładzie wartości).

Istotny jest też rozrzut wartości: jeśli unikalne wartości są równomiernie rozproszone, kompresja jest słabsza niż wtedy, gdy dane są „ułożone” tak, że podobne wartości występują blisko siebie.

Typy danych i formaty: ukryty mnożnik rozmiaru

Na to, ile pamięci zużyje kolumna, wpływa nie tylko liczba unikalnych wartości, ale też typ danych oraz sposób zapisu.

• Liczby całkowite często kompresują się lepiej niż tekst, bo są łatwiejsze do kodowania i zwykle mają bardziej regularne rozkłady.
• Teksty mają dodatkowy koszt w słowniku (przechowywanie ciągów znaków), a przy wysokiej unikalności szybko „puchną”.
• Daty/godziny mogą być relatywnie „tanie”, jeśli powtarzają się (np. tylko data), ale mogą stać się wysokokardynalne, gdy przechowujemy dokładny czas do sekund lub milisekund.

Nawet pozornie niewinne różnice (np. przechowywanie liczby jako tekst, obecność zbędnych spacji, różne warianty zapisu tej samej wartości) potrafią zwiększyć kardynalność, a tym samym rozmiar słownika i koszt kompresji.

Wpływ kardynalności na rozmiar modelu: co rośnie najszybciej

W uproszczeniu, wraz ze wzrostem kardynalności rosną dwa elementy:

• Słownik kolumny (więcej unikalnych wartości do przechowania),
• Koszt reprezentacji danych (większe kody i słabsza kompresja w segmentach).

Dlatego w praktyce najdroższe bywają kolumny, które jednocześnie są duże (wiele wierszy) i wysokokardynalne. Klasyczne przykłady to identyfikatory transakcji, numery linii dokumentów, unikalne kody zdarzeń czy szczegółowe znaczniki czasu.

Dlaczego to wpływa nie tylko na pamięć, ale i na wydajność

Choć głównym efektem wysokiej kardynalności jest większy rozmiar modelu, konsekwencje szybko przechodzą na wydajność. Większy model to więcej danych do utrzymania w pamięci i potencjalnie większy koszt skanowania kolumn. Dodatkowo, im bardziej „poszatkowane” są wartości w kolumnie, tym mniej przewidywalne i mniej efektywne mogą być operacje filtrowania w pamięci.

Wniosek praktyczny jest prosty: jeśli zależy Ci na szybkim modelu, nie wystarczy patrzeć na liczbę wierszy. Trzeba patrzeć na to, które kolumny niosą największą unikalność oraz jak ta unikalność przekłada się na słownik i kompresję w VertiPaq.

3. Denormalizacja vs. normalizacja: kiedy spłaszczać model, a kiedy trzymać relacje (trade-offy dla pamięci i wydajności)

W kontekście modeli analitycznych (np. Power BI / VertiPaq) decyzja „spłaszczać czy rozdzielać” nie jest powtórką z projektowania baz transakcyjnych. Celem nie jest eliminacja redundancji za wszelką cenę, tylko optymalizacja kompresji, skanowania kolumn oraz pracy relacji przy zachowaniu poprawnej semantyki.

Co oznacza normalizacja i denormalizacja w modelu analitycznym?

• Normalizacja – rozdzielenie atrybutów do osobnych tabel (wymiarów) i łączenie ich relacjami. Zwykle oznacza to więcej tabel, mniej powtarzanych wartości w faktach.
• Denormalizacja – „spłaszczenie” atrybutów do jednej szerszej tabeli (często wymiaru) lub doszczepienie części atrybutów do faktu, aby ograniczyć liczbę relacji i skoków między tabelami.

Najczęstszy cel: prosty i przewidywalny schemat gwiazdy

W praktyce najlepszym punktem wyjścia jest schemat gwiazdy: jedna (lub kilka) tabel faktów i zestaw wymiarów. To już jest „normalizacja” względem faktu, ale jednocześnie często denormalizacja wewnątrz wymiarów (np. produkt zawiera od razu markę, kategorię, linię) bywa korzystna. Innymi słowy: model bywa mieszanką obu podejść.

Kiedy denormalizować (spłaszczać)?

• Gdy rozbijasz wymiar na „płatki śniegu” (snowflake) i kończy się to wieloma relacjami 1:* w łańcuchu (np. Produkt → Subkategoria → Kategoria). Spłaszczenie do jednego wymiaru często upraszcza filtrowanie i ogranicza narzut na propagację filtrów.
• Gdy relacje są niejednoznaczne lub kruche (np. kilka potencjalnych ścieżek filtracji, potrzeba wielu relacji nieaktywnych). Spłaszczenie bywa prostszą drogą do stabilnej semantyki.
• Gdy atrybuty są małe i niskokardynalne (np. kilka pól kategorycznych), a ich przeniesienie do jednego miejsca upraszcza raportowanie bez wyraźnego kosztu pamięci.
• Gdy zależy Ci na ergonomii i samoobsłudze: użytkownikom łatwiej pracować na jednym wymiarze „Klient” niż na zestawie powiązanych tabel opisowych.

Kiedy trzymać relacje i normalizować?

• Gdy atrybuty są często aktualizowane i chcesz ograniczyć replikację danych (np. opisy, statusy, mapowania). W wymiarze zmienisz wartość raz zamiast w wielu miejscach.
• Gdy masz wiele faktów korzystających z tych samych opisów (wspólne wymiary, tzw. conformed dimensions). Utrzymanie jednego wymiaru jest zwykle prostsze i spójniejsze.
• Gdy denormalizacja powoduje mnożenie wierszy (np. dołączanie atrybutów z relacji wiele-do-wielu lub jeden-do-wielu w złym kierunku). „Spłaszczenie” może wtedy niepostrzeżenie zmienić ziarno danych.
• Gdy atrybuty są wysokokardynalne i ich doszczepienie do szerokiej tabeli zwiększa rozmiar oraz utrudnia kompresję (zamiast przenieść je do osobnej tabeli, gdzie występują rzadziej).

Trade-offy: pamięć, wydajność, złożoność

Praktyczna heurystyka decyzyjna

• Nie denormalizuj faktu „dla wygody”, jeśli oznacza to kopiowanie opisów do tabeli z milionami wierszy. Najpierw próbuj rozwiązać to wymiarem.
• Denormalizuj wymiary, gdy to usuwa łańcuch relacji i nie zmienia ziarna (np. Kategorie do Produktu w ramach relacji 1:*).
• Trzymaj osobno to, co ma inne tempo zmian (np. słowniki, mapowania), jeśli spłaszczenie wymuszałoby częste przebudowy.
• Wybieraj prostotę ścieżki filtrów: mniej relacji i mniej wyjątków (np. wiele relacji nieaktywnych) zazwyczaj poprawia przewidywalność modelu.

Ostatecznie „lepsze” podejście zależy od tego, czy wąskim gardłem jest rozmiar, czas zapytań, czy złożoność semantyki. Najbezpieczniejszą strategią jest utrzymywanie faktów w schemacie gwiazdy i świadome spłaszczanie tylko tych fragmentów, które redukują złożoność relacji bez wprowadzania nadmiarowej kardynalności.

4. Agregacje i tabele podsumowań: kiedy budować agregacje, jak dobierać ziarno i jakie są koszty utrzymania

Agregacje (tabele agregacyjne/podsumowań) to technika, w której obok szczegółowej tabeli faktów utrzymujesz dodatkową tabelę z danymi zrolowanymi do wyższego poziomu (np. dzień zamiast transakcji, produkt-kategoria zamiast SKU). Celem jest zmniejszenie ilości danych, które silnik musi skanować dla najczęstszych zapytań, przy zachowaniu możliwości zejścia do detalu, gdy jest to potrzebne.

Kiedy agregacje mają sens

• Duży fakt i powtarzalne wzorce analiz: raporty najczęściej odpytywane na podobnym poziomie (np. sprzedaż per dzień, region, kategoria).
• Większość użytkowników nie potrzebuje detalu w 90% interakcji, a detal jest używany incydentalnie (np. drill-through, audyt).
• Miary są agregowalne: sumy, liczniki, proste minima/maksima. (Bardziej złożone logiki zwykle wymagają ostrożności w doborze ziarna.)
• Wąskie gardło to skan faktu: gdy czas odpowiedzi wynika głównie z przetwarzania ogromnej liczby wierszy, a nie z samego DAX czy relacji.

Kiedy agregacje nie pomagają (albo szkodzą)

• Ziarno zapytań jest często „na detalu” (np. analiza po numerze transakcji, użytkowniku, zdarzeniu) — agregat nie będzie użyty i tylko zwiększy rozmiar oraz złożoność.
• Wysoka kardynalność osi raportu (np. tysiące unikalnych wartości) — nawet tabela agregacyjna może pozostać duża, a zysk ograniczony.
• Miary nie są addytywne wprost (np. średnie ważone, distinctcount) — da się je wspierać agregatami, ale wymaga to świadomego projektu (zwykle dodatkowych kolumn pomocniczych).
• Model i tak mieści się łatwo w pamięci i działa szybko — koszt utrzymania może przewyższyć korzyści.

Dobór ziarna agregacji: praktyczne zasady

Ziarno agregacji to zestaw wymiarów, po których grupujesz fakt (np. Data[Date], Produkt[Kategoria], Region[Województwo]). Dobre ziarno jest kompromisem między „mało wierszy” a „często używane w filtrach”.

• Zacznij od najczęstszych widoków: sprawdź, jakie wymiary dominują na osiach wizualizacji i w filtrach.
• Agreguj po wymiarach stabilnych i hierarchicznych: np. dzień→miesiąc, SKU→kategoria. Im bardziej naturalna hierarchia, tym łatwiej utrzymać spójność.
• Unikaj atrybutów o wysokiej kardynalności w agregacie (np. ID klienta, numer dokumentu) — szybko „zabijają” redukcję wierszy.
• Dobierz ziarno do progu użyteczności: agregat powinien obsługiwać znaczącą część zapytań. Jeśli pasuje tylko do jednej strony raportu, rozważ, czy warto.
• Projektuj „warstwowo”: czasem lepsze są 2–3 agregaty (np. dzienny i miesięczny) niż jeden „zbyt szczegółowy”.

W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo dobranie ziarna to realny kompromis między wydajnością, szczegółowością i kosztami utrzymania.

Co trzymać w tabeli agregacyjnej

W tabelach podsumowań zwykle przechowuje się:

• Klucze do wymiarów odpowiadające ziarnu (np. DateKey, CategoryKey, RegionKey).
• Miary bazowe w formie kolumn (np. SalesAmount, Quantity, Margin) gotowe do dalszej agregacji w zapytaniu.
• Kolumny pomocnicze tam, gdzie to potrzebne (np. licznik wierszy) — z założeniem, że mają sens na danym ziarnie.

Agregacje vs. „ręczne” tabele podsumowań

W praktyce spotkasz dwa podejścia: mechanizm agregacji (gdzie silnik może automatycznie „przepiąć” zapytanie na agregat) oraz manualne użycie tabel podsumowań w miarach lub jako osobnych źródeł dla części raportu. Różnią się głównie sposobem wykorzystania i kosztem kontroli.

Koszty utrzymania: co realnie „płacisz” za agregacje

• Dodatkowy rozmiar modelu: agregat zajmuje pamięć (często dużo mniej niż detal, ale to nadal kolejne kolumny i słowniki).
• Dłuższe odświeżanie: trzeba policzyć i załadować dodatkowe tabele; przy dużych wolumenach agregacja może stać się znaczącą częścią czasu refresh.
• Więcej elementów do testowania: należy weryfikować zgodność wyników między agregatem a detalem (szczególnie na granicach filtrów i w nietypowych przekrojach).
• Większa złożoność modelu: więcej tabel, relacji i potencjalnych ścieżek filtrowania; rośnie ryzyko nieintuicyjnych zachowań.
• Zarządzanie zmianą: dodanie nowego wymiaru, zmiana hierarchii lub definicji miary może wymusić przebudowę agregatu.

Minimalny przykład: tworzenie tabeli podsumowań

Poniższy fragment pokazuje ideę budowy tabeli agregacyjnej (zrolowanie do dnia i kategorii). To tylko ilustracja — kluczowe jest dopasowanie ziarna do realnych zapytań.

// Przykład koncepcyjny (DAX)
Agg_Sales_Day_Category =
SUMMARIZECOLUMNS(
    'Date'[Date],
    'Product'[Category],
    "SalesAmount", SUM('Sales'[SalesAmount]),
    "Quantity", SUM('Sales'[Quantity])
)

Najważniejsza decyzja nie dotyczy samej składni, tylko tego, czy taki agregat odpowiada dominującym przekrojom raportu i czy realnie zmniejszy liczbę skanowanych wierszy.

5. Przykłady problematycznych przypadków: atrybuty wysokokardynalne, klucze złożone, atrybuty tekstowe i identyfikatory

W praktyce modelowania (szczególnie w silnikach kolumnowych) problemy z wydajnością i rozmiarem modelu często nie wynikają z „za dużej liczby wierszy”, lecz z niekorzystnej struktury atrybutów — przede wszystkim wysokiej kardynalności, złożonych kluczy oraz „ciężkich” kolumn tekstowych. Poniżej zebrano typowe przypadki, które najczęściej okazują się kosztowne.

Atrybuty wysokokardynalne (prawie unikalne)

To kolumny, w których większość wartości się nie powtarza. Są kuszące do analizy (bo „niesie dużo informacji”), ale zwykle słabo wspierają agregację i kompresję oraz potrafią spowalniać filtrowanie.

• Adres e-mail, numer telefonu, numer konta — prawie zawsze unikalne na poziomie rekordu osoby.
• Timestamp do milisekund (np. czas zdarzenia) zamiast daty/godziny w sensownym ziarnie.
• Identyfikator zdarzenia / GUID w tabeli faktów, używany w wizualizacjach jako oś lub filtr.
• URL, User-Agent, referrer — często bardzo zmienne i długie.

Typowy objaw: raport jest szybki przy agregacji po dacie i kategorii, ale „zamula” po dodaniu do tabeli wizualizacji kolumny typu e-mail/URL/ID zdarzenia.

Klucze złożone (composite keys) i „sklejane” identyfikatory

Klucz złożony jest naturalny w źródle (np. dokument + pozycja), ale w modelu analitycznym potrafi generować dodatkowe kolumny o wysokiej kardynalności i komplikować relacje. Częstym antywzorcem jest tworzenie klucza przez konkatenację tekstów.

• (OrderID, LineNumber) jako identyfikator pozycji dokumentu — sensowne operacyjnie, ale w BI rzadko potrzebne do większości analiz.
• (ProductID, BatchID) lub (StoreID, TerminalID, ReceiptID) — dużo kombinacji, mało powtórzeń.
• Sklejony klucz tekstowy typu OrderID & "-" & LineNumber — prosty w budowie, ale zwykle cięższy od klucza liczbowego.

Typowy objaw: pojawia się potrzeba „unikalnego klucza” do relacji, a kończy się to dodaniem jednej bardzo wysokokardynalnej kolumny, która jest używana w wielu miejscach i powiększa model.

Atrybuty tekstowe: długie, nieustandaryzowane, „brudne”

Tekst jest zdradliwy: nawet jeśli wydaje się, że „to ta sama wartość”, w praktyce minimalne różnice (spacje, wielkość liter, znaki narodowe, dopiski) tworzą wiele odmiennych kategorii. Dodatkowo długie ciągi znaków zwiększają koszt przechowywania i przetwarzania.

• Nazwy produktów pochodzące z wielu systemów (różne skróty, dopiski, kolejność słów).
• Opis pozycji, uwagi, komentarze — pola „free text”, często unikalne.
• Adresy (ulica, miasto, kod) w jednym polu: „ul.” vs „ulica”, literówki, różne formaty.
• Kody przechowywane jako tekst (np. „00123” vs „123”) — to samo znaczenie, różne wartości.

Typowy objaw: slicer po „Nazwa produktu” ma tysiące pozycji, a część wygląda jak duplikaty; dodatkowo spada responsywność raportu.

Identyfikatory: GUID-y, klucze techniczne i „prawie zawsze niepotrzebne” kolumny w raporcie

Identyfikatory są niezbędne do integracji danych, ale rzadko są dobrym wymiarem analitycznym. Największy problem pojawia się wtedy, gdy ID trafia do interakcji użytkownika (filtry, osie, tabele) lub jest podstawą wielu relacji.

• GUID w postaci tekstowej — długi, praktycznie unikalny, często używany tylko „żeby było po czym łączyć”.
• Surrogate key z hurtowni danych — technicznie poprawny, ale nie zawsze musi być widoczny w modelu semantycznym.
• ID sesji, ID urządzenia, ID kliknięcia — świetne diagnostycznie, słabe do standardowej agregacji biznesowej.

Typowy objaw: model jest duży mimo „prostych danych”, a największe kolumny to różnego rodzaju identyfikatory i pola techniczne, które nie wnoszą wartości w typowych wizualizacjach.

Szybka mapa ryzyk (co zwykle boli najbardziej)

Mini-przykład: jak łatwo stworzyć „kolumnę pułapkę”

Poniżej przykład typowej kolumny o bardzo wysokiej kardynalności, która wygląda niewinnie (bo „ułatwia identyfikację”), ale często psuje wydajność, gdy trafia do raportu:

// Sklejony klucz pozycji dokumentu (często bardzo unikalny)
OrderLineKey = FORMAT ( Sales[OrderID], "0" ) & "-" & FORMAT ( Sales[LineNo], "0" )

Sam fakt istnienia takiej kolumny nie zawsze jest błędem — problem zaczyna się, gdy staje się ona osią analizy, polem w slicerze albo „uniwersalnym kluczem” łączącym wiele tabel.

6. Techniki redukcji kardynalności: hashowanie, słowniki/mapowania, grupowanie/binning, skracanie i normalizacja wartości

Redukcja kardynalności polega na zmniejszeniu liczby unikalnych wartości w kolumnach, które nie muszą przechowywać pełnej „ziarnistości” w modelu analitycznym. Celem jest zwykle lepsza kompresja i szybsze filtrowanie/sortowanie, przy jednoczesnym zachowaniu wymaganego poziomu szczegółu (np. poprzez trzymanie pełnej wartości poza modelem lub w osobnej tabeli).

6.1 Hashowanie: gdy chcesz unikalności, ale nie potrzebujesz czytelności

Hashowanie zamienia wartość (np. długi tekst, złożony klucz, identyfikator z wielu pól) na krótszy „odcisk palca”. W praktyce zmniejsza rozmiar przechowywanej wartości, ale nie zawsze zmniejsza kardynalność (liczba unikatów może pozostać taka sama). Zyskiem bywa natomiast lżejsza reprezentacja i łatwiejsze operacje na kluczu.

• Najlepsze zastosowania: techniczne klucze łączące, identyfikatory złożone, długie ciągi znaków (np. GUID w formie tekstowej), gdy użytkownik i tak ich nie ogląda.
• Warianty: hash kryptograficzny (mniejsza szansa kolizji) vs. szybszy hash niekryptograficzny (wydajność kosztem ryzyka).
• Ważne: jeśli hash ma zastąpić klucz biznesowy, potrzebujesz strategii dla kolizji (choćby w postaci kontroli jakości).

// Przykład (koncepcyjnie): budowa stabilnego klucza z pól
Key = Hash( Trim(Lower([Country])) & "|" & Trim([CustomerId]) & "|" & Format([Date], "yyyy-MM-dd") )

6.2 Słowniki i mapowania: redukcja unikatów przez ujednolicenie znaczeń

Słownik/mapowanie polega na przypisaniu wielu wariantów tej samej wartości do jednego standardu (np. „Warszawa”, „W-wa”, „WARSAW” → „Warszawa”). To jedna z najskuteczniejszych metod realnej redukcji kardynalności, bo usuwa „sztuczne” unikatowe wartości wynikające z niespójnego zapisu.

• Najlepsze zastosowania: nazwy produktów i kategorii, kanały sprzedaży, nazwy miast/regionów, statusy, kody z różnych systemów.
• Forma implementacji: tabela mapowań (wariant → wartość kanoniczna) lub reguły transformacji (np. prefiksy, zamiany znaków).
• Dobre praktyki: wersjonowanie reguł, log zmian, obsługa „nieznanych” wartości (fallback) zamiast tworzenia nowych unikatów.

6.3 Grupowanie i binning: mniej unikatów kosztem rozdzielczości

Grupowanie (kategoryzacja) i binning (przedziały) celowo obniżają kardynalność przez sprowadzenie wielu wartości do ograniczonego zestawu koszyków. To technika typowo analityczna: przyspiesza filtry i raporty, ale oznacza, że część pytań nie będzie już możliwa na poziomie dokładnej wartości.

• Najlepsze zastosowania: kwoty (np. 0–100, 100–500, >500), czas trwania, wiek, odległość, liczebności; także „Top N + reszta”.
• Wybór koszyków: stałe progi (biznesowe) lub progi statystyczne (np. kwartyle) – ważne, by były stabilne i zrozumiałe.
• Ryzyko: nadmierne uproszczenie i błędna interpretacja trendów, jeśli przedziały są źle dobrane.

// Przykład (koncepcyjnie): koszyki kwotowe
Bucket =
IF([Amount] < 100, "0-99",
IF([Amount] < 500, "100-499", "500+"))

6.4 Skracanie: mniejsze reprezentacje, gdy wystarczy fragment

Skracanie polega na zastąpieniu pełnej wartości jej fragmentem lub uproszczoną reprezentacją. Może zmniejszyć kardynalność (jeśli wiele wartości dzieli wspólny prefiks) albo jedynie ograniczyć długość tekstu (gdy unikatów jest tyle samo). Sprawdza się, gdy raporty nie potrzebują pełnego opisu.

• Najlepsze zastosowania: URL-e (np. domena zamiast całej ścieżki), ścieżki plików (katalog zamiast pełnej ścieżki), opisy (pierwsze N znaków), kody (prefiks jako grupa).
• Uwaga: skracanie może powodować zlewanie różnych wartości do jednej – to bywa celem (grupowanie), ale musi być świadome.

6.5 Normalizacja wartości: wycinanie „sztucznych” unikatów

Normalizacja wartości ujednolica zapis bez zmiany znaczenia. Często daje szybkie efekty, bo wysoka kardynalność bywa skutkiem drobnych różnic: wielkości liter, dodatkowych spacji, znaków diakrytycznych, różnych separatorów czy formatów.

• Typowe operacje: trim spacji, zamiana wielokrotnych spacji na pojedynczą, ujednolicenie wielkości liter, standaryzacja kodów (np. „0012” vs „12”), normalizacja dat/godzin do ustalonej strefy i formatu.
• Najlepsze zastosowania: nazwy własne, statusy tekstowe, kody alfanumeryczne, pola pochodzące z wielu źródeł.
• Granica: nie normalizuj agresywnie, jeśli dwie wartości mogą wyglądać podobnie, ale oznaczać coś innego (np. „PL” jako kraj vs. skrót innego atrybutu w tym samym polu).

6.6 Jak wybrać technikę: szybki przewodnik

• Jeśli unikatów jest dużo przez niespójny zapis → zacznij od normalizacji i mapowań.
• Jeśli unikatów jest dużo, bo atrybut jest ciągły (kwoty, czas) → rozważ binning (o ile analityka na to pozwala).
• Jeśli potrzebujesz technicznego klucza do łączenia i nie chcesz przenosić długich tekstów → hashowanie (z kontrolą kolizji).
• Jeśli raporty potrzebują tylko części informacji (np. domeny, prefiksu, kategorii) → skracanie lub wyciągnięcie fragmentu jako osobnej kolumny.

W praktyce najlepsze wyniki daje podejście warstwowe: najpierw usuń unikatowość „przypadkową” (normalizacja), potem zunifikuj znaczenia (mapowania), a dopiero na końcu świadomie zmniejsz rozdzielczość (binning/skracanie) lub wprowadź klucze techniczne (hash).

Wpływ decyzji na czasy zapytań: skanowanie vs. filtrowanie, relacje, DAX i wzorce mierników

To, czy raport „działa szybko”, rzadko zależy od jednego czynnika. Najczęściej jest to efekt łańcucha decyzji: jak duże i jak „różnorodne” są kolumny, jak poprowadzone są relacje oraz jak zaprojektowane są miary. Z perspektywy czasu zapytań kluczowe jest, czy silnik potrafi ograniczyć pracę do małego wycinka danych, czy musi wykonywać szerokie skanowanie dużych fragmentów modelu.

Skanowanie kontra filtrowanie: co realnie kosztuje

W praktyce dwa tryby pracy dominują w zapytaniach analitycznych:

• Skanowanie – silnik „przechodzi” po dużej liczbie wierszy/segmentów, aby policzyć wynik. Jest to typowe, gdy filtr jest słaby (mało selektywny), gdy filtr nie może być efektywnie zastosowany na wczesnym etapie, albo gdy miara wymusza operacje na poziomie wiersza.
• Filtrowanie (selektywne) – silnik potrafi szybko zawęzić zbiór danych (np. do jednej kategorii, regionu czy zakresu dat), a dopiero potem agregować. Zwykle prowadzi to do krótszych czasów odpowiedzi, bo mniej danych bierze udział w obliczeniach.

Decyzje o denormalizacji, agregacjach czy redukcji kardynalności mają znaczenie o tyle, o ile zwiększają szanse na scenariusz selektywnego filtrowania i zmniejszają konieczność skanowania dużych wolumenów.

Relacje: kiedy pomagają, a kiedy przeszkadzają

Relacje definiują, jak filtry „przechodzą” między tabelami. Z punktu widzenia wydajności liczy się nie tylko istnienie relacji, ale też jej kształt i to, jak często jest wykorzystywana przez typowe interakcje w raporcie:

• Ścieżka filtra – im prostsza i bardziej przewidywalna droga propagacji filtrów (najczęściej z wymiarów do faktów), tym łatwiej o stabilne, szybkie zapytania.
• Wiele ścieżek do tych samych danych – gdy model ma alternatywne drogi filtrów, wzrasta ryzyko niejednoznaczności i konieczności dodatkowych rozstrzygnięć w trakcie obliczeń.
• Relacje na kolumnach problematycznych – relacje oparte na kolumnach o wysokiej unikalności lub niskiej jakości (np. teksty z wariantami zapisu) częściej powodują, że filtr jest mniej selektywny lub trudniejszy do zastosowania, co kończy się większym skanowaniem.

W skrócie: dobrze zaprojektowane relacje wzmacniają filtrowanie. Źle zaprojektowane relacje zwiększają liczbę sytuacji, w których obliczenia „rozlewają się” na duże obszary danych.

DAX: koszt kontekstu i ryzyko „pracy na wierszu”

Miary potrafią być szybkie nawet na dużych modelach, jeśli pozostają w paradygmacie agregacji i korzystają z naturalnych filtrów. Najczęstsze powody spowolnień wynikają z tego, że logika miary wymusza dodatkową pracę:

• Złożone przejścia kontekstów – im częściej miara musi zmieniać sposób filtracji (np. nadpisywać, usuwać lub rekonstruować filtry), tym trudniej o przewidywalny plan zapytania i tym częściej rośnie koszt obliczeń.
• Operacje wymagające iteracji – gdy wynik zależy od obliczeń na poziomie pojedynczych elementów (np. „dla każdego … policz …”), silnik częściej wykonuje pracę proporcjonalną do liczby wierszy, a nie do liczby grup.
• Wrażliwość na kardynalność – miary, które opierają się na kolumnach o dużej liczbie unikalnych wartości (np. identyfikatorach, długich tekstach), częściej powodują droższe grupowanie i trudniejsze filtrowanie.

Najważniejsza zasada w tej sekcji: decyzje modelowe powinny umożliwiać miarom „liczenie po grupach”, a nie „liczenie po wierszach”. To zwykle robi największą różnicę w czasie zapytań.

Wzorce mierników: selektywność, stabilność i przewidywalność

W praktyce sprawdzają się wzorce, które ograniczają rozmiar zbioru danych jak najwcześniej oraz utrzymują spójny kierunek filtrów:

• Preferowanie prostych agregacji nad rozbudowaną logiką warunkową, jeśli można przenieść część decyzji do modelu (np. do wymiarów lub przygotowanych atrybutów).
• Unikanie niepotrzebnego „poszerzania” kontekstu, gdy raport i tak operuje na wąskich przekrojach (np. pojedynczy rok/region). Szeroki kontekst często oznacza skanowanie.
• Spójne użycie filtrów – jeśli ten sam wynik można osiągnąć na kilka sposobów, warto wybierać taki, który wzmacnia naturalną propagację filtrów w modelu i minimalizuje dodatkowe transformacje kontekstu.

Takie podejście nie wymaga „magii” w DAX. Zazwyczaj opiera się na konsekwentnym dopasowaniu miar do tego, jak użytkownicy faktycznie filtrują dane w raporcie.

Co w praktyce najbardziej przyspiesza zapytania

Jeśli spojrzeć na decyzje dotyczące denormalizacji, agregacji i redukcji kardynalności przez pryzmat czasu zapytań, to najczęściej wygrywają te, które:

• zwiększają selektywność filtrów (łatwiej zawęzić dane do małej części),
• zmniejszają liczbę sytuacji, w których silnik musi wykonywać szerokie skanowanie,
• utrzymują prostą, jednoznaczną propagację filtrów przez relacje,
• pozwalają miarom działać jako agregacje na grupach, a nie iteracje po szczegółach.

To właśnie w tym miejscu widać, czy kompromisy w modelu były trafione: dobre decyzje sprawiają, że większość interakcji w raporcie kończy się krótką ścieżką filtrowania i prostą agregacją, a nie kosztownym, powtarzalnym przetwarzaniem dużych zakresów danych.

8. Praktyczna checklista decyzji: jak wybrać między denormalizacją, agregacją i redukcją kardynalności

Gdy model zaczyna „puchnąć” albo zapytania spowalniają, najczęściej problem sprowadza się do jednego z trzech obszarów: zbyt wysokiej kardynalności, zbyt drogiego ziarna faktu lub nieoptymalnej struktury relacji. Poniższa checklista pomaga szybko zdecydować, czy lepiej zastosować denormalizację, agregacje, czy redukcję kardynalności — oraz w jakiej kolejności rozważać te opcje.

1) Najpierw zdiagnozuj, co jest wąskim gardłem

• Jeśli boli pamięć (rozmiar modelu): szukaj kolumn o bardzo wielu unikalnych wartościach, długich tekstów, identyfikatorów oraz pól, które są mało używane w analizie, a kosztują dużo miejsca.
• Jeśli boli czas zapytań: sprawdź, czy raporty często liczą miary na bardzo szczegółowym ziarnie (np. transakcja/zdarzenie), czy wymagają skomplikowanych filtrów i relacji, oraz czy te same agregacje są liczone wielokrotnie.
• Jeśli boli odświeżanie: zwróć uwagę na koszt przekształceń, łączeń oraz zmian w dużych tabelach, a także na to, czy model musi stale przeliczać to samo przy każdym refreshu.

2) Kiedy wybrać denormalizację (spłaszczenie)

Denormalizacja jest najczęściej decyzją o upraszczaniu modelu i ograniczaniu „przeskoków” po relacjach. Wybierz ją, gdy:

• użytkownicy raportów oczekują prostego, intuicyjnego modelu, a obecny układ wymaga wielu tabel pośrednich;
• najczęstsze zapytania filtrują i grupują po atrybutach, które dziś są w osobnych tabelach, a relacje są „głębokie” lub wielostopniowe;
• łączenia po stronie modelu komplikują logikę miar i zwiększają ryzyko dwuznaczności filtrów;
• koszt dopisania kilku niskokardynalnych atrybutów do tabeli faktów jest mniejszy niż koszt utrzymywania wielu relacji i dodatkowych tabel.

Unikaj denormalizacji, jeśli oznacza ona wciągnięcie do faktu kolumn wysokokardynalnych lub długich opisów, które są rzadko używane — wtedy możesz zyskać prostotę, ale przegrać na rozmiarze modelu.

3) Kiedy wybrać agregacje (tabele podsumowań)

Agregacje to decyzja o przeniesieniu ciężaru obliczeń z zapytań na wcześniej przygotowane podsumowania. Wybierz je, gdy:

• raporty w większości operują na poziomach typu dzień/produkt/region, a surowy fakt jest dużo bardziej szczegółowy;
• te same miary są stale liczone na tych samych przekrojach i to one dominują w kosztach zapytań;
• potrzebujesz utrzymać szczegół w modelu, ale chcesz, by typowe interakcje w raporcie działały szybko;
• akceptujesz dodatkową warstwę utrzymania (odświeżanie i spójność) w zamian za stabilne przyspieszenie.

Unikaj agregacji, jeśli zapytania niemal zawsze schodzą do najniższego poziomu szczegółu albo analiza opiera się na nietypowych, rzadko powtarzalnych przekrojach — wtedy agregaty mogą być pomijane i nie dadzą efektu.

4) Kiedy wybrać redukcję kardynalności

Redukcja kardynalności to decyzja o zmniejszeniu liczby unikalnych wartości w kolumnach lub o zastąpieniu „ciężkich” atrybutów lżejszymi reprezentacjami. Wybierz ją, gdy:

• model jest duży głównie przez kilka kolumn (ID, GUID, długie teksty, znaczniki czasu, „prawie unikalne” atrybuty);
• kolumny o wysokiej kardynalności nie są potrzebne do filtrowania/grupowania w raportach, a służą np. jedynie do identyfikacji rekordu;
• istnieje naturalna możliwość grupowania (np. przedziały, kategorie, mapowanie do słownika), a użytkownicy nie tracą na tym istotnej informacji analitycznej;
• zależy Ci przede wszystkim na zmniejszeniu rozmiaru modelu i poprawie kompresji, bez zmiany układu tabel.

Unikaj agresywnej redukcji, jeśli odbiera ona użytkownikom kluczowy wymiar analizy (np. wymagany jest dokładny poziom identyfikacji, a nie tylko grupy).

5) Szybka reguła wyboru: co daje największy efekt najszybciej

• Gdy problemem jest rozmiar: zacznij od redukcji kardynalności (usunięcie/ograniczenie drogich kolumn), dopiero potem rozważ denormalizację.
• Gdy problemem jest czas zapytań: najpierw sprawdź potencjał agregacji (przy typowych przekrojach), a denormalizację traktuj jako sposób na uproszczenie ścieżek filtrowania.
• Gdy problemem jest złożoność modelu i błędy w filtrach: denormalizacja (lub celowe uproszczenie relacji) zwykle daje najszybszą poprawę jakości pracy z modelem.

6) Kontrolne pytania, które warto zadać przed decyzją

• Czy ta kolumna jest używana w raportach? Jeśli nie — rozważ usunięcie lub zastąpienie lżejszym atrybutem.
• Czy użytkownicy naprawdę potrzebują tego poziomu szczegółu w interakcji? Jeśli zwykle analizują wyżej — agregacje mają sens.
• Czy filtracja przechodzi przez wiele relacji? Jeśli tak — spłaszczenie wybranych atrybutów może uprościć i przyspieszyć model.
• Czy to jest atrybut analityczny, czy techniczny identyfikator? Identyfikatory często są kosztowne i mało przydatne do analizy — idealny kandydat do ograniczenia ekspozycji.
• Czy zmiana wpłynie na możliwość drill-down i śledzenie szczegółu? Upewnij się, że szczegół pozostaje dostępny tam, gdzie jest wymagany.
• Jaki jest koszt utrzymania? Agregacje i dodatkowe warstwy danych zwiększają wymagania operacyjne; denormalizacja może zwiększyć obciążenie odświeżania; redukcja kardynalności wymaga spójnych mapowań i reguł.

7) Najczęstsze pułapki decyzyjne

• „Spłaszczmy wszystko” — proste w użyciu, ale może dramatycznie podnieść rozmiar modelu, jeśli do faktu trafią ciężkie atrybuty.
• „Zróbmy agregat na wszystko” — zyski pojawiają się tylko wtedy, gdy agregat odpowiada dominującym wzorcom zapytań.
• „Usuńmy szczegół, będzie szybciej” — często niepotrzebne: zwykle da się przyspieszyć typowe scenariusze bez rezygnacji z detalu, przez właściwe połączenie agregacji i selektywnej redukcji kardynalności.
• „Kardynalność nie ma znaczenia, bo to tylko kolumna tekstowa” — teksty i identyfikatory bywają jednymi z najdroższych elementów modelu.

8) Jak łączyć podejścia bez utraty szczegółu

W praktyce najlepsze rezultaty daje podejście warstwowe: redukuj kardynalność tam, gdzie nie niesie wartości analitycznej, upraszczaj strukturę tam, gdzie relacje utrudniają filtrację, i dodawaj agregacje tam, gdzie powtarzają się te same podsumowania. Takie połączenie pozwala zachować dostęp do danych szczegółowych, a jednocześnie znacząco poprawić responsywność typowych raportów.

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

Excel: dynamiczne tablice vs tabele przestawne — 10 decyzji, które zmieniają wydajność pliku 08 czerwca 2026

Claude Code dla początkujących: 11 ruchów, które przyspieszają naukę programowania bez wpadania w pułapki 06 czerwca 2026