Arhitectura sistemelor OLAP

5. Arhitectura sistemelor OLAP

Sistemele OLAP permit analiştilor şi managerilor să îmbunătăţească

performanţele unei firme, printr-un acces interactiv rapid la o mare varietate de viziuni
de date organizate, pentru a reflecta aspectul multidimensional al datelor dintr-o
întreprindere. Modelul conceptual multidimensional este cel mai natural mod de a
vizualiza informaţiile din afaceri. Dar stocarea acestor volume mari de informaţii
multidimensionale, într-un mod practic pe calculator, este departe de a fi uşor. Datele
multidimensionale nu trebuie să fie numai stocate ci trebuie să fie vizualizate,
actualizate şi folosite pentru calculul altor rezultate, preferabil în mai puţin de cinci
secunde. Modul cum sunt stocate va afecta performanţa şi funcţionalitatea la fiecare din
celelalte cerinţe. Din acest motiv, instrumentele OLAP trebuie să ofere un răspuns
rapid, indiferent de volumul de date ce trebuie utilizat pentru o simplă interogare.
Timpul de răspuns pentru o cerere ar trebui să depindă de numărul de rezultate afişate
pe ecran şi nu de dimensiunea bazei de date. În practică, cele mai multe aplicaţii OLAP
sunt foarte împrăştiate. În general mai puţin de o celulă dintr-o mie de celule are date.
Deoarece aplicaţiile OLAP sunt de fapt sisteme suport de decizie interactive, este
important ca ele să rămână rapide, chiar dacă baza de date este mare şi împrăştiată. Se
urmăreşte să se consume mai puţin spaţiu fizic pentru stocarea informaţiilor lipsă sau a
indecşilor. Multe soluţii posibile există, fiecare cu avantaje şi dezavantaje.
Factorii ce determină alegerea unei soluţii sunt :
ƒ Volumul de date curente stocat. Dacă volumul este relativ mic, o stocare în
RAM ar fi cea mai bună soluţie;
ƒ Gradul de împrăştiere a datelor. Dacă datele sunt foarte împrăştiate, poate fi
necesară o indexare mai complexă şi compresia datelor, care vor face
instrumentul mai lent;
ƒ Frecvenţa de actualizare a datelor şi modul cum se face actualizarea (în loturi
sau celule individuale);
ƒ Numărul de utilizatori;
ƒ Tipul arhitecturii client/server (unde are loc procesarea multidimensională);
ƒ Cantitatea de memorie reală şi virtuală valabilă. Aceasta va determina câte date
active trebuie păstrate în memorie;
ƒ Performanţa discului şi a microprocesorului;
ƒ Frecvenţa de modificare a dimensiunilor bazei de date etc.
Ţinând cont de aceşti factori, proiectanţii de instrumente OLAP selectează
tehnicile pe care le vor utiliza pentru a stoca şi gestiona datele multidimensionale,
pentru aceste aplicaţii. Astfel, nici un instrument nu este optim pentru orice aplicaţie

5-1
 Arhitectura sistemelor OLAP

OLAP. Toate instrumentele folosesc o combinaţie de tehnici. Prima decizie ce trebuie

luată este de a stabili unde sunt stocate datele din model, când sunt procesate şi
accesate.
În ultimii ani, un număr mare de instrumente OLAP permit stocarea datelor atât
în baze de date relaţionale cât şi multidimensionale. Astfel, modul de stocare a datelor a
devenit un criteriu de clasificare a sistemelor OLAP şi anume în: sisteme ROLAP,
sisteme MOLAP şi sisteme HOLAP. În acest capitol, se vor prezenta comparativ aceste
sisteme. Se va pune accentul pe avantajele şi dezavantajele lor, precum şi pe tipurile de
aplicaţii pentru care sunt destinate. În finalul capitolului, se prezintă comparativ tipurile
de arhitecturi specifice sistemelor OLAP.

5.1. Sisteme ROLAP

