Projektowanie hurtowni danych i modelowanie wielowymiarowe

Projektowanie hurtowni danych i modelowanie wielowymiarowe Izabela Szczęch Krzysztof Dembczyński Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska Technologie Wytwarzania Oprogramowania Semestr zimowy 2009/10

Plan wykładu 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 rozwiazanie 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ć agregowane, 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 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.

Pierwsza postać normalna Relacja występuje w pierwszej postaci normalnej 1NF wtedy i tylko wtedy, gdy wszystkie wyjściowe dziedziny zawieraja wyłacznie wartości skalarne.

Druga postać normalna Relacja występuje w drugiej postaci normalnej 2NF wtedy i tylko wtedy, gdy już jest w 1NF oraz każdy niekluczowy atrybut jest nieredukowalnie zależny od klucza głównego.

Trzecia postać normalna Relacja jest w trzeciej postaci normalnej 3NF wtedy i tylko wtedy, gdy już jest w 2NF oraz każdy niekluczowy atrybut jest w sposób nieprzechodni zależny od klucza głównego.

Postać normalna Boyce a-codd a Relacja znajduje sie w BCNF wtedy i tylko wtedy, gdy jedynymi elementami determinujacymi (występujacymy po lewej stronie zależności) sa klucze kandydujace. Redukcja do postaci BCNF jest zawsze możliwa czyli dowolna relację można zastapić równoważnym zbiorem relacjiw BCNF. Celem takiej redukcji jest unikanie redundancji (nadmiarowości), co wiaże się z anomaliami aktualizacji.

Formalna definicja 3NF i BCNF Niech R będzie relacja, X dowolnym zbiorem atrybutów R, a A dowolnym jednym atrybutem z relacji R. Wówczas R jest w 3NF wtedy i tylko wtedy, gdy dla każdej zależności funkcyjnej X A z R jest spełniony przynajmniej jeden z warunków: X zawiera A (zależność jest trywialna), X zawiera klucz kandydujacy z R (czyli X jest kluczem nadrzędnym), A zawiera się w kluczu kandydujacym. Definicję BCNF otrzymujemy z powyższej definicji przez usunięcie ostatniego warunku.

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 zaczać 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 operacyjne źródło, 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 specyficzna 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 niekupionych produktów. Zaleta tego podejścia jest oszczędność pamięci jeżeli wydarzenia występuja rzadko. Wada 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 sztuczny 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 odnosza 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 moga 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 sie 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

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.