Depozite de date

Depozite de date

1. Considerente generale

Dupa Ralph Kimball, un depozit de date reprezinta "o copie a datelor, special structurate in vederea interogarilor si analizelor"[1].

Depozitele de date completeaza informatizarea organizatiilor, alaturi de sistemele informatice tranzactionale. Rolul depozitelor de date este de a stoca date preluate din restul sistemelor informatice, in vederea analizarii acestora prin diverse mijloace. Depozitele de date constituie "coloana vertebrala" a sistemelor de asistare a deciziei bazate pe sinteza si analiza datelor, sau altfel spus, depozitele de date contin "materia prima" pentru sistemele de asistare a deciziei bazate pe sinteza si analiza datelor.

William Inmon defineste astfel principalele caracteristici ale unui depozit de date[2]:

a)     orientarea catre subiect: sistemele operationale sunt orientate (mapate) pe functiunile intreprinderii (contabilitate, salarii, vanzari etc.). Depozitele de date sunt orientate pe subiectele firmei (clienti/furnizori, surse de venituri, centre de cost);

b)     integrarea: depozitele de date integreaza date din surse multiple care sunt, eventual, supuse unor transformari. In urma transformarilor, datele rezultate reprezinta un tot unitar. Astfel, pentru un anume subiect retinut in depozitul de date se foloseste o singura codificare, indiferent de sursele din care provin datele. De asemenea, un atribut din depozitul de date va avea un tip de date bine precizat, iar toate valorile sale vor respecta cerintele tipului de date respectiv.

c)     non-volatilitatea: datele din depozitul de date nu sunt supuse, in mod obisnuit, operatiunilor de actualizare (modificare) ci numai unor operatiuni de adaugare. Datele noi care apar de-a lungul ciclului de viata al depozitului de date sunt adaugate datelor vechi.

d)     orientarea in timp: datelor din depozitul de date li se asociaza o caracteristica de timp, un atribut sau un grup de atribute care indica momentul de timp cand datele au fost inregistrate in sistemul informational. Pentru datele care caracterizeaza o operatiune (tranzactie) economica, timpul este reprezentat de data sau momentul de timp (timestamp) asociate operatiunii respective.

Este bine-cunoscut astazi potentialul informational al datelor acumulate in timp de sistemele informatice operationale din firme. Pe baza acestor date se pot identifica si cuantifica in expresie monetara fenomenele ce au intervenit in activitatea firmei in diverse perioade, atat sub aspect static ("imagini" la un moment dat), cat si dinamic (analiza comparativa in timp), de asemenea se pot cuantifica si cauzele acestor fenomene. Aceste informatii, puse la dispozitia managerilor, pot oferi un real suport in adoptarea deciziilor (unul dintre cele mai importante considerente in acest sens este faptul ca managerii stiu precis asupra caror aspecte din activitatea firmei trebuie sa intervina).

Exploatarea acestui potential nu se poate face totusi cu ajutorul sistemelor operationale, din mai multe considerente, cum ar fi[3]:

nevoile informationale ale utilizatorilor depozitelor de date difera de cele ale utilizatorilor sistemelor tranzactionale: primii sunt interesati de analiza unui volum - de multe ori semnificativ - de date, care se refera la un interval de timp, ceilalti introduc/actualizeaza si solicita date/informatii in timp real;

modul de organizare a datelor intr-un depozit de date difera de cel folosit intr-un sistem operational, in plus, pentru a raspunde unor anume cerinte exprimate de utilizatori, structura depozitului de date poate fi modificata, ceea ce intr-un sistem tranzactional este contra-indicat (sistemele operationale sunt proiectate de la bun inceput astfel incat sa raspunda cat mai bine unui anume set de cerinte, iar modificarile in structura datelor, daca sunt posibile, trebuie supuse unui proces de analiza atenta, pentru a nu se produce erori in modul de functionare a sistemului);

folosirea in scop de analiza a sistemelor operationale greveaza asupra utilizarii lor normale, prin "consumul" de resurse de procesare hard/soft pe care l-ar presupune, situatie inacceptabila avand in vedere ca pentru un sistem operational performanta este exprimata prin prisma vitezei de prelucrare a datelor/raspuns la solicitarile utilizatorilor.

Aceste considerente impun ca depozitele de date si aplicatiile care le exploateaza sa fie separate (cel putin din punct de vedere software, separarea hardware poate fi, de la caz la caz, un avantaj pentru utilizatorii finali) de sistemele informatice tranzactionale.

2. Obiectivele depozitelor de date

Principalele obiective ale unui depozit de date sunt urmatoarele[4]:

a.     Suportul in asistarea deciziei - depozitul de date trebuie sa contina date care sa asiste managementul de orice nivel in procesul decizional. Acest fapt se manifesta prin aceea ca decidentii pot consulta date din depozit pentru a-si forma/completa imaginea pe care o au asupra problemei care solicita adoptarea deciziei. Cu cat aceasta imagine este mai aproape de realitate, cu atat sunt mai mari sansele ca decizia sa fie corecta;

b.     Depozitul de date trebuie sa ofere acces rapid si facil la informatii - aici intervin aplicatiile cu rol de client care ofera utilizatorilor interesati date extrase din depozit, acestia trebuie sa acceseze datele pe care le doresc fara dificultate, rolul lor este de a interpreta datele accesate;

c.      Consistenta datelor - depozitul de date trebuie sa ofere certitudinea ca datele sunt corecte, in acest scop trebuie sa se acorde o mare atentie proceselor prin care datele sunt preluate din alte surse, prelucrate si apoi "livrate" catre depozitul de date. Respectarea consistentei datelor ridica valoarea calitativa a informatiilor care sunt obtinute pe baza acestor date;

d.     Flexibilitate si adaptabilitate - depozitul de date trebuie sa fie construit astfel incat sa fie capabil sa raspunda prompt si corect nevoilor informationale in continua schimbare ale utilizatorilor sai;

e.      Confidentialitatea - depozitele de date stocheaza informatii critice pentru activitatea firmei, informatii care trebuie sa fie disponibile numai celor in drept. Depozitele de date, prin functiile pe care le indeplinesc, stocheaza informatii intr-un volum mai mare fata de aplicatiile tranzactionale, astfel ca accesul neautorizat la continutul depozitului de date reprezinta un risc major pentru firma. Se poate spune ca daca informatiile din depozit ajuta utilizatorii in procesul decizional, odata ce caracterul secret al informatiilor a fost compromis, cei care au intrat in posesia informatiilor pot "simula" cu acuratete procesul decizional si pot prezice ce anume curs va urma activitatea firmei;

f.      Acceptabilitatea - utilizatorii depozitului de date trebuie sa acorde incredere informatiilor primite in urma exploatarii depozitului de date.

3 Componentele unui depozit de date

Principalele componente ale unui depozit de date sunt:

a.     Sursele de date

Sursele de date ale unui depozit de date pot fi toate celelalte componente ale sistemului informatic al firmei:

baze de date (sisteme informatice tranzactionale);

aplicatii de calcul tabelar;

fisiere text etc.

Cel mai adesea, sursa de date o reprezinta bazele de date ce deservesc sistemele operationale din firma. Daca anterior am considerat ca depozitele de date trebuie separate de aceste sisteme, conlucrarea intre ele reprezinta o premisa a succesului implementarii unui sistem informatic de asistare a deciziei bazat pe sinteza si analiza datelor. Majoritatea instrumentelor de dezvoltare soft includ drivere native de comunicare intre cele doua niveluri - operational si decizional. Merita subliniat inca un considerent in sprijinul ideii de mai sus: transferand datele cu caracter istoric din sistemele tranzactionale in depozitele de date, capacitatea de stocare a celor dintai este degrevata de un volum de multe ori mare de date (aceasta procedura de arhivare poate inlocui sau completa back-up-ul traditional).

Sistemele informatice care furnizeaza date catre depozitele de date sunt separate din punct de vedere arhitectural de acestea, drept urmare, in multe situatii, utilizatorii depozitelor de date nu pot controla structura si natura datelor din sistemele sursa. Pot apare deci neconcordante intre sursele de date si depozitele de date, neconcordante ce trebuie tratate folosind fie instrumente proprii sistemelor informatice sursa, fie instrumente software asociate depozitelor de date. O solutie pentru tratarea unitara a acestui gen de situatii o reprezinta reproiectarea aplicatiilor-surse de date, astfel incat structura si natura datelor sa fie compatibile cu cerintele depozitelor de date[5].

Exista totusi situatii in care depozitele de date trebuie sa fie incarcate cu date care nu exista in alte sisteme informatice din firma. In acest caz, sistemele informatice tranzactionale pot fi modificate pentru a culege aceste date, sau se pot construi aplicatii noi pentru culegerea datelor, avand in vedere si considerentele exprimate in paragraful anterior: este necesar ca noile aplicatii sa comunice fara probleme cu depozitul de date.

