GVMD Curs

ACADEMIA DE STUDII ECONOMICE DIN BUCURETI
FACULTATEA DE CIBERNETIC, STATISTIC I INFORMATIC ECONOMIC
Programul de masterat profesional

BAZE DE DATE SUPORT PENTRU AFACERI
Modulul: GESTIUNEA VOLUMELOR MARI DE DATE
-- ASPECTE PRIVIND DEPOZITELE DE DATE --
Bucureti
2016-2017
-1-
CUPRINS
DEPOZITE DE DATE.................................................................................................................... - 3 -
1. Modelul de date multidimensional ................................................................................................. - 3 -
1.1. Structura modelului multidimensional ....................................................................... - 3 -
1.2. Operaii realizate asupra modelului multidimensional ............................................... - 7 -
1.3. Restricii de integritate ............................................................................................... - 8 -
1.4. Modele de reprezentare a obiectelor depozitelor de date ........................................... - 9 -
2. Organizarea datelor n depozite de date ........................................................................................ - 11 -
2.1. Inteligena Afacerii aspecte fundamentale ............................................................ - 11 -
2.2. Principalele tehnologii informatice utilizate n sistemele pentru Inteligena Afacerii- 12 -
2.3. Evoluia i definirea depozitelor de date .................................................................. - 13 -
2.4. Obiectivele i caracteristicile organizrii datelor n depozitele de date ................... - 15 -
2.5. Faciliti oferite de depozitele de date sistemelor de Inteligena Afacerii ............... - 17 -
3. Arhitectura depozitelor de date ..................................................................................................... - 18 -
3.1. Arhitectura pe componente a depozitelor de date .................................................... - 18 -
3.2. Arhitectura pe niveluri a depozitelor de date ........................................................... - 19 -
3.3. Arhitectura depozitelor de date din punctul de vedere funcional............................ - 20 -
4. Tipuri de depozite de date............................................................................................................. - 21 -
4.1. Tipuri de depozite de date n funcie de aria de cuprindere ..................................... - 21 -
4.2. Tipuri de depozite de date n funcie de procesele decizionale pentru care au fost
proiectate ............................................................................................................................... - 22 -
4.3. Tipuri de depozite de date n funcie de modelul de date implementat .................... - 22 -
5. Aspecte comparative privind organizarea datelor n baze de date i n depozite de date ............. - 23 -
REALIZAREA DEPOZITELOR DE DATE ............................................................................... - 25 -
1. Considerente privind realizarea depozitelor de date ..................................................................... - 25 -
1.1. Modaliti de realizare a depozitelor de date............................................................ - 25 -
1.2. Metodologii utilizate la realizarea depozitelor de date ............................................ - 26 -
2. Etape de realizare a depozitelor de date ....................................................................................... - 28 -
2.1. Strategia de realizare a depozitelor de date .............................................................. - 28 -
2.2. Modelarea depozitelor de date ................................................................................. - 31 -
2.3. Implementarea depozitelor de date........................................................................... - 34 -
2.4. Exploatarea depozitelor de date ............................................................................... - 42 -
2.5. Criterii de evaluare a depozitelor de date ................................................................. - 44 -
2.6. Instrumente i medii de dezvoltare utilizate pentru realizarea depozitelor de date.. - 45 -
BIBLIOGRAFIE ........................................................................................................................... - 47 -
* Varianta extins a materialului se regsete n monografia Tratat de baze de date. Vol. I. Baze de date: organizare,
proiectare, implementare coord.Ion Lungu.
-2-
Gestiunea volumelor mari de date
DEPOZITE DE DATE
Un depozit de date furnizeaz o surs integrat i centralizat de date, separat de sistemul tranzacional,
care conine datele eseniale despre activitatea companiei din multitudinea de surse de date existente.
Rapoartele obinute pe baza acestor date sunt utilizate ca un instrument de analiz strategic i competitiv,
analizele rapide i corecte putnd influena deciziile privind evoluia organizaiei pe termen mediu i lung.
Cuvinte cheie: depozite de date, cub de date, schema de tip stea, model multidimensional, dimensiuni, fapte,
msuri.
1. Modelul de date multidimensional
Depozitele de date sunt organizate diferit fa de bazele de date, fiind destinate mai mult
extragerii de date dect actualizrilor repetate. Datele extrase sunt utilizate n analize dinamice care
presupun schimbri de perspectiv asupra datelor i vizualizri ale acestora de la un nivel detaliat la
unul sintetic, agregat i invers. Din acest motiv s-a impus o organizare specific a datelor n care
obiectele sunt structurate pe diferite niveluri care permit aceast analiz dinamic.
Modelele de date utilizate pentru reprezentarea depozitelor de date au cunoscut o diversitate
destul de mare att din punctul de vedere al teoretizrii conceptelor ct mai ales din punctul de
vedere al aplicrii diferitelor tipuri de modele n practic. Dou direcii importante au clasificat
totui aceast diversitate de modele i anume dezvoltarea unor extensii ale modelului relaional i
dezvoltarea modelelor bazate pe cuburi n-dimensionale.
Tipul de model multidimensional utilizat de diverse tehnologii i produse software care
implementeaz depozitele de date difer att din punctul de vedere al SGBD utilizat ct i din cel al
operaiilor realizate asupra datelor i a arhitecturii implementate.
1.1. Structura modelului multidimensional
Structura modelului multidimensional conine n principal obiectele referitoare la tabelele de

fapte cu atribute de tip msuri sau metrici, tabelele de tip dimensiune n care regsim niveluri
ierarhice, atribute de identificare i atribute de descriere etc. Aceste obiecte vor fi prezentate n
continuare.
n cadrul modelului multidimensional se ntlnesc mai multe tipuri de obiecte care prezint
o importan deosebit n analiz [KIRE98].
Dimensiunile reprezint structuri compuse formate din atribute structurate pe diverse
niveluri ierarhice n funcie de care sunt grupate datele. Aceste atribute sunt de obicei descriptive i
sunt folosite ca surs pentru limitarea nregistrrilor afiate n cadrul rapoartelor analitice. Sunt
considerate tabele secundare datorit dimensiunilor reduse. Consiliul OLAP, un consoriu al
firmelor dezvoltatoare de produse OLAP nfiinat n 1995 cu rolul de a standardiza aceste tehnologii
prin stabilirea unor standarde deschise (OLAP API), definete conceptul de dimensiune ca fiind un
atribut structural al unui cub care const dintr-o list de membri, pe care utilizatorii i percep ca
fiind de acelai tip (de exemplu toate lunile, trimestrele, anii formeaz dimensiunea Timp).
Dimensiunile reprezint un mod foarte concis, intuitiv de organizare i selectare a datelor pentru
-3-
explorare i analiz. [OLAP95].

Datele dintr-o dimensiune sunt structurate ierarhic, pe mai multe niveluri, fiecare dintre
acestea putnd avea mai multe atribute.
Ierarhiile sunt structuri logice utilizate pentru ordonarea nivelurilor de reprezentare a
datelor. Sunt utilizate i pentru definirea cilor de navigare n interiorul dimensiunilor i ofer
instrumentelor de analiz OLAP posibilitatea de detaliere gradual a datelor n rapoarte. Tot n
definiiile date de Consiliul OLAP se menioneaz c membrii dimensiunilor pot fi organizai pe
baza relaiilor de tip printe-copil, unde un membru printe reprezint agregarea membrilor copil.
Rezultatul este o ierarhie i relaiile printe-copil sunt relaii ierarhice [OLAP95].
Nivelurile reprezint poziii n cadrul ierarhiilor, cu exemplificare pe dimensiunea Produs
(figura 1). De exemplu dimensiunea Timp poate avea trei niveluri de ierarhizare: an, trimestru i
lun. Relaiile ntre diferite niveluri sunt relaii de tipul printe-copil, ns se pot defini ierarhii n
care datele fiecrui nivel sunt agregate la un nivel imediat superior sau se poate sri peste anumite
niveluri care sunt independente.
Figura 1. Ierarhii i niveluri ale dimensiunii Produs
Nivelurile unei ierarhii sunt eseniale pentru determinarea tipurilor de navigri care se pot
realiza n dimensiuni. Tot consiliul OLAP precizeaz urmtoarele doi membri ai unei ierarhii sunt
de aceeai generaie dac ei au acelai numr de strmoi. Termenii de generaie i nivel sunt
necesari pentru a descrie subgrupuri de membri ntruct, de exemplu, dei doi frai membri au
acelai printe i sunt de aceeai generaie, ei ar putea s nu fie la acelai nivel, dac unul din frai
are un copil i cellalt nu. [OLAP95]
Atributele dimensiunile conin atribute care reprezint calificative specifice. Orice atribut
se asociaz unei singure dimensiuni, iar o dimensiune se poate exprima prin mai multe atribute.
Exist dou tipuri de atribute: de identificare a dimensiunii i a fiecrui nivel n parte i atribute
descriptive care realizeaz o clasificare a datelor n cadrul ierarhiei.
Tabelele de fapte sunt tabelele centrale care conin atribute de tip msuri (metrici) i chei
externe ctre tabelele dimensiuni. Aceste obiecte conin de obicei date numerice care pot fi
nsumate i analizate pe fiecare nivel din ierarhiile dimensiunilor.
Msurile (metricile)- corespund atributelor (faptelor) din tabelele de fapte i sunt de regul
de natur numeric (de exemplu: volumul vnzrilor, costurile, stocurile disponibile). Aceste
variabile au sens numai n contextul unor anumite dimensiuni. Valoarea msurii este calculat
pentru un punct dat prin agregarea datelor corespondente perechii aferente valoare-dimensiune,
diferite pentru punctul dat.
Sunt mai multe criterii dup care se pot clasifica msurile utilizate ntr-o tabel de fapte, i
anume: modalitatea de calcul, tipurile de funcii agregate utilizate, modalitile de nsumare i
agregare n funcie de dimensiuni.
n funcie de modalitatea de calcul atributele se pot clasifica n msuri de baz, care se
-4-
regsesc sub forma atributelor din tabelele de fapte i care provin din sursele de date i msuri
derivate (virtuale) care se obin prin combinarea msurilor de baz i care n tabelele de fapte au
precizat formula de calcul prin care se obin.
n funcie de tipurile de funcii agregate utilizate msurile pot fi organizate n trei categorii:
distributive, algebrice, holistice.
Msurile distributive sunt calculate cu ajutorul unor funcii de agregare distributive.
Presupunem c datele sunt mprite n n seturi. Calcularea funciei pe fiecare partiie determin o
valoare agregat. Dac rezultatul obinut prin aplicarea funciei asupra a n valori agregate este
acelai cu cel obinut prin aplicarea funciei asupra tuturor datelor fr partiionare, funcia poate fi
calculat n manier distributiv. De exemplu, numrul de nregistrri participante poate fi calculat,
pentru un cub de date, printr-o prim partiionare a acestuia ntr-un set de subcuburi, aplicnd
funcia COUNT( ) pentru fiecare subcub i apoi nsumnd rezultatele obinute. Din acest motiv
funcia COUNT( ) este o funcie agregat distributiv.
Msuri algebrice - sunt calculate cu ajutorul unor funcii algebrice cu M argumente (unde M
este un ntreg pozitiv), fiecare din ele obinut prin aplicarea unei funcii agregate distributive. De
exemplu, media (funcia AVG( )) poate fi calculat aplicnd funciile SUM( )/COUNT( ) unde
ambele funcii SUM( ) i COUNT( ) sunt funcii agregate distributive. n mod similar se poate
demonstra c funciile MIN( ), MAX( ) i STDEV( ) (abaterea standard) sunt funcii algebrice
agregate. Msura este algebric dac este obinut prin aplicarea unei funcii algebrice agregate.
Msuri holistice - sunt calculate cu ajutorul unor funcii holistice. O funcie agregat este
holistic, dac aceasta nu este limitat constant pe spaiul de stocare cerut de deschiderea
subagregrii. n acest caz, nu exist o funcie algebric avnd M argumente (unde M este o
constant) care caracterizeaz calculul. Exemple comune de funcii holistice sunt: MEDIAN(),
MODE(), RANK(). O msur holistic este obinut prin aplicarea unei funcii agregate de tip
holistic. Cele mai multe aplicaii necesit calcularea eficient a msurilor distributive i algebrice.
Exist mai multe tehnici eficiente pentru aceasta dar, n contrast, pot fi mai dificil de calculat n
mod eficient msurile holistice. Exist totui anumite tehnici eficiente de aproximare a calculului
msurilor holistice. De exemplu, n loc de a aplica funcia MEDIAN( ) cu exactitate, exist tehnici
care pot determina aproximativ valoarea median pentru un set foarte mare de date, cu rezultate
satisfctoare.
Din punctul de vedere al modalitii de nsumare i agregare n funcie de dimensiuni, Ralph
Kimball n lucrarea The Data Warehouse Toolkit [KIMB96] clasific metricile n trei categorii:
indicatori aditivi care se pot nsuma dup toate dimensiunile, indicatori semiaditivi care se pot
nsuma numai dup unele dimensiuni i indicatori neaditivi care nu se pot nsuma dup nicio
dimensiune, dar care pot fi combinai cu alte variabile pentru a deveni aditivi.
Metadatele reprezint poate cea mai important component a depozitului de date.
Metadatele, denumite i date despre date, descriu coninutul depozitului i permit accesul direct la
date. Tot la nivelul metadatelor se definesc i diverse tabele virtuale (views) asociate unor categorii
specifice de utilizatori. Metadatele sunt intens folosite pentru administrarea depozitului de date,
coninnd informaii despre proveniena datelor, algoritmii de agregare i nsumare, statistici
privind utilizarea i multe altele.
Nivelul metadatelor trebuie s conin urmtoarele categorii de informaii conform
[JAJE98]:
o descriere a structurii de date din depozit, care include schema depozitului,
dimensiunile, ierarhiile, definiiile datelor derivate;
metadatele operaionale, care includ: date privind evoluia n timp (istoricul datelor i
secvena de transformare aplicat asupra lor), circulaia datelor (active, arhivate, terse)
i informaii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de
erori etc.);
-5-
algoritmii utilizai pentru sumarizare, care includ: msura i dimensiunea algoritmilor

definii, date despre granularitate, partiii, arii de subiecte, agregri, agregri, rapoarte i
filtre predefinite;
maprile (transformrile) de la mediul operaional la depozitul de date care includ:
bazele de date surs i coninutul lor, descrierile interfeelor (gateways), partiionarea
datelor, extragerea datelor, filtrarea datelor, regulile de ntreinere, securitate a datelor;
date referitoare la performanele sistemului care includ indici i profiluri care
mbuntesc accesul la date i performanele de cutare;
metadatele economice (business metadata), care includ termenii economici i definiiile
aferente.
Metadatele se aplic pentru: sursele de date; programele i regulile de extragere i
transformare; structura datelor i coninutul propriu-zis al depozitului de date. Importana
metadatelor pentru depozitul de date reiese din faptul c acestea stabilesc contextul depozitului de
date, uureaz procesul de analiz, menin i cresc calitatea datelor, dar i din faptul c sunt o form
de auditare a transformrii datelor.
Metadatele permit localizarea i regsirea datelor att n sistemele surs ct i n structura
depozitului. Dac metadatele care descriu formatul datelor din depozite sunt disponibile, atunci se
elimin orice ambiguitate legat de semnificaia datelor.
Metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea valorilor
valide pentru fiecare cmp din depozit. nainte de a fi efectiv ncrcate n depozit, datele pot fi
revzute i erorile pot fi corectate, iar regulile de corecie a erorilor pot fi documentate tot prin
metadate.
Se pot deosebi mai multe tipuri de metadate n funcie de destinaia lor:
Metadate administrative. Acestea conin descrieri ale bazelor de date surs i ale
coninutului, ale obiectelor depozitului de date i ale regulilor folosite pentru a transforma datele din
sistemul surs n depozit. Dintre exemplele de astfel de metadate menionm: descrierea tuturor
surselor de date folosite, transformarea cmpurilor surs n cmpuri destinaie, schema depozitului
de date, structura datelor folosite de programe i instrumente de analiz, reguli i formule de calcul,
reguli de securitate i de acces.
Metadate pentru utilizatorii finali. Aceste metadate au rolul de a le permite utilizatorilor s-
i creeze propriile interogri i s interpreteze rezultatele n cadrul instrumentelor de analiz
utilizate. Pentru aceasta au nevoie s cunoasc definiiile datelor din depozit, descrierea lor, precum
i orice ierarhie care poate exista n cadrul dimensiunilor. Exemple de astfel de metadate sunt
urmtoarele: coninutul depozitului de date, rapoartele i interogrile predefinite, definiiile
ierarhiilor, calitatea datelor, istoricul ncrcrii depozitului de date i regulile de eliminare.
Metadate pentru optimizare. Aceast categorie de metadate are rolul de a crete
performanele depozitului de date. Exemple de astfel de metadate sunt: definiiile agregrilor i
colecii de statistici.
Rolul metadatelor pentru depozitul de date reiese din urmtoarele considerente:
stabilesc contextul depozitului de date. n orice sistem, inclusiv n depozitele de date,
utilizatorul intr sub o sesiune de lucru, adic se creeaz automat un context de lucru:
parametri setai, conectri efectuate, drepturi existente etc.;
ajut administratorii i utilizatorii depozitului s localizeze i s neleag secvenele de
date att n sistemele surs, ct i n structura depozitului. n sistemele operaionale,
dezvoltatorii i administratorii bazelor de date lucreaz cu metadate n fiecare zi. Toat
documentaia tehnic a sistemelor reprezint ntr-un fel sau altul metadate. Ele rmn
totui transparente pentru majoritatea utilizatorilor, acetia percepnd n general sistemul
ca pe o cutie neagr care ofer o interfa prin intermediul creia trebuie utilizat. n cazul
depozitelor de date, utilizatorii sistemelor de asistare a deciziei trebuie s neleag
nainte de toate coninutul depozitului, pentru ca apoi s beneficieze de informaiile
necesare;
-6-
procesul de analiz cuprinde mai multe etape: identificarea datelor, obinerea datelor,
interpretarea i analiza datelor pentru a obine informaii, prezentarea informaiilor i
recomandarea unei direcii de aciune. Pentru ca depozitul de date s fie folositor
analitilor din ntreprindere, metadatele trebuie s ofere utilizatorilor informaii care s-i
ajute n parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie s ajute
utilizatorii s gseasc rapid datele n depozit i s interpreteze corect datele obinute
prin oferirea informaiilor referitoare la formatul i semnificaia datelor;
metadatele sunt o form de auditare a transformrii datelor. Metadatele documenteaz
transformarea datelor surs n date ale depozitului, adic trebuie s fie capabile s
explice modul n care o secven de date din depozit este dedus din sistemele
operaionale. Toate regulile care guverneaz transformarea datelor n noi valori sau noi
formate sunt considerate a fi metadate. Aceast form de audit este necesar atunci cnd
utilizatorii trebuie s aib ncredere n veridicitatea i calitatea datelor din depozit. De
asemenea, este important ca utilizatorii s-i poat da seama de unde provin datele
existente n depozit. Este de dorit ca, pe baza acestor metadate, anumite produse s poat
genera programe de extragere i transformare pentru cei care se ocup de interfaa de
analiz a depozitului de date;
metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea valorilor
valide pentru fiecare cmp din depozit. nainte de a fi efectiv ncrcate n depozit, datele
pot fi revzute i erorile pot fi corectate. De asemenea, regulile de corecie a erorilor pot
fi documentate tot prin metadate;
metadatele permit gestiunea versiunilor. Un depozit de date conine date pentru diferite
perioade de timp i de aceea este important s avem n vedere efectul pe care l poate
avea timpul asupra regulilor de trecere a cmpurilor surs n cmpuri destinaie, asupra
agregrilor etc. Utilizatorii trebuie s aib acces la metadatele corecte pentru perioada de
timp pe care o studiaz. Ceea ce la prima vedere ar prea s fie o eroare n transformarea
datelor poate fi de fapt rezultatul schimbrii regulilor de transformare a datelor. De aceea
este important ca metadatele s fie corect gestionate din punctul de vedere al versiunilor.
Exemple de metadate. Descrierea proprietilor datelor (obiectelor) din lumea real se face
prin intermediul metadatelor, printr-un proces de abstractizare. Astfel, metadatele referitoare la
cmpurile unui depozit de date se vor referi la: denumirea cmpului (aa cum va fi folosit n tabela
relaional fizic), sinonim pentru denumirea cmpului (aa cum este folosit de utilizatori), tipul de
date pentru fiecare cmp (aa cum este acceptat de SGBD), indexarea (dac va fi folosit pentru
cmp), cheia (dac un cmp este cheie), formatul cmpului, descrierea (o definiie a cmpului).
1.2. Operaii realizate asupra modelului multidimensional
Prin aplicarea unor operaii specifice asupra modelului multidimensional utilizatorului i se

