Vous êtes sur la page 1sur 16

Arhitectura depozitelor de date - s

Depozitul de date reprezint o arhitectur de achiziie i furnizare a informaiilor ctre manageri. Arhitectura depozitelor de date definete ce date vor fi extrase i cum, modul de organizare al datelor, n ce format vor fi furnizate informaiile utilizatorilor i cum. Depozitul de date reunete date din surse interne i externe care pot fi organizate ntr-un singur depozit centraliat i/sau n depozite de date specializate distribuite. Arhitectura unui depozit de date are trei componente principale (figura nr. 1) : depozitul de date propriu-zis i sistemul de gestiune a depozitului de date sistemul de achizitie a datelor din sistemele OLTP i din alte surse sistemul de analiz i prezentare a datelor din depozitul de date

Figura nr. 1 : Componentele principale ale unui depozit de date Arhitectura depozitelor de date poate varia n funcie de situaia specific a fiecarei organizaii. n continuare vom prezenta cteva tipuri de arhitecturi ale depozitelor de date

1. Arhitectura tipic a depozitelor de date


Un depozit de date const ntr-o baz de date de dimensiuni foarte mari coninnd informaiile pe care utilizatorii finali le pot folosi n luarea deciziilor. Figura nr. 2 prezint arhitectura de baz a unui depozit de date. n aceasta situaie datele sunt ncrcate din una sau mai multe surse, iar utilizatorii acceseaz n mod direct depozitul. Analiznd figura reiese c : exist mai multe tipuri de date: metadata (date despre date), date agregate la un nivel primar, datea agregate la un nivel superior, date detaliate sursele de date pentru depozit pot fi: bazele de date opera ionale curente, baze de date vechi arhivate i baze de date externe

datele agregate folosite, dei determin creterea redundanei, ele sunt foarte importante pentru a asigura un timp de rspuns ct mai mic. Totodat putem identifica care sunt etapele pentru construierea depozitului de date: extragerea datelor din bazele de date opera ionale i sursele externe n cadrul depozitului, urmat de copierea datelor cur irea datelor i ncrcarea datelor corecte n cadrul depozitului de date obinerea datelor agregate cerute de utilizatori.

Figura nr. 2. Arhitectura simplificat a unui depozit de date. Observm de asemenea n cadrul arhitecturii prezentate, instrumentele pentru accesare i utilizare, acestea putnd fi folosite de manageri, analiti, specialiti n luarea deciziilor. Aceste instrumente de accesare i utilizare a datelor din depozit sunt asigurate prin software-ul asociat depozitului de date. Instrumentele pot fi: instrumente necesare utilizatorilor (pentru acces rapid la date): de exemplu limbaj de interogare gen SQL, generatoare de rapoarte instrumente specializate pentru asisterea deciziilor (obinerea de grafice, diagrame, etc.): instrumente OLAP i Data Mining Instrumentele OLAP se bazeaz pe reprezentarea multidimensional a datelor (cubul de date) i permite analiza interactiv i rapid a datelor prin operaiuni de tip roll-up, drill-down, slice, dice etc. Utilizatorul poate obine rezultate imediate parcurgnd dinamic dimensiunile cubului de date, lucrnd cu niveluri diferite de sintez/ detaliere.

Instrumentele de tip data mining asigur transformarea datelor n cunotine. Se utilizeaz tehnici ale analizei statistice sau de inteligen artificial care permit descoperirea de corelaii, reguli, cunotinte utile sprijinirii deciziilor. ntreaga gama de instrumente software asociate depozitelor de date este prezentat n figura urmtoare:

Figura nr. 3. Componentele software ale depozitelor de date n partea stng sunt evideniate componentele din partea de back-end (instrumente de extragere i transformare), iar in partea dreapt componentele din partea de front-end (instrumente de accesare i utilizare a datelor).

2. Arhitectura complex a depozitelor de date


O arhitectur mai complex este aceea n care se folosete un sistem de purificare i integrare a datelor precum i multiple sisteme data mart proiectate pentru compartimente ale ntreprinderii. Figura nr. 4 prezint un sistem complex de data warehouse. Aa cum putem observa i din figur, sursele de date pot fi sisteme operaionale i fiiere. Acestea sunt extrase, curate, stocate i integrate n depozitul de date. Depozitul de date refer de asemenea i mai multe sisteme data mart proiectate pentru compartimentele nterprinderii. Datele din cadrul depozitului de date sunt n final folosite de utilizatori pentru efectuarea de analiz, obinerea de rapoarte i transformarea datelor n cunotine (mining).

Figura nr. 4: Depozit de date cu arhitectur complex Depozitul de date prezint trei nivele de realizare: Modulul operaional Datele unei companii sunt de obicei pstrate sub form diferit la locaii diferite. Aceste date pot proveni de la aplicaii de mainframe sau de la sisteme distribuite din cadrul companiilor cum ar fi sisteme de gestiune a comenzilor, de eliberare a facturilor, de contabilitate financiar. Indiferent de originea lor, datele trebuie s fie colectate i aduse ntr-o form consistent pentru a putea fi folosite. Acest proces se numete transformarea datelor i reprezint baza pe care se construiete un depozit de date consistent, de nalt calitate. Transformarea datelor presupune un proces de extragere, condiionare, curare, fuziune, unificare pe adres, punctare, validare i ncrcare. Modulul central al depozitului de date Partea central a unui depozit de date l constituie sistemul de gestiune al bazei de date i serverul principal pe care acesta ruleaz. Din punct de vedere al implementrii unui depozit de date exist n acest moment dou tendine: una ar fi implementarea unui sistem distribuit, descentralizat unde datele sunt pstrate n uniti independente (Independent Data Marts) fiecare conin datele relevante pentru un anumit aspect al operaiilor unei instituii. O a dou posibilitate ar fi implementarea unei surse de date unice, centralizate la care au acces utilizatorii din toate deparetamentele unei instituii. Modulul strategic, de afaceri Valoarea final a unui depozit de date este determinat de avantajele pe care le ofer utilizatorului final n diferite procese de luare a deciziilor i analiza. Prin folosirea diferitelor

unelte de acces la informaie i data mining disponibile pe pia, utilizatorii pot obine informaii care i vor ajuta n procesele de stabilire a strategiei firmei.

3. Arhitectura depozitelor de date pe trei niveluri


Adesea, n depozitele de date se adopt o arhitectur pe trei niveluri 1 (bottomtier, middle-tier, top-tier), ca n figura nr. 5. Nivelul de jos (bottom-tier) este constituit din serverul depozitului de date i este, n multe cazuri, un sistem de baze de date relaionale. n cadrul acestui nivel datele sunt extrase, curite, transformate i ncrcate n depozitul de date. Datele din bazele de date operaionale i din sursele externe sunt extrase utiliznd programe de aplicaii tip interfa cunoscute sub numele de ,,gateways". Un gateway este sprijinit de SGBD-ul de baz i permite programelor client s genereze cod SQL pentru a fi executat de server. Exemplele gateways includ ODBC (Open DataBase Connection) si OLE-DB (Open Linking and Embedding for DataBases) la Microsoft i JDBC (Java DataBase Connection). n acest mod datele sunt extrase, curite, transformate i ncrcate n depozitul de date. De asemenea, trebuie luat n considerare i modalitatea de mprosp tare a datelor
1

. Han, J., Kamber, M., Data Mining: Concepts and Techniques, Morgan Kaufmann Publishers, San Francisco, 2001.

din depozit, pe m sura trecerii timpului. Dac , de exemplu, dimensiunea timp are n structura lun , trimestru, an, nseamn c la sfaritul fiecarei luni, a fiecarui trimestru sau a fiecarui an datele din sistemul opera ional trebuie s mprospateze depozitul de date Nivelul mediu (middle-tier) bazat pe un server OLAP care este implementat n mod obinuit, utiliznd fie un model relaional OLAP (ROLAP), fie un model multidimensional(MOLAP). Modelul ROLAP este o extensie a unui SGBDR care mapeaz opera iunile pe date multidimensionale la opera iunile rela ionale standard. Modelul MOLAP este dedicat i implementeaz direct descrierea datelor i a opera iunilor multidimensionale. Nivelul superior(top-tier) este nivelul client care conine instrumente pentru generarea interogrilor i a rapoartelor, instrumente de analiz i/sau instrumente data mining(de exemplu, analiza trendului, predicii etc.).

Figura nr. 5 Arhitectura DataWarehouse cu 3 niveluri

4. Un alt tip de arhitectur pe trei niveluri


