Tehnologii Data Warehouse

2011

Cuprins
1

Introducere. Scopul DataWarehouse. Caracteristici...............................................................

1.1
Introducere.......................................................................................................................
1.2
Scop i Cerine.................................................................................................................
1.3
Caracteristici....................................................................................................................

Trecerea de la sisteme operaionale la sisteme de suport decizional...................................

2.1
Contextul apariiei. Evoluie..........................................................................................
2.2
Accesul la informaie.....................................................................................................

Utilizarea sistemelor Data Warehouse pentru un operator de telecomunicaii mobile

20
3.1
Piaa Telecomunicaiilor mobile....................................................................................
3.2
Implementarea Data Warehouse n telecomunicaiile mobile......................................
3.3
Avantajele oferite de Data Warehouse n telecomunicaiile mobile..............................

Consideraii de design..............................................................................................................
4.1
Modelarea relaional. Baze de date normalizate..........................................................
4.2
Modelarea dimensional. Baze de date demormalizate.................................................
4.3
Granularitatea.................................................................................................................
4.4
Partiionarea...................................................................................................................
4.5
Indexarea........................................................................................................................
4.6
Capcane n modelarea datelor........................................................................................

Modelul de date.........................................................................................................................
5.1
Nivelul Conceptual........................................................................................................
5.2
Nivelul logic..................................................................................................................
5.3
Nivelul fizic...................................................................................................................
5.4
Concluzie.......................................................................................................................

Bibliografie................................................................................................................................

1 Introducere. Scopul DataWarehouse.

Caracteristici
1.1

Introducere

Un Data Warehouse este o baza de date proiectat pentru a satisface necesitile

legate de informaiile cheie din cadrul unei organizaii. Acesta integreaz date dintr-un
numr variat de sisteme operaionale i este de obicei ncrcat cu informaii la intervale
regulate. Depozitul de date conine informaii ierarhizate n timp ce permit analiza a
factorilor de performana dintr-o perioad ndelungat.
Avnd n vedere c cerina de baz pentru orice sistem informatic este aceea de a
asigura informarea corecta i n timp util a tuturor factorilor de decizie dintr-o companie,
activitatea de realizare a sistemelor informatice este acceptata de majoritatea specialitilor
prin prisma utilizrii tehnicii de calcul pe dou planuri i anume n activitatea de
fundamentare a deciziilor i n asistarea activitii curente desfurate n organizaie.
Primul plan se caracterizeaz prin existena unor produse software specializate n
analiza alternativelor decizionale, urmrindu-se gsirea celei mai favorabile decizii
pentru societatea comerciala. Cel de-al doilea plan, urmrete dezvoltarea de aplicaii
informatice de gestiune economic la nivel de activitate sau grup de activiti n cadrul
companiei.
Pentru obinerea performanelor la nivelul proceselor de afaceri asistate, se
impune ca sistemele s controleze mediul prin primirea datelor, prelucrarea lor i
returnarea rezultatelor suficient de rapid pentru a fi n msur s influeneze funcionarea
proceselor n timp real. Prelucrarea n timp real cere introducerea imediat n sistem a
datelor, a mesajelor transmise de la terminalele sursa. Un numr mare de staii, aflate la
distan i legate n sistem prin intermediul unor echipamente de comunicaie de mare
viteza pot lucra simultan: unele actualizeaz fiiere, altele particip la interogari etc.
Sistemele informatice n timp real se bazeaz pe soluii tehnologice avansate:
procesoare puternice; memorii de masa cu acces direct; legatur direct ntre calculatorul
electronic i sistemul de comunicaie; terminale diferite adaptate nevoilor; perfecionri
ale echipamentelor i canalelor de comunicatie; alocarea spaiilor de memorare i
prelucrari preliminare n retea; realizarea unor tehnici evoluate de programare asigurnd
producerea software-ului necesar.
Acumularea unor mari cantiti de date, necesare funcionrii activitii i lurii
corecte a deciziilor nu mai este o problema din punct de vedere tehnic. Acum se pune
problema extragerii din multitudinea informaiilor existente, a celor mai relevante pentru
problema dat, ntr-un timp scurt i cu un cost cat mai mic. Aa s-a nscut ideea
structurrii informaiei n depozite de date (Data Warehouse sau DW). Depozitele de date
reprezint o cerin acut a organizaiilor moderne (fie ele ntreprinderi, bnci, societi
de asigurri, sector public sau administrativ) si, totodat, o realitate tehnologic pus n

practic din ce n ce mai frecvent. Un sondaj realizat de META Group n 1998 arata ca
90% dintre managerii intervievai intentionau lansarea unor proiecte de implementare a
acestui concept. Segmentul de pia legat de depozitele de date are o rata anual de
crestere de cca. 35%.
William Inmon este considerat printele noiunii n nelesul ei curent (Inmon
deine de altfel trademark-ul termenului Data Warehouse). Viziunea sa despre depozitele
de date se concentreaz asupra rolului acestora, de baza informational a deciziei
manageriale, pstrnd astfel un nivel nalt de generalitate. Un alt nume important este cel
al lui Earl Hadden, cel care a enuntat, a fundamentat i a experimentat cu succes o
metodologie riguroas pentru implementarea rapid a depozitelor de date (90 day
winners). O serie de societi comerciale i-au adus la rndul lor contribuia la
clarificarea, dezvoltarea i popularizarea noii tehnologii. Printre acestea se remarc
Software AG, Oracle, Red Brick Systems, Prism Solutions, MicroStrategy, IBM i SAP.
Din perspectiva economic, globalizarea comerului, ascuirea dramatic a
concurenei, scurtarea spectaculoasa a ciclurilor de viaa a produselor - datorit dinamicii
tehnologiei, impunerea unor cerine calitative extrem de ridicate precum i alte asemenea
evoluii, au evideniat si mai mult valoarea strategic a informaiei. Manipularea
operativ a informaiei a impus la rndul ei noi modele manageriale, mai versatile i mai
eficiente. Nevoia de a rspunde n timp optim cerinelor pieei a condus la
descentralizarea i la reducerea numrului nivelurilor decizionale, consacrnd ierarhiile
plate, care se bazeaz pe delegarea puterii decizionale operative catre esalonul
managerial secund. Atat la nivelul managementului strategic ct i la nivelul
managementului operativ, nevoia de informaie pur i corect a devenit vitala.
Din perspectiva tehnologic, ultimii ani au adus puterea de calcul la preuri
accesibile. Servere paralele bazate pe microprocesoare accesibile ca pre, rivalizeaz ca
putere cu supercalculatoarele, la o fractiune din pretul acestora din urm. Sistemele de
baze de date pot exploata la maximum arhitecturile hardware paralele, iar evoluiile spre
sisteme deschise permit o conectivitate aproape total la orice fel de surse de date i
interoperabilitate ntre diverse platforme software i hardware. Mediile de stocare
magnetice i optice admit volume de ordinul tera i chiar mai mult. PC-urile au ajuns i
ele la maturitate. Puterea lor este acum suficienta pentru funciile de analiz i prezentare
care le sunt rezervate, iar interfeele grafice intuitive le fac accesibile utilizatorilor nontehnici sau fr o pregatire special n domeniul ultilzrii intefeelor.

1.2

Scop i Cerine

Obiectivul principal al proiectului este crearea unui sistem de suport decizonal

care, acionnd ca un singur punct n care se aduc, din mai multe surse, numai
informaiile utile, s permit analiza, supravegherea i predicia comportrii clienilor,
respectiv diferitelor departamente ale unei companii de telecomunicaii.
Diferenierea ntre bazele de date informaionale i cele operaionale a aprut din
cteva motive:

Datele ce servesc nevoilor operaionale sunt diferite din punct de vedere

fizic de cele ce servesc unor nevoi de analiza sau unor nevoi informaionale

Tehnologia ce susine procesarea operaional este fundamental diferita de

tehnologia folosit pentru sisteme informaionale sau analitice

Utilizatorii datelor operaionale sunt diferiti de cei ce folosesc datele

analitice

Caracteristicile de procesare ale mediului operaional sunt diferite de cele

ale mediului informaional
Un astfel de sistem n domeniul telecomunicaiilor este de important strategic,
deoarece companiile de telecomunicaii lucreaz cu un volum foarte mare de date n
condiiile unei piee concureniale. Volumul foarte mare de date, rezult din numrul
clienilor i varietatea serviciilor i este amplificat de nevoia de a pstra i o istorie pe
baza creia s se poata realiza analiz sau predicie.
La polul opus, un sistem DataWarehouse nu ar fi potrivit pentru o companie mic.
Dimensiunile reduse ale domeniului de activitate vor permite analizarea performanelor
companiei fr existena unui sistem integrat. n acelai timp, dac concurena n
domeniul respectiv nu este ridicat, investiia ntrun sistem de suport decizinal nu se
justific.
Pentru aceste motive, i altele care s-ar putea gsi, sistemele operaionale sunt
separate de cele informaionale sau analitice i trebuie s ndeplineasc o serie de cerine
suplimentare fa de un alt proiect IT. Cerinele generale pe care sistemul de suport
decizional trebuie s le ndeplineasc pentru o implementare cu succes:

Sistemul trebuie s prezinte informaia astfel nct ea s fie accesibil

Prezentarea datelor trebuie s fie intuitiv i evident pentru un utilizator care i
cunoate afacerea. Utilizatorii doresc s separe sau s combine datele n
nenumarate combinaii (proces cunoscut sub numele de slicing and dicing).
Aplicaiile de acces trebuie s fie uor de utilizat i n acelai timp s returneze
rezultatul interogrilor cu un timp minim de ateptare.
Datele trebuie s fie consistente.
Datele vor fi asamblate din variatele surse ale organiziei, curate i integrate
pentru a fi credibile. Informaia disponibil pentru un departament trebuie s fie n
corespondent cu informaia diponibil altui department. Dac dou variabile au
acelai nume, ele trebuie s reflecte acelai nume sau din contr dac dou
variabile au semnificaii diferite, ele trebuiesc denumite diferit.
Sistemul trebuie s fie adaptiv i s reflecte cu uurin schimbrile din
organizaie.
Schimbarea este o realitate care nu poate fi neglijat. Se pot modifica nevoile de
informaie ale utilizatorilor, mediul de afaceri, datele n sine sau tehnologia.
Sistemul informaional trebuie s in cont de aceste schimbri inevitabile.
Adaptabilitatea sistemului se reflect n faptul c datele existente trebuie s nu fie
afectate iar datele noi s poata fi primite n warehouse.
Sistemul de suport decizional trebuie bazat pe un depozit sigur de date, la
care nu au acces dect utilizatori autorizati.
Sistemul trebuie s permit controlul accesului pentru a proteja datele

confideniale ale organizaiei.

Data Warehouse-ul trebuie s acioneze ca o fundaie pentru mbuntirea
procesului decizional. Datele prezente trebuie s fie numai acelea care aduc un
plus de informaie n procesul decizional. Outputul unui astfel de sistem trebuie s
fie o dovad a deciziilor ce vor fi luate.
Comunitatea de utilizatori trebuie s accepte sistemul informaional.
Spre deosebire de sistemele operaionale pe care utilizatorii sunt de multe ori
obligai de mprejurri s le foloseasc, folosirea sistemului de suport decizional
nu impune o constrngere atat de rigid. Pentru acest motiv este cu att mai
important ca sistemul s fie acceptat de utilizatori.

1.3

Caracteristici

Putem identifica patru caracterisitici comune ale implementrilor DataWarehouse,

indiferent de domeniul de aplicabilitate. Aceste caracteristici sunt:

Centrarea modelului pe subiect (Subject Oriented)

Integrat

Non-volatil

Centrat pe timp
Sitemul de fat, ce se aplic ntro companie de telecomunicaii respect toate
aceste caracteristici.
Centrarea modelului pe subiect
Spre deosebire de sistemele operaionale, care sunt organizate n jurul unei
aplicaii funcionale ale companiei spre exemplu aplicaii de facturare (Billing), de
management al relaiilor cu clienii (CRM), sistemele data warehouse au ca nucleu al
informaiei un anumit subiect cheie a crui analiz se dorete.
Modelul de date n proiectul de fa este organizat n jurul unui numar de subiecte
cheie din domeniul telecomunicaiilor mobile. Acestea sunt subiecte pe baza crora
putem analiza, urmri i msura rezultatele companiei ( financiare sau non-financiare).
Exemple de astfel de subiecte sunt: Clienti, Produse, Contracte, Parteneri, Canale de
distribuie.
Integrate
Faptul c n data warehouse datele sunt integrate nseamn c ele sunt organizate
ntrun unic format de msur i referint (sunt msurate n acelai fel i refer acelai
lucru). Aceasta este poate cea mai important caracteristic a sistemului data warehouse.
Datele intr n data warehouse din multiple surse disparate. Pentru ca datele s fie
integrate, ele trebuie s fie convertite, reformatate, renumerotate, sumarizate, etc.
Rezultatul este o unic imagine a activitilor companiei.
Datele operaionale sunt orientate pe aplicaii, n sensul c organizarea lor este
optimizat pentru a servi procesului tranzacional, dinamicii sistemului. n contrast, DW
este orientat pe subiectele importante ale procesului economic, cum ar fi: clieni,
furnizori, produse, activiti. Mai mult, date eseniale din perspectiva operaional sunt
complet lipsite de relevan din perspectiva informaional. Aceste date vor fi exluse din
data warehouse. (ex. ID-uri cu semnificaii locale)
Raiunea pentru care data warehouse-ul este creat l constituie asigurarea datelor
pentru a rspunde nevoilor informaionale ale ntregii organizaii, asigurnd faptul c
rapoartele generate pentru diverse compartimente vor furniza aceleai rezultate. Sistemul
operaional este de cele mai multe ori format din subsisteme semi-independente, create la
momente diferite, de echipe diferite, n maniere diferite, rezultnd un amalgam care, dei
funcional si de nenlocuit din punct de vedere operaional sistemul nu poate fi folosit
pentru analiz. Simpla lui structura l face imposibil de folosit n analiz

Exemplul de mai jos ilustreaz modul de integrare a informaiilor referitoare la

client, la trecerea lor din sistemele operaionale (sisteme orientate pe aplicaie) n data
warehouse,. ntro firma de telefonie mobil.

Fig 1: Integrarea datelor la ncrcarea lor n Data Warehouse

Aplicaiiile operaionale sunt sisteme independente, la designul i dezvoltarea
crora, fiecare productor are libertatea de a i stabili propriul format. Lipsa unor
standarde (codare, convenii de nume, atribute, mrimi de atribute) sau constrngeri
diferite care se aplicau fiecrei aplicaii n parte au dus la apariia unor aplicaii diferite
n care aceleai date apar reprezentate fie diferit fie parial.
Un operator de telefonie mobil dezvolt mai multe linii de afaceri, acestea, dei
sunt interconectate, au i caracteristci unice. Data Warehouse este locul n care toate
aceste date sunt consolidate.
Spre exemplu n Data Warehouse avem date referitoare la comportamentul de
utilizare a serviciilor n funcie de client, mprite pe diferitele linii de servicii oferite. Cu

aceleai date putem deasemenea analiza profitabilitatea clientului sau utilizarea

potenialul pieei. n timp ce acestea pot fi vzute ca funcii analitice distincte, ele au n
comun atribute relaionate care pot fi furnizate din Data Warehouse

Non-Volatil
Data Warehouse trebuie s fie o structur informaional stabil, a unui mediu de
suport decizional. Modelul trebuie s fie astfel proiectat, nct s susin o astfel de
stabilitate. Datele nu vor fi direct modificate ci vor fi populate periodic cu datele noi din
aplicaiile operaionale.
Sistemul operaional al unei organizaii tinde mereu s reflecte realitatea curent.
Astfel, el se afl ntro continu evoluie iar datele pe care le conine sunt relevante doar
pentru momentul n care sunt accesate. Orizontul de timp pe care l acopera este de regul
de 60 pn la 90 de zile, deoarece dup acest interval tranzaciile efectuate sunt arhivate,
fiind considerate deja de domeniul istoriei, deci neinteresante din perspectiva operativ.
Pentru nevoile analizei, dimpotriv , informaiile cu caracter istoric sunt eseniale,
deoarece ele pun n eviden tendine care reprezint fundamentul unei prognoze corecte.

Fig 2: Caracterstica de non-volatitilitate a Data Warehouse-ului n comparaie cu

sistemele operaionale
Spre deosebire de sistemele operaionale n care datele sunt n mod curent scrise,
modificate i accesate, n data warehouse datele sunt ncrcate n mas (zilnic,
sptamnal, lumar) iar apoi accesate. Datele din data warehouse nu mai sunt modificate,
pentru a pstra imaginea datelor la un anumit moment dat. Dac se produc schimbri o
nou nregistrare este inserat. n acest fel n data warehouse pstrm date cu caracter
istoric. Nu avem numai imaginea curent (ca n sistemele operaionale) ci i imagini la
diferite momente de timp. n continuare, pentru a referi imaginea datelor la un anumit
moment de timp vom folosi termenul de snapshot.
Centrat pe timp
Aceast caracteristic se refer la faptul c fiecare nregistrare din data
warehouse este valabil pe un anumit interval de timp. nregistrrile vor avea mrci de
timp i versiune (DATE_FROM, DATE_TO, DW_ENTRY_DATE, VESION). Acestea
sunt necesare pentru a indica intervalul de timp sau momentul la care nregistrarea se
refer.
Datele din warehouse sunt date despre un orizont de timp mult mai mare dect n
cazul sistemelor operaionale. Dac ntrun sistem operaional vom avea date pe 2-3 luni,
n warehouse vom pstra istorie pe 5-10 ani, deoarece pentru a putea preconiza evoluiile

viitoare i pentru a putea susine procesul decizional, istoria trebuie foarte bine urmrit
i analizat.

DW se constituie ntrun istoric al sistemului operaional, constituit dintro serie de

"instantanee", imagini la diverse momente n timp. Orizontul de timp pe care l acopera
DW este de cel puin cinci ani, ajungnd uneori la zece ani, n funcie de dinamica
evoluiei pieei i, deci, de relevana datelor cu caracter istoric pentru nevoile analizei.
Din punct de vedere tehnic, acesta implic faptul c orice nregistrare din DW
corespunde unui moment de timp specificat. Orice cheie de acces la informaiile din DW
va cuprinde i o component temporal.
Esena aplicaiilor operaionale este actualizarea continu a coleciilor de date,
actualizare realizat n general pe baza tranzacional. Orice tranzacie procesat implic
inserarea unor noi nregistrri, modificarea sau eventual tergerea altora etc. Cu totul
altfel stau lucrurile n cazul DW, unde o astfel de dinamic lipsete. Practic, aici are loc
adaugarea periodic a unor date extrase din sistemele operative. Din punctul de vedere al
aplicaiilor care folosesc DW, accesul la date este doar pentru citire.

2 Trecerea de la sisteme operaionale la sisteme de

suport decizional.
2.1

Contextul apariiei. Evoluie

Sistemele decizionale de tip DataWarehouse vin ca un rspuns la inabilitatea

vechilor implementri de sisteme de suport decizional de a rspunde nevoilor de raportare
ale companiei. Spre exemplu departamentul de markenting dorete s afle rezultatul
companei, obinut ntro anumit regiune. Dac observ c acesta este nesatisfctor, va
dori investigarea n amnunt a rezultatului pe fiecare produs, comparat cu cifra de vnzri
propus. Pentru a remedia situaia, managerul trebuie s ia o decizie rapid lund n
considerare toi factorii. Cum informaiile amnunite nu se gsesc ntro singur surs, va
trebui s adunm date din mai multe aplicaii pentru a putea construi raportul. n
diferitele aplicaii din care avem nevoie de date, de cele mai multe ori nu vom ntlni
acelai format de date sau exact aceleai entiti. Raportul cerut fie nu va putea fi fcut n
timp utill, fie datele nu vor fi exacte.
Putem observa umtoarea evoluie a sistemelor de suport decizional, prin care o
companie trece prin ncercrile sale de a crea un sistem informatic ce s susin deciziile
strategice.
Rapoarte ad hoc
Utilizatorii din departamentele de marketing sau financiar solicit
departamentului IT un anumit raport. Departamentul IT va crea un program sau un script
SQL special pentru aceast cerere. De obicei cte unul pentru fiecare cerin.
Programe specializate pentru extracte
n aceasta etap, departamentul de IT ncearc s anticipeze cerinele ce le vor fi
solicitate periodic. Departamentul IT va crea o suit de programe pe care rulndu-le
periodic vor extrage date din mai multe aplicaii. Pentru acele cereri care nu pot fi
satisfacute din aceste extracte, departamentul IT va crea un program special.
Aplicaii mici
Aceasta etap este o formalizare a programelor pentru extracte. O aplicaie
simpl, se poate folosi de extractele generate anterior pentru a genera rapoarte n funcie
de solicitare. O asfel de aplicaie ar putea permite chiar vizualizarea direct a rapoartelor.
Centre informaionale
Sunt definite ca un loc n care utilizatorii puteau vizualiza rapoartele predefinite.
Oameni de IT trebuiau s fie prezeni pentru a putea crea rapoarte ce nu sunt predefinite.
Sisteme de suport decizional
Acestea au ca scop furnizarea de informaii strategice. La fel ca i ncercrile
timpurii i ele sunt bazate pe fiiere extrase din diferite aplicaii.

Sisteme informaionale la nivel executiv

Caracteristca cea mai important acestora este usurina cu care pot fi utilizate. Ele
furnizeaz informaiii cheie n fiecare zi. Dac se dorete o analiza dup produs, regiune
sau alta dimensiune, aceasta este posibil numai dac au fost deja programate.

Cum difer?
OPERAIONAL

INFORMAIONAL

CONINUTUL DATELOR

Valori curente

Arhivate, derivate,
sumarizate

STRUCTURA DATELOR

Optimizate pentru
tranzacii

Optimizate pentru interogri

complexe

FRECVENA
ACCESRILOR

Mare

Medie sau Redus

TIP DE ACCESRI

Citire, modificare,
tergere

Citire

UTILIZARE

Predictibil, repetitiv

Ad hoc, aleatoare, euristic

TIMP DE RSPUNS

De ordinul secundelor

De ordinul minutelor

UTILIZATORI

Numeroi

Relativ puini

2.2

Accesul la informaie

Utilizatorii pot accesa datele coninute n sistemul de suport decizionat de tip data
warehouse prin intermediul unor interfee de nivel aplicaie. Numim acest nivel nivelul
front-end. Produsele software cel mai adesea ntalnite pun la dispoziia beneficiarilor:

Unelte de raportare i interogare (ex: taskuri de volum mare, vederi orientate pe

subiect);
Unelte de dezvoltare de aplicaii (pentru dezvoltarea de aplicaii proprii);
Unelte EIS (Executive information system);
Unelte Data mining. Scopul data mining l constituie filtrarea datelor coninute n
DW, n vederea pregtirii acestora pentru evaluarea i analiza ulterioar. Cel mai
simplu tip de filtre l reprezint aa numitele praguri, care pot fi rigide, variabile
sau adaptive. Pragurile rigide genereaz valori fixe, n cazul nerespectrii lor (la
obinerea unei valori mai mari sau mai mici), fiind automat generat un mesaj de
atentionare. Pragurile variabile sunt cele a cror valoare depinde de context (de
exemplu factorii de sezon). Pragurile adaptive sunt orientate dup modul de
distribuire a deviaiilor valorice astfel ca, de exemplu, o deviaie a volumului de
traffic cu 10% pe o anumit zon geografic trebuie altfel interpretata nct s
realizeze acelasi procent la nivel global.
On-line analytical processing tools (OLAP). Baza conceptului OLAP i a analizei
de date multidimensionale formeaz cuburi de date (Datacube). Descrierea unei

mulimi de dimensiuni i a unei mulimi de mrimi alctuiesc un cub de date.

Conceptul OLAP ofera de asemenea posibilitatea de utilizare a cuburilor virtuale
(Virtual Cube). Similar cu vederile din modelul relaional, un cub virtual poate fi
alctuit prin definirea de legturi ntre cuburi de date fizice. Pentru utilizator,
accesul la cuburile fizice si la cele virtuale este transparent, n sensul c nu
percepe nicio diferen ntre cele dou din punctul de vedere al ccesului la date.
Cubul virtual nu conine date materializate, fiind creat la momentul interogrilor
asupra cuburilor fizice de date. n cadrul analizelor intermediate cu ajutorul
tehnologiei OLAP se realizeaz operaii specifice: roll-up, drill-down, slicing,
dicing, pivot.

Roll-up este operaiunea prin care datele se agreg, fie printrun pas n sus n
ierarhia de dimensiuni, fie prin reducerea numrului de dimensiuni. Spre exemplu n loc
s grupm datele dup zi, printro operaiune roll-up le vom grupa dup lun sau trimestru
sau an (urcm n ierarhia de timp).

Fig 3: Exemplu de
folosire a
funcionalitii Drill
Up n Cognos 8 BI
n al doilea caz de roll-up, s presupunem c vizualizm o mrime dup data
activrii i dup localitate, eliminnd una dintre cele dou dimensiuni mrimea se va
agrega dup dimensiunea rmas.

Fig 4: Drill Up
prin elimiarea
de dimensiuni

Drill-down este operaiunea invers roll-up. O astfel de operaiune vizualizeaz

datele de la date mai generale, la date specifice, detaliate. Operaiunea poate fi fcut fie
prin a folosi o dimensiune de pe un nivel inferior al ierarhiei, fie prin a aduga noi
dimensiuni. n exemplul urmtor vizualizm datele pentru toate regiunile trii, cobornd
un pas n ierarhie vizualizm datele pe toate judeele componente ale regiunii selectate,
cobornd nca un pas vizualizm datele dup mprirea urban / rural a judeului selectat.

Fig 5: Drill Down

Slice realizeaz o filtrare dup o dimensiune din cub, realiznd astfel un subcub.
n exemplul urmtor am filtrat micrile de balan dup dimesiunea pozitiv / negativ,
pstrnd numai micrile pozitive (bonus si recharge).

Fig 6: Slice
Dice este operaiunea prin care putem realiza fitrri dup mai mult de o
dimensiune n exemplul urmtor am filtrat, pe lng tipul micrile de balan i dup o
dimensiune de timp: anul activarii s fie ntre 2005 si 2007.

Fig 7: Dice

Pivotoarea este o operaiune de vizualizare, prin care se inverseaz axele unei

vederi pentru a oferi o nou perspectiv. n exemplul urmtor am afiat sub forma unor
coloane verticale valoarea veniturilor dup trimestru pentru fiecare regiune. Apoi am
pivotat graficul astfel nct s afiam sub forma unor coloane verticale aceleai venituri,
ns o afiare dup regiune pentru fiecare trimestru.
n primul caz analistul DSS poate observa foarte uor evoluia de la trimestru la
trimestru pentru ntreaga companie avnd i informaie despre contribuia fiecarei regiuni
la performana general pe trimestru.
n al doilea caz poate fi urmrit cu uurin evoluia fiecrei regiuni de la
trimestru la trimestru mai repede dect evoluia general de la trimestru la trimestru.

Fig 8: Pivotare

3 Utilizarea sistemelor Data Warehouse pentru un

operator de telecomunicaii mobile
3.1

Piaa Telecomunicaiilor mobile

n ultimele zece decade, industriile din toate sectoarele de activitate au suferit

schimbri profunde n ceea ce privete mediul de afaceri. Concurena, avasarea
tehologic i globalizarea exercit o mare presiune asupra operatorilor de telecomunicaii
i abilitatea lor de a rspunde acestor schimbri.
Operatorii actuali de telecomunicaii au de depit provocri precum:

Concurena continua provenit de la o deregularizare global;

Micrile puternice de pe pieele n curs de dezvoltare;

Un declin profund al profitului obinut pe segmentul de telefonie-voce;

Cererile n cretere legate de noile tehnologii din domeniul comunicaiilor;

Reducerea de achiziii.
n industia telecomunicaiilor, deregularizarea a atras concurena global i pe plan
local. Acest fenomen a determinat i determina nc erodarea acestui segment de piat i
amenin profitul obinut.
Concurena a determinat apariia unor produse alternative, cu pre accesibil, ca 3G,
VOIP, serviciile ce in cont de locaie, etc. Aplicaiile multi-media au adugat un mare
factor de risc pentru o industire ce are nevoie de o mare infuzie de capital pentru a-si
mbunti infrastructura i sistemele de facturare. n tot acest timp banii ctigai din
telefonie sunt tot mai puini.
Drept rspuns, muli operatori de telefonie se lupt s obin i s-i menin
poziia pe pia prin:

Schimbarea orientrii de la segmentul de achiziii spre reinerea clienilor,

rectigarea segmentelor de pia i obinerea unora noi, profiatabilitate.

Punerea accentului pe dezvoltarea interioar n special n ceea ce privete

pstrarea segmentului de pia.

Scderea duratei de garanie i reducerea conturilor provenite din reele

prin mrirea duratei de utilizare a echipamentelor.

Dezvoltarea, vnzarea de noi produse la intervale mai scurte de timp.

mbuntirea relaiei cu clienii pentru a obine loialitatea acestora.

Mrirea puterii de decizie a angajailor.

Restructurarea organizaiilor pentru a fi mai receptive la nevoile pieei i

cerintele clienilor.
Luarea deciziilor pentru a implementa toate acestea este o adevarat provocare
fr un data warehouse sau fr tool-uri adecvate. Luarea deciziilor corecte n cel mai

scurt timp pote face diferena ntre supravieuire i faliment pe o pia foarte competitiv
i n continua schimbare.

Pentru a trece peste obstacolele ntlnite, operatorii trebuie:

S atrag ct mai muli clieni ce aduc profit mare (sau cu un mare

potenial);

S mreasca numrul produselor care atrag clieni;

S diminueze costurile;

S penetreze noi segmente de piaa;

S mbuntiasca promovarea de produse ctre clienii care au un

potenial mare de a aduce profit;

S reduc pierderea de clieni.

Toate acestea pot fi fcute prin implementarea unei soluii de data warehouse.
Data Warehouse ofera informaiile rapid i ntrun format care sprijin procesul de luarea
a deciziilor.
Acest sistem permite exploatarea potenialului informaiei detaliate, dar i a
informaiilor agregate din alte baze de date mai mici, acum accesibil utilizatorilor din
business.
Business Intelligence i Data Warehouse au urmtoarele utilizri frecvente:
Prospectarea clienilor i a segmentului de achiziii
Prevedera pierderilor de clieni i a procesului de reinere a acestora
Profitabilitatea promoiilor de loialitate, rectigare i preluare de clieni
Succesul procesului de promovare a produselor i msura n care acestea i
ating inta.
Profitabiliatea campaniilor de marketing
mbuntirea sistemelor operaionale

3.2

Implementarea Data Warehouse n telecomunicaiile mobile

Sitemul de data warehouse ofer informaiile rapid i ntrun format care sprijin
procesul decizional. Un data warehouse permite operatorilor s exploateze la maxim
potenialul infomaional, folosindu-se de date att la nivel de detaliu, ct i ntrun grad
mai mare de sumarizare, necesar utilizatorului cu capacitate de decizie sau cu
responsbilitate de raportare.
Un sistem de data warehouse poate reine informaii despre sectoarele de care
operatorii sunt mai preocupati n aceasta perioad i ofer posibilitatea unei analize
detaliate asupra acestora:

Pierderea de clieni;

Nemulumirile legate de procesul de tarifare;

Gradul de utilizare al reelei;

Eficiena serviciului de asisten clieni;

Profitabilitatea produselor;

Performaa canalelor de distribuie;

Procesul de reinere a clienilor;

Reuita campaniilor efectuate;

Problema cu care se confrunt operatorii nu este legata neaprat de volumul de

date, ci de consintena datelor, de acurateea i complexitatea lor, de actualitatea acestora.
n ultimii ani, pentru aceste probleme s-au cutat o rezolvare i au rezultat astfel
urmatoarele sisteme alternative: Decision Support Systems, Executive Information
Systems and Management Information Systems.
Acestea descarc datele din sisteme surs i ruleaz diverse programe pentru a le
reda ntrun format utilizabil care s permit rularea de interogri. Majoritatea acestor
sisteme se bazeaz pe arhitecturi mainframe i s-au bucurat de un succes limitat din
urmatoarele cauze:

Sistemele OLTP nu au fost concepute pentru a servi analizei de date

Datele sunt diverse i complexe
Accesul utilizatorului este complex i ngreuneaza operaiile de business.

Fig 9: Arhitectura unui sistem Data Warehouse

3.3 Avantajele oferite de Data Warehouse n telecomunicaiile

mobile
Sistemul de data warehouse ajut operatorii nu numai s fac fa presiunii la care

sunt supui, dar mai mult, s o transforme ntrun avantaj de business. Majoritatea
segmentelor de business sunt avantajate de construirea unui data warehouse astfel:
Avantaje competiionale ctig realizat prin campanii de marketing,
promovarea de pachete de produse, oferirea de preuri promoinale, vnzarea produselor
pe segmente de piaa bine determinate.
Informaii cheie n relaia cu clientul ctigat prin nelegerea preferinelor
clientului asupra unei game de produse, printro abordare preventiv cu privirea la
satisfacerea nevoilor clientului, prin punerea accentului pe construirea i reinerea unei
baze de clieni valoroi.
Reducerea riscurilor - ctigat prin prevederea tendinelor de evoluie a pieei.
Creterea profitului prin planuri tarifare, optimizarea profitului,
performante, respectarea unor reguli privind raportul cost - discount

preuri

Eficiena organizaional ctigat prin realizarea de aliane profitabile,

meninrerea unei structuri organizatorice optime, recompensarea loialitatii i a
aducerea de profit mare.
Avantaje asupra concurenei pot fi obinute prin folosirea infirmaiilor reinute n
data warehouse pentru a dezvolta strategii coerente, care s permit Operatorului s
rspund la presiuniea generat de competitori, la nevoia de a mri ritmul de dezvoltare
al activitilor de marketing, globalizare i inovaie n materie de produse.
Pentru a obine avantaje de business din aceast situaie, sistemul de data
warehouse poate fi folosit n scopul consolidrii datelor despre:

Tendinele de business pe anumite perioade

Tipuri de produse cerute i diverse oportuniti

Targeturi de activitate i performan

Oportuniti de vnzare de produse pe anumite segmente de pia

mprirea pieei pe anumite tipuri de clieni

