Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.08.2021

Firma Fortinet rozszerzyła...

Firma Fortinet rozszerzyła ofertę o usługę FortiTrust, która dołączyła do innych usług...
26.08.2021

Aplikacje biznesowe

Ready_™ AppStore
26.08.2021

Automatyzacja chmur...

Integracja z Red Hat Ansible
26.08.2021

Backup kodu źródłowego

GitProtect.io dostępny na Github
26.08.2021

Wsparcie pracy hybrydowej

Zdalny SD WAN
26.08.2021

Nowy monitor Philips 498P9Z

Nowy monitor Philips 498P9Z to model wyposażony w 49-calowy, zakrzywiony panel VA o...
26.08.2021

Wytrzymały punkt dostępowy

D-Link DIS-2650AP
26.08.2021

Ekonomiczne dyski

SSD bez DRAM
26.08.2021

Petabajty pojemności

Serwery QNAP

Zasady modelowania w power BI

Data publikacji: 01-04-2021 Autor: Marcin Szeliga

Model wymiarowy w praktyce
Wydajne przetwarzanie danych wymaga nie tylko odpowiedniej architektury, czyli np. serwera SQL czy Data Lake, ale przede wszystkim ich właściwego zamodelowania. W tym artykule przedstawimy na przykładzie projektu Power BI Desktop najważniejsze zasady modelowania wymiarowego.

 

Dla systemów operacyjnych, na przykład dla CRM, których użytkownicy na bieżąco modyfikują, wstawiają i odczytują niewiele rekordów, odpowiedni będzie opracowany w 1970 roku przez E.F. Codda model relacyjny. Dla systemów analitycznych (takich jak BI), których użytkownicy odczytują i grupują wiele rekordów, odpowiedni jest opracowany w 1997 roku przez Ralpha Kimballa model wymiarowy. W niniejszym omówieniu skupimy się na takich zagadnieniach jak definiowanie wymagań, import danych i związane z nim dobre praktyki, denormalizacja modeli czy w końcu atrybuty wyliczeniowe. W drugiej części natomiast skupimy się na wzbogacaniu modelu.


> Model wymiarowy


Jednym z najczęstszych błędów jest budowanie raportów i analiz na podstawie systemu relacyjnego lub plików tekstowych bądź arkuszy Excela. Tymczasem model relacyjny jest modelem technicznym, którego celem jest minimalizacja duplikatów danych. Taki model upraszcza wstawianie, usuwanie i modyfikowanie danych, ale zupełnie nie nadaje się do ich analizowania.


Model relacyjny tworzy się, normalizując dane. Normalizacja oznacza podzielenie danych pomiędzy wiele, powiązanych ze sobą relacjami jeden-do-wielu, tabel. Powoduje to, że odczytywanie danych jest mało wydajne, bo wymaga łączenia tabel. Ponadto odczytywanie i grupowanie danych jest skomplikowane, bo model relacyjny nie zawiera metadanych biznesowych, takich jak opisowe nazwy zmiennych czy odpowiednie formaty wartości.


Płaski model danych, z którym mamy do czynienia w wypadku plików tekstowych czy arkuszy kalkulacyjnych, jest z kolei skrajnie zdenormalizowany. Chociaż odczytanie interesujących nas danych nie wymaga łączenia (wszystkie dane są w jednej tabeli), to problematyczne jest ustalenie poziomu szczegółowości danych.


Rozwiązaniem obu tych problemów jest model wymiarowy. Podstawowymi obiektami tego modelu są fakty i wymiary:

 

  • fakty przechowują miary;
  • wymiary przechowują atrybuty.

 

Chociaż fakty i wymiary są tabelami (możemy je więc zaimplementować serwer wymiarowy za pomocą serwera SQL Server, Oracle czy PostgreSQL), to model jest zupełnie inny od modelu relacyjnego. Przede wszystkim łączące fakty z wymiarami relacje służą filtrowaniu, a nie wymuszaniu spójności danych. To oznacza, że atrybuty pozwalają analizować miary w różnych kontekstach. W konsekwencji ani fakty, ani wymiary nie są ze sobą bezpośrednio połączone – relacje występują wyłącznie pomiędzy faktami i wymiarami.


Model wymiarowy jest prostym modelem biznesowym, co oznacza, że jest on łatwy w użyciu. Ponadto ograniczona liczba złączeń wymaganych do odczytania danych gwarantuje przewidywalną, wysoką wydajność zapytań. Jest to także sprawdzony model, zgodny z wszystkimi narzędziami analitycznymi, takimi jak Excel, Power BI, Tableau czy Qlick.


> Metoda Kimballa


Ralph Kimball nie tylko stworzył model wymiarowy, ale również jest autorem metody jego wdrażania. Metoda ta jest od lat z sukcesem stosowana w tysiącach projektów Business Intelligence. W artykule przyjrzymy się dwóm z kilkunastu kroków tej metody: definiowaniu wymagań i modelowaniu wymiarowemu.


Definiowanie wymagań


Ponad 2/3 projektów Business Intelligence kończy się porażką – najczęściej użytkownicy po prostu nie korzystają ze stworzonego systemu BI. Dlatego powodzenie zależy przede wszystkim od jego wartości biznesowej. To oznacza, że wymagania biznesowe muszą zostać zidentyfikowane i przełożone na założenia projektu. Po drugie, jako że projekty BI są czasochłonne (wymagają zaangażowania wielu osób, w tym użytkowników) i kosztowne, powinniśmy na początku zdobyć sponsorów, środki i przychylność interesariuszy. Po trzecie, ponieważ ostatecznym celem projektów BI jest optymalizacja procesów biznesowych, musimy zidentyfikować potencjalne zagrożenia (takie jak ograniczona możliwość zmiany jakiegoś procesu).


Definiowanie wymagań należy zacząć od zidentyfikowania procesów biznesowych, takich jak sprzedaż, obsługa klienta, zarządzanie magazynem, zakupy itd. Następnie należy określić konteksty dotyczące poszczególnych procesów. Kontekstem, który jest używany do analizy praktycznie wszystkich procesów biznesowych, jest kalendarz – użytkownicy analizują sprzedaż, zakupy i inne procesy w czasie. Przykładami innych kontekstów są: produkt, klient, sprzedawca, magazyn, lokalizacja, departament, kampania reklamowa, partner biznesowy. Wynikiem tego etapu powinna być macierz, której poszczególne wiersze zawierają zidentyfikowane procesy biznesowe, a kolumny – konteksty. Jeśli dany proces powinien być analizowany w danym kontekście, w komórce znajdującej się na przecięciu procesu i kontekstu wstawiamy X. Drugim
etapem powinno być określenie priorytetów. Najłatwiej jest użyć w tym celu wykresu, w którym na osi X umieścimy łatwość zamodelowania danego procesu (od niskiej, czyli bliżej 0 umieścimy procesy, których zamodelowanie jest trudniejsze), a na osi Y wartość wynikającą z ich zamodelowania (im większa wartość dodana, tym wyżej znajdzie się modelowany proces). Oceniając łatwość modelowania procesów, należy kierować się dostępnością i jakością danych, kosztami wdrożenia i zidentyfikowanymi zagrożeniami.

 

[...]

 

Pracownik naukowy Wyższej Szkoły Bankowej w Poznaniu Wydział Zamiejscowy w Chorzowie, jest autorem książek poświęconych analizie danych i posiada tytuł Microsoft Most Valuable Professional.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"