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.
POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008
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
�ródło: opracowanie własne
8 M.Gorawski: „Hurtownia danych”, Informatyka nr 3/2000.
Grzegorz Dzie�a, Andrzej Makulski
Problemy wzrost obj�to�ci danych w Multidimensional OLAP
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
�ródło: opracowanie własne
POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008
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.
Grzegorz Dzie�a, Andrzej Makulski
Problemy wzrost obj�to�ci danych w Multidimensional OLAP
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
�ródło: www.olapreport.com
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
POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008
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
�ródło: opracowanie własne
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.
Grzegorz Dzie�a, Andrzej Makulski
Problemy wzrost obj�to�ci danych w Multidimensional OLAP
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
�ródło: www.olapreport.com
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
�ródło: www.olapreport.com
POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008
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;
Grzegorz Dzie�a, Andrzej Makulski
Problemy wzrost obj�to�ci danych w Multidimensional OLAP
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.
POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�Seria: Studia i Materiały, nr 13, 2008
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
Katedra Informatyki w Zarz�dzaniu, Wydział Zarz�dzania,
Uniwersytet Technologiczno – Przyrodniczy im. Jana i J�drzeja niadeckich w Bydgoszczy
ul. Kaliskiego, 785-970 Bydgoszcz