Sabu Gheorghe Muntean Mihaela Avram Vasile

Drdal Marian Bologa Ramona Bologa Rzvan

BAZE DE DATE, Editura MATRIX ROM, Bucureti 2008




Capitolul 11
Depozite de date


11.1. Prezentare general

11.1.1. Noiuni de baz

nc de la nceputurile erei informatice, managerii au neles c datele stocate de
sistemele informatice operaionale reprezint o min de aur informaional care se cere
exploatat. Eforturile n aceast direcie au nscut generaii de acronime: MIS (Management
Information Systems - sisteme de management al informaiei), DSS (Decision Support
Systems - sisteme suport de decizie), EIS (Executive Information Systems - sisteme
informatice executive), MSS (Management Support Systems - sisteme suport pentru
management).
Depozitele de date, sub un nume sau altul, au aprut n gndirea comunitaii
informatice la sfritul deceniului trecut. Acestea reprezint o cerin acut a organizaiilor
moderne (fie ele ntreprinderi, bnci, administraie etc.) i, totodat, o realitate tehnologic
pus n practic din ce n ce mai frecvent. Ultimele cifre estimate de IDC referitoare la piaa
depozitelor de date indic faptul c aceasta va nregistra o cretere de 9% pna n 2009,
atingnd o valoare de 14.5 miliarde de dolari, unde momentan volumul su este de
aproximativ 10 miliarde de dolari. De asemenea, Gartner Group estimeaz o cretere dubl pe
piaa depozitelor de date n raport cu creterea global a pieei de IT.
Depozitele de date sunt produsul mediului economic i al tehnologiilor avansate. Din
perspectiv economic, globalizarea comerului, acutizarea dramatic a concurenei,
reducerea spectaculoas a ciclurilor de via al produselor datorit dinamicii tehnologiei i
impunerea unor cerine calitative extrem de ridicate au evideniat i mai mult valoarea
strategic a informaiei. Manipularea operativ a informaiei a impus la rndul ei dou modele
manageriale, mai suple i mai adecvate din punct de vedere funcional. Nevoia de a rspunde
n timp optim cerinelor pieei a condus la descentralizare i la reducerea numrului nivelelor
decizionale, consacrnd aa-numitele "ierarhii plate", care se bazeaz pe delegarea puterii
decizionale operative ctre ealonul managerial secund. Practic, clasicul funcionar este pe
cale de a fi nlocuit de "lucrtorul cu informaii". Att la nivelul conducerii strategice, ct i la
nivelul managementului operativ, nevoia de informaie pur, corect i semnificativ a
devenit vital.
Din perspectiv tehnologic, ultimii ani au adus puterea de calcul la preuri accesibile.
Servere paralele bazate pe microprocesoare ieftine rivalizeaz ca putere cu
supercalculatoarele, la o fraciune din preul acestora. Sistemele de baze de date pot exploata
la maximum arhitecturile hardware paralele, iar evoluiile spre sisteme deschise permit o
conectivitate aproape total la orice fel de surse de date i interoperabilitate ntre diverse
Depozite de date

platforme software/hardware. Mediile de stocare magnetice i optice admit volume de ordinul
giga i chiar terrabytes.
Microcalculatoarele au ajuns i ele la maturitate. Puterea lor este acum suficient
pentru funciile de analiz i prezentare care le sunt rezervate, iar interfeele grafice intuitive
le fac accesibile utilizatorilor neprofesioniti, n spea managerilor.
Sistemele informatice operaionale exist, datele pot fi accesate oriunde, nevoia de
informaie este acut, puterea de calcul i de stocare este ieftin, instrumentele software sunt
accesibile, toate acestea crend un cadru favorabil implementrii depozitelor de date.
Rolul unui depozit de date este de a oferi o imagine coerent asupra datelor referitoare
la activitatea unei organizaii i a contextului n care aceasta acioneaz. Spre deosebire de
coleciile de date utilizate de sistemul operational - orientate spre optimizarea i sigurana
procesrii datelor - datele dintr-un depozit de date sunt organizate ntr-o manier care s
permit analizarea lor, deci extragerea semnificaiei economice pe care o poart. Depozitul de
date separ spaiul de lucru al analizei de spaiul de lucru al tranzaciilor i ofer posibilitatea
organizaiilor s consolideze datele din mai multe surse. Sursa principal sunt sistemele
operaionale, iar ca surse secundare pot fi att surse interne, ct i surse externe cum ar fi
bazele de date publice: date statistice furnizate de instituii specializate, date de prognoz
economic furnizate de instituii orientate pe studiul pietei, date obinute n urma unor sondaje
de opinie etc.
William Inmon, vicepreedintele firmei Prism Solutions, este considerat printele
necontestat al noiunii depozit de date" n nelesul ei curent, deinnd de altfel trademark-ul
termenului data warehouse. Viziunea sa despre depozitele de date se concentreaz asupra
rolului acestora de baz informaional a deciziei manageriale, pstrnd astfel un nivel nalt
de generalitate i permind unor multiple implementri s intre n sfera acestei noiuni.

Definiia lui Inmon este extrem de concis: Un depozit de date este o colecie de date
orientate pe subiecte, integrate, istorice i nevolatile, fiind destinat fundamentrii deciziei
manageriale.

n continuare vor fi prezentate caracteristicile evideniate de aceast definiie.

