Definiţii: Business Intelligence, Data Warehouse, olap arhitectura unui depozit de date

• Definiţii: Business Intelligence, Data Warehouse, OLAP

• Arhitectura unui depozit de date

• Modelul logic dimensional pentru depozite de date

• Business Intelligence (BI) este abilitatea unei întreprinderi de a studia comportarea şi acţiunile trecute, cu scopul:

• de a stabili poziţia şi situaţia curentă a organizaţiei şi
• de a prezice sau modifica ceea ce se va întâmpla în viitor

• BI foloseste depozitele de date (data warehouse) care conţin informaţii necesare pentru luarea deciziilor prin sisteme:

• Decision Support Systems (DSS)
• On-Line Analytical Processing (OLAP)

• BI şi data warehouse se înscriu în domeniul mai general “Corporate Information Factory” (CIF), care s-a dezvoltat în ultimii 20 ani

• Aceste sisteme au îmbunătăţit sistemele de informaţii executive (Executive Information Systems - EIS), folosite pentru analiza activităţii de către conducerea organizaţiilor

• ERP – Enterprise Resource Planning – un subsistem al BI, care se ocupă de planificarea resurselor folosind, de asemenea, data warehouse

BI se bazează pe data warehouse, care trebuie să suporte:

• BI se bazează pe data warehouse, care trebuie să suporte:

• tehnologii de prelucrare multiple: interogări, rapoarte, analiză multidimensională, explorarea datelor
• niveluri de granularitate multiple: atât date detaliate (pentru operații tranzacționale), cât și date agregate (rezumate - pentru operații de analiză și explorare)

Un depozit de date este o colecţie de date orientate pe subiect (subject-oriented), integrate, non-volatile, variabile în timp (timevarying), care constitue suport pentru luarea deciziilor într-o întreprindere (organizaţie)

• Un depozit de date este o colecţie de date orientate pe subiect (subject-oriented), integrate, non-volatile, variabile în timp (timevarying), care constitue suport pentru luarea deciziilor într-o întreprindere (organizaţie)

Datele sunt integrate:

• Datele sunt integrate:

• Depozitele sunt alimentate dintr-o multitudine de surse separate
• La alimentare, ele sunt curăţate, convertite, transformate, rezumate
• Rezultă o singură imagine integrată a datelor pentru intreaga companie
• Datele sunt stocate astfel încât să faciliteze utilizarea lor în mai multe aplicaţii
• Se respectă convenţii de nume, de structură, de măsuri

Datele sunt nonvolatile

• Datele sunt nonvolatile

• În depozite datele se încarcă în anumite momente de timp şi sunt stocate pe perioade lungi de timp

• Depozitele de date stochează date istorice

• Datele sunt semnificative pentru un anumit moment de timp (time-variancy)

• De aceea înregistrările contin o informaţie privind momentul sau perioada de timp pentru care sunt valabile

Este un aspect important în proiectarea depozitelor de date, deoarece determină volumul ocupat de date

• Este un aspect important în proiectarea depozitelor de date, deoarece determină volumul ocupat de date

• Granularitatea se referă la nivelul de detaliu (sau de rezumare) a unei unităţi de date din depozit:

• Cu cât nivelul de detaliu este mai mare, cu atât granularitatea este mai mică (mai fină) – de ex. o simplă tranzacţie este de granularitate mică
• Cu cât rezumarea este mai puternică, cu atât granularitatea este mai mare; de ex. suma tuturor tranzacţiilor dintr-o lună

Nivelul de granularitate fină (detaliere mare) se foloseşte în bazele de date operaţionale şi ca date nerezumate (sau slab rezumate) în depozite

• Nivelul de granularitate fină (detaliere mare) se foloseşte în bazele de date operaţionale şi ca date nerezumate (sau slab rezumate) în depozite

• Pe nivelul de granularitate ridicat (date puternic rezumate) se pot stoca date pe perioade îndelungate şi se folosesc pentru decizii de organizare

Se pot identifica mai multe niveluri de structură ale unui depozit de date: nivelul vechi, curent, uşor rezumat, puternic rezumat

• Se pot identifica mai multe niveluri de structură ale unui depozit de date: nivelul vechi, curent, uşor rezumat, puternic rezumat

Bazele de date operaţionale suportă prelucrarea tranzacţiilor (On-Line Transaction Processing – OLTP)

• Bazele de date operaţionale suportă prelucrarea tranzacţiilor (On-Line Transaction Processing – OLTP)