ofer posibilitatea de a vedea i de a analiza datele din perspective multiple, de a naviga n cadrul
ierarhiilor definite, de a extrage un subset de date precum i de a interschimba axele sau
dimensiunile pentru a obine o alt detaliere a datelor. Toate aceste operaii multidimensionale
implementate n cadrul modelului multidimensional sunt prezentate n paragrafele urmtoare.
Navigarea pe nivelurile ierarhice (drill down i roll up) reprezint operaii de navigare n
cadrul ierarhiilor dimensiunilor, prin agregare pe nivelurile superioare sau detaliere pe nivelurile
inferioare. Orice depozit de date trebuie s permit navigarea pe diferite niveluri ale ierarhiilor.
Aceast tehnic se numete roll up sau drill down, n funcie de direcie, spre vrful sau baza
ierarhiei. Acestea sunt operaii de schimbare a perspectivei de-a lungul nivelurilor unei ierarhii. Prin
facilitatea de drill down, utilizatorii pot vizualiza datele cu un grad de detaliu mai accentuat. Prin
roll up se pot vizualiza datele la un nivel agregat. Cu toate c instrumentele de analiz pot realiza
dinamic toate operaiile de navigare, pentru a economisi timp i resurse se prefer uneori
-7-
precalcularea unor valori globale. Aceasta operaie este numit consolidare (cnd se refer la
aspectul conceptual), nsumare (din perspectiva procedural), agregare (din perspectiva
structural). Aceste agregri se refer la o anumit msur i se realizeaz dup dimensiunile
corespunztoare acesteia. Pentru atributele organizate ierarhic, consolidarea se face nivel cu nivel.
Aceste operaii implic de cele mai multe ori doar calcularea unor subtotaluri, dar exist i excepii
n care se utilizeaz formule sau procedee statistice. Nivelul la care se face nsumarea n cazul n
care sunt implicate ierarhii se numete granularitate. Procesul de agregare creeaz o redundan n
cadrul depozitului, dar volumul acesteia nu este semnificativ deoarece scade exponenial cu fiecare
nivel de nsumare. Ctigul de performan obinut la accesarea datelor este deosebit de important
n analiz.
Rotaiile reprezint operaiile cele mai frecvente n structurile de date multidimensionale i
ofer utilizatorului posibilitatea de a alege perspectiva asupra datelor pe care le va utiliza. De
exemplu n cazul bidimensional exist dou posibiliti de vizualizare, iar n cazul tridimensional se
pot utiliza 6 rotaii pentru a vizualiza datele din diferite perspective, iar pentru patru dimensiuni
exist 24 de perspective posibile. Fiecare rotaie pune n eviden o nou perspectiv, aducnd n
prim-plan o structur bidimensional, o faet (slice) a datelor. Din acest motiv rotaia se mai
numete i data slicing. Aceste operaii nu implic o reorganizare a datelor stocate, ci o schimbare a
modalitii de reprezentare, spre deosebire de cazul unor structuri relaionale, pentru care o nou
faet poate fi obinut doar n urma unor interogri complexe.
Seciuni - reprezint vederi sau imagini (views) specifice diverselor categorii de utilizatori,
prin operaii de secionare prin care se obin felii bidimensionale (slices). Tehnica aceasta const
n limitarea unor atribute la anumite valori i obinerea unui cub de date redus (procedeu numit data
dicing).
Extensii ale operatorilor relaionali permit realizarea n limbajul SQL a unor subtotaluri
asupra obiectelor depozitului de date stocate sub form de tabele relaionale. Cercettorul american
Paul Gray a propus n anul 1998 [GRWA98] operatorii CUBE i ROLLUP care realizeaz agregarea
datelor pe baza unor coloane dintr-o tabel relaional ce reprezint o dimensiune.
Operatorul ROLLUP permite realizarea de subtotaluri n funcie de coloanele specificate cu
ajutorul funciilor de agregare implementate de SGBD relaionale (SUM( ), COUNT( ), AVG( ),
STDEV( )).
Operatorul CUBE produce toate combinaiile posibile de subtotaluri dintr-un cub. Prin
utilizarea funciei GROUPING se poate face o distincie ntre valorile NULL din tabel i cele
rezultate din agregare.
1.3. Restricii de integritate
Prin natura operaiilor realizate asupra modelului multidimensional, restriciile de integritate

nu sunt o component esenial a acestuia. Modelul multidimensional bazat pe reprezentarea sub
form de schem tip stea utilizeaz totui o adaptare a restriciilor de integritate ale modelului
relaional i anume:
restriciile de integritate structurale: restricia de unicitate a cheii i restricia entitii
aplicate n cazul atributelor de identificare ale tabelelor de fapte i ale dimensiunilor,
restricia referenial aplicat pentru stabilirea legturii dintre tabelele de fapte i
dimensiuni i dependenele ntre date pentru determinarea legturii existente ntre
anumite atribute sau metrici;
restriciile de integritate de comportament: restricii de domeniu i restricii temporale
aplicate pentru valorile atributelor i a metricilor.
Pentru relaiile existente ntre nivelurile ierarhiilor unei dimensiuni se poate considera o
restricie special - restricia de asociere a nivelurilor prin care se definete realizarea legturilor
unui nivel inferior cu nivelul superior i se specific formula de agregare.
-8-
1.4. Modele de reprezentare a obiectelor depozitelor de date
Exist dou modaliti (modele) principale de reprezentare a obiectelor depozitelor de date:

modele care utilizeaz extensii ale modelului relaional i modele care structureaz obiectele unui
depozit sub forma elementelor unui cub de date.
Ambele modele reprezint obiectele modelului multidimensional sub form de schem a
depozitului de date, care este o colecie de obiecte, incluznd tabele de fapte, dimensiuni, indeci i
sinonime. Exist mai multe tipuri de scheme utilizate n modelarea multidimensional, diferena
fiind dat de modurile n care se pot aranja obiectele n cadrul acesteia. n continuare vom prezenta
cteva modele de reprezentare a obiectelor dintr-un depozit de date.
Extensii ale modelului relaional - Modelul propus de Kimball

Acesta este modelul cel mai frecvent utilizat i care a cunoscut n timp cele mai multe
mbuntiri i variante: schema stea, fulg de zpad, galaxie.
Schema Stea n cadrul acestui model propus de Ralph Kimball [KIMB96] obiectele sunt
dispuse n form de stea, n centru aflndu-se una sau mai multe tabele de fapte care sunt n relaie
cu dimensiunile (figura 2). O schem de jonciune stea suport dou tipuri de interogri:
consultare i jonciuni multiple. Operaia de consultare se realizeaz pe o singur tabel de fapte i
nu necesit jonciuni. Interogrile de tip jonciune multipl apar dup o serie de consultri i implic
restricii plasate n cadrul dimensiunilor prin operaia de jonciune, cu tabela de fapte.
Figura 2. Schema stea
Dimensiunile n acest caz sunt denormalizate, ele avnd date redundante care elimin
necesitatea unor legturi multiple ntre tabele. ntr-o schem stea nu exist dect o singur legtur
ntre tabela de fapte i dimensiuni.
Schema de tip stea are urmtoarele caracteristici:
ntre tabela de fapte i dimensiuni exist jonciuni de egalitate;
cheile primare ale dimensiunilor se regsesc printre atributele cheii compuse a tabelei de
fapte;
atributele tabelei de fapte care nu particip la jonciune pot fi agregate.
Optimizarea performanei de rspuns la interogri este principalul avantaj al acestui model,
ns este destul de inflexibil.
Schema de tip Fulg de Nea - este o variant a modelului stea n care o parte din tabelele
-9-
dimensiune sunt normalizate, iar datele sunt distribuite n tabele suplimentare (figura 3). Rezult o
schem reprezentat ntr-un grafic similar unui fulg de zpad. Diferena ntre modelul stea i
modelul fulg de nea este c tabelele dimensiune din acesta pot fi pstrate n forma normalizat, ceea
ce determin o redundan controlat. Asemenea tabele sunt uor de ntreinut i astfel se
economisete spaiu de stocare. Totui aceast economie de spaiu este neglijabil n comparaie cu
volumul foarte mare de date din tabela de fapte. Mai mult, structura fulg de nea poate reduce
performana extragerii de date deoarece sunt necesare mai multe jonciuni ntre tabele la o singur
interogare.
Figura 3. Schema fulg de nea
Schema Galaxie reprezint o asociere de scheme de tip stea i care conine tabele de fapte
suplimentare care stocheaz date agregate. n cadrul galaxiei exist o stea principal, numit stea
central care conine datele la nivel atomic, iar celelalte stele conin date agregate (figura 4).
Figura 4. Schema galaxie
Legtura dintre stele se realizeaz prin intermediul dimensiunilor, astfel nct o dimensiune
va face parte din una sau mai multe stele.
- 10 -
Avantajul principal al acestei scheme este dat de faptul c datele agregate sunt independente
de cele atomice, ns dezavantajul este c modificarea stelelor agregate trebuie s asigure
consistena datelor cu steaua central.
Modele bazate pe cuburi multidimensionale

Cuburi de date - Un mod mai simplu de vizualizare a datelor este reprezentarea ntr-un
spaiu cartezian definit pe toate dimensiunile depozitului de date (figura 5). Acesta poate fi numit
cub de date, fiind un spaiu de date logic i nu unul fizic. Seciunile bidimensionale sunt numite
tablouri. Axele cubului sunt reprezentate de dimensiuni, la intersecia acestora fiind variabilele sau
msurile.
n analiza multidimensional cubul de date cu mai mult de trei dimensiuni poart denumirea
de cub n-dimensional sau hipercub (hypercub). Consiliul OLAP definete cubul n-dimensional ca
fiind un grup de celule de date aranjate dup dimensiunile datelor. O matrice tridimensional
poate fi vizualizat ca un cub n care fiecare dimensiune formeaz o fa a cubului [OLAP95].
PRODUS
LOCATIE
TIMP
Figura 5. Cub de date cu trei dimensiuni
Reprezentarea unui cub cu patru dimensiuni poate fi fcut ca n figura 6.

furnizor F1 furnizor F2 furnizor F3
locaie
produs
T1 T2 T3
timp
Figura 6. Cub de date cu patru dimensiuni
2. Organizarea datelor n depozite de date

2.1. Inteligena Afacerii aspecte fundamentale
Inteligena Afacerii IA (Business Intelligence BI) reprezint o tehnologie informatic

care privete organizarea i funcionarea ntreprinderii i a conducerii acesteia. Cercetrile n acest
domeniu se ncadreaz n tendina actual de trecere de la societatea industrial la cea
informaional i a cunoaterii, care presupune c tranziia pune n centrul ateniei specialitii care
trebuie s asigure societii informaionale o dezvoltare durabil, iar obiectivul propus poate fi atins
prin decizii fundamentate tiinific cu un suport informaional pe msur.
Inteligena Afacerii se refer la capacitatea de a transforma date existente n informaie util
care s furnizeze perspective bogate, i mai ales noi, asupra lumii afacerilor din prezent i s ofere o
- 11 -
idee referitoare la tendina acesteia n viitor. Soluiile de IA au rolul de a identifica abloanele i a

nelege tendinele care pot influena afacerile i permit analiza detaliat a activitii organizaiei, de
a nelege comportamentul consumatorului i de a mbunti procesul decizional. Analizele se
realizeaz pe date istorice i curente, permind determinarea unor tendine viitoare n cadrul
activitilor urmrite.
Un sistem informatic pentru Inteligena Afacerii ofer un ansamblu de tehnologii
informatice, inclusiv produse software, care livreaz utilizatorilor informaiile necesare pentru a
rspunde la ntrebrile ce apar n rezolvarea problemelor de afaceri.
Principalele considerente care determin necesitatea unui sistem informatic pentru
Inteligena Afacerii sunt legate de: reducerea timpului de obinere a cererilor i analizelor prin
accesul i livrarea rapid a informaiilor ctre utilizatori, deinnd mecanisme pentru optimizarea
regsirii datelor dintr-un volum mare de date; gestionarea i modelarea mediului de afaceri curent
printr-o serie de mecanisme pentru interogare, raportare, analiz complex a informaiilor, stocarea
volumelor uriae de date, extragerea i descoperirea datelor; reducerea costurilor informatice prin
creterea eficienei sistemelor utilizate.
Obiectivele unui sistem pentru Inteligena Afacerii rezult din scopul unui astfel de sistem:
suportul informaional pentru fundamentarea deciziilor. Rezult, deci, c la nivelurile de conducere
sunt urmrite n contextul unui sistem de IA urmtoarele obiective:
s permit soluii informatice i decizii ale conducerii avnd costuri ct mai sczute,
eficiente pentru funcionarea i dezvoltarea organizaiei;
s permit accesul rapid i uor la informaiile organizaiei pentru un numr ct mai
mare de utilizatori de toate categoriile, principala categorie de utilizatori fiind format
din manageri;
s ofere suport pentru noi tehnologii informatice care s dea eficien sistemului;
s ofere un mediu de lucru adaptat pentru nivelurile de conducere: interactiv, flexibil,
dinamic, deschis etc.
Pentru atingerea acestor obiective, multe organizaii prefer s construiasc un sistem
separat pentru Inteligena Afacerii, fie din motive de securitate, fie din motive de performan a
sistemului. De asemenea, se tie c sistemele dedicate dau performane ridicate pe domenii bine
precizate, aa cum este cel al conducerii.
2.2. Principalele tehnologii informatice utilizate n sistemele pentru Inteligena

Afacerii
n momentul actual, foarte puine dintre soluiile informatice pentru Inteligena Afacerii nu
sunt realizate cu sisteme de baze de date. Marii productori actuali de sisteme de gestiune a bazelor
de date (SGBD) - Oracle, IBM, Microsoft, Informix - sunt i marii furnizori de soluii informatice
pentru Inteligena Afacerii. Acest lucru a fost realizat prin extinderea SGBD cu tehnologiile
informatice care conduc spre soluii de IA. Extinderea se ncadreaz n tendina actual, conform
creia SGBD au devenit acum infrastructuri complexe i complete pentru baze de date de diferite
tipuri.
Printre cele mai utilizate tehnologii informatice pentru sistemele de Inteligena Afacerii
sunt: depozitele de date, concentrrile de date, extragereatransformarea-ncrcarea datelor, analiza
complex multidimensional a datelor - sistemele OLAP, extragerea i descoperirea de cunotine
din date.
Depozitele de date (Data Warehouse) i concentrrile de date (Data Marts) - sunt dou
soluii care rezolv problemele legate de sursele de date disparate i de scopurile incompatibile
dintre procesarea tranzaciilor i aplicaiile de IA. Scopul unui depozit de date este de a furniza un
stoc central de date, unde informaiile din unul sau mai multe sisteme tranzacionale pot fi
consolidate ntr-o singur surs de date, integrat i consistent. Depozitul de date este proiectat
- 12 -
pentru a optimiza generarea de rapoarte dinamice pe un numr mare de nregistrri ale coleciilor de
date. El presupune multe regsiri i foarte puine actualizri (sau deloc) pentru c datele stocate au
un caracter istoric. Rezultatele interogrii intense a depozitelor de date sunt folosite pentru
fundamentarea deciziilor.
Aceste faciliti, dac sunt integrate n produse software care aparin unui SGBD, rspund
optim tuturor cerinelor unei afaceri, deoarece se bazeaz pe un ansamblu mare i variat de date, cu
faciliti de regsire deosebite.
Deoarece procesul dezvoltrii unui depozit de date la nivel de ntreprindere este lung i
complex i uneori nu se ncheie cu succes, practicienii acestuia pot adopta o abordate alternativ:
dezvoltarea unor depozite mai mici i consolidate, cunoscute sub denumirea de concentrri de date.
Astfel, prin date stocate n volume mai mici, nevoia de o raportare mai exact i imediat poate fi
suplinit ntr-un ciclu de dezvoltare mai scurt, la un pre mai mic. Aadar, concentrarea de date este
de regul un depozit de date de dimensiuni reduse realizat la nivelul unui departament sau al unei
sector de activiti din cadrul organizaiei.
Tehnologia de Extragere, Transformare, ncrcare (ETI) - se refer la crearea unui depozit
de date din mai multe surse de date. Dezvoltarea unei vederi singulare i consistente a datelor care
exist n mai multe sisteme, adic integrarea datelor, necesit curarea acestora. De asemenea,
datele de la surs s-ar putea s necesite uneori transformarea spre un format comun n depozitul de
date. O interfa ETI permite definirea regulilor de afaceri utiliznd produse software pentru:
interfa grafic, interfee standard de comunicaie cu date (ODBC, JDBC etc.), acces la date,
prelucrarea datelor, stocarea datelor.
Tehnologia OLAP (On Line Analytical Processing) - utilizeaz analiza multidimensional a
datelor pentru a atinge flexibilitatea i n acelai timp a menine performana. n aceast abordare,
datele sunt vzute la nivel conceptual ca un cub. Acest cub const din valori cantitative, denumite
msuri i categorii descriptive, denumite dimensiuni. n procesul de analiz a datelor se tie exact ce
trebuie s se obin, prin folosirea unor algoritmi de statistic superioar. Utilitatea pentru
organizaii const n abilitatea de a-i analiza superior datele n scopul de a furniza viziunea
necesar lurii deciziilor. Aceast utilitate este dat de abilitatea la nivelul conducerii de a-i analiza
superior datele pe care le deine n scopul de a furniza viziunea necesar lurii deciziilor i de
cutare a datelor ntr-un spaiu multidimensional prin valorificarea experienei existente n analiza
statistic clasic, adugnd noi tehnici i metode superioare.
Extragerea de cunotine din date (Data Mining - DM). Extragerea i descoperirea de date
conduce tehnologia IA cu un pas mai departe dect OLAP. n sistemele OLAP utilizatorul este
angajat n mod activ n explorarea datelor, pe cnd n data mining, informaia spune ceva despre
date fr s fie adresat vreo ntrebare. Tehnologia data mining utilizeaz metode de cutare
complexe spre a identifica modele i grupri ale datelor, putnd identifica tendine neprevzute n
comportamentul consumatorului, care potenial pot fi utilizate s prevad comportamentul viitor.
Extragerea de cunotine din date se mbuntete cu ct crete cantitatea de date i necesit
depozite de date de nalt calitate pentru a putea da rezultate utile. Data mining realizeaz analiza
datelor i nvarea folosind n acest sens un conglomerat de tehnologii informatice: inteligena
artificial, statistica, matematica etc.
2.3. Evoluia i definirea depozitelor de date
Depozitele de Date (DD) reprezint rezultatul interferenei mediului economic i al

tehnologiilor informatice avansate. Mediul economic este tot mai competitiv tinznd spre
globalizare i devine tot mai complex solicitnd informaii elaborate pentru sprijinirea deciziilor
strategice. Un astfel de mediu economic a determinat evoluia activitii de realizare a sistemelor
informatice de la orientarea pe operaional (activitatea curent a firmei care pleac de la funciile
ntreprinderii i funciile conducerii) spre orientarea pe procesul de afacere. Procesul de afacere
- 13 -
(business process) este un ansamblu de activiti interdepartamentale, la nivelul unei organizaii,

