Projektowanie hurtowni danych i modelowanie wielowymiarowe

Projektowanie hurtowni danych i modelowanie wielowymiarowe Krzysztof Dembczyński Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska Technologie Wytwarzania Oprogramowania Semestr zimowy 2008/09 Studia uzupełniajace magisterskie

Systemy baz i hurtowni danych wprowadzenie do wykładu Modele danych i ewolucja systemów baz danych Projektowanie hurtowni danych i modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL) Systemy OLAP I Systemy OLAP II Systemy OLAP III

1 Schematy logiczne hurtowni danych 2 Modelowanie koncepcyjne hurtowni danych 3 Zapytania do hurtowni danych 4 Podsumowanie

Trzy cele logicznego projektu hurtowni danych: Prostota, Wyrazistość, Wydajność.

Prostota: Użytkownik powinien rozumieć projekt, Stworzony model powinien odpowiadać modelowi konceptualnemu użytkownika, Zapytania powinny być formułowane prosto i intuicyjnie.

Wyrazistość: Zawierać wszystkie potrzebne informacje, aby umożliwić odpowiedzi na wszystkie ważne zapytania, Zawierać odpowiednie dane (bez zbędnych danych).

Wydajność Efektywne rozwi azanie fizyczne powinno być możliwe do zastosowania.

Trochę inne sformułowanie celu logicznego projektu hurtowni danych: Prostota, Prostota, Prostota,...

Z reguły jest wiele różnych wymiarów, według których można analizować pewien zbiór danych. Ta złożona perspektywa, czyli wielowymiarowy obraz pojęciowy, wydaje się być sposobem, w jaki większość ludzi interesu z natury widzi swoje przedsiębiorstwo E. F. Codd, 1993

Trzy podstawowe schematy logiczne hurtowni danych: schemat gwiazdy, schemat płatka śniegu, schemat wielokrotnych tabel faktów.

Schemat gwiazdy: pojedyncza tablica w centrum poł aczona z wieloma tablicami wymiarów.

Podstawowe terminy: Miary, na przykład stopnie, cena, ilość, Miary musza być agregowalne, Miary zależa od zbioru wymiarów, np. ocena studenta zależy od studenta, przedmiotu, prowadzacego, wydziału, roku akademickiego itp., Relacja, która odwołuje wymiary do miar nazywana jest relacja faktów (np. Students grades) Informacje na temat wymiarów znajduja w zbiorze relacji wymiarów (student, rok akademicki, itd.), Każdy wymiar posiada wiele opisujacych atrybutów.

Tablica faktów: każda krotka zawiera mierzalna wartość opisujac a analizowany proces, każda krotka zawiera klucze obce do tablic wymiarów oraz kolumny numeryczne miar, każdy nowy, mierzalny fakt jest do niej zapisywany, analizie podlegaja agregowane wartości miar.

Tablica wymiaru: każda tablica wymiaru odpowiada obiektowi ze świata rzeczywistego: klient, produkt, region, dział, itp., tablica wymiaru zawiera dużo atrybutów opisowych, w ogólności liczba krotek nie jest duża (w porównaniu z tablica faktów), zapisane wartości sa stosunkowo statyczne, jej zawartość służy do filtrowania i grupowania wyników, tablica opisuje fakty zapisane w tablicy faktów.

Tablica faktów: waska, długa (bardzo dużo krotek), krotki opisane sa za pomoca atrybutów numerycznych (miar), dynamiczna (rośnie z czasem). Tablica wymiaru: szeroka, raczej krótka, opisowa, statyczna. Fakty zawieraja liczby, a wymiary etykiety

Schemat gwiazdy

Hierarchie wymiarów Dla każdego wymiaru można określić hierarchię atrybutów

Schemat płatka śniegu: rozwinięcie schematu gwiazdy poprzez normalizację relacji wymiarów.

Postacie normalne Pierwsza postać normalna (1NF) Druga postać normalna (2NF) Trzecia postać normalna (3NF) Postać normalna Boyce a-codd a (BCNF) Czwarta postać normalna (4NF) Piata postać normalna (5NF)

Projektant operacyjnego systemu baz danych powinien dażyć do stworzenia projektu zawierajacego relacje w 3NF (lub lepiej BCNF) Procedura normalizacji pozwala na przeprowadzenie operacji przejście z jednej postaci do drugiej (przy czym ta druga jest ta bardziej oczekiwana) Procedura ta jest odwracalna.

Denormalizacja proces odwrotny do normalizacji Polega na tworzeniu danych nadmiarowych przechowywanych w relacjach, co pozwala podczas wykonywania zapytań analitycznych zmniejszyć liczbę kosztownych czasowo operacji złaczenia.