• Tranzacţiile sunt operaţii atomice care accesează (în general) un număr mic de înregistrări, pentru operaţiile zilnice ale întreprinderii
• Bazele de date operaţionale sunt proiectate să maximizeze numărul de tranzacţii/secundă (throughput) şi să minimizeze conflictele concurenţiale

Depozitele de date suportă prelucrarea analitică a datelor (On-Line Analitical Processing - OLAP)

• Depozitele de date suportă prelucrarea analitică a datelor (On-Line Analitical Processing - OLAP)

• Depozitele de date conţin date consolidate, rezumate din mai multe baze de date operaţionale, pe perioade de timp îndelungate
• Depozitele de date sunt mult mai mari (cu cel puţin un ordin de mărime) decât bazele de date operaţionale

• Cerinţele OLAP diferă de cerinţele OLTP

Operaţii tipice:

• Operaţii tipice:

• În OLTP se accesează un număr mic de înregistrări
• În depozite de date se accesează mii sau milioane de linii

• Modificarea datelor:

• Sistemele OLTP sunt în permanenţă la zi, actualizate de utilizatori
• În depozitele de date detele sunt actualizate regulat de către procesul ELT (Extract, Load Transformation)

Descrierea datelor  metadata, stocate într-un repertoriu (repository)

• Descrierea datelor  metadata, stocate într-un repertoriu (repository)

• Toolset-uri de monitorizare şi administrare

Colectarea datelor în depozite implică:

• Colectarea datelor în depozite implică:

• Extragerea datelor din baze de date operaţionale multiple şi din surse externe
• Curăţarea (cleanup), transformarea şi integrarea datelor
• Încărcarea datelor (load)
• Împrospătarea datelor (refresh); preluarea noilor date din surse; transferul datelor învechite către alte suporturi de date mai lente

• Datele din depozite sunt gestionate de unul sau mai multe servere de depozite (warehouse servers)

• Mai există şi centre de date (data marts) care conţin date specifice anumitor departamente şi servere pentru acestea (data mart servers)

• Depozitele şi centrele de date reprezintă datele de intrare pentru toolset-uri de:

• Interogare
• Analiză (OLAP)
• Explorare (data mining)

Cel mai răspândit model conceptual pentru depozitele de date este modelul dimensional care specifică un set de “subiecte”; acestea:

• Cel mai răspândit model conceptual pentru depozitele de date este modelul dimensional care specifică un set de “subiecte”; acestea:

• pot fi definite prin valori (măsuri) numerice
• sunt analizate în sistemele de decizie
• Exemple de subiecte (facts): vânzări, buget, venit, inventar

• Fiecare măsură (subject, fact) depinde de un set de dimensiuni

• De exemplu, pentru “măsura” vânzări (SALES), dimensiunile pot fi: oraşul, numele produsului, data (calendaristică)
• O dată din modelul dimensional poate fi văzută ca un punct (valoare) într-un spaţiu multidimensional

• Orice măsură poate fi agregată pe oricare dintre dimensiuni; de exemplu vânzările totale pe o anumită regiune, perioadă de timp sau produs

• Pentru sistemele OLTP se folosesc scheme logice deduse din diagrama E-A (Entitate-Asociere)

• În depozite de date şi sisteme OLAP se foloseşte modelarea dimensională

În Oracle 11g se pot construi depozite de date care se folosesc pentru:

• În Oracle 11g se pot construi depozite de date care se folosesc pentru:

• Raportări şi analize
• Prelucrarea analitică (OLAP)
• Explorarea datelor (data mining)

OWB permite proiectarea şi construirea depozitelor de date, a centrelor de date (data mart) şi a aplicaţiilor BI (Business Intelligence)

• OWB permite proiectarea şi construirea depozitelor de date, a centrelor de date (data mart) şi a aplicaţiilor BI (Business Intelligence)

• OWB conţine un set de instrumente grafice care asistă utilizatorul în proiectare, pentru crearea obiectelor memorate într-un spaţiu de lucru (workspace) memorat în baza de date Oracle

• Toolset-ul Design Center permite importul obiectelor sursă şi proiectarea proceselor ETL şi a obiectelor de corespondenţă (mapping)
• Un mapping (mapare) defineşte un flux de date de la sursă la depozitul ţintă (target warehouse)
• OWB generează codul pentru extragerea, transferul şi încărcarea datelor (procesul ETL)
• Toolset-ul Repository Browser asigură o interfaţă Web pentru inspectarea metadata din depozit
• Control Center Service – controlează deploymentul bazei de date target

