problemy wzrost objętości danych w multidimensional olap · 2016-10-03 · grzegorz dzie a,...

GRZEGORZ DZIEŻA,

ANDRZEJ MAKULSKI

Uniwersytet Technologiczno-Przyrodniczy w Bydgoszczy

PROBLEMY WZROSTU OBJ�TO�CI DANYCH W MULTIDIMENSIONAL OLAP

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. Wst�p

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 zwi�zki wielowymiarowe s� realizowane za pomoc�odpowiednich relacji pomi�dzy wymiarami. Istnieje równie� trzecia technika b�d�ca 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 wielowymiarowej 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 pochodz�ce z zewn�trznych �ródeł, od u�ytkowników ko�cowych lub

powstałe w wyniku agregacji wewn�trz bazy danych, s� magazynowane w strukturze posiadaj�cej

charakter wielowymiarowy.

2. Wielowymiarowe struktury danych

Matematycznie wielowymiarowa baza danych jest macierz� n-wymiarow�. Interpretacj� geo-

metryczn� takiej bazy mo�e by� tablica (baza 2-wymiarowa), kostka (baza 3-wymiarowa) lub

w przypadku baz n-wymiarowych zbiór kostek lub tablic. Dane dotycz�ce sprzeda�y pewnej grupy

produktów s� magazynowane w strukturze o trzech wymiarach (obszar, okres i produkty). Ka�da

kostka w tym przypadku mo�e zawiera� informacje o wielko�ci sprzeda�y, poniesionych kosztach,

1 M.Gorawski: „Data Warehouse Słownik Wa�niejszych Poj��”, Raport Computerworld nr 12/2000.

2 www.olapreport.com

POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008

39

zysku itp. Mo�e równie� zawiera� mniejsze kostki, które b�d� zawiera� dane bardziej precyzyjne.

W typowych zastosowaniach liczba wymiarów w kostce nie przekracza 10, a zawarto�� ka�dej

kostki stanowi� dane numeryczne, rzadziej tekstowe3.

