INTRODUCERE Not.

Conceptul de Inteligena Afacerii IA (Business Intelligence - BI) este o tehnologie informatic ce privete organizarea i funcionarea ntreprinderii, precum i a conducerii acesteia, avnd ca suport soluiile informatice. IA a fost prezentat la modulul SBDE i ea include i depozitele de date. n practica sistemelor de baze de date, exist astfel de sisteme n care se stocheaz volume foarte mari de date, care au din acest motiv caracteristici specifice de organizare i prelucrare. Aceste caracteristici sunt asigurate de urmtoarele tehnologii ale IA privind prelucrarea volumelor mari de date: depozitele de date (data warehouse), concentrrile de date (data marts), extragerea de date (data mining).

DEPOZITELE DE DATE (data warehouse) Depozitul de date - DD este o baz de date foarte mare, proiectat pentru a susine procesul decizional i optimizat pentru interogri rapide i agregri complexe. Depozitele de date rezolv problemele legate de sursele de date disparate i de scopurile incompatibile dintre procesarea tranzaciilor i aplicaiile de Inteligena Afacerii. Scopul unui depozit de date este de a furniza un stoc central de date unde informaiile din unul sau mai multe sisteme tranzacionale pot fi consolidate ntr-o singur, integrat i consistent surs de date. Depozitul de date este proiectat pentru a optimiza obinerea de rapoarte pe un numr mare de nregistrri ale bazei de date. El presupune multe regsiri i foarte puine actualizri (sau deloc). Caracteristicile principale ale DD sunt: - dimensiunea foarte mare, volumul de date fiind de la sute de GB la TB; - este organizat la nivelul unei organizaii; - cererile de regsire sunt ad-hoc i implic foarte multe nregistrri; - sursele de date sunt variate: istorice statistice, demografice etc.; - se pot folosi modele de date multidimensionale i tehnologia OLAP; - colecia de date de tip DD este: o orientat pe subiectele importante din organizaie: clieni, produse etc. o integrat deoarece datele provin din surse diferite printr-un proces anterior de curare / filtrare i prelucrare; o non-volatil pentru c operaiile efectuate sunt n special de regsire i periodic de ncrcare, nu de actualizare; o dependent de timp pentru c datele sunt stocate pentru o perioad de 5-10 ani; - necesitatea DD se refer la mbuntirea calitii informaiilor din organizaii. De cele mai multe ori, DD sunt incluse ca faciliti care aparin unor SGBD, de exemplu Oracle Warehouse Builder, Oracle Discoverer. CONCENTRRILE DE DATE (data marts) Concentrarea de date este un DD mai mic organizat la nivelul unui departament al unei organizaii.

Deoarece procesul dezvoltrii unui depozit de date la nivel de ntreprindere este lung i complex i de multe ori nu se ncheie cu succes, practicienii acestuia au adoptat o abordate alternativ : dezvoltarea unor depozite mai mici i consolidate, cunoscute sub numele de concentrri de date. Astfel, prin date stocate n volume mai mici, nevoia de o raportare mai exact i imediat poate fi suplinit ntr-un ciclu de dezvoltare mai scurt. Caracteristicile principale ale unei concentrri de date sunt: - dimensiunea mare, volumul de date fiind de zeci de GB; - este concentrat pe un singur subiect din organizaie, de exemplu doar vnzrile; - sursa datelor este divers: din SBD operaionale ale organizaiei, din DD, din surse externe; - agregarea datelor este intens utilizat i se face rapid prin mecanisme specifice; Aceste faciliti, dac sunt integrate n interfee care aparin unui SGBD, rspund optim tuturor cerinelor unei afaceri, deoarece se bazeaz pe un ansamblu mare i variat de date, cu faciliti de regsire deosebite (exemplu Oracle Data Mart Suite, Oracle Discoverer).

EXTRAGEREA DE DATE (data mining) Extragerea de date const n analiza complex a datelor prin metode i mecanisme specifice, ca o dezvoltare a analizei statistice clasice. Extragerea de date duce Inteligena Afacerii cu un pas mai departe dect OLAP. n OLAP utilizatorul este angajat n mod activ n explorarea datelor, pe cnd n data mining, informaia spune ceva despre ea fr s fie adresat vreo ntrebare. Tehnologia de data mining utilizeaz metode de cutare complexe spre a identifica modele i grupri ale datelor. Extragerea de date poate identifica tendine nesuspectate n comportamentul consumatorului, care potenial pot fi utilizate s prevad comportamentul viitor Extragerea de date se mbuntete cu ct crete cantitatea de date i necesit depozite de date de nalt calitate pentru a putea da rezultate utile. Data mining se folosete n cel puin dou domenii: statistic superioar pentru analize complexe, inteligena artificial pentru descoperire i cunoatere. Facilitile de extragerea de date pot fi incluse n SGBD avnd stocul de date pregtit deja, prin interfee specializate cum ar fi Oracle Data Mining i Oracle Miner.

Capitolul 1 Depozite de date (DD) aspecte fundamentale

1.1. Definire DD 1.2. Organizarea datelor n DD 1.3. Faciliti oferite de DD 1.4. Baze de date i Depozite de date 1.5. Arhitectura DD 1.6. Tipuri de depozite de date

1.1. Definirea Depozitelor de Date Depozitele de Date - DD (DW - data warehouse) reprezent rezultatul interferenei mediului economic i al tehnologiilor informatice avansate. Mediul economic este tot mai competitiv, tinde spre globalizare, devine tot mai complex i solicit informaii elaborate pentru sprijinirea deciziilor strategice. Un astfel de mediu economic a determinat evoluia activitii de realizare a sistemelor informatice de la orientarea pe operaional (activitatea curent a firmei care pleac de la funciile ntreprinderii i funciile conducerii) spre orientarea pe procesul de afacere. Procesul de afacere (business process) este un ansamblu de activiti interdepartamentale, la nivelul unei organizaii, care presupune una sau mai multe intrri i care genereaz un rezultat important pentru client (intern sau extern). Sunt dou caracteristici fundamentale ale procesului de afaceri: - acum managerii gndesc i decid mai mult la nivelul procesului de afaceri (interdepartamental) dect la nivelul funciilor ntreprinderii. Acest lucru nseamn c organizaia este privit din punctul de vedere al clientului, ceea ce corespunde societii informaionale care pune pe primul plan clientul; - activitatea departamentelor unei organizaii va fi integrat, ceea ce nseamn o bun comunicare ntre ele. Rezult astfel realizarea unor sisteme informatice integrate. Evoluia tehnologiilor informatice ofer soluii eficiente de gestionare a unor volume foarte mari de date 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 n timp 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 organizarea sistematic, nelegerea i utilizarea datelor n luarea deciziilor strategice, ntr-un mediu economic competitiv i n rapid evoluie. Managerii au nteles c datele stocate de sistemele informatice operaionale, n fiiere sau baze de date, reprezint o min de aur informaional care 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 510 ani. William Inmon (vicepreedintele firmei Prism Solutions), este printele necontestat al noiunii de Data Warehouse, iar viziunea sa se concentraz asupra rolului DD ca baz informaional a deciziei manageriale, pstrnd astfel un nivel nalt de generalitate si permind unor multiple implementri s intre n sfera acestei noiuni. Earl Hadden este cel care a enunat i a experimentat o metodologie riguroas pentru implementarea depozitelor 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 separat de bazele de date operaionale ale unei organizaii i care este construit din date provenite din sisteme surs prin extragere, filtrare, transformare i stocare n depozite speciale, n scopul sprijinirii proceselor decizionale. Depozitele de date sprijina prelucrarea informaiilor pentru analiz, furniznd o platform solid de consolidare a datelor istorice. Un depozit de date este un ansamblu de date consistente, din punct de vedere semantic, care servete la o implementare fizic a unui model de date pentru sprijinirea deciziei i stocheaz informaii pe care o organizaie le solicit n luarea deciziilor strategice. 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. Not. Soluiile informatice cu DD sunt oferite pe pia astfel: 40% Oracle, 22% IBM, 15% Microsoft, 12% Teradata i altele.

1.2. Organizarea datelor n DD Sursele de date pentru depozitul de date provin n principal din datele importate din sistemul informatic operational, dar mai pot proveni din datele de arhiv (n perioada de constituire a depozitului) 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 optimizarea i 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 este optimizat 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 nregistrri care vor conine date despre client, date despre produsele sau serviciile comandate, date despre modul 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 (numrul comenzii, poziiile liniilor n cadrul comenzii etc) sunt lipsite de relevan din perspectiv informaional 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 n mod intenionat (prin denormalizare si sumarizare) pentru a permite un acces mai rapid i uor la date. Integrarea datelor reprezint un aspect important al depozitului de date i anume raiunea pentru care acesta este creat. Datele sunt adunate pentru a rspunde nevoilor informaionale ale ntregii organizaii, asigurnd faptul c rapoartele generate pentru diverse compartimente vor conine aceleai rezultate. Sistemul operaional este, de obicei, format din mai multe subsisteme relativ independente, create la momente diferite, de echipe diferite, n maniere diferite, ceea ce face greoaie folosirea unui astfel de sistem pentru analiz. Integrarea datelor provenind din sistemul operational i din alte surse se refer la urmtoarele aspecte: - modaliti unice de codificare exist nenumrate variante de a codifica un cmp dar o aplicaie pentru analiza datelor va trebui s se bazeze pe o codificare unic; - Sistem de uniti de msur unitar - unitile de msur pentru diferite cmpuri trebuie exprimate ntr-un sistem unic (metric etc.); - Sistem stabil de reprezentare fizic a datelor - n aplicaiile tranzacionale este posibil ca aceleai date s fie memorate n moduri de organizare diverse. Acestea trebuie stabilizate dup anumite reguli precise; - Convenii clare privind modul de reprezentare a datelor datele calendaristice, cmpurile care definesc timpul etc., trebuie s respecte conveniile internaionale;

Convenii unice privind denumirile cmpuilor de date - n sistemul operaional acestea pot s difere 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 afl ntr-o continu evoluie iar datele pe care le conine sunt relevante doar pentru momentul n care sunt accesate. Orizontul de timp pe care l acoper este de regul zile sau luni, deoarece dup acest interval tranzaciile efectuate sunt arhivate, fiind considerate deja de domeniul istoriei, deci neinteresante din perspectiv operativ. Pentru analiza economic, dimpotriv, informaiile care au caracter istoric sunt esentiale, deoarece ele pun n evident tendine care reprezint fundamentul unei prognoze corecte. Depozitul de date este un istoric al sistemului operaional. Orizontul de timp pe care l acoper depozitul de date este de cel puin cinci ani, ajungnd uneori la zece ani, n funcie de dinamica evoluiei pieei i, deci, de relevana datelor cu caracter istoric pentru nevoile analizei. Din 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 se realizeaz aici doar prin adugarea periodic a unor date extrase din sistemele operative sau din alte surse de date (campanii). Din punctul de vedere al aplicatiilor care folosesc depozitul de date, accesul la date este doar pentru citire. n sistemul operational, o tranzacie trebuie s duc colecia de date dintr-o stare consistent ntr-o alt stare consistent, iar aceasta implic mecanisme complexe de meninere a integritii datelor (jurnalizare, salvare/restaurare, blocare). n cazul depozitelor de date, mecanismele de integritate sunt inutile, astfel c gradul de libertate ctigat poate fi utilizat pentru optimizarea accesului la date prin denormalizare, sumarizare, statistici ale accesrii datelor, reorganizare dinamic a indexrii etc. Un depozit de date conine un volum foarte mare de date. Unele dintre aceste date provin din sursele operaionale ale organizaiei, altele pot proveni din surse externe. 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. Metadatele sunt folosite pentru administrarea depozitului de date, deoarece conin informaii despre: sursa datelor, algoritmii de sumarizare, statisticile de utilizare etc. Metadatele sunt create pentru toate numele de date i definiiile din depozit. Metadate adiionale sunt create pentru a asocia intervale 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) i informaii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erori etc.); algoritmii utilizai pentru sumarizare, care includ: msura i dimensiunea algoritmilor definii, date despre granularitate, partiii, arii de subiecte, agregri, sumarizri, rapoarte i filtre predefinite; maprile (transformrile) de la mediul operaional la depozitul de date care includ: bazele de date surs i coninutul lor, descrierile interfeelor (gateways), partiionarea datelor, extragerea datelor, filtrarea datelor, regulile de ntreinere, securitate a datelor; date referitoare la performanele sistemului care include indici i profiluri care mbuntesc accesul la date i performanele de cutare; metadatele economice (business metadata), care includ termenii economici i definiiile aferente.