• Schema depozitului creat (target schema) conţine: codul generat, cuburile, dimensiunile, tabelele, vederile, mapările şi pachetele care execută procesul ETL

Modelul dimensional se defineşte printr-un CUBE, care conţine una sau mai multe măsuri (measures), determinate de mai mulţi parametri, fiecare descris printr-o dimensiune

• Modelul dimensional se defineşte printr-un CUBE, care conţine una sau mai multe măsuri (measures), determinate de mai mulţi parametri, fiecare descris printr-o dimensiune

• Ca măsuri (ale unei activităţi) sunt considerate producţia, vânzările, profiturile, şi orice alt indicator care poate fi monitorizat

• Fiecare dimensiune defineşte atributele dimensiunii, nivelurile de agregare, şi ierarhia intre niveluri

Datele unui CUBE pot fi interpretate diferit de grupuri de utilizatori prin decuparea “feliilor” din cub pe diferite dimensiuni:

• Datele unui CUBE pot fi interpretate diferit de grupuri de utilizatori prin decuparea “feliilor” din cub pe diferite dimensiuni:

• Managerii regionali: studierea “feliilor” orientate pe pieţe regionale (market);
• Managerii de producţie: studierea “feliilor” orientate pe produs (product);

Schema stea conţine:

• Schema stea conţine:

• CUBE – SALES
• Dimensiunile:
• PRODUCTS
• PROMOTIONS
• CUSTOMERS
• CHANNELS
• TIMES

CUBE – SALES din modulul SALES_WH, proiectul OWB_DEMO

• CUBE – SALES din modulul SALES_WH, proiectul OWB_DEMO

• Defineşte măsurile:

• AMOUNT
• QUANTITY
• COST

• Referă dimensiunile:

• TIMES
• PRODUCTS
• CHANNELS
• CUSTOMERS
• PROMOTIONS

O dimensiune constă din:

• O dimensiune constă din:

• Atribute ale dimensiunii – fiecare atribut având nume şi tip (de date)
• Un set de niveluri şi un set de ierarhii definite pe aceste niveluri

• Un nivel defineşte un grad se agregare pe dimensiunea respectivă şi fiecare nivel are 2 identificatori:

• Identificator surogat – identifică unic fiecare nivel în cadrul nivelelor dimensiunii (compus dintr-un singur atribut, asemănător cheii primare artificiale a tabelelor relaţionale)
• Identificator business - alcătuit din unul sau mai multe atribute ale nivelului (asemănotor cheii primare naturale a tabelelor relaţionale)

• O ierarhie este o structură care ordonează nivelurile unei dimensiuni, definind asocieri de tipul părinte-fiu

• Exemplu: dimensiunea PRODUCTS din depozitul SALES_WH, care poate fi studiat cu toolset-ul Design Center (din Oracle Warehouse Builder), lansând Data Object Editor

Fiecare nivel are o denumire:

• Fiecare nivel are o denumire:

• PRODUCT
• SUBCATEGORY
• CATEGORY
• TOTAL

• Fiecare nivel are un set de atribute:

• este un subset al setului de atribute ale dimensiunii
• conţine identificatorii surogat şi business

• Ierarhia de niveluri (cu numele PROD_STD)

Pentru implementarea relaţională a schemei stea a unui depozit de date se definesc:

• Pentru implementarea relaţională a schemei stea a unui depozit de date se definesc:

• Tabele de subiecte (fact table) – un fact table pentru fiecare schemă stea; tabelul fact corespunde unui cube din proiectul logic
• Tabele de dimensiuni (numite şi tabele de referinţă) – care corespund dimensiunilor din proiectul logic

Tabelul corespunzător unei dimensiuni:

• Tabelul corespunzător unei dimensiuni:

• Memorează date pentru toate nivelurile dimensiunii
• Conţine o cheie primară care este referită de tabelul fact (implementare a măsurii – cube)
• Coloanele tabelului corespund atributelor nivelurilor dimensiunii
• Numele unei coloane se obţine prin prefixarea numelui atributului cu numele nivelului
• Exemplu: tabelul PRODUCTS

CUBE SALES îi corespunde tabelul relaţional SALES în care:

• CUBE SALES îi corespunde tabelul relaţional SALES în care:

• Fiecărei măsuri îi corespunde o coloană
• Fiecare tabel de dimensiune este referit printr-o cheie străină

