Utilizarea Depozitelor DE Date In Cadrul Unei Organizatii

CUPRINS

=== UTILIZAREA DEPOZITELOR DE DATE ===

CUPRINS

CAPITOLUL I. SOLUTII DE ORGANIZARE A DATELOR ÎN DEPOZITE DE DATE (DATAWAREHOUSES)

Principala modalitate de organizare a datelor în cadrul sistemelor tranzacționale a fost și va rămâne soluția de organizare în baze de date relaționale. Însa, la nivelul de agregare si sinteza cerute de sistemele informatice executive, organizarea datelor în baze de date devine ineficienta din prisma timpului de interogare si a cerințelor de prelucrare crescute. Din acest motiv, dar si datorita facilităților de integrare al surselor neomogene de date, ca soluție de organizare a datelor în cadrul sistemelor informatice executive se impun depozitele de date. Un depozit de date furnizează o sursa integrata si centralizata de date, aparte fata de sistemul tranzacțional, care conține datele esențiale despre activitatea companiei din multitudinea de surse de date existente. Rapoartele obținute pe baza acestor date sunt utilizate ca un instrument de analiza strategic si competitiv, si din acest punct de vedere analizele rapide si corecte pot influenta deciziile privind evoluția organizației pe termen mediu si lung.

O definiție a depozitelor de date formulata de către Consiliul OLAP este următoarea [OLAP95]:“Un depozit de date (datawarehouse) reprezintă o stocare centralizata a datelor detaliate provenite din toate sursele relevante din cadrul unei organizații si permite interogarea dinamica si analiza detaliata a tuturor informațiilor.”

Spre deosebire de sistemele operaționale, structurile de date într-un depozit de date sunt optimizate pentru o regăsire și o analiza rapida. Datele sunt istorice si sunt actualizate la intervale regulate de timp, în funcție de cerințele de raportare.

Definiția lui William Inmonn, cunoscut drept părintele acestui concept este extrem de concisa: “un depozit de date este o colecție de date orientate pe subiecte, integrate, istorice si nevolatile destinata sprijinirii procesului de luare a deciziilor manageriale”

În viziunea lui Ralph Kimball depozitul de date oferă acces la datele organizaționale, datele obținute sunt consistente si pot fi separate și combinate în funcție de fiecare dimensiune sau aspect al afacerii. Depozitul de date include, de asemenea un set de instrumente pentru interogare, analiza și prezentare a informațiilor și reprezintă locul în care sunt publicate datele folosite. Calitatea datelor conținute în depozit reprezintă o premiza pentru reingineria afacerii.

După Barry Devlin un depozit de date înseamnă o stocare a datelor, unitara, completa si consistenta, obținuta dintr-o varietate de surse, disponibila utilizatorilor finali într-un mod ușor perceptibil si utilizabil în contextul afacerii.

Sam Anahory subliniază finalitatea depozitelor de date precizând ca un depozit de date include datele si procesele manageriale care fac informațiile disponibile, permițând managerilor sa ia decizii corect fundamentate. Totodată o serie de firme si-au adus contribuția în definirea, dezvoltarea și popularizarea tehnologiilor de data warehouse precum: IBM, Software AG, Oracle, Microsoft, Prism Solution etc.

Din punctul meu de vedere, un depozit de date reprezintă o modalitate de integrare și organizare a datelor din surse omogene si neomogene, provenite din sisteme tranzacționale dar și din fișiere externe, integrate după anumite criterii, supuse unui proces de extragere, transformare si încărcare, stocate agregat pe nivele ierarhice, destinate prelucrărilor și analizelor dinamice, fiind soluția optimă de organizare a datelor pentru sistemele informatice suport de decizie și executive.

Volumul mare de date din depozitele de date impune utilizarea unor instrumente și tehnologii speciale de extragere a datelor cum ar fi analiza dinamica multidimensionala, metode statistice de prognoza și metode matematice aplicate unui volum foarte mare de date. Analiza statistica a datelor și extragerea unor cunoștințe aflate în astfel de depozite de date a căpătat denumirea de data mining, sau minerit al datelor, termen a cărui folosire este evidentă. Din volumul foarte mare de date se extrag numai datele relevante pentru suportul decizional, celelalte fiind ignorate sau utilizate în alte scopuri.

Ca volum, un depozit de date este alcătuit din baze de date conținând între 1 si peste 10 terabyte, aceste cifre neavând decât un caracter orientativ. Exista astfel și depozite de date conținând zeci de terabyte. Crearea unui astfel de depozit costă în medie 3-5 milioane $. Din acest cost, o treime o reprezintă serviciile profesionale. O alta treime se cheltuiește pentru software-ul necesar extragerii, prelucrării, depozitarii și analizării datelor, iar ultima treime este destinată sistemelor hardware necesare stocării datelor. De obicei, depozitele de date își dublează dimensiunile în primele 12 până la 18 luni. Aceasta creștere exponențială poate fi pe de o parte semnul sigur al succesului implementării depozitelor dar, pe de alta parte, poate deveni o problemă daca sistemele nu sunt construite de la început suficient de elastice și de deschise.

Din cele de mai sus rezultă importanța deosebită a flexibilității impuse sistemelor care implementează asemenea depozite de date. Aici flexibilitate înseamnă o conectivitate la nivelul întregii organizații, astfel încât servere de baze de date diferite 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 și administrare a sistemului, inclusiv procedurile de salvare – restaurare, precum și păstrarea în tot acest timp a funcționalității sistemului pot deveni operații extrem de dificile dacă trebuie repetate la fiecare adăugare a unor noi servere în sistem.

Pentru a evita aceste probleme, se poate alege o cale de mijloc și se poate opta pentru realizarea unui sub-depozit care să conțină numai datele relevante pentru analiza necesară. Astfel de sub-depozite sunt numite data marts și pot fi făcute să funcționeze pe configurații și cu resurse mai modeste decât depozitele de date într-un timp mult mai scurt.

Un astfel de data mart este un depozit de date specific unui anumit subset de cerințe sau unui anumit departament din cadrul organizației. În timp ce un depozit de date conține datele care pot fi utilizate pentru a răspunde oricărei întrebări privind afacerile unei companii, un data mart conține datele pertinente unui anumit compartiment al companiei.

Conectând împreuna data mart-urile aferente diferitelor compartimente ale companiei, formând astfel o infrastructura specifica, departamentele pot folosi în comun datele lor și se poate crea un depozit de date mai ușor de construit si mai elastic.

Un data mart tipic poate utiliza servere existente, structura informațională existenta (un LAN sau un Intranet) cu mai puțin de 500 GB, costă mai puțin de 1 milion de dolari și se implementează de obicei aproximativ 90 de zile. Companiile de software au început deja să ofere pe piață produsele necesare pentru a construi aceste data marts.

Rolul unui depozit de date este de a oferi o imagine coerenta asupra datelor relative la activitatea unei organizații și a contextului în care acesta acționează. Utilizarea acestei colecții poate consta din extragerea unor rapoarte (la cerere sau cu o anumita periodicitate), extragerea unor date pentru a fi utilizate de aplicațiile de birotica (programe de calcul tabelar, procesoare de text, programe de prezentare, etc.), dar mai ales pentru a fi utilizate de către aplicații specializate de analiza. Acestea au la bază doua categorii de tehnologii de analiza on-line (OLAP – On Line Analytical Processing) aplicații axate pe analiza multidimensionala și tehnologii pentru extragerea cunoștintelor din date (data mining) axate pe descoperirea unor șabloane semnificative în colecții de date.

1.1. CARACTERISTICI ALE ORGANIZARII DATELOR ÎN DEPOZITE DE DATE

Datorită obiectivelor impuse de utilizarea depozitelor de date în analiză se desprind câteva caracteristici mai importante pe care acestea le dețin:

Depozitul de date asigură accesul la datele organizației. Accesul trebuie sa se realizeze într-un timp cât mai scurt, la cerere și să fie performant. Datele într-un depozit de date pot fi separate și combinate pentru a oferi un acces cât mai rapid și un timp de răspuns cât mai mic sistemului. De asemenea, accesul presupune existența unor utilitare care să fie foarte ușor de folosit.

Datele dintr-un depozit de date trebuie să fie consistente. Consistența presupune faptul că atunci când două persoane solicită același set de informații să primească aceleași date, chiar dacă ele au fost cerute la momente de timp diferite. Dacă datele nu au fost complet încărcate atunci utilizatorul va fi avertizat cu privire la acest lucru și este sfătuit să aștepte până ce vor fi complet încărcate.