b.     Componenta de pregatire a datelor

Componenta de pregatire a datelor este acea parte a arhitecturii depozitului de date in care au loc procesele de extragere, transformare si incarcare a datelor[6], zona de granita intre sursele de date si depozitul de date.

Extragerea reprezinta procesul prin care datele sunt preluate din sursele de date si apoi incarcate in componenta de pregatire. Datele pot fi extrase folosind instrumentele de comunicare intre sursele de date (cel mai des intalnite sunt driverele OLE-DB si ODBC).

Transformarea reprezinta o intreaga colectie de operatii la care sunt supuse datele, cum ar fi:

curatirea: sunt corectate erorile de tastare, se verifica apartenenta datelor la liste de valori acolo unde este cazul si se fac corectiile de rigoare, datele lipsa sunt incarcate automat acolo unde este posibil;

combinarea datelor din mai multe surse: dupa cum am amintit anterior, sursele de date ale depozitului de date pot fi eterogene. De aceea este extrem de important sa se asigure compatibilitatea datelor, indiferent de sursa din care au provenit;

eliminarea datelor duplicate: acest considerent este la fel de important pentru depozitele de date ca si pentru bazele de date si SGBD-uri. Datele duplicate viciaza grav calitatea informatiei extrase din depozitul de date, de aceea este necesar ca toate datele duplicate sa fie eliminate.

Pentru pregatirea datelor se poate utiliza ca suport software un sistem de gestiune a bazelor de date, cel putin din urmatoarele considerente:

majoritatea SGBD existente poseda o colectie de drivere de comunicatie ce permit preluarea de date din diversele surse ale depozitului de date;

curatirea si combinarea datelor se pot implementa facil folosind procedurile stocate sau interogarile de tip "actiune" din SGBD-uri, mai mult, operatiunile de transformare pot fi automatizate;

bazele de date contin instrumente pentru eliminarea duplicatelor (cheile primare) si pentru asigurarea integritatii (cheile externe). Aceste mecanisme pot fi utilizate fara probleme pentru asigurarea unicitatii si integritatii datelor ce vor migra in depozitul de date.

Aceasta varianta presupune efectuarea urmatoarelor operatiuni:

datele sunt incarcate in una sau mai multe baze de date, cu ajutorul driverelor de comunicatie;

cu ajutorul instrumentelor specifice SGBD folosit, se executa operatiile de transformare a datelor;

datele transformate pot fi incarcate in depozitele de date.

Se estimeaza ca 80% din fondul de timp alocat construirii unui depozit de date este alocat acestor activitati.

Incarcarea se refera la operatiunea de populare a depozitului de date, folosind datele extrase si transformate anterior.

c.      Depozitul de date propriu-zis

Reprezinta acea parte a arhitecturii depozitului de date in care sunt stocate datele, disponibile pentru a fi accesate de catre utilizatori. Depozitul de date se prezinta sub forma unei colectii de baze de date multidimensionale, fiecare dintre acestea fiind dedicate unui anume segment din activitatea firmei: vanzari, contabilitate financiara, buget etc.

Daca anumite grupuri de utilizatori ai unui depozit de date manifesta cerinte informationale specifice, care necesita exploatarea unui anume segment al depozitului de date, acest segment poarta denumirea de magazie de date.

Procesul de proiectare a structurii unui depozit de date poarta denumirea de modelare dimensionala.

Modelarea dimensionala este similara pana la un punct celei relationale, datele sunt grupate in campuri si tabele. De asemenea, depozitul de date stocheaza, la fel ca o baza de date relationala, date atomice care pot fi supuse unor agregari si consolidari, combinand astfel nivele diferite de granularitate a datelor (daca depozitul de date contine datele la nivelul atomic, datele pot fi usor centralizate/agregate, astfel se creeaza premisele pentru viabilitatea in timp a structurii depozitului de date, capabila sa raspunda la diverse cerinte ale utilizatorilor, in timp ce reciproca nu este posibila - datele centralizate nu pot fi defalcate in date atomice fara ca acestea din urma sa fie stocate in depozit sau disponibile in sursele de date ale depozitului).

Modelarea dimensionala se bazeaza pe urmatoarele notiuni[7]:

masuri: reprezinta datele (in mediul economic, acestea au cel mai adesea caracter cantitativ sau valoric) ce fac obiectul analizei, ca de exemplu: valoarea vanzarilor, cantitatea de produse fabricate/vandute etc. Masurile activitatii trebuie sa descrie situatii de genul: "cat s-a produs", "cat s-a vandut", "cat s-a consumat" (cantitativ sau valoric). Din punct de vedere al posibilitatilor de insumare a lor, masurile activitatii pot fi:

o      masuri aditive: valorile masurii pot fi agregate fara restrictii in depozitul de date;

o      masuri partial (sau semi-) aditive: valorile pot fi supuse insumarii doar pentru o parte a datelor din depozit;

o      masuri non-aditive: valorile nu pot fi agregate pentru nici una dintre dimensiunile din depozitul de date.

dimensiuni: reprezinta criteriile de formare a rezultatelor reprezentate de masuri (cantitatea de produse vandute se poate grupa in functie de gama de produse oferite spre desfacere, de subdiviziunile organizatorice ale firmei unde s-au inregistrat vanzarile etc. - toate aceste criterii pot fi privite ca dimensiuni). In functie de gradul de cuprindere al dimensiunilor, intre acestea se pot stabili relatii de tip parinte-copil, de exemplu dimensiunile Produs si Categorie Produse - dimensiunea a doua o include, putem spune, pe prima. O dimensiune particulara a oricarei activitati ce poate face obiectul modelarii dimensionale este timpul. O dimensiune este caracterizata de existenta mai multor atribute si de valorile acestora. De multe ori, o dimensiune este formata din una sau mai multe ierarhii (acestea se formeaza prin agregarea valorilor atomice ale unuia sau mai multor atribute ale dimensiunii, de exemplu, in cadrul dimensiunii Timp, se poate stabili o ierarhie in functie de luni, trimestre, ani). O ierarhie este formata din mai multe nivele intercorelate (in exemplul prezentat anterior, Luna, Trimestrul si Anul reprezinta nivele ale dimensiunii Timp). O dimensiune poate avea doua sau mai multe ierarhii alternative (pentru o dimensiune Clienti se poate defini o ierarhie in functie de localizarea geografica a clientilor - localitati, judete, si una in functie de specificul activitatii lor - subdomenii si domenii de activitate). Intre nivele se definesc legaturi, de la nivelul cel mai inalt (cu granularitatea cea mai mica) pana la nivelul cel mai detaliat. Intre doua nivele adiacente din cadrul unei ierarhii se stabileste o relatie de tip parinte-copil (nivelul superior joaca rolul de parinte iar nivelul inferior rolul de copil) ;

tabelele de fapte: cuprind campurile ce reprezinta masurile activitatii, precum si campuri ce permit crearea de legaturi cu dimensiunile. Tabelul de fapte reprezinta elementul central al depozitului de date, deoarece stocheaza datele atomice (la nivel de tranzactie) ale activitatii analizate, precum si criteriile dupa care se va face analiza. Inregistrarile (randurile) din tabelul de fapte poarta denumirea de fapte. In cadrul unui tabel de fapte, raportul dintre masurile activitatii si dimensiuni este unitar (masurile din tabelul respectiv partajeaza aceleasi dimensiuni). Lista dimensiunilor prezente intr-un tabel de fapte indica granularitatea tabelului, care este identica deci pentru toate inregistrarile tabelului;

tabelele dimensionale: contin campurile ce reprezinta dimensiunile (cum ar fi clientii, produsele). Pentru a asigura o analiza cat mai completa a datelor, este de dorit ca tabelele dimensionale sa includa cat mai multe atribute, care sa reflecte cat mai multe caracteristici ale criteriilor de analiza definite sub forma de dimensiuni. Spre deosebire de tabelele de fapte, in tabelele dimensionale sunt mai putine inregistrari, deoarece tabelele de fapte stocheaza toate tranzactiile firmei, in timp ce tabelele dimensionale stocheaza, o singura data, anumite elemente care intervin in tranzactii. Astfel, un tabel pentru dimensiunea Produse va contine lista produselor firmei, in timp ce tabelul de fapte pentru vanzari de produse va inregistra fiecare vanzare pentru fiecare produs. Este de asemenea de dorit ca tabelele dimensionale sa contina cat mai putine atribute codificate si cat mai multe atribute explicitate, pentru a asigura reprezentarea cat mai usoara in rapoarte a elementelor descrise de atributele respective.