care presupune una sau mai multe intrri i care genereaz un rezultat important pentru client
(intern sau extern). Sunt dou caracteristici fundamentale ale procesului de afaceri determinate de
orientarea decidenilor spre nivelul procesului de afaceri (interdepartamental) mai mult dect spre
nivelul funciilor ntreprinderii i de integrarea activitilor dintr-o organizaie i realizarea de
sisteme informatice integrate.
Evoluia depozitelor de date este marcat de lucrrile cercettorului american William
Harvey Inmon (nscut n anul 1945) care este printele de necontestat al conceptului de Data
Warehouse, iar viziunea sa se concentreaz asupra rolului acestuia ca baz informaional a deciziei
manageriale, pstrnd astfel un nivel nalt de generalitate.
n viziunea sa depozitul de date este o colecie de date orientate pe subiecte, integrate,
istorice i nevolatile, destinat sprijinirii procesului de luare a deciziilor manageriale. [INMO96].
Consiliul OLAP formuleaz urmtoarea definiie: un depozit de date (data warehouse)
reprezint o stocare centralizat a datelor detaliate provenite din toate sursele relevante din cadrul
unei organizaii i permite interogarea dinamic i analiza detaliat a tuturor informaiilor.
[OLAP95]
n viziunea lui Ralph Kimball [KIMB96] depozitul de date ofer acces la datele
organizaionale, datele obinute sunt consistente i pot fi separate i combinate n funcie de fiecare
dimensiune sau aspect al afacerii. Depozitul de date include, de asemenea un set de instrumente
pentru interogare, analiz i prezentare a informaiilor i reprezint locul n care sunt publicate
datele folosite. Calitatea datelor coninute n depozit reprezint o premiz pentru re-ingineria
afacerii.
Contribuii la definirea, dezvoltarea i popularizarea tehnologiilor de data warehouse au fost
aduse de o serie de companii dezvoltatoare de produse software precum: IBM, Software AG,
Oracle, Microsoft, Prism Solution etc.
n concluzie, putem defini depozitul de date ca fiind un ansamblu de date de dimensiune
foarte mare care este ntreinut separat de bazele de date operaionale ale unei organizaii i care
este construit din date provenite din sisteme surs prin extragere, filtrare, transformare i stocare
n depozite speciale, n scopul sprijinirii proceselor decizionale. Depozitele de date sprijin
prelucrarea informaiilor pentru analiz, furniznd o platform solid de consolidare a datelor
istorice. Un depozit de date este un ansamblu de date consistente, din punctul de vedere semantic,
care servete la o implementare fizic a unui model de date pentru sprijinirea deciziei i stocheaz
informaii pe care o organizaie le solicit n luarea deciziilor strategice.
Un depozit de date reprezint o modalitate de integrare i organizare a datelor din surse
omogene i neomogene, provenite din sisteme tranzacionale dar i din fiiere externe, integrate
dup anumite criterii, supuse unui proces de extragere, transformare i ncrcare, stocate agregat
pe niveluri ierarhice, destinate prelucrrilor i analizelor dinamice, fiind soluia optim de
organizare a datelor pentru sistemele informatice suport de decizie i executive.
Spre deosebire de sistemele operaionale, structurile de date dintr-un depozit de date sunt
optimizate pentru o regsire i o analiz rapid. Datele sunt istorice i sunt actualizate la intervale
regulate de timp, n funcie de cerinele de raportare.
Creterea volumului de informaii, precum i perfecionarea tehnologiilor de exploatare a
acestora au condus la o nou calitate a folosirii datelor prin analize care pot releva conducerii
organizaiei informaii greu sau chiar imposibil de obinut pe alte ci. Se pot obine astfel informaii
privind preferinele clienilor, profilul lor, distribuia etc. Astfel se pot furniza conducerii date,
precum: n ce regiune a rii se vinde mai bine un anumit produs, care sunt preferinele unui anumit
segment de pia etc.
Este evident c astfel de informaii nu se pot obine dect folosind anumite prelucrri cum ar
fi analiza multidimensional, anumite metode statistice de prognoz i alte metode matematice
aplicate unui volum foarte mare de date din care se extrag numai datele relevante, celelalte fiind
- 14 -
ignorate. Pentru astfel de aplicaii, datele trebuie bine organizate i indexate pentru o uoar regsire
i utilizare.
Volumul unui depozit de date se ncadreaz ntre 1 i peste 10 TB, aceste cifre neavnd
dect un caracter orientativ [VILA97]. Exist astfel i depozite de date coninnd zeci de terabytes.
Crearea unui astfel de depozit cost n medie 3-5 milioane dolari. Din acest cost, o treime o
reprezint serviciile profesionale. O alt treime se cheltuiete pentru aplicaiile necesare extragerii,
prelucrrii, depozitrii i analizrii datelor, iar ultima treime este destinat sistemelor hardware
necesare i stocrii datelor. De obicei, depozitele de date i dubleaz dimensiunile n primele 12
pn la 18 luni. Aceast cretere exponenial poate fi pe de o parte semnul sigur al succesului
implementrii depozitelor dar, pe de alt parte, poate deveni o problem dac sistemele nu sunt
construite de la nceput suficient de elastice i de deschise.
Din cele de mai sus rezult importana deosebit a flexibilitii impuse sistemelor care
implementeaz asemenea depozite de date. Aici, flexibilitate nseamn o conectivitate la nivelul
ntregii organizaii, astfel nct servere de baze de date diferite s se poat conecta simultan la
depozitul deja existent. Este de asemenea deosebit de important s se aleag o arhitectur care s se
adapteze uor la modificrile de performane, capacitate i conectivitate.
Pentru a evita aceste probleme, se poate alege o cale de mijloc i se poate opta pentru
realizarea unei concentrri de date (data mart) care s conin numai datele relevante pentru analiza
necesar. Conectnd mpreun concentrrile de date aferente diferitelor compartimente ale
companiei se formeaz astfel o infrastructur specific, departamentele putnd folosi n comun
datele i se poate crea un depozit de date mai uor de construit i mai elastic.
Un data mart tipic poate utiliza servere existente, structura informaional existent (o reea
LAN sau Intranet) cu mai puin de 500 GB, cost mai puin de 1 milion de dolari i se
implementeaz de obicei n aproximativ 90 de zile.
Rolul unui depozit de date este de a oferi o imagine coerent asupra datelor relative la
activitatea unei organizaii i a contextului n care acesta acioneaz. Utilizarea acestei colecii poate
consta din extragerea unor rapoarte (la cerere sau cu o anumit periodicitate), extragerea unor date
pentru a fi utilizate de aplicaiile de birotic (programe de calcul tabelar, procesoare de text,
programe de prezentare etc.), dar mai ales pentru a fi utilizate de ctre aplicaii specializate de
analiz, precum tehnologia OLAP i tehnologiile pentru extragerea cunotinelor din date (data
mining).
2.4. Obiectivele i caracteristicile organizrii datelor n depozitele de date
Organizarea datelor n depozite de date prezint o serie de obiective derivate din scopul
principal al realizrii acestora i anume suportul pentru analize complexe i dinamice asupra datelor
istorice i curente ale organizaiei.
Principalele obiective identificate sunt:
depozitul de date trebuie s asigure accesul la datele organizaiei. Accesul trebuie s se
realizeze ntr-un timp ct mai scurt, la cerere i s fie performant. Datele ntr-un depozit
de date pot fi separate i combinate pentru a oferi un acces ct mai rapid i un timp de
rspuns ct mai mic sistemului. De asemenea, accesul presupune existena unor utilitare
care s fie foarte uor de folosit;
utilizarea datelor din depozite direct n analize, fr alte prelucrri suplimentare.
Datele nu sunt doar centralizate, integrate i stocate, ci dup ce sunt extrase dintr-o
varietate de surse, sunt corectate de erori, transformate, li se asigur calitatea necesar i
abia apoi devin utilizabile. Depozitele de date nu reprezint doar datele, ci i un set de
utilitare pentru a interoga, analiza i prezenta informaiile;
stocarea de date istorice. Pentru analiza economic, informaiile care au caracter istoric
sunt eseniale, deoarece ele pun n evident tendine care reprezint fundamentul unei
- 15 -
prognoze corecte. Depozitul de date este un istoric al sistemului operaional. Orizontul

de timp pe care l acoper acesta de cel puin cinci ani, ajungnd uneori la zece ani, n
funcie de dinamica evoluiei pieei i, deci, de relevana datelor cu caracter istoric
pentru nevoile analizei. Din punctul de vedere al aspectelor tehnice, aceasta implic
faptul c orice nregistrare din depozitul de date poate fi plasat n timp, orice cheie de
acces cuprinde i o variabil de timp;
orientarea depozitului pe subiectele importante ale procesului economic (clieni,
furnizori, produse, activiti) fa de datele operaionale (BD sau fiiere) care sunt
orientate pe aplicaii, n sensul c organizarea lor este optimizat pentru a servi
procesului tranzacional, dinamicii sistemului.
Datorit obiectivelor impuse de utilizarea depozitelor de date n analiz se desprind cteva
caracteristici mai importante pe care acestea le dein.
Datele dintr-un depozit de date trebuie s fie consistente. Consistena presupune faptul c
atunci cnd dou persoane solicit acelai set de informaii s primeasc aceleai date, chiar dac
ele au fost cerute la momente de timp diferite. Dac datele nu au fost complet ncrcate atunci
utilizatorul va fi avertizat cu privire la acest lucru i este sftuit s atepte pn ce vor fi complet
ncrcate.
Calitatea datelor din depozitele de date este un factor determinant pentru procesul de
analiz. Se ntlnete frecvent situaia n care datele nu sunt de bun calitate sau nu sunt extrase n
ntregime sau au un caracter incert din punctul de vedere al coninutului ceea ce face ca analiza
ulterioar s conduc la rezultate eronate.
O alt caracteristic important este redundana datelor. Dac n sistemul operaional
redundana este eliminat (prin procesul de normalizare) pentru a evita anomaliile de actualizare, n
depozitul de date redundana este creat n mod intenionat prin denormalizare i agregare pentru a
permite un acces mai rapid la date.
Sursele de date pentru depozitul de date provin n principal din datele importate din sistemul
informatic operaional, dar mai pot proveni i din datele de arhiv (n perioada de constituire a
depozitului) precum i din sursele externe (baze de date publice, date demografice, date statistice,
date de prognoz economic, date obinute n urma unor sondaje de opinie etc.).
Integrarea datelor reprezint o alt consecin important a realizrii depozitului de date i,
n cele din urm, raiunea pentru care acesta este creat. Datele sunt ncrcate 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 mai multe subsisteme relativ independente, create la momente diferite, de echipe
diferite, n maniere diferite, ceea ce face greoaie folosirea unui astfel de sistem pentru analiz.
Integrarea datelor provenind din aceste sisteme dar i din alte surse se refer la urmtoarele
aspecte:
modaliti unice de codificare exist nenumrate variante de a codifica un cmp dar o
aplicaie pentru analiza datelor va trebui s se bazeze pe o codificare unic;
sistem de uniti de msur unitar - unitile de msur pentru diferite cmpuri trebuie
exprimate ntr-un sistem unic (metric etc.);
sistem stabil de reprezentare fizic a datelor - n aplicaiile tranzacionale este posibil ca
aceleai date s fie memorate n moduri de organizare diverse. Acestea trebuie stabilizate
dup anumite reguli precise;
convenii clare privind modul de reprezentare a datelor datele calendaristice, cmpurile
care definesc timpul etc., trebuie s respecte conveniile internaionale;
convenii unice privind denumirile cmpurilor de date - n sistemul operaional acestea
pot s difere de la o aplicaie la alta, dar n depozitele de date ele trebuie s fie unice
(lucrul n echip).
Multe aplicaii operaionale (tranzacii) presupun actualizarea continu a coleciilor de date
(actualizare, modificare, tergere). La depozitele de date, actualizarea este foarte rar, adic
- 16 -
dinamica lipsete. Actualizarea se realizeaz aici doar prin adugarea periodic a unor date extrase
din sistemele operative sau din alte surse de date.
Din punctul de vedere al aplicaiilor care folosesc depozitul de date, accesul la date este
doar pentru citire.
n sistemul operaional, o tranzacie trebuie s duc colecia de date dintr-o stare consistent
ntr-o alt stare consistent, iar aceasta implic mecanisme complexe de meninere a integritii
datelor (jurnalizare, salvare/restaurare, blocare). n cazul depozitelor de date mecanismele de
integritate sunt inutile, astfel c gradul de libertate ctigat poate fi utilizat pentru optimizarea
accesului la date prin denormalizare, agregare, statistici ale accesrii datelor, reorganizare dinamic
a indexrii etc.
2.5. Faciliti oferite de depozitele de date sistemelor de Inteligena Afacerii
Creterea volumului de date, precum i perfecionarea produselor software pentru gestiunea

acestuia au condus la o nou calitate a utilizrii datelor prin analize care pot releva conducerii
organizaiei informaii greu sau chiar imposibil de obinut pe alte ci, inclusiv cu soluii informatice
clasice.
Se pot obine astfel informaii privind: preferinele clienilor, profilul clienilor, distribuia
produselor, regiunea unde se vinde mai bine un anumit produs, care sunt preferinele unui anumit
segment de pia etc.
Pentru a obine informaiile dorite, depozitele de date sunt supuse unor prelucrri complexe,
cu ajutorul unor metode specifice, cum ar fi: analiza multidimensional a datelor, metode statistice
superioare de prognoz, metode matematice aplicate unui volum foarte mare de date.
Aceste metode presupun folosirea unui software specializat deosebit de complex, bazat pe
noi tehnologii informatice, precum cele prezentate anterior: extrageri de cunotine din date (data
mining), OLAP (Online Analytical Processing), concentrri de date (data mart).
Sistemele care lucreaz cu depozite de date dispun de o mare flexibilitate, ceea ce nseamn
o conectivitate la nivelul ntregii organizaii, astfel nct servere provenind de la furnizori diferii s
se poat conecta simultan la depozitul deja existent. Este, de asemenea, deosebit de important s se
aleag o arhitectur care s se adapteze uor la modificrile de performane, capacitate i
conectivitate. Procesele de configurare, optimizare i administrare a sistemului, inclusiv procedurile
de salvare-restaurare, precum i pstrarea n tot acest timp a funcionalitii sistemului, pot deveni
operaii dificile dac trebuie repetate la fiecare adugare a unor noi servere n sistem.
Depozitele de date sunt destinate managerilor i analitilor angrenai n luarea deciziilor
strategice privind dezvoltarea i viitorul organizaiilor. Pentru aceasta, ei pot utiliza interfee
performante de accesare i analiz a datelor din depozite, adic produse software asociate
depozitului de date:
interfee oferite de SGBD utilizatorilor, care au nevoie de acces rapid, de informaii
punctuale (limbaje de interogare gen SQL, generatoare de rapoarte);
interfee specializate pentru asistarea deciziilor, care transform datele n forma cerut de
decideni (grafice, diagrame, organigrame) sau ofer posibilitatea analizei tendinelor,
corelaiilor i interpretarea acestora (OLAP, data mining).
Interfeele OLAP se bazeaz pe reprezentarea multidimensional a datelor (cubul de date) i
permite analiza interactiv i rapid a datelor prin operaiuni specifice. Utilizatorul poate obine
rezultate imediate parcurgnd dinamic dimensiunile cubului de date, lucrnd cu niveluri diferite de
sintez/detaliere (exemplu Oracle OLAP).
Interfeele de tip Data Mining asigur extragerea i transformarea datelor n cunotine, de
aceea uneori se consider termenul data mining sinonim cu termenul Knowledge Discovery in
Databases (KDD). Se utilizeaz tehnici ale analizei statistice superioare i de Inteligen Artificial
- 17 -
care permit descoperirea de corelaii, reguli, cunotine utile sprijinirii deciziilor (exemplu Oracle
Miner).
3. Arhitectura depozitelor de date
Elementele care alctuiesc un depozit de date pot fi interconectate n mai multe tipuri de
arhitecturi n funcie de rolul, funcionalitatea i de viziunea utilizatorilor asupra acestora. Astfel se
pot distinge urmtoarele tipuri de arhitecturi: pe componente, pe niveluri i arhitectura funcional
a DD.
3.1. Arhitectura pe componente a depozitelor de date
Esena unui depozit de date const ntr-un ansamblu de date de dimensiuni foarte mari
coninnd informaiile pe care le pot folosi utilizatorii (clieni, furnizori, companii de publicitate
etc.).
Arhitectura pe componente evideniaz componentele DD i legturile dintre ele: depozitul
de date, sursa de date, interfeele de analiz (figura 7).
Depozitul de date conine mai multe tipuri de date care corespund diferitelor cerine
informaionale ale utilizatorilor: date detaliate, date agregate, metadate (dicionarul de date).
Datele detaliate sunt cele relativ recente, livrate utilizatorilor, de regul la nivel de execuie.
Datele agregate, dei determin o cretere a redundanei datelor, sunt necesare n depozitul
de date deoarece n acest fel se poate asigura un timp mediu de rspuns ct mai redus. Aceste date
presupun un grad de prelucrare prealabil, astfel nct s fie pregtite pentru suport decizional i
analize avansate: consolidare, totalizare, agregare, mpachetare (n formate accesibile interfeelor de
analiz utilizate). Tot aici se gsesc date avnd o anumit vechime (civa ani), n form detaliat.
Metadatele descriu datele coninute n depozitul de date i modul n care ele sunt obinute i
stocate. Prin metadate se precizeaz structura datelor, proveniena lor, regulile de transformare, de
agregare i de calcul. Ele sunt utilizate ori de cte ori se utilizeaz depozitul de date: la ncrcarea
datelor, la consultare, la actualizare, adic pe parcursul ntregului ciclu de via al depozitului.
Figura 7. Arhitectura pe componente a depozitelor de date
Not. Aceast structur a datelor n DD este dinamic, datele intr n depozitul de date,
circul pe diverse niveluri, i schimb forma i poziia, i schimb destinaia.
- 18 -
Sursele de date pentru depozitul de date sunt: datele operaionale curente (baze de date
i/sau fiiere din sistemul informatic operaional al organizaiei), datele vechi arhivate, datele
externe (baze de date i fiiere din sistemele informatice ale altor organizaii).
Construirea depozitului de date, pornind de la sursele de date, presupune parcurgerea unor
etape n cadrul unui proces de transformare:
extragerea datelor din datele operaionale sau din surse externe, urmat de copierea lor n
depozitul de date. Acest proces trebuie, cel mai adesea, s transforme datele n structura
i formatul intern al depozitului;
filtrarea datelor, pentru a exista certitudinea c datele sunt corecte i pot fi utilizate
pentru luarea deciziilor;
ncrcarea datelor corecte n depozitul de date;
agregarea datelor: totaluri precalculate, subtotaluri, valori medii, sume etc., care se
preconizeaz c vor fi cerute i folosite de utilizatori. Aceste agregri sunt stocate n
depozitul de date mpreun cu datele importate din sursele interne i externe.
Interfeele de analiz sunt produse software care implementeaz tehnologii informatice
pentru extragerea i analiza datelor din depozitul de date: data mining, OLAP.
3.2. Arhitectura pe niveluri a depozitelor de date
Arhitectura pe niveluri evideniaz modul de implementare a depozitelor de date ntr-un

mediu de reea de calculatoare, pe trei straturi: inferior, mediu, superior (figura 8).
Rapoarte, analize, interogri

Strat superior
extragere
Strat mediu
Servere specializate
(OLAP, DATA MINING)
Depozite de date
transformare
Strat inferior Server de Date
Surse de date operaionale
Figura 8. Arhitectura pe niveluri a depozitelor de date
Stratul inferior (bottom tier) este format din serverul depozitului de date i este, n cele mai
multe cazuri, un sistem de baze de date relaionale. Datele care provin din bazele de date
operaionale i din sursele externe (de exemplu, date referitoare la profilul clientului, date furnizate
de consultani externi, rezultatele unor sondaje) sunt extrase utiliznd programe de tip interfa
(gateways), care colaboreaz cu SGBD i permite programelor client s genereze cod (de obicei
SQL) pentru a fi executat de server. Exemple de astfel de interfee: ODBC (Open DataBase
- 19 -
Connection), OLE (Open Linking and Embedding), JDBC (Java DataBase Connection). n acest
fel, datele sunt extrase, filtrate, transformate i ncrcate n depozitul de date. mprosptarea datelor
din depozitul de date se face pe msura trecerii timpului (lunar, trimestrial, anual).
Stratul mediu (middle tier) este bazat pe un server specializat, care poate fi: OLAP (bazat pe
modelul relaional ROLAP sau pe modelul multidimensional - MOLAP), data mining (extrageri
de cunotine din date i analize statistice superioare). De multe ori acest strat este inclus n SGBD
relaional (exemplu Oracle, DB2).
Stratul superior (top tier) este nivelul client care conine interfee pentru generarea
interogrilor, a rapoartelor, pentru analiza superioar a datelor.
3.3. Arhitectura depozitelor de date din punctul de vedere funcional
Aceast arhitectur mparte depozitul de date n trei module (niveluri) distincte: modulul
operaional, modulul central al depozitului de date i modulul strategic de afaceri (figura 9).
Modulul operaional - reprezentat de datele companiei care sunt de obicei pstrate sub
form diferit la locaii diferite. Aceste date pot proveni de la aplicaii sau de la sisteme distribuite
din cadrul companiilor cum ar fi sisteme de gestiune a comenzilor, de eliberare a facturilor, de
contabilitate financiar, de gestiune a stocurilor, salarizare etc. Indiferent de originea lor, datele
trebuie s fie colectate i aduse ntr-o form consistent pentru a putea fi folosite. Acest proces de
transformare a datelor reprezint baza pe care se construiete un depozit de date consistent, de nalt
calitate. Transformarea datelor presupune un proces de extragere, condiionare, curare, fuziune,
validare i ncrcare.
Modulul central al depozitului de date reprezentat de SGBD, de serverul pe care acesta
ruleaz i de modul n care este implementat depozitul. Exist n acest moment dou tendine: una
ar fi implementarea unui sistem distribuit, descentralizat unde datele sunt pstrate n concentrri de
date independente (Independent Data Marts) fiecare coninnd datele relevante pentru un anumit
aspect al operaiilor unei instituii, iar a doua posibilitate ar fi implementarea unei surse de date
unice, centralizate la care au acces utilizatorii din toate departamentele respectivei instituii.
Sisteme IA
Modulul Extragerea i procesarea datelor pentru analiz

