Capitolul3-Modelul Dimensional PT Platforma

Capitolul 3
Modele de date pentru BI

Capitolul 3 Modele de date pentru BI……………………………………………..61
3.1 Modelul dimensional ................................................................................... 62
3.2 Cubul n-dimensional/Hypercub/cub OLAP ................................................ 88
3.3 Modelul de date asociativ ............................ Error! Bookmark not defined.
3.3.1 Încărcarea şi asocierea a două sau mai multe surse de date ......... Error!
Bookmark not defined.
3.3.2 Fereastra Table Viewer....................... Error! Bookmark not defined.
3.3.3 Ataşarea de imagini la un model de date asociativ .. Error! Bookmark
not defined.
3.3.4 Modificarea structurii surselor de date Error! Bookmark not defined.
3.3.5 Utilizarea ierarhiilor ........................... Error! Bookmark not defined.
3.3.6 Fişiere QVD şi QVX .......................... Error! Bookmark not defined.
3.3.7 Realizarea joncţiunilor........................ Error! Bookmark not defined.
3.3.8 Concatenarea surselor de date ............ Error! Bookmark not defined.
3.3.9 Dimensiune Timp în modelul asociativ ............. Error! Bookmark not
defined.
3.3.10 Utilizarea datelor existente în paginile Web ..... Error! Bookmark not
defined.
3.3.11 Chei sintetice, dependenţe circulare, tabele de legătură .............. Error!
Bookmark not defined.
Rezumat .............................................................. Error! Bookmark not defined.
Întrebări .............................................................. Error! Bookmark not defined.
În acest capitol vom prezenta:

• modelul dimensional şi conceptele utilizate:
fapte, dimensiuni, ierarhii, granulaţie, gradul de
împrăştiere;
• modalități de implementare a modelului
dimensional în BDR: schema stea, schema fulg
de zăpadă şi constelaţia, tabela de fapte şi tabela
dimensională;
• cubul n-dimensional/hypercubul;
• modelul de date „asociativ”.
62 Business Intelligence. Teorie şi practică
3.1 Modelul dimensional

Modelele de date pentru baze de date pot fi clasificate în:
• modele conceptuale – utilizează concepte apropiate de modul în care
utilizatorii percep datele şi sunt independente de implementare;
• modele logice – utilizează concepte care pot fi înţelese de utilizatorii finali
şi depind de tipul de SGBD utilizat.
• modele fizice – utilizează concepte care descriu detalii despre cum sunt
stocate fizic datele, depinzând de SGBD-ul utilizat.
De exemplu, într-un mediu tranzacţional, la nivel conceptual se poate utiliza
modelul entitate-asociere, sau limbajul UML, la nivel logic se poate utiliza modelul
relaţional, orientat obiect, ierarhic, sau reţea şi la nivel fizic modelul depinde de
SGBD-ul folosit. De exemplu, modelul fizic al bazei de date Oracle este format din
următoarele tipuri de fişiere: a) fişiere de date (data files) ce conţin toate datele
stocate în baza de date (tabele, indecşi, sinonime, dicţionarul de date, proceduri
stocate, funcţii stocate, pachete etc.); b) fişiere jurnal de tranzacţii în care sunt
înregistrate toate modificările făcute asupra datelor din baza de date. Aceste fişiere
sunt foarte importante în procesul de restaurare a bazei de date; c) fişierele jurnal
de tranzacţii arhivate, copii ale fişierelor jurnal de tranzacţii on-line; d) fişierul de
control cu informaţii despre structura fizică a bazei de date (numele bazei de date,
numele şi locaţia fişierelor de date şi a fişierelor jurnal de tranzacţii); e) un fişier de
parametri utilizat pentru a defini caracteristicile unei instanţe Oracle; f) un fişier de
parole pentru autentificare a utilizatorilor [Muntean, 2008].
Într-o manieră asemănătoare, într-un mediu BI se poate folosi la nivel
conceptual modelul dimensional şi la nivel logic se poate folosi schema
stea/schema fulg de zăpadă (în cazul unui SGBDR) sau hypercub-ul (în cazul unui
SGBDMD).
Modelul dimensional este un model conceptual utilizat pentru proiectarea

depozitelor de date şi a bazelor de date multidimensionale [Kimball, 1996;
Kimball, 2002] şi are următoarele caracteristici:
• vizualizează informaţia din perspectiva unei „felii de timp” şi nu a
tranzacţiilor atomice;
• oferă suport pentru interogări ad-hoc şi analize complexe;
• este asimetric, se poate face distincţie între colecţiile de fapte şi
dimensiuni;
• asocierile dintre date sunt modelate în mod implicit. De exemplu, dacă
clientul Cora are vânzări pentru produsul Sprite, atunci asocierea dintre
client şi produs este implicită.
Modele de date pentru BI 63
Modelul entitate-asociere poate fi folosit ca punct de pornire în proiectarea

modelului dimensional. Un model entitate-asociere (la nivel de organizaţie)
corespunde unui set de modele dimensionale. De asemenea, cele două modele
utilizează concepte comune cum ar fi: atribut şi cheie. Tabelul 3.1 prezintă o
analiză comparativă dintre modelul dimensional şi modelul entitate-asociere.
În modelul dimensional, informaţiile pot fi clasificate în fapte – elementele de
date ce sunt analizate şi dimensiuni.
Un fapt poate fi un indicator/măsură prin care se poate analiza performanţa
activităţii modelate (este un atribut numeric al tabelei de fapte). Valorile unui
indicator se modifică continuu. Pentru fiecare combinaţie posibilă între dimensiuni,
există sau nu o valoare corespunzătoare a indicatorilor. Nu orice atribut numeric
este un indicator. De exemplu, număr de motoare este un atribut numeric şi totuşi
nu este un indicator, ci un atribut dimensional al dimensiunii Avion. Dacă valoarea
atributului numeric variază continuu (de exemplu, număr de pasageri, număr de
locuri, cantitatea vândută, valoarea vânzărilor) atunci este un indicator/fapt, iar
dacă atributul este perceput mai mult ca o constantă (de exemplu, număr de
motoare) atunci este un atribut dimensional.
Indicatorii pot fi clasificaţi în:
• indicatori de bază (de exemplu, valoarea vânzărilor, cantitatea vândută,
numărul de clienţi, numărul de pasageri, numărul de angajaţi, numărul de
angajări etc.);
• indicatori derivaţi care se obţin prin combinarea indicatorilor de bază (de
exemplu, profitul=venituri-costuri, sum(cant_vândută pe luna Ianuarie),
număr de pasageri/număr de locuri, cota de piaţă a unei firme etc.).
Tabel 3.1. Analiză comparativă dintre modelul dimensional

şi modelul entitate-asociere
Modelul dimensional Model entitate-asociere
Modelare top-down, deoarece se începe Modelare bottom-up.
cu identificarea proceselor importante din firmă
(unde sunt colectate datele).
Suport pentru interogări ad-hoc şi analize Suport pentru sistemele tranzacţionale.
complexe (depozite de date şi baze de date
multidimensionale).
Este mult mai simplu şi uşor de înţeles, mai ales Este prea complex, greu de reţinut
atunci când se implementează ca schemă stea. şi de înţeles, în special modelele
complexe la nivel de organizaţie.
Este robust şi proiectarea lui este făcută Este foarte variat ca structură şi
independent de tipurile de cereri. vulnerabil la modificările utilizatorilor.
Este extensibil. Modificarea lui presupune adesea
Se poate modifica fără a afecta aplicaţia. şi modificarea aplicaţiei.
Permite redundanţă. Elimină redundanţa.
O altă clasificare este dată de Ralph Kimball în [Kimball, 1996; Kimball,

2002] şi anume după posibilitatea indicatorilor de a se însuma după dimensiuni:
• indicatori aditivi care se pot însuma după toate dimensiunile. De exemplu,

