cognity: Power BI średniozaawansowany – Power Query i transformacja danych krok po kroku

Rola Power Query w Power BI i plan transformacji danych krok po kroku

Power Query to warstwa przygotowania danych w Power BI. Jej głównym zadaniem jest pobranie informacji ze źródeł, uporządkowanie ich i doprowadzenie do postaci, która nadaje się do dalszej analizy. Z punktu widzenia pracy analitycznej jest to etap wcześniejszy niż budowa modelu danych, tworzenie relacji czy pisanie miar. Najpierw dane trzeba bowiem oczyścić i ujednolicić, a dopiero później można bezpiecznie budować raporty.

Najprościej mówiąc, Power Query odpowiada na pytanie: jak przygotować dane, zanim trafią do modelu. To właśnie tutaj wykonuje się powtarzalne operacje, które po odświeżeniu raportu mogą zostać zastosowane ponownie bez ręcznej pracy. Dzięki temu raz zdefiniowany proces staje się częścią rozwiązania, a nie jednorazową czynnością wykonywaną poza Power BI.

W praktyce Power Query jest używane wtedy, gdy dane:

• pochodzą z kilku różnych miejsc i trzeba je uporządkować,
• mają niespójne nazwy, formaty lub strukturę,
• zawierają zbędne kolumny i rekordy,
• wymagają prostego przekształcenia jeszcze przed analizą,
• powinny być przygotowywane automatycznie przy każdym odświeżeniu.

Warto odróżnić Power Query od innych elementów ekosystemu Power BI. Power Query służy do przygotowania danych, model danych do ich logicznego uporządkowania i łączenia na poziomie analitycznym, a DAX do obliczeń wykonywanych już na załadowanych danych. To rozróżnienie jest bardzo ważne, ponieważ wiele problemów można rozwiązać na kilka sposobów, ale nie każdy sposób będzie równie czytelny, wydajny i łatwy w utrzymaniu.

Jeżeli jakaś zmiana dotyczy struktury danych źródłowych, ich jakości albo sposobu ładowania, zwykle dobrym miejscem startu jest właśnie Power Query. Jeżeli natomiast chodzi o logikę analityczną, agregacje i obliczenia wykorzystywane w wizualizacjach, częściej właściwszym obszarem będzie model lub warstwa miar. Świadome rozdzielenie tych ról porządkuje pracę i ogranicza liczbę późniejszych poprawek.

Rola Power Query nie sprowadza się jednak wyłącznie do „czyszczenia danych”. To także narzędzie do budowania przewidywalnego procesu transformacji. Każdy krok jest zapisywany, wykonywany w określonej kolejności i może zostać zmodyfikowany bez konieczności zaczynania od nowa. Taki sposób pracy ma duże znaczenie zwłaszcza wtedy, gdy raport korzysta z wielu źródeł albo gdy dane zmieniają się regularnie.

Dobrze zaplanowana transformacja danych powinna być przede wszystkim:

• celowa – każdy krok ma uzasadnienie biznesowe lub techniczne,
• czytelna – łatwo zrozumieć, co zostało zrobione i po co,
• powtarzalna – proces działa przy kolejnych odświeżeniach,
• oszczędna – nie wykonuje zbędnych operacji,
• odporna – lepiej radzi sobie z drobnymi zmianami w danych wejściowych.

W podejściu średniozaawansowanym szczególnie ważne jest myślenie o transformacji nie jako o serii przypadkowych kliknięć, ale jako o uporządkowanym przepływie pracy. Taki plan pomaga uniknąć bałaganu w zapytaniach i zmniejsza ryzyko, że raport będzie trudny do rozwijania. Zamiast reagować na każdy problem osobno, lepiej zaprojektować prostą sekwencję działań, która prowadzi od surowych danych do gotowego zestawu tabel.

Praktyczny plan transformacji danych krok po kroku można ująć w następujących etapach:

• Określenie celu – trzeba wiedzieć, jakie pytania biznesowe ma wspierać raport i jakie dane są rzeczywiście potrzebne.
• Rozpoznanie źródeł – warto ustalić, skąd pochodzą dane, jak często są aktualizowane i jakie mają ograniczenia.
• Wstępna selekcja – na początku dobrze jest odrzucić elementy zbędne, aby pracować tylko na tym, co potrzebne.
• Ujednolicenie – dane powinny zostać doprowadzone do spójnej postaci pod względem nazw, formatu i znaczenia.
• Kontrola jakości – należy wychwycić problemy, które mogą zaburzyć analizę, na przykład niezgodności w strukturze czy wartości problematyczne.
• Przygotowanie struktury analitycznej – dane powinny mieć układ odpowiedni do raportowania i modelowania.
• Weryfikacja wyniku – przed załadowaniem warto sprawdzić, czy końcowy efekt odpowiada założeniom.

Taki plan nie oznacza, że każdy projekt wygląda identycznie. W jednych przypadkach kluczowe będzie uporządkowanie danych z plików, w innych połączenie kilku tabel lub przebudowa układu kolumn. Istotne jest jednak zachowanie kolejności myślenia: najpierw rozumienie celu i źródła, potem porządkowanie, a na końcu przygotowanie danych do modelu.

Na tym etapie warto też pamiętać o jednej zasadzie: nie każda możliwa transformacja powinna trafić do Power Query tylko dlatego, że technicznie da się ją tam wykonać. Dobre użycie tego narzędzia polega na przygotowaniu stabilnej, sensownej warstwy wejściowej dla analizy. Im lepiej zorganizowany będzie ten etap, tym łatwiej później budować raporty, rozwijać model i utrzymywać cały projekt w czasie.

Power Query pełni więc w Power BI rolę fundamentu. To właśnie tutaj powstaje uporządkowana wersja danych, na której można bezpiecznie oprzeć dalszą pracę analityczną. Jeżeli fundament jest słaby, problemy będą wracać w modelu, wizualizacjach i wynikach. Jeżeli jest dobrze przygotowany, cały raport staje się bardziej przewidywalny, czytelny i łatwiejszy do rozwijania.

Import danych i organizacja zapytań: źródła, nawigacja, podstawowe ustawienia

Power Query to miejsce, w którym zaczyna się praktyczna praca z danymi w Power BI. Zanim pojawią się bardziej zaawansowane przekształcenia, trzeba poprawnie podłączyć źródła, zrozumieć sposób nawigacji po ich strukturze i uporządkować zapytania tak, aby model był czytelny oraz łatwy w utrzymaniu. Na poziomie średniozaawansowanym nie chodzi już tylko o kliknięcie przycisku Pobierz dane, ale o świadome przygotowanie środowiska pracy. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Import danych w Power BI może dotyczyć wielu typów źródeł. Najczęściej spotykane są pliki, bazy danych, foldery oraz usługi online. Każde z tych źródeł ma nieco inny charakter i warto rozumieć podstawowe różnice między nimi.

