Unpivot i Pivot w Power Query: porządek w danych z raportów

Dlaczego raporty „ładne na oko” psują analizę danych

Prezentacja kontra struktura danych

Większość raportów generowanych z systemów ERP, CRM czy arkuszy Excela jest projektowana pod potrzeby prezentacji: pod spotkanie, maila do zarządu, plik wysyłany klientowi. Taki raport ma być „ładny na oko”: pogrubione nagłówki, pogrupowane sekcje, wstawione sumy, dodatkowe kolory. Z perspektywy analizy danych ta estetyka często zasłania podstawowe pytanie: jak wygląda faktyczna struktura tabeli?

Na pierwszy rzut oka widzimy tylko układ wizualny: miesiące w kolumnach, produkty w wierszach, w środku jakieś liczby. Dopiero przy bliższym oglądzie da się zauważyć, że kolumny oznaczone nazwami miesięcy to tak naprawdę jedna miara (np. sprzedaż), a nie dwanaście różnych miar. Z kolei wiersze podpisane „Razem”, „Suma działu”, „Grand Total” nie reprezentują pojedynczych zdarzeń, ale są efektem obliczeń. To rozróżnienie jest kluczowe, gdy dane mają trafić do Power Query i dalej do modelu danych lub tabel przestawnych.

W efekcie raport „ładny na oko” z punktu widzenia analizy bywa po prostu źle ustrukturyzowany. Brakuje jednej, spójnej kolumny z miarą, zamiast niej mamy wiele kolumn z nagłówkami odzwierciedlającymi okres, wariant czy wersję planu. To miejsce, w którym Unpivot i Pivot w Power Query zaczynają mieć znaczenie – ich rolą jest rozbicie formy prezentacyjnej i zbudowanie formy analitycznej.

Typowe układy, które blokują analizę

W raportach pojawia się kilka powtarzających się schematów, które są wygodne do oglądania, a trudne do obróbki:

• Miesiące lub lata w kolumnach – np. „Styczeń”, „Luty”, „Marzec”…; po stronie wierszy produkty lub kategorie.
• Warianty w kolumnach – „Plan”, „Wykonanie”, „Budżet”, „Prognoza”; jedna liczba w komórce, ale wiele kolumn opisujących ten sam typ wielkości.
• Sumy i podsumy w środku tabeli – wiersze „Razem region A”, „Razem kategoria X” wymieszane z normalnymi rekordami.
• Złożone nagłówki – nagłówki w kilku wierszach, scalone komórki, puste komórki zakładające „domyślne” dziedziczenie opisu z wiersza wyżej.
• Dane w blokach – kilka podobnych tabel obok siebie w jednym arkuszu, każda z innym tytułem, ale podobną strukturą.

Tak zbudowane raporty często dobrze wyglądają na ekranie lub wydruku, ale praktycznie uniemożliwiają automatyczną analizę. Power Query wymaga, aby każdy wiersz był pojedynczym rekordem, a każda kolumna reprezentowała jedno jasno zdefiniowane pole. Skomplikowane układy wizualne mieszają te dwa poziomy: struktury i prezentacji.

Co widać, a czego nie widać w typowym raporcie

Co wiemy, patrząc na raport z systemu? Widzimy nagłówki, sekcje, podsumowania, czasem wykresy. Zwykle też łatwo dostrzec, jaką historię raport ma opowiedzieć: wzrost sprzedaży, porównanie planu do wykonania, strukturę kosztów. Czego natomiast nie wiemy od razu?

Po pierwsze, nie widać, które kolumny są wymiarami (opisami: produkt, region, klient), a które są tak naprawdę przechowywaną miarą, tylko wyrażoną w specyficznym układzie, np. „Sprzedaż Styczeń”, „Sprzedaż Luty”. Po drugie, układ tabeli nie mówi, które wiersze reprezentują realne zdarzenia (np. sprzedaż konkretnego produktu w danym miesiącu), a które są jedynie wynikami formuł (sumy, różnice, odchylenia).

Unpivot i Pivot w Power Query pełnią tu funkcję „filtra strukturalnego”: pomagają odróżnić, co jest częścią struktury danych (wymiary i miary), a co jest tylko formą prezentacji (rozłożenie po kolumnach, grupowanie, podsumowania). Po ich zastosowaniu dane zyskują jasną logikę, dzięki której kolejne kroki – budowa tabeli faktów, tworzenie modelu danych pod Power BI czy analizy w Excelu – stają się powtarzalne, a nie ręcznie dopasowywane do każdego pliku z osobna.

Podstawy myślenia tabelą: wymiary, miary i forma „long” vs „wide”

Wiersz jako rekord, kolumna jako opis

Punktem wyjścia do sensownego używania unpivot w Power Query i pivot w Power Query jest zaakceptowanie prostego modelu: wiersz to pojedyncze zdarzenie lub rekord, a każda kolumna opisuje jakieś jego pole. Zdarzeniem może być sprzedaż produktu w danym dniu, wystawienie faktury, naliczenie kosztu, zapis stanu magazynu.

W takim podejściu w tabeli nie ma miejsca na wiersze „Razem” czy „Suma działu”, bo nie są one pojedynczymi zdarzeniami. Zamiast tego suma powstaje później, w tabeli przestawnej, miarze DAX lub prostym filtrowaniu i agregacji. Jeżeli raport „ładny na oko” miesza zdarzenia z ich podsumowaniami, pierwszy etap pracy w Power Query musi te podsumowania wyciąć albo odseparować.

