plik


ÿþProjektowanie schematów logicznych dla magazynów danych Bartosz Bbel, MikoBaj Morzy Politechnika PoznaDska, Instytut Informatyki ul. Piotrowo 3A, 60-965 PoznaD Bartosz.Bebel@cs.put.poznan.pl, Mikolaj.Morzy@cs.put.poznan.pl Abstrakt. Technologia magazynów danych pozwala na aktywne wykorzystanie informacji posiadanych przez przedsibiorstwo do podejmowania strategicznych decyzji, okre[lania trendów rynkowych lub zarzdzania zasobami. W artykule przedstawiono model tworzenia korporacyjnego magazynu danych i szczegóBowo opisano metodologi projektowania schematów baz danych dla potrzeb magazynów danych. Poszczególne zagadnienia zostaBy zobrazowane praktycznymi przykBadami. 1. Wstp Wikszo[ wspóBczesnych przedsibiorstw stara si wykorzystywa najnowsze technologie do zwikszenia konkurencyjno[ci i odniesienia sukcesu ekonomicznego. Jedn z popularnych metod jest aktywne wykorzystanie informacji gromadzonych na przestrzeni lat przez te przedsibiorstwa. Mo|liwo[ dokBadnej analizy tych informacji pozwala na popraw jako[ci procesu podejmowania decyzji oraz na zwikszenie dochodowo[ci poprzez szybsze reagowanie na zmiany zachodzce w otoczeniu przedsibiorstwa. Podstawow przeszkod na drodze aktywnej analizy danych i informacji zgromadzonych przez przedsibiorstwo jest niekompatybilno[ licznych systemów transakcyjnych obsBugujcych bie|c dziaBalno[ przedsibiorstwa. Systemy obsBugi bie|cej nie s dostosowane do potrzeb procesu wspomagania decyzji i czsto zawieraj niespójne informacje. W celu przezwyci|enia tych problemów w ostatnich latach rozwinBa si technologia magazynów danych (ang. data warehouse). Magazyn danych jest zbiorem kluczowych informacji wykorzystywanych do zarzdzania przedsibiorstwem. Informacjami mog by dane pomagajce decydowa o poziomie zapasów w magazynie, dane demograficzne do przeprowadzania kampanii promocyjnych, czy te| podsumowania i dane zbiorcze wspomagajce podejmowanie strategicznych decyzji na poziomie makroekonomicznym. Magazyn danych to nie tylko tematycznie zorientowane dane, ale tak|e caBy proces ekstrakcji informacji z heterogenicznych zródeB danych (systemy transakcyjne, sie WWW, arkusze kalkulacyjne, pliki tekstowe) do relacji w bazie danych, oraz przetwarzania danych do postaci atrakcyjnej dla analityków i decydentów. Podsumowujc, magazynem danych nazywamy dane (metadane, fakty, wymiary, agregaty) oraz procesy (Badowanie, od[wie|anie, odpytywanie), które wspólnie udostpniaj dane i umo|liwiaj decydentom podejmowanie strategicznych decyzji. Niniejszy artykuB jest zorganizowany nastpujco. W rozdziale 2 przedstawiono szczegóBowo proces konstruowania magazynu danych. RozdziaB 3 po[wicony jest metodom tworzenia logicznego schematu bazy danych, ze szczególnym uwzgldnieniem projektowania relacji faktów, relacji wymiarów i relacji zbiorczych. RozdziaB 4 stanowi krótkie podsumowanie. Wiele zagadnieD zostaBo zobrazowanych przykBadami zaczerpnitymi z dziedziny telefonii komórkowej. Schemat logiczny magazynu danych dla firmy telekomunikacyjnej, do którego odnosz si przykBady, zostaB przedstawiony w zaBczniku A. 264 Bartosz Bbel, MikoBaj Morzy 2. Proces konstruowania magazynu danych Rozwizania stosowane w dziedzinie magazynów danych ró|ni si zasadniczo od rozwizaD stosowanych w tradycyjnych systemach transakcyjnych. Podstawowa ró|nica polega na tym, |e magazyny danych nigdy nie s statyczne, lecz nieustannie zmieniaj si by odzwierciedli ewolucj przedsibiorstwa i jego zmieniajce si potrzeby. W praktyce oznacza to, |e magazyny danych musz by projektowane w elastyczny sposób, który bdzie pozwalaB na Batwe wprowadzanie modyfikacji do struktury magazynu danych. KBopot polega na tym, |e w momencie konstruowania magazynu danych przyszBe potrzeby i wymagania s w ogólno[ci nieznane. Z powodu nieustannie zmieniajcych si wymagaD proces konstrukcji magazynu danych ró|ni si fundamentalnie od metodologii stosowanej powszechnie w przypadku systemów transakcyjnych. Tradycyjne podej[cie zakBadajce rozpoczcie projektowania architektury i struktury systemu po uprzednim zakoDczeniu fazy analizy mo|e Batwo doprowadzi do  parali|u przez analiz , poniewa| najcz[ciej peBne zebranie wszystkich wymagaD jest niemo|liwe. W rzeczywisto[ci konieczne jest konstruowanie magazynu danych na podstawie aktualnie dostpnych wymagaD oraz tego, co projektanci mog przewidzie na temat przyszBych zastosowaD, wymagaD, profilów zapytaD i innych parametrów projektowanego magazynu danych. Na rysunku 1 przedstawiono ogólny schemat procesu tworzenia magazynu danych. Rys. 1. Proces tworzenia magazynu danych " Strategia Magazyn danych jest strategiczn inwestycj przedsibiorstwa, a koszty jego budowy mog by bardzo wysokie. Projekt powinien mie[ci si w ramach szerszej strategii informatycznej przedsibiorstwa, poniewa| w przeciwnym wypadku jego finansowanie mo|e okaza si trudne. Projektowanie schematów logicznych dla magazynów danych 265 " Analiza ekonomiczna Celem tej fazy jest identyfikacja wszystkich zysków, jakie przedsibiorstwo osignie poprzez implementacj magazynu danych. Nawet je[li zakBadane zyski nie s wymierne, powinny by jasno okre[lone na samym pocztku projektu. " Edukacja i prototyp Magazyn danych stwarza nowe mo|liwo[ci, ale te| wymaga od u|ytkowników nowych umiejtno[ci. Dobrym pomysBem jest stworzenie prototypu, za pomoc którego przyszli u|ytkownicy posid wymagane umiejtno[ci i nabior zaufania do nowej technologii. Prototyp nie powinien by zacztkiem magazynu danych, tzn. nie powinien by dalej rozwijany, poniewa| architektura prototypu jest najprawdopodobniej nieskalowalna w kontek[cie caBego magazynu danych. " Wymagania ekonomiczne W trakcie tej fazy okre[la si logiczny model informacji przechowywanej w magazynie danych, systemy zródBowe z których czerpie si informacje, reguBy ekonomiczne stosujce si do informacji, profile zapytaD kierowanych do magazynu danych, itp. PrawidBowe zrozumienie krótko- i [rednioterminowych potrzeb przedsibiorstwa pozwala na zbudowanie efektywnego magazynu danych, który bdzie odpowiadaB aktualnym wymaganiom i bdzie mógB ewoluowa w momencie pojawienia si nowych wymagaD. Ponadto nale|y przeznaczy nieco wysiBku na okre[lenie prawdopodobnych potrzeb dBugoterminowych. Znajomo[ takich potrzeb pozwala na elastyczn konstrukcj magazynu danych. " Projekt techniczny W fazie projektu technicznego nale|y okre[li caBoksztaBt architektury speBniajcej dBugoterminowe wymagania, oraz wszystkie komponenty konieczne do implementacji magazynu danych. Projekt musi okre[li m.in.: ogóln architektur systemu, architektur serwera i tematycznych magazynów danych, najwa|niejsze elementy schematu bazy danych, okres przechowywania danych w magazynie, strategie archiwizowania i odtwarzania magazynu oraz plan obci|enia sprztu. Na tym etapie nie tworzy si szczegóBowego schematu logicznego magazynu danych, lecz tylko identyfikuje jego najwa|niejsze komponenty. " Budowanie wizji GBównym celem tego etapu jest dostarczenie maBego, w peBni funkcjonalnego prototypu. Najcz[ciej tworzony jest system stanowicy niewielki fragment planowanego magazynu. Gotowy prototyp powinien zaspokaja najbardziej palce potrzeby informatyczne przedsibiorstwa. " Aadowanie historii W trakcie tej fazy magazyn danych nie jest rozbudowywany  wszerz (dodawanie nowych encji) lecz  w gBb (poszerzanie horyzontu czasowego informacji przechowywanych w magazynie danych). Je[li w fazie budowania wizji do magazynu danych zaBadowano dane obejmujce ostatnie trzy miesice poBczeD telefonicznych, to w fazie Badowania historii do magazynu danych zostan dodane wszystkie pozostaBe informacje o poBczeniach na przestrzeni ostatnich lat. GwaBtowny wzrost wolumenów danych, jaki pojawia si w tej fazie, komplikuje zagadnienia zwizane z pielgnacj i utrzymaniem magazynu. Na tym etapie nale|y opracowa dokBadne strategie tworzenia kopii zapasowych bazy danych, odtwarzania po awarii, partycjonowania danych, itp. " Zapytania ad hoc Kolejna faza projektowania magazynu danych polega na dokBadnej analizie profili zapytaD wydawanych przez u|ytkowników i strojeniu narzdzi dostpu do bazy danych. Wikszo[ u|ytkowników magazynu danych nie potrafi operowa jzykiem SQL i do wydawania zapytaD wykorzystuje ró|nego rodzaju wizualne generatory zapytaD. Zadaniem projektantów magazynu danych jest takie skonfigurowanie tych narzdzi dostpu, aby generowane przez nie plany 266 Bartosz Bbel, MikoBaj Morzy wykonania zapytania byBy mo|liwie efektywne. Zadanie to mo|e wymaga wprowadzenia licznych zmian w strukturze bazy danych (statystyki, dodatkowe indeksy, dodatkowe perspektywy, itp.), std powinno by wykonane jako osobna faza procesu konstrukcji magazynu danych. " Automatyzacja Ta faza polega na zautomatyzowaniu mo|liwie du|ej cz[ci procesu zarzdzania magazynem danych. W[ród skBadowych tego procesu, które mog podlega automatyzacji, wymieni nale|y: ekstrakcj i Badowanie danych z systemów zródBowych, transformacj danych, tworzenie kopii zapasowych, odtwarzanie i archiwizacj danych, tworzenie predefiniowanych agregatów, monitorowanie profili najczstszych zapytaD. " Rozszerzanie zakresu W fazie rozszerzania zakresu magazyn danych jest rozbudowywany w ten sposób, aby funkcjonalnie obj nowe wymagania ekonomiczne. Najcz[ciej zmiany dotycz dodawania nowych encji oraz wprowadzania nowych zródeB informacji, cho czasem rozszerzenie magazynu danych mo|e polega tylko na dodaniu nowych perspektyw i agregatów na podstawie informacji, które ju| s obecne w magazynie. WysiBek i zBo|ono[ tej operacji w peBni usprawiedliwia umieszczenie jej w ramach osobnej fazy procesu konstruowania magazynu danych. " Ewolucja wymagaD Jak ju| wspomniano wcze[niej, najwa|niejsz cech procesu tworzenia magazynu danych jest to, |e wymagania funkcjonalne dotyczce magazynu nigdy nie s statyczne, lecz ewoluuj wraz z dziaBalno[ci przedsibiorstwa i zmieniajcymi si warunkami rynku. W celu zapewnienia magazynowi danych maksymalnej elastyczno[ci, system taki powinien by konstruowany przede wszystkim w oparciu o szeroko pojty model dziaBania przedsibiorstwa, a nie w oparciu o wymagania konkretnych zapytaD. Bardzo istotne jest, aby zmiany wymagaD byBy nieustannie monitorowane i sygnalizowane projektantom. 3. Schemat logiczny magazynu danych W przypadku magazynów danych najcz[ciej stosuje si schemat gwiazdy (ang. star schema), schemat pBatka [niegu (ang. snowflake schema) lub schemat hybrydowy (ang. starflake schema). Wynika to z tego, |e schematy gwiazdziste i ich pochodne najlepiej przystaj do zapytaD wydawanych w systemach wspomagania decyzji. Wikszo[ zapytaD posiada podobn struktur: analizuj zbiór szczegóBowych informacji (transakcje dotyczce rozmów telefonicznych, zdarzenia zwizane z u|ytkownikami i klientami) poprzez agregacj i grupowanie informacji wzgldem ró|nych kryteriów (przedziaBy czasowe, typy abonamentu, lokalizacje geograficzne). Taki profil zapytaD wymusza pewn logiczn organizacj bazy danych. SzczegóBowe informacje opisujce transakcje znajduj si w centrum, za[ otaczaj je opisy kryteriów. Centralna relacja zawierajca szczegóBowe dane nazywana jest relacj faktów (ang. fact table). Informacje referencyjne, takie jak hierarchie regionów geograficznych, przedziaBy czasowe, grupy produktów, itd., umieszczone s w relacjach wymiarów (ang. dimension tables). Oprócz tego w magazynie danych mog si znalez dane zbiorcze, przechowywane w relacjach zbiorczych (ang. summary tables). PoBczone relacje faktów i wymiarów tworz schemat gwiazdy. Informacje przechowywane w magazynie danych dziel si na dwie rozBczne klasy: informacje faktyczne i referencyjne. Informacja faktyczna opisuje fizyczne wystpienie zdarzenia w [wiecie rzeczywistym. Zdarzeniem takim mo|e by transakcja w sklepie, poBczenie telefoniczne, operacja bankowa lub |danie wypBacenia ubezpieczenia. W wikszo[ci magazynów danych informacje faktyczne stanowi ponad 70% zawarto[ci caBego magazynu. Poniewa| wikszo[ zapytaD odwoBuje si do informacji faktycznych, relacje faktów musz by projektowane bardzo starannie. Ich zawarto[ oraz format przechowywanych w nich danych musz zosta dokBadnie ustalone w fazie zbierania wymagaD ekonomicznych. Relacje faktów zawieraj najcz[ciej miliony krotek, s w wikszo[ci typu numerycznego i po wprowadzeniu do magazynu danych nie ulegaj zmianom. Projektowanie schematów logicznych dla magazynów danych 267 Informacje referencyjne opisuj wymiary, wedBug których s analizowane dane faktyczne. Charakter informacji referencyjnych ró|ni si znaczco od informacji faktycznych. Relacje wymiarów s du|o mniejsze od relacji faktów i zawieraj setki lub tysice krotek, najcz[ciej s BaDcuchami znaków (tekstowymi opisami) i czsto mog ulega modyfikacji. Informacje zbiorcze to zagregowane kopie szczegóBowych informacji przechowywanych w relacjach faktów. W przeciwieDstwie do faktów informacje zbiorcze maj charakter tymczasowy i ulegaj czstym modyfikacjom. Celem wstpnego obliczania informacji zbiorczych jest przede wszystkim przyspieszenie wykonywania wspólnych cz[ci zapytaD. Liczba relacji zbiorczych, wystpujcych w magazynie danych jest [ci[le zwizana z charakterem magazynu, jego przeznaczeniem, profilami zapytaD, itp. Najcz[ciej magazyny danych zawieraj kilkadziesit ró|nych relacji zbiorczych. Obok informacji faktycznych, referencyjnych i zbiorczych w magazynie danych przechowywane s równie| metadane, czyli dane opisujce zawarto[ magazynu. W ramach metadanych przechowywane s szczegóBowe informacje o poBo|eniu i charakterystyce ka|dego z zewntrznych zródeB danych, definicje wszystkich agregatów, informacje pozwalajce na kierowanie zapytaD do najbardziej adekwatnych fragmentów magazynu danych. Poza tym w metadanych zawarte s wszystkie informacje niezbdne dla dziaBania magazynu danych: statystyki, szczegóBy dotyczce strategii archiwizowania i odtwarzania magazynu, itp. 3.1. Identyfikowanie faktów Czsto projektanci maj kBopoty z poprawnym rozró|nieniem faktów i wymiarów. Poni|ej przedstawiono metod pozwalajc na jednoznaczne zidentyfikowanie tych encji, które w magazynie danych bd reprezentowane jako fakty. 3.1.1. Wyszukanie transakcji elementarnych Pierwszym krokiem w identyfikacji faktów jest analiza modelu przedsibiorstwa i wyszukanie tych transakcji, które s fundamentalne z punktu widzenia dziaBalno[ci przedsibiorstwa. PrzykBadami takich transakcji s: " dla handlu: transakcje zakupu w sklepie, wahania kursów gieBdowych, " dla bankowo[ci: operacje na kontach bankowych, zmiany typów kont, zaBo|enie lub likwidacja konta, " dla firm ubezpieczeniowych: |dania wypBacenia odszkodowania, podpisanie nowej polisy, zmiana warunków polisy, " dla firm telekomunikacyjnych: poBczenia telefoniczne, wpBynicie opBaty, podBczenie lub odBczenie klienta. Nale|y przy tym pamita, |e nie wszystkie dane szczegóBowe musz koniecznie by faktami. StopieD szczegóBowo[ci danych mo|e wynika z charakterystyki zródBa danych, a nie z rzeczywistego modelu informacyjnego przedsibiorstwa. 3.1.2. Okre[lenie kluczowych wymiarów dla faktów Nastpnym krokiem jest identyfikacja podstawowych wymiarów dla ka|dej potencjalnej relacji faktów. Na podstawie analizy modelu logicznego nale|y znalez te wymiary, które zostan wBczone do relacji faktów jako klucze obce. W niektórych przypadkach konieczna bdzie restrukturyzacja modelu logicznego. PrzykBadowo, je[li relacj faktów jest relacja reprezentujca operacje na koncie bankowym, to mo|e ona by poBczona z relacj WBa[ciciel-konta poprzez relacje Konto i Konto-Posiadane-Przez. Je|eli wikszo[ zapytaD analizuje transakcje bankowe z perspektywy poszczególnych wBa[cicieli, to do relacji faktów nale|y bezwzgldnie doda klucz obcy reprezentujcy wBa[ciciela konta. Dziki temu wszystkie zapytania analizujce transakcje bankowe wedBug wBa[cicieli unikn kosztownych operacji poBczeD. 268 Bartosz Bbel, MikoBaj Morzy 3.1.3. Sprawdzenie, czy potencjalny fakt nie jest wymiarem W systemach obsBugi bie|cej wiele relacji zródBowych mo|e zawiera pomieszane fakty i wymiary. Dzieje si tak, poniewa| relacje zródBowe zostaBy skonstruowane pod ktem speBniania konkretnych wymagaD systemu obsBugi. Jako przykBad rozwa|my relacj Klient. Zawiera ona identyfikator, nazwisko, dat podpisania umowy, dat wyga[nicia umowy, rodzaj abonamentu. W rzeczywisto[ci faktami s tu daty wystpienia poszczególnych zdarzeD, za[ to|samo[ klienta i typ abonamentu s wymiarami. Dobrym testem pozwalajcym na zidentyfikowanie takiej sytuacji jest: " sprawdzenie, czy potencjalna relacja faktów nie jest relacj wymiarów zawierajc powtarzajce si grupy faktów, " sprawdzenie, czy potencjalna relacja faktów nie bdzie w przyszBo[ci ulegaBa modyfikacjom. Je[li istnieje prawdopodobieDstwo, |e krotki w tej relacji bd ulega w przyszBo[ci modyfikacji, to nale|y tak relacj kandydujc podzieli na fakty i wymiary. 3.1.4. Sprawdzenie, czy potencjalny wymiar nie jest faktem Niektóre encje mog by jednocze[nie postrzegane jako fakty i wymiary. Encja Klient jest faktem w przypadku magazynu danych nakierowanego na marketing i budowanie profili klientów, za[ w magazynie danych dla analizy sprzeda|y detalicznej staje si wymiarem. Wybór klasy, do której nale|y dana encja, zale|y od charakteru konstruowanego magazynu danych. W przypadku zaistnienia wtpliwo[ci nale|y sprawdzi, z ilu ró|nych wymiarów mo|na postrzega dan encj. Je[li takich wymiarów jest wicej ni| trzy, to encja jest prawdopodobnie faktem. 3.2. Projektowanie relacji faktów Tworzc relacje faktów projektant powinien odpowiednio zrównowa|y warto[ informacji przechowywanej w takiej relacji i koszt jej utworzenia. Czynniki, takie jak poziom szczegóBowo[ci informacji lub horyzont czasowy danych, powinny by skorelowane z kosztem pielgnowania i modyfikowania relacji faktów. Poni|ej przedstawiono kilka technik, które pozwalaj znaczco obni|y koszt utworzenia i pielgnacji relacji faktów, zachowujc jednocze[nie jej jako[. 3.2.1. Identyfikacja horyzontu czasowego dla ka|dej z funkcji Projektanci magazynów danych czsto popeBniaj bBd polegajcy na zaBo|eniu, |e szczegóBowe informacje faktyczne musz by przechowywane w magazynie danych przez dBugi okres czasu, np. przez 10 lat. Powszechny jest tak|e brak ró|nicowania stopnia szczegóBowo[ci przechowywanych danych w zale|no[ci od ich wieku. W rzeczywisto[ci takie podej[cie mo|e negatywnie wpByn na efektywno[ zapytaD kierowanych do magazynu danych. Opracowanie strategii stopniowego agregowania danych wraz z ich starzeniem si mo|e znaczco zmniejszy objto[ wolumenu danych przechowywanych w relacji faktów, a co za tym idzie, przyspieszy wykonywanie zapytaD. Najcz[ciej szczegóBowe dane nie musz by przechowywane przez okres dBu|szy ni| kilka lat. Dla raportów rocznych wystarczajce powinny by agregaty sumujce fakty z dokBadno[ci do tygodnia. Dla zapytaD odczytujcych fakty starsze ni| 5 lat najprawdopodobniej w zupeBno[ci wystarczaj podsumowania miesiczne zamiast dziennych, itd. Pomocne dla projektanta mo|e okaza si stworzenie wykresu, na którym dla ka|dej funkcji (typu zapytania) znajd si przedziaBy czasowe, w jakich poszczególne fakty musz by szczegóBowe. 3.2.2. Czy dane szczegóBowe mo|na zastpi próbkowaniem? Inn metod znacznego zmniejszenia objto[ci relacji faktów jest zastpienie danych szczegóBowych przez reprezentatywn próbk. Reszta danych jest przechowywana wówczas jako dzienne lub tygodniowe agregaty. Ta technika znajduje zastosowanie przede wszystkim w przypadku magazynów danych, dla których znajomo[ wszystkich szczegóBowych faktów jest niepotrzebna. Je[li firma pragnie przeanalizowa schematy zachowaD abonentów w okresie letnim, to taka analiza mo|e by z powodzeniem dokonana na próbce zawierajcej 15% faktów opisujcych Projektowanie schematów logicznych dla magazynów danych 269 rozmowy midzy abonentami. Z drugiej strony, je[li firma pragnie przeprowadzi zogniskowan kampani reklamow dotyczc szczególnego segmentu rynku, próbkowanie mo|e okaza si niewystarczajce, poniewa| w próbce znajdzie si zbyt maBo faktów opisujcych zachowania docelowych abonentów. 3.2.3. Wybór wBa[ciwych atrybutów Kolejnym krokiem jest usunicie z relacji faktów wszystkich zbdnych atrybutów. Dla ka|dego atrybutu nale|y zada pytania:  Czy ten atrybut wnosi jak[ now wiedz o fakcie? ,  Czy istnieje jakie[ inne miejsce, skd mo|na wywie[ t dan? ,  Czy atrybut ma istotne znaczenie, czy mo|e sBu|y do celów zwizanych z implementacj systemu? . Dane wywiedzione lub agregaty nie powinny by przechowywane w relacji faktów, poniewa| bardziej efektywne jest generowanie tych informacji  w locie . Wszystkie atrybuty, które s obecne w relacji faktów tylko ze wzgldu na specyficzne potrzeby systemu obsBugi bie|cej, z którego pobrano fakty, powinny by bezwzgldnie usunite z magazynu danych. W przypadku firmy telekomunikacyjnej atrybuty, które powinny si znalez w relacji faktów, to: numer inicjujcy poBczenie, numer docelowy, data poBczenia, oraz czas trwania poBczenia. 3.2.4. Minimalizacja rozmiarów atrybutów w relacji faktów Projektanci baz danych maj tendencj do przeszacowywania rozmiarów atrybutów w poszczególnych relacjach. W przypadku magazynu danych zmniejszenie rozmiaru jednego atrybutu o jeden bajt mo|e zaowocowa znaczcym zmniejszeniem rozmiaru relacji, a co za tym idzie, popraw ef ektywno[ci wykonywania zapytaD. Je[li relacja faktów zawiera informacje o dwóch milionach abonentów, z których ka|dy dzwoni [rednio dwa i póB raza dziennie (zakBadamy dwuletni horyzont czasowy dla szczegóBowych faktów), to w relacji faktów zawartych jest 3.65 miliarda krotek. Zmniejszenie rozmiaru któregokolwiek z atrybutów o dziesi bajtów spowoduje zmniejszenie relacji o 34 gigabajty. 3.2.5. Wybór pomidzy kluczami naturalnymi i sztucznymi Klucze obce wystpujce w relacji faktów mog by naturalne (ka|dy klucz reprezentuje jednoznaczny identyfikator obiektu w [wiecie rzeczywistym), lub sztuczne (ka|dy klucz jest generowany automatycznie). Kluczami naturalnymi s np. numer PESEL, data lub numer przedstawicielstwa/sklepu. Kluczami sztucznymi s np. identyfikator klienta (wi|cy dany fakt z identyfikatorem w relacji wymiaru Klienci), identyfikator daty (wi|cy dany fakt z konkretn dat przechowywan w relacji Czas) lub identyfikator sklepu. U|ycie kluczy naturalnych mo|e okaza si bardzo korzystne. Je[li zapytanie odnosi si bezpo[rednio do warto[ci klucza, to do skonstruowania odpowiedzi wystarczy odczyt samej relacji faktów, bez konieczno[ci dokonywania poBczenia z relacj wymiarów. Z drugiej strony, je[li jaki[ identyfikator naturalny ulega zmianie, wówczas taka zmiana musi zosta odzwierciedlona w relacji faktów. Koszt wykonania modyfikacji relacji faktów mo|e by bardzo wysoki i takiej operacji nale|y za wszelk cen unika. Je|eli projektant jest absolutnie pewien, |e warto[ci identyfikatorów nie ulegn w przyszBo[ci |adnym zmianom, powinien u|y kluczy naturalnych. W przeciwnym wypadku powinien u|ywa kluczy sztucznych. 3.2.6. Modelowanie czasu w relacji faktów Czas mo|na modelowa podobnie jak wszystkie inne wymiary, tj. poprzez skBadowanie w relacji faktów sztucznego klucza do relacji wymiarów, w której przechowywane s fizyczne daty. Jednak|e bardziej efektywn metod jest skBadowanie czasu za pomoc klucza naturalnego bezpo[rednio w relacji faktów. Istniej w ogólno[ci trzy metody skBadowania czasu w relacji faktów. 270 Bartosz Bbel, MikoBaj Morzy " SkBadowanie fizycznej daty Ta metoda zakBada skBadowanie w relacji faktów atrybutu Data. Jest bardzo efektywna zarówno w przypadku zapytaD odwoBujcych si do dokBadnego znacznika czasowego (ang. timestamp), jak i samej daty z dokBadno[ci do dnia. W przypadku dat nie zachodzi niebezpieczeDstwo modyfikacji warto[ci atrybutu w przyszBo[ci, za[ zysk wynikajcy z przyspieszenia wykonywania zapytaD (nie trzeba wykonywa dodatkowego poBczenia z relacj wymiarów Czas) jest ogromny. Nale|y przy tym pamita, |e w [rodowisku magazynów danych znakomita wikszo[ zapytaD dotyczy, w ten czy inny sposób, czasu. " SkBadowanie przesunicia od wBa[ciwego pocztku relacji Jest bardzo prawdopodobne, |e relacja faktów podlega partycjonowaniu wzgldem czasu (patrz 3.3). Najcz[ciej poszczególne partycje reprezentuj okresy czasowe, np. tydzieD, miesic lub kwartaB. Modelujc czas w relacji faktów mo|na wykorzysta fakt partycjonowania poprzez skBadowanie w tej relacji przesunicia danego faktu wzgldem wBa[ciwego pocztku partycji. Na przykBad, je|eli relacja faktów jest podzielona na miesiczne partycje, a fakt miaB miejsce 9-go dnia miesica, to w odpowiedniej partycji zostanie umieszczona liczba 8 (zakBadamy, |e pierwszy dzieD miesica odpowiadajcego danej partycji ma indeks 0). Taka reprezentacja niesie ze sob ogromn oszczdno[ przestrzeni dyskowej, poniewa| teraz do reprezentowania ka|dej daty w zupeBno[ci wystarcz dwa bajty. Co wicej, wBa[ciwa data pocztkowa danej partycji nie musi by nigdzie przechowywana, poniewa| mo|e by na staBe zaszyta w nazwie partycji, np. Abonenci_lipiec_2000. Wad tego rozwizania jest fakt, |e ka|de zapytanie operujce na datach fizycznych musi by wpierw poddane konwersji do formy uwzgldniajcej przesunicie. Ka|da taka transformacja niesie ze sob dodatkowy koszt. Poza tym niektóre narzdzia dostpu mog by niekompatybilne z takim modelem. W takim wypadku rozwizaniem mo|e by zdefiniowanie na partycji perspektywy, która dokona odpowiedniej konwersji. " SkBadowanie zakresów dat W przypadku niektórych relacji faktów poszczególne krotki takiej relacji reprezentuj f akty, których wa|no[ rozciga si na pewien okres. Je[li relacja faktów opisuje stan magazynu, to najprawdopodobniej tylko maBa cz[ produktów jest kupowana danego dnia, za[ wikszo[ produktów nie zmienia swego stanu magazynowego. W takim wypadku bardziej opBacalne jest odnotowywanie tylko tych faktów (pozycji magazynowych), które ulegBy zmianom. Ka|da krotka w relacji faktów opisuje stan jakiego[ produktu, który obowizywaB od dnia Data_od do dnia Data_do. Je[li ilo[ jakiego[ produktu nie ulega zmianie, to zamiast wstawia now krotk do relacji faktów, zwiksza si o 1 warto[ atrybutu Data_do. Taka technika mo|e prowadzi do znacznych oszczdno[ci przestrzeni dyskowej. Je[li ka|dego dnia sprzedawanych jest 10% produktów z katalogu, to wykorzystywanie kodowania dat za pomoc zakresów obowizywania powoduje zmniejszenie relacji faktów do okoBo 10% objto[ci pocztkowej relacji (poniewa| pojawia si dodatkowy atrybut Data_do). To podej[cie jest obci|one tymi samymi wadami, co skBadowanie przesunicia wzgldem pocztku partycji. Zapytania staj si bardziej skomplikowane, a niektóre narzdzia dostpu nie bd mogBy sobie poradzi z tak organizacj skBadowania czasu. Aby temu zapobiec, mo|liwe jest wykorzystanie dodatkowej relacji zawierajcej krotk dla ka|dej kolejnej daty. Relacja faktów jest Bczona z relacj zawierajc daty w celu utworzenia produktu kartezjaDskiego. Niestety, utworzenie produktu kartezjaDskiego jest kosztowne i wymaga przestrzeni tymczasowej. Je|eli wikszo[ zapytaD wykorzystuje tak perspektyw, skBadowanie zakresów dat mo|e okaza si zBym wyborem. Generalnie zaleca si, aby wykorzystywa wy|ej opisan metod tylko w tych przypadkach, w których narzdzia dostpu mog bezpo[rednio wykorzystywa zakresy dat i nie wymagaj tworzenia produktu kartezjaDskiego. Projektowanie schematów logicznych dla magazynów danych 271 3.3. Partycjonowanie faktów Partycjonowanie polega na dzieleniu logicznej encji na mniejsze podencje. Dzielenie du|ych relacji na podrelacje ma na celu m.in.: " Zwikszenie efektywno[ci zapytaD: pojedyncze zapytanie wykonuje si du|o szybciej, je[li zamiast jednej ogromnej relacji musi odczyta zbiór maBych partycji. Wi|e si z tym jednak problem automatycznego kierowania zapytaD do odpowiednich partycji. " UBatwienie zarzdzania relacjami: relacje faktów czsto rozrastaj si do monstrualnych rozmiarów. Administrowanie relacj o rozmiarze rzdu setek gigabajtów mo|e by trudne lub wrcz niemo|liwe. Dotyczy to zmian w strukturze relacji, zakBadania indeksów, modyfikowania podzbiorów krotek, itp. " UBatwienie archiwizowania i odtwarzania: archiwizowanie relacji faktów zawierajcej wszystkie aktualne dane mo|e by technicznie niewykonalne bez wyBczenia magazynu danych. Przy wykorzystaniu partycjonowania administrator mo|e pozostawi aktywn tylko aktualn partycj, za[ wszystkie pozostaBe oznaczy jako partycje  tylko do odczytu i stopniowo je archiwizowa. Istnieje kilka podstawowych metod partycjonowania relacji faktów. 3.3.1. Partycjonowanie wedBug czasu na segmenty o jednakowym rozmiarze To podstawowa metoda partycjonowania polegajca na podziale relacji faktów na segmenty odpowiadajce takim samym przedziaBom czasowym. Rozmiar przedziaBu zale|y od charakteru magazynu danych i jego przeznaczenia. Je|eli wikszo[ zapytaD kierowanych do magazynu dokonuje raportów miesicznych, to relacja faktów powinna by podzielona na partycje odpowiadajce poszczególnym miesicom. Nale|y przy tym pamita, |e ogólna liczba partycji nie powinna przekroczy kilkudziesiciu, poniewa| zarzdzanie relacj podzielon na zbyt du| liczb segmentów mo|e sta si kosztowne. 3.3.2. Partycjonowanie wedBug czasu na segmenty o ró|nych rozmiarach Je|eli starsze dane s odczytywane rzadziej ni| nowsze, to dobr metod jest podzielenie relacji faktów na segmenty o ró|nych rozmiarach. Najcz[ciej tworzy si w takim wypadku kilka maBych partycji dla danych z ostatnich kilku miesicy, kilka [rednich partycji dla mniej aktualnych danych sprzed póB roku, oraz zbiór du|ych partycji dla rzadko odczytywanych danych pochodzcych sprzed kilku lat. GBówn zalet tego podej[cia jest to, |e najcz[ciej wykorzystywane dane przechowywane s w maBych partycjach, co wydatnie przyspiesza ich odczyt. Poza tym ogólna liczba partycji jest utrzymywana na niskim poziomie. Podstawow wad tej metody jest fakt, |e w regularnych odstpach czasu profil partycjonowania si zmienia i administrator musi przenosi bardzo du|e ilo[ci danych pomidzy partycjami, co mo|e okaza si bardzo kosztowne. Tego typu schemat jest zalecany w przypadku, gdy wymagania stawiane przed magazynem danych stanowi mieszank aktywnej analizy najnowszych danych i eksploracji du|ych wolumenów danych historycznych. 3.3.3. Partycjonowanie wedBug innego wymiaru Czas nie jest jedynym wymiarem, wedBug którego mo|e przebiega partycjonowanie. Wezmy jako przykBad magazyn danych du|ej korporacji, której oddziaBy s rozproszone geograficznie. Je|eli ka|dy z oddziaBów odczytuje przede wszystkim informacje dotyczce regionu wBa[ciwego dla siebie, to bardziej efektywn metod partycjonowania byBby podziaB relacji na partycje odpowiadajce poszczególnym regionom. W ten sposób ka|dy z oddziaBów unikaBby odczytywania danych dotyczcych innych oddziaBów. Decydujc si na takie partycjonowanie relacji faktów projektant musi si upewni, |e wymiar bdcy podstaw podziaBu relacji faktów nie ulegnie w przyszBo[ci modyfikacji. Restrukturyzacja schematu partycjonowania zwizana z modyfikacj wymiaru mo|e by bardzo kosztowna, je[li nie niemo|liwa. Jako wskazówk mo|na przyj tu 272 Bartosz Bbel, MikoBaj Morzy zasad, |e partycjonowanie odbywa si tylko wedBug czasu, chyba, |e projektant jest absolutnie pewny, |e podstawa partycjonowania nie zmieni si w przyszBo[ci. 3.3.4. Partycjonowanie wedBug rozmiaru relacji W przypadku, gdy |aden wymiar nie jest odpowiedni aby stanowi podstaw do podziaBu relacji, nale|y rozwa|y schemat partycjonowania wedBug rozmiaru relacji. W takim przypadku za ka|dym razem, gdy rozmiar relacji faktów zbli|a si do pewnego predefiniowanego maksimum, tworzona jest nowa partycja, która od tego momentu staje si partycj aktywn. Partycjonowanie wedBug rozmiaru relacji jest zBo|one, uci|liwe w zarzdzaniu i wymaga specjalnych metadanych, pozwalajcych na okre[lenie, które krotki s przechowywane w poszczególnych partycjach. 3.3.5. Partycjonowanie pionowe Partycjonowanie pionowe polega na podziale relacji zawierajcej wiele atrybutów na zbiór relacji, z których ka|da posiada podzbiór atrybutów wyj[ciowych. Partycjonowanie pionowe jest przydatne w przypadku, gdy projektant chce odseparowa zbiór rzadko odczytywanych atrybutów relacji faktów od atrybutów czsto odczytywanych. Jak ju| wspomniano wcze[niej ka|de zmniejszenie rozmiaru krotki w relacji faktów ma niebagatelny wpByw na efektywno[ wykonywania zapytaD. Partycjonowanie pionowe mo|e by wykonane jako normalizacja (ang. normalization), lub jako podziaB krotek (ang. row splitting). Normalizacja jest standardow metod organizacji baz danych i pozwala na kondensowanie powtarzajcych si warto[ci do pojedynczych krotek. W przypadku magazynów danych czsto obserwuje si tendencj odwrotn, tzn. przeprowadza si denormalizacj, w wyniku której zwiksza si zajto[ przestrzeni dyskowej, ale jednocze[nie mo|na unikn kosztownych operacji Bczenia relacji podczas wykonywania zapytaD. W ogólno[ci projektanci magazynów danych powinni unika procesu normalizacji relacji. W przypadku podziaBu krotek zachowywane jest odwzorowanie jeden-do-jeden pomidzy partycjami. GBównym celem podziaBu wierszy jest przyspieszenie wykonywania zapytaD poprzez zmniejszenie rozmiaru relacji faktów. Oddzielone atrybuty nadal mog by odczytywane w nowo utworzonej partycji. PodziaB krotek mo|e okaza si ef ektywn metod partycjonowania, pod warunkiem wszak|e, |e nie wystpuje konieczno[ dokonywania poBczenia podzielonych cz[ci relacji. 3.4. Projektowanie relacji wymiarów Relacje wymiarów mog by zaimplementowane na kilka sposobów. Z racji ogólnej charakterystyki informacji referencyjnych relacje wymiarów s zawsze wielokrotnie mniejsze od relacji faktów, std ich restrukturyzacja nie jest specjalnie kosztowna. Trzeba jednak pamita o tym, |e prawidBowo zaprojektowana struktura informacji referencyjnych mo|e znacznie zwikszy efektywno[ wykonywania zapytaD w magazynie danych. 3.4.1. Wymiary gwiazdziste Wymiary gwiazdziste s podstaw konstrukcji schematu gwiazdzistego. Zwikszaj prdko[ wykonywania zapytaD poprzez denormalizacj wszystkich informacji referencyjnych danego wymiaru do jednej relacji. Wikszo[ zapytaD analizuje fakty po uprzednim ograniczeniu relacji faktów poprzez naBo|enie licznych ograniczeD na relacj wymiarów (np. zapytanie sumujce zyski w grupie klientów mBodych, mieszkajcych w du|ych miastach i posiadajcych  |óBty abonament). Poniewa| zapytanie ogranicza zbiór klientów wedBug ró|nych kryteriów (grupa wiekowa, miejsce zamieszkania, rodzaj abonamentu), mo|na je przyspieszy poprzez wBczenie wszystkich atrybutów dotyczcych wymiaru Klient do jednej relacji. Wad tego rozwizania jest znaczce zwikszenie rozmiaru relacji wymiaru. Je|eli niektóre z atrybutów wymiaru s odczytywane bardzo rzadko, to koszt zwikszenia rozmiaru relacji mo|e by wikszy ni| zysk wynikajcy z przyspieszenia wykonywania zapytaD. Je|eli atrybut wymiaru jest u|ywany rzadko, to nale|y pozostawi go w postaci schematu pBatka [niegu. Projektowanie schematów logicznych dla magazynów danych 273 3.4.2. Wymiary typu  pBatek [niegu Nie wszystkie encje mo|na sprowadzi do wymiarów gwiazdzistych. W pewnych przypadkach encje skBadajce si na wymiar s poBczone ze sob zwizkami typu wiele-do-wiele, których nie nale|y denormalizowa. Czsto dla jednej encji wystpuje wiele ró|nych hierarchii, reprezentujcych ró|ne punkty widzenia na jedne i te same dane. PrzykBadowo, przedstawicielstwa handlowe firmy X podlegaj pod hierarchi opisujc geograficzn lokalizacj placówek. Równolegle do podstawowej hierarchii u|ytkownicy korzystaj z dodatkowych hierarchii, klasyfikujcych przedstawicielstwa pod wzgldem: typu lokalizacji (supermarket, centrum handlowe, wolnostojce, itp.), rozmiaru placówki, ofert i promocji oferowanych przez placówk, itd. W takim przypadku denormalizacji do wymiaru gwiazdzistego powinna podlega ta hierarchia, z której korzysta najwicej zapytaD, za[ pozostaBe hierarchie powinny pozosta w postaci pBatków [niegu. Je|eli w przyszBo[ci zmieni si profil zapytaD (czyli inna hierarchia stanie si  najpopularniejsza ), to nie nale|y usuwa aktualnie wykorzystywanego wymiaru gwiazdzistego (koszt modyfikacji zapytaD mo|e by znaczny), lecz wzbogaci go o te atrybuty, które opisuj now hierarchi. 3.4.3. Wymiary zmieniajce si w czasie Informacje referencyjne, w przeciwieDstwie do faktycznych, ulegaj czstym zmianom i modyfikacjom. Wynika to z tego, |e organizacje zmieniaj swój punkt widzenia na posiadane dane w zale|no[ci od aktualnych warunków ekonomicznych. Co wicej, same przedsibiorstwa ulegaj wewntrznym przeobra|eniom i reorganizacjom, co znajduje odbicie w modyfikacji wymiarów w magazynie danych (wymiary opisujce struktur organizacyjn firmy, wymiary opisujce przydziaB produktów do grup, itp.). Czasami pojawia si te| potrzeba wykonywania zapytaD, które operuj jednocze[nie na faktach grupowanych wedBug aktualnych i przeszBych hierarchii (tzw. zapytania  jak jest, jak byBo ). W takim wypadku niezbdne staje si przechowywanie zakresów dat w relacjach wymiarów. Wówczas przyporzdkowanie krotki wymiaru do pewnej generalizacji jest wBa[ciwe tylko w przedziale czasowym Data_od, Data_do. Je|eli jakakolwiek warto[ w relacji wymiaru ulega zmianie, to jej poprzednie przyporzdkowanie jest zamykane poprzez uzupeBnienie warto[ci Data_do i wstawiana jest nowa krotka, opisujca nowe przyporzdkowanie danej warto[ci wymiaru. 3.4.4. Wymiary hybrydowe 274 Bartosz Bbel, MikoBaj Morzy W poprzednich akapitach przedstawiono dwie podstawowe organizacje relacji wymiarów: schemat gwiazdzisty i schemat typu  pBatek [niegu . W rzeczywistych projektach rzadko udaje si wykorzystywa oba schematy w czystej postaci. Najcz[ciej projektanci wybieraj organizacj hybrydow (ang. starflake schema). W ramach takiej organizacji podstawowa cz[ informacji referencyjnej jest przedstawiona w postaci gwiazdzistej (jako zdenormalizowane relacje), a cz[ pomocnicza w postaci  pBatka [niegu (jako znormalizowane hierarchie). PrzykBad schematu hybrydowego przedstawiono poni|ej na rysunku 2. Rys. 2. PrzykBad schematu hybrydowego W miar eksploatacji magazynu danych wspólne cz[ci relacji wymiarów powinny ulega stopniowemu zanikowi. WpBywa na to lepsze zrozumienie potrzeb u|ytkownika oraz krystalizacja profilu wykorzystania magazynu. Po pewnym czasie projektant dysponuje wystarczajc wiedz aby dokona restrukturyzacji niektórych wymiarów i sprowadzenia ich do bardziej  poprawnej formy. 3.4.5. Partycjonowanie wymiarów W pewnych przypadkach relacja wymiaru mo|e urosn do rozmiaru, w którym niezbdne stanie si partycjonowanie tego wymiaru. Taka sytuacja mo|e powsta dla wymiaru, który czsto podlega zmianom i dla którego istnieje wymóg przechowywania wszystkich poprzednich wersji wymiaru w celu dokonywania porównaD. Zbyt du|y rozmiar relacji wymiaru mo|e bardzo negatywnie wpByn na czas wykonywania zapytaD. Podstaw partycjonowania relacji wymiaru powinien by jeden z atrybutów grupujcych dla tego wymiaru. Je[li partycjonowaniu podlega katalog oferowanych produktów o du|ym rozmiarze, to podstaw partycjonowania powinna by kategoria produktu. Oczywi[cie, nie mo|na tworzy osobnej partycji dla ka|dego produktu. Podstawa partycjonowania powinna by wybrana na odpowiednim poziomie hierarchii klasyfikacji produktu, tak, aby Bczna liczba utworzonych partycji nie przekraczaBa 50. W rzeczywisto[ci przypadki, w których partycjonowanie wymiaru jest konieczne, s niezwykle rzadkie. Bardziej prawdopodobne jest, |e du|a relacja wymiaru zawiera ukryte w niej fakty, które powinny by wyodrbnione. Projektowanie schematów logicznych dla magazynów danych 275 3.5. Projektowanie relacji zbiorczych Agregacja stanowi bardzo istotny element magazynów danych. Pozwala na efektywne wykonywanie zBo|onych i kosztownych zapytaD w rozsdnym czasie i bez potrzeby znaczcych inwestycji w zasoby sprztowe. Poprawne zaprojektowanie strategii agregacji jest jednak trudne: zbyt wiele agregatów odbije si negatywnie na kosztach zarzdzania i pielgnowania magazynu danych, zbyt maBo agregatów nie pozwoli na efektywne wykonywanie zapytaD. Ogólnie rzecz biorc, nale|y przyj zasad 70-30: w dobrze zaprojektowanym magazynie danych 70% zapytaD wykonuje si z prdko[ci zadowalajc u|ytkowników, za[ przyspieszenie pozostaBych 30% musi odby si kosztem znacznych inwestycji w moc obliczeniow sprztu, na którym dziaBa magazyn danych. 3.5.1. Czym jest agregacja? Agregacja to wstpne dokonywanie obliczeD, tworzenie danych zbiorczych oraz ich przechowywanie w celu pózniejszego wykorzystania. Agregaty nie nios ze sob |adnych nowych informacji w tym sensie, |e wszystkie obliczenia bazuj na danych obecnych w relacjach faktów i wymiarów. Wikszo[ strategii agregacji wykorzystuje fakt, |e bardzo wiele zapytaD operuje na wskich podzbiorach faktów wyznaczanych przez specyficznie pogrupowane warto[ci wymiarów. Aby efektywnie realizowa proces wspierania decyzji magazyn danych musi dostarcza u|ytkownikom informacji na odpowiednim poziomie szczegóBowo[ci. Bezpo[rednia analiza relacji faktów nie pozwala na wyciganie |adnych wniosków na temat ogólnych trendów i regularno[ci wystpujcych w danych. Dopiero spojrzenie na fakty  z dystansu , np. na poziomie caBej grupy klientów lub regionu geograficznego, pozwala na dostrze|enie istotnych prawidBowo[ci. Podstawow zalet stosowania agregacji jest przyspieszenie wykonywania zapytaD. ZBo|one zapytanie odczytuje wyniki skomplikowanych i czasochBonnych obliczeD bezpo[rednio z relacji zbiorczej i nie musi traci czasu na powtarzanie tych obliczeD. Odbywa si to kosztem dokonania wcze[niejszych obliczeD i skBadowania wyniku w relacji zbiorczej oraz, w niektórych przypadkach, pielgnowania wyliczonej warto[ci. Wida te| wyraznie, |e zyski z agregacji mog okaza si krótkoterminowe, poniewa| je[li zmieni si profil zapytaD i dana warto[ zbiorcza przestanie by u|ywana, to jej dalsze przechowywanie w magazynie danych oka|e si bezcelowe. Ostatnia uwaga pokazuje, |e projektowanie relacji zbiorczych nie jest czynno[ci jednorazow. W trakcie |ycia magazynu danych administrator powinien nieustannie monitorowa profile zapytaD i, w przypadku odkrycia takiej konieczno[ci, dodawa bdz usuwa pewne relacje zbiorcze. Jak ju| powiedziano, zysk z wcze[niejszego wyliczania warto[ci zbiorczych polega na przesuniciu kosztów przetwarzania w czasie, dziki czemu zmniejsza si koszt wykonywania zapytaD. Oczywi[cie, dla ka|dej relacji zbiorczej mo|na zdefiniowa perspektyw udostpniajc te same dane. W przypadku perspektywy jednak zysk bdzie znikomy, poniewa| obecno[ perspektywy w |aden sposób nie wpBynie na czas wykonania zapytania. Co wicej, warto[ci wyliczonej za pomoc perspektywy nie mo|na powtórnie wykorzysta i w przypadku powtórzenia zapytania caBe przetwarzanie wykona si raz jeszcze od pocztku. 3.5.2. Które relacje zbiorcze powinny by tworzone? Wybór informacji, które powinny podlega agregacji, jest trudnym procesem, poniewa| wraz ze zmian profilu zapytaD zmieniaj si tak|e wymagania dotyczce agregatów. W pierwszym kroku trzeba okre[li pocztkowy zbiór informacji, które trafi do relacji zbiorczych. Je|eli magazyn danych jest budowany na bazie starszego systemu komputerowego, to dobrym pocztkiem jest agregacja tych samych informacji, które podlegaBy agregacji w poprzednim systemie. Podstawow metod odkrywania istotnych agregacji jest stworzenie tabeli ze wszystkimi poziomami wszystkich kluczowych wymiarów. Z tej tabeli nale|y odczyta wszystkie mo|liwe kombinacje wymiarów i zbada, które z tych kombinacji bd odpowiadaBy zapytaniom u|ytkowników. Poni|ej przedstawiono tabel zawierajc przekrój poziomów hierarchii dla wymiarów Taryfikacja, Klient i Czas. 276 Bartosz Bbel, MikoBaj Morzy Tabela 1. PrzykBadowy przekrój poziomów hierarchii Taryfikacja Klient Czas Strefa czasowa Nazwa DzieD Lokalizacja TydzieD Region Miesic Kraj Rok Z powy|szej tabeli mo|na wybra kombinacj Strefa czasowa-Region-Miesic i utworzy dla niej odpowiednie relacje zbiorcze, a nastpnie zapeBni te relacje wyliczonymi warto[ciami. Taka relacja zbiorcza bdzie przechowywa dane o czasie trwania i warto[ciach rozmów we wszystkich strefach czasowych, zsumowanych dla poszczególnych regionów i miesicy. Relacje zbiorcze mo|na podzieli na trzy klasy: " Wysoki poziom agregacji: udostpniaj szersze spojrzenie na caBoksztaBt danych, np. sumaryczna sprzeda| przedsibiorstwa z podziaBem na tygodnie i produkty, " Zredni poziom agregacji: bardziej szczegóBowe dane na temat konkretnego regionu lub grupy produktów, np. sumaryczna sprzeda| z podziaBem na tygodnie i sklepy, " Niski poziom agregacji: szczegóBowe informacje, podobne do faktów, np. dzienna sprzeda| z podziaBem na produkty i sklepy. Relacje zbiorcze z wysokim poziomem agregacji s zazwyczaj maBe i powinny zawiera wszystkie konieczne agregaty wraz ze zdenormalizowanymi wymiarami. Relacje zbiorcze z niskim poziomem agregacji s bardzo du|e i sw charakterystyk przypominaj relacje faktów. W trakcie ich konstruowania nale|y przestrzega reguB dotyczcych konstrukcji relacji faktów. Relacje zbiorcze ze [rednim poziomem agregacji s relacjami  granicznymi , w których przypadku nale|y rozsdnie balansowa midzy rozmiarem takiej relacji a jej zawarto[ci. Je[li rozmiar takiej relacji przekroczy 1-2 GB, to prawdopodobnie dane w niej zawarte s zbyt szczegóBowe. 3.5.3. Projektowanie relacji zbiorczych Istot wykorzystania relacji zbiorczych jest zmniejszenie wolumenu odczytywanych danych poprzez skBadowanie w relacji zbiorczej maksymalnej liczby warto[ci cz[ciowych. Nie chodzi tu tylko o zapisywanie do relacji warto[ci zbiorczych, ale np. o skBadowanie w relacji zbiorczej informacji referencyjnych celem uniknicia kosztownych operacji poBczenia. W ogólno[ci proces konstruowania relacji zbiorczych jest podobny do procesu konstruowania relacji faktów, z uwzgldnieniem pewnych istotnych szczegóBów. SkBada si z nastpujcych kroków. " Wybór wBa[ciwych wymiarów do agregacji Relacje zbiorcze s naturalnym rozszerzeniem relacji faktów. Zapytanie, pierwotnie skierowane do relacji faktów, powinno wykorzysta relacj zbiorcz bez konieczno[ci modyfikowania tre[ci zapytania, w sensie wykorzystania tych samych wymiarów i faktów. Oznacza to, |e w stosunku do relacji faktów relacja zbiorcza powinna zachowywa t sama struktur wymiarów (poza agregowanym wymiarem), oferujc jednocze[nie sumaryczne warto[ci pewnych faktów. Relacja zbiorcza prezentujca sumaryczny czas rozmów dla poszczególnych rodzajów taryfikacji i rodzajów abonamentu musi zawiera identyfikatory taryfikacji oraz abonamentu. Atrybut Data jest niepotrzebny, poniewa| miesic, którego dotyczy agregacja, jest zaszyty w nazwie relacji zbiorczej. W tym wypadku oprócz zmniejszenia liczby krotek w relacji zbiorczej zmniejsza si rozmiar ka|dej z krotek. Je|eli relacja zbiorcza przechowuje dane o sumarycznym dziennym czasie rozmów w caBym kraju, to atrybut KlientId staje si niepotrzebny, poniewa| sumowanie pomija podmiotowo[ poszczególnych abonentów. Drug mo|liwo[ci jest przechowywanie w ka|dej krotce warto[ci zagregowanych na pewnym poziomie hierarchii wymiaru. W takim wypadku agregowany wymiar powinien pozosta w relacji zbiorczej. Je[li w poprzednim przykBadzie pojawiBaby si konieczno[ obliczania sumarycznego Projektowanie schematów logicznych dla magazynów danych 277 dziennego czasu rozmów na poziomie regionalnym, to wówczas wymiar opisujcy lokalizacj powinien by na powrót wBczony do relacji zbiorczej. Nie powinien by to jednak atrybut KlientID, który jest zbyt szczegóBowy, lecz atrybut RegionID. " Agregacja wielu warto[ci Celem tego kroku jest okre[lenie, które warto[ci powinny by agregowane i zapisywane do relacji zbiorczych. Robi si to poprzez analiz zapytaD i identyfikacj agregowanych warto[ci. Rzadko kiedy u|ytkownika interesuje tylko jedna warto[ zbiorcza. Najcz[ciej zapytania odczytuj zbiór agregatów obliczony dla tych samych wymiarów. Analizujc relacj zbiorcz zawierajc dane o rozmowach wykonanych w przecigu tygodnia u|ytkownik najprawdopodobniej zapyta o: sumaryczny czas poBczeD, najwiksz, najmniejsz i [redni liczb poBczeD dla poszczególnych typów abonamentów, itp. Je|eli wikszo[ zapytaD odczytuje wicej ni| jedn warto[ agregowan wzdBu| tych samych wymiarów, to warto[ci zbiorcze dla tych agregatów powinny by przechowywane w jednej relacji zbiorczej. Projektanci maj tendencj do zawy|ania liczby przechowywanych agregatów ( a nu| si przyda w przyszBo[ci ), jednak pamita trzeba, |e ka|dy dodatkowy atrybut w relacji zbiorczej wpBywa negatywnie na prdko[ wykonywania si zapytaD. Najcz[ciej w zupeBno[ci wystarcza kilka atrybutów. " Agregacja wielu faktów w jednej relacji zbiorczej Czasami okazuje si, |e jedno zapytanie odczytuje wiele ró|nych faktów, agregowanych na tych samych podstawach (tj. na tym samym poziomie hierarchii wymiarów). Tego typu zapytania s czste w przypadku analizy porównawczej, np. warto[ci rozmów w ró|nych okresach czasowych, klientów przychodzcych do i odchodzcych z firmy, itp. Jako przykBad wezmy zapytanie analizujce liczb podpisanych umów w ramach poszczególnych tygodni. Oprócz podstawowych informacji o liczbie umów u|ytkownik dodatkowo pyta si o: liczb innych typów umów podpisanych w tym samym okresie, liczb klientów, która w tym samym okresie zrezygnowaBa z abonamentu, przewidywan liczb umów podpisanych w ramach promocji w danym tygodniu lub zyski osignite w danym tygodniu. Takie zapytanie odczyta cztery relacje: o rozmowach, o promocjach, o przewidywanych obrotach oraz o zdarzeniach (podpisanie lub anulowanie umowy). W rezultacie jedno zapytanie zostanie wykonane jako cztery ró|ne zapytania, z których ka|de dokona tej samej agregacji dla czterech ró|nych faktów. Je|eli podobne zapytania pojawiaj si czsto, to nale|y rozwa|y stworzenie relacji zbiorczej przechowujcej agregaty pochodzce z wielu ró|nych relacji faktów. Nale|y przy tym pamita, |e takie rozwizanie jest efektywne tylko dla agregatów czsto wykorzystywanych wspólnie. Je|eli tylko nieliczne zapytania wykorzystuj kombinacj agregatów ró|nych faktów, to koszt pielgnacji takiej relacji zbiorczej przekroczy ewentualny zysk wynikajcy z przyspieszenia zapytaD. " Wybór poziomu agregacji Dokonanie agregacji na okre[lonym poziomie hierarchii wymiarów powoduje, |e bardziej szczegóBowe informacje dotyczce tego wymiaru staj si niedostpne. Z drugiej strony zani|anie poziomu agregacji powoduje wzrost liczby relacji zbiorczych i zwikszenie kosztu pielgnacji tych relacji. Dla systemów bankowych czste s zapytania dokonujce agregacji w skali miesica (raporty o stanie konta, naliczanie odsetek, rat kredytów, itp.). Stworzenie relacji zbiorczej na poziomie miesica powoduje jednak, |e obliczenie tygodniowego salda dla konkretnego klienta musi si odby na podstawie relacji faktów i nie mo|na do tego celu wykorzysta relacji zbiorczej. Jednak je[li zostaBa zdefiniowana relacja zbiorcza z agregatami na poziomie tygodnia, wyliczenie podsumowaD miesicznych wymaga dokonania agregacji [rednio czterech wierszy w relacji zbiorczej. Ta metoda jest szczególnie efektywna, je|eli dokonanie agregacji  w locie , jak w powy|szym przykBadzie, wymaga przeliczenia niewielkiej liczby krotek. Tworzc relacje zbiorcze projektanci powinni rozwa|y budowanie agregatów o poziom ni|ej od poziomu wymaganego przez u|ytkowników, co przy minimalnym koszcie pozytywnie wpBywa na elastyczno[ i funkcjonalno[ magazynu danych. " Wybór stopnia wBczenia informacji referencyjnych do relacji zbiorczych 278 Bartosz Bbel, MikoBaj Morzy Relacje zbiorcze s czsto modyfikowane i od[wie|ane. W szczególnym przypadku relacja zbiorcza mo|e by od[wie|ana po ka|dym dodaniu nowych faktów do relacji faktów. To sprawia, |e w relacjach zbiorczych nale|y zawsze korzysta z kluczy naturalnych. Podstawowym argumentem przemawiajcym przeciwko stosowaniu kluczy naturalnych w relacjach faktów byBo niebezpieczeDstwo konieczno[ci dokonywania restrukturyzacji relacji faktów po zmianie warto[ci kluczy naturalnych. Poniewa| relacje zbiorcze s nieustannie modyfikowane, powy|szy argument traci moc. Samo stosowanie kluczy naturalnych nie chroni jednak przed konieczno[ci Bczenia relacji zbiorczych z relacjami wymiarów. W wielu przypadkach takie operacje mog by bardzo kosztowne i czasochBonne, szczególnie dla du|ych relacji zbiorczych. Je|eli zapytanie wymaga dostpu zarówno do relacji wymiarów jak i do relacji faktów, to dobrym rozwizaniem projektowym jest zaszycie niektórych atrybutów wymiaru w relacji zbiorczej. Takie rozwizanie wyeliminuje potrzeb dokonywania Bczenia relacji i pozwala odpowiedzie na zapytanie tylko na podstawie relacji zbiorczej. Je[li np. zapytanie odczytuje relacj zawierajc sumaryczn tygodniow ilo[ rozmów w poszczególnych strefach czasowych, za[ w zapytaniu u|ytkownicy wybieraj tylko pewne typy abonamentu (co wymaga odczytania relacji wymiaru Abonament), to nale|y rozwa|y wBczenie dodatkowego atrybutu do relacji zbiorczej. Ta technika powoduje znaczne zwikszenie rozmiaru poszczególnych krotek i nie powinna by stosowana do relacji zbiorczych o niskim poziomie agregacji (np. do relacji zawierajcej dzienne podsumowania sprzeda|y). " Modelowanie czasu w relacjach zbiorczych Zdecydowanie najlepsz metod modelowania czasu w relacjach zbiorczych jest przechowywanie dat fizycznych bezpo[rednio w relacji. Przechowywanie dat w postaci przesunicia wzgldem pocztku relacji lub jako zakresu dat jest nieefektywne. Koszt zwizany z przeliczaniem przesunicia na konkretn dat w przypadku maBych i [rednich relacji zbiorczych jest znaczny i nie posiada |adnych zalet. W przypadku skBadowania zakresów dat aktualny jest problem narzdzi dostpu, za pomoc których u|ytkownicy odczytuj dane. Wikszo[ z tych narzdzi nie potrafi wykorzystywa takiej metody skBadowania dat. " Indeksowanie relacji zbiorczych Obecno[ indeksu zaBo|onego na atrybucie wskazuje systemowi zarzdzania baz danych, |e zapytania powinny by kierowane do danego atrybutu. W przypadku relacji zbiorczych zaleca si, aby indeksowa wszystkie atrybuty, które prawdopodobnie bd odczytywane. Koszt pielgnacji indeksów nie powinien by wysoki, zwa|ywszy na niewielkie rozmiary relacji zbiorczych. Istnienie indeksów nie rozwi|e wszystkich problemów, ale dla zapytaD skoncentrowanych na maBym fragmencie relacji zbiorczej (a takie powinny stanowi wikszo[ zapytaD) wydajnie zwikszy efektywno[ systemu. 4. Podsumowanie Technologia magazynów danych znajduje zastosowanie w coraz wikszej liczbie przedsibiorstw. Mimo, |e magazyny danych s budowane w oparciu o technologi relacyjnych baz danych, proces konstruowania schematu logicznego magazynu danych jest odmienny od metodologii tworzenia schematów logicznych dla systemów obsBugi bie|cej. W artykule przedstawiono najwa|niejsze ró|nice i pokazano, w jaki sposób wpBywaj one na konkretne rozwizania projektowe. Podstawowym problemem jest nieustanna ewolucja magazynu danych, wynikajca ze zmiennych warunków, w jakich dziaBa przedsibiorstwo. Magazyny danych musz by projektowane w taki sposób, aby oferowa u|ytkownikom elastyczno[, Batwo[ obsBugi, wszechstronno[ i efektywno[. Rozmiary magazynów danych oraz specyficzne wymagania, które s zwizane z charakterystyk zapytaD kierowanych do magazynów, powoduj, |e konstrukcja schematu logicznego magazynu danych jest trudna. Projektowanie schematów logicznych dla magazynów danych 279 W artykule przedstawiono metody identyfikacji faktów, wymiarów i informacji zbiorczych. Pokazano równie|, w jaki sposób mo|na zamodelowa podstawowe skBadowe magazynu danych w relacyjnym systemie baz danych. Autorzy maj nadziej, |e przedstawione uwagi i rozwizania oka| si przydatne dla wszystkich projektantów i administratorów magazynów danych. Bibliografia 1. Mattison R., Data Warehousing  Strategies, Technologies, and Techniques, McGraw-Hill, 1996, ISBN 0- 07-041034-8 2. Anahory S., Murray D., Data Warehousing in the real world, Addison-Wesley, 1997, ISBN 0-201-17519-3 3. Corey M.J., Abbey M., Abramson I., Taub B., Oracle8 Data Warehousing, McGraw-Hill, 1998, ISBN 0-07- 882511-3 4. Connolly T., Begg C., Strachan A., Database Systems  A Practical Approach to Design, Implementation, and Management, Addison-Wesley, 1999, ISBN 0-201-34287-1 5. Jarke M., Lenzerini M., Vassiliou V., Vassiliadis P., Fundamentals of Data Warehouses, Springer Verlag, 2000, ISBN 3-540-65365-1 280 Bartosz Bbel, MikoBaj Morzy 5. ZaBcznik A Rysunek 3 przedstawia przykBadowy schemat logiczny magazynu danych dla firmy oferujcej usBugi w dziedzinie telefonii komórkowej. Relacje PoBczenie i Zdarzenie to relacje faktów. Relacje Rozmowy w miesicach i Umowy w promocjach s relacjami zbiorczymi. PozostaBe relacje to relacje wymiarów. Rys. 3. PrzykBadowy schemat logiczny magazynu danych

Wyszukiwarka