indicatorul cantitate vândută se poate calcula pentru o categorie de
produse, sau pentru o anumită regiune, sau pentru o anumită perioadă de
timp. Valoarea vânzărilor, cantitatea vândută şi numărul de angajaţi sunt
indicatori aditivi.
• indicatori care se pot însuma numai după unele dimensiuni. De exemplu,
indicatorul numărul de clienţi se poate calcula pentru o anumită perioadă
de timp, sau pentru o anumită regiune, dar nu este aditiv după dimensiunea
Produs. Dacă pentru fiecare produs (dintr-o categorie de produse) se
cunoaşte numărul de clienţi şi dorim să aflăm numărul de clienţi pentru
categoria de produse, nu se pot aduna aceste numere. Rezultatul poate fi
eronat, deoarece pot exista clienţi, care au cumpărat mai multe tipuri de
produse, din categoria respectivă.
• indicatori non-aditivi care nu se pot însuma după nicio dimensiune (de
exemplu, profitul marginal, număr de pasageri/număr de locuri etc.). Se
pot combina cu alţi indicatori pentru a deveni aditivi.
Granulaţia unui fapt poate fi definită ca nivelul de detaliu la care sunt stocate
datele, în modelul dimensional. De exemplu, cantitatea vândută poate fi prezentă
în modelul dimensional la nivel de zi/lună, produs/categorie de produs. Granulaţia
unui fapt este determinată de combinaţia granulaţiilor tuturor dimensiunilor
asociate. Faptele cu granulaţii identice fac parte din aceeaşi colecţie de fapte. De
exemplu, cantitatea vândută şi valoarea vânzărilor au aceeaşi granulaţie. Stabilirea
corectă a granulaţiei este extrem de importantă şi depinde de cerinţele analitice de
business. De asemenea, determină nivelul de detaliu la care utilizatorii finali vor
realiza analize. Selectarea unui nivel de granulaţie necorespunzător afectează
semnificativ volumul de date stocat în depozitul de date, precum şi capacitatea
depozitului de a oferi răspunsuri la diferite tipuri de cereri şi are un impact
important asupra performanţei la analiză.
Gradul de împrăştiere a datelor este un element important în modelul
dimensional, influenţând dimensiunea bazei de date. De exemplu, indicatorul
valoarea vânzărilor poate avea valori valide numai pentru o mică fracţiune a
produsului cartezian al dimensiunilor Produs, Client şi Timp. Dacă considerăm că
modelul dimensional are 120 de clienţi, 20000 de produse şi 1098 de zile avem
2625200000 de combinaţii posibile. Vânzările reale pot fi numai pentru
1% din combinaţiile posibile. Uneori acest lucru este descris ca 99% împrăştiere
[Muntean, 2004].
Conceptul de dimensiune este fundamental pentru modelarea dimensională.
Dimensiunile au următoarele caracteristici:
• furnizează informaţii descriptive despre fiecare fapt/indicator/măsură. De
exemplu, caracteristicile indicatorului valoarea vânzărilor pot fi: locaţia
(unde?), timpul (când?), produsul vândut (ce?);
• conţin în general date statice. Dimensiunile nu se modifică la fel de des ca
faptele. Totuşi, uneori apar modificări ale valorilor atributelor
dimensionale, iar modelul dimensional trebuie să permită aceste

modificări, pentru a asigura coerenţa şi corectitudinea datelor;
• sunt esenţiale pentru analiză. Un model dimensional cu un număr mare de
atribute dimensionale, permite analize cât mai complexe şi mai variate;
• într-o schemă stea, sunt tabelele care se dispun radial în jurul tabelei de
fapte şi se mai numesc tabele dimensionale. Aceste tabele nu sunt
normalizate, iar cheia lor primară este o cheie simplă.
O dimensiune conţine mai mulţi membri. Un membru este un nume distinct sau
un identificator folosit pentru a determina poziţia unui element de dată (în schema
stea apare sub denumirea de atribut dimensional). De exemplu, toate lunile,
trimestrele şi anii formează dimensiunea Timp şi toate oraşele, regiunile şi ţările
dimensiunea Locaţie. Un membru poate aparţine la una sau mai multe ierarhii, sau
poate să nu fie inclus într-o ierarhie (membru independent). De exemplu, în
dimensiunea Produs, membru culoare nu este inclus în nicio ierarhie, iar în
dimensiunea Timp, membru zi aparţine la două ierarhii: zi>săptămâna>an şi
zi>luna>trimestru>an (figura 3.1).
Dimensiunile au de regulă o structură ierarhică. De exemplu, dimensiunea Timp
poate avea două ierarhii: ierarhia calendaristică şi ierarhia fiscală. Ierarhiile pot fi
simetrice şi asimetrice. De exemplu, ierarhia calendaristică este o ierarhie
simetrică. Ierarhiile asimetrice sunt implementate cu succes în bazele de date
multidimensionale, bazele de date relaţionale fiind necorespunzătoare. De
exemplu, în dimensiunea Bănci există o ierarhie asimetrică, anumite sucursale au
ATM, altele nu au (figura 3.2).
an
săptămâna trimestru
luna
zi
Figura 3.1 Multiple ierarhii în dimensiunea Timp
Dimensiunile sunt foarte importante în modelarea dimensională şi pot avea:

• milioane de înregistrări cu sute de atribute (de exemplu, clienţii unei firme
de asigurări) sau sute de milioane de înregistrări cu câteva atribute (de
exemplu, clienţii unui supermarket). Aceste dimensiuni sunt „conforme”
[Kimball, 2002], adică cheile, denumirile atributelor, definiţiile atributelor,
valorile lor sunt consistente de a lungul proceselor de business. Două

dimensiuni sunt „conforme” dacă sunt identice, sau una este un subset al
celeilalte. Exemple de dimensiuni „conforme”: Client, Produs, Locaţie,
Pacient, Tratament, Angajat etc.
• un număr mic de înregistrări cu unul sau mai multe atribute. De exemplu,
Tip tranzacţie, Starea unei reclamaţii etc. Aceste dimensiuni nu sunt
„conforme”.
Cele mai utilizate dimensiuni sunt: Locaţia, Produsul, Clientul şi Timpul.
banca X
sucursala 1 sucursala 2 sucursala 3
agentia 11 agentia 12 agentia 31
ATM111 agentia 32
ATM112 agentia 33
Figura 3.2 Ierarhie asimetrică
Dimensiunea Timp
Deoarece un depozit de date este o colecţie integrată de date istorice, abilitatea
de a analiza datele din perspectiva timpului este o cerinţă fundamentală pentru
fiecare utilizator al depozitului. Utilizatorii realizează agregări folosind elemente
de timp (cum ar fi ziua, săptămâna, luna, anul, anul fiscal etc.). De regulă,
dimensiunea Timp se adaugă la modelul dimensional, în mod explicit. Ralph
Kimball propune următoarele atribute pentru dimensiunea Timp [Kimball, 1996]:
• atributul Ziua din săptămână conţine numele zilei (de exemplu, marţi).
Acest atribut ar putea fi folosit pentru a compara activitatea zilei de marţi
cu cea de luni;
• atributul Numărul zilei în lună începe cu (1) la începutul fiecărei luni şi se
termină cu 28, 29, 30, sau 31. Acest atribut este folosit pentru a compara
aceeaşi zi din fiecare lună;
• atributul Numărul total de zile este numeric. De exemplu, un număr
consecutiv începând cu prima zi dintr-un secol;
• atributul Tipul zilei ia valorile (D) sau (N) dacă este o zi din săptămână sau
nu. Sâmbăta şi duminica au valoarea (N). Acest atribut permite comparaţii
rapide între zilele din săptămână şi cele de la sfârşitul săptămânii;
• atributul Sezon conţine denumirea sezonului;
• atributul eveniment se referă la un eveniment special (crăciunul,

paştele etc.).
În figura 3.3 sunt incluse numai atributele de timp cu o semnificaţie
calendaristică. Totuşi organizaţiile au propriile perioade de timp cum ar fi anul
fiscal, perioadele promoţionale, perioadele de concediu etc. Cheia primară se poate
obţine prin stabilirea unei date fixe, de referinţă, ca punct de pornire pentru
numărarea tuturor celorlalte elemente de timp.
Dimensiunea Timp
Cheie timp
Ziua din săptămână
Numărul zilei în lună
Numărul total de zile
Numărul săptămânii în an
Numărul total de săptămâni
Luna
Trimestru
Tipul zilei din săptămână
Sezonul
Evenimente
etc.
Figura 3.3 Dimensiunea Timp, în schema stea
În cele ce urmează, se va exemplifica modul cum se creează dimensiunea Timp

cu ajutorul instrumentului Oracle Warehouse Builder 11g R2 (OWB). OWB este
un instrument utilizat pentru a proiecta structura unui depozit de date, precum şi
pentru a extrage, transforma şi încărca datele în depozitul de date.
Figura 3.4 Crearea dimensiunii Timp_dimensiune cu OWB
Se va utiliza o schemă stea şi se vor crea următoarele elemente: o tabelă

dimensională, o secvenţă şi un trigger pentru a încărca valorile secvenţei în tabelă,
precum şi o mapare prin care se populează tabela dimensională. Iniţial se stabileşte
tipul de implementare (de exemplu, schema stea), perioada de timp pentru care se
vor crea atributele de timp (de exemplu, 2 ani), data de referinţă (de exemplu, anul
2000), precum şi tipul de ierarhie calendaristică/fiscală (figura 3.4) [Lane, 2010;
Oracle, 2010; Oracle, 2010a; Sreeraman, 2010]. Se stabilesc nivelele ierarhice, de
exemplu luna>trimestru>an (figura 3.5).
Figura 3.5 Stabilirea ierarhiei în dimensiunea Timp_dimensiune
Se vor genera definiţii pentru: atributele dimensiunii Timp_dimensiune (figura

3.6), tabela dimensională TIMP_DIMENSIUNE_TAB (figura 3.7, figura 3.8),
secvenţa corespunzătoare (TIMP_SEQ), precum şi asocierea dintre dimensiune şi
tabela dimensională (figura 3.9).
Se va crea şi o mapare pentru încărcarea datelor în tabela dimensională
Timp_dimensiune_tab (figura 3.10).
Urmează apoi procesul de creare a obiectelor definite şi anume: dimensiunea,
tabela dimensională, secvenţa, pachetul de funcţii PL/SQL pentru încărcare date.
Pentru a afişa tabela creată, s-a utilizat instrumentul SQL Developer
(figura 3.11).
Figura 3.6 Atributele dimensiunii Timp_dimensiune
Figura 3.7 Definiţia structurii tabelei dimensionale Timp_dimensiune_tab

Figura 3.8 Detalii despre nivelele ierarhice
Figura 3.9 Asocierea dintre dimensiune şi tabela dimensională

Figura 3.10 Maparea pentru încărcarea datelor în tabela dimensională

Timp_dimensiune_tab
Figura 3.11 Tabela dimensională Timp_dimensiune_tab

Dimensiunea Produs
Este derivată din nomenclatorul de produse care se găseşte, în cele mai multe
cazuri, în sistemul informatic operaţional, de gestiune a stocurilor. Pentru a
transforma nomenclatorul de produse în dimensiunea Produs trebuie să ţinem cont
de următoarele aspecte:
• trebuie generate chei primare diferite de cele folosite în sistemul
operaţional, deoarece depozitul de date are un orizont de timp mai mare
decât sistemul operaţional;
• trebuie generate noi chei primare pentru a permite urmărirea modificărilor
descrierilor de produse, în acele cazuri unde sistemul operaţional nu a
modificat cheia primară, dar a schimbat descrierea produsului, iar în
depozit se doreşte păstrarea istoriei produselor;
• trebuie generate chei primare pentru agregate (de exemplu, cheia pentru
categorie, cheia pentru subcategorie);
• codurile numerice şi abrevierile din nomenclatorul de produse trebuie
înlocuite cu atribute descriptive.
Dimensiunea Produs conţine una sau mai multe ierarhii, precum şi atribute
dimensionale independente. Ralph Kimball propune următoarea structură (figura
3.12) pentru dimensiunea Produs (schema stea) [Kimball,1996].
Dimensiunea Produs
Cheie produs
Număr inventar
Descriere produs
Dimensiunea ambalajului
Marca
Subcategorie
Categorie
Raion
Tip ambalaj
Greutate
Unitatea de măsură pentru greutate
Lăţimea raftului de stocare
Înălţimea raftului, Adâncimea raftului etc.
Figura 3.12 Dimensiunea Produs [Kimball, 2002]
În cele ce urmează, vom exemplifica modul cum se creează dimensiunea

Produs cu ajutorul instrumentului OWB [Lane, 2010; Oracle, 2010; Oracle, 2010a;
Sreeraman, 2010]. Se parcurg următorii paşi:
1. se stabileşte denumirea dimensiunii: Produs (figura 3.13);
Figura 3.13 Crearea dimensiunii Produs
2. se stabileşte modul de implementare a dimensiunii: schema stea (ROLAP)

sau hypercub /MOLAP (în acest caz, se utilizează opţiunea OLAP a
SGBDR Oracle). În acest exemplu se va utiliza schema stea (figura 3.14);
3. se stabilesc atributele dimensionale, de exemplu: ID (identificator surogat),
denumire (identificator de business), descriere, codprodus şi preţ
(figura 3.15);
4. se stabilesc nivelele ierarhice: categorie, subcategorie, produs (figura
3.16). Fiecare nivel ierarhic al unei ierarhii trebuie să aibă cel puţin trei
atribute, dintre care doi identificatori: un identificator surogat şi un
identificator de business. Identificatorul surogat este compus dintr-un
singur atribut. Pentru o dimensiune care are o implementare
relaţională/ROLAP, identificatorul surogat ar trebui să fie numeric şi
serveşte pentru următorul scop: dacă un nivel copil este stocat într-o tabelă
diferită de nivelul părinte, fiecare membru al nivelului copil stochează
identificatorul părintelui. Se utilizează o secvenţă pentru a genera valorile
identificatorilor surogat, pentru toate nivelurile ierarhice. Identificatorul de
business trebuie să fie unic pentru un nivel ierarhic şi este întotdeauna
derivat din cheia sursei de date. De exemplu, identificatorul de business al
unei categorii de produs poate fi denumirea categoriei (unică pentru fiecare
categorie). Acest identificator oferă o legătură logică între un fapt şi o
dimensiune, sau între două nivele ierarhice. Când se populează cu date un
nivel copil, trebuie specificat identificatorul de business al nivelului
părinte. Când se populează cu date un cub, trebuie specificat identificatorul
de business al nivelului ierarhic la care se referă cubul.
5. pentru fiecare nivel ierarhic se stabilesc atributele corespunzătoare

