Sunteți pe pagina 1din 21

CAPITOLUL 1

INTRODUCERE N TEHNOLOGIA DEPOZITELOR DE DATE

1.1. Depozitele de date yi tehnologiile societ(ii informa(ionale


1.2. Concepte de baz privind tehnologia depozitelor de date
1.3. Arhitectura depozitelor de date
1.4. Aspecte privind proiectarea yi realizarea depozitelor de date
1.5. Depozite de date versus baze de date opera(ionale

14 Capitolul 1, Introducere n tehnologia depozitelor de date
1.1. DEPOZITELE DE DATE $I TEHNOLOGIILE SOCIETTII
INFORMATIONALE
ConIorm unor studii recente, depozitele de date au devenit, la sIrsitul anilor
90 una din cele mai importante dezvoltri din domeniul sistemelor inIormationale
1
.
Palo Alto Management Group previziona nc din 1998 c piata data warehouse va
ajunge la 113.5 miliarde USD n 2002, incluznd aici vnzrile de sisteme data
warehouse, soItware adecvat si servicii
2
. Industria data warehouse s-a dezvoltat
continuu n termeni de investitii, produse disponibile si proiecte elaborate. Se
apreciaz c aproximativ 90 din companiile multinationale au implementate
depozite de date sau lucreaz la dezvoltarea unor proiecte data warehouse
3
.
Depozitele de date sunt produsul mediului economic si al tehnologiilor
avansate. Pe de o parte, mediul economic este tot mai competitiv, global si complex si
solicit inIormatii elaborate pentru sprijinirea deciziilor strategice iar, pe de alt parte,
evolutiile tehnologiilor inIormationale oIer solutii eIiciente de gestionare a unor
volume mari de date integrate, de ordinul terabytes-ilor, asigurnd niveluri de sintez/
detaliere adecvate. AstIel evolutiile perIormante din hardware cum sunt sistemele de
procesri masive paralele (Massive Parallel Processing MPP), sistemele de
multiprocesare simetric (symetric multi-processing SPM), sistemele tip baze de
date paralele Iac posibile ncrcarea, ntretinerea si accesul la baze de date de
dimensiuni uriase. Aplicatiile data warehouse sunt n msur s asigure si un timp
mediu de rspuns extrem de scurt pentru categorii extinse de utilizatori.
Depozitele de date (data warehouse) Iurnizeaz arhitecturi si instrumente utile
conducerii executive (business executives) prin organizarea sistematic, ntelegerea si
utilizarea datelor n luarea deciziilor strategice. Un mare numr de organizatii
consider c sistemele data warehouse dispun de instrumente valoroase n mediul
economic de astzi, mediu competitiv si n rapid evolutie. n ultimii ani multe Iirme
au cheltuit milioane de dolari cu realizarea de depozite de date. Mult lume si d
seama c n conditiile competitiei sporite din Iiecare industrie, depozitele de date sunt
armele care trebuie marketingului, reprezentnd calea de a pstra clientii.
Primele domenii care au adoptat tehnologia depozitelor de date au Iost
telecomunicatiile, bncile si comertul cu amnuntul. Ulterior depozitele de date au
ptruns si n alte domenii cum ar Ii industria Iarmaceutic, sistemul sanitar, asigurri,

1
Wixom, B., Watson, H., An Empirical Investigation oI the Factors AIIecting Data Warehousing
Success, MIS Quarterly Vol. 25 No. 1, March 2001, pp. 17-41.
2
Eckerson, W.W., Post-Chasm Warehousing, Journal oI Data Warehouse, Vol.3 no. 3, 1998, pp. 38-
45.
3
Humphries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and Implementation, Prentice
Hall PTR, Upper Saddle River, New Jersey, 1999, p. xvii.
Depozite de date 15
transporturi etc. Studiile statistice arat c telecomunicatiile si sistemul bancar se
mentin n top ntruct aloc cel putin 15 din bugetul IT pentru proiecte reIeritoare la
depozite de date
4
.
Un proiect data warehouse reprezint ns o investitie riscant si scump.
Costurile tipice pentru dezvoltarea unui depozit de date ntr-un interval de 3-6 luni se
situeaz ntre 0.8 si 2 milioane USD. Ponderea echipamentelor se situeaz ntre 1/2 si
2/3 din costul total al proiectului
5
. O solutie pentru Iirmele mici si mijlocii este
recurgerea la data marts pentru care costurile se situeaz sub 100 000 USD ntr-un
interval adesea sub 90 de zile
6
. Uneori investitiile n depozite de date nu se Iinalizeaz
cu succes. Motivatiile cele mai des ntlnite pentru esecul unor data warehouse includ
sustinerea insuIicient din partea conducerii organizatiei, insuIicienta Iondurilor si
politicile organizationale deIectuoase
7
.
1.2. CONCEPTE DE BAZ PRIVIND TEHNOLOGIA
DEPOZITELOR DE DATE
1.2.1. Depozite de date - delimitri conceptuale
Depozitele de date (data warehouse) au Iost deIinite n Ioarte multe moduri
nct este destul de diIicil de Iormulat o deIinitie riguroas. n sens larg, un depozit de
date reprezint o baz de date care este ntretinut separat de bazele de date
operationale ale organizatiei. Datele din sistemele surs sunt extrase, curtite,
transIormate si stocate n depozite speciale n scopul sprijinirii proceselor
decizionale
8
. Depozitele de date sprijin procesarea inIormatiilor Iurniznd o
platIorm solid de consolidare a datelor istorice pentru analiz. Un depozit de date
este o sum de date consistent din punct de vedere semantic care serveste la o
implementare Iizic a unui model de date pentru sprijinirea deciziei si stocheaz
inIormatii pe care o organizatie le solicit n luarea deciziilor strategice
9
.
n concordant cu W. H. Inmon, liderul n construirea sistemelor data
warehouse, ,un depozit de date este o colectie de date orientate pe subiecte, integrate,
istorice si nevolatile destinat sprijinirii procesului de luare a deciziilor

4
Kelly, S., Data Warehousing in Action, John Wiley & Sons, Chichester, 1997.
5
Humphries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and Implementation, Prentice
Hall PTR, Upper Saddle River, New Jersey, 1999, p. xvii.
6
Turban, E., Aronson, J., Decision Support Systems and Intelligent Systems, Sixth Edition, Prentice
Hall, Inc., Upper Saddle River, New Jersey, 2001, p. 145
7
Watson, H., Gerard, J., Gonzalez, L., Haywood, M., Fenton,D., Data Warehousing Failures: Case
Studies and Findings, Journal oI Data Warehousing Vol. 4 No. 1, 1999, pp. 44-55
8
Graz, P., Watson, H., Decision Support in the Data Warehouse, Prentice Hall, Upper Saddle River,
1998.
9
Han, J., Kamber, M., Data Mining: Concepts and Techniques, Morgan KauImann Publishers, San
Francisco, 2001, p.40.
16 Capitolul 1, Introducere n tehnologia depozitelor de date
manageriale
10
. n sintez, deIinitia prezentat mai sus exprim caracteristicile majore
ale depozitelor de date:
orientare pe subiecte;
integrare;
caracter istoric;
persistenta datelor.
Aceste caracteristici Iac distinctia ntre data warehouse si alte depozite de date
(data repository systems) cum ar Ii sistemele de baze de date relationale si sistemele
de prelucrare a tranzactiilor.
Orientarea pe subiecte. Sistemele operationale traditionale erau Iocalizate pe
datele cerute de compartimentele Iunctionale ale ntreprinderii. Odat cu reingineria
proceselor (Business Process Reengineering BPR) ntreprinderile ncep s axeze pe
cerintele decizionale ale echipelor de conducere. Sistemele operationale moderne sunt
orientate pe cerintele ntregului proces tranzactional si sprijin executia proceselor de
la nceput pn la sIrsit. Un depozit de date merge dincolo de inIormatiile
traditionale prin Iocalizarea pe subiecte ale activittii ntreprinderii cum ar Ii: clienti,
vnzri, proIituri etc. Aceste subiecte necesit inIormatii din diverse surse pentru a
Iurniza o imagine complet a domeniului. n loc de a se concentra pe procesarea
operatiilor si tranzactiilor zilnice dintr-o organizatie, un depozit de date se Iocalizeaz
pe modelarea si analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele de
date oIer, n mod tipic, o viziune simpl si concis relativ la un subiect speciIic
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, Iisiere, nregistrri privind
tranzactii on-line. Tehnicile de curtire a datelor (data cleaning) si de integrare sunt
aplicate pentru a asigura concordanta n conventiile de atribuire a numelor, de
codiIicare a structurilor, de atribuire a valorilor s.a.m.d.
Caracterul istoric. Datele sunt stocate pentru a Iurniza inIormatii n
perspectiv istoric (de exemplu, 5-10 ani n urm). AstIel decidentii pot consulta
valorile succesive ale acelorasi date pentru a determina evolutia n timp si a calcula
anumiti indicatori.
Persisten(a datelor. Datele dintr-un depozit sunt permanente si nu pot Ii
modiIicate. O actualizare a depozitului de date, ca urmare a modiIicrilor eIectuate n
datele surs, nsemn adugare de date noi Ir a modiIica sau sterge datele existente.
Un depozit de date este ntotdeauna memorat separat din punct de vedere Iizic de
datele transIormate din alte aplicatii. Datorit acestei separri, un depozit de date nu

10
Inmon, W.H., Building the Data Warehouse, New York, John Wiley & Sons, 1996.
Depozite de date 17
necesit mecanisme de procesare a concurentei. n mod uzual solicit numai dou
operatiuni n accesarea datelor: ncrcarea initial a datelor si accesul la date.
Alte deIinitii ale depozitelor de date surprind, cu unele nuantri, aceleasi
elemente esentiale:
Un depozit de date contine un volum Ioarte mare de date. Unele dintre
aceste date provin din sursele operationale ale organizatiei, altele pot
proveni din surse externe;
Depozitul de date este organizat astIel nct s Iaciliteze Iolosirea
datelor n scopuri decizionale.
Depozitul de date Iurnizeaz instrumente prin intermediul crora
utilizatorii Iinali pot accesa rapid datele.
n continuare prezentm cteva deIinitii reprezentative din literatura de
specialitate.
n viziunea lui Barry Devlin, un depozit de date nseamn ,o stocare a datelor
unitar, complet si consistent obtinut dintr-o varietate de surse, disponibil
utilizatorilor Iinali ntr-un mod usor perceptibil si utilizabil n contextul aIacerii
11
.
Dup Ralph Kimball ,depozitul de date oIer acces la datele organizationale;
datele continute sunt consistente; datele pot Ii separate si combinate n Iunctie de
Iiecare dimensiune sau aspect al aIacerii. Depozitul de date include, de asemenea, un
set de instrumente pentru interogare, analiz yi prezentare a inIormatiilor;
reprezint locul n care sunt publicate datele folosite; calitatea datelor continute n
depozit reprezint o premis pentru reingineria afacerii
12
.
Sam Anahory subliniaz Iinalitatea depozitelor de date preciznd c un depozit
de date include ,datele ... si procesele manageriale ... care Iac inIormatiile disponibile,
permitnd managerilor s ia decizii corect Iundamentate
13
.
De asemenea, o serie de Iirme si-au adus contributia n deIinirea, dezvoltarea
si popularizarea tehnologiilor data warehouseIBM, SoItware AG, Oracle, MicrosoIt,
Prism Solutions etc.
De exemplu, SoItware AG deIineste depozitul de date ca ,punctul central
pentru diIuzarea inIormatiilor ctre utilizatorii Iinali pentru sprijinirea deciziilor si
pentru acoperirea cerintelor inIormationale ale conducerii
14
.
IBM a propus un termen propriu pentru depozitele de date: InIormation
Warehouse. Dup unii autori, viziunea IBM se reIer mai degrab la conectivitatea

11
Devlin, B., Data Warehouse Irom Architecture to Implementation, Addison Wesley Longman,
Reading, Mass, 1997.
12
Kimball, R., The Data Warehouse Toolkit, Wiley, New York, 1996.
13
Anahory, S., Dennis, M., ,Data Warehousing in the Real World`, Addison Wesley Longman,
Reading, Mass, 1997.
14
SoItware AG., ,The Decision-Makers Goldmine. The Data Warehouse`, suplement to Datamation,
March 15, 1995.
18 Capitolul 1, Introducere n tehnologia depozitelor de date
global a diverselor surse de date, Iiind un Iel de 'middleware generalizat bazat pe
arhitectura proprie DRDA Distributed Relational Database Architecture
15

De altIel, n literatura de specialitate se Iolosesc si simultan cei doi termeni
pentru depozite de date: Data Warehouse si InIormation Warehouse. Dup EIraim
Turban, scopul unui 'data (or inIormation) warehouse este de a realiza un Iond de
date (data repository) care s Iac accesibile datele operationale ntr-o Iorm
acceptabil pentru asistarea deciziilor si pentru alte aplicatii
16
.
1.2.2. Data warehousing
n legtur cu depozitele de date o notiune Irecvent utilizat este cea de 'data
warehousing care desemneaz procesul de construire si utilizare a depozitelor de date
(data warehouse). Construirea unui depozit de date necesit integrarea datelor,
curtirea datelor (data cleaning) si consolidarea datelor. Utilizarea unui depozit de
date necesit adesea o colectie de tehnologii de asistare a deciziilor. Acestea permit
managerilor si specialistilor (de exemplu, analisti, consilieri etc.) s utilizeze depozitul
pentru a obtine rapid si convenabil datele necesare si s ia deciziile bazate pe
inIormatiile din depozit. Alti autori utilizeaz termenul de ,data warehousing pentru
a reIeri numai procesul de construire a depozitului de date, n timp de termenul de
,warehouse DBMS este utilizat pentru a reIeri conducerea si utilizarea depozitului de
date
17
.
n privin(a utilizrii datelor din depozitele de date trebuie precizat c multe
organizatii utilizeaz aceste inIormatii pentru sprijinirea lurii deciziilor n diIerite
domenii de activitate cum ar Ii:
sporirea Iocalizrii pe clienti care include analize ale vnzrilor
(preIerinte, periodicitate, cicluri bugetare, apetit pentru cumprare etc.)
reorientarea productiei si gestionarea portoIoliului de produse,
comparnd perIormantele vnzrilor pe trimestre, ani, zone geograIice,
n ordinea celor mai bune strategii de productie;
analiza operatiilor si cutarea surselor de proIit;
gestionarea relatiilor cu clientii,
gestionarea costului activelor corporale.
Data warehousing este, de asemenea, Ioarte util din punct de vedere al
integrrii surselor de date heterogene. Multe organizatii colecteaz, n mod obisnuit,
diIerite tipuri de date si ntretin baze de date mari din surse de inIormatii multiple,

15
Srbu, M., Data Warehouse. n cutarea deIinitiei, Revista Byte Romania, nr.3, 1996.
16
Turban, E., Aronson, J., Decision Support Systems and Intelligent Systems, Prentice Hall
International,m Upper Saddle River, New Jersey, 2001, p. 142.
17
Han, J., Kamber, M., Data Mining: Concepts and Techniques, Morgan KauImann Publishers, San
Francisco, 2001, p.41.
Depozite de date 19
heterogene, autonome si distributive. Integrarea acestor date si obtinerea unui acces
eIicient la ele este lucrul cel mai dorit. Multe eIorturi au Iost depuse n industria
bazelor de date si n comunittile de cercetare pentru ndeplinirea acestui scop.
n conceptia bazelor de date traditionale integrarea bazelor de date heterogene
este realizat de ,wrappers si integratori (integrators) sau mediatori (mediators)
asupra bazelor de date multiple (ex. IBM Data Joiner, InIormix Data Blade). Cnd o
interogare este pus unui site client, un dictionar de metadate este utilizat la
transIormarea interogrii n interogri corespunztoare site-urilor heterogene
implicate. Aceste interogri sunt atunci mapate si transmise proceselor locale de
interogare. Rezultatele primite de la diIerite site-uri sunt integrate n rspunsul global.
Aceast conceptie de interogare necesit procese complexe de Iiltrare si
integrare care concureaz la resursele de procesare. Este ineIicient si potential scump
pentru interogri Irecvente, n special pentru interogri ce solicit agregri. Data
warehousing Iurnizeaz o interesant alternativ la conceptul traditional de integrare a
bazelor de date heterogene descrise mai sus. Data warehousing Ioloseste conceptul
,update-driven n care inIormatiile din surse multiple, heterogene sunt interogate n
avans si stocate n depozitul de date pentru integrare direct si analiz. Spre deosebire
de bazele de date cu procesare on-line, depozitele de date nu contin inIormatiile cele
mai proaspete. Cu toate acestea, un depozit de date determin o nalt perIormant
prin integrarea bazelor de date heterogene ntruct datele sunt copiate, preprocesate,
integrate, adnotate, nsumate si restructurate ntr-o colectie semantic de date
(semantic data store). n plus procesul de interogare din depozitul de date nu
interIereaz cu procesele din sursele locale. De altIel, depozitele de date pot stoca si
integra inIormatii istorice si sprijin interogri multidimensionale complexe.
1.2.3. Obiectivele Data Warehouse
n sintez, scopurile unui depozit de date sunt urmtoarele:
S Iurnizeze utilizatorilor accesul sporit la date;
S Iurnizeze o singur versiune a adevrului;
S nregistreze cu acuratete trecutul;
S ,jongleze cu nivelurile de acces sintez/detaliu la date;
S separe prelucrrile de nivel operational si analitic;
Acces sporit la date pentru utilizatori. Depozitul de date Iurnizeaz accesul
la datele integrate ale ntreprinderii, anterior blocat prin ci neprietenoase. Utilizatorii
pot acum s stabileasc, cu un minim de eIort, o conexiune garantat la depozitul de
date prin intermediul unui microcalculator. Securitatea este ntrit prin ,the
warehouse Iront-end application, prin serverul bazei de date sau prin ambele.
20 Capitolul 1, Introducere n tehnologia depozitelor de date
O singur versiune a adevrului. Datele din depozitele de date sunt
consistente si au calitatea asigurat nainte de a Ii puse la dispozitia utilizatorilor
Iinali. 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 sedintele de
lucru. Depozitul de date ncepe s Iie resursa comun de date pentru nivelurile
decizionale din organizatii. Mentionm c ,o singur versiune a adevrului este
adesea posibil numai dup multe discutii si dezbateri asupra termenilor utilizati n
organizatie. De exemplu, termenul de ,client ru platnic poate avea mai multe
ntelesuri: client care nu plteste la timp, client care nu plteste dect partial, client
care nu plteste niciodat etc. Ar putea Ii stabilit si o alt acceptiune: clienti care au
datorii mai vechi de o lun. n mod sigur aceste acceptiuni au inIluent asupra
proceselor decizionale si asupra pertinentei deciziilor.
nregistrarea cu acurate(e a trecutului. Multe date primite de manageri nu
sunt semniIicative dac nu sunt comparate cu datele anterioare. De exemplu,
rapoartele care compar perIormantele actuale ale companiei cu cele din anul
precedent sunt comune. Rapoartele care arat perIormantele companiei pentru Iiecare
lun din ultimii trei ani pot Ii Ioarte interesante pentru decidenti. Sistemele
operationale nu vor putea permite acest gen de inIormatii. Un depozit de date va Ii
utilizat pentru nregistrarea cu acuratete a trecutului, prsind sistemele OLPT libere
pentru a realiza Iocalizarea pe corecta nregistrare curent a tranzactiilor. Datele
istorice sunt ncrcate si integrate cu alte date n depozit pentru un acces rapid.
Acces combinat sintez/detaliu la date. Rapoartele dinamice si instrumentele
de interogare OLAP (de exemplu, releveele din programele de calcul tabelar, drill up,
drill down) permit utilizatorilor s vizualizeze inIormatiile din depozitul de date sub
diIerite unghiuri si la diIerite niveluri de detaliere. Aceste disponibilitti oIerite de
depozitele de date reduc timpul si eIortul necesar pentru colectarea, Iormatarea si
Iiltrarea inIormatiilor plecnd de la date.
Separarea prelucrrilor de nivel opera(ional yi analitic. Procesele
decizionale si procesele operationale sunt totalmente divergente arhitectural.
ncercarea de a s reuni n acelasi sistem inIormatiile decizionale si operationale
determin ca ntretinerea sistemului s devin o problem.
Pornind de la procesele operationale depozitul de date Iurnizeaz o arhitectur
separat pentru implementarea deciziilor. Aceasta Iace ca ntreaga arhitectur IT a
ntreprinderii s devin mult mai deschis schimbrii cerintelor inIormationale.
Depozite de date 21
1.3. ARHITECTURA DEPOZITELOR DE DATE
1.3.1. Arhitectura simplificat a depozitelor de date
Esenta unui depozit de date const ntr-o baz de date de dimensiuni Ioarte
mari continnd inIormatiile pe care le pot Iolosi utilizatorii Iinali (clienti, Iurnizori,
companii de publicitate etc.). Arhitectura simpliIicat a unui depozit de date este
prezentat n Iigura nr. 1.1.
n depozitul de date ntlnim mai multe tipuri de date care corespund
diIeritelor cerinte inIormationale ale utilizatorilor: date detaliate, date agregate,
metadate. Metadatele descriu datele continute n depozitul de date si modul n care ele
sunt obtinute si stocate. Prin metadate se precizeaz structura datelor, provenienta lor,
regulile de transIormare, de agregare si de calcul. Metadatele joac un rol esential n
alimentarea depozitului cu date. Ele sunt utilizate n toate etapele de ncrcare a
datelor si sunt consultate si actualizate pe parcursul ntregului ciclu de viat al
depozitului. Includerea datelor agregate n depozit, desi determin o crestere a
redundantei datelor, este necesar deoarece n acest Iel se poate asigura un timp mediu
de rspuns ct mai redus.



Figura nr.1.1. Arhitectura de principiu a unui depozit de date
Sursele de date pentru depozite sunt: bazele de date operationale curente,
bazele de date vechi arhivate precum si bazele de date externe. Construirea
depozitului de date presupune parcurgerea urmtoarelor etape:
22 Capitolul 1, Introducere n tehnologia depozitelor de date
Un proces de extragere a datelor din bazele de date operationale sau
din surse externe urmat de copierea lor n depozitul de date. Acest
proces trebuie, cel mai adesea, s transIorme datele n structura si
Iormatul intern al depozitului.
Un proces de cur(ire a datelor, pentru a exista certitudinea c datele
sunt corecte si pot Ii utilizate pentru luarea deciziilor.
Un proces de ncrcare a datelor corecte n depozitul de date.
Un proces de creare a oricror agregri ale datelor: totaluri
precalculate, subtotaluri, valori medii etc. care se preconizeaz c vor Ii
cerute si Iolosite de utilizatori. Aceste agregri sunt stocate n depozitul
de date mpreun cu datele importate din sursele interne si externe.
Depozitele de date sunt destinate managerilor, analistilor si specialistilor
angrenati n luarea deciziilor strategice privind dezvoltarea si viitorul organizatiilor.
Pentru aceasta ei au nevoie de instrumente perIormante de accesare si utilizare a
datelor din depozite, instrumente asigurate prin soItware-ul asociat depozitului de
date. Pe de o parte, regsim instrumente necesare utilizatorilor care au nevoie de acces
rapid de inIormatii punctuale care includ un limbaj de interogare gen SQL sau
generatoare de rapoarte (Report Writers) ce transpun inIormatiile n Iormate adecvate.
Pe de alt parte, sunt intrumente specializate pentru asistarea deciziilor care
transIorm inIormatiile n Iorma cerut de decidenti (graIice, diagrame, organigrame)
sau oIer posibilitatea analizei tendintelor, corelatiilor si interpretarea acestora. n
aceast categorie se ncadreaz instrumentele OLAP si Datamining.
Instrumentele OLAP se bazeaz pe reprezentarea multidimensional a datelor
(cubul de date) si permite analiza interactiv si rapid a datelor prin operatiuni de tip
roll-up, drill-down, slice, dice etc. Utilizatorul poate obtine rezultate imediate
parcurgnd dinamic dimensiunile cubului de date lucrnd cu niveluri diIerite de
sintez/ detaliere.
Instrumentele de tip data mining asigur transIormarea datelor n cunostinte,
de aceea mult lume consider termenul data mining sinonim cu termenul de
Knowledge Discovery in Databases (KDD). Se utilizeaz tehnici ale analizei statistice
sau de inteligent artiIicial care permit descoperirea de corelatii, reguli, cunostinte
utile sprijinirii deciziilor.
ntreaga gam de instrumente soItware asociate depozitelor de date este
prezentat n Iigura nr.1.2. n partea stng snut evidentiate componentele din partea
de back-end (instrumente de extragere si transIormare) iar n partea dreapt
componentele din partea de Iront-end (instrumente de extragere si accesare a datelor).
Depozite de date 23

Figura nr. 1.2. Componentele soItware ale depozitelor de date
1.3.2. Arhitectura depozitelor de date pe trei niveluri
Adesea n depozitele de date se adopt o arhitectur pe trei niveluri
18
(bottom
tier, middle tier, top tier) ca n Iigura nr.1.3.
Nivelul de jos (bottom-tier) este constituit din serverul DD si este, n multe
cazuri, un sistem baze de date relationale. Datele din bazele de date operationale si din
sursele externe (cum ar Ii inIormatii relative la proIilul clientului Iurnizate de
consultanti externi, rezultatele unor sondaje) sunt extrase utiliznd programe de
aplicatii tip interIata cunoscute sub numele de ,gateways. Un gateway este sprijinit
de SGBD-ul de baz si permite programelor client s genereze cod SQL pentru a Ii
executat de server. Exemplele gateways includ ODBC (Open Database Connection) si
OLE-DB (Open Linking and Embedding Ior Databases) la MicrosoIt si JDBC (Java
Database Connection). n acest mod datele sunt extrase, curtite, transIormate si
ncrcate n depozitul de date. De asemenea, trebuie luat n considerare si
modalitatea de mprosptare a datelor din depozit, pe msura trecerii timpului. Dac,
de exemplu, dimensiunea timp are n structur luna, trimestru, an nseamn c la

18
Han, J., Kamber, M., Data Mining: Concepts and Techniques, Morgan KauImann Publishers, San
Francisco, 2001, p.66.
24 Capitolul 1, Introducere n tehnologia depozitelor de date
sIrsitul Iiecrei luni, a Iiecrui trimestru sau a Iiecrui an datele din sistemul
operational trebuie s mprospteze depozitul de date.
Nivelul mediu (middle tier) bazat pe un server OLAP care este implementat n
mod obisnuit, utiliznd Iie un model relational OLAP (ROLAP) Iie un model
multidimensional OLAP (MOLAP). Modelul ROLAP este o extensie a unui SGBDR
care mapeaz operatiunile pe date multidimensionale la operatiunile relationale
standard. Modelul MOLAP este dedicat si implementeaz direct descrierea datelor si
a operatiilor multidimenionale.
Nivelul superior (top tier) este nivelul client care contine instrumente pentru
generarea interogrilor si a rapoartelor, instrumente de analiz si/sau instrumente data
mining (de exemplu, analiza trendului, predictii etc.)

Fig.nr.1.3. Arhitectura Data warehouse cu trei niveluri
Depozite de date 25
1.3.3. Tipuri de depozite de date
Din punct de vedere al ariei de cuprindere, se ntlnesc trei modele de depozite
de date: depozite de ntreprindere (entreprise warehouse), data mart si depozite
virtuale de date.
Un depozit de ntreprindere (Entreprise Warehouse) colecteaz toate
inIormatiile despre subiecte care privesc ntreaga organizatie. El Iurnizeaz un volum
extins de date. De regul contine date detaliate dar si date agregate, iar ca ordin de
mrime porneste de la ctiva gigabytes pn la sute de gigabytes, terabytes sau mai
mult. Un depozit de date de ntreprindere poate Ii implementat pe traditionalele
mainIrames, pe superservere UNIX sau pe platIorme cu arhitecturi paralele. Necesit
cheltuieli mai mari pentru modelare si ani de zile pentru proiectare si realizare.
Un data mart contine un subset al volumului de date din organizatie, speciIic
unui grup de utilizatori. Domeniul este limitat la subiecte speciIice. De exemplu, un
data mart pentru marketing limiteaz subiectele la clienti, articole, vnzri. Datele
continute n data mart sunt de obicei agregate. Data marts sunt, n mod curent,
implementate pe servere departamentale mai ieItine care se bazeaz pe UNIX sau
Windows/NT. Ciclul de implementare al unui data mart este mai curnd msurat n
sptmni dect n luni sau ani. Ca atare, un data mart poate Ii considerat un
subansamblu al unui depozit de date mai usor de construit si ntretinut si mai putin
scump.
Un depozit virtual (Virtual warehouse) este un set viziuni (views) asupra
bazelor de date operationale. Pentru eIicienta procesrii interogrilor numai unele din
viziunile de agregare pot Ii materializate. Un depozit virtual este usor de construit dar
necesit capacitti suplimentare pe serverele de baze de date.
1.4. ASPECTE PRIVIND PROIECTAREA $I REALIZAREA
DEPOZITELOR DE DATE
1.4.1. O schem de analiz economic pentru proiectarea unui
depozit de date
Proiectarea unui depozit de date presupune aplicarea unei scheme de analiz
economic pentru a determina msura n care depozitul de date este necesar si
eIicient.
n primul rnd, trebuie ca depozitul de date s Iurnizeze avantaje competitive
prezentnd inIormatii relevante pe baza crora putem msura perIormantele si putem
Iace ajustrile critice pentru a cstiga n Iata competitorilor.
26 Capitolul 1, Introducere n tehnologia depozitelor de date
n al doilea rnd, un depozit de date poate determina cresterea productivittii
din moment ce permite obtinerea rapid si eIicient de inIormatii care descriu cu
acuratete organizatia.
n al treilea rnd, un depozit de date Iaciliteaz gestiunea relatiilor cu clientii
din moment ce Iurnizeaz o viziune consistent despre clienti si produse ntlnite pe
toate liniile de aIaceri, pe toate departamentele si pe toate pietele.
n Iinal, un depozit de date determin reducerea costurilor prin relieIarea
tendintelor, directiilor si exceptiilor pe perioade lungi de timp.
Pentru proiectarea unui depozit de date este necesar ntelegerea si analiza
proceselor economice din domeniu si construirea unei scheme de analiz economic.
Construirea unui sistem inIormational complex si vast poate Ii comparat cu ridicarea
unei cldiri mari si complexe, pentru care proprietarul, arhitectul si constructorul au
diIerite viziuni. Aceste viziuni sunt combinate ntr-o schem complex care reprezint
perspectiva top-down, perspectiva proprietarului sau, la Iel de bine, perspectiva
bottom-up sau viziunea celui care implementeaz sistemul inIormational.
1.4.2. Viziuni de proiectare a unui depozit de date
Proiectarea unui depozit de date poate lua n considerare viziuni diIerite:
viziunea top-down, viziunea datelor surs (data source view), viziunea depozitelor de
date si viziunea business query.
Viziunea top-down permite selectarea inIormatiilor relevante necesare n
depozitul de date. Aceste inIormatii reprezint un sprijin decizional n activitatea
curent.
Viziunea datelor surs (data source view) exprim inIormatiile culese,
stocate si gestionate de sistemele operationale. Aceste inIormatii pot Ii documentate
pe niveluri variate de detaliere si acuratete, de la tabele individuale de date surs la
tabele de date integrate. Datele surs sunt adesea modelate prin tehnicile traditionale
de modelare a datelor cum sunt diagramele E-A (Entitate Asociatie) sau
instrumentele CASE.
Viziunea depozitelor de date are n vedere tabelele de Iapte si tabelele
dimensiune. Reprezint inIormatiile care sunt stocate n depozitele de date, incluznd
contorizri si totaluri precalculate, ca si inIormatii privitoare la sursa, data
calendaristic, origine adugate pentru a Iurniza contextul istoric.
Viziunea business query oIer o perspectiv din punct de vedere al
utilizatorului Iinal.
Construirea si utilizarea unui depozit de date este o sarcin complex din
moment ce necesit abilitti de aIaceri, abilitti tehnologice si manageriale. Abilittile
de aIaceri necesare construirii unui depozit de date se reIer la ntelegerea modului n
care sistemele stocheaz si gestioneaz datele, la modul de Iunctionare a
Depozite de date 27
instrumentelor de extragere care transIer datele din sistemul operational n depozite
de date, la modul cum se construieste soItware-ul pentru mprosptarea depozitului
prin preluarea datelor din sistemele operationale. Utilizarea unor depozite de date
implic ntelegerea semniIicatiei datelor continute, ca si ntelegerea si traducerea
cerintelor inIormationale n interogri care pot Ii satisIcute de depozitele de date.
ReIeritor la abilittile tehnologice, analistii datelor trebuie s nteleag cum se
obtin inIormatii cantitative si Iapte derivate bazate pe concluzii de la inIormatiile
istorice din depozitele de date. Aceste ndemnri includ abilitatea de a descoperi
modele si tendinte, de a extrapola trendul bazndu-se pe date istorice, de a vedea
anomaliile sau paradigmele si de a prezenta recomandri manageriale concrete bazate
pe asemenea analize.
Abilittile de gestiune a programelor permit intermedierea interIetei cu
productorii, vnztorii si utilizatorii Iinali n privinta distribuirii rezultatelor rapid si
la costuri acceptabile.
1.4.3. Procesul de proiectare a unui depozit de date
Un depozit de date poate Ii proiectat si construit utiliznd abordarea top-down,
abordarea bottom-up sau combinatii ale acestora.
Abordarea top-down porneste cu proiectarea si planiIicarea complet. Se
utilizeaz n cazul cnd tehnologia este matur si bine cunoscut si problemele
economice care trebuie rezolvate sunt clare si bine ntelese.
Abordarea bottom-up porneste cu experimente si prototipuri. Aceasta este
utilizat la nceputul stadiului de modelare si de dezvoltare tehnologic. Ea permite
unei organizatii s mearg nainte cu cheltuieli considerabil mai mici si s evalueze
beneIiciile tehnologiei nainte de a Iace angajamente semniIicative n aceast directie.
n abordarea combinat, o organizatie poate exploata caracterul planiIicat si
strategic al abordrii top-down att timp ct retinem avantajele implementrii rapide si
oportune a aplicatiilor dup abordarea bottom-up.
Din punct de vedere al ingineriei programrii, proiectarea si construirea unui
depozit de date const n urmtorii pasi: planiIicare, studiul cerintelor, analiza
problemei, proiectarea depozitului, integrarea datelor si testarea si, n Iinal, utilizarea
depozitului de date. Sistemele soItware mari pot Ii dezvoltate utiliznd dou
metodologii: metoda n cascad sau metoda n spiral.
Metoda n cascad execut o analiz structurat si sistematic la Iiecare pas
nainte de a trece la urmtorul.
Metoda n spiral implic generarea rapid de sisteme Iunctionale din ce n ce
mai complete, la intervale scurte, ntre dou versiuni succesive. Acest lucru constituie
un atu important pentru dezvoltarea depozitelor de date, n special pentru data marts
28 Capitolul 1, Introducere n tehnologia depozitelor de date
pentru c intervalul de realizare este scurt, modiIicrile pot Ii Icute rapid si noile
proiecte si tehnologii pot Ii adaptate n mod rapid.
n general, procesul de proiectare a depozitului const n urmtorii pasi:
1. Alegerea procesului economic de modelat, de exemplu: stocuri,
vnzri etc. Dac procesul economic este organizational si implic
colectii de obiecte complexe si multiple modelul tip depozit de date
trebuie realizat. Dac procesul este departamental si Iocalizat pe
analiza unui singur domeniu va Ii ales modelul data marts.
2. Alegerea nivelului de granularitate. Nivelul de granularitate este
nivelul de date Iundamental, atomic care va Ii Iolosit pentru
reprezentarea datelor n tabelul de Iapte pentru Iiecare proces.
3. Alegerea dimensiunilor care vor Ii aplicate la Iiecare nregistrare din
tabelul de Iapte. Dimensiunile tipice sunt: timp, articol, client, Iurnizor,
depozit, tip tranzactii si stare.
4. Alegerea msurilor (valorilor) care vor popula Iiecare nregistrare din
tabelul de Iapte. Valorile tipice sunt numerice: de exemplu, vnzrilei
si cantitatevndut.
Din moment ce construirea unui depozit de date este o sarcin diIicil si pe
termen lung, ocaziile de implementare trebuie clar deIinite. Scopurile unei
implementri initiale ale unui depozit de date ar trebui s Iie speciIice, realizabile si
msurabile. Aceasta implic determinarea timpului si bugetului alocat, a subsetului
din organizatie care trebuie modelat, a numrului de surse de date selectate, a
numrului si a tipurilor de departamente utilizatoare.
Odat ce depozitul de date este proiectat si construit, dezvoltarea initial a
depozitului include instalarea initial, planiIicarea derulrii depozitului de date,
instruirea si orientarea. Actualizarea platIormelor si ntretinerea lor trebuie de
asemenea, luate n considerare. Administrarea depozitului de date include
mprosptarea datelor, sincronizarea datelor surs, planiIicarea reacoperirilor,
gestiunea controlului pentru acces si securitate, extinderea depozitului de date. SIera
managementului include controlarea numrului si ariei de interogri, dimensiuni,
rapoarte, limitarea mrimii depozitului de date sau limitarea bugetului si resurselor.
Sunt disponibile categorii variate de instrumente de proiectare a depozitelor de
date. Instrumentele de dezvoltare a depozitelor de date Iurnizeaz Iunctii de deIinire si
editare a depozitului de metadate (scheme, scripturi, reguli), interogri, rapoarte de
iesire etc.. Instrumentele de analiz si planiIicare studiaz impactul schimbrilor si
mbunttirea perIormantelor cnd se schimb intervalele de timp.
Depozite de date 29
1.4.4. Dezvoltarea incremental a depozitelor de date
Dezvoltarea top-down a unui depozit de ntreprindere constituie o solutie
sistemic si minimizeaz integrarea problemelor. Totusi, ea este scump, solicit timp
ndelungat pentru dezvoltare si i lipseste Ilexibilitatea determinat de diIiculttile n
realizarea modelelor de date pentru ntreaga organizatie.
Abordarea bottom-up n proiectarea, dezvoltarea si aplicarea data marts
independente Iurnizeaz Ilexibilitate, costuri sczute si recuperarea rapid a
investitiei. Totusi poate determina probleme cnd se ncearc integrarea ntr-un
depozit de date consistent la nivel de ntreprindere.
O metod recomandat pentru dezvoltarea sistemelor tip depozite de date este
implementarea depozitelor ntr-o manier incremental si evolutiv prezentat n
Iigura nr. 1.4.
n primul rnd, modelul de date la nivel superior este deIinit n perioade
rezonabile de timp (una sau dou luni) ceea ce Iurnizeaz consistenta, integrarea
viziunilor de date (view) ntre diIerite subiecte si potentiali utilizatori. Acest model de
nivel superior, cu toate c va Ii raIinat (perIectionat) n urmtoarele dezvoltri ale
depozitului de date de ntreprindere si a data marts departamentale, va determina o
reducere a integrrii viitoare a problemelor.

Figura nr. 1.4. Procesul de dezvoltare a depozitelor de date
n al doilea rnd, mai multe data marts independente pot Ii implementate
paralel cu depozitul de ntreprindere bazat pe acelasi model de date.
n al treilea rnd, data marts distribuite pot Ii construite prin intermediul hub
serverelor.
30 Capitolul 1, Introducere n tehnologia depozitelor de date
n ultimul rnd, un depozit de date multinivel este construit cnd depozitul de
ntreprindere contine toate depozitele de date care sunt distribuite n diIerite data
marts.
1.5. DEPOZITE DE DATE VERSUS BAZE DE DATE
OPERATIONALE
1.5.1. Diferen(e ntre sistemele de baze de date opera(ionale yi
depozitele de date
O comparatie ntre bazele de date si depozitele de date este n msur s oIere
o imagime coerent privind rolul depozitelor de date n organizatii precum si
raporturile cu alte tipuri de sisteme inIormatice. Att bazele de date ct si depozitele
de date contin mari cantitti de date structurate care pot Ii consultate rapid datorit
structurilor de acces optimizate si se bazeaz, n majoritatea cazurilor, pe tehnologii
relationale. Totusi ele nu au Iost proiectate pornind de la aceleasi obiective si se
diIerentiaz prin numeroase aspecte
Sistemele de gestiune a bazelor de date sunt adecvate aplicatiilor curente de
gestiune si servesc la crearea si ntretinerea sistemelor de baze de date operationale.
Aceste sisteme cunoscute sub denumirea de sisteme OLTP (On-Line Transaction
Processing) au ca obiectiv executia on-line a tranzactiilor si a proceselor de
interogare. Ele ncorporeaz toate operatiile zilnice dintr-o organizatie cum ar Ii:
aprovizionri, stocuri, productie, decontri, plti, contabilitate. Sistemele depozite de
date, pe de alt parte, servesc utilizatorii sau specialistii n domeniul analizei datelor si
lurii deciziilor. Aceste sisteme pot organiza si prezenta datele n Iormate variate n
ordinea solicitrilor de la diIeriti utilizatori. Aceste sisteme sunt cunoscute sub numele
de sisteme OLAP (On-Line Analytical Processing).
Bazele de date din sistemele operationale contin date curente, detaliate care
trebuie actualizate si interogate rapid, n conditii de deplin securitate, constituind
suportul sistemelor inIormationale de prelucrare a tranzactiilor (TPS).
Depozitele de date sunt concepute special pentru sprijinirea lurii deciziilor.
Ele au ca obiectiv regruparea datelor, agregarea si sintetizarea lor, organizarea si
coordonarea inIormatiilor provenind din surse diIerite, integrarea si stocarea acestora
pentru a da decidentilor o imagine adecvat care s permit regsirea si analiza
eIicace a inIormatiilor necesare. Interogrile obisnuite ntr-un depozit de date sunt mai
complexe si mai variate dect cele din sistemele de gestiune a bazelor de date. Ele se
aplic asupra unor volume Ioarte mari de date si presupun calcule complexe (analiza
tendintei, medii, dispersii etc.) care necesit adesea agregri (group by).
Depozite de date 31
Deosebirile majore ntre OLTP si OLAP sunt sintetizate n tabelul nr. 1.1. si
iau n considerare urmtoarele trsturi: utilizatorii si orientarea sistemului, caracterul
datelor continute, nivelul de sintez, unitatea de lucru, schemele de acces, numrul de
nregistrri accesate, mrimea bazelor de date, sistemul de evaluare etc.
Tabelul nr. 1.1 Comparatie ntre sistemele OLTP i OLAP
Nr.
crt.
Trsturi OLTP OLAP
1 Destinatia Procese operationale Procese inIormationale
2 Orientarea sistemului Tranzactii Analize
3
Utilizatori Functionari,
administratori BD,
proIesionisti BD
Specialisti, manageri,
executivi, analisti
4 Functii Operatii zilnice Cerinte inIormationale pe
termen lung, asistarea
deciziei
5 Instrumente Iolosite n
proiectare
Diagrame E-A Star/ snowIlake
6 Caracterul datelor Curente, noutate
garantat
Istorice, precizie
mentinut n timp
7 Nivelul de sintez Primitive, detaliere
ridicat
Sintetizare, consolidare
8 Unitatea de lucru Scurt, tranzactii simple Interogri complexe
9 Scheme de acces Read/write Aproape ntotdeauna
Read
10 Focalizare Culegere date Furnizare inIormatii
11 Numr de nregistrri
accesate
Zeci Milioane
12 Numr de utilizatori Mii Sute
13 Mrimea bazelor de date 100 MB GB 100 GB TB
14 Prioritti PerIormante ridicate,
disponibilitate ridicat
Flexibilitate ridicat,
autonomie utilizatori Iinali
15 Sistem de evaluare Tranzactii culese Interogri culese, timp de
rspuns

Un sistem OLTP este orientat pe client (customer oriented) si este utilizat
pentru procesarea tranzactiilor si interogrilor. Un sistem OLAP este orientat spre
piat (market-oriented) si este utilizat de manageri, analisti si specialisti. Din punct de
vedere al datelor continute un OLTP gestioneaz date curente care, n mod obisnuit,
sunt destul de detaliate pentru a Ii usor utilizate n luarea deciziilor curente. Un sistem
OLAP gestioneaz volume mari de date istorice Iurniznd Iacilitti pentru sintetizare
si agregare precum si pentru stocarea si gestionarea inIormatiilor cu diIerite niveluri
de granularitate. Aceste aspecte Iac ca datele s Iie usor utilizate de ctre decidenti,
mai ales n domeniile tactic si strategic. De asemenea, un sistem OLTP este Iocalizat
n principal pe datele curente dintr-o ntreprindere sau dintr-un departament Ir a
reIeri date istorice sau date din alte organizatii. n contrast, un sistem OLAP cuprinde
32 Capitolul 1, Introducere n tehnologia depozitelor de date
date istorice si date care provin de la diIerite organizatii, integrnd inIormatii din
surse heterogene. n sistemele OLTP unittile de acces sunt, n principal, tranzactiile
atomice. Aceste sisteme necesit mecanisme de control al concurentei si de
reacoperire. Accesul la sistemele OLAP este cel mai adesea de tip read-only, cu toate
acestea este posibil realizarea de interogri complexe.
1.5.2. De ce trebuie un depozit de date separat?
De ce nu se execut procesri analitice on-line (OLAP) direct pe bazele de
date existente mai degrab dect a cheltui timp si resurse pentru a construi separat un
depozit de date? Este o ntrebare pertinent iar rspunsul poate explica si Iundamenta
investitia ntr-un depozit de date. Argumentul Iorte pentru aceast separare este
promovarea perIormantei ridicate n ambele sisteme.
O baz de date operational este proiectat si adaptat pornind de la sarcini si
activitti cunoscute cum ar Ii indexarea, utilizarea cheile primare, cutarea unor
nregistrri speciIice, optimizarea interogrilor. Pe de alt parte, interogrile unui
depozit de date sunt adesea complexe. Ele implic calcule asupra unor grupuri mari de
date cu totalizri pe diIerite niveluri ce pot necesita utilizarea de metode speciale de
organizare a datelor, de acces si implementare bazate pe viziuni multidimensionale.
Procesnd interogrile OLAP ntr-o baz de date operational s-ar degrada substantial
perIormantele sarcinilor operationale. De altIel, o baz de date operational sprijin
procesarea concurent a tranzactiilor multiple. Controlul concurentei si mecanismele
de reacoperire sunt necesare pentru a asigura consistenta si robustetea tranzactiilor. O
interogare OLAP are nevoie adesea de acces read-only la nregistrri pentru
sumarizare si agregare. Controlul concurentei si mecanismele de reacoperire, dac
sunt aplicate pentru operatiunile OLAP pot primejdui executia tranzactiilor
concurente si astIel s reduc substantial consistenta unui sistem OLTP.
n Iinal, separarea dintre BD operationale si depozitele de date se bazeaz pe
structuri, continut, utilizatori si date diIerite. Luarea deciziilor necesit date istorice pe
cnd bazele de date operationale nu contin, n mod obisnuit, date istorice. n acest
context, datele operationale, desi abundente, sunt, n mod obisnuit, departe de a Ii
complete pentru luarea deciziilor. Asistarea deciziei solicit consolidarea datelor
(totalizri si agregri) din diIerite surse, rezultnd date de nalt calitate, curate si
integrate. n contrast, bazele de date operationale contin numai date neprelucrate
(primare) detaliate, cum sunt tranzactiile care trebuie consolidate naintea analizelor.
Dat Iiind c cele dou sisteme au Iunctionalitti diIerite si necesit tipuri diIerite de
date este necesar s le mentinem n baze de date separate. Totusi multi vnztori de
SGBD-uri operationale au nceput optimizarea acestor sisteme, asa nct ele suport
interogrile OLAP. Pe linia acestui trend, separarea intre sistemele OLPT si OLAP
este de asteptat s scad.
Depozite de date 33
1.5.3. Depozite de date sau magazine de date
Discutiile despre depozitele de date conduc, n mod natural, la magazine de
date (Operational Data Stores ODS), care la prima vedere nu se deosebesc de
depozitele de date. Desi ambele tehnologii sprijin decidentii, ele sunt diIerite
deoarece sunt destinate s acopere anumite tipuri de cerinte inIormationale.
W.H.Inmon, C. ImhoII, G. Battas
19
deIinesc un ODS ca ,o constructie
arhitectural unde este stocat o colectie integrat de date operationale. Un magazin
de date poate Ii deIinit, de asemenea, ca o colectie de baze de date proiectate pentru
sprijinirea controlului operational. Spre deosebire de bazele de date din aplicatiile
OLPT (care sunt operationale sau orientate pe Iunctii), magazinele de date contin date
orientate pe subiecte din ntreprinderi mari. Spre deosebire de depozitele de date,
datele din ODS sunt volatile si detaliate. ODS Iurnizeaz o viziune integrat asupra
datelor din sistemele operationale. Tabelul nr.1.2. prezint comparativ depozitele de
date si magazinele de date.

Tabelul nr.1.2. Depozite de date n compara[ie cu Magazinele de date
Data Warehouse Operational Data Store
Scopuri Sprijinirea deciziilor
strategice
Control operational
Asemnri Date integrate
Orientare pe subiecte
Date integrate
Orientare pe subiecte
Deosebiri Date statice
Date istorice
Date sintetice
Date volatile
Date curente
Detaliere ridicat

Pentru construirea unui magazin de date datele sunt transIormate si integrate
ntr-o Iorm consistent, uniIicat, pornind de la sistemele legacy si alte sisteme
operationale pentru a Iurniza utilizatorilor imagini integrate si actuale ale
operatiunilor. Datele din magazinul de date sunt permanent mprosptate, rezultnd o
imagine Iidel a ultimelor stri ale operatiunilor.


19
Inmon, W.H., ImhoII C., Battas, G., Building the Operational Data Store, John Wiley & Sons, 1996.

S-ar putea să vă placă și