Data Warehouse

(Depozite de date)

Pastor Tiberiu-Dan
Master, Anul I, SIFB

Cuprins
1.

Concepte de baz privind tehnologia depozitelor de date......................................................3

1.1

Depozite de date- delimitri conceptuale....................................................................3

1.2

Data warehousing................................................................................................ 5

1.3

Obiectivele Data Warehouse................................................................................... 6

1.4

Baza de date vs. Data Warehouse.............................................................................7

1.5. Arhitectura Data Warehouse....................................................................................... 8

1.6. Tipuri de Data Warehouse........................................................................................ 12
2.

Realizarea Data Warehouse........................................................................................ 12

2.1. Strategia de realizare a Data Warehouse......................................................................14
2.2. Planificarea cerinelor............................................................................................. 17
2.3. Implementarea Data Warehouse................................................................................ 22
2.4. Exploatarea......................................................................................................... 35

1. Concepte de baz privind tehnologia depozitelor de date

1.1 Depozite de date- delimitri conceptuale

Depozitele de date (data warehouse) au fost definite n foarte multe moduri, nct este
destul de dificil de formulat o definiie riguroas. n sens larg, un depozit de date reprezint o
baz de date care este ntreinut separat de bazele de date operaionale ale organizaiei. Datele
din sistemele surs sunt extrase, curite, transformate i stocate n depozite speciale n scopul
sprijinirii proceselor decizionale. Depozite,le de date sprij ins procesarea informaiilor
furniznd o platform solid de consolidare a datelor istorice pentru analiz. Un depozit de date
este o sum de date consistent, din punct 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.
n concordan cu W. H. Inmon, liderul n construirea sistemelor data warehouse, "un
depozit de date este o colecie de date orientate pe subiecte, integrate, istorice i nevolatile
destinat sprijinirii procesului de luare a deciziilor manageriale" . n sintez, definiia prezentat
mai sus exprim caracteristicile majore ale depozitelor de date:
orientare pe subiecte;
integrare;
caracter istoric ;
persistena datelor.
Aceste caracteristici fac distincia ntre data warehouse i alte depozite de date (data
repository systems), cum ar fi sistemele de baze de date relaionale i sistemele de prelucrare a
tranzaciilor.
Orientarea pe subiecte. Sistemele operaionale tradiionale erau focalizate pe datele
cerute de compartimentele funcionale ale ntreprinderii. O dat cu reingineria proceselor
(Business Process Reengineering - BPR), ntreprinderile ncep s se axeze pe cerinele
decizionale ale echipelor de conducere. Sistemele operaionale moderne sunt orientate pe
cerinele ntregului proces tranzacional i sprijin execuia proceselor de la nceput pn la
sfrit. Un depozit de date merge dincolo de informaiile tradiionale prin focalizarea pe
subiecte ale activitii ntreprinderii cum ar fi: clieni, vnzri, profituri etc. Aceste subiecte
necesit informaii din diverse surse pentru a furniza o imagine complet a domeniului. n loc
de a se concentra pe procesarea operaiilor i tranzaciilor zilnice dintr-o organizaie, un depozit
de date se focalizeaz pe modelarea i analiza datelor pentru luarea deciziilor. Din acest motiv,
depozitele de date ofer, n mod tipic, o viziune simpl i concis relativ la un subiect specific,
excluznd datele care nu sunt utile n procesul de sprijinire a deciziei.
Integrarea. Un depozit de date este, n mod uzual, construit prin integrarea unor multiple
surse heterogene: baze de date relationale, fiiere, nregistrri privind tranzactii on-line.
Tehnicile de curtire a datelor (data cleaning) i de integrare sunt aplicate pentru a asigura
concordanta n conventiile de atribuire a numelor, de codificare a structurilor, de atribuire a
valorilor .a.m.d.
Caracterul istoric. Datele sunt stocate pentru a furniza informatii n perspectiv istoric
(de exemplu, 5-10 ani n urm). Astfel, decidentii pot consulta valorile succesive ale acelorai

date pentru a determina evolutia n timp i a calcula anumiti indicatori.

Persistena datelor. Datele dintr-un depozit sunt permanente i nu pot fi modificate. O
actualizare a depozitului de date, ca urmare a modificrilor efectuate n datele surs, nsemn
adugare de date noi fr a modifica sau terge datele existente. Un depozit de date este
ntotdeauna memorat separat din punct de vedere fizic de datele transformate din alte aplicatii.
Datorit acestei separri, un depozit de date nu necesit mecanisme de procesare a concurentei.
n mod uzual solicit numai dou operatiuni n accesarea datelor: ncrcarea initial a datelor i
accesul la date.
Alte definitii ale depozitelor de date surprind, cu unele nuantri, aceleai elemente
esentiale :
Un depozit de date contine un volum foarte mare de date. Unele dintre aceste date provin
din sursele operationale ale organizatiei, altele pot proveni din surse externe ;
Depozitul de date este organizat astfel nct s faciliteze folosirea datelor n scopuri
decizionale ;
Depozitul de date furnizeaz instrumente prin intermediul crora utilizatorii finali pot accesa
rapid datele.
n continuare prezentm cteva definitii reprezentative din literatura de specialitate.
n viziunea lui Barry Devlin, un depozit de date nseamn "o stocare a datelor, unitar,
complet i consistent, obtinut dintr-o varietate de surse, disponibil utilizatorilor finali ntrun mod uor perceptibil i utilizabil n contextul afacerii".
Dup Ralph Kimball "depozitul de date ofer acces la datele organizationale; datele
continute sunt consistente; datele pot fi separate i combinate n functie de fiecare dimensiune
sau aspect al afacerii. Depozitul de date include, de asemenea, un set de instrumente pentru
interogare, analiz i prezentare a informatiilor; reprezint locul n care sunt publicate datele
folosite; calitatea datelor continute n depozit reprezint o premis pentru reingineria afacerii".
Sam Anahory subliniaz finalitate a depozitelor de date preciznd c un depozit de date
include "datele ... i procesele manageriale ... care fac informatiile disponibile, permitnd
managerilor s ia decizii corect fundamentate" .
De asemenea, o serie de firme i-au adus contributia n definirea, dezvoltarea i
popularizarea tehnologiilor data warehouse IBM, Software AG, Oracle, Microsoft, Prism
Solutions etc. De exemplu, Software AG definete depozitul de date ca "punctul central pentru
difuzarea informatiilor ctre utilizatorii finali pentru sprijinirea deciziilor i pentru acoperirea
cerintelor informationale ale conducerii".
IBM a propus un termen propriu pentru depozitele de date: lnformation , Warehouse.
Dup unii autori, viziunea IBM se refer mai degrab la conecti, vitatea global a diverselor
surse de date, fiind un fel de "middleware generalizat" bazat pe arhitectura proprie DRDA Distributed Relational Database , Architecture.
De altfel, n literatura de specialitate se folosesc i simultan cei doi termeni pentru
depozite de date: Data Warehouse i Information Warehouse. Dup Efraim Turban, scopul unui
"data (sau information) warehouse este de a realiza un fond de date (data repository) care s fac
accesibile datele operationale ntr-o form acceptabil pentru asistarea deciziilor i pentru alte
aplicatii".