În ultimii ani, un număr mare de instrumente OLAP permit stocarea datelor
multidimensionale în baze de date relaţionale (depozite de date). Chiar dacă o aplicaţie
OLAP stochează toate datele sale într-o bază de date relaţională, totuşi ea va lucra
separat, pe o copie separată a datelor (depozite de date/centre de date), nu pe baza de
date tranzacţională. Aceasta permite să fie structurată optim pentru OLAP mai bine
decât pentru alte aplicaţii. Datele multidimensionale pot fi stocate în depozite de
date/centre de date, utilizând schema stea sau fulg de zăpadă. Problema este de a oferi
acces rapid şi flexibilitate în manipularea multidimensională. Totuşi tabela de fapte este
un mod ineficient de a stoca volume mari de date. Dacă sunt multe variabile, există
posibilitatea de a nu le putea stoca pe toate într-o singură tabelă de fapte (gradul de
împrăştiere poate diferi mult între grupurile de variabile). Datele pot fi încărcate din
multiple surse, astfel actualizările unei singure tabela de fapte foarte mare sunt
ineficiente. De aceea, în aplicaţiile complexe, tabela de fapte este partiţionată în grupuri
de variabile după gradul de împrăştiere, stabilindu-se, de asemenea, dimensiunile
corespunzătoare şi sursele de date. În aplicaţiile OLAP complexe pot exista 10..20 de
tabele de fapte. Pentru o bună performanţă la interogare, unele agregări trebuie
antecalculate şi stocate în tabele de agregate. În aplicaţiile complexe pot exista mii de
tabele de agregate.
În figura 5-1, este prezentată arhitectura unui sistem ROLAP. Un motor ROLAP
face trecerea dinamică între modelul de date multidimensional logic M şi modelul de
stocare relaţional R. Tehnic vorbind acest motor implementează o transformare a unei
cereri multidimensionale m pe modelul de date multidimensional logic M, într-o cerere
relaţională r pe modelul de stocare R. Eficienţa la interogare este factorul dominat
asupra performanţei globale a sistemului şi scalabilităţii. Strategiile de optimizare sunt
factorii principali în diferenţierea sistemelor ROLAP existente. Preocuparea majoră este
găsirea celei mai eficiente reprezentări a cererii pentru un SGBDR dat şi a schemei date,
precum şi încărcarea dinamică echilibrată între SGBDR şi motorul ROLAP. Întrucât
optimizatorul de cereri al SGBDR ar putea să nu fie capabil să aleagă planul de execuţie
optim pentru cereri, unele instrumente (de exemplu DSS Server/Microstrategy) împart
cererea complexă în mai multe subcereri, care sunt executate secvenţial (SQL în mai
mulţi paşi). Să considerăm QR(m) setul tuturor reprezentărilor relaţionale ale cererii
multidimensionle m pentru modelul relaţional R (incluzând toate variantele în mai mulţi
paşi). Pentru fiecare cerere, motorul ROLAP trebuie să aleagă o reprezentare optimă pe
baza unui criteriu (de exemplu performanţa cererii).
Unele operaţii multidimensionale nu pot fi exprimate uşor folosind limbajul
SQL. Este necesar pentru motorul ROLAP să implementeze aceste operaţii folosind
structuri de date multidimensionale. Aceasta complică problema de optimizare prin

5-2
 Arhitectura sistemelor OLAP

extinderea spaţiului de căutare QR(m). Încărcarea echilibrată între serverul de bază de

date şi motorul ROLAP este un rezultat al strategiei utilizate pentru a alege cererea
optimă. Evaluarea operaţiilor multidimensionale de către motorul ROLAP poate reduce
timpii de procesare a unei cereri dar şi scalabilitatea globală a sistemului.
Factorii ce influenţează decizia de optimizare pot fi împărtiţi în statici şi
dinamici (ce pot fi evaluaţi numai la momentul execuţiei). Factorii statici sunt: natura
operaţiei multidimensionale, complexitatea operaţiei executate de motorul ROLAP faţă
de complexitatea implementării relaţionale. Factorii dinamici includ caracteristicile de
încărcare ale serverului de bază de date şi ale motorului ROLAP, volumul datelor
curente ce trebuie să fie transferate de la sistemul relaţional la motorul ROLAP. De
exemplu, Decision Suite/Microstrategy permite administratorului să determine locaţia
procesării prin metadate.

Aplicaţia analitică client

Clienţi OLAP

Interfaţa
multidimensională

optimizarea cerererii procesarea multidimensională Motor ROLAP

multidimensionale
metadate

generarea cererii transformare

relaţionale

SQL interfaţa
relaţională

SGBDR

Figura 5-1. Arhitectura unui sistem ROLAP

Alte probleme ale instrumentelor ROLAP sunt: i) metamodelele (pentru o

schemă stea sau fulg de zăpadă metamodelul este foarte important); ii) seturile de
funcţii complexe etc. Limbajul SQL standard nu permite operaţii multidimensionale.
Specialiştii oferă trei soluţii pentru a adăuga funcţionalitate multidimensională la datele
stocate în tabelele SQL : i) integrarea procesării multidimensionale în sistemul de
gestiune a bazei de date relaţionale, fie prin extinderea limbajului SQL sau prin
adăugarea funcţionalităţii multidimensionale în nucleul SGBD-ului; ii) executarea în
mai mulţi paşi a comenzilor SQL (multipass SQL). Instrumentul OLAP realizează o
serie de comenzi SELECT, în care ieşirile comenzilor anterioare sunt stocate în tabele
temporale, care sunt apoi utilizate de comenzile următoare; iii) încărcarea datelor
relevante din tabelele corespunzătoare pe un server de aplicaţie intermediar, unde este
realizată procesarea multidimensională.
Datorită modului complicat în care datele sunt stocate pe disc, instrumentele
OLAP ce folosesc baze de date relaţionale permit numai citirea datelor. Alte
instrumente trebuie să fie utilizate pentru actualizarea datelor de bază şi a tabelele de
agregate. Aceste instrumente ROLAP nu pot fi folosite pentru analize de tip “what-if”.