Drugim elementem jest rozróżnienie pól opisowych i wartości. Pola typu „Produkt”, „Region”, „Miesiąc”, „Klient” opisują kontekst rekordu – to są potencjalne wymiary analityczne. Pola typu „Ilość”, „Wartość sprzedaży”, „Koszt” są miarami. Unpivot i Pivot pozwalają zmienić układ tabeli w taki sposób, aby ta różnica stała się jednoznaczna i stabilna w kolejnych plikach.

Dane szerokie (wide) a dane długie (long)

Dobrym punktem orientacyjnym jest porównanie dwóch podejść: danych „szerokich” i danych „długich”. Najprościej pokazać to na przykładzie sprzedaży miesięcznej. Dane „szerokie” wyglądają mniej więcej tak:

To klasyczny raport: miesiące jako kolumny, prosto odczytać rząd po rzędzie. Dane „długie” (long) prezentują to samo inaczej:

W wersji „long” każda kombinacja Produkt–Miesiąc jest osobnym rekordem. Kolumny „Styczeń”, „Luty”, „Marzec” zostały zastąpione jedną kolumną „Miesiąc”, a wartości z tych kolumn trafiły do jednej kolumny „Sprzedaż”. Tabela zrobiła się dłuższa (więcej wierszy), ale z punktu widzenia analizy – prostsza.

Kiedy używać układu „szerokiego”, a kiedy „długiego”

Układ szeroki dobrze sprawdza się w dwóch sytuacjach: gdy raport ma być do czytania przez człowieka (łatwiej porównać wartości w wierszu) oraz gdy powstaje jednorazowa prezentacja. To forma naturalna dla raportów wysyłanych w Excelu mailem i drukowanych na spotkaniu. Problem zaczyna się wtedy, gdy na tych samych danych trzeba wykonać kolejne analizy – dodać filtr, obliczyć dynamikę rok do roku, połączyć z danymi z innego systemu.

Układ długi jest podstawą dla tabel przestawnych, Power BI i bardziej zaawansowanych modeli danych. Tabela faktów w modelu danych niemal zawsze ma formę „long”: wiele wierszy, powtarzające się wartości w kolumnach opisowych (wymiarach), jedna lub kilka kolumn z liczbami. Dzięki temu filtrowanie, grupowanie i obliczenia działają przewidywalnie niezależnie od liczby miesięcy, nowych produktów czy zmian w układzie raportu źródłowego.

Unpivot w Power Query odpowiada za zamianę układu „wide” na „long”, a pivot w Power Query – odwrotnie. Kluczem do sensownego użycia obu jest pytanie kontrolne, o które warto zahaczyć przed każdą transformacją.

Pytanie kontrolne przed transformacją

Najprostsza metoda oceny, czy trzeba użyć unpivot, brzmi: co ma być rekordem, a co opisem tego rekordu? Jeśli rekordem ma być „sprzedaż produktu w danym miesiącu”, to naturalne pola opisowe to Produkt i Miesiąc, a miarą jest Sprzedaż. Kolumny z nazwami miesięcy przestają być miarą, stają się opisem, który trzeba przenieść do wierszy. To właśnie robi unpivot w Power Query.

Z kolei pivot ma sens, gdy jest odwrotnie: rekordem jest np. „wynik dla danej jednostki w danym okresie”, ale potrzebujesz mieć różne rodzaje kosztów w osobnych kolumnach, aby np. łatwo policzyć wybrane sumy w Excelu. Wtedy dane „długie” (jedna kolumna „Rodzaj kosztu”) można rozszerzyć na wiele kolumn, jeśli tylko taka forma ułatwia odbiorcom pracę, a ty masz już za sobą etap budowy modelu danych.

Unpivot w Power Query – idea, działanie, różnice między opcjami

„Unpivot Columns” a „Unpivot Other Columns”

Unpivot w Power Query ma dwie główne opcje kontekstowe na nagłówkach kolumn: Unpivot Columns oraz Unpivot Other Columns. Z pozoru robią to samo – zamieniają wybrane kolumny z nagłówków w wiersze – ale różnica w praktyce jest kluczowa.

Unpivot Columns wybiera do rozwinięcia konkretne kolumny, które wskażesz. To rozwiązanie przydatne, gdy potrzebujesz unpivot tylko części kolumn, a inne, o podobnych nazwach, muszą pozostać w spokoju. Przykład: raport ma kolumny „Styczeń 2023”, „Luty 2023”, „Marzec 2023”, a dodatkowo „Plan roczny” i „Prognoza” – możesz rozwinąć tylko miesiące, zostawiając kolumny planistyczne jako osobne miary.

Unpivot Other Columns działa odwrotnie: zaznaczasz kolumny, które mają pozostać niezmienione (kluczowe wymiary, np. Produkt, Region), a Power Query zrobi unpivot wszystkich pozostałych. Ta opcja jest zdecydowanie bezpieczniejsza w procesach powtarzalnych, gdy nagłówki z miesiącami czy latami będą się zmieniały w czasie. Nie musisz co roku wskazywać nowych kolumn – zaznaczasz tylko te, które nie podlegają zmianie, i pozwalasz Power Query objąć resztę.

W procesach, gdzie łączysz dane z wielu plików o podobnym układzie, Unpivot Other Columns minimalizuje ryzyko, że pojawienie się nowej kolumny (np. kolejny miesiąc) zablokuje działanie zapytania. Wskazujesz kolumny opisowe, a wszystko, co „w nadmiarze”, traktowane jest jako zestaw wartości do rozwinięcia.

