Projektowanie hurtowni danych

Krzysztof Dembczyński Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska Technologie Wytwarzania Oprogramowania Semestr zimowy 2004/05

Plan wykładu Ewolucja systemów baz danych Modele danych i ich ewolucja Systemy OLAP Proces ekstrakcji, transformacji i ładowania (ETL) Internet jako baza danych (Dawid Weiss) Rozszerzenia systemów OLAP Eksploracja hurtowni danych Rozmyte zapytania do baz danych

Plan wykładu 1 Logiczne projetkowanie hurtowni danych 2 Schematy logiczne hurtowni danych 3 Modelowanie koncepcyjne hurtowni danych 4 Dodatkowe aspekty modelowania

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

Cele projetkowania hurtowni danych Prostota: Użytkownik powinien rozumieć projekt, Stworzony model powinien odpowiadać modelowi konceptualnemu, który jest prezentowany przez użytkownika, Zapytania powinny być formułowane prosto i intuicyjnie.

Cele projetkowania hurtowni danych Wyrazistość: Zawierać wszystkie potrzebne informacje, aby umożliwić odpowiedź na wszystkie ważne zapytania, Zawiarać odpowiednie dane.

Cele projetkowania hurtowni danych Wydajność: Efektywne rozwiazanie fizyczne powinno być możliwe do zastosowania.

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

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

Schemat gwiazdy 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.

Schemat gwiazdy 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.

Schemat gwiazdy

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

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

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

Schemat wielokrotnych tablic faktów 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

Modelowanie koncepcyjne hurtowni danych Cztery kroki modelowania koncepcyjnego hurtowni danych: Wybór procesu biznesowego do zamodelowania Zdefiniowanie ziarna (rozdzielczości) procesu biznesowego Wybór wymiarów znajdujacych się w każdej krotce tablicy faktów Identyfikacja miar, które wypełnia każda krotkę tablicy faktów

Modelowanie koncepcyjne hurtowni danych Wybór procesu biznesowego do zamodelowania: powinna to być naturalna aktywność przedsiębiorstwa, wspomagana przez operacyjne system źródłowe, moga to być: 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.

Modelowanie koncepcyjne hurtowni danych 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.

Modelowanie koncepcyjne hurtowni danych 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.

Modelowanie koncepcyjne hurtowni danych 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, cześć miar może być częściowo-addytywna (liczba jabłek i pomarańczy),

Modelowanie koncepcyjne hurtowni danych 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 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.

Wymiar czasu 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 czasu W przypadku potrzeby zapisywania daty oraz dokładnego czasu w ciagu dnia warto zamodolować wymiar czasu za pomoca dwóch tabel: Data i Czas_dnia.

Wymiar czasu 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 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.

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, Produkt,...), ID jest jedynie unikalnym identyfikatorem, ID pozwala na połaczenie produktów zakupionych w jednym koszyku (pozwala na analizę wielkości koszyka).

Zdegenerowane wymiary Wymiary takie jak ID 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 Zdegenerowany wymiar: 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 :) 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 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 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.

Rozdzielanie wymiarów 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 czasu 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,.

Plan wykładu Ewolucja systemów baz danych Modele danych i ich ewolucja Systemy OLAP Proces ekstrakcji, transformacji i ładowania (ETL) Internet jako baza danych (Dawid Weiss) Rozszerzenia systemów OLAP Eksploracja hurtowni danych Rozmyte zapytania do baz danych