5-3
 Arhitectura sistemelor OLAP

În concluzie, stocarea datelor multidimensionale se face într-o bază de date

relaţională atunci când:
ƒ Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu sunt
copiate în baza de date multidimensională ci sunt stocate în baze de date
relaţionale sursă (depozite de date/ centre de date) şi citite când este nevoie.
ƒ Datele sursă se modifică frecvent şi este mai bine de a citi în timp real decât din
copii.
ƒ Integrarea cu alte sisteme informatice relaţionale existente.
ƒ Firma are o politică de neduplicare a datelor în alte structuri de fişiere, pentru
securitate sau alte motive, chiar dacă aceasta conduce la aplicaţii mai puţin
eficiente.
Câteva avantaje ale sistemelor ROLAP sunt: i) se integrează cu tehnologia şi
standardele existente; ii) sistemele MOLAP nu permit cereri ad-hoc eficace, deoarece
sunt optimizate pentru operaţii multidimensionale; iii) actualizarea sistemelor MOLAP
este dificilă; iv) sistemele ROLAP sunt adecvate pentru a stoca volume mari de date,
prin utilizarea procesării paralele şi a tehnologiilor de partiţionare etc; v) sistemele
MOLAP sunt limitate la 5-10 dimensiuni şi sunt adecvate pentru aplicaţii
departamentale cu volume mici de date şi dimensionalitate limitată, iar sistemele
ROLAP au o arhitectură flexibilă ce oferă suport pentru o varietate mare de SSD-uri şi
cerinţe analitice (figura 5-2); vi) volatilitatea descrie gradul la care datele şi structurile
de date se modifică în timp. Datele cu un nivel de volatilitate scăzut rămân relativ
constante. De exemplu, datele despre timp au un nivel scăzut de volatilitate (zilele sunt
grupate întotdeauna în luni şi lunile sunt întotdeauna grupate în ani). Datele despre
produse, angajaţi, clienţi se modifică frecvent. Volatilitatea datelor afectează cerinţele
de procesare în lot ale sistemului. Ori de câte ori datele atomice se modifică, datele
agregate, ce au fost antecalculate, trebuie să fie recalculate. De aceea, datele volatile au
un impact mai mare asupra unui sistem, care conţine un volum mare de informaţii
agregate, decât asupra unui sistem care calculează valorile agregate la momentul
execuţiei. Atât sistemele ROLAP cât şi cele MOLAP sunt optime pentru aplicaţii cu
volatilitate scăzută a datelor. Pentru aplicaţiile cu volatilitate ridicată a datelor, numai
sistemele ROLAP sunt optime.

5.2. Sisteme MOLAP

Cel mai evident mod de a stoca datele multidimensionale este ca o simplă
matrice. Spaţiul este rezervat pentru fiecare combinaţie posibilă între membrii
dimensiunilor. În unele instrumente, numai valorile nenule sunt stocate. Numai
matricile ce conţin date sunt stocate fizic. Fiecare dimensiune a matricii reprezintă o
dimensiune a cubului. Conţinutul matricii sunt măsurile cubului. O astfel de matrice are
multe avantaje: se identifică rapid locaţia oricărei celule, iar celulele pot fi actualizate
fără a afecta locaţia fizică a celorlalte celule. Totuşi stocarea datelor pe disc folosind o
simplă matrice, ce reflectă direct viziunea utilizatorului, este foarte rar eficientă. Chiar
şi atunci când datele sunt stocate în memorie, este adesea necesar de a păstra datele într-
un format mai complex decât o simplă matrice. Aceasta are legatură cu fenomenul de
împrăştiere şi cu cerinţa de a modifica dimensiunile, fără să fie nevoie să se
reconstruiască din nou întreaga matrice. În cazul stocării pe disc a datelor împrăştiate,
datele sunt citite în blocuri şi dacă fiecare bloc are un grad de împrăştiere mare, multe
blocuri goale sau aproape goale vor fi stocate în memorie, iar memoria va fi utilizată de
mult mai multe ori decât este necesar.

5-4
 Arhitectura sistemelor OLAP

Atomicitate
(Gb) 1000
1 2

100
3 ROLAP 4

10
5 6
MOLAP

10 100 1000 dimensionalitate

1=SSD pentru analiza vânzărilor (activitate de comerţ) 4=SSD pentru analiza poliţelor de asigurare
2=SSD pentru analiza promoţională 5=EIS pentru analiza financiară
3=SSD pentru analiza profitului bancar 6= SSD pentru analiza creditului bancar