- Orientare pe subiecte
Datele operaionale sunt orientate pe aplicaii, n sensul c organizarea lor este
optimizat pentru a servi procesului tranzacional, dinamicii sistemului. n contrast, depozitul
de date este orientat pe subiectele importante ale procesului economic, cum ar fi: clieni,
furnizori, produse, activiti. Aceste subiecte necesit informaii din diferite surse pentru a
furniza o imagine complet a domeniului. n loc de a se concentra pe procesarea operaiilor i
tranzaciilor zilnice dintr-o organizaie, un depozit de date se focalizeaz pe modelarea i
analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele de date ofer, n mod
tipic, o viziune simpl i concis, relativ la un subiect specific, excluznd datele care nu sunt
utile n procesul de sprijinire a deciziei.
Un exemplu simplu poate fi edificator: o comand lansat de un client va fi
consemnat de sistemul operaional printr-un set de nregistrri care vor conine informaii
despre client, informaii despre produsele sau serviciile comandate, informaii despre modul
de transport i modul de plat etc. Atenia sistemului tranzacional este orientat ctre
consistena cheilor, astfel nct operaia s pstreze consisten. Multe dintre datele eseniale
din perspectiv operaional (numrul comenzii, poziiile liniilor n cadrul comenzii etc.) sunt
complet lipsite de relevan din perspectiv informaional.
O consecin important a acestei orientri este redundana datelor. Dac n sistemul
operaional redundana este controlat (prin procesul de normalizare) pentru a evita anomaliile
296
Capitol 11
de actualizare, n depozitul de date redundana este creat n mod intenionat (prin
denormalizare i sumarizare) pentru a permite un acces tematic mai facil.
- Integrare
Este cel mai important aspect al depozitului de date i, n cele din urm, raiunea
pentru care acesta este creat. Datele sunt adunate aici pentru a rspunde nevoilor
informaionale ale ntregii organizaii, asigurnd faptul c rapoartele generate pentru diverse
compartimente vor conine aceleai rezultate. Sistemul operaional este de cele mai multe ori
format din subsisteme semi-independente, create la momente diferite, de echipe diferite, n
maniere diferite, iar rezultatul, dei funcional, este imposibil de folosit pentru analiz.
Integrarea unor multiple surse heterogene: baze de date relaionale, fiiere, nregistrri
privind tranzaciile on-line, impune implementarea unor tehnici de curire a datelor (data
cleaning) i de integrare, pentru a se asigura consistenta datelor din depozit.

- Caracterul istoric
Sistemul operaional al unei organizaii tinde mereu s reflecte realitatea curent.
Astfel, el se afl ntr-o continu evoluie, iar datele pe care le conine sunt relevante doar
pentru momentul n care sunt accesate. Orizontul de timp pe care l acoper este de regul de
60 pn la 90 de zile, deoarece dup acest interval tranzaciile efectuate sunt arhivate, fiind
considerate deja de domeniul istoriei, deci neinteresante din perspectiv operativ.
Pentru nevoile analizei economice, dimpotriv, informaiile cu caracter istoric sunt
eseniale, deoarece ele pun n eviden tendine care reprezint fundamentul unei prognoze
corecte. Depozitul de date se constituie ntr-un istoric al sistemului operational, constituit
dintr-o serie de "instantanee", imagini la diverse momente n timp. Orizontul de timp pe care
l acoper depozitul de date este de cel puin cinci ani, ajungnd uneori la zece ani, n functie
de dinamica evoluiei pieei i, deci, de relevana datelor cu caracter istoric pentru nevoile
analizei.
Din punct de vedere tehnic, acesta implic faptul c orice nregistrare din depozitul de
date poate fi plasat n timp. Orice cheie de acces cuprinde i o variabil temporal.

- Persistena datelor
Esena aplicaiilor operaionale este actualizarea continu a coleciilor de date,
actualizare realizat n general pe baza tranzactional. Orice tranzactie procesat implica
adugarea unor noi nregistrri, modificarea sau eventual tergerea altora etc. Cu totul altfel
stau lucrurile n cazul depozitului de date, unde o astfel de dinamic lipsete. n mod uzual
sunt solicitate doar dou operaiuni n accesarea datelor: ncrcarea iniial a datelor i accesul
la date pentru citire. Practic singura actualizare care se realizeaz este adugarea periodic a
unor date extrase din sistemele operative.
Din punctul de vedere al proiectrii, aceast diferen este extrem de important. n
sistemul operaional, o tranzacie trebuie s duc colecia de date dintr-o stare consistent ntr-
o alt stare consistent, iar aceasta implic mecanisme extrem de complexe de meninere a
integritii datelor, mai ales n situaia sistemelor intens concureniale: mecanisme de
jurnalizare, mecanisme de salvare/restaurare/refacere, mecanisme de detectare a blocrilor
circulare (dead lock) etc. n cazul depozitelor de date, aceste mecanisme sunt inutile, astfel c
gradul de libertate ctigat poate fi utilizat pentru optimizarea accesului la date prin
denormalizare, sumarizare, statistici ale accesrii datelor i reorgarnizare dinamic a indexrii
etc.

11.1.2. Obiectivele unui depozit de date

297
Depozite de date

Primele domenii care au adoptat tehnologia depozitelor de date au fost
telecomunicaiile i comerul cu amnuntul. Ulterior, depozitele de date au ptruns i n alte
domenii cum ar fi industria farmaceutic, sistemul sanitar, asigurri, transporturi. Studiile
statistice arat c telecomunicaiile i sistemul bancar se menin n top, ntruct aloc cel puin
15% din bugetul IT pentru proiecte referitoare la depozite de date.