Kolumny Attribute i Value – jak je rozumieć

Po wykonaniu unpivot w Power Query pojawiają się zazwyczaj dwie nowe kolumny: domyślnie nazywane Attribute i Value. Ich znaczenie jest proste, ale dobrze je precyzyjnie nazwać.

Kolumna Attribute zawiera to, co do tej pory było nagłówkami kolumn. Jeśli raport miał kolumny „Styczeń”, „Luty”, „Marzec”, właśnie te nazwy pojawią się jako wartości w nowej kolumnie Attribute. Innymi słowy: Attribute opisuje wymiar, który dotąd był ukryty w nagłówkach. Często naturalną nazwą dla tej kolumny jest „Miesiąc”, „Rok”, „Wariant”, „Rodzaj”, zależnie od zawartości.

Kolumna Value zawiera wartości z rozwiniętych komórek, czyli liczby (lub inne dane), które znajdowały się w unpivotowanych kolumnach. Jeśli rozwijałeś kolumny z kwotami sprzedaży, Value będzie właśnie tymi kwotami. W praktyce niemal zawsze warto zmienić jej nazwę na konkretną: „Sprzedaż”, „Koszt”, „Ilość”.

Przykład: kolumny „Styczeń”, „Luty”, „Marzec” zawierają wartości sprzedaży. Po unpivot:

• Attribute → np. „Styczeń”, „Luty”, „Marzec” → kolumna przemianowana na „Miesiąc”.
• Value → liczby sprzedaży → kolumna przemianowana na „Sprzedaż”.

Ta prosta zmiana nazewnictwa ułatwia czytelność całego modelu i uodparnia go na modyfikacje w źródłowych raportach.

Unpivot krok po kroku na prostym układzie

Załóżmy, że masz tabelę z raportu sprzedaży: w kolumnach miesiące, w wierszach produkty, dodatkowo kolumna z kategorią. Potrzebny jest układ „long” do dalszej analizy. Praktyczny schemat pracy z unpivot w Power Query wygląda tak:

• Załaduj dane do Power Query (np. z pliku Excel, z zakresu nazwanych danych albo z folderu).
• Usuń zbędne wiersze nagłówkowe (tytuły raportu, puste wiersze, komentarze).

Praktyczne ustawienia przed unpivot – typy danych, nagłówki, puste kolumny

Zanim kolumny trafią do unpivot, potrzebują porządku technicznego. Jeśli zabraknie kilku kroków przygotowawczych, efekt końcowy będzie poprawny wizualnie, ale problematyczny w modelu danych.

• Sprawdzenie nagłówków kolumn – unpivot opiera się na tekstach w nagłówkach, więc „Styczeń 2023 ” (z odstępem na końcu) i „Styczeń 2023” to formalnie dwa różne atrybuty. W praktyce często przydaje się krok Trim i Clean na wszystkich nagłówkach (Home → Transform → Format).
• Typ danych w kolumnach opisowych – kolumny, które nie będą unpivotowane (np. Produkt, Kategoria, Region), powinny mieć już ustawiony właściwy typ (tekst, liczba całkowita, data). Dzięki temu późniejsze łączenia tabel i relacje w modelu zadziałają bez dodatkowych korekt.
• Usunięcie kolumn technicznych – w wielu raportach pojawiają się dodatkowe kolumny „suma”, „razem”, „% udziału”, które nie są ani wymiarem, ani miarą w docelowym modelu. Jeśli nie są potrzebne, wygodniej je usunąć przed unpivot, zamiast filtrować je później z kolumny Attribute.
• Puste kolumny i puste wiersze – raporty generowane do Excela często zawierają „przerwy dla czytelności”. Dla Power Query to zbędne wiersze lub kolumny, które tylko komplikują transformacje. Szybki filtr na „null” w kluczowych kolumnach pozwala odsiać wiersze-śmieci.

Co wiemy po tym etapie? Zestaw kolumn wymiarów jest ustalony, a wszystko, co zostanie puszczone do unpivot, ma już czyste nagłówki i przewidywalny typ danych.

Unpivot na raportach z wieloma poziomami nagłówków

W realnych plikach rzadko pojawia się jeden, prosty wiersz nagłówków. Częstszy scenariusz: dwa lub trzy wiersze tytułów, z czego część opisuje okres, a część rodzaj wartości (np. „Ilość”, „Wartość”).

Typowy układ:

Aby unpivot zadziałał przewidywalnie, potrzebny jest jeden wiersz nagłówków. Stąd popularna technika „sklejenia” nagłówków poziomych:

1. Promuj pierwszy wiersz nagłówków (Home → Use First Row as Headers).
2. Drugi wiersz nagłówków potraktuj jak zwykły wiersz danych (jest już w tabeli).
3. Użyj transformacji Fill down na kolumnach z nazwami miesięcy, jeśli brakuje powtórzeń (np. puste komórki pod „Styczeń” nad „Ilość”, „Wartość”).
4. Połącz wartości z dwóch kolumn nagłówkowych (np. Miesiąc i Typ) w jedną, używając Merge Columns z separatorem, np. „ — ” lub „ | ”.
5. Promuj tak przygotowany wiersz jako nagłówki, a pomocniczy wiersz usuń.

