Architektura publikowania raportów w serwisie Power BI

Od początku istnienia Power BI ideą przyświecającą jego twórcom było udostępnienie możliwości, jakie oferują SQL Server Analysis Services (SSAS) oraz SQL Server Reporting Services (SSRS) szerszemu gronu odbiorców i ułatwienie tworzenia potężnych w swojej prostocie narzędzi analitycznych dla biznesu. Projekt przeszedł przez długą drogę, zmieniając się z wewnętrznego dla Microsoftu Gemini, w udostępniony jako darmowy dodatek do MS Excela Power Pivot, by w roku 2015 przybrać znaną już dość powszechnie nazwę Power BI.

W ciągu 14 lat rozwoju stał się rozległym systemem złożonym z kilku komponentów i oferującym gamę możliwości przekształcania gromadzonych danych w przydatne podczas podejmowania decyzji raporty. Każdy, kto pracował z SSRS oraz Power BI, na pewno zauważył różnicę w intuicyjności oraz przystępności korzystania z bohatera tego artykułu. 

Pełnoprawny element pakietu Office

Po sukcesie pakietu Office wielu próbowało stworzyć podobny zestaw narzędzi, stając się konkurencyjnymi, bądź udostępniając darmową alternatywę. Niewątpliwie przyczyniła się do tego prostota oraz dobra organizacja interfejsu graficznego programów wchodzących w jego skład.

Z drugiej strony narzędzia takie jak SSAS oraz SSRS pozostawały w sferze programów dla developerów – wymagały znajomości SQL, a ich interfejs odbiegał wyglądem od rodziny pakietu Office. Power BI Desktop jest programem rewolucyjnym pod tym względem, łączy w sobie bowiem możliwości modelowania i analizy danych oraz prostotę użytkowania. W ramach tworzenia raportu można skorzystać z przeciągania i upuszczania elementów na siebie, wybierania wizualizacji danych spośród miniatur oraz podobnego do innych produktów wchodzących w skład pakietu Office. Na zakończenie w trzech kliknięciach raport przygotowany przy użyciu Power BI Desktop może zostać opublikowany w Power BI Service (por. rysunek 1).

Czy jest więc to aż tak proste? Co zrobić, by opublikowane raporty nie utonęły w większej ich liczbie? Jak przedstawić je użytkownikowi estetycznie, a jednocześnie funkcjonalnie?

Rysunek 1 Publikowanie raportu w aplikacji Power BI Desktop. 1 – opcja publikacji raportu, 2 – wybór przestrzeni roboczej, 3 – zatwierdzenie

Czym jest współdzielony zestaw danych?

Zanim przyjrzymy się kwestiom czysto technicznym, rozważmy przypadek średniej firmy produkującej i sprzedającej okna i drzwi, w której znajduje się kilka działów. Dla ułatwienia, nazwijmy ją ModelDoor. Posłuży nam ona do zamodelowania spodziewanego problemu. Niech to będą (m.in.) dział sprzedaży, odpowiedzialny za ilość sprzedanego towaru, dział serwisowy, odpowiedzialny za utrzymanie produktów sprzedanych klientowi w dobrym stanie w ramach umów gwarancyjnych, dział innowacji, odpowiedzialny za tworzenie i ulepszanie produktów oraz dział controllingu, kontrolujący koszty i przychody firmy.

Gromadzone w firmie dane dotyczą sprzedaży (liczba sztuk, przyznane zniżki), serwisu (zawodność konkretnych produktów, terminowość naprawy) i transakcji (kosztów oraz przychodów) uwzględniając sprzedaż. 

Wszystkie te działy chciałyby usprawnić swoją pracę w oparciu o system raportowy wykorzystujący dane gromadzone przez firmę podczas rutynowych działań takich jak sprzedaż, serwis czy zamówienia części u zewnętrznych dostawców. Dział sprzedaży chciałby sprawdzić, jak w ostatnim czasie wygląda sprzedaż poszczególnych produktów, które klienci kupują chętniej, gdy jest na nie rabat, a na które popyt jest mniejszy.

