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

Systems) ......................................................................................................................................... 13

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

Administrator ...................................................................................................... 224

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

Tehnologia utilizată Tipuri de SSD-uri LAN Web

SSD-uri de grup SSD-uri orientate pe comunicaţii

Aplicabile la nivel local Aplicabile la nivel global

SSD-uri orientate pe date Client complex Client simplu (de tip browser)

SSD-uri orientate pe documente

Numai documente de tip (.doc), (.xls)

Documente HTML

SSD-uri orientate pe model

Monoutilizator Multiutilizator

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).

Server Web Modele/baza de date

Browser

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

principală a SSD-ului

Utilizatorii: interni/ externi

Scopul: general/ specific

Arhitectura utilizată

Comunicaţii SSD-uri orientate pe comunicaţii

Echipe interne/ parteneri externi

Suport pentru comunicare şi colaborare

Web sau client/ server

Baze de date SSD-uri orientate pe date

Manageri, furnizori

Interogarea unui depozit de date, foloseşte date structurate

Mainframe, client/server, Web

Baze de documente SSD-uri orientate pe documente

Utilizatori interni dar grupul poate fi extins

Căutarea paginilor Web sau a documentelor nestructurate

Client/server, Web

Baze de cunoştinţe SSD-uri orientate pe cunoştinţe

Utilizatori interni, clienţi

Foloseşte reguli, relaţii

Client/server, Web, PC

Modele SSD-uri orientate pe modele

Manageri, clienţi

Foloseşte modele PC,client/server, Web

Modele/ baze de date şi comunicaţii SSD-uri interorganizaţionale /intraorganizaţionale

Utilizatori interni şi externi

Suport pentru intermediari

Client/server, Web

Modele/ baze de date şi comunicaţii SSD-uri bazate pe Web

Utilizatori interni şi externi

Suport pentru orice sarcină a SSD-ului

Web

12


Componenta principală a SSD-

ului

Utilizatorii: interni/ externi

Scopul: general/ specific

Arhitectura utilizată

Modele/baze de date SSD-uri specializate

Utilizatori interni

Specializate pe anumite domenii de activitate sau cu un scop mai general (generator SSD)

PC, client/server

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 mari pentru firme mici, la nivel de departament

Domenii multiple un singur domeniu Surse de date numeroase puţine Dimensiunea 100 Gb-Tb < 100 Gb Timpul de implementare

ani luni

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

mari de date

Multe niveluri

Mulţi factori

Mulţi utilizatori

Oportunitate Acces rapid Calcule rapide

OLAP OLAP

OLAP OLAP

OLAP OLAP

DW OLAP

Acurateţe Date de bază exacte Expresivitate de calcul

DW OLAP

DW OLAP

DW OLAP

DW

Inteligibilitate Interfaţă prietenoasă Viziuni flexibile

OLAP OLAP

OLAP OLAP

OLAP OLAP

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

Aplicaţie Caracteristici Procesarea tranzacţională

(OLTP) Procesarea

analitică (OLAP) Volum de date pe tranzacţie

mic mare

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 datelor

BI (∀ tip de dată+∀ tip de analiză) Tehnici de analiză a datelor

Data mining

Cerere

OLAP

Depozit de date / centru de date

BDMD

Alte stocuri de informaţii

SSD hibride orientate pe cunoştinţe şi date

SSD cu depozite de date

Sisteme ROLAP

Sisteme MOLAP

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.

Ges

tiune

a m

etad

atel

or

adm

inis

trare

Aplicaţii pentru inteligenţa afacerilor

Accesul interfeţele aplicaţiilor servere de aplicaţii

Instrumente pentru construirea şi modelarea depozitelor de date

Gestiunea datelor

Centre de date

Alte stocuri de informaţii

Depozit central

Date externe şi operaţionale

Instrumente suport de decizie Cerere şi raportare OLAP data mining

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

Iniţiere în tehnologia OLAP-teorie şi practică 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 doara

Hune doara

Deva Bacău Bacău Piatra Neamţ

3410

3310 6100 8100

Nokia Membru dimensiunea Produs (ierarhia: produs, model produs)

10 22 10 29 21 92 21 12 34 22 8

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

Iniţiere în tehnologia OLAP-teorie şi practică 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 Martie Nokia vânzări

Vânzări (buc)

telefoane mobile Nokia 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.

cosmetice electronice

sapun şampon parfum acasă birou

fax xerox radio casetofon

TV

cu baterii electric

Toate produsele

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ă.

Figura 2.4 Ierarhie simetrică

L

Trim1 Trim2 Trim3 Trim4

L L L L L L L L L L L

an

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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică î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 Hypercubul pentru vânzări Hypercubul pentru angajaţi

