depozite de date -

7/28/2019 Depozite de Date -

1/35


2/35

Miloi Maria Denisa

Master : Sisteme informatice financiar bancare

Anul 1


3/35

CUPRINS :

Capitolul 1 Depozite de date (DD) aspecte fundamentale

1.1. Definire DD

1.2. Organizarea datelor n DD1.3. Faciliti oferite de DD1.4. Baze de date i Depozite de date1.5. Arhitectura DD1.6. Tipuri de depozite de date

Capitolul 2 Realizarea DD

2.1. Metodologia de realizare a DD2.2. Modelarea2.3. Implementarea2.4. Exploatarea


4/35

Capitolul 1 Depozite de date (DD) aspecte fundamentale

1.7. Definire DD1.8. Organizarea datelor n DD

1.9. Faciliti oferite de DD1.10. Baze de date i Depozite de date1.11. Arhitectura DD1.12. Tipuri de depozite de date

1.1. Definirea Depozitelor de Date

Depozitele de Date - DD (DW - data warehouse) reprezent rezultatul interferenei mediuluieconomic i al tehnologiilor informatice avansate.

Mediul economic este tot mai competitiv, tinde spre globalizare, devine tot mai complex i solicitinformaii elaborate pentru sprijinirea deciziilor strategice.Un astfel de mediu economic a determinat evoluia activitii de realizare a sistemelor informaticede la orientarea pe operaional (activitatea curent a firmei care pleac de la funciile ntreprinderiii funciile conducerii) spre orientarea pe procesul de afacere.Procesul de afacere (business

process) este un ansamblu de activiti interdepartamentale, la nivelul unei organizaii, carepresupune una sau mai multe intrri i care genereaz un rezultat important pentru client (intern sauextern). Sunt dou caracteristici fundamentale ale procesului de afaceri:

- acum managerii gndesc i decid mai mult la nivelul procesului de afaceri(interdepartamental) dect la nivelul funciilor ntreprinderii. Acest lucru nseamn corganizaia este privit din punctul de vedere al clientului, ceea ce corespunde societiiinformaionale care pune pe primul plan clientul;

- activitatea departamentelor unei organizaii va fi integrat, ceea ce nseamn o buncomunicare ntre ele. Rezult astfel realizarea unor sisteme informatice integrate.

Evoluia tehnologiilor informatice ofer soluii eficiente de gestionare a unor volume foarte mari dedate integrate(de ordinul TB terabytes), asigurnd niveluri de sintez i detaliere adecvate.

Costul realizrii unui DD este foarte mare (milioane de USD) i recuperarea investiiei se face ntimp indelungat.Din aceste costuri, 1/3 se cheltuiesc cu software necesar, 1/3 cu hardware i 1/3 cu servicii

profesionale.

Depozitele de date furnizeaz arhitecturi i instrumente utile conducerii executive prin organizareasistematic, nelegerea i utilizarea datelor n luarea deciziilor strategice, ntr-un mediu economiccompetitiv i n rapid evoluie.

Managerii au nteles c datele stocate de sistemele informatice operaionale, n fiiere sau baze dedate, reprezint o min de aur informaionalcare se cere exploatat.

Domeniile economice care se preteaz la aplicarea DD sunt: bnci, asigurri, telecomunicaii,hipermarket, transporturi. n aceste domenii au mare importan datele istorice din ultimii 5-10 ani.

William Inmon (vicepreedintele firmei Prism Solutions), este printele necontestat al noiunii deData Warehouse, iar viziunea sa se concentraz asupra rolului DD ca baz informaional a deciziei


5/35

manageriale, pstrnd astfel un nivel nalt de generalitate si permind unor multiple implementri sintre n sfera acestei noiuni.

Earl Hadden este cel care a enunat i a experimentat o metodologie riguroas pentru implementareadepozitelor de date.O serie de firme de Informatic i-au adus contribuia la clarificarea, dezvoltarea si popularizarea

noii tehnologii: Software AG, Oracle Corp., Prism Solutions, MicroStrategy etc.

Depozitul de date (sens larg) = o baz de date de foarte mari dimensiuni care este ntreinut separatde bazele de date operaionale ale unei organizaii i care este construit din date provenite dinsisteme surs prin extragere, filtrare, transformare i stocare n depozite speciale, n scopul sprijinirii

proceselor decizionale.Depozitele de date sprijina prelucrarea informaiilor pentru analiz, furniznd o platform solid deconsolidare a datelor istorice. Un depozit de date este un ansamblu de date consistente, din punct devedere semantic, care servete la o implementare fizic a unui model de date pentru sprijinireadeciziei i stocheaz informaii pe care o organizaie le solicit n luarea deciziilor strategice.

Depozitul de date (sens W.Inmon) = un ansamblu de colecii de date orientat pe subiecte, integrate,istorice i nevolatile destinat sprijinirii procesului de luare a deciziilor manageriale.

1.2. Organizarea datelor n DD

Sursele de date pentru depozitul de date provin n principal din datele importate din sistemulinformatic operational, dar mai pot proveni din datele de arhiv (n perioada de constituire adepozitului) precum i din surse externe (baze de date publice, date demografice, date statistice,date de prognoz economic, date obtinute n urma unor sondaje de opinie etc.).

Coleciile de date (BD sau fiiere) utilizate de sistemul informatic operaional au ca scop optimizareai sigurana procesrii datelor. Datele dintr-un depozit de date sunt organizate ntr-o manier care s

permit analizarea lor complex, deci extragerea semnificaiei economice pe care o poart.

Datele operaionale (BD sau fiiere) sunt orientate pe aplicaii, n sensul c organizarea lor esteoptimizat pentru a servi procesului tranzacional, dinamicii sistemului.Depozitul de date este orientat pe subiectele importante ale procesului economic: clientii, furnizorii,

produsele, activitile.Exemplu, o comand lansat de un client va aprea n sistemul operaional ca un set de nregistrricare vor conine date despre client, date despre produsele sau serviciile comandate, date despremodul de transport, date despre modul de plat.

Sistemului tranzacional (operaional) este orientat ctre consistena datelor (restriciile de integritate- cheile, validrile etc.). Multe dintre datele eseniale din perspectiv operaional (numrulcomenzii, poziiile liniilor n cadrul comenzii etc) sunt lipsite de relevan din perspectivinformaional a DD.

n sistemul operaional redundana este minimizat (de exemplu prin procesul de normalizare -proiectarea) pentru a evita anomaliile de actualizare. n depozitul de date redundana este creat nmod intenionat (prin denormalizare si sumarizare) pentru a permite un acces mai rapid i uor ladate.

Integrarea datelor reprezint un aspect important al depozitului de date i anume raiunea pentrucare acesta este creat. Datele sunt adunate pentru a rspunde nevoilor informaionale ale ntregii


6/35

organizaii, asigurnd faptul c rapoartele generate pentru diverse compartimente vor conineaceleai rezultate.Sistemul operaional este, de obicei, format din mai multe subsisteme relativ independente, create lamomente diferite, de echipe diferite, n maniere diferite, ceea ce face greoaie folosirea unui astfel desistem pentru analiz.

Integrarea datelor provenind din sistemul operational i din alte surse se refer la urmtoareleaspecte:

- modaliti unice de codificare exist nenumrate variante de a codifica un cmp dar oaplicaie pentru analiza datelor va trebui s se bazeze pe o codificare unic;

- Sistem de uniti de msur unitar - unitile de msur pentru diferite cmpuri trebuieexprimate ntr-un sistem unic (metric etc.);

- Sistem stabil de reprezentare fizic a datelor - n aplicaiile tranzacionale este posibil caaceleai date s fie memorate n moduri de organizare diverse. Acestea trebuie stabilizatedup anumite reguli precise;

- Convenii clareprivind modul de reprezentare a datelor datele calendaristice, cmpurilecare definesc timpul etc., trebuie s respecte conveniile internaionale;

- Convenii unice privind denumirile cmpuilor de date - n sistemul operaional acestea pot sdifere de la o aplicaie la alta, dar n DD ele trebuie s fie unice (lucrul n echip).

Sistemul operaional al unei organizaii tinde mereu s reflecte realitatea curent. Astfel, el se aflntr-o continu evoluie iar datele pe care le conine sunt relevante doar pentru momentul n care suntaccesate. Orizontul de timp pe care l acoper este de regul zile sau luni, deoarece dup acestinterval tranzaciile efectuate sunt arhivate, fiind considerate deja de domeniul istoriei, decineinteresante din perspectiv operativ.Pentru analiza economic, dimpotriv, informaiile care au caracter istoric sunt esentiale, deoareceele pun n evident tendine care reprezint fundamentul unei prognoze corecte. Depozitul de dateeste un istoric al sistemului operaional. Orizontul de timp pe care l acoper depozitul de date este decel puin cinci ani, ajungnd uneori la zece ani, n funcie de dinamica evoluiei pieei i, deci, derelevana datelor cu caracter istoric pentru nevoile analizei.Din punct de vedere tehnic, aceasta implic faptul c orice nregistrare din depozitul de date poate fi