Strategic Utilitare pentru accesul la date
Modulul Data Marts

Central Replicare i distribuire
Depozitul de date central
Modulul Extragere, Transformare i ncrcare (ETI)

Operaional Date operaionale: secveniale, nerelaionale, relaionale, fiiere,
surse externe
Sisteme operaionale, sisteme

informatice integrate
Figura 9. Arhitectura funcional a depozitelor de date
- 20 -
Modulul strategic de afaceri - valoarea final a unui depozit de date este determinat de
avantajele pe care le ofer utilizatorului n diferite procese de luare a deciziilor i analiz. Prin
folosirea diferitelor modaliti de acces la informaie i a tehnologiilor de procesare disponibile,
utilizatorii pot obine informaii care i vor ajuta n procesele de stabilire a strategiei firmei. La
ultimul nivel al arhitecturii, datele sunt pregtite pentru interpretare i analiz cu ajutorul
instrumentelor specifice cum ar fi: instrumente de realizare a graficelor, prezentri, rapoarte
dinamice, navigatoare (browser Web), instrumente de vizualizare a datelor.
Arhitectura funcional a depozitelor de date prezentat mai sus permite proiectarea i
implementarea unor diverse tipuri de depozite de date n funcie de cerinele de afaceri, resursele
disponibile i posibilitile de realizare.
4. Tipuri de depozite de date
Depozitele de date se pot clasifica n funcie de: aria de cuprindere, de procesele

decizionale pentru care a fost proiectat i de modelul de date implementat.
4.1. Tipuri de depozite de date n funcie de aria de cuprindere
n funcie de aria de cuprindere se ntlnesc trei tipuri de depozite de date: depozite la nivelul
organizaiei (Enterprise Warehouse), concentrri de date (Data Marts), depozite virtuale de date
(Virtual Data warehouse).
Depozitul la nivel de organizaie colecteaz toate informaiile despre subiectele care privesc
ntreaga activitate a unei companii i furnizeaz un volum foarte mare de date. De regul conine
date detaliate, dar i date agregate, iar ordinul de mrime este de peste 5 TB. Un astfel de depozit de
date poate fi implementat pe servere dedicate, pe platforme cu arhitecturi paralele sau pe maini de
baze de date. Acestea necesit cheltuieli mari i mult timp (ani) pentru modelare, proiectare i
realizare.
Concentrrile de date conin un subset al volumului de date din organizaie, specific unui
grup de utilizatori (unui compartiment). Domeniul este limitat la subiecte specifice. De exemplu,
pentru activitatea de marketing se limiteaz subiectele la clieni, produse, vnzri. Datele coninute
sunt de obicei agregate. Concentrrile de date sunt implementate pe servere departamentale sau pe
serverele de baze de date existente n cadrul organizaiei. Ciclul de implementare al unei concentrri
de date este msurat n sptmni sau luni sau ani. Ca atare, un data mart poate fi considerat un
subansamblu al unui depozit de date mai uor de construit i ntreinut i mai ieftin [INMO99].
Depozitul virtual este un set de vederi (views) asupra bazelor de date operaionale. Pentru
eficiena procesrilor interogrilor, numai unele din vederile de agregare pot fi materializate. Un
depozit virtual este uor de construit, dar problema extragerii i prelucrrii datelor revine n mod
exclusiv serverului de baze de date, ceea ce poate conduce la un timp de prelucrare mare, ns se
elimin necesitatea stocrii datelor ntr-un depozit real [HOLL00]. Aceast variant se recomand a
fi aplicat n cazul n care volumul de date necesar este mic, de mii de nregistrri. ns dac se
depete acest interval, timpul de extragere a datelor crete semnificativ i recomandabil ar fi s se
combine soluia de depozit virtual cu stocarea datelor agregate separat ntr-un data mart sau depozit
de date real.
- 21 -
4.2. Tipuri de depozite de date n funcie de procesele decizionale pentru care au fost
proiectate
Aceast clasificare a depozitelor de date este propus n lucrarea [POWE00] i mparte

tipologia depozitelor de date n funcie de suportul decizional oferit.
Depozitul de date de tip organizaional sau galactic (Galactic Data Warehouse - GDW)
reprezint un tip de depozit centralizat, cu o arie de cuprindere extins avnd drept obiectiv
integrarea i prelucrarea datelor la toate nivelurile organizaiei, att la nivelul departamentelor ct i
al ntregii organizaii.
Depozitul de date orientat pe procese de afacere (Business Process Data Warehouse -
BPDW) reprezint un tip de depozit specializat, orientat pe satisfacerea cerinelor de afaceri i a
proceselor de afaceri.
Depozitul de date departamental (Departamental Data Warehouse - DDW) reprezint un tip
de depozit orientat pe departamente, avnd drept obiectiv integrarea i prelucrarea datelor din
fiecare departament n parte.
Concentrri de date de tip proces de afaceri (Business Process Data Mart - BPDM)
reprezint un tip de depozit specializat, orientat pe satisfacerea unei anumite cerine de afaceri i a
unui singur proces de afaceri.
Concentrri de date departamentale (Departamental Data Mart - DDM) reprezint un tip de
depozit specializat, cu o arie de cuprindere limitat la un anumit departament, avnd drept obiectiv
integrarea i prelucrarea datelor specifice activitilor acestuia.
4.3. Tipuri de depozite de date n funcie de modelul de date implementat
n funcie de modelul de date implementat sunt identificate urmtoarele tipuri de depozite:

relaionale, multidimensionale i hibride.
Depozitele de date relaionale utilizeaz modelul relaional al datelor i se recomand a se
utiliza n cazul n care datele provin dintr-un SGBD relaional, iar depozitul de date este gestionat
de ctre acesta sau este implementat ca un depozit de date virtual. n acest caz, datele sunt stocate
ntr-o structur denormalizat cum ar fi o schem stea sau una din variantele sale; o baz de date
normalizat nu este potrivit din punctul de vedere al performanelor.
Depozitele de date multidimensionale utilizeaz modelul multidimensional al datelor i n
acest caz datele sunt stocate pe un server dedicat, denumit server multidimensional. n acest caz
putem vorbi de un depozit de date format din obiecte multidimensionale asupra crora pot fi
aplicate direct operaiile multidimensionale. Sarcina realizrii acestor operaii cade n seama
serverului multidimensional. Datele sunt extrase din surse diverse (baze de date relaionale, fiiere),
transformate i ncrcate n cubul de date, agregate pe diverse niveluri, preprocesate i pregtite
pentru analiz. Este varianta optim datorit avantajelor oferite: capacitatea de procesare a unui
volum mare de date, existena procesului ETI pentru transformarea i ncrcarea datelor,
implementarea operaiilor la nivel de server multidimensional optimizat pentru analiz.
Depozitele de date hibride utilizeaz modelul multidimensional pentru stocarea datelor
istorice i separat un model relaional pentru datele curente care urmeaz a fi transformate i
ncrcate n depozit. n acest fel se pot analiza toate datele existente la nivelul organizaiei.
- 22 -
5. Aspecte comparative privind organizarea datelor n baze de date i n

depozite de date
Depozitele de date impun condiii de realizare diferite fa de bazele de date relaionale.

Dintre aceste diferene se pot meniona urmtoarele:
Condiii de utilizare diferite. Depozitele de date sunt proiectate pentru analize ad-hoc i
rezultatele nu sunt cunoscute dinainte, iar modelul datelor este optimizat pentru a realiza o mare
varietate de interogri. n schimb sistemele tranzacionale suport numai anumite operaii pentru
care au fost proiectate. Sistemele de baze de date relaionale sunt adecvate aplicaiilor curente de
gestiune i au ca obiectiv execuia on-line a tranzaciilor i proceselor de interogare (sunt sisteme
tip OLTP - OnLine Transaction Processing). Aceste sisteme implementeaz toate operaiile zilnice
dintr-o organizaie. Sistemele cu depozite de date servesc utilizatorilor sau specialitilor n
domeniul analizei datelor i lurii deciziilor, pot organiza i prezenta datele n formate variate, n
ordinea solicitrilor, de la diferii utilizatori (sunt sisteme tip OLAP OnLine Analytical
Processing).
Actualizarea i accesul la date. Datele din depozite sunt actualizate regulat (de regul
sptmnal sau lunar) cu ajutorul procesului de extragere, transformare i ncrcare automat (ETI).
Utilizatorii finali nu pot modifica (actualiza) direct datele. n sistemele tranzacionale utilizatorii
finali sunt cei care actualizeaz datele astfel nct s se reflecte starea fiecrei tranzacii din
organizaie. O baz de date este proiectat pornind de la sarcini i activiti cunoscute: indexarea,
utilizarea cheilor, cutarea unor nregistrri specifice, optimizarea interogrilor. Interogrile unui
depozit de date sunt adesea complexe, implicnd calcule asupra unor grupuri mari de date cu
totalizri pe diferite niveluri, ceea ce presupune activiti speciale de organizare a datelor i de
acces la acesta. O baz de date presupune procesarea concurent a tranzaciilor multiple. Controlul
concurenei pentru depozitele de date este mult mai simplu de realizat deoarece se aplic doar
pentru citire.
Surse de date diferite. n cazul bazelor de date sursele de date sunt tranzaciile atomice, iar
accesul este de tip citire i scriere. n cazul depozitelor de date sursele de date sunt bazele de date
operaionale, iar accesul este cel mai adesea de tip citire pentru interogri complexe.
Operaii tipice. O interogare a depozitelor de date poate parcurge mii sau chiar milioane de
nregistrri (de exemplu pentru a analiza totalul vnzrilor din luna trecut pentru toi clienii
existeni). n schimb, o operaie tranzacional afecteaz o singur nregistrare sau un numr limitat
de nregistrri. Depozitele de date sunt construite special pentru sprijinirea lurii deciziilor. Acestea
au ca obiectiv regruparea datelor, agregarea i sintetizarea lor, organizarea i coordonarea
informaiilor provenind din surse diferite, integrarea i stocare acestora pentru a da decidenilor o
imagine adecvat care s permit regsirea i analiza eficace a informaiilor necesare. Din acest
motiv interogrile obinuite ntr-un depozit de date sunt mai complexe i mai variate dect cele din
bazele de date. Acestea se aplic asupra unor volume foarte mari de date i presupun calcule
complexe (analiza tendinei, medii, dispersii etc.), care necesit adesea agregri.
Date istorice. Bazele de date din sistemele operaionale conin date curente, detaliate, care
trebuie actualizate i interogate rapid, n condiii de deplin securitate, constituind suportul
sistemelor informaionale de prelucrare a tranzaciilor. Depozitele de date gestioneaz date istorice,
furniznd faciliti pentru sintetizare i agregare, precum i pentru stocarea i gestionarea
informaiilor cu diferite niveluri de granularitate. Aceste aspecte fac ca datele s fie uor utilizate de
ctre decideni, mai ales n tactica i strategia organizaiei.
Modelul utilizat. n depozitele de date se folosete forma denormalizat (cum este schema
stea) pentru optimizarea operaiilor, fa de forma normalizat a datelor din modelul relaional care
optimizeaz operaiile de adugare/modificare/terge i garanteaz consistena datelor. O ultim i
controversat diferen ntre cele dou tipuri de modele este modul de abordare a datelor. Esena
unui model multidimensional de calitate sporit este alegerea unui set de dimensiuni ct mai
apropiate de cele naturale i de perspectiva utilizatorului. Este folositor s avem o analiz
- 23 -
relaional a datelor nainte de a ncepe analiza dimensional deoarece echipa de proiectani a

depozitului de date va nelege datele mai bine. Modelul multidimensional trebuie abordat mai mult
din perspectiva utilizatorului dect din cea a datelor.
Modelul multidimensional ofer o baz de date care este mult mai uor de consultat i de
interogat la un nivel nalt, sintetic, agregat, cu mai puine tabele i chei de administrat dect modelul
entitate - asociere.
Tabelul de mai jos descrie diferenele principale ntre prelucrarea tranzacional (modelul
relaional) i prelucrarea analitic (modelul multidimensional):
Tabel 1. Diferene ntre modelul relaional i modelul multidimensional al datelor
Criteriu Modelul relaional Modelul multidimensional

Organizarea datelor Tabela Dimensiuni, tabele de fapte,
cub de date
Procesele Operaionale Informaionale
Execuie Tranzacii Analize
Utilizatori Toate categoriile Manageri, analiti de date
Operaia tipic Actualizare Raportare i analiz
Frecvena operaiilor Zilnice Asistarea deciziei
Caracterul datelor Curente Istorice
Nivelul de sintez Primitive, detaliere Sintetizare, consolidare
Acces Citire, scriere Citire
Focalizare Culegere date Furnizare informaii
Sursa de date este Validat Filtrat, transformat
Volum de date Redus, de ordinul GB Mare, de ordinul TB
Prioriti Performane, disponibilitate Flexibilitate, autonomie
Software necesar SGBD Specializat, SGBD
Ca o asemnare, att bazele de date ct i depozitele de date conin cantiti mari de date
structurate care pot fi consultate rapid, prin structuri de acces optimizate i se bazeaz, n
majoritatea cazurilor, pe tehnologia relaional.
- 24 -
REALIZAREA DEPOZITELOR DE DATE
Realizarea depozitelor de date trebuie privit n contextul realizrii sistemelor destinate Inteligenei
Afacerii, care necesit modele de analiz i proiectare diferite, abordri specifice ale ciclului de dezvoltare
care s se concentreze pe cerinele de afaceri ale organizaiei. Aceste sistemele sunt orientate mai mult spre
oportunitile de afaceri dect spre cerinele sau nevoile curente i trebuie s ofere suport decizional la nivel
departamental sau chiar la nivelul ntregii organizaii n funcie de scopul pentru care au fost proiectate.
Cuvinte cheie: realizarea depozitelor de date, metodologii de realizare a depozitelor de date, procesul de
extragere, transformare i ncrcare a datelor.
1. Considerente privind realizarea depozitelor de date
La realizarea unui depozit de date trebuie avute n vedere o serie de aspecte preliminare care
condiioneaz atingerea obiectivelor pentru care acesta este destinat.
Astfel, deoarece activitatea de realizare a unui depozit de date consum importante resurse,
este necesar s se elaboreze mai nti o analiz economic, pentru a determina msura n care
depozitul de date este necesar i eficient. Din aceast analiz economic se va vedea dac depozitul
de date satisface urmtoarele cerine: furnizeaz avantaje competitive oferind informaii relevante,
pe baza crora se pot msura performanele i se pot face ajustri critice pentru a ctiga n faa
concurenei; faciliteaz gestiunea relaiilor cu clienii prin furnizarea unei vederi consistente despre
clienii i produsele comercializate de organizaie, pe toate departamentele; determin reducerea
costurilor prin evidenierea tendinelor, direciilor i excepiilor pe perioade lungi de timp;
determin creterea productivitii prin obinerea rapid i eficient de informaii care descriu cu
acuratee organizaia.
1.1. Modaliti de realizare a depozitelor de date
Realizarea depozitelor de date este condiionat de o serie de cerine specifice sistemelor de

Inteligena Afacerii, iar ciclul de dezvoltare al acestor sisteme i implicit al depozitelor de date, este
iterativ, orientat spre evaluarea i mbuntirea versiunilor succesive i nu spre o livrare de
proporii a unei singure versiuni.
Datorit acestor particulariti la realizarea depozitelor de date se pot lua n considerare
diferite vederi de lucru:
analiza cerinelor decizionale ncepnd cu nivelurile superioare i continund cu
nivelurile departamentale (top-down view) care permite selectarea informaiilor relevante
- 25 -
necesare n depozitul de date, informaii care reprezint un sprijin decizional pe toate

nivelurile de management implicate;
analiza datelor surs (data source view) care exprim informaiile culese, stocate i
gestionate de sistemele operaionale. Aceste informaii pot fi documentate pe diferite
niveluri de detaliere i acuratee, de la colecii individuale de date surs pn la colecii
de date integrate;
analiza i proiectarea schemelor depozitului de date (data warehouse view) care are n
vedere identificarea tabelelor de fapte i a tabelelor dimensiune. Se reprezint
informaiile care sunt stocate n depozitele de date, incluznd contorizri i totaluri
precalculate, precum i informaiile referitoare la surse, date calendaristice, origine,
adugate pentru a furniza contextul istoric;
analiza i proiectarea interogrilor (business query view) ofer o perspectiv din punctul
de vedere al utilizatorului asupra informaiilor oferite n urma analizei datelor din
depozitul de date.
n ceea ce privete abordarea activitilor de realizare a depozitului de date se alege una
dintre variantele:
realizarea de sus n jos (top-down) care pornete cu proiectarea i planificarea complet.
Aceast abordare se utilizeaz n cazul n care tehnologiile utilizate sunt bine cunoscute
i problemele economice care trebuie rezolvate sunt clare i bine nelese. Dezvoltarea
top-down a unui depozit de date constituie o soluie sistemic i minimalizeaz
integrarea problemelor. Soluia este scump, solicit timp ndelungat pentru dezvoltare i
i lipsete flexibilitatea determinat de dificultile care pot aprea la realizarea
modelelor de date pentru ntreaga organizaie;
realizarea de jos n sus (bottom-up) pornete cu experimente i prototipuri. Aceasta
abordare este utilizat la nceputul stadiului de modelare i de dezvoltare tehnologic.
Permite unei organizaii s mearg nainte cu cheltuieli considerabil mai mici i s
evalueze beneficiile tehnologiei nainte de a face angajamente semnificative n aceast
direcie. Abordarea bottom-up n proiectarea, implementarea i dezvoltarea
concentrrilor de date (data marts) independente furnizeaz flexibilitate, costuri sczute
i recuperarea rapid a investiiei. Soluia poate determina probleme, cnd se ncearc
integrarea ntr-un depozit de date consistent la nivel de organizaie;
realizarea mixt presupune c o organizaie poate exploata caracterul planificat i
strategic al abordrii top-down att timp ct reine avantajele implementrii rapide i
oportune a aplicaiilor dup abordarea bottom-up.
1.2. Metodologii utilizate la realizarea depozitelor de date
Privind depozitele de date ca orice sistem informatic integrat de mari dimensiuni, putem
utiliza la realizarea acestora metodologiile existente adaptate la cerinele de utilizare a sistemelor de
Inteligena Afacerii.
Din punctul de vedere al ciclului de via putem aplica dou tipuri de metode: metoda n
cascad i metoda n spiral. Metoda n cascad presupune o analiz structurat i sistematic pe
fiecare etap. Metoda n spiral implic generarea rapid de sisteme funcionale din ce n ce mai
complete, la intervale scurte, ntre dou versiuni succesive. Acest lucru constituie un atu important
pentru realizarea depozitelor de date, pentru c intervalul de finalizare este scurt, schimbrile pot fi
fcute imediat i noile tehnologii pot fi adaptate rapid i uor.
Din punctul de vedere al modului de abordare putem aplica att metodologii structurate ct
i metodologii orientate-obiect.
Metodologii cu abordare structurat (descrise pe larg n [LUNG05b]) presupun
diviziunea n subsisteme pe baza funciilor identificate - abordarea funcional, care structureaz
- 26 -
sistemul pornind de la prelucrrile pe care le sufer datele, sau n funcie de date - abordarea bazat
pe date, care structureaz sistemul pornind de la structura datelor utilizate i de la relaiile care
exist ntre acestea. Aceste metodologii propun modelarea datelor separat de modelarea
procedurilor. Din acest punct de vedere depozitul de date poate fi realizat pe dou niveluri: logic
n care se modeleaz schemele depozitului de date i fizic n care este realizat structura tehnic i
operaional a acestuia.
Aceast descompunere pe cele dou niveluri poate fi un punct de plecare n abordarea unui
depozit de date n ceea ce privete separarea i delimitarea funciilor acestuia, identificarea
subsistemelor i a componentelor sale. Din acest punct de vedere, avantajele utilizrii modelelor
structurate n realizarea depozitelor de date ar fi legate de realizarea modular prin divizarea pe
componente i reducerea timpului de implementare prin posibilitatea realizrii paralele a
componentelor identificate.
Dezavantajele utilizrii acestor metode n realizarea depozitelor de date pot fi cauzate de
rigiditatea modelelor n sensul c divizarea i realizarea modular pot duce la pierderea privirii de
ansamblu la un moment dat, iar cerinele de afaceri pentru care acesta a fost conceput nu sunt
modelate n interaciune cu funciile i datele.
Printre metodologiile structurate care pot fi aplicate la realizarea depozitelor de date putem
meniona: Structured System Analysis and Design Methodology (SSADM elaborat la propunerea
Guvernului britanic), Rapid Application Development (RAD), AXIAL elaborat de firma IBM,
Custom Development Method (CDM elaborat de corporaia Oracle).
Metodologiile orientate-obiect (OO) bazate pe conceptele de obiect i clas permit
utilizarea a trei tipuri diferite de modele pentru realizarea unui depozit de date: modelul static prin
care se modeleaz obiectele i relaiile lor n cadrul depozitului; modelul dinamic sunt descrise
interaciunile dintre obiecte; modelul funcional prin care se realizeaz transformarea valorii
datelor cu ajutorul operaiilor i proceselor.
Avantajele aplicrii metodologiilor orientate-obiect pentru realizarea depozitelor de date
deriv tocmai din posibilitatea de a modela unitar att funciile ct i datele, de a surprinde asupra
aceluiai obiect att caracteristicile statice, funcionale ct i dinamice, prin prisma interaciunilor
cu alte obiecte. n acest fel pot fi modelate i cerinele de afaceri n interaciune cu obiectele.
Un alt aspect este acela c metodologiile orientate-obiect acord o mare importan
reutilizrii pachetelor i a componentelor. Astfel eventualele schimbri identificate n utilizarea
depozitelor se pot realiza cu uurin prin modificarea structurilor deja implementate, fr a fi
necesar reproiectarea DD.
n concluzie, putem spune c avantajele aduse de metodologiile orientate-obiect fa de cele
structurate recomand abordarea obiectual n cazul realizrii depozitelor de date.
n ceea ce privete metodologiile orientate-obiect, prin elaborarea standardului UML s-au
nlturat o mare parte dintre diferenele existente ntre diferitele tipuri de abordri i se poate aplica
acest standard de modelare pentru realizarea depozitelor de date. Astfel se poate adapta setul
standard de notaii i diagrame existente n UML innd cont de urmtoarele aspecte:
condiiile de utilizare depozitele de date sunt proiectate pentru analize
multidimensionale i extrageri de date, din acest motiv trebuie s fie optimizate pentru a
realiza o mare varietate de interogri;
actualizarea datelor datele din depozite sunt actualizate la intervale de timp regulate
(sptmnal, lunar) cu ajutorul procesului ETI. Utilizatorii finali nu pot modifica
(actualiza) direct datele;
modelul de date utilizat - n depozitele de date se folosete forma denormalizat (schema
stea) pentru optimizarea operaiilor de interogare, fa de sistemele OLTP care folosesc
forma normalizat a datelor pentru a optimiza operaiile de adugare/modificare/tergere
i pentru a garanta consistena datelor. Esena unui model dimensional de calitate sporit
const n alegerea unui set de dimensiuni ct mai apropiate de cele naturale i de
perspectiva utilizatorului;
- 27 -
operaiile tipice realizate utilizarea depozitelor implic schimbri de perspectiv,