Figura 5-2. Utilizarea sistemelor MOLAP /ROLAP pentru diferite tipuri de aplicaţii SSD

Sistemele MOLAP au pus accentul pe flexibilitatea şi optimizarea tehnicilor de

stocare şi pe conceptul de tranzacţie. Sistemele MOLAP nu au încă o tehnologie pentru
stocarea şi gestionarea datelor unanim acceptată. Stocarea fizică a datelor
multidimensionale, precum şi fenomenul de împrăştiere sunt preocupări majore, în
domeniul bazelor de date multidimensionale. O tehnică de stocare a datelor optimă ar
trebui să ţină cont de mulţi factori dinamici şi anume: i) profilul datelor şi volumul lor
(numărul de dimensiuni şi membrii ai dimensiunilor, tipuri de date etc); ii) fenomenul
de împrăştiere (în care dimensiuni sau combinaţii de dimensiuni, tipul de împrăştiere);
iii) frecvenţa de modificare în sursele de date (cât de des vor fi actualizate bazele de
date multidimensionale); iv) frecvenţa de modificare în datele multidimensionale (de
exemplu pentru analiza de tip “what if”); v) frecvenţa de modificare în modelul
multidimensional (dimensiuni, membri ai dimensiunilor); vi) accesul concurent; vii)
accesul la scriere etc.
Ideal un SGBDMD ar trebui să aleagă structura de date optimă în funcţie de
aceşti factori. În cele mai multe SGBDMD comerciale se utilizează o tehnică de stocare
pe două niveluri. La nivelul inferior sunt stocate toate dimensiunile dense. Nivelul
superior conţine dimensiunile împrăştiate ca o structură index, care conţine pointeri la
cuburile de date dense din nivelul inferior.
Unele dintre instrumentele OLAP oferă administratorului un număr foarte
limitat de opţiuni de optimizare. De exemplu, Arbor Essbase (Hyperion Essbase) are o
metodă proprie pentru stocarea şi încărcarea datelor multidimensionale în memorie.
Aceasta metodă utilizează o structură multinivel (cu un număr arbitrar de niveluri pentru
diferitele grade de împrăştiere). Administratorul poate specifica dimensiunile dense şi
împrăştiate, care construiesc cele două niveluri. Oracle Express suportă, de asemenea, o
structură pe două niveluri. Pilot Decision Support Suite (Pilot Software) suportă aşa
numitele multicuburi. Timpul este tratat ca o dimensiune densă, iar toate celelalte
dimensiunile sunt considerate împrăştiate.
O a două problemă este transferul conceptului de tranzacţie aşa cum este
cunoscut şi acceptat în lumea relaţională la SGBDMD. Puţine instrumente MOLAP (de
exemplu Arbor Essbase ) permit acces multiutilizator concurent atât la citire cât şi la
scriere. Majoritatea instrumentelor MOLAP permit acces multiutilizator la citire şi
monoutilizator la scriere. SGBDMD blochează întreaga bază de date în timpul
actualizărilor (care este o formă foarte simplă de acces concurent). De asemenea, multe
instrumente MOLAP au o noţiune foarte vagă a conceptului de tranzacţie. Modificările

5-5
 Arhitectura sistemelor OLAP

în cuburile de date pot fi executate ca adăugări în cub sau în timpul analizei de tip “what
if”. Adesea ele cer o actualizare incrementală a agregatelor sau măsurilor, care sunt
calculate pe bază de formulă. Astfel de dependenţe fac actualizările mult mai
complicate. Conceptul de tranzacţie este legat de multe alte probleme cum ar fi:
ƒ propietăţile ACID (atomic, consistency, isolation, durability). Pentru a realiza
propietăţile ACID, toţi termenii (în special consistenţa şi izolarea) trebuie
reanalizaţi. De exemplu, dependenţele între datele de detaliu, datele agregate şi
măsuri complică noţiunea de consistenţă.
ƒ mecanismul de blocare. Dacă controlul concurenţial este realizat printr-o tehnică
de blocare, trebuie să fie definite modurile de blocare şi nivelul la care se face
blocarea. Blocarea întregii baze de date nu este o soluţie foarte potrivită. Totuşi
interdependenţele între date fac ca definirea nivelurilor de blocare să fie o
problemă complexă.
ƒ strategia de propagare a modificărilor. Datele (agregate şi măsuri) trebuie
modificate în conformitate cu modificările din datele de detaliu sau din modelul
de date.
Sunt şi alte probleme importante, deja rezolvate în SGBDR, dar care sunt
nerezolvate sau numai parţial rezolvate în SGBDMD cum ar fi: i) restaurarea bazei de
date; ii) conceptul de tabelă virtuală; iii) baze de date distribuite etc.
Avantajul sistemelor MOLAP este că oferă o viziune multidimensională directă
a datelor, în timp ce sistemele ROLAP sunt o “interfaţă multidimensională” la datele
relaţionale. SGBDMD cer antecalcularea tuturor agregatelor posibile, astfel sunt adesea
mai performante decât SGBDR tradiţionale, dar mai dificil de actualizat şi administrat.
Deoarece bazele de date multidimensionale folosesc acelaşi motor atât pentru stocare
cât şi pentru procesarea datelor şi acest motor are informaţii complete despre structurile
de date multidimensionale şi manipulările multidimensionale, este uşor pentru
instrument de a manipula datele multidimensionale şi de a face calcule corecte şi
complexe. Totuşi multe baze de date multidimensionale nu oferă facilitatea de
recuperare a erorilor şi alte facilităţi specifice bazelor de date relaţionale.
Câteva avantaje ale sistemelor MOLAP sunt: i) tabelele relaţionale nu sunt
potrivite pentru date multidimensionale; ii) matricile multidimensionale permit stocarea
eficientă a datelor multidimensionale; iii) limbajul SQL nu este corespunzător pentru
operaţii multidimensionale. Tabelul 5-1 prezintă o analiză comparativă între sistemele
ROLAP şi sistemele MOLAP.