Exemple de metadate. Descrierea proprietilor datelor (obiectelor) din lumea real se face prin intermediul metadatelor, printr-un proces de abstractizare. Astfel, metadatele referitoare la cmpurile unui depozit de date se vor referi la: denumirea cmpului (aa cum va fi folosit n tabela relaional fizic), sinonim pentru denumirea cmpului (aa cum este folosit de utilizatori), tipul de date pentru fiecare cmp (aa cum este acceptat de SGBD), indexarea (dac va fi folosit pentru cmp), cheia (dac un cmp este cheie), formatul cmpului, descrierea (o definiie a cmpului). Rolul metadatelor pentru depozitul de date reiese din urmtoarele considerente: - stabilesc contextul depozitului de date. Sub orice sistem, inclusiv DD, utilizatorul intr sub o sesiune de lucru, adic se creaz automat un context de lucru: parametri setai, conectri efectuate, drepturi existente etc. - ajut administratorii i utilizatorii depozitului s localizeze i s neleag secvenele de date att n sistemele surs ct i n structura depozitului. n sistemele operaionale, dezvoltatorii i administratorii bazelor de date lucreaz cu metadate n fiecare zi. Toat documentaia tehnic a sistemelor reprezint ntr-un fel sau altul metadate. Ele rmn totui transparente pentru majoritatea utilizatorilor, ei percepnd n general sistemul ca pe o cutie neagr ce ofer 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. - procesul de analiz cuprinde mai multe etape: identificarea datelor, obinerea datelor, interpretarea i analiza datelor pentru a obine informaii, prezentarea informaiilor i recomandarea unei direcii de aciune. Pentru ca depozitul de date s fie folositor analitilor din ntreprindere, metadatele trebuie s ofere utilizatorilor informaii care s-i ajute n parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie s ajute utilizatorii s gseasc rapid datele n depozit i s interpreteze corect datele obinute prin oferirea informaiilor referitoare la formatul i semnificaia datelor; - metadatele sunt o form de auditare a transformrii datelor. Metadatele documenteaz transformarea datelor surs n date ale depozitului, adic trebuie s fie capabile s explice modul n care o secven de date din depozit este dedus din sistemele operaionale. Toate regulile care guverneaz transformarea datelor n noi valori sau

noi formate sunt considerate a fi metadate. Aceast form de audit este necesar atunci cnd utilizatorii trebuie s aib ncredere n veridicitatea i calitatea datelor din depozit. De asemenea, este important ca utilizatorii s-i poat da seama de unde provin datele existente n depozit. Este de dorit ca, pe baza acestor metadate, anumite produse s poat genera programe de extragere i transformare pentru cei care se ocup de interfaa de analiz a depozitului de date; metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea valorilor valide pentru fiecare cmp din depozit. nainte de a fi efectiv ncrcate n depozit, datele pot fi revzute i erorile pot fi corectate. De asemenea, regulile de corecie a erorilor pot fi documentate tot prin metadate; permite gestiunea versiunilor. Un depozit de date conine date pentru diferite perioade de timp i de aceea este important s avem n vedere efectul pe care l poate avea timpul asupra regulilor de trecere a cmpurilor surs n cmpuri destinaie, asupra agregrilor etc. Utilizatorii trebuie s aib acces la metadatele corecte pentru perioada de timp pe care o studiaz. Ceea ce la prima vedere ar prea s fie o eroare n transformarea datelor poate fi de fapt rezultatul schimbrii regulilor de transformare a datelor. De aceea este important ca metadatele s fie corect gestionate din 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 folosite pentru 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 de acces; o metadate pentru utilizatori. Acestea au rolul de a ajuta pe utilizatori s-i creeze propriile lor interogri i s interpreteze rezultatele. Pentru aceasta, ei au nevoie s cunoasc definiiile datelor din depozit, descrierea lor, precum i orice ierarhie care poate exista n diferite dimensiuni. Astfel de metadate sunt: coninutul depozitului de date, rapoarte i interogri predefinite, definiiile ierarhiilor, calitatea datelor, istoricul ncrcrii depozitului de date, reguli detergere a datelor; o metadate pentru optimizare. Aceastea au rolul de a crete performanele depozitului de date. Exemple de astfel de metadate sunt definiiile agregrilor i colecii de statistici. 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, obinut dintr-o varietate de surse, disponibil utilizatorilor ntr-un mod uor perceptibil i destinat fundamentrii deciziei n contextul afacerii.

1.3. Faciliti oferite de DD Creterea volumului de date, precum i perfecionarea software-ului de gestiunea acestuia au condus la 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 anumit segment de pia etc. Pentru a obine informaiile dorite, DD sunt supuse unor prelucrri complexe, cu ajutorul unor metode specifice, cum ar fi: analiza multidimensional a datelor, metode statistice superioare de prognoz, metode matematice aplicate unui volum foarte mare de date. Aceste metode presupun folosirea unui software specializat deosebit de complex, bazat pe noi tehnologii informatice: 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 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 functionalitii sistemului pot deveni operaii 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 tot depozitul de date, se poate crea un sub-depozit (data mart concentrri de date) care s conin numai datele relevante pentru analiza necesar. Concentrrile de date (data marts) pot fi construite s funcioneze pe configuraii mai modeste dect depozitele de date i sunt specifice unei anumite aplicaii. 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 anumit compartiment al organizaiei (de ordinul GB). Conectnd impreuna Concentrrile de date aferente diferitelor 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 de construit i mai flexibil. Depozitele de date sunt destinate managerilor i analitilor angrenai n luarea deciziilor strategice privind dezvoltarea i viitorul organizaiilor. Pentru aceasta, ei au nevoie de interfee performante de accesare i utilizare a datelor din depozite, adic de produse software asociate depozitului de date: - interfee oferite de SGBD utilizatorilor, care au nevoie de acces rapid, de informaii punctuale (limbaje de interogare gen SQL, generatoare de rapoarte); - interfee specializate pentru asistarea deciziilor, care transform datele n forma cerut de decideni (grafice, diagrame, organigrame) sau ofer posibilitatea analizei tendinelor, corelaiilor i interpretarea acestora (OLAP, Data mining). Interfeele OLAP se bazeaz pe reprezentarea multidimensional a datelor (cubul de date) i permite analiza interactiv i rapid a datelor prin operaiuni specifice. Utilizatorul poate

obine rezultate immediate parcurgnd dinamic dimensiunile cubului de date, lucrnd cu niveluri diferite de sintez/detaliere (exemplu Oracle OLAP). Interfeele de tip Data Mining asigur extragerea i transformarea datelor n cunotiine (de aceea mult lume consider termenul Data Mining sinonim cu termenul Knowledge Discovery in Databases - KDD). Se utilizeaz tehnici ale analizei statistice superioare i de Inteligen Artificial care 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 fi consultate rapid, prin structuri de acces optimizate i se bazeaz, n majoritatea cazurilor, pe tehnologia relaional. Sistemele de baze de date relaionale sunt adecvate aplicaiilor curente de gestiune i au ca obiectiv execuia on-line a tranzaciilor i proceselor de interogare (sunt sisteme tip OLTP On Line Transaction Processing). Aceste sisteme implementeaz toate operaiile zilnice dintro organizaie. Sistemele cu depozite de date servesc utilizatorilor sau specialitilor n domeniul analizei datelor i lurii deciziilor, pot organiza i prezenta datele n formate variate, n ordinea solicitrilor, de la diferii utilizatori (sunt sisteme tip OLAP On Line Analytical Processing). Bazele de date din sistemele operaionale conin date curente, detaliate, care trebuie actualizate i interogate rapid, n condiii de deplin securitate, constituind suportul sistemelor informaionale de prelucrare a tranzaciilor. Depozitele de date sunt construite special pentru sprijinirea lurii deciziilor. Ele au ca obiectiv regruparea datelor, agregarea i sintetizarea lor, organizarea i coordonarea informaiilor provenind din surse diferite, integrarea i stocare acestora pentru a da decidenilor o imagine adecvat care s permit regsirea i analiza eficace a informaiilor necesare. Interogrile obinuite ntr-un depozit de date sunt mai complexe i mai variate dect cele din bazele de date. Ele se aplic asupra unor volume foarte mari de date i presupun calcule complexe (analiza tendinei, medii, dispersii etc.), care necesit adesea agregri. Bazele de date sunt orientate pe client (customer oriented) i sunt utilizate pentru procesarea tranzaciilor i interogrilor. DD sunt orientate pe pia (market oriented) i utilizate de manageri i analiti de date. BD gestioneaz date curente care sunt destul de detaliate pentru a fi uor utilizate nactivitatea operaional. DD gestioneaz date istorice, furniznd faciliti pentru sintetizare i agregare, precum i pentru stocarea i gestionarea informaiilor cu diferite niveluri de granularitate. Aceste aspecte fac ca datele s fie uor utilizate de ctre decideni, mai ales n tactica i strategia organizaiei. La BD sursele de date sunt tranzaciile atomice, iar accesul este de tip citire i scriere. La DD sursele de date sunt BD operaionale, iar accesul este cel mai adesea de tip citire pentru interogri complexe. O baz de date este proiectat pornind de la sarcini i activiti cunoscute: indexarea, utilizarea cheilor, cutarea unor nregistrri specifice, optimizarea interogrilor. Interogrile unui depozit de date sunt adesea complexe, implicnd calcule asupra unor grupuri mari de date cu totalizri pe diferite niveluri, ceea ce presupune activiti speciale: de organizare a datelor, de acces. O baz de date presupune procesarea concurent a tranzaciilor multiple. Controlul concurenei pentru DD este mult mai simplu deoarece se aplic doar pentru citire.

Comparaie ntre BD i DD Criteriu Procesele Execuie Utilizatori Operaii Caracterul datelor Nivelul de sintez Acces Focalizare Sursa de date este Volum de date Prioriti Software necesar BD operaionale tranzacii toate categoriile zilnice curente primitive, detaliere citire, scriere culegere date validat ordinul GB performane, disponibilitate SGBD DD informaionale analize manageri, analiti de date asistarea deciziei istorice sintetizare, consolidare citire furnizare informaii filtrat, transformat ordinul TB flexibilitate, autonomie specializat, SGBD

1.5. Arhitectura 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 de analiz. Esena unui depozit de date const ntr-o baz de date de dimensiuni foarte mari coninnd informaiile pe care le pot folosi utilizatorii (clieni, furnizori, companii de publicitate etc.). Depozitul de date conine mai multe tipuri de date care corespund diferitelor cerine informaionale ale utilizatorilor: date detaliate, date agregate, metadate (dicionarul de date). Metadatele descriu datele coninute n depozitul de date i modul n care ele sunt obinute i stocate. Prin metadate se precizeaz structura datelor, proveniena lor, regulile de transformare, de agregate i de calcul. Ele sunt utilizate oro de cte ori se utilizeaz DD: la ncrcarea datelor, la consultare, la actualizare, adic pe parcursul ntregului ciclu de via al depozitului. Datele agregate, dei determin o cretere a redundanei datelor, sunt necesare n DD deoarece n acest fel se poate asigura un timp mediu de rspuns ct mai redus. Aceste date presupun un grad de prelucrare prealabil, astfel nct s fie pregtite pentru nevoile managementului: consolidare, totalizare, nsumare, mpachetare (n formate accesibile interfeelor de analiz utilizate). interfee de analiz

sursa de date

depozit de date

Date externe

Date interne

Date arhivate

t r a n s f o r m a r e

Data Mart Metadatele Data Mining Datele aggregate OLAP Datele detaliate

Datele detaliate sunt cele relativ recente, livrate utilizatorilor, de regul la nivel de execuie. Tot aici se gsesc date avnd o anumit vechime (civa ani), n form detaliat.