selecii de dimensiuni, rotaii n cadrul acestora, deci trebuie modelat distinct accesul la
date.
Modelarea depozitelor de date cu ajutorul metodologiei orientateobiect presupune
utilizarea conceptelor fundamentale ale paradigmei OO (clase, obiecte, ncapsulare, agregare,
motenire, polimorfism, abstractizare) n realizarea modelului att din punctul de vedere static
(structural), ct i dinamic.
2. Etape de realizare a depozitelor de date
Din analiza diferitelor metodologii de realizare a depozitelor de date se pot deduce o serie de
activiti, care pot fi sintetizate n necesitatea parcurgerii urmtorilor pai/etape: 1. strategia de
realizare; 2. planificarea (modelarea) cerinelor; 3. implementarea; 4. exploatarea. Aceti pai vor
fi prezentai n continuare.
2.1. Strategia de realizare a depozitelor de date
Strategia de realizare a depozitelor de date este primul pas care trebuie parcurs i presupune
elaborarea urmtoarelor elemente:
planul preliminar al depozitului de date. n cadrul unui proiect de DD nu pot fi
satisfcute chiar toate cerinele utilizatorilor, deoarece ar rezulta un sistem uria, greu de
gestionat. De aceea, de regul se face o list cu prioritile cerinelor utilizatorilor, iar
aceste cerine vor fi ataate diferitelor componente ale depozitului, care vor fi dezvoltate
iterativ. Natura iterativ a proiectului permite echipei de dezvoltare s extind
funcionalitile depozitului de date ntr-o manier uor de controlat;
arhitectura preliminar a depozitului de date. Se definete arhitectura global a
depozitului de date pentru proiectul pilot, precum i versiunile care vor urma pentru a
asigura scalabilitatea sistemului. Prin analizarea posibilelor arhitecturi de depozite de
date, analitii de sistem vor putea s determine o mulime de alte componente care vor fi
necesare pentru fiecare versiune;
lista preliminar a mediilor de dezvoltare a depozitului de date. Exist un numr destul
de mare de medii de dezvoltare pentru depozitele de date i, de aceea, se recomand
alctuirea unei liste sintetice cu cele care pot fi de folos n cadrul organizaiei. Alegerea
unor produse informatice standardizate va reduce problemele de integrare i va minimiza
efortul de nvare att pentru echipa de dezvoltare, ct i pentru utilizatori.
Etapele necesare pentru a duce la ndeplinire strategia depozitelor de date sunt urmtoarele:
determinarea contextului organizaional, realizarea unei vederi preliminare de ansamblu asupra
cerinelor, realizarea auditului preliminar referitor la sistemele surs, identificarea surselor de
date externe, definirea versiunilor depozitului de date, definirea arhitecturii preliminare a
depozitului de date i evaluarea mediilor de dezvoltare a depozitului de date.
Fiecare etap poate fi ndeplinit ntr-un interval de timp de aproximativ trei pn la cinci
sptmni, n funcie de disponibilitatea resurselor i mrimea organizaiei.
1. Determinarea contextului organizaional. nelegerea profund a organizaiei ajut la
stabilirea contextului n care se desfoar proiectul i poate evidenia aspectele culturii
organizaionale, care pot uura sau ngreuna proiectul depozitului de date. Rspunsurile la
ntrebrile legate de organizaie se obin de obicei de la susintorul proiectului, managerul IT sau
managerul de proiect. ntrebrile tipice sunt urmtoarele:
- 28 -
Cine este finanatorul (susintorul) proiectului n acest caz? Susintorul proiectului

stabilete domeniul proiectului DD. Acesta joac un rol foarte important n stabilirea relaiilor de
lucru ntre membrii echipei de dezvoltare, mai ales dac sunt implicai i teri. Accesul facil la
datele depozitului poate fi limitat de domeniul organizaional, care se afl sub controlul
susintorului proiectului.
Care sunt grupurile IT din organizaie care sunt implicate n proiectul de realizare a
depozitului de date? Deoarece un depozit de date este o dorin a organizaiei, grupurile IT din
interior vor fi ntotdeauna implicate n acest efort. Trebuie tiut care sunt relaiile de lucru dintre ele
i care este gradul de ocupare. Dac, de exemplu, departamentul IT este foarte preocupat cu
mbuntirea sistemelor operaionale, este foarte puin probabil ca un depozit de date s fie pe lista
de prioriti.
Care sunt rolurile i responsabilitile fiecruia dintre cei care au legtur cu proiectul?
Este important s definim rolul i responsabilitile fiecrei persoane implicate. n acest fel se
stabilesc limite i obiective, iar comunicarea i nelegerea proiectului se mbuntesc.
2. Realizarea unei viziuni preliminare de ansamblu asupra cerinelor. n aceast etap se
obine un inventar al cerinelor utilizatorilor prin interviuri, individuale sau de grup, realizate n
comunitatea utilizatorilor finali. Dac este posibil, se recomand obinerea de formate referitoare la
rapoartele curente folosite de conducere. Inventarul cerinelor furnizeaz aria de ntindere a
informaiilor pe care se ateapt s le ofere un viitor depozit de date.
Obiectivul principal este acela de a nelege nevoile utilizatorilor, destul de mult, astfel nct
s poat fi ierarhizate. Aceasta este o informaie critic care determin aria fiecrui segment din
depozitul de date.
Exemple de ntrebri care pot constitui repere ntr-o discuie cu potenialii utilizatori ai
depozitului de date sunt prezentate n continuare.
Funciile. Care este misiunea grupului sau a departamentului? Cum procedai ca s v
ndeplinii misiunea? Cum tii dac ai atins obiectivele fixate? Care sunt indicatorii de
performan pe care i folosii i care sunt factorii critici de succes?
Clienii. Cum v grupai sau v clasificai clienii? Se modific aceast grupare de-a lungul
timpului? Modul de grupare afecteaz modul n care v tratai clienii? Ce fel de informaii pstrai
despre fiecare tip de client? Ce informaii demografice folosii? Avei nevoie s pstrai date despre
fiecare client n parte?
Profitul. La ce nivel msurai profitabilitatea n grupul sau departamentul dvs.? Pe agent? Pe
client? Pe produs? Pe regiune? La ce nivel de detaliere sunt nregistrate costurile i veniturile? Ce
fel de rapoarte privind profitabilitatea folosii actualmente?
Sistemele. Ce sisteme folosii ca parte a muncii dvs.? Ce fel de transformri manuale de date
trebuie s facei atunci cnd datele nu sunt disponibile?
Timpul. Pentru cte luni sau ani avei nevoie s fie pstrate datele? Analizai performanele
pe durata unui an? La ce nivel de detaliere avei nevoie s fie prezentate graficele? Zilnic?
Sptmnal? Lunar? Trimestrial? Anual? Ct de repede avei nevoie de date?
Interogrile i rapoartele. Ce rapoarte folosii acum? Ce informaii folosii de fapt din
fiecare raport pe care l primii? Putem obine machete ale acestor rapoarte? Ct de des se produc
aceste rapoarte? Le primii destul de frecvent sau timpul de ateptare este prea mare? Cine produce
rapoartele pe care le primii? Cine sunt cei pentru care alctuii dvs. rapoartele?
Produsele. Ce produse vindei i cum le clasificai? Avei o ierarhie a produselor? Analizai
datele pentru toate produsele n acelai timp sau analizai datele despre fiecare produs n parte?
Cum gestionai modificrile care intervin n ierarhia produselor?
Geografia. Organizaia opereaz n mai mult de o singur zon? V mprii piaa n zone
geografice? Pstrai datele despre vnzri pe fiecare regiune n parte?
La realizarea interviurilor pentru dezvoltarea depozitelor de date, este indicat s se ia n
considerare urmtoarele recomandri:
- 29 -
trebuie evitat s se fac delimitri clare privind aria depozitelor de date. Uneori se va
constata c o parte dintre situaiile de ieire de care au nevoie utilizatorii nu pot fi
realizate pe baza datelor existente n sistemele operaionale;
trebuie pstrat clar obiectivul interviului i nu trebuie s ne abatem de la el: realizarea
unui inventar al cerinelor i nu o nelegere foarte detaliat a lor;
echipa care realizeaz interviurile trebuie s fie mic. Echipa ideal este format din doi
oameni: unul pune ntrebrile i cellalt noteaz rspunsurile;
se poate nregistra interviul, dac persoana este de acord, ascultarea ulterioar a discuiei
putnd fi de mare ajutor;
stilul de interviu va depinde de persoana intervievat. Managerii de nivel mediu sunt cei
care lucreaz cel mai mult cu rapoartele analitice, n timp ce managerii de nivel nalt au
cerine legate de informaii cu caracter strategic.
3. Realizarea auditului preliminar referitor la sistemele surs. Este recomandabil ca echipa
de dezvoltare s obin un inventar al sistemelor surs poteniale pentru depozitul de date. n timp
ce managerul IT va furniza imaginea de ansamblu a sistemelor existente n organizaie, detaliile
pentru auditarea sistemelor surs vor fi furnizate de administratorii de sistem care ntrein sistemele
operaionale. Exemple de ntrebri tipice pentru realizarea unui astfel de audit sunt prezentate n
continuare
Arhitectura curent. Care este arhitectura tehnologic curent a organizaiei? Ce fel de
sisteme, echipamente, sisteme de gestiune a bazelor de date, reele, instrumente utilizator, interfee
de dezvoltare i de accesare a datelor se folosesc n prezent?
Relaiile ntre sistemele surs. Exist o legtur ntre diversele sisteme surs? Un sistem
furnizeaz informaii altuia? Sistemele sunt integrate ntr-un mod anume?
Faciliti de reea. Exist faciliti de reea care pot fi utilizate? Este posibil a se folosi doar
un terminal sau un microcalculator pentru a accesa sisteme operaionale diferite, din orice zon?
Calitatea datelor. Care este calitatea datelor? Ct de multe operaii de filtrare, triere,
duplicare i integrare estimai c vor fi necesare? Ce zone, tabele sau cmpuri, din sistemele actuale
sunt cunoscute pentru slaba calitate a datelor?
Documentaia. Ct documentaie este disponibil pentru sistemele surs? Ct de corecte i
de actuale sunt aceste manuale i referine? Este bine s se obin urmtoarele informaii ori de cte
ori este posibil: copii ale manualelor i instruciunilor de utilizare, structura bazelor de date, pri de
programe surs, scheme de generare a codului surs.
Mecanisme de extragere posibile. Ce mecanisme de extragere sunt posibile pentru sistemul
curent? Ce mecanisme au fost folosite nainte i care credei c vor fi mecanismele de extragere a
datelor care nu vor funciona cu sistemul actual?
4. Identificarea surselor de date externe. Organizaia poate folosi surse de date externe
pentru completarea datelor din sistemele surs interne. Astfel de surse de date externe pot fi: date de
la bnci, coduri potale, date statistice sau demografice, date de la alte organizaii, date de la agenii
de tiri sau din publicaii.
Dei datele externe reprezint o oportunitate pentru mbogirea depozitului de date, ele
prezint dificulti din cauza granularitii diferite i, de aceea, decizia n legtur cu folosirea
datelor externe trebuie s fie bine fundamentat.
5. Definirea versiunilor depozitului de date. Se recomand dezvoltarea depozitului de date
n mai multe versiuni, derulate n spiral. Disponibilitatea i calitatea datelor surs vor juca un rol
critic n finalizarea cu succes a acestei faze.
Abordarea iterativ permite gestionarea eficient a cerinelor utilizatorilor i reduce efectele
riscurilor care pot aprea. Fiecrei cerine i se atribuie un nivel de prioritate. Se face o evaluare
iniial a complexitii n funcie de numrul sistemelor surs. De asemenea, este identificat i
sistemul int. Pot fi luai n calcul mai muli factori pentru o mai bun nelegere a cerinelor
fiecrui modul. Definirea fiecrui modul este finalizat doar atunci cnd este aprobat de ctre
susintorul proiectului.
- 30 -
6. Definirea arhitecturii preliminare a depozitului de date. Trebuie s se schieze o

arhitectur preliminar pentru fiecare modul, n funcie de aria de ntindere aprobat. Este
recomandat s se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaionale i
multidimensionale, precum i instrumentele adecvate.
Depozitul de date i concentrrile de date. Se definesc aceste elemente pentru fiecare modul
n parte. Este necesar s se indice modul n care sunt legate diferite baze de date. Arhitectura trebuie
s asigure faptul c anumite concentrri de date nu sunt implementate izolat.
Numrul de utilizatori. Se specific numrul de utilizatori pentru fiecare interfa de acces la
fiecare versiune n parte.
Localizarea. Se precizeaz locul de dispunere a depozitului de date, a concentrrilor de date
i a utilizatorilor pentru fiecare modul.
7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizaia poate alege dintre
mai multe medii i interfee pentru a dezvolta depozitul de date. Important este s se selecteze
combinaia de interfee care satisfac cel mai bine cerinele organizaiei. Se vor elimina variantele
neconvenabile i se va alctui o list din care fiecare versiune va avea parte de un set de interfee
(acces la date, SGBD etc.).
2.2. Modelarea depozitelor de date
Modelarea (planificarea) unei versiuni a depozitului de date se realizeaz conform strategiei

acestuia, stabilit de ctre specialitii organizaiei. Planificarea depozitului de date detaliaz
domeniul preliminar al unei versiuni prin obinerea detaliilor despre cerinele utilizatorilor
referitoare la interogri, la construirea unei scheme iniiale a depozitului de date i la stabilirea
cmpurilor de interes din sistemele surs.
Un proiect de planificare (modelare) dureaz ntre cinci i opt sptmni, n funcie de aria
de ntindere a modulului. Evoluia proiectului variaz n funcie de: modul de participare a
personalului din ntreprindere, disponibilitatea i calitatea documentaiei sistemelor surs, modul n
care sunt rezolvate problemele care apar.
Etapele necesare pentru realizarea planificrii depozitului de date sunt urmtoarele:
alctuirea echipei, analiza cerinelor, auditarea sistemelor surs, proiectarea schemelor depozitului,
transformarea cmpurilor surs n cele destinaie, ncrcarea datelor istorice n depozit, selectarea
mediilor de dezvoltare, crearea prototipului pentru versiunea curent.
1. Alctuirea echipei de lucru. Se identific toate prile care vor fi implicate n
implementarea depozitului de date i vor fi iniiate n legtur cu proiectul. Se vor distribui copii ale
materialelor referitoare la strategia de realizare a depozitului.
Se ncepe cu organizarea intern a echipei n cazul n care este necesar o astfel de structur
formal. Fiecare membru al echipei va fi instruit privind rolul pe care l va avea n cadrul echipei
(drepturi i responsabiliti), astfel nct s poat fi stabilite termene i obiective realiste pentru
fiecare n parte.
Membrii echipei vor fi instruii cu privire la conceptele referitoare la tehnologia depozitelor
de date. Trebuie descrise activitile proiectului, precum i legturile care exist ntre diversele
activiti. Se va stabili i frecvena ntlnirilor cu toi membrii echipei, de regul sptmnal, pentru
a analiza starea n care se afl proiectul.
2. Analiza cerinelor informaionale. Analiza cerinelor informaionale se poate desfura n
paralel, n timpul planificrii depozitului de date, cu activitatea de auditare a sistemelor surs.
Obiectul analizei cerinelor l constituie nelegerea cerinelor informaionale ale decidenilor.
O analiz preliminar a fost deja efectuat n etapa de formulare a strategiei DD. n aceast
etap este revizuit aria de cuprindere a modulului depozitului de date, aa cum a fost ea definit n
documentaia strategiei. Se va finisa acest aspect prin detalierea analizei preliminare a cerinelor
decizionale. Va fi necesar s se stabileasc noi ntlniri cu reprezentanii utilizatorilor. Aria de
cuprindere a modulului va fi determinat innd cont de interogri i rapoarte, care vor putea fi
- 31 -
realizate la finalizarea modulului depozitului de date. Finanatorul proiectului trebuie s revad i s