Efekt: zamiast „Styczeń” + „Ilość” i „Styczeń” + „Wartość” pojawiają się nagłówki „Styczeń | Ilość”, „Styczeń | Wartość” itd. Dopiero potem wykonywany jest unpivot. Po rozwinięciu kolumny Attribute można łatwo rozdzielić ją z powrotem (Split Column by Delimiter) na dwa atrybuty: Miesiąc i Rodzaj miary.

Wielokrotne unpivot – gdy jeden krok to za mało

Niektóre raporty mają jednocześnie rozbicie na kolumny według okresu i według kategorii, a część informacji wciąż pozostaje w wierszach. Jednokrotny unpivot poradzi sobie z jednym wymiarem, ale nie wyciągnie wszystkiego, co schowane jest w układzie.

Przykład: raport z budżetem, w którym kolumny to miesiące, ale w nagłówkach wierszy znajdują się dodatkowo kody pozycji budżetowych, zgrupowane blokami. Aby uzyskać „czystą” tabelę faktów, często stosuje się sekwencję:

• unpivot kolumn miesięcznych do wymiaru „Miesiąc” + „Kwota”,
• oczyszczenie wierszy opisowych i przeniesienie kodu pozycji budżetowej do osobnej kolumny (np. przez wypełnianie w dół),
• ewentualny kolejny unpivot, jeśli w tabeli nadal są grupy kolumn reprezentujące różne scenariusze („Plan”, „Wykonanie”, „Prognoza”).

W praktyce tworzy się czasem dwie lub trzy tabele pomocnicze, każdą obsługiwaną osobnym unpivot, a następnie łączy je poleceniem Append Queries. To prostsze niż jeden, rozbudowany scenariusz na przeładowanej tabeli.

Kontrola po unpivot – filtrowanie, typy danych, duplikaty

Po unpivot tabela wygląda na „posprzątaną”, ale dopiero kilka prostych testów pokazuje, czy jest gotowa do analizy. Co sprawdzić?

• Puste wartości w kolumnie miary – jeśli po unpivot pojawia się wiele wierszy z null w kolumnie Value (np. dla okresów, które raport jeszcze nie obejmuje), można je bezpiecznie usunąć. Każdy taki wiersz to zbędny rekord.
• Typ danych w kolumnie atrybutu – dla wymiaru „Miesiąc” przekształcenie tekstu „Styczeń 2023” na typ Date (np. 2023-01-01) otwiera drogę do standardowych hierarchii daty, filtrów, porównań rok do roku. W wielu projektach warto dodać osobną tabelę kalendarza i mapować te daty na pełne miesiące.
• Duplikaty rekordów – unpivot może utrwalić istniejące wcześniej powielenia wierszy. Szybki test: zaznaczenie wszystkich kolumn opisowych (wymiarów) + kolumny miary, a potem polecenie „Remove Duplicates” na kopii zapytania pokazuje, czy dane zawierają powielenia, których nikt nie zauważył w raporcie źródłowym.

Pytanie kontrolne z tego etapu brzmi: czy każdy wiersz tabeli faktów reprezentuje pojedyncze, dobrze zdefiniowane zdarzenie biznesowe? Jeśli nie, wracamy krok wcześniej i szukamy przyczyny.

Pivot w Power Query – od danych „długich” do czytelnego raportu

Jak działa pivot na poziomie rekordu

Pivot w Power Query wykonuje lustrzane odbicie unpivot. Zamiast zamieniać kolumny w wiersze, zamienia wartości z jednej kolumny w nowe nagłówki. Za każdym razem potrzebne są trzy elementy:

• kolumny, które pozostaną wierszami (wymiary, np. Produkt, Rok),
• kolumna, która stanie się nagłówkami (np. Rodzaj kosztu, Scenariusz, Kanał),
• kolumna zawierająca wartości miary, które trafią do komórek w nowej, „szerokiej” tabeli.

Mechanizm jest prosty: dla każdej kombinacji wymiarów (Produkt + Rok) i wartości kolumny „Rodzaj kosztu” powstaje jedna liczba. Jeśli tych liczb jest więcej niż jedna (np. kilka rekordów dla „Produkt A, Rok 2023, Koszt stały”), Power Query musi zdecydować, jak je połączyć – i tu wchodzi agregacja.

Ustawienia agregacji podczas pivot

Domyślne ustawienie pivot w Power Query to agregacja Sum. Dla wielu raportów finansowych i sprzedażowych to naturalny wybór, ale w innych scenariuszach może zniekształcić dane.

Kiedy pivot jest uruchamiany, pojawia się okno dialogowe z pytaniem o sposób łączenia wartości. Dostępne są m.in.:

• Sum – suma wszystkich wartości (typowe dla kwot, ilości),
• Average – średnia arytmetyczna (np. średnia cena),
• Min/Max – wartości skrajne (przydatne w analizie dat),
• Count lub Count Distinct – liczba rekordów, liczba unikalnych pozycji.

Jeśli każdy wiersz tabeli wejściowej jest unikalny po kombinacji wymiarów i atrybutu pivot, można użyć opcji Don’t Aggregate. Gdy w praktyce okazuje się, że w jednym „polu tabeli” powinny być dwie różne wartości, brak agregacji spowoduje błąd – i to sygnał, że tabela wejściowa wymaga dalszego oczyszczenia lub dodatkowego wymiaru (np. numer pozycji).

Pivot jako etap przygotowania raportu końcowego

W modelach Power BI i Power Pivot tabela faktów zwykle pozostaje w układzie „long”. Pivot pojawia się głównie wtedy, gdy trzeba wygenerować gotowy raport w formie zbliżonej do klasycznego arkusza Excela, np. do cyklicznego wysyłania menedżerom.