(figura 3.17);
6. se va stabili tehnica de urmărire a modificărilor. În exemplul nostru se va
alege de tip SCD1 (figura 3.18);
Figura 3.14 Stabilirea modului de implementare
Figura 3.15 Stabilirea atributelor dimensionale

Figura 3.16 Stabilirea ierarhiei
Figura 3.17 Stabilirea atributelor corespunzătoare pentru fiecare nivel ierarhic

Figura 3.18 Stabilirea tehnicii de urmărire a modificărilor
Se observă că s-a creat definiţia unei secvenţe Produs_seq care este asociată cu
atributul cheie al dimensiunii (figura 3.19). Se va crea şi o asociere între
dimensiune şi tabela dimensională (figura 3.20).
Figura 3.19 Structura dimensiunii Produs

Figura 3.20 Asocierea dintre dimensiune şi tabela dimensională
Urmează apoi procesul de creare a obiectelor definite (figura 3.21).
Figura 3.21 Procesul de creare a dimensiunii Produs

Figura 3.22 Tabela dimensională Produs_tab
Structura tabelei dimensionale este prezentată în figura 3.22 (s-a utilizat

instrumentul SQL Developer). Cheia primară este atributul dimension_key. Fiecare
nivel ierarhic are asociate cel puţin trei atribute (de exemplu, categorie_id,
categorie_denumire, categorie_ descriere).
Dimensiunea Client
Ar putea avea 50-100 de atribute şi cel puţin două ierarhii:
• o ierarhie ar reprezenta aspectele legate de expediere şi facturare,
referitoare la clienţi;
• o altă ierarhie se referă la repartizarea regională a clienţilor (locaţie, oraş,
district, stat).
Există de asemenea, un număr de atribute în dimensiunea Client cum ar fi:
vârsta, sexul, starea civilă, numărul de copii, nivelul venitului, nivelul de educaţie
care sunt foarte des folosite în analize şi sunt numite de Ralph Kimball „atribute
demografice”. Ralph Kimball consideră că „cea mai bună tehnică pentru
urmărirea modificărilor în dimensiunile mari este de a le descompune în una sau
mai multe dimensiuni demografice, fiecare conţinând un număr mic de atribute
care vor avea un număr limitat de valori” [Kimball, 1996]. Aceste dimensiuni
pot fi asociate prin joncţiune direct la tabela de fapte sau la dimensiunea Client
(figura 3.23).
Dimensiunile se modifică rar în timp, spre deosebire de colecţiile de fapte. De
exemplu, se modifică descrierile produselor, clienţii îşi schimbă numele, se
căsătoresc şi divorţează, au mai mulţi copii şi îşi modifică adresele, un produs se
poate schimba de la categoria X la categoria Y, sau un client se poate schimba de la

o categorie de vârstă la alta etc. În acest caz, trebuie să se analizeze aspectele legate
de modificările cheilor, a atributelor şi a relaţiilor structurale din dimensiune.
Modelul dimensional trebuie să permită înregistrarea acestor modificări, fără să
crească prea mult redundanţa datelor.
Tabela de fapte
Vânzări Dimensiunea
Timp_id Demografică
Demografic_id Demografic_id
Client_id Categorie_vârstă
Produs_id Categorie_venit
Cantitate Stare civilă
valoare_vânzări Sex
Dimensiunea Client Comportament la
Client_id cumpărare
Nume, prenume
Adresa, oraş, judeţ,
cod fiscal
Demografic_id
Figura 3.23 Dimensiuni demografice
Aplicaţiile tranzacţionale efectuează operaţii de actualizare pe înregistrările

bazei de date, astfel se creează chei şi se şterg. Când sunt adăugate noi tupluri în
bazele de date tranzacţionale, se stabilesc şi valorile cheilor corespunzătoare
acestor tupluri. Aceste valori pot fi noi sau reutilizate. Dacă valorile cheilor sunt
reutilizate, atunci aceste chei nu mai pot fi folosite în depozitul de date (care
păstrează istoria înainte şi după reutilizarea cheilor). O altă problemă a cheilor este
atunci când datele despre un obiect sunt preluate din sisteme sursă diferite. Fiecare
sistem poate avea propriul set de chei, într-un format total diferit. Şi chiar dacă ar
avea acelaşi format, o valoare a cheii folosită într-un sistem sursă poate identifica
obiectul ABC, în timp ce în alt sistem poate identifica obiectul XYZ. Din aceste
motive, este necesar un mecanism de generare şi administrare a cheilor în depozitul
de date, diferit de cel din sistemele sursă. Există mai multe tehnici de generare a
cheilor din depozitul de date şi anume:
• concatenarea cheii obiectului din baza de date operaţională cu marca de
timp corespunzătoare momentului în care se face încărcarea în depozitul
de date. Această tehnică are însă multe dezavantaje, cum ar fi: 1) cheile din
baza de date operaţională, de regulă, sunt de tip caracter şi mai puţin
numeric. În acest caz, joncţiunea tabelelor de fapte cu tabelele
dimensionale devine ineficientă; 2) adăugarea unei mărci de timp face
cheia mai mare, deci tabela dimensională mai mare. Tabela de fapte
conţine această cheie (este inclusă în cheia sa primară), deci este şi ea mai
mare; 3) dacă se modifică cheile surselor, se pune întrebarea cum se face

actualizarea cheii tabelei dimensionale; 4) probleme de scalabilitate, în
cazul utilizării de surse neomogene;
• triggeri pe baza de date care citesc ultima valoare a cheii surogat şi
generează următoarea valoare a cheii surogat. De exemplu, instrumentul
OWB utilizează o secvenţă şi un trigger pentru a genera valorile cheii
surogat.
Ralph Kimball propune patru tehnici pentru a gestiona modificările atributelor

dimensionale [Kimball, 1996] şi anume:
• Suprascrierea valorilor vechi (SCD tip 1);
• Păstrarea istoriei prin adăugarea unei noi înregistrări (flat model/SCD
tip 2);
• Partiţionarea istoriei folosind tabele istorice;
• Păstrarea parţială a istoriei (SCD tip 3).
Suprascrierea valorilor vechi (slowly changing dimension/SCD tip 1)

