Cursul 5

2.3.2. Depozite de Date

Un depozit de date furnizeaz o surs integrat i centralizat de date, aparte fa
de sistemul tranzacional, care conine datele eseniale despre activitatea companiei din
multitudinea de surse de date existente. Rapoartele obinute pe baza acestor date sunt
utilizate ca un instrument de analiz strategic i competitiv. Analizele rapide i corecte
pot influena deciziile privind evoluia organizaiei pe termen mediu i lung.
O definiie a depozitelor de date formulat de ctre Consiliul OLAP este
urmtoarea [OLAP95]:
Un depozit de date reprezint o stocare centralizat a datelor detaliate
provenite din toate sursele relevante din cadrul unei organizaii ce permite
interogarea dinamic i analiza detaliat a tuturor informaiilor.
Spre deosebire de sistemele operaionale, structurile de date ntr-un depozit de
date sunt optimizate pentru o regsire i o analiz rapid. Datele sunt istorice i sunt
actualizate la intervale regulate de timp, n funcie de cerinele de raportare.
Definiia lui William Inmon, cunoscut drept printele acestui concept (de altfel
deine i trademark-ul pentru datawarehouse) este extrem de concis: un depozit de date
este o colecie de date orientate pe subiecte, integrate, istorice i nevolatile destinat
sprijinirii procesului de luare a deciziilor manageriale (A data warehouse is a subjectoriented, integrated, time-variant and nonvolatile collection of data in support of
management's decision making process) [INMO96]
n viziunea lui Ralph Kimball [KIMB96] depozitul de date ofer acces la datele
organizaionale, datele obinute sunt consistente i pot fi separate sau combinate n
funcie de fiecare dimensiune sau aspect al afacerii. Depozitul de date include, de
asemenea un set de instrumente pentru interogare, analiz i prezentare a informaiilor;
reprezint locul n care sunt publicate datele folosite. Calitatea datelor coninute n
depozit reprezint o premiz pentru reingineria afacerii.
Dup Barry Devlin [DEVL97], un depozit de date nseamn o stocare a datelor,
unitar, complet i consistent, obinut dintr-o varietate de surse, disponibil
utilizatorilor finali ntr-un mod uor perceptibil i utilizabil n contextul afacerii.
Sam Anahory [ANDE97] subliniaz finalitatea depozitelor de date, preciznd c
un depozit de date include datele i procesele manageriale care fac informaiile
disponibile, permind managerilor s ia decizii corect fundamentate.
Exist o serie de firme binecunoscute care i-au adus contribuia n definirea,
dezvoltarea i popularizarea tehnologiilor de data warehouse precum: IBM, Software AG,
Oracle, Microsoft, Prism Solution etc.
Creterea volumului de informaii, precum i perfecionarea software-ului de
exploatare a acestuia, au condus la o nou calitate a folosirii datelor prin analize care pot
releva conducerii organizaiei informaii greu sau chiar imposibil de obinut pe alte ci.
Se pot obine astfel informaii privind preferinele clienilor, profilul lor, distribuia etc.
Astfel se pot furniza conducerii date, cum ar fi de exemplu: n ce regiune a rii se
vinde mai bine un anumit produs, care sunt preferinele unui anumit segment de pia etc.
Este evident c astfel de informaii nu se pot obine dect folosind anumite
prelucrri, cum ar fi analiza multidimensional, anumite metode statistice de prognoz

Cursul 5
sau alte metode matematice aplicate unui volum foarte mare de date. Aceste metode
matematice reclam folosirea unui software specializat deosebit de complex. Analiza
matematic a datelor aflate n astfel de depozite de date a cptat denumirea de data
mining (minerit al datelor). Din volumul foarte mare de date se extrag numai datele
relevante, celelalte fiind ignorate. Pentru astfel de aplicaii datele trebuie bine organizate
i indexate pentru o uoar regsire si utilizare.
Pentru a ne da seama de dimensiunile fenomenului vor fi oferite cteva cifre
semnificative [VILA97]. Un depozit de date este alctuit din baze de date coninnd intre
1 i peste 10 terrabyte, aceste cifre neavnd dect un caracter orientativ. Exist astfel i
depozite de date coninnd zeci de terrabyte. Crearea unui astfel de depozit cost n jur de
3 milioane $. Din acest cost, o treime o reprezint serviciile profesionale. O alt treime se
cheltuiete pentru software-ul necesar extragerii, prelucrrii, depozitrii i analizrii
datelor, iar ultima treime este destinat sistemelor hardware necesare i stocrii datelor.
De obicei, depozitele de date i dubleaz dimensiunile n primele 12 pn la 18 luni.
Aceast cretere exponenial poate fi pe de o parte semnul sigur al succesului
implementrii depozitelor dar, pe de alta parte, poate deveni o problem, dac sistemele
nu sunt construite de la nceput suficient de elastice i de deschise.

Figura 2.12. Structura cheltuielilor pentru crearea unui depozit de date

Din cele de mai sus rezult importana deosebit a flexibilitii impuse sistemelor
care adpostesc asemenea depozite de date. n acest caz, flexibilitate nseamn o
conectivitate la nivelul ntregii organizaii, astfel nct servere provenind de la furnizori
diferii s se poat conecta simultan la depozitul deja existent. Este, de asemenea,
deosebit de important s se aleag o arhitectur care s se adapteze uor la modificrile
de performane, capacitate i conectivitate. Procesele de configurare, optimizare si
administrare a sistemului, inclusiv procedurile de salvare - restaurare, precum si pstrarea
n tot acest timp a funcionalitii sistemului pot deveni operaii extrem de dificile dac
trebuie repetate la fiecare adugare a unor noi servere n sistem.
Pentru a evita aceste probleme, se poate alege o cale de mijloc i se poate crea un
sub-depozit care s conin numai datele relevante pentru analiza necesar. Astfel de subdepozite sunt numite data marts i pot fi fcute s funcioneze pe configuraii mai
modeste dect depozitele de date.
Un astfel de data mart este un depozit de date specific unui anumit subset de
cerine sau unui anumit departament din cadrul organizaiei. n timp ce un depozit de date
conine datele care pot fi utilizate pentru a rspunde oricrei ntrebri privind afacerile

Cursul 5
unei companii, un data mart conine datele pertinente unui anumit compartiment al
companiei. Departamentele pot folosi n comun datele lor, conectnd mpreun data
mart-urile aferente diferitelor compartimente ale companiei i formnd astfel o
infrastructur specific pe baza creia se poate crea un sistem de suport al deciziei mai
uor de construit i mai elastic.
Un data mart care poate utiliza serverele existente, structura informaional
existent (un LAN sau un Intranet) cu mai puin de 500 GB, cost ai puin de 1 milion de
dolari i se implementeaz,de obicei, n 90 de zile. Companiile de software au nceput
deja s ofere pe pia produsele necesare pentru a construi aceste data marts.
Rolul unui depozit de date este de a oferi o imagine coerent asupra datelor
relative la activitatea unei organizaii i a contextului n care acesta acioneaz. Utilizarea
acestei colecii poate consta din extragerea unor rapoarte (la cerere sau cu o anumit
periodicitate), extragerea unor date pentru a fi utilizate de aplicaiile de birotic
(programe de calcul tabelar, procesoare de text, programe de prezentare etc.), dar mai ales
pentru a fi utilizate de ctre aplicaii specializate de analiz. Acestea ar putea fi mprite
n dou categorii:
instrumente de analiz on-line (OLAP - On Line Analytical Processing aplicaii axate pe analiz multidimensional);
instrumente pentru "minerit" n date (data mining - aplicaii axate pe
descoperirea unor abloane semnificative n colecii de date).

2.3.2.1. Caracteristici ale depozitelor de date

Datorit obiectivelor impuse de utilizarea depozitelor de date n analiz, se
desprind cteva caracteristici mai importante pe care acestea le dein:
depozitul de date asigur accesul la datele organizaiei. Accesul trebuie s fie
imediat, la cerere i s fie performant. Nu este acceptabil ca acest acces s fie
realizat prin intermediari sau s fie prea lent. De asemenea, accesul presupune
existena unor utilitare care s fie foarte uor de folosit;
datele dintr-un depozit de date trebuie s fie consistente. Consistena
presupune faptul c atunci cnd dou persoane solicit acelai set de
informaii s primeasc aceleai date, chiar dac ele au fost cerute la momente
de timp diferite. Dac datele nu au fost complet ncrcate atunci utilizatorul va
fi avertizat cu privire la acest lucru i este sftuit s atepte pn ce vor fi
complet ncrcate;
datele ntr-un depozit de date pot fi separate i combinate pentru a oferi un
acces ct mai rapid i un timp de rspuns ct mai mic sistemului;
depozitele de date nu reprezint doar datele, ci i un set de utilitare pentru a
interoga, analiza, prezenta informaiile;
datele din depozite sunt utilizate direct n analize, fr alte prelucrri
suplimentare. Datele nu sunt doar acumulate la un loc i pstrate ci sunt

Cursul 5
asamblate dintr-o varietate de surse, sunt corectate de erori, li se asigur
calitatea necesar i abia apoi devin utilizabile;
calitatea datelor din depozitele de date este un factor determinant pentru
procesul de reculegere a datelor. Se ntlnete frecvent situaia n care datele
sunt de bun calitate, dar nu sunt colectate n ntregime sau au un caracter
opional.
Pentru obinerea acestor caracteristici este necesar redundana datelor. Dac n
sistemul operaional redundana este eliminat (prin procesul de normalizare) pentru a
evita anomaliile de actualizare, n depozitul de date redundana este creat n mod
intenionat (prin denormalizare i sumarizare) pentru a permite un acces mai rapid la date.
Raiunea pentru care este creat depozitul de date este, n cele din urm,
integrarea datelor. Datele sunt adunate pentru a rspunde nevoilor informaionale ale
ntregii organizaii, asigurnd faptul c rapoartele generate pentru diversele
compartimente vor conine aceleai rezultate. Sistemul operaional este adesea imposibil
de folosit pentru analiz, fiind de cele mai multe ori format din subsisteme semiindependente, create la momente diferite, de echipe diferite, n maniere diferite.
Integrarea datelor n cadrul depozitului de date se refer la diferite aspecte:
modaliti unice de codificare, sistem de uniti de msur consistente,
sistem stabil de reprezentare fizic a datelor,
convenii clare privind modul de reprezentare a datelor calendaristice,
convenii unice privind denumirile datelor.

2.3.2.2. Arhitectura depozitelor de date

Arhitecturi de baz aunui depozit de date presupune ncrcarea datelor din una
sau mai multe surse, utilizatorii acceseaz n mod direct depozitul de date. Dar arhitectura
depozitelor de date poate varia n funcie de situaia specific a fiecrei organizaii.
O arhitectur complex presupune existena unui sistem de purificare i integrare
a datelor precum i a mai multor sisteme de tipul data mart proiectate pentru
compartimente ale ntreprinderii. Figura urmtoare prezint un sistem complex de
datawarehouse:

Cursul 5

Surse de date

Depozitul de date

Instrumente BI

Interogari
Interogari
Stocare
Stocare
centralizata
centralizata

ET
ET
L
L

Data
Data
Warehouse
Warehouse

OLAP
OLAP
Data
Data Mining
Mining

Fisiere
Baze de date
Surse externe

Rapoarte
Rapoarte
Data Marts

Figura 2.13 Depozit de date cu arhitectur complex

Din punct de vedere funcional, n cadrul unui depozit de date pot fi identificate
trei niveluri distincte de realizare:
1) Modulul operaional este reprezentat de datele instituiei care sunt, de obicei,
pstrate n diverse forme, n fiiere sau baze de date i prelucrate de SGBD-uri
diferite. Aceste date pot proveni de la aplicaii sau de la sisteme distribuite din
cadrul companiilor cum ar fi sisteme de gestiune a comenzilor, de eliberare a
facturilor, de contabilitate financiar. Indiferent de originea lor, datele trebuie
s fie colectate i aduse ntr-o form consistent pentru a putea fi folosite.
Transformarea datelor presupune un proces de extragere, condiionare,
curare, fuziune, validare i ncrcare Acest proces de transformare a
datelor reprezint baza pe care se construiete un depozit de date consistent,
de nalt calitate..
2) Modulul central al depozitului de date este reprezentat de SGBD i de
serverul pe care acesta ruleaz i de modul n care este implementat depozitul.
Exist n acest moment dou modele de implementare:
a. implementarea unui sistem distribuit, descentralizat unde datele sunt
pstrate n uniti independente (Independent Data Marts), fiecare
coninnd datele relevante pentru un anumit aspect al operaiilor unei
instituii;
b. implementarea unei surse de date unice, centralizate i integrate la care
au acces utilizatorii din toate departamentele unei instituii.
3) Modulul strategic, de afaceri este nivelul la care datele sunt prezentate
analistului pentru interpretare. Prin folosirea diferitelor unelte de acces la
informaie i a tehnologiilor data mining disponibile, utilizatorii pot obine
informaii care i vor ajuta n procesele de stabilire a strategiei firmei.
Instrumentele de cereri grafice, prezentrile, rapoarte scrise, browser-ele Web,
instrumente de vizualizare a datelor, toate aparin acestui nivel. Interpretarea