Not. Aceast structur a datelor n DD este dinamic, datele intr n depozitul de date, circul pe diverse nivele, i schimb forma i pozitia, i schimb destinaia. Sursele de date pentru DD sunt: datele operaionale curente (BD i/sau fiiere din sistemul informatic al organizaiei), datele vechi arhivate, datele externe (BD i fiiere din sistemele informatice ale altor organizaii). Construirea depozitului de date, pornind de la sursele de date, presupune parcurgerea unor etape n cadrul unui proces de extragere transformare ncrcare (ETL Extract Transformation Load): - extragerea datelor din datele operaionale sau din surse externe, urmat de copierea lor n depozitul de date. Acest proces trebuie, cel mai adesea, s transforme datele n structura i formatul intern al depozitului; - filtrarea datelor, pentru a exista certitudinea c datele sunt corecte i pot fi utilizate pentru luarea deciziilor; - ncrcarea datelor corecte n depozitul de date; - agregarea datelor: totaluri precalculate, subtotaluri, valori medii, sume etc., care se preconizeaz c vor fi cerute i folosite de utilizatori. Aceste agregri sunt stocate n depozitul de date mpreun cu datele importate din sursele interne i externe. Not. n infrastructura Oracle funcia ETL pentru un depozit de date este ndeplinit de produsul Oracle Data Integrator ODI. Interfeele de analiz sunt produse software care implementeaz tehnologii informatice pentru extragerea i analiza datelor din DD: concentrri de date (Data Mart), extrageri i analize de date (Data Mining) analiza multidimensional a datelor (OLAP). Arhitectura depozitelor de date pe trei straturi Evideniaz modul de implementare a DD ntr-un mediu de reea de calculatoare, pe trei straturi: stratul inferior, stratul mediu, stratul superior. Stratul inferior (bottom tier) este format din serverul depozitului de date i este, n cele mai multe cazuri, un sistem de baze de date relaionale. Datele care provin din bazele de date operaionale i din sursele externe (de exemplu date referitoare la profilul clientului, date furnizate de consultani externi, rezultatele unor sondaje) sunt extrase utiliznd programe de tip interfa (gateways), care colaboreaz cu SGBD de baz i permite programelor client s genereze cod (de obicei SQL) pentru a fi executat de server. 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 interfee specializate de tip ETL - Extract Transformation Load (de exemplu produsul Oracle Data Integrator ODI). mprosptarea datelor din DD se face pe msura trecerii timpului (lunar, trimestrial, anual). Stratul mediu (middle tier) este bazat pe un server specializat, care poate fi: OLAP (bazat pe modelul relaional ROLAP sau pe modelul multidimensional - MOLAP), Data Mining (analize statistice superioare), Data Mart (concentrri de date). De multe ori acest strat este inclus n SGBDR (exemplu Oracle, DB2). Stratul superior (top tier) este nivelul client care conine interfee pentru generarea interogrilor, a rapoartelor, pentru superioar a datelor. Strat superior Rapoarte, interogri

extragere Strat mediu Servere specializate

Depozite de date transformare Strat inferior Server de Date

1.6. Tipuri de 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 (Virtual Datawarehouse). Depozitul de ntreprindere colecteaz toate informaiile despre subiectele care privesc ntreaga organizaie. El furnizeaz un volum foarte mare de date. De regul conine date detaliate, dar i date agregate, iar ca ordin de mrime, terabytes. Un depozit de date de ntreprindere poate fi implementat pe calculatoare mari (mainframes), pe superservere UNIX, pe platforme cu arhitecturi paralele. Acestea necesit cheltuieli mari i mult timp (ani) pentru modelare proiectare i realizare. Concentrrile de date conin un subset al volumului de date din organizaie, specific unui grup de utilizatori (unui compartiment). Domeniul este limitat la subiecte specifice. De exemplu, pentru activitatea de marketing se limiteaz subiectele la clieni, produse, vnzri. Datele coninute sunt de obicei agregate. Concentrrile de date sunt implementate pe servere departamentale (UNIX sau Windows). Ciclul de implementare al unei Concentrri de date este msurat n sptmni sau luni sau ani. Ca atare, un data mart poate fi considerat un subansamblu al unui depozit de date mai uor de construit i ntreinut i mai puin scump. Depozitul virtual este un set de viziuni (views) asupra bazelor de date operaionale. Pentru eficiena procesrilor interogrilor, numai unele din viziunile de agregare pot fi materializate. Un depozit virtual este uor de construit, dar necesit capaciti suplimentare pe serverele de baze de date. Dup modelul de date implementat sunt urmtoarele tipuri de DD: DD relaionale, DD multidimensionale.

Capitolul 2

Realizarea DD

2.1. 2.2. 2.3. 2.4.

Metodologia de realizare a DD Modelarea Implementarea Exploatarea

Realizarea unui depozit de date presupune aplicarea unei scheme de analiz economic pentru a determina msura n care depozitul de date este necesar i eficient: - trebuie s furnizeze avantaje competitive prezentnd informaii relevante pe baza crora putem msura performanele i putem face ajustri critice pentru a ctiga n faa competitorilor; - poate determina creterea productivitii deoarece permite obinerea rapid i eficient de informaii care descriu cu acuratee organizaia; - faciliteaz gestiunea relaiilor cu clienii, deoarece acesta furnizeaz o viziune consistent despre clienii i produsele comercializate de organizaie, pe toate departamentele; - determin reducerea costurilor prin reliefarea tendinelor , direciilor i excepiilor pe perioade lungi de timp. Realizarea unui depozit de date poate lua n considerare viziuni diferite: o viziunea de sus n jos (top-down) permite selectarea informaiilor relevante necesare n depozitul de date, informaii care reprezint un sprijin decizional n activitatea curent. o viziunea datelor surs (data source view) exprim informaiile culese, stocate i gestionate de sistemele operaionale. Aceste informaii pot fi documentate pe niveluri variate de detaliere i acuratee, de la tabele individuale de date surs la tabele de date integrate. o viziunea depozitelor de date (data warehouse) are n vedere tabele de fapte i tabele dimensiune i reprezint informaiile care sunt stocate n depozitele de date, incluznd contorizri i totaluri precalculate, precum i informaii privitoare la surs, dat calendaristic, origine, adugate pentru a furniza contextul istoric. o viziunea de interogare (business query) ofer o perspectiv din punct de vedere al utilizatorului. Un depozit de date poate fi proiectat i construit utiliznd abordarea: - de sus n jos (top-down) care pornete cu proiectarea i planificarea complet. Se utilizeaz n cazul cnd tehnologia este matur i bine cunoscut i problemele economice care trebuie rezolvate sunt clare i bine nelese. Dezvoltarea top-down a unui depozit de date constituie o soluie sistemic i minimalizeaz integrarea problemelor. Soluia este scump, solicit timp ndelungat pentru dezvoltare i i lipsete flexibilitatea determinat de dificultile n realizarea modelelor de date pentru ntreaga organizaie;

de jos n sus (bottom-up) pornete cu experimente i prototipuri. Aceasta este utilizat la nceputul stadiului de modelare i de dezvoltare tehnologic. Ea permite unei organizaii s mearg nainte cu cheltuieli considerabil mai mici i s evalueze beneficiile tehnologiei nainte de a face angajamente semnificative n aceast direcie. Abordarea bottom-up n proiectarea, dezvoltarea i aplicarea concentrrilor de date (data marts) independente furnizeaz flexibilitate, costuri sczute i recuperarea rapid a investiiei. Soluia poate determina probleme, cnd se ncearc integrarea ntr-un depozit de date consistent la nivel de ntreprindere. mixt presupune c o organizaie poate exploata caracterul planificat i strategic al abordrii top-down att timp ct reine avantajele implementrii rapide i oportune a aplicaiilor dup abordarea bottom-up.

Realizarea unui depozit de date presupune urmtorii pai: 1. strategia de realizare; 2. planificarea (modelarea) cerinelor; 3. implementarea; 4. exploatarea. Sistemele software mari pot fi dezvoltate utiliznd dou metodologii: metoda in cascad, metoda n spiral. Metoda n cascad execut o analiz structurat i sistematic la fiecare pas, nainte de a trece la urmtorul. Metoda n spiral implic generarea rapid de sisteme funcionale din n ce mai complete, la intervale scurte, ntre dou versiuni succesive. Acest lucru constituie un atu important pentru dezvoltarea depozitelor de date, n special pentru data marts, pentru c intervalul de realizare este scurt, modificrile pot fi fcute imediat i noile proiecte i tehnologii pot fi adaptate n mod rapid. Not. Cu toate c au existat ncercri de a utiliza metodologiile tradiionale de dezvoltare a software-ului pentru depozitele de date, practicienii depozitelor de date consider c strategia n spiral (iterativ) este mai potrivit dect cea n cascad.

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 de vedere al capacitii de gestionare. Este mult mai realist s se fac o list cu prioritile cerinelor diferiilor utilizatori, iar aceste cerine s fie ataate diferitelor segmente care se vor dezvolta prin strategia iterativ. Natura iterativ a proiectului permite echipei de dezvoltare s extind funcionalitile depozitului de date ntr-o manier uor de controlat; - arhitectura preliminar a depozitului de date. Se definite arhitectura general a depozitului de date pentru proiectul pilot i versiunile care vor urma pentru a asigura scalabilitatea depozitului. Prin analizarea posibilelor arhitecturi de depozite de date, analitii pot s determine o mulime de alte componente tehnologice care sunt necesare pentru fiecare versiune; - lista preliminar a mediilor de dezvoltare a depozitului de date. Exist un numr destul de mare de medii i instrumente pentru DD din care se pot face alegeri i, de aceea, se recomand alctuirea unei liste sintetice cu cele care pot fi de folos n cadrul organizaiei. Un set standard de instrumente va reduce problemele de integrare i va minimiza efortul de nvare att pentru echipa de dezvoltare, ct i pentru utilizatori. Etapele necesare pentru a duce la ndeplinire strategia DD sunt urmtoarele: determinarea contextului organizaional, realizarea unei vederi preliminare de ansamblu asupra cerinelor, realizarea auditului preliminar referitor la sistemele surs, identificarea surselor de date externe, definirea versiunilor depozitului de date, definirea arhitecturii preliminare a depozitului de date, evaluarea mediilor de dezvoltare a depozitului de date. 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. 1. Determinarea contextului organizaional. Inelegerea profund a organizaiei ajut la stabilirea contextului n care se desfoar proiectul i poate evidenia aspectele culturii organizaionale, care pot uura sau ngreuna proiectul depozitului de date. Rspunsurile la ntrebrile legate de organizaie se obin de obicei de la susintorul proiectului, managerul IT sau managerul de proiect. Intrebrile tipice sunt urmtoarele: - cine este finanatorul (susintorul) proiectului n acest caz? Susintorul proiectului stabilete domeniul proiectului DD. Acesta joac un rol foarte important n stabilirea relaiilor de lucru ntre membrii echipei de dezvoltare, mai ales dac sunt implicai i teri. Accesul facil la datele depozitului poate fi limitat de domeniul organizaional, care se afl sub controlul susintorului proiectului; - care sunt grupurile IT din organizaie care sunt implicate n proiectul DD? Deoarece un depozit de date este o dorin a organizaiei, grupurile IT din interior vor fi ntotdeauna implicate n acest efort. Trebuie tiut care sunt relaiile de lucru dintre ele i care este gradul de ocupare. Dac, de exemplu, departamentul IT este foarte preocupat cu 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 stabilesc limite i obiective, iar comunicarea i nelegerea proiectului se mbuntesc.

2. Realizarea unei vederi preliminare de ansamblu asupra cerinelor. In aceast etap se obine un inventar al cerinelor utilizatorilor prin interviuri, individuale sau de grup, realizate n comunitatea utilizatorilor finali. Dac este posibil, se recomand obinerea de formate referitoare la rapoartele curente folosite de conducere. Inventarul cerinelor furnizeaz aria de ntindere a informaiilor despre care se ateapt s le ofere un viitor depozit de date. Obiectivul principal este acela de a nelege nevoile utilizatorilor, destul de mult, ca s poat fi ierarhizate. Aceasta este o informaie critic ce determin aria fiecrui segment DD. Exemple de ntrebri care pot constitui repere ntr-o discuie cu potenialii utilizatori ai depozitului de date: Funciile. Care este misiunea grupului sau a departamentului? Cum procedai ca s v ndeplinii misiunea? Cum tii dac ai atins obiectivele fixate? Care sunt indicatorii de performan pe care i folosii i care sunt factorii critici de succes? Clienii. Cum v grupai sau v clasificai clienii? Se modific aceast grupare de-a lungul timpului? Modul de grupare afecteaz modul n care v tratai clenii? Ce fel de informaii pstrai despre fiecare tip de client? Ce informaii demografice folosii? Avei nevoie s pstrai date despre fiecare client n parte? Profitul. La ce nivel msurai profitabilitatea n grupul sau departamentul dvs.? Pe agent? Pe client? Pe produs? Pe regiune? La ce nivel de detaliere sunt nregistrate costurile i veniturile? Ce fel de rapoarte privind profitabilitatea folosii actualmente? Sistemele. Ce sisteme folosii ca parte a muncii dvs.? Ce fel de transformri manuale de date trebuie s facei atunci cnd datele nu sunt disponibile? Timpul. Pentru cte luni sau ani avei nevoie s fie pstrate datele? Analizai performanele pe durata unui an? La ce nivel de detaliere avei nevoie s fie prezentate graficele? Zilnic? Sptmnal? Lunar? Trimestrial? Anual? Ct de repede avei nevoie de date? Interogrile i rapoartele. Ce rapoarte folosii acum? Ce informaii folosii de fapt din fiecare raport pe care l primii? Putem obine machete ale acestor rapoarte? Ct de des se produc aceste rapoarte? Le primii destul de frecvent sau timpul de ateptare este prea mare? Cine produce rapoartele pe care le primii? Cine sunt cei pentru care alctuii dvs. rapoartele? Produsele. Ce produse vindei i cum le clasificai? Avei o ierarhie a produselor? Analizai datele pentru toate produsele n acelai timp sau analizai datele despre fiecare produs n parte? Cum gestionai modificrile care intervin n ierarhia produselor? Geografia. Organizaia opereaz n mai mult de o singur zon? V mprii piaa n zone geografice? Pstrai datele despre vnzri pe fiecare regiune n parte? La realizarea interviurilor pentru dezvoltarea depozitelor de date, este indicat s lum n considerare urmtoarele recomandri: - Trebuie evitat s facem delimitri clare privind aria depozitului de date. Nu trebuie s fim surprini dac o s constatm c o parte dintre interogrile i rapoartele de care au nevoie utilizatorii nu pot fi realizate pe baza datelor existente n sistemele operaionale. - Trebuie pstrat clar obiectivul interviului i nu trebuie s ne abatem de la el. Obiectivul principal este acela de a realiza un inventar al cerinelor, nefiind nevoie o nelegere foarte detaliat a acestora. - Echipa care realizeaz interviurile trebuie s fie mic; echipa ideal este format din doi oameni 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, iar ascultarea ulterioar a discuiei poate fi de mare ajutor.