Performaele canalelor de distribuie (vnzare de produse i servicii)

Procesul de tarifare
Organizarea informaiilor dup aceste criterii ajut la obinerea de avantaje prin
identificarea oportunitilor pentru:

Campanii de marketing cu o int bine determinat

Personalizarea produselor

Structurarea produselor n pachete

Urmrirea performaelor

Evoluia vnzrilor

Detectarea canalelor de distribuie ineficiente

Oferirea de preuri promoionale

Crearea de aliane competitive

Previziuni n legatur cu evoluia pieei

Emiterea de previziuni pentru ctiguri, costuri i stabilirea unor strategii.

Consideraii de design
n domeniul bazelor de date de tip Data Warehouse exist dou paradigme
recunoscute.
Paradigma lui Bill Inmon: Data warehouse este parte a unui sistem de suport
decizional integrat. O companie poate avea un data warehouse i data mart-urile
i iau informaii din data warehouse. Informaiile stocate n data warehouse sunt
n a treia form normal.
Paradigma lui Ralph Kimball: Data warehouse este un conglomerat al tuturor
data mart-urilor din companie. Modelul informaional este ntotdeauna unul
dimensional, denormalizat.

Cele dou paradigme reprezint filozofii diferite i niciuna din aceste doua idei nu
poate fi considerat corect sau greit. n realitate majoritatea companiilor folosesc
sisteme data warehouse mai apropiate de ideea lui Ralph Kimball. O posibil explicaie a
acestui fapt este c sistemele data warehouse apar ca un efort al unui departament, deci
i au originea ntrun data mart. Pe msur ce evolueaz i mai multe data mart-uri sunt
dezvoltate, acestea compun de fapt sistemul data warehouse.
n aplicaia ce face obiectul acestei lucrri am folosit modelul dimensional. Cu
toate acestea, pentru a justifica alegerea, n continuare vom prezenta caracteristicile de
modelare ale fiecarei din cele doua idei.

4.1 Modelarea relaional. Baze de date normalizate

Necesitatea normalizrii datelor.
Anomalii i forme normale n bazele de date
n teoria bazelor de date, formele normale sunt un criteriu ce determin gradul de
vulnerabilitate al unei structuri de baze de date la inconsistene i anomalii. Formele
normale se aplic individual fiecarei tabele.
Anomaliile de inserare, modificare i tergere sunt situaii care ar putea duce la
pierderea integritii. Anomaliile au fost identificate i formalizate de E.F. Codd,
mpreun cu primele trei forme normale care au rolul de a a evita circumstanele n care
au loc anomalii.
Anomalia de modificare
Este un fenomen ce poate s apar la reprezentarea aceleiai informaii pe mai
multe rnduri. Un update pe o astfel de tabel poate duce la inconsistene logice. Spre
exemplu o tabel n care avem cmpurile regiune, jude i localitate pe care dorim s o
modificm n sensul schimbrii apartenenei unui jude la o regiune necesit modificarea

mai multor rnduri. Dac operaiunea de modificare nu este realizat cu succes, adic
modificarea este fcut asupra unor rnduri dar nu asupra tuturor, atunci datele din tabel
devin inconsistente i practic inutilizabile.

nainte de update
id

Regiune Judet

Localitate

Dobroge
a

Tulcea

Localitate 1

Dobroge
a

Tulcea

Localitate 2

Dobroge
a

Tulcea

Localitate 3

Moldova

Galati

Localitate 4

Moldova

Galati

Localitate 5

Moldova

Galati

Localitate 6

Presupunem c judeul Galai trece n regiunea Dobrogea, ns modificarea nu se

nchie cu succes.
id

Regiune Judet

Localitate

Dobroge
a

Tulcea

Localitate 1

Dobroge
a

Tulcea

Localitate 2

Dobroge
a

Tulcea

Localitate 3

Dobroge Galati
a

Localitate 4

Dobroge Galati
a

Localitate 5

Moldova Galati

Localitate 6

Anomalia de inserare
Pot exista cazuri n care anumite fapte nu pot fi urmrite deoarece nu exist
informaia necesar la un moment dat. Dei o parte din date sunt disponibile, informaia
complet nu poate fi inserat n baz.
Anomalia de tergere
n anumite circumstane, stergerea unor date poate atrage dup sine stergerea altor
date din arii complet diferite, a caror stergere nu o dorim.
Prima form normal (1NF)
O tabel este n prima form norml daca tabela reprezint cu fidelitate o relaie
si nu conine grupuri repetitive. Aceast definiie se presupune urmtoarele:

rndurile nu sunt supuse niciunei relaii de ordonare;

coloanele nu sunt ordonate;

nu exst rnduri duplicate;

intersecia unui rnd cu o coloan conine exact o singur valoare din

domeniul dat

nu exist coloane ascunse (rowid, timestamp-uri ascunse)

Faptul c tabela nu conine grupuri repetitive face inadmisibile pentru prima
form normal structuri de tipul urmtor:

Grupuri repetitive ntro coloan

Custom Nume
er Id

Numar de telefon

Paul

0215479445, 0257995845

George

0215495845

Grupuri repetitive de-a lungul coloanelor

Custome Nume
r Id

Numar de telefon
1

Numar de telefon
2

Paul

0257995845

0215479445

George

0215495845

Numar de telefon
3

Definiia primei forme normale n varianta original a lui E.F Codd pentru a face
referire la atomicitate. Valorile domeniului pe care fiecare relaie este definit trebuie s
fie atomice, adic s nu poat fi imprite de SGBD n pri mai mici.
A doua form normal (2NF)
O tabel avnd forma normal 1, este n form normal 2 dac i numai dac nu
include dependene partiale; adic niciun atribut nu este dependent doar de o poriune din
cheia primar. De remarcat faptul c o tabel n prima form normal ce nu are nicio
cheie candidat compozit este automat i n a doua form normal.
A doua form normal face inadmisibil structura urmtoare, structur n care
cheia primar este combinatia id oferta id plan tarifar; planul tarifar determin
discountul iar oferta pretul.
id id plan nume oferta
ofe tarifar
rta

nume plan
tarifar

discount

pret

Abonament cu minute incluse youth

20

100

Abonament cu minute incluse weekend

15

100

Abonament cu minute incluse seara

10

100

A treia form normal (3NF)

O tabel avand forma normal 2, este m form normal 3 daca i numai daca nu
conine dependete tranzitive. Cu alte cuvinte orice atribut depinde numai de cheia
primar.
A treia form normal face inadmisibil structura urmtoare, structur n care
judeul determin regiunea iar localitatea determin judeul.
id

Regiune

Judet

Localitate

Dobrogea

Tulcea

Localitate 1

Moldova

Galati

Localitate 6

Forma normal Boyce-Codd (BCNF) este apropiat de forma normal 3 dar

este mai restrictiv dect aceasta. O tabel se afl forma normal BCNF dac fiecare

determinant din tabela este o cheie candidat ( un determinant este orice atribut a crei
valoare determina alte valori din tupla). Cazurile n care o tabel n a treia form normal
nu sunt i n forma normal Boyce-Codd sunt foarte rare.

A patra form normal (4NF)

O tabela n form normal trei, se afl n a patra form normal dac i numai
dac nu are seturi multiple de dependene ale atributelor de tip multivaloare
A cincea form normal (5NF), cunoscut i sub numele de Forma Normal
Project-Join (PJ/NF) are rolul de a minimiza redundana datelor n cadrul bazelor de date
relaionale. Aceasta minimizare se produce prin nregistrarea faptelor multi valoare i
izolarea relaiilor multiple asociate semantic. O tabela este n form normal cinci dac i
numai dac fiecare asociere este implicat de cheia primar sau o cheie candidat.
Forma normal Domeniu Cheie (DKNF)
Acceast nou form normal este propus de Ronald Fagin cercettor al
laboratoarelor IBM [5] presupune ca o tabel s nu fie supus altor constrngeri dect
constrngeri de cheie. O tabel este n forma normala DKNF dac i numai dac nu are
anomalii de inserare i de stergere. Spre deosebire de formele normale precedente,
definite n termeni tradiionali de dependene funcionale, multivaloare, aceast form
norml este definit de conceptele mult mai simple de domeniu i cheie, mpreun cu
conceptul general de constrngere. Dac o tabel este n forma normal DKNF, atunci ea
aparine i precedentelor forme normale.
O definiie intuitiv a acestei forme normale spune c o tabel este n form
normal DKNF dac orice constrngere poate fi definit prin simpla cunoatere a
mulimii numelor atributelor i a domeniilor pe care acestea sunt bazate.
Aceast nou teorie redefinete anomaliile de inserare i de tergere (anomalii
definite anterior de Codd). n noua accepiune o anomalie de inserare presupune ca
inserarea aparent legal a unei singure tuple s cauzeze nclcarea unei constrngeri a
tabelei. n mod asemntor, o anomalie de tergere nseamn stergerea unei singure tuple
dintro serie valid ce duce la nclcarea unei constrngeri.
A asea form nomal (6NF) extinde teoria normalizrii bazelor de date pentru a
lua n considerare i dimensiunea temporal.

Modelul fulg de zpad

Modelul fulg de zpad pornete de la un model stea, n care ns, dimensiunile
sunt normalizare. Procesul de normalizare a dimensiunilor este cunoscut sub numele de
snowflake-ing, deoarece produce n model o serie de micro stele n jurul unei dimensiuni.
Modelul fulg de zpad este rezultatul descompunerii unei dimensiuni sau a mai
multor dimensiuni care au ierarhii. Relaiile de tip (M:1) ntre membrii unei dimensiuni
se descompun n tabele separate formnd o ierarhie de tabele.
Diferena eseniala fa de schema stea este c dimensiunile sunt normalizate.

Principala motivaie a normalizrii este spaiul de stocare i evitarea anomaliilor de

inserare. Dac ierarhiile se pstreaz n tabele separate, se consider c spaiul de stocare
se reduce consistent. Totui eforturile de a normaliza tabelele din bazele de date
dimensionale, n scopul de a reduce spatiul de stocare, sunt greoaie i consumatoare de
timp. Normalizarea dimensiunilor reduce cu mai putin de 1% spaiul total de stocare iar
vizualizarea datelor este mai dificil, implicnd un numar mai mare de jonciuni ntre
tabele. Normalizarea se dovedete cu att mai inutil n contextul n care dimesiunile nu
sunt structuri de date care s se modifice frecvent.

Fig 10: Modelul Snowflake

4.2

Modelarea dimensional. Baze de date demormalizate

Necesitatea modelrii dimensionale

Motivele pentru care modelarea dimensional a datelor este de preferat modelrii

relaionale, n cazul sistemelor data warehouse provin din nsi natura operaiunilor
proceselor de afaceri i a modului n care utilizatorii percep procesele de afaceri.
O serie dintre aceste motive pot fi:

Analiza proceselor de afaceri se realizeaz n termeni dimensionali. Spre

exemplu analitii pot formula o cerin prin care doresc s afle ce venit a generat noul
produs de la lun la lun n regiunea de sud, dup caracteristicile demografice ale
utilizatorilor. Aceast formulare se traduce n analiza unei variabile a venuturilor
dup dimensiuni geografice i demografice.

Aplicaiile de raportare necesit o modelare dimensional i au numeroase

beneficii dac un astfel de model este folosit.

Utilizatorii gndesc dimensional

Datele sunt ncrcate dintro baz n care aceeai tabel dimensiune poate fi
folosit n diferite contexte.

Accesul la date se realizeaza mai rapid. Timpul de procesare a

interogrilor scade deoarece modelul dimensional reduce numarul de legturi ntre
tabele.