Tabelul 5-1. Analiză comparativă între sistemele ROLAP şi MOLAP

Criterii
Spaţiul de disc ocupat
Performanţa la încărcarea
datelor
Viteza de calcul
Volumul datelor atomice
Posibilitatea de acces la
date de către alte aplicaţii
(integrare cu alte sisteme
existente)
Accesul la date
Dimensionalitate
MOLAP/ Baze de date ROLAP/ Baze de date relaţionale
multidimensionale
Mare, dacă agregatele sunt Posibil zero, dacă sunt folosite baze
antecalculate (explozia datelor de date existente nemodificate
derivate şi fenomenul de (depozite de date virtuale), dar poate
împrăştiere) fi mare dacă noi structuri sunt create
Moderată Scăzută
Mare Mică
Mediu la mare (Mb-Gb) Extrem de mare (Gb-Tb)
Limitată Excelentă în principiu, dar poate fi
limitată dacă este folosită o schemă
complexă
Încet şi adesea limitat, Performanţă moderată, adesea acces
citire/scriere numai la citire
Mică (modele Mare (modele multidimensionale

5-6
 Arhitectura sistemelor OLAP

multidimensionale simple, 5- complexe)

10 dimensiuni)
Modificarea dimensiunilor Bună dar baza de date trebuie Bună
să fie off-line

Volatilitatea datelor Adecvate pentru volatilitate Adecvate pentru volatilitate ridicată

scăzută

Facilităţi de administrare a Puţine Foarte puternice

SGBD-ului
Uşurinţa de a construi Moderată Aproape imposibilă
aplicaţii de către utilizatorii
finali
Arhitectura Client/server pe două sau trei Client/server pe două sau trei
niveluri, lipsa standardelor niveluri, arhitectură deschisă,
standarde
Managementul metadatelor Nu Da

Limbaj de interogare Specific fiecărui instrument SQL

Facilităţi de calcul Foarte complexe, în toate Limitate
dimensiunile
Joncţiuni Nu Da
Agregări dinamice Nu Da
Joncţiuni stea Nu Da
Partiţionarea datelor Nu Da
Cereri paralele Nu Da
Indecşi bitmap Nu Da
Algoritmi hash Da Da
Agregare în lot Da Da
Indexare Da Da
Măsuri derivate Da Da
Comparaţii ale perioadelor Da Da
de timp
Analiza valutelor Nu Da
Previziuni Da Da
Consolidări financiare Da Da
Tipul aplicaţiilor La nivel departamental La nivelul întreprinderii

În [COLL96], se face o evaluare comparativă a sistemelor ROLAP şi MOLAP.

Se utilizează un model de afaceri cu şase dimensiuni al unei firme de băuturi. Fiecare
dimensiune este compusă dintr-o ierarhie de membri. Se consideră următorul număr de
membrii pentru fiecare dimensiune:
ƒ dimensiunea Canal: 6 membri;
ƒ dimensiunea Produs: 1500 de membri;
ƒ dimensiunea Zona de desfacere: 100 membri;
ƒ dimensiunea Timp: 17 membri;
ƒ dimensiunea Scenariu: 8 membri;
ƒ dimensiunea Măsuri: 50 măsuri;
Se doreşte stabilirea profitului real al firmei pentru luna curentă şi comparaţia lui
cu bugetul alocat, apoi operaţii de drill down pe regiuni de desfacere şi familie de
produse. Sistemul ROLAP utilizează o schemă stea denormalizată. Agregările sunt
antecalculate şi stocate în tabela de fapte. Numărul potenţial de rânduri din tabela de
fapte este produsul cartezian al dimensiunilor:
canal(6)* produs(1500)* piaţa de desfacere(100) * timp(17) * scenariu(8) = 122
milioane .