Locaţie Timp ○ ○ ○ ○

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 pro emplu, în loc de a introduce valoare null pen date cu informaţii despre angajaţi, când un an introduce valoarea validă “Nu” în câmpul nu tabelă separată cu informaţii despre soţii. Îm e ar putea elimina datele invalide. Cele două ebuie totuşi să fie tratate individual, deoarece duri.

T=adevărat A=lipsă F=fals I=invalid

Figura 2.7 Logica c

2.2 Modele de dat

Aşa cum se observă dezvoltat pe două direcţiimodele orientate pe cub.

Multe din modelele exemplu, Gray [GRAY96GROUP BY din limbajul Spentru aplicaţiile OLAP. Mşi Lakshmanan [GYSS97]urmează, se vor analiza cât

iectări proaste a bazei de date. De extru “numele soţiei ” într-o bază degajat nu are soţie, ar fi mai bine de a

mit “este căsătorit”. Se poate crea obunătăţirea proiectării bazei de dat tipuri de date (lipsă şi invalide) tr ele afectează calculele în diferite mo

P Not (P) T F A A I I F T

u patru valori a modelului relaţional, versiunea 2

e OLAP-extensii ale modelului relaţional

în figura 2.8 modelele de date multidimensionale s-au şi anume: modele extensii ale modelului relaţional şi

propuse sunt extensii ale modelului relaţional. De ] propune operatorul CUBE ce generalizează clauza QL şi care este o abordare foarte pragmatică, potrivită odelul lui Li şi Wang [LIWA96] şi modelul lui Gyssens constituie o extensie a algebrei relaţionale. În cele ce eva 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).

Model cu facilităţi extinse –Lehner

Concepte extinse

Modele extensii ale algebrei relaţionale

Operatorul Data Cube-Gray

Algebra de grupare-modelul Li, Wang

Modelul Gyssens

Modelul Agrawal

Modelul Cabbibo

Modelul Vassiliadis

Modelul Golfarelli

Modelul StarER

Modelul Teste

Modelul Rafanelli

Modelul Guazzo

Modelul Blanschka

Modelul lui Kimball

Modelul MAC

Modele orientate pe cub

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

from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat 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

from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat group by i.codfac, f.an union select i.codfac, ‘ ‘, sum(f.nrcadre) profesori from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat group by i.codfac, ‘ ‘ union select ‘ ‘, ‘ ‘, sum(f.nrcadre) profesori from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat 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

from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat 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

from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat 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 where f.codcat=i.codcat 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 from F2_indicatori_performanţă f, institutii i where f.codcat=i.codcat 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.

Tabela de fapte Vânzări

Dimensiunea Client

Dimensiunea Timp

Dimensiunea Locaţie

Dimensiunea Produs

Dimensiunea Vânzător

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 Client Locaţie Vânzător Produs

Tabela de fapte Vânzări

data

săptămâna luna

fabrica

regiune

model

produs

vânzător

locaţie

piaţa de desfacere

regiune

client

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.

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

Timp

Client

luna

ziua Ora

Moment

zona contract

Număr_telefon

numeric

şir de caractere

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


Relaţie de clasificare

Fapt

Nivel

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).

garaj regiune

district

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

Iniţiere în tehnologia OLAP-teorie şi practică 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=costuri componente sal=salarii costt=costuri totale nrpers=număr persoane

an

luna

ziua

client

model masina garaj regiune

Tip garaj

Costc

sal

costt

nrpers

vârsta

durata

venit

tara marca

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 modelului relaţional

Modele orientate pe cub

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 dimensiunilor complexe Modelarea măsurilor complexe

Formalism pentru limbaj de interogare

Model

Separa- rea

expli- cită

structura/

conţinut

Nivel ierarhic

Membri

Forma- lism

pentru niveluri

Atri- bute

dimen sio nale

Sime- trie

măsuri şi

membri tip

înreg Deriv Adititiv Tip Ierarhii ad-hoc

Funcţii de

agreg. defi-

nite de utiliz.

Agrawal Nu Nu

Nu

Da Nu Da Nu Nu Nu algebra

Da Da

Li/Wang Da Da

Da

Da Da Nu Nu Nu Nu algebra

Da Da

Gyssens Da Da

Da

Da Da Da Da Nu Nu algebra si calcul

Da Da

Cabbibo Da Da Da

Da Nu Da Nu Nu Nu algebra si calcul

Da Da

Vassiliadis Nu Da Da Da Nu Da Nu Nu Nu algebra

Nu Nu

Lehner Da Da Da Da Da Nu Nu Nu Pe măsura

algebra

Nu Nu

Golfarelli Da Da Da Nu Da Nu Da Da Da algebra

Da Nu se specifica

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-

bra Nu Nu

