Power Query – jak łączyć dane z wielu plików i źródeł bez ręcznego kopiowania

Wprowadzenie: dlaczego Power Query do integracji danych z wielu źródeł

Przygotowanie raportu często zaczyna się od pracy, której w samym raporcie nie widać: zebrania plików, skopiowania danych do jednego arkusza i poprawienia różnic w ich zapisie. Gdy co miesiąc dochodzą kolejne zestawienia, te same czynności trzeba wykonywać ponownie. Łatwo wtedy pominąć plik, wkleić dane dwukrotnie albo pracować na nieaktualnej wersji. Power Query pozwala zastąpić ręczne kopiowanie powtarzalnym procesem pobierania i przygotowania danych.

To narzędzie dostępne m.in. w Excelu i Power BI. Łączy się ze wskazanymi źródłami, pobiera ich zawartość i przekształca ją według zapisanych reguł. Większość typowych operacji można zbudować w edytorze graficznym, bez pisania kodu. Zamiast za każdym razem odtwarzać całą pracę, tworzysz zapytanie, które przy odświeżeniu ponownie wykonuje ustalone kroki na aktualnie dostępnych danych.

Integracja może oznaczać dwa różne zadania: zebranie podobnych zestawień w jedną całość, na przykład raportów sprzedaży z kolejnych miesięcy, albo wzbogacenie jednego zbioru informacjami z drugiego, choćby uzupełnienie transakcji o dane produktów. Power Query obsługuje oba scenariusze. Pozwala też przygotować wspólny zestaw danych pochodzących z różnych środowisk — nie tylko z plików, lecz także z baz danych czy usług internetowych.

W porównaniu z kopiowaniem i wklejaniem najważniejszą zmianą jest zapisanie sposobu przygotowania danych, a nie wyłącznie jego wyniku. Kolejne operacje pozostają widoczne w zapytaniu, więc łatwiej sprawdzić, skąd pochodzi wynik i jakie zmiany do niego doprowadziły. Przekształcenia nie wymagają przy tym ręcznego poprawiania plików źródłowych. Power Query przygotowuje dane do dalszego wykorzystania, ale nie zastępuje samych obliczeń analitycznych ani wizualizacji.

Najwięcej korzyści daje w zadaniach cyklicznych: raportowaniu sprzedaży, konsolidacji budżetów, zestawianiu stanów magazynowych czy analizie eksportów z kilku systemów. Warunkiem niezawodności pozostają jednak odpowiednio przygotowane reguły i przewidywalna struktura źródeł. Narzędzie nie rozpozna samodzielnie znaczenia każdej kolumny ani nie naprawi wszystkich błędów. Dobrze zbudowany proces ogranicza natomiast ręczne interwencje i pozwala poświęcić więcej czasu na analizę, zamiast na ponowne składanie danych.

Źródła danych w Power Query: Folder, SharePoint, CSV/XLSX, bazy danych i API — kiedy które wybrać?

Wybór źródła w Power Query zależy przede wszystkim od tego, gdzie powstają dane i w jaki sposób są udostępniane. Jeśli masz dostęp do bazy, z której korzysta system sprzedażowy, regularne eksportowanie raportów do Excela może być zbędnym etapem. Jeśli jednak otrzymujesz zestawienia od wielu oddziałów jako osobne pliki, właściwym punktem wejścia będzie folder lub biblioteka dokumentów SharePoint.

W Cognity często słyszymy pytania, jak dobrać źródło danych w Power Query do konkretnego zadania — odpowiadamy na nie także na blogu. Warto zacząć od rozróżnienia: Folder i SharePoint wskazują miejsce przechowywania plików, natomiast CSV i XLSX określają ich format. Nie są więc konkurencyjnymi opcjami. Power Query może pobierać na przykład pliki CSV z folderu sieciowego albo skoroszyty XLSX z biblioteki SharePoint.

Folder — gdy dane przychodzą w kolejnych plikach

Łącznik Folder sprawdza się przy cyklicznych eksportach: miesięcznych raportach sprzedaży, dziennych zestawieniach zamówień czy plikach przekazywanych przez poszczególne placówki. Zamiast wskazywać każdy dokument osobno, wybierasz katalog zawierający cały zbiór. Może to być folder lokalny lub dostępny zasób sieciowy.

Wybierz Folder, gdy pliki tworzą jedną serię danych i mają podobny układ. To dobry wybór dla powtarzalnego procesu opartego na eksportach. Sam wspólny katalog nie oznacza jednak, że wszystkie znajdujące się w nim dokumenty nadają się do połączenia — raport sprzedaży i zestawienie stanów magazynowych nadal reprezentują różne zbiory.

SharePoint — gdy pliki są współdzielone w Microsoft 365