W procesie eksploracji danych u�ytkownik nie ogl�da 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�� sprzeda�y 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, mo�na uzyska� ró�ne zestawienia zmieniaj�c jedynie wymiar tytułowy (np. ilo�� sprze-

danych produktów, �rednia sprzeda� miesi�czna 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, umo�liwiaj�c redukcj� fizycznego rozmiaru bazy danych

oraz skracaj�c czas wykonywania zapyta�. W bazach wielowymiarowych dane maj� posta� rzadk�, tzn. nie wypełniaj� całej przestrzeni wymiarowej (pojedynczy proces biznesowy najcz��ciej opisa-

ny jest za pomoc� jednej kategorii w konkretnym wymiarze). Dane nie s� równie� rozmieszczone

równomiernie, ale mog� wyst�powa� w postaciach skupisk4.

Wybór odpowiedniej struktury danych nie ma wpływu na wizualizacj� danych zawartych w ba-

zie, natomiast zale�y od niego sposób projektowania bazy, agregowania danych, wyboru typu

indeksowania itp. W przypadku zastosowa� praktycznych popularno�ci� ciesz� si� rozwi�zania

struktury typu „hypercube” i „multicube”. Najprostsz� struktur� wielowymiarowej bazy danych

jest kartezja�ski układ współrz�dnych, okre�lony przez wymiary wła�ciwe dla aplikacji. Struktura

taka zwana „data space” w rzeczywisto�ci ma posta� pojedynczych nie skompresowanych tablic

i mo�e by� stosowana na mał� skal� ze wzgl�du na du�y rozmiar pami�ci jak� zaj�łyby dane

o niskim współczynniku g�sto�ci. Układ kartezja�ski 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 du�ych bazach danych ze wzgl�-du na intuicyjn� struktur� logiczn�. Polega ona na odwzorowaniu rzeczywisto�ci w postaci poje-

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”

Grzegorz Dzie�a, Andrzej Makulski

Problemy wzrost obj�to�ci danych w Multidimensional OLAP

40

dynczej n-wymiarowej kostki. Pozwala to na wprowadzanie danych dla ka�dej kombinacji wymia-

rów, dodatkowo ka�da cz�� przestrzeni w strukturze hypercube posiada identyczn� wymiarowo��(jest okre�lona przez te same wymiary). Wymiary nie musz� posiada� równych rozmiarów, a w

zale�no�ci od producenta bazy mo�na stosowa� ró�n� ich maksymaln� liczb�. Przykładem produk-

tu wykorzystuj�cego struktur� 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

g�sta struktura o małej liczbie wymiarów. W przypadku analizy wiekszej liczby wymiarów fringed

hypercube mo�e by� traktowany jako cz�� wi�kszej struktury danych. To rozwi�zanie znalazło

zastosowanie w nast�puj�cych produktach: Hyperion Enterprise, CLIME Comshare FDC. Wielo-

wymiarowa baza danych zrealizowana w oparciu o pojedyncz� wielowymiarow� struktur� wymaga

du�ej ilo�ci pami�ci 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 b�d�cych kompozycj� wielu wymiarów. Struktura taka charakteryzuje si�wysok� uniwersalno�ci�, wydajno�ci� (szczególnie w przypadku rzadkich danych). Multicube jako

podstruktury cz�sto 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ło�ona z kilku logicznych wielowymiarowych baz da-

nych, maj�cych posta� sze�cianów. Mo�na wyró�ni� dwa typy struktury multiciube: block7. i se-

ries. Block multicube wykorzystywany w BusinessObject, Gentia, Holos, Microsoft’s OLAP Se-

rvices i iTM1, u�ywa ortogonalnych wymiarów, w zwi�zku z czym nie posiada dodatkowych wy-

miarów na poziomie danych. Kostka mo�e zawiera� wiele zdefiniowanych wymiarów, a miara i

czas s� traktowane jako równorz�dne wymiary.

3. Agregaty w wielowymiarowych bazach danych

Hurtownia danych zwykle jest zasilana danymi pochodz�cymi z zewn�trznych systemów trans-

akcyjnych. Struktura danych w tych systemach oparta jest najcz��ciej na schemacie relacyjnym, co

uniemo�liwia bezpo�rednie załadowanie ich do wielowymiarowej bazy danych. W celu zasilenia

hurtowni opartej na serwerze MDDB konieczne jest wykonanie serii procedur wsadowych agregu-

j�cych dane w ortogonalne wymiary i wypełniaj�ce struktury tablicowe MDDB. Agregaty s� zsu-

mowanymi danymi ilo�ciowymi w rozbiciu na zmienne kategoryzuj�ce (pola zawieraj�ce dane

słu��ce do grupowania informacji). W ka�dej wielowymiarowej bazie danych znajduje si� agregat

podstawowy, który jest oparty na wszystkich zmiennych kategoryzuj�cych. 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 transak-

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.


41

cyjnych)8. W zale�no�ci od potrzeb definiuje si� agregaty cz��ciowe, które s� oparte w cz��ci na

wybranych zmiennych kategoryzuj�cych. Agregat podstawowy umieszczony jest w dolnej cz��ci

kostki. Do niego trafiaj� zapytania, które s� obsługiwane na miejscu lub przekazywane istniej�cym

agregatom cz��ciowym. W analizie OLAP cz�sto wa�nym czynnikiem jest oczekiwanie na odpo-

wied�. W wielowymiarowych bazach danych uzale�nione jest to od ilo�ci wymiarów, istniej�cych

agregatów cz��ciowych 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 zale�no�ci od rodzaju agregatów czas zwrócenia wyników przez zapytanie jest

zale�ny od tego, czy jest ono obsługiwane przez agregat podstawowy, czy przez agregat cz��cio-

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 cz��ciowego. W przypadku gdy nie ma w bazie agregatu o odpowiedniej strukturze

zapytanie zostaje skierowane do agregatu o strukturze zbli�onej, wówczas czas odpowiedzi zosta-

nie wydłu�ony, poniewa� niektóre z ��danych warto�ci b�d� wymagały przeliczenia. W przypadku,