Cteva dintre obiectivele urmrite n construirea unui depozit de date sunt:
- Rularea unor activiti de server/disc asociate cu interogarea i raportarea pe
servere/discuri care nu sunt utilizate de sistemele de procesare a tranzaciilor.
Firmele vor ca sistemele s proceseze o tranzacie ntr-un timp rezonabil. Rapoartele i
interogrile, utiliznd n mod variabil resursele fizice (server/disc), ncetinesc
procesarea tranzaciilor, i fac ca serverele/discurile s fie dificil de organizat. De
aceea, firmele pot considera c implementarea unei arhitecturi data warehouse care
utilizeaz servere/discuri separate este un mod mai ieftin sau/i mai organizat de a
obine un timp de procesare a tranzaciilor acceptabil. Procesele decizionale i
procesele operaionale sunt total divergente arhitectural.
- Utilizarea unor modele de date i/sau tehnologii server care accelereaz interogarea
i raportarea i care nu sunt adecvate pentru procesarea tranzaciilor. Exist modele
de date care accelereaz interogarea i raportarea (de exemplu, schema stea) i care nu
sunt adecvate pentru procesarea tranzaciilor, pentru c tehnica de modelare o va
ncetini i complica. De asemenea, exist i tehnologii server care pot mbuntii
viteza pentru interogare i raportare, dar ncetinesc procesarea tranzactional
(indexarea de tip bitmap) i anumite tehnologii care acioneaz n sens invers
(tehnologii pentru restaurarea datelor).
- Furnizarea unui acces sporit la date pentru utilizatori. Depozitul de date furnizeaz
accesul la datele integrate ale ntreprinderii, anterior blocat prin ci neprietenoase.
Utilizatorii pot acum s stabileasca, cu un minim de efort, o conexiune garantat la
depozitul de date prin intermediul unui calculator.
- Oferirea unui depozit de date "curat", furniznd o singur versiune a realitii.
Depozitul de date ofer posibilitatea de a curaa datele fr modificarea sistemului de
procesare a tranzaciilor. Datele din depozitele de date sunt consistente i au calitatea
asigurat nainte de a fi puse la dispoziia utilizatorilor. n msura n care se utilizeaz
o surs comun de date, depozitele de date pun capt dezbaterilor privind veridicitatea
datelor utilizate pentru realizarea rapoartelor.
- Facilitarea interogrii i raportrii pe date provenite din mai multe sisteme
tranzacionale i/sau din surse externe de date. Mult vreme firmele care aveau nevoie
de rapoarte bazate pe date provenite din mai multe sisteme rezolvau aceast problem
prin extragerea, sortarea i combinarea datelor, n final lansnd n execuie rapoarte
asupra lor. n multe cazuri aceast soluie este una adecvat. Dar, dac o companie are
multe date care trebuiesc sortate/combinate frecvent, dac datele din sistemele
tranzacionale trebuie "curate" atunci soluia adecvat este depozitul de date.
- Acces combinat sintez/detaliu la date. Rapoartele dinamice i instrumentele de
integrare OLAP permit utilizatorilor s vizualizeze informaiile din depozitul de date
sub diferite unghiuri i la diferite niveluri de detaliere. Aceste disponibiliti oferite de
depozitele de date reduc timpul i efortul necesar pentru colectarea, formatarea i
filtrarea informaiilor plecnd de la date.
- nregistrarea cu acuratee a trecutului. Datele istorice sunt deseori eliminate din
sistemul de procesare a tranzaciilor pentru a optimiza i controla timpul de rspuns al
sistemului. Pentru interogare i raportare, aceste date i datele curente pot fi stocate n
298
Capitol 11
depozitul de date n cadrul cruia timpul de rspuns ateptat se afl la un nivel mai
ridicat.
- mpiedicarea persoanelor care au nevoie de acces doar pentru raportare i interogare
s aib acces la bazele de date ale sistemului de procesare a tranzaciilor. Acest
punct privete securitatea. De exemplu depozitul de date poate fi un punct de interes
pentru firmele care doresc s permit raportarea i interogarea prin intermediul
Internetulul.

Un proiect data warehouse reprezint ns o investiie riscant i scump. Costurile
tipice pentru dezvoltarea unui depozit de date ntr-un interval de 3-6 luni se situeaz ntre 0,8
i 2 milioane USD. Ponderea echipamentelor se situeaz ntre 1/2 i 2/3 din costul total al
proiectului. O soluie pentru firmele mici i mijlocii este recurgerea la data marts pentru care
costurile se situeaz sub 100.000 USD ntr-un interval adesea sub 90 de zile. Uneori
investiiile n depozitele de date nu se finalizeaz cu succes. Motivaiile cele mai des ntlnite
pentru eecul unor depozite de date includ: susinerea insuficient din partea conducerii
organizaiei, insuficiena fondurilor i politicile organizaionale defectuoase.


11.2. Arhitectura depozitelor de date

Depozitul de date conine date care sunt extrase dintr-unul sau mai multe sisteme,
numite surse de date. Aceasta include o gam larg de sisteme incluznd baze de date
relaionale i baze de date orientate obiect, dar i baze de date prerelaionale i sisteme
motenite (figura 11.1).
Arhitectura unui depozit de date conine urmtoarele componente care nu sunt toate
obligatorii. Primele dou componente opereaz pe sursa de date.
- Componenta Filtru verific acurateea datelor naintea inserrii lor n depozit. Filtrele
pot elimina datele care sunt clar incorecte bazndu-se pe restriciile de integritate i
regulile privitoare la o singur surs de date. Ele pot, de asemenea, scoate la iveal i
inconsistena datelor extrase din surse multiple. n acest fel, filtrul realizeaz tergerea
datelor, lucru esenial pentru a asigura un nivel satisfctor al calitii. Este important
s parcurgem atent construcia depozitului, verificnd calitatea datelor pe pri mici
nainte de a realiza ntreaga ncrcare.
- Componenta Export este folosit pentru extragerea datelor din sursele de date.
Procesul de extragere este incrementat normal, componenta export construiete
colecia tuturor modificrilor pe sursa de date, care sunt apoi importate de depozitul de
date.
- ncrctorul este responsabil pentru ncrcarea iniial a datelor n depozitul de date.
Aceast component pregatete datele pentru utilizarea operaional, ocupndu-se att
de ordonarea i agregarea operaiilor ct i de construirea structurilor de date n
depozitul de date. n mod standardizat, operaiile de ncrcare sunt realizate pe grupe,
caz n care depozitele de date utilizeaz paralelismul. Acest modul se ocup i cu
fragmentarea iniial a datelor. n unele aplicaii, caracterizate de o cantitate limitat
de date, acest model este invocat pentru ncrcarea ntregului coninut al depozitului
de date dup fiecare schimbare a surselor de date. Cel mai adesea, datele din depozitul
de date sunt rennoite automat de componenta Refresh care va fi discutat n
continuare.
- Componenta Refresh nnoiete coninutul depozitului de date, propagnd automat
noutile aprute n sursele de date. Modificrile din sursele de date sunt realizate cu
ajutorul a dou tehnici: transportarea datelor i transportarea tranzaciilor.
299
Depozite de date

Prima tehnic utilizeaz triggeri pe sursa de date, care, invizibili de ctre
aplicaii, nregistreaz tergerile, inserrile i modificrile n fiiere.
Modificrile sunt adesea tratate ca perechi de inserri i tergeri.
A doua tehnic folosete consemnarea tranzaciilor pentru a construi fiierele
de modificri. n ambele cazuri, fiierele de modificri sunt transmise
depozitului de date i apoi folosite pentru a nnoi depozitele de date; vechile
valori sunt marcate de obicei ca date istorice, dar nu sunt terse.
- Componenta Acces la date este responsabil pentru ndeplinirea operaiilor de analiza
a datelor. n depozitele de date acest modul compune n mod eficient ntrebri
relaionale complexe, cu compuneri, ordonri i agregri complexe. Compune de
asemenea i operaii noi specifice dicionarelor de date, cum ar fi mpachetri,
despachetri i agregarea total a datelor. Acest modul este n strns legtur cu
sistemele client care ofer interfee prietenoase utilizatorilor, compatibile pentru
analize complexe ale datelor.