Schemat wielokrotnych tablic faktów: wiele tablic faktów dzieli relacje wymiarów. Takie schematy pojawiaja się przy projektowaniu hurtowni danych dla dużych i złożonych problemów. Z punktu widzenia sukcesu projektu, dobrze jest zacz ać od prostego modelu logicznego hurtowni danych.

Cztery kroki modelowania koncepcyjnego hurtowni danych: Wybór procesu biznesowego do zamodelowania (np. sprzedaż) Zdefiniowanie ziarna (rozdzielczości) procesu biznesowego (np. transakcja w sklepie identyfikowana przez skaner przy kasie), Wybór wymiarów znajdujacych się w każdej krotce tablicy faktów (np. lokalizacja sklepu, produkt, data, pora dnia, rodzaj promocji, itp.), Identyfikacja miar, które wypełnia każda krotkę tablicy faktów (np. liczba sprzedanych sztuk, łaczna wartość sprzedaży).

Wybór procesu biznesowego do zamodelowania: Powinna to być naturalna aktywność przedsiębiorstwa, wspomagana przez operacyjny system źródłowy, Przykład: zakup surowców, zamówienia, dystrybucja, sprzedaż, Proces nie może być mylony z działem lub funkcja administracyjna, Wybór procesu powinien być zależny od jego złożoności, czasu i budżetu przeznaczonego na projekt.

Zdefiniowanie ziarna (rozdzielczości) procesu biznesowego: Należy dokładnie określić znaczenie pojedynczej krotki tabeli faktów, Określa jak bardzo szczegółowe dane chcemy przechowywać w hurtowni danych, Przykłady: transakcja w sklepie identyfikowana przez skaner przy kasie, codzienna migawka poziomu inwentarza dla każdego produktu w hurtowni, miesięczna migawka dla każdego konta bankowego, Im większa rozdzielczość, tym większy rozmiar i szybsze powiększanie się hurtowni danych, Im mniejsza rozdzielczość, tym mniej dokładny proces wspomagania decyzji.

Wybór wymiarów znajdujacych się w każdej krotce tablicy faktów: Zdefiniowanie opisu danych będacych wynikiem procesu biznesowego, Szczegółowy opis ziarna zdefiniowanego w poprzednim kroku, Przykład: dla transakcji w sklepie może to być wymiar lokalizacji, produktu, daty, pory dnia, rodzaj promocji, itp., Rozdzielczość tabeli faktów determinuje rozdzielczość tabel wymiarów, Jeżeli dowolny wymiar występuje w dwóch tabelach faktów, musza to być dokładnie takie same wymiary, lub jeden z wymiarów jest podzbiorem drugiego.

Identyfikacja miar, które wypełnia każda krotkę tablicy faktów: Zdefiniowanie tego co chcemy zmierzyć, Hurtownia danych ma nam dać odpowiedź na temat wydajności procesu biznesowego, Każda miara (jak również krotka i wymiar) w tabeli faktów musza być na tym samym poziomie szczegółowości, Miary powinny być numeryczne, najlepiej addytywne, Część miar może być częściowo-addytywna (liczba jabłek i pomarańczy).

Zadanie 1 Dla sieci sklepów zaprojektuj hurtownię danych zorientowana na analizę sprzedaży. Zaproponuj relację faktów i wymiarów, Zaproponuj schemat gwieździsty, Zaproponuj hierarchie wymiarów.

Zadanie 1

Dodatkowe aspekty modelowania: Zapisywanie w tabeli faktów atrybutów wyliczonych, Opisywanie tabeli wymiarów, Wybór przedziału czasu dla hurtowni danych, Wymiar czasu, Sztuczne klucze główne, Zdegenerowane wymiary, Pozbawiona faktów relacja faktów :), Uwzględnienie wolno zmieniajacych się wymiarów, Planowanie hurtowni danych dla całego przedsiębiorstwa, Fizyczna organizacja hurtowni danych pod względem wydajności.

Wymiar czasu jest specyficznym i nieodłacznym wymiarem w projekcie logicznym hurtowni danych. Hurtownia danych może (powinna) być traktowana jako temporalna baza danych. Wymiar czasu pozwala na porównania ze względu na historię przechowywanych danych.

Typowe atrybuty w wymiarze czasu: Konkretny czas (klucz główny), dzień miesiaca, dzień tygodnia, weekend, 24-godzinny dzień pracy święto publiczne, dzień wolny od pracy, tydzień roku, miesiac, nazwa miesiaca, kwartał, rok, miesiac finansowy, rok finansowy.

Wymiar daty i czasu dnia W przypadku potrzeby zapisywania daty oraz dokładnego czasu w ciagu dnia warto zamodelować wymiar czasu za pomoca dwóch tabel: Data i Czas_dnia.

