Artykuł pochodzi z wydania: Kwiecień 2021
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).
[…]
Marcin Szeliga
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.