5-7
 Arhitectura sistemelor OLAP

Dacă se consideră un grad de împrăştiere de 80% , numărul de rânduri este de 24

milioane (20%*122 mil). Dimensiunea unui rând este de 500 bytes şi tabela de fapte
ajunge la 13Gb. Dacă se consideră şi indecşii construiţi pe fiecare coloană (cod_canal,
cod_produs, cod_piaţă, cod_timp şi cod_scenariu) necesari pentru a se executa
joncţiunile, dimensiunea tabelei de fapte ajunge la 17 Gb (blocul de date de 4K) .
În ciuda popularităţii bazelor de date relaţionale în aplicaţiile tranzacţionale,
autorii demonstrează că modelul relaţional nu este potrivit pentru aplicaţii OLAP,
datorită numărului mare de operaţii I/O necesare pentru a executa operaţii simple de
drill down sau calcule simple.
Pentru sistemul MOLAP, datele relevante pentru analiză sunt extrase dintr-un
depozit de date relaţional sau alte surse de date şi încărcate într-o baza de date
multidimensională (un cub cu 6 dimensiuni). Implementarea acestui cub n-dimensional
este specific lui Essbase. Autorii constată că: i) încărcarea este foarte rapidă, deoarece
datele corespunzătoare oricărei combinaţii de membrii ai dimensiunilor pot fi încărcate
cu o singură operaţie de I/O, valorile sunt antecalculate, indecşii corespunzători sunt de
dimensiuni mici şi pot fi stocaţi în memorie; ii) stocarea este foarte eficientă deoarece
blocurile conţin numai date, pentru localizarea unui bloc de date este necesar un singur
index, indecşii rezidă complet în memorie; iii) calculele sunt eficiente, deoarece numai
o singură citire şi o singură scriere I/O pe bloc sunt necesare pentru a agrega toată baza
de date (tabelul 5-2).

Tabelul 5-2. Comparaţie între sisteme ROLAP şi MOLAP

ROLAP MOLAP
Spaţiul ocupat pe disc (Gb) 17 10
Încărcarea datelor(I/O) 240 1
Calculul datelor derivate (timpul I/O în ore) 237 2

Deci bazele de date multidimensionale utilizează cel mult jumătate din spaţiu,
încarcă datele şi calculează datele derivate mult mai repede decât bazele de date
relaţionale.

O serie de instrumente OLAP permit stocarea datelor multidimensionale în

fişiere, pe client (desktop OLAP). Volumul de date multidimensionale stocat pe client
este mic şi poate fi creat la cerere (utilizând facilităţi Web).

5.3. Sisteme hibride (HOLAP)

Un sistem OLAP hibrid (HOLAP) este un sistem care utilizează pentru stocarea
datelor atât baze de date relaţionale cât şi baze de date multidimensionale în scopul de a
beneficia de caracteristicile corespunzătoare şi de tehnicile de optimizare. Un sistem
HOLAP trebuie să aibă următoarele caracteristici:
ƒ transparenţa locaţiei şi a accesului: locaţia datelor utilizate trebuie să fie
ascunsă pentru utilizator. Transparenţa accesului permite utilizatorului să
acceseze datele la fel, indiferent dacă sunt stocate în BDR sau BDMD;
ƒ transparenţa fragmentării: fragmentarea datelor trebuie să fie invizibilă pentru
utilizator (cererile utilizatorului trebuie să fie descompuse în cereri parţiale în
funcţie de sistemul de stocare);

5-8
 Arhitectura sistemelor OLAP

ƒ transparenţa performanţei: trebuie furnizate tehnici de optimizare pentru ambele

sisteme MOLAP şi ROLAP;
ƒ un model de date comun utilizat atât de datele relaţionale cât şi de date
multidimensionale;
ƒ alocarea optimă în sistemele de stocare: sistemele hibride ar trebui să
beneficieze de strategiile de alocare specifice sistemelor distribuite;
ƒ realocarea automată (reorganizarea distribuţiei datelor în sistemele de stocare
MOLAP şi ROLAP).

Sunt diferite arhitecturi pentru un sistem hibrid OLAP:

ƒ integrarea sistemelor MOLAP şi ROLAP printr-o interfaţă comună. Clientul
OLAP poate fi luat în considerare într-o astfel de soluţie, întrucât oferă o
interfaţă comună pentru SGBDMD şi motoarele ROLAP. Totuşi multe din
cerinţele listate mai sus nu sunt satisfăcute. De exemplu, Seagate Holos
utilizează această arhitectură, permite tehnici de stocare relaţionale şi
multidimensionale integrate în aşa numita arhitectură OLAP compusă.
ƒ integrarea mutuală a sistemelor ROLAP şi MOLAP. Aceasta arhitectură poate fi
găsită la Arbor Essbase, care oferă acces la datele relaţionale (IBM DB2 OLAP
Server).
ƒ extensii la SGBDR sau SGBDOR prin utilizarea tehnologiei datablade (de
exemplu Informix cu opţiunea Metacube). Totuşi acesta nu este un sistem OLAP
hibrid (Metacube este un motor ROLAP, deci nu este încă implicat un
SGBDMD).