aprobe documentaia pentru a se asigura c ateptrile conducerii organizaiei vor fi atinse. De
asemenea, vor fi documentate toate limitrile impuse de sistemele surs, iar aceste informaii vor fi
oferite auditorilor pentru a fi confirmate.
Aria de cuprindere a versiunii determin direct timpul de implementare. O arie prea mare va
face ca proiectul s nu poat fi gestionat eficient. Ca regul general, aria trebuie limitat astfel
nct versiunea s poat fi implementat ntr-o perioad de la trei pn la ase luni, de o echip de 6-
12 membri.
Uneori, este posibil ca o organizaie s treac direct la faza de planificare a depozitului de
date, fr ca n prealabil s formuleze strategia acestuia. Acest lucru se ntmpl, de obicei, atunci
cnd un grup de utilizatori preiau iniiativa realizrii depozitului de date, dup ce n prealabil i-a
sintetizat cerinele informaionale. n acest caz, anumite activiti din etapa de formulare a strategiei
vor fi etape din planificarea primei versiuni a depozitului de date: determinarea contextului
organizaional, definirea modulelor depozitului de date, definirea arhitecturii acestuia, evaluarea
instrumentelor i a mediilor de dezvoltare.
3. Auditarea sistemelor surs. Auditarea sistemelor surs trebuie s ofere o vedere de
ansamblu asupra sistemelor care pot fi surse poteniale de date pentru depozitul de date. Auditarea
preliminar a sistemelor surs, realizat deja n cadrul formulrii strategiei depozitului de date,
trebuie s ofere o list complet a surselor de date.
Sistemele surse de date sunt n primul rnd cele interne. Cele mai bune candidate pentru a fi
sisteme surs sunt sistemele operaionale care automatizeaz tranzaciile zilnice ale ntreprinderii.
Pe lng sistemele operaionale, mai sunt folosite ca surs de date i rapoartele financiare ale
ntreprinderii, mai ales dac interogrile i rapoartele se focalizeaz pe msurarea profitabilitii. n
cazul n care sunt disponibile i surse de date externe, ele vor putea fi integrate n depozitul de date.
Persoanele cele mai potrivite n cazul auditrii sistemelor surs sunt administratorii de baze
de date, administratorii de sistem i ali specialiti IT, care gestioneaz sisteme interne ce pot deveni
surse pentru depozitul de date. Avnd n vedere cunotinele pe care le au asupra sistemelor
existente, ei sunt cei mai n msur s aprecieze oportunitatea folosirii fiecrui sistem ca surs de
date pentru depozit. Aceste persoane sunt, de asemenea, familiarizate cu problemele legate de
calitatea datelor din diverse sisteme surs. Informaiile oferite de acetia vor fi documentate pentru
a sprijinii procesul de extragere i filtrare a datelor. Administratorii de baze de date i ceilali
specialitii IT pot oferi informaii valoroase cu privire la regulile dup care se obin rapoartele
existente pe baza datelor operaionale.
Pentru auditarea sistemelor surs trebuie realizate interviuri, individuale sau de grup, cu
specialitii IT din organizaie i se va urmri obinerea urmtoarelor documente i informaii, dac
nu au fost deja colectate n etapa de stabilire a strategiei de realizare a depozitului:
documentaia arhitecturii IT a organizaiei: diagramele arhitecturii sistemului (un model
al tuturor sistemelor informaionale existente n ntreprindere i al legturilor dintre ele),
modelul datelor ntreprinderii (un model al tuturor datelor care sunt stocate n prezent),
arhitectura reelei (diagrama care descrie configurarea reelei);
manualul tehnic i manualul de utilizare pentru fiecare sistem surs: modelele datelor i
schemele pentru toate subsistemele informatice care pot fi sisteme surs;
bazele de date: pentru fiecare sistem surs se va identifica tipul bazei de date folosite i
se vor face aprecieri asupra mrimii ei;
planurile de perspectiv: ce proiecte de dezvoltare i implementare au fost aprobate
pentru urmtoarele 6-12 luni pentru fiecare sistem surs n parte; dac schimbarea
structurii datelor va afecta preluarea datelor din sistemele surs n depozit, va aduce
eventual noi date disponibile sau vor fi pierdute o parte dintre cele existente;
sistemele de codificare: fiecare sistem surs poate folosi un alt sistem de codificare i de
aceea administratorii bazei de date trebuie s ofere informaii referitoare la: modul n
care sunt generate codurile, modul de reutilizare a codurilor, posibilitatea unificrii lor;
- 32 -
mecanismele de extragere: trebuie verificat dac datele pot fi citite sau extrase direct din
bazele de date operaionale. Pachetele de aplicaii existente i SGBD pot avea probleme,
mai ales n cazul n care structura nu este documentat.
4. Proiectarea schemelor depozitului de date. Proiectarea schemelor depozitului de date
trebuie s asigure acoperirea cerinelor informaionale ale utilizatorilor versiunii respective. Sunt
disponibile scheme rezultate din dou tipuri de modele: relaional (bazat pe normalizare) i
multidimensional (bazat pe denormalizare).
n modelarea bazat pe normalizare schema bazei de date este proiectat folosind tehnicile
de normalizare utilizate n sistemele relaionale (tranzacionale OLTP).
n modelarea multidimensional se lucreaz cu schemele: stea, fulg de zpad, constelaie,
care sunt denormalizate i conin tabele de fapte i tabele dimensiune.
5. Transformarea cmpurilor surs n cmpurile destinaie. La trecerea cmpurilor surs n
cmpurile destinaie trebuie s se stabileasc modul n care cmpurile din sistemele surs
operaionale sunt transformate n cmpuri ale depozitului de date.
Un cmp din depozitul cu date poate fi populat cu date din mai multe sisteme surs. Aceasta
este o consecin natural a rolului de integrare pe care l are depozitul de date. Spre exemplu, dac
fiecare sistem operaional va avea propriile nregistrri referitoare la clieni i produse atunci un
cmp din depozitul de date care va fi denumit Nume_client sau Denumire_produs va fi populat cu
date din mai multe sisteme.
Este posibil i situaia invers, un cmp din sistemele operaionale poate fi divizat n mai
multe cmpuri n depozitul de date. Spre exemplu, exist sisteme operaionale care nregistreaz
adresele ca linii de text cu denumirea cmpului Adresa ce poate fi mprit n mai multe cmpuri
cum ar fi: Strad, Ora, Jude.
Pentru a elimina orice confuzie, care poate aprea referitor la modul n care datele surs sunt
transformate n depozitul de date, se recomand crearea unui tabel surs-destinaie care s
evidenieze cum se transform fiecare cmp. De asemenea, trebuie s se precizeze toate regulile
care guverneaz integritatea sau divizarea datelor.
6. ncrcarea datelor istorice n depozitul de date. La ncrcarea datelor istorice n depozitul
de date trebuie avute n vedere urmtoarele aspecte:
schimbrile n structura datelor. Se va determina dac schemele tuturor sistemelor surs
au suferit modificri n timp. De exemplu, dac perioada pentru care sunt pstrate datele
n depozit este de doi ani i datele din ultimii doi ani trebuie ncrcate n depozit, echipa
trebuie s verifice dac schema a suferit modificri n aceast perioad. n caz afirmativ,
operaiunile de extragere i integrare a datelor devin mai complicate, fiecare sistem surs
putnd necesita propriul tabel surs-destinaie;
disponibilitatea datelor istorice. n mod obligatoriu trebuie s se determine dac datele
istorice sunt disponibile pentru ncrcarea lor n depozitul de date.
Aceste aspecte vor fi mult mai dificil de analizat, dac documentaia necesar lipsete sau
dac niciun specialist IT din ntreprindere nu este familiarizat cu vechile scheme de date.
7. Selectarea mediilor de dezvoltare. n aceast etap se finalizeaz alegerea produselor
software necesare pentru realizarea depozitului. Dac a fost efectuat un studiu amnunit al acestui
aspect n etapa de definire a strategiei, activitatea de selectare devine opional. Dac strategia de
realizare a depozitului nu a fost formulat atunci trebuie s se fac evaluarea n acest moment. Este
obligatoriu s se fac selecia mediilor de dezvoltare pentru ca livrarea lor s nu perturbe procesul
de dezvoltare.
8. Crearea prototipului pentru versiunea curent. Prin folosirea listei finale a mediilor de
dezvoltare se va crea prototipul depozitului de date. Realizarea i prezentarea unui prototip de
depozit de date este motivat de unul sau mai multe dintre aspectele urmtoare:
selectarea interfeelor software. Este posibil s se cear furnizorilor de tehnologii
informatice s ofere un prototip al depozitului de date pentru a-l evalua. Rezultatul
evalurii va folosi n selectarea interfeelor: produse OLAP, generatoare etc.
- 33 -
corectitudinea schemei de date. Echipa va realiza un prototip bazat pe o anumit schem

i apoi va lansa interogri sau rapoarte de prob pe baza datelor reale din sistemele surs.
Dac cerinele utilizatorilor pot fi ndeplinite folosind schema proiectat, atunci echipa
poate valida aceast schem;
validarea prototipului. Echipa de dezvoltatori va invita reprezentanii utilizatorilor s
foloseasc prototipul pentru a-i formula o prere iniial. Prototipul este primul rezultat
concret al efortului de dezvoltare. El ofer utilizatorilor ceva tangibil, pe care l pot
vedea i folosi. El permite, de asemenea, utilizatorilor s experimenteze pentru prima
dat noua tehnologie. De regul, o astfel de experien declaneaz o multitudine de
reacii pozitive i negative din partea utilizatorilor. Aceste reacii pot ghida echipa de
dezvoltare privind coreciile care trebuie efectuate. La validarea prototipului,
urmtoarele aspecte trebuie s devin clare pentru utilizatori: obiectivele ntlnirilor,
natura i sursa datelor folosite la validare, aria de cuprindere a prototipului.
2.3. Implementarea depozitelor de date
Unele dintre soluiile pentru a obine rapoartele decizionale solicitate de manageri necesit
doar programe simple de extragere a datelor, care sunt executate periodic pentru a obine datele
necesare. Alte soluii necesit executarea unei serii complexe de pai, care combin manipularea
datelor, programele de extragere, formulele de conversie.
Faza de implementare a depozitelor de date presupune parcurgerea urmtorilor pai, care vor
fi prezentai n continuare: 1. definirea ariei de cuprindere, 2. crearea planului de implementare
pentru versiunea curent, 3. implementarea propriu-zis a depozitului de date, 4. stabilirea schemei
depozitului de date, 5. metadatele din depozitul de date, 6. modul de acces la date, 7. ncrcarea
depozitului de date, 8. instruirea utilizatorilor, 9. testarea depozitului de date.
1. Definirea ariei de cuprindere a depozitului de date. n absena unui depozit de date multe
dintre cerinele decizionale sunt clasificate n categoria rapoartelor ad-hoc i, ca urmare, cele mai
multe dintre programele de extragere i prelucrare a datelor nu sunt suficient documentate i sunt
cunoscute doar de cei care le-au conceput. Astfel, se ajunge n situaia n care, n aceeai
organizaie, nu se aplic aceleai standarde pentru aceleai informaii, adic persoane diferite aplic
formule i reguli diferite pentru aceleai date.
Echipa de dezvoltare a depozitului de date trebuie s urmreasc n primul rnd
introducerea standardelor locale sau internaionale pentru manipularea datelor. n acest sens vor fi
vizate urmtoarele aspecte:
datele actuale folosite pentru obinerea rapoartelor. Aceste date trebuie s fie incluse n
procesul de auditare a sistemelor surs. Avantajul este c echipa de dezvoltare va ti din
start care cmpuri din aceste sisteme sunt mai importante;
programele actuale de extragere a datelor. Programele de extragere sunt un indiciu
valoros pentru realizarea tabelelor surs-destinaie. Astfel, ele ofer informaii valoroase
referitoare la regulile de transformare a datelor;
transformarea manual a datelor. n cazul n care exist astfel de situaii, ele trebuie
analizate cu grij pentru a se obine informaiile necesare i pentru a se elimina o parte
dintre transformrile manuale.
Este posibil ca echipa care planific depozitul de date s descopere o serie de deficiene
legate de rapoartele care se produc n organizaie. Astfel, pot fi descoperite inconsistene referitoare
la folosirea unor termeni, formule de calcul, reguli, n funcie de persoana care creeaz sau citete
raportul.
Fiecare secven de date, care este necesar pentru crearea rapoartelor solicitate de
manageri, provine din unul sau mai multe sisteme surs disponibile n ntreprindere, ns exist date
- 34 -
care nu se regsesc n sistemele surs. Limitrile impuse de datele disponibile pot fi de urmtoarele
tipuri:
secvene de date care lipsesc. O secven de date este considerat lips dac nu exist
niciun sistem surs care s fie prevzut pentru a o colecta i stoca. Cele mai frecvente
cazuri sunt cele ale datelor care nu sunt stocate, deoarece nu au nicio importan pentru
derularea zilnic a tranzaciilor, ns pot avea o mare importan pentru deciziile tactice
i strategice. De exemplu, dac sistemele de acordare a mprumuturilor bancare nu
nregistreaz domeniul de activitate n care activeaz fiecare beneficiar de credite, atunci
banca va avea probleme serioase cnd va dori s-i analizeze gradul de expunere la risc
n funcie de sectorul economic finanat, deoarece nu va putea genera un raport detaliat
pe aceast tem;
secvene de date incomplete sau opionale. Exist cazuri cnd o secven de date este
clasificat cu termenul de reinut, ns nu exist reguli care s precizeze clar c acea
secven trebuie s fie colectat i stocat sau nu. Aa se ajunge n situaia c astfel de
secvene de date sunt nregistrate doar pentru o parte dintre clieni, produse, perioade de
timp etc. Atunci cnd se dorete realizarea unei analize globale, acest lucru nu este
posibil, din cauza faptului c datele nu sunt disponibile n totalitate. De exemplu,
sistemul de acordare a mprumuturilor poate avea un cmp denumit stare_client, dar
dezvoltatorii aplicaiei l-au prevzut ca fiind un cmp opional. Astfel, doar o parte a
raportului anterior poate fi realizat i anume doar pentru clienii pentru care s-au
nregistrat valorile pentru acel cmp;
date eronate. Pot aprea date eronate cnd acestea sunt stocate n unul sau mai multe
surse de date, din una dintre urmtoarele cauze posibile: erori care au scpat la
introducerea datelor, datele nu sunt disponibile, se merge pe varianta valorilor implicite
care de fapt nu sunt corecte.
Se poate observa cum aria de cuprindere a unui depozit de date poate fi compromis de
limitrile impuse de datele din sistemele surs curente. Cele mai multe proiecte se limiteaz doar la
ceea ce ofer sistemele surs. Trebuie s lum n considerare i varianta mbuntirii sistemelor
surs n paralel cu desfurarea proiectului de realizare a depozitului de date. Echipa de dezvoltare
trebuie s identifice toate limitrile impuse de sistemele curente (auditarea), iar acest lucru va fi
utilizat n procesul de rafinare.
Un raport de auditare a sistemelor surs trebuie s conin urmtoarele componente:
lista sintetic a sistemelor surs. Aceast seciune trebuie s listeze toate sistemele
operaionale existente. Sunt oferite, pentru fiecare sistem operaional, descrieri generale
ale funcionalitilor i ale datelor, o list cu entitile cele mai importante, precum i
cmpurile eseniale. De asemenea, se pot meniona i utilizatorii actuali ai sistemelor
analizate;
secvene de date care lipsesc. n aceast seciune sunt evideniate datele care ar fi
necesare n cadrul depozitului de date, dar nu sunt disponibile n sistemele surs. Trebuie
evideniat importana datelor care lipsesc i modul cum pot fi ele obinute;
rafinarea calitii datelor. Pentru fiecare sistem operaional, trebuie identificat modul
cum poate fi mbuntit calitatea datelor;
estimarea resurselor i a efortului. Pentru fiecare sistem operaional, se poate preciza un
cost estimativ i durata de timp necesar pentru a aduga datele lips sau pentru a
mbunti calitatea datelor.
n concluzie, planificarea depozitului de date are ca scop definirea clar a ariei de cuprindere
a fiecrui modul din acesta. Combinaia dintre abordrile top-down i bottom-up ofer procesului de
planificare avantajul de a vedea problema din dou perspective complementare: cerinele
utilizatorilor i datele disponibile n sistem.
2. Crearea planului de implementare pentru versiunea curent a depozitului.
- 35 -
Dup definirea ariei de cuprindere i specificarea modului de transformare a datelor surs,