Criteriul de unicitate a inregistrarilor mentionat anterior impune definirea unor chei in tabele, care sa asigure indeplinirea acestui obiectiv. Pentru tabelele dimensionale, definirea cheilor poate urma acelasi principiu ca si in cazul unui model relational (de fapt, tabelele dimensionale se aseamana foarte mult cu tabelele de nomenclatoare din modelele si bazele de date relationale). Pentru tabelele de fapte, se definesc chei externe, reprezentate de cheile primare ale tabelelor dimensionale care reflecta dimensiunile existente in tabelele de fapte. Prin combinarea cheilor externe se poate defini o cheie primara, compusa, pentru fiecare tabel de fapte. Legatura intre tabelele de fapte si tabelele dimensionale se realizeaza prin perechi de campuri de legatura cheie primara - cheie externa (similar cu legaturile dintre tabelele relationale). Definirea legaturilor intre tabelele dimensionale si de fapte in cadrul unui model dimensional permite pastrarea integritatii datelor.

Modelarea dimensionala este un proces iterativ, care cuprinde urmatoarele etape:

a)     analiza activitatii ce va face obiectul modelarii. Cel mai adesea, beneficiarii depozitului de date isi vor exprima nevoile informationale, indicand ce anume informatii doresc sa primeasca din depozitul de date. Odata identificate informatiile, se poate trece la identificarea surselor de date pentru viitorul depozit de date si la stabilirea procedurilor de extragere a informatiilor dorite. Daca de exemplu se doreste construirea unui depozit de date pentru analiza dinamicii si structurii cifrei de afaceri, se vor identifica sursele de date pentru analiza (fie sisteme informatice pentru evidenta vanzarilor/prestarilor de servicii, fie, daca acestea nu exista, fluxul informational al activitatii in cauza);

b)     definirea nivelului de granularitate al datelor din tabelul de fapte. In acest sens se poate tine cont si de sursele de date anterior determinate (sisteme informationale sau informatice din firma). Pentru exemplul considerat anterior, nivelul de granularitate va fi reprezentat de fiecare detaliu din factura de vanzare (fiecare produs care apare in factura va face obiectul unei fapte distincte);

c)     identificarea faptelor si masurilor activitatii;

d)     definirea dimensiunilor care caracterizeaza faptele. In cazul analizei dinamicii si structurii cifrei de afaceri, dimensiunile vor fi construite pe baza surselor de venituri ale firmei (bineinteles, sunt considerate doar veniturile ce se vor include in cifra de afaceri): produse vandute, organizarea activitatii de desfacere (agenti de vanzari sau magazine), clienti etc. De un real folos in definirea dimensiunilor sunt sursele de date de la care se porneste.

Modelarea dimensionala a depozitelor de date trebuie sa tina cont de urmatoarele considerente:

a)     tabelele de fapte trebuie sa contina datele detaliate, la nivel de tranzactie si nu date agregate. Agregarea si insumarea datelor trebuie sa se realizeze doar cu ajutorul instrumentelor de interogare a datelor. Acest element este esential pentru a asigura o cat mai mare flexibilitate in interogarea datelor. Modificarea cerintelor informationale ale utilizatorilor depozitelor de date nu constituie o problema foarte dificila in acest caz;

b)     modelele dimensionale trebuie sa functioneze la nivel de firma, pentru a se evita datele si elementele duplicate. Instrumentele de interogare permit definirea de magazii de date pe baza depozitelor de date. Chiar daca ulterior se vor utiliza magazii de date pentru a satisface cat mai bine necesitatile informationale ale unui anumit grup de utilizatori, magaziile trebuie extrase din depozitele de date;

c)     in proiectarea unui depozit de date, principalul criteriu pe care trebuie avut in vedere il reprezinta nevoile informationale ale beneficiarilor depozitului de date, corelat cu necesitatea ca acestia sa acceseze cat mai usor datele ce le sunt necesare.

Exista trei variante de modele utilizate in proiectarea unui depozit de date:

modelul stea (star): presupune existenta unui singur tabel de fapte, de care sunt legate toate tabelele dimensionale ale modelului;

modelul fulg de nea (snowflake): presupune existenta unui singur tabel de fapte, dar nu toate tabelele dimensionale sunt legate direct de acesta, ci dimensiunile legate prin relatii de tip parinte-copil sunt reprezentate prin tabele dimensionale separate. Tabelele asociate dimensiunilor parinte sunt legate numai de tabelele asociate dimensiunilor copil, acestea din urma fiind legate de tabelul de fapte;