• Pliki sprawdzają się wtedy, gdy dane są przechowywane lokalnie lub na współdzielonych zasobach, na przykład w arkuszach, plikach tekstowych czy eksportach z systemów. Są wygodne na początku pracy, ale wymagają pilnowania struktury i lokalizacji.
• Bazy danych są lepszym wyborem, gdy pracujemy na większych zbiorach lub danych aktualizowanych centralnie. Dają zwykle większą kontrolę nad zakresem pobieranych informacji i lepiej wspierają wydajność.
• Foldery są użyteczne wtedy, gdy dane przychodzą cyklicznie w wielu plikach o podobnej strukturze. To częsty scenariusz przy raportach miesięcznych i eksportach seryjnych.
• Źródła online i usługi przydają się, gdy dane pochodzą z platform chmurowych, aplikacji biznesowych lub narzędzi analitycznych. Tu szczególne znaczenie mają sposób logowania i uprawnienia dostępu.

Po wybraniu źródła pojawia się etap nawigacji. To moment, w którym użytkownik wskazuje konkretny element do dalszej pracy: tabelę, arkusz, widok, plik lub obiekt wewnątrz usługi. W praktyce jest to jeden z najważniejszych kroków, ponieważ decyzja podjęta tutaj wpływa na dalszą stabilność całego procesu. Lepiej wybierać elementy możliwie uporządkowane i przewidywalne niż opierać się na przypadkowych zakresach czy strukturach tworzonych ręcznie.

W przypadku plików trzeba zwracać uwagę na to, czy dane rzeczywiście są zapisane w formie, którą Power Query może jednoznacznie odczytać. Arkusz roboczy nie zawsze jest najlepszym wyborem, jeśli zawiera dodatkowe opisy, puste wiersze albo kilka niezależnych sekcji. Bardziej przewidywalna bywa tabela danych lub jasno wydzielony zakres. Podobnie w bazach danych: lepiej pracować na obiektach przygotowanych do analizy niż na źródłach o niejednoznacznej strukturze.

Dobrym nawykiem jest od początku rozróżnianie, które zapytania służą do pobierania danych źródłowych, a które mają charakter pomocniczy. Dzięki temu nawet większy projekt pozostaje czytelny. W praktyce organizacja zapytań obejmuje kilka prostych zasad.

• Nadawaj zapytaniom zrozumiałe nazwy, które opisują ich funkcję, a nie przypadkowy etap pracy.
• Grupuj zapytania w folderach, jeśli projekt obejmuje wiele źródeł lub kilka obszarów danych.
• Oddzielaj warstwę źródłową od warstwy roboczej, aby łatwiej było kontrolować przepływ danych.
• Nie zostawiaj domyślnych nazw, jeśli mają utrudniać orientację w modelu.
• Wyłączaj ładowanie pomocniczych zapytań, gdy nie muszą trafiać bezpośrednio do modelu danych.

Jednym z podstawowych ustawień, o którym warto pamiętać, jest sposób uwierzytelniania do źródeł. Power BI może korzystać z różnych metod logowania w zależności od typu połączenia. Z perspektywy organizacji pracy ważne jest, aby połączenia były spójne, aktualne i oparte na właściwych uprawnieniach. Błędnie skonfigurowany dostęp często nie ujawnia się od razu podczas lokalnej pracy, ale staje się problemem przy odświeżaniu danych.

Drugim ważnym obszarem są ustawienia prywatności źródeł. W Power Query mają one wpływ na sposób łączenia danych z różnych miejsc. Dla użytkownika średniozaawansowanego najistotniejsze jest to, że poziomy prywatności nie są jedynie formalnością. Mogą wpływać zarówno na bezpieczeństwo, jak i na zachowanie zapytań. Warto więc świadomie zarządzać tym ustawieniem, szczególnie gdy w jednym raporcie pojawiają się dane z plików lokalnych, baz i usług online.

Na etapie importu dobrze jest też zwrócić uwagę na podgląd danych i automatycznie wykrywane zmiany. Power Query często sam rozpoznaje strukturę, nagłówki czy typy kolumn, ale ten mechanizm należy traktować jako punkt wyjścia, a nie ostateczne rozwiązanie. Wstępna automatyzacja bywa pomocna, jednak wymaga kontroli, aby nie budować dalszej logiki na błędnych założeniach.

W codziennej pracy duże znaczenie ma także rozumienie różnicy między połączeniem z danymi a ich przygotowaniem do modelu. Samo podłączenie źródła nie oznacza jeszcze, że dane są gotowe do analizy. Import to pierwszy etap, którego celem jest bezpieczne i uporządkowane doprowadzenie danych do miejsca, w którym można zacząć ich dalsze opracowanie. Dlatego już na początku warto zadbać o spójność nazw, przejrzystość struktury zapytań i poprawne ustawienia połączeń.

Dobrze zorganizowany panel zapytań szybko pokazuje swoją wartość. Ułatwia analizę zależności, ogranicza liczbę pomyłek i przyspiesza rozwój raportu, gdy model zaczyna się rozrastać. Nawet proste projekty stają się znacznie bardziej przewidywalne, jeśli import danych nie jest wykonywany przypadkowo, lecz według uporządkowanego schematu: wybór właściwego źródła, świadoma nawigacja po jego strukturze, sensowne nazewnictwo i podstawowa kontrola ustawień.

Czyszczenie i standaryzacja danych: typy danych, błędy, duplikaty, brakujące wartości

Na etapie transformacji danych w Power Query bardzo często największym problemem nie jest sam import, ale jakość i spójność danych. Nawet dobrze przygotowany raport może dawać mylące wyniki, jeśli kolumny mają niewłaściwe typy, pojawiają się błędy, te same rekordy występują wielokrotnie albo część wartości jest pusta. Dlatego czyszczenie danych warto traktować nie jako kosmetykę, ale jako jeden z kluczowych etapów przygotowania modelu.

Power Query daje do tego zestaw prostych, praktycznych narzędzi. Ich celem jest ujednolicenie danych tak, aby dalsza analiza była przewidywalna: liczby były liczbami, daty datami, tekst miał spójny format, a problemy jakościowe były wychwycone możliwie wcześnie.

Dlaczego standaryzacja danych jest tak ważna

Standaryzacja oznacza doprowadzenie danych do wspólnego, logicznego formatu. W praktyce chodzi o to, by wartości z różnych źródeł lub różnych okresów wyglądały i zachowywały się tak samo. Bez tego łatwo o sytuacje, w których:

• ta sama data w jednej tabeli jest datą, a w innej tekstem,
• wartości liczbowe zawierają spacje, przecinki lub symbole walut,
• ten sam klient lub produkt zapisany jest w kilku wariantach,
• puste pola są mieszane z zerami, tekstem „brak” albo wartościami błędnymi.

W efekcie filtrowanie, grupowanie, sortowanie i obliczenia mogą działać niezgodnie z oczekiwaniami. Dobrą praktyką jest więc szybkie sprawdzenie kilku podstawowych obszarów jakości danych zaraz po wczytaniu tabeli.

Typy danych – pierwszy punkt kontroli

Jednym z najważniejszych elementów porządkowania danych w Power Query jest poprawne ustawienie typu danych dla każdej kolumny. To od niego zależy, jakie operacje będą możliwe i jak Power BI zinterpretuje wartości.

Najczęściej spotykane typy to:

• tekst – dla nazw, kodów, identyfikatorów zapisanych jako ciągi znaków,
• liczba całkowita lub liczba dziesiętna – dla wartości ilościowych i kwot,
• data, godzina, data/godzina – dla pól czasowych,
• wartość logiczna – dla pól typu prawda/fałsz.

Błędnie przypisany typ danych może powodować wiele problemów. Przykładowo:

• kolumna sprzedaży ustawiona jako tekst nie będzie poprawnie sumowana,
• data zapisana jako tekst nie da się łatwo filtrować po miesiącu czy roku,
• kod pocztowy ustawiony jako liczba może utracić zera na początku.

Warto pamiętać, że Power Query często sam próbuje rozpoznać typy automatycznie. To wygodne, ale nie zawsze poprawne, dlatego po imporcie dobrze jest zweryfikować najważniejsze kolumny ręcznie.

Przy standaryzacji typów warto zwrócić uwagę nie tylko na sam typ, ale też na format źródłowy. W różnych plikach ta sama liczba może być zapisana z przecinkiem lub kropką dziesiętną, a daty mogą mieć różny układ dnia, miesiąca i roku. To często źródło nieoczekiwanych błędów po zmianie typu.

Błędy w danych – usuwać, zastępować czy diagnozować

Po ustawieniu typów danych często okazuje się, że część rekordów zamienia się w błędy. Dzieje się tak na przykład wtedy, gdy w kolumnie liczbowej pojawi się tekst, w kolumnie daty znajdzie się niepoprawna wartość albo źródło zawiera niestandardowe oznaczenia.

W Power Query błędy warto traktować jako sygnał ostrzegawczy, a nie tylko przeszkodę techniczną. Samo ich usunięcie bywa szybkie, ale ważniejsze jest zrozumienie, skąd się biorą. W praktyce można zastosować trzy podstawowe podejścia:

• usunąć wiersze z błędami – gdy wiadomo, że są nieistotne lub niepoprawne,
• zastąpić błędy wartością – gdy chcemy zachować rekord, ale uzupełnić pole wartością domyślną,
• zdiagnozować źródło problemu – gdy błąd wskazuje na niespójność wymagającą poprawy wcześniej w procesie.

Najbardziej ostrożne podejście polega na tym, by najpierw sprawdzić skalę problemu: czy błąd dotyczy kilku rekordów, jednej konkretnej kolumny, czy może całego wzorca danych. Dzięki temu łatwiej zdecydować, czy problem ma charakter incydentalny, czy systemowy.

W niektórych sytuacjach przydatne może być podstawowe zastąpienie błędu wartością neutralną, na przykład:

Table.ReplaceErrorValues(Source, {{"Kwota", 0}})

Taki zapis może być użyteczny, ale warto stosować go świadomie. Zero i brak danych to nie zawsze to samo.

Duplikaty – kiedy są problemem, a kiedy nie

Duplikaty to rekordy powtarzające się w danych. W Power Query można je stosunkowo łatwo wykrywać i usuwać, ale kluczowe jest wcześniejsze ustalenie, co właściwie oznacza duplikat w danym zbiorze.

Nie każdy powtarzający się wiersz jest błędem. Czasem wielokrotne wystąpienie tej samej wartości jest naturalne, na przykład gdy jeden klient ma wiele zamówień. Problem pojawia się wtedy, gdy ten sam rekord biznesowy trafia do danych więcej niż raz i zaburza wyniki agregacji.

Przy pracy z duplikatami najczęściej rozważa się dwa poziomy:

• duplikat całego wiersza – wszystkie wartości są identyczne,
• duplikat według wybranych kolumn – powtarza się kluczowy identyfikator lub zestaw pól, które powinny być unikalne.

To rozróżnienie ma duże znaczenie. Usunięcie duplikatów po całym wierszu jest bezpieczniejsze, ale mniej precyzyjne. Usunięcie ich po wybranych kolumnach bywa skuteczniejsze, jednak wymaga pewności, że wybrane pola rzeczywiście definiują unikalność rekordu.

Przed usunięciem duplikatów dobrze jest sprawdzić, czy powtórzenia nie wynikają z różnic pozornych, takich jak dodatkowe spacje, różna wielkość liter albo odmienny zapis tego samego kodu. Czasem najpierw trzeba ujednolicić tekst, a dopiero potem ocenić unikalność rekordów.

Brakujące wartości – puste pole to nie zawsze to samo

Jednym z najczęstszych problemów jakości danych są brakujące wartości. W Power Query mogą one występować jako:

• null – rzeczywisty brak wartości,
• pusty ciąg tekstowy,
• wartości zastępcze, takie jak „brak”, „n/d”, „-”, „0”.

Z punktu widzenia analizy to bardzo ważne rozróżnienie. Wartość null oznacza brak danych, natomiast zero może oznaczać realny wynik liczbowy. Podobnie pusty tekst i słowo „brak” mogą wyglądać podobnie wizualnie, ale w transformacji zachowują się inaczej.

Podstawowe sposoby pracy z brakami danych to:

• pozostawienie null – jeśli brak ma być widoczny i interpretowany na dalszym etapie,
• zastąpienie wartością – gdy potrzebna jest wartość domyślna,
• wypełnienie w dół lub w górę – gdy dane mają strukturę hierarchiczną lub blokową,
• odfiltrowanie braków – jeśli rekord bez danej wartości nie nadaje się do analizy.

Najważniejsze jest zachowanie spójności. Jeśli w jednej kolumnie brak danych oznaczany jest jako null, a w innej jako tekst „brak”, późniejsze raportowanie staje się mniej przejrzyste. Dobrze jest więc już w Power Query przyjąć jednolite zasady reprezentacji pustych wartości.

Typowe działania porządkujące w kolumnach tekstowych

Czyszczenie danych to nie tylko błędy i puste pola. W wielu zestawach danych przydatne są też drobne operacje standaryzujące tekst, które ograniczają liczbę wariantów tej samej wartości. Do najczęstszych należą:

• usuwanie zbędnych spacji z początku i końca tekstu,
• czyszczenie znaków niewidocznych lub niedrukowalnych,
• ujednolicanie wielkości liter,
• zamiana różnych zapisów tej samej kategorii na jedną wersję.

Takie działania wydają się niewielkie, ale mają praktyczne znaczenie. Dzięki nim ta sama kategoria nie pojawia się osobno jako kilka niemal identycznych wartości, co poprawia filtrowanie i grupowanie.

Prosty schemat pracy przy czyszczeniu danych

W codziennej pracy dobrze sprawdza się krótka, powtarzalna kolejność działań:

1. sprawdzenie struktury tabeli i zawartości kolumn,
2. weryfikacja oraz poprawa typów danych,
3. identyfikacja błędów po zmianie typów,
4. ujednolicenie wartości tekstowych,
5. analiza duplikatów,
6. obsługa brakujących wartości według przyjętej zasady,
7. końcowa kontrola wyników transformacji.

Taki schemat nie musi być sztywny, ale pomaga zachować porządek i ogranicza ryzyko, że istotny problem jakościowy zostanie przeoczony.

Na co zwracać uwagę w praktyce