gdy �aden z istniej�cych agregatów nie posiada struktury zbli�onej do struktury zapytania, realiza-

cja odbywa si� w agregacie podstawowym, który generuje odpowiedni wynik na podstawie danych

atomowych. Proces ten zajmuje najwi�cej czasu ze wzgl�du na du�� ilo�� operacji agregacji jakie

musi przeprowadzi� motor MDDB. W celu zmniejszenia czasu oczekiwania na odpowied� mo�li-we jest wygenerowanie wszystkich mo�liwych agregatów lub cz��ci agregatów.

Rozwi�zanie z wygenerowaniem wszystkich mo�liwych agregatów z pewno�ci� jest optymalne

ze wzgl�du na krótki czas oczekiwania na odpowied�, ale zapewnienie przestrzeni dyskowej po-

trzebnej do przechowania wszystkich agregatów mo�e okaza� si� niemo�liwe. Wygenerowanie

niektórych agregatów cz��ciowych jest rozwi�zaniem na wzór „złotego �rodka”. Zapytania, które

nie posiadaj� gotowych agregatów cz��ciowych, mog� by� obsłu�one przez inne agregaty o struk-

turze zbli�onej do zapytania, co wydłu�y czas oczekiwania, ale korzy�ci� jaka zostanie odniesiona

b�dzie mniejszy rozmiar fizyczny bazy danych. Oczywi�cie pozostaje jeszcze problem wyboru

odpowiednich agregatów cz��ciowych, ze wzgl�du na fakt, �e w fazie projektowania hurtowni nie

zawsze jest mo�liwo�� wgl�du do ostatecznej listy zapyta�, na podstawie której mo�liwe byłoby

wybranie optymalnego zestawu agregatów cz��ciowych. Z poj�ciem agregatu �ci�le zwi�zana jest

hierarchia wymiarów. Okre�la ona sposób grupowania zmiennych kategoryzuj�cych w poszczegól-

nych wymiarach. Przykładowa hierarchia wymiaru dla okresu znajduje si� na rysunku 1.

Rys. 1. Prosta hierarchia wymiaru okres


8 M.Gorawski: „Hurtownia danych”, Informatyka nr 3/2000.



42

Oczywi�cie tak rozbudowana hierarchia spowoduje wzrost liczby danych magazynowanych w

bazie. Rozwi�zaniem mo�e by� tutaj ponowna agregacja danych historycznych. Je�eli firma prze-

chowuje dane z ostatnich 5 lat, to istnieje małe prawdopodobie�stwo, �e do analizy potrzebuje

dziennych, tygodniowych lub nawet miesi�cznych warto�ci z lat poprzednich. Rozwi�zaniem

zmniejszaj�cym rozmiar bazy mo�e by� skonsolidowanie danych historycznych do postaci o

dwóch poziomach np. rok i kwartał, ponowne zagregowanie ich i usuni�cie szczegółowych danych

historycznych. W szczególnych przypadkach istnieje mo�liwo�� stosowania hierarchii posiadaj�cej

w swojej strukturze poziomy podrz�dne wywodz�ce si� bezpo�rednio z dwóch lub wi�kszej liczby

poziomów nadrz�dnych (Rys. 2.). Najwy�szym poziomem hierarchii wymiaru okres jest rok. Po-

ziom główny posiada dwa poziomy potomne w postaci poziomów kwartał i tydzie�. Poziomem

potomnym tygodnia jest dzie�, który jest równie� poprzez poziom rodzicielski - miesi�c potom-

kiem poziomu kwartał. Taka hierarchia wymiaru umo�liwia analiz� danych historycznych z dwóch

punktów widzenia:

− rok �kwartał miesi�c dzie� miesi�ca,

− rok tydzie� �dzie� tygodnia dzie� miesi�ca.

Rys. 2. Zmodyfikowana hierarchia wymiaru okres



43

3. Eksplozja wielowymiarowej bazy danych

Niewła�ciwy pod k�tem wyboru agregatów dodatkowych projekt, nieodpowiedni sposób łado-

wania i konserwacji wielowymiarowej bazy danych mo�e doprowadzi� do gwałtownego wzrostu