Stilul de interviu va depinde de persoana intervievat. Managerii de nivel mediu sunt cei care lucreaz cel mai mult cu rapoarte analitice, n timp ce managerii de nivel nalt au cerine legate de informaii cu caracter strategic. In funcie de intervievat se vor alege i ntrebrile la care se solicit rspuns. Trebuie obinut copii ale rapoartelor, ori de cte ori este posibil. Rapoartele vor furniza echipei de dezvoltare informaii importante, referitoare la sistemele surs i la regulile i termenii afacerii.

3. Realizarea auditului preliminar referitor la sistemele surs. Este recomandabil ca echipa de dezvoltare s obin un inventar al sistemelor surs poteniale pentru depozitul de date. In timp ce managerul IT va furniza imaginea de ansamblu a sistemelor existente n organizaie, cei mai n msur s ofere detalii pentru auditarea sistemelor surs sunt administratorii de baze de date i administratorii de sistem care ntrein sistemele operaionale. Exemple de ntrebri 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 furnizeaz informaii 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 un terminal 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 i integrare estimai c vor fi necesare? Ce zone, tabele sau cmpuri, din sistemele actuale sunt cunoscute pentru slaba calitate a datelor? Documentaia. Ct documentaie este disponibil pentru sistemele surs? Ct de corecte i de actuale sunt aceste manuale i referine? Este bine de obinut urmtoarele informaii ori de cte ori este posibil: copii ale manualelor i instruciunilor de utilizare, structura bazelor de date, pri de programe surs, scheme de generare a codului surs. Mecanisme de extragere posibile. Ce mecanisme de extragere sunt posibile pentru sistemul curent? Ce mecanisme au fost folosite nainte i care credei c vor fi mecanismele de extragere a datelor care nu vor funciona cu sistemul actual? 4. Identificarea surselor de date externe. Organizaia poate folosi surse de date externe pentru completarea datelor din sistemele surs interne. Astfel de surse de date externe pot fi: date de la bnci, 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 prezint dificulti din cauza granularitii diferite i, de aceea, decizia n legtur cu folosirea datelor externe trebuie s fie bine fundamentat. 5. Definirea versiunilor depozitului de date. Specialitii recomand mprirea dezvoltrii depozitului de date n mai multe versiuni derulate n spiral. Disponibilitatea i calitatea datelor surs vor juca un rol critic n finalizarea cu succes a acestei faze. Abordarea iterativ permite gestionarea eficient a cerinelor utilizatorilor i reduce efectele riscurilor care pot aprea. Fiecrei cerine i se atribuie un nivel de prioritate. Se face o evaluare iniial a complexitii n funcie de numrul sistemelor surs. De asemenea, este identificat i sistemul int. Pot fi luai n calcul mai muli factori pentru o mai bun nelegere

a cerinelor fiecrui modul. Definirea fiecrui modul este finalizat doar atunci cnd este aprobat de ctre susintorul proiectului. 6. Definirea arhitecturii preliminare a depozitului de date. Trebuie s se schieze o arhitectur preliminar pentru fiecare modul n funcie de aria de ntindere aprobat. Este recomandabil s se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaionale i multidimensionale, precum i instrumente adecvate. 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 s asigure faptul c anumite concentrri de date nu sunt implementate izolat. Numrul de utilizatori. Se specific numrul de utilizatori pentru fiecare instrument de acces la fiecare versiune n parte. Localizarea. Se precizeaz locul de dispunere a depozitului de date, a concentrrilor de date i a utilizatorilor pentru fiecare modul. Aceste aspecte au implicaii asupra cerinelor arhitecturii tehnice a proiectului depozitului de date. 7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizaia poate alege ntre Versiunea mai multe medii i interfee pentru a dezvolta depozitul de date. Important este s se selecteze nr. 1 ROLAP Report combinaia de interfee care satisfac cel mai bine cerinele organizaiei. In prezent nu exist un Front-End Writer productor care s ofere o suit integrat pentru depozite de date, ns exist lideri pentru (10 fiecare categorie n parte. Se vor elimina variantele neconvenabile i se(5 va alctui o list din utilizatori) utilizatori) care fiecare versiune va avea parte de un set de interfee (acces la date, SGBD etc.). Data Warehous e Versiunea nr. 2 ROLAP Front-End (15 utilizatori) Data Warehous e

Alert System (10 utilizatori)

EIS/DSS (3 utilizatori)

Data Mar t

Report Server (10 utilizatori)

Fig. 20. Exemple de arhitecturi preliminare pe versiuni

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

ateptrile conducerii organizaiei vor fi atinse. De asemenea, vor fi documentate toate limitrile impuse de sistemele surs, iar aceste informaii vor fi oferite auditorilor pentru a fi confirmate. Limitrile impuse de sistemele surs determin n mare msur modul n care va arta depozitul de date n final. Aria de ntindere a versiunii determin direct timpul de implementare. O arie prea mare va face ca proiectul s nu poat fi gestionat eficient. Ca regul general, aria trebuie limitat astfel nct versiunea s poat fi implementat ntr-o perioad de la trei pn la ase luni, de o echip de 6-12 membrii. 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 un grup de utilizatori preiau iniiativa depozitului de date, dup ce n prealabil iau sintetizat cerinele informaionale. In acest caz, un numr de operaiuni din etapa de formulare a strategiei vor fi etape din planificarea primei versiuni a depozitului de date: determinarea contextului organizaional, definirea modulelor depozitului de date, definirea arhitecturii depozitului de date, evaluarea instrumentelor i a mediilor de dezvoltare. 3. Auditarea sistemelor surs. Auditarea sistemelor surs trebuie s ofere o vedere de ansamblu asupra sistemelor care pot fi surse poteniale de date pentru depozit. Auditarea preliminar a sistemelor surs din cadrul formulrii strategiei DD trebuie s ofere o list complet a surselor de date. Sistemele surs de date sunt n primul rnd cele interne. Cele mai bune candidate pentru a fi sisteme surs sunt sistemele operaionale care automatizeaz tranzaciile zilnice ale ntreprinderii. Pe lng sistemele operaionale, mai sunt folosite ca surs de date i rapoartele financiare ale ntreprinderii, mai ales dac interogrile i rapoartele se focalizeaz pe msurarea profitabilitii. In cazul n care sunt disponibile i surse de date externe, ele vor putea fi integrate n depozitul de date. Persoanele cele mai potrivite n cazul auditrii sistemelor surs sunt administratorii de baze de date, administratorii de sistem i ali specialiti IT, care gestioneaz sisteme interne ce pot deveni surse pentru depozitul de date. Avnd n vedere cunotiinele pe care le au asupra sistemelor existente, ei sunt cei mai n msur s aprecieze oportunitatea folosirii fiecrui sistem ca surs de date pentru depozit. Aceste persoane sunt de asemenea familiarizate cu problemele legate de calitatea datelor din diverse sisteme surs. Informaiile oferite de acetia vor fi documentate pentru a sprijinii procesul de extragere i filtrare a datelor. Administratorii de baze de date i ceilali specialitii IT pot oferi informaii valoroase cu privire la regulile dup care se obin rapoartele existente pe baza datelor primare. Pentru auditarea sistemelor surs trebuie realizate interviuri, individuale sau de grup, cu specialitii IT din organizaie i se va urmri obinerea urmtoarelor documente i informaii, dac nu au fost deja colectate n etapa de stabilire a strategiei DD: - documentaia arhitecturii IT a organizaiei (toat documentaia care ofer o vedere de ansamblu asupra arhitecturii IT): diagramele arhitecturii sistemului (un model al tuturor sistemelor informaionale existente n ntreprindere i al legturilor dintre ele), modelul datelor ntreprinderii (un model al tuturor datelor care sunt stocate n prezent), arhitectura reelei (o diagram care descrie amplasarea i configurarea reelei);

- manualul tehnic i manualul de utilizare pentru fiecare sistem surs: modelele datelor i schemele pentru toate subsistemele informatice care candideaz ca sisteme surs; - bazele de date: pentru fiecare sistem surs se va identifica tipul bazei de date folosite i se vor face aprecieri ale mrimii ei; - planurile de perspectiv: ce proiecte de dezvoltare i implementare au fost aprobate pentru urmtoarele 6-12 luni pentru fiecare sistem surs n parte; dac schimbarea structurii datelor va afecta preluarea datelor din sistemele surs n depozit, va aduce eventual noi date disponibile sau vor fi pierdute o parte dintre cele existente; - sistemele de codificare: fiecare sistem surs folosete un anumit sistem de codificare i de aceea administratorii bazelor de date trebuie s ofere informaii referitoare la modul n care sunt generate codurile, la modul de reutilizare a codurilor, la posibilitatea unificrii lor; - mecanismele de extragere: trebuie verificat dac datele pot fi citite sau extrase direct din bazele de date operaionale. Pachetele de aplicaii existente i sisteme de gestiune a bazelor de date pot prezenta probleme, mai ales n cazul n care structura nu este documentat.

4. Proiectarea schemelor depozitului de date. Proiectarea schemelor depozitului de date trebuie s asigure acoperirea cerinelor informainale ale utilizatorilor versiunii respective. Sunt disponibile scheme rezultate din dou tipuri de modele: relaional (bazat pe normalizare), multidimensional (bazat pe denormalizare). n modelarea bazat pe normalizare schema bazei de date este proiectat folosind tehnicile de normalizare utilizate n sistemele relaionale (tranzacionale OLTP). n modelarea multidimensional se lucreaz cu schemele: stea, fulg de zpad, constelaie, care sunt denormalizate i conin tabele de fapte i tabele dimensiune (tehnologia OLAP). 5. Transformarea cmpurilor surs n cmpurile destinaie. La trecerea cmpurilor surs n cmpurile destinaie trebuie s se stabileasc modul n care cmpurile din sistemele surs operaionale sunt transformate n cmpuri ale depozitului de date. Un cmp din depozitul cu date poate fi populat cu date din mai multe sisteme surs. Aceasta este o consecin natural a rolului integrator pe care l are depozitul de date. Exemplu, fiecare sistem operaional va avea propriile nregistrri referitoare la clieni i produse. Un cmp din depozitul de date care va fi denumit Nume_client sau Denumire_produs va fi populat cu date din mai multe sisteme. Este posibil i situaia invers, un cmp din sistemele operaionale poate fi divizat n mai multe cmpuri n depozitul de date. Exemplu, exist sisteme operaionale care nregistreaz adresele ca linii de text cu numele cmpului Adresa. Acesta poate fi imprit n mai multe cmpuri cum ar fi: Strada, Ora, Jude. Pentru a elimina orice confuzie, care poate aprea referitor la modul n care datele surs sunt transformate n depozitul de date, se recomand creearea unui tabel surs-destinaie care s evidenieze cum se transform fiecare cmp. De asemenea, trebuie s se precizeze toate regulile care guverneaz integritatea sau divizarea datelor.

6. ncrcarea datelor istorice n depozitul de date. La ncrcarea datelor istorice n depozitul de date trebuie avut n vedere urmtoarele aspecte: - Schimbrile n structura datelor. Se va determina dac schemele tuturor sistemelor surs au suferit modificri in timp. De exemplu, dac perioada pentru care sunt pstrate datele n depozit este de doi ani i datele din ultimii doi ani trebuie ncrcate n depozit, echipa trebuie s verifice dac schema a suferit modificri n aceast perioad. n caz afirmativ, operaiunile de extragere i integrare a datelor devin mult mai complicate. Fiecare sistem surs va necesita, probabil, propriul tabel surs-destinaie. - Disponibilitatea datelor istorice. n mod obligatoriu trebuie s se determine dac datele istorice sunt disponibile pentru ncrcarea lor n depozitul de date. Not. Aspectele de mai sus vor fi mult mai dificil de analizat, dac documentaia necesar lipsete sau dac nici un specialist IT din ntreprindere nu este familiarizat cu vechile scheme de date.