Cea mai simplă soluţie de a gestiona modificările este de a suprascrie valorile
anterioare din înregistrare şi de a pierde posibilitatea de a urmări istoria datelor. De
exemplu, se consideră că în dimensiunea Client există clientul Muntean Mihaela.
Până la 15 februarie 1995, Muntean Mihaela nu era măritată şi, de aceea, atributul
stare civilă avea valoarea necăsătorită. Muntean Mihaela s-a căsătorit pe
15 februarie 1995. Deci se scrie în atributul stare civilă valoarea căsătorită.
Această soluţie este uşor de implementat, dar elimină scopul real al depozitului de
date, de a urmări evoluţia în timp a clientului Muntean Mihaela. Se foloseşte atunci
când datele iniţiale despre Muntean Mihaela sunt greşite şi nu ne interesează să
păstrăm istoria stării civile (figura 3.24).
Figura 3.24 Suprascrierea valorilor vechi (SCD tip 1)
Păstrarea istoriei prin adăugarea unei noi înregistrări (SCD tip2)

În acest caz, se păstrează cele două descrieri ale clientului Muntean Mihaela
(descrierea cu starea civilă necăsătorită şi cea cu starea civilă căsătorită). Se
realizează acest lucru prin crearea unei noi înregistrări în dimensiunea Client,
pentru Muntean Mihaela cu starea civilă căsătorită. Cea de a doua înregistrare
trebuie să aibă o nouă cheie. Cu alte cuvinte, codul numeric personal pentru
Muntean Mihaela nu mai poate fi cheie în dimensiunea Client. Această soluţie cere
utilizarea cheilor generalizate/surogat (de exemplu: două cifre la sfârşitul codului
numeric personal sau un număr secvenţial generat de sistem) (figura 3.25).
CNP Nume Stare civilă

1 2080577644890 Muntean Mihaela necăsătorită
2 2080577644890 Muntean Mihaela căsătorită
Figura 3.25 Păstrarea istoriei prin adăugarea unei noi înregistrări
Partiţionarea istoriei folosind tabele istorice

Pentru a păstra modificările atributului stare civilă pentru clientul Muntean
Mihaela, se foloseşte o tabelă istorică. Fiecare tuplu din tabelă este unic. Cheia
primară a tabelei poate fi formată din codul numeric personal şi data modificării
valorii atributului stare civilă (figura 3.26). Starea civilă curentă pentru Muntean
Mihaela este păstrată în dimensiunea Client, iar istoria acestui atribut, în tabela
istorică (modelarea evenimentului).
Se poate îmbunătăţi structura acestei tabele prin adăugarea atributelor De la
data şi Până la data care stabilesc în mod explicit perioada de timp în care
atributul Stare civilă are o anumită valoare (modelarea stării).
Tabela
de
fapte
Figura 3.26 Tabela cu istoricul atributului stare civilă
Păstrarea parţială a istoriei (SCD tip 3)

Dacă se alege această soluţie se va adăuga atributul Stare civilă anterioară care
păstrează valoarea atributului Stare civilă înainte de modificare, precum şi un
atribut de tip dată calendaristică care păstrează data la care a avut loc modificarea.
Dezavantajul acestei soluţii este că datele sunt incomplete, se pierd informaţii
(figura 3.27).
Momentul 1
Momentul 2
Figura 3.27 Păstrarea parţială a istoriei
În continuare, vom prezenta un exemplu de implementare a unei dimensiuni de

tip SCD 3. Se va utiliza instrumentul Oracle Warehouse Builder care poate
implementa cele trei tipuri de SCD. Vom considera că dimensiunea Produs este o
dimensiune de tip SCD 3. Se consideră că atributul preţ se modifică şi se vor
adăuga atributele: prev_pret care păstrează valoarea atributului preţ înainte de
modificare şi data_modificării, un atribut de tip dată calendaristică care păstrează
data la care a avut loc modificarea (figura 3.28, figura 3.29, figura 3.30).
Figura 3.28 Implementarea unei dimensiuni de tip SCD3, cu OWB

Figura 3.29 Structura unei dimensiuni de tip SCD3
Figura 3.30 Structura tabelei dimensionale corespunzătoare

Există, de asemenea, posibilitatea de a se modifica în timp şi ierarhiile şi

anume:
• când numărul de niveluri dintr-o ierarhie rămâne acelaşi şi numai valorile
curente se modifică. De exemplu, categoria produsului ABC se schimbă de
la X la Y. Se doreşte să se cunoască când a avut loc modificarea, sau în ce
perioadă, produsul ABC a aparţinut categoriei X/Y. Într-o schemă stea,
categoria ar putea fi unul dintre atributele înregistrării corespunzătoare
produsului ABC. Dacă se foloseşte schema fulg de zăpadă, categoriile sunt
stocate într-o tabelă separată Categorie.
• cazul când numărul de niveluri din ierarhie se modifică, se adaugă/şterge
un nivel ierarhic. Pentru schema stea, adăugarea sau ştergerea unui nivel
ierarhic este echivalentă cu adăugarea sau ştergerea atributelor din tabela
dimensională.
Colecţiile de fapte şi dimensiunile pot fi reprezentate într-o bază de date

relaţională ca tabele, iar modelul dimensional ca: schemă stea, fulg de zăpadă,
constelaţie sau alte combinaţii. În schema stea, fiecare dimensiune este descrisă
prin propria tabelă şi colecţia de fapte este stocată într-o singură tabelă numită
tabelă de fapte, aflată în centrul schemei, singura tabelă cu multiple joncţiuni.
Celelalte tabele au o singură joncţiune la tabela de fapte. Figura 3.31 prezintă o
schemă stea formată din trei tabele dimensionale: Timp, Produs şi Locaţie şi o
tabelă de fapte Vânzări.
Tabela Tabela
dimensională Tabela de fapte dimensională
Timp Vânzări Produs
timpid prodid prodid
ziua locatieid denumire
ziua_din_săpt timpid marca
luna cant tip
trimestru valoare_vânzări tipul_distribuitor
an
etc.
Tabela
dimensională
Locaţie
locatieid
strada
oraş
judeţ
ţară
Figura 3.31 Exemplu de schemă stea
Indicatorii analizaţi sunt: cantitatea vândută (cant) şi valoarea vânzărilor.

Cheia tabelei de fapte este o cheie compusă formată din atributele prodid, locatieid
şi timpid. Atributul timpid este şi cheie externă şi asigură legătura la tabela

dimensională Timp, atributul prodid este cheie externă şi asigură legătura la tabela
Produs şi atributul locatieid este cheie externă şi asigură asocierea cu tabela
Locaţie.
Tabela de fapte este tabela centrală într-o schemă stea şi are următoarele
caracteristici:
• conţine un număr foarte mare de tupluri (posibil milioane). Numărul de
tupluri din tabelă reprezintă produsul cartezian al dimensiunilor;
• cheia primară a tabelei este o cheie compusă, formată din cheile primare
ale tabelelor dimensionale;
• este normalizată şi realizează de fapt o legătură indirectă între tabelele
dimensionale;
• poate conţine şi date agregate.
Este posibil ca o tabelă de fapte să nu conţină indicatori şi se numeşte tabelă de
fapte fără fapte (factless fact tables) (figura 3.32). Tabela de fapte din figura 3.32
este un exemplu de tabelă de fapte ce înregistrează evenimente şi anume prezenţa
zilnică la o facultate [Kimball, 1996]. Această tabelă de fapte ne oferă informaţii
despre: cursurile cele mai frecventate, studenţii care participă la aceste cursuri, rata
medie de ocupare a facilităţilor în funcţie de perioada de timp din zi etc. De
exemplu, dacă dorim să aflăm care sunt cele mai frecventate cursuri, se scrie
următoarea cerere SQL: Select curs_id, count(distinct data_id) From fact_table
group by curs_id order by count(distinct data_id) desc;
Curs
Curs_id
Profesor
Profesor_id
Student
Student_id
Facilitate_id Facilitate
Data Data_id
Figura 3.32 Tabelă de fapte fără fapte
Avantajele şi dezavantajele schemei stea sunt prezentate în tabelul 3.2.
Tabelul 3.2 Avantajele şi dezavantajele schemei stea

