1

ACADEMIA DE STUDII ECONOMICE FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ

ECONOMICĂ

SOLUŢII INFORMATICE PENTRU MANAGEMENTUL

STRATEGIC

TEZĂ DE DOCTORAT

Conducător ştiinţific: Doctorand:

Prof. univ. dr. Ion LUNGU Asist. univ. drd. Adela BÂRA

BUCUREŞTI 2007

2

CUPRINS: INTRODUCERE 5

CAPITOLUL I. MANAGEMENTUL STRATEGIC AL ORGANIZAŢIEI 9 1.1. Rolul şi funcţiile managementului organizaţiei 9

1.2. Procesul decizional şi elaborarea deciziilor 10

1.3. Nivelurile de management ale organizaţiei 12

1.4. Sistemul informatic – instrument al managementului organizaţiei 16

1.5. Tipologia sistemelor informatice utilizate în managementul organizaţiei 18

CAPITOLUL 2. SOLUŢII DE SISTEME INFORMATICE PENTRU MANAGEMENTUL STRATEGIC 21

2.1. Sistemele informatice executive – suport pentru managementul strategic 21

2.2. Caracteristici ale sistemelor informatice executive 26

2.3. Aspecte comparative între MIS, DSS ŞI EIS 28

2.4. Tehnologii utilizate în realizarea sistemelor informatice executive 34

2.5. Arhitectura sistemelor informatice executive 35

CAPITOLUL III. SOLUŢII DE ORGANIZARE A DATELOR ÎN DEPOZITE DE DATE (DATAWAREHOUSES) 40 3.1. Caracteristici ale organizării datelor în depozite de date 43

3.2. Arhitectura depozitelor de date 44

3.3. Trecerea de la modelul relaţional la modelarea multidimensională 48

3.4. Modelul de date multidimensional 49

3.5. Operaţii realizate asupra modelului multidimensional 58

3.6. Analiza comparativă a performanţelor obţinute în urma implementării diferitelor tipuri de depozite de date 62

CAPITOLUL IV: SOLUŢII DE ANALIZĂ A DATELOR - TEHNOLOGIA OLAP (ON-LINE ANALYTICAL PROCESSING) 67 4.1. Cerinţele funcţionale ale sistemelor OLAP 68

4.2. Arhitectura sistemelor OLAP 73

4.3. Modele de date multidimensionale utilizate în sistemele OLAP 77

4.4. Locul tehnologiei OLAP în arhitectura depozitului de date 80

CAPITOLUL V. SOLUŢII DE EXTRAGERE A CUNOŞTINŢELOR DIN DATE - DATA MINING 82 5.1. Etapele procesului de extragere a cunoştinţelor din date 85

5.2. Sistemele OLAM (On-Line Analytical Data Mining) 86

5.3. Metode şi algoritmi de extragere a cunoştinţelor din date. Tipuri de invăţare 88

5.4. Validarea rezultatelor obţinute în urma aplicării metodelor de extragere a cunoştinţelor 95

CAPITOLUL VI –SOLUŢII DE EXTRAGERE ŞI OPTIMIZARE A CERERILOR DE REGĂSIRE DIN DEPOZITELE DE DATE 97 6.1. Soluţii de interogare a datelor din depozite de date utilizând limbajul SQL şi funcţiile analitice 97

6.2. Algoritmi de optimizare a cererilor de regăsire pentru depozitele de date 107

6.2.1. Soluţii de optimizare a cererilor realizate pe o singură tabelă 110

6.2.2. Soluţii de optimizare a cererilor cu joncţiuni 111

6.2.3. Soluţii de optimizare a cererilor cu funcţii de agregare şi operaţii de ordonare 120

3

CAPITOLUL VII – SOLUŢII DE DEZVOLTARE A SISTEMELOR INFORMATICE EXECUTIVE 122 7.1. Ciclul de dezvoltare a sistemelor informatice executive 122

7.1.1. Fazele de dezvoltare a sistemelor informatice executive 122

7.1.2. Etape ale ciclului de dezvoltare a sistemelor informatice executive 124

7.3. Studii şi cadre (frameworks) de dezvoltare a sistemelor informatice executive 148

7.4. Minimizarea riscului de dezvoltare 154

7.4.1. Factorii principali care influenţează realizarea sistemelor executive. Analiza şi evaluarea gradului de influenţă a factorilor pe fiecare etapă a ciclului de dezvoltare 154

7.4.2. Criterii de evaluare a sistemelor executive 166

CAPITOLUL VIII - METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE EXECUTIVE 168 8.1. Clasificări şi caracteristici ale metodologiilor de realizare a sistemelor informatice 168

8.2. Soluţii de realizare a sistemelor informatice executive conform metodologiilor orientate-obiect utilizând limbajul unificat de modelare (UML) 173

8.2.1. Elemente ale limbajului UML care pot fi utilizate în realizarea sistemelor informatice executive 173

8.2.2. Extensii UML utilizate în realizarea sistemelor informatice executive 177

CAPITOLUL IX – SOLUŢII DE TEHNOLOGII ŞI INSTRUMENTE DISPONIBILE CARE POT FI UTILIZATE ÎN REALIZAREA SISTEMELOR INFORMATICE EXECUTIVE 190

9.1. Soluţii de sisteme de gestiune a bazelor de date. Analiză comparativă a performanţelor şi facilităţilor obţinute de SGBD-urile disponibile 190

9.2. Soluţii de tehnologii şi instrumente Oracle utilizate în realizarea sistemelor informatice executive 205

CAPITOLUL X. PROPUNEREA ŞI REALIZAREA UNEI SOLUŢII DE SISTEM INFORMATIC EXECUTIV ÎN CADRUL UNEI COMPANII NAŢIONALE 210 CONCLUZII 262 BIBLIOGRAFIE 270

ANEXE 277 ANEXA 1 - Construirea depozitului de date centralizat în Oracle Warehouse Builder 10g (OWB) 277

ANEXA 2: Realizarea depozitului virtual în Oracle BI Discoverer Administrator 10g 287 ANEXA 3: Realizarea interfeţei, a rapoartelor şi prezentărilor cu Oracle BI Discoverer Desktop 10g 292

4

INTRODUCERE

Motto: “Valoarea unui sistem depinde de cât de

folositor le este executivilor, de cât de bine este

înteles şi cât de mult este utilizat” - D. Delong, J.F.

Rockart în cartea Identifying the Attributes of

Successful Executive Support System Implementation,

John Wiley & Sons, 1992

In cadrul evoluţiei actuale a economiei şi a societăţii în general, problematica luării

deciziilor devine din ce în ce mai complicată. Managerii se confruntă cu o avalanşă de

informaţii, date, cunoştinţe într-un mediu din ce în ce mai aglomerat, atât din punctul de

vedere organizaţiei proprii, dar mai ales din puctul de vedere al al pieţii, al potenţialilor

clienţi şi al concurenţei. In acest cadru, necesitatea existenţei unui sistem informatic

destinat organizării datelor, a extragerii de informaţii utile şi cunoştinţe noi şi relevante, a

prezentării acestora într-un format sintetic şi specific managementului de vârf este

evidentă.

Derularea afacerilor la nivel înalt nu se desfăşoară studiind rapoarte ce prezintă

volume mari de date, detaliate, zilnice şi fără corelare. Mediul actual, în care fracţiuni de

timp pot decide evoluţia unei organizaţii, impune existenţa unui sistem informatic

performant, în care datele să fie prezentate direct, rapid, sintetic, relevant, cu posibilităţi de

previziune şi analiză avansată. Un astfel de sistem informatic trebuie să-i permită

managerului executiv ca oricând să poată vedea şi analiza situaţia organizaţiei sale astfel

încât deciziile adoptate să fie fundamentate. De exemplu, decizia de investiţie pe termen

mediu şi lung poate fi fundamentată prin analiza unui raport referitor la situaţia cash-flow-

ului pe următoarele luni, raport prezentat managerului prin intermediul unui portal,

accesibil de oriunde cu ajutorul dispozitivelor mobile, nefiind condiţionat de existenţa unor

sisteme greoaie de analiză, raportare şi prezentare a datelor.

In acest context, motivaţia cercetării unor soluţii destinate suportului decizional de

nivel strategic este evidentă. In esenţă, lucrarea abordează problematica sistemelor

informatice executive ca soluţii principale de sisteme informatice destinate suportului

decizional de nivel strategic şi îşi propune să identifice soluţiile teoretice şi practice,

tehnologice şi metodologice, studiile şi cadrele de dezvoltare implicate în realizarea cu

5

succes a acestor sisteme. Prezentarea acestor soluţii este structurată în patru secţiuni

princiale:

Astfel, în partea I (capitolele I - II) sunt abordate conceptele legate de

managementul organizaţiei, tipuri de sisteme informatice destinate suportului decizional pe

diferitele niveluri de management şi sunt identificate principalele soluţii informatice pentru

suportul decizional strategic.

Capitolul I prezintă noţiuni legate de managementul organizaţiei, de procesul

decizional şi de rolul şi funcţiile sistemelor informatice în asistarea deciziilor. Sunt

clasificate şi prezentate caracteristicile fiecărui tip de sistem informatic, precum şi rolul

acestora în cadrul proceselor decizionale.

In capitolul II sunt abordate problemele legate de managementul strategic al

organizaţiei şi sunt identificate sistemele informatice executive (EIS – Executive

Information Systems) ca fiind principalele soluţii informatice de asistare a procesului

decizional de nivel strategic. Acestea sunt prezentate pe larg, din punct de vedere al

definirii, al caracteristicilor şi obiectivelor, sunt propuse o serie de elemente comparative

faţă de sistemele suport de decizie (DSS – Decision Support Systems) şi sistemele

informatice pentru management (MIS – Management Information Systems). In finalul

capitolului, pe baza caracteristicilor şi obiectivelor prezentate, este identificată şi propusă o

arhitectură cu caracter general pentru sistemele informatice executive formată din patru

niveluri de realizare. Pe baza acestei arhitecturi am identificat principalele tehnologii ce

stau la baza realizării unui sistem executiv.

In partea a doua (capitolele III – VI) pe baza arhitecturii prezentate în capitolul II

sunt prezentate pe larg principalele soluţii tehnologice de realizare a sistemelor informatice

executive: depozitele de date, tehnologia OLAP, tehnologia data mining de extragere a

cunoştinţelor din date, tehnologii şi modalităţi de extragere a datelor din depozitele de date.

In capitolul III, pornind de la principalele modalităţi de organizare a datelor şi de

la avantajele comparative pe care depozitele de date le au faţă de bazele de date relaţionale,

am abordat pe larg caracteristicile şi arhitectura depozitelor de date, modelul de date

multidimensional, operaţiile realizate asupra modelului de date multidimensional, tipologia

depozitelor de date. In finalul capitolului am propus o serie de criterii de analiză a

performanţelor obţinute în urma implementării unor tipuri de depozite de date, realizând pe

baza acestor criterii o analiză comparativă cu scopul de a identifica modalitatea optimă de

organizare a datelor în cadrul depozitelor.

6

Capitolul IV este orientat spre analiza principalei soluţii de extragere şi prelucrare a

datelor din depozitele de date şi anume tehnologia OLAP (On Line Analytical Processing).

Sunt prezentate conceptele teoretice ce stau la baza tehnologiei, cerinţele funcţionale,

arhitectura sistemelor OLAP, modelele de date multidimensionale ce stau la baza

sistemelor OLAP. Pe baza analizei acestor concepte sunt propuse elementele caracteristice

pentru realizarea sistemelor informatice executive.

In capitolul V am continuat prezentarea soluţiilor de extragere şi prelucrare a

datelor, însă cu noi valenţe şi anume extragerea cunoştinţelor din depozitele de date cu

ajutorul algoritmilor de data mining. Sunt prezentate principalele metode şi algortimi ce

pot fi aplicaţi în cadrul sistemelor informatice executive pentru obţinerea unor cunoştinţe

noi pentru susţinerea procesului decizional strategic.

In capitolul VI am extins problematica extragerii datelor din cadrul depozitelor de

date prin identificarea şi abordarea soluţiilor de interogare cu ajutorul funcţiilor analitice

SQL şi aplicarea asupra acestora a unor algoritmi şi tehnici de optimizare pentru

micşorarea timpului de răspuns. Sunt tratate principalele tehnici de optimizare pe fiecare

tip de cerere în parte: cereri pe o singură tabelă (tabelă virtuală), cereri cu joncţiuni, cereri

cu funcţii de agregare şi operaţii de ordonare.

Partea a treia (capitolele VII - VIII) se axează pe analiza, identificarea şi

propunerea unor soluţii de proiectare şi dezvoltare a sistemelor informatice executive, este

propus un ciclu de dezvoltare şi este aleasă metodologia cea mai potrivită din punctul meu

de vedere pentru realizarea unui EIS.

Capitolul VII se concentrează pe analiza şi propunerea unui ciclu de dezvoltare

care să permită o realizare de succes a sistemelor informatice executive pe parcursul unor

etape şi subetape în care se modelează distinct toate aspectele specifice unui EIS. Sunt

prezentate şi o serie de studii şi cadre de dezvoltare, este abordată şi problematica

factorilor critici care pot influenţa succesul unui EIS şi sunt propuse câteva criterii de

evaluare a performanţelor obţinute de un sistem informatic executiv.

Capitolul VIII îşi propune să analizeze facilităţile şi caracteristicile metodologilor

existente de realizare a sistemelor informatice şi, pe baza acestora şi a particularităţilor

sistemelor informatice executive, să stabilească metodologiile potrivite pentru realizarea

unor astfel de sisteme, dar şi să extindă facilităţile standard ale acestora pentru o modelare

cât mai detaliată a sistemelor EIS.

Partea a patra (capitolele IX – X) este orientată spre oferirea unor soluţii practice

care să se aplice sistemelor informatice executive, prin alegerea unor tehnologii şi soluţii

7

existente, potrivite pentru realizarea unui EIS şi propunerea şi dezvoltarea unui sistem

informatic executiv într-o companie naţională.

Capitolul IX analizează din punctul de vedere al performanţelor, al facilităţilor de

administrare a datelor şi al tehnologiilor de inteligenţa afacerilor oferite, două mari soluţii

existente în cadrul organizaţiilor româneşti: platforma Oracle şi platforma SQL Server

2005.

Capitolul X oferă o abordare practică a tuturor conceptelor discutate şi propuse în

capitolele anterioare. Este analizată situaţia concretă a unei organizaţii naţionale, iar pe

baza analizei am propus o soluţie de realizare a unui sistem informatic executiv conform

ciclului de dezvoltare propus în capitolul VII, al extensiilor realizate în capitolul VIII şi

incorporând soluţiile tehnologice discutate în capitolele III – VI.

Fiecare dintre capitolele II - IX este echilibrat din punct de vedere al noţiunilor

teoretice şi practice, acestea din urmă sunt referite pe baza realizărilor din ultimul capitol

în care este oferită o soluţie completă de sistem informatic executiv.

Concluziile lucrării sunt importante din punctul de vedere al observaţiilor şi

recomandărilor personale făcute în baza analizelor realizate şi a contribuţiilor personale

aduse la domeniul studiat.Contribuţiile personale sunt prezente în fiecare capitol, pentru

evidenţiere sunt marcate distinct prin sublinierea unor idei mai importante şi vor fi

detaliate în concluziile acestei lucrări.

Mulţumesc pe această cale colectivului Catedrei de Informatică Economică pentru

sprijinul acordat pe perioada derulării programului de pregătire doctorală, pentru ocazia

deosebită de a participa la comunicările Conferinţei de Infromatică Economică, de a

prezenta în faţa specialiştilor studiile şi cercetările ce au stat la baza acestei teze şi de a

publica în volumele Revistei de Informatică Economică rezultatele obţinute.

Mulţumesc profesorilor şi colegilor din cadrul colectivului de Baze de Date pentru

susţinerea acordată pe parcursul elaborării tezei.

Mulţumesc domnului profesor Ion Lungu, conducătorul ştiinţific al acestei lucrări

pentru încrederea acordată şi pentru observaţiile, ideile şi sugestiile făcute pe tot parcursul

programului de pregătire şi elaborare a tezei.

8

CAPITOLUL I. MANAGEMENTUL STRATEGIC AL ORGANIZAŢIEI

1.1. ROLUL ŞI FUNCŢIILE MANAGEMENTULUI ORGANIZAŢIEI

Ştiinţa managementului a apărut ca răspuns la necesităţile societăţii moderne.

Managementul organizaţiei este abordat din multiple puncte de vedere de diferiţi autori. În

cartea “Fundamentele managementului organizaţiei” [NIVE01] O. Nicolaescu şi I.

Verboncu propun următoarea definiţie: “managementul organizaţiei rezidă în studierea

proceselor şi relaţiilor de management din cadrul lor, în vederea descoperirii legităţilor şi

principiilor care le guvernează şi a conceperii de noi sisteme, metode, tehnici şi modalităţi

de conducere, de natură să asigure obţinerea, menţinerea şi creşterea competitivităţii.” In

aceeaşi lucrare procesul de management este definit astfel: “procesul de management în

organizaţie constã, în ansamblul fazelor, în procesele prin care se determinã obiectivele

acesteia şi ale subsistemelor incorporate, resursele şi procesele de muncã necesare

realizãrii lor şi executanţii acestora, prin care se integreazã şi controleazã munca

personalului folosind un complex de metode şi tehnici în vederea îndeplinirii cât mai

eficiente a raţiunilor ce au determinat înfiinţarea respectivei organizaţii. “

Henry Fayol afirmă că rolul managementului este de a previziona, organiza,

comanda, coordona şi controla activităţile unei organizaţii. Aceste funcţii au fost

reformulate de O. Nicolaescu şi I. Verboncu în lucrarea menţionată mai sus astfel:

previziune, organizare, coordonare, antrenare şi evaluare-control.

Funcţia de previziune reprezintă “ansamblul proceselor de muncă prin intermediul

cărora se determină principalele obiective ale organizaţie şi componentelor sale, precum

şi resursele şi principalele mijloace necesare realizării lor.”

Funcţia de organizare este definită ca fiind ”ansamblul proceselor de management

prin intermediul cărora se stabilesc şi delimitează procesele de muncă fizică şi intelectuală

şi componentele lor (mişcări, timpi, operaţii, lucrări, sarcini etc.), precum şi gruparea

acestora pe posturi, formaţii de muncă, compartimente şi atribuirea lor personalului,

corespunzător anumitor criterii manageriale, economice, tehnice şi sociale, în vederea

realizării în cât mai bune condiţii a obiectivelor previzionate. ”

Funcţia de coordonare constă în ”ansamblul proceselor de muncă prin care se

armonizează deciziile şi acţiunile personalului organizaţiei şi ale subsistemelor sale, în

cadrul previziunilor şi sistemului organizatoric stabilite anterior. ”

9

Funcţia de antrenare încorporează ”ansamblul proceselor de muncă prin care se

determină personalul organizaţiei să contribuie la stabilirea şi realizarea obiectivelor

previzionate, pe baza luării în considerare a factorilor care îl motivează.”

Funcţia de evaluare-control poate fi definită ca ”ansamblul proceselor prin care

performanţele organizaţiei, subsistemelor şi componenţilor acesteia sunt măsurate şi

comparate cu obiectivele şi standardele stabilite iniţial, în vederea eliminării deficienţelor

constatate şi integrării abaterilor pozitive.”

Tot în “Fundamentele managementului organizaţiei” autorii structurează aceste

funcţii pe trei faze sau etape distincte, după cum urmează: faza previzională de stabilire a

tendinţelor şi obiectivelor, faza de operaţionalizare sau de aplicare a obiectivelor stabilite

şi faza finală de comensurare şi interpretare a rezultatelor

Ca dimensiuni ale realizării acestor etape şi funcţii sunt identificate două

componente: informaţia şi oamenii.

In ceea ce priveşte rolul factorului uman în realizarea funcţiilor managementului în

lucrarea [DOBR99] se caracterizează acest aspect astfel: “dimensiunea umană specifică

proceselor şi relaţiilor de management se reflectă şi în faptul că oamenii au multiple

consecinţe asupra componentelor întreprinderii, atât în calitate de titulari ai anumitor

posturi de conducere, cât şi de indivizi cu personalitate proprie. De asemenea, fiecare

decident reprezintă o personalitate aparte cu aspiraţii, caracteristici şi necesităţi

extraprofesionale specifice, de care trebuie să se ţină seama pentru buna funcţionare a

întreprinderii“.

Pentru a indeplini aceste funcţii într-o organizaţie modernă informaţia este

esenţială. Totodată este necesar de a avea la îndemână o serie de tehnici şi instrumente

pentru măsurarea activităţilor curente şi planificarea activităţilor ulterioare. Pentru a-şi

îndeplini rolul managerii trebuie să cunoască comportamentul uman şi organizaţional,

trebuie să fie lideri ai organizaţiei, utilizatori şi furnizori de informaţii, să aibă puterea de a

lua decizii pentru reglarea sistemului condus.

1.2. PROCESUL DECIZIONAL ŞI ELABORAREA DECIZIILOR

Procesul decizional implică o serie de elemente atât de natură umană cât şi

informaţională şi presupune parcurgerea unor etape care de cele mai multe ori conduc la

mai multe variante posibile de alegere. In [DOBR99] procesul decizional este definit

astfel: ”un ansamblu de activităţi pe care le desfăşoară un individ şi/sau un grup,

confruntaţi cu un eveniment care generează mai multe variante de acţiune, obiectivul

10

activităţii fiind alegerea unei variante care corespunde sistemului de valori al individului

şi/sau grupului”. Varianta aleasă în urma procesului decizional este decizia prin aceasta

stabilindu-se scopul şi obiectivele unei acţiuni, direcţiile şi modalităţile de realizare a

acesteia, toate determinate în funcţie de o anumită necesitate, pe baza unui proces de

informare, reflecţie şi evaluare a mijloacelor şi a consecinţelor desfăşurării acţiunii

respective. [MARI03]

Luarea unei decizii presupune următoarele elemente: trebuie să existe unul sau mai

multe obiective care trebuie atinse, managerul trebuie să aibă de ales între mai multe

alternative de acţiune, factorii limitativi economici (resurse, timp, muncă) să fie incluşi în

planul decizional, decizia trebuie să fie fundamentată ştiinţific şi să fie formulată clar în

termeni în care să poată fi înţeleasă şi aplicată.

Studierea deciziilor şi a caracteristicilor acestora a dus la o clasificare a lor din mai

multe aspecte [MARI03]:

• Din punct de vedere al conţinutului funcţional, deciziile pot fi clasificate în decizii

de planificare; decizii organizaţionale; decizii de conducere; decizii de stimulare (a

angajaţilor, de exemplu); decizii de control.

• După nivelul de elaborare a deciziilor se clasifică în: decizii strategice - sunt

deciziile care stabilesc orientările de perspectivă şi se iau în colectiv, vizează

ansamblul activităţii economice a societăţii comerciale; decizii tactice - care se iau

pentru o perioadă mai mică de un an şi vizează o activitate sau o subactivitate a

societăţii comerciale; decizii operaţionale - sunt decizii de rutină şi se referă la

perioade scurte, care vizează îndeplinirea obiectivelor specifice şi individuale.

• În funcţie de certitudinea atingerii obiectivelor, deciziile pot fi: decizii certe;

decizii incerte; decizii de risc.

• În raport cu sfera de cuprindere a decidentului deciziile se clasifică astfel: decizii

individuale - sunt adoptate de către un singur cadru de conducere; decizii colective

– adoptate în grup.

Etapele de adoptare a unei decizii sunt identificate şi prezentate conform modelului

lui Simon în lucrarea [MUNT04] . Iniţial, în 1965 procesul decizional cuprindea trei etape

principale şi anume:

• Identificarea şi formularea problemei – presupune identificarea obiectivelor

organizaţiei, identificarea problemei, definirea ei, stabilirea tipului (structurată,

emistructurată sau nestructurată), precum şi stabilirea unei priorităţi;

11

• Proiectarea, identificarea şi analiza alternativelor – se examinează setul de

alternative relevante şi are loc un proces de evaluare a acestora;

• Alegerea unei alternative - se selectează una dintre alternativele valabile generate şi

analizate în etapa anterioară. În unele cazuri, mediul decizional este foarte dinamic,

iar soluţiile vor fi selectate pe baza condiţiilor estimate la momentul când soluţia

va fi fizic implementată. Adesea, se impune o revenire la etapa anterioară pentru

rafinări ale strategiei de selecţie şi ale definirii setului de soluţii fezabile.

Modelul a fost completat ulterior în 1982 de Sprague şi Carlson care au adăugat şi

etapa de implementare ce presupune declanşarea unor acţiuni în cadrul organizaţiei ce pun

accentul pe implementarea soluţiei şi rezolvarea problemei (crearea consensului,

negocierea etc). Există şi o etapă ulterioară de evaluare a consecinţelor implementării

deciziei în mediul organizaţional.

1.3. NIVELURILE DE MANAGEMENT ALE ORGANIZAŢIEI

Managementul organizaţiei implică tipuri diferite de activităţi şi deci, necesită

tipuri diferite de informaţii. O clasificare general acceptată împarte nivelurile de

management al organizaţiei în trei: nivelul operaţional, nivelul tactic şi nivelul strategic.

La nivelul managementului operaţional, informaţiile necesare managerilor se

referă la operaţiile curente, la controlul activităţilor zilnice şi implică determinarea celui

mai eficient mod de implementare a setului de sarcini stabilit de conducere şi totodată

evaluarea rezultatelor. Procesul decizional la acest nivel necesită informaţii detaliate

despre sarcinile ce trebuiesc finalizate, resursele necesare, coordonarea cu alte activităţi

curente din organizaţie.

Managerii operaţionali trebuie să ia decizii privind realizarea unor programe

curente, la nivelul echipei de lucru, pe baza setului de politici şi reguli stabilite de

managerii de la nivelul tactic. Informaţia pentru aceste activităţi trebuie să fie foarte

detaliată, exactă şi furnizată periodic, de obicei zilnic şi săptămânal.

Nivelul managementului tactic implică stabilirea şi realizarea obiectivelor

precizate în planuri de activitate şi gestionarea eficientă a resurselor pentru a îndeplini

politicile şi obiectivele impuse de managementul de vârf. Managerii de la acest nivel

coordonează activităţile din cadrul departamentelor sau serviciilor (de exemplu

departamentele de producţie, comercial, financiar, etc). Managerii de la nivelul tactic au

nevoie de rapoarte de sinteză referitoare la activităţile desfăşurate pentru a lua decizii în

vederea realizării obiectivelor la nivelul fiecărui departament. De obicei informaţiile

12

trebuie furnizate la cerere, periodic (de regulă saptămânal, lunar) sau la finalizarea unor

termene referitoare la anumite activităţi.

Managementul strategic implică determinarea obiectivelor organizaţiei, strategia

necesară pentru realizarea acestor obiective, precum şi structura organizaţiei. Aşa cum se

menţionează în lucrarea [NIVE01] “strategia reprezintă ansamblul obiectivelor majore ale

organizaţiei pe termen lung, principalele modalităţi de realizare împreună cu resursele

alocate, în vederea obţinerii avantajului competitiv potrivit misiunii organizaţiei.”

Grupul STRATEGOR se referă la elaborarea strategiei organizaţiei ca fiind

“alegerea acelor domenii de activitate în care firma reuşeşte să fie prezentă precum şi

alocarea resurselor astfel încât să-şi menţină poziţia dobândită sau chiar să şi-o

consolideze“. [STRA00]

Referitor la aceste domenii de activitate în lucrarea [ISTO03] autorul propune şapte

domenii de performanţă în care trebuie fixate obiectivele:

• Profitabilitatea şi performanţa – se exprimă printr-o serie de indicatori financiari

cum ar fi rata profitului, valoarea acţiunilor pe piaţă, rentabilitatea, valoarea

dividendelor. Informaţiile prezentate sunt concentrate pe analiza indicatorilor cheie

de performanţă (KPI – key performance indicators), iar deciziile luate pe baza

acestora trebuie să ducă la obţinerea de rezultate în favoarea companiei într-un timp

cât mai scurt;

• Cota de piaţă – în acest domeniu se fixează segmentele de piaţă care prezinţă

interes pentru organizaţie;

• Inovarea şi avantajul competitiv – obiectivul se formulează în termenii legaţi de

structura şi tipul produselor noi lansate pe piaţă. Situaţia pieţei, a potenţialilor

clienţi dar şi a companiilor concurente trebuie să fie monitorizată şi trebuie

investigate noi oportunităţi de diversificare a produselor;

• Productivitatea – reprezintă eficienţa în utilizarea resurselor pentru atingerea

obiectivelor;

• Resursele umane, materiale, financiare şi informaţionale – în acest domeniu se

stabilesc structura, volumul, modul de achiziţionare şi utilizare a acestora;

• Performanţele manageriale – pentru aceasta se fixează criteriile de performanţă ale

managerilor organizaţiei, modalitatea de îmbunătăţire şi perfecţionare a acestora şi

modalităţile de evaluare;

13

• Responsabilitatea publică – se precizează rolul organizaţiei în mediul de afaceri,

imaginea pe care aceasta o are pe piaţă precum şi participarea la satisfacerea unor

nevoi sociale.

Aceste obiective devin strategice numai dacă “sunt clar formulate, exprimate

cantitativ, bine precizate în timp (utilizând termenele iniţiale, intermediare şi finale) şi

ierarhizate, adică ordonate după contribuţia la creşterea performanţelor organizaţiei şi

exact prin aceste atribute se deosebesc de misiune. “ [ISTO03]

Aşa cum deciziile au fost clasificate în funcţie de criteriile menţionate anterior şi

strategiile se pot grupa în tipologii după cum este prezentat pe larg în lucrarea [ISTO03].

Voi reda în cele ce urmează câteva dintre aceste criterii de clasificare:

• În funcţie de evoluţia propusă de către managementul firmei avem strategii de

dezvoltare care vizează maximizarea cifrei de afaceri, prin creşterea producţiei şi

obţinerea unui avantaj competitiv legat de costuri; strategii neutrale, denumite şi

strategii de stabilitate sunt adoptate de firme mari, care-şi asumă un anumit grad de

risc într-un mediu stabil în care se urmăreşte stabilizarea performanţelor prin

îmbunătăţiri calitative la nivel funcţional; strategii de restrângere, care sunt

asociate de obicei eşecului în adoptarea unor strategii anterioare.

• În funcţie de diversitatea activităţilor unei firme şi de existenţa unor legături între

aceste activităţi, există strategii de portofoliu care se pot clasifica în următoarele

categorii: strategii de specializare, care sunt caracteristice acelor firme care se

orientează în producerea unui singur produs sau serie de produse sau spre

desfacerea lor pe o singură piaţă; strategii de diversificare ce constau în adăugarea

la portofoliul existent a unor afaceri similare sau noi în ceea ce priveşte produsele,

tehnologiile, canalele de distribuţie;

• În funcţie de provenienţa resurselor şi a competenţelor în producerea de noi

produse există strategii ale modalităţilor de creştere care se clasifică astfel:

strategii de creştere internă ce constau în creşterea volumului activelor unei firme

prin utilizarea resurselor proprii; strategii de achiziţie reprezintă cumpărarea unei

firme de către o alta, caracterizându-se prin dispariţia firmei cumpărate ca entitate

juridică independentă, aceasta devenind doar o simplă divizie sau domeniu strategic

de afaceri; strategii de fuziune reprezintă o înţelegere între două sau mai multe

firme care se finalizează prin unirea lor într-o singură organizaţie.

14

• După sfera de cuprindere, există strategii globale care se referă la ansamblul

activităţilor firmei şi se caracterizează prin complexitatea ridicată şi implicare de

resurse apreciabile concretizându-se în planuri sau programe vizând firma în

ansamblul său; strategii parţiale care se referă la unele activităţi ale firmei şi se

caracterizează prin concentrarea cu prioritate asupra celor mai bune sau mai

deficitare componente ale firmei, folosind resurse relativ limitate concretizându-se

în programe sau planuri pe domenii.

• După gradul de participare a firmei la elaborarea strategiei se deosebesc strategii

integrate situează în primul plan corelarea activităţilor întreprinderii cu obiectivele

suprasistemelor din care aceasta face parte; strategii independente situează

maximizarea profiturilor unităţii sau supravieţuirea acesteia.

• După dinamica principalelor obiective încorporate există strategii de redresare,

strategii de consolidare şi strategii de dezvoltare.

• După tipul obiectivelor şi natura abordărilor se deosebesc strategii de privatizare,

restructurare, manageriale, joint-venture, inovaţionale, ofensive, de specializare,

de diversificare, informaţionale şi organizatorice.

• După natura viziunii obiectivelor şi mijloacelor încorporat se deosebesc strategii

economice care se bazează predominant pe studierea şi luarea în considerare a

cerinţelor pieţei, iar obiectivele şi principalele mijloace de realizat preconizate sunt

de natură economică şi stabilite pe bază de criterii economice; administrativ-

economice în care un rol major în stabilirea lor îl au factorii decizionali externi

firmei, care impun anumite obiective, opţiuni strategice sau restricţii privitoare la

acestea, iar cerinţele pieţei nu au un rol determinant în stabilirea conţinutului

acestora.

In procesul de stabilire şi de fundamentare a strategiei intervin o serie de factori

determinanţi de care trebuie să se ţină cont în corelarea elementelor caracteristicile

organizaţiei şi mediul în care aceasta evoluează, înţelegerea acestei corelaţii condiţionând

viabilitatea organizaţiei. Adoptarea deciziilor strategice trebuie să ţină cont de mediul

ambiant al organizaţiei, acesta ”include toate elementele exogene firmei de natură

economică, managerială, tehnică, politică, juridică, demografică, culturală, ştiinţifică,

psihosociologică, educaţională şi ecologică ce marchează stabilirea obiectivelor acesteia,

obţinerea resurselor necesare, adoptarea şi aplicarea deciziilor de realizare a

lor”[NIVE01].

15

Informaţia de la acest nivel de decizie este deosebit de importantă şi vizează aceste

elemente necesare stabilirii strategiei şi a fundamentării deciziilor în concordanţă cu

mediul ambiant. Este o informaţie în general sintetică, mai puţin detaliată şi compusă atât

din date istorice şi curente cât şi din previzionări. Managerii de la nivelul strategic

stabilesc politica, obiectivele şi resursele de capital necesare pentru dezvoltarea

organizaţiei, deci au nevoie de informaţie la cerere şi într-o formă specializată. Analizele

se realizează lunar, la intervalle de 3, 6 şi 9 luni şi anual sau aleator, la cerere, în funcţie

de necesităţi.

1.4. SISTEMUL INFORMATIC – INSTRUMENT AL MANAGEMENTULUI

ORGANIZAŢIEI

Noţiunea de sistem este aplicabilă în orice domeniu: social, biologic, economic,

informatic şi a dezvoltarea conceptelor legate de sisteme în general a presupus o cercetare

interdisciplinară. El. Von Bertalanffy a definit sistemul ca “o mulţime de elemente care

interacţionează între ele”, iar El. Zadeh a adăugat la această definiţie noţiunea de stare a

unui sistem la un moment dat [ZADE74].

După A. Rapaport “un sistem este: (a) ceva constând într-o mulţime de entităţi; (b)

între care se specifică o mulţime de relaţii astfel că sunt posibile deducţiile privind relaţiile

dintre entităţi, comportamentul sau istoria sistemului” [RAPA72].

In lucrarea [LUNG05] autorul defineşte sistemul ca fiind “un ansamblu de entităţi

între care există legături variabile de intercondiţionare, a cărui funcţionare, desfăşurată

într-un mediu dinamic pe care îl influenţează şi de care este influenţat, permite atingerea

unor obiective cu evoluţie dinamică”.

La nivelul organizaţional în literatura de specialitate sunt unanim acceptate trei

subsisteme distincte care alcătuiesc sistemul întregii organizaţii, şi anume: sistemul

operaţional (condus), sistemul de management (decizional) şi sistemul informaţional.

Sistemul condus este reprezentat de totalitatea proceselor şi activităţilor

operaţionale (de exemplu producţie, transport, servicii etc).

Sistemul de management este reprezentat de totalitatea proceselor decizionale, a

deciziilor şi decidenţilor, a tehnicilor şi instrumentelor utilizate pentru coordonarea

activităţilor sistemului condus în funcţie de obiectivele, priorităţile şi restricţiile stabilite.

Sistemul informaţional este reprezentat de totalitatea informaţiilor şi fluxurilor

informaţionale, procedurilor de prelucrare a informaţiilor, a tehnicilor şi instrumentelor

16

utilizate în prelucrarea datelor pentru conceperea şi obţinerea informaţiilor necesare

procesului decizional.

In lucrarea [LUNG05] se propune următoarea definiţie: “Sistemul informaţional

poate fi definit ca un ansamblu tehnico-organizatoric de proceduri de constatare,

consemnare, culegere, verificare, transmitere, stocare şi prelucrare a datelor, în scopul

satisfacerii cerinţelor informaţionale necesare conducerii în procesul fundamentării şi

elaborării deciziilor.”

Dintre obiectivele sistemului informaţional autorii lucrării [LUSA04] menţionează

următoarele:

• Culegerea şi consemnarea datelor primare direct de la locurile unde au loc

procesele şi fenomenele economice, precum şi din spaţiul economic extern;

• Verificarea, transmiterea şi stocarea datelor pe diferiţi purtători tehnici de

informaţii;

• Prelucrarea manuală sau automată a datelor în concordanţă cu cerinţele conducerii;

• Asigurarea informaţiilor necesare conducerii conform principiului selecţiei şi

informării prin excepţie.

Sistemul informatic a apărut ca urmare a automatizării proceselor de culegere,

prelucrare şi obţinere a informaţiilor şi este inclus în cadrul sistemului informaţional. Deci,

se poate spune că sistemul informatic reprezintă totalitatea proceselor de culegere,

verificare, transformare, stocare şi prelucrare automată a datelor. În lucrarea [LUNG05]

este prezentată definiţia următoare: “Sistemul informatic este un ansamblu structurat de

elemente intercorelate funcţional necesare asigurării automatizării procesului de obţinere

a informaţiilor şi pentru fundamentarea deciziilor.”

Componentele principale ale unui sistem informatic sunt formate din elemente de

harware, software, comunicaţii, baza ştiinţifico-metodologică, baza informaţională,

resursele umane.

Obiectivele sistemelor informatice, conform autorilor lucrării [LUSA04] pot fi

clasificate după mai multe criterii astfel:

• Din punctul de vedere al sferei de cuprindere, obiectivele pot fi principale

(generale) reprezentate de asigurarea selectivă şi în timp util a tuturor nivelelor de

conducere cu informaţii necesare şi reale pentru fundamentarea şi elaborarea

operativă a deciziilor cu privire la desfăşurarea cât mai eficientă a întregii activităţi

17

din unitatea economică şi obiective secundare (derivate) care pot fi considerate

chiar condiţii de prim ordin pentru realizarea obiectivului general;

• Din punct de vedere al domeniului de activităţi asupra cărora acţionează sistemele

informatice, obiectivele pot fi clasificate astfel: obiective ce afectează activităţile

de bază din cadrul unităţilor economice (comercială, financiară, producţie etc) şi

obiective ce afectează funcţionarea sistemului informaţional (de exemplu creşterea

vitezei de răspuns, a exactităţii în procesul de prelucrare a datelor şi informare a

conducerii, etc).

• Din punctul de vedere al posibilităţilor de cuantificare a efectelor acestora, astfel:

obiective cuantificabile (de exemplu reducerea costurilor de prelucrare, urmărirea şi

reducerea stocurilor fără mişcare, etc) şi obiective necuantificabile (de exemplu

creşterea prestigiului unităţii economice sau a calităţii informaţiilor).

1.5. TIPOLOGIA SISTEMELOR INFORMATICE UTILIZATE ÎN

MANAGEMENTUL ORGANIZAŢIEI

Necesitatea clasificării sistemelor informatice a apărut ca urmare a cerinţelor şi

funcţionalităţilor diferite implementate de unele dintre acestea şi din nevoia de a organiza

şi stabili clar obiectivele şi ariile de influenţă a fiecărui tip de sistem în parte.

Un prim criteriu de clasificare al sistemelor informatice menţionat în lucrarea

[LUNG05] este cel după aportul acestuia în actul decizional, astfel:

• Sistemele informatice la nivel operaţional (Operational Level System) ce permit

culegerea, stocarea şi prelucrarea datelor referitoare la tranzacţiile şi procesele

economice (plăţi efectuate către furnizori, încasări, gestiunea materialelor şi

stocurilor, etc);

• Sistemele de gestiune a cunoaşterii în cadrul organizaţiei (Knowledge Systems) ce

permit promovarea noilor tehnologii şi cunoştinţe în cadrul organizaţiei (de

exemplu produsele software destinate proiectării asistate de calculator – CAD)

precum şi asigurarea automatizării şi controlului fluxului de documente;

• Sistemele informatice destinate conducerii curente ce asigură desfăşurarea

activităţilor de control şi conducere pe termen scurt;

• Sistemele informatice destinate conducerii strategice ce permit echipei manageriale

de pe nivelurile superioare ale conducerii să realizeze planificarea activităţii

organizaţiei pe termen lung în vederea atingerii obiectivelor strategice preconizate.

18

Un alt criteriu întâlnit în lucrarea [STAN00] este cel al naturii prelucrărilor

realizate prin intermediul sistemelor informatice, astfel:

• Sisteme pentru prelucrarea tranzacţiilor (TPS- Transaction Processing System)

specializate în preluarea, stocarea şi prelucrarea datelor privitoare la tranzacţiile

zilnice.

• Sisteme destinate activităţii de birotică (OAS – Office Automation System) destinate

în principal personalului implicat în procesul prelucrării informaţiei (de exemplu

procesoarele de texte, calcul tabelar, sisteme de poştă electronică.

• Sisteme informatice destinate cercetării-dezvoltării (KWS- Knowledge Work

System) ce permit realizarea şi integrarea noilor tehnologii.

• Sisteme informatice pentru conducerea la nivel tactic (MIS – Management

Information System) destinate asigurării rapoartelor sintetice necesare în procesul

fundamentării deciziilor curente, tactice, controlului şi planificării pe termen scurt.

• Sisteme suport de decizie (DSS – Decision Support System) oferă managerilor

modele complexe şi aprofundate de analiză în vederea fundamentării deciziilor.

• Sisteme informatice executive sau suport ale executivului (ESS - Executive Support

System sau EIS – Executive Information Systems) reprezintă sisteme informatice

destinate conducerii strategice şi permit luarea unor decizii nestructurate, altele

decât cele de rutină.

Un alt criteriu este cel al domeniului de utilizare, precizat în [LUNG05] astfel:

• Sisteme informatice pentru conducerea activităţilor unităţilor economico-sociale -

sunt caracterizate prin faptul că datele de intrare, de regulă, sunt furnizate prin

documente întocmite manual, iar datele de ieşire sunt furnizate de către sistem tot

sub formă de documente (liste, rapoarte etc.).

• Sistemele informatice pentru conducerea proceselor tehnologice - se

caracterizează prin aceea că datele de intrare sunt asigurate prin intermediul unor

dispozitive automate care transmit sub formă de semnale (impulsuri electronice)

informaţii despre diverşi parametri ai procesului tehnologic (presiune,

temperatură, umiditate, nivel) iar datele de ieşire se transmit de asemenea sub

formă de semnale unor organe de execuţie, regulatoare, care modifică automat

parametrii procesului tehnologic. Se execută în acest fel controlul şi comanda

automată a procesului tehnologic.

19

• Sistemele informatice pentru activitatea de cercetare ştiinţifică şi proiectare -

asigură automatizarea calculelor tehnico-inginereşti, proiectarea asistată de

calculator şi alte facilităţi necesare specialiştilor din domeniile respective.

• Sistemele informatice speciale - sunt destinate unor domenii specifice de activitate

ca de exemplu: informare şi documentare, tehnico-ştiinţifică, medicină etc.

Un alt criteriu de clasificare al sistemelor informatice economice este în funcţie de

nivelul ierarhic ocupat de sistemul economic în structura organizatorică a societăţii,

conform căruia avem:

• Sisteme informatice pentru conducerea activităţii la nivelul unităţilor economice –

sunt sisteme ce pot fi descompuse în subsisteme informatice asociate funcţiunilor

unităţilor economico-sociale sau chiar unor activităţi;

• Sisteme informatice pentru conducerea activităţii la nivelul organizaţiilor

economico-sociale cu structură de grup – sunt sistemele informatice la nivelul

regiilor autonome sau a companiilor cu structură de trust;

• Sisteme informatice teritoriale - sunt constituie la nivelul unităţilor administrativ-

teritoriale şi servesc la fundamentarea deciziilor adoptate de către organele locale

de conducere;

• Sisteme informatice pentru conducerea ramurilor, subramurilor şi activităţilor la

nivelul economiei naţionale - se constituie la nivelul ramurilor, subramurilor şi

activităţilor individualizate în virtutea diviziunii sociale a muncii şi specificate în

clasificarea ramurilor economiei naţionale;

• Sisteme informatice funcţionale generale - au ca atribut principal faptul că

intersectează toate ramurile şi activităţile ce au loc în spaţiul economiei naţionale,

furnizând informaţiile necesare coordonării de ansamblu şi sincronizării lor în

procesul reproducţiei din cadrul economiei de piaţă. În această categorie sunt

cuprinse sistemele pentru planificare, statistică, financiar-bancare etc.

Alte clasificări ale sistemelor informatice pentru asistarea deciziei sunt menţionate

şi în articolul [BAFU04].

20

CAPITOLUL 2. SOLUŢII DE SISTEME INFORMATICE PENTRU MANAGEMENTUL STRATEGIC

2.1. SISTEMELE INFORMATICE EXECUTIVE – SUPORT PENTRU

MANAGEMENTUL STRATEGIC

Dezvoltarea sistemelor informatice pentru management (MIS – Management

Information System) a fost un pas important în furnizarea informaţiilor necesare

managementului pentru fundamentarea deciziilor. Insă limitarea principală a acestora era

aceea că nu ofereau variante de decizii, şi deci nu găseau soluţii la problemele decizionale,

neavând capacitatea rezolvării unor probleme variate de management. Astfel, au apărut

sistemele suport de decizie (DSS – Decision Support System) care au extins aria de

cuprindere a sistemelor informatice pentru management şi la nivelurile superioare ale

conducerii.

Printre primele definiţii date sistemelor suport de decizie se regăseşte şi formularea

dată de Steven Alter care 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”. [MUNT04]

Referitor la tipurile de decizii pe care un DSS le poate susţine în definiţia dată de

Sprague şi Carlson se precizează că sistemul suport de decizie este “un sistem informatic

interactiv ce îi ajută pe decidenţi să folosească date şi modele, pentru a rezolva probleme

economice semistructurate şi nestructurate” [MUNT04]. Tot în acest sens E. Turban

[TURB98] defineşte un DSS ca fiind “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”.

In ceea ce priveşte caracteristicile principale ale sistemelor suport de decizie în

lucrarea [MUNT04] sunt citaţi Holsapple şi Whinston care în “Decision Support Systems:

A knowledge –Based Approach” (1996) pun în evidenţă cinci caracteristici specifice unui

DSS şi anume:

• Conţine o bază de cunoştinţe ce descrie unele aspecte ale lumii decidentului;

21

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

Datorită faptului că sistemele suport de decizie ofereau un cadru foarte larg de

tratare a suportului decizional, a fost necesară o specializare a lor astfel încât să trateze

distinct cerinţele de afaceri ale diferitelor tipuri de management. Astfel au apărut sistemele

informatice executive (Executive Information Systems) care au ca principal obiectiv

asistarea procesului decizional la nivel strategic.

Aşa cum se precizează în [THIE91], “executivii sunt manageri cu o autoritate

formală asupra întregii organizaţii sau a unei unităţi funcţionale”. O caracteristică

importantă a rolului menagerilor executivi este luarea deciziilor la nivel înalt care se referă

la evaluarea oportunităţilor şi posibilităţilor de acţiune pe termen mediu şi lung, selectarea

şi inţierea acestor posibilităţi [MINT89]. Pentru a lua decizii executivii au nevoie de

informaţii cu o calitate ridicată, relevante, uşor accesibile şi prezentate într-un format uşor

de înţeles. Astfel, s-a impus o nouă cerinţă şi anume aceea de a proiecta sisteme

informatice care să răspundă nevoilor şi obiectivelor managerilor executivi. Acestor noi

tipuri de sisteme li s-au dat denumiri diferite: sisteme informatice executive, sisteme

informatice pentru directori executivi, sisteme suport executive, sisteme informatice

strategice. In literatura de specialitate însă, termenul consacrat a rămas cel de sistem

informatic executiv pentru a descrie sistemele informatice pentru managementul strategic.

Termenul de sistem informatic executiv a fost utlizat pentru prima dată în anii 1982

de către Rockart şi Treacy în cercetările întreprinse la institulul MIT, desemnând un sistem

orientat pe date şi proiectat pentru a furniza informaţii managementului strategic

reprezentat de executivi astfel încât să ofere support pentru planificare managerială,

monitorizare şi analiză. [BOSA98]

In multe cercetări şi studii se pot observa diverse definiri ale conceptului de sistem

informatic executiv.

22

Astfel, în 1984 în definiţia dată de DeLong şi Rockart sistemele informatice

executive sunt văzute ca sisteme concepute pentru asistarea cerinţelor şi funcţilor de

afaceri, iar utilizatorii sunt fie membri CEO fie fac parte din echipa managerială de nivel

înalt, strategic. In aceeaşi definiţie se specifică faptul că sistemele informatice executive

pot fi implementate la nivel corporativ sau la nivel departamental. [BOSA98]

Astfel, în 1990, Meall defineşte un EIS ca fiind “un instrument, sistem care

furnizează accesul rapid la informaţiile cheie necesare executivilor pentru fundamentarea

deciziilor. Utilizatorii implicaţi nu trebuie să aibă cunoştinţe în domeniul IT. Accesul şi

utilizarea sistemului trebuie să se realizeze prin intermediul mouse-ului, a touch screen-

ului şi nu prin funcţii complicate sau comenzi date de la tastatură. Datele sunt prezentate

grafic, structurat, excepţiile sunt marcate distinct spre a ieşi în evidenţă astfel încât să fie

uşor de vizualizat şi de înţeles. “ [KUMA00]

In 1992, Matthews şi Shoebridge definesc sistemele informatice executive ca

“sisteme bazate pe furnizarea şi comunicarea de informaţii proiectate pentru asistarea şi

satisfacerea cerinţelor managerilor executivi. “[KUMA00]

Tot în 1992, Millet şi Mawhinney definesc EIS ca fiind “un sistem ce integrează

informaţii din susrse interne şi externe făcând posibile monitorizarea şi prezentarea

indicatorilor cheie către managerii executivi prin intermediul unor formate şi rapoarte

flexibile şi adaptabile cerinţelor acestora.“ [KUMA00]

Mai târziu, în 1995, Turban propune următarea definiţie: “EIS reprezintă un sistem

informatic proiectat pentru a satisface cerinţele de afaceri ale managerilor executivi.

Acesta furnizează acces rapid şi direct la rapoarte şi informaţii temporale. Interfaţa

sistemului este prietenoasă, oferind reprezentări grafice, raportare de excepţie şi facilităţi

de navigare pe niveluri ierarhice cu funcţii de drill-down. De asemenea oferă acces la

servicii online şi poştă electronică“[KUMA00]

Din punctul meu de vedere pot spune că un sistem informatic executiv este un

sistem informatic complex ce dispune de o interfaţă prietenoasă şi oferă acces rapid şi

direct la informaţii corecte şi relevante referitoare la domeniile şi activităţile principale

ale afacerilor şi permite analiza indicatorilor cheie de performanţă, ajutând la

îndeplinirea funcţiilor manageriale şi la atingerea obiectivelor strategice ale organizaţiei.

Este un sistem proiectat special pentru a satisface cerinţele senior managerilor, pentru a

concentra, organiza şi filtra datele interne şi externe ale organizaţiei astfel încât acestea

să poată fi mai bine utilizate. Se poate spune că un EIS contribuie la conducerea strategică

a organizaţiei focalizănd atenţia managerilor asupra domeniilor care au cel mai mare

23

impact asupra rezultatelor. Furnizează managerilor executivi date cheie şi informaţii

sintetizate astfel încât să-şi fundamenteze cunoştinţele despre organizaţie şi despre mediul

economic în care funcţionează.

Un EIS ajută managerii să analizeze, să compare, să pună în evidenţă tendinţele, să

monitorizeze performanţele şi să identifice oportunităţile şi problemele cu care se

confruntă organizaţia. Utilizarea unui EIS rămâne la latitudinea managerilor executivi,

aceştia putând schimba modul în care se utilizează informaţia în organizaţie, contribuind în

acest fel la îmbunătăţirea performanţelor.

Vandenbosch şi Huff (1992) de la Universitatea Western Ontario au remarcat faptul

că firmele canadiene au obţinut rezultate mai bune în afaceri dacă EIS-ul a permis şi

învăţarea managerială. EIS-urile care se bazează numai pe cunoştinţele existente ale

managerilor sunt mai puţin eficiente decât EIS-urile realizate cu posibilitatea de a construi

sau a spori cunoştinţele managerilor. În concluzie, accesul rapid la informaţii trebuie să

stimuleze şi procesul de cunoaştere şi învăţare, orice răspuns dat de sistem la o întrebare

determină apariţia altor întrebări puse de manager. În acest fel, ciclul de învăţare continuă,

managerii putând lua decizii mai bine fundamentate. La sistemele tradiţionale, de la

momentul formulării cerinţei până la obţinerea răspunsului, contextul întrebării nu mai este

de actualitate. Pe de altă parte, nici ciclul de învăţare nu este derulat ca un proces continuu.

Referitor la obiectivele unui sistem informatic executiv, Ian McNaught Davis,

director al companiei Comshare, implicată în dezvoltarea şi furnizarea de soluţii

informatice pentru managementul şi performanţa în afaceri, a sugerat că acestea ar trebui

să fie:

• Reducerea cantităţii de informaţii cu care se confruntă managerii;

• Creşterea relevanţei informaţiilor care ajung la executivi;

• Sporirea înţelegerii informaţiilor prezentate;

• Facilitarea comunicării cu alte persoane.

Aceste obiective se regăsesc şi în alte lucrări de specialitate, dar prezentate şi

grupate sub o altă formă.

Consider însă că principalul obiectiv al sistemelor informatice executive este acela

de a asista procesul decizional pe nivelele superioare de decizie prin furnizarea şi

prezentarea on-line a unor informaţii utile, a unor variante de decizii într-un timp scurt,

într-o manieră prietenoasă adaptată cunoştinţelor informatice ale managerilor, preluând

24

datele din surse diverse ce deservesc nivelul operaţional al organizaţiei, dar şi din afara

graniţelor acesteia.

Din acest obiectiv principal se poate contura ideea că un EIS trebuie să permită un

acces rapid al managerilor executivi la informaţii utile necesare procesului decizional.

Aceste informaţii pot fi obţinute şi prin intermediul altor tipuri de sisteme informatice.

Totuşi, resursele necesare pentru a extrage şi a filtra datele dintr-o varietate mare de

formate, sunt semnificative iar informaţiile obţinute cu aceste sisteme ajung la un moment

dat să nu mai răspundă cerinţelor strategice care sunt în continuă schimbare.

Tot din obiectivul principal se desprinde ideea că un EIS trebuie să permită

extragerea informaţiilor din datele care provin de la diferite surse, astfel încât utilizatorii

să-şi formeze o părere clară asupra a ceea ce există în interiorul organizaţiilor, dar şi asupra

mediului de afaceri în care evoluează. Una din sursele de date pentru un EIS poate fi

depozitul de date al organizaţiei de unde se obţin date cu un anume grad de sintetizare, şi

care, sunt prelucrate şi furnizate executivilor ca indicatori la nivel de organizaţie.

Un alt obiectiv al sistemelor informatice executive este acela că trebuie să fie uşor

de utilizat şi trebuie să răspundă exact cerinţelor managerilor executivi având o interfaţă

prietenoasă. Un EIS trebuie să ofere accesul on-line, direct la informaţiile relevante, pe

baza unor interfeţe foarte bine structurate şi uşor de parcurs de manageri care au puţin timp

la dispoziţie şi puţină experienţă în domeniul IT.

Informaţiile relevante trebuie să fie exacte, de actualitate şi să prezinte aspectele

esenţiale ale activităţilor din domeniul de interes al managerului şi trebuie să permită

obţinerea de informaţii şi cunoştinţe noi din datele prezentate, să genereze idei şi soluţii noi

pentru domeniul de activitate al managerului. De asemenea, trebuie să ofere indicatori

sintetici care să permită conturarea unei analize a activităţii organizaţiei, scoţând în

evidenţă realizările şi deficienţele acesteia. EIS-ul trebuie să ofere variante de soluţii

pentru ameliorarea deficienţelor, fiind suport pentru deciziile strategice. Sistemul

informatic trebuie să permită planificarea strategică a activităţii organizaţiei şi totodată să

monitorizeze şi să controleze performanţele în domeniul vizat. În acest scop, el va permite

interogări variate ale datelor şi va fi un suport pentru diverse cerinţe manageriale care nu

pot fi prevăzute decât într-o mică măsură.

25

2.2. CARACTERISTICI ALE SISTEMELOR INFORMATICE EXECUTIVE

Din literatura de specialitate pot fi conturate două categorii de caracteristici şi

anume: caracteristici funcţionale generale valabile pentru toate tipurile de sisteme

informatice executive şi caracteristici funcţionale specifice anumitor tipuri.

Cu toate că mediul organizaţional şi cerinţele de afaceri diferă de la un caz la altul

de realizare a sistemelor informatice executive se poate distinge un set de caracteristici

funcţionale care sunt mai mult sau mai puţin comune tuturor cazurilor, şi anume:

• Conţin un nivel de date distinct creat pentru a cuprinde informaţiile cerute de

utilizatorii executivi având informaţii cheie de la sistemele operaţionale, financiare,

alte sisteme informatice de management din cadrul organizaţiei, precum şi de la

sisteme din exteriorul organizaţiei. Desigur, multe din datele de la aceste surse sunt

importante şi pentru managerii de pe nivelele tactice ale organizaţiei. Necesitatea

de a stabili un nivel de date distinct provine din faptul că nu toate datele conţinute

în sistemele existente nu se află intr-o formă potrivită pentru a satisface cerinţele

utilizatorilor executivi, menţinând integritatea strictă a datelor;

• Oferă facilităţi de agregare a datelor. Un sistem informatic executiv trebuie să fie

capabil să realizeze agregarea şi detalierea datelor la cerere în funcţie de solicitările

managerilor executivi care doresc efectuarea unor analize. Este important ca un

sistem informatic executiv să furnizeze metode de acces de la cele mai generale la

cele mai detaliate nivele de informaţie şi acces structurat la volume mari de date;

• Permit raportarea de excepţie prin monitorizarea anumitor indicatori. Când un

indicator cheie de performanţă atinge un nivel inacceptabil, atunci este scos în

evidenţă şi prezentat utilizatorului permiţându-i identificarea uşoară a domeniilor

afacerii care trebuie supuse atenţiei;

• Permit analiza tendinţelor pe baza datelor istorice şi curente prin oferirea unor

evoluţii şi funcţii de previzionare şi prin posibilitatea de a compara indicatorii de

performanţă în timp;

• Au o interfaţă prietenoasă cu utilizatorii. Sistemul este realizat astfel încât

managerii să poată avea acces la informaţiile prezentate prin intermediul unei

interfeţe prietenoase fără a avea nevoie de personal suplimentar pentru configurarea

acesteia;

26

• Conţin instrumente de analiză dinamică a informaţiilor care permit realizarea de

operaţii multidimensionale asupra datelor, schimbări de persepctivă, rotaţii,

extragerea unui subset de date pentru analiză;

• Oferă facilităţi de modelare. Aceste facilităţi de modelare vor permite managerilor

executivi să studieze scenarii de tipul "ce s-ar întâmpla dacă? “ şi să facă variante

de plan care pot fi comparate cu performanţele aşteptate sau planificate;

• Oferă facilităţi de comunicare şi legături automate la surse de date externe.

Această facilitate permite transferul datelor interne şi externe dintr-o varietate de

baze de date în alte baze de date. Deseori apare necesitatea unor informaţii

provenite din datele externe, acest lucru determinând ca sistemele să ofere accesul

on-line la baze de date externe. Aceste facilităţi furnizează executivilor informaţii

zilnice ca ratele de schimb, preţurile şi alte informaţii referitoare la anumite

evenimente care pot fi încorporate în bazele lor de date.

Aceste caracteristici generale pot fi grupate la rândul lor în funcţie de capacităţile

tehnice ale sistemelor EIS şi beneficiile obţinute prin utilizarea lor.

În funcţie de capacităţile tehnice ale sistemelor EIS se desprind următoarele

caracteristici:

• Permit accesul la informaţii globale ale organizaţiei, preluând date atât din

sistemele operaţionale existente în interior cât şi din surse externe;

• Oferă acces la datele curente, istorice şi previzionate;

• Analiza şi prezentarea informaţiilor se realizează direct, online, bazându-se pe

analiza multidimensională a datelor;

• Prezintă informaţiile într-o formă ierarhică cu facilităţi de navigare pe diferite

niveluri şi implementează de asemenea operaţiile multidimensionale de rotaţii,

secţionări, limitări în cadrul datelor;

• Prezintă sintetic indicatorii de performanţă cheie ai organizaţiei (KPI);

• Prezintă tendinţele şi devierile fenomenelor şi proceselor de la comportamentul

normal;

• Oferă posibilităţi de previziune şi realizarea de scenarii privind evoluţia

indicatorilor de performanţă;

• Dispun de o interfaţă prietenoasă în care se îmbină prezentările de tip text, tabelar

şi grafic a informaţiilor.

27

In funcţie de beneficiile oferite de sistemele EIS se disting următoarele

caracteristici:

• Prin accesul rapid la informaţii critice facilitează obţinerea obiectivelor

organizaţionale;

• Pe baza analizei indicatorilor cheie prezentaţi creşte calitatea deciziilor luate şi

astfel se oferă suportul pentru un avantaj competiţional;

• Minimizează timpul destinat procesului decizional şi oferă un control mai bun în

organizaţie;

• Prin analizele dinamice a informaţiilor critice permite anticiparea problemelor şi

identificarea rapidă a oportunităţilor de afaceri;

• Pe baza posibilităţilor de previziune permite identificarea unor tendinţe ale

procesului de afaceri şi planificarea unor activităţi şi stabilirea unor obiective la

nivel strategic.

2.3. ASPECTE COMPARATIVE ÎNTRE MIS, DSS ŞI EIS

Sistemele informatice de management au fost dezvoltate pentru a furniza

informaţiile necesare pentru a asigura performanţe competitoare managerilor responsabili

cu luarea deciziilor operaţionale. Deciziile în acest caz au un caracter zilnic sau

săptămânal. In practică, ele sunt implementate în managementul operaţional însă dacă sunt

aplicate la nivelele cele mai înalte ale organizaţiei de cele mai multe ori eşuează. Sistemul

informatic de management este sistemul în care datele din diferitele unităţi operaţionale ale

companiei sunt centralizate pentru analiză de grup şi consolidare.

Sistemele informatice de management au evoluat de la o nevoie managerială reală

pentru o viziune consistentă a modului în care compania funcţionează ca un întreg. Rolul

lor este de a colecta date de la sistemele de raportare departamentale şi de a stoca, analiza

şi manipula informaţiile în formate consistente, controlate şi aprobate pentru prezentarea

lor managerilor.

Tipic, informaţiile dintr-un sistem informatic managerial vor fi prezentate ca un

raport listat care poate conţine unele grafice, analize diverse şi comentarii care sunt

adunate împreună într-o carte de raportare formală şi livrate managerilor. Rapoarte la

cerere pot fi furnizate când apar cerinţele, dar va fi cerută o notificare cu câteva zile înainte

ca raportul listat să fie disponibil.

Departamentele sistemului informatic de management sunt, în general, incapabile

de a prezice, de la o zi la alta, cerinţele executivilor. Rolul lor este acela de a furniza date

28

consistente despre consolidarea financiară şi raportarea în concordanţă cu un model comun

de date structurat şi acceptat. Acest model poate fi necesar pentru rapoartele financiare şi

pentru discuţiile de la întâlnirile consiliului, dar un asemenea mod flexibil şi structurat de

prezentare a informaţiilor nu reflectă cerinţele informaţionale ale managerilor executivi.

Acest lucru nu înseamnă numai timp consumat, ci este posibil ca în timpul procesului de

extragere unele cerinţe informaţionale să nu fie luate în seamă.

Tocmai pentru a înlătura aceste neajunsuri la sfârşitul anilor ‘70 sistemele suport de

decizie au devenit disponibile şi se presupunea că oferă managerilor facilităţi analitice

pentru a manipula volume mari de date. Îmbunătăţirile tehnologice în procesarea

informaţiilor furnizează oportunitatea de a mări şi a susţine lucrul indivizilor şi al

grupurilor, prin informaţii şi alte resurse decizionale cum ar fi capacitatea de a modela şi

analiza scenariile de decizie. Trăsăturile majore a unui sistem suport de decizie ar fi,

conform lui Rockart şi De Long, 1988 următoarele:

• Este orientat către un singur decident, sau clasa de decidenţi, ocupându-se cu o

decizie semistructurată.

• Decizia este repetitivă, justificând costurile mari de dezvoltare.

• Sistemul este orientat pe model şi bazat pe multe date.

Când primele sisteme informatice executive au devenit disponibile, în ciuda

încercărilor de a le distinge de sistemele suport de decizie, ele arătau similar cu acestea.

Accentul era pe date şi analize.

Asemănările între sistemele informatice executive şi sistemele suport de decizie

sunt evidente în anumite domenii, îndeosebi în ceea ce priveşte natura aplicaţiilor. De fapt,

mulţi privesc sistemele informatice executive ca un segment din piaţa sistemelor suport de

decizie. Totuşi, ideea că sistemul suport de decizie şi sistemul informatic executiv sunt

inseparabile este incorectă.

Confuzia dintre sistemul informatic executiv şi sistemul suport de decizie este

semnificativă, deoarece o viziune neclară şi limitată despre ceea ce înseamnă un sistem

informatic executiv poate limita potenţialul acestuia. În ultimii ani, o mai mare înţelegere a

rolului managerilor executivi împreună cu o creştere empirică a evidenţei utilizării unui

sistem informatic executiv a subliniat faptul că, managementul şi conducerea prin

intermediul datelor şi analiza orientată a unui sistem informatic executiv este departe de a

fi suficient. Chiar cantităţile mari de date, baza unui sistem suport de decizie, este frecvent

fie absentă, fie irelevantă în rezolvarea problemei executive.

29

Multe probleme executive sunt caracterizate de incertitudine şi implică informaţii

delicate sau ambigue, cum ar fi opiniile, presupunerile conflictuale sau valoarea

judecăţilor. Comunicarea este o parte importantă a multor sarcini ce sunt îndeplinite de

executivi. Este rolul unui executiv să studieze şi să facă înţelese dezvoltările în medii

interne şi externe şi să traducă aceste interpretări în acţiuni care să aducă beneficii

companiei.

Pentru a susţine un manager executiv în îndeplinirea acestui rol, un sistem

informatic executiv trebuie să furnizeze capacităţi de comunicare. În particular, trebuie să

fie capabil să integreze şi să utilizeze date cum ar fi: idei, opinii, preziceri, evaluări şi

explicaţii. Dată fiind importanţa furnizării canalelor bogate de comunicaţii, cum ar fi

canalele de conferinţă, de întâlniri, de contact persoană cu persoană se pare ca unele

aplicaţii automate de birou, cum ar fi capacitatea de a introduce material sub formă de text,

poşta electronică, etc. sunt o parte critică a sistemelor informatice executive.

Diferenţa majoră între conceptul de sisteme executive şi tradiţionalele sisteme

suport de decizie este întinderea mare de aplicaţii care sunt incluse într-un sistem

informatic executiv. Conceptul de sistem informatic executiv poate să includă multe

trăsături ale unui sistem suport de decizie, dar mediul executivilor şi rolul lor sunt atât de

complexe încât sunt necesare aplicaţii adiţionale pentru a asigura că toate cerinţele

managerilor sunt sunt satisfăcute. În practică, un sistem informatic executiv diferă de un

sistem suport de decizie în urmatoarele aspecte:

• Volumul informaţiei şi flexibilitatea. Un sistem informatic executiv integrează tipic

informaţiile dintr-o varietate mare de surse, atât interne cât şi externe. El susţine

datele, graficele şi textul şi încorporează instrumentele pentru a permite adaptarea

rapidă şi modificarea sistemului pentru a-l adapta schimbărilor intervenite;

• Gradul de specializare. Majoritatea sistemelor suport de decizie sunt specializate

funcţional, dezvoltate pentru a satisface cerinţele unui grup particular de afaceri, pe

când sistemele executive sunt proiectate pentru a satisface nevoile tuturor

managerilor executivi;

• Interfaţa. O interfaţă a unui sistem suport de decizie presupune că utilizatorul are

unele cunoştinţe în lucrul cu calculatorul şi are timp să se obişnuiască cu o interfaţă

complexă. Sistemul informatic executiv nu presupune asemenea cunoştinţe şi este

proiectat pentru a fi utilizat de persoane care nu au nici timpul şi nici înclinaţia de a

învăţa modul în care să utilizeze interfeţe complexe.

30

• Viteza de răspuns. Sistemele informatice executive sunt optimizate pentru a asigura

un timp scurt de răspuns, pe când sistemele suport de decizie, din cauza volumelor

mari de date implicate şi din cauza design-ului nu pot asigura timpi rapizi de

răspuns.

Aceste două tipuri de sisteme informatice se adresează unor nivele ierarhice

diferite. DSS creează un suport pentru managementul operativ cât şi pentru cel strategic,

iar EIS au ca beneficiari managerii executivi care trebuie să ia decizii strategice.

Un DSS este proiectat în special pentru a ajuta la descoperirea soluţiilor alternative

la probleme după care explorează ramificaţiile selectării uneia din alternative. Grupul de

manageri de mijloc sau de analişti interacţionează cu DSS-ul pentru introducerea datelor

sau presupunerilor, dezvoltarea modelelor, testarea efectelor datorate schimbării datelor şi

presupunerilor şi raportarea la executivii de la nivelul de vârf care iau deciziile finale. Pe

de altă parte, un EIS este în mod normal utilizat doar de o persoană (un executiv de vârf)

pentru a vizualiza informaţia într-un format special proiectat pentru nevoile sale. Pe baza

acestei informaţii, un executiv poate detecta o problemă sau o oportunitate competitivă

care necesită investigare.

Unul din obiectivele EIS este să aibă o interfaţă prietenoasă astfel încât, utilizarea

lor să nu necesite cunoştinţe informatice sau o experienţă vastă în lucrul cu calculatorul.

Spre deosebire de EIS, DSS sunt simplu de utilizat de către analişti dar necesită unele

cunoştinţe de specialitate, ceea ce le fac mai greoaie pentru managerii fără aptitudini în

lucrul cu calculatorul.

EIS furnizează în mod operativ informaţii de sinteză necesare managerilor

executivi, spre deosebire de DSS care furnizează informaţii şi analize detaliate pentru

decizii operative informate.

În timp ce EIS, în scopul sintetizării, filtrează datele pentru o mai bună administrare

a timpului, aceste sisteme pot conduce la date mai nesigure şi de neîncedere. DSS

examinează multiple alternative cu scopul alegerii celei mai bune decizii dar aceste operaţii

sunt consumatoare de timp, şi uneori, deciziile trebuie luate repede. Aceste sisteme

necesită timp pentru pregătire şi analiză, fiind orientate pe detalii.

EIS oferă instrumente puternice de prezentare grafică a situaţiilor sintetice şi

asigură suport pentru datele externe, în timp ce DSS furnizează doar suport moderat pentru

datele externe şi facilităţi grafice reduse.

31

În termeni de cum sunt utilizate, DSS ajută la rezolvarea problemelor

semistructurate şi nestructurate, spre deosebire de EIS care este utilizat aproape exclusiv

pentru probleme nestructurate.

Pentru a evidenţia câteva dintre caracteristicile şi diferenţele dintre cele trei tipuri

de sisteme informatice am realizat o prezentare comparativă în tabelul următor:

Caracteristica MIS DSS EIS

Nivelul de decizie

vizat

Operaţional, Tactic Tactic şi strategic Strategic

Beneficiarii

sistemului

Manageri la nivel

operaţional

Manageri la nivel

tactic

Manageri

executivi, la nivel

strategic

Tipuri de

informaţii

furnizate

Informaţii şi

indicatori ai

activităţii curente

Informaţii şi

indicatori ai

activităţii curente,

la nivel

departamental sau

organizaţional

Informaţii şi

indicatori

strategici,

indicatorii cheie de

performanţă

Oferă previziuni şi

predicţii ale

evoluţiei

indicatorilor de

activitate

Rar, la cerere Uneori, în cazul

indicatorilor la

nivel central şi

organizaţional

Obligatoriu, pentru

indicatorii cheie de

performanţă

Tipuri de rapoarte Rapoarte detaliate,

statice, rar cu

facilităţi de analiză

multidimensională

Rapoarte detaliate,

sintetice, dinamice,

cu unele facilităţi

de analiză

multidimensională

Rapoarte sintetice,

flexibile şi

dinamice, cu

facilităţi de analiză

multidimensională

Tipuri de

informaţii de ieşire

ale sistemelor

Informaţii detaliate Informaţii detaliate

/ agregate

Informaţii de

sinteză

Tipuri de decizii Structurate Structurate şi

nestructurate

Structurate şi de ce

mai multe ori

nestructurate

32

Caracteristica MIS DSS EIS

Oferă variante de

decizie

Nu Uneori Da

Interfaţa grafică Tabelară, grafică

dar cu

facilităţi de analiză

reduse, deseori sub

formă de foi de

calcul

Tabelară, grafică,

cu facilităţi de

analiză şi pivotare

Tabelară sub

formă de pivot,

grafică, facilităţi

de analiză

importante,

posibilităţi de

modificare

dinamică a

interfeţei

Nivelul

cunoştinţelor în

domeniul

informatic

Mediu Mediu Mic

Tabelul 2.1. Analiza comparativă între MIS, DSS şi EIS

Din analiza prezentată reiese că decizia de a utiliza un MIS, un DSS sau un EIS

depinde de cerinţele de afaceri, de nivelul de decizie, de volumul, sursa şi structura

informaţiilor implicate, de tipul deciziilor şi mai ales de beneficiarii sistemului. Insă pot

exista cazuri în care decizia de a implementa şi utiliza un EIS versus un DSS depinde de o

situaţie particulară, de exemplu în cazul în care în cadrul organizaţiei nu există un sistem

suport de decizie atunci se va prefera realizarea unui sistem informatic executiv dar cu

facilităţi şi capacităţi extinse, acoperind practic şi aria unui DSS. Este cazul prezentat în

ultimul capitol al tezei.

33

2.4. TEHNOLOGII UTILIZATE ÎN REALIZAREA SISTEMELOR

INFORMATICE EXECUTIVE

Aşa cum am menţionat anterior cerinţa principală impusă sistemelor informatice

executive este aceea de a asista procesul decizional de nivel strategic prin furnizarea şi

prezentarea de informaţii utile şi variante de soluţii într-un timp scurt şi într-o manieră

prietenoasă, adaptată cunoştinţelor informatice ale managerilor. Datorită obiectivelor şi

domeniilor de perfomanţă precizate mai sus se impune ca sursele de date furnizate

procesului decizional să fie cât mai variate. Astfel, se utilizează, în general, trei tipuri

diferite de informaţii: informaţii externe companiei, informaţiile din interiorul organizaţiei

şi comunicatii şi relaţii personale.

Aceste informaţii provin dintr-un număr mare de surse interne şi externe

organizaţiei. Problema extragerii informaţiilor folositoare din aceste surse devine mai

dificilă pe an ce trece, mai ales pentru managerii responsabili cu controlul marilor

corporaţii. Din acest motiv cerinţele de realizare a sistemelor informatice executive

necesită utilizarea de tehnologii şi instrumente variate de organizare, transformare,

procesare, analiză, interpretare şi prezentare a datelor provenite din surse multiple.

Aceste tehnologii fac parte din cateoria elementelor de inteligenţa afacerii

(Business Intelligence) şi cuprind: tehnologii de organizare a datelor în depozite de date

(Datawarehouse), sisteme de analiză de tipul OLAP (On-Line Analytical Processing),

algoritmi de extragere a cunoştinţelor din date (Data Mining), instrumente de extragere,

transformare şi încărcare a datelor, instrumente de modelare de tipul CASE şi

tehnologii web.

Tehnologiile implicate sunt combinate într-o arhitectură unitară şi pentru fiecare se

stabilesc în cadrul etapelor de analiză şi proiectare a sistemului rolul şi funcţionalităţile

implementate astfel încât să se asigure performanţa, fiabilitatea şi satisfacerea cerinţelor de

afaceri identificate în cadrul analizei de business. Datorită complexităţii sistemului şi

schimbărilor rapide care vor interveni în mediul de afaceri, tendinţa este de a opta pentru

o arhitectură tipică şi de a utiliza majoritatea tehnologiilor enumerate mai sus astfel încât

să se poată acoperi o serie cât mai variată de cerinţe. Voi prezenta în continuare un model

de arhitectură tipică utilizată în dezvoltarea sistemelor informatice executive, o viziune

asemănătoare fiind descrisă anterior şi în lucrările [BARA03/2], [BAFU03] şi

[BARA05/1].

34

2.5. ARHITECTURA SISTEMELOR INFORMATICE EXECUTIVE

In definiţia dată de Bonczek şi Holsapple în lucrarea “Foundation of Decision

Support Systems” (1981) autorii menţionează şi componentele principale ale unui sistem

suport de decizie în general şi anume că acesta este 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)” [MUNT04].

In [POWE00] autorul a identificat patru componente importante ale unui sistem

suport de decizie şi anume: interfaţa considerată adesea cea mai importantă componentă,

sistemul de baze de date care include bazele de date şi sistemele de gestiune al bazelor de

date ale organizaţiei, sistemul de modele ce conţine modelele analitice, matematice,

statistice şi componenta pentru asigurarea comunicaţiei reprezentată de reţelele şi

dispozitive mobile.

Arhitectura unui Sistem Informativ Executiv este în principiu asemănătoare cu cea

a sistemelor suport de decizie şi se poate structura pe patru nivele distincte [POWE00]:

Gestiunea datelor (nivelul 1) reprezintă nivelul de bază, al surselor de date, a

sistemelor de gestiune a bazelor de date şi a dicţionarelor metadatelor. Este format din

serverul depozitului de date şi, în cele mai multe cazuri şi un server de baze de date

relaţionale. Datele din bazele de date operaţionale şi din sursele externe sunt extrase

utilizând programe de aplicaţii tip interfaţă cunoscute sub numele de gateways. Un

gateway funcţionează pe baza SGBD-ului şi permite programelor utilizator să genereze

cod SQL pentru a fi executat de server. Exemplele gateways includ ODBC (Open

DataBase Connection) şi OLE-DB (Open Linking and Embedding for DataBase) şi JDBC

(Java DataBase Connection).

La acest nivel o problemă des întâlnită este aceea a integrării datelor din surse

multiple. Pentru aceasta se pot utiliza tehnologii de integrare bazate pe date cum ar fi:

replicarea, federalizarea, construirea de depozite de date, opţiunea recomandată pentru

capacitatea de a organiza, stoca şi prelucra un volum mare de date. Alte modalităţi şi

tehnologii de integrare a datelor sunt descrise pe larg în raportul de cercetare [BALV06].

Sursele de date pot fi: bazele de date operaţionale curente, bazele de date istorice,

precum şi bazele de date externe sau publice. Sunt necesare o serie de etape pentru

utilizarea corespunzatoare a datelor:

• Culegerea datelor din surse multiple în funcţie de cerinţele informaţionale;

35

• Extragerea datelor din bazele de date operaţionale sau din sursele externe. Se poate

forma un depozit de date sursă în care să se colecteze toate datele necesare care

apoi să fie prelucrate şi încărcate într-un alt depozit destinaţie. Acest proces trebuie,

cel mai adesea, să transforme datele în structura şi formatul intern al depozitului;

• Curăţirea datelor, pentru a exista certitudinea că datele sunt corecte şi pot fi

utilizate pentru analiză;

• Incărcarea datelor corecte în depozitul de date destinaţie;

• Prelucrarea datelor şi realizarea unor agregări implicite: totaluri precalculate,

subtotaluri, valori medii etc, care se preconizează că vor fi cerute şi folosite de

utilizatori.

Astfel datele sunt extrase, curăţate, transformate şi încărcate într-un depozit de date

destinaţie de unde vor fi utilizate de nivelele superioare ale sistemului. De asemenea,

trebuie luată în considerare şi modalitatea de împrospătare a datelor din depozit, pe măsura

trecerii timpului. Dacă, de exemplu, dimensiunea timp are în structură luna, trimestru, an,

înseamnă că la sfârşitul fiecărei luni, al fiecărui trimestru sau al fiecărui an datele din

sistemul operaţional trebuie să împrospăteze depozitul de date.

Gestiunea modelelor (nivelul 2) este nivelul unde se prelucrează, se transformă şi

se extrag informaţiile şi include modele de analiză şi previziune a datelor destinate

satisfacerii cerinţelor manageriale de nivel înalt. La acest nivel componentele principale

sunt: baza de modele, sistemul de gestiune a bazei de modele, metamodelele (sau

dicţionarul de metamodele), serverul de gestiune şi execuţie a modelulelor.

Pentru realizarea sistemelor informatice executive la acest nivel se alege

implementarea funcţionalităţilor OLAP. Instrumentele OLAP se bazează pe reprezentarea

multidimensională a datelor, şi permit analiza interactivă şi rapidă a datelor prin operaţiuni

de tip roll-up, drill-down, slice sau dice. Serverul OLAP este implementat în mod obişnuit

utilizând fie un model relaţional OLAP (ROLAP), fie unul multidimesional OLAP

(MOLAP). Modelul ROLAP este o extensie a modelului relaţional prin care se transformă

operaţiile realizate pe baze de date relaţionale în operaţii multidimensionale. Modelul

MOLAP este dedicat şi implementează direct descrierea datelor şi a operaţiilor

multidimensionale. Modelul de date multidimensional va fi descris pe larg în cadrul

capitolului următor.

Tot la acest nivel, dacă cerinţele de afaceri o impun, se pot proiecta şi implementa

algoritmi de extragere a cunoştinţelor din date cu ajutorul instrumentelor de data mining.

36

Acestea asigură transformarea datelor în cunoştinţe, utilizând tehnici de analiză statistică

sau de inteligenţă artificială ce permit identificarea corelaţii, regulilor, cunoştinţelor utile

sprijinirii procesului decizional.

Interfaţa (nivelul 3) este nivelul superior prin care utilizatorul poate comunica cu

sistemul şi îl poate comanda şi trebuie proiectată astfel încât utilizatorii finali, managerii

executivi să nu aibă nevoie de asistenţă suplimentară şi să poată interacţiona uşor cu

sistemul.

Acesta este nivelul client care conţine instrumente pentru generarea interogărilor

şi a rapoartelor, instrumente de analiză dinamică (vizualizarea datelor sub diverse

perspective, analiza evoluţiei ulterioare, predicţii, previziuni, corelaţii între date). La acest

nivel se regăseşte şi resursa umană reprezentată prin decidenţi, manageri executivi care

interacţionează cu sistemul prin intermediul interfeţelor .

Pentru integrarea rapoartelor şi a interfeţelor obţinute se pot utiliza tehnologii de

integrare a aplicaţiilor cum ar fi: servere de aplicaţii care implementează modelele

middleware, SOA (service oriented arhitecture), platforme Java şi web. O tot mai mare

pondere în realizarea interfeţelor sistemelor suport de decizie în general şi a sistemelor

informatice executive în special o au în ultimul timp tehnologiile web bazate pe portal.

Portalurile de Inteligenţa Afacerilor ocupă locul cel mai important în realizarea unor

interfeţe specilizate pentru sistemele executive, cu interfeţe prietenoase, accesibile şi ce

oferă posibilitatea integrării multiplelor rapoarte şi instrumente grafice obţinute din

etapele anterioare.

Telecomunicaţiile (nivelul 4) se referă la reţelele de calculatoare, dispozitivele de

comunicaţii, la modul cum este organizat hardware-ul în reţea, suportul pentru software-ul

distribuit şi cum sunt integrate şi conectate fizic componentele sistemului.

Gama tehnologiilor asociate sistemelor informatice executive poate fi prezentată

ca în figura 2.1. În partea stângă sunt evidenţiate componentele din partea de back-end

(instrumente de extragere şi transformare), iar în partea dreaptă componentele din partea

de front-end (instrumentele de extragere şi accesare a datelor).

37

v

v

Arhitectura unui sistem informatic executiv poate fi privită şi din punctul de vedere

al nivelurilor de realizare, de jos în sus, piramidal, pe trei niveluri: bottom-tier, middle-

tier şi top-tier (figura 2.2):

1. Nivelul datelor (bottom–tier) – reprezintă nivelul surselor de date pentru EIS în

care are loc integrarea tuturor surselor relevante de date din interiorul organizaţiei

din modulele operaţionale (producţie, financiar, clienţi, comercial, etc) şi exteriorul

organizaţiei (legislaţie, concurenţă, cunoştinţe), procese de extragere, transformare

şi încărcare a datelor (ETL – Extract, Transform, Load) şi depozitele de date din

care se extrag date pentru analiză. Modelele de date utilizate pot fi relaţionale,

orientate-obiect, multidimensionale.

2. Nivelul de analiză (middle-tier) – reprezintă nivelul de analiză a datelor cu

ajutorul tehnologiilor OLAP şi data mining şi pin extragerea datelor din depozite

prin interogări SQL.

3. Nivelul de prezentare (top-tier) – reprezintă nivelul de prezentare şi utilizare a

datelor prin instrumente grafice, rapoarte, interfeţe web, etc.

Intre aceste trei niveluri legătura este realizată de componenta telecomunicaţiilor

reprezentată prin reţelele de comunicaţii, dispozitive mobile, protocoale şi standarde de

interconectare.

NIVELUL MODELELOR

NIVELUL DATELOR

Tehnologii de extragere şi transformare şi integrare a datelor

Tehnologii de procesare şi

analiză a datelor

Surse eterogene

Tehnologii de integrare a datelor: replicare, federalizare; Instrumente de extragere, transformare, încărcare a datelor (ETL); Instrumente de asigurare a calităţii;

Depozite de

date

Sisteme de raportare de

excepţie

SQL

Data Mining

Tehnologia OLAP

Figura 2.1.Repartiţia tehnologiilor în cadrul arhitecturii

NIVELUL INTERFEŢEI

Tehnologii de integrare a aplicaţiilor;

Tehnologii Web;

Instrumente de prezentare a datelor:

rapoarte, grafice

Tehnologii de prezentare a informaţiilor

38

Figura 2.2. Arhitectura complexă a sistemelor informatice executive

Pornind de la această arhitectură a sistemelor informatice executive voi prezenta

în capitolele următoare soluţiile şi tehnologiile utilizate în realizarea EIS pe fiecare nivel

al arhitecturii: soluţii de organizare a datelor, de extragere a datelor din depozite de date,

de extragere a cunoştinţelor pentru obţinerea de informaţii noi, de analiză dinamică a

datelor, iar în ultimul capitol al acestei lucrări am realizat un sistem informatic executiv

pe baza acestor soluţii şi tehnologii.

BOTTOM-TIER

TOP-TIER

MIDDLE-TIER

Producţie Comercial

Financiar

HR

Surse externe

Fişiere diverse

Integrare Extragere/Transformare/Încarcare (ETL)

Surse de date

Dicţionarul metadatelor Depozitul de date centralizat

Data Marts

Destinaţiile datelor

OLAP Data Mining

Interogări SQL

Interfeţe de prezentare: grafice,

web, rapoarte

39

CAPITOLUL III. SOLUŢII DE ORGANIZARE A DATELOR ÎN DEPOZITE DE DATE (DATAWAREHOUSES)

Principala modalitate de organizare a datelor în cadrul sistemelor tranzacţionale a

fost şi va rămane soluţia de organizare în baze de date relaţionale. Însă, la nivelul de

agregare şi sinteză cerute de sistemele informatice executive, organizarea datelor în baze

de date devine ineficientă din prisma timpului de interogare şi a cerinţelor de prelucrare

crescute. Din acest motiv, dar şi datorită facilităţilor de integrare al surselor neomogene

de date, ca soluţie de organizare a datelor în cadrul sistemelor informatice executive se

impun depozitele de date. Un depozit de date furnizează o sursă integrată şi centralizată de

date, aparte faţă de sistemul tranzacţional, care conţine datele esenţiale despre activitatea

companiei din multitudinea de surse de date existente. Rapoartele obţinute pe baza acestor

date sunt utilizate ca un instrument de analiză strategic şi competitiv, şi din acest punct de

vedere analizele rapide şi corecte pot influenţa deciziile privind evoluţia organizaţiei pe

termen mediu şi lung.

O definiţie a depozitelor de date formulată de către Consiliul OLAP este

următoarea [OLAP95]:

“Un depozit de date (datawarehouse) reprezintă o stocare centralizată a datelor

detaliate provenite din toate sursele relevante din cadrul unei organizaţii şi permite

interogarea dinamică şi analiza detaliată a tuturor informaţiilor.”

Spre deosebire de sistemele operaţionale, structurile de date într-un depozit de date

sunt optimizate pentru o regăsire şi o analiză rapidă. Datele sunt istorice şi sunt actualizate

la intervale regulate de timp, în funcţie de cerinţele de raportare.

Definiţia lui William Inmon, cunoscut drept părintele acestui concept este extrem

de concisă: “un depozit de date este o colecţie de date orientate pe subiecte, integrate,

istorice şi nevolatile destinată sprijinirii procesului de luare a deciziilor manageriale”

[INMO96]

În viziunea lui Ralph Kimball [KIMB96] depozitul de date oferă acces la datele

organizaţionale, datele obţinute sunt consistente şi pot fi separate şi combinate în funcţie de

fiecare dimensiune sau aspect al afacerii. Depozitul de date include, de asemena un set de

instrumente pentru interogare, analiză şi prezentare a informaţiilor şi reprezintă locul în

care sunt publicate datele folosite. Calitatea datelor conţinute în depozit reprezintă o

premiză pentru reingineria afacerii.

40

După Barry Devlin [DEVL97] un depozit de date înseamnă o stocare a datelor,

unitară, completă şi consistentă, obţinută dintr-o varietate de surse, disponibilă

utilizatorilor finali într-un mod uşor perceptibil şi utilizabil în contextul afacerii.

Sam Anahory [ANDE97] subliniază finalitatea depozitelor de date precizând că un

depozit de date include datele şi procesele manageriale care fac informaţiile disponibile,

permiţând managerilor să ia decizii corect fundamentate.

Totodată o serie de firme şi-au adus contribuţia în definirea, dezvoltarea şi

popularizarea tehnologiilor de data warehouse precum: IBM, Software AG, Oracle,

Microsoft, Prism Solution etc.

Din punctul meu de vedere, un depozit de date reprezintă o modalitate de integrare

şi organizare a datelor din surse omogene şi neomogene, provenite din sisteme

tranzacţionale dar şi din fişiere externe, integrate după anumite criterii, supuse unui

proces de extragere, transformare şi încărcare, stocate agregat pe nivele ierarhice,

destinate prelucrărilor şi analizelor dinamice, fiind soluţia optimă de organizare a datelor

pentru sistemele informatice suport de decizie şi executive.

Volumul mare de date din depozitele de date impune utilizarea unor instrumente şi

tehnologii speciale de extragere a datelor cum ar fi analiza dinamică multidimensională,

metode statistice de prognoză şi metode matematice aplicate unui volum foarte mare de

date. Analiza statistică a datelor şi extragerea unor cunoştinţe aflate în astfel de depozite de

date a căpătat denumirea de data mining, sau minerit al datelor, termen a cărui folosire este

evidentă. Din volumul foarte mare de date se extrag numai datele relevante pentru suportul

decizional, celalalte fiind ignorate sau utilizate în alte scopuri.

Ca volum, un depozit de date este alcătuit din baze de date conţinând intre 1 şi

peste 10 terabyte, aceste cifre neavând decât un caracter orientativ [VILA97]. Există astfel

şi depozite de date conţinând zeci de terabyte. Crearea unui astfel de depozit costă în medie

3-5 milioane $. Din acest cost, o treime o reprezintă serviciile profesionale. O altă treime

se cheltuieşte pentru software-ul necesar extragerii, prelucrării, depozitării şi analizării

datelor, iar ultima treime este destinată sistemelor hardware necesare stocării datelor. De

obicei, depozitele de date îşi dublează dimensiunile în primele 12 până la 18 luni. Această

creştere exponenţială poate fi pe de o parte semnul sigur al succesului implementării

depozitelor dar, pe de alta parte, poate deveni o problemă dacă sistemele nu sunt construite

de la început suficient de elastice şi de deschise.

Din cele de mai sus rezultă importanţa deosebită a flexibilităţii impuse sistemelor

care implementează asemenea depozite de date. Aici flexibilitate înseamnă o conectivitate

41

la nivelul întregii organizaţii, astfel încât servere de baze de date diferite să se poată

conecta simultan la depozitul deja existent. Este de asemenea deosebit de important să se

aleagă o arhitectură care să se adapteze uşor la modificările de performanţe, capacitate şi

conectivitate. Procesele de configurare, optimizare si administrare a sistemului, inclusiv

procedurile de salvare - restaurare, precum si păstrarea în tot acest timp a functionalităţii

sistemului pot deveni operaţii extrem de dificile dacă trebuie repetate la fiecare adăugare a

unor noi servere în sistem.

Pentru a evita aceste probleme, se poate alege o cale de mijloc şi se poate opta

pentru realizarea unui sub-depozit care să conţină numai datele relevante pentru analiza

necesară. Astfel de sub-depozite sunt numite data marts şi pot fi făcute să funcţioneze pe

configuraţii şi cu resurse mai modeste decât depozitele de date într-un timp mult mai scurt.

Un astfel de data mart este un depozit de date specific unui anumit subset de cerinţe

sau unui anumit departament din cadrul organizaţiei. În timp ce un depozit de date conţine

datele care pot fi utilizate pentru a răspunde oricărei întrebări privind afacerile unei

companii, un data mart conţine datele pertinente unui anumit compartiment al companiei.

Conectând împreună data mart-urile aferente diferitelor compartimente ale companiei,

formând astfel o infrastructură specifică, departamentele pot folosi în comun datele lor şi

se poate crea un depozit de date mai uşor de construit şi mai elastic.

Un data mart tipic poate utiliza servere existente, structura informaţională existentă

(un LAN sau un Intranet) cu mai puţin de 500 GB, costă mai puţin de 1 milion de dolari şi

se implementează de obicei aproximativ 90 de zile. Companiile de software au început deja

să ofere pe piaţă produsele necesare pentru a construi aceste data marts.

Rolul unui depozit de date este de a oferi o imagine coerentă asupra datelor relative

la activitatea unei organizaţii şi a contextului în care acesta acţionează. Utilizarea acestei

colecţii poate consta din extragerea unor rapoarte (la cerere sau cu o anumită periodicitate),

extragerea unor date pentru a fi utilizate de aplicaţiile de birotică (programe de calcul

tabelar, procesoare de text, programe de prezentare, etc), dar mai ales pentru a fi utilizate

de către aplicaţii specializate de analiză. Acestea au la bază două categorii de tehnologii de

analiză on-line (OLAP - On Line Analytical Processing) aplicaţii axate pe analiză

multidimensională si tehnologii pentru extragerea cunoştinţelor din date (data mining)

axate pe descoperirea unor şabloane semnificative în colecţii de date.

42

3.1. CARACTERISTICI ALE ORGANIZĂRII DATELOR ÎN DEPOZITE DE

DATE

Datorită obiectivelor impuse de utilizarea depozitelor de date în analiză se desprind

câteva caracteristici mai importante pe care acestea le deţin:

• Depozitul de date asigură accesul la datele organizaţiei. Accesul trebuie să se

realizeze într-un timp cât mai scurt, la cerere şi să fie performant. Datele într-un

depozit de date pot fi separate şi combinate pentru a oferi un acces cât mai rapid şi

un timp de răspuns cât mai mic sistemului. De asemenea, accesul presupune

existenţa unor utilitare care să fie foarte uşor de folosit.

• Datele dintr-un depozit de date trebuie să fie consistente. Consistenţa presupune

faptul că atunci când două persoane solicită acelaşi set de informaţii să primească

aceleaşi date, chiar dacă ele au fost cerute la momente de timp diferite. Dacă datele

nu au fost complet încărcate atunci utilizatorul va fi avertizat cu privire la acest

lucru şi este sfătuit să aştepte până ce vor fi complet încărcate.

• Datele din depozite sunt utilizate direct în analize, fără alte prelucrări

suplimentare. Datele nu sunt doar centralizate, integrate şi stocate ci, după ce sunt

extrase dintr-o varietate de surse, sunt corectate de erori, transformate, li se asigură

calitatea necesară şi abia apoi devin utilizabile. Depozitele de date nu reprezintă

doar datele ci şi un set de utilitare pentru a interoga, analiza şi prezenta informaţiile.

• Calitatea datelor din depozitele de date este un factor determinant pentru procesul

de analiză. Se întâlneşte frecvent situaţia în care datele nu sunt de bună calitate sau

nu sunt extrase în întregime sau au un caracter incert din punct de vedere al

conţinutului ceea ce face ca analiza ulterioară să conducă la rezultate eronate.

O consecinţă importantă a acestor caracteristici este redundanţa datelor. Dacă în

sistemul operaţional redundanţa este eliminată (prin procesul de normalizare) pentru a

evita anomaliile de actualizare, în depozitul de date redundanţa este creată în mod

intenţionat prin denormalizare si agregare pentru a permite un acces mai rapid la date.

Integrarea datelor reprezintă o altă consecinţă importantă a realizării depozitului

de date şi, în cele din urmă, raţiunea pentru care acesta este creat. Datele sunt încărcate

pentru a răspunde nevoilor informaţionale ale întregii organizaţii, asigurând faptul că

rapoartele generate pentru diverse compartimente vor conţine aceleaşi rezultate. Sistemul

operaţional este de cele mai multe ori format din subsisteme semi-independente, create la

43

momente diferite, de echipe diferite, în maniere diferite, ceea ce face imposibilă folosirea

acestui sistem pentru analiză.

Integrarea datelor provenind din sistemul operational şi din alte surse se referă la

diferite aspecte: modalităţi unice de codificare, sistem de unităţi de măsură consistent,

sistem stabil de reprezentare fizică a datelor, convenţii clare privind modul de

reprezentare a datelor calendaristice, convenţii unice privind denumirile şi conţinutul

acestora.

3.2. ARHITECTURA DEPOZITELOR DE DATE

Arhitectura depozitelor de date poate varia în funcţie de situaţia specifică a fiecărei

organizaţii. În cazul unei arhitecturi de bază, datele sunt încărcate din una sau mai multe

surse, iar utilizatorii accesează în mod direct depozitul de date.

O arhitectură complexă este structurată pe patru niveluri distince de realizare a

datelor astfel:

• Nivelul surselor de date în care se colectează date eterogene provenite din diverse

sistemele operaţionale ale organizaţiei. De regulă se utilizează un proces de

integrare a acestor date printr-un modul separat al depozitului de date numit şi

modul sursă.

• Nivelul transformăriii datelor în care se foloseşte un proces de extragere,

transformare (curăţare) şi încărcare a datelor (ETL - Extract, Transform, Load) ce

presupune prelucrarea datelor din punct de vedere al integrităţii, preciziei, acurateţii

şi al formatului.

• Nivelul depozitului de date conţine datele prelucrate, încărcate în structuri

multidimensionale şi agregate pe diferite niveluri pregătite pentru a fi utilizate în

analiză. La acest nivel se pot proiecta multiple sisteme de tipul data mart proiectate

pentru compartimente şi departamente ale întreprinderii.

• Nivelul de prezentare şi raportare a datelor presupune extragerea datelor din

depozit şi utilizarea unor instrumente şi tehnologii de inteligenţa afacerii (Business

Intelligence) pentru analiza şi interpretarea informaţiilor furnizate. La acest nivel se

utilizează funcţionalităţile OLAP pentru analiză, informaţiile fiind prezentate

grafic, tabelar, integrate în portaluri etc.

Figura următoare prezintă un sistem complex de datawarehouse:

44

Figura 3.1: Depozit de date cu arhitectură complexă

Pe această arhitectură din punct de vedere funcţional se regăsesc trei nivele

distince de realizare (fig. 3.2.):

• Modulul operaţional - reprezentat de datele companiei care sunt de obicei păstrate

sub formă diferită la locaţii diferite. Aceste date pot proveni de la aplicaţii sau de la

sisteme distribuite din cadrul companiilor cum ar fi sisteme de gestiune a

comenzilor, de eliberare a facturilor, de contabilitate financiară, de gestiune a

stocurilor, salarizare, etc. Indiferent de originea lor, datele trebuie să fie colectate şi

aduse într-o formă consistentă pentru a putea fi folosite. Acest proces de

transformare a datelor reprezintă baza pe care se construieşte un depozit de date

consistent, de înaltă calitate. Transformarea datelor presupune un proces de

extragere, condiţionare, curăţare, fuziune, validare şi încărcare (ETL).

• Modulul central al depozitului de date – reprezentat de SGBD-ul şi de serverul pe

care acesta rulează şi de modul în care este implementat depozitul - există în acest

moment două tendinţe: una ar fi implementarea unui sistem distribuit,

descentralizat unde datele sunt păstrate în unităţi independente (Independent Data

Marts) fiecare conţinând datele relevante pentru un anumit aspect al operaţiilor

unei instituţii, iar a doua posibilitate ar fi implementarea unei surse de date unice,

centralizate la care au acces utilizatorii din toate departamentele unei instituţii.

• Modulul strategic, de afaceri - valoarea finală a unui depozit de date este

determinată de avantajele pe care le oferă utilizatorului în diferite procese de luare

Interogari

Data Warehouse

OLAP

Data Mining

Rapoarte

Surse de date

ETL

Tehnologii de analiză a datelor

Stocare centralizata

Data Marts

Depozitul de date

Fisiere Baze de date Surse externe

Extragere, trasformare,

încărcare

45

a deciziilor şi analiză. Prin folosirea diferitelor modalităţi de acces la informaţie şi a

tehnologiilor de procesare disponibile, utilizatorii pot obţine informaţii care îi vor

ajuta în procesele de stabilire a strategiei firmei. La ultimul nivel al arhitecturii,

datele sunt pregătite pentru interpretare şi analiză cu ajutorul instumentelor

specifice cum ar fi: instrumente de realizare a graficelor, prezentări, rapoarte

dinamice, browsere Web, instrumente de vizualizare a datelor.

Figura 3.2: Modulele funcţionale ale unui depozit de date

Arhitectura funcţională a depozitelor de date prezentată mai sus permite

proiectarea şi implementarea unor diverse tipuri de depozite de date în funcţie de cerinţele

de afaceri, resursele disponibile şi posibilităţile de realizare. Voi prezenta mai jos o

clasificare a acestor tipuri de depozite de date, urmând să realizez o analiză comparativă

a performanţelor obţinute în urma implementării acestora la sfârşitul acestui capitol.

Astfel, din punct de vedere al ariei de cuprindere se întâlnesc trei tipuri de depozite

de date:

Depozitul central al organizaţiei (Enterprise Warehouse) colectează toate

informaţiile despre subiectele care privesc întreaga organizaţie şi furnizează un volum

extins de date. De regulă conţine date detaliate, dar şi date agregate, iar ca ordin de mărime

porneşte de la câţiva gigabytes până la sute de gigabytes şi terabytes. Un depozit de date de

întreprindere trebuie implementat pe servere puternice UNIX sau pe platforme cu

Extragerea şi procesarea datelor pentru analiză Utilitare pentru accesul la date

Data Marts Replicare şi distribuire

Depozitul de date central

Extragere, Transformare şi Încărcare (ETL)

Date operaţionale: secvenţiale, nerelaţionale, relaţionale, fişiere, surse externe

Modulul Strategic

Modulul Central

Modulul Operaţional

Sisteme operaţionale, sisteme informatice integrate (ERP)

Sisteme DSS, MIS, EIS

46

arhitecturi paralele. Acest tip de depozit necesită însă cheltuieli şi resurse mai mari pentru

analiză, proiectare şi realizare [RYAN99].

Data mart-ul conţine un subset al volumului de date din organizaţie, specific unui

grup de utilizatori sau departament. Domeniul este limitat la subiecte specifice. Datele

conţinute în data mart sunt de obicei agregate. În mod curent data marts sunt implementate

pe servere departamentale cu resurse mai reduse care se bazează pe UNIX sau Windows

2000/2003. Ciclul de implementare al unui data mart este mai curând măsurat în săptămâni

sau luni dacât în ani. Ca atare, un data mart poate fi considerat un subansamblu al unui

depozit de date mai uşor de construit şi întreţinut şi mai puţin scump [INMO99].

Depozitul virtual (Virtual warehouse) este un set de tabele virtuale (views) asupra

bazelor de date operaţionale. Pentru eficienţa procesărilor interogărilor, numai unele din

viziunile de agregare pot fi materializate. Un depozit virtual este uşor de construit, dar

problema extragerii şi prelucrării datelor revine în mod exclusiv serverului de baze de date,

ceea ce poate conduce la un timp de prelucrare mare, însă se elimină necesitatea stocării

datelor într-un depozit real [HOLL00]. Această variantă se recomandă a fi aplicată în cazul

în care volumul de date necesar este mic, de mii de înregistrări. Insă dacă se depăşeşte

acest interval, timpul de extragere a datelor creşte semnificativ şi recomandabil ar fi să se

combine soluţia de depozit virtual cu stocarea datelor agregate separat într-un data mart

sau depozit de date real.

O altă clasificare a depozitelor de date este propusă în lucrarea [POWE00] în care

se identifică cinci tipuri, în funcţie de aria de cuprindere a proceselor decizionale şi

anume:

• Depozitul de date de tip organizaţional sau “galactic” (galactic datawarehouse -

GDW) reprezintă un tip de depozit centralizat, cu o arie de cuprindere extinsă având

drept obiectiv integrarea şi prelucrarea datelor la toate nivelurile organizaţiei, atât la

nivelul departamentelor cât şi al întregii organizaţii;

• Depozitul de date orientat pe procese de afacere (business process datawarehouse

- BPDW) reprezintă un tip de depozit specializat, orientat pe satisfacerea cerinţelor

de afaceri şi a proceselor de afaceri;

• Depozitul de date departamental (departamental datawarehouse - DDW) reprezintă

un tip de depozit orientat pe departamente, având drept obiectiv integrarea şi

prelucrarea datelor din fiecare departament în parte;

47

• Centru de date de tip proces de afaceri (business process data mart - BPDM)

reprezintă un tip de depozit specializat, orientat pe satisfacerea unei anumite cerinţe

de afaceri şi a unui singur proces de afaceri;

• Centru de date departamental (departamental data mart - DDM) reprezintă un tip

de depozit specializat, cu o arie de cuprindere limitată la un anumit departament,

având drept obiectiv integrarea şi prelucrarea datelor specifice activităţilor acestuia;

In practică consider că ar fi recomandabilă combinarea acestor tipuri de depozite

deoarece nu este indicat să se proiecteze un data mart pentru fiecare proces de afaceri sau

pentru fiecare departament şi apoi să se reunească într-un depozit centralizat, fără să se

ţină cont şi de relaţiile interdepartamentale.

3.3. TRECEREA DE LA MODELUL RELAŢIONAL LA MODELAREA

MULTIDIMENSIONALĂ

Depozitele de date impun condiţii de realizare diferite faţă de bazele de date

relaţionale. Dintre aceste diferenţe menţionez următoarele:

• Condiţii de utilizare – depozitele de date sunt proiectate pentru analize ad-hoc şi

rezultatele nu sunt cunoscute dinainte, iar modelul datelor este optimizat pentru a

realiza o mare varietate de interogări. In schimb sistemele tranzacţionale suportă

numai anumite operaţii pentru care au fost proiectate;

• Modificarea datelor - datele din depozite sunt actualizate regulat (de regulă

săptămânal sau lunar) cu ajutorul procesului de extragere, transformare şi încărcare

automată (ETL). Utilizatorii finali nu pot modifica (actualiza) direct datele. În

sistemele tranzacţionale utilizatorii finali sunt cei care actualizează datele astfel

încât să se reflecte starea fiecarei tranzacţii din întreprindere;

• Modelul utilizat - în depozitele de date se foloseşte forma denormalizată (cum este

schema stea) pentru optimizarea operaţiilor, faţă de forma normalizată a datelor

din modelul relaţional care optimizează operaţiile de actualizare/inserare/şterge şi

garantează consistenţa datelor;

• Operaţii tipice - o interogare a depozitelor de date poate parcurge mii sau chiar

milioane de înregistrări (de exemplu pentru a analiza totalul vânzărilor din luna

trecută pentru toţi clienţii existenţi). In schimb o operaţie tranzacţională afectează o

singură înregistrare sau un număr limitat de înregistrari;

48

• Date istorice - în depozitele de date se stochează de regulă datele istorice din

ultimii ani faţă de modul de lucru al sistemelor tranzacţionale care stochează date

pe câteva luni astfel încât să realizeze tranzacţiile curente cu succes.

O ultima şi controversată diferenţa între cele două tipuri de modele este modul de

abordare a datelor. Esenţa unui model multidimensional de calitate sporită este alegerea

unui set de dimensiuni cât mai apropiate de cele naturale şi de perspectiva utilizatorului.

Este folositor să avem o analiză dintr-o perspectivă relaţională a datelor înainte de a incepe

analiza dimensională deoarece echipa de proiectanţi a depozitului de date va înţelege datele

mai bine. Modelul multidimensonal trebuie abordat mai mult din perspectiva utilizatorului

decât din cea a datelor.

Tehnica modelării multidimensionale permite o restructurare a datelor în vederea

interogării lor prin tehnologii de analiză specifică. Nu este uşor de transformat un model

relaţional în unul multidimensional, chiar dacă modelam aceleaşi date. Cele două abordări

cer premise diferite, tehnici diferite şi produc baze de date cu structuri diferite.

Modelarea dimensională produce o bază de date care este mult mai uşor de

consultat şi de interogat la un nivel înalt, sintetic, agregat. De asemenea, modelul

dimensional produce o bază de date cu mai puţine tabele şi chei de administrat decât

modelul ER.

Tabelul de mai jos descrie diferenţele principale între prelucrarea tranzacţională

(modelul relaţional) şi prelurarea analitică (modelul multidimensional) [CRAB99]:

Caracteristici Modelul relaţional Modelul multidimensional

Organizarea datelor Tabela Dimensiuni, tabele de fapte, cub de date

Nivelul datelor Detaliu Agregat

Operaţia tipică Actualizare Raportare şi analiză

Nivelul de analiză cerut Scazut Ridicat

Volum de date per tranzacţie Redus Mare

Vârsta datelor Curente Istorice, curente, previzionate

Tabel 3.1: Paralela între prelucrarea relaţională şi cea analitică

49

3.4. MODELUL DE DATE MULTIDIMENSIONAL

Pentru definirea unui model de date este necesară specificarea următoarelor

elemente:

• Structura modelului constituită din obiectele modelului precum şi relaţiile dintre

ele;

• Operatorii care acţionează asupra structurii;

• Restricţiile de integritate formate din totalitatea de regului şi constrângeri impuse

modelului pentru asigurarea corectitudinii datelor.

Structura modelului conţine în principal obiectele referitoare la tabele de fapte cu

atributele de tip măsuri sau metrici, tabelele de tip dimensiune în care regăsim nivele

ierarhice, attribute de descriere, etc. Aceste obiecte vor fi prezentate în continuare.

In cadrul modelului multidimensional se întâlnesc mai multe tipuri obiecte care

prezintă o importanţă deosebită în analiză [KIRE98]:

Dimensiunile – reprezintă structuri compuse atribute structurate pe diverse niveluri

ierarhice în funcţie de care sunt grupate datele. Aceste atribute sunt de obicei descriptive şi

sunt folosite ca sursă pentru restricţii şi pentru rândurile din rapoarte. Sunt considerate

tabele secundare datorită dimensiunilor reduse. Consiliul OLAP defineşte conceptul de

dimensiune ca fiind “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). Dimensiunile repreznintă un mod foarte concis, intuitiv

de organizare şi selectare a datelor pentru explorare şi analiză.” [OLAP95]. Datele sunt

de obicei colectate la nivelul cel mai detaliat şi apoi agregate pe nivelele superioare pentru

analiză.

In cadrul dimensiunilor se regăsesc şi conceptele de ierarhie, nivel, atribut,

concepte care vor fi prezentate în continuare:

Ierarhiile – sunt structuri logice utilizate pentru ordonarea nivelelor de reprezentare

a datelor. Sunt utilizate şi pentru definirea căilor de navigare în interiorul datelor. Nivelele

ierarhice sunt utilizate de instrumentele de analiză OLAP permiţând detalierea graduală a

datelor. Tot în definiţiile date de Consiliul OLAP se menţionează că “membrii

dimensiunilor pot fi organizaţi pe baza relaţiilor de tip părinte-copil, unde un membru

părinte reprezintă agregarea membrilor copil. Rezultatul este o ierarhie şi relaţiile

părinte-copil sunt relaţii ierarhice”. [OLAP95]

50

Ierarhia definită pe o dimensiune determină aranjarea membrilor dimensiunii într-o

configuraţie piramidală. Pe orizontală se plasează rezultatele corespunzătoare măsurilor de

pe acelaşi nivel în ierarhia dimensiunii, iar pe verticală se plasează rezultatele având

niveluri diferite în ierarhia dimensiunii.

Nivelele – reprezintă poziţii în cadrul ierarhiilor (figura 3.3). De exemplu

dimensiunea Timp poate avea trei nivele de ierarhizare: an, trimestru şi lună. Nivelele se

structurează în funcţie de ierarhie de la general la specific, rădăcina fiind reprezentată de

nivelul superior, cel mai înalt al ierarhiei. Relaţiile între diferite nivele sunt relaţii de tipul

părinte-copil. Se pot defini ierarhii în care datele fiecărui nivel sunt agregate la un nivel

superior sau se pot sări anumite nivele care sunt independente.

Figura 3.3: Ierarhii şi nivele

Atribute – dimensiunile conţin atribute care reprezintă calificative specifice. Orice

atribut se asociază unei singure dimensiuni, iar o dimensiune se poate exprima prin mai

multe atribute. Cu cât aceste atribute sunt mai descriptive cu atât depozitele de date vor fi

mai performante.

Tabelele de fapte – sunt tabelele centrale. Acestea conţin atribute de tip măsuri

(metrici) şi chei externe către tabelele dimensiuni. Faptele sunt de obicei date numerice

care pot fi însumate şi analizate pe diferite nivele.

Metricile (măsurile) corespund atributelor (faptelor) din tabelele de fapte şi sunt de

regulă de natură numerică (de exemplu: volumul vânzărilor, costurile, stocurile

disponibile). Aceste variabile au sens numai în contextul unor anumite dimensiuni.

Măsurile reprezintă valorile centrale care sunt analizate prin cubul de date. Valoarea

Ţară

Regiune

Judeţ

Oraş

Nivele ierarhice

Detaliere

Agregare

Ierarhia locaţie

51

măsurii este calculată pentru un punct dat prin agregarea datelor corespondente perechii

respective valoare-dimensiune, diferite pentru punctul dat.

Măsurile pot fi clasificate după modalitatea de calcul în măsuri de bază care se

regăsesc sub forma atributelor din tabelele de fapte şi care provin din sursele de date şi

măsuri derivate (virtuale) care se obţin prin combinarea măsurilor de bază şi care în

tabelele de fapte au precizată formula de calcul prin care se obţin.

Măsurile pot fi organizate în trei categorii bazate pe tipurile de funcţii agregate

utilizate: distributive, algebrice, holistice.

Măsurile distributive – sunt calculate cu ajutorul unor funcţii de agregare

distributive. Presupunem că datele sunt împărţite în n seturi. Calcularea funcţiei pe fiecare

partiţie determină o valoare agregată. Dacă rezultatul obţinut prin aplicarea funcţiei asupra

a n valori agregate este acelaşi cu cel obţinut prin aplicarea funcţiei asupra tuturor datelor

fără partiţionare, funcţia poate fi calculată în manieră distributivă. De exemplu, funcţia

count( ) poate fi calculată pentru cubul de date printr-o primă partiţionare a cubului într-un

set de subcuburi, calculând count( ) pentru fiecare subcub şi apoi însumând rezultatele

obţinute pentru fiecare subcub. Din acest motiv funcţia count( ) este o funcţie agregată

distributivă.

Măsuri algebrice - sunt calculate cu ajutorul unor funcţii algebrice cu M argumente

(unde M este un întreg pozitiv), fiecare din ele obţinută prin aplicarea unei funcţii agregate

distributive. De exemplu, AVG( ) poate fi calculată prin sum()/count() unde ambele funcţii

sum( ) şi count( ) sunt funcţii agregate distributive. În mod similar se poate demonstra că

min( ), max( ) şi abaterea standard sunt funcţii algebrice agregate. Măsura este algebrică

dacă este obţinută prin aplicarea unei funcţii algebrice agregate.

Măsuri holistice - sunt calculate cu ajutorul unor funcţii holistice. O funcţie

agregată este holistică, dacă aceasta nu este limitată constant pe spaţiul de stocare cerut de

deschiderea subagregării. În acest caz nu există o funcţie algebrică având M argumente

(unde M este o constantă) care caracterizează calculul. Exemple comune de funcţii

holistice sunt: median( ), mode ( ), rank( ). O măsură holistică este obţinută prin aplicarea

unei funcţii agregate de tip holistic. Cele mai multe aplicaţii necesită calcularea eficientă a

măsurilor distributive şi algebrice. Există mai multe tehnici eficiente pentru aceasta, în

contrast, poate fi mai dificil de calculat în mod eficient măsuri holistice. Există totuşi

anumite tehnici eficiente de aproximare a calculului măsurilor holistice. De exemplu, în loc

de a calcula exact median( ), există tehnici care pot determina aproximativ valoarea

mediană pentru un set foarte mare de date, cu rezultate satisfăcătoare.

52

Din punctul de vedere al modalităţii de însumare şi agregare în funcţie de

dimensiuni, Ralph Kimball în lucrarea “The Data Warehouse Toolkit” [KIMB96] clasifică

metricile în trei categorii: indicatori aditivi care se pot însuma după toate dimensiunile,

indicatori semiaditivi care se pot însuma numai după unele dimensiuni şi indicatori

neaditivi care nu se pot însuma după nici o dimensiune dar care pot fi combinate cu alte

variabile pentru a deveni aditive.

Metadatele – reprezintă poate cea mai importantă componentă a depozitului de

date. Pentru a putea utiliza depozitul de date, utilizatorii trebuie să cunoască ce date se

găsesc aici, iar metadatele nu sunt altceva decât date despre date, date care descriu

conţinutul depozitului şi furnizează trimiteri directe la date. Tot la nivelul metadatelor se

definesc şi diverse vederi (views) asociate unor categorii specifice de utilizatori.

Dar metadatele nu sunt utile doar utilizatorului final. Ele sunt intens folosite pentru

administrarea depozitului de date, conţinând informaţii despre provenienţa datelor,

algoritmii de agregare şi însumare, statistici privind utilizarea şi multe altele.

Cand se utilizează într-un depozit de date, metadatele sunt date care definesc

obiectele depozitului. Metadatele sunt create pentru numele de date şi definiţiile din

depozit. Metadatele adiţionale sunt create pentru a asocia intervale de timp la datele extrase

şi alte câmpuri care vor fi adăugate prin curăţirea datelor sau prin procesele de integrare.

Nivelul metadatelor trebuie să conţină conform [JAJE98]:

• O descriere a structurii datelor din depozit, incluzând schema depozitului,

dimensiunile, ierarhiile, definiţiile datelor derivate;

• Metadatele operaţionale, care includ date privind evoluţia în timp (istoricul datelor

şi secvenţa de transformare aplicată asupra lor), situaţia datelor (active, arhivate sau

şterse) şi informaţii de monitorizare (statistici privind utilizarea depozitului de date,

rapoarte de erori, împrăştierea datelor etc.);

• Algoritmi utilizaţi pentru însumare, care includ măsura şi dimensiunea algoritmilor

definiţi, date despre granularitate, partiţii, arii de subiecte, agregări, sumarizări,

rapoarte şi filtre predefinite;

• Transformările datelor de la mediul operaţional la depozitul de date şi care includ

bazele de date sursă şi conţinutul lor, partiţionarea datelor, extragerea datelor,

curăţirea datelor, regulile de întreţinere şi securitate a datelor;

• Date relative la performanţele sistemului care includ indicatori şi profiluri care

îmbunătăţesc accesul la date şi performanţele de căutare;

53

• Metadate economice (business metadata), care includ termeni economici şi

definiţii, expresii şi formule de calcul ale indicatorilor.

Metadatele se aplică pentru sursele de date, pentru programele şi regulile de

extragere şi transformare, pentru structura datelor şi pentru conţinutul propriu-zis al

depozitului de date. Importanţa metadatelor pentru depozitul de date reiese din faptul că

acestea stabilesc contextul depozitului de date, uşurează procesul de analiză, menţin şi

cresc calitatea datelor dar şi din faptul că sunt o formă de auditare a transformării datelor.

Metadatele ajută administratorii şi utilizatorii depozitului să localizeze şi să

înţeleagă secvenţele de date atât în sistemele sursă cât şi în structura depozitului. Dacă

metadatele care descriu formatul datelor din depozite sunt disponibile, atunci se elimină

orice ambiguitate legată de semnificaţia datelor.

Metadatele menţin şi cresc calitatea datelor, fapt ce se realizează prin definirea

valorilor valide pentru fiecare câmp din depozit. Înainte de a fi efectiv încărcate în depozit,

datele pot fi revăzute şi erorile pot fi corectate, regulile de corecţie a erorilor pot fi

documentate tot prin metadate. Se pot deosebi mai multe tipuri de metadate:

Metadate administrative. Acestea conţin descrieri ale bazelor de date sursă şi ale

conţinutului, ale obiectelor depozitului de date şi ale regulilor folosite pentru a transforma

datele din sistemul sursă în depozit. Printre exemple de astfel de metadate menţionez:

descrirea tuturor sursele de date folosite, trecerea câmpurilor sursă în câmpuri destinaţie,

schema depozitului de date, structura datelor din back-end, programe şi instrumente back-

end, reguli şi formule de calcul, reguli de securitate şi de acces.

Metadate pentru utilizatorii finali. Aceste metadate au rolul de a ajuta pe utilizatori

să-şi creeze propriile lor interogări şi să interpreteze rezultatele. Pentru aceasta, ei au

nevoie să cunoască definiţiile datelor din depozit, descrierea lor, precum şi orice ierarhie

care poate exista în diferite dimensiuni. Exemple de astfel de metadate sunt următoarele:

conţinutul depozitului de date, rapoarte şi interogări predefinite, definiţiile ierarhiilor,

calitatea datelor, istoricul încărcării depozitului de date, reguli de eliminare.

Metadate pentru optimizare. Această categorie de metadate are rolul de a creşte

performanţele depozitului de date. Exemple de astfel de metadate sunt: definiţiile

agregărilor şi colecţii de statistici.

Un depozit de date conţine date pentru diferite perioade de timp şi de aceea este

important să avem în vedere efectul pe care îl poate avea timpul asupra regulilor de trecere

a câmpurilor sursă în câmpuri destinaţie, asupra agregărilor etc. Utilizatorii trebuie să aibă

acces la metadatele corecte pentru perioada de timp pe care o studiază. Echipa IT are

54

nevoie de aceste informaţii pentru a putea întreţine depozitul de date, iar ceea ce la prima

vedere ar părea să fie o eroare în transformarea datelor poate fi de fapt rezultatul

schimbării regulilor de transformare a datelor. De aceea este important ca metadatele să fie

corect gestionate din punct de vedere al versiunilor.

Deşi în mod tradiţional metadatele reprezintă o componentă dezvoltată spre

sfârşitul ciclului de dezvoltare, la ora actuală există o tendinţă puternică de a atribui

metadatelor un rol mai important. Utilizatorii instrumentelor de extragere şi transformare

pot specifica modul de trecere din câmpurile sursă în câmpurile destinaţie şi pot introduce

toate regulile care guverzează transformarea. Tabelul sursă-destinaţie poate servi ca bază

pentru generarea codului de program folosit apoi la extragerea şi transformarea efectivă a

datelor. Utilizatorii instrumentelor pentru calitatea datelor pot specifica valorile valide

pentru diferite secvenţe de date atât în sistemele sursă, cât şi în depozitul de date. Aceste

instrumente pot folosi metadatele ca bază de pornire în identificarea şi corectarea erorilor.

Utilizatorii specifică metadatele referitoare la schema depozitului de date (fapte,

dimensiuni etc), iar aplicaţile pot folosi aceste specificaţii ca intrare pentru a genera efectiv

schema (tabele, indecşi, agregări etc.).

Schema depozitului de date este o colecţie de obiecte, incluzând tabelele, viziunile,

indecşi şi sinonime. Există mai multe tipuri de scheme utilizate în modelarea

multidimensională acestea diferind de modurile în care se pot aranja obiectele în cadrul

schemei.

Schema de tip “Stea“ - Acesta este cel mai simplu şi mai frecvent utilizat model

(figura 3.4.a). Obiectele sale sunt dispuse în formă de stea, în centru aflându-se una sau

mai multe tabele de fapte de care sunt legate dimensiunile. O schemă de “joncţiune stea“

suportă două tipuri de interogări: consultare şi joncţiuni multiple. Operaţia de consultare se

realizează pe o singură tabelă de fapte şi nu necesită joncţiuni. O cerere de interogare tipică

apare atunci când un utilizator final solicită o listă derulantă. Interogările de tip joncţiune

multiplă apar după o serie de consultări şi implică restricţii plasate în câteva tabele

dimensiune care sunt puse în legatură simultan, prin operaţia de joncţiune, cu tabela de

fapte. Scopul este de a aduce sute şi mii de înregistrări de bază într-un set de răspunsuri de

dimensiune mică.

55

Figura 3.4. a: Schema de joncţiune stea

Dimensiunile în acest caz sunt denormalizate, ele având date redundante care

elimină necesitatea unor legaturi multiple între tabele. Într-o schemă stea nu exista decât o

singură legatură între tabela de fapte şi dimensiuni. Optimizarea performanţei de răspuns la

interogări este principalul avantaj al acestui model.

Schema de tip “Fulg de Nea” - este o variantă a modelului stea în care o parte din

tabelele dimensiune sunt normalizate, iar datele sunt distrinuite în tabele suplimentare

(figura 3.4. b). Rezultă o schemă reprezentată într-un grafic similar unui fulg de zăpadă.

Diferenţa între modelul stea şi modelul fulg de nea este că tabelele dimensiune din acesta

pot fi păstrate în forma normalizată, ceea ce determină o redundanţă redusă. Asemenea

tabele sunt uşor de întreţinut şi astfel se economiseşte spaţiu de stocare. Totuşi această

economie de spaţiu este neglijabilă în comparaţie cu volumul foarte mare de date din

tabelul de fapte. Mai mult, structura fulg de nea poate reduce performanţa extragerii de

date deoarece sunt necesare mai multe joncţiuni între tabele la o singură interogare.

Atribute ale dimensiunii TIMP

Dimensiunea TIMP

Atribute ale dimensiunii PRODUS

Dimensiunea PRODUS

Atribute ale dimensiunii LOCATIE

Dimensiunea LOCATIE

Atribute ale dimensiunii CLIENT

Dimensiunea CLIENT

ID TIMP ID LOCATIE ID PRODUS ID CLIENT Vol vânzarilor Vol discount

Tabela de fapte

56

Figura 3.4. b: Schema de joncţiune fulg de nea

Cuburi de date - Un mod mai simplu de vizualizare a datelor este reprezentarea

într-un spaţiu cartezian definit pe toate dimensiunile depozitului de date (figura 3.4.c,

3.4.d). Acesta poate fi numit cub de date, fiind un spaţiu de date logic şi nu unul fizic.

Secţiunile bidimensionale sunt numite tablouri. Axele cubului sunt reprezentate de

dimensiuni, la intersecţia acestora fiind variabilele sau măsurile.

In analiza multidimensională cubul de date cu mai mult de trei dimensiuni poartă

denumirea de cub n-dimensional sau hipercub (hypercub). Consiliul OLAP defineşte cubul

n-dimensional ca fiind ”un grup de celule de date aranjate după dimensiunile datelor. O

matrice tridimensională poate fi vizualizată ca un cub cu fiecare dimensiune formând o

faţă a cubului” [OLAP95]. Tot în aceeaşi definiţie se menţionează că dimensiunile tipice

ale datelor dintr-o întreprindere sunt timpul, măsurile, produsele, regiunile geografice,

canalele de distribuţie.

Atribute ale dimensiunii TIMP

Dimensiunea TIMP

Atribute ale dimensiunii PRODUS

Dimensiunea PRODUS

Atribute ale dimensiunii REGIUNE

Dimensiunea REGIUNE

Atribute ale dimensiunii CLIENT

Dimensiunea CLIENT

ID TIMP ID REGIUNE ID PRODUS ID CLIENT Vol vânzarilor Vol discount

Tabela de fapte

Atribute ale dimensiunii

TIP_PRODUS

Dimensiunea TIP_PRODUS

Atribute ale dimensiunii LOCATIE

Dimensiunea LOCATIE

57

Figura 3.4.c: Cub de date cu trei dimensiuni

Figura 3.4.d: Cub de date cu patru dimensiuni

3.5. OPERAŢII REALIZATE ASUPRA MODELULUI MULTIDIMENSIONAL

Aplicaţiile de analiză OLAP trebuie să asigure o utilizatorilor o viziune

multidimensională asupra datelor, indiferent dacă modalitatea de stocare este relaţională

sau multidimensională. Pentru utilizarea viziunilor multidimensionale nu este necesară o

stocare a datelor în aceasta formă. Bazele de date relaţionale şi cele multidimensionale

folosesc modele asemănătoare ceea ce permite o trasformare uşoară a datelor. Prin

aplicarea unor operaţii specifice asupra modelului multidimensional utilizatorului i se oferă

posibilitatea de a vedea şi de a analiza din perspective multiple datele, de a naviga în

locatie

prod

us

T1 T2 T3

furnizor F1 furnizor F2 furnizor F3

timp

PRODUS

TIMP

LOCATIE

58

cadrul ierarhiilor definite, de a extrage un subset de date, de a interschimba axele sau

dimensiunile pentru a obţine o altă detaliere a datelor. Toate aceste operaţii

multidimensionale impementate în cadrul modelului multidimensional sunt prezentate în

paragrafele următoare.

Navigarea pe nivelele ierarhice (Drill Down şi Roll Up) – reprezintă operaţii de

navigare în cadrul ierarhiilor dimensiunilor, prin agregare pe nivelele superioare sau

detaliere pe nivelele inferioare. Orice bază de date multidimensională trebuie să permită

navigarea pe diferite nivele ale ierarhiilor. Aceasta tehnică se numeste roll up sau drill

down, în funcţie de direcţie, spre vârful sau baza ierarhiei. Acestea sunt operaţii de

schimbare a vederii de-a lungul nivelelor unei ierarhii. Prin facilitatea de drill down,

utilizatorii pot naviga pe nivele cu un grad de detaliu mai accentuat. Prin roll up se pot

vizualiza datele la un nivel agregat. Cu toate ca instrumentele OLAP pot realiza dinamic

toate operaţiile necesare analizei, pentru a economisi timp şi resurse se preferă uneori pre-

calcularea unor valori globale în cadrul depozitului. Aceasta operaţie este numită

consolidare (când se referă la aspectul conceptual) sau însumare (din perspectiva

procedurală), fie agregare (din perspectiva structurală). Aceste agregări se referă la o

anumită măsură şi se realizează după dimensiunile corespunzatoare acesteia. Pentru

atributele organizate ierarhic, consolidarea se face nivel cu nivel. Aceste operaţii implică

de cele mai multe ori doar calcularea unor totaluri, dar există şi excepţii în care se

utilizează formule sau procedee statistice. Nivelul la care se face însumarea în cazul în care

sunt implicate ierarhii se numeste granularitate. Procesul de agregare creaza o redundanţă

în cadrul bazei de date, dar volumul acesteia nu este semnificativ deoarece scade

exponenţial cu fiecare nivel de însumare. Câştigul de performanţă obţinut la accesarea

datelor este deosebit de important în analiză.

Rotaţii – reprezintă operaţiile cele mai uzuale în structurile de date

multidimensionale şi oferă utilizatorului posibilitatea de a alege perspectiva asupra datelor

pe care o va utiliza. De exemplu în cazul bidimensional există două posibilităţi de

vizualizare, iar în cazul tridimensional se pot utiliza 6 rotaţii pentru a vizualiza datele din

diferite perspective, iar pentru patru dimensiuni există 24 de perspective posibile. Fiecare

rotaţie pune în evidenţă o nouă perspectivă, aducând în prim plan o structură

bidimensională, o faţetă (slice). Din acest motiv rotaţia se mai numeste şi “data slicing”.

Aceste operaţii nu implică o reorganizare a datelor stocate, ci o schimbare a modalităţii de

reprezentare, spre deosebire de cazul unor structuri relaţionale, pentru care o nouă faţetă

poate fi obţinută doar în urma unor interogări complexe.

59

Secţiuni - reprezintă viziuni sau imagini (views) specifice diverselor categorii de

utilizatori, prin operaţii de secţionare prin care se obţin "felii" bidimensionale (slices).

Astfel, un manager de produs poate avea la îndemână datele legate de produsul pe care-l

supervizează, pe toate zonele, pe toată perioada analizată. În schimb, un manager regional,

va fi interesat de toate produsele, dar numai pe toate zonele pe care le coordonează.

Tehnica aceasta constă în limitarea unor atribute la anumite valori şi obţinerea unui cub de

date redus (procedeu numit data dicing) (figura 3.5.).

Figura 3.5.a: Cub de date tridimensional. Dimensiunile reprezintă timpul, produsele şi

zonele de desfacere.

Figura 3.5.b: Viziunea managerului de produs: acesta poate obţine o viziune a

datelor ce reflectă doar vânzările anumitor produse în toată regiunea şi în toată perioada

de timp considerată.

Figura 3.5.c: Viziunea managerului financiar: poate restricţiona analiza la un anumit

trimestru pe toate produsele şi toate zonele.

PRODUS

TIMP

ZONA

PRODUS

TIMP

ZONA

PRODUS

TIMP

ZONA

60

Figura 3.5.d: Viziunea managerului regional: poate vedea vânzările întregii game de

produse în regiunea de care răspunde, pe toată perioada de timp considerată.

Figura 3.5.e: O viziune ad-hoc: diferite cerinţe pot duce la selectarea unor anumite valori

ale atributelor. Rezultatul constă în subseturi de date şi din acest motiv aceste operaţii se

mai numesc şi “data dicing”.

PRODUS

TIMP

ZONA

PRODUS

TIMP

ZONA

61

3.6. ANALIZA COMPARATIVĂ A PERFORMANŢELOR OBŢINUTE ÎN

URMA IMPLEMENTĂRII DIFERITELOR TIPURI DE DEPOZITE DE DATE

Problemele apărute în cazul realizării unor depozite de date la nivelul organizaţiei

sau chiar la niveluri departamentale sunt legate de performanţele în interogare, de accesul

la date, de administrarea metadatelor, de modalitatea de organizare şi stocare şi nu în

ultimul rând de dimensiunea depozitului şi de facilităţile de administrare.

In cele ce urmează voi realiza în tabelul 3.2 o comparaţie între caracteristicile

depozitelor de date organizaţionale pe de o parte şi data marturi organizaţionale pe de

altă parte din punct de vedere al realizării lor atât virtual cât şi separat, prin stocarea

datelor în formă agregată.

Depozit de date organizaţional Data Mart/ depozit specializat Criterii Virtual Date stocate

agregat Virtual Date stocate

agregat Dimensiunea depozitului

Zero, datele stocate la nivelul surselor de date.

Foarte mare (terra bytes), datele sunt antecalculate şi stocate agregat pe toate dimensiunile.

Zero, datele stocate la nivelul surselor de date.

Mare (maxim 1Tb), datele sunt antecalculate şi stocate agregat pe dimensiuni.

Dimensiunea surselor de date

Foarte mare, dimensiunea dicţionarelor de date este mare deoarece conţine informaţii despre structurile depozitului.

Nu sunt afectate sursele de date, dimensiunea acestora depide de sistemele tranzacţionale.

Mare, dimensiunea dicţionarelor de date este mare deoarece conţine informaţii despre structurile depozitului.

Nu sunt afectate sursele de date, dimensiunea acestora depide de sistemele tranzacţionale.

Obiectele depozitului

Sunt de fapt obiecte ale bazei de date relaţionale şi anume tabele virtuale asupra cărora se aplică anumite transformări.

Sunt obiecte multidimensionale construite distinct de cele relaţionale: dimensiuni, tabele de fapte, ierarhii, etc.

Sunt de fapt obiecte ale bazei de date relaţionale şi anume tabele virtuale asupra cărora se aplică anumite

Sunt obiecte multidimensionale construite distinct de cele relaţionale: dimensiuni, tabele de fapte, ierarhii, etc.

62

transformări. Administrarea metadatelor

Se realizează la nivel relaţional.

Se realizează la nivelul depozitului.

Se realizează la nivel relaţional.

Se realizează la nivelul data martului.

Performanţă la încărcarea datelor din surse

Foarte scăzută, nu este o încărcare propriu-zisă ci mai mult o interogare a date.

Moderată, volumul mare al datelor şi al structurilor îngreunează procesul de încărcare ce poate dura şi cîteva zile.

Scăzută, nu este o încărcare propriu-zisă ci mai mult o interogare a date.

Ridicată, volumul dateor fiind relativ mic procesul se derulează destul de rapid (max 24 ore).

Procesul ETL Este realizat preponderent la nivelul bazei de date relaţionale şi constă în prelucrarea datelor prin funcţii şi proceduri stocate. Procesul este realizat online, cu performanţe scăzute în momentul în care datelele sunt încărcate.

Se realizează la nivelul depozitului prin funcţii, proceduri şi operatori aplicaţi la nivelul acestuia. Este un proces foarte complex de transformare a datelor.

Este realizat la nivelul bazei de date relaţionale şi constă în prelucrarea datelor prin funcţii şi proceduri stocate. Procesul este realizat online, în momentul în care datelele sunt încărcate.

Se realizează la nivelul data martului prin funcţii, proceduri şi operatori aplicaţi la nivelul acestuia. Este un proces complex de transformare a datelor.

Nivelul de detaliere al datelor

Detaliat, datele sunt interogate direct din surse.

Detaliat şi agregat, datele precalculate sunt stocate.

Detaliat, datele sunt interogate direct din surse.

Detaliat şi agregat, datele precalculate sunt stocate.

Operatorii şi facilităţi de prelucrare analtică

De regulă sunt aplicaţi la nivelul interfeţelor sau aplicaţiilor client.

Sunt aplicaţi atât la nivelul depozitului cât şi la nivelul aplicaţiilor client.

Sunt aplicaţi la nivelul interfeţelor sau aplicaţiilor client.

Sunt aplicaţi atât la nivelul depozitului cât şi la nivelul aplicaţiilor client.

Modificarea structurilor de date

Se realizează foarte greu prin schimbări mari la

Se realizează relativ uşor, dar la proiectarea depozitului trebuie să se ţină

Se realizează destul de uşor prin modificări

Se realizează foarte uşor.

63

nivelul surselor de date şi ale tabelelor virtuale.

cont de aceste posibilităţi astfel încât să nu fie necesară reproiectarea întregului depozit.

aduse la nivelul tabelelor virtuale din baza de date relaţională.

Performanţa în analiză

Scăzută, toate operaţiile de agregate, ordonare, însumare se realizează online, acest lucru ducând uneori la timpi de aşteptare de cîteva ore.

Ridicată, operaţiile de agregate, ordonare, însumare se realizează la nivelul depozitului, datele stocate precalculat sunt doar aduse la nivelul aplicaţiei client. Volumul de date din depozit poate încetini operaţia de analiză.

Moderată, operaţiile de agregate, ordonare, însumare se realizează online, însă volumul datelor fiind mai mic decât la depozitele virtuale timpul de aşteptare se reduce la nivelul minutelor.

Foarte ridicată, operaţiile de agregate, ordonare, însumare se realizează la nivelul depozitului, datele stocate precalculat sunt doar aduse la nivelul aplicaţiei client.

Analiza datelor istorice

Analiza este redusă la datele existente în sursele relaţionale.

Datele sunt încărcate în depozit, deci există posibilitatea analizei lor de la momentul iniţial al construirii depozitului.

Analiza este redusă la datele existente în sursele relaţionale.

Datele sunt încărcate în data mart existând posibilitatea analizei lor de la momentul iniţial al construirii acestuia.

Posibilităţi de previziune

Aplicate la nivelul aplicaţiilor client, se realizează greu datorită volumului mare de date.

Se realizează şi la nivelul depozitului prin aplicarea unor operatori specifici şi la nivelul aplicaţiilor pe baza datelor din depozit.

Aplicate la nivelul aplicaţiilor client, se realizează relativ repede pe perioade de timp mici.

Sunt realizate atât la nivelul data martului prin aplicarea unor operatori specifici cât şi la nivelul aplicaţiilor pe baza datelor existente.

Independenţa aplicaţiilor faţă de date

Aplicaţiile sunt dependente de modul în care sunt realizate tabele virtuale.

Aplicaţiile au un grad de independenţă ridicat faţă de date, modificările în structura acestora ducând la schimbări relativ

Aplicaţiile sunt dependente de modul în care sunt realizate tabele virtuale.

Aplicaţiile au un grad de independenţă ridicat faţă de date, modificările în structura acestora ducând la schimbări mici la

64

Orice modificare la nivelul datelor va avea consecinţe foarte mari la nivelul aplicaţiilor.

mici la nivelul aplicaţiilor.

nivelul aplicaţiilor.

Realizarea depozitului

Durata de dezvoltare este medie, problemele apar la proiectarea porcesului ETL.

Durata de dezvoltare este mare, se proiectează obiectele depozitului, prcesul ETL, se aplică transformări asupra datelor.

Durata de dezvoltare este mică.

Durata de dezvoltare este medie.

Puncte critice din punct de vedere tehnic

Timpul mare de răspuns şi de interogare. Procesul ETL trebuie realizat la nivel relaţional. Volumul mare de date din sursele existente poate sufoca utilizarea depozitului.

Durata şi complexitatea ciclului de dezvoltare. Volumul mare de date din depozit poate duce la spaţii foarte mari de stocare şi la necesitatea unor servere puternice pentru procesare.

Procesul ETL trebuie realizat la nivel relaţional.

Foarte puţine, sunt mai mult legate de aspectele funcţionale.

Tabelul 3.2. – Analiza comparativă a tipurilor de depozite de date

Din analiza realizată se observă că în cazul unei organizaţii extinse, în care

volumul datelor este mare, este indicat să se dezvolte un depozit de date organizaţional, cu

datele agregate stocate, pregătite pentru analiză. In cazul în care se doreşte un data mart

realizat rapid, cu performanţe mari pe volume de date relativ reduse, fără spaţiu de

stocare separat, se poate aborda realizarea unui data mart virtual în care datele să fie

prelucrate, agregate şi prezentate spre analiză direct din sursele de date.

In anumite cazuri se pot combina aceste două variante de depozit stocat separat

pentru date provenite din perioade mai mari de timp, de exemplu pentru datele până în

urmă cu 3 luni şi chiar o lună, iar pentru datele curente să se realizeze separat, ţinând

65

totuşi cont de algoritmii şi fluxurile procesului ETL, un depozit virtual care să prelucreze

datele din ultima perioadă până în prezent.

Performanţa implementării uneia sau alteia dintre variante depinde însă şi de

capacităţile şi facilităţile oferite de sistemul de gestiune, dar şi de resursele hardware, din

acest motiv recomand ca la realizarea unei soluţii de depozite de date să se ţină cont şi de

aceste aspecte.

Exemplificare: In ultimul capitol al lucrării am propus o soluţie de sistem

informatic executiv în care am realizat un depozit de date centralizat în oracle Warehouse

Builder 10g pentru datele provenite din perioade de timp mai mari de 3 luni, iar pentru

datele provenite din perioade recente, inclusiv perioada curentă am realizat un depozit de

date virtual în Oracle Discoverer Administrator 10g. Modalitatea de realizare este descrisă

în capitolul 10 şi detalitată în Anexa 1 şi Anexa 2.

66

CAPITOLUL IV: SOLUŢII DE ANALIZĂ A DATELOR - TEHNOLOGIA

OLAP (ON-LINE ANALYTICAL PROCESSING)

Conceptul de On-line Analytical Processing a apărut începând cu anii 60-70 din

dorinţa de a modela prin funcţii analitice activităţile financiare. Primul limbaj

multidimensional, A Programming Language (APL) a fost dezvoltat de firma IBM şi

utilizat pe mainframe-uri încă din 1962, multe din conceptele acestuia fiind şi astăzi

implementate în unele limbaje, cum ar fi Adaytum Planning şi Lex 2000.

În 1993, E.F.Codd observă diferenţa de procesare dintre modelele relaţionale şi cele

multidimensionale şi introduce termenul de OLAP fundamentat pe 12 reguli, pe care

sistemele de analiză multidimensională ar trebui să le respecte. Într-un articol în revista

Computerworld, Codd menţionează faptul că: “oricât de puternice ar fi pentru utilizatori

sistemele relaţionale, acestea nu au fost proiectate pentru a asigura funcţii puternice de

sinteză, analiză şiconsolidare a datelor, funcţii cunoscute colectiv sub denumirea de analiză

multidimenionlă a datelor”.

În 1995 se înfiinţează Consiliul OLAP, un consorţiul al firmelor dezvoltatoare de

produse OLAP, cu rolul de a standariza aceste tehnologii prin stabilirea unor standarde

deschise (OLAP API). Consiliul OLAP a publicat următoarea definitie [OLAP95]:

“On-Line Analytical Processing este o tehnologie software ce permite analiştilor,

managerilor şi persoanelor cu funcţie de conducere să analizeze datele printr-un acces

rapid, consistent şi interactiv şi să le vizualizeze într-un mod cât mai variat. “

Tehnologia OLAP este caracterizată de o dinamică analiză multidimendională în

sprijinul utilizatorului final printr-o serie de activităţi:

• Aplicarea de formule şi modele asupra dimensiunilor şi ierarhiilor;

• Previziuni pe perioade diferite de timp;

• Analiza în adâncime (drill-down);

• Extragerea unui subset de date pentru vizualizare;

• Rotaţii în cadrul dimensiunilor;

Din punctul meu vedere, tehnologia OLAP reprezintă o modalitate de prelucrare şi

analiză dinamică şi avansată a datelor, oferind decidenţilor posibilitatea de a obţine

propria perspectivă asupra datelor, de creare flexibilă şi obţinere directă a situaţiilor

centralizate şi sintetice, dar şi cu posibilitatea de navigare în detaliu, cu facilităţi de

67

previzionare şi simulare a unor situaţii viitoare, fiind o soluţie eficientă de analiză a

datelor din depozitele de date.

Sistemele OLAP ajută utilizatorul să sintetizeze informaţiile organizaţiei printr-o

vizualizare comparativă şi personalizată ca şi printr-o analiză a datelor istorice folosind

scenarii de tipul “ce se întâmplă dacă?” (“what-if?”). Acestea se obţin cu ajutorul

serverului de OLAP special conceput pentru manipularea structurilor de date

multidimensionale. Arhitectura serverului şi structura datelor sunt optimizate pentru

regăsiri rapide, analize ad-hoc, calcule flexibile şi transformări ale datelor.

Spre deosebire de sistemul operaţional care funcţionează pe baza unor proceduri

prestabilite (există o gamă relativ limitată de tranzacţii operate de o organizaţie) un sistem

de analiză on-line (OLAP) oferă suport pentru o varietate de cerinţe care nu pot fi

prevăzute decât într-o mică măsură.

Sistemele OLAP ajută managerii în urma analizei datelor să-şi fundamenteze

deciziile astfel încât să-şi comercializeze mai bine produsele, să-şi planifice producţia într-

un mod mai eficient, să controleze costurile, să descopere evoluţiile viitoare ale unor

factori. OLAP poate fi utilizat în orice domeniu al afacerilor: analiza vanzârilor şi studii de

piaţă, evoluţii ale indicatorilor financiari ai întreprinderii, ca suport de decizii: previziuni

ale veniturilor şi cheltuielilor. Se poate studia volumul vânzărilor în funcţie de produse,

arii geografice şi timp, etc.

4.1. CERINŢELE FUNCŢIONALE ALE SISTEMELOR OLAP

Datorită particularităţilor cerinţelor de raportare ale managerilor, sistemele OLAP

trebuie să prezinte următoarele caracteristici:

• Analiza dinamică a datelor - Aceasta cere existenţa diferitelor instrumente de

analiză şi implică dimensiuni multiple concentrându-se asupra manipulării

modelelor de date ale întreprinderii. Analiza dinamică a datelor oferă o inţelegere

mai bună asupra schimbărilor intervenite în cadrul afacerilor întreprinderii şi pot fi

utilizate pentru identificarea soluţiilor, pentru planificarea tactică şi strategică la

nivelul întreprinderii.

• Acces rapid la date - Aplicaţiile OLAP necesită un volum mare de date care trebuie

să fie acesate foarte rapid, ceea ce presupune de obicei ca acestea să fie stocate în

structuri separate, optimizate care pot fi accesate fară să afecteze răspunsul din

sistem.

68

• Surse de date multiple - Majoritatea aplicaţiilor OLAP cer surse de date din sisteme

multiple, incluzând surse externe şi aplicaţii realizate în medii de programare

diferite. Procesul fuzionării acestor surse multiple poate fi foarte complex datorită

sistemelor de codificare diferite şi calităţii diferite a datelor.

• Sincronizarea surselor de date - Dacă datele dintr-o aplicaţie OLAP provin din mai

multe baze de date, este foarte probabil ca acestea să fie modificate la cicluri

diferite. Ca analiza să fie bazată pe date consistente, datele trebuie încărcate

împreună în depozitele de date.

• Analiza istorică - Majoritatea aplicaţiilor OLAP includ timpul ca o dimensiune, şi

multe rezultate utile sunt obţinute din analize de serii de timp. Dar pentru ca acest

lucru să fie util ar fi necesar ca datele să fie stocate într-un depozit sau data mart pe

o perioadă de cel puţin 2-3 ani. Aceasta presupune un efort de localizare a datelor

istorice şi în general, trebuie ajustate datorită modificărilor din organizaţie şi a

structurilor ierarhice.

• Grad de generalizare ridicat – Cerinţele de analiză ale managerilor impun ca

informaţiile să fie grupate, agregate şi reprezentate cât mai sintetic. Pentru a creşte

eficienţa şi a reduce timpul de răspuns, de obicei este util să stocăm datele

fuzionate şi ajustate la un nivel superior de agregare, dând însă posibilitatea

managerilor să poată vedea la cerere şi nivelele de detaliu.

În lucrarea [THOM02] Erik Thomsen structurează cerinţele funcţionale ale

sistemelor OLAP în două mari categorii şi anume cerinţe logice şi cerinţe fizice.

Cerinţele logice se referă la modalităţile de prelucrare a datelor din dimensiuni, la

structurarea datelor şi flexibilitatea sistemelor, astfel sunt identificate următoarele cerinţe:

• Structurare completă a dimensiunilor prin ierarhizare – se referă la capacitatea

unui sistem OLAP de a modela dimensiunile existente în mediul organizaţional pe

diferite niveluri în funcţie de anumite ierarhii, pornind de la nivelul cel mai detaliat

până la un nivel superior, generalizat şi abstarctizat.

• Realizarea eficientă a calculelor şi prelucrarilor – sistemul OLAP trebuie să

implementeze funcţionalităţi complexe de analiză, de comparare şi previzionare a

datelor, pe lângă abilităţile de agregare şi segmentare a acestora.

• Flexibilitate – modul de prezentare a datelor rezultate în urma prelucrărilor trebuie

să ţină cont de utilizator. Interfaţa poate fi grafică, tabelară, complexă in funcţie de

69

cerinţe. Flexibilitatea se referă şi la posibilităţile de modificare a modelului de către

utilizator fără a fi necesară re-proiectarea întregului sistem.

• Independenţa reprezentărilor faţă de structura modelului – referitor la această

cerinţă, un sistem OLAP trebuie să ofere posibilitatea modificării reprezentării fără

a afecta structura datelor.

Cerinţele fizice ale sistemelor OLAP sunt referitoare la accesul şi timpul de

răspuns al sistemului şi la suportul multiutilizator al acesuia:

• Acces rapid şi direct – principalul obiectiv al sistemelor OLAP este de a realiza

analize ad-hoc pe un volum mare de date. Accesul la aceste analize artrebui să se

realizeze direct de către utilizatorii finali, fără intervenţii suplimentare, într-un timp

cât mai scurt.

• Suport multiutilizator – datorită volumului de date şi a faptului că acestea sunt

centralizate şi prelucrate dintr-un depozit de date, iar asupra depozitului au acces

diverşi utilizatori, sistemul OLAP trebuie să permită accesul concurenţial şi

distribuit la prelucrările analitice.

O altă abordare a cerinţelor sistemelor OLAP este realizată chiar de părintele

conceptului, E.F. Codd în 1993 prin intermediul unui set de 12 reguli. Mai târziu, în 1995,

setul a fost extins la 18 reguli ce surprind caracteristicile sistemelor OLAP. Voi prezenta

mai jos acest set de reguli, după cum urmează:

A. Caracteristici de bază

Regula 1: O viziune conceptuală multidimensională

Viziunea conceptuală a modelelor OLAP trebuie să fie multidimensională bazată pe

viziunea sau modelul existent în organizaţie.

Regula 2: Manipularea intuitivă a datelor

Sistemele OLAP trebuie să permită operaţii intuitive şi flexibile de manipulare a

datelor, cum ar fi navigarea penivelurile ierarhiilor (operaţii de drill down, drill up, drill

across), analize pe secţiuni din date, etc.

Regula 3: Accesibilitate

Sistemele OLAP trebuie să ofere acces la o singură viziune logică a datelor din

organizaţie. Sursele de date, în modelul OLAP, trebuie să fie transparente utilizatorilor.

Regula 4: Surse de date variate

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) sau chiar sisteme

hibride (HOLAP).

70

Regula 5: Modele de analiză OLAP

Sistemele OLAP trebuie să suporte patru modele de analiză: explicativ, direct,

contemplativ şi formativ în sensul că un trebuie să permită cel puţin realizarea rapoartelor

parametrizate, analize de tip “ce se întâmplă dacă..?”, operaţii de tip drill-down/roll-up şi

slice/dice.

Regula 6: Arhitectura client/server

Orice sistem OLAP ar trebui să fie bazat pe o arhitectură client/server, oferind

accesul utilizatorilor prin intermediul unui client, iar prelucrarea multidimensională să fie

realizată de un server specializat.

Regula 7: Transparenţă

Accesul la sursele de date eterogene ar trebui să fie transparente pentru utilizatori,

iar analiza datelor să poată fi realizată şi prin intermediul diverselor instrumente client ca:

grafice, calcul tabelar, procesoare de text, etc.

Regula 8: Suport multiutilizator

Sistemele OLAP trebuie să asigure acces concurent şi distribuit la sursele de date,

fiind asigurate însă integritatea şi securitatea acestora.

B.Caracteristici speciale

Regula 9: Denormalizarea datelor

Prelucrarea datelor într-un mediu OLAP nu trebuie să afecteze sursele externe din

care provin acestea. Procesarea colecţiilor mari de date actualizate periodic, trebuie să fie

realizată prin intermediul unor legături persistente cu sursele externe de date, pentru a

asigura sincronizarea între acestea şi cubul de date. Deoarece sistemele OLAP sunt în

general separate de sistemele sursă, legăturile servesc ca funcţii de transformare ce

precizează modul de transformare a datelor din tabele sau foi de calcul tabelar în date

multidimensionale. Legăturile pot descrie relaţii structurale, atributele membrilor sau

conţinutul cuburilor şi pot fi unidirecţionale (de citire) sau bidirecţionale (citire/scriere).

Regula 10: Stocarea rezultatelor generate de sistemul OLAP

Datele supuse analizei trebui stocate şi prelucrate separat de sursele relaţionale sau

de fişierele din care provin datorită diferenţelor existente între modele şi a cerinţelor de

procesare.

Regula 11: Manipularea valorilor lipsă

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). Al treilea caz, unde termenul de împrăştiere a fost utilizat cu semnificaţia de

71

existenţă a multor valori zero, este un caz special al modului în care este stocat un număr

mare de valori care se repetă, în cazul de faţă valoarea zero. Insă valoarea zero este validă

ca orice alt număr. Confuzia a apărut deoarece în aplicaţiile OLAP apar 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.

[MUNT04]

Regula 12: Modul de tratare a valorilor lipsă

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

diferite moduri [MUNT04]

C. Modul de prezentare a datelor

Regula 13: Flexibilitatea rapoartelor

Modul de prezentare a datelor supuse analizei trebuie să fie accesibil utilizatorilor

astfel încât aceştia să poată aranja cu uşurinţă datele pe diverse dimensiuni pe axele

disponibile.

Regula 14: Performanţa raportării

Dimesiunea sau modul de organizare a datelor nu ar trebui să influenţeze

performanţa în raportare. Există însă doi factori importanţi care afectează performanţa

raportării şi anume: modul în care 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 dimensiunea bazei de date, numărul de dimensiuni sau complexitatea

raportului.

Regula 15: Ajustarea automată a nivelului fizic

Sistemele OLAP ar trebui să-şi modifice automat schema fizică a bazei de date în

funcţie de tipul modelului logic şi de volumul datelor.

D. Controlul dimensiunilor

Regula 16: Dimensionalitate generică

72

Dimensiunile proiectate trebuie să fie echivalente structural şi operaţional, adică 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

Codd recomandă utilizarea un număr maxim de 15-20 de dimensiuni. În practică

însă există o multitudine de alte cerinţe şi limitări ale instrumentelor OLAP, astfel încât

problema numărului maxim de dimensiuni poate deveni o cerinţă minoră, nesemnificativă.

Regula 18: Operaţii între dimensiuni nerestrictive

Sistemele OLAP ar trebui să permită relizarea de operaţii între diverse dimensiuni,

fară restricţii.

4.2. ARHITECTURA SISTEMELOR OLAP

Datorită caracteristicilor funcţionale şi a particularităţilor sistemelor existente în

cadrul fiecărei organizaţii se disting mai multe tipuri de arhitecturi ale sistemelor OLAP.

Acestea diferă în funcţie de modalitatea de stocare a datelor şi de tipul prelucrării

acestora, însă generalizând se pot identifica 3 niveluri ale arhitecturii: nivelul surselor de

date, al serverului OLAP şi al prezentării datelor sau interfaţa cu utilizatorul.

Figura următoare prezintă rolul serverului OLAP în extragerea datelor din diferite

surse şi prezentarea informaţiilor obţinute în diverse moduri pe cele trei niveluri

menţionate anterior.

73

Figura 4.1: Arhitectura Sistemelor OLAP

Multe confuzii există în legătură cu arhitecturile OLAP şi termeni ca ROLAP,

HOLAP, DOLAP. De fapt există mai multe opţiuni în care datele OLAP ar putea fi stocate

şi unde ar putea fi procesate. Sunt mai multe variante rezultate în urma combinaţiilor între

modalităţile de stocare şi cele de prelucrare a datelor din sistem.

In funcţie de modalitatea de organizare şi stocare a datelor pot exista trei opţiuni:

• Fişiere client - în acest caz, extragerile de date relativ mici sunt stocate local pe

calculatorul client sub formă de fişiere (de exemplu foi de calcul) care pot fi

utilizate direct, prelucrate şi transformate pentru analiză. În acest caz există o serie

de limitări cum ar fi: voumul redus de date care poate fi prelucrat, timpul relative

mare de procesare a informaţiilor, securitate redusă, prelucrări rudimentare datorate

inexistenţei unor funcţii puternice de analiză multidimensională.

• Baze de date relaţionale – această variantă se recomandă în cazul în care datele

provin dintr-un SGBD relaţional iar depozitul de date a fost implementat utilizând

un model relaţional sau este implementat ca deposit de date virtual. În acest caz,

datele ar fi stocate într-o structură denormalizată cum ar fi o schemă stea sau una

din variantele sale: o bază de date normalizată nu ar fi potrivită pentru performanţe.

Grafice

Data Warehouse

Aplicatii WEB Rapoarte

Nivelul Surselor de date

Nivelul Interfetei cu utilizatorul

Server OLAP

Surse externe Depozitul de date Baze de date

Nivelul Serverului

OLAP

74

• Baze de date multidimensionale - în acest caz datele sunt stocate într-un depozit de

date pe un server dedicate, denumit server multidimensional. In acest caz putem

vorbi de un deposit de date format din obiecte multidimensionale asupra cărora pot

fi aplicate direct operaţiile multidimensionale. Sarcina realizării acestor operaţii

cade în seama serverului multidimensional. Datele sunt extrase din surse diverse

(baze de date relaţionale, fişiere), transformate şi încărcate în tabelele de fapte şi

dimensiuni, aggregate pe diverse nivele, preprocesate şi pregătite pentru analiză.

Este varianta optimă datorită avantajelor oferite: capacitatea de procesare a unui

volum mare de date, existenţa procesului ETL pentru transformarea şi încărcarea

datelor, implementarea operaţiilor la nivel de server multidimensional optimizat

pentru analiză.

Aşa cum există trei modalităţi de stocare pentru datele OLAP, tot trei opţiuni sunt

şi pentru procesarea datelor. Aşa cum se va observa, operaţiile multidimensionale nu

trebuie neapărat să aibă loc unde sunt stocate datele din acest motiv există următoarele

variante:

• Nucleul SQL - Aceasta este departe de a fi o optiune optimă pentru a efectua

calcule multidimensionale complexe, chiar dacă datele OLAP sunt stocate într-o

bază de date relaţională. Limbajul SQL nu are implementate facilităţile de a efectua

direct calcule multidimensionale şi sunt necesari mai multi paşi pentru a obţine

aceleaşi rezultate cu cele obţinute prin aplicarea funcţiilor şi operaţiilor

multidimensionale.

• Motorul client multidimensional - Presupunând că majoritatea utilizatorilor au

sisteme relativ puternice, se pot efectua local unele operaţii multidimensionale, de

exemplu pivotarea sau filtrarea în cadrul foilor de calcul. Însă această variantă

presupune cunoştinţe avansate în domeniu şi lasă practic sarcina construirii şi

aplicării funcţiilor de analiză pe seama utilizatorului final.

• Motorul server multidimensional - Aceasta este alegerea optimă pentru efectuarea

operaţiilor multidimensionale într-o aplicaţie OLAP client/server. Execuţia

operaţiilor multidimensionale de către serverul dedicat degrevează sistemul client şi

utilizatorul final de sarcina construirii acestora, asigură accesul concurent la

aceleaşi resurse, iar procesarea cererilor de analiză se realizează în timp real şi

informaţiile sunt disponibile pentru vizualizare prin intermediul unor interfeţe

standardizate şi prietenoase pentru utilizatorii finali.

75

In funcţie de opţiune de stocare şi procesare a datelor teoretic sunt posibile nouă

arhitecturi de bază, din care doar şase au sens. Aceste combinaţii precum şi câteva dintre

produsele software care le utilizează sunt prezentate în tabelul de mai jos [HUHA99]:

OPŢIUNI DE STOCARE A DATELOR

OPŢIUNI DE PROCESARE

Fişiere SGBDR Baza de date

multidimensionale

Nucleul SQL 1

2 Cartesis Magnitude MicroStrategy

3

Motorul client Multidimensional

4 Brio.Enterprise BusinessObjects Cognos PowerPlay Oracle Personal Express iTM1 Perspectives Microsoft Excel

5 Oracle Discoverer Informix MetaCube

6 Comshare FDC Dimensional Insight Hyperion Enterprise Hyperion Pillar PwC CLIME

Motorul server Multidimensional

7

8 Crystal Holos (ROLAP mode) IBM DB2 OLAP Server CA EUREKA:Strategy Longview Khalix Informix MetaCube Speedware Media/MR Microsoft Analysis Services Pilot Analysis Server Sagent Applix iTM1 WhiteLight Oracle Express (ROLAP mode) Oracle Warehouse Builder Oracle Discoverer

9 SAS CFO Vision Crystal Holos Comshare Decision Hyperion Essbase Gentia Speedware Media/M Microsoft Analysis Services PowerPlay Enterprise Server Pilot Analysis Server Applix iTM1 Oracle Express Oracle Warehouse Builder Oracle Discoverer

Tabel 2.3: Variante de implementare ale sistemelor OLAP

Arhitecturile cele mai utilizate dintre aceste tipuri de combinaţii sunt următoarele:

• OLAP relaţional (ROLAP) (2, 5, 8) din care OLAP hibrid (Hybrid OLAP sau

HOLAP) (5, 8)

• OLAP multidimensional (MOLAP) (6, 9) din care OLAP client (Desktop OLAP sau

DOLAP) (6)

• OLAP client (DOLAP) (4)

76

4.3. MODELE DE DATE MULTIDIMENSIONALE UTILIZATE ÎN

SISTEMELE OLAP

Modelele de date utilizate în sistemele OLAP au cunoscut o diversitate destul de

mare atât din punctul de vedere al teoretizării conceptelor cât mai ales din punctul de

vedere al aplicării diferitelor tipuri de modele în practică. Două direcţii importante au

clasificat totuşi această diversitate de modele şi anume dezvoltarea unor extensii ale

modelului relaţional şi utilizarea acestora în cadrul sistemelor OLAP şi a doua direcţie –

dezvoltarea modelelor bazate pe cuburi n-dimensionale.

Printre extensiile modelului relaţional se pot menţiona: modelul propus de Gray la

baza căruia sunt operatorii CUBE şi ROLLUP din clauza GROUP BY din limbajul SQL

care presupune agregarea datelor pe atributele clauzei group by; modelul propus de Li şi

Wang sau modelul lui Gyssens şi Lakshmanan care sunt extensii ale algebrei relaţionale

[MUNT04]. Insă cel mai important model şi cel mai reprezentativ este cel propus de Ralph

Kimball în lucrarea [KIMB96] care defineşte schema tip stea ca o reprezentare relaţională

a cubului n-dimensional. Schema tip stea prezentată anterior şi în cadrul acestui capitol

cuprinde în viziunea lui Kimball o tabelă centrală şi mai multe tabele dimensiune legate

radial de tabela de fapte prin joncţiuni asemănător cu modelul ER. Din modelul de tip stea

a derivat mai târziu şi modelul tip fulg de nea care extinde facilităţile oferite de modelul

anterior. Ulterior au apărut noţiuni ca schemă galaxie care este o schemă stea cu mai multe

tabele de fapte sau schemă constelaţie (fact constellation scheme) în care 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 [MUNT04].

Printre modelele bazate pe cub se poate aminti modelul lui Agrawal, Gupta şi

Sarawagi care are la bază un set minimal de operatori asemănători cu cei din algebra

relaţională, însă organizarea datelor se bazează pe unul sau mai multe cuburi n-

dimensionale. In viziunea lui Agrawal [MUNT04] cubul are următoarele componente:

dimensiunile definite prin nume şi domeniu de valori şi elementele cubului care sunt

definite printr-o funcţie ce asociază mulţimea valorilor dimensiunilor la un n-tuplu

reprezentat de celulele cubului.

Tot în categoria modelelor bazate pe cub se situează şi modelul propus de Cabibbo

şi Torlone [MUNT04] în care dimensiunile sunt categorii lingvistice ce descriu diferite

moduri de prezentare şi de analiză a informaţiilor, iar fiecare edimensiune este organizată

77

pe ierarhii. Modelul are la bază o schemă multidimensională formată din setul de

dimensiuni, tabelele de fapte (f-table) şi descrierile nevelurilor ierarhice.

Modelul propus de Blaschka [MUNT04] introduce o extensie a tehnicii de

modelare entitate – asociere a modelului relaţional. Tehnica ME/R pentru proiectarea

schemei multidimensionale conţine o entitate denumită nivel al dimensiunii (dimension

level), o relaţie tip 1:n denumită fact relationship şi o relaţie binară denumită relaţie de

clasificare a două niveluri ierarhice.

Din punct de vedere al nivelului de realizare modelele multidimensionale utilizate

în cadrul sistemelor OLAP sunt împărţite pe cele trei niveluri: conceptual, logic şi fizic

[MUNT04]:

• modele conceptuale oferă concepte apropiate de modul în care utilizatorii percep

datele şi sunt independente de implementare. La acest nivel se pot considera ca

modele conceptuale modelul lui Cabibbo şi cel propus de Blaschka.

• modele logice oferă concepte ce pot fi înţelese de utilizatorii finali dar depind de

tipul de SGBD utilizat. Dintre modelele multidimensionale la nivel logic se pot

considera modelul lui Kimball, cel propus de Li şi Wang şi cel al lui Agrawal.

• modele fizice oferă concepte legate de modul în care sunt stocate fizic datele

(descrierea datelor pe suport fizic), depinzând de SGBD-ul utilizat.

Tipul de model multidimensional utilizat de diverse tehnologii şi produse software

ce implementează sistemele OLAP diferă atât din punct de vedere al SGBD-ului utilizat

cât şi din punct de vedere al operaţiilor realizate asupra datelor şi a arhitecturii

implementate (MOLAP, ROLAP, HOLAP).

In ceea ce priveşte modelul de date utilizat în cadrul sistemelor informatice

executive acesta este asemănător cu modelul constelaţie derivat din modelul stea propus

de R. Kimball. Insă pentru a putea modela cât mai corect cerinţele de afaceri impuse

acestui tip de sistem consider că ar trebui utilizat un model piramidal structurat pe trei

niveluri distincte, astfel:

Nivelul I sau nivelul organizaţional – compus din dimensiuni şi fapte cu caracter

general, valabile pentru activităţile întregii organizaţii, de exemplu dimensiunea <timp>,

<zonă geografică>. Nivelul datelor este detaliat, cu mai multe ierarhii pe fiecare

dimensiune.

Nivelul II sau nivelul departamental – compus din dimensiuni şi fapte cu caracter

departamental, valabile pentru anumite activităţi, de regulă grupate pe departamente sau

centre, ar fi un nivel al data marturilor, de exemplu aici s-ar regăsi dimensiunea <cont

78

contabil> sau <client>/<furnizor>. Nivelul datelor este semi-agregat, cu ierarhii

specializate pe care să se poată naviga.

Nivelul III sau nivelul strategic – compus din dimensiuni şi fapte derivate din cele

de bază şi din cele departamentale, având şi elemente proprii, valabile doar pentru analiza

strategică, de exemplu dimensiunea <intercompanie>. Nivelul datelor este agregat, sintetic,

ierarhiile fiind compuse şi derivate din cele de bază şi cele departamentale.

Caracteristica principală a modelului propus este aceea că între tabelele de fapte şi

dimensiunile de pe diferite niveluri ale arhitecturii se pot stabili legături şi în plus tabelele

de fapte pot avea ierarhii sau clase de atribute astfel încât sa se poată naviga pe acestea.

Avantajele modelului:

Flexibilitate – Se pot introduce foarte uşor elemente noi pe oricare dintre niveluri

fără a afecta arhitectura axistentă, iar reîmprospătarea datelor la un anumit nivel nu

influenţează nivelurile adiacente;

Model real al cerinţelor de afaceri – modelul permite evidenţierea caracteristicilor

şi cerinţelor de afaceri existente pe nivelele superioare ale arhitecturii;

Performanţă în navigare (drill-down, roll-up) – fiind separate dimensiunile pe

fiecare nivel se poate uşor naviga pe ierarhiile acestora de sus în jos şi invers;

Construcţie incrementală – modelul poate fi realizat în trepte, validând pe rând

fiecare nivel şi având în permanenţă o evaluare a sistemului;

Suport pentru MIS, DSS – fiind construit pe trei niveluri modelul oferă suport şi

pentru realizarea unor sisteme de tipul MIS şi DSS care să utilizeze datele de pe nivelurile

organizaţionale şi departamentale.

Dezavantajele modelului:

Complexitate mare – fiind modelat pe trei niveluri diferite sistemul necesită o

atenţie deosebită şi experienţă în alegerea dimensiunilor, a faptelor şi a ierarhiilor la fiecare

nivel, alegerea greşită a acestora poate avea efecte majore asupra performanţelor şi a

modelului;

Performanţă scazută la interogare – fiind necesare joncţiuni multiple între

dimensiuni şi fapte performanţa la interogare scade considerabil şi sunt necesare optimizări

ale acestor joncţiuni;

Necesitatea de abordare pe două direcţii top-down şi bottom-up – pentru a modela

corespunzător cerinţele de afaceri consider necesară abordarea modelului atât în maniera

top-bottom cât şi bottom-up pentru validare.

79

In ultimul capitol al acestei lucrări voi exemplifica acest model de date pe o soluţie

de sistem informatic executiv.

4.4. LOCUL TEHNOLOGIEI OLAP ÎN ARHITECTURA DEPOZITULUI DE

DATE

In cartea “Building the Data Warehouse”, W.H. Inmon menţionează: “Sunt patru

niveluri în cadrul mediului arhitectural: operaţional, atomic sau al depozitului de date,

departamental şi individual” [INMO96].

Nivelul operaţional - Sistemele operaţionale sunt reprezentate de sursele, datele

care populează depozitul de date. Datele operaţionale sunt supuse tranzacţiilor, volatile,

stocate la nivel de tranzacţie în formă normalizată sau proprie în sistem OLTP.

Nivelul depozitului de date - Acest nivel conţine date cu caracter istoric ale

nivelului tranzacţional, prelucrate şi transformate într-un format multidimensional mult

mai potrivit pentru suportul de decizii. O singură tabelă de fapte poate avea o înregistrare

pentru fiecare tranzacţie şi fiecare înregistrare va conţine valorile sau măsurile şi alte

câmpuri descriptive ce vor reprezenta cât mai fidel întregul potenţial al dimensiunilor

caracterizănd afacerile (timp, zone, clienţi, produs) tinzând către un conţinut complet al

ariei subiectelor (date despre vânzărea produselor, date despre cost, tipuri de venituri,

tipuri de cheltuieli). Însă cu un volum foarte mare de date este imposibil să se furnizeze un

timp de răspuns rapid la cererile managerilor. De aceea este nevoie de nivelul

departamental.

Nivelul departamental, data mart sau OLAP - În aceeasi carte, W.H.Inmon scrie:

“Nivelul departamental este uneori denumit ‘nivelul data mart’, ‘OLAP’, ‘bază de date

multidimensională’”. Tehnologia OLAP ar trebui folosita la acest nivel în arhitectura. Un

data mart OLAP va fi limitat la submulţimea mărimilor statistice disponibile şi

dimensiunilor necesare pentru a studia problemele specifice afacerilor. Într-un mediu

inteligent, bine proiectat al afacerilor, 80% sau mai mult din totalul de cereri sunt transmise

data mart-ului şi server-ului OLAP. Când datele ajung în depozit, ele trebuie să fie

pregătite pentru a fi redistribuite imediat în data mart. Structura dimensională trebuie să fie

deja definită şi reprezentată în depozit prin schema stea a bazei de date relaţionale. Ar

trebui să existe un depozit central care cataloghează conţinutul şi statutul depozitului.

Serverul OLAP ar trebui să poată citi direct din tabelele depozitului, atât datele cât şi

metadatele necesare pentru restructurarea şi actualizarea data mart-ului cu submulţimea

cerută de măsuri, dimensiuni, înregistrări.

80

Mai mult, arhitectura trebuie să fie cuprinzătoare şi flexibilă suficient pentru ca

noile date mart-uri să poată fi create rapid şi cele existente să fie redefinite rapid, simplu,

prin selectarea noilor combinaţii de măsuri şi dimensiuni din cele deja existente în

depozitul metadatelor ca răspuns la cererea nouă sau redefinită. Când bazele de date ale

sistemului OLAP sunt incomplete (acest lucru se întamplă des), proiectanţii încearcă să

anticipeze toate cererile posibile pentru toate domeniile posibile (subiecte) şi apoi încearcă

să reunească conţinuturile întregului depozit într-unul singur numindu-se OLAP ‘data

waremart’. Depozitul de date este un proces continuu de dezvoltare iterativ, ceea ce trebuie

să conducă la posibilitatea de a adapta modelele data mart la necesitătile afacerilor. În orice

caz, pentru o mai mare flexibilitate se recomandă ca arhitectura să includă atât nivelul

depozitului de date cât şi data mart.

Nivelul individual - La ultimul nivel al arhitecturii, datele sunt prezentate

managerilor pentru interpretare. Instrumentele de vizualizare a cererilor, precum grafice,

prezentări, rapoarte dinamice, browserele Web, toate aparţin acestui nivel. Aplicaţiile

clienţilor, care conţin informaţii despre bugete, prognoze, recomandări cu privire la

alocarea resurselor şi multe altele se află în data mart la acest nivel al arhitecturii.

Din punctul de vedere al modalităţilor de realizare a sistemelor informatice

executive, consider că locul tehnologiei OLAP în cadrul depozitelor de date ale

organizaţiei este esenţial, acesta acoperind practic cele două nivele superioare identificate

de W.H. Inmon. Analiza datelor din depozite fără tehnologia OLAP este ar fi extrem de

grea, implicând metode şi modele statistice şi matematice laborioase, funcţii de analiză

dezvoltate de programatori, interfeţe speciale, dezvoltate separate de restul sistemului.

OLAP oferă posibilitatea realizării rapide a sistemelor executive, prin integrarea

facilităţilor de analiză dinamică, multidimensională, a previziunilor şi scenariilor “ce se

întâmplă dacă”, a simulărilor, schimbări de perspectivă, navigare în adâncime şi mai ales

realizarea uşoară a interfeţelor specializate, caracteristice EIS.

Exemplificare: în capitolul 10 pentru soluţia de sistem informatic executiv propusă

am integrat în cadrul sistemului realizat funcţionalităţile OLAP de navigare pe nivele

ierarhice, rotaţii, schimbări de perspectivă şi previziune. Modelul de date multidimensional

pyramidal propus anterior a fost modelat cu ajutorul unui set de stereotipuri UML propuse

în capitolul 8 şi implementat în cadrul depozitului de date cu Oracle Warehouse Builder

10g. Paşii necesari realizării funcţionalităţilor OLAP sunt descrişi în detaliu în Anexa 3.

81

CAPITOLUL V. SOLUŢII DE EXTRAGERE A CUNOŞTINŢELOR DIN

DATE - DATA MINING

Metodele statistice clasice sunt restrictive în ceea ce priveşte posibilitatea de

prelucrarea a datelor, necesitând formularea iniţială de ipoteze, elaborarea de ecuaţii,

necesită un anumit volum de cunostinţe şi experienţă din partea specialiştilor, o

cunoaştere prealabilă a distribuţiei probabilităţilor iar datele trebuie să aibă o calitate

ridicată, fiind supuse în prealabil unor prelucrări şi transformări.

Datorită acestor dezavantaje în anii '80 a apărut conceptul de data mining

desemnând iniţial numai procesul de aplicare a unor algoritmi de extragere a cunoştinţelor

din colectii de date de dimensiuni mari. Primul program larg răspândit de data mininig a

fost “Clementine” al companiei SPSS şi a apărut în anul 1994. Un alt moment important

pentru data mining a fost elaborarea metodologiei de proiectare CRISP-DM (CRoss

Industry Standard Process for Data Mining) în 1996, din fonduri alocate de Comisia

Europeană.

Ulterior, procesul de data mining a fost interpretat în mod mai larg, drept întregul

proces de extragere a cunoştinţelor din bazele de date, pornind de la fixarea unor cerinţe

informaţionale pâna la validarea informaţiilor descoperite. Această din urmă accepţiune a

conceptului de data mining s-a impus tot mai mult în ultimul timp.

Datorită volumelor foarte mari de informaţii în format electronic de tip text a apărut

şi necesitatea extragerii automate de cunoştinte din text şi în acest mod data miningul a

cunoscut o noua specializare - text miningul, iar mai târziu dezvoltându-se şi conceptul de

webmining, referitor la extragerea de cunoştinţe din resurse web.

In lucrarea [BODE98] se regăseşte următoarea definiţie: prin data mining se

întelege procesul de extragere a cunoştinţelor din bazele sau depozitele de date,

cunoştinţe necunoscute anterior, valide şi în acelasi timp operaţionale.

Prin data mining nu se urmareşte verificarea sau confirmarea/infirmarea de ipoteze,

ci se intenţionează descoperirea unor cunoştinţe noi, neintuitive, care pot contrazice

percepţia intuitivă, fiind deci informaţii complet necunoscute la momentul realizării

procesului de data mining. Din acest motiv rezultatele obţinute sunt cu adevărat valoroase.

Cunoştinţele descoperite prin data mining trebuie să fie valide. Prin aplicarea

tehnicilor de data mining asupra unor volume mari de date extrem de variate pot apărea şi

82

informaţii false. Verificarea validităţii rezultatelor unui proces de data mining este

esenţială.

Informaţiile obtinuţe prin data mining trebuie să fie operaţionale, în sensul că pe

baza lor să se poată întreprinde acţiuni care să ofere organizaţiei o serie de avantaje

economice. În multe cazuri, rezultatele unui proces de data mining nu sunt atât de simplu

de aplicat. Prelucrând prin tehnici de data mining date istorice, rezultatele obtinute pot

evidenţia oportunităţi care nu mai sunt actuale. Identificarea unor informaţii utile prezente

sau viitoare poate reclama prelucrarea unor date care nu sunt încă disponibile. Indiferent de

dificultatea aplicării rezultatelor obţinute, importanţa proceselor de data mining este legată

de abilitatea utilizării rezultatelor în cadrul proceselor decizionale critice.

Procesul de data mining este deseori utilizat împreună cu tehnici tradiţionale de

interogare sau de analiză a datelor. Din aceasta cauză, data mining-ul este asociat frecvent

cu: interogări SQL, regăsiri de date, cu ajutorul unor instrumente avansate precum agenţii

inteligenţi, analize în sisteme de baze de date multidimensionale cu ajutorul sistemelor

OLAP, rapoarte şi grafice de prezentare a datelor, prelucrari statistice tradiţionale ale

datelor.

Insă aceste tehnici menţionate anterior nu permit descoperirea de cunoştinţe fară

formularea prealabilă de ipoteze. Dacă cele mai multe tehnici de analiză statistică a

datelor sau de vizualizare a acestora urmăresc verificarea unor ipoteze, tehnicile de data

mining urmăresc obţinerea de răspunsuri la întrebări de genul: “Care sunt cauzele unui

anumit fenomen?”, “Cum se pot obţine anumite rezultate?”. Figura următoare prezintă

diferenţele existente între cele două abordări:

83

Figura. 5.1. Diferenţe între analiza clasică a datelor şi procesul de data mining

Dintre metodele tradiţionale de analiză a datelor, cele mai apropiate de data mining

sunt metodele statistice. Acestea sunt utilizate pentru descoperirea corelaţiilor, asociaţiilor

între date şi pentru construirea de modele predictive. Este ceea ce se realizeaza şi prin data

mining. Se poate afirma că ceea ce se realizează prin data mining s-ar putea realiza şi cu

ajutorul metodelor statistice. Ceea ce este o caracteristică a procesului de data mining este

relativa uşurinţă cu care se obţin rezultatele, în comparaţie cu dificultatea de aplicare a

metodelor statistice. Metodele statistice reclamă formularea de ipoteze şi construirea unor

ecuaţii care să fie în concordanţă cu aceste ipoteze. Nu trebuie însă să se treacă cu vederea

faptul că obţinerea rezultatelor nu este urmată imediat de aplicarea acestora şi obţinerea de

avantaje economice. Cunoştinţele obţinute prin aplicarea metodelor de data mining trebuie

interpretate şi validate, ceea ce reprezintă o activitate care poate fi extrem de dificilă.

Deşi se bazează pe tehnologii informatice distincte, procesele de data mining şi cele

de proiectare şi implementare a bazelor de date sunt într-o strânsă interdependenţă. Ca

orice proces bazat pe date, data mining este puternic dependent de calitatea datelor asupra

Baza de date Depozit de

date

Rapoarte şi grafice prin interogări SQL

Analiză multidimensională

Analiza statistică a datelor

Data Mining

Descoperirea de cunoştinţe noi

Dar dacă?

De ce? Cum?

84

cărora se aplică metodele şi tehnicile de extragere a cunoştinţelor. Din această cauză,

tehnologiile care asigură o calitate ridicată a acestor date sunt esenţiale pentru procesul de

data mining [HAKA01].

Chiar dacă se bazează pe date, stocarea acestora într-o bază de date nu reprezintă o

condiţie obligatorie pentru realizarea proceselor de extragere a cunoştinţelor din date.

Multe dintre procesele de data mining se pot aplica şi asupra fişierelor şi nu asupra bazelor

de date. Aceste fişiere sunt create special pentru procesul de data mining, prin extragerea

de date din bazele de date operaţionale.

De cele mai multe ori este preferată soluţia prin care se construieşte un depozit de

date sau mai multe data marts la nivelul organizaţiei şi asupra acestora să se aplice

procesul de data mining. Însă asupra datelor este necesar să se aplice procesul ETL

(extragere, transformare şi încărcare) pentru curăţarea şi îmbunătăţirea calităţii datelor

utilizate în procesul de extragere a cunoştinţelor.

Implementarea unui depozit de date ce urmează sa fie valorificat şi prin metode şi

tehnici de data mining constituie o soluţie deosebit de utilă pentru asistarea deciziilor

economice, soluţie care contribuie la asigurarea mediului inteligent al afacerilor (business

intelligence).

5.1. ETAPELE PROCESULUI DE EXTRAGERE A CUNOŞTINŢELOR DIN

DATE

În general, când se vorbeste despre procesul de extragere a cunoştinţelor din date se

are în vedere numai etapa de aplicare a diferitelor metode şi tehnici de data mining, fară a

se acorda nici o atenţie altor etape necesare realizării procesului. In lucrarea [ULLM00]

sunt precizate însă următoarele etapre necesare realizării întregului proces (figura 5.2.):

• Colectarea datelor din surse multiple: web, text, baze de date, depozite de date (A);

• Curăţarea datelor realizată prin eliminarea erorilor, a datelor incorecte. Dacă se

utilizează un depozit de date, acest proces este eliminat deoarece asupra datelor a

fost aplicat un proces de ETL (B);

• Stabilirea atributelor reprezentative a datelor care vor participa la procesul de data

mining prin selectarea acelor proprietăţi care interesează domeniul de analiză (C);

• Aplicarea şabloanelor şi descoperirea/analiza noilor cunoştinţe (D);

• Vizualizarea, validarea şi evaluarea rezultatelor obţinute (E).

85

Figura 5.2: - Etapele procesului de extragere a cunostinţelor din date

Întregul proces de extragere a cunoştinţelor din date este dirijat de un scop

(obiectiv) legat de problemele întâmpinate în cadrul domeniului economic, probleme ce

reclamă identificarea unor cunoştinţe care să permită soluţionarea lor.

Scopul formulat la iniţierea procesului de extragere a cunoştinţelor ajută la

determinarea datelor relevante, întrucât ecesta nu se aplică niciodată asupra întregului fond

de date al organizaţiei economice. Tot acest obiectiv determină şi modul de interpretare şi

vadidare a rezultatelor.

Procesul de extragere a cunoştinţelor este iterativ întrucât, pe parcursul acestui

proces, etapele menţionate sunt executate în mod repetat, prin reluarea unora dintre ele.

Desi metodele şi tehnicile de extragere a cunoştinţelor sunt aplicate în regim

automat, procesul reclamă un efort uman considerabil, implicat mai ales în etapele de

analiză, dar şi în cele de validare a rezultatelor obţinute.

5.2. SISTEMELE OLAM (ON-LINE ANALYTICAL DATA MINING)

Data Mining ca şi OLAP face parte din spectrul instrumentelor de afaceri

inteligente. Cererile OLAP descriu ce se află într-o bază de date, la anumite nivele de

DEPOZIT DE DATE

DATE

A

ETL

B

C

ŞABLOANE D

CUNOŞTINŢE

PROBLEME REALE (E)

86

agregare. Analistul OLAP încearcă să explice o cerere sau să descopere un model în baza

de date, generând o serie de ipoteze şi relaţii, cereri de baze de date pentru a verifica sau

infirma. Analiza OLAP este în esenţă un proces deductiv.

Data Mining este deci o tehnologie diferită de OLAP pentru că în loc să verifice

modelele de ipoteze îşi utilizează datele pentru a descoperi modele. Acest instrument

examinează datele şi interacţiunile certe dintre ele. Poate ajunge la aceleaşi concluzii ca şi

analistul sau poate să găsească relaţii mult mai complexe decât cele pe care acesta le-a

investigat.

Tehnologia data mining, pe de altă parte este focalizată pe aprecierea puterii

predictive a modelelor. Acest lucru este posibil datorită testării concluziilor pe alte date şi

calculul acurateţii predictive. Deci, îmbinând cele două tehnologii putem spune că data

mining şi OLAP se completează reciproc.

Înainte de acţiunea de prezicere data mining, analistul poate înţelege mai bine

implicaţiile acestora. Data mining poate ajuta procesul de analiză şi proiectare a

depozitului de date prin concentrarea atenţiei asupra variabilelor importante, identificarea

excepţiilor, găsirea interacţiunilor dintre variabile.

Ca urmare a acestor aspecte de interconectare, între cele două tehnologii au apărut

sistemele OLAM (on-line analytical data mining), denumite şi sisteme OLAP pentru Data

Mining. Acestea integrează prelucrarea multidimensională de tip OLAP cu cea de

extragere a cunoştinţelor din date (de tip data mining). Aceste sisteme presupun aplicarea

diferitelor metode de extragere a cunoştinţelor în cadrul bazelor de date multidimensionale

[HACH98].

Dintre diferitele arhitecturi definite în ultimul timp pentru sistemele de extragere a

cunoştiinţelor din date, sistemele OLAM se impun tot mai mult datorită avantajelor pe care

le prezintă şi anume:

• Asigurarea unei calităţi ridicate a datelor în cadrul depozitului de date -

Majoritatea instrumentelor pentru data mining reclamă date consistente, complete.

Din acest motiv, pentru asigurarea unei calităţi corespunzatoare a acestor date, sunt

necesare prelucrări costisitoare (transformări, integrări etc.);

• Valorificarea infrastructurii de prelucrare a datelor disponibilă în cadrul

depozitelor de date - Facilităţile de prelucrare oferite de depozitele de date includ,

de regulă, accesarea, integrarea, consolidarea şi transformarea unor baze de date

eterogene, multiple, accesul Web, facilităţi de generare de rapoarte şi analize on-

line;

87

• Realizarea unei analize exploratorii a datelor, pe baza facilităţilor oferite de

prelucrările OLAP - Tehnicile de data mining reclamă efectuarea unei analize

exploratorii a datelor, realizată cu ajutorul navigării prin baza de date, selectării

datelor relevante, analizării datelor la diferite niveluri de dataliere, prezentării

rezultatelor în diferite forme;

• Selectarea on-line a funcţiilor de prelucrare pentru data mining - Frecvent

utilizatorul nu cunoaşte tipurile de informaţii ce pot fi extrase din baza de date.

Integrând în cadrul unui sistem OLAP diferite funcţii pentru data mining se oferă

utilizatorului o mare flexibilitate în selectarea acestor funcţii, fiind posibilă o rapidă

comutare între diferitele tipuri de prelucrări.

Un sistem OLAM trebuie să realizeze extragerea cunoştinţelor din datele

multidimensionale într-un mod similar celui în cere sistemele OLAP realizează prelucrările

asupra acestor date. Dat fiind faptul că sistemele OLAM realizează şi prelucrări specifice,

legate de data mining (descriere de concepte, asociere, clasificare, grupare etc.) sunt

necesare module funcţionale suplimentare, ce nu se regasesc într-un sistem OLAP simplu.

Existenţa numeroaselor produse OLAP disponibile face utilă dezvoltarea

mecanismelor pentru data mining direct în cadrul acestor sisteme, asigurandu-se în acest

fel un acces direct la cuburile de date din sistemele OLAP. O asemenea soluţie

arhitecturală este fezabilă, pentru că nu există cerinţe diferite pentru structurile de date din

cadrul sistemelor OLAM comparativ cu cele disponibile în cadrul sistemelor OLAP.

Prelucrarile de tip OLAM pot impune existenţa unor dimensiuni de granularitate

mai fină sau agregări pe mai multe caracteristici în cadrul cuburilor de date, ceea ce

impune asigurarea unor facilităţi suplimentare la definirea cuburilor de date şi la accesarea

acestora în cadrul sistemelor OLAP. Este posibil ca în timpul prelucrărilor de tip data

mining să fie necesară schimbarea organizării datelor, din cuburi în forma tabelară

(relaţională) clasică sau în forma de schemă tip stea sau fulg de nea.

5.3. METODE ŞI ALGORITMI DE EXTRAGERE A CUNOŞTINŢELOR DIN

DATE. TIPURI DE INVĂŢARE

În principal metodele de extragere a cunoştinţelor din date reprezintă clase de

probleme asupra cărora se aplică diverşi algoritmi de rezolvare. La baza metodelor stau

tipurile de învăţare, deoarece aceste tipuri au un impact direct asupra metodei prin cerinţele

legate de forma intărilor, algoritmul aplicat şi forma ieşirilor. Prin învăţare se întelege

procesul de îmbunătăţire, schimbare a comportamentului într-un mod favorabil. În lucrarea

88

[BODE98] este precizată următoarea definiţie: “Un program învaţă din experimentul E din

punctul de vedere al clasei de activităţi T (tasks) şi al indicelui de performanţă P, dacă

performanţa a posteriori P’ în rezolvarea activităţilor T se îmbunătăţeşte cu experienţa din

E.”

În aplicaţiile de data mining, procesul de învăţare automată reprezintă de fapt

extragerea regularităţilor din setul de exemple disponibil.

Putem clasifica metodele de extragere a cunoştinţelor din date în funcţie de tipul

învăţării în metode cu mecanisme de învăţare supervizată şi în metode cu mecanisme de

învăţare nesupervizată.

Invaţarea supervizată presupune furnizarea iniţială a unor informaţii despre

conceptele ce urmează a fi învăţate, această etapă fiind o etapă de antrenare a reţelei. De

obicei se utilizează un set reprezentativ de informaţii pentru antrenare, urmând ca în etapa

următoare să se testeze procesul de învătare prin utilizarea unui alt set reprezentativ de date

de test.

Invăţarea nesupervizată porneşte direct de la extragerea de cunoştinţe şi obţinerea

de rezultate. Informaţiile nu sunt cunoscute a priori, ci trebuie obţinute. Elementele de

bază în procesul de învăţare nesupervizată sunt observarea regularităţilor şi formularea

diferitelor ipoteze.

Procesul de învăţare nesupervizată este în general mai abstract decât învăţarea

supervizată.

Pe lângă tipurile de învăţare, metodele de extragere a cunoştinţelor pot fi clasificate

şi după tipul prelucrărilor în mecanisme de învăţare neuronale şi simbolice. Atât

mecanismele de extragere a cunoştinţelor bazate pe calculul simbolic cât şi cele bazate pe

calcul neuronal pot adopta ambele tipuri de modele de învăţare.

In funcţie de aceste două clasificări menţionate mai sus se diferenţiază patru

metode principale de extragere a cunoştinţelor din date, şi anume: clusterizarea,

clasificarea, asocierea, predicţia.

Clusterizarea poate fi defină ca fiind procesul de grupare a elementelor similare

grupuri omogene numite clustere. Aceste grupuri sau clustere nu sunt cunoscute din iniţial,

ele trebuie descoperite prin procesul de învăţare. Clusterizarea este o clasă de probleme ce

utilizează mecanisme de învăţare nesupervizată, informaţiile iniţiale despre clustere nefiind

cunoscute înaintea aplicării procesului.

Gruparea elementelor în clustere se poate realiza pe mai multe direcţii sau criterii în

funcţie de:

89

• Modalitatea de construcţie a clusterelor care poate fi:

- Constructivă – se porneşte de la principiul că fiecare element de intrare

reprezintă un cluster apoi acestea se asociază în clase de clustere în funcţie

de anumite condiţii de grupare;

- Deconstructivă – iniţial toate elementele sunt grupate într-un mega-cluster

şi apoi prin divizări succesive în funcţie de anumite condiţii se formeaza

clustere mai mici până la obţinerea grupării finale.

Tot din punctul de vedere al constructiei clusterelor regăsim şi următoarea

abordare:

- Construcţie de tip centroid – se aleg centrozii sau punctele centrale pentru

fiecare cluster şi se asigează elementele la clusterul cu cel mai apropiat

centroid;

- Construcţie ierarhică – se porneşte de la principiul constructiv, adică iniţial

fiecare element formează un cluster şi apoi se comasează repetat clusterele

apropiate prin folosirea unei măsuri a distanţei dintre centroizi.

• Numărul de criterii în funcţie de care se realizează gruparea: unicriterială sau

multicriterială.

• Apartenenţa la un cluster:

- Hard – fiecare element aparţine unui singur cluster;

- Fuzzy – fiecare element are o anumită probabilitate de apartenenţă la un

grup;

• Modul de testare a erorii:

- Deterministă – se calculează eroarea pentru toate elementele;

- Probabilistă - se calculează eroarea pentru un eşantion din fiecare cluster.

În procesul de grupare a elementelor este necesară evaluarea distanţei dintre acele

elemente cu ajutorul unei funcţii D(x, y). Axiomele uzuale pentru măsurarea distanţei

dintre două elemente sunt:

1. D(x,x) = 0, un punct este la distanţă 0 de el însuşi;

2. D(x,y) = D(y,x), proprietatea de simetrie a distanţei dintre x şi y;

3. D(x,y)≤ D(x,z) + D(z, y), proprietatea de inegalitate a triunghiului.

De cele mai multe ori se utilizează distanţa euclidiană, plasând elementele într-un

spaţiu euclidian k-dimensional, distanţa între orice doua elemente, x = [x1, x2,…, xn] şi y

= [y1, y2,…, yn] este dată prin următoarele funcţii:

90

1. Distanţa comună: ( )∑ =−

k

i ii yx1

2

2. Distanţa Manhattan: ∑ =−

k

i ii yx1

3. Maximul pe o dimensiune: iiki yx −=1max

In funcţie de tipul distanţei utilizate şi de aborarea folosită se pot distinge următorii

algoritmi [ULLM00]:

• Algoritmii Bradley – Fayyad – Reina (BFR) şi k-means (sau k-NN) – sunt

algoritmi cu aborare centroidă, care utilizează o distanţă euclidiană, cu clustere

formate în jurul centroidului printr-un proces gaussian în fiecare dimensiune;

• Algoritmul Fastmap – este mai mult un mod de a construi un spaţiu euclidian

cu puţine dimensiuni pornind de la o măsură a distanţei;

• Algoritmul Ganti et al (GRGPF) – este tot cu aordare centroidă, utilizează o

distanţă euclidiană şi nu un spaţiu euclidian;

• Algoritmul CURE – este un algoritm cu abordare ierarhică, utilizează o distanţă

euclidiană, dar se aplică pe clustere care au o structură neobişuită.

Pentru exemplificare voi prezenta pe scurt algoritmul k-means sau k-NN:

Algoritmul presupune gruparea elementelor în k clustere prin asocierea fiecărui

element unei grupe în care se află cel mai apropiat centroid prin calculul distanţei între

elemente (pattern-uri).

Iniţial se creează aleator o partiţionare a setului de elemente şi se stabileşte numărul

de clustere (k) şi centrele lor. Se pot alege primele k elemente, acestea fiind iniţial şi

centroizii clusterelor.

Se asigneaza fiecare element din set celui mai apropiat cluster în funcţie de distanţa

euclidiană. La fiecare pas se recalculează poziţia centroidului şi se grupează următorul

element. Această etapa se repetă pană când se stabilizează clusterele şi la noile iteraţii nu

se mai produce nici o deplasare a unui pattern de la un cluster la altul.

In final se pot unifica sau diviza clusterele obţinute conform unor tehnici euristice (număr

minim/maxim de pattern-uri din cluster, numar minim/maxim de clustere, etc).

Aplicaţii ale clusterizării:

Clusterizarea are aplicaţii destul de vechi, de exemplu în timpul unei epidemii de

holeră din Londra, un medic a urmărit localizarea cazurilor de îmbolnăviri, obţinând o

grupare a acestora în jurul unor intersecţii principale unde existau puţuri infestate, arătând

nu numai cauza bolii ci şi modalitatea de eradicare a focarelor.

91

Mai recent, în cadrul proiectului Sloan Sky, Skycat a grupat obiectele cereşti în

clustere 2x109 în stele, galaxii, quasari, etc. Fiecare obiect era un punct într-un spaţiu cu 7

dimensiuni, unde fiecare dimensiune reprezenta nivelul rediaţiei într-o bandă a spectrului.

O altă aplicaţie a clusterizării este pe text, prin clusterizarea documentelor

percepute ca puncte într-un spaţiu multidiensional în care fiecare dimensiune corespunde

unui cuvânt. Poziţia documentului într-o dimensiune este dată de apariţia cuvântului în

document. Clusterele de documente în acest spaţiu corespund deseori cu grupuri de

documente din acelaşi domeniu.

In domeniul prelucrărilor de imagini, clusterizarea îşi găseşte aplicabilitatea, fiind

bazată pe segmentarea imaginilor în tipuri de forme care au un anumit înţeles. O aplicaţie

similară, dar pe text, poate fi recunoaşterea scrisului, OCR (Object Character Recognition).

Clasificarea presupune stabilirea apartenetei unui element la o clasă dintr-un set

de clase discrete. Spre deosebire de clusterizare unde grupurile nu erau cunoscute de

la început, în cazul clasificării aceste clase sunt proiectate de utilizator iar elementele

trebuie asociate acestora în funcţie de anumite criterii. Algoritmul are ca intrări elementele

de clasificat, iar iesirile clasele la care au fost asociate. Etapa de intruire se realizează

pe baza elementelor ale caror clasă este deja cunoscută.

Unul dintre cei mai cunoscuţi algoritmi este modelul lui Bayes, sau clasificatorul

Naïve Bayes. Algoritmul este bazat pe teoria probabilităţilor, derivând din teorema lui

Thomas Bayes şi pornind de la date istorice estimează probabilitatea de realizare a

evenimentelor viitoare.

Probabilitatea reprezintă cel mai important sistem de tratare a incertitudinii.

Utilizarea teoriei probabilităţilor pentru reprezentarea incertitudinii cunoştinţelor

presupune ca pentru fiecare informaţie, element de tipul cunoştinţelor să se asocieze o

mărime, denumita măsură de probabilitate. Astfel, fiecare element, C va fi reprezentat sub

forma: (C, P(C)), unde P(C) reprezintă măsura de probabilitate a lui C. Interpretarea

măsurii P(C) se poate face de pe pozitii [BODE98]:

• obiectiviste, în sensul că enunţul C este tratat ca eveniment, măsura P(C) fiind

considerată o proprietate intrinsecă a evenimentului. Aceasta probabilitate apare în

lucrările de specialitate sub numele de probabilitate clasică de referinţă,

frecventalistă dupa modul de calcul, obiectivă sau fizică dictată de legea producerii

evenimentului C.

• subiectiviste, măsura raportându-se la persoana care realizează enunţarea lui C şi

fiind dependentă de nivelul cunoştinţelor acestei persoane. Această interpretare a

92

măsurii de probabilitate, implementată prin statistica bayesiană este utilizată în

data mining.

Statistica Bayesiana utilizeaza probabilitatea în sensul de măsura condiţionată a

nesiguranţei, asociată cu apariţia unui anumit eveniment C, în condiţiile informaţionale

date F şi a presupunerilor acceptate. Atunci P(C|F) este probabilitatea de apariţie a

evenimentului C condiţionat de F este o măsură a încrederii în apariţia evenimentului C în

condiţiile F.

Presupunând că avem un element C condiţionat de realizarea unor factori F1…Fn,

în conformitate cu teorema lui Bayes putem scrie:

),...,(

)|,...,()(),...,|(

1

11

n

nn FFP

CFFPCPFFCP =

In practică ne interesează doar dependeţa lui C faţă de factorii F1…Fn, P(F1…Fn)

fiind constant. Deci, putem rescrie formula astfel:

...),,|,...,(),|()|()(

),|,...,()|()()|,...,()(),...,|(

213121

12111

=

===

FFCFFPFCFPCFPCP

FCFFPCFPCPCFFPCPFFCP

n

nnn

Se presupune că fiecare factor Fi este condiţional independent de alt factor Fj dacă

Fi≠ Fj, deci:

)|(),|( CFiPFCFiP j =

In acest caz modelul devine:

∏=

==n

iinn CFPCPCFPCFPCFPCPFFCP

1211 )|()()|()...|()|()(),...,|(

Ţinând cont şi de factorul constant z de realizare a probabilităţii P(F1…Fn) putem

scrie:

∏=

=n

iin CFPCP

zFFCP

11 )|()(

1),...,|(

Dacă avem un număr de k clase şi P(Fi) poate fi exprimat sub forma de r parametrii

atunci modelul lui Bayes conţine un număr de (k-1)+nrk parametrii. In practică se

consideră k=2 pentru clasificarea binară şi r=1, deci numărul de parametri ai modelului

Naïve Bayes este 2n+1, unde n este numărul caracteristici binare utilizate pentru predicţie.

Clasificatorul poate fi construit combinând acest model cu o regulă de decizie.

Uzual se alege ca regulă ipoteza cea mai probabilă, cunoscută sub denumirea de maximum

a posteriori sau MAP. Funcţia corespondentă de clasficare este [WIKI**]:

93

∏=

====n

iiicn cCfFPcCPffeclasificar

11 )|()(maxarg),...(

Asocierea reprezintă procesul de stabilire a asocierilor dintre atribute şi este aplicat

în cazul în care nu sunt specificate clase şi orice fel de structurare a datelor este considerată

utilă. Faţă de clasificare poate stabili nu numai clasa unui atribut dar şi valoarea acestuia.

De aceea asocierile sunt mult mai numeroase şi sunt necesare restricţii pentru ceea ce

trebuie considerat asociere: un prag al minimei acoperiri a asocierii si a unei minime

exactităţi ale regulilor de asociere [BODE98].

Printre algoritmii bazaţi pe reguli de asociere este algoritmul CLS introdus de

Quinlan în 1983. Acesta şi varianta sa, ID3 sunt dintre cei mai cunoscuţi algoritmi de

învăţare simbolică. Ambii se bazează pe o reprezentare a conceptelor sub formă de arbore.

Pentru clasificarea unui set de instanţe se începe din vârful arborelui şi se răspunde la

întrebările asociate nodurilor până se atinge un nod frunză, adică locul în care este

memorată clasificarea sau decizia.

Algoritmul ID3 presupune alegerea în mod aleator a unui subset de exemple de

instruire, subset denumit fereastră. Pentru aceasta fereastră, algoritmul construieşte un

arbore de decizie, care să rezolve şi să clasifice toate instanţele incluse în acea fereastră.

Arborele este apoi testat pe instanţele de instruire din afara ferestrei. Dacă toate instanţele

sunt clasificate corect, procedura se opreşte, altfel se adaugă la fereastră unele dintre

instanţele incorect rezolvate şi se reia procesul pentru noua fereastră. Această strategie

iterativă este mai eficientă decât prelucrarea concomitentă a tuturor instanţelor de instruire,

asa cum realizează algoritmul CLS.

Aplicaţii ale regulilor de asociere

Una dintre cele mai frecvente aplicaţii este problema coşului de produse care

presupune stabilirea asocierilor dintre tipuri diverse de produse cumpărate, adică ce produs

este achiziţionat împreună cu altele. Regulile de asociere în acest caz sunt propoziţii de

forma {X1, X2,…, Xn} =>Y cu seminficaţia următoare: dacă vom regăsi toate produsele

X1 X2,..., Xn în coş atunci sunt şanse mari ca acel cumpărător să achiziţioneze şi produsul

Y [ULLM00]. Probabilitatea de a-l regăsi pe Y pentru a accepta această regulă este numită

încrederea respectivei reguli. Astfel se vor considera doar reguli care au o încredere peste

un anumit prag. Se poate merge pe principiul cauzalităţii, adică ce anume determină

achiziţionarea produsului Y în cazul în care cumpărătorul alege produsele X1 X2,..., Xn. În

multe situaţii se iau în considerare regulile şi cauzalitatea în ceea ce priveşte mulţimile de

articole care apar frecvent în coşuri într-un anumit procent numit prag de suport.

94

O altă aplicaţie este descoperirea de asocieri în cadrul unor documente standard.

Spre exemplu studierea arhivelor cererilor de împrumut cu valoare mai mare de 100.000$

au arătat că beneficiarii aveau peste 45 de ani, erau în funcţii de conducere şi câştigau peste

80.000$ pe an.

Predicţia se bazează pe dependenţele detectate în datele istorice a căror intensitate

este modelată şi apoi dând valori atributelor-cauză încearcă să estimeze valoarea viitoare a

atributelor-efect.

5.4. VALIDAREA REZULTATELOR OBŢINUTE ÎN URMA APLICĂRII

METODELOR DE EXTRAGERE A CUNOŞTINŢELOR

În urma aplicării diverşilor algoritmi se obţin o serie de rezultate care necesită o

testare şi validare în funcţie de natura domeniului aplicaţiei. O astfel de testare presupune o

împărţire a datelor valide ce descriu domeniul în seturi de atrenare şi seturi de testare. Este

important ca setul de test să fie un set de instanţe independente care nu au luat parte la

formarea clasificatorului şi care sunt reprezentative pentru domeniu. In acest caz, o

abordare corectă a problemei cere împărţirea în trei a datelor: setul de antrenare, setul de

validare şi setul de testare. Aceasta nu înseamnă ca datele din setul de testare sunt pierdute

din punct de vedere al construirii modelului, în momentul în care evaluarea este terminată,

ele pot fi folosite pentru a optimiza modelul dacă acesta a depăşit condiţiile minime impuse

în faza de evaluare.

Asupra acestor seturi pot fi aplicate formule de calcul a validităţii modelului

precum: numărul de clasificări corecte, acurateţea estmărilor probabilităţilor sau eroarea în

predicţiile numerice [BODE98]. Oricăreia dintre aceste formule îi pot fi asociate costuri

ale erorii, conform implicaţiilor particulare pe care producerea ei o are asupra problemei.

Se pot utiliza fie rata erorii ca fiind proporţia erorilor în clasificarea setului de test, fie rata

erorii de substituţie ca fiind proporţia erorilor în clasificarea setului de antrenare.

Corectitudinea ratei erorii depinde de dimensiunea setului de test, dar trebuie avut în

vedere faptul că acesta nu poate fi mărit decât în detrimentul setului de antrenare şi

validare ceea ce va duce la slăbirea puterii de explorare a modelului, ducând şi la creşterea

ratei erorii.

Setul de test trebuie să fie reprezentativ atfel încât să acopere aceleaşi subdomenii

ca şi setul de antrenare. De aceea, separarea datelor inţiale nu se poate face la nivel global,

ci stratificat pe subdomenii, păstrând proporţia între datele de test şi de antrenare. In mod

uzual proporţiile cele mai des întâlnite sunt de 66% setul de antrenare şi de 33% setul de de

95

testare. O metodă des utilizată pentru construirea seturilor şi estimarea erorii este metoda

0.632 Bootstrap. Aceasta presupune că o instanţă din setul de start N are probabilitatea 1-

1/n de a nu fi aleasă, atunci probabilitatea de a apare la final in setul de test este P= (1-

1/n)^n=1/e=0.632. Ceea ce înseamnă că datele de antrenare vor conţine 63.2% din setul

iniţial. Estimarea erorii cu ajutorul acestei metode se bazează pe rata actualizată a erorii,

adică:

Rata actualizata a erorii = 0.632 * rata erorii pe setul de antrenare + 0.368 * rata

erorii pe setul de test

Procesul de calcul al acestei rate este repetat de mai multe ori cu diferite

eşantioane selectate, apoi rata erorii se calculează ca medie a ratelor astfel obţinute.

Metoda este considerată ca fiind cea mai bună pentru seturi mici de date.

96

CAPITOLUL VI –SOLUŢII DE EXTRAGERE ŞI OPTIMIZARE A

CERERILOR DE REGĂSIRE DIN DEPOZITELE DE DATE

6.1. SOLUŢII DE INTEROGARE A DATELOR DIN DEPOZITE DE DATE

UTILIZÂND LIMBAJUL SQL ŞI FUNCŢIILE ANALITICE

Funcţiile analitice sunt utilizate frecvent în extragerea şi realizarea de rapoarte pe

baza datelor din depozitele de date. Acestea procesează datele pe baza unor grupuri de

înregistrări însă diferă de funcţiile agregate sau de grup returnând mai multe rezultate

pentru fiecare grup în parte. Grupul de înregistrări aupra căruia se aplică analiza este

numit fereastră şi este definit cu ajutorul unei clauze analitice.

Fereastra determină intervalul de tupluri supuse analizei pentru fiecare înregistrare

curentă procesată. Dimenisunea ferestrei poate fi determinată fie fizic, precizând numărul

de înregistrări din grup, fie logic, prin condiţii pe valorile câmpurilor. Operaţiile analitice

sunt ultimele procesate într-o cerere SQL înaintea clauzei ORDER BY.

Structura unei funcţii analitice este următoarea:

FUNCŢIE_ANALITICĂ (argumente) OVER (clauza_analitică)

Clauza analitică poate avea următoarele subclauze:

PARTITION BY (expresie1, expresie2,…) ORDER [SIBLINGS] BY

expresie/pozitie/alias [ASC/DESC] [nulls first/last] CLAUZA_FEREASTRA

Unde clauza_fereastra poate fi:

ROWS/RANGE [BETWEEN] {UNBOUNDED PRECEDING}/ {CURRENT

ROW}/ {expresie PRECEDING/FOLLOWING}[AND] {UNBOUNDED PRECEDING}/

{CURRENT ROW}/ {expresie PRECEDING/FOLLOWING}

Dacă se omite clauza_fereastră atunci în mod implicit se aplică RANGE

BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.

Funcţiile analitice implementate de Oracle 10g sunt următoarele: AVG, CORR,

COVAR_POP, COVAR_SAMP, COUNT, CUME_DIST, DENSE_RANK, FIRST,

FIRST_VALUE, LAG, LAST, LAST_VALUE, LEAD, MAX, MIN, NTILE,

PERCENT_RANK, PERCENTILE_CONT, PERCENTILE_DISC, RANK,

RATIO_TO_REPORT, REGR_RL, ROW_NUMBER, STDDEV, STDDEV_POP,

STDDEV_SAMP, SUM, VAR_POP, VAR_SAMP, VARIANCE.

In continuare voi exemplifica aplicarea acestor funcţii pentru realizarea de

interogări analitice asupra unui set de tabele şi view-uri care stau la baza analizei

97

activităţilor comerciale şi financiare modelate în cadrul ultimului capitol al acestei lucrări

şi anume: CLIENTI, FURNIZORI, COMENZI_DESFACERE, COMENZI_APROV,

PRODUSE, UNITATI, RULAJE_BALANTA.

1) Funcţia AVG utilizată pentru calcularea mediei valorilor în funcţie de criteriile

specificate în clauza ferestrei.

Exemplu: Se calculează media rulajelor debitoare pe trei zile consecutive pe

fiecare companie:

SELECT e.compania, e.cont, e.moneda, e.data, e.rulaj_d,

AVG(e.rulaj_d) OVER (PARTITION BY e.compania ORDER BY e.data

ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS

medie_rulaj_debitor

FROM rulaje_balanta e;

Utilizarea clauzei ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING

determină analiza valorii anterioare şi imediat următoare a înregistrării curente. In acest

caz fereastra de analiză este formată din înregistrările vecine înregistrării curente în funcţie

de zi pe fiecare companie în parte.

Modificând condiţia de partiţionare putem calcula media rulajelor debitoare pe trei

luni (luna anterioară, luna curentă şi luna imediat următoare) faţă de ziua curentă pe fiecare

companie:

SELECT e.compania, e.cont, e.moneda, e.data, e.rulaj_d,

AVG(e.rulaj_d) OVER (PARTITION BY e.compania ORDER BY extract(month

from e.data)

ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS

medie_rulaj_debitor

FROM rulaje_balanta e

order by e.data;

2) Funcţia CORR utilizată pentru calcularea coeficientului de corelaţie dintre un set

de valori. Funcţia primeşte doi parametrii (expresie1, expresie2) şi realizează următoarele

calcule: COVAR_POP(expresie1, expresie2)/STDEV_POP(expresie1) *

STDEV_POP(expresie1). Este implementată în trei variante: CORR – coeficientul de

corelaţie Pearson, CORR_S – coeficientul de corelaţie Spearman şi CORR_K– coeficientul

de corelaţie Kendall. În forma analitică funcţia este utilizată pentru calcularea valorii

cumulate a coeficientului de corelaţie. În exemplul următor voi calcula prin metoda

98

agregată coeficientul de corelaţie Pearson dintre pretul produsului current şi cel minim

pentru fiecare categorie de produse şi prin metoda analitică acelaşi coeficient de corelaţie

dintre cantitatea recepţionată şi preţul unitar pe fiecare lună în funcţie de furnizor şi de

codul produsului:

select a.categorie,

corr(unit_price, (select min(unit_price) from

EXPR_DETALII_COMENZI_APR_V@prodlink min_price)) corelatie

from EXPR_DETALII_COMENZI_APR_V a

group by categorie

select vendor_id,inventory_item_id ,

corr(quantity_received, unit_price) OVER (ORDER BY extract(month from

creation_date)) as corelatie

from expr_detalii_comenzi_apr_v

3) Funcţia COVAR_POP utilizată pentru calcularea covarianţei dintre două valori

transmise ca parametrii şi realizează următoarele calcule:

(SUM(expresie1*expresie2)-SUM(expresie2)*SUM(expresie1)/n)/n

In continuare voi calcula covarianţa dintre preţul unitar al produselor şi preţul

minim în funcţie de furnizor şi produs.

select c.vendor_id, c.inventory_item_id,

covar_pop(c.unit_price, (select min(unit_price) from

EXPR_DETALII_COMENZI_APR_V min_price))

over (order by c.vendor_id, c.inventory_item_id) as covarianta

from EXPR_DETALII_COMENZI_APR_V c

4) Funcţia COUNT utilizată în varianta analitică poate fi aplicată pentru realizarea

de subtotaluri în funcţie de fereastra analizată. Atfel se poate calcula numărul de produse

pe fiecare furnizor în parte care au valoarea comenzilor cuprinsă între intervalul

[valoare_curentă-1000 RON , valoare_curentă+1000 RON]:

select c.vendor_id, c.inventory_item_id,

count(*)

over (order by (c.unit_price*c.quantity_received) range between 1000 preceding

99

and 1000 following) as nr_comenzi_interval

from EXPR_DETALII_COMENZI_APR_V c

Un alt exemplu permite calcularea numărului de unităţi care au o situaţie a rulajelor

debitoare apropiată de a unităţii curente cu o abatere de ±1000 RON pentru conturile de

clasă 6:

select e.cont, e.compania,sum(rulaj_d),

count(*)

over (order by sum(rulaj_d) range between 1000 preceding and 1000 following)

as nr_vecini

from rulaje_balanta e

where e.moneda ='RON' and cont like'6%'

group by e.cont, e.compania

order by cont

5) Funcţiile MIN şi MAX aplicate în mod analitic pot realiza statistici sau

clasamente şi pot încadra valoarea curentă analizată într-un interval de valori. In exemplul

următor se realizează o clasificare a produselor în funcţie de valoarea comenzilor pe

fiecare furnizor şi companie în parte:

select c.vendor_id, c.organization_id,

min(c.unit_price*c.quantity_received) keep (dense_rank first order by unit_price)

over (partition by c.inventory_item_id) as inferior,

max(c.unit_price*c.quantity_received) keep (dense_rank last order by unit_price)

over (partition by c.inventory_item_id) as superior

from EXPR_DETALII_COMENZI_APR_V c

order by c.vendor_id

Un alt exemplu este realizarea unei situaţii privind totalul rulajelor debitoare ale

conturilor de clasă 6 cu încadrarea acestora între limitele inferioare şi superioare ale

contului current:

select e.compania, e.cont,sum(e.rulaj_d),

min(sum(e.rulaj_d)) keep (dense_rank first order by e.cont)

over (partition by e.cont) as inferior,

max(sum(e.rulaj_d)) keep (dense_rank last order by e.cont)

over (partition by e.cont) as superior

from rulaje_balanta e

100

where cont like'6%' and moneda='RON'

group by e.compania, e.cont

order by cont, sum(e.rulaj_d)

6) Funcţiile FIRST_VALUE şi LAST_VALUE reprezintă o altă variantă de

realizare a clasificărilor pe intervale şi limite. Avantajul este că prin aceste funcţii se pot

indica limitele cu aceleaşi valori în funcţie de criterii alternative de clasificare. Exemplele

de mai sus pot fi scrise astfel:

select e.compania, e.cont,sum(e.rulaj_d),

first_value(sum(e.rulaj_d)) over (partition by e.cont order by sum(e.rulaj_d)

rows unbounded preceding) as inferior,

last_value(sum(e.rulaj_d)) over (partition by e.cont order by sum(e.rulaj_d) rows

between unbounded preceding and unbounded following) as superior

from rulaje_balanta e

where cont like'6%' and moneda='RON'

group by e.compania, e.cont

order by cont, sum(e.rulaj_d)

Modificând clauza ferestrei putem afişa valorile minime, respectiv maxime ale

intervalului ± 1000000 RON faţă de valoarea curentă a rulajului debitor:

select e.compania, e.cont,sum(e.rulaj_d),

first_value(sum(e.rulaj_d)) over (partition by e.cont order by sum(e.rulaj_d)

range between 1000000 preceding and 1000000 following) as inferior,

last_value(sum(e.rulaj_d)) over (partition by e.cont order by sum(e.rulaj_d)

range between 1000000 preceding and 1000000 following) as superior

from rulaje_balanta e

where cont like'6%' and moneda='RON'

group by e.compania, e.cont

order by cont, sum(e.rulaj_d)

7) Funcţia LAG raportează valoarea curentă la valorile anterioare din fereastră sau

pe baza condiţiilor analitice. Funcţia permite accesul la o serie de înregistrări în acelaşi

timp fără a fi necesar un self-join prin specificarea unei poziţii a cursorului faţă de poziţia

curentă. Dacă această poziţie nu se specifică atunci se consideră ca fiind implicit 1. Funcţia

primeşte ca parametrii expresia asupra căreia se aplică analiza, deplasarea înapoi a

101

cursorului şi valoarea implicită a deplasării în cazul în care cursorul ar depăşi fereastra de

analiză. Exemplul următor afişează valorile curente şi precedente ale rulajelor totale

debitoare cu o deplasare a cursorului de o singură înregistrare:

select e.cont,e.data, e.compania,sum(e.rulaj_d) rulaj_curent,

lag(sum(e.rulaj_d),1,0) over (order by cont, data, compania)

as rulaj_anterior

from rulaje_balanta e

where cont like'6%' and moneda='RON'

group by e.cont, e.data, e.compania

8) Funcţia LEAD raportează valoarea curentă parcursă de cerere la valorile

ulterioare din fereastră sau pe baza condiţiilor analitice. Funcţia, la fel ca şi LAG, permite

accesul la un set de înregistrări prin specificarea unei poziţii a cursorului faţă de poziţia

curentă fără a fi necesar un self-join. Dacă această poziţie nu se specifică atunci se

consideră ca fiind implicit 1. Funcţia primeşte ca parametrii expresia asupra căreia se

aplică analiza, deplasarea înainte a cursorului şi valoarea implicită a deplasării în cazul în

care cursorul ar depăşi fereastra de analiză. În exemplul următor se afişează valorile

curente, precedente şi ulterioare ale rulajelor totale debitoare cu o deplasare a cursorului de

o singură înregistrare:

select e.cont,e.data, e.compania,sum(e.rulaj_d) rulaj_curent,

lag(sum(e.rulaj_d),1,0) over (order by cont, data, compania)

as rulaj_anterior,

lead(sum(e.rulaj_d),1,0) over (order by cont, data, compania)

as rulaj_urmator

from rulaje_balanta e

where cont like'6%' and moneda='RON'

group by e.cont, e.data, e.compania

Funcţiile LEAD şi LAG sunt utile şi în realizarea de previziuni prin calcularea

valorilor viitoare pe un anumit interval în funciţie de valoarea anterioară şi următoare a

valorilor curente.

9) Funcţia NTILE permite împărţirea unui interval de valori în n diviziuni şi

încadrarea valorii curente în cardrul acestor diviziuni. Funcţia primeşte ca parametru

numărul de intervale şi returnează numărul de valori găsite în acelaşi interval cu valoarea

curentă. De exemplu putem împărţi valoarea totală a comenzilor în 10 intervale şi aplicând

102

funcţia NTILE calculăm în ce interval se află valoarea curentă şi câte valori sunt în acelaşi

interval:

select c.inventory_item_id, c.organization_id,

sum(c.unit_price*c.quantity_received) valoare_comenzi,

ntile(10) over (partition by c.inventory_item_id order by

sum(c.unit_price*c.quantity_received)) as nr_comenzi_pe_interval

from EXPR_DETALII_COMENZI_APR_V c

group by c.inventory_item_id, c.organization_id

order by c.inventory_item_id, c.organization_id

10) Funcţia RANK se utilizează la realizarea de clasificări şi topuri, returnând

poziţia valorii curente în cadrul ferestrei analizate. Dacă se găsesc valori identice ele vor fi

încadrate la aceeaşi poziţie în cadrul clasamentului. De exemplu interogarea următoare

returnează poziţia fiecărui produs în cadrul comenzilor de aprovizionare realizate:

select c.vendor_id, c.inventory_item_id, c.quantity_received, c.unit_price,

rank() over (partition by c.inventory_item_id

order by c.quantity_received desc, c.unit_price desc) pozitie

from expr_detalii_comenzi_apr_v c

Un alt exemplu realizează un top al rulajelor pe conturile de cheltuieli înregistrate

de fiecare companie:

select e.compania, e.cont, sum(e.rulaj_d),

rank() over (partition by e.compania

order by sum(e.rulaj_d) desc ) pozitie

from rulaje_balanta e

where e.moneda='ron' and e.cont like '6%'

group by e.compania, e.cont

order by e.compania, pozitie

În mod similar se poate utiliza funcţia DENSE_RANK, diferenţa între cele două

este modul de tratare a intervalelor de valori, în cazul funcţiei DENSE_RANK aceasta

tratează compact valorile şi asociează acestora numere consecutive.

select e.compania, e.cont, sum(e.rulaj_d),

rank() over (partition by e.compania

order by sum(e.rulaj_d) desc ) pozitie1,

dense_rank() over (partition by e.compania

103

order by sum(e.rulaj_d) desc ) pozitie2

from rulaje_balanta e

where e.moneda='ron' and e.cont like '6%'

group by e.compania, e.cont

order by e.compania, pozitie1

11) Funcţia PERCENT_RANK este utilizată tot pentru realizarea de clasamente,

însă în mod procentual similar cu o distribuţie cumulată. Primul element dintr-un set de

valori va avea aociată poziţa 0, restul elementelor asociindu-se pe rând procente de

distribuţie. Dacă sunt găsite valori identice, aceastora li se asociază acelaşi procent.

Modificând exemplul anterior putem obţine distribuţia cumulată a rulajelor conturilor de

cheltuieli pe fiecare companie:

Select e.COMPANIA, e.cont, sum(e.RULAJ_d),

percent_RANK() OVER (PARTITION BY e.compania

ORDER BY sum(e.RULAJ_d) desc ) Pozitie,

RANK() OVER (PARTITION BY e.compania

ORDER BY sum(e.RULAJ_d) desc ) Distributie

from rulaje_balanta e

where e.MONEDA='RON' and e.CONT like '6%'

group by e.COMPANIA, e.CONT

order by e.COMPANIA, pozitie

12) Funcţia RATIO_TO_REPORT permite asocierea ponderii deţinute de fiecare

înregistrare în cadrul grupului sau ferestrei analizate. De exemplu putem stabili ponderea

fiecărui produs în totalul valoric al comenzilor de aprovizionare pe fiecare funizor:

select c.vendor_id, c.inventory_item_id, c.quantity_received*c.unit_price

valoare_produs,

ratio_to_report(c.quantity_received*c.unit_price) over (partition by c. vendor_id)

procent

from expr_detalii_comenzi_apr_v c

Sau putem stabili ponderea fiecărei cheltuieli din totalul acestora pe companii:

select e.COMPANIA, e.cont, sum(e.RULAJ_d),

ratio_to_report(sum(e.rulaj_d))

OVER (PARTITION BY e.compania ) Procent

104

from rulaje_balanta e

where e.MONEDA='RON' and e.CONT like '6%'

group by e.COMPANIA, e.CONT

order by e.COMPANIA, procent

13) Funcţiile REGR_RL pentru regresie liniară. Oracle 10g implementează

următoarele tipuri de funcţii de regresie: REGR_SLOPE, REGR_INTERCEPT,

REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY,

REGR_SXY. In continuare voi considera un emxeplu care utilizează comparativ toate

aceste tipuri de funcţii:

select e.COMPANIA, e.cont,extract (month from e.data)luna, sum(e.RULAJ_d)

total_rulaj_debitor,

REGR_SLOPE(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) slope,

REGR_INTERCEPT(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) intcpt,

REGR_R2(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) rsqr,

REGR_COUNT(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) count,

REGR_AVGX(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) avgx,

REGR_AVGY(SYSDATE-e.data, sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA) avgy

from rulaje_balanta e

where e.MONEDA='RON' and e.CONT like '6%' and e.compania='A10'

group by e.COMPANIA, e.CONT,e.data

order by e.COMPANIA

14) Funcţiile STATS_TIPTest deşi nu sunt funcţii analitice, ele permit observarea

şi calcularea unor coeficienţi statistici, relevanţi pentru stabilirea unor legături între doua

valori nominale. Coeficienţii care se pot calcula se referă la diverse tipuri de teste utilizate

în statistică şi sunt: STATS_BINOMIAL_TEST, STATS_CROSSTAB (pentru testul CHI

pătrat), STATS_F_TEST (testul F), STATS_KS_TEST (testul Kolmorogov-Smirnov),

105

STATS_MODE, STATS_MW_TEST (testul Mann Whitney),

STATS_ONE_WAY_ANOVA (pentru testul ANANOVA), STATS_T_TEST (testul T),

STATS_WSR_TEST (rangul Wilcoxon).

Exemplu următor detemină gradul de legătură dintre pretul produsului şi cantitatea

comandată pentru tipuri de produse din aceeaşi categorie:

SELECT c.VENDOR_ID, c.INVENTORY_ITEM_ID,

STATS_CROSSTAB(c.QUANTITY_RECEIVED,c.UNIT_PRICE,'CHISQ_OBS'

) chi_patrat,

STATS_CROSSTAB(c.QUANTITY_RECEIVED,c.UNIT_PRICE,'CHISQ_SIG'

) semnificatie,

STATS_CROSSTAB(c.QUANTITY_RECEIVED,c.UNIT_PRICE,'PHI_COEFF

ICIENT') coeficientul_phi

FROM expr_detalii_comenzi_apr_v c

15) Funcţia STDDEV calculează coeficientul de deviaţie standard pentru valorile

din grupul analizat. De exemplu putem calcula coeficientul standard de deviaţie cumulat

pentru produsele din categoria ‘carburanti’:

SELECT c.VENDOR_ID,c.inventory_organization_id,

c.INVENTORY_ITEM_ID,

stddev(c.QUANTITY_RECEIVED)

OVER (PARTITION BY c.inventory_organization_id) deviatie

FROM expr_detalii_comenzi_apr_v c

WHERE c.categorie='carburanti'

16) Funcţia SUM utilizată în mod analitic permite realizarea de sume cumulate în

funcţie de grupul analizat. Exemplu urmator realizează un subtotal al comenzilor cuprinse

în intervalul ±100000 fată de valoarea curentă:

SELECT c.VENDOR_ID,c.inventory_organization_id,

c.INVENTORY_ITEM_ID,

SUM(c.UNIT_PRICE*c.QUANTITY_RECEIVED)

OVER (PARTITION BY c.inventory_organization_id

ORDER BY c.UNIT_PRICE*c.QUANTITY_RECEIVED

RANGE between 100000 preceding and 100000 following) cumulat

FROM expr_detalii_comenzi_apr_v c

106

Dacă se schimbă clauza ferestrei se poate realiza un subtotal al comenzilor cu

valoarea mai mică sau egală cu valoarea curentă:

SELECT c.VENDOR_ID,c.inventory_organization_id,

c.INVENTORY_ITEM_ID,

SUM(c.UNIT_PRICE*c.QUANTITY_RECEIVED)

OVER (PARTITION BY c.inventory_organization_id

ORDER BY c.UNIT_PRICE*c.QUANTITY_RECEIVED

RANGE unbounded preceding ) cumulat

FROM expr_detalii_comenzi_apr_v c

17) Funcţia VARIANCE calculează coeficientul de varianţă dintre setul de valori

supuse analizei. De exemplu putem obţine în varianta analitică a funcţiei, un coeficient

cumulat pentru rulajele debitoare ale conturilor de clasă 6 pe fiecare companie:

select e.COMPANIA, e.cont, sum(e.RULAJ_d) total_rulaj_debitor,

variance(sum(e.RULAJ_d))

OVER (PARTITION BY e.COMPANIA order by e.cont)

from rulaje_balanta e

where e.MONEDA='RON' and e.CONT like '6%'

group by e.COMPANIA, e.cont

order by e.COMPANIA

107

Figura 6.1.1. – Aplicarea funcţiilor analitice SUM şi COUNT

Aceste funcţii au fost prezentate sintetic şi în articolul [BALU06].

6.2. ALGORITMI DE OPTIMIZARE A CERERILOR DE REGĂSIRE PENTRU

DEPOZITELE DE DATE

Sistemele suport de decizie care utilizează depozite de date se confruntă cu

probleme legate de viteza de răspuns a interogărilor realizate asupra surselor de date, de

obicei asupra bazelor dedate relaţionale. Un factor principal care influenţează negativ

viteza de răspuns este dimensiunea bazei de date care poate ajunge în cele mai multe

cazuri la 5000 – 10000 de gigabytes. În cadrul cererilor de regăsire realizate asupra

acestor baze de date proiectanţii depozitelor se confruntă cu alţi factori negativi şi anume

multitudinea de joncţiuni realizate între tabele, indecşi şi tabele virtuale neoptimizate.

108

Deseori, în mediile în care există puţini utilizatori ai depozitului de date, cu cereri

de regăsire la intervale relativ mari şi regulate de timp se preferă ca datele din bazele de

date să fie încărcate periodic în depozit, o singură dată, la începutul intervalului specificat

de utilizator. Problemele grave apar în mediile cu mulţi utilizatori, cu cereri

concurenţiale, online, la intervale neregulate, aleatoare unde timpul de răspuns al

sistemului creşte, ducând chiar la imposibilitatea operării şi rulării rapoartelor de analiză

cerute.

In vederea îmbunătăţirii performanţelor acestor sisteme se pot aplica tehnici de

optimizarea a cererilor de interogare şi regăsire a datelor. In continuare voi prezenta

modalitatea de estimare a timpului de răspuns, modul de execuţie şi tehnicile de

optimizare utilizate de Oracle Database 10g. Pentru exemplificare voi utiliza acelaşi set de

tabele rezultate activitatea comercială şi financiară, respectiv: CLIENTI, FURNIZORI,

PRODUSE, UNITATI, COMENZI_DESFACERE, COMENZI_APROV. Pentru orice tip de

raport de analiză avem nevoie de un set de view-uri rezultate prin joncţiuni multiple între

aceste tabele. Presupunând că numărul de înregistrări relevante pentru analiză este foarte

mare, se pune problema optimizării acestor joncţiuni astfel încât rularea raportelor cerute

să se realizeze într-un timp cât mai scurt.

Oracle 10g dispune de un instrument de analiză a timpilor şi a algoritmilor de

execuţie a cererilor – Explain Plan. În momentul în care se execută o cerere de regăsire

(query), în funcţie de anumiţi factori, Oracle aplică un anumit algoritm, de regulă

optimizat. Principliul de lucru are la bază costul execuţiei acelei cereri aplicând pe rând

diverşi algoritmi de optimizare în funcţie de statisticile obţinute din dicţionarul metadatelor

referitoare la: operatorii relaţionali, numărul de înregistrări din fiecare tabelă implicată,

indecşi, clustere şi partiţii disponibile pentru acele tabele implicate în cerere. Sunt luaţi în

calcul şi alţi factori precum căile de acces la date, ordinea joncţiunilor, resursele fizice

disponibile (CPU, memorie, operaţii de I/O). Este ales acel algoritm care minimizează

costul de execuţie şi implică un minim de resurse. Aceşti algoritmi selectaţi implicit de

către Oracle pot fi aleşi şi de către programator cu ajutorul unor directive (hints) inserate în

codul SQL astfel încât să se seteze parametrul OPTIMIZER_MODE pentru o anumită

cerere. Directivele sunt precizate imediat după instrucţiunea SELECT şi indică algoritmul

de execuţie ales pentru cererea respectivă. De asemenea aceşti algoritmi sunt aplicaţi

diferit în cazul cererilor executate pe o singură tabelă sau în cazurile în care sunt aplicate şi

alte operaţii cum ar fi agregări, ordonări etc

109

Pentru a putea determina ce algoritm va îmbunătăţi performanţele cererilor se

utilizează pachetul DBMS_STATS. Rezultatele furnizate de funcţiile pachetului se referă

la distribuţia datelor, numărul de înregistrări, unicitatea valorilor, duplicate, etc, rezultate

pe baza cărora se poate aplica un plan de execuţie selectând un anumit algoritm.

De exemplu putem colecta informaţii despre tabelele din schema curentă cu

ajutorul funcţiei GATHER_TABLE_STATS(USER, TABELA):

Begin

DBMS_STATS.GATHER_TABLE_STATS (user, 'comenzi_desfacere');

End;

/

Select column_name, count(*)

from user_tab_histograms

where table_name='COMENZI_DESFACERE'

and column_name in ('INVENTORY_ORGANIZATION_ID',

'INVENTORY_ITEM_ID')

group by column_name;

Rezultatele se pot vizualiza în figura următoare:

Figura 6.1: Utilizarea pachetului DBMS_STATS

Alegerea unui anumit tip de algortim se face în funcţie de statisticile obţinute. În

continuare voi prezenta pe scurt fiecare tip de cerere şi algoritmii implicaţi, comparaţii

între rezultatele obţinute şi recomandări privind alegerea celei mai bune metode care să

optimizeze performanţa interogării. Aceste rezultate au fost prezentate pe scurt şi în

articolul [BALU06].

110

6.2.1. SOLUŢII DE OPTIMIZARE A CERERILOR REALIZATE PE O

SINGURĂ TABELĂ

In cazul cererilor realizate pe o singură tabelă, de exemplu pe tabela de fapte

COMENZI_DESFACERE, o mare influenţă asupra performanţelor o au indecşii pe

coloanele implicate în condiţiile din clauza WHERE [ORA10G].

De exemplu, dacă indexăm câmpul CUSTOMER_ID din tabela

COMENZI_DESFACERE:

create index cd_c_id_idx on comenzi_desfacer e(customer_id);

şi aplicăm un criteriu de selecţie în clauza WHERE pe CUSTOMER_ID se va

observa o îmbunătăţire a costului de execuţie de doar 2 unităţi la rularea cererii

select *

from comenzi_desfacere cd

where CUSTOMER_ID=1598

faţă de varianta de execuţie fără aplicarea indexului cu un cost de execuţie de 3

unităţi:

select /*+ NO_INDEX(CD CD_C_ID_IDX) */ *

from comenzi_desfacere cd

where CUSTOMER_ID=1598

Insă aplicarea indexării nu întotdeauna poate genera rezultate mai bune. Dacă

numărul total de înregistrări selectate este mare şi cardinalitatea pentru criteriul respectiv

depăşeşte 20% din numărul total de înregistrări din tabelă atunci nu se recomandă folosirea

directivei INDEX. De exemplu, cardinalitatea pentru condiţia CUSTOMER_ID=1905 este

de 53, aproximativ 50% din numărul total de înregistrări din tabelă, iar costul obţinut prin

aplicarea indexării (4 unităţi) este mai mare decăt costul obţinut prin parcurgerea totală a

tabelei (3 unităţi):

111

Figura 6.2 – Utilizarea directivei INDEX vs. NO_INDEX pentru cardinalităţi mari

6.2.2. SOLUŢII DE OPTIMIZARE A CERERILOR CU JONCŢIUNI

In cadrul depozitelor de date predomină acest tip de cereri, datele finale de analiză

fiind opţinute prin joncţiuni între o tabelă de fapte şi mai multe tabele dimensiuni. In

aceste tipuri de interogări, aşa cum am prezentat anterior un rol important îl au în

continuare indecşii, o cerere de joncţiune se realizează mult mai repede dacă pe coloanele

respective sunt activi indecşi, iar numărul de înregistrări care participă este relativ mic.

O interogare de joncţiune poate fi executată în multe feluri, aplicând algoritmi de

optimizare diferiţi ca: full table scans, index scans, nested loops, hash joins, sort merge

joins [ORA10G]. Algoritmii se pot aplica diferit şi pe seturi de înregistrări, astfel putem

specifica în directivă execuţia într-un anumit mod pentru primele n înregistrări

(FIRST_ROWS(n)) sau pentru toate înregistrările (ALL_ROWS).

Algortimi de tipul Hash Joins - este utilizat pentru cererile în care sunt implicate

tabele cu foarte multe îregistrări şi asupra cărora se aplică un join de egalitate. Algoritmul

constă în alegerea tabelei cu dimensiunea mai mică şi construirea unei tabele hash în

memorie pe baza condiţiei de joncţiune. Apoi este scanată şi cealaltă tabelă pentru

regăsirea de înregistrări care corespund condiţiei de legătură. Acest algoritm este aplicat în

cazul în care tabela mai mică încape în memoria internă astfel minimizându-se operaţiile

de acces pe disc. Costul execuţiei se rezumă la timpul de parcurgere a tabelei de

dimensiune mare în căutarea înregistrărilor de joncţiune.

Exemplul următor prezintă modalitatea de joncţiune HASH dintre tabelele

CLIENTI şi COMENZI_DESFACERE. În acest caz tabela COMENZI_DESFACERE cu

86 de înregistrări este utilizătă pe post de tabelă hash în memorie, iar tabela CLIENTI

având 262 de înregistrări va fi scanată:

select

112

c.customer_id,

c.customer_name,

cd.ordered_date,

cd.ordered_quantity

from clienti c,

comenzi_desfacere cd

where cd.item_id=22

and c.customer_id=cd.customer_id

Figura. 6.3. Joncţiune de tipul HASH

In acest caz implicit este aplicat acest algoritm, însă dacă se aplică un alt algoritm se poate

seta parametrul de optimizare cu ajutrul directivei /*+ USE_HASH(cd c) */:

select /*+ USE_HASH(cd c) */

c.customer_id,

c.customer_name,

cd.ordered_date,

cd.ordered_quantity

from clienti c,

comenzi_desfacere cd

where cd.item_id=22

and c.customer_id=cd.customer_id

Algortimi de tipul Nested Loop Joins – este recomandat pentru joncţiuni între

subseturi relativ reduse de date, iar condiţia de joncţiune reprezintă un mod eficient de

parcurgere a tabelelor. Opţiunea de utilizare a algoritmului se specifică prin directiva

USE_NL:

113

Figura 6.4: Nested Loops

select /*+ USE_NL (cd c)*/

c.customer_id,

c.customer_name,

cd.ordered_date,

cd.ordered_quantity

from clienti c,

comenzi_desfacere cd

where cd.item_id=22

and c.customer_id=cd.customer_id;

Prin comparaţie între cele două metode utilizate, costul de execuţie prin Hash Joins

este de 7 iar prin Nested Lops de 24, deci în cazul acesta este recomandată utilizarea

primei metode.

Algortimi de tipul Sort Merge Joins – este recomandat pentru joncţiuni în care

una dintre tabele are înregistrările deja sortate. In general dacă este aplicată în prelabil o

ordonare a înegistrărilor, acest algoritm duce la scăderea costurilor de execuţie faţă de

rezultatele similare obţinute prin aplicarea algoritmului Hash Joins. Sort Merge Joins este

recomandat şi pentru cazurile în care se realizează o joncţiune cu o condiţie de inegalitate

sau pentru seturi foarte mari de date. Principiul de execuţie nu este ghidat de alegerea unei

tabele sau alta, ci este următorul:

• se realizează o ordonare a datelor din ambele tabele după cheia (condiţia) de

căutare. Dacă deja a fost aplicată o sortare corespunzătoare, acest pas nu se

mai aplică.

114

• se realizează operaţia de joncţiune între cele două tabele ordonate.

Alegerea acestui algoritm este recomandată pentru seturi mari de date şi pentru

condiţii de inegalitate între tabele deoarece acest tip de joncţiune necesită şi o ordonare a

datelor.

În exemplul următor se indexează tabela CLIENTI pe câmpul customer_id, iar

tabela COMENZI_DESFACERE pe customer_id şi ordered_date.

create index clienti_cust_id_idx on clienti(customer_id);

create index cd_c_id_idx on comenzi_desfacere(customer_id);

create index cd_ord_date_idx on comenzi_desfacere(ordered_date);

Apoi este aplicată joncţiunea pe cele două tabele cu directiva USE_MERGE:

select /*+ USE_MERGE (cd c)*/

c.customer_id,

c.customer_name,

cd.ordered_date,

cd.ordered_quantity

from clienti c,

comenzi_desfacere cd

where cd.item_id=22

and c.customer_id=cd.customer_id;

Figura 6.5: Sort Merge joins

Algortimi de tipul Cartesian Joins - se aplică în cazul joncţiunilor de tip produs

cartezian cand între cele două tabele implicate nu se poate realiza o legătură, iar rezultatul

cererii constă în combinaţia fiecărei înregistrări din prima tabelă cu fiecare înregistrare din

cea de-a doua.

115

Algortimi de tipul Outer Joins - sunt aplicaţi în cazul joncţiunilor externe şi sunt

de patru tipuri: Nested Loop Outer Joins, Hash Join Outer Joins, Sort Merge Outer Joins,

Full Outer Joins.

• Nested Loop Outer Joins – este utilizat în cazul joncţiunilor externe iar principiul

de lucru ste următorul: este aleasă una dintre tabele pe post de pivot, iar

înregistrările celei de-a doua tabele sunt parcurse într-un ciclu repetitiv în funcţie de

condiţia de legătură. În exemplul următor aplicarea acestui algortim duce la

obţinerea celui mai mare cost de execuţie:

SELECT /*+ USE_NL(c cd) */

c.customer_id,

c.customer_name,

nvl(sum(cd.ordered_quantity),0) total_quantity

FROM clienti c,

comenzi_desfacere cd

WHERE c.customer_id = cd.customer_id(+)

group by c.customer_id,

c.customer_name;

Dacă însă introducem o condiţie suplimentară de limitare a valorilor câmpului

customer_id vom obţine o îmbunătăţire a performanţelor cu un cost de 5 unităţi,

faţă de 7 obţinut cu Hash Joins sau Merge Joins:

SELECT /*+ USE_NL(c cd) */

c.customer_id,

c.customer_name,

nvl(sum(cd.ordered_quantity),0) total_quantity

FROM clienti c,

comenzi_desfacere cd

WHERE c.customer_id = cd.customer_id(+)

and c.customer_id IN(1592, 1598)

group by c.customer_id,

c.customer_name;

• Hash Join Outer Joins – este aplicat în principal pentru volume mari de date astfel

încât metoda Hash să fie eficientă şi nu există posibilitatea utilizării unei tabele pe

post de pivot. În exemplul următor se obţine cel mai bun rezultat prin aplicarea

acestui algoritm:

116

SELECT /*+ USE_HASH(c cd) */

c.customer_id,

c.customer_name,

nvl(sum(cd.ordered_quantity),0) total_quantity

FROM clienti c,

comenzi_desfacere cd

WHERE c.customer_id = cd.customer_id(+)

group by c.customer_id,

c.customer_name;

• Sort Merge Outer Joins – este aplicat când nu se poate alege o tabelă pe post de

pivot sau condiţiile impuse datelor duc la o creştere a costurilor obţinute prin

aplicarea algoritmului Hash sau când deja înregistrările sunt ordonate:

SELECT /*+ USE_MERGE(c cd) */

c.customer_id,

c.customer_name,

nvl(sum(cd.ordered_quantity),0) total_quantity

FROM clienti c,

comenzi_desfacere cd

WHERE c.customer_id = cd.customer_id(+)

group by c.customer_id,

c.customer_name;

• Full Outer Joins – Este utilizat ca o extensie a joncţiunilor la dreapta şi la stânga

(left joins şi right joins). Se aplică după ce se realizează o joncţiune internă şi se

adaugă toate înregistrările neselectate din ambele tabele inclusiv valorile null.

Optimizarea joncţiunilor multiple

Până acum am analizat cazurile de joncţiune între două tabele în care pentru

optimizare era aleasă automat ca tabelă pivot tabela cu cele mai puţine înregistrări şi

cealaltă tabelă era scanată pentru jocţiune.

Modalitatea de optimizare a joncţiunilor multiple constă în optimizarea fiecărei

joncţiuni separat dar şi combinarea rezultatelor parţiale astfel încât costul final să fie cât

mai mic. O joncţiune multiplă se poate executa în două variante: liniar şi paralel

(arborescent) [CHAU98] :

117

6.6. Joncţiune liniară versus joncţiune arborescentă

Planul de execuţie va lua în considerare variantele optimizate de execuţie ale

combinaţiilor dintre joncţiuni. De exemplu, pentru a optimiza un join multiplu între A, B,

C, D sau J(A,B,C,D) se vor lua în considerare optimizările dintre:

J (A, J(B, J(C,D))) sau J(A, J(C, J(B,D))) sau J(B, J(C, J(A,D))) etc.

În cazul în care sunt implicate mai multe tabele ordinea de execuţie este şi ea

optimizată, în sensul că pe baza statisticilor realizate se aleg mai întâi tabelele cu un număr

mic de înregistrări şi apoi se parcurg pentru formarea rezultatului şi celelalte tabele.

De exemplu, dacă în condiţia de joncţiune se precizează următoarea relaţie:

A.a=B.b and B.b=C.c and C.c=D.d

atunci pentru optimizare se va ţine cont de nmărul de înregistrări implicate în

condiţie. Astfel, dacă a<b<c<d atunci ordinea de execuţie a joncţiunilor va fi: A.a=B.b and

B.b=C.c and C.c=D.d, dacă însă a>b>c>d atunci ordinea de execuţie va fi schimbată în:

D.d=C.c and C.c = B.b and B.b=A.a.

Dacă statisticile nu indică automat o ordine de execuţie atunci aceasta se poate

indica prin două directive: ORDERED şi LEADING.

Directiva ORDERED indică execuţia joncţiunilor exact cum apar în instrucţiune.

Este recomandat însă să se tină cont de dimensiunile şi de cardinalităţile tabelelor,

condiţiile de joncţiune să implice mai întâi tabelele cu cardinalităţi mici şi apoi progresiv

tabelele cu cardinalităţi din ce în ce mai mari. Intâi se va estima numărul de înregistrări din

fiecare tabelă implicate în cerere şi apoi se va stabili ordinea de joncţiune. Pentru

exemplele următoare statisticile sunt:

TABELA NR DE ÎNREGISTRĂRI

UNITATI 30

COMEZI_DESFACERE 86

CLIENTI 262

118

PRODUSE 2379

Tabel 6.1. Statistici referitoare la numărul de înregistrări ale tabelelor

În acest caz, ordinea de joncţiune trebuie să fie aceeaşi cu ordinea din tabel. In

continuare voi aplica directiva ORDERED pentru a indica respectarea acestei ordini de

execuţie:

Select /*+ordered*/ cd.*

From comenzi_desfacere cd

, unitati u

, clienti c

, produse p

Where

P.category_set_name='CONTABIL'

And u.inventory_organization_id=cd.inventory_organization_id

And cd.ship_id=c.ship_id and cd.customer_id=c.customer_id

And cd.inventory_organization_id=p.organization_id and

cd.inventory_item_id=p.inventory_item_id

Directiva LEADING (t1 t2 ..) se utilizează pentru a indica o anumită ordine de

execuţie precizată prin tabelele t1, t2, etc. Se recomandă utilizarea acestei clauze şi nu a

clauzei ORDERED deoarece este mai versatilă şi indiferent de ordinea de scriere a

joncţiunilor instrucţiunea se execută în modul specificat. De exemplu:

Select /*+leading (u cd c)*/ cd.*

From comenzi_desfacere cd

, unitati u

, clienti c

, produse p

Where

p.category_set_name='CONTABIL'

And cd.inventory_organization_id=p.organization_id

And cd.inventory_item_id=p.inventory_item_id

And u.inventory_organization_id=cd.inventory_organization_id

And cd.ship_id=c.ship_id and cd.customer_id=c.customer_id

119

Directiva INDEX sau NO_INDEX poate fi utilizată cu rezultate bune dacă se

introduce un criteriu de selecţie pe coloanele indexate şi dacă numărul de înregistrări

rezultate prin aplicarea acestui criteriu nu depăşeşte 20% din numărul total de înregistrări

ale tabelei. De exemplu prin introducerea unui filtru pe customer_id =1163 se obţin 8

înregistrări din totalul de 86, aproximativ 10%, deci aplicarea directivei INDEX (CD

CD_C_ID_IDX) va conduce la obţinerea unui cost de execuţie mai mic:

Figura 6.7: Directiva INDEX ( ) aplicată pe joncţiuni multiple

Directivele STAR_TRANSFORMATION şi FACT (tabela) permit

transformarea unei interogări obişnuite într-o interogare multidimensională prin precizarea

tabelei de fapte şi joncţiunea acesteia cu celelalte tabele dimensiuni. Oracle evaluează

costul execuţiei cererii normale şi a cererii transformate şi dacă se consideră că prin

aplicarea directivei se obţine un rezultat mai bun atunci aceasta se aplică, altfel se ignoră.

Select /*+ STAR_TRANSFORMATION */ cd.*

From comenzi_desfacere cd

, unitati u

, clienti c

, produse p

Where

P.category_set_name='contabil'

And u.inventory_organization_id=cd.inventory_organization_id

120

And cd.ship_id=c.ship_id and cd.customer_id=c.customer_id

And cd.inventory_organization_id=p.organization_id and

cd.inventory_item_id=p.inventory_item_id

Select /*+ FACT (cd) */ cd.*

From comenzi_desfacere cd

, unitati u

, clienti c

, produse p

Where

P.category_set_name='contabil'

And u.inventory_organization_id=cd.inventory_organization_id

And cd.ship_id=c.ship_id and cd.customer_id=c.customer_id

And cd.inventory_organization_id=p.organization_id and

cd.inventory_item_id=p.inventory_item_id

6.2.3. SOLUŢII DE OPTIMIZARE A CERERILOR CU FUNCŢII DE

AGREGARE ŞI OPERAŢII DE ORDONARE

Optimizarea cererilor care conţin clauzele ORDER BY şi GROUP BY se poate

obţine dacă ordonarea şi agregarea respectivă se realizează direct pe coloanele tabelelor,

fără a introduce expresii şi dacă coloanele implicate în aceste operaţii sunt deja indexate

[ORA10G].

De exemplu, cererea următoare foloseşte în criteriul de agregare şi de ordonare

coloana ORDERED_DATE pe care deja există index, ceea ce conduce la obţinerea unui

cost de execuţie de numai 20 de unităţi:

121

Figura 6.8: Optimizarea pe clauzele ORDER BY şi GROUP BY

Modalitatea de execuţie a cererilor din sistemele care utilizează depozite de date

este deosebit de importantă pentru a obţine performanţa întregului sistem şi pentru

micşorarea timpului de răspuns a rulării rapoartelor de analiză. Factorii relevanţi pentru

obţinerea acestor performanţe sunt legaţi atât de resursele fizice implicate (CPU,

memorie, I/O), de modalitatea de organizare, stocare şi procesare a datelor (prin

procesare paralelă, clusterizare, partiţionare) dar şi prin modul de execuţie a

interogărilor, mai ales în cazul joncţiunilor multiple foarte des întâlnite în cazul analizelor

multidimensionale.

Obţinerea şi studierea statisticilor referitoare la tabelele implicate, obţinute cu

ajutorul pachetului DBMS_STATS şi utilizarea corespunzătoare a directivelor de execuţie

pot duce la creşterea performanţei şi a micşorării timpilor de execuţie a sistemelor

informatice care utilizează depozite de date şi analize multidimensionale.

122

CAPITOLUL VII – SOLUŢII DE DEZVOLTARE A SISTEMELOR

INFORMATICE EXECUTIVE

7.1. CICLUL DE DEZVOLTARE A SISTEMELOR INFORMATICE

EXECUTIVE

Cerinţele de realizare a sistemelor informatice executive necesită modele de analiză

şi proiectare diferite, abordări specifice ale ciclului de dezvoltare care să se concentreze pe

cerinţele de afaceri ale sistemului de realizat. Voi prezenta în continuare câteva aspecte ale

modelării sistemelor informatice executive, propunând un ciclu de dezvoltare specific

precum şi posibilitatea adaptării şi extinderii metodologiilor existente pentru analiza şi

proiectarea cerinţelor sistemelor informatice executive.

7.1.1. FAZELE DE DEZVOLTARE A SISTEMELOR INFORMATICE

EXECUTIVE

Studiul pentru implementarea unui sistem informatic executiv implică şase faze

principale corelate cu etapele ciclului de dezvoltare. Aceste faze se pot aplica tuturor

organizaţiilor şi pot fi descrise pe larg astfel:

Faza I - Evaluarea

Prima fază implică realizarea unui process de evaluare a domeniului, a cerinţelor

preliminare, a consultanţilor care vor lua parte la proiectarea unui sistem informatic

executiv şi ar trebui să se bazeze pe experienţele anterioare legate de implementarea

particularităţilor sistemelor informatice executive în domeniul în care va fi implementat

sistemul.

La acest nivel, evaluarea nu se aplică unui sistem particular şi nu este posibilă încă

proiectarea unei soluţii de sistem informatic executiv şi nu se poate vorbi de o arhitectură

anume sau de un produs software, însă sunt luate în calcul posibilităţile de realizare ale

sistemului.

Faza II - Studiul cerinţelor de afaceri

In cea de-a doua fază un sondaj corespunzator şi un studiu de fezabilitate ar trebui

să identifice soluţia potrivită care va fi discutată cu conducerea organizaţiei. Se va realiza

un prototip care ar trebui să implementeze câteva din funcţionalităţile mai importante

pentru cerinţele managerilor, iar aceştia ar trebui să fie implicaţi în realizarea prototipului.

Vor fi selectate în această fază hardware-ul şi software-ul prototipului conform cu

cerinţele specificate de echipa proiectului. Selecţia acestor componente nu ar trebui

123

considerată ca fiind definitivă, deoarece se pot produce schimbări în arhitectura sistemului

şi chiar în tehnologia de lucru. In ceea ce priveşte interfaţa cu utilizatorul, se pot realiza

machete pentru videoformate şi meniuri, iar unde este posibil vor fi utilizate biblioteci de

interfaţă din pachete software predefinite.

Este necesar la acest nivel sa evaluăm acurateţea datelor. Majoritatea sistemelor

informatice executive vor implementa rutine de extragere a datelor din surse diferite având

o calitate a datelor mai mult sau mai puţin propice procesului de analiză.

In acest punct este important să se realizeze şi o planificare a proiectului, incluzând

costurile şi succesiunea în timp a activităţilor. Aceasta va oferi termene clare de referire

pentru proiect şi ar trebui sa includă scopul prototipului, detalii despre activităţi, beneficii,

costuri şi un rezumat cost-beneficiu.

Faza III - Elaborarea şi introducerea prototipului

Pe baza cerinţelor şi a arhitecturii stabilite în faza anterioară se proiectează un

prototip al viitorului sistem. Cu toate că la acest nivel datele nu vor fi colectate din toate

sursele organizaţiei, totuşi funcţionalitatea întregului sistem ar trebui să fie reflectată în

proiectarea interfeţei, pentru ca viitori utilizatori sa aibă o viziune reală asupra a ceea ce se

va realiza. Pentru prototip este posibil scoaterea în evidenţă a structurii de raportare

informaţională existentă.

Prototipul realizat este prezentat pentru evaluarea preliminară conducerii

organizaţiei. Dacă este necesar, informaţiile adiţionale, din bazele de date externe pot fi

adăugate la datele interne şi istorice, utilizate. Datele ar trebui verificate pentru a se asigura

corectitudinea, relevanţa rapoartelor şi graficelor.

Faza IV – Revizuirea avantajelor prototipului

La acest nivel, un studiu formal cost-beneficiu este extrem de important. Acest

studiu se va realiza pe baza rezultatelor estimate prin validarea prototipului. Se ţine cont şi

de îmbunătăţirile ulterioare aduse prototipului prin introducerea altor funcţiuni

suplimentare sau prin includerea în arhitectura sa şi a altor surse relevante de date.

Structura şi funcţiile prototipului ar trebui să fie revizuite pentru a determina

strucura datelor organizaţiei. Dacă prototipul a avut succes şi a fost validat, managerii

executivi vor fi de acord cu expandarea proiectului prin introducerea cât mai multor

funcţionalităţi, precum şi a unei modalităţi de includere şi procesare a unor surse externe

de date.

124

Faza V – Implementarea funcţionalităţilor sistemului EIS

In funcţie de rezultatele obţinute în urma introducerii prototipului s-ar putea să fie

necesare schimbări generale în cadrul funcţiunilor acestuia, incluzând chiar posibilitatea de

a reconstrui din nou prototipul cu o structură diferită în funcţie de cerinţele organizaţiei.

Se realizează transformarea şi încărcarea datelor din toate sursele necesare, se

proiectează rapoartele, machetele şi graficele dorite şi se finalizează procedurile de acces la

date şi de analiză a acestora.

Trebuie tratate şi problemele legate de integritatea, siguranţa şi conţinutul datelor

ce vor fi utilizate în sistem. Integritatea datelor înseamnă capacitatea de a stabili exact atât

înţelesul şi situaţiile în care sunt utilizate datele, cât şi capacitatea de a rezolva o situaţie în

care departamente diferite produc date contradictorii care pot duce la o interpretare greşită.

Datele sunt distribuite de-a lungul unei categorii largi de aplicaţii şi de dispozitive

de stocare şi procesare. Pentru a obţine un conţinut relevant al datelor, informaţiile

detaliate din aceste surse trebuie integrate, prelucrate şi agregate într-un depozit de date.

Faza VI – Transferarea capacităţilor sistemului în cadrul organizaţiei

Pregătirea şi susţinerea sesiunilor de instruire pentru manageri ar putea fi una din

etapele cele mai dificile ale întregului proiect. Ar trebui realizată documentaţia pentru toate

procedurile de operare pentru fiecare tip de utilizator. Documentaţia ar trebui să fie

completată permanent, chiar şi după ce au fost realizate schimbari structurale sistemului.

Alte probleme ale implementării ar fi cele legate de organizarea şi managementul

firmei, eventualele restructurări ale organizaţiei reprezentând o provocare mai mare decât

aspectele pur tehnice de instalare a unui sistem informatic executiv. Convingerea acestora

de a-şi schimba modul de obţinere a informaţiilor a fost de asemenea subliniată ca un

domeniu problematic.

7.1.2. ETAPE ALE CICLULUI DE DEZVOLTARE A SISTEMELOR

INFORMATICE EXECUTIVE

In lucrarea [MOAT04] autorii propun o serie de etape de realizare pentru sistemele

informatice de inteligenţa afacerilor şi anume: studiul de fezabilitate, planificarea

proiectului, analiză, proiectare, dezvoltare, implementare, etape ilustrate în figura 7.1.

125

Fig. 7.1: Ciclul de dezvoltare al sistemelor informatice pentru inteligenţa

afacerilor

Aceste etape se pot adapta şi aplica şi sistemelor informatice executive, dar în

cadrul ciclului de dezvoltare trebuie tratate în mod obligatoriu diferenţele majore existente

între modelarea sistemelor executive şi cea a sistemelor informatice decizionale pentru a

obţine o implementare de succes a cerinţelor de afaceri specifice. Aceste diferenţe au fost

prezentate pe larg în primul capitol al acestei lucrări, însă referitor la ciclul de dezvoltare

pot fi precizate umătoarele caracteristici:

• Sistemele informatice executive sunt orientate mai mult spre oportunităţile de

afaceri decât spre cerinţele sau nevoile curente şi trebuie să implementeze

strategiile întregii organizaţii şi nu decizii la nivelul fiecărui departament;

• Nivelul suportului decizional oferit de EIS trebuie să ofere informaţii strategice

şi nu informaţii şi cerinţe strict operaţionale sau tactice;

• Analiza trebuie să fie concentrată spre cerinţe de business şi nu spre o analiză a

sistemului existent. Aceasta etapă de analiză este cea mai importantă din cadrul

întregului ciclu de dezvoltare;

• Ciclul de dezvoltare este iterativ, orientat spre evaluarea şi îmbunătăţirea

versiunilor succesive şi nu spre o livrare de proporţii ale unei singure versiuni

(fig 7.1).

Tot în lucrarea [MOAT04] autorii propun în cadrul celor 6 etape majore şi 16

subetape specifice ilustrate în figura 7.2. Aceste etape şi subetape pot fi aplicate ca şi

cadru de dezvoltare şi la realizarea sistemelor informatice executive, dar aşa cum am

Ciclul de

dezvoltare

Etapa 1: Studiul de fezabilitate

Etapa 2: Planificarea

Etapa 3: Analiza cerinţelor de afaceri

Etapa 4: Proiectarea

Etapa 5: Dezvoltarea

Etapa 6: Implementarea sistemului

Evaluarea versiunii curente

126

precizat anterior, trebuie să se ţină cont de toate aceste diferenţe şi caracteristici ale EIS-

urilor.

Fig 7.2: Etapele ciclului de dezvoltare a Sistemelor Informatice Executive

Studiul de fezabilitate

1. Evaluarea oportunităţilor de realizare

Planificare 2. Evaluarea infrastructurii intreprinderii

3. Planificarea proiectului

Analiza cerinţelor de afaceri

4. Definirea cerinţelor

5. Analiza datelor

6. Realizarea prototipului

7. Analiza metadatelor

Proiectare

8. Proiectarea datelor

9. Proiectarea procesului ETL

10. Proiectarea metadatelor

Dezvoltare

12. Realizarea aplicaţiei

14. Realizarea metadatelor

11. Realizarea procesului ETL

13. Extragerea cunoştinţelor

Implementare 15. Implementarea

16. Evaluarea sistemului

127

Etapele ciclului de dezvoltare nu presupun o parcurgere întocmai, unele subetape se

pot realiza în paralel de către echipe distincte de lucru, însă există o înlănţuire şi o

dependenţă între etape (aşa cum am prezentat în fig. 7.2).

Cadrul de dezvoltare propus în lucrarea [MOAT04] destinat sistemelor informatice

de inteligenţa afacerilor poate fi adapat şi modificat pentru realizarea sistemelor

informatice executive, ţinând cont la fiecare etapă şi subetapă de particularităţile acestora.

În continuare voi prezenta pe fiecare subetapă în parte aceste caracteristici precum şi

obiectivele şi activităţile care trebuie realizate pentru dezvoltarea cu succes a unui sistem

informatic executiv. Aceste activităţi au fost sintetizate anterior şi în articolul [BALU05] şi

vor fi prezentate pe larg în cele ce urmează:

Etapa 1: Studiul de fezabilitate

Pas 1: Evaluarea oportunităţilor de realizare - în acest pas sunt identificate

cerinţele şi oportunităţile de afaceri şi se propune o soluţie. Fiecare soluţie propusă este

justificată prin prisma costurilor şi beneficiilor implicate.

Se iau în considerare următoarele componente:

• Identificarea cerinţelor de afaceri - presupune stabilirea cerinţelor strategice de

afaceri ale managerilor care se pun în corelaţie cu obiectivele sistemului EIS;

• Analiza cerinţelor de afaceri - se identifică principalele resurse informaţionale

care vor fi utilizate în aplicaţie în funcţie de cerinţele identificate mai sus;

• Analiza cost-beneficiu - se estimează costurile implicate în dezvoltarea unui

sistem executiv comparativ cu beneficiile tangibile aduse de acesta. Sunt însă şi

unele beneficii care nu pot fi măsurate şi care vizează imaginea sau extinerea

organizaţiei în alte domenii de activitate, dar aceste beneficii pot fi apreciate ca

având un impact pozitiv asupra firmei;

• Factorii de risc - sunt identificaţi principalii factori de influenţă în funcţie de

tehnologie, complexitate, modalitatea de integrare, organizaţie, echipele de proiect

şi investiţii financiare. In lucrarea [MOAT04] este propusă o matrice în care sunt

prezentate variabilele de risc, condiţiile în care acestea sunt declanşate şi nivelul de

risc produs. Autorii identifică trei nivele de risc: minim, mediu şi maxim, iar în

funcţie de nivelul rezultat în urma analizei matricei se poate recurge la realizarea

sau la abandonul proiectului curent sau se pot identifica factorii negativi şi găsi

soluţii pentru eliminarea acestora.

128

Factori Risc minim Risc mediu Risc maxim

Tehnologie Experienţă în

domeniul

tehnologiilor din

domeniul

inteligenţei

afacerilor

Experienţă redusă

în domeniul

tehnologiilor din

domeniul

inteligenţei

afacerilor

Lipsă totală de

experienţă în

domeniul

tehnologiilor din

domeniul

inteligenţei

afacerilor

Complexitatea

sistemului

Moderată, fără un

impact semnificativ

în cadrul

organizaţiei

Moderată, dar cu

un impact crescut

în cadrul

organizaţiei

Ridicată, necesită

schimbări majore în

cadrul organizaţiei

Integrare Surse integrate,

standarde unitare,

sistemul va utiliza

aceste surse direct

Surse diverse, dar

cu posibilitatea de

integrare uşoară

Surse diverse,

procesul de

integrare este

anevoios, necesitând

resurse mari

Organizare Suport mare din

partea organizaţiei

Organizaţia acordă

sprijin dezvoltării

priectului, dar în

anumite condiţii

Spijin condiţionat de

anumite aspecte

Echipa de

proiect

Are experienţă

bogată şi

determinare,

atitudine pozitivă şi

implicare

Are experienţă şi

determinare,

atitudine şi

implicare

Nu au experienţă în

realizarea

sistemelor, iar

atitudinea este

indiferentă

Investiţia

financiară

Profit estimat într-

un timp scurt

Profit estimat într-

un timp mediu

Profit estimat într-

un termen lung

Tabel 7.1. – Tipuri de risc determinate de factorii principali identificaţi în studiul de

fezabilitate

La sfârşitul acestui capitol am propus o serie de criterii de identificare şi analiză a

factorilor critici care pot influenţa succesul realizării unui sistem informatic executiv pe

fiecare subetapă, inclusiv în această etapă.

129

Rezultatul acestei subetape se concretizează într-un raport de analiză în care sunt

prezentate cerinţele şi oportunităţile de afaceri, analiza cost – beneficiu, se propun

variante de soluţii şi se prezintă principale elemente de risc pentru fiecare variantă.

Etapa 2: Planificarea proiectului

Pas 2: Evaluarea infrastructurii organizaţiei – Sunt evaluate posibilităţile de

susţinere ale proiectului, sunt identificate componentele de infrastructură existente dar şi

necesităţile ulterioare.

Infrastructura unei organizaţii este formată din 2 tipuri de componente:

1) Infrastructura tehnică – conţine elemente de hardware, software, middleware,

sistemele de gestiune a bazelor de date, sisteme de operare, componente de reţea, utilitare

diverse, dicţionare de metadate, etc;

Aceasta poate fi analizată pe trei nivele:

• Platforma hardware – aceasta trebuie să facă faţă cerinţelor de access la date,

volumul acestora, sistemele de operare şi instrumentele software necesare, numărul

de utilizatori implicaţi în sistem, să fie usor de întreţinut şi de adaptat unor cerinţe

şi funcţionalităţi ulterioare.

• Platforma middleware – aceasta se referă la sisteme de tipul runtime, care se

regăsesc între nivelul aplicaţie şi sistemele de operare. Cerinţele impuse platformei

middleware sunt legate de capacitatea lucrului ditribuit şi de conectivitatea şi

posibilitatea de integrare între diferite tipuri de aplicaţii.

• Platforma sistemelor de gestiune a bazelor de date – este nivelul SGBD-urilor,

sunt evaluate criteriile de alegere a unui SGBD în funcţie de performanţele acestuia

şi de cerinţele de acces şi prelucrare a datelor. Se iau în considerare următoarele

elemente: prelucrarea paralelă, scalabilitatea, modelul de date utilizat, prelucrarea

on-line, facilităţile de replicare pe diferite platforme, transparenţa prelucrarii,

independenţa datelor faţă de aplicaţii şi de platformele utilizate, nivelul de

securitate.

Rezultatul acestei evaluări îl constituie un raport în care sunt prezentate

infrastructura existentă şi propuneri de soluţii pentru noul sistem.

2) Infrastructura nontehnică – include standarde referitoare la metadate, codificări,

metodologii, recomandări, proceduri de testare, de control, politici de securitateetc;

Este analizată şi construită arhitectura organizaţiei în funcţie de modelul proceselor,

al functiilor, al datelor, al rolurilor fiecarui departament şi angajat implicat în sistem. Sunt

130

specificate standardele existente referitoare la securitate, calitatea datelor, procedurile de

control, back-up şi testare, codificarea datelor.

Infrastructura tehnică şi nontehnică vizează arhitectura întregii organizaţii, inter-

departamentale şi integrează toate componentele tehnice, funcţionale, modele, date,

aplicaţii care vor susţine realizarea proiectului (fig. 7. 3)

Fig. 7.3. Arhitectura organizaţiei

Pas 3: Planificarea proiectului – sistemele executive implică o dinamică deosebită

a proiectelor informatice, în derularea acestora au loc o serie de schimbări de mediu,

schimbări de tehnologie, de personal implicat atât din partea echipei de consultanţi şi

dezvoltatori IT cât şi din partea referenţilor de afaceri. In aceste condiţii planificarea unui

proiect de tipul EIS trebuie realizată detaliat, progresiv, fiecare etapă şi fază în parte având

documente de control şi raportare, după cum urmează:

1) Definirea proiectului, a obiectivelor şi scopului acestuia:

• Definirea şi detalierea factorilor de risc identificaţi în prima etapă;

• Identificarea constrângerilor proiectului – sunt cinci elemente de contrângere:

timp, scop (obiectiv), buget, resurse, calitate, după cum se poate observa în tabelul

7.2.

Constrângere Prioritate

(scăzută ���� crescută)

Business Business Business Business Business Business Business

Mar

keti

ng

Fin

acia

r

Pro

ducţ

ie

Cli

enţi

Apr

oviz

iona

re

Vân

zări

Sto

curi

IT IT IT IT IT IT IT

Mediul Operaţional Mediul Decizional, EIS

ARHITECTURA ORGANIZATIEI Coordonare, Integrare, Documentare, Conducere

131

1 2 3 4 5

Efort (timp) v

Scop v

Buget v

Resurse v

Calitate v

Tabel 7.2. Elementele de constrângere din cadrul proiectului

• Procedurile de control al modificărilor intervenite pe parcursul proiectului.

Datorită complexitatii unui proiect de tipul EIS pot apare schimbări şi trebuie

prevăzute modalităţile de intervenţie şi control a acestora: modificări ale timpului

de execuţie, repartizarea altor resurse, eliminarea unor proceduri dificile şi a

impactului negativ pe care il pot aduce aceste modificări.

2) Planificarea detaliată a proiectului include următoarele elemente:

• Estimarea şi planificarea activităţilor;

• Planificarea resurselor;

• Identificarea dependenţelor între activităţi;

• Identificarea dependenţelor între reurse;

Pentru planificarea detaliată se pot utiliza tehnici diverse de planificare ca: metoda

drumului critic, grafice de tipul Gantt, etc.

Rezultatul acestor activităţi se concretizează în planul proiectului. După validarea

şi aprobarea sa se trece la demararea efectivă a acestuia.

Etapa 3: Analiza cerinţelor de afaceri

Pas 4: Definirea cerinţelor sistemului – sunt detaliate şi analizate cerinţele iniţiale

ale conducerii organizaţiei. De obicei cerinţele se identifică pe baza interviurilor organizate

cu managerii şi personalul implicat în proiect. Acestea se pot schimba pe parcursul

proiectului, însă echipa de realizare trebuie să informeze managerii organizaţiei despre

posibilităţile şi limitările unui sistem informatic tocmai pentru a reduce apariţia unor

cerinţe irealizabile din partea acestora.

In principal cerinţele se pot grupa pe categorii sau tipuri, astfel:

• Cerinţe funcţionale – vizează tipul de informaţii cerute, rapoarte, interogări,

instrumente de analiză şi departamentele care vor furinza aceste tipuri de raportări;

• Cerinţe referitoare la date – sunt precizate sursele şi calitatea datelor, nivelul

de detaliere, timpul de procesare, modalităti de prelucrare;

132

• Cerinţe referitoare la perioada datelor – se pun două probleme majore: care

este perioada istorică de analiză a datelor şi din ce moment se incepe această

perioadă: data curentă sau se importă datele din perioade anterioare din aplicaţiile

existente;

• Cerinţe de securitate – se definesc rolurile utilizatorilor, nivelul de acces la

date, procedurile de control ale accesului;

• Cerinţe de performanţă – este luat în considerare timpul de răspuns al

sistemului, timpul de acces la date, modalităţile de rulare a rapoartelor (pe timpul

zilei sau noaptea), existenţa unor rapoarte critice care necesită cereri ad-hoc.

Cerinţele pot fi structurate şi în funcţie de specificul proiectelor în: cerinţe generale

în care se precizeaza caracteristici şi obiective valabile pentru toate tipurile de sisteme EIS

şi cerinţe specifice proiectului în funcţie de fiecare organizaţie (tabelul 7. 3).

Cerinţe generale Cerinţe specifice

Scop

Determinarea cerinţelor de

afaceri ale organizaţiei

Definirea funcţiilor şi datelor

specifice care vor fi livrate la

sfârşitul proiectului

Inte

rviu

ri

Participanţi la interviuri:

• Managerii executivi

• Directorii IT

• Personalul IT

• Manageri departamentali

• Experţi în domeniile de

interes

Participanţi la interviuri:

• Managerii executivi şi

reprezentanţi ai organizaţiei

• Acţionari

• Directorii IT

• Analişti şi programatori

experimentaţi

• Experţi

Rez

ulta

te

Raportul cerinţelor de afaceri:

• Consideraţii generale

• Oportunităţi

• Recomandări

• Paşi de urmat

Documentaţia cu cerinţele

aplicaţiei:

• Cerinţe funcţionale

• Cerinţe referitoare la date

• Cerinţe de securitate

• Cerinţe de performanţă

• Alte cerinţe

Tabelul 7.3. – Tipuri de cerinţe identificate în cadrul proiectelor EIS

133

Pas 5: Analiza datelor – cea mai mare provocare a unui proiect EIS o constituie

stabilirea surselor corecte de date. Aceasta subetapă este cea mai mare consumatoare de

timp din tot proiectul şi constă în identificarea datelor necesare, analiza conţinutului

acestora şi modul în care se relaţionează.

Analiza datelor este axată pe analiza de business şi nu pe analiza de sistem ca în

metodologiile tradiţionale şi în plus acest proces se desfăşoară pe două direcţii princiale şi

complementare:

1) Analiza datelor de sus în jos (top – down) pentru aspectele referitoare la

integrarea şi consistenţa datelor şi presupune realizarea modelului logic al datelor la nivelul

organizaţiei, relaţiile între acestea şi modalităţile de integrare a modulelor şi surselor

existente. Cea mai bună reprezentare a modelului logic o reprezintă tehnica entitate –

asociere (modelul E-R). Se recomandă decompunerea modelului pe nivele, astfel se vor

realiza diagramele ER pe fiecare modul existent, pe fiecare proiect şi se vor integra aceste

modele la nivelul întregii organizaţii obţinându-se astfel modelul logic al întrepriderii.

Modelarea datelor prin tehnica entitate - asociere se realizează ţinând cont de

independenţa datelor faţă de aplicaţii, platformele utilizate, instrumente software, SGBD-

uri etc. Datele vor fi normalizate şi se va urmări obţinerea unei redundante minime şi

controlate a acestora.

Modelul logic al organizaţiei va urmări şi consistenţa datelor ţinându-se cont de:

• Denumirea datelor – se vor realiza reguli privind denumirile, înlăturarea

sinonimelor, a valorilor incomplete etc;

• Definirea/descrierea datelor – fiecare obiect sau element va avea o descriere

sugestivă, relevantă, prin care să fie perceput scopul utilizării acestora;

• Identificatorii datelor – reguli de formare a acestora (de exemplu prin

secvenţe, autoincrementare, etc);

• Tipul datelor, lungimea câmpurilor şi domeniile de valori;

• Relaţiile dintre date;

• Reguli şi restricţii de integritate;

• Roluri ale utilizatorilor şi drepturi de acces;

2) Analiza datelor de jos în sus (bottom – up) pentru aspectele referitoare la

standardizare şi calitate. Se definesc reguli de conversie a datelor, de integritate şi

referitoare la domeniul de valori. Acest proces este extrem de util pentru etapa de

134

transformare şi încărcare a datelor din surse în modulele destinaţii. Este recomandat să se

realizeze diagramele ER într-o formă simplificată, de ansamblu pentru datele deja existente

în organizaţie, sursele din modulele funcţionale.

3) Curăţarea datelor presupune transformarea şi filtrarea surselor de date pentru a

putea fi utilizate în construirea modulului destinaţie, de analiză. Acest proces se realizează

în următoarele etapele:

• Identificarea datelor necesare din cadrul modulelor funcţionale;

• Analiza conţinutului surselor găsite;

• Selectarea datelor pentru proiect;

• Realizarea specificaţiilor referitoare la filtrarea datelor;

• Selectarea instrumentelor utilizate în procesul de curăţare/filtrare.

In procesul de selectare a surselor trebuie să se ţină cont de câteva aspecte cheie:

integritatea datelor, precizia, acurateţea şi formatul datelor. Aceste aspecte sunt decisive

pentru succesul procesului ETL.

Rezultatele acestei subetape se concretizează în diagramele ER la nivel detaliat, cu

caracteristicile şi proprietăţile fiecărui atribut, modelul logic al întreprinerii şi specificaţiile

referitoare la procesul de curăţare.

Pas 6: Construirea unui prototip iniţial – faza de analiză a sistemului se poate

încheia prin construirea unui prototip care va fi prezentat managerilor pentru validarea

cerinţelor funcţionale. Existenta unor instrumente de dezvoltare rapide permit construirea

unor interfeţe pe baza modelului de analiză. Aceste videoformate şi meniuri ale

prototipului pot fi modificate foarte uşor pentru introducerea şi testarea unor funcţionalităţi

suplimentare.

Un punct important în această subetapă este alegerea tehnologiilor utilizate în

realizarea prototipului şi mai târziu a sistemului final. În baza unei analize comparative a

avantajelor şi dezavantajelor aduse de anumite tehnologii asupra proiectului se poate opta

pentru utilizarea depozitelor de date, pentru includerea funcţionalităţilor OLAP, a unor

algoritmi de extregere a cunoştinţelor, instrumente de integrare a surselor de date sau, în

faza finală, dacă se merge pe o construcţie paralelă a sistemului, pe instrumente de

integrare a aplicaţiilor. Aceste tehnologii şi instrumente au fost deja prezentate în

capitolele anterioare.

Propun câteva recomandări în construirea prototipului:

135

• Limitarea scopului pentru care este construit – este indicat ca prototipul să se

concentreze asupra unor obiective specifice şi cât mai restrânse, cu fucţionalităţi şi

cu un set de date limitate ca dimensiune şi complexitate;

• Inţelegerea cerinţelor referitoare la date să se realizeze încă din primele faze de

dezvoltare;

• Alegerea unui set reprezentativ de date pentru prototip, astfel încat datele

prezentate să fie supuse unui proces relativ scurt de curăţare şi transformare;

• Utilizarea unor instrumente cât mai simple pentru înţelegerea managerilor

astfel încât aceştia să nu fie derutaţi de utilizarea aplicaţiei. Instrumentele să fie

concentrate spre a oferi managerilor cât mai multe şi diverse modalităţti de utilizare

şi analiză;

• Implicarea managerilor să fie activă şi nu doar o simplă prezentare, la testarea

prototipului să participe întreaga echipă managerială implicată şi nu doar o singură

persoană.

Prototipul se poate alege dintre mai multe tipuri în funcţie de proiect: demonstrativ,

şablon, interfaţă, prototip de implementare, prototip operaţional.

In urma demonstării prototipului se realizează un raport în care sunt menţionate

aspectele pozitive şi negative ale prototipului şi se propun soluţii de remediere.

Pas 7: Analiza metadatelor – toate cerinţele identificate vor fi trasformate în

funcţie de structura metadatelor şi stocate într-un dicţionar al metadatelor. Aceste

dicţionare se pot construi cu ajutorul unor instrumente de tip CASE de modelare sau se pot

achiziţiona diverse tipuri de dicţionare existente care pot fi adaptate sau utilizate ca atare.

Un depozit sau dicţionar al metadatelor conţine informaţii contextuale referitoare la datele

implicate în proiect.

Rezultatul etapei este realizarea un meta-model logic al metadatelor organizaţiei

ţinând cont de aceleaşi aspecte ca şi în modelul logic al datelor: standarizare, securitate,

caracteristici fizice şi descriptive. Sunt analizate cerinţele legate de accesul la date, de

interfeţe şi punţi de acces, de integrarea surselor multiple de date.

Pentru modelul metadatelor se pot folosi diagramele ER modificate, de exemplu

modelul generic al metadatelor poate fi realizat ca în figura următoare:

136

Fig. 7.4 – Modelul logic al metadatelor la nivel de organizaţie

Etapa 4: Proiectarea sistemului

Pas 8: Proiectarea bazei de date – datele necesare vor fi stocate atât la nivel

detaliat cât şi la nivel agregat, în funcţie de cerinţele sistemului, din acest motiv se poate

opta atât pentru o stocare a datelor sub formă relaţională, orientată obiect sau

multidimensională. In aceasta subetapă se detaliază şi se rafinează modelul logic al datelor

şi se realizează modelul fizic pentru noul sistem astfel încât să se satisfacă cerinţele de

raportare şi analiză ale managerilor.

Dacă la pasul 5 “Analiza datelor” procesul a fost orientat spre sursele de date (data-

in sau data-entry) provenite din modulele operaţionale, în aceasta etapă se stabilesc ţintele

sau destinaţiile de date (data-out) orientate spre raportări, analize şi interogări. Din acest

motiv se ţine cont de următoarele consideraţii:

• Modulele destinaţie (target databases) sunt proiectate pentru performanţă în raportare,

simplificarea operaţiilor, regăsiri rapide şi de calitate şi nu pe eficienţă în stocare şi

mentenanţă ca sursele de date;

• Nu se pune accentul pe eliminarea sau reducerea redundanţei, însă aceasta

trebuie să fie controlată. Se preferă o redudanţă mai mare în favoarea unei

complexităţi a operaţiilor;

• Datele vor fi stocate astfel încât să fie accesibile în funcţie de cerinţele de

afaceri, iar proiectarea este axată pe acces rapid şi utilitate;

• Pentru a integra toate sursele de date se pot construi tabele virtuale care să

reunească datele din multitudinea de tabele sursă identificate;

Baza de date

Entitate Tabela Index

Atribut Coloana

137

• Nu trebuie inventate sau introduse manual în sistem anumite date, toate datele

din destinaţii trebuie să provină din sursele interne sau externe organizaţiei şi să fie

transformate şi prelucrate. Dacă anumite informaţii nu sunt disponibile în sursele de

date recomand realizarea unor extinderi sau modificări în sistemele operaţionale

existente introducerea, prelucrarea şi stocarea acestor informaţii;

• Se va analiza modul în care vor fi stocate datele, la ce nivel de agregare, astfel

încât sistemul să permită operaţii de drill-down/roll-up rapide, fără a fi necesare

foarte multe operaţii ad-hoc ce pot conduce la creşterea timpului de răspuns.

Activităţile principale ale acestei subetape sunt următoarele:

1) Se realizează modelul logic detaliat al datelor la nivelul organizaţiei pentru

destinaţiile datelor. Modelul logic se concretizează în schemele bazelor de date destinaţii

care pot fi relaţionale sau multidimensionale.

2) Modelul fizic al datelor modeleaza datele din punctul de vedere al opţiunilor de

implementare, de distribuire a datelor, partiţionare, clusterizare, indexare, back-up şi

recuperare a datelor, procesare paralelă.

Datorită acestor considerente recomand ca soluţia aleasă pentru stocarea,

gestionarea şi prelucrarea datelor să o reprezinte un depozit de date centralizat la nivelul

întregii organizaţii. Depozitul de date poate fi împărţit pe criterii logice şi fizice în data

mart-uri la nivel departamental care să fie gestionate mult mai uşor şi care pot fi

proiectate de echipe separate urmând însă aceleaşi specificaţii.

Pas 9: Proiectarea procesului ETL (extragere / transformare / încărcare (load)) –

acest pas este cel mai complex din întregul ciclu de viaţă al proiectului şi depinde în

proporţie mare de calitatea surselor de date.

Recomand integrarea tuturor bazelor de date destinaţie într-un singur mediu şi

construirea procesului ETL pe acest mediu şi nu separat pe fiecare modul destinaţie în

parte pentru a evita astfel crearea unor nivele departamentale distincte şi neintegrate. Se

poate recurge şi la construirea în cadrul aceluiaşi mediu a nivelelor departamentale (data

marts) dar cu condiţia ca acestea să fie deja integrate (fig.7. 5). Important este ca procesul

ETL să fie acelaşi pentru toate nivelele (principiul share one coordinated process).

138

Fig. 7.5. Centralizarea procesului ETL

Proiectarea procesului ETL necesită câteva etape pregătitoare: prelucrarea

preliminară a surselor de date pentru a le aduce la acelaşi format standard şi reconcilierea

datelor şi eliminarea redundanţei şi a inconsistenţei acestora.

Activităţile parcurse în crearea unui proces ETL sunt următoarele:

1) Crearea specificaţiilor de transformare (mapping) a surselor pe destinaţiile

corespunzatoare. Acestea pot fi sub formă de matrice sau diagrame de

transformare.

2) Alegerea şi testarea intrumentelor ETL utilizate. In prezent există o serie de

instrumente de modelare şi implementare a procesului ETL, însă alegerea lor va

depinde de facilităţile oferite şi suportul pentru integrarea surselor diverse în cadrul

aceluiaţi proces de transformare.

3) Proiectarea procesului ETL – se utilizează diverşi operatori de extragere şi

transformare (sortări, agregări, jocţiuni, divizări, etc) în funcţie de modelele de

date. Procesul se poate împărţi în subprocese care se vor rula separat pentru

micşorarea timpului de execuţie. Fluxul de execuţie al procesului se va modela cu

ajutorul diagramelor de flux.

4) Proiectarea programelor ETL care vor fi rulate. Există trei faze de încărcare a

datelor în destinaţii şi pentru care se aplică programe diferite:

• Încărcarea iniţială – popularea iniţială a destinaţiilor cu date operaţionale

curente;

Module sursă integrate

Nivele Data Marts

Producţie HR Comercial Fiananciar

ETL Extragere/Transformare/Incarcare

Producţie HR Comercial Fiananciar

139

• Incărcarea cu date istorice – popularea iniţială a destinaţiilor cu date istorice

arhivate;

• Incărcarea incrementală – încărcarea regulată în destinaţii a datelor curente

provenite din sistemele operaţionale.

5) Alegerea mediului în care va fi rulat procesul ETL – se decide dacă se va utiliza un

server dedicat sau procesul va fi divizat şi va rula descentralizat. Alegerea va

depinde de resursele disponibile şi de timpul de realizare a procesululi, precum şi

de perioadele şi intervalele la care va fi programat să ruleze procesul.

Rezultatele acestor activităţi se concretizează în documentaţia de mapare a datelor,

diagrama sau diagramele de flux ale procesului ETL, documentaţia programelor de

transformare şi specificaţiile de execuţie a procesului.

Pas 10: Proiectarea dicţionarului metadatelor (metadata repository) – dacă

dicţionarul este achiziţionat şi se utilizează un şablon predefinit atunci în această subetapă

se pot aduce mici modificări în funcţie de cerinţele identificate în subetapa de analiză a

metadatelor, însă dacă s-a optat pentru construirea unui dicţionar propriu, atunci se

realizează modelul logic al metadatelor pentru sistemul nou în funcţie de opţiunile de

stocare a datelor: se realizează un model relaţional, orientat obiect sau multidimensional.

Dacă s-a optat pentru construirea unui depozit propriu consider că centralizarea şi

standarizarea acestuia ar fi o soluţie bună pentru o administrare mai uşoară. Un depozit

central la nivelul organizaţiei va fi adaptat cerinţelor impuse de aplicaţiile existente,

astfel:

• Instrumentele CASE utilizează un depozit propriu pentru componentele de

modelare;

• SGBD-urile utilizează dicţionare de date pentru structura datelor şi pentru

gestiunea acestora;

• Instrumentele ETL au un depozit în care se mentin informaţii le referitoare la

maparea datelor;

• Instrumentele de analiză OLAP stochează informaţii referitoare la algoritmii de

analiză, la modelele multidimensionale, raportare şi interogare;

• Instrumentele de data mining necesită un depozit pentru algoritmii de extragere

a cunoştinţelor din date.

140

O soluţie pentru a rezolva problemele de integrare a acestor tipuri de depozite este

fie achiziţionarea unui depozit predefinit, fie adaptarea funcţiilor depozitelor şi

centralizarea acestora pe un singur depozit.

Activităţile realizate în aceasta subetapă se concretizează în modelul logic detaliat

şi modelul fizic al metadatelor.

Etapa 5: Construirea sistemului

Pas 11: Construirea procesului ETL – în realizarea procesului de extragere şi

prelucrare a datelor se pot utiliza diverse instrumente de filtrare, proceduri predefinite etc.

Curăţarea şi transformarea datelor depinde foarte mult de sursele de date şi de calitatea

acestora. Sursele pot fi diverse: fişiere, baze de date, e-mail, internet, surse

neconvenţionale.

Aceasta subetapă este concentrată pe implementarea specificaţiilor programelor

ETL realizate în pasul 9, rularea şi testarea acestora.

Un aspect important îl constituie experienţa echipei de programatori care va realiza

programele de extragere şi trasformare.

Activităţile care se desfaşoară în această subetapă sunt următoarele:

1) Realizarea şi testarea unitară a programelor – se vor realiza programele pentru

cele trei faze de încărcare menţionate la pasul 9: încărcare iniţiala, încărcare

datelor istorice, încărcare incrementală a datelor din surse în destinaţii. Tot în

acest moment se creează şi dicţionarul metadatelor utilizat de utilitarele de

extragere. Toate modulele realizate se vor testa şi se vor corecta erorile care apar.

2) Integrarea programelor şi modulelor de extragere şi transformare – toate

programele realizate şi testate anterior se integrează într-un proces unitar, planificat

şi centralizat la nivelul organizaţiei care se testează şi validează.

3) Testarea performanţelor procesului ETL – deoarece sistemele executive necesită

volume mari de date se recomandă testarea procesului ETL în condiţii reale astfel

încât să se verifice timpul de răspuns şi stabilitatea sistemului, modalităţile de

procesare paralelă. Se simulează comportamentul sistemului în condiţii reale de

lucru.

4) Verificarea calităţii programelor ETL – în majoritatea cazurilor trebuie îndeplinite

condiţiile de asigurarea calităţii impuse de anumite standarde. Programele sunt

verificate de experţi sau de departamentul AQ (Asigurarea Calităţii) existent în

cadrul organizaţiei.

141

5) Verificarea şi acceptarea finală a procesului ETL – dacă toate testele anterioare au

fost trecute şi procesul a fost validat de experţi şi de reprezentanţi ai organizaţiei

atunci se finalizează documentaţia procesului, iar acesta este certificat de

conducerea proiectului.

Rezultatele etapei sunt programele şi bibliotecile de programe de extragere şi

transformare, rezultatele testărilor şi certificatele de calitate obţinute.

Pas 12: Construirea aplicaţiei - după validarea prototipului iniţial, construirea

aplicaţiei poate consta într-o simplă modificare a acestuia din punct de vedere al interfeţei

sau o reconstrucţie a întregului sistem în funcţie de cerinţe şi de complexitatea acestuia. Se

scriu procedurile de acces la date, de validare, de analiză, interfaţa cu utilizatorul etc.

Activităţile sunt:

1) Determinarea cerinţelor finale ale proiectului – pe baza evaluării rezultatelor

prototipului se verifică dacă au apărut cerinţe noi de afaceri, în acest caz se

determină modificările ce trebuie aduse în proiect.

2) Proiectarea aplicaţiilor – se aleg instrumentele pentru realizarea aplicaţiei în

funcţie de cerinţele finale identificate mai sus: instrumente de dezvoltare a

programelor, instrumente de analiză OLAP, de realizare a interfeţelor, a

rapoartelor, instrumente web, etc. şi este realizat un plan de execuţie a acestora.

3) Scrierea şi testarea aplicaţiilor – se realizează programele, se compilează şi se

testează rezultatele obţinute.

4) Testarea funcţionalitţii şi a calităţilor aplicaţiilor – programele realizate anterior se

integrează şi se testează funcţionalitatea şi performanţa sistemului şi se certifică din

punctul de vedere al calitaţii de catre experţii AQ.

5) Realizarea accesului la date şi planificarea sesiunilor de instruire a utilizatorilor –

se identifică persoanele care vor participa la training, perioadele de instruire,

suportul oferit.

Rezultatele acestei etape se concretizează în documentaţia sistemului, planificarea

şi materialele necesare sesiunilor de instruire.

Pas 13: Extragrea cunoştinţelor din date (Data Mining) – deseori succesul unui

sistem executiv este determinat de descoperirea unor noi informaţii şi corelatii între date şi

nu de construirea unor rapoarte în care sunt prezentate datele. Pentru ca aceste cerinţe să

fie indeplinite trebuie aplicate tehnici de data mining, algoritmi de extragere a

cunoştinţelor din datele organizaţiei, cum ar fi: clusterizarea, previziunea, modelele

predictive şi de clasificare.

142

Sunt analizate domeniile de aplicare a tehnicilor de data mining şi algoritmii

specifici care vor fi aplicaţi şi echipele care vor lucra la implementarea acestora.

Activităţile desfăşurate sunt:

1) Stabilirea domeniilor şi a obiectivelor de aplicare a tehnicilor de data mining –

sunt analizate cerinţele specifice care nu pot fi rezolvate prin alte mijloace,

oportunitatea de aplicare a tehnicilor data mining şi modul în care acestea ar

soluţiona aceste probleme.

2) Colectarea datelor – se verifică dacă există deja datele încărcate în destinaţii, dacă

nu se stabilesc noi surse de date şi se revine la paşii anteriori privind proiectarea

datelor.

3) Consolidarea şi curăţarea datelor – se aplică procesele de curăţare a datelor dacă

acestea nu sunt în formatul dorit. Se pot modifica procesele ETL realizate la pasul

11 prin introducerea acestor cerinţe suplimentare.

4) Pregătirea datelor – algoritmii de data mining utilizează paşi pregătitori de

formatare şi încărcare a datelor specifici tehnicilor folosite.

5) Realizarea modelului analitic – se realizează programele de implementare a

algoritmilor de data mining şi specificaţiile pentru etapele de învăţare şi de testare.

6) Interpretarea rezultatelor – în funcţie de cerinţele şi obiectivele stabilite se verifică

dacă rezultatele obtinuţe concordă cu acestea. Se interpretează valorile obţinute şi

se stabileşte dacă acestea pot fi utilizate de către manageri.

7) Validarea rezultatelor – se compară rezultatele obţinute cu cele aşteptate, se

stabilesc deviaţiile şi abaterile pe baza unor statistici sau analize comparative şi

cauzele pentru care aceste deviaţii au apărut. Dacă rezultatele pot fi utilizate atunci

sunt prezentate managerilor pentru valiarea finală.

8) Monitorizarea modelului analitic – se observă perfomanţele modelului pe parcursul

unor perioade de timp stabilite în specificaţii.

In urma aplicării tehnicilor de data mining se obţine baza de date utilizată de

programele repective şi specificaţiile modelului de analiză.

Pas 14: Construirea depozitului metadatelor – dacă s-a optat pentru construirea

unui depozit nou şi nu pentru achiziţionarea unei soluţii predefinite, atunci se formează o

echipă de dezvoltare separată reponsabilă pentru realizarea dicţionarului metadatelor.

Se construiesc şi se adaptează dicţionarele de metadate utilizate de componentele şi

utilitarele sistemului, se integrează, se realizează interfeţele care vor asigura conectarea

143

dintre utilizatori şi dicţionarul centralizat al metadatelor şi dicţionarele utilizate de fiecare

componentă în parte.

Se crează structura dicţionarului şi se încarcă datele conform modelului logic şi

fizic realizat la pasul 10.

Etapa 6: Implementarea sistemului

Pas 15: Implementarea propriu-zisă – este etapa în care se livrează sistemul: se

organizează instructaje de utilizare pentru managerii implicaţi, se asigură suportul tehnic

necesar, se rulează procedurile de încărcare a datelor, de instalare a aplicaţiei, de

monitorizare a performanţelor. Activităţile realizate sunt următoarele:

1) Planificarea implementării – aceasta se face ţinând cont atât de evoluţia de până

acum a proiectului, de termenii contractuali şi de disponibilitatea resurselor

necesare. Sunt planificate: data de lansare a aplicaţiei, managerii implicaţi în

sesiunile de instruire şi validare, personalul şi resursele materiale necesare execuţiei

în bune condiţii a sistemului. Dacă la nivelul organizaţiei sunt necesare schimbări

organizatorice trebuie avut în vedere ca acestea să fie deja planificate şi în curs de

realizare.

2) Pregătirea mediului de producţie – sunt organizate activităţile pentru asigurarea

resurselor necesare rulării proiectului: instalarea bibliotecilor de programe, crearea

bazelor de date, stabilirea drepturilor de acces şi nivelele de securitate, asigurarea

bazei materiale (calculatoare, reţele, servere), instruirea personalului care va fi

responsabil de funcţionarea sistemului, realizarea şi documentarea procedurilor de

back-up, de recuperare a sistemului, finalizarea documentaţiilor proiectului.

3) Instalarea aplicaţiei – se instalează toate modulele aplicaţiei, se încarcă datele în

surse, se pregatesc de execuţie programele ETL, se fac ultimele retuşuri la nivel de

interfeţe.

4) Planificarea execuţiei programelor ETL şi a altor programe şi proceduri automate

– toate programele şi procesele care vor rula automat vor fi setate şi pregătite de

execuţie la anumite perioade şi intervale de timp sau în funcţie de anumite

evenimente.

5) Incărcarea datelor în bazele de date destinaţie – se rulează programele ETL de

încărcare iniţială a datelor curente şi a datelor istorice în destinaţii. Astfel aplicaţia

este pregătită cu date reale şi este gata de a fi utilizată.

6) Pregătirea procedurilor de asistenţă şi suport tehnic – se stabilesc regulile de

acordare a suportului în caz de incidente, modalităţile de realizare a salvării şi

144

recuperării datelor, se realizează un plan de monitorizare a performanţelor, a

modului de utilizare a resurselor, etc.

Etapa se încheie cu intrarea efectivă în producţie a sistemului şi livrarea

utilitarelor şi a documentaţiei finale a proiectului, a manualelor de utilizare şi de

prezentare a aplicaţiei.

Pas 16: Evaluarea sistemului – Se recomandă organizarea unei sesiuni de discuţii

cu managerii implicaţi pentru a trage concluziile finale referitoare la implicaţiile

sistemului, se evaluează costurile, se identifică anumite puncte slabe ale proiectului pentru

a fi înlăturate pe viitor, se fac o serie de recomandări pentru îmbunătăţirea performanţelor.

Se pot face chiar şi o serie de ajustări în proiectul existent dacă acestea nu presupun

modificări majore. Evaluarea sistemului consider că ar trebui să fie un proces continuu,

realizat pe tot ciclul de dezvoltare al sistemului pentru a preveni apariţia unor modificări

finale majore datorate unor schimbări în structura de afaceri a organizaţiei neincluse în

fazele intermediare ale proiectului.

In timp ce unele subetape sunt specifice proiectului şi se realizează independent de

mediul extern, altele necesită o corelaţie între elementele specifice organizaţiei şi proiect şi

o perspectivă de ansamblu asupra organizaţiei. Aceste corelaţii se realizează prin

participarea unor referenţi din partea organizaţiei şi a unor consultanţi specializaţi pe

domeniile de interes care să identifice şi să modeleze cerinţele specifice de afaceri, iar

reprezentanţii organizaţiei să poată valida modelele rezultate. In tabelul 7.4 sunt prezentate

etapele ciclului de dezvoltare şi cerinţele de implicare în proiect:

Etapele ciclului de dezvoltare Implicaţiile la nivelul

organizaţiei/proiectului

1. Evaluarea oportunităţilor de realizare Nivel organizational

2. Evaluarea infrastructurii întreprinderii Nivel organizational

3. Planificarea proiectului Nivel de proiect

4. Definirea cerinţelor Nivel de proiect

5. Analiza datelor Nivel organizational

6. Realizarea prototipului Nivel de proiect

7. Analiza metadatelor Nivel organizational

8. Proiectarea datelor Nivel organizational

9. Proiectarea proceului ETL Nivel organizational

10. Proiectarea depozitului metadatelor Nivel organizational

145

11. Realizarea procesului ETL Nivel organizational

12. Realizarea aplicaţiei Nivel de proiect

13. Extragerea cunoştinţelor din date (Data

Mining)

Nivel organizational

14. Contruirea depozitului metadatelor Nivel organizational

15. Implementarea sistemului Nivel de proiect

16. Evaluarea sistemului Nivel organizational

Tabel 7.4 – Implicaţiile activităţilor desfăşurate în cadrul proiectului

Realizarea modulară şi paralelă a subetapelor ciclului de dezvoltare

După etapele iniţiale ale dezvoltării sistemului (studiul de fezabilitate şi

planificarea proiectului) se pot realiza în paralel subetapele premergătoare etapei de

implementare finală pentru reducerea perioadei de dezvoltare. In lucrarea [MOAT04]

referitor la ciclul de dezvoltare al sistemelor de inteligenţa afacerii se disting trei direcţii

principale care pot fi realizate în paralel (fig. 7. 6):

Fig. 7.6: Realizarea în paralel a etapelor ciclului de dezvoltare

2. A

plic

atţa

1

2 3 4

5

9

11

6

8

12

13

7

10

14

16 15

3. M

etad

ate

1. P

roce

sul E

TL

146

1. Procesul ETL (extragere / transformare / încărcare) – acest proces este referit

deseori ca un proces ascuns utilizatorilor finali (un proces de back-end). Scopul său este de

a analiza şi proiecta un model de curăţare, prelucrare şi încărcare a datelor din sursele

disponibile în bazele de date utilizate de aplicaţia finală. Procesul este unul destul de

complicat datorită surselor multiple de date, a calităţii acestora, a codificării diferite şi

necesită aplicarea unor proceduri şi algoritmi specifici.

In construirea modelului ETL se pot utiliza o serie de instrumente de modelare a

transformării datelor. Echipa implicată în realizarea acestui proces trebuie să fie foarte

experimentată, se poate apela şi la consultanţi externi cu mai multă experientă. Aceştia pot

fi administratori de baze de date, programatori experimentaţi (senior programmers),

analişti şi consultanţi pe probleme de afaceri.

Succesul întregului proiect depine de modul în care acest proces este realizat, chiar

şi cele mai puternice intrumente de analiză de tipul OLAP sau algoritmi de Data Mining nu

pot oferi rezultatele şi performanţele dorite dacă datele sunt utilizate necorespunzator şi

calitatea acestora este îndoielnică.

2. Construirea aplicaţiei – acesta este un proces vizibil şi pentru utilizatorii finali

(un proces de front-end), scopul său fiind acela de a proiecta şi realiza accesul la date prin

intermediul interfeţei şi a unor proceduri şi algoritmi de analiză. Punctele cheie de care

trebuie tinut cont sunt oferirea de informaţii suplimentare managerilor prin intermediul

aplicaţiei şi oferirea unui acces simplu la datele organizaţiei.

Echipa implicată în aceste etape este formată din programatori şi analişti

specializaţi în instrumentele de tipul OLAP, web, client-server, data mining.

3. Construirea depozitului metadatelor – procesul presupune analiza, proiectarea şi

construirea modelului metadatelor în cadrul unui dicţionar (repository), precum şi

realizarea interfeţelor de acces la date şi posibilităţile de interogare şi raportare a acestora.

Se realizează schema bazei de date în funcţie de modelul ales (relaţional, orientat obiect,

multidimensional). Echipa responsabilă de aceste etape este formată în special din

administratori ai bazelor de date şi de programatori experimentaţi.

Aceste trei direcţii de realizare paralelă pot fi considerate subproiecte distincte care

au personal şi activităţi proprii, dar care interacţionează şi se influenţează reciproc.

Depedenţele sunt prezentate în figura 7.6. Fiecare subproiect are ieşiri proprii după cum

urmează:

147

Procesul Ieşiri

Procesul ETL Incărcarea datelor în bazele de date destinaţie

Procesul de construire a aplicaţiei Realizarea interfeţei, a rapoartelor şi

interogărilor

Procesul de proiectare a

dicţionarului

Definirea şi realizarea schemei metadatelor

Echipele implicate în realizarea proiectului pot fi formate din personal propriu sau

resurse externe (consultanţi, reprezentanţi ai organizaţiei). Se poate apela şi la personal

propiu specializat în anumite domenii dar implicat în alte proiecte.

Ţinând cont de activităţile realizate în cadrul fiecărei etape şi subetape se poate

detalia diagrama din figura anterioară surprinzând înlănţuirea dintre paşi dar şi repartizarea

acestora pe fazele de dezvoltare prezentate anterior pentru sistemele informatice executive:

Figura 7.7 – Realizarea paralelă a subetapelor ciclului de dezvoltare a EIS pe

fazele principale

1

2

3 4

5 6

7

8

9

10

11 12

13 14

15

16

APLICAŢIA METADATE ETL

FAZA I: Evaluare

FAZA II: Studiul cerinţelor de afaceri

FAZA III: Elaborarea şi introducerea prototipului

FAZA IV: Implementarea funcţionalităţiilor EIS

FAZA V: Transferarea capacităţilor sistemului în cadrul organizaţiei

148

7.3. STUDII ŞI CADRE (FRAMEWORKS) DE DEZVOLTARE A

SISTEMELOR INFORMATICE EXECUTIVE

Scopul prezentării studiilor este de a identifica avantajele aduse de acestea în

stabilirea elementelor necesare în dezvoltarea şi utilizarea sistemelor informatice executive

care pot influenţa succesul acestor sisteme. Odată identificate aceste avantaje şi

particularităţi, ele pot fi combinate într-un singur cadru care va servi ca bază pentru un

studiu mai profund al factorilor asociaţi succesului sistemelor informatice executive. In

lucrarea “Executive Information Systems: A framework for their development and use”, T.

Kaniclides şi C. Kimble [KAKI94] prezintă comparativ următoarele studii:

1) Studiul ESPRIT - este un model al instalării “Resolve”, o varianta comercială a

pachetului software al sistemelor informatice executive, comercializată pentru compania

Metapraxis [MEBI91]. Acest studiu a fost dezvoltat după experienţa câştigată din

instalarea “Resolve” în companii, prin ceea ce se consideră a fi proiectele de dezvoltare a

sistemelor informatice executive de succes. ESPRIT este un studiu secvenţial în şase etape.

El descrie o metodă prototip evolutivă. Incepe cu un studiu de fezabilitate şi urmareşte apoi

alte etape de dezvoltare pănă la instalarea sistemului final şi pregătirea utilizatorilor.

Compania Metapraxis susţine că este aplicabil tuturor organizaţiilor, indiferent de structura

şi de specificul lor.

Cele şase etape ESPRIT sunt următoarele:

1. E = Evaluation of Consultants - Evaluarea consultanţilor;

2. S = Survey of Business needs - Rezultatul cerinţelor de afaceri;

3. P = Prototype a current requirement - Prototipul cerinţelor curente;

4. R = Review the benefits - Trecerea în revistă a beneficiilor;

5. I = Implement the full EIS project - Implementarea întregului proiect de sistem

informatic executiv;

6. T = Transfer the skills in-house - Transferul funcţionalităţilor proiectului în cadrul

organizaţiei.

In prima fază, consultanţii responsabili cu dezvoltarea proiectului sunt implicaţi în

realizarea unui studio preliminar pentru a evalua cerinţele unui sistem informatic executiv.

Se propune o soluţie iniţială care este apoi evaluată. Printre aspectele care necesită a fi

luate în consideraţie este experienţa echipei în domeniul în care sistemul va fi implementat

şi de asemenea dacă echipa are o cunoaştere totală a criteriilor prin care organizaţia obţine

succes.

149

A doua fază implică realizarea unui sondaj şi a unui studiu de fezabilitate pentru a

stabili dacă se poate utiliza un prototip corespunzător. Utilizatorii finali ai sistemului şi alte

persoane interesate sunt implicate în proiect. Sunt selectate resursele softwarel şi hardware

ce vor fi folosite în prototip. De asemenea, este necesar, ca la acest nivel să evaluăm

utilitatea datelor. Este relizată o ofertă formală cuprinzând costuri, beneficii şi detalii

despre activităţi este descrisă. Această formează termenii de referinţă ai proiectului, care

sunt supuşi unor discuţii şi validări de ambele părţi pentru a putea merge mai departe cu

realizarea prototipului.

Odată ce prototipul este terminat el este prezentat utilizatorilor săi. Prezentarea şi

testarea acestuia se realizează în cadrul unei întâlniri. Informaţiile prezentate trebuie

verificate pentru a asigura corectitudinea şi relevanţa acestora înainte de a fi prezentate.

Este un mod oportun pentru sistem de a caştiga credibilitatea utilizatorilor săi. Prezentarea

ar trebui să se concentreze pe evidenţierea funcţionalităţiilor reale ale sistemului, pe

punctele cheie bazate pe rezolvarea unor cerinţe obligatorii ale organizaţiei, pe beneficiile

majore aduse activităţilor de afaceri. Aceasta ocazie furnizează potenţialilor utilizatori

oportunitatea explorării sistemului şi ocazia de a formula întrebari în legatură cu sistemul.

Prototipul este instalat la cererea managerilor şi se va realiza o analiză formală cost

– beneficii. Bazându-se pe această analiză, şi în lumina experienţei câştigate până în acest

moment, întregul sistem informatic executiv propus este actualizat cu toate costurile

proiectului. Propunerea este apoi înaintată spre validare pentru a putea continua cu etapele

următoare.

Schimbările aduse prototipului pot fi minore, existând însă şi varianta unei

reconstrucţii totale a acestuia în funcţie de rezultatele obţinute în faza anterioară, cu o nouă

structură organizaţională şi funcţională. Se poate reproiecta întreaga infrastructură dacă

este necesar sau poate fi prelucrată de la varianta prototipului. Alegerea resurselor software

este re-evaluată în lumina noilor schimbări. Procedurile pentru extragerea automată a

informaţiilor sunt proiectate şi implementate integrând verificări ale datelor pentru

consistenţă. Formatul rapoartelor (atât pe hârtie cât şi pe ecran) furnizat de sistem este

proiectat şi sistemul informatic executiv este pregătit pentru a fi prezentat din nou

organizaţiei

Ultima fază implică proiectarea şi implementarea cursurilor de pregătire pentru

utilizatorii sistemului. Cursurile de pregătire pentru proiectanţi, analiţti şi managerul de

sistem sunt de asemenea planificate şi implementate. Orice documentaţie livrată cu

sistemul, legată de facilităţile furnizate de EIS este produsă în versiuni diferite pentru toate

150

tipurile de utilizatori. Aceştia sunt apoi intervievaţi şi comentariile lor legate de beneficiile

obţinute prin instalarea sistemului sunt documentate pentru a justifica toate costurile de

rulare a sistemului informatic executiv pe o bază permanentă. Pot fi identificate noi cerinţe

pentru sistm, acest fapt implicând reluarea etapelor şi îmbunătăţirea continuă a sistemului

informatic executiv.

2) Studiul structural - a fost realizat pentru a clasifica rezultatele obţinute în urma

implementării sistemelor informatice executive din SUA, în 1988. Studiul a implicat 50 de

companii care, fie că utilizează un sistem informatic executiv, fie sunt foarte aproape de a

implementa un astfel de sistem operaţional. Studiul se naşte din experienţa practică în

dezvoltarea sistemelor informatice executive, din discuţiile cu producătorii sistemelor

informatice executive, consultanţii şi membrii din echipa de dezvoltare [WATS91]. Studiul

constă din trei componente:

1. Prima componentă este o perspectivă structurală a dezvoltării sistemelor

informatice executive. Ea ilustrează elemente cheie, importante în procesul de

dezvoltare şi interacţiunile dintre ele. Autorii identifică un numar de elemente

asociate perspectivei structurale. Aceste elemente sunt clasificate în două categorii:

personalul şi datele. Prima categorie include oamenii implicaţi în dezvoltarea unui

sistem informatic executiv. Cealaltă categorie face diferenta dintre datele interne

organizaţiei şi datele utilizate din afara organizaţiei. Studiul relevă faptul că

dezvoltarea sistemelor informatice executive este un proces dinamic care conţine

elementele ce formeaza perspectivă structurală în mişcare;

2. Problemele importante din procesul de dezvoltare formează a doua componentă a

studiului. Ele sunt incluse în studiu pentru a atrage atenţia asupra problemelor

importante din activităţile întreprinse pentru dezvoltarea unui sistem informatic

executiv, din moment ce aceste activităţi joacă un rol important în succesul

sistemului final. Problemele ce primează în această componentă includ: timpul de

dezvoltare al sistemului, metodologia de dezvoltare utilizată, hardware-ul şi

software-ul implicate pentru sistem ca şi probleme legate de evoluţia şi răspândirea

sistemului către alţi membrii în organizaţie;

3. Cea de a treia componentă este dialogul dintre utilizator şi sistem. Diferite

probleme referitoare la utilizatorii sistemului sunt clasificate în trei categorii: prima

categorie implică probleme legate de cunoştinţele necesare utilizatorilor pentru a

opera sistemul, a doua se referă la problemele constatate în timpul funcţionării

sistemului, cum ar fi timpul de răspuns al acestuia şi interfaţa utilizator – sistem,

151

cea de a treia categorie se referă la modul în care informaţiile sunt prezentate şi la

efectul utilizării graficii şi al formatelor pentru prezentări. Dialogul sistem –

utilizator este important deoarece încorporează perspectiva utilizatorilor în studiu.

3) Metoda de studiu - majoritatea articolelor despre sistemele informatice

executive se concentrează fie pe sugestii prescriptive pentru dezvoltarea şi implementarea

sistemului informatic executiv, fie pe explicaţii descriptive despre modul de funcţionare al

EIS. Metoda de studiu propune o nouă perspectivă prin focalizarea atenţiei asupra

importanţei timpului şi coordonării activităţilor în cadrul dezvoltării unui sistem informatic

executiv. Descrie, de asemenea, modul în care sistemul informatic executiv evoluează către

un sistem informatic pentru management pentru a răspunde nevoilor manageriale de pe

nivelurile superioare de informaţie accesibilă şi la obiect.

Potrivit acestui studiu, dezvoltarea sistemului informatic executiv are loc ca rezultat

al evoluţiei prin intermediul nivelelor tehnologice şi organizatorice. Evoluţia unui sistem

informatic executiv de la tradiţionalul sistem informatic de management implică schimbări

în două domenii. In primul rand trebuie să fie o schimbare de la un grup sau un nivel

limitat de management, la un mediu interactiv şi apoi o creştere în concentrarea şi

integrarea informaţiei. Fiecare dintre aceste tranziţii cer şi au ca rezultat schimbări

tehnologice şi organizatorice.

Concentrarea şi integrarea privesc abilităţile sistemului de a furniza şi integra

informaţii despre indicatori specifici de performanţă importanţi pentru diferite domenii

funcţionale din cadrul organizaţiei.

In mod obişnuit, punctul de plecare este implementarea unui sistem informatic de

management şi al unui sistem informatic executiv reprezentând cel mai avansat nivel din

acest studiu. Exista un număr de metode şi etape pe care un sistem informatic le poate

parcurge şi care pot duce de la un sistem informatic de management la un sistem

informatic executiv. In practică, după obţinerea capacităţilor unui sistem informatic

executiv, o organizaţie poate implementa tranziţii de-a lungul uneia sau a ambelor

dimensiuni pentru a adaugă alte tipuri de funcţionalităţi şi pentru a facilita nevoile

diferiţilor utilizatori.

4) Studiul structurat - a fost utilizat în contexte diferite în relaţie cu sistemele

informatice cum ar fi: analiza modului în care noua tehnologie influenţează acţiunile

oamenilor implicaţi [BARL86], apropierea de categoria sistemelor suport de decizie

[PODE89], utilizarea teoriei ca model de înţelegere a naturii tehnologiei în cadrul

organizaţiilor [ORLI90] şi dezvotarea unui studiu de investigare a interacţiunii dintre

152

acţiunile umane şi structura socială din timpul dezvoltării sistemelor informatice

[ORRO91]. Acest ultim studiu poate fi utilizat pentru analizarea şi interpretarea instalării

unui sistem informatic executiv.

Cu toate că autorii dau un număr de exemple despre funcţionarea evenimentelor

descrise în studiu, ei observă că dovada empirică lipseşte. Studii ulterioare folosesc acestă

teorie pentru a analiza dezvoltarea unui sistem informatic executiv într-o companie, în

scopul observării dacă fenomenul descris poate fi constatat şi pentru a determina valoarea

studiului ca ghid pentru cercetare [JONA93].

Cocluzia a fost că structura studiului Orlikowski şi Robey [ORRO91] este

folositoare pentru atragerea atenţiei către problemele importante din cadrul procesului de

dezvoltare al sistemelor informatice executive. Mai mult, studiul conţine un număr de

trăsături ce sugerează faptul că el poate aduce o contribuţie analizei şi înţelegerii sistemelor

informatice executive în cadrul organizaţiilor.

O comparaţie între cele patru studii este realizată în tabelul următor:

Studiu ESPRIT STRUCTURAL METODA STRUCTURAT

Natura Model precis Studiu semi-

precis

Studiu semi-

precis

Studiu precis

Perspective/

Origini

Practice – din

punctul de

vedere al

consultanţilor

Teoretice –

încearcă să

reprezinte

realitatea

Teoretice –

un mod de

abordare

mai putin

practic

Teoretice –

perspective pur

teoretice

Obiectiv Prezintă

instalarea

RESOLVE

Serveşte ca

instrument de

raportare

Subliniază

noi

probleme

despre

dezvoltarea

EIS-urilor

Interpretează

procesele sociale

care se

desfăşoară în

organizaţie

Nivel

abstract

Mic Mediu Mediu Mare

Expresivita-

te

Serii de paşi

ce trebuie

urmate în mod

Relaţii între

elementele

implicate în

Trecerea la

sisteme

organizaţion

Procese sociale

care se

desfăşoară în

153

liniar dezvoltarea EIS ale timpul dezvoltării

Intindere Dezvoltare

(nivel scăzut)

Dezvoltare şi

utilizare

Dezvoltare

(nivel înalt)

Dezvoltare şi

utilizare

Nivel de

detaliere

Mare Mare Scăzut Poate fi mare

Tabel 7.5: Comparaţie între studiile de dezvolate a EIS

Consider că pentru cazul în care organizaţia doreşte să dezvolte atât un sistem

informatic pentru management cât şi un sistem informatic executiv, elementele propuse în

Metoda de studiu pot duce la extinderea cu succes a funcţionalităţilor implementate în MIS

pentru a se realiza rapid şi fără resurse prea mari un EIS. Însă aceste elemente teoretice

vor trebui îmbinate practic cu etapele şi componentele precizate în studiul ESPRIT şi în cel

Structural pentru a realiza pas cu pas atât sistemul informatic pentru management cât şi

pe cel executiv. Abordarea pe care o voi utiliza în cadrul acestei lucrări în soluţia de

sistem informatic executiv propusă va îmbina aspectele teoretice din Metoda de studiu cu

etapele şi elementele ciclului de dezvoltare descris anterior la începutul acestui capitol.

Practic, iniţial voi realiza un sistem informatic pentru management din care va fi apoi

dezvoltat şi extins cu facilităţile şi funcţionalităţile unui sistem informatic executiv astfel

încât să fie satisfăcute cerinţele de afaceri ale managementului strategic.

154

7.4. MINIMIZAREA RISCULUI DE DEZVOLTARE

Luând în considerare costurile ridicate, timpul de realizare şi impactul introducerii

sistemelor informatice executive în interiorul organizaţiei, nu este surprinzător faptul că

de cele mai multe ori doar reuşitele sau succesele obţinute sunt descrise în literatură şi

foarte puţine cazuri de sisteme informatice executive care au eşuat în implementare sunt

menţionate. Realizarea unui sistem informatic executiv constituie o strategie cu mari

riscuri pentru multe organizaţii, atât din partea firmelor dezvoltatoare cât şi a

beneficiarilor.

7.4.1. FACTORII PRINCIPALI CARE INFLUENŢEAZĂ REALIZAREA

SISTEMELOR EXECUTIVE. ANALIZA ŞI EVALUAREA GRADULUI DE

INFLUENŢĂ A FACTORILOR PE FIECARE ETAPĂ A CICLULUI DE

DEZVOLTARE

In timp, în urma unor implementări de sisteme informatice executive au fost

propuşi diferiţi factori care pot afecta succesul acestor sisteme. Chiar dacă nu există un

acord clar cu privire la cei mai semnificativi dintre aceştia, este general acceptat că depind

în mare măsură de procesul de dezvoltare.

Deseori, eşecul unui sistem informatic executiv se datorează schimbărilor

permanente a cerinţelor informaţionale ale managerilor. Pentru a avea succes sistemele

executive trebuie sa continue să evolueze şi să se extindă pentru a satisface cerinţele

utilizatorilor.

Sistemele executive constituie o nouă arie înrudită cu sistemele de inteligenţa

afacerii. In acest domeniu însă nu s-au facut încă suficiente cercetări academice şi nu s-a

stabilit o infrastructură teoretică care să sprijine şi să îndrume practic realizarea unor astfel

de sisteme. Noutatea sistemelor executive implică, de asemenea, faptul că experienţa

practică în ceea ce priveşte dezvoltarea acestora este limitată. Prin identificarea unor

factori general valabili pentru diferite tipuri de organizaţii, dezvoltatorii ar fi capabili să

acţioneze potrivit pentru a asigura minimizarea riscurilor de eşec.

Gradul de influenţă şi tipologia factorilor pot fi utilizate pentru a îndruma

dezvoltarea şi eforturile implementării ulterioare şi se asigură faptul că un sistem este

utilizat cu succes pentru scopul pentru care a fost proiectat la început. Raţionamentul din

spatele acestei idei este acela că, pentru a realiza un sistem executiv de succes,

dezvoltatorii trebuie să cunoască factorii care, potenţial ar putea influenţa succesul

sistemului. Aceşti factori prezintă următoarele caracteristici:

155

• Unicitatea mediului specific în care este implementat sistemul - fiecare sistem

diferă radical în ceea ce priveste structura, natura, scopul, rezultatul şi contextul,

fiind dependent de mediul în care este implementat. Aceasta unicitate se extinde

asupra factorilor afectând succesul sistemului în fiecare caz individual. Prin urmare,

ar fi nerealist sa încercăm să specificam o metodă de implementare care sa producă

universal un sistem executiv de succes;

• Factorii sunt în legatură cu procesul de dezvoltare şi particular cu faza de

utilizare - corespunzător naturii şi cerinţelor informaţionale ale managerilor,

folosirea sistemelor executive devine de o importanţă particulară. Implicarea

acestui lucru în examinarea factorilor ce afectează succesul unui sistem executiv

este că utilizarea ar trebui examinată separat faţă de restul procesului de dezvoltare;

• Utilizatorii joacă un rol principal în cadrul acestor factori - pentru sistemele

executive utilizatorii constituie un element important de determinare a succesului

sistemului. Profilul înalt al sistemelor executive sugerează probleme legate de

natura organizaţională, socială, psihologică, economică şi politică.

Cunoscând aceşti factori pentru un proiect particular de sistem executiv, cei

implicaţi în dezvoltarea EIS pot lua deciziile potrivite pentru a asigura succesul sau în cel

mai rău caz să minimizeze riscul de eşec al sistemului. Prin urmare, este benefic să se

poată identifica factorii critici de influenţă a unui sistem într-un cadru organizaţional

particular pentru a ghida dezvoltarea sistemelor executive. Există mai multe niveluri de

risc ce pot influenţa realizarea EIS-urilor, acestea fiind descrise anterior şi în articolul

[BARA05/2]:

• Proiectarea sistemului – în analiza şi proiectarea sistemelor informatice executive

trebuie să se ţină cont de obiectivul şi de caracteristicile acestora, iar modelarea

trebuie să fie orientată spre o detaliere a soluţiilor oferite de EIS-uri şi pe modul de

realizare a depozitelor de date. Construirea unui prototip într-un timp cât mai scurt

şi testarea acestuia este o soluţie pentru reducerea acestui tip de risc;

• Calitatea datelor – datele din sursele de date interne şi externe trebuie să fie corect

transformate şi prelucrate. Procesul de extragere, transformare şi furnizare a datelor

trebuie să respecte următoarele cerinţe de calitate: să producă informaţii corecte, de

actualitate, relevante, complete şi valide. Pentru reducerea acestui risc

recomandarea ar fi să se aloce resurse importante de timp şi tehnologie pentru

elaborarea procesului ETL;

156

• Impactul noilor tehnologii – datorită timpului relativ mare al ciclului de dezvoltare

al SIE există riscul ca la apariţia unor cerinţe funcţionale noi sistemul să nu poată fi

extins datorită platfomelor şi arhitecturii fizice de generaţie anterioară sau

inadaptabile. Pentru a reduce acest risc dezvoltatorul trebuie să ţină cont de

apariţia şi introducerea unor tehnologii noi, astfel încât sistemul să poată fi

adaptat, extins şi utilizat în condiţii tehnologice noi;

• Interfaţa cu utilizatorul – managerii executivi sunt utilizatorii finali ai sistemelor

EIS, din acest motiv o interfaţă sofisticată care necesită intervenţie din partea unui

personal specializat va influenţa în mod negativ eficienţa în operare a sistemului.

Managerilor trebuie să li se ofere o interfaţă cât mai simplă, adaptată cunoştinţelor

lor în domeniul IT, fără să necesite pregătire suplimentară. Din acest punct de

vedere se impun următoarele cerinţe sistemului EIS: să ofere o interfaţă grafică

(GUI) prietenoasă, să permită acces sigur şi confidenţial la informaţii, timpul de

răspuns să fie cât mai scurt, să fie accesibil din mai multe locuri (clienţi), eventual

prin interfeţe web;

• Costul unui sistem informatic executiv - sistemele informatice executive sunt

complexe, iar tehnologiile de realizare a acestora necesită costuri ridicate. Nu este

însă numai software-ul complex şi implică cheltuieli mai mari pentru un sistem

informatic executive, pe lângă acesta şi costurile de dezvoltare, şi tehnologii

hardware noi vor fi cu siguranţă necesare. Pentru sistemele informatice executive

sunt necesare servere de baze de date şi aplicaţii puternice multiprocesor, spaţiu de

stocare considerabil al datelor, reţele şi dispozitive mobile pentru clienţi. La acestea

se adaugă şi costul de introducere a datelor manual sau automat, costul de instruire

atât al utilizatorilor cât şi al personalului de susţinere (de obicei din cadrul

departamentelor IT). Consider că recomandabil este să se realizeze la început o

analiză a costurilor de achiziţie şi mentenanţă a dispozitivelor şi componentelor

fizice şi să fie evaluat şi costul de realizare al întregului sistem;

• Dezvoltare continuă - un EIS trebuie să fie actualizat continuu cu noi facilităţi

pentru a face faţă problemelor strategice aflate pe ordinea de zi. Pe parcursul şi la

sfarşitul fiecărei faze şi etape de dezvoltare consider că ar fi recomandabil să se

realizeze sesiuni de analiză şi validare a rezultatelor obţinute până în punctul

respectiv.

157

In timp ce funcţionalitatea şi timpul de răspuns sunt factori importanţi utilizarea

sistemului, costul şi flexibilitatea sunt factorii supremi. O organizaţie va accepta mai uşor

un sistem care nu este scump şi care furnizează 20% din informaţia necesara într-o lună

sau două decât un sistem scump care furnizează 80% din informaţia necesară după un an

de dezvoltare. Conducerea organizaţiei poate realiza, de asemenea, că sistemul mai ieftin

este mai usor de schimbat şi poate fi adaptat mai uşor la nevoile evoluate ale afacerii. A

schimba un sistem de dimensiuni foarte mari implică înlăturarea unor părţi ale unei

investiţii substanţiale. A schimba un sistem mai putin scump înseamnă un timp mai scurt

de muncă.

Din punctul de vedere al influenţei acestor factori şi a altor aspecte pe fiecare

etapă a ciclului de dezvoltare este necesară realizarea unei analize pentru stabilirea

obiectivelor urmărite în fiecare etapă şi a elementelor de risc ce pot duce la neîndeplinirea

acostora. In continuare, în tabelul 7.6, voi realiza această analiză cu menţionarea

factorilor de risc şi a unor recomandări personale pentru evitarea acestora.

Nr

etapă

Etapele

ciclului de

dezvoltare

Obiective Risc

1 Evaluarea

oportunităţilor

de realizare

Analiza fluxurilor

manageriale, în special la

nivel strategic;

Identificarea obiectivelor

strategice ale organizaţiei şi

oportunităţile de afaceri;

Identificarea cerinţelor de

afaceri ale sistemului EIS;

Analiza cost-beneficiu;

Analiza riscului implicat în

dezvoltarea proiectului;

Recomandări pentru etapele

următoare;

Analiza corectă a cerinţelor

strategice de afaceri este

decisivă pentru întregul ciclu

de dezvoltare şi pentru

succesul proiectului. Este

recomandabil să se acorde

suficiente resurse şi atenţie

analizei corecte a

activităţilor strategice şi la

discuţii să fie implicaţi activ

managerii executivi.

Stabilirea incorectă a

indicatorilor cheie de

performanţă şi a

informaţiilor necesare

procesului decizional la

158

nivel strategic va conduce la

eşecul întregului sistem.

2 Evaluarea

infrastructurii

întreprinderii

A. Infrastructura tehnică:

Analiza următoarelor

elemente: tipuri de servere,

sisteme de operare, staţii de

lucru, niveluri midleware,

interfeţe, componente de

reţea şi interconectare,

SGBD-uri, tehnologii şi

instrumente de dezvoltare,

etc.

Propunerea şi realizarea

noii infrastructuri pentru

sistemul EIS.

Recomandări pentru

achiziţonare de

echipamente noi sau

produse software necesare

dezvoltării proiectului.

B. Infrastructura

funcţională (non-tehnică):

Analiza următoarelor

elemente: standarde,

metodologii de dezvoltare,

utilizatori, roluri şi

responsabilităţi implicate,

proceduri specifice de

management, proceduri de

securitate, recomandări

existente, asigurarea

calităţii datelor, controlul

metadatelor, etc.

Impactul tehnologic este

factorul de risc cel mai

puternic în acest caz,

realizarea unei infrastructuri

pe o platformă învechită sau

rigidă, compusă din

elemente de diferite

generaţii, neomogene va

face ca o viitoare exdindere

a sistemului să fie

imposibilă.

Alegerea SGBD-ului este un

alt factor extrem de

important, trebuie să se ţină

cont de performanţele,

facilităţile, instrumentele de

dezvoltare şi utilitare oferite

de SGBD-ul ales.

Modalitatea de integrare a

surselor de date şi alegerea

corectă a standardelor şi a

tipurilor de integrare

utilizate va inflenţa în mod

decisiv posibilităţile de

dezvoltare a depozitului de

date.

159

Recomandări privind

modificarea acestor

elemente pentru bunul mers

al proiectului.

3 Planificarea

proiectului

Propunerea unei soluţii

pentru sistemul EIS,

stabilirea obiectivelor

proiectului, stabilirea

cerinţelor de securitate, a

rolurilor şi utilizatorilor

implicaţi, stabilirea echipei

şi a termenelor proiectului,

identificarea factorilor

critici şi a restricţiilor sau

constrângerilor.

Se realizează detaliat planul

de desfăşurare al

proiectului.

Elementele de risc de pe

acest nivel pot fi: lipsa de

implicare şi motivare a

resursei umane atât din

partea dezvoltatorilor cât şi

din partea beneficiarilor (mai

ales neimplicarea

managerilor executivi),

planificarea nerealistă sau

incorectă a termenelor,

resurselor financiare şi

umane, realizarea unui plan

rigid, fără a ţine cont de

modificări ulterioare ale

cerinţelor de afaceri,

stabilirea unor obiective

irealizabile,management

defectuos al proiectului.

4 Definirea

cerinţelor

Stabilirea cerinţelor

referitoare la infrastructura

tenhică şi nontehnică;

Cerinţe referitoare la

raportare, la cereri ad-hoc,

la tipul datelor (istorice,

curente, previzionate);

Cerinţe referitoare la

indicatorii cheie de

performanţă;

Cerinţe referitoare la

Riscul principal este

reprezentat de identificarea

şi stabilirea incorectă a

cerinţelor de raportare,

referitoare la datele utilizate,

la modul de realizare a

procesului ETL, la

securitate. In fapt, această

etapă cumulează factorii de

risc specificaţi anterior, fiind

o etapă de stabilire şi de

160

procesul de extragere,

transformare şi încărcare a

datelor (ETL);

Cerinţe privitoare la

securitate;

centralizare a cerinţelor

proiectului.

5 Analiza

datelor

Modelul datelor la nivel

logic, specificaţii privitoare

la procesul ETL, specificaţii

referitoare la date:

identificatori, restricţii de

integritate, relaţii între date,

restricţii de domeniu, etc.

Se realizează modelele

logice ale datelor atât

pentru datele operaţionale

cât şi pentru cele din

depozitele de date.

Principalul risc este acela de

a realiza o colecţie de date,

organizate şi integrate

haotic, fără a ţine cont de

cerinţele de raportare şi

analiză, acest fapt ducând

automat la eşecul sistemului,

acesta devenind doar un

sistem de prezentare a unor

date, fără a avea posibilităţi

de analiză a acestora.

Modelul logic al datelor la

nivelul organizaţiei nu

trebuie realizat prin adunarea

sau “cârpirea” schemelor

existente pentru că va rezulta

un sistem rigid, nepracticabil

pentru analize decizionale.

Alegerea tipului de depozit

de date şi a modalităţii de

realizare este deosebit de

importantă. Analiza

multidimensională este de

asemenea importantă, fiind

necesară stabilirea corectă a

dimensiunilor implicate.

6 Realizarea

prototipului

Realizarea prototipului şi

specificaţii ale acestuia:

Alegerea incorectă a

facilităţilor implementate de

161

scopul, funcţionalităţile

implementate, utilizatori

implicaţi, datele utilizate,

platforma hardware şi

software utilizată, interfeţe

şi standarde utilizate.

Este recomandabil să fie

incluse şi funcţionalităţile

OLAP, data mining, analize

de exepţie astfel încât

managerii executivi să aibă

o imagine cât mai apropiată

de ceea ce va oferi viitoarul

sistem.

Analiza performanţelor

prototipului, validarea

rezultatelor obţinute în

urma testării sale şi

recomandări privind

continuarea proiectului.

prototip, a datelor utilizate şi

a instrumentelor de

dezvoltare impleicate va face

ca durata de dezvoltare să fie

mare sau prototipul să nu

reflecte corect imaginea

viitoarului sistem.

Prototipul trebuie să ofere

managerilor executivi o

viziune reală a întregului

sistem pentru a căştiga

încrederea acestora, dar fără

a consuma foarte multe

resurse pentru realizarea

acestuia.

7 Analiza

metadatelor

Modelul logic al

metadatelor la nivel

organizaţional, înclusiv

următoarele elemente:

denumirea obiectelor,

descriere, tipuri, relaţii,

domenii, atribute.

Descrierea obiectelor din

dicţionarul metadatelor.

Riscurile acestei etape sunt

legate de cele precizate

anterior la analiza datelor,

realizarea în grabă sau

incorect a modelului

medatelor, fără analiza şi

documentarea obiectelor din

dicţionarul de date va face ca

modificări şi extinderi

utlerioare ale sistemului să

fie extrem de greoaie.

8 Proiectarea

datelor

Completarea modelului

logic al datelor şi realizarea

Realizarea incorectă a

modelelor utlizate (de

162

modelului fizic al datelor

atât pentru sursele de date

cât şi pentru destinaţii

(indecşi, partiţionări,

clustere).

Schema bazei de date, cu

modelul ER pentru bazele

de date operaţionale,

depozitele de date şi/sau

data mart-uri sau scheme

multidimensionale pentru

depozite cu obiecte

multidimensionale.

exemplu modelarea

mulidimensională doar prin

diagrame ER), neproiectarea

unor algoritmi sau tehnici de

optimizare, de securitate a

datelor va afecta

performanţele sistemului.

Un alt aspect este acela de a

stabili corect structura

datelor din depozit/data

marts, ce date se vor stoca

agregat şi la ce nivel.

9 Proiectarea

procesului

ETL

Specificaţii ale procesului

ETL referitoare la: sursele

de date, transformarea

acestora în modulele

destinaţii, operatorii şi

algoritmii implicaţi în

transformare, diagrame de

procese privind modulele

sursă şi cele destinaţie,

biblioteci şi utilitare de

transformare, programarea

desfăşurării procesului.

Un factor de risc principal

este acela de a nu analiza

calitatea datelor pe fiecare

sursă/modul în parte şi de a

proiecta un proces ETL

general care doar să încarce

datele în modulele

destinaţie. Trebuie aleşi

operatorii şi funcţiile

aplicate pe fiecare modul în

parte, ţinând cont în primul

rând de scopul pentru care se

vor încărca acele date.

10 Proiectarea

depozitului

metadatelor

Rafinarea modelului logic

al metadatelor şi realizarea

modelului fizic al

metadatelor, descrierea

obiectelor dicţionarului de

date, modalitate de

administrare, de acces,

Proiectarea finală a

depozitului metadatelor

trebuie să ţină cont de

flexibilitatea, performanţa şi

robusteţea sistemului,

obiectele să fie realizate

uniform şi descrise

163

specificaţii privind procesul

ETL pentru metadate.

corespunzător.

11 Realizarea

procesului

ETL

Realizarea şi implementarea

algoritmilor de extragere,

transformare şi încărcare,

realizarea programelor

ETL, programarea detaliată

de execuţie a procesului,

testarea execuţiei.

Incărcarea iniţială a datelor

în modulele destinaţie

pentru testare.

Realizarea finală a

procesului ETL trebuie să

incorporeze şi elemente de

performanţă, trebuie stabilite

intervalele de încărcare a

datelor astfel încât să nu fie

afectată funcţionarea

sistemului sau a altor

aplicaţii.

Testarea procesului ETL

trebuie să se realizeze

riguros pentru a identifica la

timp eventualele erori în

procesul de transformare a

datelor.

12 Realizarea

aplicaţiei

Aplicarea tehnologiilor de

inteligenţa afacerilor,

OLAP, cereri ad-hoc.

Realizarea interfeţei

utilizând reprezentări

tabelare, grafice, marcarea

excepţiilor în raportare,

tablouri de bord.

Informaţiile prezentate

trebuie să fie cât mai

sintetice, la obiect,

concentrate pe indicatorii de

performanţă ceruţi de

executivi, cu posibilităţi de

analiză avansată.

Realizarea unor optimizări

In această etapă este

deosebit de important ca

aplicaţia să fe orientată către

decidentul strategic în sensul

de a oferi acestuia o interfaţă

prietenoasă fără a fi necesare

cunoştinţe IT, de a

implementa funcţionalităţile

OLAP de analiză

multidimensională, de a

realiza scenarii “ce se

întâmplă dacă”, previziuni,

analize istorice, raportări de

excepţie, grafice

profesionale şi accesibile,

tablouri de bord.

164

în interogare, aplicarea

funcţiilor analitice.

Planificarea testării

aplicaţiei, furnizarea unor

date şi cazuri de testare.

Redactarea documentelor

de instructaj: manuale de

utilizare, teste, prezentări,

etc.

Neincluderea acestor

elemente va transforma

sistemul într-o aplicaţie de

vizualizare a unor date, fără

posibilitatea analizei lor şi

oferirea suportului

decizional strategic.

Instruirea utilizatorilor finali

trebuie axată pe utilizarea

facilităţilor şi funcţionalităţii

sistemului din punctul de

vedere al managerilor

executivi şi nu din punct de

vedere tehnic.

13 Extragerea

cunoştinţelor

din date (Data

Mining)

Specificarea cerinţelor

referitoare la descoperirea

de noi cunoştinţe.

Stabilirea datelor necesare

pentru aplicarea

algoritmilor, implementarea

algoritmilor de data mining

şi realizarea modelului

analitic.

Depozitul de date sau

datamart-urile realizate pot fi

considerate “mine de aur”

din punct de vedere al

posibilităţilor de obţinere a

unor cunoştinţe importante,

însă dacă acest proces de

data mining nu este orientat

spre ţinte strategice sau

rezultatele nu sunt

interpretate corespunzător

atunci procesul poate fi

inutil sau chiar să conducă la

decizii eronate.

14 Contruirea

depozitului

metadatelor

Realizarea depozitului

metadatelor, testarea

funcţionalităţii sale,

specificaţii privind

administrarea şi realizarea

Finalizarea construirii

depozitului metadatelor şi

instruirea corespunzătoare a

personalului din punct de

vedere al administrării

165

programelor, realizarea

documentaţiei (manuale de

configurare, prezentări,

instructaje cu utilizatorii

implicaţi în administrare).

datelor sunt elementele

principale în acest caz.

Nerealizarea acestora va face

imosibilă administrarea

ulterioară şi extinderea

sistemului.

15 Implementarea

sistemului

Trecerea de la etapele de

test la procesele de

producţie efectivă,

încărcarea iniţială a datelor

în modulele destinaţie,

implementarea completă a

funcţionalităţilor OLAP, a

extragerii cunoştinţelor din

date, a algoritmilor de

optimizare.

Prezentarea sistemului

utilizatorilor finali.

In acest moment este

important să se acorde

atenţie trecerii sistemului din

faza de testare în mediu real

organizaţional şi să se

acorde în continuare

asistenţă utilizatorilor, să se

observe şi să se remedieze

imediat problemele apărute.

Este important să se acorde

timp şi resurse suficiente

acestei treceri în mediul real.

16 Evaluarea

sistemului

Evaluarea satisfacerii

cerinţelor de afaceri ale

managementului strategic,

identificarea unor

posibilităţi de extindere, a

unor probleme sau puncte

slabe care se pot corecta

fără o reproiectare a

sistemului, retuşuri şi

adaptări online ale

sistemului.

Această etapă nu ar trebui

considerată ca o etapă finală,

după evaluarea sistemului ar

trebui să se reia o serie de

etape în care sunt necesare

modificări şi corecţii, dar

totuşi fără a întrerupe

funcţionarea sistemului sau

a-l reproiecta în întregime

dacât în cazul unui eşec total

sau dacă au survenit cerinţe

incompatibile cu cele

iniţiale.

Tabelul 7.6. – Analiza factorilor de risc pe fiecare etapă a ciclului de dezvoltare

166

Din această analiză, esenţială pentru succesul sistemului informatic executiv

ramâne analiza şi realizarea acestuia orientată pe satisfacerea cerinţelor decizionale

strategice fără de care sistemul s-ar transforma într-o aplicaţie de prezentare şi

vizualizare a unor date.

7.4.2. CRITERII DE EVALUARE A SISTEMELOR EXECUTIVE

Cerinţele impuse în realizarea EIS-urilor trebuie să ţină cont de principalul

obiectiv al acestora: asistarea procesului decizional la nivel strategic. In practică multe

sisteme au eşuat tocmai din cauza nerespectării acestor cerinţe: fie analiza datelor s-a

realizat la un nivel mediu, fie sistemul nu putea integra datele necesare analizei, fie timpul

de răspuns era mare sau interacţiunea cu utilizatorul se realiza anevoios.

Valoarea sistemului depinde de cât de folositor este conducerii executive, de cât de

bine este înteles şi cât de mult este utilizat [DERO92]. Din acest motiv s-au impus anumite

criterii de evaluare a EIS-urilor:

• Suport decizional – sistemul nu trebuie să fie doar o colecţie de date şi de modele

de analiză, ci să ofere instrumente puternice de evaluare a procesului de afaceri

pentru care este realizat;

• Performanţa – presupune oferirea de soluţii intr-un timp cât mai scurt. Performanţa

depinde şi de dimensiunile depozitelor de date şi complexitatea problemelor;

• Interfaţa prietenoasă – utilizatorii trebuie să realizeze singuri şi intr-un mod cât

mai uşor operaţiile asupra datelor şi modelelor, fără a necesita asistenţă

suplimentară;

• Flexibilitate – sistemul trebuie să fie capabil să se adapteze noilor condiţii ce pot

interveni în procesul de afaceri: schimbări de legislaţie, de politici manageriale, de

personal, servicii, etc.

• Scalabilitate – sistemele trebuie să se poată redimensiona în funcţie de structura şi

de mediul de afaceri fără a pierde însă din performanţă;

• Mentenanţa - introducerea noilor tehnologii şi construirea unor module noi trebuie

să se poată realiza cât mai uşor;

• Integrarea datelor – sursele de date ale sistemului să fie multiple şi variate, bazate

atât pe date interne rezultate din procesul operaţional cât şi pe date externe

organizaţiei, referitoare la evoluţia pieţii, legislaţie, concurenţă, relaţii cu alte

organizaţii.

167

Deşi în documentaţia de specialitate sunt menţionate puţine cazuri de eşec ale

sistemelor executive, acesta poate fi pus pe seama următoarelor aspecte: fie beneficiile

potenţiale ale sistemului nu sunt realizate, fie sistemul nu e utilizat sau există o rezistenţă

de folosire substanţială din partea managerilor.

Pe lângă acestea, nu există un acord clar cu privire la factorii cei mai semnificativi

ce contribuie la succesul unui proiect de implementare al unui EIS. Este totuşi acceptat că

pentru un EIS succesul sau eşecul într-o măsură considerabilă depinde de modul în care

procesul de dezvoltare este condus. Pentru un EIS, cel mai important moment în cadrul

ciclului de dezvoltare este utilizarea sistemului. Unicitatea şi particularitatea utilizatorilor,

aduc în discuţie constrângerile particulare pentru EIS-uri, care pot juca un rol major în

succesul global al sistemului. Din acest motiv, utilizarea EIS-urilor necesită o examinare

separată de restul procesului de dezvoltare.

Este necesar să se ţină cont de varietatea factorilor ce pot afecta în vreun fel

succesul sistemului în timpul dezvoltării pentru a asigura un risc minim de eşec. Cel mai

eficient mod de a realiza acest lucru este prin obţinerea unui mod de abordare structurat

care să uşureze studiul acestor factori. Acest lucru este asigurat prin construirea unui cadru

de dezvoltare potrivit pentru clasificarea unor probleme relevante. Un asemenea cadru de

dezvoltare este folositor în organizarea unui subiect complex, identificarea legăturilor

dintre părţi şi dezvăluirea domeniilor unde vor fi cerute dezvoltări suplimentare.

In concluzie, deşi etapele ciclului de dezvoltare a sistemelor informatice excutive

sunt cele tradiţionale, scopul şi caracteristicile specifice acestor tipuri de sisteme şi

cerinţele lor informaţionale prezintă un set de probleme unice şi dificile care trebuie

analizate şi depaşite.

Eventualul succes al acestor tipuri de sisteme este afectat de factori variaţi care

trebuie identificaţi pe durata întregului proces de dezvoltare şi în special în timpul

utilizării sistemului. Se recomandă ca întregul proces de dezvoltare să fie orientat spre

cerinţele de afaceri ale managementului strategic, spre identificarea oportunităţilor de

business şi spre analiza indicatorilor cheie de performanţă. În acest sens este utilă

realizarea unui prototip al tabloului de bord într-un timp cât mai scurt, validarea acestuia

de către utilizatorii cheie, respectiv managerii executivi şi apoi continuat şi detaliat

procesul de analiză şi proiectare a sistemului informatic.

Exemplificare: în capitolul 10 am propus o soluţie de sistem informatic executiv

realizat conform acestui ciclu de dezvoltare, iar după implementarea sistemului, am aplicat

criteriile de evaluare propuse în cadrul acestui capitol.

168

CAPITOLUL VIII - METODOLOGII DE REALIZARE A SISTEMELOR

INFORMATICE EXECUTIVE

8.1. CLASIFICĂRI ŞI CARACTERISTICI ALE METODOLOGIILOR DE

REALIZARE A SISTEMELOR INFORMATICE

Conceptul de metodologie de realizare a sistemelor informatice a apărut din

necesitatea de organizare a activităţilor şi utilizare eficientă a resurselor implicate în

realizarea unui sistem informatic. Astfel, activităţile de realizare a sistemelor informatice

au fost structurate în general în următoarele etape principale: analiza de sistem,

proiectarea, programarea şi implementarea.

Metodologia poate fi definită ca fiind “o implementare fizică a ciclului de viaţă al

sistemelor care include:

• Activităţile pas cu pas pentru fiecare fază de lucru;

• Regulile individuale şi de grup pentru fiecare activitate;

• Standardele de calitate în fiecare activitate;

• Instrumentele şi tehnicile utilizate în fiecare activitate.” [WHBE98]

In lucrarea [LUNG05] este definit conţinutul unei metodologii care trebuie să

cuprindă:

• Etapele/procesele de realizare a unui sistem informatic structurate în subetape,

activităţi, sarcini şi conţinutul lor;

• Fluxul realizării acestor etape / procese, subetape şi activităţi;

• Modalitatea de derulare a ciclului de viaţă a sistemului informatic;

• Modul de abordare al sistemelor;

• Strategiile de lucru / metodele de realizare;

• Regulile de formalizare a componentelor sistemului informatic;

• Tehnicile, procedurile, instrumentele, normele şi standardele utilizate;

• Modalităţile de conducere a proiectului (planificare, programare, urmărire) şi

modul de utilizare a resurselor financiare, umane şi materiale etc.

Clasificarea metodologiilor se poate realiza în funcţie de orizontul şi specificaţiile

de aplicare, modul de realizare şi abordare sistemelor informatice. In lucrarea [LUNG05]

sunt identificate următoarele criterii de clasificare:

a) După gradul de generalitate:

169

• Metode generale cu un grad înalt de generalitate, pot fi folosite pentru

realizarea sistemelor informatice din domenii diferite. Astfel de metodologii

pot fi: SSADM (Structured System Analysis and Design Methodology),

MERISE, OMT (Object Modeling Technique), UML (Unified Modeling

Language).

• Metode cadru ce se pot aplica doar asupra unor produse software. In general

aceste metodologii au fost realizate şi se aplică în cadrul unor firme

dezvoltatoare de sisteme informatice, de exemplu: Selection and

Implementation of Integrated Packaged Software (SIIPS) elaborată de

KPMG.

• Metode specializate se aplică doar pentru realizarea unui singur produs

software, de exemplu:. AIM (Oracle E Business Suite), POIS (Sun

Systems), Extract (Extract), Signature (Scala), ASAP (SAP).

b) Din punct de vedere al evoluţiei în timp metodele şi tehnicile se clasifică în:

• Metodele şi tehnicile clasice presupun realizarea activităţilor manual, fără

ajutorul unor produse de tip CASE.

• Metodele şi tehnicile evoluate presupun utilizarea unor pachete de programe

de asistare a analizei şi proiectării sistemelor informatice şi instrumente de

tip CASE.

c) După modelul ciclului de viaţă există metode de parcurgere a etapelor cu model

în cascadă; cu model în spirală; cu model incremental; cu model evolutiv; cu modele

compozite (ca exemplificare, aşa numitele cicluri în V şi în X) unde modelul răspunde şi

cerinţelor proiectării orientate obiect (POO) încurajând prototipizarea şi reutilizarea

componentelor. Aceste metode de parcurgere sunt în detaliu prezentate în lucrările

[LUNG05], [LUSA04], [VATU05].

d) Din punct de vedere al modului de abordare al sistemelor, metodele de

realizare a sistemelor informatice sunt descrise pe larg în cele ce urmează pentru a

identifica principalele avantaje şi dezavantaje ale utilizării uneia sau alteia dintre metode

în dezvoltarea SIE:

Metode cu abordare structurată presupun împărţirea sistemului în subsisteme pe

baza funcţiilor sistemului - abordarea funcţională ce structurează sistemul pornind de la

prelucrările pe care le suferă datele sau în funcţie de date - abordarea bazată pe date ce

structurează sistemul pornind de la structura datelor utilizate în sistem şi de la relaţiile care

170

există între acestea. Aceste metodologii propun modelarea datelor separat de modelarea

procedurilor. Modelarea procedurilor se face plecând de la ideea că funcţiile sunt active,

având un comportament, iar datele sunt afectate de aceste funcţii.

Se descompune sistemul în trei modele principale:

• Modelul mediului prin care se stabileşte graniţa între sistem şi mediu, precum şi

modul de interacţiune între ele.

• Modelul fizic al sistemului reflectă structura tehnică şi operaţională a sistemului

şi arată CUM funcţionează sistemul într-o anumită implementare.

• Modelul logic al sistemului arată CE face sistemul, fiind independent de

implementare.

Ultimele două tipuri de modele se realizează atât pentru sistemul existent, cât şi

pentru sistemul proiectat.

Această descompunere pe cele trei modele consider că poate fi un punct de plecare

în abordarea unui sistem informatic executiv în ceea ce priveşte separarea şi delimitarea

graniţelor sistemului, identificarea subsistemelor şi a funcţionalităţii acestora. Din acest

punct de vedere avantajele utilizării modelelor structurate în realizarea EIS ar fi

următoarele:

• Realizarea modulară a sistemului prin divizarea pe subsisteme;

• Identificarea şi delimitarea funcţionalităţii fiecărui subsistem şi a sistemului în

ansamblu;

• Reducerea timpului de implementare prin posibilitatea realizării paralele a

EIS.

La aceste avantaje se adaugă şi cele de ordin general, referitoare la sistemele

informatice, identificate în lucrarea [LUNG05]:

• Un mediul bine structurat este flexibil din punct de vedere al comportamentului,

are obiective clare, o arie de cuprindere cunoscută;

• Posibilitatea reducerii costului de dezvoltare a sistemului prin luarea în

considerare de la început a detaliilor, prin interacţiunea continuă cu

beneficiarul;

• Modificarea unei anumite activităţi a sistemului nu conduce la reluarea

integrală a studiului.

Dezavantajele utilizării acestor metode în realizarea sistemelor informatice

executive pot fi datorate rigidităţii modelelor în sensul că divizarea şi realizarea modulară

171

şi separarea pe funcţii şi date pot duce la pierderea privirii de ansamblu la un moment dat.

Insă ceea ce consider a fi un dezavantaj major este faptul că cerinţele de afaceri şi

specificaţiile sistemului nu sunt modelate în interacţiune cu funcţiile şi datele. Detalierea

separată a acestora poate duce la pierderea importanţei şi a impactului cerinţelor de

afaceri asupra lor.

Exemple de metodologii structurate: Structured Analysis and Design Information

Systems (STRADIS – este prima metodologie descrisă, propusă de Cris Gane şi Trish

Sarson ), Structured System Analysis and Design Methodology (SSADM – elaborată la

propunerea Guvernului britanic), MERISE – elaborată de Institutul de Cercetări în

Informatică, Rapid Application Development (RAD), AXIAL – elaborată de firma IBM,

Franţa, Custom Development Method (CDM – elaborată de corporaţia Oracle).

Metodologiile orientate obiect au apărut odată cu apariţia limbajelor de

programare orientate pe obiect şi se bazează pe conceptele de obiect şi clasă: un obiect

aparţine unei clase fiind o instanţă a clasei, iar o clasă este o grupare logică a obiectelor care au

aceeaşi structură şi un comportament similar. Un obiect este o abstractizare a datelor

elementare şi poate fi descris prin identitate, comportament şi stare.

Identitatea obiectului se realizează printr-un un atribut unic (identificator) ce permite

ca obiectul să fie referit independent de celelalte obiecte.

Starea obiectului este o valoare care caeacterizează obiectul la un moment dat.

Comportamentul unui obiect poate fi asociat printr-un set de operaţiuni ce-i pot fi

aplicate şi este descris în clasa căreia îi aparţine obiectul.

Premizele ce au dus la abordarea obiectuală a analizei şi proiectării sistemelor

informatice sunt prezentate tot în lucrarea[LUNG05] după cum urmează:

• Limitele abordării structurate în analiza şi proiectarea sistemelor informatice;

• Limitele modelului relaţional de organizare a datelor;

• Schimbările în ceea ce priveşte orientarea aplicaţiilor care puneau accent pe

stocarea datelor spre aplicaţii care pun accent pe prelucrarea mai eficientă a

acestora cu algoritmi performanţi;

• Succesele dobândite de către sistemele expert sub aspectul stocării

cunoştinţelor;

• Necesitatea unor noi tipuri de aplicaţii ce implică noi tipuri de date, de genul

imagine, sunet (aplicaţii multimedia);

• Apariţia conceptului de date abstracte;

172

• Progresele în domeniul hardware-ului precum şi în domeniul instrumentelor de

tip case.

Analiza şi proiectarea orientată-obiect utilizează trei tipuri diferite de modele

pentru descrierea unui sistem informatic:

• modelul static – prin care se modelează obiectele si relaţiile lor în sistem

• modelul dinamic – sunt descrise interacţiunile între obiecte în cadrul sistemului

• modelul funcţional – se realizează transformarea valorii datelor în sistem prin

operaţii şi procese.

Avantajele abordării orientate obiect a ciclului de dezvoltare al EIS consider că

derivă tocmai din posibilitatea de a modela unitar atât funcţiile cât şi datele, de a

surprinde asupra aceluiaşi obiect atât a caracteristicilor statice, funcţionale cât şi

dinamice prin prisma interacţiunilor cu alte obiecte. In acest fel pot fi modelate şi

cerinţele de afaceri în interacţiune cu obiectele.

Un alt aspect este acela că metodologiile OO acordă o mare importanţă reutilizării

pachetelor şi a componentelor. Practic ciclul de dezvoltare al EIS fiind orientat pe

prototip, componentele acestuia vor putea fi reutilizate fără a reproiecta întregul sistem.

In concluzie, pot spune că avantajele aduse de metodologiile orientate obiect faţă

de cele structurate recomandă abordarea obiectuală a sistemelor informatice executive.

Exemple de metodologii şi metode orientate obiect de realizare a sistemelor

informatice: Object Oriented Design (OOD - elaborată de Grady Booch), Object Oriented

Analysis (OOA - elaborată de Peter Coad şi Edward Yourdon), Object Oriented Structured

Design (OOSD - elaborată de Wasserman), Object Oriented System Analysis (OOSA - este

o metodologie de proiectare a sistemelor în timp real propusă de Sally Shlaer şi Steven

Mellor), Object Modeling Technique (OMT - elaborată de James Rumbaugh, Michael

Blaha), Object Oriented Software Engineering (OOSE - concepută de Ivar Jacobson).

173

8.2. SOLUŢII DE REALIZARE A SISTEMELOR INFORMATICE

EXECUTIVE CONFORM METODOLOGIILOR ORIENTATE-OBIECT UTILIZÂND

LIMBAJUL UNIFICAT DE MODELARE (UML)

8.2.1. ELEMENTE ALE LIMBAJULUI UML CARE POT FI UTILIZATE ÎN

REALIZAREA SISTEMELOR INFORMATICE EXECUTIVE

Metodologiile şi metodele orientate obiect prezentau o serie de limite precum şi

foarte multe diferenţieri de simboluri, notaţii sau tipuri de diagrame. Aceste aspecte

generau dificultăţi în privinţa înţelegerii, preluării şi folosirii lor de diferite grupuri de

utilizatori, în crearea de noi sisteme sau în procesul de mentenanţă a sistemelor.

In anul 1997 prin elaborarea standardardului UML (Unified Modeling Language) cu

privire la simboluri, notaţii, tipuri de diagrame şi tipuri de modele s-au înlăturat o mare

parte dintre diferenţele existente între metodologiile orientate obiect. În prezent Limbajul

Unificat de Modelare (UML) este un standard de modelare recunoscut de către OMG

(Object Management Group), standardizarea fiind realizată în noiembrie 1997, iar până în

prezent realizându-se o perfecţionare continuă a acestuia.

UML poate fi definit ca fiind un limbaj de vizualizare, specificare, construire şi

documentare a modelelor. Valoarea lui constă în faptul că este un standard deschis,

realizează întreg ciclul de dezvoltare al software-ului, acoperă multe tipuri de aplicaţii, este

bazat pe marea experienţă a celor care l-au realizat şi poate fi implementat de multe

produse de tip CASE. [LUNG05].

Majoritatea corporaţiilor au adoptat UML ca standard pentru propria lor

metodologie, însă există şi analişti care găsesc setul UML incomplet fiind nevoiţi să

extindă notaţiile existente cu alte tehnici, cum ar fi fişele CRC, pentru analiza orientată pe

responsabilităţi şi modelul entitate asociere, pentru proiectarea bazelor de date relaţionale.

Exemple de metodologii care utilizează UML sunt: Catalysis care furnizează şi o

serie de tehnici specifice pentru modelarea componentelor distribuite, Objectory -

metodologie de modelare a sistemelor orientată pe cazuri de utilizare realizată de Ivar

Jacobson, Fusion - dezvoltată la Hewlett Packard în anii 90 ca primă încercare de

standardizare a unei metodologii orientate obiect şi combină OMT, Booch cu fişe CRC şi

metodologiile clasice.

Limbajul UML dispune de o serie de notaţii standard utilizate ca suport în

modelarea sistemelor orientate şi defineşte un set de diagrame pentru etapele de dezvoltare

174

orientată-obiect a sistemelor, făcând şi o descriere riguroasă a semanticii acestor diagrame

şi simboluri.

Un sistem poate fi descris luând în considerare diferite aspecte:

• Funcţional: este descrisă structura statică şi comportamentul dinamic al

sistemului;

• Non-funcţional: necesarul de resurse implicate în dezvoltarea şi funcţionarea

sistemului, precum şi caracteristicile tehnice ale acestuia;

• Din punct de vedere organizatoric: organizarea proiectului prin succesiunea de

etape urmărite în dezvoltarea sistemului;

UML a standardizat zece tipuri de diagrame pentru modelarea acestor aspecte,

pentru modelarea structurii statice, pentru modelarea dinamicii şi pentru implementare.

Aceste diagrame sunt utilizate în diferite etape din cadrul ciclului de viaţă pentru realizarea

modelelor sistemului:

• Modelarea proceselor de afaceri se realizează folosind diagrama cazurilor de

utilizare - această diagramă dirijează întreg procesul de dezvoltare a sistemului

în cazul metodelor orientate pe cazuri de utilizare.

• Modelarea structurii statice se face cu ajutorul diagramei claselor (pentru

modelarea structurii statice a claselor sistemului) şi diagramei obiectelor

(pentru modelarea structurii statice a obiectelor sistemului).

• Modelarea dinamicii este făcută utilizând diagrame de interacţiune şi diagrame

de comportament. UML utilizează două diagrame de interacţiune, una pentru

modelarea circuitului mesajelor între obiecte, numită diagrama de secvenţă şi

alta, pentru modelarea interacţiunilor între obiecte, denumită diagrama de

colaborare. Ca diagrame de comportament, se utilizează diagrama de stare

pentru modelarea comportamentului obiectelor din sistem şi respectiv diagrama

de activitate pentru modelarea comportamentului cazurilor de utilizare,

obiectelor sau operaţiilor.

• Modelarea implementării se face cu ajutorul a trei diagrame. Modelarea

componentelor se realizează utilizând diagrama componentelor, modelarea

distribuirii sistemului se obţine folosind diagrama de desfăşurare, iar diagrama

pachetelor este un mijloc de grupare a elementelor diagramelor în pachete.

Se poate schiţa şi o succesiune de activităţi şi etape urmărite în realizarea acestor

tipuri de modele ale sistemelor informatice:

175

1) Specificarea cerinţelor sistemului presupune descrierea cerinţelor funcţionale şi

nefuncţionale pe baza discuţiilor şi interviurilor cu beneficiarii sistemului informatic;

2) Analiza sistemului care poate cuprinde următorii paşi:

• Modelarea cazurilor de utilizare în care se realizează diagrama use case la nivel

general precum şi descrierea acestora;

• Analiza domeniului claselor pe două nivele: static – prin diagrama claselor în

care sunt schiţate clasele din domeniul proceselor de afaceri fără precizarea în

detaliu a atributelor şi operaţiilor acestora, iar pentru clasele care au un

comportament dinamic se realizează şi diagramele de stare; dinamic - se

modelează procesele de afaceri cu ajutorul diagramelor de activităţi, de

colaborare şi de secvenţă.

3) Proiectarea sistemului prin care se va definitiva soluţia sistemului informatic şi

se vor rafina modelele acestuia prin următorii paşi:

• Construierea soluţiei definitive a sistemului cu ajutorul diagramelor cazurilor de

utilizare detaliate;

• Proiectarea arhitecturală în care se identifică principalele pachete ale

sistemului, se grupează clasele în pachete şi se realizează diagrama de pachete;

• Proiectarea detaliată, tot pe cele două nivele din analiză: static – se detaliază

diagrama claselor din domeniul proceselor de afaceri cu specificarea completă a

atributelor şi operaţiilor, se realizeaza diagrama de stare pentru clasele care au

un comportament dinamic, iar opţional se realizează şi diagrama claselor pentru

modelarea interfeţei cu utilizatorul şi pentru accesul la date; dinamic – se

modelează interacţiunea dintre elementele sistemului, atât din domeniul

proceselor de afaceri cât şi cele legate de interfaţă şi de acces la date prin

intermediul diagramelor de colaborare şi de secvenţă.

4) Implementarea sistemului prin care se specifică componentele principale cu

ajutorul diagramei componentelor şi distribuirea acestora pe resursele fizice existente

modelate prin diagrama de desfăşurare.

Modelarea sistemului se realizează în funcţie de utilizatorii implicaţi şi de aspectele

ce urmează a fi modelate. Pentru aceasta sunt utilizate vederile UML (Views). Acestea

surprind aspecte particulare ale sistemului de modelat. O viziune este o abstractizare a

sistemului, fiecare reprezentând o proiecţie a descrierii intregului sistem şi care reflectă un

anumit aspect al său. Fiecare vedere este descrisă folosind un număr de diagrame care

176

conţin informaţii relative la un anumit aspect particular al sistemului. Aceste vederi se

completează, deci este posibil ca o anumită diagramă să facă parte din mai multe view-uri.

• Viziunea cazurilor de utilizare (Use-case View) - Aceasta surprinde funcţionalitatea

sistemului, aşa cum este ea percepută de actorii externi care interacţionează cu

sistemul, de exemplu managerii executivi sau sistemele tranzacţionale existente în

organizaţie. In cadrul acestei vederi se pot realiza diagrame ale cazurilor de

utilizare şi ocazional, diagrame de activitate. Cei interesaţi de această viziune

asupra sistemului sunt deopotrivă managerii, dezvoltatorii dar şi cei care vor

realiza testarea şi validarea funcţionalităţii sistemului.

• Viziunea logică (Logic View) - Spre deosebire de view-ul cazurilor de utilizare, un

view logic “priveşte” înăuntrul sistemului şi descrie atât structura internă a acestuia

(clase, obiecte şi relaţii) cât şi colaborările care apar când obiectele trimit unul

altuia mesaje pentru a realiza funcţionalitatea dorită.

Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea

dinamicii sistemului se vor folosi diagramele de stare, de secventă, de colaborare

sau de activitate. Prin urmare, cei care sunt interesaţi de acest tip de vizualizare a

sistemului sunt consultanţii şi dezvoltatorii.

• Viziunea componentelor (Component View) - Componentele sunt module de cod de

diferite tipuri. În funcţie de conţinutul lor acestea pot fi: componente care conţin

cod sursă, componente binare sau executabile.

View-ul componentelor are rolul de a descrie componentele implementate de

sistem şi dependenţele ce există între ele, precum şi resursele alocate acestora şi

eventual alte informaţii administrative, cum ar fi de exemplu o planificare a

activităţilor de dezvoltare. Este folosit în special de dezvoltatorii sistemului, iar în

componenţa sa intră diagrame ale componentelor.

• Viziunea de concurenţă (Concurent View) - Sistemul poate fi construit astfel încât

să ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncţional, este

util pentru o gestionare eficientă a resurselor, execuţii paralele şi tratări asincrone

ale unor evenimente din sistem, precum şi pentru rezolvarea unor probleme legate

de comunicare şi sincronizare.

Cei care sunt interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi

integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice

177

(stare, secventă, colaborare şi activitate) şi diagrame de implementare (ale

componentelor sau de desfăşurare).

• Viziunea de desfăsurare (Deployment View) – Este modelată desfăşurarea fizică a

sistemului, pe dispozitivele folosite pentru realizarea efectivă a implementării, cum

sunt acestea conectate, precum şi ce componente se vor executa pe fiecare nod.

Aceast tip de vizualizare a sistemului prezintă interes pentru dezvoltatori,

integratorii de sistem şi cei care realizează testarea sistemului, iar pentru

construirea view-ului este folosită diagrama de desfăşurare.

Modelarea sistemelor se realizează ţinând cont de componentele acestuia împărţite

în trei pachete principale:

• Procesele de afaceri (Business Services) – modelează soluţia sistemului, clasele de

bază şi interacţiunea dintre acestea.

• Interfaţa cu utilizatorul (User Services) – modelează componenetele legate de

interfaţa sistemului cu utilizatorul, dar şi elementele de interfaţa dintre anumite

subsisteme.

• Accesul la date (Data Services) – modelează serviciile legate de accesul la sursele

de date, atât la cele din sistemele tranzacţionale cât şi la depozitele de date, precum

şi modalitatea de extragere a datelor.

8.2.2. EXTENSII UML UTILIZATE ÎN REALIZAREA SISTEMELOR

INFORMATICE EXECUTIVE

Realizarea sistemelor informatice executive implică modelarea particularităţilor

acestor tipuri de sisteme prin adaptarea setului standard de notaţii şi diagrame existente

în UML. Astfel, trebuie ţinut cont de următoarele aspecte:

• Condiţii de utilizare - EIS sunt proiectate pentru analize ad-hoc şi rezultatele nu

sunt cunoscute dinainte, modelarea sistemului trebuie orientată spre cerinţele şi

procesele de afaceri;

• Actualizarea datelor – In cadrul EIS se utilizează depozite de date optimizate

pentru a realiza o mare varietate de interogări. Datele din depozite sunt actualizate

regulat (de regulă în fiecare săptămână sau lună) cu ajutorul procesului ETL.

Utilizatorii finali nu pot modifica (actualiza) direct datele.

• Modelul de date utilizat - În depozitele de date se foloseşte forma denormalizată

(cum este schema stea) pentru optimizarea operaţiilor faţă de sistemele OLTP care

178

folosesc forma normalizată a datelor pentru a optimiza operaţiile de

actualizare/inserare/şterge şi pentru a garanta consistenţa datelor. Esenţa unui

model dimensional de calitate sporită este alegerea unui set de dimensiuni cât mai

apropiate de cele naturale şi de perspectiva utilizatorului. Este folositor să avem o

analiză ER înainte de a începe analiza dimensională deoarece echipa de proiectanţi

a depozitului de date va înţelege datele mai bine. Modelul dimensional trebuie

abordat mai mult din perspectiva utilizatorului decât din cea a datelor. Dacă nu

există o analiză ER anterioară, ea nu se recomandă a fi făcută datorită redundanţei

datelor.

• Operaţiile tipice realizate - O operaţie de analiză în cadrul EIS cere premise de

realizare diferite faţă de sistemele tranzacţionale, implică schimbări de perspectivă,

selecţia dimensiunilor, rotaţii în cadrul acestora, deci trebuie modelată distinct atât

interacţiunea dintre componentele sistemului cât şi accesul la date.

• Funcţii de previzionare şi analiză a datelor istorice, data mining – Modelarea va

surprinde şi aceste particularităţi prin proiectarea unor funcţii şi algoritmi care vor

permite realizarea de astfel de operaţii la nivelul sistemului

Abordarea modelării sistemelor informatice executive prin prisma proiectării

orientate – obiect presupune utilizarea conceptelor fundamentale ale OO (clase, obiecte,

încapsulare, agregare, moştenire, polimorfism, abstractizare) în realizarea modelului atât

din punct de vedere static (structural) cât şi dinamic.

Unul din principalele scopuri ale UML este acela de a asigura extensibilitatea

precum şi mecanismele de specializare prin care să fie extinse conceptele de bază. Pentru

acoperirea tuturor situaţiilor de modelare, autorii UML dau posibilitatea extinderii acestor

situaţii cu stereotipuri, comentarii şi constângeri.

Constrăngerile introduce anumite restricţii legate de comportamentul unui obiect

şisunt ataşate unui element al modelului. O constrângere este inclusă între acolade ({ }).

Comentariile documentează cu ajutorul unor informaţii suplimentare

comportamentul unui element al modelului.

Stereotipurile sunt clase adiţionale elementului modelat care reprezintă elemente

ale modelului existent dar utilizate cu scop diferit. Practic, comportamentul obiectului este

modificat şi direcţiile de aplicare sunt reorientate. Un stereotip este inclus între << >>.

In lucrările [LMTR02] şi [TRPA01] autorii propun extinderea setului de

stereotipuri şi constrângeri standard ale UML prin introducerea unui set corespunzător

179

pentru modelarea multidimensională. Pentru definirea acestor stereotipuri se propune

următorul şablon:

Tabel 8.1. Şablon pentru definirea stereotipurilor

Pentru modelarea sistemelor informatice executive putem să utilizăm, să

modificăm sau să definim extensii ale elementelor UML, după cum voi prezenta în

continuare, în funcţie de cele două aspecte ale modelului: componenta statică şi cea

dinamică. O primă formă a acestor extensii am propus-o iniţial în lucrarea de disertaţie

[BARA03/1], mai târziu acestea au suferit câteva completări aşa că în continuare voi

prezenta viziunea finală a acestor elemente.

A. Modelul static - Modelarea comportamentului static al sistemului presupune

identificarea claselor existente şi a relaţiilor dintre acestea. În cazul sistemelor EIS

modelarea statică presupune identificarea dimensiunilor şi a tabelelor de fapte şi a

legăturilor dintre ele.

Clasele modelului

Tabelele de fapte şi dimensiunile sunt reprezentate prin clase fapte (Fact classes),

respectiv clase dimensiuni (Dimension classes). Clasele fapte vor fi specificate ca fiind

clase compozite formate prin agregarea claselor dimensiuni. Relaţia dintre clasele fapte şi

clasele dimensiuni este de tipul multi – la – multi.

Considerăm cardinalitatea minimă a claselor dimensiuni 1, indicând astfel faptul

că o instanţă a clasei fapte este realizată de o instanţă a clasei dimensiune. Cardinalitatea

minimă a clasei fapte se poate considera 0, indicând astfel faptul că o instanţă a clasei

dimensiune poate participa la zero sau o instanţă a clasei fapte.

Dimensiunile se formează din mai multe nivele ierarhice prin compuneri si agregări

succesive ale nivelelor. Nivelul de bază este modelat cu ajutorul unei clase speciale numite

clasă de bază (Base Class). Nivelele superioare se modelează prin clase de nivel (Level

Class).

• Denumire: Numele stereotipului • Clasa de baza: Elementul UML caruia i se aplica stereotipul • Descriere: Descrierea detaliata a functionalitatii stereotipului • Imagine: Simbolul grafic asociat stereotipului • Constrangeri: Lista constangerilor definita prin expresii ale limbajului OCL

(object constraint language) asociate stereotipului • Valori: Se pot asocia anumite valori permise şi valori implicite

180

Pentru modelarea structurilor ierarhice şi a nivelelor din cadrul dimensiunilor şi a

modului de formare a acestora se utilizează două tipuri de relaţii între clasa dimensiune şi

nivelele ierarhice:

• Asocierea – se utilizează în cazul agregării nivelelor ierarhice pentru formarea

dimensiunilor şi este considerată de de tipul 1 – la – multi.

• Clasificarea - se utilizează în cazul compunerii unor nivelelor ierarhice sau de

bază în formarea dimensiunilor şi este considerată ca fiind o relaţie de

generalizare – specializare.

În cadrul unei clase dimensiune se pot întâlni ambele tipuri de asocieri.

Atributele şi operaţiile claselor dimensiune

Atributele claselor dimensiuni se pot clasifica astfel:

• Atribute de identificare (Identifying attribute) – sunt identificatorii claselor

dimensiune (de exemplu IDTIMP, IDZONA). Sunt considerate ca atribute

private.

• Atribute descriptive (Descriptor attribute) – permit descrierea dimensiunilor şi

sunt considerate drept atribute publice (de exemplu Descriere Timp, Descriere

Zona).

• Atribute părinte (Parent attribute) – permit stabilirea ierarhiilor.

Aceste tipuri de atribute sunt necesare în procesul de generare automată a

depozitelor de date şi sunt stocate în dicţionarul metadatelor. Pe lângă acestea se pot

identifica şi alte tipuri atribute în funcţie de cerinţe.

Operaţiile claselor dimensiune derivă din operaţiile modelului multidimensional şi

sunt:

• Roll Up / Drill Down - sunt operaţii de navigare în cadrul nivelelor ierarhice.

• Secţionări (Slice-Dice) – sunt limitări, fragmentări ale dimensiunilor pentru a

obţine o anumită viziune asupra datelor.

• Rotaţii (Pivoting) – sunt interschimbări ale dimensiunilor pentru obţinerea unor

perspective diferite asupra datelor.

Atributele şi operaţiile claselor de fapte

Atributele claselor de fapte sunt:

• Atribute de identificare (Identifying attribute) – sunt identificatori asemănători

cu cheile externe din modelul relaţional şi de obicei sunt proveniţi din

identificatorii claselor de dimensiune.

181

• Atribute descriptive (Descriptor attribute) – permit descrierea variabileleor şi a

măsurilor .

• Atribute măsuri sau fapte (Fact attribute) – definesc variabilele şi măsurile

tabelelor de fapte.

• Atribute calculate sau formule (Formula attribute) - definesc variabilele şi

măsurile calculate pe baza unor formule sau expresii.

Operaţiile claselor de fapte sunt operaţiile care se aplică în corespondenţă cu

operaţiile dimensiunilor pe lângă acestea se definesc şi o serie de operaţii ce permit

calcularea variabilelor şi stabilirea formulelor pentru atributele calculate.

Pentru modelul static pe baza celor identificate mai sus am realizat următoarele

stereotipuri:

Clase:

Nr Stereotip Semnificaţie

1. <<Dimension>> Clasa dimensiune

2. <<Fact>> Clasa fapte

3. <<Base>> Clasa de bază

4. <<Level>> Clasa nivel

Atribute:

Nr Stereotip Semnificaţie

1 <<OID>> Atribut identificator

2 <<OD>> Atribut descriptor

3 <<Parent ID>> Atribut părinte (clasa dimensiune)

4 <<Dimension Attribute>> Atribut (clasa dimensiune)

5 <<Fact Attribute>> Atribut măsură (clasa fapte)

6 <<Formula Attribute>> Atribut calculat (clasa fapte)

Relaţii:

Nr Stereotip Semnificaţie

1 <<HDim>> Reprezintă existenţa tipurilor de ierarhii in

cazul dimensiunilor

2 <<Completeness>> Completitudinea unei asocieri de

clasificare în cadrul ierarhiilor

182

Pe baza acestora am realizat şi o descriere a stereotipurilor care vor fi utilizate la

nivel static pentru a putea documenta complet acest set. Pentru a-l putea defini şi utiliza în

orice instrument CASE fiecare stereotip trebui să aibă asociate şi constrângerile

corespunzatoare, acestea fiind descrise cu ajutorul limbajului OCL (Object Constraint

Language):

<<Dimension>>

• Denumire: DIMENSION

• Clasa de baza: Class

• Descriere: Extensia reprezinta o dimensiune intr-un model multidimensional

• Imagine:

• Constrangeri:

1. Atributele clasei trebuie sa fie de tipul: Atribut Identificator, Atribut descriptor,

Atribut Dimensiune:

self.feature->select(oclIsKindOf(Attribute))->forAll(oclIsTypeOf(OID) or

oclIsTypeOf(Descriptor) or oclIsTypeOf(DimensionAttribute))

2. Asocierea Clasei dimensiune cu o clasa Fapte trebuie sa fie de tipul agregare:

self.association.association->forAll(associationEnd.participant.oclIsTypeOf(Fact)

implies associationEnd.aggregation= #aggregate)

self.association.association->forAll(associationEnd.participant.oclIsTypeOf(Fact)

implies aggregation <> #aggregate)

3. Optional pentru scheme de tip stea: o clasa dimensiune nu se poate asocia cu o

alta clasa dimensiune

self.allOppositeAssociationEnds->forAll(not participant.oclIsTypeOf(Dimension))

• Valori:

-isTime:

Tip: UML::Datatype::Boolean

Multiplicitate: 1

Descriere: Indica faptul ca dimensiunea reprezinta timpul sau nu

<<Fact>>

• Denumire: FACT

• Clasa de baza: Class

183

• Descriere: Extensia reprezinta o tabela de fapte intr-un model multidimensional

• Imagine:

• Constrangeri:

• Atributele clasei trebuie sa fie de tipul: Atribut Identificator, Atribut Fact:

self.feature->select(oclIsKindOf(Attribute))->forAll(oclIsTypeOf(OID) or

oclIsTypeOf(FactAttribute))

• Asocierea clasei Fapte trebuie sa fie de tipul agregare:

self.association->forAll(aggregation = #aggregate)

• Clasa de fapte se poate asocia cu o clasa dimensiune

self.allOppositeAssociationEnds->forAll(participant.oclIsTypeOf(Dimension))

• Valori:

Neprecizate

<<Level>>

• Denumire: LEVEL

• Clasa de baza: Class

• Descriere: Extensia reprezinta un nivel superior dintr-o ierarhie intr-un model

multidimensional

• Imagine:

• Constrangeri:

• Atributele clasei trebuie sa fie de tipul: Atribut Identificator, Atribut descriptor,

Atribut Parinte:

self.feature->select(oclIsKindOf(Attribute))->forAll(oclIsTypeOf(OID) or

oclIsTypeOf(Descriptor) or oclIsTypeOf(ParentAttribute))

• O clasa nivel se poate asocia cu o clasa dimensiune, cu o clasa nivel sau cu o

clasa de baza:

self.allOppositeAssociationEnds->forAll(participant.oclIsTypeOf(Base) or

participant.oclIsTypeOf(Dimension)) or participant.oclIsTypeOf(Level))

• Valori:

Neprecizate

184

<<Base>>

• Denumire: BASE

• Clasa de baza: Class

• Descriere: Extensia reprezinta nivelul de baza a unei dimensiuni intr-un model

multidimensional

• Imagine:

• Constrangeri:

• Atributele clasei trebuie sa fie de tipul: Atribut Identificator, Atribut descriptor,

Atribut Parinte:

self.feature->select(oclIsKindOf(Attribute))->forAll(oclIsTypeOf(OID) or

oclIsTypeOf(Descriptor) or oclIsTypeOf(ParentAttribute))

• O clasa de baza se poate asocia cu o clasa dimensiune, cu o clasa Level sau cu o

clasa de baza:

self.allOppositeAssociationEnds->forAll(participant.oclIsTypeOf(Base) or

participant.oclIsTypeOf(Dimension)) or participant.oclIsTypeOf(Level))

• O clasa de baza poate fi numai copil intr-o asociere:

self.generalization->size <= 1

• Valori:

Neprecizate

<<OID>>

• Denumire: OID

• Clasa de baza: Attribute

• Descriere: Atribute de identificare ale claselor Dimensions, Facts, Level, Base

• Imagine: !

• Constrangeri:

Neprecizate

• Valori:

Neprecizate

185

<<OD>>

• Denumire: OD

• Clasa de baza: Attribute

• Descriere: Atribute de descriere ale claselor Dimensions, Level, Base

• Imagine: …

• Constrangeri:

Poate apare numai la atributele claselor Dimensions, Level, Base

self.owner.oclIsTypeOf(Dimension) or self.owner.oclIsTypeOf(Base) or

self.owner.oclIsTypeOf(Level)

• Valori:

Neprecizate

<<Parent ID>>

• Denumire: PARENT ID

• Clasa de baza: Attribute

• Descriere: Atribute parinte ale claselor Level, Base

• Imagine: ↑↑↑↑

• Constrangeri:

Poate apare numai la atributele claselor Level, Base

self.owner.oclIsTypeOf(Level) or self.owner.oclIsTypeOf(Base)

• Valori:

Neprecizate

<< Dimension Atribute >>

• Denumire: DIMENSION ATTRIBUTE

• Clasa de baza: Attribute

• Descriere: Atribute dimensiune ale claselor Dimensions, Level, Base

• Imagine: β

186

• Constrangeri:

Poate apare numai la atributele claselor Level, Base sau Dimensions

self.owner.oclIsTypeOf(Level) or self.owner.oclIsTypeOf(Base) or

self.owner.oclIsTypeOf(Dimensions)

• Valori:

Neprecizate

<< Fact Atribute >>

• Denumire: FACT ATTRIBUTE

• Clasa de baza: Attribute

• Descriere: Atribute fapte ale claselor Fact

• Imagine: φ

• Constrangeri:

Poate apare numai la atributele claselor Fact

self.owner.oclIsTypeOf(Fact)

• Valori:

Neprecizate

<< Formula Atribute >>

• Denumire: FORMULA ATTRIBUTE

• Clasa de baza: Attribute

• Descriere: Atribute calculate ale claselor Fact

• Imagine: ƒƒƒƒ

• Constrangeri:

• Poate apare numai la atributele claselor Fact

self.owner.oclIsTypeOf(Fact)

• Necesita definirea formulei de calcul sau a regulii de derivare (expresie OCL)

self.derived implies self.derivationRule.oclIsTypeOf(OclExpression)

187

• Valori:

- derivationRule:

Tip: UML::Datatypes::String

Multiplicitate: 1

Descriere: Specificarea regulii de derivare sau a formulei de calcul

<< Dimension Package >>

• Denumire: DIMENSION PACKAGE

• Clasa de baza: Logical Package

• Descriere: Pachet logic utilizat pentru gruparea si modelarea ierarhiilor unei clase

dimensiuni

• Imagine: Ρ

• Constrangeri:

• Poate contine numai clase de tipul: dimension, base, level

self.feature-> select(oclIsKindOf(Class))-> forAll(oclIsTypeOf(Dimension) or

oclIsTypeOf(Base) or oclIsTypeOf(Level))

• Valori:

- derivationRule:

Tip: UML::Datatypes::String

Multiplicitate: 1

Descriere: Specificarea regulii de derivare sau a formulei de calcul

<< DAG >>

• Denumire: DAG

• Clasa de baza: Asociere

• Descriere: Directed Acyclic Graph – reprezinta existenta ambelor tipuri de

ierarhii in cazul dimensiunilor

• Imagine: None

• Constrangeri:

• Poate apare numai la asocierile dintre clasele Dimensions, Base, Level

188

self.associationEnd.participant->forAll(oclIsTypeOf(Dimension) or oclIsTypeOf(Base))

or oclIsTypeOf(Base))

• Valori:

Neprecizate

<< Completeness >>

• Denumire: COMPLETENESS

• Clasa de baza: Asociere

• Descriere: reprezinta o asociere completa

• Imagine: Neprecizata

• Constrangeri:

• Poate apare numai la asocierile dintre clasele Dimensions, Base, Level

self.associationEnd.participant->forAll(oclIsTypeOf(Dimension) or oclIsTypeOf(Base))

or oclIsTypeOf(Base))

• Valori:

Neprecizate

Reguli de validare MD

• Denumire: REGULI DE VALIDARE MD

• Descriere: reprezinta reguli de apartenenta a claselor la modelul

multidimensional

• Imagine: Neprecizata

• Constrangeri:

• Clasele din modelul MD pot fi de tipul Dimensions, Base, Level, Fact

self.allContents->forAll(oclIsKindOf(Class) implies (oclIsTypeOf(Fact) or

oclIsTypeOf(Dimension) or oclIsTypeOf(Base)))

• Valori:

Neprecizate

Tabel 8.2. Definirea stereotipurilor pentru modelarea sistemului EIS

189

B. Modelul dinamic - surprinde interacţiunea dintre instanţele claselor modelului.

Orice obiect are o stare ca rezultat al unor activităţi anterioare realizate de obiect şi de

obicei este determinată de valorile atributelor şi de legăturile lui cu alte obiecte.

Starea unui obiect se modifică atunci când apare un eveniment. Sunt două

dimensiuni ale dinamicii: interacţiunea cu obiectul şi modificările survenite în starea lui

internă, iar pentru a vedea cum obiectele reacţionează la evenimente şi ce modificări

implică fiecare eveniment în starea lor internă se modelează starea obiectelor.

În programarea orientată obiect o interacţiune între două obiecte este realizată

printr-un mesaj trimis de la un obiect la altul. Cel mai adesea mesajul este implementat ca

un simplu apel de operaţie iar după ce operaţia a fost executată, controlul este returnat

apelantului împreună cu valoarea returnată.

În cazul Sistemelor Informatice Executive modelarea interacţiunilor dintre

elemente se va focaliza pe schimbul de mesaje şi apelul operaţiilor de tipul: navigare pe

nivelele ierarhice, schimbarea perspectivei de analiză, previzionare, scenarii “ce se

întâmplă dacă” (What If), aplicarea algoritmilor de Data Mining, selectarea şi

recalcularea unor indicatori, analize top-bottom, etc. Aceste mesaje se vor schimba în

principal între clasele de fapte şi cele dimensiune la declanşarea unor cereri din partea

utilizatorului. Pentru modelarea comportamentului dinamic se pot utiliza atât diagramele

de secvenţă şi colaborare cât şi cele de activităţi.

Exemplificare: În capitolul 10 este modelată o soluţie de sistem informatic

executiv conform ciclului de dezvoltare propus în capitolul 7 şi în care am aplicat

stereotipurile UML prezentate în cadrul acestui capitol, descrierea lor şi a diagramelor

realizându-se în Rational Rose 2003.

190

CAPITOLUL IX – SOLUŢII DE TEHNOLOGII ŞI INSTRUMENTE

DISPONIBILE CARE POT FI UTILIZATE ÎN REALIZAREA

SISTEMELOR INFORMATICE EXECUTIVE

9.1. SOLUŢII DE SISTEME DE GESTIUNE A BAZELOR DE DATE.

ANALIZĂ COMPARATIVĂ A PERFORMANŢELOR ŞI FACILITĂŢILOR

OBŢINUTE DE SGBD-URILE DISPONIBILE

Obiectivul principal al acestui capitol este de a realiza o comparaţie între

principalele sisteme de gestiune a bazelor de date şi instrumente existente şi care sunt sau

se pot utiliza la realizarea unor sisteme informatice executive în cadrul organizaţiilor din

România.

Studiul nu se va concentra pe analiza unor produse software de inteligenţa

afacerilor sau sisteme executive deja existente deoarece nu este relevantă comparaţia

avantajelor şi dezavantajelor comerciale sau funcţionale aduse de un produs la cheie, luat

separat, fără mediul de afaceri în care funcţionează, chiar dacă în comparaţie s-ar utiliza

aceleaşi criterii. Mai importantă consider că este o analiză a platformelor şi sistemelor de

gestiune a bazelor de date pe care se poate construi un sistem informativ executiv.

Aşa cum am arătat în capitolul destinat ciclului de dezvolare al EIS, rolul unui

sistem de gestiune a bazelor de date şi al facilităţilor oferite de acesta este deosebit de

important în succesul şi performanţa unui sistem informatic executiv. Din acest punct de

vedere analiza va ţine cont de facilităţile de lucru cu baze de date evoluate şi depozite de

date, de implementarea unor funcţionalităţi OLAP şi data mining dar şi legate de

integrarea datelor din surse diverse şi de integrarea aplicaţiilor, de modalitatea de

realizare a procesului de extragere, transformare şi încărcare a acestor date în depozitele

de date finale, de uşurinţa în administrare şi de instrumentele oferite pentru dezvoltarea

interfeţelor. Un punct important al analizei se referă la performanţa în interogare, atât pe

bazele de date operaţionale, dar mai ales pe extragerea datelor din depozitele de date.

Având în vedere că majoritatea organizaţiilor au deja implementate aplicaţii de

diferite generaţii pe două mari platforme de baze de date şi anume Oracle şi Microsoft

SQL Server voi rezuma comparaţia la aceste două SGBD-uri, iar versiunile curente supuse

analizei sunt Oracle Database 10g şi Microsoft SQL Server 2005. Fiecare dintre acestea

191

sunt disponibile în diferite ediţii sau variante pentru a acoperi cât mai bine toate cerinţele

existente pe piaţă.

Oracle Database 10g este disponibil în cinci ediţii, fiecare având implementate

caracteristici specifice fiecărui segment de piaţă vizat:

• Oracle Database 10g Standard Edition One (SE1) este destinat mediilor de afacerii

cu cerinţe de prelucrare relativ reduse, nivelelor departamentale, fiind limitat la

maxim două procesoare;

• Oracle Database 10g Standard Edition (SE) este varianta superioară a lui SE1,

având şi facilităţi de clusterizare cu Real Application Cluster, însă este limitat la un

server cu maxim 4 procesoare;

• Oracle Database 10 Enterprise Edition (EE) reprezintă versiunea cea mai complexă,

cu facilităţi de gestionare a volumelor mari de date în medii tranzacţionale şi

aplicaţii critice, optimizări în extragerea datelor din depozite de date, administrare

şi securitate ridicată. In cadrul acestui studiu mă vom referi în mod explicit la

caracteristicile acestei versiuni;

• Oracle Database 10g Personal Edition (PE) este ediţia destinată dezvoltării de

aplicaţii individuale, fiind compatibilă cu celelalte produse ca SE1, SE şi EE.

Avantajul constă în faptul că rulează pe staţii variante, cu mai multe procesoare,

însă este limitată la un singur utilizator;

• Oracle Database 10g Express Edition (Oracle Database XE) este o ediţie lansată

recent, gratuită, destinată mediilor de afaceri cu cerinţe de prelucrare mici şi medii,

se poate instala pe orice staţie, însă fiind o versiune gratuită dimensiunea bazei de

date este limitată la maxim 4 Gb.

Majoritatea ediţiilor disponibile conţin facilităţi de administrare şi securitate

avansate cum ar fi clusterizare, partiţionare, algoritmi de criptare, gestiunea utilizatorilor în

funcţie de drepturile şi rolurile acordate, gestionare integrată a resurselor, optimizarea

cererilor de date. Sunt implementate atât metodele de prelucrare tranzacţionale cât şi

opţiuni de Business Intelligence cu funcţionalităţile OLAP, data mining şi suportul pentru

construirea depozitelor de date. Din punct de vedere al integrării datelor sunt prezente

servicii de interconectare a datelor din surse şi sisteme externe.

O comparaţie între facilităţile ediţiilor este prezentată în tabelul 9.1.[OWP06]:

Caracteristică XE SE1 SE EE Comentarii

192

Caracteristică XE SE1 SE EE Comentarii

Număr de

procesoare

nelimitat 2 4 nelimitat

Dimensiune

bază de date

4 GB Fără limită Fără limită Fără limită

Partiţionare - - - DA

Clusterizare - - DA DA

Optimizare

automată

DA DA DA DA

Administrare

integrată a

resurselor prin

Enterprise

Manager

- DA DA DA

Gestiunea

utilizatorilor

DA DA DA DA

Criptare date şi

management al

cheilor

DA DA DA DA

Import/Export DA DA DA DA

Extragere,

transformare şi

prelucrare a

datelor (ETL)

- - DA DA

Replicare

fuzionare

DA DA DA DA

Replicare

tranzacţională

DA DA DA DA

Suportă

instrumente de

DA DA DA DA

193

Caracteristică XE SE1 SE EE Comentarii

Business

Intelligence

Management şi

administrare

avansat

Parţial * DA DA DA *Fără gestiunea

automată a spaţiului,

restaurare şi back-up

automat

OLAP - - - DA

Data Mining - - - DA

Text Mining - - - DA

Tabel 9.1. Caracteristicile ediţiilor Oracle Database 10g

Corporaţia Microsoft a realizat familia de produse SQL Server 2005 pentru a

satisface cerinţele tuturor segmentelor de clienţi, cu ajutorul a patru ediţii: Express,

Workgroup, Standard şi Enterprise. Cele patru ediţii oferă o varietate de caracteristici, de

la disponibilitate ridicată şi scalabilitate robustă până la instrumente Business Intelligence

implementate prin instrumentele Analysis Services.

Fiind o componentă a Windows Server System, clienţii pot dispune de beneficii

care includ o durată de implementare redusă prin capacitatea de administrare şi integrare

care rezultă din strategia Common Engineering.

Cele patru ediţii sunt destinate unor cerinţe diferite de prelucrare şi din punct de

vedere al facilităţilor aceste patru ediţii sunt dispuse în mod asemănător cu ediţiile Oracle

Database 10g, după cum se prezintă în tabelul 9.2: [NET03]

Caracteristică Expres Workgroup Standard Enterprise Comentarii

Număr de

procesoare

1 2 4 Fără limită Include suport

pentru procesoare

multicore

Dimensiune

bază de date

4 GB Fără limită Fără

limită

Fără limită

Partiţionare - - - DA Suport pentru

194

Caracteristică Expres Workgroup Standard Enterprise Comentarii

baze de date la

scară largă

Clusterizare - - DA DA

Optimizare

automată

DA DA DA DA Optimizează

automat baza de

date pentru

performanţă

optimă

Administrare

integrată a

resurselor prin

Management

Studio

- DA DA DA Platformă de

management

completă pentru

SQL Server;

include Business

Intelligence (BI)

Development

Studio

Gestiunea

utilizatorilor

DA DA DA DA

Criptare date

şi management

al cheilor

DA DA DA DA Criptare

încorporată

pentru securitate

avansată a datelor

Import/Export DA DA DA DA

Extragere,

Transformare

şi prelucrare a

datelor (ETL)

- - DA DA

Replicare DA DA DA DA

195

Caracteristică Expres Workgroup Standard Enterprise Comentarii

fuzionare

Replicare

tranzacţională

DA DA DA DA

Replicare

Oracle

- - - DA Replicare

tranzacţională cu

o bază de date

Oracle în calitate

de publisher

Instrumente de

Business

Intelligence -

BI

Development

Studio

DA DA DA DA Mediu de

dezvoltare

integrat pentru

generarea şi

depanarea

integrării datelor,

soluţii OLAP,

data mining şi de

raportare

Management

al datelor

avansat

- - - DA Cuburi

partiţionate,

procesare

paralelă,

sincronizare

server

Data Mining - - DA DA

Text Mining - - - DA

Tabel 9.2. Caracteristicile ediţiilor Microsoft SQL Server 2005

Conform unor studii comparative realizate asupra acestor două produse, Oracle

Database 10g şi Microsoft SQL Server 2005, de către Edison Group Inc [EDIS06] şi de

WisdomForce Technologies Inc [WISD06] se observă o superioritate în ceea ce priveşte

196

facilităţile de gestiune şi administrare a datelor, dar şi a caracteristicilor de Business

Intelligence implementate de Oracle Database 10g faţă de SQL Server 2005.

Comparaţia dintre cele două produse pe baza criteriilor de administrare şi

gestionare a datelor este sintetizată în tabelul 9.3:

Car

acte

rist

ica

Oracle Database 10g

Microsoft SQL Server 2005

Sist

eme

de o

pera

re s

upor

tate

Microsoft Windows

98/NT/2000/2003/XP, inclusiv varianta

64-bit Itanium

Unix

Linux, Linux Itanium, Linux x86-64,

Linux on Power

IBM z/OS

Solaris, Solaris SPARC (64-bit)

HP-UX Itanium, HP-UX PA-RISC

AIX5L

Apple MAC OS

Microsoft Windows

98/NT/2000/2003/XP

Sup

ort

pe

64-b

iţi Oferă suport încă din versiunea 9i, atât

pentru Microsoft Windows cât şi pentru

alte sisteme de operare (Linux, Solaris).

Oferă suport începând cu versiunea 2005,

numai pentru Microsoft Windows Server

2003 Standard x64 Edition, Enterprise

x64 Edition, sau Datacenter x64 Edition

197

Adm

inis

trar

e Administrare uşoară prin intermediul

interfeţelor şi utilitarelor specifice cum ar

fi Enterprise Manager sau direct din linia

de comandă cu ajutorul instrucţiunilor.

Cei care au acest rol sunt utilizatorii cu

drepturi de DBA şi se conectează prin

conturile specifice ca sys sau system.

Sunt implementate roluri pentru grupuri

de utilizatori prin intermediul funcţiei

sys.verify_function definită în

$ORACLE_HOME/rdbms/ admin/

utlpwdmg.sql

Începând cu versiunea 8i se oferă

posibilitatea schimbării schemei curente

şi conectării la o altă schemă prin

intermediul sesiunilor de lucru:

ALTER SESSION SET

CURRENT_SCHEMA = apps;

Administrarea dedicată se poate realiza

numai prin linia de comandă:

SQLCMD -S user\parola -U system -P

manager –A

Schimbarea schemei curente se poate

realiza prin intermediul politicilor de

securitate referitoare la schemele

utilizatorilor.

Inde

xare

Sunt implementate mai multe tipuri de

indecşi: BTree, reverse BTree, indecşi de

tip Bitmap care funcţionează foarte bine

pe coloane cu selectivitate redusă, indecşi

bazaţi pe clustere

Se implementează doar indecşi de tip

BTree.

198

Par

tiţi

onar

e Oracle oferă mai multe tipuri de

partiţionare bazată pe intervale de valori,

hash sau liste. Este implementată şi

partiţionarea pe două nivele.

Aceste tipuri acoperă majoritatea

cerinţelor de partiţionare. Tipul se poate

specifica în cadrul sintaxei DDL create

table….

Partiţionarea este o facilitate recent

introdusă în versiunea de MSSQL 2005.

Partiţionarea este implementată printr-o

funcţie utilizator definită în T-SQL sau

.NET. Paşii pentru realizarea unei partiţii

sunt:

- se creează o funcţie în care se

specifică modalitatea de

partiţionare a tabelelor;

- se creează o schemă de

partiţionare;

- se creează tabela sau index-ul

utilizând schema de partiţionare.

Clu

ster

izar

e

Avantajul pe care îl are Oracle asupra

MSSQL este acela că implementează

clusterizarea bazată pe RAC/Grid care

poate fi scalată pe orice arhitectură şi este

suportată chiar şi în versiunea SE.

Administrarea clusterelor de tipul

RAC/Grid se realizează prin soluţia de

management ASM (Automatic Storage

Management).

Se oferă suport pentru clusterizare, însă

facilităţile şi opţiunile sunt mult mai

reduse decât cele oferite de Oracle 10g.

Opţiunea de clusterizare de tipul Grid nu

este dezvoltată.

199

Rep

lica

re d

ate şi

man

agem

ent

al c

heil

or Oracle implementează replicarea de tipul

peer-to-peer, cu reguli extinse printr-o

nouă facilitate numită "rules engine"care

permite realizarea de transformări online,

în timp real asupra datelor replicate. Faţă

de MSSQL 2005, replicarea suportă şi

filtrări şi mapări de date.

Facilităţile de replicare din SQL Server

sunt destul de limitate, în sensul că toate

bazele de date participante trebuie să aibă

scheme identice, iar obiectele conţinute

trebuie să fie diferite. De asemenea

replarea de tipul peer-to-peer nu suportă

filtrarea în cadrul liniilor sau coloanelor.

Impo

rt/E

xpor

t

Versiunea 10g aduce un nou utilitar de

import/export numit “data pump“ astfel

încât în prezent există două utilitare de

import imp/data pump şi două utilitare de

export de date exp/data pump.

Pentru importul/exportul de date din

surse externe, inclusiv fişiere text se

utilizează utilitarul sqlldr.

Tot pentru transformarea şi încărcarea

datelor se poate utiliza la instrumentul

ETL din Warehouse Builder. care oferă

suport pentru întregul proces de

extragere, transformare şi prelucrare a

datelor din surse variate ca: SAP,

Microsoft, text, Oracle, DB2, Informix.

MSSQL 2005 are de asemenea două

utilitare de import/export: BCP şu DTS

prin care se pot importa date atât din

surse relaţionale cât şi din fişiere text.

Utilitarul DTS (Data Transformation

Service) este, din punct de vedere al

facilităţilor de transformare şi încărcare a

datelor, superior utilitarelor similare de la

Oracle.

Totuşi din punct de vedere al surselor de

date şi al complexităţii transformărilor

realizate, utilitarul ETL din Warehouse

Builder nu are echivalent în

MSSQL2005.

200

Supo

rt p

entr

u X

ML

Prin opţiunea XML DB se oferă suport

pentru stocarea, indexarea şi interogarea

documentelor.

MSSQL 2005 oferă aceleaşi facilităţi ca

şi Oracle Database 10g.

Tabel 9.3. Analiza facilităţilor de administrare şi gestiune a datelor în Oracle Database

10g vs. Microsoft SQL Server 2005

Din punct de vedere al facilităţilor şi instrumentelor de inteligenţa afacerilor

(Business Intelligence) comparaţia dintre cele doua SGBD-uri am prezentat-o în tabelul

9.4:

Car

acte

rist

ica

Oracle Database 10g

Microsoft SQL Server 2005

Man

agem

entu

l dat

elor

mul

tidi

men

sion

ale

Instrumentele pentru construirea

depozitelor de date cât şi pentru

managementul lor sunt variate

începând cu un nivel general în

Enterprise Manager Console, în

Analytic Workspace Manager, a

depozitelor virtuale în Discoverer

Administrator şi culminând cu

Oracle Warehouse Builder,

instrument ce susţine întreg ciclul de

dezvoltare

Construirea depozitelor de date se

realizează cu ajutorul instrumentului

SQL Server 2000 Analysis Services, iar

managementul datelor şi al metadatelor

cu Enterprise Manager şi Analysis

Manager

201

Supo

rt p

entr

u pr

oces

ul E

TL

In Oracle Warehouse Builder se

oferă un instrument puternic de

asistare a procesului de extragere,

transformare şi încărcare a datelor

din surse variate: SAP, Oracle, DB2,

MSSQL Server, FoxPro, foi de

calcul, fişiere text, etc.

Componenta SQL Server 2005

Integration Services sau în variantele

mai vechi componenta Data

Transformation Services (DTS) susţin

procesul ETL, însă din punctul de

vedere al surselor de date şi al

complexităţii transformărilor realizate

aceste componente sunt inferioare

utilitarului corespondent din Oracle

Warehouse Builder.

Fun

cţii

anal

itic

e şi

OL

AP

Oracle începând cu versiunea 8i

oferă o gamă largă de funcţii

analitice (aproape 100) destinate

extragerii de date pentru rapoarte

complexe, printre care: AVG,

CORR, COVAR_x, COUNT,

CUME_DIST, DENSE_RANK,

FIRST, FIRST_VALUE, LAG,

LAST, LAST_VALUE, LEAD,

MAX, MIN, NTILE,

PERCENT_RANK,

PERCENTILE_x, RANK,

RATIO_TO_REPORT, REGR_x,

ROW_NUMBER, STDDEV_x,

SUM, VAR_x, VARIANCE.

Pentru operaţii OLAP se oferă

suport atât prin limbajele DML şi

DDL specifice cât şi prin

instrumente variate din gama

Business Intelligence.

Începând cu versiunea 2005 şi MSSQL

implementează prin T-SQL funcţii

analitice şi funcţii destinate analizei

OLAP şi operatori relaţionali cum ar fi:

PIVOT, APPLY, ROW_NUMBER.

202

Dat

a M

inin

g Opţiunea Oracle Data Mining

permite aplicarea următoarelor tipuri

de algoritmi:

• Modele predictive sau instruire

supervizată: algoritmi de clasificare,

algoritmi de regresie;

• Modele descriptive sau instruire

nesupervizată: clusterizare, reguli

de asociere bazate pe analiza

“coşului de cumpărături”;

Ca şi Oracle Database 10g se

implementează nouă algoritmi care

includ arbori de decizie şi regresie,

clustering, logistică şi regresie liniară,

reţele neutre, clasificatori naive bayes,

asociere, clustering în secvenţă şi serii

temporare.

Tex

t M

inin

g

Pe lângă text mining sunt

implementate şi modele pentru

multimedia şi bioinformatică

(BLAST)

Are facilităţi de text mining.

Uti

litar

e de

Dat

a M

inin

g

Oracle Data Miner prin care se pot

aplica algoritmii specifici atât prin

intermediul interfeţei cît şi prin cod

Java sau PL/SQL.

SQL Server 2005 Analysis Services prin

care se pot aplica algoritmii de extragere

a cunoştinţelor prin intermediul

interfeţei

Ana

lize

ad-h

oc

Se pot realiza prin diverse utiltare şi

componente: Analytic Workspace

Manager, Discoverer Desktop,

Discoverer Viewer, Discoverer Plus.

Se pot exporta foarte uşor în foi de

calcul (de exemplu în Microsoft

Excel).

Se pot realiza prin suita de produse

Microsoft Office (Excel, Office Web

Components, Data Analyzer, SharePoint

Portal Server) şi prin utilitarul SQL

Server 2005 Reporting Services.

203

Dez

volt

area

inte

rfeţ

elor

Din gama de utilitare pentru

dezvoltarea de interfeţe şi rapoarte

dinamice, specifice sistemelor

informatice executive se pot utiliza

atât suita Discoverer Desktop, cât şi

extensiile Java BI Beans din

JDeveloper.

Un punct forte al acestor utilitare

este facilitatea de publicare rapidă şi

uşoară în cadrul portalurilor prin

intermediul componentei Oracle

Portal.

Incepând cu SQL Server 2005

interfeţele şi aplicaţiile pot fi realizate

foarte uşor cu utilitarul Business

Intelligence Development Studio care

oferă posibilitatea de vizalizare a datelor

atît din punct de vedere grafic cât şi

tabelar.

Tabel 9.4. Analiza facilităţilor şi instrumentelor de Business Intelligence oferite de Oracle

Database 10g vs. Microsoft SQL Server 2005

Referitor la performanţa în realizarea cererilor pe bazele de date relaţionale într-un

studiu realizat în iunie 2006 de către Transaction Processing Performance Council (TPC)

[TPPC06] la testul de performanţă TPC-C V5 prin care se evaluează performanţele de

procesare ale tranzacţiilor în sistemele OLTP (on-line transaction processing) pe varianta

fără clusterizare Oracle Databse 10g ocupă poziţiile 3 şi 4 după IBM DB2 şi înaintea

MSSQL Sever 2005, iar în varianta cu clusterizare Oracle Databse 10g este singura

variantă posibilă cu un scor de 1,184,893 tpcm.

La testul TPC Benchmark H (TPC-H) prin care se evaluează performanţele de

procesare în raportarea ad-hoc, în medii decizionale Oracle Databse 10g cu Real

Application Clusters a obţinut un nou record de performanţă în ceea ce priveşte procesarea

datelor pentru o dimensiune a bazei de date de 3000 GB. Acesta este un test de evaluare a

caracteristicilor de procesare analitică, de extragere a datelor prin cereri şi modificări

concurente. Unitatea de măsură a performanţei este numită TPC-H Composite Query-per-

Hour Performance Metric (QphH@dimensiune) şi reflectă mai multe caracteristici de

procesare a datelor. Acestea includ dimensiunea bazei de date, viteza de procesare şi

modificare a datelor. Se analizează şi raportul de cost/performanţă, măsurat în

$/QphH@dimensiune.

Astfel, rulând pe un server 64-Node HP ProLiant cu procesor dual-core AMD

Opteron 2.4 GHz şi Red Hat Enterprise Linux 4, Oracle Database 10g cu Oracle Real

204

Application Clusters a înregistrat un nou record de performanţă cu 110,576.5

QphH@3000GB având o rată cost/performanţă de $37.80/QphH@3000GB.

Performanţele Oracle Database 10 g sunt evidente şi la o dimensiune a bazei de

date de 300, 1000 şi chiar 10000 GB, în timp ce MSSQL Server 2005 se clasează pe

locurile 5-10. La o dimensiune a bazei de date de 100 GB, rolurile sunt inversate, MSSQL

2005 situându-se pe primele poziţii. Rezultatele pot fi vizualizate în figura următoare şi la

adresa: http://www.tpc.org/tpch/results/tpch_perf_results.asp [TPPC06].

Figura 9.1. Rezultatele obţinute la testele de performanţă TPC-H

Din analizele comparative realizate se observă că facilităţile şi caracteristicile

Oracle Database 10g au un avantaj clar asupra celor implementate de MSSQL Server

2005, iar în cazul sistemelor informatice executive unde cerinţele de prelucrare şi

integrare a datelor sunt ridicate, soluţia Oracle Database 10g este cea mai indicată atât

din punctul de vedere al administrării datelor cât şi din punct de vedere al facilităţilor de

Business Intelligence oferite. In acest sens, în subcapitolul următor voi face o prezentare a

principalelor tehnologii şi instrumente Oracle ce pot fi utilizate în construirea unui sistem

informatic executiv.

205

9.2. SOLUŢII DE TEHNOLOGII ŞI INSTRUMENTE ORACLE UTILIZATE

ÎN REALIZAREA SISTEMELOR INFORMATICE EXECUTIVE

Platforma Oracle oferă o serie de instrumente şi tehnologii pentru dezvoltarea de

aplicaţii şi sisteme de inteligenţa afacerilor care pot fi utilizate în realizarea EIS-urilor.

Acestea sunt grupate într-o clasă specială - Oracle Business Intelligence şi au următoarele

componente [ORA10g]:

1) Componente pentru stocarea şi pregătirea datelor în vederea analizei:

• Oracle Business Intelligence Warehouse Builder (OracleBI Warehouse

Builder) pentru proiectarea, implementarea şi mentenanţa depozitelor de

date;

• Oracle Business Intelligence Discoverer Administrator (OracleBI

Discoverer

• Administrator) pentru realizarea şi administrarea unei viziuni orientate pe

business a datelor relaţionale;

• Analytic Workspace Manager pentru structurarea datelor în vederea analizei

avansate.

2) Componente pentru analiza datelor şi realizarea de rapoarte:

• Oracle Business Intelligence Discoverer Plus (OracleBI Discoverer Plus)

pentru realizarea de rapoarte ad-hoc;

• Oracle Reports pentru realizarea de rapoarte detaliate la nivelul întregii

companii;

• Oracle Business Intelligence Spreadsheet Add-In (OracleBI Spreadsheet

Add-In) pentru analiza datelor direct într-o foaie de calcul Excel;

• Oracle Data Miner pentru realizarea procesului de data mining;

• Oracle Spreadsheet Add-In for Predictive Analytics pentru realizarea

procesului de data mining direct în Excel.

3) Componente publicarea şi interacţiunea cu rapoartele create:

• Oracle Business Intelligence Discoverer Portlet Provider (OracleBI

Discoverer Portlet Provider) pentru publicarea rapoartelor în OracleAS

Portal

206

• Oracle Reports pentru distribuirea şi publicarea rapoartelor în mediul

organizaţiei, pe web prin integrarea cu E-Business Suite sau OracleAS

Portal;

• Oracle Business Intelligence Discoverer Viewer (OracleBI Discoverer

Viewer) care suportă vizualizarea rapoartelor pe web.

4) Componente pentru dezvoltarea de aplicaţii:

• Oracle Business Intelligence Beans (OracleBI Beans) este o componentă

integrată în Jdeveloper şi permite dezvoltarea de aplicaţii JSP;

• Oracle OLAP permite creare şi aplicarea de funcţii analitice (de ex:

previziune şi alocare) şi care pot fi utilizate în alicaţiile realizate cu

OracleBI Beans.

Arhitectura Oracle Business Intelligence oferită de corporaţia Oracle este

prezentată în figura următoare:

Figura 9.2. – Arhitectura Oracle Business Intelligence [ORA10g]

Oracle Data Miner oferă posibilitatea realizării de aplicaţii flexibile cu o interfaţă

grafică intuitivă şi uşor de modificat de către utilizatorii finali prin aplicarea algoritmilor

de data mining şi construirea de modele predictive de analiză [ORA10g].

In urma aplicării acestor modele se generează cod Java sau PL/SQL. Se pot

construi şi o serie de aplicaţii prin care aplicarea procesului de data mining să se realizeze

automat. In figurile următoare este prezentată realizarea unei astfel de aplicaţii (figura 9.3)

şi rezultatele obţinute (figura 9.4).

207

Figura 9.3: Construirea unei aplicaţii în Oracle Data Miner

Figura 9.4: Rezultatele obţinute în urma aplicării procesului de data mining

Oracle Data Mining permite aplicarea următoarelor tipuri de algoritmi:

208

• Modele predictive sau instruire supervizată:

– Algoritmi de clasificare care presupun gruparea datelor în clase distincte şi apoi

autoclasificarea noilor valori introduse;

– Algoritmi de regresie – funcţii de aproximare şi de previziune a valorilor

continue;

– Selecţia atributelor importante – se selectează cele mai relevante atribute ale

datelor pentru rezultatelor predictive;

• Modele descriptive sau înstruire nesupervizată:

– Clusterizare – descoperirea de grupări în date;

– Reguli de asociere bazate pe analiza “coşului de cumpărături”;

– Algoritmi de extragere pentru realizarea de noi atribute bazate pe cele existente;

• Modele pentru multimedia (TEXT) şi bioinformatică (BLAST)

Datele necesare procesului sunt extrase direct din baza de date Oracle, fără a fi

necesară stocarea separată a acestora.

Suita de componente Oracle necesare realizării unui sistem pentru inteligenţa

afacerilor suportă întreg ciclul de dezvoltare a sistemului care presupune următoarele etape

conform [ORA10g]:

• Identificarea cerinţelor de business ale utilizatorilor finali;

• Identificarea surselor de date;

• Proiectarea modelului de date;

• Realizarea depozitului de date;

• Generarea datelor agregate;

• Pregătirea datelor pentru accesul instrumentelor de extragere şi analiză;

• Acordarea drepturilor de acces;

• Distribuirea rapoartelor şi aplicaţiilor realizate şi furnizarea documentaţiei.

Cerinţele de afaceri pot apare la toate nivelele şi departamentele unei companii, în

acest sens componentele Oracle permit realizarea de aplicaţii pentru satisfacerea acestor

cerinţe:

• Consiliul de conducere: analiza Indicatorilor cheie de performanţă, analiza

tendinţelor de dezvoltare ale organizaţiei, raportarea de excepţie;

• Planificare şi analiză administrativă: investiţii, reorganizare, alocarea resurselor,

politici privind resursele umane;

209

• Departamentul financiar: bugetare, consolidare, analiza variaţiilor, modelare

financiară, Cash management, indicatori financiari;

• Departamentul comercial: profitabilitate, profilul cumpărătorului, indicatori de

rentabilitate comercială, analiza vânzărilor.

210

CAPITOLUL X. PROPUNEREA ŞI REALIZAREA UNEI SOLUŢII DE

SISTEM INFORMATIC EXECUTIV ÎN CADRUL UNEI COMPANII

NAŢIONALE

Studiul de caz următor are ca scop dezvoltarea unui sistem informatic executiv

destinat analizei rezultatelor înregistrate de către o societate comercială multinaţională,

cu mai multe sucursale distribuite geografic. Pentru a evidenţia necesitatea implementării

unui sistem executiv, voi descrie pe scurt desfăşurarea activităţii decizionale realizate în

prezent:

• Tranzacţiile zilnice sunt înregistrate într-o bază de date relaţională prin intermediul

unui sistem informatic integrat, şi anume suita de aplicaţii Oracle E-business Suite;

• Pe baza acestora se obţin rapoarte periodice şi la cerere privind activitatea

comercială, de producţie şi economică din sistemul ERP existent;

• Lunar se realizează situaţii privind realizările pe fiecare unitate şi se centralizează

apoi la nivelul întregii organizaţii;

• Indicatorii financiari se calculează semi-automat pe baza acestor rapoarte de către

personalul specializat la nivelul unitaţilor iar situaţiile obţinute sunt prezentate

managerilor departamentali şi apoi conducerii centrale în vederea luării deciziilor;

• Pe baza acestor rapoarte obţinute şi pe baza informărilor directe, la nivel executiv

sunt luate deciziile privind activitatea organizaţiei şi transmise ulterior spre

aplicare pe linie ierarhică.

Problemele majore identificate într-o astfel de activitate sunt:

• Activitatea de obţinere a indicatorilor se realizează la nivel de sucursală, detaliat,

rezultatele fiind centralizate manual ulterior în foi de calcul;

• Sistemul existent nu oferă posibilitatea analizei dinamice şi a simulărilor referitoare

la aceşti indicatori, rapoartele fiind prezentate managerilor executivi în foi de calcul

şi pe hârtie;

• Procesul de analiză financiară este anevoios şi există posibilitatea de apariţie a unor

erori sau date redundante sau datele prezentate să nu mai fie de actualitate;

• Nu sunt surprinsi toţi factorii de influenţă asupra indicatorilor;

211

• Nu sunt incluse în raportare decât informaţiile furnizate de sistemul ERP, pentru

situaţiile cerute de managementul executiv sunt necesare şi alte informaţii care nu

se regăsesc în cadrul sistemului.

• Pentru persoanele cu funcţii de conducere sunt necesare situaţii centralizate, dar şi

detaliate greu de realizat în timp util: evoluţii ale volumului vânzărilor şi a

aprovizionării, situaţia veniturilor şi cheltuielilor pe o perioada sau în ziua curentă,

evoluţia principalilor indicatori economici într-o perioadă, previzionări ale situaţiei

existente, etc.

Datorită acestor probleme şi a faptului că în prezent nu este implementat nici un

sistem tip suport de decizie care să poată fi utilizat sau un depozit de date centralizat din

care să poată fi extrase informaţiile necesare şi să poată fi adaptat pentru un sistem tip

EIS, soluţia va fi aceea de a realiza integral un sistem suport de decizie bazat pe un

depozit de date centralizat destinat nivelului tactic de management şi pe baza acestuia se

va dezvolta şi sistemul informatic executiv destinat nivelului stretegic de management.

Aceste niveluri împreună cu sistemele informatice specifice sunt ierarhizate conform

piramidei următoare:

Figura 10.i – Nivelurile de management şi sistemele informatice care se vor construi

Analiza şi proiectarea sistemului suport de decizie şi al sistemului informatic

executiv se vor realiza conform ciclului de dezvoltare prezentat anterior în capitolul VII şi

Sistemul informatic

Sistemul informatic executiv

Sistemul suport de decizie pentru activitatea economică şi comercială

Sistemul ERP la nivelul întregii organizaţii

Oracle E-Business Suite

Nivelul de management Strategic Tactic Operaţional

Nivel de realizare

Propus

Propus

Existent

212

va ţine cont de particularităţile organizaţiei, de cerinţele managementului executiv şi de

constrângerile de realizare.

Etapa 1: Studiul de fezabilitate

Pas 1: Evaluarea oportunităţilor de realizare

Cerinţele sistemului, atât cele funcţionale cât şi cele legate de aspectele tehnice se

identifică prin participarea consultanţilor la discuţii şi dezbateri cu reprezentanţi ai

organizaţiei în care se va derula proiectul de realizare a EIS. Este recomandat să se

realizeze întâlniri şi discuţii pe diferite nivele de management, utilizând tehnica top-

bottom, pentru a se putea identifica sursa şi destinaţia rapoartelor şi analizelor cerute la

nivel strategic. Pentru stabilirea interviurilor şi a participanţilor se utilizează Tabelul 7.3. –

Tipuri de cerinţe identificate în cadrul proiectelor EIS. Proiectul se va orienta pe

indicatorii strategici, de performanţă, economici şi comerciali la nivelul societăţii. Din

acest motiv analiza cerinţelor se va concentra pe nivelul de management strategic dar şi la

nivelul departamentelor economic şi comercial.

Din punct de vedere tehnic, funcţionalităţile sistemului trebuie să respecte

următoarele cerinţe:

• Accesarea informaţiilor din bazele de date sau depozitul de date să se realizeze în

timp real. Datele accesate se vor organiza în subseturi corespunzătoare criteriilor de

filtrare specificate prin interogări dinamice şi flexibile ale bazelor de date din

aplicaţia integrată existentă în organizaţie;

• Selectarea datelor de interes pentru analize şi sinteze să fie făcută într-o manieră

grafică, prietenoasă;

• Realizarea de analize complexe ale activităţii să fie realizată foarte uşor atât la

nivelul întregii companii cât şi la nivel de subdiviziune administrativă;

Sunt identificaţi factorii de risc ce pot afecta desfăşurarea proiectului, pe baza

tabelului propus în capitolul VII:

Factori Nivelul de risc

Tehnologie Risc mediu: Experienţă redusă în domeniul tehnologiilor din

domeniul inteligenţei afacerilor – se utilizează în cadrul organizaţiei

diverse instrumente şi tehnologii de inteligenţa afacerilor.

Complexitatea

sistemului

Risc maxim: Ridicată, necesită schimbări majore în cadrul

organizaţiei – este necesară o reorganizare a firmei din punctul de

vedere al fluxurilor de conducere.

213

Integrare Risc mediu: Surse diverse, dar cu posibilitatea de integrare uşoară –

majoritatea datelor sunt deja integrate prin intermediul sistemului

ERP, iar alte date necesare se pot introduce în acest sistem, deci

sursele pot fi integrate şi obţinute uşor.

Organizare Risc minim: Suport mare din partea organizaţiei – atât managerii cât

şi persoanele implicate în dezvoltarea sistemului, în special personalul

IT acordă sprijin şi se participă activ la desfăşurarea proiectului.

Echipa de

proiect

Risc mediu: Are experienţă şi determinare, atitudine şi implicare –

chiar dacă nu au experienţă bogată în dezvoltarea unor sisteme de

inteligenţa afacerii şi în special a sistemelor executive, echipa are

experienţă în utilizarea unor tehnologii specifice şi se implică în

desfăşurarea proiectului.

Investiţia

financiară

Risc minim: Profit estimat într-un timp scurt – datorită beneficiilor

aduse de facilităţile de analiză a sistemului executiv se estimează că

prin suportul decizional oferit se pot obţine şi rezultate financiare mai

bune.

Tabel 10.1 – Identificarea factorilor de risc ai proiectului

Etapa 2: Planificarea proiectului

Pas 2: Evaluarea infrastructurii organizaţiei

Este analizată infrastructura organizaţiei pe cele două tipuri de componente:

1) Infrastructura tehnică – sunt identificate elemente de hardware, software,

middleware, sistemele de gestiune a bazelor de date, sisteme de operare, componente de

reţea, utilitare diverse, dicţionare de metadate. Arhitectura pe care se va dezvolta sistemul

este formată din servere pentru baze de date, servere pentru aplicaţii, calculatoare client

performante, laptop-uri şi dispozitive mobile pentru acces mai facil. Sistemele de operare

pe care se va rula sistemul sunt: pentru servere – UNIX, iar pentru calculatoarele client –

Windows XP. Datorită criteriilor de performanţă prezentate în capitolul VI, dar şi datorită

faptului că deja este implementat sistemul ERP Oracle E-Business Suite sistemul de

gestiune a bazelor de date ales este Oracle 10g - Oracle Application Server 10g release 2.

2) Infrastructura nontehnică – sunt specificate standarde referitoare la metadate,

codificări, metodologii, recomandări, proceduri de testare, de control, politici de securitate.

Aceste elemente sunt realizate de personalul IT şi echipa de proiect.

214

Arhitectura sistemului EIS este finalizată şi se prezintă schematic ca în figura

următoare:

Figura 10.ii. – Nivelurile arhitecturii sistemului

Pas 3: Planificarea proiectului – se estimează şi se planifică de către managerul de

proiect activităţile, resursele, dependenţele între activităţi şi între resurse.

Etapa 3: Analiza cerinţelor de afaceri

Pas 4: Definirea cerinţelor sistemului – sunt detaliate şi analizate cerinţele iniţiale

ale conducerii organizaţiei.

In urma discuţiilor avute cu managerii şi şefii serviciilor din cadrul organizaţiei au

fost identificate şi centralizate următoarele cerinţe:

C1: Cerinţe referitoare la activitatea economică. Evoluţia indicatorilor cheie se va

concentra pe următoarele direcţii importante atât pe perioade istorice cât şi previziuni prin

diferite metode (liniară, exponenţială şi funcţii proprii):

• Bilanţ – analiză pe conturi de bilanţ, istoric şi previziuni

• Contul de profit şi pierdere (inclusiv raport cu marja brută)

• Fluxul de numerar (Cash Flow) la care se va ţine cont de tipurile de plăţi şi încasări.

• Tablouri de bord (indicatori de performanţă) pe nivele ierarhice (dir. general,

economic, departament).

• Realizare bugete – planificarea bugetelor de venituri şi cheltuieli şi urmărirea

realizărilor acestora

ERP Oracle E-Business Suite – module funcţionale

Module Financiar: General Ledger (Contabilitate Generala), Account Payables (Plati Furnizori), Account Receivables (Incasari Clienti), Cash Management (Gestiune lichiditati)

Module Comercial: Purchasing (Aprovizionare), Order Management (Desfacere), Inventory (Gestiune Stocuri), Engineering (Concepţie/Prototipuri), Bills of Material (Tehnologia, liste materiale şi operaţii), Work in Process (Producţie în curs), Master Scheduling/Material Requirement Planning (Planificarea producţiei)

Alte surse externe organizaţiei

Depozit de date centralizat ce intregrează două data marts departamentale: economic şi comercial

ETL

Interfaţă grafică cu facilităţi de raportare avansată, integrată în Oracle Portal

Extragere OLAP

Data mining

215

• Tabloul soldurilor intermediare de gestiune şi urmărirea evoluţiei indicatorilor

respectivi.

C2. Cerinţe referitoare la activitatea comercială:

Cerinte referitoare la stocuri:

• Urmărirea situaţiei şi mişcărilor de stocuri pe fiecare sucursală, pe categorii de

produse şi pe activităţi. Se doreşte urmărirea situaţiei stocurilor fără mişcare sau cu

mişcare lentă.

• Previzionarea evoluţiei stocurilor pe sucursale/activităţi/produse

• Istoricul evoluţiei stocurilor pe sucursale/activităţi/produse

• Analiza intrărilor şi ieşirilor din stoc pe sucursale/activităţi/produse

• Situaţia transferurilor între sucursale

• Urmărirea limitelor la stocuri (stocurile de siguranţă).

Cerinte referitoare la aprovizionare:

• Analiza şi previzionarea necesarelor de aprovizionare

• Evoluţia participării la licitaţii, a cererilor de ofertă în vederea aprovizionării cu

materiale

• Urmărirea comenzilor de aprovizionare pe produse/unităţii/furnizori

Cerinte referitoare la ofertare-desfacere:

• Evoluţia ofertelor si contractelor încheiate precum si derularea acestora

• Evidenţa şi urmărirea comezilor de prestări servicii încheiate precum şi derularea

acestora

• Situaţia vânzărilor de materiale pe sectoare/activităţi

Cerinte referitoare la indicatorii activităţii comerciale:

• Urmărire indicatori: viteza de rotaţie a stocurilor, vechime stocuri, marja

comercială, etc

• Analiza valorică şi procentuală a: cifrei de afaceri, cheltuieli cu materialele, stocuri

cu materii prime si materiale, cheltuieli si stocuri raportate la CA.

• Analiza valorică şi procentuală a plaţilor către furnizori şi încasărilor de la clienţi

C3. Cerinţe privind indicatorii cheie de performanţă. Tabloul de bord va permite analiza

următorilor indicatori:

• Indicatori privind lichiditatea: lichiditatea curentă (globală), lichiditatea

patrimonială, lichiditatea imediată

216

• Indicatori de risc: indicatorul gradului de indatorare, capital imprumutat raportat la

capitalul propriu, indicatorul privind acoperirea dobânzii, viteza de rotaţie a

activelor totale

• Indicatori de profitabilitate: rentabilitatea capitalului angajat, marja brută din

vânzări

• Alţi indicatori privind activitatea întreprinderii: marja comercială, producţia

exerciţiului, valoarea adaugată, excedentul brut al exploatării (EBE), rezultatele

exploatării, venituri financiare, cheltuieli financiare, rezultatul curent, venituri

excepţionale, cheltuieli excepţionale, rezultatul excepţional, rezultatul brut,

productivitatea muncii, cheltuieli totale la 1000 usd la CA, cifra de afaceri,

capitaluri permanente, active imobilizate, fondul de rulment (FR), active circulante,

datorii pe termen scurt, datorii curente, nevoia de fond de rulment (NFR), trezoreria

neta, rata de lichiditate, rata rentabilitatii comerciale (RC).

Un tabel centralizat cu toti aceşti indicatori este prezentat în anexa 1.

Paşii 5, 6, 7 - In urma cerinţelor identificare se trece la realizarea următoarelor

subetape – analiza datelor şi metadatelor, precum construirea unui prototip iniţial.

Această analiză se va realiza utilizând diagramele cazurilor de utilizare şi

diagramele de clase şi de interacţiune (diagramele de secvenţă, de activităţi şi de

colaborare). Modelarea sistemului şi proiectarea bazei de date multidimensionale se va

face utilizând instrumentul CASE Rational Rose 2003 Enterprise Edition.

Pentru a surprinde cât mai detaliat caracteristicile sistemului derivate din modelul

multidimensional (clase de tipul dimensiune şi fapte, ierarhii şi asocieri între acestea,

precum şi tipurile de operaţii OLAP) se trece mai întâi la implementarea stereotipurilor în

mediul CASE pentru a le putea utiliza în specificaţiile claselor. Se realizează următoarele

definiţii în fişierul DefaultStereotypes.ini:

Class:Base

Class:Level

Class:Fact

Class:Dimension

Attribute: OID

Attribute: OD

Attribute: Parent ID

Attribute: Dimension Attribute

217

Attribute: Fact Attribute

Attribute: Formula Attribute

Association: DAG

Association: Completeness

Logical Package:Dimension Package

[Class:Base]

Item =Class

Stereotype =Base

Metafile=&\stereotypes\color\base.wmf

ToolTip=Creates a Base Class\nBase Class

[Class:Level]

Item =Class

Stereotype = Level

Metafile=&\stereotypes\color\level.wmf

ToolTip=Creates a Level Class\nLevel Class

[Class:Fact]

Item =Class

Stereotype =Fact

Metafile=&\stereotypes\color\fact.wmf

ToolTip=Creates a Fact Class\nFact Class

[Class:Dimension]

Item =Class

Stereotype =Dimension

Metafile=&\stereotypes\color\dimension.wmf

ToolTip=Creates a Dimension Class\nDimension Class

[Attribute: OID]

Item=Attribute

Stereotype=OID

ToolTip=Creates a Dimension Attribute ID\nDimension Attribute ID

[Attribute: OD]

Item=Attribute

Stereotype=OD

ToolTip=Creates a Dimension DescriptionID\nDimension Description

[Attribute: Parent ID]

218

Item=Attribute

Stereotype=Parent ID

ToolTip=Creates a Parent Attribute ID\nParent Attribute ID

[Attribute: Dimension Attribute]

Item=Attribute

Stereotype=Dimension Attribute

ToolTip=Creates a Dimension Attribute\nDimension Attribute

[Attribute: Fact Attribute]

Item=Attribute

Stereotype=Fact Attribute

ToolTip=Creates a Fact Attribute\nFact Attribute

[Attribute: Formula Attribute]

Item=Attribute

Stereotype=Formula Attribute

ToolTip=Creates a Formula Attribute\nFormula Attribute

[Association: DAG]

Item=Association

Stereotype=DAG

ToolTip=Creates a DAG Association\nDAG Association

[Association: Completeness]

Item=Association

Stereotype=Completeness

ToolTip=Creates a Completeness Association\nCompleteness Association

[Logical Package:Dimension Package]

Item=Logical Package

Stereotype=Dimension Package

ToolTip=Creates a Dimension Package\nDimension Package

Analiza va începe cu modelarea cazurilor de utilizare prin identificarea actorilor ce

vor interacţiona cu sistemul, a cazurilor de utilizare principale identificate pe baza

cerinţelor de afaceri, va continua cu analiza datelor şi metadatelor modelate în UML prin

intermediul diagramelor de clase şi de interacţiune.

219

Modelarea cazurilor de utilizare (Use Case View)

Identificarea actorilor prezenţi în sistem. In cadrul sistemului un actor principal –

Manager Executiv care reprezintă un grup de utilizatori ai sistemului. Aceştia sunt divizaţi

pe diverse nivele ierarhice, conform organigramei funcţionale a organizaţiei şi sunt în

principal managerii implicaţi în procesul decizional pe diferite nivele.

Figura 10.1. Actorii prezenţi în sistem

Identificarea cazurilor de utilizare

Pentru a putea fi gestionat mai uşor, sistemul a fost împărţit în pachete în funcţie de

subsistemele implicate în realizarea EIS (figura 10.2).

220

Use Case - Nivelul 0:

Figura 10.2. Diagrama Use Case - Nivel 0

Se detaliază în continuare pachetele şi se obţin următoarele diagrame:

221

Use Case - Nivelul 1- Activitatea Economică:

Figura 10.3. Diagrama Use Case - Nivel 1- Activitatea Economică

Cazurile de utilizare prezente în cadrul diagramei se referă la modelarea cerinţelor

referitoare la indicatorii economici - fluxul de numerar (cash flow), tabloul indicatorilor de

gestiune şi a celor financiari, bugetare şi urmărirea realizărilor.

222

Use Case - Nivelul 1- Activitatea Comercială:

Figura 10.4. Diagrama Use Case – Nivel 1- Activitatea Comercială

Cazurile de utilizare prezentate se referă la modelarea cerinţelor de analiză a

activităţii comerciale: aprovizionare, desfacere, stocuri.

Se detaliază diagrama Use Case pentru pachetul subsistemului OLAP pentru

modelarea operaţiilor specifice: analiza evoluţiei (previziuni, istorice, top-bottom, scenarii

What If), rotaţii şi schimbarea perspectivei şi viziunii asupra tabloului de bord, aplicarea

unor parametrii pentru selectarea datelor, etc.

223

Figura 10.5. Diagrama Use Case – Selectarea parametrilor

Pentru o înţelegere mai bună a proceselor de analiză au fost create diagramele de

activităţi care să detalieze cazurile de utilizare:

Figura. 10.6. Diagrama de activităţi pentru procesul de analiză a indicatorilor

Analiza domeniului claselor In continuare sunt analizate sursele de date, sunt studiate diagramele ER ale

modulelor funcţionale din sistemul ERP disponibile în manualele tehnice. După acest pas,

sunt identificate dimensiunile sistemului şi modul în care vor fi transformate sursele în

destinaţii. Din discuţiile cu reprezentanţii organizaţiei se stabilesc pentru analiza

multidimensională următoarele dimensiuni principale:

• Sucursală sau unitate - sunt necesare două ierarhii – ierarhia administrativă:

organizaţie->sucursală->locaţie şi o ierarhie geografică: ţară->zona->oraş->locaţie.

• Produs - se va utiliza ierarhia contabilă de clasificare (în funcţie de conturile

contabile) şi o altă ierarhie pe tipuri de produse: grupă->categorie->produs

• Client – sunt ierarhizaţi în corelaţie cu zona, sucursala şi tipul clientului.

• Furnizor - sunt ierarhizaţi în corelatie cu zona, sucursala şi tip furnizor şi o altă

ierarhizare pe două nivele interni şi externi.

• Timp - se va utiliza ierarhia standard an->trimestru->luna->decadă->zi

Modelarea comportamentului static al sistemului şi a relatiilor dintre clase se

realizează prin diagrama de clase. Se identifică clasele şi legăturile dintre acestea, atât

pentru clasele dimensiune cât şi pentru clasele fapte.

Fiecare clasă va utiliza un anumit stereotip din şablonul prezentat în tabelul 8.2.

Definirea stereotipurilor pentru modelarea sitemului EIS, astfel: clasele dimensiune au

stereotipul <<dimension>>, iar clasele de fapte poartă stereotipul <<fact>>.

Figura.10.7. Diagrama de clase principală

226

In urma analizei cerinţelor rezultă următoarele clase:

Clase dimensiuni – sunt specificate utilizand stereotipul <<Dimension>>:

• Regiuni – reprezintă dimensionarea variabilelor în funcţie de aria geografică.

Această dimensiune prezintă o structură ierarhică: Ţara-> Zona -> Oraş ->Locaţie.

• Unităţi – reprezintă dimensiuea pe care se urmăresc unităţile organizatorice:

Organizaţie-> Sucursala -> Punct de lucru

• Plan Conturi – activitatea financiară este urmărită şi în funcţie de conturile

contabile, din acest motiv se va utiliza ierarhia contabilă obişuită: Clasa-> Cont

Sintetic -> Cont .

• Timp – reprezintă perioada de timp pe care se realizează analiza şi prezintă

structura ierarhică următoare: An->Trimestru->Luna->Zi;

Clase fapte – este specificată utilizând stereotipul <<Fact>>:

• Indicatori de performanţă – conţine atribute şi formule referitoare la indicatorii de

performanţă prezenţi în tabloul de bord (indicatori privind lichiditatea, indicatori de

risc, indicatori de profitabilitate, alţi indicatori privind activitatea întreprinderii).

Clasele de fapte prezintă un comportament dinamic care se modelează cu ajutorul

diagramelor de stare. Se prezintă în continuare diagrama de stare pentru clasa de fapte

Indicatori Financiari:

Figura. 10.8. Diagrama de stare pentru clasa Indicatori Financiari

Pentru celelalte clase de fapte stările şi tranziţiile sunt similare.

Modelarea comportamentului dinamic al sistemului şi a interacţiunii dintre

clase.

227

Comportamentul dinamic rezultă în principal din operaţiile executate asupra bazei

de date multidimensionale, cum ar fi Roll-Up/Drill Down, secţiuni, rotaţii, previziuni,

What-If şi analiza Top-Bottom.

In continuare sunt prezentate diagramele de secvenţă pentru analiza indicatorilor:

Operaţia de navigare în cadrul nivelelor dimensiunilor - Roll-Up/Drill Down

Figura. 10.9. Diagrama de secvenţă pentru operaţia de Roll-Up

Diagrama de colaborare este prezentată în figura 10.10:

228

Figura. 10.10. Diagrama de colaborare pentru operaţia de Roll-Up

Pentru operaţia de navigare pe nivelele ierarhice inferioare, pentru detalierea

informaţiilor se realizează separat şi este modelată prin urmatoarele diagrame:

229

Figura. 10.11. Diagrama de secvenţă pentru operaţia de Drill Down

Fig. 10.12. Diagrama de colaborare pentru operaţia de Drill Down

Schimbarea perspectivelor asupra datelor se poate modela prin diagrame de

secvenţă, figurile 10.13 – 10.14:

230

Figura 10.13. Diagrama de secvenţă pentru operaţiile de schimbare a viziunii asupra

datelor

Figura 10.14. Diagrama de colaborare pentru operaţiile de schimbare a viziunii asupra

datelor

231

Operaţiile de tipul previziunilor, scenariilor “ce se întâmplă dacă”, algoritmilor de

extragere a cunoştinţelor din tabelele de fapte sunt modelate prin următoarele diagrame:

Figura 10.15. Diagrama de secvenţă pentru operaţii de analiză OLAP

Figura 10.16. Diagrama de colaborare pentru operaţii de analiză OLAP

Etapa 4: Proiectarea sistemului

Această etapă se va realiza tot cu ajutorul limbajului UML prin detalierea

diagramelor de clase şi de interacţiune şi presupune parcurgerea paşilor 8, 9, 10:

proiectarea bazei de date, proiectarea procesului ETL (extragere / transformare /

încărcare (load)) şi proiectarea dicţionarului metadatelor (metadata repository)

Proiectarea arhitecturală In aceasta etapă se identifică principalele pachete ale aplicaţiei, se grupează clasele

în pachete şi se realizează diagrama de pachete. Gruparea claselor în pachete se face astfel:

La nivelul întregului sistem se identifică trei pachete după cum urmează: pachetul

Business Services sau al afacerii care conţine clasele soluţiei principale, pachetul Data

Services în care sunt grupate clasele de acces la date, tabelele şi depozitul de date şi

pachetul User Services în care se vor modela clasele ce asigură interfaţa cu utilizatorul.

Diagrama de pachete la nivel logic este următoarea:

Figura 10.17. Diagrama de pachete la nivel logic

La nivelul soluţiei sistemului sau Business Services se grupează clasele pe trei

pachete principale – Financiar, Comercial şi Strategic în funcţie de modulul funcţional din

care se vor prelua datele.

Figura 10.18. Diagrama de pachete la nivelul soluţiei de afaceri

233

Pentru fiecare clasă dimensiune se realizează un pachet în care se vor modela

nivelele ierarhice ale acestora. Pachetele identificate sunt: PUNITATI, PREGIUNI,

PTIMP, PCONT, PPRODUSE, PCLIENT, PFURNIZOR. Pachetele au specificat

stereotipul <<Dimension Package>> pentru a le diferenţia de cele de tipul standard.

Figura 10.19. Diagrama de pachete din modulul comercial

Proiectarea detaliată In aceasta etapă se detaliază conţinutul pachetelor, se stabilesc principalele atribute

şi operaţii din clase. Se realizează diagramele de clase detaliate pentru nivelul soluţiei –

Business Services. În cadrul acestora vor fi utilizate stereotipurile pentru precizarea

nivelelor ierarhice: <<Base>> pentru nivelul de bază, <<Level>> pentru nivele

intermediare şi <<Dimension>> pentru superclasa dimensiune. În realizarea asocierii

dintre superclasa dimensiune şi nivelul de bază al acesteia se utilizează stereotipul

<<DAG>> , iar între nivelele superioare şi cele inferioare tipul legăturii va fi de 1: 1..n.

Diagramele de clase pentru pachetele de dimensiuni sunt prezentate în continuare:

234

PREGIUNI

Figura 10.20. Diagrama de clase pentru pachetul PREGIUNI

Descrierea claselor:

Regiuni – reprezintă dimensiunea regiuni specificată cu stereotipul <<Dimensions>>.

Atribute:

IDRegiune – identificator specificat cu stereotipul <<OID>>

Descriere – scurtă descriere a dimensiunii, specificat cu stereotipul <<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

235

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

Dimensiunea Regiuni se structurează pe patru nivele ierarhice: Locatie, Oras, Zona, Tara.

Pentru aceste nivele ierarhice se construiesc patru clase:

Locatie – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

IDLocatie – identificator specificat cu stereotipul <<OID>>.

Denumire – denumirea locatiei, specificat cu stereotipul <<OD>>.

Adresa – sediul locaţiei respective, este un atribut precizat cu stereotipul

<<Dimension Attribute>>

ID Oras – identificatorul nivelului superior specificat cu stereotipul

<<ParentID>>.

Oras – reprezintă un nivel în ierarhie. Este specificată cu stereotipul << Level>>.

Atribute:

IDOras – identificator specificat cu stereotipul <<OID>>.

Nume – denumirea oraşului, specificată cu stereotipul <<OD>>.

ID Zona – identificatorul nivelului superior, al zonei din care face parte oraşul. Este

specificat cu stereotipul <<ParentID>>.

Zona – reprezintă nivelul superior oraşului. Este specificată cu stereotipul <<Level>>.

Atribute:

IDZona – identificator specificat cu stereotipul <<OID>>.

Denumire – precizarea zonei, se specifică prin stereotipul <<OD>>.

ID Tara – identificatorul nivelului superior, al ţării din care face parte zona. Este

specificat cu stereotipul <<ParentID>>.

Tara – reprezintă nivelul superior al ierarhiei. Este specificată cu stereotipul <<Level>>.

Atribute:

IDTara – identificator specificat cu stereotipul <<OID>>.

Denumire – numele ţării, se specifică prin stereotipul <<OD>>.

236

PUNITATI

Figura 10.21. Diagrama de clase pentru pachetul PUNITATI

Descrierea claselor:

Unitati – reprezintă dimensiunea unităţi specificată cu stereotipul <<Dimensions>>.

Atribute:

IDUnitate – identificator specificat cu stereotipul <<OID>>

Unitate – scurtă descriere a dimensiunii, specificat cu stereotipul <<OD>>

TipUnitate – identifică tipul şi rolul unităţii în cadrul organizaţiei. Este specificat cu

stereotipul <<Dimension Attribute>>

Descriere – o scurtă prezentare a unităţii, atrinutul este specificat cu stereotipul

<<Dimension Attribute>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

237

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

Dimensiunea Unitati se structurează pe trei nivele ierarhice: Punct de lucru, Sucursala,

Organizaţie. Pentru aceste nivele ierarhice se construiesc trei clase diferite:

Punct Lucru – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul

<<Base>>.

Atribute:

IDPunct – identificator specificat cu stereotipul <<OID>>.

Nume – denumirea punctului de lucru, specificat cu stereotipul <<OD>>.

Adresa – sediul locaţiei respective, este un atribut precizat cu stereotipul

<<Dimension Attribute>>

Info – alte informaţii utile legate de punctul de lucru respectiv, precizat cu

stereotipul <<Dimension Attribute>>

ID Sup – identificatorul nivelului superior specificat cu stereotipul <<ParentID>>.

Sucursala – reprezintă un nivel în ierarhie. Este specificată cu stereotipul << Level>>.

Atribute:

IDsucursala – identificator specificat cu stereotipul <<OID>>.

Nume – denumirea sucursalei respective, specificată cu stereotipul <<OD>>.

ID Org – identificatorul nivelului superior, al organizaţiei din care face parte

sucursala. Este specificat cu stereotipul <<ParentID>>.

Organizatie – reprezintă nivelul superior în ierarhie. Este specificată cu stereotipul

<<Level>>.

Atribute:

IDOrganizatie – identificator specificat cu stereotipul <<OID>>.

Descriere – scurtă descriere a organizaţiei, se specifică prin stereotipul <<OD>>.

În cadrul acestei dimensiuni este utiliă şi o ierarhizare a unităţilor organizatorice în funcţie

de locaţia geografică pentru a facilita analiza pe arii şi zone de distribuţii. Din acest motiv

clasa de bază a dimensiunii – Punct Lucru, va fi legată de nivelele ierarhice ale dimensiunii

Regiuni prin clasa de bază Locatie.

238

PTIMP

Figura 10.22. Diagrama de clase pentru pachetul PTIMP

Descrierea claselor:

Timp – reprezintă dimensiunea timp specificată cu stereotipul <<Dimensions>>.

Atribute:

IDTimp – identificator specificat cu stereotipul <<OID>>

Perioada – scurtă descriere a perioadei de timp analizată, specificat cu stereotipul

<<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

239

Dimensiunea Timp se structurează pe cinci nivele ierarhice, dar se pot construi două

ierarhii paralele astfel: zi, săptămâna sau decadă, luna, trimestrul şi anul. Pentru aceste

nivele ierarhice se construiesc următoarele clase:

Zi – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

IDZi– identificator specificat cu stereotipul <<OID>>.

Ziua – precizarea zilei, specificată cu stereotipul <<OD>>.

ID Sup – identificatorul nivelului superior specificat cu stereotipul <<ParentID>>.

Saptamana – reprezintă un nivel în ierarhie. Este specificată cu stereotipul << Level>>.

Atribute:

IDSaptamana – identificator specificat cu stereotipul <<OID>>.

Saptamana – precizarea săptămânii, specificată cu stereotipul <<OD>>.

ID Sup– identificatorul nivelului superior, al lunii din care face parte. Este

specificat cu stereotipul <<ParentID>>.

Decada – reprezintă un nivel în ierarhie. Este specificată cu stereotipul <<Level>>.

Atribute:

IDDecada – identificator specificat cu stereotipul <<OID>>.

Decada – scurtă descriere a periadei de 10 zile, se specifică prin stereotipul

<<OD>>.

ID Sup– identificatorul nivelului superior, al lunii din care face parte decada. Este

specificat cu stereotipul <<ParentID>>.

Luna – reprezintă un nivel în ierarhie. Este specificată cu stereotipul <<Level>>.

Atribute:

IDLuna – identificator specificat cu stereotipul <<OID>>.

Luna – numele lunii, se specifică prin stereotipul <<OD>>.

ID Sup– identificatorul nivelului superior, al trimestrului din care face parte luna.

Este specificat cu stereotipul <<ParentID>>.

Trimestrul – reprezintă un nivel în ierarhie. Este specificată cu stereotipul <<Level>>.

Atribute:

IDTrimestru – identificator specificat cu stereotipul <<OID>>.

Trimestrul– numele trimestrului, se specifică prin stereotipul <<OD>>.

ID Sup– identificatorul nivelului superior, al anului din care face parte. Este

specificat cu stereotipul <<ParentID>>.

Anul – este nivelul superior. Este specificată cu stereotipul <<Level>>.

240

Atribute:

IDAn – identificator specificat cu stereotipul <<OID>>.

Anul – anul respectiv, se specifică prin stereotipul <<OD>>.

PCONT

Figura 10.23. Diagrama de clase pentru pachetul PCONT

Descrierea claselor:

Plan Conturi – reprezintă dimensiunea contabilă în funcţie de care se va face analiza

financiară. Este specificată cu stereotipul <<Dimensions>>.

Atribute:

ID Plan Cont – identificator specificat cu stereotipul <<OID>>

Descriere Plan – scurtă descriere a dimensiunii contabile, specificată cu stereotipul

<<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

241

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

Dimensiunea Cont se structurează pe trei nivele ierarhice, astfel: cont, cont sintetic, clasa.

Pentru aceste nivele ierarhice se construiesc următoarele clase:

Cont – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

IDCont– identificator specificat cu stereotipul <<OID>>.

Denumire cont – precizarea numelui contului, specificată cu stereotipul <<OD>>.

Descriere – scurtă descriere a funcţionalităţii contului, specificată cu stereotipul

<<Dimension Attribute>>.

Tip Cont – tipul contului, specificat cu stereotipul <<Dimension Attribute>>.

ID Sup – identificatorul nivelului superior, al contului sintetic căruia îi aparţine

specificat cu stereotipul <<ParentID>>.

Cont Sintetic – reprezintă un nivel în ierarhie. Este specificat cu stereotipul << Level>>.

Atribute:

ID Cont Sintetic – identificator specificat cu stereotipul <<OID>>.

Descriere– descrierea funcţionalităţii, specificată cu stereotipul <<OD>>.

ID Clasa– identificatorul nivelului superior, al clasei din care face parte. Este

specificat cu stereotipul <<ParentID>>.

Clasa – este nivelul superior. Este specificată cu stereotipul <<Level>>.

Atribute:

IDClasa – identificator specificat cu stereotipul <<OID>>.

Descriere– precizarea funcţionalitătii clasei contabile, se specifică prin stereotipul

<<OD>>.

242

PPRODUSE

Figura 10.24. Diagrama de clase pentru pachetul PPRODUSE

Descrierea claselor:

Produse – reprezintă dimensiunea produs în funcţie de care se va face analiza comercială.

Este specificată cu stereotipul <<Dimensions>>.

Atribute:

ID Dim Produse – identificator specificat cu stereotipul <<OID>>

Descriere– scurtă descriere a dimensiunii, specificată cu stereotipul <<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

243

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

Dimensiunea Produse se structurează pe trei nivele ierarhice, astfel: produs, categorie,

grupa. Pentru aceste nivele ierarhice se construiesc următoarele clase:

Produs – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

IDProdus – identificator specificat cu stereotipul <<OID>>.

Denumire – numele produsului, specificată cu stereotipul <<OD>>.

Tip produs – tipul produsului, specificat cu stereotipul <<Dimension Attribute>>.

Caracteristici – scurtă descriere a proprietăţilor produsului, specificată cu

stereotipul <<Dimension Attribute>>.

ID Categorie – identificatorul nivelului superior, al categoriei din care face parte

specificată cu stereotipul <<ParentID>>.

ID Punct – identificatorul punctului de lucru căruia îi aparţine specificat cu

stereotipul <<ParentID>>.

Categorie – reprezintă un nivel în ierarhie. Este specificat cu stereotipul << Level>>.

Atribute:

ID Categorie – identificator specificat cu stereotipul <<OID>>.

Denumire – descrierea categoriei, specificată cu stereotipul <<OD>>.

Specificatii – descrierea atributelor şi caracteristicilor categoriei, specificată cu

stereotipul << Dimension Attribute >>.

ID Grupa– identificatorul nivelului superior, al grupei de produse din care face

parte. Este specificat cu stereotipul <<ParentID>>.

Grupa – este nivelul superior. Este specificată cu stereotipul <<Level>>.

Atribute:

IDGrupa – identificator specificat cu stereotipul <<OID>>.

Denumire – precizarea denumirii grupei de produse, se specifică prin stereotipul

<<OD>>.

Specificatii – descrierea atributelor şi caracteristicilor grupei, specificată cu

stereotipul << Dimension Attribute >>.

Se observă că fiecare produs se află în asociere directă cu un anumit punct de lucru din

cadrul organizaţiei pentru a realiza cât mai uşor o analiză a stocurilor pe unităţi şi arii

geografice.

244

PCLIENT

Figura 10.25. Diagrama de clase pentru pachetul PCLIENTI

Descrierea claselor:

Clienti – reprezintă dimensiunea client în funcţie de care se va face analiza comercială.

Este specificată cu stereotipul <<Dimensions>>.

Atribute:

ID Dim Clienti – identificator specificat cu stereotipul <<OID>>

Descriere– scurtă descriere a dimensiunii, specificată cu stereotipul <<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

245

Dimensiunea Clienti se structurează pe două nivele ierarhice, astfel: client şi clasa client.

Pentru aceste nivele ierarhice se construiesc următoarele clase:

Client – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

IDClient – identificator specificat cu stereotipul <<OID>>.

Denumire – numele clientului, specificat cu stereotipul <<OD>>.

Locatie – adresa, specificată cu stereotipul <<Dimension Attribute>>.

Tip Client – precizarea tipului de client, specificată cu stereotipul <<Dimension

Attribute>>.

ID Locatie – identificatorul locaţiei geografice din care face parte specificată cu

stereotipul <<ParentID>>.

ID Clasa – identificatorul nivelului superior, al clasei, specificat cu stereotipul

<<ParentID>>.

Clasa client – reprezintă nivelul superior. Este specificat cu stereotipul << Level>>.

Atribute:

ID Clasa – identificator specificat cu stereotipul <<OID>>.

Descriere – descrierea clasei, specificată cu stereotipul <<OD>>.

Dimensiunea Client este asociată cu dimensiunea Regiuni pentru a putea realiza şi o

analiză a distribuţiei geografice a clienţilor pe oraşe, zone, ţări.

246

PFURNIZOR

Figura 10.26. Diagrama de clase pentru pachetul PFURNIZORI

Descrierea claselor:

Furnizori – reprezintă dimensiunea furnizor în funcţie de care se va face analiza

comercială. Este specificată cu stereotipul <<Dimensions>>.

Atribute:

ID Dim Furnizori – identificator specificat cu stereotipul <<OID>>

Descriere– scurtă descriere a dimensiunii, specificată cu stereotipul <<OD>>

Operaţii:

Select() – permite serverului OLAP selecţia nivelelor prin intermediul obiectelor

grafice de selecţie şi limitare a valorilor

Slice() – permite realizarea unor secţiuni în cadrul datelor pe dimensiune

Roll Up() – operaţia de agregare a valorilor pe nivelele ierarhice superioare

Drill Down() - operaţia de detaliere a valorilor pe nivelele ierarhice inferioare

Dimensiunea Furnizori se structurează pe două nivele ierarhice, astfel: furnizor şi clasa

furnizor. Pentru aceste nivele ierarhice se construiesc următoarele clase:

247

Furnizor – reprezintă clasa de bază a ierarhiei. Este specificată cu stereotipul <<Base>>.

Atribute:

ID Furnizor – identificator specificat cu stereotipul <<OID>>.

Denumire – numele furnizorului, specificat cu stereotipul <<OD>>.

Locatie – adresa, specificată cu stereotipul <<Dimension Attribute>>.

Tip Furnizor – precizarea tipului de furnizor, specificată cu stereotipul

<<Dimension Attribute>>.

ID Locatie – identificatorul locaţiei geografice din care face parte specificată cu

stereotipul <<ParentID>>.

ID Clasa – identificatorul nivelului superior, al clasei, specificat cu stereotipul

<<ParentID>>.

Clasa furnizor – reprezintă nivelul superior. Este specificat cu stereotipul << Level>>.

Atribute:

ID Clasa – identificator specificat cu stereotipul <<OID>>.

Descriere – descrierea clasei, specificată cu stereotipul <<OD>>.

Dimensiunea Furnizor este asociată cu dimensiunea Regiuni pentru a putea realiza şi o

analiză a distribuţiei geografice pe oraşe, zone, ţări.

După finalizarea detalierii claselor şi pachetelor de tipul dimensiune se rafinează şi

clasele de fapte, prin stabilirea atribuelor li operaţiilor acestora. Sunt detaliate clasele de

fapte şi se realizează diagramele de clase complete la nivelul pachetului Business Services,

pe fiecare subpachet, respectiv Comercial, Financiar şi Strategic:

Figura 10.27 . – Diagrama de clase completă pentru modulul comercial

249

Figura 10.28 . – Diagrama de clase completă pentru modulul financiar

250

Figura 10.29 . – Diagrama de clase completă pentru modulul strategic

După finalizarea detalierii pachetului Business Services, se trece la modelarea datelor.

Pachetul Data Services va fi detaliat şi descompus pe două pachete pentru a putea grupa

clasele pe nivelele depozitului de date respectiv al surselor şi bazelor de date:

Figura 10.30 . – Diagrama de pachete pentru Data Services

Se schiţează şi entităţile din depozitul de date referitoare la indicatorii strategici:

Figura 10.31 . – Diagrama de clase pentru modulul Indicatorilor de performanţă la

nivelul depozitului de date

Obiectele din aceste pachete vor fi modelate cu ajutorul unui mediu integrat de proiectare

şi dezvoltare a depozitelor de date, de exemplu Oracle Warehouse Builder 10g.

252

Etapa 5: Construirea sistemului

Etapa de construcţie a sistemului începe odată cu programarea efectivă a

claselor modelate şi presupune şi realizarea paşilor 11, 12, 13, 14 şi anume:

Construirea procesului ETL, Construirea aplicaţiei, Extragrea cunoştinţelor din

date (Data Mining), Construirea depozitului metadatelor. Mai întâi se realizează

diagrama de componente astfel încât pachetelor de la nivelul logic le corespunde cate

o componentă în viziunea componentelor.

«executable»

Componente interfata

Componente acces BDComponente Clase

Figura 10.32. Diagrama de componente

Pentru modelul fizic al sistemului se realizează diagrama de desfăşurare.

Arhitectura sistemului va cuprinde un server de baze de date cu facilităţi

multidimensionale, un server de aplicaţii pentru rularea rapoartelor şi videoformatelor

care vor fi integrate la nivelul unui Portal la nivelul întregii organizaţii. Utilizatorii

vor accesa sistemul EIS prin intermediul calculatoarelor personale sau dispozitive

mobile.

Figura10.33. Diagrama de desfăşurare

253

Sistemul va fi implementat într-un mediu integrat de dezvoltare care va

permite realizarea depozitului de date, a tipurilor de obiecte specifice, a operaţiilor şi

a facilităţilor de analiză modelate prin diagramele prezentate în aceste etape.

Pentru realizarea depozitului de date la nivel centralizat voi utiliza mediul

Oracle Warehouse Builder şi pentru construirea aplicaţiei şi a rapoartelor Oracle

Business Intelligence Discoverer. Voi opta şi pentru realizarea în variantă virtuală a

unei părţi a depozitului de date deoarece anumite informaţii sunt cerute imediat, deci

extragerea trebuie realizată online.

E5.1. Construirea depozitului de date centralizat în ORACLE

WAREHOUSE BUILDER 10g (OWB)

Această sub-etapă presupune pargurgerea unor paşi cum ar fi definirea

surselor de date din sistemul operaţional, construirea obiectelor multidimensionale,

definirea procesului de extragere şi încărcare a datelor (ETL) şi în final stabilirea

perioadelor de actualizarea şi de încărcare a datelor în depozit. Toate aceste activităţi

sunt prezentate pe larg în Anexa 1 a lucrării.

E5.2. Realizarea depozitului virtual în ORACLE BUSINESS

INTELLIGENCE DISCOVERER ADMINISTRATOR 10g

Realizarea depozitului virtual presupune construirea unui set de tabele virtuale

şi a nivelului intermediar, a metadepozitului şi a obiectelor de tipul Folders, a

ierarhiilor şi legăturilor între obiecte. Realizarea depozitului virtual este prezentată pe

larg în Anexa 2.

E5.3. Realizarea interfeţei, a rapoartelor şi prezentărilor cu Oracle BI

Discoverer Desktop 10g

Mediul Oracle BI Discoverer Desktop permite construirea de rapoarte

complexe şi flexibile pe baza Business Area şi a folderelor definite anterior în Oracle

Discoverer Administrator. Analiza datelor se realizează prin aplicarea următoarelor

tipuri de operaţii asupra datelor:

• Navigarea pe nivelele ierarhice (Drill Down şi Roll Up) – reprezintă operaţii

de navigare în cadrul ierarhiilor dimensiunilor, prin agregare pe nivelele

superioare (roll-up sau drill-up) sau detaliere pe nivelele inferioare (drill-

down). Cu toate ca operaţiile se pot realiza dinamic, pentru a economisi timp

şi resurse se preferă uneori pre-calcularea unor valori globale prin însumare

sau agregare. Aceste agregări se referă la o anumită măsură şi se realizează

după dimensiunile corespunzatoare acesteia. Aceste operaţii implică de cele

254

mai multe ori doar calcularea unor totaluri, dar există şi excepţii în care se

utilizează formule sau procedee statistice. Prin facilitatea de drill down,

utilizatorii pot naviga pe nivele cu un grad de detaliu mai accentuat. Prin roll

up sau drill up se pot vizualiza datele la un nivel agregat.

• Rotaţii – Acestea reprezintă operaţiile cele mai uzuale realizate aupra datelor

în rapoartele de analiză. Ele oferă utilizatorului posibilitatea de a alege

perspectiva asupra datelor pe care o va utiliza. Fiecare rotaţie pune în evidenţă

o nouă perspectivă, aducând în prim plan o structură bidimensională, o faţetă

(slice). Din acest motiv rotaţia se mai numeste şi “data slicing”. Aceste

operaţii nu implică o reorganizare a datelor stocate, ci o schimbare a

modalităţii de reprezentare.

• Secţiuni – Oferă viziuni sau imagini (views) prin operaţii de secţionare prin

care se obţin “felii” (slices). Tehnica aceasta constă în limitarea unor atribute

la anumite valori şi obţinerea unui cub de date redus (procedeu numit data

dicing).

Paşii parcurşi pentru realizarea aplicaţiei sunt prezentaţi în detaliu în Anexa 3.

Interfeţele finale pot fi vizualizate şi în figurile următoare:

Figura 10.34. Videoformatul pentru analiza indicatorilor economici

255

Figura 10.35. Videoformatul pentru analiza grafică indicatorilor economici

Figura 10.36. Videoformatul pentru analiza indicatorilor financiari ai activităţii

comerciale

256

Figura 10.37. Videoformatul pentru analiza indicatorilor comerciali

Rapoartele construite în Oracle Discoverer sunt flexibile, uşor de modificat de

către utilizatorii finali şi dispun de instrumente puternice de analiză pentru realizarea

operaţiilor de navigare în cadrul dimensiunilor, rotaţii, secţiuni şi construirea de

variabile noi cu ajutorul unor funcţii de analiză. Rapoartele pot fi integrate în cadrul

aplicaţiilor Oracle existente în companie prin intermediul Oracle Portal sau prin

Oracle E-Business Suite.

E5.4. Realizarea portalului de inteligenţa afacerii cu Oracle Portal

Cu ajutorul suitei Oracle Application Server 10g release 2 şi a componentei

Oracle Portal se trece la construirea portalului de inteligenţa afacerii. Acesta este

compus din trei sectiuni:

• Home unde se regăsesc informaţii utile, prezentarea pe scurt a facilităţilor

Portalului, legături catre ERP-ul existent, curs valutar, etc.

• Financiar unde sunt legături către rapoartele din Oracle Discoverer realizate

pentru departamentul economic, precum şi manualele şi documentaţia

necesaăa utilizării acestora.

257

• Comercial sunt legături către rapoartele din Oracle Discoverer realizate pentru

departamentul comercial, precum şi manualele şi documentaţia necesară

utilizării acestora.

Utilizarea este simplă, de exemplu pentru accesarea rapoartelor

departamentului economic se alege secţiunea Departamentul Economic şi se deschide

fereastra principală:

Figura 10.38: Pagina principală a portalului de inteligenţa afacerii

Figura 10.39: Secţiunea rapoartelor pentru activitatea economică din cadrul

portalului

258

Figura 10.40: Secţiunea rapoartelor pentru activitatea comerciaăl din cadrul

portalului

In partea stângă este o listă completă a rapoartelor care se pot deschide. Sunt

rapoartele din Oracle BI Discoverer Desktop integrate în portal cu ajutorul unor

elemente numite portlets. Lista este funcţională, în sensul că prin expandarea şi

alegerea unui raport, acesta se deschide într-o altă fereastră.

259

Etapa 6: Implementarea sistemului

Pas 15: Implementarea propriu-zisă – sunt organizate instructaje de utilizare

pentru managerii implicaţi, se asigură suportul tehnic necesar, se rulează procedurile

de încărcare a datelor, de instalare a aplicaţiei, de monitorizare a performanţelor. Sunt

completate manualele de prezentare, de utilizare şi configurare, procedurile de lucru

pe fiecare modul în parte, sunt testaţi utilizatorii şi funcţionalităţile sistemului.

Etapa se încheie cu intrarea efectivă în producţie a sistemului şi livrarea

utilitarelor şi a documentaţiei finale a proiectului, a manualelor de utilizare şi de

prezentare a aplicaţiei.

Acest pas durează aproximativ 1-2 luni pentru finalizarea instruirii, a testării

sistemului şi a trecerii în producţie atât în sediul central cât şi în unităţile din ţară.

Pas 16: Evaluarea sistemului – Se organizează o sesiune de discuţii cu

managerii implicaţi pentru a trage concluziile finale referitoare la implicaţiile

sistemului, se evaluează costurile, se identifică anumite puncte slabe ale proiectului

pentru a fi înlăturate pe viitor, se fac o serie de recomandări pentru îmbunătăţirea

performanţelor. Sunt realizate o serie de ajustări în proiectul existent referitoare la

schimbările din planul de conturi, anumite conturi nu mai sunt valabile şi sunt

înlocuite cu altele, dar fără modificări majore în cadrul sistemului.

Pornind de la motto – ul lucrării: “Valoarea sistemului depinde de cât de

folositor este executivilor, de cât de bine este înteles şi cât de mult este utilizat”

[DERO92]. Din acest motiv se trece la evaluarea sistemului pe baza criteriilor

propuse în capitolul VII:

Criteriu de

performanţă

Gradul de îndeplinire

Suport decizional Ridicat - sistemul nu prezintă doar datele ci oferă

instrumente necesare analizei dinamice, decizionale.

Analiza cerinţelor de afaceri, modelarea proceselor de

afaceri şi subordonarea întregului ciclu de dezvoltare în

faţa acestor aspecte a condus la obţinerea unui sistem

informatic suport de decizie, atât la nivele departamentale,

tactice, cât mai ales la nivel strategic. Din aceste

considerente criteiul este îndeplinit.

Performanţa Ridicat – Construirea depozitului de date centralizat cu

260

date istorice din perioade mai mari de 3 luni şi în paralel a

depozitului virtual cu date recente face ca sistemul să

răspundă rapid la interogări şi analize. Un alt aspect al

performanţei îl constituie succesul realizării procesului

ETL pentru transformarea şi prelucrarea datelor şi

încărcarea acestora în depozit. Timpul de răspuns al

sistemului este mic, datele extrase sunt coerente şi corecte,

deci sistemul respectă criteriile de performanţă cerute.

Interfaţa prietenoasă Ridicat – Interfaţa realizată permite prezentarea

informaţiilor atât grafic cât şi tabelar, exportul datelor în

foi de calcul, are toate funcţioalităţile OLAP de analiză

dinamică (rotaţii, secţiuni, navigări pe ierarhii), rapoartele

dinamice sunt integrate în portalul de inteligenţa afacerii

pentru a oferi un acces rapid şi direct la analize, utilizatorii

nu au nevoie de cunoştinţe avansate pentru manevrarea

sistemului. În concluzie, datorită acestor caracteristici,

sistemul întruneşte toate condiţiile pentru respectarea

acestui criteriu.

Flexibilitate Mediu – Din punct de vedere al aspectelor tehnice sistemul

este flexibil şi se poate adapta uşor schimbărilor

tehnologice, însă din punctul de vedere al organizării

fluxurilor decizionale în cadrul societăţii, la schimbări

majore sunt necesare şi reproiectări ale sistemului. Din

aceste motive consider că acest criteriu este parţial

îndeplinit.

Scalabilitate Ridicat – Datorită depozitului de date centralizat şi a ERP-

ului existent sistemul se poate redimensiona în funcţie de

structura organizaţiei şi de mediul de afaceri fără a pierde

din performanţă, din acest punct de vedere consider că

acest criteriu este îndeplinit.

Mentenanţa Ridicat – Din punct de vedere tehnologic este prevăzută

deja introducerea unor instrumente şi tehnologii noi, de

exemplu accesul se face prin intermediul portalului şi se

261

Tabelul 10.2. – Analiza modului de îndeplinire a criteriilor de performanţă de către

sistemul informatic executiv construit

In concluzie, studiul de caz propus a urmărit realizarea unui sistem informatic

executiv în cadrul unei organizaţii multinaţionale, respectând fazele şi paşii descrişi

în capitolele teoretice anterioare. Sistemul a fost structurat pe trei module principale

pentru modelarea activităţilor economice, comercialeşi strategice specifice.

Am construit un depozit de date atât la nivel centralizat pentru stocarea

datelor agregate pe perioadele mai mari de 3 luni, cât şi un depozit de date virtual

penru extragerea online a datelor curente din surse.

Interfaţa furnizează un front-end cu grafică flexibilă şi puternică.

Reprezentarea datelor este grafică şi tabelară. Utilizatorul îşi poate alege modul de

reprezentare ţinând cont de avantajele fiecăruia: reprezentarea grafică este usor de

interpretat, explorat şi analizat, iar cea tabelară este mai exactă.

Aplicaţia dezvoltată dispune de un set de mecanisme foarte puternice de

selecţie a datelor. Acest set de mecanisme serveşte la alegerea valorilor

dimensiunilor şi variabilelor ce sunt afişate într-o formă tabelară sau într-un grafic.

Tipurile folosite se pot alege dintr-o listă bogată de opţiuni incluzând selecţii de

valori care conţin un anumit subşir de caractere, care fac excepţie de la un criteriu,

care se situează pe un anumit nivel ierarhic sau au un anumit atribut. Sunt

implementate toate funcţionalităţile OLAP: navigare pe ierarhii, rotaţii, schimbări de

perspectivă, previziuni, analize dinamice.

oferă acces wireless, prin dispozitive mobile (laptop,

PDA). În ceea ce priveşte construirea unor module noi

acesta se poate face uşor prin extinderea modulelor

sistemului ERP şi prin construirea unor noi module în

actualul depozit de date. Deci, criteriu este îndeplinit.

Integrarea datelor din

surse multiple

Ridicat – Datorită implementării sistemului ERP în cadrul

organizaţiei, sursele de date ale sistemului, chiar dacă sunt

multiple şi variate, sunt integrate prin modulele

funcţionale. Alte informaţii din exteriorul organizaţiei nu

sunt supuse analizei, deci nu influenţează funcţionarea

sistemului. Din acest punct de vedere criteriul este

satisfăcut.

262

Integrarea rapoartelor în cadrul portalului de inteligenţa afacerilor face

posibil accesul direct la acestea, chiar şi cu jutorul dispozitivelor mobile, fără a fi

necesară instalarea sau dependenţa de o aplicaţie client.

In concluzie, sistemul informatic executiv realizat oferă managerilor

executivi posibilitatea de a analiza imediat şi complet acivitivatea organizaţiei, atât

la nivelul departamentelor şi al subactivităţilor, cât mai ales la nivel înalt, strategic,

de a lua decizii în timp real şi de a le fundamenta în baza acestor analize dinamice.

Sistemul realizat oferă atât un sistem suport de decizie la nivel tactic datorită

posibilităţilor de analiză a activităţilor economice şi comerciale, cât şi un sistem

informatic executiv destinat nivelului superior, strategic de decizie. Datorită

performanţelor şi a îndeplinirii tuturor criteriilor prezentate anterior, consider că

realizarea acestui sistem informativ executiv s-a finalizat cu succes.

263

CONCLUZII

Pornind de la definirea şi descrierea elementelor caracteristice ale

managementului strategic şi a problemelor apărute în cadrul procesului decizional al

acestui nivel, în societatea şi mediul economic actual, s-a conturat şi justificat

necesitatea elaborării unor soluţii informatice destinate asistării acestui proces. La

începutul lucrării s-au prezentat soluţiile informatice existente, soluţii cum ar fi

sistemele suport pentru decizii (DSS – decision support systems), sistemele

informatice pentru management (MIS – management information systems) şi

sistemele informatice executive (EIS – executive information systems). In urma

identificării şi descrierii componentelor şi caracteristicilor fiecăreia dintre aceste tipuri

de sisteme şi a analizei comparative a acestor soluţii am ajuns la concluzia că pentru

nivelul strategic al managementului soluţia informatică cea mai potrivită, care să

satisfacă toate cerinţele şi particularităţile acestui nivel, o reprezintă sistemele

informatice executive (Executive Information Systems).

In continuare, lucrarea s-a axat pe alegerea unei arhitecturi cu caracter general

pentru sistemele informatice executive, pe fiecare nivel al arhitecturii am identificat

componentele şi tehnologiile implicate. Concluzia desprinsă din aceste idei a fost că

sunt necesare elemente, funcţionalităţi şi facilităţi ale unor tehnologii de vârf, din

aria tehnologiilor de inteligenţa afacerilor (Business Intelligence) cum ar fi:

depozitele de date, OLAP, data mining, tehnologii web, algoritmi de extragere şi

optimizare a cererilor, tehnologii de realizare a interfeţelor dinamice şi complexe.

In partea a doua a lucrării am prezentat principalele soluţii de organizare a

datelor, de extragere a cunoştinţelor, de extragere şi prelucrare a datelor. Astfel, ca

principală soluţie de organizare a datelor am propus depozitele de date, atât din

punct de vedere centralizat, cu date agregate, preprocesate pe diverse niveluri şi

stocate în această formă, cât şi din punctul de vedere al organizării virtuale, al

realizării unui nivel superior de organizare a datelor la nivel logic în cadrul bazelor de

date relaţionale, cu posibilitatea de extragere a acestora în timp real. In continuare am

abordat problematica extragerii datelor din depozitele de date, în primul rând prin

intermediul tehnologiei OLAP, dar şi cu ajutorul unor funcţii analitice implementate

în limbajul SQL. Am tratat separat problema optimizării cererilor de regăsire cu

ajutorul unor algoritmi aplicaţi pe tipuri de interogări, atât pe sursele de date cât şi pe

264

depozitele de date virtuale unde modelul multidimensional impune condiţii de

interogare diferite.

In partea a treia am abordat modalităţile de realizare a sistemelor informatice

executive din punctul de vedere al ciclului de dezvoltare şi a metodologiilor prin care

se pot modela caracteristicile şi particularităţile specifice acestor tipuri de sisteme.

Referitor la ciclul de dezvoltare, concluzia la care am ajuns a fost aceea că se pot

adapta activităţile parcurse în cadrul etapelor şi subetapelor ciclului de dezvoltare a

sistemelor de inteligenţa afacerilor la cerinţele de realizare a sistemelor informatice

executive. Condiţia principală ar fi aceea că în permanenţă trebuie să se ţină cont de

cerinţele de afaceri specifice sistemelor EIS, iar evaluarea şi validarea

funcţionalităţilor sistemului trebuie să se realizeze în permanenţă prin consultări cu

managerii implicaţi. Un alt aspect ar fi acela că trebuie să se ţină cont la fiecare

activitate din cadrul ciclului de dezvoltare de anumiţi factori de influenţă, unii dintre

aceştia fiind critici pentru succesul întregului sistem. Datorită acestor condiţii, o altă

concluzie a fost aceea că ciclul de dezvlotare este orientat spre prototip, spre

construirea rapidă a sistemului cu o parte din funcţionalităţi, validarea şi evaluarea

acestuia impunând modificări sau adaptări ale prototipului şi adăugarea treptată a altor

funcţionalităţi.

Referitor la metodologia de realizare potrivită pentu modelarea sistemelor

informatice executive, după ce am prezentat principalele tipuri şi caracteristici ale

metodologiilor existente, am identificat avantajele şi dezavantajele acestora în raport

cu particularităţile sistemelor EIS şi am ajuns la concluzia că soluţia optimă ar fi

utilizarea unei metodologii orientate obiect. Pentru a surprinde cât mai bine

caracteristicile modelului multidimensional şi operaţiile acestuia am propus

extinderea setului standard de stereotipuri ale limbajului UML.

In ultima parte a lucrării am trecut la abordarea practică a tuturor conceptelor

şi soluţiilor identificate anterior. Astfel, am analizat situaţia şi fluxul decizional

existent în cadrul unei companii naţionale, pe baza acestei analize am propus şi

elaborat o soluţie de sistem informatic executiv conform ciclului de dezvoltare propus

şi modelat orientat obiect cu ajutorul stereotipurilor definite anterior. Soluţia include

tehnologiile prezentate, astfel, datele sunt organizate într-un depozit de date

centralizat, realizat parţial pentru date istorice şi un depozit de date virtual realizat

pentru date recente şi curente. Datele sunt extrase folosind tehnologia OLAP,

algoritmi de data mining şi funcţii analitice, cererile fiind optimizate. Interfaţa

265

sistemului este dinamică, permite analize complexe, navigări pe nivelurile ierarhice,

rotaţii în cadrul dimensiunilor, schimbări deperspectivă, analize cu parametrii,

vizualizări grafice şi tabelare ale aceluiaţi set dinamic de date, totaluri şi procente

flexibile, schimbate automat, marcări ale excepţiilor apărute în anumite valori,

exportul datelor în foi de calcul pentru compatibilitate cu alte sisteme. Sistemul este

accesibil direct, de oriunde prin intermediul unui portal de inteligenţă a afacerilor, la

care managerii pot avea acces şi prin dispozitive mobile, din orice locaţie conentată la

internet. In final sistemul este analizat din punctul de vedere al criteriilor de

performanţă propuse în capitolele anterioare, concluzia finală fiind că prin aplicarea

tehnologiilor de inteligenţa afacerilor şi prin respectarea activităţilor etapelor

ciclului de dezvoltare, ţinând cont şi de minimizarea influenţei factorilor critici se

poate realiza cu succes o soluţie de sistem informatic executiv destinată suportului

decizional pentru nivelul strategic al managementului organizaţiei.

Stadiul cunoaşterii

Cercetările asupra domeniului sistemelor informatice executive ca suport

pentru asistarea procesului decizional de nivel strategic datează încă de la începutul

anilor ’80 odată cu aparţia unor noi cerinţe în organizarea şi procesarea datelor

destinate nivelului superior de management. Incepând cu anii ’90 procesul a cunoscut

o evoluţie hotărâtoare prin cercetările întreprinse de personalităţi ca: R. Thierauf în

cartea Executive Information Systems: A Guide for Senior Management and Mis

Professionals sau E. Turban în Decision Support Systems and Intelligent Systems. Au

fost formulate astfel primele definiţii, precizate principalele obiective şi componente

ale sistemelor executive, au fost stabilite diferenţele majore faţă de sistemele suport

de decizie şi faţă de sistemele informatice pentru management.

Recent, odată cu evoluţia sistemelor şi tehnologiilor de inteligenţa afacerii, au

fost introduse elemente noi şi în ceea ce priveşte arhitectura şi componentele unui

sistem informatic executiv. Au fost luate în considerarea elemente din tehnologia

depozitelor de date, a bazelor de date evoluate, a tehnologiei OLAP, modalităţi de

descoperire a unor cunoştinţe noi din datele centralizate în cadrul organizaţiilor. Rolul

telecomunicaţiilor a crescut foarte mult şi au fost incluse astfel o serie de elemente

precum: portalurile de inteligenţa afacerilor şi suport pentru dispozitive mobile, astfel

încât sistemele executive să poată satisface o nouă cerinţă a managementului strategic

şi anume aceea de a fi accesibile oricând de oriunde.

266

Cercetările din domeniul bazelor de date şi al depozitelor de date din ultimul

timp au condus la creşterea posibilităţilor de integrare a datelor provenite din surse

eterogene, ducând astfel la satisfacerea unei alte cerinţe a sistemelor informatice

executive, aceea de a procesa şi extrage informaţii din cât mai multe surse, din

interiorul şi exteriorul organizaţiei. Tot cercetările asupra bazelor de date şi a

depozitelor de date au condus la creşterea performanţelor în interogarea şi extragerea

datelor prin aplicarea unor tehnici de optimizare cum ar fi: algoritmi, metode de

clusterizare, de indexare şi partiţionare.

Pentru realizarea sistemelor informatice executive au fost propuse o serie de

cadre de dezvoltare, unele orientate spre activităţi practice, altele fiind studii teoretice,

însă ambele au influenţat pozitiv procesul de analiză, proiectare şi implementare a

sistemelor informatice executive. Au fost studiaţi anumiţi factori de influenţă ce pot

duce la succesul sau eşecul implementării unui EIS.

Un alt aspect în care domeniul a cunoscut o creştere spectaculoasă în ultimii

ani a fost acela al mediilor de dezvoltare şi al instrumentelor CASE specifice

tehnologiilor de depozite de date şi OLAP care reduc costul şi timpul de realizare al

sistemelor executive şi permit asistarea procesului de dezvoltare dar şi construirea de

interfeţe specializate, prietenoase, rapid şi cu posibilităţi de analiză dinamică

avansată.

Ceea ce a cunoscut însă o mai slabă dezvoltare în contextul sistemelor

informatice executive a fost elaborarea unor cadre complete de dezvoltare care să

specifice pe fiecare etapă şi activitate acţiunile ce vor fi întreprinse, să identifice

factorii critici pe aceste activităţi, să coordoneze procesul de realizare şi să specifice

modalităţile de îmbinare a tehnologiilor existente astfel încât să se poată obţine un

sistem informatic executiv de succes care să satisfacă cerinţele de afaceri pentru care

a fost proiectat. Lucrarea de faţă propune o astfel de soluţie şi încearcă să ofere un

astfel de cadru, susţinut de o metodologie adecvată şi de un ciclu de dezvoltare în care

la fiecare etapă sunt punctate activităţile specifice sistemelor EIS şi factorii critici de

influenţă.

Contribuţii personale

Pornind de la analiza mediului decizional de nivelul strategic în capitolul II

am identificat sistemele informatice executive ca fiind principala soluţie pentru

asistarea procesului decizional, am analizat caracteristicile şi obiectivele acestor

sisteme, pe baza definiţiilor anterioare ale cercetătorilor din domeniu am propus o

267

redefinire a acestora şi am specificat, din punctul meu de vedere care ar trebui să fie

principalele obiective ale unui EIS. In finalul capitolului, prin comparaţie cu

facilităţile sistemelor suport pentru decizii şi ale sistemelor informatice pentru

management am propus un set de criterii de diferenţiere a acestora. Din analiza

realizată se desprinde ideea conform căreia decizia de a implementa şi utiliza un EIS

versus un DSS sau un MIS depinde de o situaţie particulară, de exemplu în cazul în

care în cadrul organizaţiei nu există un sistem suport de decizie atunci se va prefera

realizarea unui sistem informatic executiv dar cu facilităţi şi capacităţi extinse,

acoperind practic şi aria unui DSS. In continuare, am adaptat arhitectura sistemelor

suport de decizie la caraceristicile specifice ale sistemelor informatice executive,

realizând astfel o arhitectură complexă, pe patru niveluri. Pe baza acesteia am tratat pe

fiecare nivel tehnologiile implicate în realizarea sistemelor informatice executive.

In capitolul III, ca soluţie de organizare a datelor am propus depozitele de

date, pe baza definiţiilor formulate de diferiţi cercetători am enunţat o definiţie

proprie a unui depozit de date din prisma elementelor şi funcţionalităţilor pe care

trebuie să le ofere unui sistem informatic executiv. Pe baza caracteristicilor

depozitelor de date în general, am dedus principalele avantaje şi consecinţe pe care

acestea le au în ceea ce priveşte organizarea datelor. După prezentarea diferitelor

tipuri de depozite de date propuse de cercetători, am formulat anumite recomandări

privind posibilităţile de implementare eficientă a acestor tipuri. In ultima parte a

capitolului, am considerat necesară realizarea unei comparaţii pe baza unui set de

criterii a performanţelor obţinute în urma implementării diferitelor tipuri de depozite

de date, respectiv depozite de date versus data mart cu cele două modalităţi principale

de realizare: depozit cu date stocate şi depozit virtual. Concluzia analizei este

prezentată la finalul capitolului III.

In capitolul IV, ca principală soluţie de extragere a datelor am considerat ca

fiind tehnologia OLAP, iar în baza definiţiilor formulate în studii şi cercetări

anterioare am definit din punctul meu de vedere aceste concepte. După prezentarea

elementelor arhitecturii OLAP şi a modelelelor multidimensionale ce stau la baza

tehnologiei, ţinând cont de cerinţele de analiză ale sistemelor informatice executive

am propus un model de date multidimensional piramidal, ca extensie a modelului de

tip stea propus de R. Kimball, în care obiectele sunt structurate pe trei niveluri

interconectate: nivelul de bază (general), nivelul departamental şi nivelul strategic,

derivat.

268

In capitolul VI, în urma studierii problematicii extragerii datelor din depozite,

am identificat principalele funcţii analitice implementate în limbajul SQL care pot fi

aplicate pentru construirea rapoartelor de analiză strategică. Tot în cadrul acestui

capitol, am analizat modalităţile de optimizare a cererilor din depozitele de date cu

ajutorul unor algoritmi specifici, aplicaţi diferit în funcţie de obiectele implicate.

In capitolul VII, după analiza fazelor şi a etapelor ciclului de dezvoltare a

sistemelor de inteligenţa afecerilor în general, am ajuns la concluzia că acesta se poate

adapta şi aplica şi sistemelor informatice executive, dar în cadrul activităţilor etapelor

şi subetapelor trebuie tratate în mod obligatoriu diferenţele majore existente între

modelarea sistemelor executive şi cea a sistemelor informatice decizionale pentru a

obţine o implementare de succes a cerinţelor de afaceri specifice. Astfel, pe fiecare

etapă şi subetapă a ciclului de dezvoltare am propus activităţi specifice modelării

caracteristicilor sistemelor executive, am formulat anumite recomandări referitoare la

aceste activităţi, am propus gruparea unor subetape şi realizarea acestora în paralel

pentru micşorarea timpului de dezvoltare a sistemului. In urma prezentării unor studii

şi cadre de dezvoltare a sistemelor informatice executive, am formulat anumite

recomandări privind realizarea acestora în medii şi organizaţii diferite. In finalul

capitolului, am considerat necesară analiza factorilor ce pot influenţa succesul unui

sistem informatic executiv. Aceşti factori au fost analizaţi în baza unor criterii

propuse pe fiecare subetapă a ciclului de dezvoltare. Am identificat nivelul de risc,

modalităţile de apariţie a acestuia şi recomandările privind evitarea sa.

In capitolul VIII, pe baza prezentării unor caracteristici generale ale

metodologilor de realizare a sistemelor informatice, am analizat avantajele aduse de

acestea în dezvoltarea sistemelor EIS şi am propus ca soluţie de dezvoltare

metodologia orientată obiect. Datorită particularităţilor sistemelor informatice

executive, am propus şi definit un set de stereotipuri UML pentru modelarea acestor

caracteristici.

In capitolul IX am realizat un studiu al principalelor platforme pentru baze de

date existente în România şi care pot oferi suport pentru realizarea sistemelor

informatice executive. Analiza a urmărit satisfacerea unor criterii privind

administrarea datelor, facilităţile de analiză şi optimizare, tehnologiile de inteligenţa

afacerilor oferite în cadrul acestor platforme.

In capitolul X am aplicat conceptele şi rezultatele teoretice obţinute în

capitolele anterioare şi pornind de la analiza unei situaţii concrete a unei organizaţii

269

naţionale am propus o soluţie de realizare a unui sistem informatic executiv. Soluţia a

urmărit etapele şi activităţile ciclului de dezvoltare propus în capitolul VII, modelarea

orientată obiect a aplicat stereotipurile propuse în capitolul VIII, tehnologiile

prezentate în capitolele III – VI au fost incluse în cadrul sistemului, obţinând astfel o

soluţie complexă, valabilă şi în alte medii organizaţionale. Sistemul a fost supus

evaluării pe baza criteriilor de performanţă propuse în capitolul VII, obţinând

calificative favorabile la toate aspectele vizate. Datorită acestor considerente, consider

că realizarea acestui sistem informativ executiv s-a finalizat cu succes.

Diseminarea rezultatelor

Cercetările şi analizele realizate în această lucrare sunt rezultatul preocupărilor

şi studiilor derulate pe parcursul a 6 ani, începând cu lucrarea de licenţă din anul

2002 cu titlul “Sistem OLAP destinat analizei operaţiunilor şi a rezultatelor

financiare ale băncii Raiffeisen - Banca Agricolă România” sub conducerea

ştiinţifică a doamnei prof. univ. dr. Constanţa Bodea, continuând cu două articole

apărute în anul 2003, şi anume: “Rolul sistemelor OLAP şi a depozitelor de date în

managementul strategic” [BARA03/2] şi “Tehnici şi arhitecturi pentru micşorarea

timpului de răspuns în sistemele cu depozite de date” [BAFU03]. Studiile referitoare

la metodologiile de realizare a sistemelor decizionale au fost aprofundate în anul 2003

în lucrarea de disertaţie având tema “Modelarea multidimensională utilizând UML”

sub conducerea ştiinţifică a domnului prof. univ. dr. Ion Lungu, continuând în anul

2004 cu articolele: “Utilizarea UML în modelarea sistemelor informatice executive”

[BALU04], “Sisteme informatice de asistare a deciziei în managementul modern al

organizaţiilor economice” [BAFU04], în anul 2005 cu articolele cu unic autor: “The

potential for executive information systems to support the high-level management”

[BARA05/1] şi “Minimizarea riscului de dezvoltare a Sistemelor Informatice

Executive” [BARA05/2] şi coautor al lucrărilor: “Executive Information Systems

Development Lifecycle” [BALU05], “Tuning SQL queries for better performance in

Management Information Systems using large set of data” [BALU06], acestea din

urmă fiind publicate şi într-o bază de date internaţională (Social Science Research

Network - ssrn.com)

Studiile întreprinse au fost aplicate şi în două granturi CNCSIS: “Tehnologii

informatice pentru integrarea sistemelor instituţiilor publice” [GRANT01] şi

270

“Interferenţa tehnologiei BD cu platforma Java în arhitectura Grid Computing”

[GRANT02].

In ceea ce priveşte diseminarea rezultatelor în cadrul cursurilor şi seminariilor,

menţionez că începând cu anul universitar 2004-2005 acestea au stat la baza realizării

materialelor suport pentru cursurile şi seminariile de la disciplinele unor programe

masterale (de exemplu seminariile la disciplinele “Depozite de date”, “Sisteme de

baze de date evoluate”, “Sisteme Informatice Executive”, “Tehnologia OLAP” din

cadrul programului masteral “Baze de date – Suport pentru Afaceri”, “Business

Intelligence” şi “Realizarea SI multidimensionale – Oracle Business Intelligence

Portal” în cadrul programului masteral SIMPRE), materialele constituind suport

pentru realizarea unor lucrări de licenţă şi disertaţie în cadrul acestor programe.

Menţionez, de asemenea, că în prezent este în lucru o carte având ca tematică

sistemele informatice executive şi care va apare cel mai probabil în următoarele luni.

271

BIBLIOGRAFIE

[ANDE97] Anahory, S., Dennis, M. - Data Warehousing in the Real World,

Addison Wesley Longman, Reading, Mass, 1997

[BARA02] Bâra A. – “Sistem OLAP destinat analizei operaţiunilor şi a

rezultatelor financiare ale băncii Raiffeisen - Banca Agricolă

România”, lucrarea de licenţă, coordonator prof. univ. dr. Constanţa

Bodea, facultatea CSIE, secţia IE, ASE Bucureşti, mai 2002

[BARA03/1] Bâra A. – Modelarea multidimensională utilizând UML, Lucrare de

disertarţie, coordonator prof. univ Ion Lungu, programul de Studii

Aprofundate, facultatea CSIE, secţia IE, ASE Bucureşti, mai 2003

[BARA03/2] Bâra A. - Rolul sistemelor OLAP şi a depozitelor de date în

managementul strategic, Sesiunea tinerilor cercetători “Evoluţii

economice şi financiare în contextul integrării şi globalizării”, Centrul

de Cercetări Financiare şi Monetare “Victor Slăvescu”, Bucureşti, 2003

[BARA05/1] Bâra A. - The potential for executive information systems to support the

high-level management - Conferinţa Internaţională de Informatică

Economică "Information & Knowledge Age", ASE Bucureşti, 2005,

publicată în volumul conferinţei la editura Economică, INFOREC

Printing House, mai 2005, ISBN 973-8360-04-8

[BARA05/2] Bâra A. - Minimizarea riscului de dezvoltare a Sistemelor Informatice

Executive - Sesiunea de comunicări ştiinţifice a cadrelor didactice,

Universitatea Spiru Haret, Bucureşti, mai 2005, publicatǎ în Analele

Universitǎţii Spiru Haret, Seria Economie, Anul 5, nr. 5, Editura şi

Tipografia Fundaţiei România de Mâine, 2005, ISSN 1582-8336

[BAFU03] Bâra A., Fusaru D. - Tehnici şi arhitecturi pentru micşorarea timpului

de răspuns în sistemele cu depozite de date - Comunicare la Sesiunea de

Comunicări Ştiinţifice a cadrelor didactice “Economia României –

criterii de funcţionalitate şi competitivitate”, Universitatea “Spiru

Haret”, Bucureşti, mai 2003, publicatǎ în Analele Universitǎţii Spiru

Haret, Seria Economie, Anul 3, nr. 3, pag. 378-385 Editura şi Tipografia

Fundaţiei România de Mâine, 2003, ISSN 1582-8336.

[BAFU04] Bâra A., Fusaru D. - Sisteme informatice de asistare a deciziei în

272

managementul modern al organizaţiilor economice - Comunicare la

Sesiunea de Comunicări Ştiinţifice “Realizări şi perspective în procesul

făuririi economiei de piaţă, funcţionale, competitive şi durabile în

România”, Universitatea Spiru Haret, Bucureşti, mai 2004, publicatǎ în

Analele Universitǎţii Spiru Haret, Seria Economie, Anul 4,nr. 4, pag.

393-399 Editura şi Tipografia Fundaţiei România de Mâine, 2004, ISSN

1582-8336.

[GRANT01] Bâra A., Lungu I, Velicanu M. - GRANT CNCSIS (tip A) Tema nr.

13, Cod CNCSIS: 1118 - Tehnologii informatice pentru integrarea

sistemelor instituţiilor publice, 2005-2007, director prof univ dr. Ion

Lungu

[GRANT02] Bâra A., Lungu I, Velicanu M. - GRANT CNCSIS (tip A) nr.

27662/04.03.2005 cod CNCSIS 1112 - Interferenţa tehnologiei BD cu

platforma Java în arhitectura Grid Computing, 2005-2007, director prof

univ dr. Velicanu Manole

[BALU04] Bâra A., Lungu I., Andronie M. – Utilizarea UML în modelarea

sistemelor informatice executive – Comunicare la Sesiunea de

Comunicări Ştiinţifice “Realizări şi perspective în procesul făuririi

economiei de piaţă, funcţionale, competitive şi durabile în România”,

Universitatea Spiru Haret, Bucureşti, mai 2004, publicatǎ în Analele

Universitǎţii Spiru Haret, Seria Economie, Anul 4,nr. 4, pag. 399-403

Editura şi Tipografia Fundaţiei România de Mâine, 2004, ISSN 1582-

8336.

[BALU05] Bâra A., Lungu I. - Executive Information Systems Development

Lifecycle, Revista “Economy Informatics”, nr.1-4/2005, pag. 19-22,

ISSN 1582-7941.

[BALU06] Bâra A., Lungu I.- Tuning SQL queries for better performance in

Management Information Systems using large set of data, Supliment

revista Informatică Economică, Conferinţa internaţională ”Knowledge

management: projects, systems and technologies, Bucureşti, noiembrie

2006”

[BALV05] Bâra A. , Lungu I., Velicanu M.- Intocmirea unui studiu privind sisteme

de baze de date avansate, platforma Java, arhitectura Grid Computing,

273

Comunicare la Sesiunea ştiinţificǎ a Departamentului de Cercetǎri

Economice, Academia de Studii Economice, publicatǎ în “Economia”,

pag. 453-464, Editura ASE, 2005, ISSN 1454-0320.

[BALV06] Bâra A., Lungu I., Velicanu M.– Tehnologii informatice pentru

integrarea sistemelor instituţiilor publice. Realizarea unui studiu

privind produsele software care permit integrarea datelor. Realizarea

unui studiu privind produsele software care permit integrarea

aplicaţiilor, Comunicare la Sesiunea ştiinţificǎ a Departamentului de

Cercetǎri Economice, Academia de Studii Economice, octombire 2006,

în curs de publicare în “Economia”, Editura ASE, 2006, ISSN 1454-

0320.

[BARL86] Barley, S. R. - Technology as an occasion for structuring: evidence

from observations of CT scanners and the social order of radiology

departments. Admin. Sci. Quarterly, 31st March 1986

[BODE98] Bodea, C – Inteligenţa artificială şi sisteme expert, Editura Inforec,

Bucuresti,1998

[BOOC94] Booch G - Object Oriented Analysis and Design, Addison Wesley 1994

[BOSA98] Bocionek S, Sassin M - Applications of Negotiating and Learning

Agents, Encyclopedia of Microcomputers: Volume 22 – Supplement,

1998

[CHAU98] Chaudhuri Surajit - An Overview of Query Optimization in Relational

Systems, Proceedings of the ACM PODS, pag 34-43, iunie 1998

[CRAB99] Crabone, L., P. - Data Warehouses: Many of the common failures,

White paper, mai 1999

[DERO92] Delong D., Rockart J.F - Identifying the Attributes of Successful

Executive Support System Implementation, Chichester: John Wiley &

Sons, 1992

[DEVL97] Devlin, B. - Data Warehouse – from Architecture to Implementation,

Addison Wesley Longman, Reading, Mass, 1997

[DOBR99] Dobre I. - Suport de curs postuniversitar, Metode şi tehnici de analiză a

sistemelor social economice, Academia de Studii Economice, Facultatea

de Cibernetică, Statistică şi Informatică Economică, 1999

[EDIS06] Edison Group Inc - Comparative management Cost study of Oracle

274

Database 10g release 2 and Microsoft SQL Server 2005, 6 martie 2006

[HACH98] J. Han, S. Chee, J. Y. Chiang. - Issues for on-line analytical mining of

data warehouses. In Proc. 1998 SIGMOD Workshop on Research

Issues on Data Mining and Knowledge Discovery (DMKD'98), Seattle,

Washington, iunie 1998.

[HAKA01] Han, J., Kamber, M. - Data Minig: Concepts and Techniques, Morgan

Kaufmann Publishers, San Francisco, 2001

[HOLL00] Holland, P. - Traditional data warehouses vs virtual data warehouses ,

White Paper, March, 2000

[HUHA99] Humphries, M., Hawkins, M., Dz, M., - Data Warehousing.

Architecture and Implementation, Prentice Hall PTR,Upper Saddle

River, New Jersez, 1999

[INMO96] Inmon, W.H. - Building the Data Warehouse, John Wiley & Sons, New

York, 1996

[INMO99] Inmon, B. - Data mart does not equal data warehouse, DM Direct

Newsletter, November, 1999

[ISTO03] Istocescu A. – Strategia şi managementul strategic al organizaţiei.

Concepte fundamentale. Aplicaţii manageriale., Editura ASE, 2003

[JAJE98] Jarke, M., Jeusfeld, M.A., Quix, C., Vassiliadis, P.- Architecture and

quality in data warehouses, Proceedings CaiSE 98, Pisa, Italy, 1998

[JONA93] Jones M., Nandhakumar J. - Structured Development? A structurational

analysis of the development of an Executive Information System.

Research Papers in Management Studies, University of Cambridge,

1992-1993 No.5

[KAKI94] Kaniclides T., Kimble C. - Executive Information Systems: A framework

for their development and use, YCS 247,

1994

[KAKI95] Kaniclides, A., Kimble, C. – A Development Framework for Executive

Information Systems, Proceedings of GRONICS '95, Groningen, The

Netherlands, T LOURENS, Feb 1995

[KIMB96] Kimball, R. - The Data Warehouse Toolkit, John Wiley & Sons, New

York, 1996

[KIRE98] Kimball, R., Reeves, L., Ross, M., Thornthwaite, W. - The data

275

Warehouse Lifecycle Toolkit, John Wiley&Sons, Inc., New York, 1998.

[KUMA00] Kumar, Anil - Global Executive Information Systems: Key Issues and

Trends, Business & Economics, 2000

[LIMI01] Liang, Leo Yonghong; Miranda, Rowan – Dashboards and Scorecards:

Executive Information Systems for the Public Sector, Government

Finance Review, Dec 2001

[LMTR02] Luján-Mora S, Trujillo J - Extending UML for Multidimensional

Modeling, Proceedings of the 5th International Conference on The

Unified Modeling Language, 2002

[LUNG05] Lungu, I - Metode de dezvoltare a sistemelor informatice, Editura

Universitas, Petroşani, 2005

[LUSA04] Lungu, I, Sabău Gh, Velicanu M, Muntean M, Ionescu S, Posdarie E,

Sandu D - Sisteme informatice. Analiză, proiectare şi implementare, Ed.

Economică, 2004

[MARI03] Marinescu P - Mangementul institutiilor publice, Editura Universităţii

din Bucureşti, 2003

[MEBI89] Meiklejohn I. - The executive information systems Report. Business

Intelligence, 1989

[MEBI91] Bird Jill - Executive Information Systems Management Handbook,

Manchester: NCC; Blackwell, 1991

[MINT89] Mintzberg H. - Mintzberg on Management, Insided our strange World

of Organizations, Macmillan, 1989

[MOAT04] Moss L., Atre S. – Business Intelligence Roadmap – The complete

project lifecycle for decision-support applications, Addison-Wesley,

2004

[MUNT04] Muntean M. - Iniţiere în tehnologia OLAP: teorie şi practică, Editura

ASE, Bucureşti, 2004

[NET01] Object Management Group (OMG),

http://www.omg.org

[NET02] Rational Software Corporation,

http://www.rational.com

[NET03] Microsoft Corporation web page, www.microsoft.com

[NIVE01] Niculescu O., Verboncu I. – Fundamentele managementului

276

organizaţional, Editura Tribuna Economică, 2001

[OLAP95] The OLAP Council Definitions, ianuarie 1995

www.olapcouncil.org

[ORA10G] ORACLE Corporation – documentatie produse Business Intelligence

10g - User’s Guide, Concepts, Internet seminars.

www.oracle.com

[ORLI90] Orlikowski w. J. - The Duality of Technology. Rethinking the concept of

technology in organization, Sloan School of Management Working

paper, No. 3141, MIT 1990.

[ORRO91] Orlikowski W. J. and Robey D. - Information Technology and the

Structuring of organisations. Information Systems Research. Vol. 2,

1991, pp. 143-169.

[OWP06] Oracle Database 10g Product Family – Oracle White Paper, Oracle

Corporation, august 2006

[PODE89] Poole, M. S. and Desanctis, G. - Understanding the use of Group

Decision Support Systems: The Theory of Adaptive Structuration, in

Stein field C. And Fulk J., (eds.) Perspectives on Organisations and

New Information Technology. Sage, 1989.

[POWE00] Power D.J. - Decision Support Systems: Concepts and Resources,

Cedar

Falls, IA: DSSresources.com, http://dssresources.com/dssbook/

[RAPA72] Rapaport A. - The use mathematical isomorphism in general systems

theory, Trends in general systems theory, New York, 1972

[RUMB94] Rumbaugh J. - Object Oriented Modeling and Design, Prentice-Hall,

1994

[RYAN99] Ryan, J. - Building and deploying an enterprise data warehouse, White

Paper, 1999.

[STAN00] Stanciu V. - Proiectatea sistemelor informatice de gestiune, Ed. Cison,

Bucureşti, 2000

[STRA00] Strategor Group – Politique generale de l’enteprise , Dunod, 2000,

op.cit. în [ISTO03]

[THIE91] Thierauf Robert J. - Executive Information Systems: A Guide for Senior

Management and Mis Professionals, Hardcover / Quorum Books, 1991

277

[THOM02] Thomsen E. - OLAP Solutions: Building Multidimensional Information

Systems, John Wiley&Sons, New York, 2002, second edition

[TPPC06] Transaction Processing Performance Council (TPC) reports

http://www.tpc.org

[TRPA01] J. Trujillo, M. Palomar, J. Gómez, Il-Yeol Song - Designing Data

Warehouses with OO Conceptual Models. IEEE Computer, special issue

on Data Warehouses, 2001.

[TURB98] Turban, E. - Decision Support Systems and Intelligent Systems, 5th ed.,

Englewood Cliffs, New Jersey, Prentice Hall, 1998

[ULLM00] Jeffrey, D. Ullman - Data Mining Lecture Notes, 2000

[VATU05] Vatuiu, T - Strategii de realizare a sistemlor informatice, Teză de

doctorat, ASE, 2005

[VILA97] Vilan, A. - Data warehouses, data marts şi data mining, Revista

Computerworld România, nr. 18 (88), 21 Octombrie 1997

[WATS91]. Watson H., R. Kelly Rainer, Chang E. Koh - Executive Information

Systems: A framework for Development and a Survey of Current

Practices. MIS Quarterly, Vol. 15, No. I, March, 1991.

[WHBE98] Jeffrey L.Whitten, Lonnie D.Bentley - Systems Analysis and Design

Methods, McGraw-Hill Companies Inc, 1998

[WIKI**] http://en.wikipedia.org/wiki/

[WISD06] WisdomForce Technologies - Features, strengths and weaknesses

comparison between MS SQL 2005 (Yukon) and Oracle 10g databases,

2006

[ZADE74] Zadeh, L, A. - Noţiunile de sistem, subsistem şi stare în teoria

sistemelor, Ed Tehnică, 1974

278

ANEXE

ANEXA 1 - Construirea depozitului de date centralizat în ORACLE

WAREHOUSE BUILDER 10g (OWB)

Realizarea depozitului necesită parcurgerea următorilor paşi: definirea

surselor de date din sistemul operaţional, construirea obiectelor multidimensionale,

definirea procesului de extragere şi încărcare a datelor (ETL) şi în final stabilirea

perioadelor de actualizarea şi de încărcare a datelor în depozit.

Pas 1. Construirea depozitului de date, definirea surselor operaţionale şi a

obiectelor multidimensionale

In OWB la realizarea unui proiect nou sunt create următoarele tipuri de

module (figura 11.1.):

Figura 11.1. Modulele utilizate în aplicatie

• Colecţiile (Collections) reprezintă un mecanism generic de grupare. Ele sunt

o cale de acces mai uşoară la definiţiile obiectelor pe care o folosim pentru a

realiza activităţi la nivel de grup, de exemplu validarea sau generarea de cod.

• Bazele de date (Databases) reprezintă maparea unor date din baze de date

Oracle sau non-Oracle. Se introduc noţiunile de „modul” şi „locaţie”.

279

Modulul reprezintă un mod logic de grupare a definiţiilor de obiecte. De

exemplu, un modul de bază de date Oracle reprezintă o grupare logică de

obiecte care aparţin unei baze de date(scheme) Oracle.

Bazele de date (databases), fişierele (Files), aplicaţiile (Applications) cât şi

fluxurile de procese (Process Flows) sunt grupate din punct de vedere logic

în module.

Locaţia defineşte informaţii referitoare la schema bazei de date sau la

instrumente destinaţie. Locaţiile sunt specifice tipurilor de module: bazei de

date Oracle, bazei de date non-Oracle, SAP, sau fişiere. Atunci când se

creează o locaţie, se memorează o definiţie logică ce conţine tipul de locaţie

şi versiunea.

• Fişiere (files).. Un modul de fişiere defineşte o „legătură” către un director

ce conţine un număr de fişiere text. Putem folosi wizard-ul pentru a importa

aceste fişiere ce pot conţine tipuri multiple de înregistrări, înregistrări

separate prin caractere, etc.

• Aplicaţii (applications) conţin definiţii ale pachetelor de aplicaţii. Oracle

Warehouse Builder asigură un instrument de integrare pentru sistemele SAP.

• Flux de date (process flow) conţine definiţii ale fluxurilor de procese.

Acestea sunt conţinute de module, iar în cadrul modulului sunt conţinute de

pachete de fluxuri de date. Codul pe care Warehouse Builder-ul îl generează

pentru a reprezenta definiţiile fluxurilor de date respectă standardul XML

Process Definition Language(XPDL).

• Transformările publice (Public Transformations) reprezintă transformări

ce pot fi folosite în cadrul proiectului. Acestea sunt divizate în transformări

obişnuite şi transformări predefinite. Cele obişnuite pot fi definite sau

importate de către utilizator, în timp ce, cele predefinite sunt legate de

instalarea Warehouse Builder. Toate acestea sunt disponibile în schema

destinaţie. Transformările publice sunt divizate în următoarele categorii:

„Administration”, ca de exemplu: activarea/anularea restricţiilor, analizare

tabela/schemă,etc;

„Character”, ca de exemplu CHR, CONCAT, LDAP,LTRIM,etc;

„Conversion”=pentru realiyarea conversiilor dintre tipurile de date;

280

„Date”=asigură un număr de transformări specifice pentru datele de tip

„date”

„Numeric”, ca de exemplu ABS, SIN, FLOOR, etc;

„OLAP”=asigură accesul la procedurile de încărcare a cubului şi

dimensiunilor

„Other”, inclusiv transformări NVL;

„XML”=pentru a expune transformările de încărcare XML;

• Conexiunea la Runtime Repository (Runtime Repository Connections)

conţine specificaţiile de conectare la depozitul central de rulare (runtime

repository).

Construirea modulelor sursă şi destinaţie

Modulul sursă se defineşte pe baza tabelelor din sistemul operaţional existent,

mai exact se utilizează tabelele din sistemul ERP E-Bsiness Suite. Pentru

simplificarea procesului de extragere şi încărcare a datelor în depozit se pot construi

tabele virtuale suplimentare care să prezinte datele într-o formă asemănătoare celor

din dimensiuni şi fapte.

Modulul destinaţie va conţine dimensiunile, tabelele de fapte, cuburile şi

mapările necesare depozitului de date. In cadrul acestui modul voi defini următoarele

elemente:

• Dimensiunile - Warehouse Builder permite proiectarea dimensională, iar

dimensiunile constau în unul sau mai multe niveluri şi ierarhii şi conţin

atribute.

• Cuburile - sunt descrise de dimensiuni. În mod obişnuit un cub are legături cu

una sau mai multe dimensiuni şi conţine măsuri ale datelor care prezintă

importanţă. Într-o implementare relaţională cubul este realizat ca o tabelă

relaţională, în timp ce în mediul OLAP cubul este creat ca o structură separată.

• Mapările - reprezintă fluxuri de date necesare modelării procesului ETL

(Extract, Transform and Load). Warehouse Builder generează cod pentru

implementarea mapărilor în mediul de rulare (runtime). Se poate genera cod în

3 tipuri de limbaje în funcţie de natura sursei: PL/SQL, SQL Loader (în cazul

în care fişierele text reprezintă sursa) şi ABAP (în cazul în care sursa e

reprezentată de tabelele din cadrul pachetelor de aplicaţii SAP)

281

• Transformările - cod PL/SQL implementat ca şi funcţie, procedură sau

pachet. Warehouse Builder asigură utilizatorului posibilitatea de a defini cod

PL/SQL şi de a-l include în proiect pentru a implementa orice tip de

transformare.

• Tabelele - deseori se folosesc definiţii de tabele în proiectarea unui sistem de

inteligenţă a afacerilor.

• Viziunile - se pot folosi viziuni pentru a simplifica eventualele interogări de

regăsire.

• Viziuni materializate - pot fi foarte importante pentru a uşura cererile de

regăsire prin stocarea datelor extrase din tabelele iniţiale.

• Tabele externe - Warehouse Builder permite proiectarea tabelelor externe în

cadrul sistemului destinaţie(target). Pentru a nu folosi un fişier text direct ca şi

sursă într-o mapare şi de a rula programul de încărcare SQL, se poate defini o

tabelă externă. Avantajele folosiriii definiţiei unei tabele externe comparativ

cu folosirea definiţiei unui fişier text sunt: rularea select-urilor în paralel şi

flexibilitate în cadrul transformărilor PL/SQL, datorată posibilităţii realizării

unui join eterogen între tabelele externe şi tabelele relaţionale

• Liste avansate (advanced queues) - pot fi folosite atât ca sursă cât şi ca

destinaţie într-o mapare.

• Secvenţe - definiţiile de secvenţe pot fi folosite ca definiţie a unui obiect

sursă într-o mapare pentru a genera o valoare numerică în secvenţă.

Se definesc dimensiunile sistemului şi ierarhiile acestora conform modelului

de analiză prezentat anterior (figura 11.2.):

282

Figura 11.2. Definirea dimensiunilor şi ierarhiilor acestora

Definirea cuburilor se realizează precizând numele, dimensiunile şi măsurile

componente, iar Warehouse Builder realizează automat schema cubului respectiv

(figura 11.3.):

Figura 11.3: Definirea cuburilor

283

Pas.2. Realizarea procesului ETL (Extract, Transform, Load)

Folosind terminologia Warehouse Builder, un proces ETL sau de fapt un flux

de date este numit mapare. Definiţiile transformărilor sau mapărilor se stabilesc în

contextul unui modul destinaţie. Mapările sunt dezvoltate într-o bază de date Oracle,

iar Warehouse Builder generează cod ce foloseşte următoarele elemente:

• Un set de comenzi bazate pe INSERT/UPDATE/MERGE (cunoscut sub

numele de UPSERT);

• Adăugarea în mai multe tabele: adăugarea în tabele multiple se face

folosind o singură comandă şi nu mai multe comenzi separate;

• Cel mai rapid mod de a încărca date într-o tabelă destinaţie (ţintă)

• Funcţiile tabelelor pentru a manevra execuţia paralelă a codului PL/SQL.

Majoritatea codului generat pentru mapările din Warehouse Builder va fi cod

PL/SQL. Dacă definim fluxuri de date care mută datele din definiţiile obiectelor

relaţionale în definiţii ale obiectelor relaţionale, atunci codul va fi întotdeauna cod

PL/SQL. Dacă mapăm direct dintr-un fişier text (flat file) atunci Warehouse Builder

va genera un fişier SQL de control a încărcării. În cazul în care citim date din cadrul

pachetelor SAP ce conţin definiţii de tabele, în special tabele cluster sau pool, atunci

Warehouse Builder va genera cod ABAP, care e necesar pentru a regăsi datele.

In realizarea mapărilor se utilizează o serie de operatori şi se pot construi

expresii pentru specificarea modului de transformare a datelor sursă în destinaţiile

corespunzătoare. Câţiva dintre operatori specifici sunt:

• listă avansată (advanced queue) - poate fi folosită atât ca sursă cât şi

ca destinaţie

• operatorul de divizare (splitter) - asigură împărţirea datelor pentru

mai multe obiecte(deseori rezultă într-un insert pe mai multe tabele)

• operatorul set, pentru a genera operatorii de UNIUNE (ALL),

INTERSECŢIE, DIFERENŢĂ

• operatorul pivot - pentru a muta o structură de date cu mai multe

coloane, într-o implementare cu mai multe linii.

• operatorul unpivot - mută date din linii în coloane

• transformare - oferă posibilitatea de a adăuga orice transformare

PL/SQL

284

• funcţii tablelă - orice funcţie tabelă structurată poate fi inclusă într-o

mapare

Maparea dimensiunilor se va realiza prin punerea în corespondenţă a

atributelor dimensiunii cu atributele tabelelor relaţionale din modulul sursă (figura

11.4.).

Figura 11.4. Maparea dimensiunilor

Maparea cuburilor se realizează pe baza dimensiunilor definite, dar se pot

utiliza şi tabele relaţionale sau tabele virtuale care conţin datele referitoare la măsuri

(figura 11.4.).

Figura 11.4: Maparea cuburilor

285

Validarea obiectelor. Validarea funcţionează ca un instrument de raportare a

erorilor pentru scripturile de încărcare a obiectelor depozitelor de date.

Înainte de generarea obiectelor trebuie să ne asigurăm că sunt definite locaţii

pentru toate modulele care vor fi generateşi conectorii dintre locaţii şi este instalat

Runtime Repository şi acesta este referit printr-o conexiune.

Rezultatele validării modulului DESTINATIE sunt prezentate în figura

următoare:

Figura 11.5: Validarea obiectelor depozitului de date

Pas.3. Generarea obiectelor multidimensionale în Oracle Warehouse

Builder 10g

Având proiectate obiectele se poate folosi utilitarul din Warehouse Builder -

Deployment Manager pentru a genera dimensiunile, tabelele de fapte, cuburile.

Utilitarul asigură atât generarea, crearea obiectelor cât şi execuţia pentru obiectele

executabile, ca de exemplu mapările sau fluxurile de date.

În timpul generării, Warehouse Builder validează şi generează script-urile

necesare pentru crearea şi popularea instanţelor depozitului de date. Acest proces

începe prin validarea definiţiilor şi generarea script-urilor utilizate pentru crearea

obiectelor depozitului de date şi script-urilor de mapare utilizate pentru încărcarea

depozitului de date. Când sunt generate script-urile, sunt create obiectele depozitului

286

de date şi scripturile de mapare sunt depozitate în instanţele depozitului. Se generează

o instanţă fizică a depozitului de date pornind de la un depozit de date definit logic.

Cu ajutorul instrumentului OWB Deployment Manager putem observa

obiectele depozitului de date care au fost generate (figura 11.6.).

Figura 11.6: Rezultatul procesului de validare şi generare a obiectelor depozitului

de date

Warehouse Builder generează următoarele tipuri de script-uri:

• Script-uri DDL – pentru crearea şi ştergerea obiectelor;

• Fişiere de control SQL*Loader – pentru extragerea şi transportul datelor

pornind de la fişierul sursă;

• Script-uri TCL pentru programarea şi conducerea job-urilor – Enterprise

Manager.

Warehouse Builder poate genera multiple script-uri pentru a implemneta

fiecare mapare, iar pentru fiecare dimensiune Warehouse Builder generează script-uri

DDL ca de exemplu în figura următoare:

287

Figura 11.7: Scripurile utilizate pentru crearea unui cub

Pas.4. Exportul metadatelor din Warehouse Builder

Warehouse Builder Transfer Wizard permite exportul metadatelor către

următoarele tipuri de destinaţie: un fişier în conformitate cu standardul OMG CWM,

Oracle Discoverer, Oracle Express, OLAP Server.

Pentru a exporta metadatele trebuie mai întâi definite colecţiile. Colecţiile sunt

zone în Warehouse Builder care depozitează metadatele care se vor a fi exportate în

alte instrumente sau sisteme. Când se crează o colecţie nu se crează obiecte noi sau

copii ale celor existente, ci se crează shortcut-uri care punctează obiectele deja

existente în proiect.

Datorită faptului că este necesară construirea unei părţi a depozitului în

variantă virtuală pentru extragerea onlinea datelor exportul metadatelor va fi realizat

în Oracle Discoverer care permite şi realizarea paralelă a zonei virtulae.

288

ANEXA 2: Realizarea depozitului virtual în ORACLE BI

DISCOVERER ADMINISTRATOR 10g

Instrumentele oferite de Oracle Business Intelligence Discoverer 10g cuprind

elemente de analiză multidimensională a datelor care implementează operaţiile

specifice (navigare în cadrul ierarhiilor rotaţii, secţiuni) şi funcţii de analiză (de

previziune, de construire a scenariilor “ce se întâmplă dacă?”), elemente de

vizualizare a datelor prin construirea de rapoarte şi grafice flexibile şi uşor de

modificat de către utilizatorul final.

Oracle BI Discoverer 10g este alcătuit din două componente majore (figura

11.8):

• Un mediu pentru definirea structurilor de date şi a metadatelor utilizate în

analiză – Oracle BI Discoverer Administrator;

• Mai multe medii petru construirea şi prezentarea raportelor şi analizelor –

OracleAS Discoverer Plus, OracleAS Discoverer Viewer, Oracle BI

Discoverer Desktop [ORA10g].

Arhitectura Oracle Discoverer este compusă din trei nivele distincte: nivelul

datelor, nivelul End User Layer (EUL V5 pentru versiunea Oracle Discoverer 9.0.4)

care conţine metadatele şi structurile specifice utilizate în analiză şi nivelul interfeţei

cu utilizatorul (figura 11.8):

289

Figura 11.8: Arhitectura Oracle BI Discoverer

Accesul la date se realizează prin intermediul nivelului EUL şi este un acces

direct, fără contruirea unui depozit de date în care datele să fie stocate. Din acest

motiv se poate spune că este realizat un depozit de date virtual. Structurile

multidimenionale de tipul dimensiunilor şi a tabelelor de fapte sunt transformate

automat din sursele relaţionale în obiecte de tipul Folder şi grupate şi încărcate în

obiectele de tipul Business Area ale nivelului EUL. Din acest motiv pe baza de date

relaţională treburie construite mai întâi o serie de view-uri care să faciliteze

transformarea datelor pe obiectele din Oracle Discoverer.

Pentru realizarea unui depozit virtual în Oracle Discoverer se parcurg mai

mulţi paşi după cum voi detalia în cele ce urmează.

Definirea obiectelor în Oracle Discoverer Administrator

P1: Definirea Business Area şi a folderelor pentru maparea tabelelor

relaţionale. Oracle Discoverer nu face diferenţa între foldere de tipul dimensiunilor

sau de tipul tabelelor de fapte. Se construiesc două business area: Financiar – pentru

analiza indicatorilor financiari şi Comercial – pentru analiza activităţilor

departametului comercial (figura 11.9):

ORACLE

DATABASE

EUL V5

DISCOVERER ADMINISTRATOR

(WINDOWS)

DEFINIRE

DISCOVERER DESKTOP

(WINDOWS)

DISCOVERER PLUS

(WEB)

DISCOVERER VIEWER

(WEB)

EXTRAGERE

ADMINISTRARE

VIZUALIZARE

290

Figura 11.9: Definirea Business Area şi a folderelor pentru obiecte

P2: Ajustarea proprietăţilor folderelor prin setarea modalităţilor de

vizualizare, de stocare, aparteneţa la o clasă de tip item class (figura 11.10). In funcţie

de cerinţe se pot construi noi foldere pe baza tabelelor sau foldere calculate.

291

Figura 11.10: Stabilirea proprietăţilor folderelor

P3: Realizarea legăturilor între folderele aplicaţiei. Se stabilesc legăturile între

folderele de tipul tabelelor de fapte şi folderele de tipul dimensinilor pe baza cheilor

primare şi a cheilor externe (figura 11.11):

Figura 11.11: Realizarea legăturilor între foldere

P4: Construirea ierarhiilor în cadrul folderelor care conţin dimensiunile. Există

două tipuri de ierarhii:

• date hierarchy pentru ierarhiile care au la bază timpul. Discoverer permite

utilizarea unor ierarhii predefinite (ex: day->month->quarter->year) sau

adaptarea acestora pentru necesităţile aplicaţiei.

292

Figura 11.12: Şalon pentru ierarhiile de tip date

• item hierarchy pentru ierarhiile construite de utilizator pe baza legăturilor de

tip părinte-copil existente între valorile din tabelele relaţioale. Ex: punct de

lucru->sucursala->oraş->regiune->ţară (figura 11.13):

Figura 11.13: Ierarhii de tip item: H_unitati, H_conturi, H_produse, H_clienti,

H_furnizori

293

ANEXA 3: Realizarea interfeţei, a rapoartelor şi prezentărilor cu

ORACLE BI DISCOVERER DESKTOP 10g

Mediul Oracle BI Discoverer Desktop permite construirea de rapoarte

complexe şi flexibile pe baza Business Area şi a folderelor definite anterior în Oracle

Discoverer Administrator. Analiza datelor se realizează prin aplicarea următoarelor

tipuri de operaţii asupra datelor:

• Navigarea pe nivelele ierarhice (Drill Down şi Roll Up) – reprezintă operaţii

de navigare în cadrul ierarhiilor dimensiunilor, prin agregare pe nivelele

superioare (roll-up sau drill-up) sau detaliere pe nivelele inferioare (drill-

down). Cu toate ca operaţiile se pot realiza dinamic, pentru a economisi timp

şi resurse se preferă uneori pre-calcularea unor valori globale prin însumare

sau agregare. Aceste agregări se referă la o anumită măsură şi se realizează

după dimensiunile corespunzatoare acesteia. Aceste operaţii implică de cele

mai multe ori doar calcularea unor totaluri, dar există şi excepţii în care se

utilizează formule sau procedee statistice. Prin facilitatea de drill down,

utilizatorii pot naviga pe nivele cu un grad de detaliu mai accentuat. Prin roll

up sau drill up se pot vizualiza datele la un nivel agregat.

• Rotaţii – Acestea reprezintă operaţiile cele mai uzuale realizate aupra datelor

în rapoartele de analiză. Ele oferă utilizatorului posibilitatea de a alege

perspectiva asupra datelor pe care o va utiliza. Fiecare rotaţie pune în evidenţă

o nouă perspectivă, aducând în prim plan o structură bidimensională, o faţetă

(slice). Din acest motiv rotaţia se mai numeste şi “data slicing”. Aceste

operaţii nu implică o reorganizare a datelor stocate, ci o schimbare a

modalităţii de reprezentare.

• Secţiuni – Oferă viziuni sau imagini (views) prin operaţii de secţionare prin

care se obţin “felii” (slices). Tehnica aceasta constă în limitarea unor atribute

la anumite valori şi obţinerea unui cub de date redus (procedeu numit data

dicing).

P1: Alegerea tipului de raport. Se pot utiliza patru tipuri de rapoarte în funcţie

de necesităţile de vizualizare a datelor (figura 11.14):

• Table – datele sunt vizualizate la nivel detaliat, tabular şi nu există

posibilitatea de modificare a perpectivelor prin interchimbarea dimensiuilor;

294

• Page-detail table – datele sunt vizualizate la nivel detaliat, tabular dar există

posibilitatea de modificare a perpectivelor prin interchimbarea dimensiunilor.

Acestea sunt prezente în partea de sus a raportului (page items);

• Crosstab – datele sunt agregate în funcţie de nivelul ierarhic al dimeniunilor,

existând posibilitatea navigării în cadrul ierarhiilor prin operaţii de tip drill-up

şi drill-down. Insă posibilităţile de interchimbare a dimensiuilor sunt limitate

datorită lipsei obiectelor de tip page items.

• Page-detail crosstab – este cel mai complex tip de raport, datele sunt agregate

în funcţie de nivelul ierarhic al dimeniunilor, cu posibilitatea navigării în

cadrul ierarhiilor prin operaţii de tip drill-up şi drill-down şi de interchimbare

a dimensiuilor prin prezenţa obiectelor de tip page items.

Figura 11.14: Alegerea tipului de raport

P2: Alegerea Business Area şi obiectelor de tip item care vor intra în

componenţa raportului. Pe baza legăturilor stabilite în Discoverer Administrator se

aleg câmpurile şi nivelul de agregare la care se vor prezenta datele (figura 11.15):

Figura 11.15: Nivelul de detaliere a datelor

295

Se aleg şi nivelele de ierarhice în funcţie de care se vor agrega datele prin selectarea

câmpului corespunzător (ex: punct de lucru) (figura 11.16):

Figura 11.16: Alegerea Business Area şi obiectelor de tip item care vor intra în

componenţa raportului

P3: Plasarea obiectelor de tip item în raport. Această etapă este dependentă de

tipul de raport ales la pasul 1. Voi exemplifica pe un tip de raport crosstab-detail

(figura 11.17). Se stabilesc obiectele de tip page items şi data points.

Figura 11.17: Plasarea obiectelor în raport

296

P4: Vizualizarea datelor din raport. Se finalizează raportul şi se pot prezenta

datele (figura 11.18).

Figura 11.18: Vizualizarea datelor

Perspective diferite asupra datelor (rotaţii – data slicing) se pot obţine interschimbând

dimensiunile, adăugând sau eliminând o parte dintre acestea (figura 11.19 a):

Figura 11.19 a: Rotaţii în cadrul dimensiunilor

Navigarea în cadrul nivelelor dimensiunilor se obţin prin aplicarea operaţiilor de drill-

down şi roll-up sau drill-up (figura 11.19 b):

297

Figura 11.19 b: Navigarea în cadrul dimensiunilor

Limitarea asupra unui set de date (data dicing) se poate realiza fie prin selectarea unor

valori pentru nivelele dimesiunilor (figura 11.19 c) fie prin aplicarea condiţiilor sau a

parametrilor asupra datelor. Acestea se vor prezenta în paşii următori.

Figura 11.19 c: Limitarea setului de date la anumite valori

P5: Construirea de noi variabile calculate pe baza datelor existente.

Discoverer dispune de o serie variată de funcţii cu ajutorul cărora se pot obţine noi

variabile. Funcţiile sunt grupate în categorii: analitice, de conversie, numerice, de tip

dată calenaristică, pentru şiruri de caractere, de agregare, statistice, etc. (figura

11.20):

298

Figura 11.20: Construirea de variabile pe baza datelor existente

P6: Construirea parametrilor. Se pot defini rapoarte parametrizate pentru

prezentarea unui anumit set de date dorit de utilizator (figura 11.21):

Figura 11.21: Introducerea parametrilor în raport

La momentul rulării raportului utilizatorul va fi atenţionat şi rugat să introducă

valorile pentru parametrii existenţi (figura 11.22):

299

Figura 11.22: Introducerea valorilor pentru rapoarte

P7: Filtrarea rezultatelor prin introducerea de condiţii. Datele prezentate se pot

limita la anumite valori pe care utilizatorul doreşte să le analizeze (figura 11.23):

Figura 11.23: Introducerea de condiţii asupra datelor

P8: Realizarea totalurilor. Datele şi variabilele calculate se pot grupa şi

însuma pe diferite nivele, în funcţie de criteriile de grupare (figura 11.24):

300

Figura 11.24: Realizarea totalurilor

P9: Vizualizarea procentajelor prin stabilirea nivelelor la care se calculează

acestea (figura 11.25):

Figura 11.25: Introducerea de procente pentru variabile

Totalurile şi procentele pot fi combinate astfel încât să se obţină o situaţie ca în figura

11.26:

301

Figura 11.26: Vizualizarea procentelor şi a totalurilor

P10: Vizualizarea unor excepţii ale datelor. Rapoartele pot evdenţia diferit

anumite valori ale datelor prin introducerea unor excepţii prin aplicarea unui format

special acelor valori (figura 11.27 a):

Figura 11.27 a: Vizualizarea excepţiilor

Vizualizarea diferită a datelor în funcţie de valorile existente se poate realiza şi prin

marcarea grafică a acestora obţinându-se o ierarhizare a lor (figura 11.27 b):

302

Figura 11.27 b: Marcarea grafică a valorilor

P11: Prezentarea grafică a datelor. Discoverer oferă poibilitatea realizării de

grafice de diferite tipuri în funcţie de cerinţele utilizatorilor. Tipul de grafic şi

elementele acestuia se poate schimba la cerere prin selectarea acestora din bara de

instrumente (figura 11.28):

Figura 11.28: Realizarea graficelor

P12: Partajarea rapoartelor între utilizatori. Se pot acorda drepturi de acces la

rapoartele realizate în Discoverer Desktop, dar pentru a vizualiza aceste rapoarte

utilizatorii respectivi trebuie să aibă drepturi de acces la Business Area. Aceste

drepturi se acordă din Oracle Discoverer Administrator şi Discoverer Desktop se

acordă drepturile asupra fiecărui raport partajat (figura 11.29):

303

Figura 11.29: Acordarea drepturilor de vizualizare asupra raportelor partajate

P13: Planificarea execuţiei unui raport. Rularea rapoartelor la o anumită dată

şi la anumite intervale de timp se poate realiza în Dicoverer Desktop pentru a

economisi timp în cazul rapoartelor care rulează foarte încet şi pentru a pregăti setul

de rezultate pentru analize la termen (figura 11.30):

Figura 11.30: Planificarea execuţiei rapoartelor

Rapoartele construite în Oracle Discoverer sunt flexibile, uşor de modificat de

către utilizatorii finali şi dispun de instrumente puternice de analiză pentru realizarea

304

operaţiilor de navigare în cadrul dimensiunilor, rotaţii, secţiuni şi construirea de

variabile noi cu ajutorul unor funcţii de analiză. Rapoartele pot fi integrate în cadrul

aplicaţiilor Oracle existente în companie prin intermediul Oracle Portal sau prin

Oracle E-Business Suite.