plasat n timp, orice cheie de acces cuprinde i o variabil de timp.

Multe aplicaii operaionale (tranzacii) presupun actualizarea continu a coleciilor de date (A, M,S).La depozitele de date, actualizarea este foarte rar, adic dinamica lipsete. Actualizarea serealizeaz aici doar prin adugarea periodic a unor date extrase din sistemele operative sau din altesurse de date (campanii).

Din punctul de vedere al aplicatiilor care folosesc depozitul de date, accesulla date este doar pentrucitire.

n sistemul operational, o tranzacie trebuie s duc colecia de date dintr-o stare consistent ntr-oalt stare consistent, iar aceasta implic mecanisme complexe de meninere a integritii datelor(jurnalizare, salvare/restaurare, blocare).n cazul depozitelor de date, mecanismele de integritate sunt inutile, astfel c gradul de libertatectigat poate fi utilizat pentru optimizarea accesului la date prin denormalizare, sumarizare, statisticiale accesrii datelor, reorganizare dinamic a indexrii etc.

Un depozit de date conine un volum foarte mare de date. Unele dintre aceste date provin dinsursele operaionale ale organizaiei, altele pot proveni din surse externe.


7/35

Metadatele

Metadatele sunt informaii despre datele existente n DD, care descriu structura (coninutul)depozitului i furnizeaz referine directe la date.

Ca metadate se stocheaz i diverse viziuni (views) asociate unor categorii de utilizatori.Metadatelesunt folosite pentru administrareadepozitului de date, deoarece conin informaii despre:sursa datelor, algoritmii de sumarizare, statisticile de utilizare etc. Metadatele sunt create pentrutoate numele de date i definiiile din depozit. Metadate adiionale sunt create pentru a asociaintervale de timp la datele extrase i alte cmpuri care vor fi adugate prin filtrarea datelor sau prin

procesele de integrare.

Metadatele unui DD conin urmtoarele categorii de informaii:- o descriere a structurii de date din depozit, care include schema depozitului, dimensiunile,

ierarhiile, definiiile datelor derivate;- metadatele operaionale, care includ: date privind evoluia n timp (istoricul datelor i

secvena de transformare aplicat asupra lor), circulaia datelor (active, arhivate, terse) iinformaii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erorietc.);

- algoritmii utilizai pentru sumarizare, care includ: msura i dimensiunea algoritmilordefinii, date despre granularitate, partiii, arii de subiecte, agregri, sumarizri, rapoarte ifiltre predefinite;

- maprile (transformrile) de la mediul operaional la depozitul de date care includ: bazele dedate surs i coninutul lor, descrierile interfeelor (gateways), partiionarea datelor,extragerea datelor, filtrarea datelor, regulile de ntreinere, securitate a datelor;

- date referitoare laperformanele sistemului care include indici i profiluri care mbuntescaccesul la date i performanele de cutare;

- metadatele economice (business metadata), care includ termenii economici i definiiileaferente.

Exemple de metadate. Descrierea proprietilor datelor (obiectelor) din lumea real se face prinintermediul metadatelor, printr-un proces de abstractizare. Astfel, metadatele referitoare la cmpurileunui depozit de date se vor referi la: denumirea cmpului (aa cum va fi folosit n tabela relaionalfizic), sinonim pentru denumirea cmpului (aa cum este folosit de utilizatori), tipul de date pentrufiecare cmp (aa cum este acceptat de SGBD), indexarea (dac va fi folosit pentru cmp), cheia(dac un cmp este cheie), formatul cmpului, descrierea (o definiie a cmpului).

Rolulmetadatelor pentru depozitul de date reiese din urmtoarele considerente:- stabilesc contextuldepozitului de date. Sub orice sistem, inclusiv DD, utilizatorul intr sub osesiune de lucru, adic se creaz automat un context de lucru: parametri setai, conectriefectuate, drepturi existente etc.

- ajut administratorii i utilizatorii depozituluis localizeze i s neleag secvenele de dateatt n sistemele surs ct i n structura depozitului. n sistemele operaionale, dezvoltatoriii administratorii bazelor de date lucreaz cu metadate n fiecare zi. Toat documentaiatehnic a sistemelor reprezint ntr-un fel sau altul metadate. Ele rmn totui transparente

pentru majoritatea utilizatorilor, ei percepnd n general sistemul ca pe o cutie neagr ceofer o interfa prin intermediul creia trebuie manevrat. n cazul depozitelor de date,utilizatorii sistemelor de asistare a deciziei trebuie s neleag nainte de toate coninutul

depozitului, pentru ca apoi s beneficieze de informaiile necesare.


8/35

- procesul de analiz cuprinde mai multe etape: identificarea datelor, obinerea datelor,interpretarea i analiza datelor pentru a obine informaii, prezentarea informaiilor irecomandarea unei direcii de aciune. Pentru ca depozitul de date s fie folositor analitilordin ntreprindere, metadatele trebuie s ofere utilizatorilor informaii care s-i ajute n

parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie s ajute utilizatorii s

gseasc rapid datele n depozit i s interpreteze corect datele obinute prin oferireainformaiilor referitoare la formatul i semnificaia datelor;

- metadatele sunt o form de auditare a transformrii datelor. Metadatele documenteaztransformarea datelor surs n date ale depozitului, adic trebuie s fie capabile s explicemodul n care o secven de date din depozit este dedus din sistemele operaionale. Toateregulile care guverneaz transformarea datelor n noi valori sau noi formate sunt consideratea fi metadate. Aceast form de audit este necesar atunci cnd utilizatorii trebuie s aibncredere n veridicitatea i calitatea datelor din depozit. De asemenea, este important cautilizatorii s-i poat da seama de unde provin datele existente n depozit. Este de dorit ca,

pe baza acestor metadate, anumite produse s poat genera programe de extragere itransformare pentru cei care se ocup de interfaa de analiz a depozitului de date;

- metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea valorilorvalide pentru fiecare cmp din depozit. nainte de a fi efectiv ncrcate n depozit, datele potfi revzute i erorile pot fi corectate. De asemenea, regulile de corecie a erorilor pot fidocumentate tot prin metadate;

- permite gestiunea versiunilor. Un depozit de date conine date pentru diferite perioade detimp i de aceea este important s avem n vedere efectul pe care l poate avea timpul asupraregulilor de trecere a cmpurilor surs n cmpuri destinaie, asupra agregrilor etc.Utilizatorii trebuie s aib acces la metadatele corecte pentru perioada de timp pe care ostudiaz. Ceea ce la prima vedere ar prea s fie o eroare n transformarea datelor poate fi defapt rezultatul schimbrii regulilor de transformare a datelor. De aceea este important cametadatele s fie corect gestionate din punct de vedere al versiunilor.

Tipuri de metadate n funcie de destinaia lor:o metadate administrative. Acestea conin descrieri ale bazelor de date surs i ale

coninutului lor, descrieri ale obiectelor depozitului de date i ale regulilor folositepentru a transforma datele din sistemul surs n depozit, schema depozitului de date,interfee pentru analiza datelor, reguli i formule de calcul, reguli de securitate i deacces;

o metadate pentru utilizatori. Acestea au rolul de a ajuta pe utilizatori s-i creezepropriile lor interogri i s interpreteze rezultatele. Pentru aceasta, ei au nevoie scunoasc definiiile datelor din depozit, descrierea lor, precum i orice ierarhie care

poate exista n diferite dimensiuni. Astfel de metadate sunt: coninutul depozitului dedate, rapoarte i interogri predefinite, definiiile ierarhiilor, calitatea datelor, istoriculncrcrii depozitului de date, reguli detergere a datelor;

o metadatepentru optimizare. Aceastea au rolul de a crete performanele depozituluide date. Exemple de astfel de metadate sunt definiiile agregrilor i colecii destatistici.

Not. Dei n mod tradiional metadatele reprezint o component dezvoltat la sfritul proiectului,la ora actual exist o tendin puternic de a atribui metadatelor un rol mai activ.Concluzie. Depozitul de date nseamn o stocare a datelor, unitar, complet i integrat, obinutdintr-o varietate de surse, disponibil utilizatorilor ntr-un mod uor perceptibil i destinatfundamentrii deciziei n contextul afacerii.