7. Selectarea mediilor de dezvoltare. n aceast etap se finalizeaz alegerea produselor software necesare pentru realizarea DD. Dac a fost efectuat un studiu amnunit al acestui aspect n etapa de definire a strategiei, activitatea de selectare devine opional. Dac strategia DD nu a fost formulat atunci trebuie s se fac evaluarea n acest moment. Este indicat s se fac selecia ct mai repede pentru ca livrarea s nu perturbe procesul de dezvoltare, mai ales n cazul importurilor. 8. Crearea prototipului pentru versiunea curent Prin folosirea listei finale a mediilor de dezvoltare se va creea prototipul depozitului de date. Realizarea i prezentarea unui prototip de depozit de date este motivat de unul sau mai multe dintre aspectele urmtoare: - Selectarea interfeelor software. Este posibil s cerem furnizorilor de tehnologii s prezinte un prototip de depozit de date pentru a-l evalua. Rezultatul evalurii ne va folosi n selectarea interfeelor: produse OLAP, generatoare etc. - Corectitudinea schemei de date. Echipa creaz un prototip bazat pe o anumit schem i apoi se pot lansa interogri sau realiza rapoarte de prob pe baza datelor reale din sistemele surs. Dac cerinele utilizatorilor, n termeni de interogri, pot fi ndeplinite folosind schema proiectat, atunci echipa poate valida aceast schem. - Validarea prototipului. Echipa de dezvoltatori va invita reprezentanii utilizatorilor s foloseasc efectiv prototipul pentru a-i formula o prere iniial. Prototipul este primul rezultat concret al efortului de dezvoltare. El ofer utilizatorilor ceva tangibil, pe care l pot vedea i folosi. El permite, de asemenea, utilizatorilor s experimenteze pentru prima dat noua tehnologie. De regul, o astfel de experien declanaz o multitudine de reacii pozitive i negative din partea utilizatorilor. Aceste reacii pot ghida echipa de dezvoltare privind coreciilor care trebuie fcute. La validarea prototipului, urmtoarele aspecte trebuie s devin clare pentru utilizatori: obiectivele ntlnirilor, natura i sursa datelor folosite la validare, aria de cuprindere a prototipului.

2.3. Implementarea depozitelor de date

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

Definirea ariei de cuprindere n absena unui depozit de date multe dintre cerinele decizionale sunt clasificate n categoria rapoartelor ad-hoc i, ca urmare, cele mai multe dintre programele de extragere i procesare nu sunt suficient documentate i sunt cunoscute doar de cei care le-au conceput. Astfel, se ajunge n situaia n care, n aceeai organizaie, nu exist standarde n acest domeniu (de exemplu, persoane diferite aplic formule i reguli diferite pentru aceleai date). Echipa de dezvoltare a depozitului de date trebuie s urmreasc n primul rnd introducerea standardelor locale sau internaionale pentru manipularea datelor. n acest sens vor fi vizate urmtoarele aspecte: o Date actuale folosite pentru obinerea rapoartelor. Aceste date tebuie s fie incluse n procesul de auditare al sistemelor surs. Avantajul este c echipa de dezvoltare va ti din start care cmpuri din aceste sisteme sunt cele mai importante. o Programele actuale de extragere. Programele de extragere sunt un indiciu valoros pentru realizarea tabelelor surs-destinaie. De asemenea, ele ofer informaii valoroase referitoare la formulele i regulile de transformare a datelor. o Transformarea manual a datelor. n cazul n care exist astfel de situaii, ele trebuie analizate cu grij pentru a se obine informaiile necesare i pentru a se elimina o parte dintre transformrile manuale. Este posibil ca echipa care planific depozitul de date s descopere o serie de deficene legate de rapoartele care se produc n organizaie. Nu este nimic neobinuit s fie descoperite inconsistene referitoare la folosirea unor termeni, formule de calcul sau reguli, n funcie de persoana care creez sau citete raportul. Fiecare secvent de date, care este necesar pentru crearea rapoartelor solicitate de manageri, provine din unul sau mai multe sisteme surs disponibile n ntreprindere, ns exist date care nu se regsesc n sistemele surs. Limitrile impuse de datele disponibile sunt de urmtoarele tipuri: - Secvene de date care lipsesc. O secven de date este considerat lips dac nu exist nici un sistem surs care s fie prevzut pentru a o colecta i stoca. Cele mai frecvente cazuri sunt cele ale datelor care nu sunt stocate, deoarece nu au nici o importan pentru derularea zilnic a tranzaciilor, ns au o mare importan pentru deciziile tactice i strategice. De exemplu, dac sistemele de acordare a mprumuturilor bancare nu nregistreaz domeniul de activitate n care activeaz fiecare beneficiar de creadite atunci banca va avea probleme serioase cnd va dori s-i analizeze gradul de expunere la risc n funcie de sectorul economic finanat, deoarece nu va putea genera un raport detaliat pe aceast tem. - Secvene de date incomplete sau opionale. Exist cazuri cnd o secven de date este clasificat cu termenul de reinut, ns nu exist reguli care s precizeze clar c acea secvent trebuie s fie colectat i stocat sau nu. Aa se ajunge n situaia c astfel de secvene de date sunt nregistrate doar pentru o parte din clieni, produse, perioade de timp. Atunci cnd se dorete realizarea unei analize globale, acest lucru nu este posibil, din cauza faptului c datele nu sunt disponibile pentru toate reperele avute n vedere.

Exemplu, sistemul de acordare al mprumuturilor poate avea un cmp numit stare_client, dar dezvoltatorii aplicaiei l-au prevzut ca fiind un cmp opional. Astfel, doar o parte a raportului anterior poate fi realizat i anume doar pentru clienii pentru care s-au nregistrat valorile pentru acel cmp. - Date eronate. Pot aprea date eronate cnd acestea sunt stocate n unul sau mai multe surse de date, din una dintre urmtoarele cauze posibile: erori la introducerea datelor, datele nu sunt disponibile, 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 de limitrile impuse de datele din sistemele surs curente. Cele mai multe proiecte DD se limiteaz doar 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 s documenteze 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 ale funcionalitilor i ale datelor fiecrui sistem operaional, precum i o list cu entitile cele mai importante, precum i a cmpurilor eseniale. De asemenea, se pot meniona i utilizatorii actuali ai sistemelor analizate. o Secvene de date care lipsesc. n aceast seciune sunt evideniate datele care ar fi necesare n cadrul depozitului de date, dar nu sunt disponibile n sistemele surs. Trebuie oferite explicaii n legtur cu importana datelor care lipsesc i modul cum pot fi ele obinute. o Ameliorarea calitii datelor. Pentru fiecare sistem operaional, trebuie evideniate toate zonele n care poate fi mbuntit calitatea datelor i cum anume. o Estimarea resurselor i a efortului. Pentru fiecare sistem operaional, se poate preciza un cost estimativ i durata de timp necesar pentru a aduga datele lips sau pentru a mbunti calitatea. Concluzie. Planificarea depozitului de date are ca scop definirea clar a ariei de cuprindere a fiecrui modul din depozit. Combinaia dintre abordrile top-down i bottom-up ofer procesului de planificare avantajul de a vedea problema din dou perspective complementare: cerinele utilizatorilor i datele disponibile n sistem. Crearea planului de implementare pentru versiunea curent Dup definirea ariei de cuprindere i specificarea modului de transformare a datelor surs, este posibil s se schieze un plan de implementare pentru versiunea curent. Atunci cnd se creaz planul de implementare trebuie s avem n vedere urmtorii factori: - Numrul sistemelor surs i mecanismele specifice de extragere a datelor. Cu ct sunt mai multe sisteme surs, cu att procesele de extragere i integrare sunt mai comlexe. - Numrul de procese decizionale asistate. Cu ct sunt asistate mai multe procese decizionale, cu att va fi mai mare numrul utilizatorilor care vor avea o prere n privina depozitului de date referitoare la definiii de termeni, reguli care trebuie respectate etc. - Numrul de subiecte reinute n depozitul de date. Unul dintre atuurile tehnologiei depozitelor de date este c se orienteaz pe subiecte. Cu ct va fi mai mare numrul

subiectelor avute n vedere, cu att va crete complexitatea versiunii, datorit numrului sporit de tabele de fapte. - Dimensiunea estimat a volumului de date. Aceast mrime furnizeaz o estimare preliminar a efortului de ncrcare, indexare i modificare a depozitului de date. Volumul de date permite echipei de dezvoltare s aprecieze durata de ncrcare a depozitului (numrul de nregistrri ponderat cu durata necesar pentru ncrcarea unei nregistrri). - Disponibilitatea i calitatea documentaiei sistemelor surs. n cazul n care aceste documentaii exist i sunt actualizate, munca echipei de dezvoltare va fi mult uurat. - Rata de ncrcare a depozitului de date. Aceast valoare este impus de cerinele utilizatorilor (ct de proaspete trebuie s fie datele) i este determinant pentru proiectarea i implemenatrea depozitului. - Disponibilitatea solicitat de utilizatori. Un depozit de date care s fie disponibil pentru utilizatori 24 de ore, timp de apte zile pe sptmn, necesit o arhitectur care este complet diferit de unul care trebuie s fie disponibil doar 12 ore, timp de patru zile pe sptmn. - Participarea i sprijinul compartimentului IT. Dac se poate conta pe sprijinul real al compartimentului IT i al altor persoane implicate, atunci planul implementrii va estima o durat mai mic de realizare. Implemenatrea propriu-zis a depozitului de date Procesul de implementare a depozitului de date const de fapt din activiti legate de implementarea fiecrei versiuni. Activitile sunt organizate pe baza rezultatealor etapei de planificare a depozitului de date. Echipa de implementare construiete sau extinde o schem existent a depozitului de date bazat pe proiectul schemei produse n timpul planificrii. Echipa construiete de asemenea subsistemele DD care asigur un flux constant de date valide din sistemele operaionale n depozitul de date. Ali membrii ai echipei sunt responsabili cu instalarea i configurarea interfeelor pentru a permite utilizatorilor accesul la depozitul de date. Un proiect de implementare trebuie s dureze ntre trei i ase luni. Progresul lucrrilor efectuate variaz n funcie de calitatea proiectrii depozitului de date, calitatea planului de implementare, de disponibilitatea i interesul personalului ntreprinderii. Instruirea utilizatorilor i testarea depozitului de date sunt activiti care au loc spre finalul proiectului de implementare, nainte de instalarea definitiv. Odat instalat depozitul de date, ncep activitile de gestionare, ntreinere zilnic i optimizare. Procesul de implementare propriu-zis a depozitului de date presupune realizarea urmtoarelor activiti: achiziia i configurarea mediului de dezvoltare, obinerea copiilor coleciilor de date operaionale, finalizarea proiectrii schemei fizice a depozitului de date, construirea sau configurarea subsistemelor de extragere i transformare, construirea sau configurarea subsistemului pentru calitatea datelor, construirea subsistemului pentru ncrcarea depozitului de date. 1. Achiziia i configurarea mediului de dezvoltare Prima activitate din procesul de implementare o reprezint achiziia i configurarea mediului de dezvoltare, care cuprinde urmtoarele aspecte: instalarea componentelor hardware, instalarea sistemului de operare, instalarea i configurarea motorului pentru baze de date

relaionale, instalarea produselor de DD, crearea conexiunilor n reea i stabilirea drepturilor utilizatorilor. De obicei, depozitul de date se afl pe o main care este separat fizic de restul sistemelor operaionale. n cazul n care depozitul de date este gestionat n manier relaional, sistemul relaional care face acest lucru nu trebuie neaprat s fie acelai cu cel existent n sistemele operaionale. La sfritul acestei etape trebuie ca echipa de dezvoltare s aib la dispoziie infrastructura necesar pentru a realiza efectiv implementarea. 2. Obinerea copiilor coleciilor de date operaionale Uneori echipa de implementare nu are acces direct la sistemele surs operaionale. Acest lucru este posibil mai ales n cadrul proiectelor pilot, unde conexiunea sistemelor operaionale cu depozitul de date nu a fost nc realizat. De aceea echipa trebuie s intre n posesia copiilor coleciilor de date operaionale pe care le va stoca pe serverul DD. Crearea acestor copii poate fi, de asemenea, automatizat prin folosirea tehnicii de replicare din tehnologia SBD distribuite. Echipa de implementare trebuie s dispun de un mecanism de verificare a corectitudinii i completitudinii datelor care sunt ncrcate pe serverul DD. O modalitate este aceea de a folosi numrarea cazurilor (numrul de clieni, numrul de conturi, numrul de tranzacii etc) care sunt comparate cu tabelele iniiale. Utilitarele pentru verificarea calitii datelor pot sprijini echipa de dezvoltarea n demersul implementrii depozitului de date. 3. Finalizarea proiectrii schemei fizice a depozitului de date Detaliile proiectrii logice i fizice ale depozitului de date din faza de planificare se transpun ntr-o versiune final a schemei fizice, avndu-se n vedere aspectele specifice ale sistemului de gestiune a bazelor de date, care a fost desemnat pentru depozitul de date. Aspectele importante sunt urmtoarele: Proiectarea schemei depozitului de date. Se finalizeaz proiectarea fizic a tabelelor de fapte i a tabelelor dimensiune cu cmpurile lor specifice. Administratorul depozitului de date poate opta pentru divizarea unei dimensiuni logice (de exemplu, client) n dou sau mai multe dimensiuni separate (de exemplu, o dimensiune client i o dimensiune demografie) pentru a economisi spaiu de memorare i pentru a crete performana interogrilor. Indexarea. Se identific cea mai potrivit metod de indexare pentru tabelele i cmpurile depozitului de date, n funcie de dimensiunea estimat a volumului de date i de natura anticipat a interogrilor ce se vor efectua asupra depozitului de date. Parionarea. Administratorul depozitului de date poate opta ntre partiionarea tabelelor de fapte i de dimensiuni, n funcie de mrimea lor i de posibilitile de partiionare care sunt suportate de motorul de baze de date. Decizia de partiionare trebuie de asemenea s aib n vedere c un depozit de date partiionat este mai uor de gestionat, ns performana interogrilor scade. 4. Construirea sau configurarea subsistemelor de extragere i transformare Subsistemele de transformare i extragere trebuie s filtreze i s ncarce datele din sistemul operaional n depozitul de date, apoi s le pun la dispoziia utilizatorilor. Aceaste activiti nu pot fi automatizate total, deoarece difer de la o organizaie la alta n funcie de sistemele surs, mediul de dezvoltare i de cerinele utilizatorilor.