Łącznik Folder programu SharePoint służy do pobierania plików z bibliotek dokumentów SharePoint. Jest przydatny, gdy zespół pracuje na wspólnych raportach przechowywanych w chmurze, również w kanałach Microsoft Teams, których pliki są zapisywane w SharePoint.

Wybierz SharePoint, gdy źródłem ma być wspólna biblioteka, a nie lokalna kopia na komputerze jednej osoby. Bezpośrednie połączenie z witryną pozwala uniknąć uzależnienia zapytania od indywidualnej ścieżki folderu synchronizowanego. Jeżeli dane są zapisane jako lista SharePoint, a nie dokumenty, właściwym wyborem jest odrębny łącznik do list.

CSV i XLSX — gdy pracujesz na konkretnych plikach

Bezpośrednie połączenie z plikiem ma sens, gdy źródłem jest pojedynczy eksport lub stale aktualizowany skoroszyt. CSV dobrze nadaje się do wymiany prostych danych tabelarycznych między systemami. Nie przechowuje arkuszy ani formatowania komórek, ale przy imporcie wymaga poprawnego rozpoznania separatora i kodowania znaków.

XLSX wybierz, gdy dane są przygotowywane i utrzymywane w Excelu. Skoroszyt może zawierać wiele arkuszy i tabel, dlatego trzeba wskazać właściwy obiekt. Najwygodniejsze są źródła o czytelnym, tabelarycznym układzie; dokument zaprojektowany głównie do wydruku, z rozbudowanymi nagłówkami i podsumowaniami, zwykle wymaga więcej przygotowania.

Bazy danych — gdy potrzebujesz danych bezpośrednio z systemu

Połączenie z bazą, na przykład SQL Server, PostgreSQL lub Oracle, pozwala pobierać dane bez pośredniego eksportu do pliku. To naturalny wybór dla raportów opartych na centralnych, regularnie aktualizowanych zbiorach. W zależności od łącznika i sposobu przygotowania zapytania część operacji może zostać wykonana po stronie bazy, co ma znaczenie przy większych wolumenach.

Wybierz bazę danych, gdy masz uprawniony dostęp do potrzebnych tabel lub widoków. W środowisku firmowym warto korzystać z obiektów przeznaczonych do raportowania i uzgodnić zakres dostępu z administratorem. Dostępność łączników oraz wymagania dotyczące sterowników zależą od używanego środowiska.

API — gdy aplikacja udostępnia dane przez interfejs

API jest przydatne wtedy, gdy dane znajdują się w aplikacji internetowej, np. systemie CRM, platformie e-commerce lub narzędziu marketingowym, a nie masz dostępu do jej bazy. Power Query może korzystać z dedykowanego łącznika, jeśli taki istnieje, albo pobierać dane przez łącznik internetowy. Odpowiedzi często mają format JSON.

Wybierz API, gdy dostawca usługi udostępnia udokumentowany interfejs obejmujący potrzebne dane. Przed wyborem sprawdź sposób uwierzytelniania, limity zapytań, zakres dostępnej historii i ewentualne ograniczenia planu abonamentowego. API nie zawsze zwraca cały zbiór naraz — może dzielić wyniki na strony, co trzeba uwzględnić przy ocenie nakładu pracy nad integracją.

Łączenie wielu plików z folderu lub SharePoint: „Combine Files” i rola funkcji transformacji

Gdy co miesiąc otrzymujesz kolejny plik z danymi w tym samym układzie, nie musisz otwierać go i kopiować wierszy do zbiorczego arkusza. Funkcja Połącz pliki (Combine Files) pozwala zdefiniować sposób odczytu jednego pliku, zastosować go do pozostałych i zebrać wyniki w jednej tabeli. Przy kolejnym odświeżeniu Power Query ponownie odczyta listę plików i uwzględni nowe pozycje spełniające warunki zapytania.

Ten mechanizm sprawdza się przede wszystkim przy plikach o zgodnej strukturze, na przykład miesięcznych eksportach CSV lub skoroszytach zawierających tak samo nazwane tabele. Nie rozpoznaje natomiast automatycznie znaczenia dowolnych arkuszy i nie dopasowuje bezbłędnie różnych układów raportów.

Najpierw wybierz pliki, dopiero potem je połącz

Dla plików dostępnych na dysku lub w lokalizacji sieciowej wybierz w Excelu albo Power BI konektor Folder. Dla biblioteki dokumentów w SharePoint użyj konektora Folder programu SharePoint (SharePoint Folder), podając adres witryny, a nie link udostępniania pojedynczego dokumentu. W obu przypadkach punktem wyjścia jest tabela z listą plików oraz ich metadanymi.