Export
Data mining
Accesul la date
Refresh
Incrctor

















Fig. 11.1 Arhitectura depozitului de date

- Componenta Data mining permite executarea de explorri complexe ale informaiilor
ascunse n date, utiliznd tehnici i algoritmi specifici de data mining.
- Componenta de Export al datelor e folosit pentru exportarea datelor prezente ntr-un
depozit spre alte depozite, crendu-se astfel o arhitectur ierarhic. n plus,
dicionarele de date sunt adesea dotate cu module care suport formatul i organizarea
lor:
Un instrument CASE care poate suporta formatul depozitelor de date.
Un dicionar de date descrie coninutul depozitelor de date este utilizat pentru
a nelege ce fel de analiz a datelor trebuie realizat.
Elementele prezentate legate de arhitectura depozitelor de date trebuie completate de
cteva consideraii privind calitatea datelor.
Export n
Filtru n
Export 2
Filtru 2
Export 1
Filtru 1
Sursa de
date 1



Sursa de
date 2
Sursa de
date n
300
Capitol 11

Calitatea datelor este un element esenial pentru succesul depozitelor de date. Dac
datele stocate conin erori, rezultatul analizei va produce rezultate eronate, i utilizarea
depozitelor de date ar putea fi la un moment dat contraproductiv. Din pcate, exist muli
factori care distrug calitatea datelor.
Cnd sursa de date nu are restricii de integritate, de exemplu pentru c este condus
de tehnologii pre-relaionale, cantitatea datelor murdare este foarte mare. Estimrile tipice
indic faptul c datele eronate din aplicaiile comerciale fluctueaz ntre 5 i 50% din totalul
datelor.
Pentru a obine niveluri nalte de calitate trebuie utilizate filtre reprezentate printr-un
numr mare de restricii de integritate, care corecteaz sau terg datele care sunt
necorespunztoare restriciilor. Mai general, calitatea datelor este mbuntit prin observarea
cu grij a procesului de producie al datelor i asigurarea c verificarea i corectarea datelor
este realizat chiar n timpul producerii datelor .


11.3. Obiectele depozitului de date

ntr-un depozit de date se ntlnesc mai multe tipuri obiecte care prezint o importan
deosebit n analiz:
- Tabelele de fapte sunt tabelele centrale. Acestea conin faptele i cheile externe
ctre tabelele de dimensiuni. Faptele sunt de obicei date numerice care pot fi totalizate
i analizate pe diferite nivele.
- Dimensiunile sunt nite nite structuri compuse din una sau mai multe ierarhii care
structureaz datele. Tabelele secundare se numesc tabele dimensiuni, i sunt mult mai
mici dect tabelele de fapte. Fiecare tabel dimensiune are cte o cheie. Cmpurile
dintr-o tabel dimensiune sunt de obicei textuale i sunt folosite ca surs pentru
restricii i pentru rndurile din rapoarte. Datele sunt de obicei colectate la nivelul cel
mai de jos i mai detaliat i sunt agregate pe nivelele superioare pentru analiz.
- Ierarhiile sunt structuri logice utilizate pentru ordonarea nivelelor de reprezentare a
datelor. Sunt utilizate i pentru definirea cailor de navigare n interiorul datelor.
Nivelele ierarhice sunt utilizate de instrumentele de analiz OLAP permind
detalierea gradual a datelor.
301
Depozite de date




















Fig. 11.2. Ierarhii i nivele

- Nivelele reprezint poziii n cadrul ierarhiilor. De exemplu, dimensiunea Timp
poate avea trei nivele de ierarhizare: an, trimestru i luna. Nivelele se structureaz n
funcie de ierarhie de la general la specific, rdcina fiind reprezentat de nivelul
superior, cel mai general al ierarhiei. Relaiile ntre diferite nivele sunt relaii de tipul
printe-copil. Se pot defini ierarhii n care datele fiecrui nivel sunt agregate la un
nivel superior sau se pot sri anumite nivele care sunt independente (figura 11.2).
- Atribute dimensiunile sunt concretizate prin intermediul atributelor care reprezint
calificative specifice. Orice atribut se asociaz unei singure dimensiuni, iar o
dimensiune se poate exprima prin mai multe atribute. Cu ct aceste atribute sunt mai
descriptive, cu att depozitele de date vor fi mai performante.
- Metrici (msuri) n analiza depozitelor de date se utilizeaz anumite variabile sau
metrici. Aceste corespund faptelor din tabelele de fapte i sunt de regul de natur
numeric. Exemple tipice: vnzri, costuri, stocuri. Aceste variabile au sens numai n
contextul unor anumite dimensiuni.


11.4. Scheme pentru depozitele de date

Construcia unui dicionar de date, care descrie toate datele prezente n companie, este
un scop ambiios adesea greu de obinut. Din acest motiv, construirea unui depozit de date
trebuie s se concentreze n mod separat pe subseturi de date ale companiei (cunoscute ca
date de departament), pentru care scopul de analiz este clar. Fiecare schem simplificat a
datelor de departament preia numele de Data Mart. Fiecare colecie de date este realizat n
conformitate cu o structur simpl, numit schem multidimensional, termen care implic
prezena unor multiple dimensiuni de analiz. Exist mai multe scheme de structurare a unui
depozit de date: schema stea, schema fulg de zpad i schema constelaie de fapte.

Familie de produse
Categorie
Subcategorie
Marca
Produs
Nivele ierarhice pentru
dimensiunea produs
302
Capitol 11
11.4.1. Schema stea