1.2 Data warehousing

n legtur cu depozitele de date o notiune frecvent utilizat este cea de "data
warehousing" care desemneaz procesul de construire i utilizare a depozitelor de date (data
warehouse). Construirea unui depozit de date necesit integrarea datelor, curtirea datelor (data
cleaning) i consolidarea datelor. Utilizarea unui depozit de date necesit adesea o colecie de
tehnologii de asistare a deciziilor. Acestea permit managerilor i specialitilor (de exemplu,
analiti, consilieri etc.) s utilizeze depozitul pentru a obine rapid i convenabil datele necesare
i s ia deciziile bazate pe informaiile din depozit. Ali autori utilizeaz termenul de "data
warehousing" pentru a referi numai procesul de construire a depozitului de date, n timp ce
termenul de "warehouse DBMS" este utilizat pentru a referi conducerea i utilizarea depozitului
de date.
n privinla utilizrii datelor din depozitele de date trebuie precizat c multe organizaii
utilizeaz aceste informaii pentru sprijinirea lurii deciziilor n diferite domenii de activitate
cum ar fi :
sporirea focalizrii pe clieni, care include analize ale vnzrilor (preferine, periodicitate,
cicluri bugetare, apetit pentru cumprare etc.) ;
reorientarea produciei i gestionarea portofoliului de produse, comparnd performanele
vnzrilor pe trimestre, ani, zone geografice, n ordinea celor mai bune strategii de producie;
analiza operaiilor i cutarea surselor de profit;
gestionarea relaiilor cu clienii ;
gestionarea costului activelor corporale.
Data warehousing este, de asemenea, foarte util din punct de vedere al integrrii surselor
de date heterogene. Multe organizaii colecteaz, n mod obinuit, diferite tipuri de date i
ntrein baze de date mari din surse de informaii multiple, heterogene, autonome i distributive.
Integrarea acestor date i obinerea unui acces eficient la ele este lucrul cel mai dorit. Multe
eforturi au fost depuse n industria bazelor de date i n comunitile de cercetare pentru
ndeplinirea acestui scop.
n concepia bazelor de date tradiionale integrarea bazelor de date heterogene este
realizat de "wrappers" i integratori (integrators) sau mediatori (mediators) asupra bazelor de
date multiple (de exemplu: IBM Data Joiner, Informix Data Blade). Cnd o interogare este pus
unui site client, un dicionar de metadate este utilizat la transformarea interogrii n interogri
corespunztoare site-urilor heterogene implicate. Aceste interogri sunt atunci mapate i
transmise proceselor locale de interogare. Rezultatele primite de la diferite site-uri sunt integrate
n rspunsul global.
Acest concept de interogare necesit procese complexe de filtrare i integrare, care
concureaz la resursele de procesare. Este ineficient i potenial scump pentru interogri
frecvente, n special pentru interogri ce solicit agregri. Data warehousing furnizeaz o
interesant alternativ la conceptul tradiional de integrare a bazelor de date heterogene descrise
mai sus. Data warehousing folosete conceptul "update-driven" n care informaiile din surse
multiple, heterogene sunt interogate n avans i stocate n depozitul de date pentru integrare

direct i analiz. Spre deosebire de bazele de date cu procesare on-line, depozitele de date nu
conin informaiile cele mai proaspete. Cu toate acestea, un depozit de date determin o nalt
performan prin integrarea bazelor de date heterogene ntruct datele sunt copiate, preprocesate,
integrate, adnotate, nsumate i restructurate ntr-o colecie semantic de date (semantic data
store). n plus procesul de interogare din depozitul de date nu interfereaz cu procesele din
sursele locale. De altfel, depozitele de date pot stoca i integra informaii istorice i sprijin
interogri multidimensionale complexe.

1.3 Obiectivele Data Warehouse