este posibil s se schieze un plan de implementare pentru versiunea curent a depozitului de date.
Pentru un astfel de plan trebuie avui n vedere urmtorii factori:
numrul sistemelor surs i mecanismele specifice de extragere a datelor. Cu ct sunt
mai multe sisteme surs, cu att procesele de extragere i integrare sunt mai multe i mai
complexe;
numrul de procese decizionale asistate. Cu ct sunt asistate mai multe procese
decizionale, cu att va fi mai mare numrul utilizatorilor care vor avea observaii privind
depozitul, referitoare la definiii de termeni, reguli care trebuie respectate etc.;
numrul de subiecte reinute n depozitul de date. Unul dintre atuurile tehnologiei
depozitelor de date este c este orientat pe subiecte. Cu ct va fi mai mare numrul
subiectelor avute n vedere, cu att va crete complexitatea versiunii, datorit numrului
sporit de tabele de fapte care vor rezulta;
dimensiunea estimat a volumului de date. Aceast mrime furnizeaz o estimare
preliminar a efortului de ncrcare i prelucrare a depozitului de date. Volumul de date
permite echipei de dezvoltare s aprecieze durata de ncrcare a depozitului de date
(numrul de nregistrri ponderat cu durata necesar pentru ncrcarea unei nregistrri);
disponibilitatea i calitatea documentaiei sistemelor surs. n cazul n care aceste
documentaii exist i sunt actualizate, munca echipei de dezvoltare va fi mult uurat;
rata de ncrcare a depozitului de date. Aceast valoare este impus de cerinele
utilizatorilor (ct de proaspete trebuie s fie datele) i este determinant pentru
proiectarea i implementarea depozitului;
disponibilitatea solicitat de utilizatori. Un depozit de date care s fie disponibil non-
stop pentru utilizatori, necesit o arhitectur specific, diferit de a unuia care trebuie s
fie disponibil, de exemplu, doar 12 ore, timp de 5 zile pe sptmn;
participarea i sprijinul compartimentului IT. Dac se poate conta pe sprijinul real al
compartimentului IT i al altor persoane implicate, atunci planul implementrii va estima
o durat mai mic de realizare.
3. Implementarea propriu-zis a depozitului de date.
Procesul de implementare a depozitului de date const de fapt din activitile legate de
implementarea fiecrei versiuni. Activitile sunt organizate pe baza rezultatelor etapei de
planificare a depozitului de date. Astfel, echipa de implementare construiete sau extinde o schem
existent a depozitului de date bazat pe proiectul schemei realizat n timpul planificrii. Echipa
construiete de asemenea subsistemele depozitului care asigur un flux constant de date valide din
sistemele operaionale n DD. Ali membri ai echipei sunt responsabili cu instalarea i configurarea
interfeelor pentru a permite utilizatorilor accesul la depozitul de date.
Un proiect de implementare a depozitului de date trebuie s dureze ntre trei i ase luni.
Progresul lucrrilor efectuate variaz n funcie de calitatea proiectrii depozitului de date, calitatea
planului de implementare, de disponibilitatea i interesul beneficiarului.
Instruirea utilizatorilor i testarea depozitului de date sunt activiti care au loc spre finalul
proiectului de implementare, nainte de instalarea definitiv. Odat instalat depozitul de date, ncep
activitile de gestionare, ntreinere zilnic i optimizare.
Procesul de implementare propriu-zis a depozitului de date presupune realizarea
urmtoarelor activiti: a) achiziia i configurarea mediului de dezvoltare, b) obinerea copiilor
coleciilor de date operaionale, c) finalizarea proiectrii schemei fizice a depozitului de date, d)
construirea sau configurarea subsistemelor de extragere i transformare, e) construirea sau
configurarea subsistemului pentru asigurarea calitii datelor, f) construirea subsistemului pentru
ncrcarea depozitului de date.
a) Achiziia i configurarea mediului de dezvoltare
Prima activitate din procesul de implementare o reprezint achiziia i configurarea mediului
de dezvoltare, care cuprinde urmtoarele aspecte: instalarea componentelor hardware, instalarea
- 36 -
sistemului de operare, instalarea i configurarea motorului pentru baze de date relaionale, instalarea
produselor software pentru DD, crearea conexiunilor n reea i stabilirea drepturilor utilizatorilor.
De obicei, depozitul de date se afl pe o main care este separat fizic de restul sistemelor
operaionale. n cazul n care depozitul de date este gestionat cu suport baz de date relaional,
SGBDR nu trebuie neaprat s fie acelai cu cel existent n sistemele operaionale. Echipa de
dezvoltare trebuie s aib la dispoziie infrastructura necesar pentru a realiza efectiv
implementarea depozitului.
b) Obinerea copiilor coleciilor de date operaionale
Uneori echipa de implementare nu are acces direct la sistemele surs operaionale. Acest
lucru este posibil mai ales n cadrul proiectelor pilot, unde conexiunea sistemelor operaionale cu
depozitul de date nu a fost nc realizat. De aceea echipa trebuie s intre n posesia copiilor
coleciilor de date operaionale pe care le va stoca pe serverul depozitului. Crearea acestor copii
poate fi automatizat prin folosirea tehnicii de replicare din tehnologia sistemelor de baze de date
distribuite.
Echipa de implementare trebuie s dispun de un mecanism de verificare a corectitudinii i
completitudinii datelor care sunt ncrcate pe serverul DD. O modalitate este aceea de a folosi
numrarea cazurilor (numrul de clieni, numrul de conturi, numrul de tranzacii etc.) care sunt
comparate cu tabelele iniiale. Utilitarele pentru verificarea calitii datelor pot sprijini echipa de
dezvoltare n activitatea de implementare a depozitului de date.
c) Finalizarea proiectrii schemei fizice a depozitului de date
Detaliile proiectrii logice i fizice ale depozitului de date din faza de planificare se transpun
ntr-o versiune final a schemei fizice, avndu-se n vedere urmtoarele aspectele specifice ale
sistemului software, care a fost ales pentru depozitul de date:
proiectarea schemei depozitului de date. Se finalizeaz proiectarea fizic a tabelelor de
fapte i a tabelelor dimensiune cu cmpurile lor specifice. Administratorul depozitului de
date poate opta pentru divizarea unei dimensiuni logice (de exemplu, client) n dou sau
mai multe dimensiuni separate (de exemplu, o dimensiune client i o dimensiune
demografie) pentru a economisi spaiul de memorare i pentru a crete performana
interogrilor;
indexarea. Se identific cea mai potrivit metod de indexare pentru tabelele i
cmpurile depozitului de date, n funcie de dimensiunea estimat a volumului de date i
de natura anticipat a interogrilor ce se vor efectua asupra depozitului de date;
parionarea. Administratorul depozitului de date poate opta ntre partiionarea tabelelor
de fapte i de dimensiuni, n funcie de mrimea lor i de posibilitile de partiionare
care sunt suportate de motorul de baze de date. Decizia de partiionare trebuie s aib n
vedere c un depozit de date partiionat este mai uor de gestionat, ns performana
interogrilor scade.
d) Construirea sau configurarea subsistemelor de extragere i transformare
Subsistemele de transformare i extragere trebuie s filtreze i s ncarce datele din sistemul
operaional n depozitul de date, apoi s le pun la dispoziia utilizatorilor. Aceste activiti nu pot fi
automatizate total, deoarece difer de la o organizaie la alta n funcie de sistemele surs, mediul de
dezvoltare i de cerinele utilizatorilor.
Subsistemul de extragere se refer la procesul de obinere a datelor necesare din coleciile de
date ale sistemului operaional, care pot fi cele originale sau doar copii ncrcate pe serverul
depozitului de date. Extragerea se poate realiza printr-o varietate de mecanisme, de la interfee
software specializate pn la programe realizate de personalul propriu.
Interfeele software oferite de diverii productori sunt capabile s documenteze procesul de
extragere prin generarea metadatelor specifice. Dezavantajul acestora este preul prea mare. De
aceea, organizaiile prefer deseori s-i dezvolte propriile lor aplicaii de extragere a datelor.
Aceast soluie este viabil n msura n care sistemele surs sunt ntr-un mediu omogen. Aplicaiile
- 37 -
pentru extragerea datelor dezvoltate n cadrul organizaiei au dezavantajul c sunt greu de ntreinut,
deoarece exist tendina ca ele s nu fie documentate la momentul dezvoltrii lor.
Subsistemul de transformare modific datele n concordan cu regulile i standardele care
au fost stabilite pentru depozitul de date. n tehnologia DD au fost identificate cteva tipuri de
transformri, care vor fi prezentate n continuare.
schimbarea formatului. Fiecare dintre cmpurile utilizate n sistemele operaionale pot
stoca date n diverse formate i tipuri. Aceste secvene individuale de date sunt
modificate n timpul procesului de transformare pentru a respecta setul standard de
formate din depozitul de date;
redundana datelor. nregistrrile din mai multe surse sunt comparate pentru a identifica
nregistrrile duplicat bazate pe valoarea cmpurilor cheie. Duplicatele sunt eliminate
pentru a crea o singur nregistrare pentru un client, un produs, un angajat sau o
tranzacie. Duplicatele de tip excepie pot fi rezolvate manual prin folosirea unui sistem
de avertizare. Tot manual se vor rezolva i nregistrrile duplicat cu valori conflictuale,
n cazul n care nu exist mecanisme clare n acest sens;
partiionarea cmpurilor. Uneori este necesar ca o secven de date din sistemul surs s
fie partiionat n unul sau mai multe cmpuri n depozitul de date. Unul dintre cele mai
des ntlnite cazuri de acest gen se refer la adresa clienilor care n sistemul surs este
memorat ntr-un singur cmp, n timp ce n depozit va fi memorat pe mai multe
cmpuri (strad, ora, zon, regiune, ar etc.);
integrarea cmpurilor. Integrarea reprezint operaiunea invers partiionrii: dou sau
mai multe cmpuri din sistemul operaional vor fi integrate n depozitul de date;
nlocuirea valorilor. Unele valori care sunt folosite n sistemele operaionale pot s nu
fie pe nelesul utilizatorilor depozitului de date. De exemplu, codurile care au un neles
specific n sistemul operaional sunt lipsite de relevan pentru manageri. Subsistemul de
transformare nlocuiete valorile originale cu valori noi care sunt utile pentru cei ce
folosesc coninutul depozitului de date;
derivarea valorilor. Estimrile, determinarea de indici i alte valori derivate pot fi
calculate folosind diverse formule. Prin calcularea i ncrcarea acestor valori n depozit,
posibilitatea ca utilizatorii s le calculeze greit este eliminat;
agregarea valorilor. Agregrile pot fi, de asemenea, precalculate nainte de ncrcarea
lor n depozitul de date. Aceasta este o alternativ la ncrcarea doar a valorilor atomice
n depozitul de date.
e) Construirea subsistemului pentru asigurarea calitii datelor
Probleme legate de calitatea datelor nu sunt ntotdeauna vizibile nc de la nceputul
proiectului de implementare, deoarece atenia echipei este focalizat pe conversia unor volume mari
de date i mai puin pe analizarea fiecrei secvene de date n parte. Ulterior, calitatea datelor va
deveni o problem din ce n ce mai stringent.
Una dintre cauzele care determin reticena utilizatorilor n privina depozitului de date o
constituie tocmai slaba calitate a datelor. De asemenea, foarte important este i percepia pe care o
au utilizatorii despre date. Acetia vor folosi depozitul de date doar n msura n care au
convingerea c datele pe care le gestioneaz sunt corecte. nelegerea cauzelor care determin erori
n cadrul datelor face mai uoar munca de depistare i corectare. Deoarece majoritatea erorilor
provin din sistemele surs, administratorii bazei de date i administratorii de sistem vor avea un rol
deosebit de important n aceast etap.
Cteva dintre cauzele care produc erori sunt prezentate n continuare.
valori lips. Valorile lipsesc din sistemele surs, din cauza nregistrrilor incomplete sau
a cmpurilor opionale care nu sunt completate;
integritatea referenial slab. Uneori, integritatea referenial nu poate fi realizat n
sistemele surs, din cauza valorilor inconsistente;
- 38 -
erori n datele precalculate. O parte din datele din depozitul de date pot fi precalculate
nainte de ncrcarea lor, ca parte a procesului de transformare; dac formulele sau
calculele sunt greite, atunci depozitul va conine date eronate;
uniti de msur diferite. Folosirea diferitelor uniti de msur pentru diverse atribute
(valoare, cantitate, volum, timp etc.) poate duce la erori n depozitul de date dac nu se
efectueaz n prealabil transformri la o msur unitar;
obinerea duplicatelor. nlturarea datelor multiplicate trebuie s aib loc nainte de
ncrcarea lor n depozitul de date. n cazul n care aceast operaiune nu se desfoar
corect, exist riscul ca n depozit s apar valori duplicate, generatoare de inconsistene
i erori;
partiionarea cmpurilor. Exist cazuri n care un singur cmp din sistemul operaional
trebuie partiionat n mai multe cmpuri n depozitul de date. Uneori, volumul mare de
date necesit utilizarea unor proceduri automate de partiionare a cmpurilor, care pot s
nu funcioneze corect n toate cazurile;
ierarhii multiple. Multe dintre dimensiunile depozitului de date vor avea ierarhii
multiple determinate de necesitile de analiz. De exemplu, dimensiunea timp poate
avea o ierarhie zi lun trimestru - an, precum i ierarhiile zi - sptmn i zi lun
fiscal trimestru fiscal an fiscal. Nenelegerea semnificaiilor acestor ierarhii
multiple din diferite dimensiuni poate cauza ncrcri eronate n depozitul de date;
termeni i reguli conflictuale. Regulile sau termenii conflictuali pot determina
planificatorii depozitului de date s ncarce dou secvene diferite de date n acelai
cmp al depozitului sau, invers, aceeai secven n dou cmpuri diferite.
Calitatea datelor din cadrul organizaiei poate fi mbuntit prin mai multe modaliti:
evaluarea calitii datelor. Trebuie determinat mai nti calitatea datelor pentru fiecare
dintre sistemele surs existente n ntreprindere;
identificarea datelor importante. Echipa de implementare trebuie s determine care sunt
datele cele mai importante pentru depozitului de date. n felul acesta se pot stabili
anumite prioriti, iar efortul de optimizare poate fi direcionat n mod eficient ctre zona
de cel mai mare interes;
definirea modului de filtrare i mbuntire a datelor. Pentru fiecare secven de date
cu importan mare pentru ntreprindere, trebuie stabilit o tactic specific de
optimizare a calitii. Atunci cnd este posibil, filtrarea datelor trebuie s se focalizeze n
primul rnd asupra sistemelor surs, astfel nct s se elimine posibilitatea propagrii lor
n depozitul de date;
prevenirea erorilor. Efortul ntreprinderii nu trebuie s se limiteze doar la corecii asupra
datelor deja existente, ci trebuie s aib n vedere prevenirea apariiei erorilor. Dac
sistemele operaionale care genereaz date eronate nu sunt revizuite, ele vor continua s
fie o surs sigur de erori pentru depozite.
Toate erorile descoperite trebuie s fie corectate la surs, ceea ce nseamn c sistemele
operaionale trebuie s fie adaptate astfel nct s conin valorile corecte. Aceast practic asigur
c att utilizatorii sistemelor operaionale, ct i cei de la nivel decizional vor beneficia de date
corecte. Practica a dovedit ns c procesul de corectare a datelor la surs poate fi uneori dificil de
implementat att din cauza responsabilitilor operaionale, ct i din cauza faptului c datele
corecte nu sunt cunoscute.
f) Construirea subsistemului pentru ncrcarea depozitului de date
Subsistemul pentru ncrcarea depozitului de date preia schema generat de subsistemul de
extragere i transformare i ncarc datele direct n depozit. Dup cum s-a menionat anterior, datele
care vor fi ncrcate sunt stocate n colecii de date care au aceeai schem ca i depozitul de date.
Subsistemul de ncrcare a datelor n depozitul de date trebuie s furnizeze facilitile
prezentate n continuare:
- 39 -
ncrcarea nregistrrilor n tabelele dimensiune. n sistemele surs, fiecare nregistrare

referitoare la un client, un produs sau o tranzacie este identificat n mod unic printr-o
cheie primar. Similar, aceste entiti trebuie identificate n depozitul de date tot printr-o
cheie. Cheile din sistemele surs sunt uneori nepotrivite ca i chei pentru depozitul de
date, astfel nct apare necesitatea generrii lor n timpul procesului de ncrcare;
ncrcarea nregistrrilor n tabelele de fapte. Cheia primar n tabela de fapte este n
realitate o concatenare a cheilor din tabelele dimensiune cu care sunt n legtur.
nregistrrile din tabelele dimensiune se ncarc nainte de cele din tabelele de fapte
pentru a se putea realiza integritatea referenial;
calcularea valorilor agregate pe baza nregistrrilor surs. Dup ncrcarea valorilor
atomice n depozitul de date, subsistemul de ncrcare trebuie s fie capabil s calculeze
i s stocheze i valori agregate;
reindexrile. Dup ce toate datele s-au ncrcat cu succes, indecii din tabelele cele mai
importante trebuie refcui pentru a crete performana interogrilor;
prezentarea unui sistem de control. Un astfel de sistem trebuie s furnizeze echipei de
implementare informaii referitoare la modul n care s-a desfurat operaiunea de
ncrcare, adic prezentarea pailor i a erorilor care au aprut n timpul fiecrui pas.
Exist controverse cu privire la datele inconsistente i anume dac acestea trebuie sau nu s
fie ncrcate n depozitul de date. Unele echipe de dezvoltare prefer s ncarce doar date corecte n
depozitul de date, argumentnd c datele inconsistente sunt generatoare de erori. Alte echipe prefer
s ncarce ambele categorii de date, cu condiia ca datele inconsistente s fie marcate distinct. Dac
mai mult de 20% din date sunt incorecte i doar 80% sunt ncrcate n depozitul de date, utilizatorii
finali vor lua decizii bazate pe o imagine incomplet. Unii consider necuprinderea datelor
inconsistente ca pe un lucru absolut normal, ns sunt cazuri n care ar fi de preferat ca ele s fie
ncrcate n depozitul de date.
4. Stabilirea schemei depozitului de date.
Administratorul depozitului de date realizeaz schema acestuia n paralel cu construirea i
configurarea subsistemelor back-end (extragere i transformare, asigurarea calitii datelor i
ncrcare). n acest sens, el trebuie s efectueze urmtoarele activiti:
crearea tabelelor depozitului de date. Schema fizic a depozitului de date se
implementeaz prin crearea efectiv a tuturor tabelelor de fapte i de dimensiuni, precum
i a tabelelor cu valori agregate;
construirea indecilor. Indecii vor fi construii n tabele n concordan cu schema
fizic a depozitului de date;
popularea depozitului de date. Dup definirea schemei tabelelor i precizarea indecilor
se trece la ncrcarea datelor. Trebuie avute n vedere i tabelele create pentru a gestiona
excepii, de genul celei prezentate n legtur cu restricia referenial.
5. Metadatele din depozitul de date.
Metadatele se definesc ca fiind date despre date. Acest lucru nseamn c metadatele descriu
coninutul depozitului de date, indicnd de unde provin datele originale i documentnd regulile
care guverneaz transformarea datelor. Interfeele DD folosesc metadatele i pentru automatizarea
unor etape din ciclul de via al dezvoltrii depozitului de date.
6. Modul de acces la date
Stabilirea modului de acces la date reprezint aproximativ a zecea parte din ntregul efort de
dezvoltare a depozitului de date i este partea vizibil pentru utilizatori. n acest sens, se efectueaz
activitile care urmeaz.
Achiziia i instalarea interfeelor de acces. Echipa care are ca responsabilitate
implementarea componentei de acces trebuie s instaleze interfeele selectate mai nti pe o main
de test, care are acces la depozitul de date. n acest fel, dezvoltatorii pot descoperi o serie de
probleme legate de funcionarea interfeelor.
- 40 -
Construirea rapoartelor i a interogrilor predefinite. Prototipul dezvoltat iniial este rafinat

n timpul dezvoltrii depozitului de date prin ncorporarea unor elemente furnizate de reacia
utilizatorilor (feed-back) i prin construirea unor rapoarte i interogri predefinite de care au nevoie
decidenii. Interfeele au diverse opiuni legate de rapoarte i interogri, astfel nct echipa de
dezvoltare trebuie s selecteze varianta optim.
Construirea rapoartelor dinamice i a interogrilor ad-hoc. Un avantaj important al soluiei
informatice cu depozite de date este acela c rezultatele de ieire pot fi att statice (predefinite), ct
i dinamice (flexibile). De multe ori n procesul decizional este nevoie de situaii de ieire dinamice,
instantanee. Echipa de dezvoltare trebuie s includ n sistem aceast facilitate prin utilizarea unor
interfee software adecvate.
Stabilirea profilurilor utilizator. n sistemul de gestiune a depozitului de date, trebuie
neaprat definite roluri i profiluri de utilizatori pentru a stabili corect drepturile de acces. Se
recomand definirea cel puin a urmtoarelor roluri:
utilizator - utilizatorul obinuit al depozitului de date are drepturi de vizualizare i
interogare asupra tabelelor din depozitul de date. Nu sunt permise actualizri;
administrator - acest rol este atribuit pentru utilizatorii care trebuie s poat efectua orice
fel de operaii pe depozitul de date;
dezvoltator - acest rol se atribuie membrilor din echipa de dezvoltare, care sunt
responsabili de realizarea componentelor depozitului de date. Un utilizator care are acest
rol poate crea noi obiecte n interiorul DD.
7. ncrcarea depozitului de date
La anumite intervale de timp, datele din depozit se mprospteaz prin ncrcare. ncrcarea
efectiv a depozitului de date se poate efectua doar dup ce s-au populat tabelele care rezult din
procesul de extragere i transformare a datelor, iar schema depozitului i metadatele au fost
proiectate n ntregime.
Se recomand ca la nceput s se mearg pe varianta ncrcrilor pariale pentru a putea
estima timpul total necesar pentru aceast operaiune. Dac utilizatorii au nevoie pentru analize, de
datele cele mai recente, atunci depozitul de date nu este soluia ideal, ci mai degrab se poate apela
la varianta bazelor de date.
Depozitul de date este folosit, de regul, de ctre utilizatori n orele de serviciu din timpul
zilei i de aceea el se ncarc de obicei noaptea sau la sfritul sptmnii.
8. Instruirea utilizatorilor
Instruirea privind depozitul de date care va fi implementat n ntreprindere este absolut
necesar pentru toi utilizatorii. Cel puin dou activiti sunt necesare n acest sens: aria de
cuprindere a instruirii utilizatorilor i instruirea categoriilor de utilizatori.
Aria de cuprindere a instruirii utilizatorilor. Instruirea trebuie s aib n vedere toi
utilizatorii care vor intra n contact cu depozitul de date i trebuie acoperite urmtoarele aspecte:
definirea depozitului de date. Utilizatorii au ateptri diferite n ceea ce privete
depozitul de date i de aceea instruirea trebuie s nceap neaprat cu definirea DD;
aria de cuprindere a depozitului de date. Toi utilizatorii trebuie s aib cunotine
legate de coninutul depozitului de date. Instruirea trebuie s evidenieze clar ce poate i
ce nu poate s fac depozitul de date;
folosirea interfeelor. Utilizatorii trebuie s nvee cum s foloseasc fiecare opiune n
parte;
intervalul de ncrcare. Utilizatorii vor fi informai cu privire la intervalul de ncrcare a
datelor i la datele care vor fi ncrcate;
alte informaii. Utilizatorii vor fi informai cum s obin diverse informaii despre
folosirea depozitului de date.
Instruirea categoriilor de utilizatori. Instruirea trebuie efectuat pentru acei utilizatori care
vor avea contact cu funcionalitile depozitului de date. Trebuie avut ns n vedere c utilizatorii
diferii au cerine diferite. Dac numrul lor este mare, atunci ei pot fi mprii n dou grupuri
- 41 -
nceptori i avansai. Instruirea este de fapt pasul premergtor testrii, deoarece utilizatorii nu vor
putea testa corect depozitul de date pn cnd nu sunt instruii cu privire la coninutul acestuia i la
regulile de utilizare.
9. Testarea depozitului de date
Pentru testarea depozitului de date vor fi instruii reprezentanii utilizatorilor, avndu-se n
vedere urmtoarele aspecte:
interogrile. Utilizatorii vor testa corectitudinea rapoartelor i interogrilor obinute din
depozitul de date. De regul, validarea rapoartelor generate din depozitul de date se face
construind manual sau prin mecanismele existente acelai raport i comparnd cele dou
rezultate. Eventualele discrepane sunt reinute i se vor efectua coreciile care se impun.
Echipa trebuie s aib n vedere i varianta ca eroarea s provin din sistemul manual de
obinere a raportului;
performana. Utilizatorul va dori ca interogarea lansat asupra depozitului de date s se
execute instantaneu, ns acest lucru depinde de mai multe aspecte: mrimea depozitului
de date, numrul de utilizatori, performanele reelei de calculatoare. Pentru a ameliora
acest indicator se pot folosi valorile agregate precalculate;
rspuns pe durate specificate. Depozitul de date trebuie s fie capabil s furnizeze
rapoarte pe intervalul specificat de utilizatori (zi, sptmn, lun, trimestru, an), adic
n timp util.
Pot fi stabilite anumite criterii de acceptare nainte de nceperea implementrii, iar acceptul
va fi obinut dac sunt ndeplinite aceste criterii. Documentele privind acceptana depozitului de
date sunt semnate doar dup ce testele s-au terminat cu succes i utilizatorii s-au declarat mulumii
de acesta.
2.4. Exploatarea depozitelor de date
Activitii de implementare a depozitului de date i urmeaz cea de exploatare, adic