Przykład z praktyki: firma zbiera dane o reklamach online w formacie „długim” (Data, Kampania, Kanał, Koszt, Kliknięcia, Wyświetlenia). Na potrzeby comiesięcznego zestawienia dla zarządu trzeba jednak przedstawić tabelę, w której każdy kanał (Search, Social, Display) to osobna kolumna z kosztami. Rozwiązanie:

1. W Power Query filtrowane są dane do konkretnego miesiąca i waluty.
2. Następnie pivot przenosi wartości „Kanał” do nagłówków kolumn, agregując koszty przez Sum.
3. Tabela jest ładowana do arkusza Excela jako gotowy zestaw, z zamrożonymi nagłówkami, bez konieczności ręcznego budowania tabeli przestawnej.

Fakty są takie: model danych nadal pracuje na układzie „long”, ale na końcu procesu powstaje „odwrócony” raport dopasowany do przyzwyczajeń odbiorców.

Pivot a łączenie tabel – kiedy się przydaje

Pivot jest również użyteczny jako etap pośredni przy łączeniu kilku strumieni danych. Wyobraźmy sobie przypadek, w którym:

• pierwsza tabela zawiera dzienne wyniki sprzedaży według produktów,
• druga tabela przynosi szczegółowe informacje o rabatach, w której „Rodzaj rabatu” jest kolumną atrybutu (dane „długie”).

Jeżeli po dołączeniu (Merge) danych o rabatach do sprzedaży trzeba uzyskać „cechy” w formie osobnych kolumn (np. „Rabat stały”, „Rabat sezonowy”, „Rabat lojalnościowy”), pivot na kolumnie „Rodzaj rabatu” zamienia długą listę rabatów na jednoznaczne, łatwe do czytania kolumny. Każda kombinacja Produkt–Data–Klient ma wtedy przyporządkowane konkretne wartości rabatu w formie szerokiej.

Typowe problemy przy pivot i sposoby ich diagnozy

W teorii pivot jest prosty, w praktyce pojawia się kilka powtarzalnych pułapek. Dobrze je nazwać:

• Zduplikowane rekordy po pivot – jeśli po przestawieniu danych liczba wierszy jest większa niż oczekiwano, zwykle oznacza to, że brakuje jakiegoś wymiaru w grupowaniu. Rozwiązanie: sprawdzić, czy w tabeli wejściowej są kolumny, które różnicują wiersze, a nie zostały uwzględnione w zestawie wymiarów przed pivot.
• Kolumny z nazwą „null” lub pustą etykietą – gdy w kolumnie atrybutu pivot znajdują się puste wartości, Power Query potrafi utworzyć nagłówek „null”. Jeśli taka kolumna nie ma sensu biznesowego, najlepiej odfiltrować puste atrybuty jeszcze przed pivot.
• Zmieniająca się liczba kolumn po odświeżeniu – nowy rodzaj atrybutu (np. kolejny typ kosztu) doda kolejną kolumnę. Samo w sobie nie jest błędem, ale jeśli raport końcowy ma ustaloną strukturę, trzeba przewidzieć taki scenariusz (np. filtrować tylko wybrane typy lub uzupełniać brakujące kolumny ręcznie w zapytaniu).

Co tu jest faktem? Pivot reaguje na

Kombinacja unpivot i pivot – porządkowanie zagnieżdżonych raportów

Scenariusz: raport wieloarkuszowy z sumami i wariantami

W wielu organizacjach krąży arkusz Excela, w którym:

• każdy arkusz odpowiada innemu regionowi lub działowi,
• kolumny zawierają kolejne miesiące,
• wiersze grupują kategorie i podkategorie produktów,
• w dolnej części znajdują się sumy częściowe i ogólne.

Aby zamienić to na spójne dane do dalszej analizy, proces często składa się z kilku kroków:

1. Konsolidacja wielu arkuszy jednym konektorem „From Folder” lub „From Workbook”, z kolumną wskazującą nazwę arkusza (która stanie się wymiarem „Region”).
2. Usunięcie wierszy z sumami częściowymi (filtr na kolumnie Produkt, odrzucenie wartości typu „Razem”, „SUMA”).

Projektowanie kolejnych kroków: unpivot, czyszczenie, dopiero potem pivot

Po konsolidacji i odfiltrowaniu oczywistych „śmieci” przychodzi moment decyzji: w którą stronę zagiąć dane jako pierwsze. W typowym raporcie wieloarkuszowym logiczny łańcuch wygląda tak:

1. Unpivot kolumn miesięcy do struktury (Produkt, Kategoria, Region, Miesiąc, Wartość).
2. Standaryzacja wymiarów – nazwy produktów, kategorie, regiony, format daty.
3. Oddzielenie typów wartości (np. Plan, Wykonanie, Prognoza) – jeśli pierwotnie były w kolejnych blokach kolumn.
4. Opcjonalny pivot na końcu – tylko jeśli trzeba odtworzyć „raportowy” widok dla odbiorców.

Fakt: unpivot i pivot nie są symetryczną parą używaną zawsze razem. W wielu projektach unpivot zostaje w środku procesu przygotowania modelu, a pivot pełni funkcję końcowego formatera raportu.

Ukryte atrybuty w nagłówkach – jak je odzyskać