Cursul 5
uzual const n reprezentarea tabelar sau grafic a datelor. Valoarea final a
unui depozit de date este determinat de avantajele pe care le ofer
utilizatorului n diferite procese de luare a deciziilor i analiz. Aplicaiile
suport de decizie ale clienilor, care ne dau noi informaii despre bugete,
prognoze, recomandri cu privire la alocarea resurselor i multe altele se afl
n modulele data marts la acest nivel al arhitecturii.
Utilizatori IT
Modulul Operational

Secventiale
Incarcare

Date operationale
Ne-relationale Relationale
Transformarea datelor
Filtrare

Externe
Conditionare

Depozitul de date
Modulul Central

Replicare si distribuire
Data Marts
Cunoastere/Data Mining

Modulul Strategic

Utilitare pentru accesarea informatiilor

Utilizatori finali

Figura 2.14 Modulele funcionale ale unui depozit de date

Din punct de vedere al ariei de cuprindere, se ntlnesc trei modele de depozite
de date:
1. Depozitul central al organizaiei (Enterprise Warehouse) colecteaz toate
informaiile despre subiectele care privesc ntreaga organizaie, integrnd date
din surse eterogene, provenite din sisteme tranzacionale diferite. El
furnizeaz un volum extins de date. De regul, conine date detaliate, dar i
date agregate, iar ca ordin de mrime pornete de la civa gigabytes pn la
sute de gigabytes, terrabytes sau mai mult. Un depozit de date de ntreprindere
poate fi implementat pe servere puternice UNIX sau pe platforme cu
arhitecturi paralele. n acest caz, cheltuielile pentru modelare sunt mai mari i
sunt necesari ani de zile pentru proiectare i realizare [RYAN99].
2. Data mart-ul conine un subset al volumului de date din organizaie, specific
unui grup de utilizatori sau departament. Domeniul este limitat la subiecte
specifice. Datele coninute n data mart sunt, de obicei, agregate. n mod
curent, data mart-urile sunt implementate pe servere departamentale mai
ieftine care se bazeaz pe UNIX sau Windows 2000/2003. Un data mart poate
fi considerat un subansamblu al unui depozit de date mai uor de construit i