Warto najpierw wybrać Przekształć dane, zamiast od razu łączyć całą zawartość. Konektor Folder może uwzględniać również podfoldery, a konektor SharePoint Folder zwraca pliki dostępne w obrębie wskazanej witryny. Bez zawężenia listy do wyniku mogą trafić archiwalne eksporty, kopie robocze lub dokumenty z innej biblioteki.

• Folder Path pozwala ograniczyć wybór do właściwej ścieżki. Warunek „równa się” wskazuje konkretny folder, a „zaczyna się od” może objąć także jego podfoldery.
• Extension służy do wybrania odpowiedniego formatu, np. wyłącznie plików CSV.
• Name pomaga wskazać właściwe raporty i odrzucić pliki tymczasowe, w tym pliki Excela o nazwach zaczynających się od ~$.

Takie filtrowanie dotyczy jeszcze listy plików, nie ich zawartości. Dopiero po nim uruchom polecenie łączenia przy kolumnie Content, która przechowuje zawartość każdego pliku w postaci binarnej.

Co ustalasz w oknie „Combine Files”?

Power Query potrzebuje pliku przykładowego, na podstawie którego przygotuje sposób odczytu danych. Domyślnie może to być pierwszy plik z listy, ale warto świadomie wybrać taki, który reprezentuje standardowy układ raportu — nie pusty szablon ani wyjątkowy eksport.

Dla skoroszytów XLSX wskazujesz obiekt do pobrania, na przykład konkretną tabelę lub arkusz. Dla CSV istotne są ustawienia interpretacji pliku, takie jak separator i kodowanie. Wybrany sposób odczytu zostanie zastosowany do wszystkich plików. Jeśli zapytanie odwołuje się do tabeli o określonej nazwie, powinna ona występować również w pozostałych skoroszytach.

Jaką strukturę zapytań tworzy Power Query?

Po zatwierdzeniu operacji w panelu zapytań pojawia się kilka powiązanych elementów. Ich nazwy mogą różnić się zależnie od wersji i języka aplikacji, ale pełnią te same zasadnicze role:

• Plik przykładowy i parametr dostarczają zawartość używaną do przygotowania oraz sprawdzenia sposobu odczytu.
• Zapytanie transformacji pliku przykładowego zawiera kroki wykonywane na pojedynczym pliku.
• Funkcja transformacji przyjmuje zawartość kolejnego pliku i wykonuje na niej zdefiniowane operacje.
• Zapytanie główne wywołuje funkcję dla każdego wybranego pliku, a następnie rozwija otrzymane tabele do wspólnego wyniku.

Gdzie wprowadzać zmiany?

Jeżeli określona operacja ma być wykonywana osobno w każdym pliku, dodaj ją w zapytaniu transformacji pliku przykładowego. Dotyczy to na przykład pominięcia wierszy opisowych poprzedzających właściwą tabelę. W standardowo wygenerowanej strukturze zmiany tego zapytania są przenoszone do powiązanej funkcji — nie trzeba powtarzać ich dla każdego źródłowego dokumentu.

Zapytanie główne pozostaje miejscem wyboru plików oraz operacji dotyczących już zbiorczego wyniku. Warto zachować w nim kolumnę z nazwą pliku źródłowego: ułatwia ustalenie, skąd pochodzą konkretne wiersze. Po zmianie zestawu kolumn zwróć też uwagę na krok rozwijania tabel, ponieważ może on nadal odwoływać się do wcześniejszej listy pól. Samo dodanie kolumny w jednym z plików nie gwarantuje więc, że pojawi się ona w wyniku.

Transformacje i standaryzacja danych: typy, kolumny, czyszczenie, unifikacja schematów i obsługa braków

Dwie tabele mogą wyglądać identycznie, a mimo to zawierać dane, których nie da się poprawnie porównać. W jednej kwota jest liczbą, w drugiej tekstem. Kod produktu raz ma postać „00125”, a raz „125”. Pusta komórka może oznaczać brak informacji albo wartość, która nie dotyczy danego rekordu. Standaryzacja w Power Query polega na nadaniu danym wspólnej struktury i jednoznacznego znaczenia — zanim trafią do obliczeń i raportów. W Cognity omawiamy standaryzację danych zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.

Typy danych: ustalaj je świadomie, nie tylko automatycznie

Power Query potrafi automatycznie rozpoznawać typy, ale wynik takiego rozpoznania wymaga sprawdzenia. Typ powinien wynikać z roli kolumny, a nie wyłącznie z wyglądu jej wartości. Identyfikator złożony z cyfr nie musi być liczbą: kody pocztowe, numery dokumentów i indeksy produktów zwykle należy przechowywać jako tekst. Dzięki temu zachowasz zera wiodące — pod warunkiem, że nie zostały utracone wcześniej, na przykład w pliku źródłowym.

