Power Query pozwala budować bardzo rozbudowane procesy przygotowania danych, ale domyślnie wiele rzeczy wpisuje się „na sztywno”: ścieżkę do pliku, konkretną datę, nazwę klienta czy liczbę dni wstecz. Taki kod działa, dopóki środowisko się nie zmieni. Wystarczy przenieść plik Excela do innego folderu albo wskazać nowy katalog z CSV i cała konstrukcja wymaga ręcznej edycji kroków w edytorze zapytań.
Parametry w Power Query są sposobem na wyciągnięcie takich zmiennych elementów na zewnątrz. Zamiast wpisywać ścieżkę w kodzie M, podaje się ją w polu „Wartość” parametru. Zamiast zmieniać datę w kroku filtra, zmienia się wartość parametru daty. Zapytanie pozostaje identyczne, modyfikuje się tylko konfiguracja. To szczególnie przydatne, gdy raport ma służyć miesiącami lub latami, a zmieniają się tylko warunki wejściowe.
Różnica jest podobna jak między formułą Excela z wpisaną liczbą (np. =A1*1,23) a formułą bazującą na komórce konfiguracyjnej (np. =A1*$B$1). W obu przypadkach wynik da się uzyskać, ale druga wersja jest znacznie bardziej odporna na zmiany i łatwiejsza do utrzymania.
Typowe scenariusze użycia parametrów
Parametry Power Query najwięcej dają w powtarzalnych procesach, gdzie zmieniają się pojedyncze warunki wejściowe. Najczęściej spotykane zastosowania to:
zmiana folderu z plikami – jeden zestaw kroków do łączenia i czyszczenia plików CSV/XLSX, ale dla różnych klientów lub okresów dane przechowywane są w innych katalogach;
zakres dat – raport sprzedaży, który ma pokazywać „ostatnie X dni” lub okres od–do definiowany poza edytorem zapytań;
wybór klienta/regionu – ten sam model danych, ale filtrowany w zależności od wybranego kontrahenta, oddziału lub kraju;
środowisko test / produkcja – to samo zapytanie, ale wskazujące na bazę testową podczas rozwijania i na bazę produkcyjną podczas pracy użytkowników końcowych;
parametry serwerów i baz SQL – nazwa serwera, bazy, schematu czy katalogu jest przechowywana w parametrach, a zapytania SQL bazują na tych zmiennych.
W każdym z tych przypadków do zmiany konfiguracji nie trzeba otwierać kroków M. Wystarczy zmodyfikować wartości parametrów w menedżerze parametrów lub – w bardziej rozbudowanych rozwiązaniach – w tabeli konfiguracyjnej Excela albo w ustawieniach źródła w Power BI.
Raport bez parametrów kontra raport z jednym parametrem
Najprostsze porównanie: raport zbierający pliki z folderu. W wersji „bez parametrów” w kroku Source pojawia się np.:
Source = Folder.Files("C:Raporty2024Styczen"),
Jeśli w kolejnym miesiącu trzeba przejść na folder Luty, konieczna jest edycja tego kroku lub nagranie wszystkiego od zera, jeśli mniej doświadczony użytkownik boi się modyfikować kod. W wersji z parametrem powstaje parametr pFolderRaportow z wartością domyślną:
"C:Raporty2024Styczen"
W kroku Source zamiast ścieżki pojawia się:
Source = Folder.Files(pFolderRaportow),
Zmiana miesiąca sprowadza się wtedy do podmiany wartości parametru, bez dotykania kroków zapytania. Dodatkowo, gdy struktura katalogów zmieni się po stronie IT, użytkownik biznesowy może samodzielnie wskazać nową ścieżkę bez angażowania osoby, która budowała model.
Kiedy parametry naprawdę pomagają, a kiedy tylko komplikują
Parametry w Power Query wnoszą największą wartość wtedy, gdy:
model jest używany cyklicznie (codziennie, tygodniowo, miesięcznie),
warunki wejściowe zmieniają się przewidywalnie (np. zakres dat, foldery okresowe),
kilka raportów korzysta z tych samych ustawień (np. ta sama baza, różne widoki),
konfiguracja ma być dostępna dla osób nietechnicznych.
Jeśli powstaje jednorazowy raport, do którego dane nigdy nie będą odświeżane, tworzenie parametrów jest zwykle przerostem formy nad treścią. Z kolei przy zbyt agresywnym parametryzowaniu (każdy drobiazg jako osobny parametr) pojawia się odwrotny problem – konfiguracja staje się nieczytelna, a utrzymanie trudniejsze niż przy prostym, „twardym” kodzie.
Dobrym punktem wyjścia jest zasada: parametryzować tylko te elementy, które realnie mogą się zmienić bez zmiany logiki raportu. Liczba kolumn, typy przekształceń czy specyficzne reguły czyszczenia rzadko nadają się na parametry – najczęściej stabilne są przez długi czas. Z kolei ścieżki, daty i identyfikatory środowisk to naturalni kandydaci do uelastycznienia.
Rodzaje parametrów w Power Query – co można kontrolować
Podstawowe typy: tekst, liczba, data i logika
Podczas tworzenia parametru w Power Query trzeba określić jego typ danych. Od tego zależy, czy parametr można wstawić do filtra, ścieżki pliku, wyrażenia M i czy nie pojawią się błędy typów przy odświeżaniu. Najczęściej używane typy to:
Tekst – ścieżki plików, nazwy klientów, kody regionów, identyfikatory baz danych, fragmenty zapytań SQL, prefiksy plików;
Liczba całkowita / liczba dziesiętna – liczba dni wstecz, numer roku, minimalna/ maksymalna wartość w filtrach, wersje;
Data / Data i czas – dokładne daty „od” i „do”, znaczniki aktualizacji, granice filtrów okresów;
Logika (True/False) – proste przełączniki typu „uwzględniaj dane archiwalne”, „tryb testowy”, „łączyć z dodatkowymi plikami” itp.
Zastosowanie odpowiedniego typu parametru upraszcza korzystanie z funkcji M. Przykładowo parametr typu Data można od razu wykorzystać w funkcjach Date.AddDays czy Date.StartOfMonth, bez dodatkowego konwertowania. Z kolei parametr typu liczbowego dobrze współpracuje z Number.From lub jako argument w granicach filtrów.
Listy wartości i parametry z ograniczonym wyborem
Oprócz zwykłej „gołej” wartości, Power Query oferuje parametry oparte na listach. Przy tworzeniu parametru można wybrać:
Wartość dowolna – pełna swoboda, użytkownik wpisuje cokolwiek zgodnego z typem;
Lista wartości – użytkownik wybiera z zamkniętej listy kilku wartości;
Lista sugestii – lista podpowiedzi, ale można wpisać coś spoza niej.
Lista wartości przydaje się szczególnie dla parametrów, które reprezentują niewielki, zamknięty zbiór opcji, np. środowisko DEV/TEST/PROD, rok rozliczeniowy czy typ raportu. Minimalizuje to ryzyko literówek i błędnych wartości, które mogłyby rozbić logikę zapytań.
Listy sugestii są dobrym kompromisem, gdy standardowo używa się kilku powtarzalnych ustawień, ale okazjonalnie trzeba podać wartość niestandardową (np. dodatkowy rok, którego jeszcze nie ma na liście). Daje to większą elastyczność przy zachowaniu „katalogu” najpopularniejszych opcji.
Parametry w filtrach, ścieżkach i wyrażeniach M
Parametry Power Query można wstrzykiwać praktycznie w dowolne miejsce kodu M, o ile wymagana jest wartość zgodna z typem parametru. Typowe zastosowania to:
Filtry – np. Table.SelectRows z użyciem parametrów dat, liczb, tekstów;
Źródła danych – ścieżki folderów, adresy URL, connection stringi, nazwy serwerów SQL;
Wyrażenia M – obliczanie zakresów (ostatnie X dni), budowanie dynamicznych nazw tabel, wybór wariantu logiki w zależności od parametru logicznego;
Parametry zapytań do baz – w wielu konektorach (SQL, OData, Web) parametry można przekazać jako wartości do zapytania lub jako element adresu.
Przykład prostego filtra opartego na parametrach dat:
= Table.SelectRows(
#"Poprzedni krok",
each [Data] >= pDataOd and [Data] <= pDataDo
)
Taki filtr nie wymaga później żadnej edycji w krokach, jeśli zmieniają się tylko granice zakresu. Parametry daty można też połączyć z funkcjami typu Date.AddDays, co pozwala dynamicznie wyznaczać okresy względem daty dzisiejszej.
Stałe konfiguracyjne kontra parametry „interaktywne”
W praktyce dobrze rozdzielić dwa typy parametrów:
Stałe konfiguracyjne – rzadko zmieniane, typowo techniczne (ścieżki, nazwy serwerów, liczba dni wstecz, nazwy baz, flagi środowiskowe);
Parametry interaktywne – zmieniane częściej, często przez użytkownika biznesowego (zakres dat, wybór klienta, wskaźnik „pokazuj archiwalne”).
Stałe konfiguracyjne zwykle są edytowane przez osobę techniczną i mają charakter „ustaw raz, używaj długo”. Parametry interaktywne bywają modyfikowane przy każdym odświeżeniu raportu. To rozróżnienie pomaga utrzymać porządek: parametry konfiguracyjne można trzymać nawet w osobnym zapytaniu lub tabeli, a interaktywne udostępnić użytkownikom w prostszej formie, np. jako pola w panelu konfiguracyjnym Excela.
Porównanie: parametry Power Query, DAX i nazwy zakresów Excela
Parametry w Power Query warto odnieść do innych mechanizmów znanych z Excela i Power BI. Różnice dobrze ilustruje prosta tabela:
Mechanizm
Miejsce działania
Typowa rola
Dla kogo
Parametry Power Query
Etap pobierania i transformacji danych
Źródła, filtry wstępne, logika ETL
Autor modelu, zaawansowany użytkownik
Parametry / miary DAX
Warstwa modelu i wizualizacji
Dynamiczne obliczenia, interaktywne raporty
Projektant raportów, analityk BI
Nazwy zakresów w Excelu
Arkusz kalkulacyjny
Konfiguracja formuł, wartości sterujące
Użytkownik arkusza
Parametry Power Query wpływają na to, jakie dane trafią do modelu i w jakiej postaci. DAX i slicery w Power BI obsługują późniejszą warstwę prezentacji i analityki – pracują na już załadowanych danych. Nazwy zakresów w Excelu pełnią często podobną rolę jak parametry, ale na poziomie formuł arkusza, a nie procesu ETL.
W praktyce te mechanizmy się uzupełniają: parametrem Power Query można ograniczyć wolumen danych (np. tylko ostatni rok), a DAX-em i slicerami pozwalać użytkownikom na elastyczną analizę w tym zawężonym zbiorze, bez przeciążania modelu i czasu odświeżania.
Źródło: Pexels | Autor: Bia Limova
Tworzenie parametrów krok po kroku – interfejs a kod M
Menedżer parametrów – najważniejsze pola i opcje
Parametry można tworzyć zarówno w Excelowym dodatku Power Query, jak i w Power BI Desktop. W obu miejscach służy do tego „Menedżer parametrów” (Manage Parameters). Najważniejsze elementy formularza tworzenia parametru to:
Nazwa – identyfikator parametru w kodzie M, bez spacji i polskich znaków, np. pDataOd, pFolderZrodlowy;
Opis – krótkie wyjaśnienie dla innych użytkowników (np. „Folder z raportami sprzedaży z systemu X”);
Typ – tekst, liczba, data, logika, itp.;
Sugerowany typ wartości – Wartość dowolna, Lista wartości, Lista sugestii; w zależności od wyboru pojawia się pole do zdefiniowania listy;
Wartość domyślna – ustawienie, które będzie stosowane, gdy nie zostanie podana inna wartość;
Wartość bieżąca – aktualne ustawienie używane podczas odświeżania (w niektórych wersjach występuje rozdział na domyślną i bieżącą).
Dobrą praktyką jest stosowanie spójnego prefiksu, np. p dla parametrów (pDataOd, pRok, pTrybTestowy). Pozwala to od razu odróżnić parametr od zwykłego zapytania czy kolumny, zarówno w interfejsie, jak i w kodzie M.
Tryby wartości: dowolna, lista wartości, lista sugestii
Tryby wyboru wartości parametru decydują o tym, jak łatwo (i jak bezpiecznie) będzie można zmienić jego ustawienie:
Wartość dowolna – pełna elastyczność, ale też większe ryzyko błędów poprzez literówki, niepoprawne formaty dat, dodatkowe spacje;
Parametry oparte na tabelach i zapytaniach pomocniczych
Zamiast wpisywać listę wartości ręcznie w Menedżerze parametrów, można ją zbudować jako zwykłe zapytanie (tabelę), a następnie przekształcić w listę. Taka konstrukcja jest elastyczniejsza, bo listę da się odświeżać z pliku, bazy czy innego źródła.
Typowy schemat wygląda tak:
Tworzone jest zapytanie pomocnicze (np. qListaKlientow), które zwraca jedną kolumnę z dopuszczalnymi wartościami.
Ta kolumna jest zamieniana na listę poleceniem = Table.Column(qListaKlientow, „Klient”).
Parametr przyjmuje tę listę jako źródło do opcji „Lista wartości” albo „Lista sugestii”.
Takie podejście ma kilka zalet w porównaniu z ręcznie wpisaną listą:
można utrzymywać listę opcji w centralnym pliku konfiguracyjnym lub w tabeli bazy danych;
przy zmianie oferty, struktury organizacyjnej czy nowym roku rozliczeniowym lista odświeża się automatycznie;
parametr nie wymaga edycji – zmienia się wyłącznie dane źródłowe zapytania pomocniczego.
Sprawdza się to szczególnie w raportach wielooddziałowych, gdzie zestaw „dozwolonych” oddziałów jest przechowywany w tabeli referencyjnej. Parametr wybiera oddział, ale nie trzeba za każdym razem przepisywać nazw jednostek do Menedżera parametrów.
Parametry powiązane – budowanie zależności między wyborami
Często pojawia się potrzeba, by wartość jednego parametru ograniczała możliwe opcje innego. Klasyczny przykład: najpierw wybór kraju, a dopiero potem klienta z danego kraju. Power Query nie oferuje kaskadowych list wprost w interfejsie, jednak zależność da się zbudować na poziomie kodu M.
Prosty wzorzec:
Parametr nadrzędny (np. pKraj) ma listę wartości niezależną od innych ustawień.
Zdefiniowane jest zapytanie qKlienci, które pobiera wszystkich klientów z bazowego źródła.
Powstaje zapytanie pomocnicze qKlienciDlaKraju, filtrujące qKlienci po parametrze pKraj.
Kolumna z nazwami klientów z qKlienciDlaKraju jest używana jako lista wartości dla parametru pKlient.
Efekt jest inny niż w typowym slicerze Power BI: zmiana pKraj wymaga odświeżenia, by zaktualizowała się lista pKlient, ale użytkownik otrzymuje logicznie spójne kombinacje ustawień. Dodatkowo te same parametry mogą równolegle kontrolować zarówno filtry w Power Query, jak i – po zmapowaniu – filtry w warstwie raportowej.
Parametry środowiskowe – DEV, TEST, PROD w jednym pliku
Przy rozwoju raportów ważne jest rozdzielenie środowisk: DEV (tworzenie), TEST (weryfikacja) i PROD (produkcyjne). Parametry w Power Query dobrze nadają się do przełączania między nimi bez przepisywania ścieżek i adresów serwerów.
Proste podejście opiera się na pojedynczym parametrze, np. pSrodowisko z listą wartości:
"DEV"
"TEST"
"PROD"
Następnie w jednym zapytaniu konfiguracyjnym można zdefiniować logikę:
let
Source =
if pSrodowisko = "DEV" then
[Serwer = "DEV-SQL", Baza = "Raport_DEV", Folder = "C:DEVRaporty"]
else if pSrodowisko = "TEST" then
[Serwer = "TEST-SQL", Baza = "Raport_TEST", Folder = "D:TESTRaporty"]
else
[Serwer = "PROD-SQL", Baza = "Raport_PROD", Folder = "prodRaporty"]
in
Source
Inne zapytania odwołują się już tylko do rekordów tego „konfiga”, np. Konfig[Serwer], Konfig[Baza]. W porównaniu ze scenariuszem, gdzie wszystkie ścieżki są wpisane „na sztywno”, zmiana środowiska wymaga teraz wyłącznie przełączenia pSrodowisko.
Kiedy użyć jednego parametru środowiskowego, a kiedy kilku? Dla prostych raportów wystarczy pojedynczy przełącznik DEV/TEST/PROD, który steruje wszystkimi ścieżkami. W bardziej złożonych modelach (różne źródła, inne harmonogramy) praktyczniejsza bywa osobna para parametrów serwer/baza dla każdego systemu źródłowego – daje to większą kontrolę kosztem nieco trudniejszej konfiguracji.
Parametry jako „bezpieczniki” i przełączniki logiki
Parametr logiczny (True/False) może pełnić rolę przełącznika trybu pracy. Zamiast mieć dwa osobne zapytania – jedno „pełne”, a drugie „demo” – można użyć jednego, w którym logika filtrów zależy od parametru.
Przykładowy wzorzec:
let
Zrodlo = ...,
Filtrowanie =
if pTrybDemo then
Table.SelectRows(Zrodlo, each [Data] > Date.AddDays(DateTime.Date(DateTime.LocalNow()), -30))
else
Zrodlo
in
Filtrowanie
Ten sam mechanizm nadaje się do:
włączania/wyłączania drogich kroków (np. grupowań, joinów z dużymi tabelami);
sterowania, czy łączyć z dodatkowymi plikami (archiwum, załączniki);
uruchamiania alternatywnej logiki przetwarzania (np. inny podział na regiony).
W porównaniu z kopiowaniem zapytań i ręcznym przełączaniem źródeł parametry „bezpiecznikowe” ograniczają ryzyko, że część logiki zostanie zaktualizowana tylko w jednym wariancie, a drugi zapomniany. Utrzymywana jest jedna ścieżka M z rozgałęzieniami, kontrolowanymi prostymi flagami.
Parametry a wydajność – filtrowanie przy źródle kontra po załadowaniu
Parametry mogą istotnie wpłynąć na wydajność, jeśli są wykorzystywane do tzw. query folding (składania zapytań do źródła). Różnica polega na tym, gdzie faktycznie wykonuje się filtr:
filtr „składany” – Power Query przekłada warunek na zapytanie SQL/OData/itd., a baza zwraca już przefiltrowane dane;
filtr „nieskładany” – całe źródło jest pobierane, a filtr stosowany dopiero lokalnie.
Parametry użyte w pierwszych krokach (tuż po źródle) zwiększają szansę, że filtr z ich udziałem zostanie złożony do bazy. Przykład różnicy:
Lepszy wariant: najpierw pobranie tabeli z SQL, zaraz potem filtr po pDataOd i pDataDo;
Gorszy wariant: najpierw kilka transformacji lokalnych (dodanie kolumn, sortowania), dopiero później filtr po parametrach dat.
W pierwszym scenariuszu większość pracy wykonuje serwer bazy, a do Power Query trafia już okrojony zestaw. W drugim – nawet dobrze skonstruowany filtr parametrowy może nie zostać „zepchnięty” do źródła, bo wcześniejsze kroki uniemożliwią query folding.
Przy projektowaniu parametrów filtrujących dane z dużych tabel opłaca się:
umieszczać kroki z ich użyciem możliwie najbliżej kroku źródłowego;
unikać transformacji, które przerywają składanie zapytania (niestandardowe funkcje M, niektóre złączenia, krok „Zastąp błędy” w środku potoku);
testować w okienku „Widok natywnego zapytania”, czy parametr jest widoczny w generowanym SQL.
Parametry i łączenie zapytań – dynamiczne zakresy oraz wybór tabel
Parametry przydają się nie tylko w filtrach, ale także przy łączeniu wielu tabel w jedną strukturę. Klasyczny przypadek to miesięczne pliki sprzedażowe w folderze, gdzie:
parametr pLiczbaMiesiecy określa, ile ostatnich plików ma być wczytanych;
parametr pWzorNazwy pozwala ograniczyć pobieranie do plików spełniających wzór (np. „Sprzedaz_*.xlsx”).
W jednym podejściu pliki są łączone „na sztywno” – tzn. wszystkie, z całej historii. W drugim – zakres jest dynamiczny, sterowany parametrami. Z punktu widzenia użytkownika różnica jest taka, że:
przy stałym zestawie plików odświeżanie trwa coraz dłużej, ale nie wymaga ingerencji;
przy parametrach zakres można przyciąć (np. tylko ostatnie 3 miesiące), skracając czas odświeżania i wagę modelu.
Podobnie można parametryzować wybór tabel w bazie. Zamiast mieć trzy niemal identyczne zapytania (FaktSprzedaz_2022, FaktSprzedaz_2023, FaktSprzedaz_2024), można:
utworzyć parametr pRok lub pTabelaFakt (z listą nazw tabel),
w kroku źródłowym odwołać się do pTabelaFakt w funkcji Sql.Database lub analogicznej,
połączyć kilka parametrów w jedną tabelę za pomocą List.Transform i funkcji niestandardowej.
Podejście parametryczne jest bardziej uniwersalne – wspiera zarówno analizę pojedynczego roku (prostota), jak i tworzenie zapytań łączących wiele lat w jedną tabelę faktów (elastyczność).
Przechowywanie konfiguracji parametrów w arkuszu Excela
W środowiskach, gdzie głównym narzędziem nadal jest Excel, wygodnym rozwiązaniem jest wyprowadzenie parametrów do zwykłej tabeli w arkuszu. Użytkownik wypełnia kolumny Nazwa oraz Wartosc, a Power Query odczytuje te dane i buduje z nich zestaw parametrów.
Dwa podejścia:
Parametry systemowe – tworzone „normalnie” w Menedżerze parametrów, ale ich wartości są nadpisywane poprzez wczytanie tabeli konfiguracyjnej i przypisanie do zmiennych w pierwszym kroku zapytania głównego.
Brak formalnych parametrów – wszystko trzymane jest w jednym zapytaniu Konfiguracja, zwracającym rekord (np. [DataOd = #date(…), Klient = „XYZ”]), z którego inne zapytania czytają wartości.
Drugi wariant daje większą elastyczność: nie narzuca typu „parametr” w interfejsie, ale efekt jest podobny – konfiguracja znajduje się „na wierzchu” w Excelu, a w kodzie M jest tylko odczytywana. W porównaniu z edycją wartości bezpośrednio w Menedżerze parametrów, taki panel na arkuszu jest przystępniejszy dla użytkowników biznesowych.
Parametry w Power BI Service – odcięcie od źródeł lokalnych
Jeśli raport z Power BI Desktop jest publikowany do Power BI Service, parametry mogą pomóc przy rozdzieleniu konfiguracji lokalnej i chmurowej. Typowy scenariusz:
W wersji deweloperskiej parametry ścieżek wskazują na lokalne pliki lub instancję SQL na laptopie.
Po publikacji te same parametry są zmieniane w Power BI Service (na stronie datasetu), by wskazać serwer produkcyjny.
W porównaniu z ręcznym edytowaniem pliku PBIX i ponowną publikacją, zmiana parametrów w usłudze bywa wygodniejsza: nie trzeba angażować twórcy modelu do każdej modyfikacji źródeł. Kluczowe jest jednak, by nazwy parametrów i ich rola były jednoznaczne – stąd sensowny prefiks (pSerwerProd, pFolderSharepoint) i opis w Menedżerze parametrów.
Trzeba też brać pod uwagę ograniczenia: nie wszystkie atrybuty da się parametryzować w sposób wspierany przez gateway i refresh z chmury. W przypadku niektórych konektorów bezpieczniej jest parametryzować wyłącznie te elementy, które są formalnie obsługiwane (np. nazwa bazy, filtr daty), a nie np. cały fragment dynamicznego SQL-a.
Parametry a bezpieczeństwo – minimalizacja ekspozycji danych
W raportach, które trafiają do szerszej grupy odbiorców, parametry pomagają ograniczyć dostęp do wrażliwych danych. Zamiast budować osobny model dla każdego działu, można:
przydzielić parametry określające „zakres odpowiedzialności” (np. region, segment klienta);
powiązać odświeżenia z określonymi kontami lub workspace’ami, gdzie wartości parametrów są ustawione na poziomie datasetu;
łączyć parametry z mechanizmami RLS (row-level security) w modelu.
Dwa modele podejścia:
Parametry jako pre‑filter – ograniczają, co w ogóle trafia do modelu (np. tylko dane regionu „Północ”);
RLS jako filtr w modelu – całość danych jest załadowana, ale użytkownik widzi tylko część dzięki regułom bezpieczeństwa.
Parametry vs. kolumny wymiarów – kiedy co stosować
Przy filtrowaniu raportów często pojawia się dylemat: czy dany „przełącznik” zbudować jako parametr w Power Query, czy jako zwykły wymiar (kolumnę) z filtrem w modelu? Oba podejścia mają inne konsekwencje:
Parametr – wpływa na to, co zostanie wczytane do modelu; zmiana wymaga odświeżenia zapytań.
Kolumna wymiaru – wszystko jest w modelu; użytkownik filtrowaniem decyduje, co jest widoczne na wizualizacjach.
Przykład różnicy:
Parametr pRegion – do modelu trafiają wyłącznie dane wybranego regionu; mniejszy rozmiar PBIX, ale każda zmiana regionu to przebudowa i odświeżenie.
Kolumna Region – raport jest „wieloregionowy”, użytkownik wybiera region slicerem; model rośnie, ale przełączanie jest natychmiastowe.
Parametr opłaca się, gdy:
dane są bardzo duże i trzymanie pełnego zakresu w modelu jest niepraktyczne;
analizowany jest zawsze jeden wariant naraz (np. pojedynczy klient, jedna spółka, jedna dywizja);
zakres danych jest trwale „przypisany” do odbiorcy – np. oddział dostaje raport tylko dla siebie.
Z kolei filtr w modelu sprawdzi się lepiej, gdy:
trzeba często porównywać różne warianty bok w bok (region vs region, rok vs rok);
raport trafia do analityków, którzy potrzebują dużej swobody eksploracji;
wielkość danych mieści się komfortowo w limitach Power BI / Excela.
Parametry są więc bardziej narzędziem projektanta modelu (kształtują zakres i rozmiar danych), a kolumny wymiarów – narzędziem użytkownika końcowego (pozwalają swobodnie oglądać to, co już jest załadowane).
Parametry w funkcjach niestandardowych – wielokrotne użycie tej samej logiki
Częsta sytuacja: trzeba przetworzyć wiele tabel lub plików tą samą logiką, ale z drobnymi różnicami konfiguracyjnymi. Zamiast kopiować kroki, praktyczniejsze jest zbudowanie funkcji M z parametrami:
(tabela as table, pDataOd as nullable date, pCzyDemo as logical) as table =>
let
FiltrowanieDat =
if pDataOd <> null then
Table.SelectRows(tabela, each [Data] >= pDataOd)
else
tabela,
TrybDemo =
if pCzyDemo then
Table.FirstN(FiltrowanieDat, 1000)
else
FiltrowanieDat
in
TrybDemo
Taką funkcję można wywoływać z różnych zapytań:
dla tabeli zamówień,
dla tabeli faktur,
dla historii kontaktów z CRM.
W każdym przypadku przekazywane są inne źródła, ale ten sam zestaw parametrów steruje:
od którędy ciąć po dacie,
czy pracujemy w trybie „demo” (np. pierwsze N rekordów zamiast całości).
W porównaniu z kopiowaniem kodu M do wielu zapytań, podejście funkcyjne:
upraszcza utrzymanie – pojedyncza zmiana w funkcji automatycznie obejmuje wszystkie zapytania ją wykorzystujące;
ułatwia testowanie – funkcję można wywołać z różnymi kombinacjami parametrów i sprawdzić zachowanie;
czytelniej oddziela „co robimy” (logika funkcji) od „na czym” (konkretne źródła danych).
Parametry a automatyzacja scenariuszy ETL w Power Query
Jeżeli Power Query służy nie tylko do zasilania pojedynczego raportu, ale do stałych, powtarzalnych zadań ETL (np. przygotowanie plików wyjściowych dla innych systemów), parametry działają jak panel sterowania tymi zadaniami. Typowe zastosowania:
parametr pTrybEksportu (np. „Pełny”, „Inkrementalny”, „Kontrola jakości”);
parametr pFormatWyjscia („CSV”, „XLSX”, „Tabela w tym skoroszycie”);
parametr pDataReferencyjna (np. miesiąc rozliczeniowy, na podstawie którego cięte są zakresy).
Trzy możliwe podejścia do automatyzacji:
Parametry ustawiane ręcznie – osoba odpowiedzialna zmienia wartości w Menedżerze parametrów lub w tabeli konfiguracyjnej w Excelu i odświeża zapytania.
Parametry powiązane z funkcjami czasowymi – pDataOd i pDataDo wyliczane są automatycznie na podstawie bieżącej daty (np. poprzedni miesiąc).
Parametry sterowane zewnętrznie – ich wartości pochodzą z pliku „command” lub prostej tabeli w SharePoint/OneDrive, którą może nadpisywać inny proces.
W pierwszym wariancie kontrola jest najbardziej manualna, ale też najprostsza organizacyjnie. Drugi zmniejsza nakład pracy, lecz w zamian ogranicza elastyczność (scenariusze „niestandardowe” wymagają naruszenia automatyki). Trzeci daje największe możliwości integracji – Power Query staje się wtedy jednym z etapów większego łańcucha przetwarzania.
Parametry a inkrementalne odświeżanie (logika własna vs. wbudowana)
W Power BI istnieje wbudowany mechanizm inkrementalnego odświeżania, który korzysta z parametrów RangeStart i RangeEnd. Można jednak zbudować podobną logikę „ręcznie” na własnych parametrach, także w środowiskach, które nie wspierają oficjalnego mechanizmu (np. Excel, starsze wersje Power BI).
Dwa sposoby podejścia:
Mechanizm wbudowany – parametry RangeStart i RangeEnd są wykorzystywane przez reguły inkrementalnego odświeżania na poziomie datasetu.
Mechanizm własny – parametry pDataOd/pDataDo sterują filtrami w Power Query, a historia danych łączona jest w osobnych tabelach/plikach.
Rozwiązanie wbudowane:
jest prostsze do konfiguracji i lepiej zintegrowane z usługą Power BI;
wymaga jednak Premium/PPU lub określonych wersji funkcjonalności oraz spełnienia wymogów co do źródła danych.
Logika własna:
działa także w Excelu czy w prostszych środowiskach bez wsparcia inkrementalnego odświeżania;
wymaga świadomego zarządzania archiwami (np. osobne pliki „historia do 2022”, „dane bieżące”).
W obu podejściach parametry pełnią rolę „ramy czasowej” – ograniczają, ile nowych danych trzeba pobrać przy odświeżeniu. W projektach mieszanych (część raportów w Excelu, część w Power BI) opłaca się ujednolicić nazewnictwo (pDataOd, pDataDo), tak aby ten sam model konceptualny dało się przenieść między środowiskami.
Parametry wielowartościowe – listy i tabele jako wejście
Większość prostych parametrów ma pojedynczą wartość (jedna data, jeden region). Zdarzają się jednak scenariusze, w których trzeba przekazać zestaw wielu wartości – np. listę kodów klientów lub grup produktowych. Power Query pozwala na parametr typu List lub Any, który przyjmie:
listę stałą zdefiniowaną w Menedżerze parametrów,
listę wygenerowaną z tabeli konfiguracyjnej (np. kolumna „Klient” w arkuszu Excel).
Przykład użycia parametru-listy pListaKlientow:
let
Zrodlo = ...,
Filtrowanie =
if List.Count(pListaKlientow) > 0 then
Table.SelectRows(Zrodlo, each List.Contains(pListaKlientow, [Klient]))
else
Zrodlo
in
Filtrowanie
Dwa praktyczne warianty:
Lista krótka – kilka/kilkanaście pozycji, utrzymywana ręcznie (np. „top” klienci, wybrane produkty).
Lista długa – dziesiątki lub setki wartości, generowana z innej tabeli (np. z systemu uprawnień lub arkusza „Mapa przypisań”).
W pierwszym scenariuszu parametry-listy są prostym uzupełnieniem klasycznych parametrów pojedynczych. W drugim mogą pełnić funkcję technicznego filtra bezpieczeństwa lub ograniczenia zakresu analiz (np. lista aktywnych kontraktów, z którą łączona jest główna tabela faktów).
Nazewnictwo i organizacja parametrów w większych modelach
Przy jednym lub dwóch parametrach nazewnictwo ma mniejsze znaczenie. Gdy jednak pojawia się ich kilkanaście lub kilkadziesiąt, brak porządku szybko mści się przy utrzymaniu. Sprawdza się podział na kategorie, udokumentowane już w samej nazwie:
Prefiks typu – p dla parametrów („parameter”), ewentualnie rozszerzony: pCfg, pFiltr, pBezpieczenstwo.
Minimalistyczny – kilka ogólnych parametrów typu pSrodowisko, pSciezkaBazowa, które następnie rozwijane są w krokach M.
Granularny – osobne parametry dla serwera, bazy, schematu, tabeli, okresu dat itd.
Styl minimalistyczny skraca listę parametrów, ale utrudnia dynamiczną zmianę pojedynczych elementów (np. potrzeba zmiany tylko nazwy bazy wymaga edycji logiki M). Styl granularny ułatwia precyzyjne przełączanie, za cenę dłuższej listy i konieczności dobrej dokumentacji.
W większych modelach zwykle lepiej sprawdza się podejście mieszane:
jedno lub dwa parametry nadrzędne (np. pSrodowisko = Dev/Test/Prod),
kilka parametrów szczegółowych tam, gdzie realnie zachodzi potrzeba niezależnej zmiany (np. pSrc_FolderWejscie, pSrc_FolderArchiwum).
Parametry w scenariuszach „co-jeśli” – symulacje w Power Query vs. w modelu
Do analiz typu „co-jeśli” (what-if) zwykle wykorzystuje się parametry w modelu danych (np. w Power BI – wbudowany mechanizm What-if parameter). Da się jednak część takich scenariuszy odsunąć do Power Query, gdy:
symulacja wymaga przeliczenia dużych tabel (np. przeliczenie rabatów lub kosztów jednostkowych),
wariantów jest stosunkowo mało, a każdy ma być „utrwalony” jako osobna tabela wynikowa.
Przykładowo parametr pMarzaDocelowa może sterować:
dodaniem kolumny „Cena sugerowana” w tabeli produktów,
przeliczeniem prognozowanego zysku per produkt/segment.
Możliwe są dwa modele:
Symulacja w Power Query – parametr wpływa na obliczenia w M, a wynikowa tabela jest zasileniem modelu (np. jedna „wersja planu” na dataset).
Symulacja w modelu – parametry what-if wpływają na miary DAX, dane bazowe pozostają niezmienione.
Pierwszy model jest bliższy klasycznym procesom planistycznym („wyprodukuj mi arkusz z planem przy marży X%”), drugi – eksploracyjnej pracy analityka („co jeśli zwiększymy marżę o 2 punkty procentowe?”). Parametry w Power Query pasują szczególnie do tego pierwszego typu zadań.
Przenoszenie rozwiązań parametrycznych między projektami
Kiedy jeden zestaw parametrów i wzorce ich użycia sprawdzi się w kilku raportach, naturalną konsekwencją jest próba budowy „szablonu” – gotowej paczki zapytań i parametrów do ponownego użycia. Da się to zorganizować na kilka sposobów:
Szablon PBIX/XLSX – plik z przygotowanym modelem i parametrami, kopiowany jako baza kolejnych projektów.
Biblioteka funkcji M – osobny plik z funkcjami i parametrami, z którego inne projekty importują kod.
Repozytorium fragmentów kodu – np. plik tekstowy lub Git, w którym przechowywane są standardowe wzorce (konfiguracja z arkusza, przełącznik środowisk, tryb demo itp.).
Szablon PBIX/XLSX jest najszybszy do wdrożenia – wystarczy otworzyć, zapisać pod nową nazwą i dostosować parametry. Minus: trudno z poziomu jednego miejsca zaktualizować logikę we wszystkich projektach korzystających z szablonu.
Źródła
Power Query M formula language specification. Microsoft – Oficjalna specyfikacja języka M używanego w Power Query
Create and manage parameters in Power BI Desktop. Microsoft Learn – Dokumentacja tworzenia i użycia parametrów w Power BI Desktop
Power Query for Excel Help. Microsoft Support – Podstawy użycia Power Query w Excelu, w tym konfiguracja zapytań
Power Query and Power BI M Language. SQLBI – Omówienie języka M, twardego kodu i wzorców parametryzacji
Applied Microsoft Power BI. Rowell (2016) – Praktyczne scenariusze raportów, parametry źródeł i środowisk
