Nazewnictwo transformacji w Power Query
W dzisiejszym wpisie przedstawię zastosowanie kolejnych dobrych praktyk w modelowaniu danych. Tym razem nie skupimy się na optymalizacji raportów, lecz nazewnictwie kroków transformacji w Power Query. Artykuł jest przeznaczony dla deweloperów Power BI na dowolnym poziomie doświadczenia.
Omówienie
Zapewne zdarzyło Ci się nie raz, że po otwarciu zapytania w edytorze zapytań Twojego raportu BI i przejrzeniu samych nazw transformacji dokonanych w Power Query, że nie do końca jasna jest logika wprowadzanych zmian. Spójrzmy na poniższy przykład:
Nie wspominając, że nawet nazwa zapytania nie ma sensu prawdopodobnie potrzebowalibyśmy trochę czasu, aby zrozumieć powzięte kroki, jak mają się one do przekształceń w zbiorze danych. Następnie przechodząc przez każdy krok po kolei ciężko byłoby zrozumieć czemu w ogóle zostały zastosowane przekształcenia.
Jaki jest cel?
Zmieniając nazwy transformacji chcemy:
-
Poprawić przejrzystość;
-
Opisać typ operacji zastosowanej w danym kroku;
-
Nadać kontekst zmiany w jej nazwie;
-
Ustandaryzować powzięte kroki.
Możliwości zmian w nazewnictwie kroków w Power Query
Power Query posiada bardzo przejrzysty interfejs użytkownika, który zawiera mnóstwo operacji przekształcania danych. Jego celem jest ułatwienie przekształcania danych wsadowych do Excel/ Power BI, aby nawet użytkownicy nie znający kodu M umieli „wyklikać” swój pożądany model. Za każdym razem, gdy dokonujesz zmiany w modelu danych Power Query tworzy nowy krok, który:
-
Dotyczy zmiany wyniku poprzedniego kroku;
-
Automatycznie tworzy linijkę kodu M w zaawansowanym edytorze, a także na pasku formuł;
-
Jest nazwany na podstawie generycznej nazwy operacji, a także potrafi być iterowany w przypadku, gdy identyczna zmiana zachodzi kolejny raz, np. Changed Type, Changed Type1…
Wśród generycznych operacji w Power Query możemy wyróżnić:
-
Source (źródło)
-
Navigation (nawigacja)
-
Changed Type (zmiana typu kolumn/y)
-
Added Conditional Column (dodanie kolumny warunkowej)
-
Added Custom (dodanie własnej kolumny)
-
Renamed columns (zmiana nazwy kolumn/y)
-
Reordered columns (zmiana kolejności kolumn)
-
Removed columns (usunięcie kolumn/y)
-
Replaced values (zamiana wartości)
-
Oraz wiele innych.
Problemem nazw generycznych nie jest ich brak powiązania z operacją, ponieważ te mówią wprost co zostało wykonane, lecz kontekst zmiany, który nadaje sensu zachodzącemu procesowi na pierwszy rzut oka. Aby zmienić nazwę kroku wystarczy kliknąć na niego prawym przyciskiem myszy i wybrać Rename.
Przy nazywaniu kroków transformacji kieruj się poniższymi zasadami:
-
Unikaj zbyt długich nazw – szczególnie jeśli przekraczają one standardową szerokość interfejsu. Zawijanie wierszy w interfejsie pogarsza przejrzystość – jedna linia powinna oznaczać jeden krok;
-
Używaj naturalnego języka nazywając kroki – unikaj używania skrótów znanych tylko Tobie, pisz pełne wyrazy w sposób naturalny gdy tylko jest to możliwe – poprawi to znacząco przejrzystość;
-
Nie zostawiaj nazw generycznych niezmienionych – wykorzystaj czas na opracowanie nazewnictwa, zaoszczędzi Ci to później wiele czasu w przypadku powrotu do raportu. Pozostawianie nazw generycznych jest akceptowalne w przypadku, gdy Twoje zapytanie jest naprawdę krótkie, dotyczy generalnych kroków (np. wskazanie źródła lub nawigacja), oraz gdy kroki nie powtarzają się;
-
Bądź konsekwentny w nazewnictwie – nazywaj kroki w innych raportach według tej samej logiki, a także propaguj wspólne ustandaryzowane nazewnictwo w zespole. Usprawni to Waszą pracę.
Sposoby nazewnictwa
Jako dobrą praktykę sugeruje się standaryzację nazewnictwa kroków według poniższego:
[Wykonywana akcja] + [Kontekst]
Gdy mówimy o wykonywanej akcji tutaj trzymamy się domyślnych czasowników jak „Added” (dodano) po dodaniu kolumny lub „Merged” i „Expanded” (dołączono, rozszerzono) dla zapytań scalanych. Jak przy wcześniejszych rozwiązaniach – sugeruję wykorzystanie angielskich nazw ze względu na ich intuicyjność.
Gdy mówimy o kontekście tutaj wskazałbym kolumny lub tabele, które są dotknięte zmianą, tak aby opis od razu wyjaśniał powzięty krok. Jako przykład możemy tutaj wymienić:
-
Added Conditional Column – Added Order Status,
-
Renamed Columns – Renamed Order Status,
-
Merged Queries – Joined Vendor Attributes,
-
itd.
Wracając do naszego przykładu zobaczmy jak wyglądają nasze kroki przed i po zmianie:
Patrząc na zmienione nazewnictwo możemy wywnioskować:
-
Zmiany dotyczą danych sprzedażowych
-
Źródłem danych jest Excel
-
Kroki „Promoted Headers”, „Changed Types” oraz „Renamed Columns” dotyczą automatycznego przypisania odpowiednich typów danych i nazw kolumn
-
Pole „City” jest wypełnione w dół
-
Dokonano operacji Unpivot (rozgrupowania) ze względu na kolumny City i Category
-
Dodano dwie kolumny Year oraz Gross Sales
Potwierdza to widok poniższej tabeli:
Podsumowanie
-
Zawsze nadawaj swoim transformacjom sensowną nazwę, ponieważ pomoże to zrozumieć innym użytkownikom celowość zmian oraz oczekiwany rezultat.
-
Sprawdź czy Twoje zapytanie nie posiada zbędnych kroków.
-
Ustandaryzuj nazewnictwo transformacji i wypracuj wspólną metodykę w zespole.
Oczywiście zapraszam do dyskusji w komentarzach na temat innych dobrych praktyk, z którymi się spotkaliście.
Artykuł opracowany na podstawie: