INTRODUCERE

Notă. Conceptul de Inteligenţa Afacerii – IA (Business Intelligence - BI) este o tehnologie informatică ce priveşte organizarea şi funcţionarea întreprinderii, precum şi a conducerii acesteia, având ca suport soluţiile 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 următoarele tehnologii ale IA privind prelucrarea volumelor mari de date: depozitele de date (data warehouse), concentrările 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 susţine procesul decizional şi optimizată pentru interogări rapide şi agregări complexe.

Depozitele de date rezolvă problemele legate de sursele de date disparate şi de scopurile incompatibile dintre procesarea tranzacţiilor şi aplicaţiile de Inteligenţa Afacerii. Scopul unui depozit de date este de a furniza un stoc central de date unde informaţiile din unul sau mai multe sisteme tranzacţionale pot fi consolidate într-o singură, integrată şi consistentă sursă de date. Depozitul de date este proiectat pentru a optimiza obţinerea de rapoarte pe un număr mare de înregistrări ale bazei de date. El presupune multe regăsiri şi foarte puţine actualizări (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 organizaţii;- cererile de regăsire sunt ad-hoc şi implică foarte multe înregistrări;- sursele de date sunt variate: istorice statistice, demografice etc.;- se pot folosi modele de date multidimensionale şi tehnologia OLAP;- colecţia de date de tip DD este:

o orientată pe subiectele importante din organizaţie: clienţi, produse etc.o integrată deoarece datele provin din surse diferite printr-un proces anterior de

curăţare / filtrare şi prelucrare;o non-volatilă pentru că operaţiile efectuate sunt în special de regăsire şi periodic

de încărcare, nu de actualizare;o dependentă de timp pentru că datele sunt stocate pentru o perioadă de 5-10 ani;

- necesitatea DD se referă la îmbunătăţirea calităţii informaţiilor din organizaţii.

De cele mai multe ori, DD sunt incluse ca facilităţi care aparţin unor SGBD, de exemplu Oracle Warehouse Builder, Oracle Discoverer.

CONCENTRĂRILE DE DATE (data marts)Concentrarea de date este un DD mai mic organizat la nivelul unui departament al unei organizaţii.

Deoarece procesul dezvoltării 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 concentrări 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 concentrări de date sunt:- dimensiunea mare, volumul de date fiind de zeci de GB;- este concentrat pe un singur subiect din organizaţie, de exemplu doar vânzările;- sursa datelor este diversă: din SBD operaţionale ale organizaţiei, din DD, din surse

externe;- agregarea datelor este intens utilizată şi se face rapid prin mecanisme specifice;

Aceste facilităţi, dacă sunt integrate în interfeţe care aparţin unui SGBD, răspund optim tuturor cerinţelor unei afaceri, deoarece se bazează pe un ansamblu mare şi variat de date, cu facilităţi de regăsire 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 Inteligenţa Afacerii cu un pas mai departe decât OLAP. În OLAP utilizatorul este angajat în mod activ în explorarea datelor, pe când în data mining, informaţia spune ceva despre ea fără să fie adresată vreo întrebare.Tehnologia de data mining utilizează metode de căutare complexe spre a identifica modele şi grupări ale datelor. Extragerea de date poate identifica tendinţe nesuspectate în comportamentul consumatorului, care potenţial pot fi utilizate să prevadă comportamentul viitorExtragerea de date se îmbunătăţeşte cu cât creşte cantitatea de date şi necesită depozite de date de înaltă calitate pentru a putea da rezultate utile.

Data mining se foloseşte în cel puţin două domenii: statistică superioară – pentru analize complexe, inteligenţa artificială – pentru descoperire şi cunoaştere.

Facilităţile de extragerea de date pot fi incluse în SGBD având stocul de date pregătit deja, prin interfeţe specializate cum ar fi Oracle Data Mining şi Oracle Miner.

Capitolul 1 – Depozite de date (DD) – aspecte fundamentale

1.1. Definire DD1.2. Organizarea datelor în DD1.3. Facilităţi oferite de DD1.4. Baze de date şi Depozite de date1.5. Arhitectura DD1.6. Tipuri de depozite de date

1.1. Definirea Depozitelor de Date

Depozitele de Date - DD (DW - data warehouse) reprezentă rezultatul interferenţei mediului economic şi al tehnologiilor informatice avansate. Mediul economic este tot mai competitiv, tinde spre globalizare, devine tot mai complex şi solicită informaţii elaborate pentru sprijinirea deciziilor strategice. Un astfel de mediu economic a determinat evoluţia activităţii de realizare a sistemelor informatice de la orientarea pe operaţional (activitatea curentă a firmei care pleacă de la funcţiile întreprinderii şi funcţiile conducerii) spre orientarea pe procesul de afacere. Procesul de afacere (business process) este un ansamblu de activităţi interdepartamentale, la nivelul unei organizaţii, care presupune una sau mai multe intrări şi care generează un rezultat important pentru client (intern sau extern). Sunt două caracteristici fundamentale ale procesului de afaceri:

- acum managerii gândesc şi decid mai mult la nivelul procesului de afaceri (interdepartamental) decât la nivelul funcţiilor întreprinderii. Acest lucru înseamnă că organizaţia este privită din punctul de vedere al clientului, ceea ce corespunde societăţii informaţionale care pune pe primul plan clientul;

- activitatea departamentelor unei organizaţii va fi integrată, ceea ce înseamnă o bună comunicare între ele. Rezultă astfel realizarea unor sisteme informatice integrate.

Evoluţia tehnologiilor informatice oferă soluţii eficiente de gestionare a unor volume foarte mari de date integrate(de ordinul TB – terabytes), asigurând niveluri de sinteză şi detaliere adecvate.

Costul realizării unui DD este foarte mare (milioane de USD) şi recuperarea investiţiei 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ă, înţelegerea şi utilizarea datelor în luarea deciziilor strategice, într-un mediu economic competitiv şi în rapidă evoluţie.

Managerii au înteles că datele stocate de sistemele informatice operaţionale, în fişiere sau baze de date, reprezintă o mină de aur informaţional care se cere exploatată.

Domeniile economice care se pretează la aplicarea DD sunt: bănci, asigurări, telecomunicaţii, hipermarket, transporturi. În aceste domenii au mare importanţă datele istorice din ultimii 5-10 ani.

William Inmon (vicepreşedintele firmei Prism Solutions), este părintele necontestat al noţiunii de Data Warehouse, iar viziunea sa se concentrază asupra rolului DD ca bază informaţională a deciziei manageriale, păstrând astfel un nivel înalt de generalitate si permiţând unor multiple implementări să intre în sfera acestei noţiuni. Earl Hadden este cel care a enunţat şi a experimentat o metodologie riguroasă pentru implementarea depozitelor de date.O serie de firme de Informatică şi-au adus contribuţia 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 întreţinută separat de bazele de date operaţionale ale unei organizaţii ş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 informaţiilor pentru analiză, furnizând o platformă solidă de consolidare a datelor istorice. Un depozit de date este un ansamblu de date consistente, din punct de vedere semantic, care serveşte la o implementare fizică a unui model de date pentru sprijinirea deciziei şi stochează informaţii pe care o organizaţie le solicită în luarea deciziilor strategice.

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

Notă. Soluţiile 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.).

Colecţiile de date (BD sau fişiere) utilizate de sistemul informatic operaţional au ca scop optimizarea şi siguranţa procesării datelor. Datele dintr-un depozit de date sunt organizate într-o manieră care să permită analizarea lor complexă, deci extragerea semnificaţiei economice pe care o poartă.

Datele operaţionale (BD sau fişiere) sunt orientate pe aplicaţii, în sensul că organizarea lor este optimizată pentru a servi procesului tranzacţional, dinamicii sistemului. Depozitul de date este orientat pe subiectele importante ale procesului economic: clientii, furnizorii, produsele, activităţile. Exemplu, o comandă lansată de un client va apărea în sistemul operaţional ca un set de înregistrări care vor conţine date despre client, date despre produsele sau serviciile comandate, date despre modul de transport, date despre modul de plată.

Sistemului tranzacţional (operaţional) este orientat către consistenţa datelor (restricţiile de integritate - cheile, validările etc.). Multe dintre datele esenţiale din perspectivă operaţională (numărul comenzii, poziţiile liniilor în cadrul comenzii etc) sunt lipsite de relevanţă din perspectivă informaţională a DD.

În sistemul operaţional redundanţa este minimizată (de exemplu prin procesul de normalizare - proiectarea) pentru a evita anomaliile de actualizare. În depozitul de date redundanţa este creată în mod intenţionat (prin denormalizare si sumarizare) pentru a permite un acces mai rapid şi uşor la date.

Integrarea datelor reprezintă un aspect important al depozitului de date şi anume raţiunea pentru care acesta este creat. Datele sunt adunate pentru a răspunde nevoilor informaţionale ale întregii organizaţii, asigurând faptul că rapoartele generate pentru diverse compartimente vor conţine aceleaşi rezultate. Sistemul operaţional 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 următoarele aspecte:

- modalităţi unice de codificare – există nenumărate variante de a codifica un câmp dar o aplicaţie pentru analiza datelor va trebui să se bazeze pe o codificare unică;

- Sistem de unităţi de măsură unitar - unităţile de măsură pentru diferite câmpuri trebuie exprimate într-un sistem unic (metric etc.);

- Sistem stabil de reprezentare fizică a datelor - în aplicaţiile tranzacţionale este posibil ca aceleaşi date să fie memorate în moduri de organizare diverse. Acestea trebuie stabilizate după anumite reguli precise;

- Convenţii clare privind modul de reprezentare a datelor – datele calendaristice, câmpurile care definesc timpul etc., trebuie să respecte convenţiile internaţionale;

- Convenţii unice privind denumirile câmpuilor de date - în sistemul operaţional acestea pot să difere de la o aplicaţie la alta, dar în DD ele trebuie să fie unice (lucrul în echipă).

Sistemul operaţional al unei organizaţii tinde mereu să reflecte realitatea curentă. Astfel, el se află într-o continuă evoluţie iar datele pe care le conţine 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 tranzacţiile efectuate sunt arhivate, fiind considerate deja de domeniul istoriei, deci neinteresante din perspectivă operativă. Pentru analiza economică, dimpotrivă, informaţiile care au caracter istoric sunt esentiale, deoarece ele pun în evidentă tendinţe care reprezintă fundamentul unei prognoze corecte. Depozitul de date este un istoric al sistemului operaţional. Orizontul de timp pe care îl acoperă depozitul de date este de cel puţin cinci ani, ajungând uneori la zece ani, în funcţie de dinamica evoluţiei pieţei şi, deci, de relevanţa 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 aplicaţii operaţionale (tranzacţii) presupun actualizarea continuă a colecţiilor de date (A, M, S). La depozitele de date, actualizarea este foarte rară, adică dinamica lipseşte. Actualizarea se realizează aici doar prin adăugarea 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 tranzacţie trebuie să ducă colecţia de date dintr-o stare consistentă într-o altă stare consistentă, iar aceasta implică mecanisme complexe de menţinere a integrităţii datelor (jurnalizare, salvare/restaurare, blocare). În cazul depozitelor de date, mecanismele de integritate sunt inutile, astfel că gradul de libertate câştigat poate fi utilizat pentru optimizarea accesului la date prin denormalizare, sumarizare, statistici ale accesării datelor, reorganizare dinamică a indexării etc.

Un depozit de date conţine un volum foarte mare de date. Unele dintre aceste date provin din sursele operaţionale ale organizaţiei, altele pot proveni din surse externe.

Metadatele

Metadatele sunt informaţii despre datele existente în DD, care descriu structura (conţinutul) depozitului şi furnizează referinţe 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 conţin informaţii despre: sursa datelor, algoritmii de sumarizare, statisticile de utilizare etc. Metadatele sunt create pentru toate numele de date şi definiţiile din depozit. Metadate adiţionale sunt create pentru a asocia intervale de timp la datele extrase şi alte câmpuri care vor fi adăugate prin filtrarea datelor sau prin procesele de integrare.

Metadatele unui DD conţin următoarele categorii de informaţii:

- o descriere a structurii de date din depozit, care include schema depozitului, dimensiunile, ierarhiile, definiţiile datelor derivate;

- metadatele operaţionale, care includ: date privind evoluţia în timp (istoricul datelor şi secvenţa de transformare aplicată asupra lor), circulaţia datelor (active, arhivate, şterse) şi informaţii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erori etc.);