Teste Da Da Da Da Da Da Nu Nu Nu algebra

Nu Nu

Tabelul 2.4

Evalurea modelelor de date multidimensionale conform cerinţelor prezentate în [VASS99]

Spaţiu

multidimensional Limbajul de interogare Arhitectura

implementată Modele Cuburi Ierarhii Procedural Declarativ Vizual

ROLAP MOLAP

Orientat pe relaţional

Gray T - - extensie SQL

- da -

Li/Wang T Implicit algebra - - da - Gyssens T da algebra calcul - da - Teste T da algebra - - da - StarER T da - - - da - Orientat pe cub

Agrawal C - algebra - - da da

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

Arhitectura sistemelor OLAP

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

Iniţiere în tehnologia OLAP-teorie şi practică 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 Motor ROLAP SGBDR

optimizarea cerererii procesarea multidimensională multidimensionale generarea cererii transformare relaţionale

metadate

Interfaţa multidimensională

SQL interfaţa relaţională

Clienţi OLAP

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.

Figura 3.2 Utilizarea sistemelor MOLAP sau ROLAP pentru diferite tipuri de aplicaţii SSD

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

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

Iniţiere în tehnologia OLAP-teorie şi practică 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 multidimensionale

ROLAP/Baze de date relaţionale

Spaţiul de disc ocupat mare, dacă agregatele sunt antecalculate (explozia datelor derivate şi fenomenul de împrăştiere)

posibil zero, dacă sunt folosite baze de date existente nemodificate (depozite de date virtuale), dar poate fi mare dacă noi structuri sunt create

Performanţa la încărcarea datelor

moderată scăzută

Viteza de calcul mare mică Volumul datelor atomice mediu la mare (Mb-Gb) extrem de mare (Gb-Tb) Posibilitatea de acces la date de către alte aplicaţii (integrare cu alte sisteme existente)

limitată excelentă în principiu, dar poate fi limitată dacă este folosită o schemă complexă

Accesul la date încet şi adesea limitat, citire/scriere

performanţă moderată

Dimensionalitate mică (modele multidimensionale simple, 5-10 dimensiuni)

mare (modele multidimensionale complexe)

Modificarea dimensiunilor

bună dar baza de date trebuie să fie off-line

bună

Volatilitatea datelor adecvate pentru volatilitate scăzută

adecvate pentru volatilitate ridicată

Facilităţi de administrare a SGBD-ului

puţine foarte puternice

Uşurinţa de a construi aplicaţii de către utilizatorii finali

moderată aproape imposibilă

Arhitectura client/server pe două sau trei niveluri, lipsa standardelor

client/server pe două sau trei niveluri, arhitectură deschisă, standarde

Managementul metadatelor

nu da

Limbaj de interogare specific fiecărui instrument SQL Facilităţi de calcul foarte complexe, în toate

dimensiunile limitate

Joncţiuni nu da Agregări dinamice nu da Partiţionarea datelor nu da Cereri paralele nu da

83


Criterii MOLAP/Baze de date multidimensionale

ROLAP/Baze de date relaţionale

Algoritmi hash da da Indexare da da Măsuri derivate da da Comparaţii ale perioadelor de timp

da da

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).

1. Fişiere de date

2

3

4

5 Interfaţa

Calcule ad hoc multidimensionale

Calcule multidimensionale în lot

Se împart între client şi server depinde de locaţia datelor

Calcule făcute în avans pe server

Motor pentru gestiunea datelor-baze de date relaţionale sau multidimensionale

Datele şi agregatele stocate trebuie să fie distribuite între utilizatori

Gestiunea datelor

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

date Calcule multi dimensionale în lot

Calcule multi dimensionale ad-hoc

Interfaţa

Figura 3.5 Server de fişiere-client OLAP

Server de bază de date relaţional client OLAP -

Gestiune date

Calcule multi dimensionale în lot

Interfaţa Calcule multidimensionale ad-hoc

Fişiere de date

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 date



Interfaţa Fişiere de date

Figura 3.7 Arhitectura pe trei niveluri

Server OLAP client OLAP

Fişiere de date

Gestiune date



Interfaţa

Figura 3.8. Arhitectura client/server (Server OLAP/client OLAP)

88


Server de bază de date relaţional Server de aplicaţii client WEB

Fişiere de date

Gestiune date



Interfaţa

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 Numai nivelul 1 este pe un server de fişiere, nivelurile 2-5 pe client

Uşor de implementat, independent de protocoalele de reţea, server ieftin. Orice server de fişiere poate fi folosit

Nu este chiar o arhitectură client/server. Procesarea nu se face pe 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 Nivelurile 1 şi 2 sunt pe un server de baze de date relaţional, nivelurile 3-5 pe client