Subsistemul de extragere se refer la procesul de obinere a datelor necesare din coleciile de date ale sistemului operaional, care pot fi cele originale sau doar copii ncrcate pe serverul DD. Extragerea se poate realiza printr-o varietate de mecanisme, de la instrumente sofisticate puse la dispoziie de ctre productorii software pn la programe realizate de personalul propriu. Interfeele oferite de diverii productori sunt capabile s documenteze procesul de extragere prin generarea metadatelor specifice. Dezavantajul acestora este determinat de preul prea mare. De aceea, organizaiile prefer deseori s-i dezvolte propriile lor aplicaii de extragre a datelor. Aceast soluie este viabil n msura n care sistemele surs sunt ntr-un mediu omogen. Aplicaiile pentru extragerea datelor dezvoltate n cadrul organizaiei au dezavantajul c sunt greu de ntreinut, deoarece exist tendina ca ele s nu fie documentate la momentul dezvoltrii lor. Subsistemul de transformare modific datele n concordan cu regulile i standardele care au fost stabilite pentru depozitul de date. n tehnologia DD au fost delimitate cteva tipuri de transformri: - Schimbarea formatului. Fiecare dintre cmpurile utilizate n sistemele operaionale pot stoca date n diverse formaturi i tipuri. Aceste secvene individuale de date sunt modificate n impul procesului de transformare pentru a respecta setul standard de formate din depozitul de date. - Redundana datelor. nregistrrile din mai multe surse sunt comparate pentru a identifica nregistrrile duplicat bazate pe valoarea cmpurilor cheie. Duplicatele sunt eliminate pentru a crea o singur nregistrare pentru un client, un produs, un angajat sau o tranzacie. Duplicatele de tip excepie pot fi rezolvate manual prin folosirea unui sistem de avertizare. Tot manual se vor rezolva i nregistrrile duplicat cu valori conflictuale n cazul n care nu exist mecanisme clare pentru stabilirea valorilor corecte. - Partiionarea cmpurilor. Uneori este necesar ca o secven de date din sistemul surs s fie partiionat n unul sau mai multe cmpuri n depozitul de date. Unul dintre cele mai des ntlnite cazuri de acest gen se refer la adresa clienilor care n sistemul surs este memorat ntr-un singur cmp, n timp ce n depozit va fi memorat pe mai multe cmpuri (strad, ora, zon, regiune, ar etc). - Integrarea cmpurilor. Integrarea reprezint operaiunea invers partiionrii: dou sau mai multe cmpuri din sistemul operaional vor fi integrate n vederea populrii depozitului de date. - nlocuirea valorilor. Unele valori care sunt folosite n sistemele operaionale pot s nu fie pe nelesul utilizatorilor depozitului de date. De exemplu, codurile care au un neles specific n sistemul operaional sunt lipsite de relevan pentru manageri. Subsistemul de transformare nlocuiete valorile originale cu valori noi care sunt utile pentru cei ce folosesc coninutul depozitului de date. - Derivarea valorilor. Estimrile, determinarea de indici i alte valori derivate pot fi calculate folosind diverse formule. Prin calcularea i ncrcarea acestor valori n depozit, posibilitatea ca utilizatorii s le calculeze greit este eliminat. - Agregarea valorilor. Agregrile pot fi, de asemenea, precalculate nainte de ncrcarea lor n depozitul de date. Aceasta este o alternativ la ncrcarea doar a valorilor atomice n depozitul de date. 5. Construirea subsistemului pentru calitatea datelor Probleme legate de calitatea datelor nu sunt ntotdeauna vizibile nc de la nceputul proiectului de implementare, deoarece atenia echipei este focalizat pe mutarea unor volume mari de date i mai puin pe analizarea fiecrei secvene de date n parte. n orice caz, pe

msura evoluiei implementrii, calitatea datelor va deveni o problem din ce n ce mai stringent. Una dintre cauzele care determin mpotrivirea utilizatorilor n privina depozitului de date o constituie tocmai slaba calitate a datelor. De asemenea, foarte important este i percepia pe care o au utilizatorii despre date. Acetia vor folosi depozitul de date doar n msura n care au convingerea c datele pe care le gestioneaz sunt corecte. Rezult c subsistemul pentru calitatea datelor reprezint o component critic a arhitecturii depozitului de date. nelegerea cauzelor care determin erori n cadrul datelor face mai uoar munca de depistare i corectare. Deoarece majoritatea erorilor provin din sistemele surs, administratorii bazelor de date i administratorii de sistem vor avea un rol deosebit de important n aceast etap. Erorile au urmtoarele cauze: - Valori lips. Valorile lipsesc din sistemele surs, din cauza nregistrrilor incomplete sau a cmpurilor opionale care nu sunt completate. - Integritatea referenial slab. Uneori, integritatea referenial nu poate fi realizat n sistemele surs, din cauza valorilor inconsistente. - Erori n datele precalculate. O parte din datele din depozitul de date pot fi precalculate nainte de ncrcarea lor, ca parte a procesului de transformare, dac formulele sau calculele sunt greite, atunci depozitul va conine date eronate. - Uniti de msur diferite. Folosirea diferitelor uniti de msur pentru diverse atribute (valoare, cantitate, volum, timp etc.) poate duce la erori n depozitul de date dac nu se efectueaz n prealabil transformri la o msur unitar. - Obinerea duplicatelor. Deduplicarea datelor trebuie s aib loc nainte de ncrcarea lor n depozitul de date. n cazul n care aceast operaiune nu se desfoar corect, exist riscul ca n depozit s apar valori duplicate, generatoare de inconsistene i erori. - Partiionarea cmpurilor. Exist cazuri n care un singur cmp din sistemul operaional trebuie partiionat n mai multe cmpuri n depozitul de date. Din pcate volumul mare de date necesit apelarea la proceduri automate de partiionare a cmpurilor, care pot s nu funcioneze corect n toate cazurile. - Ierarhii multiple. Multe dintre dimensiunile depozitului de date vor avea ierarhii multiple determinate de necesitile de analiz. De exemplu, dimensiunea timp poate avea o ierarhie zilun-trimestru-an, precum i ierarhiile zi-sptmn i zi-lunfiscal-trimestrufiscal-anfiscal. Nenelegerea semnificaiilor acestor ierarhii multiple din diferite dimensiuni poate cauza ncrcri eronate n depozitul de date. - Termeni i reguli conflictuale. Regulile sau termenii conflictuali pot determina planificatorii depozitului de date s ncarce dou secvene diferite de date n acelai cmp al depozitului sau, invers, aceeai secven n dou cmpuri diferite. Calitatea datelor din cadrul organizaiei poate fi ameliorat prin mai multe modaliti: o Evaluarea calitii datelor. Trebuie determinat mai nti calitatea datelor pentru fiecare dintre sistemele surs existente n ntreprindere. o Identificarea datelor importante. Echipa de implemenatre trebuie s determine care sunt datele cele mai importante din perspectiva depozitului de date. n felul acesta se pot stabili anumite prioriti, iar efortul de ameliorare poate fi direcionat n mod eficient ctre zona de cel mai mare interes. o Definirea modului de filtrare i mbuntire a datelor. Pentru fiecare secven de date cu importan mare pentru ntreprindere, trebuie stabilit o tactic specific de ameliorarea a calitii. Atunci cnd este posibil, filtrarea datelor trebuie s se focalizeze n primul rnd asupra sistemelor surs, astfel inct s se elimine posibilitatea propagrii lor n depozitul de date.

o Prevenirea erorilor. Efortul ntreprinderii nu trebuie s se limiteze doar la corecii asupra datelor deja existente, ci doar s aib n vedere prevenirea apariiei erorilor. Dac sistemele operaionale care genereaz date eronate nu sunt revizuite, ele vor continua s fie o surs sigur de erori pentru depozite. Avnd n vedere complexitatea unui astfel de proiect, nu ar fi realist dac am considera c exist un singur instrument care s asigure calitatea datelor. De asemenea, orict de mari ar fi eforturile de ameliorare a calitii, ntreprinderea trebuie s fie oricnd pregtit pentru a aborda noi probleme referitoare la acest aspect. Toate erorile descoperite ar trebui s fie corectate la surs, ceea ce nseamn c sistemele operaionale trebuie s fie modificate astfel nct s conin valorile corecte. Acest practic asigur c att utilizatorii sistemelor operaionale, ct i cei de la nivel decizional vor beneficia de date corecte. Experienta a dovedit ns c procesul de corectare a datelor la surs poate fi uneori dificil de implementat att din cauza responsabilitilor operaionale, ct i din cauza faptului c datele corecte nu sunt cunoscute. Responsabilitatea pentru corectarea datelor din sistelele surs revine personalului operaional care nu prea agreaz ideea de a accepta o responsabilitate suplimentar. Chiar dac se tie despre o anumit secven de date c nu este cea corect, pot exista situaii n care s nu poat fi determinate valorile corecte din cauza imposibilitii obinerii lor. 6. Construirea subsistemului pentru ncrcarea depozitului de date Subsistemul pentru ncrcarea depozitului de date preia schema generat de subsistemul de extragere i transformare i ncarc datele direct n depozit. Dup cum s-a menionat anterior, datele care vor fi ncrcate sunt stocate n colecii de date care au aceeai schem ca i depozitul de date. Subsistemul de ncrcare a datelor n depozitul de date trebuie s fie apt s furnizeze urmtoarele faciliti: - ncrcarea nregistrrilor n tabelele dimensiune. n sistemele surs, fiecare nregistrare referitoare la un client, un produs sau o tranzacie este identificat n mod unic printr-o cheie. De asemenea, aceste entiti trebuie identificate n depozitul de date tot printr-o cheie. Cheile din sistemele surs sunt deseori nepotrivite ca chei pentru depozit, astfel nct apare necesitatea generrii lor n timpul procesului de ncrcare. - ncrcarea nregistrrilor n tabelele de fapte. Cheia primar n tabela de fapte este n realitate o concatenare a cheilor din tabelele dimensiune cu care sunt n legtur. nregistrrile din tabelele dimensiune se ncarc nainte de cele din tabelele de fapte pentru a se putea realiza integritatea referenial. - Calcularea valorilor agregate pe baza nregistrrilor surs. Dup nrcarea valorilor atomice n depozitul de date, subsistemul de ncrcare trebuie s fie capabil s calculeze i s stocheze i valori agregate. - Reindexrile. Dup ce toate datele s-au ncrcat cu succes, indecii din tabelele cele mai importante trebuie refcui pentru a crete performana interogrilor. - Prezentarea unui sistem de control. Acest sistem trebuie s furnizeze echipei de implementare informaii referitoare la modul n care s-a desfurat operaiunea de ncrcare: prezentarea pailor i a erorilor care au aprut n timpul fiecrui pas (de exemplu, erori cu privire la integritatea referenial). Exist discuii dac datele inconsistente trebuie sau nu s fie ncrcate n depozitul de date. Unele echipe de dezvoltare prefer s ncarce doar date corecte n depozitul de date, argumentnd c datele inconsistente sunt generatoare de erori. Alte echipe prefer s ncarce