obj�to�ci bazy. Zjawisko to cz�sto nazywane jest „eksplozj� wielowymiarowej bazy danych” i

polega na nieprzewidywalnym, niekontrolowanym zwi�kszeniu obj�to�ci bazy w przestrzeni pa-

mi�ci. Na zwi�kszenie obj�to�ci bazy z pewno�ci� wpływ b�d� miały takie czynniki jak:

− g�sto�� danych (wska�nik okre�laj�cy 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 obj�to�ci danych podczas gdy

w niektórych przypadkach warto�� współczynnika wzrostu (ang. GF – Growth Factor) mo�e osi�-gn�� rz�d wielko�ci 10 lub nawet 100. Na niekontrolowany wzrost obj�to�ci bazy nie ma wpływu

charakter �ródła danych. Dane �ródłowe hurtowni danych pochodz� z systemów transakcyjnych,

które najcz��ciej 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

zwi�zany z procesem agregacji danych. Im bardziej dane s� agregowane, czyli zwi�kszany jest ich

stopie� konsolidacji, tym mniej b�d� zajmowały miejsca w pami�ci. Wa�ne jest, �e nawet w przy-

padku zastosowania niskiego stopnia konsolidacji danych, dane w MDDB b�d� 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 zwi�zany jest z faktem, �e w MDDB

nie zawsze istnieje potrzeba przechowywania kluczy, indeksów lub informacji na temat struktury

wymiarów, a je�eli jest to wymagane, to zajmuj� one mniej pami�ci ni� w systemach relacyjnych.

Niektóre bazy danych maj� mo�liwo�� 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 wcze�niej wspomniano zdefiniowanie wszystkich mo�liwych agregatów jest niew�tpliwie

skuteczne w przypadku, gdy wymagane jest szybkie zwrócenie wyniku zapytania. Jednak z drugiej

strony takie rozwi�zanie to główna przyczyna eksplozji bazy danych. Pogl�d na rozmiar danych

�ródłowych, umieszczonych w agregacie podstawowym, agregatach dodatkowych oraz oblicza-

nych na ��danie przedstawia rysunek 3.

9 www.olapreport.com

10 N. Pendse: „Database explosion” , OLAP Report 2000, http://www.olapreport.com.



44

Rys. 3. Rozmiary danych ródłowych i zagregowanych w wielowymiarowej bazie danych

�ródło: www.olapreport.com

Po�rednio wpływ na wzrost obj�to�ci danych ma hierarchia wymiarów. W zale�no�ci od liczby

poziomów oraz od ich szeroko�ci zale�e� b�dzie liczba mo�liwych agregatów. W celu zobrazowa-

nia wpływu hierarchii na współczynnik wzrostu bazy mo�na zało�y� istnienie wymiaru o hierarchii

przedstawionej na rysunku 4.

Rys. 4. Przykład hierarchii prostej


Kolorem czarnym oznaczone s� agregaty zawieraj�ce dane, kolorem niebieskim agregaty puste.

W zale�no�ci od poziomu jaki zostanie wybrany do analizy, g�sto�� danych jest ró�na. Bior�c pod

uwag� dane skonsolidowane, współczynnik g�sto�ci danych wynosi 80% (4 kategorie z danymi na

5 mo�liwych). Na najni�szym poziomie tej hierarchii współczynnik g�sto�ci jest mniejszy i wynosi

32% (8 kategorii pustych na 25 mo�liwych). Współczynnik wzrostu (GF) bazy danych o jednym


45

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


Zakładaj�c baz� 2-wymiarow� (Rys. 5.) mo�na zaobserwowa� wpływ liczby wymiarów na war-

to�� współczynnika wzrostu (GF). Dla uproszczenia mo�na przyj��, �e oba wymiary maj� iden-

tyczn� struktur� hierarchiczn�. Kolor biały okre�la komórki, w których znajduj� si� dane agregatu

podstawowego (ang. detail data). Kolor jasno-szary okre�la dane skonsolidowane (ang. consolida-

ted data) na pierwszym poziomie, w�skie komórki dane skonsolidowane na poziomie drugim.

Kolorem ciemnoszarym oznaczono odpowiednio dane podsumowuj�ce 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 zawieraj�cych dane atomowe, reprezen-

tuj�cych agregat podstawowy oraz 336 komórek, w których znajduj� si� dane reprezentuj�ce agre-

gaty dodatkowe. Wynika z tego, �e w tym konkretnym przypadku na dowolne 2 komórki �ródłowe

przypada wi�cej 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�mo�e przypada� 2 do 3 komórek obliczanych. W zale�no�ci od g�sto�ci danych umieszczonych w

bazie danych przedstawionej na rysunku 6 współczynnik wzrostu (GF) mo�e przyjmowa� warto�ci

od 1,5 dla danych o g�sto�ci 100% do 5,83 dla danych o g�sto�ci 1%. Na podstawie tych wyników

mo�na okre�li� 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 wykre�lenia zale�no�ci pomi�dzy g�sto-

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.



46

�ci� danych a warto�ci� CFG napisano program umo�liwiaj�cy symulacj� zjawiska eksplozji. Pro-

gram wykorzystuje struktur� bazy danych przedstawion� na rysunku 5. Dla okre�lonej z góry war-

to�ci współczynnika g�sto�ci danych jest generowana odpowiednia liczba elementów rozmieszczo-

nych losowo w tablicy o wymiarach 25x25. Nast�pnie 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 zale�no�ci od zadanej warto�ci. Symulacj� przeprowadzono dla nast�puj�cych war-

to�ci współczynnika g�sto�ci danych: 0.5, 5, 10, 20, 30, 40, 50, 60 oraz 70%, powtarzaj�c dla

ka�dej 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


Wykorzystuj�c wyniki symulacji mo�na stwierdzi�, �e dla bazy danych o 4 wymiarach i da-

nych, których współczynnik g�sto�ci wynosi 15% współczynnik wzrostu (FG) wyniesie około 10

(dokładnie: 1.84). Innymi słowy ładuj�c dane do hurtowni, które w agregacie podstawowym zajm�10 MB, wypełniaj�c go w 15%, mo�na spodziewa� si�, �e wszystkie agregaty zajm� około 100

MB. Warto�� współczynnika CFG dla n-wymiarowej bazy danych nie mo�e by� wyznaczana na

podstawie danych o tej samej g�sto�ci, umieszczonych w 2- lub 3-wymiarowej bazie. Autor twier-

dzi, �e w przypadku danych rzadkich umieszczonych w wielowymiarowej bazie danych mo�na

przyj�� orientacyjn� warto�� współczynnika CFG, która dla bazy 5-wymiarowej wynosi 2 i zwi�k-

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



47

Z analizy danych wynika, �e przeprowadzanie pełnej agregacji w bazie danych o du�ej ilo�ci

wymiarów i rzadkim charakterze danych wi��e si� z astronomicznym wzrostem obj�to�ci 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 zale�no�ci od stopnia konsolidacji

danych zmienia si� ich g�sto�� na odpowiednich poziomach. Fakt ten jest równie� przyczyn� eks-

plozji danych. Z powy�szego wynika, �e najwi�cej miejsca w wielowymiarowej bazie danych

zajmuj� agregaty dodatkowe. Im wi�ksza g�sto�� danych w agregatach, tym wi�cej zajmuj� one

miejsca.

4. Ograniczenie wielko�ci wielowymiarowej bazy danych

Unikni�cie eksplozji wielowymiarowej bazy danych staje si� głównym celem projektantów

oraz administratorów hurtowni w przypadku baz o liczbie wymiarów wi�kszej ni� 5 i rzadkim

charakterze danych. Mo�na tego dokona� poprzez:

− Rezygnacj� z pełnej agregacji danych na rzecz agregacji obliczanych na bie��co (on-

thefly). Niektóre produkty posiadaj� odpowiednie mechanizmy grupowania, agregacji

oraz obliczania rankingów, udziałów procentowych i innych wska�ników, które s�optymalizowane w operowaniu na danych w locie.

− Redukcj� zjawiska rzadkich danych poprzez odpowiednie projektowanie, u�ywanie

rozwi�za� opartych na multicube oraz ograniczenie do minimum liczby niezb�dnych

wymiarów. Redukcj� wymiarów mo�na przeprowadzi� poprzez ł�cznie dwóch

wybranych wymiarów w jeden wymiar zło�ony (ang. compound dimensions, conjoint

dimensions – Oracle Express). Zwi�kszenie współczynnika g�sto�ci danych wi��e si�ze zmniejszeniem ryzyka wyst�pienia eksplozji bazy danych oraz ze znacznym

zmniejszeniem obj�to�ci bazy danych. Jednak takie rozwi�zanie ma swoje wady,

którymi s�: nieprzejrzysta struktura danych – nieczytelna dla u�ytkownika, du�e

obci��enie aplikacji OLAP zwi�zane ze skomplikowanymi procedurami grupowania i

agregowania.

Lepszym rozwi�zaniem wydaje si� by� ograniczenie liczby agregatów poprzez wyliczanie nie-

których z nich w locie. Takie rozwi�zanie wymaga okre�lenia liczby oraz typów agregatów, jakie

maj� by� przechowywane w bazie albo wyliczane na bie��co. Dla ka�dego poziomu g�sto�ci da-

nych mo�na wyznaczy� optimum pomi�dzy agregatami przechowywanymi a obliczanymi. Opti-

mum to b�dzie zale�ało od wielu współczynników zwi�zanych z infrastruktur� techniczn� hurtow-

ni, charakterem oprogramowania, liczby u�ytkowników, zało�onego czasu odpowiedzi, maksymal-

nego rozmiaru bazy danych, charakteru procesu ładowania itp. Oczywi�cie wraz z liczb� agrega-

tów dodatkowych ro�nie rozmiar bazy danych, ale co wa�ne maleje czas oczekiwania na wynik

zapytania. W przypadku baz danych o stopniu agregacji powy�ej 90% czas oczekiwania na wynik

zapytania wzrasta. Przyczyn� tego zjawiska jest konieczno�� trzymania w pami�ci RAM du�ej

ilo�ci kluczowych danych dotycz�cych agregatów. W�skim gardłem nie jest wtedy moc oblicze-

niowa procesora, ale dost�p do pami�ci. Je�eli zostanie okre�lony 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 du�o czasu, poniewa�zale�� od wielu komórek �ródłowych, formuł itp.;

− dane, które cz�sto s� pobierane z bazy;



48

− 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� mo�na 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 operuj�cych na mniej ni� 5 wymiarach;

− konieczno�ci stosowania oblicze� kompleksowych i współzale�nych;

− zapotrzebowania na wszelkiego rodzaju agregacje (ang. all-important) np.

w niektórych aplikacjach EIS;

− aplikacji z du�� liczb� konkurencyjnych wzgl�dem siebie u�ytkownikó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 zagro�one 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ł

wyposa�ony w mechanizm partycjonowania oraz ulepszone procedury przeliczania „w locie”. Baza

danych Seagate Holos 6.0 została wyposa�ona w technologi� COA (ang. Compound OLAP Archi-

tecture – zło�ona 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 wi�ksze 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 narz�dzie pomagaj�ce okre�li� optymaln� strategi� agregowania. Microsoft OLAP

Services poza podobnymi mo�liwo�ciami pozwala u�ytkownikowi 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 mo�liwe było przechowywanie du�ej liczby agregatów.

Bibliografia

1. M.Gorawski: „Analiza porównawcza ROLAP i MOLAP”, Software 8/1999.

2. M.Gorawski: „Data Warehouse Słownik Wa�niejszych 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.


49

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 Dzie�a

[email protected]

Katedra Informatyki w Zarz�dzaniu, Wydział Zarz�dzania,

Uniwersytet Technologiczno – Przyrodniczy im. Jana i J�drzeja niadeckich w Bydgoszczy

ul. Kaliskiego, 785-970 Bydgoszcz

problemy wzrost objętości danych w multidimensional olap · 2016-10-03 · grzegorz dzie a,...

Documents