Raporty budowane ręcznie często kodują dodatkowe informacje w nagłówkach. Przykład: kolumna „2023-01 – Plan” obok „2023-01 – Wykonanie”. Dla człowieka to czytelne, dla Power Query – pojedynczy ciąg tekstu. Żeby z tych danych zrobiło się coś użytecznego, trzeba rozbić nagłówek na dwa atrybuty.

Praktyczny schemat:

1. Wykonać unpivot na wszystkich kolumnach miesięcy/bloków.
2. Na kolumnie z atrybutem (dotychczasowy nagłówek) zastosować Split Column po separatorze (np. „ – ”).
3. Nowo powstałe części nazwać jasno: np. Miesiąc i Typ wartości.
4. Kolumnę Miesiąc przekształcić na typ daty lub osobny wymiar kalendarza.

Co się wtedy dzieje? Z jednej, trudnej do filtrowania kolumny „Attribute” powstaje przejrzysty zestaw: data + rodzaj wartości. To otwiera drogę do klasycznego porównania Plan vs Wykonanie bez dodatkowych sztuczek.

Unpivot z wieloma blokami kolumn – scenariusz z planem i wykonaniem

Częsty przypadek: raport zawiera blok kolumn „Plan styczeń–grudzień” oraz drugi blok „Wykonanie styczeń–grudzień”. Oba bloki są podobne, ale różnią się prefiksem w nagłówku. Technicznie to dwie osobne macierze w jednym arkuszu.

Żeby odzyskać z nich czytelną strukturę, schemat bywa następujący:

• Najpierw duplikat zapytania – jedno będzie przetwarzało blok Plan, drugie blok Wykonanie.
• W każdym zapytaniu pozostawia się tylko odpowiedni blok kolumn (np. „Plan_*”).
• Unpivot wykonuje się osobno w każdym zapytaniu, dodając przy tym kolumnę z etykietą Typ wartości = "Plan" lub "Wykonanie".
• Oba strumienie danych łączy się operacją Append Queries w jedną tabelę.

Fakt: takie podejście generuje dwukrotną pracę na początku, ale końcowa tabela faktów ma prostą, czterokolumnową oś: Produkt, Data, Typ wartości, Kwota. Z perspektywy modelu analitycznego to znacznie mniej skomplikowane niż kilkadziesiąt kolumn z wymieszanym planem i wykonaniem.

Unpivot przy zagnieżdżonych nagłówkach – „główka” na dwóch wierszach

W raportach księgowych i kontrolingowych nagłówki kolumn bywają dwupoziomowe: w pierwszym wierszu „Rok 2023”, w drugim „Styczeń”, „Luty” itd. Dla Excela to nadal jedna kolumna, ale Power Query odczyta tylko pierwszy wiersz jako nagłówek, a drugi potraktuje jako zwykły rekord.

Jedna z praktycznych dróg:

1. Załadować tabelę z włączoną opcją „Use first row as headers” tylko raz, żeby nie produkować zbędnych transformacji.
2. Wstawić dodatkowy krok, który przed przeniesieniem nagłówków „podciąga” drugi wiersz jako część nazwy kolumny (np. przez Fill Down i łączenie tekstu).
3. Dopiero po stworzeniu pełnych nazw (np. „2023_Styczeń”, „2023_Luty”) zastosować unpivot na blokach miesięcznych.

Po unpivot takiej struktury powstaje atrybut złożony z roku i miesiąca, który można znów rozbić na dwie kolumny i powiązać z tabelą kalendarza. Interpretacja jest wtedy oczywista: każdy wiersz odpowiada unikalnemu okresowi.

Łączenie unpivot z dodatkowymi tabelami wymiarów

Gdy źródłowy raport ma uproszczone etykiety (np. „PL”, „CZ”, „DE” zamiast pełnych nazw krajów), sensownie jest przerzucić znaczenie tych kodów do osobnych tabel wymiarów. Unpivot ułatwia ten krok, bo po spłaszczeniu danych kod pojawia się w jednym, spójnym polu.

Przykładowy ciąg działań:

• Po unpivot tabeli z kolumną RegionKod przygotować osobną tabelę wymiaru Region z dodatkowymi informacjami (kraj, menedżer, waluta raportowa).
• Ustandaryzować typy danych i kody (np. usunąć zbędne spacje, wyrównać wielkość liter).
• Połączyć (Merge) tabelę faktów z tabelą Region po kodzie, usuwając z faktów zbędne, opisowe kolumny.

Efekt jest konkretny: pivoty i wizualizacje można budować na pełnych nazwach regionów, a nie na skrótach umownych dla jednego arkusza.

Pivot kontrolowany kolumną pomocniczą

Żeby uniknąć nieoczekiwanych agregacji przy pivot, czasem dodaje się prostą kolumnę pomocniczą, która wymusza unikalność wiersza. Najprostsza forma to numer pozycji w ramach kombinacji wymiarów.

Scenariusz z praktyki: raport sprzedaży zawiera osobne wiersze dla kilku dostaw do tego samego klienta w tym samym dniu. Po unpivot dane są „długie”, a przed pivotem (np. po atrybucie „Rodzaj rabatu”) może dojść do zlewania kilku rekordów. Żeby zachować szczegółowość:

1. Dodać kolumnę indeksową w Power Query (np. Add Column > Index Column), która numeruje wiersze w tabeli.
2. Użyć tej kolumny jako jednego z wymiarów w pivot (obok Klienta, Daty, Produktu).
3. Dzięki temu każdy rekord pozostaje odrębnym wierszem, a pivot pełni tylko funkcję „rozszerzania” rabatów w poziomie.