Datele din bazele de date operaionale reprezint sursa pentru orice aplicaie de afacere, dar de obicei datele nu sunt n formatul corespunztor pentru a putea fi utilizate n procesul de luare a deciziilor. Indiferent dac implementm un depozit de date, un data mart, sau un sistem suport decizie, scopul este ntotdeauna acelai: transformarea datelor n informaii ce pot fi folosite n procesul zilnic de luare a deciziilor. Depozitarea datelor pe trei niveluri semnific faptul c exist 3 niveluri de date,

fiecare dintre ele proiectate pentru a folosi diferitelor cerine ale utilizatorilor, aa cum arat i figura nr. 6.2

Figura nr. 6: Un alt tip de arhitectur pe 3 niveluri Nivelul 1 este reprezentat de sistemele operaionale ce gestioneaz date curente i care sunt folosite pentru procesarea tranzac iilor i interog rilor: stocuri, produc ie, pl i, etc Nivelul 2 este reprezentat de depozitul de date. n cadrul acestui nivel, datele sunt curite i prelucrate pentru a suporta una sau mai multe data mart-uri. Acest nivel poate const din mai multe structuri de date: ODS(operational data store) i depozite de date. ODS-urile integreaz datele din sistemele tranzacionale, fiind de asemenea utile i pentru prelucrri de tip suport de decizie i prelucrri analitice care rspund cerinelor managementului operativ. Depozitele de date furnizeaz date integrate, folosite n special pentru sprijinirea lurii deciziilor n cadrul unei organizaii. Aceste nivel este deseori iniial ignorat, sau uitat, fiind adugat mai trziu, atunci cnd dimensiunea aplicaiilor suport decizie se extinde incluznd mai multe data mart-uri. Nivelul 3 se numete data mart. Acest nivel este specializat pentru un anumit department, sau grup de utilizatori ca de exemplu: vnzri/analiti marketing,analiti financiari, relaii cu clienii, etc. Motivele pentru care aceast arhitectur nu este folosit sunt complexitatea ei, costurile, iar implementarea ei dureaz timp ndelungat. Concepia greit este c depozitul de date trebuie s fie construit n totalitate nainte ca realizarea data mart-ului inial s nceap. Acest lucru nu e adevrat. Realizarea n mod incremental a depozitului de date s-a dovedit a fi o metod folosit cu succes, putnd ndeplini cerinele n continu dezvoltare ale clienilor.
2

Agarwal, K. Data Warehousing Multi Tier Approach, White Paper, Scarlet, Infotech Ltd

n concluzie arhitectura pe trei niveluri, presupune preluarea datelor din cadrul sistemelor de date operaionale, transformarea, extragerea i curarea acestor date ntr-un depozit de date, acesta fiind folosit pentru construirea uneia sau mai multor data mart-uri, ce ndeplinesc cerinele utilizatorilor finale.

5. Arhitectura Oracle Warehouse


Oracle Warehouse este o suit de produse i servicii care acoper ntregul proces de definire, proiectare i implementare a depozitului de date. Figura de mai jos arat componentele suitei Oracle:

Figura nr 7. Oracle Warehouse

Orice Sursa. Datele colectate n depozitul de date Oracle pot proveni dintr-o varietate de surse, att operaionale(interne) ct i externe. n mod obinuit datele din depozitul de date provin din sisteme operaionale interne. Totusi, sursele externe de date: (demografice, economice, internet) devin tot mai populare i n curnd vor furniza tot mai multe date depozitelor de date. Sursele interne i externe trebuie combinate pentru a furniza utilizatorilor finali acces la ambele tipuri de date. Orice Date. Datorit profilului utilizatorilor depozitului de date, proiectanii de sisteme sunt pui n fata unui set divers de cerine. Accesul la date trebuie s fie rapid, direct si intuitiv. Majoritatea utilizatorilor necesit interogri direte si analize n detaliu, n timp ce ali utilizatori au cerine de analize complexe. Sursele de date trebuie s fie capabile de manevrarea a noi formate de date: date audio, video, texte i spaiale. Mai mult, cerine de volume de date istorice mari pot conduce la baze de date foarte mari (Very Large DataBases VLDB). Pentru a satisface aceste cerine, Oracle furnizeaz att soluii relationale (Oracle) ct i multidimensional (Express Server). Orice Acces. Oracle ofer o suit de instrumente ce permite tuturor utilizatorilor accesul la date, inlusiv: interogri i raportri ad-hoc, analiza n detalii, modelare, previziune i analize de tip "ce se intimpl dac". Majoritatea utilizatorilor necesit instrumente intuitive ce permit accesul rapid la date pentru luarea deciziilor. O categorie separat de utilizatori necesit instrumente sofisticate de analiz pentru stabilirea strategiilor pe termen lung. Luate mpreun, necesitatea de accesare a informaiilor se regasete n ntreaga organizaie. Depozitele de date tind s se extind de la domeniul analitilor la o categorie mai larg de utilizatori. n acest context, decizia asupra instrumentelor ce vor fi folosite devine critic. Pentru a raspunde tuturor cerinelor de analiz ale Ministerului Finanelor, Oracle furnizeaz un set complet de instrumente de raportare i analiz ce include: setul de instrumente de analiz Oracle Express si Oracle Discoverer:

Oracle Express ServerTM este serverul multimensional ce ocup n prezent locul 1 pe pia n domeniu, i este baza tuturor aplicaiilor Express. Oracle Express AnalyzerTM este instrumentul de analiz cu posibilitatea de publicare pe Web, destinat utilizatorilor finali, care asigur posibiliti de analiz complex cum ar fi: previziuni, modelare i analize de tip "ce se ntmpl daca". Oracle Express ObjectsTM este un mediu complex de dezvoltare de aplicaii OLAP, orientat obiect, integrat cu Express Analyzer.

Oracle DiscovererTM este un instrument de interogare i raportare cu posibilitate de publicare pe Web, destinat utlizatorilor finali, ce permite accesul rapid la datele stocate relaional n depozitul de date.

Figura 8 - Arhitectura Oracle Warehouse

Metadatele i rolul acestora ntr-un depozit de date - d Poate cea mai important component a depozitului de date o reprezint nivelul metadatelor. Pentru a putea utiliza depozitul de date, utilizatorii trebuie s cunoasc ce date se gsesc aici, iar metadatele nu sunt altceva dect date despre date, date care descriu coninutul depozitului i furnizeaz, asemenea fielor dintr-o bibliotec, trimiteri directe la date. Tot la nivelul metadatelor se definesc i 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, coninnd informaii despre proveniena datelor, algoritmii de sumarizare, statistici de utilizare i multe altele. Cand se utilizeaz ntr-un depozit de date, metadatele sunt date care definesc obiectele depozitului. Metadatele sunt create pentru numele de date i definiiile din depozit. Metadatele adiionale sunt create pentru a asocia intervale de timp la datele extrase i alte cmpuri care vor fi adugate prin curirea datelor sau prin procesele de integrare. Un depozit de metadate trebuie s conin:

O descriere a structurii datelor din depozit, care include schema depozitului, dimensiunile, ierarhiile, definiiile datelor derivate; Metadatele operaionale, care includ date privind evoluia n timp (istoricul datelor i secvena de transformare aplicat asupra lor), circulaia datelor (active, arhivate sau terse) i informaii de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erori, linii de antet etc.); Algoritmi utilizai pentru sumarizare, care includ msura i dimensiunea algoritmilor definii, date despre granularitate, partiii, arii de subiecte, agregri, sumarizri, rapoarte i filtre predefinite; Maprile de la mediul operaional la depozitul de date care includ bazele de date surs i coninutul lor, descrierile gateways, partiionarea datelor, extragerea datelor, curirea datelor, regulile de ntreinere i securitate a datelor; Date relative la performanele sistemului care include indici i profiluri care mbuntesc accesul la date i performanele de cutare; Metadate economice (Business metadata), care includ termeni economici i definiii.