Schema stea este cel mai simplu model de structurare a unui depozit de date, model
ilustrat n figura de mai jos cu ajutorul modelului entitate-asociere. O entitate central
reprezint faptele pe care este focalizat analiza. Diferite entiti aranjate sub form de raze n
jurul acesteia reprezint dimensiunile analizei. Mai multe relaii unu la muli conecteaz
fiecare element din domeniul faptelor la exact un element al fiecrei dimensiuni. Schema din
figura de mai jos reprezint managementul unei reele de magazine. Entitatea din centrul
stelei reprezint vnzrile care sunt factori de interes; dimensiunile sunt reprezentate de
produsele vndute, magazinele, promoiile i timpul fiecrei vnzri (figura 11.3.)
Figura 11.4. reprezint organizarea plilor unei companii de asigurri. Entitatea din
centrul stelei reprezint plile ctre cei trebuie onorai de ctre companie; dimensiunile
reprezint poliele de asigurare, clienii, timpul i tipul problemelor care au cauzat aceast
revendicare.
Schema din Figura 11.5. reprezint organizarea terapiilor ntr-un grup de spitale.
Entitatea din centrul stelei reprezint terapiile; dimensiunile reprezint mbolnvirile,
pacienii, doctorii n cauz i spitalele n care sunt acceptai pacienii.

Vanzare
Produs
Promotie
Timp
Supermarket (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)


Fig. 11.3. Colecia de date pentru un lan de supermarketuri


303
Depozite de date

Plata
Polita
Problema
Timp
Client (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)


Fig. 11.4. Colecia de date pentru o companie de asigurri

Aa cum este prezentat n cele trei colecii de date, principala caracteristic a schemei
stea este folosirea unei structuri regulate independent de problema n cauz. Desigur,
numrul dimensiunilor poate fi diferit, dar cel puin dou dimensiuni sunt necesare (deoarece,
n caz contrar, modelul se descompune ntr-o simpl ierarhie unu la muli). Un numr ridicat
de dimensiuni este nerecomandat, deoarece analiza de date ar deveni prea complex.

11.4.2. Schema stea pentru un lan de supermarketuri

n cele ce urmeaz vor fi analizate coleciile de date pentru organizarea unui lan de
supermarket-uri, ilustrnd schema relaional corespunztoare schemei entitate-asociere.
Relaia unu la muli poate fi transformat prin atribuirea n entitatea central a unui
identificator compus dintr-un set de identificatori pentru fiecare dimensiune.
Fiecare tuplu a relaiei vnzare are patru coduri: ProdCod, MarketCod, PromoCod,
TimpCod, care, luate mpreun, formeaz o cheie primar.

304
Capitol 11
Terapia
Pacient
Boala
Timp
Doctor (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)


Fig. 11.5. Colecia de date pentru un sistem de informaii medical

Astfel, o vnzare elementar poate fi descris ca un set al tuturor vnzrilor care sunt
realizate ntr-o perioad de timp, cu referire la un produs, o promoie dintr-un supermarket.
Fiecare eveniment de vnzare este astfel un articol de date agregate. Atributele non-cheie sunt
Cantitile vndute i Valoarea veniturilor. Se presupune c fiecare vnzare este numai pentru
o promoie i se accept vnzrile produselor ce nu au promoie, considerndu-le ca avnd o
promoie nul.
Informaiile despre atributele celor patru domenii sunt urmtoarele:
- Produsele sunt identificate de cod (ProdCod) i au ca atribute: Nume, Categorie,
Subcategorie, Marca, Greutate, nlocuitor.
- Supermarket-urile sunt identificate prin cod (MarketCod) i au ca atribute: Nume,
Ora, Regiune, Zon, Mrime, Aezarea supermarketului (de exemplu: la etajul 1 sau
etajul 2, etc.).
- Promoiile sunt identificate prin cod (PromoCod) i au ca atribute: Nume, Tip,
discount procentual (Procentaj), CuponFlag (care indic prezena de cupoane n ziare),
DataStart, DataSfrit, Cost i Agenie de publicitate.
- Timpul este identificat prin cod (TimpCod) i are atribute ce descriu ziua vnzrii din
timpul sptmnii (ZiSpt: de duminica pn smbta), din timpul lunii (ZiLuna: 1 la
31), i din an (ZiAn: 1-365), apoi sptmna din luna (SptLuna) i din an (SptAn),
apoi luna din an (LunaAn); Anotimpul.
n general, dimensiunile prezint redundanta i date derivate. De exemplu, n
dimensiunea Timp, cunoscnd o zi dintr-un an i un calendar se pot deriva valori ale tuturor
atributelor de timp relatate. Similar, daca un ora apare de mai multe ori n relaia
Supermarket, regiunile sale sunt repetate. Redundanta este introdusa pentru a facilita ct mai
mult posibil operaia de analiz de date i a o face ct mai eficient. Schema entitate-asociere
este transformat ntr-o schem logic relaional, rezultatul artnd dup cum urmeaz:

VNZRI(ProdCod, MarketCod, PromoCod, TimpCod, Cantitate, Venit)
PRODUS(ProdCod, Nume, Categorie, Subcategorie, Marca, Greutate, nlocuitor)
SUPERMARKET(MarketCod, Nume, Ora, Regiune, Zona, Mrime, Aezare)
305
Depozite de date

PROMOIE(PromoCod, Nume, Tip, Procentaj, CuponFlag, DataStart, DataSfrit,
Cost, Agenie)
TIMP(TimpCod, ZiSpt, ZiLun,ZiAn, SptLun, SptAn, LunAn, Anotimp).

De fapt, relaia este n form normal Boyce-Codd prin care fiecare atribut care nu este
cheie depinde funcional de cheia relaiei. Pe de alt parte, n general dimensiunile sunt relaii
nenormalizate. n final, sunt patru restricii de integritate ntre fiecare atribut care alctuiete
cheia tabelei de fapte i tabelele dimensiune. Fiecare dintre cele patru coduri care alctuiesc
cheia tabelei de fapte este o cheie extern, referindu-se la tabela dimensiune care o are ca
cheie primar.

11.4.3. Schema fulg de zpad