Datele din depozite sunt utilizate direct în analize, fără alte prelucrări suplimentare. Datele nu sunt doar centralizate, integrate și stocate ci, după ce sunt extrase dintr-o varietate de surse, sunt corectate de erori, transformate, li se asigură calitatea necesară și abia apoi devin utilizabile. Depozitele de date nu reprezintă doar datele ci și un set de utilitare pentru a interoga, analiza și prezenta informațiile.

Calitatea datelor din depozitele de date este un factor determinant pentru procesul de analiza. Se întâlnește frecvent situația în care datele nu sunt de bună calitate sau nu sunt extrase în întregime sau au un caracter incert din punct de vedere al conținutului ceea ce face ca analiza ulterioara să conducă la rezultate eronate. O consecință importantă a acestor caracteristici este redundanța datelor. Dacă în sistemul operațional redundanța este eliminată (prin procesul de normalizare) pentru a evita anomaliile de actualizare, în depozitul de date redundanța este creata în mod intenționat prin denormalizare și agregare pentru a permite un acces mai rapid la date.

Integrarea datelor reprezintă o altă consecința importantă a realizării depozitului de date și, în cele din urmă, rațiunea pentru care acesta este creat. Datele sunt încărcate pentru a răspunde nevoilor informaționale ale întregii organizații, asigurând faptul ca rapoartele generate pentru diverse compartimente vor conține aceleași rezultate. Sistemul operațional este de cele mai multe ori format din subsisteme semi-independente, create la momente diferite, de echipe diferite, în maniere diferite, ceea ce face imposibilă folosirea acestui sistem pentru analiză.

Integrarea datelor provenind din sistemul operațional și din alte surse se referă la diferite aspecte: modalități unice de codificare, sistem de unități de măsura consistent, sistem stabil de reprezentare fizica a datelor, convenții clare privind modul de reprezentare a datelor calendaristice, convenții unice privind denumirile și conținutul acestora.

1.2. ARHITECTURA DEPOZITELOR DE DATE

Arhitectura depozitelor de date poate varia în funcție de situația specifica a fiecărei organizații. În cazul unei arhitecturi de baza, datele sunt încărcate din una sau mai multe surse, iar utilizatorii accesează în mod direct depozitul de date. O arhitectura complexa este structurata pe patru niveluri distincte de realizare a datelor astfel:

Nivelul surselor de date în care se colectează date eterogene provenite din diverse sistemele operaționale ale organizației. De regula se utilizează un proces de integrare a acestor date printr-un modul separat al depozitului de date numit și

modul sursa.

Nivelul transformăriii datelor în care se folosește un proces de extragere, transformare (curățare) și încărcare a datelor (ETL – Extract, Transform, Load) ce presupune prelucrarea datelor din punct de vedere al integrității, preciziei, acurateții și al formatului.

Nivelul depozitului de date conține datele prelucrate, încărcate în structuri multidimensionale și agregate pe diferite niveluri pregătite pentru a fi utilizate în analiză. La acest nivel se pot proiecta multiple sisteme de tipul data mart proiectate pentru compartimente și departamente ale întreprinderii.

Nivelul de prezentare și raportare a datelor presupune extragerea datelor din depozit și utilizarea unor instrumente și tehnologii de inteligența afacerii (Business Intelligence) pentru analiza și interpretarea informațiilor furnizate. La acest nivel se utilizează funcționalitățile OLAP pentru analiza, informațiile fiind prezentate grafic, tabelar, integrate în portaluri etc.

Figura următoare prezintă un sistem complex de datawarehouse:

Figura 1.1: Depozit de date cu arhitectura complexa

Pe aceasta arhitectura din punct de vedere funcțional se regăsesc trei nivele distincte de realizare (fig. 1.2.):

Modulul operațional – reprezentat de datele companiei care sunt de obicei păstrate sub formă diferită la locații diferite. Aceste date pot proveni de la aplicații sau de la sisteme distribuite din cadrul companiilor cum ar fi sisteme de gestiune a

comenzilor, de eliberare a facturilor, de contabilitate financiara, de gestiune a stocurilor, salarizare, etc. Indiferent de originea lor, datele trebuie să fie colectate și aduse într-o formă consistentă pentru a putea fi folosite. Acest proces de transformare a datelor reprezintă baza pe care se construiește un depozit de date consistent, de înaltă calitate. Transformarea datelor presupune un proces de extragere, condiționare, curățare, fuziune, validare și încărcare (ETL).

Modulul central al depozitului de date – reprezentat de SGBD-ul și de serverul pe care acesta rulează și de modul în care este implementat depozitul – există în acest moment două tendințe: una ar fi implementarea unui sistem distribuit, descentralizat unde datele sunt păstrate în unități independente (Independent Data Marts) fiecare conținând datele relevante pentru un anumit aspect al operațiilor unei instituții, iar a doua posibilitate ar fi implementarea unei surse de date unice, centralizate la care au acces utilizatorii din toate departamentele unei instituții.

Modulul strategic, de afaceri – valoarea finala a unui depozit de date este determinata de avantajele pe care le ofera utilizatorului în diferite procese de luare

a deciziilor si analiza. Prin folosirea diferitelor modalitati de acces la informatie si a tehnologiilor de procesare disponibile, utilizatorii pot obtine informatii care îi vor ajuta în procesele de stabilire a strategiei firmei. La ultimul nivel al arhitecturii, datele sunt pregatite pentru interpretare si analiza cu ajutorul instumentelor specifice cum ar fi: instrumente de realizare a graficelor, prezentari, rapoarte dinamice, browsere Web, instrumente de vizualizare a datelor.

Figura 1.2: Modulele funcționale ale unui depozit de date

Arhitectura funcționala a depozitelor de date prezentata mai sus permite proiectarea si implementarea unor diverse tipuri de depozite de date în functie de cerintele de afaceri, resursele disponibile si posibilitățile de realizare. Voi prezenta mai jos o clasificare a acestor tipuri de depozite de date, urmând sa realizez o analiza comparativa a performantelor obținute în urma implementarii acestora la sfârsitul acestui capitol.

Astfel, din punct de vedere al ariei de cuprindere se întâlnesc trei tipuri de depozite de date:

Depozitul central al organizației (Enterprise Warehouse) colecteaza toate informatiile despre subiectele care privesc întreaga organizatie si furnizeaza un volum extins de date. De regula contine date detaliate, dar si date agregate, iar ca ordin de marime porneste de la câtiva gigabytes pâna la sute de gigabytes si terabytes. Un depozit de date de întreprindere trebuie implementat pe servere puternice UNIX sau pe platforme cu arhitecturi paralele. Acest tip de depozit necesita însa cheltuieli si resurse mai mari pentru analiza, proiectare si realizare.

Data mart-ul conține un subset al volumului de date din organizație, specific unui grup de utilizatori sau departament. Domeniul este limitat la subiecte specifice. Datele conținute în data mart sunt de obicei agregate. În mod curent data marts sunt implementate pe servere departamentale cu resurse mai reduse care se bazează pe UNIX sau Windows 2000/2003. Ciclul de implementare al unui data mart este mai curând masurat în saptamâni sau luni dacât în ani. Ca atare, un data mart poate fi considerat un subansamblu al unui depozit de date mai usor de construit si întretinut si mai putin scump.

Depozitul virtual (Virtual warehouse) este un set de tabele virtuale (views) asupra bazelor de date operationale. Pentru eficienta procesarilor interogarilor, numai unele din viziunile de agregare pot fi materializate. Un depozit virtual este usor de construit, dar problema extragerii si prelucrarii datelor revine în mod exclusiv serverului de baze de date, ceea ce poate conduce la un timp de prelucrare mare, însa se elimina necesitatea stocarii datelor într-un depozit real. Aceasta varianta se recomanda a fi aplicata în cazul în care volumul de date necesar este mic, de mii de înregistrari. Insa daca se depaseste acest interval, timpul de extragere a datelor creste semnificativ si recomandabil ar fi sa se combine solutia de depozit virtual cu stocarea datelor agregate separat într-un data mart sau depozit de date real.

O alta clasificare a depozitelor de date este propusa în lucrarea în care se identifica cinci tipuri, în funcție de aria de cuprindere a proceselor decizionale si anume:

Depozitul de date de tip organizational sau “galactic” (galactic datawarehouse – GDW) reprezinta un tip de depozit centralizat, cu o arie de cuprindere extinsa având drept obiectiv integrarea si prelucrarea datelor la toate nivelurile organizatiei, atât la nivelul departamentelor cât si al întregii organizatii;