Jeśli liczby lub daty zapisano jako tekst w innej konwencji językowej, skorzystaj z opcji zmiany typu z użyciem ustawień regionalnych. Pozwala ona wskazać sposób interpretacji wartości. Samo formatowanie komórki w Excelu nie zastępuje poprawnego typu danych w zapytaniu.

Kolumny i schemat: zdefiniuj wspólny układ danych

Ustal docelowy zestaw kolumn: ich nazwy, znaczenie, typy oraz to, które są wymagane. Nagłówki „Data sprzedaży” i „SaleDate” można sprowadzić do jednej nazwy, jeżeli opisują to samo zdarzenie. Nie należy natomiast utożsamiać daty wystawienia dokumentu z datą płatności tylko dlatego, że obie kolumny zawierają daty.

Usuń pola niepotrzebne w analizie, a informacje zapisane wspólnie rozdziel, jeśli będą wykorzystywane osobno. Przykładowo warto oddzielić kwotę od oznaczenia waluty. Zgodność schematu oznacza zgodność znaczenia danych, nie tylko nagłówków: kwoty netto i brutto albo ilości wyrażone w sztukach i opakowaniach wymagają odrębnego traktowania lub jawnej reguły przeliczenia.

Określ także reakcję na zmiany w źródle. Brak kolumny opcjonalnej można obsłużyć przez dodanie jej z wartościami null. Brak pola wymaganego powinien zostać ujawniony, zamiast prowadzić do raportu, który wygląda poprawnie, lecz jest niekompletny. Dodatkowe kolumny warto zachowywać lub pomijać według świadomie przyjętej reguły.

Czyszczenie tekstu: podobny wygląd nie gwarantuje równości

W polach tekstowych przydatne są operacje przycinania białych znaków na początku i końcu wartości oraz usuwania znaków niedrukowalnych. Nie rozwiązują jednak każdego problemu: twarde spacje lub niestandardowe separatory mogą wymagać osobnej zamiany. Ujednolicenie wielkości liter ma sens w kategoriach i kodach tylko wtedy, gdy jej rozróżnienie nie niesie informacji.

Stosuj zamiany możliwie precyzyjnie. Zastąpienie całej etykiety „w trakcie” etykietą „W realizacji” jest bardziej przewidywalne niż globalna zamiana fragmentu tekstu we wszystkich kolumnach. Zachowuj też rozróżnienia istotne biznesowo — podobne nazwy statusów nie zawsze oznaczają ten sam stan.

Braki i błędy: nie zastępuj wszystkiego zerem

W Power Query null, pusty tekst i błąd to różne sytuacje. null oznacza brak wartości, pusty tekst jest wartością tekstową o zerowej długości, a błąd może powstać na przykład przy próbie przekształcenia napisu „brak” w liczbę. Każdy przypadek wymaga odpowiedniej reguły:

• Brak wartości: pozostaw null, jeśli informacja jest nieznana. Zamiana na zero może zaniżyć średnią i błędnie sugerować, że pomiar został wykonany.
• Puste teksty i umowne oznaczenia: sprowadź je do null dopiero po potwierdzeniu, że rzeczywiście oznaczają brak danych.
• Błędy konwersji: sprawdź problematyczne rekordy. Przyczyną może być niewłaściwy typ, konwencja regionalna lub niepoprawny zapis w źródle.
• Uzupełnianie w dół: stosuj je tylko wtedy, gdy układ danych jednoznacznie wskazuje, że wartość z poprzedniego wiersza obowiązuje także w kolejnych.

Po transformacjach sprawdź jakość, rozkład i profil kolumn w edytorze Power Query. Zwróć uwagę na zakres profilowania: domyślnie obejmuje ono pierwsze 1000 wierszy, ale można przełączyć je na cały zestaw danych. Pozwala to wykryć braki i błędy, które nie pojawiły się w początkowym podglądzie.

Scalanie (Merge) vs dołączanie (Append): klucze, relacje, deduplikacja i typowe pułapki

Raporty sprzedaży z kolejnych miesięcy trzeba zwykle ułożyć jeden pod drugim. Dane sprzedażowe i kartotekę produktów — połączyć na podstawie identyfikatora produktu. W Power Query odpowiadają za to dwie różne operacje: dołączanie (Append) dodaje wiersze, a scalanie (Merge) dopasowuje rekordy według wskazanych kolumn. Wybór zależy więc nie od tego, skąd pochodzą dane, lecz od tego, jaki wynik chcesz uzyskać.

Dołączanie: wspólny zbiór, ale bez automatycznej deduplikacji

Append sprawdza się wtedy, gdy tabele opisują ten sam rodzaj zdarzeń i mają tę samą szczegółowość, np. jeden wiersz oznacza jedną pozycję zamówienia. Power Query przyporządkowuje dane według nazw kolumn. Jeśli kolumna występuje tylko w części tabel, wynik nadal ją zawiera, a dla pozostałych wierszy pojawia się wartość null.