ambele categorii de date, cu condiia ca datele inconsistente s fie marcate distinct. Dac mai mult de 20% din date sunt incorecte i doar 80% sunt ncrcate n depozitul de date, utilizatorii depozitului de date vor lua decizii bazate pe o imagine incomplet. Probabil c muli ar considera necuprinderea datelor inconsistente ca pe un lucru absolut normal, ns sunt cazuri n care ar fi de preferat ca ele s fie ncrcate n depozit. Decidenii trebuie s aib datele la dispoziie 24 de ore pe zi, ns procesul de ncrcare a depozitului de date blocheaz accesul pe durata desfurrii lui. Cea mai mare provocare n construirea unui sistem de ncrcare o constituie optimizarea operaiunii de ncrcare astfel nct ea s blocheze ct mai puin accesul utilizatorilor la date.

Stabilirea schemei depozitului de date Administratorul DD realizeaz schema acestuia n paralel cu construirea sau configurarea subsistemelor back-end (extragere i transformare, asigurarea calitii datelor, ncrcare). n acest sens, el trebuie s efectueze urmtoarele activiti: - Crearea tabelelor DD. Schema fizic a depozitului de date se implementeaz prin crearea efectiv a tuturor tabelelor de fapte i de dimensiuni, precum i a tabelelor cu valori agregate. - Construirea indecilor. Indecii vor fi construii n tabele n concordan cu schema fizic a depozitului de date. - Popularea DD. Dup definirea schemei tabelelor i precizarea indecilor se trece la ncrcarea datelor. Trebuie avute n vedere i tabelele create pentru a gestiona excepii, de genul celei prezentate n legtur cu restricia referenial.

Metadatele din depozitul de date Metadatele se definesc ca fiind informaii despre date. Aceast definiie nu este perceput corect de obicei de cei ce ncearc s o neleag i de aceea poate ar fi mai potrivit s remarcm c metadatele descriu coninutul depozitului de date, indicnd de unde provin datele originale i documentnd regulile care guverneaz transformarea datelor. Interfeele DD folosesc metadatele i pentru automatizarea unor etape din ciclul de via al dezvoltrii depozitului de date.

Modul de acces la date Stabilirea modului de acces la date reprezint aproximativ 10% din ntregul efort de dezvoltare a depozitului de date i este partea vizibil de care iau contact utilizatorii. De aceea, modul acces este o component critic n vederea acceptrii depozitului de date de ctre utilizatori. Achiziia i instalarea interfeelor de acces. Echipa care are ca responsabilitate implementarea componentei de acces trebuie s instaleze interfeele selectate mai nti pe o main test care are acces la depozitul de date. n acest fel, dezvoltatorii pot descoperi o serie de probleme legate de funcionarea interfeelor. Construirea rapoartelor i a interogrilor predefinite. Prototipul dezvoltat iniial este rafinat n timpul dezvoltrii depozitului de date prin ncorporarea unor elemente furnizate de reacia (feed-back) utilizatorilor i prin construirea unor rapoarte i interogri predefinite de care au

nevoie decidenii. Interfeele au diverse opiuni legate de rapoarte i interogri, astfel nct echipa de dezvoltare trebuie s selecteze varianta optim. Stabilirea profilurilor utilizator. n sistemul de gestiune a depozitului de date, trebuie neaprat definite roluri i profiluri de utilizatori pentru a stabili corect drepturile de acces. Se recomand definirea cel puin a urmtoarelor roluri: - Utilizator depozit de date. Utilizatorul obinuit al depozitului de date are drepturi de vizualizare i interogare asupra tabelelor din depozitul de date. Nu sunt permise actualizri. - Administrator depozit de date. Acest rol este atribuit pentru utilizatorii care trebuie s poat efectua orice fel de operaii pe DD. - Dezvoltator depozit de date. Acest rol se atribuie membrilor din echipa de dezvoltare care sunt responsabili de realizarea componentelor depozitului de date. Un utilizator care are acest rol poate crea noi obiecte n interiorul depozitului. ncrcarea depozitului de date La anumite intervale de timp, datele din DD se mprospteaz prin ncrcare. ncrcarea efectiv a depozitului de date se poate efectua doar dup ce s-au populat tabelele care rezult din procesul de extragere i transformare a datelor, iar schema depozitului i metadatele au fost proiectate n ntregime. Este indicat ca la nceput s se mearg pe varianta ncrcrilor pariale pentru a putea estima timpul total necesar pentru aceast operaiune. Dac utilizatorii au nevoie pentru analize de datele cele mai recente, atunci depozitul de date nu este soluia ideal, ci mai degrab se poate apela la varianta BD. Depozitul de date este disponibil de regul utilizatorilor n orele de serviciu din timpul zilei i din acest motiv el se ncarc deobicei noaptea sau la sfritul sptmnii.

Instruirea utilizatorilor Instruirea pe tema depozitului de date care va fi implementat n curnd n ntreprindere este absolut necesar pentru toi utilizatorii. Aria de cuprindere a instruirii utilizatorilor. Instruirea trebuie s aib n vedere toi utilizatorii care vor intra n contact cu depozitul de date i trebuie acoperite urmtoarele aspecte: o Definirea depozitului de date. Oamenii au ateptri diferite n ceea ce privete depozitul de date. Instruirea trebuie s nceap neaprat cu definirea depozitului. o Aria de cuprindere a depozitului de date. Toi utilizatorii trebuie s cunoasc coninutul depozitului de date. Instruirea trebuie s evidenieze clar ce poate i ce nu poate s fac depozitul de date. o Folosirea interfeelor. Utilizatorii trebuie s invee cum s foloseasc fiecare instrument n parte. o Intervalul de ncrcare. Utilizatorii vor fi informai cu privire la intervalul de ncrcare a datelor i la datele care suntncrcate. o Aflarea rspunsurilor la alte ntrebri. Utilizatorii vor fi informai cum s obin diverse informaii despre folosirea depozitului de date.

Instruirea categoriilor de utilizatori. Instruirea trebuie s cuprind pe acei utilizatori care vor avea contact cu funcionalitile depozitului de date. Trebuie avut ns n vedere c utilizatorii diferii au necesiti diferite. Dac numrul lor este mare, atunci ei pot fi mprii n dou grupuri nceptori i avansai. Avansaii se vor plictisi n cazul n care li se prezint noiuni de baz, n timp ce nceptorii vor fi depii de situaie dac se trece direct la chestiuni de finee. Instruirea este de fapt pasul premergtor al testrii, deoarece utilizatorii nu vor putea testa corect depozitul de date pn cnd nu sunt instruii cu privire la coninutul lui i la regulile care l guverneaz.

Testarea depozitului de date Pentru testarea depozitului de date se va face apel la reprezentanii utilizatorilor avndu-se n obiectiv urmtoarele aspecte: - Interogrile. Utilizatorii vor testa corectitudinea rapoartelor i interogrilor obinute din depozitul de date. De regul, validarea rapoartelor generate din depozitul de date se face construind manual sau prin mecanismele existente acelai raport i comparnd cele dou rezultate. Eventualele discrepane sunt reinute i se vor efectua coreciile care se impun. Echipa nu trebuie s omit i varianta ca eroarea s provin de fapt din sistemul manual de obinere a raportului. - Performana. Ideal ar fi ca fiecare interogare lansat asupra depozitului de date s se execute instantaneu, ns n lumea real valoarea acestui indicator depinde de mrimea depozitului de date, de numrul de utilizatori i de capacitatea reelei. O metod de a ameliora acest indicator este cea a folosirii valorilor agregate precalculate. - Rspuns pe durate specificate. Depozitul de date trebuie s fie capabil s furnizeze rapoarte pe intervalul specificat de utilizatori (zi, sptmn, lun, trimestru,an). Depozitul de date este acceptat doar dup ce testele s-au terminat cu succes i utilizatorii s-au declarat mulumii de el. Pot fi stabilite anumite criterii de acceptare nainte de nceperea implementrii, iar acceptul va fi obinut dac sunt ndeplinite aceste criterii.

2.4. Exploatarea depozitelor de date Activitii de implementare a depozitului de date i urmeaz ntreinerea i dezvoltarea depozitului. Acest lucru implic o serie de activiti specifice, derulate n momente diferite de timp. 1. ncrcarea periodic a depozitului de date Noi date trebuie ncrcate n mod regulat din sistemele surs n depozitul de date pentru ca utilizatorii s poat beneficia de cele mai recente date. Acest lucru este n legtur direct cu structura dimensiunii ierarhiei timp. Operaiunile de ncrcare a datelor se desfoar, de regul, dup ncheierea programului de munc, seara sau noaptea, atunci cnd sistemele operaionale nu sunt folosite. n timpul fiecrei ncrcri a depozitului trebuie parcurse toate etapele procesului final (back-end): extragerea, transformarea, asigurarea calitii i ncrcarea efectiv a datelor. ncrcarea depozitului cu date noi presupune i necesitatea calculrii i populrii tabelelor de agregri cu noi nregistrri. 2. Calcularea indicatorilor statistici referitori la depozitul de date

Evoluia i ntreinerea depozitului de date poate fi urmrit prin intermediul indicatorilor statistici. Valorile acestor indicatori statistici trebuie determinate i analizate pentru a monitoriza performant i gradul de utilizare a depozitului. Indicatorii statistici cel mai des folosii sunt urmtorii: o Numrul de interogri efectuate ntr-o zi. Acest indicator exprim numrul de interogri efectuate asupra datelor din depozit i poate fi calculat pe diferite niveluri de complexitate i detaliere. Numrul de interogri efectuate asupra tabelelor care conin valori agregate indic, de asemenea, utilizarea agregrilor stocate. o Timpul mediu de rspuns la interogri. Acest indicator exprim timpul necesar pentru a obine rezultatul din momentul n care a fost lansat interogarea n execuie. o Numrul de excepii pe zi. Indicatorul caracterizeaz numrul de atenionri i de excepii (erori) generate de depozitul de date, n cazul n care exist ncorporat un sistem pentru aa ceva. o Numrul de utilizatori. Indic numrul total de utilizatori care au acces la datele coninute n depozit. o Numrul zilnic de utilizatori. Indic numrul zilnic de utilizatori care folosesc efectiv avantajele oferite de depozitul de date. o Frecvena utilizrii. Acest indicator este foarte important, deoarece evideniaz numrul de accesri ale depozitului de ctre un utilizator ntr-o anumit perioad de timp, sugernd astfel gradul n care depozitul de date sprijin utilizatorul n activitile de zi cu zi. o Durata medie a sesiunii de lucru. Exprim perioada de timp n care utilizatorul rmne conectat la depozitul de date. o Intervalele de utilizare maxim a depozitului de date. Se are n vedere perioada din zi, ziua din sptmn, sptmna din lun, etc. n care numrul de interogri este mai mare. Astfel se scot n eviden momentele i perioadele de timp n care depozitul este cel mai utilizat. o Subiectele interogate. Acest indicator arat care subiecte din depozitul de date sunt cele mai folosite de ctre utilizatori, putndu-se lua msuri pentru optimizarea acestor zone, precum i subiectele care nu prezint interes i care pot fi eliminate. o Mrimea depozitului de date. Dup fiecare ncrcare a depozitului de date, se determin numrul de nregistrri din fiecare colecie de date pentru a obine rata de cretere a depozitului de date. 3. Meninerea calitii datelor Calitatea datelor este un aspect care trebuie s preocupe organizaia i dup implementarea depozitului de date. Problema principal const n modul n care sunt abordate erorile care apar n legtur cu funcionarea depozitului de date. Dou alternative referitoare la calitatea datelor trebuie luate n considerare: ncrcarea n depozit numai a datelor corecte sau ncrcarea tuturor datelor i efectuarea coreciilor pe parcurs. n prim abordare, doar datele care sunt corecte sunt ncrcate n depozitul de date. n felul acesta utilizatorii sunt siguri c depozitul conine numai date corecte i, ca atare, pot lua decizii bine fundamentate. Deoarece erorile necesit mult timp pentru a fi identificate i corectate, ar trece prea mult timp pn ce s-ar efectua o nou ncrcare a depozitului. De asemenea, rezultatele multor interogri (de exemplu: care sunt primii 10 clieni sau care sunt cele mai bine vndute produse?) nu vor fi relevante n cazul in care depozitul de date este incomplet.