Depozitul de date orientat pe procese de afacere (business process datawarehouse – BPDW) reprezinta un tip de depozit specializat, orientat pe satisfacerea cerintelor de afaceri si a proceselor de afaceri;

Depozitul de date departamental (departamental datawarehouse – DDW) reprezinta un tip de depozit orientat pe departamente, având drept obiectiv integrarea si prelucrarea datelor din fiecare departament în parte;

Centru de date de tip proces de afaceri (business process data mart – BPDM) reprezinta un tip de depozit specializat, orientat pe satisfacerea unei anumite cerinte de afaceri si a unui singur proces de afaceri;

Centru de date departamental (departamental data mart – DDM) reprezintă un tip de depozit specializat, cu o arie de cuprindere limitata la un anumit departament, având drept obiectiv integrarea si prelucrarea datelor specifice activităților acestuia;

În practica consider ca ar fi recomandabila combinarea acestor tipuri de depozite deoarece nu este indicat sa se proiecteze un data mart pentru fiecare proces de afaceri sau pentru fiecare departament si apoi sa se reuneasca într-un depozit centralizat, fara sa se tina cont si de relațiile interdepartamentale.

Capitolul II. TRECEREA DE LA MODELUL RELATIONAL LA MODELAREA MULTIDIMENSIONALA

Depozitele de date impun condiții de realizare diferite fata de bazele de date relaționale. Dintre aceste diferențe menționez următoarele:

Condiții de utilizare – depozitele de date sunt proiectate pentru analize ad-hoc si rezultatele nu sunt cunoscute dinainte, iar modelul datelor este optimizat pentru a realiza o mare varietate de interogări. In schimb sistemele tranzacționale suporta numai anumite operații pentru care au fost proiectate;

Modificarea datelor – datele din depozite sunt actualizate regulat (de regula saptamânal sau lunar) cu ajutorul procesului de extragere, transformare si încarcare automata (ETL). Utilizatorii finali nu pot modifica (actualiza) direct datele. În sistemele tranzactionale utilizatorii finali sunt cei care actualizeaza datele astfel încât sa se reflecte starea fiecarei tranzactii din întreprindere;

Modelul utilizat – în depozitele de date se foloseste forma denormalizata (cum este schema stea) pentru optimizarea operatiilor, fata de forma normalizata a datelor din modelul relational care optimizeaza operatiile de actualizare/inserare/sterge si garanteaza consistenta datelor;

Operații tipice – o interogare a depozitelor de date poate parcurge mii sau chiar milioane de înregistrari (de exemplu pentru a analiza totalul vânzarilor din luna trecuta pentru toți clienții existenți). In schimb o operație tranzactionala afecteaza o singura înregistrare sau un număr limitat de înregistrari;

Date istorice – în depozitele de date se stocheaza de regula datele istorice din ultimii ani fata de modul de lucru al sistemelor tranzacționale care stochează date pe câteva luni astfel încât sa realizeze tranzacțiile curente cu succes.

O ultima si controversata diferenta între cele doua tipuri de modele este modul de abordare a datelor. Esenta unui model multidimensional de calitate sporita este alegerea unui set de dimensiuni cât mai apropiate de cele naturale si de perspectiva utilizatorului.

Este folositor sa avem o analiza dintr-o perspectiva relaționala a datelor înainte de a incepe analiza dimensionala deoarece echipa de proiectanți a depozitului de date va întelege datele mai bine. Modelul multidimensonal trebuie abordat mai mult din perspectiva utilizatorului decât din cea a datelor.

Tehnica modelarii multidimensionale permite o restructurare a datelor în vederea interogarii lor prin tehnologii de analiza specifica. Nu este usor de transformat un model relational în unul multidimensional, chiar daca modelam aceleasi date. Cele doua abordari cer premise diferite, tehnici diferite si produc baze de date cu structuri diferite.

Modelarea dimensionala produce o baza de date care este mult mai usor de consultat si de interogat la un nivel înalt, sintetic, agregat. De asemenea, modelul dimensional produce o baza de date cu mai putine tabele si chei de administrat decât modelul ER.

Tabelul de mai jos descrie diferentele principale între prelucrarea tranzactionala (modelul relational) si prelurarea analitica (modelul multidimensional):

Tabel 2.1: Paralela între prelucrarea relaționala si cea analitica

2.1. MODELUL DE DATE MULTIDIMENSIONAL

Pentru definirea unui model de date este necesara specificarea urmatoarelor elemente:

Structura modelului constituita din obiectele modelului precum si relatiile dintre ele;

Operatorii care actioneaza asupra structurii;

Restrictiile de integritate formate din totalitatea de regului si constrângeri impuse modelului pentru asigurarea corectitudinii datelor.

Structura modelului contine în principal obiectele referitoare la tabele de fapte că atributele de tip masuri sau metrici, tabelele de tip dimensiune în care regasim nivele ierarhice, attribute de descriere, etc. Aceste obiecte vor fi prezentate în continuare.

În cadrul modelului multidimensional se întâlnesc mai multe tipuri obiecte care prezinta o importanta deosebita în analiza:

Dimensiunile – reprezinta structuri compuse atribute structurate pe diverse niveluri ierarhice în functie de care sunt grupate datele. Aceste atribute sunt de obicei descriptive si sunt folosite ca sursa pentru restricții si pentru rândurile din rapoarte. Sunt considerate tabele secundare datorita dimensiunilor reduse. Consiliul OLAP defineste conceptul de dimensiune ca fiind “un atribut structural al unui cub ce consta dintr-o lista de membrii, pe care utilizatorii îi percepe ca fiind de acelasi tip (de exemplu toate lunile, trimestrele, anii formeaza dimensiunea Timp). Dimensiunile reprezninta un mod foarte concis, intuitiv de organizare si selectare a datelor pentru explorare si analiza.” [OLAP95]. Datele sunt de obicei colectate la nivelul cel mai detaliat si apoi agregate pe nivelele superioare pentru analiza.

In cadrul dimensiunilor se regăsesc si conceptele de ierarhie, nivel, atribut, concepte care vor fi prezentate în continuare:

Ierarhiile – sunt structuri logice utilizate pentru ordonarea nivelelor de reprezentare a datelor. Sunt utilizate si pentru definirea cailor de navigare în interiorul datelor. Nivelele ierarhice sunt utilizate de instrumentele de analiza OLAP permitând detalierea graduala a datelor. Tot în definitiile date de Consiliul OLAP se mentioneaza ca “membrii dimensiunilor pot fi organizati pe baza relatiilor de tip parinte-copil, unde un membru parinte reprezinta agregarea membrilor copil. Rezultatul este o ierarhie si relatiile parinte-copil sunt relatii ierarhice”. [OLAP95] Ierarhia definita pe o dimensiune determina aranjarea membrilor dimensiunii într-o configuratie piramidala. Pe orizontala se plaseaza rezultatele corespunzatoare masurilor de pe acelasi nivel în ierarhia dimensiunii, iar pe verticala se plaseaza rezultatele având niveluri diferite în ierarhia dimensiunii.

Nivelele – reprezinta pozitii în cadrul ierarhiilor (figura 2.1). De exemplu dimensiunea Timp poate avea trei nivele de ierarhizare: an, trimestru si luna. Nivelele se structureaza în functie de ierarhie de la general la specific, radacina fiind reprezentata de nivelul superior, cel mai înalt al ierarhiei. Relatiile între diferite nivele sunt relatii de tipul parinte-copil. Se pot defini ierarhii în care datele fiecarui nivel sunt agregate la un nivel superior sau se pot sari anumite nivele care sunt independente.

Figura 2.1. Ierarhii și nivele

Atribute – dimensiunile contin atribute care reprezinta calificative specifice. Orice

atribut se asociaza unei singure dimensiuni, iar o dimensiune se poate exprima prin mai multe atribute. Cu cât aceste atribute sunt mai descriptive cu atât depozitele de date vor fi mai performante.

Tabelele de fapte – sunt tabelele centrale. Acestea contin atribute de tip masuri (metrici) si chei externe catre tabelele dimensiuni. Faptele sunt de obicei date numerice care pot fi însumate si analizate pe diferite nivele.