Avantaje Dezavantaje
o este simplu de construit; ▪ este o schemă inflexibilă. Adăugarea unei
o reflectă cu exactitate modul cum noi dimensiuni în schemă, poate duce la
înţeleg utilizatorii activitatea modificarea granulaţiei tabelei de fapte;
modelată; ▪ conţine date redundante ce conduc
o este o schemă uşor de înţeles de către la creşterea riscului de inconsistenţă
utilizatori, deoarece datele sunt a datelor;
aranjate într-un mod uşor de înţeles, ▪ pentru a permite analize complexe,
iar relaţiile dintre entităţi sunt foarte trebuie să includă tabele de agregate;
clare;
o furnizează o performanţă ridicată ▪ face dificilă joncţiunea între tabelele
pentru cereri analitice, prin reducerea de fapte;
numărului de joncţiuni; ▪ dimensiunea indexului aferent cheii tabelei
o toţi indicatorii de performanţă de fapte este destul de mare, având efect
ai activităţii modelate sunt stocaţi asupra performanţei şi a scalabilităţii.
în tabela de fapte.
În schema fulg de zăpadă, tabelele dimensionale sunt normalizate. De exemplu,

în figura 3.33 s-a creat câte o tabelă pentru fiecare nivel ierarhic, din dimensiunile
Locaţie şi Produs: tabelele Oraşe şi Locaţie, respectiv tabelele Produse şi
Distribuitori. Dimensiunea Timp a rămas nenormalizată. Se utilizează atunci când
dimensiunile sunt mari. Schema fulg de zăpadă poate conţine şi tabele de fapte
separate pentru fiecare nivel de agregare.
Tabela Tabela de fapte Tabela

dimensională Vânzări dimensională
Timp Timpid Produse
Timpid prodid prodid
ziua Locatieid denumire
Ziua_din_sapt Valoare_vânz marca
luna cantitate distribuitor_id
trimestru
…
an…
……..
Tabela
Tabela dimensională Tabela
dimensională Oraşe dimensională
Locaţie Orasid Distribuitori
Locatieid oraş distribuitorid
strada judeţ Tip_distrib
orasid ţară …
… …
Figura 3.33 Schema fulg de zăpadă
Avantajele şi dezavantajele schemei fulg de zăpadă sunt prezentate în tabelul 3.3.
Tabel 3.3. Avantajele şi dezavantajele schemei fulg de zăpadă

• structura normalizată a tabelelor ▪ este mai complexă decât schema stea;
dimensionale este mai uşor de modificat; ▪ scade performanţa la interogare,
• reduce redundanţa datelor; deoarece sunt folosite multe joncţiuni;
• îmbunătăţeşte performanţa operaţiilor ▪ schema este mai dificil de înţeles
de drill-down şi roll-up. de către utilizatori.
O schemă constelaţie (figura 3.34) include mai multe tabele de fapte cu

dimensiuni comune, normalizate sau nenormalizate.
Tabela Tabela
de fapte de fapte
Tabela Timp Tabela
Vânzări Produse
Livrare
timpid timpid prodid
ziua prodid
prodid timpid
ziua_din_săpt denumire
locatieid marca distribid
luna val_vânz de_la
trimestru categorie
cantitate destinaţie
an furniz_tip Tabela
costuri
etc. Distribuitori
etc. cant_livrată
distribid
etc.
denumire
Tabela locatieid
Locaţie distribtip
Locatieid etc.
strada
oraş
judeţ
etc
Figura 3.34 Schema constelaţie
3.2 Cubul n-dimensional

Cubul n-dimensional/hypercurb/cub OLAP este un model logic utilizat de
bazele de date multidimensionale şi de instrumentele OLAP. Tehnicile de
proiectare a unui hypercub sunt specifice fiecărui instrument OLAP (nu există
standarde). Principalele concepte utilizate sunt: dimensiunile, ierarhiile, măsurile,
granulaţia, fenomenul de împrăştiere şi multicubul. Aceste concepte sunt utilizate
de majoritatea instrumentelor OLAP, deşi modul lor de definire diferă uneori foarte
mult. Observăm că modelul dimensional şi cubul n-dimensional utilizează concepte
comune. Aşa cum am precizat în paragraful anterior, modelul dimensional este un
model conceptual care poate fi implementat şi în baze de date multidimensionale,
sub forma de cub n-dimensional. În cele ce urmează, vom prezenta numai
conceptele specifice cubului n-dimensional. Consiliul OLAP a propus un glosar de
termeni care s-a dorit standardizat. De aceea, în prezentarea acestor concepte s-au
utilizat şi definiţiile date de Consiliul OLAP [OLAP, 1997].
Conceptul de hypercub sau cub cu mai mult de trei dimensiuni (cub
n-dimensional) sau structură multidimensională este fundamental pentru
înţelegerea sistemelor OLAP şi a bazelor de date multidimensionale. Instrumentele
OLAP folosesc conceptul de hypercub în acelaşi mod în care instrumentele de
calcul tabelar folosesc conceptul de foaie de lucru şi bazele de date relaţionale
conceptul de tabelă. Toate vizualizările şi analizele sunt făcute în termeni de

hypercuburi /cuburi n-dimensionale.
Consiliul OLAP defineşte cubul n-dimensional ca „un grup de celule de date
aranjate după dimensiunile datelor.” Un cub n-dimensional este de fapt un set de
măsuri (variabile/indicatori) care utilizează aceleaşi dimensiuni de identificare.
Figura 3.35 prezintă un cub n-dimensional utilizat în analiza vânzărilor. Acest cub
are trei dimensiuni: Magazin, Produs şi Timp. În celulele cubului sunt stocate
valorile măsurii analizate şi anume cantitatea vândută. Valoarea acestui indicator
variază în funcţie de produsul vândut, de magazinul care vinde acest produs şi de
perioada de timp. Se spune că acest indicator este „dimensionat” după Produs,
Magazin şi Timp. De exemplu, valoarea 65 reprezintă cantitatea vândută în luna
Ianuarie, din produsul Sprite, în magazinul St3.
Dimensiuni
Indicatori
Produs
Magazin
Ierarhie Timp
Membri
i
Figura 3.35 Exemplu de cub n-dimensional
Conceptul de dimensiune este definit de Consiliul OLAP ca „un atribut

