Uniwersytet Technologiczno-Przyrodniczy w Bydgoszczy
Streszczenie
Do przetwarzania analitycznego (OLAP) wykorzystywane są róĪnorodne syste-my zarządzania bazami danych. W praktyce technologie analizy wielowymiarowej wspierają specjalizowane rozwiązania MOLAP, jaka równieĪ najpopularniejsze sys-temy zarządzania relacyjnymi bazami danych. Stosowane rozwiązania na rynku aplikacji wspomagających decyzjĊ mają róĪną podatnoĞü na niekontrolowany wzrost objĊtoĞci bazy bĊdący nastĊpstwem tworzenia agregatów danych.
Słowa kluczowe: OLAP, Bazy danych, agregaty danych 1. Wstp
Przetwarzanie analityczne realizowane jest na dwa róne sposoby. Jeden z nich oparty jest na serwerze wielowymiarowej bazy danych (ang. Multidimensional OLAP), za drugi na serwerze relacyjnym (ang. Relational OLAP), gdzie zwizki wielowymiarowe s realizowane za pomoc odpowiednich relacji pomidzy wymiarami. Istnieje równie trzecia technika bdca połczeniem obu tych technologii nazywana przetwarzaniem hybrydowym (ang. Hybrid OLAP) 1.
MOLAP – (ang. Multidimensional Database On-Line Analytical Processing) jest to jedna z koncepcji interaktywnego przetwarzania analitycznego (OLAP) oparta na serwerze wielowy-miarowej bazy danych (ang. MDDB – Multidimensional DataBase). Model wielowywielowy-miarowej bazy danych został zaproponowany w 1972 roku przez firm konsultingow Management Decision Systems2 jako magazyn danych dla systemów wspomagania decyzji (ang. DSS – Decision Support Systems), systemów informowania kierownictwa (ang. MIS – Management Information Systems) oraz innych systemów analizy danych rynkowych. Charakterystyczn cech wielowymiarowych baz danych jest to, e dane pochodzce z zewntrznych ródeł, od uytkowników kocowych lub powstałe w wyniku agregacji wewntrz bazy danych, s magazynowane w strukturze posiadajcej charakter wielowymiarowy.
2. Wielowymiarowe struktury danych
Matematycznie wielowymiarowa baza danych jest macierz n-wymiarow. Interpretacj geo-metryczn takiej bazy moe by tablica (baza 2-wymiarowa), kostka (baza 3-wymiarowa) lub w przypadku baz n-wymiarowych zbiór kostek lub tablic. Dane dotyczce sprzeday pewnej grupy produktów s magazynowane w strukturze o trzech wymiarach (obszar, okres i produkty). Kada kostka w tym przypadku moe zawiera informacje o wielkoci sprzeday, poniesionych kosztach,
1 M.Gorawski: „Data Warehouse Słownik WaĪniejszych PojĊü”, Raport Computerworld nr 12/2000. 2 www.olapreport.com
zysku itp. Moe równie zawiera mniejsze kostki, które bd zawiera dane bardziej precyzyjne. W typowych zastosowaniach liczba wymiarów w kostce nie przekracza 10, a zawarto kadej kostki stanowi dane numeryczne, rzadziej tekstowe3.
W procesie eksploracji danych uytkownik nie oglda całej kostki, ale jej cze – tzw. widok, czyli zestawienie danych wybranych do prezentacji. Atrybutami widoku s (Tab. 1.):
− wymiary w wierszach, − wymiary w kolumnach, − wymiar tytułowy.
Tabela 1. Przykład widoku produktów sprzedanych w regionach Warto sprzeday w roku 2005
Produkt
Region1 Region2 Region3
Produkt1 125 135 145
Produkt2 120 130 140
Produkt3 175 145 166
ħródło: opracowanie własne
Dla przykładu przedstawionego w tabeli, przy zachowaniu tych samych wymiarów kolumn i wierszy, mona uzyska róne zestawienia zmieniajc jedynie wymiar tytułowy (np. ilo sprze-danych produktów, rednia sprzeda miesiczna itp.). W chwili obecnej znanych jest wiele sposo-bów utrzymywania logicznej struktury wielowymiarowej bazy danych. W aspekcie historycznym metody te s coraz bardziej wydajne, umoliwiajc redukcj fizycznego rozmiaru bazy danych oraz skracajc czas wykonywania zapyta. W bazach wielowymiarowych dane maj posta rzadk, tzn. nie wypełniaj całej przestrzeni wymiarowej (pojedynczy proces biznesowy najczciej opisa-ny jest za pomoc jednej kategorii w konkretopisa-nym wymiarze). Dane nie s równie rozmieszczone równomiernie, ale mog wystpowa w postaciach skupisk4.
Wybór odpowiedniej struktury danych nie ma wpływu na wizualizacj danych zawartych w ba-zie, natomiast zaley od niego sposób projektowania bazy, agregowania danych, wyboru typu indeksowania itp. W przypadku zastosowa praktycznych popularnoci ciesz si rozwizania struktury typu „hypercube” i „multicube”. Najprostsz struktur wielowymiarowej bazy danych jest kartezjaski układ współrzdnych, okrelony przez wymiary właciwe dla aplikacji. Struktura taka zwana „data space” w rzeczywistoci ma posta pojedynczych nie skompresowanych tablic i moe by stosowana na mał skal ze wzgldu na duy rozmiar pamici jak zajłyby dane o niskim współczynniku gstoci. Układ kartezjaski w przypadku wielowymiarowych baz danych traktuje si w zasadzie jako model logiczny, a nie fizyczn struktur przechowywania danych. 2.1. Hypercube
Hypercube jest prostym sposobem, szeroko wykorzystywanym w duych bazach danych ze wzgl-du na intuicyjn struktur logiczn. Polega ona na odwzorowaniu rzeczywistoci w postaci
3 M.Gorawski: „Analiza porównawcza ROLAP i MOLAP”, Software 8/1999.
4 N.Pendse: „Multidimensional Data Structures”, OLAP Report 2000,http://www.olapreport.com - „dane w wielowy-miarowej aplikacji mają tendencjĊ do skupiania siĊ w stosunkowo gĊste bloki z duĪymi przerwami pomiĊdzy – tak jak planety i gwiazdy w przestrzeni kosmicznej”
dynczej n-wymiarowej kostki. Pozwala to na wprowadzanie danych dla kadej kombinacji wymia-rów, dodatkowo kada cz przestrzeni w strukturze hypercube posiada identyczn wymiarowo (jest okrelona przez te same wymiary). Wymiary nie musz posiada równych rozmiarów, a w zalenoci od producenta bazy mona stosowa rón ich maksymaln liczb. Przykładem produk-tu wykorzysproduk-tujcego strukproduk-tur hypercube jest Essbase, który jest wykorzystywany przez takie apli-kacje jak ExecutiveViewer, CFO Vision, BI/Analyze oraz PowerPlay. Struktura hypercube posiada pewn odmian zwan ograniczonym (okrojonym) hypercube (ang. fringed hypercube). Jest to gsta struktura o małej liczbie wymiarów. W przypadku analizy wiekszej liczby wymiarów fringed hypercube moe by traktowany jako cz wikszej struktury danych. To rozwizanie znalazło zastosowanie w nastpujcych produktach: Hyperion Enterprise, CLIME Comshare FDC. Wielo-wymiarowa baza danych zrealizowana w oparciu o pojedyncz wielowymiarow struktur wymaga duej iloci pamici do agregowania i magazynowania danych.5
2.2. Mulitcube
Multicube jest bardziej znan struktur, której idea polega na rozbiciu bazy na zbiór wielowy-miarowych podstruktur bdcych kompozycj wielu wymiarów. Struktura taka charakteryzuje si wysok uniwersalnoci, wydajnoci (szczególnie w przypadku rzadkich danych). Multicube jako podstruktury czsto wykorzystuje struktur hypercube. Multicube został po raz pierwszy wykorzy-stany w latach 60 w produkcie APL6. Rozbicie przestrzeni bazy danych na m kostek n-wymiarowych pozwala unikn zjawiska rzadkich danych, co z kolei ogranicza zjawisko tzw. eks-plozji danych. W praktyce multicube jest złoona z kilku logicznych wielowymiarowych baz da-nych, majcych posta szecianów. Mona wyróni dwa typy struktury multiciube: block7. i se-ries. Block multicube wykorzystywany w BusinessObject, Gentia, Holos, Microsoft’s OLAP Se-rvices i iTM1, uywa ortogonalnych wymiarów, w zwizku z czym nie posiada dodatkowych wy-miarów na poziomie danych. Kostka moe zawiera wiele zdefiniowanych wywy-miarów, a miara i czas s traktowane jako równorzdne wymiary.
3. Agregaty w wielowymiarowych bazach danych
Hurtownia danych zwykle jest zasilana danymi pochodzcymi z zewntrznych systemów trans-akcyjnych. Struktura danych w tych systemach oparta jest najczciej na schemacie relacyjnym, co uniemoliwia bezporednie załadowanie ich do wielowymiarowej bazy danych. W celu zasilenia hurtowni opartej na serwerze MDDB konieczne jest wykonanie serii procedur wsadowych agregu-jcych dane w ortogonalne wymiary i wypełniajce struktury tablicowe MDDB. Agregaty s zsu-mowanymi danymi ilociowymi w rozbiciu na zmienne kategoryzujce (pola zawierajce dane słuce do grupowania informacji). W kadej wielowymiarowej bazie danych znajduje si agregat podstawowy, który jest oparty na wszystkich zmiennych kategoryzujcych. Agregat podstawowy zawiera dane, które z punktu widzenia serwera MDDB s danymi atomowymi (z punktu widzenia baz relacyjnych dane te nie s atomowe, poniewa powstały w wyniku grupowania danych
5 http://www.olapreport.com
6 APL (A Programming Language) jest to jĊzyk programowania wymyĞlony przez Kenneth E. Iverson - oczywiĞcie termin multicube nie funkcjonował wówczas, a niektóre szczegóły rozwiązaĔ fizycznych wyglądały inaczej, ale idea była iden-tyczna z obecnymi rozwiązaniami multicube.
7 N.Pendse: „Multidimensional Data Structures”, OLAP Report 2000,http://www.olapreport.com - struktura block multicube pojawiła siĊ w połowie lat 80 i do tej pory jest popularnym rozwiązaniem.
cyjnych)8. W zalenoci od potrzeb definiuje si agregaty czciowe, które s oparte w czci na wybranych zmiennych kategoryzujcych. Agregat podstawowy umieszczony jest w dolnej czci kostki. Do niego trafiaj zapytania, które s obsługiwane na miejscu lub przekazywane istniejcym agregatom czciowym. W analizie OLAP czsto wanym czynnikiem jest oczekiwanie na odpo-wied. W wielowymiarowych bazach danych uzalenione jest to od iloci wymiarów, istniejcych agregatów czciowych oraz konsolidacji danych. Wszystkie zapytania skierowane do bazy danych s kierowane do agregatu podstawowego, który je wykonuje lub ich wykonanie zleca agregatom dodatkowym. W zalenoci od rodzaju agregatów czas zwrócenia wyników przez zapytanie jest zaleny od tego, czy jest ono obsługiwane przez agregat podstawowy, czy przez agregat czcio-wy. Wynik zapytania zostanie zwrócony w krótkim czasie o ile w bazie znajduje si agregat o strukturze tego zapytania, wówczas realizacja zapytania jest przeniesiona z agregatu podstawowe-go do agregatu czciowepodstawowe-go. W przypadku gdy nie ma w bazie agregatu o odpowiedniej strukturze zapytanie zostaje skierowane do agregatu o strukturze zblionej, wówczas czas odpowiedzi zosta-nie wydłuony, pozosta-niewa zosta-niektóre z danych wartoci bd wymagały przeliczenia. W przypadku, gdy aden z istniejcych agregatów nie posiada struktury zblionej do struktury zapytania, realiza-cja odbywa si w agregacie podstawowym, który generuje odpowiedni wynik na podstawie danych atomowych. Proces ten zajmuje najwicej czasu ze wzgldu na du ilo operacji agregacji jakie musi przeprowadzi motor MDDB. W celu zmniejszenia czasu oczekiwania na odpowied moli-we jest wygenerowanie wszystkich moliwych agregatów lub czci agregatów.
Rozwizanie z wygenerowaniem wszystkich moliwych agregatów z pewnoci jest optymalne ze wzgldu na krótki czas oczekiwania na odpowied, ale zapewnienie przestrzeni dyskowej po-trzebnej do przechowania wszystkich agregatów moe okaza si niemoliwe. Wygenerowanie niektórych agregatów czciowych jest rozwizaniem na wzór „złotego rodka”. Zapytania, które nie posiadaj gotowych agregatów czciowych, mog by obsłuone przez inne agregaty o struk-turze zblionej do zapytania, co wydłuy czas oczekiwania, ale korzyci jaka zostanie odniesiona bdzie mniejszy rozmiar fizyczny bazy danych. Oczywicie pozostaje jeszcze problem wyboru odpowiednich agregatów czciowych, ze wzgldu na fakt, e w fazie projektowania hurtowni nie zawsze jest moliwo wgldu do ostatecznej listy zapyta, na podstawie której moliwe byłoby wybranie optymalnego zestawu agregatów czciowych. Z pojciem agregatu cile zwizana jest hierarchia wymiarów. Okrela ona sposób grupowania zmiennych kategoryzujcych w poszczegól-nych wymiarach. Przykładowa hierarchia wymiaru dla okresu znajduje si na rysunku 1.
Rys. 1. Prosta hierarchia wymiaru okres ħródło: opracowanie własne
Oczywicie tak rozbudowana hierarchia spowoduje wzrost liczby danych magazynowanych w bazie. Rozwizaniem moe by tutaj ponowna agregacja danych historycznych. Jeeli firma prze-chowuje dane z ostatnich 5 lat, to istnieje małe prawdopodobiestwo, e do analizy potrzebuje dziennych, tygodniowych lub nawet miesicznych wartoci z lat poprzednich. Rozwizaniem zmniejszajcym rozmiar bazy moe by skonsolidowanie danych historycznych do postaci o dwóch poziomach np. rok i kwartał, ponowne zagregowanie ich i usunicie szczegółowych danych historycznych. W szczególnych przypadkach istnieje moliwo stosowania hierarchii posiadajcej w swojej strukturze poziomy podrzdne wywodzce si bezporednio z dwóch lub wikszej liczby poziomów nadrzdnych (Rys. 2.). Najwyszym poziomem hierarchii wymiaru okres jest rok. Po-ziom główny posiada dwa poPo-ziomy potomne w postaci poPo-ziomów kwartał i tydzie. PoPo-ziomem potomnym tygodnia jest dzie, który jest równie poprzez poziom rodzicielski - miesic potom-kiem poziomu kwartał. Taka hierarchia wymiaru umoliwia analiz danych historycznych z dwóch punktów widzenia:
− rok kwartał miesic dzie miesica, − rok tydzie dzie tygodnia dzie miesica.
Rys. 2. Zmodyfikowana hierarchia wymiaru okres ħródło: opracowanie własne
3. Eksplozja wielowymiarowej bazy danych
Niewłaciwy pod ktem wyboru agregatów dodatkowych projekt, nieodpowiedni sposób łado-wania i konserwacji wielowymiarowej bazy danych moe doprowadzi do gwałtownego wzrostu objtoci bazy. Zjawisko to czsto nazywane jest „eksplozj wielowymiarowej bazy danych” i polega na nieprzewidywalnym, niekontrolowanym zwikszeniu objtoci bazy w przestrzeni pa-mici. Na zwikszenie objtoci bazy z pewnoci wpływ bd miały takie czynniki jak:
− gsto danych (wskanik okrelajcy wypełnienie przestrzeni tablicowych MDDB), − technologia przechowywania wielowymiarowej bazy danych,
− niska kompresja danych, − błdy aplikacji,
które mog doprowadzi , „zaledwie” 9 do 4-krotnego wzrostu objtoci danych podczas gdy w niektórych przypadkach warto współczynnika wzrostu (ang. GF – Growth Factor) moe osi-gn rzd wielkoci 10 lub nawet 100. Na niekontrolowany wzrost objtoci bazy nie ma wpływu charakter ródła danych. Dane ródłowe hurtowni danych pochodz z systemów transakcyjnych, które najczciej zbudowane s w oparciu o model relacyjny, chocia mog to by arkusze kalku-lacyjne, pliki tekstowe itp. Proces ładowania tego typu danych do hurtowni opartej o MDDB jest zwizany z procesem agregacji danych. Im bardziej dane s agregowane, czyli zwikszany jest ich stopie konsolidacji, tym mniej bd zajmowały miejsca w pamici. Wane jest, e nawet w przy-padku zastosowania niskiego stopnia konsolidacji danych, dane w MDDB bd zajmowały mniej miejsca ni w transakcyjnych systemach ródłowych. Stosunek rozmiaru danych umieszczonych w relacyjnych systemach transakcyjnych do tych samych danych w umieszczonych w wielowymiaro-wej bazie danych waha si w okolicach 5,510. Ten stan rzeczy zwizany jest z faktem, e w MDDB nie zawsze istnieje potrzeba przechowywania kluczy, indeksów lub informacji na temat struktury wymiarów, a jeeli jest to wymagane, to zajmuj one mniej pamici ni w systemach relacyjnych. Niektóre bazy danych maj moliwo likwidacji zjawiska rzadkich danych przez co dane mog by efektywniej kompresowane. Przykładem mog by systemy oparte o PowerPlay, Microsoft OLAP Services oraz QueryObjects.
Aplikacje OLAP w trakcie analizy mog pobiera dane z: − agregatu podstawowego,
− zdefiniowanych agregatów dodatkowych przechowywanych w bazie, − agregatów dodatkowych, które nie s przechowywane w bazie.
Jak wczeniej wspomniano zdefiniowanie wszystkich moliwych agregatów jest niewtpliwie skuteczne w przypadku, gdy wymagane jest szybkie zwrócenie wyniku zapytania. Jednak z drugiej strony takie rozwizanie to główna przyczyna eksplozji bazy danych. Pogld na rozmiar danych ródłowych, umieszczonych w agregacie podstawowym, agregatach dodatkowych oraz oblicza-nych na danie przedstawia rysunek 3.
9 www.olapreport.com
Rys. 3. Rozmiary danych Ĩródłowych i zagregowanych w wielowymiarowej bazie danych ħródło: www.olapreport.com
Porednio wpływ na wzrost objtoci danych ma hierarchia wymiarów. W zalenoci od liczby poziomów oraz od ich szerokoci zalee bdzie liczba moliwych agregatów. W celu zobrazowa-nia wpływu hierarchii na współczynnik wzrostu bazy mona załoy istnienie wymiaru o hierarchii przedstawionej na rysunku 4.
Rys. 4. Przykład hierarchii prostej ħródło: www.olapreport.com
Kolorem czarnym oznaczone s agregaty zawierajce dane, kolorem niebieskim agregaty puste. W zalenoci od poziomu jaki zostanie wybrany do analizy, gsto danych jest róna. Biorc pod uwag dane skonsolidowane, współczynnik gstoci danych wynosi 80% (4 kategorie z danymi na 5 moliwych). Na najniszym poziomie tej hierarchii współczynnik gstoci jest mniejszy i wynosi 32% (8 kategorii pustych na 25 moliwych). Współczynnik wzrostu (GF) bazy danych o jednym
wymiarze i takiej strukturze wynosi 1,625 (13 komórek wykorzystanych na 8 komórek z danymi ródłowymi)11.
Rys. 5. Struktura bazy 2-wymiarowej ħródło: opracowanie własne
Zakładajc baz 2-wymiarow (Rys. 5.) mona zaobserwowa wpływ liczby wymiarów na war-to współczynnika wzrostu (GF). Dla uproszczenia mona przyj , e oba wymiary maj iden-tyczn struktur hierarchiczn. Kolor biały okrela komórki, w których znajduj si dane agregatu podstawowego (ang. detail data). Kolor jasno-szary okrela dane skonsolidowane (ang. consolida-ted data) na pierwszym poziomie, wskie komórki dane skonsolidowane na poziomie drugim. Kolorem ciemnoszarym oznaczono odpowiednio dane podsumowujce pierwszy i drugi poziom konsolidacji. Pojedyncza komórka (w rogu) jest podsumowaniem drugiego stopnia konsolidacji. W bazie danych o takiej strukturze znajduje si 625 komórek zawierajcych dane atomowe, reprezen-tujcych agregat podstawowy oraz 336 komórek, w których znajduj si dane reprezentujce agre-gaty dodatkowe. Wynika z tego, e w tym konkretnym przypadku na dowolne 2 komórki ródłowe przypada wicej ni 1 komórka danych skonsolidowanych. Wraz ze wzrostem liczby wymiarów ten stosunek zmienia si gwałtownie i tak dla 6-wymiarowych danych na 1 komórk ródłow moe przypada 2 do 3 komórek obliczanych. W zalenoci od gstoci danych umieszczonych w bazie danych przedstawionej na rysunku 6 współczynnik wzrostu (GF) moe przyjmowa wartoci od 1,5 dla danych o gstoci 100% do 5,83 dla danych o gstoci 1%. Na podstawie tych wyników mona okreli współczynnik wzrostu dla jednego wymiaru12. W przypadku 2-wymiarowej bazy danych CFG jest pierwiastkiem kwadratowym współczynnika FG, dla 3-wymiarowej bazy danych CFG jest pierwiastkiem stopnia trzeciego FG itd. W celu wykrelenia zalenoci pomidzy
11 Ibidem
12 Nigel Pendse w artykule Database Explosion – OLAP Report proponuje dla niego nazwĊ compound growth factor (CFG) – złoĪony współczynnik wzrostu.
ci danych a wartoci CFG napisano program umoliwiajcy symulacj zjawiska eksplozji. Pro-gram wykorzystuje struktur bazy danych przedstawion na rysunku 5. Dla okrelonej z góry war-toci współczynnika gswar-toci danych jest generowana odpowiednia liczba elementów rozmieszczo-nych losowo w tablicy o wymiarach 25x25. Nastpnie jest sprawdzana liczba niepustych elemen-tów, która w porównaniu z liczb elementów ródłowych daje CFG. Próba jest przeprowadzana kilkakrotnie w zalenoci od zadanej wartoci. Symulacj przeprowadzono dla nastpujcych war-toci współczynnika gswar-toci danych: 0.5, 5, 10, 20, 30, 40, 50, 60 oraz 70%, powtarzajc dla kadej z nich pomiar 20-krotnie. Wyniki pomiarów zostały przedstawione na rysunku 6. Pionowe odcinki reprezentuj dane uzyskane w symulacji za linia jest krzyw logarytmiczn aproksymuj-c otrzymane wyniki.
Rys. 6. WartoĞü CFG w zaleĪnoĞci od współczynnika gĊstoĞci danych ħródło: www.olapreport.com
Wykorzystujc wyniki symulacji mona stwierdzi , e dla bazy danych o 4 wymiarach i da-nych, których współczynnik gstoci wynosi 15% współczynnik wzrostu (FG) wyniesie około 10 (dokładnie: 1.84). Innymi słowy ładujc dane do hurtowni, które w agregacie podstawowym zajm 10 MB, wypełniajc go w 15%, mona spodziewa si, e wszystkie agregaty zajm około 100 MB. Warto współczynnika CFG dla n-wymiarowej bazy danych nie moe by wyznaczana na podstawie danych o tej samej gstoci, umieszczonych w 2- lub 3-wymiarowej bazie. Autor twier-dzi, e w przypadku danych rzadkich umieszczonych w wielowymiarowej bazie danych mona przyj orientacyjn warto współczynnika CFG, która dla bazy 5-wymiarowej wynosi 2 i zwik-sza swoj warto o 0.1 w miar dodawania dodatkowych wymiarów (Tab. 2.).
Tabela 2. WartoĞü współczynnika CFG i FG dla baz 5-9 wymiarowych
Liczba Wymiarów Warto współczynnika CFG Warto współczynnika przyrostu FG
5 2 32 6 2,1 85,8 7 2,2 249,4 8 2,3 783,1 9 2,4 2641,8 ħródło: www.olapreport.com
Z analizy danych wynika, e przeprowadzanie pełnej agregacji w bazie danych o duej iloci wymiarów i rzadkim charakterze danych wie si z astronomicznym wzrostem objtoci bazy (nawet 2500 razy dla bazy 9-wymiarowej). Dane w bazie danych o wielopoziomowej hierarchii wymiarów mog by konsolidowane na rónych poziomach. W zalenoci od stopnia konsolidacji danych zmienia si ich gsto na odpowiednich poziomach. Fakt ten jest równie przyczyn eks-plozji danych. Z powyszego wynika, e najwicej miejsca w wielowymiarowej bazie danych zajmuj agregaty dodatkowe. Im wiksza gsto danych w agregatach, tym wicej zajmuj one miejsca.
4. Ograniczenie wielkoci wielowymiarowej bazy danych
Uniknicie eksplozji wielowymiarowej bazy danych staje si głównym celem projektantów oraz administratorów hurtowni w przypadku baz o liczbie wymiarów wikszej ni 5 i rzadkim charakterze danych. Mona tego dokona poprzez:
− Rezygnacj z pełnej agregacji danych na rzecz agregacji obliczanych na bieco (on-thefly). Niektóre produkty posiadaj odpowiednie mechanizmy grupowania, agregacji oraz obliczania rankingów, udziałów procentowych i innych wskaników, które s optymalizowane w operowaniu na danych w locie.
− Redukcj zjawiska rzadkich danych poprzez odpowiednie projektowanie, uywanie rozwiza opartych na multicube oraz ograniczenie do minimum liczby niezbdnych wymiarów. Redukcj wymiarów mona przeprowadzi poprzez łcznie dwóch wybranych wymiarów w jeden wymiar złoony (ang. compound dimensions, conjoint dimensions – Oracle Express). Zwikszenie współczynnika gstoci danych wie si ze zmniejszeniem ryzyka wystpienia eksplozji bazy danych oraz ze znacznym zmniejszeniem objtoci bazy danych. Jednak takie rozwizanie ma swoje wady, którymi s: nieprzejrzysta struktura danych – nieczytelna dla uytkownika, due obcienie aplikacji OLAP zwizane ze skomplikowanymi procedurami grupowania i agregowania.
Lepszym rozwizaniem wydaje si by ograniczenie liczby agregatów poprzez wyliczanie nie-których z nich w locie. Takie rozwizanie wymaga okrelenia liczby oraz typów agregatów, jakie maj by przechowywane w bazie albo wyliczane na bieco. Dla kadego poziomu gstoci da-nych mona wyznaczy optimum pomidzy agregatami przechowywanymi a obliczanymi. Opti-mum to bdzie zaleało od wielu współczynników zwizanych z infrastruktur techniczn hurtow-ni, charakterem oprogramowania, liczby uytkowników, załoonego czasu odpowiedzi, maksymal-nego rozmiaru bazy danych, charakteru procesu ładowania itp. Oczywicie wraz z liczb agrega-tów dodatkowych ronie rozmiar bazy danych, ale co wane maleje czas oczekiwania na wynik zapytania. W przypadku baz danych o stopniu agregacji powyej 90% czas oczekiwania na wynik zapytania wzrasta. Przyczyn tego zjawiska jest konieczno trzymania w pamici RAM duej iloci kluczowych danych dotyczcych agregatów. Wskim gardłem nie jest wtedy moc oblicze-niowa procesora, ale dostp do pamici. Jeeli zostanie okrelony optymalny stopie agregacji bazy danych, kolejnym etapem jest wybranie agregatów, które maj by przechowywane w bazie. Zbiór agregatów magazynowanych powinien obejmowa przede wszystkim:
− dane, których obliczanie w czasie rzeczywistym zajmuje zbyt duo czasu, poniewa zale od wielu komórek ródłowych, formuł itp.;
− dane, które s podstaw do obliczania wielu agregatów pochodnych.
Niektóre aplikacje mog wymaga danych, które s w pełni zagregowane, pomimo tego, e dla pracy optymalnej jest to raczej niewskazane. Pełn agregacj mona zastosowa w przypadku:
− małych aplikacji (kilka milionów komórek ródłowych), w których obliczenia nie s skomplikowane, a pami dyskowa nieograniczona;
− aplikacji operujcych na mniej ni 5 wymiarach;
− koniecznoci stosowania oblicze kompleksowych i współzalenych;
− zapotrzebowania na wszelkiego rodzaju agregacje (ang. all-important) np. w niektórych aplikacjach EIS;
− aplikacji z du liczb konkurencyjnych wzgldem siebie uytkowników (np. aplikacje via WEB).
5. Podsumowanie
Warto współczynnika wzrostu jest charakterystyczna dla produktów odpowiednich produ-centów. Niektóre z nich nigdy nie były zagroone eksplozj (iTM1, PowerPlay). W przypadku niektórych systemów producenci dołczali pakiety z oprogramowaniem administracyjnym, które miały ograniczy (nie zlikwidowa ) problem eksplozji. Przykładowo Hyperion Essbase 5.0 został wyposaony w mechanizm partycjonowania oraz ulepszone procedury przeliczania „w locie”. Baza danych Seagate Holos 6.0 została wyposaona w technologi COA (ang. Compound OLAP Archi-tecture – złoona architektura OLAP). Kolejna, siódma wersja Seagate Holos została rozszerzona o wyrafinowany mechanizm przeliczania agregatów „w locie”. Pomimo ulepsze zastosowanych np. w Hyperion Essbase 5.0 system ten generuje bazy 10-100 razy wiksze od baz wygenerowa-nych przez PowerPlay lub OLAP Services. Niektórzy producenci do swoich systemów dołczaj oprogramowanie, które nie tylko kontroluje, ale aktywnie przeciwdziała eksplozji. Informix Meta-Cube 4 posiada narzdzie pomagajce okreli optymaln strategi agregowania. Microsoft OLAP Services poza podobnymi moliwociami pozwala uytkownikowi zdecydowa na jakiej partycji i w jaki sposób (relacyjny lub wielowymiarowy) maj by przechowywane odpowiednie agregaty.
Obecnym kierunkiem rozwoju technologii MOLAP jest opracowanie efektywnych procedur kompresji danych wielowymiarowych, aby moliwe było przechowywanie duej liczby agregatów. Bibliografia
1. M.Gorawski: „Analiza porównawcza ROLAP i MOLAP”, Software 8/1999.
2. M.Gorawski: „Data Warehouse Słownik Waniejszych Poj ”, Raport Computerworld nr 12/2000.
3. M.Gorawski: „Hurtownia danych”, Informatyka nr 3/2000.
4. N. Pendse: „Database explosion” , OLAP Report 2000, http://www.olapreport.com. 5. N. Pendse: „Market segment analysis”, OLAP Report 2000, http://www.olapreport.com.
NOT CONTROLLED GROWTH IN VOLUME OF THE DATA IN MULTIDIMENSIONAL OLAP
Summary
Differentiated Data Base Management Systems are used for realization of ana-lytical processing systems (OLAP). In practice multidimensional analysing technolo-gies support specialised MOLAP solutions and also the most popular relational data base management systems. Solutions used at market of decision support applications have different susceptibility for not controlled growth in data base being result of creation of data aggregates/
Keywords: OLAP, data bases, data aggregates
Grzegorz Dziea zis@utp.edu.pl
Katedra Informatyki w Zarzdzaniu, Wydział Zarzdzania,
Uniwersytet Technologiczno – Przyrodniczy im. Jana i Jdrzeja niadeckich w Bydgoszczy ul. Kaliskiego, 785-970 Bydgoszcz