Przy czyszczeniu i standaryzacji danych w Power Query warto pamiętać o kilku prostych zasadach:

• nie zakładaj, że automatyczne wykrywanie typu jest zawsze poprawne,
• nie traktuj błędów wyłącznie jako czegoś do usunięcia,
• nie usuwaj duplikatów bez ustalenia, co jest unikalnym rekordem,
• nie zamieniaj wszystkich braków danych na zero bez uzasadnienia,
• dbaj o spójność zapisu w całej tabeli.

Dobrze oczyszczone dane są prostsze w utrzymaniu, mniej podatne na błędy i znacznie lepiej przygotowane do dalszej analizy. Właśnie dlatego etap standaryzacji w Power Query warto wykonywać świadomie i metodycznie, nawet jeśli same operacje wydają się podstawowe.

Łączenie danych: Merge i Append, praca na wielu tabelach oraz kontrola kluczy

W praktycznych projektach Power BI rzadko pracuje się na jednej, kompletnej tabeli. Znacznie częściej dane są rozdzielone między kilka źródeł lub kilka arkuszy, plików i tabel, które trzeba połączyć w logiczną całość. W Power Query najważniejsze operacje w tym obszarze to Merge oraz Append. Choć obie służą do łączenia danych, rozwiązują zupełnie inne problemy i warto rozróżniać je już na etapie planowania modelu.

Merge służy do łączenia tabel po wspólnym kluczu, czyli podobnie jak join w bazach danych. Używa się go wtedy, gdy jedna tabela ma zostać wzbogacona o kolumny z innej tabeli. Append działa inaczej: dokleja wiersze jednej tabeli pod drugą, więc sprawdza się wtedy, gdy kilka tabel ma podobną strukturę i chcemy zbudować z nich jeden wspólny zbiór.

Kiedy używać Merge

Merge stosuje się wtedy, gdy tabele opisują różne aspekty tych samych obiektów. Przykładowo jedna tabela może zawierać transakcje sprzedaży, a druga informacje opisowe o produktach. Połączenie po identyfikatorze produktu pozwala przenieść nazwę, kategorię lub inne atrybuty do danych operacyjnych albo przygotować osobną tabelę wymiaru do modelu.

Najważniejsze jest tutaj poprawne wskazanie kolumny kluczowej. Jeżeli klucz jest spójny, Merge daje przewidywalny wynik. Jeżeli nie, mogą pojawić się puste dopasowania, nadmiarowe wiersze albo zwielokrotnienie danych. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności.

• Dobre zastosowanie: tabela sprzedaży + tabela produktów po ID produktu.
• Dobre zastosowanie: tabela zamówień + tabela klientów po ID klienta.
• Ryzyko: łączenie po nazwie zamiast po identyfikatorze, gdy występują różnice w zapisie.

Kiedy używać Append

Append jest właściwym wyborem wtedy, gdy kilka tabel ma ten sam sens biznesowy i zbliżony układ kolumn. Przykładem mogą być dane sprzedażowe z kolejnych miesięcy, raporty z różnych oddziałów albo eksporty z kilku systemów, które po standaryzacji powinny znaleźć się w jednej tabeli faktów.

W tym przypadku nie szukamy relacji po kluczu, lecz budujemy jeden większy zbiór rekordów. Kluczowe jest więc nie dopasowanie wartości, ale zgodność struktury kolumn: nazw, typów danych i znaczenia biznesowego.

• Dobre zastosowanie: połączenie danych ze stycznia, lutego i marca w jedną tabelę sprzedaży.
• Dobre zastosowanie: scalenie tabel o tej samej strukturze z kilku plików.
• Ryzyko: append tabel, które mają podobne nazwy kolumn, ale różne znaczenie danych.

Merge a Append — najważniejsza różnica

Najprościej można to ująć tak:

• Merge = dołączam kolumny na podstawie dopasowania rekordów,
• Append = dołączam wiersze bez dopasowywania rekordów po kluczu.

Jeżeli więc pytanie brzmi: „skąd pobrać dodatkowe informacje do już istniejących rekordów?” — zwykle chodzi o Merge. Jeżeli pytanie brzmi: „jak złączyć wiele podobnych tabel w jedną?” — zwykle chodzi o Append.

Praca na wielu tabelach w jednym projekcie

W bardziej rozbudowanych plikach Power BI łatwo stracić kontrolę nad tym, które zapytanie jest źródłem, które jest pomocnicze, a które końcowe. Dlatego przy łączeniu wielu tabel warto od początku przyjąć prosty porządek pracy:

• oddzielać zapytania źródłowe od zapytań przekształconych,
• jasno nazywać tabele wykorzystywane do Merge i Append,
• nie łączyć danych „w ciemno”, bez sprawdzenia zgodności kluczy i struktury,
• traktować tabele słownikowe, referencyjne i transakcyjne jako osobne role w modelu.

Takie podejście ułatwia późniejsze poprawki, diagnostykę błędów i rozwój raportu. Szczególnie przy wielu tabelach ważne jest też, by wiedzieć, czy dana operacja ma przygotować dane do modelu relacyjnego, czy raczej uprościć dane już na etapie Power Query.

Kontrola kluczy przed łączeniem danych

Najczęstszą przyczyną problemów podczas Merge nie jest sama operacja, lecz słaba jakość kluczy. Klucz to kolumna, która pozwala jednoznacznie dopasować rekordy między tabelami. W idealnym przypadku wartości klucza są kompletne, unikalne tam, gdzie powinny być unikalne, i zapisane w tym samym formacie po obu stronach.

Przed wykonaniem Merge warto sprawdzić przynajmniej kilka podstawowych kwestii:

• czy typ danych klucza jest taki sam w obu tabelach,
• czy w kluczu nie występują puste wartości,
• czy nie ma zbędnych spacji lub różnic w wielkości liter, jeśli mają znaczenie dla dopasowania,
• czy po stronie tabeli referencyjnej nie występują duplikaty wartości klucza,
• czy klucz rzeczywiście identyfikuje ten sam obiekt biznesowy w obu źródłach.

Nawet drobna niespójność może sprawić, że część rekordów nie zostanie dopasowana albo zostanie dopasowana wielokrotnie. W efekcie raport może wyglądać poprawnie na pierwszy rzut oka, ale zawierać błędne liczby.

Znaczenie rodzaju połączenia

Podczas Merge Power Query pozwala wybrać rodzaj połączenia, na przykład takie, które zachowuje wszystkie rekordy z tabeli głównej albo tylko rekordy wspólne dla obu tabel. Na poziomie średniozaawansowanym warto pamiętać przede wszystkim o zasadzie: rodzaj połączenia wpływa na to, które rekordy pozostaną w wyniku. To nie jest wyłącznie techniczne ustawienie, ale decyzja biznesowa.

Jeżeli chcemy zachować pełną tabelę transakcji i tylko uzupełnić ją dodatkowymi informacjami, zwykle wybiera się połączenie zachowujące wszystkie rekordy z tabeli podstawowej. Jeżeli celem jest znalezienie wyłącznie wspólnych elementów, używa się połączenia ograniczającego wynik do dopasowanych rekordów. Już na tym etapie warto więc rozumieć, czy brak dopasowania oznacza błąd danych, czy normalną sytuację.