Metricile (masurile) corespund atributelor (faptelor) din tabelele de fapte si sunt de regula de natura numerica (de exemplu: volumul vânzarilor, costurile, stocurile

disponibile). Aceste variabile au sens numai în contextul unor anumite dimensiuni. Masurile reprezinta valorile centrale care sunt analizate prin cubul de date. Valoarea masurii este calculata pentru un punct dat prin agregarea datelor corespondente perechii respective valoare-dimensiune, diferite pentru punctul dat. Masurile pot fi clasificate dupa modalitatea de calcul în masuri de baza care se regasesc sub forma atributelor din tabelele de fapte si care provin din sursele de date si masuri derivate (virtuale) care se obtin prin combinarea masurilor de baza si care în tabelele de fapte au precizata formula de calcul prin care se obtin. Masurile pot fi organizate în trei categorii bazate pe tipurile de functii agregate utilizate: distributive, algebrice, holistice.

Masurile distributive – sunt calculate cu ajutorul unor functii de agregare distributive. Presupunem ca datele sunt împartite în n seturi. Calcularea functiei de fiecare partitie determina o valoare agregata. Daca rezultatul obtinut prin aplicarea functiei asupra a n valori agregate este acelasi cu cel obtinut prin aplicarea functiei asupra tuturor datelor fara partitionare, functia poate fi calculata în maniera distributiva. De exemplu, functia count( ) poate fi calculata pentru cubul de date printr-o prima partitionare a cubului într-un set de subcuburi, calculând count( ) pentru fiecare subcub si apoi însumând rezultatele obtinute pentru fiecare subcub. Din acest motiv functia count( ) este o functie agregata distributiva.

Masuri algebrice – sunt calculate cu ajutorul unor functii algebrice cu M argumente (unde M este un întreg pozitiv), fiecare din ele obtinuta prin aplicarea unei functii agregate distributive. De exemplu, AVG( ) poate fi calculata prin sum()/count() unde ambele functii sum( ) si count( ) sunt functii agregate distributive. În mod similar se poate demonstra ca min( ), max( ) si abaterea standard sunt functii algebrice agregate. Masura este algebrica daca este obtinuta prin aplicarea unei functii algebrice agregate.

Masuri holistice – sunt calculate cu ajutorul unor functii holistice. O functie agregata este holistica, daca aceasta nu este limitata constant pe spatiul de stocare cerut de deschiderea subagregarii. În acest caz nu exista o functie algebrica având M argumente (unde M este o constanta) care caracterizeaza calculul. Exemple comune de functii holistice sunt: median( ), mode ( ), rank( ). O masura holistica este obtinuta prin aplicarea unei functii agregate de tip holistic. Cele mai multe aplicatii necesita calcularea eficienta a masurilor distributive si algebrice. Exista mai multe tehnici eficiente pentru aceasta, în contrast, poate fi mai dificil de calculat în mod eficient masuri holistice. Exista totusi anumite tehnici eficiente de aproximare a calculului masurilor holistice. De exemplu, în loc de a calcula exact median( ), exista tehnici care pot determina aproximativ valoarea mediana pentru un set foarte mare de date, cu rezultate satisfacatoare.

Din punctul de vedere al modalitatii de însumare si agregare în functie de dimensiuni, Ralph Kimball în lucrarea “The Data Warehouse Toolkit” clasifica metricile în trei categorii: indicatori aditivi care se pot însuma dupa toate dimensiunile, indicatori semiaditivi care se pot însuma numai dupa unele dimensiuni si indicatori neaditivi care nu se pot însuma dupa nici o dimensiune dar care pot fi combinate cu alte variabile pentru a deveni aditive.

Metadatele – reprezinta poate cea mai importanta componenta a depozitului de date. Pentru a putea utiliza depozitul de date, utilizatorii trebuie sa cunoasca ce date se gasesc aici, iar metadatele nu sunt altceva decât date despre date, date care descriu continutul depozitului si furnizeaza trimiteri directe la date. Tot la nivelul metadatelor se definesc si diverse vederi (views) asociate unor categorii specifice de utilizatori. Dar metadatele nu sunt utile doar utilizatorului final. Ele sunt intens folosite pentru administrarea depozitului de date, continând informatii despre provenienta datelor, algoritmii de agregare si însumare, statistici privind utilizarea si multe altele.

Cand se utilizeaza într-un depozit de date, metadatele sunt date care definesc obiectele depozitului. Metadatele sunt create pentru numele de date si definitiile din depozit. Metadatele aditionale sunt create pentru a asocia intervale de timp la datele extrase si alte câmpuri care vor fi adaugate prin curatirea datelor sau prin procesele de integrare.

Nivelul metadatelor trebuie sa contina conform:

O descriere a structurii datelor din depozit, incluzând schema depozitului, dimensiunile, ierarhiile, definitiile datelor derivate;

Metadatele operationale, care includ date privind evolutia în timp (istoricul datelor si secventa de transformare aplicata asupra lor), situatia datelor (active, arhivate sau sterse) si informatii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erori, împrastierea datelor etc.);

Algoritmi utilizati pentru însumare, care includ masura si dimensiunea algoritmilor definiti, date despre granularitate, partitii, arii de subiecte, agregari, sumarizari, rapoarte si filtre predefinite;

Transformarile datelor de la mediul operational la depozitul de date si care includ bazele de date sursa si continutul lor, partitionarea datelor, extragerea datelor, curatirea datelor, regulile de întretinere si securitate a datelor;

Date relative la performantele sistemului care includ indicatori si profiluri care îmbunatatesc accesul la date si performantele de cautare;

Metadate economice (business metadata), care includ termeni economici si definitii, expresii si formule de calcul ale indicatorilor.

Metadatele se aplica pentru sursele de date, pentru programele si regulile de extragere si transformare, pentru structura datelor si pentru continutul propriu-zis al depozitului de date. Importanta metadatelor pentru depozitul de date reiese din faptul ca acestea stabilesc contextul depozitului de date, usureaza procesul de analiza, mentin si cresc calitatea datelor dar si din faptul ca sunt o forma de auditare a transformarii datelor.

Metadatele ajuta administratorii si utilizatorii depozitului sa localizeze si sa înteleaga secventele de date atât în sistemele sursa cât si în structura depozitului. Daca metadatele care descriu formatul datelor din depozite sunt disponibile, atunci se elimina orice ambiguitate legata de semnificatia datelor. Metadatele mentin si cresc calitatea datelor, fapt ce se realizeaza prin definirea valorilor valide pentru fiecare câmp din depozit. Înainte de a fi efectiv încarcate în depozit, datele pot fi revazute si erorile pot fi corectate, regulile de corectie a erorilor pot fi documentate tot prin metadate. Se pot deosebi mai multe tipuri de metadate:

Metadate administrative. Acestea contin descrieri ale bazelor de date sursa si ale continutului, ale obiectelor depozitului de date si ale regulilor folosite pentru a transforma datele din sistemul sursa în depozit. Printre exemple de astfel de metadate mentionez: descrirea tuturor sursele de date folosite, trecerea câmpurilor sursa în câmpuri destinatie, schema depozitului de date, structura datelor din back-end, programe si instrumente backend, reguli si formule de calcul, reguli de securitate si de acces.

Metadate pentru utilizatorii finali. Aceste metadate au rolul de a ajuta pe utilizatori sa-si creeze propriile lor interogari si sa interpreteze rezultatele. Pentru aceasta, ei au nevoie sa cunoasca definitiile datelor din depozit, descrierea lor, precum si orice ierarhie care poate exista în diferite dimensiuni. Exemple de astfel de metadate sunt urmatoarele: continutul depozitului de date, rapoarte si interogari predefinite, definitiile ierarhiilor, calitatea datelor, istoricul încarcarii depozitului de date, reguli de eliminare.

Metadate pentru optimizare. Aceasta categorie de metadate are rolul de a creste performantele depozitului de date. Exemple de astfel de metadate sunt: definitiile agregarilor si colectii de statistici.

Un depozit de date contine date pentru diferite perioade de timp si de aceea este important sa avem în vedere efectul pe care îl poate avea timpul asupra regulilor de trecere a câmpurilor sursa în câmpuri destinatie, asupra agregarilor etc. Utilizatorii trebuie sa aiba acces la metadatele corecte pentru perioada de timp pe care o studiaza. Echipa IT are nevoie de aceste informatii pentru a putea întretine depozitul de date, iar ceea ce la prima vedere ar parea sa fie o eroare în transformarea datelor poate fi de fapt rezultatul schimbarii regulilor de transformare a datelor. De aceea este important ca metadatele sa fie corect gestionate din punct de vedere al versiunilor.