Componentele modelului multidimensional

Tabela Fact (colecie de fapte)
Tabela fact ocup locul central ntro schem stea i corespunde unei colecii de
fapte din modelul dimensional. Termenul fact desemneaz de fapt o variabil a procesului
de afaceri. S considerm exemplul unei tabele fact pentru vnzarea unui serviciu. Vom
urmri fiecare vnzare din fiecare magazin n fiecare zi. Acesetea se traduc prin
msuratori la intersecia tuturor dimensiunilor (zi, produs, magazin). Lista de dimensiuni
n funcie de care se face msuratoarea defiente granularitatea. O unitate a granularitii
este atomic i aparea n tabela fact ca un singur rnd.
Caracteristicile tabelei fact:
- Conine un numr foarte mare de rnduri (posibil milioane). Numrul
maxim de rnduri din tabel reprezint de fapt produsul cartezian al dimensiunilor. De
exemplu se dorete analiza activitii de desfacere a unei firme de comunicaii mobile,
care are un lan de 500 de reprezentante n ntreaga ar si care contracteaz 100 de
conectri n fiecare magazin. Baza de date dimensional va stoca informaiile referitoare
la tranzaciile zilnice, pe o perioad de doi ani. Tabela de fapte va conine
500*100*2*365 de rnduri.
- Dimensiunea tabelei fact este n continu cretere, n funcie de cantitatea
de date ncarcate la fiecare ciclu de ncrcare a datelor, precum i n funcie de cantitatea
de date istorice stocate n baza de date .
- Este tabela care reflect rezultatul activitii analizate. Conine toi
indicatorii de performan importani (n schema stea sunt de regul atribute numerice
aditive).
- Cheia primar a tabelei este o cheie compus, format din cheile primare
ale tabelelor dimensionale. ntre tabela fact i cheia compus format din cheile primare
ale dimensiunilor exista o dubl implicaie: fiecare tabel fact are o cheie compus i
fiecare cheie compusa este o tabel de fact.
- Tabela fact este o tabel normalizat ce realizeaz o legatur indirect
ntre tabelele dimensiune.

Dimensiunile
Dimensiunile sunt tabele care, printro asociere cu o tabela fact furnizeaz
informaii descriptive despre fiecare mrime msurat de tabela fact. Dimensiunile conin
n general date statice: datele nu se schimb, sau care se schimb rar. Spre exemplu o
dimensiune geografic va conine cte un rnd pentru fiecare localitate cu atribute
precum judet, regiune de interes i ar. Desigur, nu ne ateptm ca judeul din care o
localitate face parte s se modifice. Cu toate acestea organizaia i poate redefini periodic
gruparea judeelor pe regiuni.
Modelul dimensional trebuie s permit modificarea dimensiunilor. Gestionarea
modificrilor se poate implementa cu pstrarea istoricului sau cu rescrierea complet a
datelor. Pstrarea istoricului dimensiunilor se poate realiza prin introducerea unui cmp
de versionare. Dac o modificare apare, rndurile afectate sunt marcate cu 0 n cmpul de
versionare i noi rnduri sunt introduse, avnd versiunea 1 pentru a realiza modificarea.
O alt metod de pstrare a istoricului dimensiunilor este de a aduga dou
atribute suplimentare fiecrei nregistrri: valabil_de_la, valabil_pn_la care s
marcheze data de la care nregistrarea nu mai este valabil i data de la care noua
nregistrare este valabil.
ntr-un hipercub, o dimensiune este reprezentat printro ax. De obicei
dimensiunile conin un numr mare de atribute ce cresc felxibilitatea schemei i permit
un mod variat de analiz. De exemplu dimensiunea Oferta poate s conin urmtoarele
atribute dimensionale: tipul ofertei, numrul de minute incluse, numrul de SMS-uri,
valoarea n euro, valoarea n dolari, descrierea ofertei etc.
ntro schem stea sunt tabelele care se dispun radial n jurul tabelei de fapte i se
mai numesc tabele dimensionale. Aceste tabele sunt denormalizate iar cheia lor primara
este o cheie surogat sau o combinaie de atribute.
Conceptul de dimensiune este fundamental pentru modelarea multidimensional.
Cei mai multi proiectani utilizeaz fraza dimensiuni comune afacerilor. De exemplu,
un model multidimensional trebuie s includ timpul ca dimensiune fundamental. Cele
mai multe instrumente de analiz multidimensional implementeaz facilitatea de a
permite conversii de calendar i operaii de agregare ( zi > saptamn > lun > an )
automate i chiar manipularea cu usurin a seriilor de timp ( perioade promoionale,
sezoane, perioade fiscale etc.) Alte dimensiuni des ntlnite n domenii variate de afaceri
sunt: locaia, organizaia (ierarhia organizaional), clientul.
O dimensiune conine mai muli membri. Un membru este un nume distinct sau
un identificator folosit pentru a determina pozitia unui element de data (n schema stea
apare sub denumirea de atribut dimensional). De exemplu, toate lunile, trimestrele i anii
formeaz dimensiunea Timp i toate oraele, regiunile i rile dimensiunea Locaie.

Ierarhiile

Ierarhiile sunt structuri n interiorul crora exista o legatur de subordonare ntre

dimensiuni apartinnd aceleiai axe dimensionale. Putem vobi de ierarhii de timp, ierarhii
de canale de distribuie, etc.
Membrii unei dimensiuni se pot organiza n una sau mai multe ierarhii. Fiecare
ierarhie poate avea mai multe nivele ierarhice. Un membru poate apartine la una sau mai
multe ierarhii sau poate s nu fie inclus ntro ierarhie (independent). De exemplu n
dimensiunea Ofert membrul descriere promotional nu este inclus n nici o ierarhie.
S considerm spre exemplu dimensiunea Timp n care putem avea o ierarhie n
funcie de structura anului calendaristic i o ierarhie n funcie de structura anului fiscal.
Mai mult, deoarece o sptmn nu aparine cu certitunie unei singure luni putem
implementa i o a treia ierarhie n care sptmna se subordoneaz trimestrului sau direct
anului. Pentru a identifica poziia unui membru ntro dimensiune se folosesc conceptele
de nalime i adncime n ierarhie. nalimea se stabilete de jos n sus. Din acest motiv
nivelul (N0) al ierarhiei reprezint nodurile frunz ale ierarhiei (naltimea cea mai mic).
n schema stea, nivelul N0 se leag la tabela fact.

Adncimea n ierarhie este stabilit de sus n jos. Exista posibilitatea ca doi

membri care au aceeai naltime s aiba adncimi diferite i invers. Acestea sunt structuri
arborescente neechilibrate. Structurile arborescente neechilibrate sunt implementate cu
succes n bazele de date dimensionale spre deosebire de bazele de date relationale care nu
ofer structurile necesare pentru implementare.

Fig 11: Ierarhie de timp la nivel de lun

Fig 12: Ierarhie de timp la nivel de sptmn

Mrimile
Mrimile sunt atribute numerice al unui element din fact, un indicator de
performan prin care se poate analiza activitatea modelat. Valorile unui indicator se
modific continuu. Pentru fiecare combinaie posibil ntre dimensiuni, exist o valoare
corespunztoare a mrimii.
Nu orice atribut numeric este un indicator. De exemplu, costul pltit de client
pentru o ofert este un atribut numeric (valoarea ofertei) i totui nu este un indicator ci
un atribut al ofertei, deci o dimensiune. Dac valoarea atributului numeric variaz
continuu (costul de livrare, cantitatea vndut, volumul vnzarilor) atunci atributul este
un indicator, iar dac atributul este perceput mai mult ca o constant sau o nsuire a unei
alte dimensiuni atunci este un atribut dimensional.
Indicatorii pot fi indicatori de baza (volumul vnzarilor, cantitatea vndut,
costurile, numrul de clienti) sau indicatori derivai care se obin prin combinarea
indicatorilor de baz (profitul). n funcie de funcia de agregare folosit pentru calculul
mrimilor, acestea se clasific astfel:
Mrimi distributive, calculate cu funcii distributive de agregare, precum
count(), sum(), min(). Calculul mrimii pentru un subseturi ale datelor poate fi
nsumat i va returna acelai rezultat ca i n cazul calculului pentru ntregul set de
date. Aceste mrimi poart i numele de mrimi aditive, deoarece totalul se obine
prin nsumare. O mrime aditiv se poate nsuma dup toate dimensiunile. De
exemplu indicatorul volumul vnzrilor se poate calcula pentru o categorie de
oferte sau pentru o anumit regiune sau pentru a anumit perioad de timp.
Volumul vnzrilor, cantitatea vndut i costurile sunt aditive. Aceasta nseamn
c are sens de a aduna euro sau cantiti de-a lungul oricrei combinaii timp,
produs, magazin.
Mrimi algebrice, calculate folosind funcii algebrice de agregare. O funcie de
agregare este algebric dac poate fi calculat ca o funcie algebric de funcii
distributive. Un astfel de exemplu este funcia medie avg() care poate fi calculat
ca sum()/count(). Alte funcii algebrice sunt procentaj: percentage(), deviaia
standard.
Mrimi holistice, calculate folosind funcii holistice de agregare. Exemple de
astfel de funcii sunt mediana: median(), moda: mode(), numrul distinct: count
(distinct() ). Aceste funcii au n comun faptul c depind n mod intrinsec de setul
de date pe care sunt calculate

Schema stea
Este o reprezentare intuitiv a cubului multidimensional de date, ntrun mediu
relaional. Schema stea conine o tabel central i un set de tabele dimensionale aranjate
ntro manier radial n jurul tabelei centrale. Fiecare tabel dimensional reprezint o
dimensiune a activitii analizate, n timp ce tabela central conine elementele cubului de
date.

Schema este asimetric. Exist o tabela dominant n centrul schemei, singura

tabela din schema cu multiple legturi prin care se conecteaz la celelalte tabele. Aceast
tabel se numete tabela fact. Celelalte tabele au numai o singur jonciune prin care se
leag la tabela central i se numesc tabele dimensionale sau dimensiuni. Schema stea
reduce numrul de legturi ntre tabele i astfel simplific planul de execuie al
interogrilor. Acestea sunt jonciuni de egalitate. Totui, denormalizarea determin
duplicarea datelor i o nevoie mai mare de capacitate de stocare. Compromisul capacitate
de stocare contra putere de procesare dinamic este unul acceptabil n condiiile n care
memoria este o resurs mult mai ieftin dect capacitatea de procesare.

Fig 13: Modelul Stea

O colecie de modele stea ce au dimensiuni n comun alctuiesc modelul stea

Fig
14: Modelul Stea extins
extins

Concluzii
Dac am realiza o comparaie ntre modelul relaional i modelul dimensional,
Relaia care se evidentiaz ntre cele doua este ca modelul relaional corespunde unui set
de modele dimensionale i o singur diagram entitate-relaie (la nivel de organizatie)
corespunde unei mulimi de diagrame dimensionale. Modelul rezultat pentru o
corporaie, va consta din aproximativ 10-25 de scheme stea. Fiecare schem stea are de
obicei 4-12 tabele de dimensiuni.
Modelul dimensional prezint o serie de avantaje fa de modelul relaional:

schema stea se preteaz modificrilor neateptate ale cerinelor

utilizatorilor. Toate dimensiunile pot fi gndite ca puncte de intrare egal simetrice n
tabela de fapte. Proiectarea logic este independent de tipurile de interogri.
Strategiile de interogare sunt simetrice i codul SQL-ul generat pentru modelul
multidimensional este simetric

schema stea reduce numrul de legturi i permite o administrare uoar;

