Iniiere in Tehnologia OLAP Teorie I Practic

Cuprins
1. Sistemele OLAP – sisteme suport de decizie moderne ......................... 6
1.1. Locul sistemelor OLAP în evoluţia sistemelor suport de decizie ............................... 6

1.2. Sisteme suport de decizie orientate pe date (Data Driven Decision Support
13
Systems) .........................................................................................................................................
1.2.1. Sisteme informatice executive ............................................................................ 13
1.2.2. Sisteme suport de decizie spaţiale .................................................................... 14
1.2.3. Sisteme suport de decizie ce utilizează depozite de date .......................... 15
1.2.4. Sisteme OLAP ......................................................................................................... 17
1.2.4.1. Evoluţia sistemelor OLAP ....................................................................... 21
1.2.4.2. Relaţia între depozitele de date şi sistemele OLAP ........................ 24
1.2.4.3. Regulile lui Codd ........................................................................................ 25
1.3. Sisteme informatice pentru inteligenţa afacerilor ...................................................... 39
2. Modele de date multidimensionale pentru sisteme OLAP .................... 36
2.1. Concepte de bază .................................................................................................................. 37
2.1.1. Conceptul de cub n - dimensional ........................................................................ 37
2.1.2. Conceptul de dimensiune ....................................................................................... 41
2.1.3. Conceptul de ierarhie ............................................................................................ 42
2.1.4. Conceptul de măsură .............................................................................................. 45
2.1.5. Conceptul de multicub ........................................................................................... 46
2.1.6. Conceptul de împrăştiere ...................................................................................... 47
2.2. Modele de date OLAP – extensii ale modelului relaţional .......................................... 49
2.2.1. Operatorul Cub de date ........................................................................................ 50
2.2.2. Modelul lui Li Wang ................................................................................................ 54
2.2.3. Modelul lui Kimball ................................................................................................. 55
2.3. Modele orientate pe cuburi ............................................................................................... 59
2.3.1. Modelul lui Agrawal ................................................................................................ 59
2.3.2. Modelul lui Cabibbo ................................................................................................ 62

2.3.3. Modelul lui Blaschka .............................................................................................. 64
2.4. Evaluarea modelelor multidimensionale ........................................................................... 69
3. Arhitectura sistemelor OLAP ..................................................................... 76
3.1. Sisteme ROLAP ..................................................................................................................... 77
3.2. Sisteme MOLAP .................................................................................................................... 80
3.3. Sisteme hibride (HOLAP) .................................................................................................. 85
3.4. Arhitectura sistemelor OLAP ........................................................................................... 87
4. Instrumente OLAP ........................................................................................ 92
4.1. Caracteristici logice ............................................................................................................. 92
4.1.1. Structura datelor ................................................................................................... 93
4.1.2. Operaţii ..................................................................................................................... 95
4.1.3. Modul de reprezentare a datelor multidimensionale ..................................... 96
4.1.4. Alte caracteristici logice ...................................................................................... 96
4.2. Caracteristici fizice ............................................................................................................ 97
4.3. Exemple de instrumente OLAP ......................................................................................... 98
4.4. Standarde .............................................................................................................................. 106
5. Proiectarea sistemelor OLAP ..................................................................... 110
5.1. Metoda lui Cabibbo şi Torlone ........................................................................................... 111
5.1.1. Identificarea faptelor, dimensiunilor, ierarhiilor şi măsurilor .................... 112
5.1.2. Restructurarea modelului entitate – asociere ................................................. 113
5.1.3. Derivarea unui graf dimensional .......................................................................... 115
5.1.4. Transformarea în modelul multidimensional conceptual ................................ 116
5.2. Metoda lui Golfarelli ............................................................................................................ 118
5.2.1. Identificarea faptelor .......................................................................................... 119
5.2.2. Construirea unui arbore al atributelor ............................................................. 120
5.2.3. Rafinarea arborelui ................................................................................................ 121
5.2.4. Definirea dimensiunilor ........................................................................................ 122
5.2.5. Definirea măsurilor ............................................................................................... 122
5.2.6. Definirea ierarhiilor .............................................................................................. 123
5.3. Metoda lui Erik Thomsen .................................................................................................... 124

5.3.1. Definirea cuburilor şi a dimensiunilor ................................................................ 125
5.3.2. Rafinarea cuburilor n – dimensionale ................................................................. 125
5.3.3. Identificarea ierarhiilor din dimensiuni ........................................................... 126
5.3.4. Identificarea variabilelor .................................................................................... 126
5.3.5. Stabilirea formulelor de calcul şi a tipurilor de agregare ........................... 126
5.3.6. Tratarea fenomenului de împrăştiere ............................................................... 126
5.3.7. Definirea modelelor de calcul complexe necesare analizelor ...................... 127
6. Dezvoltarea sistemelor OLAP cu Oracle Express Objects ................. 132
6.1. Utilitarul Object Browser .................................................................................................. 135
6.2. Crearea unui proiect ............................................................................................................ 136
6.3. Deschiderea, închiderea şi lansarea în execuţie a unui proiect ................................ 137
6.4. Crearea, editarea şi lansarea în execuţie a unei pagini ............................................... 139
6.5. Componentele lui Object Inspector ................................................................................ 141
6.6. Crearea obiectelor unui proiect ........................................................................................ 143
6.7. Utilizarea colecţiei de rutine QuickActions .................................................................. 148
6.8. Limbajul de programare Express....................................................................................... 150
6.8.1. Declararea variabilelor .......................................................................................... 153
6.8.2. Structuri de program ............................................................................................ 156
6.9. Utilitarul Database Browser .............................................................................................. 165
6.10. Crearea şi utilizarea tabelelor şi a graficelor ............................................................. 171
6.10.1. Crearea tabelelor şi a graficelor ...................................................................... 176
6.11. Crearea listelor ce conţin valori ale dimensiunilor ...................................................... 181
6.12. Instrumentul Selector ...................................................................................................... 185
6.13. Crearea meniurilor ............................................................................................................. 190
6.14. Adăugarea obiectelor definite de utilizator în caseta de instrumente ................ 192
6.15. Utilizarea obiectelor de dialog ........................................................................................ 192
7. Dezvoltarea sistemelor OLAP cu Oracle Express Analyzer ............... 200
7.1. Conectarea la baza de date multidimensională .............................................................. 204
7.2. Crearea, actualizarea şi salvarea unui briefing ........................................................... 204
7.3. Crearea şi editarea paginilor ............................................................................................. 205

7.4. Mutarea, duplicarea şi referirea paginilor ..................................................................... 206
7.5. Crearea obiectelor unui briefing ...................................................................................... 207
7.6. Lansarea în execuţie a unui briefing sau a unei pagini ................................................ 212
7.7. Utilizarea tabelelor pentru analiza datelor ................................................................... 212
7.8. Instrumentul Selector ........................................................................................................ 215
7.9. Agregarea datelor ................................................................................................................ 219
8. Crearea unei baze de date multidimensionale cu Oracle Express

224
Administrator ......................................................................................................
8.1. Definirea dimensiunilor bazei de date ............................................................................. 225
8.2. Definirea variabilelor .......................................................................................................... 236
8.3. Definirea relaţiilor ............................................................................................................... 240
8.4. Definirea formulelor ........................................................................................................... 242
8.5. Definirea seturilor de valori .............................................................................................. 243
8.6. Definirea programelor ........................................................................................................ 244
9. Proiectarea şi realizarea unui sistem OLAP (studiu de caz) ............... 248
9.1. Iniţierea proiectului ............................................................................................................. 252
9.2. Studiul şi analiza procesului decizional curent şi a cerinţelor informaţionale ...... 254
9.3. Proiectarea modelului multidimensional conceptual ..................................................... 261
9.3.1. Identificarea variabilelor ..................................................................................... 261
9.3.2. Identificarea dimensiunilor şi a ierarhiilor ..................................................... 262
9.3.3. Definirea cuburilor n – dimensionale sau a structurii multicub .................. 264
9.3.4. Rafinarea modelului multidimensional ............................................................... 264
9.4. Proiectarea logică ................................................................................................................. 266
9.5. Proiectarea fizică ................................................................................................................. 270
9.6. Construirea sistemului OLAP ............................................................................................. 271
Anexe .................................................................................................................... 288
Bibliografie .......................................................................................................... 326

Capitolul 1
Sistemele OLAP-sisteme suport
de decizie moderne
Accesul la informaţie este o cerinţă de primă importanţă în orice organizaţie,
care îşi doreşte să aibă o prezenţă competitivă pe piaţă, în condiţiile schimbărilor
rapide din ziua de azi. Managerii doresc o informaţie corectă şi actuală, oferită în
timp real, într-un format corespunzător şi la un preţ convenabil. În 1992 Codd
observa că “Abilitatea întreprinderii de a concura cu succes şi de a prospera este
corelată direct cu eficacitatea capacităţii sale OLAP”.
Deşi sistemele OLAP (On-Line Analytical Processing) au fost incluse în
sistemele suport de decizie orientate pe date [POWE01] totuşi ele sunt mai exact
sisteme suport de decizie hibride, deoarece utilizează tehnici analitice simple
(analiza multidimensională a datelor) pentru a analiza seturi mari de date.
Majoritatea specialiştilor sunt de acord că depozitele de date (data warehouse)
împreună cu instrumentele OLAP oferă posibilitatea de a transforma cantităţile
uriaşe de date ce există în firme, în informaţii utile procesului decizional. De
asemenea, folosirea tehnicilor analitice oferite de instrumentele OLAP împreună cu
depozitele de date şi facilităţile oferite de Web, permit un acces mai uşor şi mai
rapid la informaţiile necesare procesului decizional modern. Aceste sisteme au
reuşit să ofere managerilor o informaţie de calitate şi noi moduri de interpretare a
informaţiilor, astfel eficacitatea procesului decizional s-a îmbunătăţit.
Ca urmare a creşterii rolului pe care sistemele OLAP îl au în infrastructura
informatică a unei organizaţii, s-a considerat necesară prezentarea, în acest capitol,
a evoluţiei sistemelor OLAP de la apariţia lor până în prezent, a locului acestor
sisteme în cadrul sistemelor suport de decizie moderne şi rolul lor în managementul
“inteligent” al firmelor secolului XXI.
1.1 Locul sistemelor OLAP în evoluţia sistemelor suport

de decizie
Conceptul de sistem suport de decizie (SSD) este extrem de larg şi definiţia sa
variază în funcţie de punctul de vedere al celui care a formulat-o. Încă din anii’70
6
Sisteme OLAP-sisteme suport de decizie moderne
specialiştii au încercat să definească cât mai complet sistemele suport de decizie şi

să le stabilească caracteristicile.
Prima definiţie a sistemelor suport de decizie a fost dată de Little, la începutul
anilor’70 [TURB98]. El definea SSD-ul ca fiind “un model bazat pe un set de
proceduri pentru procesarea datelor şi pentru asistarea unui manager în procesul
decizional. Un SSD trebuie să fie simplu, robust, uşor de întreţinut, adaptiv, uşor
de comunicat cu el etc”.
Unul din pionerii cercetării în domeniul sistemelor suport de decizie, Steven
Alter [TURB98] defineşte aceste sisteme în comparaţie cu sistemele tranzacţionale.
El consideră că „sistemele suport de decizie sunt destinate managerilor şi au ca
obiectiv principal eficacitatea deciziilor spre deosebire de sistemele tranzacţionale
care sunt folosite de operatori şi au ca obiectiv principal eficienţa şi consistenţa
datelor”.
Moore şi Chang [TURB98] definesc sistemul suport de decizie ca “un sistem
extensibil, capabil să suporte analize ad-hoc şi modelarea deciziei, orientat pentru
planificări viitoare şi folosit la intervale neplanificate şi neregulate”.
În lucrarea “Decision Support Systems: An Organizational Perspective”
(1978), Keen defineşte sistemul suport de decizie ca “un produs al procesului de
dezvoltare în care managerul, proiectantul şi sistemul sunt capabili să se
influenţeze reciproc, cu rezultate în evoluţia sistemului” [TURB98].
Bonczek şi Holsapple în lucrarea “Foundation of Decision Support Systems”
(1981) definesc sistemul suport de decizie ca fiind un “sistem informatic format din
trei componente ce interacţionează: interfaţa cu utilizatorul (Dialog Management),
componenta de gestiune a datelor (Data Management), componenta de gestiune a
modelelor (Model Management).
Sprague şi Carlson [SPRA93] definesc SSD-ul ca fiind “un sistem informatic
interactiv ce îi ajută pe decidenţi să folosească date şi modele, pentru a rezolva
probleme economice semistructurate şi nestructurate”.
Holsapple şi Whinston în lucrarea „Decision Support Systems: A knowledge –
Based Approach” (1996) pun în evidenţă cinci caracteristici specifice unui SSD şi
anume:
conţine o bază de cunoştinţe ce descrie unele aspecte ale lumii decidentului
(de exemplu cum se realizează diferite activităţi ale procesului decizional);
are abilitatea de a achiziţiona şi gestiona cunoştinţe descriptive şi alte tipuri
de cunoştinţe (proceduri, reguli);
are abilitatea de a prezenta cunoştinţele ad-hoc sau sub formă de rapoarte
periodice;
are abilitatea de a selecta un subset de cunoştinţe pentru a fi vizualizate sau
pentru a deriva alte cunoştinţe necesare procesului decizional;
poate interacţiona direct cu decidentul şi îi permite acestuia flexibilitate în
alegerea soluţiilor şi a gestiunii cunoştinţelor.
Într-un mod mult mai precis, Turban [TURB98] defineşte un SSD ca “un
sistem informatic interactiv, flexibil şi adaptabil, special proiectat pentru a oferi
suport în soluţionarea unor probleme manageriale nestructurate sau
7
Iniţiere în tehnologia OLAP-teorie şi practică
semistructurate, cu scopul de a îmbunătăţi procesul decizional. Sistemul utilizează

date (interne şi externe) şi modele, oferă o interfaţă simplă şi uşor de utilizat,
permite decidentului să controleze procesul decizional şi oferă suport pentru toate
etapele procesului decizional”.
Hattenschwiler [HATT99] consideră că SSD-urile sunt “sisteme informatice
bine organizate, proiectate în special pentru un mediu de decizie clar definit şi
capabile să fie perfecţionate continuu. SSD-urile nu iau decizii dar propun
decidenţilor analize ale avantajelor şi dezavantajelor alternativelor existente,
studii de fezabilitate şi documentaţii ale alternativelor”.
Se observă că definirea sistemelor suport de decizie a pornit de la:
percepţia a ceea ce face un astfel de sistem (suport pentru procesul
decizional, în probleme nestructurate şi semistructurate);
ideile despre cum pot fi realizate obiectivele unui SSD;
identificarea componentelor unui SSD;
facilităţile oferite utilizatorilor (tabelul 1.1).
Tabelul 1.1
Definiţii ale conceptului de SSD
Sursa Definirea unui SSD
Sprague, Carlson Tipul problemei şi funcţia sistemului
Little Funcţia sistemului
Alter Obiectivele sistemului
Moore, Chang Facilităţile sistemului
Keen Procesul de dezvoltare
Bonczek Componentele sistemului
Holsapple, Whinston Caracteristicile sistemului
Turban O combinare a definiţiilor date de Alter, Moore,
Bonczek, Sprague
Pe de altă parte, Schroff [SCHR98] şi Keen [POWE01] consideră că este

imposibil de a da o definiţie precisă incluzând toate aspectele SSD-urilor. Totuşi
conceptul de SSD rămâne un termen folositor care se referă la multe tipuri de
sisteme informatice, ce oferă suport procesului decizional [POWE01].
În ultimii ani, noile tehnologii informatice au determinat apariţia de noi criterii
de clasificare a sistemelor suport de decizie moderne. Astfel Power [POWE01]
propune o nouă clasificare (la nivel conceptual) a SSD-urilor în: SSD-uri orientate
pe comunicaţie (Communication-Driven DDS), SSD-uri orientate pe date (Data-
Driven DSS), SSD-uri orientate pe documente (Document-Driven DDS), SSD-uri
orientate pe cunoştinţe (Knowledge-Driven DDS), SSD-uri orientate pe modele
(Model-Driven DDS), SSD-uri bazate pe Web (Web-based DSS), SSD-uri
specializate (Function-specific DSS/industry-specific DDS) şi SSD-uri
interorganizaţionale sau intraorganizaţionale (Inter-organizational/Intra-
organizational DSS).
8
SSD-urile orientate pe date includ sistemele de fişiere, sistemele de raportare

pentru conducere, depozitele de date, sistemele OLAP, sistemele informatice
executive (Executive Information Systems), sistemele informatice spaţiale (Spatial
Information Systems) şi sistemele informatice pentru inteligenţa afacerilor
(Business Intelligence Systems). Aceste sisteme pun accentul pe accesul şi
manipularea unor baze de date structurate, de dimensiuni mari (în special serii de
timp ale datelor interne şi externe). Sistemele simple de fişiere, accesate de
instrumente de interogare, oferă cel mai elementar nivel de funcţionalitate, iar
sistemele cu depozite de date, sistemele OLAP şi sistemele informatice pentru
inteligenţa afacerilor oferă cel mai înalt nivel de funcţionalitate.
SSD-urile orientate pe modele includ sisteme ce utilizează modele financiare şi
de contabilitate, modele de optimizare şi de simulare. Un SSD orientat pe modele
pune accentul pe accesul şi manipularea unui model. În aceste sisteme, valorile
variabilelor cheie se modifică adesea, pentru a reflecta modificările ce apar în
activităţile de livrare, producţie, etc. Instrumentele analitice şi statistice simple
oferă cel mai elementar nivel de funcţionalitate. Unele sisteme OLAP, ce permit
analiza complexă a datelor pot fi clasificate ca SSD-uri hibride, deoarece permit
atât modelare cât şi agregarea datelor.
SSD-urile orientate pe cunoştinţe (Suggestion DSS/Knowledge Driven DDS/
Management Expert Systems) pot sugera sau recomanda acţiuni managerului.
Aceste SSD-uri oferă experienţă (cunoştinţe despre domeniul analizat, înţelegerea
problemelor din acel domeniu) în rezolvarea unor probleme. Aceste sisteme
utilizează modele speciale pentru procesarea regulilor sau identificarea relaţiilor ce
apar în date. Instrumentele utilizate pentru construirea SSD-urilor orientate pe
cunoştinţe sunt uneori numite suport de decizie inteligente (Intelligent Decision
Support Methods) [Dhar şi Stein 1997]. Instrumentele de tip data mining pot fi
folosite pentru a crea SSD-uri hibride ce includ atât date cât şi cunoştinţe.
Un nou tip de SSD este cel orientat pe documente sau sistem de gestiune a
cunoştinţelor (Knowledge Management System) care îi ajută pe manageri să
gestioneze documente nestructurate şi pagini Web, într-o varietate de formate
electronice. Un astfel de SSD integrează o varietate de tehnologii de stocare şi
prelucrare a documentelor. Web-ul oferă acces la baze de documente, de
dimensiuni mari (baze de documente hypertext, imagini, sunete şi video). Un astfel
de SSD trebuie să includă un motor de căutare foarte rapid. Activităţile specifice
acestui tip de SSD sunt crearea, căutarea, gruparea şi indexarea documentelor.
SSD-urile de grup (Group Decision Support Systems) sau o categorie mai
extinsă şi anume sistemele suport de decizie orientate pe comunicaţii includ
tehnologii de comunicare, colaborare şi suport de decizie. Un SSD de grup este un
SSD hibrid ce pune accentul atât pe utilizarea comunicării cât şi a modelelor de
decizie. Un SSD de grup este un sistem informatic interactiv ce facilitează
soluţionarea problemelor ce apar într-un proces decizional de grup. Aceste sisteme
oferă suport pentru comunicarea electronică, planificarea întâlnirilor, distribuirea
documentelor etc.
9
SSD-urile interorganizaţionale sau intraorganizaţionale (Inter-organizational/

Intra-organizational DSS) utilizează facilităţile oferite de Internet şi Intranet. Cele
mai multe SSD-uri sunt intraorganizaţionale, deoarece sunt proiectate pentru a fi
folosite de angajaţii unei firme, ca sisteme monoutilizator, sau de un grup de
manageri, ca sisteme la nivel de întreprindere .
Multe SSD-uri sunt proiectate pentru a oferi suport în anumite domenii de
activitate sau pentru funcţii specifice (de exemplu pentru planificarea bugetară,
marketing, planificarea activităţii de zbor pentru o firmă de transport aerian etc).
Astfel de SSD-uri se numesc SSD-uri specializate (Function-specific
DSS/industry-specific DDS). Aceste SSD-uri specializate pot fi mai departe
clasificate în funcţie de componenta dominantă, ca fiind SSD-uri orientate pe
modele, orientate pe date sau pe cunoştinţe. Unele SSD-uri specializate sunt
proiectate pentru un scop mai general, cum ar fi managementul proiectelor, analiza
deciziilor sau planificarea afacerilor şi în acest caz ele se mai numesc generatoare
SSD, deoarece pot fi folosite pentru a dezvolta sau “genera” un SSD mai specializat
[SPRA93].
SSD-urile bazate pe Web (Web-based DSS) sunt sisteme informatice ce
livrează informaţii necesare procesului decizional sau instrumente suport de decizie
managerilor sau analiştilor, utilizând un simplu browser Web (de exemplu
Netscape Navigator, Microsoft Internet Explorer) şi facilităţile oferite de
arhitectura client/server. În multe firme, un SSD bazat pe Web este sinonim cu un
SSD la nivel de întreprindere sau intraorganizaţional. SSD-urile bazate pe Web
permit: analiza şi afişarea datelor structurate stocate în baze de date relaţionale sau
multidimensionale, acces la modele, acces la documente multimedia şi date
nestructurate, comunicarea şi luarea deciziilor în echipele distribuite. În general,
toate tipurile de SSD-uri (orientate pe date, orientate pe modele, orientate pe
cunoştinţe, orientate pe documente şi cele de grup) pot fi implementate folosind
tehnologii Web (tabelul 1.2). Tehnologiile Web au extins scopul SSD-urilor, în
special pentru SSD-urile de grup.
Tabelul 1.2
Implementarea SSD-urilor
Tipuri de SSD-uri Tehnologia utilizată
LAN Web
SSD-uri de grup Aplicabile la nivel local Aplicabile la nivel
SSD-uri orientate pe global
comunicaţii
SSD-uri orientate pe date Client complex Client simplu (de tip
browser)
SSD-uri orientate pe Numai documente de tip Documente HTML
documente (.doc), (.xls)
SSD-uri orientate pe Monoutilizator Multiutilizator
model
10
Tendinţa actuală în tehnologia informaţiei este de a utiliza facilităţile Web în

toate sistemele informatice, deci şi în sistemele suport de decizie.
Un SSD bazat pe Web impune existenţa unui server de Web (de exemplu
Apache WWW Server) (figura 1.1). Instrumentele pentru construirea unui sistem
suport de decizie bazat pe Web includ HTML, CGI, Java Applets, cod JavaScript
în pagini HTML, componente ActiveX. Limbajul Java asigură facilităţi puternice
instrumentelor de dezvoltare a SSD-urilor, iar JavaScript permite integrarea
obiectelor Web. Arhitecturile Web trebuie să manipuleze un număr mare de cereri
concurente, simultan cu obţinerea unui răspuns în timp util, în condiţiile creşterii
numărului de utilizatori şi a volumului datelor procesate.
Multe firme au realizat SSD-uri bazate pe Web sau oferă instrumente pentru
dezvoltarea şi implementarea unui sistem suport de decizie orientat pe Web. De
exemplu, Oracle oferă posibilitatea de a construi un sistem OLAP pe Web sau un
sistem cu depozite de date pe Web (WebHouse).
Browser Server Web Modele/baza

de date
Figura 1.1 Arhitectura unui SSD bazat pe Web
Avantajele SSD-urilor bazate pe Web sunt:

s-au eliminat barierele tehnologice şi s-a permis utilizatorilor un acces
distribuit la informaţii, cu costuri mici;
firmele pot oferi managerilor prin Intranet, clienţilor şi furnizorilor prin
extranet sau prin Internet, facilităţile specifice SSD-urilor;
folosind infrastructura Web la realizarea SSD-urilor, s-au realizat analize şi
s-au luat decizii mai consistente în problemele decizionale repetitive, într-o
organizaţie distribuită;
permit aducerea de noi resurse de cunoştinţe în procesul decizional;
nu mai este necesar un software complex, ci un simplu browser instalat pe
staţia client.
Dezavantajele unui SSD bazat pe Web sunt:
uneori aşteptările pot fi supradimensionate, în raport cu informaţia
accesibilă pe Web;
apar probleme tehnice de implementare în timpul procesului de interogare
sau încărcare;
costuri mari pentru instruirea utilizatorilor (clienţi, furnizori).
Managerii trebuie să aibă în vedere faptul că sistemele suport de decizie
orientate pe Web pot oferi un avantaj important firmelor. Locul de acţiune al
11
sistemelor suport de decizie moderne este Internetul. Web-ul reprezintă o

importantă oportunitate în livrarea cantitativă şi calitativă a informaţiilor
decidenţilor.
Pentru a putea realiza un studiu comparativ al sistemelor suport de decizie
moderne este necesar să stabilim criteriile pe baza cărora se face analiza
comparativă. Aceste criterii sunt: scopul sistemului, arhitectura utilizată, tipul de
utilizatori, componenta principală a sistemului (tabelul 1.3). După cum se observă,
SSD-urile orientate pe date, pe cunoştinţe şi pe documente au componenta
principală baza de date (date, cunoştinţe, documente). Un SSD orientat pe model
are componenta principală formată din modele analitice şi matematice.
Tabelul 1.3
Analiza comparativă a sistemor suport de decizie
Componenta Utilizatorii: Scopul: general/ Arhitectura
principală a SSD- interni/ specific utilizată
ului externi
Comunicaţii Echipe interne/ Suport pentru Web sau client/
SSD-uri orientate pe parteneri comunicare şi server
comunicaţii externi colaborare
Baze de date Manageri, Interogarea unui Mainframe,
SSD-uri orientate pe furnizori depozit de date, client/server,
date foloseşte date Web
structurate
Baze de documente Utilizatori Căutarea paginilor Client/server,
SSD-uri orientate pe interni dar Web sau a Web
documente grupul poate fi documentelor
extins nestructurate
Baze de cunoştinţe Utilizatori Foloseşte reguli, Client/server,
SSD-uri orientate pe interni, clienţi relaţii Web, PC
cunoştinţe
Modele Manageri, Foloseşte modele PC,client/server,
SSD-uri orientate pe clienţi Web
modele
Modele/ baze de date Utilizatori Suport pentru Client/server,
şi comunicaţii interni şi intermediari Web
SSD-uri externi
interorganizaţionale
/intraorganizaţionale
Modele/ baze de date Utilizatori Suport pentru orice Web
şi comunicaţii interni şi sarcină a SSD-ului
SSD-uri bazate pe externi
Web
12
Componenta Utilizatorii: Scopul: general/ Arhitectura

principală a SSD- interni/ specific utilizată
ului externi
Modele/baze de date Utilizatori Specializate pe PC, client/server
SSD-uri specializate interni anumite domenii de
activitate sau cu un
scop mai general
(generator SSD)
1.2 Sisteme suport de decizie orientate pe date (Data Driven

Decision Support Systems)
Sistemele suport de decizie orientate pe date (SSDOD) au captat atenţia
managerilor, deoarece aceste sisteme pot furniza un acces mai uşor la colecţii
foarte mari de date. Într-o lume a competiţiei acerbe şi a comunicării electronice,
managerii doresc să găsească propriile răspunsuri la întrebările ce apar în domeniul
afacerilor. Managerii sunt utilizatorii direcţi şi cei mai vizaţi ai acestor sisteme. Ei
trebuie să identifice împreună cu proiectantul, datele necesare pentru analiză şi
relevante pentru procesul decizional.
Un SSDOD este „un sistem informatic interactiv care-i ajută pe manageri să
utilizeze baze de date de dimensiuni foarte mari ce conţin date preluate din surse
interne şi externe ale organizaţiilor” [POWE01].
Utilizatorii sistemului pot realiza analize foarte complexe şi cereri analitice de
date. Într-un sistem suport de decizie orientat pe date, managerii procesează date
pentru a identifica fapte şi pentru a trage concluzii despre relaţiile dintre date sau
despre tendinţa lor de evoluţie. Sistemele suport de decizie orientate pe date pot
ajuta managerii să găsească, să afişeze şi să analizeze date istorice. Deşi aceste
sisteme sunt scumpe şi greu de implementat, multe firme mari le-au implementat.
Se pot defini următoarele categorii principale de sisteme suport de decizie
orientate pe date:
Sisteme informatice executive;
Sisteme suport de decizie spaţiale;
Sisteme suport de decizie care utilizează depozite de date;
Sisteme OLAP.
1.2.1 Sisteme informatice executive
Sistemele informatice executive (Executive Information Systems) sunt sisteme

suport de decizie la nivel de întreprindere care îi ajută pe manageri să analizeze, să
compare şi să pună în evidenţă tendinţele, să monitorizeze performanţele şi să
13
identifice oportunităţile şi problemele cu care se confruntă organizaţia. Au

următoarele caracteristici:
sunt proiectate pentru cerinţele informaţionale ale managerilor de la nivelul
tactic şi strategic al organizaţiei;
accesează date din surse variate (interne şi externe);
pun accentul pe afişarea grafică a informaţiilor şi pe uşurinţa în a utiliza
interfaţa. Aceste sisteme oferă facilităţi puternice de raportare (standard şi
ad-hoc) şi tehnici analitice complexe;
utilizează de obicei o arhitectură client/server.
La ora actuală, există o mare varietate de instrumente software pentru
proiectarea sistemelor informatice executive (de exemplu: ActiveInsights-
ActiveInsights, Action Driven balanced Scorecard-Show Business Software,
Active Architect-European Management Systems etc), precum şi un număr mare
de sisteme informatice executive proiectate (de exemplu: Decision-Datavision
Technologies Inc., Focus EIS-Information Builders Inc., Executive Information
Support System-Applied Media Resources Inc. etc).
Cerinţele informaţionale ale managerilor se modifică rapid, astfel multe
sisteme informatice executive sunt proiectate şi dezvoltate folosind metodologia
prototipului. Identificarea factorilor critici de succes pentru organizaţie (de
exemplu distribuţia pieţei, productivitatea etc) îi poate ajuta pe analişti să
determine ce informaţii trebuie prezentate într-un sistem informatic executiv. Un
proiect SIE este similar cu proiectele de depozite de date, dar pune accent în
special pe proiectarea interfeţei.
1.2.2 Sisteme suport de decizie spaţiale
Sistemele suport de decizie spaţiale (Spatial Decision Support Systems) sunt

construite folosind tehnologii GIS (Geographic Information System). Datele
spaţiale sunt reprezentări de obiecte construite din puncte, linii, suprafeţe, volume
sau chiar date cu dimensionalitate ridicată. Datele spaţiale pot constitui reprezentări
ale oraşelor, judeţelor, râurilor dintr-o hartă codificată într-un sistem GIS. Bazele
de date spaţiale facilitează memorarea şi prelucrarea eficientă a informaţiilor
spaţiale şi nespaţiale. Astfel de baze de date sunt din ce în ce mai folosite în
sistemele informatice geografice. În bazele de date spaţiale, unui obiect grafic i se
pot ataşa atât propietăţi spaţiale (de exemplu, frontiera unui judeţ poate fi o
propietate spaţială asociată respectivului judeţ) cât şi atribute nespaţiale cum ar fi
numele unui oraş sau înălţimea unui munte. Sistemele suport de decizie spaţiale îi
ajută pe manageri să acceseze, afişeze şi analizeze datele care au conţinut
geografic. Ele şi-au găsit aplicabilitate în domenii ca geologie, industria forestieră,
agricultură. Multe firme software oferă instrumente GIS puternice pentru
proiectarea sistemelor suport de decizie spaţiale (de exemplu: Expert Base-Expert
Database Marketing System, SAS System-SAS Institute, Arcview, BusinessMap-
ESRI etc).
14
1.2.3 Sisteme suport de decizie ce utilizează depozite de date
În fiecare organizaţie există multe sisteme informatice tranzacţionale ce

automatizează operaţiile zilnice ale unei organizaţii, operaţii care sunt structurate şi
repetitive şi constau din tranzacţii scurte, atomice şi izolate. Aceste sisteme permit
conducerea operativă a organizaţiilor şi utilizează date de detaliu, reprezentări
curente şi în timp real a stării firmei, accesate şi actualizate frecvent. Dimensiunea
bazelor de date operaţionale variază de la sute de Mb la Gb, iar consistenţa datelor
stocate este o cerinţă fundamentală a sistemelor tranzacţionale. Spre deosebire de
sistemele tranzacţionale, sistemele suport de decizie sunt utilizate pentru a gestiona
şi controla firma. Depozitele de date sunt destinate suportului decizional. Datele
istorice şi datele agregate sunt mai importante decât datele de detaliu. Dimensiunea
depozitelor de date pentru întreprindere variază de la sute de Gb pâna la Tb.
Cererile ad-hoc pot accesa milioane de înregistrări şi execută o mulţime de
parcurgeri ale tabelelor, joncţiuni şi agregări. Timpul de răspuns este un factor
principal în proiectarea sistemelor suport de decizie orientate pe date. Pentru a
facilita analize complexe şi vizualizări, datele stocate în depozitul de date sunt
modelate multidimensional. Operaţiile specifice acestor sisteme sunt: roll up
(creşterea nivelului de agregare), drill down (creşterea nivelului de detaliu),
slice/dice (selecţia şi proiecţia) şi pivot (reorientarea viziunii multidimensionale a
datelor). De asemenea, sistemele suport de decizie pot utiliza date ce nu se găsesc
în bazele de date operaţionale (de exemplu, pentru realizarea de predicţii se cer
date istorice, în timp ce bazele de date operaţionale stochează numai date curente).
Datele din depozitele de date provin din surse variate: sisteme operaţionale
eterogene (sisteme de gestiune a bazelor de date, sisteme de gestiune a fişierelor) şi
alte surse de date externe (baze de date demografice şi statistice, Internet). Sursele
de date externe sau interne pot conţine date inconsistente, cu formate variate, date
care trebuiesc “curăţate” şi prelucrate înainte de a fi stocate în depozitul de date.
De asemenea, modele de date multidimensionale şi operaţiile tipice OLAP impun o
organizare diferită a datelor şi metode de acces care nu sunt oferite în general de
SGBD-urile comerciale, destinate pentru sistemele informatice tranzacţionale. Din
aceste motive, depozitele de date sunt implementate separat de bazele de date
operaţionale.
În concluzie, un depozit de date este o bază de date de dimensiuni mari,
specific proiectată pentru a susţine procesul decizional dintr-o organizaţie şi
optimizată pentru interogări on-line rapide şi pentru agregări complexe.
În 1995, Bill Inmon definea depozitul de date ca fiind “o colecţie de date
orientată pe subiect, integrată, dependentă de timp şi nevolatilă, destinată pentru a
susţine procesul decizional dintr-o organizaţie”:
Orientată pe subiect. Într-un depozit, datele sunt organizate în funcţie de
subiectele importante pentru organizaţie, cum ar fi clienţii, produsele şi
activităţile.
15
Integrată. Datele trebuie să fie reprezentate, în depozitul de date, într-un

format consistent, pentru a permite analistului să se concentreze asupra
utilizării datelor din depozit şi nu asupra credibilităţii şi consistenţei lor.
Nevolatilă. În depozitul de date, există doar două tipuri de operaţii:
încărcarea iniţială a datelor şi interogarea datelor. Datele nu mai sunt
actualizate după ce au fost încărcate în depozitul de date. La proiectarea
depozitului de date, tratarea anomaliilor de actualizare nu mai este un
factor important. Ralph Kimball [KIMB96] afirma că “un depozit de date
este o copie a datelor tranzacţionale, specific structurată pentru interogare
şi analiză”.
Dependentă de timp. Datele din depozitul de date sunt asociate cu elemente
temporale. În depozitul de date, orizontul de timp este cuprins între 5 şi 10
ani, în timp ce în sistemele tranzacţionale poate lua valori între 60 şi 90 de
zile. De asemenea, structura cheilor conţine implicit sau explicit un
element de timp.
Tehnologiile pentru depozite de date au fost utilizate cu succes în multe

domenii: producţie, comerţul cu amănuntul (pentru gestiunea stocurilor), servicii
financiare (analiza riscului, analiza cardurilor de credit şi detectarea fraudelor),
transport, telecomunicaţii (analiza apelurilor şi detectarea fraudelor) etc. Motivul
fundamental pentru construirea unui depozit de date este de a îmbunătăţi calitatea
informaţiilor din organizaţie. Problema cheie este de a oferi acces la o viziune
globală a datelor la nivelul organizaţiei, indiferent de locaţia lor. Datele provin din
surse interne ş externe, existând într-o varietate de forme de la datele structurate la
cele nestructurate cum ar fi documentele sau multimedia.
Multe organizaţii doresc să implementeze un depozit de date la nivel de
întreprindere integrat ce colectează informaţii despre toate subiectele (clienţi,
produse, vânzări, personal etc). Totuşi construirea unui depozit de date este un
proces lung şi complex. De aceea, unele organizaţii utilizează centrele de date
(data mart).
Un centru de date este un depozit de date la nivel de departament, care are
dimensiuni mai reduse (10-50 Gb). El este concentrat pe un singur subiect (de
exemplu vânzări, finanţe, asigurări), fiind construit şi folosit de un singur
departament al unei organizaţii şi preia date din sistemul operaţional intern al
organizaţiei, din depozitul de date central sau din surse externe. Centrele de date
permit o agregare mai rapidă a datelor, dar pot conduce la probleme de integrare
complexe. În tabelul 1.4 se prezintă o analiză comparativă între depozitele de date
şi centrele de date.
16
Tabelul 1.4
Analiză comparativă între depozitele de date şi centrele de date
Depozitul de date Centru de date
Se foloseşte: la nivel de organizaţie, pentru firme mici, la nivel
pentru firme mari de departament
Domenii multiple un singur domeniu
Surse de date numeroase puţine
Dimensiunea 100 Gb-Tb < 100 Gb
Timpul de ani luni
implementare
Depozitele de date virtuale sunt considerate un mod de a implementa mai rapid

un depozit de date. Utilizatorii au posibilitatea de a accesa direct datele sursă reale
utilizând instrumente cu facilităţi de reţea complexe. Dezavantajele acestor
depozite de date virtuale sunt:
calitatea şi consistenţa datelor nu este garantată, întrucât nu se execută
anterior nici o “pregătire” a datelor;
datele istorice nu sunt valabile;
timpul de acces al utilizatorilor este de obicei imprevizibil depinzând de
valabilitatea surselor de date operaţionale, încărcarea reţelei, complexitatea
cererii etc.
Majoritatea firmelor de renume, în domeniul bazelor de date, oferă instrumente
software puternice pentru proiectarea depozitelor de date, precum şi pentru
extracţia, transformarea şi încărcarea datelor din surse variate în depozitele de date
(Power Designer Warehouse Architect –Power Soft, Red Brick Warehouse-
Informix, Warehouse Builder-Oracle, SAS System –SAS Institute etc).
1.2.4 Sisteme OLAP
Aşa cum indică cuvintele folosite pentru a construi acronimul (“on-line”,

“analytic”, “proccesing”), rolul sistemelelor OLAP într-o organizaţie este de a oferi
un acces interactiv şi uşor la resursele analitice necesare procesului decizional şi de
conducere. În teoria sistemelor suport de decizie sunt recunoscute două tipuri de
resurse analitice: datele (informaţii statice) şi modelele (informaţii dinamice).
La ora actuală nu există încă o teorie OLAP completă, unanim acceptată de toţi
specialiştii. Există totuşi o serie de principii (reguli) care pun în evidenţă
potenţialul sistemelor OLAP, ca o componentă critică în orice infrastructură
informaţională. Aceste principii sunt simple dar relevante şi nu trebuie să fie
ignorate:
La baza tuturor activităţilor dintr-o firmă stă prelucrarea informaţiilor.
Aceasta include colectarea, stocarea, transmiterea şi manipularea datelor.
Importanţa unei bune informaţii poate fi gândită ca diferenţa în valoare între
deciziile corecte şi cele greşite, unde deciziile sunt bazate pe informaţii. Cu cât este
17
mai mare diferenţa între deciziile bune şi cele greşite, cu atât este mai important de
a avea informaţii bune. Majoritatea firmelor investesc mult în tehnologiile
informatice. Informaţiile bune trebuie să fie corecte, curente, complete şi uşor de
înţeles. Prima cerinţă funcţională a sistemelor OLAP decurge din aceste cerinţe
generale pentru prelucrarea informaţiei: să ofere informaţii corecte, curente,
complete şi uşor de înţeles.
Activităţile operaţionale şi cele de analiză orientată pe decizie constituie
nucleul activităţii unei firme, independent de mărimea ei, domeniul de activitate,
forma legală. Cumpărarea, vânzarea, producţia şi transportul sunt exemple de
activităţi operaţionale. Informaţiile despre vânzări, producţie şi costuri pot fi
înregistrate şi gestionate în una sau mai multe baze de date, folosite pentru scopuri
operaţionale. Activităţile operaţionale se execută la un interval relativ constant.
Datele sunt citite şi actualizate frecvent şi reprezintă o fotografie curentă a ceea ce
se întâmplă în firmă. Fiecare cerere foloseşte un volum mic de informaţii iar natura
ei este în general previzibilă.
Monitorizarea, evaluarea, compararea, planificarea şi alocarea strategică a
resurselor sunt exemple de activităţi de analiză. Informaţia generată prin activităţile
de analiză este orientată pe decizie, deoarece este într-o formă ce o face imediat
utilizabilă în procesul decizional. Orientarea spre decizie a analizei este esenţială.
Multe activităţi operaţionale sunt orientate pe decizie, fără a se baza pe analiză. De
exemplu dacă un client doreşte o creştere a creditului, trebuie luată o decizie. Dacă
înregistrarea corespunzătoare clientului menţionează că s-a ajuns la limita cardului,
decizia este NU. Informaţia despre credit a fost orientată pe decizie, dar nici o
analiză nu a fost implicată în decizie.
Cu o frecvenţă mai mică, managerii şi analiştii pot pune întrebări analitice cum
ar fi: “Ce produse au fost cele mai profitabile pentru firmă, în acest an?” “Care
este profitul firmei în acest trimestru faţă de acelaşi trimestru al anului trecut?”
etc. Răspunsurile la aceste tipuri de întrebări reprezintă informaţii ce sunt bazate pe
analiză şi orientate pe decizie. Datele sunt mai mult citite decât actualizate în aceste
activităţi. Cererile analitice folosesc date derivate şi natura lor nu este întotdeauna
previzibilă. Diferenţele între activităţile operaţionale şi cele orientate pe decizie şi
bazate pe analiză sunt prezentate în tabelul 1.5. Ca urmare a acestor diferenţe,
majoritatea firmelor folosesc instrumente diferite pentru cele două tipuri de
activităţi :
pentru a asigura eficienţă maximă în ambele activităţi;
pentru a realiza actualizare rapidă în activităţile tranzacţionale şi calcul
rapid în activităţile de analiză.
18
Tabelul 1.5
Analiză comparativă între activităţile operaţionale
şi cele orientate pe decizie şi bazate pe analiză
Activităţi operaţionale Activităţi orientate pe decizie
şi bazate pe analiză
Mai frecvente Mai puţin frecvente
Mai previzibile Mai puţin previzibile
Volume mai mici de date pe cerere Volume mai mari de date pe cerere
Utilizează mai mult date de bază Utilizează mai mult date derivate
Utilizează datele cele mai curente Utilizează date istorice şi date
curente
Teoria sistemelor suport de decizie stă la baza fundamentării teoretice a

sistemelor OLAP. Definiţia sistemului suport de decizie: “Sistem informatic
interactiv, flexibil şi adaptabil, special proiectat pentru a oferi suport în
soluţionarea unor probleme manageriale nestructurate sau semistructurate, cu
scopul de a îmbunătăţi procesul decizional, ce utilizează date şi modele, oferă o
interfaţă simplă şi uşor de folosit, permite decidentului să controleze procesul
decizional şi oferă suport pentru toate etapele procesului decizional” [TURB98] a
fost o provocare pentru sistemele OLAP .
Sistemele OLAP reprezintă o categorie importantă de sisteme suport de decizie
orientate pe date. Cerinţele funcţionale ale sistemelor OLAP decurg din obiectivele
sistemelor suport de decizie orientate pe date:
Oportunitate. Un SSDOD trebuie să garanteze următoarele:
- datele de bază au fost deja prelucrate sau pregătite pentru analiză.
Aceasta se referă la ”curăţarea” şi integrarea datelor;
- accesul la date este rapid;
- calculele sunt rapide.
Acurateţe. Un SSDOD trebuie să asigure precizia datelor de bază şi
exactitatea calculelor.
Inteligibile. Un SSDOD trebuie să asigure interfeţe prietenoase sau
intuitive.
Locul sistemelor OLAP în SSDOD-uri, în raport cu obiectivele SSDOD-urilor,
este pus în evidenţă în tabelul 1.6 [THOM96]. Se observă că principalele obiective
ale sistemelor OLAP sunt :
access rapid şi calcule rapide, facilităţi analitice puternice (analize ad-hoc
foarte rapide);
interfaţă prietenoasă şi prezentări flexibile;
permit prelucrarea unor volume mari de date (1-500 Gb), cu multe niveluri
de detaliu, în mediu multiutilizator.
Acces rapid şi calcule rapide. Sistemele OLAP oferă suport pentru cereri
analitice ad-hoc. Obiectivul principal al sistemelor OLAP este „de a furniza un
timp de răspuns de cinci secunde sau mai puţin, indiferent de tipul de cerere sau de
dimensiunea bazei de date, într-un mediu multiutilizator şi distribuit” [OLAP97].
19
Pentru acces eficient maxim, sistemele OLAP trebuie să ofere combinaţia corectă
de rezultate antecalculate şi calculate la momentul interogării. Sistemele OLAP
stochează date istorice, curente, de detaliu sau agregate.
Tabelul 1.6
Locul sistemelor OLAP în SSDOD-uri
Scopuri Colecţii Multe Mulţi Mulţi
mari de niveluri factori utilizatori
date
Oportunitate Acces rapid OLAP OLAP OLAP DW
Calcule rapide OLAP OLAP OLAP OLAP
Acurateţe Date de bază DW DW DW DW
exacte
Expresivitate OLAP OLAP OLAP
de calcul
Inteligibilitate Interfaţă OLAP OLAP OLAP
prietenoasă
Viziuni OLAP OLAP OLAP
flexibile
Facilităţi analitice puternice. Sistemele OLAP permit navigarea interactivă la

niveluri diferite de agregare şi viziuni multidimensionale ale datelor
Flexibilitate. Flexibilitatea este un alt obiectiv al sistemelor OLAP. Ea are o
varietate de înţelesuri (prezentări flexibile, definiţii flexibile, analiză flexibilă,
interfeţe flexibile). Sistemele OLAP trebuie să fie flexibile în toate modurile.
Flexibilitatea prezentării se referă la faptul că utilizatorul poate vizualiza informaţia
sub formă de grafice, matrici sau hărţi. De asemenea, utilizatorii trebuie să fie
capabili să modifice definiţiile formulelor şi locaţia surselor de date. Flexibilitatea
interfeţei este o formă mai generală a ceea ce uneori se numeşte o interfaţă
intuitivă. Flexibilitatea interfeţei se aplică la o varietate de arii cum ar fi definiţia
modelului, vizualizarea modelului, specificarea formulelor, introducerea directă a
datelor şi legăturile la sursele de date externe.
Suport multiutilizator. Organizaţiile sunt medii de lucru în colaborare. Ca
rezultat al descentralizării, numărul relativ de angajaţi, ce trebuie să aibă acces de
citire şi scriere la datele analitice pentru decizii, este în creştere.
Sistemele OLAP sunt o aplicaţie a combinării între algoritmi şi structuri de
date în scopul de a creşte puterea de calcul. La început tehnologia OLAP a fost
considerată ca o tehnologie de baze de date, fundamental diferită de tehnologia
bazelor de date relaţionale [CODD93]. Teoria lui Codd nu a fost completă şi nici în
totalitate reală, dar a constituit o listă de cerinţe pe care sistemele OLAP trebuie să
le respecte. Alţi autori au încercat să detalieze aceste cerinţe [THOM96].
20
Sistemele OLAP sunt cel mai potrivit mediu pentru implementarea modelelor
de afaceri (business models) ce aplică principiile dinamice ale sistemelor. Pentru
a putea fi folosite efectiv, modelele trebuie să fie accesate şi manipulate uşor.
Sistemele OLAP oferă aceste facilităţi.
1.2.4.1 Evoluţia sistemelor OLAP
Încă din anii ‘70-’80, s-au dezvoltat sisteme informatice ce au permis analiză
multidimensională, înainte de a fi cunoscute sub numele de sisteme OLAP.
Principalele eforturi în dezvoltarea tehnologiei OLAP pot fi prezentate cronologic
după cum urmează :
În 1962 Ken Iverson, în cartea sa “A programming Language”, descrie primul
limbaj multidimensional, limbajul APL. Acest limbaj a fost implementat de IBM pe
mainframe-uri, la sfârşitul anilor ’60. Multe din conceptele acestui limbaj sunt
folosite şi astăzi (de exemplu, Adaytum Planning şi Lex 2000 folosesc limbajul
APL).
La sfârşitul anilor ’60, John Little, doctor în fizică, Len Lodish, tânăr specialist
în marketing la Massachusetts Institute of Technology Sloan School şi Glen Urban,
decanul de la Sloan School, au încercat să utilizeze calculatoarele în aplicaţii
matematice şi analitice. Au încercat utilizarea analiticului în marketing, în special
în marketingul bunurilor de consum. Aceasta era o arie ideală de investigaţie,
deoarece exista un volum mare de date brute neprelucrate şi procesul decizional
putea fi îmbunătăţit prin înţelegerea mai bine a datelor. Efortul lor a condus la
apariţia sistemelor de gestiune a deciziilor (Management Decision Systems), în
1974. MDS-urile erau utilizate în special pentru crearea de modele matematice
pentru analize de marketing. A fost o muncă complexă de programare în Fortran,
care a avut ca rezultat o bibliotecă de funcţii analitice şi facilităţi de stocare a
matricilor pe disc. John Wirts a considerat că biblioteca de subrutine ar putea fi
generalizată şi că facilităţile analitice ar putea fi îmbunătăţite mult, pentru
utilizatorul final, prin adăugarea facilităţilor de gestiune a datelor. Acesta a fost un
important pas în dezvoltarea primelor sisteme OLAP.
În 1972 funcţiile analitice şi facilităţile de gestiune a datelor au fost integrate
într-un limbaj, limbajul Express. După 30 de ani, Express rămâne una din
principalele tehnologii OLAP folosite, conceptele şi modelul de date fiind
neschimbate.
La începutul anilor ’70, firma Comshare a ales analiza financiară ca o activitate
centrală. Firma a achiziţionat un limbaj de modelare financiară numit FCS de la o
firmă de software britanică (EPS Consultants). Specialiştii firmei au căutat să facă
din limbajul FCS, un limbaj care să satisfacă cerinţele utilizatorilor pentru analiza
multidimensională.
În 1978-1979, Comshare a considerat necesară trecerea la o nouă generaţie de
limbaj de modelare financiară, realizată prin combinarea funcţiilor analitice de
modelare cu tehnologia gestiunii datelor, în scopul de a gestiona volume mult mai
21
mari de date asociate cu conceptul de multidimensionalitate. Instrumentul rezultat a

fost System W DSS, primul instrument OLAP pentru aplicaţii financiare, care
folosea conceptul de hypercub. Principala sa utilizare era ca suport decizional
financiar, utilizat în activitatea bugetară, de previziune şi de planificare strategică.
A introdus multe concepte cum ar fi: reguli complet neprocedurale, vizualizare
multidimensională a datelor, integrare cu datele relaţionale etc. Aşa cum Express a
devenit un instrument important în aplicaţiile de analiză de piaţă, System W a
devenit o forţă în planificare, analiză şi aplicaţii de raportare financiară, în anii’80.
Hyperion Essbase, deşi nu este un descendent direct al lui System W, foloseşte
multe din conceptele utilizate de System W (de exemplu conceptul de hypercub).
În 1984 a apărut primul instrument ROLAP, Methafor, folosit în analiza de
marketing. A introdus noi concepte, care au devenit populare în anii’90, cum ar fi
calcule distribuite client/server, procesare multidimensională a datelor relaţionale.
Din păcate costurile pentru hardware şi software erau foarte mari şi nu a folosit o
arhitectură deschisă şi interfeţe GUI standard.
La mijlocul anilor’80 a apărut termenul de EIS (Executive Information
System). În 1985 apare Pilot Command Center, primul instrument OLAP stil EIS,
cu arhitectură client/server. Instrumentul utiliza analiza seriilor de timp, fiind
implementat pe servere VAX şi clienţi PC standard. Pilot a introdus multe concepte
utilizate de noile instrumente OLAP cum ar fi procesarea multidimensională
client/server. Unele din aceste concepte au fost implementate în Pilot’s Analysis
Server.
În 1990 Cognos Power Play devine primul instrument OLAP cu arhitectură
desktop, pentru Windows. Firma Cognos oferă şi versiuni pentru arhitectură
client/server şi Web.
În 1991 Metaphor este achiziţionat de consorţiul Apple - IBM Taligent.
Firma Arbor Software s-a constituit în 1991, cu scopul unic de a crea un server
de bază de date multidimensională şi multiutilizator, care s-a numit Essbase.
Essbase a fost introdus pe piaţă în 1992 şi s-a lansat sub sistemul de operare OS/2
şi Windows NT .
În 1993 Codd introduce termenul de OLAP şi cele 12 reguli referitoare la
sistemele OLAP. După ce a văzut Essbase, ca un exemplu de bază de date
multidimensională, a ajuns la concluzia că limbajul SQL nu a fost niciodată
adecvat pentru analiză multidimensională. El a afirmat că există o diferenţă
semnificativă între tehnologia sistemelor multidimensionale şi tehnologia sistemele
tranzacţionale [CODD93].
În 1994 apare primul instrument ROLAP, Microstrategy DSS Agent, fără
motor multidimensional. Toată procesarea era executată cu limbajul SQL (multi-
pass SQL), o tehnică utilizată foarte des pentru baze de date foarte mari .
În 1995 apare primul OLAP hibrid, HOLOS 4.0 ce permite accesul atât la baze
de date relaţionale cât şi multidimensionale. Multe din instrumentele OLAP
folosesc această arhitectură.
În 1995 Oracle achiziţionează Express. Ianuarie 1995 a marcat şi formarea
consiliului OLAP care a jucat un rol cheie în stabilirea sistemelor OLAP ca o
22
categorie de software mai bine înţeleasă şi cunoscută. După 8 luni de muncă, patru
fabricanţi de software au format consiliul OLAP (OLAP Council) cu scopul a
elimina confuziile şi de a face sistemele OLAP mult mai atrăgătoare pe piaţă, prin
stabilirea unor standarde deschise (OLAP API). Consiliul OLAP definea conceptul
de OLAP ca “o categorie de instrumente software, care permit analiştilor,
managerilor şi directorilor să înţeleagă esenţa datelor printr-un acces rapid,
consistent şi interactiv la o mare varietate de viziuni posibile ale informaţiilor,
care au fost obţinute prin tranformarea datelor primare astfel încât să reflecte
dimensiunile reale ale întreprinderii aşa cum o percepe şi o înţelege utilizatorul”.
În 1997 apare Microsoft OLEDB for OLAP, un standard OLAP API dezvoltat
de Microsoft, ca un set de obiecte COM şi interfeţe destinate a oferi acces la
sursele de date multidimensionale prin OLEDB. OLEDB for OLAP dezvoltă un
model pentru cuburi şi dimensiuni, oferă un limbaj MDX (multidimensional
expressions) pentru calcul şi vizualizare a cuburilor şi este utilizat de peste 40 de
firme.
În 1997 apare standardul MDIS (Metadata Interchange Specification) propus
de un grup de firme (IBM, Sybase, Informix) care oferă un mecanism standard de
acces şi o interfaţă standard pentru a gestiona metadatele.
În 1998 apare IBM DB2 OLAP Server, o versiune a lui Essbase, care utilizează
date stocate în baze de date relaţionale (schemă stea).
În 1999 apare Microsoft OLAP Services (numit iniţial Plato sau Decision
Support Services) ce utilizează o tehnologie achiziţionată de la Panorama Software
Systems şi cu o arhitectură de stocare complexă (ROLAP/MOLAP/HOLAP).
În 2000 Microsoft redenumeşte Microsoft OLAP Services ca Microsoft
Analysis Services.
În 2002 Oracle lansează Oracle9i Release 2 OLAP care integrează toate
facilităţile OLAP (Analytical Workspace) în baza de date relaţională Oracle.
Indiferent de tipul de arhitectură implementat, sistemele OLAP prezintă datele
la utilizator într-un model de date multidimensional, iar cererile sunt formulate
utilizând paradigma multidimensională. Începând cu 1995 cercetătorii, din diferite
domenii de aplicaţii, au propus o serie de modele multidimensionale şi limbaje de
interogare corespunzătoare. Multe din modelele propuse sunt extensii ale
modelului relaţional. De exemplu, Gray [GRAY96] propune operatorul CUBE care
generalizează clauza GROUP BY din limbajul SQL, o abordare foarte pragmatică,
potrivită pentru aplicaţiile OLAP. Modelul lui Li şi Wang [LIWA96] şi modelul lui
Gyssens şi Lakshmanan [GYSS97] constituie o extensie a algebrei relaţionale, iar
modelul lui Agrawal, Gupta şi Sarawagi [AGRA97] şi modelul lui Cabbibo şi
Torlone [CABB97] sunt modele orientate pe cub. Cele mai multe dintre ele sunt
modele de date logice şi numai câteva pot fi considerate pur conceptuale. Dar
fiecare model prezintă o viziune proprie a cerinţelor analizei multidimensionale, o
terminologie şi un formalism propriu.
23
Se poate afirma că la ora actuală nu există nici un model de date

multidimensional (conceptual şi formal) acceptat în unanimitate. Un astfel de
model este totuşi necesar pentru a servi ca o fundamentare pentru standardizare şi
cercetarea viitoare.
1.2.4.2 Relaţia între depozitele de date şi sistemele OLAP
Sistemele OLAP şi depozitele de date fac parte din categoria sistemelor suport
de decizie orientate pe date şi sunt similare. Totuşi depozitul de date pune accentul
pe procesele ce asigură consistenţa, corectitudinea şi valabilitatea datelor la
utilizatori, iar sistemele OLAP pun accentul pe cerinţele analitice şi procesele de
modelare şi calcul necesare. Bill Inmon părintele conceptului de data warehouse a
sugerat că scopul unui depozit de date este de a asigura consistenţa şi
corectitudinea datelor utilizate în întreprindere, accesibile utilizatorilor finali.
Valoarea unui depozit de date constă în calitatea informaţiilor livrate utilizatorului
final şi nu în cantitatea de date stocate în depozit. Aaron Zornes, un analist
proeminent, a numit depozitele de date monolitice “închisori de date” (data
jailhouses).
Tabelul 1.7 prezintă o analiză comparativă între datele operaţionale şi cele
necesare pentru suport decizional, realizată de Bill Inmon [INMO92], iar tabelul
1.8 prezintă o analiză comparativă între sistemele tranzacţionale şi sistemele
OLAP, realizată de Jeff Stamen, vicepreşedinte pentru Oracle OLAP Division
[THOM96], la care s-au adaugat şi alte criterii de comparare.
Tabelul 1.7
Analiză comparativă între datele operaţionale
şi datele necesare pentru suport decizional
Date operaţionale Date necesare pentru suport decizional

Detaliate Agregate
Curente Serii de timp
Destinate operatorilor Destinate managerilor
Repetitive Nerepetitive
Orientate pe aplicaţie Orientate pe subiect
Neredundante Redundante
Statice Dinamice
Suport pentru operaţii zilnice Suport strategic
24
Tabelul 1.8
Analiză comparativă între sistemele OLTP şi sistemele OLAP
Caracteristici Aplicaţie
Procesarea tranzacţională Procesarea
(OLTP) analitică (OLAP)
Volum de date pe mic mare
tranzacţie
Orientarea înregistrări atribute
Modul de afişare pe ecran nemodificabil definit de utilizator
Operaţii tipice actualizare analiză
Nivelul datelor detaliu agregate
Orizontul de timp curente istorice
Scopul operaţional analiză
Tip de acces citire/scriere citire/scriere
Structura datelor normalizată dimensională,
ierarhică
Investiţii hardware moderate la scumpe minime la moderate
Durata de implementare luni săptamâni/luni
Prin compararea tabelului 1.7 cu tabelul 1.8, se obţine o analiză comparativă

între depozitele de date şi sistemele OLAP (tabelul 1.9).
Tabelul 1.9
Analiză comparativă între depozitele de date (DW) şi sistemele OLAP
Caracteristici OLAP DW
Baza modelului atribute orientată pe subiect
Granulaţia datelor agregate agregate
Orizontul de timp istorice serii de timp
Redundanţa datelor redundante redundante
Volumul de date accesate pe cerere mare depinde de cerere
Caracteristici cerere analiza manageri, strategic
1.2.4.3 Regulile lui Codd
Termenul de OLAP a fost folosit prima dată în septembrie 1993 de către Codd,
în articolul “Providing OLAP (On-line Analytical Processing) to User-Analysts: An
IT Mandate”. Cele 12 reguli, mai târziu considerate ca facilităţi (caracteristici) ale
sistemelor OLAP au fost extinse la 18, în mai 1995 [CODD93]:
Caracteristici de bază
Regula 1: O viziune conceptuală multidimensională. Codd consideră că
viziunea utilizatorului asupra întreprinderii este multidimensională şi de aceea,
viziunea conceptuală a modelelor OLAP trebuie să fie, de asemenea,
25
multidimensională. La ora actuală puţine modele propuse sunt considerate modele

multidimensionale pur conceptuale şi anume: modelul lui Lehner [Leh98], modelul
lui Cabibbo şi Torlone [CABB98], modelul lui Golfarelli [GOLF98], modelul lui
Sapia şi Blaschka [BLAS99], modelul StarER [TRYF99] şi modelul MAC
[TSOI01]. Aceste modele încearcă să reprezinte modul cum utilizatorii percep un
cub multidimensional, fără să acorde o atenţie deosebită formalismului.
Regula 2: Manipularea intuitivă a datelor. Majoritatea modelelor

multidimensionale propuse permit operaţii de manipulare a datelor (operaţii de drill
down, drill up, drill across), iar multe din instrumentele OLAP, existente la ora
actuală pe piaţă, permit manipularea intuitivă a datelor (de exemplu: Express,
Essbase, Microsoft OLAP etc).
Regula 3: Accesibilitate. Sistemele OLAP trebuie să prezinte o singură viziune

logică a datelor din întreprindere. Sursele de date trebuie să fie transparente la
utilizator. Codd consideră că şi utilizatorii pot fi, de asemenea, o sursă de date.
Regula 4: Surse de date variate. Codd consideră că un sistem OLAP trebuie să

fie capabil să lucreze cu date stocate fie în baze de date multidimensionale
(MOLAP) cât şi în baze de date relaţionale (ROLAP). La ora actuală, o parte din
produsele OLAP îndeplinesc această regulă (de exemplu: Power Play, Oracle
Express, Pilot Analysis, Seagate Holos sunt sisteme OLAP hibride).
Sunt diferite arhitecturi pentru un sistem hibrid OLAP şi anume: integrarea
sistemelor MOLAP şi ROLAP printr-o interfaţă comună (de exemplu Seagate
Holos), integrarea mutuală a sistemelor ROLAP şi MOLAP (de exemplu Arbor
Essbase) şi extensii la SGBDR sau SGBDOR (de exemplu Informix cu opţiunea
Metacube).
Regula 5: Modele de analiză OLAP. Codd consideră că instrumentele OLAP

trebuie să suporte patru modele de analiză: explicativ, direct, contemplativ şi
formativ. Cu alte cuvinte instrumentele OLAP trebuie să permită cel puţin
realizarea rapoartelor parametrizate, analize de tip “ce se întâmplă dacă?”
(simulare) şi de “urmărire a unui scop“ (optimizare), operaţii de tip drill down, roll
up, slice şi dice.
Regula 6: Arhitectura client/server. Codd consideră că un sistem OLAP

trebuie să permită arhitectură client/server. Majoritatea instrumentelor OLAP
permit arhitectură client/server (de exemplu: Power Play, Oracle Express, Business
Object, DSS Microstrategy, Acumate, Informix Metacube, Microsoft OLAP etc) şi
chiar arhitectură pe trei niveluri (de exemplu: Business Objects, Informix
Metacube, DB2 OLAP etc).
26
Regula 7: Transparenţă. Sistemele OLAP trebuie să conţină interfeţe spre

diverse instrumente client (de exemplu instrumente de tip foaie de calcul tabelar) şi
să permită acces la tipuri de date eterogene. La ora actuală puţine instrumente
OLAP oferă transparenţă (de exemplu Acumate, Express).
Regula 8: Suport multiutilizator. Instrumentele OLAP trebuie să asigure acces

concurent, integritatea şi securitatea datelor. Sistemele ROLAP permit accesul
concurent la scriere, integrarea cu alte sisteme informatice relaţionale existente.
Puţine instrumente MOLAP (de exemplu Arbor Essbase) permit acces
multiutilizator concurent, atât la citire cât şi la scriere. Majoritatea instrumentelor
MOLAP permit acces multiutilizator la citire şi monoutilizator la scriere.
SGBDMD blochează întreagă bază de date în timpul actualizărilor (o formă foarte
simplă de acces concurent). De asemenea, multe instrumente MOLAP au o noţiune
foarte vagă a conceptului de tranzacţie. Modificările în cuburile de date pot fi
executate ca adăugări în cub sau în timpul analizei de tip “what if”. Adesea ele cer
o actualizare incrementală a agregatelor sau a măsurilor care sunt calculate pe bază
de formulă. Astfel de dependenţe fac actualizările mult mai complicate. Multe
sisteme MOLAP nu oferă facilitatea de recuperare a erorilor şi alte facilităţi
specifice sistemelor ROLAP.
Caracteristici speciale
Regula 9: Denormalizarea datelor. Codd sugerează că prelucrarea datelor într-
un mediu OLAP nu trebuie să afecteze datele externe ce servesc ca sursă.
Instrumentele OLAP sunt folosite pentru a procesa colecţii mari de date, actualizate
periodic, de aceea trebuie să aibă abilitatea de a stabili legături persistente cu
sursele externe de date, pentru a asigura sincronizarea între sursele externe şi
hypercub (cubul de date). Deoarece sistemele OLAP sunt în general separate de
sistemele sursă, legăturile servesc ca funcţii de transformare. Ele indică cum se
transformă datele din tabele sau foi de calcul tabelar în date multidimensionale.
Legăturile pot descrie relaţii structurale, atributele membrilor sau conţinutul
hypercuburilor. Legăturile pot fi unidirecţionale (de citire) sau bidirecţionale
(citire/scriere). Unele instrumente OLAP oferă suport pentru legături bidirecţionale
(de exemplu Essbase). Legăturile oferă o infrastructură persistentă pentru
importarea şi exportarea datelor şi a metadatelor. Ele variază în functie de tipul
informaţiei adusă în cub şi de tipul sursei de date, de la care informaţia este
obţinută.
Regula 10: Stocarea rezultatelor generate de instrumentul OLAP. Sistemele

OLAP trebuie să stocheze datele separat de sistemele tranzacţionale. Această
cerinţă apare ca urmare a diferenţelor ce există între datele operaţionale şi cele
destinate suportului decizional.
27
Regula 11: Manipularea valorilor lipsă. Valorile lipsă sunt diferite de valorile
zero şi cele invalide. Termenul de împrăştiere a fost utilizat cu semnificaţia de
valoare lipsă, valoare inaplicabilă şi valoare zero. Primele două cazuri sunt
considerate date invalide (conceptul de null). Codd sugerează că modelele OLAP
respectă regula privind valorile null, a modelului relaţional. Existenţa unui număr
mare de valori zero nu este totuşi un exemplu real de împrăştiere. Valoarea zero
este validă ca orice alt număr. Confuzia a apărut deoarece în aplicaţiile OLAP
apare un număr mare de valori zero, precum şi volume mari de date lipsă şi
invalide. Tehnicile pentru optimizarea fizică a stocării unui număr mare de valori
repetate sunt similare şi uneori aceleaşi cu tehnicile pentru optimizarea fizică a
stocării de volume mari de date lipsă şi invalide. Totuşi valorile lipsă şi cele
invalide nu sunt date valide. Ele nu pot fi tratate în acelaşi mod ca orice altă
valoare. De aceea, sunt necesare tehnici speciale pentru aceste cazuri. Tratamentul
impropriu al valorilor null poate cauza calcule incorecte. Acurateţea calculelor este
de o importanţă crucială pentru analiza oricărui set de date, indiferent că este sau
nu multidimensional. Problema tratării datelor împrăştiate este una foarte
importantă şi este frecvent dezbătută în domeniul bazelor de date. Cele două tipuri
de date (lipsă şi invalide) trebuie totuşi să fie tratate individual, deoarece ele
afectează calculele în moduri diferite.
Regula 12: Modul de tratare al valorilor lipsă. Valorile lipsă sunt ignorate de
instrumentul OLAP, indiferent de sursa lor.
Modul de prezentare al datelor
Regula 13: Flexibilitatea rapoartelor. Codd consideră că orice subset de
membri ai unei dimensiuni poate fi mapat la orice rând, coloană sau pagină a
ecranului de afişare. Cu alte cuvinte, aranjamentul axelor în raportare trebuie să fie
la libera alegere a utilizatorului.
Regula 14: Performanţa raportării. Codd sugerează că performanţa raportării
nu trebuie să varieze semnificativ cu numărul de dimensiuni sau mărimea bazei de
date. Principalii factori care afectează performanţa raportării sunt: modul cum sunt
realizate calculele (antecalculate sau la momentul interogării) şi locul unde sunt
procesate calculele (client/server). Aceşti factori sunt mai importanţi decât
mărimea bazei de date, numărul de dimensiuni sau complexitatea raportului.
Regula 15: Ajustarea automată a nivelului fizic. Codd cere sistemelor OLAP
să-şi modifice automat schema fizică a bazei de date, în funcţie de tipul modelului
logic şi de volumul datelor. Sistemele MOLAP nu au încă o tehnologie pentru
stocarea şi gestionarea datelor unanim acceptată. Stocarea fizică a datelor
multidimensionale, precum şi fenomenul de împrăştiere sunt preocupări majore în
domeniul bazelor de date multidimensionale. O tehnică de stocare a datelor optimă
trebuie să ţină cont de mulţi factori dinamici şi anume:
profilul datelor şi volumul lor (numărul de dimensiuni şi membrii ai
dimensiunilor, tipuri de date etc);
28
fenomenul de împrăştiere (în care dimensiuni sau combinaţii de

dimensiuni, tipul de împrăştiere);
frecvenţa de modificare în sursele de date (cât de des vor fi actualizate
bazele de date multidimensionale);
frecvenţa de modificare în datele multidimensionale (de exemplu pentru
analiza de tip “what if”);
frecvenţa de modificare în modelul multidimensional;
accesul concurent etc.
Ideal un sistem MOLAP ar trebui să aleagă structura de date optimă în funcţie
de aceşti factori. În cele mai multe sisteme MOLAP comerciale, se utilizează o
tehnică de stocare pe două niveluri: la nivelul inferior sunt stocate toate
dimensiunile dense, iar la nivelul superior dimensiunile împrăştiate ca o structură
index, care conţine pointeri la cuburile de date dense, din nivelul inferior.
Unele dintre instrumentele OLAP oferă administratorului un număr foarte
limitat de opţiuni de optimizare. De exemplu Arbor Essbase are o metodă proprie
pentru stocarea şi încărcarea datelor multidimensionale în memorie. Această
metodă utilizează o structură multinivel (cu un număr arbitrar de niveluri pentru
diferitele grade de împrăştiere). Administratorul poate specifica dimensiunile dense
şi împrăştiate. Oracle Express suportă, de asemenea, o structură pe două niveluri.
Pilot Decision Support Suite (Pilot Software) suportă aşa numitele multicuburi. Se
tratează timpul ca o dimensiune densă (toate celelalte dimensiuni sunt considerate
împrăştiate). Seagate Holos (Seagate Software) oferă structuri de date multiple, ce
pot fi combinate în aşa numita arhitectură OLAP compusă (Compound OLAP
Architecture).
Controlul dimensiunilor
Regula 16: Dimensionalitate generică. Codd consideră că dimensiunile
trebuie să fie echivalente structural şi operaţional. Cu alte cuvinte să permită
ierarhii multiple şi toate tipurile de operaţii multidimensionale şi în acelaşi timp să
poate fi actualizate (adăugarea/ştergerea unui membru, adăugarea/ştergerea unei
ierarhii, modificarea unui membru/ierarhie etc).
Regula 17: Dimensiuni şi niveluri de agregare nelimitate. Tehnic vorbind,

nici un produs software nu poate realiza acest lucru, pentru că nu se poate vorbi de
un lucru nelimitat pe un calculator cu resurse limitate. Puţine aplicaţii OLAP
necesită mai mult de 8 sau 10 dimensiuni şi puţine ierarhii conţin mai mult de 6
niveluri. Codd consideră că dacă ar trebui stabilit un număr maxim de dimensiuni,
acesta ar fi de 15-20 de dimensiuni. În practică există o multitudine de alte cerinţe
şi limitări ale instrumentelor OLAP, astfel încât problema numărului maxim de
dimensiuni poate fi pur şi simplu nesemnificativă.
Regula 18: Operaţii între dimensiuni nerestrictive. Limbajul de manipulare al

instrumentului OLAP trebuie să permită calcule şi manipularea datelor indiferent
de numărul de dimensiuni.
29
1.3 Sisteme informatice pentru inteligenţa afacerilor

În pagina Web a firmei IBM, conceptul de Business Intelligence (BI)
(inteligenţa afacerii) este definit astfel:
“BI înseamnă utilizarea tuturor datelor de care dispune o firmă, pentru a
îmbunătăţi procesul decizional. BI presupune accesul la date, analiza lor şi
descoperirea de noi oportunităţi de utilizare a lor.”
În climatul competiţional al zilelor noastre, este vital pentru organizaţii să ofere
acces rapid la informaţii, la costuri mici, pentru un număr cât mai mare şi mai
variat de utilizatori. Soluţia la această problemă este un sistem BI care oferă un set
de tehnologii şi produse software ce livrează utilizatorilor informaţiile necesare
pentru a răspunde la întrebările ce apar în rezolvarea problemelor de afaceri:
Nevoia de a creşte veniturile şi de a reduce costurile. S-au dus zilele când
utilizatorii finali puteau gestiona şi planifica activităţile utilizând rapoarte lunare şi
organizaţiile IT aveau mult timp la dispoziţie pentru a implementa noi aplicaţii.
Astăzi firmele trebuie să dispună rapid de aplicaţii, să ofere utilizatorilor acces
rapid şi uşor la informaţiile, ce reflectă schimbările mediului de afaceri. Sistemele
BI pun accentul pe accesul şi livrarea rapidă a informaţiilor la utilizatori.
Nevoia de a gestiona şi modela complexitatea mediului de afaceri curent. A
înţelege şi gestiona un mediu de afaceri complex şi a maximiza investiţiile devine
mult mai dificil. Sistemele BI oferă mai mult decât mecanisme de interogare şi
raportare, ele oferă instrumente de analiză a informaţiilor complexe şi de data
mining.
Nevoia de a reduce costurile IT. Astăzi, investiţia în sistemele informatice este
un procent semnificativ din cheltuielile firmelor şi nu este necesar numai să se
reducă aceste cheltuieli, dar de asemenea, să se obţină beneficii maxime de la
informaţiile gestionate de sistemele IT. Noile tehnologii informatice ca Intranetul şi
arhitectura pe trei niveluri, reduc costul de utilizare a sistemelor BI de către o mare
varietate de utilizatori, în special manageri.
În cele ce urmează, se va prezenta evoluţia sistemelor informatice pentru
inteligenţa afacerii:
Primele sisteme informatice pentru afaceri foloseau aplicaţii a căror ieşiri
implicau volume uriaşe de hârtie, pe care utilizatorii trebuiau să le citească, pentru
a obţine răspunsurile dorite. Aplicaţiile client/server cu clienţi de tip terminal
permiteau un acces mai rapid la date, dar erau totuşi greu de utilizat şi cereau acces
la baze de date operaţionale complexe. Aceste sisteme informatice pentru afaceri
erau folosite numai de analişti. Managerii şi directorii executivi puteau foarte rar să
utilizeze aceste sisteme.
A doua generaţie de sisteme informatice pentru afaceri a apărut odată cu
depozitele de date, care au o serie de avantaje faţă de sistemele din prima generaţie:
depozitele de date sunt proiectate pentru a satisface nevoile managerilor şi
nu a aplicaţiilor tranzacţionale;
30
informaţia din depozitele de date este curată, consistentă şi este stocată

într-o formă pe care managerii o înţeleg;
spre deosebire de sistemele operaţionale, care conţin numai date de detaliu
curente, depozitele pot furniza atât informaţii istorice cât şi agregate;
utilizarea unei arhitecturi client/server oferă utilizatorilor de depozite de
date interfeţe îmbunătăţite şi instrumente suport de decizie mai puternice.
A treia generaţie: BI. Un depozit de date nu este totuşi o soluţie completă
pentru nevoile managerilor. Un punct slab al soluţiilor ce folosesc depozitele de
date este că specialiştii pun accentul pe tehnologie şi mai puţin pe soluţii
manageriale (business solutions). Deşi producătorii de depozite de date oferă
instrumente puternice pentru construirea şi accesarea unui depozit de date, aceste
instrumente cer un volum semnificativ de muncă pentru implementare. De
asemenea, se pune prea mult accent pe procesul de construire a depozitului şi mai
puţin pe accesul la datele din depozit. Multe organizaţii consideră că dacă
construiesc un depozit de date şi oferă utilizatorilor instrumente corecte, problema
este rezolvată. De fapt este tocmai începutul. Deşi informaţia din depozit este
complet documentată şi uşor de accesat, complexitatea va limita utilizarea
depozitului de către manageri, principalii beneficiari. Sistemele pentru inteligenţa
afacerii pun accentul pe îmbunătăţirea accesului şi livrării de informaţii utile atât la
consumatorii de informaţii cât şi la cei care oferă informaţii. Un sistem informatic
pentru inteligenţa afacerii trebuie să ofere scalabilitate şi să fie capabil să suporte şi
să integreze instrumente software de la mai mulţi fabricanţi. Un depozit de date
este una din sursele de date ale unui sistem BI. De asemenea, există un volum mare
de informaţii pe serverele de Web ale Intranetului, pe Internet şi în format de
hârtie. Sistemele informatice pentru inteligenţa afacerilor sunt proiectate pentru a
permite acces la toate formele de informaţii, nu numai cele stocate într-un depozit
de date.
Într-o firmă se colectează volume mari de date în tranzacţiile zilnice: date
despre comenzi, stocuri, facturi, vânzări, clienţi etc. De asemenea, firmele au
nevoie şi de informaţii externe (de exemplu informaţii demografice). A fi capabil
să consolidezi şi să analizezi aceste date poate conduce adesea la un avantaj
competiţional (creşterea vânzărilor, reducerea costurilor de producţie,
îmbunătăţirea activităţii de desfacere, descoperirea unor noi surse de venit etc).
Toate acestea sunt posibile dacă există aplicaţii corespunzătoare şi instrumente
necesare pentru a analiza datele şi dacă datele sunt într-un format corespunzător
pentru analiză.
În concluzie, un sistem BI are trei avantaje cheie:
include în arhitectura sa cele mai avansate tehnologii informatice;
pune accentul pe accesul şi livrarea de informaţii la utilizatorii finali şi
oferă suport atât pentru specialişti cât şi pentru utilizatorii finali;
permite acces la toate formele de informaţii, nu numai cele stocate într-un
depozit de date.
31
Principalele obiective ale unui sistem BI sunt:

să permită soluţii cu costuri scăzute ce oferă avantaje firmei;
să permită acces rapid şi uşor la informaţiile firmei pentru un număr mare
şi variat de utilizatori ;
să ofere suport pentru tehnologiile moderne (tehnici de analiză complexe-
instrumente OLAP, instrumente de tip data mining etc);
să ofere un mediu de operare deschis şi scalabil.
Observăm că sistemele informatice pentru inteligenţa afacerilor sunt de fapt
sisteme suport de decizie moderne la nivel de organizaţie, care utilizează noile
tehnologii informatice. Termenul de sistem informatic pentru inteligenţa afacerilor
este de fapt un termen “umbrelă” utilizat de specialişti pentru o categorie mai vastă
de sisteme suport de decizie, ce integrează toate facilităţile oferite de depozitele de
date, instrumentele OLAP, instrumentele data mining, Web-ul etc. În funcţie de
complexitatea procesului decizional la nivel de organizaţie, de numărul de
utilizatori, de cerinţele organizaţiei, de volumul de informaţii necesare procesului
decizional şi de alţi mulţi factori, sistemele suport de decizie moderne vor utiliza şi
vor integra una sau mai multe din noile tehnologii informatice actuale. Dacă se
utilizează depozite de date/centre de date şi instrumente de interogare şi raportare
atunci avem un sistem suport de decizie cu depozite de date. Dacă se integrează
depozitele de date cu instrumentele OLAP se obţin aşa numitele sisteme ROLAP,
iar dacă se utilizează şi facilităţile oferite de Web se obţin sistemele suport de
decizie orientate pe Web (figura 1.2).
Multe firme preferă să construiască un sistem separat pentru aplicaţii BI fie
din motive de securitate, fie din motive de performanţă ale sistemelor operaţionale.
Moduri de stocare a BI (∀ tip de dată+∀ tip de analiză) Tehnici de

datelor analiză a datelor
SSD hibride orientate pe Data mining
Depozit de date /
cunoştinţe şi date
centru de date
SSD cu depozite de date Cerere
BDMD Sisteme ROLAP

OLAP
Sisteme MOLAP
Alte stocuri
de informaţii
SSD orientat pe Web
Web, Internet/Intranet
Figura 1.2 Influenţa noilor tehnologii informatice în evoluţia sistemelor suport

de decizie moderne
32
La ora actuală există o gamă variată de instrumente şi metodologii valabile

pentru a dezvolta soluţii BI :
Aplicaţii cum ar fi IBM’s DecisionEdge pentru managementul relaţiilor cu
clienţii, Oracle Sales Analyzer pentru analiza activităţii de marketing,
Oracle Financial Analyzer pentru analiza activităţii financiare etc;
Instrumente pentru interogări cum ar fi Power Play-Cognos, Business
Objects-Business Objects, IBM’s Query Management Facility etc;
Instrumente OLAP cum ar fi Essbase-Arbor Software, Express Analyzer,
Express Objects-Oracle etc;
Instrumente pentru analiză statistică cum ar fi SAS System-SAS Institute,
etc;
Instrumente pentru data mining cum ar fi IBM’s Intelligent Miner.
Multe din aceste aplicaţii şi instrumente au facilităţi Web. În figura 1.3 este
prezentată arhitectura unui sistem informatic pentru inteligenţa afacerilor sau a
unui sistem suport de decizie modern la nivel de organizaţie.
Aplicaţii pentru inteligenţa afacerilor
Instrumente suport de decizie

Cerere şi raportare OLAP data mining
Gestiunea metadatelor
Accesul
interfeţele aplicaţiilor servere de aplicaţii
administrare
Gestiunea datelor
Depozit Centre de Alte
central date stocuri de
informaţii
Instrumente pentru construirea şi modelarea depozitelor

de date
Date externe şi operaţionale
Figura 1.3 Arhitectura unui sistem informatic pentru inteligenţa afacerilor
33
Rezumat
Un SSD este “un sistem informatic interactiv, flexibil şi adaptabil, special
proiectat pentru a oferi suport în soluţionarea unor probleme manageriale
nestructurate sau semistructurate, cu scopul de a îmbunătăţi procesul decizional.
Sistemul utilizează date (interne şi externe) şi modele, oferă o interfaţă simplă şi
uşor de utilizat, permite decidentului să controleze procesul decizional şi oferă
suport pentru toate etapele procesului decizional”.
Power propune o nouă clasificare (la nivel conceptual) a SSD-urilor în: SSD-
uri orientate pe comunicaţie, SSD-uri orientate pe date, SSD-uri orientate pe
documente, SSD-uri orientate pe cunoştinţe şi SSD-uri orientate pe modele.
Un SSDOD este un sistem informatic interactiv care-i ajută pe manageri să
utilizeze baze de date de dimensiuni foarte mari ce conţin date preluate din surse
interne şi externe ale organizaţiilor.
Principalele categorii de sisteme suport de decizie orientate pe date sunt:
sistemele informatice executive, sistemele suport de decizie spaţiale, sistemele
suport de decizie care utilizează depozite de date, sistemele OLAP.
Sistemele informatice executive sunt sisteme suport de decizie la nivel de
întreprindere care îi ajută pe manageri să analizeze, să compare şi să pună în
evidenţă tendinţele, să monitorizeze performanţele şi să identifice oportunităţile şi
problemele cu care se confruntă organizaţia.
Sistemele suport de decizie spaţiale îi ajută pe manageri să acceseze, afişeze şi
analizeze datele care au conţinut geografic şi-au aplicabilitate în domenii ca
geologie, industria forestieră, agricultură.
Depozitul de date este „o colecţie de date orientată pe subiect, integrată,
dependentă de timp şi nevolatilă, destinată pentru a susţine procesul decizional
dintr-o organizaţie.”
Sistemele OLAP reprezintă o categorie importantă de sisteme suport de decizie
orientate pe date.
Principalele obiective ale sistemelor OLAP sunt: access rapid şi calcule
rapide, facilităţi analitice puternice (analize ad-hoc foarte rapide), interfaţă
prietenoasă şi prezentări flexibile, permit prelucrarea unor volume mari de date
(1-500 Gb), cu multe niveluri de detaliu, în mediu multiutilizator.
Consiliul OLAP definea conceptul de OLAP ca “o categorie de instrumente
software, care permit analiştilor, managerilor şi directorilor să înţeleagă esenţa
datelor printr-un acces rapid, consistent şi interactiv la o mare varietate de viziuni
posibile ale informaţiilor, care au fost obţinute prin tranformarea datelor primare
astfel încât să reflecte dimensiunile reale ale întreprinderii aşa cum o percepe şi o
înţelege utilizatorul”.
Termenul de OLAP a fost folosit prima dată în septembrie 1993 de către Codd,
în articolul “Providing OLAP (On-line Analytical Processing) to User-Analysts:
An IT Mandate”, care a şi propus 18 reguli, mai târziu considerate ca facilităţi
(caracteristici) ale sistemelor OLAP.
34
Cele mai comune domenii de aplicaţii pentru sistemele OLAP sunt analiza şi
modelarea financiară, cercetarea şi analiza pieţei. Singurul principiu arhitectural
ce caracterizează sistemele OLAP este multidimensionalitatea.
Sistemele informatice pentru inteligenţa afacerilor sunt de fapt sisteme suport
de decizie moderne la nivel de organizaţie, care utilizează noile tehnologii
informatice. Termenul de sistem informatic pentru inteligenţa afacerilor este de
fapt un termen “umbrelă” utilizat de specialişti pentru o categorie mai vastă de
sisteme suport de decizie ce integrează toate facilităţile oferite de depozitele de
date, instrumentele OLAP, instrumentele data mining, Web-ul etc.
Cuvinte cheie
Sisteme suport de decizie, sisteme suport de decizie orientate pe date, sisteme
suport de decizie orientate pe Web, sisteme informatice executive, depozite de date,
sisteme OLAP, sisteme informatice pentru inteligenţa afacerilor, sisteme suport de
decizie spaţiale, centre de date.
35
Capitolul 2
Modele de date multidimensionale
pentru sisteme OLAP
Economia din zilele noastre este caracterizată de o creştere substanţială a
competiţiei între întreprinderi. Pentru a face faţă acestei competiţii acerbe,
managerii trebuie să ia decizii strategice corecte, bazate pe informaţii reale. Astfel,
informaţia devine un factor de producţie esenţial. Factorii care au condus la aceasta
situaţie sunt: creşterea complexităţii structurii întreprinderilor, a relaţiilor între
firme, crearea de noi procese de afaceri, redirecţionarea proceselor de afaceri
existente către client, globalizarea pieţelor, clienţilor şi întreprinderilor şi apariţia
de noi tehnologii cum ar fi Internetul sau comerţul electronic.
Instrumentele OLAP sunt utilizate frecvent în sistemele suport de decizie,
deoarece permit analiza interactivă a datelor multidimensionale. Avantajul lor
principal este că sunt apropiate de modul de gândire al analiştilor şi îmbunătăţesc
performanţa execuţiei cererilor. În consecinţă, tehnologia bazelor de date
multidimensionale a câştigat, în ultima perioadă, multă atenţie din partea firmelor
producătoare şi a cercetătorilor. Indiferent de tipul de arhitectură implementat,
instrumentele OLAP prezintă datele la utilizator într-un model de date
multidimensional, iar cererile sunt formulate utilizând paradigma
multidimensională. Totuşi multe din produsele OLAP existente au o serie de
limitări:
nu oferă un limbaj de interogare similar cu limbajul SQL;
tratează dimensiunile şi măsurile asimetric;
nu există un model conceptual unanim acceptat pentru bazele de date
multidimensionale.
Modelarea multidimensională este o tehnică de modelare conceptuală folosită
de aplicaţiile OLAP. Totuşi modelarea datelor multidimensionale nu este o
problemă specifică sistemelor OLAP. Bazele de date statistice, bazele de date
geografice şi cele temporale au legătură cu datele multidimensionale. Modelele de
date propuse în domeniul bazelor de date statistice, spaţiale, temporale au multe
puncte comune cu modele de date OLAP. De exemplu, în bazele de date temporale
rândurile şi coloanele unei tabele relaţionale sunt vizualizate ca două dimensiuni,
iar timpul apare ca a treia dimensiune, formând ceea ce se numeşte cubul timpului
36
Modele de date multidimensionale pentru sisteme OLAP
(time cube). Acest cub este diferit de cubul multidimensional propus de Agrawal,
unde toate dimensiunile sunt tratate uniform. Eforturile de modelare în bazele de
date spaţiale sunt concentrate pe reprezentarea obiectelor geometrice (puncte, linii,
poligoane, regiuni etc) în spaţiul multidimensional. Datele OLAP pot fi vizualizate
ca puncte în spaţiul multidimensional al atributelor. Totuşi operaţiile specifice
bazelor de date spaţiale sunt diferite de operaţiile OLAP. Domeniul cel mai
apropiat de depozitele de date şi sistemele OLAP este domeniul bazelor de date
statistice, unde o serie de modele multidimensionale au fost propuse [SHOS97].
Aceste modele au fost propuse înainte de apariţia termenului de OLAP şi sunt în
principal extensii ale modelelor de date existente (de regula relaţionale). În bazele
de date statistice, dimensiunile şi măsurile sunt tratate diferit. De exemplu, în
[RAFA93] este prezentat un model funcţional “Mefisto” bazat pe definiţia unei
structuri de date numită entitate statistică (statistical entity) şi un set de operatori
(agregare, restricţie etc).
Multe firme utilizează şi dezvoltă propriile modele de date multidimensionale.
De asemenea, diferite comitete de standardizare au definit propriile modele
[META97], [OLAP97], [TPCB99]. Multe dintre ele sunt modele de date logice şi
numai câteva pot fi considerate pur conceptuale. De asemenea, cercetătorii din
diferite domenii de aplicaţii au propus o serie de modele multidimensionale
formale şi limbaje de interogare corespunzătoare. Dar fiecare model prezintă o
viziune proprie a cerinţelor analizei multidimensionale, o terminologie şi un
formalism propriu. La ora actuală nu există nici un model de date multidimensional
(conceptual şi formal) acceptat în unanimitate.
2.1 Concepte de bază
Pentru a descrie în detaliu modelele de date multidimensionale (extensii ale

modelului relaţional sau orientate pe cub) şi a putea fi înţelese, s-a considerat
necesar a se prezenta o serie de concepte utilizate şi anume: hypercubul (cub n-
dimensional), multicubul, dimensiunile, ierarhiile, măsurile şi fenomenul de
împrăştiere. Aceste concepte apar în majoritatea modelelor OLAP, deşi modul lor
de definire diferă uneori foarte mult. De asemenea, consiliul OLAP a propus un
glosar de termeni care se doreşte standardizat. De aceea, în prezentarea acestor
concepte de bază s-au utilizat şi definiţiile date de Consiliul OLAP.
2.1.1 Conceptul de cub n-dimensional
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 modelului multidimensional. Instrumentele OLAP folosesc
conceptul de hypercub în acelaşi mod în care foile de calcul tabelar folosesc
conceptul de foaie de lucru (worksheet) şi bazele de date relaţionale conceptul de
37
tabelă. Toate vizualizările, rapoartele şi analizele sunt făcute în termeni de

hypercuburi (cuburi n-dimensionale).
Consiliul OLAP defineşte hypercubul ca „un grup de celule de date aranjate
după dimensiunile datelor. De exemplu, o foaie de calcul tabelar exemplifică o
matrice bidimensională cu celulele de date aranjate în rânduri şi coloane, fiecare
fiind o dimensiune. O matrice tridimensională poate fi vizualizată ca un cub cu
fiecare dimensiune formând o faţă a cubului. Dimensiunile tipice ale datelor dintr-
o întreprindere sunt timpul, măsurile, produsele, regiunile geografice, canalele de
distribuţie etc.” [OLAP97]
Pentru a înţelege conceptul de hypercub (cub n-dimensional) trebuie să ţinem
cont de următoarele aspecte:
Afişarea pe ecranul calculatorului nu este identică cu metaforele vizuale. Se
consideră un exemplu de date bidimensionale şi anume informaţiile despre
vânzările lunare (cantitatea vândută) de telefoane mobile Nokia ale unei firme.
Exemplul poate fi realizat foarte uşor cu ajutorul unei foi de calcul tabelar şi afişat
pe orice ecran (tabelul 2.1).
Tabelul 2.1
Vânzările lunare ale unei firme
Luni Vânzări
Ianuarie 790
Februarie 850
Martie 900
Aprilie 910
….. ……
Decembrie 810
Total 10180
Totalul vânzărilor este afişat pe ultimul rând. Este o singură coloană de date:
coloana Vânzări. Setul de date are două dimensiuni: o dimensiune Luna aranjată pe
rânduri şi o dimensiune Vânzări aranjată pe coloane. Lunile reprezintă modul cum
sunt organizate datele. Lunile sunt un tip de cheie sau identificator. În concluzie,
modelul prezentat are două dimensiuni: o dimensiune de identificare şi una pentru
variabile. În figura 2.1 variabila “cantitatea vândută” este determinată în funcţie de
trei dimensiuni: Locaţie, Produs şi Timp. Dimensiunea Locaţie include o ierarhie
cu două niveluri “judeţ” şi “oraş”, iar dimensiunea Produs ierarhia cu nivelurile
“produs” şi “model produs”. Deşi nu se reprezintă în figură, dimensiunea Timp se
referă la anul 2003. Fiecare subcub conţine cantitatea vândută pentru o anumită
combinaţie de valori ale dimensiunilor. De exemplu, într-o anumită perioadă de
timp, în oraşul Deva, din judeţul Hunedoara, s-au vândut 10 telefoane celulare,
model Nokia 3410.
Ecranul calculatorului, la fel ca o hârtie, are numai două dimensiuni fizice.
Putem crea o reprezentare bidimensională pe ecran a unui cub tridimensional.
Afişarea datelor pe ecranul bidimensional al calculatorului este diferită de
38
metaforele folosite pentru a vizualiza datele. Cubul vizualizat în figura 2.1 este o
metaforă vizuală. Acest aspect îi face pe dezvoltatorii de software să caute un mod
optim de reprezentare a structurilor numerice cu mai mult de două dimensiuni pe
un ecran bidimensional, pentru vizualizare şi manipulare. De exemplu, în cazul
foilor de calcul tabelar tridimensionale, setul de date tridimensional din figura 2.1
este afişat pe ecran, pe rânduri, coloane şi pagini. Este uşor de a vizualiza relaţia
între datele prezentate pe ecran şi întregul set de date stocat în calculator. Tot ce
trebuie să facem este să ne imaginam un cub de date tridimensional şi un ecran ce
afişează o felie din acel cub.
dimensiunea Locaţie variabila (cantitatea vândută)

Ierarhia:
Judeţ, Oraş
Hune Hune
doara doara
Deva
10 22 10 29 21 9
Bacău Bacău
2 21 12 34 22 8
Piatra
Neamţ
3410 3310 6100 8100
Nokia
Membru dimensiunea Produs (ierarhia: produs, model produs)
Figura 2.1 Reprezentarea sub forma unui cub a modelului multidimensional
Dimensiunile logice nu sunt identice cu dimensiunile fizice. Cuburile studiate

la geometrie sunt implicit fizice, deoarece se bazează pe noţiuni fizice ca lungime,
lăţime şi înălţime. Cele trei axe perpendiculare (x, y, z) se transformă perfect în
dimensiuni fizice ca lungime, lăţime şi înălţime. Cubul fizic este o reprezentare
intuitivă a unui eveniment, deoarece toate dimensiunile coexistă pentru orice punct
din cub şi sunt independente între ele. Într-un spaţiu tridimensional, orice punct
(orice vânzare) este identificat de coordonatele sale x, y şi z (sau de produs, timp şi
locaţie). Totuşi fizic sunt numai trei dimensiuni independente. Chiar dacă nu este
greşit de a folosi un cub cu unghiuri drepte pentru reprezentarea multidimensională
a unui eveniment, definiţia bazată pe unghi drept a unei dimensiuni nu este
necesară pentru reprezentarea evenimentului. O reprezentare corectă cere
dimensiuni independente [THOM96].
Erik Thomsen [THOM96] utilizează pentru reprezentarea evenimentelor un
nou concept: “structură de domeniu multidimensională” (multidimensional domain
structure-MDS) (figura 2.2). Fiecare dimensiune este reprezentată printr-un
segment vertical. Orice membru dintr-o dimensiune este reprezentat de un interval
39
din segment. Pentru exemplu tridimensional anterior, se identifică patru segmente:

unul pentru timp, unul pentru produse, unul pentru locaţie şi unul pentru variabile.
Fiecărui element din eveniment şi din cub îi corespunde un interval din fiecare din
cele patru segmente. De exemplu, în figura 2.2, MDS prezintă vânzările de
telefoane mobile Nokia din luna martie. Un MDS este mai descriptiv decât un cub
fizic, totuşi nu arată punctele de date curente, ci combinaţii posibile ale membrilor
dimensiunilor. Utilizând un MDS este uşor de a adăuga alte dimensiuni la model.
Un MDS nu este o reprezentare fotografică a evenimentului ce a generat datele, dar
nu este nici cub fizic. Un MDS:
arată numărul de puncte de date extrase din eveniment şi organizarea lor
logică;
prezintă toate dimensiunile care se pot vizualiza;
arată mai multe informaţii structurale decât un cub fizic;
şi poate fi realizat pentru orice număr de dimensiuni.
Dimensiunile logice pot fi combinate. Cum se pot reprezenta patru sau mai
multe dimensiuni logice în trei dimensiuni fizice (rând, coloană, pagină)?
Răspunsul este de a combina multiple dimensiuni logice în aceeaşi dimensiune
fizică. Maparea a două dimensiuni logice într-o singură dimensiune fizică
înseamnă crearea unei versiuni unidimensionale. Metoda tipică este de a include o
dimensiune în alta. Două lucruri se modifică ca rezultat al combinării
dimensiunilor : forma datelor prezentate şi vecinii.
Evenimentul ce generează datele MDS cubul de date

Timp Produse Variabile
Vânzări (buc) Martie
Nokia
telefoane mobile Nokia
vânzări
martie
Figura 2.2 Exemplu de utilizare a MDS-ului pentru reprezentarea evenimentelor
Într-o matrice bidimensională, fiecare punct are patru vecini. Când

dimensiunile sunt combinate fiecare punct într-o listă unidimensională are numai
doi vecini. Un lucru important nu se modifică în timpul procesului de combinare a
dimensiunilor logice: nu are importanţă cum se combină dimensiunile, rezultatele
sunt aceleaşi. Abilitatea de a modifica uşor prezentările aceloraşi date, prin
reconfigurarea a cum sunt afişate dimensiunile, este una din cele mai mari avantaje
40
ale sistemelor OLAP. Se separă structura datelor reprezentată în MDS, de afişarea

datelor. Orice combinaţie de dimensiuni logice poate fi mapată la orice combinaţie
de rânduri, coloane şi pagini ale unui ecran.
2.1.2 Conceptul de dimensiune
Conceptul de dimensiune este definit de Consiliul OLAP ca “un atribut

structural al unui cub ce constă dintr-o listă de membrii, pe care utilizatorii îi
percepe ca fiind de acelaşi tip. De exemplu, toate lunile, trimestrele, anii formează
dimensiunea Timp….. O dimensiune acţionează ca un index pentru identificarea
valorilor dintr-o matrice multidimensională..…..Dimensiunile oferă un mod foarte
concis, intuitiv de organizare şi selectare a datelor pentru explorare şi analiză.”
[OLAP97]
Dimensiunile sunt atribute de identificare a evenimentelor măsurabile sau a
lucrurilor pe care le analizăm. Spre deosebire de dimensiunile fizice care sunt
bazate pe unghiuri şi sunt limitate la trei, dimensiunile logice nu au astfel de limite.
Frecvent numărul de dimensiuni într-un set de date depăşeşte cele trei dimensiuni
fizice (rând, coloană, pagină) ale ecranului de afişare. Abilitatea instrumentului
OLAP de a modela multiple dimensiuni de informaţii îl face mult mai potrivit
pentru a lucra cu seturi complexe de date, decât bazele de date relaţionale şi foile
de calcul tabelar. Dimensiunile au următoarele caracteristici:
furnizează informaţii descriptive despre fiecare indicator (variabilă);
conţin în general date statice şi sunt esenţiale pentru analiză. Un model
multidimensional ce oferă un număr mare de atribute dimensionale permite
analize cât mai complexe şi mai variate;
într-un cub n-dimensional o dimensiune este reprezentată printr-o axă;
într-o schemă stea sunt tabelele care se dispun radial în jurul tabelei de
fapte şi se mai numesc tabele de dimensiuni.
De exemplu, într-o bază de date pentru analiza vânzărilor se identifică
următoarele dimensiuni: Timp, Regiune/locaţie, Client, Agent de vânzare, Produs.
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 (independent). De exemplu, în
dimensiunea Produs membru “culoare” nu este inclus în nici o ierarhie.
41
2.1.3 Conceptul de ierarhie
O ierarhie este un atribut al unei dimensiuni. Cele mai multe dimensiuni au o

structură multi-nivel sau ierarhică. Timpul este o dimensiune ierarhică multi-nivel
(ore, zile, săptămâni, luni, trimestre şi ani), Locaţia geografică este o dimensiune
ierarhică (vecini, oraşe, state şi ţări). În cele mai multe activităţi ale unei firme,
ierarhiile sunt o necesitate. Ar fi imposibil de a funcţiona o firmă, dacă toate datele
sale ar fi limitate la nivel tranzacţional. De exemplu, este necesar de a păstra
informaţii despre volumul vânzărilor lunare, pe trimestru, pe an, pentru a vedea
care produse se vând mai bine şi care mai prost. Criteriile după care datele sunt
agregate pentru analiză şi raportare trebuie să fie aceleaşi cu factorii folosiţi în
procesul decizional. În figura 2.3 este prezentată o ierarhie de produse.
Toate produsele
cosmetice electronice
sapun şampon parfum acasă birou
radio casetofon
TV fax xerox
cu baterii electric
Figura 2.3 O ierarhie de produse

Elementele individuale sau nodurile sunt numite membri (de exemplu:
cosmetice, echipamente de birou etc). Cei mai mulţi membri au conexiuni în sus şi
jos, în ierarhie. Conexiunile în sus sunt de tip (m:1) şi sunt numite asocieri părinte.
Conexiunile în jos sunt de tip (1:m) şi sunt numite asocieri copil. De exemplu,
echipamentele electronice sunt părinţi pentru echipamentele de birou. Faxurile şi
xerox-urile sunt copii pentru echipamentele de birou. În general, un membru poate
avea un singur părinte. Un membru ce nu are părinte se numeşte membru rădăcină
(root). În figura 2.3 membru Toate Produsele este rădacină în ierarhia de produse.
Membrii ce nu au copii sunt numiţi frunză (de exemplu radio casetofoane cu baterii
etc).
42
Pentru a identifica poziţia unui membru într-o dimensiune se folosesc

conceptele de înălţime şi adâncime în ierarhie. Înălţimea se stabileşte de jos în sus.
Din acest motiv nivelul (L0) al ierarhiei reprezintă nodurile frunză ale ierarhiei
(înălţimea cea mai mică). Adâncimea în ierarhie este stabilită de sus în jos. Există
posibilitatea ca doi membri, care au aceeaşi înălţime, să aibă adâncimi diferite şi
invers (structuri arborescente neechilibrate). Structurile arborescente neechilibrate
sunt implementate cu succes în bazele de date multidimensionale, bazele de date
relaţionale fiind necorespunzătoare.
Ierarhiile dimensionale pot fi simetrice sau asimetrice (figura 2.4). În
dimensiunea Timp există o ierarhie simetrică. Cu ierarhiile simetrice se pot referi
membrii prin nivelul lor ierarhic.
Î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”.
Produsele se pot grupa şi în alte moduri decât cosmetice şi electronice. De
exemplu, preţul reprezintă un alt criteriu pentru organizarea dimensiunii Produs
(de exemplu: solduri, specifice, de lux). Cu alte cuvinte, într-o dimensiune pot
exista mai multe ierarhii. Alegerea nivelurilor intermediare de grupare sau agregare
este importantă pentru înţelegerea şi abilitatea de a lua decizii, deoarece datele au
numai un nivel de detaliu, un nivel de agregare complet, dar multe niveluri
intermediare. Aşa cum arată figura 2.5, fiecare direcţie de agregare scoate în
evidenţă unii factori şi-i ascunde pe alţii [THOM96]. Numărul de niveluri
intermediare, cum ar fi grupuri de produse după preţ, grupuri de produse după
profit, după tipul produsului şi producător, permite să experimentăm diferite
moduri de a privi şi înţelege datele. Aceasta este una din ariile de convergenţă între
structurile multidimensionale şi analiza statistică.
an
Trim1 Trim2 Trim3 Trim4
L L L L L L L L L L L L
Figura 2.4 Ierarhie simetrică

Ierarhiile sunt fundamentul pentru agregarea datelor şi pentru navigarea între
nivelurile de detaliu dintr-un cub n-dimensional. Deşi nu toate dimensiunile conţin
ierarhii, toate aplicaţiile din lumea reală implică dimensiuni ierarhice. Numărul de
ierarhii distincte într-o structură multidimensională este egal cu produsul dintre
numărul de ierarhii din fiecare dimensiune. De exemplu, dacă sunt trei ierarhii în
43
dimensiunea Timp, trei ierarhii în dimensiunea Locaţie, patru ierarhii în

dimensiunea Produs şi o singură variabilă ar putea fi 3*3*4*1=36 ierarhii distincte.
Unele instrumente OLAP permit numai o singură ierarhie pe dimensiune. În
acest caz, fiecare ierarhie este tratată ca o dimensiune separată.
Combinaţia de multiple dimensiuni şi multiple niveluri pe dimensiune
constituie esenţa unui cub n-dimensional sau hypercub.
O celulă într-un cub n-dimensional este definită de intersecţia unui membru din
fiecare dimensiune. Unele celule conţin date de intrare cum ar fi vânzările zilnice,
altele conţin date derivate. Valorile datelor derivate sunt definite cu ajutorul
formulelor. Cu cât sunt mai multe dimensiuni şi ierarhii în cub, cu atât este mai
complexă vecinătatea din jurul unei celule şi există mai multe direcţii după care se
pot vizualiza datele. Într-un cub n-dimensional (cu un nivel ierahic pe dimensiune),
fiecare celulă are 2n vecini imediaţi sau direcţii de vizualizare. De exemplu, o
celulă într-o foaie de calcul tabelar are patru vecini (4 celule adiacente), iar o celulă
într-un cub tridimensional are şase. Când se adaugă ierarhii, numărul de direcţii de
vizualizare creşte.
Toată compania
Domenii de activitate Regiuni
Diviziuni Oraşe
Departamente
Figura 2.5 Agregarea datelor dintr-o dimensiune

Ce tip de date pot fi stocate într-un cub n-dimensional? Deşi majoritatea
datelor stocate în cuburile n-dimensionale sunt numerice, orice tip de date de la
text la grafice şi chiar sunete pot fi multidimensionale. Multe instrumente OLAP
oferă abilitatea de a popula cuburile n-dimensionale cu date text. Datele numerice
sunt mai potrivite pentru aplicaţiile OLAP, deoarece au o organizare
multidimensională şi se pot agrega. Alte tipuri de date pot beneficia de organizarea
multidimensională, dar apar probleme datorate agregării lor. Totuşi cele mai multe
date sursă, la nivel de întreprindere, sunt de tip caracter. Din acest motiv, datele de
tip şir de caractere vor deveni mult mai importante pentru instrumentele OLAP.
44
Date cum ar fi: culoarea, adresa, tipul de ambalaj, tipul de client sunt factori
esenţiali pentru analiză.
Conceptul de nivel într-o ierarhie este foarte important pentru a determina ce
tipuri de navigări se pot executa în dimensiuni şi ce tipuri de calcule suportă
dimensiunile. În glosarul OLAP se specifică că “ doi membrii ai unei ierarhii sunt
de aceeaşi generaţie dacă ei au acelaşi număr de strămoşi….. Termenii de
generaţie şi nivel sunt necesari pentru a descrie subgrupuri de membrii întrucât,
de exemplu, deşi doi fraţi membri au acelaşi părinte şi sunt de aceeaşi generaţie, ei
ar putea să nu fie la acelaşi nivel, dacă unul din fraţi are un copil şi celălalt nu.”
2.1.4 Conceptul de măsură
O măsură (variabilă) este un indicator de performanţă prin care se poate

analiza performanţa activităţii modelate (de regulă un atribut numeric al unui
element din colecţia 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, “dimensiunea ambalajului” este un atribut numeric şi totuşi nu este un
indicator ci un atribut dimensional. Dacă valoarea atributului numeric variază
continuu (de exemplu: costul de livrare, cantitatea vândută, volumul vânzărilor)
atunci atributul este un indicator, iar dacă atributul este perceput mai mult ca o
constantă (de exemplu: dimensiunea ambalajului, descriere produs, culoare) atunci
este un atribut dimensional. Indicatorii pot fi clasificaţi în:
indicatori de bază (de exemplu: volumul vânzărilor, cantitatea vândută,
costurile, numărul de clienţi);
indicatori derivaţi care se obţin prin combinarea indicatorilor de bază (de
exemplu profitul).
O altă clasificare este dată de Ralph Kimball în cartea sa “The Data Warehouse
Toolkit” şi anume după posibilitatea indicatorilor de a se însuma după dimensiuni:
indicatori aditivi care se pot însuma după toate dimensiunile. De exemplu,
indicatorul “volumul vânzărilor” se poate calcula pentru o categorie de
produse sau pentru o anumită regiune sau pentru a anumită perioadă de
timp. Volumul vânzărilor, cantitatea vândută şi costurile sunt aditive.
Aceasta înseamnă că are sens de a aduna lei sau cantităţi de-a lungul
oricărei combinaţii timp, produs, magazin.
indicatori semiaditivi care se pot însuma numai după unele dimensiuni. De
exemplu, indicatorul “numărul de clienţi” este semiaditiv, deoarece se
poate calcula numărul de clienţi într-o anumită perioadă de timp sau pentru
o anumită regiune, dar nu este aditiv de-a lungul dimensiunii 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
45
exista clienţi, care au cumpărat mai multe tipuri de produse, din categoria
respectivă.
indicatori neaditivi care nu se pot însuma după nici o dimensiune (de
exemplu profitul marginal). Variabilele neaditive pot fi combinate cu alte
variabile pentru a deveni aditive.
2.1.5 Conceptul de multicub
Un cub n-dimensional este de fapt un set de variabile ce utilizează aceleaşi

dimensiuni de identificare. Întrebarea care apare 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. De exemplu, se
consideră cubul n-dimensional care modelează activitatea de vânzări cu
dimensiunile iniţiale: Timp, Locaţie, Produs şi dimensiunea de variabile
[THOM96]. Se adaugă dimensiunea Angajat şi variabila “numărul de ore
lucrate/tip de angajat”. În modelul modificat, variabilele iniţiale (de exemplu
cantitatea vândută, volumul vânzărilor) continuă să fie identificate de locaţie, timp
şi produs la care se adaugă tipul de angajat. În cubul modificat, variabilele pentru
vânzări sunt acum în funcţie de locaţie, timp, produs şi angajat. Dar în realitate,
vânzările nu depind de tipul angajatului. Într-un caz simplificat (fără dimensiunile
Locaţie şi Timp) se consideră dimensiunea Angajat cu 10 membri, dimensiunea
Produs cu 10 membri. Ca variabile se consideră numai “volumul vânzărilor”
pentru fiecare produs şi “totalul vânzărilor” pentru toate produsele şi “numărul de
ore lucrate” pentru fiecare tip de angajat, precum şi “total număr de ore lucrate”
pentru toţi angajaţii. Cele două seturi de date au câte 11 puncte de date fiecare.
Ierarhiile au fost eliminate din cub. Membrii “Toti angajaţii” şi “Toate produsele”
au fost adăugaţi la fiecare din dimensiunile respective, pe un singur nivel. Cubul
rezultat este format din 11*11*2 = 242 de intersecţii (celule). Din acestea numai
22 de celule au date, celelalte sunt goale. Cu alte cuvinte rezultă un cub n-
dimensional foarte împrăştiat. Apare necesitatea de a defini un nou cub n-
dimensional logic şi un mod de a determina când o dimensiune nouă aparţine sau
nu unui nou cub n-dimensional. Dacă două seturi de date aparţin aceluiaşi cub n-
dimensional logic, densitatea combinaţiilor lor va fi egală cu media aritmetică a
densităţilor lor înainte de a fi combinate. De exemplu, un cub perfect dens ce
conţine dimensiunea Locaţie (cu 100 de membri), dimensiunea Timp (cu 10
perioade de timp), dimensiunea Produs (cu 100 de produse) şi dimensiunea de
variabile (cu 5 variabile) va avea 500000 puncte de date. Un cub ce conţine
dimensiunea Locaţie (cu 100 de magazine), dimensiunea Timp (cu 10 perioade de
timp), dimensiunea Produs (cu 100 de produse), dimensiunea de variabile (cu 5
variabile) şi dimensiunea Scenariu (planificat, curent şi variaţia), iar datele există
numai pentru scenariu planificat, va conţine 500000 celule de date, dar este numai
33 % dens. Combinaţia celor două cuburi va conţine 1000000 celule de date şi este
67% dens.
46
În multe aplicaţii multidimensionale 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 logice sau structuri multicub. Problema care
apare în proiectarea unei structuri multicub este legată de modul cum se realizează
legătura între cuburile n-dimensionale. Se consideră cele două cuburi din exemplu
anterior: cubul cu date despre vânzări şi cubul cu date despre angajaţi. Cele două
cuburi au două dimensiuni comune: Locaţie şi Timp. Cubul pentru vânzări are în
plus dimensiunile Produs, Scenariu şi dimensiunea de variabile. Niciuna din aceste
dimensiuni nu este folosită de cubul pentru angajaţi. Cubul pentru angajaţi are
dimensiunea Angajat şi dimensiunea de variabile legate de activitatea angajaţilor
(de exemplu numărul total de ore lucrate/tip angajat) care nu sunt folosite de cubul
pentru vânzări. Se doreşte să se analizeze dacă există o relaţie între variabila
“numărul de ore lucrate/tip de angajat” şi variabila “cantitatea de produse vândute”.
Pentru a compara valorile celor două variabile, care se găsesc în două cuburi n-
dimensionale separate, trebuie mai întâi să se definească un cadru analitic sau un
numitor comun [THOM96]. În cazul celor două cuburi n-dimensionale, numitorul
comun sunt cele două dimensiuni comune: Locaţie şi Timp. În acest fel se pot
compara valori individuale, serii dimensionale sau volume dimensionale. Figura
2.6 arată o schemă pentru acest model multicub. Se observă că modelul conţine
dimensiunile globale Locaţie şi Timp şi fiecare cub n-dimensional din model este o
ramificaţie a dimensiunilor globale. Prin utilizarea structurii multicub este posibil
de a integra seturi de date eterogene.
În concluzie, cel mai simplu mod de reprezentare a datelor unei aplicaţii
multidimensionale este cel al unui spaţiu cartezian definit de toate dimensiunile
aplicaţiei (spaţiul datelor). Totuşi datele multidimensionale sunt împrăştiate şi
celulele de date nu sunt distribuite în mod egal în spaţiul multidimensional.
Proiectanţii de instrumente OLAP au adoptat o varietate de strategii pentru a trata
fenomenul de împrăştiere dar şi gruparea datelor. Instrumente ca Essbase, Power
Play utilizează structura hypercub, o structură logică de cub simplu, dar cu un
model sofisticat de compresie a datelor. Cealaltă structură, multicubul, este mai des
întâlnită. În aplicaţiile multicub, proiectanţii descompun baza de date într-un set de
structuri multidimensionale, fiecare fiind compusă dintr-un subset de dimensiuni
ale bazei de date. Aceste structuri multidimensionale au diferite denumiri (variabile
– Oracle Express, Pilot; structuri – Holos; cuburi – Microsoft OLAP).
2.1.6 Conceptul de împrăştiere
Conceptul de împrăştiere este frecvent asociat cu datele multidimensionale.

Termenul de împrăştiere a fost utilizat cu semnificaţia de valoare lipsă, valoare
inaplicabilă şi valoare zero. Primele două cazuri sunt considerate date invalide
(conceptul de null). Codd, în cele 18 reguli pentru OLAP [CODD93], sugerează că
modelele OLAP respectă regula privind valorile null, a modelului relaţional.
Existenţa unui număr mare de valori zero nu este totuşi un exemplu real de
47
împrăştiere. Valoarea zero este validă ca orice alt număr. Confuzia a apărut,
deoarece în aplicaţiile OLAP apare un număr mare de valori zero, precum şi
volume mari de date lipsă şi invalide. Tehnicile pentru optimizarea fizică a stocării
unui număr mare de valori repetate sunt similare şi uneori aceleaşi cu tehnicile
pentru optimizarea fizică a stocării de volume mari de date lipsă şi invalide. Totuşi
valorile lipsă şi cele invalide nu sunt date valide. Ele nu pot fi tratate în acelaşi mod
ca orice altă valoare. De aceea, sunt necesare tehnici speciale pentru aceste cazuri.
Tratamentul impropriu al valorilor null poate cauza calcule incorecte. Acurateţea
calculelor este de o importanţă crucială pentru analiza oricărui set de date,
indiferent că este sau nu multidimensional. Problema tratării datelor împrăştiate
este una foarte importantă şi este frecvent dezbătută în lumea bazelor de date.
Logicienii au crezut că există numai două valori logice: adevărat şi fals.
Regulile logice, care se aplică la bazele de date, sunt exprimate în funcţie de aceste
două valori. Problema apare totuşi când se introduc date invalide. Dar conform
logicii, o propoziţie şi inversa sa nu pot avea ambele valoarea adevărat. Nu ştim
dacă este adevărat sau fals, deoarece datele sunt lipsă. Conceptul de “invalid” este
similar cu conceptul de “lipsă” în sensul că nu se poate prelucra ca o valoare
validă, dar este diferit în sensul că ar putea fi greşit introdusă o valoare în acel
câmp. Datele lipsă şi cele invalide se introduc regulat în toate tipurile de baze de
date, inclusiv cele multidimensionale. În modelul relaţional, versiunea 2, Codd a
propus utilizarea unei logici bazată pe patru valori logice (figura 2.7). El a
schimbat semnificaţia termenului de negaţie. Pentru propoziţii adevărate şi false,
negaţia unui termen produce un termen diferit cu o valoare adevărată diferită.
Negaţia lui adevărat este fals şi negaţia lui fals este adevărat. Pentru propoziţii cu
valori lipsă sau invalide, negaţia unui termen este el însuşi. Deci negaţia unei valori
lipsă este “lipsă” şi negaţia unei valori invalide este “invalid” [THOM96].
Dimensiuni globale
Locaţie Timp
○ ○
○ ○
Hypercubul pentru vânzări Hypercubul pentru angajaţi
Produs Scenariu Variabile Angajat Variabile

○ ○ ○ ○ ○
○ ○ ○ ○ ○
Figura 2.6 Model multicub
48
Această inconsistenţă în definiţia negaţiei produce totuşi o serie de probleme.

Unii specialişti preferă să păstreze logica cu două valori, datorită propietăţilor ei de
deducere şi eliminarea datelor invalide. Ei caracterizează în general, datele invalide
ca fiind rezultatul unei proiectări proaste a bazei de date. De exemplu, în loc de a
introduce valoare null pentru “numele soţiei ” într-o bază de date cu informaţii
despre angajaţi, când un angajat nu are soţie, ar fi mai bine de a introduce valoarea
validă “Nu” în câmpul numit “este căsătorit”. Se poate crea o tabelă separată cu
informaţii despre soţii. Îmbunătăţirea proiectării bazei de date ar putea elimina
datele invalide. Cele două tipuri de date (lipsă şi invalide) trebuie totuşi să fie
tratate individual, deoarece ele afectează calculele în diferite moduri.
P Not (P)
T F
A A
I I
F T
T=adevărat A=lipsă
F=fals I=invalid
Figura 2.7 Logica cu patru valori a modelului relaţional, versiunea 2
2.2 Modele de date OLAP-extensii ale modelului relaţional

Aşa cum se observă în figura 2.8 modelele de date multidimensionale s-au
dezvoltat pe două direcţii şi anume: modele extensii ale modelului relaţional şi
modele orientate pe cub.
Multe din modelele propuse sunt extensii ale modelului relaţional. De
exemplu, Gray [GRAY96] propune operatorul CUBE ce generalizează clauza
GROUP BY din limbajul SQL şi care este o abordare foarte pragmatică, potrivită
pentru aplicaţiile OLAP. Modelul lui Li şi Wang [LIWA96] şi modelul lui Gyssens
şi Lakshmanan [GYSS97] constituie o extensie a algebrei relaţionale. În cele ce
urmează, se vor analiza câteva modele de date multidimensionale.
49
2.2.1 Operatorul Cub de date
În limbajul SQL standard ‘93 se utilizează pentru agregare cinci funcţii:

count(), sum(), min(), max(), avg() şi clauza GROUP BY. De asemenea, limbajul
SQL permite agregarea valorilor distincte (clauza DISTINCT). În afara de cele
cinci funcţii de agregare standard, multe SGBDR-uri permit funcţii statistice,
funcţii de analiză financiară şi alte funcţii specifice unor domenii. Unele sisteme
permit utilizatorilor să definească noi funcţii de agregare (de exemplu Informix
Illustra).
Modele extensii ale Modele orientate pe Concepte extinse

algebrei relaţionale cub
Operatorul Data Cube- Modelul Agrawal

Gray
Model cu facilităţi extinse

–Lehner
Algebra de grupare- Modelul Cabbibo
modelul Li, Wang
Modelul lui Kimball Modelul Vassiliadis
Modelul Golfarelli
Modelul Gyssens
Modelul Rafanelli
Modelul StarER
Modelul Guazzo
Modelul Teste
Modelul Blanschka
Modelul MAC
Figura 2.8 Istoria modelului de date multidimensional
50
Gray [GRAY96] propune pentru agregare utilizarea operatorului CUBE.
Multe sisteme relaţionale permit deja aceşti operatori (Oracle, SQL Server). De
exemplu, se consideră tabela de fapte F2_indicatori_performanţă (codcat, an,
nrcadre, nrtesa, nrstud_cer, nrdoct, …) şi tabela de dimensiuni Instituţii (codcat,
dencat, codfac, denfac, codinst, denumire). Cheia primară a tabelei de fapte este
cheie compusă (codcat, an), iar a tabelei de dimensiuni este codcat:
SQL> select an, codcat, nrcadre profesori from F2_indicatori_performanţă;
AN CODCAT PROFESORI
-------------------------------------------
2000 CIB 1
2000 IE 8
2000 MAN 1
2001 IE 3
SQL> select i.codfac, f.an, sum(f.nrcadre) profesori

from F2_indicatori_performanţă f, institutii i
where f.codcat=i.codcat
group by i.codfac, f.an;
CODFAC AN PROFESORI
-------------------------------------------
CSIE 2000 9
CSIE 2001 3
FMAN 2000 1
Operatorul ROLLUP creează subtotaluri:

SQL > select i.codfac, f.an, sum(f.nrcadre) profesori
group by rollup(i.codfac, f.an);
CODFAC AN PROFESORI
-------------------------------------------
CSIE 2000 9
CSIE 2001 3
CSIE 12
FMAN 2000 1
FMAN 1
13
51
Primele două rânduri sunt identice cu cererea anterioară. Al treilea rând este un
subtotal al atributului “an” (apare valoarea null în coloană “an”). În realitate nu
sunt valori nule în această coloană (este un artificiu al operatorului ROLLUP).
Următorul rând este rând de detaliu, iar al cincilea rând este un alt subtotal după
atributul “an”. Ultimul rând este un total general. Următoarea cerere este
echivalentă cu cererea ce utilizează operatorul ROLLUP:
SQL > select i.codfac, f.an, sum(f.nrcadre) profesori
group by i.codfac, f.an
union
select i.codfac, ‘ ‘, sum(f.nrcadre) profesori
group by i.codfac, ‘ ‘
union
select ‘ ‘, ‘ ‘, sum(f.nrcadre) profesori
group by ‘ ‘, ‘ ‘, ;
CODFAC AN PROFESORI
-------------------------------------------
CSIE 2000 9
CSIE 2001 3
CSIE 12
FMAN 2000 1
FMAN 1
13
Citirea cererii este dificilă. De asemenea, tabela se parcurge de mai multe ori.
Operatorul ROLLUP, mai concis şi mai uşor de citit, este mai eficient (mai ales
pentru seturi mari de date), deoarece tabela se parcurge o singură dată. Sunt
posibile şi operaţii rollup parţiale:
SQL > select f.an, i.codfac, sum(f.nrcadre) PROFESORI
group by f.an, rollup(i.codfac);
AN CODFAC PROFESORI
----------------------------------------------------
2000 CSIE 9
2000 FMAN 1
2000 10
2001 CSIE 3
2001 3
52
În acest caz, nu se produce un total general (total după toate dimensiunile).

Dacă în ROLLUP sunt specificate N coloane, atunci se produc N+1 tipuri de
subtotal.
Operatorul CUBE realizează toate tipurilor posibile de agregare (totaluri pentru
fiecare combinaţie posibilă de dimensiuni). De exemplu:
SQL> select f.an, i.codfac, sum(f.nrcadre) PROFESORI
group by cube(f.an,i.codfac);
AN CODFAC PROFESORI
----------------------------------------------------
2000 CSIE 9
2000 FMAN 1
2000 10
2001 CSIE 3
2001 3
CSIE 12
FMAN 1
13
Operatorul CUBE produce toate combinaţiile posibile sau 2**N tipuri de
subtotaluri. Cubul poate fi un cub complet sau un cub parţial. Funcţia GROUPING
face distincţie între valorile null curente şi cele ce rezultă prin agregare, returnând o
valoare 0 pentru primul caz şi o valoare 1, când este detectat un subtotal. De
exemplu:
SQL> select f.an, i.codfac, sum(f.nrcadre) profesori,
grouping(f.an) t,
grouping(i.codfac) f
from F2_indicatori_performanţă f, institutii I
group by cube(f.an,i.codfac);
AN CODFAC PROFESORI T F
-----------------------------------------------------------------------
2000 CSIE 9 0 0
2000 FMAN 1 0 0
2000 10 0 1
2001 CSIE 3 0 0
2001 3 0 1
CSIE 12 1 0
FMAN 1 1 0
13 1 1
Funcţia GROUPING poate fi utilizată, de asemenea, pentru filtrarea rândurilor.
53
De exemplu:
SQL> select f.an, i.codfac, sum(f.nrcadre) profesori
grouping(f.an) t,
grouping(i.codfac) f
group by cube(f.an,i.codfac)
having grouping(f.an)=0
and grouping(i.codfac)=0;
AN CODFAC PROFESORI T F
-----------------------------------------------------------------------
2000 CSIE 9 0 0
2000 FMAN 1 0 0
2001 CSIE 3 0 0
Toate funcţiile utilizate în clauza GROUP BY (sum, count, max, min, variance,
stddev) pot fi utilizate şi cu ROLLUP şi CUBE.
2.2.2 Modelul lui Li, Wang
În [LIWA96] se defineşte un model de date multidimensional (MDD) pentru

aplicaţii OLAP. Conceptul de bază este cubul multidimensional.
O schemă de cub n-dimensional este un set {(D1, R1), …,(Dn, Rn)} unde : Di
sunt dimensiuni şi Ri atribute.
Un cub MD este o pereche (F,µ) unde F={(D1, r1), …,(Dn, rn)}(unde ri este o
relaţie pe Ri pentru fiecare i) şi µ este o funcţie de la {(D1, t1), …,(Dn, tn) | ∀ 1≤ i
≤ n , ti ∈ri } la V (set de valori scalare). Deci un cub MD este un set de relaţii
dimensionale ri şi o funcţie de la un n-tuplu la o valoare scalară.
O bază de date multidimensională este un set finit de cuburi MD şi un set finit
de relaţii de grupare (grouping relations). De asemenea, se introduce o algebră
(MD cube algebra), o extensie a algebrei relaţionale, pentru manipularea cuburilor
(de exemplu reuniune de cuburi, adăugarea unei noi dimensiuni, agregarea cubului
etc) şi un limbaj de interogare algebric numit algebra de grupare (grouping
algebra).
Modelul lui Li şi Wang este un model multidimensional cu o puternică
expresivitate prin setul de operatori definiţi, dar nu permite modelarea măsurilor
complexe într-un singur cub. Pentru fiecare măsură trebuie construit un cub MD
separat. Ierarhiile multiple pot fi exprimate folosind operatorii algebrei de grupare
(operatorul roll, order, operatorul de agregare).
54
Pentru a ilustra acest model, autorii propun ca exemplu o fabrică de automobile

care doreşte să analizeze cazurile de reparaţii pentru maşinile pe care le produce.
Se consideră că o “reparaţie” este descrisă în funcţie de următoarele dimensiuni:
Vehicul (vehiculul ce trebuie reparat);
Timp (data reparaţiei);
Garaj (garajul ce execută reparaţia);
Clientul (propietarul maşinii reparate).
Pentru o reparaţie sunt relevante următoarele informaţii: costurile pieselor
componente (cost_comp), salariile (sal), costurile totale (cost_total), numărul de
persoane implicate (nr_pers) şi durata reparaţiei (durata). Pentru fiecare măsură se
construieşte un cub separat. De exemplu, pentru măsura “cost_total” se defineşte
următorul cub :
Reparatie_Vehicul=(rt, rg, rv, cost_total). Schema cub n – dimensional este:
<(timp, Rd), (garaj, Rg), (vehicul, Rv)>, unde Rd ={an, luna, zi} .
2.2.3 Modelul lui Kimball
În [KIMB96] se defineşte schemă stea, o reprezentare intuitivă a cubului de

date multidimensional într-un mediu relaţional. Schema stea conţine o tabelă
centrală şi un set de tabele de dimensiuni aranjate într-o manieră radială, în jurul
tabelei centrale. Fiecare tabelă de dimensiuni reprezintă o dimensiune a activităţii
analizate, în timp ce tabela centrală conţine conţinutul cubului de date. Schema este
foarte asimetrică. Există o tabelă dominantă în centrul schemei, singura tabelă din
schemă cu multiple joncţiuni, prin care se conectează la celelalte tabele. Această
tabelă se numeşte tabela de fapte (fact table). Celelalte tabele au numai o singură
joncţiune, prin care se leagă la tabela centrală şi se numesc tabele de dimensiuni
sau dimensiuni (dimension table). Schema stea reduce numărul de joncţiuni între
tabele, ca urmare a procesului de denormalizare. Nu există nici o informaţie despre
nivelurile ierarhice stocate în structura schemei stea. În plus, reprezentarea unei
dimensiuni printr-o singură tabelă conduce la date redundante, denormalizate şi
inconsistente. În mediile cu depozite de date, aceasta nu cauzează nici o problemă,
deoarece datele sunt în cele mai multe cazuri interogate. Tabelă de fapte are
următoarele caracteristici:
Conţine un număr foarte mare de tupluri (posibil milioane). Numărul de
tupluri din tabelă reprezintă de fapt produsul cartezian al dimensiunilor. De
exemplu, pentru analiza activităţii de desfacere a unei firme de comerţ cu
500 de magazine de distribuţie în întreaga lume şi care comercializează
50000 de produse în fiecare magazin, tabela de fapte va conţine
500*50000*2*365 de tupluri. Baza de date va stoca informaţiile referitoare
la tranzacţiile zilnice, pe o perioadă de doi ani.
Dimensiunea ei creşte dinamic, în funcţie de cantitatea de date încărcate la
fiecare ciclu de actualizare a bazei de date, precum şi în funcţie de volumul
de date istorice stocate în baza de date.
55
Este tabela care reflectă performanţa activităţii (procesului) analizate.

Cheia primară a tabelei este o cheie compusă, formată din cheile primare
ale tabelelor de dimensiuni. Fiecare tabelă de fapte are o cheie compusă şi
invers fiecare tabelă care are o cheie compusă este o tabelă de fapte.
Este normalizată şi realizează de fapt o legătură indirectă între dimensiuni.
Figura 2.9 prezintă un exemplu de schemă stea. Tabela centrală este tabela
Vânzări înconjurată de dimensiunile Timp, Client, Locaţie, Produs, Vânzător. Deci
schema stea are următoarele caracteristici:
tabela de fapte se leagă de dimensiuni prin joncţiuni de egalitate;
fiecare atribut din cheie primară a tabelei de fapte reprezintă cheia primară
a unei dimensiuni;
atributele non cheie pot fi agregate. Tabelele de fapte conţin numai atribute
numerice;
tabelele de dimensiuni sunt denormalizate.
Dimensiunea Dimensiunea
Client Timp
Dimensiunea
Locaţie
Tabela de fapte
Dimensiunea Vânzări
Vânzător
Dimensiunea
Produs
Figura 2.9 Modelul stea
Avantajele schemei stea:

este simplu de construit;
reflectă cu exactitate modul cum înţeleg utilizatorii activitatea modelată;
furnizează o performanţă ridicată pentru cereri analitice, prin reducerea
numărului de joncţiuni;
permite modelarea unor structuri multidimensionale complexe;
este o schemă uşor de înţeles de către utilizatori, deoarece datele sunt
aranjate într-un mod uşor de înţeles, iar relaţiile între entităţi sunt foarte
clare;
toţi indicatorii de performanţă ai activităţii modelate sunt stocaţi în tabela
de fapte.
Dezavantajele schemei stea:
este o schemă inflexibilă. Adăugarea unei noi dimensiuni în schemă, poate
duce la modificarea granulaţiei tabelei de fapte;
conţine date redundante ce conduc la creşterea riscului de inconsistenţă a
datelor;
56
pentru a permite analize complexe, trebuie să includă multe tabele de

agregate;
are o scalabilitate limitată;
face dificilă joncţiunea între tabelele de fapte.
Schema fulg de zăpadă este o variantă a schemei stea. Este rezultatul
descompunerii unei dimensiuni sau a mai multor dimensiuni care au ierarhii.
Relaţiile de tip (m:1) între membrii unei dimensiuni se descompun în tabele
separate formând o ierarhie de tabele. De exemplu, dimensiunea Produs este
descompusă în subdimensiunile Model şi Produs (figura 2.10). Schema fulg de
zăpadă vizualizează structura ierarhică a dimensiunilor. Diferenţa esenţială faţă de
schema stea este că dimensiunile sunt normalizate. Principala motivaţie a
normalizării este spaţiul de stocare. Dacă ierarhiile se păstrează în tabele separate,
se consideră că spaţiul de stocare se reduce consistent. Totuşi Ralph Kimball în
lucrarea sa “Practical Techniques for Building Dimensional Data
Warehouse”(1996) încearcă să demonstreze contrariul. El afirmă că eforturile de a
normaliza tabelele, în scopul de a reduce spaţiul de stocare, sunt inutile şi
consumatoare de timp. Normalizarea dimensiunilor reduce cu mai puţin de 1%
spaţiul total de stocare, iar vizualizarea datelor este mai dificilă, implicând un
număr mai mare de joncţiuni între tabele. Mulţi proiectanţi nu consideră că
salvarea spaţiului ar fi o cerinţă majoră în selectarea tehnicii de modelare.
Timp
săptămâna
luna
client
data regiune
Client Locaţie
locaţie
fabrica
Tabela de
fapte
Vânzări
vânzător
model
produs
piaţa de
Vânzător desfacere Produs
regiune
Figura 2.10 Modelul fulg de zăpadă
57
Avantajele schemei fulg de zăpadă:

este mai flexibilă şi se pot defini cerinţele utilizatorilor mult mai bine. De
exemplu, cu schema stea nu se pot folosi tabele istorice pentru modificarea
dimensiunilor;
structura normalizată a dimensiunilor este mai uşor de modificat;
reduce redundanţa datelor;
îmbunătăţeşte performanţa operaţiilor de drill down şi roll up.
Dezavantajele schemei fulg de zăpadă:
este mai complexă decât schema stea;
scade performanţa la interogare, deoarece sunt folosite multe joncţiuni;
schema este mai dificil de înţeles de către utilizatori, fiind mai apropiată de
modelul entitate-asociere.
Modelele stea şi fulg de zăpadă, precum şi variantele lor au devenit o
reprezentare logică bine cunoscută a structurilor de date multidimensionale, în
sistemele relaţionale. Selectarea unei scheme potrivite ţine cont de raportul între
costul de stocare şi performanţa interogării. Schema stea oferă performanţe mai
bune la interogare, datorită unui număr mic de operaţii de joncţiune între tabela de
fapte şi tabelele de dimensiuni, dar costul de stocare este mai ridicat. Schema fulg
de zăpadă implică mai multe operaţii de joncţiune, dar presupune o capacitate de
stocare mai mică. Pentru ambele modele există o mulţime de variante. Schema stea
de zăpadă (starflake) sau schema fulg de zăpadă degenerată (degenerated
snowflake scheme) este o combinaţie de schemă stea şi schemă fulg de zăpadă, în
care o parte a tabelelor de dimensiuni sunt denormalizate.
Schema galaxie este o schemă stea cu mai multe tabele de fapte. În schema
constelaţie (fact constellation scheme) există tabele de fapte suplimentare ce
stochează date agregate. O constelaţie este o colecţie de stele şi constă dintr-o stea
centrală înconjurată de alte stele. Steaua centrală conţine datele la nivel atomic, iar
celelalte stele conţin date agregate. Steaua centrală se leagă de celelalte stele prin
atribute dimensionale (figura 2.11).
Figura 2.11 Constelaţia
58
2.3 Modele orientate pe cuburi
Au existat, de asemenea, eforturi pentru a modela direct şi mai natural bazele

de date multidimensionale şi anume modelele orientate pe cuburi.
2.3.1 Modelul lui Agrawal
Modelul de date multidimensional propus de Agrawal [AGRA97] are în vedere

următoarele aspecte:
tratarea simetrică a dimensiunilor şi măsurilor;
flexibilitatea (multiple ierarhii, agregate ad-hoc);
un set minimal de operatori asemănători cu cei din algebra relaţională.
În modelul lui Agrawal datele sunt organizate în unul sau mai multe cuburi n-
dimensionale (hypercuburi). Un cub are următoarele componente:
k dimensiuni (fiecare dimensiune are un nume Di şi un domeniu de valori
domi);
elementele cubului sunt definite printr-o funcţie E(C) care asociază dom1
×…×domk la un n-tuplu (valorile celulelor cubului C ) sau { 0, 1}. Astfel,
E (C) (d1, …….., dk ) referă elementul de la “poziţia” d1,……,dk a
cubului C. Elementele unui cub (valorile celulelor cubului) pot fi fie {0,1}
sau un n-tuplu <X1,……,Xn>. Dacă elementul corespunzător la
E(C)(d1,…..,dk) este “0” atunci acea combinaţie de valori ale
dimensiunilor nu există (celule fără conţinut). Valoarea “1” indică
existenţa acelei combinaţii. Un n-tuplu reprezintă existenţa unei înregistrări
cu n măsuri. Dacă un element al unui cub este “1” atunci nici unul din
celelalte elemente ale cubului nu pot fi un n-tuplu. Dacă toate elementele
unui cub sunt “0” sau dacă domeniul domi al dimensiunii Di nu are valori,
atunci cubul este considerat a fi “gol” (empty).
un n-tuplu ce descrie elementele cubului.
Dimensiunile nu au structură sau ordine şi elementele cubului sunt adresate

prin numele lor. De exemplu, un cub pentru analiza vânzărilor poate avea
următoarele dimensiuni :
Dimensiunea Produs (D1) cu domeniul de valori dom1={p1, p2, p3, p4};
Dimensiunea Data (D2) cu domeniul de valori dom2={ian1, feb2, feb3,
mar4};
Dimensiunea Furnizori (D3) cu domeniul de valori dom3={s1, s2, s3, s4};
n-tuplu este format dintr-un singur membru <vânzare>;
Elementele cubului :
E (C)(p1, ian1, s1) este <10>
E (C)(p1, ian1, s2) este <20>
E (C)(p1, ian1, s3) este <50>
59
E (C)(p1, ian1, s4) este <70>

E (C)(p2, ian1, s1) este <15>
E (C)(p2, ian1, s1) este <20> etc.
Notaţia < > indică că fiecare element din cub este o valoare a vânzărilor.
Modelul de date pentru analiza reparaţiilor este de forma : C= (D, E (C), N)

unde :
D={garaj, timp, vehicul} sunt dimensiunile cubului
N=(costurile pieselor componente, salariile, numărul de persoane, durata
reparaţiei).
E (C) este funcţia care defineşte elementele cubului
Modelul lui Agrawal tratează simetric dimensiunile şi măsurile (de exemplu

măsura Vânzare se poate transforma într-o dimensiune). În figura 2.12 cubul
multidimensional are dimensiunile: Produs, Data şi Vânzare. Elementul
corespunzător la “data=mar 4”, “produs=p1” şi “vânzări=15” este “1”. Notaţia
<vânzare> din figură 2.13 indică că fiecare element din cub este o valoare a
vânzarilor. De exemplu, <15> este valoarea vânzarilor pentru “data=mar 4” şi
“produs=p1”.
Data
Mar4
Feb3
Feb2
Ian1
15 P1 P2 P3 P4 Produs
20
Vânzare
Figura 2.12 Măsura Vânzare este transformată în dimensiune
Autorii definesc şi un set minimal de operatori multidimensionali (push, pull,

destroy, restriction, join şi merge), utilizând un cub C cu k dimensiuni
(dimensiunile D1, …., Dk). Valorile dimensiunilor din modelul de date determină
funcţional elementele cubului. Operatorii propuşi pot fi combinaţi pentru a construi
operatori OLAP cum ar fi roll up, drill down etc. Ei au o serie de propietăţi: sunt
bine definiţi semantic şi sunt minimali în sensul că nici unul nu poate fi exprimat în
funcţie de ceilalţi. Fiecare operator este definit pe cuburi şi produce ca ieşire un
cub. Operatorii pot fi implementaţi fie într-un sistem relaţional (limbajul SQL) sau
într-un sistem multidimensional. De exemplu, operatorul Push (figura 2.13) este
utilizat pentru a converti dimensiunile în elemente ce pot fi apoi manipulate
60
utilizând o funcţie felem. Acest operator este necesar pentru a permite tratarea
uniformă a dimensiunilor şi măsurilor. Are ca intrări cubul C, dimensiunile Di şi
ca ieşire cubul C cu fiecare element (diferit de zero) extins cu valoarea dimensiunii
Di corespunzătoare pentru acel element.
Matematic: push (C, Di ) =Ca
E (Ca)(d1,……..,dk) = g ⊕ di unde g= E (C)(d1,……..,dk).
Operatorul ⊕ este :
- 0 dacă g=0 ,
- < d i > dacă g=1
- altfel g concatenat cu < di >.
Operatorul Pull este invers operatorului Push şi se utilizează pentru a converti

un element într-o dimensiune, astfel că elementul poate fi utilizat pentru joncţiune
şi este necesar pentru tratamentul simetric al dimensiunilor şi măsurilor. Operatorul
Destroy şterge o dimensiune D ce are domeniul format dintr-o singură valoare.
Operatorul Restriction operează pe o dimensiune a unui cub şi şterge valorile
cubului ce nu satisfac o condiţie dată (operaţia slice şi dice pe un cub ). Operatorul
Join realizează joncţiunea unui cub m-dimensional C cu un cub n-dimensional C1
pe k dimensiuni numite dimensiuni de joncţiune (joining dimensions) şi se obţine
cubul Ca cu m+n-k dimensiuni. În cazul produsului cartezian, cele două cuburi nu
au nici o dimensiune de joncţiune comună. Operatorul Merge este un operator de
agregare.
Data
Mar4 <15> <10> <Vânzări>
Feb3 <20> <15> <15> <20>

Feb2 <10> <15>
Ian1 <10> <20> <25>
P1 P2 P3 P4 Produs
Data
Mar4 <15,p1> <10,p1> <Vânzări, Produs>
Feb3 <20,p1> <15,p2> <15,p3> <20,p4>
Feb2 <10,p2><15,p3>
Ian1 ………..
p1 p2 p3 p4 produs
Figura 2.13 Operatorul Push
61
Tratarea simetrică a dimensiunilor şi măsurilor are o influenţă mare în

proiectarea schemei conceptuale multidimensionale. Absenţa ei cauzează
reproiectarea schemei atunci când se doreşte agregarea după un atribut ce a fost
iniţial definit ca măsură. Autorii consideră că operatorii relaţionali: proiecţie,
reuniune, intersecţie şi diferenţă cât şi operaţiile multidimensionale roll up, drill
down pot fi exprimaţi în funcţie de operatorii prezentaţi anterior.
Modelul nu face o distincţie explicită între structură şi conţinut, nu conţine
informaţii despre structura dimensiunilor. Aceasta înseamnă că toate informaţiile
structurale şi funcţionale trebuie să fie incluse în cerere. Măsurile structurate ca
înregistrări pot fi exprimate uşor, deoarece modelul permite n-tupluri.
2.3.2 Modelul lui Cabibbo
Modelul MD propus de Cabibbo este un model de date multidimensional

conceptual pentru sisteme OLAP. Cabbibo propune şi un limbaj de interogare
descriptiv bazat pe un calcul logic [CABB97]. În modelul MD, dimensiunile sunt
categorii lingvistice ce descriu diferite moduri de prezentare şi de analiză a
informaţiilor. Fiecare dimensiune este organizată într-o ierarhie de niveluri (un
nivel corespunde la un domeniu de date cu o anumită granularitate). Un nivel poate
avea asociate descrieri.
Fie ℒ un set de nume numite niveluri. Fiecare nivel l∈ℒ este asociat cu un set
finit de valori numit domeniu al lui l şi notat cu DOM(l). O dimensiune constă din:
un set finit de niveluri L⊆ℒ;
o ordine parţială ≼ pe nivelurile din L (când l1 ≼ l2 spunem că l1 “roll-
up” la l2). De exemplu, garaj ≼ regiune înseamnă că nivelul “garaj” se va
agrega la nivelul “regiune”.
o familie de funcţii “roll-up”. O funcţie R-UP(l1→l2) : DOM(l1) →
DOM(l2 ) este definită pentru fiecare pereche de niveluri l1 ≼ l2. Funcţiile
“roll-up” sunt o facilitate a modelului MD, ele descriu cum sunt asociate
valorile diferitelor niveluri (de exemplu garajele A, B, C aparţin la
regiunea Bavaria). Funcţiile “roll-up” oferă un instrument puternic pentru
interogarea datelor multidimensionale, întrucât ele specifică modul cum
trebuie agregate datele.
Fiecare nivel l∈L este asociat cu un set de valori numit domeniu (de exemplu
dom(garaj) ={A,B,C,…….}). O dimensiune cu un singur nivel se numeşte atomică.
O schemă MD constă din:

un set finit D de dimensiuni;
un set finit F de tabele de fapte (f-table) de forma
f[A1:l1<d1>,….., An:ln<dn>]: lo<do>, unde f este numele tabelei, fiecare
62
Ai (1 ≤ i≤ n) este un atribut al lui f şi fiecare li (0≤ i ≤n) este un nivel al

dimensiunii di;
un set finit ∆ de descrieri de nivel.
În acest context, se prezintă şi o metodologie de proiectare a unui model MD,

având ca punct de pornire modelul entitate-asociere al bazei de date operaţionale
sursă.
Modelul conceptual MD poate fi implementat logic fie folosind tabele
relaţionale în formă de schemă stea (sisteme ROLAP) sau folosind matrici
multidimensionale (sisteme MOLAP). Se consideră pentru exemplificare o firmă
de telecomunicaţii interesată în analiza informaţiilor ei operaţionale. Datele despre
apelurile telefonice pot fi organizate de a lungul dimensiunilor Timp şi Client.
Ierarhiile corespunzătoare sunt prezentate în figura 2.14. Dimensiunea Client
conţine nivelurile: “număr_telefon”, “zona” (zona geografică în care telefonul este
localizat, identificată de codul zonei) şi “contract”. Dimensiunea Timp conţine
nivelurile: “moment curent”, “zi”, ”ora”, ”luna”.
Se definesc următoarele tabele de fapte (f-table): Tariful (reprezintă costul
pentru un minut de conversaţie între un client dintr-o zonă de apel şi un client
dintr-o zonă apelată), Durata (asociază fiecărui apel durata în secunde),
Factura_lunară (o tabela de fapte derivată ce conţine încasările după număr
telefon şi lună). “Propietarul” este o descriere de nivel ce asociază numele unui
client cu un număr de telefon.
luna numeric
zona contract
ziua Ora
Număr_telefon şir de
caractere
Moment
Client
Timp
Tarif [ora: ora, contract: contract, zona de apel: zona, zona apelată: zona] : numeric
Durata [apel: număr telefon, apelatul: număr telefon, momentul_începerii_convorbirii: moment] : numeric
Factura_lunară [clientul::număr _telefon, perioada: luna] : numeric
Propietar (număr_ telefon) : şir
Figura 2.14 Un exemplu de schema MD
63
Modelul MD a fost definit în principal, pentru dezvoltarea unei metodologii de

proiectare a bazelor de date multidimensionale. Ierarhiile dimensionale sunt
definite explicit în modelul MD, în timp ce în modelul lui Agrawal ele sunt
implementate folosind un operator special al limbajului de interogare (operatorul
merge). De asemenea, modelul lui Agrawal este orientat în principal, spre o
implementare SQL, în baze de date relaţionale. Este posibilă definirea ierarhiilor
multiple într-o dimensiune, deoarece relaţia ≼ defineşte numai o ordine parţială pe
nivelurile dimensiunii. Limbajul de interogare descriptiv este un calcul logic
(conţine operaţii logice (∧, ∨, ¬), cuantificatori (∀ şi ∃) şi funcţii definite de
utilizatori). În [CABB98b] se extinde modelul multidimensional pentru a permite şi
măsuri structurate ca înregistrare şi se defineşte un limbaj de interogare algebric.
Algebra utilizează 10 operatori, mulţi sunt similari cu operatorii relaţionali
(joncţiunea, produsul cartezian, selecţia etc).
2.3.3 Modelul lui Blaschka
Tehnica de modelare ME/R propusă de autori [BLAS00] pentru proiectarea

schemei multidimensionale este o extensie a tehnicii entitate-asociere. Notaţiile
grafice utilizate sunt specificate în figura 2.15. Se definesc următoarele concepte:
o entitate specială : “nivel al dimensiunii” (dimension level);
o relaţie n-ară numită relaţia “fapt “ (fact relationship);
o relaţie binară numită relaţia de “clasificare” (classification relationship).
Pentru a modela structura datelor se introduce o relaţie binară specială: relaţia
de clasificare. Ea asociază un nivel A cu un nivel superior B (de exemplu nivelul
“oraş” este “clasificat” în funcţie de nivelul “ţară”).
Graficul de clasificare este un graf aciclic definit astfel: RG=(E,V) unde : E
este un set finit al tuturor nivelurilor e1,…,ek şi V={(ei, ej) | i#j ∧1≤ i, j≤ k ∧ei
este clasificat în funcţie de ej}.
Numele relaţiei de clasificare descrie criteriul de clasificare (de exemplu,
“locuieşte în” pentru relaţia de clasificare ce conectează nivelul “client” şi nivelul
“regiune geografică”). Relaţia fapt asociază n niveluri. O astfel de relaţie reprezintă
un fapt (de exemplu “repararea maşinilor”) de dimensionalitate n. Nivelurile
asociate direct cu faptul sunt numite niveluri dimensionale atomice (atomic
dimension levels).
64
Nivel
Fapt
Relaţie de clasificare
Figura 2.15 Notaţii grafice în tehnica ME/R
Atributele unei relaţii fapt modelează măsurile faptului (date cantitative) în

timp ce nivelurile asociate prin aceasta relaţie, modelează datele calitative. Autorii
propun ca exemplu o fabrică de automobile, care doreşte să analizeze cazurile de
reparaţii pentru maşinile pe care le produc. Se consideră că o “reparaţie” este
descrisă în funcţie de următoarele dimensiuni: Vehicul (vehiculul ce trebuie
reparat), Ziua (data reparaţiei), Garaj (garajul ce execută reparaţia) şi Clientul
(propietatul maşinii reparate). Pentru o reparaţie sunt relevante următoarele
informaţii: costurile pieselor componente, salariile, costurile totale, numărul de
persoane implicate şi durata reparaţiei.
Pentru a construi graful ME/R trebuie respectate următoarele condiţii :
nu există noduri izolate, fiecare arc conectează două noduri (fiecare nod
este fie sursă sau destinaţie la cel puţin un arc). Sunt patru tipuri de arce :
relaţia între un nivel şi un atribut, relaţia între un fapt şi un atribut, relaţia
de clasificare între două niveluri şi relaţia “este dimensiune a” între un fapt
şi nivelurile corespunzătoare;
nu se poate conecta un fapt cu un nivel printr-o relaţie de clasificare;
sunt trei tipuri de noduri: nivel, fapt şi atribut. Două noduri atribut nu pot
fi conectate;
un graf ME/R constă minim dintr-un nod fapt şi un nod nivel conectat
printr-un arc “este dimensiune a”. La orice nod se ajunge plecând de la
nodul fapt printr-o secvenţă de noduri şi arce;
se evită ciclurile în ierarhiile de clasificare (figura 2.16);
Autorii propun, de asemenea, următorul set de operaţii:
inserare nivel (se creează un nivel izolat). Relaţiile de clasificare pentru
acest nou nivel trebuie adăugate separat;
ştergerea unui nivel (ştergerea unui nivel existent dar izolat). Instanţele
nivelului sunt şterse automat;
actualizarea unui atribut (crearea un nou atribut fără ataşarea lui la un
nivel sau fapt, ştergerea unui atribut existent dar deconectat, conectarea sau
65
deconectarea unui atribut la un nivel, conectarea sau deconectarea unui

atribut la un fapt);
actualizarea unei relaţii de clasificare (inserarea unei relaţii de clasificare
între două niveluri existente, ştergerea unei relaţii existente între două
niveluri);
actualizarea unui fapt (inserarea unui fapt fără ataşarea nivelurilor
dimensionale la el, ştergerea unui fapt existent dar izolat împreună cu
instanţele lui, inserarea sau ştergerea unui nivel dimensional).
district
garaj regiune
Figura 2.16 Ciclu într-o ierarhie de clasificare
Un model MD (schema MD) este 6-tuplu <F, L, A, gran, class, attr> unde:
F⊂Z* este un set finit de m fapte {f1,……,fm} unde fi∈Z* pentru 1≤ i
≤m;
L⊂ Z* este un set finit de k niveluri dimensionale {l1,…..,lk} unde li ∈ Z*
pentru 1≤ i ≤ k;
A⊂ Z* este un set finit de p atribute {a1,….,ap} unde ai ∈ Z* pentru 1≤ i
≤ p. Fiecare atribut ai are un domeniu ataşat dom(ai ) şi L∩F∩A=∅;
gran este o funcţie ce asociază un set de niveluri cu o colecţie de fapte.
Aceste niveluri gran(f) sunt numite niveluri de bază ale colecţiei de fapte
F;
class ⊆L×L este o relaţie definită pe niveluri ;
attr: A→F∪L este o funcţie ce asociază un atribut la o colecţie de fapte (în
acest caz se numeşte măsură), la un nivel (în acest caz se numeşte atribut al
nivelului);
Se constată că nu s-a definit o construcţie pentru noţiunea de dimensiune,
deoarece există nivelurile şi relaţiile de clasificare, ambele construcţii furnizează
informaţiile necesare pentru o dimensiune. Se pot defini măsuri structurate ca
înregistrare întrucât funcţia attr poate asocia mai multe atribute la o colecţie de
fapte. De exemplu, modelul multidimensional pentru analiza activităţii de reparaţii
are următoarele componente (figura 2.17):
colecţie de fapte: F={reparatie_vehicul};
nivelurile: L={client, vehicul, model, marca, zi, luna, an, garaj, tip_garaj,
geog.regiune, ţara};
atributele: A={costc, sal, costt, nrpers, durata, vârsta, venit};
66
funcţia: gran(reparatie_vehicul) ={client, vehicul, zi, garaj} asociază

colecţia de fapte F cu nivelurile de bază ale dimensiunilor;
relaţiile între niveluri: class={(zi, luna), (luna, an), (garaj, tip_garaj),
(garaj, geog.regiune), (geog.regiune, tara), (client, geog.regiune), (vehicul,
model), (model, marca)};
funcţiile:
attr(“costc”)=reparatie_vehicul, attr(“sal”)=reparatie_vehicul;
attr(“costt”)=reparatie_vehicul, attr (“nrpers”)=reparatie_vehicul;
attr(durata)=reparatie_vehicul, attr(vârsta)=client, attr(venit)=client.
Domeniul unui nivel l∈L este un set finit de membrii dimensionali (dimension
members): dom(l)={m1,….,mq}. Pentru a reprezenta structura instanţelor unei
colecţii de fapte se defineşte domeniul şi co-domeniul. Domeniul unei colecţii de
fapte este produsul cartezian al tuturor nivelurilor de bază (coordonatele celulei
cubului), iar co-domeniul este produsul cartezian al măsurilor acestei colecţii de
fapte.
Instanţa unui model MD ℳ= <F, L, A, gran, class, attr> este un triplet:
ℑℳ = < R - UP, C, AV > unde :
R-UP ={r-up} este un set finit de funcţii r-up: dom(nivel1) →dom(nivel2)
pentru (nivel1, nivel2)∈class;
C={cf1,…..cfm}, fi∈F ∀ 1≤ i ≤m este un set finit de funcţii cf :
dom(f)→codom(f), f∈F. Funcţia C asociază coordonatele cubului la
măsuri definind astfel conţinutul cubului;
AV={av1,….,avr} este un set finit de funcţii care conţine o funcţie ava
pentru fiecare atribut a unde attr(a)∈L (atributul a este un atribut al
nivelului).
Un exemplu de instanţă a modelului MD din figura 2.17 este:
ℳex este <R-UPex, Cex, AVex> dacă:
dom (client)={“Popescu”, “Ionescu”}
dom (garaj)={“Deva”, “Cluj”, “Iasi”}
dom (geog.regiune)={“Vest”, “Est”}
dom (zi)={“01/01/97”, “01/02/97”}
dom (vehicul)={“B-07-NID”, “B-08-JAD”}
Domeniul şi co-domeniul colecţiei de fapte “reparaţie_vehicul” sunt:
dom (reparaţie_vehicul)=dom (client)×dom (garaj)×dom (zi)×dom (vehicul)
codom (reparaţie_vehicul)=dom(costc) × dom (sal) × dom (costt) × dom (nrpers) ×
× dom (durata)
R-UPex={r-upgaraj→geogr.regiune, r-upgaraj→tip_garaj, r-upgeogr.regiune→tara, r-

upclient→geogr.regiune, r-upvehicul→model, r-upmodel→marca, r-upzi→luna, r-upluna→an}
unde r-uplevel1→level2 este o funcţie ce asociază membrii nivelului 1 la membrii
nivelului superior 2.
De exemplu: r-up garaj→geogr.regiune(“Cluj”)=”Vest”.
67
Cex={creparaţie_vehicul} cu Creparaţie_vehicul:
dom (reparaţie_vehicul)→codom (reparaţie_vehicul)
De exemplu: creparaţie_vehicul (“Popescu”, “Cluj”, “01/01/97”, “B-07-NID”)= ($500,
$200, $700, 2, 8)
AVex={avvârsta, avvenit} cu
avvârsta : dom (client)→dom (vârsta) şi avvenit: dom (client)→dom (venit)
De exemplu: avvârsta(“Popescu”)=70; avvenit(“Popescu”)=50000$
O schemă MD consistentă ℳ=<F, L, A, gran, class, attr> trebuie să respecte
următoarele restricţii:
fiecare colecţie de fapte trebuie să fie asociată la cel puţin un nivel;
fiecare nivel trebuie să facă parte dintr-o ierarhie de clasificare sau să fie
asociat la o colecţie de fapte (niveluri izolate nu există);
fiecare atribut trebuie să fie asociat fie la o colecţie de fapte sau la un nivel
dimensional;
nu se permit ierarhii dimensionale izolate (nu sunt conectate la o colecţie
de fapte).
Costc an
sal
luna
costt Tip
garaj
ziua
nrpers
durata
marca model masina garaj regiune tara
vârsta
client
costc=costuri componente
venit sal=salarii
costt=costuri totale
nrpers=număr persoane
Figura 2.17 Reprezentarea grafică a unui model MD
68
2.4 Evaluarea modelelor multidimensionale
Un model de date [ELMA94, BATI92] este un set de concepte ce pot fi

utilizate pentru a descrie structura unei baze de date. Modele de date pot fi
clasificate în:
modele conceptuale (high-level models): oferă concepte ce sunt apropiate
de modul în care utilizatorii percep datele şi sunt independente de
implementare;
modele logice: oferă concepte ce pot fi înţelese de utilizatorii finali şi
depind de tipul de SGBD utilizat .
modele fizice (low-level models): oferă concepte ce descriu detalii despre
cum sunt stocate fizic datele (descrierea datelor pe suport fizic), depinzând
de SGBD-ul utilizat ;
De exemplu, într-un mediu tranzacţional, proiectarea la nivel conceptual poate
utiliza modelul entitate-asociere sau limbajul de definire obiectual (Object
Definition Language-ODL) pentru a reprezenta ideile utilizatorilor, la nivel logic se
poate utiliza modelul relaţional, ierarhic sau reţea şi la nivel fizic implementarea
depinde de SGBD-ul folosit (de exemplu Oracle, Informix, ObjectStore etc)
(figura 2.18). Într-o manieră asemănătoare, într-un mediu OLAP (figura 2.18) se
poate folosi modelul de date multidimensional la nivel conceptual şi în funcţie de
arhitectura aleasă: relaţional-OLAP (ROLAP), orientat-obiect-OLAP (O3LAP) sau
multidimensional (MOLAP) se poate folosi un model diferit la nivel logic şi un
SGBD diferit pentru implementare.
În afară de cele trei modele menţionate mai sus, există un set de modele (la
nivel formal) al căror concepte nu pot fi utilizate în etapa de proiectare a bazei de
date, dar oferă un cadru teoretic şi includ o algebră sau calcul. De exemplu, în
mediu tranzacţional, un model formal ar putea fi algebra relaţională. Conform cu
această clasificare, modelele multidimensionale pot fi: modele multidimensionale
conceptuale, modele multidimensionale logice, modele multidimensionale fizice şi
modele multidimensionale formale.
Mediu tranzacţional SGBDOO Mediu OLAP
ODL SGBDMD
idei relaţii SGBDR idei MDDM clase SGBDOO
E/R relaţii SGBDR
Figura 2.18 Procesul de modelare a datelor în mediu tranzacţional şi mediu OLAP
69
Următoarele modele sunt considerate modele conceptuale: modelul lui Lehner

[LEHN98], modelul lui Cabibbo şi Torlone [CABB98], modelul lui Golfarelli
[GOLF98], modelul lui Blaschka [BLAS00], modelul StarER [TRYF99] şi
modelul MAC [TSOI01]. Aceste modele încearcă să reprezinte modul cum
utilizatorii percep un cub multidimensional, fără să acorde o atenţie deosebită
formalismului. Modelul StarER [TRYF99] este un model de date bazat pe modelul
entitate-asociere care satisface următoarele cerinţe: modelează faptele şi
propietăţile lor, asociază dimensiunile temporale la fapte, modelează obiecte,
propietăţile lor şi asocierile dintre ele, modelează asocierile între obiecte şi fapte.
Elementele constructive ale modelului sunt : faptele, entităţile, asocierile între
entităţi şi fapte (1:1, 1:m, n:m) şi atributele (propietăţi statice ale entităţilor,
asocierilor sau faptelor).
Următoarele modele sunt considerate modele logice: modelul lui Kimball
[KIMB96], modelul lui Mangisengi şi Wagner [MANG99], modelul lui Moody şi
Kortink [MOOD00] şi modelul lui Teste [TEST00]. În [KIMB96] se defineşte
schema stea (star join schema) ca fiind compusă dintr-o tabelă de fapte centrală, de
dimensiuni mari şi un set de tabele de dimensiuni mai mici. În [MANG99] se
defineşte conceptul de relaţii imbricate (nested relations), relaţii care nu sunt în
forma normală unu. O relaţie imbricată este o relaţie ale cărui atribute pot fi alte
relaţii. Prin relaţii imbricate se pot specifica nivelurile de detaliu diferite ale
măsurilor. În [MOOD00] se prezintă o metodologie de proiectare a modelelor
multidimensionale plecând de la modelele entitate-asociere. Schemele
multidimensionale propuse sunt caracterizate de niveluri diferite de denormalizare,
în fiecare tabelă de fapte sau tabelă de dimensiuni. Autorii prezintă următoarele
tipuri de scheme multidimensionale:
schema flat conţine un număr minim de tabele de fapte şi nici o tabelă de
dimensiuni, deoarece sunt denormalizate şi toate informaţiile sunt stocate
în tabele de fapte. Toate joncţiunile sunt antecalculate;
schema cu etaje (terraced) conţine numai tabele de fapte şi nici o tabelă de
dimensiuni. Această schemă antecalculează numai joncţiunile stea (care
implică o tabelă de fapte şi o tabelă de dimensiuni);
schema stea conţine tabele de fapte şi tabele de dimensiuni. Ierarhiile nu
sunt prezentate în mod explicit;
schema constelaţie (constellation);
schema galaxie (galaxy);
schema fulg de zăpadă este o schemă stea normalizată;
schema stea cluster (star cluster) este o schemă fulg de zăpadă în care
tabelele de dimensiuni, ce nu au ierarhii multiple, sunt compuse într-o
singură tabelă de dimensiuni.
70
La nivel formal, s-au identificat următoarele modele: modelul lui Agrawal

[AGRA97], modelul lui Li şi Wang [LIWA96], modelul lui Gyssens [GYSS97],
modelul lui Vassiliadis [VASS98] şi modelul lui Guazzo [GUAZ00]. În
[AGRA97] se prezintă unul din primele modele multidimensionale şi probabil unul
de referinţă. Principalele caracteristici ale acestui model sunt: tratamentul simetric
al măsurilor şi dimensiunilor, un set minim de operatori, care pot fi prezentaţi şi în
limbajul SQL şi posibilitatea de a defini ierarhii multiple într-o dimensiune. Acest
model nu oferă prea multe elemente conceptuale pentru a modela o schemă
conceptuală multidimensională. În [GYSS97] modelul permite cereri ad-hoc,
gruparea şi agregarea seturilor de date. Se propune, de asemenea, o algebră
asemănătoare cu algebra relaţională. Operatorii fold şi unfold permit conversia
măsurilor în atribute dimensionale şi invers. În [VASS99] şi [VASS00] se descrie
un alt model formal pentru date multidimensionale, care poate fi implementat în
arhitectura ROLAP şi MOLAP.
La nivel fizic, se pune accentul mai mult pe tehnicile de stocare utilizate,
specifice SGBD-ului şi mai puţin pe definirea unui model de date.
În tabelul 2.2 se prezintă o sinteză a clasificării modelelor multidimensionale
pe cele trei niveluri: conceptual, logic şi formal. Se constată că modelele
conceptuale oferă un set mai bogat de construcţii semantice, în scopul de a captura
ideile utilizatorilor. Se observă, de asemenea, că cele mai recente modele folosesc
mai multe semantici. Aceasta poate fi interpretată ca o tendinţă a îmbogăţirii
semantice a modelelor multidimensionale.
Tabelul 2.2
Analiză comparativă a modelelor multidimensionale
Nivelul Modele extensii ale Modele orientate pe cub
modelului relaţional
conceptual StarER, Lehner, Cabibbo, Golfarelli,
Blaschka, MAC
logic Kimball, Teste
formal Teste, Li şi Wang, Gyssens, Cabibbo, Agrawal, Vassiliadis,
Guazzo
În [BLAS99] Carsten Sapia prezintă un set de cerinţe pe care ar trebui să le
aibă un model de date multidimensional şi limbajul lui de interogare. Aceste
cerinţe sunt derivate din principiile generale de proiectare ale sistemelor
informatice ce au utilizat modelul relaţional şi de la caracteristicile aplicaţiilor
OLAP dezvoltate:
Principii generale de proiectare. Cerinţele generale pentru selectarea unui
model de date formal, ce poate servi ca un fundament pentru sistemele de baze de
date multidimensionale, sunt similare cu acelea ce au determinat succesul
modelului relaţional şi anume:
un model independent de implementare. Modelul formal trebuie să fie pur
conceptual, să nu conţină vreun detaliu de implementare. Această cerinţă
este importantă în special, pentru sistemele ROLAP care implementează
multidimensionalitatea prin maparea modelului multidimensional logic la
71
un model relaţional. În acest caz, nivelul relaţional trebuie să fie considerat

ca structura “fizică” pentru stocarea datelor.
separarea structurii de date de conţinut. Formalismul trebuie să permită
definiţia separată a structurii de date (cubul multidimensional şi
dimensiunile lui) şi a conţinutului (valorile din celule).
limbaj de interogare declarativ. Analog cu limbajul SQL, limbajul de
interogare multidimensional (calcul logic sau algebră) trebuie să fie
declarativ, pentru a permite optimizarea cererii şi independenţa datelor.
Pe lângă aceste cerinţe generale, aplicaţiile OLAP au o serie de cerinţe speciale
ce nu se aplică la alte domenii de aplicaţii pentru analiza multidimensională.
Aceste cerinţe sunt:
Dimensiuni structurate complex. Dimensiunile oferă informaţii de context
despre datele ce sunt analizate. Pentru a prezenta aceste cerinţe, autorii utilizează
un exemplu. O firmă de maşini doreşte să analizeze reparaţiile de maşini pentru a
îmbunătăţi produsele ei, să definească noi politici de garanţie şi să crească calitatea
garajelor. Subiectul de analiză este “reparaţia maşinii”. Dimensiunile acestei
aplicaţii sunt: maşina ce este reparată (de exemplu maşina lui Ionescu), garajul ce
face reparaţia şi ziua când se execută reparaţia (de exemplu 27 Iunie). Pentru
aplicaţiile OLAP, din perspectiva utilizatorului OLAP, elementele (respectiv
instanţele) unei dimensiuni (membrii dimensiunii) nu sunt ordonate linear (de
exemplu garajele). O excepţie de la această regulă este dimensiunea Timp ce
posedă o ordine moştenită. Pentru a structura o dimensiune sunt utilizate ierarhiile.
Fiecare nivel ierarhic conţine un set distinct de membri. Un nivel L1 al ierarhiei se
poate agrega (roll-up) la alt nivel L2 . Semantica acestei relaţii este că nivelul L2
reprezintă o clasificare (sau abstractizare) a conceptelor lui L1. Pentru a descrie o
ierarhie, este necesar a modela structura unui nivel (level structure) şi a determina
corespondenţa între elementele nivelului inferior şi elementele nivelului superior
(structura membru/member structure). Ambele structuri ale unei dimensiuni pot fi
vizualizate folosind grafice, unde nivelurile/membrii apar ca noduri şi relaţiile de
agregare ca arce. De exemplu, garajele pot fi clasificate după regiunea geografică
(de exemplu Bavaria) sau după tipul de garaj (de exemplu cu contract sau
independent). În terminologia OLAP, se spune ca nivelul ierarhic “garaj” roll up la
nivelurile “regiune geografică” şi “tip de garaj”. Logic se definesc două ierarhii
distincte pe dimensiunea Garaj. Un alt mod de structurare a dimensiunilor, din
punctul de vedere al utilizatorului, este utilizarea atributelor dimensionale. Aceste
atribute descriu membrii dimensiunii, dar nu definesc ierarhii (de exemplu numele
şi adresa propietarului actual al unei maşini). Nivelurile ierarhiilor pot avea diferite
atribute dimensionale. Ierarhiile şi atributele ce structurează dimensiunile sunt
elementele componente ale schemei conceptuale a bazei de date.
Măsuri complexe. Conţinutul unei celule a cubului multidimensional poate fi,
de asemenea, structurat într-un mod complex. Fiecare celulă poate conţine o serie
de măsuri ce formează o structură tip înregistrare. Aplicaţiile OLAP adesea conţin
un volum mare de măsuri derivate (măsuri ce nu sunt atomice, în sensul că ele pot
fi calculate de la alte măsuri atomice sau derivate). În exemplu prezentat, sunt
definite următoarele măsuri: ”salariul”, „costul pieselor componente”, „costul
total”, „durata de reparaţie” şi „numărul de persoane” implicate într-o reparaţie.
„Costul total” este o măsură derivată, se calculează din costurile pieselor
72
componente şi salarii. Conceptul de măsuri derivate este similar cu conceptul de

viziune din sistemele relaţionale. Astfel, definiţia măsurilor derivate (formula de
calcul) ar trebui să fie o parte a schemei conceptuale a bazei de date. Măsurile
atomice şi cele derivate trebuie tratate egal de limbajul de interogare. De asemenea,
aditivitatea unei măsuri de a lungul unei dimensiuni ar trebui să fie exprimată în
modelul conceptual.
Tipuri de cereri. Cererile multidimensionale selectează hiperplane (adesea
două dimensiuni) din spaţiul multidimensional. Pentru a reduce dimensionalitatea
cubului rezultat pot fi formulate predicate pe nivelurile dimensiunilor (de exemplu
an=1997). Pentru fiecare dimensiune se poate stabili un nivel de granulaţie printr-
un predicat de restricţie. Acesta defineşte implicit operaţiile de agregare necesare.
Restricţiile pot fi formulate utilizând, de asemenea, măsuri în predicat (de exemplu
numărul de persoane>3). Un limbaj de interogare trebuie să permită, de asemenea,
integrarea funcţiilor definite de utilizator, precum şi operaţii de navigare prin
ierarhiile dimensiunilor. În tabelul 2.3. se prezintă o evaluare a modelelor de date
multidimensionale în funcţie de aceste criterii.
În [VASS99], Vassiliadis propune un alt set de criterii de evaluare a modelelor
multidimensionale şi anume: modelarea spaţiului multidimensional sub formă de
cuburi sau tabele (notate cu C sau T), modelarea ierarhiilor, caracterul limbajului
de interogare (procedural, declarativ, vizual) şi arhitectura utilizată pentru
implementare (ROLAP şi/ sau MOLAP). În tabelul 2.4. se prezintă o evaluare a
modelelor multidimensionale în funcţie de aceste criterii.
73
Tabelul 2.3
Evaluarea modelelor multidimensionale conform cerinţelor prezentate
în [BLAS99]
Modelarea măsurilor Formalism pentru limbaj de

Separa- Modelarea dimensiunilor complexe
complexe interogare
rea Sime-
expli- trie Funcţii
Atri-
Model cită Forma- măsuri de
Nivel bute
struc- Membri lism şi tip Ierarhii agreg.
ierar- dimen Deriv Adititiv Tip
tura/ pentru membri înreg ad-hoc defi-
hic sio
conţinut niveluri nite de
nale
utiliz.
Agrawal Nu Nu Nu Da Nu Da Nu Nu Nu alge- Da Da
bra
Li/Wang Da Da Da Da Da Nu Nu Nu Nu alge- Da Da
bra
Gyssens Da Da Da Da Da Da Da Nu Nu alge- Da Da
bra si
calcul
Cabbibo Da Da Da Da Nu Da Nu Nu Nu alge- Da Da
bra si
calcul
Vassiliadis Nu Da Da Da Nu Da Nu Nu Nu alge- Nu Nu
bra
Lehner Da Da Da Da Da Nu Nu Nu Pe alge- Nu Nu
măsura bra
Golfarelli Da Da Da Nu Da Nu Da Da Da alge- Da Nu se
bra speci-
fica
MAC Da Da Da Nu Nu Da Nu Da Nu Nu Nu Nu
StarER Da Da Da Nu Da Da Nu Da Nu Nu Nu Nu
Blaschka Da Da Da Da Da Da Da Da Nu alge- Nu Nu
bra
Teste Da Da Da Da Da Da Nu Nu Nu alge- Nu Nu
bra
Tabelul 2.4
Evalurea modelelor de date multidimensionale conform cerinţelor prezentate
în [VASS99]
Spaţiu Limbajul de interogare Arhitectura

multidimensional implementată
Modele Cuburi Ierarhii Procedural Declarativ Vizual ROLAP MOLAP
Orientat Gray T - - extensie - da -

pe SQL
relaţional
Li/Wang T Implicit algebra - - da -
Gyssens T da algebra calcul - da -
Teste T da algebra - - da -
StarER T da - - - da -
Orientat Agrawal C - algebra - - da da
pe cub
Cabibbo C da algebra calcul da da da
Vassiliadis C da algebra - - da da
Lehner C da algebra - - da implicit
Golfarelli C da algebră - - da da
MAC C da - - - - da
Guazzo C da algebra - - - da
Blaschka C da algebra - da da da
74
Rezumat
La ora actuală există un număr mare de modele de date multidimensionale
propuse. Cele mai multe dintre ele sunt modele de date logice şi numai câteva pot
fi considerate pur conceptuale. Fiecare prezintă o viziune proprie a cerinţelor
analizei multidimensionale, o terminologie şi un formalism propriu.
Modelele de date multidimensionale s-au dezvoltat pe două direcţii şi anume:
modele extensii ale modelului relaţional şi modele orientate pe cub.
Pentru a descrie în detaliu modelele de date multidimensionale şi a putea fi
înţelese, se utilizează o serie de concepte de bază şi anume: cubul n-dimensional,
multicubul, dimensiunile, ierarhiile şi măsurile.
Combinaţia de multiple dimensiuni şi multiple niveluri pe dimensiune
constituie esenţa unui cub n-dimensional.
Dimensiunile furnizează informaţii descriptive despre fiecare indicator, conţin
în general date statice şi sunt esenţiale pentru analiză.
Cele mai multe dimensiuni au o structură multi-nivel sau ierarhică. Ierarhiile
sunt fundamentul pentru agregarea datelor şi pentru navigarea între nivelurile de
detaliu dintr-un cub n-dimensional.
O măsură este un indicator de performanţă prin care se poate analiza
performanţa activităţii modelate. Valorile unui indicator se modifică continuu.
Datele multidimensionale sunt împrăştiate şi celulele de date nu sunt
distribuite în mod egal în spaţiul multidimensional. Proiectanţii de instrumente
OLAP au adoptat o varietate de strategii pentru a trata fenomenul de împrăştiere
dar şi gruparea datelor.
Cuvinte cheie
Cub n-dimensional, dimensiune, structură multicub, ierarhie, măsură, împrăştierea
datelor, model multidimensional conceptual, model multidimensionl logic, schema
stea, schema fulg de zăpadă, modele de date OLAP extensii ale modelului
relaţional, modele orientate pe cuburi.
75
Capitolul 3
Arhitectura sistemelor OLAP
Sistemele OLAP permit analiştilor şi managerilor să îmbunătăţească
performanţele unei firme, printr-un acces interactiv rapid la o mare varietate de
viziuni de date organizate, pentru a reflecta aspectul multidimensional al datelor
dintr-o întreprindere. Modelul conceptual multidimensional este cel mai natural
mod de a vizualiza informaţiile din afaceri. Dar stocarea acestor volume mari de
informaţii multidimensionale, într-un mod practic pe calculator, este departe de a fi
uşor. Datele multidimensionale nu trebuie să fie numai stocate ci trebuie să fie
vizualizate, actualizate şi folosite pentru calculul altor rezultate, preferabil în mai
puţin de cinci secunde. Modul cum sunt stocate va afecta performanţa şi
funcţionalitatea la fiecare din celelalte cerinţe. Din acest motiv, instrumentele
OLAP trebuie să ofere un răspuns rapid, indiferent de volumul de date ce trebuie
utilizat pentru o simplă interogare. Timpul de răspuns pentru o cerere ar trebui să
depindă de numărul de rezultate afişate pe ecran şi nu de dimensiunea bazei de
date. În practică, cele mai multe aplicaţii OLAP sunt foarte împrăştiate. În general
mai puţin de o celulă dintr-o mie de celule are date. Deoarece aplicaţiile OLAP
sunt de fapt sisteme suport de decizie interactive, este important ca ele să rămână
rapide, chiar dacă baza de date este mare şi împrăştiată. Se urmăreşte să se
consume mai puţin spaţiu fizic pentru stocarea informaţiilor lipsă sau a indecşilor.
Multe soluţii există, fiecare cu avantaje şi dezavantaje.
Factorii ce determină alegerea unei soluţii sunt :
Volumul de date curente stocat. Dacă volumul este relativ mic, o stocare
în RAM ar fi cea mai bună soluţie;
Gradul de împrăştiere a datelor. Dacă datele sunt foarte împrăştiate, poate
fi necesară o indexare mai complexă şi compresia datelor, care vor face
instrumentul mai lent;
Frecvenţa de actualizare a datelor şi modul cum se face actualizarea (în
loturi sau celule individuale);
Numărul de utilizatori;
Tipul arhitecturii client/server (unde are loc procesarea
multidimensională);
Cantitatea de memorie reală şi virtuală valabilă. Aceasta va determina câte
date active trebuie păstrate în memorie;
76
Performanţa discului şi a microprocesorului;

Frecvenţa de modificare a dimensiunilor bazei de date etc.
Ţinând cont de aceşti factori, proiectanţii de instrumente OLAP selectează
tehnicile pe care le vor utiliza pentru a stoca şi gestiona datele multidimensionale,
pentru aceste aplicaţii. Astfel, nici un instrument nu este optim pentru orice
aplicaţie OLAP. Toate instrumentele folosesc o combinaţie de tehnici. Prima
decizie ce trebuie luată este de a stabili unde sunt stocate datele din model, când
sunt procesate şi accesate.
În ultimii ani, un număr mare de instrumente OLAP permit stocarea datelor
atât în baze de date relaţionale cât şi multidimensionale. Astfel, modul de stocare a
datelor a devenit un criteriu de clasificare a sistemelor OLAP şi anume în: sisteme
ROLAP, sisteme MOLAP şi sisteme HOLAP. În acest capitol, se vor prezenta
comparativ aceste sisteme. Se va pune accentul pe avantajele şi dezavantajele lor,
precum şi pe tipurile de aplicaţii pentru care sunt destinate. În finalul capitolului, se
prezintă comparativ tipurile de arhitecturi specifice sistemelor OLAP.
3.1 Sisteme ROLAP

În ultimii ani, un număr mare de instrumente OLAP permit stocarea datelor
multidimensionale în baze de date relaţionale (depozite de date). Chiar dacă o
aplicaţie OLAP stochează toate datele sale într-o bază de date relaţională, totuşi ea
va lucra separat, pe o copie separată a datelor (depozite de date/centre de date), nu
pe baza de date tranzacţională. Aceasta permite să fie structurată optim pentru
OLAP, mai bine decât pentru alte aplicaţii. Datele multidimensionale pot fi stocate
în depozite de date/centre de date, utilizând schema stea sau fulg de zăpadă.
Problema este de a oferi acces rapid şi flexibilitate în manipularea
multidimensională. Totuşi tabela de fapte este un mod ineficient de a stoca volume
mari de date. Dacă sunt multe variabile, există posibilitatea de a nu le putea stoca
pe toate într-o singură tabelă de fapte (gradul de împrăştiere poate diferi mult între
grupurile de variabile). Datele pot fi încărcate din multiple surse, astfel
actualizările unei singure tabele de fapte foarte mare sunt ineficiente. De aceea, în
aplicaţiile complexe, tabela de fapte este partiţionată în grupuri de variabile după
gradul de împrăştiere, stabilindu-se, de asemenea, dimensiunile corespunzătoare şi
sursele de date. În aplicaţiile OLAP complexe pot exista 10..20 de tabele de fapte.
Pentru o bună performanţă la interogare, unele agregări trebuie antecalculate şi
stocate în tabele de agregate. În aplicaţiile complexe pot exista mii de tabele de
agregate.
În figura 3.1, este prezentată arhitectura unui sistem ROLAP. Un motor
ROLAP face trecerea dinamică între modelul de date multidimensional logic M şi
modelul de stocare relaţional R. Tehnic vorbind acest motor implementează o
transformare a unei cereri multidimensionale m pe modelul de date
multidimensional logic M, într-o cerere relaţională r pe modelul de stocare R.
Eficienţa la interogare este factorul dominat asupra performanţei globale a
sistemului şi scalabilităţii. Strategiile de optimizare sunt factorii principali în
77
diferenţierea sistemelor ROLAP existente. Preocuparea majoră este găsirea celei

mai eficiente reprezentări a cererii pentru un SGBDR dat şi a schemei date, precum
şi încărcarea dinamică echilibrată între SGBDR şi motorul ROLAP. Întrucât
optimizatorul de cereri al SGBDR ar putea să nu fie capabil să aleagă planul de
execuţie optim pentru cereri, unele instrumente (de exemplu DSS
Server/Microstrategy) împart cererea complexă în mai multe subcereri, care sunt
executate secvenţial (SQL în mai mulţi paşi). Să considerăm QR(m) setul tuturor
reprezentărilor relaţionale ale cererii multidimensionale m pentru modelul
relaţional R (incluzând toate variantele în mai mulţi paşi). Pentru fiecare cerere,
motorul ROLAP trebuie să aleagă o reprezentare optimă pe baza unui criteriu (de
exemplu performanţa cererii).
Unele operaţii multidimensionale nu pot fi exprimate uşor folosind limbajul
SQL. Este necesar pentru motorul ROLAP să implementeze aceste operaţii
folosind structuri de date multidimensionale. Aceasta complică problema de
optimizare prin extinderea spaţiului de căutare QR(m). Încărcarea echilibrată între
serverul de bază de date şi motorul ROLAP este un rezultat al strategiei utilizate
pentru a alege cererea optimă. Evaluarea operaţiilor multidimensionale de către
motorul ROLAP poate reduce timpii de procesare a unei cereri, dar şi scalabilitatea
globală a sistemului.
Aplicaţia analitică
client
Clienţi OLAP
Interfaţa
multidimensională
optimizarea cerererii procesarea multidimensională

multidimensionale Motor ROLAP
metadate
generarea cererii transformare

relaţionale
SQL interfaţa
relaţională
SGBDR
Figura 3.1 Arhitectura unui sistem ROLAP
Factorii ce influenţează decizia de optimizare pot fi împărţiţi în statici şi

dinamici (ce pot fi evaluaţi numai la momentul execuţiei). Factorii statici sunt:
natura operaţiei multidimensionale, complexitatea operaţiei executate de motorul
78
ROLAP faţă de complexitatea implementării relaţionale. Factorii dinamici includ

caracteristicile de încărcare ale serverului de bază de date şi ale motorului ROLAP,
volumul datelor curente ce trebuie să fie transferate de la sistemul relaţional la
motorul ROLAP. De exemplu, Decision Suite/Microstrategy permite
administratorului să determine locaţia procesării prin metadate.
Alte probleme ale instrumentelor ROLAP sunt metamodelele (pentru o schemă
stea sau fulg de zăpadă metamodelul este foarte important), seturile de funcţii
complexe etc. Limbajul SQL standard nu permite operaţii multidimensionale.
Specialiştii oferă trei soluţii pentru a adăuga funcţionalitate multidimensională la
datele stocate în tabelele SQL:
integrarea procesării multidimensionale în sistemul de gestiune a bazei de
date relaţionale, fie prin extinderea limbajului SQL sau prin adăugarea
funcţionalităţii multidimensionale în nucleul SGBD-ului;
executarea în mai mulţi paşi a comenzilor SQL (multipass SQL).
Instrumentul OLAP realizează o serie de comenzi SELECT, în care ieşirile
comenzilor anterioare sunt stocate în tabele temporale, care sunt apoi
utilizate de comenzile următoare;
încărcarea datelor relevante din tabelele corespunzătoare pe un server de
aplicaţie intermediar, unde este realizată procesarea multidimensională.
Datorită modului complicat în care datele sunt stocate pe disc, instrumentele
OLAP ce folosesc baze de date relaţionale permit numai citirea datelor. Alte
instrumente trebuie să fie utilizate pentru actualizarea datelor de bază şi a tabelele
de agregate. Aceste instrumente ROLAP nu pot fi folosite pentru analize de tip
“what-if”.
În concluzie, stocarea datelor multidimensionale se face într-o bază de date
relaţională atunci când:
Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu sunt
copiate în baza de date multidimensională ci sunt stocate în baze de date
relaţionale sursă (depozite de date/centre de date) şi citite când este nevoie;
Datele sursă se modifică frecvent şi este mai bine de a citi în timp real
decât din copii;
Integrarea cu alte sisteme informatice relaţionale existente;
Firma are o politică de neduplicare a datelor în alte structuri de fişiere,
pentru securitate sau alte motive, chiar dacă aceasta conduce la aplicaţii
mai puţin eficiente;
Câteva avantaje ale sistemelor ROLAP sunt:
se integrează cu tehnologia şi standardele existente;
sistemele MOLAP nu permit cereri ad-hoc eficace, deoarece sunt
optimizate pentru operaţii multidimensionale;
actualizarea sistemelor MOLAP este dificilă;
sistemele ROLAP sunt adecvate pentru a stoca volume mari de date, prin
utilizarea procesării paralele şi a tehnologiilor de partiţionare etc;
sistemele MOLAP sunt limitate la 5-10 dimensiuni şi sunt adecvate pentru
aplicaţii departamentale cu volume mici de date şi dimensionalitate
79
limitată, iar sistemele ROLAP au o arhitectură flexibilă ce oferă suport

pentru o varietate mare de SSD-uri şi cerinţe analitice (figura 3.2);
volatilitatea descrie gradul la care datele şi structurile de date se modifică
în timp. Datele cu un nivel de volatilitate scăzut rămân relativ constante.
De exemplu, datele despre timp au un nivel scăzut de volatilitate (zilele
sunt grupate întotdeauna în luni şi lunile sunt întotdeauna grupate în ani).
Datele despre produse, angajaţi, clienţi se modifică frecvent. Volatilitatea
datelor afectează cerinţele de procesare în lot ale sistemului. Ori de câte ori
datele atomice se modifică, datele agregate, ce au fost antecalculate,
trebuie să fie recalculate. De aceea, datele volatile au un impact mai mare
asupra unui sistem, care conţine un volum mare de informaţii agregate,
decât asupra unui sistem care calculează valorile agregate la momentul
execuţiei. Atât sistemele ROLAP cât şi cele MOLAP sunt optime pentru
aplicaţii cu volatilitate scăzută a datelor. Pentru aplicaţiile cu volatilitate
ridicată a datelor, numai sistemele ROLAP sunt optime.
Atomicitate
(Gb) 1000
1 2
100
3 ROLAP 4
10
5 6
MOLAP
10 100 1000 dimensionalitate
1=SSD pentru analiza vânzărilor (activitate de comerţ) 4=SSD pentru analiza poliţelor de asigurare
2=SSD pentru analiza promoţională 5=EIS pentru analiza financiară
3=SSD pentru analiza profitului bancar 6= SSD pentru analiza creditului bancar
Figura 3.2 Utilizarea sistemelor MOLAP sau ROLAP pentru diferite tipuri
de aplicaţii SSD
3.2 Sisteme MOLAP
Cel mai evident mod de a stoca datele multidimensionale este ca o simplă

matrice. Spaţiul este rezervat pentru fiecare combinaţie posibilă între membrii
dimensiunilor. În unele instrumente, numai valorile nenule sunt stocate. Numai
matricile ce conţin date sunt stocate fizic. Fiecare dimensiune a matricii reprezintă
o dimensiune a cubului. Conţinutul matricii sunt măsurile cubului. O astfel de
matrice are multe avantaje: se identifică rapid locaţia oricărei celule, iar celulele
pot fi actualizate fără a afecta locaţia fizică a celorlalte celule. Totuşi stocarea
datelor pe disc folosind o simplă matrice, ce reflectă direct viziunea utilizatorului,
80
este foarte rar eficientă. Chiar şi atunci când datele sunt stocate în memorie, este
adesea necesar de a păstra datele într-un format mai complex decât o simplă
matrice. Aceasta are legatură cu fenomenul de împrăştiere şi cu cerinţa de a
modifica dimensiunile, fără să fie nevoie să se reconstruiască din nou întreaga
matrice. În cazul stocării pe disc a datelor împrăştiate, datele sunt citite în blocuri şi
dacă fiecare bloc are un grad de împrăştiere mare, multe blocuri goale sau aproape
goale vor fi stocate în memorie, iar memoria va fi utilizată de mult mai multe ori
decât este necesar.
Sistemele MOLAP au pus accentul pe flexibilitatea şi optimizarea tehnicilor de
stocare şi pe conceptul de tranzacţie. Sistemele MOLAP nu au încă o tehnologie
pentru stocarea şi gestionarea datelor unanim acceptată. Stocarea fizică a datelor
multidimensionale, precum şi fenomenul de împrăştiere sunt preocupări majore, în
domeniul bazelor de date multidimensionale. O tehnică de stocare a datelor optimă
ar trebui să ţină cont de mulţi factori dinamici şi anume:
profilul datelor şi volumul lor (numărul de dimensiuni şi membrii ai

dimensiunilor, tipuri de date etc);
fenomenul de împrăştiere (în care dimensiuni sau combinaţii de
dimensiuni, tipul de împrăştiere);
frecvenţa de modificare în sursele de date (cât de des vor fi actualizate
bazele de date multidimensionale);
frecvenţa de modificare în datele multidimensionale;
frecvenţa de modificare în modelul multidimensional ;
accesul concurent.
Ideal un SGBD multidimensional (SGBDMD) ar trebui să aleagă structura de

date optimă în funcţie de aceşti factori. În cele mai multe SGBDMD comerciale se
utilizează o tehnică de stocare pe două niveluri. La nivelul inferior sunt stocate
toate dimensiunile dense. Nivelul superior conţine dimensiunile împrăştiate ca o
structură index, care conţine pointeri la cuburile de date dense din nivelul inferior.
Unele instrumente OLAP oferă administratorului un număr foarte limitat de
opţiuni de optimizare. De exemplu, Arbor Essbase are o metodă proprie pentru
stocarea şi încărcarea datelor multidimensionale în memorie. Aceasta metodă
utilizează o structură multinivel (cu un număr arbitrar de niveluri pentru diferitele
grade de împrăştiere). Administratorul poate specifica dimensiunile dense şi
împrăştiate, care construiesc cele două niveluri. Oracle Express suportă, de
asemenea, o structură pe două niveluri. Pilot Decision Support Suite (Pilot
Software) suportă aşa numitele multicuburi. Timpul este tratat ca o dimensiune
densă, iar toate celelalte dimensiunile sunt considerate împrăştiate.
O altă problemă este transferul conceptului de tranzacţie aşa cum este cunoscut
şi acceptat în lumea relaţională la SGBDMD. Puţine instrumente MOLAP (de
exemplu Arbor Essbase ) permit acces multiutilizator concurent atât la citire cât şi
la scriere. Majoritatea instrumentelor MOLAP permit acces multiutilizator la citire
şi monoutilizator la scriere. SGBDMD blochează întreaga bază de date în timpul
81
actualizărilor (o formă foarte simplă de acces concurent). De asemenea, multe

instrumente MOLAP au o noţiune foarte vagă a conceptului de tranzacţie.
Modificările în cuburile de date pot fi executate ca adăugări în cub sau în timpul
analizei de tip “what if”. Adesea ele cer o actualizare incrementală a agregatelor
sau măsurilor, care sunt calculate pe bază de formulă. Astfel de dependenţe fac
actualizările mult mai complicate. Conceptul de tranzacţie este legat de multe alte
probleme cum ar fi:
propietăţile ACID (atomic, consistency, isolation, durability). Pentru a
realiza propietăţile ACID, toţi termenii (în special consistenţa şi izolarea)
trebuie reanalizaţi. De exemplu, dependenţele între datele de detaliu, datele
agregate şi măsuri complică noţiunea de consistenţă;
mecanismul de blocare. Dacă controlul concurenţial este realizat printr-o
tehnică de blocare, trebuie să fie definite modurile de blocare şi nivelul la
care se face blocarea. Blocarea întregii baze de date nu este o soluţie foarte
potrivită. Interdependenţele între date fac ca definirea nivelurilor de
blocare să fie o problemă complexă;
strategia de propagare a modificărilor. Datele (agregate şi măsuri) trebuie
modificate în conformitate cu modificările din datele de detaliu sau din
modelul de date.
Sunt şi alte probleme importante, deja rezolvate în SGBDR, dar care sunt
nerezolvate sau numai parţial rezolvate în SGBDMD cum ar fi: restaurarea bazei
de date, conceptul de tabelă virtuală etc.
Avantajul sistemelor MOLAP este că oferă o viziune multidimensională
directă a datelor, în timp ce sistemele ROLAP sunt o “interfaţă multidimensională”
la datele relaţionale. SGBDMD cer antecalcularea tuturor agregatelor posibile,
astfel sunt adesea mai performante decât SGBDR tradiţionale, dar mai dificil de
actualizat şi administrat. Deoarece, bazele de date multidimensionale folosesc
acelaşi motor atât pentru stocare cât şi pentru procesarea datelor şi acest motor are
informaţii complete despre structurile de date multidimensionale şi manipulările
multidimensionale, este uşor pentru instrument de a manipula datele
multidimensionale şi de a face calcule corecte şi complexe. Totuşi multe baze de
date multidimensionale nu oferă facilitatea de recuperare a erorilor şi alte facilităţi
specifice bazelor de date relaţionale.
Câteva avantaje ale sistemelor MOLAP sunt:
tabelele relaţionale nu sunt potrivite pentru date multidimensionale;
matricile multidimensionale permit stocarea eficientă a datelor
multidimensionale;
limbajul SQL nu este corespunzător pentru operaţii multidimensionale.
Tabelul 3.1 prezintă o analiză comparativă între sistemele ROLAP şi sistemele
MOLAP.
82
Tabelul 3.1
Analiză comparativă între sistemele ROLAP şi MOLAP
Criterii MOLAP/Baze de date ROLAP/Baze de date
multidimensionale relaţionale
Spaţiul de disc ocupat mare, dacă agregatele sunt posibil zero, dacă sunt
antecalculate (explozia datelor folosite baze de date
derivate şi fenomenul de existente nemodificate
împrăştiere) (depozite de date
virtuale), dar poate fi
mare dacă noi structuri
sunt create
Performanţa la moderată scăzută
încărcarea datelor
Viteza de calcul mare mică
Volumul datelor atomice mediu la mare (Mb-Gb) extrem de mare (Gb-Tb)
Posibilitatea de acces la limitată excelentă în principiu,
date de către alte dar poate fi limitată dacă
aplicaţii (integrare cu este folosită o schemă
alte sisteme existente) complexă
Accesul la date încet şi adesea limitat, performanţă moderată
citire/scriere
Dimensionalitate mică (modele multidimensionale mare (modele
simple, 5-10 dimensiuni) multidimensionale
complexe)
Modificarea bună dar baza de date trebuie să bună
dimensiunilor fie off-line
Volatilitatea datelor adecvate pentru volatilitate adecvate pentru

scăzută volatilitate ridicată
Facilităţi de administrare puţine foarte puternice

a SGBD-ului
Uşurinţa de a construi moderată aproape imposibilă
aplicaţii de către
utilizatorii finali
Arhitectura client/server pe două sau trei client/server pe două sau
niveluri, lipsa standardelor trei niveluri, arhitectură
deschisă, standarde
Managementul nu da
metadatelor
Limbaj de interogare specific fiecărui instrument SQL
Facilităţi de calcul foarte complexe, în toate limitate
dimensiunile
Joncţiuni nu da
Agregări dinamice nu da
Partiţionarea datelor nu da
Cereri paralele nu da
83
Criterii MOLAP/Baze de date ROLAP/Baze de date

multidimensionale relaţionale
Algoritmi hash da da
Indexare da da
Măsuri derivate da da
Comparaţii ale da da
perioadelor de timp
Analiza valutelor nu da
Previziuni da da
Consolidări financiare da da
Tipul aplicaţiilor la nivel departamental la nivelul întreprinderii
În [COLL96], se face o evaluare comparativă a sistemelor ROLAP şi MOLAP.

Se utilizează un model de afaceri cu şase dimensiuni al unei firme de băuturi.
Fiecare dimensiune este compusă dintr-o ierarhie de membri. Se consideră
următorul număr de membrii pentru fiecare dimensiune:
dimensiunea Canal: 6 membri;
dimensiunea Produs: 1500 de membri;
dimensiunea Zona de desfacere: 100 membri;
dimensiunea Timp: 17 membri;
dimensiunea Scenariu: 8 membri;
dimensiunea Măsuri: 50 măsuri;
Se doreşte stabilirea profitului real al firmei pentru luna curentă şi comparaţia
lui cu bugetul alocat, apoi operaţii de drill down pe regiuni de desfacere şi familie
de produse. Sistemul ROLAP utilizează o schemă stea denormalizată. Agregările
sunt antecalculate şi stocate în tabela de fapte. Numărul potenţial de rânduri din
tabela de fapte este produsul cartezian al dimensiunilor:
canal(6)* produs(1500)* piaţa de desfacere(100) * timp(17) * scenariu(8) = 122
milioane.
Dacă se consideră un grad de împrăştiere de 80%, numărul de rânduri este de
24 milioane (20%*122 mil). Dimensiunea unui rând este de 500 bytes şi tabela de
fapte ajunge la 13Gb. Dacă se consideră şi indecşii construiţi pe fiecare coloană
(cod_canal, cod_produs, cod_piaţă, cod_timp şi cod_scenariu) necesari pentru a se
executa joncţiunile, dimensiunea tabelei de fapte ajunge la 17 Gb (blocul de date
de 4Kb) .
În ciuda popularităţii bazelor de date relaţionale în aplicaţiile tranzacţionale,
autorii demonstrează că modelul relaţional nu este potrivit pentru aplicaţii OLAP,
datorită numărului mare de operaţii I/O necesare pentru a executa operaţii simple
de drill down sau calcule simple.
Pentru sistemul MOLAP, datele relevante pentru analiză sunt extrase dintr-un
depozit de date relaţional sau alte surse de date şi încărcate într-o baza de date
multidimensională (un cub cu 6 dimensiuni). Implementarea acestui cub n-
dimensional este specific lui Essbase.
84
Autorii constată că:

încărcarea este foarte rapidă, deoarece datele corespunzătoare oricărei
combinaţii de membrii ai dimensiunilor pot fi încărcate cu o singură
operaţie de I/O, valorile sunt antecalculate, indecşii corespunzători sunt de
dimensiuni mici şi pot fi stocaţi în memorie;
stocarea este foarte eficientă deoarece blocurile conţin numai date, pentru
localizarea unui bloc de date este necesar un singur index, indecşii rezidă
complet în memorie;
calculele sunt eficiente, deoarece numai o singură citire şi o singură scriere
I/O pe bloc sunt necesare pentru a agrega toată baza de date (tabelul 3.2).
Tabelul 3.2
Comparaţie între sisteme ROLAP şi MOLAP
ROLAP MOLAP
Spaţiul ocupat pe disc (Gb) 17 10
Încărcarea datelor(I/O) 240 1
Calculul datelor derivate (timpul I/O în ore) 237 2
În concluzie, bazele de date multidimensionale utilizează cel mult jumătate din

spaţiu, încarcă datele şi calculează datele derivate mult mai repede decât bazele de
date relaţionale.
O serie de instrumente OLAP permit stocarea datelor multidimensionale în
fişiere, pe client (desktop OLAP). Volumul de date multidimensionale stocat pe
client este mic şi poate fi creat la cerere (utilizând facilităţi Web).
3.3 Sisteme hibride (HOLAP)

Un sistem OLAP hibrid (HOLAP) este un sistem care utilizează pentru
stocarea datelor atât baze de date relaţionale cât şi baze de date multidimensionale,
în scopul de a beneficia de caracteristicile corespunzătoare şi de tehnicile de
optimizare. Un sistem HOLAP trebuie să aibă următoarele caracteristici:
transparenţa locaţiei şi a accesului (locaţia datelor utilizate trebuie să fie
ascunsă pentru utilizator). Transparenţa accesului permite utilizatorului să
acceseze datele la fel, indiferent dacă sunt stocate în BDR sau BDMD;
transparenţa fragmentării. Fragmentarea datelor trebuie să fie invizibilă
pentru utilizator (cererile utilizatorului trebuie să fie descompuse în cereri
parţiale în funcţie de sistemul de stocare);
transparenţa performanţei. Trebuie furnizate tehnici de optimizare pentru
ambele sisteme MOLAP şi ROLAP;
un model de date comun utilizat atât de datele relaţionale cât şi de datele
multidimensionale;
85
alocarea optimă în sistemele de stocare. Sistemele hibride ar trebui să

beneficieze de strategiile de alocare specifice sistemelor distribuite.
Sunt diferite arhitecturi pentru un sistem hibrid OLAP:

integrarea sistemelor MOLAP şi ROLAP printr-o interfaţă comună.
Clientul OLAP poate fi luat în considerare într-o astfel de soluţie, întrucât
oferă o interfaţă comună pentru SGBDMD şi motoarele ROLAP. Totuşi
multe din cerinţele listate mai sus nu sunt satisfăcute. De exemplu, Seagate
Holos utilizează această arhitectură, permite tehnici de stocare relaţionale
şi multidimensionale integrate în aşa numita arhitectură OLAP compusă;
integrarea mutuală a sistemelor ROLAP şi MOLAP. Aceasta arhitectură
poate fi găsită la Arbor Essbase, care oferă acces la datele relaţionale (IBM
DB2 OLAP Server);
extensii la SGBDR sau SGBDOR prin utilizarea tehnologiei datablade (de
exemplu Informix cu opţiunea Metacube). Totuşi acesta nu este un sistem
OLAP hibrid (Metacube este un motor ROLAP, deci nu este încă implicat
un SGBDMD).
Aplicaţiile complexe şi cu grad mare de împrăştiere vor folosi o combinaţie a
acestor moduri de stocare. Datele care sunt utilizate cel mai des vor fi stocate în
memoria RAM. Datele care sunt utilizate regulat, dar nu frecvent pot fi stocate în
baze de date multidimensionale optimizate. În final, volumele mari de date
detaliate sunt stocate în baze de date relaţionale sursă. În figura 3.3 [THOM96] se
prezintă strategia de stocare optimă pentru aplicaţii de diferite mărimi şi grade de
împrăştiere. Desigur scara este aproximativă şi va depinde de hardware-ul utilizat.
Împrăştiate
0.00001%
0.00001% stocare în BDR sau

hibrid
0.001%
0.1% stocare în RAM

stocare în BDM
1%
10%
100%
Dense Volumul de date de bază (celule)
Figura 3.3 Moduri de stocare
86
Pentru aplicaţii foarte împrăştiate, o soluţie hibridă este probabil cea mai bună.
Aria graficului, în care sistemele MOLAP sunt recomandate, reflectă abilitatea lor
de a stoca cel mai eficient volume medii până la mari de date. Pentru date foarte
împrăştiate sau pentru baze de date foarte mari, o strategie de stocare de tip bază de
date relaţională poate fi singura opţiune fezabilă. În general, dacă se doreşte
implementarea unei singure aplicaţii, este mai eficient din punct de vedere al
costului de a selecta un instrument mai simplu, decât unul proiectat special pentru
acea aplicaţie. Pentru scopuri strategice şi aplicaţii complexe poate fi necesar de a
achiziţiona un instrument complex. În funcţie de tipul bazei de date, se poate alege
tehnica de indexare folosită. Cele mai multe baze de date multidimensionale
stabilesc automat tehnica de indexare.
3.4 Arhitectura sistemelor OLAP

Aplicaţiile OLAP au o varietate mare de arhitecturi, unele foarte complexe.
Multe aplicaţii OLAP stochează volume mari de date, care nu pot fi duplicate
pentru fiecare utilizator. Această cerinţă impune arhitectură client/server. În
arhitectura client/server, atât clientul cât şi unul sau mai multe procesoare ale
serverului pot face transformări multidimensionale şi calcule. În principiu, se pot
defini mai multe niveluri logice într-o arhitectură client/server (figura 3.4).
Interfaţa 5
Se împart între client şi server
depinde de locaţia datelor
Calcule ad hoc
multidimensionale 4
Calcule făcute în avans pe

server
Calcule
multidimensionale în 3
lot Motor pentru gestiunea datelor-baze
de date relaţionale sau
multidimensionale
Gestiunea datelor 2
Datele şi agregatele stocate trebuie să
fie distribuite între utilizatori
1. Fişiere de date
Figura 3.4 Niveluri logice în arhitectura client/server
87
În general, într-o implementare particulară, nu toate aceste niveluri logice pot

exista ca niveluri distincte, astfel încât două sau mai multe pot fi combinate într-un
singur program [THOM96]. Totuşi în cazuri extreme, ar putea fi niveluri separate,
executate pe maşini separate. În figura 3.4 volumele de date transmise între niveluri
sunt indicate de grosimea săgeţilor. Volumele vor varia în funcţie de aplicaţie.
Figurile de la 3.5. la 3.9. ilustrează diferite tipuri de configuraţii client/server, iar
tabelul 3.3. prezintă avantajele şi dezavantajele lor [THOM96].
Server de fişiere client OLAP

Fişiere
de date Gestiune Calcule multi Calcule multi
Interfaţa
date dimensionale dimensionale
în lot ad-hoc
Figura 3.5 Server de fişiere-client OLAP
Server de bază de date relaţional client OLAP
Fişiere Gestiune Calcule multi Calcule Interfaţa

de date date dimensionale multidimensi
- în lot onale ad-hoc
Figura 3.6 Arhitectura client/server (server relaţional/client OLAP)
Server de bază de date relaţional Server de aplicaţii client OLAP
Gestiune Calcule multi Calcule multi

Fişiere Interfaţa
de date
în lot ad-hoc
Figura 3.7 Arhitectura pe trei niveluri
Server OLAP client OLAP
Calcule multi
Fişiere Gestiune dimensionale Calcule multi Interfaţa
de date date în lot dimensionale
ad-hoc
Figura 3.8. Arhitectura client/server (Server OLAP/client OLAP)
88
Server de bază de date relaţional Server de aplicaţii client WEB
Gestiune Calcule multi Calcule multi Interfaţa

Fişiere
de date
în lot ad-hoc
Figura 3.9 WEB OLAP pe trei niveluri
Tabelul 3.3
Tipuri de arhitecturi client/server
Descriere Facilităţi Dezavantaje

Server de fişiere/client OLAP Uşor de implementat, independent de Nu este chiar o arhitectură
Numai nivelul 1 este pe un server protocoalele de reţea, server ieftin. Orice client/server. Procesarea nu se face pe
de fişiere, nivelurile 2-5 pe client server de fişiere poate fi folosit server. Poate cere clienţi PC puternici.
Poate genera trafic excesiv în reţea,
deoarece toate datele trebuie să fie
mutate la clienţi pentru procesare.
Securitatea trebuie să fie gestionată de
aplicaţiile client. Greu de implementat
actualizarea multiutilizator
Server relaţional/client OLAP În funcţie de aplicaţie poate fi gestionată Cere un SGBD potrivit pe server,
Nivelurile 1 şi 2 sunt pe un server securitatea pe server. Reduce încărcarea adaugând la costuri şi complexitatea.
de baze de date relaţional, reţelei, deoarece datele pot fi selectate şi Poate genera trafic excesiv în reţea,
nivelurile 3-5 pe client procesate parţial de serverul de bază de date, dacă toate procesările
înainte de a fi trimise la client pentru multidimensionale sunt făcute pe client.
procesare şi prezentare. Cele mai multe
procesări pot fi făcute de SGBD-ul relaţional,
care permite o exploatare bună a procesării
paralele. Capabil de actualizări online cu
blocări mai bune a datelor.
Arhitectura pe trei niveluri Distribuţie flexibilă a procesării între serverul Greu de implementat şi se cere
Nivelurile 1 şi 2 pe un server de de bază de date şi serverele de aplicaţii. Se experienţă în reţele. Adesea mai puţin
baze de date relaţional, nivelul 3 reduce traficul în reţea pentru că datele pot fi deschis decât arhitectura cu bază de
pe unul sau mai multe servere de procesate acolo unde sunt stocate. date distribuită . Scalabilitatea în
aplicaţii, nivelurile 4 şi 5 pe client. Funcţionalitate ridicată prin utilizarea unui funcţie de numărul de utilizatori poate
Nivelul 3 poate avea, de SGBD relaţional complex şi a unui server de fi restricţionată de limitele fiecărui
asemenea, o bază de date locală aplicaţii puternic. Scalabilitate bună în funcţie server de bază de date sau de aplicaţii .
pentru stocarea informaţiilor de dimensiunea aplicaţiei.
multidimensionale.
Server OLAP/ client OLAP Performanţă optimă cu trafic în reţea minim. În general o arhitectură mai puţin
Nivelurile 1-3 pe un server de bază Costuri hardware mici. Uşor de implementat deschisă. Instrumentele de acest tip
de date multidimensional, actualizarea multiutilizator a datelor sunt adesea mai specializate şi mai
nivelurile 4 şi 5 pe client. multidimensionale, cu securitate puţin potrivite pentru utilizare generală.
multidimensională la nivel de detaliu.
Aplicaţiile complexe sunt mai simplu de
implementat.
WEB OLAP pe trei niveluri Uşor de utilizat pentru un număr mare de Funcţionalitate şi performanţă redusă.
Nivelurile 1 şi 2 sunt pe un server utilizatori, incluzând acei utilizatori din afara Reduce manipulările de date la nivel de
relaţional, nivelurile 3 şi 4 pe organizaţiei. Reţea la un cost mic. Nu cere client.
serverul de aplicaţii şi nivelul 5 pe software dedicat pe client, reducând costurile
un browser WEB conectat prin cu software-ul. Suportă o varietate de
Internet sau Intranet. platforme.
89
Rezumat
Sistemele OLAP permit analiştilor şi managerilor să îmbunătăţească

performanţele unei firme, printr-un acces interactiv rapid la o mare varietate de
viziuni de date organizate, pentru a reflecta aspectul multidimensional al datelor
dintr-o întreprindere.
În funcţie de modul de stocare a datelor, sistemele OLAP se clasifică în:
sisteme ROLAP, sisteme MOLAP şi sisteme HOLAP.
Sisteme ROLAP permit stocarea datelor multidimensionale în baze de date
relaţionale (depozite de date), utilizând schema stea sau fulg de zăpadă.
Stocarea datelor multidimensionale se face într-o bază de date relaţională

atunci când:
Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu
sunt copiate în baza de date multidimensională ci sunt stocate în baze de
date relaţionale sursă (depozite de date/centre de date) şi citite când este
nevoie;
Datele sursă se modifică frecvent şi este mai bine de a citi în timp real
decât din copii;
Integrarea cu alte sisteme informatice relaţionale existente;
Firma are o politică de neduplicare a datelor în alte structuri de fişiere,
pentru securitate sau alte motive, chiar dacă aceasta conduce la aplicaţii
mai puţin eficiente;
Sistemele MOLAP permit stocarea datelor multidimensionale în baze de date

multidimensionale, sub formă de matrici multidimensionale. Spaţiul este rezervat
pentru fiecare combinaţie posibilă între membrii dimensiunilor. Numai matricile
ce conţin date sunt stocate fizic. Fiecare dimensiune a matricii reprezintă o
dimensiune a cubului. Conţinutul matricii sunt măsurile cubului.
Un sistem OLAP hibrid (HOLAP) este un sistem care utilizează pentru
stocarea datelor atât baze de date relaţionale cât şi baze de date
multidimensionale, în scopul de a beneficia de caracteristicile corespunzătoare şi
de tehnicile de optimizare.
Sunt diferite arhitecturi pentru un sistem hibrid OLAP şi anume: integrarea
sistemelor MOLAP şi ROLAP printr-o interfaţă comună, integrarea mutuală a
sistemelor ROLAP şi MOLAP, extensii la SGBDR sau SGBDOR prin utilizarea
tehnologiei datablade.
Aplicaţiile OLAP au o varietate mare de arhitecturi, unele foarte complexe şi
anume: server de fişiere/client OLAP, server relaţional/client OLAP, server de
90
baze de date relaţional/server de aplicaţii/client OLAP, server OLAP/client OLAP,

server de bază de date relaţional/server de aplicaţii/client WEB.
Cuvinte cheie
Sisteme ROLAP, sisteme MOLAP, sisteme HOLAP
91
Capitolul 4
Instrumente OLAP
Cerinţele utilizatorilor, identificate în etapa de analiză a sistemului informatic,
vor determina alegerea instrumentului OLAP. De exemplu, dacă aplicaţia implică
analiză financiară, atunci instrumentul trebuie să permită conversii de valută.
Caracteristicile unui instrument OLAP sunt clasificate în două categorii:
caracteristici logice şi caracteristici fizice [THOM96].
Caracteristicile logice sunt independente de platforma hardware utilizată, de
sistemul de operare, de numărul de utilizatori şi de metodele de stocare fizică.
Dimensiunile, ierarhiile, formulele, legăturile sunt exemple de atribute logice.
Caracteristicile fizice sunt independente de modelul definit sau analizat şi
includ modul cum se stochează şi încarcă datele şi ce platforme software şi
hardware se folosesc.
4.1 Caracteristici logice

Caracteristicile logice sunt: structura datelor (modul cum sunt definite
modelele, dimensiunile, tipurile de relaţii ce pot exista între membrii unei
dimensiuni), operaţiile (tipurile de legături ce pot fi create, tipurile de formule ce
pot fi definite) şi reprezentările (modul de afişare a datelor multidimensionale:
tabel sau grafic). Această organizare este similară dar nu identică cu modelul
relaţional care este definit în funcţie de structura datelor, operaţiile între date şi
integritatea datelor. Instrumentele OLAP au fost construite şi dezvoltate în absenţa
unui model de date spre deosebire de modelul relaţional, care a fost definit ca un
model de date înainte ca să se construiască un SGBDR.
Aspectele structurale ale modelului relaţional constau din domenii, atribute,
tupluri, relaţii şi scheme. În lumea multidimensională, ele sunt compuse din
dimensiuni, ierarhii, cuburi n-dimensionale (hypercuburi) şi modele (scheme).
Operatorii modelului relaţional sunt specifici algebrei relaţionale şi calculului
relaţional. Produsul cartezian, joncţiunea şi proiecţia sunt exemple de operatori
relaţionali. Aceşti operatori pot fi numiţi operatori structurali, în sensul că ei
manipulează structura relaţiilor. Modelul relaţional şi SGBDR-urile se
92
Caracteristicile sistemelor OLAP
concentrează mai mult pe operaţiile structurale decât pe operaţiile pe date (data

operations) cum ar fi suma, maxim, minim, order by etc.
În lumea multidimensională se pune accentul pe operaţiile pe date (tipurile de
formule ce pot fi definite într-un cub sunt probleme legate de operaţiile pe date) şi
mai puţin pe operaţiile structurale (formarea unui cub dintr-un set de dimensiuni nu
corespunde unui operator în lumea multidimensională, dar în lumea relaţională
reprezintă produsul cartezian al dimensiunilor).
„Restricţiile de integritate denumite şi reguli de integritate definesc cerinţele
pe care trebuie să le satisfacă datele din cadrul bazei de date pentru a putea fi
considerate corecte, coerente în raport cu lumea reală pe care o reflectă.
Restricţiile de integritate reprezintă principalul mod de integrare a semanticii
datelor în cadrul modelului relaţional al datelor, mecanismele de definire şi
verificare a acestor restricţii reprezentând principalele instrumente pentru
controlul semantic al datelor. Restricţiile de integritate ale modelului relaţional
sunt de două tipuri şi anume:
restricţii de integritate structurale inerente modelului relaţional care se
definesc prin egalitatea sau inegalitatea unor valori din cadrul relaţiilor
(restricţia de unicitate a cheii, restricţia entităţii, restricţia referenţială şi
dependenţele între date);
restricţiile de integritate de comportament proprii unei anumite BDR, care
ţin cont de semnificaţia valorilor din cadrul bazei de date. În funcţie de
realitatea descrisă în baza de date, se pot defini de către utilizatori mai
multe tipuri de restricţii de integritate de comportament şi anume:
restricţii de domeniu, restricţii temporale etc” [LUBO95].
Restricţiile de integritate nu sunt o componentă a modelului multidimensional
(unele modele fac totuşi referiri la restricţiile de integritate), dar s-au inclus
reprezentările care lipsesc de la descrierea modelului relaţional. Modelele
multidimensionale au totuşi legătură cu problema integrităţii în sensul de filtrare.
Testarea integrităţii datelor este o parte importantă a modelării multidimensionale
şi este inclusă ca o parte a aplicaţiilor.
Reprezentările sunt o problemă importantă pentru modelele multidimensionale
(modul de afişare a datelor multidimensionale: tabel sau grafic). În modelul
relaţional reprezentarea ar putea fi legată de viziuni.
4.1.1 Structura datelor
Dimensiunile. Unele instrumente OLAP permit numai o direcţie de agregare

pe dimensiune. Pentru aceste instrumente, fiecare direcţie de agregare constituie o
dimensiune separată. Alte instrumente definesc o dimensiune ca un singur nivel al
unei ierarhii. De exemplu, săptămânile ar putea descrie o dimensiune. Lunile ar
descrie altă dimensiune. Trimestrele ar defini a treia dimensiune etc. Alte
instrumente consideră că toate dimensiunile sunt compuse din niveluri cu nume.
Timpul foloseşte de regulă niveluri cu nume. Unele instrumente tratează
dimensiunile şi măsurile în acelaşi mod. Ele nu fac distincţie între dimensiuni şi
93
măsuri. Alte instrumente tratează explicit măsurile ca o dimensiune specială şi le

ataşează la celelalte dimensiuni pentru a forma un cub (instrumentele ROLAP).
În alegerea unui instrument OLAP se vor analiza următoarele aspecte
[THOM96]:
Cardinalitatea (numărul maxim de membri dintr-o dimensiune). Instrumentul
lucrează eficient sau nu cu dimensiunile foarte mari.
Ierarhiile. Instrumentul permite sau nu :
dimensiuni ierarhice;
multiple ierarhii într-o singură dimensiune;
niveluri cu nume în ierarhie şi ierarhii neregulate. Dacă agregările sunt
neregulate şi se modifică frecvent (cazul produselor sau ierarhiilor
organizaţionale) este necesar un instrument ce permite ierarhii neregulate;
conectarea membrilor copii la mai mulţi părinţi într-o singură ierarhie (de
exemplu un oraş care se găseşte în două state).
Versiunile. Dacă într-un model multidimensional sunt multiple cuburi de date
sau dacă dimensiunile pot fi create şi actualizate independent de cuburi, aceleaşi
dimensiuni apar frecvent în mai multe cuburi. Problema care apare este legată de
modul cum se realizează sincronizarea între multiple instanţe ale unei dimensiuni.
În acest caz, instrumentul trebuie să suporte mai multe versiuni ale dimensiunii.
Cuburile. Cele mai multe propietăţi ale cuburilor decurg din propietăţile
componentelor lor (dimensiunile şi formulele). În alegerea unui instrument OLAP
se va ţine cont de:
numărul maxim de dimensiuni într-un cub. Instrumentele care nu permit
dimensiuni ierarhice sau ierarhii multiple pe dimensiune sunt mai limitate
(de exemplu un model cu 6 dimensiuni ierarhice cu multiple direcţii de
agregare ar putea să aibă nevoie de 30 sau mai multe dimensiuni
neierarhice);
numărul maxim de celule într-un cub;
numărul maxim de date de intrare/pe cub;
numărul maxim de celule de date stocate/pe cub;
Modelele. Unele instrumente tratează toate dimensiunile drept componente ale
unui singur cub n-dimensional. Alte instrumente permit ca unele dimensiuni să fie
comune la mai multe cuburi (multicuburi). De aceea, se va stabili dacă :
modelul este compus dintr-un singur cub n-dimensional sau din multiple
cuburi interactive;
toate variabilele sunt dimensionate în acelaşi mod.
Tipurile de date. Valorile de date sunt limitate de tipul de date. În modelul
relaţional, valorile atributelor trebuie să se încadreze între anumite limite
(domeniul ce defineşte toate valorile posibile). Cu instrumentele OLAP, definirea
unei variabile prin specificarea tipului de date determină valorile posibile pe care
membrul le poate avea. Orice instrument OLAP permite stocarea numerelor reale,
dar nu toate instrumentele OLAP permit stocarea: şirurilor de caractere, a
imaginilor şi a tipurilor de date definite de utilizator.
94
4.1.2 Operaţii
Toate instrumentele OLAP permit ca datele de intrare atomice să fie agregate.

În alegerea unui instrument OLAP se va analiza dacă:
datele trebuie încărcate numai la nivel atomic;
formulele pot utiliza date de pe orice nivel ierarhic din cub;
formulele pot utiliza date din mai multe cuburi.
Se vor analiza, de asemenea, şi următoarele aspecte:
Prioritate. Pentru unele formule, ordinea în care ele sunt combinate afectează
rezultatele. În aceste cazuri se va stabili:
logica implicită utilizată de instrument;
prioritatea prin definirea de către utilizator a tipului de date sau utilizând
prioritatea implicită a formulei;
dacă instrumentul oferă posibilitatea de a testa impactul utilizării unei
priorităţi diferite.
Variabile/măsuri. În alegerea unui instrument OLAP se va analiza dacă:
variabilele sunt tratate diferit de dimensiuni;
se pot ataşa formule de agregare la variabile;
se pot declara tipuri de variabile şi moşteni formula de la alte variabile;
instrumentul permite variabile care nu sunt numerice.
Fenomenul de împrăştiere. Cuburile n-dimensionale sunt împrăştiate. Această
împrăştiere poate indica fie lipsă de date, date invalide sau date cu valoare zero.
Cele mai multe instrumente OLAP oferă suport pentru procesarea datelor lipsă şi a
celor invalide. În aceste cazuri, se va analiza dacă instrumentul procesează datele
lipsă diferit de cele invalide şi de cele cu valoare zero.
Formule. Un instrument OLAP trebuie să permită utilizarea formulelor
algebrice pentru definirea variabilelor. În alegerea instrumentelor OLAP se va
analiza dacă:
instrumentul permite ataşarea unei formule algebrice la orice membru
dintr-o dimensiune;
instrumentul OLAP permite, de asemenea, funcţii logice şi ecuaţii;
instrumentul permite definirea vizuală a formulelor.
Legături. Modelele multidimensionale utilizează diferite surse de date şi din
acest motiv, în alegerea unui instrument OLAP se va analiza dacă:
datele şi metadatele pot fi încărcate dintr-o singură colecţie de date;
legăturile sunt persistente;
formulele stocate în sursele de date externe pot fi apelate în formulele din
cub etc.
Întrucât sistemele OLAP utilizează adesea volume mari de date ce se
actualizează regulat, procesul de propagare a modificărilor de la surse la cub
impune multe activităţi ce trebuie automatizate. Din acest motiv, se va analiza
dacă:
modificările ce apar în tabelele externe se pot propaga automat în modelul
multidimensional;
95
modificările ce apar în denumirea unui membru sunt propagate automat în

toate formulele în care membrul este folosit;
ordinea în care elementele sunt modificate se poate stabili automat (cum ar
fi de exemplu, calculul dimensiunilor înaintea cuburilor);
Optimizare/eficienţă. Un instrument OLAP trebuie să fie capabil să detecteze
toate tipurile de valori modificate şi să declanşeze automat modificările în cubul n-
dimensional (hypercub). De asemenea, se va analiza dacă:
instrumentul permite ca un administrator să specifice care agregate sunt
antecalculate şi stocate şi care sunt calculate la momentul interogării;
instrumentul poate stabili automat care agregate trebuie să fie antecalculate
şi care se execută la momentul interogării;
instrumentul poate stabili locul unde se execută un calcul (pe client sau pe
server).
4.1.3 Modul de reprezentare a datelor multidimensionale
Reprezentarea datelor multidimensionale este un domeniu important în

sistemele OLAP şi se referă la:
Vizualizarea datelor. Un instrument OLAP trebuie să permită cel puţin
vizualizarea datelor multidimensionale sub formă de tabel. În plus, un instrument
OLAP trebuie să ofere prezentări grafice ale datelor multidimensionale. Multe
instrumente OLAP permit grafice în două şi trei dimensiuni. Unele instrumente
permit vizualizare multicub, în care dimensiunile comune pentru două sau mai
multe cuburi sunt afişate pe ecran ca dimensiuni imbricate.
Navigarea. Ideal un instrument OLAP trebuie să permită operaţii de tip drill
down, roll up şi drill across în ierarhiile dimensionale.
Formatul de afişare a variabilelor. Modelele OLAP sunt folosite de utilizatori
pentru a comunica informaţia necesară procesului decizional. La ora actuală,
instrumentele OLAP au o abilitate foarte limitată de a defini modul cum se afişează
o variabilă. Ideal, un instrument OLAP ar trebui să permită un format de afişare
implicit (cum ar fi valoarea curentă), care să fie asociat cu variabila.
4.1.4 Alte caracteristici logice
Domenii de cunoştinţe. Domeniile în care un instrument multidimensional

posedă cunoştinţe sunt : timpul, valuta, limbile străine. Timpul este o dimensiune
ce apare în orice model multidimensional şi de aceea, este necesar ca instrumentul:
să aibă cunoştinţe despre timp;
să înţeleagă diferitele tipuri de calendare (de exemplu fiscal);
să permită compararea seriilor de timp, de periodicităţi diferite;
să poată crea o dimensiune Timp specifică unei aplicaţii;
să permită crearea mai multor dimensiuni Timp într-un singur cub.
96
De asemenea, este necesar ca instrumentul: să recunoască valutele, să execute

conversii de valute, să se bazeze pe o anumită rată de schimb (medie, ultima zi,
prima zi, cea mai mare, cea mai mică) etc. Este necesar, de asemenea, a se stabili
ce limbi suportă instrumentul şi cât din aplicaţie poate fi tradusă (de exemplu:
opţiunile din meniu, mesajele de eroare, help-ul).
Domeniile orientate pe proces se referă la:
Realizarea aplicaţiei. Se va analiza:
dacă instrumentul oferă un mediu complet de dezvoltare a aplicaţiei;
ce funcţii realizează instrumentul (analiză, crearea modelului etc);
dacă instrumentul foloseşte un limbaj procedural sau neprocedural;
dacă instrumentul oferă facilităţi de depanare etc.
Asigurarea securităţii multiutilizator. Sistemele OLAP au aceleaşi nevoi de
securitate ca orice mediu de date multiutilizator şi de aceea, se va analiza:
dacă oferă securitate atât la citire cât şi la scriere;
dacă securitatea este definită folosind un limbaj multidimensional;
la ce nivel de granulaţie poate fi definită securitatea (model, cub, membrii
dimensiunii, celulă);
dacă sistemul poate monitoriza toate încercările utilizatorilor de a accesa
datele;
dacă utilizatorul poate vedea membrii pentru celulele la care el nu are
acces;
dacă drepturile unui utilizator pot fi modificate;
dacă se pot defini grupuri de utilizatori (roluri) sau numai utilizatori
individuali etc.
Facilităţi de gestiune a datelor. Se va analiza: ce tip de facilităţi de salvare şi
restaurare oferă instrumentul, dacă instrumentul realizează controlul tranzacţiilor
etc.
Interfaţa instrumentului. Sunt în general o serie de probleme legate de interfaţa
cu utilizatorul, care trebuie luate în considerare şi anume dacă:
instrumentul permite utilizatorului confirmarea înainte de execuţia
operaţiilor importante, cum ar fi ştergerea unui cub;
utilizatorul poate să oprească o cerere în execuţie;
există facilităţi de anulare a diferitelor acţiuni etc.
4.2 Caracteristici fizice
Caracteristicile fizice sunt independente de modelul multidimensional şi se

referă la:
Stocare/acces. Se va analiza:
dacă datele din sesiunea curentă sunt stocate pe client sau pe server;
cum sunt stocate datele lipsă, invalide şi cele cu valoarea zero;
97
care este spaţiu necesar pentru a stoca 1 milion, 10 milioane şi 100

milioane de numere etc.
Modul de calcul. Unele instrumente pot fi rapide pentru calcule simple, dar
neperformante pentru cele complexe. Altele pot lucra cel mai bine cu un număr mic
de dimensiuni.
Tipul de arhitectură client/server. Se va determina:
ce calcule, definite de utilizator, pot fi procesate pe server;
dacă sistemul poate stabili cel mai eficient mod de a distribui calculele
între client şi server;
care este numărul maxim de clienţi concurenţi (la citire);
dacă instrumentul suportă access concurenţial la scriere;
ce se întâmplă dacă doi utilizatori, cu drept de scriere, încearcă să scrie în
aceeaşi celulă la un moment dat;
la ce nivel este blocat cubul în cazul scrierilor concurente etc.
Platforma. Pentru a alege un instrument OLAP se va stabili:
care sunt sistemele de operare acceptate de instrument;
ce tipuri de maşini foloseşte instrumentul OLAP;
dacă instrumentul poate să folosească avantajele lui MPP pentru încărcare,
cerere şi/sau calcule etc.
4.3 Exemple de instrumente OLAP
Business Objects Americans [www.businessobjects.com] este lider în

furnizarea de instrumente suport de decizie incluzând interogare, raportare, analiza
proceselor on-line, data mining şi administrare SSD pentru arhitectură client/server
şi mediu Internet :
Business Objects permite dezvoltarea de aplicaţii suport de decizie cu facilităţi
de interogare şi raportare. Asigură acces la diferite surse de date (depozite de date
/centre de date, baze de date multidimensionale, fişiere text, pachete de aplicaţii,
sisteme SAP). Folosind facilitatea VBA permite utilizatorilor să modifice şi să
extindă nucleul funcţional al produsului Business Objects (se pot crea noi funcţii,
noi comenzi sau subprograme) .
Developer Suite permite integrarea completă a lui Business Objects cu alte
aplicaţii (financiare, resurse umane, marketing sau producţie) şi cuprinde
următoarele componente: Business Objects, WebIntelligence (server de Web),
Broadcast Agent şi o componentă pentru vizualizarea rapoartelor.
Cognos [www.cognos.com] oferă instrumente pentru inteligenţa afacerii

(Power Play şi Impromptu), medii de dezvoltare a aplicaţiilor (Power House,
Axiant, RealObjects).
Power Play este un instrument de analiză şi raportare multidimensională folosit
pentru a oferi informaţii utile managerilor. Este folosit de manageri pentru a
explora datele în format numeric sau grafic şi pentru raportare. Power Play este un
98
instrument foarte scalabil (până la câteva mii de utilizatori), cuburile pot fi create
pe client sau pe servere Unix. Ele pot fi create ca fişiere într-un sistem de gestiune
de fişiere sau ca tabele într-o bază de date relaţională (Oracle sau Sybase). Power
Play permite o metodologie de proiectare a aplicaţiilor iterativă.
Impromptu permite utilizatorilor să creeze rapoarte complexe fără să cunoască
limbajul SQL sau structura bazei de date. Power Play şi Impromptu se folosesc
pentru aplicaţii de analiză a vânzărilor, analiză financiară, controlul calităţii etc.
Instrumentele pot importa date din peste 100 de surse de date relaţionale şi
multidimensionale.
Holistic Systems, Inc [www.holistic.com] este un membru al grupului Seagate

Software Information Management şi este cel mai puternic furnizor de instrumente
pentru inteligenţa afacerii. Holistic Systems este complet dedicat pentru activitatea
de marketing, fiind un lider în BI. Holos este un mediu de dezvoltare pentru
aplicaţii BI, încorporează facilităţi EIS, SSD şi OLAP, cu o arhitectură pe trei
niveluri, pentru firme de dimensiuni foarte mari. Holos se poate instala pe Unix,
VMS şi NT şi clienţi Windows, Windows NT şi MacIntosh. În versiunea 5.0 a fost
introdusă facilitatea de data mining, bazată pe reţele neuronale, integrată cu nivelul
analitic foarte puternic ale lui Holos.
Pilot Software, Inc [www.pilotsw.com] este o firmă a corporaţiei The Dun &
Bradstreet, care dezvoltă instrumente suport de decizie interactive pentru manageri
şi analişti. Pilot Decision Support Suite constă din cinci componente şi poate fi
instalat monoutilizator, workgroup sau distribuit. Clienţii suportă Windows 95,
Windows NT şi Windows 3.1, iar serverul Windows NT şi Unix .
Pilot Desktop este un mediu monoutilizator pentru analiză interactivă de
afaceri cu un set complet de instrumente multidimensionale, ce permit utilizatorilor
să facă operaţii de drill down, roll up şi pivotare prin datele agregate. Include un
motor OLAP cu cunoştinţe de timp şi instrumente pentru analiza de excepţii.
Sursele de date pot fi relaţionale .
Pilot Analysis Server este un server OLAP multiutilizator ce oferă multe
facilităţi de modelare (suport pentru analiza seriilor de timp), include o bibliotecă
de funcţii (funcţii de previziune, funcţii de corelaţie, analiza de regresie etc).
Pilot Designer este un instrument pentru crearea tuturor tipurilor de aplicaţii
vizuale de tip suport de decizie (de la EIS la aplicaţii OLAP complexe). Include un
limbaj pentru scripturi ce este compatibil cu Visual Basic.
Pilot Analysis Library este o bibliotecă opţională de module de analiză ce
permite utilizatorilor să accelereze implementarea de soluţii suport de decizie
complexe .
Pivot Excel Add-In este o componentă opţională ce permite utilizatorilor Excel
de a integra facilităţile mediului Pilot în soluţiile Excel .
MicroStrategy, Inc [http://www.strategy.com] este lider în soluţii ROLAP şi

oferă următoarele produse OLAP: DSS Server (motor relaţional-OLAP), clienţi
99
(DSS Agent Relational OLAP, DSS Objects pentru dezvoltarea de aplicaţii OLAP,
DSS Web Relational OLAP- client pentru Web ), DSS Architect (instrument de
proiectare), DSS Administrator (client pentru depozite de date), DSS Executive EIS
(instrument de proiectare).
Kenan Systems Corp [http://www.kenan.com] oferă soluţii pentru firmele din

domeniul telecomunicaţiilor, servicii financiare, comerţ. Oferă următoarele
produse:
Acumate Server este un mediu de dezvoltare de aplicaţii, incluzând un limbaj
procedural multidimensional (MSPL) şi instrumente de analiză complexe. Serverul
include un set de instrumente de încărcare a datelor, pentru accesarea depozitelor
de date şi a sistemelor operaţionale eterogene.
Acutrieve este o aplicaţie suport de decizie optimizată pentru analişti.
Acumate Workbench este o interfaţă grafică ce permite utilizatorilor să
folosească avantajele mediului Windows, precum şi a limbajului multidimensional
MSPL.
Acumate Web este un motor generator HTML ce poate fi utilizat pentru a
permite raportare ad-hoc şi statică folosind tehnologia Web.
Informix Software, Inc [http://www.informix.com] oferă următoarele produse

OLAP:
INFORMIX MetaCube este un motor de analiză complex, ce transformă
Informix Online Dynamic Server într-un server OLAP foarte performant.
INFORMIX MetaCube Explorer este un instrument SSD pentru utilizatori ce
oferă o interfaţă simplă pentru acces la depozitele de date şi realizarea de rapoarte.
INFORMIX MetaCube Warehouse Manager este un instrument grafic pentru
administrarea metadatelor ce descriu depozitul de date.
INFORMIX MetaCube Warehouse Optimizer analizează automat depozitul de
date pentru a recomanda agregarea optimă şi strategii de performanţă.
INFORMIX MetaCube for Excel extinde mediul foaie de calcul tabelar pentru a
oferi acces de tip wizard la depozitul de date.
Arbor Software Corporation [http://www.arborsoft.com] oferă instrumente

OLAP pentru activitatea de planificare şi analiză a afacerilor :
Essbase Analysis Server este un server de bază de date multidimensional
optimizat pentru aplicaţii de planificare şi analiză a afacerilor (analiza
profitabilităţii, analiza bugetară, previzionare, planificare, analiza de piaţă şi EIS)
cu următoarele caracteristici: arhitectură client/server, acces concurent la
citire/scriere, stochează volume mari de date, permite calcule analitice complexe,
navigare flexibilă prin date, timp de răspuns mic, permite aplicaţii OLAP robuste
ce accesează direct sisteme OLTP sau un centru de date şi operează pe Windows
NT, OS/2, IBM-AIX, Sun Solaris şi AS/400 cu clienţi Windows, MacIntosh şi
Unix.
100
Essbase Spreasheet Add-In permite integrarea facilităţilor oferite de

instrumentele de tip foaie de calcul tabelar (Excel, Lotus) cu facilităţile OLAP.
Essbase Application Manager este folosit pentru a construi, modifica şi
gestiona modele analitice, securitatea accesului la date, reguli de încărcare a
datelor.
Există o serie de module opţionale cum ar fi: Essbase Adjustment Module
(pentru planificarea automată a momentului lansării în execuţie a rapoartelor) şi
Essbase Currency Conversion Module (pentru conversii de valute).
Wired for OLAP este un instrument de prezentare şi analiză ce operează atât pe
client cât şi pe server.
Essbase Objects este un instrument puternic ce permite dezvoltarea de aplicaţii
OLAP.
IBM Corporation [www.ibm.com]. Arhitectura generală a unei soluţii IBM

OLAP este prezentată în figura 4.1.
Componenta Componenta Motorul Depozitul de

de de aplicaţie OLAP date
prezentare
Figura 4.1 Arhitectura unei soluţii IBM OLAP
Componenta de prezentare oferă un set de facilităţi de vizualizare, navigare şi

raportare. Motorul OLAP permite reprezentarea multidimensională a schemei stea,
calcule analitice complexe şi agregări. Unele soluţii OLAP includ un nivel
suplimentar componenta de aplicaţie. Această componentă oferă logica afacerii,
specifică pentru subiectul analizat (de exemplu marketing şi vânzări).
DB2 OLAP Server utilizează un motor OLAP Essbase dezvoltat de firma Arbor
Software Corporation, pentru gestiunea şi proiectarea aplicaţiilor, navigarea şi
accesul la date, încărcarea datelor. Este compatibil cu Essbase şi cu toate
instrumentele firmei Arbor şi permite: analize multidimensionale pe volume mari
de date relaţionale, gestiunea datelor, accesul şi interogarea datelor din schema stea
folosind limbajul SQL. Essbase este o soluţie MOLAP iar DB2 OLAP Server
foloseşte o bază de date relaţională DB2 (DB2 Universal Database/UDB) şi este o
soluţie ROLAP. Figura 4.2 prezintă arhitecturile lui Essbase şi DB2 OLAP Server.
Arhitectura lui DB2 OLAP Server combină avantajele lui DB2 UDB, un sistem
de gestiune a bazelor de date relaţional foarte puternic, cu puterea motorului
OLAP. Permite administratorilor să gestioneze datele multidimensionale, în acelaşi
mod ca datele relaţionale din depozitele de date şi sistemele tranzacţionale. Atât
Essbase cât şi DB2 OLAP folosesc acelaşi motor OLAP, accesat printr-o interfaţă
API (Essbase API). DB2 OLAP structurează datele într-o schemă stea special
proiectată pentru analiza multidimensională a datelor relaţionale. Componenta
101
Relational Storage Manager (RSM) separă motorul OLAP de baza de date

relaţională.
Componentele de prezentare şi aplicaţie
MS Excel Essbase Essbase Essbase Essbase SQL
Lotus Objects Application Currency Adjustment Decision
Manager Conversion Module Support
Module
RDBMS
Essbase Management
Spreadsheet Tools
Add-In
Essbase API Essbase API
Motor Essbase OLAP Motor Essbase OLAP
Multidimensional Storage
Manager Relational Storage Manager
Motorul OLAP SQL
Fişiere/baze de date
Bază de date
multidimensionale
relaţională
(schema stea)
Figura 4.2 Arhitectura pentru Essbase şi DB2 OLAP Server
Oracle Corporation [http://www.oracle.com] oferă următoarele produse

OLAP:
Oracle Express Server/Oracle Personal Express este un server OLAP. Datele
sunt stocate într-o bază de date multidimensională. În 2002, Oracle lansează
Oracle9i Release 2 OLAP care integrează toate facilităţile OLAP (Analytical
Workspace) în baza de date relaţională Oracle.
Oracle Express Administrator este un utilitar grafic pentru definirea,
întreţinerea şi popularea bazelor de date multidimensionale Express.
Oracle Express Relational Access Manager (RAM) permite ca Express
Analyzer să acceseze datele stocate într-o bază de date relaţională, care a fost
configurată cu Oracle Relational Access Administrator (RAA).
102
Pentru a construi o bază de date Express se parcurg următoarele etape:

Etapa de definire. În această etapă, cu ajutorul lui RAA se execută următoarele
activităţi:
se selectează tabelele depozitului de date folosit;
se defineşte modelul multidimensional;
se determină modul cum se accesează datele relaţionale şi se definesc
caracteristicile bazei de date Express. Modelul de date împreună cu
mapările asociate şi definiţiile bazei de date formează un proiect. RAM
construieşte un set de metadate şi le stochează în baza de date relaţională.
Pot exista mai multe proiecte asociate cu un singur depozit de date şi
fiecare proiect poate utiliza un model de date multidimensional diferit.
Etapa de creare/actualizare. În această etapă, se contruieşte baza de date
Express pentru a fi utilizată de aplicaţiile Express.
Etapa online. Utilizatorii pot utiliza datele prin aplicaţii Express (figura 4.3).
Clientul Express generează

o cerere de date
Da Nu
Date in
Express
cache
Modulul de runtime generează comenzi SQL SELECT
Se trimit comenzile SELECT la SGBDR
Se primeşte răspunsul şi se stochează în Expres Cache
Express procesează datele
Răspunsul este trimis la client
Figura 4.3 Etapa online
RAM conţine următoarele componente (figura 4.4):

Relational Access Administrator, un utilitar folosit pentru a defini un
model multidimensional şi a determina cum accesează serverul Express
datele relaţionale. Când se creează un nou proiect se alege fie opţiunea
103
Project Editor sau Project Wizard. Opţiunea Project Editor este o interfaţă
prin care se poate crea un proiect pentru orice tip de schemă, în timp ce
opţiunea Project Wizard oferă o metodă simplă pentru crearea unui model
multidimensional bazat pe o schemă stea. RAA defineşte automat cuburi
de date, un cub de date separat pentru fiecare set unic de dimensiuni, ce
este utilizat în definirea variabilelor. De exemplu, dacă avem două
variabile: variabilă Vânzări dimensionată după Produs, Locaţie geografică
şi Timp şi variabila Populaţie după Locaţia geografică şi Timp, RAA
defineşte două cuburi CUBUL 1 (Produs, Locaţie geografică, Timp) şi
CUBUL2 (Locaţie geografică, Timp). Cu ajutorul opţiunii
Database/Sparsity, RAA permite specificarea dimensiunilor împrăştiate şi
includerea lor într-o dimensiune de tip conjoint. Pentru stocarea datelor
lipsă, Oracle Express foloseşte dimensiunile de tip conjoint. O dimensiune
conjoint stochează combinaţii de valori de la două sau mai multe
dimensiuni, numai pentru acele celule ce conţin date.
Build modul conţine programul ce construieşte noi baze de date Express
sau actualizează pe cele existente. Acest modul citeşte proiectul şi
construieşte sau actualizează baza de date Express, ce corespunde
modelului de date multidimensional definit în proiect.
Runtime modul conţine utilitare ce încarcă datele relaţionale la momentul
de execuţie.
Relation Access Administrator

Aplicaţie Express
Express
RAM RAM
Runtime Build
Modul modul
Depozit de date
Baza de date
Express
Figura 4.4 Componentele lui Relational Access Manager
Oracle Express Analyzer este un instrument OLAP folosit pentru analiza

datelor şi realizarea rapoartelor. Permite:
lansarea în execuţie a briefing-urilor (dosare);
crearea de briefing-uri pentru utilizatori;
analiză ad-hoc;
lansarea în execuţie a aplicaţiilor realizate cu Express Objects;
104
editarea briefing-urilor create cu Express Objects. Aceste briefing-uri pot

fi accesate prin Web. Un briefing este un set de pagini ce conţin tabele,
grafice şi date preluate de la alte instrumente, organizate într-un mod
accesibil utilizatorilor, pentru a putea fi analizate. Datele afişate într-un
briefing pot fi stocate într-o bază de date relaţională (Oracle) sau
multidimensională (Express).
Oracle Express Objects permite crearea de aplicaţii OLAP şi briefing-uri
complexe care pot fi rulate în Express Analyzer, precum şi realizarea de programe
în limbaj Express, prin care se controlează comportamentul aplicaţiei. Este un
element cheie în Oracle Integrated Business Intelligence Tools, fiind integrat cu
Oracle Discoverer.
Oracle Express Spreadsheet Add-In permite afişarea datelor multidimensionale
într-o foaie de tip calcul tabelar Excel.
Oracle Express Web Agent permite crearea de aplicaţii Express ce pot fi
lansate în execuţie folosind un browser Web şi constă din următoarele componente
distribuite într-o arhitectură client/server:
Web Listener primeşte şi procesează cererile de la browserul Web pentru a
vizualiza documente HTML sau a executa programe. Se poate utiliza
Oracle Web Server;
WebListener Interface (Oracle Web Request Broker cartridge sau Common
Gateway Interface –CGI);
Web Agent Modules for Express Server ce permite comunicarea între
Express Server şi Web Listener Interface;
Developer’s Toolkit ce conţine programe folosite în aplicaţii Web pentru a
genera tag-uri HTML şi a produce viziuni de date multidimensionale
(figura 4.5).
Client Server
Express Web Agent
Web Web Web Listener Express Server

browser Listener Interface
Web Developer’s
Modules Toolkit
Figura 4.5 Componentele lui Express Web Agent
Aplicaţii Oracle Express (Oracle Sales Analyzer şi Oracle Financial Analyzer)

sunt aplicaţii preconstruite pentru analiza vânzărilor şi a pieţei şi analiză financiară.
Sales Analyzer poate estima tendinţe ale vânzărilor, profitabilitatea unor produse
sau a unor clienţi, ciclul de viaţă al unui produs, eficacitatea unei campanii de
promovare. Include template-uri pentru rapoarte de excepţii, o bibliotecă de
formule predefinite. Utilizatorii îşi pot defini propriile lor formule. Cu ajutorul unui
105
browser Web, Sales Analyzer poate executa analize ad-hoc folosind facilităţile
Internetului.
Oracle Financial Analyzer este o aplicaţie preconstruită pentru planificare,
stabilirea bugetelor, analize şi rapoarte financiare.
SNAPI (structured N dimensional application programming interface) este o
bibliotecă de funcţii C care permite ca aplicaţiile client Windows să poată
comunica cu serverul Express. Local SNAPI permite clienţilor să se conecteze la
Personal Express, iar Remote SNAPI la serverul Express. ExpressCommunication
Architecture (XCA) permite comunicarea între Personal Express şi Express Server
şi între instanţe diferite ale serverului Express.
4.4 Standarde
Consiliul OLAP a propus un APB-1 benchmark [OLAP97b ] pentru a compara
serverele OLAP din punct de vedere al timpului mediu de interogare (Average
Query Time-AQT). Standardul defineşte un set de dimensiuni specifice activităţii
de analiză a vânzărilor. Structura logică a bazei de date este formată din 6
dimensiuni: Timp, Scenariu, Măsura, Produs, Client şi Canal de distribuţie.
Benchmark-ul nu consideră un anumit model fizic de bază de date, datele de intrare
sunt furnizate în format de fişiere ASCII. Operaţiile simulează perfect operaţiile
standard OLAP şi includ încărcarea secvenţială şi în lot a datelor de la surse de
date interne sau externe, agregarea sau deagregarea (roll up, drill down) datelor de
a lungul ierarhiilor, calcule de noi date bazându-se pe modele de afaceri etc.
TPC-D benchmark [TPBC98] modelează un mediu suport de decizie în care
sunt executate cereri ad-hoc complexe pe un volum mare de date relaţionale. TPC-
D include o schemă fulg de zăpadă cu mai multe tabele de fapte şi tabele de
dimensiuni. Dimensiunile au o structură simplă. Benchmark-ul prezintă un set de
cereri specifice mediului SSD.
Standardul OLEDB pentru OLAP [MICR98] a fost dezvoltat de firma
Microsoft ca un set de obiecte COM şi interfeţe destinate pentru a furniza acces la
surse de date multidimensionale prin OLEDB. Standardul OLEDB pentru OLAP
utilizează un model pentru cuburi şi dimensiuni şi oferă un limbaj de expresii
multidimensionale (MultiDimensional eXpressions/MDX) pentru calcule şi
prezentări de cuburi. Acest standard are o serie de dezavantaje: îi lipseşte un suport
teoretic solid (nu există definită schema unui multicub) şi utilizează un limbaj prea
complex (deşi destul de puternic).
Metadata Interchange Specification [META97] a fost propus de Metadata
Coalition (un grup de firme cum ar fi IBM, Sybase, Informix etc). MDIS oferă un
mecanism de acces standard şi o interfaţă API standard pentru a gestiona
metadatele cu instrumente specificate de standard. MDIS încearcă să prezinte un
metamodel de metadate pentru o varietate de modele de baze de date (relaţional,
orientat-obiect etc). Modelul propus de MDIS suportă noţiunea de dimensiune
(care include un set de niveluri). Cuburile nu sunt direct modelate în modelul
106
MDIS. În tabelul 4.2 este prezentată o analiză comparativă între standardele

descrise mai sus (C-cub, T-tabela).
Tabelul 4.2
Comparaţie între standarde
Standarde Spaţiu multi- Limbajul Stocarea datelor
dimensional de interogare
Cuburi Ierarhii Procedu- Decla- ROLAP MOLAP
ral rativ
APB-1 C da Limbaj
propriu
TPC-D T SQL da
OLEDB C da C++ SQL da da
MDIS T da
În tabelul 4.3 este prezentată o clasificare a celor mai cunoscute instrumente
OLAP, în funcţie de modul de stocare a datelor multidimensionale şi de modul de
procesare multidimensională utilizat. Instrumentele din grupele 1, 2 şi 3 sunt
instrumente ROLAP, cele din grupele 4 şi 5 instrumente MOLAP, cele din grupa 6
instrumente desktop OLAP, iar cele din grupele 2, 4 instrumente OLAP hibride
(cele scrise italic). În tabelul 4.4 sunt prezentate produse OLAP cu facilităţi Web,
iar în tabelul 4.5 este prezentată o evaluare a câtorva instrumente OLAP luând în
considerare următoarele criterii: modul de vizualizare a datelor, tipul de aplicaţii,
modul de stocare a datelor, modul de procesare a datelor, tipul de arhitectură
utilizat, sistemul de operare utilizat şi limbajul utilizat.
Tabelul 4.3
Clasificarea instrumentelor OLAP
Modul de procesare Modul de stocare a datelor multidimensionale
multidimensională BDR BDMD Fişiere client
SQL în mai mulţi paşi 1.
Microstrategy
Motor OLAP pe server 2. 4.
IBM DB2 OLAP Server Comshare Decision
Informix Metacube Essbase
Microsoft OLAP Services Oracle Express,
Oracle Express Seagate Holos, Gentia
Pilot Analysis Server Microsoft OLAP
Seagate Holos Services
Applix TM-1 Power Play Enterprise
White Light Server
Pilot Analysis Server
Applix TM-1
Motor OLAP pe client 3. 5. 6.
Oracle Discoverer Dimensional Insight Brio Enterprise,
Informix MetaCube Comshare FDC Business Objects
Cognos PowerPlay
Personal Express
107
Tabelul 4.4
Produse OLAP cu facilităţi Web
Firma Produsul OLAP Produsul Web Modul de stocare
Arbor Software Essbase Essbase Web Gateway BDMD
Brio Technology Inc. BrioQueryEnterprise BrioQuery Enterprise BDR
Business Objects Inc Business Objects Business Objects BDR
Cognos Corp. Power Play PowerPlay BDR
Comshare Inc. Commander Decision CDWeb BDMD
Dimensional Insight Inc. CrossTarget DataFountain BDR
Information Advantage Inc. DecisionSuiteServer WebOLAP BDMD
InformixSoftware Inc. Informix MetaCube MetaCube for the Web BDR
Kenan Systems Corp. Acumate Es Acumate Web BDMD
Microstrategy Inc. DSS Server DSS Web BDR
Oracle Corp. Oracle Express Server Oracle Express Web Agent BDMD
Pilot Software Inc. Pilot Analysis Server Pilot Internet Publisher BDMD
Seagate Software IMG Holos Holos BDMD
TM-1 Software TM-1 Server TM-1Server BDMD
Tabelul 4.5
Analiză comparativă a instrumentelor OLAP
Produs Vizualizarea Tipul de aplicaţii Modul Modul de Tipul de Platforma Limbajul
OLAP datelor de procesare arhitectură utilizată utilizat
stocare
Power Play Tabele Analiza vânzarilor Fişiere Motor Client/ Server APL2000
Cognos Grafice, Analiză financiară BDR OLAP pe server Unix pentru
Rapoarte Controlul calităţii BDM client/ WinNT, aplicaţii
server Client financiare
Windows
DecisionBas Rapoarte HTML, Analiza vânzărilor BDM Motor Client/ Windows Orientat
e OLAP Grafice OLAP pe server pe trei obiect
Computer server niveluri
Associates
Oracle Rapoarte, tabele, Analiza vânzărilor BDR Motor Client/ Server Express
Express grafice Analiza financiară BDM OLAP pe Server, PC WinNT Basic
Oracle Fişiere server / Client
client Windows
Business Rapoarte Analiza vânzărilor Fişiere Motor Client/ WinNT Visual
Objects Analiza financiară OLAP pe server pe Basic
client două/trei
niveluri
DSS Rapoarte, grafice Marketing BDR SQL în Client/ Server SQL
Micro mai mulţi server WinNT
strategy paşi Client
Windows
Acumate Rapoarte Telecomunicaţii, BDM Motor Client/ Server Limbaj
Kenan Servicii OLAP pe server WinNT multidim
Systems financiare, server Client MSPL
marketing, Windows
Analiza
vânzărilor,
previziuni,
Segmentarea
pieţei,
Analiza clienţilor
Informix Rapoarte, grafice Analiza vânzărilor BDR Motor Client/ Server Limbaj
Metacube Analiză financiară OLAP pe server pe WinNT OO,
Informix server/ două şi trei Unix, SQL
Software client niveluri Client
Windows
108
Produs Vizualizarea Tipul de aplicaţii Modul Modul de Tipul de Platforma Limbajul

OLAP datelor de procesare arhitectură utilizată utilizat
stocare
DB2 OLAP Rapoarte Telecomu BDR Motor Client/ Server SQL
IBM nicaţii (Decision BDM OLAP pe server pe trei WinNT, Interfaţă
Edge), marketing, server niveluri OS/2 API
previziuni (motor Unix pentru
Essbase) Visual
Basic,
C
Microsoft Grafice, rapoarte Previzionări BDR Motor Client/ Server Visual

OLAP Analiză financiară BDM OLAP pe server WinNT Basic
Services server Unix
Microsoft VAX/
VMS
Sun, Mac,
Aix
Essbase Rapoarte, grafice Analiza de piaţă BDM Motor Client/ server Interfaţă
Arbor Analiza Fişiere OLAP pe server WinNT API
Software profitabilităţii, BDR server OS/2 pentru
Planificare, IBM-AIX Visual
Analiza bugetară, Sun Solaris Basic, C,
Previzionare, AS/400 Power
EIS Client Builder
Windows
Unix
Rezumat
Caracteristicile unui instrument OLAP sunt clasificate în două categorii:
caracteristici logice şi caracteristici fizice.
Cuvinte cheie
Caracteristici logice, caracteristici fizice, standarde OLAP.
109
Capitolul 5
Proiectarea sistemelor OLAP
Firmele şi mediul academic au acordat puţină atenţie problemelor legate de
modelarea multidimensională conceptuală. Tehnicile de modelare conceptuale
existente nu pot fi direct aplicate la caracteristicile modelului de date
multidimensional [BLAS98]. Ca o consecinţă, multe proiecte industriale elimină
etapa de modelare conceptuală şi încep cu proiectarea logică (de exemplu
modelarea unei scheme stea sau fulg de zăpadă).
Nu există la ora actuală, nici un standard pentru modelarea multidimensională
conceptuală a datelor. Există însă un consens general că tehnica de modelare
entitate-asociere nu este potrivită pentru proiectarea sistemelor cu depozite de date
şi a sistemelor OLAP. De exemplu, în [KIMB96] se precizează că “ modelele
entitate-asociere nu pot fi utilizate pentru proiectarea depozitelor de date la nivel
de întreprindere”, iar în [BULO96] că “modelul entitate-asociere nu este potrivit
pentru modelarea cuburilor n-dimensionale.”
În [BLAS98] se consideră că procesul de proiectare a modelului
multidimensional conceptual depinde foarte mult de cerinţele utilizatorilor şi de
valabilitatea şi structura datelor din sistemele operaţionale. Cele mai multe proiecte
folosesc o metodologie evolutivă [KIMB96],[INMO92]. Proiectele încep cu un
prototip, care este apoi modificat în concordanţă cu cerinţele utilizatorilor. Procesul
de proiectare a modelului multidimensional conceptual este executat de mai multe
ori (iterativ). Există două motive principale pentru acest comportament dinamic:
tehnologia de analiză multidimensională interactivă este nouă pentru
analist. Aceasta înseamnă că este imposibil pentru el să stabilească de la
început toate cerinţele aplicaţiei;
procesele de afaceri pe care analistul trebuie să le modeleze, se modifică
frecvent. Aceste modificări trebuie reflectate în cerinţele de analiză (noi
tipuri de cereri). Întrucât modelul multidimensional determină facilităţile
de analiză posibile, noile cerinţe conduc la modificări ale schemei bazei de
date.
La ora actuală se identifică două abordări în proiectarea modelului
multidimensional conceptual şi anume:
Abordarea orientată pe sursele de date ce presupune existenţa sistemului
informatic tranzacţional şi începe cu analiza datelor existente în baza de date
110
operaţională. Această abordare utilizează în general ca punct de pornire, modelul

entitate-asociere al bazelor de date operaţionale existente, pentru domeniul
analizat, pe care apoi îl transformă în modelul multidimensional (de exemplu
metoda lui Cabibbo [CABB98a] şi metoda lui Golfarelli [GOLF99]). De asemenea,
această abordare se utilizează în special, în procesul de proiectare a sistemelor
ROLAP, care utilizează un depozit de date pentru stocarea datelor
multidimensionale.
Abordarea orientată pe cereri este utilizată în absenţa surselor de date (şi a
modelelor entitate-asociere corespunzătoare). Pe baza studiului şi analizei
activităţii pentru care se construieşte sistemul OLAP, se vor identifica indicatorii
de performanţă ai activităţii respective (variabilele cubului n-dimensional). Această
abordare se poate utiliza în procesul de proiectare a sistemelor MOLAP.
Indiferent de tipul abordării, se utilizează aceleaşi concepte, iar paşii sunt
asemănători (figura 5.1).
Modelarea multidimensională datelor
Orientată pe cereri Orientată pe surse de date
Identificarea măsurilor (variabilelor) Identificarea faptelor

Identificarea dimensiunilor şi a Identificarea dimensiunilor şi a
ierarhiilor ierarhiilor
Identificarea hypercubului sau a Identificarea măsurilor
structurii multicub
Figura 5.1 Abordări în modelarea multidimensională a datelor

În cele ce urmează, se vor prezenta câteva metode de modelare
multidimensională şi anume: metoda lui Cabibbo, metoda lui Golfarelli şi metoda
lui Thomsen. Ele utilizează concepte asemănătoare (de exemplu conceptul de
dimensiune, ierarhie, măsură, fapt), dar etapele parcurse pentru proiectarea
modelului multidimensional conceptual sunt diferite.
5.1 Metoda lui Cabibbo şi Torlone

Metoda propusă de autori, pentru proiectarea unei model multidimensional
[CABB98b] are ca punct de pornire modelul entitate-asociere al bazelor de date
operaţionale existente pentru domeniul analizat. Se consideră că modelul entitate-
111
asociere existent este complet (conţine toate informaţiile necesare în procesarea

analitică) şi normalizat.
Metoda propusă constă din patru etape:
identificarea faptelor, dimensiunilor, ierarhiilor şi măsurilor;
restructurarea modelului entitate-asociere;
derivarea unui graf dimensional;
transformarea în modelul multidimensional.
De obicei, primele două etape nu sunt strict secvenţiale, în multe cazuri se
execută în paralel (în etapa de restructurare a modelului entitate-asociere, faptele şi
dimensiunile identificate pot fi rafinate şi modificate). Apoi celelalte etape se
execută secvenţial, întrucât fiecare etapă cere completarea etapei anterioare.
Autorii utilizează această metodă pentru a proiecta un model multidimensional
conceptual pentru analiza activităţii de desfacere a unei firme. Modelul entitate-
asociere al activităţii de desfacere este prezentat în figura 5.2.
5.1.1 Identificarea faptelor, dimensiunilor, ierarhiilor şi măsurilor
În prima etapă, se face o analiză atentă a modelului entitate-asociere existent

pentru a se identifica faptele, măsurile şi dimensiunile de interes pentru domeniul
analizat. Faptele pot fi entităţi, asocieri sau atribute ale modelului entitate-asociere,
importante în procesul decizional. O măsură este o propietate atomică a unui fapt
(în general un atribut numeric al unui fapt sau un număr al instanţelor lui). O
dimensiune este o subschemă a modelului entitate-asociere ce descrie o perspectivă
prin care analiză unui fapt poate fi executată.
Firma doreşte pe de o parte să cunoască evoluţia în timp a volumului vânzărilor
şi veniturile corespunzătoare, pe de altă parte analiza variaţiei costurilor de
producţie ale produselor vândute. În acest caz, faptele sunt entitatea Vânzare şi
atributul „cost” al entităţii Produs. Faptul Vânzare are următoarele măsuri:
„numărul de vânzări” (numărul de instanţe ale entităţii) şi veniturile obţinute din
vânzări (atributul „venit”). Faptul Cost are măsura „valoarea costului”.
De-a lungul unei dimensiuni, analiza unui fapt este executată prin consolidarea
(agregarea) datelor. De aceea, se poate identifica o dimensiune prin navigarea în
schemă începând de la fiecare fapt şi incluzând conceptele ce sugerează un mod de
a grupa datele (entităţile asociate prin relaţii (1:m) sau atributele după care se pot
face clasificări, de exemplu atributele „vârsta” sau „sex”). Se consideră de
exemplu, faptul Vânzare. Se poate vedea că fiecare vânzare este asociată cu
produsul corespunzător vândut şi fiecare produs este asociat cu categoria şi marca
corespunzătoare. Înseamnă că vânzările pot fi analizate după tipurile de produse
vândute, la diferite niveluri de agregare (produs, categorie, marcă). Astfel, o
posibilă dimensiune pentru analiza vânzărilor este Tipologia produsului vândut.
Această dimensiune include entităţile Produs, Marcă şi Categorie. Se poate, de
asemenea, observa că pentru unele vânzări există informaţii despre clientul asociat.
Clienţii pot fi grupaţi după vârstă, sex, oraş de reşedinţă şi ocupaţie. Deci o altă
112
dimensiune pentru analiza vânzărilor este Tipologia clientului. Această dimensiune

include entităţile Client şi Ocupaţie (şi atributele lor corespunzătoare). De
asemenea, Locaţia vânzărilor este o altă posibilă dimensiune pentru analiza
vânzărilor. Această dimensiune include numai entitatea Magazin. Se poate
identifica şi o dimensiune temporală pentru analiza vânzărilor (atributul „data-
vânzării” al entităţii Vânzare). Aceasta este o dimensiune fundamentală în analiza
multidimensională.
Figura 5.2 Modelul entitate-asociere
5.1.2 Restructurarea modelului entitate-asociere
În această etapă, se face o reorganizare a modelului entitate-asociere existent,

pentru a pune în evidenţă faptele şi dimensiunile. Această etapă include
următoarele activităţi :
Reprezentarea faptelor ca entităţi. În general, faptele corespund la entităţi, dar
pot corespunde şi la atribute sau asocieri. În aceste cazuri, este necesar să fie
transformate în entităţi. De exemplu, costul de producţie al unui produs este un
atribut în modelul entitate-asociere iniţial. Acest atribut poate fi transformat uşor
într-o entitate Cost al produsului prin adăugarea unei asocieri (1:1) între noua
entitate şi entitatea Produs (figura 5.3). Se poate întâmpla ca unele dimensiuni
importante pentru analiză să lipsească din modelul entitate-asociere al bazelor de
date operaţionale sursă, dar pot fi derivate din baze de date externe. De exemplu,
analiza efectivă a costurilor poate fi realizată numai prin comparaţia lor, în diferite
perioade de timp. De aceea, este necesar a se adăuga informaţii temporale despre
113
costuri. Dacă se consideră că se cunoaşte momentul exact al operaţiilor de

actualizare a costurilor şi că costurile se modifică de regulă, o singură dată pe lună,
se face restructurarea entităţii Cost. Astfel, între entitatea Produs şi entitatea Cost
apare o asociere (1:m), iar între entitatea Cost şi entitatea Luna o asociere (m:1)
(figura 5.4).
Cod produs
valoare
Produs Cost
produs
denumire
Figura 5.3 Restructurarea entităţii Cost
Rafinarea nivelurilor din fiecare dimensiune. În fiecare dimensiune trebuie să

se reprezinte într-un mod explicit, nivelurile de agregare importante pentru analiza
faptelor (de exemplu atributele „categorie” şi „marca” unui produs) şi să se
diferenţieze de conceptele ce sunt numai descriptive şi nu pot fi utilizate în analiză,
întrucât nu permit realizarea de agregări (de exemplu atributele „adresa” şi
„numărul de telefon” al unui magazin). În practică, această activitate presupune
următoarele transformări :
înlocuirea relaţiilor (m:m);
adăugarea de noi concepte (entităţi sau atribute) ce reprezintă noi niveluri
de agregare;
stabilirea unui identificator pentru fiecare entitate nivel;
eliminarea conceptelor irelevante.
Se consideră de exemplu, entitatea Client. Clienţii se pot agrega după vârstă,
sex şi oraş de reşedinţă. Dacă se doreşte agregarea clienţilor în funcţie de ocupaţia
lor, nu se poate utiliza direct entitatea Ocupaţie, întrucât între entităţile Client şi
Ocupaţie există o asociere (m:m), fiecare client are în general mai multe ocupaţii.
Totuşi se poate înlocui această entitate cu o nouă entitate Ocupaţia Principală ce
descrie ocupaţia unui client în cea mai mare parte a timpului, astfel că relaţia este
transformată din (m:m) în (1:m) (figura 5.4). Dimensiunea Locaţie constă din
entitatea Magazin. Ar putea fi de interes agregarea magazinelor după oraş şi zona
geografică (această informaţie poate fi derivată din atributul “adresa”). Aceasta
poate fi făcută explicit prin adăugarea unor noi entităţi Oraş şi Zonă (figura 5.4).
Pentru noile entităţi se stabileşte un identificator. Dacă se doreşte agregarea
vânzărilor, de exemplu după zile, luni, perioade speciale (Crăciun, Paşte etc),
trimestre şi ani se adaugă noi entităţi. Când toate dimensiunile au fost examinate,
pasul final constă în eliminarea conceptelor (entităţi, atribute şi relaţii) ce nu sunt
folositoare în procesarea analitică (de exemplu niveluri de agregare
nesemnificative). Modelul entitate-asociere obţinut după etapa de restructurare este
prezentat în figura 5.4.
114
Figura 5.4 Modelul entitate-asociere restructurat
5.1.3 Derivarea unui graf dimensional
Pornind de la modelul entitate-asociere restructurat, se poate deriva un graf

special numit dimensional. Un graf dimensional reprezintă faptele şi dimensiunile
modelului entitate-asociere restructurat. Fiecare nod al grafului corespunde unui
concept specific (entitate sau atribut), iar reprezentarea unui domeniu se face astfel:
dacă nodul corespunde la o entitate, se reprezintă domeniul cheii entităţii, iar dacă
nodul corespunde unui atribut, se reprezintă domeniul atributului. Arcul între două
noduri reprezintă o funcţie între domeniile corespunzătoare (arcul este punctat dacă
funcţia este parţială). Figura 5.5 reprezintă graful dimensional obţinut din modelul
entitate-asociere prezentat în figura 5.4. În acest graf, nodul Produs reprezintă
domeniul atributului “cod_produs”, nodul Luna reprezintă domeniul atributului
“nume” al entităţii corespunzătoare, nodul Venit reprezintă domeniul atributului
115
“venit” al entităţii Vânzare. Se observă că dimensiunile devin subgrafuri ale

grafului dimensional. În graful dimensional se pot distinge patru tipuri de noduri:
noduri de fapte (fact nodes) ce au marginile bolduite (ele îşi au originea în
entităţile de fapte);
noduri nivel (level nodes) sunt acelea ce apar într-o dimensiune;
noduri descriptive sunt noduri reprezentate în afara dimensiunilor, dar sunt
legate prin arce de nodurile nivel (se obţin din atributele descriptive);
şi noduri măsuri legate printr-un arc la un nod de fapte.
De exemplu, nodul Vânzare este un nod de fapte, nodul Valoare şi nodul Venit
sunt noduri măsuri, iar nodul Adresă este un nod descriptiv.
5.1.4 Transformarea în modelul multidimensional conceptual
Modelul multidimensional conceptual (figura 5.6) poate fi derivat din graful

dimensional şi anume:
fiecare dimensiune a grafului dimensional devine o dimensiune a
modelului multidimensional;
fiecare nod nivel al grafului devine un nivel al modelului
multidimensional;
fiecare arc al subgrafului corespuzător se transformă într-o funcţie de
agregare (roll-up).
Subgrafurile grafului dimensional, asociate cu dimensiunile, determină ordinea
parţială pe nivelurile modelului multidimensional. Trebuie să se definească, de
asemenea, un număr de dimensiuni atomice pentru a reprezenta nodurile măsuri şi
nodurile descriptive. De exemplu, se poate defini o dimensiune numerică pentru
veniturile obţinute din vânzări şi costurile produselor şi o dimensiune şir de
caractere pentru numele produselor şi adresele magazinelor.
În exemplul prezentat de autori, modelul multidimensional conceptual este
implementat în baze de date relaţionale şi transformat în schema stea. Tabelele de
fapte pot definite astfel: pentru fiecare nod de fapte din graful dimensional se
selectează o combinaţie de niveluri de la dimensiunile “asociate” (dimensiuni
pentru care există un arc de la nodul de fapte la ele). Se pot selecta mai multe
niveluri pentru fiecare dimensiune corespunzătoare şi nu toate dimensiunile
asociate cu un nod de fapte trebuie să fie selectate. În exemplu studiat sunt
identificate trei măsuri: cantitatea de produse vândute pentru fiecare tip de produs
şi în fiecare magazin, veniturile obţinute prin vânzarea fiecărui tip de produs, în
fiecare magazin şi costul lunar al produselor. Aceste măsuri pot fi reprezentate de
următoarele tabele de fapte:
Vânzare [timp: ziua, produs: produs, locaţie: magazin] : numeric (obţinută din
faptul Vânzare prin count(vânzare));
Venituri [timp: ziua, produs: produs, locaţie: magazin]: numeric (obţinută din
faptul Vânzare prin sum(venit(vânzare));
116
Costul produsului [timp: luna, produs: produs]: numeric (obţinută din faptul
Cost prin valoare(cost))
Produs
nume marca cost valoare
categorie produs
venit
sex
client vânzare zi luna
Timp
ocupaţie
princ Locatie
oraş Perioada trimestru
specială
magazin
vârsta zona an
Client adresa
Figura 5.5 Graful dimensional
Produs Locaţie
Denumire Vânzare Magazin
Marca Oraş
Categorie Zona
etc etc
Cost Client
Timp Sex
Ziua Vârsta
Luna Oraş
Trimestru etc
etc
Figura 5.6 Modelul multidimensional conceptual
117
Metoda lui Cabibbo poate fi utilizată în procesul de proiectare a unui

sistem ROLAP, care presupune utilizarea unui depozit de date pentru stocarea
datelor multidimensionale.
5.2 Metoda lui Golfarelli

În [GOLF99], Golfarelli propune o metodologie pentru proiectarea unui
depozit de date (poate fi utilizată pentru proiectarea unui sistem ROLAP). Această
metodologie pune accentul pe proiectarea modelului multidimensional conceptual.
În tabelul 5.1 sunt prezentate etapele acestei metodologii.
Tabelul 5.1
Metodologia de proiectare a unui depozit de date
Etape Intrări Ieşiri Personalul
implicat
Analiza sistemului documentaţia schema bazei de Proiectant,
informatic existent existentă date operaţionale manageri ai
sistemului
informatic
Specificarea schema bazei de faptele Proiectant,
cerinţelor date operaţionale utilizatori finali
Proiectarea schema bazei de modelul Proiectant
conceptuală date operaţionale, multidimensional
(modelul faptele
multidimensional)
Validarea modelului modelul modelul Proiectant,
multidimensional multidimensional multidimensional utilizatori finali
conceptual validat
Proiectarea logică modelul modelul logic al Proiectant
multidimensional, depozitului de
modelul logic date
utilizat
Proiectarea fizică modelul logic al modelul fizic al Proiectant
depozitului, depozitului
SGBD-ul ales
În timpul analizei sistemului operaţional proiectantul trebuie:

să verifice corectitudinea datelor sursă sau dacă lipsesc date importante
pentru analiză;
să selecteze sursele de date operaţionale în funcţie de calitatea datelor şi
stabilitatea schemelor lor;
să determine care date pot fi integrate în scopul de a obţine o viziune
completă. Persoanele implicate în această etapă sunt proiectantul
118
depozitului de date împreună cu cei care gestionează sistemul informatic

operaţional existent şi cu proiectanţii săi.
Specificarea cerinţelor constă în colectarea şi filtrarea cerinţelor utilizatorilor,
implicând atât proiectantul cât şi utilizatorii finali ai depozitului. Se obţin ca ieşiri
faptele şi cerinţele preliminare legate de procesul de încărcare a depozitului de
date. Stabilirea faptelor are ca punct de pornire modelul entitate-asociere al
sistemului informatic operaţional.
Proiectarea modelului multidimensional conceptual presupune parcurgerea
următorilor paşi:
identificarea faptelor;
construirea unui arbore al atributelor;
rafinarea arborelui;
definirea dimensiunilor;
definirea măsurilor;
definirea ierarhiilor.
Autorii proiectează modelul multidimensional conceptual pentru analiza
activităţii de desfacere (modelul entitate-asociere este prezentat în figura 5.7).
Fiecare instanţă a entităţii Vânzare se referă la un singur produs din bonul de casă.
Atributul “preţ unitar” aparţine entităţii Vânzare şi nu entităţii Produs, întrucât
preţul produselor poate varia în timp. Schema logică a bazei de date operaţionale
(cheile primare sunt subliniate, pentru fiecare cheie externă este prezentată schema
referită) este următoarea:
MAGAZINE(magazin, adresa, telefon, manager_vânzări, oras: ORASE, nrdistrict:
DISTRICTE)
ORASE (oraş, zona: ZONE)
STATE (stat)
ZONE (zona, stat: STATE)
DISTRICTE (nrdistrict, stat: STATE)
PRODUSE (codprodus, greutate, mărime, dieta, marca: MARCI, tip: TIPURI)
MARCI(marca)
TIPURI (tip, grup: GRUPURI, categorie: CATEGORII)
GRUPURI (grup, manager_grup marketing)
CATEGORII (categorie, departament: DEPARTAMENT)
DEPARTAMENTE (departament, manager_departament)
BONURI (nrbon, data, magazin: MAGAZINE)
VÂNZARI (codprodus: PRODUSE, nrbon: BONURI, cant, preţ unitar)
DEPOZITE (depozit, adresa)
PROD_DEPOZ (codprodus: PRODUSE, depozit: DEPOZITE)
5.2.1 Identificarea faptelor

Faptele sunt concepte importante pentru procesul decizional şi modelează
evenimente ce au loc în întreprindere (de exemplu vânzările). Un fapt poate fi
reprezentat în modelul entitate-asociere fie de o entitate F sau de o asociere R de
119
tip (m:m) între entităţile E1,….,En. În ultimul caz, pentru simplitate, este indicat a
se transforma relaţia într-o entitate F prin înlocuirea fiecărei ramuri Ei cu o relaţie
binară între F şi Ei. Atributele relaţiei devin atribute ale lui F, identificatorul lui F
este combinaţia identificatorilor lui Ei, i=1,…n. Entităţile sau asocierile care sunt
actualizate frecvent (cum ar fi Vânzare) pot fi considerate fapte. Cele care nu se
modifică frecvent (sunt aproape statice, cum ar fi entităţile Magazin şi Oraş) nu pot
fi considerate fapte. Fiecare fapt identificat în modelele entitate-asociere sursă,
devine rădăcină a unei scheme fapt.
Figura 5.7 Modelul entitate-asociere al bazei de date operaţionale
5.2.2 Construirea unui arbore al atributelor
Se consideră un model entitate-asociere şi o entitate F ce identifică un fapt. Se

numeşte arbore al atributelor (attribute tree) un semi-arbore în care :
fiecare vârf corespunde la un atribut (simplu sau compus) al modelului
entitate-asociere;
rădăcina corespunde la identificatorul lui F (cheia primară);
pentru fiecare vârf v, atributul corespunzător determină funcţional toate
atributele ce corespund descendenţilor lui v (figura 5.8).
120
Arborele atributelor va fi utilizat pentru a construi schema fapt. Rădăcina

arborelui se etichetează cu numele entităţii F (şi nu cu identificatorul ei). Relaţiile
opţionale dintre atributele unei ierarhii sunt puse în evidenţă în schema fapt (de
exemplu atributul “dieta”). O asociere (1:1) poate fi gândită ca un caz particular de
asociere (m:1) şi poate fi introdusă în arborele atributelor.
5.2.3 Rafinarea arborelui
Nu toate atributele arborelui sunt importante pentru analiză. De aceea, arborele

trebuie rafinat în scopul de a elimina nivelurile de detaliu nesemnificative pentru
analiză. Prin ştergerea unui subarbore, atributele componente vor fi şterse şi nu vor
fi incluse în schema fapt. Astfel, nu se vor putea utiliza pentru agregarea datelor.
De asemenea, există cazuri când un vârf al arborelui (ce conţine informaţii
nesemnificative) este şters, dar descendenţii lui trebuie păstraţi. De exemplu, se
poate dori clasificarea produselor direct după categorie, fără să se ia în considerare
informaţiile despre tipul lor. Dacă se consideră v vârful ce trebuie eliminat şi v’
părintele său, prin ştergerea lui v se mută întregul subarbore cu rădăcina din v în v’.
Ca rezultat, atributul v nu va fi inclus în schema fapt şi nivelul de agregare
corespunzător va fi eliminat. Pe de altă parte, toate nivelurile descendente vor
rămâne. De exemplu, atributul “număr bon” nu este important pentru analiză, de
aceea se elimină acest vârf şi arborele este transformat ca în figura 5.9.
Atunci când un vârf opţional este eliminat, toţi copiii lui moştenesc
opţionalitatea. De asemenea, dacă granulaţia unei entităţi E trebuie păstrată în
schema fapt, vârful corespunzător este păstrat, în timp ce unul sau mai mulţi copii
ai lui pot fi eliminaţi. Altfel, dacă granulaţia lui E este “prea fină”, vârful
corespunzător poate fi eliminat şi unii din copiii lui păstraţi.
marca
manager categorie dieta cant data manager adresa
Dept greutate dimen telefon
tip
codprodus vânzare nrbon magazin oras judet stat
manager grup pret unitar nrdistrict
Figura 5.8 Exemplu de arbore al atributelor
121
5.2.4 Definirea dimensiunilor
Dimensiunile determină cum pot fi agregate instanţele unui fapt. Dimensiunile

trebuie să fie alese din arborele de atribute (vârfurile copil ale rădăcinii, incluzând
şi atributele care au devenit copii ai rădăcinii, după ce arborele a fost rafinat).
Stabilirea dimensiunilor este o etapă importantă, întrucât determină granulaţia
instanţelor unui fapt. De asemenea, Timpul este o dimensiune importantă.
Modelele entitate-asociere pot fi clasificate în funcţie de modul cum tratează
timpul în fotografii (snapshot) şi temporale. Un model fotografie descrie starea
curentă a domeniului aplicaţiei (versiunile vechi ale datelor sunt înlocuite de noile
versiuni).
Un model temporal descrie evoluţia în timp a domeniului aplicaţiei (versiunile
vechi ale datelor sunt reprezentate explicit şi stocate). Când se utilizează un model
temporal, timpul este reprezentat explicit ca un atribut în modelul entitate-asociere
şi astfel poate deveni o dimensiune a schemei fapt. Timpul apare în arborele
atributelor uneori ca un copil al unor vârfuri diferite de rădăcină. Subarborele va fi
rafinat, în scopul de a deveni timpul o dimensiune (un copil al rădăcinii). În
modelul fotografie, timpul nu este reprezentat explicit (modelul reprezintă datele la
momentul curent). Totuşi, timpul ar putea fi adăugat ca o dimensiune a schemei
fapt. În exemplu prezentat, atributele alese ca dimensiuni sunt: Produs, Magazin şi
Săptămâna.
marca
manager categorie dieta cant data manager adresa
Dept greutate dimen telefon
tip
codprodus vânzare magazin oras judet stat
manager grup pret unitar nrdistrict
Figura 5.9 Rafinarea arborelui
5.2.5 Definirea măsurilor
Se construieşte un dicţionar care descrie modul cum se calculează aceste

măsuri pe baza atributelor modelului entitate-asociere sursă. Măsurile determinate
(cantitatea_vândută, volumul_vânzărilor, număr_clienţi) sunt afişate în schema
fapt.
Un fapt poate să nu aibă asociate atribute (singura informaţie ce este
înregistrată este apariţia faptului).
122
În unele cazuri, agregarea nu este necesară pentru a defini măsurile, întrucât a

fost deja executată la nivelul modelului entitate-asociere. De exemplu, fiecare
instanţă a entităţii Vânzare din modelul entitate-asociere ar putea descrie vânzările
totale săptămânale pentru fiecare produs, în fiecare magazin. În acest caz,
instanţele entităţii corespund (1:1) la instanţele faptului Vânzare şi atributele
entităţii pot fi transformate direct în măsuri.
5.2.6 Definirea ierarhiilor
Ultima etapă este definirea ierarhiilor în dimensiuni. În fiecare ierarhie,

atributele trebuie aranjate într-un semi-arbore astfel că între fiecare nod şi
descendenţii săi există o relaţie (1:m). Se pot adăuga noi niveluri de agregare (de
exemplu, în dimensiunea Timp se adaugă atributul “luna”). În această etapă, sunt
identificate atributele care nu sunt folosite pentru agregare ci numai pentru scopuri
informative (de exemplu atributele “adresa” şi “greutate”).
În etapa de validare a modelului multidimensional, se verifică dacă
dimensiunile şi măsurile au fost corect identificate şi ierarhiile bine structurate.
Proiectarea logică are ca intrări modelul multidimensional conceptual şi un set
de informaţii suplimentare (frecvenţa de utilizare, spaţiu de stocare valabil etc).
Este necesar să se stabilească modelul logic utilizat (relaţional sau
multidimensional). De exemplu, un model multidimensional conceptual poate fi
implementat în baze de date relaţionale prin scheme stea sau fulg de zăpadă. În
această etapă sunt create tabelele de fapte şi cele de dimensiuni pe baza modelului
multidimensional conceptual şi în funcţie de modelul logic adoptat. În cel mai
simplu caz, în care este adoptată schema stea, fiecare schemă fapt f=(M, A, N, R,
O, S) cu Dim(f)={d1, …dn} şi M={m1, …, mz} este transformată într-o tabelă de
fapte:
FT_f(k1, ….kn, m1,….mz) cu n tabele de dimensiuni:
DT_d1 (k1, a11,…., a1v1, a’11,…., a’1u1)
…………………………………………………
DT_dn (kn, a n1,…., a nvn, a’ n1,…., a’ nun)
Ierarhia din dimensiunea di include atributele dimensionale ai1,…., aivi şi
atributele a’i1,…., a’iui. De exemplu, schema stea pentru exemplu din figura 5.9
devine:
FT_VANZARE(codprodus, codtimp, codmagazin, volumul_vânzărilor,
număr_clienti, cantitatea_vândută)
DT_PROD (codprodus, produs, greutate, dieta, marca, oraş, tip, categorie,
departament, manager_departament, …..)
DT_TIMP (codtimp, data, ziua din săptămână, luna,…)
DT_MAGAZIN(codmagazin, magazin, telefon, adresa, manager de vânzări, oraş,
zona)
123
5.3 Metoda lui Erik Thomsen
În [THOM96] Erik Thomson propune o metodă pentru proiectarea modelului

multidimensional conceptual ce poate fi utilizată în proiectarea şi realizarea unui
sistem MOLAP sau ROLAP.
În etapă de analiză a cerinţelor, se vor analiza aspectele fizice şi logice ale
activităţii pentru care se construieşte sistemul OLAP. Se va stabili, pe bază de
interviu sau chestionar:
frecvenţa de utilizare a sistemului pe categorii de utilizatori;
numărul de utilizatori pe categorie şi categoriile de utilizatori ai sistemului;
tipul de dialog specific pentru fiecare categorie de utilizatori;
volumul de date utilizat de fiecare categorie de utilizatori, în timpul unei
sesiuni de lucru;
categoriile de informaţii vizualizate de fiecare categorie de utilizatori;
tipurile de instrumente utilizate pentru a vizualiza sau analiza datele;
volumul de date de intrare;
sursele de date şi problemele ce apar ca urmare a integrării acestor surse
eteroge;
tipurile de calcule ad-hoc ce se execută de regulă pe server;
tipurile de calcule ce trebuie antecalculate;
tipurile de calcule executate de regulă pe client;
frecvenţa de actualizare a datelor pe server;
tipurile de calculatoare, sistemele de operare şi configuraţiile de reţea
utilizate.
Proiectanul va culege informaţii de la toate persoanele care utilizează direct sau
indirect sistemul (utilizatori finali, operatori de date, administratori de sistem,
persoane responsabile pentru sursele de date etc). Unele din informaţiile relevante
pot fi exprimate de utilizatori sub formă de restricţii la soluţie. O soluţie poate
include următoarele tipuri de restricţii de sistem: tipul de calculator, sistemul de
operare, rezoluţia monitorului, protocolul de reţea, instrumentele client, numărul de
utilizatori ai sistemului, tipurile de date valide etc. Pe baza acestor informaţii se va
construi o diagramă a surselor şi a modului de utilizare (arată ce tipuri de date intră
în sistem şi cine utilizează datele). Este un model logic al situaţiei curente.
Pentru definirea modelului multidimensional conceptual se parcurg următorii
paşi:
definirea cuburilor şi a dimensiunilor;
rafinarea cuburilor n-dimensionale;
identificarea ierarhiilor;
identificarea variabilelor;
stabilirea formulelor de calcul necesare analizelor şi a tipurilor de agregare;
tratarea fenomenului de împrăştiere
definirea modelelor de calcul necesare analizelor.
124
5.3.1 Definirea cuburilor şi a dimensiunilor
Definirea cubului de date sau a structurii multicub va depinde, în primul rând,

de tipul şi formatul surselor de date. Aceste surse vor determina identificarea
dimensiunilor cubului şi a variabilelor. De exemplu, dacă sursa de date este un
depozit de date cu o schemă stea, atunci tabelele de dimensiuni vor deveni
dimensiunile cubului n-dimensional, iar din tabela de fapte se vor identifica
variabilele. Există instrumente OLAP care generează automat cubul n-dimensional,
dacă se cunoaşte schema stea a depozitului de date (de exemplu Oracle Express
Relational Manager).
În absenţa surselor de date, se vor identifica mai întâi, pe baza studiului şi
analizei activităţii pentru care se construieşte sistemul, variabilele sau indicatorii de
performanţă ai activităţii respective. Apoi pentru fiecare indicator (variabilă) se vor
stabili factorii în funcţie de care variază (dimensiunile cubului n-dimensional). De
exemplu, într-o aplicaţie pentru analiza vânzărilor, variabilele ar putea fi volumul
vânzărilor, costurile şi cantitatea vândută, iar dimensiunile Timpul, Locaţia şi
Produsul. Într-o aplicaţie de planificare a bugetului, variabilele ar fi veniturile
stabilite, cheltuielile alocate, iar dimensiunile Unitatea organizaţională, Timpul şi
Scenariu. În cazul structurii multicub, este important a se stabili de la început
dimensiunile comune.
5.3.2 Rafinarea cuburilor n-dimensionale
Structura multidimensională, identificată în etapa anterioară, se poate rafina

prin adăugarea sau ştergerea dimensiunilor. Pentru a elimina valorile fără
semnificaţie şi a reduce explozia datelor derivate în cub, se pot combina două sau
mai multe dimensiuni într-o singură dimensiune. De asemenea, se pot adăuga
dimensiuni şi anume dimensiunea Timp (dacă nu există), o dimensiune foarte
importantă în sistemele OLAP. Este necesar a se stabili şi dimensiunile care se
modifică frecvent şi care este rata de modificare a fiecărei dimensiuni. Unele
dimensiuni nu se modifică în timp, în special dacă modelul este utilizat pe termen
scurt. Cele mai frecvente modificări apar de obicei, în dimensiunile Produs,
Organizaţie şi Locaţie geografică. Există diferite metode de modelare a acestor
modificări şi anume:
se păstrează copii multiple ale dimensiunilor şi se construiesc cuburi
separate pentru fiecare versiune de dimensiune;
se păstrează o singură dimensiune în cub ce reprezintă reuniunea
versiunilor;
se păstrează versiuni explicite pentru dimensiuni într-un singur cub
[KIMB96].
125
5.3.3 Identificarea ierarhiilor din dimensiuni

Dimensiunile pot avea structură ierarhică. Problema care apare este de a stabili
tipul de ierarhie : simetrică sau asimetrică. De exemplu, dimensiunea Timp are o
structură ierarhică simetrică şi se pot identifica nivelurile: zi, luna, trimestru şi an.
De asemenea, dimensiunea Locaţie geografică poate fi o dimensiune cu structură
ierarhică simetrică cu nivelurile: ţară, regiune, judeţ şi oraş. Este necesar a se defini
relaţiile de tip părinte-copil între nivelurile unei ierarhii. De asemenea, se vor
identifica dimensiunile care conţin ierarhii multiple şi criteriile de grupare a
membrilor. De exemplu, produsele se pot grupa după tip, culoare, mărime sau zonă
geografică de destinaţie. O problemă destul de importantă este de a stabili dacă se
utilizează dimensiuni cu ierarhii multiple sau fiecare ierarhie va deveni o
dimensiune separată. În general, se examinează cardinalitatea relaţiilor ce apar între
membrii dimensiunilor. De exemplu, dimensiunea Produs conţine ierarhii multiple,
în care produsele pot fi grupate după categorii, mărci etc. Timpul este un exemplu
de dimensiune, în care nivelurile sunt reprezentate frecvent ca dimensiuni separate,
în special săptămânile şi lunile.
5.3.4 Identificarea variabilelor
Pe baza studiului şi analizei activităţii pentru care se construieşte sistemul, se

identifică variabilele sau indicatorii de performanţă ai activităţii respective. Pentru
fiecare variabilă se stabilesc dimensiunile corespunzătoare. De exemplu, pentru
analiza vânzărilor, variabila “cantitatea vândută” depinde de dimensiunile Timp,
Locaţie geografică şi Produs. De asemenea, fiecare variabilă va fi analizată, în
scopul de a se determina dacă este aditivă, semiaditivă sau neaditivă.
5.3.5 Stabilirea formulelor de calcul şi a tipurilor de agregare
O componentă cheie a modelării multidimensionale este definirea formulelor şi

în special a formulelor de agregare. O astfel de formulă poate fi o simplă sumă a
doi membrii sau complexă, un sistem de ecuaţii. Pentru cele mai multe aplicaţii,
majoritatea formulelor de agregare sunt sume sau medii aritmetice. Cu excepţia
variabilelor, cele mai multe dimensiuni cum ar fi Produs, Client, Timp, Locaţie
geografică sunt ierarhice şi sunt utilizate în agregări.
5.3.6 Tratarea fenomenului de împrăştiere
Când se proiectează şi implementează un sistem OLAP, trebuie să se cunoască

următoarele aspecte: cum sunt împrăştiate datele şi ce tip de împrăştiere există.
Unele instrumente stabilesc automat dacă datele sunt împrăştiate şi care combinaţii
de dimensiuni sunt cele mai împrăştiate. Totuşi este bine ca proiectantul să acorde
126
destulă atenţie fenomenului de împrăştiere, deoarece tipul de împrăştiere va afecta

analizele executate.
5.3.7 Definirea modelelor de calcul complexe necesare analizelor

Dacă sistemul OLAP va fi folosit pentru analize complexe, în special pentru
previziuni, se vor defini modelele de realizare a acestor analize. Unele instrumente
OLAP au incluse astfel de modele, în acest caz proiectantului îi revine sarcina de a
alege modelul adecvat.
De asemenea, Erik Thomsen propune şi un mod de reprezentare a unui cub n-
dimensional, în care segmentele verticale reprezintă dimensiunile cubului n-
dimensional, iar pentru fiecare segment se specifică nivelul de granulaţie şi direcţia
de agregare (figura 5.10).
La ora actuală nu există nici o metodologie unanim acceptată pentru
proiectarea şi realizarea unui sistem OLAP, dar există un consens general că
proiectarea unui sistem OLAP (în special a unui sistem ROLAP) este un proces
complex şi evolutiv. În figura 5.11 se prezintă un cadru generalizat al etapelor
acestui proces evolutiv. Se consideră că aceste etape ar trebui parcurse indiferent că
se proiectează un sistem ROLAP sau un sistem MOLAP.
De asemenea, se observă că modelarea multidimensională a datelor reprezintă
o etapă centrală în proiectarea unui sistem OLAP.
Locaţie geografică Produs Timp
1 ∧ 1 ∧ 1 ∧
Variabile pentru analiza vânzărilor:
- volumul vânzărilor 10 ∧ 500 ∧ 10 ∧
- cantitatea vândută •
- numărul de clienţi etc 100 • 10000 500 •
Notă: dimensiunea Locaţie geografică are trei niveluri ierarhice (ţara, judeţ, oraş) cu 1,
10 şi 100 de membrii fiecare nivel. Nivelul de granulaţie de bază este oraşul, iar
direcţia de calcul şi agregare este simbolizată prin săgeată cu linie întreruptă.
Figura 5.10 Reprezentarea grafică a unui cub n-dimensional
Procesul de proiectare a modelului conceptual multidimensional depinde foarte

mult de cerinţele utilizatorilor, de valabilitatea şi structura datelor din sistemele
operaţionale sursă. Identificarea cerinţelor este foarte mult orientată pe înţelegerea
domeniului problemei, pentru care modelarea va fi făcută. Pentru identificarea
cerinţelor se folosesc tehnici tradiţionale cum ar fi interviurile cu utilizatorii finali,
studiul documentelor existente şi rapoartelor. Aceste cerinţe vor fi punctul de
pornire în proiectarea modelului multidimensional conceptual.
127
Cadrul generalizat din figura 5.11 încearcă să grupeze cerinţele utilizatorilor în

două categorii şi anume: cerinţe orientate pe proces şi cerinţe orientate pe
informaţii (figura 5.12) [BALL98].
Pentru sistemele ROLAP, care utilizează un depozit de date pentru stocarea
datelor multidimensionale, este foarte dificil de a identifica, în etapa de studiu şi
analiză a cerinţelor informaţionale, toate cerinţele utilizatorilor. De aceea, se
consideră a fi utilă şi importantă această structurare, pentru a putea fi identificate
mai uşor cerinţele.
Cerinţele orientate pe proces se referă la principale activităţi de prelucrare a
informaţiilor stocate (de regulă într-un depozit de date), executate de utilizatori.
Din această categorie de cerinţe fac parte:
Obiectivele proiectului. Se pot stabili unul sau mai multe obiective şi pot fi
exprimate textual astfel: ”Depozitul de date trebuie să suporte analiza costurilor
de producţie şi a veniturilor obţinute prin vânzarea produselor fabricate şi vândute
de firma X”. Aceste obiective pot fi folosite pentru a identifica domeniile
(subiectele) de interes implicate în proiect şi variabilele ce vor fi analizate. În
exemplu de mai sus, subiectele de interes sunt produsele şi vânzările. Obiectivele
indică că variabilele globale folosite în procesul de analiză a informaţiilor sunt
“costul de fabricaţie” şi “venitul obţinut din vânzări”.
Tipurile de cereri reprezintă cereri, ipoteze şi întrebări analitice pe care
utilizatorii încearcă să le rezolve în activităţile de analiză. Aceste cereri sunt
exprimate în termenii specifici activităţii analizate, în general nu sunt precis
formulate şi nu sunt exprimate în limbaj SQL. Exemple de tipuri de cereri frecvent
folosite:
cereri de verificare a existenţei cum ar fi : ”S-a vândut un anume tip de
produs la un anumit client?”;
cereri de comparare cum ar fi : ”Să se compare valoarea comenzilor a doi
clienţi pe ultimele şase luni” sau “Să se compare numărul de produse dintr-
o anumită categorie, vândute săptămânal, în fiecare magazin”;
cereri de analiză a tendinţelor cum ar fi : ”Care este tendinţa vânzărilor
pentru un grup de produse, în ultimele 12 luni?”;
cereri de analiză statistică cum ar fi : ”Să se calculeze media vânzărilor pe
categorii de produse şi regiuni.”
Scenariile de analiză a datelor sunt un mod de a adăuga substanţă la setul de
cerinţe ce sunt identificate şi analizate. Din păcate sunt mai greu de obţinut decât
alte cerinţe de prelucrare şi de aceea, nu sunt întotdeauna valabile pentru analiza
cerinţelor. De exemplu, pentru modelarea depozitului de date se pot folosi două
tipuri de scenarii:
Scenarii pentru fluxul de execuţie a cererilor. Aceste scenarii reprezintă
secvenţe de cereri pe care utilizatorii finali le execută în activitatea de
analiză şi sunt utile pentru a crea o mai bună înţelegere a procesului de
analiză a informaţiilor;
Strategii de inferenţă a cunoştinţelor. Aceste cerinţe confirmă faptul că
activităţile executate de utilizatorii finali au caracteristici de sistem expert.
Cele mai simple forme de strategii sunt acelea care arată cum utilizatorii
execută operaţii de drill down şi roll up de-a lungul ierarhiilor.
128
Cerinţele orientate pe informaţii se referă la principalele categorii de

informaţii şi date ce sunt cerute de utilizatori pentru activităţile de analiză şi
anume:
subiectele informaţionale (information subject areas) sunt informaţii
folosite pentru a construi modelul de date la nivelul întreprinderii. Aceste
subiecte indică scopul proiectului şi permite analistului de a corela
proiectul cu alte părţi deja proiectate ale depozitului de date sau cu centrele
de date existente. De exemplu, subiecte informaţionale de interes pot fi:
produsele, vânzările şi producţia (incluzând stocurile) etc. Deşi vânzările
se fac la clienţi, deci sunt şi ei implicaţi, nu există întotdeauna o cerinţă de
a include subiectul „Clienţi” în proiect.
modelele de date valabile ca modele la nivel de întreprindere, modelele
entitate-asociere sau modelele multidimensionale deja existente.
Etapa de proiectare a modelului multidimensional conceptual este structurată în
trei subetape şi anume: proiectarea modelului multidimensional conceptual iniţial,
rafinarea modelului multidimensional şi validarea modelului multidimensional. Se
consideră că aceste subetape trebuie executate indiferent că se proiectează un
sistem ROLAP sau MOLAP. De asemenea, în ceea ce priveşte proiectarea
modelului multidimensional iniţial, se identifică două abordări: una orientată pe
cereri şi alta orientată pe sursele de date. Rafinarea modelului multidimensional
presupune stabilirea nivelurilor de granulaţie pentru dimensiuni şi măsuri, stabilirea
tipurilor de agregare, tratarea fenomenului de împrăştiere (în special pentru
sistemele MOLAP), stabilirea metadatelor pentru elementele modelului
multidimensional (în special pentru sistemele ROLAP). Validarea modelului
multidimensional presupune verificarea coerenţei şi completitudinii modelului
multidimensional conceptual şi dacă corespunde cerinţelor utilizatorilor.
În etapa de proiectare logică modelul multidimensional conceptual se
transformă într-un model logic în funcţie de tipul de implementare ales. De
exemplu, pentru sistemele ROLAP se transformă în schema stea sau fulg de
zăpadă, identificându-se tabelele de fapte şi tabelele de dimensiuni
corespunzătoare.
În etapa de proiectare fizică, se stabileşte dimensiunea bazei de date sau
tehnicile de optimizare utilizate (tipuri de indecşi, clustere), în special pentru
sistemele ROLAP.
Urmează etapa de construire şi testare a sistemului OLAP care pune accentul
pe definirea modelelor de analiză complexe, realizarea şi testarea elementelor
componente ale interfeţei, realizarea prototipului şi testarea lui împreună cu
utilizatorii. În această etapă, se stabilesc ce produse software şi arhitecturi se
folosesc.
În etapa de implementare este inclusă încărcarea iniţială cu date a bazei de date
(pentru prima iteraţie a ciclului de proiectare şi realizare a sistemului OLAP). Dacă
există un volum mare de noi cerinţe, începe o nouă iteraţie a ciclului de proiectare.
Acest cadru generalizat va fi utilizat ca metodologie în capitolul 9 pentru
proiectarea şi realizarea unui sistem MOLAP.
129
Iniţierea proiectului (definirea problemei)
Studiul şi analiza procesului decizional curent şi a cerinţelor

informaţionale ale utilizatorilor
Cerinţe orientate Cerinţe orientate

pe proces pe informaţii
Proiectarea modelului multidimensional conceptual
Orientată pe cereri Orientată pe sursele de date
Rafinarea modelului multidimensional
Validarea modelului multidimensional
Proiectarea logică (BDR/BDM)
Proiectarea fizică
Construirea şi testarea sistemului OLAP
Implementarea sistemului OLAP
Întreţinerea şi funcţionarea sistemului OLAP
Figura 5.11 Cadru generalizat al etapelor de proiectare şi realizare a sistemelor

OLAP
130
Tipuri de cereri, ipoteze,….
Modele multi
Obiectivele proiectului dimensionale
Subiecte /domenii Analiza
iniţiale
datelor
Cerinţe validate
Scenarii
Variabile, colecţii de fapte, dimensiuni,

entităţi
Figura 5.12 Identificarea cerinţelor
Rezumat
Nu există la ora actuală nici un standard pentru modelarea multidimensională
conceptuală a datelor. Există însă un consens general că tehnica de modelare
entitate-asociere nu este potrivită pentru proiectarea sistemelor cu depozite de
date şi a sistemelor OLAP.
Procesul de proiectare a modelului multidimensional conceptual depinde
foarte mult de cerinţele utilizatorilor şi de valabilitatea şi structura datelor din
sistemele operaţionale.
La ora actuală se identifică două abordări în proiectarea modelului
multidimensional conceptual şi anume: abordarea orientată pe sursele de date ce
presupune existenţa sistemului informatic tranzacţional şi începe cu analiza
datelor existente în baza de date operaţională şi abordarea orientată pe cereri ce
este utilizată în absenţa surselor de date.
Modelarea multidimensională a datelor reprezintă o etapă centrală în
proiectarea unui sistem OLAP.
La ora actuală nu există nici o metodologie unanim acceptată pentru
proiectarea şi realizarea unui sistem OLAP, dar există un consens general că
proiectarea unui sistem OLAP (în special a unui sistem ROLAP) este un proces
complex şi evolutiv.
Cuvinte cheie
Modelarea multidimensională a datelor, modelul multidimensional conceptual,
abordare orientată pe sursele de date, abordare orientată pe cereri, fapte,
dimensiuni, ierarhii, măsuri.
131
Capitolul 6
Dezvoltarea sistemelor OLAP cu
Oracle Express Objects
Oracle Express este un pachet software de tip sistem de gestiune a bazelor de
date multidimensionale (SGBDMD) cu următoarele caracteristici:
oferă un limbaj de manipulare a datelor foarte puternic;
utilizează modelul de date multidimensional;
utilizează o arhitectură client/server (Oracle Express Server) sau o
arhitectură pe un singur nivel (Oracle Personal Express);
permite dezvoltarea de aplicaţii OLAP care pot fi executate utilizând un
browser Web.
Instrumente de dezvoltare
Express Express Express Web Financial Sales
Objects Analyzer Publisher Analyzer Analyzer
BDR (depozite
de date)
Nucleul (limbajul Express)
BDMD
Utilitare pentru administrare

fişiere
Express Instance Express Relational
Manager Administrator Access Manager
Figura 6.1 Arhitectura pe componente a lui Oracle Express
132
Dezvoltarea sistemelor OLAP cu Oracle Express Objects
Arhitectura pe componente a lui Oracle Express este formată din (figura 6.1):
Utilitare pentru administrare (Express Instance Manager, Express

Administrator şi Relational Access Manager). Oracle Express Administrator este
un utilitar pentru crearea, configurarea şi instalarea bazei de date Oracle Express.
Acest utilitar permite crearea bazei de date Express, a elementelor ei componente
(măsuri, dimensiuni, ierarhii, selecţii etc) şi a programelor de încărcare a datelor
din fişiere externe în baza de date. Aplicaţiile OLAP dezvoltate cu Oracle Express
pot accesa direct date stocate în baze de date relaţionale (depozite de date) cu
ajutorul lui Relational Access Manager (RAM). Express Instance Manager este un
utilitar orientat Java ce utilizează comunicaţii CORBA şi care gestionează şi
configurează servicii şi sesiuni de lucru. Fiecare instanţă Express Server este un
serviciu ce permite utilizatorilor acces la bazele de date multidimensionale sau
aplicaţii prin interfeţe de tip SNAPI (Structured n-dimensional Application
Programming Interface), XCA (Express Communications Architectures) sau
Express Web Agent. De asemenea, Express Instance Manager permite modificarea
parametrilor de configurare a instanţelor Express.
Instrumente de dezvoltare. Oracle Express Analyzer este un instrument OLAP
care permite utilizatorilor să selecteze, afişeze şi analizeze datele stocate în baza de
date multidimensională. Oracle Express Objects este un instrument OLAP ce
permite dezvoltarea de aplicaţii OLAP şi utilizează limbajul de programare
Express.
Conexiunile la baza de date multidimensională se definesc cu editorul de
conexiuni (Express Connection Editor). Aceste conexiuni sunt utilizate de
aplicaţiile dezvoltate cu Oracle Express Objects/Analyzer. Fiecare conexiune
definită se salvează într-un fişier de conexiune cu extensia (.xcf) ce conţine
informaţii despre versiunea bazei de date şi locaţia fişierelor corespunzatoare.
Pentru a defini o conexiune Express se selectează editorul de conexiuni. Se
deschide fereastra de dialog Express Connection Editor. Se selectează butonul
Define şi se deschide fereastra de dialog Connection Settings (figura 6.2). Se
introduce numele fişierului de conexiune cu locaţia corespunzătoare şi descrierea
conexiunii (se specifică serverul la care se face conexiunea). Se selectează
versiunea de Express (Express Server sau Personal Express). Se introduce numele
(host name) sau adresa IP a serverului Express la care se face conexiunea. Se alege
protocolul de transport. De exemplu ncacn_ip_tcp (TCP/IP), dacă sistemul de
operare este Windows. Se introduce identificatorul unic universal (universal unique
identifier-uuid) pentru a identifica unic instanţa Express. Pentru protocolul
ncacn_ip_tcp nu se introduce numărul portului (end point) pe care serverul Express
acceptă cereri de conexiune. Se alege tipul de autentificare şi nivelul de securitate
şi se salvează setările.
Oracle Express Objects este un instrument OLAP ce permite crearea de
aplicaţii OLAP şi briefing-uri complexe care pot fi rulate şi în Express Analyzer,
precum şi realizarea de programe în limbaj Express, prin care se controlează
comportamentul aplicaţiei. Acest instrument este un element cheie în pachetul de
133
instrumente pentru inteligenţa afacerilor Oracle Integrated Business Intelligence

Tools, fiind integrat cu Oracle Discoverer. Aplicaţiile OLAP dezvoltate cu Oracle
Express Objects accesează datele stocate în baze de date multidimensionale sau
baze de date relaţionale.
Figura 6.2 Definirea unei conexiuni cu Express Connection Editor

Fereastra principală a lui Express Objects [DAOE98] are următoarele
componente (figura 6.3):
Titlu ferestrei (title bar) ce afişează numele aplicaţiei OLAP şi al
obiectului activ;
Meniul principal (menu bar) cu opţiunile: File, Edit, Database, Layout,
Window şi Help;
Selectorul (selector bar) ce permite un acces mai rapid la facilităţile oferite
de instrumentul Selector;
Bara (Layout toolbar) cu instrumentele ce permit îmbunătăţirea interfeţei
aplicaţiei (de exemplu: alinierea obiectelor, redimensionarea lor etc);
Bara de instrumente (main window toolbar) ce permite un acces mai rapid
la facilităţile oferite de Express Objects (de exemplu New Project, Object
Browser, Database Browser, Open Project etc);
Bara de stare (status bar) ce afişează informaţii despre activitatea curentă
(de exemplu ora curentă);
Caseta de instrumente (toolbox) utilizate pentru a crea diferitele obiecte ale
interfeţei aplicaţiei (de exemplu: pagini, tabele, grafice, butoane etc).
134
6.1 Utilitarul Object Browser

Utilitarul Object Browser permite vizualizarea conţinutului unui proiect sau a
unui briefing (dosar). Cu acest utilitar (figura 6.4) se pot:
deschide şi vizualiza mai multe proiecte (opţiunea View Projects din bara
de butoane corespunzătore lui Object Browser) sau briefing-uri (opţiunea
View Briefings);
selecta, muta, copia, şterge, deriva obiecte incluse în proiect/briefing;
muta, copia sau referi obiecte între proiecte/briefing-uri;
edita şi modifica pagini;
se pot vizualiza propietăţile obiectelor cu Object Inspector;
specifica diferite acţiuni (de exemplu QuickActions) pentru obiecte;
lansa în execuţie briefing-uri/proiecte etc.
Un proiect este unitatea de bază pentru stocarea obiectelor create cu Express
Objects. Este un container rădăcină ce include celelalte obiecte. Proiectele sunt
stocate în fişiere cu extensia (.xpj). Briefing-ul (o colecţie ordonată de pagini) este
inclus într-un proiect şi se stochează într-un fişier cu extensia (.xbr). O aplicaţie
OLAP poate fi formată din unul sau mai multe proiecte.
Figura 6.3 Componentele ferestrei principale
135
Se poate utiliza Object Inheritance Browser (opţiunea View Inheritance din

bara de butoane corespunzătoare lui Object Browser) pentru a vizualiza relaţia
părinte-copil pentru toate obiectele create. Se afişează toate obiectele predefinite de
Oracle Express Objects, dar şi obiectele ce sunt derivate din aceste obiecte
(figura 6.5).
Figura 6.4 Object Browser
6.2 Crearea unui proiect

Pentru a crea un proiect se selectează opţiunea Create a new Project din
fereastra de dialog Oracle Express Objects sau opţiunea File/New Project din
meniul principal sau icoana New project din bara de instrumente a ferestrei
principale. Se deschide fereastra New Project (figura 6.6) în care se tastează
numele proiectului (valoare a propietăţii Name), descrierea proiectului (valoare a
propietăţii Description) şi tipul de proiect (standard sau de tip briefing). Numele nu
trebuie să fie un şir mai mare de 8 caractere alfanumerice (primul caracter o literă).
Proiectele se pot lansa în execuţie şi din Express Analyzer, dar nu pot fi modificate.
Briefing-urile pot fi editate şi executate din Express Analyzer, dar codul scris în
limbajul Express nu poate fi modificat. Un proiect poate conţine unul sau mai
multe briefing-uri sau una sau mai multe pagini.
Dacă se creează un briefing, se utilizează Briefing Editor pentru a edita
paginile din briefing sau pentru a adăuga noi pagini. Pentru a afişa Briefing Editor
se selectează icoana corespunzătoare din caseta de instrumente (toolbox) sau se
136
face dublu click cu mouse-ul pe briefing-ul creat sau se selectează opţiunea Edit
din meniul ataşat butonului dreapta al mouse-ului (briefing-ul este selectat cu
mouse-ul). Briefing Editor conţine o bară de instrumente (Briefing Toolbar) ce
permite navigarea între paginile briefing-ului, un browser pentru a afişa briefing-
urile deschise şi o zonă de editare a paginii curente (figura 6.7).
Figura 6.5 Object Inheritance Browser
Pentru a adaugă o nouă pagină la un briefing, se selectează briefing-ul şi apoi

se selectează icoana Page din caseta de instrumente (Toolbox) sau se selectează
icoana New Page din bara de instrumente a Briefing Editor-ului (figura 6.7).
6.3 Deschiderea, închiderea şi lansarea în execuţie

a unui proiect
Se utilizează fereastra de dialog Open Project pentru a selecta şi deschide
proiectul dorit (opţiunea File/Open Project din meniul principal). Se utilizează
opţiunea File/Close Project din meniul principal pentru a închide un proiect sau
opţiunea File/Close All Projects pentru a închide toate proiectele deschise la un
moment dat.
137
Pentru lansarea în execuţie a unui proiect se selectează opţiunea Run an

Application or Briefing din fereastra de dialog Oracle Express Objects sau
opţiunea File/Run din meniul principal.
În Oracle Express Objects se pot utiliza meniurile ataşate butonului dreapta al
mouse-ului pentru a executa mai rapid diferite acţiuni. Conţinutul meniului este
specific obiectului la care este asociat meniul. Opţiunile din partea de sus a
meniului oferă acces la acţiuni comune tuturor obiectelor (de exemplu: duplicarea
obiectului, derivarea obiectului, ştergerea obiectului etc), iar opţiunile din partea de
jos a meniului se referă la propietăţi specifice obiectului. Dacă se doreşte
dezactivarea acestui meniu se setează propietatea ShowDefaultPopup pe No
(propietatea este inclusă în setul de propietăţi PopupMenus). De asemenea, se
poate modifica acest meniu (ce opţiuni din meniu se vor afişa la momentul
execuţiei) prin utilizarea ferestrei de dialog Popup Menu Attributes. Se selectează
obiectul (tabela/graficul/lista cu valorile unei dimensiuni) cu mouse-ul, se afişează
propietăţile obiectului cu Object Inspector. Se selectează (dublu click) propietatea
PopuMenuAttributes din setul de propietăţi PopupMenus şi se deschide fereastra de
dialog Popup Menu Attributes (figura 6.8). Coloana V indică dacă opţiunea este
vizibilă, coloana E indică dacă opţiunea este activată.
Figura 6.6 Fereastra New Project
138
6.4 Crearea, editarea şi lansarea în execuţie a unei pagini

Un proiect (sau briefing) poate fi format din mai multe pagini. Pentru a crea o
pagină se selectează (dublu click) icoana Page din caseta de instrumente (Toolbox)
sau dublu click pe icoana Table sau Graph (se creează automat şi pagina
corespunzătoare).
Pentru a lansa în execuţie o pagină, se selectează opţiunea Run din meniul
ataşat butonului dreapta al mouse-ului sau se selectează opţiunea Run Page din
meniul ataşat paginii (colţul stânga al paginii). Tot din acest meniu se poate selecta
opţiunea Close pentru a închide o pagină sau opţiunea Stop Running Page pentru a
opri execuţia unei pagini şi a reveni în modul de editare a paginii. Pagina se poate
edita şi prin selectarea ei (dublu click) din Object Browser.
Figura 6.7 Briefing Editor
Pagina poate avea multe propietăţi asociate. De exemplu se utilizează fereastra

de dialog Page Style (opţiunea Style din meniul ataşat butonului dreapta al mouse-
ului, dacă pagina este în modul de editare) pentru a seta propietăţile referitoare la
modul de prezentare a paginii (de exemplu, tipul de bordură, textul care se va afişa
ca titlu, dacă pagina conţine butoanele de minimizare/maximizare etc) (figura 6.9).
139
Figura 6.8. Fereastra de dialog Popup Menu Attributes
Figura 6.9 Fereastra de dialog Page Style

Dacă se selectează opţiunea Size din meniul ataşat butonului dreapta al mouse-
ului, se deschide fereastra de dialog Page Size and Position prin care se setează
140
poziţia paginii pe ecran, dimensiunea paginii şi starea iniţială de afişare a paginii

(normală, minimizată sau maximizată).
6.5 Componentele lui Object Inspector

Pentru a afişa şi modifica propietăţile, evenimentele şi metodele asociate unui
obiect se utilizează Object Inspector. Se selectează icoana Object Inspector din
bara de instrumente a ferestrei principale sau opţiunea Window/Object Inspector
din meniul principal sau opţiunea Inspect din meniul ataşat butonului dreapta al
mouse-ului, dacă obiectul este selectat. Fereastra Object Inspector (figura 6.10)
afişează :
propietăţile implicite ale obiectului selectat. Pentru fiecare propietate se
indică dacă se poate modifica sau nu (R-read only), dacă este ascunsă (H-
hidden) şi dacă valoarea ei este moştenită de la obiectul părinte (O-
overriden). Pentru fiecare propietate se specifică valoarea curentă.
evenimentele implicite asociate cu obiectul selectat. Se pot adăuga şi alte
evenimente. Pentru fiecare eveniment se specifică dacă are ataşat cod (scris
în limbajul Express sau QuickActions) şi când se declanşează.
metodele implicite asociate obiectului selectat.
elementele componente ale obiectului selectat. De exemplu, dacă obiectul
selectat este o pagină, se afişează conţinutul paginii (butoane, tabele,
grafice etc).
Figura 6.10 Object Inspector
141
Fereastra Object Inspector conţine şi o bara de instrumente ce permite definirea

de noi propietăţi, evenimente şi metode. Pentru a crea o nouă propietate se parcurg
următorii paşi (figura 6.11):
se selectează obiectul pentru care se doreşte definirea unei noi propietăţi;
se selectează opţiunea Inspect din meniul ataşat butonului dreapta al
mouse-ului şi se deschide fereastra Object Inspector;
se selectează icoana Add Item din bara de icoane şi se afişează fereastra de
dialog Add property;
se specifică: numele propietăţii, descrierea ei, tipul de data (de exemplu
număr întreg sau dată calendaristică), valoarea implicită a propietăţii, dacă
este o propietate sau set de propietăţi (caseta de validare Property Set),
numele setului de propietăţi la care se adaugă propietatea (Add to set), care
caractere sunt valori valide pentru propietate (Characters to allow),
atributele propietăţii (Property Attributes), caseta de dialog care se va
utiliza pentru a seta valorile propietăţii (Custom Inspector, Font Dialog
etc).
Aceste propietăţi definite de utilizator pot fi modificate (icoana Modify din bara
de icoane a lui Object Inspector) sau şterse (icoana Delete).
Figura 6.11 Fereastra Add Property
142
6.6 Crearea obiectelor unui proiect

Se pot crea următoarele tipuri de obiecte:
Briefing-ul este o colecţie de pagini ce conţin în general tabele sau grafice,
organizate într-un mod accesibil utilizatorilor;
Pagina este un container pentru alte obiecte (butoane, casete de validare,
tabelă, grafic etc);
Tabelul (sau graficul) este utilizat pentru a afişa şi analiza datele
multidimensionale;
Obiectul de tip ieşire (Express output) permite utilizatorilor să execute
comenzi din limbajul Express, în timpul execuţiei aplicaţiei;
Obiectul OLE (OLE object) permite inserarea de informaţii din alte
aplicaţii într-o pagină;
Obiectul de tip banner-ul se utilizează pentru a afişa static sau dinamic un
text . Obiectele de tip banner afişează o singură linie de text şi se utilizează
pentru a crea efecte speciale în asociaţie cu obiectele de tip timer.
Butonul de comandă este utilizat pentru a executa o acţiune sau o comandă
predefinită;
Caseta de validare (check box);
Lista (de tip combo box din care se poate selecta un element sau în care se
poate insera un element sau de tip List box ce permite numai selectarea a
unuia sau a mai multor elemente);
Lista valorilor unei dimensiuni (Dimension list box) permite afişarea
valorilor unei dimensiuni;
Lista de directoare (Directory list box) afişează directoarele de la o
anumită locaţie;
Listă de locaţii (Drive combo box) afişează locaţiile accesibile
utilizatorilor;
Lista de fişiere (File list box) afişează fişierele de la o anumită locaţie;
Obiectul de tip reţea (Grid object) conţine un număr specificat de linii şi
coloane şi este utilizat pentru a afişa text sau imagini într-un format
tabular;
Obiectul de tip grup (Group box) este utilizat pentru a grupa alte obiecte
cum ar fi casete de validare sau butoane de opţiune;
Obiectul de tip Hotspot creează o zonă invizibilă pe pagină de la care se
pot executa unele acţiuni ca răspuns la un eveniment;
Eticheta (Label) este utilizată pentru a afişa una sau mai multe linii de text
ce nu se pot modifica, iar obiectul de tip text (text box) afişează una sau
mai multe linii de text ce pot fi editate de utilizator;
Buton de opţiune (option button);
Bara de defilare (scroll bar);
Obiectul de tip Tabcontrol (Tabcontrol) este un container ce grupează mai
multe obiecte. Fiecare Tab poate conţine numai o tabelă, un grafic sau o
pagină;
143
Obiectul de tip arbore (Tree view) afişează o ierarhie de elemente (noduri);

Meniul orizontal sau vertical cu opţiunile corespunzătoare (command
item);
Bara de instrumente (toolbar) se poate ataşa unui briefing sau unei pagini;
Bara de stare (Status bar) se utilizează pentru a afişa unele informaţii ( de
exemplu ora curentă, starea tastei CAPS etc);
Secţiunea din bara de stare (Status bar panel) se utilizează pentru a afişa
text sau informaţii despre modul de derulare a unei operaţii;
Obiectul de dialog Color (Color Dialog) este un obiect invizibil la
momentul execuţiei aplicaţiei şi este utilizat pentru a afişa fereastra de
dialog Color;
Obiectul de dialog File (File Dialog) este un obiect invizibil la momentul
execuţiei aplicaţiei şi este utilizat pentru a afişa fereastra de dialog Open
sau Save As;
Obiectul de dialog Font (Font Dialog) este un obiect invizibil la momentul
execuţiei aplicaţiei şi este utilizat pentru a afişa fereastra de dialog Font;
Obiectul de dialog Printer este utilizat pentru a afişa fereastra de dialog
Printer Setup;
Obiectul de tip Timer este un obiect invizibil la momentul execuţiei
aplicaţiei şi este utilizat pentru a se executa la intervale regulate de timp
diferite acţiuni (cod Express);
Obiectul de tip modul reprezintă o unitate de compilare în limbajul
Express;
Obiectul de tip QuickAction permite specificarea unei acţiuni (de exemplu
exportul unei pagini de date dintr-o tabelă în Microsoft Excel, afişarea unui
document Word etc) pentru un anumit eveniment (specific unui anumit
obiect). De exemplu, la apăsarea unui buton să se lanseze în execuţie o altă
aplicaţie (Microsoft Excel).
În figura 6.12 se afişează un obiect de tip banner, o etichetă, un obiect de tip

listă de directoare, un obiect de tip listă de fişiere, un obiect de tip listă de locaţii,
un obiect de tip combo box şi un obiect de tip list box.
144
Figura 6.12 Crearea unor obiecte
Pentru a crea un obiect se selectează icoana corespunzătoare obiectului din

caseta de instrumente (Toolbox) şi apoi click cu mouse-ul pe pagină sau se trage cu
mouse-ul (drag and drop) pe pagină.
De exemplu, se deschide proiectul pjexemplu2. Se creează o pagină cu
propietăţile (Name: pgprincipala, Text: Pagina principală). Apoi se creează un
grup de obiecte (Groupbox1) cu propietăţile (Name: grpRaport, Text: Alegeţi tipul
de raport). Grupul de obiecte conţine două butoane radio şi anume: Optionbuton1
(Name: optStandard, Text: Raportare standard) şi OptionButon2 (Name:
optExceptie, Text: Raportare de excepţie). De asemenea, se creează un grup de
obiecte (Groupbox2) (Name: grpmasuri, Text: Selectaţi măsurile ) ce conţine o listă
(Name: lstmasuri, Default list: nrproiect |valoare_dolari|valoare_lei, Sorted: No,
ColumnPos: 20, ColumnScaleUnits: 1-Avg. char) şi patru butoane: buton 1 (Name:
btnvizualizare, Text: Vizualizare), buton 2 (Name: btnComentariu, Text:
Comentarii), buton 3 (Name: btnHelp, Text: Help) şi buton 4 (Name: btnIesire,
Text: Ieşire) (figura 6.13).
145
Figura 6.13 Crearea unui grup de butoane şi a unei liste
Caseta de dialog Default list afişează lista implicită de elemente ce se afişează

(caseta List), indexul pentru fiecare element din listă (caseta List Index). Indexul
primului element din listă este 0.
În figura 6.14 este creat un obiect de tip TabControl. Propietatea TabCaption
specifică textul pentru fiecare Tab.
Pentru a crea un obiect se poate utiliza şi opţiunea Derive din meniul ataşat
butonului dreapta al mouse-ului. Obiectul de la care se moştenesc propietăţile,
metodele şi evenimentele se numeşte părinte, iar obiectul care moşteneşte copil. De
exemplu, dacă părintele are asociată o acţiune cu evenimentul AfterClick, atunci şi
copilul va moşteni automat aceeaşi acţiune cu evenimentul AfterClick asociat lui.
Se poate modifica în mod explicit o propietate, un eveniment sau o metodă a
obiectului copil (propietatea, metoda sau evenimentul corespunzător părintelui nu
se va modifica). Pentru a crea un obiect copil, ce moşteneşte caracteristicile
obiectului părinte, se selectează opţiunea Derive din meniul ataşat butonului
dreapta al mouse-ului (obiectul părinte este selectat) sau se selectează obiectul
părinte în Object Browser sau Briefing Browser şi se “trage” (drag) la poziţia
dorită. Apare un meniu vertical din care se selectează opţiunea Derive
(figura 6.15).
146
Figura 6.14 Crearea unui obiect de tip TabControl
Figura 6.15 Crearea unui obiect cu opţiunea Derive
În figura 6.16 se creează o pagină cu propietăţile (Name: pgVizualizare, Text:

Vizualizare date), un tabel (Name: tabvizualizare), un grafic (Name: grvizualizare)
şi un buton (Name: btninapoi, Text: Inapoi).
147
Figura 6.16 Crearea unui tabel, a unui grafic şi a unui buton
6.7 Utilizarea colecţiei de rutine QuickActions
Se poate utiliza colecţia de rutine predefinite QuickActions (scrise în Visual

C++) pentru a executa anumite operaţii. De exemplu se creează un buton. Se
doreşte ca la apăsarea acestui buton să se lanseze în execuţie o altă aplicaţie cum ar
fi Notepad. Se selectează butonul, apoi se selectează opţiunea Set QuickAction din
meniu ataşat butonului dreapta al mouse-ului. Apare o listă de evenimente asociate
cu obiectul selectat. Se selectează evenimentul AfterClick şi se afişează fereastra de
dialog QuickAction Definition (figura 6.17) în care se specifică: numele obiectului
QuickAction care se creează, descrierea lui, acţiunea care se asociază acestui obiect
şi o serie de argumente necesare pentru a se executa acţiunea. În caseta Actions se
specifică acţiunile care se pot asocia şi anume:
User defined şi se specifică codul Express care se va executa;
Goto page permite deplasarea la pagina specificată;
Launch Application lansează în execuţie o aplicaţie;
Print tipăreşte un proiect, un briefing sau o pagină;
Run lansează în execuţie un proiect, un briefing sau o pagină;
Show Help afişează helpul sistemului;
Show Message afişează caseta de mesaje;
148
Stop termină execuţia unui proiect, a unui briefing sau a unei pagini;
Create View creează o viziune temporară (tabel sau grafic) pe baza uneia
existente;
Define Custom Measure afişează fereastra de dialog Custom Measures,
care permite utilizatorului să vizualizeze, editeze, copieze sau să creeze
măsuri;
Execute Express Command execută una sau mai multe comenzi Express;
Export Table permite exportul paginii curente (de exemplu în Microsoft
Excel);
Execute Action List permite execuţia unei liste de acţiuni de tip
QuickAction etc.
Figura 6.17 Fereastră QuickAction Definition
În caseta Command Line se tastează numele aplicaţiei care se lansează, iar în

caseta Display State se alege: 1-Normal (dacă fereastra se va deschide la
dimensiunea normală), 2-Minimized (dacă fereastra va fi minimizată iniţial) etc.
Pentru a exporta pagina curentă de date dintr-un tabel (de exemplu în
Microsoft Excel) se utilizează Export Table. Se specifică numele tabelului care se
va exporta (de exemplu linktable), numele fişierului în care se va exporta tabelul
(de exemplu d:\oracle\olap\oeo632\work\export.xls), comanda care va lansa în
execuţie aplicaţia (de exemplu C:\Program Files\Microsoft Office\Office\
EXCEL.EXE), formatul în care se exporta (Microsoft Excel XLS Format, Tab
Delimited values şi Comma separated values) (figura 6.18).
149
Figura 6.18 Exportul unui tabel
6.8 Limbajul de programare Express

Fiecare obiect are ataşată o listă de evenimente pe care le recunoaşte şi
răspunde la ele. La declanşarea unui eveniment se execută o acţiune care poate fi o
procedură scrisă în limbajul Express, o metodă a obiectului sau o rutină din colecţia
de rutine QuickActions. Metodele pot fi apelate de proceduri. Există proceduri care
se execută la apariţia unui eveniment şi proceduri locale valabile numai în modulul
de cod în care se găsesc.
Modulul este unitatea de compilare în Express. Există trei tipuri de module:
Modulul de cod (code module) este creat automat de Oracle Express
Objects când un obiect este creat. Modulul de cod este identificat prin
numele obiectului. Acest modul poate conţine proceduri ce se execută la
apariţia unui eveniment, metode, metode definite de utilizator şi proceduri
locale valabile numai în interiorul modulului de cod. Modulul de cod este
încapsulat în obiect. Fiecare obiect conţine un singur modul de cod. În
modulul de cod se pot identifica uşor procedurile ce se execută la apariţia
unui eveniment sau metodele, deoarece au un indicator “read-only” ca
prim caracter la începutul şi la sfârşitul lor. Pentru a şterge dintr-un modul
de cod, o metodă sau o procedură ce se execută la apariţia unui eveniment,
mai întâi se selectează opţiunea Detach Code şi apoi se şterge codul.
150
Această opţiune şterge indicatorii de “read-only” de la începutul şi sfârşitul

procedurii.
Modulul bibliotecă (library module) este creat prin selectarea icoanei
corespunzătoare din caseta de instrumente (Toolbox). Apoi dublu click pe
modulul de tip bibliotecă creat şi se afişează editorul Express Basic
corespunzător. Modulele bibliotecă sunt stocate la nivel de proiect şi conţin
proceduri ce sunt accesibile la nivelul unei aplicaţii. Toate procedurile
create într-o bibliotecă sunt tratate ca metode. De exemplu, pentru a referi
procedura p1 din bibliotecă librarie1 se utilizează notaţia librarie1.p1. Se
pot crea un număr nelimitat de module de tip bibliotecă într-o aplicaţie ce
conţine mai multe proiecte.
Modulul global (global module) se creează automat atunci când se
selectează opţiunea File/New/Global module din meniul lui Express Basic
Editor. În fiecare proiect poate fi un singur modul global. Un modul global
nu trebuie să includă proceduri, ci numai declaraţii de variabile globale,
constante sau tipuri de date definite de utilizator.
Se poate utiliza editorul Express Basic pentru a scrie, compila şi depana
modulele de cod Express. Acest editor poate fi accesat în mai multe moduri şi
anume: prin selectarea opţiunii Window/Express Basic Editor din meniul principal
sau prin selectarea opţiunii Edit Express Basic din meniul ataşat butonului dreapta
al mouse-ului (obiectul pentru care se scrie cod este selectat). Express Basic Editor
are următoarele componente şi anume (figura 6.19):
Meniul cu opţiunile File, View, Edit, Debug, Window şi Help;
Bara de icoane ce permite un acces mai rapid la facilităţile editorului;
Zonă ce conţine fereastra în care se introduce codul, fereastra în care se
afişează mesajele de eroare ale ultimei compilări, fereastra ce afişează
variabilele globale declarate pentru fiecare proiect deschis, fereastra ce
afişează tipurile de date şi valorile pentru variabilele modului curent
(activă numai la depanarea modulului) etc;
Bara de stare ce afişează o serie de informaţii despre activitatea curentă
(dacă modulul este compilat fără erori).
Pentru a compila codul se utilizează opţiunea File/Compile sau se selectează
icoana Compile din bara de butoane.
Pentru a insera o funcţie Express în modulul de cod se utilizează opţiunea
Edit/Insert Function.
Se poate compila un singur modul sau se pot compila toate modulele dintr-un
proiect sau toate modulele din toate proiectele deschise. Dacă se lansează în
execuţie un obiect (pagina, briefing sau proiect), Express Basic Editor va compila
automat toate modulele de cod ataşate, dacă ele au fost modificate. Pentru a
compila toate modulele, se selectează opţiunea File/Build All. Se afişează fereastra
de dialog Build All şi se selectează modulele care se vor compila (opţiunea Current
Project sau All projects).
151
Figura 6.19 Express Basic Editor
Se utilizează caracterul (!) pentru a indica obiectul de tip container şi caracterul

(.) pentru a indica metoda, propietatea sau evenimentul (Nume_obiect.nume_
propietate sau Nume_obiect.nume_metoda). De exemplu,
Exercitii!pagina1!buton1.text se referă la propietatea Text a butonului buton1 din
pagina pagina1 din proiectul exercitii (a se vedea bara de titlu a lui Object
Inspector).
Se pot insera comentarii pe orice linie de cod utilizând (‘) sau comanda Rem.
De asemenea, se poate continua o comandă pe mai multe linii utilizând SpaceBar şi
underscore. Pentru concatenare de şiruri se utilizează (&). Pentru a afişa mesaje
într-o casetă de mesaje se utilizează comanda:
Msgbox prompt, [butoane] [, titlu] unde
prompt specifică textul care se va afişa;
[butoane] specifică o sumă de trei valori ce indică butoanele, icoanele şi
butonul implicit din caseta de dialog. Dacă lipseşte acest argument, caseta
afişează numai butonul OK.
titlu specifică titlul casetei .
De exemplu: Msgbox “Doriţi să părăsiţi aplicaţia?”, 4+32+256, “Iesire”
În tabelul 6.1 se afişează valorile ce se pot utiliza şi semnificaţia lor.
152
Tabelul 6.1
Valorile ce se pot utiliza pentru butoane
Valoarea Semnificaţie
0 Afişează butonul OK
1 Afişează butoanele OK şi CANCEL
2 Afişează butoanele Abort, Retry, Ignore
3 Afişează butoanele Yes, No şi Cancel
4 Afişează butoanele Yes şi No
5 Afişează butoanele Retry şi Cancel
16 Afişează icoana de mesaj critic (STOP)
32 Afişează icoana de întrebare de atenţionare (?)
48 Afişează icoana de mesaj de atenţionare (!)
64 Afişează icoana de mesaj informativ (i)
0 Selectează primul buton ca implicit
256 Selectează al doilea buton ca implicit
512 Selectează al treilea buton ca implicit
Se pot utiliza şi o serie de constante (de exemplu qaMBIconInfoExpressBasic,

qaMBOK) pentru a selecta butoanele şi icoanele ce se vor afişa în caseta de mesaje.
De exemplu, se deschide pagina pgprincipala din proiectul pjexercitiu2. Se creează
o procedură, ce se declanşează la evenimentul AfterClick al butonului
btncomentarii (Text: Comentarii) şi va afişa într-o casetă de mesaje (cu un buton
OK) următorul mesaj: “Pagina curentă este: pgprincipala.” Se vor utiliza
constantele qaMBIconInfoExpressBasic şi qaMBOK (figura 6.20).
În figura 6.21 se prezintă lansarea în execuţie a paginii pgprincipala. Se
modifică procedura astfel încât dacă caseta de mesaje este afişată, propietatea Text
a butonului btncomentarii se modifică din “Comentarii” în “Afişare mesaj” şi dacă
caseta se închide, revine la valoarea iniţială. De asemenea, mesajul ce apare în
caseta de mesaje va fi (figura 6.22):
„Pagina curentă este: Application!Projects!pjexercitiu2!pgprincipala”
În figura 6.23 se afişează pagina pgprincipala lansată în execuţie.
6.8.1 Declararea variabilelor
O variabilă poate fi declarată: la nivel de procedură şi este valabilă numai în

aceea procedură, la nivel de modul (declarată într-un modul şi valabilă pentru toate
procedurile din acel modul) şi global (declarată într-un modul global şi valabilă
pentru toate modulele şi procedurile proiectului). Pentru a defini o variabilă, se
utilizează comanda:
Dim nume_variabila [AS tip_data]
Pentru a iniţializa o variabilă se utilizează comanda:
[Let] nume_variabila = expresie
153
De exemplu: Dim messagetext as string

Messagetext=”Selectaţi butonul OK”
Figura 6.20 Utilizarea constantelor qaMBIconInfoExpressBasic, qaMBOK
Figura 6.21 Lansarea în execuţie a paginii Pgprincipala
154
Figura 6.22 Codul pentru modificarea propietăţii Text a butonului btncomentarii
Figura 6.23 Lansarea în execuţie a paginii Pgprincipala
155
În limbajul Express se pot declara următoarele tipuri de date: integer, long,

single, double, currency, date, string, object, record şi variant. Se declară o
variabilă de tip variant, atunci când tipul variabilei nu este cunoscut la începutul
procedurii. De exemplu, se poate defini o variabilă de tip variant care va stoca
informaţia introdusă de utilizator, care poate fi de tip şir de caractere sau numeric.
Următoarele exemple sunt identice şi creează un buton btniesire.
Dim nume_obiect as [New] tip_obiect
[Set] nume_variabila=expresie
Dim btniesire as New Button

Sau
Dim btniesire as object
Set btniesire=New Button
Variabila Me este creată de sistem, valoarea ei este setată de sistem, stochează

o referire la obiectul curent şi se utilizează pentru a rezolva referirile la obiecte
necalificate. Exemplele de mai jos sunt identice:
Btniesire.text=”Iesire”
Me.text=”Iesire” (Variabila Me stochează referirea la obiectul btniesire)
Text=”Iesire” (propietatea Text este asociată automat obiectului a cărui referire
este stocată în variabila Me)
6.8.2 Structuri de program
Structura alternativă simplă:

IF conditie Then
Secventa_comenzi –
[elseif expresie then
secventa_comenzi] _
[Else
secventa_comenzi] _
end if
De exemplu, se creează o procedură ataşată evenimentului DoRun pentru
proiectul pjexercitii2. Se declară o variabilă la nivel de procedură ce va stoca ora
curentă a sistemului. Se iniţializează această variabilă cu valoarea returnată de
funcţia Hour(). Se utilizează o structură alternativă IF…END IF pentru a afişa într-
o casetă de mesaje următoarele mesaje (figura 6.24):
“Buna dimineata, este ora….”
“Buna ziua, este ora ….”
“Buna seara , este ora…”.
Structura alternativă cu mai multe ramuri execută o serie de comenzi în
funcţie de valoarea expresiei:
SELECT CASE expresie
156
[CASE lista_expresii
[secventa_comenzi]]
[CASE lista_expresii
[secventa_comenzi]]
[CASE else
[secventa_comenzi]]
END SELECT
De exemplu, se creează un buton în pagina pagina_quickaction cu următoarele
propietăţi: Name: btntrimestru, Text şi Description: Afişează trimestru. Se asociază
evenimentului AfterClick o procedură ce utilizează funcţia Month() pentru a stoca
luna curentă într-o variabilă. Se utilizează structura SELECT CASE pentru a evalua
valoarea variabilei şi a afişa într-o casetă de mesaje următorul mesaj: “Trimestru
…. Luna…” (figura 6.25). În figura 6.26 se prezintă pagina pagina_quickaction
lansată în execuţie.
Figura 6.24 Utilizarea structurii alternative simple
Structura repetitivă condiţionată anterior, cu numărător:

FOR contor=valoare_iniţiala TO valoare_finală [STEP increment]
[secventa_comenzi]
[EXIT FOR]
[secventa_comenzi]
NEXT [contor]
157
Figura 6.25 Utilizarea structurii SELECT CASE
Figura 6.26 Lansarea în execuţie a paginii Pagina_quickaction
De exemplu, se creează un buton btnFOR în pagina pagina_quickaction, iar la

evenimentul AfterClick se asociază o procedură care afişează numerele de la 1 la 5
într-o casetă de mesaje (figura 6.27).
158
Structura repetitivă condiţionată anterior:

WHILE conditie secventa_comenzi WEND
Secvenţa de comenzi este executată atâta timp cât condiţia este adevărată. Condiţia
trebuie să fie iniţial adevărată.
Structura repetitivă condiţionată anterior/posterior execută o serie de
comenzi atâta timp cât condiţia este adevărată:
DO [{WHILE|UNTIL} conditie]
[secventa_comenzi]
[EXIT DO]
[secventa_comenzi]
LOOP
sau :
DO
[secventa_comenzi]
[EXIT DO]
[secventa_comenzi]
LOOP [{WHILE|UNTIL} conditie]
Figura 6.27 Utilizarea structurii FOR…NEXT
159
Comanda GOTO eticheta transferă controlul programului la eticheta

specificată. Comanda EXIT {DO|FOR|function|Sub} determină o ieşire forţată din
structura repetitivă (DO… LOOP sau FOR….NEXT) sau transferă controlul la
procedura apelantă.
Apelul de metode sau proceduri ce se execută la apariţia unui eveniment se
face cu comanda:
CALL nume_metoda(lista_argumente) sau
Nume_metoda lista_argumente sau
Nume_variabila = nume_metoda (lista_argumente)
De exemplu call move(240, 720, 1575, 375) sau Move 240, 720, 1575, 375
Metoda Count () este utilizată pentru a returna numărul de membrii ai unui
obiect de tip container. În exemplul următor, variabila nr_membri stochează
numărul de obiecte dintr-o pagină:
Dim nr_membri as integer
Nr_membri = pagina_quickaction.count()
Metoda Item(nume sau index) este utilizată pentru a referi un membru al unui
obiect de tip container prin nume sau index. În exemplul următor, numele primului
membru al unei pagini este stocat într-o variabilă:
Dim variabila as string
Variabila = pagina_quickaction.item(0).name
Metoda Run() este utilizată pentru a lansa în execuţie un obiect. Un proiect
trebuie să fie deschis înainte de a fi apelată metoda Run() corespunzătoare. În
exemplu următor, se creează un buton btnexecuta în pagina pagina_quickaction a
proiectului pjexercitii2. La evenimentul AfterClick al butonului, se ataşează o
procedură care permite lansarea în execuţie a altui proiect:
Dim pjproiect as new project
If pjproiect.open() then
Call pjproiect.run()
Else
Msgbox “Proiectul nu este deschis”
End if
Metoda Stop() este utilizată pentru a opri execuţia unui proiect, briefing sau
pagină. În exemplul următor, se lansează în execuţie pagina pagina_quickaction şi
se opreşte execuţia paginii pgvizualizare. În acest fel, se permite navigarea între
două pagini ale unui proiect:
Call pagina_quickaction.run()
Call pgvizualizare.stop()
De exemplu, se creează un buton (Name: btn_membrii, Description: Membrii
paginii) în pagina pagina_quickaction. Se ataşează la evenimentul AfterClick al
butonului o procedură care afişează într-o casetă de mesaje, numărul de membrii ai
paginii curente şi ultimul membru (figura 6.28). În figura 6.29 se prezintă pagina
pagina_quickaction lansată în execuţie.
160
Figura 6.28 Utilizarea metodei count()
Figura 6.29 Lansarea în execuţie a paginii
161
Se poate utiliza direct limbajul Express cu ajutorul următoarele obiecte:

Obiectul Express (Express object) gestionează conexiunea clientului Express
la serverul Express. Se poate utiliza obiectul Express pentru pornirea şi oprirea
instanţei Express, pentru a verifica starea conexiunii, pentru a executa comenzi din
limbajul Express etc. De exemplu, se utilizează metoda Connect ([Prompt]) pentru
a stabili o conexiune la serverul Express. Se poate utiliza metoda Disconnect
([UpdateAllDBs], [,QueryOnDBDetach]) pentru a încheie o conexiune.
Argumentul UpdateAllDBs specifică dacă se actualizează toate bazele de date când
se face deconectarea, iar argumentul QueryOnDBDetach specifică dacă utilizatorul
este întrebat la deconectare, dacă se va face sau nu actualizarea bazelor de date. De
exemplu:
Call express.connect()
Call express.disconnect()
Propietatea Connected a obiectului Express specifică dacă clientul Express este
conectat sau nu la serverul Express, iar propietatea ServerDescription conţine o
descriere textuală a conexiunii Express. De exemplu, la evenimentul AfterClick al
unui buton btnopen se ataşează un cod care deschide şi lansează în execuţie un
proiect. Codul verifică de asemenea, dacă este stabilită conexiunea cu serverul
Express .
Dim pjexemplu as newproject
If express.connected=true then
Msgbox „Sunteţi conectat la Express” &express.serverdescription
Else
Call express.connect(Yes)
End if
If pjexemplu.open() then
Call pjexemplu.run()
else
Msgbox „Nu s-a selectat nici un proiect”
End if
Obiectul de tip comandă Express (express command object) permite
executarea comenzilor din limbajul Express şi accesarea rezultatelor. Pentru a
accesa baza de date, obiectul de tip comandă Express este asociat cu obiectul
Express. Atunci când este apelată metoda Execute() a obiectului Express, se
creează un obiect de tip comandă Express care se poate utiliza pentru a accesa
rezultatele execuţiei comenzilor. Se utilizează metoda Execute ([command(s)]) a
obiectului de tip comandă Express pentru a executa comenzile specificate ca
argumente. De exemplu, la evenimentul AfterClick al butonului btnexecuta se
ataşează următorul cod:
Dim comenzi as expresscommand
Set comenzi=express.execute („baza de date demo.db” & ‚;”& _
„limit time to first 6” & „;” & _
„limit product to first 1”)
162
Argumentul command al metodei Execute (command [, pusherroronstack])

specifică comenzile care se vor executa, iar dacă argumentul pusherroronstack este
setat pe No, nu se mai afişează mesajele de erori.
Obiectul de tip ieşire Express (express output object) oferă o interfaţă vizuală
în care se introduc comenzi Express la momentul execuţiei aplicaţiei OLAP şi se
afişează rezultatele. Obiectul de tip ieşire Express are următoarele componente: o
zonă unde se introduc comenzi Express (script), o zonă unde se afişează rezultatele
comenzilor (output), un buton Execute prin care se execută comenzile şi un buton
Clear prin care se şterg rezultatele afişate (figura 6.30).
Figura 6.30 Exemplu de utilizare a obiectului de tip ieşire Express
Propietatea Commands a obiectului de tip ieşire Express stochează o listă de

comenzi ce sunt executate de obiect. Propietatea AutoexecuteOnRun specifică dacă
toate comenzile sunt executate automat, atunci când obiectul se lansează în
execuţie. Propietatea HideButtonsOnRun specifică dacă butoanele Execute şi Clear
sunt afişate la momentul execuţiei. Propietatea ShowErrors specifică dacă se
afişează mesaje de eroare în zona de afişare a rezultatelor (output) (figura 6.31).
Setul de propietăţi CommandArgs specifică argumentele pentru comenzile
Express. Se tastează valorile argumentelor (Arg0...Argn), iar în comenzi se
utilizează aceste valori folosind semnul de substituţie (%). De exemplu : %0 se
referă la Arg0 (figura 6.32).
163
Figura 6.31 Propietăţile obiectului de tip ieşire Express
Figura 6.32 Utilizarea propietăţii ArgX
164
Figura 6.33 Propietatea Commands
Metoda Execute() a obiectului de tip ieşire Express se utilizează pentru a

executa toate comenzile din propietatea Commands (figura 6.33). Această
propietate stochează toate comenzile tastate în zona de execuţie a comenzilor şi
este echivalentă cu a selecta butonul Execute. Metoda ClearOutput () este
echivalentă cu a selecta butonul Clear. De exemplu:
Call expressoutput1.execute()
Call expressoutput1.clearoutput()
6.9 Utilitarul Database Browser
Utilitarul Database Browser afişează dimensiunile şi măsurile (variabile,

formule şi relaţii) ale bazei de date multidimensionale la care se conectează
Express Objects. Conectarea la o bază de date se face:
prin selectarea opţiunii Database/Attach (figura 6.34);
prin deschiderea sau lansarea în execuţie a unui proiect care cere o bază de
date ataşată. Această ultimă metodă ataşează automat baza de date.
165
Figura 6.34 Caseta de dialog pentru ataşarea la o bază de date multidimensională
Pentru a afişa utilitarul Database Browser se selectează opţiunea

Window/Database Browser/Pane sau Floating. În Oracle Express Objects, unui
fişier al bazei de date i se asociază un obiect de tip DatabaseFile. Acest obiect este
adăugat la obiectul de tip DatabaseList atunci când o bază de date
multidimensională este ataşată şi proiectul este salvat. Obiectele de tip
DatabaseFile sunt stocate în obiectul de tip DatabaseList (figura 6.35).
Utilitarul Database Browser afişează numele bazei de date multidimensionale
ataşată, dimensiunile şi măsurile corespunzătoare.
Pentru a popula cu date un tabel sau grafic se selectează măsura sau măsurile şi
se “trag” din Database Browser în pagină.
Se pot crea noi măsuri în Oracle Express Objects. Aceste măsuri sunt definite
ca formule ce conţin variabile deja stocate în baza de date. Pentru a crea o măsură
se selectează opţiunea Database/Custom Measures sau opţiunea Custom din
instrumentul Selector. Fereastra de dialog Custom Measures are următoarele
componente: caseta Database în care se afişează numele bazei de date curente,
caseta Custom Measures în care se afişează toate variabilele definite, caseta
Expression ce afişează formula de calcul a variabilei, caseta Dimensions afişează
dimensiunile măsurii selectate. Pentru a crea o nouă variabilă se selectează butonul
New. Se deschide fereastra Custom Measures New în care se specifică numele şi
descrierea variabilei, formula de calcul etc (figura 6.36).
166
Figura 6.35 Utilitarul Database Browser
Dicţionarul de date (DataDictionary) este o colecţie de obiecte, cod şi

structuri de date ce oferă acces la obiectele bazei de date multidimensionale. El este
gestionat de obiectul DataDictionary creat automat atunci când Express Objects se
conectează prima dată la serverul Express. Obiectul DataDictionary gestionează
obiectele de tip DatabaseFile şi este utilizat în următoarele proceduri: ataşarea
bazelor de date, afişarea utilitarului Database Browser, afişarea ferestrei de dialog
Edit Custom Measures, accesarea obiectelor bazei de date. Pentru a vizualiza
propietăţile obiectului DataDictionary, se selectează acest obiect în fereastra
Object Inheritance (se selecteaza icoana View Inheritance din Object Browser).
Apoi se selectează opţiunea Inspect din meniul ataşat butonului dreapta al mouse-
ului (figura 6.37).
Obiectul DataDictionary are metode pentru ataşarea unei baze de date
multidimensionale. În exemplu următor, se utilizează metoda AttachDatabase()
pentru a ataşa baza de date DEMO, respectiv metoda DetachDatabase():
Call DataDictionary.AttachDatabase (“DEMO”)
Call Datadictionary.DetachDatabase (“DEMO”)
167
Figura 6.36 Fereastra de dialog Custom Measures
Se utilizează metoda BrowseDatabases() pentru a afişa utilitarul Database

Browser şi metoda EditCustomMeasures() pentru a afişa fereastra de dialog Edit
Custom Measures. În exemplu următor, se afişează utilitarul Database Browser
fără bara de butoane şi fereastra de dialog Edit Custom Measures:
Call DataDictionary.BrowseDatabases (ddBRWNoToolbar)
Call DataDictionary.EditCustomMeasures()
De exemplu, se creează o nouă pagină (Name: pagina_attach, Description:
Ataşare la baza de date DEMO) în proiectul pjexercitii2. Apoi se creează trei
butoane: buton 1 (Name: btnAttach, Text: Ataşare la DEMO, Enabled :No), buton
2 (Name: btndeattach, Text: deataşarea bazei DEMO; Enabled: Yes), buton 3
(Name: btnmasuri, Text : Creare noi măsuri, Enabled: Yes). La evenimentul
AfterClick al butonului btnattach se asociază o procedură care permite ataşarea la
baza de date DEMO (figura 6.38). De asemenea, se creează o procedură şi pentru
evenimentul AfterClick al butonului btndeattach (figura 6.40) prin care se activează
butonul btnattach, se dezactivează celelalte două butoane şi se utilizează metoda
DetachDatabase() a obiectului DatabaseDictionary. La evenimentul AfterClick al
butonului btnmasuri se asociază o procedură care utilizează metoda
EditCustomMeasures() pentru a afişa fereastra de dialog Custom Measures
(figura 6.39).
168
Figura 6.37 Propietăţile obiectului DataDictionary
Figura 6.38 Utilizarea metodei AttachDatabase()
169
Figura 6.39 Utilizarea metodei EditCustomMeasures()
Figura 6.40 Utilizarea metodei DetachDatabase()
170
6.10 Crearea şi utilizarea tabelelor şi a graficelor

Oracle Express Objects utilizează un mod optim de reprezentare a structurilor
numerice cu mai mult de două dimensiuni pe un ecran bidimensional, pentru
vizualizare şi manipulare. De exemplu, un set de date tridimensional este afişat pe
ecran, pe rânduri, coloane şi pagini. Cum se pot reprezenta patru sau mai multe
dimensiuni logice în trei dimensiuni fizice (rând, coloană, pagină)? Răspunsul este
de a combina multiple dimensiuni logice în aceeaşi dimensiune fizică.
Oracle Express Objects creează automat un cub de date n-dimensional
(datacube) şi obiectele lui asociate ori de câte ori se populează cu date un tabel sau
un grafic. Cubul de date n-dimensional defineşte conţinutul şi structura datelor
afişate într-un tabel sau într-un grafic. Fiecare tabel sau grafic are un cub de date n-
dimensional asociat.
Propietatea DataCube a tabelului sau a graficului se referă la obiectul cub de
date n-dimensional asociat. Pentru a vizualiza propietăţile, metodele şi
evenimentele asociate acestui obiect se face dublu click pe obiect, în fereastra
Object Inspector (figura 6.41).
Cubul de date are trei muchii (dimensiuni fizice): coloana (column edge),
rândul (row edge) şi pagina (page edge). Structura multidimensională a cubului de
date este afişată în bara de dimensiuni a instrumentului Selector. Icoanele din bara
de dimensiuni arată ce dimensiuni logice (noduri ale dimensiunilor fizice- edge
node) sunt afişate pe coloană, rând sau pagină. Pentru fiecare dimensiune logică
afişată în tabel sau grafic, există creat un obiect de tip edge node (figura 6.42).
Figura 6.41 Vizualizarea propietăţilor obiectului DataCube
171
În figura 6.42, pe pagină se afişează districtele (pe fiecare pagină un alt

district), pe linii produsele, iar pe coloane variabila Sales (Vânzări) şi lunile. Deci
pagina conţine o singură dimensiune logică (nod), rândul o singură dimensiunea
logică, iar coloana două dimensiuni logice ale cubului de date n-dimensional.
Pentru a vizualiza propietăţile unui nod (de exemplu edgenode1) se face dublu
click cu mouse-ul pe valoarea propietăţii Datacube. Se selectează, din fereastra
Object Inspector corespunzătoare, opţiunea Contents, apoi dublu click pe valoarea
unui nod ( de exemplu edgenode1) şi se selectează opţiunea Properties. Propietatea
Dimension a unui nod specifică numele dimensiunii logice asociate cu acel nod. De
exemplu, valoarea propietăţii Dimension pentru nodul edgenode1 este
XP_MEASUREDIM (figura 6.43).
Figura 6.42 Afişarea structurii cubului de date multidimensional
Obiectul cub de date (DataCube) are o serie de metode pentru adăugarea de

măsuri, schimbarea poziţiei dimensiunilor fizice ale cubului n-dimensional,
reordonarea nodurilor într-o dimensiune fizică, mutarea unui nod de la o
dimensiune fizică la alta şi afişarea informaţiilor despre un nod. Metoda
AddMeasures (listă_măsuri)) se utilizează pentru a adăuga una sau mai multe
măsuri la obiectul DataCube. Această metodă este echivalentă cu operaţia de
“tragere” (drag) a unei măsuri din fereastra utilitarului Database Browser şi
poziţionarea ei pe pagină. În exemplul următor, se adaugă măsura Sales la obiectul
Datacube asociat cu tabelul table1:
Call table1.datacube.addmeasures(“Sales”)
172
În exemplul următor, se creează un nou obiect Datacube, se adaugă măsura

Sales la acest obiect şi se setează propietatea Datacube a tabelului table1 la noul
obiect Datacube:
Dim dc as new datacube
Call dc.addmeasures (“Sales”)
Set table1.datacube=dc
Figura 6.43 Afişarea propietăţilor unui nod
Metoda Rotate(optiune_rotire, de la dimensiunea/nod, la dimensiunea/nod) se

utilizează pentru a muta sau schimba nodurile într-un grafic sau tabel. În exemplul
următor, se mută nodul asociat cu dimensiunea Timp, după nodul asociat cu
dimensiunea Produs din tabelul table1. Apoi se mută dimensiunea Timp pe pagină:
Call table1.datacube.rotate (dcROAfter, “TIMP”, “PRODUS”)
Call table1.datacube.rotate (dcROTOPage, “TIMP”)
Metoda RotateEdges() schimbă între ele dimensiunile fizice ale cubului de
date. În exemplul următor, se schimbă între ele coloana cu rândul, apoi pagina cu
rândul:
Call table1.rotateedges (dcEColumn, dcERow)
Call table1.rotateedges (dcEPage, dcERow)
173
În exemplu următor, se schimbă nodul asociat cu dimensiunea Produs cu nodul

asociat cu dimensiunea Timp din tabelul table1:
Call table1.datacube.rotate (dcROSwap, “PRODUS”, “TIMP”)
Metoda GetEdgeNode() întoarce numele nodului sau a dimensiunii fizice. În
exemplu următor, se afişează numele nodului corespunzător dimensiunii Timp:
Dim timenode as edgenode
Set timenode=table1.datacube.getedgenode (“TIMP”)
Msgbox “Dimensiunea TIMP este ‘ + timenode.name
De exemplu, se creează o pagină (Name: pagina_metodecubdate, Text: Metode
ale cubului de date). Se creează un grafic graph4. La evenimentul AfterClick al
graficului se ataşează un cod care creează un nou obiect Datacube, apelează
metoda AddMeasures() pentru a adăuga măsura Sales la noul cub de date, setează
propietatea Datacube a graficului la noul obiect creat (figura 6.44). Apoi se creează
două butoane în pagina pagina_metodecubdate şi anume: buton 1 (Name: btnmuta,
Description şi Text: Mută măsura la pagină) şi buton 2 (Name: btnschimba,
Description şi Text: Schimbă coloana cu pagina). Se ataşează la evenimentul
AfterClick al butonului btnmuta un cod care mută dimensiunea Măsuri pe pagină
(figura 6.45), iar la evenimentul AfterClick al butonului btnschimba un cod care
schimbă coloana cu pagina (figura 6.46). În figura 6.47 se afişează pagina
pagina_metodecubdate lansată în execuţie.
Figura 6.44 Utilizarea metodei AddMeasures()
174
Figura 6.45 Utilizarea metodei Rotate()
Figura 6.46 Utilizarea metodei Rotateedges()
175
Figura 6.47 Lansarea în execuţie a paginii Pagina_metodecubdate
6.10.1 Crearea tabelelor şi a graficelor
Tabelele şi graficele sunt utilizate pentru a vizualiza datele multidimensionale

stocate în baza de date multidimensională. Există mai multe moduri de a crea o
tabel sau un grafic şi anume:
se selectează icoana corespunzătoare din caseta de instrumente (toolbox) şi
apoi click cu mouse-ul în pagină. Se va crea un tabel (sau grafic) fără date;
din fereastra utilitarului Database Browser se selectează o măsură şi se
“trage” în pagină. Se creează un tabel (sau grafic) populat cu valorile
măsurii selectate.
se utilizează opţiunea Derive sau Duplicate pentru a deriva sau copia un
nou tabel (sau grafic) plecând de la un tabel (sau grafic) deja existent.
se utilizează limbajul Express.
Componentele unui tabel nu pot fi derivate, duplicate sau şterse şi sunt: titlu
tabelului, subtitlul, pagina (se afişează valorile dimensiunii logice asociată paginii),
rândul (se afişează valorile dimensiunii logice asociată rândului), valorile măsurii
selectate (databody), informaţii suplimentare despre tabel (footnote), coloana (se
afişează valorile dimensiunii logice asociată coloanei). Unele componente sunt
invizibile în mod implicit (de exemplu titlul, subtitlu etc). Componentele tabelului
176
nu se pot şterge, nu se poate adăuga o nouă propietate, eveniment sau metodă la o

componentă a tabelului.
Graficele au diferite componente în funcţie de tipul graficului şi anume: axele
graficului (X/Y1/Y2-axis), linia ce marchează intervale de valori de a lungul axelor
(Tick mark), eticheta (Label), legenda graficului (Legend), subtitlu, zona unde se
afişează datele (Plot area) etc. Unele componente ale graficului sunt invizibile în
mod implicit (de exemplu subtitlu). Componentele graficului nu pot fi mutate, nu
se pot adăuga noi propietăţi, metode sau evenimente la o componentă a graficului.
Se poate modifica modul de afişare a tabelei sau a graficului prin setarea unor
propietăţi. De exemplu, setul de propietăţi SpecialEffects creează efecte speciale în
grafic, propietatea GraphType specifică tipul de grafic etc.
Propietatea DisplayPage specifică pagina logică de date ce va fi afişată în tabel
sau grafic, la un moment dat. De exemplu, dacă pagina are asociată dimensiunea
Timp care are trei valori: 2000, 2001, 2002, atunci vom avea trei pagini logice. De
asemenea, se poate utiliza metoda GoToDataPage() pentru deplasarea de la o
pagină logică la altă pagină logică. Această metodă are ca argument următoarele
constante (tabelul 6.2):
Tabelul 6.2
Constantele utilizate de metoda GoToDataPage()
Constanta Valoare Rezultat
VwPGFirst -1 Afişează prima pagină
VwPGLast -2 Afişează ultima pagină
VwPGNext -3 Afişează următoarea pagină
VwPGPrevious -4 Afişează pagina anterioară
În exemplul următor, se realizează mutarea la ultima pagină logică din tabelul

table1:
Call table1.gotodatapage (vwpglast) sau
Call table1.gotodatapage (-2)
De exemplu, se creează o pagină (Name: pagina_mutare, Description şi Text:
Mutarea de la o pagină la alta). Apoi se creează un tabel table1 care afişează
valorile măsurii Sales. Se creează un grup de butoane radio (Name: grpmutare,
Text: Selectaţi pagina dorită) format din patru butoane: buton 1 (Name: optprima,
Text: Prima pagină), buton 2 (Name: optanterioara , Text: Pagina anterioară),
buton 3 (Name: opturmatoarea, Text: Următoarea pagină) şi buton 4 (Name:
optultima, Text: Ultima pagină). La evenimentul BeforeRun al paginii se asociază
un cod care activează butonul optprima şi le dezactivează pe celelalte (figura 6.48).
La evenimentul AfterClick al grupului de butoane se asociază un cod care permite
deplasarea de la o pagină la alta. Dacă este afişată prima pagină logică şi se
selectează butonul “Prima pagină” sau butonul “Pagina anterioară”, se va afişa
într-o casetă de mesaje mesajul :”Eşti pe prima pagină”. Dacă este afişată ultima
pagină şi se selectează butonul “Ultima pagină” sau “Următoarea pagină” se va
afişa mesajul “Eşti pe ultima pagină” (figura 6.49). În figura 6.50 se prezintă
pagina pagina_mutare lansată în execuţie.
177
Figura 6.48 Asocierea unui cod la evenimentul BeforeRun al paginii
Figura 6.49 Codul pentru deplasarea de la o pagină logică la alta pagină logică
178
Figura 6.50 Lansarea în execuţie a paginii Pagina_mutare
Propietatea GraphType a unui grafic specifică tipul de grafic şi se poate utiliza

pentru a schimba programat tipul de grafic. În exemplul următor, se specifică un
grafic de tip bară , un grafic de tip plăcintă şi un grafic de tip linie:
Graph1.graphtype = grGTBarClust
Graph1.graphtype = grGTPie
Graph1.graphtype = grGTLineAbs
Pentru a îmbunătăţi aspectul graficului, se utilizează setul de propietăţi
SpecialEffects şi anume: SFXApplyType specifică tipul de efect (Wash sau Image),
SFXIImageFileName specifică numele fişierului ce conţine imaginea, propietăţile
SFXWashDirection, SFXWashStartColor, SFXWashstopcolor şi SFXWashType
specifică modul în care va fi colorat fundalul graficului, stabilindu-se culoarea de
început, culoarea de sfârşit etc.
De exemplu, se creează o pagină (Name: pagina_grafice, Description şi Text :
Pagina cu tipuri de grafice). Se creează un grafic (Name: graph1) ce va afişa
valorile măsurii Sales. Se creează apoi un grup de butoane de opţiune (Name:
grpgrafic, Text: Se selectează tipul de grafic). Se adaugă trei butoane de opţiune şi
anume: buton 1 (Name: optbar, Text: Bar), buton 2 (Name: optlinie, Text: Linie),
buton 3 (Name: optplacinta, Text: Pie). Dacă se selectează unul din butoane se
modifică tipul de grafic. Se modifică de asemenea, setul de propietăţi
SpecialEffects şi anume: SFXApplyType: Wash, SFXWashDirection: Down Right,
SFXWashType: Start-Stop, SFXWashStartColor: galben deschis,
SFXWashStopColor: verde. Se afişează şi titlul graficului “Volumul vânzărilor”
(figura 6.51). În figura 6.52 se prezintă pagina pagina_grafice lansată în execuţie.
179
Figura 6.51 Setarea tipului de grafic
Figura 6.52 Lansarea în execuţie a paginii Pagina_grafice
180
Pentru a sincroniza un grafic cu un tabel, astfel ca orice modificare în tabel să

se reflecte automat şi în grafic, se setează propietatea SyncDataPage pe Yes (atât
pentru tabel cât şi pentru grafic). De exemplu, se creează o pagină (Name:
pagina_sincronizare, Text: Sincronizarea unui tabel cu un grafic). Se creează apoi
un buton (Name:btnsincronizare, Text: Sincronizare tabel cu grafic). La
evenimentul AfterClick al butonului se ataşează un cod ce va permite sincronizarea
tabelului cu graficul (cele două obiecte partajează acelaşi cub de date). În acest
scop, se creează un obiect cub de date. Se apelează metoda AddMeasures () pentru
a adăuga măsura Sales la cubul de date. Se setează propietatea DataCube a
tabelului, precum şi a graficului la noul cub de date creat (figura 6.53). Pagina
lansată în execuţie este prezentată în figura 6.54.
Figura 6.53 Sincronizarea unui tabel cu un grafic
6.11 Crearea listelor ce conţin valori ale dimensiunilor
Obiectul Dimension List este o listă ce afişează valorile unei dimensiuni din
care utilizatorul poate selecta una sau mai multe valori. Pentru a crea o listă de
valori se selectează icoana DimListBox din caseta de instrumente (Toolbox) şi click
cu mouse-ul în pagină. Se va crea o listă care va fi mai târziu populată cu date. Sau
se selectează o dimensiune din fereastra utilitarului Database Browser şi se “trage”
în pagină. Această metodă creează o listă ce afişează valorile dimensiunii selectate.
Pentru a popula o listă cu valorile unei dimensiuni, se selectează opţiunea
Dimension din meniu ataşat butonului dreapta al mouse-ului sau se selectează
opţiunea Inspect. Se deschide fereastra Object Inspector. Apoi dublu click pe
181
propietatea Dimension. De asemenea, se poate utiliza şi metoda

SetDefaultSelection():
Call dimlb1.setdefaultselection (nume_dimensiune) sau
Dimlb1.dimension = “nume_dimensiune”
Se utilizează propietatea Availablevalues pentru a specifica valorile ce vor fi
afişate în listă şi anume: 0-All (afişează toate valorile dimensiunii. Este valoare
implicită pentru toate dimensiunile ce nu au ierarhii), 1-hierarchy (afişează toate
valorile din ierarhia curentă a dimensiunii ), 2-Selection (afişează toate valorile din
selecţia curentă. Este valoarea implicită, după ce se utilizează instrumentul Selector
pentru a schimba selecţia), 3-None.
Figura 6.54 Lansarea în execuţie a paginii Pagina_sincronizare
Propietatea ListBoxType stabileşte tipul de listă asociată unei dimensiuni şi

anume: 0-single highlight (o singură valoare este selectată la un moment dat) sau 1-
extended highlight (permite selecţie multiplă). Pentru a schimba valorile afişate în
listă se selectează opţiunea Select data din meniul ataşat butonului dreapta al
mouse-ului.
De exemplu, se creează o pagină (Name: pagina_dimensionlist, Text: Pagina
ce conţine o listă cu valorile unei dimensiuni). Se creează un tabel (Name:table2)
ce afişează valorile măsurii Sales. Se creează o listă ce va afişa valorile dimensiunii
Product (baze de date DEMO). Apoi se creează două butoane: buton 1 (Name:
btnsinc, Text: Sincronizare) şi buton 2 (Name: btnrefresh, Text:Refresh). La
evenimentul AfterClick al butonului btnsinc se asociază un cod care sincronizează
lista cu tabelul (valorile ce se afişează în tabel se vor afişa selectate în listă)
(figura 6.55). La evenimentul AfterClick al butonului btnrefresh se asociază un cod
182
care va sincroniza lista cu tabelul (ce se selectează din listă se va afişa în tabel). De
exemplu, dacă din listă se selectează produsul Tents, în tabel se vor afişa numai
vânzările acestui produs (figura 6.56). În figura 6.57 se afişează pagina
pagina_dimensionlist lansată în execuţie.
Figura 6.55 Codul ataşat evenimentului AfterClick al butonului “Sincronizare”
Figura 6.56 Codul ataşat evenimentului AfterClick al butonului “Refresh”
183
Figura 6.57 Lansarea in execuţie a paginii Pagina_dimensionlist
Figura 6.58 Propietatea Highlight Selection
184
Dacă se selectează propietatea HighlightSelection (dublu click) a listei Dimlb1

se afişează valorile dimensiunii selectate. În figura 6.58 se observă că propietatea
HighLightSelection se referă la obiectul Selection9. Dublu click pe această valoare
şi se afişează propietăţile obiectului Selection9 (inclusiv valorile dimensiunii care
sunt selectate la un moment dat ) (figura 6.59). Metoda RefreshSelection() poate
modifica propietăţile DataSelection şi HighlightSelection ale listei.
De exemplu: Call dimlb1.refreshSelection (dlbselhighlight) actualizează tabelul
table2 cu valorile curent selectate din lista Dimlb1.
Figura 6.59 Propietăţile obiectului Selection9
6.12 Instrumentul Selector

Instrumentul Selector (figura 6.60) permite dezvoltatorilor de aplicaţii OLAP şi
utilizatorilor să selecteze valorile unei dimensiuni ce vor fi afişate într-un tabel
(grafic sau listă de valori). Propietatea Selector a unui tabel (grafic sau listă de
valori) specifică tipul de Selector utilizat. Când se creează un tabel sau un graphic,
propietatea Selector are valoare “No value”. Prima dată când instrumentul Selector
este apelat, Express Objects creează un obiect Selector de tip Main selector şi-l
ataşează la propietatea Selector a tabelului sau graficului. Se poate modifica tipul
de selector prin utilizarea opţiunii Options din fereastra instrumentului Selector sau
185
din Object Inspector. În fereastra de dialog Selector Options se poate modifica

tipul de instrument Selector (figura 6.61).
Propietatea SelectorType a obiectului Selector creat determină ce selector va fi
afişat şi anume: Main Selector (selectorul implicit creat automat de sistem), Single
Tool Selector (unul din instrumentele incluse în Selector) şi miniselector (o listă de
valori cu butoane de comandă ataşate) (tabelul 6.3).
Tabelul 6.3
Valorile propietaţii SelectorType
Constanta Valoare Descriere
SlcTYPMain 1 Selectorul principal
slcTYPMini 2 Caseta de dialog pentru dimensiuni (Dimension
dialog box)
slcTYPAll 4 Instrumentul All
slcTYPAttribute 8 Instrumentul Attribute
slcTYPException 16 Instrumentul Exception
slcTYPFamily 32 Instrumentul Family
slcTYPLevel 64 Instrumentul Level
slcTYPMatch 128 Instrumentul Match
slcTYPRange 512 Instrumentul Range
slcTYPsavedSel 1024 Instrumentul Saved selection
SlcTYPSort 2048 Instrumentul Sort
slcTYPTopBottom 4096 Instrumentul Top/Bottom
slcTYPCustomMeasure 16384 Instrumentul Custom Measure
slcTYPList 32768 Instrumentul List
Propietatea ShowOptions dacă este setată pe Yes, permite utilizatorilor să

acceseze fereastra de dialog Selector Options (figura 6.62).
Propietatea AvailableTools specifică ce instrumente se vor afişa (se specifică
suma valorilor constantelor din tabelul 6.3).
Miniselectorul conţine o listă de valori şi trei butoane Ok, Cancel şi Help.
Titlul listei afişează numele dimensiunii asociate. Pentru a crea un miniselector se
setează propietatea SelectorType a obiectului Selector pe valoarea 2 (figura 6.62).
Setul de propietăţi SelectorMini conţine:
propietatea Explanatory Text ce permite dezvoltatorului de aplicaţie să
controleze promptul ce apare în miniselector. Acest prompt specifică
utilizatorului cum se utilizează miniselectorul. De exemplu “Selectaţi
valorile pentru Timp” (figura 6.63);
propietatea ListBoxType specifică tipul de selecţie din listă şi anume: 0-
Single Highlight (se selectează un singur element), 1-extended highlight (se
selectează multiple elemente utilizând Shift+Click sau CTRL+Click), 2-
manual sort (elementele se selectează prin “drag and drop”), 4-view only
(nici un element nu poate fi selectat), 3-dropdown (se selectează numai un
element din lista de tip “combo”). În figura 6.63 se afişează un
miniselector.
186
Orice instrument din Selector se poate afişa individual dacă se setează

propietatea SelectorType cu una din valorile specificate în tabelul 6.3. De exemplu,
Selector Type=32768 afişează numai instrumentul List (figura 6.64).
Figura 6.60 Instrumentul Selector
Figura 6.61 Fereastra de dialog Selector Options
187
Figura 6.62. Setarea propietăţilor AvailableTools şi ShowOptions
Figura 6.63 Exemplu de miniselector
188
Figura 6.64 Instrumentul List
Propietatea EnableSelectData afişează sau ascunde Selectorul ataşat unui tabel

sau grafic (nu se afişează icoana Selector din bara de dimensiuni). Se poate utiliza
propietatea EnableSelectData şi pentru a determina dacă utilizatorii pot modifica
selecţia pentru un anumit nod. De exemplu, dacă propietatea EnabledSelectData
este setată pe No, pentru un nod şi pe Yes, pentru un tabel (sau grafic), utilizatorii
pot afişa Selectorul, dar dimensiunile ataşate nodului respectiv nu apar în lista de
dimensiuni din Selector. De exemplu se modifică obiectul Selector pentru tabelul
table2 din pagina pagina_dimensionlist, astfel încât dimensiunea ce conţine
măsurile să nu se mai afişeze în lista cu dimensiuni din Selector. Se utilizează
Object Inspector pentru a determina care nod corespunde dimensiunii ce conţine
măsurile (XP_MEASUREDIM). Se selectează opţiunea Inspect din meniul ataşat
butonului dreapta al mouse-ului şi se deschide fereastra Object Inspector pentru
tabelul table2. Apoi dublu click pe valoarea propietăţii Datacube şi se afişează
propietăţile obiectului cub de date asociat. Se selectează opţiunea Contents, dublu
click pe fiecare dimensiune fizică a cubului (de exemplu edge4), apoi pe fiecare
nod (de exemplu edgenode7). Apoi se setează propietatea EnableSelectData a
nodului corespunzător dimensiunii XP_MEASUREDIM pe No. Dimensiunea ce
conţine măsurile nu se mai afişează în lista de dimensiuni din Selector
(figura 6.65).
Pentru a ataşa unui grafic selectorul utilizat de un tabel, se utilizează comanda:
set graph1.selector= table1.selector
189
Figura 6.65 Setarea propietăţii EnableSelectData
6.13 Crearea meniurilor

Se pot crea meniuri orizontale sau verticale. Se selectează opţiunea Menu din
caseta de instrumente (toolbox) şi click cu mouse-ul pe pagină. Apoi se creează
opţiunile meniului selectând icoana CommandItem din caseta de instrumente.
Pentru a modifica propietăţile unei opţiuni, se utilizează Object Inspector sau
fereastra de dialog Command ItemProperties. Această fereastră este accesată prin
dublu click pe propietatea Accelerator a opţiunii respective. Fereastra Command
ItemProperties (figura 6.66) permite dezvoltatorilor un acces mai rapid la un subset
de propietăţi. Unele propietăţi sunt valabile numai dacă se creează o bară de
butoane (de exemplu propietatea Popup Tip). În această fereastră (figura 6.66) se
specifică: numele opţiunii (Name), textul asociat, stilul opţiunii, textul ce se va
afişa în bara de stare atunci când utilizatorul selectează această opţiune, textul ce se
va afişa atunci când utilizatorul trece cu mouse-ul peste opţiunea din bara de icoane
(Popup Tip), dacă opţiunea este activă (enabled) şi vizibilă (visible), starea opţiunii
(state), combinaţia de chei ataşată opţiunii (accel.Key), identificatorul opţiunii (id)
etc.
Pentru a crea o bară de butoane (toolbar) se selectează icoana Toolbar din
caseta de instrumente şi click cu mouse-ul pe pagină. Bara de butoane poate fi
afişată vertical sau orizontal. Există mai multe moduri de a crea un buton în bara de
butoane. De exemplu: se selectează icoana CommandItem din caseta de
190
instrumente, sau dublu click pe bara de butoane nou creată, apoi se “trage” (drag
and drop) o imagine din instrumentul Toolbar Galery în bara de butoane nou
creată. Instrumentul Toolbar Galery (figura 6.67) conţine o colecţie de imagini
predefinite ce pot fi utilizate pentru a crea butoane în bara de butoane. Aceste
imagini sunt grupate în şase categorii. De exemplu, categoria Stock conţine imagini
pentru funcţiile standard cum ar fi print şi paste, categoria Graph conţine imagini
reprezentând diferite tipuri de grafice etc.
Figura 6.66 Fereastra Command Item Properties
Figura 6.67 Instrumentul Toolbar Galery
191
6.14 Adăugarea obiectelor definite de utilizator în caseta

de instrumente
Un obiect definit de utilizator poate fi adăugat în caseta de instrumente

(toolbox) prin “tragere” (drag and drop). Icoana ataşată obiectului poate fi
modificată prin setarea propietăţilor ToolbarSmallPicture şi ToolbarLargePicture.
Caseta de instrumente va afişa obiectele definite de utilizator, numai dacă
proiectele care le conţine sunt deschise (figura 6.68). Pentru a şterge un obiect creat
de utilizator din caseta de instrumente, se selectează opţiunea Edit/Install din
meniul principal. Se afişează fereastra de dialog Install. Se selectează caseta User
Defined şi se deselectează numele obiectului din lista de obiecte, apoi se apasă tasta
OK .
Figura 6.68 Includerea unui obiect definit de utilizator (pagina_template)

în caseta de instrumente
6.15 Utilizarea obiectelor de dialog

Obiectele de dialog (dialog objects) sunt obiecte invizibile la momentul
execuţiei proiectului sau briefing-ului. Ele sunt utilizate pentru a afişa următoarele
ferestre de dialog: Open, Save As, Color, Font şi Print.
192
Pentru a crea un obiect de dialog se selectează icoana corespunzătoare din

caseta de instrumente şi click cu mouse-ul pe pagină. Obiectul de dialog este afişat
ca o icoană pe pagină. Pentru a vizualiza fereastra de dialog asociată cu obiectul de
dialog se alege opţiunea Show din meniul ataşat butonului dreapta al mouse-ului
(cu excepţia ferestrei de dialog Print). Pentru a afişa o fereastră de dialog la
momentul execuţiei proiectului se utilizează metoda Show() (în cazul ferestrelor de
dialog File, Color şi Font) sau Showdialog() (pentru fereastra de dialog Print).
Metoda Show() întoarce valoarea Yes dacă utilizatorul a selectat butonul OK. În
exemplu următor, se utilizează metoda Show() pentru a afişa fereastra de dialog
File şi metoda ShowDialog() pentru a afişa fereastra de dialog Print:
Call filedialog1.show()
Call printer1.showdialog
În figura 6.69 se afişează fereastra de dialog File, se evaluează dacă utilizatorul
a ales butonul OK şi se deschide proiectul selectat de utilizator. Apoi se lansează în
execuţie proiectul. Metoda Openproject () deschide proiectul selectat, îl face activ,
elimină orice căsuţă de dialog sau mesaje (argumentul pjsilent). Variabila fişier
păstrează calea pentru proiectul selectat. Metoda Run() este folosită pentru a lansa
în execuţie proiectul.
Figura 6.69 Utilizarea metodei Show()
193
Obiectul de dialog File este utilizat pentru a permite unui utilizator să deschidă
un fişier (propietatea DialogType=0) sau să-l salveze cu alt nume (propietatea
DialogType=1). În exemplul următor obiectul de dialog permite utilizatorului să
salveze un fişier cu un alt nume:
Filedialog1.dialogtype=1
Call filedialog1.show()
Propietatea Filter specifică lista de filtre (condiţii) care se vor afişa în caseta
Files of Type din fereastra de dialog File. Un filtru specifică un tip de fişier. De
exemplu:
Project Files (*.xpj)|*.xpj|Text Files (*.txt)|*.txt|All Files (*.*)|*.*
Propietatea DefaultExt specifică extensia implicită a fişierelor. Propietatea
DialogTitle specifică numele ferestrei de dialog (implicit este Open sau Save As),
propietatea DialogType specifică tipul de fereastră (Open/Save As), propietatea
InitDir specifică directorul utilizat implicit. Setul de propietăţi File se referă la o
serie de propietăţi ale fişierelor selectate în fereastra de dialog File (de exemplu:
driverul implicit, directorul implicit, numele fişierului, extensia etc).
Obiectul de dialog Font afişează fereastra de dialog Font, în care utilizatorul
poate specifica numele fontului utilizat, stilul, dimensiunea, efectele utilizate,
culoarea etc. Obiectul de dialog Font are multe propietăţi şi anume: titlul ferestrei
(implicit Font), fontul (nume, stil, culoare) etc (figura 6.70).
Figura 6.70 Propietăţile obiectului de dialog Font
194
Obiectul de dialog Color se utilizează pentru a afişa fereastra de dialog Color

din care utilizatorul poate selecta culoarea dorită.
Obiectul de dialog Printer se utilizează pentru a afişa fereastra de dialog Print
Setup care permite utilizatorului să specifice setările pentru imprimantă. Obiectul
de dialog Printer are multe propietăţi cum ar fi: propietatea docname (indică
numele documentului care se va tipări), propietatea orientation (tipul de orientare:
portrait sau landscape), propietatea copies (numărul de copii) etc. De exemplu se
deschide pagina pagina_meniu. Se creează un obiect de dialog File (Name:
Filedialog2, Title: Open Proiect, Filter: Project Files (*.xpj)|*.xpj|All Files
(*.*)|*.* ) (figura 6.71). La evenimentul AfterItemClick a opţiunii cifisier (Text:
Fişier) se asociază un cod care permite afişarea ferestrei de dialog File (titlul
ferestrei va fi Open Fişier, iar în caseta Files of type se vor afişa numai Project
Files şi All Files). Utilizatorul va selecta un fişier (proiect) şi-l va deschide. Se va
utiliza metoda Run() pentru a lansa apoi în execuţie proiectul selectat (figura 6.72).
Figura 6.71 Selectarea opţiunii Fişier din meniu
În exemplul următor, se creează o pagină (Name: pagina_export, Text: Pagina

Export). Se ataşează un meniu (menu1) cu următoarele opţiuni cibar (Text:
Afişează bara de dimensiuni), ciselector (Text: Selectorul), ciexcel (Text: Export
Excel). Se selectează din Database Browser, măsura Sales şi se trage în pagină. Se
creează un tabel table1 ce afişează valorile acestei măsuri (se utilizează baza de
date DEMO). La evenimentul AfterItemClick al opţiunii cibar se ataşează un cod
195
ce permite afişarea sau ascunderea barei de dimensiuni corespunzătoare tabelului

(figura 6.73). La evenimentul AfterItemClick al opţiunii ciselector se ataşează un
cod ce permite afişarea selectorului pentru tabelul table1 (figura 6.74). La
evenimentul AfterItemClick al opţiunii ciexcel se ataşează rutina Export Table
QuickAction ce permite exportul paginii curente de date, din tabelul table1 într-o
foaie de calcul tabelar Excel (figura 6.75).
Figura 6.72 Codul ataşat evenimentului AfterItemClick al opţiunii cfisier
Figura 6.73 Codul ataşat evenimentului AfterItemClick al opţiunii cibar
196
Figura 6.74 Codul ataşat evenimentului AfterItemClick al opţiunii ciselector
Figura 6.75 Exportul unei pagini de date în Excel.
197
Rezumat
Oracle Express Objects este un instrument OLAP ce permite crearea de
aplicaţii OLAP, precum şi realizarea de programe în limbaj Express, prin care se
controlează comportamentul aplicaţiei.
Acest instrument este un element cheie în pachetul de instrumente pentru
inteligenţa afacerilor Oracle Integrated Business Intelligence Tools, fiind integrat
cu Oracle Discoverer. Aplicaţiile OLAP dezvoltate cu Oracle Express Objects
accesează datele stocate în baze de date multidimensionale sau baze de date
relaţionale.
Oracle Express Objects utilizează tabele şi grafice pentru a vizualiza datele
multidimensionale stocate în baza de date multidimensională.
Un proiect este unitatea de bază pentru stocarea obiectelor create cu Express
Objects. Este un container rădăcină ce include celelalte obiecte.
O aplicaţie OLAP poate fi formată din unul sau mai multe proiecte.
Utilitarul Object Browser permite deschiderea şi vizualizarea mai multor
proiecte sau briefing-uri, selectarea, mutarea, copierea, ştergerea, derivarea
obiectelor incluse în proiect (sau briefing), editarea şi modificarea paginilor,
vizualizarea propietăţile obiectelor etc.
În Oracle Express Objects se pot crea următoarele tipuri de obiecte: briefing-
uri, pagini, tabele, grafice, obiecte de tip ieşire, diferite tipuri de butoane, diferite
tipuri de liste, etichete, bare de defilare, obiecte de tip arbore, meniuri, obiecte de
dialog, obiecte de tip Timer etc.
Utilitarul Database Browser afişează dimensiunile şi măsurile bazei de date
multidimensionale, la care se conectează Express Objects.
Instrumentul Selector permite dezvoltatorilor de aplicaţii OLAP şi
utilizatorilor să selecteze valorile unei dimensiuni ce vor fi afişate într-un tabel
(grafic sau listă de valori).
Modulul este unitatea de compilare în limbajul Express şi există trei tipuri de
module: modulul de cod, modulul bibliotecă şi modulul global.
O variabilă poate fi declarată la nivel de procedură, la nivel de modul şi
global.
În limbajul Express se pot declara următoarele tipuri de date: integer, long,
single, double, currency, date, string, object, record şi variant.
În limbajul Express se pot defini structuri de program: structura alternativă
simplă (IF…END IF), structura alternativă cu mai multe ramuri (SELECT
CASE…END SELECT), structura repetitivă condiţionată anterior cu numărător
(FOR…NEXT), structura repetitivă (WHILE…WEND) etc.
198
Cuvinte cheie
Obiect, moştenire, metodă, eveniment, modul de cod, modul bibliotecă, modul
global, aplicaţie, proiect, briefing, pagină, variabilă globală, tabel, grafic, obiecte
de tip ieşire, etichete, bare de defilare, obiecte de tip arbore, meniuri, obiecte de
dialog, obiecte de tip timer etc.
199
Capitolul 7
Dezvoltarea sistemelor OLAP
cu Oracle Express Analyzer
Oracle Express Analyzer [OEAG99] este un instrument OLAP ce permite :
analiza datelor. Se pot crea tabele şi grafice ce afişează datele stocate în
baza de date multidimensională. Datele sunt selectate cu ajutorul
instrumentului Selector;
crearea de briefing-uri ce pot fi folosite de alţi utilizatori;
editarea şi modificarea briefing-urilor create cu Express Analyzer sau
Express Objects;
lansarea în execuţie a unui briefing;
lansarea în execuţie a aplicaţiilor create cu Express Objects.
Oracle Express Analyzer poate accesa datele stocate în baze de date
multidimensionale Express sau baze de date relaţionale.
La lansarea în execuţie a lui Express Analyzer, se afişează fereastra de dialog
Welcome to Oracle Express Analyzer (figura 7.1). Se poate selecta opţiunea: Run a
Briefing or Application pentru a lansa în execuţie un briefing sau o aplicaţie,
Create a new Briefing (crearea unui briefing), Change an existing Briefing pentru a
modifica un briefing existent, Analyzer Express Data pentru a afişa în fereastra
Database Browser o listă cu baze de date multidimensionale existente, pentru
conectare, Start where I left off last time pentru a redeschide briefing-ul utilizat
anterior şi a realiza conectarea automată la bazele de date deschise anterior.
Utilitarul Briefing Browser listează toate briefing-urile deschise şi se poate
vizualiza conţinutul fiecăruia (figura 7.2). Acest utilitar se utilizează şi pentru
modificarea unui briefing şi anume: se poate modifica ordinea paginilor în briefing,
se poate deschide o pagină şi poate fi modificată, se poate muta o pagină de la un
briefing la altul sau se poate face o copie etc.
Utilitarul Database Browser permite selectarea datelor din una sau mai multe
baze de date multidimensionale, pentru a fi afişate în tabele sau grafice, în paginile
unui briefing (figura 7.3).
Pentru baza de date la care se face conexiunea se afişează dimensiunile şi
măsurile. Pentru a determina dimensionalitatea unei variabile se selectează baza de
date din Database Browser. Apoi se selectează una sau mai multe dimensiuni (în
200
Dezvoltarea sistemelor OLAP cu Oracle Express Analyzer
ecranul din stânga al ferestrei utilitarului Database Browser). În ecranul din

dreapta, variabilele asociate cu aceste dimensiuni sunt colorate (figura 7.4).
Figura 7.1 Fereastra de dialog Welcome to Oracle Express Analyzer
Figura 7.2 Utilitarul Briefing Browser
201
Figura 7.3 Utilitarul Database Browser
Figura 7.4 Stabilirea dimensionalităţii variabilelor
202
Se pot obţine informaţii despre o bază de date multidimensională prin

selectarea ei în Database Browser şi apoi se selectează din submeniul Window
opţiunea Object Inspect. Se afişează fereastra de propietăţi Object Inspector
(figura 7.5).
Figura 7.5 Afişarea propietăţilor unui obiect cu Object Inspector
Când se creează un obiect, Express Analyzer stabileşte valori implicite pentru

propietăţile obiectului respectiv. Aceste valori pot fi modificate ulterior cu Object
Inspector. Toate obiectele au o serie de propietăţi standard şi anume:
propietatea Name specifică numele obiectului care apare în fereastra
utilitarului Briefing Browser (implicit object# unde object este tipul de
obiect creat şi # este un număr secvenţial). De exemplu, page3 reprezintă
pagina 3 dintr-un briefing;
propietatea LocalName specifică alt nume pentru obiect (în altă limbă
străină: germana, italiana etc);
propietatea Description afişează descrierea obiectului;
propietatea Parent specifică tipul de obiect (de exemplu: page, banner).
Propietatea este read-only.
propietatea Container specifică obiectul în care este inclus obiectul curent.
Această propietate este read-only. De exemplu, pentru o pagină, container-
ul este briefing-ul, pentru un tabel sau grafic container-ul este pagina etc.
203
De asemenea, există seturi de propietăţi (seturi de caracteristici grupate logic).

De exemplu, setul de propietăţi Line include propietăţi ce controlează
caracteristicile liniilor cum ar fi culoarea liniei, lăţimea, stilul etc.
Dacă se selectează opţiunea Contents, din fereastra utilitarului Object Inspector
se afişează conţinutul obiectului curent, numai dacă este de tip container. De
exemplu, o pagină poate conţine tabele, grafice etc.
7.1 Conectarea la baza de date multidimensională

Conectarea la o bază de date multidimensională se face prin selectarea opţiunii
Attach din submeniul Database. Se deschide fereastra de dialog Attach Database.
Se selectează baza de date şi se apasă apoi butonul OK (figura 7.6).
Figura 7.6 Conectarea la baza de date
7.2 Crearea, actualizarea şi salvarea unui briefing

Pentru a crea un nou briefing, se selectează din submeniul File opţiunea New
Briefing. Se deschide fereastra de dialog Briefing Name în care se tastează numele
şi descrierea briefing-ului (figura 7.7).
204
Pentru a şterge un briefing se utilizează instrumentul Windows File Manager

sau comanda DEL de la promptul de DOS (se şterge fişierul corespunzător cu
extensia .xbr).
Figura 7.7 Crearea unui briefing
Pentru a actualiza un briefing existent (care nu este deschis) se selectează din

submeniul File opţiunea Open Briefing sau dublu click pe butonul Open Briefing
din bara de instrumente a ferestrei principale. În fereastra utilitarului Briefing
Browser se selectează dublu click cu mouse-ul briefing-ul pe care dorim să-l
actualizăm.
Salvarea unui briefing se face selectând din submeniul File următoarele
opţiuni: Save, Save As sau Save All.
7.3 Crearea şi editarea paginilor

Pentru a crea o pagină se selectează icoana Page din bara de butoane ataşată
ferestrei utilitarului Briefing Browser. Se poate crea indirect o pagină, atunci când
se creează un tabel sau un grafic, un obiect OLE sau un obiect de tip ieşire Express.
Pentru a edita o pagină se selectează dublu click cu mouse-ul pagina dorită
(figura 7.8).
205
Paginile create nu se pot salva separat de briefing. Atunci când o pagină este
creată, ea este adaugată automat la briefing-ul curent. Dacă dorim ca paginile
create să nu fie adăugate la un briefing, se parcurg următorii paşi:
din submeniul Edit se alege opţiunea Options şi se afişează fereastra de
dialog Options;
se deselectează caseta de validare Add New pages to briefing (figura 7.9).
Totuşi, atunci când se doreşte închiderea paginii, Express Analyzer întreabă
utilizatorul dacă doreşte să adauge pagina la briefing-ul curent.
Figura 7.8 Crearea şi editarea unei pagini
7.4 Mutarea, duplicarea şi referirea paginilor

Pentru a muta, duplica sau referi o pagină se parcurg următorii paşi:
se selectează pagina din fereastra utilitarului Briefing Browser;
se „trage” (drag and drop) pagina în alt briefing. Express Analyzer întreabă
utilizatorul dacă doreşte duplicarea (duplicate), mutarea (move) sau
referirea (link) paginii. Duplicarea presupune crearea unei copii a paginii,
la noua locaţie. Mutarea presupune ştergerea paginii din briefing-ul curent
şi inserarea în noul briefing, iar referirea stabileşte o legătură (link) la o
pagină din briefing-ul original. Această ultimă opţiune simplifică viitoarele
206
modificări, deoarece actualizarea paginii (indiferent de briefing) cauzează

modificări ce sunt reflectate în ambele briefing-uri.
Figura 7.9 Fereastra de dialog Options

Unele propietăţi ale paginii pot afecta comportamentul obiectelor incluse în
pagină. De exemplu, propietatea Scale Units specifică unitatea de măsură (inch,
pixel) utilizată pentru pagină şi obiectele sale. Propietatea AutoSize specifică
comportamentul paginii şi al obiectelor sale, dacă dimensiunea paginii este
modificată. Dacă propietatea este setată pe Yes, o modificare a dimensiunii paginii
produce o modificare corespunzătoare a dimensiunilor obiectelor incluse. O pagină
dintr-un briefing poate conţine: tabele, grafice, obiecte de tip ieşire (Express output
object), obiecte OLE, obiecte de tip banner şi butoane.
7.5 Crearea obiectelor unui briefing
Pentru a adaugă un obiect la o pagină se parcurg următorii paşi:

se selectează icoana obiectului din caseta de instrumente (toolbox);
se face click cu mouse-ul pe suprafaţa paginii, în locul unde se doreşte
crearea obiectului (figura 7.10).
207
Figura 7.10 Crearea unui obiect
Pentru a crea un tabel sau un grafic ce conţine date se parcurg următorii paşi:
din fereastra utilitarului Database Browser se selectează baza de date şi
apoi măsurile dorite;
se „trag” cu mouse-ul (drag and drop) pe suprafaţa paginii şi apare un
meniu vertical cu două opţiuni: Table şi Graph. Se alege una din opţiuni şi
va apare în pagină fie un tabel populat cu date, fie un grafic (figura 7.11).
Se pot adăuga şi alte obiecte în pagină, dacă propietatea AutoSize a tabelului
sau graficului este setată pe No. Se selectează cu mouse-ul pagina unde este creat
tabelul şi se alege din meniul vertical ataşat butonului dreapta al mouse-ului,
opţiunea Inspect. Se deschide fereastra Object Inspector şi se setează propietatea
AutoSize.
Pentru a crea un obiect de tip ieşire (Express output object) se selectează
icoana obiectului din caseta de instrumente şi se „trage” cu mouse-ul în pagină. Se
poate utiliza acest tip de obiect pentru a afişa rezultatele comenzilor Express
executate de utilizatori (figura 7.12).
Express Analyzer permite includerea de informaţii preluate din alte aplicaţii
folosind obiecte OLE (Object Linking and Embedding). Express Analyzer permite
numai obiecte OLE incluse (embedding OLE objects). Odată adăugate în pagina
briefing-ului, ele devin elemente componente ale briefing-ului. Pentru a crea un
obiect OLE, se selectează icoana OLE din caseta de instrumente şi se „trage” cu
208
mouse-ul în pagină. Se alege obiectul OLE care va fi inserat (de exemplu un fişier
cu extensia (.bmp) sau un fişier Excel) (figura 7.13).
Figura 7.11 Crearea unui tabel sau a unui grafic
Figura 7.12 Crearea unui obiect de tip ieşire
209
Figura 7.13 Crearea unui obiect OLE
Se pot crea şi butoane utilizate pentru: a lansa în execuţie un alt briefing, a

schimba pagina curentă din briefing, a crea tabele sau grafice, a rearanja datele în
tabele sau grafice, a afişa mesaje sau a executa comenzi Express. Pentru a adăuga
un buton şi a-i ataşa o acţiune se parcurg următorii paşi:
se selectează icoana butonului din caseta de instrumente;
se „trage” cu mouse-ul în pagină şi se creează butonul;
se selectează apoi butonul şi se deschide meniul vertical ataşat butonului
dreapta al mouse-ului;
se alege opţiunea QuickAction şi se deschide fereastra de dialog
QuickAction;
se selectează acţiunea dorită care va fi ataşată butonului. De exemplu
pentru a schimba pagina curentă, se alege acţiunea GO TO şi se specifică
numărul paginii (figura 7.14).
Un obiect de tip banner este o casetă ce conţine o singură linie de caractere. Se
utilizează de exemplu ca titlul unei pagini. Pentru a crea un obiect de tip banner se
parcurg următorii paşi:
se selectează icoana corespunzătoare din caseta de instrumente;
se „trage” în pagină briefing-ului curent şi se creează obiectul de tip
banner;
se selectează obiectul de tip banner creat şi se deschide meniul vertical
ataşat butonului dreapta al mouse-ului;
210
se alege opţiunea Text şi se tastează şirul de caractere care va fi afişat

(figura 7.15).
Figura 7.14 Crearea unui buton şi ataşarea unei acţiuni
Figura 7.15 Crearea unui obiect de tip banner

Pentru a afişa mai multe linii de text, se poate crea un obiect OLE ce afişează
textul scris într-un editor cum ar fi Microsoft Word.
211
7.6 Lansarea în execuţie a unui briefing sau a unei pagini
Lansarea în execuţie a unui briefing, se poate face prin selectarea opţiunii Run
nume_briefing din submeniul File.
Pentru a lansa în execuţie o pagină, se selectează pagina şi apoi opţiunea Run
din meniul vertical asociat butonului dreapta al mouse-ului.
Ordinea în care apar paginile într-un briefing (în fereastra utilitarului Briefing
Browser), este ordinea în care vor fi afişate la lansarea în execuţie a briefing-ului.
Când se creează o nouă pagină, Express Analyzer o adaugă la sfârşitul briefing-ului
curent. Pentru a modifica ordinea de afişare a unei pagini, se selectează pagina în
fereastra utilitarului Briefing Browser şi se „trage” (drag and drop) cu mouse-ul la
noua locaţie .
În Express Analyzer se pot tipări paginile briefing-ului, tabelele sau graficele.
Când se tipăresc pagini, se poate selecta tipărirea paginii curente, a tuturor
paginilor sau numai a unui set de pagini.
7.7 Utilizarea tabelelor pentru analiza datelor
Tabelele se utilizează pentru :

a vizualiza toate datele stocate în baza de date multidimensională;
a executa analize ad-hoc prin interogarea bazei de date. Se selectează
datele dorite şi sunt vizualizate în tabel din diferite perspective (view-uri),
prin modificarea poziţiilor dimensiunilor cu ajutorul barei de dimensiuni
(Dimension Bar) ;
a modifica setul de date afişate cu ajutorul instrumentului Selector;
a executa analize de tip “What-if” etc.
Pentru a crea un tabel fără date se selectează icoana Table din caseta de
instrumente şi se „trage” cu mouse-ul pe suprafaţa paginii curente. Pentru a crea un
tabel populat cu date, se conectează la o bază de date. În fereastra utilitarului
Database Browser se selectează o măsură şi se trage cu mouse-ul pe suprafaţa
paginii curente. Apare un meniu vertical. Se selectează opţiunea Table şi se creează
automat un tabel populat cu valorile măsurii selectate (figura7.16). De asemenea,
se poate crea un tabel plecând de la un tabel existent, dacă se selectează opţiunea
Duplicate din meniul vertical asociat butonului drepta al mouse-ului (tabelul sursă
este selectat) sau de la un grafic, dacă se selectează opţiunea Table din meniul
vertical asociat butonului dreapta al mouse-ului (se selectează în prealabil fundalul
graficului). În acest ultim caz, se creează un tabel pe o nouă pagină.
Datele afişate în tabel pot fi prezentate sub diferite aspecte. Când se creează
un nou tabel, bara de dimensiuni apare implicit. Se poate modifica această setare.
În fereastra de dialog Options, se deselectează caseta de validare Show Dimension
Bar. În bara de dimensiuni sunt afişate trei icoane care reprezintă cele trei
212
dimensiuni fizice ale cubului de date şi anume pagina (page edge icon), rândul
(row edge icon) şi coloana (column edge icon). În pagină se afişează numele
dimensiunilor logice ale cubului de date, vizibile în pagina curentă a tabelului. De
exemplu, în figura 7.16, pagina conţine valorile dimensiunii Instituţii, rândul
conţine tipurile de proiecte, iar coloana conţine valorile variabilei număr proiecte şi
anii de analiză: 2000, 2001, 2002, 2003. Se pot modifică dimensiunile logice
incluse într-o dimensiune fizică, precum şi ordinea lor de afişare. De exemplu, în
figura 7.17 s-a mutat dimensiunea logică Timp (anii) pe rând. Nu se poate muta o
dimensiune logică de pe coloană pe rând, dacă există o singură dimensiune logică
inclusă în coloană.
Figura 7.16 Crearea unui tabel populat cu date
Formatul unui tabel este controlat de propietăţile sale, care pot fi modificate
folosind utilitarul Object Inspector. Un tabel are următoarele componente:
coloanele (column edge), rândurile (row edge), paginile (page edge), titlul,
subtitlul, zona de date (databody), nota de subsol (footnote). Aceste componente
sunt listate prin selectarea opţiunii Contents din fereastra Object Inspector şi au
propriile propietăţi.
213
Figura 7.17 Mutarea dimensiunii Anii
Dacă se setează propietatea AllowCellEditing (din setul de propietăţi

CellEditing) cu valoarea Yes, se pot modifica valorile din celulele de date. Totuşi
nu se pot edita celulele ce conţin valori calculate pe baza unor formule. Această
propietate permite executarea analizelor de tip “what-if” de către utilizatori. De
asemenea, în Express Analyzer se pot defini variabile (custom measures) care pot fi
folosite pentru analize de tip “what-if”. Utilizatorul poate modifica valorile acestor
variabile, fără ca aceste valori să fie stocate în baza de date (baza de date este read-
only). Pentru a crea aceste variabile se parcurg următorii paşi:
din submeniul Database se alege opţiunea Custom Measures;
în fereastra de dialog Custom Measures se specifică baza de date utilizată
şi se afişează variabilele deja definite de utilizatori (de exemplu baza de
date evaluare_final);
se alege opţiunea New pentru a crea o nouă variabilă, Copy pentru a crea o
copie a unei variabile deja existentă sau Edit pentru a modifica o variabilă
deja definită;
în caseta Expression se defineşte expresia pe baza căreia se creează nouă
variabilă. De exemplu, se defineşte variabila Total_personal cu expresia :
Total_personal=nrcadre+nrtesa (figura 7.18).
Când se creează o nouă variabilă, Express Analyzer adăugă numele acestei
variabile în fereastra Measures a utilitarului Database Browser (figura 7.19).
Definiţia variabilei este stocată în briefing-ul în care este definită variabila şi în
214
fişierul XANALYZE.XPJ. Fiecare utilizator a lui Express Analyzer are propriul

fişier XANALYZE.XPJ, în care sunt stocate variabilele proprii şi selecţiile de date
salvate.
Figura 7.18 Crearea unei variabile
7.8 Instrumentul Selector
Instrumentul Selector permite dezvoltatorilor de aplicaţii OLAP şi

utilizatorilor să selecteze valorile unei dimensiuni, care vor fi afişate într-un tabel
sau grafic. Acest instrument a fost prezentat în detaliu în capitolul 6. În Oracle
Express Analyzer se pot utiliza opţiunile selectorului şi anume:
All selectează (sau deselectează) toate valorile unei dimensiuni sau toate
valorile unei ierarhii;
List selectează (sau deselectează) acele valori ale unei dimensiuni care se
vor afişa;
Level selectează (sau deselectează) toate valorile dimensiunii de la un nivel
sau de la mai multe niveluri ale unei ierarhii. De exemplu, în dimensiunea
Instituţii se pot selecta toate valorile de la nivelul L1 (figura 7.20);
Match selectează (sau deselectează) acele valori ale unei dimensiuni care
conţin un şir de caractere specificat (figura 7.21);
215
Family selectează (sau deselectează) o familie de valori dintr-o ierarhie;

Exception selectează (sau deselectează) un set de valori ale unei
dimensiuni, în funcţie de valorile unei variabile ce utilizează această
dimensiune. De exemplu, se pot selecta numai facultăţile care au număr
proiecte> 2 (figura 7.22);
Top/Bottom se utilizează pentru a afişa primele sau ultimele n valori ale
unei dimensiuni, în funcţie de valorile unei variabile. De exemplu, se pot
selecta primele 3 facultăţi, în funcţie de valoarea contractată în lei, în 2002;
Range selectează (sau deselectează) un şir de valori ale unei dimensiuni de
tip Timp. De exemplu, se pot selecta lunile cuprinse între Ianuarie şi
Septembrie 2002;
• Saved Selection selectează (sau deselectează) un set de valori dintr-o
selecţie salvată (ce poate fi reutilizată);
Sort ordonează valorile unei dimensiuni după diferite criterii.
Figura 7.19 Afişarea variabilei create în fereastra Measures a utilitarului

Database Browser
Se poate afişa instrumentul Selector prin dublu click cu mouse-ul pe o

dimensiune din bara de dimensiuni (dimension bar) a unui tabel (sau grafic), sau se
selectează opţiunea Select Data, din meniul vertical ataşat butonului dreapta al
mouse-ului (tabelul sau graficul este selectat).
216
Figura 7.20 Opţiunea Level
Figura 7.21 Opţiunea Match
217
Figura 7.22 Opţiunea Exception
Se poate modifica selecţia curentă prin adăugarea unor noi valori ale
dimensiunii sau ştergerea unor valori. De exemplu, se alege opţiunea List a
selectorului (figura 7.23). În fereastra de dialog List, se selectează cu mouse-ul, din
caseta Available Instituţii, valorile care se doresc adăugate (de exemplu FPS). Apoi
se selectează butonul Add. Valorile selectate apar în caseta Selected Institutii. La
selectarea butonului OK, valorile sunt adăugate la selecţie curentă. Dacă se
selectează butonul Select, selecţia curentă este înlocuită cu noile valori selectate.
Butonul Add adaugă noi valori la selecţia curentă. Butonul Keep păstrează noile
valori în selecţia curentă şi le şterge pe celelalte, iar butonul Remove şterge noile
valori din selecţia curentă şi le păstrează pe celelalte.
Se poate salva o selecţie, pentru a fi reutilizată. Salvarea se poate face în două
moduri:
static. Selecţiile salvate au aceleaşi valori ori de câte ori sunt utilizate. De
exemplu, o selecţie ce conţine numai facultăţile (dimensiunea Institutii). Se
alege opţiunea Library şi se deschide fereastra de dialog Selection Library
(figura 7.24).
dinamic. Selecţiile salvate variază în timp, deoarece ele se bazează pe un
criteriu de selecţie respectat de valorile dimensiunii. De exemplu, se poate
crea o selecţie ce cuprinde primele 3 facultăţi care au cel mai mare număr
de proiecte. Această selecţie variază de la an la an. Scriptul pentru o
218
selecţie salvată dinamic conţine descrierea criteriului utilizat, pentru a

determina ce valori ale dimensiunii vor fi incluse în selecţie.
Figura 7.23 Modificarea selecţiei curente
7.9 Agregarea datelor
Se pot agrega datele utilizând diferite funcţii de agregare (total(), average(),

smallest(), largest() etc). De exemplu, se consideră variabila units (număr de
produse vândute pentru fiecare tip de produs, în fiecare lună şi în fiecare oraş)
(figura 7.25). Baza de date ataşată este DEMO. Pentru a agrega datele se parcurg
următorii paşi:
din bara de dimensiuni se selectează dimensiunea pe care dorim să o
agregăm (de exemplu dimensiunea Month);
se selectează opţiunea Aggregate din meniul vertical asociat butonului
dreapta al mouse-ului şi se deschide fereastra de dialog Aggregate
Dimension;
se selectează tipul de agregare (de exemplu total) şi se alege butonul OK
(figura 7.26). Se va afişa numărul total de produse vândute în primele 10
luni ale anului 1995, pentru fiecare tip de produs (figura 7.27).
219
Figura 7.24 O selecţie statică
Figura 7.25 Agregarea datelor
220
Figura 7.26 Fereastra Aggregate
Figura 7.27 Numărul total de produse vândute în primele 10 luni ale anului
221
După agregare, în bara de dimensiuni apare o icoană specială ce indică că

dimensiunea respectivă a fost agregată, iar dacă dimensiunea este selectată cu
mouse-ul, se afişează un mesaj care descrie agregarea (figura 7.27). Se poate
agrega orice dimensiune cu excepţia variabilelor. La anularea agregării (prin
alegerea opţiunii Disaggregate), modul de afişare a datelor nu mai este identic cu
cel dinainte de agregare .
În Express Analyzer, dimensiuniile ierarhice deja includ niveluri de agregare
cum ar fi pentru dimensiunea Instituţii din baza de date evaluare_final (figura
7.28). Această dimensiune are incluse totaluri (embedded totals). Atunci când se
doreşte agregarea dimensiunii Instituţii apare un mesaj de avertizare (figura 7.28),
prin care se specifică că dimensiunea conţine totaluri. Pentru a nu crea rezultate
eronate, se selectează butonul Change Selection din fereastra Aggregate şi se aleg
numai valorile unui singur nivel ierarhic sau se utilizează instrumentul Selector
(opţiunea Level şi Family).
Figura 7.28 Dimensiunea ierarhică Instituţii
Rezumat
Oracle Express Analyzer este un instrument OLAP ce permite analiza datelor,
crearea de briefing-uri, actualizarea briefing-urilor create cu Express Analyzer
sau Express Objects, lansarea în execuţie a unui briefing şi lansarea în execuţie a
aplicaţiilor create cu Express Objects.
222
Oracle Express Analyzer poate accesa datele stocate în baze de date

multidimensionale Express sau baze de date relaţionale.
În Oracle Express Analyzer se pot crea briefing-uri, pagini, tabele, grafice,
obiecte de tip ieşire, obiecte OLE, obiecte de tip banner şi butoane.
Oracle Express Analyzer şi Oracle Express Objects au o serie de utilitare
comune şi anume: Database Browser, Briefing Browser, Object Inspector,
instrumentul Selector.
Cuvinte cheie
Briefing, pagină, obiect de tip ieşire, obiect de tip OLE, tabel, grafic, agregarea
datelor.
223
Capitolul 8
Crearea unei baze de date
multidimensionale cu Oracle Express
Administrator
Oracle Express Administrator [OEDA99] se utilizează pentru a crea şi
administra baze de date multidimensionale Express. Elementele componente ale
unei baze de date Express sunt:
Variabilele. O variabilă este un obiect al bazei de date Express ce stochează
date, o matrice multidimensională ale cărei celule stochează date. Tipul de dată al
unei variabile indică datele pe care le conţine. Fiecare variabilă este organizată sau
dimensionată după una sau mai multe dimensiuni (max 32 de dimensiuni). Nu este
necesar ca toate variabilele să aibă aceeaşi dimensionalitate (să utilizeze acelaşi set
de dimensiuni). În lumea multidimensională, dimensionalitatea unei variabile este
adesea numită configuraţia variabilei.
Dimensiunile. Primele obiecte care trebuie create într-o bază de date Express
sunt dimensiunile. Express Server permite definirea a trei tipuri de dimensiuni:
Timp (valorile reprezintă perioade de timp), Text (valorile sunt descrieri ale
entităţilor pe care le reprezintă) şi INTEGER (valorile sunt identificate prin
poziţiile lor numerice. O dimensiune de tip integer este o secvenţă de numere ce
începe cu 1). O dimensiune ce conţine valori la toate nivelurile de agregare este
cunoscută ca dimensiune cu totaluri incluse (embedded total dimension).
Relaţiile. O relaţie descrie corespondenţa între valorile unei dimensiuni şi
valorile altei dimensiuni din baza de date. De exemplu, se poate crea o relaţie
numită niv_inst ce asociază valorile dimensiunii Instituţii cu valorile dimensiunii
Nivel_institut. Se pot utiliza relaţiile şi pentru a defini ierarhiile în dimensiuni.
Formulele. O formulă este un obiect al bazei de date Express ce defineşte o
expresie. Valorile formulei sunt calculate ori de câte ori este apelată formula.
Termenul de măsură este folosit pentru a referi variabilele, formulele şi relaţiile.
Obiectele compuse (composite). Un obiect compus este o dimensiune artificială
ce combină valorile a două dimensiuni împrăştiate. Express Server creează automat
un obiect compus, când se defineşte o variabilă împrăştiată.
224
Crearea unei baze de date multidimensionale
Modelele. Un model stochează un set de ecuaţii interdependente, care

utilizează valorile unor variabile sau a unor dimensiuni. Modelele sunt folosite
atunci când calculele sunt complexe sau variabilele nu sunt aditive.
Programele. Un program conţine secvenţe de comenzi ale limbajului Express
ce manipulează datele multidimensionale. În tabelul 8.1 sunt prezentate comparativ
conceptele utilizate de limbajul SQL şi limbajul multidimensional Express
[OEDA99].
Tabelul 8.1
Prezentare comparativă a conceptelor utilizate de limbajul SQL
şi limbajul Express
Concepte SQL Concepte Express
Baza de date Baza de date
Tabela -
Tabela virtuală Formula
Coloana Dimensiune
Clauza JOIN Relaţie
Clauza GROUP BY Comanda LIMIT
Clauza ORDER BY Comanda SORT
GRANT PERMIT
Proceduri stocate, scripturi SQL Programe, funcţii definite de utilizatori, comanda
INFILE
PL/SQL Limbaj de programare Express (Express SPL-
Stored Procedural Language)
Agregări (sum, avg, count, min, Funcţii şi formule Express folosind dimensiunile
max)
SELECT REPORT
INSERT MAINTAIN ADD
DELETE DELETE/MAINTAIN DELETE
UPDATE SET
Pentru a crea o bază de date multidimensională se parcurg următorii paşi:

definirea dimensiunilor bazei de date;
definirea măsurilor (variabile, relaţii, formule);
definirea seturilor de valori;
definirea programelor şi a modelelor de analiză.
8.1 Definirea dimensiunilor bazei de date
Din meniul principal se selectează submeniul File şi apoi se alege opţiunea

New. Apare fereastra de dialog Create a New Express Database. Se tastează
numele bazei de date (de exemplu evaluare_final). Oracle Express Administrator
va crea un fişier principal evaluare_final.db, în directorul specificat în mod implicit
225
(de exemplu d:\oracle\olap\oes634\service) sau se va alege un alt director, dacă se

selectează butonul Browse (figura 8.1).
Figura 8.1 Fereastra de dialog Create a New Express Database
Dimensiunea maximă a fişierului principal este de 2Gb (propietatea Filesize).

Pe măsură ce se creează obiecte în baza de date, Express Server creează unul sau
mai multe fişiere de extensie (extension file) cu acelaşi nume cu cel al bazei de
date. Pentru fişierul principal extensia este (.DB), iar pentru fişierele de extensie
(.001, 002, 003 etc).
Numele bazei de date creată este afişat în fereastra Database Browser, care se
deschide automat la lansarea în execuţie a utilitarului Oracle Express
Administrator. Se vor afişa de asemenea, obiectele bazei de date (dimensiuni,
formule, modele, programe, relaţii, seturi de valori, variabile) sub forma unei
structuri ierarhice. În mod implicit, în fereastra Database Browser se vor afişa
numai obiectele care sunt vizibile utilizatorului (figura 8.2).
Există mai multe modalităţi pentru a defini o dimensiune a bazei de date şi
anume:
se selectează cu mouse-ul ramura Dimension din fereastra Database
Browser şi apoi opţiunea New din meniul ataşat butonului dreapta al
mouse-ului. Se deschide fereastra de dialog Define a Dimension;
se selectează din meniul principal opţiunea Edit/Define/Dimension şi se
deschide fereastra de dialog Define a Dimension;
226
se utilizează limbajul Express .
Figura 8.2 Fereastra Database Browser
De exemplu, pentru a defini dimensiunea Nivel_institut, se selectează din

meniul principal, opţiunea Edit/Define/Dimension şi se deschide fereastra de dialog
Define a Dimension (figura 8.3). În caseta Name se tastează numele dimensiunii
(de exemplu Nivel_institut). În caseta Database se alege baza de date în care se
defineşte dimensiunea. În caseta Type se alege tipul de date (Text, ID, Integer, Day,
Week, Month, Quarter, Year, Conjoint şi Composite). Dacă dimensiunea este Timp
atunci tipul de dată ales poate fi: Day, Week, Month, Quarter, Year. Dacă
dimensiunea este de tip text (de exemplu dimensiunea Centre) tipul de dată poate fi
: ID (valorile dimensiunii au maxim 8 caractere) sau Text (valorile dimensiunii pot
avea mai mult de opt caractere). Dacă dimensiunea este de tip Integer valorile sale
sunt identificate numai de poziţiile lor numerice (1, 2 etc). Dacă tipul de dată este
Text se specifică şi numărul maxim de caractere pentru valorile dimensiunii, în
caseta Width. În caseta Dimension Identifier se specifică un identificator
alfanumeric pentru dimensiune. În caseta Dimension se specifică dimensiunile de
bază utilizate pentru a defini o dimensiune de tip conjoint sau composite, iar în
caseta Options, algoritmul utilizat pentru a încărca şi accesa valorile unei
dimensiuni de tip conjoint sau composite. Pentru a specifica numele, pe care
Express Objects şi Express Analyzer îl vor utiliza pentru a identifica dimensiunea,
se selectează butonul Labels. În caseta Comments se specifică o descriere a
227
dimensiunii create. Caseta Short Description specifică o descriere scurtă utilizată

de Express Objects şi Express Analyzer în tabele sau grafice, iar caseta Short
Description (Plural) specifică pluralul acestei descrieri, utilizată de Express
Objects şi Express Analyzer în scripturile selectorului. Caseta Description specifică
o descriere mai detaliată utilizată de instrumentul Selector sau Database Browser
din Express Analyzer sau Express Objects (dacă lipseşte se utilizează valoarea
specificată în caseta Short Description), iar caseta Description (Plural) specifică
pluralul acestei descrieri (figura 8.4).
Figura 8.3 Fereastra de dialog Define a Dimension
Când se creează o dimensiune, numele ei este stocat automat în dicţionarul de

date. Dicţionarul de date include structuri de date generate de Oracle Express
Administrator, pe care aplicaţiile construite cu Express Analyzer sau Express
Objects le utilizează, pentru a organiza datele şi ale prezenta mult mai clar. Pentru
a vizualiza metadatele în fereastra Database Browser, se selectează opţiunea
Options din submeniul Tools şi se deschide fereastra de dialog Administrator
Options (figura 8.5). Se selectează opţiunea DBBrowser, apoi opţiunea Show All
Metadata.
228
Figura 8.4 Utilizarea opţiunii Label din fereastra Define a Dimension
Figura 8.5 Fereastra Administrator Options
229
O dimensiune se poate defini folosind şi comanda DEFINE DIMENSION din

limbajul Express. De exemplu, se creează programul def_nivel (figura 8.6). Se
editează apoi programul pentru a-i ataşa următorul cod (figura 8.7):
Define Nivel_Institut dimension text
Ld Nivele in ierarhia institutului
Maintain Nivel_Institut Add 'UNIVERSITATI' 'FACULTATI' 'CATEDRE'
Programul se execută prin selectarea opţiunii Execute din meniul vertical ataşat
butonului dreapta al mouse-ului (programul este selectat cu mouse-ul).
Pentru dimensiunea creată se pot modifică unele propietăţi şi anume: valorile
dimensiunii, descrierea (Short Description, Description, Comments), selecţiile
ataşate (nume, descriere, scriptul utilizat pentru selecţie). Alte propietăţi nu pot fi
modificate (de exemplu baza de date în care este definită dimensiunea, numele
dimensiunii, tipul şi identificatorul). Pentru a modifica propietăţile unei dimensiuni
se selectează opţiunea Modify din meniul ataşat butonului dreapta al mouse-ului şi
se deschide fereastra de dialog Modify (figura 8.8) sau opţiunea Property Inspector
şi se deschide fereastra de propietăţi Property Inspector (figura 8.9).
Figura 8.6 Fereastra de dialog Define a Program
230
Figura 8.7 Definirea unei dimensiuni cu comanda DEFINE DIMENSION
Figura 8.8 Modificarea propietăţilor unei dimensiuni
231
Figura 8.9 Fereastra de propietăţi
După definirea unei dimensiuni, se vor introduce valorile corespunzătoare

manual sau prin import din surse externe. Pentru a defini valorile unei dimensiuni,
se selectează opţiunea Edit Values din meniul ataşat butonului dreapta al mouse-
ului şi se deschide fereastra de dialog Edit Values (figura 8.10). În această fereastră
se pot: adăuga noi valori (butonul Add values), şterge anumite valori, ordona
valorile după anumite criterii (butonul Sort), seta propietăţile Value, Short label şi
Long label pentru fiecare valoare (figura 8.11), adăuga, copia, şterge sau redenumi
ierarhii sau niveluri din ierarhii.
Pentru o dimensiune Timp (year, month, day, week) se deschide fereastra de
dialog Add Initial Data Values în care se stabileşte prima valoare (caseta First
Time Period), apoi numărul de valori (caseta Number of Periods). De exemplu, se
defineşte o dimensiune Luna de tip Month, se stabileşte prima lună (JUL03), apoi
se stabileşte numărul de perioade (6 luni) (figura 8.12).
O dimensiune poate avea una sau mai multe ierarhii. Pentru a defini o ierarhie
există două modalităţi şi anume:
se defineşte o relaţie între două dimensiuni;
sau se defineşte ierarhia în fereastra de dialog Edit Values.
De exemplu, se defineşte dimensiunea ierarhică Universitate cu următoarele
niveluri ierarhice: universitate (de exemplu ASE), facultate (de exemplu CSIE,
FMAN, FREI, EGPAA etc) şi catedră (de exemplu CIB, IE, STAT, EM etc)
(figura 8.13). În fereastra Edit Values se creează o ierarhie pentru care se specifică
numele şi descrierea (figura 8.14). Se pot redenumi nivelurile în ierarhie
232
(figura 8.15). Se definesc apoi valorile care vor fi incluse în ierarhie. Aceste valori
se „trag” apoi din caseta Available în caseta Hierarchy pentru a crea ierarhia de
valori (figura 8.13).
Figura 8.10 Fereastra de dialog Edit Values
Figura 8.11 Setarea propietăţilor Value, Short Label şi Long Label
233
Figura 8.12 Adăugarea de valori pentru o dimensiune Timp
Figura 8.13 O dimensiune ierarhică
234
Figura 8.14 Fereastra Add Hierarchy
Figura 8.15 Fereastra Rename Hierarchy Levels
235
8.2 Definirea variabilelor

Pentru a defini o variabilă se alege opţiunea Define Variable din submeniul
Edit. Se afişează fereastra de dialog Define a Variable (figura 8.16). Se tastează
numele variabilei în caseta Name (de exemplu nrproiecte). În caseta Database se
selectează baza de date, în care se va defini variabila. Se alege tipul de dată în
caseta Type (Boolean, Date, Decimal, ID, Integer, Shortdecimal, Shortinteger sau
Text). De exemplu, pentru variabila nrproiecte se alege tipul de dată shortinteger.
În caseta Available se selectează dimensiunile variabilei (de exemplu Timp, Centre
şi Tip_proiect). Se selectează mai întâi dimensiunea care se modifică cel mai des
(dimensiunea Timp). Toate variabilele definite vor putea fi folosite de aplicaţiile
create cu Express Analyzer şi Express Objects. Dacă caseta Temporary Data este
selectată, valorile variabilei vor fi şterse la încheierea sesiunii de lucru. În caseta
Sparse se listează dimensiunile împrăştiate (Express creează automat un obiect
compus). Pentru a specifică numele pe care Express Objects şi Express Analyzer îl
folosesc pentru a identifica variabila, se selectează opţiunea Labels. Pentru a
specifica formatul de afişare al valorilor variabilei, se selectează opţiunea Format.
Figura 8.16 Fereastra Define a Variable
Propietăţile variabilei se pot modifica în două moduri:

se selectează opţiunea Property Inspector din meniul ataşat butonului
dreapta al mouse-ului (variabila este selectată ) şi se deschide fereastra de
propietăţi (figura 8.17). Se poate modifica: propietatea LD (descrierea
variabilei), propietatea ShortName, propietatea UserVisible (dacă variabila
apare sau nu în Database Browser);
236
se selectează opţiunea Modify din meniul ataşat butonului dreapta al

mouse-ului şi se deschide fereastra de dialog Modify Variable (figura
8.18). Se pot modifica: formatul de afişare al valorilor variabilei (opţiunea
Format), numele pe care îl utilizează Express Objects şi Express Analyzer
pentru a identifica variabila (opţiunile Comments, ShortDescription,
Description), precum şi valorile variabilei (opţiunea Data).
Figura 8.17 Modificarea propietăţilor unei variabile
Valorile variabilei se pot adăuga fie manual, dacă se selectează opţiunea Data
din fereastra de dialog Modify Variable (figura 8.19), fie prin import din surse
externe, dacă se selectează opţiunea Import din submeniul File. Se pot importa date
din fişiere text, fişiere create cu instrumentul Discoverer, din baze de date
relaţionale etc. De exemplu, pentru a importa date dintr-o bază de date relaţională,
se selectează opţiunea Import Relational din submeniul File şi se afişează fereastra
de dialog Import Relational Data (figura 8.20). Se selectează butonul SQLConnect
pentru a realiza conexiunea la baza de date relaţională. Se selectează din caseta
TableName numele tabelei sursă (de exemplu nrprof_cat din schema de obiecte
mihaela), apoi se identifică obiectele din baza de date multidimensională
corespunzătoare atributelor tabelei (se „trag”cu mouse-ul din Database Browser în
caseta Express Object). Se selectează butonul Save şi se deschide fereastra de
dialog Save SQL Data Loader (figura 8.21), în care se specifică numele
programului de încărcare a datelor (implicit newloader). Acest program apare în
fereastra Database Browser, în ramura Programs şi se poate executa ori de câte ori
237
se doreşte. Se selectează programul şi se alege opţiunea Execute din meniul asociat

butonului dreapta al mouse-ului.
Figura 8.18 Fereastra de dialog Modify variable
Figura 8.19 Adăugarea valorilor unei variabile
238
Figura 8.20 Fereastra de dialog Import Relational Data
Figura 8.21 Fereastra de dialog Save SQL Data Loader
239
O variabilă se poate defini şi cu ajutorul comenzii DEFINE VARIABLE din

limbajul Express. De exemplu, pentru a defini variabila nrcadre se scrie următorul
cod:
Define nrcadre variable shortinteger <Timp, Institutii>
Ld Numărul de Cadre Didactice antrenate în cercetare la nivel de catedră şi an
Describe nrcadre
8.3 Definirea relaţiilor

O relaţie descrie corespondenţa între valorile unei dimensiuni şi valorile altei
dimensiuni din baza de date şi se utilizează adesea pentru a defini ierarhii. De
exemplu, se poate stabili o relaţie prin care se specifică modul cum se asociază
facultăţile cu catedrele. Pentru a defini o relaţie se selectează opţiunea Define
Relation din submeniul Edit şi se deschide fereastra de dialog Define a Relation
(figura 8.22). Se specifică numele relaţiei în caseta Name, numele bazei de date în
caseta Database, dimensiunea ale cărei valori se vor utiliza în relaţie (caseta
Related Dimension) etc. Dimensiunile care se asociază se selectează din caseta
Available şi se mută în caseta Selected.
Figura 8.22 Fereastra de dialog Define a Relation
Propietăţile unei relaţii se pot modifica fie în fereastra de propietăţi Property

Inspector, fie se selectează opţiunea Modify din meniul ataşat butonului dreapta al
mouse-ului şi se deschide fereastra de dialog Modify a Relation (figura 8.23). Se
pot modifica etichetele relaţiei (opţiunea Labels) şi valorile relaţiei (opţiunea
Data), dar nu se pot modifica propietăţile de bază ale relaţiei.
240
Figura 8.23 Fereastra de dialog Modify a Relation
De asemenea, o relaţie se poate defini şi cu comanda DEFINE RELATION din

limbajul Express. De exemplu, pentru a defini relaţia inst_inst se scrie următorul
cod:
define inst_inst relation institutii<institutii>
limit institutii to 'CO' 'TS' 'MMC''MAR'
inst_inst='COM'
limit institutii to 'DR' 'AEF' 'MON' 'FIN'
inst_inst='FABBV'
limit institutii to 'CIIF' 'CACG' 'IG'
inst_inst='CIG'
limit institutii to 'MAN' 'EC'
inst_inst='FMAN'
limit institutii to 'TI' 'CDE' 'EPE' 'EFS' 'IEG'
inst_inst='EG'
limit institutii to 'LRCA' 'LGCA' 'REI'
inst_inst='FREI'
limit institutii to 'TPAA'
inst_inst='EGPAA'
limit institutii to 'SELS'
inst_inst='FSELS'
limit institutii to 'CIB' 'IE' 'STAT' 'AS' 'EM'
inst_inst='CSIE'
limit institutii to fac_set
inst_inst='ASE'
241
8.4 Definirea formulelor

Într-o bază de date multidimensională Express se pot defini şi formule.
Formulele se folosesc pentru a calcula date temporare, care nu trebuie stocate
permanent în baza de date. De exemplu, se defineşte formula procent (procentul de
participare la activitatea de cercetare) = nrcadre/ncd unde: variabila nrcadre se
referă la numărul de cadre didactice antrenate în cercetare, la nivel de catedră şi an,
iar variabila ncd se referă la numărul de cadre didactice la nivel de catedră şi an.
Pentru a defini această formulă se selectează opţiunea Define Formula din
submeniul Edit şi se deschide fereastra de dialog Define a Formula (figura 8.24).
Figura 8.24 Fereastra de dialog Define a Formula
Se specifică numele formulei (caseta Name), baza de date curentă (caseta

Database), tipul de dată (boolean, date, decimal, id, integer etc), dimensiunile
formulei (caseta Selected). Dacă formula va conţine valori încărcate dintr-o bază de
date relaţională, se selectează caseta SQL Data şi se activează butoanele SQL
Connect (se realizează conexiunea la baza de date relaţională), Map Data (se
mapează atributelor tabelei relaţionale sursă la obiectele corespunzătoare din baza
de date multidimensională Express). În caseta Equation, se scrie formula de calcul
corespunzătoare.
Dacă se selectează opţiunea Edit Formula din meniul ataşat butonului dreapta
al mouse-ului, se afişează formula de calcul corespunzătoare şi se poate modifica
(figura 8.25). Propietăţile formulei se pot modifica fie în fereastra de propietăţi
Property Inspector, fie prin selectarea opţiunii Modify din meniul ataşat butonului
dreapta al mouse-ului şi se deschide fereastra de dialog Modify Formula (figura
8.26). Se pot modifica etichetele formulei (opţiunea Labels), formatul de afişare
(opţiunea Format) şi formula de calcul corespunzătoare.
242
Se poate crea o formulă de formatare (culori, fonturi) a datelor afişate, în

funcţie de valorile acestor date. De exemplu, se poate specifica ca toate valorile
formulei procent mai mici de 0.5 (un procent de încărcare a cadrelor didactice mai
mic de 50%) să se afişeze cu culoare roşie. Această formulă de formatare este
valabilă şi în Express Objects şi Express Analyzer. Pentru a crea o formulă de
formatare se selectează opţiunea Data Driven Format din fereastra de dialog
Modify Formula.
Figura 8.25 Modificarea formulei de calcul
O formulă se poate defini şi cu comanda DEFINE FORMULA din limbajul

Express. De exemplu, pentru a defini formula procent se scrie următorul cod:
define procent formula decimal <timp, institutii>
eq nrcadre/ncd
8.5 Definirea seturilor de valori

Setul de valori (valueset) este un obiect al bazei de date Express care stochează
o listă de valori ale unei dimensiuni. Acest obiect se utilizează pentru a seta mai
rapid starea unei dimensiuni. De exemplu, se poate defini un set de valori cat_set
care va stoca o listă a catedrelor. Pentru a crea setul de valori cat_set, se selectează
opţiunea Define valueset din submeniul Edit. Se deschide fereastra de dialog
Define a Valueset (figura 8.27). Se specifică numele setului (caseta Name), baza de
date curentă (caseta Database), dimensiunea corespunzătoare setului de valori
243
(caseta Dimension), etichetele setului de valori (opţiunea Labels). Pentru a adăuga

valori în setul de valori se utilizează comanda LIMIT.
Propietăţile setului de valori pot fi modificate fie în fereastra de propietăţi
Property Inspector, fie se selectează opţiunea Modify din meniul ataşat butonului
dreapta al mouse-ului şi se deschide fereastra de dialog Modify Valueset (figura
8.28).
Un set de valori se poate defini şi cu comanda DEFINE VALUESET. De
exemplu, pentru a defini setul de valori cat_set se scrie următorul cod:
define cat_set valueset institutii
ld setul de catedre
limit cat_set to 'CO' 'REI' 'MAN' 'SELS' 'CIB' 'IE' 'STAT' 'AS' 'DR' 'CIIF' 'CACG'
Figura 8.26. Fereastra de dialog Modify Formula
8.6 Definirea programelor

Un program conţine secvenţe de comenzi ale limbajului Express ce
manipulează datele multidimensionale. Pentru a crea un program, se selectează
opţiunea Define program din submeniul Edit. Se deschide fereastra de dialog
Define a program (figura 8.29). Se specifică numele programului (caseta Name),
baza de date curentă (caseta Database), etichetele programului (opţiunea Labels),
tipul de dată al valorii returnate de program (caseta Return Type).
Se selectează opţiunea Modify din meniul ataşat butonului dreapta al mouse-
ului, pentru a afişă fereastra de dialog Edit program, în care se tastează secvenţa de
comenzi (figura 8.30). Programul se poate compila, dacă se selectează icoana
244
Compile din bara de butoane a ferestrei de dialog Edit program şi lansa în execuţie,
dacă se selectează icoana Run Program. Un program se poate lansa în execuţie şi
dacă se selectează opţiunea Execute din meniul ataşat butonului dreapta al mouse-
ului şi se deschide fereastra Express Command. În fereastra Express Command, se
pot executa comenzile limbajului Express.
Figura 8.27 Fereastra de dialog Define a Valueset
Figura 8.28 Fereastra de dialog Modify Valueset
245
Figura 8.29 Fereastra de dialog Define a Program
Figura 8.30 Fereastra de dialog Edit program
246
Se poate crea un program şi prin utilizarea instrumentului Data Loader (de

exemplu, pentru a importa date din baze de date relaţionale), a instrumentului
Database Wizard, a instrumentului Rollup Wizard (pentru agregarea datelor) sau cu
comanda DEFINE PROGRAM din limbajul Express.
Se poate planifica momentul lansării în execuţie (ora, ziua) a unui program,
dacă se selectează opţiunea Schedule din meniul ataşat butonului dreapta al mouse-
ului. Se deschide fereastra de dialog Schedule the program (figura 8.31). Se
specifică numele programului, baza de date în care este stocat, tipul de program
(command, dataloader, rollup), descrierea programului, comanda ce apelează
programul (caseta Command), momentul lansării în execuţie: imediat
(immediately), la un anumit moment (at this time), după execuţia altui program
(after running). De asemenea, se specifică de câte ori se execută programul (în ore,
minute, zile, luni) şi momentul opririi execuţiei programului (caseta Until).
Figura 8.31 Fereastra de dialog Schedule the Program
Rezumat
Oracle Express Administrator se utilizează pentru a crea şi administra baze de
date multidimensionale Express.
Pentru a crea o bază de date multidimensională se definesc dimensiunile bazei
de date, măsurile (variabile, relaţii, formule), seturile de valori, programele şi
modelele de analiză.
Cuvinte cheie
Bază de date multidimensională, dimensiuni, variabile, formule, relaţii, seturi de
valori, programe, modele de analiză, obiecte compuse.
247
Capitolul 9
Proiectarea şi realizarea unui sistem
OLAP
(studiu de caz)
În secolul 21, secolul informaţiilor şi al afacerilor inteligente, organizaţiile vor
putea să-şi îndeplinească obiectivele, numai dacă managerii vor putea utiliza ca
suport în procesul decizional informaţii suficiente şi de calitate.
La ora actuală, preocuparea majoră a specialiştilor în domeniul sistemelor
informatice este de a satisface cererea tot mai mare a managerilor pentru informaţii
care să le permită evaluarea cât mai rapidă şi mai corectă a performanţelor
organizaţiilor pe care le conduc. Sistemele OLAP pot satisface această cerere de
informaţii de calitate şi pot îmbunătăţi eficacitatea muncii decizionale a
managerilor.
Obiectivul acestui capitol este de a arăta că modelarea multidimensională a
datelor existente în organizaţii, în funcţie de subiectele de interes ale managerilor şi
vizualizarea multidimensională a informaţiilor, poate oferi un suport informaţional
eficace managerilor în procesul decizional, indiferent de domeniul de activitate.
Pentru a demonstra acest lucru, în acest capitol, se va proiecta un model de date
multidimensional şi un sistem OLAP pentru analiza activităţii de cercetare
ştiinţifică în învăţământul universitar.
Tehnica de modelare entitate-asociere şi structurarea datelor în tabele
normalizate reprezintă standardul pentru specialiştii de baze de date, care utilizează
în mod frecvent bazele de date relaţionale, pentru a stoca volumele mari de date
tranzacţionale existente în organizaţii. Totuşi, utilizarea tabelelor pentru a furniza
informaţiile necesare procesului decizional la nivelul organizaţiilor, nu este
întotdeauna o soluţie ideală pentru manageri.
Accesul la informaţiile stocate în bazele de date relaţionale tranzacţionale cere
realizarea de operaţii, adesea foarte complexe, între multe tabele. Din acest motiv,
managerii trebuie să apeleze la specialişti pentru a executa cererile de regăsire (de
exemplu în limbajul SQL). De asemenea, bazele de date relaţionale de dimensiuni
mari, proiectate să ofere suport aplicaţiilor tranzacţionale, permit cu dificultate
vizualizarea informaţiilor după subiectele de interes ale managerilor.
248
Proiectarea şi realizarea unui sistem OLAP
Apariţia sistemelor OLAP a permis managerilor să acceseze un volum mare de

informaţii integrate, să le vizualizeze din diferite perspective şi să le analizeze on-
line, cu scopul de a evalua cât mai obiectiv şi mai exact performanţele
organizaţiilor şi de a realiza un proces decizional bazat pe analiză.
Pentru a realiza un suport decizional de calitate la nivelul organizaţiilor,
modelele conceptelor de afaceri, care asigură o viziune consolidată asupra
afacerilor, pot fi definite la nivel conceptual, sub forma unor cuburi de date n-
dimensionale (hypercub) (figura 9.1). Aceste modele descriu subiectele principale
despre care organizaţia trebuie să colecteze informaţii (ce informaţii sunt necesare
pentru a lua decizii mai bune?). Cerinţele afacerii sunt o combinaţie între cerinţele
utilizatorilor, realităţile legate de sursele de date şi realităţile economice.
Organizaţii
executând
Procese
Produse şi
Resurse: servicii:
Bani Învăţământ
Oameni Cercetare
Experienţa Suport financiar
Munca Sănatate
Facilităţi Alimentaţie
…….. …….
Clienţi
Figura 9.1 Modelul conceptelor de afaceri sub forma unui cub n-dimensional
Definirea modelelor de afaceri sub forma de cuburi n-dimensionale sau

multicuburi permite analiştilor şi managerilor să înţeleagă mai bine datele din
organizaţii, date ce ar putea fi integrate, agregate, să vizualizeze şi să analizeze
datele din multiple perspective (dimensiunile afacerii), să pună în evidenţă noi
aspecte ale afacerii, care ar putea oferi firmelor noi oportunităţi şi o îmbunătăţire a
eficacităţii procesului decizional (figura 9.2). În cele ce urmează, propunem câteva
prototipuri multidimensionale de modele de afaceri.
249
De exemplu, evaluarea şi managementul activităţilor de marketing presupune

[KOTL98]:
“ verificarea realizării performanţelor planificate cu ajutorul a cinci tipuri
de analize: analiza vânzărilor, analiza participării pe piaţă, analiza
raportului dintre cheltuielile de marketing şi vânzări, analiza financiară şi
urmărirea nivelului de satisfacere a clientului.
examinarea locului unde câştigă firma bani şi unde pierde prin stabilirea
profitabilităţii pe produs, teritoriu, client, segment al pieţei, canal de
distribuţie, mărimea comenzii lansate.
evaluarea şi îmbunătăţirea eficienţei utilizării fondurilor destinate
activităţii de marketing prin: analiza eficienţei forţei de vânzare, analiza
eficienţei reclamei comerciale, analiza eficienţei promovării vânzărilor şi
analiza eficienţei activităţii de distribuţie.
examinarea modului în care firma dă curs celor mai bune ocazii ale sale
legate de pieţe, produse şi canale de distribuţie prin: evaluarea eficienţei
activităţii de marketing, analiza de marketing, analiza performanţelor de
marketing şi analiza responsabilităţilor etice şi sociale ale firmei.”
Conţinut
“fapte”
Exemple de dimensiuni
Resurse: Exemple de
Bani dimensiuni
Organizaţii Client:
Personal Studenţi
Echipamente Stat/societate
Clienţi interni
Exemple de dimensiuni Produs:

La studenţi: La societate:
Invăţământ Cercetare
Cazare Resurse umane
Ajutor financiar Servicii publice
Hrană Contabilitate
Sănatate etc
Cercetare în învăţământ etc
Figura 9.2 Procesul (problema analizată) sub forma unui “cub” de informaţii
Analiza vânzărilor constă în măsurarea şi evaluarea vânzărilor reale, în raport

cu obiectivele propuse prin plan. Controlul pe baza planului anual cere de
asemenea, firmei să se asigure că nu face cheltuieli exagerate pentru a-şi realiza
vânzările. În acest scop, se va face analiza raportului dintre cheltuielile de
marketing şi vânzări care constă în rapoartele: forţa de vânzare/vânzări, cheltuielile
cu reclama/vânzări, promovarea vânzărilor/vânzări, cercetarea de
250
marketing/vânzări, cheltuieli administrative/vânzări. Pentru aceste analize se poate

utiliza cu succes modelul multidimensional. Cubul n-dimensional pentru analiza
vânzărilor conţine informaţii despre venituri (volumul vânzărilor) şi cheltuieli
(cheltuieli cu reclama şi promovarea vânzărilor, costul bunurilor vândute, cheltuieli
cu cercetarea de piaţă, cheltuieli administrative şi generale, cheltuieli cu activitatea
de desfacere, cheltuieli cu activitatea de ambalare şi livrare, cheltuieli cu activitatea
de facturare, salarii, chiria, costurile cu investiţiile etc). Dimensiunile de bază ale
cubului n-dimensional sunt : Ţara (locaţie geografică), Produs, Timp şi Promoţie.
Atributele acestor dimensiuni pot varia în funcţie de specificul firmei analizate. De
asemenea, se pot adăuga şi alte dimensiuni cum ar dimensiunea Strategia de
investiţii. Dimensiunea Strategia de investiţii a fost definită pentru a evalua
diferitele moduri de a investi (efectul expansiunii liniei de produse, a numărului de
pieţe sau regiuni de desfacere sau a publicităţii şi reclamei asupra profitului). Ca
variabile se pot defini: volumul de vânzări, costul bunurilor vândute, cheltuielile cu
activitatea de desfacere, cheltuielile cu activitatea de reclamă, cheltuielile cu
activitatea de ambalare şi livrare, salariile, cheltuielile administrative, chiria,
costurile cu investiţiile, alte cheltuieli (ce apar pe lângă cele prezentate anterior),
costul banilor (pierderile ce apar ca urmare a schimburilor valutare, dacă firma are
reprezentanţe şi în alte ţări). Pe baza acestor variabile se pot determina cu ajutorul
formulelor: marja profitului brut (vânzări-costul bunurilor vândute), cheltuielile
totale directe, total cheltuieli, profitul net sau pierderea (volumul vânzărilor-total
cheltuieli). În figura 9.3 se prezintă un prototip de cub n-dimensional pentru
analiza vânzărilor.
Produs Măsuri: Timp

Codprodus Cantitatea vândutâ Cod data
Marca Volumul vânzărilor Ziua din săptămâna
Subcategoria Costurile Numărul zilei în luna
Categorie Numărul de clienţi Numărul săptămânii în
Tipul de ambalaj an
Greutatea Luna
Culoare Trimestru
Dimensiune An
Fabricant Perioada fiscală
Sezon, Eveniment
Promoţie
Cod Locaţie geografică
Denumire Cod magazin
Tipul de reducere a Denumire
preţului Cubul n- Adresa, Oraş
Tipul de publicitate Judeţ, Regiune
Costul promoţional dimensional pentru
Ţara,
Data începerii analiza vânzărilor Manager magazin,
promoţiei Telefon,
Data de sfârşit fax,
Suprafaţă
Figura 9.3 Cubul n-dimensional pentru analiza vânzărilor
251
Granulaţia cubului n-dimensional este dată de granulaţia dimensiunilor (de

exemplu cantitatea zilnică vândută din fiecare produs, în fiecare magazin). Cu acest
model se poate realiza o analiză detaliată a vânzărilor şi anume volumul total al
vânzărilor la nivel de săptămână, lună, trimestru, an , pe o anumită categorie de
produse, într-un anumit magazin, oraş, regiune etc.
Orice firmă trebuie de asemenea, să măsoare rentabilitatea diferitelor ei
produse, teritorii, canale de distribuţie şi comenzi. Aceste informaţii îi vor ajuta pe
manageri să stabilească dacă vreunele din produsele firmei trebuie să fie extinse,
reduse sau eliminate. Cubul n-dimensional din figura 9.3 poate fi folosit pentru a
stabili rapoarte de profit şi cheltuieli, pentru fiecare canal de comercializare (tip de
magazin), produs, teritoriu etc. În figura 9.4 se propune un prototip de cub n-
dimensional pentru analiza poliţelor de asigurare (granularitatea este la nivel de
tranzacţie individuală).
Riscul Măsuri: Timp

Cod poliţă Suma asigurată Cod data
Grad de risc Suma încasată Ziua din săptămână
Rata primă Perioada fiscală
etc
Tipul de asigurare
Cod
Agent
Descriere
Cod agent
Segment piaţă
Nume
Tip agent
Locaţie
Asigurat/ coasigurat/
contractant Cubul n-dimensional
Cod pentru analiza poliţelor
Nume Produs asigurat
de asigurare Cod produs asigurat
Adresa
Tip Descriere
Atribute demografice Tranzacţie Tip produs asigurat
Cod tranzacţie
Descriere
Motiv
Figura 9.4 Cubul n-dimensional pentru analiza poliţelor de asigurare
9.1 Iniţierea proiectului

Pentru proiectarea sistemului OLAP s-a utilizat metodologia prezentată în
capitolul 5. În cartea “Metodologia cercetării ştiinţifice economice” [RACI01]
cercetarea ştiinţifică este definită “ca o activitate sistematică şi creatoare, menită
să sporească volumul de cunoştinţe, inclusiv cunoştinţe despre om, cultura, şi
utilizarea acestor cunoştinţe pentru noi aplicaţii”. Activitatea de cercetare
ştiinţifică se clasifică în trei categorii [RACI01]:
252
Cercetarea ştiinţifică fundamentală este o activitate mai mult teoretică (în

domenii ca: creşterea economică şi modelare, analiza proceselor economice,
probleme financiare, fiscale şi monetare etc) care are ca scop principal
“acumularea de noi cunoştinţe privind aspectele fundamentale ale fenomenelor şi
faptelor observabile, fără să aibă în vedere o aplicaţie deosebită sau specifică”
[RACI01].
Cercetarea ştiinţifică aplicativă este o activitate de investigare “orientată spre
un scop sau obiectiv practic specific” care transformă rezultatele cercetării
ştiinţifice fundamentale şi de dezvoltare în “tehnici şi tehnologii concrete, în
măsuri concrete de organizare, de conducere economică etc” [RACI01].
Cercetarea ştiinţifică fundamentală şi aplicativă ocupă un loc important în
activitatea de cercetare ştiinţifică din învăţământul superior.
Cercetarea şi dezvoltarea experimentală este o activitate sistematică dedicată
utilizării rezultatelor cercetării ştiinţifice fundamentale şi a celei aplicative “pentru
obţinerea unor soluţii de principiu, pentru proiectare, executare şi încercare de
prototipuri experimentale şi de produse etc” [RACI01].
În România, cercetarea ştiinţifică economică are următoarea structură
instituţională [RACI01]:
Institutul Naţional de Cercetări Economice;
Reţeaua cercetării ştiinţifice economice româneşti din sistemul
Ministerului Educaţiei şi Cercetării;
Institute de cercetare ştiinţifică fără subordonare directă academică,
aparţinând altor ministere;
Reţeaua cercetării ştiinţifice economice româneşti din sistemul Ministerului
Educaţiei şi Cercetării include universităţi publice şi private, din centrele
universitare cu învăţământ economic. Astfel în Academia de Studii Economice,
activitatea de cercetare ştiinţifică este “componenta principală a proceselor de
învăţământ şi inovare”.
Principalele direcţii de dezvoltare şi modernizare ale cercetării ştiinţifice din
Academia de Studii Economice, specificate în Buletinul Informativ al
Departamentului de Cercetări Economice [BULE01], sunt: “ i) încurajarea
cercetării ştiinţifice finanţată pe plan naţional; ii) dezvoltarea cercetării ştiinţifice
cu colaborare internaţională şi finanţare mixtă, oferită de Guvernul României,
Comunitatea Europeană, Banca Mondială; iii) iniţierea unor programe de
cercetare în colaborare bilaterală cu universităţi din Uniunea Europeană; iv)
încurajarea cercetării ştiinţifice fundamentale; v) intensificarea activităţii
laboratoarelor pentru cercetări aplicative şi studii de caz; vi) crearea/acreditarea
unor noi centre de cercetare; vii) promovarea transferului tehnologic; viii)
recunoaşterea activităţii de cercetare ştiinţifică; ix) perfecţionarea programelor de
doctorat şi masterat; x) modernizarea managementului cercetării ştiinţifice.”
Deoarece activitatea de cercetare este componenta principală a proceselor de
învăţământ şi inovare din universităţi şi ca urmare a faptului că universităţile îşi
desfăşoară activitatea într-un mediu competitiv, se impune un management cât mai
eficace pentru activitatea de cercetare. Există cel puţin două motive diferite care
253
determină necesitatea evaluării performanţei activităţii de cercetare în universităţi

şi anume : alocarea de fonduri şi asigurarea calităţii.
Sistemul OLAP propus (prototipul a fost proiectat şi construit pentru
activitatea de cercetare ştiinţifică din Academia de Studii Economice, cu
posibilitatea de a fi extins) încearcă să ofere managerilor:
posibilitatea de a accesa direct datele (fără intermediari) şi de a le manipula
uşor;
posibilitatea de a identifica erorile şi datele lipsă şi de a le corecta;
o activitate de planificare mai uşoară, deoarece toţi participanţii vor avea
acces la informaţii;
posibilitatea de a aloca, în mod obiectiv, fondurile şi de a asigura o
activitate de cercetare de calitate.
9.2 Studiul şi analiza procesului decizional curent

şi a cerinţelor informaţionale
În Regulamentul privind organizarea, desfăşurarea şi finanţarea cercetării
ştiinţifice în Academia de Studii Economice Bucureşti, se prezintă modul de
organizare:
“Unitatea de bază a organizării activităţii de cercetare ştiinţifică din
Academia de Studii Economice este catedra” [BULE01].
“Activitatea de cercetare ştiintifică se poate realiza şi prin colaborare cu alte
institute de învăţământ şi de cercetare din ţară şi din străinatate” [BULE01].
“Activitatea de cercetare ştiinţifică se organizează şi se desfăşoară prin
proiecte şi teme, finanţate sau nefinanţate cuprinse în programele catedrelor,
facultăţilor, centrelor de cercetare etc” [BULE01].
Aşa cum se specifică în “Metodologia de identificare, evaluare şi recunoaştere
a centrelor de cercetare, în vederea acreditării centrelor de excelenţă ştiinţifică”,
centrele de cercetare ştiinţifică se pot constitui la nivel de catedră, facultate sau
universitate, iar evaluarea şi recunoaşterea lor are la bază competiţia organizată la
nivelul universităţilor şi cea organizată la nivel naţional de CNCSIS. În urma
evaluării de către CNCSIS, centrele primesc niveluri de competenţă (centru de
excelenţă, centru de cercetare de tip B, centru de cercetare de tip C)
[http://www.cncsis.ro]. Centrele de cercetare neacreditate reprezintă unităţi
recunoscute şi aprobate instituţional. În Academia de Studii Economice îşi
desfăşoară activitatea următoarele centre de cercetare [BULE01]:
Centrul de Cercetare ECO-INFOSOC–Modelarea şi informatizarea
proceselor economico-sociale, acreditat CNCSIS. Nivelul de organizare
este facultatea de Cibernetică, Statistică şi Informatică Economică.
Centrul de Cercetări, Analize şi Expertize Mărfuri Alimentare, acreditat
CNCSIS. Nivelul de organizare este catedra de Merceologie şi
Managementul Calităţii, Facultatea de Comerţ.
254
Centrul Naţional de Excelenţă pentru Studii de Management Comparat,

acreditat CNCSIS. Nivelul de organizare este facultatea de Management.
Centrul de Excelenţă pentru Analize şi Politici Economice, acreditat
CNCSIS. Nivelul de organizare este catedra de Economie şi Politici
Economice.
Centrul de Studii în Contabilitate şi Informatică de Gestiune, acreditat
CNCSIS. Nivelul de organizare este facultatea de Contabilitate şi
Informatică de Gestiune.
Centrul de Cercetări în Managementul Proiectelor-PM Forum, acreditat
instituţional. Nivelul de organizare este facultatea de Cibernetică, Statistică
şi Informatică Economică.
Centrul de Excelenţă pentru Analize şi Politici Regionale, acreditat
instituţional, face parte din Centrul European Interuniversitar Româno-
Bulgar, BRIE.
Centrul de Cercetări Financiar Monetare, acreditat instituţional. Nivelul
de organizare este facultatea de Finanţe, Asigurări, Bănci şi Burse de valori
[BULE01].
“Activitatea de cercetare ştiinţifică finanţată se desfăşoară prin intermediul
programelor, subprogramelor, temelor de cercetare-dezvoltare şi activităţilor
cuprinse, după caz, în: i) programe naţionale de cercetare ştiinţifică, precum şi
managementul acestora, finanţate de Agenţia Naţională pentru Ştiinţă, Tehnologie
şi Inovare; ii) programe de cercetare ştiinţifică finanţate de Ministerul Educaţiei
Naţionale, prin Consiliul Naţional al Cercetării Ştiinţifice din Învăţământul
Superior; iii) teme de cercetare ştiinţifică şi consultanţă contractate cu societăţi
comerciale, organizaţii guvernamentale şi neguvernamentale; iv) programe
instituţionale coordonate de Biroul Senatului Academiei de Studii Economice şi
finanţate din fonduri proprii; v) programe instituţionale coordonate de
Departamentul de Cercetări Economice; vi) programele departamentale
coordonate de catedre şi facultăţi care cuprind şi cercetările individuale finanţate”
[BULE01].
Programele de finanţare naţională (granturi CNCSIS) includ:
programele anuale de cercetare (tip A) care au ca obiective principale:
”dezvoltarea activităţilor de cercetare ştiinţifică în procesul de formare a
resursei umane, creşterea performanţei ştiinţifice şi stimularea formării
echipelor de cercetare prin implicarea studenţilor admişi în programe de
studii aprofundate, academice şi doctorat”;
programele anuale pentru tineri (tip AT) care urmăresc să ofere tinerilor
cercetători, doctori sau doctoranzi, un suport eficient pentru realizarea unor
lucrări de cercetare ştiinţifice valoroase;
programele de echipamente pentru laboratoare (tip E) care urmăresc
“dezvoltarea/consolidarea de echipamente care să permită cercetarea în
domenii de vârf pentru care nu există structura necesară”;
programele individuale de cercetare pentru tineri doctoranzi (tip Td) care
urmăresc “să ofere tinerilor doctoranzi suportul necesar pentru efectuarea,
255
în ţară sau în străinătate a cercetărilor cuprinse în programul de

doctorat”;
programele de burse individuale de cercetare pentru tineri doctoranzi (tip
Bd) care urmăresc “stimularea tinerilor doctoranzi în activitatea de
cercetare şi în realizarea studiilor doctorale în maxim 4 ani”
[http://www.cncsis.ro].
În contextul general al reformei sistemului universitar românesc s-a desfăşurat
şi “Programul de Reformă a Învăţământului Superior şi Cercetării din
Universităţi” (RO-4096) cofinanţat de Guvernul României şi Banca Mondială cu
următoarele componente: proiecte majore de cercetare (C), proiecte pentru
învăţământ postuniversitar, studii aprofundate, master şi doctorat (D), proiecte de
cercetare pentru tineri (T), baze de cercetare cu utilizatori multipli (B), proiecte
universitare, proiecte pentru educaţie permanentă şi proiecte pentru colegii
[http://www.cncsis.ro].
“Rezultatele recunoscute ale activităţii de cercetare ştiinţifică se concretizează
în: i) rapoarte de cercetare depuse la bibliotecile Academiei de Studii Economice,
inclusiv la secţia ştiinţifică şi la arhiva Departamentului de Cercetări Economice;
ii) sisteme, modele, produse program, soluţii de modernizare şi creştere a eficienţei
economice etc. însoţite de documentaţii corespunzătoare depuse la bibliotecile
Academiei de Studii Economice, inclusiv la secţia ştiinţifică şi la arhiva
Departamentului de Cercetări Economice; iii) cărţi, tratate şi monografii cu
conţinut ştiinţific inedit publicate şi depuse la bibliotecile Academiei de Studii
Economice inclusiv la secţia ştiinţifică şi la arhiva Departamentului de Cercetări
Economice; iv) comunicări ştiinţifice pe plan naţional şi internaţional; v) articole
publicate în volume ale manifestărilor ştiinţifice sau în reviste de specialitate din
ţară şi străinătate.” [BULE01]
“La nivelul Academiei de Studii Economice, al facultăţilor şi catedrelor se pot
organiza seminarii ştiinţifice, sesiuni, conferinţe şi alte manifestări ştiinţifice,
pentru comunicarea rezultatelor şi experienţei acumulate în activitatea de
cercetare.” [BULE01]
“Activitatea de cercetare ştiinţifică a studenţilor se desfăşoară sub diverse
forme: i) cercetare ştiinţifică realizată în mod independent, îndrumată de cadrele
didactice şi care se finalizează prin proiecte, lucrări de diplomă, studii de caz; ii)
transformarea parţială a unor seminarii didactice în seminarii ştiinţifice; iii)
antrenarea şi participarea studenţilor la realizare unor programe/proiecte
coordonate de către catedre şi centrele de cercetare ştiinţifică; iv) organizarea de
către catedre a unor cercuri ştiinţifice studenteşti. Rezultatele activităţii ştiinţifice
pot fi luate în considerare în sistemul de notare a studenţilor, pot fi publicate în
reviste de specialitate, pot fi prezentate la sesiunile de comunicări ştiinţifice ale
studenţilor şi la concursurile profesionale organizate.
Cerinţele prototipului au fost determinate pe baza identificării indicatorilor
utilizaţi pentru măsurarea nivelului performanţelor în cercetarea ştiinţifică, precum
şi a obiectivele şi strategiile activităţii de cercetare ştiinţifică în învăţământul
universitar.
256
În “Metodologia de alocare a fondurilor reprezentând finanţarea de bază a

universităţilor”, propusă de MEC, se definesc un număr de indicatori de
performanţă utilizaţi pentru măsurarea nivelului performanţelor în cercetarea
ştiinţifică finanţată şi nefinanţată, în învăţamântul universitar şi anume [BULE01]:
Indicatorul n1
Granturi câştigate (granturi CNCSIS şi ale Academiei Române)
n1=n1a*p1+n1b*p2
n1a=c1*N1/(Ncd+Nc)
n1b=c2*Vtgn/(Ncd+Nc) unde:
p1=ponderea indicatorului n1a în n1 (p1=0.5)

p2=ponderea indicatorului n1b în n1 (p2=0.5)
N1=numărul total de granturi naţionale
Ncd=numărul total de cadre didactice
Nc=numărul total de cercetători
Vtgn=valoarea totală granturi naţionale(milioane ROL)
c1=punctaj pentru grant naţional (c1=10)
c2=punctaj pentru resursele financiare atrase (referinţa este 10 mil. ROL per om)
(c2=1)
Indicatorul n2
Contracte de cercetare internaţionale
n2=n2a*p3+n2b*p4
n2a=c3*N2/(Ncd+Nc)
n2b=c4*Vtci/(Ncd+Nc) unde:

N2=numărul total de contracte de cercetare internaţionale
Vtci=valoarea totală de contracte internaţionale (USD)
c3=punctaj pentru un contract internaţional (c3=300)
c4=punctaj pentru resursele financiare atrase (referinţa este 500 USD per om)
(c4=0.02)
Indicatorul n3
Contracte cu diverse companii din ţară şi contracte obţinute în cadrul Planului
Naţional de Cercetare Dezvoltare
n3=n3a*p5+n3b*p6
n3a=c5*N3/(Ncd+Nc)
n3b=c6*Vtcn/(Ncd+Nc) unde:
257

N3=numărul total de contracte cu companii din ţară şi contracte obţinute în cadrul
PNCD
Vtcn=valoarea totală de contracte cu companii din ţară şi contracte obţinute în
cadrul PNCD (milioane ROL)
c5=punctaj pentru un contract cu companii din ţară şi contracte obţinute în cadrul
PNCD (c5=10)
c6=punctaj pentru resursele financiare atrase (referinţa este de 20 mil. ROL per
om) (c6=0.5)
Indicatorul n4
Teze de doctorat finalizate
n4=n4.1*p7+n4.2*p8
n4.1=c7*N dcd /Np
n4.2=c8*N ftd /Nd unde:
p7=ponderea indicatorului n4.1 în n4 (p7=0.3)

N dcd =numărul total conducători de doctorat
N ftd =numărul total teze de doctorat finalizate
Nd=numărul total de doctoranzi aflaţi în evidenţa universităţii la 1 ianuarie 20..
Np=număr total profesori
c7=punctaj pentru un conducător de doctorat (c7=10)
c8=punctaj pentru o teză de doctorat finalizată (c8=100)
Indicatorul n5
Articole publicate în reviste cotate
n5=n5.1*p9+n5..2*p10
n5.1=c9*N5.1/(Ncd+Nc)
n5.2=c10* N5.2/(Ncd+Nc) unde:

N5.1=numărul total de articole publicate în reviste româneşti recunoscute de
CNCSIS, lucrări publicate în volumele conferinţelor internaţionale cu recenzori şi
lucrări publicate în reviste din străinătate cu recenzori
N5.2=numărul total de articole publicate în reviste cotate ISI
258
c9=punctaj pentru un articol publicat în reviste româneşti recunoscute CNCSIS

(c9=20)
c10=punctaj pentru un articol publicat în reviste cotate ISI (c10=60)
Indicatorul n6
Cărţi publicate în edituri recunoscute
n6=n6.1*p11+n6..2*p12
n6.1=c11*∑pagin/Npnr(Ncd+Nc)
n5.2=c10*∑pagiin /Npir(Ncd+Nc) unde:

N6.1=numărul total de cărţi publicate în edituri româneşti recunoscute CNCSIS
N6.2=numărul total de cărţi publicate în edituri recunoscute în străinatate
c11=punctaj pentru numărul de pagini ale cărţii publicate în edituri recunoscute de
CNCSIS (referinţa este de 100 de pagini la trei ani pentru un autor) (c11=50)
c12=punctaj pentru numărul de pagini ale cărţii publicate în edituri recunoscute din
străinătate (c12=150)
pagin=numărul de pagini ale cărţii in (i=1.. N6.1)
pagiin=numărul de pagini ale cărţii iin (i=1.. N6.2)
Npnr=numărul de pagini de referinţă pentru lucrări la nivel naţional (ex. 200 pag)
Npir=numărul de pagini de referinţă pentru lucrări la nivel internaţional (ex. 200
pag)
Indicatorul n7
Brevete sub protecţie/produse cu drept de propietate intelectuală
n7=c13*N7/(Ncd+Nc) unde:
N7=numărul total de brevete/produse cu drept de propietate intelectuală

c13=punctaj pentru brevet sub protecţie/produs cu drept de propietate intelectuală
(c13=150)
Indicatorul n8
Centre de cercetare sau creaţie artistică acreditate/recunoscute
n8=n8.1*p13+n8.2*p14
n8.1=c14*N8.1/(Ncd+Nc)
n8.2=c15* N8.2/(Ncd+Nc) unde:

N8.1=numărul total de centre de cercetare recunoscute de CNCSIS
N8.2=numărul total de centre de cercetare recunoscute internaţional
c14=punctaj pentru un centru recunoscut de CNCSIS (c14=300)
c15=punctaj pentru un centru recunoscut internaţional (c15=900)
259
Indicatorul n9
Reprezentări în academii, organizaţii profesionale
n9=n9.1*p15+n9.2*p16+n9.3*p17
n9.1=c16*N9.1/Np
n9.2=c17* N9.2/Np
n9.3=c18* N9.3/Np unde:

N9.1=Reprezentări în Academia Română
N9.2=Reprezentări în Academia de Ştiinţe Tehnice, Academia de Ştiinţe Medicale
şi Academia de Ştiinţe Agricole
N9.3=reprezentări în organizaţii profesionale internaţionale (nu acelea în care devii
membru prin plata unei taxe)
c16=punctaj pentru o reprezentare în Academia Română (c16=150)
c17=punctaj pentru o reprezentare în Academia de Ştiinte Tehnice, Academia de
Ştiinte Medicale şi Academia de Ştiinte Agricole (c17=100)
c18=punctaj pentru o reprezentare în organizaţii profesionale internaţionale (nu
acelea în care devii membru prin plata unei taxe) (c18=50)
Indicatorul n10
Premii la nivel naţional: premiile Academiei Române, premiile acordate de
CNCSIS şi premiile acordate de Uniunile de Creaţie (UNITER, Uniunea
Scriitorilor, UAP, UCMR, UCIN, UAR)
n10=c19*N10/(Ncd+Nc) unde:
N10=numărul total de premii la nivel naţional (Academia Română, CNCSIS,

Uniunile de Creaţie)
c19=punctaj pentru un premiu naţional (c19=1000)
Pe baza studiului procesului decizional curent şi a cerinţelor informaţionale ale

activităţii de evaluare a cercetării ştiinţifice în învăţământul universitar, în figura
9.5 se propune un model de afaceri (sub forma unui cub de informaţii) pentru
evaluarea activităţii de cercetare. Utilizând acest mod de prezentare se pot realiza
analize de tip suport de decizie cum ar fi: analiza comparativă între încărcarea
cadrelor didactice şi rata publicaţiilor, analiza ratei publicaţiilor (număr de
publicaţii/cadru didactic), încărcarea cadrelor didactice, analiză de tip top 3
(primele trei facultăţi/centre de cercetare în funcţie de indicatorii de performanţă),
evoluţia grafică a personalului implicat în activitatea de cercetare etc.
260
9.3 Proiectarea modelului multidimensional conceptual

Aşa cum s-a prezentat în capitolul 5, există două metode pentru proiectarea
modelului multidimensional conceptual şi anume: metoda orientată pe cereri şi
metoda orientată pe sursele de date. În cazul activităţii de cercetare în
învăţământul superior, se va utiliza metoda orientată pe cereri. Această metodă este
mai adecvată, deoarece în etapa anterioară s-au pus în evidenţă indicatorii de
performanţă corespunzători. De asemenea, sistemul informatic tranzacţional sursă
se va proiecta în paralel cu sistemul suport de decizie.
Măsuri:
Număr de publicaţii
Rata publicaţiilor
Institut (Universitate) Timp
Număr de proiecte
Valoarea contractată (lei)
Valoarea contractată (dolari)
Număr de cadre didactice
implicate în cercetare etc
Centre Publicaţie
Cubul n-dimensional
Dimensiunea
Tip_proiect
Figura 9.5 Cubul n-dimensional de informaţii pentru activitatea de cercetare în

învăţământul universitar
9.3.1 Identificarea variabilelor
Pe baza studiului şi analizei activităţii pentru care se construieşte sistemul, se

identifică variabilele activităţii respective (se specifică şi granulaţia acestor
variabile) şi anume:
Personalul implicat în activitatea de cercetare şi anume: numărul de cadre
didactice antrenate în cercetare la nivel de catedră şi an (nrcadre), numărul
de cadre tesa (cercetători) antrenate în cercetare la nivel de catedră şi an
(nrtesa), numărul de doctoranzi antrenaţi în cercetare la nivel de catedră şi
261
an (nrdoct), numărul de studenţi antrenaţi în cercetare la nivel de catedră şi

an (nrstud_cer);
Numărul de proiecte pe tip de proiect, an, catedră (nrproiecte).
Numărul de proiecte pe tip de proiect, an, centre de cercetare (nrpro).
Numărul de publicaţii la nivel de catedră, tip de publicaţie şi an (nrpub).
Numărul de studenţi la nivel de facultate şi an (nrstud), numărul de cadre
didactice la nivel de catedră şi an (Ncd).
Valoarea contractată în dolari, pe tip de proiect, an, catedră
(Valoare_dolari).
Valoarea contractată în lei, pe tip de proiect, an, centru de cercetare
(Vallei).
Valoarea contractată în dolari, pe tip de proiect, an, centru de cercetare
(Valdol).
Valoarea contractată în lei, pe tip de proiect, an, catedră (Valoare_lei).
Numărul de conducători de doctorat (N dcd ), numărul de teze de doctorat
finalizate (N ftd ), numărul de brevete (N7), numărul de reprezentări în
Academia Română (N91), numărul de reprezentări în Academia de Ştiinţe
Tehnice, Academia de Ştiinţe Medicale şi Academia de Ştiinţe Agricole
(N92), numărul de reprezentări în organizaţii profesionale internaţionale
(N93) şi numărul de premii la nivel naţional (N10), la nivel de catedră şi
an.
Pentru fiecare variabilă se vor stabili factorii de care depinde sau în funcţie de
care variază (dimensiunile cubului) şi anume:
Variabilele nrcadre, nrtesa, nrdoct, nrstud_cer, Ncd, nrstud, N dcd , N ftd , N7,
N91, N92, N93, N10 au ca dimensiuni: Timp, Institut (universitate).
Variabilele nrproiecte, valoare_lei, valoare_dolari au ca dimensiuni:
Timp, Institut, Tip_proiect.
Variabilele nrpro, vallei, valdol au ca dimensiuni: Timp, Centru,
Tip_proiect.
Variabila nrpub are ca dimensiuni: Timp, Institut, Publicaţie.
De asemenea, fiecare variabilă va fi analizată, în scopul de a determina dacă
este aditivă, semiaditivă sau neaditivă. Toate variabilele definite sunt aditive.
9.3.2 Identificarea dimensiunilor şi a ierarhiilor
Se identifică următoarele dimensiuni ierarhice: Publicaţie, Institut

(universitate) şi Tip_proiect. Dimensiunea Institut este o dimensiune cu structură
ierarhică cu nivelurile: Institut, Facultate şi Catedră. Dimensiunea Publicaţie are o
structură ierarhică cu nivelurile: Total_publicaţii, Carte (Cărţi publicate în edituri
româneşti recunoscute de CNCSIS-CCNCSIS, Cărţi publicate în edituri româneşti
recunoscute în străinătate-CS, Cărţi publicate în edituri româneşti nerecunoscute
CNCSIS-CNER), Articole (Articole publicate în reviste româneşti recunoscute
262
CNCSIS-ACNCSIS, Articole publicate în reviste cotate ISI-AISI, Articole publicate

în reviste nerecunoscute-ANER, Lucrări publicate în reviste din străinătate cu
recenzori-AS), Conferinţe (Comunicări în volumele conferinţelor ştiinţifice
naţionale-CN, lucrări publicate în volumele conferinţelor internaţionale-CI)
(figura 9.6).
Revistele româneşti sunt recunoscute de CNCSIS pe baze unor criterii de
evaluare şi anume: “includerea revistei în baza de date a unui institut de evaluare
scientometrică, includerea revistei în cataloage centralizatoare de rezumate pe
domeniu, difuzarea în străinatate a revistei, factorul de impact pe plan
internaţional etc” [http://www.cncsis.ro].
Total_publicaţii
carte conferinţe articole
CS CNER CCNCSIS CN CI ACNCSIS ANER AISI AS
Figura 9.6 Dimensiunea ierarhică Publicaţie (ierarhia este strictă)
Revistele cotate de Institutul pentru Ştiinţa Informării (ISI) din Philadelphia

sunt grupate în trei indexuri în funcţie de domeniile ştiinţifice abordate şi anume:
Science Citation Index (SCI), Social Citation Index (SSCI) şi Arts&Humanities
Citation Index (A&HCI) [http://www.cncsis.ro].
Editurile româneşti sunt recunoscute de CNCSIS pe baza unor criterii de
evaluare şi anume: “pondere însemnată din activitate în domeniul cărţii ştiinţifice
şi manualelor universitare, publicarea a minimum 50 de cărţi ştiinţifice sau
manuale universitare în ultimii 5 ani, premii obţinute de editură la saloane şi
târguri de carte etc” [http://www.cncsis.ro].
Dimensiunea Tip_proiect are o structură ierarhică cu nivelurile: Total,
Contracte cu companii din ţară (Alţii), Academia Română (ACAD), CNCSIS
(GR_A, GR_AT, GR_E, GR_Td, GR_Bd), Orizont 2000 (O2000), RO-4096 (PU,
PEP, PC, D, C, T, B), proiecte nefinanţate (NF), proiecte finanţate de MEC prin
programe din planul naţional de cercetare-dezvoltare şi inovare(CERES, MENER,
INFRAS, MANATECH), proiecte de cercetare internaţională (PI).
Dimensiunea Timp nu are o structură ierarhică, este formată numai din ani
(2000, 2001, 2002, 2003). Dimensiunea Centru se consideră neierarhică, deşi poate
avea o structură ierarhică cu nivelurile: Institut şi Centre de cercetare (într-o
universitate pot exista unul sau mai multe centre de cercetare).
263
9.3.3 Definirea cuburilor n-dimensionale sau a structurii multicub
Pentru a reduce fenomenul de împrăştiere s-a ales o structură multicub cu

patru cuburi n-dimensionale şi anume:
cubul n-dimensional cu dimensiunile Timp, Institut, Tip_proiect şi
variabilele valoare_lei, valoare_dolari, nrproiecte;
cubul n-dimensional cu dimensiunile Timp, Institut şi variabilele nrcadre,
nrtesa, nrdoct, nrstud_cer, N dcd , N ftd , N7, N91, N92, N93, N10;
cubul n-dimensional cu dimensiunile Timp, Tip_proiect, Centru şi
variabilele vallei, valdol, nrpro;
cubul n-dimensional cu dimensiunile Timp, Publicaţie, Institut şi variabila
nrpub.
Structura multicub are o singură dimensiune globală, dimensiunea Timp.
9.3.4 Rafinarea modelului multidimensional
Este necesar a se stabili şi dimensiunile care se modifică frecvent şi care este

rata de modificare a fiecărei dimensiuni. Cele mai frecvente modificări apar în
dimensiunea Tip_proiect, iar rata ei de modificare poate fi de cel puţin un an.
Deoarece dimensiunea Tip_proiect are puţini membri, se va utiliza ca metodă de
modelare a modificărilor care vor apare, metoda de a păstra o singură dimensiune
în cub, ce reprezintă reuniunea versiunilor.
O componentă cheie a modelării multidimensionale este definirea formulelor şi
în special a formulelor de agregare. Se vor defini următoarele formule de calcul şi
anume:
rata publicaţiilor (numărul mediu de publicaţii pe cadru didactic):
rata=nrpub/nrcadre
încărcare cadre didactice: încărcare=nrstud/Ncd
procent de participare la cercetare : procent=nrcadre/Ncd
De asemenea, se vor realiza agregări după dimensiunile: Tip_proiect, Institut,
Publicaţie. Pentru fiecare dimensiune se stabilesc nivelurile de granulaţie şi anume:
Dimensiunea Institut are nivelul de granulaţie catedra.
Dimensiunea Publicaţie are nivelul de granulaţie subcategorie de
publicaţie (cărţi publicate în edituri româneşti recunoscute de CNCSIS,
cărţi publicate în edituri româneşti recunoscute în străinătate, cărţi
publicate în edituri româneşti nerecunoscute CNCSIS etc).
Dimensiunea Timp are nivelul de granulaţie anii calendaristici (2000, 2001,
2002 etc).
Dimensiunea Tip_proiect are nivelul de granulaţie tipurile de proiecte
finanţate (granturi anuale de tip A, de tip AT etc).
Dimensiunea Centru are nivelul de granulaţie centru de cercetare.
Conform modelului propus de Blanschka, modelul multidimensional
conceptual pentru activitatea de cercetare are următoarele componente (figura 9.7):
264
Colecţie de fapte: FS_1

Niveluri: L={tip_proiect, finanţator, catedra, facultate, institut, an}
Atribute: A={valoare_lei, valoare_dol, nrproiecte}
Funcţia: gran (FS_1)={catedra, an, tip_proiect} care asociază FS_1
cu nivelurile de bază ale dimensiunilor
Relaţiile între niveluri: class={(catedra, facultate), (facultate, institut),
(tip_proiect, finanţator)}
Funcţiile: attr(“valoare_lei”)=FS_1, attr(“valoare_dol”)=FS_1 etc.
Colecţie de fapte: FS_2
Niveluri: L={tip_proiect, finanţator, centre, an}
Atribute: A={vallei, valdol, nrpro}
Funcţia: gran (FS_2)={centre, an, tip_proiect} care asociază FS_2
cu nivelurile de bază ale dimensiunilor
Relaţiile între niveluri: class={(tip_proiect, finanţator)}
Funcţiile: attr(“vallei”)=FS_2, attr(“valdol”)=FS_2 etc.
Colecţie de fapte: FP_1
Niveluri: L={subcategorie, categorie, catedra, facultate, institut,
an}
Atribute: A={nrpub}
Funcţiile: gran (FP_1)={catedra, an, subcategorie} care asociază
FP_1 cu nivelurile de bază ale dimensiunilor
Relaţiile între niveluri: class={(catedra, facultate), (facultate, institut),
(subcategorie, categorie)}
Funcţiile: attr(“nrpub”)=FP_1
Colecţie de fapte: FP_2
Niveluri: L={catedra, facultate, institut, an}
Atribute: A={nrcadre, nrtesa, nrstud, Ncd, nrstud_cer, nrdoct, N dcd ,
N ftd , N7, N91, N92, N93, N10 }
Funcţiile: gran(FP_2)={catedra, an} care asociază FP_2 cu nivelurile
de bază ale dimensiunilor
Relaţiile între niveluri: class={(catedra, facultate), (facultate, institut)}
Funcţiile: attr(“nrcadre”)=FP_2, attr(“nrtesa”)=FP_2 etc
Modelul entitate-asociere al sistemului informatic tranzacţional este prezentat
în figura 9.8. Schema conceptuală a bazei de date relaţională sursă este următoarea
(cheile primare sunt subliniate, pentru fiecare cheie externă este prezentată schema
referită):
INSTITUŢII (UNIVERSITĂŢI)(codinst, denumire, adresa)
FACULTĂŢI (codfac, denfac, codinst: INSTITUŢII)
CATEDRE (codcat, dencat, codfac: FACULTĂŢI)
PERSOANE (codp, nume, funcţia, codcat: CATEDRE, doctorat, imagine)
PERS_PUB (codp: PERSOANE, codpub: PUBLICAŢII, nrpagini)
PUBLICAŢII (codpub, denpub, an, codsubcat: CATEGORII, editura, nrpag)
CATEGORII (codsubcat, densubcat, categ)
265
PERS_PROI (codp: PERSOANE, cod: PROIECTE, nrore)

PROIECTE (cod, denumire, codp: PERSOANE, director, an, denetapa, codtip:
TIPURI_PROIECT, codc: CENTRE, vallei, valdol)
TIPURI_PROIECT (codtip, denumire)
CENTRE (codc, denumire, director, domeniu, acreditare (organizaţie),
an_acreditare, tip_acreditare, nivel, universitate, facultate, catedra, coordonate,
direcţii)
REPREZENTĂRI (codr, codp:PERSOANE, an_reprezentare, denumire_academie)
PREMII (codpr, titlu, codp:PERSOANE, an_premiu, denumire_organizaţie)
TEZE (codt, titlu, nume_doctorand, codp:PERSOANE, an_înmatriculare,
an_susţinere)
BREVETE (titlu, codp:PERSOANE, an_brevet)
Pentru a păstra o istorie a numărului de studenţi şi a numărului de cadre didactice
se vor adăuga două tabele istorice:
STUD_FAC (an, codfac: FACULTĂŢI, nrstud)
NRPROF_CAT (an, codcat: CATEDRE, Ncd)
9.4 Proiectarea logică

Modelul multidimensional conceptual proiectat în etapa anterioară poate fi
implementat atât într-o bază de date relaţională (o soluţie ROLAP) cât şi într-o
bază de date multidimensională (o soluţie MOLAP). Dacă se adoptă o soluţie
ROLAP, se va proiecta schema stea a bazei de date.
S-au identificat următoarele tabele de fapte:
Tabela de fapte FS_1 (codcat, codtip, an, nrproiecte: number(3), valoare_lei:
number(20), valoare_dol: number(10)) cu tabelele de dimensiuni: Tipuri_proiect
(codtip: varchar2(8), denumire: varchar2(100), finanţator: varchar2(8)), Timp (an:
varchar2(4)), Instituţii(Universităţi) (codcat: varchar2(5), dencat: varchar2(60),
codfac: varchar2(5), denfac: varchar2(60), codinst: varchar2(5), deninst:
varchar2(60)) (figura 9.9 şi figura 9.10).
Tabela de fapte FS_2 (codc, codtip, an, nrpro: number(3), vallei: number(20),
valdol: number(10)) cu tabelele de dimensiuni: Tipuri_proiect (codtip: varchar2(8),
denumire: varchar2(100), finanţator: varchar2(8)), Timp (an: varchar2(4)), Centre
(codc: varchar2(12), denumire: varchar2(100)).
Tabela de fapte FP_1 (codcat, an, codsubcat, nrpub: number(3)) cu
dimensiunile: Instituţii (codcat: varchar2(5), dencat: varchar2(60), codfac:
varchar2(5), denfac: varchar2(60), codinst: varchar2(5), deninst: varchar2(60)),
Timp (an: varchar2(4)), Publicaţii (codsubcat: varchar2(8), densubcat:
varchar2(70), categ: varchar2(10)) (figura 9.11).
Tabela de fapte FP_2 (codcat, an, nrcadre: number(3), nrtesa: number(3),
nrstud_cer: number(3), nrdoct: number(3), nrstud: number(3), ncd: number(3),
N dcd : number(3), N ftd : number(3), N7: number(3), N91: number(3), N92:
number(3), N93: number(3), N10: number(3) cu dimensiunile: Timp (an:
varchar2(4)), Instituţii (Universităţi) (codcat: varchar2(5), dencat: varchar2(60),
266
codfac: varchar2(5), denfac: varchar2(60), codinst: varchar2(5), deninst:

varchar2(60)) (figura 9.11).
Valoare_lei an valoare_dol
nrproiecte
FS_1
finanţator tip_proiect catedra facultate universitate
an
nrpub
FP_1
categorie subcat catedra facultate universitate
nrcadre ncd
nrtesa nrstud
an FP_2 catedra facultate universitate
d N10
N cd
N7 Nrstud_cer
nrdoct
finanţator Tip_proiect FS_2

centru
vallei
an nrpro
valdol
Figura 9.7 Modelul multidimensional conceptual pentru activitatea de cercetare

în învăţământul universitar
267
Figura 9.8 Modelul entitate asociere
Figura 9.9 Schema fulg de zăpadă cu tabela de fapte FS_1
268
Figura 9.10 Schema stea cu tabela de fapte FS_1
Figura 9.11 Schema stea cu tabelele de fapte FP_1 şi FP_2
269
9.5 Proiectarea fizică

Pentru a stabili aproximativ dimensiunea bazei de date relaţionale (soluţia
ROLAP), s-a utilizat modul de calcul propus de Ralph Kimball [KIMB96]. Autorul
consideră că fiecare atribut are maxim 4 bytes. De asemenea, consideră că pentru
tabelele de fapte cu un număr mic de atribute, dimensiunea indexului principal
creat pe cheia compusă a tabelei va fi de 60-80% din dimensiunea tabelei de fapte.
Pentru tabele de fapte cu multe atribute (15-20 de atribute), dimensiunea indexului
principal este de 30-50% din dimensiunea tabelei de fapte. De asemenea, tabelele
de dimensiuni şi indecşii asociaţi vor fi foarte mici în comparaţie cu tabela de fapte
şi indexul principal aferent.
Pentru cazul nostru, s-au utilizat nivelurile de granulaţie stabilite în etapa 9.3,
iar dimensiunea bazei de date relaţionale s-a calculat aproximativ astfel:
Dimensiunea Timp : 3 ani=3*365 zile=1095 zile
Dimensiunea Instituţii (Universităţi) : 31 catedre
Dimensiunea Centre : 8 centre (cel puţin)
Dimensiunea Tip_proiect : 20 tipuri de proiect
Dimensiunea Publicaţii : 9 tipuri de publicaţii
Numărul de înregistrări din tabela de fapte FS_1 = 1095*31*20= 678900
înregistrări
Numărul de atribute cheie pentru tabela de fapte FS_1 = 3
Numărul de atribute din tabela de fapte FS_1 = 3
Numărul total de atribute din tabela de fapte FS_1 = 6
Dimensiunea tabelei de fapte FS_1=678900*6 atribute* 4 bytes/atribut= 16293600
bytes
Dimensiunea indexului principal pe cheia compusă a tabelei= 70%* 16293600=
11405520 bytes
Numărul de înregistrări din tabela de fapte FS_2 = 1095*20*8= 175200 înregistrări

Numărul de atribute cheie pentru tabela de fapte FS_2 = 3
Numărul de atribute din tabela de fapte FS_2 = 3
Numărul total de atribute din tabela de fapte FS_2 = 6
Dimensiunea tabelei de fapte FS_2 = 175200*6 atribute* 4 bytes/atribut = 4204800
bytes
Dimensiunea indexului principal pe cheia compusă a tabelei= 70%* 4204800 =
2943360 bytes
Numărul de atribute cheie pentru tabela de fapte FP_1 = 3

Numărul de atribute din tabela de fapte FP_1 = 1
Numărul total de atribute din tabela de fapte FP_1 = 4
Numărul de înregistrări din tabela de fapte FP_1 = 1095* 9*31= 305505
înregistrări
Dimensiunea tabelei de fapte FP_1 = 305505*4*4 = 4888080 bytes
Dimensiunea indexului pricipal = 70%*4888080= 3421656 bytes
270
Numărul de atribute cheie pentru tabela de fapte FP_2 = 2

Numărul de atribute din tabela de fapte FP_2 = 13
Numărul total de atribute din tabela de fapte FP_2 = 15
Numărul de înregistrări din tabela de fapte FP_2 = 1095* 31= 33945 înregistrări
Dimensiunea tabelei de fapte FP_2 = 33945*15*4 = 2036700 bytes
Dimensiunea indexului principal = 70%*2036700 = 1425690 bytes
Dimensiunea totală aproximativă =

2036700+1425690+3421656+4888080+2943360+4204800+16293600+11405520
= 46619406 bytes~50 Mb.
9.6 Construirea sistemului OLAP

Cu scopul de a furniza managerilor informaţiile necesare pentru a asigura
calitatea activităţii de cercetare ştiintifică în învăţământul universitar, datele la
nivel de detaliu sunt stocate într-o bază de date relaţională, iar datele agregate sunt
stocate în baza de date multidimensională.
Pentru a crea baza de date multidimensională, s-a utilizat utilitarul Oracle
Express Administrator 6.3.2. Baza de date multidimensională Evaluare_final are
următoarele dimensiuni:
Dimensiunea Centre (centre de cercetare);
Dimensiunea Instituţii (universităţi) este o dimensiune cu totaluri incluse şi
conţine catedrele şi facultăţile care participă la cercetare;
Dimensiunea Nivel_institut (niveluri în ierarhia institutului);
Dimensiunea Publicaţii (categorii şi subcategorii de publicaţii) este o
dimensiune cu totaluri incluse;
Dimensiunea Timp (anii pentru analiză);
Dimensiunea Tip_proiect (tipul proiectului) este o dimensiune cu totaluri
incluse.
S-au definit următoarele variabile:
nrcadre (numărul de cadre didactice antrenate în cercetare la nivel de
catedră şi an).
nrstud_cer (numărul de studenţi antrenaţi în cercetare la nivel de catedră şi
an).
nrdoct (numărul de doctoranzi antrenaţi în cercetare la nivel de catedră şi
an).
nrtesa (numărul de cadre tesa antrenate în cercetare la nivel de catedră şi
an).
nrproiecte (numărul de proiecte de cercetare la nivel de catedră, tip de
proiect, an). Aceasta variabilă oferă informaţii despre: indicatorul N1
(granturi CNCSIS şi ale Academiei Române), la nivel de catedră şi an,
indicatorul N2 (numărul de contracte de cercetare internaţionale), la nivel
271
de catedră şi an şi indicatorul N3 (numărul de contracte cu companii din

ţară şi PNCD), la nivel de catedră şi an.
nrpro (numărul de proiecte de cercetare la nivel de centru de cercetare, tip
de proiect, an). Centrele de cercetare sunt constituite la nivel de catedră,
facultate sau universitate. Există totuşi catedre sau facultăţi care nu sunt
incluse într-un centru de cercetare. De aceea s-a considerat necesar a se
defini două variabile: nrproiecte şi nrpro.
nrpub (numărul de publicaţii la nivel de catedră, tip de publicaţie şi an).
Aceasta variabilă oferă informaţii despre: indicatorul N5.1 (număr de
articole publicate în reviste recunoscute CNCSIS), la nivel de catedră şi an,
indicatorul N5.2 (număr de articole publicate în reviste cotate ISI), la nivel
de catedră şi an, indicatorul N6.1 (cărţi publicate în edituri recunoscute de
CNCSIS), la nivel de catedră şi an şi indicatorul N6.2 (cărţi publicate în
edituri recunoscute din străinatate), la nivel de catedră şi an.
nrstud (numărul de studenţi la nivel de facultate şi an).
ncd (numărul de cadre didactice la nivel de catedră şi an)
valoare_dolari (valoarea contractată în dolari la nivel de catedră, tip de
proiect şi an). Aceasta variabilă oferă informaţii despre indicatorul Vtci
(valoare contracte internaţionale) la nivel de catedră şi an.
vallei (valoarea contractată în lei la nivel de centru, tip de proiect şi an).
valoare_lei (valoarea contractată în lei la nivel de catedră, tip de proiect şi
an). Această variabilă oferă informaţii despre: indicatorul Vtgn (valoare
granturi naţionale) la nivel de catedră şi an şi indicatorul Vtcn (valoare
contracte cu companii din ţară şi PNCD), la nivel de catedră şi an.
valdol (valoarea contractată în dolari lei la nivel de centru, tip de proiect şi
an).
De asemenea, se pot defini şi variabilele N dcd (număr de conducători de
doctorat), N ftd (număr de teze de doctorat finalizate), N7 (număr de brevete), N91
(numărul de reprezentări în Academia Română), N92 (număr de reprezentări în
Academia de Ştiinţe tehnice, Academia de Ştiinţe Medicale şi Academia de Ştiinţe
Agricole), N93 (număr de reprezentări în organizaţii profesionale internaţionale şi
N10 (număr de premii), la nivel de catedră şi an.
S-au definit următoarele formule:
rata =nrpub/nrcadre
încărcare=nrstud/ncd
procent=nrcadre/ncd
S-au definit următoarele relaţii între dimensiuni :
inst_inst (relaţia construită pe dimensiunea Instituţii)
niv_inst (relaţia între dimensiunea Nivel_Institut şi dimensiunea Instituţii)
tip_tip (relaţia construită pe dimensiunea Tip_proiect)
pub_pub (relaţia construită pe dimensiunea Publicaţii)
centre_centre (relaţia construită pe dimensiunea Centre)
S-au definit de asemenea, următoarele seturi de valori:
272
cat_set (setul de catedre)

fac_set (setul de facultăţi)
centre_set (setul de centre de cercetare)
tip_set (setul de tipuri de proiecte internaţionale)
tip1_set (setul de tipuri de proiecte naţionale)
Figura 9.12 prezintă structura logică a bazei de date multidimensională
Evaluare_final.
Pentru definirea dimensiunilor, a variabilelor, relaţiilor, formulelor de calcul şi
a seturilor de valori s-au utilizat programe scrise în limbajul Express şi anume:
“definire baza de date
database create evaluare_final
“definire dimensiunea Instituţii
define institutii dimension text
ld Catedrele şi facultăţile care participă la cercetare
maintain institutii add ‘ASE’ ‘FSELS’ ‘COM’ ‘EG’ ‘EGPAA’ ‘CIG’ ‘FABBV’
‘CSIE’ ‘FREI’ ‘DPPD’ ‘COLB’ ‘FMAN’ ‘COLBU’ ‘CO’ ‘TS’ ‘MMC’ ‘DR’
‘AEF’ ‘MON’ ‘FIN’ ‘CIIF’ ‘CACG’ ‘IG’ ‘MAN’ ‘EC’ ‘TI’ ‘CDE’ ‘EPE’ ‘EFS’
‘IEG’ ‘LRCA’ ‘LGCA’ ‘REI’ ‘TPAA’ ‘SELS’ ‘CIB’ ‘IE’ ‘STAT’ ‘AS’ ‘EM’
‘SSDI’ ‘FPS’
“definire dimensiunea Centre
define centre dimension text
ld centre de cercetare
maintain centre add 'CCAEMA' 'CNESMC' 'CEAPE' 'CSCIG' 'CCMP' 'CEAPR'
'CEFIMO' 'ECOINFOSOC'
describe centre
“definire dimensiunea Nivel_institut
define Nivel_institut dimension text
ld Niveluri în ierarhia institutului
maintain Nivel_institut i add ‘UNIVERSITATI’ ‘FACULTATI’ ‘CATEDRE’
“definire dimensiunea Timp
define timp dimension text
ld Anii pentru analiză
maintain timp add ‘2000’ ‘2001’ 2002’ ‘2003’
“definire dimensiunea Publicaţii
define Publicaţii dimension text
ld Publicatii cu totaluri incluse
maintain publicatii add 'CCNCSIS' 'CS' 'CNER' 'AS' 'ACNCSIS' 'AISI' 'ANER'
'CN' 'CI' 'CARTE' 'ARTICOLE' 'CONFERINTE'
“definire dimensiunea Tip_proiect
define Tip_proiect dimension text
ld Tipul proiectului
maintain tip_proiect add 'GR_A' 'GR_AT' 'GR_E' 'GR_TD' 'GR_Bd' 'PU' 'PEP' 'D'
'C' 'T' 'B' 'PC' 'CERES' 'MENER' 'MANATECH' 'INFRAS' 'ALTII' 'ACAD'
'CNCSIS' 'O2000' 'RO-4096' 'PNCDI' 'NF' 'PI'
273
“definire variabilă nrcadre

define nrcadre integer <timp, institutii>
ld numărul de cadre didactice antrenate în cercetare la nivel de catedră şi an
describe nrcadre
“definire variabilă nrproiecte
define nrproiecte shortinteger <timp, tip_proiect, institutii>
ld număr de proiecte pe tip, an, instituţii
describe nrproiecte
“definire variabilă valoarea_dolari
define valoarea_dolari integer <timp, tip_proiect, institutii>
ld valoarea contractată (dolari)
describe valoarea_dolari
Figura 9.12 Structura logică a bazei de date multidimensională
“definire variabilă nrpro

define nrpro variable shortinteger <timp, tip_proiect, centre>
ld numărul de proiecte pe tip, an, centre
describe nrpro
“definire variabilă n1
define n1 variable shortinteger <timp, institutii>
ld numărul de granturi naţionale câştigate (CNCSIS şi Academia Română) la nivel
de catedră şi an
describe n1
“definire variabilă n2
274
define n2 variable shortinteger <timp, institutii>

ld numărul de contracte de cercetare internaţionale la nivel de catedră şi an
describe n2
“definire variabilă ncd
define ncd variable shortinteger <timp, institutii>
ld numărul de cadre didactice la nivel de catedră şi an
describe ncd
“definire variabilă nrdoct
define nrdoct variable shortinteger <timp, institutii>
ld numărul de doctoranzi implicaţi în activitatea de cercetare
describe nrdoct
“definire variabilă nrpub
define nrpub variable shortinteger <timp, institutii, publicatii>
ld numărul de publicaţii la nivel de catedră, tip de publicaţie şi an
describe nrpub
“definire variabilă nrstud_cer
define nrstud_cer variable shortinteger <timp, institutii>
ld numărul de studenţi implicaţi în activitatea de cercetare
describe nrstud_cer
“definire variabilă nrstud
define nrstud variable shortinteger <timp, institutii>
ld numărul de studenţi la nivel de facultate şi an
describe nrstud
“definire variabilă nrtesa
define nrtesa variable shortinteger <timp, institutii>
ld numărul de cadre tesa antrenate în cercetare la nivel de catedră şi an
describe nrtesa
“definire variabilă valdol
define valdol variable integer <timp, tip_proiect, centre>
ld valoarea contractată(dolari) pe centre
describe valdol
“definire variabilă vallei
define vallei variable decimal <timp, tip_proiect, centre>
ld valoarea contractată(lei) pe centre
describe vallei
“definire variabilă valoare_lei
define valoare_lei variable decimal <timp, tip_proiect, institutii>
ld valoare contractată(mil lei)
describe valoare_lei
“definire variabilă vtci
define vtci variable integer <timp, institutii>
ld valoarea contractelor internaţionale la nivel de catedră şi an
describe vtci
“definire variabilă vtgn
275
define vtgn variable integer <timp, institutii>

ld valoarea granturilor naţionale câştigate la nivel de catedră şi an
describe vtgn
“definire relaţia inst_inst

define inst_inst relation institutii<institutii>
limit institutii to 'CO' 'TS' 'MMC'
inst_inst='COM'
limit institutii to 'DR' 'AEF' 'MON' 'FIN'
inst_inst='FABBV'
limit institutii to 'CIIF' 'CACG' 'IG'
inst_inst='CIG'
limit institutii to 'MAN' 'EC' 'SSDI'
inst_inst='FMAN'
limit institutii to 'TI' 'CDE' 'EPE' 'EFS' 'IEG' 'FPS'
inst_inst='EG'
limit institutii to 'LRCA' 'LGCA' 'REI'
inst_inst='FREI'
limit institutii to 'TPAA'
inst_inst='EGPAA'
limit institutii to 'SELS'
inst_inst='FSELS'
limit institutii to 'CIB' 'IE' 'STAT' 'AS' 'EM'
inst_inst='CSIE'
inst_inst='ASE'
define niv_inst relation nivel_institut<institutii>
limit institutii to cat_set
niv_inst='CATEDRE'
niv_inst='FACULTATI'
limit institutii to 'ASE'
niv_inst='UNIVERSITATI'
“definire relaţia pub_pub

define pub_pub relation publicatii<publicatii>
limit publicatii to 'CCNCSIS' 'CS' 'CNER'
pub_pub='CARTE'
limit publicatii to 'AS' 'ANER' ‘AISI’
pub_pub='ARTICOLE'
limit publicatii to 'CN' 'CI'
pub_pub='CONFERINTE'
limit publicatii to 'CARTE' 'ARTICOLE' 'CONFERINTE'
pub_pub='TOTPUB'
276
“definire relaţia tip_tip

define tip_tip relation tip_proiect<tip_proiect>
limit tip_proiect to 'GR_A' 'GR_AT' 'GR_E' 'GR_TD' 'GR_Bd'
tip_tip='CNCSIS'
limit tip_proiect to 'PU' 'PEP' 'D' 'C' 'T' 'B' 'PC'
tip_tip='RO-4096'
limit tip_proiect to 'CERES' 'MENER' 'MANATECH' 'INFRAS'
tip_tip='PNCDI'
limit tip_proiect to 'ALTII' 'ACAD' 'CNCSIS' 'O2000' 'RO-4096' 'PNCDI' 'NF' 'PI'
tip_tip='TOTAL'
“definire relaţia centre_centre

define centre_centre relation centre<centre>
limit centre to 'CCAEMA' 'CNESMC' 'CEAPE' 'CSCIG' 'CCMP' 'CEAPR'
centre_centre='ASE'
“definire relaţia niv_inst

define niv_inst relation nivel_institut<institutii>
limit institutii to cat_set
niv_inst='CATEDRE'
niv_inst='FACULTATI'
limit institutii to 'ASE'
niv_inst='UNIVERSITATI'
“definire setul de valori cat_set

define cat_set valueset institutii
ld setul de catedre
limit cat_set to 'CO' 'REI' 'MAN' 'SELS' 'CIB' 'IE' 'STAT' 'AS' 'DR' 'CIIF' 'CACG'
'IG' 'AEF' 'EC' 'TI' 'TPAA' 'CDE' 'MON' 'LRCA' 'TS' 'MMC' 'EPE' 'EFS' 'FIN' 'IEG'
'LGCA' 'EM' 'SSDI' 'FPS'
“definire setul de valori fat_set

define fac_set valueset institutii
ld setul de facultăţi
limit fac_set to 'CSIE' 'FSELS' 'COM' 'EG' 'EGPAA' 'CIG' 'FMAN' 'FABBV'
'FREI' 'DPPD' 'COLB' 'COLBU'
“definire setul de valori tip_set

define tip_set valueset tip_proiect
ld setul de proiecte internaţionale
limit tip_set to 'TOTAL' 'PI' 'RO-4096' 'D' 'PU' 'PEP' 'C' 'T' 'B' 'PC'
277
“definire setul de valori centre_set

define centre_set valueset centre
ld setul de centre
limit centre_set to 'CCAEMA' 'CNESMC' 'CEAPE' 'CSCIG' 'CCMP' 'CEAPR'
“definire setul de valori tip_set1

define tip_set1 valueset tip_proiect
ld setul de proiecte naţionale
limit tip_set1 to 'TOTAL''ALTII' 'ACAD' 'CNCSIS' 'O2000' 'PNCDI' 'NF' 'GR_A'
'GR_
“definire formula de calcul incarcare

define incarcare formula decimal <timp institutii>
limit institutii to fac_set, 'ASE'
eq nrstud/ncd
“definire formula de calcul rata
define rata formula decimal <timp publicatii institutii>
eq nrpub/nrcadre
“definire formula de calcul procent
define procent formula decimal <timp, institutii>
eq nrcadre/ncd
Datele au fost încărcate din baza de date relaţională sursă, a cărei schemă
logică a fost prezentată în etapa 9.3, iar programele de încărcare sunt scrise în
limbajul Express şi prezentate în anexa 1.
Pentru agregarea datelor s-au creat următoarele programe:
“program pentru agregarea variabilei ncd după dimensiunea Instituţii
rollup ncd over institutii using inst_inst
“program pentru agregarea variabilei nrstud după dimensiunea Instituţii
limit institutii to fac_set, 'ASE'
rollup nrstud over institutii using inst_inst
“program pentru agregarea variabilelor nrtesa, nrcadre, nrdoct şi nrstud_cer
după dimensiunea Instituţii
rollup nrtesa over institutii using inst_inst
rollup nrcadre over institutii using inst_inst
rollup nrdoct over institutii using inst_inst
rollup nrstud_cer over institutii using inst_inst
“program pentru agregarea variabilelor nrproiecte, valoare_dolari şi valoare_lei
după dimensiunea Instituţii
rollup nrproiecte over institutii using inst_inst
rollup valoare_dolari over institutii using inst_inst
rollup valoare_lei over institutii using inst_inst
278
“program pentru agregarea variabilelor nrproiecte, valoare_dolari şi valoare_lei

după dimensiunea Tip_proiect
rollup valoare_dolari over tip_proiect using tip_tip
rollup valoare_lei over tip_proiect using tip_tip
rollup nrproiecte over tip_proiect using tip_tip
“program pentru agregarea variabilelor nrpro, valdol şi vallei după dimensiunea
Centre
rollup nrpro_centre over centre using centre_centre
rollup valdol over centre using centre_centre
rollup vallei over centre using centre_centre
“program pentru agregarea variabilelor nrpro, valdol şi vallei după dimensiunea
Centre
rollup valdol over tip_proiect using tip_tip
rollup vallei over tip_proiect using tip_tip
rollup nrpro_centre over tip_proiect using tip_tip
“program pentru agregarea variabilei nrpub după dimensiunea Instituţii
rollup nrpub over institutii using inst_inst
“program pentru agregarea variabilei nrpub după dimensiunea Publicaţii
rollup nrpub over publicatii using pub_pub
“program pentru agregarea variabilelor n1 şi vtgn după dimensiunea Instituţii
rollup n1 over institutii using inst_inst
rollup vtgn over institutii using inst_inst
Interfaţa sistemului OLAP a fost construită utilizând instrumentul Oracle

Express Objects 6.3.2. şi este prezentată în figura 9.13. Interfaţă permite operaţii
specifice OLAP şi anume:
cereri de tip slice şi dice ce fac selecţii în cubul n-dimensional. De
exemplu, numărul de granturi (A, AT, E, Td, Bd) realizate de facultatea
CSIE în perioada 2000-2003;
cereri de tip drill down şi roll up. De exemplu, numărul de granturi (A, AT,
E, Td, Bd) realizate de fiecare catedră în perioada 2000-2003 (cerere de tip
drill down), apoi numărul de granturi realizate de fiecare facultate în
perioada 2000-2003 (se vor agrega valorile variabilei nrproiecte de la
nivelul catedră la nivelul facultate);
cereri de tip top/bottom (de exemplu primele 3 facultăţi după valoarea
contractată în lei, în anul 2000);
rotirea cubului n-dimensional ce permite utilizatorilor să vizualizeze datele
grupate după alte dimensiuni. Cererile de tip drill down şi roll up se pot
combina cu cererile de tip slice şi dice.
279
Figura 9.13 Interfaţa sistemului OLAP
Sistemul OLAP permite următoarele tipuri de analize:

evoluţia grafică a personalului implicat în activitatea de cercetare (figura
9.14). Se alege facultatea sau catedra şi se afişează, tabelar şi grafic,
evoluţia numărului de cadre didactice şi a numărului de cadre tesa, în
perioada 2000-2003. De asemenea, se poate modifica modul de afişare a
variabilelor şi anume pe linii sau coloane;
evoluţia grafică a valorii contractate (lei sau dolari). De exemplu: valoare
contractelor de cercetare (mil.lei) pentru Orizont 2000, valoarea totală a
contractelor de finanţare în perioada 2000-2003, valoarea contractelor de
cercetare (mil lei) în perioada 2000-2003 pe surse de finanţare (figura 9.15)
etc. Se selectează facultatea sau catedra, precum şi tipul de proiect şi se
afişează evoluţia grafică a finanţării pe surse de finanţare, în perioada
2000-2003. Se poate modifica tipul de grafic. Dacă se selectează un
element de dată din grafic, se afişează valoarea lui;
topul primelor trei facultăţi în funcţie de indicatorul ales (figura 9.16).
Dacă se selectează butonul Total (şi se alege anul), se afişează, pentru toate
facultăţile, valoarea contractată (lei sau dolari), precum şi numărul de
proiecte corespunzătoare. Se selectează apoi, butonul Top3 şi se afişează
primele trei facultăţi în funcţie de valorile indicatorului selectat. Dacă se
doresc şi detalii referitoare la tipul de proiecte, se selectează butonul
Tip_Proiect;
280
evoluţia indicatorilor: N1 (figura 9.17), Vtgn, N2, Vtci, N3, Vtcn, N dcd ,
N ftd , N7, N91, N92, N93 şi N10.
evoluţia grafică a numărului de studenţi implicaţi în activitatea de cercetare
(figura 9.18);
încărcarea cadrelor didactice, rata publicaţiilor (figura 9.19);
evoluţia grafică a numărului de publicaţii (include şi evoluţia grafică a
indicatorilor N5.1, N5.2, N6.1, N6.2) (figura 9.20);
procentul de participare la activitatea de cercetare;
evoluţia grafică a numărului de studenţi la nivel de facultate. Se alege
facultatea sau facultăţile, precum şi anul sau anii de analiză şi se afişează
tabelar, evoluţia numărului de studenţi. Tabelul rezultat poate fi exportat în
Excel.
evoluţia grafică a numărului de doctoranzi implicaţi în activitatea de
cercetare;
evoluţia grafică a numărului de proiecte de cercetare. De exemplu: evoluţia
numărului de proiecte în perioada 2000-2003, evoluţia numărului de
proiecte finanţate prin Orizont 2000 în perioada 2000-2003, evoluţia
indicatorului N1, la nivel de catedră, facultate sau universitate, în perioada
2000-2003, evoluţia indicatorului N2, la nivel de catedră, facultate sau
universitate, în perioada 2000-2003, evoluţia indicatorului N3, la nivel de
catedră, facultate sau universitate, în perioada 2000-2003 etc;
Utilizarea modelului multidimensional şi a unei baze de date
multidimensionale permite managerilor să manipuleze datele fără intermediari
(cum ar fi în cazul interogării unui sistem relaţional) şi să identifice mult mai uşor
erorile şi datele care lipsesc, precum şi să le corecteze. Prezentarea
multidimensională a informaţiilor permite managerilor să manipuleze şi să
interpreteze mai uşor aceste informaţii. Se reduce astfel timpul de acces şi efortul
depus.
Toţi managerii, care utilizează sistemul OLAP, vor vizualiza informaţiile din
aceleaşi perspective (modelul multidimensional este proiectat pe baza tipurilor de
cereri şi a scenariilor de analiză stabilite de manageri). Cererile realizate pe bazele
de date relaţionale au diferite rezultate, în funcţie de modul cum sunt ele formulate.
281
Figura 9.14 Evoluţia grafică a personalului implicat în activitatea de cercetare
Figura 9.15 Evoluţia finanţării pe surse de finanţare
282
Figura 9.16 Topul primelor trei facultăţi
Figura 9.17 Evoluţia indicatorului N1
283
Figura 9.18 Evoluţia grafică a numărului de studenţi implicaţi în cercetare
Figura 9.19 Evoluţia ratei publicaţiilor
284
Figura 9.20 Evoluţia numărului de publicaţii
De asemenea, sistemul suport de decizie permite managerilor să vizualizeze

uşor structura bazei de date (dimensiuni, variabile, relaţii, formule) (figura 9.21).
Principalele dezavantaje ale utilizării unei baze de date multidimensionale sunt:
dimensiunea Tip_proiect se poate modifica în funcţie de timp;
se observă de asemenea, că baza de date multidimensională nu permite
cercetătorilor individuali să extragă o listă cu propriile publicaţii. Baza de
date multidimensională stochează numai date agregate (de exemplu
numărul anual de publicaţii de un anumit tip, la nivelul unei facultăţi) şi nu
date atomice. Din acest motiv, se utilizează o bază de date relaţională sursă
care stochează datele de detaliu, integrată cu baza de date
multidimensională care stochează datele agregate. Schema logică a bazei
de date relaţionale sursă a fost prezentată în etapa 9.3.
Cele două sisteme (tranzacţional şi suport de decizie) se completează reciproc,
oferind informaţii complete şi curente. De asemenea, cele două sisteme proiectate
oferă suport şi pentru metodologia de alocare a fondurilor reprezentând finanţarea
de bază a universităţilor, propusă de MEC. Pe baza datelor oferite de sistemul
tranzacţional, se pot determina şi analiza indicatorii utilizaţi pentru măsurarea
nivelului performanţelor în cercetarea ştiinţifică [BULE01]. Schema conceptuală şi
logică a bazei de date relaţionale sursă permite definirea acestor indicatori. De
asemenea, modelul multidimensional conceptual nu trebuie modificat (nu apar noi
dimensiuni).
285
Chiar dacă este unanim acceptată, ideea că indicatorii de performanţă pot fi

utilizaţi pentru evaluarea activităţii de cercetare, totuşi este greu de stabilit un set
de indicatori (măsuri) corespunzători, un mod de a stabili ponderile acestor
indicatori comun pentru toate instituţiile de cercetare şi toate disciplinele, astfel ca
analizele comparative la nivel global să fie corecte şi relevante pentru manageri.
De asemenea, apar probleme legate de colectarea datelor, analiza şi prezentarea
informaţiilor, acurateţea, relevanţa lor, precum şi dacă rezultatul final justifică
efortul depus.
Informaţia însăşi poate fi considerată un instrument puternic pentru
managementul în organizaţie, dar efectele utilizării ei sunt adesea imprevizibile şi
complexe. Asigurarea informaţiilor de calitate poate îmbunătăţi procesul
decizional, deciziile pot fi luate mai uşor, se pot identifica de asemenea, probleme
care până atunci au fost ignorate sau necunoscute.
Codul pentru realizarea interfeţei sistemului OLAP este prezentat în anexa 2,
iar în anexa 3 scriptul SQL pentru definirea structurii bazei de date relaţionale.
Figura 9.21 Sistemul OLAP oferă informaţii despre structura bazei de date
Rezumat
În acest capitol s-a proiectat şi realizat un sistem OLAP. Pentru proiectarea
sistemului OLAP s-a utilizat metodologia propusă în capitolul 5.
De asemenea, s-a propus un model de afaceri, pentru evaluarea activităţii de
cercetare, sub forma unui cub de informaţii, pe baza studiului procesului
286
decizional curent şi a cerinţelor informaţionale ale activităţii de evaluare a

cercetării ştiinţifice în învăţământul universitar.
Pentru proiectarea modelului multidimensional conceptual s-a utilizat metoda
orientată pe cereri.
Cuvinte cheie
Model de afaceri, cub n-dimensional de informaţii, sistem OLAP, metoda
orientată pe cereri, model multidimensional conceptual, structură multicub,
schema stea, schema fulg de zăpadă, tabelă de fapte.
287
Anexa 2
Interfaţă sistemului OLAP a fost realizată cu instrumentul Oracle Express
Objects 6.3.2. Elementele componente ale interfeţei sunt prezentate în figura A2.1.
Figura A2.1 Elementele componente ale interfeţei sistemului OLAP
În această anexă, sunt prezentate cele mai semnificative pagini ale aplicaţiei,
elementele lor componente, precum şi codul scris în limbajul Express. Elementele
componente ale paginii principale pagmain (Text: Evaluarea activităţii de
cercetare universitară) sunt prezentate în figura A2.2. Pagina conţine un meniu
principal menu1, un grup de obiecte grpstatusbar ce include o eticheta label2 şi o
bară de stare, un obiect de tip banner ase (Text: Academia de Studii Economice), un
obiect de tip timer timer1, o figură picturebox2 (File Name: D :\oracle \olap\
OEO632\work\PERSCMP1.BMP) şi o etichetă label1 (Text: Activitatea de
288
Anexa 2
cercetare ştiinţifică este componentă principală a proceselor de învăţământ şi

inovare din). Codul pentru obiectul timer1 este următorul:
Sub AfterTimer ()
if ase.visible=yes then ase.visible=no else ase.visible=yes
End Sub
La evenimentul AfterActivate al paginii pagmain este ataşat următorul cod:

Sub AfterActivate ()
grpStatusBar.SetStatusMsg "Selectati o optiune din meniu"
End Sub
Sub AfterRun (Flags As Integer)
AfterActivate
End Sub
Opţiunile meniului principal sunt prezentate în figurile A2.3, A2.4 şi A2.5.
Figura A2.2 Elementele componente ale paginii Pagmain
289
Figura A2.3 Opţiunile submeniului Indicatori sintetici
Figura A2.4 Opţiunile submeniului Indicatori de performanţă
290
Anexa 2
Figura A2.5 Opţiunile submeniului Help
Opţiunea commanditem1 (Text: Indicatori sintetici) are ataşat următorul cod:

Sub AfterItemSelect ()
Dim tMsg as String
If ( it.ItemStyle = 2) Then
tMsg = " "
ElseIf ( Instr(it.Text, "E&xit") > 0 ) Then
tMsg = "Ieşire din aplicaţie"
Else
If (Instr(it.text, "lei") > 0) or (Instr(it.text, "valuta") > 0) Then
tMsg="Valoarea contractată în "&it.text
else
tMsg = it.text
end if
End If
grpStatusBar.SetStatusMsg tmsg
End Sub
Opţiunea commanditem1 (prima opţiune din submeniul Indicatori sintetici) (Text: :

&Personal implicat în activitatea de cercetare) are ataşat următorul cod:
Sub AfterItemClick ()
Dim tStr as String
291
Dim iPageResult as Integer

iPageResult = evolutie_personal.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem4 (Text: &Doctoranzi implicaţi în activitatea de cercetare)

are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutie_doctoranzi.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem5 (Text: &Studenţi implicaţi în activitatea de cercetare) are

ataşat următorul cod:
Dim tStr as String
iPageResult = evolutie_studenti_cercetare.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem2 (Text: &Evoluţia grafică a personalului implicat în

activitatea de cercetare) are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutie_personal1.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem6 (Text: &Evoluţia grafică a numărului de doctoranzi

implicaţi în activitatea de cercetare) are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutie_doctoranzi_grafic.ShowModal()
pagMain.SetFocus
End Sub
292
Anexa 2
Opţiunea commanditem7 (Text: &Evoluţia grafică a studenţilor implicaţi în

activitatea de cercetare) are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutie_studcerc_grafic.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea Commanditem3 (Text: &Evoluţia grafică a valorii contractate pe

catedre) cu opţiunile commanditem2 (Text: lei) şi commanditem3 (Text: valută):
evolutie_volumul_finantarii_lei.ShowModal
End Sub
Dim tStr as String
iPageResult = evolutie_vol_finantarii_dol.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem14 (Text: &Evoluţia grafică a numărului de proiecte pe

catedre) are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutia_proiecte.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commandcentre (Text: &Evoluţia grafică a numărului de proiecte pe

centre de cercetare) are ataşat următorul cod:
Dim tStr as String
iPageResult = evolutia_proiecte_centre.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commandvaloare (Text: Evoluţia grafică a valorii contractate pe centre

de cercetare) cu opţiunea commandlei (Text: lei) şi opţiunea commanddol (Text:
dolari):
293
Dim tStr as String

iPageResult = evolutia_vallei_centre.ShowModal()
pagMain.SetFocus
End Sub
Dim tStr as String
iPageResult = evolutia_valdol_centre.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem8 (Text: &Top 3 (facultăţi)) are ataşat următorul cod:

Dim tStr as String
iPageResult = top.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commandtopcentre (Text: &Top 3 (centre de cercetare)) are ataşat

următorul cod:
Dim tStr as String
iPageResult = topcentre.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem16 (Text: E&xit) are ataşat următorul cod:

Application.Stop
End Sub
Opţiunea Commanditem3 (Text: Indicatori de performanţă) cu opţiunile:

commanditem2 (Text: &Numărul de studenţi pe facultăţi) şi commanditem5 (Text:
&Evoluţia grafică a numărului de studenţi pe facultăţi) :
Dim tStr as String
iPageResult = linkview1.ShowModal()
pagMain.SetFocus
End Sub
294
Anexa 2
dim tstr as string
dim ipageresult as integer
ipageresult=studenti_grafic.showmodal()
pagmain.setfocus
End Sub
Opţiunea commanditem7 (Text: &Incărcarea cadrelor didactice) are ataşat

următorul cod:
Dim tStr as String
iPageResult = incarcare.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem6 (Text: &Procentul de participare la activitatea de

cercetare) are ataşat următorul cod:
dim tstr as string
dim ipageresult as integer
ipageresult=procentparticipare.showmodal()
pagmain.setfocus
End Sub
Opţiunea commanditem3 (Text: &Afişarea facultăţilor care au un anumit număr de

publicaţii) are ataşat următorul cod:
Dim tStr as String
iPageResult = raportpub1.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem1 (Text: &Articole/cărţi publicate în reviste cotate/edituri

recunoscute) are ataşat următorul cod:
Dim tStr as String
iPageResult =evolutie_publicatii.ShowModal()
pagMain.SetFocus
End Sub
295
Opţiunea commanditem4 (Text: &Rata publicaţiilor) are ataşat următorul cod:

Dim tStr as String
iPageResult = ratapublicatii.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem8 (Text: &Granturi câştigate (evoluţia indicatorului N1))

Dim tStr as String
iPageResult = indicatoruln1.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commandvtgn (Text: &Granturi câştigate (evoluţia indicatorului Vtgn))

Dim tStr as String
iPageResult = indicatorulvtgn.ShowModal()
pagMain.SetFocus
End Sub
Opţiunea commanditem2 (Text: &Baza de date) are ataşat următorul cod:

Dim tStr as String
iPageResult = pgIterator1_1.ShowModal()
pagMain.SetFocus
End Sub
Dim tStr as string, tMsg as String
tMsg = " "
Else
tStr = it.Text
If (Instr(tStr, "...") > 0) Then
tStr = Left$(tStr, Len(tStr) - 3)
End If
tMsg = tStr
296
Anexa 2
End If
grpStatusBar.SetStatusMsg tMsg
End Sub
Opţiunea commanditem18 (Text: &Help) are ataşat următorul cod:

Dim tStr as string, tMsg as String
tMsg = " "
Else
tStr = it.Text
If (Instr(tStr, "...") > 0) Then
tStr = Left$(tStr, Len(tStr) - 3)
End If
tMsg = tstr
End If
grpStatusBar.SetStatusMsg tMsg
End Sub
Opţiunea commanditem19 (Text: &informaţii) are ataşat următorul cod:

pagHelpAbout.ShowModal
End Sub
Opţiunea commanditem1 (Text: Facultăţile din ASE) are ataşat următorul cod:
institutii.showmodal
End Sub
Opţiunea commanditem2 (Text: Proiecte de cercetare) are ataşat următorul cod:

ierarhiaproiecte.showmodal
End Sub
Opţiunea commanditem3(Text: Tipuri de publicaţii) are ataşat următorul cod:

ierarhiapublicatii.showmodal
End Sub
La opţiunea commanditem4 (Text: Regulament) se ataşează o rutină QuickAction şi

anume Launch Application (Commandline: c:\program files\microsoft office
\office\winword.exe d:\proiect\regulament), iar la opţiunea commanditem5 (Text:
Consiliul Ştiinţific) se ataşează o rutină QuickAction şi anume Launch Application
297
(Commandline: c:\program files\microsoft office\ office\ winword.exe d:\ proiect\

consiliul).
Grupul de obiecte Grpstatusbar are ataşat codul:

Sub SetStatusMsg (tMsg As String)
label2.text=tmsg
End Sub
Pagina pagHelpAbout (Text : Despre Aplicaţie) este prezentată în figura A2.6 şi

conţine următoarele elemente: un buton button1 (Text: OK), un obiect de tip banner
banner1 (Text: Aplicaţie pentru evaluarea activităţii de cercetare universitară), o
etichetă label1_1 (Text: Această aplicaţie face o evaluare a activităţii de cercetare
universitară utilizând o serie de indicatori de performanţă propuşi în Metodologia
de alocare a fondurilor reprezentând finanţarea de baza a Universităţilor), un
obiect basecontrol1, un obiect de tip timer timer2.
Figura A2.6 Elementele componente ale paginii PagHelpAbout
Codul ataşat obiectului timer2 este:

Sub AfterTimer ()
if banner1.visible=yes then banner1.visible=no else banner1.visible=yes
End Sub
298
Anexa 2
Pagina pgiterator1_1 (Text: Baza de date) este prezentată în figura A2.7 şi are
următoarele componente: o etichetă label1_3 (Text: Baza de date a aplicaţiei), un
grup de obiecte groupbox1 (Text: Opţiuni) format din două casete de validare
chkvisible (Text: Afişează numai obiectele vizibile utilizatorului, Value: 1-
Checked)) şi chklabels (Text: Utilizează etichetele, Value: 0-Unchecked), o etichetă
label3_1 (Text: Obiectele bazei de date), o etichetă label2_1 (text: Tipuri de
obiecte), două liste lbtypes (unde se vor afişa tipurile de obiecte ale bazei de date)
şi lbobjects (unde se vor afişa obiectele de un anumit tip), o etichetă label3_1_1
(Text: Dimensiuni), o listă lbdims (unde se vor afişa dimensiunile măsurilor) şi o
etichetă label1 (Text: Se selectează obiectele bazei de date pe care dorim să le
afişam (dublu click cu mouse-ul). La evenimentul AfterDblClick al listei lbtypes se
Sub AfterDblClick ()
Dim db as DatabaseFile
Dim iter as DatabaseIterator
Dim desc as String
Dim i as Integer
Dim objType as String
Dim objFlags as Integer
Dim flags as Integer
Dim sort as Integer
Dim useLabels as Integer
Const MB_ICONEXCLAMATION = 48
' Get the database file
On Error Goto haderror
Set Db = DataDictionary.AttachDatabase("EVALUARE_FINAL" )
If Db is Nothing Then Goto haderror
objType = UCase( text )
Select Case ObjType
Case "DIMENSIUNI"
objFlags = dbiOTDimension
Case "FORMULE"
objFlags = dbiOTFormula
Case "VARIABILE"
objFlags = dbiOTVariable
Case "RELATII"
objFlags = dbiOTRelation
End Select
If GroupBox1.chkVisible.Value = 1 Then
flags = dbiOBJUserData
Else
flags = 0
End If
If GroupBox1.chkLabels.Value = 1 Then
299
useLabels = YES
sort = dbiSTLongName
Else
useLabels = NO
sort = dbiSTName
End If
Set iter = db.GetDatabaseIterator( objFlags, flags, sort )
If useLabels = YES Then
call lbObjects.SetItems( iter.GetDescription(-1), , YES )
Else
call lbObjects.SetItems( iter.GetName(-1), , YES )
End If
set lbObjects.iter = iter
Exit Sub
haderror:
Call MsgBox( "EVALUARE_FINAL.DB nu poate fi gasita",
MB_ICONEXCLAMATION, "BAZA APLICATIEI" )
Exit Sub
End Sub
Figura A2.7 Pagina Pgiterator1_1
300
Anexa 2
La evenimentul AfterDblclick al listei lbobjects se ataşează următorul cod:

Sub AfterDblClick ()
Dim dataObj as Object
Dim dimIter as DatabaseIterator
Dim useLabels as Integer
Set dataObj = DataDictionary.GetDatabaseObject( iter.GetName( listindex ) )
If dataObj Is Nothing Then Exit Sub
If GroupBox1.chkLabels.Value = 1 Then useLabels = YES
Set dimIter = dataObj.GetDimensions()
lbDims.Clear
Do While ( dimIter.IsDone() = FALSE )
If useLabels = YES Then
lbDims.AddItem dimIter.GetDescription()
Else
lbDims.AddItem dimIter.GetName()
End If
dimIter.Next
loop
set lbDims.Iter = dimIter
End Sub
Pagina raportpub1 (Text: Facultăţile cu un anumit număr de publicaţii) este

prezentată în figura A2.8 şi are următoarele componente: un buton cmdfetch (Text:
Afişează), un grup de obiecte grpbxdim ce conţine o etichetă label2 (Text:
Selectează tipul publicaţiei), o etichetă label1 (Text: Selectează facultăţile cu un
număr de publicaţii mai mare decât), o casetă de tip text txtcat (în care se va
introduce un număr), o etichetă label3 (Text: Selectează anul), o listă dimlbpub ce
afişează valorile dimensiuniii Publicaţii, o lista dimlbtimp ce afişează valorile
dimensiunii Timp, o casetă de tip text txtoutput (în care se afişează publicaţiile care
satisfac condiţia cerută), un buton cmdhelp (Text: Help). La evenimentul AfterClick
al butonului cmdfetch se ataşează următorul cod:
Sub AfterClick ()
Dim cmd As String
Dim ExpCmd As New ExpressCommand
cmd = "limit publicatii to '" & GrpBxDim.DimLBpub.FocusValueText & "'"
cmd = cmd & ";limit timp to '" & GrpBxDim.DimLBtimp.FocusValueText & "'"
If GrpBxDim.txtcat.[Text] = "" then
GrpBxDim.txtcat.[Text] = 0
End If
cmd = cmd & ";limit institutii to nrpub gt " & GrpBxDim.txtcat.[Text] & ";limit
institutii remove
'ASE''CO''REI''MAN''SELS''CIB''IE''STAT''AS''DR''CIIF''CACG''IG''AEF''EC''TI''
TPAA''CDE''MON''LRCA''TS''MMC''EPE''EFS''FIN''IEG''LGCA''EM''MAR''SSDI
301
' 'FPS'"
If ExpCmd.Execute(cmd) <> true then
MsgBox ExpCmd.Errortext
End If
' se execută comanda şi se afişează rezultatele
cmd = "rpr down institutii nrpub"
If ExpCmd.Execute(cmd) <> true then
txtOutput.text = ExpCmd.ErrorText
Else
txtOutput.text = ExpCmd.GetLog()
End If
'Call ExpressOutput1.Execute()
End Sub
Figura A2.8 Pagina Raportpub1
La evenimentul AfterClick al butonului cmdhelp se ataşează următorul cod:

Sub AfterClick ()
msgbox container.explicatie, 64, me.text
End Sub
Se adaugă o nouă propietate Explicaţie pentru pagina raportpub1 (figura A2.9).
302
Anexa 2
Figura A2.9 Adăugarea unei propietăţi
Pagina linkview1 (Text: Numărul de studenţi la nivel de facultate) este prezentată

în figura A2.10 şi are următoarele componente: o listă linkdimlb ce afişează
valorile dimensiunii Instituţii, un buton btnlink (Text: Link), un buton btnrefresh
(Text: Refresh), o listă dimlbtimp ce afişează valorile dimensiunii Timp, un buton
helpstudenti (Text: Help), un buton cmdexcel (Text: Export Excel), o etichetă
Facultatea, o etichetă Anii, şi un tabel linktable (ce afişează valorile variabilei
nrstud). La evenimentul AfterClick al butonului helpstudenti se ataşează următorul
cod:
Sub AfterClick ()
End Sub
Se defineşte propietatea Explicaţie (Se apasă butonul Link, apoi se selectează

Facultatea şi anul, apoi se apasă butonul Refresh ) a paginii linkview1.
La evenimentul AfterClick al butonului cmdlink se ataşează următorul cod:

Sub AfterClick ()
set LinkDimLB.HighlightSelection = LinkTable.GetSelection("INSTITUTII")
set dimlbtimp.highlightselection=LinkTable.getselection("TIMP")
End Sub
303
Figura A2.10 Pagina Linkview1
La evenimentul AfterClick al butonului cmdrefresh se ataşează următorul cod:

Sub AfterClick ()
call LinkDimLB.RefreshSelection( dlbSELHighlight )
call DimLBtimp.RefreshSelection( dlbSELHighlight )
End Sub
La evenimentul AfterClick al butonului cmdexcel se ataşează două rutine

QuickAction şi anume Export table şi Launch Application.
Pagina evoluţia_proiecte (Text: Evoluţia numărului de proiecte) este prezentată în

figura A2.11 şi are următoarele componente: un buton piegraph (Text: &Pie
Grafic), un buton explain (Text: &Explicaţii), un buton bargraph (Text: &Bar
Graph), o listă dimlbtip ce afişează valorile dimensiunii Tip_proiect, o etichetă
Tip_proiect, o listă dimlbnivel ce afişează valorile dimensiunii Nivel_Institut, o
etichetă Nivel, o listă dimlbinstitut ce afişează valorile dimensiunii Instituţii, o
etichetă Facultăţi/catedre, un buton btnlink (Text: Link), un buton btnrefresh (Text:
Refresh), un tabel table1 şi un grafic graph5 ce vor afişa valorile variabilei
nrproiecte. Tipul graficului se poate modifica. La evenimentul AfterClick al
butonului piegraph se ataşează următorul cod:
Sub AfterClick ()
Graph5.Visible = No
304
Anexa 2
Graph5.GraphType = grGTMultiPieProp
if Graph5.Effect3D = No then
Graph5.Effect3D = Yes
end if
if Graph5!XTitle.Visible = Yes then
Graph5!XTitle.Visible = No
end if
if Graph5!Y1Title.Visible = Yes then
Graph5!Y1Title.Visible = No
end if
Graph5.Visible = Yes
End Sub
Figura A2.11 Pagina Evoluţia_proiecte
La evenimentul AfterClick al butonului bargraph se ataşează următorul cod:

Sub AfterClick ()
Graph5.Visible = No
' se schimbă tipul de grafic
Graph5.GraphType = grGTBarClust
if Graph5.Effect3D = No then
Graph5.Effect3D = Yes
end if
305
if Graph5!XTitle.Visible = Yes then

Graph5!XTitle.Visible = No
end if
if Graph5!Y1Title.Visible = Yes then
Graph5!Y1Title.Visible = No
end if
Graph5.Visible = Yes
End Sub
La evenimentul AfterClick al butonului btnlink se ataşează următorul cod:

Sub AfterClick ()
set DimLBinstitut.HighlightSelection = Table1.GetSelection("INSTITUTII")
set DimLBtip.HighlightSelection = Table1.GetSelection("TIP_PROIECT")
End Sub
La evenimentul AfterClick al butonului btnrefresh se ataşează următorul cod:

Sub AfterClick ()
call DimLBinstitut.RefreshSelection( dlbSELHighlight )
call DimLBtip.RefreshSelection( dlbSELHighlight )
set graph5.datacube=table1.datacube
End Sub
La evenimentul AfterClick al butonului explain se ataşează următorul cod:

Sub AfterClick ()
Dim strMsg as string
strMsg = "Se prezintă evoluţia numărului de proiecte pe tipuri de proiecte, catedre
şi ani." & Chr$(13)
strMsg = strMsg & "Se alege facultatea sau catedra şi tipul de proiect" & Chr$(13)
& chr$(13)
strMsg = strMsg & "Se poate vizualiza evoluţia la nivel de
facultate/catedră/universitate a următorilor indicatori:" & Chr$(13)
strMsg = strMsg & "Numărul de granturi câştigate (CNCSIS, Academia Romana)"
& Chr$(13)
strMsg = strMsg & "Numărul de contracte de cercetare internaţionale" & Chr$(13)
strMsg = strMsg & "Numărul de contracte cu companii din ţară" & Chr$(13)
strMsg = strMsg & "Numărul de contracte obţinute în cadrul PNCD" & Chr$(13)
& Chr$(13)
strMsg = strMsg & "Click pe obiectul ce reprezintă date în grafic şi se afişează
valoarea curentă" & Chr$(13)
strMsg = strMsg & "Se poate modifica şi tipul de grafic" & Chr$(13) & chr$(13)
MsgBox strMsg, 64, Container.[Text]
End Sub
La evenimentul AfterSelect al graficului se ataşează un cod, care afişează valoarea
unui punct al graficului, dacă este selectat cu mouse-ul (figura A2.12):
306
Anexa 2
Sub AfterSelect (SelectType As Integer, Component As Object, ObjectClass As

Integer, Row As Long, Column As Long)
on error goto ErrorLoc
If ObjectClass <> vwOCDataBody or Row < 1 or Column < 1 then
exit sub
end if
if GraphType >= grGTBarClust then
dim datavalue as long
dim result as integer
datavalue = GetDataValue(Row, Column)
valoare_curenta!Label3.Text = str$(datavalue)
result = valoare_curenta.ShowModal()
end if
ErrorLoc:
Visible = Yes
End Sub
Pagina valoare_curentă (Text: Se afişează valoarea curentă) (figura A2.13) se

afişează atunci când se selectează un element de dată din graficul graph5. Pagina
are următoarele componente: o etichetă label1 (Text: Valoarea curentă este), o
etichetă label3 (unde se va afişa valoarea curentă), un buton button1 (Text: OK).
Pagina evolutie_volumul_finantarii_lei (Text: Evoluţia finanţării pe surse de

finanţare (lei)) este prezentată în figura A2.14 şi afişează informaţii despre
variabila val_lei, iar pagina evolutie_volumul_finantarii_dol (Text: Evoluţia
finanţării pe surse de finanţare (dolari)) despre variabila val_dol .
Pagina evolutie_personal (Text: Evoluţia personalului implicat în activitatea de

cercetare) este prezentată în figura A2.15 şi are următoarele componente: o listă
dimlb1_2 ce afişează valorile dimensiunii Nivel_institut, o listă dimlb2_1 ce
afişează valorile dimensiunii Institutii, o etichetă Nivel, o etichetă
Facultatea/catedra, un buton btnLink (Text: Link), un buton btnRefresh (Text:
Refresh), un buton Help (Text: Help), un tabel table_pers şi un grafic graph6 (ce
afişează valorile variabilelor nrcadre şi nrtesa), un grup de obiecte cu două
butoane de opţiuni optmoverow (Text: Afişează variabilele pe linii) şi
optionbutton5 (Text: Afişează variabilele pe coloane).
307
Figura A2.12 Afişarea valorii unui punct al graficului
Figura A2.13 Pagina Valoare_curentă
308
Anexa 2
La evenimentul AfterHighlight al listei dimlb1_2 se ataşează codul:

Sub AfterHighlight ()
call DimLB1_2.SetExpressStatus( dlbSELHighlight )
DimLB2_1.DataSelection.AutoRefreshData = False
DimLB2_1.DataSelection.AutoRefreshData = True
call DimLB2_1.RefreshListbox(dlbSELData)
End Sub
La evenimentul AfterClick al butonului btnlink se ataşează codul:

Sub AfterClick ()
set DimLB2_1.HighlightSelection = Table_pers.GetSelection("INSTITUTII")
End Sub
La evenimentul AfterClick al butonului btnrefresh se ataşează codul:

Sub AfterClick ()
call DimLB2_1.RefreshSelection( dlbSELHighlight )
End Sub
La evenimentul AfterClick al butonului Help se ataşează codul:

Sub AfterClick ()
End Sub
La evenimentul AfterClick al butonului de opţiune optmoverow se ataşează codul:

Sub AfterClick ()
dim dcpers as DataCube
dim edgrow as Edge
dim iENCount as integer
dim enLastInrow as EdgeNode
dim enMeasure as EdgeNode
call table_pers!datacube.rotate(dcrotorow, "XP_MEASUREDIM")
call graph6!datacube.rotate(dcrotorow, "XP_MEASUREDIM")
'se găseşte dimensiunea fizică rând
set dcpers = table_pers.DataCube
set edgrow = dcpers.GetEdge(dcErow)
'dacă dimensiunea cu măsuri este ultima în dimensiunea fizică rând
iENCount = edgrow.GetEdgeNodeCount()
set enLastInrow = edgrow.GetNthEdgeNode(iENCount-1)
if not enLastInrow.IsMeasureNode() then
set enMeasure = dcpers.GetEdgeNode ("XP_MEASUREDIM")
On Error goto RotateError
call dcpers.Rotate(dcROAfter, enMeasure, enLastInrow)
end if 'enLastInrow is not Measure node
exit sub
309
RotateError:
call dcpers.Rotate(dcROSwap, enMeasure, enLastInrow)
resume next
End Sub
La evenimentul AfterClick al butonului de optiune optionbutton5 se ataşează codul:

Sub AfterClick ()
dim dcpers as DataCube
dim edgcol as Edge
dim iENCount as integer
dim enLastIncol as EdgeNode
dim enMeasure as EdgeNode
call table_pers!datacube.rotate(dcrotocolumn, "XP_MEASUREDIM")
call graph6!datacube.rotate(dcrotocolumn, "XP_MEASUREDIM")
'se caută dimensiunea fizică coloana
set dcpers = table_pers.DataCube
set edgcol = dcpers.GetEdge(dcEcolumn)
'se verifică dacă dimensiunea cu măsuri este ultima în dimensiunea fizică coloana
iENCount = edgcol.GetEdgeNodeCount()
set enLastIncol = edgcol.GetNthEdgeNode(iENCount-1)
if not enLastIncol.IsMeasureNode() then
set enMeasure = dcpers.GetEdgeNode ("XP_MEASUREDIM")
On Error goto RotateError
call dcpers.Rotate(dcROAfter, enMeasure, enLastIncol)
end if 'enLastInCol is not Measure node
exit sub
RotateError:
call dcpers.Rotate(dcROSwap, enMeasure, enLastIncol)
resume next
End Sub
La evenimentul AfterRun al paginii se ataşează codul:

call DimLB1_2.AfterHighlight()
End Sub
Pagina evoluţie_personal1 (Text: Evoluţia grafică a personalului implicat în

activitatea de cercetare) este prezentată în figura A2.16 şi are următoarele
componente: o listă dimlb1_grafic ce afişează valorile dimensiunii Nivel_institut, o
listă dimlb2_grafic ce afişează valorile dimensiunii Instituţii, un grafic graph3 (se
vor afişa valorile variabilelor nrcadre şi nrtesa), un grup de obiecte grchoose
(Text: Alegeţi tipul de grafic) cu trei butoane de opţiuni optbar (Text: Bar), optline
310
Anexa 2
(Text: Line) şi optpie (Text: Pie). La evenimentul AfterRun al paginii se ataşează

următorul cod:
call DimLB1_grafic.AfterHighlight()
End Sub
Figura A2.14 Pagina Evolutie_volumul_finantarii_lei
La evenimentul AfterHighlight al listei dimlb1_grafic se ataşează codul:

call DimLB1_grafic.SetExpressStatus( dlbSELHighlight )
DimLB2_grafic.DataSelection.AutoRefreshData = False
DimLB2_grafic.DataSelection.AutoRefreshData = True
call DimLB2_grafic.RefreshListbox(dlbSELData)
End Sub
La evenimentul AfterHighLight al listei dimlb2_grafic se ataşează codul:

Dim persSel as Selection
set persSel = Graph3.GetSelection("INSTITUTII")
persSel.StatusScript = "Limit INSTITUTII to '" &
DimLB2_grafic.FocusValueText
persSel.AutoSort = TRUE
End Sub
311
La evenimentul AfterSelect al graficului graph3 se ataşează codul:

Sub AfterSelect (SelectType As Integer, Component As Object, ObjectClass As
Integer, Row As Long, Column As Long)
on error goto ErrorLoc
If ObjectClass <> vwOCDataBody or Row < 1 or Column < 1 then
exit sub
end if
if GraphType >= grGTBarClust then
dim datavalue as long
dim result as integer
datavalue = GetDataValue(Row, Column)
valoare_curenta_pers_grafic!Label3.Text = str$(datavalue)
result = valoare_curenta_pers_grafic.ShowModal()
end if
ErrorLoc:
Visible = Yes
End Sub
Figura A2.15 Pagina Evoluţie_personal
La evenimentul AfterClick al butonului optbar se ataşează codul:

Sub AfterClick ()
graph3.graphtype=grgtbarclust
312
Anexa 2
End Sub
La evenimentul AfterClick al butonului optline se ataşează codul:

Sub AfterClick ()
graph3.graphtype=grgtlineabs
End Sub
La evenimentul AfterClick al butonului optpie se ataşează codul:

Sub AfterClick ()
graph3.graphtype=grgtmultipie
End Sub
Figura A2.16 Pagina Evolutie_personal1
Pagina Top (Text: Primele trei facultăţi) este prezentată în figura A2.17 şi are
următoarele componente: un buton domzoom (Text: Total), un buton tipzoom (Text:
Tip_proiect), un buton Top3 (Text: Top3), un buton explicatie (Text: Explicaţie),
un grup de obiecte measgroup (Text: Indicatori) format din trei casete de validare
opt1 (Text: Valoare(lei), Value:1-Checked), opt2 (Text: Valoare(dolari), Value: 0-
unchecked), opt3 (Text: Număr proiecte, Value:0-unchecked), un tabel table1 (se
vor afişa valorile variabilei selectate). La evenimentul AfterRun al paginii se
313

table1.GetSelection("INSTITUTII").StatusScript = "LIMIT INSTITUTII TO
fac_set"
End Sub
La evenimentul AfterClick al butonului domzoom se ataşează următorul cod:

Sub AfterClick ()
application.showhourglass = true
table1.datacube.autorefreshdata = false
call table1.rotate(dcROToPage,"TIP_PROIECT")
table1.GetSelection("TIP_PROIECT").StatusScript= "LIMIT TIP_PROIECT TO
'TOTAL'"
table1.GetSelection("TIMP").StatusScript = "LIMIT TIMP TO all"
table1.GetSelection("INSTITUTII").AutoSort = YES
table1.GetSelection("INSTITUTII").StatusScript = "LIMIT INSTITUTII TO
fac_set"
table1.datacube.autorefreshdata = true
End Sub
La evenimentul AfterClick al butonului tipzoom se ataşează următorul cod:

Sub AfterClick ()
if table1.getselection("TIP_PROIECT").container.container is _
table1.datacube.item(2) then
call table1.rotate(dcROAfter,"TIP_PROIECT", "INSTITUTII")
table1.GetSelection("TIP_PROIECT").StatusScript = "LIMIT TIP_PROIECT TO
ALL"
table1.GetSelection("INSTITUTII").AutoSort = YES
else
call table1.rotate(dcROAfter, "TIP_PROIECT", "TIMP")
end if
End Sub
La evenimentul AfterClick al butonului Top3 se ataşează următorul cod:

Sub AfterClick ()
Dim Comp as Object
Dim ObjClass as integer
Dim Row as long
Dim Column as long
dim measval as string
dim sel as object
DIM TIMPVAL AS STRING
314
Anexa 2
call table1.GetSelectedObject(Comp, ObjClass, Row, Column)
select case objclass
case vwocdatabody, vwocdataedge, vwocbodynondata
measVal = table1.GetDimValues(ObjClass, Row, Column,
"XP_MEASUREDIM")
timpval = table1.GetDimValues(ObjClass, Row, Column, "TIMP")
if (measval = "" or timpval = "") Then goto exit_sub
set sel = table1.getselection("INSTITUTII")
sel.AutoSort = NO
sel.sortdatameasure = measval
sel.StatusScript = _
"call XP_SLLIMIT('INSTITUTII', 'EXTREME', 'KEEP'," & _
"'NONE', 'NA', 'TOP', '3', 'NO', 'NA', 'NO', 'YES', " & _
"'YES', '" & MEASVAL & "', 'TIP_PROIECT\nTIMP', " & _
"'TOTAL\n" & timpval & " ')"
call table1.GetSelectedObject(Comp, ObjClass, Row, Column)
case else
end select
exit_sub:
End Sub
La evenimentul AfterClick al grupului de obiecte measgroup se ataşează următorul

cod:
Sub AfterClick ()
dim pcxtext as string, meassel as selection
pcxtext="limit xp_measuredim to"
if opt1.value=0 and opt2.value=0 and opt3.value=0 then opt1.value=1
if opt1.value=1 then pcxtext=pcxtext & " 'VALOARE_LEI'"
if opt2.value=1 then pcxtext=pcxtext & " 'VALOARE_DOLARI'"
if opt3.value=1 then pcxtext=pcxtext & " 'NRPROIECTE'"
set meassel = table1.getselection("XP_MEASUREDIM")
meassel.statusscript=pcxtext
End Sub
La evenimentul AfterClick al butonului explicaţie se ataşează următorul cod:

Sub AfterClick ()
dim strmsg as string
strmsg= "Se selectează indicatorul" & chr$(13) & chr$(13)
strmsg=strmsg & "Se apasă butonul Total pentru a afişa valorile indicatorului
selectat pentru fiecare facultate. Se alege anul." & chr$(13) & chr$(13)
315
strmsg=strmsg & "Se apasă apoi butonul Top 3 pentru a afişa primele trei facultăţi
în funcţie de valorile indicatorului selectat" & chr$(13) & chr$(13)
strmsg=strmsg & "Pentru detalii se apasă apoi butonul Tip_proiect. Se afişează în
detaliu valorile indicatorului pentru fiecare tip de proiect"
msgbox strmsg, 64,"Explicatii", container.[text]
End Sub
Pagina ratapublicatii (Text: Rata publicaţiilor) este prezentată în figura A2.18 şi

are următoarele componente: un buton btnrefresh1 (Text: Refresh), un buton
btnlink1 (Text: Link), o listă dimlb1 ce afişează valorile dimensiunii Timp, o listă
diminstitut1 ce afişează valorile dimensiunii Instituţii, o etichetă label1 (Text:
Anii), o listă dimnivel1ce afişează valorile dimensiunii Nivel_institut, un buton help
(Text: Help), un buton explicatie (Text:Explicatie), un tabel table1, un grafic
graph1 (se vor afişa valorile variabilei rata), o etichetă nivel, o etichetă publicaţii
şi o listă dimlbpub ce afişează valorile dimensiunii Publicaţii. La evenimentul
AfterRun al paginii se ataşează următorul cod:
call dimnivel1.afterhighlight()
End Sub
Figura A2.17 Pagina Top

La evenimentul AfterClick al butonului btnrefresh1 se ataşează următorul cod:
Sub AfterClick ()
316
Anexa 2
call diminstitut1.refreshselection(dlbselhighlight)
call DimLB1.RefreshSelection( dlbSELHighlight )
call DimLBpub.RefreshSelection( dlbSELHighlight )
set graph1.datacube=table1.datacube
End Sub
La evenimentul AfterClick al butonului btnlink1 se ataşează următorul cod:

Sub AfterClick ()
set Diminstitut1.HighlightSelection = Table1.GetSelection("INSTITUTII")
set DimLB1.HighlightSelection = Table1.GetSelection("TIMP")
set DimLBpub.HighlightSelection = Table1.GetSelection("publicatii")
End Sub
La evenimentul AfterHighlight al listei dimnivel1 se ataşează următorul cod:

call Dimnivel1.SetExpressStatus( dlbSELHighlight )
Diminstitut1.DataSelection.AutoRefreshData = False
Diminstitut1.DataSelection.AutoRefreshData = True
call Diminstitut1.RefreshListbox(dlbSELData)
end sub
La evenimentul Afterclick al butonului Help se ataşează următorul cod:

Sub AfterClick ()
msgbox container.ajutor, 64, me.text
End Sub
La evenimentul Afterclick al butonului explicatie se ataşează următorul cod:

Sub AfterClick ()
Dim strMsg as string
strMsg ="Categorii şi subcategorii de publicaţii:" & Chr$(13) & Chr$(13)
strMsg = strMsg & "CARTE" & Chr$(13)
strMsg = strMsg & "CCNCSIS=cărţi publicate în edituri româneşti recunoscute de
CNCSIS" & Chr$(13)
strMsg = strMsg & "CS=cărţi publicate în edituri româneşti recunoscute din
străinatate" & Chr$(13)
strMsg = strMsg & "CNER=cărţi publicate în edituri româneşti nerecunoscute"&
Chr$(13)& Chr$(13)
strMsg = strMsg & "ARTICOLE"& Chr$(13)
strMsg = strMsg & "ACNCSIS=articole publicate în reviste româneşti recunoscute
CNCSIS"& Chr$(13)
strMsg = strMsg & "AISI=articole publicate în reviste cotate ISI"& Chr$(13)
strMsg = strMsg & "AS=articole în reviste din străinătate cu recenzori"& Chr$(13)
strMsg = strMsg & "ANER=articole publicate în reviste nerecunoscute"&
Chr$(13)& Chr$(13)
317
strMsg = strMsg & "CONFERINŢE"& Chr$(13)

strMsg = strMsg & "CN=comunicări naţionale"& Chr$(13)
strMsg = strMsg & "CI=lucrări publicate în volumele conferinţelor
internaţionale"& Chr$(13)& Chr$(13)
strmsg=strmsg & "Rata publicaţiilor reprezintă numărul mediu de publicaţii pe
cadru didactic" & chr$(13)
MsgBox strMsg, 64, Container.[Text]
End Sub
Figura A2.18 Pagina Ratapublicatii
Pagina instituţii (Text: Facultăţile şi catedrele din ASE) este prezentată în figura
A2.19 şi are următoarele componente: un arbore treeview1 (TreeLine: 1-Root lines,
Tree ViewStyle: 6-Lines...). La evenimentul AfterActivate al paginii se ataşează
următorul cod:
Sub AfterActivate ()
dim i as integer
call TreeView1.Clear
call TreeView1.AddTreeNode("ACADEMIA DE STUDII ECONOMICE",
"ASE")
call TreeView1.AddTreeNode("FACULTATEA STUDII ECONOMICE IN
LIMBI STRAINE", "FSELS", "ASE", tvwRSChild)
318
Anexa 2
call TreeView1.AddTreeNode("FACULTATEA COMERT", "COM", "ASE",

tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA ECONOMIE GENERALA ",
"EG", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA ECONOMIE GENERALA A
PRODUCTIEI AGRICOLE SI ALIMENTARE", "EGPAA", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA CONTABILITATE SI
INFORMATICA DE GESTIUNE", "CIG", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA FINANTE, ASIGURARI,
BANCI, BURSE DE VALORI", "FABBV", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA CIBERNETICA, STATISTICA
SI INFORMATICA ECONOMICA", "CSIE", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA RELATII ECONOMICE
INTERNATIONALE", "FREI", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("DEPARTAMENTUL DE PREGATIRE A
PERSONALULUI DIDACTIC", "DPPD", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("COLEGIU ECONOMIC BUCURESTI ",
"COLB", "ASE", tvwRSChild)
call TreeView1.AddTreeNode("FACULTATEA MANAGEMENT", "FMAN",
"ASE", tvwRSChild)
call TreeView1.AddTreeNode("CIBERNETICA ECONOMICA", "CIB", "CSIE",
tvwRSChild)
call TreeView1.AddTreeNode("INFORMATICA ECONOMICA", "IE", "CSIE",
tvwRSChild)
call TreeView1.AddTreeNode("STATISTICA SI PREVIZIUNE ECONOMICA",
"STAT", "CSIE", tvwRSChild)
call TreeView1.AddTreeNode("ANALIZA STATISTICA SI EVALUARE", "AS",
"CSIE", tvwRSChild)
call TreeView1.AddTreeNode("ECONOMIE MATEMATICA", "EM", "CSIE",
tvwRSChild)
call TreeView1.AddTreeNode("COMERT", "CO", "COM", tvwRSChild)
call TreeView1.AddTreeNode("TURISM SERVICII", "TS", "COM",
tvwRSChild)
call TreeView1.AddTreeNode("MERCEOLOGIE SI MANAGEMENTUL
CALITATII", "MMC", "COM", tvwRSChild)
call TreeView1.AddTreeNode("DREPT", "DR", "FABBV", tvwRSChild)
call TreeView1.AddTreeNode("ANALIZA ECONOMICO-FINANCIARA",
"AEF", "FABBV", tvwRSChild)
call TreeView1.AddTreeNode("MONEDA", "MON", "FABBV", tvwRSChild)
call TreeView1.AddTreeNode("FINANTE", "FIN", "FABBV", tvwRSChild)
call TreeView1.AddTreeNode("CONTABILITATE INTERNATIONALA SI
INFORMARE FINANCIARA", "CIIF", "CIG", tvwRSChild)
call TreeView1.AddTreeNode("CONTABILITATE, AUDIT SI CONTROL DE
GESTIUNE", "CACG", "CIG", tvwRSChild)
319
call TreeView1.AddTreeNode("INFORMATICA DE GESTIUNE", "IG", "CIG",

tvwRSChild)
call TreeView1.AddTreeNode("MANAGEMENT", "MAN", "FMAN",
tvwRSChild)
call TreeView1.AddTreeNode("EFICIENTA ECONOMICA", "EC", "FMAN",
tvwRSChild)
call TreeView1.AddTreeNode("TEHNOLOGIE INDUSTRIALA", "TI", "EG",
tvwRSChild)
call TreeView1.AddTreeNode("COMUNICARE SI DOCTRINE ECONOMICE",
"CDE", "EG", tvwRSChild)
call TreeView1.AddTreeNode("ECONOMIE SI POLITICI ECONOMICE",
"EPE", "EG", tvwRSChild)
call TreeView1.AddTreeNode("EDUCATIE FIZICA SI SPORT", "EFS", "EG",
tvwRSChild)
call TreeView1.AddTreeNode("ISTORIA ECONOMIEI SI GEOGRAFIEI",
"IEG", "EG", tvwRSChild)
call TreeView1.AddTreeNode("LIMBI ROMANICE SI COMUNICARE IN
AFACERI", "LRCA", "FREI", tvwRSChild)
call TreeView1.AddTreeNode("LIMBI GERMANICE SI COMUNICARE IN
AFACERI", "LGCA", "FREI", tvwRSChild)
call TreeView1.AddTreeNode("RELATII ECONOMICEC INTERNATIONALE",
"REI", "FREI", tvwRSChild)
call TreeView1.AddTreeNode("TEHNOLOGIA PRODUCTIEI AGRICOLE SI
ALIMENTARE", "TPAAI", "EGPAA", tvwRSChild)
call TreeView1.AddTreeNode("STUDII ECONOMICE IN LIMBI STRAINE",
"SELS", "FSELS", tvwRSChild)
End Sub
La evenimentul DoRun al proiectului evaluarea se ataşează un cod, care permite

afişarea unei ferestre la lansarea în execuţie a proiectului (figura A2.20):
Function DoRun (Flags As Integer, EnableDefault As Integer) As Integer
dim msgtext as string
dim thetime as variant
thetime=hour(now)
if thetime>=18 then
msgtext="Buna seara,este ora:"& time & "."
elseif thetime>=12 then
msgtext="Buna ziua,este ora:"& time & "."
else
msgtext="Buna dimineata,este ora:" & time & "."
end if
msgbox msgtext, 64, me.description
if (pagmain.showmodal()<>pgprok) then
enabledefault=no
320
Anexa 2
end if
End Function
Figura A2.19 Pagina Institutii
Figura A2.20 Fereastra iniţială ce apare la lansarea în execuţie a proiectului
321
Anexa 3
Sistemul informatic tranzacţional utilizează o bază de date relaţională Oracle
8.1.7. Modelul entitate-asociere al sistemului informatic tranzaţional, precum şi
schema conceptuală a bazei de date relaţională sursă sunt prezentate în capitolul 9.
Scriptul SQL pentru definirea structurii bazei de date relaţionale este prezentat
în cele ce urmează:
drop table facultati cascade constraints;
drop table catedre cascade constraints;
drop table categ_pub cascade constraints;
drop table persoane cascade constraints;
drop table publicatii cascade constraints;
drop table pers_pub;
drop table nrprof_cat;
drop table stud_fac;
drop view pub_prof;
drop table teze;
drop table brevete;
drop table reprezentari;
drop table premii;
drop table centre cascade constraints;
drop table tip_proiect cascade constraints;
drop table proiecte cascade constraints;
drop table pers_proi;
prompt creare tabelă Facultati
create table facultati(codfac varchar2(5) primary key, den_fac varchar2(60),
den_inst varchar2(6));
prompt creare tabelă Catedre
create table catedre(codcat varchar2(5) primary key, dencat varchar2(60),
codfac varchar2(5), foreign key(codfac) references facultati(codfac));
prompt creare tabelă Categorii
create table categ_pub(codsubcat varchar2(2) primary key,
den_subcat varchar2(70), categ varchar2(10));
prompt creare tabelă Persoane_cercetare
create table persoane(codp number(3) primary key, nume varchar2(30),
functia varchar2(3), doctorat varchar2(3), imagine blob, an_prom varchar2(4),
322
Anexa 3
codcat varchar2(7), foreign key (codcat) references catedre(codcat));

prompt creare tabelă Publicaţii
create table publicatii(codpub number(4) primary key, den_pub varchar2(60),
an varchar2(4), editura varchar2(30), nrpag number(4), codsubcat varchar2(2),
foreign key(codsubcat) references categ_pub(codsubcat));
prompt creare tabelă Pers_Pub
create table pers_pub(codp number(3), codpub number(4), nrpagini number(3),
foreign key(codp) references persoane(codp),
foreign key(codpub) references publicatii(codpub));
prompt creare tabelă Stud_fac
create table stud_fac(codfac varchar2(5), an varchar2(4), nrstud number(4),
primary key(codfac, an));
prompt creare tabelă Brevete
create table brevete (titlu varchar2(100) primary key, codp number(3),
an_brev varchar2(4),
constraint BR_fk foreign key (codp) references persoane(codp));
prompt creare tabelă Centre
create table centre (codc varchar2(10) primary key, denumire varchar2(50),
director varchar2(25), domeniu varchar2(30), acreditare varchar2(50),
an_cred varchar2(4));
prompt creare tabelă Premii
create table premii( codpr number primary key, titlu varchar2(70), codp number(3),
an_prem varchar2(4), den_org varchar2(80), constraint pe_fk foreign key(codp)
references persoane(codp));
prompt creare tabelă Reprezentări
create table reprezentari( codr number primary key, codp number(3),
an_repr varchar2(4), den_acad varchar2(50), constraint per_fk foreign key(codp)
references persoane(codp));
prompt creare tabelă Teze
create table teze (codt number primary key, titlu varchar2(100),
nume_doct varchar2(30), codp number(3), an_matr varchar2(4), an_sust
varchar2(4), constraint pers_fk foreign key (codp) references persoane(codp));
prompt creare tabela Nrprof_cat
create table nrprof_cat(codcat varchar2(5), an varchar2(4), nrprof number(4),
primary key(codcat,an));
prompt creare tabelă Tipuri_proiect
create table tip_proiect(cod_tip varchar2(8) primary key, denumire varchar2(100));
prompt creare tabelă Proiecte
create table proiecte(cod varchar2(11) primary key, denumire varchar2(150),
director varchar2(25), codp number(3), an varchar2(4), cod_tip varchar2(7),
codc varchar2(12), val_lei number(20), val_dol number(10),
finantator varchar2(30), observatii varchar2(50),
den_etapa varchar2(200), foreign key(cod_tip) references tip_proiect(cod_tip),
323
foreign key (codp) references persoane(codp), foreign key(codc) references

centre(codc));
prompt creare tabelă Pers_Proi
create table pers_proi(codp number(3), cod varchar2(11), nrore number(5),
primary key(codp,cod), foreign key(codp) references persoane(codp),
foreign key(cod) references proiecte(cod));
prompt creare secvenţe
drop sequence secv_premii;
drop sequence secvteze;
drop sequence secv_reprez;
drop sequence publicatii_cod;
create sequence secv_premii start with 1 increment by 1 maxvalue 10000 ;
create sequence secvteze start with 1 increment by 1 maxvalue 10000;
create sequence secv_reprez start with 1 increment by 1 maxvalue 10000;
create sequence publicatii_cod start with 1 increment by 1 maxvalue 10000;
prompt creare tabelă virtuală View_contrint
create or replace view view_contrint as
select proiecte.an, persoane.codcat, count(distinct denumire) N2 , sum(val_dol)
VTCI from proiecte, persoane
where persoane.codp=proiecte.codp
and (cod_tip in ('PU','PEP','D', 'C', 'T', 'B', 'PI' 'PC'))
group by proiecte.an, persoane.codcat
order by proiecte.an, persoane.codcat;
prompt creare tabelă virtuală View_grant
create or replace view view_grant
as select proiecte.an, persoane.codcat, count(distinct denumire) N1 , sum(val_lei)
Vtgn from proiecte, persoane
where persoane.codp=proiecte.codp and (cod_tip like 'GR%' or cod_tip='ACAD')
group by proiecte.an, persoane.codcat
order by proiecte.an, persoane.codcat;
prompt creare tabela virtuală Pub_prof
create view pub_prof(codcat, codsubcat , an, nrpub )
as select persoane.codcat, publicatii.codsubcat,an, count(distinct pers_pub.codpub)
nrpub
from persoane, pers_pub, publicatii
where persoane.codp=pers_pub.codp
and pers_pub.codpub=publicatii.codpub
group by persoane.codcat, publicatii.codsubcat, publicatii.an;
prompt creare tabela virtuală Proiecte_cat
create or replace view proiecte_cat as
select proiecte.an, proiecte.cod_tip, persoane.codcat,
count(distinct proiecte.denumire) nrpro, sum(nvl(proiecte.val_lei, 0)) total_lei,
sum(nvl(proiecte.val_dol, 0)) total_dol from persoane, proiecte
where persoane.codp=proiecte.codp
324
Anexa 3
group by proiecte.an, proiecte.cod_tip, persoane.codcat;

prompt creare tabela virtuală nrcadre_cat_an
create or replace view nrcadre_cat_an(an, codcat, nrcadre)
as select proiecte.an, persoane.codcat, count(distinct(pers_proi.codp)) nrcadre
from proiecte, pers_proi, persoane where proiecte.cod=pers_proi.cod
and persoane.codp=pers_proi.codp and persoane.functia<>'T'
and persoane.functia<>'S'
group by proiecte.an, persoane.codcat;
prompt creare tabela virtuală nrdoct_cat_an
create or replace view nrdoct_cat_an(an, codcat, nrdoct)
as select proiecte.an, persoane.codcat, count(distinct(pers_proi.codp)) nrdoct
from proiecte, pers_proi, persoane
where proiecte.cod=pers_proi.cod
and persoane.codp=pers_proi.codp and persoane.doctorat='drd'
prompt creare tabela virtuală nrstud_cat_an
create or replace view nrstud_cat_an(an, codcat, nrstud)
as select proiecte.an, persoane.codcat, count(distinct(pers_proi.codp)) nrstud
and persoane.codp=pers_proi.codp and persoane.functia='S'
prompt creare tabela virtuală nrtesa_cat_an
create or replace view nrtesa_cat_an(an,codcat, nrtesa)
as select proiecte.an, persoane.codcat, count(distinct (pers_proi.codp)) nrtesa
and persoane.codp=pers_proi.codp and persoane.functia='T'
325
Bibliografie
Cărţi
[BALL98] C. Ballard, D. Herreman, D. Schau, Data Modeling Techniques for
Data Warehousing, http://www.redbooks/ibm/com, 1998
[BARA00] C. Baragoin, J. Bercianos, G. Robinson “DB2 OLAP Server
Theory and Practices”, International Technical Support
Organization, http://www.redbooks/ibm/com, 2000
[BATI92] C. Batini, S. Ceri, S. Navathe, Conceptual database Design - an
Entity-Relationship Approach, Benjamin/Cummings, 1992
[BEYO97] D. Beyon, Information and Data Modeling, MacGraw Hill
Publishing Company, 1997
[BONC81] R. Bonczek, C. Holsapple, A. Whinston, Foundation of Decision
Support Systems, Academy Press, New York, 1981
[CODD91] E. Codd, The relational Model for Database Management: version
2, Addison-Wesley Publishing Company, Reading, MA, 1991
[DATE95] Date, Chris J., An Introduction to Database Systems, 6th ed.,
Addison-Wesley Publishing Company, Reading, MA, 1995
[DAOE98] Oracle Corporation, Develop Applications with Oracle Express
Objects, Student Guide, vol 1, 2, 1998
[ELMA94] R. Elmasri, S. Navathe, Fundamentals of Database Systems, 2nd
Benjamin/Cummings, 1994
[GRAY98] P. Gray, H. Watson, Decision Support in the Data Warehouse,
Prentice Hall, 1998
[INMO92] W H Inmon, Building the Data Warehouse, John Wiley&Sons,
New York, 1992
[KEND92] K. E. Kendall, J E. Kendall, Systems Analysis and Design, 2nd ed.,
Englewood Cliffs, New Jersey, Prentice Hall Inc., 1992
[KILA98] R. Kimball, Laure Reeves, Margy Ross, The Datawarehouse Life
Cycle Toolkit. Experts Methods for Designing, Developing and
Deploying Data Warehouses, John Willey &Sons, 1998
[KIMB96] R. Kimball, The Data Warehouse Toolkit, Practical Techniques
for Building Dimensional Data Warehouses, John Wiley&Sons,
New York, 1996
326
Bibliografie
[KIMB98] R. Kimball, L. Leeves, M.Ross, W. Thornthwaite, The Data

Warehouse Lifecycle Toolkit, John Wiley&Sons, New York, 1998
[KOTL98] P. Kotler, Managementul marketingului, editura Teora, Bucureşti,
1998
[LUBO95] I. Lungu, C. Bodea, G. Bădescu, C. Ioniţă, Baze de date
Organizare, proiectare şi implementare, editura ALL, Bucureşti,
1995
[MARA99] G. Marakas, Decision Support Systems in the 21st Century,
Prentice Hall, 1999
[OEOG99] Oracle Corporation, Oracle Express Objects Getting Started,
Release 6.3.2, 1999
[OEAG99] Oracle Corporation, Oracle Express Analyzer Getting Started,
Release 6.3.2, 1999
[OEWA99] Oracle Corporation, Oracle Express Web Agent User’s Guide,
Release 6.3.2, 1999
[OEDA99] Oracle Corporation, Oracle Express Database Administrator
Guide, Release 6.3.4, 1999
[POWE01] D.J. Power, Decision Support Systems: Concepts and Resources,
Cedar Falls, IA: DSSresources.com,
http://dssresources.com/ dssbook/, 2001
[RACI01] Gh. Răboacă, D. Ciucur, Metodologia cercetării ştiinţifice
economice, editura Fundaţiei România de Mâine, Universitatea
Spiru Haret, 2001
[RAMU99] Oracle Corporation, Relational Access Manager User’s Guide,
Release 6.3.2, 1999
[ROCK98] J. Rockart, D. DeLong, Executive Support Systems, Dow Jones-
Irwin, 1998
[SLVM03] Gh. Sabău, I. Lungu, M. Velicanu, M. Muntean ş.a., Sisteme
informatice. Analiză, proiectare, implementare, editura
Economică, Bucureşti, 2003
[SPRA93] R. Sprague, H. Watson, Decision Support Systems-Putting Theory
Into Practice, 3rd. Edition, Englewood Cliffs, Prentice Hall, 1993
[STON93] M Stonebraker, Reading in Database Systems, Morgan Kaufmann,
San Francisco, 1993
[TANS93] A.U.Tansel, J.Clifford, S.Gadia, S.Jajodia, Temporal Databases:
Theory, Desig and Implementation, Benjamin/Cummings, 1993
[TILL93] G Tillman, A practical Guide to Logical Data Modeling, McGraw-
Hill, New York, 1993
[THOM96] E. Thomsen, OLAP Solutions: Building Multidimensional
Information Systems, John Wiley&Sons, New York, 1996
[TURB98] E. Turban, Decision Support Systems and Intelligent Systems, 5th
ed., Englewood Cliffs, New Jersey, Prentice Hall, 1998
[ULLM97] J. Ullman, J.Widom, A first Course in Database Systems, Prentice
Hall, 1997
327
Iniţiere în tehnologia OLAP-teorie şi practică.
[VMLI03] M. Velicanu, M. Muntean, I. Lungu, S. Ionescu, Oracle. Platformă

pentru baze de date, editura Petrion, Bucureşti, 2002
[WIJE91] G Wijers, Modeling Support in Information System Development,
Thesis Publishers Amsterdam, 1991
Articole şi comunicări
[ABEL00] A. Abello, J. Samos, F. Saltor, A data warehouse multidimensional
Data Models classification, Proc. Workshop on Design and
Management of Data Warehouses, 2000
[AGRA97] R. Agrawal, A. Gupta, S. Sarawagi, Modeling multidimensional
databases, 13th International Conference on Data Engineering,
1997
[ARBO97] Arbor Sofware Corporation, Relational OLAP: Expectiations &
Reality, White Paper, 1997
[ARBO00] Arbor Software Corporation, Analytical Processing: A comparison
of multidimensional and SQL-based approaches, White paper,
2000
[BLAS98] M. Blaschka, C. Sapia, G. Höfling, B. Dinter, Finding your way
through multidimensional data models, Proc of 9th International
Conference on Database and Expert Systems Applications, nr 1460
in LNCS Springer, 1998
[BLAS99] C. Sapia, M. Blaschka, G. Höfling, B. Dinter, Extending the E/R
model for the multidimensional paradigm, Proc. International
Workshop on Data Warehouse and Data Mining in conjunction
with the ER’98, nr 1552, in LNCS, Springer, 1999
[BLAS00] M. Blaschka, Fiesta: A framework for Schema Evolution in
Multidimensional Databases, PhT thesis, Institut fur Informatik
der Technischen Universität München, 2000
[BULE01] Academia de Studii Economice, Departamentul de Cercetări
Economice, Buletin Informativ, 2001, 2002, 2003
[BULO96] Bulos D., A new Dimension, Database Programming& Design,
6/1996
[CABB97] L. Cabbibo, R. Torlone, Querying Multidimensional databases,
Proc of 6th Workshop Database Programming Languages, USA,
1997
[CABB98a] L. Cabbibo, R. Torlone, From a procedural to a Visual Query
Language for OLAP, 10th IEEE International Conference on
Scientific and Statistical Database Management, 1998
[CABB98b] L. Cabbibo, R. Torlone, A logical approach to multidimensional
databases, Proc. of EDBT’98, Springer, 1998
[CHAU97] S. Chaudhuri, U. I. Dayal, An overview of Data Warehousing and
OLAP Technology, ACM SIGMOD Record 26, Tucson, 1997
328
Bibliografie
[CNCS01] I. Lungu, M. Velicanu, M. Muntean, S. Ionescu, Studiul şi analiza

comparativă a metodelor, tehnicilor şi instrumentelor utilizate în
domeniul “Inteligenţei afacerilor”, Soluţii economice şi
informatice pentru inteligenţa afacerilor, CNCSIS, 2001
[CNCS02] I. Lungu, M. Velicanu, M. Muntean, S. Ionescu, Dezvoltarea
sistemelor informatice pentru afaceri inteligente, Soluţii
economice şi informatice pentru inteligenţa afacerilor, CNCSIS,
2002
[CODD93] E.F. Codd, Providing OLAP (on-line analytical processing) to
user-analysts: An IT mandate, Technical report, E.F. Codd and
Associates, White paper, Arbor Software Corporation, 1993
[COLL96] G. Colliat, OLAP, relational and multidimensional database
systems, SIGMOD Record 25, 3(1996), Technical report, Arbor
Software Corporation, Sunnyvale, CA, 1996
[DATT97] A. Datta, H. Thomas, A conceptual Model and a an Algebra for
on-line Analytical processing in Data Warehouses, Proc. of
Workshop on Information Technologies and Systems, Atlanta,
1997
[DEKE99] S. Dekeyser, B. Kuijpers, J. Paredaens, J. Wijsen, The nested
datacube model for OLAP, Proc International Workshop on Data
Warehousing and Data Mining Springer, Verlag, 1998
[GRAY96] J.Gray, A.Bosworth, A.Layan, H.Pirahesh, Data Cube: A
relational aggregation operator generalizing group by, cross-tabs
and sub-totals, Proc. of the 12th International Conference of Data
Engineering, 1996
[GOLF98a] M. Golfarelli, S. Rizzi, Conceptual design of data warehouses
from E/R schemes, Proc. HICSS-31, VII, Hawaii, 1998
[GOLF98] M. Golfarelli, S. Rizzi, A Methodological Approach for Data
Warehouse Design, Proceedings of the 1st International Workshop
on Data Warehouse and OLAP (DOLAP’98), Washington, 1998
[GOLF98b] M. Golfarelli, S. Rizzi, The Dimensional Fact Model: A
conceptual Model for data Warehouses, Journal of Computer
Science and Information Systems, 1998
[GOLF99] M. Golfarelli, S. Rizzi, Designing the Data Warehouse: Key Steps
and crucial issues, Journal of Computer Science and Information
management, vol2, nr.3, 1999
[GUAZ00] M. Guazzo, A cartesian Data Model for Decision Support Systems,
Proc of 2nd International Workshop on Design and Management of
Data Warehouses, Stockholm, 2000
[GYSS97] M. Gyssen, L. Lakshmanan, A foundation for multi-dimensional
Databases, Proc 23th VLDB, Greece, 1997
[HASS99] H. Hassan, Effective Information for managers, Proc. 10th
Australian Conference on Information Systems, 1999
329
[HATT99] P.Hattenschwiler, Neue Konzepte der Entscheidungsunterstutzung,

Working Paper 99-4, Institute of Informatics, University of
Fribourg, 1999
[INFO96] Informix Software Inc., The Informix-MetaCube Approach,
Product Information, 1996
[KENA95] Kenan Technologies, An Introduction to Multidimensional
Database Technology, White paper, 1995
[KIMB97] R. Kimball, A dimensional Modeling Manifesto, DBMS Online,
http://www.dbmsmag.com/9708d15.html, 1997
[LEHN98] W. Lehner, Modeling Large Scale OLAP Scenarios, Lecture Notes
in Computer Science, nr. 1377, Proceedings. Of the 6th
International Conference on Extending Database Technology,
EDBT 98, Spania, 1998
[LIWA96] C. Li, X. S. Wang, A data model for supporting on-line analytical
processing, Proc. Conf on Information and Knowledge
Management, SUA, 1996
[MANG99] O. Mangisengi, A. Tjoa, R. Wagner, Multidimensional Modeling
Approaches for OLAP based on Extended Relational Concepts,
Proc of the 9th International Database Conference on
Heterogeneous and Internet Databases, Hong Kong, 1999
[META97] Metadata Coalition, Meta Data Interchange Specification (MDIS
version 1.1), http://www.he.net/~metadata/standards/, 1997
[MICR98] Microstrategy Inc, The Case for Relational OLAP, White Paper,
1998
[MICR98] Microsoft Corporation, OLEDB for OLAP,
http://www.microsoft.com/data/oledb/olap/, 1998
[MICR99] Microstrategy Inc, True Relational OLAP, White Paper, 1999
[MOOD00] D. Moody, M. Kortink, From enterprise models to dimensional
models: A Methodology for Data Warehouse and Data Mart
Design, Proc of 2nd International Workshop on Design and
Management of Data Warehouses, Stockholm, 2000
[OLAP96] The OLAP Council, MD-API the OLAP Application Program
Interface, version 0.5 Specification, 1996
[OLAP97] Olap Council, The OLAP glossary, OLAP and OLAP Server
Definitions,
http://www.olapcouncil.org/research/glossary.htm, 1997
[OLAP97b] OLAP Council, The APB-1 Benchmark,
http://www.olapcouncil.org/research/bmarkly.htm, 1997
[PEDE99] T. Pendersen, C. Jensen, Multidimensional Data Modeling of
Complex Data, Proceedings of the 15th IEEE International
Conference on Data Engineering, Sydney, 1999
[PEDE00] T. Pedersen, Aspectes of Data Modeling and Query Processing for
complex multidimensional data, PhD thesis, faculty of Engineering
and Science, Denmark, 2000
330
Bibliografie
[PEND99a] N. Pendse, OLAP Applications, http://www.olapreport.com/, 1999

[PEND99b] N. Pendse, Multidimensional data structures,
http://www.olapreport.com/, 1999
[PEND99c] N. Pendse, Database explosion, http://www.olapreport.com/, 1999
[PEND99d] N. Pendse, The origins of today’s OLAP products,
http://www.olapreport.com/, 1999
[PEND97] N.Pendse, R.Creeth, The OLAP Report,
http://www.olapreport.com, 1997
[POKO98] J. Pokorny, Conceptual Modeling in OLAP, Proceeding of EIS,
Aix-en-Provence, 1998
[POWE99] D. J. Power, A brief History of Decision Support Systems, DSS
Resources, http://dss.cba.uni.edu/dss/dsshistory.html, 1999
[RAFA93] M.Rafanelli, F. Ricci, Mefisto: A functional model for statistical
entities, IEEE Transactions on Knowledge and Data Engineering,
1993
[SCHR98] A. Schroff, An Approach to User Oriented Decision Support
Systems, Inaugural Dissertation nr.1208, Druckerei Horn,
Bruchsal, 1998
[SHOS97] A. Shoshani, OLAP and Statistical Databases: Similarities and
Differences, Proc. ACM PODS, 1997
[TEST00] O. Teste, Towards Conceptual Multidimensional Design in
Decision Support Systems, Dexa 2000, LNCS 1873, Londra, 2000
[TPCB98] Transaction Processing Council, TPC: TPC Benchmark,
http://www.tpc.org/dspec.html, 1998
[TRYF99] N. Tryfona, F. Busborg, J. G. Christiansen, StarER: A conceptual
model for Data Warehouse Design, DOLAP, Kansas City, 1999
[TSOI01] A. Tsois, N. Karayannidis, T. Sellis, MAC: Conceptual Data
Modeling for OLAP, Proceedings of the International Workshop
on Design and Management of Data Warehouses, 2001
[VASS00] P. Vassiliadis, Data Warehouse Modeling and Quality Issues, PhD
thesis, Department of Electrical and Computer Engineering
National Technical University of Athens, 2000
[VASS98] P. Vassiliadis, Modeling multidimensional databases, cubes, and
cube operations, Proc. of the 10th SSDBM Conference, Italy, 1998
[VASS99] P. Vassiliadis, T. Sellis, A survey of logical models for OLAP
databases, SIGMOD Record (28) 4, 1999
[VLMI02] M. Velicanu, M. Muntean, I. Lungu, S. Ionescu, Spre noua
economie digitală prin inteligenţa afacerii, Revista Informatică
Economică, vol. V, nr. 4, Bucureşti, 2002
331
Adrese Internet
http://www.dce.ase.ro/
http://www.cncsis.ro/
http://www.arborsoft.com/
http://www.businessobjects.com/
http://www.cognos.com/
http://www.informix.com/
http://www.ibm.com
http://www.holistic.com/
http://www.kenan.com/
http://www.pilotsw.com/
http://www.olapcouncil.org
http://www.olapreport.com/
http://www.oracle.com
http://www.strategy.com/
332

Iniiere in Tehnologia OLAP Teorie I Practic

Î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

Iniiere in Tehnologia OLAP Teorie I Practic

Încărcat de

Drepturi de autor:

Formate disponibile

Cuprins

1. Sistemele OLAP – sisteme suport de decizie moderne ......................... 6

1.1. Locul sistemelor OLAP în evoluţia sistemelor suport de decizie ............................... 6

1.2.1. Sisteme informatice executive ............................................................................ 13

1.2.2. Sisteme suport de decizie spaţiale .................................................................... 14

1.2.3. Sisteme suport de decizie ce utilizează depozite de date .......................... 15

1.2.4. Sisteme OLAP ......................................................................................................... 17

1.2.4.1. Evoluţia sistemelor OLAP ....................................................................... 21

1.2.4.2. Relaţia între depozitele de date şi sistemele OLAP ........................ 24

1.2.4.3. Regulile lui Codd ........................................................................................ 25

1.3. Sisteme informatice pentru inteligenţa afacerilor ...................................................... 39

2. Modele de date multidimensionale pentru sisteme OLAP .................... 36

2.1. Concepte de bază .................................................................................................................. 37

2.1.1. Conceptul de cub n - dimensional ........................................................................ 37

2.1.2. Conceptul de dimensiune ....................................................................................... 41

2.1.3. Conceptul de ierarhie ............................................................................................ 42

2.1.4. Conceptul de măsură .............................................................................................. 45

2.1.5. Conceptul de multicub ........................................................................................... 46

2.1.6. Conceptul de împrăştiere ...................................................................................... 47

2.2. Modele de date OLAP – extensii ale modelului relaţional .......................................... 49

2.2.1. Operatorul Cub de date ........................................................................................ 50

2.2.2. Modelul lui Li Wang ................................................................................................ 54

2.2.3. Modelul lui Kimball ................................................................................................. 55

2.3. Modele orientate pe cuburi ............................................................................................... 59

2.3.1. Modelul lui Agrawal ................................................................................................ 59

2.3.2. Modelul lui Cabibbo ................................................................................................ 62

2.4. Evaluarea modelelor multidimensionale ........................................................................... 69

3. Arhitectura sistemelor OLAP ..................................................................... 76

3.1. Sisteme ROLAP ..................................................................................................................... 77

3.2. Sisteme MOLAP .................................................................................................................... 80

3.3. Sisteme hibride (HOLAP) .................................................................................................. 85

3.4. Arhitectura sistemelor OLAP ........................................................................................... 87

4. Instrumente OLAP ........................................................................................ 92

4.1. Caracteristici logice ............................................................................................................. 92

4.1.1. Structura datelor ................................................................................................... 93

4.1.2. Operaţii ..................................................................................................................... 95

4.1.3. Modul de reprezentare a datelor multidimensionale ..................................... 96

4.1.4. Alte caracteristici logice ...................................................................................... 96

4.2. Caracteristici fizice ............................................................................................................ 97

4.3. Exemple de instrumente OLAP ......................................................................................... 98

4.4. Standarde .............................................................................................................................. 106

5. Proiectarea sistemelor OLAP ..................................................................... 110

5.1. Metoda lui Cabibbo şi Torlone ........................................................................................... 111

5.1.1. Identificarea faptelor, dimensiunilor, ierarhiilor şi măsurilor .................... 112

5.1.2. Restructurarea modelului entitate – asociere ................................................. 113

5.1.3. Derivarea unui graf dimensional .......................................................................... 115

5.1.4. Transformarea în modelul multidimensional conceptual ................................ 116

5.2. Metoda lui Golfarelli ............................................................................................................ 118

5.2.1. Identificarea faptelor .......................................................................................... 119

5.2.2. Construirea unui arbore al atributelor ............................................................. 120

5.2.3. Rafinarea arborelui ................................................................................................ 121

5.2.4. Definirea dimensiunilor ........................................................................................ 122

5.2.5. Definirea măsurilor ............................................................................................... 122

5.2.6. Definirea ierarhiilor .............................................................................................. 123

5.3. Metoda lui Erik Thomsen .................................................................................................... 124

5.3.2. Rafinarea cuburilor n – dimensionale ................................................................. 125

5.3.3. Identificarea ierarhiilor din dimensiuni ........................................................... 126

5.3.4. Identificarea variabilelor .................................................................................... 126

5.3.5. Stabilirea formulelor de calcul şi a tipurilor de agregare ........................... 126

5.3.6. Tratarea fenomenului de împrăştiere ............................................................... 126

5.3.7. Definirea modelelor de calcul complexe necesare analizelor ...................... 127

6. Dezvoltarea sistemelor OLAP cu Oracle Express Objects ................. 132

6.1. Utilitarul Object Browser .................................................................................................. 135

Integrată. Datele trebuie să fie reprezentate, în depozitul de date, într-un