Você está na página 1de 13

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 MOLAP/ Baze de date ROLAP/ Baze de date relaţionale
multidimensionale
Spaţiul de disc ocupat 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
Performanţa la încărcarea Moderată Scăzută
datelor
Viteza de calcul Mare Mică
Volumul datelor atomice Mediu la mare (Mb-Gb) Extrem de mare (Gb-Tb)
Posibilitatea de acces la Limitată Excelentă în principiu, dar poate fi
date de către alte aplicaţii limitată dacă este folosită o schemă
(integrare cu alte sisteme complexă
existente)
Accesul la date Încet şi adesea limitat, Performanţă moderată, adesea acces
citire/scriere numai la citire
Dimensionalitate 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
Arhitectura sistemelor OLAP

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

Calcule multi Calcule multi


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

Figura 5-8. WEB OLAP pe trei niveluri

Tabelul 5-3. Tipuri de arhitecturi client/server


Descriere Facilităţi Dezavantaje
Server de fişiere/client Uşor de implementat, Nu este chiar o arhitectură
OLAP independent de protocoalele de client/server. Procesarea nu se
Numai nivelul 1 este pe un reţea, server ieftin. Orice server face pe server. Poate cere clienţi
server de fişiere, nivelurile de fişiere poate fi folosit PC puternici. Poate genera trafic
2-5 pe client 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
Server relaţional/client În funcţie de aplicaţie poate fi Cere un SGBD potrivit pe
OLAP gestionată securitatea pe server. server, adaugând la costuri şi
Nivelurile 1 şi 2 sunt într-un Reduce încărcarea reţelei, complexitatea. Poate genera
server de baze de date deoarece datele pot fi selectate trafic excesiv în reţea, dacă toate
relaţional, nivelurile 3-5 pe şi procesate parţial de serverul procesările multidimensionale
client de bază de date, înainte de a fi sunt făcute pe client.
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.
Arhitectura pe trei niveluri Distribuţie flexibilă a procesării Greu de implementat şi se cere
Nivelurile 1 şi 2 pe un server între serverul de bază de date şi experienţă în reţele. Adesea mai
de baze de date relaţional, serverele de aplicaţii. Se reduce puţin deschis decât arhitectura
nivelul 3 pe unul sau mai traficul în reţea pentru că datele cu bază de date distribuită .
multe servere de aplicaţii, pot fi procesate acolo unde sunt Scalabilitatea în funcţie de
nivelurile 4 şi 5 pe client. stocate. numărul de utilizatori poate fi
Nivelul 3 poate avea, de Funcţionalitate ridicată prin restricţionată de limitele fiecărui
asemenea, o bază de date utilizarea unui SGBD relaţional server de bază de date sau de
locală pentru stocarea complex şi a unui server de aplicaţii .
informaţiilor aplicaţii puternic. Scalabilitate
multidimensionale. bună în funcţie de dimensiunea
aplicaţiei.
Server OLAP/ client Performanţă optimă cu trafic în În general o arhitectură mai
OLAP reţea minim. Costuri hardware puţin deschisă. Instrumentele de
Nivelurile 1-3 pe un server mici. Uşor de implementat acest tip sunt adesea mai
de bază de date actualizarea multiutilizator a specializate şi mai puţin
multidimensional, nivelurile datelor multidimensionale, cu potrivite pentru utilizare
4 şi 5 pe client. securitate multidimensională la generală.
nivel de detaliu. Aplicaţiile
complexe sunt mai simplu de
implementat.

5-12
Arhitectura sistemelor OLAP

WEB OLAP pe trei Uşor de utilizat pentru un număr Funcţionalitate şi performanţă


niveluri mare de utilizatori, incluzând redusă. Reduce manipulările de
Nivelurile 1 şi 2 sunt pe un acei utilizatori din afara date la nivel de client.
server relaţional, nivelurile 3 organizaţiei. Reţea la un cost
şi 4 pe serverul de aplicaţii şi mic. Nu cere software dedicat
nivelul 5 pe un browser pe client, reducând costurile cu
WEB conectat prin Internet software-ul. Suportă o varietate
sau Intranet. de platforme.

5-13