Append wymaga spójnej struktury

Choć Append jest zwykle prostszy od Merge, również wymaga kontroli. Tabele dokładane do siebie powinny mieć możliwie spójny układ. Jeżeli jedna tabela ma kolumnę „Data sprzedaży”, a druga „Data”, Power Query potraktuje je jako różne pola, chyba że wcześniej zostaną ujednolicone. Podobnie z typami danych: niezgodność może prowadzić do późniejszych problemów w modelu i wizualizacjach.

Przy Append warto zwrócić uwagę na:

• jednolite nazwy kolumn,
• zgodne typy danych,
• ten sam poziom szczegółowości danych,
• zgodność znaczenia kolumn między źródłami.

Jeżeli tabele mają podobny kształt, ale inne znaczenie biznesowe, ich scalenie może wprowadzić chaos zamiast porządku.

Krótki przykład w języku M

Operacje Merge i Append można wykonać z interfejsu Power Query, ale w tle powstaje kod M. Przykładowo:

// Append dwóch tabel
Table.Combine({TabelaA, TabelaB})

// Merge po kluczu ID
Table.NestedJoin(TabelaSprzedaz, {"ID"}, TabelaProdukty, {"ID"}, "Produkty", JoinKind.LeftOuter)

Nie trzeba od razu pisać tych konstrukcji ręcznie, ale warto wiedzieć, że za każdą operacją stoi czytelny krok transformacji. Ułatwia to później analizę działania zapytania i jego utrzymanie.

Najczęstsze błędy przy łączeniu danych

• użycie Merge zamiast Append lub odwrotnie,
• łączenie po kolumnie, która nie jest stabilnym kluczem,
• pomijanie kontroli duplikatów przed Merge,
• doklejanie tabel o niejednolitej strukturze bez wcześniejszego ujednolicenia,
• brak weryfikacji liczby rekordów przed i po połączeniu.

Dobrą praktyką jest sprawdzanie, czy wynik połączenia zgadza się z oczekiwaniem: czy liczba wierszy nie wzrosła bez powodu, czy nie pojawiły się puste wartości w kluczowych polach i czy dane nadal odpowiadają logice biznesowej.

Praktyczne podejście

Na poziomie średniozaawansowanym najważniejsze jest nie tyle mechaniczne wykonanie Merge lub Append, ile właściwe rozpoznanie celu operacji. Najpierw warto odpowiedzieć na trzy pytania:

• czy chcę rozszerzyć rekordy o nowe atrybuty, czy połączyć wiele zestawów tego samego typu danych,
• czy mam poprawny i kontrolowany klucz do dopasowania,
• czy wynik ma wspierać przejrzysty model danych, a nie tylko chwilowo „skleić” informacje.

Jeżeli te kwestie są przemyślane, łączenie danych w Power Query staje się znacznie bardziej przewidywalne i bezpieczne. Merge i Append to podstawowe narzędzia budowania spójnych zbiorów danych, ale ich skuteczność zależy przede wszystkim od jakości przygotowania tabel i świadomej kontroli kluczy.

Przekształcenia struktury: Pivot/Unpivot, kolumny warunkowe i formuły niestandardowe

Na średniozaawansowanym poziomie pracy z Power Query bardzo często pojawia się potrzeba zmiany układu danych, a nie tylko ich czyszczenia. W praktyce oznacza to przekształcanie tabel tak, aby były wygodne do analizy, modelowania i raportowania w Power BI. Do najważniejszych operacji w tym obszarze należą Pivot, Unpivot, tworzenie kolumn warunkowych oraz budowanie formuł niestandardowych.

Te narzędzia nie służą do tego samego. Jedne zmieniają strukturę wierszy i kolumn, inne dodają logikę biznesową lub obliczenia pomocnicze. Dobrze dobrana metoda pozwala ograniczyć liczbę ręcznych poprawek i przygotować dane w formie bardziej przewidywalnej.

Pivot i Unpivot – dwie przeciwne operacje

Pivot oraz Unpivot to operacje przekształcania struktury tabeli. Najprościej mówiąc, jedna zamienia wartości z wierszy na kolumny, a druga wykonuje ruch odwrotny.

Pivot przydaje się wtedy, gdy dane źródłowe są zapisane w układzie pionowym, a do dalszej pracy potrzebny jest widok bardziej tabelaryczny lub porównawczy. Typowy przypadek to sytuacja, w której w jednej kolumnie znajdują się nazwy kategorii, a w drugiej odpowiadające im wartości. Po pivotowaniu każda kategoria może stać się osobną kolumną.

Unpivot jest szczególnie ważny w raportowaniu i analizie, ponieważ wiele źródeł danych trafia do Power BI w układzie „arkuszowym”, czyli z dużą liczbą kolumn reprezentujących miesiące, typy miar lub warianty danych. Taki format bywa wygodny dla człowieka, ale mniej użyteczny dla modelu danych. Unpivot pozwala zamienić taki układ na bardziej analityczny: jedna kolumna przechowuje nazwę cechy, a druga jej wartość.

Kiedy wybrać Pivot, a kiedy Unpivot

• Wybierz Pivot, gdy chcesz uzyskać bardziej syntetyczny widok i jasno rozdzielić wartości na osobne kolumny.
• Wybierz Unpivot, gdy zależy Ci na ujednoliceniu wielu podobnych kolumn do jednego formatu.
• Uważaj na Pivot, jeśli liczba możliwych wartości jest duża lub zmienna, ponieważ może to prowadzić do bardzo szerokiej tabeli.
• Uważaj na Unpivot, jeśli nie chcesz przypadkowo przekształcić kolumn identyfikacyjnych, które powinny pozostać bez zmian.

W praktyce Unpivot jest bardzo często pierwszym krokiem do uporządkowania danych pochodzących z plików Excel, eksportów systemowych lub zestawień, w których kolejne kolumny reprezentują ten sam typ informacji dla różnych okresów czy kategorii.

Kolumny warunkowe – logika bez pisania kodu od zera

Kolumna warunkowa pozwala tworzyć nowe wartości na podstawie prostych reguł typu „jeśli – wtedy – w przeciwnym razie”. To wygodny mechanizm, gdy trzeba zaklasyfikować rekordy, przypisać etykiety, grupy lub statusy bez ręcznego przepisywania danych.

Najczęstsze zastosowania kolumn warunkowych:

• podział rekordów na przedziały wartości,
• oznaczanie transakcji jako poprawne, opóźnione lub wymagające weryfikacji,
• tworzenie uproszczonych kategorii na podstawie bardziej szczegółowych danych,
• budowanie flag logicznych, np. 0/1 lub tak/nie.

Zaletą tego rozwiązania jest to, że interfejs Power Query pozwala zbudować reguły bez konieczności ręcznego pisania składni języka M. Dzięki temu można szybko wdrożyć prostą logikę transformacji i łatwo ją później odczytać w liście zastosowanych kroków.

Warto jednak pamiętać, że kolumny warunkowe najlepiej sprawdzają się przy jasnych i stosunkowo prostych regułach. Jeśli warunki zaczynają się rozgałęziać, opierać na wielu kolumnach albo wymagają bardziej zaawansowanych obliczeń tekstowych czy liczbowych, praktyczniejsza staje się formuła niestandardowa.