modelul dimensional este extensibil. Se pot aduga noi tabele fact, noi
dimensiuni, noi atribute n cadrul unei dimensiuni. Acest extindere se poate realiza
fr a afecta aplicaia.

4.3

Granularitatea

Acest aspect al designului influenteaz ntreaga arhitectur a data warehouse-ului.

Granularitatea se refer la nivelul de detaliu sau de sumarizare a unitiolor
informaionale. Cu ct se dorete un nivel de detaliu mai mare, cu att granularitatea
scade. Cu ct nivelul de detaliu este mai redus, cu att granularitatea este mai mare.
Spre exemplu efectuarea unui apel poate reprezenta cea mai mica unitate de
informaie i are cea mai mic granularitate. Numrul sumarizat al apelurilor pentru o
ntreag lun este un exemplu de mai mare granularitate.
Granularitatea are un impact direct asupra volumului de date ce trebuie stocat in
warehouse i deci i a timpului de rspuns la interogri. . Odata cu creterea comprimrii
datelor are loc scderea granularitii, ceea ce se reflect asupra necesarului de spaiu de
stocare (mai puin spaiu de stocare necesat), a vitezei de prelucrare obinute (vitez de
procesare mai mare) precum i asupra flexibilitii Data Warehouse (felxibilitate mai
redus).
Alegerea nivelului de granularitate se va face innd cont de nivelul de detaliu de
care este nevoie pentru a susine procesul decizional. De cele mai multe ori designerul va
trebui s realizeze un compromis ntre cele doua: granularitate mare, detaliere slab, timp
bun de rspuns sau granulariate mic, detaliere puternic, timp de rspuns mai mare. n
afar de timpul de rspuns trebuiesc luate n calcul si necesitile de stocare i processare

a unui volum mare de date. Se va opta pentru un nivel foarte detaliat numai dac acesta
va aduce informaiile necesare.
S consideram urmtorul exemplu: dorim s nregistrm toate operaiunile de
balan realizare de clienii prepaid (realizarea de rencrcri, primirea de bonusuri, plata
de taxe). Dac am nregistra aceste date o agregare zilnic la nivel de client, am avea
nevoie de o nregistrarare pe zi pentru fiecare client. La un numar de 1000 de clieni am
avea
pe
an
un
maxim
de
aproximativ
1000 * 30 * 12 = 360 000. nregistrri care ar ocupa n medie un spatiu de stocare de
aproximativ 72 000 000 bytes. Dac lum n calcul faptul c n Romnia principalii
operatori de telefonie mobil au un numr de clieni de ordinul milioanelor nevoia de
capacitate de stocare crete exponenial.
Pe de alt parte, dac am agrega datele lunar la nivel de client, pentru un eantion
de 1000 de clieni am avea pe an un numr de maxim 1000 * 12 = 12 000 de nregistrri
pentru fiecare tip de micare. Ce se traduce ntrun spaiu de stocare de aproximativ 2 400
000 bytes. Mai mult dac scopul analizei nu este de a analiza comportamentul clientilor
putem folosi numai o agregare lunar ce va rezulta n 12 nregistrri pe an pentru fiecare
tranzacie sau o agregare zilnic ce va rezulta n aproximativ 365 de nregistrri pe an
pentru fiecare tranzacie.

4.4

Partiionarea

Partiionarea unui data warehouse nu este n niciun caz o consideraie opional.

Problema n discuie este cum se va realiza partiionarea i nu dac se va partiiona.
Volumul foarte mare de date din tabelele fact sau din tabelele de istoric sunt adevrate
provocri pentru administratori i designeri.
Problemele care pot aprea datorit volumului mare de date, si care pot fi
prentampinate prin partiionare. sunt:

performana sczut a interogrilor

inserarea de volume mari de date

stergerea unor volume mari de date, atunci cnd dorim tergerea datelor
prea vechi
Pe lng

prentampinarea unor probleme, partiionarea aduce i o serie de

benficii:
mbuntire a performantei: timpul de rulare al interogarilor scade de la
zeci de minute la secunde

Timpul de disponibilitate al bazei de date crete consiberabil: accesul la

date se poate realiza 24 de ore pe zi, 7 zile pe sptamn.

Faciliteaz managementul bazei de date deoarece este mult mai uor s

adminstrezi uniti de date dect un volum nestructurat de date, de dimensiuni foarte
mari.

Managementul ciclului de via al informaiei prin utilizare eficient din

punct de vedere al costului a unitilor de stocare.

Partiionarea se refer la mprirea datelor n uniti fizice separate care s poata

fi tratate independent. Ea este o funcionalitate a sistemului de gestiune a bazei de date. O
bun partiionare a datelor poate aduce imbuntiri majore pentru timpul de acces,
timpul de ncrcare, timpul de arhivare, stocarea i monitorizarea datelor.
Una din functionalitile cheie ale data warehouse-ului este de a oferi acces
flexibil la date. Volumul mare de date face ca aceasta functionalitate de baza sa para greu
de realizat. Din acest motiv toate datele curente din data warehouse vor fi partitionate.
Datele sunt partitionate atunci cand date cu aceeasi structura sunt impartite in untati de
stocare fizica diferite. Mai mult orice unitate de date apartine numai unei singure partitii.
Datele pot fi impartite dupa criterii variate, cum ar fi:

dup data

dup linia de produse

dup mparirea geografic

dup unitatea organizational

dup toate criteriile de mai sus simultan

Putem identifica trei tipuri majore de partiionare:

Partiionarea Range. Poate fi folosit atunci cnd datele pot fi mprite din punct
de vedere logic. Un exemplu de range partitioning este partitionarea dup dat.
Partiionarea Hash. Folosit pentru a mpri datele n mod egal pe toate partiiile.
Se va folosi hash partitionig atunci cnd nu exist nicio grupare logic a datelor.
Partiionarea Lista. Folosit pentru a grupa n aceeai partiie date care nu au o
legtur logic direct. Spre exemplu informaiile referitoare la mai multe judee pot fi
puse mpreun ntro partiie de tip list care s conin informaiile pentru ntreaga
regiune.
Combinaii ale acestora pot genera noi tipuri de partiionare. Cu toate acestea din
punct de vedere fizic partiia va aparine uneia din cele trei tipuri majore.
Partiionare compozit Range-Hash. Realizeaz nti un range partitioning
dup care partiioneaz hash. Prima operaie este de a mpri datele din punct de vedere
logic, iar apoi de a mpri datele n mod egal n partiii hash. Un exemplu este
partiionare dup data naterii urmat de o partiionare hash dup nume. Datele sunt
stocate n partiii hash.
Partiionare compozit Range-List Folosete nti partiii range dup care
mparte datele n partiii lista. Un exeplu de folosire poate fi mprirea informaiilor dup
data naterii urmat de stocarea lor n partiii lista dup regiune.
Fiind o funcionalitate a SGBD, felul n care partiionarea este implementat
difer de la un productor la altul. Spre exemplu DB2 folosete clauzele PARTITION BY
RANGE, DISTRIBUTE BY HASH si ORGANIZE BY DIMENSION pe cnd Oracle
folosete clauzele PARTITION BY RANGE, PARTITION BY HASH, PARTITION BY
LIST. Pentru ambele sisteme clauzele de partiionare se folosesc n instruciunea de
definire a tabelei (CREATE TABLE)
Pe lng cele trei tipuri de partiionare a tabelelor, se mai poate realiza i o
partiionare la nivel de baz de date. Acest facilitate este deasemnea una a SGBD. Spre
exemplu IBM DB2 Warehouse Edition implementeaz acest tip de partiionare astfel
nct baza de date se poate intinde pe multiple partiii ce se pot afla pe maini diferite.
Tehnologia poart numele de DPF (Database Partitioning Feature) si este bazata pe
conceptul arhitectural shared-nothing arhitecture (nimic n comun). Pe msur ce un
computer este adugat n grupul de partiionare el aduce grupului att putere de procesare
(CPU) ct i memorie. Aceast funcionalitate este cu att mai important n sistemele de
tip data warehose n care ruleaz interogri de suport decizional.
Exemplu de partiionare:
Hash

ALTER TABLE DW.AGG_PRP_REVENUE_S_MONTHLY

DISTRIBUTE BY HASH(BALANCE_MOVEMENT_TYPE)
INTO 4 PARTITIONS

Range

ALTER TABLE DW.AGG_PRP_REVENUE_S_MONTHLY

PARTITION BY RANGE(AGG_DATE)
(
STARTING '1/1/2009'
ENDING '12/31/2009'
EVERY 1 MONTHS
)

4.5

Indexarea

Principalul scop al unui index este de a ajuta sistemul de gestiune a bazei de date
s localizeze mai usor rndurile stocate n tabele. Daca indexarea este facut pe coloane
utilizate frecvent, performana operaiilor de acces la date este exponenial mbuntit.
Mai mult, indecii permit o mai bun concuren a tranzaciilor ce au nevoie s acceseze
acelai tabele n acelai timp.
Cu toate acestea, beneficiile indecilor vin cu preul unei uoare scderi a
performanei pentru operaiile de insert i de update pentru ca fiecare operaie trebuie
fcut att asupra tabelei ct i asupra indexului asociat. Considerm acest compromis
benefic pentru un data warehouse, unde, operaiile de acces la date sunt mult mai
frecvente dect cele de insert sau update.
Tipuri de indecsi
Indecsi bitmap. Folosesc pentru stocare cmpuri de bii denumite bitmap.
Pentru a rspunde interogrilor realizeaz operaii logice pe cmpurile de bii. Sunt
potrivii pentru cmpuri care au un numr mic de valori distincte. Indecii bitmap au
performane ridicate dac sunt aplicai tabelelor pe care nu sunt frecvente operaiile de
update.
Spaiul ocupat n memorie de indecii bitmap este proporional cu cardinalitatea
coloanei pe care sunt creai. Dac domeniul are n valori, deci cardinalitate n, atunci
indexul va avea neoie de n bii pentru fiecare intrare n indexul bitmap. n data
warehouse sunt potrivii pentru a lega tabela fact de tabele dimensiune, adic pentru a
lega o tabel de mari dimensiuni de una cu dimensiuni reduse.
Indeci de asociere (join indexes). Spre deosebire de indecii tradiionali ce
asociaz o valoare dintr-o coloan dat unei liste de rnduri ce au acea valoare, indecii
join nregistreaz rndurile ce pot fi asociate din doua relaii din baza de date.
nregistrrile indecilor join identific tuplele care pot fi asociate. Operaiile de asociere
sunt mai costisitoare dect identificarea prin indeci join. Indecii join menin legtura
dintre atributele unei dimensiuni i rndul corespunztor n tabela fact.

4.6

Capcane n modelarea datelor

n modelarea datelor pot aprea situaii speciale, cunoscute sub numele de

capcane. Acestea nu indic neaprat o problem, dar sunt situaii care necesit o atenie
special.
Sunt cunoscute patru astfel de capcane:

1. Capcana prpastiei ntre date (eng. Chasm Trap) se refer la relaiile M:M;
2. Capcana relaiilor tranzitive apare atunci cnd exist mai mult de o cale
ntre dou tabele;
3. Capcana conexiunilor apare atunci cnd exist o cale opional ntre
entiti diferite;
4. Capcana ventilatorului (eng. Fan Trap) apare la existena mai multor
relaii 1:M ce provin din aceeai tabel.

Chasm Trap
Cazul trivial al acestei capcane este o relaie de tipul M:M ntre dou tabele.
Aceast relaie se traduce prin mai multor rnduri dintro tabel le corespund mai multe
rnduri din alt tabel. Dei nu este o relaie incorect atunci cnd elaborm modelul cu
o vedere de ansamblu, vom descoperi c aceast structur nu poate nregistra i menine
datele. Informaia cade ntr-o prpastie ntre cele dou tabele de date.