Desi în mod traditional metadatele reprezinta o componenta dezvoltata spre sfârsitul ciclului de dezvoltare, la ora actuala exista o tendinta puternica de a atribui metadatelor un rol mai important. Utilizatorii instrumentelor de extragere si transformare pot specifica modul de trecere din câmpurile sursa în câmpurile destinatie si pot introduce toate regulile care guverzeaza transformarea. Tabelul sursa-destinatie poate servi ca baza pentru generarea codului de program folosit apoi la extragerea si transformarea efectiva a datelor. Utilizatorii instrumentelor pentru calitatea datelor pot specifica valorile valide pentru diferite secvente de date atât în sistemele sursa, cât si în depozitul de date. Aceste instrumente pot folosi metadatele ca baza de pornire în identificarea si corectarea erorilor.

Utilizatorii specifica metadatele referitoare la schema depozitului de date (fapte, dimensiuni etc), iar aplicatile pot folosi aceste specificatii ca intrare pentru a genera efectiv schema (tabele, indecsi, agregari etc.).

Schema depozitului de date este o colectie de obiecte, incluzând tabelele, viziunile, indecsi si sinonime. Exista mai multe tipuri de scheme utilizate în modelarea multidimensionala acestea diferind de modurile în care se pot aranja obiectele în cadrul schemei.

Schema de tip “Stea“ – Acesta este cel mai simplu si mai frecvent utilizat model (figura 2.2.a). Obiectele sale sunt dispuse în forma de stea, în centru aflându-se una sau mai multe tabele de fapte de care sunt legate dimensiunile. O schema de “jonctiune stea“ suporta doua tipuri de interogari: consultare si jonctiuni multiple. Operatia de consultare se realizeaza pe o singura tabela de fapte si nu necesita jonctiuni. O cerere de interogare tipica apare atunci când un utilizator final solicita o lista derulanta. Interogarile de tip jonctiune multipla apar dupa o serie de consultari si implica restrictii plasate în câteva tabele dimensiune care sunt puse în legatura simultan, prin operatia de jonctiune, cu tabela de fapte. Scopul este de a aduce sute si mii de înregistrari de baza într-un set de raspunsuri de dimensiune mica.

Figura 2.2. a: Schema de joncțiune stea

Dimensiunile în acest caz sunt denormalizate, ele având date redundante care elimina necesitatea unor legaturi multiple între tabele. Într-o schema stea nu exista decât o singura legatura între tabela de fapte si dimensiuni. Optimizarea performantei de raspuns la interogari este principalul avantaj al acestui model.

Schema de tip “Fulg de Nea” – este o varianta a modelului stea în care o parte din tabelele dimensiune sunt normalizate, iar datele sunt distrinuite în tabele suplimentare (figura 2.2. b). Rezulta o schema reprezentata într-un grafic similar unui fulg de zapada.

Diferenta între modelul stea si modelul fulg de nea este ca tabelele dimensiune din acesta pot fi pastrate în forma normalizata, ceea ce determina o redundanta redusa. Asemenea tabele sunt usor de întretinut si astfel se economiseste spatiu de stocare. Totusi aceasta economie de spatiu este neglijabila în comparatie cu volumul foarte mare de date din tabelul de fapte. Mai mult, structura fulg de nea poate reduce performanta extragerii de date deoarece sunt necesare mai multe jonctiuni între tabele la o singura interogare.

Figura 2.2. b: Schema de jonctiune fulg de nea

Cuburi de date – Un mod mai simplu de vizualizare a datelor este reprezentarea într-un spatiu cartezian definit pe toate dimensiunile depozitului de date (figura 2.2.c, 2.2.d). Acesta poate fi numit cub de date, fiind un spatiu de date logic si nu unul fizic. Sectiunile bidimensionale sunt numite tablouri. Axele cubului sunt reprezentate de dimensiuni, la intersectia acestora fiind variabilele sau masurile.

In analiza multidimensionala cubul de date cu mai mult de trei dimensiuni poarta denumirea de cub n-dimensional sau hipercub (hypercub). Consiliul OLAP defineste cubul n-dimensional ca fiind ”un grup de celule de date aranjate dupa dimensiunile datelor. O matrice tridimensionala poate fi vizualizata ca un cub cu fiecare dimensiune formând o fata a cubului” [OLAP95]. Tot în aceeasi definitie se mentioneaza ca dimensiunile tipice ale datelor dintr-o întreprindere sunt timpul, masurile, produsele, regiunile geografice, canalele de distributie.

Figura 2.2.c: Cub de date cu trei dimensiuni

Figura 2.2.d: Cub de date cu patru dimensiuni

2.2. OPERATII REALIZATE ASUPRA MODELULUI MULTIDIMENSIONAL

Aplicatiile de analiza OLAP trebuie sa asigure o utilizatorilor o viziune multidimensionala asupra datelor, indiferent daca modalitatea de stocare este relationala sau multidimensionala. Pentru utilizarea viziunilor multidimensionale nu este necesara o stocare a datelor în aceasta forma. Bazele de date relationale si cele multidimensionale folosesc modele asemanatoare ceea ce permite o trasformare usoara a datelor. Prin aplicarea unor operatii specifice asupra modelului multidimensional utilizatorului i se ofera posibilitatea de a vedea si de a analiza din perspective multiple datele, de a naviga în cadrul ierarhiilor definite, de a extrage un subset de date, de a interschimba axele sau dimensiunile pentru a obtine o alta detaliere a datelor. Toate aceste operatii multidimensionale impementate în cadrul modelului multidimensional sunt prezentate în paragrafele urmatoare.

Navigarea pe nivelele ierarhice (Drill Down si Roll Up) – reprezinta operatii de navigare în cadrul ierarhiilor dimensiunilor, prin agregare pe nivelele superioare sau detaliere pe nivelele inferioare. Orice baza de date multidimensionala trebuie sa permita navigarea pe diferite nivele ale ierarhiilor. Aceasta tehnica se numeste roll up sau drill down, în functie de directie, spre vârful sau baza ierarhiei. Acestea sunt operatii de schimbare a vederii de-a lungul nivelelor unei ierarhii. Prin facilitatea de drill down, utilizatorii pot naviga pe nivele cu un grad de detaliu mai accentuat. Prin roll up se pot vizualiza datele la un nivel agregat. Cu toate ca instrumentele OLAP pot realiza dinamic toate operatiile necesare analizei, pentru a economisi timp si resurse se prefera uneori precalcularea unor valori globale în cadrul depozitului. Aceasta operatie este numita consolidare (când se refera la aspectul conceptual) sau însumare (din perspectiva procedurala), fie agregare (din perspectiva structurala). Aceste agregari se refera la o anumita masura si se realizeaza dupa dimensiunile corespunzatoare acesteia. Pentru atributele organizate ierarhic, consolidarea se face nivel cu nivel. Aceste operatii implica de cele mai multe ori doar calcularea unor totaluri, dar exista si exceptii în care se utilizeaza formule sau procedee statistice. Nivelul la care se face însumarea în cazul în care sunt implicate ierarhii se numeste granularitate. Procesul de agregare creaza o redundanta în cadrul bazei de date, dar volumul acesteia nu este semnificativ deoarece scade exponential cu fiecare nivel de însumare. Câstigul de performanta obtinut la accesarea datelor este deosebit de important în analiza.

Rotatii – reprezinta operatiile cele mai uzuale în structurile de date multidimensionale si ofera utilizatorului posibilitatea de a alege perspectiva asupra datelor pe care o va utiliza. De exemplu în cazul bidimensional exista doua posibilitati de vizualizare, iar în cazul tridimensional se pot utiliza 6 rotatii pentru a vizualiza datele din diferite perspective, iar pentru patru dimensiuni exista 24 de perspective posibile. Fiecare rotatie pune în evidenta o noua perspectiva, aducând în prim plan o structura bidimensionala, o fateta (slice). Din acest motiv rotatia se mai numeste si “data slicing”.

Aceste operatii nu implica o reorganizare a datelor stocate, ci o schimbare a modalitatii de reprezentare, spre deosebire de cazul unor structuri relationale, pentru care o noua fateta poate fi obtinuta doar în urma unor interogari complexe.

Sectiuni – reprezinta viziuni sau imagini (views) specifice diverselor categorii de utilizatori, prin operatii de sectionare prin care se obtin "felii" bidimensionale (slices).

Astfel, un manager de produs poate avea la îndemâna datele legate de produsul pe care-l supervizeaza, pe toate zonele, pe toata perioada analizata. În schimb, un manager regional, va fi interesat de toate produsele, dar numai pe toate zonele pe care le coordoneaza.

Tehnica aceasta consta în limitarea unor atribute la anumite valori si obtinerea unui cub de date redus (procedeu numit data dicing) (figura 2.3.).