Formuły niestandardowe – większa elastyczność

Kolumna niestandardowa daje większą swobodę niż kolumna warunkowa, ponieważ można w niej wykorzystać wyrażenia języka M. Pozwala to łączyć teksty, wykonywać obliczenia, odwoływać się do wielu kolumn jednocześnie i budować bardziej precyzyjną logikę.

Formuły niestandardowe są przydatne wtedy, gdy chcesz:

• połączyć kilka pól w jeden identyfikator lub opis,
• wyliczyć nową wartość na podstawie kilku kolumn,
• zastosować funkcje tekstowe, liczbowe lub datowe,
• odwzorować regułę, której nie da się wygodnie zapisać przez prosty kreator warunków.

Przykładowa formuła niestandardowa może wyglądać bardzo prosto:

if [Wartosc] > 1000 then "Wysoka" else "Standardowa"

Albo służyć do złożenia nowego pola z kilku kolumn:

[Kategoria] & " - " & [Produkt]

Nie chodzi tu o rozbudowane programowanie, ale o możliwość precyzyjnego sterowania wynikiem transformacji. To często wystarcza, aby przygotować dane dokładnie w takim kształcie, jaki jest potrzebny do raportu.

Porównanie: kolumna warunkowa a kolumna niestandardowa

Dobre zastosowanie przekształceń struktury

Najważniejsza zasada brzmi: najpierw ustal, jaki ma być docelowy układ danych, a dopiero potem wybieraj narzędzie. Nie każda tabela wymaga pivotowania, tak samo jak nie każda wymaga budowania własnych formuł. Czasem najprostsza operacja daje najlepszy rezultat.

• Jeśli dane są zbyt szerokie i trudno je analizować, zacznij od Unpivot.
• Jeśli potrzebujesz porównania wartości między kategoriami w osobnych kolumnach, rozważ Pivot.
• Jeśli chcesz dodać prostą klasyfikację, użyj kolumny warunkowej.
• Jeśli potrzebujesz większej kontroli nad wynikiem, wybierz formułę niestandardową.

W dobrze zaprojektowanym procesie transformacji te operacje często się uzupełniają. Najpierw można uporządkować układ tabeli przez pivot lub unpivot, a później dodać logikę biznesową za pomocą nowych kolumn. Dzięki temu dane stają się jednocześnie bardziej spójne i bardziej użyteczne analitycznie.

Parametry i podstawy języka M: zmienne, funkcje, własne funkcje i dobre praktyki

Power Query nie ogranicza się do klikania w interfejsie. Każda operacja wykonywana w edytorze jest zapisywana w języku M, który odpowiada za pobieranie, przekształcanie i przygotowanie danych. Na poziomie średniozaawansowanym nie trzeba znać całego języka, ale warto rozumieć jego podstawowe elementy: parametry, zmienne, funkcje oraz sposób budowania czytelnych i łatwych do utrzymania zapytań.

Najważniejsza korzyść z poznania M jest praktyczna: zamiast ręcznie powtarzać te same operacje, można budować bardziej elastyczne i wielokrotnego użytku zapytania. Dzięki temu model danych łatwiej rozwijać, testować i aktualizować.

Parametry w Power Query – do czego służą

Parametr to wartość zdefiniowana osobno, którą można wykorzystywać w wielu zapytaniach. Pozwala on sterować działaniem transformacji bez edytowania kodu w każdym miejscu osobno. Parametry są szczególnie przydatne wtedy, gdy jakaś wartość może się zmieniać: ścieżka do pliku, nazwa arkusza, zakres dat, identyfikator środowiska czy wartość filtrowania.

W praktyce parametr pomaga ograniczyć liczbę ręcznych zmian i zmniejsza ryzyko błędów. Zamiast wpisywać tę samą wartość w kilku krokach, odwołuje się do jednego źródła ustawień.

Parametry mogą być tworzone z poziomu interfejsu Power Query, a następnie używane w kodzie M tak samo jak inne obiekty. To wygodne rozwiązanie, gdy zapytanie ma być bardziej konfigurowalne, ale nadal czytelne dla osoby pracującej głównie w edytorze graficznym.

Zmienne i konstrukcja let ... in

Podstawowa struktura kodu M opiera się na konstrukcji let ... in. W sekcji let definiuje się kolejne kroki, czyli w praktyce zmienne, a w sekcji in wskazuje wynik końcowy, który ma zostać zwrócony. To właśnie dlatego każdy krok w Power Query można traktować jak nazwany etap transformacji.

Najprościej mówiąc, zmienne w M nie służą głównie do chwilowego przechowywania pojedynczych liczb, lecz do budowania całego przepływu danych: od źródła, przez transformacje, aż do wyniku końcowego.

let
    Source = Excel.Workbook(File.Contents("C:\\Dane\\sprzedaz.xlsx"), null, true),
    Arkusz = Source{[Item="Dane", Kind="Sheet"]}[Data],
    Naglowki = Table.PromoteHeaders(Arkusz, [PromoteAllScalars=true]),
    Typy = Table.TransformColumnTypes(Naglowki, {{"Data", type date}, {"Kwota", type number}})
in
    Typy

W tym przykładzie każdy krok ma własną nazwę i odwołuje się do poprzedniego. Takie podejście daje dwie ważne korzyści:

• czytelność – łatwiej zrozumieć, co dzieje się z danymi,
• kontrola – można szybciej wykryć miejsce, w którym pojawia się błąd lub nieoczekiwany wynik.

Dobrą praktyką jest nadawanie krokom nazw opisujących ich rolę, zamiast zostawiania wyłącznie automatycznych nazw generowanych przez interfejs. W prostych zapytaniach nie ma to dużego znaczenia, ale przy większej liczbie kroków wyraźnie poprawia utrzymanie rozwiązania.

Funkcje w języku M – podstawowa idea

Funkcja to fragment logiki, który przyjmuje argumenty wejściowe i zwraca wynik. W Power Query funkcje są wykorzystywane bardzo szeroko: od prostych działań na tekście i datach po bardziej zaawansowane operacje na tabelach, listach i rekordach.

Warto pamiętać, że wiele elementów używanych na co dzień w Power Query to właśnie gotowe funkcje M, na przykład:

• Text.Trim – usuwa zbędne spacje,
• Date.Year – zwraca rok z daty,
• Table.SelectRows – filtruje wiersze tabeli,
• Table.AddColumn – dodaje nową kolumnę,
• List.Sum – sumuje wartości listy.

To ważna różnica względem pracy wyłącznie w interfejsie: użytkownik nie musi znać pełnej składni wszystkich funkcji, ale powinien rozumieć, że transformacje są oparte na wywołaniach funkcji operujących na konkretnych typach danych.

Własne funkcje – kiedy mają sens

Własna funkcja w M przydaje się wtedy, gdy ta sama logika ma być użyta wielokrotnie dla różnych danych wejściowych. Zamiast kopiować całe zapytanie i zmieniać tylko jeden element, można wydzielić logikę do funkcji i przekazywać do niej argumenty.