modelul constelatie: se caracterizeaza prin existenta mai multor tabele de fapte, partajate de tabelele dimensionale corespunzatoare.

Studiu de caz:

Pentru exemplificare, vom considera o societate de brokeraj de credite.

Societatea de brokeraj de credite functioneaza ca un intermediar intre banci (institutiile ce ofera creditele) si clientii doritori de credite. Societatea lucreaza pentru mai multe banci si angajeaza consultanti financiari pentru mentinerea relatiilor cu clientii. Sub indrumarea consultantilor, clientii completeaza o cerere de credit, specificand datele personale, banca la care doresc sa apeleze, tipul si valoarea creditului solicitat. De asemenea, clientii completeaza un dosar cu diferite documente solicitate de banca. Daca banca aproba cererea de credit, clientul primeste creditul, moment in care se constituie un comision pentru societatea de brokeraj. Activitatea fiecarui consultant este coordonata de un superior (denumit unit manager in cadrul societatii), fiecare coordonator avand in subordine o echipa de consultanti.

Din considerente de marketing, se doreste efectuarea analizei evolutiei lunare a valorii creditelor solicitate (nu neaparat acordate) in functie de mai multe criterii:

banca la care s-a solicitat creditul;

tipurile de credite solicitate (acestea difera de la o banca la alta, fiecare tip de credit are caracteristici distincte in functie de banca ofertanta: durata maxima, dobanda anuala efectiva, suma maxima oferita, destinatia etc.)

valuta in care s-a cerut acordarea creditului (se pot acorda credite in EUR, RON sau USD);

activitatea consultantilor financiari si a conducatorilor de echipe.

Observatie: dat fiind ca firma lucreaza preponderent cu clienti persoane fizice si ca pentru persoanele fizice solicitarea unui credit nu este caracterizata printr-o repetabilitate mare, consideram neconcludenta analiza in functie de criteriul clienti.

Ca masura a activitatii, vom folosi valoarea solicitata. Aceasta este o masura partial aditiva, deoarece insumarea sumelor solicitate se poate face numai la nivel de valuta (sumele in EURO, USD, RON nu se pot insuma intre ele). Dimensiunile vor fi reprezentate de criteriile de analiza enumerate anterior: banci, tipuri de credite, valute, consultanti financiari.

O alta masura a activitatii poate fi reprezentata de comisionul pe care societatea de brokeraj il poate incasa in momentul acordarii creditului. Comisionul este un procent care se aplica la valoarea creditului solicitat, procent care depinde de tipul creditului si de valuta in care se acorda creditul, fara a fi influentat de activitatea echipelor de consultanti financiari.

Deoarece fiecare tip de credit corespunde unei banci, intre aceste doua elemente se poate stabili o relatie parinte-copil. De asemenea, faptul ca un coordonator are in echipa mai multi consultanti permite stabilirea unei astfel de relatii.

Modelul depozitului de date poate fi construit in cele trei variante prezentate anterior, astfel:

stea. un singur tabel de fapte, dimensiunile parinte si copil sunt memorate in acelasi tabel dimensional (fig. 4.1) :

Fig. 4.1 Modelul stea al depozitului de date

arhitectura tip fulg de nea (fig. 4.2):

Fig. 4.2 Modelul fulg de nea al depozitului de date

constelatie: mai multe tabele de fapte si mai multe tabele dimensionale care le partajeaza (fig. 4.3):

Fig. 4.3 Modelul constelatie al depozitului de date

d.     Componentele client

Putem aprecia ca aceste ultime componente sunt la fel de importante ca si depozitul de date propriu-zis, deoarece de folosirea corespunzatoare a acestora depinde calitatea informatiilor ce vor fi puse la dispozitia utilizatorilor finali. Componentele client se pot regasi sub forma unor simple instrumente utilitare de interogare a depozitelor de date, mergand pana la aplicatii complexe ce folosesc modele decizionale avansate pentru a prezenta informatiile.

Exemple de componente client:

serviciul Pivot Table din EXCEL;

utilitarul MDX Sample Application;

aplicatia SQL Server Reporting Services (add-on pentru SQL Server 2000, integrat in SQL Server 2005);

modelele obiect ADOMD si ADOMD.NET, aflat la dispozitia dezvoltatorilor Visual STUDIO .NET;

Componentele unui depozit de date si interactiunile dintre ele sunt reprezentate in figura 4.4:

Fig. 4.4 Componentele unui depozit de date