Cursul 5
ntreinut i mai puin scump [INMO99].Ciclul de implementare al unui data
mart este mai curnd msurat n sptmni dect n luni sau ani.
3. Depozitul virtual (Virtual warehouse) este un set de viziuni (views) asupra
bazelor de date relaionale. Pentru eficiena procesrilor interogrilor, unele
din viziunile de agregare pot fi materializate. Un depozit virtual este uor de
construit, dar problema extragerii i prelucrrii datelor revine n mod exclusiv
serverului de baze de date, ceea ce poate conduce la un timp de prelucrare
mare, ns se elimin necesitatea stocrii datelor ntr-un depozit real
[HOLL00].
2.3.3. Migrarea datelor
"Migrare sau reproiectare?" este una din primele ntrebri cnd se ia n
considerare migrarea ctre o nou baz de date. Uneori, simpla migrare a bazei de date nu
este suficient, ci este necesar reproiectarea ntregului sistem informatic. Aceast situaie
apare cnd procesele interne ale firmei s-au schimbat n aa msur nct nu mai pot fi
acoperite de sistemul existent, iar efortul de adaptare a acestuia nu se justific economic.
Avantajele pe care le confer reproiectarea sistemului informatic sunt:
posibilitatea de a ncepe de la zero i a elimina slbiciunile structurale;
adoptarea de noi tehnologii;
crearea unei fundaii proaspete pentru noul sistem.
Reproiectarea sistemului informatic creaz ns i o serie de neajunsuri:
analiza, proiectarea i implementarea unui nou sistem solicit mult timp i resurse
fiind o investiie important. De cele mai multe ori, departamentul de IT
nsrcinat cu realizarea noului sistem nu poate s ntrein i vechiul sistem n
acelai timp;
este posibil ca noul sistem s fie mai puin funcional dect vechiul, anumite
funcii putnd fi uitate.
Nu exist un rspuns facil la ntrebarea "Migrare sau reproiectare?". Fiecare caz
trebuie analizat individual prin prisma avantajelor i dezavantajelor. Alegerea poate fi
ns i una combinat: reproiectare i migrare parial sau reproiectarea sistemului dup
ncheierea migrrii pe noile echipamente.
Schimbarea bazei de date nu este doar un simplu proces de transfer de date, ci
implic i conversia schemei bazei de date (definiii de tabele, viziuni, restricii de
integritate etc.), ct i a funciilor, procedurilor i pachetelor stocate n baza de date.
Principalii factorii ce trebuie luai n considerare cnd se migreaz la o alt baz de date:
1. Diferenele de sintax SQL ntre principalele SGBD-uri;
2. SGBD-urile de top precum Oracle, SQL Server i DB2 pun la dispoziie
dezvoltatorilor posibilitatea de integra n baza de date diferite restricii de
integritate, ct i algoritmi. Toate aceste elemente i obiecte sunt foarte importante
pentru funcionarea corect a aplicaiilor i dac baza de date surs le conine
trebuie s ne asigurm c i baza de date destinaie le suport i le putem converti;
3. Bazele de date pot conine sute sau chiar mii de obiecte (tabele, viziuni,
proceduri). Din aceast cauz se recomand folosirea unui asistent de migrare,
care s automatizeze cele mai multe sarcini, iar n sarcina administratorului bazei