Schema fulg de zpad este o dezvoltare a schemei stea, n care domeniile sunt
structurate ierarhic. Schema este introdus pentru a lua n calcul prezena unor dimensiuni
nenormalizate. Figura 11.6. ilustreaz colecia de date pentru organizarea supermarketurilor,
reprezentat prin schema fulg de zpad. n timp ce dimensiunea promoiilor e neschimbata,
celelalte dimensiuni sunt organizate ierarhic. Schema fulg de zpad prezint ierarhizri
explicite, acestea reducnd redundana i anomaliile, dar fiind mult mai complex.
- Dimensiunea Supermarket este structurat dup ierarhie: Zon, Regiune, Ora,
Supermarket. Fiecare Zon include multe Regiuni, fiecare Regiune include multe
Orae i fiecare Ora are unul sau mai multe Supermarket-uri.
- Dimensiunea Produs este reprezentat de o ierarhie cu dou noi entiti: nlocuitor i
Categoria Produsului.
- Dimensiunea Timp e structurat dup ierarhia Zi, Lun, An.
Atributele schemei stea sunt distribuite unor entiti variate ale schemei fulg de
zpad, eliminnd sursele de redundant. Toate relaiile descrise n figura anterioar sunt unu
la muli i fiecare element este conectat la unul i doar un element al nivelului urmtor.
Principalul avantaj a schemei stea este simplitatea ei, care permite crearea unei
interfee foarte simple pentru formularea interogrilor.

11.4.4. Schema constelaie de fapte

Aplicaiile sofisticate pot solicita tabele multiple de fapte care partajeaz tabele
dimensiune. O alt variant a schemei stea este schema constelaie de fapte (sau multistea),
care const n mai multe tabele de fapte, conectate de obicei la una sau mai multe dimensiuni.
Acest gen de schem poate fi vzut ca o colecie de stele.
Pentru depozitele de date, schema constelaie de fapte este n mod curent utilizat, un
depozit de date colectnd date despre subiecte multiple care se refer la ntreaga organizaie.
Un exemplu de astfel de schem poate fi obinut dac la schema stea iniial pentru reeaua de
supermarket-uri se adaug pe lng tabela de fapte iniial, cea de Vnzri, o tabel
suplimentar de fapte pentru Aprovizionri, care se leag la rndul ei de dimensiunile
Supermarket, Produs i Timp.

306
Capitol 11
Vanzare
Produs
Promotie
Zi
Supermarket (0,N)
(0,N)
(1,N)
(1,N)
(0,N)
(0,N) (1,N) (1,N)
Inlocuitor (0,N) (1,N) Categorie (0,N) (1,N)
Oras
Regiune
Zona
(1,1)
(0,N)
(1,1)
(0,N)
(1,1)
(0,N)
Luna
An
(1,1) (0,N)
(1,1)
(0,N)


Fig. 11.6 Schema fulg de zpad pentru un lan de supermarketuri


11.5. Operaii pentru analiza datelor

n acest paragraf vor fi prezentate interfeele pentru formularea interogrilor i cteva
operaii pentru utilizate pentru creterea puterii de expresivitate a limbajelor de interogare.

11.5.1. Interfee de formulare a interogrilor

Analiza datelor pentru o colecie de date organizate conform schemei stea, necesit
mai nti extragerea unui subset de factori i dimensiuni bazate pe solicitrile unei activiti
particulare de analiz a datelor. Aceste extrageri de date urmresc un model standard:
dimensiunile sunt utilizate pentru a selecta datele i a le grupa n timp ce funciile agregate
sunt, de obicei, aplicate faptelor. E posibil astfel realizarea unor module predefinite pentru
consultarea depozitului de date n care sunt oferite opiuni predefinite pentru selecie, agregare
i evaluare a funciilor agregate. Figura 11.7. prezint o interfa de consultare a datelor
pentru Data Mart-ul din seciunea 11.4.2. n ceea ce privete dimensiunile, acestea sunt
307
Depozite de date

preselectate: numele promoiei, numele produsului, numele vnzrii. Pentru fiecare element,
sunt selectate cantitile pentru vnzri. Valoarea Superpromoie este inserat n partea de
jos a acestui modul. Superpromoie identific o promoie particular, indicnd astfel
procentul din valoarea vnzrilor obinut prin aceasta.
n mod similar, intervale de valori Paste i Ulei ( pentru produse) i Februarie i
Aprilie sunt selectate.
n ultimul rnd al interfeei de extragere a datelor se definete structura rezultatelor
care ar trebui s includ dimensiunile Produs (incluznd valorile selectate Paste i Ulei) i
Timp (ntre Februarie i Aprilie) i cantitatea totala de vnzri.

Promoie.Nume Produs.Nume Timp.LunaAn Cantitate
Trei pt. Dou
Cupon 15%
Superpromoie
Vin
Paste
Ulei
IanuarieDecembrie



Superpromoie PasteUlei Februarie...Aprilie
Produs.Nume Timp.Luna Sum

Fig. 11.7. Interfaa pentru formularea unei interogri OLAP

Interfaa corespunde unei interogri SQL cu o structur predefinit, care, este
completat cu opiunile introduse de utilizator. n interogare apar clauze Join, care conecteaz
tabela de fapte cu dimensiunile), clauze de selecie (care extrag date relevante), grupri,
ordonri, clauze de agregare.

select D1,C1DnCn, Aggr1 (F.C1), Aggrn(FCn)
from Fact as F, dimension1 as D1,dimensionn as Dn
where conditie-join (F,D1)
and
and conditie-join (F,Dn) and conditie-selectie group by D1.C1,Dn.Cn
order by D1.C1,Dn.Cn

n cazul specificat, interogarea construit conform cu opiunile utilizatorului arat
dup cum urmeaz:

Select Timp.Luna, Produs.Nume, sum(Cantitate)
From Vnzare, Timp, Produs
Where Vnzare. TimpCod=Timp. TimpCod And Vnzare. ProdusCod =Produs. ProdusCod
And Vnzare. PromoieCod=Promoie. PromoieCod
And (Produs.Nume=Paste Or Produs.Nume=Ulei)
And Timp.LunaAn between Februarieand Aprilie
And Promoie.Nume=Superpromoie Group By Timp.LunaAn, Produs.Nume
Order By Timp.LunaAn, Produs.Nume