Zalety wymiaru czasu: Można zawrzeć ciekawe informacje zwiazane z czasem: wakacje, dni robocze, rano, południe, święto, Brak konieczności wykorzystywania funkcji czasowych (mniejszy koszt obliczeń), Możliwość stosowania indeksów do wymiaru czasu.

Sztuczne klucze główne (ang. Surrogate Keys) warto stosować zamiast kluczy naturalnych (takich jak np. PESEL): klucz sztuczny może być krótszy, co może poprawić wydajność, łatwiejsza obsługa wyjatkowych przypadków (np. brak konkretnych danych w takim przypadku lepiej jest dodać specyficzny wiersz w relacji wymiaru: wartość nieznana ), brak nadinterpretacji wartości klucza, odporność na zmianę znaczenia klucza naturalnego, odporność na ponowne wykorzystanie dawnej wartości klucza naturalnego.

Zdegenerowane wymiary Niektóre wymiary maja raczej znaczenie identyfikatora niż wielu interesujacych atrybutów: rozważmy hurtownię danych dla sklepu detalicznego, typowa transakcja może zostać opisana następujaco: (Id_transakcji, Produkt,...), Id_transakcji jest jedynie unikalnym identyfikatorem, Id_transakcji pozwala na poł aczenie produktów zakupionych w jednym koszyku (pozwala na analizę wielkości koszyka).

Wymiary takie jak Id_transakcji moga być potraktowane w następujacy sposób: nie sa brane pod uwagę podczas tworzenia hurtowni danych, tworzony jest zdegenerowany wymiar (ang. Degenerate Dimension).

Zdegenerowane wymiary Nie jest tworzona osobna tablica wymiaru (taka tablica zmieniałaby się dynamicznie i rozmiarami byłaby podobna do tablicy faktów!!!), Identyfikator jest bezpośrednio wprowadzany do tabeli faktów, Możliwa jest analiza np. wielkości koszyka.

Pozbawiona faktów relacja faktów :) Relacja faktów nie zawiera krotek przy braku zdarzeń: np. brak krotek dla produktów, które nie zostały kupione. Zaleta tego podejścia jest oszczędność pamięci jeżeli wydarzenia występuja rzadko. Wad a tego podejścia jest brak możliwości sprawdzenia np. niepowodzeń promocji.

Pozbawiona faktów relacja faktów :) nie zawiera atrybutów będacych miarami, dodany jest durny :) atrybut zawierajacy wartość 1, opisuje zależności pomiędzy wymiarami. Przykład: które produkty były w promocji w danym dniu?

Wolno zmieniajace się wymiary W porównaniu do relacji faktów, zawartość relacji wymiarów jest stosunkowo stabilna: nowe transakcje (fakty) w sposób ciagły dodawane sa do relacji faktów, nowe produkty pojawiaja się raczej rzadko, nowe sklepy otwierane sa też raczej rzadko. Niektóre wartości atrybutów wymiarów czasami ulegaja zmianie: klient przenosi się pod nowy adres, reforma administracyjna w Polsce, zmiana kategoryzacji produktu.

Wolno zmieniajace się wymiary Pierwsze rozwiazanie (najprostsze): nadpisywanie starej informacji. Przykłady: błędna nazwa ulicy, która trzeba poprawić (poprawne podejście), nadpisanie adresu zamieszkania może prowadzić do niespójności w otrzymanych wynikach analizy: Nowak przeprowadził się z Poznania do Warszawy: produkty przez niego zakupione będa odnosić się do miasta Warszawa!!!

Wolno zmieniajace się wymiary Drugie rozwiazanie: tworzenie nowych rekordów ze zmieniona wartościa. Przykłady: podczas zmiany adresu, w wymiarze klienta będa występować dwie krotki: Klient Nazwisko Miasto 23401 Nowak Poznań 23402 Nowak Warszawa stare krotki z tablicy faktów odnosza się do starej krotki w relacji wymiaru nowe krotki z tablicy faktów odnosz a się do nowej krotki w relacji wymiaru.

Wolno zmieniajace się wymiary Trzecie rozwiazanie: tworzenie nowych atrybutów zawierajacych nowe wartości. Przykłady: zmiana podziału administracyjnego w Polsce Obszar Nazwa Nowa nazwa 23401 poznańskie wielkopolskie 23402 pilskie wielkopolskie stare i nowe krotki z tablicy faktów odnosza się do tej samej krotki analizy mog a być przeprowadzone ze względu na dwa różne atrybuty.