9/35

1.3. Faciliti oferite de DD

Creterea volumului de date, precum i perfecionarea software-ului de gestiunea acestuia au condusla o noua calitate a utilizrii datelor prin analize care pot releva conducerii organizaiei informaii

greu sau chiar imposibil de obinut pe alte cai.Se pot obine astfel informaii privind: preferinele clienilor, profilul clienilor, distribuia

produselor, regiunea unde se vinde mai bine un anumit produs, care sunt preferinele unui anumitsegment de pia etc.

Pentru a obine informaiile dorite, DD sunt supuse unorprelucrri complexe, cu ajutorul unormetode specifice, cum ar fi: analiza multidimensional a datelor, metode statistice superioare de

prognoz, metode matematice aplicate unui volum foarte mare de date.Aceste metode presupun folosirea unui software specializat deosebit de complex, bazat pe noitehnologii informatice: extrageri de date (data mining), OLAP, concentrri de date (data mart).

Sistemele care lucreaz cu depozite de date trebuie s aib o mare flexibilitate, ceea ce nseamn oconectivitate 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 sealeag o arhitectur care s se adapteze uor la modificrile de performane, capacitate iconectivitate. Procesele de configurare, optimizare si administrare a sistemului, inclusiv procedurilede salvare - restaurare, precum si pstrarea n tot acest timp a functionalitii sistemului pot devenioperaii dificile dac trebuie repetate la fiecare adugare a unor noi servere n sistem.

Pentru a se evita cutarile costisitoare, de multe ori, se alege o cale de mijloc: n loc s caute n totdepozitul de date, se poate crea un sub-depozit (data mart concentrri de date) care s coninnumai datele relevante pentru analiza necesar. Concentrrile de date (data marts) pot fi construites funcioneze pe configuraii mai modeste dect depozitele de date i sunt specifice unei anumiteaplicaii. Depozitul de date conine informaii care pot fi utilizate pentru a rspunde oricrei ntrebri

privind afacerile unei organizaii, iar Concentrrile de date conin datele necesare unui anumitcompartiment al organizaiei (de ordinul GB). Conectnd impreuna Concentrrile de date aferentediferitelor compartimente aleorganizaiei, formnd astfel o infrastructur specific, departamentele

pot folosi n comun datele lor i se poate crea astfel un sistem de suport al deciziei mai uor deconstruit i mai flexibil.

Depozitele de date sunt destinate managerilor i analitilor angrenai n luarea deciziilor strategiceprivind dezvoltarea i viitorul organizaiilor. Pentru aceasta, ei au nevoie de interfee performante de

accesare i utilizare a datelor din depozite, adic deproduse software asociate depozitului de date:- interfee oferite de SGBD utilizatorilor, care au nevoie de acces rapid, de informaiipunctuale (limbaje de interogare gen SQL, generatoare de rapoarte);

- interfee specializate pentru asistarea deciziilor, care transform datele n forma cerut dedecideni (grafice, diagrame, organigrame) sau ofer posibilitatea analizei tendinelor,corelaiilor i interpretarea acestora (OLAP, Data mining).

Interfeele OLAPse bazeaz pe reprezentarea multidimensional a datelor (cubul de date) i permiteanaliza interactiv i rapid a datelor prin operaiuni specifice. Utilizatorul poate obine rezultateimmediate parcurgnd dinamic dimensiunile cubului de date, lucrnd cu niveluri diferite desintez/detaliere (exemplu Oracle OLAP).


10/35

Interfeele de tip Data Miningasigur extragerea i transformarea datelor n cunotiine (de aceeamult lume consider termenul Data Mining sinonim cu termenul Knowledge Discovery inDatabases - KDD). Se utilizeaz tehnici ale analizei statistice superioare i de Inteligen Artificialcare permit descoperirea de corelaii, reguli, cunotiine utile sprijinirii deciziilor.

1.4. Baze de date i Depozite de date

Att bazele de date ct i depozitele de date conin cantiti mari de date structurate care pot ficonsultate rapid, prin structuri de acces optimizate i se bazeaz, n majoritatea cazurilor, petehnologia relaional.

Sistemele de baze de date relaionale sunt adecvate aplicaiilor curente de gestiune i au ca obiectivexecuia on-line a tranzaciilor i proceselor de interogare (sunt sisteme tip OLTP - On LineTransaction Processing). Aceste sisteme implementeaz toate operaiile zilnice dintr-o organizaie.Sistemele cu depozite de date servesc utilizatorilor sau specialitilor n domeniul analizei datelor ilurii 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 iinterogate 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 obiectivregruparea datelor, agregarea i sintetizarea lor, organizarea i coordonarea informaiilor

provenind din surse diferite, integrarea i stocare acestora pentru a da decidenilor o imagineadecvat 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 dinbazele 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 procesareatranzaciilor 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 nactivitateaoperaional.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 dateles fie uor utilizate de ctre decideni, mai ales n tactica i strategia organizaiei.

La BDsursele de date sunt tranzaciile atomice, iaraccesuleste de tip citire iscriere.La DD sursele de date sunt BD operaionale, iar accesul este cel mai adesea de tip citire pentruinterogri complexe.

O baz de date este proiectat pornind de la sarcini i activiti cunoscute: indexarea, utilizareacheilor, cutarea unor nregistrri specifice, optimizarea interogrilor. Interogrile unui depozit dedate sunt adesea complexe, implicnd calcule asupra unor grupuri mari de date cu totalizri pediferite niveluri, ceea ce presupune activiti speciale: de organizare a datelor, de acces.

O baz de date presupune procesarea concurent a tranzaciilormultiple.


11/35

Controlul concurenei pentru DD este mult mai simplu deoarece se aplic doar pentru citire.

Comparaie ntre BD i DD

Criteriu BD DD

Procesele operaionale informaionaleExecuie tranzacii analizeUtilizatori toate categoriile manageri, analiti de dateOperaii zilnice asistarea decizieiCaracterul datelor curente istorice

Nivelul de sintez primitive, detaliere sintetizare, consolidareAcces citire, scriere citireFocalizare culegere date furnizare informaiiSursa de date este validat filtrat, transformatVolum de date ordinul GB ordinul TB

Prioriti performane,disponibilitate flexibilitate, autonomieSoftware necesar SGBD specializat, SGBD

1.5.Arhitectura depozitelor de date

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 deanaliz.

Esena unui depozit de date const ntr-o baz de date de dimensiuni foarte mari coninndinformaiile 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 informaionaleale 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 ide calcul. Ele sunt utilizate oro de cte ori se utilizeaz DD: la ncrcarea datelor, la consultare, laactualizare, adic pe parcursul ntregului ciclu de via al depozitului.

Datele agregate, dei determin o cretere a redundanei datelor, sunt necesare n DD deoarece nacest 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).


12/35

sursa de date depozit de date interfee de analiz

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.

Not. Aceast structur a datelor n DD este dinamic, datele intr n depozitul de date, circul pediverse nivele, i schimb forma i pozitia, i schimb destinaia.Sursele de date pentru DD sunt: datele operaionale curente (BD i/sau fiiere din sistemulinformatic al organizaiei), datele vechi arhivate, datele externe (BD i fiiere din sistemeleinformatice ale altor organizaii).

Construirea depozitului de date, pornind de la sursele de date, presupune parcurgerea unoretape ncadrul unui proces de extragere transformare ncrcare (ETL Extract Transformation Load):

- extragerea datelor din datele operaionale sau din surse externe, urmat de copierea lor ndepozitul de date. Acest proces trebuie, cel mai adesea, s transforme datele n structura iformatul intern al depozitului;

- filtrarea datelor, pentru a exista certitudinea c datele sunt corecte i pot fi utilizate pentruluarea 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 ndepozitul de date mpreun cu datele importate din sursele interne i externe.

Not. n infrastructura Oracle funcia ETL pentru un depozit de date este ndeplinit de produsulOracle Data Integrator ODI.Interfeele de analiz sunt produse software care implementeaz tehnologii informatice pentruextragerea 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 multecazuri, un sistem de baze de date relaionale.

Dateexterne

Dateinterne

Datearhivate

transformar

e

Metadatele

Datele aggregate

Datele detaliate

Data

Mart

DataMining

OLAP


13/35