Co wiemy po takim zabiegu? Jeśli mimo dodatkowego indeksu pivot nadal wymusza agregację, w danych istnieją prawdziwe duplikaty. To jest materiał do audytu źródła, a nie do „zamiecenia” sumą.

Przestawianie wielu miar: pivot z kolumną typu „Nazwa miary”

W niektórych systemach eksport danych ma formę tabeli, w której obok wymiarów pojawiają się kolumny: MeasureName oraz MeasureValue. W jednym pliku spotykają się wtedy np. „Przychód”, „Koszt”, „Marża procentowa” jako wartości tekstowe, a liczby siedzą w jednej kolumnie wartości.

Jeśli celem jest odbudowanie klasycznego układu (osobna kolumna dla każdej miary), pivot po kolumnie MeasureName robi całą pracę:

• Kolumny wymiarów (np. Klient, Produkt, Okres) zostają w wierszach.
• MeasureName trafia do nagłówków kolumn.
• MeasureValue stanowi dane numeryczne dla każdej nowej kolumny.

Ryzyko jest jedno: jeśli ten sam zestaw wymiarów ma kilka rekordów dla tej samej nazwy miary, pivot będzie musiał je zsumować lub inaczej zagregować. Jeśli to nie ma sensu biznesowego (np. marża procentowa), konieczne jest wcześniejsze pogrupowanie lub wybranie właściwego rekordu (np. najświeższego po dacie aktualizacji).

Dynamiczny zakres unpivot – jak nie „zahaczyć” kolumn pomocniczych

W ręcznie budowanych raportach w pierwszych kolumnach często znajdują się pola pomocnicze: komentarz, status akceptacji, uwagi. Automatyczne „Unpivot Other Columns” potrafi wciągnąć je w przekształcenie, co psuje strukturę tabeli.

Prostsze rozwiązanie niż ręczne zaznaczanie każdej kolumny:

1. Zbudować krok, w którym przez Choose Columns wskazuje się wyłącznie stabilny zestaw wymiarów (np. Kod produktu, Nazwa, Grupa, Region).
2. Następnie użyć funkcji Unpivot Other Columns na tej wybranej grupie.
3. Kolumny komentarza czy statusu pozostaną wtedy cały czas poza zakresem unpivot, nawet gdy ktoś doda nowe pola pomocnicze w źródle.

Co z tego wynika? Zakres unpivot można kontrolować definicją tego, co ma zostać „w pionie”, a nie listą każdej pojedynczej kolumny do przekształcenia.

Pivot w połączeniu z hierarchiami – poziomy kategorii jako kolumny

Niektóre raporty odbiorcy chcą widzieć w postaci „macierzy”, w której wiersze to główne kategorie, a kolumny – podkategorie lub poziomy hierarchii. Taki układ jest wygodny do szybkiego przeglądu, ale mniej przyjazny do modelowania. Da się jednak połączyć jedno z drugim.

Przykład: tabela faktów po unpivot zawiera kolumny Kategoria główna, Podkategoria, Okres, Wartość. Model analityczny działa na tej „długiej” strukturze. Na potrzeby raportu syntetycznego:

• Tworzy się osobne zapytanie, które pobiera te same dane po filtrze (np. ostatni miesiąc).
• Pivotuje się kolumnę Podkategoria, tak aby powstały kolumny odpowiadające głównym liniom biznesu.
• Agregacja odbywa się po sumie lub innym uzgodnionym wskaźniku.

Fakt: model nie musi znać tego układu „w szerz”. To jest warstwa prezentacji dla konkretnego odbiorcy, nadbudowana nad stabilną tabelą faktów.

Łączenie kilku pivotów w jednym procesie odświeżania

Pojawia się czasem pytanie: czy w jednym modelu Power Query sensowne jest używanie wielu pivotów w różnych zapytaniach? Z technicznego punktu widzenia – tak, jeśli każde z nich pełni inną funkcję:

• pierwszy pivot – do „wypłaszczenia” strumieni rabatów na pojedyncze kolumny przed włączeniem do tabeli faktów,
• drugi pivot – do zbudowania finalnej tabeli raportowej „dla zarządu”,
• trzeci – jako element pośredni w łączeniu danych z dodatkowego systemu (np. budżetowego), gdzie miary są trzymane w formie „Nazwa miary/Wartość”.

Co warto sprawdzić? Czy któryś z tych pivotów nie duplikuje pracy innego. Jeśli ten sam atrybut jest najpierw rozbijany na kolumny, a potem znów zaganiany unpivot, to sygnał, że proces można uprościć i utrzymać dany wymiar w jednej, konsekwentnej postaci.

Kontrola jakości po kombinacji unpivot + pivot

Po serii przekształceń łatwo zgubić się w liczbach. Dobrym zwyczajem jest wprowadzenie prostych testów kontrolnych w Power Query, zanim dane trafią do modelu lub raportu.

Najprostszy zestaw kontroli to:

• Suma kontrolna – porównanie jednej kluczowej miary (np. łączny przychód za rok) przed i po ciągu unpivot/pivot, na oddzielnych krokach lub w duplikacie zapytania.
• Liczba wierszy – świadome sprawdzenie, czy po unpivot wierszy jest co najmniej tyle, ile w źródle, i czy pivot nie redukuje ich w nieuzasadniony sposób.
• Liczba unikalnych kombinacji wymiarów – szybki test przez funkcję „Remove Duplicates” na kopii zapytania, bez zapisywania tego kroku w finalnym procesie.