structural al unui cub ce constă dintr-o listă de membri, pe care utilizatorul îi
percepe ca fiind de acelaşi tip. …Dimensiunile oferă un mod foarte concis, intuitiv
de organizare şi selectare a datelor pentru explorare şi analiză.” Într-un cub
n-dimensional, o dimensiune este reprezentată printr-o axă. O dimensiune conţine
mai mulţi membri. Un membru este „un nume distinct sau un identificator folosit
pentru a determina poziţia unui element de dată” [OLAP, 1997]. De exemplu, All
şi Sprite sunt membri ai dimensiunii Produs, Ianuarie este un membru al
dimensiunii Timp.
Cele mai multe dimensiuni au o structură ierarhică. În cele mai multe activităţi
ale unei firme, ierarhiile sunt o necesitate. În glosarul de termeni OLAP se
specifică că „membrii dimensiunilor pot fi organizaţi pe baza relaţiilor de tip
părinte-copil, unde un membru părinte reprezintă consolidarea (agregarea)
membrilor copil. Rezultatul este o ierarhie şi relaţiile părinte/copil sunt relaţii
ierarhice”. Ierarhiile sunt esenţiale pentru agregarea datelor şi pentru navigarea în
cubul n-dimensional.
Combinaţia de multiple dimensiuni şi multiple niveluri pe dimensiune constituie
esenţa unui cub n-dimensional.
Granulaţia cubului n-dimensional este dată de granulaţia dimensiunilor. De
exemplu, dimensiunea Timp are granulaţia la nivel de lună, iar dimensiunea
Locaţie are granulaţia la nivel de magazin.
O celulă într-un cub n-dimensional poate conţine indicatori de bază, dar şi
indicatori derivaţi. De exemplu, celulele cubului n-dimensional pentru analiza
vânzărilor pot stoca valorile următorilor indicatori: cantitatea vândută, valoarea
vânzărilor, numărul de clienţi, dar şi profitul (ca indicator derivat).
Întrebarea care apare adesea este dacă se poate adăuga un număr nelimitat de
dimensiuni la un cub n-dimensional şi dacă pentru modelarea unei activităţi
complexe este suficient un singur cub n-dimensional. În multe aplicaţii OLAP, se
utilizează date din mai multe domenii de activitate (de exemplu: activitatea
financiară şi activitatea de marketing sau activitatea de producţie şi activitatea de
desfacere). În aceste cazuri, se utilizează mai multe cuburi n-dimensionale sau
structuri multicub. Prin utilizarea structurii multicub este posibil de a integra seturi
de date eterogene. Problema care apare în proiectarea unei structuri multicub este
legată de modul cum se realizează legătura între cuburile n-dimensionale.
Datele multidimensionale sunt împrăştiate. Conceptul de împrăştiere este
frecvent asociat cu datele multidimensionale şi a fost utilizat cu semnificaţia de
valoare lipsă, valoare inaplicabilă şi valoare zero. Problema tratării datelor
împrăştiate este una foarte importantă şi este frecvent dezbătută în lumea bazelor
de date. Proiectanţii de instrumente OLAP au adoptat o varietate de strategii pentru
a trata fenomenul de împrăştiere, dar şi gruparea datelor. Essbase şi Power Play
utilizează structura hypercub, cu un model complex de compresie a datelor.
Cealaltă structură, multicubul, este mai des întâlnită. În aplicaţiile multicub,
proiectanţii descompun baza de date multidimensională într-un set de structuri
multidimensionale (cuburi), fiecare fiind compusă dintr-un subset de dimensiuni
ale bazei de date. O dimensiune poate fi comună la mai multe cuburi. Multicubul
este utilizat pentru a stoca date împrăştiate [Thomsen, 1996].
Utilizatorii pot executa următoarele operaţii de bază pe datele stocate în cubul
n-dimensional:
• Slice şi dice sau selecţii în cub. Slice presupune selecţia unui singur
membru al unei dimensiuni, spre deosebire de dice care presupune selecţia
mai multor membri, din mai multe dimensiuni. De exemplu, „Care sunt
vânzările în luna ianuarie?” este o operaţie slice, iar „Care sunt vânzările
de băuturi în luna ianuarie?” este o operaţie dice;
• Drill-down / roll-up utilizează ierarhiile din dimensiuni şi măsurile pentru

agregări sau de-agregări;
• Drill across combină mai multe cuburi cu una sau mai multe dimensiuni
comune (joncţiunea de cuburi);
• Pivot sau rotirea unui cub pentru a pune în evidenţă alte aspecte analitice.
În cele ce urmează, se va prezenta modul de generare a unui cub în Oracle
Warehouse Builder. Un cub în OWB se poate implementa în relaţional (o tabelă va
stoca cubul de date) sau în multidimensional (în spaţiul analitic). Agregatele sunt
generate fie în timpul procesului de creare a cubului (deploy) sau la momentul
execuţiei unei cereri. În cazul unei implementări MOLAP, datele agregate sunt
generate şi stocate în spaţiul analitic. În cazul unei implementări ROLAP, se vor
crea viziuni materializate care vor stoca agregatele.
Se consideră cubul Cubul_vanzari care va stoca vânzările agregate. Se parcurg
următorii paşi:
 se stabileşte tipul de stocare (ROLAP /MOLAP). Vom alege ROLAP
relational storage, adică se va utiliza o schemă stea. Se vor crea viziuni
materializate pentru stocarea datelor agregate;
 se specifică dimensiunile: Clienti, Produse_dimensiune şi
Timp_dimensiune (figura 3.36). Dimensiunile trebuie create anterior.
Pentru fiecare dimensiune, se stabileşte nivelul de detaliu. Se poate utiliza
aceeaşi dimensiune pentru a defini multiple cuburi. De exemplu,
dimensiunea Timp poate fi utilizată în cubul_vanzari şi în cubul_costuri;
Figura 3.36 Crearea cubului în OWB

Figura 3.37 Stabilirea măsurilor
 se specifică măsurile: vânzări, cantitate vândută (figura 3.37);

 se stabileşte metoda de agregare. De exemplu, se va utiliza funcţia sum()
pentru agregare şi se precizează nivelele de agregare pentru fiecare
dimensiune (figura 3.38);
 se va crea o asociere între cub şi tabela de fapte (figura 3.39).
Figura 3.38 Stabilirea metodei de agregare

Figura 3.39 Asocierea dintre cub şi tabela de fapte
Integrarea tehnologiei relaţionale cu tehnologia OLAP permite realizarea de