n sintez, scopurile unui depozit de date sunt urmtoarele:
Acces sporit la date pentru utilizatori. Depozitul de date furnizeaz accesul la datele
integrate ale ntreprinderii, anterior blocat prin ci neprietenoase. Utilizatorii pot acum s
stabileasc, cu un minim de efort, o conexiune garantat la depozitul de date prin intermediul
unui microca1culator. Securitatea este ntrit prin the warehouse front-end application, prin
serverul bazei de date sau prin ambele.
O singur versiune a adevrului. Datele din depozitele de date sunt consistente i au
calitatea asigurat nainte de a fi puse la dispoziia utilizatorilor finali. n msura n care se se
utilizeaz o surs comun de date, depozitele de date pun capt dezbaterilor privind veridicitatea
datelor utilizate sau citate n edinele de lucru. Depozitul de date ncepe s fie resursa comun
de date pentru nivelurile decizionale din organizaii. Menionm c "o singur versiune a
adevrului" este adesea posibil numai dup multe discuii i dezbateri asupra termenilor utilizai
n organizaie. De exemplu, termenul de "client ru platnic" poate avea mai multe nelesuri:
client care nu pltete la timp, client care nu pltete dect parial, client care nu pltete
niciodat etc. Ar putea fi stabilit i o alt acceptiune: clienti care au datorii mai vechi de o lun.
n mod sigur aceste acceptiuni au influen asupra proceselor decizionale i asupra pertinentei
deciziilor.
nregistrarea cu acuratete a trecutului. Multe date primite de manageri nu sunt
semnificative, dac nu sunt comparate cu datele anterioare. De exemplu, rapoartele care compar
performantele actuale ale companiei cu cele din anul precedent sunt comune. Rapoartele care
arat performantele companiei pentru fiecare lun din ultimii trei ani pot fi foarte interesante
pentru decidenti. Sistemele operationale nu vor putea permite acest gen de informatii. Un depozit
de date va fi utilizat pentru nregistrarea cu acuratete a trecutului, prsind sistemele OLPT
libere pentru a realiza focalizarea pe corecta nregistrare curent a tranzactiilor. Datele istorice
sunt ncrcate i integrate cu alte date n depozit pentru un acces rapid.
Acces combinat sintez/detaliu la date. Rapoartele dinamice i instrumentele de interogare
OLAP (de exemplu, releveele din programele de calcul tabelar, drill-up, drill-down) permit
utilizatorilor s vizualizeze informatiile din depozitul de date sub diferite unghiuri i la diferite
niveluri de detaliere. Aceste disponibilitti oferite de depozitele de date reduc timpul i efortul
necesar pentru colectarea, formatarea i filtrarea informatiilor plecnd de la date.
Separarea prelucrri/ar de nivel opera1ional i analitic. Procesele decizionale i procesele
operationale sunt totalmente divergente arhitectural. ncercarea de a se reuni n acelai sistem

informatiile decizionale i operationale determin ca ntretinerea sistemului s devin o

problem.
Pornind de la procesele operationale, depozitul de date furnizeaz o arhitectur separat
pentru implementarea deciziilor. Aceasta face ca ntreaga arhitectur IT a ntreprinderii s devin
mult mai deschis schimbrii cerintelor informationale.

1.4 Baza de date vs. Data Warehouse

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.
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 - On
Line 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 On Line Analytical Processing).
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 sunt construite special pentru sprijinirea lurii deciziilor. Ele 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.
Interogrile obinuite ntr-un depozit de date sunt mai complexe i mai variate dect cele
din bazele de date. Ele se aplic asupra unor volume foarte mari de date i presupun calcule
complexe (analiza tendinei, medii, dispersii etc.), care necesit adesea agregri.
Bazele de date sunt orientate pe client (customer oriented) i sunt utilizate pentru procesarea
tranzaciilor i interogrilor. DD sunt orientate pe pia (market oriented) i utilizate de
manageri i analiti de date. BD gestioneaz date curente care sunt destul de detaliate pentru a fi
uor utilizate nactivitatea operaional.
DD 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. La
BD sursele de date sunt tranzaciile atomice, iar accesul este de tip citire i scriere. La DD
sursele de date sunt BD operaionale, iar accesul este cel mai adesea de tip citire pentru
interogri complexe.
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, de

acces.
O baz de date presupune procesarea concurent a tranzaciilor multiple.
Controlul concurenei pentru DD este mult mai simplu deoarece se aplic doar pentru citire.
Comparaie ntre BD i DD

Criteriu
Procesele
Execuie
Utilizatori
Operaii
Caracterul datelor
Nivelul de sintez
Acces
Focalizare
Sursa de date este
Volum de date
Prioriti
Software necesar

BD
operaionale
tranzacii
toate categoriile
zilnice
curente
primitive, detaliere
citire, scriere
culegere date
validat
ordinul GB
performane,
disponibilitate
SGBD

DD
informaionale
analize
manageri, analiti de date
asistarea deciziei
istorice
sintetizare, consolidare
citire
furnizare informaii
filtrat, transformat
ordinul TB
flexibilitate, autonomie
specializat, SGBD

1.5. Arhitectura Data Warehouse

Sunt cel puin dou arhitecturi de DD care se pot transforma oricnd una n cealalt: pe
componente, pe niveluri.
Arhitectura pe componente a depozitelor de date
Evideniaz componentele DD i legturile dintre ele: depozitul de date, sursa de date,
interfeele de analiz.
Esena unui depozit de date const ntr-o baz de date de dimensiuni foarte mari
coninnd informaiile pe care le pot folosi utilizatorii (clieni, furnizori, companii de publicitate
etc.).
Depozitul de date conine mai multe tipuri de date care corespund diferitelor cerine
informaionale ale utilizatorilor: date detaliate, date agregate, metadate (dicionarul de date).
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 agregate i de calcul. Ele sunt utilizate oro de cte ori se utilizeaz DD: la ncrcarea datelor,
la consultare, la actualizare, adic pe parcursul ntregului ciclu de via al depozitului.
Datele agregate, dei determin o cretere a redundanei datelor, sunt necesare n DD
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 nevoile
managementului: consolidare, totalizare, nsumare, mpachetare (n formate accesibile
interfeelor de analiz utilizate).

sursa de date

depozit de date

interfee de analiz

Data Mart

transformare
Date externe

Data Mining
Metadatele
Date interne
Datele aggregate

OLAP

Date arhivate
Datele detaliate