Cursul 5
de date, s rmn doar corecii minore i de finee. O alt problem este i
interdependena dintre obiectele bazei de date. Aproape orice procedur face
referiri la tabele, viziuni sau la alte proceduri, iar aceast interdependen trebuie
meninut i dup migrare. Din aceast cauz, dac spre exemplu numele unei
tabele din Oracle este un nume rezervat n MySQL acesta va trebui schimbat, sau
pus ntre ghilimele i fcut modificarea n toate viziunile, funciile/
procedurile/pachetele stocate, cheile externe care fac apel sau refer tabela
respectiv. Un astfel de exemplu este LIMIT, care nu este cuvnt rezervat n
Oracle, dar este n MySQL;
4. Volumul mare de date face ca transferul s dureze i zeci de ore n funcie de
metoda de export-import folosit.
Etapele Migrrii datelor
Migrarea datelor se realizeaz n trei etape: export i conversie, transfer i procesare
i import.

Figura 2.20 Etapele migrrii datelor

Etapa 1: Export i conversie
n aceast etap se export i se convertete ntreaga baz de date iniial sau doar
anumite obiecte, caz n care se pot alege urmtoarele tipuri de obiecte:
tabele;
viziuni;
proceduri / funcii / pachete stocate;
declanatori.
Dup ce s-au ales obiectele, acestea se pot redenumi sau se pot schimba tipurile de
reprezentare a datelor (de exemplu se pot converti toate datele de tip numeric ntreg n
tipul caracter). Operaia poate fi la nivel global, pentru toate obiectele sau doar pentru o
parte dintre acestea. Etapa se finalizeaz prin crearea fiierelor cu comenzi SQL, folosite