A doua abordare presupune ca toate datele s fie ncrcate n depozit, dar sunt definite i implementate mecanisme pentru identificarea i corectarea erorilor. Dei acast abordare permite ncrcarea depozitului cu toate datele din sistemele operaionale, calitatea datelor poate fi necorespunztoare, iar deciziile care se iau pe baza lor pot fi inadecvate. Not. Ori de cte ori este posibil, trebuie s se mearg pe varianta corectrii datelor n sistemele operaionale astfel nct la urmtoarea ncrcare a depozitului utilizatorii s beneficieze de avantajul datelor corecte. 4. Evaluarea mrimii depozitului de date ncrcarea iniial a depozitului de date poate s nu ridice probleme referitoare la capacitatea de memorare, dar pe msura trecerii timpului depozitul poate crete cu fiecare nou operaiune de ncrcare, iar gestiunea creterii volumului de date va cpta o importan deosebit. Exist cteva modaliti clasice de gestionare a creterii volumului datelor: agregrile stocate, limitarea perioadei de timp, tergerea datelor nefolosite. Folosirea agregrilor stocate reduce semnificativ spaiul solicitat de date, n special dac datele sunt folosite doar la nivelurile de sintez. Datele analitice pot fi terse sau arhivate dup ce au fost create valorile agregate, dar trebuie avut n vedere faptul c odat terse, nu se pot obine detalieri ale agregrilor. Dei utilizatorii ar vrea ca depozitul s stocheze datele permanent, se poate face un compromis referitor la perioada de timp pentru care un anumit set de date este pstrat n depozit. Prin folosirea rezultatelor indicatorilor statistici referitori la depozitul de date, pot fi identificate datele care nu sunt folosite de ctre utilizatori i astfel se poate proceda la tergerea lor. 5. Refacerea datelor n caz de accidente La fel ca i la BD, administratorii depozitului de date trebuie s acorde important sistemelor de recuperare a datelor n caz de accidente. Pe msura trecerii timpului, tot mai muli utilizatori din organizaie vor deveni dependeni de coninutul depozitului de date i astfel recuperarea datelor capt o importan deosebit. Anumite accidente pot necesita reinstalarea sistemelor de operare i a sistemelor de gestiune a bazelor de date, precum i rencrcarea depozitului de date i popularea tabelelor care conin agregri. Procedurile de recuperare trebuie s prevad toate situaiile neplcute care pot aprea.

Capitolul 3

Oracle DISCOVERER

3.1. Oracle Business Intelligence(BI) Discoverer - fundamentele 3.2. Componentele Oracle BI Discoverer 3.3. Oracle Discoverer Plus - aspecte relaionale 3.4. Oracle Discoverer Plus - aspecte multidimensionale

3.1. Oracle Business Intelligence(BI) Discoverer - fundamentele OracleBI Discoverer este o interfa interactiv de interogare, analiz, rapoarte i de publicare Web care ofer utilizatorilor acces rapid la informaii din baza de date. Acetia, att la nivel de conducere ct i la nivel operaional, au posibilitatea s ia decizii bine

fundamentate, n timp util. Folosind orice navigator (browser) Web se poate avea acces la sursa de date din Oracle BI Discoverer, surs care poate fi relaional sau multidimensional. Interfaa OracleBI Discoverer ofer o viziune din punctul de vedere al afacerii: ascunde complexitatea structurii datelor; ajut utilizatorul s se concentreze pe rezolvarea problemelor; ofer o soluie integrat i complet de Inteligena Afacerii.

Din punctul de vedere al tehnologiei utilizate, OracleBI Discoverer este un produs puternic, intuitiv, care permite: regsirea datelor dintr-o baz de date relaional sau multidimensional; accesarea datele rapid i eficient, fr a fi nevoie de o cutare n toata baza de date; vizualizarea datele ntr-un format acceptat de utilizatori: prietenos, familiar, uor de citit, uor de neles, flexibil; analiza complex a datelor utiliznd o mare varietate de tehnici: o operaii att de detaliu (drill down) ct i de sintez (roll up); o cutarea datelor care ndeplinesc tot felul de condiii, de la simple la complexe; o ordonarea datelor dup diferite chei simple sau compuse. construirea rapoartelor de diferite tipuri i afiarea lor; partajarea datelor ntre diferii utilizatori sau ntre diferite aplicaii informat ice care ruleaz sub diferite sisteme (exemplu sub Microsoft Excel).

Not. De exemplu, se poate folosi OracleBI Discoverer pentru analiza datelor avnd ca rezultat o colecie de foi de calcul (worksheet). Fiecare foaie de calcul va conine informaii i grafice provenite BD ca urmare a unei interogri.

3.2. Componentele Oracle BI Discoverer Componentele OracleBI Discoverer sunt Oracle Database i produsele Oracle Discoverer (D Administrator, D End User Layer, D Plus Relational and OLAP, D Desktop, D Catalog, D Viewer, D Portlets, D Portlet Provider). Scopul acestor componente este de oferi utilizatorului posibilitatea de a: analiza date din surse relaionale i multidimensionale folosind Internetul (D Plus); analiza date din surse de date relaionale i multidimensionale folosind o aplicaie Windows de pe calculator (D Desktop); analiza date ntr-o foaie de calcul existent (worksheet) (D Viewer sau D portlets); vizualiza date ca msur n tabloul de bord (D Portlet Provider i D portlets); gestiona datele din DD (D Administrator).

Oracle BI Discoverer Plus poate rula att pe Internet ct i pe Intranet i ofer posibilitatea: o s se creeze foi de calcul (worksheet) i grafice n care se aduc din DD informaiile dorite, sub forma dorit; o s se analizeze datele regsite din DD; o s se partajeze datele cu ali utilizatori. Oracle BI Discoverer Viewer poate rula att pe Internet ct i pe Intranet prin intermediul unui navigator (browser) Web i permite: o analiza datelor din foile de calcul create cu Discoverer Plus, i Discoverer Desktop; o personalizarea foilor de calcul (exemplu: repoziionnd componentele) si apoi salvarea schimbrilor efectuate. OracleBI Discoverer Desktop este o aplicatie tip Windows care ofer posibilitatea dezvoltrii de noi foi de calcul (worksheet) pentru analiza datelor relaionale. Foaia de calcul creat n Discover Desktop poate fi utilizat apoi n alte componente (Discoverer Plus, Discoverer Viewer, Discoverer portals). OracleBI Discoverer Administrator este o aplicaie de tip Windows folosit de ctre administrator pentru a realiza i menine o viziune de afaceri a datelor relaionale. OracleBI Discoverer End User Layer (EUL) este un dicionar/catalog utilizat pentru a salva i a restaura definiia obiectelor folosite la interogarea datelor relaionale.

OracleBI Discoverer Catalog este un dicionar/catalog utilizat pentru a salva i a restaura definiia obiectelor utilizator folosite la interogarea datelor multidimensionale. 3.3. Oracle Discoverer Plus - aspecte relaionale Discoverer Plus Relational este componenta care ofer posibilitatea de a crea i analiza foi de calcul (worksheet). Astfel, se poate regsi i analiza date din bazele de date ale companiei fr a fi nevoie s se neleag structurarea i complexitatea acesteia. Ali utilizatori Discoverer pot deschide foile de calcul partajate cu ei folosind Discoverer Plus Relational, Discoverer Viewer, Discoverer portals si Discoverer Desktop. Sursa de date relaionale este o baza de date n care datele sunt pstrate n mai multe tabele. Fiecare tabel conine un numr de coloane (atribute) i mai multe rnduri (tupluri). Acest lucru reprezint un mod eficient de a stoca i regsi datele operaionale. De obicei, tabelele din BDR sunt principala surs de date pentru DD, dar acestea pot deveni complicate i greoaie pentru regsire, atunci cnd conin foarte multe nregistrri. Zona de afaceri (business) este o colecie de date nrudite care se refer la acelai subiect dintr-o firm. Administratorul Discoverer lucreaz cu diferite departamente dintr-o organizaie pentru a identifica pentru fiecare datele din baza de date. El localizeaz datele n baza de date i le grupeaz in zone de afaceri. n cadrul fiecrei astfel de zone, administratorul Discoverer organizeaz datele n dosare. De exemplu, zonele de afaceri importante ale unei organizaii poat fi: Vnzri, Producie, Resurse umane etc. Administratorul Discoverer decide de asemenea, drepturile de acces ale utilizatorilor la fiecare zon de afaceri. Dosarul/directorul este o colecie de date nrudite. De exemplu, date despre produsele pe care organizaia le comercializeaz pot fi ntr-un director (folder) Produse. Un dosar este, analog cu o baz de date relaional, asemntor cu o tabel i el chiar poate fi construit dintr-o tabel. Diferitele dosare ntr-o zon de afaceri pot conine date relaionate. De exemplu, o zon de afaceri (divizia de vnzri) poate conine dou dosare: Produse care conine date despre fiecare produs: cod produs, denumire produs, unitate de msur ;

Vnzri care conine date despre vnzrile pentru fiecare produs: magazinul unde un anumit produs a fost vndut, preul cu care a fost vndut, codul produsului.

Prin interogarea dosarului de Vnzri se pot vedea informaii despre a anumit tranzacie. Dac vrem s vedem i denumirea produsul care a fost vndut, nu numai codul acestuia, va trebui s interogm i dosarul Produse. Administratorul Discoverer poate combina date din mai multe dosare ntr-unul singur pentru a face mai uoar regsirea datelor dorite. De exemplu, administratorul Discoverer poate crea un al treilea dosar denumit Produse-Vanzri care conine: denumirea produsului (din dosarul Produs) i preul care a fost dat pentru acesta (din dosarul Vnzri).

Obiectele (items) sunt date de diferite tipuri din dosare. Un obiect este similar unei coloane, dac ne gndim la o baz de date relaional i el chiar se poate baza pe o coloan dintr-o tabel. De exemplu, fiecare produs poate avea un cod, o denumire i o unitate de msur i atunci dosarul Produse va avea trei obiecte (cod produs, denumire produs, unitate de msur). Fiecare obiect va conine valori individuale, de exemplu, codul produsului poate conine o list de coduri. Administratorul Discoverer decide care obiecte sunt incluse n dosare bazndu-se pe datele care vor fi analizate.

3.4. Oracle Discoverer Plus - aspecte multidimensionale Discoverer Plus OLAP ne ajut s accesm i s analizm date multidimensionale din baza de date a organizaiei. Datele multidimensionale sunt optimizate pentru analiz i ele sunt organizate fie ca o baz de date multidimensional fie ca un depozit de date (datawarehouse). In bazele de date relaionale datele sunt organizate n tabele care sunt structurate n coloane/atribute i rnduri / tupluri. Datele multidimensionale sunt date organizate dup una sau mai multe dimensiuni, care sunt adesea referite sub forma unor cuburi. Baza de date Oracle poate include ambele surse de date: relaional (tabele i coloane) i multidimensional (cuburi). Aceast combinaie ofer un acces rapid la datele multidimensionale oferind i un sumar al datelor relaionale.

Figura. 10: Tabele i cuburi n baza de date Oracle Cubul multidimensional are urmtoarele componente: O msur = numele dat datelor propriu-zise (exemplu: Vnzari, Costuri); Una sau mai multe dimensiuni = numele dat prii cubului care clasific datele (exemplu: Produs, Zon geografic i Timp). Dimensiunile au membri, ierarhii i atribute; Celulele cubului = o valoare msurat pentru fiecare posibil combinaie a dimensiunilor, reprezentnd msura pentru cub; Clasificarea datelor = partea din cub care grupeaz datele (exemplu: produsul, timpul i oraul). Msurile reprezint date care pot fi examinate i analizate n rezultate sub form de tabele i grafice (exemplu: Vanzri, Cost, Profit). Dimensiunile se refer la msuri i au rolul de a clasifica datele. De exemplu, o msur a vnzrilor poate avea produse, timp si zon geografic ca dimensiuni. Cnd o msur are anumite dimensiuni particulare, se consider c msoar aceea dimensiune. De exemplu Vnzrile sunt dimensionate de Produse. Grupul de dimensiuni pentru msur constituie dimensionalitatea msurii. De exemplu dimensionalitatea Vanzrilor sunt Produsele, Timpul i Locaia. Membru al dimensiunii este fiecare element dintr-o dimensiune. De exemplu, Ianuarie 2005, Februarie 2005, anul 2005 pot fi membri ai dimensiunii Timp.

Ierarhia dimensiunii descrie o legtur ierarhic dintre dou sau mai multe dimensiuni. Membrii dimensiunilor individuale pot fi legai unul cu altul n ordine ierarhic. De exemplu o anumit zi aparine unei anumite luni, care aparine unui anumit an. Ierarhia ne ajut s facem o analiz mai amnunit i s avem informaii detaliate. O dimensiune poate avea mai mult de o ierarhie. De exemplu, dimensiunea Timp poate avea ierarhii diferite dac pentru organizaie anul fiscal nu corespunde cu anul calendaristic. O ierarhie poate fi An Calendaristic - Semestru Calendaristic - Luna Calendaristic, n timp ce alt ierarhie poate fi An Fiscal - Semestru Fiscal - Luna Fiscal. Cnd exist mai multe ierarhii pentru aceiai dimensiune, una dintre ierarhii trebuie s fie specificat ca implicit. Atributul dimensiunii descrie o caracteristic care este mprit de membrii dimensiunii. Atributele dimensiunii ne dau posibilitatea selectrii datelor pentru anumite caracteristici. De exemplu, dimensiunea Produse poate avea atributul Culoare care ne d posibilitatea s cutm doar produsele de culoare roie.