ntreinerea i dezvoltarea acestuia. Acest lucru implic o serie de activiti specifice, derulate n
momente diferite de timp: ncrcarea periodic a depozitului de date, calcularea indicatorilor
statistici referitori la depozitul de date, meninerea calitii datelor, evaluarea mrimii depozitului
de date i refacerea datelor n caz de accidente.
a) ncrcarea periodic a depozitului de date
Date noi trebuie ncrcate, n mod periodic, din sistemele surs n depozitul de date pentru
ca utilizatorii s poat beneficia de date reale. Acest lucru este n legtur direct cu structura
dimensiunii ierarhiei timp. Operaia de ncrcare a datelor se desfoar, de regul, dup ncheierea
programului de munc, noaptea sau la sfrit de sptmn, atunci cnd sistemele operaionale nu
sunt folosite. n timpul fiecrei ncrcri a depozitului trebuie parcurse toate etapele procesului final
(back-end): extragerea, transformarea, asigurarea calitii i ncrcarea efectiv a datelor. ncrcarea
depozitului cu date noi presupune i necesitatea calculrii i populrii tabelelor de agregri cu noi
nregistrri.
b) Calcularea indicatorilor statistici referitori la depozitul de date
Evoluia i ntreinerea depozitului de date poate fi urmrit prin intermediul indicatorilor
statistici. Valorile acestor indicatori statistici trebuie determinate i analizate pentru a monitoriza
performant i gradul de utilizare a depozitului de date. Civa dintre indicatorii statistici mai des
folosii sunt prezentai n continuare.
numrul de interogri efectuate ntr-o zi exprim numrul de interogri efectuate asupra
datelor din depozit i poate fi calculat pe diferite niveluri de complexitate i detaliere.
Numrul de interogri efectuate asupra tabelelor care conin valori agregate indic, de
asemenea, utilizarea agregrilor stocate;
- 42 -
timpul mediu de rspuns la interogri exprim timpul necesar pentru a obine rezultatul,
din momentul n care a fost lansat interogarea n execuie;
numrul de excepii pe zi caracterizeaz numrul de atenionri i de erori generate de
depozitul de date, n cazul n care exist ncorporat un sistem pentru aa ceva;
numrul de utilizatori indic numrul total de utilizatori care au acces la datele coninute
n depozitul de date;
numrul zilnic de utilizatori indic numrul de utilizatori care folosesc n fiecare zi,
efectiv facilitile oferite de depozitul de date;
frecvena utilizrii evideniaz numrul de accesri ale depozitului de date de ctre un
utilizator ntr-o anumit perioad de timp, indicnd astfel gradul n care DD sprijin
utilizatorul n activitile zilnice;
durata medie a sesiunii de lucru exprim perioada medie de timp n care utilizatorul
rmne conectat la depozitul de date;
intervalele de utilizare maxim a depozitului de date au n vedere perioada din zi, ziua
din sptmn, sptmna din lun etc. n care numrul de interogri este mai mare.
Astfel se scot n eviden momentele i perioadele de timp n care depozitul de date este
mai utilizat i mai puin utilizat;
interogrile arat care subiecte din depozitul de date sunt cele mai folosite de ctre
utilizatori, putndu-se lua msuri pentru optimizarea acestor zone, precum i subiectele
care nu prezint interes i care pot fi eliminate;
mrimea depozitului de date exprim, dup fiecare ncrcare a depozitului de date,
numrul de nregistrri din fiecare colecie de date, pentru a obine rata de cretere a
depozitului de date.
c) Meninerea calitii datelor
Indicatorii privind calitatea datelor trebuie s preocupe organizaia i dup implementarea
depozitului de date. Problema principal const n modul n care sunt tratate erorile care apar n
legtur cu funcionarea depozitului de date. Dou alternative referitoare la calitatea datelor trebuie
luate n considerare: ncrcarea n depozitul de date numai a datelor corecte sau ncrcarea tuturor
datelor i efectuarea ulterioar a coreciilor.
n prima abordare, doar datele care sunt corecte sunt ncrcate n depozitul de date. n felul
acesta utilizatorii sunt siguri c depozitul de date conine numai date corecte i, ca atare, pot lua
decizii bine fundamentate. Deoarece erorile necesit mult timp pentru a fi identificate i corectate,
ar trece prea mult timp pn ce s-ar efectua o nou ncrcare a DD. De asemenea, rezultatele multor
interogri (de exemplu: care sunt primii 100 clieni ?; care sunt cele mai slab vndute produse?) nu
vor fi relevante n cazul n care depozitul de date este incomplet.
A doua abordare presupune ca toate datele s fie ncrcate n depozitul de date, dar sunt
definite i implementate mecanisme pentru identificarea i corectarea erorilor. Dei aceast
abordare permite ncrcarea DD cu toate datele din sistemele operaionale, calitatea datelor poate fi
necorespunztoare, iar deciziile care se iau pe baza lor pot fi eronate.
Ori de cte ori este posibil, trebuie s se mearg pe varianta corectrii datelor n sistemele
operaionale, astfel nct la urmtoarea ncrcare a depozitului de date utilizatorii s beneficieze de
avantajul datelor corecte.
d) Evaluarea mrimii depozitului de date
ncrcarea iniial a depozitului de date poate s nu ridice probleme referitoare la capacitatea
de stocare, dar pe msura trecerii timpului acesta poate crete cu fiecare nou operaie de ncrcare,
iar gestiunea creterii volumului de date va cpta o importan deosebit. Exist cteva modaliti
clasice de gestionare a creterii volumului datelor: agregrile stocate, limitarea perioadei de timp,
tergerea datelor nefolosite.
Folosirea agregrilor stocate reduce semnificativ spaiul de memorare a datelor, n special
dac datele sunt folosite doar la nivelurile de sintez. Datele analitice pot fi terse sau arhivate dup
- 43 -
ce au fost create valorile agregate, dar trebuie avut n vedere faptul c odat terse, nu se pot obine
detalieri ale agregrilor.
Dei utilizatorii ar vrea ca depozitul s stocheze datele permanent, se poate face un
compromis referitor la perioada de timp pentru care un anumit set de date este pstrat n depozit,
adic o limitare a perioadei de stocare a datelor.
Prin folosirea rezultatelor indicatorilor statistici referitori la depozitul de date, pot fi
identificate datele care nu sunt folosite de ctre utilizatori i astfel se poate proceda la tergerea lor.
e) Refacerea datelor n caz de accidente
La fel ca i n cazul bazelor de date, administratorii depozitului de date trebuie s acorde
important sistemelor de recuperare a datelor n caz de accidente. Pe msura trecerii timpului, tot
mai muli utilizatori din organizaie vor deveni dependeni de coninutul depozitului de date i astfel
recuperarea datelor capt o importan deosebit.
Anumite incidente pot necesita reinstalarea sistemelor de operare i a sistemelor de gestiune
a bazelor de date, precum i rencrcarea depozitului de date i popularea tabelelor care conin
agregri. Procedurile de recuperare trebuie s prevad toate situaiile neplcute care pot aprea n
acest sens.
2.5. Criterii de evaluare a depozitelor de date
Activitile complexe i resursele costisitoare implicate n realizarea depozitelor de date i a

sistemelor de Inteligena Afacerii pentru care acestea sunt destinate impun satisfacerea unor criterii
minime de performan i asigurarea unui suport decizional corespunztor. Din acest motiv s-au
impus anumite criterii de evaluare a depozitelor de date:
performana depinde de dimensiunile depozitului de date i vizeaz realizarea de
analize complexe ntr-un timp ct mai scurt;
scalabilitate i mentenan depozitele trebuie s poat fi redimensionate n funcie de
structura i de mediul de afaceri fr a pierde ns din performan;
integrarea datelor sursele de date ale depozitului de date trebuie s fie multiple i
variate, bazate att pe date interne rezultate din procesul operaional ct i pe date
externe organizaiei, referitoare la evoluia pieei, legislaie, concuren, relaii cu alte
organizaii;
suport pentru sistemele de Inteligena Afacerii depozitul de date trebuie s permit
extragerea datelor n vederea realizrii analizelor multidimensionale de tip OLAP i a
extragerii de cunotine din date (data mining).
Pe parcursul etapelor de realizare este necesar s se in cont de varietatea factorilor ce pot
afecta n vreun fel reuita unui depozit de date pentru a asigura un risc minim de eec. Cel mai
eficient mod de a realiza acest lucru este prin obinerea unui mod de abordare structurat care s
uureze studiul acestor factori. Astfel se pot identifica o serie de riscuri care pot aprea pe parcursul
etapelor urmtoare:
analiza datelor - principalul risc este acela de a realiza o colecie de date, organizate i
integrate haotic, fr a avea posibiliti de analiz a acestora, acest fapt ducnd automat
la eecul sistemelor de Inteligena Afacerii pentru care depozitul este proiectat. Modelul
logic al datelor la nivelul organizaiei nu trebuie realizat prin adunarea sau crpirea
schemelor existente pentru c va rezulta un sistem rigid, nepracticabil pentru analize
decizionale. Alegerea tipului de depozit de date i a modalitii de realizare este deosebit
de important. Analiza multidimensional este de asemenea important, fiind necesar
stabilirea corect a dimensiunilor implicate;
analiza metadatelor - riscurile acestei etape sunt legate de cele precizate anterior,
realizarea n grab sau incorect a modelului metadatelor, fr analiza i documentarea
- 44 -
obiectelor din dicionarul de date va face ca modificri i extinderi ulterioare ale

depozitului de date s fie extrem de greoaie;
proiectarea datelor - realizarea incorect a modelelor utilizate (de exemplu modelarea
multidimensional prin diagrame entitate-asociere), neproiectarea unor algoritmi sau
tehnici de optimizare, de securitate a datelor va afecta performanele depozitului. Un alt
aspect este acela de a stabili corect structura datelor din depozit, ce date se vor stoca
agregat i la ce nivel;
proiectarea procesului ETI - un factor de risc principal este acela de a nu analiza
calitatea datelor pe fiecare surs/modul n parte i de a proiecta un proces de extragere,
transformare i ncrcare cu un grad mare de generalitate care doar s ncarce datele n
modulele destinaie. Trebuie alei operatorii i funciile aplicate pe fiecare modul n
parte, innd cont n primul rnd de scopul pentru care se vor ncrca acele date;
proiectarea metadatelor - proiectarea final a metadatelor trebuie s in cont de
flexibilitatea, performana i robusteea depozitului, obiectele s fie realizate uniform i
descrise corespunztor;
implementarea procesului ETI - etapa final a procesului de extragere, transformare i
ncrcare trebuie s ncorporeze i elemente de performan, trebuie stabilite intervalele
de ncrcare a datelor astfel nct s nu fie afectat funcionarea sistemului sau a altor
aplicaii. Testarea procesului ETI trebuie s se realizeze riguros pentru a identifica la
timp eventualele erori n transformarea datelor;
realizarea depozitului metadatelor - finalizarea construirii depozitului metadatelor i
instruirea corespunztoare a personalului din punctul de vedere al administrrii datelor
sunt elementele principale n acest caz. Nerealizarea acestora va face imposibil
administrarea ulterioar i extinderea depozitului.
2.6. Instrumente i medii de dezvoltare utilizate pentru realizarea depozitelor de date
Pentru asistarea activitilor desfurate la realizarea depozitelor de date se pot utiliza o serie
de instrumente i medii de dezvoltare puse la dispoziie de companiile productoare de software.
Cteva dintre acestea sunt identificate n aceast seciune, fr a fi ns detaliate.
Instrumentele Oracle pentru construirea depozitelor de date ct i pentru managementul lor
sunt variate ncepnd cu un nivel general n Enterprise Manager Console, n Analytic Workspace
Manager, a depozitelor virtuale n Discoverer Administrator i culminnd cu Oracle Warehouse
Builder, instrument care susine ntreg ciclul de dezvoltare. Acesta reprezint un instrument puternic
de asistare a procesului de extragere, transformare i ncrcare a datelor din surse variate: SAP,
Oracle, DB2, Microsoft SQL Server, FoxPro, foi de calcul, fiiere text etc.
Compania Microsoft ofer pentru construirea depozitelor de date instrumentul Microsoft
SQL Server Analysis Services, iar managementul datelor i al metadatelor se realizeaz cu
Enterprise Manager i Analysis Manager. Componenta SQL Server Integration Services sau n
variantele mai vechi componenta Data Transformation Services (DTS) susin procesul ETI, ns din
punctul de vedere al surselor de date i al complexitii transformrilor realizate aceste componente
sunt nc inferioare utilitarului corespondent din Oracle Warehouse Builder.
Compania IBM pune la dispoziia utilizatorilor un mediu complet de realizare a depozitelor
de date prin suita InfoSphere Warehouse care conine instrumente pentru planificarea, modelarea,
implementarea, exploatarea DD, pentru aplicarea funciilor de analiz i pentru integrarea cu
tehnologiile de Inteligena Afacerii.
Compania SAP, prin achiziia n anul 2007 a companiei franceze Business Objects care a
realizat suita cu acelai nume destinat dezvoltrii de soluii de Inteligena Afacerii, ofer mediul de
dezvoltare Universe Designer care permite construirea universurilor. Acestea reprezint o viziune
unitar asupra depozitelor de date i permit modelarea multidimensional.
- 45 -
n concluzie, dei metodologiile i etapele de realizare ale depozitelor de date sunt cele
clasice, scopul i caracteristicile specifice ale depozitelor de date prezint un set de probleme unice
i dificile care trebuie analizate i depite. Eventualul succes al realizrii depozitelor de date poate
fi afectat de factori variai care trebuie identificai pe durata ntregului proces de dezvoltare
recomandndu-se s fie orientat spre cerinele de afaceri ale managementului i spre satisfacerea
suportului decizional.
- 46 -
BIBLIOGRAFIE
[AGGU97] Agrawal R., Gupta A., Sarawagi S. - Modeling multidimensional databases,

13th International Conference on Data Engineering, 1997
[ANDE97] Anahory S., Dennis, M. - Data Warehousing in the Real World, Addison
Wesley Longman, Reading, Mass, 1997
[BALU08] Bra A., Lungu I., Velicanu M., Diaconia V., Botha I. Improving query
performance in virtual data warehouses, WSEAS Transactions on Information
Science and Applications, vol. 5, nr. 5, Mai 2008, ISSN: 1709-0832.
[DEVL97] Devlin, B. - Data Warehouse from Architecture to Implementation, Addison
Wesley Longman, Reading, Mass, 1997
[DIBO08] Diaconia V., Botha I., Bra A., Lungu I., Velicanu M. Two integration
flavors in public institutions, Revista WSEAS Transactions on Information
Science and Applications, volumul 5, numrul 5, pp. 806-815, ISSN: 1709-
0832, Mai 2008
[ERIC08] Erickson J. - Data Warehousing gets extreme, Oracle Magazine, vol. XXII,
ISSUE 6, November/December 2008.
[GOMA98] Golfarelli M., Maio D, Rizzi S. - Conceptual design of data warehouses from
E/R schemes, Proceeding of HICSS-31, Hawaii, 1998
[GRBO96] Gray J., Bosworth A., Layan A., Pirahesh H. - Data Cube: A relational
aggregation operator generalizing group by, cross-tabs and sub-totals,Proc. of
the 12th International Conference of Data Engineering, 1996
[GRWA98] Gray P., Watson H. Decision Support in the Data Warehouse, Prentice Hall,
1998.
[HOLL00] Holland, P. - Traditional data warehouses vs virtual data warehouses, White
Paper, March, 2000
[INMO96] Inmon, W.H. - Building the Data Warehouse, John Wiley & Sons, New York,
1996
[INMO99] Inmon, B. - Data mart does not equal data warehouse, DM Direct Newsletter,
November, 1999
[JAJE98] Jarke M., Jeusfeld M.A., Quix C., Vassiliadis P.- Architecture and quality in
data warehouses, Proceedings CaiSE 98, Pisa, Italy, 1998
[KIMB96] Kimball R. - The Data Warehouse Toolkit, John Wiley & Sons, New York,
1996
[KIRE98] Kimball R., Reeves L., Ross M., Thornthwaite W. - The data Warehouse
Lifecycle Toolkit, John Wiley&Sons, Inc., New York, 1998.
[LUBA07] Lungu I, Bra A Sisteme informatice executive, editura ASE, 2007
- 47 -
[OLAP95] The OLAP Council Definitions, www.olapcouncil.org, ianuarie 1995

[POWE00] Power D.J. - Decision Support Systems: Concepts and Resources, Cedar Falls,
IA: DSSresources.com, http://dssresources.com/dssbook, 2000
[TEST00] Teste O. - Towards Conceptual Multidimensional Design in DecisionSupport
Systems, Dexa 2000, LNCS 1873, Londra, 2000
[VELU09] Velicanu M., Lungu I. .a. Sisteme de baze de date evoluate, ed. ASE, ISBN
978-606-505-217-8, 2009.
[VEMA07] Velicanu M., Matei Gh. A few implementation solutions for Business
Intelligence, Revista Informatica Economica nr. 3/2008, ISSN 1453-1305.
[VEMA07a] Velicanu M., Matei Gh. Building a data warehouse step by step, Revista
Informatica Economic nr 2/2007, pag. 83-89, ISSN 1453-1305, 2007
[VEMA07b] Velicanu M., Matei Gh. Database vs Data Warehouse, Revista Informatica
Economic nr 3/2007 (43), pag. 91-95, ISSN 1453-1305, 2007
[VEMA10] Velicanu M., Matei Gh. Tehnologia Inteligena Afacerii, Editura ASE
Bucureti, ISBN 978-606-505-311-3, 2010
[VILA97] Vilan A. Data warehouses, data marts i data mining, Revista
Computerworld Romnia, nr. 18 (88), 21 Octombrie 1997
- 48 -

GVMD Curs

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

GVMD Curs

Încărcat de

Drepturi de autor:

Formate disponibile

ACADEMIA DE STUDII ECONOMICE DIN BUCURETI

FACULTATEA DE CIBERNETIC, STATISTIC I INFORMATIC ECONOMIC

Programul de masterat profesional

Modulul: GESTIUNEA VOLUMELOR MARI DE DATE

-- ASPECTE PRIVIND DEPOZITELE DE DATE --

1. Modelul de date multidimensional

1.1. Structura modelului multidimensional

Structura modelului multidimensional conine n principal obiectele referitoare la tabelele de

explorare i analiz. [OLAP95].

Figura 1. Ierarhii i niveluri ale dimensiunii Produs

algoritmii utilizai pentru sumarizare, care includ: msura i dimensiunea algoritmilor

1.2. Operaii realizate asupra modelului multidimensional

Prin aplicarea unor operaii specifice asupra modelului multidimensional utilizatorului i se

1.3. Restricii de integritate

Prin natura operaiilor realizate asupra modelului multidimensional, restriciile de integritate

1.4. Modele de reprezentare a obiectelor depozitelor de date

Exist dou modaliti (modele) principale de reprezentare a obiectelor depozitelor de date:

Extensii ale modelului relaional - Modelul propus de Kimball

Figura 2. Schema stea

Figura 3. Schema fulg de nea

Figura 4. Schema galaxie

Modele bazate pe cuburi multidimensionale

Figura 5. Cub de date cu trei dimensiuni

Reprezentarea unui cub cu patru dimensiuni poate fi fcut ca n figura 6.

2. Organizarea datelor n depozite de date

Inteligena Afacerii IA (Business Intelligence BI) reprezint o tehnologie informatic

idee referitoare la tendina acesteia n viitor. Soluiile de IA au rolul de a identifica abloanele i a

2.2. Principalele tehnologii informatice utilizate n sistemele pentru Inteligena

2.3. Evoluia i definirea depozitelor de date

Depozitele de Date (DD) reprezint rezultatul interferenei mediului economic i al

(business process) este un ansamblu de activiti interdepartamentale, la nivelul unei organizaii,

2.4. Obiectivele i caracteristicile organizrii datelor n depozitele de date

prognoze corecte. Depozitul de date este un istoric al sistemului operaional. Orizontul

2.5. Faciliti oferite de depozitele de date sistemelor de Inteligena Afacerii

Creterea volumului de date, precum i perfecionarea produselor software pentru gestiunea

3. Arhitectura depozitelor de date

3.1. Arhitectura pe componente a depozitelor de date

Figura 7. Arhitectura pe componente a depozitelor de date

3.2. Arhitectura pe niveluri a depozitelor de date

Arhitectura pe niveluri evideniaz modul de implementare a depozitelor de date ntr-un

Rapoarte, analize, interogri

Strat inferior Server de Date

Surse de date operaionale

Figura 8. Arhitectura pe niveluri a depozitelor de date

3.3. Arhitectura depozitelor de date din punctul de vedere funcional

Modulul Extragerea i procesarea datelor pentru analiz

Modulul Data Marts

Modulul Extragere, Transformare i ncrcare (ETI)

Sisteme operaionale, sisteme

Figura 9. Arhitectura funcional a depozitelor de date

4. Tipuri de depozite de date

Depozitele de date se pot clasifica n funcie de: aria de cuprindere, de procesele

4.1. Tipuri de depozite de date n funcie de aria de cuprindere

Aceast clasificare a depozitelor de date este propus n lucrarea [POWE00] i mparte

4.3. Tipuri de depozite de date n funcie de modelul de date implementat

n funcie de modelul de date implementat sunt identificate urmtoarele tipuri de depozite:

5. Aspecte comparative privind organizarea datelor n baze de date i n

Depozitele de date impun condiii de realizare diferite fa de bazele de date relaionale.

relaional a datelor nainte de a ncepe analiza dimensional deoarece echipa de proiectani a

Tabel 1. Diferene ntre modelul relaional i modelul multidimensional al datelor

Criteriu Modelul relaional Modelul multidimensional

REALIZAREA DEPOZITELOR DE DATE

1. Considerente privind realizarea depozitelor de date