Cursul 5
pentru crearea structurii bazei de date. Aceste fiiere ASCII conin att datele exportate
ct i scripturile necesare derulrii importului i depind de baza de date destinaie.
Etapa 2: Transfer i procesare
Aceast etap este una opional i este folosit n cazul proiectelor n care
fiierele de export trebuie dintr-un motiv sau altul s fie transferate. Acest lucru este
frecvent n cazul migrrii bazelor de date distribuite geografic sau cnd nu se poate stabili
o conexiune direct ntre baza de date surs i cea destinaie. n faza de procesare,
scripturile rezultate din transfer pot fi modificate pentru anumite nevoi particulare
neacoperite de asistentul de migrare folosit.
Etapa 3: Import
Scriptul rezultat dup prima etap i eventual prelucrat n cea de a doua este
executat pe baza de date destinaie. Structura bazei de date este creat cu ajutorul
utilitarelor specifice fiecrei baze de date care permit execuia de scripturi SQL. Cele mai
importante sunt:
SQL Plus pentru Oracle;
CLP (Command Line Processor) pentru IBM DB2;
ISQL pentru Ms SQL Server i SyBase;
linia de comand MySQL.
Utilitarele pentru ncrcarea datelor din fiierele ASCII sunt de asemenea
specifice bazei de date. Cele mai importante sunt:
SQL Loader pentru Oracle;
LOAD/IMPORT pentru IBM DB2;
BCP pentru SQL Server i Sybase;
LOAD DATA INFILE pentru MySQL;
BUTIL pentru Persasive SQL.
n general, n cazul migrrii este necesar mai puin timp i efort, procesul fiind n
general sigur, cu o probabilitate sczut de eec. n plus, investiia fcut n vechiul
sistem nu este pierdut, dar este evident c slbiciunile acestuia nu vor fi eliminate n
totalitate de migrarea la un nou sistem de gestiune a bazelor de date.