Dołączanie nie sprawdza, czy dany rekord już istnieje. Połączenie raportu miesięcznego z raportem narastającym może zatem podwoić część transakcji. Przed operacją warto ustalić, czy zakresy danych są rozłączne. Nie należy też bezpośrednio dołączać miesięcznych podsumowań do szczegółowych pozycji sprzedaży — późniejsze sumowanie takiego zbioru prowadzi do błędnych wyników.

Scalanie: klucz i liczba dopasowań decydują o wyniku

Merge wymaga wskazania kolumn, których wartości identyfikują pasujące rekordy. Najbezpieczniej używać stabilnych identyfikatorów, np. numeru produktu, zamiast opisowych nazw. Jeśli jedna kolumna nie wystarcza, można zastosować klucz złożony, np. numer zamówienia i numer pozycji. Kolumny trzeba zaznaczyć w odpowiadającej sobie kolejności w obu tabelach; zgodne muszą być także ich typy danych i sposób zapisu wartości.

Przy wzbogacaniu transakcji o dane słownikowe zwykle oczekujesz relacji wiele do jednego: wiele transakcji może dotyczyć jednego produktu, ale jego identyfikator powinien występować w kartotece tylko raz. Jeśli kartoteka zawiera trzy pasujące rekordy, rozwinięcie kolumny utworzonej przez Merge da trzy wiersze dla jednej transakcji. Suma sprzedaży może wtedy wzrosnąć, mimo że żaden nowy zakup nie nastąpił.

Znaczenie ma również rodzaj złączenia:

• Lewe zewnętrzne (Left Outer) zachowuje wszystkie wiersze pierwszej tabeli; przy braku dopasowania rozwinięte pola drugiej tabeli mają wartości null.
• Wewnętrzne (Inner) pozostawia tylko dopasowane rekordy — może więc usunąć z wyniku transakcje bez odpowiednika w słowniku.
• Lewe anty (Left Anti) zwraca wiersze pierwszej tabeli bez dopasowania w drugiej, co pomaga wykryć brakujące pozycje w kartotece.

Scalenie zapytań nie tworzy przy tym relacji w modelu danych. To operacja przygotowująca wynikową tabelę, a nie mechanizm łączenia tabel podczas analizy.

Deduplikacja: najpierw ustal, co oznacza duplikat

Dwa wiersze z tym samym identyfikatorem klienta nie muszą być duplikatami — mogą opisywać różne zamówienia. Usuwanie powtórzeń powinno opierać się na kluczu właściwym dla szczegółowości danych. Jeśli rekordy o tym samym kluczu różnią się pozostałymi wartościami, potrzebna jest reguła wyboru, np. zachowanie wersji z najnowszą datą aktualizacji.

Nie zakładaj, że polecenie usuwania duplikatów zachowa pierwszy widoczny wiersz, nawet po wcześniejszym sortowaniu. Power Query nie gwarantuje takiego wyboru. Regułę rozstrzygania konfliktów trzeba zdefiniować jawnie, zamiast usuwać powtórzenia wyłącznie po to, by scalanie przestało mnożyć rekordy.

Po połączeniu porównaj liczbę wierszy, liczbę niedopasowanych kluczy i sumy kontrolne. Przy lewym scaleniu transakcji z unikalnym słownikiem produktów liczba wierszy po rozwinięciu oraz suma sprzedaży powinny pozostać bez zmian. To prosty test, który pozwala wychwycić błędy niewidoczne w samym podglądzie tabeli.

6. Parametryzacja i automatyzacja: parametry, funkcje, dynamiczne ścieżki/URL, prywatność i poświadczenia

Jeżeli zmiana lokalizacji plików wymaga poprawiania kilku zapytań, proces nadal jest podatny na ręczne błędy. W Power Query warto oddzielić ustawienia źródeł od logiki przetwarzania. Parametry przechowują zmienne wartości, funkcje pozwalają wielokrotnie wykorzystywać tę samą logikę, a ustawienia prywatności i poświadczenia określają warunki dostępu do danych.

Parametry: jedna zmiana zamiast edycji wielu zapytań

Parametr to nazwana wartość, do której można odwoływać się w kodzie M. Może przechowywać ścieżkę folderu, adres serwera, nazwę bazy, identyfikator zasobu lub datę graniczną. Parametry tworzy się w edytorze Power Query przez opcję Zarządzaj parametrami, określając między innymi typ danych i bieżącą wartość.

Przykładowo parametr pFolder może wskazywać katalog z plikami wejściowymi. Zamiast wpisywać jego ścieżkę bezpośrednio w każdym zapytaniu, wystarczy odwołanie:

Folder.Files(pFolder)

Po przeniesieniu danych zmieniasz wartość parametru, a nie każde zależne zapytanie. Podobnie można przygotować rozwiązanie do przełączania między środowiskiem testowym i produkcyjnym. Parametr sam nie wykrywa jednak zmian ani nie uruchamia zapytania — jest ustawieniem wykorzystywanym podczas jego wykonania.

Funkcje: ta sama operacja dla różnych wartości

Parametr odpowiada na pytanie „jakiej wartości użyć?”, a funkcja — „jaką operację wykonać dla przekazanego argumentu?”. Funkcja przydaje się wtedy, gdy identyczną procedurę trzeba zastosować do wielu elementów, na przykład pobrać dane z API dla kolejnych identyfikatorów lub okresów.

Zamiast utrzymywać osobne zapytanie dla każdego identyfikatora, można przekazywać kolejne wartości do jednej funkcji. Jej późniejsza poprawka obowiązuje we wszystkich miejscach, które ją wywołują. Warto przy tym jasno określić oczekiwane argumenty, ich typy oraz zachowanie przy pustej wartości. Przy pobieraniu danych z API trzeba też pamiętać, że wiele wywołań funkcji może oznaczać wiele żądań do serwera — funkcja ogranicza powielanie kodu, ale niekoniecznie liczbę operacji.

Dynamiczne ścieżki i URL: zmieniaj tylko potrzebne elementy

Ścieżkę do pliku można budować z katalogu bazowego i zmiennej nazwy pliku. Dobrze jednak przechowywać katalog w jednym miejscu oraz konsekwentnie obsługiwać separatory. Lokalizacja działająca na komputerze autora nie musi być dostępna w innym środowisku wykonania.

Przy zapytaniach HTTP lepiej, gdy to możliwe, pozostawić stały adres bazowy, a zmienne fragmenty przekazywać przez opcje RelativePath i Query funkcji Web.Contents. Przykład z parametrem pRok:

Web.Contents(
    "https://api.example.org",
    [
        RelativePath = "reports",
        Query = [year = Text.From(pRok)]
    ]
)

To wzorzec konstrukcji zapytania, nie adres rzeczywistej usługi. Opcja Query pomaga poprawnie zakodować wartości parametrów URL. Stała baza ułatwia również rozpoznanie źródła przez Power BI Service; składanie całego adresu dynamicznie może powodować ograniczenia przy wykonywaniu zapytania w usłudze. Sam ten wzorzec nie gwarantuje jednak zgodności z każdym API.

Prywatność i poświadczenia: dwa różne zadania

Poświadczenia potwierdzają prawo dostępu do źródła. Poziomy prywatności określają natomiast, jak Power Query może izolować dane podczas łączenia źródeł. Oznaczenia „Publiczne”, „Organizacyjne” i „Prywatne” nie zastępują uprawnień w bazie, SharePoint ani API.

Niezgodne ustawienia prywatności mogą zablokować wykonanie zapytania, między innymi komunikatem Formula.Firewall. Nie należy traktować wyłączenia kontroli prywatności jako standardowej naprawy: mechanizm ten pomaga zapobiegać niezamierzonemu przekazaniu danych z jednego źródła do drugiego.

Hasła, tokeny i klucze API nie powinny trafiać do zwykłych parametrów ani bezpośrednio do kodu M. Parametr nie jest magazynem sekretów. Korzystaj z mechanizmów uwierzytelniania właściwych dla danego łącznika. Po zmianie adresu źródła sprawdź ustawienia dostępu — poświadczenia przypisane do poprzedniej lokalizacji mogą nie obejmować nowej, a udostępnienie skoroszytu lub raportu nie nadaje odbiorcy uprawnień do danych.

Odświeżanie i publikacja: harmonogramy, incremental refresh, wydajność i monitoring błędów

Połączenie danych z wielu źródeł przynosi trwałą oszczędność czasu dopiero wtedy, gdy kolejne aktualizacje nie wymagają ręcznej obsługi. Power Query zapisuje sposób pobrania i przekształcenia danych, ale to środowisko, w którym działa zapytanie, decyduje o możliwościach odświeżania. Dlatego przed udostępnieniem raportu trzeba ustalić, gdzie będzie aktualizowany, jak często i kto zareaguje na nieudane wykonanie.

Odświeżanie w Excelu a harmonogram w Power BI

W klasycznym Excelu zapytania można uruchamiać poleceniem „Odśwież wszystko”. Dla obsługiwanych połączeń dostępne są również ustawienia odświeżania przy otwarciu pliku lub w określonych odstępach podczas pracy z otwartym skoroszytem. Nie jest to jednak harmonogram działający niezależnie od uruchomionego Excela. Samo zapisanie pliku na dysku współdzielonym nie zapewnia cyklicznej aktualizacji jego danych.