Rozdzielanie wymiarów ma swoje uzasadnienie przy uwzględnieniu wolno zmieniajacych się wymiarów. Rozważmy następujacy model: Sprzedaż (tablica faktów), Dział (tablica wymiarów), Miejsce (tablica wymiarów), Sprzedawca (tablica wymiarów), Pensja (atrybut w tablicy Sprzedawca, osobny wymiar dołaczany do relacji Sprzedaż, zdegenerowany wymiar) W przypadku tworzenia osobnego wymiaru trzeba pamiętać, że jedyne połaczenie Sprzedawcy z Pensja przebiega przez relację faktów: brak faktu brak połaczenia.

Macierz procesów biznesowych i wymiarów W celu stworzenia pełnej hurtowni danych dla całego przedsiębiorstwa, bioracej pod uwagę wiele procesów biznesowych, warto jest stworzyć macierz procesów biznesowych i wymiarów (ang. bus matrix).

Dalsze problemy Według pewnych badań 80% zapytań w hurtowniach danych dotyczy relacji wymiarów. Tylko 20% zapytań dotyczy bezpośrednio zapisanych faktów. Przykład zapytania dotyczacej relacji wymiarów Ilu klientów odeszło w ostatnim roku? Z powyższym problemem wiaże się modelowanie systemów zarzadzania relacjami z klientami (CRM) patrz Chris Todman, Projektowanie hurtowni danych.

Celem projektu hurtowni danych jest umożliwienie zadawania odpowiednich zapytań z punktu widzenia decydentów oraz ich efektywne przetworzenie.

Schemat gwiazdy

Zapytania relacyjne Zapytania do hurtowni danych sa często formułowane w standardowym SQL lub SQL3. SQL group by SELECT Name, AVG(Grade) FROM Students_grades G, Student S WHERE G.Student = S.ID GROUP BY Name; Odpowiedź Name AVG(Grade) Inmon 4.8 Kimball 4.7 Gates 4.0 Todman 4.5

SQL group by SELECT Academic_year, Name, AVG(Grade) FROM Students_grades G, Academic_year A, Professor P WHERE G.Professor = P.ID and G.Academic_year = A.ID GROUP BY Academic_year, Name; Odpowiedź Academic_year Name AVG(Grade) 2001/2 Stefanowski 4.2 2002/3 Stefanowski 4.0 2003/4 Stefanowski 3.9 2001/2 Słowiński 4.1 2002/3 Słowiński 3.8 2003/4 Słowiński 3.6 2003/4 Dembczyński 4.8

SQL3 group by rollup SELECT Academic_year, Name, AVG(Grade) FROM Students_grades G, Academic_year A, Professor P WHERE G.Professor = P.ID and G.Academic_year = A.ID GROUP BY ROLLUP Academic_year, Name; Odpowiedź Academic_year Name AVG(Grade) 2001/2 Stefanowski 4.2 2001/2 Słowiński 4.1 2001/2 NULL 4.15 2002/3 Stefanowski 4.0 2002/3 Słowiński 3.8 2002/3 NULL 3.85 2003/4 Stefanowski 3.9 2003/4 Słowiński 3.6 2003/4 Dembczyński 4.8 2003/4 NULL 3.8 NULL NULL 3.95

Zapytania wielowymiarowe Alternatywa dla zapytań relacyjnych sa zapytania wielowymiarowe i język MDX.

Zapytania wielowymiarowe Alternatywa dla zapytań relacyjnych sa zapytania wielowymiarowe i język MDX. Język MDX (Multidimensional Expressions): MDX SELECT [Time].[1997],[Time].[1998] ON COLUMNS, [Measures].[Sales],[Measures].[Cost] ON ROWS FROM Warehouse WHERE ([Store].[All Stores].[USA])

Kostka wielowymiarowa: Możliwa jest większa liczba wymiarów.

Operacje w wielowymiarowym modelu danych: Roll up sumowanie danych wzdłuż hierarchii wymiaru (miasto województwo) Drill down w druga stronę (województwo miasto) Slice and dice selekcja i projekcja wymiarów Pivot zamiana wyświetlanych wymiarów Inne np. tworzenie rankingów, średnie ruchome, itp.

Podsumowanie Trzy cele projektu hurtowni danych: prostota, wyrazistość i wydajność, Najbardziej znany model koncepcyjny hurtowni danych to schemat gwiazdy, Zadanie projektowania hurtowni danych nie jest proste..., Sposoby odpytywania hurtowni danych: SQL, SQL3, wielowymiarowe raporty i język MDX.

Systemy baz i hurtowni danych wprowadzenie do wykładu Modele danych i ewolucja systemów baz danych Projektowanie hurtowni danych i modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL) Systemy OLAP I Systemy OLAP II Systemy OLAP III