În funcţie de aplicaţie poate fi gestionată securitatea pe server. Reduce încărcarea reţelei, deoarece datele pot fi selectate şi procesate parţial de serverul de bază de date, înainte de a fi trimise la client pentru 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.

Cere un SGBD potrivit pe server, adaugând la costuri şi complexitatea. Poate genera trafic excesiv în reţea, dacă toate procesările multidimensionale sunt făcute pe client.

Arhitectura pe trei niveluri Nivelurile 1 şi 2 pe un server de baze de date relaţional, nivelul 3 pe unul sau mai multe servere de aplicaţii, nivelurile 4 şi 5 pe client. Nivelul 3 poate avea, de asemenea, o bază de date locală pentru stocarea informaţiilor multidimensionale.

Distribuţie flexibilă a procesării între serverul de bază de date şi serverele de aplicaţii. Se reduce traficul în reţea pentru că datele pot fi procesate acolo unde sunt stocate. Funcţionalitate ridicată prin utilizarea unui SGBD relaţional complex şi a unui server de aplicaţii puternic. Scalabilitate bună în funcţie de dimensiunea aplicaţiei.

Greu de implementat şi se cere experienţă în reţele. Adesea mai puţin deschis decât arhitectura cu bază de date distribuită . Scalabilitatea în funcţie de numărul de utilizatori poate fi restricţionată de limitele fiecărui server de bază de date sau de aplicaţii .

Server OLAP/ client OLAP Nivelurile 1-3 pe un server de bază de date multidimensional, nivelurile 4 şi 5 pe client.

Performanţă optimă cu trafic în reţea minim. Costuri hardware mici. Uşor de implementat actualizarea multiutilizator a datelor multidimensionale, cu securitate multidimensională la nivel de detaliu. Aplicaţiile complexe sunt mai simplu de implementat.

În general o arhitectură mai puţin deschisă. Instrumentele de acest tip sunt adesea mai specializate şi mai puţin potrivite pentru utilizare generală.

WEB OLAP pe trei niveluri Nivelurile 1 şi 2 sunt pe un server relaţional, nivelurile 3 şi 4 pe serverul de aplicaţii şi nivelul 5 pe un browser WEB conectat prin Internet sau Intranet.

Uşor de utilizat pentru un număr mare de utilizatori, incluzând acei utilizatori din afara organizaţiei. Reţea la un cost mic. Nu cere software dedicat pe client, reducând costurile cu software-ul. Suportă o varietate de platforme.

Funcţionalitate şi performanţă redusă. Reduce manipulările de date la nivel de client.

89

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică (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 de aplicaţie

Motorul OLAP

Depozitul de date

Componenta de 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

Iniţiere în tehnologia OLAP-teorie şi practică Relational Storage Manager (RSM) separă motorul OLAP de baza de date relaţională.

Figura 4.2 Arhitectura pentru Essbase şi DB2 OLAP Server

Componentele de prezentare şi aplicaţie Motorul OLAP SQL

MS Excel Lotus

Essbase Objects

Essbase Application Manager

Essbase Currency Conversion Module

Essbase Adjustment Module

Essbase Spreadsheet Add-In

RDBMS Management Tools

Essbase API

Motor Essbase OLAP

Essbase API

Motor Essbase OLAP

Multidimensional Storage Manager Relational Storage Manager

Fişiere/baze de date multidimensionale Bază de date

relaţională (schema stea)

SQL Decision Support

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).

Figura 4.3 Etapa online

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

Clientul Express generează o cerere de date

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.

Baza de date Express

Aplicaţie Express

Express RAM RAM Runtime Build Modul modul

Depozit de date

Relation Access Administrator

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 Listener

Web Listener Interface

Express Server Web Developer’s Modules Toolkit

Web browser

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

Iniţiere în tehnologia OLAP-teorie şi practică 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-

dimensional Limbajul

de interogare Stocarea datelor

Cuburi Ierarhii Procedu- ral

Decla- rativ

ROLAP MOLAP

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 stocare a datelor multidimensionale Modul de procesare

multidimensională BDR BDMD Fişiere client SQL în mai mulţi paşi 1.

Microstrategy

Motor OLAP pe server 2. IBM DB2 OLAP Server Informix Metacube Microsoft OLAP Services Oracle Express Pilot Analysis Server Seagate Holos Applix TM-1 White Light

4. Comshare Decision Essbase Oracle Express, Seagate Holos, Gentia Microsoft OLAP Services Power Play Enterprise Server Pilot Analysis Server Applix TM-1

Motor OLAP pe client 3. Oracle Discoverer Informix MetaCube

5. Dimensional Insight Comshare FDC

6. Brio Enterprise, 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 OLAP

Vizualizarea datelor