Fig 15: Capcana Chasm cazul I

Exemplul de mai sus ilustreaz un caz de chasm trap n care un furnizor poate
furniza mai multe pri, dar n acelai timp aceeai parte poate veni de la diferii furnizori.
Dac potenial fiecare furnizor poate furniza fiecare parte, apare problema: cum raportez
furnizorii care au adus anumite pri? n mod tipic aceast problem este rezolvat cu o
tabel cu rolul unui pod, ce face trecerea de la o entitate la alta nregistrnd detaliile
relaiei.
Cazul capcanei chasm cel mai adesea ntlnit apare atunci cand dorim inteorgarea
a trei tabele ntre care avem dou asocieri 1:M ce pornesc de la o singur tabel ctre alte
dou tabele. Implicaia acestor relaii se traduce prin absena unei relaii ntre cele dou
tabele implicate n relaiile 1:M. Aceasta capcan este cunoscut i sub numele de
capcana relaiilor paralele.
n figura urmtoare avem ilustrat un exemplu:

Fig 16: Capcana Chasm cazul II

n acest exemplu am presupus ca avem dou tabele de tip fact, una n care avem
informaii despre minute la nivel de ofert i de client i una n care avem informaii
despre veniturile aduse de clieni la nivel de ofert. Fiecare din cele dou tabele fact este
n relaie de 1:M cu tabela dimensiune n care avem informaii despre oferte. De observat
c ntre cele dou tabele fact nu exist o legatur direct.
Aceasta arhitectura nu ridica probleme dac sunt interogate separat cele dou
tabele fact. Problema apare la interogarea simultan a celor trei tabele.
S presupunem ca n tabele avem urmatoarele date:

Tabela offer_dim

Tabela minutes_fct

Tabela revenue_fct

Select A.nume_oferta, sum(B.total_min)

From offer_dim A, minutes_fct B
Where A.offer_id=B.offer_id
Group by A.nume_oferta;

Rezultatul ntors este corect.

Select A.nume_oferta, sum(C.total_eur)

From offer_dim A, revenue_fct C
Where A.offer_id=C.offer_id
Group by A.nume_oferta;

Rezultatul ntors este corect.

Dac utilizatorul dorete un raport n care s prezinte att totalul minutelor ct i

totalul banilor ncasai, s-ar atepta ca rezultatul ntors s fie: oferta z | 500 | 54 , n
schimb rezultatul ntors de SGBD este oferta z | 1500 | 54 care nu este un rezultat corect.
Select A.nume_oferta, sum(C.total_eur), sum(B.total_min)
From offer_dim A,minutes_fct B, revenue_fct C
Where A.offer_id=B.offer_id and A.offer_id=C.offer_id
Group by A.nume_oferta;

Acest comportament se datoreaz faptului c ntre cele dou tabele fact

(minutes_fct i revenue_fct) nu exista o legtur direct i exista diferen de granularitate
(minutes_fct este la nivel de detaliu mai mare decat reveneue_fct) i fiecare rnd din
revenue_fct s-a multiplicat pentru fiecare rnd din minutes_fct avnd loc un produs
cartezian.

Pentru a rezolva aceast problem putem folosi un proces ETL (extract transform
and load) care s multiplice fiecare rnd din tabela revenue_fct pentru fiecare rnd din
minutes_fct, dar care s nlocuiasc valoarea proprizis cu o medie astfel:
oferta z | 166,66 | 20 | 1
oferta z | 166,66 | 22 | 2
oferta z | 166,67 | 12 | 3
Aceast metod nu aduce un plus de informaie i nu va contribui la procesul
decizional cu informaii noi, ns evit afiarea unor date incorecte.
O alt metod de evitare a acestei capcane, fr a modifica datele din tabele, este
de a realiza dou inteorgri separare i de a rezolva problema din modul de afiare al
sistemului de suport decizional.
Capcana relaiilor tranzitive
Capcana de tranzitivitate apare la crearea unei bucle ntre cel puin trei tabele. n
acest fel, ntre doua tabele avem mai mult de o cale prin care tabelele relaioneaz. Acest
tip de capcan ngreuneaz interogrile i este posibil ca datele ntoarse s nu fie cele
corecte deoarece nu este clar care sunt tabelele care trebuiesc incluse n query.
O modalitate de rezolvare a capcanei este de a crea un alias pentru una din tabele,
obinnd astfel o rupere a buclei n doua seturi de doua relaii.
Modalitile de rezolvare a buclelor difer ca implementare de la o aplicaie la
alta.
SAP propune n pachetul de programe de Business Objects o rezolvare prin crearea de
contexte. n mod tipic un context este asociat unei tabele de tip fact; daca bucla include

doua tabele de acest tip, se vor crea dou contexte. n figura urmtoare se poate observa
un exemplu de rezolvare a capcanei de tranzitivitate cu ajutorul contextelor n aplicaia
Business Objects. Cele dou contexte sunt marcate n culori diferite.

Fig 17: Capcana relatiilor tranzitive

Dac n bucla este implicat o tabela de tip dimensiune cu utilizri diferite, se va
crea cte un alias pentru fiecare utilizare a tabelei dimensiune. Un exemplu de utilizare
diferita a unei tabele dimeniuni poate fi o dimensiune de timp pe care doresc s o folosesc
pentru a obine caracteristicile datei de activare a unui client i n acelai query s o
folosesc pentru a obine detalii despre data unei rencrcri.
IBM, prin aplicaia sa Cognos 8 Business Intelligence, propune rezolvarea acestei
capcane cu realizare de scurtturi ale tabelelor care sunt implicate n relaia tranzitiv.
Acestea funcioneaz ca aliai la aceeai tabel.
Capcana conexiunilor
Capcana conexiunilor apare n situaia n care ntre dou tabele care au deja o
asociere ntre ele, mai exista nca o legatur. De cele mai multe ori acest legtur este
optional sau nu este evident.
S presupunem c n tabela dimensiune a canalelor de distribuie avem informaii
datate, Accesul la aceste informaii se face n mod normal n momentul raportrii datelor
din tabela fact cu detalii de timp i detalii despre canalele de distribuie. Dac am dori
ns s vizualizm o list numai cu informaiile despre canalele de distribuie i datele de
la care acestea sunt active sau datele la care au devenit inactive, interogarea tabelei fact ar
fi redundant. Astfel, ntre dimensiunea de distribuie i dimensiunea de timp va exista o
scurtatur print+in join direct.
Desigur, scopul unui sistem de suport decizional nu este acela de a returna liste, ci
de a returna rapoarte analitice din care s se poat extrage uor informaia. n acest
context legatura direct dintre cele dou dimensiuni nu este evident.

Fig 18: Capcana conexiunilor

Fan Trap
Fan Trap apare atunci cnd o tabel se leag printro relaie 1:M de a alt tabel
care la rndul ei este legat de o alt tabel tot printro relaie 1:M. Rezultatul unei
interogri pe o astfel de structur va ntoarce rezultate incorecte dac toate cele trei tabele
sunt incluse n interogare.
Pentru a explica fenomenul ce are loc ntr-o astfel de capcan vom analiza
umtorul exemplu:

Fig 19: Capcana Fan

S presupunem ca n tabele avem urmatorele date:
Tabela customer

Tabela opt_facturate

Tabela opt_line

Totalul banilor facturai pentru clientul Paul este returnat de interogarea:

select A.cust_name, sum(B.pret_optiune) Total_facturat
from customer A, opt_facturate B
where A.cust_id=B.cust_id
group by A.cust_name;

Dac dorim n schimb s aflm totalul facturat dup tipul serviciului oferit,
interogarea va multiplica datele din tabela de facturare pentru fiecare rnd din tabela cu
detalii despre opiunile facturate.
select A.cust_name, sum(B.pret_optiune) Total_facturat,
sum(C.valoare) Total_servicii
from customer A, opt_facturate B, opt_line C
where A.cust_id=B.cust_id and B.id_fact=C.id_fact
group by A.cust_name, C.tip;

C.tip,

Problema poate fi rezolvat prin crearea unui alias la tabela care produce
multiplicarea datelor. Aliasul i tabela original vor fi legate de o asociere 1:1.
Rezolvarea capcanei fan nu aduce informaie n plus. Totalul facturat nu va fi
disponibil pentru fiecare serviciu n parte deoarece strctura tabelelor nu permite
interogarea datelor pentru a afla aceast informaie. Datele din sistemele surs nu
urmresc aceast informaie. Informaia poate chiar s nu existe pentru c nu prezint
interes. Cu toate acestea rezolvarea capcanei previne afiarea de date eronate.

Modelul de date
Exista trei niveluri [3,4] la care se poate construi modelul de date:
1. nivelul conceptual (high-level): modelul entitate relaie (ERD-entity
relationship diagram)
2. nivelul intermediar (midlevel): modelul logic (DIS Data Item Set)
3. nivelul cel mai mic de detaliu (low-level): modelul fizic

Folosim acest mprire pe niveluri deoarece, din multitudinea de concepte

existente n problematica realizrii modelului de date, multe din concepte i terminologii
prezint suprapuneri care pot fi confuze. Celelalte modele de date (ierarhic, retea,
relational, orientat obiect, relational-obiectual, conceptual, intern, extern, fizic, etc.)
existente pot fi ncadrate pe unul din cele trei niveluri. mprirea pe aceste trei nivele a
fost pentru prima dat prezentat i adoptat de ANSI n 1975.
Putem vedea cele trei niveluri ca pai ce sunt parcuri n ordine de la analiz ctre
implementare. Primul pas este crearea unor cerine de nivel nalt asupra datelor, acesta
este nivelul conceptual. Urmtorul pas este modelul fizic folosit pentru a descrie schema
precis i platforma de baze de date. Ultimul este nivelul logic folosit pentru a integra
modelul conceptual i cel fizic pentru a facilita comunicarea cu alte grupuri/departamente
IT. Dei ne-am fi putut atepta ca nivelul logic s reprezinte al doilea pas, utilitatea lui i
face necesar crearea abia la sfritul dezvoltrii modelului fizic.
Un important avantaj al modelarii pe trei niveluri este faptul c ofer trei
perspective independente unul de cellalt. Tehnologia de stocare (storage) se poate
schimba fr a afecta modelul logic sau cel conceptual, structura coloanelor tabelelor se
poate schimba fr s afecteze modelul conceptual.

5.1

Nivelul Conceptual

Nivelul conceptual i are bazele n modelul entitate relaie propus de Peter Chen
n 1976. Acest model ncorporeaz informie semantic din lumea real. Sunt unificate
pentru prima dat modelele reea, relaional i entitate-mulime, analiznd ambiguitile
semantice existente n aceste modele.
Modelul retea este o extindere a nivelului ierarhic. Baza de date este privit ca un
graf orientat. A fost elaborat de Charles Bachman i publicat n 1969 de CODASYL
Conference on Data System Languages. A fost adoptat i ca standard OSI.
Modelul relaional a fost propus n 1968 de Edgar Frank Codd i este bazat pe
logica predicativ. Privete baza de date ca pe o colecie de variabile predicative peste un
domeniu finit de astfel de variabile. Variabilele predicative exprim constrngerile de la
nivelul bazei de date. O relaie este asociat fiecrei astfel de variabile.
Modelul entitate-mulime este bazat pe teoria mulimilor i privete datele ca pe