- algoritmii utilizaţi pentru sumarizare, care includ: măsura şi dimensiunea algoritmilor definiţi, date despre granularitate, partiţii, arii de subiecte, agregări, sumarizări, rapoarte şi filtre predefinite;

- mapările (transformările) de la mediul operaţional la depozitul de date care includ: bazele de date sursă şi conţinutul lor, descrierile interfeţelor (gateways), partiţionarea datelor, extragerea datelor, filtrarea datelor, regulile de întreţinere, securitate a datelor;

- date referitoare la performanţele sistemului care include indici şi profiluri care îmbunătăţesc accesul la date şi performanţele de căutare;

- metadatele economice (business metadata), care includ termenii economici şi definiţiile aferente.

Exemple de metadate. Descrierea proprietăţilor datelor (obiectelor) din lumea reală se face prin intermediul metadatelor, printr-un proces de abstractizare. Astfel, metadatele referitoare la câmpurile unui depozit de date se vor referi la: denumirea câmpului (aşa cum va fi folosită în tabela relaţională fizică), sinonim pentru denumirea câmpului (aşa cum este folosit de utilizatori), tipul de date pentru fiecare câmp (aşa cum este acceptat de SGBD), indexarea (dacă va fi folosit pentru câmp), cheia (dacă un câmp este cheie), formatul câmpului, descrierea (o definiţie a câmpului).

Rolul metadatelor pentru depozitul de date reiese din următoarele 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 setaţi, conectări efectuate, drepturi existente etc.

- ajută administratorii şi utilizatorii depozitului să localizeze şi să înţeleagă secvenţele de date atât în sistemele sursă cât şi în structura depozitului. În sistemele operaţionale, dezvoltatorii şi administratorii bazelor de date lucrează cu metadate în fiecare zi. Toată documentaţia tehnică a sistemelor reprezintă într-un fel sau altul metadate. Ele rămân totuşi transparente pentru majoritatea utilizatorilor, ei percepând în general sistemul ca pe o cutie neagră ce oferă o interfaţă prin intermediul căreia trebuie manevrat. În cazul depozitelor de date, utilizatorii sistemelor de asistare a deciziei trebuie să înţeleagă înainte de toate conţinutul depozitului, pentru ca apoi să beneficieze de informaţiile necesare.

- procesul de analiză cuprinde mai multe etape: identificarea datelor, obţinerea datelor, interpretarea şi analiza datelor pentru a obţine informaţii, prezentarea informaţiilor şi recomandarea unei direcţii de acţiune. Pentru ca depozitul de date să fie folositor analiştilor din întreprindere, metadatele trebuie să ofere utilizatorilor informaţii care să-i ajute în parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie să ajute utilizatorii să găsească rapid datele în depozit şi să interpreteze corect datele obţinute prin oferirea informaţiilor referitoare la formatul şi semnificaţia datelor;

- metadatele sunt o formă de auditare a transformării 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 operaţionale. Toate regulile care guvernează transformarea datelor în noi valori sau

noi formate sunt considerate a fi metadate. Această formă de audit este necesară atunci când 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 interfaţa de analiză a depozitului de date;

- metadatele menţin şi cresc calitatea datelor, fapt ce se realizează prin definirea valorilor valide pentru fiecare câmp din depozit. Înainte de a fi efectiv încărcate în depozit, datele pot fi revăzute şi erorile pot fi corectate. De asemenea, regulile de corecţie a erorilor pot fi documentate tot prin metadate;

- permite gestiunea versiunilor. Un depozit de date conţine 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 câmpurilor sursă în câmpuri destinaţie, asupra agregărilor etc. Utilizatorii trebuie să aibă acces la metadatele corecte pentru perioada de timp pe care o studiază. Ceea ce la prima vedere ar părea să fie o eroare în transformarea datelor poate fi de fapt rezultatul schimbării 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 funcţie de destinaţia lor:o metadate administrative. Acestea conţin descrieri ale bazelor de date sursă şi

ale conţinutului lor, descrieri ale obiectelor depozitului de date şi ale regulilor folosite pentru a transforma datele din sistemul sursă în depozit, schema depozitului de date, interfeţe 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 interogări şi să interpreteze rezultatele. Pentru aceasta, ei au nevoie să cunoască definiţiile datelor din depozit, descrierea lor, precum şi orice ierarhie care poate exista în diferite dimensiuni. Astfel de metadate sunt: conţinutul depozitului de date, rapoarte şi interogări predefinite, definiţiile ierarhiilor, calitatea datelor, istoricul încărcării depozitului de date, reguli deştergere a datelor;

o metadate pentru optimizare. Aceastea au rolul de a creşte performanţele depozitului de date. Exemple de astfel de metadate sunt definiţiile agregărilor şi colecţii de statistici.

Notă. Deşi în mod tradiţional metadatele reprezintă o componentă dezvoltată la sfârşitul 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ă, obţinută dintr-o varietate de surse, disponibilă utilizatorilor într-un mod uşor perceptibil şi destinată fundamentării deciziei în contextul afacerii.

1.3. Facilităţi oferite de DD

Creşterea volumului de date, precum şi perfecţionarea software-ului de gestiunea acestuia au condus la o noua calitate a utilizării datelor prin analize care pot releva conducerii organizaţiei informaţii greu sau chiar imposibil de obţinut pe alte cai. Se pot obţine astfel informaţii privind: preferinţele clienţilor, profilul clienţilor, distribuţia produselor, regiunea unde se vinde mai bine un anumit produs, care sunt preferinţele unui anumit segment de piaţă etc.

Pentru a obţine informaţiile dorite, DD sunt supuse unor prelucrări 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, concentrări 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 organizaţii, astfel încât servere provenind de la furnizori diferiţi să se poată conecta simultan la depozitul deja existent. Este, de asemenea, deosebit de important să se aleagă o arhitectură care să se adapteze uşor la modificările de performanţe, capacitate şi conectivitate. Procesele de configurare, optimizare si administrare a sistemului, inclusiv procedurile de salvare - restaurare, precum si păstrarea în tot acest timp a functionalităţii sistemului pot deveni operaţii dificile dacă trebuie repetate la fiecare adăugare a unor noi servere în sistem.

Pentru a se evita căutarile 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 – concentrări de date) care să conţină numai datele relevante pentru analiza necesară. Concentrările de date (data marts) pot fi construite să funcţioneze pe configuraţii mai modeste decât depozitele de date şi sunt specifice unei anumite aplicaţii. Depozitul de date conţine informaţii care pot fi utilizate pentru a răspunde oricărei întrebări privind afacerile unei organizaţii, iar Concentrările de date conţin datele necesare unui anumit compartiment al organizaţiei (de ordinul GB). Conectând impreuna Concentrările de date aferente diferitelor compartimente aleorganizaţiei, formând astfel o infrastructură specifică, departamentele pot folosi în comun datele lor şi se poate crea astfel un sistem de suport al deciziei mai uşor de construit şi mai flexibil.

Depozitele de date sunt destinate managerilor şi analiştilor angrenaţi în luarea deciziilor strategice privind dezvoltarea şi viitorul organizaţiilor. Pentru aceasta, ei au nevoie de interfeţe performante de accesare şi utilizare a datelor din depozite, adică de produse software asociate depozitului de date:

- interfeţe oferite de SGBD utilizatorilor, care au nevoie de acces rapid, de informaţii punctuale (limbaje de interogare gen SQL, generatoare de rapoarte);

- interfeţe specializate pentru asistarea deciziilor, care transformă datele în forma cerută de decidenţi (grafice, diagrame, organigrame) sau oferă posibilitatea analizei tendinţelor, corelaţiilor şi interpretarea acestora (OLAP, Data mining).

Interfeţele OLAP se bazează pe reprezentarea multidimensională a datelor (cubul de date) şi permite analiza interactivă şi rapidă a datelor prin operaţiuni specifice. Utilizatorul poate

obţine rezultate immediate parcurgând dinamic dimensiunile cubului de date, lucrând cu niveluri diferite de sinteză/detaliere (exemplu Oracle OLAP).