Un depozit de date conine diferite niveluri de sumarizare, din care metadata este un tip. Alte tipuri includ date detaliate n mod curent (care sunt tot timpul pe disc), date detaliate anterior (care sunt n mod uzual stocate pe un suport terial), date uor sumarizate i date puternic sumarizate (care pot sau nu pot exista din punct de vedere fizic). Metadatele joac un rol foarte diferit fa de alte date din depozitul de date i sunt importante din mai multe raiuni. De exemplu, metadatele sunt utilizate pentru a direciona help-ul ntr-un DSS, localiznd coninutului unui depozit de date, ca ghid n maparea datelor, cnd se face transformarea de la mediul operaional la mediul data warehouse, ca ghid pentru algoritmii utilizai la sumarizare etc. Abstractizarea lucrurilor i obiectelor din lumea real constituie o practic des ntlnit. Un produs concret este abstractizat i descris prin proprietile sale (atributele specifice), de exemplu denumire, culoare, greutate, volum, pre. O persoan poate fi de asemenea abstractizat i descris prin: nume i prenume, vrst, ocupaie etc. Atunci cnd elementul avut n vedere nu are o reprezentare concret crete complexitatea abstractizrii. De exemplu, o tranzacie bancar poate fi descris prin valoarea tranzaciei, valuta n care s-a efectuat tranzacia, tipul tranzaciei, data i ora. Descrierea acestor proprieti ale datelor se

face prin intermediul metadatelor. Exemple de metadate: Metadate referitoare la cmpurile unui depozit de date (figura 4); Metadate referitoare la dimensiunile depozitului (figura 5).

Ex: metadate pentru cmpurile depozitului de date Denumire cmp. Denumirea cmpului, aa cum va fi folosit n tabela fizic; Titlu. Denumirea cmpului, aa cum va aprea pentru utilizatori; Tipul datei. Tipul de date pentru cmpul respectiv, suportat de sistemul de gestiune al bazelor de date; Tipul indexului. Tipul de index care va fi folosit pentru acest cmp; Key? Specific dac este un cmp cheie n tabela dimensiune; Format. Formatul cmpului; Descriere. O descriere sau o definiie a cmpului. Fig. 4. Exemplu de metadate pentru cmpurile depozitului de date

Ex: metadate pentru tabelele dimensiuni ale depozitului de date Denumire. Numele tabelei fizice care va fi folosit n depozitul de date; Titlu. Numele dimensiunii; acest titlu va fi folosit de ctre utilizatori pentru a face referire la dimensiune; Descriere. Definiia standard a dimensiunii; Tipul folosirii. Indic dac un obiect al depozitului de date este folosit ca fapt sau ca dimensiune; Sursa. Indic sursa primar de date pentru dimensiune; Online? Indic dac tabela fizic este populat corect i dac este disponibil pentru utilizatorii depozitului de date. Fig. 5. Exemplu de metadate pentru dimensiunile depozitului de date n domeniul data warehouse, metadatele se aplic pentru sursele de date, pentru programele i regulile de extragere i transformare, pentru structura datelor i pentru coninutul propriu-zis al depozitului de date. Importana metadatelor pentru depozitul de date reiese din urmtoarele considerente: Metadatele stabilesc contextul depozitului de date; Metadatele uureaz procesul de analiz; Metadatele sunt o form de auditare a transformrii datelor; Metadatele menin i cresc calitatea datelor.

Metadatele ajut administratorii i utilizatorii depozitului s localizeze i s neleag secvenele de date att n sistemele surs ct i n structura depozitului. De exemplu o secven de tipul dat 06/09/2004 poate semnifica date diferite n funcie de convenia folosit pentru reprezentarea datei calendaristice: 6 Septembrie 2004 (n formatul european) sau 9 Iunie 2004 (n formatul american). Dac metadatele care descriu formatul cmpului dat calendaristic sunt disponibile, atunci se elimin orice ambiguitate legat de acest aspect. n sistemele operaionale, dezvoltatorii de software i administratorii bazelor de date lucreaz cu metadate n fiecare zi. Toat documentaia tehnic a sistemelor surs reprezint ntr-un fel sau altul metadate. Ele rmn totui transparente pentru majoritatea utilizatorilor sistemelor operaionale, ei percepnd n general sistemul ca pe o cutie neagr ce ofer o interfa prin intermediul creia trebuie manevrat. Acast situaie este total schimbat n cazul depozitelor de date, unde utilizatorii sistemelor de asistare a deciziei trebuie s neleag nainte de toate coninutul depozitului, pentru ca apoi s beneficieze de informaiile necesare. Procesul clasic de analiz cuprinde diferite etape: identificarea datelor, obinerea datelor, interpretarea i analiza datelor pentru a obine informaii, prezentarea informaiilor i recomandarea unei direcii de aciune. Pentru ca depozitul de date s fie folositor analitilor din ntreprindere, metadatele trebuie s ofere utilizatorilor finali informaii care s-i ajute n parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie s ajute utilizatorii s gseasc rapid datele n depozit i s interpreteze corect datele obinute prin oferirea informaiilor referitoare la formatul i semnificaia datelor. De exemplu, dac o secven de date din tabela de fapte a depozitului de date este denumit Profit, atunci utilizatorul trebuie s poat consulta metadatele depozitului pentru a afla care este formula de calcul a profitului. Metadatele sunt o form de auditare a transformrii datelor. Metadatele documenteaz transformarea datelor surs n date ale depozitului. Metadatele trebuie s fie capabile s explice modul n care o secven de date din depozit este derivat din sistemele operaionale. Toate regulile care guverneaz transformarea datelor n noi valori sau noi formate sunt considerate a fi metadate. Aceast form de audit este necesar atunci cnd utilizatorii trebuie s aib ncredere n veridicitatea i calitatea datelor din depozit. De asemenea este important ca utilizatorii s-i poat da seama de unde provin datele existente n depozit. Este de dorit ca, pe baza acestor metadate, anumite produse s poat genera programe de extragere i transformare pentru cei care se ocup cu componenta back-end a depozitului de date. Metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea valorilor valide pentru fiecare cmp din depozit. nainte de a fi efectiv ncrcate n depozit, datele pot fi revzute i erorile pot fi corectate; regulile de corecie a erorilor pot fi