Dział serwisowy pragnie dowiedzieć się, które produkty i które ich części psują się najczęściej, aby przeszkolić w ich naprawie większą liczbę pracowników i zadbać o odpowiednią liczbę części zamiennych w magazynie.

Dział innowacji również przygląda się bacznie serwisowi, mając na celu usprawnienie wadliwych projektów. Ma jednak ograniczone środki i chciałby skupić się na produktach, które są przez klientów najczęściej wybierane.

Wreszcie, dział controllingu chciałby wiedzieć, jaki zysk wypracowują poszczególne produkty, jakie są ewentualne koszty zaopatrzenia u poszczególnych dostawców oraz produkcji i serwisu finalnych elementów domów.

Chociaż każdy dział ma inny cel swojego działania i nie potrzebuje do niego wszystkich dostępnych informacji, wiele z nich pokrywa się. W tej sytuacji można śmiało stworzyć jeden wspólny zestaw danych, który posłuży budowie wyspecjalizowanych raportów dla każdej jednostki organizacyjnej.

Ponadto może on w przyszłości pozwolić stworzyć narzędzia dla innych działów lub osób postawionych wyżej w hierarchii firmy, które będą zainteresowane jeszcze inną konfiguracją przedstawienia informacji zawartych w ramach zestawu danych. Scentralizowane źródło pozwoli też łatwiej zarządzać zmianami w modelu danych – będzie on jeden lub ich liczba będzie mniejsza niż w przypadku tworzenia oddzielnych jego wersji dla każdego raportu. Nikt nie lubi przecież utrzymywać rozległych systemów, których stworzenie w jakiejś części sprowadzało się do podejścia „kopiuj i wklej”! Ostatecznie oddzielenie warstwy danych od warstwy prezentacji raczej zawsze okazuje się dobrym pomysłem.

Postanawiając więc ograniczyć się do jednego modelu danych, w naszym systemie możemy stworzyć nowy plik w Power BI Desktop i załadować dane z przygotowanego wcześniej źródła.

Do przedstawienia sytuacji firmy ModelDoor posłużą tabele widoczne na rysunku 2; SaleOrders oraz ProductsInSaleOrders, w których zebrane są informacje o zakupach, ServiceOrder wraz z PartsServiced, gdzie znajdują się dane o wykonanych świadczeniach serwisowych, Products i Parts, zawierających opis produktów i części, z których się składają, a także tabeli Supplies, opisującej koszt zakupu części, jeśli nie jest ona produkowana na miejscu i wiążącej cztery inne tabele PartsOfProducts, definiującej relacje pomiędzy produktami i ich poszczególnymi elementami.

Rysunek 2 Model bazy danych firmy ModelDoor w aplikacji Power BI Desktop

Zarządzanie przestrzeniami roboczymi

Po przygotowaniu modelu możemy przejść do utworzenia raportu w ramach tego samego pliku. Zamknie to jednak możliwość przedstawienia kompletnie różnych zestawień poszczególnym działom.

Wyjściem z tej sytuacji mogłoby okazać się zastosowanie bardziej rozbudowanego modelu w połączeniu z Row Level Security (RLS), które przefiltrowałoby dane, uwzględniając to, kto w danym momencie je przegląda.

Jednak to rozwiązanie nie byłoby aż tak czyste, jak zaproponowane w niniejszym artykule. Każda zmiana, jakiej potrzebowałby dany dział, wymagałaby zmian w de facto tym samym pliku. Być może doszłoby też do sytuacji, w której potrzeby dwóch różnych jednostek wykluczałyby się wzajemnie.

Innym podejściem może być skopiowanie pliku kilkukrotnie i stworzenie osobnych raportów w każdym z nich. Zmiany w raportach nie będą na siebie wzajemnie wpływały, jednak każda zmiana w modelu będzie musiała być wprowadzona w każdym z tych plików.

Alternatywnie możemy nie tworzyć wizualnych elementów raportu (pusty raport i tak zawsze jest wpisany w plik *.pbix tworzony przez Power BI Desktop, nawet, gdy otworzymy w nim zapisany model) i opublikować go w tej wersji już na tym etapie.