Tipul de aplicaţii Modul de

stocare

Modul de procesare

Tipul de arhitectură

Platforma utilizată

Limbajul utilizat

Power Play Cognos

Tabele Grafice, Rapoarte

Analiza vânzarilor Analiză financiară Controlul calităţii

Fişiere BDR BDM

Motor OLAP pe client/ server

Client/ server

Server Unix WinNT, Client Windows

APL2000 pentru aplicaţii financiare

DecisionBase OLAP Computer Associates

Rapoarte HTML, Grafice

Analiza vânzărilor BDM Motor OLAP pe server

Client/ server pe trei niveluri

Windows Orientat obiect

Oracle Express Oracle

Rapoarte, tabele, grafice

Analiza vânzărilor Analiza financiară

BDR BDM Fişiere

Motor OLAP pe server / client

Client/ Server, PC

Server WinNT Client Windows

Express Basic

Business Objects

Rapoarte Analiza vânzărilor Analiza financiară

Fişiere Motor OLAP pe client

Client/ server pe două/trei niveluri

WinNT Visual Basic

DSS Micro strategy

Rapoarte, grafice Marketing BDR SQL în mai mulţi paşi

Client/ server


SQL

Acumate Kenan Systems

Rapoarte Telecomunicaţii, Servicii financiare, marketing, Analiza vânzărilor, previziuni, Segmentarea pieţei, Analiza clienţilor

BDM Motor OLAP pe server

Client/ server


Limbaj multidim MSPL

Informix Metacube Informix Software

Rapoarte, grafice Analiza vânzărilor Analiză financiară

BDR Motor OLAP pe server/ client

Client/ server pe două şi trei niveluri

Server WinNT Unix, Client Windows

Limbaj OO, SQL

108


Produs OLAP

Vizualizarea datelor

Tipul de aplicaţii Modul de

stocare

Modul de procesare

Tipul de arhitectură

Platforma utilizată

Limbajul utilizat

DB2 OLAP IBM

Rapoarte Telecomu nicaţii (Decision Edge), marketing, previziuni

BDR BDM

Motor OLAP pe server (motor Essbase)

Client/ server pe trei niveluri

Server WinNT, OS/2 Unix

SQL Interfaţă API pentru Visual Basic, C

Microsoft OLAP Services Microsoft

Grafice, rapoarte Previzionări Analiză financiară

BDR BDM

Motor OLAP pe server

Client/ server

Server WinNT Unix VAX/ VMS Sun, Mac, Aix

Visual Basic

Essbase Arbor Software

Rapoarte, grafice Analiza de piaţă Analiza profitabilităţii, Planificare, Analiza bugetară, Previzionare, EIS

BDM Fişiere BDR

Motor OLAP pe server

Client/ server

server WinNT OS/2 IBM-AIX Sun Solaris AS/400 Client Windows Unix

Interfaţă API pentru Visual Basic, C, Power Builder

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

Proiectarea sistemelor OLAP 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).

Orientată pe cereri Orientată pe surse de date

Identificarea măsurilor (variabilelor)Identificarea dimensiunilor şi a ierarhiilor Identificarea hypercubului sau a structurii multicub

Identificarea faptelor Identificarea dimensiunilor şi a ierarhiilor Identificarea măsurilor

Modelarea multidimensională datelor

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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Proiectarea sistemelor OLAP 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

Iniţiere în tehnologia OLAP-teorie şi practică 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 denumire

Produs Cost produs

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

Proiectarea sistemelor OLAP

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

Iniţiere în tehnologia OLAP-teorie şi practică “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 Timp Locatie Client

sex

ocupaţieprinc

vârsta

client

oraş

nume

categorie

zona

marca

produs

vânzare

magazin

cost

venit

zi

Perioada specială

adresa

valoare

luna

trimestru

an

Figura 5.5 Graful dimensional

Client Sex Vârsta Oraş etc

Locaţie Magazin Oraş Zona etc

Cost

Vânzare

Timp Ziua Luna Trimestru etc

Produs Denumire Marca Categorie 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 informatic existent

documentaţia existentă

schema bazei de date operaţionale

Proiectant, manageri ai sistemului informatic

Specificarea cerinţelor

schema bazei de date operaţionale

faptele Proiectant, utilizatori finali

Proiectarea conceptuală (modelul multidimensional)

schema bazei de date operaţionale, faptele

modelul multidimensional

Proiectant

Validarea modelului multidimensional

modelul multidimensional conceptual

modelul multidimensional validat

Proiectant, utilizatori finali

Proiectarea logică modelul multidimensional, modelul logic utilizat

modelul logic al depozitului de date

Proiectant

Proiectarea fizică modelul logic al depozitului, SGBD-ul ales

modelul fizic al depozitului