Figura 2.3.a: Cub de date tridimensional. Dimensiunile reprezintă timpul, produsele si zonele de desfacere.

Figura 2.3.b: Viziunea managerului de produs: acesta poate obține o viziune a datelor ce reflectă doar vânzările anumitor produse în toata regiunea si în toată perioada de timp considerată.

Figura 2.3.c: Viziunea managerului financiar: poate restricționa analiza la un anumit trimestru pe toate produsele si toate zonele.

Figura 2.3.d: Viziunea managerului regional: poate vedea vânzările întregii game de produse în regiunea de care răspunde, pe toata perioada de timp considerată.

Figura 2.3.e: O viziune ad-hoc: diferite cerințe pot duce la selectarea unor anumite valori ale atributelor. Rezultatul consta în subseturi de date si din acest motiv aceste operații se mai numesc si “data dicing”.

2.3. ANALIZA COMPARATIVA A PERFORMANTELOR OBTINUTE ÎN

URMA IMPLEMENTARII DIFERITELOR TIPURI DE DEPOZITE DE DATE

Problemele aparute în cazul realizarii unor depozite de date la nivelul organizatiei sau chiar la niveluri departamentale sunt legate de performantele în interogare, de accesul la date, de administrarea metadatelor, de modalitatea de organizare si stocare si nu în ultimul rând de dimensiunea depozitului si de facilitatile de administrare.

În cele ce urmează voi realiza în tabelul 2.2 o comparație între caracteristicile depozitelor de date organizaționale pe de o parte si data marturi organizationale pe de alta parte din punct de vedere al realizării lor atât virtual cât si separat, prin stocarea datelor în forma agregata.

Tabelul 1.2. Analiza comparativa a tipurilor de depozite de date

Din analiza realizata se observa ca în cazul unei organizatii extinse, în care volumul datelor este mare, este indicat sa se dezvolte un depozit de date organizational, cu datele agregate stocate, pregatite pentru analiza. In cazul în care se doreste un data mart realizat rapid, cu performante mari pe volume de date relativ reduse, fara spatiu de stocare separat, se poate aborda realizarea unui data mart virtual în care datele sa fie prelucrate, agregate si prezentate spre analiza direct din sursele de date.

In anumite cazuri se pot combina aceste doua variante de depozit stocat separat pentru date provenite din perioade mai mari de timp, de exemplu pentru datele pâna în urma cu 3 luni si chiar o luna, iar pentru datele curente sa se realizeze separat, tinând totusi cont de algoritmii si fluxurile procesului ETL, un depozit virtual care sa prelucreze datele din ultima perioada pâna în prezent.

Performanta implementarii uneia sau alteia dintre variante depinde însa si de capacitatile si facilitatile oferite de sistemul de gestiune, dar si de resursele hardware, din acest motiv recomand ca la realizarea unei solutii de depozite de date sa se tina cont si de aceste aspecte.

CAPITOLUL III: EXEMPLE DE PROIECTARE A SCHEMEI UNUI DEPOZIT DE DATE

3.1. OBIECTIVELE APLICAȚIEI ȘI DESCRIEREA SISTEMELOR OPERAȚIONALE

3.1.1. Obiectivele aplicației

S.C. ALFA SA și-a fixat ca obiectiv proiectarea și realizarea unui depozit de date în domeniul vânzărilor. Firma are acoperire la nivel național, cu prezență regională în toate zonele istorice ale României. Ea deține un lanț de magazine prin intermediul cărora vinde în sistem en-detail diverse produse către clienți individuali, de regulă persoane fizice.

3.1.2. Descrierea sistemelor operaționale

Firma se află la un nivel mediu de informatizare. Analiza sistemelor informatice existente a identificat mai multe aplicații care gestionează datele din domeniul vânzări. Ele se referă la următoarele entitățile implicate în activitatea comercială curentă: clienți, produse, magazine.

Bazele de date operaționale sunt realizate și întreținute în mediul Visual FoxPro și conțin următoarele tabele:

CLIENȚI – datele referitoare la clienții care au efectuat cel puțin o operație de cumpărare;

MAGAZINE – datele referitoare la magazinele firmei, prin care se efectuează vânzările de produse către clienți;

TIMP – date despre intervalele de timp în care s-au efectuat tranzacțiile către clienți:

CLASA_PRODUSE – date referitoare la clasele în care sunt incluse produsele vândute de către firmă;

PRODUSE – date privind produsele comercializate de firmă;

VÂNZĂRI – date despre vânzările fectuate.

Structura tabelelor, denumirea câmpurilor și semnificațiile acestora sunt descrise în paginile următoare. Pentru a putea urmări procesele de transformare a datelor și modul de construire a modelului multidimensional, pentru fiecare tabel s-a prezentat atât structura cât și secvențe din conținut. Se observă că unele tabele din bazele de date operaționale nu sunt normalizate complet. Dacă este necesar ele vor fi în continuare denormalizate în depozitul de date.

3.1.2.1. Tabelul CLIENȚI

CLIENȚI

Figura nr. 3.1. Secvență din conținutul tabelei CLIENȚI

3.1.2.2. Tabelul MAGAZINE

3.1.2.3. Tabelul TIMP

TIMP

Figura nr. 3.3. Secvență din conținutul tabelei TIMP

3.1.2.4. Tabelul CLASA_PRODUSE

CLASA_PRODUSE

Figura nr. 3.4. Secvență din conținutul tabelei CLASA PRODUSE

3.1.2.5. Tabelul PRODUSE

Figura nr. 3.5. Secvență din conținutul tabelei PRODUSE

3.1.2.6. Tabelul VÂNZĂRI

Figura 3.6. Secvență din conținutul tabele VANZARI

3.2. CONSTRUIREA DEPOZITULUI DE DATE UTILIZÂND DIFERITE MEDII DE DEZVOLTARE

3.2.1. Stabilirea tabelelor de fapte și a tabelelor dimensiune

O analiză atentă a tabelelor din bazele de date operaționale ne conduce la ideea că tabelul VÂNZĂRI poate fi stabilit ca tabel de fapte iar celelalte tabele (CLIENȚI, MAGAZINE, PRODUSE, CLASA PRODUSE, TIMP) ca tabele dimensiune. De aceea, transpunerea în modelul multidimensional se va realiza destul de ușor.

Faptele care descriu tranzacțiile efectuate (vânzările) sunt:

Cantități vândute (Cantitate);

Valoare vânzări (Val_vanzare);

Valoare costuri (Val_costuri).

Fiecare tranzacție este interpretată din următoarele perspective care sunt
desemnate ca dimensiuni:

Clienți;

Timp;

Magazine;

Produse;

Clase de produse.

3.2.2. Construirea depozitului de date în mediul Microsoft SQL Analysis Manager 2000

Mediul Microsoft SQL Analysis Manager 2000 permite realizarea depozitului de date pe baza conexiunii care se face la sursa primară de date. Cel mai folosit tip de conexiune este interfața ODBC (Open DataBase Connectivity) care permite accesarea datelor din diverse surse de către aplicația client prin intermediul unui driver specific.

Î cazul de față, aplicația client este tocmai SQL Analysis Manager care va avea nevoie de datele existente în sursa de tip Microsoft Visual FoxPro. Driver-ul specific are rol de translator între cele două aplicații: client și sursa de date. în felul acesta clientul are acces la datele din Visual FoxPro referitoare la structura și conținutul tabelelor, la cheile primare, la legături etc.

Figura nr. 3.7. Interfața ODBC

Ca urmare, trebuie creată o legătură de tip ODBC la care să aibă acces utilizatorii SQL Analysis Manager. Urmează conectarea prin această legătură și în felul acesta proiectantul depozitului de date are acces la sursa primară de date.

Conceptul de bază în SQL Analysis Manager este cubul multidimensional care conține o tabelă de fapte și una sau mai multe dimensiuni. în cazul nostru, tabela de fapte este reprezentată de tabela VÂNZĂRI din care vor fi specificate următoarele măsuri (fapte, valori numerice): valoarea vânzărilor, valoarea costurilor, cantitățile vândute.

Figura nr. 3.8. Selectarea faptelor pentru cubul multidimension

După specificarea faptelor din cub, SQL Analysis Manager solicită specificarea dimensiunilor aferente, urmărindu-se următoarele aspecte:

Declararea schemei de reprezentare: stea (star schema) sau fulg de nea (snowflake schema);

Declararea tabelei sau tabelelor pe aza cărora va fi construită noua dimensiune;

Stabilirea ierarhiei dimensionale;

Specificarea numelui noii dimensiuni create.

