teza_doctorat.pdf management stategic
TRANSCRIPT
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.