Proiectant

Î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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Proiectarea sistemelor OLAP 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


Implementarea sistemului OLAP

Întreţinerea şi funcţionarea sistemului OLAP

Cerinţe orientate pe proces

Cerinţe orientate pe informaţii

Orientată pe cereri Orientată pe sursele de date

Rafinarea modelului multidimensional

Proiectarea modelului multidimensional conceptual

Validarea modelului multidimensional

Proiectarea logică (BDR/BDM)

Construirea şi testarea sistemului OLAP

Proiectarea fizică

Studiul şi analiza procesului decizional curent şi a cerinţelor informaţionale ale utilizatorilor

Iniţierea proiectului (definirea problemei)

Figura 5.11 Cadru generalizat al etapelor de proiectare şi realizare a sistemelor OLAP

Figura 5.11 Cadru generalizat al etapelor de proiectare şi realizare a sistemelor OLAP

130


Tipuri de cereri, ipoteze,….

Analiza datelor Scenarii

Obiectivele proiectului Subiecte /domenii

Modele multi dimensionale iniţiale Cerinţe validate

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.

Nucleul (limbajul Express)

Utilitare pentru administrare

Express Administrator

BDR (depozite de date)

BDMD

Relational Access Manager

fişiere Express Instance Manager

Instrumente de dezvoltare Express Analyzer

Express Web Publisher

Financial Analyzer

Sales Analyzer

Express Objects

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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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, max)

Funcţii şi formule Express folosind dimensiunile

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

Iniţiere în tehnologia OLAP-teorie şi practică (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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică (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.

Clienţi

Organizaţii executând Procese

Produse şi servicii: Învăţământ Cercetare Suport financiar Sănatate Alimentaţie …….

Resurse: Bani Oameni Experienţa Munca Facilităţ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.”

Exemple de dimensiuni Client: Studenţi Stat/societate Clienţi interni

Conţinut “fapte”

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

Exemple de dimensiuni Resurse: Bani Organizaţii Personal Echipamente

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

Proiectarea şi realizarea unui sistem OLAP 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.

Locaţie geografică Cod magazin Denumire Adresa, Oraş Judeţ, Regiune Ţara, Manager magazin, Telefon, fax, Suprafaţă

Timp Cod data Ziua din săptămâna Numărul zilei în luna Numărul săptămânii în an Luna Trimestru An Perioada fiscală Sezon, Eveniment

Măsuri: Cantitatea vândutâ Volumul vânzărilor Costurile Numărul de clienţi

Produs Codprodus Marca Subcategoria Categorie Tipul de ambalaj Greutatea Culoare Dimensiune Fabricant

Cubul n-dimensional pentru analiza vânzărilor

Promoţie Cod Denumire Tipul de reducere a preţului Tipul de publicitate Costul promoţional Data începerii promoţiei Data de sfârşit

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ă).

Produs asigurat Cod produs asigurat Descriere Tip produs asigurat

Agent Cod agent Nume Tip agent Locaţie

Tranzacţie Cod tranzacţie Descriere Motiv

Riscul Cod poliţă Grad de risc

Măsuri: Suma asigurată Suma încasată Rata primă etc

Asigurat/ coasigurat/ contractant Cod Nume Adresa Tip Atribute demografice

Cubul n-dimensional pentru analiza poliţelor de asigurare

Tipul de asigurare Cod Descriere Segment piaţă

Timp Cod data Ziua din săptămână Perioada fiscală

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

Iniţiere în tehnologia OLAP-teorie şi practică 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: p3=ponderea indicatorului n2a în n2 (p3=0.5) p4=ponderea indicatorului n2b în n2 (p4=0.5) N2=numărul total de contracte de cercetare internaţionale Ncd=numărul total de cadre didactice Nc=numărul total de cercetători 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

Iniţiere în tehnologia OLAP-teorie şi practică p5=ponderea indicatorului n3a în n3 (p5=0.5) p6=ponderea indicatorului n3b în n3 (p6=0.5) N3=numărul total de contracte cu companii din ţară şi contracte obţinute în cadrul PNCD Ncd=numărul total de cadre didactice Nc=numărul total de cercetători 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 /Np d

cd

n4.2=c8*N /Nd unde: ftd

p7=ponderea indicatorului n4.1 în n4 (p7=0.3) p8=ponderea indicatorului n4.2 în n4 (p8=0.7) N =numărul total conducători de doctorat d

cd

N =numărul total teze de doctorat finalizate ftd

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: p9=ponderea indicatorului n5.1 în n5 (p9=0.5) p10=ponderea indicatorului n5.2 în n5 (p10=0.5) 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

Proiectarea şi realizarea unui sistem OLAP 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: p11=ponderea indicatorului n6.1 în n6 (p11=0.3) p12=ponderea indicatorului n6.2 în n6 (p12=0.7) 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: p13=ponderea indicatorului n8.1 în n8 (p13=0.5) p14=ponderea indicatorului n8.2 în n8 (p14=0.5) 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

Iniţiere în tehnologia OLAP-teorie şi practică 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: p15=ponderea indicatorului n9.1 în n9 (p15=0.4) p16=ponderea indicatorului n9.2 în n9 (p16=0.3) p17=ponderea indicatorului n9.3 în n9 (p17=0.3) 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.

Dimensiunea Tip_proiect

Dimensiunea Publicaţie

Cubul n-dimensional

Măsuri: Număr de publicaţii Rata publicaţiilor Număr de proiecte Valoarea contractată (lei) Valoarea contractată (dolari) Număr de cadre didactice implicate în cercetare etc

Dimensiunea Timp

Dimensiunea Centre

Dimensiunea Institut (Universitate)

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 ), numărul de teze de doctorat