W Power BI po opublikowaniu modelu semantycznego w usłudze można skonfigurować odświeżanie zaplanowane. Trzeba przy tym zapewnić dostęp do źródeł i poprawne uwierzytelnianie. Źródła lokalne, takie jak folder na firmowym serwerze lub baza niedostępna bezpośrednio z chmury, zwykle wymagają bramy danych. Komputer obsługujący bramę musi pozostawać dostępny w czasie odświeżania. Dostępna częstotliwość aktualizacji zależy m.in. od licencji i pojemności Power BI.

Harmonogram warto dopasować do momentu gotowości danych, a nie tylko do godziny rozpoczęcia pracy odbiorców. Jeśli pliki trafiają do folderu partiami, aktualizacja uruchomiona w połowie dostawy może zakończyć się bez błędu, lecz uwzględnić niekompletny zestaw danych. Pomaga ustalone okno publikacji z buforem na opóźnienia.

Incremental refresh: aktualizacja tylko potrzebnego zakresu

Przy dużych zbiorach ponowne wczytywanie całej historii bywa niepotrzebnie kosztowne. Odświeżanie przyrostowe w Power BI pozwala przechowywać dane historyczne, a podczas kolejnych aktualizacji przetwarzać przede wszystkim wyznaczony, nowszy zakres. Przykładowo model może zachowywać kilka lat sprzedaży, ale regularnie odświeżać tylko ostatnie tygodnie. Pierwsze załadowanie historii nadal może być czasochłonne.

To rozwiązanie sprawdza się szczególnie wtedy, gdy dane mają wiarygodną kolumnę daty, a źródło umożliwia sprawne pobieranie wybranego okresu. Nie jest to uniwersalny przełącznik przyspieszający każde zapytanie. Jeśli przy odczycie plików i tak trzeba przejrzeć cały zbiór, korzyść może być ograniczona. Trzeba też uwzględnić spóźnione korekty: zmiany poza zakresem odświeżania nie zostaną automatycznie pobrane przy zwykłej aktualizacji przyrostowej.

Wydajność oceniaj w docelowym środowisku

Szybki podgląd w edytorze nie oznacza, że pełne odświeżenie będzie równie sprawne. Przed udostępnieniem raportu należy sprawdzić czas przetwarzania całego zbioru, obciążenie źródła oraz działanie bramy. W przypadku baz danych istotne jest zachowanie query folding, czyli przekazywania obsługiwanych operacji do wykonania po stronie źródła. Ograniczanie pobieranych danych do potrzebnego zakresu zwykle pomaga bardziej niż samo zwiększanie częstotliwości odświeżania.

Monitoring: kontroluj błędy i rzeczywistą aktualność danych

W Power BI podstawą kontroli jest historia odświeżania oraz powiadomienia o niepowodzeniach. Warto wyznaczyć osobę odpowiedzialną za ich obsługę i obserwować nie tylko błędy, lecz także wydłużający się czas wykonania. Może on sygnalizować wzrost wolumenu danych, przeciążenie źródła lub problemy z bramą.

Status „zakończono pomyślnie” potwierdza wykonanie procesu, nie kompletność danych. Dlatego obok daty ostatniego odświeżenia warto kontrolować najnowszą datę danych, liczbę wczytanych rekordów oraz obecność oczekiwanych plików. Takie kontrole pozwalają wychwycić sytuację, w której raport działa technicznie poprawnie, ale nadal pokazuje nieaktualny lub niepełny obraz.

Kontrola jakości danych: konsolidacja miesięcznych raportów do jednej tabeli krok po kroku

Poprawne wykonanie zapytania nie oznacza jeszcze, że raport zawiera poprawne dane. Power Query może połączyć pliki bez komunikatu o błędzie, mimo że w folderze brakuje jednego miesiąca, ten sam raport został zapisany dwukrotnie albo część kwot pozostała pusta. Dlatego konsolidację warto zakończyć nie tylko załadowaniem tabeli, lecz także sprawdzeniem jej kompletności i zgodności ze źródłami.

Kontrola techniczna odpowiada na pytanie, czy dane dało się odczytać i przetworzyć. Kontrola biznesowa sprawdza, czy wynik ma sens: obejmuje właściwe okresy, nie zawiera nieuzasadnionych powtórzeń i zachowuje wartości z raportów wejściowych. Obie są potrzebne — brak błędów konwersji nie potwierdza poprawności zestawienia.

Co sprawdzić przed wykorzystaniem połączonych danych?