Typowe zastosowania własnych funkcji to:

• przetwarzanie wielu plików według tego samego schematu,
• standaryzacja podobnych tabel pochodzących z różnych źródeł,
• powtarzalne czyszczenie wybranych kolumn,
• budowanie prostych reguł klasyfikacji.

Najprostsza funkcja może przyjmować jedną wartość i zwracać przekształcony wynik:

(tekst as text) as text =>
Text.Upper(Text.Trim(tekst))

Taka funkcja najpierw usuwa zbędne spacje, a następnie zamienia tekst na wielkie litery. Choć przykład jest prosty, dobrze pokazuje ideę: logika zostaje zapisana raz i może być wykorzystana w wielu miejscach.

Funkcje mogą też działać na tabelach, co jest szczególnie użyteczne w bardziej rozbudowanych procesach transformacji. Na poziomie średniozaawansowanym najważniejsze jest jednak zrozumienie, że własna funkcja nie jest osobnym mechanizmem poza Power Query, lecz naturalnym rozszerzeniem zwykłych zapytań.

Najważniejsze różnice: parametr, zmienna i funkcja

Te pojęcia bywają mylone, bo wszystkie odnoszą się do pracy z wartościami i logiką. Ich role są jednak różne.

Najprostszy sposób myślenia o tych elementach jest następujący:

• parametr odpowiada na pytanie: „jaką wartość ustawiam?”,
• zmienna odpowiada na pytanie: „jaki jest wynik tego kroku?”,
• funkcja odpowiada na pytanie: „co ma się stać dla podanego wejścia?”.

Dobre praktyki pracy z M

Znajomość kilku zasad organizacji kodu daje dużą przewagę nawet bez wchodzenia w zaawansowane konstrukcje. W Power Query szczególnie liczy się przewidywalność i łatwość utrzymania.

• Nazywaj kroki jasno i konsekwentnie – nazwa typu UsunieteDuplikaty lub ZmianaTypow jest znacznie czytelniejsza niż ogólne Custom1.
• Unikaj nadmiernego rozbudowywania jednego kroku – lepiej podzielić logikę na kilka prostszych etapów niż budować jeden trudny do odczytania zapis.
• Stosuj parametry tam, gdzie wartość może się zmieniać – dzięki temu zapytanie jest bardziej elastyczne i łatwiejsze do przenoszenia.
• Wydzielaj powtarzalną logikę do funkcji – ogranicza to kopiowanie kodu i ułatwia aktualizacje.
• Dbaj o zgodność typów danych – wiele funkcji działa poprawnie tylko dla określonych typów wejścia.
• Testuj pośrednie kroki – w Power Query łatwo podejrzeć wynik każdego etapu, dlatego warto z tego korzystać.
• Nie edytuj kodu „na ślepo” – nawet drobna zmiana w M może wpłynąć na dalsze kroki, więc dobrze jest sprawdzać zależności.

W praktyce najlepsze zapytania to nie te najbardziej skrócone, lecz te, które można po czasie szybko zrozumieć i bezpiecznie zmodyfikować.

Dlaczego warto znać podstawy M nawet przy pracy głównie w interfejsie

Power Query pozostaje narzędziem przyjaznym dla użytkownika biznesowego, ale podstawowa znajomość M daje większą kontrolę nad transformacją danych. Pozwala szybciej rozumieć działanie kolejnych kroków, sprawniej poprawiać błędy i tworzyć rozwiązania mniej zależne od ręcznego klikania.

Nie chodzi o pisanie całych zapytań od zera w każdej sytuacji. Wystarczy rozumieć, jak działają parametry, jak są budowane kroki w let ... in, kiedy warto użyć gotowej funkcji i kiedy opłaca się stworzyć własną. To właśnie ten poziom wiedzy najczęściej oddziela prostą, jednorazową transformację od rozwiązania, które da się wygodnie rozwijać i utrzymywać.

Query folding: jak działa, jak go diagnozować i jak go nie zepsuć

Query folding to mechanizm, w którym Power Query przekazuje część operacji przekształcania danych bezpośrednio do źródła, zamiast wykonywać je lokalnie po stronie Power BI. W praktyce oznacza to, że filtrowanie, wybór kolumn czy niektóre agregacje mogą zostać przetworzone tam, gdzie dane już są przechowywane. To zwykle przekłada się na lepszą wydajność, mniejsze zużycie pamięci i szybsze odświeżanie.

Najważniejsza idea jest prosta: im więcej kroków da się „złożyć” do zapytania wykonywanego w źródle, tym mniej danych trzeba przenosić i obrabiać lokalnie. Nie każde źródło obsługuje folding w takim samym stopniu. Najlepiej działa on zwykle w relacyjnych bazach danych, natomiast w plikach, ręcznie wpisanych tabelach czy niektórych usługach sieciowych możliwości są ograniczone albo żadne.

Z punktu widzenia pracy analitycznej query folding jest ważny szczególnie wtedy, gdy:

• pracujesz na dużych wolumenach danych,
• odświeżanie raportu trwa zbyt długo,
• źródło danych ma własny silnik, który potrafi szybciej wykonać operacje niż lokalne przetwarzanie,
• chcesz ograniczyć liczbę rekordów i kolumn pobieranych do modelu.

Warto też rozumieć podstawową różnicę między foldingiem pełnym, częściowym i brakiem foldingu. W pierwszym przypadku kolejne kroki transformacji są tłumaczone na operacje źródła. W drugim tylko część kroków może zostać wypchnięta do źródła, a reszta jest wykonywana lokalnie. W trzecim całe przetwarzanie odbywa się po stronie Power Query. Dla użytkownika najważniejszy jest efekt: pełny lub częściowy folding zwykle poprawia wydajność, a jego utrata często oznacza spadek szybkości działania.

Diagnozowanie query foldingu warto traktować jako element codziennej kontroli jakości zapytań. Najprostszym sygnałem jest sprawdzenie, czy dany krok nadal może być tłumaczony na operacje źródłowe. Jeżeli folding działa, oznacza to zwykle, że Power Query zachowuje możliwość przekazania logiki dalej. Jeżeli przestaje działać na konkretnym etapie, właśnie tam najczęściej pojawił się krok, który przerwał optymalny przepływ przetwarzania.

Przy analizie problemów warto zwracać uwagę na kilka typowych objawów:

• nagłe wydłużenie czasu podglądu danych po dodaniu jednego kroku,
• duże obciążenie pamięci lokalnej podczas odświeżania,
• pobieranie większej liczby rekordów niż potrzebna do analizy,
• spadek wydajności po wprowadzeniu niestandardowej logiki w środku zapytania.

Niektóre operacje zwykle sprzyjają foldingowi, a inne częściej go przerywają. Do tych pierwszych należą przeważnie proste działania, takie jak ograniczanie kolumn, filtrowanie wierszy czy zmiana kolejności kroków w sposób zgodny z logiką źródła. Z kolei bardziej złożone transformacje, nietypowe formuły, niektóre operacje na tekstach, indeksowanie, odwołania między zapytaniami albo przekształcenia wymagające lokalnego kontekstu mogą folding osłabić lub całkowicie zatrzymać.