Czego nie wiemy bez takich testów? Czy techniczne przekształcenia nie wprowadziły przypadkowej agregacji lub nie zgubiły części rekordów przy filtrowaniu. Te pytania zadaje później zarząd – lepiej zadać je wcześniej sobie, mając w ręku konkretne liczby z poszczególnych etapów.

Najczęściej zadawane pytania (FAQ)

Co to jest unpivot w Power Query i do czego służy?

Unpivot w Power Query to przekształcenie, które zamienia wiele kolumn z wartościami na dwie kolumny: jedną z nazwą atrybutu (np. miesiąc, wariant), drugą z wartością miary (np. sprzedaż). Tabela „szeroka” (wide) staje się wtedy „długa” (long) – rośnie liczba wierszy, maleje liczba kolumn.

W praktyce unpivot służy do rozbijania raportów typowo „prezentacyjnych”, w których miesiące, lata, warianty czy scenariusze są kolumnami. Dzięki temu dane nadają się do dalszej analizy: tabel przestawnych, modelu danych, Power BI. Pytanie kontrolne brzmi: czy nagłówki kolumn nie są w rzeczywistości wartościami wymiaru (np. nazwami miesięcy)? Jeśli tak, zazwyczaj potrzebny jest unpivot.

Kiedy powinienem użyć unpivot, a kiedy pivot w Power Query?

Unpivot stosuje się, gdy źródło ma zbyt wiele kolumn opisujących jeden typ wielkości – np. „Styczeń”, „Luty”, „Marzec” zamiast jednej kolumny „Miesiąc” i jednej kolumny „Sprzedaż”. Celem jest budowa tabeli faktów w układzie „long”, gdzie każdy wiersz to pojedyncze zdarzenie, a kolumny są jego opisem.

Pivot działa odwrotnie: zamienia wartości z wierszy na kolumny. Przydaje się, gdy dane są już w formie „long”, ale odbiorca oczekuje raportu „do czytania” – np. miesięcy w kolumnach na potrzeby prezentacji. Do analizy modelowej zwykle dąży się do unpivotu, a pivot to raczej ostatni krok przygotowania estetycznego raportu.

Dlaczego raport z miesiącami w kolumnach jest problemem dla Power Query i tabel przestawnych?

Raport z miesiącami w kolumnach łączy w jednym miejscu dwie role: formę prezentacji i strukturę danych. Dla człowieka taki układ jest wygodny, ale dla narzędzi analitycznych kolumny „Styczeń”, „Luty”, „Marzec” wyglądają jak trzy różne miary, a nie trzy wartości jednej miary w różnych okresach.

Efekt jest prosty: trudniej filtrować po miesiącach, liczyć dynamikę rok do roku czy łączyć raporty z różnych okresów. Po unpivot dane stają się jednorodne – mamy kolumnę „Miesiąc” i kolumnę „Sprzedaż” – więc tabele przestawne, DAX czy Power BI widzą spójny wymiar czasu i jedną miarę, którą da się łatwo agregować.

Jak rozpoznać, które kolumny unpivotować w raporcie?

Punkt wyjścia to proste pytanie: co ma być pojedynczym rekordem? Na przykład: „sprzedaż produktu w danym miesiącu”. Jeśli tak, to opisem rekordu są Produkt i Miesiąc, a miarą jest Sprzedaż. Kolumny, które reprezentują ten opis (np. nazwy miesięcy, wersje planu, warianty „Plan/Wykonanie/Budżet”), zwykle powinny zostać zebrane do jednej kolumny poprzez unpivot.

Technicznie w Power Query wybiera się kolumny opisowe (np. Produkt, Region) i używa polecenia „Unpivotuj inne kolumny”. Pozostałe kolumny – najczęściej z nagłówkami typu okres, wariant, wersja – stają się wtedy wartościami wymiaru zamiast osobnymi polami.

Co zrobić z wierszami „Razem”, „Suma działu”, „Grand Total” przy użyciu Power Query?

Wiersze z sumami i podsumami nie reprezentują pojedynczych zdarzeń, dlatego nie powinny trafić do tabeli faktów. W Power Query zazwyczaj filtruje się je na etapie wstępnym, usuwając wiersze z opisami typu „Razem”, „Suma”, „Total” w kolumnach tekstowych. Można to zrobić przez filtrowanie tekstu lub reguły oparte na wzorcach.

Co wiemy? Te wiersze są wynikiem formuł, a nie surowym zapisem zdarzeń. Czego nie wiemy? Dokładnie jak zostały policzone i czy nie dublują się z innymi sumami. Dlatego bezpieczniej budować agregacje później – w Power BI, DAX, tabeli przestawnej – na czystych rekordach bez wbudowanych podsumowań.

Dlaczego układ „long” jest lepszy do analizy niż „wide”?

Układ „long” odpowiada logice relacyjnej tabeli: każdy wiersz to rekord, każda kolumna ma jednoznaczną rolę (wymiar lub miara). Dane można wtedy łatwo filtrować, grupować, łączyć z innymi tabelami i rozbudowywać o nowe okresy czy produkty bez zmiany struktury.

W układzie „wide” każda nowa kolumna z miesiącem czy wariantem wymaga dostosowania formuł, zapytań i modeli. W „long” nowy miesiąc to po prostu nowy wiersz z już znaną kolumną „Miesiąc”. To prostsze do automatyzacji i stabilniejsze, zwłaszcza przy pracy na wielu plikach lub regularnie aktualizowanych raportach.