Datele care provin din bazele de date operaionale i din sursele externe (de exemplu date referitoarela profilul clientului, date furnizate de consultani externi, rezultatele unor sondaje) sunt extraseutiliznd 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.Exemple de astfel de interfee: ODBC (Open DataBase Connection), OLE(Open Linking and

Embedding), JDBC (Java DataBase Connection).Astfel, datele sunt extrase, filtrate, transformate i ncrcate n depozitul de date prin interfeespecializate 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 pemodelul relaional ROLAP sau pe modelul multidimensional - MOLAP), Data Mining (analizestatistice superioare), Data Mart (concentrri de date). De multe ori acest strat este inclus n SGBDR(exemplu Oracle, DB2).Stratul superior (top tier) este nivelul clientcare conine interfee pentru generarea interogrilor, arapoartelor, pentru superioar a datelor.

Strat superior

extragere

Strat mediu

transformareStrat inferior

1.6. Tipuri de depozite de date

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 (VirtualDatawarehouse).

Depozitul de ntreprindere colecteaz toate informaiile despre subiectele care privesc ntreagaorganizaie. El furnizeaz un volum foarte mare de date. De regul conine date detaliate, dar i dateagregate, iar ca ordin de mrime, terabytes.Un depozit de date de ntreprindere poate fi implementat pe calculatoare mari (mainframes), pesuperservere UNIX, pe platforme cu arhitecturi paralele. Acestea necesit cheltuieli mari i mult

timp (ani) pentru modelare proiectare i realizare.

Rapoarte, interogri

Servere specializate

Depozite dedate

Server de Date


14/35