finalizate (N ), 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.

dcd

ftd

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 , N f , N7, N91, N92, N93, N10 au ca dimensiuni: Timp, Institut (universitate).

dcd td

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

Proiectarea şi realizarea unui sistem OLAP 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 AISI AS CN CI ANER ACNCSIS

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 d

cd , N , N7, N91, N92, N93, N10; ftd

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

Proiectarea şi realizarea unui sistem OLAP 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 ,

N , N7, N91, N92, N93, N10 }

dcd

ftd

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

Iniţiere în tehnologia OLAP-teorie şi practică 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 : number(3), N : number(3), N7: number(3), N91: number(3), N92: number(3), N93: number(3), N10: number(3) cu dimensiunile: Timp (

dcd

ftd

an: varchar2(4)), Instituţii (Universităţi) (codcat: varchar2(5), dencat: varchar2(60),

266

Proiectarea şi realizarea unui sistem OLAP codfac: varchar2(5), denfac: varchar2(60), codinst: varchar2(5), deninst: varchar2(60)) (figura 9.11).

FS_1

an

finanţator tip_proiect catedra facultate universitate

valoare_dolValoare_lei

nrproiecte

FP_2 an catedra facultate universitate

nrtesa

ncdnrcadre

nrdoctNrstud_cer

nrstud

N dcd

N7

N10

FP_1 catedra facultate

an

subcat categorie

nrpub

FS_2

centru Tip_proiect finanţator

an

vallei

nrpro valdol

universitate

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

Proiectarea şi realizarea unui sistem OLAP 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 (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.

ftd

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

Iniţiere în tehnologia OLAP-teorie şi practică “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

Proiectarea şi realizarea unui sistem OLAP 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

Iniţiere în tehnologia OLAP-teorie şi practică 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' limit institutii to fac_set inst_inst='ASE' define niv_inst relation nivel_institut<institutii> limit institutii to cat_set niv_inst='CATEDRE' limit institutii to fac_set 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

Proiectarea şi realizarea unui sistem OLAP “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' 'CEFIMO' 'ECOINFOSOC' centre_centre='ASE' “definire relaţia niv_inst define niv_inst relation nivel_institut<institutii> limit institutii to cat_set niv_inst='CATEDRE' limit institutii to fac_set 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

Iniţiere în tehnologia OLAP-teorie şi practică “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' 'CEFIMO' 'ECOINFOSOC' “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

Proiectarea şi realizarea unui sistem OLAP “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 ,

N , N7, N91, N92, N93 şi N10.

dcd

ftd

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

Proiectarea şi realizarea unui sistem OLAP 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

Iniţiere în tehnologia OLAP-teorie şi practică 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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ă): Sub AfterItemClick () evolutie_volumul_finantarii_lei.ShowModal End Sub Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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): Sub AfterItemClick ()

293

Iniţiere în tehnologia OLAP-teorie şi practică Dim tStr as String Dim iPageResult as Integer iPageResult = evolutia_vallei_centre.ShowModal() pagMain.SetFocus End Sub Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = evolutia_valdol_centre.ShowModal() pagMain.SetFocus End Sub Opţiunea commanditem8 (Text: &Top 3 (facultăţi)) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = top.ShowModal() pagMain.SetFocus End Sub Opţiunea commandtopcentre (Text: &Top 3 (centre de cercetare)) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = topcentre.ShowModal() pagMain.SetFocus End Sub Opţiunea commanditem16 (Text: E&xit) are ataşat următorul cod: Sub AfterItemClick () 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) : Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = linkview1.ShowModal() pagMain.SetFocus End Sub

294