aplicaţii cu o funcţionalitate ridicată, mai puţin costisitoare şi care oferă un suport
adecvat atât pentru activitatea de analiză, cât şi pentru activităţile operaţionale. Va
exista un singur stoc de date şi un singur dicţionar de metadate. De asemenea, este
implementată o singură politică de securitate. De exemplu, Oracle cu opţiunea
OLAP realizează integrarea tehnologiei relaţionale cu tehnologia OLAP. Oracle
utilizează baza de date relaţională atât pentru aplicaţii operaţionale, cât şi pentru
aplicaţii analitice. Opţiunea OLAP include un motor de calcul multidimensional ce
permite analize foarte complexe pe datele stocate în spaţiul analitic şi are la bază
tehnologia Express. Datele stocate în spaţiile analitice sunt manipulate cu ajutorul
limbajului de manipulare OLAP (OLAP DML). Acest limbaj este echivalentul
“multidimensional” al limbajului PL/SQL şi extinde facilităţile analitice ale
limbajului SQL. Include funcţii pentru analiza seriilor de timp (de exemplu: funcţia
LAG()), funcţii financiare, funcţii statistice, o mare varietate de metode de agregare
(după nivelul din ierarhie, după anumiţi membri etc.).
Datele pot fi stocate în tabele (tabele de fapte şi tabele dimensionale) sub formă
de schemă stea sau fulg de zăpadă, sau în variabilele din spaţiul analitic, iar
utilizatorii pot accesa datele printr-o interfaţă OLAP sau cu ajutorul limbajului
SQL (de exemplu, instrumentul Oracle BI Discoverer).
Spaţiul analitic (analytic workspace – AW) [Oracle, 2010b]:
• conţine un număr de obiecte multidimensionale (dimensiuni, ierarhii,
măsuri) şi poate fi gândit ca o schemă multidimensională;
• aparţine unui utilizator şi alţi utilizatori pot avea acces la el.
Într-o bază de date Oracle se pot crea mai multe spaţii de lucru analitice. Un
spaţiu analitic în format standard este un spaţiu analitic construit cu un set specific
de obiecte, cum ar fi dimensiuni ierarhice, asocieri de tip părinte, asocieri de tip
nivel. Fiecare obiect trebuie să fie definit cu un set de proprietăţi ce identifică rolul
obiectului şi asocierile lui cu alte obiecte din spaţiu analitic.
Analytic Workspace Manager (AWM) este un instrument de administrare
utilizat pentru:
• a crea spaţii analitice în format standard ce pot fi accesate de aplicaţiile
construite cu Oracle BI Discoverer, Oracle BI Spreadsheet Add-In etc. În
figura 3.40 este prezentat un spaţiu analitic în format standard, creat cu
AWM şi care are denumirea GLOBAL.
• a actualiza spaţiile analitice;
• a crea şi executa planuri pentru agregarea datelor;
• a crea măsuri derivate.
Un utilizator care cunoaşte cerinţele analitice şi are acces la sursele de date
poate construi un spaţiu analitic cu AWM, parcurgând următorii paşi:
• Definirea modelului multidimensional logic. Trebuie definite dimensiunile,
nivelele, ierarhiile, cuburile şi măsurile. În figura 3.41 se vizualizează
nivelele ierarhice ale dimensiunii Clienti, iar în figura 3.42 ierarhia din
dimensiunea Clienti.
Figura 3.40 Spaţiul analitic Global creat cu AWM

Figura 3.41 Definirea nivelelor ierarhice dintr-o dimensiune
Figura 3.42 Definirea ierarhiilor

Figura 3.43 Maparea modelului multidimensional la sursele de date
• Maparea la sursele de date. Sursele de date pot fi tabele (tabele de fapte şi

tabele dimensionale – schemă stea) sau tabele virtuale. De exemplu, în
figura 3.43. este prezentată maparea nivelelor ierarhice din dimensiunea
Client la atributele corespunzătoare ale tabelei dimensionale Clienti.
• Incărcarea şi agregarea datelor în spaţiul analitic.
• Analiza datelor. Datele din spaţiul analitic pot fi vizualizate utilizând

AWM (figura 3.44) şi analizate utilizând instrumentele Oracle Discoverer
Plus OLAP, Oracle BI Spreadsheet Add-In etc.
Figura 3.44 Vizualizarea datelor din cub

Capitolul3-Modelul Dimensional PT Platforma

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Capitolul3-Modelul Dimensional PT Platforma

Încărcat de

Drepturi de autor:

Formate disponibile

Capitolul 3

Modele de date pentru BI

În acest capitol vom prezenta:

3.1 Modelul dimensional

Modelul dimensional este un model conceptual utilizat pentru proiectarea

Modelul entitate-asociere poate fi folosit ca punct de pornire în proiectarea

Tabel 3.1. Analiză comparativă dintre modelul dimensional

O altă clasificare este dată de Ralph Kimball în [Kimball, 1996; Kimball,

• indicatori aditivi care se pot însuma după toate dimensiunile. De exemplu,

dimensionale, iar modelul dimensional trebuie să permită aceste

Figura 3.1 Multiple ierarhii în dimensiunea Timp

Dimensiunile sunt foarte importante în modelarea dimensională şi pot avea:

valorile lor sunt consistente de a lungul proceselor de business. Două

sucursala 1 sucursala 2 sucursala 3

agentia 11 agentia 12 agentia 31

Figura 3.2 Ierarhie asimetrică

• atributul eveniment se referă la un eveniment special (crăciunul,

În cele ce urmează, se va exemplifica modul cum se creează dimensiunea Timp

Figura 3.4 Crearea dimensiunii Timp_dimensiune cu OWB

Se va utiliza o schemă stea şi se vor crea următoarele elemente: o tabelă

Figura 3.5 Stabilirea ierarhiei în dimensiunea Timp_dimensiune

Se vor genera definiţii pentru: atributele dimensiunii Timp_dimensiune (figura

Figura 3.6 Atributele dimensiunii Timp_dimensiune

Figura 3.7 Definiţia structurii tabelei dimensionale Timp_dimensiune_tab

Figura 3.8 Detalii despre nivelele ierarhice

Figura 3.9 Asocierea dintre dimensiune şi tabela dimensională

Figura 3.10 Maparea pentru încărcarea datelor în tabela dimensională

Figura 3.11 Tabela dimensională Timp_dimensiune_tab

Figura 3.12 Dimensiunea Produs [Kimball, 2002]

În cele ce urmează, vom exemplifica modul cum se creează dimensiunea

Figura 3.13 Crearea dimensiunii Produs

2. se stabileşte modul de implementare a dimensiunii: schema stea (ROLAP)

5. pentru fiecare nivel ierarhic se stabilesc atributele corespunzătoare

Figura 3.14 Stabilirea modului de implementare

Figura 3.15 Stabilirea atributelor dimensionale

Figura 3.16 Stabilirea ierarhiei

Figura 3.17 Stabilirea atributelor corespunzătoare pentru fiecare nivel ierarhic

Figura 3.18 Stabilirea tehnicii de urmărire a modificărilor

Figura 3.19 Structura dimensiunii Produs

Figura 3.20 Asocierea dintre dimensiune şi tabela dimensională

Urmează apoi procesul de creare a obiectelor definite (figura 3.21).

Figura 3.21 Procesul de creare a dimensiunii Produs

Figura 3.22 Tabela dimensională Produs_tab

Structura tabelei dimensionale este prezentată în figura 3.22 (s-a utilizat

poate schimba de la categoria X la categoria Y, sau un client se poate schimba de la

Figura 3.23 Dimensiuni demografice

Aplicaţiile tranzacţionale efectuează operaţii de actualizare pe înregistrările

mare; 3) dacă se modifică cheile surselor, se pune întrebarea cum se face

Ralph Kimball propune patru tehnici pentru a gestiona modificările atributelor

Suprascrierea valorilor vechi (slowly changing dimension/SCD tip 1)

Figura 3.24 Suprascrierea valorilor vechi (SCD tip 1)

Păstrarea istoriei prin adăugarea unei noi înregistrări (SCD tip2)

CNP Nume Stare civilă

Partiţionarea istoriei folosind tabele istorice

Figura 3.26 Tabela cu istoricul atributului stare civilă

Păstrarea parţială a istoriei (SCD tip 3)

Figura 3.27 Păstrarea parţială a istoriei

În continuare, vom prezenta un exemplu de implementare a unei dimensiuni de

Figura 3.28 Implementarea unei dimensiuni de tip SCD3, cu OWB

Figura 3.29 Structura unei dimensiuni de tip SCD3

Figura 3.30 Structura tabelei dimensionale corespunzătoare

Există, de asemenea, posibilitatea de a se modifica în timp şi ierarhiile şi

Colecţiile de fapte şi dimensiunile pot fi reprezentate într-o bază de date