Concentrrile de date conin un subset al volumului de date din organizaie, specific unui grup deutilizatori (unui compartiment). Domeniul este limitat la subiecte specifice. De exemplu, pentruactivitatea de marketing se limiteaz subiectele la clieni, produse, vnzri.Datele coninute sunt de obicei agregate. Concentrrile de date sunt implementate pe serveredepartamentale (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 alunui 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 eficienaprocesrilor interogrilor, numai unele din viziunile de agregare pot fi materializate. Un depozitvirtual 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, DDmultidimensionale.


15/35

Capitolul 2 Realizarea DD

2.5. Metodologia de realizare a DD2.6. Modelarea2.7. Implementarea2.8. Exploatarea

Realizarea unui depozit de date presupune aplicarea unei scheme de analiz economic pentru adetermina 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 faacompetitorilor;

- poate determina creterea productivitii deoarece permite obinerea rapid i eficient deinformaii care descriu cu acuratee organizaia;

- faciliteaz gestiunea relaiilor cu clienii, deoarece acesta furnizeaz o viziune consistentdespre clienii i produsele comercializate de organizaie, pe toate departamentele;

- determin reducerea costurilor prin reliefarea tendinelor , direciilor i excepiilor peperioade 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 activitateacurent.

o viziunea datelor surs (data source view) exprim informaiile culese, stocate igestionate de sistemele operaionale. Aceste informaii pot fi documentate pe nivelurivariate de detaliere i acuratee, de la tabele individuale de date surs la tabele de dateintegrate.

o viziunea depozitelor de date (data warehouse) are n vedere tabele de fapte i tabeledimensiune i reprezint informaiile care sunt stocate n depozitele de date, incluzndcontorizri i totaluri precalculate, precum i informaii privitoare la surs, datcalendaristic, origine, adugate pentru a furniza contextul istoric.

o viziunea de interogare (business query) ofer o perspectiv din punct de vedere alutilizatorului.

Un depozit de date poate fiproiectat i construitutiliznd 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 trebuierezolvate 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 timpndelungat pentru dezvoltare i i lipsete flexibilitatea determinat de dificultile nrealizarea 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 smearg nainte cu cheltuieli considerabil mai mici i s evalueze beneficiile tehnologiei


16/35

nainte de a face angajamente semnificative n aceast direcie. Abordarea bottom-up nproiectarea, dezvoltarea i aplicarea concentrrilor de date (data marts) independentefurnizeaz flexibilitate, costuri sczute i recuperarea rapid a investiiei. Soluia poatedetermina probleme, cnd se ncearc integrarea ntr-un depozit de date consistent la nivel dentreprindere.

- mixtpresupune c o organizaie poate exploata caracterul planificat i strategic al abordriitop-down att timp ct reine avantajele implementrii rapide i oportune a aplicaiilor dupabordarea bottom-up.

Realizarea unui depozit de date presupune urmtorii pai: 1. strategia de realizare; 2. planificarea(modelarea) cerinelor; 3. implementarea; 4. exploatarea.

Sistemele software mari pot fi dezvoltate utiliznd dou metodologii: metoda in cascad, metoda nspiral.

Metoda n cascad execut o analiz structurat i sistematic la fiecare pas, nainte de a trece laurmtorul.

Metoda n spiral implic generarea rapid de sisteme funcionale din n ce mai complete, laintervale scurte, ntre dou versiuni succesive. Acest lucru constituie un atu important pentrudezvoltarea depozitelor de date, n special pentru data marts, pentru c intervalul de realizare estescurt, modificrile pot fi fcute imediat i noile proiecte i tehnologii pot fi adaptate n mod rapid.

2.1. Strategia de realizare a depozitelor de date

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 devedere al capacitii de gestionare. Este mult mai realist s se fac o list cu prioritilecerinelor diferiilor utilizatori, iar aceste cerine s fie ataate diferitelor segmente care se vordezvolta prin strategia iterativ. Natura iterativ a proiectului permite echipei de dezvoltare sextind funcionalitile depozitului de date ntr-o manier uor de controlat;

- arhitectura preliminar a depozitului de date. Se definite arhitectura general a depozituluide date pentru proiectul pilot i versiunile care vor urma pentru a asigura scalabilitateadepozitului. Prin analizarea posibilelor arhitecturi de depozite de date, analitii pot sdetermine o mulime de alte componente tehnologice care sunt necesare pentru fiecareversiune;

- 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, serecomand alctuirea unei liste sintetice cu cele care pot fi de folos n cadrul organizaiei. Unset standard de instrumente va reduce problemele de integrare i va minimiza efortul denvare att pentru echipa de dezvoltare, ct i pentru utilizatori.

Etapele necesare pentru a duce la ndeplinire strategia DD sunt urmtoarele: determinareacontextului 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.

Not. Fiecare etap poate fi ndeplinit ntr-un interval de timp de aproximativ trei pn la cinci

sptmni, n funcie de disponibilitatea resurselor i mrimea organizaiei.


17/35

1. Determinarea contextului organizaional. Inelegerea profund a organizaiei ajut la stabilireacontextului n care se desfoar proiectul i poate evidenia aspectele culturii organizaionale, care

pot uura sau ngreuna proiectul depozitului de date. Rspunsurile la ntrebrile legate de organizaiese obin de obicei de la susintorul proiectului, managerul IT sau managerul de proiect. Intrebriletipice sunt urmtoarele:

- cine este finanatorul (susintorul) proiectului n acest caz? Susintorul proiectului stabiletedomeniul proiectului DD. Acesta joac un rol foarte important n stabilirea relaiilor de lucru ntremembrii echipei de dezvoltare, mai ales dac sunt implicai i teri. Accesul facil la dateledepozitului poate fi limitat de domeniul organizaional, care se afl sub controlul susintorului

proiectului;- care sunt grupurile IT din organizaie care sunt implicate n proiectul DD? Deoarece un depozit dedate este o dorin a organizaiei, grupurile IT din interior vor fi ntotdeauna implicate n acest efort.Trebuie tiut care sunt relaiile de lucru dintre ele i care este gradul de ocupare. Dac, de exemplu,departamentul IT este foarte preocupat cu imbuntirea sistemelor operaionale este foarte puin

probabil ca un depozit de date s fie pe lista de prioriti;- care sunt rolurile i responsabilitile fiecaruia dintre cei care au legtur cu proiectul? Este

important s definim rolul i responsabilitaile fiecrei persoane implicate. In acest fel se stabilesclimite i obiective, iar comunicarea i nelegerea proiectului se mbuntesc.

2. Realizarea unei vederi preliminare de ansamblu asupra cerinelor. In aceast etap se obineun inventar al cerinelor utilizatorilor prin interviuri, individuale sau de grup, realizate n comunitateautilizatorilor finali. Dac este posibil, se recomand obinerea de formate referitoare la rapoartelecurente folosite de conducere. Inventarul cerinelor furnizeaz aria de ntindere a informaiilor desprecare se ateapt s le ofere un viitor depozit de date.Obiectivul principal este acela de a nelege nevoile utilizatorilor, destul de mult, ca s poat fiierarhizate. Aceasta este o informaie critic ce determin aria fiecrui segment DD.

Exemple dentrebri care pot constitui repere ntr-o discuie cu potenialii utilizatori ai depozituluide date:

Funciile. Care este misiunea grupului sau a departamentului? Cum procedai ca s v ndepliniimisiunea? Cum tii dac ai atins obiectivele fixate? Care sunt indicatorii de performan pe care ifolosii i care sunt factorii critici de succes?Clienii. Cum v grupai sau v clasificai clienii? Se modific aceast grupare de-a lungul timpului?Modul de grupare afecteaz modul n care v tratai clenii? Ce fel de informaii pstrai desprefiecare tip de client? Ce informaii demografice folosii? Avei nevoie s pstrai date despre fiecareclient n parte?

Profitul. La ce nivel msurai profitabilitatea n grupul sau departamentul dvs.? Pe agent? Pe client?

Pe produs? Pe regiune? La ce nivel de detaliere sunt nregistrate costurile i veniturile? Ce fel derapoarte privind profitabilitatea folosii actualmente?Sistemele. Ce sisteme folosii ca parte a muncii dvs.? Ce fel de transformri manuale de date trebuies facei atunci cnd datele nu sunt disponibile?Timpul. Pentru cte luni sau ani avei nevoie s fie pstrate datele? Analizai performanele pe durataunui an? La ce nivel de detaliere avei nevoie s fie prezentate graficele? Zilnic? Sptmnal? Lunar?Trimestrial? Anual? Ct de repede avei nevoie de date?

Interogrile i rapoartele. Ce rapoarte folosii acum? Ce informaii folosii de fapt din fiecare raportpe care l primii? Putem obine machete ale acestor rapoarte? Ct de des se produc aceste rapoarte?Le primii destul de frecvent sau timpul de ateptare este prea mare? Cine produce rapoartele pe carele primii? Cine sunt cei pentru care alctuii dvs. rapoartele?


18/35

Produsele. Ce produse vindei i cum le clasificai? Avei o ierarhie a produselor? Analizai datelepentru toate produsele n acelai timp sau analizai datele despre fiecare produs n parte? Cumgestionai modificrile care intervin n ierarhia produselor?Geografia. Organizaia opereaz n mai mult de o singur zon? V mprii piaa n zonegeografice? Pstrai datele despre vnzri pe fiecare regiune n parte?

La realizarea interviurilor pentru dezvoltarea depozitelor de date, este indicat s lum n considerareurmtoarele recomandri:

- Trebuie evitat s facem delimitri clare privind aria depozitului de date. Nu trebuie s fimsurprini dac o s constatm c o parte dintre interogrile i rapoartele de care au nevoieutilizatorii nu pot fi realizate pe baza datelor existente n sistemele operaionale.

- Trebuie pstrat clar obiectivul interviului i nu trebuie s ne abatem de la el. Obiectivulprincipal este acela de a realiza un inventar al cerinelor, nefiind nevoie o nelegere foartedetaliat a acestora.

- Echipa care realizeaz interviurile trebuie s fie mic; echipa ideal este format din doioameni unul va pune intrebrile i cellalt va nota rspunsurile. Intervievaii pot fi

intimidai dac sunt abordai de un grup prea mare.- Se poate nregistra interviul, dac persoana este de acord. Majoritatea persoanelor nu au

nimic mpotriv, dac le cerei acordul s nregistrai discuia pe suport magnetic, iarascultarea ulterioar a discuiei poate fi de mare ajutor.

- Stilul de interviu va depinde de persoana intervievat. Managerii de nivel mediu sunt cei carelucreaz cel mai mult cu rapoarte analitice, n timp ce managerii de nivel nalt au cerinelegate de informaii cu caracter strategic. In funcie de intervievat se vor alege i ntrebrile lacare se solicit rspuns.

- Trebuie obinut copii ale rapoartelor, ori de cte ori este posibil. Rapoartele vor furnizaechipei de dezvoltare informaii importante, referitoare la sistemele surs i la regulile itermenii afacerii.

3. Realizarea auditului preliminar referitor la sistemele surs. Este recomandabil ca echipa dedezvoltare s obin un inventar al sistemelor surs poteniale pentru depozitul de date. In timp cemanagerul IT va furniza imaginea de ansamblu a sistemelor existente n organizaie, cei mai nmsur s ofere detalii pentru auditarea sistemelor surs sunt administratorii de baze de date iadministratorii de sistem care ntrein sistemele operaionale.

Exemple dentrebri tipice pentru realizarea unui astfel de audit:Arhitectura curent. Care este arhitectura tehnologic curent a organizaiei? Ce fel de sisteme,echipamente, sisteme de gestiune a bazelor de date, reele, instrumente utilizator, interfee de

dezvoltare i de accesare a datelor se folosesc n prezent?Relaiile ntre sistemele surs. Exist o legtur ntre diversele sisteme surs? Un sistem furnizeazinformaii altuia? Sistemele sunt integrate ntr-un mod anume?

Faciliti de reea. Exist faciliti de reea ce pot fi utilizate? Este posibil a se folosi doar unterminal sau un microcalculator pentru a accesa sisteme operaionale diferite, din orice zon?Calitatea datelor. Care este calitatea datelor? Ct de multe operaii defiltrare, triere, deduplicare iintegrare estimai c vor fi necesare? Ce zone, tabele sau cmpuri, din sistemele actuale suntcunoscute pentru slaba calitate a datelor?

Documentaia. Ct documentaie este disponibil pentru sistemele surs? Ct de corecte i deactuale sunt aceste manuale i referine? Este bine de obinut urmtoarele informaii ori de cte orieste posibil: copii ale manualelor i instruciunilor de utilizare, structura bazelor de date, pri de

programe surs, scheme de generare a codului surs.


19/35

Mecanisme de extragere posibile. Ce mecanisme de extragere sunt posibile pentru sistemul curent?Ce mecanisme au fost folosite nainte i care credei c vor fi mecanismele de extragere a datelorcare nu vor funciona cu sistemul actual?

4. Identificarea surselor de date externe. Organizaia poate folosi surse de date externe pentru

completarea datelor din sistemele surs interne. Astfel de surse de date externe pot fi: date de labnci, date referitoare la codurile potale, date statistice sau demografice, date de la alte organizaii,date de la agenii de tiri sau din publicaii.

Dei datele externe reprezint o oportunutate pentru mbogirea depozitului de date, ele prezintdificulti din cauza granularitii diferite i, de aceea, decizia n legtur cu folosirea datelor externetrebuie s fie bine fundamentat.

5. Definirea versiunilor depozitului de date. Specialitii recomand mprirea dezvoltriidepozitului de date n mai multe versiuni derulate n spiral. Disponibilitatea i calitatea datelor sursvor juca un rol critic n finalizarea cu succes a acestei faze.

Abordarea iterativ permite gestionarea eficient a cerinelor utilizatorilor i reduce efecteleriscurilor care pot aprea. Fiecrei cerine i se atribuie un nivel de prioritate. Se face o evaluareiniial a complexitii n funcie de numrul sistemelor surs. De asemenea, este identificat isistemul int. Pot fi luai n calcul mai muli factori pentru o mai bun nelegere a cerinelor fiecruimodul. Definirea fiecrui modul este finalizat doar atunci cnd este aprobat de ctre susintorul

proiectului.

6. Definirea arhitecturii preliminare a depozitului de date. Trebuie s se schieze o arhitecturpreliminar pentru fiecare modul n funcie de aria de ntindere aprobat. Este recomandabil s seanalizeze posibilitatea de a se folosi o intercorelare de baze de date relaionale i multidimensionale,

precum i instrumente adecvate.

O arhitectur preliminar trebuie s prezinte cel puin urmtoarele elemente:Depozitul de date i concentrrile de date. Se definesc aceste elemente pentru fiecare modul n parte.Este necesar s se indice modul n care sunt legate diferite baze de date. Arhitectura trebuie sasigure faptul c anumite concentrri de date nu sunt implementate izolat.

Numrul de utilizatori. Se specific numrul de utilizatori pentru fiecare instrument de acces lafiecare versiune n parte.

Localizarea. Se precizeaz locul de dispunere a depozitului de date, a concentrrilor de date i autilizatorilor pentru fiecare modul. Aceste aspecte au implicaii asupra cerinelor arhitecturii tehnice

a proiectului depozitului de date.


20/35

7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizaia poate alege ntre mai multemedii i interfee pentru a dezvolta depozitul de date. Important este s se selecteze combinaia deinterfee care satisfac cel mai bine cerinele organizaiei. In prezent nu exist un productor care sofere o suit integrat pentru depozite de date, ns exist lideri pentru fiecare categorie n parte. Sevor elimina variantele neconvenabile i se va alctui o list din care fiecare versiune va avea parte deun set de interfee (acces la date, SGBD etc.).

2.2. Modelarea depozitelor de date

Modelarea (planificarea) unei versiuni a depozitului de date se realizeaz conform strategiei acestuia,stabilit de ctre specialitii organizaiei. Planificarea depozitului de date detaliaz domeniul

preliminar al unei versiuni prin obinerea detaliilor despre cerinele utilizatorilor referitoare lainterogri, la construirea unei scheme iniiale a depozitului de date i la stabilirea cmpurilor deinteres din sistemele surs.Un proiect de planificare (modelare) dureaz n general ntre cinci i opt sptmni, n funcie dearia 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 demodul n care sunt rezolvate problemele care apar.

DataWarehous

e

Report

Writer(5utilizatori)

DataWarehous

e ReportServer

(10utilizatori)

Data

Mart

Fig. 20. Exemple de arhitecturi preliminare pe versiuni

Versiuneanr. 2

Versiuneanr. 1ROLAP

Front-End(10utilizatori)

ROLAP

Front-End(15utilizatori)

AlertSystem

(10utilizatori)

EIS/DSS(3

utilizatori)


21/35

Etapele necesare pentru realizarea planificrii depozitului de date sunt urmtoarele: alctuireaechipei, analiza cerinelor, auditarea sistemelor surs, proiectarea schemelor depozitului de date,transformarea cmpurilor surs n cmpurile destinaie, ncrcarea datelor istorice n depozitul dedate, 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 iniiaten 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 structurformal. 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 pentrufiecare n parte.

Dac este necesar membrii echipei vor fi instruii cu privire la conceptele referitoare la tehnologiadepozitelor 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, trebuiedescrise 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 analizastarea n care se afl proiectul.

2. Analiza cerinelor informaionale.Analiza cerinelor informaionale este una din cele dou activiti care se pot desfura n paralel ntimpul planificrii depozitului de date, cealalt activitate fiind auditarea sistemelor surs. Obiectulanalizei cerinelor l constituie nelegerea cerinelor informaionale ale decidenilor.

O analiz preliminar a fost deja efectuat ca parte a formulrii strategiei DD. In aceast etap esterevizuit aria de cuprindere a modulului depozitului de date, aa cum a fost ea definit ndocumentaia strategiei. Se va finisa acest aspect prin detalierea analizei preliminare a cerinelordecizionale. Va fi necesar s se stabileasc noi ntlniri cu reprezentanii utilizatorilor. Aria decuprindere a modulului va fi determinat n termeni de interogri i rapoarte care vor putea firealizate la finalizarea modulului depozitului de date. Finanatorul proiectului trebuie s revad i saprobe documentaia pentru a se asigura c ateptrile conducerii organizaiei vor fi atinse. Deasemenea, vor fi documentate toate limitrile impuse de sistemele surs, iar aceste informaii vor fioferite auditorilor pentru a fi confirmate. Limitrile impuse de sistemele surs determin n maremsur 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 caproiectul s nu poat fi gestionat eficient. Ca regul general, aria trebuie limitat astfel nctversiunea s poat fi implementat ntr-o perioad de la trei pn la ase luni, de o echip de 6-12membrii.

Not. Uneori, este posibil ca o organizaie s treac direct la faza de planificare a depozitului de date,fr ca n prealabil s formuleze strategia DD. Acest lucru se ntmpl, de obicei, atunci cnd ungrup de utilizatori preiau iniiativa depozitului de date, dup ce n prealabil i-au sintetizat cerineleinformaionale. In acest caz, un numr de operaiuni din etapa de formulare a strategiei vor fi etapedin planificarea primei versiuni a depozitului de date: determinarea contextului organizaional,definirea modulelor depozitului de date, definirea arhitecturii depozitului de date,

evaluarea instrumentelor i a mediilor de dezvoltare.


22/35

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 formulriistrategiei 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 sistemesurs sunt sistemele operaionale care automatizeaz tranzaciile zilnice ale ntreprinderii. Pe lngsistemele 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 caresunt 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, eisunt cei mai n msur s aprecieze oportunitatea folosirii fiecrui sistem ca surs de date pentrudepozit. 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 deextragere i filtrare a datelor. Administratorii de baze de date i ceilali specialitii IT pot oferiinformaii 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 specialitiiIT din organizaie i se va urmri obinerea urmtoarelordocumente i informaii, dac nu au fostdeja colectate n etapa de stabilire a strategiei DD:- documentaia arhitecturii IT a organizaiei (toat documentaia care ofer o vedere de ansambluasupra arhitecturii IT): diagramele arhitecturii sistemului (un model al tuturor sistemelorinformaionale existente n ntreprindere i al legturilor dintre ele),modelul datelor ntreprinderii (un model al tuturor datelor care sunt stocate n prezent), arhitecturareelei (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 faceaprecieri ale mrimii ei;- planurile de perspectiv: ce proiecte de dezvoltare i implementare au fost aprobate pentruurmtoarele 6-12 luni pentru fiecare sistem surs n parte; dac schimbarea structurii datelor vaafecta preluarea datelor din sistemele surs n depozit, va aduce eventual noi date disponibile sau vorfi pierdute o parte dintre cele existente;

- sistemele de codificare: fiecare sistem surs folosete un anumit sistem de codificare i de aceeaadministratorii bazelor de date trebuie s ofere informaii referitoare la modul n care sunt generatecodurile, 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 dedate 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 cerinelorinformainale aleutilizatorilor versiunii respective. Sunt disponibile scheme rezultate din dou tipuri de modele:

relaional (bazat pe normalizare), multidimensional (bazat pe denormalizare).


23/35

n modelarea bazat pe normalizare schema bazei de date este proiectat folosind tehnicile denormalizare utilizate n sistemele relaionale (tranzacionale OLTP).

n modelarea multidimensional se lucreaz cu schemele: stea, fulg de zpad, constelaie, care suntdenormalizate 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 cmpuriledin 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 oconsecin natural a rolului integrator pe care l are depozitul de date. Exemplu, fiecare sistemoperaional va avea propriile nregistrri referitoare la clieni i produse. Un cmp din depozitul dedate care va fi denumit Nume_client sau Denumire_produs va fi populat cu date din mai multesisteme.

Este posibil i situaia invers, un cmp din sistemele operaionale poate fi divizat n mai multecmpuri n depozitul de date. Exemplu, exist sisteme operaionale care nregistreaz adresele calinii de text cu numele cmpuluiAdresa. 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 sunttransformate n depozitul de date, se recomand creearea unui tabel surs-destinaie care sevidenieze cum se transform fiecare cmp. De asemenea, trebuie s se precizeze toate regulile careguverneaz 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 suferitmodificri in timp. De exemplu, dac perioada pentru care sunt pstrate datele n depozit este de doiani i datele din ultimii doi ani trebuie ncrcate n depozit, echipa trebuie s verifice dac schema asuferit modificri n aceast perioad. n caz afirmativ, operaiunile de extragere i integrare a datelordevin 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 istoricesunt 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 afost efectuat un studiu amnunit al acestui aspect n etapa de definire a strategiei, activitatea deselectare devine opional. Dac strategia DD nu a fost formulat atunci trebuie s se fac evaluarean 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 curentPrin 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:


24/35

- Selectarea interfeelor software. Este posibil s cerem furnizorilor de tehnologii s prezinteun prototip de depozit de date pentru a-l evalua. Rezultatul evalurii ne va folosi n selectareainterfeelor: produse OLAP, generatoare etc.

- Corectitudinea schemei de date. Echipa creaz un prototip bazat pe o anumit schem i apoise 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 schemaproiectat, atunci echipa poate valida aceast schem.

- Validarea prototipului. Echipa de dezvoltatori va invita reprezentanii utilizatorilor sfoloseasc efectiv prototipul pentru a-i formula o prere iniial. Prototipul este primulrezultat concret al efortului de dezvoltare. El ofer utilizatorilor ceva tangibil, pe care l potvedea i folosi. El permite, de asemenea, utilizatorilor s experimenteze pentru prima datnoua tehnologie. De regul, o astfel de experien declanaz o multitudine de reacii pozitivei negative din partea utilizatorilor. Aceste reacii pot ghida echipa de dezvoltare privindcoreciilor care trebuie fcute. La validarea prototipului, urmtoarele aspecte trebuie sdevin clare pentru utilizatori: obiectivele ntlnirilor, natura i sursa datelor folosite lavalidare, aria de cuprindere a prototipului.

2.3. Implementarea depozitelor de date

ntreprinderile, de-a lungul anilor, au cutat diferite soluii pentru a obine rapoartele decizionalesolicitate de manageri. Unele dintre aceste soluii necesit doar programe simple de extragere adatelor, care sunt executate periodic pentru a obine datele necesare. Alte soluii necesit o seriecomplex de pai care combin manipularea manual a datelor, programe de extragere, formule deconversie.

Definirea ariei de cuprindere

n absena unui depozit de date multe dintre cerinele decizionale sunt clasificate n categoriarapoartelor ad-hoc i, ca urmare, cele mai multe dintre programele de extragere i procesare nu suntsuficient documentate i sunt cunoscute doar de cei care le-au conceput. Astfel, se ajunge n situaian care, n aceeai organizaie, nu exist standarde n acest domeniu (de exemplu, persoane diferiteaplic 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 vizateurmtoarele 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 startcare 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 laformulele i regulile de transformare a datelor.

o Transformarea manual a datelor. n cazul n care exist astfel de situaii, ele trebuieanalizate cu grij pentru a se obine informaiile necesare i pentru a se elimina o parte dintretransformrile manuale.

Este posibil ca echipa care planific depozitul de date s descopere o serie de deficene legate derapoartele 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 creezsau citete raportul.


25/35

Fiecare secvent de date, care este necesar pentru crearea rapoartelor solicitate de manageri, provinedin unul sau mai multe sisteme surs disponibile n ntreprindere, ns exist date care nu se regsescn 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 aledatelor 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.De exemplu, dac sistemele de acordare a mprumuturilor bancare nu nregistreaz domeniul deactivitate n care activeaz fiecare beneficiar de creadite atunci banca va avea probleme serioase cndva dori s-i analizeze gradul de expunere la risc n funcie de sectorul economic finanat, deoarecenu va putea genera un raport detaliat pe aceast tem.- Secvene de date incomplete sau opionale. Exist cazuri cnd o secven de date este clasificat cutermenul de reinut, ns nu exist reguli care s precizeze clar c acea secvent trebuie s fiecolectat i stocat sau nu. Aa se ajunge n situaia c astfel de secvene de date sunt nregistratedoar 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 pentrutoate reperele avute n vedere.Exemplu, sistemul de acordare al mprumuturilor poate avea un cmp numit stare_client, dardezvoltatorii aplicaiei l-au prevzut ca fiind un cmp opional. Astfel, doar o parte a raportuluianterior poate fi realizat i anume doar pentru clienii pentru care s-au nregistrat valorile pentruacel cmp.- Date eronate. Pot aprea date eronate cnd acestea sunt stocate n unul sau mai multe surse dedate, din una dintre urmtoarele cauze posibile: erori la introducerea datelor, datele nu suntdisponibile, se merge pe varianta valorilor implicite care de fapt nu sunt corecte.

Not. Se poate observa cum aria de cuprindere a unui depozit de date poate fi compromis delimitrile impuse de datele din sistemele surs curente. Cele mai multe proiecte DD se limiteazdoar la ceea ce ofer sistemele surs. Trebuie s lum n considerare i varianta mbuntirii

sistemelor surs n paralel cu desfurarea proiectului DD. Echipa de dezvoltare trebuie sdocumenteze toate limitrile impuse de sistemele curente, iar aceast documentaie va deveni intrare

pentru procesul de ameliorare.

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 alefuncionalitilor 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 utilizatoriiactuali 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 oferiteexplicaii n legtur cu importana datelor care lipsesc i modul cum pot fi ele obinute.

o Ameliorarea calitii datelor. Pentru fiecare sistem operaional, trebuie evideniate toatezonele n care poate fi mbuntit calitatea datelor i cum anume.

o Estimarea resurselor i a efortului. Pentru fiecare sistem operaional, se poate preciza un costestimativ i durata de timp necesar pentru a aduga datele lips sau pentru a mbunticalitatea.

Concluzie. Planificarea depozitului de date are ca scop definirea clar a ariei decuprindere a fiecruimodul din depozit. Combinaia dintre abordrile top-down i bottom-up ofer procesului de


26/35

planificare avantajul de a vedea problema din dou perspective complementare: cerineleutilizatorilor i datele disponibile n sistem.

Crearea planului de implementare pentru versiunea curent

Dup definirea ariei de cuprindere i specificarea modului de transformare a datelor surs, esteposibil 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 multesisteme surs, cu att procesele de extragere i integrare sunt mai comlexe.- Numrul de procese decizionale asistate. Cu ct sunt asistate mai multe procese decizionale, cuatt va fi mai mare numrul utilizatorilor care vor avea o prere n privina depozitului de datereferitoare la definiii de termeni, reguli care trebuie respectate etc.- Numrul de subiecte reinute n depozitul de date. Unul dintre atuurile tehnologiei depozitelor dedate 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 aefortului de ncrcare, indexare i modificare a depozitului de date. Volumul de date permite echipeide dezvoltare s aprecieze durata de ncrcare a depozitului (numrul de nregistrri ponderat cudurata necesar pentru ncrcarea unei nregistrri).- Disponibilitatea i calitatea documentaiei sistemelor surs. n cazul n care aceste documentaiiexist 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 (ctde proaspete trebuie s fie datele) i este determinant pentru proiectarea i implemenatreadepozitului.- Disponibilitatea solicitat de utilizatori. Un depozit de date care s fie disponibil pentru utilizatori24 de ore, timp de apte zile pe sptmn, necesit o arhitectur care este complet diferit de unulcare 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 alcompartimentului IT i al altor persoane implicate, atunci planul implementrii va estima o duratmai mic de realizare.

Implemenatrea propriu-zis a depozitului de date

Procesul de implementare a depozitului de date const de fapt din activiti legate de implementareafiecrei 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 DDcare asigur un flux constant de date valide din sistemele operaionale n depozitul de date. Alimembrii ai echipei sunt responsabili cu instalarea i configurarea interfeelor pentru a permiteutilizatorilor accesul la depozitul de date.

Un proiect de implementare trebuie s dureze ntre trei i ase luni. Progresul lucrrilor efectuatevariaz n funcie de calitatea proiectrii depozitului de date, calitatea planului de implementare, dedisponibilitatea i interesul personalului ntreprinderii.


27/35

Instruirea utilizatorilor i testarea depozitului de date sunt activiti care au loc spre finalulproiectului de implementare, nainte de instalarea definitiv. Odat instalatdepozitul de date, ncepactivitile 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 dateoperaionale, finalizarea proiectrii schemei fizice a depozitului de date, construirea sau configurareasubsistemelor de extragere i transformare, construirea sau configurarea subsistemului pentrucalitatea datelor, construirea subsistemului pentru ncrcarea depozitului de date.

1. Achiziia i configurarea mediului de dezvoltarePrima activitate din procesul de implementare o reprezint achiziia i configurarea mediului dedezvoltare, care cuprinde urmtoarele aspecte: instalarea componentelor hardware, instalareasistemului 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 sistemeloroperaionale. n cazul n care depozitul de date este gestionat n manier relaional, sistemulrelaional care face acest lucru nu trebuie neaprat s fie acelai cu cel existent n sistemeleoperaionale.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 operaionaleUneori 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 dedate nu a fost nc realizat. De aceea echipa trebuie s intre n posesia copiilor coleciilor de dateoperaionale 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 icompletitudinii datelor care sunt ncrcate pe serverul DD. O modalitate este aceea de a folosinumrarea cazurilor (numrul de clieni, numrul de conturi, numrul de tranzacii etc) care suntcomparate cu tabelele iniiale. Utilitarele pentru verificarea calitii datelor pot sprijini echipa dedezvoltarea 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-oversiune final a schemei fizice, avndu-se n vedere aspectele specifice ale sistemului de gestiune abazelor 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 atabelelor dimensiune cu cmpurile lor specifice. Administratorul depozitului de date poate opta

pentru divizarea unei dimensiuni logice (de exemplu, client) n dou sau mai multe dimensiuniseparate (de exemplu, o dimensiune clienti o dimensiune demografie) pentru a economisi spaiu dememorare 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 ainterogrilor ce se vor efectua asupra depozitului de date.


28/35

Parionarea. Administratorul depozitului de date poate opta ntre partiionarea tabelelor de fapte ide dimensiuni, n funcie de mrimea lor i de posibilitile de partiionare care sunt suportate demotorul de baze de date. Decizia de partiionare trebuie de asemenea s aib n vedere c un depozitde date partiionat este mai uor de gestionat, ns performana interogrilor scade.

4. Construirea sau configurarea subsistemelor de extragere i transformareSubsistemele de transformare i extragere trebuie s filtreze i s ncarce datele din sistemuloperaional n depozitul de date, apoi s le pun la dispoziia utilizatorilor. Aceaste activiti nu potfi automatizate total, deoarece difer de la o organizaie la alta n funcie de sistemele surs, mediulde dezvoltare i de cerinele utilizatorilor.

Subsistemul de extragere se refer la procesul de obinere a datelor necesare din coleciile de dateale 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 ladispoziie 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. Deaceea, organizaiile prefer deseori s-i dezvolte propriile lor aplicaii de extragre a datelor. Aceastsoluie este viabil n msura n care sistemele surs sunt ntr-un mediu omogen. Aplicaiile pentruextragerea 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 foststabilite 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 daten diverse formaturi i tipuri. Aceste secvene individuale de date sunt modificate n impul procesuluide transformare pentru a respecta setul standard de formate din depozitul de date.- Redundana datelor. nregistrrile din mai multe surse sunt comparate pentru a identificanregistrrile duplicat bazate pe valoarea cmpurilor cheie. Duplicatele sunt eliminate pentru a crea osingur nregistrare pentru un client, un produs, un angajat sau o tranzacie. Duplicatele de tipexcepie pot fi rezolvate manual prin folosirea unui sistem de avertizare. Tot manual se vor rezolva inregistrrile duplicat cu valori conflictuale n cazul n care nu exist mecanisme clare pentrustabilirea 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 ntlnitecazuri de acest gen se refer la adresa clienilor care n sistemul surs este memorat ntr-un singurcmp, 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 multecmpuri 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 penelesul 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 suntutile pentru cei ce folosesc coninutul depozitului de date.- Derivarea valorilor. Estimrile, determinarea de indici i alte valori derivate pot fi calculatefolosind diverse formule. Prin calcularea i ncrcarea acestor valori n depozit, posibilitatea cautilizatorii s le calculeze greit este eliminat.


29/35

- Agregarea valorilor. Agregrile pot fi, de asemenea, precalculate nainte de ncrcarea lor ndepozitul de date. Aceasta este o alternativ la ncrcarea doar a valorilor atomice n depozitul dedate.

5. Construirea subsistemului pentru calitatea datelor

Probleme legate de calitatea datelor nu sunt ntotdeauna vizibile nc de la nceputul proiectului deimplementare, 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 oconstituie tocmai slaba calitate a datelor. De asemenea, foarte important este ipercepia pe care oau utilizatorii despre date. Acetia vor folosi depozitul de date doar n msura n care au convingereac datele pe care le gestioneaz sunt corecte. Rezult c subsistemul pentru calitatea datelorreprezint o component critic a arhitecturii depozitului de date. nelegerea cauzelor care determinerori 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 roldeosebit de important n aceast etap.Erorile au urmtoarele cauze:- Valori lips. Valorile lipsesc din sistemele surs, din cauza nregistrrilor incomplete sau acmpurilor opionale care nu sunt completate.- Integritatea referenial slab. Uneori, integritatea referenial nu poate fi realizat n sistemelesurs, din cauza valorilor inconsistente.- Erori n datele precalculate. O parte din datele din depozitul de date pot fi precalculate nainte dencrcarea lor, ca parte a procesului de transformare, dac formulele sau calculele sunt greite, atuncidepozitul 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 prealabiltransformri la o msur unitar.- Obinerea duplicatelor. Deduplicarea datelor trebuie s aib loc nainte de ncrcarea lor ndepozitul de date. n cazul n care aceast operaiune nu se desfoar corect, exist riscul ca ndepozit 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 necesitapelarea la proceduri automate de partiionare a cmpurilor, care pot s nu funcioneze corect n toatecazurile.- Ierarhii multiple. Multe dintre dimensiunile depozitului de date vor avea ierarhii multiple

determinate de necesitile de analiz. De exemplu, dimensiunea timp poate avea o ierarhie zi-lun-trimestru-an, precum i ierarhiile zi-sptmn i zi-lunfiscal-trimestrufiscal-anfiscal.Nenelegerea semnificaiilor acestor ierarhii multiple din diferite dimensiuni poate cauza ncrcrieronate n depozitul de date.- Termeni i reguli conflictuale. Regulile sau termenii conflictuali pot determina planificatoriidepozitului 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 organizaieipoate 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


30/35

anumite prioriti, iar efortul de ameliorare poate fi direcionat n mod eficient ctre zona decel mai mare interes.

o Definirea modului de filtrare i mbuntire a datelor. Pentru fiecare secven de date cuimportan mare pentru ntreprindere, trebuie stabilit o tactic specific de ameliorarea acalitii. 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 dedate.

o Prevenirea erorilor. Efortul ntreprinderii nu trebuie s se limiteze doar la corecii asupradatelor deja existente, ci doar s aib n vedere prevenirea apariiei erorilor. Dac sistemeleoperaionale care genereaz date eronate nu sunt revizuite, ele vor continua s fie o surssigur de erori pentru depozite.

Avnd n vedere complexitatea unui astfel de proiect, nu ar fi realist dac am considera c exist unsingur instrument care s asigure calitatea datelor. De asemenea, orict de mari ar fi eforturile deameliorare a calitii, ntreprinderea trebuie s fie oricnd pregtit pentru a aborda noi problemereferitoare la acest aspect.Toate erorile descoperite ar trebui s fie corectate la surs, ceea ce nseamn c sistemeleoperaionale trebuie s fie modificate astfel nct s conin valorile corecte. Acest practic asigurc att utilizatorii sistemelor operaionale, ct i cei de la nivel decizional vor beneficia de datecorecte. Experienta a dovedit ns c procesul de corectare a datelor la surs poate fi uneori dificil deimplementat att din cauza responsabilitilor operaionale, ct i din cauza faptului c datele corectenu sunt cunoscute. Responsabilitatea pentru corectarea datelor din sistelele surs revine personaluluioperaional care nu prea agreaz ideea de a accepta o responsabilitate suplimentar. Chiar dac setie despre o anumit secven de date c nu este cea corect, pot exista situaii n care s nu poat fideterminate valorile corecte din cauza imposibilitii obinerii lor.

6. Construirea subsistemului pentru ncrcarea depozitului de dateSubsistemul pentru ncrcarea depozitului de date preia schema generat de subsistemul de extragerei transformare i ncarc datele direct n depozit. Dup cum s-a menionat anterior, datele care vor fincrcate 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 urmtoarelefaciliti:- ncrcarea nregistrrilor n tabelele dimensiune. n sistemele surs, fiecare nregistrare referitoarela 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 surssunt 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 oconcatenare a cheilor din tabelele dimensiune cu care sunt n legtur. nregistrrile din tabeleledimensiune se ncarc nainte de cele din tabelele de fapte pentru a se putea realiza integritateareferenial.- Calcularea valorilor agregate pe baza nregistrrilor surs. Dup nrcarea valorilor atomice ndepozitul de date, subsistemul de ncrcare trebuie s fie capabil s calculeze i s stocheze i valoriagregate.- Reindexrile. Dup ce toate datele s-au ncrcat cu succes, indecii din tabelele cele maiimportante 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 aerorilor care au aprut n timpul fiecrui pas (de exemplu, erori cu privire la integritatea referenial).


31/35

Exist discuii dac datele inconsistente trebuie sau nu s fie ncrcate n depozitul de date. Uneleechipe de dezvoltare prefer s ncarce doar date corecte n depozitul de date, argumentnd c dateleinconsistente sunt generatoare de erori. Alte echipe prefer s ncarce ambele categorii de date, cucondiia 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 bazatepe o imagine incomplet. Probabil c muli ar considera necuprinderea datelor inconsistente ca pe unlucru 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 depozituluide date blocheaz accesul pe durata desfurrii lui. Cea mai mare provocare n construirea unuisistem de ncrcare o constituie optimizarea operaiunii de ncrcare astfel nct ea s blocheze ctmai puin accesul utilizatorilor la date.

Stabilirea schemei depozitului de date

Administratorul DD realizeaz schema acestuia n paralel cu construirea sau configurareasubsistemelor back-end (extragere i transformare, asigurarea calitii datelor, ncrcare). n acestsens, el trebuie s efectueze urmtoarele activiti:- Crearea tabelelor DD. Schema fizic a depozitului de date se implementeaz prin crearea efectiva 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 adepozitului de date.- Popularea DD. Dup definirea schemei tabelelor i precizarea indecilor se trece la ncrcareadatelor. Trebuie avute n vedere i tabelele create pentru a gestiona excepii, de genul celei prezentaten legtur cu restricia referenial.

Metadatele din depozitul de date

Metadatele se definesc ca fiind informaii despre date. Aceast definiie nu este perceput corect deobicei de cei ce ncearc s o neleag i de aceea poate ar fi mai potrivit s remarcm c metadateledescriu coninutul depozitului de date, indicnd de unde provin datele originale i documentndregulile care guverneaz transformarea datelor. Interfeele DD folosesc metad

depozite de date -

Documents