Przygotujmy więc przestrzenie robocze; jedną dla zestawów danych i po jednej dla każdego działu jak na rysunku 3. Następnie umieśćmy raport w odpowiednim miejscu. Na rysunku 4 widać już raport w usłudze Power BI Service. A w zasadzie widać raport i zestaw danych. Współistnieją one w jednym pliku aż do czasu publikacji, gdzie są rozdzielane. Ujawnia się tu idea zachowania podziału między warstwą danych i warstwą prezentacji. W panelu po lewej stronie ekranu widoczne są wszystkie raporty i wszystkie zestawy danych w przestrzeni roboczej Datasets (znaczniki 1 i 2). Na liście mieszają się raport o nazwie Dataset, oznaczony jako 3 oraz zestaw danych o tej samej nazwie. Nie potrzebujemy tego raportu, więc może on zostać bezpiecznie usunięty.

Rysunek 3

Rysunek 4 Opublikowany plik zawierający model danych

Po opublikowaniu modelu danych, którego celem w założeniu jest posłużenie jako źródło danych do budowania być może wielu raportów, warto jest go wyróżnić. W rzeczywistości w obszarze roboczym może znaleźć się wiele zestawów danych, nie wszystkie jednak muszą koniecznie być warte polecenia.

Ponieważ jednak rozważany przypadek przewiduje utworzenie narzędzi dla wielu komórek w firmie ModelDoor, zostanie on oznaczony jako sprawdzone źródło danych dla łatwiejszego odnalezienia go na liście wszystkich zestawów danych. Rysuneg 5 przedstawia, jak można to zrobić w usłudze Power BI Service (ang. Endorsement).

Rysunek 5 Wyróżnienie zestawu danych

Budowa przykładowego raportu

Posiadając już współdzielony zestaw danych dostępny dla wszystkich użytkowników, można stworzyć na jego bazie raport. Dla przykładu niech będzie to raport dla działu sprzedaży.

Na początek należy utworzyć nowy plik w Power BI Desktop i wybrać jako źródło danych Zestawy danych usługi Power BI, a następnie zaznaczyć na liście interesującą nas pozycję. Dzięki podwyższeniu poręczenia na pierwszym miejscu znajduje się stworzony przez nas zestaw o nazwie Dataset. Jest on też specjalnie oznaczony w kolumnie Poręczenie, jak widać to na rysunku 6. 

Rysunek 6 Wybór zestawu danych jako źródła danych dla raportu

Model danych zawarty w pliku Dataset jest teraz dostępny w nowym pliku. Nie możemy go co prawda modyfikować, jednak jeśli stworzyliśmy go z myślą o raporcie, nie powinniśmy tego potrzebować.

Na rysunku 7 widać przykładowy raport przedstawiający raport sprzedaży poszczególnych produktów. Gdy będzie on gotowy, kolejnym krokiem jest udostępnienie go w odpowiedniej przestrzeni roboczej. Nie musi to być wcale ta sama przestrzeń, w której znajduje się zestaw danych! Dla działu sprzedaży została przewidziana osobna przestrzeń, gdzie publikowane będą jedynie związane z działem raporty lub tworzone pulpity i aplikacje.

Rysunek 7 Przykładowy raport dla działu sprzedaży

Stworzenie pulpitu nawigacyjnego i aplikacji

Od tej pory raport dostępny jest online w przestrzeni roboczej Sales. Nie jest to jednak najwygodniejszy sposób dostępu do danych.

Użytkownik, chcąc przejrzeć nowości w swoim obszarze, będzie widział nie tylko własne raporty, ale też powiązane z nimi pulpity nawigacyjne, skoroszyty i zestawy danych. O ile nie jest to szkodliwe, może okazać się niepraktyczne i utrudnić mu pracę z przygotowanymi dla niego narzędziami. Dodatkowo widoczne będą też różne przyciski, których działanie i tak zostało zablokowane dla osób niebędących administratorami systemu. Na szczęście istnieje sposób na lepsze przedstawienie efektów naszej pracy!