Interfeţele de tip Data Mining asigură extragerea şi transformarea datelor în cunoştiinţe (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 corelaţii, reguli, cunoştiinţe utile sprijinirii deciziilor.

1.4. Baze de date şi Depozite de date

Atât bazele de date cât şi depozitele de date conţin cantităţi mari de date structurate care pot fi consultate rapid, prin structuri de acces optimizate şi se bazează, în majoritatea cazurilor, pe tehnologia relaţională.

Sistemele de baze de date relaţionale sunt adecvate aplicaţiilor curente de gestiune şi au ca obiectiv execuţia on-line a tranzacţiilor şi proceselor de interogare (sunt sisteme tip OLTP - On Line Transaction Processing). Aceste sisteme implementează toate operaţiile zilnice dintr-o organizaţie. Sistemele cu depozite de date servesc utilizatorilor sau specialiştilor în domeniul analizei datelor şi luării deciziilor, pot organiza şi prezenta datele în formate variate, în ordinea solicitărilor, de la diferiţi utilizatori (sunt sisteme tip OLAP – On Line Analytical Processing).

Bazele de date din sistemele operaţionale conţin date curente, detaliate, care trebuie actualizate şi interogate rapid, în condiţii de deplină securitate, constituind suportul sistemelor informaţionale de prelucrare a tranzacţiilor. Depozitele de date sunt construite special pentru sprijinirea luării deciziilor. Ele au ca obiectiv regruparea datelor, agregarea şi sintetizarea lor, organizarea şi coordonarea informaţiilor provenind din surse diferite, integrarea şi stocare acestora pentru a da decidenţilor o imagine adecvată care să permită regăsirea şi analiza eficace a informaţiilor necesare.

Interogările obişnuite într-un depozit de date sunt mai complexe şi mai variate decât cele din bazele de date. Ele se aplică asupra unor volume foarte mari de date şi presupun calcule complexe (analiza tendinţei, medii, dispersii etc.), care necesită adesea agregări.

Bazele de date sunt orientate pe client (customer oriented) şi sunt utilizate pentru procesarea tranzacţiilor şi interogărilor. DD sunt orientate pe piaţă (market oriented) şi utilizate de manageri şi analişti de date.

BD gestionează date curente care sunt destul de detaliate pentru a fi uşor utilizate înactivitatea operaţională.DD gestionează date istorice, furnizând facilităţi pentru sintetizare şi agregare, precum şi pentru stocarea şi gestionarea informaţiilor cu diferite niveluri de granularitate. Aceste aspecte fac ca datele să fie uşor utilizate de către decidenţi, mai ales în tactica şi strategia organizaţiei.

La BD sursele de date sunt tranzacţiile atomice, iar accesul este de tip citire şi scriere. La DD sursele de date sunt BD operaţionale, iar accesul este cel mai adesea de tip citire pentru interogări complexe.

O bază de date este proiectată pornind de la sarcini şi activităţi cunoscute: indexarea, utilizarea cheilor, căutarea unor înregistrări specifice, optimizarea interogărilor. Interogările unui depozit de date sunt adesea complexe, implicând calcule asupra unor grupuri mari de date cu totalizări pe diferite niveluri, ceea ce presupune activităţi speciale: de organizare a datelor, de acces.

O bază de date presupune procesarea concurentă a tranzacţiilor multiple. Controlul concurenţei pentru DD este mult mai simplu deoarece se aplică doar pentru citire.

Comparaţie între BD şi DD

Criteriu BD DDProcesele operaţionale informaţionaleExecuţie tranzacţii analizeUtilizatori toate categoriile manageri, analişti de dateOperaţii zilnice asistarea decizieiCaracterul datelor curente istoriceNivelul de sinteză primitive, detaliere sintetizare, consolidareAcces citire, scriere citireFocalizare culegere date furnizare informaţiiSursa de date este validată filtrată, transformatăVolum de date ordinul GB ordinul TBPriorităţi performanţe, disponibilitate flexibilitate, autonomie Software necesar SGBD specializat, SGBD

Date externe

Date interne

Date arhivate

transformare

Metadatele

Datele aggregate

Datele detaliate

Data Mart

Data Mining

OLAP

1.5. Arhitectura depozitelor de date

Sunt cel puţin două arhitecturi de DD care se pot transforma oricând una în cealaltă: pe componente, pe niveluri.

Arhitectura pe componente a depozitelor de date

Evidenţiază componentele DD şi legăturile dintre ele: depozitul de date, sursa de date, interfeţele de analiză.

Esenţa unui depozit de date constă într-o bază de date de dimensiuni foarte mari conţinând informaţiile pe care le pot folosi utilizatorii (clienţi, furnizori, companii de publicitate etc.).

Depozitul de date conţine mai multe tipuri de date care corespund diferitelor cerinţe informaţionale ale utilizatorilor: date detaliate, date agregate, metadate (dicţionarul de date).Metadatele descriu datele conţinute în depozitul de date şi modul în care ele sunt obţinute şi stocate. Prin metadate se precizează structura datelor, provenienţa lor, regulile de transformare, de agregate şi de calcul. Ele sunt utilizate oro de câte ori se utilizează DD: la încărcarea datelor, la consultare, la actualizare, adică pe parcursul întregului ciclu de viaţă al depozitului.Datele agregate, deşi determină o creştere a redundanţei datelor, sunt necesare în DD deoarece în acest fel se poate asigura un timp mediu de răspuns cât mai redus. Aceste date presupun un grad de prelucrare prealabilă, astfel încât să fie pregătite pentru nevoile managementului: consolidare, totalizare, însumare, împachetare (în formate accesibile interfeţelor de analiză utilizate).

sursa de date depozit de date interfeţe de analiză

Datele detaliate sunt cele relativ recente, livrate utilizatorilor, de regulă la nivel de execuţie. Tot aici se găsesc date având o anumită vechime (câţiva 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ă destinaţia.Sursele de date pentru DD sunt: datele operaţionale curente (BD şi/sau fişiere din sistemul informatic al organizaţiei), datele vechi arhivate, datele externe (BD şi fişiere din sistemele informatice ale altor organizaţii).Construirea depozitului de date, pornind de la sursele de date, presupune parcurgerea unor etape în cadrul unui proces de extragere – transformare – încărcare (ETL – Extract Transformation Load):

- extragerea datelor din datele operaţionale 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;

- încărcarea 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 agregări sunt stocate în depozitul de date împreună cu datele importate din sursele interne şi externe.

Notă. În infrastructura Oracle funcţia ETL pentru un depozit de date este îndeplinită de produsul Oracle Data Integrator – ODI.Interfeţele de analiză sunt produse software care implementează tehnologii informatice pentru extragerea şi analiza datelor din DD: concentrări de date (Data Mart), extrageri şi analize de date (Data Mining) analiza multidimensională a datelor (OLAP).

Arhitectura depozitelor de date pe trei straturi

Evidenţiază modul de implementare a DD într-un mediu de reţea 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 relaţionale. Datele care provin din bazele de date operaţionale şi din sursele externe (de exemplu date referitoare la profilul clientului, date furnizate de consultanţi externi, rezultatele unor sondaje) sunt extrase utilizând 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 interfeţe: ODBC (Open DataBase Connection), OLE(Open Linking and Embedding), JDBC (Java DataBase Connection). Astfel, datele sunt extrase, filtrate, transformate şi încărcate în depozitul de date prin interfeţe specializate de tip ETL - Extract Transformation Load (de exemplu produsul Oracle Data Integrator – ODI). Împrospătarea datelor din DD se face pe măsura trecerii timpului (lunar, trimestrial, anual). Stratul mediu (middle tier) este bazat pe un server specializat, care poate fi: OLAP (bazat pe modelul relaţional – ROLAP sau pe modelul multidimensional - MOLAP), Data Mining (analize statistice superioare), Data Mart (concentrări de date). De multe ori acest strat este inclus în SGBDR (exemplu Oracle, DB2). Stratul superior (top tier) este nivelul client care conţine interfeţe pentru generarea interogărilor, a rapoartelor, pentru superioară a datelor.

Strat superior Rapoarte, interogări

extragere

Strat mediu

transformareStrat inferior

1.6. Tipuri de depozite de date

După aria de cuprindere se întâlnesc trei tipuri de depozite de date: depozite de întreprindere (Enterprise Warehouse), concentrări de date (Data marts), depozite virtuale de date (Virtual Datawarehouse).Depozitul de întreprindere colectează toate informaţiile despre subiectele care privesc întreaga organizaţie. El furnizează un volum foarte mare de date. De regulă conţine date detaliate, dar şi date agregate, iar ca ordin de mărime, 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.Concentrările de date conţin un subset al volumului de date din organizaţie, specific unui grup de utilizatori (unui compartiment). Domeniul este limitat la subiecte specifice. De exemplu, pentru activitatea de marketing se limitează subiectele la clienţi, produse, vânzări. Datele conţinute sunt de obicei agregate. Concentrările de date sunt implementate pe servere departamentale (UNIX sau Windows). Ciclul de implementare al unei Concentrări de date este măsurat în săptămâni sau luni sau ani. Ca atare, un data mart poate fi considerat un subansamblu al unui depozit de date mai uşor de construit şi întreţinut şi mai puţin scump.Depozitul virtual este un set de viziuni (views) asupra bazelor de date operaţionale. Pentru eficienţa procesărilor interogărilor, numai unele din viziunile de agregare pot fi materializate. Un depozit virtual este uşor de construit, dar necesită capacităţi suplimentare pe serverele de baze de date.După modelul de date implementat sunt următoarele tipuri de DD: DD relaţionale, DD multidimensionale.

Servere specializate

Depozite de date

Server de Date

Capitolul 2 Realizarea DD

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

Realizarea unui depozit de date presupune aplicarea unei scheme de analiză economică pentru a determina măsura în care depozitul de date este necesar şi eficient:

- trebuie să furnizeze avantaje competitive prezentând informaţii relevante pe baza cărora putem măsura performanţele şi putem face ajustări critice pentru a câştiga în faţa competitorilor;

- poate determina creşterea productivităţii deoarece permite obţinerea rapidă şi eficientă de informaţii care descriu cu acurateţe organizaţia;

- facilitează gestiunea relaţiilor cu clienţii, deoarece acesta furnizează o viziune consistentă despre clienţii şi produsele comercializate de organizaţie, pe toate departamentele;

- determină reducerea costurilor prin reliefarea tendinţelor , direcţiilor şi excepţiilor 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 informaţiilor relevante

necesare în depozitul de date, informaţii care reprezintă un sprijin decizional în activitatea curentă.

o viziunea datelor sursă (data source view) exprimă informaţiile culese, stocate şi gestionate de sistemele operaţionale. Aceste informaţii pot fi documentate pe niveluri variate de detaliere şi acurateţe, 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ă informaţiile care sunt stocate în depozitele de date, incluzând contorizări şi totaluri precalculate, precum şi informaţii privitoare la sursă, dată calendaristică, origine, adăugate 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 utilizând abordarea:- de sus în jos (top-down) care porneşte cu proiectarea şi planificarea completă. Se

utilizează în cazul când tehnologia este matură şi bine cunoscută şi problemele economice care trebuie rezolvate sunt clare şi bine înţelese. Dezvoltarea top-down a unui depozit de date constituie o soluţie sistemică şi minimalizează integrarea problemelor. Soluţia este scumpă, solicită timp îndelungat pentru dezvoltare şi îi lipseşte flexibilitatea determinată de dificultăţile în realizarea modelelor de date pentru întreaga organizaţie;

- de jos în sus (bottom-up) porneşte cu experimente şi prototipuri. Aceasta este utilizată la începutul stadiului de modelare şi de dezvoltare tehnologică. Ea permite unei organizaţii să meargă înainte cu cheltuieli considerabil mai mici şi să evalueze beneficiile tehnologiei înainte de a face angajamente semnificative în această direcţie. Abordarea bottom-up în proiectarea, dezvoltarea şi aplicarea concentrărilor de date (data marts) independente furnizează flexibilitate, costuri scăzute şi recuperarea rapidă a investiţiei. Soluţia poate determina probleme, când se încearcă integrarea într-un depozit de date consistent la nivel de întreprindere.

- mixtă presupune că o organizaţie poate exploata caracterul planificat şi strategic al abordării top-down atât timp cât reţine avantajele implementării rapide şi oportune a aplicaţiilor după abordarea bottom-up.

Realizarea unui depozit de date presupune următorii paşi: 1. strategia de realizare; 2. planificarea (modelarea) cerinţelor; 3. implementarea; 4. exploatarea.

Sistemele software mari pot fi dezvoltate utilizând 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 următorul. Metoda în spirală implică generarea rapidă de sisteme funcţionale 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, modificările pot fi făcute imediat şi noile proiecte şi tehnologii pot fi adaptate în mod rapid.

Notă. Cu toate că au existat încercări de a utiliza metodologiile tradiţionale de dezvoltare a software-ului pentru depozitele de date, practicienii depozitelor de date consideră că strategia în spirală (iterativă) este mai potrivită decât cea în cascadă.

2.1. Strategia de realizare a depozitelor de date

Strategia de dezvoltare, la nivelul cel mai sintetic, trebuie să încludă elementele următoare:- planul preliminar al depozitului de date. In cadrul unui proiect DD nu pot fi

satisfăcute toate cerinţele utilizatorilor deoarece un astfel de proiect ar fi imens şi periculos din punct de vedere al capacităţii de gestionare. Este mult mai realist să se facă o listă cu priorităţile cerinţelor diferiţilor utilizatori, iar aceste cerinţe să fie ataşate diferitelor segmente care se vor dezvolta prin strategia iterativă. Natura iterativă a proiectului permite echipei de dezvoltare să extindă funcţionalităţile depozitului de date într-o manieră uşor de controlat;

- arhitectura preliminară a depozitului de date. Se definişte 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, analiştii pot să determine o mulţime de alte componente tehnologice care sunt necesare pentru fiecare versiune;

- lista preliminară a mediilor de dezvoltare a depozitului de date. Există un număr destul de mare de medii şi instrumente pentru DD din care se pot face alegeri şi, de aceea, se recomandă alcătuirea unei liste sintetice cu cele care pot fi de folos în cadrul organizaţiei. Un set standard de instrumente va reduce problemele de integrare şi va minimiza efortul de învăţare atât pentru echipa de dezvoltare, cât şi pentru utilizatori.

Etapele necesare pentru a duce la îndeplinire strategia DD sunt următoarele: determinarea contextului organizaţional, realizarea unei vederi preliminare de ansamblu asupra cerinţelor, 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 până la cinci săptămâni, în funcţie de disponibilitatea resurselor şi mărimea organizaţiei.

1. Determinarea contextului organizaţional. Inţelegerea profundă a organizaţiei ajută la stabilirea contextului în care se desfăşoară proiectul şi poate evidenţia aspectele culturii organizaţionale, care pot uşura sau îngreuna proiectul depozitului de date. Răspunsurile la întrebările legate de organizaţie se obţin de obicei de la susţinătorul proiectului, managerul IT sau managerul de proiect. Intrebările tipice sunt următoarele:- cine este finanţatorul (susţinătorul) proiectului în acest caz? Susţinătorul proiectului stabileşte domeniul proiectului DD. Acesta joacă un rol foarte important în stabilirea relaţiilor de lucru între membrii echipei de dezvoltare, mai ales dacă sunt implicaţi şi terţi. Accesul facil la datele depozitului poate fi limitat de domeniul organizaţional, care se află sub controlul susţinătorului proiectului;- care sunt grupurile IT din organizaţie care sunt implicate în proiectul DD? Deoarece un depozit de date este o dorinţă a organizaţiei, grupurile IT din interior vor fi întotdeauna implicate în acest efort. Trebuie ştiut care sunt relaţiile de lucru dintre ele şi care este gradul de ocupare. Dacă, de exemplu, departamentul IT este foarte preocupat cu imbunătăţirea sistemelor operaţionale este foarte puţin probabil ca un depozit de date să fie pe lista de priorităţi;- care sunt rolurile şi responsabilităţile fiecaruia dintre cei care au legătură cu proiectul? Este important să definim rolul şi responsabilitaţile fiecărei persoane implicate. In acest fel se stabilesc limite şi obiective, iar comunicarea şi înţelegerea proiectului se îmbunătăţesc.

2. Realizarea unei vederi preliminare de ansamblu asupra cerinţelor. In această etapă se obţine un inventar al cerinţelor utilizatorilor prin interviuri, individuale sau de grup, realizate în comunitatea utilizatorilor finali. Dacă este posibil, se recomandă obţinerea de formate referitoare la rapoartele curente folosite de conducere. Inventarul cerinţelor furnizează aria de întindere a informaţiilor despre care se aşteaptă să le ofere un viitor depozit de date.Obiectivul principal este acela de a înţelege nevoile utilizatorilor, destul de mult, ca să poată fi ierarhizate. Aceasta este o informaţie critică ce determină aria fiecărui segment DD.

Exemple de întrebări care pot constitui repere într-o discuţie cu potenţialii utilizatori ai depozitului de date:Funcţiile. Care este misiunea grupului sau a departamentului? Cum procedaţi ca să vă îndepliniţi misiunea? Cum ştiţi dacă aţi atins obiectivele fixate? Care sunt indicatorii de performanţă pe care îi folosiţi şi care sunt factorii critici de succes?Clienţii. Cum vă grupaţi sau vă clasificaţi clienţii? Se modifică această grupare de-a lungul timpului? Modul de grupare afectează modul în care vă trataţi clenţii? Ce fel de informaţii păstraţi despre fiecare tip de client? Ce informaţii demografice folosiţi? Aveţi nevoie să păstraţi date despre fiecare client în parte?Profitul. La ce nivel măsuraţi 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 folosiţi actualmente? Sistemele. Ce sisteme folosiţi ca parte a muncii dvs.? Ce fel de transformări manuale de date trebuie să faceţi atunci când datele nu sunt disponibile?Timpul. Pentru câte luni sau ani aveţi nevoie să fie păstrate datele? Analizaţi performanţele pe durata unui an? La ce nivel de detaliere aveţi nevoie să fie prezentate graficele? Zilnic? Săptămânal? Lunar? Trimestrial? Anual? Cât de repede aveţi nevoie de date? Interogările şi rapoartele. Ce rapoarte folosiţi acum? Ce informaţii folosiţi de fapt din fiecare raport pe care îl primiţi? Putem obţine machete ale acestor rapoarte? Cât de des se produc aceste rapoarte? Le primiţi destul de frecvent sau timpul de aşteptare este prea mare? Cine produce rapoartele pe care le primiţi? Cine sunt cei pentru care alcătuiţi dvs. rapoartele?Produsele. Ce produse vindeţi şi cum le clasificaţi? Aveţi o ierarhie a produselor? Analizaţi datele pentru toate produsele în acelaşi timp sau analizaţi datele despre fiecare produs în parte? Cum gestionaţi modificările care intervin în ierarhia produselor?Geografia. Organizaţia operează în mai mult de o singură zonă? Vă împărţiţi piaţa în zone geografice? Păstraţi datele despre vânzări pe fiecare regiune în parte?

La realizarea interviurilor pentru dezvoltarea depozitelor de date, este indicat să luăm în considerare următoarele recomandări:

- Trebuie evitat să facem delimitări clare privind aria depozitului de date. Nu trebuie să fim surprinşi dacă o să constatăm că o parte dintre interogările şi rapoartele de care au nevoie utilizatorii nu pot fi realizate pe baza datelor existente în sistemele operaţionale.

- Trebuie păstrat clar obiectivul interviului şi nu trebuie să ne abatem de la el. Obiectivul principal este acela de a realiza un inventar al cerinţelor, nefiind nevoie o înţelegere foarte detaliată a acestora.

- Echipa care realizează interviurile trebuie să fie mică; echipa ideală este formată din doi oameni – unul va pune intrebările şi celălalt va nota răspunsurile. Intervievaţii pot fi intimidaţi dacă sunt abordaţi de un grup prea mare.

- Se poate înregistra interviul, dacă persoana este de acord. Majoritatea persoanelor nu au nimic împotrivă, dacă le cereţi acordul să înregistraţi discuţia pe suport magnetic, iar ascultarea ulterioară a discuţiei 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 cerinţe legate de informaţii cu caracter strategic. In funcţie de intervievat se vor alege şi întrebările la care se solicită răspuns.

- Trebuie obţinut copii ale rapoartelor, ori de câte ori este posibil. Rapoartele vor furniza echipei de dezvoltare informaţii 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ă obţină un inventar al sistemelor sursă potenţiale pentru depozitul de date. In timp ce managerul IT va furniza imaginea de ansamblu a sistemelor existente în organizaţie, cei mai în măsură să ofere detalii pentru auditarea sistemelor sursă sunt administratorii de baze de date şi administratorii de sistem care întreţin sistemele operaţionale.

Exemple de întrebări tipice pentru realizarea unui astfel de audit:Arhitectura curentă. Care este arhitectura tehnologică curentă a organizaţiei? Ce fel de sisteme, echipamente, sisteme de gestiune a bazelor de date, reţele, instrumente utilizator, interfeţe de dezvoltare şi de accesare a datelor se folosesc în prezent?Relaţiile între sistemele sursă. Există o legătură între diversele sisteme sursă? Un sistem furnizează informaţii altuia? Sistemele sunt integrate într-un mod anume?Facilităţi de reţea. Există facilităţi de reţea ce pot fi utilizate? Este posibil a se folosi doar un terminal sau un microcalculator pentru a accesa sisteme operaţionale diferite, din orice zonă?Calitatea datelor. Care este calitatea datelor? Cât de multe operaţii defiltrare, triere, deduplicare şi integrare estimaţi că vor fi necesare? Ce zone, tabele sau câmpuri, din sistemele actuale sunt cunoscute pentru slaba calitate a datelor?Documentaţia. Câtă documentaţie este disponibilă pentru sistemele sursă? Cât de corecte şi de actuale sunt aceste manuale şi referinţe? Este bine de obţinut următoarele informaţii ori de câte ori este posibil: copii ale manualelor şi instrucţiunilor de utilizare, structura bazelor de date, părţi 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 credeţi că vor fi mecanismele de extragere a datelor care nu vor funcţiona cu sistemul actual?

4. Identificarea surselor de date externe. Organizaţia poate folosi surse de date externe pentru completarea datelor din sistemele sursă interne. Astfel de surse de date externe pot fi: date de la bănci, date referitoare la codurile poştale, date statistice sau demografice, date de la alte organizaţii, date de la agenţii de ştiri sau din publicaţii.

Deşi datele externe reprezintă o oportunutate pentru îmbogăţirea depozitului de date, ele prezintă dificultăţi din cauza granularităţii diferite şi, de aceea, decizia în legătură cu folosirea datelor externe trebuie să fie bine fundamentată.

5. Definirea versiunilor depozitului de date. Specialiştii recomandă împărţirea dezvoltării 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 cerinţelor utilizatorilor şi reduce efectele riscurilor care pot apărea. Fiecărei cerinţe i se atribuie un nivel de prioritate. Se face o evaluare iniţială a complexităţii în funcţie de numărul sistemelor sursă. De asemenea, este identificat şi sistemul ţintă. Pot fi luaţi în calcul mai mulţi factori pentru o mai bună înţelegere

Data Warehouse

ReportWriter

(5 utilizatori)

Data Warehouse

ReportServer

(10 utilizatori)

DataMart

Fig. 20. Exemple de arhitecturi preliminare pe versiuni

Versiunea nr. 2

Versiunea nr. 1

ROLAPFront-End

(10 utilizatori)

ROLAPFront-End

(15 utilizatori)

AlertSystem

(10 utilizatori)

EIS/DSS(3 utilizatori)

a cerinţelor fiecărui modul. Definirea fiecărui modul este finalizată doar atunci când este aprobată de către susţinătorul proiectului.

6. Definirea arhitecturii preliminare a depozitului de date. Trebuie să se schiţeze o arhitectură preliminară pentru fiecare modul în funcţie de aria de întindere aprobată. Este recomandabil să se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaţionale şi multidimensionale, precum şi instrumente adecvate.

O arhitectură preliminară trebuie să prezinte cel puţin următoarele elemente:Depozitul de date şi concentrările 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 concentrări de date nu sunt implementate izolat.Numărul de utilizatori. Se specifică numărul de utilizatori pentru fiecare instrument de acces la fiecare versiune în parte.Localizarea. Se precizează locul de dispunere a depozitului de date, a concentrărilor de date şi a utilizatorilor pentru fiecare modul. Aceste aspecte au implicaţii asupra cerinţelor arhitecturii tehnice a proiectului depozitului de date.

7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizaţia poate alege între mai multe medii şi interfeţe pentru a dezvolta depozitul de date. Important este să se selecteze combinaţia de interfeţe care satisfac cel mai bine cerinţele organizaţiei. In prezent nu există un producător care să ofere o suită integrată pentru depozite de date, însă există lideri pentru fiecare categorie în parte. Se vor elimina variantele neconvenabile şi se va alcătui o listă din care fiecare versiune va avea parte de un set de interfeţe (acces la date, SGBD etc.).

2.2. Modelarea depozitelor de date

Modelarea (planificarea) unei versiuni a depozitului de date se realizează conform strategiei acestuia, stabilită de către specialiştii organizaţiei. Planificarea depozitului de date detaliază domeniul preliminar al unei versiuni prin obţinerea detaliilor despre cerinţele utilizatorilor referitoare la interogări, la construirea unei scheme iniţiale a depozitului de date şi la stabilirea câmpurilor de interes din sistemele sursă.Un proiect de planificare (modelare) durează în general între cinci şi opt săptămâni, în funcţie de aria de întindere a modulului. Evoluţia proiectului variază în funcţie de modul de participare a personalului din întreprindere, de disponibilitatea şi calitatea documentaţiei sistemelor sursă şi de modul în care sunt rezolvate problemele care apar.

Etapele necesare pentru realizarea planificării depozitului de date sunt următoarele: alcătuirea echipei, analiza cerinţelor, auditarea sistemelor sursă, proiectarea schemelor depozitului de date, transformarea câmpurilor sursă în câmpurile destinaţie, încărcarea datelor istorice în depozitul de date, selectarea mediilor de dezvoltare, crearea prototipului pentru versiunea curentă.

1. Alcătuirea echipei de lucru.Se identifică toate părţile care vor fi implicate în implementarea depozitului de date şi vor fi iniţiate în legătură 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 responsabilităţi), astfel încât să poată fi stabilite termene şi obiective realiste pentru fiecare în parte.

Dacă este necesar membrii echipei vor fi instruiţi cu privire la conceptele referitoare la tehnologia depozitelor de date. Va fi mult mai uşor pentru fiecare să muncească împreună, dacă toţi vor avea un scop comun şi o viziune identică în ceea ce priveşte atingerea acestui scop. Ca urmare, trebuie descrise activităţile şi jaloanele proiectului, precum şi legăturile care există între diversele activităţi. Se va stabili şi frecvenţa întâlnirilor cu toţi membrii echipei, de regulă săptămânal, pentru a analiza starea în care se află proiectul.

2. Analiza cerinţelor informaţionale.Analiza cerinţelor informaţionale este una din cele două activităţi care se pot desfăşura în paralel în timpul planificării depozitului de date, cealaltă activitate fiind auditarea sistemelor sursă. Obiectul analizei cerinţelor îl constituie înţelegerea cerinţelor informaţionale ale decidenţilor.

O analiză preliminară a fost deja efectuată ca parte a formulării strategiei DD. In această etapă este revizuită aria de cuprindere a modulului depozitului de date, aşa cum a fost ea definită în documentaţia strategiei. Se va finisa acest aspect prin detalierea analizei preliminare a cerinţelor decizionale. Va fi necesar să se stabilească noi întâlniri cu reprezentanţii utilizatorilor. Aria de cuprindere a modulului va fi determinată în termeni de interogări şi rapoarte care vor putea fi realizate la finalizarea modulului depozitului de date. Finanţatorul proiectului trebuie să revadă şi să aprobe documentaţia pentru a se asigura că

aşteptările conducerii organizaţiei vor fi atinse. De asemenea, vor fi documentate toate limitările impuse de sistemele sursă, iar aceste informaţii vor fi oferite auditorilor pentru a fi confirmate. Limitările impuse de sistemele sursă determină în mare măsură modul în care va arăta 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 încât versiunea să poată fi implementată într-o perioadă de la trei până la şase luni, de o echipă de 6-12 membrii.

Notă. Uneori, este posibil ca o organizaţie să treacă direct la faza de planificare a depozitului de date, fără ca în prealabil să formuleze strategia DD. Acest lucru se întâmplă, de obicei, atunci când un grup de utilizatori preiau iniţiativa depozitului de date, după ce în prealabil şi-au sintetizat cerinţele informaţionale. In acest caz, un număr de operaţiuni din etapa de formulare a strategiei vor fi etape din planificarea primei versiuni a depozitului de date: determinarea contextului organizaţional, 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 potenţiale de date pentru depozit. Auditarea preliminară a sistemelor sursă din cadrul formulării strategiei DD trebuie să ofere o listă completă a surselor de date.

Sistemele sursă de date sunt în primul rând cele interne. Cele mai bune candidate pentru a fi sisteme sursă sunt sistemele operaţionale care automatizează tranzacţiile zilnice ale întreprinderii. Pe lângă sistemele operaţionale, mai sunt folosite ca sursă de date şi rapoartele financiare ale întreprinderii, mai ales dacă interogările şi rapoartele se focalizează pe măsurarea profitabilităţii. 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 auditării sistemelor sursă sunt administratorii de baze de date, administratorii de sistem şi alţi specialişti IT, care gestionează sisteme interne ce pot deveni surse pentru depozitul de date. Având în vedere cunoştiinţele pe care le au asupra sistemelor existente, ei sunt cei mai în măsură să aprecieze oportunitatea folosirii fiecărui sistem ca sursă de date pentru depozit. Aceste persoane sunt de asemenea familiarizate cu problemele legate de calitatea datelor din diverse sisteme sursă. Informaţiile oferite de aceştia vor fi documentate pentru a sprijinii procesul de extragere şi filtrare a datelor. Administratorii de baze de date şi ceilalţi specialiştii IT pot oferi informaţii valoroase cu privire la regulile după care se obţin rapoartele existente pe baza datelor primare.

Pentru auditarea sistemelor sursă trebuie realizate interviuri, individuale sau de grup, cu specialiştii IT din organizaţie şi se va urmări obţinerea următoarelor documente şi informaţii, dacă nu au fost deja colectate în etapa de stabilire a strategiei DD:- documentaţia arhitecturii IT a organizaţiei (toată documentaţia care oferă o vedere de ansamblu asupra arhitecturii IT): diagramele arhitecturii sistemului (un model al tuturor sistemelor informaţionale existente în întreprindere şi al legăturilor dintre ele), modelul datelor întreprinderii (un model al tuturor datelor care sunt stocate în prezent), arhitectura reţelei (o diagramă care descrie amplasarea şi configurarea reţelei);

- 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 mărimii ei;- planurile de perspectivă: ce proiecte de dezvoltare şi implementare au fost aprobate pentru următoarele 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ă foloseşte un anumit sistem de codificare şi de aceea administratorii bazelor de date trebuie să ofere informaţii referitoare la modul în care sunt generate codurile, la modul de reutilizare a codurilor, la posibilitatea unificării lor;- mecanismele de extragere: trebuie verificat dacă datele pot fi citite sau extrase direct din bazele de date operaţionale. Pachetele de aplicaţii 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 cerinţelor informaţinale ale utilizatorilor versiunii respective. Sunt disponibile scheme rezultate din două tipuri de modele: relaţional (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 relaţionale (tranzacţionale –OLTP).

În modelarea multidimensională se lucrează cu schemele: stea, fulg de zăpadă, constelaţie, care sunt denormalizate şi conţin tabele de fapte şi tabele dimensiune (tehnologia OLAP).

5. Transformarea câmpurilor sursă în câmpurile destinaţie.La trecerea câmpurilor sursă în câmpurile destinaţie trebuie să se stabilească modul în care câmpurile din sistemele sursă operaţionale sunt transformate în câmpuri ale depozitului de date.

Un câmp 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 operaţional va avea propriile înregistrări referitoare la clienţi şi produse. Un câmp 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 situaţia inversă, un câmp din sistemele operaţionale poate fi divizat în mai multe câmpuri în depozitul de date. Exemplu, există sisteme operaţionale care înregistrează adresele ca linii de text cu numele câmpului Adresa. Acesta poate fi impărţit în mai multe câmpuri cum ar fi: Strada, Oraş, Judeţ.

Pentru a elimina orice confuzie, care poate apărea referitor la modul în care datele sursă sunt transformate în depozitul de date, se recomandă creearea unui tabel sursă-destinaţie care să evidenţieze cum se transformă fiecare câmp. De asemenea, trebuie să se precizeze toate regulile care guvernează integritatea sau divizarea datelor.

6. Încărcarea datelor istorice în depozitul de date.La încărcarea datelor istorice în depozitul de date trebuie avut în vedere următoarele aspecte:- Schimbările în structura datelor. Se va determina dacă schemele tuturor sistemelor sursă au suferit modificări in timp. De exemplu, dacă perioada pentru care sunt păstrate datele în depozit este de doi ani şi datele din ultimii doi ani trebuie încărcate în depozit, echipa trebuie să verifice dacă schema a suferit modificări în această perioadă. În caz afirmativ, operaţiunile de extragere şi integrare a datelor devin mult mai complicate. Fiecare sistem sursă va necesita, probabil, propriul tabel sursă-destinaţie.- Disponibilitatea datelor istorice. În mod obligatoriu trebuie să se determine dacă datele istorice sunt disponibile pentru încărcarea lor în depozitul de date.

Notă. Aspectele de mai sus vor fi mult mai dificil de analizat, dacă documentaţia necesară lipseşte 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 amănunţit al acestui aspect în etapa de definire a strategiei, activitatea de selectare devine opţională. Dacă strategia DD nu a fost formulată atunci trebuie să se facă evaluarea în acest moment. Este indicat să se facă selecţia cât 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 următoare:

- Selectarea interfeţelor software. Este posibil să cerem furnizorilor de tehnologii să prezinte un prototip de depozit de date pentru a-l evalua. Rezultatul evaluării ne va folosi în selectarea interfeţelor: produse OLAP, generatoare etc.

- Corectitudinea schemei de date. Echipa crează un prototip bazat pe o anumită schemă şi apoi se pot lansa interogări sau realiza rapoarte de probă pe baza datelor reale din sistemele sursă. Dacă cerinţele utilizatorilor, în termeni de interogări, pot fi îndeplinite folosind schema proiectată, atunci echipa poate valida această schemă.

- Validarea prototipului. Echipa de dezvoltatori va invita reprezentanţii utilizatorilor să folosească efectiv prototipul pentru a-şi formula o părere iniţială. 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ţă declanşază o multitudine de reacţii pozitive şi negative din partea utilizatorilor. Aceste reacţii pot ghida echipa de dezvoltare privind corecţiilor care trebuie făcute. La validarea prototipului, următoarele aspecte trebuie să devină clare pentru utilizatori: obiectivele întâlnirilor, natura şi sursa datelor folosite la validare, aria de cuprindere a prototipului.

2.3. Implementarea depozitelor de date

Întreprinderile, de-a lungul anilor, au căutat diferite soluţii pentru a obţine rapoartele decizionale solicitate de manageri. Unele dintre aceste soluţii necesită doar programe simple de extragere a datelor, care sunt executate periodic pentru a obţine datele necesare. Alte soluţii necesită o serie complexă de paşi care combină manipularea manuală a datelor, programe de extragere, formule de conversie.

Definirea ariei de cuprindere

În absenţa unui depozit de date multe dintre cerinţele 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 situaţia în care, în aceeaşi organizaţie, nu există standarde în acest domeniu (de exemplu, persoane diferite aplică formule şi reguli diferite pentru aceleaşi date).Echipa de dezvoltare a depozitului de date trebuie să urmărească în primul rând introducerea standardelor locale sau internaţionale pentru manipularea datelor. În acest sens vor fi vizate următoarele aspecte:

o Date actuale folosite pentru obţinerea 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 câmpuri din aceste sisteme sunt cele mai importante.

o Programele actuale de extragere. Programele de extragere sunt un indiciu valoros pentru realizarea tabelelor sursă-destinaţie. De asemenea, ele oferă informaţii valoroase referitoare la formulele şi regulile de transformare a datelor.

o Transformarea manuală a datelor. În cazul în care există astfel de situaţii, ele trebuie analizate cu grijă pentru a se obţine informaţiile necesare şi pentru a se elimina o parte dintre transformările manuale.

Este posibil ca echipa care planifică depozitul de date să descopere o serie de deficenţe legate de rapoartele care se produc în organizaţie. Nu este nimic neobişnuit să fie descoperite inconsistenţe referitoare la folosirea unor termeni, formule de calcul sau reguli, în funcţie de persoana care creeză sau citeşte 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 regăsesc în sistemele sursă. Limitările impuse de datele disponibile sunt de următoarele tipuri:- Secvenţe de date care lipsesc. O secvenţă de date este considerată lipsă dacă nu există nici un sistem sursă care să fie prevăzut 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 tranzacţiilor, î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 când va dori să-şi analizeze gradul de expunere la risc în funcţie de sectorul economic finanţat, deoarece nu va putea genera un raport detaliat pe această temă.- Secvenţe de date incomplete sau opţionale. Există cazuri când o secvenţă de date este clasificată cu termenul de reţinut, însă nu există reguli care să precizeze clar că acea secventă trebuie să fie colectată şi stocată sau nu. Aşa se ajunge în situaţia că astfel de secvenţe de date sunt înregistrate doar pentru o parte din clienţi, produse, perioade de timp. Atunci când se doreşte 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 câmp numit stare_client, dar dezvoltatorii aplicaţiei l-au prevăzut ca fiind un câmp opţional. Astfel, doar o parte a raportului anterior poate fi realizată şi anume doar pentru clienţii pentru care s-au înregistrat valorile pentru acel câmp.- Date eronate. Pot apărea date eronate când acestea sunt stocate în unul sau mai multe surse de date, din una dintre următoarele 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 limitările impuse de datele din sistemele sursă curente. Cele mai multe proiecte DD se limitează doar la ceea ce oferă sistemele sursă. Trebuie să luăm în considerare şi varianta îmbunătăţirii sistemelor sursă în paralel cu desfăşurarea proiectului DD. Echipa de dezvoltare trebuie să documenteze toate limitările impuse de sistemele curente, iar această documentaţie va deveni intrare pentru procesul de ameliorare.

Un raport de auditare a sistemelor sursă trebuie să aibă următoarele componente:o Lista sintetică a sistemelor sursă. Această secţiune trebuie să listeze toate sistemele

operaţionale cuprinse în operaţiunea de audit. Sunt oferite descrieri generale ale funcţionalităţilor şi ale datelor fiecărui sistem operaţional, precum şi o listă cu entităţile cele mai importante, precum şi a câmpurilor esenţiale. De asemenea, se pot menţiona şi utilizatorii actuali ai sistemelor analizate.

o Secvenţe de date care lipsesc. În această secţiune sunt evidenţiate datele care ar fi necesare în cadrul depozitului de date, dar nu sunt disponibile în sistemele sursă. Trebuie oferite explicaţii în legătură cu importanţa datelor care lipsesc şi modul cum pot fi ele obţinute.

o Ameliorarea calităţii datelor. Pentru fiecare sistem operaţional, trebuie evidenţiate toate zonele în care poate fi îmbunătăţită calitatea datelor şi cum anume.

o Estimarea resurselor şi a efortului. Pentru fiecare sistem operaţional, se poate preciza un cost estimativ şi durata de timp necesară pentru a adăuga datele lipsă sau pentru a îmbunătăţi calitatea.

Concluzie. Planificarea depozitului de date are ca scop definirea clară a ariei de cuprindere a fiecărui modul din depozit. Combinaţia dintre abordările top-down şi bottom-up oferă procesului de planificare avantajul de a vedea problema din două perspective complementare: cerinţele 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 schiţeze un plan de implementare pentru versiunea curentă.

Atunci când se crează planul de implementare trebuie să avem în vedere următorii factori:- Numărul sistemelor sursă şi mecanismele specifice de extragere a datelor. Cu cât sunt mai multe sisteme sursă, cu atât procesele de extragere şi integrare sunt mai comlexe.- Numărul de procese decizionale asistate. Cu cât sunt asistate mai multe procese decizionale, cu atât va fi mai mare numărul utilizatorilor care vor avea o părere în privinţa depozitului de date referitoare la definiţii de termeni, reguli care trebuie respectate etc.- Numărul de subiecte reţinute în depozitul de date. Unul dintre atuurile tehnologiei depozitelor de date este că se orientează pe subiecte. Cu cât va fi mai mare numărul

subiectelor avute în vedere, cu atât va creşte complexitatea versiunii, datorită numărului sporit de tabele de fapte.- Dimensiunea estimată a volumului de date. Această mărime furnizează o estimare preliminară a efortului de încărcare, indexare şi modificare a depozitului de date. Volumul de date permite echipei de dezvoltare să aprecieze durata de încărcare a depozitului (numărul de înregistrări ponderat cu durata necesară pentru încărcarea unei înregistrări).- Disponibilitatea şi calitatea documentaţiei sistemelor sursă. În cazul în care aceste documentaţii există şi sunt actualizate, munca echipei de dezvoltare va fi mult uşurată.- Rata de încărcare a depozitului de date. Această valoare este impusă de cerinţele utilizatorilor (cât 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 săptămână, necesită o arhitectură care este complet diferită de unul care trebuie să fie disponibil doar 12 ore, timp de patru zile pe săptămână.- Participarea şi sprijinul compartimentului IT. Dacă se poate conta pe sprijinul real al compartimentului IT şi al altor persoane implicate, atunci planul implementării 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 activităţi legate de implementarea fiecărei versiuni. Activităţile sunt organizate pe baza rezultatealor etapei de planificare a depozitului de date.

Echipa de implementare construieşte sau extinde o schemă existentă a depozitului de date bazată pe proiectul schemei produse în timpul planificării. Echipa construieşte de asemenea subsistemele DD care asigură un flux constant de date valide din sistemele operaţionale în depozitul de date. Alţi membrii ai echipei sunt responsabili cu instalarea şi configurarea interfeţelor pentru a permite utilizatorilor accesul la depozitul de date.

Un proiect de implementare trebuie să dureze între trei şi şase luni. Progresul lucrărilor efectuate variază în funcţie de calitatea proiectării depozitului de date, calitatea planului de implementare, de disponibilitatea şi interesul personalului întreprinderii.

Instruirea utilizatorilor şi testarea depozitului de date sunt activităţi care au loc spre finalul proiectului de implementare, înainte de instalarea definitivă. Odată instalat depozitul de date, încep activităţile de gestionare, întreţinere zilnică şi optimizare.

Procesul de implementare propriu-zisă a depozitului de date presupune realizarea următoarelor activităţi: achiziţia şi configurarea mediului de dezvoltare, obţinerea copiilor colecţiilor de date operaţionale, finalizarea proiectării schemei fizice a depozitului de date, construirea sau configurarea subsistemelor de extragere şi transformare, construirea sau configurarea subsistemului pentru calitatea datelor, construirea subsistemului pentru încărcarea depozitului de date.

1. Achiziţia şi configurarea mediului de dezvoltarePrima activitate din procesul de implementare o reprezintă achiziţia şi configurarea mediului de dezvoltare, care cuprinde următoarele aspecte: instalarea componentelor hardware, instalarea sistemului de operare, instalarea şi configurarea motorului pentru baze de date

relaţionale, instalarea produselor de DD, crearea conexiunilor în reţea şi stabilirea drepturilor utilizatorilor.

De obicei, depozitul de date se află pe o maşină care este separată fizic de restul sistemelor operaţionale. În cazul în care depozitul de date este gestionat în manieră relaţională, sistemul relaţional care face acest lucru nu trebuie neapărat să fie acelaşi cu cel existent în sistemele operaţionale. La sfârşitul acestei etape trebuie ca echipa de dezvoltare să aibă la dispoziţie infrastructura necesară pentru a realiza efectiv implementarea.

2. Obţinerea copiilor colecţiilor de date operaţionaleUneori echipa de implementare nu are acces direct la sistemele sursă operaţionale. Acest lucru este posibil mai ales în cadrul proiectelor pilot, unde conexiunea sistemelor operaţionale cu depozitul de date nu a fost încă realizată. De aceea echipa trebuie să intre în posesia copiilor colecţiilor de date operaţionale 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 încărcate pe serverul DD. O modalitate este aceea de a folosi numărarea cazurilor (numărul de clienţi, numărul de conturi, numărul de tranzacţii etc) care sunt comparate cu tabelele iniţiale. Utilitarele pentru verificarea calităţii datelor pot sprijini echipa de dezvoltarea în demersul implementării depozitului de date.

3. Finalizarea proiectării schemei fizice a depozitului de dateDetaliile proiectării logice şi fizice ale depozitului de date din faza de planificare se transpun într-o versiune finală a schemei fizice, avându-se în vedere aspectele specifice ale sistemului de gestiune a bazelor de date, care a fost desemnat pentru depozitul de date.

Aspectele importante sunt următoarele:Proiectarea schemei depozitului de date. Se finalizează proiectarea fizică a tabelelor de fapte şi a tabelelor dimensiune cu câmpurile 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 spaţiu de memorare şi pentru a creşte performanţa interogărilor.Indexarea. Se identifică cea mai potrivită metodă de indexare pentru tabelele şi câmpurile depozitului de date, în funcţie de dimensiunea estimată a volumului de date şi de natura anticipată a interogărilor ce se vor efectua asupra depozitului de date.Parţionarea. Administratorul depozitului de date poate opta între partiţionarea tabelelor de fapte şi de dimensiuni, în funcţie de mărimea lor şi de posibilităţile de partiţionare care sunt suportate de motorul de baze de date. Decizia de partiţionare trebuie de asemenea să aibă în vedere că un depozit de date partiţionat este mai uşor de gestionat, însă performanţa interogărilor scade.

4. Construirea sau configurarea subsistemelor de extragere şi transformareSubsistemele de transformare şi extragere trebuie să filtreze şi să încarce datele din sistemul operaţional în depozitul de date, apoi să le pună la dispoziţia utilizatorilor. Aceaste activităţi nu pot fi automatizate total, deoarece diferă de la o organizaţie la alta în funcţie de sistemele sursă, mediul de dezvoltare şi de cerinţele utilizatorilor.

Subsistemul de extragere se referă la procesul de obţinere a datelor necesare din colecţiile de date ale sistemului operaţional, care pot fi cele originale sau doar copii încărcate pe serverul DD.Extragerea se poate realiza printr-o varietate de mecanisme, de la instrumente sofisticate puse la dispoziţie de către producătorii software până la programe realizate de personalul propriu. Interfeţele oferite de diverşii producători sunt capabile să documenteze procesul de extragere prin generarea metadatelor specifice. Dezavantajul acestora este determinat de preţul prea mare. De aceea, organizaţiile preferă deseori să-şi dezvolte propriile lor aplicaţii de extragre a datelor. Această soluţie este viabilă în măsura în care sistemele sursă sunt într-un mediu omogen. Aplicaţiile pentru extragerea datelor dezvoltate în cadrul organizaţiei au dezavantajul că sunt greu de întreţinut, deoarece există tendinţa ca ele să nu fie documentate la momentul dezvoltării 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 câteva tipuri de transformări:- Schimbarea formatului. Fiecare dintre câmpurile utilizate în sistemele operaţionale pot stoca date în diverse formaturi şi tipuri. Aceste secvenţe individuale de date sunt modificate în impul procesului de transformare pentru a respecta setul standard de formate din depozitul de date.- Redundanţa datelor. Înregistrările din mai multe surse sunt comparate pentru a identifica înregistrările duplicat bazate pe valoarea câmpurilor cheie. Duplicatele sunt eliminate pentru a crea o singură înregistrare pentru un client, un produs, un angajat sau o tranzacţie. Duplicatele de tip excepţie pot fi rezolvate manual prin folosirea unui sistem de avertizare. Tot manual se vor rezolva şi înregistrările duplicat cu valori conflictuale în cazul în care nu există mecanisme clare pentru stabilirea valorilor corecte.- Partiţionarea câmpurilor. Uneori este necesar ca o secvenţă de date din sistemul sursă să fie partiţionată în unul sau mai multe câmpuri în depozitul de date. Unul dintre cele mai des întâlnite cazuri de acest gen se referă la adresa clienţilor care în sistemul sursă este memorată într-un singur câmp, în timp ce în depozit va fi memorată pe mai multe câmpuri (stradă, oraş, zonă, regiune, ţară etc).- Integrarea câmpurilor. Integrarea reprezintă operaţiunea inversă partiţionării: două sau mai multe câmpuri din sistemul operaţional vor fi integrate în vederea populării depozitului de date.- Înlocuirea valorilor. Unele valori care sunt folosite în sistemele operaţionale pot să nu fie pe înţelesul utilizatorilor depozitului de date. De exemplu, codurile care au un înţeles specific în sistemul operaţional sunt lipsite de relevanţă pentru manageri. Subsistemul de transformare înlocuieşte valorile originale cu valori noi care sunt utile pentru cei ce folosesc conţinutul depozitului de date.- Derivarea valorilor. Estimările, determinarea de indici şi alte valori derivate pot fi calculate folosind diverse formule. Prin calcularea şi încărcarea acestor valori în depozit, posibilitatea ca utilizatorii să le calculeze greşit este eliminată.- Agregarea valorilor. Agregările pot fi, de asemenea, precalculate înainte de încărcarea lor în depozitul de date. Aceasta este o alternativă la încărcarea doar a valorilor atomice în depozitul de date.

5. Construirea subsistemului pentru calitatea datelorProbleme legate de calitatea datelor nu sunt întotdeauna vizibile încă de la începutul proiectului de implementare, deoarece atenţia echipei este focalizată pe mutarea unor volume mari de date şi mai puţin pe analizarea fiecărei secvenţe de date în parte. În orice caz, pe

măsura evoluţiei implementării, calitatea datelor va deveni o problemă din ce în ce mai stringentă.

Una dintre cauzele care determină împotrivirea utilizatorilor în privinţa depozitului de date o constituie tocmai slaba calitate a datelor. De asemenea, foarte importantă este şi percepţia pe care o au utilizatorii despre date. Aceştia vor folosi depozitul de date doar în măsura î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. Înţelegerea cauzelor care determină erori în cadrul datelor face mai uşoară 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 următoarele cauze:- Valori lipsă. Valorile lipsesc din sistemele sursă, din cauza înregistrărilor incomplete sau a câmpurilor opţionale care nu sunt completate.- Integritatea referenţială slabă. Uneori, integritatea referenţială 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 încărcarea lor, ca parte a procesului de transformare, dacă formulele sau calculele sunt greşite, atunci depozitul va conţine date eronate.- Unităţi de măsură diferite. Folosirea diferitelor unităţi de măsură pentru diverse atribute (valoare, cantitate, volum, timp etc.) poate duce la erori în depozitul de date dacă nu se efectuează în prealabil transformări la o măsură unitară.- Obţinerea duplicatelor. Deduplicarea datelor trebuie să aibă loc înainte de încărcarea lor în depozitul de date. În cazul în care această operaţiune nu se desfăşoară corect, există riscul ca în depozit să apară valori duplicate, generatoare de inconsistenţe şi erori.- Partiţionarea câmpurilor. Există cazuri în care un singur câmp din sistemul operaţional trebuie partiţionat în mai multe câmpuri în depozitul de date. Din păcate volumul mare de date necesită apelarea la proceduri automate de partiţionare a câmpurilor, care pot să nu funcţioneze corect în toate cazurile.- Ierarhii multiple. Multe dintre dimensiunile depozitului de date vor avea ierarhii multiple determinate de necesităţile de analiză. De exemplu, dimensiunea timp poate avea o ierarhie zi-lună-trimestru-an, precum şi ierarhiile zi-săptămână şi zi-lunăfiscală-trimestrufiscal-anfiscal. Neînţelegerea semnificaţiilor acestor ierarhii multiple din diferite dimensiuni poate cauza încărcări eronate în depozitul de date.- Termeni şi reguli conflictuale. Regulile sau termenii conflictuali pot determina planificatorii depozitului de date să încarce două secvenţe diferite de date în acelaşi câmp al depozitului sau, invers, aceeaşi secvenţă în două câmpuri diferite.

Calitatea datelor din cadrul organizaţiei poate fi ameliorată prin mai multe modalităţi:o Evaluarea calităţii datelor. Trebuie determinată mai întâi 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 priorităţi, iar efortul de ameliorare poate fi direcţionat în mod eficient către zona de cel mai mare interes.

o Definirea modului de filtrare şi îmbunătăţire a datelor. Pentru fiecare secvenţă de date cu importanţă mare pentru întreprindere, trebuie stabilită o tactică specifică de ameliorarea a calităţii. Atunci când este posibil, filtrarea datelor trebuie să se focalizeze în primul rând asupra sistemelor sursă, astfel incât să se elimine posibilitatea propagării lor în depozitul de date.

o Prevenirea erorilor. Efortul întreprinderii nu trebuie să se limiteze doar la corecţii asupra datelor deja existente, ci doar să aibă în vedere prevenirea apariţiei erorilor. Dacă sistemele operaţionale care generează date eronate nu sunt revizuite, ele vor continua să fie o sursă sigură de erori pentru depozite.

Având î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, oricât de mari ar fi eforturile de ameliorare a calităţii, întreprinderea trebuie să fie oricând pregătită pentru a aborda noi probleme referitoare la acest aspect.Toate erorile descoperite ar trebui să fie corectate la sursă, ceea ce înseamnă că sistemele operaţionale trebuie să fie modificate astfel încât să conţină valorile corecte. Acestă practică asigură că atât utilizatorii sistemelor operaţionale, cât ş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 atât din cauza responsabilităţilor operaţionale, cât şi din cauza faptului că datele corecte nu sunt cunoscute. Responsabilitatea pentru corectarea datelor din sistelele sursă revine personalului operaţional 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 situaţii în care să nu poată fi determinate valorile corecte din cauza imposibilităţii obţinerii lor.

6. Construirea subsistemului pentru încărcarea depozitului de dateSubsistemul pentru încărcarea depozitului de date preia schema generată de subsistemul de extragere şi transformare şi încarcă datele direct în depozit. După cum s-a menţionat anterior, datele care vor fi încărcate sunt stocate în colecţii de date care au aceeaşi schemă ca şi depozitul de date.

Subsistemul de încărcare a datelor în depozitul de date trebuie să fie apt să furnizeze următoarele facilităţi:- Încărcarea înregistrărilor în tabelele dimensiune. În sistemele sursă, fiecare înregistrare referitoare la un client, un produs sau o tranzacţie este identificată în mod unic printr-o cheie. De asemenea, aceste entităţi trebuie identificate în depozitul de date tot printr-o cheie. Cheile din sistemele sursă sunt deseori nepotrivite ca chei pentru depozit, astfel încât apare necesitatea generării lor în timpul procesului de încărcare.- Încărcarea înregistrărilor în tabelele de fapte. Cheia primară în tabela de fapte este în realitate o concatenare a cheilor din tabelele dimensiune cu care sunt în legătură. Înregistrările din tabelele dimensiune se încarcă înainte de cele din tabelele de fapte pentru a se putea realiza integritatea referenţială.- Calcularea valorilor agregate pe baza înregistrărilor sursă. După înărcarea valorilor atomice în depozitul de date, subsistemul de încărcare trebuie să fie capabil să calculeze şi să stocheze şi valori agregate.- Reindexările. După ce toate datele s-au încărcat cu succes, indecşii din tabelele cele mai importante trebuie refăcuţi pentru a creşte performanţa interogărilor.- Prezentarea unui sistem de control. Acest sistem trebuie să furnizeze echipei de implementare informaţii referitoare la modul în care s-a desfăşurat operaţiunea de încărcare: prezentarea paşilor şi a erorilor care au apărut în timpul fiecărui pas (de exemplu, erori cu privire la integritatea referenţială).

Există discuţii dacă datele inconsistente trebuie sau nu să fie încărcate în depozitul de date. Unele echipe de dezvoltare preferă să încarce doar date corecte în depozitul de date, argumentând că datele inconsistente sunt generatoare de erori. Alte echipe preferă să încarce

ambele categorii de date, cu condiţia ca datele inconsistente să fie marcate distinct. Dacă mai mult de 20% din date sunt incorecte şi doar 80% sunt încărcate în depozitul de date, utilizatorii depozitului de date vor lua decizii bazate pe o imagine incompletă. Probabil că mulţi ar considera necuprinderea datelor inconsistente ca pe un lucru absolut normal, însă sunt cazuri în care ar fi de preferat ca ele să fie încărcate în depozit.

Decidenţii trebuie să aibă datele la dispoziţie 24 de ore pe zi, însă procesul de încărcare a depozitului de date blochează accesul pe durata desfăşurării lui. Cea mai mare provocare în construirea unui sistem de încărcare o constituie optimizarea operaţiunii de încărcare astfel încât ea să blocheze cât mai puţin 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 calităţii datelor, încărcare). În acest sens, el trebuie să efectueze următoarele activităţi:- 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 indecşilor. Indecşii vor fi construiţi în tabele în concordanţă cu schema fizică a depozitului de date.- Popularea DD. După definirea schemei tabelelor şi precizarea indecşilor se trece la încărcarea datelor. Trebuie avute în vedere şi tabelele create pentru a gestiona excepţii, de genul celei prezentate în legătură cu restricţia referenţială.

Metadatele din depozitul de date

Metadatele se definesc ca fiind informaţii despre date. Această definiţie nu este percepută corect de obicei de cei ce încearcă să o înţeleagă şi de aceea poate ar fi mai potrivit să remarcăm că metadatele descriu conţinutul depozitului de date, indicând de unde provin datele originale şi documentând regulile care guvernează transformarea datelor. Interfeţele DD folosesc metadatele şi pentru automatizarea unor etape din ciclul de viaţă al dezvoltării 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 acceptării depozitului de date de către utilizatori.Achiziţia şi instalarea interfeţelor de acces. Echipa care are ca responsabilitate implementarea componentei de acces trebuie să instaleze interfeţele selectate mai întâi pe o maşină test care are acces la depozitul de date. În acest fel, dezvoltatorii pot descoperi o serie de probleme legate de funcţionarea interfeţelor.Construirea rapoartelor şi a interogărilor predefinite. Prototipul dezvoltat iniţial este rafinat în timpul dezvoltării depozitului de date prin încorporarea unor elemente furnizate de reacţia (feed-back) utilizatorilor şi prin construirea unor rapoarte şi interogări predefinite de care au

nevoie decidenţii. Interfeţele au diverse opţiuni legate de rapoarte şi interogări, astfel încât echipa de dezvoltare trebuie să selecteze varianta optimă.Stabilirea profilurilor utilizator. În sistemul de gestiune a depozitului de date, trebuie neapărat definite roluri şi profiluri de utilizatori pentru a stabili corect drepturile de acces. Se recomandă definirea cel puţin a următoarelor roluri:

- Utilizator depozit de date. Utilizatorul obişnuit al depozitului de date are drepturi de vizualizare şi interogare asupra tabelelor din depozitul de date. Nu sunt permise actualizări.

- Administrator depozit de date. Acest rol este atribuit pentru utilizatorii care trebuie să poată efectua orice fel de operaţii 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.

Încărcarea depozitului de date

La anumite intervale de timp, datele din DD se împrospătează prin încărcare. Încărcarea 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 încărcărilor parţiale pentru a putea estima timpul total necesar pentru această operaţiune. Dacă utilizatorii au nevoie pentru analize de datele cele mai recente, atunci depozitul de date nu este soluţia 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 sfârşitul săptămânii.

Instruirea utilizatorilor

Instruirea pe tema depozitului de date care va fi implementat în curând în întreprindere este absolut necesară pentru toţi utilizatorii.

Aria de cuprindere a instruirii utilizatorilor. Instruirea trebuie să aibă în vedere toţi utilizatorii care vor intra în contact cu depozitul de date şi trebuie acoperite următoarele aspecte:

o Definirea depozitului de date. Oamenii au aşteptări diferite în ceea ce priveşte depozitul de date. Instruirea trebuie să înceapă neapărat cu definirea depozitului.

o Aria de cuprindere a depozitului de date. Toţi utilizatorii trebuie să cunoască conţinutul depozitului de date. Instruirea trebuie să evidenţieze clar ce poate şi ce nu poate să facă depozitul de date.

o Folosirea interfeţelor. Utilizatorii trebuie să inveţe cum să folosească fiecare instrument în parte.

o Intervalul de încărcare. Utilizatorii vor fi informaţi cu privire la intervalul de încărcare a datelor şi la datele care suntîncărcate.

o Aflarea răspunsurilor la alte întrebări. Utilizatorii vor fi informaţi cum să obţină diverse informaţii despre folosirea depozitului de date.

Instruirea categoriilor de utilizatori. Instruirea trebuie să cuprindă pe acei utilizatori care vor avea contact cu funcţionalităţile depozitului de date. Trebuie avut însă în vedere că utilizatorii diferiţi au necesităţi diferite. Dacă numărul lor este mare, atunci ei pot fi împărţiţi în două grupuri – începători şi avansaţi. Avansaţii se vor plictisi în cazul în care li se prezintă noţiuni de bază, în timp ce începătorii vor fi depăşiţi de situaţie dacă se trece direct la chestiuni de fineţe. Instruirea este de fapt pasul premergător al testării, deoarece utilizatorii nu vor putea testa corect depozitul de date până când nu sunt instruiţi cu privire la conţinutul lui şi la regulile care îl guvernează.

Testarea depozitului de date

Pentru testarea depozitului de date se va face apel la reprezentanţii utilizatorilor avându-se în obiectiv următoarele aspecte:- Interogările. Utilizatorii vor testa corectitudinea rapoartelor şi interogărilor obţinute din depozitul de date. De regulă, validarea rapoartelor generate din depozitul de date se face construind manual sau prin mecanismele existente acelaşi raport şi comparând cele două rezultate. Eventualele discrepanţe sunt reţinute şi se vor efectua corecţiile care se impun. Echipa nu trebuie să omită şi varianta ca eroarea să provină de fapt din sistemul manual de obţinere a raportului.- Performanţa. Ideal ar fi ca fiecare interogare lansată asupra depozitului de date să se execute instantaneu, însă în lumea reală valoarea acestui indicator depinde de mărimea depozitului de date, de numărul de utilizatori şi de capacitatea reţelei. O metodă de a ameliora acest indicator este cea a folosirii valorilor agregate precalculate.- Răspuns pe durate specificate. Depozitul de date trebuie să fie capabil să furnizeze rapoarte pe intervalul specificat de utilizatori (zi, săptămână, lună, trimestru,an).

Depozitul de date este acceptat doar după ce testele s-au terminat cu succes şi utilizatorii s-au declarat mulţumiţi de el. Pot fi stabilite anumite criterii de acceptare înainte de începerea implementării, iar acceptul va fi obţinut dacă sunt îndeplinite aceste criterii.

2.4. Exploatarea depozitelor de date

Activităţii de implementare a depozitului de date îi urmează întreţinerea şi dezvoltarea depozitului. Acest lucru implică o serie de activităţi specifice, derulate în momente diferite de timp.

1. Încărcarea periodică a depozitului de dateNoi date trebuie încărcate î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 legătură directă cu structura dimensiunii ierarhiei timp. Operaţiunile de încărcare a datelor se desfăşoară, de regulă, după încheierea programului de muncă, seara sau noaptea, atunci când sistemele operaţionale nu sunt folosite. În timpul fiecărei încărcări a depozitului trebuie parcurse toate etapele procesului final (back-end): extragerea, transformarea, asigurarea calităţii şi încărcarea efectivă a datelor. Încărcarea depozitului cu date noi presupune şi necesitatea calculării şi populării tabelelor de agregări cu noi înregistrări.

2. Calcularea indicatorilor statistici referitori la depozitul de date

Evoluţia şi întreţinerea depozitului de date poate fi urmărită 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 folosiţi sunt următorii:

o Numărul de interogări efectuate într-o zi. Acest indicator exprimă numărul de interogări efectuate asupra datelor din depozit şi poate fi calculat pe diferite niveluri de complexitate şi detaliere. Numărul de interogări efectuate asupra tabelelor care conţin valori agregate indică, de asemenea, utilizarea agregărilor stocate.

o Timpul mediu de răspuns la interogări. Acest indicator exprimă timpul necesar pentru a obţine rezultatul din momentul în care a fost lansată interogarea în execuţie.

o Numărul de excepţii pe zi. Indicatorul caracterizează numărul de atenţionări şi de excepţii (erori) generate de depozitul de date, în cazul în care există încorporat un sistem pentru aşa ceva.

o Numărul de utilizatori. Indică numărul total de utilizatori care au acces la datele conţinute în depozit.

o Numărul zilnic de utilizatori. Indică numărul zilnic de utilizatori care folosesc efectiv avantajele oferite de depozitul de date.

o Frecvenţa utilizării. Acest indicator este foarte important, deoarece evidenţiază numărul de accesări ale depozitului de către un utilizator într-o anumită perioadă de timp, sugerând astfel gradul în care depozitul de date sprijină utilizatorul în activităţile de zi cu zi.

o Durata medie a sesiunii de lucru. Exprimă perioada de timp în care utilizatorul rămâne conectat la depozitul de date.

o Intervalele de utilizare maximă a depozitului de date. Se are în vedere perioada din zi, ziua din săptămână, săptămâna din lună, etc. în care numărul de interogări 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 către utilizatori, putându-se lua măsuri pentru optimizarea acestor zone, precum şi subiectele care nu prezintă interes şi care pot fi eliminate.

o Mărimea depozitului de date. După fiecare încărcare a depozitului de date, se determină numărul de înregistrări din fiecare colecţie de date pentru a obţine rata de creştere a depozitului de date.

3. Menţinerea calităţii datelorCalitatea datelor este un aspect care trebuie să preocupe organizaţia şi după implementarea depozitului de date. Problema principală constă în modul în care sunt abordate erorile care apar în legătură cu funcţionarea depozitului de date. Două alternative referitoare la calitatea datelor trebuie luate în considerare: încărcarea în depozit numai a datelor corecte sau încărcarea tuturor datelor şi efectuarea corecţiilor pe parcurs.

În primă abordare, doar datele care sunt corecte sunt încărcate în depozitul de date. În felul acesta utilizatorii sunt siguri că depozitul conţine 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 până ce s-ar efectua o nouă încărcare a depozitului. De asemenea, rezultatele multor interogări (de exemplu: care sunt primii 10 clienţi sau care sunt cele mai bine vândute produse?) nu vor fi relevante în cazul in care depozitul de date este incomplet.

A doua abordare presupune ca toate datele să fie încărcate în depozit, dar sunt definite şi implementate mecanisme pentru identificarea şi corectarea erorilor. Deşi acastă abordare permite încărcarea depozitului cu toate datele din sistemele operaţionale, calitatea datelor poate fi necorespunzătoare, iar deciziile care se iau pe baza lor pot fi inadecvate.

Notă. Ori de câte ori este posibil, trebuie să se meargă pe varianta corectării datelor în sistemele operaţionale astfel încât la următoarea încărcare a depozitului utilizatorii să beneficieze de avantajul datelor corecte.

4. Evaluarea mărimii depozitului de dateÎncărcarea iniţială a depozitului de date poate să nu ridice probleme referitoare la capacitatea de memorare, dar pe măsura trecerii timpului depozitul poate creşte cu fiecare nouă operaţiune de încărcare, iar gestiunea creşterii volumului de date va căpăta o importanţă deosebită. Există câteva modalităţi clasice de gestionare a creşterii volumului datelor: agregările stocate, limitarea perioadei de timp, ştergerea datelor nefolosite.

Folosirea agregărilor stocate reduce semnificativ spaţiul 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 obţine detalieri ale agregărilor.

Deşi 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 păstrat în depozit.

Prin folosirea rezultatelor indicatorilor statistici referitori la depozitul de date, pot fi identificate datele care nu sunt folosite de către 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 măsura trecerii timpului, tot mai mulţi utilizatori din organizaţie vor deveni dependenţi de conţinutul depozitului de date şi astfel recuperarea datelor capătă o importanţă deosebită.Anumite accidente pot necesita reinstalarea sistemelor de operare şi a sistemelor de gestiune a bazelor de date, precum şi reîncărcarea depozitului de date şi popularea tabelelor care conţin agregări. Procedurile de recuperare trebuie să prevadă toate situaţiile neplăcute care pot apărea.

Capitolul 3 Oracle DISCOVERER

3.1. Oracle Business Intelligence(BI) Discoverer - fundamentele

3.2. Componentele Oracle BI Discoverer

3.3. Oracle Discoverer Plus - aspecte relaţionale

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 informaţii din baza de date. Aceştia, atât

la nivel de conducere cât şi la nivel operaţional, 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 relaţională sau multidimensională.

Interfaţa 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 soluţie integrată şi completă de Inteligenţa Afacerii.

Din punctul de vedere al tehnologiei utilizate, OracleBI Discoverer este un produs puternic,

intuitiv, care permite:

- regăsirea datelor dintr-o bază de date relaţională sau multidimensională;

- accesarea datele rapid şi eficient, fără a fi nevoie de o căutare în toata baza de date;

- vizualizarea datele într-un format acceptat de utilizatori: prietenos, familiar, uşor

de citit, uşor de înţeles, flexibil;

- analiza complexă a datelor utilizând o mare varietate de tehnici:

o operaţii atât de detaliu (drill down) cât şi de sinteză (roll up);

o căutarea datelor care îndeplinesc tot felul de condiţii, de la simple la

complexe;

o ordonarea datelor după diferite chei simple sau compuse.

- construirea rapoartelor de diferite tipuri şi afişarea lor;

- partajarea datelor între diferiţi utilizatori sau între diferite aplicaţii informatice care

rulează sub diferite sisteme (exemplu sub Microsoft Excel).

Notă. De exemplu, se poate folosi OracleBI Discoverer pentru analiza datelor având ca

rezultat o colecţie de foi de calcul (worksheet). Fiecare foaie de calcul va conţine informaţii şi

grafice provenite BD ca urmare a unei interogări.

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 relaţionale şi multidimensionale folosind Internetul (D Plus);

- analiza date din surse de date relaţionale şi multidimensionale folosind o aplicaţie

Windows de pe calculator (D Desktop);

- analiza date într-o foaie de calcul existentă (worksheet) (D Viewer sau D portlets);

- vizualiza date ca măsură în tabloul de bord (D Portlet Provider şi D portlets);

- gestiona datele din DD (D Administrator).

Oracle BI Discoverer Plus poate rula atât pe Internet cât şi pe Intranet şi oferă posibilitatea:

o să se creeze foi de calcul (worksheet) şi grafice în care se aduc din DD informaţiile

dorite, sub forma dorită;

o să se analizeze datele regăsite din DD;

o să se partajeze datele cu alţi utilizatori.

Oracle BI Discoverer Viewer poate rula atât pe Internet cât ş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: repoziţionând componentele) si apoi salvarea

schimbărilor efectuate.

OracleBI Discoverer Desktop este o aplicatie tip Windows care oferă posibilitatea dezvoltării

de noi foi de calcul (worksheet) pentru analiza datelor relaţionale. 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 aplicaţie de tip Windows folosită de către

administrator pentru a realiza şi menţine o viziune de afaceri a datelor relaţionale.

OracleBI Discoverer End User Layer (EUL) este un dicţionar/catalog utilizat pentru a salva şi

a restaura definiţia obiectelor folosite la interogarea datelor relaţionale.

OracleBI Discoverer Catalog este un dicţionar/catalog utilizat pentru a salva şi a restaura

definiţia obiectelor utilizator folosite la interogarea datelor multidimensionale.

3.3. Oracle Discoverer Plus - aspecte relaţionale

Discoverer Plus Relational este componenta care oferă posibilitatea de a crea şi analiza foi de

calcul (worksheet). Astfel, se poate regăsi şi analiza date din bazele de date ale companiei fără

a fi nevoie să se înţeleagă structurarea şi complexitatea acesteia.

Alţi utilizatori Discoverer pot deschide foile de calcul partajate cu ei folosind Discoverer Plus

Relational, Discoverer Viewer, Discoverer portals si Discoverer Desktop.

Sursa de date relaţionale este o baza de date în care datele sunt păstrate în mai multe tabele.

Fiecare tabelă conţine un număr de coloane (atribute) şi mai multe rânduri (tupluri). Acest

lucru reprezintă un mod eficient de a stoca şi regăsi datele operaţionale.

De obicei, tabelele din BDR sunt principala sursă de date pentru DD, dar acestea pot deveni

complicate şi greoaie pentru regăsire, atunci când conţin foarte multe înregistrări.

Zona de afaceri (business) este o colecţie de date înrudite care se referă la acelaşi subiect

dintr-o firmă. Administratorul Discoverer lucrează cu diferite departamente dintr-o

organizaţie 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 fiecărei astfel de zone, administratorul

Discoverer organizează datele în dosare. De exemplu, zonele de afaceri importante ale unei

organizaţii poat fi: Vânzări, Producţie, Resurse umane etc.

Administratorul Discoverer decide de asemenea, drepturile de acces ale utilizatorilor la

fiecare zonă de afaceri.

Dosarul/directorul este o colecţie de date înrudite. De exemplu, date despre produsele pe

care organizaţia le comercializează pot fi într-un director (folder) Produse.

Un dosar este, analog cu o bază de date relaţională, asemănător cu o tabelă şi el chiar poate fi

construit dintr-o tabelă.

Diferitele dosare într-o zonă de afaceri pot conţine date relaţionate. De exemplu, o zonă de

afaceri (divizia de vânzări) poate conţine două dosare:

Produse care conţine date despre fiecare produs: cod produs, denumire produs,

unitate de măsură ;

Vânzări care conţine date despre vânzările pentru fiecare produs: magazinul

unde un anumit produs a fost vândut, preţul cu care a fost vândut, codul

produsului.

Prin interogarea dosarului de Vânzări se pot vedea informaţii despre a anumită tranzacţie.

Dacă vrem să vedem şi denumirea produsul care a fost vândut, nu numai codul acestuia, va

trebui să interogăm şi dosarul Produse.

Administratorul Discoverer poate combina date din mai multe dosare într-unul singur pentru a

face mai uşoară regăsirea datelor dorite. De exemplu, administratorul Discoverer poate crea

un al treilea dosar denumit Produse-Vanzări care conţine: denumirea produsului (din dosarul

Produs) şi preţul care a fost dat pentru acesta (din dosarul Vânzări).

Obiectele (items) sunt date de diferite tipuri din dosare. Un obiect este similar unei coloane,

dacă ne gândim la o bază de date relaţională ş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 măsură şi

atunci dosarul Produse va avea trei obiecte (cod produs, denumire produs, unitate de măsură).

Fiecare obiect va conţine valori individuale, de exemplu, codul produsului poate conţine o

listă de coduri.

Administratorul Discoverer decide care obiecte sunt incluse în dosare bazându-se pe datele

care vor fi analizate.

3.4. Oracle Discoverer Plus - aspecte multidimensionale

Discoverer Plus OLAP ne ajută să accesăm şi să analizăm date multidimensionale din baza de

date a organizaţiei.

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 relaţionale datele sunt organizate în tabele care sunt structurate în

coloane/atribute şi rânduri / 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: relaţional (tabele şi coloane) şi multidimensional (cuburi). Această combinaţie oferă un

acces rapid la datele multidimensionale oferind şi un sumar al datelor relaţionale.

Figura. 10: Tabele şi cuburi în baza de date Oracle

Cubul multidimensional are următoarele componente:

O măsură = numele dat datelor propriu-zise (exemplu: Vânzari, Costuri);

Una sau mai multe dimensiuni = numele dat părţii cubului care clasifică datele

(exemplu: Produs, Zonă geografică şi Timp). Dimensiunile au membri, ierarhii

şi atribute;

Celulele cubului = o valoare măsurată pentru fiecare posibilă combinaţie a

dimensiunilor, reprezentând măsura pentru cub;

Clasificarea datelor = partea din cub care grupează datele (exemplu: produsul,

timpul şi oraşul).

Măsurile reprezintă date care pot fi examinate şi analizate în rezultate sub formă de tabele şi

grafice (exemplu: Vanzări, Cost, Profit).

Dimensiunile se referă la măsuri şi au rolul de a clasifica datele. De exemplu, o măsură a

vânzărilor poate avea produse, timp si zonă geografică ca dimensiuni. Când o măsură are

anumite dimensiuni particulare, se consideră că măsoară aceea dimensiune. De exemplu

Vânzările sunt dimensionate de Produse. Grupul de dimensiuni pentru măsură constituie

dimensionalitatea măsurii. De exemplu dimensionalitatea Vanzărilor sunt Produsele, Timpul

şi Locaţia.

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 legătură ierarhică dintre două sau mai multe dimensiuni.

Membrii dimensiunilor individuale pot fi legaţi unul cu altul în ordine ierarhică. De exemplu

o anumită zi aparţine unei anumite luni, care aparţine unui anumit an. Ierarhia ne ajută să

facem o analiză mai amănunţită şi să avem informaţii detaliate.

O dimensiune poate avea mai mult de o ierarhie. De exemplu, dimensiunea Timp poate avea

ierarhii diferite dacă pentru organizaţie 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ă. Când există mai multe

ierarhii pentru aceiaşi dimensiune, una dintre ierarhii trebuie să fie specificată ca implicită.

Atributul dimensiunii descrie o caracteristică care este împărţită de membrii dimensiunii.

Atributele dimensiunii ne dau posibilitatea selectării datelor pentru anumite caracteristici. De

exemplu, dimensiunea Produse poate avea atributul Culoare care ne dă posibilitatea să căutăm

doar produsele de culoare roşie.