Astfel, pentru dimensiunea Client, având în vedere că datele referitoare la această entitate se regăsesc într-o singură tabelă, schema aleasă va fi de tip stea, iar tabela sursă va fi tabela CLIENT din baza de date relațională. Nivelurile dimensionale vor fi selectate conform ierarhiei: Regiune -> Județ -> Localitate -> Nume_client.

Figura nr. 3.9. Specificarea nivelurilor ierarhice pentru dimensiunea CLIENT

Proiectantul depozitului de date trebuie să fie atent la semnificația fiecărui nivel ierarhic și să specifice ierarhia în ordinea corectă. Ca urmare, o ierarhie de genul Județ -> Regiune -> Localitate -> Nume_client nu va fi acceptată deoarece numărul înregistrărilor de la nivelul Regiune este mai mic decât numărul înregistrărilor la nivelul Județ.

în urma specificării tuturor elementelor referitoare la dimensiunea CLIENT, datele din tabela sursă vor organizate într-o nouă structură dimensională care arată conform figurii următoare (figura nr.3.10):

Figura nr. 3.10. Organizarea dimensiunii CLIENT

Dimensiunea Timp va avea o arhitectură de tip stea și va fi de tip Time Dimension, ceea ce permite construirea mai rapidă a ierahiei. Pe aza datelor din tabela sursă și a specificării unei ierarhii de tip Year -> Quarter -> Month (An -> Trimestru -> Lună) se obține următoarea structură dimensională.

Figura nr. 3.11. Organizarea dimensiunii TIMP

În acest caz trebuie remarcat faptul că SQL Analysis Manager are predefmit tipul dimensional de natura timpului și ca urmare procesul de proiectare este forte simplu. Singurul dezavantaj este că structura dimensională construită în acest fel conține denumiri predefmite ale diferitelor niveluri. Se poate opta pentru construirea unei dimensiuni clasice de tip stea, iar nivelurile vor fi specificate manual de către utilizator, ajungându-se astfel la ierarhia dorită de utilizator.

în cazul dimensiunii PRODUS, ierarhia are următoarele niveluri: Familie -Departament -> Categorie -> Subcategorie -> Marca -> Nume produs. Având în vedere că primele patru niveluri se regăsesc în tabela Clasa_produse, iar ultimele două în tabela Produse, este necesar ca arhitectura dimensiunii să fie de tip snowflake (fulg de zăpadă).

Pe aza legăturii care există în aza de date relațională între cheia primară a tabelei Clasa_Produse și cheia străină a tabelei Produse, dimensiunea Produs va fi organizată în maniera următoare (figura nr. 3.12):

Pentru a pune în evidență principiile de lucru în stabilirea dimensiunilor și în modul de transpunere a tabelelor relaționale în modelul dimensional prezentăm în figurile de mai jos structura dimensiunii PRODUS, pe niveluri ierarhice, conform datelor exemplificate în figurile 3.4 (CLASA PRODUSE) și 3.5 (PRODUSE).

Figura nr. 3.13. Dimensiunea PRODUS la nivel maxim de detaliere

Figura nr. 3.14. Dimensiunea PRODUS la primul nivel de detaliere (familie produse)

Figura nr. 3.15. Dimensiunea PRODUS la al doilea nivel de detaliere (departament)

Figura nr. 3.16. Dimensiunea PRODUS la al treilea nivel de detaliere (categorie)

Figura nr. 3.17. Dimensiunea PRODUS la al patrulea nivel de detaliere (subcategorie)

Figura nr. 3.18. Dimensiunea PRODUS la al cincilea nivel de detaliere (marca)

Figura nr. 3.19. Dimensiunea PRODUS la un nivel intermediar de detaliere

În cazul dimensiunii MAGAZIN, având în vedere că toate datele se regăsesc într-o singură tabelă, arhitectura va fi cea de tip stea, ierarhia conținând următoarele niveluri: Regiune -> Județ -> Localitate -> Nume magazin.

Figura nr. 3.20. Organizarea dimensiunii MAGAZIN

Schema generală a cubului de date multidimensional va cuprinde în centru tabela de fapte (Vânzări) la care vor fi conectate tabelele dimensiune (figura nr. 3.21). Legăturile între tabela de fapte și tabelele dimensiuni sunt evidențiate automat pe aza relațiilor existente în aza de date sursă. Aceste relații sunt extrase și prelucrate de către SQL Analysis Manager prin intermediul legăturii de tip ODBC cu care ne-am conectat la baza de date din Visual FoxPro.

Figura nr. 3.21. Structura cubului multidimensional VÂNZĂRI

Pe măsură ce proiectantul depozitului de date adaugă specificații la modelul curent, ele sunt înmagazinate într-o structură separată care conține metadatele depozitului. Ele sunt stocate separat de datele operaționale ale depozitului, însă pot fi accesate prin interogările lansate asupra cubului. Modificarea lor se efectuează automat în urma acțiunilor utilizatorului, dar nu direct; deci proiectantul sau utilizatorul nu vor putea modifica manual un parametru inclus în secțiunea metadatelor, ci doar prin modificarea altor proprietăți ale depozitului: dimensiuni, fapte, ierarhii, procesări etc.

SQL Analysis Manager actualizează imediat secțiunea metadatelor, astfel încât utilizatorul depozitului știe în orice moment care este situația curentă.

Figura nr. 3.22. Metadatele cubului multidimensional VÂNZĂRI

Observăm că ultima informație din secțiunea de metadate se referă la procesarea cubului. Această etapă este necesară pentru definitivarea datelor memorate în structura multidimensională, adică de implementare a arhitecturii MOLAP (Multidimensional OLAP) care va putea fi accesată prin interogări specifice sau prin browser-ul SQL Analysis Manager. în primă fază, generatorul pune la dispoziția utilizatorului o serie de date demonstrative pentru a se evidenția modalitatea de navigare OLAP. După procesarea cubului, utilizatorul va putea accesa datele reale. Motivul pentru care sunt afișate mai întâi date demonstrative ține de faptul că procesarea este mare consumatoare de timp și resurse de memorare și calcul, iar orice modificare efectuată la nivelul depozitului de date necesită o nouă procesare.

Figura nr. 3.23.Datele din cub la cel mai înalt nivel de sintetizare

Figura nr. 3.24. Datele cubului multidimensional VÂNZĂRI vizualizate în manieră

OLAP

Deosebit de utilă este posibilitatea de a vedea estimativ care sunt performanțele și resursele necesare pentru a procesa cubul de date. Proiectantul poate specifica un anumit nivel de perfomanță (între 1% – 100%), astfel încât SQL Analysis Manager să poată previziona spațiul ocupat de date în urma procesării lor. Forma grafică este foarte utilă și permite modificarea diverșilor parametri astfel încât opțiunea finală va putea fi în concordanță cu resursele disponibile și cu necesitățile în privința vitezei de răspuns a depozitului.

Figura nr. 3.25. Relația între performanța depozitului și resursele solicitate

Interogarea depozitului de date se realizează prin fraze MDX (MultiDimensional Extensions) care presupun parcurgerea ierahiilor și poziționarea la nivelurile dorite în cadrul dimensiunilor. De exemplu, pentru a afla valoarea vânzărilor pentru clienții din județul Iași, fraza de interogare este următoarea:

SELECT

{ [Measures].[Val Vânzare] } on columns,

{ [Client].[Județ].[Iași] } on rows FROM Cub_Vanzari

"Traseul" valoric este specificat printr-o cale definită prin noduri incluse între paranteze pătrate, iar axele sunt determinate prin cuvintele cheie columns și rows.

3.2.3. Construirea depozitului de date în mediul ORACLE WAREHOUSE BUILDER 9i

În Oracle Warehouse Builder întâlnim o serie de concepte asemănătoare (dimensiuni, fapte, ierarhii etc.) însă proiectantul își desfășoară munca în cadrul unui proiect care conține mai multe module. La rândul lor, modulele pot fi de două tipuri:

module de tip sursă de date (Source Module);

modul de tip depozit de date (Target Module).

Figura nr. 3.26. Componentele unui proiect Oracle Warehouse Builder

Spre deosebire de SQL Analysis Manager care suportă o varietate de surse de date, Oracle Warehouse Builder preferă sursele de date native Oracle, definite în Oracle 8i/9i. Configurarea unui modul sursă presupune specificarea elementelor de identificare pentru baza de date: IP-ul serverului, numele de utilizator și parola. în modulul sursă pot fi apoi importate diverse obiecte: tabele, secvențe, view-uri.

Figura nr. 3.27. Obiecte ce pot fi importate în modulul sursă