Chociaż rozważamy przypadek, w którym istnieje jedynie jeden raport stworzony dla działu sprzedaży, w rzeczywistości takich raportów może być wiele i/lub mogą one być bardzo rozbudowane. Najczęściej można wtedy wyróżnić kilka ogólnych obszarów, jakie przedstawiają stworzone narzędzia i wybrać po jednym elemencie, który najlepiej je reprezentuje.

Przykładowo, dane o sprzedaży mogą zostać przedstawione na wykresie jako rozkład w czasie, w tabeli jako suma dla całego okresu i na interaktywnej mapie pokazując w jakim regionie najlepiej sprzedają się dane produkty. Gdy raport będzie już zamieszczony w usłudze Power BI Service w widoku raportu, każdy element wizualny raportu może zostać przypięty do pulpitu nawigacyjnego. Na pulpicie powinny znaleźć się właśnie elementy reprezentujące dany raport lub jego część. Kliknięcie w taki element na pulpicie nawigacyjnym przeniesie nas do odpowiedniego miejsca w raporcie, dlatego jeden pulpit może być wystarczający dla całego działu sprzedaży.

Na rysunku 8 widać, jak można przypiąć wykres sprzedaży do nowego pulpitu nawigacyjnego.

Rysunek 8 Utworzenie nowego pulpitu nawigacyjnego

Na pulpicie nawigacyjnym znajdą się więc wszystkie kluczowe elementy systemu raportowego z punktu widzenia działu sprzedaży. Jeśli zostanie on udostępniony jego pracownikom jako punkt startowy dla dalszego poruszania się po raportach, nie zostaną wykluczone problemy z przejrzystością, dostępnością różnych niepotrzebnych opcji i ogólnego wrażenia, że wszystko jest w stanie surowym.

Idąc jednak krok dalej, można przygotować aplikację dla użytkowników końcowych, w której pulpity nawigacyjne oraz raporty zostaną przedstawione w formie tylko do odczytu, zachowując możliwość interakcji z nimi oraz eksportu danych. 

To bardzo proste! W pierwszej kolejności należy wybrać elementy, które są pożądane w aplikacji z listy obiektów w danej przestrzeni roboczej, jak widać to na rysunku 9, i utworzyć na ich bazie aplikację. W razie pomyłki, można ją później zaktualizować.

Drugim krokiem jest konfiguracja aplikacji. Chociaż posiada ona wiele opcji wymagane pola to zaledwie nazwa i opis. Rysunek 10 przedstawia aktualizację aplikacji, chociaż nie różni się ona od stworzenia zupełnie nowej niczym, poza napisem na przycisku.

Rysunek 10 Tworzenie aplikacji Power BI

Voilà! Aplikacja dla działu sprzedaży została utworzona! Panel nawigacyjny po lewej stronie (patrz rysunek 11) zawiera teraz jedynie obiekty, które zostały przeznaczone do przeglądania przez pracowników tej komórki. Aplikacja posiada własny URL (Uniform Resource Locator), który można bezpiecznie przekazać osobom uprawnionym do wglądu.

Oczywiście przed ewentualnym niepowołanym dostępem do danych warto zabezpieczyć się za pomocą wspomnianego wcześniej RLS, jednak nie jest to przedmiotem niniejszego artykułu.

Rysunek 11 Opublikowana aplikacja dla działu sprzedaży

Podsumowanie

Chociaż dla wielu czytelników takie podejście do przedstawienia danych wydawać się może oczywiste, nie zawsze jest ono stosowane. Power BI oferuje bogatą gamę opcji, a zapoznanie się ze wszystkimi wymaga czasu i jak każde narzędzie wykonania pracy przy jego użyciu. W tym artykule pominięto wiele istotnych kwestii i etapów tworzenia raportów, takich jak bezpieczeństwo czy wstępna obróbka danych, aby nie przysłonić prezentowanej architektury i ścieżki tworzenia aplikacji.