entiti ce pot sau nu s aparin unei mulimi. Apartenena este exprimat prin predicate.
Considerm cele trei modele ca fiind nvechite, deoarece noul model: modelul
entitate relaie a fost acceptat pe scar larg i a devenit un standard de dezvoltare,
beneficiind i de standarde de notaie foarte bine documentate (IDEF1X,UML).
Modelul entitate relaie este modelul cu cel mai nalt grad de abstractizare a
datelor. Aceast tehnic de modelare presupune o abordare de sus n jos (top-down):
pornete de la delimtarea scopului modelului i a informailor pe care dorim s le obinem
din baza de date, pn la abstractizarea termenillor, definirea de entiti i tratarea
modurilor i cazurilor n care aceste entiti pot relaiona. Din totalitatea de relaii
posibile ntre entiti se vor selecta numai cele care aduc un plus de valoare sau de
informaie modelului.
O entitate poate fi definit ca un obiect care are o existen independent i care
poate fi identificat n mod unic. Entitatea trebuie s aiba un coninut de sine stttor i o
existen determinat. Entitile sunt uzual identificate dup caracteristica lor de a
reprezenta un substantiv. Exemple de entiti n cazul unui operator de telefonie mobil
sunt: Client, Operator, Canal de distribuie, Oferta
O relaie descrie modul n care entitile interacioneaz unele cu altele. O relaie
poate fi considerat i ca o asociere ntre entiti. Relaiile sunt percepute n general ca
verbe ce aduc n aceeai propoziie doua sau mai multe entiti. Spre exemplu dac un
operator activeaz unul sau mai muli clieni putem spune ca ntre entitatea Client i
entitatea Operator exist relaia de activare.
Regula minimal aplicabil este Tot ceea ce este necesar se afl aici i tot ceea ce se afla
aici este necesar
Cardinalitatea unei entiti n relaie cu o alt entitate se refer la numrul de
elemente din entitatea dreapt, respectiv stng, care sunt puse n coresponden prin
relaia dat. Aftel o cardinalitate 1:M se traduce prin fiecare rnd din entitatea dreapt
are unul sau mai muli corespondeni n entitatea stang i fiecare rnd din entitatea
stang are un singur corespondent n entitatea dreapt.
Cele mai ntlnite tipuri de relaii i cardinaliti:
Nr. Diagrama conceptual
Relatia Legtur

Caracteristicile relaiei
Relatie opional 0:0. O
persoan poate ocupa un loc
de parcare, dar nu avem
nevoie de o persoan pentru a

Nr. Diagrama conceptual

Relatia Sub tip

Relaie 1:0 opional ntr-o

singur parte. Indic faptul c
o persoan poate fi inginer,
iar un inginer cu siguran
este o persoan. Este facut
asumpia c partea obligatorie
a
relaiei
este
partea
dominant. La fel ca la relaia
anterioar,
riggere
sau
programe trebuiesc folosite
pentru controlul bazei de
date.

Relatia Segment fizic

Relaie obligatorie 1:1.O

persoan poate un i numai
un ADN. Acest ADN apartine
numai
acestei
persoane.
Aceasta relaie este dificil de
implementat
deoarece
integritatea
referentiala
declarativ va fi prin n
capcana Oul sau gina.
Acest
tip
de
relaie
demonstreaz
necesitatea
denormalizrii. n mod curent
vor fi implementate ca o
singur entitate.

Relaia Posesiune

Relaie
opional
0:M.
Caracteristici:
o persoan poate avea
unul sau mai multe
telefoane;
un telefon are cel mult
un posesor.
n baza de date se
implementeaz
printro
coloan cheie strin n tabela
Telefon ce refer tabela
Persoana, cheie care poate
avea valoarea null.

2.

3.

4.

Caracteristicile relaiei

Nr. Diagrama conceptual

Relaia Copil

Relaie
obligatorie
1:M,
obligatorie n partea unitar.
Este cel mai comun tip de
relaie. O persoan poate sau
nu s fie menbru, dar poate s
fie membru de mai multe ori
(spre exemplu dac entitatea
membru exprim apartena la
mai multe cluburi). Un
membru este cu siguran o
persoan. Cheia strain n
tabela membru nu poate fi
null.

Relaia Caracteristic

Relaie 0:M obligatorie n

partea mulipl. Caracteristici:
o persoan are cel
puin un nume, dar
poate avea i mai
multe
un nume poate sau nu
s fie asociat unei
persoane,
dar
cu
siguran exist o
persoan cu acest
nume.
n baza de date vom avea o
cheie strin n tabela Nume,
ctre tabela Persoana i
triggere care vor fora ca
entitatea Persoana s aib un
nume.

Relaia Paradox

Relaie 1:M obligatorie de

ambele pri. Asemntor cu
cazul segmentului fizic, apare
paradoxul Oul sau gina
deoarece avem nevoie de o
persoan pentru a avea o
cetenie i de cetenie
pentru a defini o persoan.

1.

2.

1.

Caracteristicile relaiei

Nr. Diagrama conceptual

Caracteristicile relaiei

Relaia Asociere

Relaie
M:M
opional.
Conceptual se traduce prin: o
persoan poate sau nu s
lucreze pentru un angajator
2.
dat, dar poate lucra pentru
mai muli ali angajatori. Un
angajator poate s nu aib
angajai sau poate avea muli
angajai. Cel mai adesea se
implementeaz cu o entitate
de asociere auxiliar pentru a
mpri relaia n dou relaii
de tip 0:M. Aceasta entitate
auxiliar ar putea purta
numele Angajat
deoarece
leag persoana de angajatorul
pentru care aceasta lucrez.
Modelul conceptual pentru o corporaie este un compozit al mai multor vederi ale
oamenilor provenind din diferite departamente ale corporaiei. Diferitele comuniti ale
corporaiei i pot crea propria vedere conceptual. Aceast vedere ns este limitat la
relaiile i entitile vzute de respectivul departament. Colectarea tuturor acestor vederi
alctuiete ntregul model conceptual.
Pentru a alctui diagrama entitate relaie ce va reprezenta cerinele comunitii ce
va folosi sistemul de suport decizional, discuii de analiz trebuiesc realizate cu fiecare
grup pentru a cunoate fiecare din aceste vederi. Dup ce toate vederile sunt cunoscute,
ele vor fi integrate n modelul entitate relatie al corporaiei. Figura urmtoare prezint
procesul prin care se construiete diagrama entitate relaie pentru o corporaie. (Fig 20)

Fig 20: Modelul conceptual al activitilor unei corporaii, n

5.2

Nivelul logic

Nivelul logic este pragul la care apar pentru prima dat ideile IT n cerinele de
dezvoltare a sistemului de suport decizional. n modelul conceptual au fost folosite
numele cu care conceptele sunt folosite n organizaie, acum este momentul n care se
dezvolt convenii de nume i alte standarde. Atributele erau create fr consideraii
privind infrastructura sau arhitectura existent. n modelul logic sunt mai departe grupate
i aranjate.
Modelul logic este folosit n designul bazelor de date ca pas intermediar ntre
designul conceptual i cel fizic. El este intependent de sistemul de gestiune a bazei de
date. La acest nivel avem structura tabelelor i putem realiza denormalizri. O data
modelul logic creat, avem structura tabelelor, chei straine i indeci.
Spre exemplu, indeciii nu sunt o cerin n faza iniial de analiz, dar, dac se
dovedete c este nevoie de ei. pot fi creai n etapa nivelului logic. Cheile surogate sunt
adesea adugate n aceast etap pentru a minimiza complexitatea cheilor strine. n cele
din urm modelul logic va fi destul de aproape de cel fizic ca aspect.
Modelul logic foloseste termeni specifici modelului fizic: coloane, tabele,
indecii, dar nc prezint datele la un nivel lipsit de detaliu. n cadrul organizaiei,
oamenii interesai de modelul logic sunt cei ce analizeaz cerinele, managerii de proiect,
dezvoltatorii, arhitecii i integratorii de date. Dup ce sturctura i conveniile sunt
agreate se poate trece la relizarea modelului fizic.

5.3

Nivelul fizic

Modelul fizic este construit pe baza modelului logic la care se adaug chei,
caracteristici fizice i elementele de timp caracteristice pentru warehouse. La acest punct
modelul poate fi vzut ca o serie de tabele relaionale. Am putea spune c modelul este
gata s fie transferat ctre sistemul de gestiune a bazei de date (SGBD), cu toate acestea
din model lipsesc caracteristicile de optimizare a performanei. Consideraiile de design
care trebuiesc fcute n continuare n cazul sistemelor data warehouse se refer la
granularitate i partiionare
Nivelul fizic este domeniul administratorului bazei de date. Aici se aplic asupra
cerinelor i a datelor constrngeri ale platformei, cum ar fi limitri pentru lungimea
numelui tabelelor, limitri de integritate referenial. La acest nivel sunt create tabele,
tablespace-uri, triggere, proceduri stocate, partiii. Toate aceste sunt dependente de
sistemul de gestiune a bazei de date.

5.4

Concluzie

Cele trei nivele de modelare aduc valoare sistemului nc din faza de analiz. Ele
sunt de un real ajutor dac sunt folosite mpreun. La nceput, prin modelul conceptual
sunt strnse cerinele i comunicate napoi ctre stakeholderi ntr-o form high level, cu
posibilitatea de a fi detaliate. Apoi, nivelul logic permite deprtamentului IT s aplice
standarde i convenii fr a se lovi de limitri ale SGBD. n cele din urm, modelul fizic
este folosit de DBA pentru a crea o schema valid fr un editor de text.
O bun modelare i un bun program pentru crearea modelului ajut la stabilirea
unor standarde i la minimizarea efortului de dezvoltare. n acelai timp mbuntete i
comunicarea reducnd posibilitatea de confuzie.

Bibliografie
1. Peter Pin-Shan Chen - "The Entity-Relationship Model-Toward a Unified View of
Data", 1976, Massachusetts Institute of Technology p1-28.
2. Peter Pin-Shan Chen - "Entity-Relationship Modeling:Historical Events, Future
Trends, and Lessons Learned", 2002, Louisiana State University p1-11.
3. Mike Nicewarner - Data Modeling Layers Why have Conceptual, Logical and
Physical data modeling, December 2003, PowerDesigner Blueprint p1-5.
4. American National Standards Institute ANSI/X3/SPARC Study Group On
Database Management Systems; Interim Report, 1975.
5. Ronald Fagin - A Normal Form for Relational Databases That Is Based on
Domains and Keys, ACM Transactions on Database Systems, Vol. 6, No. 3,
September 1981
6. W. H. Inmon Building the Data Warhouse, Third Edition, 2002
7. Ralph Kimball, Margy Ross - The Data Warehouse Toolkit 2nd Edition The
Complete Guide to Dimensional Modeling, 2002
8. Morgan Kaufmann - Data Mining - Concepts and Techniques, 2004
9. Esteban Zimanyi - Temporal Aggregates and Temporal Universal Quantification
in Standard SQL, Universit e Libre de Bruxelles, 2005
10. Paulraj Ponniah - Data Warehousing Fundamentals: A Comprehensive Guide for
IT Professionals, 2001
11. Rob Mattison - Data Warehousing and Data Mining for Telecommunications,
1997
12. Roger E. Sanders - DB2 Universal Database Enterprise Server Edition V8.1:
Basic Performance Tuning Guidelines
13. IBM - Enterprise Data Warehousing with DB2 9 for z/OS, 2008
14. Dan Volitich - IBM Cognos 8 Business Intelligence: The Official Guide
15. Efraim Turban, Jay E. Aronson, Ting-Peng Liang, Ramesh Sharda - Decision
Support and Business Intelligence Systems (8th Edition) , 2006
16. IBM - The IBM Telecommunications Data Warehouse, 2005