W edytorze Power Query pomocne są narzędzia profilowania dostępne na karcie Widok: jakość kolumn, rozkład kolumn i profil kolumny. Pozwalają zauważyć między innymi błędy, puste wartości oraz nietypowy rozkład danych. Domyślnie profilowanie obejmuje pierwsze 1000 wierszy. Przed końcową oceną przełącz je na cały zestaw danych, pamiętając, że przy większych zbiorach analiza może potrwać dłużej.

Interpretacja wyników wymaga znajomości raportu. Pusta uwaga do transakcji może być dopuszczalna, ale brak identyfikatora dokumentu lub daty sprzedaży powinien trafić do wyjaśnienia. Podobnie ujemna kwota nie musi oznaczać błędu — może dotyczyć korekty. Reguły jakości powinny wynikać ze znaczenia danych, a nie wyłącznie z ich wyglądu.

Przykład: miesięczne raporty sprzedaży w jednej tabeli

Załóżmy, że każdy plik XLSX zawiera raport za jeden miesiąc, a pojedynczy wiersz opisuje pozycję dokumentu sprzedaży. Raporty mają kolumny: numer dokumentu, numer pozycji, data sprzedaży, kod produktu i kwota netto. Kwoty są wyrażone w jednej walucie. Celem jest uzyskanie wspólnej tabeli oraz potwierdzenie, że podczas łączenia nie pominięto ani nie powielono danych.

1. Ustal oczekiwany zakres. Przygotuj listę miesięcy objętych zestawieniem i wskaż właściwy plik dla każdego okresu. Sprawdź, czy w zbiorze nie ma kopii, wersji roboczych ani plików tymczasowych. Sama zgodność liczby plików nie wystarczy: dwa raporty ze stycznia mogą ukryć brak raportu z lutego.
2. Zapisz wartości kontrolne ze źródeł. Dla każdego raportu zanotuj liczbę pozycji sprzedaży oraz sumę kwoty netto, bez nagłówków i wierszy podsumowań. Będą punktem odniesienia dla wyniku konsolidacji. Jeżeli źródła zawierają różne waluty, uzgadniaj kwoty osobno dla każdej z nich.
3. Połącz raporty i zachowaj informację o pochodzeniu. W wynikowym zapytaniu pozostaw nazwę pliku źródłowego. Ułatwi to przypisanie brakującej kwoty lub błędnej daty do konkretnego raportu. Zweryfikuj również zgodność okresu wskazanego w nazwie pliku z datami w jego zawartości, jeśli zgodnie z przyjętą zasadą raport ma obejmować wyłącznie dany miesiąc.
4. Sprawdź pola wymagane i błędy. Skontroluj kompletność numerów dokumentów, numerów pozycji, dat oraz kwot. Wiersze wymagające wyjaśnienia wydziel do osobnego zapytania kontrolnego. Nie usuwaj ich automatycznie tylko po to, by wynik nie zawierał błędów — mogłoby to zaniżyć sprzedaż.
5. Zweryfikuj powtórzenia na właściwym poziomie. W tym przykładzie numer dokumentu może występować wielokrotnie, ponieważ dokument zawiera kilka pozycji. Potencjalne duplikaty sprawdzaj więc według uzgodnionego klucza, na przykład numeru dokumentu i numeru pozycji, jeżeli taka para jest unikalna w całym analizowanym zbiorze. Powtórzenia najpierw wyjaśnij, zamiast od razu je usuwać.
6. Uzgodnij wynik z raportami wejściowymi. Porównaj liczbę wierszy i sumę netto dla każdego pliku oraz miesiąca z wartościami zapisanymi wcześniej. Kontrola wyłącznie sumy końcowej jest niewystarczająca: brak danych w jednym okresie może zostać zamaskowany ich nadmiarem w innym.

Kiedy uznać konsolidację za poprawną?

Tabela jest gotowa do analizy, gdy obejmuje wszystkie oczekiwane okresy, wartości kontrolne zgadzają się ze źródłami, a wykryte wyjątki zostały wyjaśnione. Jeśli część wierszy świadomie wykluczono, zachowaj ich liczbę, wartość i powód wyłączenia — różnica powinna być możliwa do rozliczenia.

Kontrole warto pozostawić jako osobne zapytania odświeżane razem z danymi. Po dodaniu kolejnego raportu sprawdzisz wtedy nie tylko, czy pojawił się nowy miesiąc, ale również czy wcześniejsze okresy nie zmieniły się nieoczekiwanie. To pozwala powtarzać konsolidację bez ręcznego kopiowania, nie rezygnując z odpowiedzialności za jakość wyniku.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy temat łączenia i kontroli jakości danych w praktyce.

Power BI zaawansowany – jak tworzyć profesjonalne modele danych 03 października 2026

Power BI zaawansowany – DAX w praktyce: miary, kalkulacje i analiza danych 01 października 2026