documentate tot prin metadate. Tipuri de metadate: Metadate administrative. Acestea conin descrieri ale bazelor de date surs i ale coninutului, ale obiectelor depozitului de date i ale regulilor folosite pentru a transforma datele din sistemul surs n depozit. Printre exemple de astfel de metadate enumerm: descrirea tuturor sursele de date folosite, trecerea cmpurilor surs n cmpuri destinaie, schema depozitului de date, structura datelor din back-end, programe i instrumente back-end, reguli i formule de calcul, reguli de securitate i de acces. Metadate pentru utilizatorii finali. Aceste metadate au rolul de a ajuta pe utilizatori s-i creeze propriile lor interogri i s interpreteze rezultatele. Pentru aceasta, ei au nevoie s cunoasc definiiile datelor din depozit, descrierea lor, precum i orice ierarhie care poate exista n diferite dimensiuni. Exemple de astfel de metadate sunt urmtoarele: coninutul depozitului de date, rapoarte i interogri predefinite, definiiile ierarhiilor, calitatea datelor, istoricul ncrcrii depozitului de date, reguli de eliminare. Metadate pentru optimizare. Aceast categorie de metadate are rolul de a crete performanele depozitului de date. Exemple de astfel de metadate sunt: definiiile agregrilor i colecii de statistici. Un depozit de date conine date pentru diferite perioade de timp i de aceea este important s avem n vedere efectul pe care l poate avea timpul asupra regulilor de trecere a cmpurilor surs n cmpuri destinaie, asupra agregrilor etc. Utilizatorii trebuie s aib acces la metadatele corecte pentru perioada de timp pe care o studiaz. Echipa IT are nevoie de aceste informaii pentru a putea ntreine depozitul de date; ceea ce la prima vedere ar prea s fie o eroare n transformarea datelor poate fi de fapt rezultatul schimbrii regulilor de transformare a datelor. De aceea este important ca metadatele s fie corect gestionate din punct de vedere al versiunilor. Dei n mod tradiional metadatele reprezint o component dezvoltat la sfritul proiectului, la ora actual exist o tendin puternic de a atribui metadatelor un rol mai activ. Utilizatorii instrumentelor de extragere i transformare pot specifica modul de trecere din cmpurile surs n cmpurile destinaie i pot introduce toate regulile care guverzeaz transformarea. Tabelul surs-int poate servi ca baz pentru generarea codului de program folosit apoi la extragerea i transformarea efectiv a datelor. Utilizatorii instrumentelor pentru calitatea datelor pot specifica valorile valide pentru diferite secvene de date att n sistemele

surs, ct i n depozitul de date. Aceste instrumente pot folosi metadatele ca baz de pornire n identificarea i corectarea erorilor. Utilizatorii specific metadatele referitoare la schema depozitului de date (fapte, dimensiuni etc), iar aplicaile pot folosi aceste specificaii ca intrare pentru a genera efectiv schema (tabele, indeci, agregri etc.).