Rezultatul interogrii poate fi prezentat de clientul OLAP n forma de matrice sau
grafic. n formatul matrice, dimensiunile corespund rndurilor i coloanelor, iar faptele
corespund celulelor, ca n Figura 11.8.
Aceast reprezentare a datelor este destul de des utilizat de uneltele de analiz
deoarece permite operaii de calcul tabelar asupra rezultatelor interogrilor. Graficele clasice
cu bare i cele tip plcint pot fi utilizate pentru vizualizarea datelor; de exemplu graficele
Schema
Optiuni
Conditie
View
308
Capitol 11
cu bare pot utiliza diferite culori pentru a reprezenta diferite tipuri de produse la diferite
momente de timp.

Feb Mar Apr
Ulei
Paste
5K
45K
5K
50K
7K
51K

Fig. 11.8. Rezultatul interogrii OLAP

11.5.2. Drill-down i roll-up

Analogia cu programele de calcul tabelar nu este limitat la prezentarea datelor. De
fapt, exist dou operaii de manipulare primitiva a datelor care deriv din dou operaii tipice
cu tabele: drill-up i drill-down (figura 11.9.)

Timp.LunaAn Produs.Nume Sum(Cant)
Feb
Mar
Apr
Paste
Paste
Paste
45K
50K
51K

Fig. 11.9. Subseturi de rezultate ale interogrii OLAP

Drill-down permite introducerea unei dimensiuni a analizei, realiznd astfel o
dezagregare a datelor. De exemplu, un utilizator ar putea fi interesat n adugarea distribuiei
cantitii vndute pe zone de vnzare, realiznd i operaia drill-down pe Zon. Presupunnd
c atributul Zona ia valoarea Nord, Centru i Sud, obinem tabelul din figura 11.10.

Timp.LunaAn Produs.Nume Zona Sum(Cant)
Feb
Feb
Feb
Mar
Mar
Mar
Apr
Apr
Apr
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Paste
Nord
Centru
Sud
Nord
Centru
Sud
Nord
Centru
Sud
18K
15K
12K
18K
18K
14K
18K
17K
16K

Fig. 11.10. Drill-down pentru tabelele reprezentate n figura 11.9.

Roll-up permite n schimb eliminarea unei dimensiuni de analiz, reagregnd datele.
De exemplu, un utilizator poate s decid c subdivizarea vnzrilor pe zone e mai
folositoare dect cea pe luni. Acest rezultat e obinut realiznd o operaie de roll-up pe luni,
obinndu-se rezultatul afiat n figura 11.11.
Alternnd operaiile roll-up i drill-down, analistul poate evidenia dimensiunile care
au influen mai mare asupra fenomenelor reprezentate de fapte. De notat c operaia roll-up
se realizeaz opernd pe rezultatul interogrii, n timp ce operaia drill-down necesit n
general o reformulare i o reevaluare a interogrii pentru c necesit adugarea unei noi
coloane n rezultatul interogrii
309
Depozite de date

Produs.Nume Zona Sum(cant)
Paste
Paste
Paste

Nord
Centru
Sud
54K
50K
42K


Fig. 11.11. Eliminarea tabelelor prezentate n figura 11.10.
.
11.5.3. Seciuni i rotaii

Asupra cuburilor de date trebuie s se poat predefini viziuni sau imagini (views)
specifice diverselor categorii de utilizatori, prin operaii de secionare. O sectiune (slice)
reprezint un membru specific al unei dimensiuni, de ex. Produsul A din dimensiunea Produs.
Secionarea conduce la crearea unei serii de intersecii cu alte dimensiuni pentru seciunea
respectiv. De exemplu, dup luna, dup regiune, dup client. Acest dup ne indic cum
putem realiza vizualizarea datelor prin limitarea unor atribute la anumite valori i obinerea
unui cub de date redus (procedeu numit data dicing). Aceasta intersecie multidimensional i
modul ei de organizare face modelul OLAP foarte puternic. Abilitatea de a schimba
perspectivele asupra datelor intuitiv i instantaneu este o facilitate de baz a tuturor
instrumentelor serioase pentru OLAP.
Alte dou faciliti important n proiectarea multidimensional OLAP sunt pivotarea
i imbricarea dimensiunilor. Pivotarea presupune schimbarea intre ele a dimensiunilor in
cadrul unei vizualizari, reorientarea cubului de date, de obicei trecerea de pe linii pe coloane
si invers.

11.5.4. Data cube

Utilizarea recurent a agregrilor a sugerat introducerea unui operator foarte puternic,
cunoscut ca DATA CUBE, pentru a realiza toate agregrile posibile prezente ntr-o tabel
extras pentru analiz. Pentru descrierea operatorului se va folosi un exemplu. Se presupune
c depozitul de date conine urmtoarea tabel care descrie vnzrile de maini. Vor fi afiate
tuplurile unice referitoare la maini Ferrari sau Porsche roii, vndute ntre 1998 i 1999
(figura 11.12)

Productor An Culoare Vnzri
Ferrari
Ferrari
Porsche
1998
1999
1998
Rou
Rou
Rou
50
85
80

Fig. 11.12. Imaginea unei tabele de vnzri

DATA CUBE este construit prin adugarea clauzei cu WITH CUBE la o interogare ce
conine o clauz GROUP BY. De exemplu, se consider urmtoarea interogare:

select Productor,An,Culoare,Sum(Vnzri)
from Vnzri
where (Productor=Ferrari or Productor =Porsche)
and Culoare= Rou and An between 1998 and 1999
group by Productor, An, Culoare with cube
310
Capitol 11
Interogarea extrage toate agregrile construite prin gruparea intr-un mod combinat a
tuplurilor conform cu cele trei dimensiuni ale analizei (Productor, An, Culoare). Agregarea
este reprezentata de valoarea polimorfic ALL care (ca i NULL) e prezent n toate
domeniile i corespunde tuturor valorilor posibile prezente n domeniu ( figura13).
O reprezentare spaial a structurii DATA CUBE este evideniat n figura 11.14.
Diagrama arata un spaiu cartezian construit pe trei axe corespunznd domeniilor celor trei
atribute. n acest exemplu, domeniul Productor ia valorile Ferrari i Porsche, domeniul An ia
valorile 1998 i 1999, iar domeniul Culoare ia valoarea Rou. Punctele n spaiu reprezint
tupluri n figura 11.12. De notat ca nu toate punctele sunt prezente n depozitul de date. n
exemplul considerat, trei din patru sunt prezente. Cele trei planuri carteziene reprezint
agregarea unei dimensiuni, axele carteziene reprezint agregrile pentru dou dimensiuni i
originea axelor carteziene reprezint agregarea pentru toate cele trei dimensiuni.
Evident, o reprezentare carteziana similara din punct de vedere conceptual, ntr-un
spaiu cu n dimensiuni este posibila n cazul unei operaii de DATA CUBE cu un numr
arbitrar de atribute de grupare.