Datele detaliate sunt cele relativ recente, livrate utilizatorilor, de regul la nivel de
execuie.
Tot aici se gsesc date avnd o anumit vechime (civa ani), n form detaliat.
Sursele de date pentru DD sunt: datele operaionale curente (BD i/sau fiiere din
sistemul informatic al organizaiei), datele vechi arhivate, datele externe (BD 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 extragere transformare ncrcare (ETL Extract
Transformation Load):
- 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 DD: concentrri de date (Data Mart), extrageri i analize
de date (Data Mining) analiza multidimensional a datelor (OLAP).
Arhitectura depozitelor de date pe trei straturi
Evideniaz modul de implementare a DD ntr-un mediu de reea de calculatoare, pe trei
straturi: stratul inferior, stratul mediu, stratul superior.
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
de baz i permite programelor client s genereze cod (de obicei SQL) pentru a fi executat de
server.
Astfel, datele sunt extrase, filtrate, transformate i ncrcate n depozitul de date prin
interfee specializate de tip ETL - Extract Transformation Load (de exemplu produsul Oracle
Data Integrator ODI). mprosptarea datelor din DD 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 (analize statistice superioare), Data Mart (concentrri de date). De multe ori acest strat
este inclus n SGBDR (exemplu Oracle, DB2).
Stratul superior (top tier) este nivelul client care conine interfee pentru generarea
interogrilor, a rapoartelor, pentru superioar a datelor.
Strat superior

Rapoarte, interogri

extragere

Strat mediu

Servere specializate

Depozite de
date

transformare
Strat inferior

Server de Date

1.6. Tipuri de Data Warehouse

Dup aria de cuprindere se ntlnesc trei tipuri de depozite de date: depozite de
ntreprindere (Enterprise Warehouse), concentrri de date (Data marts), depozite virtuale de date
(Virtual Datawarehouse).
Depozitul de ntreprindere colecteaz toate informaiile despre subiectele care privesc
ntreaga organizaie. El furnizeaz un volum foarte mare de date. De regul conine date
detaliate, dar i date agregate, iar ca ordin de mrime, terabytes.
Un depozit de date de ntreprindere poate fi implementat pe calculatoare mari
(mainframes), pe superservere UNIX, pe platforme cu arhitecturi paralele. 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 (UNIX sau Windows). 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 puin scump.
Depozitul virtual este un set de viziuni (views) asupra bazelor de date operaionale.
Pentru eficiena procesrilor interogrilor, numai unele din viziunile de agregare pot fi
materializate. Un depozit virtual este uor de construit, dar necesit capaciti suplimentare pe
serverele de baze de date.
Dup modelul de date implementat sunt urmtoarele tipuri de DD: DD relaionale, DD
multidimensionale.

2. Realizarea Data Warehouse

Realizarea unui depozit de date presupune aplicarea unei scheme de analiz economic
pentru a determina msura n care depozitul de date este necesar i eficient:

trebuie s furnizeze avantaje competitive prezentnd informaii relevante pe baza crora

putem msura performanele i putem face ajustri critice pentru a ctiga n faa
competitorilor;
poate determina creterea productivitii deoarece permite obinerea rapid i eficient de
informaii care descriu cu acuratee organizaia;
faciliteaz gestiunea relaiilor cu clienii, deoarece acesta furnizeaz o viziune consistent
despre clienii i produsele comercializate de organizaie, pe toate departamentele;
determin reducerea costurilor prin reliefarea tendinelor , direciilor i excepiilor pe
perioade lungi de timp.

Realizarea unui depozit de date poate lua n considerare viziuni diferite:

o viziunea de sus n jos (top-down) permite selectarea informaiilor relevante
necesare n depozitul de date, informaii care reprezint un sprijin decizional n
activitatea curent.
o viziunea datelor surs (data source view) exprim informaiile culese, stocate i
gestionate de sistemele operaionale. Aceste informaii pot fi documentate pe
niveluri variate de detaliere i acuratee, de la tabele individuale de date surs la
tabele de date integrate.
o viziunea depozitelor de date (data warehouse) are n vedere tabele de fapte i
tabele dimensiune i reprezint informaiile care sunt stocate n depozitele de date,
incluznd contorizri i totaluri precalculate, precum i informaii privitoare la
surs, dat calendaristic, origine, adugate pentru a furniza contextul istoric.
o viziunea de interogare (business query) ofer o perspectiv din punct de vedere al
utilizatorului.
Un depozit de date poate fi proiectat i construit utiliznd abordarea:
- de sus n jos (top-down) care pornete cu proiectarea i planificarea complet. Se
utilizeaz n cazul cnd tehnologia este matur i bine cunoscut 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 n realizarea modelelor de date pentru ntreaga organizaie;
- de jos n sus (bottom-up) pornete cu experimente i prototipuri. Aceasta este utilizat la
nceputul stadiului de modelare i de dezvoltare tehnologic. Ea 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, dezvoltarea i aplicarea 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 ntreprindere.
- 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.

Realizarea unui depozit de date presupune urmtorii pai: 1. strategia de realizare; 2.

planificarea (modelarea) cerinelor; 3. implementarea; 4. exploatarea.

2.1. Strategia de realizare a Data Warehouse

Strategia de dezvoltare, la nivelul cel mai sintetic, trebuie s nclud elementele urmtoare:
- planul preliminar al depozitului de date. In cadrul unui proiect DD nu pot fi satisfcute
toate cerinele utilizatorilor deoarece un astfel de proiect ar fi imens i periculos din punct
de vedere al capacitii de gestionare. Este mult mai realist s se fac o list cu prioritile
cerinelor diferiilor utilizatori, iar aceste cerine s fie ataate diferitelor segmente care se
vor dezvolta prin strategia 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 definite arhitectura general a
depozitului de date pentru proiectul pilot i versiunile care vor urma pentru a asigura
scalabilitatea depozitului. Prin analizarea posibilelor arhitecturi de depozite de date,
analitii pot s determine o mulime de alte componente tehnologice care sunt necesare
pentru fiecare versiune;
- lista preliminar a mediilor de dezvoltare a depozitului de date. Exist un numr destul
de mare de medii i instrumente pentru DD din care se pot face alegeri i, de aceea, se
recomand alctuirea unei liste sintetice cu cele care pot fi de folos n cadrul organizaiei.
Un set standard de instrumente 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 DD 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,
evaluarea mediilor de dezvoltare a depozitului de date.
1. Determinarea contextului organizaional. Inelegerea 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.
2. Realizarea unei vederi preliminare de ansamblu asupra cerinelor. In 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 despre care se ateapt s le ofere un viitor depozit de date.
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. In
timp ce managerul IT va furniza imaginea de ansamblu a sistemelor existente n organizaie, cei

mai n msur s ofere detalii pentru auditarea sistemelor surs sunt administratorii de baze de
date i administratorii de sistem care ntrein sistemele operaionale.
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, date referitoare la codurile potale, date statistice sau demografice, date de la alte
organizaii, date de la agenii de tiri sau din publicaii.
5. Definirea versiunilor depozitului de date. Specialitii recomand mprirea dezvoltrii
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.
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 recomandabil s
se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaionale i
multidimensionale, precum i instrumente adecvate.
7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizaia poate alege ntre 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. In prezent nu exist un
productor care s ofere o suit integrat pentru depozite de date, ns exist lideri pentru fiecare
categorie n parte. 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. Planificarea cerinelor

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 n general 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, de disponibilitatea i calitatea documentaiei
sistemelor surs i de 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 de date, transformarea cmpurilor surs n cmpurile destinaie, ncrcarea datelor
istorice n depozitul de date, 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
DD.

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.
Dac este necesar membrii echipei vor fi instruii cu privire la conceptele referitoare la
tehnologia depozitelor de date. Va fi mult mai uor pentru fiecare s munceasc mpreun, dac
toi vor avea un scop comun i o viziune identic n ceea ce privete atingerea acestui scop. Ca
urmare, trebuie descrise activitile i jaloanele 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 este una din cele dou activiti care se pot desfura n
paralel n timpul planificrii depozitului de date, cealalt activitate fiind auditarea sistemelor
surs. Obiectul analizei cerinelor l constituie nelegerea cerinelor informaionale ale
decidenilor.
O analiz preliminar a fost deja efectuat ca parte a formulrii strategiei DD. In 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 n termeni de interogri i rapoarte care vor
putea fi 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. Limitrile impuse de sistemele surs
determin n mare msur modul n care va arta depozitul de date n final.
Aria de ntindere 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 membrii.
3. Auditarea sistemelor surs.
Auditarea sistemelor surs trebuie s ofere o vedere de ansamblu asupra sistemelor care
pot fi surse poteniale de date pentru depozit. Auditarea preliminar a sistemelor surs din cadrul
formulrii strategiei DD trebuie s ofere o list complet a surselor de date.
Sistemele surs 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. In 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 cunotiinele 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 primare.
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 DD:
- documentaia arhitecturii IT a organizaiei (toat documentaia care ofer o vedere de
ansamblu asupra arhitecturii IT): 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 (o diagram care descrie amplasarea i configurarea reelei);
- manualul tehnic i manualul de utilizare pentru fiecare sistem surs: modelele datelor i
schemele pentru toate subsistemele informatice care candideaz ca sisteme surs;
- bazele de date: pentru fiecare sistem surs se va identifica tipul bazei de date folosite i se vor
face aprecieri ale 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 folosete un anumit sistem de codificare i de
aceea administratorii bazelor de date trebuie s ofere informaii referitoare la modul n care sunt
generate codurile, la modul de reutilizare a codurilor, la posibilitatea unificrii lor;
- mecanismele de extragere: trebuie verificat dac datele pot fi citite sau extrase direct din bazele
de date operaionale. Pachetele de aplicaii existente i sisteme de gestiune a bazelor de date pot
prezenta 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
informainale ale utilizatorilor versiunii respective. Sunt disponibile scheme rezultate din dou
tipuri de modele: relaional (bazat pe normalizare), 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 (tehnologia
OLAP).
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 integrator pe care l are depozitul de date. Exemplu,
fiecare sistem operaional va avea propriile nregistrri referitoare la clieni i produse. 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. Exemplu, exist sisteme operaionale care nregistreaz
adresele ca linii de text cu numele cmpului Adresa. Acesta poate fi imprit n mai multe
cmpuri cum ar fi: Strada, 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 creearea 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 avut n vedere urmtoarele
aspecte:
- Schimbrile n structura datelor. Se va determina dac schemele tuturor sistemelor surs au
suferit modificri in 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 mult mai complicate. Fiecare sistem surs va necesita, probabil,
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.
7. Selectarea mediilor de dezvoltare.
n aceast etap se finalizeaz alegerea produselor software necesare pentru realizarea
DD. Dac a fost efectuat un studiu amnunit al acestui aspect n etapa de definire a strategiei,
activitatea de selectare devine opional. Dac strategia DD nu a fost formulat atunci trebuie s
se fac evaluarea n acest moment. Este indicat s se fac selecia ct mai repede pentru ca
livrarea s nu perturbe procesul de dezvoltare, mai ales n cazul importurilor.

8. Crearea prototipului pentru versiunea curent

Prin folosirea listei finale a mediilor de dezvoltare se va creea 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 cerem furnizorilor de tehnologii s

prezinte un prototip de depozit de date pentru a-l evalua. Rezultatul evalurii ne va folosi
n selectarea interfeelor: produse OLAP, generatoare etc.
- Corectitudinea schemei de date. Echipa creaz un prototip bazat pe o anumit schem i
apoi se pot lansa interogri sau realiza rapoarte de prob pe baza datelor reale din
sistemele surs. Dac cerinele utilizatorilor, n termeni de interogri, pot fi ndeplinite
folosind schema proiectat, atunci echipa poate valida aceast schem.
Validarea prototipului. Echipa de dezvoltatori va invita reprezentanii utilizatorilor s
foloseasc efectiv 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 declanaz o multitudine de reacii pozitive i
negative din partea utilizatorilor. Aceste reacii pot ghida echipa de dezvoltare privind coreciilor
care trebuie fcute. 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 Data Warehouse
Definirea ariei de cuprindere
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 procesare 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 exist standarde n acest domeniu (de exemplu,
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:
o Date actuale folosite pentru obinerea rapoartelor. Aceste date tebuie s fie incluse n
procesul de auditare al sistemelor surs. Avantajul este c echipa de dezvoltare va ti din
start care cmpuri din aceste sisteme sunt cele mai importante.
o Programele actuale de extragere. Programele de extragere sunt un indiciu valoros pentru
realizarea tabelelor surs-destinaie. De asemenea, ele ofer informaii valoroase
referitoare la formulele i regulile de transformare a datelor.

o 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 deficene
legate de rapoartele care se produc n organizaie. Nu este nimic neobinuit s fie descoperite
inconsistene referitoare la folosirea unor termeni, formule de calcul sau reguli, n funcie de
persoana care creez sau citete raportul.
Fiecare secvent 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 care nu se regsesc n sistemele surs. Limitrile impuse de datele disponibile sunt de
urmtoarele tipuri:
- Secvene de date care lipsesc. O secven de date este considerat lips dac nu exist nici un
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 nici o importan pentru derularea zilnic a
tranzaciilor, ns au o mare importan pentru deciziile tactice i strategice.
- 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 secvent
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 din clieni, produse, perioade de timp. Atunci cnd se dorete
realizarea unei analize globale, acest lucru nu este posibil, din cauza faptului c datele nu sunt
disponibile pentru toate reperele avute n vedere.
- 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 la introducerea datelor, datele nu sunt
disponibile, se merge pe varianta valorilor implicite care de fapt nu sunt corecte.
Un raport de auditare a sistemelor surs trebuie s aib urmtoarele componente:
o Lista sintetic a sistemelor surs. Aceast seciune trebuie s listeze toate sistemele
operaionale cuprinse n operaiunea de audit. Sunt oferite descrieri generale ale
funcionalitilor i ale datelor fiecrui sistem operaional, precum i o list cu entitile
cele mai importante, precum i a cmpurilor eseniale. De asemenea, se pot meniona i
utilizatorii actuali ai sistemelor analizate.
o 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
oferite explicaii n legtur cu importana datelor care lipsesc i modul cum pot fi ele
obinute.
o Ameliorarea calitii datelor. Pentru fiecare sistem operaional, trebuie evideniate toate
zonele n care poate fi mbuntit calitatea datelor i cum anume.
o 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.

Crearea planului de implementare pentru versiunea curent

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.
Atunci cnd se creaz planul de implementare trebuie s avem 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 comlexe.
- Numrul de procese decizionale asistate. Cu ct sunt asistate mai multe procese decizionale,
cu att va fi mai mare numrul utilizatorilor care vor avea o prere n privina depozitului de date
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 se orienteaz 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.
- Dimensiunea estimat a volumului de date. Aceast mrime furnizeaz o estimare preliminar
a efortului de ncrcare, indexare i modificare a depozitului de date. Volumul de date permite
echipei de dezvoltare s aprecieze durata de ncrcare a depozitului (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 implemenatrea
depozitului.
- Disponibilitatea solicitat de utilizatori. Un depozit de date care s fie disponibil pentru
utilizatori 24 de ore, timp de apte zile pe sptmn, necesit o arhitectur care este complet
diferit de unul care trebuie s fie disponibil doar 12 ore, timp de patru 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.
Implemenatrea propriu-zis a depozitului de date
Procesul de implementare a depozitului de date const de fapt din activiti legate de
implementarea fiecrei versiuni. Activitile sunt organizate pe baza rezultatealor etapei de
planificare a depozitului de date.
Echipa de implementare construiete sau extinde o schem existent a depozitului de date
bazat pe proiectul schemei produse n timpul planificrii. Echipa construiete de asemenea
subsistemele DD care asigur un flux constant de date valide din sistemele operaionale n

depozitul de date. Ali membrii ai echipei sunt responsabili cu instalarea i configurarea

interfeelor pentru a permite utilizatorilor accesul la depozitul de date.
Un proiect de implementare 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 personalului ntreprinderii.
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: achiziia i configurarea mediului de dezvoltare, obinerea copiilor
coleciilor de date operaionale, finalizarea proiectrii schemei fizice a depozitului de date,
construirea sau configurarea subsistemelor de extragere i transformare, construirea sau
configurarea subsistemului pentru calitatea datelor, construirea subsistemului pentru ncrcarea
depozitului de date.
1. 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 sistemului de operare, instalarea i configurarea motorului pentru baze de date
relaionale, instalarea produselor de 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 n manier relaional,
sistemul relaional care face acest lucru nu trebuie neaprat s fie acelai cu cel existent n
sistemele operaionale.
La sfritul acestei etape trebuie ca echipa de dezvoltare s aib la dispoziie
infrastructura necesar pentru a realiza efectiv implementarea.
2. 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 DD. Crearea acestor copii poate fi,
de asemenea, automatizat prin folosirea tehnicii de replicare din tehnologia SBD 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
dezvoltarea n demersul implementrii depozitului de date.

3. 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 aspectele specifice ale
sistemului de gestiune a bazelor de date, care a fost desemnat pentru depozitul de date.
Aspectele importante sunt urmtoarele:
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 spaiu 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 de asemenea s aib n
vedere c un depozit de date partiionat este mai uor de gestionat, ns performana interogrilor
scade.
4. 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. Aceaste
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 DD. Extragerea se poate realiza printr-o varietate de mecanisme, de la instrumente
sofisticate puse la dispoziie de ctre productorii software pn la programe realizate de
personalul propriu.
Interfeele oferite de diverii productori sunt capabile s documenteze procesul de
extragere prin generarea metadatelor specifice. Dezavantajul acestora este determinat de preul
prea mare. De aceea, organizaiile prefer deseori s-i dezvolte propriile lor aplicaii de extragre
a datelor. Aceast soluie este viabil n msura n care sistemele surs sunt ntr-un mediu
omogen. Aplicaiile 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 delimitate cteva tipuri
de transformri:

- Schimbarea formatului. Fiecare dintre cmpurile utilizate n sistemele operaionale pot stoca
date n diverse formaturi i tipuri. Aceste secvene individuale de date sunt modificate n impul
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
pentru stabilirea valorilor corecte.
- 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 vederea populrii depozitului 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.
5. Construirea subsistemului pentru calitatea datelor
Probleme legate de calitatea datelor nu sunt ntotdeauna vizibile nc de la nceputul
proiectului de implementare, deoarece atenia echipei este focalizat pe mutarea unor volume
mari de date i mai puin pe analizarea fiecrei secvene de date n parte. n orice caz, pe msura
evoluiei implementrii, calitatea datelor va deveni o problem din ce n ce mai stringent.
Una dintre cauzele care determin mpotrivirea 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. Rezult c subsistemul pentru
calitatea datelor reprezint o component critic a arhitecturii depozitului de date. nelegerea
cauzelor care determin erori n cadrul datelor face mai uoar munca de depistare i corectare.

Deoarece majoritatea erorilor provin din sistemele surs, administratorii bazelor de date i
administratorii de sistem vor avea un rol deosebit de important n aceast etap.
Erorile au urmtoarele cauze:
- 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.
- 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. Deduplicarea datelor 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. Din pcate volumul mare de date necesit
apelarea la 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 zilun-trimestru-an, precum i ierarhiile zi-sptmn i zi-lunfiscal-trimestrufiscal-anfiscal.
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 ameliorat prin mai multe modaliti:
o Evaluarea calitii datelor. Trebuie determinat mai nti calitatea datelor pentru fiecare
dintre sistemele surs existente n ntreprindere.
o Identificarea datelor importante. Echipa de implemenatre trebuie s determine care sunt
datele cele mai importante din perspectiva depozitului de date. n felul acesta se pot
stabili anumite prioriti, iar efortul de ameliorare poate fi direcionat n mod eficient
ctre zona de cel mai mare interes.
o Definirea modului de filtrare i mbuntire a datelor. Pentru fiecare secven de date
cu importan mare pentru ntreprindere, trebuie stabilit o tactic specific de

ameliorarea a calitii. Atunci cnd este posibil, filtrarea datelor trebuie s se focalizeze
n primul rnd asupra sistemelor surs, astfel inct s se elimine posibilitatea propagrii
lor n depozitul de date.
o Prevenirea erorilor. Efortul ntreprinderii nu trebuie s se limiteze doar la corecii asupra
datelor deja existente, ci doar 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.
Avnd n vedere complexitatea unui astfel de proiect, nu ar fi realist dac am considera c
exist un singur instrument care s asigure calitatea datelor. De asemenea, orict de mari ar fi
eforturile de ameliorare a calitii, ntreprinderea trebuie s fie oricnd pregtit pentru a aborda
noi probleme referitoare la acest aspect.
Toate erorile descoperite ar trebui s fie corectate la surs, ceea ce nseamn c sistemele
operaionale trebuie s fie modificate astfel nct s conin valorile corecte. Acest practic
asigur c att utilizatorii sistemelor operaionale, ct i cei de la nivel decizional vor beneficia
de date corecte. Experienta 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. Responsabilitatea pentru corectarea datelor din
sistelele surs revine personalului operaional care nu prea agreaz ideea de a accepta o
responsabilitate suplimentar. Chiar dac se tie despre o anumit secven de date c nu este cea
corect, pot exista situaii n care s nu poat fi determinate valorile corecte din cauza
imposibilitii obinerii lor.
6. 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 fie apt s furnizeze
urmtoarele faciliti:
- 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. De
asemenea, aceste entiti trebuie identificate n depozitul de date tot printr-o cheie. Cheile din
sistemele surs sunt deseori nepotrivite ca chei pentru depozit, 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 nrcarea 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. Acest sistem trebuie s furnizeze echipei de implementare
informaii referitoare la modul n care s-a desfurat operaiunea de ncrcare: prezentarea pailor
i a erorilor care au aprut n timpul fiecrui pas (de exemplu, erori cu privire la integritatea
referenial).
Exist discuii dac datele inconsistente 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
depozitului de date vor lua decizii bazate pe o imagine incomplet. Probabil c muli ar considera
necuprinderea datelor inconsistente ca pe un lucru absolut normal, ns sunt cazuri n care ar fi
de preferat ca ele s fie ncrcate n depozit.
Decidenii trebuie s aib datele la dispoziie 24 de ore pe zi, ns procesul de ncrcare a
depozitului de date blocheaz accesul pe durata desfurrii lui. Cea mai mare provocare n
construirea unui sistem de ncrcare o constituie optimizarea operaiunii de ncrcare astfel nct
ea s blocheze ct mai puin accesul utilizatorilor la date.
Stabilirea schemei depozitului de date
Administratorul DD realizeaz schema
acestuia n paralel cu construirea sau
configurarea subsistemelor back-end (extragere i transformare, asigurarea calitii datelor,
ncrcare). n acest sens, el trebuie s efectueze urmtoarele activiti:
- Crearea tabelelor DD. 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 DD. 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.
Metadatele din depozitul de date
Metadatele se definesc ca fiind informaii despre date. Aceast definiie nu este
perceput corect de obicei de cei ce ncearc s o neleag i de aceea poate ar fi mai potrivit s
remarcm 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.
Modul de acces la date
Stabilirea modului de acces la date reprezint aproximativ 10% din ntregul efort de
dezvoltare a depozitului de date i este partea vizibil de care iau contact utilizatorii. De aceea,
modul acces este o component critic n vederea acceptrii depozitului de date de ctre
utilizatori.
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 test care are acces la depozitul de date. n acest fel, dezvoltatorii pot descoperi o serie de
probleme legate de funcionarea interfeelor.
Construirea rapoartelor i a interogrilor predefinite. Prototipul dezvoltat iniial este rafinat
n timpul dezvoltrii depozitului de date prin ncorporarea unor elemente furnizate de reacia
(feed-back) utilizatorilor 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.
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 depozit de date. Utilizatorul obinuit al depozitului de date are drepturi de

vizualizare i interogare asupra tabelelor din depozitul de date. Nu sunt permise
actualizri.
- Administrator depozit de date. Acest rol este atribuit pentru utilizatorii care trebuie s
poat efectua orice fel de operaii pe DD.
- Dezvoltator depozit de date. 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 depozitului.
ncrcarea depozitului de date
La anumite intervale de timp, datele din DD 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.
Este indicat 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 BD.
Depozitul de date este disponibil de regul utilizatorilor n orele de serviciu din timpul
zilei i din acest motiv el se ncarc deobicei noaptea sau la sfritul sptmnii.

Instruirea utilizatorilor
Instruirea pe tema depozitului de date care va fi implementat n curnd n ntreprindere este
absolut necesar pentru toi utilizatorii.
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:
o Definirea depozitului de date. Oamenii au ateptri diferite n ceea ce privete depozitul
de date. Instruirea trebuie s nceap neaprat cu definirea depozitului.
o Aria de cuprindere a depozitului de date. Toi utilizatorii trebuie s cunoasc coninutul
depozitului de date. Instruirea trebuie s evidenieze clar ce poate i ce nu poate s fac
depozitul de date.
o Folosirea interfeelor. Utilizatorii trebuie s invee cum s foloseasc fiecare instrument
n parte.
o Intervalul de ncrcare. Utilizatorii vor fi informai cu privire la intervalul de ncrcare a
datelor i la datele care suntncrcate.
o Aflarea rspunsurilor la alte ntrebri. Utilizatorii vor fi informai cum s obin diverse
informaii despre folosirea depozitului de date.
Instruirea categoriilor de utilizatori. Instruirea trebuie s cuprind pe acei utilizatori care vor
avea contact cu funcionalitile depozitului de date. Trebuie avut ns n vedere c utilizatorii
diferii au necesiti diferite. Dac numrul lor este mare, atunci ei pot fi mprii n dou
grupuri nceptori i avansai. Avansaii se vor plictisi n cazul n care li se prezint noiuni de
baz, n timp ce nceptorii vor fi depii de situaie dac se trece direct la chestiuni de finee.
Instruirea este de fapt pasul premergtor al testrii, deoarece utilizatorii nu vor putea testa corect
depozitul de date pn cnd nu sunt instruii cu privire la coninutul lui i la regulile care l
guverneaz.
Testarea depozitului de date
Pentru testarea depozitului de date se va face apel la reprezentanii utilizatorilor avnduse n obiectiv 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
nu trebuie s omit i varianta ca eroarea s provin de fapt din sistemul manual de obinere a
raportului.
- Performana. Ideal ar fi ca fiecare interogare lansat asupra depozitului de date s se execute
instantaneu, ns n lumea real valoarea acestui indicator depinde de mrimea depozitului de
date, de numrul de utilizatori i de capacitatea reelei. O metod de a ameliora acest indicator
este cea a folosirii valorilor 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).
Depozitul de date este acceptat doar dup ce testele s-au terminat cu succes i utilizatorii
s-au declarat mulumii de el. Pot fi stabilite anumite criterii de acceptare nainte de nceperea
implementrii, iar acceptul va fi obinut dac sunt ndeplinite aceste criterii.

2.4. Exploatarea Data Warehouse

Activitii de implementare a depozitului de date i urmeaz ntreinerea i dezvoltarea
depozitului. Acest lucru implic o serie de activiti specifice, derulate n momente diferite de
timp.
1. ncrcarea periodic a depozitului de date
Noi date trebuie ncrcate n mod regulat din sistemele surs n depozitul de date pentru
ca utilizatorii s poat beneficia de cele mai recente date. Acest lucru este n legtur direct cu
structura dimensiunii ierarhiei timp. Operaiunile de ncrcare a datelor se desfoar, de regul,
dup ncheierea programului de munc, seara sau noaptea, 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.
2. 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. Indicatorii statistici cel mai des folosii sunt
urmtorii:
o Numrul de interogri efectuate ntr-o zi. Acest indicator 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.
o Timpul mediu de rspuns la interogri. Acest indicator exprim timpul necesar pentru a
obine rezultatul din momentul n care a fost lansat interogarea n execuie.
o Numrul de excepii pe zi. Indicatorul caracterizeaz numrul de atenionri i de excepii
(erori) generate de depozitul de date, n cazul n care exist ncorporat un sistem pentru
aa ceva.
o Numrul de utilizatori. Indic numrul total de utilizatori care au acces la datele coninute
n depozit.
o Numrul zilnic de utilizatori. Indic numrul zilnic de utilizatori care folosesc efectiv
avantajele oferite de depozitul de date.

o Frecvena utilizrii. Acest indicator este foarte important, deoarece evideniaz numrul
de accesri ale depozitului de ctre un utilizator ntr-o anumit perioad de timp,
sugernd astfel gradul n care depozitul de date sprijin utilizatorul n activitile de zi cu
zi.
o Durata medie a sesiunii de lucru. Exprim perioada de timp n care utilizatorul rmne
conectat la depozitul de date.
o Intervalele de utilizare maxim a depozitului de date. Se are 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 este cel mai
utilizat.
o Subiectele interogate. Acest indicator 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.
o Mrimea depozitului de date. Dup fiecare ncrcare a depozitului de date, se determin
numrul de nregistrri din fiecare colecie de date pentru a obine rata de cretere a
depozitului de date.
3. Meninerea calitii datelor
Calitatea datelor este un aspect care trebuie s preocupe organizaia i dup
implementarea depozitului de date. Problema principal const n modul n care sunt abordate
erorile care apar n legtur cu funcionarea depozitului de date. Dou alternative referitoare la
calitatea datelor trebuie luate n considerare: ncrcarea n depozit numai a datelor corecte sau
ncrcarea tuturor datelor i efectuarea coreciilor pe parcurs.
n prim abordare, doar datele care sunt corecte sunt ncrcate n depozitul de date. n
felul acesta utilizatorii sunt siguri c depozitul 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 depozitului. De
asemenea, rezultatele multor interogri (de exemplu: care sunt primii 10 clieni sau care sunt
cele mai bine vndute produse?) nu vor fi relevante n cazul in care depozitul de date este
incomplet.
A doua abordare presupune ca toate datele s fie ncrcate n depozit, dar sunt definite i
implementate mecanisme pentru identificarea i corectarea erorilor. Dei acast abordare permite
ncrcarea depozitului cu toate datele din sistemele operaionale, calitatea datelor poate fi
necorespunztoare, iar deciziile care se iau pe baza lor pot fi inadecvate.
4. Evaluarea mrimii depozitului de date
ncrcarea iniial a depozitului de date poate s nu ridice probleme referitoare la
capacitatea de memorare, dar pe msura trecerii timpului depozitul poate crete cu fiecare nou
operaiune 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 solicitat de date, n special dac
datele sunt folosite doar la nivelurile de sintez. Datele analitice pot fi terse sau arhivate dup 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.
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.
5. Refacerea datelor n caz de accidente
La fel ca i la BD, 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 accidente 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.