Anexa 2 Sub AfterItemClick () 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = incarcare.ShowModal() pagMain.SetFocus End Sub Opţiunea commanditem6 (Text: &Procentul de participare la activitatea de cercetare) are ataşat următorul cod: Sub AfterItemClick () 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer 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: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult =evolutie_publicatii.ShowModal() pagMain.SetFocus End Sub

295

Iniţiere în tehnologia OLAP-teorie şi practică Opţiunea commanditem4 (Text: &Rata publicaţiilor) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = ratapublicatii.ShowModal() pagMain.SetFocus End Sub Opţiunea commanditem8 (Text: &Granturi câştigate (evoluţia indicatorului N1)) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = indicatoruln1.ShowModal() pagMain.SetFocus End Sub Opţiunea commandvtgn (Text: &Granturi câştigate (evoluţia indicatorului Vtgn)) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = indicatorulvtgn.ShowModal() pagMain.SetFocus End Sub Opţiunea commanditem2 (Text: &Baza de date) are ataşat următorul cod: Sub AfterItemClick () Dim tStr as String Dim iPageResult as Integer iPageResult = pgIterator1_1.ShowModal() pagMain.SetFocus End Sub Sub AfterItemSelect () Dim tStr as string, tMsg as String If ( it.ItemStyle = 2) Then 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: Sub AfterItemSelect () Dim tStr as string, tMsg as String If ( it.ItemStyle = 2) Then 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: Sub AfterItemClick () pagHelpAbout.ShowModal End Sub Opţiunea commanditem1 (Text: Facultăţile din ASE) are ataşat următorul cod: Sub AfterItemClick () institutii.showmodal End Sub Opţiunea commanditem2 (Text: Proiecte de cercetare) are ataşat următorul cod: Sub AfterItemClick () ierarhiaproiecte.showmodal End Sub Opţiunea commanditem3(Text: Tipuri de publicaţii) are ataşat următorul cod: Sub AfterItemClick () 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

Iniţiere în tehnologia OLAP-teorie şi practică (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 ataşează următorul cod: 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică ' '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 () msgbox container.explicatie, 64, me.text 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

Iniţiere în tehnologia OLAP-teorie şi practică 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 () msgbox container.explicatie, 64, me.text 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

Iniţiere în tehnologia OLAP-teorie şi practică 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: Sub AfterRun (Flags As Integer) 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: Sub AfterRun (Flags As Integer) 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: Sub AfterHighlight () 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: Sub AfterHighlight () Dim persSel as Selection set persSel = Graph3.GetSelection("INSTITUTII") persSel.StatusScript = "Limit INSTITUTII to '" & DimLB2_grafic.FocusValueText persSel.AutoSort = TRUE End Sub

311

Iniţiere în tehnologia OLAP-teorie şi practică 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 ataşează următorul cod:

313

Iniţiere în tehnologia OLAP-teorie şi practică Sub AfterRun (Flags As Integer) 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 () application.showhourglass = true table1.datacube.autorefreshdata = false 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 table1.datacube.autorefreshdata = true 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 application.showhourglass = true table1.datacube.autorefreshdata = false 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: table1.datacube.autorefreshdata = true 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

Iniţiere în tehnologia OLAP-teorie şi practică 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: Sub AfterRun (Flags As Integer) 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: Sub AfterHighlight () 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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

Iniţiere în tehnologia OLAP-teorie şi practică 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' group by proiecte.an, persoane.codcat; 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 from proiecte, pers_proi, persoane where proiecte.cod=pers_proi.cod and persoane.codp=pers_proi.codp and persoane.functia='S' group by proiecte.an, persoane.codcat; 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 from proiecte, pers_proi, persoane where proiecte.cod=pers_proi.cod and persoane.codp=pers_proi.codp and persoane.functia='T' group by proiecte.an, persoane.codcat;

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

http://www.redbooks/ibm/com

http://www.redbooks/ibm/com

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

http://dssresources.com/ dssbook/

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

Iniţiere în tehnologia OLAP-teorie şi practică. [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

http://www.dbmsmag.com/9708d15.html

http://www.he.net/~metadata/standards/

http://www.microsoft.com/data/oledb/olap/

http://www.olapcouncil.org/research/glossary.htm

http://www.olapcouncil.org/research/bmarkly.htm

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

http://www.olapreport/MDstructures

http://www.olapreport.com/



http://www.olapreport.com/

http://dss.cba.uni.edu/dss/dsshistory.html

http://www.tpc.org/dspec.html

Iniţiere în tehnologia OLAP-teorie şi practică. 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.comhttp://www.holistic.com/ http://www.kenan.com/ http://www.pilotsw.com/ http://www.olapcouncil.org http://www.olapreport.com/http://www.oracle.comhttp://www.strategy.com/

332

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.oracle.com/

http://www.strategy.com/

iniiere in tehnologia olap teorie i practic

Documents