Aplicaţiile complexe şi cu grad mare de împrăştiere vor folosi o combinaţie a

acestor moduri de stocare. Datele care sunt utilizate cel mai des vor fi stocate în
memoria RAM. Datele care sunt utilizate regulat, dar nu frecvent pot fi stocate în baze
de date multidimensionale optimizate. În final, volumele mari de date detaliate sunt
stocate în baze de date relaţionale sursă. În figura 5-2 [THOM96] se prezintă strategia
de stocare optimă pentru aplicaţii de diferite mărimi şi grade de împrăştiere. Desigur
scara este aproximativă şi va depinde de hardware-ul utilizat.

Împrăştiate
0.00001%

0.00001% stocare în BDR sau

hibrid
0.001%

0.1% stocare în RAM

stocare în BDM
1%

10%

100%
Dense Volumul de date de bază (celule)

Figura 5-2. Moduri de stocare

5-9
 Arhitectura sistemelor OLAP

Pentru aplicaţii foarte împrăştiate, o soluţie hibridă este probabil cea mai bună.
Aria graficului, în care sistemele MOLAP sunt recomandate, reflectă abilitatea lor de a
stoca cel mai eficient volume medii până la mari de date. Pentru date foarte împrăştiate
sau pentru baze de date foarte mari, o strategie de stocare de tip bază de date relaţională
poate fi singura opţiune fezabilă. În general, dacă se doreşte implementarea unei
singure aplicaţii, este mai eficient din punct de vedere al costului de a selecta un
instrument mai simplu decât unul proiectat special pentru acea aplicaţie. Pentru scopuri
strategice şi aplicaţii complexe poate fi necesar de a achiziţiona un instrument complex.
În funcţie de tipul bazei de date se poate alege tehnica de indexare folosită. Cele mai
multe baze de date multidimensionale stabilesc automat tehnica de indexare.

5.4. Arhitectura sistemelor OLAP

Aplicaţiile OLAP au o varietate mare de arhitecturi, unele foarte complexe.
Multe aplicaţii OLAP stochează volume mari de date, care nu pot fi duplicate pentru
fiecare utilizator. Această cerinţă impune arhitectură client/server. În arhitectura
client/server, atât clientul cât şi unul sau mai multe procesoare ale serverului pot face
transformări multidimensionale şi calcule.
În principiu, se pot defini mai multe niveluri logice într-o arhitectură
client/server (figura 5-3). În general, într-o implementare particulară, nu toate aceste
niveluri logice pot exista ca niveluri distincte, astfel încât două sau mai multe pot fi
combinate într-un singur program.

Interfaţa 5

Se împart între client şi server depinde de

locaţia datelor
Calcule ad hoc
multidimensionale 4

Calcule făcute în avans pe server

Calcule
multidimensionale în 3
lot
Motor pentru gestiunea datelor-baze de date
relaţionale sau multidimensionale
Gestiunea datelor
2
Datele şi agregatele stocate trebuie să fie
distribuite între utilizatori

1. Fişiere de date

Figura 5-3. Niveluri logice în arhitectura client/server

Totuşi în cazuri extreme, ar putea fi niveluri separate, executate pe maşini

separate. În figura 5-3 volumele de date transmise între niveluri sunt indicate de
grosimea săgeţilor. Volumele vor varia în funcţie de aplicaţie. Figurile de la 5-4 la 5-8
ilustrează diferite tipuri de configuraţii client/server, iar tabelul 5-3 prezintă avantajele

5-10
 Arhitectura sistemelor OLAP

şi dezavantajele lor. În principiu, când un server suportă un număr mare de utilizatori, se

distribuie nu numai capacitatea lui de procesare şi memoria dar şi datele între utilizatori.
Într-o aplicaţie, ce permite utilizatorilor să modifice datele, este foarte important ca
modificările făcute de un utilizator, să fie imediat valabile la ceilalţi utilizatori (care
altfel ar lucra cu informaţii vechi). Cele mai moderne instrumente OLAP (cele
multiprocesor) oferă un mediu multiutilizator adevărat.

Server de fişiere client OLAP

Fişiere de Calcule multi Calcule multi
date Gestiunea Interfaţa
dimensionale dimensionale
datelor în lot ad-hoc

Figura 5-4. Server de fişiere-client OLAP

Server de bază de date relaţional client OLAP

Fişiere Gestiunea Calcule multi Calcule multi

Interfaţ
de date datelor dimensionale dimensionale
a
- în lot ad-hoc