Încărcarea datelor din fişiere sau tabele sursă în baza de date ţintă (target) se face prin operaţiile de extragere, transformare şi încărcare (operaţiile ETL)

• Încărcarea datelor din fişiere sau tabele sursă în baza de date ţintă (target) se face prin operaţiile de extragere, transformare şi încărcare (operaţiile ETL)

• Operaţiile ETL se definesc în mapări (mapping)

• O mapare este compusă din operatori şi poate fi definită în cadrul OWB

• Operatorii folosiţi de OWB:

• Operatori sursă/target Oracle – reprezintă obiecte Oracle (tabele, vederi etc.)
• Operatori sursă/target non-Oracle sau remote
• Operatori de flux de date (data-flow) – definesc transformările datelor
• Operatori pre sau post mapping
• Operatori de grupare (pluggable maping operators)

• De exemplu, maparea LOAD_CHANNELS din modulul SALES_WH

• Operatorul CHANNELS_IN este legat (BOUND) la tabelul CHANNELS
• Operatorul CHANNELS_OUT este legat la dimensiunea CHANNELS
• Sunt definite corespondenţe între atributele operatorilor

Un proces flux (flow process) asigură execuţia operaţiilor ETL, conform mapărilor definite

• Un proces flux (flow process) asigură execuţia operaţiilor ETL, conform mapărilor definite

Prin deployment se creează sistemul ţintă din modelul proiectat

• Prin deployment se creează sistemul ţintă din modelul proiectat

• Pentru un depozit proiectat se deploy-ază:

• Tabelele externe
• Cubul şi dimensiunile
• Mapările
• Procesele flux

• În OWB deplymentul se face cu Control Center Manager, care poate fi lansat din Design Center

• Încărcarea datelor în tabelele ţintă se face conform mapărilor şi a proceselor flux definite şi deployate

• Datele încărcate în tabelele ţintă pot fi viyualiyate, selectate etc.

• De exemplu, datele din tabelel schemei sh din baza de date Oracle 11g corespund bazei de date ţintă SALES_WH (cu mici diferenţe de denumiri ale atributelor, provenind din diferenţa de versiuni)

În ODW se folosesc:

• În ODW se folosesc:

• Indexuri B-Tree - pentru indexuri pe atribute chei unice (primare)
• Indexuri bitmap – pentru alte atribute

• Indexuri bitmap – utilizate în depozite, unde sunt mari cantităţi de date şi interogări ad-hoc, dar un nivel scăzut de concurenţă a tranzacţiilor

• În astfel de aplicaţii indexurile bitmap asigură:

• Timp de răspuns bun pentru interogări
• Spaţiu de memorare mai redus decât alte tipuri de indexuri (indexurile bitmap necesită o mică fracţie din dimensiunea datelor, în timp ce indexurile B-tree pot ajunge mai mari decât tabelel însele)

• Un index furnizează pointeri la liniile dintr-un tabel care conţine o anumită valoare a cheii de ordonare a indexului.

• Un index obişnuit conţine lista identificatorilor liniilor care conţin cheia
• Un index bitmap conţine câte un bit pentru fiecare linie din tabel: 1 dacă linia conţine cheia; 0 dacă linia nu conţine cheia
• Indexurile bitmap se pot comprima foarte eficient

Un index bitmap este cu atât mai eficient cu cât numărul de valori distincte ale atributului folosit ca şi cheie de indexare este mai mic

• Un index bitmap este cu atât mai eficient cu cât numărul de valori distincte ale atributului folosit ca şi cheie de indexare este mai mic

• deoarece pentru fiecare valoare distinctă a atributului cheie a indexului se memorează un şir cu un număr de biţi egal cu numărul de linii

• Exemplu: în tabelul CUSTOMERS (cust_id, cust_gender, cust_marital_status, cust_income_level, ....)

• Se pot pune indexuri bitmap pe atributele:

• cust_gendre – 2 valori posibile (F, B)
• cust_marital_status – 5 valori posibile (null, single, married, divorced, widow)
• cust_income_level – 12 niveluri posibile

• Pe atributul cust_id nu se poate defini un index bitmap, deoarece are număr mare de valori distincte, dar se poate defini indexul primar (de tip B-Tree)

Se consideră o parte (selecţie) din tabelul CUSTOMERS

• Se consideră o parte (selecţie) din tabelul CUSTOMERS

• Dacă acesta ar fi tot tabelul, atunci indexul bitmap pe atributul cust_gendre ar arăta astfel:

Indexul bitmap pe atributul cust_marital_status pe porţiunea selectată din tabelul CUSTOMERS arată în felul următor:

• Indexul bitmap pe atributul cust_marital_status pe porţiunea selectată din tabelul CUSTOMERS arată în felul următor:

Funcţiile de agregare se pot folosi ca extensii ale clauzei GROUP BY:

• Funcţiile de agregare se pot folosi ca extensii ale clauzei GROUP BY:

• ROLLUP
• CUBE
• GROUPING
• GROUPING SET

• Extensia ROLLUP a clauzei GROUP BY permite instrucţiunii SELECT să calculeze niveluri de subtotal multiple peste un grup de dimensiuni

• Exemplu de interogare cu agregare prin clauza GROUP BY fără nici o extensie (în schema sh, folosind SQL Developer):

Aceeaşi interogare în care clauza GROUP BY are extensia ROLLUP

• Aceeaşi interogare în care clauza GROUP BY are extensia ROLLUP

• Se obţin:

• Liniile cu vânzările trimestriale, pe categorii de produse, în intervalul dat
• Totalul pentru toate categoriile, pe fiecare trimestru
• Totalul pe toate categoriile, pe tot intervalul

Extensia CUBE a clauzei GROUP BY generează toate subtotalurile care pot fi calculate dintr-un CUBE pe dimensiunile specificate;

• Extensia CUBE a clauzei GROUP BY generează toate subtotalurile care pot fi calculate dintr-un CUBE pe dimensiunile specificate;

• Exemplu – adăugând extensia CUBE în clauza GROUP BY se obţin:

• Liniile cu vânzările trimestriale, pe categorii de produse, în intervalul dat
• Toate totalurile posibile pentru vânzările trimestriale şi pe categorii de produse

Interogare stea: o joncţiune între tabelul fact şi unul sau mai multe tabele de dimensiuni, folosind cheile străine din tabelul fact

• Interogare stea: o joncţiune între tabelul fact şi unul sau mai multe tabele de dimensiuni, folosind cheile străine din tabelul fact

• Nu se pot face joncţiuni între tabele de dimensiuni

• Pentru optimizarea interogărilor stea foloseşte “transformarea stea”:

• Se defineşte câte un index bitmap în tabelul fact pentru fiecare cheie străină
• Exemplu: în tabelul fact SALES sunt definite indexuri pe cheile străine: time_id, channel_id, cust_id, prod_id, and promo_id

Pentru execuţia interogării folosind transformarea stea, se transformă interogarea stea în sub-interogări pe fiecare dimensiune:

• Pentru execuţia interogării folosind transformarea stea, se transformă interogarea stea în sub-interogări pe fiecare dimensiune:

• SELECT ... FROM sales
• WHERE time_id IN
• (SELECT time_id FROM times WHERE calendar_quarter_desc = '1999-Q1')
• AND cust_id IN
• (SELECT cust_id FROM customers WHERE cust_state_province='CA')
• AND channel_id IN
• (SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog'));

• Se execută joncţiunea între tabelul fact şi fiecare tabel de dimensiune rezultat prin selecţie folosind indexul bitmap corespunzător dimensiunii respective

• Se obţine câte un bitmap pentru fiecare dimensiune, fiecare valoare 1 din bitmap reprezentând mulţimea liniilor din tabelul sales care satisface condiţia corespunzătoare dimensiunii respective

• Se execută operaţia AND între bitmap-urile de dimensiuni pentru a obţine mulţimea liniilor rezultat

Oracle extinde SQL cu următoarele funcţii pentru analiză şi raportare:

• Oracle extinde SQL cu următoarele funcţii pentru analiză şi raportare:

Funcţiile RANK şi DENSE RANK permit aflarea rangului unui articol dintr-un grup dat

• Funcţiile RANK şi DENSE RANK permit aflarea rangului unui articol dintr-un grup dat

• Ex: să găsim primele 3 produse cel mai bine vândute în California anul trecut

• Sintaxa:

• RANK ( ) OVER ( [query_partition_clause] order_by_clause )
• DENSE_RANK ( ) OVER ( [query_partition_clause] order_by_clause )

• Dacă lipseşte clauza query_partition_clause, rangul se aplică întregului result set

• Diferenţa dintre cele 2 funcţii:

• La RANK: urmatorul rang are valoarea obţinută prin incrementarea valorii rangului precedent cu numărul de aticole de pe rangul precedent
• La DENSE_RANK, următorul rang are valoare incrementata cu 1 fată de rangul precedent, indiferent câte articole sunt asignate acestuia

Sintaxa:

• Sintaxa:

• {LAG | LEAD} ( value_expr [, offset] [, default] )
• OVER ( [query_partition_clause] order_by_clause )

• Exemplu:

OLAP şi Data Mining sunt integrate în serverul Oracle; pot fi privite ca modalităţi complementare de analiză:

• OLAP şi Data Mining sunt integrate în serverul Oracle; pot fi privite ca modalităţi complementare de analiză:

• OLAP oferă calcule de rezumare (sinteză); de ex. “Cum sunt vânzările de fonduri mutuale din acest trimestru comparate cu cele de anul trecut? Ce se poate prevedea pentru vânzările în trimestrul următor?”
• Data mining descoperă legături (pattern-uri) neaşteptate în seturile de date; explorarea operează cu detalii, nu cu rezumate ale datelor; de exemplu, explorarea poate oferi răspuns la întrebări: “Care sunt cartacteristicile celor care vor cumpăra fonduri mutuale în următoarele 6 luni?”

• OLAP foloseşte kernelul bazei de date Oracle:

• Securitatea este administrată în mod standard, prin acordarea sau revocarea de drepturei utilizatorilor şi rolurilor
• Obiectele dimensionale sunt memorate în baza de date (de ex.cuburile)
• Se poate folosi limbajul SQL pentru interogarea obiectelor dimensionale

• Data mining foloseşte mari volume de date pentru a crea modele, atât în aplicaţiile economice cât şi în aplicaţii ştiinţifice

Oracle Data Mining suportă majoritetea funcţiilor de explorare:

• Oracle Data Mining suportă majoritetea funcţiilor de explorare:

• Clasificarea (gruparea entităţilor în clase) – algoritmi implementaţi: arbori de decizie, regresie, SVM (support vector machines)
• Regresia (aproximarea şi predicţia valorilor numerice continue) – algoritmi SVM, modele lineare generalizate (multivariate linear regression)
• Detecţia anomaliilor – foloseşte algoritmi SVM
• Detecţia importanţei atributelor – algoritmi de detecţie a descriptorilor de lungime minimă (minimum descriptor length)
• Gruparea (clustering – identificarea grupării naturale a datelor) – algoritmi k-Means, O-Cluster
• Asocieri (analiza în “coşul de cumpărături” a articolelor care sunt cumpărate împreună) – algoritmul apriori
• Extragerea trăsăturilor – algoritmul de factorizare cu matrice non-negativă

• Pe lângă explorarea datelor structurate, ODM mai permite explorarea textelor (de ex. rapoarte ale poliţiei, note medicale) sau a datelor spaţiale

MySQL (versiunea 5.1) și PostgreSQL (versiunea 8.4) nu oferă suport pentru depozite de date

• MySQL (versiunea 5.1) și PostgreSQL (versiunea 8.4) nu oferă suport pentru depozite de date

• Dar există toolset-uri cu care se pot construi depozite implementate în baze de date relationale ale acestora
• De exemplu: The Data Warehouse Toolkit by Ralph Kimball

• Microsoft SQL Server 2008 permite crearea și utilizarea depozitelor de date prin următoarele componente:

• Componente de stocare - acestea sunt baze de date ce conțin date colectate și informații de configurare
• Componente de execuție - folosite pentru colectarea și stocarea datelor
• Componente de interfață (API) – permit interacțiunea dintre interfețele utilizator și colecțiile de date
• Componente client – sunt interfețe utilizatori pentru accesarea colecțiilor de date

W. H. Inmon, Building the Data Warehouse, Fourth Edition, Wiley Publishing, Inc., 2005

• W. H. Inmon, Building the Data Warehouse, Fourth Edition, Wiley Publishing, Inc., 2005

• S. Chaudhuri, U. Dayal, An Overview of Data Warehousing and OLAP Technology, Intl. Conference on Data Engineering, 1995.

• Oracle 11g Documentation

• Oracle® Database - Data Warehousing Guide 11g Release 1 (11.1) B28313-02
• Oracle® Database - 2 Day + Data Warehousing Guide 11g Release 1 (11.1) B28314-01
• Oracle® Warehouse Builder User's Guide 11g Release 1 (11.1) B31278-06

• MySQL 5.1 Documentation

• PostgreSQL 8.4.3 Documentation

• Microsoft SQL Server 2008 Books Online