Productor An Culoare Suma(Vnzri)
Ferrari
Ferrari
Ferrari
Ferrari
Ferrari
Ferrari
Porsche
Porsche
Porsche
Porsche
All
All
All
All
All
All
1998
1999
1998
1999
All
All
1998
1998
All
All
1998
1999
All
1998
1999
All
Rosu
Rou
All
All
Rou
All
Rou
All
Rou
All
Rou
Rou
Rou
All
All
All
50
85
50
85
135
135
80
80
80
80
130
85
215
130
85
215

Fig. 11.13. Operaia data CUBE a tabelei reprezentate n figura 11.12

Complexitatea DATA CUBE crete exponenial cu creterea numrului de atribute
care sunt grupate. O extensie diferit de SQL construiete agregri progresive n loc s
construiasc toate agregrile posibile; astfel complexitatea evalurii acestei operaii crete
doar ntr-un mod liniar cu creterea numrului de atribute grupate. Aceast extensie necesit
nlocuirea clauzei WITH CUBE cu clauza WITH ROLL-UP, ilustrat n urmtorul exemplu:

select Productor, An, Culoare, Sum(Vnzri)
from Vnzri
where (Productor=Ferrari or Productor= Porsche)
and Culoare =Rou
and An between 1998 and 1999
group By Productor, An, Culoare with roll-up

Rezultatul evalurii acestei interogri este evideniat n Figura 11.4.
311
Depozite de date


Productor An Culoare Sum(Vnzri)
Ferrari
Ferrari
Porsche
Ferarri
Ferrari
Porsche
Ferrari
Porsche
All
1998
1999
1998
1998
1999
1998
All
All
All
Rou
Rou
Rou
All
All
All
All
All
All
50
85
80
50
85
80
135
80
215

Fig. 11.14. Roll-up realizat asupra tabelei reprezentate n figura 11.12

Se observ progresul agregrilor, de la stnga la dreapta, i faptul c rezultatul are mai
puine tupluri dect rezultatul operaiei DATA CUBE.
Interogrile cu WITH CUBE i WITH ROLL-UP sunt prezente n multe SGBD-uri
relaionale i nu necesit n mod obligatoriu prezena unui depozit de date. n orice caz, o
interpretare a celor dou interogri conform modelului stea este ntotdeauna posibila,
deoarece atributele clauzei GROUP BY joac rolul domeniilor, n timp ce atributele ramase
ale clauzei SELECT descriu operaiile de agregare aplicate faptelor.


11.6. Dezvoltarea depozitului de date

Exist patru abordri alternative cu privire la dezvoltarea depozitului de date:
- Prima abordare const n utilizarea tehnologiei relaionale, adaptat i extins
corespunztor. Datele sunt stocate utiliznd tabele, dar operaiile de analiz sunt
realizate n mod eficient utiliznd structuri speciale de date. Acest tip de sistem este
numit ROLAP (Relational OnLine Analytic Processing). n ROLAP toate agregrile
sunt stocate n cadrul bazelor de date relaionale surs. ROLAP reprezint cea mai
lent soluie pentru consultarea datelor, deoarece, indiferent dac exist sau nu o
agregare, trebuie accesat direct depozitul de date. Aceast soluie este recomandat
pentru implementri de dimensiuni mai mici.

- A doua abordare, mai radical, const n stocarea datelor n form multidimensional,
folosind structuri de date vector. Acest tip de sistem este numit MOLAP
(Multidimensional OnLine Analytic Processing). n MOLAP, att datele surs ct i
agregrile sunt stocate n format multidimensional. MOLAP este opiunea cea mai
rapid pentru consultarea datelor, dar necesit cel mai mult spatiu de disc (acest
criteriu nu mai reprezint o prioritate n ultima vreme, avnd n vedere scderea
costurilor de stocare i procesare).


- HOLAP (Hybrid OnLine Analytic Processing) este o combinaie a primelor dou
modele. Bazele de date HOLAP stocheaz agregrile existente ntr-o structur
multidimensional, lsnd nivelul celulelor de baz n form relaional. Deoarece
datele sunt n form preagregat, HOLAP ofer performanele MOLAP atunci cnd
este nevoie de preluarea datelor din tabele.
312
Capitol 11
- DOLAP (Desktop OnLine Analytic Processing) presupune stocarea datelor pe maini
desktop individuale, fiind ntlnite in aplicaii de dimensiune redus, n care exist
solicitri minime ca mai muli utilizatori s aib acces la o baz de date central aflat
pe un server central. DOLAP este inclus n soluiile oferite de muli dintre furnizori
pentru a facilita analiza n cazurile n care uilizatorii nu se pot conecta la reeaua
companiei.

Soluia MOLAP este adoptat de un numr mare de produse specializate n
managementul Data Mart-urilor, datorit restriciilor legate de hardware i de costul
procesrii. HOLAP ofer performane mai bune n cazul n care se acceseaz o baz de date
stand-alone. Soluia ROLAP este utilizat de un numr mare de productori de soluii
relaionale. Aceasta aduga soluii specifice OLAP experienei tehnologice a SGBD-urilor
relaionale i astfel este foarte probabil ca ROLAP s reziste pe termen mediu i lung.
Soluiile ROLAP sunt preferate cnd cererile de interogare sunt relative reduse i se acceseaz
o baza de date standalone. n orice caz, tehnologiile ROLAP i MOLAP utilizeaz soluii
inovative pentru acces la date i cu privire la indeci i materializarea view-urilor.
Aceste soluii iau n considerare faptul c depozitul de date folosit n principal pentru
operaii de citire i ncrcare iniial sau progresiv a datelor, n timp ce modificrile i
anulrile sunt rare. Depozitele de date mari utilizeaz paralelismul, cu fragmentarea i
alocarea corespunztoare a datelor pentru a face interogrile mai eficiente. n cele ce urmeaz
se vorbete doar despre tehnologiile ROLAP.
313