Figura 5-5. Arhitectura client/server (server relaţional/client OLAP)

Server de bază de date relaţional Server de aplicaţii client OLAP

Gestiunea Calcule multi Calcule multi

Fişiere Interfaţ
dimensionale dimensionale
de date datelor a
în lot ad-hoc

Figura 5-6. Arhitectura pe trei niveluri

Server OLAP client OLAP

Calcule multi
Fişiere Gestiunea dimensionale Calcule multi
Interfaţ
de date datelor în lot dimensionale
a
ad-hoc

Figura 5-7. Arhitectura client/server (Server OLAP/client OLAP)

5-11

Server de bază de date relaţional
Fişiere Gestiunea
de date datelor
Figura 5-8. WEB OLAP pe trei niveluri
Tabelul 5-3. Tipuri de arhitecturi client/server
Descriere
Server de fişiere/client
OLAP
Numai nivelul 1 este pe un
server de fişiere, nivelurile
2-5 pe client
Server relaţional/client
OLAP
Nivelurile 1 şi 2 sunt într-un
server de baze de date
relaţional, nivelurile 3-5 pe
client
Arhitectura pe trei niveluri
Nivelurile 1 şi 2 pe un server
de baze de date relaţional,
nivelul 3 pe unul sau mai
multe servere de aplicaţii,
nivelurile 4 şi 5 pe client.
Nivelul 3 poate avea, de
asemenea, o bază de date
locală pentru stocarea
informaţiilor
multidimensionale.
Server OLAP/ client
OLAP
Nivelurile 1-3 pe un server
de bază de date
multidimensional, nivelurile
4 şi 5 pe client.
Server de aplicaţii
Calcule multi
dimensionale
în lot
Facilităţi
Uşor de implementat,
independent de protocoalele de
reţea, server ieftin. Orice server
de fişiere poate fi folosit
În funcţie de aplicaţie poate fi
gestionată securitatea pe server.
Reduce încărcarea reţelei,
deoarece datele pot fi selectate
şi procesate parţial de serverul
de bază de date, înainte de a fi
trimise la client pentru procesare
şi prezentare. Cele mai multe
procesări pot fi făcute de
SGBD-ul relaţional, care
permite o exploatare bună a
procesării paralele. Capabil de
actualizări online cu blocări mai
bune a datelor.
Distribuţie flexibilă a procesării
între serverul de bază de date şi
serverele de aplicaţii. Se reduce
traficul în reţea pentru că datele
pot fi procesate acolo unde sunt
stocate.
Funcţionalitate ridicată prin
utilizarea unui SGBD relaţional
complex şi a unui server de
aplicaţii puternic. Scalabilitate
bună în funcţie de dimensiunea
aplicaţiei.
Performanţă optimă cu trafic în
reţea minim. Costuri hardware
mici. Uşor de implementat
actualizarea multiutilizator a
datelor multidimensionale, cu
securitate multidimensională la
nivel de detaliu. Aplicaţiile
complexe sunt mai simplu de
implementat.
Arhitectura sistemelor OLAP
client WEB
Calcule multi
dimensionale Interfaţ
ad-hoc a
Dezavantaje
Nu este chiar o arhitectură
client/server. Procesarea nu se
face pe server. Poate cere clienţi
PC puternici. Poate genera trafic
excesiv în reţea, deoarece toate
datele trebuie să fie mutate la
clienţi pentru procesare.
Securitatea trebuie să fie
gestionată de aplicaţiile client.
Greu de implementat
actualizarea multiutilizator
Cere un SGBD potrivit pe
server, adaugând la costuri şi
complexitatea. Poate genera
trafic excesiv în reţea, dacă toate
procesările multidimensionale
sunt făcute pe client.
Greu de implementat şi se cere
experienţă în reţele. Adesea mai
puţin deschis decât arhitectura
cu bază de date distribuită .
Scalabilitatea în funcţie de
numărul de utilizatori poate fi
restricţionată de limitele fiecărui
server de bază de date sau de
aplicaţii .
În general o arhitectură mai
puţin deschisă. Instrumentele de
acest tip sunt adesea mai
specializate şi mai puţin
potrivite pentru utilizare
generală.
5-12

WEB OLAP pe trei
niveluri
Nivelurile 1 şi 2 sunt pe un
server relaţional, nivelurile 3
şi 4 pe serverul de aplicaţii şi
nivelul 5 pe un browser
WEB conectat prin Internet
sau Intranet.
Arhitectura sistemelor OLAP
Uşor de utilizat pentru un număr Funcţionalitate şi performanţă
mare de utilizatori, incluzând redusă. Reduce manipulările de
acei utilizatori din afara date la nivel de client.
organizaţiei. Reţea la un cost
mic. Nu cere software dedicat
pe client, reducând costurile cu
software-ul. Suportă o varietate
de platforme.
5-13