Aby go nie zepsuć, najlepiej stosować kilka praktycznych zasad:

• Wykonuj jak najwcześniej kroki redukujące dane – najpierw odfiltruj niepotrzebne wiersze i usuń zbędne kolumny.
• Unikaj zbyt wczesnego dodawania skomplikowanych transformacji – jeśli są konieczne, dobrze umieścić je później, po ograniczeniu zakresu danych.
• Dbaj o logiczną kolejność kroków – najpierw selekcja, później bardziej wymagające operacje.
• Ostrożnie korzystaj z funkcji niestandardowych i złożonych przekształceń – bywają wygodne, ale mogą przenieść obliczenia na lokalny silnik.
• Nie zakładaj, że folding działa zawsze tak samo – to zależy od rodzaju źródła i konkretnej operacji.
• Testuj po każdej większej zmianie – nawet jeden dodatkowy krok może zmienić sposób wykonywania całego zapytania.

W praktyce query folding nie jest celem samym w sobie, ale narzędziem optymalizacji. Czasem warto zaakceptować jego częściową utratę, jeśli transformacja jest potrzebna biznesowo i nie da się jej sensownie wykonać wcześniej. Kluczowe jest jednak świadome podejście: rozumieć, kiedy dane są przetwarzane w źródle, a kiedy lokalnie, i umieć ocenić konsekwencje dla wydajności, stabilności odświeżania oraz skali rozwiązania.

Dobrze zaprojektowane zapytanie w Power Query to nie tylko poprawny wynik, ale też sposób jego uzyskania. Query folding pomaga osiągnąć oba cele naraz: zachować logikę transformacji i jednocześnie wykorzystać możliwości źródła danych zamiast niepotrzebnie obciążać Power BI.

Mini-przykład transformacji danych sprzedażowych + checklista przygotowania danych pod model oraz wsparcie/szkolenia cognity

W praktyce Power Query najłatwiej zrozumieć na prostym scenariuszu sprzedażowym. Załóżmy, że do raportu trafiają dane z kilku plików lub systemów: lista transakcji, słownik produktów, tabela klientów i kalendarz pomocniczy. Celem nie jest samo zaimportowanie danych, ale przygotowanie ich tak, aby model w Power BI był spójny, czytelny i gotowy do dalszej analizy.

Typowy mini-proces zaczyna się od uporządkowania tabeli sprzedaży. Na tym etapie zwykle sprawdza się, czy kolumny mają właściwe znaczenie biznesowe, czy daty są rzeczywiście datami, a wartości liczbowe nie zostały zapisane jako tekst. Następnie porządkuje się nazwy kolumn, usuwa pola techniczne, które nie będą używane w analizie, oraz ogranicza dane do zakresu potrzebnego w modelu. Dzięki temu zestaw danych jest lżejszy i łatwiejszy do utrzymania.

Kolejny krok to ujednolicenie wartości. W danych sprzedażowych często pojawiają się różne warianty nazw tych samych kategorii, produktów lub regionów. Nawet drobne różnice w zapisie mogą później powodować błędne wyniki łączenia i problemy z filtrowaniem. Dlatego już na etapie przygotowania danych warto zadbać o standaryzację, eliminację pustych rekordów i kontrolę duplikatów tam, gdzie nie powinny występować.

W prostym przykładzie sprzedażowym istotne jest także rozdzielenie danych na role analityczne. Tabela transakcyjna pełni zwykle funkcję źródła faktów, a tabele produktów, klientów czy dat wspierają analizę jako wymiary. Power Query pomaga doprowadzić te obiekty do postaci, w której relacje między nimi są jednoznaczne, a klucze nadają się do poprawnego połączenia. To właśnie tutaj widać praktyczną różnicę między zwykłym importem danych a świadomym przygotowaniem podstaw pod model.

Warto też pamiętać, że nie każda transformacja ma ten sam cel. Jedne operacje służą poprawie jakości danych, inne upraszczają strukturę, a jeszcze inne przygotowują dane pod relacje i miary. W kontekście sprzedaży oznacza to na przykład odróżnienie czyszczenia kolumn od tworzenia logicznego układu tabel. Takie podejście ułatwia późniejsze raportowanie i zmniejsza ryzyko problemów podczas rozbudowy modelu.

Checklista przygotowania danych pod model

• Sprawdź cel biznesowy danych – upewnij się, że każda tabela i kolumna mają uzasadnienie w raporcie lub analizie.
• Ustal role tabel – rozdziel dane transakcyjne od słowników i tabel pomocniczych.
• Zweryfikuj typy danych – daty, liczby, tekst i wartości logiczne powinny być poprawnie rozpoznane.
• Uporządkuj nazewnictwo – stosuj spójne nazwy kolumn i zapytań, zrozumiałe dla użytkownika biznesowego i analityka.
• Usuń zbędne kolumny – pozostaw tylko te pola, które będą potrzebne w modelu, relacjach lub analizie.
• Skontroluj jakość kluczy – sprawdź, czy identyfikatory są kompletne, spójne i nadają się do łączenia tabel.
• Oceń duplikaty i braki danych – rozróżnij sytuacje dopuszczalne od tych, które wymagają korekty.
• Ujednolić wartości opisowe – zadbaj o spójność nazw kategorii, regionów, produktów i innych atrybutów.
• Oddziel transformacje techniczne od biznesowych – łatwiej wtedy utrzymać logikę zapytań i kontrolować zmiany.
• Myśl o wydajności – przygotowanie danych powinno wspierać prostszy model i sprawniejsze odświeżanie.
• Zadbaj o czytelność procesu – kolejność kroków i struktura zapytań powinny być zrozumiałe także po czasie.

Wsparcie i szkolenia cognity

Jeżeli chcesz uporządkować pracę z Power Query i lepiej przygotowywać dane pod modele Power BI, warto oprzeć się na praktycznym podejściu do transformacji danych. W tym obszarze pomocne może być wsparcie cognity, zarówno w formie szkoleń, jak i działań nastawionych na rozwój umiejętności analitycznych w codziennej pracy z danymi.

Szczególnie dla osób na poziomie średniozaawansowanym duże znaczenie ma nie tylko znajomość pojedynczych funkcji, ale przede wszystkim umiejętność budowania logicznego procesu przygotowania danych: od importu, przez porządkowanie i łączenie, aż po przygotowanie stabilnej podstawy pod model raportowy. To właśnie takie kompetencje pozwalają pracować szybciej, czytelniej i z mniejszą liczbą błędów. W Cognity łączymy teorię z praktyką, dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

W praktyce oznacza to lepsze zrozumienie, które transformacje wykonywać już w Power Query, jak dbać o spójność danych oraz jak przygotować zapytania tak, aby były użyteczne nie tylko jednorazowo, ale również przy dalszym utrzymaniu i rozwoju raportów Power BI.

cognity: Power BI średniozaawansowany – najlepsze techniki wizualizacji danych i storytellingu 17 lipca 2026

Weryfikacja odpowiedzi AI i ograniczanie halucynacji: kontrola jakości zanim użyjesz wyniku 15 lipca 2026