CAPITOLUL 2

MODELE DE DATE SPECIFICE DEPOZITELOR DE DATE

2.1. Modele de date multidimensionale

2.2. Opera(ii OLAP n modele de date multidimensionale
2.3. Tipuri de servere OLAP
2.4. Alte aspecte privind cubul de date

36 Capitolul 2, Modele de date speciIice depozitelor de date
2.1. MODELE DE DATE MULTIDIMENSIONALE
Depozitele de date si instrumentele OLAP sunt bazate pe modele
multidimensionale de date. Aceste modele vizualizeaz datele sub Iorma unui cub de
date (data cube).
2.1.1. De la tabele yi foi de calcul la cubul de date
Cubul de date permite modelarea si vizualizarea datelor n dimensiuni
multiple. El este deIinit prin dimensiuni si Iapte. n termeni generali, dimensiunile
exprim perspectivele n care o anumit organizatie doreste s pstreze nregistrrile
privitoare la tranzactiile desIsurate. De exemplu, Iirma ALFA SA poate crea un
depozit de date pentru vnzri care contine nregistrrile lund n considerare
urmtoarele dimensiuni: timp, articol, ramur si zon. Aceste dimensiuni permit
memorarea vnzrilor lunare pe articole, ramuri si zone. Fiecare dimensiune poate
avea un tabel asociat, numit tabel dimensiune, care descrie dimensiunile. De exemplu,
un tabel dimensiune pentru articol poate contine atributele: nume-articol, marca, tip.
Tabelele dimensiune pot Ii speciIicate de utilizatori sau de experti sau pot Ii generate
n mod automat si adaptate n Iunctie de distributia datelor.
Un model multidimensional de date este organizat n jurul unei teme centrale,
vnzri, de exemplu. Aceast tem este reprezentat de tabelul de Iapte. Faptul are o
msur numeric. El exprim msurile prin care dorim s analizm relatiile ntre
dimensiuni. De exemplu, Iaptele din depozitul de date vnzri includ: vnzri n lei
(vnzri-lei) cantitate-vndut (numrul de unitti vndute), total vnzri planiIicate.
Tabelul de Iapte contine numele Iaptelor sau msurile precum si cheile pentru Iiecare
din tabele dimensiune aIlate n legtur. Pentru clariIicri Iigurile urmtoare ne vor
pune n evident cum lucreaz schemele multidimensionale.
Desi, n mod obisnuit, ne bazm pe cuburi 3D, n depozitele de date cubul este
n-dimensional. Pentru o mai bun ntelegere a cubului de date si a modelului
multidimensional de date pornim de la un exemplu de cub de date 2D care poate Ii, n
principiu, un tabel sau o Ioaie de calcul privind vnzrile unei Iirme. n particular, este
vorba de datele despre vnzrile Iirmei ALFA SA pe articole vndute trimestrial n
municipiul Vaslui, dup cum se vede n tabelul nr.2.1.
n reprezentarea 2D, vnzrile din Vaslui sunt expuse lund n considerare
dimensiunea timp (organizat pe trimestre) si dimensiunea articol (organizat pe tipuri
de articole vndute). Valorile sunt aIisate n milioane lei. Presupunem acum c dorim
vizualizarea datelor despre vnzri cu o a treia dimensiune: zona. Cele trei dimensiuni
sunt: timp, articol si zon (V, T, N, I).
Depozite de date 37
Tabelul nr. 2.1 Viziune 2D privind vnzrile firmei ALFA SA
Milioane lei
Zona ~V
Articole
Trimestre
Service Calculatoare Telefoane Protec(ie
1 605 825 14 400
2 680 952 31 512
3 812 1023 30 501
4 927 1058 38 580

Varianta 3D este prezentat n tabelul nr. 2.2.. Datele 3D sunt reprezentate ca
serii de tabele 2D. Conceptual, putem reprezenta aceleasi date n Iormatul cub de date
3D ca n Iigura nr. 2.1.
Un cub de date este un set de date organizat si sumarizat ntr-o structur
multidimensional printr-un set de dimensiuni si msuri. Cubul de date Iurnizeaz un
mecanism Iacil pentru interogarea datelor cu un timp de rspuns Ioarte scurt. Fiecare
cub are o schem reprezentat de setul de tabele din depozitul de date. Tabelul central
este tabelul de Iapte si este sursa de msuri din cub, iar tabelele dimensiune sunt
sursele de dimensiuni.
Tabelul nr. 2.2. Viziune 3D privind vnzrile firmei ALFA SA
n milioane lei
Zona ~I Zona ~N Zona ~T Zona ~V
Articole Articole Articole Articole
T
r
i
m
e
s
t
r
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
(
i
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
(
i
e

S
e
r
v
i
c
e

C
a
l
c
u
l
a
t
o
a
r
e

T
e
l
e
f
o
a
n
e

P
r
o
t
e
c
(
i
e

s
e
r
v
i
c
e

c
a
l
c
u
l
a
t
o
a
r
e

t
e
l
e
f
o
a
n
e

P
r
o
t
e
c
(
i
e

1 854 882 89 623 1087 968 38 872 818 746 43 591 605 825 14 400
2 493 890 64 698 1130 1024 41 925 894 769 52 682 680 952 31 512
3 952 924 59 789 1034 1048 45 1002 940 795 58 728 812 1023 30 501
4 659 992 63 870 1142 1091 54 984 978 864 59 784 927 1058 38 580

Presupunem acum c dorim s vizualizm vnzrile adugnd a patra
dimensiune, cum ar Ii Iurnizorii. Vizualizarea n 4D devine interesant. Totusi putem
vedea cubul 4D ca serii de cuburi 3D ca n Iig. nr. 2.2. Dac vom continua asa putem
aIisa orice n-D date ca serii de (n-1)D cuburi.

38 Capitolul 2, Modele de date speciIice depozitelor de date


Figura nr.2.1. Cub 3D reprezentnd datele din tabelul nr.2.2




Figura nr. 2.2. Cuburi de date 4D
Cubul de date este o metaIor pentru datele stocate multidimensional. Stocarea
la nivel Iizic n mediile actuale depinde de reprezentarea logic. Este important de
retinut c acest cub de date este n-dimensional si nu se limiteaz la 3D. Tabele de mai
Depozite de date 39
sus prezint date cu diIerite grade de sintetizare. n literatura data warehouse cubul de
date este denumit ,cuboid. Stabilind setul de dimensiuni, putem construi matricea
cuboidului, Iiecare prezentnd datele cu diIerite niveluri de sintetizare sau grupare
(group by). Matricea cuboidului este reIerit tot ca un cub de date. Fig. nr. 2.3.
exprim matricea cuboidului Iormnd cuburi de date pentru dimensiunile: timp,
articole, zon, Iurnizor.


Figura nr. 2.3. Matricea cuburilor

Cuboidul situat la nivelul cel mai de jos este numit cuboid de baz. De
exemplu, n Iig. 2.3. cuboidul 4D este cuboid de baz pentru dimensiunile timp,
articol, zon si Iurnizor. Cuboidul 0D care ne arat cel mai nalt nivel de sintetizare si
este numit apex cuboid (cuboid vrI). n exemplul nostru acesta este totalul
vnzrilor, sau nsumarea vnzrilor n lei pentru toate cele 4 dimensiuni. Cuboidul
vrI este, n mod obisnuit, denumit cu all (toate).
2.1.2. Stele, fulgi de zpad yi constela(iile de fapte
Modelul de date entitate-asociatie (E-A) este curent utilizat n proiectarea
bazelor de date relationale. Schema bazei de date const ntr-un set de entitti si de
relatii ntre ele. Ca model de date acesta este corespunztor reprezentrii on-line a
40 Capitolul 2, Modele de date speciIice depozitelor de date
tranzactiilor. Totusi un depozit de date, necesit o schem concis, orientat pe
subiecte care Iaciliteaz analiza on-line a datelor.
Cel mai popular model pentru depozitele de date este modelul
multidimensional. Acesta poate Ii n Iorm de stea (star schema), de Iulg de zpad
(snow-Ilake schema) sau de constelatie (constellation schema).
2.1.2.1. Schema stea
Schema stea este cel mai comun model de date, n care depozitul de date
contine un tabel central voluminos (tabelul de Iapte) si un set de tabele nsotitoare
(tabelele dimensiune) pentru Iiecare dimensiune. Tabelul de Iapte cuprinde, Ir
redundante, cea mai mare parte a datelor. GraIul asociat semn cu o stea n care
tabelele dimensiune sunt aIisate radial n jurul tabelului de Iapte central.
Exemplul 2.1.
Un exemplu de schem stea este prezentat n Iig. nr. 2.4.. Vnzrile sunt
considerate cu 4 dimensiuni numite timp, articol, ramur si zon. Schema
cuprinde un tabel central pentru vnzri care contine chei pentru Iiecare din
cele 4 dimensiuni naintea celor dou msuri: vnzri-lei si cantitate-vndut.

Precizm c n aceast schem stea Iiecare dimensiune este reprezentat
printr-un singur tabel si Iiecare tabel contine un set de atribute. De exemplu, tabelul
zona contine atributele
Cheie-:ona, localitate, fudet, cod-potal, tara
Aceast deIinitie poate introduce o anumit redundanta. De exemplu, Negresti
si Brlad sunt ambele din judetul Vaslui. nregistrrile pentru aceste localitti vor
contine:
...Negresti, Vaslui,., Romnia
.Brlad, Vaslui, ., Romnia
Depozite de date 41


Figura nr.2.4. Schema stea a unui depozit de date pentru vnzri
2.1.2.2. Schema ,fulg de zpad (snowflake)
Modelul snowIlake este o variant a modelului stea, unde o parte din tabelele
dimensiune sunt normalizate. De aceea, datele sunt mprtite n tabele suplimentare.
Rezult o schem reprezentat ntr-un graI similar unui Iulg de zpad. DiIerenta
major ntre modelul ,Iulg de zpad si modelul stea este c tabelele dimensiune din
modelul ,Iulg de zpad pot Ii pstrate n Iorma normalizat ceea ce determin o
redundant redus. Asemenea tabele sunt usor de ntretinut si se economiseste spatiu
de stocare, deoarece un tabel dimensiune mare poate deveni enorm cnd structura
dimensional este inclus n coloane. Totusi aceast economie de spatiu este
neglijabil n comparatie cu volumul Ioarte mare de date din tabelul de Iapte. Mai
mult, structura ,Iulg de zpad` poate reduce eIicacitatea ,browsing-ului cnd mai
multe ,join-uri trebuie executate la o interogare. De aceea, schema Iulg de zpad
este mai putin rspndit Iat de schema stea n proiectarea depozitelor de date.
Exemplul 2.2.
Un exemplu de schem ,Iulg de zpad pentru vnzrile Iirmei ALFA
SA este prezentat n Iig. nr. 2.5.. Aici tabelul de Iapte vnzri este identic cu cel
42 Capitolul 2, Modele de date speciIice depozitelor de date
din schema stea din Iigura nr. 2.4. Principala diIerent ntre cele dou scheme
const n deIinirea tabelelor dimensiune. Dintr-un singur tabel dimensiune
pentru articol din schema stea, n schema ,Iulg de zpad rezult dou tabele:
unul nou pentru articol si altul pentru Iurnizor. Atributul cheieIurnizor din
Iurnizori Iace legtura cu tabelul articol. n mod similar, tabelul dimensiune
zona poate Ii normalizat n dou noi tabele: zona si localitatea. Atributul cheie-
localitate Iace legtura ntre cele dou table. Normalizarea poate continua.



Figura nr. 2.5. Schema Iulg de zpad pentru depozitul de date Vnzri
2.1.2.3. Schema constela(ia de fapte (Fact constellation)
Aplicatiile soIisticate pot solicita tabele multiple de Iapte care partajeaz
tabelele dimensiune. Acest gen de schem poate Ii vzut ca o colectie de stele si, de
aici, denumirea de schem galaxie sau constelatie de Iapte (Iact constellation).
Exemplul 2.3.
Un exemplu de schem constelatie este prezentat n Iigura nr. 2.6.
Aceast schem speciIic 2 tabele de Iapte: vnzri si shipping. DeIinitia
tabelului vnzri este la Iel cu cea din schema stea (Iig. nr. 2.4.). tabelul
shipping are 5 dimensiuni sau chei: cheiearticol, cheietimp, cheieshipper,
Depozite de date 43
expeditor, destinatar si dou msuri: cost-USD si cantitatetransp.. Schema
constelatie permite tabelelor dimensiune s Iie partajate ntre tabelele de Iapte.
De exemplu, tabelele dimensiune timp, articol si zona sunt partajate ntre cele
dou tabele de Iapte: vnzri si shipping.



Figura nr. 2.6. Schema constelatie de Iapte

Pentru depozitele de date, schema constelatie de Iapte este n mod curent
utilizat. Dup cum se stie un depozit de date colecteaz date despre subiecte care se
reIer la ntreaga organizatie cum ar Ii: clienti, produse, vnzri, active, personal etc.
Pentru data mart schemele stea si ,Iulg de zpad sunt cele mai utilizate
deoarece sunt adecvate modelrii unor subiecte restrnse. Reamintim c un data mart
este un subset al depozitului de date Iocalizat pe anumite subiecte iar domeniul la care
se reIer este departamentul sau o subdiviziune a ntreprinderii.
2.1.2.4. Exemple de definire a schemelor stea, fulg de zpad yi constela(ie de
fapte
Modelele de date multidimensionale prezentate mai sus pot Ii descrise si
printr-un limbaj de programare care dispune de comenzi adecvate. Un limbaj
relational de interogare cum este SQL poate Ii utilizat pentru a speciIica interogrile
iar un limbaj pentru mineritul datelor poate Ii utilizat pentru speciIicarea sarcinilor
data mining. Limbajul SQL bazat pe data mining (Data Mining Query Language
DMQL) contine si primitive pentru deIinirea depozitelor de date si a data marts.
44 Capitolul 2, Modele de date speciIice depozitelor de date
Un depozit de date sau un data mart poate Ii deIinit utiliznd dou primitive,
una pentru deIinirea cubului si una pentru deIinirea dimensiunilor. Comanda pentru
deIinirea cubului are urmtoarea sintax:
define cube (nume - cub) as
(lista - dimensiuni)] : (lista - valori)
Comanda pentru deIinirea dimensiunilor are sintaxa:
define dimension (nume - dimensiune) as
(atribut _sau _lista _ sudimensiune)
Exemplul 2.4.
Schema stea din exemplul 2.1 si Iigura nr. 2.4 sunt deIinite n DMQL
astIel:
Define cube vanzari-stea timp, articole, ramura, zona]: vanzari_lei
sum(vanzari_lei), cantitate_vanduta count(`)
Define dimension timp as (cheie_timp, zi, zi_din_sapt, luna,
trimestru, an)
Define dimension articol as (cheie_articol, nume_articol, categorie,
tip, tip_furnizor)
Define dimension ramura as (cheie_ramura, nume_ramura,
tip_ramura)
Define dimension zona as (cheie_zona, localitate, strada, judet,
cod_postal)

Exemplul 2.5.
Schema snowIlake din exemplul 2.2 si Iigura nr. 2.5 sunt deIinite n
DMQL astIel:
Define cube vanzari-fulg_de_nea timp, articole, ramura, zona]:
vanzari_lei sum(vanzari_lei), cantitate_vanduta count(`)
Define dimension timp as (cheie_timp, zi, zi_din_sapt, luna,
trimestru, an)
Define dimension articol as (cheie_articol, nume_articol, categorie,
tip, furnizor(cheie_furnizor, tip_furnizor))
Define dimension ramura as (cheie_ramura, nume_ramura,
tip_ramura)
Depozite de date 45
Define dimension zona as (cheie_zona, den_zona,
localitate(cheie_localitate, localitate, strada, judet,
cod_postal))

2.1.2.5. Cubul de date: fapte, dimensiuni, msuri
Un cub de date este deIinit prin msurile si dimensiunile pe care le contine. De
exemplu, un cub pentru analiza vnzrilor poate include ca msuri pret-articol-vndut,
cost-articol-vndut, cantitate-vnduta, iar ca dimensiuni zona, tip-produs, timp. Acest
cub va permite utilizatorilor s determine si s analizeze volumul vnzrilor, volumul
costurilor, cantittile vndute pe categorii variate cum ar Ii: pe zone, pe tipuri de
produse, pe trimestre etc.
Din punct de vedere multidimensional n spatiul cub de date poate Ii deIinit un
set de perechi valoare-dimensiune, de exemplu (timp ,trim1, zon ,Vaslui,
articol ,calculator. O msur ntr-un cub de date este o Iunctie numeric care poate
Ii evaluat n Iiecare punct din spatiul cubului de date. Msurile reprezint valorile
centrale care sunt analizate prin cubul de date.
Valoarea msurii este calculat pentru un punct dat prin agregarea datelor
corespondente perechii respective valoare-dimensiune diIerite pentru punctul dat.
Exemplele urmtoare pun n evidenta n mod concret principiul de lucru.
Msurile pot Ii organizate n trei categorii, bazate pe tipurile de Iunctii
agregate utilizate: distributive, algebrice, holistice.
Msuri distributive. O Iunctie de agregare este distributiv dac poate Ii
calculat n mod distributiv. Presupunem c datele sunt mprtite n n seturi.
Calcularea Iunctiei pe Iiecare partitie determin o valoare agregat. Dac rezultatul
obtinut prin aplicarea Iunctiei asupra n valori agregate este acelasi cu cel obtinut prin
aplicarea Iunctiei asupra tuturor datelor Ir partitionare, Iunctia poate Ii calculat n
manier distributiv. De exemplu, Iunctia Count ( ) poate Ii calculat pentru cubul de
date printr-o prim partitionare a cubului ntr-un set de subcuburi, calculnd count ( )
pentru Iiecare subcub si apoi nsumnd rezultatele obtinute pentru Iiecare subcub. n
acest motiv count ( ) este Iunctie agregat distributiv.
Msuri algebrice. O Iunctie agregat este algebric dac poate Ii calculat
printr-o Iunctie algebric cu M argumente (unde M este un ntreg pozitiv), Iiecare din
ele obtinut prin aplicarea unei Iunctii agregate distributive.
De exemplu, AVG() poate Ii calculat prin sum ( )/ count ( ) unde ambele
(sum ( ) si count ( ) sunt Iunctii agregate distributive. n mod similar se poate
demonstra c min ( ), max( ) si abaterea-standard sunt Iunctii algebrice agregate.
Msura este algebric dac este obtinut prin aplicarea unei Iunctii algebrice agregate.
46 Capitolul 2, Modele de date speciIice depozitelor de date
Msuri holistice. O Iunctie agregat este holistic dac aceasta nu este
limitat constant pe spatiul de stocaj cerut de deschiderea subagregrii. n acest caz nu
exist o Iunctie algebric avnd M argumente (unde M este o constant) care
caracterizeaz calculul. Exemple comune de Iunctii holistice sunt: median ( ), mode(),
rank(). O msur holistic este obtinut prin aplicarea unei Iunctii agregate de tip
holistic.
Cele mai multe aplicatii cub de date necesit calcularea eIicient a msurilor
distributive si algebrice. Exist multe tehnici eIiciente pentru aceasta. n contrast
poate Ii mai diIicil de calculat n mod eIicient msuri holistice. Exist totusi anumite
tehnici eIiciente de aproximare a calculului msurilor holistice. De exemplu, n loc de
a calcula exact median( ) exist tehnici care pot determina aproximativ valoarea
median pentru un set Ioarte mare de date, cu rezultate satisIctoare.
Exemplul 2.7.
Multe msuri din cubul de date pot Ii calculate prin operatii relationale
agregate. n Iig. nr.2.4. s-a prezentat o schem stea pentru vnzrile Iirmei
ALFA SA care contine dou msuri numite vnzri-lei si cantitate-vndut. n
exemplul 2.4. vnzrile-stea din cubul de date corespund la schema deIinit
prin comenzi DMQL. Dar cum sunt aceste comenzi interpretate n ordinea
generrii cubului de date speciIicat?

Presupunem c schema BDR pentru ALFA SA este:

time (cheie-timp, zi,zi_din_spt, trim, an)
articol (cheie-articol, nume-articol, categorie, tip, tip-furnizor)
ramur (cheie-ramur, nume-ramur, tip-ramur)
zona (cheie-zona, den-zona, localitate, strada, jude(, cod-poytal)
vnzri (cheie-timp, cheie-articol, cheie-ramur, cheie-zon, cant-
vndut, pre()

Cubul de date speciIicat n exemplul 2.4. este tradus n urmtoarele interogri
SQL care genereaz cubul vnzri-stea cerut. Aici Iunctia agregat SUM este utilizat
pentru a calcula vnzri-lei si cantitate-vndut.

SELECT v.cheie-timp, v.articol-cheie, v.ramur-cheie, v.zona-cheie,
SUM (v.cantitate-vndut, `v.pret), SUM(v.cant-vndut
FROM timp t, articol a, ramur r, zona z, vnzri v
WHERE v.cheie-timp t.cheie-timp and
Depozite de date 47
v.cheie-articol-cheiea.cheie-articol and
v.cheie-ramur r.cheie-ramur and v.cheie-zonaz.cheie-zona
GROUP BY by v.cheie-timp, v.cheie-articol,v.cheie-ramur, v.cheie-zona

Cubul creat n interogarea de mai sus este cuboid baz pentru cubul de date
vnzri-stea. El contine toate dimensiunile speciIicate n deIinitia cubului de date
unde granularitatea Iiecrei dimensiuni este cheie de jonctiune. O cheie jonctiune este
o cheie care leag o tabel de Iapte cu o tabel dimensiune. Schimbnd clauza group
by putem genera alti cuboizi pentru cubul de date vnzri-stea. De exemplu, n loc de
grupare dup v.cheie-timp putem grupa datele dup t.luna.
2.1.2.6. Ierarhii dimensionale
O dimensiune a cubului de date reprezint o ierarhie de categorii care descriu
datele din tabelele de Iapte. Fiecare dimensiune descrie un set de membri dup care
utilizatorii doresc s-si Iundamenteze analizele. Fiecare membru al dimensiunii are o
pozitie relativ Iat de altul, pozitie care determin ierarhia n cadrul dimensiunii. n
SQL Server un cub de date poate contine pn la 128 dimensiuni, Iiecare dimensiune
avnd mii sau milioane de membri si pn la 1024 de msuri.
S lum n considerare ierarhia pentru dimensiunea localitti. Orasele
reprezint valori pentru localitti: Brlad, Pascani, Neamt, Hrlu, Iasi, Suceava,
Flticeni. Fiecare oras Iace parte dintr-un judet, judetele pot Ii grupate n zone: N-E,
S-V, V etc. Ierarhia descris mai sus este prezentat n Iigura nr. 2.7.

Fig. nr. 2.7. Ierarhia pentru dimensiunea localitti
48 Capitolul 2, Modele de date speciIice depozitelor de date
Ierarhia deIinit pe o dimensiune determin aranjarea membrilor dimensiunii
ntr-o conIiguratie piramidal. Pe orizontal se plaseaz rezultatele corespunztoare
msurilor de pe acelasi nivel n ierarhia dimensiunii, iar pe vertical se plaseaz
rezultatele avnd niveluri diIerite n ierarhia dimensiunii.
Multe concepte ierarhice sunt induse implicit n schema bazei de date. De
exemplu, s presupunem c dimensiunea localitti este descris prin atributele strada,
numr, oras, judet, tar, cod postal. Aceste atribute sunt n legtur ntr-o anumit
ordine si Iormeaz o ierarhie dup cum urmeaz: 'strada oras judet tara.
Atributele din dimensiune pot Ii organizate ntr-o ordine partial Iormnd o matrice.
De exemplu, o ordine partial pentru dimensiunea timp bazat pe atributele zi,
sptmn, lun, trimestru si an este 'zilun trimestru; sptmn} an.
Conceptul ierarhic care are corespondent o ordine partial sau total printre atributele
din schema bazei de date se numeste schem ierarhic. Conceptul ierarhic ntlnit
Ioarte des n multe aplicatii poate Ii predeIinit n sistemele data mining ca un concept
ierarhic pentru timp.
2.2. OPERATII OLAP N MODELE DE DATE
MULTIDIMENSIONALE
n modelul multidimensional datele sunt organizate n multiple dimensiuni, iar
Iiecare dimensiune contine mai multe niveluri de abstractizare deIinite prin ierarhii.
Aceast organizare Iurnizeaz utilizatorilor Ilexibilitate n vizualizarea datelor din
diIerite perspective. Operatiunile OLAP asupra cubului de date oIer o Ilexibilitate
sporit pentru a materializa diIerite viziuni (views), permitnd interogri si analize
interactive. Din acest motiv OLAP Iurnizeaz un mediu utilizator prietenos pentru
analiza interactiv a datelor. n continuare vom prezenta urmtoarele operatiuni
OLAP:
Drill-up (roll-up);
Drill-down;
Dice;
Slice;
Pivot (rotate).
Drill-up. Operatiunea 'drill-up denumit, de asemenea, si 'roll-up de unii
productori, execut agregri pe cubul de date, prin escaladarea ierarhiei pentru o
dimensiune sau prin reducerea dimensiunii. Fig. 2.8 arat rezultatul operatiunii drill-
up executate pe cubul central de date parcurgnd conceptul ierarhic zona de jos n sus
(vezi Iig. nr. 2.7.). Aceast ierarhie a Iost deIinit prin ordinea total: strada
localitate judet regiune. Operatiunea Drill-up de mai sus realizeaz agregarea
Depozite de date 49
datelor parcurgnd ascendent ierarhia zona de la nivelul localitate la nivelul regiune.
Cnd drill-up-ul este executat prin reducerea dimensiuni, una sau mai multe
dimensiuni sunt sterse din cub. De exemplu, considerm cubul de date vnzri numai
cu dou dimensiuni: zona si timp. Roll-up poate Ii executat prin stergerea Iie a
dimensiunii timp, rezultnd o agregare a vnzrilor pe zone, Iie a dimensiunii zona,
rezultnd o agregare n timp.

Fig.nr.2.8. Operatiunea OLAP drill-up
Drill-down. Drill-down este opusul operatiunii drill-up. Parcurgerea ierarhiei
este de la cele mai putin detaliate niveluri la cele mai detaliate. Drill-down poate Ii
realizat sau prin parcurgerea descendent a ierarhiei pentru o dimensiune sau prin
introducerea de dimensiuni suplimentare.
50 Capitolul 2, Modele de date speciIice depozitelor de date

Fig.nr.2.9. Operatiunea OLAP drill-down

Fig.nr. 2.9 arat rezultatul unei operatii drill-down executate pe cubul central
prin parcurgerea conceptului ierarhic pentru timp deIinit astIel: zi luna trimestru
an. Drill-down merge descendent pe ierarhia timp, de la nivelul trimestru la un nivel
Depozite de date 51
mai detaliat luna. Cubul de date rezultat detaliaz vnzrile pe lun. ntruct un
drill-down adaug mai multe detalii la date, el poate Ii, de asemenea, executat prin
adugarea unei noi dimensiuni la cub. De ex.emplu, un drill-down pe cubul central
din Iig. nr. 2.9. poate determina introducerea unei dimensiuni suplimentare cum ar Ii
tip client.
Slice. Operatiunea slice execut o selectie pe o dimensiune a unui cub dat
rezultnd un subcub. Fig. 2.10. prezint o operatiune slice unde vnzrile sunt
selectate de la cubul central pentru dimensiunea timp utiliznd criteriul timp 'T1.

Fig.nr.2.10. Operatiunea OLAP slice

Dice. Operatiunea dice deIineste un subcub prin mai multe dimensiuni. Fig. nr.
2.11 prezint o operatiune dice bazat pe urmtorul criteriu de selectie (zona
'Tulcea or 'Vaslui and (trim 'T1 or 'T2) and (articol service or
'calculatoare).
52 Capitolul 2, Modele de date speciIice depozitelor de date

Fig.nr.2.11. Operatiunea OLAP dice

Pivot (rotate). Pivot (rotate) este o operatie care roteste axele de vizualizare a
datelor n ordinea cerut de alternativa prezentrii lor. Fig. 2.12. ne arat o operatie
pivot unde sunt rotite axele pentru articol si zona n 2-D. Rotatia axelor se poate
aplica si pentru reprezentri 3-D.
Depozite de date 53


Fig.nr.2.12. Operatiunea OLAP pivot

2.3. TIPURI DE SERVERE OLAP
n mod logic serverele OLAP prezint utilizatorilor date multidimensionale
din depozite de date sau data marts, Ir a sti amnunte privitoare la modul cum si
unde sunt stocate datele. Totusi arhitectura Iizic si implementarea serverelor OLAP
trebuie s ia n considerare modul de stocare a datelor.
Serverele rela(ionale OLAP (ROLAP). Acestea sunt servere intermediare
care se situeaz ntre un server relational back-end si instrumentele client Iront-end.
Ele utilizeaz un SGBD relational sau relational-extins pentru a stoca si gestiona
54 Capitolul 2, Modele de date speciIice depozitelor de date
depozitul de date si nivelul middleware OLAP. Serverele ROLAP includ optimizri
pentru Iiecare SGBD back-end, implementarea nivelului logic de navigare agregat si
instrumente aditionale pentru service. Tehnologiile ROLAP tind s aib o scalabilitate
mai mare dect tehnologiile MOLAP. De exemplu, serverul DSS al Microstrategy and
Metacube de la InIormix a adoptat abordarea ROLAP.
Servere multidimensionale OLAP (MOLAP). Aceste servere se bazeaz pe
viziuni multidimensionale ale datelor gestionate de motoare de stocare
multidimensionale. Acestea ataseaz viziunile multidimensionale direct la structurile
data cub. De exemplu, Essbase de la Arbor este un server MOLAP. Avantajul
utilizrii cubului de date este acela c permite indexarea rapid pentru precalcularea
datelor agregate. Multe servere MOLAP adpot un al doilea nivel de reprezentare a
datelor memorate pentru a gestiona seturile de date mprstiate si dense: subcuburile
dense sunt identiIicate si stocate ca structuri de masive, n timp ce subcuburile pentru
datele mprttiate Iolosesc tehnologii de compresie pentru utilizarea eIicient a
spatiului de stocare.
Serverele OLAP hibride (HOLAP). Conceptul OLAP hibrid combin
tehnologiile ROLAP si MOLAP beneIiciind de scalabilitatea sporit serverelor
ROLAP si de procesarea rapid a serverelor MOLAP. De exemplu, MicrosIt SQL
Server 7.0 OLAP Services suport un server HOLAP.
Servere SQL specializate. Datorit cererii sporite de procesri OLAP n
bazele de date relationale unele Iirme de data warehousing (eg. Redbrick de la
InIormix) implementeaz servere specializate SQL care Iurnizeaz limbaje de
interogare avansate si reprezint suportul pentru procesarea interogrilor SQL
utiliznd schemele stea si Iulg de zpad ntr-un mediu read-only.
Totusi, cum sunt stocate datele n arhitecturile ROLAP si MOLAP? Dup cum
indic si numele, ROLAP utilizeaz tabele relationale pentru memorarea datelor
pentru OLAP (On Line Analytical Processing). Tabelul de Iapte asociat cuboidului de
baz este reIerit ca tabel de Iapte de baz. Tabelul de Iapte de baz memoreaz datele
la nivelul de abstractizare indicat prin cheile de legtur n schema pentru cubul de
date. Datele agregate pot Ii, de asemenea, memorate n tabele de Iapte sumarizate. Un
tabel de Iapte sumarizat memoreaz mpreun att date din tabelul de Iapte de baz
ct si date agregate, ca n exemplul 2.8.
Exemplul 2.8.
Tabelul 2.4 contine att Iapte de baza ct si Iapte sumarizate. Schema
tabelului este ,(cod, articol,..., zi, luna, trimestru, an, vnzri-lei, unde zi, lun,
trimestru si an deIinesc date despre vnzri. Tuplurile care au codul 1001, 1002
reprezint Iapte de baz. Tuplul care au codul 5001 are un nivel de abstractizare mai
mare dect tuplurile 1001, 1002. Valoarea pentru zi este all, ceea ce nseamn c ne
Depozite de date 55
arat un nivel de agregare pentru ntreaga lun octombrie 2001 (toate zilele din luna
octombrie). Aceasta valoare special ,all este utilizat n reprezentarea subtotalurilor
n sumarizarea datelor.
Tabel nr.2.4. Exemplu de tabel pentru fapte de baz i sumarizate
Cod Articol ... zi lun Trim. an vnzri-lei
1001 TV ... 17 10 T4 2001 250.60
1002 TV ... 23 10 T4 2001 175.00
.
.
.

5001 TV ... all 10 T4 2001 45786.08

MOLAP utilizeaz structuri multidimensionale pentru OLAP. Multe sisteme
data warehouse adopt o arhitectur client-server. Memorarea relational a datelor
este ntlnit ntotdeauna pe serverul data warehouse/ data mart. Memorarea
multidimensional poate Ii ntlnit att pe serverul baza de date ct pe site-ul client.
2.4. ALTE ASPECTE PRIVIND CUBUL DE DATE
Depozitele de date contin volume imense de date. Serverele OLAP cerute de
interogrile DSS pot da rspunsuri n timp de cteva secunde. De aceea, este crucial
pentru sistemele data warehouse s dispun de tehnici de tip cub Ioarte eIiciente
pentru calcule, metode de acces si de procesare a interogrilor.
2.4.1. Calcule eficiente n cubul de date
n centrul analizelor multidimensionale de date st eIicienta calculelor de
agregare la intersectia multor seturi de dimensiuni. n termeni SQL aceste agregri
sunt reIerite prin group by.
O abordare a calculelor tip cub extinde SQL prin includerea operatorului
compute cube. Operatorul compute cube calculeaz agregri asupra tuturor
subseturilor pe dimensiunile speciIicate n operatie.
Exemplu 2.9
Presupunem c dorim crearea unui cub de date pentru vnzrile Iirmei
ALFA SA care s contin urmtoarele: articol, localitate, an si vnzri-lei.
Apoi dorim analiza datelor n interogri ca urmtoarele:

56 Capitolul 2, Modele de date speciIice depozitelor de date
Compute the sum of vanzari, grouping by articol and oras
Compue sum of vanzari, grouping by articol
Compute sum of vanzari, grouping by oras

Care este numrul total de cuboizi, sau de group by, ce pot Ii calculati pentru
acest cub de date? Lund trei atribute localitate, articol si an ca trei dimensiuni si
vnzri-lei ca msur, numrul total de cuboizi, sau de group by, care poate Ii calculat
pentru acest cub este 2
3
8. Posibilele group by sunt urmtoarele: (localitate, articol,
an), (localitate, articol), (localitate, an), (articol, an), (localitate), (articol), (an), ( )},
unde ( ) arat un group by vid. Aceste group-by Iormeaz o zon de cuboizi pe cubul
de date, prezentate n Iig. nr. 2.13. Cuboidul de baz contine toate cele 3 dimensiuni:
localitate, articol, si an.



Figura nr.2.13. Matricea de cuboizi rezultati din cubul de date 3D
Rezultatul obtinut poate Ii totalul vnzrilor pentru orice combinatie din cele
trei dimeniuni. VrIul cuboidului, sau cuboid-ul 0-D, speciIic n acest caz un group
by vid. El contine suma total pentru toate vnzrile. O interogare SQL care nu
contine group by, cum sunt cele asemntoare cu ,compute the sum oI total-vnzri
este o operatiune zero-dimensional. O interogare SQL continnd un group by cum ar
Depozite de date 57
Ii compute the sum oI vnzri, group by localitate este uni-dimensional. Un
operator cub pe n dimensiuni este echivalent cu o colectie de comenzi group by, una
pentru Iiecare subiect din cele n dimensiuni. De aceea, operatorul cub este
generalizarea n-dimensional a operatorului group by.
Bazndu-ne pe sintaxa DMQL, cubul de date din exemplul 2.9 poate Ii deIinit
astIel:
define cube vnzri articol, localitate, an]: sum (vnzri-lei)

Pentru un cub cu n dimensiuni exist un total 2
n
cuboizi, inclusiv baza
cuboidului.
Comanda
compute cube vnzri
speciIic sistemului s calculeze cuboizii pentru vnzrile agregate pentru
toate cele 8 subseturi ale setului (articol, localitate, an) inclusiv subsetul vid.
Procesarea analitic on-line poate solicita accesul la diIeriti cuboizi pentru
interogri diIerite. De aceea, este oportun s se calculeze n avans toti sau o parte din
cuboizi. Precalcularea determin un timp de rspuns Ioarte redus. Actualmente Ioarte
multe, dar nu toate, produsele OLAP includ anumite grade de precalculare pentru
agregri multidimensionale. Dezavantajul este c precalcularea solicit spatiu de
memorare, n special cnd cubul are multe dimensiuni cu multiple niveluri ierarhice.
ntrebarea este: ct de multi cuboizi sunt ntr-un cub de date n-dimensional? Dac nu
sunt asociate ierarhii pe Iiecare dimensiune, atunci numrul total de cuboizi pentru un
cub de data n-dimensiuni este, asa cum am vzut si mai sus, 2
n
. Totusi, n practic
multe dimensiuni au o anumit ierarhie. De exemplu, dimensiunea timp este n mod
curent, cu o anumit ierarhie, cum s-a exempliIicat: zi sptmn lun trimestru
an. Pentru un cub de date n-dimensional, numrul total de cuboizi care poate Ii
generat, inclusiv cuboizi generati prin parcurgeri ierarhice la Iiecare dimensiune, este:
) 1 (
10
1
+ =

=
i
i
L T
unde Li

numrul de niveluri asociate cu dimensiunea i
Aceasta Iormul este bazat pe Iaptul c un nivel de abstractizare din Iiecare
dimensiune va opera ntr-un cuboid. De exemplu, dac un cub are 10 dimensiuni si
Iiecare dimensiune 4 niveluri, numrul total de cuboizi care poate Ii generat este 5
10

9,8.10
6

10
10
1
10
1
5 ) 1 4 ( ) 1 ( = + = + =

= = i
i
i
L T
Constatm c precalculul si materializarea tuturor cuboizilor este nerealist.
De aceea, se aplic un precalcul partial prin selectarea cuboizilor.
58 Capitolul 2, Modele de date speciIice depozitelor de date
2.4.2. Metadate
Metadele sunt date despre date. Cnd se utilizeaz ntr-un depozit de date,
metadatele sunt date care deIinesc obiectele depozitului. Metadatele sunt create pentru
numele de date si deIinitiile din depozit. Metadatele aditionale suunt create pentru a
asocia intervale de timp la datele extrase si alte cmpuri care vor Ii adugate prin
curtirea datelor sau prin procesele de integrare.
Un depozit de metodate trebuie s contin:
o descriere a structurii datelor din depozit care include schema
depozitului, dimensiunile, ierarhiile, deIinitiile datelor derivate;
metadatele operationale care includ date privind evolutia n timp
(istoricul datelor migrate si secventa de transIormare aplicat asupra
lor), circulatia datelor (active, arhivate sau sterse) si inIormatii de
monitorizare (statistici privind utilizarea depozitului de date, rapoarte
de erori, linii de antet etc.
Algoritmi utilizati pentru sumarizare, care includ msura si
dimensiunea algoritmilor deIiniti, date despre granularitate, partitii, arii
de subiecte, agregri, sumarizri, rapoarte si Iiltre predeIinite;
Maprile de la mediul operational la depozitul de date, care includ
bazele de date surs si continutul lor, descrierile gateways,
partitionarea datelor, extragerea datelor, curtirea datelor, regulile de
ntretinere si securitate a datelor;
Date relative la perIormantele sistemului care include indici si proIiluri
ce mbunttesc accesul la date si perIormantele de cutare;
Metadate economice (Business metadata) care includ termeni
economici si deIinitii.
Un depozit de date contine diIerite niveluri de sumarizare din care metadata
este un tip. Alte tipuri includ date detaliate n mod curent (care sunt tot timpul pe
disc), date detaliate anterior (care sunt n mod uzual stocate pe un suport tertiar) date
usor sumarizate si date puternic sumarizate (care pot sau nu pot exista din punct de
vedere Iizic). Metadatele joac un rol Ioarte diIerit Iat de alte date din depozitul de
date si sunt importante din mai multe ratiuni. De exemplu, metdatele sunt utilizate
pentru a directiona help-ul ntr-un DSS localiznd continutul unui depozit de date, ca
ghid n maparea datelor cnd se Iace transIormarea de la mediul operational la mediul
data warehouse, ca ghid pentru algoritmi utilizati la sumarizare etc.