Principalele componente ale depozitului de date, regăsite în modulul de tip target, sunt: dimensiuni, fapte, mapări, transformări. Dimensiunile au același sens ca în SQL Analysis Manager, însă modul de proiectare este puțin diferit. Dacă în varianta Microsoft dimensiunile sunt proiectate pornind de la sursa de date, în varianta Oracle dimensiunile sunt proiectate în manieră CASE, iar apoi, prin intermediul mapărilor, se face legătura cu sursa de date relațională.

Figura nr. 3.28. Principalele componente ale depozitului de date

O dimensiune se caracterizează prin mai multe niveluri ce pot fi grupate în cadrul mai multor ierarhii. în exmplul curent, dimensiunea PRODUS are nivelurile Clasa, Subclasa și Produs care sunt incluse în ierarhia Subclasare. Pentru fiecare nivel se specifică tipul de date (Numeric, Varchar, Date etc.) și dimensiunea.

Figura nr. 3.29. Nivelurile ierarhice ale dimensiunii PRODUS

După definirea dimensiunilor, ca element de noutate, intervine secțiunea de mapări în cadrul căreia trebuie specificate legăturile și transformările între sursă (baza de date relațională) și destinație (depozitul de date). Se folosesc operatorii de mapare (JOINER, SPLITTER etc.) care definesc tranziția datelor din relațional în multidimensional. în cazul operatorului JOINER avem mai multe grupuri de intrare (tabele sursă: CLASA PRODUSE, SUBCLASA PRODUSE, PRODUSE) și un singur grup de ieșire (dimensiunea Produs). Maparea se specifică în manieră CASE, prin declararea metadatelor procesului de transformare: câmpurile de intrare, câmpurile de ieșire, transformările care au loc și legăturile specifice.

Figura nr. 3.30. Specificarea mapării pentru dimensiunea PRODUSE

Maparea grupurilor de intrare presupune stabilirea tabelelor și a câmpurilor care sunt incluse în transformare. Modalitatea de realizare este una vizuală, prin tehnica Drag & Drop.

Maparea grupului de ieșire înseamnă selectarea din mulțimea câmpurilor incluse în procesul de transformare doar a celor care se regăsesc în destinație (în cazul curent dimensiunea PRODUSE).

După stabilirea sursei, a destinației și a operatorului de mapare urmează etapa de validare în care Oracle Warehouse Builder verifică corectitudinea tipurilor de date și a mărimilor specificate.

Figura nr. 3.31. Maparea grupurilor de intrare

Figura nr. 3.32. Maparea grupului de ieșire

În cazul în care validarea se încheie cu succes, se poate trece la etapa de generare a codului pentru obiectele depozitului de date (figura nr. 3.33, 3.34). Sunt create obiecte pentru sursă, transformări și destinație.

La implementarea depozitului de date vor fi luate în considerare toate definițiile utilizatorului și pe baza specificațiilor acestuia va fi generată o instanță fizică

CREATE TABLE "DIM_PRODUSE"

( "CLASA_DENUMIRE_CLASA" VARCHAR2 (20) , "CLASA_ID" NUMBER,

"PRODUS_DENUMIRE_PRODUS" VARCHAR2(20), "PRODUS_EXPLICATII" VARCHAR2(20), "PRODUS_ID" NUMBER,

"PRODUS_UNITATE_MASURA" VARCHAR2(3), "SUBCLASA_DENUMIRE_SUBCLA" VARCHAR2(20), "SUBCLASA_ID" NUMBER) TABLESPACE "USERS" PARALLEL LOGGING ;

Figura nr. 3.33. Codul generat pentru tabela sursă în cazul dimensiunii PRODUS

CREATE DIMENSION "DIM_PRODUSE_DIM" LEVEL "PRODUS" IS "DIM_PRODUSE"."PRODUS_ID" LEVEL "CLASA" IS "DIM_PRODUSE"."CLASA_ID" LEVEL "SUBCLASA" IS "DIM_PRODUSE"."SUBCLASA_ID" HIERARCHY "SUBCLASARE"( "PRODUS" CHILD O "SUBCLASA" CHILD O "CLASA" )

ATTRIBUTE "PRODUS" DETERMINES

("PRODUS_DENUMIRE_PRODUS","PRODUS_EXPLICATII", "PRODUS_UNITATE_MASURA" ) ATTRIBUTE "CLASA" DETERMINES ("CLASA_DENUMIRE_CLASA" ) ATTRIBUTE "SUBCLASA" DETERMINES ("SUBCLASA_DENUMIRE_SUBCLA" ) ;

Figura nr. 3.34. Codul generat pentru dimensiunea DIM PRODUS

CONCLUZII

Construirea unui depozit de date și utilizarea lui (data warehousing) necesită integrarea datelor, curățarea datelor (data cleaning) și consolidarea datelor. Data warehousing folosește conceptul “update-driven” în care informațiile din surse multiple, heterogene sunt integrate în avans și stocate în depozitul de date pentru integrare directă și analiză. Procesul de extragere a datelor vizează transformarea datelor din baza de date operațională în structura și formatul intern al depozitului. Procesul de curățare a datelor dă certitudinea că datele sunt autentice și pot fi folosite în actul decizional.

Spre deosebire de bazele de date cu procesare on-line depozitele de date nu conțin informațiile cele mai proaspete..

Scopurile unui depozit de date sunt :

a. acces sporit la date pentru utilizatori

b. redarea corectă a realității și înregistrarea cu acuratețe a trecutului

c. vizualizarea informațiilor din depozitul de date sub diferite unghiuri și sub diferite niveluri de detaliere.

d. Separarea prelucrărilor de nivel operațional și analitic.

Un proiect data warehouse necesită o gamă largă de tehnologii și instrumente. Aceste date conținute în depozite vor fi baza procesărilor analitice necesare proceselor de decizie. Viitorul va aparține cu siguranță aplicării în cât mai multe domenii a acestui tip de tehnologii performante.

În lucrare este prezentată CONSTRUIREA DEPOZITULUI DE DATE UTILIZÂND DIFERITE MEDII DE DEZVOLTARE, cum ar fi Microsoft SQL Analysis Manager sau Oracle Warehouse Builder

Mediul Microsoft SQL Analysis Manager 2000 permite realizarea depozitului de date pe baza conexiunii care se face la sursa primară de date. Cel mai folosit tip de conexiune este interfața ODBC (Open DataBase Connectivity) care permite accesarea datelor din diverse surse de către aplicația client prin intermediul unui driver specific.

În Oracle Warehouse Builder întâlnim o serie de concepte asemănătoare (dimensiuni, fapte, ierarhii etc.) însă proiectantul își desfășoară munca în cadrul unui proiect care conține mai multe module. La rândul lor, modulele pot fi de două tipuri:

module de tip sursă de date (Source Module);

modul de tip depozit de date (Target Module).

Spre deosebire de SQL Analysis Manager care suportă o varietate de surse de date, Oracle Warehouse Builder preferă sursele de date native Oracle, definite în Oracle 8i/9i. Configurarea unui modul sursă presupune specificarea elementelor de identificare pentru baza de date: IP-ul serverului, numele de utilizator și parola. în modulul sursă pot fi apoi importate diverse obiecte: tabele, secvențe, view-uri.

Principalele componente ale depozitului de date, regăsite în modulul de tip target, sunt: dimensiuni, fapte, mapări, transformări. Dimensiunile au același sens ca în SQL Analysis Manager, însă modul de proiectare este puțin diferit. Dacă în varianta Microsoft dimensiunile sunt proiectate pornind de la sursa de date, în varianta Oracle dimensiunile sunt proiectate în manieră CASE, iar apoi, prin intermediul mapărilor, se face legătura cu sursa de date relațională.

BIBLIOGRAFIE

Bara, Adela, Soluții informatice pentru managementul strategic, teză de doctorat, 2007

Beyond., D., Information and Data Modelling, Oxford Blackwell Sci. Publications, 1990

Ganguly, A. R., Gupta A., Data Mining Technologies and decision Support Systems for Business and Scientific Applications, Encyclopedia of Data Warehousing and Mining, Blackwell Publishing, 2005

Graz, P., Watson, H., Decision Support in the Data Warehouse, Prentice Hall, Upper Saddle River Publishing, 1998

Inmon, W.H., Building the Data Warehouse, 3rd Edition, Wiley Computer Publishing, USA, 2002

Oprean, D., Racovitan, D., M., Oprean Victoria, Informatică de gestiune și managerială, Editura Eurounion, Oradea, 1994