sisteme interactive de asistare a deciziei

2

Corectura aparține autoarei

© Editura REVERS Craiova Toate drepturile asupra acestei ediţii sunt rezervate autoarei. Orice reproducere integrală sau parţială, prin orice procedeu, a unor pagini din această lucrare, efectuate fără autorizaţia editorului este ilicită şi constituie o contrafacere. Sunt acceptate reproduceri strict rezervate utilizării sau citării justificate de interes ştiinţific, cu specificarea respectivei citări.

© Editura REVERS Craiova All rights reserved. This book is protected by copyright. No part of this book may be reproduced in any form or by any means, including photocopying or utilised any information storage and retrieval system without written permision from the copyright

owner.

Descrierea CIP a Bibliotecii Naţionale a României LAURA GAVRILĂ (ȘTEFĂNESCU) Sisteme interactive de asistare a deciziei / LAURA GAVRILĂ (ȘTEFĂNESCU). - Craiova : Revers, 2015

Bibliogr.

ISBN 978-606-703-474-5

Editura Revers ISBN: 978-606-703-474-5

2

Corectura aparține autoarei

© Editura REVERS Craiova Toate drepturile asupra acestei ediţii sunt rezervate autoarei. Orice reproducere integrală sau parţială, prin orice procedeu, a unor pagini din această lucrare, efectuate fără autorizaţia editorului este ilicită şi constituie o contrafacere. Sunt acceptate reproduceri strict rezervate utilizării sau citării justificate de interes ştiinţific, cu specificarea respectivei citări.

© Editura REVERS Craiova All rights reserved. This book is protected by copyright. No part of this book may be reproduced in any form or by any means, including photocopying or utilised any information storage and retrieval system without written permision from the copyright

owner.

Descrierea CIP a Bibliotecii Naţionale a României LAURA GAVRILĂ (ȘTEFĂNESCU) Sisteme interactive de asistare a deciziei / LAURA GAVRILĂ (ȘTEFĂNESCU). - Craiova : Revers, 2015

Bibliogr.

ISBN 978-606-703-474-5

Editura Revers ISBN: 978-606-703-474-5

Sisteme informatice de asistare a deciziilor final trimis 08,06,2015.pdf, Flat 2 of 154 - Pages: 2, 2, 06/08/15 07:37 PM

3

CUPRINS

CAPITOLUL I

ASISTAREA DECIZIILOR ............................................................. 5

1.1. Decizii. Decidenţi. Procese decizionale ............................ 5

1.2. Modelarea proceselor decizionale. Principalele modele de fundamentare a deciziilor ................................................ 123

CAPITOLUL II

TEHNOLOGII INFORMAŢIONALE DESTINATE ASISTĂRII DECIZIILOR .............................................................. 33

2.1. Tehnologia Datawarehouse – centralizare, consolidare, reorganizare şi stocare volume mari de date .................... 33

2.1.1. Exploatarea datelor din depozitele de date ................. 36

2.1.2. Modelarea conceptuală a depozitelor de date ............ 42

2.2. Tehnologia On-Line Analytical Processing – agregarea

datelor stocate în depozite abordate multidimensional .......... 48

2.3. Tehnologia Datamining – mineritul datelor stocate......... 51

2.3.1. Extragerea informațiilor din depozitele de date. Instrumente de extragere şi transformare a datelor .... 53

2.3.2. Metode și tehnici de datamining.Clustering tehnică de grupare a datelor multi-dimensionale ..........................56

CAPITOLUL III

ASISTAREA DECIZIEI ÎN MANAGEMENTUL DE PORTOFOLIU.

STUDIU DE CAZ.......................................................................... 61

3.1. Definirea obiectivelor sistemului pentru asistarea managementului de portofoliu ........................................... 62

3.2. Specificarea ieşirilor şi identificarea intrărilor sistemului

suport ............................................................................. 66

3.3. Managementul datelor .................................................... 76

3.3.1. Baza de date pentru managementul datelor. Modelul obiectelor. ................................................................... 77

3

CUPRINS

CAPITOLUL I

ASISTAREA DECIZIILOR ............................................................. 5

1.1. Decizii. Decidenţi. Procese decizionale ............................ 5

1.2. Modelarea proceselor decizionale. Principalele modele de fundamentare a deciziilor ................................................ 123

CAPITOLUL II

TEHNOLOGII INFORMAŢIONALE DESTINATE ASISTĂRII DECIZIILOR .............................................................. 33

2.1. Tehnologia Datawarehouse – centralizare, consolidare, reorganizare şi stocare volume mari de date .................... 33

2.1.1. Exploatarea datelor din depozitele de date ................. 36

2.1.2. Modelarea conceptuală a depozitelor de date ............ 42

2.2. Tehnologia On-Line Analytical Processing – agregarea

datelor stocate în depozite abordate multidimensional .......... 48

2.3. Tehnologia Datamining – mineritul datelor stocate......... 51

2.3.1. Extragerea informațiilor din depozitele de date. Instrumente de extragere şi transformare a datelor .... 53

2.3.2. Metode și tehnici de datamining.Clustering tehnică de grupare a datelor multi-dimensionale ..........................56

CAPITOLUL III


STUDIU DE CAZ.......................................................................... 61

3.1. Definirea obiectivelor sistemului pentru asistarea managementului de portofoliu ........................................... 62

3.2. Specificarea ieşirilor şi identificarea intrărilor sistemului

suport ............................................................................. 66

3.3. Managementul datelor .................................................... 76

3.3.1. Baza de date pentru managementul datelor. Modelul obiectelor. ................................................................... 77


4

3.3.2. Facilități de interogare a datelor ......... ...................... 103

3.4. Managementul modelelor. Structura bazei de modele . 105

3.4.1. Modele de calcul a indicatorilor sintetici şi analitici .... 108

3.4.2. Modele de prognoză a trendului cotaţiilor ................. 115

3.4.3. Modele de analiză a deciziei ..................................... 122

3.5. Managementul interfeţelor şi dialogurilor ...................... 128

3.5.1. Interfața și dialogul .................................................... 129

3.5.2. Formate de ecran folosite ca interfață pentru sistemul suport ........................................................................ 130

3.5.3. Controale grafice Visual C++ folosite de sistem ca

interfaţă şi pentru dialogul cu utilizatorii .................... 131

3.6. Funcţionalităţile sistemului pentru managementul de portofoliu. Prezentarea generală a sesiunii de lucru ....... 134

3.7. Studiu de caz - prelucrarea și analiza datelor pentru managementul de portofoliu ........................................... 134

BIBLIOGRAFIE .............................................................................. 151

4

3.3.2. Facilități de interogare a datelor ......... ...................... 103

3.4. Managementul modelelor. Structura bazei de modele . 105

3.4.1. Modele de calcul a indicatorilor sintetici şi analitici .... 108

3.4.2. Modele de prognoză a trendului cotaţiilor ................. 115

3.4.3. Modele de analiză a deciziei ..................................... 122

3.5. Managementul interfeţelor şi dialogurilor ...................... 128

3.5.1. Interfața și dialogul .................................................... 129

3.5.2. Formate de ecran folosite ca interfață pentru sistemul suport ........................................................................ 130

3.5.3. Controale grafice Visual C++ folosite de sistem ca

interfaţă şi pentru dialogul cu utilizatorii .................... 131

3.6. Funcţionalităţile sistemului pentru managementul de portofoliu. Prezentarea generală a sesiunii de lucru ....... 134

3.7. Studiu de caz - prelucrarea și analiza datelor pentru managementul de portofoliu ........................................... 134

BIBLIOGRAFIE .............................................................................. 151


5

CAPITOLUL I

ASISTAREA DECIZIILOR

În arhitectura, funcţionalitatea şi performanţele managementului,

componenta sa decizională deţine o poziţie privilegiată. Nici un alt element nu

are o specificitate managerială atât de pronunţată şi un impact atât de mare în

toate planurile activităţilor şi rezultatelor sale. Managerii iau decizii care privesc

grupuri de persoane sau chiar organizaţia în ansamblul său şi antrenează

resurse însemnate. Efectul acestor decizii poate fi resimţit în prezent sau pe

termen mai lung şi uneori se răsfrânge chiar şi asupra carierei celui care le

adoptă. În management, decizia are un rol extrem de important: permite

desfăşurarea eficientă a activităţii organizaţiei în concordanţă cu mediul în care

aceasta funcţionează, stabilirea şi realizarea obiectivelor prevăzute.

Acestea sunt principalele raţiuni care ne determină să începem prezenta

carte cu: tratarea conceptului de decizie, analiza procesului decizional, studiul

acelor abordări decizionale care permit elaborarea modelelor de decizie

frecvent utilizate în activitatea managerială.

1.1. Decizii. Decidenţi. Procese decizionale

În literatura de specialitate s-au publicat numeroase studii asupra deciziei

şi procesului decizional (Coates 1999; Constantinescu, Ungureanu 1998;

Maness, Zietlow 2001)abordate dintr-o varietate de puncte de vedere, unele

chiar contradictorii. Situaţia este pe deplin firească, reflectând diversitatea

condiţiilor în care activităţile se desfăşoară, diferenţele în pregătirea şi

experienţa managerilor, specificitatea obiectivelor urmărite.

Trăsăturile enunţate argumentează definiţia pe care o vom adopta în

această carte: Decizia reprezintă rezultatul unor activităţi conştiente, de

alegere a unei direcţii de acţiune, … fiind rezultatul unor prelucrări de informaţii

şi cunoştinţe1, formulare care îşi are rădăcinile în propunerile de definiţie ale

mai multor specialişti2, cum ar fi:

Alegerea unei direcţii de acţiune (Simon, 1960);

Alegerea unei strategii de acţiune (Fishburn, 1964);

1 Filip, F.Ghe. – Decizie asistată de calculator, Editura Tehnică, Bucureşti, 2002, p. 25 2 citaţi de Filip, F.Ghe. în „Decizie asistată de calculator”, Editura Tehnică, Bucureşti, 2002, pag. 25

5

CAPITOLUL I

ASISTAREA DECIZIILOR

În arhitectura, funcţionalitatea şi performanţele managementului,

componenta sa decizională deţine o poziţie privilegiată. Nici un alt element nu

are o specificitate managerială atât de pronunţată şi un impact atât de mare în

toate planurile activităţilor şi rezultatelor sale. Managerii iau decizii care privesc

grupuri de persoane sau chiar organizaţia în ansamblul său şi antrenează

resurse însemnate. Efectul acestor decizii poate fi resimţit în prezent sau pe

termen mai lung şi uneori se răsfrânge chiar şi asupra carierei celui care le

adoptă. În management, decizia are un rol extrem de important: permite

desfăşurarea eficientă a activităţii organizaţiei în concordanţă cu mediul în care

aceasta funcţionează, stabilirea şi realizarea obiectivelor prevăzute.

Acestea sunt principalele raţiuni care ne determină să începem prezenta

carte cu: tratarea conceptului de decizie, analiza procesului decizional, studiul

acelor abordări decizionale care permit elaborarea modelelor de decizie

frecvent utilizate în activitatea managerială.

1.1. Decizii. Decidenţi. Procese decizionale

În literatura de specialitate s-au publicat numeroase studii asupra deciziei

şi procesului decizional (Coates 1999; Constantinescu, Ungureanu 1998;

Maness, Zietlow 2001)abordate dintr-o varietate de puncte de vedere, unele

chiar contradictorii. Situaţia este pe deplin firească, reflectând diversitatea

condiţiilor în care activităţile se desfăşoară, diferenţele în pregătirea şi

experienţa managerilor, specificitatea obiectivelor urmărite.

Trăsăturile enunţate argumentează definiţia pe care o vom adopta în

această carte: Decizia reprezintă rezultatul unor activităţi conştiente, de

alegere a unei direcţii de acţiune, … fiind rezultatul unor prelucrări de informaţii

şi cunoştinţe1, formulare care îşi are rădăcinile în propunerile de definiţie ale

mai multor specialişti2, cum ar fi:

Alegerea unei direcţii de acţiune (Simon, 1960);

Alegerea unei strategii de acţiune (Fishburn, 1964);

1 Filip, F.Ghe. – Decizie asistată de calculator, Editura Tehnică, Bucureşti, 2002, p. 25 2 citaţi de Filip, F.Ghe. în „Decizie asistată de calculator”, Editura Tehnică, Bucureşti, 2002, pag. 25


6

O alegere conducând la un anume obiectiv dorit (Churchman, 1968);

O formă specifică de angajare într-o acţiune - de obicei, este vorba de

angajarea unor resurse (Mintzberg, Raisinghani, Theoret, 1976;

Mintzberg, 1980);

Elaborarea ad-hoc a mai multe strategii alternative, analiza strategiilor

elaborate şi a celor deja formulate şi alegerea unora dintre ele (Popescu,

Găvănescu, Rădulescu, 1983);

Rezultatul unui tip particular de prelucrare a informaţiilor, care constă în

alegerea unui plan de acţiune (Holsapple, Whinston, 1993);

Alegerea uneia dintr-un număr de alternative; cunoştinţe – în sens de

elemente de cunoaştere, care indică o angajare într-o anumită direcţie de

acţiune (Holsapple, Whinston, 1996);

O alocare a resurselor (Spradlin, 1997);

Alegerea uneia dintre mai multe alternative; o afirmaţie care arată

angajarea într-o direcţie de acţiune (Power, 2000);

Indiferent cum este definită decizia, ea este o necesitate obiectivă care

transpusă la nivel managerial este rezultatul procesului de gândire al

managerului care a trasat-o. Ceea ce determină managerul să opteze pentru o

alternativă şi nu pentru alta este informaţia. Atunci când aceasta există,

alegerea este mai simplă, uneori chiar evidentă, alteori alegerea urmează

numai după o atentă prelucrare a noilor date. Ceea ce trebuie să conteze în

luarea unei decizii corecte sunt consecinţele pe care aceasta le va avea

asupra organizaţiei. De aceea, decizia este sarcina comună tuturor funcţiilor

manageriale şi se dezvoltă în sistem piramidal pe nivele de management şi pe

funcţiile acestuia. Aceasta înseamnă că decizia managerială trebuie să

îndeplinească următoarele caracteristici:

să fie fundamentată ştiinţific, adică să se bazeze pe o serie de informaţii

bine studiate şi analizate;

să fie împuternicită, adică să fie adoptată de persoana care are sarcini în

acest sens, care are cunoştinţele, calităţile şi aptitunile necesare

fundamentării respectivei decizii;

să fie clară, concisă, necontradictorie și realistă, ceea ce presupune

adoptarea deciziei cu o prealabilă evaluare a situaţiei de fapt şi o

cunoaştere exactă a problemei a cărei rezolvare este vizată de decizie;

să fie oportună, adică să fie adoptată în cel mai adecvat moment, din

punct de vedere al eficacităţii, executarea sa făcându-se cu cele mai

6

O alegere conducând la un anume obiectiv dorit (Churchman, 1968);

O formă specifică de angajare într-o acţiune - de obicei, este vorba de

angajarea unor resurse (Mintzberg, Raisinghani, Theoret, 1976;

Mintzberg, 1980);

Elaborarea ad-hoc a mai multe strategii alternative, analiza strategiilor

elaborate şi a celor deja formulate şi alegerea unora dintre ele (Popescu,

Găvănescu, Rădulescu, 1983);

Rezultatul unui tip particular de prelucrare a informaţiilor, care constă în

alegerea unui plan de acţiune (Holsapple, Whinston, 1993);

Alegerea uneia dintr-un număr de alternative; cunoştinţe – în sens de

elemente de cunoaştere, care indică o angajare într-o anumită direcţie de

acţiune (Holsapple, Whinston, 1996);

O alocare a resurselor (Spradlin, 1997);

Alegerea uneia dintre mai multe alternative; o afirmaţie care arată

angajarea într-o direcţie de acţiune (Power, 2000);

Indiferent cum este definită decizia, ea este o necesitate obiectivă care

transpusă la nivel managerial este rezultatul procesului de gândire al

managerului care a trasat-o. Ceea ce determină managerul să opteze pentru o

alternativă şi nu pentru alta este informaţia. Atunci când aceasta există,

alegerea este mai simplă, uneori chiar evidentă, alteori alegerea urmează

numai după o atentă prelucrare a noilor date. Ceea ce trebuie să conteze în

luarea unei decizii corecte sunt consecinţele pe care aceasta le va avea

asupra organizaţiei. De aceea, decizia este sarcina comună tuturor funcţiilor

manageriale şi se dezvoltă în sistem piramidal pe nivele de management şi pe

funcţiile acestuia. Aceasta înseamnă că decizia managerială trebuie să

îndeplinească următoarele caracteristici:

să fie fundamentată ştiinţific, adică să se bazeze pe o serie de informaţii

bine studiate şi analizate;

să fie împuternicită, adică să fie adoptată de persoana care are sarcini în

acest sens, care are cunoştinţele, calităţile şi aptitunile necesare

fundamentării respectivei decizii;

să fie clară, concisă, necontradictorie și realistă, ceea ce presupune

adoptarea deciziei cu o prealabilă evaluare a situaţiei de fapt şi o

cunoaştere exactă a problemei a cărei rezolvare este vizată de decizie;

să fie oportună, adică să fie adoptată în cel mai adecvat moment, din

punct de vedere al eficacităţii, executarea sa făcându-se cu cele mai


7

potrivite mijloace şi cu cele mai reduse cheltuieli, dar obţinându-se

rezultate maxime. Oportunitatea se apreciază aşadar, în funcţie de

condiţiile concrete de timp şi de loc.

să fie eficientă, adică să coreleze raportul dintre efectul obţinut şi efortul

făcut;

să fie completă, adică să cuprindă toate elementele necesare înţelegerii

corecte şi, mai ales, implementării deciziei.

Abordările recente ale noțiunii de decizie3, ne îndreptățesc să avem în

vedere și aceste aspecte:

decizia luată la nivel superior este urmată de decizii la celelalte nivele

pentru realizarea ei, cu alte cuvinte o decizie luată devine scop sau

obiect pentru altele care o urmează;

decizia luată la nivelul funcţiei de previziune se realizează printr-o seamă

de decizii luate la nivelul realizării-coordonării, etc. Se poate spune că o

decizie implică un volum decizional ulterior şi o sumă de acţiuni pentru

materializarea ei.

Deşi în procesul decizional ignorarea oricărei funcţii manageriale poate

avea efecte negative, esenţiale ramân funcţiile de previziune şi control,

furnizoare de informaţii asupra stărilor şi stadiilor proceselor decizionale din

organizaţii. Figura de mai jos indică faptul că funcțiile managementului reflectă

dublul caracter al procesului managerial: ca ştiinţă şi ca artă. În acest sens,

funcţiile de previziune şi organizare necesită cunoştinţe teoretice de

management, pe când cele de antrenare, coordonare şi control-evaluare

necesită experienţă practică.

Figura 1.1. – Dublul caracter al funcţiilor managementului

3http://www.tutorialspoint.com/management_information_system/managerial_ decision_making.htm

Coordonare Antrenare

Organizare Previziune

informaţii Decizii strategice n = 1

7

potrivite mijloace şi cu cele mai reduse cheltuieli, dar obţinându-se

rezultate maxime. Oportunitatea se apreciază aşadar, în funcţie de

condiţiile concrete de timp şi de loc.

să fie eficientă, adică să coreleze raportul dintre efectul obţinut şi efortul

făcut;

să fie completă, adică să cuprindă toate elementele necesare înţelegerii

corecte şi, mai ales, implementării deciziei.

Abordările recente ale noțiunii de decizie3, ne îndreptățesc să avem în

vedere și aceste aspecte:

decizia luată la nivel superior este urmată de decizii la celelalte nivele

pentru realizarea ei, cu alte cuvinte o decizie luată devine scop sau

obiect pentru altele care o urmează;

decizia luată la nivelul funcţiei de previziune se realizează printr-o seamă

de decizii luate la nivelul realizării-coordonării, etc. Se poate spune că o

decizie implică un volum decizional ulterior şi o sumă de acţiuni pentru

materializarea ei.

Deşi în procesul decizional ignorarea oricărei funcţii manageriale poate

avea efecte negative, esenţiale ramân funcţiile de previziune şi control,

furnizoare de informaţii asupra stărilor şi stadiilor proceselor decizionale din

organizaţii. Figura de mai jos indică faptul că funcțiile managementului reflectă

dublul caracter al procesului managerial: ca ştiinţă şi ca artă. În acest sens,

funcţiile de previziune şi organizare necesită cunoştinţe teoretice de

management, pe când cele de antrenare, coordonare şi control-evaluare

necesită experienţă practică.

Figura 1.1. – Dublul caracter al funcţiilor managementului

3http://www.tutorialspoint.com/management_information_system/managerial_ decision_making.htm

Coordonare Antrenare

Organizare Previziune

informaţii Decizii strategice n = 1


8

Indiferent de accentul pus pe conţinutul noţional, orice proces decizional

cuprinde următoarele elemente caracteristice:

un decident, care apare ca subiect al deciziei şi care poate fi individual

sau colectiv, şi, în mod obligatoriu, investit cu puterea de a decide;

Decidentul4 este persoana (sau grupul de persoane) care alege calea de

acţiune şi care angajează folosirea resurselor. Dacă în deciziile care

privesc viaţa personală, aceasta cerinţă nu ridică probleme, atunci când

este vorba de resursele unei organizaţii, lucrurile sunt, fără excepţie, mai

complexe: este nevoie de o împuternicire în acest sens, însoţită de

stabilirea răspunderii pentru folosirea eficace sau eficientă a resurselor.

mulţimea variantelor să fie formată din cel puţin două elemente;

condiţiile obiective specifice mediului în care se va decide şi acţiona;

o mulţime de consecinţe, care ar putea apărea adoptându-se o

alternativă de acţiune;

criteriul, cu ajutorul căruia se confirmă că alternativa adoptată asigură în

măsură maximă echilibrul dintre urmările pozitive şi negative.

Interesant este însă de analizat relaţia decizie - decident pentru a

evidenţia rolul acestora în procesul decizional şi a înţelege mecanismul pentru

asistarea deciziilor de management. Startul îl poate constitui realizarea unui

model de evaluare realist, obiectiv care să ofere răspunsuri la întrebări de

genul: "Când un manager este competent şi când este mai puţin competent?",

"Cum putem previziona o activitate managerială performantă?". Mergând pe

firul analizei, este nevoie să fie identificaţi factorii constituenţi ai unei decizii

bune si care sunt cei ai unei decizii foarte bune dar şi ce diferenţe pot fi

evidenţiate astfel încât acestea să fie evaluate cât mai bine. Putem considera

următorii factori cvasi-independenţi, ca factorii constituenţi ai deciziei

manageriale:

Coeficientul de inteligenţă cognitivă (Q.I.);

Coeficientul de inteligenţă emoţională (Q.E.);

Responsabilitate (grad de) a individului;

Motivaţia intrinsecă (sistemul motivaţional al individului);

Pregătirea profesională (teoretică şi practică) în domeniul pentru care

se emit decizii;

Experienţa în activitate;

Viteza de reacţie (promtitudinea);

Orizontul de cultură.

4 Filip, F.G. (2001). Decizie asistată de calculator; decizie şi decidenţi - o încercare de sistematizare, Revista Informatică Economică, 1 (17): 7-25.

8

Indiferent de accentul pus pe conţinutul noţional, orice proces decizional

cuprinde următoarele elemente caracteristice:

un decident, care apare ca subiect al deciziei şi care poate fi individual

sau colectiv, şi, în mod obligatoriu, investit cu puterea de a decide;

Decidentul4 este persoana (sau grupul de persoane) care alege calea de

acţiune şi care angajează folosirea resurselor. Dacă în deciziile care

privesc viaţa personală, aceasta cerinţă nu ridică probleme, atunci când

este vorba de resursele unei organizaţii, lucrurile sunt, fără excepţie, mai

complexe: este nevoie de o împuternicire în acest sens, însoţită de

stabilirea răspunderii pentru folosirea eficace sau eficientă a resurselor.

mulţimea variantelor să fie formată din cel puţin două elemente;

condiţiile obiective specifice mediului în care se va decide şi acţiona;

o mulţime de consecinţe, care ar putea apărea adoptându-se o

alternativă de acţiune;

criteriul, cu ajutorul căruia se confirmă că alternativa adoptată asigură în

măsură maximă echilibrul dintre urmările pozitive şi negative.

Interesant este însă de analizat relaţia decizie - decident pentru a

evidenţia rolul acestora în procesul decizional şi a înţelege mecanismul pentru

asistarea deciziilor de management. Startul îl poate constitui realizarea unui

model de evaluare realist, obiectiv care să ofere răspunsuri la întrebări de

genul: "Când un manager este competent şi când este mai puţin competent?",

"Cum putem previziona o activitate managerială performantă?". Mergând pe

firul analizei, este nevoie să fie identificaţi factorii constituenţi ai unei decizii

bune si care sunt cei ai unei decizii foarte bune dar şi ce diferenţe pot fi

evidenţiate astfel încât acestea să fie evaluate cât mai bine. Putem considera

următorii factori cvasi-independenţi, ca factorii constituenţi ai deciziei

manageriale:

Coeficientul de inteligenţă cognitivă (Q.I.);

Coeficientul de inteligenţă emoţională (Q.E.);

Responsabilitate (grad de) a individului;

Motivaţia intrinsecă (sistemul motivaţional al individului);

Pregătirea profesională (teoretică şi practică) în domeniul pentru care

se emit decizii;

Experienţa în activitate;

Viteza de reacţie (promtitudinea);

Orizontul de cultură.

4 Filip, F.G. (2001). Decizie asistată de calculator; decizie şi decidenţi - o încercare de sistematizare, Revista Informatică Economică, 1 (17): 7-25.


9

În stabilirea factorilor constituenţi ai deciziei manageriale a fost luată în

considerare definiţia deciziei manageriale adoptată anterior dar şi definiţia dată

de DEX: "act cu caracter obligatoriu, normativ al unui organ de conducere care

stabileşte direcţia unei acţiuni şi modul ei de realizare." O hartă grafică a

deciziei (vezi Figura 1.2.) este realizată din punct de vedere al evaluării

psihometrice (Radu, Pescaru 2006), astfel că toţi factorii amintiţi mai sus pot fi

evaluaţi şi cuantificaţi. Pe baza elaborării unui model aşteptat al "hărţii"

decidentului performant, se pot evidenţia apoi diferenţe şi face analize

predictive. Astfel urmărind şi analizând harta deciziei, observăm că:

decizia are viteza de reacţie maximă adică a fost luată la momentul

oportun;

are inteligenţă standard deoarece împleteşte optim cerinţele cu resursele;

are un grad ridicat de responsabilitate întrucât reduce atât cât este posibil

riscurile;

are un nivel optim de inteligenţă emoţională, ţinând cont de problemele

socio-umane existente sau viitoare;

are o motivaţe intrinsecă relativ scazută, are şanse să nu fie pusă în

aplicare prin non-implicare sau să nu fie urmărită realizarea ei;

integrează la maxim cunostinţe specifice profesionale;

nu are un nivel ridicat de strategie, îi lipseşte o mai mare experienţă în

activitate fiind, din această cauză, nevoie de ajutorul unui/unor consilieri;

are un orizont de cultură "mediu", comunicarea ei (a deciziei) putând să-i

compromită realizarea obiectivă.

Sursa: www.e-scoala.ro

Figura 1.2. - Harta grafică a deciziei

9

În stabilirea factorilor constituenţi ai deciziei manageriale a fost luată în

considerare definiţia deciziei manageriale adoptată anterior dar şi definiţia dată

de DEX: "act cu caracter obligatoriu, normativ al unui organ de conducere care

stabileşte direcţia unei acţiuni şi modul ei de realizare." O hartă grafică a

deciziei (vezi Figura 1.2.) este realizată din punct de vedere al evaluării

psihometrice (Radu, Pescaru 2006), astfel că toţi factorii amintiţi mai sus pot fi

evaluaţi şi cuantificaţi. Pe baza elaborării unui model aşteptat al "hărţii"

decidentului performant, se pot evidenţia apoi diferenţe şi face analize

predictive. Astfel urmărind şi analizând harta deciziei, observăm că:

decizia are viteza de reacţie maximă adică a fost luată la momentul

oportun;

are inteligenţă standard deoarece împleteşte optim cerinţele cu resursele;

are un grad ridicat de responsabilitate întrucât reduce atât cât este posibil

riscurile;

are un nivel optim de inteligenţă emoţională, ţinând cont de problemele

socio-umane existente sau viitoare;

are o motivaţe intrinsecă relativ scazută, are şanse să nu fie pusă în

aplicare prin non-implicare sau să nu fie urmărită realizarea ei;

integrează la maxim cunostinţe specifice profesionale;

nu are un nivel ridicat de strategie, îi lipseşte o mai mare experienţă în

activitate fiind, din această cauză, nevoie de ajutorul unui/unor consilieri;

are un orizont de cultură "mediu", comunicarea ei (a deciziei) putând să-i

compromită realizarea obiectivă.

Sursa: www.e-scoala.ro

Figura 1.2. - Harta grafică a deciziei


10

O decizie îmbracă forma unui proces decizional în sensul desfăşurării

sale în mai multe faze, pe parcursul cărora:

- se culeg şi se analizează o anumită cantitate de informaţii;

- se stabilesc unul sau mai multe obiective;

- se identifică mai multe variante pentru atingerea obiectivelor;

- se aleg sau selectează una dintre posibilităţile de realizare conturate.

Abordările decizionale specifice managementului depăşesc faza

regulilor de decizie, concretizându-se în modele decizionale, care

preconizează un mod eficace de structurare a procesului decizional, prin

integrarea elementelor implicate şi a interrelaţiilor dintre ele într-o schemă

logică, ce reflectă funcţionalitatea voită a mecanismului decizional (vezi

Figura1.3.).

Figura 1.3 – Schema logică a mecanismului decizional

O evaluare de ansamblu a numeroaselor studii publicate (Oashott, 1998)

despre procesul decizional ne permit să structurăm procesul decizional în 6

etape:

1. Identificarea şi definirea problemei decizionale;

2. Precizarea obiectivului sau obiectivelor urmărite;

3. Stabilirea alternativelor sau variantelor decizionale;

4. Alegerea variantei optime, respectiv deciderea;

5. Aplicarea deciziei;

6. Evaluarea rezultatelor obţinute.

Situaţie stimul

Conceperea sau

modelul deciziei

Clasificarea obiectivelor şi evaluarea îmbunătăţirii lor

Adunarea datelor pentru prevederea

rezultatelor

Enunțarea soluțiilor alternative

Alegerea imediată

10

O decizie îmbracă forma unui proces decizional în sensul desfăşurării

sale în mai multe faze, pe parcursul cărora:

- se culeg şi se analizează o anumită cantitate de informaţii;

- se stabilesc unul sau mai multe obiective;

- se identifică mai multe variante pentru atingerea obiectivelor;

- se aleg sau selectează una dintre posibilităţile de realizare conturate.

Abordările decizionale specifice managementului depăşesc faza

regulilor de decizie, concretizându-se în modele decizionale, care

preconizează un mod eficace de structurare a procesului decizional, prin

integrarea elementelor implicate şi a interrelaţiilor dintre ele într-o schemă

logică, ce reflectă funcţionalitatea voită a mecanismului decizional (vezi

Figura1.3.).

Figura 1.3 – Schema logică a mecanismului decizional

O evaluare de ansamblu a numeroaselor studii publicate (Oashott, 1998)

despre procesul decizional ne permit să structurăm procesul decizional în 6

etape:

1. Identificarea şi definirea problemei decizionale;

2. Precizarea obiectivului sau obiectivelor urmărite;

3. Stabilirea alternativelor sau variantelor decizionale;

4. Alegerea variantei optime, respectiv deciderea;

5. Aplicarea deciziei;

6. Evaluarea rezultatelor obţinute.

Situaţie stimul

Conceperea sau

modelul deciziei

Clasificarea obiectivelor şi evaluarea îmbunătăţirii lor

Adunarea datelor pentru prevederea

rezultatelor

Enunțarea soluțiilor alternative

Alegerea imediată


11

Pe parcursul desfăşurării procesului decizional, în funcţie de

constatarea necesităţii unor informaţii suplimentare, pot apărea reveniri de la

activităţile care compun fazele din aval la cele din amonte, ordinea lor nefiind

rigidă. Încadrarea în succesiunea raţională a operaţiilor decizionale nu trebuie

transformată într-un obiectiv în sine, care să fie urmărit cu orice preţ, lucru

evidenţiat prin Figura 1.4.

Figura 1.4. - Model de structurare a procesului decizional

Cunoscând foarte bine etapele procesului decizional, managerul poate

să conştientizeze mai bine propriile procese decizionale şi, astfel, să le poată

controla, să înţeleagă de ce anumite decizii luate în trecut nu au avut efectul

aşteptat.

În general, efectul aplicării unei decizii îl constituie obţinerea anumitor

obiective (scopuri), de claritatea formulării acestora depinzând eficienţa acţiunii

întreprinse, precum şi utilizarea raţională a informaţiilor disponibile. De aceea,

relaţii directe relaţii indirecte

Mediul deciziona

l

Mediul decizional

Sit

uaţ

ia s

tim

ul

Iden

tific

area

şi d

efin

irea

prob

lem

ei

Pre

ciza

rea

obie

ctiv

ului

Sta

bilir

ea a

ltern

ativ

elor

Dec

ider

ea

Apl

icar

ea d

eciz

iei

Eva

luar

ea r

ezul

tate

lor

Situaţii stimul

11

Pe parcursul desfăşurării procesului decizional, în funcţie de

constatarea necesităţii unor informaţii suplimentare, pot apărea reveniri de la

activităţile care compun fazele din aval la cele din amonte, ordinea lor nefiind

rigidă. Încadrarea în succesiunea raţională a operaţiilor decizionale nu trebuie

transformată într-un obiectiv în sine, care să fie urmărit cu orice preţ, lucru

evidenţiat prin Figura 1.4.

Figura 1.4. - Model de structurare a procesului decizional

Cunoscând foarte bine etapele procesului decizional, managerul poate

să conştientizeze mai bine propriile procese decizionale şi, astfel, să le poată

controla, să înţeleagă de ce anumite decizii luate în trecut nu au avut efectul

aşteptat.

În general, efectul aplicării unei decizii îl constituie obţinerea anumitor

obiective (scopuri), de claritatea formulării acestora depinzând eficienţa acţiunii

întreprinse, precum şi utilizarea raţională a informaţiilor disponibile. De aceea,

relaţii directe relaţii indirecte

Mediul deciziona

l

Mediul decizional

Sit

uaţ

ia s

tim

ul

Iden

tific

area

şi d

efin

irea

prob

lem

ei

Pre

ciza

rea

obie

ctiv

ului

Sta

bilir

ea a

ltern

ativ

elor

Dec

ider

ea

Apl

icar

ea d

eciz

iei

Eva

luar

ea r

ezul

tate

lor

Situaţii stimul


12

la stabilirea obiectivelor se recomandă întocmirea unei liste a factorilor care

cuprind rezultatele urmărite şi resursele disponibile (Figura 1.5.a), elemente

care trebuie bine armonizate.

Întrucât de cele mai multe ori o decizie importantă are un caracter

complex, cu implicaţii tehnice, economice, sociale şi politice, este necesară o

anume clasificare a obiectivelor şi anume: obiective obligatorii (acele rezultate

sau resurse din care unul singur dacă nu este realizat, întreaga decizie se

poate solda cu un eşec), obiective deziderat (dacă unul din rezultate nu este

îndeplinit la valoarea preconizată, decizia nu se soldează cu eşec). În această

etapă, decidentul trebuie să efectueze, în afara operaţiei de împărţire a

obiectivelor în cele două categorii, şi o anume ierarhizare a obiectivelor

deziderat, în care scop se poate folosi o scară convenţională de valori,

cuprinsă între 0 şi 1 (Figura 1.5. b).

Figura 1.5. – Ierarhizarea obiectivelor de realizat

1.2. Modelarea proceselor decizionale. Principalele modele de

fundamentare a deciziilor

Modelul, ca instrument al cunoaşterii ştiinţifice, este folosit în foarte

numeroase discipline teoretice şi practice. Fără pretenţia de a face o clasificare

riguroasă a tipurilor de modele, vom arăta că ele pot fi: modele verbal-

descriptive – folosite în toate disciplinele matematizate, modele matematice,

Obiective

Rezultate Resurse

Obiective

1 2 3 4

Pondere

Număr de obiective

obligatorii

6 5 4 3 2 1

Pondere

Număr de obiective

deziderate

a b

0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9

12

la stabilirea obiectivelor se recomandă întocmirea unei liste a factorilor care

cuprind rezultatele urmărite şi resursele disponibile (Figura 1.5.a), elemente

care trebuie bine armonizate.

Întrucât de cele mai multe ori o decizie importantă are un caracter

complex, cu implicaţii tehnice, economice, sociale şi politice, este necesară o

anume clasificare a obiectivelor şi anume: obiective obligatorii (acele rezultate

sau resurse din care unul singur dacă nu este realizat, întreaga decizie se

poate solda cu un eşec), obiective deziderat (dacă unul din rezultate nu este

îndeplinit la valoarea preconizată, decizia nu se soldează cu eşec). În această

etapă, decidentul trebuie să efectueze, în afara operaţiei de împărţire a

obiectivelor în cele două categorii, şi o anume ierarhizare a obiectivelor

deziderat, în care scop se poate folosi o scară convenţională de valori,

cuprinsă între 0 şi 1 (Figura 1.5. b).

Figura 1.5. – Ierarhizarea obiectivelor de realizat

1.2. Modelarea proceselor decizionale. Principalele modele de

fundamentare a deciziilor

Modelul, ca instrument al cunoaşterii ştiinţifice, este folosit în foarte

numeroase discipline teoretice şi practice. Fără pretenţia de a face o clasificare

riguroasă a tipurilor de modele, vom arăta că ele pot fi: modele verbal-

descriptive – folosite în toate disciplinele matematizate, modele matematice,

Obiective

Rezultate Resurse

Obiective

1 2 3 4

Pondere

Număr de obiective

obligatorii

6 5 4 3 2 1

Pondere

Număr de obiective

deziderate

a b

0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9


13

modele fizice analogice (de tipul machetelor statice sau dinamice), modele

grafice etc.

Folosirea modelelor necesită adesea formularea unor ipoteze

dubitabile, aplicarea unor costuri improbabile şi a altor date, ca şi predicţia

evenimentelor viitoare care nu sunt aşa uşor de anticipat. Chiar şi în acest caz,

cunoştinţele obţinute din lucrul cu modelele şi încercarea de a le aplica pot

descoperi concepte valoroase în legătură cu o anumită problemă şi cu tipurile

de decizii care sunt necesare. Simpla recunoaştere a zonelor de decizie poate

fi un progres major în multe situaţii. În plus, folosind modelele, decidenţii pot

recunoaşte variabilele care pot fi controlate pentru a influenţa performanţele

sistemului, costurile relevante şi magnitudinea lor precum şi corelaţia dintre

costuri şi variabile, inclusiv opţiunile de costuri importante.

O serie de reguli de bază trebuie cunoscute ca preambul al activităţii de

modelare (Ungureanu, 2012):

- Punctul de plecare îl constituie un model extrem de simplu care apoi este

continuu rafinat prin îmbunătăţiri. Acest proces de îmbogăţire succesivă se

materializezază în versiuni din ce în ce mai elaborate şi mai veridice ale

fenomenului analizat şi va permite în final obţinerea unor soluţii mai bune.

Gradualitatea construcţiei modelului permite reţinerea la fiecare nivel a acelei

„părţi " cunoscute şi verificate, iar în locul ei introducerea unor date şi informaţii

noi spre a fi procesate. Această manieră de abordare mai poartă denumirea de

greedy şi permite obţinerea în fiecare etapă a câştigului maxim pe linia funcţie

- scop.

Alegerea modelului de bază este fundamentală, aşadar se recomandă

asocieri şi analogii ale fenomenului de modelat, cu structuri şi scheme

logice complexe a căror valoare de adevăr este cunoscută.

Procesul de modelare are un caracter iterativ, la fiecare pas având de

făcut următoarea alegere:

Fie confruntarea fiecărei versiuni a modelului cu realitatea

reprezentată prin datele cuantificabile. Ca finalitate a seriei de teste,

rezultatul poate fi o versiune „acceptabilă" a modelului, care poate fi

exploatată o anumită perioadă de timp, sau concluzia că este

necesară o nouă versiune, care trebuie apoi şi ea testată.

Fie explorarea structutii deductive a modelului în contextul ipotezelor

făcute. Dacă obiectivele deductive la nivelul pasului respectiv sunt

13

modele fizice analogice (de tipul machetelor statice sau dinamice), modele

grafice etc.

Folosirea modelelor necesită adesea formularea unor ipoteze

dubitabile, aplicarea unor costuri improbabile şi a altor date, ca şi predicţia

evenimentelor viitoare care nu sunt aşa uşor de anticipat. Chiar şi în acest caz,

cunoştinţele obţinute din lucrul cu modelele şi încercarea de a le aplica pot

descoperi concepte valoroase în legătură cu o anumită problemă şi cu tipurile

de decizii care sunt necesare. Simpla recunoaştere a zonelor de decizie poate

fi un progres major în multe situaţii. În plus, folosind modelele, decidenţii pot

recunoaşte variabilele care pot fi controlate pentru a influenţa performanţele

sistemului, costurile relevante şi magnitudinea lor precum şi corelaţia dintre

costuri şi variabile, inclusiv opţiunile de costuri importante.

O serie de reguli de bază trebuie cunoscute ca preambul al activităţii de

modelare (Ungureanu, 2012):

- Punctul de plecare îl constituie un model extrem de simplu care apoi este

continuu rafinat prin îmbunătăţiri. Acest proces de îmbogăţire succesivă se

materializezază în versiuni din ce în ce mai elaborate şi mai veridice ale

fenomenului analizat şi va permite în final obţinerea unor soluţii mai bune.

Gradualitatea construcţiei modelului permite reţinerea la fiecare nivel a acelei

„părţi " cunoscute şi verificate, iar în locul ei introducerea unor date şi informaţii

noi spre a fi procesate. Această manieră de abordare mai poartă denumirea de

greedy şi permite obţinerea în fiecare etapă a câştigului maxim pe linia funcţie

- scop.

Alegerea modelului de bază este fundamentală, aşadar se recomandă

asocieri şi analogii ale fenomenului de modelat, cu structuri şi scheme

logice complexe a căror valoare de adevăr este cunoscută.

Procesul de modelare are un caracter iterativ, la fiecare pas având de

făcut următoarea alegere:

Fie confruntarea fiecărei versiuni a modelului cu realitatea

reprezentată prin datele cuantificabile. Ca finalitate a seriei de teste,

rezultatul poate fi o versiune „acceptabilă" a modelului, care poate fi

exploatată o anumită perioadă de timp, sau concluzia că este

necesară o nouă versiune, care trebuie apoi şi ea testată.

Fie explorarea structutii deductive a modelului în contextul ipotezelor

făcute. Dacă obiectivele deductive la nivelul pasului respectiv sunt


14

uşor de atins, ipotezele pot fi rafinate (restricţii mai tari), dacă nu, ele

trebuie relaxate (condiţii mai slabe).

Utilizarea modelelor decizionale nu este simplă. Diferite studii au arătat

că multe proiecte ce erau destinate să ajute managerii în procesul decizional

prin dezvoltarea unor modele decizionale s-au dovedit eşecuri.

Înainte de a decide dacă merită să utilizăm un model decizional pentru

a ajuta procesul decizional, trebuie să avem în vedere patru întrebări:

1. Cât va costa? Dezvoltarea şi adaptarea modelelor poate fi costisitoare

pentru că experţii trebuie plătiţi bine. O excepţie o constituie pachetele

software pentru computere, mai ales în domeniul modelării financiare.

2. Cât de mult va dura? Timpul necesar construirii unui model este mai

lung decât timpul necesar gândirii unei decizii de către manageri.

Timpul luării unei decizii este deseori scurt. Deci, nu contează cât de

util poate fi un model, el nu este de nici un folos dacă decizia trebuie

luată înainte de terminarea modelului.

3. Până unde poate îmbunătăţii un model o judecată nesusţinută?

Dezvoltarea unui model nu este necesară atunci când costul său este

mai mare decât beneficiul maxim obţinut.

4. Influenţează modelarea luarea deciziei? Pentru a răspunde la această

întrebare, probabil cea mai importantă, trebuie să luăm în considerare

circumstanţele deciziei însăşi. McClelland diastinge trei trăsături ale

situaţiei decizionale care influenţează capacitatea de a ajuta pe

decident:

a. Resursele puse în joc. Cu cât sunt mai multe resurse în joc, cu

atât este mai importantă luarea unei decizii acceptabile, şi de

aceea trebuie folosite mai multe ajutoare. În opoziţie dacă

„miza” este mică, este mai puţin probabil că merită timpul,

efortul şi cheltuiala efectuată.

b. Complexitatea problemei. Este foarte cunoscută capacitatea

modelului matematic de a manevra un număr mare de factori

complexi interdependenţi. Totuşi, multe probleme manageriale

sunt aşa de complexe şi atât de multe soluţii posibile, încât nu

pot fi rezolvate nici de cel mai sofisticat model.

c. Relevanţa datelor. Dacă e dorit să se obţină un „răspuns” de la

un model, răspunsul va depinde de datele folosite pentru

modelul respectiv. De aceea, un model este suficient atunci

14

uşor de atins, ipotezele pot fi rafinate (restricţii mai tari), dacă nu, ele

trebuie relaxate (condiţii mai slabe).

Utilizarea modelelor decizionale nu este simplă. Diferite studii au arătat

că multe proiecte ce erau destinate să ajute managerii în procesul decizional

prin dezvoltarea unor modele decizionale s-au dovedit eşecuri.

Înainte de a decide dacă merită să utilizăm un model decizional pentru

a ajuta procesul decizional, trebuie să avem în vedere patru întrebări:

1. Cât va costa? Dezvoltarea şi adaptarea modelelor poate fi costisitoare

pentru că experţii trebuie plătiţi bine. O excepţie o constituie pachetele

software pentru computere, mai ales în domeniul modelării financiare.

2. Cât de mult va dura? Timpul necesar construirii unui model este mai

lung decât timpul necesar gândirii unei decizii de către manageri.

Timpul luării unei decizii este deseori scurt. Deci, nu contează cât de

util poate fi un model, el nu este de nici un folos dacă decizia trebuie

luată înainte de terminarea modelului.

3. Până unde poate îmbunătăţii un model o judecată nesusţinută?

Dezvoltarea unui model nu este necesară atunci când costul său este

mai mare decât beneficiul maxim obţinut.

4. Influenţează modelarea luarea deciziei? Pentru a răspunde la această

întrebare, probabil cea mai importantă, trebuie să luăm în considerare

circumstanţele deciziei însăşi. McClelland diastinge trei trăsături ale

situaţiei decizionale care influenţează capacitatea de a ajuta pe

decident:

a. Resursele puse în joc. Cu cât sunt mai multe resurse în joc, cu

atât este mai importantă luarea unei decizii acceptabile, şi de

aceea trebuie folosite mai multe ajutoare. În opoziţie dacă

„miza” este mică, este mai puţin probabil că merită timpul,

efortul şi cheltuiala efectuată.

b. Complexitatea problemei. Este foarte cunoscută capacitatea

modelului matematic de a manevra un număr mare de factori

complexi interdependenţi. Totuşi, multe probleme manageriale

sunt aşa de complexe şi atât de multe soluţii posibile, încât nu

pot fi rezolvate nici de cel mai sofisticat model.

c. Relevanţa datelor. Dacă e dorit să se obţină un „răspuns” de la

un model, răspunsul va depinde de datele folosite pentru

modelul respectiv. De aceea, un model este suficient atunci


15

când datele pe care le prelucrează sunt precise şi

cuprinzătoare.

Principalele modele de fundamentare a deciziilor

Modele de programare liniară. Modelele de programare liniară tratează

clasele de decizii în care resursele trebuie alocate uneia sau mai multor

activităţi. În general, există reguli care guvernează posibilitatea unei alocări.

Aceste reguli fie limitează nivelul resurselor care pot fi alocate activităţilor, fie

afectează modul în care pot fi combinate resursele. Regulile sunt numite

restricţii. Combinarea resurselor este apoi legată de o măsură formală a

obiectivelor, numită funcţie obiectiv, care poate fi maximizată (dacă este

exprimată, de exemplu, în termeni de profil) sau minimizată (dacă este

exprimată în termeni de cost). Atunci când restricţiile şi funcţia obiectiv sunt

funcţii liniare, poate fi formulat un model de programare liniară.

În cadrul programării liniare, se iau în considerare mai multe metode:

grafică, simplex, metoda transporturilor. Prezentăm în continuare un model util

pentru vizualizarea conceptelor de bază ale acestei metode.

Exemplificare: O firmă realizează două produse A şi B. Fiecare din ele

necesită volume diferite din trei tipuri de muncă: subasamblare, asamblare şi

inspecţie. Luna viitoare vor fi disponibile 316 ore de muncă de subasamblare,

354 ore de muncă de asamblare şi 62 ore de muncă de inspecţie. Managerul

operaţiunilor cunoaşte faptul că fiecare produs de tip A necesită 0,4 ore de

muncă de subasamblare, 0,5 ore de muncă de asamblare şi 0,05 ore de

muncă de inspecţie, iar un produs de tip B necesită 0,5 ore de muncă de

subasamblare, 0,3 ore de muncă de asamblare şi 0,10 ore de muncă de

inspecţie. Managerul de marketing este sigur că tot ceea ce va fi produs în

viitorul apropiat poate fi vândut. Se mai ştie că fiecare produs de tip A vândut

contribuie cu 50 u.m. la profit şi cheltuieli de regie, pe când un produs de tip B

contribuie cu 40u.m. la profit şi cheltuieli de regie. Ce decizie va lua managerul

general privind atât capacitatea de producţie cât şi structura de producţie

pentru luna viitoare ?

1. Identificarea variabilelor de decizie. Atât produsele de tip A cât şi cele de

tip B pot fi produse de firma respectivă. Acestea sunt cele două variabile de

decizie. Problema constă în a decide câte produse de tip A şi câte de tip B

15

când datele pe care le prelucrează sunt precise şi

cuprinzătoare.

Principalele modele de fundamentare a deciziilor

Modele de programare liniară. Modelele de programare liniară tratează

clasele de decizii în care resursele trebuie alocate uneia sau mai multor

activităţi. În general, există reguli care guvernează posibilitatea unei alocări.

Aceste reguli fie limitează nivelul resurselor care pot fi alocate activităţilor, fie

afectează modul în care pot fi combinate resursele. Regulile sunt numite

restricţii. Combinarea resurselor este apoi legată de o măsură formală a

obiectivelor, numită funcţie obiectiv, care poate fi maximizată (dacă este

exprimată, de exemplu, în termeni de profil) sau minimizată (dacă este

exprimată în termeni de cost). Atunci când restricţiile şi funcţia obiectiv sunt

funcţii liniare, poate fi formulat un model de programare liniară.

În cadrul programării liniare, se iau în considerare mai multe metode:

grafică, simplex, metoda transporturilor. Prezentăm în continuare un model util

pentru vizualizarea conceptelor de bază ale acestei metode.

Exemplificare: O firmă realizează două produse A şi B. Fiecare din ele

necesită volume diferite din trei tipuri de muncă: subasamblare, asamblare şi

inspecţie. Luna viitoare vor fi disponibile 316 ore de muncă de subasamblare,

354 ore de muncă de asamblare şi 62 ore de muncă de inspecţie. Managerul

operaţiunilor cunoaşte faptul că fiecare produs de tip A necesită 0,4 ore de

muncă de subasamblare, 0,5 ore de muncă de asamblare şi 0,05 ore de

muncă de inspecţie, iar un produs de tip B necesită 0,5 ore de muncă de

subasamblare, 0,3 ore de muncă de asamblare şi 0,10 ore de muncă de

inspecţie. Managerul de marketing este sigur că tot ceea ce va fi produs în

viitorul apropiat poate fi vândut. Se mai ştie că fiecare produs de tip A vândut

contribuie cu 50 u.m. la profit şi cheltuieli de regie, pe când un produs de tip B

contribuie cu 40u.m. la profit şi cheltuieli de regie. Ce decizie va lua managerul

general privind atât capacitatea de producţie cât şi structura de producţie

pentru luna viitoare ?

1. Identificarea variabilelor de decizie. Atât produsele de tip A cât şi cele de

tip B pot fi produse de firma respectivă. Acestea sunt cele două variabile de

decizie. Problema constă în a decide câte produse de tip A şi câte de tip B


16

pot fi produse de firma respectivă. Să notăm cu a numărul produselor de tip

A şi cu b numărul produselor de tip B.

2. Identificarea funcţiei obiectiv. Fiecare produs de tip A contribuie cu 50

u.m. la profit şi cheltuielile de regie, iar fiecare produs de tip B contribuie cu

40 u.m. Marja totală de contribuţie a firmei (profitul) este următoarea:

baP 4050 1.1.

Această funcţie liniară obiectiv prezintă faptul că profitul depinde de decizia

câte produse de tip A şi câte de tip B să fie produse. Firma doreşte ca marja

totală de contribuţii să fie cât mai mare; se doreşte deci maximizarea lui P.

3. Identificarea restricţiilor de resurse. Pentru producţia produselor este

nevoie de trei tipuri de muncă: subasamblare, asamblare şi inspecţie. Astfel,

cu ajutorul datelor putem identifica trei restricţii, câte una pentru fiecare

resursă de muncă. Aceste restricţii le putem exprima, modela, ca inegalităţi

liniare:

a) pentru subasamblare: 3165,04,0 ba

b) pentru asamblare: 3543,05,0 ba

c) pentru inspecţie: 621,005,0 ba

4. Identificarea spaţiului soluţie şi întocmirea diagramei tuturor restricţiilor

(Figura 1.6.) este cât se poate de edificatoare în acest sens. Spaţiu soluţie

reprezintă totalitatea valorilor posibile (cu semnificaţie) ale variabilelor într-o

problemă (aici, de programare liniară). Considerăm un sistem de axe de tipul

a0b. Spaţiul soluţie (partea graficului unde se poate găsi răspunsul la

problemă) constă în toate punctele de pe sau la dreapta axei verticale şi pe

sau deasupra axei orizontale (cadranul I), deoarece valorile negative ale lui a

sau b nu au nici o semnificaţie. Fiecare punct din acest spaţiu reprezintă o

combinaţie de a şi b.

Pentru reprezentarea dreptei pentru restricţia de muncă de subasamblare

se raţionează astfel: dacă toate cele 316 ore de subasamblare sunt alocate

producerii produselor de tip a, atunci pot fi produse 316 : 0,4 = 790 de astfel de

produse. Această combinaţie de producere a 0 produse de tip B şi 790

16

pot fi produse de firma respectivă. Să notăm cu a numărul produselor de tip

A şi cu b numărul produselor de tip B.

2. Identificarea funcţiei obiectiv. Fiecare produs de tip A contribuie cu 50

u.m. la profit şi cheltuielile de regie, iar fiecare produs de tip B contribuie cu

40 u.m. Marja totală de contribuţie a firmei (profitul) este următoarea:

baP 4050 1.1.

Această funcţie liniară obiectiv prezintă faptul că profitul depinde de decizia

câte produse de tip A şi câte de tip B să fie produse. Firma doreşte ca marja

totală de contribuţii să fie cât mai mare; se doreşte deci maximizarea lui P.

3. Identificarea restricţiilor de resurse. Pentru producţia produselor este

nevoie de trei tipuri de muncă: subasamblare, asamblare şi inspecţie. Astfel,

cu ajutorul datelor putem identifica trei restricţii, câte una pentru fiecare

resursă de muncă. Aceste restricţii le putem exprima, modela, ca inegalităţi

liniare:

a) pentru subasamblare: 3165,04,0 ba

b) pentru asamblare: 3543,05,0 ba

c) pentru inspecţie: 621,005,0 ba

4. Identificarea spaţiului soluţie şi întocmirea diagramei tuturor restricţiilor

(Figura 1.6.) este cât se poate de edificatoare în acest sens. Spaţiu soluţie

reprezintă totalitatea valorilor posibile (cu semnificaţie) ale variabilelor într-o

problemă (aici, de programare liniară). Considerăm un sistem de axe de tipul

a0b. Spaţiul soluţie (partea graficului unde se poate găsi răspunsul la

problemă) constă în toate punctele de pe sau la dreapta axei verticale şi pe

sau deasupra axei orizontale (cadranul I), deoarece valorile negative ale lui a

sau b nu au nici o semnificaţie. Fiecare punct din acest spaţiu reprezintă o

combinaţie de a şi b.

Pentru reprezentarea dreptei pentru restricţia de muncă de subasamblare

se raţionează astfel: dacă toate cele 316 ore de subasamblare sunt alocate

producerii produselor de tip a, atunci pot fi produse 316 : 0,4 = 790 de astfel de

produse. Această combinaţie de producere a 0 produse de tip B şi 790


17

produse de tip A este reprezentată de punctul A de pe grafic. Altă alternativă ar

consta în a nu produce nici un produs de tip A. În această situaţie se dispune

de destulă muncă de subasamblare pentru a produce 316 : 0,5 = 632 de

produse de tip B. Această situaţie este reprezentată de punctul B de pe grafic.

Deoarece toate restricţiile sunt liniare poate fi trasată o dreaptă care leagă

punctele A şi B. Fiecare punct de pe dreapta AB, dreapta de ecuaţie

3165,04,0 ba , reprezintă o combinaţie de m produse de tip A sau B care

consumă tot timpul de muncă de subasamblare. Punctele din spaţiul soluţie

care se încadrează deasupra sau pe dreapta AB sunt denumite soluţii

nefezabile deoarece necesită mai mult de 316 ore de muncă de subasamblare.

Punctele din spaţiul soluţie care se încadrează pe sau sub dreapta AB sunt

denumite soluţii fezabile.

Aşadar, dreapta CD, de ecuaţie 3543,05,0 ba este dreapta de

restricţie a muncii de subasamblare, iar dreapta EF, de ecuaţie 621,005,0 ba .

Figura.1.6 – Diagrama restricţiilor

5. Identificarea zonei de decizie fezabilă (Figura 1.7.) este, de asemenea,

relevant pentru teoria deciziei. Când managerul decide câte produse de tip

A şi câte de tip B să producă, trebuie să adere simultan la toate cele trei

restricţii relevante. Soluţiile fezabile se încadrează în zona haşurată

0FGHC.

D

B

C A E

Asamblare

Inspecţie Subasamblare

17

produse de tip A este reprezentată de punctul A de pe grafic. Altă alternativă ar

consta în a nu produce nici un produs de tip A. În această situaţie se dispune

de destulă muncă de subasamblare pentru a produce 316 : 0,5 = 632 de

produse de tip B. Această situaţie este reprezentată de punctul B de pe grafic.

Deoarece toate restricţiile sunt liniare poate fi trasată o dreaptă care leagă

punctele A şi B. Fiecare punct de pe dreapta AB, dreapta de ecuaţie

3165,04,0 ba , reprezintă o combinaţie de m produse de tip A sau B care

consumă tot timpul de muncă de subasamblare. Punctele din spaţiul soluţie

care se încadrează deasupra sau pe dreapta AB sunt denumite soluţii

nefezabile deoarece necesită mai mult de 316 ore de muncă de subasamblare.

Punctele din spaţiul soluţie care se încadrează pe sau sub dreapta AB sunt

denumite soluţii fezabile.

Aşadar, dreapta CD, de ecuaţie 3543,05,0 ba este dreapta de

restricţie a muncii de subasamblare, iar dreapta EF, de ecuaţie 621,005,0 ba .

Figura.1.6 – Diagrama restricţiilor

5. Identificarea zonei de decizie fezabilă (Figura 1.7.) este, de asemenea,

relevant pentru teoria deciziei. Când managerul decide câte produse de tip

A şi câte de tip B să producă, trebuie să adere simultan la toate cele trei

restricţii relevante. Soluţiile fezabile se încadrează în zona haşurată

0FGHC.

D

B

C A E

Asamblare

Inspecţie Subasamblare


18

6. Reprezentarea funcţiei obiectiv şi selectarea punctului optim. Deşi toate

punctele din zona haşurată sunt alternative fezabile, unele oferă o contribuţie

totală mai mare decât altele. În punctul C (708 de tip A şi 0 de tip B) de

exemplu, profitul este 3540004070850 u.m. Dar 300 produse de tip A şi 300

produse de tip B vor aduce un profit de doar 270003004030050 u.m.

Trebuie ales „cel mai bun” punct din numărul infinit de puncte din zona

fezabilă. Sarcina este destul de uşoară, ţinând cont că „cel mai bun” punct se

află în unul din colţurile zonei fezabile. Prin urmare, unul din punctele O, F, G,

H sau C este optim. Se poate calcula contribuţia totală a fiecăruia din aceste

cinci puncte şi selecta pe cel cu cea mai mare valoare.

Apelăm acum la procedura grafică pentru determinarea unui astfel de punct.

Această procedură necesită determinarea unei noi linii, linia de izo-profit sau

profit constant. Pe o astfel de linie toate punctele dau acelaşi profit. Dacă

dorim să determinăm linia de izo-profit care reprezintă o contribuţie de 25000

u.m., folosind datele problemei construim dreapta de ecuaţie:

250004050 ba (cu linie punctată) 1.2.

De exemplu, o combinaţie de 0 produse de tip A şi 625 produse de tip

B determină un profit de 25.000 u.m. Se pot obţine profituri şi mai mari. Dar, de

exemplu, unele puncte ale seriei de izoprofit de 30.000 u.m. se află în afara

zonei fezabile, nefiind alternative legitime. Deoarece alte puncte ale acestei

linii se încadrează în zona haşurată putem spune că este posibilă totuşi

obţinerea unui profit de 30.000 u.m.

A

B

C

D

E

F

G

H

Asamblare

Subasamblare

Inspecţie

Izoprofit 25000 u.m. Izoprofit 30000 u.m.

Figura.1.7. – Zona deciziei fezabile

18

6. Reprezentarea funcţiei obiectiv şi selectarea punctului optim. Deşi toate

punctele din zona haşurată sunt alternative fezabile, unele oferă o contribuţie

totală mai mare decât altele. În punctul C (708 de tip A şi 0 de tip B) de

exemplu, profitul este 3540004070850 u.m. Dar 300 produse de tip A şi 300

produse de tip B vor aduce un profit de doar 270003004030050 u.m.

Trebuie ales „cel mai bun” punct din numărul infinit de puncte din zona

fezabilă. Sarcina este destul de uşoară, ţinând cont că „cel mai bun” punct se

află în unul din colţurile zonei fezabile. Prin urmare, unul din punctele O, F, G,

H sau C este optim. Se poate calcula contribuţia totală a fiecăruia din aceste

cinci puncte şi selecta pe cel cu cea mai mare valoare.

Apelăm acum la procedura grafică pentru determinarea unui astfel de punct.

Această procedură necesită determinarea unei noi linii, linia de izo-profit sau

profit constant. Pe o astfel de linie toate punctele dau acelaşi profit. Dacă

dorim să determinăm linia de izo-profit care reprezintă o contribuţie de 25000

u.m., folosind datele problemei construim dreapta de ecuaţie:

250004050 ba (cu linie punctată) 1.2.

De exemplu, o combinaţie de 0 produse de tip A şi 625 produse de tip

B determină un profit de 25.000 u.m. Se pot obţine profituri şi mai mari. Dar, de

exemplu, unele puncte ale seriei de izoprofit de 30.000 u.m. se află în afara

zonei fezabile, nefiind alternative legitime. Deoarece alte puncte ale acestei

linii se încadrează în zona haşurată putem spune că este posibilă totuşi

obţinerea unui profit de 30.000 u.m.

A

B

C

D

E

F

G

H

Asamblare

Subasamblare

Inspecţie

Izoprofit 25000 u.m. Izoprofit 30000 u.m.

Figura.1.7. – Zona deciziei fezabile


19

Se observă că liniile de izoprofit sunt paralele şi, cu cât sunt mai departe de

originea graficului, cu atât ele reprezintă un profit mai mare. Deoarece toate

liniile au aceeaşi pantă, etapa finală constă în continuarea trasării de astfel de

linii care sunt din ce în ce mai departe de origine. Această procedură se

opreşte când orice mutare mai departe de origine ar cauza plasarea liniei de

izoprofit complet în afara zonei fezabile. În exemplul dat o astfel de linie trece

prin punctul H. Acest punct aduce profitul maxim, găsind astfel decizia optimă.

Când problema constă în maximizarea funcţiei obiectiv, curba de izoprofit

trebuie să fie cel mai departe de origine, iar când problema constă în

minimizarea sa, curba izocost trebuie să fie cel mai aproape de origine.

Decizia optimă în punctul H, interpolată din origine, necesită o producţie

de 630 produse de tip A şi 125 produse de tip B. Valoarea aproximativă care

se obţine în urma acestei decizii este

3600012563050 P u.m. 1.3.

O evaluare mai precisă a soluţiei se obţine prin observarea faptului că

punctul optim H se află la intersecţia a două drepte de restricţii, restricţie de

muncă de subasamblare şi cea de muncă de asamblare.

Rezolvând sistemul format cu ecuaţiile celor două drepte se obţin

valorile a = 125,15 şi b = 632,31 valoarea profitului fiind

06,3666115,1264031,63250 P 1.4.

7. Interpretarea soluţiei. Numărul optim de produse de tip A şi B este acum

cunoscut. Câte dintre cele trei resurse vor fi folosite pentru producerea

acestora? Va rămâne nefolosită vreuna din resurse? La aceste întrebări se

poate răspunde atât grafic cât şi algebric observând din grafic că punctul optim

H se află la intersecţia dreptelor ce prezintă restricţiile pentru munca de

subasamblare şi pentru cea de asamblare, el reprezentând maximul acestor

resurse disponibile pentru folosire. Prin urmare, valorile maxime ale acestor

două resurse sunt folosite în cadrul soluţiei optime. Nu există muncă de

subasamblare sau de asamblare nefolosită. Să luăm acum în considerare

munca de inspecţie. Soluţia optimă se incadrează sub linia corespunzătoare

muncii de inspecţie, ceea ce înseamnă că nu toată munca de inspecţie

disponibilă este folosită în soluţia optimă. O parte din această muncă rămâne

nefolosită. Putem calcula algebric munca nefolosită, ca fiind diferenţa dintre

munca de inspecţie disponibilă şi munca de inspecţie folosită:

ore

Bore

AoreoreMMM ifidin

76,1762,1262,3162

15,12610,031,63205,062

1.5.

19

Se observă că liniile de izoprofit sunt paralele şi, cu cât sunt mai departe de

originea graficului, cu atât ele reprezintă un profit mai mare. Deoarece toate

liniile au aceeaşi pantă, etapa finală constă în continuarea trasării de astfel de

linii care sunt din ce în ce mai departe de origine. Această procedură se

opreşte când orice mutare mai departe de origine ar cauza plasarea liniei de

izoprofit complet în afara zonei fezabile. În exemplul dat o astfel de linie trece

prin punctul H. Acest punct aduce profitul maxim, găsind astfel decizia optimă.

Când problema constă în maximizarea funcţiei obiectiv, curba de izoprofit

trebuie să fie cel mai departe de origine, iar când problema constă în

minimizarea sa, curba izocost trebuie să fie cel mai aproape de origine.

Decizia optimă în punctul H, interpolată din origine, necesită o producţie

de 630 produse de tip A şi 125 produse de tip B. Valoarea aproximativă care

se obţine în urma acestei decizii este

3600012563050 P u.m. 1.3.

O evaluare mai precisă a soluţiei se obţine prin observarea faptului că

punctul optim H se află la intersecţia a două drepte de restricţii, restricţie de

muncă de subasamblare şi cea de muncă de asamblare.

Rezolvând sistemul format cu ecuaţiile celor două drepte se obţin

valorile a = 125,15 şi b = 632,31 valoarea profitului fiind

06,3666115,1264031,63250 P 1.4.

7. Interpretarea soluţiei. Numărul optim de produse de tip A şi B este acum

cunoscut. Câte dintre cele trei resurse vor fi folosite pentru producerea

acestora? Va rămâne nefolosită vreuna din resurse? La aceste întrebări se

poate răspunde atât grafic cât şi algebric observând din grafic că punctul optim

H se află la intersecţia dreptelor ce prezintă restricţiile pentru munca de

subasamblare şi pentru cea de asamblare, el reprezentând maximul acestor

resurse disponibile pentru folosire. Prin urmare, valorile maxime ale acestor

două resurse sunt folosite în cadrul soluţiei optime. Nu există muncă de

subasamblare sau de asamblare nefolosită. Să luăm acum în considerare

munca de inspecţie. Soluţia optimă se incadrează sub linia corespunzătoare

muncii de inspecţie, ceea ce înseamnă că nu toată munca de inspecţie

disponibilă este folosită în soluţia optimă. O parte din această muncă rămâne

nefolosită. Putem calcula algebric munca nefolosită, ca fiind diferenţa dintre

munca de inspecţie disponibilă şi munca de inspecţie folosită:

ore

Bore

AoreoreMMM ifidin

76,1762,1262,3162

15,12610,031,63205,062

1.5.


20

În mod similar se poate confirma că timpul de muncă de asamblare şi

subasamblare este pe deplin utilizat.

Modelele firului de aşteptare. Teoria cozilor constă în concepte şi

modele care descriu şi măsoară modelele sosirii sarcinilor şi modelele de

servire a consumatorilor, de evaluare a eficienţei servirii clienţilor care aşteaptă

la rând să fie serviţi. O abordare a matematicienilor a constat în aplicarea

aceste serii la sarcini pe măsură ce „aşteaptă la coadă” pentru a fi prelucrate.

Punctul forte al teoriei cozilor este acela că, potenţial, ea oferă relaţii optime.

Aplicarea este însă limitată sever deoarece complexitatea matematică devine

copleşitoare când ipotezele legate de timpii de servire şi de prelucrare diferă

de câteva distribuţii binecunoscute (exponenţială, Poisson) în distribuţii

empirice sau realiste.

Modelele firului de aşteptare nu rezolvă ca atare acest tip de probleme.

Ele sunt folosite în general pentru a prezice comportamentul sistemelor de

aşteptare, în aşa fel încât comportamentul şi costurile să poată fi combinate

pentru a evalua aranjamentele alternative. Din nefericire, există câteva limite

serioase ale capacităţii modelelor matematice ale firului de aşteptare de a trata

sistemele mai complexe întâlnite în practică. Restricţiile practice majore

privesc natura distribuţiilor sosirii clienţilor în firul de aşteptare şi mărimea

sistemului (numărul unităţilor de servire), în special în sistemele de serie.

Vom descrie acum modelul de bază al teoriei aşteptării, în care se

adptă, pentru claritatea exemplului, ipoteza exponenţială privind repartiţia

timpului între două sosiri, precum şi repartiţia duratei de „servire”. Fie, deci,

repartiţia timpului inter-sosiri:

tetF 1 1.6

cu funcţia de distribuţie:

tetf 1.7

şi, în mod analog, pentru durata de servire:

t

t

et

et

1 1.8

Se poate calcula imediat probabilitatea ca nici o sosire să nu aibă loc în

intervalul vT

vT

vT

t edtevTp

0 1.9

20

În mod similar se poate confirma că timpul de muncă de asamblare şi

subasamblare este pe deplin utilizat.

Modelele firului de aşteptare. Teoria cozilor constă în concepte şi

modele care descriu şi măsoară modelele sosirii sarcinilor şi modelele de

servire a consumatorilor, de evaluare a eficienţei servirii clienţilor care aşteaptă

la rând să fie serviţi. O abordare a matematicienilor a constat în aplicarea

aceste serii la sarcini pe măsură ce „aşteaptă la coadă” pentru a fi prelucrate.

Punctul forte al teoriei cozilor este acela că, potenţial, ea oferă relaţii optime.

Aplicarea este însă limitată sever deoarece complexitatea matematică devine

copleşitoare când ipotezele legate de timpii de servire şi de prelucrare diferă

de câteva distribuţii binecunoscute (exponenţială, Poisson) în distribuţii

empirice sau realiste.

Modelele firului de aşteptare nu rezolvă ca atare acest tip de probleme.

Ele sunt folosite în general pentru a prezice comportamentul sistemelor de

aşteptare, în aşa fel încât comportamentul şi costurile să poată fi combinate

pentru a evalua aranjamentele alternative. Din nefericire, există câteva limite

serioase ale capacităţii modelelor matematice ale firului de aşteptare de a trata

sistemele mai complexe întâlnite în practică. Restricţiile practice majore

privesc natura distribuţiilor sosirii clienţilor în firul de aşteptare şi mărimea

sistemului (numărul unităţilor de servire), în special în sistemele de serie.

Vom descrie acum modelul de bază al teoriei aşteptării, în care se

adptă, pentru claritatea exemplului, ipoteza exponenţială privind repartiţia

timpului între două sosiri, precum şi repartiţia duratei de „servire”. Fie, deci,

repartiţia timpului inter-sosiri:

tetF 1 1.6

cu funcţia de distribuţie:

tetf 1.7

şi, în mod analog, pentru durata de servire:

t

t

et

et

1 1.8

Se poate calcula imediat probabilitatea ca nici o sosire să nu aibă loc în

intervalul vT

vT

vT

t edtevTp

0 1.9


21

şi probabilitatea unei sosiri în intervalul dvvv , :

dvevp v 1.10

Probabilitatea ca o sosire să aibă loc în intervalul dvvv , şi ca nici o

sosire să nu aibă loc în restul intervalului, vT , atunci când v variază de la 0

la T este:

TT

vTv TedveeTp 01 1.11

Probabilitatea a două sosiri în intervalul T se calculează ca

probabilitatea combinată a unei sosiri în intervalul [0, v] şi a altei sosiri în

intervalul vT :

tT

vTv eT

dvevTeTp 2

2

02 1.12

Continuând calculul se obţine:

t

n

n en

TTp

! 1.13

Este de notat că expresia probabilităţii de mai sus constituie legătura

dintre distribuţia exponenţială şi distribuţia Poisson. În cazul nostru, dacă

timpul dintre două sosiri consecutive este exponenţial distribuit, atunci

distribuţia numărului de evenimente într-un interval dat este de tip Poisson.

Ţinând cont de expresia de mai sus, distribuţia numărului de unităţi „servite”

într-un interval de timp este:

s

n

n en

st

!

1.14

Considerând un interval foarte mic de timp, t , putem defini după cum

urmează probabilitatea ca într-un sistem de servire să se afle n unităţi:

PttPtp nn 1 (o sosire şi nici o servire în t ) PttPn (nici o

sosire şi nici o servire în t ) PttPn (o sosire şi o servire în t )

PttPn 1 (nici o sosire şi o servire în t ).

Probabilităţile definite în relaţia de mai sus se pot calcula prin

probabilităţile elementare deja calculate:

P(o sosire şi nici o servire în t ) tte

P(nici o sosire şi nici o servire în t ) te

P(o sosire şi o servire în t ) tet 2

21

şi probabilitatea unei sosiri în intervalul dvvv , :

dvevp v 1.10

Probabilitatea ca o sosire să aibă loc în intervalul dvvv , şi ca nici o

sosire să nu aibă loc în restul intervalului, vT , atunci când v variază de la 0

la T este:

TT

vTv TedveeTp 01 1.11

Probabilitatea a două sosiri în intervalul T se calculează ca

probabilitatea combinată a unei sosiri în intervalul [0, v] şi a altei sosiri în

intervalul vT :

tT

vTv eT

dvevTeTp 2

2

02 1.12

Continuând calculul se obţine:

t

n

n en

TTp

! 1.13

Este de notat că expresia probabilităţii de mai sus constituie legătura

dintre distribuţia exponenţială şi distribuţia Poisson. În cazul nostru, dacă

timpul dintre două sosiri consecutive este exponenţial distribuit, atunci

distribuţia numărului de evenimente într-un interval dat este de tip Poisson.

Ţinând cont de expresia de mai sus, distribuţia numărului de unităţi „servite”

într-un interval de timp este:

s

n

n en

st

!

1.14

Considerând un interval foarte mic de timp, t , putem defini după cum

urmează probabilitatea ca într-un sistem de servire să se afle n unităţi:

PttPtp nn 1 (o sosire şi nici o servire în t ) PttPn (nici o

sosire şi nici o servire în t ) PttPn (o sosire şi o servire în t )

PttPn 1 (nici o sosire şi o servire în t ).

Probabilităţile definite în relaţia de mai sus se pot calcula prin

probabilităţile elementare deja calculate:

P(o sosire şi nici o servire în t ) tte

P(nici o sosire şi nici o servire în t ) te

P(o sosire şi o servire în t ) tet 2


22

P(nici o sosire şi o servire în t ) tte

Se poate ţine seama de doi factori: a) apariţia lui 2t face ca respectiva

expresie să tindă către zero; b există relaţia P(nici o sosire şi nici o servire în

t ) = 1 – P(o sosire şi nici o servire în t ) – P(nici o sosire şi o servire în t ).

Cu aceste observaţii se obţine:

tn

tn

tnn

tnn

tettPtettP

tettPttPtettPtP

1

1 1.15

de unde se deduce:

t

nnnnn ettPttPttPt

ttPtP

11 1.16

care, prin trecere la limită când 0t , devine:

tPtPtPtP nnnn 11'

1.17

În cazul staţionar, pentru care t , rezultă anularea membrului stâng

al ecuaţiei de mai sus, deci:

tPtPtP nnn 11

1.18

de unde se va deduce prin recurenţă:

NntP

tP

N

n

n

N

,,2,1,

1

1

1

1

1

10

1.19

Dacă nu există restricţii asupra numărului maxim de unităţi în aşteptare, pentru

N , se obţine:

1

n

n tP 1.20

care are sens numai dacă , respectiv atunci când ritmul mediu al sosirilor

este mai mic sau egal decât ritmul mediu al servirii.

În mod analog cu probabilitatea ca n unităţi să se afle în sistem (în

aşteptare sau în curs de servire), se poate calcula probabilitatea ca m unităţi

să se afle în aşteptare, în timp ce n – m unităţi se află în curs de servire:

22

P(nici o sosire şi o servire în t ) tte

Se poate ţine seama de doi factori: a) apariţia lui 2t face ca respectiva

expresie să tindă către zero; b există relaţia P(nici o sosire şi nici o servire în

t ) = 1 – P(o sosire şi nici o servire în t ) – P(nici o sosire şi o servire în t ).

Cu aceste observaţii se obţine:

tn

tn

tnn

tnn

tettPtettP

tettPttPtettPtP

1

1 1.15

de unde se deduce:

t

nnnnn ettPttPttPt

ttPtP

11 1.16

care, prin trecere la limită când 0t , devine:

tPtPtPtP nnnn 11'

1.17

În cazul staţionar, pentru care t , rezultă anularea membrului stâng

al ecuaţiei de mai sus, deci:

tPtPtP nnn 11

1.18

de unde se va deduce prin recurenţă:

NntP

tP

N

n

n

N

,,2,1,

1

1

1

1

1

10

1.19

Dacă nu există restricţii asupra numărului maxim de unităţi în aşteptare, pentru

N , se obţine:

1

n

n tP 1.20

care are sens numai dacă , respectiv atunci când ritmul mediu al sosirilor

este mai mic sau egal decât ritmul mediu al servirii.

În mod analog cu probabilitatea ca n unităţi să se afle în sistem (în

aşteptare sau în curs de servire), se poate calcula probabilitatea ca m unităţi

să se afle în aşteptare, în timp ce n – m unităţi se află în curs de servire:


23

1

m

m tQ 1.21

Dacă aşa cum s-a presupus iniţial, devine evident că:

nmtQtP mn , 1.22

după cum se deduce imediat din compararea ultimelor relaţii.

Concluzia pe care o fundamentează acest model general al teoriei

aşteptărilor, constă în faptul că singura modalitate a evitării creşterii nedefinite

a numărului de unităţi în aşteptare, este ca media timpului de servire să fie mai

mică decât media intervalului între două sosiri sau, altfel spus, servirea să se

efectueze mai rapid decât sosirea.

Jocul este definit ca situaţie în care două sau mai multe persoane

(grupuri etc) numite jucători iau separat decizii – determinate de obiectivele

proprii şi de datele prezumtive asupra strategiilor celorlalţi parteneri – iar

rezultatul final este dat de ansamblul deciziilor luate. Rezultatul final se

numeşte câştig şi este determinat de o funcţie de câştig care pune în legătură

configuraţia decizională (adică ansamblul deciziilor constituit într-o anume

situaţie) finală cu un anumit nivel şi mod de distribuţie al câştigului.

Vom considera, ca trăsătură generală şi esenţială a oricărui joc crearea

unei situaţii de competiţie. Noţiunea de competiţie poate implica atât conflictul

cât şi cooperarea.

Modele euristice. Managerii ar putea dori adesea optimul în deciziile lor,

dar acesta este un concept dificil de folosit în practică. Modelele matematice

de optimizare folosesc un set rigid de ipoteze privitoare la obiectivele

decidentului, orizontul de timp considerat şi natura deciziei însăşi. Descrierea

ipotezelor celor trei categorii de modele prezentate anterior (Tabelul 1.1),

reprezintă, în acest context, mai mult decât un deziderat sau o cerinţă, un

imperativ.

Tabel 1. – Ipoteze pentru modele matematice

Model

IPOTEZE

Obiective Orizont de timp Natura deciziei

Programare

liniară

Maximizează o

singură măsură a

utilităţii

Până când valorile

parametrului se

schimbă

Restricţii şi funcţii

obiectiv liniare

Fire de

aşteptare

Prevede

caracteristici de

utilitate


parametrului se

schimbă

Timpii de servire şi

sosire distribuiţi

exponenţial.

23

1

m

m tQ 1.21

Dacă aşa cum s-a presupus iniţial, devine evident că:

nmtQtP mn , 1.22

după cum se deduce imediat din compararea ultimelor relaţii.

Concluzia pe care o fundamentează acest model general al teoriei

aşteptărilor, constă în faptul că singura modalitate a evitării creşterii nedefinite

a numărului de unităţi în aşteptare, este ca media timpului de servire să fie mai

mică decât media intervalului între două sosiri sau, altfel spus, servirea să se

efectueze mai rapid decât sosirea.

Jocul este definit ca situaţie în care două sau mai multe persoane

(grupuri etc) numite jucători iau separat decizii – determinate de obiectivele

proprii şi de datele prezumtive asupra strategiilor celorlalţi parteneri – iar

rezultatul final este dat de ansamblul deciziilor luate. Rezultatul final se

numeşte câştig şi este determinat de o funcţie de câştig care pune în legătură

configuraţia decizională (adică ansamblul deciziilor constituit într-o anume

situaţie) finală cu un anumit nivel şi mod de distribuţie al câştigului.

Vom considera, ca trăsătură generală şi esenţială a oricărui joc crearea

unei situaţii de competiţie. Noţiunea de competiţie poate implica atât conflictul

cât şi cooperarea.

Modele euristice. Managerii ar putea dori adesea optimul în deciziile lor,

dar acesta este un concept dificil de folosit în practică. Modelele matematice

de optimizare folosesc un set rigid de ipoteze privitoare la obiectivele

decidentului, orizontul de timp considerat şi natura deciziei însăşi. Descrierea

ipotezelor celor trei categorii de modele prezentate anterior (Tabelul 1.1),

reprezintă, în acest context, mai mult decât un deziderat sau o cerinţă, un

imperativ.

Tabel 1. – Ipoteze pentru modele matematice

Model

IPOTEZE

Obiective Orizont de timp Natura deciziei

Programare

liniară

Maximizează o

singură măsură a

utilităţii


parametrului se

schimbă

Restricţii şi funcţii

obiectiv liniare

Fire de

aşteptare

Prevede

caracteristici de

utilitate


parametrului se

schimbă

Timpii de servire şi

sosire distribuiţi

exponenţial.


24

Condiţii de operare

staţionare

Teoria

jocului

Maximizează o

singură măsură a

utilităţii


parametrului se

schimbă

Stategii bine

definite.

Decizii simultane.

Adversar raţional

Modelele euristice nu încearcă să optimizeze, ci să deriveze soluţii

suboptimale. Modul de abordare euristică adoptă „scurtături” în raţionament şi

foloseşte metode empirice în căutarea unei soluţii satisfăcătoare. Asemănarea

cu comportamentul uman este chiar mai apropiată atunci când euristica este

adaptabilă: altfel spus „învaţă” adaptând unii parametri de decizie pe măsură

ce progresează. Există două modele în care modelele euristice s-au dovedit

folositoare în mod deosebit: acolo unde decizia este prost structurată şi nu se

potriveşte ipotezelor unui model matematic standard; acolo unde gama

soluţiilor realizabile este atât de mare, încât chiar metodele de calcul modern

nu permit enumerarea completă.

S-a sugerat că un manager ar trebui să examineze rezultatul unui

model euristic având în minte patru întrebări:

- Produce rezultate mai bune decât metodele existente?;

- Se pot realiza economii tot mai mari de resurse?;

- Se reduc cheltuielile şi efortul de calcul fără să se sacrifice calitatea

muncii?;

- Este produsă informaţia în timp util şi sunt luate mai repede deciziile

decât prin folosirea metodelor actuale?

Nivelul modelului euristic nu este un nivel inferior al fundamentării

deciziei, ci un nivel specific unor anumite contexte decizionale. Cu aceste

precizări, rămâne de făcut distincţia dintre „model procedural” şi „model

euristic”.

Modelul procedural reflectă, sub variate forme, rezultatul unor procese

de învăţare de tip „încercare şi eroare” care, în timp, se constituie sub forma

unor rutine decizionale. „În situaţia Xi şi în prezenţa tendinţei de evoluţie Yj se

adoptă decizia Zk” reprezintă un exemplu în acest sens. Foarte puţini dintre

posesorii de barometre sunt în posesia unei explicaţii complete asupra legăturii

dintre presiunea atmosferică, temperatură, regim de precipitaţii etc. Cu toate

acestea, oricare dintre ei va raţiona în modul următor: „Suntem în timpul verii,

presiunea atmosferică este ridicată, dar cu tendinţa de scădere rapidă. Este de

aşteptat în acest scurt timp o vreme mai rece cu ploi şi vânt puternic. Deci este

necesar: („să-mi iau haina de ploaie”, „să închid ferestrele pentru a nu fi trântite

24

Condiţii de operare

staţionare

Teoria

jocului

Maximizează o

singură măsură a

utilităţii


parametrului se

schimbă

Stategii bine

definite.

Decizii simultane.

Adversar raţional

Modelele euristice nu încearcă să optimizeze, ci să deriveze soluţii

suboptimale. Modul de abordare euristică adoptă „scurtături” în raţionament şi

foloseşte metode empirice în căutarea unei soluţii satisfăcătoare. Asemănarea

cu comportamentul uman este chiar mai apropiată atunci când euristica este

adaptabilă: altfel spus „învaţă” adaptând unii parametri de decizie pe măsură

ce progresează. Există două modele în care modelele euristice s-au dovedit

folositoare în mod deosebit: acolo unde decizia este prost structurată şi nu se

potriveşte ipotezelor unui model matematic standard; acolo unde gama

soluţiilor realizabile este atât de mare, încât chiar metodele de calcul modern

nu permit enumerarea completă.

S-a sugerat că un manager ar trebui să examineze rezultatul unui

model euristic având în minte patru întrebări:

- Produce rezultate mai bune decât metodele existente?;

- Se pot realiza economii tot mai mari de resurse?;

- Se reduc cheltuielile şi efortul de calcul fără să se sacrifice calitatea

muncii?;

- Este produsă informaţia în timp util şi sunt luate mai repede deciziile

decât prin folosirea metodelor actuale?

Nivelul modelului euristic nu este un nivel inferior al fundamentării

deciziei, ci un nivel specific unor anumite contexte decizionale. Cu aceste

precizări, rămâne de făcut distincţia dintre „model procedural” şi „model

euristic”.

Modelul procedural reflectă, sub variate forme, rezultatul unor procese

de învăţare de tip „încercare şi eroare” care, în timp, se constituie sub forma

unor rutine decizionale. „În situaţia Xi şi în prezenţa tendinţei de evoluţie Yj se

adoptă decizia Zk” reprezintă un exemplu în acest sens. Foarte puţini dintre

posesorii de barometre sunt în posesia unei explicaţii complete asupra legăturii

dintre presiunea atmosferică, temperatură, regim de precipitaţii etc. Cu toate

acestea, oricare dintre ei va raţiona în modul următor: „Suntem în timpul verii,

presiunea atmosferică este ridicată, dar cu tendinţa de scădere rapidă. Este de

aşteptat în acest scurt timp o vreme mai rece cu ploi şi vânt puternic. Deci este

necesar: („să-mi iau haina de ploaie”, „să închid ferestrele pentru a nu fi trântite


25

de vânt”, „să protejez florile mai sensibile din grădină”, „să amân picnicul

proiectat pentru mâine” etc.)”. Algoritmi de conducere şi decizie bazaţi pe astfel

de modele formează obiectul unor contribuţii recente.

Un alt exemplu: în general, nici un conducător auto nu poate cunoaşte

cu maximă precizie întreaga configuraţie geometrică (curbe, intersecţii, pante,

porţiuni în linie dreaptă, indicatoare de circulaţie) şi fizică (drum uscat sau

umed, pavat sau asfaltat etc) a itinerarului de parcurs. Este evident însă că

experienţa dobândită în alte împrejurări are un cuvânt hotărâtor şi nu poate

înlocui simpla cunoaştere şi aplicare a regulilor generale de circulaţie, în ceea

ce priveşte păstrarea unui regim de mers economic, rapid, şi cât mai scutit de

evenimente (accidente).

Modelul euristic este tot rezultatul unor procese de învăţare al intuiţiei şi

experienţei, dar se constituie nu ca o expresie a rutinei decidentului ci,

îndeosebi, ca măsură a abilităţii acestuia de a-şi utiliza capacitatea de analiză,

volumul experienţei acumulate şi acuitatea intuiţiei în situaţii (câmpuri

decizionale) cu pronunţate elemente de varietate. Procesul prin care

matematicianul, pus în faţa unei probleme noi, reuşeşte s-o descompună sau

să o reducă la o problemă anterior rezolvată (fireşte, când acest lucru este

posibil), este edificator ca exemplu în acest sens. Conducătorul de

întreprindere care reuşeşte să se adapteze la viteza schimbărilor tehnologice,

la fluctuaţiile pieţei de aprovizionare şi de desfacere sau la strategia

competiţională a partenerilor (sau concurenţilor) de tranzacţii, constituie un alt

exemplu major.

Modelele procedurale şi euristice sunt legate într-o măsură importantă

de persoana decidentului, întrucât sunt bazate majoriter pe calităţile personale

ale acestuia. Transferul lor în alt context se face cu pierderi importante de

informaţie deoarece, dacă experienţa se poate comunica integral în timp,

intuiţia şi inspiraţia sunt mult mai dificil de comunicat. Aceste circumstanţe au

generat tendinţa naturală de diseminare a competenţei decizionale prin

obiectivizarea, „algoritmizarea” modelelor decizionale dovedite ca fiind

performanţe. Calea principală a constituit-o adâncirea surselor de informaţie şi

perfecţionarea metodelor de a culege informaţii. Astfel, s-a trecut de la

culegerea neorganizată a informaţiilor de la „suprafaţa” sistemului, la

elaborarea şi organizarea de sisteme informaţionale (şi ulterior, informatice) cu

identitate proprie în cadrul sistemelor de producţie şi economico-sociale. În

urma acestui fapt, câştigul de precizie şi completitudine a informaţiilor a permis

organizarea acestora sub forma unor modele matematice, deci un mod cu

eficienţă sporită de a fundamenta deciziile.

25

de vânt”, „să protejez florile mai sensibile din grădină”, „să amân picnicul

proiectat pentru mâine” etc.)”. Algoritmi de conducere şi decizie bazaţi pe astfel

de modele formează obiectul unor contribuţii recente.

Un alt exemplu: în general, nici un conducător auto nu poate cunoaşte

cu maximă precizie întreaga configuraţie geometrică (curbe, intersecţii, pante,

porţiuni în linie dreaptă, indicatoare de circulaţie) şi fizică (drum uscat sau

umed, pavat sau asfaltat etc) a itinerarului de parcurs. Este evident însă că

experienţa dobândită în alte împrejurări are un cuvânt hotărâtor şi nu poate

înlocui simpla cunoaştere şi aplicare a regulilor generale de circulaţie, în ceea

ce priveşte păstrarea unui regim de mers economic, rapid, şi cât mai scutit de

evenimente (accidente).

Modelul euristic este tot rezultatul unor procese de învăţare al intuiţiei şi

experienţei, dar se constituie nu ca o expresie a rutinei decidentului ci,

îndeosebi, ca măsură a abilităţii acestuia de a-şi utiliza capacitatea de analiză,

volumul experienţei acumulate şi acuitatea intuiţiei în situaţii (câmpuri

decizionale) cu pronunţate elemente de varietate. Procesul prin care

matematicianul, pus în faţa unei probleme noi, reuşeşte s-o descompună sau

să o reducă la o problemă anterior rezolvată (fireşte, când acest lucru este

posibil), este edificator ca exemplu în acest sens. Conducătorul de

întreprindere care reuşeşte să se adapteze la viteza schimbărilor tehnologice,

la fluctuaţiile pieţei de aprovizionare şi de desfacere sau la strategia

competiţională a partenerilor (sau concurenţilor) de tranzacţii, constituie un alt

exemplu major.

Modelele procedurale şi euristice sunt legate într-o măsură importantă

de persoana decidentului, întrucât sunt bazate majoriter pe calităţile personale

ale acestuia. Transferul lor în alt context se face cu pierderi importante de

informaţie deoarece, dacă experienţa se poate comunica integral în timp,

intuiţia şi inspiraţia sunt mult mai dificil de comunicat. Aceste circumstanţe au

generat tendinţa naturală de diseminare a competenţei decizionale prin

obiectivizarea, „algoritmizarea” modelelor decizionale dovedite ca fiind

performanţe. Calea principală a constituit-o adâncirea surselor de informaţie şi

perfecţionarea metodelor de a culege informaţii. Astfel, s-a trecut de la

culegerea neorganizată a informaţiilor de la „suprafaţa” sistemului, la

elaborarea şi organizarea de sisteme informaţionale (şi ulterior, informatice) cu

identitate proprie în cadrul sistemelor de producţie şi economico-sociale. În

urma acestui fapt, câştigul de precizie şi completitudine a informaţiilor a permis

organizarea acestora sub forma unor modele matematice, deci un mod cu

eficienţă sporită de a fundamenta deciziile.


26

Procedeul analizei euristice constituie un cadru conceptual şi analitic de

măsurare a aspectelor necuantificabile. Într-o arborescenţă, de exemplu, pot fi

integrate cu uşurinţă informaţii obiective şi subiective. De aceea, acest tip de

modele este utilizat într-un număr important de situaţii decizionale privind

producţia, gândirea strategică, aspecte de marketing, finanţe, probleme de

personal.

Modele de simulare. Într-un fel, toate modelele reprezintă o „simulare”,

în măsura în care imită realitatea. Esenţa modelelor de simulare este aceea că

se bazează pe o formulare a procedurii care subliniază relaţiile logice între

variabile. De fapt, ceea ce sunt numite în general modele de simulare, ar trebui

să fie numite mai corect modele procedurale, deoarece modelul este o

procedură exprimată în simboluri precise. Termenul „simulare” se referă de

fapt la metoda prin care modelul este folosit pentru a face predicţii. Un model

de simulare ia de obicei forma unei diagrame de flux logice, care descrie

corelaţiile între variabile. Modelul este apoi utilizat pentru a executa procedura

descrisă în diagrama de flux, şi astfel, comportamentul oricărui sistem modelat

este simulat.

De exemplu, aceste modele pot fi utilizate în evaluarea unor reguli de

ordonare din unităţile de producţie. În această situaţie modelatorul trebuie să

poată specifica mai multe date pentru a putea simula problema de ordonare:

Centre de muncă (număr de centre de muncă din producţie);

Sosirea sarcinilor (modelul şi succesiunea sarcinilor care „sosesc” în

unitate);

Clasificarea posturilor (cerinţele de prelucrare şi traseul sarcinilor);

Durata de procesare (durata necesară procesării sarcinilor);

Parametri de performanţă (procentul timpilor morţi, numărul de

sarcini în aşteptare, valoarea stocurilor, fluxul mediu al posturilor

etc);

Regula de ordonare. Simularea este realizată în timp. Ea are loc

printr-un număr foarte mare de sarcini, generând altele noi care

sosesc în diverse momente, le determină traseul, le transferă la alte

centre de muncă, le ordonează în funcţie de regula de ordonare şi le

determină timpii de prelucrare.

26

Procedeul analizei euristice constituie un cadru conceptual şi analitic de

măsurare a aspectelor necuantificabile. Într-o arborescenţă, de exemplu, pot fi

integrate cu uşurinţă informaţii obiective şi subiective. De aceea, acest tip de

modele este utilizat într-un număr important de situaţii decizionale privind

producţia, gândirea strategică, aspecte de marketing, finanţe, probleme de

personal.

Modele de simulare. Într-un fel, toate modelele reprezintă o „simulare”,

în măsura în care imită realitatea. Esenţa modelelor de simulare este aceea că

se bazează pe o formulare a procedurii care subliniază relaţiile logice între

variabile. De fapt, ceea ce sunt numite în general modele de simulare, ar trebui

să fie numite mai corect modele procedurale, deoarece modelul este o

procedură exprimată în simboluri precise. Termenul „simulare” se referă de

fapt la metoda prin care modelul este folosit pentru a face predicţii. Un model

de simulare ia de obicei forma unei diagrame de flux logice, care descrie

corelaţiile între variabile. Modelul este apoi utilizat pentru a executa procedura

descrisă în diagrama de flux, şi astfel, comportamentul oricărui sistem modelat

este simulat.

De exemplu, aceste modele pot fi utilizate în evaluarea unor reguli de

ordonare din unităţile de producţie. În această situaţie modelatorul trebuie să

poată specifica mai multe date pentru a putea simula problema de ordonare:

Centre de muncă (număr de centre de muncă din producţie);

Sosirea sarcinilor (modelul şi succesiunea sarcinilor care „sosesc” în

unitate);

Clasificarea posturilor (cerinţele de prelucrare şi traseul sarcinilor);

Durata de procesare (durata necesară procesării sarcinilor);

Parametri de performanţă (procentul timpilor morţi, numărul de

sarcini în aşteptare, valoarea stocurilor, fluxul mediu al posturilor

etc);

Regula de ordonare. Simularea este realizată în timp. Ea are loc

printr-un număr foarte mare de sarcini, generând altele noi care

sosesc în diverse momente, le determină traseul, le transferă la alte

centre de muncă, le ordonează în funcţie de regula de ordonare şi le

determină timpii de prelucrare.


27

După ce toate datele au fost prelucrate, simularea evaluează

performanţele conform parametrilor specificaţi. Modelatorul poate acum să

efectueze o nouă simulare, plecând de la o altă regulă de ordonare pentru ca

în final, să se compare rezultatele simulărilor în funcţie de randamentul

preconizat.

Modelele de simulare sunt folositoare, în special, în predicţia

comportamentului dinamic al sistemului, în modelarea sistemelor în care o

parte a variabilele de intrare necontrolabile sunt descrise în termeni

probabilistici.

Complicate sau simple, aceste modele au câteva trăsături comune. În

primul rând, trebuie specificat orizontul planificării. În al doilea rând, trebuie

identificate explicit variabilele de decizie, care sunt, de obicei, factori ce pot fi

modificaţi pentru a genera planuri alternative: mărimea resurselor de muncă,

rata producţiei, timpul suplimentar, nivelul stocurilor etc. În sfârşit, în al treilea

rând, modelele necesită ca decidentul să estimeze costurile relevante, inclusiv

costurile salariilor, angajării/concedierii, timpul suplimentar ş.a.m.d.

În sinteză, după tipul problemei, pot fi identificate următoarele clase de

modele (bine susţinute şi de transpuneri profesionale în sisteme informatice):

Modele pentru aplicaţii financiar-contabile cum sunt: calculul punctului

de frângere, planificarea bugetului, analiza indicatorilor financiari;

Modele de analiză a deciziilor pentru recomandarea celei mai bune

alternative: arborii de decizie, analiza deciziilor multiatribut;

Modele de prognoză pentru a prezice valorile viitoare ale unei

variabile, analizând datele acumulate. Ele sunt bazate fie pe analiza

seriilor de timp (extrapolarea naivă, media alunecătoare, netezirea

exponenţială), fie pe determinarea relaţiilor cauzale (metode de

regresie);

Modele de tip reţea şi de optimizare, utilizate la rezolvarea unei

multitudini de probleme de planificare, alocare, distribuire, transport,

amplasament optimal;

Modele de simulare, care servesc în primul rând la evaluarea

consecinţelor produse de alternativele examinate în vederea alegerii

celei optime sau preferate.

27

După ce toate datele au fost prelucrate, simularea evaluează

performanţele conform parametrilor specificaţi. Modelatorul poate acum să

efectueze o nouă simulare, plecând de la o altă regulă de ordonare pentru ca

în final, să se compare rezultatele simulărilor în funcţie de randamentul

preconizat.

Modelele de simulare sunt folositoare, în special, în predicţia

comportamentului dinamic al sistemului, în modelarea sistemelor în care o

parte a variabilele de intrare necontrolabile sunt descrise în termeni

probabilistici.

Complicate sau simple, aceste modele au câteva trăsături comune. În

primul rând, trebuie specificat orizontul planificării. În al doilea rând, trebuie

identificate explicit variabilele de decizie, care sunt, de obicei, factori ce pot fi

modificaţi pentru a genera planuri alternative: mărimea resurselor de muncă,

rata producţiei, timpul suplimentar, nivelul stocurilor etc. În sfârşit, în al treilea

rând, modelele necesită ca decidentul să estimeze costurile relevante, inclusiv

costurile salariilor, angajării/concedierii, timpul suplimentar ş.a.m.d.

În sinteză, după tipul problemei, pot fi identificate următoarele clase de

modele (bine susţinute şi de transpuneri profesionale în sisteme informatice):

Modele pentru aplicaţii financiar-contabile cum sunt: calculul punctului

de frângere, planificarea bugetului, analiza indicatorilor financiari;

Modele de analiză a deciziilor pentru recomandarea celei mai bune


Modele de prognoză pentru a prezice valorile viitoare ale unei

variabile, analizând datele acumulate. Ele sunt bazate fie pe analiza

seriilor de timp (extrapolarea naivă, media alunecătoare, netezirea

exponenţială), fie pe determinarea relaţiilor cauzale (metode de

regresie);

Modele de tip reţea şi de optimizare, utilizate la rezolvarea unei

multitudini de probleme de planificare, alocare, distribuire, transport,

amplasament optimal;

Modele de simulare, care servesc în primul rând la evaluarea

consecinţelor produse de alternativele examinate în vederea alegerii

celei optime sau preferate.


28

Utilizarea acestora însă, este de competenţa şi în responsabilitatea

compartimentului care se ocupă de fundamentarea deciziilor şi a strategiilor

sau politicilor dezvoltării, urmărind totodată realizarea setului de funcţiuni

principale al unui sistem informatic interactiv, ce se constituie într-un veritabil

suport pentru asistarea deciziilor, după cum urmează:

scanarea universului decidentului în vederea semnalării apariţiei unor

situaţii decizionale prin analiza datelor primare, furnizând răspunsuri

la posibile întrebări de tipul „Ce se întâmplă?”;

identificarea şi diagnosticarea cauzelor şi tipului de problemă

decizională prin furnizarea de informaţii la întrebări de tipul „De ce se

întâmplă?”;

rezolvarea problemei decizionale percepute de către decident prin

evaluarea variantelor furnizând răspunsuri la întrebări de tipul „Ce s-ar

întâmpla dacă ... ?” și/sau prin sugerarea unei soluţii prin furnizarea

de răspunsuri la întrebări de tipul „Care este soluţia cea mai

bună/suficient de bună?”;

semnalarea deciziilor umane care ar putea conduce la efecte

catastrofale furnizând răspunsuri la întrebările ipotetice ale unei terţe

părţi, cu puteri de cenzură, de tipul „Este aceasta o decizie corectă?”;

facilitarea propagării deciziei, urmărirea implementării şi evaluarea

efectelor ei (prin furnizarea de informaţii la întrebări de tipul „Unde am

ajuns?”.

1.3. Metode si tehnicii de bază pentru asistarea deciziilor

Utilizarea metodelor şi tehnicilor decizionale determină o sporire a

gradului de rigurozitate şi, implicit, de eficacitate a deciziilor adoptate,

diferenţiate însă, în funcţie de tipul situaţiilor decizionale implicate. Prin

intermediul deciziilor este influenţat comportamentul decizional şi acţional al

altor persoane şi se urmăreşte realizarea unor obiective individuale, integrate

şi obiective specifice, derivate şi fundamentale, de calitatea lor depinzând

bunul mers al activităţilor. Dar, o calitate superioară a deciziilor este asigurată

de fundamentarea lor superioară, complexă, prin prelucrarea de informaţii

relevante.

28

Utilizarea acestora însă, este de competenţa şi în responsabilitatea

compartimentului care se ocupă de fundamentarea deciziilor şi a strategiilor

sau politicilor dezvoltării, urmărind totodată realizarea setului de funcţiuni

principale al unui sistem informatic interactiv, ce se constituie într-un veritabil

suport pentru asistarea deciziilor, după cum urmează:

scanarea universului decidentului în vederea semnalării apariţiei unor

situaţii decizionale prin analiza datelor primare, furnizând răspunsuri

la posibile întrebări de tipul „Ce se întâmplă?”;

identificarea şi diagnosticarea cauzelor şi tipului de problemă

decizională prin furnizarea de informaţii la întrebări de tipul „De ce se

întâmplă?”;

rezolvarea problemei decizionale percepute de către decident prin

evaluarea variantelor furnizând răspunsuri la întrebări de tipul „Ce s-ar

întâmpla dacă ... ?” și/sau prin sugerarea unei soluţii prin furnizarea

de răspunsuri la întrebări de tipul „Care este soluţia cea mai

bună/suficient de bună?”;

semnalarea deciziilor umane care ar putea conduce la efecte

catastrofale furnizând răspunsuri la întrebările ipotetice ale unei terţe

părţi, cu puteri de cenzură, de tipul „Este aceasta o decizie corectă?”;

facilitarea propagării deciziei, urmărirea implementării şi evaluarea

efectelor ei (prin furnizarea de informaţii la întrebări de tipul „Unde am

ajuns?”.

1.3. Metode si tehnicii de bază pentru asistarea deciziilor

Utilizarea metodelor şi tehnicilor decizionale determină o sporire a

gradului de rigurozitate şi, implicit, de eficacitate a deciziilor adoptate,

diferenţiate însă, în funcţie de tipul situaţiilor decizionale implicate. Prin

intermediul deciziilor este influenţat comportamentul decizional şi acţional al

altor persoane şi se urmăreşte realizarea unor obiective individuale, integrate

şi obiective specifice, derivate şi fundamentale, de calitatea lor depinzând

bunul mers al activităţilor. Dar, o calitate superioară a deciziilor este asigurată

de fundamentarea lor superioară, complexă, prin prelucrarea de informaţii

relevante.


29

Având în vedere elementele care intervin în luarea unei decizii,

specialiştii au conceput mai multe metode şi tehnici cu suport matematic,

adaptate la specificul celor trei tipuri de situaţii decizionale: certitudine, risc,

incertitudine (Popescu, Ungureanu, Muscalu 2005):

1) După natura variabilelor implicate, respectiv starea condiţiilor obiective

ce marchează problema supusă rezolvării decizionale:

a) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de certitudine: metoda utilităţii globale, metoda Electre,

metoda Onicescu, metoda coeficientului k;

b) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de risc: tehnica arborilor decizionali, tehnica jocurilor

strategice, etc.;

c) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de incertitudine: metoda speranţei matematice, tehnica

optimistă, tehnica minimizării regretelor, tehnica optimalităţii, etc.

2) După tipologia deciziilor pot fi delimitate metode şi tehnici decizionale

pe tipuri de decizii, precum:

a) amploarea decidentului duce la decizii individuale şi de grup (pentru

optimizarea deciziilor individuale: metodele şi tehnicile enumerate mai

sus; pentru optimizarea deciziilor de grup: metoda Electre

tridimensională, algoritmul Deutch – Martin);

b) în funcţie de orizontul de timp şi implicaţiile decizionale (strategice,

tactice şi curente) instrumentul decizional cuprinde: pentru deciziile

strategice şi tactice: metoda Electre bi şi tridimensională, algoritmul

Deutch – Martin, metoda arborelui decizional, iar pentru deciziile

curente: metoda tabelului decizional.

Oricare dintre metodele şi tehnicile, prezentate în continuare, poate fi

utilizată pentru alegerea celei mai bune decizii, din mai multele posibile.

Pentru alegerea deciziei, se poate realiza un model care stabileşte

legătura dintre diferiţi factori de influenţă şi criteriul de decizie şi care să

permită şi identificarea factorilor de risc, în care scop se face apel la diferite

metode şi tehnici specifice Figura 1.8.

29

Având în vedere elementele care intervin în luarea unei decizii,

specialiştii au conceput mai multe metode şi tehnici cu suport matematic,

adaptate la specificul celor trei tipuri de situaţii decizionale: certitudine, risc,

incertitudine (Popescu, Ungureanu, Muscalu 2005):

1) După natura variabilelor implicate, respectiv starea condiţiilor obiective

ce marchează problema supusă rezolvării decizionale:

a) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de certitudine: metoda utilităţii globale, metoda Electre,

metoda Onicescu, metoda coeficientului k;

b) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de risc: tehnica arborilor decizionali, tehnica jocurilor

strategice, etc.;

c) metode şi tehnici decizionale folosite în optimizarea deciziilor în

condiţii de incertitudine: metoda speranţei matematice, tehnica

optimistă, tehnica minimizării regretelor, tehnica optimalităţii, etc.

2) După tipologia deciziilor pot fi delimitate metode şi tehnici decizionale

pe tipuri de decizii, precum:

a) amploarea decidentului duce la decizii individuale şi de grup (pentru

optimizarea deciziilor individuale: metodele şi tehnicile enumerate mai

sus; pentru optimizarea deciziilor de grup: metoda Electre

tridimensională, algoritmul Deutch – Martin);

b) în funcţie de orizontul de timp şi implicaţiile decizionale (strategice,

tactice şi curente) instrumentul decizional cuprinde: pentru deciziile

strategice şi tactice: metoda Electre bi şi tridimensională, algoritmul

Deutch – Martin, metoda arborelui decizional, iar pentru deciziile

curente: metoda tabelului decizional.

Oricare dintre metodele şi tehnicile, prezentate în continuare, poate fi

utilizată pentru alegerea celei mai bune decizii, din mai multele posibile.

Pentru alegerea deciziei, se poate realiza un model care stabileşte

legătura dintre diferiţi factori de influenţă şi criteriul de decizie şi care să

permită şi identificarea factorilor de risc, în care scop se face apel la diferite

metode şi tehnici specifice Figura 1.8.


30

Figura 1.8. - Metode şi tehnici specifice de asistare a deciziilor

Procesul decizional implică o metodologie aparte, care cuprinde un sistem

de metode de selectare, alegere şi pregătire a deciziilor. Arsenalul

metodologic la care ne referim este deosebit de bogat şi include metode de

analiză, modelare, expertiză. Cu ajutorul metodelor se reuşeşte să se

aprecieze, cu o precizie mai mică sau mai mare, valoarea şi utilitatea

diferitelor alternative. Aceste metode au în vedere:

- perfecţionarea stabilirii criteriilor de apreciere a diferitelor aspecte ale

fiecărei alternative propuse;

- stabilirea valorii ponderii factorilor implicaţi pe diferite criterii;

- oferirea de soluţii pentru rezolvarea situaţiilor conflictuale şi eliminarea

unor erori;

- efectuarea de studii de comparare;

- predeterminarea avantajelor aplicării deciziei;

- stabilirea dependenţelor economico-sociale şi determinarea gradului de

acceptare a deciziei;

Identificarea factorilor de

risc

Definirea riscurilor

Analiza şi măsurarea efectelor

Administrarea propriu-

zisă a riscurilor

Integrarea în procesul de

decizie

Factorii din mediul fizic

Factorii din mediul

economic

Factorii sociali

Factorii interni sociali

Riscuri „pure”

Riscuri speculative

Defini-rea caracte-

rului mediului

Tehnici de gestiune

preventivă şi previzională

Tehnici de conservare a riscurilor

Tehnici de transformare

INCERT CERT RISC

INSTRUMENTE DE EVALUARE

Mediu incert: Mediu cert: Mediu de risc: - speranţa matematică; - metoda utilităţii globale; - teoria jocurilor strategice; - criteriul Hurwics (optimist); - metoda Onicescu; - arbori de decizie. - criteriul Laplace; - metoda Electra. - criteriul Ward (pesimist); - criteriul Savage (al regretului); - criteriul Bayes. - criteriul Jaynes.

30

Figura 1.8. - Metode şi tehnici specifice de asistare a deciziilor

Procesul decizional implică o metodologie aparte, care cuprinde un sistem

de metode de selectare, alegere şi pregătire a deciziilor. Arsenalul

metodologic la care ne referim este deosebit de bogat şi include metode de

analiză, modelare, expertiză. Cu ajutorul metodelor se reuşeşte să se

aprecieze, cu o precizie mai mică sau mai mare, valoarea şi utilitatea

diferitelor alternative. Aceste metode au în vedere:

- perfecţionarea stabilirii criteriilor de apreciere a diferitelor aspecte ale

fiecărei alternative propuse;

- stabilirea valorii ponderii factorilor implicaţi pe diferite criterii;

- oferirea de soluţii pentru rezolvarea situaţiilor conflictuale şi eliminarea

unor erori;

- efectuarea de studii de comparare;

- predeterminarea avantajelor aplicării deciziei;

- stabilirea dependenţelor economico-sociale şi determinarea gradului de

acceptare a deciziei;

Identificarea factorilor de

risc

Definirea riscurilor

Analiza şi măsurarea efectelor

Administrarea propriu-

zisă a riscurilor

Integrarea în procesul de

decizie

Factorii din mediul fizic

Factorii din mediul

economic

Factorii sociali

Factorii interni sociali

Riscuri „pure”

Riscuri speculative

Defini-rea caracte-

rului mediului

Tehnici de gestiune

preventivă şi previzională

Tehnici de conservare a riscurilor

Tehnici de transformare

INCERT CERT RISC

INSTRUMENTE DE EVALUARE

Mediu incert: Mediu cert: Mediu de risc: - speranţa matematică; - metoda utilităţii globale; - teoria jocurilor strategice; - criteriul Hurwics (optimist); - metoda Onicescu; - arbori de decizie. - criteriul Laplace; - metoda Electra. - criteriul Ward (pesimist); - criteriul Savage (al regretului); - criteriul Bayes. - criteriul Jaynes.


31

- sporirea raţionalităţii procesului decizional managerial în ansamblu sau a

diferitelor faze componente.

Utilizarea acestor metode si tehnici decizionale determiă o sporire a

gradului de rigurozitate şi implicit de eficacitate a deciziilor adoptate,

diferenţiate în raport de tipologia situatiilor decizionale implicate.

Metodele şi tehnicile decizionale se pot grupa, în funcţie de tipul

situaţiilor decizionale implicate, în trei categorii:

- metode şi tehnici de optimizare a deciziilor în conditţi de certitudine:

Electre, metoda utilităţii globale, metoda aditivă, algoritmul lui Deutch-

Martin, tabelul decizional, simulerea decizională;

- metode şi tehnici de optimizare a deciziilor în condiţii de incertitudine:

tehnica optimistă, tehnica pesimistă (A.Wald), tehnica optimalitatii

(C.Hurwicz), tehnica proporţionalităţii (Bayes-Laplace), tehnica

minimizării regretelor (L.Savage);

- metode si tehnici de optimizare a deciziilor în condiţii de risc: arborele

decizional, metoda speranţei matematice.

31

- sporirea raţionalităţii procesului decizional managerial în ansamblu sau a

diferitelor faze componente.

Utilizarea acestor metode si tehnici decizionale determiă o sporire a

gradului de rigurozitate şi implicit de eficacitate a deciziilor adoptate,

diferenţiate în raport de tipologia situatiilor decizionale implicate.

Metodele şi tehnicile decizionale se pot grupa, în funcţie de tipul

situaţiilor decizionale implicate, în trei categorii:

- metode şi tehnici de optimizare a deciziilor în conditţi de certitudine:

Electre, metoda utilităţii globale, metoda aditivă, algoritmul lui Deutch-

Martin, tabelul decizional, simulerea decizională;

- metode şi tehnici de optimizare a deciziilor în condiţii de incertitudine:

tehnica optimistă, tehnica pesimistă (A.Wald), tehnica optimalitatii

(C.Hurwicz), tehnica proporţionalităţii (Bayes-Laplace), tehnica

minimizării regretelor (L.Savage);

- metode si tehnici de optimizare a deciziilor în condiţii de risc: arborele

decizional, metoda speranţei matematice.


32

CAPITOLUL II

TEHNOLOGII INFORMAŢIONALE DESTINATE ASISTĂRII

DECIZIILOR

Revoluţia informatică a schimbat relaţia managementului cu informaţia.

Astăzi informaţia are statut de resursă intangibilă fiind considerată unul dintre

noi factorii de producție, alături de clasicii factorii de producție: muncă, pământ

și capital. Astfel, tehnologiile informaţionale sunt cele care creează, stochează

şi furnizează accesul la această resursă. Mai mult decât atât, în condiţiile

dezvoltării societăţii cunoaşterii şi a organizaţiilor bazate pe cunoaştere, a

sporit şi complexitatea problemelor manageriale, iar deciziile managerului au

început să fie puse în aplicare utilizând soluţii ce au la bază tehnologii

informaţionale din ce în ce mai avansate.

Necesitatea utilizării tehnologiilor informaţionale în asistarea deciziilor de

management este impusă de utilizarea raţionamentului uman atât pentru a

conduce la soluţii pentru probleme decizionale complexe, cât şi pentru a

determina un plus de cunoaştere în cadrul organizaţiei, sporind calitatea

procesului managerial.

Având în vedere faptul că: „informaţia singură nu poate determina decizia

ci numai atrage atenţia asupra deciziei adecvate5”, punem şi noi în discuţie

acele tehnologii informaţionale care au ca scop principal direcţionarea

managementului asupra deciziilor adecvate, deoarece informaţia este numai

intrarea în procesul de adoptare a deciziilor, nu este şi decizia în sine.

Pentru asistarea decidenţilor în rezolvarea problemelor manageriale

sau organizaţionale se poate face apel la una sau mai multe tehnologii

informaţionale, context în care sunt posibile următoarele abordări:

utilizarea anumitor tehnologii în mod independent, pentru rezolvarea

diferitelor aspecte ale unei probleme complexe;

5 Constantinescu, D.A., Minculescu, M., Rădoi, L. (1998). Sisteme informaţionale în asigurări, Editura

Bren, Bucureşti, 1998, pag.16 şi următoarele

32

CAPITOLUL II

TEHNOLOGII INFORMAŢIONALE DESTINATE ASISTĂRII

DECIZIILOR

Revoluţia informatică a schimbat relaţia managementului cu informaţia.

Astăzi informaţia are statut de resursă intangibilă fiind considerată unul dintre

noi factorii de producție, alături de clasicii factorii de producție: muncă, pământ

și capital. Astfel, tehnologiile informaţionale sunt cele care creează, stochează

şi furnizează accesul la această resursă. Mai mult decât atât, în condiţiile

dezvoltării societăţii cunoaşterii şi a organizaţiilor bazate pe cunoaştere, a

sporit şi complexitatea problemelor manageriale, iar deciziile managerului au

început să fie puse în aplicare utilizând soluţii ce au la bază tehnologii

informaţionale din ce în ce mai avansate.

Necesitatea utilizării tehnologiilor informaţionale în asistarea deciziilor de

management este impusă de utilizarea raţionamentului uman atât pentru a

conduce la soluţii pentru probleme decizionale complexe, cât şi pentru a

determina un plus de cunoaştere în cadrul organizaţiei, sporind calitatea

procesului managerial.

Având în vedere faptul că: „informaţia singură nu poate determina decizia

ci numai atrage atenţia asupra deciziei adecvate5”, punem şi noi în discuţie

acele tehnologii informaţionale care au ca scop principal direcţionarea

managementului asupra deciziilor adecvate, deoarece informaţia este numai

intrarea în procesul de adoptare a deciziilor, nu este şi decizia în sine.

Pentru asistarea decidenţilor în rezolvarea problemelor manageriale

sau organizaţionale se poate face apel la una sau mai multe tehnologii

informaţionale, context în care sunt posibile următoarele abordări:

utilizarea anumitor tehnologii în mod independent, pentru rezolvarea

diferitelor aspecte ale unei probleme complexe;

5 Constantinescu, D.A., Minculescu, M., Rădoi, L. (1998). Sisteme informaţionale în asigurări, Editura

Bren, Bucureşti, 1998, pag.16 şi următoarele


33

utilizarea unor tehnologii care comunică între ele în sensul

transferului de date şi informaţii în scopul soluţionării unei probleme;

utilizarea mai multor tehnologii integrate într-un singur sistem (un

sistem hibrid).

Asistarea deciziilor necesită date istorice, în timp ce bazele de date

operaţionale nu menţin date istorice astfel încât datele din bazele de date

operaţionale, deşi abundente, sunt de obicei departe de a fi complete/

suficiente pentru luarea deciziilor. Asistarea deciziilor necesită consolidarea

(cum ar fi agregarea şi sumarizarea) datelor din surse eterogene, rezultând

date de înaltă calitate, curăţate şi integrate. În contrast, bazele de date

operaţionale conţin doar date primare brute, cum ar fi tranzacţiile, care

trebuiesc consolidate înainte de analiză. Astfel, sistemele de asistare a deciziei

orientate pe date pot îngloba tehnologii de modelare pentru efectuarea de

estimări, previziuni, simulări asupra datelor analizate şi tehnologii inteligente

pentru rezolvarea problemelor puse în termeni calitativi. Principalul obiectiv al

acestor sisteme de asistare a deciziei manageriale îl constituie obţinerea unor

soluţii pertinente pentru problemele pe care le abordează, şi nu utilizarea unei

anumite tehnologii informaţionale. Acestea pot conlucra între ele în diferite

moduri în scopul atingerii unei performanţe cât mai ridicate.

Noul peisaj al sistemelor informaţionale moderne utilizate în procesul

de management, a fost transformat radical de tehnologiile informaţionale.

Cuvintele – cheie sunt astăzi: Datawarehouse, On-line Analytical Processing

(OLAP), Data mining, Tehnologia orientată obiect, Reţele de calculatoare,

Internet, World Wide Web, etc.

2.1. Tehnologia Datawarehouse – centralizare, consolidare,

reorganizare şi stocare volume mari de date

Tehnologia Datawarehouse a apărut ca o necesitate în momentul în

care s-a realizat imensul potenţial informaţional al datelor cumulate de-a lungul

timpului de către sistemele informatice. Exploatarea inteligentă a acestora

asigură un important avantaj prin mărirea capacităţii de acomodare la

tendinţele pieţei. Integrarea datelor istorice într-o structură unică care să se

constituie în fundament pentru procesul deciziilor, a devenit o prioritate a

acestui tip de tehnologie informaţională.

33

utilizarea unor tehnologii care comunică între ele în sensul

transferului de date şi informaţii în scopul soluţionării unei probleme;

utilizarea mai multor tehnologii integrate într-un singur sistem (un

sistem hibrid).

Asistarea deciziilor necesită date istorice, în timp ce bazele de date

operaţionale nu menţin date istorice astfel încât datele din bazele de date

operaţionale, deşi abundente, sunt de obicei departe de a fi complete/

suficiente pentru luarea deciziilor. Asistarea deciziilor necesită consolidarea

(cum ar fi agregarea şi sumarizarea) datelor din surse eterogene, rezultând

date de înaltă calitate, curăţate şi integrate. În contrast, bazele de date

operaţionale conţin doar date primare brute, cum ar fi tranzacţiile, care

trebuiesc consolidate înainte de analiză. Astfel, sistemele de asistare a deciziei

orientate pe date pot îngloba tehnologii de modelare pentru efectuarea de

estimări, previziuni, simulări asupra datelor analizate şi tehnologii inteligente

pentru rezolvarea problemelor puse în termeni calitativi. Principalul obiectiv al

acestor sisteme de asistare a deciziei manageriale îl constituie obţinerea unor

soluţii pertinente pentru problemele pe care le abordează, şi nu utilizarea unei

anumite tehnologii informaţionale. Acestea pot conlucra între ele în diferite

moduri în scopul atingerii unei performanţe cât mai ridicate.

Noul peisaj al sistemelor informaţionale moderne utilizate în procesul

de management, a fost transformat radical de tehnologiile informaţionale.

Cuvintele – cheie sunt astăzi: Datawarehouse, On-line Analytical Processing

(OLAP), Data mining, Tehnologia orientată obiect, Reţele de calculatoare,

Internet, World Wide Web, etc.

2.1. Tehnologia Datawarehouse – centralizare, consolidare,

reorganizare şi stocare volume mari de date

Tehnologia Datawarehouse a apărut ca o necesitate în momentul în

care s-a realizat imensul potenţial informaţional al datelor cumulate de-a lungul

timpului de către sistemele informatice. Exploatarea inteligentă a acestora

asigură un important avantaj prin mărirea capacităţii de acomodare la

tendinţele pieţei. Integrarea datelor istorice într-o structură unică care să se

constituie în fundament pentru procesul deciziilor, a devenit o prioritate a

acestui tip de tehnologie informaţională.


34

Tehnologia depozitelor de date se bazează pe sinteza şi analiza datelor

realizând acest deziderat prin comasarea, consolidarea, sistematizarea,

corelarea şi gruparea datelor existente în vederea obţinerii de informaţii

pertinente care să evidenţieze factorii care afectează performanţele

managementului şi ce anume ar putea fi făcut pentru ameliorarea lor.

Rapoartele ce prezintă aceste informaţii într-o formă accesibilă factorilor de

decizie sunt rezultatul unor tehnici speciale de exploatare a masivelor de date

capabile să descopere diverse corelaţii între date, să facă estimări şi prognoze,

să atragă atenţia asupra unor puncte nevralgice, să sugereze eventualele

soluţii, într-un cuvânt să contribuie decisiv la luarea celor mai bune decizii într-

o situaţie dată.

Prin realizarea unui Data Warehouse se urmărește punerea în aplicare

a unui sistem de informare coerent şi pe deplin integrat, ci nu de a construi un

sistem decizional izolat; acest sistem nu se construieşte printr-un singur bloc,

ci se descompune în mai multe aplicaţii integrate. Ceea ce diferenţiază tipurile

de depozite de date este aria de cuprindere a proceselor decizionale6:

depozit de date galactic (Galactic Data Warehouse - GDW), asistă

procesele decizionale manageriale care privesc oricare şi toate procesele

de business şi compartimentele organizației, precum şi organizația luată

ca un întreg;

depozit de date orientat pe un proces de business (Business Process Data

Warehouse - BPDW) asistă procesele decizionale care privesc oricare și

toate procesele de business şi legăturile lor reciproce, precum şi cu mediul

lor înconjurător;

depozit de date departamental (Department Data Warehouse - DDW)

asistă procesele decizionale care privesc oricare și toate compartimentele

şi interacţunile lor reciproce, precum şi cu mediul lor înconjurător;

magazie de date (data mart) de tip proces de business (Business Process

Data Mart - BPDM) asistă procesele decizionale centrate pe un singur

proces de business7;

magazie de date departamentală (Department Data Mart - DDM) asistă

procesele decizionale centrate pe un singur compartiment.

6 Ryan, J. Building and deploying an enterprise data warehouse , White Paper, 1999 7 Inmon, W. (1999). Data mart does not equal data warehouse, DM Direct Newsletter,

November.

34

Tehnologia depozitelor de date se bazează pe sinteza şi analiza datelor

realizând acest deziderat prin comasarea, consolidarea, sistematizarea,

corelarea şi gruparea datelor existente în vederea obţinerii de informaţii

pertinente care să evidenţieze factorii care afectează performanţele

managementului şi ce anume ar putea fi făcut pentru ameliorarea lor.

Rapoartele ce prezintă aceste informaţii într-o formă accesibilă factorilor de

decizie sunt rezultatul unor tehnici speciale de exploatare a masivelor de date

capabile să descopere diverse corelaţii între date, să facă estimări şi prognoze,

să atragă atenţia asupra unor puncte nevralgice, să sugereze eventualele

soluţii, într-un cuvânt să contribuie decisiv la luarea celor mai bune decizii într-

o situaţie dată.

Prin realizarea unui Data Warehouse se urmărește punerea în aplicare

a unui sistem de informare coerent şi pe deplin integrat, ci nu de a construi un

sistem decizional izolat; acest sistem nu se construieşte printr-un singur bloc,

ci se descompune în mai multe aplicaţii integrate. Ceea ce diferenţiază tipurile

de depozite de date este aria de cuprindere a proceselor decizionale6:

depozit de date galactic (Galactic Data Warehouse - GDW), asistă

procesele decizionale manageriale care privesc oricare şi toate procesele

de business şi compartimentele organizației, precum şi organizația luată

ca un întreg;

depozit de date orientat pe un proces de business (Business Process Data

Warehouse - BPDW) asistă procesele decizionale care privesc oricare și

toate procesele de business şi legăturile lor reciproce, precum şi cu mediul

lor înconjurător;

depozit de date departamental (Department Data Warehouse - DDW)

asistă procesele decizionale care privesc oricare și toate compartimentele

şi interacţunile lor reciproce, precum şi cu mediul lor înconjurător;

magazie de date (data mart) de tip proces de business (Business Process

Data Mart - BPDM) asistă procesele decizionale centrate pe un singur

proces de business7;

magazie de date departamentală (Department Data Mart - DDM) asistă

procesele decizionale centrate pe un singur compartiment.

6 Ryan, J. Building and deploying an enterprise data warehouse , White Paper, 1999 7 Inmon, W. (1999). Data mart does not equal data warehouse, DM Direct Newsletter,

November.


35

Source: https://oracleprophet.files.wordpress.com/2010/10/kungfu-006.jpg

Figura 2.1. - Depozit de date galactic

Un depozit de date reprezintă un tip special de bază de date, construită

prin metode specifice din datele operaţionale păstrate de o organizaţie. Rostul

unui astfel de depozit este de a furniza arhitecturi şi instrumente utile

conducerii executive prin: organizarea sistemică, înţelegerea şi utilizarea

datelor în luarea decizilor strategice.

O definiţie a depozitelor de date formulată de către Consiliul OLAP este

următoarea (OLAP95): Un depozit de date (datawarehouses) 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 .

Depozitele de date au fost definite în foarte multe moduri, astfel încât

este destul de dificil de formulat o definiţie riguroasă. Potrivit lui Inmon, W.,

liderul în construirea sistemelor data warehouse, un depozit de date este “o

colecţie de date orientate pe subiecte, integrate, istorice şi nevolatile destinată

sprijinirii procesului de luare a deciziilor manageriale8”. În schimb, Ralph

Kimball a oferit o definiție mai concisă a unui depozit de date, din perspectiva

8 http://www.1keydata.com/datawarehousing/data-warehouse-definition.html

35

Source: https://oracleprophet.files.wordpress.com/2010/10/kungfu-006.jpg

Figura 2.1. - Depozit de date galactic

Un depozit de date reprezintă un tip special de bază de date, construită

prin metode specifice din datele operaţionale păstrate de o organizaţie. Rostul

unui astfel de depozit este de a furniza arhitecturi şi instrumente utile

conducerii executive prin: organizarea sistemică, înţelegerea şi utilizarea

datelor în luarea decizilor strategice.

O definiţie a depozitelor de date formulată de către Consiliul OLAP este

următoarea (OLAP95): Un depozit de date (datawarehouses) 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 .

Depozitele de date au fost definite în foarte multe moduri, astfel încât

este destul de dificil de formulat o definiţie riguroasă. Potrivit lui Inmon, W.,

liderul în construirea sistemelor data warehouse, un depozit de date este “o

colecţie de date orientate pe subiecte, integrate, istorice şi nevolatile destinată

sprijinirii procesului de luare a deciziilor manageriale8”. În schimb, Ralph

Kimball a oferit o definiție mai concisă a unui depozit de date, din perspectiva

8 http://www.1keydata.com/datawarehousing/data-warehouse-definition.html


36

funcționalității sale pentru organizație, afirmând că: un depozit de date este o

copie a datelor de tranzacție structurate în mod special prin interogare și

analiză (Kimball 1996), urmare a faptului că acesta nu a abordat modul în care

depozitul de date este construit așa cum a făcut Inmon.

În sens larg, un depozit de date reprezintă o bază de date care este

întreţinută separat de bazele de date operaţionale ale organizaţiei. Datele din

sisteme sursă sunt extrase, curăţite, transformate şi stocate în depozite

speciale în scopul sprijinirii proceselor decizionale9. Depozitele de date

reprezintă o componentă a domeniului “Business Intelligence” - Inteligenţă

Afacerilor.

2.1.1. Exploatarea datelor din depozitele de date

Exploatarea acestor depozite de date este asigurată de motoare

speciale ce permit interogarea masivelor de date precum şi de servicii speciale

ce asigură analiza on-line a datelor. În spatele acestor performanţe stau

suporturi software care realizează transformarea datelor, corelarea şi

completarea lor precum şi crearea dicţionarelor de date care vor asigura

accesul la structurile primare (stocarea modelelor conceptuale ale bazelor de

date). Extragerea datelor se face prin tehnologii specifice astfel:

- programul furnizat de proiectanţii bazelor de date;

- programe utilitare de replicare care permit copierea elementelor unei

baze de date către una sau mai multe baze situate în mediul

eterogen;

- instrumente specifice de extragere ce au ca dezavantaj un preţ foarte

ridicat care va restricţiona utilizarea lor.

Cel mai clasic exemplu de data warehouse este cel referitor la

vânzările unui supermarket/hipermarket, preferabil având şi ceva informaţii

despre clienţii, despre fiecare vânzare în parte. Dintr-un asemenea

datawarehouse s-ar putea extrage informaţii privind sezonalitatea vânzărilor

unor anumite produse (ajutând la o aprovizionare mai eficientă), rentabilitatea

9 Airinei, D. (2002). Depozite de date, Editura Polirom, Iași, p. 172.

36

funcționalității sale pentru organizație, afirmând că: un depozit de date este o

copie a datelor de tranzacție structurate în mod special prin interogare și

analiză (Kimball 1996), urmare a faptului că acesta nu a abordat modul în care

depozitul de date este construit așa cum a făcut Inmon.

În sens larg, un depozit de date reprezintă o bază de date care este

întreţinută separat de bazele de date operaţionale ale organizaţiei. Datele din

sisteme sursă sunt extrase, curăţite, transformate şi stocate în depozite

speciale în scopul sprijinirii proceselor decizionale9. Depozitele de date

reprezintă o componentă a domeniului “Business Intelligence” - Inteligenţă

Afacerilor.

2.1.1. Exploatarea datelor din depozitele de date

Exploatarea acestor depozite de date este asigurată de motoare

speciale ce permit interogarea masivelor de date precum şi de servicii speciale

ce asigură analiza on-line a datelor. În spatele acestor performanţe stau

suporturi software care realizează transformarea datelor, corelarea şi

completarea lor precum şi crearea dicţionarelor de date care vor asigura

accesul la structurile primare (stocarea modelelor conceptuale ale bazelor de

date). Extragerea datelor se face prin tehnologii specifice astfel:

- programul furnizat de proiectanţii bazelor de date;

- programe utilitare de replicare care permit copierea elementelor unei

baze de date către una sau mai multe baze situate în mediul

eterogen;

- instrumente specifice de extragere ce au ca dezavantaj un preţ foarte

ridicat care va restricţiona utilizarea lor.

Cel mai clasic exemplu de data warehouse este cel referitor la

vânzările unui supermarket/hipermarket, preferabil având şi ceva informaţii

despre clienţii, despre fiecare vânzare în parte. Dintr-un asemenea

datawarehouse s-ar putea extrage informaţii privind sezonalitatea vânzărilor

unor anumite produse (ajutând la o aprovizionare mai eficientă), rentabilitatea

9 Airinei, D. (2002). Depozite de date, Editura Polirom, Iași, p. 172.


37

unor campanii de marketing (analizând creşterea vânzărilor unor anumite

produse într-o anumită perioadă), etc.

Pentru o mai bună înțelegere a modului în care datele pot fi exploatate

prin datawarehouse, putem lua în considerare exemplul „Supermarket-ului X”,

companie, care dispune de filiale în toată ţara, fiecare dintre filiale beneficiind

de o bază de date proprie. La nivelul consiliului de administraţie este cerută o

analiză a contractelor încheiate pe fiecare produs, de către fiecare filială, în

trimestrul al treilea al anului în curs. În cazul în care compania nu dispune de

un depozit de date, această operaţiune este dificil de realizat, întrucât datele

necesare sunt disipate în mai multe baze de date, aflate în locaţii fizice diferite,

situate la distanţe mari unele de celelalte. Dacă organizaţia dispune de un

depozit de date, arhitectura acestuia poate fi cea reprezentată în Figura 2.2 iar

procesul în sine, de exploatare a bazei de date este redat în Figura 2.3.

Depozit de date

Instrumente de analiză

Baza de date Oltenia

Baza de date Muntenia Utilizatori

Utilizatori

Baza de date Ardeal

Figura 2.2 – Arhitectura depozitului de date al

companiei

37

unor campanii de marketing (analizând creşterea vânzărilor unor anumite

produse într-o anumită perioadă), etc.

Pentru o mai bună înțelegere a modului în care datele pot fi exploatate

prin datawarehouse, putem lua în considerare exemplul „Supermarket-ului X”,

companie, care dispune de filiale în toată ţara, fiecare dintre filiale beneficiind

de o bază de date proprie. La nivelul consiliului de administraţie este cerută o

analiză a contractelor încheiate pe fiecare produs, de către fiecare filială, în

trimestrul al treilea al anului în curs. În cazul în care compania nu dispune de

un depozit de date, această operaţiune este dificil de realizat, întrucât datele

necesare sunt disipate în mai multe baze de date, aflate în locaţii fizice diferite,

situate la distanţe mari unele de celelalte. Dacă organizaţia dispune de un

depozit de date, arhitectura acestuia poate fi cea reprezentată în Figura 2.2 iar

procesul în sine, de exploatare a bazei de date este redat în Figura 2.3.

Depozit de date

Instrumente de analiză

Baza de date Oltenia

Baza de date Muntenia Utilizatori

Utilizatori

Baza de date Ardeal

Figura 2.2 – Arhitectura depozitului de date al

companiei


38

Figura 2.3. - Exploatarea datelor în depozitele de date

În scopul desfăşurării unui proces de adoptare a deciziei mult mai

eficient, datele din depozitul de date sunt organizate în jurul problemelor

principale (de exemplu: clienţi, produse, furnizori, etc.); cu alte cuvinte, datele

sunt orientate pe subiect (tematice), fapt diferit de modelul clasic, în care

datele sunt grupate pe funcţiuni. Acest mod de organizare asigură construirea

unei viziuni transversale asupra companiei, mult mai bogată în informaţii decât

viziunea clasică verticală.

Datele din depozitul de date sunt consistente (în sensul codificării

unitare a informaţiei). Datorită faptului că este obligatorie realizarea

conservării informaţiilor care au stat la baza adoptării unei decizii (rezultatul

unei cereri pentru care valorile parametrilor se păstrează constante, lansate de

mai multe ori şi la intervale mari de timp trebuie să fie întotdeauna acelaşi)

este necesar ca informaţiile stocate într-un depozit de date să nu poată fi

modificate. Se poate afirma că aceste date sunt non-volatile, „îngheţate”

(„frozen”). În consecinţă, în momentul în care o dată a fost introdusă în cadrul

unui depozit de date ea nu va mai putea fi actualizată ulterior (nici modificată,

nici suprimată), ci va deveni o parte componentă a istoricului, a evoluţiei în

timp a organizaţiei. Acest lucru este fundamental diferit faţă de concepţia

clasică a unui sistem tranzacţional, care permite reactualizarea datelor. Din

acest motiv, se consideră că într-un sistem tranzacţional datele sunt volatile,

spre deosebire de data warehouse, unde trebuie, în mod obligatoriu, să fie

non-volatile.

Datele din depozitele de date sunt stocate în scopul furnizării

informaţiilor dintr-o perspectivă istorică (de exemplu ultimii 10-15 ani) şi sunt,

38

Figura 2.3. - Exploatarea datelor în depozitele de date

În scopul desfăşurării unui proces de adoptare a deciziei mult mai

eficient, datele din depozitul de date sunt organizate în jurul problemelor

principale (de exemplu: clienţi, produse, furnizori, etc.); cu alte cuvinte, datele

sunt orientate pe subiect (tematice), fapt diferit de modelul clasic, în care

datele sunt grupate pe funcţiuni. Acest mod de organizare asigură construirea

unei viziuni transversale asupra companiei, mult mai bogată în informaţii decât

viziunea clasică verticală.

Datele din depozitul de date sunt consistente (în sensul codificării

unitare a informaţiei). Datorită faptului că este obligatorie realizarea

conservării informaţiilor care au stat la baza adoptării unei decizii (rezultatul

unei cereri pentru care valorile parametrilor se păstrează constante, lansate de

mai multe ori şi la intervale mari de timp trebuie să fie întotdeauna acelaşi)

este necesar ca informaţiile stocate într-un depozit de date să nu poată fi

modificate. Se poate afirma că aceste date sunt non-volatile, „îngheţate”

(„frozen”). În consecinţă, în momentul în care o dată a fost introdusă în cadrul

unui depozit de date ea nu va mai putea fi actualizată ulterior (nici modificată,

nici suprimată), ci va deveni o parte componentă a istoricului, a evoluţiei în

timp a organizaţiei. Acest lucru este fundamental diferit faţă de concepţia

clasică a unui sistem tranzacţional, care permite reactualizarea datelor. Din

acest motiv, se consideră că într-un sistem tranzacţional datele sunt volatile,

spre deosebire de data warehouse, unde trebuie, în mod obligatoriu, să fie

non-volatile.

Datele din depozitele de date sunt stocate în scopul furnizării

informaţiilor dintr-o perspectivă istorică (de exemplu ultimii 10-15 ani) şi sunt,


39

în general, date agregate, acest lucru derivând din necesitatea urmăririi în timp

a evoluţiei valorilor unor indicatori. Spre exemplu, în locul stocării detaliilor

pentru fiecare contract de vânzare-cumpărare, în depozitul de date se va

memora numai valoarea totală a contractelor încheiate pentru fiecare marfă,

pe fiecare filială, sau chiar pe fiecare zonă. Se poate aprecia că un depozit de

date reprezintă o bază de date multidimensională, în care fiecare dimensiune

corespunde unui atribut sau set de atribute, iar fiecare celulă memorează valori

ale unor măsuri agregate (numărul de…, valoarea totală a…, valoarea medie

a…).

În exemplul din Figura 2.4. este prezentat un cub care cumulează

valoarea contractelor de vânzare-cumpărare încheiate de către filialele

companiei pe o regiune (din motive de spaţiu au fost prezentate numai o parte

dintre valorile dimensiunilor adresa şi produse). Cubul prezintă trei dimensiuni:

timp (cu valorile corespunzătoare celor patru trimestre ale unui an: Trim I, Trim

II, Trim III, Trim IV), adresa (cu valorile: Ardeal, Banat, Dobrogea,…) şi

produse. Valorile agregate stocate în fiecare celulă a cubului reprezintă

volumul total al contractelor încheiate (exprimat în sute de mii de u.m.). Prin

operaţiuni de drill-down, respectiv roll-up, se pot realiza detalieri, respectiv

agregări ale datelor prezentate. Spre exemplu, prin operaţiunea de drill-down

asupra adresei Ardeal, se poate realiza o detaliere a valorii totale a

contractelor de leasing încheiate la nivel de judeţ de fiecare filială, iar prin

operaţiunea de roll-up asupra timpului exprimat în trimestre se pot obţine

valorile agregate la nivel de semestru ale contractelor încheiate.

Este posibil ca nu întreg setul de date existent într-un depozit de date

să fie util pentru furnizarea de informaţii necesare fundamentării deciziei, ci

numai o mică parte a acestuia. În aceste condiţii, se poate realiza un magazin

de date (Data Mart), care reprezintă un subset dintr-un data warehouse. În

literatura de specialitate se consideră că depozitul de date acoperă cerinţele

informaţionale ale întregii organizaţii, în timp ce magazinul de date se rezumă

la furnizarea informaţiilor necesare unui anumit departament din cadrul

companiei.

39

în general, date agregate, acest lucru derivând din necesitatea urmăririi în timp

a evoluţiei valorilor unor indicatori. Spre exemplu, în locul stocării detaliilor

pentru fiecare contract de vânzare-cumpărare, în depozitul de date se va

memora numai valoarea totală a contractelor încheiate pentru fiecare marfă,

pe fiecare filială, sau chiar pe fiecare zonă. Se poate aprecia că un depozit de

date reprezintă o bază de date multidimensională, în care fiecare dimensiune

corespunde unui atribut sau set de atribute, iar fiecare celulă memorează valori

ale unor măsuri agregate (numărul de…, valoarea totală a…, valoarea medie

a…).

În exemplul din Figura 2.4. este prezentat un cub care cumulează

valoarea contractelor de vânzare-cumpărare încheiate de către filialele

companiei pe o regiune (din motive de spaţiu au fost prezentate numai o parte

dintre valorile dimensiunilor adresa şi produse). Cubul prezintă trei dimensiuni:

timp (cu valorile corespunzătoare celor patru trimestre ale unui an: Trim I, Trim

II, Trim III, Trim IV), adresa (cu valorile: Ardeal, Banat, Dobrogea,…) şi

produse. Valorile agregate stocate în fiecare celulă a cubului reprezintă

volumul total al contractelor încheiate (exprimat în sute de mii de u.m.). Prin

operaţiuni de drill-down, respectiv roll-up, se pot realiza detalieri, respectiv

agregări ale datelor prezentate. Spre exemplu, prin operaţiunea de drill-down

asupra adresei Ardeal, se poate realiza o detaliere a valorii totale a

contractelor de leasing încheiate la nivel de judeţ de fiecare filială, iar prin

operaţiunea de roll-up asupra timpului exprimat în trimestre se pot obţine

valorile agregate la nivel de semestru ale contractelor încheiate.

Este posibil ca nu întreg setul de date existent într-un depozit de date

să fie util pentru furnizarea de informaţii necesare fundamentării deciziei, ci

numai o mică parte a acestuia. În aceste condiţii, se poate realiza un magazin

de date (Data Mart), care reprezintă un subset dintr-un data warehouse. În

literatura de specialitate se consideră că depozitul de date acoperă cerinţele

informaţionale ale întregii organizaţii, în timp ce magazinul de date se rezumă

la furnizarea informaţiilor necesare unui anumit departament din cadrul

companiei.


40

Figura 2.4. – Drill-down şi roll-up

În exemplificarea noastră, utilizatorul poate cu ușurință organiza

interogări pe diverse nivele, astfel încât acestea să fie ușor de accesat în

sesiuni ulterioare, într-un mediu multi-utilizator, arătând acțiunile fiecărui

utilizator pentru a organiza, reutiliza, lansa (executare de interogare și

vizualizare răspuns), căuta, răsfoi (posibilitatea de a naviga prin seturi de

interogări dar și prin interogările dint-un set) și distribui interogări. După cum se

observă, în zona de exploatare a datelor din depozitele de date (ceea ce de

fapt se numește analiză a datelor), este nevoie de organizare, reutilizare,

schimb de date, în scopul de a simplifica și grăbi procesul de interogare.

2.1.2. Modelarea conceptuală a depozitelor de date

În contextul depozitării datelor s-a constatat că modelele conceptuale

tradiţionale ale bazelor de date, cum ar fi modelul entitate-relaţie, nu sunt

adecvate pentru a descrie aspectele fundamentale ale unui demers de

depozitare a datelor. Esenţial este faptul că, în modelarea conceptuală a unui

depozit de date, este nevoie de a reprezenta în mod explicit caracteristici

importante ale informaţiilor. Există cel puţin două noţiuni specifice pe care orice

model conceptual pentru depozitarea datelor trebuie să le includă într-o

anumită formă şi anume faptul şi dimensiunea. Faptul este o entitate, a unei

40

Figura 2.4. – Drill-down şi roll-up

În exemplificarea noastră, utilizatorul poate cu ușurință organiza

interogări pe diverse nivele, astfel încât acestea să fie ușor de accesat în

sesiuni ulterioare, într-un mediu multi-utilizator, arătând acțiunile fiecărui

utilizator pentru a organiza, reutiliza, lansa (executare de interogare și

vizualizare răspuns), căuta, răsfoi (posibilitatea de a naviga prin seturi de

interogări dar și prin interogările dint-un set) și distribui interogări. După cum se

observă, în zona de exploatare a datelor din depozitele de date (ceea ce de

fapt se numește analiză a datelor), este nevoie de organizare, reutilizare,

schimb de date, în scopul de a simplifica și grăbi procesul de interogare.

2.1.2. Modelarea conceptuală a depozitelor de date

În contextul depozitării datelor s-a constatat că modelele conceptuale

tradiţionale ale bazelor de date, cum ar fi modelul entitate-relaţie, nu sunt

adecvate pentru a descrie aspectele fundamentale ale unui demers de

depozitare a datelor. Esenţial este faptul că, în modelarea conceptuală a unui

depozit de date, este nevoie de a reprezenta în mod explicit caracteristici

importante ale informaţiilor. Există cel puţin două noţiuni specifice pe care orice

model conceptual pentru depozitarea datelor trebuie să le includă într-o

anumită formă şi anume faptul şi dimensiunea. Faptul este o entitate, a unei


41

aplicaţii, care face obiectul unei analize orientată către decizie, reprezentabilă

grafic prin intermediul „cubului de date”, iar dimensiunea corespunde

perspectivei din care faptele pot fi analizate în mod concludent (Lepadatu,

2013).

Referitor la modelarea conceptuală a unui depozit de date, în literatura

de specialitate (Velicanu, Muntean 2001) sunt acceptate următoarele modele:

modelul stea;

modelul fulg de nea;

modelul constelaţie.

Elementele componente ale unui astfel de model sunt:

măsuri ale activităţii – sunt reprezentate de datele cantitative la nivel agregat

(totaluri, medii, contorizări).

dimensiuni - sunt reprezentate de criteriile de agregare, acestea conţinând în

mod obligatoriu timpul (data calendaristică) şi alte astfel de criterii (de

exemplu: codul clientului, codul produsului, codul filialei etc.). Bineînţeles că

aceste dimensiuni trebuiesc explicitate în tabele distincte, tabele care trebuie

să respecte următoarele condiţii:

să descrie datele din tabela de fapte;

fiecare cheie trebuie să fie unică;

cheile trebuie să reprezinte nivelul de detaliere cel mai reprezentativ

pentru problema dată;

numărul dimensiunilor trebuie să fie rezonabil, întrucât un număr prea

mare de dimensiuni conduce la o gestionare mai dificilă a acestora,

precum şi la un timp de răspuns ridicat din partea sistemului în urma

solicitărilor venite de la utilizatori.

tabela de fapte - reprezintă locaţia unde se află stocate măsurile activităţii

grupate pe dimensiuni.

Această tabelă de fapte trebuie să îndeplinească următoarele condiţii:

să realizeze cuantificarea datelor descrise de către dimensiuni;

să conțină valori numerice care fac obiectul analizei (cantitate vândută,

preț, profit, cost, nr. clienți, etc.);

41

aplicaţii, care face obiectul unei analize orientată către decizie, reprezentabilă

grafic prin intermediul „cubului de date”, iar dimensiunea corespunde

perspectivei din care faptele pot fi analizate în mod concludent (Lepadatu,

2013).

Referitor la modelarea conceptuală a unui depozit de date, în literatura

de specialitate (Velicanu, Muntean 2001) sunt acceptate următoarele modele:

modelul stea;

modelul fulg de nea;

modelul constelaţie.

Elementele componente ale unui astfel de model sunt:

măsuri ale activităţii – sunt reprezentate de datele cantitative la nivel agregat

(totaluri, medii, contorizări).

dimensiuni - sunt reprezentate de criteriile de agregare, acestea conţinând în

mod obligatoriu timpul (data calendaristică) şi alte astfel de criterii (de

exemplu: codul clientului, codul produsului, codul filialei etc.). Bineînţeles că

aceste dimensiuni trebuiesc explicitate în tabele distincte, tabele care trebuie

să respecte următoarele condiţii:

să descrie datele din tabela de fapte;

fiecare cheie trebuie să fie unică;

cheile trebuie să reprezinte nivelul de detaliere cel mai reprezentativ

pentru problema dată;

numărul dimensiunilor trebuie să fie rezonabil, întrucât un număr prea

mare de dimensiuni conduce la o gestionare mai dificilă a acestora,

precum şi la un timp de răspuns ridicat din partea sistemului în urma

solicitărilor venite de la utilizatori.

tabela de fapte - reprezintă locaţia unde se află stocate măsurile activităţii

grupate pe dimensiuni.

Această tabelă de fapte trebuie să îndeplinească următoarele condiţii:

să realizeze cuantificarea datelor descrise de către dimensiuni;

să conțină valori numerice care fac obiectul analizei (cantitate vândută,

preț, profit, cost, nr. clienți, etc.);


42

să conțină chei externe către tabele dimensionale; fiecare cheie trebuie

să fie o combinaţie unică a cheilor primare din tabelele de dimensiuni;

cheile trebuie să conţină întotdeauna dimensiunea timp;

are un număr redus de coloane (câmpuri) și un număr mare de linii

(înregistrări);

informația din cadrul tabelei de fapte este:

numerică astfel încât să poată fi agregată;

aditivă sau semiaditivă pentru a permite sumarizarea unui număr

mare/larg de valori;

faptele depind în mod direct de câmpurile cheie externă care

permit relaționarea cu tabelele dimensionale și sunt la același nivel

de detaliu.

Modelul de bază al reprezentării la nivel conceptual al unui depozit de

date este reprezentat de modelul stea, din acesta obţinându-se şi celelalte

două modele. În Figura 2.3 este prezentat modelul stea pentru contractele de

vânzare-cumpărare încheiate de Supermarket X, contractele fiind grupate pe

patru dimensiuni: timp, produs, client şi filială. Acest model conţine o tabelă de

fapte pentru contracte, care conţine chei corespunzătoare pentru fiecare dintre

cele patru dimensiuni, precum şi două măsuri ale activităţii: TotalValoare,

TotalCantitate.

Într-un model stea, fiecare dimensiune este reprezentată printr-o

singură tabelă, care conţine la rândul său un set de atribute. Spre exemplu

tabela Clienti conţine următoarele atribute: CodClient, NumeClient, TipClient,

LocalitateClient, JudetClient, ZonaClient. Această structură a tabelei poate

conduce la apariţia unor redundanţe: localităţile „Constanţa”, „Mangalia” şi

„Medgidia” fiind toate din judeţul „Constanţa”, regiunea „Dobrogea”,

înregistrările de tipul (…, Constanta, Constanta, Dobrogea), (…, Mangalia,

Constanta, Dobrogea), (…, Medgidia, Constanta, Dobrogea) determină

redundanţe între câmpurile JudetClient şi ZonaClient (de fapt, este vorba

despre o dependenţă funcţională tranzitivă între câmpurile LocalitateClient,

JudetClient şi, ZonaClient).

42

să conțină chei externe către tabele dimensionale; fiecare cheie trebuie

să fie o combinaţie unică a cheilor primare din tabelele de dimensiuni;

cheile trebuie să conţină întotdeauna dimensiunea timp;

are un număr redus de coloane (câmpuri) și un număr mare de linii

(înregistrări);

informația din cadrul tabelei de fapte este:

numerică astfel încât să poată fi agregată;

aditivă sau semiaditivă pentru a permite sumarizarea unui număr

mare/larg de valori;

faptele depind în mod direct de câmpurile cheie externă care

permit relaționarea cu tabelele dimensionale și sunt la același nivel

de detaliu.

Modelul de bază al reprezentării la nivel conceptual al unui depozit de

date este reprezentat de modelul stea, din acesta obţinându-se şi celelalte

două modele. În Figura 2.3 este prezentat modelul stea pentru contractele de

vânzare-cumpărare încheiate de Supermarket X, contractele fiind grupate pe

patru dimensiuni: timp, produs, client şi filială. Acest model conţine o tabelă de

fapte pentru contracte, care conţine chei corespunzătoare pentru fiecare dintre

cele patru dimensiuni, precum şi două măsuri ale activităţii: TotalValoare,

TotalCantitate.

Într-un model stea, fiecare dimensiune este reprezentată printr-o

singură tabelă, care conţine la rândul său un set de atribute. Spre exemplu

tabela Clienti conţine următoarele atribute: CodClient, NumeClient, TipClient,

LocalitateClient, JudetClient, ZonaClient. Această structură a tabelei poate

conduce la apariţia unor redundanţe: localităţile „Constanţa”, „Mangalia” şi

„Medgidia” fiind toate din judeţul „Constanţa”, regiunea „Dobrogea”,

înregistrările de tipul (…, Constanta, Constanta, Dobrogea), (…, Mangalia,

Constanta, Dobrogea), (…, Medgidia, Constanta, Dobrogea) determină

redundanţe între câmpurile JudetClient şi ZonaClient (de fapt, este vorba

despre o dependenţă funcţională tranzitivă între câmpurile LocalitateClient,

JudetClient şi, ZonaClient).


43

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

JudetFiliala

RegiuneFiliala

Dimensiunea

TIMP

Dimensiunea

CLIENT

Dimensiunea

PRODUS

Dimensiunea

FILIALA

Tabela

de fapte

Măsuri ale

activităţii

Figura 2.5 - Modelul stea al unui depozit de date

Dacă în cazul unei model de tip stea se doreşte realizarea unei

subclasificări a anumitor dimensiuni, obţinându-se astfel subdimensiuni,

modelul nou-obţinut se va numi model fulg de nea.

În Figura 2.6 este prezentat modelul fulg de nea (derivat din modelul

stea prezentat anterior) pentru contractele încheiate, acestea fiind grupate pe

cinci dimensiuni: timp, sezon, produs, client şi filială. În model se observă o

detaliere a dimensiunilor produs (cu CategoriiProduse), client (cu

CategoriiClienti), şi filială (cu judete), precum şi faptul că există două

dimensiuni alternative (timp şi sezon).

Dacă în cadrul unei model există două sau mai multe tabele de fapte

care au în comun anumite dimensiuni (partajează anumite tabele), modelul

obţinut se numeşte model constelaţie. Bineînţeles că una dintre dimensiunile

comune ale tabelelor de fapte o reprezintă timpul, în urma asocierilor tabelelor

de fapte putându-se obţine o serie de corelaţii interesante între acestea.

43

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

JudetFiliala

RegiuneFiliala

Dimensiunea

TIMP

Dimensiunea

CLIENT

Dimensiunea

PRODUS

Dimensiunea

FILIALA

Tabela

de fapte

Măsuri ale

activităţii

Figura 2.5 - Modelul stea al unui depozit de date

Dacă în cazul unei model de tip stea se doreşte realizarea unei

subclasificări a anumitor dimensiuni, obţinându-se astfel subdimensiuni,

modelul nou-obţinut se va numi model fulg de nea.

În Figura 2.6 este prezentat modelul fulg de nea (derivat din modelul

stea prezentat anterior) pentru contractele încheiate, acestea fiind grupate pe

cinci dimensiuni: timp, sezon, produs, client şi filială. În model se observă o

detaliere a dimensiunilor produs (cu CategoriiProduse), client (cu

CategoriiClienti), şi filială (cu judete), precum şi faptul că există două

dimensiuni alternative (timp şi sezon).

Dacă în cadrul unei model există două sau mai multe tabele de fapte

care au în comun anumite dimensiuni (partajează anumite tabele), modelul

obţinut se numeşte model constelaţie. Bineînţeles că una dintre dimensiunile

comune ale tabelelor de fapte o reprezintă timpul, în urma asocierilor tabelelor

de fapte putându-se obţine o serie de corelaţii interesante între acestea.


44

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CodCategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

CodJudetFiliala

CategoriiProduse

PK CodCategorieProdus

DenumireCategorieProdus

CategoriiClienti

PK CodCategorieClient

DenumireCategorieClient

Judete

PK CodJudet

Regiune

Sezon

PK CodData

ZiDinSaptamana

Sezon

Figura 2.6 - Modelul fulg de nea al unui depozit de date

În Figura 2.7. este prezentat modelul constelaţie (derivat din modelul

stea prezentat anterior) pentru contractele şi încasările companiei, atât

contractele, cât şi încasările fiind grupate pe patru dimensiuni: pentru contracte

– timp, produs, client şi filială, pentru încasări - timp, DocumentDeIncasare,

client şi filială. Se poate observa că cele două tabele de fapte au trei

dimensiuni comune, şi anume: timp, client şi filială.

44

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CodCategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

CodJudetFiliala

CategoriiProduse

PK CodCategorieProdus

DenumireCategorieProdus

CategoriiClienti

PK CodCategorieClient

DenumireCategorieClient

Judete

PK CodJudet

Regiune

Sezon

PK CodData

ZiDinSaptamana

Sezon

Figura 2.6 - Modelul fulg de nea al unui depozit de date

În Figura 2.7. este prezentat modelul constelaţie (derivat din modelul

stea prezentat anterior) pentru contractele şi încasările companiei, atât

contractele, cât şi încasările fiind grupate pe patru dimensiuni: pentru contracte

– timp, produs, client şi filială, pentru încasări - timp, DocumentDeIncasare,

client şi filială. Se poate observa că cele două tabele de fapte au trei

dimensiuni comune, şi anume: timp, client şi filială.


45

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

JudetFiliala

RegiuneFiliala

DocIncasare

PK TipDocument

DenumireDocument

Incasari

PK CodFiliala

PK CodClient

PK TipDocument

PK CodData

TotalIncasari

Figura 2.7. - Modelul constelaţie al unui depozit de date

Cele trei tipuri de modele conceptuale ale unui depozit de date pot fi

modificate pe parcursul existenţei acestuia, fără a fi periclitată existenţa sa. De

altfel, în literatura de specialitate se consideră că dezvoltarea unui data

warehouse este un proces ciclic şi repetitiv, care se desfăşoară de-a lungul

întreagii sale existenţe (după cum se poate observa şi în Figura 2.8). În etapa

de proiectare se elaborează structura depozitului de date, plecându-se de la

premisa că trebuie să se asigure o identificare exactă a informaţiilor, urmată de

un acces rapid la date.

În etapa de populare se realizează preluarea automată a datelor din

sursele disponibile, datele suferind un proces de curăţare şi transformare,

45

Clienti

PK CodClient

NumeClient

TipClient

LocalitateClient

JudetClient

RegiuneClient

Contracte

PK CodData

PK CodFiliala

PK CodClient

PK CodProdus

TotalValoare

TotalCantitate

Timp

PK CodData

Zi

Luna

Trimestru

Semestru

An

Produse

PK CodProdus

NumeProdus

CategorieProdus

Filiale

PK CodFiliala

NumeFiliala

LocalitateFiliala

JudetFiliala

RegiuneFiliala

DocIncasare

PK TipDocument

DenumireDocument

Incasari

PK CodFiliala

PK CodClient

PK TipDocument

PK CodData

TotalIncasari

Figura 2.7. - Modelul constelaţie al unui depozit de date

Cele trei tipuri de modele conceptuale ale unui depozit de date pot fi

modificate pe parcursul existenţei acestuia, fără a fi periclitată existenţa sa. De

altfel, în literatura de specialitate se consideră că dezvoltarea unui data

warehouse este un proces ciclic şi repetitiv, care se desfăşoară de-a lungul

întreagii sale existenţe (după cum se poate observa şi în Figura 2.8). În etapa

de proiectare se elaborează structura depozitului de date, plecându-se de la

premisa că trebuie să se asigure o identificare exactă a informaţiilor, urmată de

un acces rapid la date.

În etapa de populare se realizează preluarea automată a datelor din

sursele disponibile, datele suferind un proces de curăţare şi transformare,


46

urmat de integrarea lor în depozitul de date. Această operaţiune are loc

periodic, în scopul reactualizării datelor conţinute de către depozitul de date.

Etapa de exploatare se desfăşoară după ce depozitul de date este

operaţional, în urma utilizării acestuia apărând o serie de noi cerinţe

informaţionale din partea decidenţilor, cerinţe menite să vină în sprijinul

procesului de asistare a elaborării deciziei. Pentru rezolvarea noilor cerinţe, se

va realiza o reproiectare a depozitului de date, urmată de o repopularea a

acestuia şi de o nouă etapă de exploatare.

Eficiența modelării în datawarehousing depinde strict de capacitatea de

a descrie datele factuale în funcție de dimensiunile adecvate, adică în funcție

de perspectivele din care datele pot fi analizate. Pentru a putea susține mai

bine analiza datelor este util ca pentru fiecare dimensiune să se organizeze o

ierarhie de niveluri obtenabilă prin gruparea elementelor/ membrilor

dimensiunii în funcție de nevoile analizei.

2.2. Tehnologia On-Line Analytical Processing - agregarea datelor

stocate în depozite abordate multidimensional

Tehnologia On-Line Analytical Processing (OLAP) este o tehnologie de

agregare a datelor stocate în depozite, într-o abordare multidimensională care

asigură acces rapid la informaţiile necesare analiştilor financiari, într-o manieră

consistentă, interactivă şi foarte flexibilă. OLAP şi depozitele de date se

completează reciproc, OLAP transformând volumul imens de date stocate şi

gestionate în depozite, în informaţii utile procesului de decizie.

PROIECTARE

POPULARE

EXPLOATARE

Figura 2.8. – Ciclul de viaţă al unui depozit de date

46

urmat de integrarea lor în depozitul de date. Această operaţiune are loc

periodic, în scopul reactualizării datelor conţinute de către depozitul de date.

Etapa de exploatare se desfăşoară după ce depozitul de date este

operaţional, în urma utilizării acestuia apărând o serie de noi cerinţe

informaţionale din partea decidenţilor, cerinţe menite să vină în sprijinul

procesului de asistare a elaborării deciziei. Pentru rezolvarea noilor cerinţe, se

va realiza o reproiectare a depozitului de date, urmată de o repopularea a

acestuia şi de o nouă etapă de exploatare.

Eficiența modelării în datawarehousing depinde strict de capacitatea de

a descrie datele factuale în funcție de dimensiunile adecvate, adică în funcție

de perspectivele din care datele pot fi analizate. Pentru a putea susține mai

bine analiza datelor este util ca pentru fiecare dimensiune să se organizeze o

ierarhie de niveluri obtenabilă prin gruparea elementelor/ membrilor

dimensiunii în funcție de nevoile analizei.

2.2. Tehnologia On-Line Analytical Processing - agregarea datelor

stocate în depozite abordate multidimensional

Tehnologia On-Line Analytical Processing (OLAP) este o tehnologie de

agregare a datelor stocate în depozite, într-o abordare multidimensională care

asigură acces rapid la informaţiile necesare analiştilor financiari, într-o manieră

consistentă, interactivă şi foarte flexibilă. OLAP şi depozitele de date se

completează reciproc, OLAP transformând volumul imens de date stocate şi

gestionate în depozite, în informaţii utile procesului de decizie.

PROIECTARE

POPULARE

EXPLOATARE

Figura 2.8. – Ciclul de viaţă al unui depozit de date


47

Tehnicile utilizate de OLAP cuprind de la simpla navigaţie şi selecţie a

datelor până la analize complexe incluzând modele şi serii temporale.

Aplicaţiile construite cu tehnologia OLAP asigură analiza rapidă a informaţiei

multidimensionale distribuită în locaţii multiple şi accesibilă în acelaşi timp unui

număr mare de utilizatori. OLAP utilizează în acest scop baze de date

multidimensionale, prin contrast cu bazele de date relaţionale care sunt

bidimensionale prin definiţie.

O facilitate extrem de puternică oferită de OLAP este posibilitatea de a

construi scenarii şi în consecinţă, posibilitatea de a răspunde la întrebări de

tipul: „Ce ar fi dacă?” în timp ce depozitele de date pot oferi răspunsuri numai

la întrebări de tipul „Cine?”, „Ce?”, „Unde?”, „Când?”. Analiza datelor, de tip

numeric sau statistic, poate fi predefinită de creatorul aplicaţiei dar şi de

utilizatorul final în cadrul unor interogări ad-hoc. OLAP asigură suport acestei

analize prin capacitatea sa de a efectua calcule intensive.

Principalele caracteristici ale OLAP ce pot fi utilizate în asistarea

deciziei de management, se referă la:

Perspectiva (view) multidimensională asupra datelor - capacitatea de a

integra mai multe aspecte ale managementului privit din diferite perspective:

timp, locație, produs. Fiecare dimensiune poate avea mai multe nivele:

dimensiunea temporală se poate divide în luni, zile, dimensiunea produs în

contracte, furnizori, etc.

Figura nr. 2.9. - Perspectiva (view) multidimensională asupra datelor

47

Tehnicile utilizate de OLAP cuprind de la simpla navigaţie şi selecţie a

datelor până la analize complexe incluzând modele şi serii temporale.

Aplicaţiile construite cu tehnologia OLAP asigură analiza rapidă a informaţiei

multidimensionale distribuită în locaţii multiple şi accesibilă în acelaşi timp unui

număr mare de utilizatori. OLAP utilizează în acest scop baze de date

multidimensionale, prin contrast cu bazele de date relaţionale care sunt

bidimensionale prin definiţie.

O facilitate extrem de puternică oferită de OLAP este posibilitatea de a

construi scenarii şi în consecinţă, posibilitatea de a răspunde la întrebări de

tipul: „Ce ar fi dacă?” în timp ce depozitele de date pot oferi răspunsuri numai

la întrebări de tipul „Cine?”, „Ce?”, „Unde?”, „Când?”. Analiza datelor, de tip

numeric sau statistic, poate fi predefinită de creatorul aplicaţiei dar şi de

utilizatorul final în cadrul unor interogări ad-hoc. OLAP asigură suport acestei

analize prin capacitatea sa de a efectua calcule intensive.

Principalele caracteristici ale OLAP ce pot fi utilizate în asistarea

deciziei de management, se referă la:

Perspectiva (view) multidimensională asupra datelor - capacitatea de a

integra mai multe aspecte ale managementului privit din diferite perspective:

timp, locație, produs. Fiecare dimensiune poate avea mai multe nivele:

dimensiunea temporală se poate divide în luni, zile, dimensiunea produs în

contracte, furnizori, etc.

Figura nr. 2.9. - Perspectiva (view) multidimensională asupra datelor


48

Conceptul „dimensiune” este utilizat în sensul de aspect, dimensiunile

fiind complet independente şi au ca unitate de măsură toate valorile întâlnite în

dimensiunea respectivă. Aceste unităţi de măsură sunt posibile criterii de

agregare a datelor iar nivelele unei dimensiuni formează o ierarhie care de

asemenea oferă criterii de agregare a datelor. O tabelă dimensională are

următoarele caracteristici:

conține informații descriptive despre valorile numerice din tabelele de

fapte;

este denormalizată cu un număr mare de coloane;

conține puține înregistrări, comparativ cu tabela de fapte care poate

conține de la zeci de mii la milioane de înregistrări;

câmpurile sale sunt utilizate ca etichete pentru rândurile și coloanele

rapoartelor.

Atunci când toate dimensiunile au fost definite cubul OLAP este supus

procesului de prelucrare și putem obține o perspectivă multidimensională a

datelor. Prelucrarea cubului OLAP este ultimul pas după extragerea datelor din

sistemul sursă, transformarea adică aplicarea unor funcții pentru ca datele să

se poată conforma la o schemă standard de dimensiuni și încărcarea datelor în

vederea execuțiilor.

Evoluțiile recente ale depozitelor de date impun ca binecunoscutul flux

Extract (E) – Transform (T) – Load (L) care precede procesul de prelucrare a

cubului să fie extins la E-MPAC-TL adică: Extract - Monitor, Profile, Analyze,

Clean – Transform & Load, în încercarea de a echilibra în mod corespunzător

cerințele utilizatorilor finali cu realitățile sistemelor, instrumentelor,

constrângerilor și problemelor tehnice existente. Figura 2.10. descrie locul

fiecărei componente în arhitectula generală a fluxului, accentul fiind pus pe

calitatea datelor ce vor urma să fie prelucrate în vederea obținerii de informații,

cunoștințe care trebuie să constituie suportul deciziei/deciziilor, la nivel de

management.

Source: http://www.element61.be/assets/best-practise-extraction-tr.gif

Figura 2.10. - Arhitectura generală a fluxului E-MPAC-TL

48

Conceptul „dimensiune” este utilizat în sensul de aspect, dimensiunile

fiind complet independente şi au ca unitate de măsură toate valorile întâlnite în

dimensiunea respectivă. Aceste unităţi de măsură sunt posibile criterii de

agregare a datelor iar nivelele unei dimensiuni formează o ierarhie care de

asemenea oferă criterii de agregare a datelor. O tabelă dimensională are

următoarele caracteristici:

conține informații descriptive despre valorile numerice din tabelele de

fapte;

este denormalizată cu un număr mare de coloane;

conține puține înregistrări, comparativ cu tabela de fapte care poate

conține de la zeci de mii la milioane de înregistrări;

câmpurile sale sunt utilizate ca etichete pentru rândurile și coloanele

rapoartelor.

Atunci când toate dimensiunile au fost definite cubul OLAP este supus

procesului de prelucrare și putem obține o perspectivă multidimensională a

datelor. Prelucrarea cubului OLAP este ultimul pas după extragerea datelor din

sistemul sursă, transformarea adică aplicarea unor funcții pentru ca datele să

se poată conforma la o schemă standard de dimensiuni și încărcarea datelor în

vederea execuțiilor.

Evoluțiile recente ale depozitelor de date impun ca binecunoscutul flux

Extract (E) – Transform (T) – Load (L) care precede procesul de prelucrare a

cubului să fie extins la E-MPAC-TL adică: Extract - Monitor, Profile, Analyze,

Clean – Transform & Load, în încercarea de a echilibra în mod corespunzător

cerințele utilizatorilor finali cu realitățile sistemelor, instrumentelor,

constrângerilor și problemelor tehnice existente. Figura 2.10. descrie locul

fiecărei componente în arhitectula generală a fluxului, accentul fiind pus pe

calitatea datelor ce vor urma să fie prelucrate în vederea obținerii de informații,

cunoștințe care trebuie să constituie suportul deciziei/deciziilor, la nivel de

management.

Source: http://www.element61.be/assets/best-practise-extraction-tr.gif

Figura 2.10. - Arhitectura generală a fluxului E-MPAC-TL


49

Într-o abordare orientată către cerințe, schemele multidimensionale se

definesc pe baza obiectivelor instituționale care rezultă din cerințele factorilor

de decizie. De aceea este extrem de important ca sursele de date să parcurgă

cerințele fluxului E-MPAC-TL pentru o mai bună mapare a conceptelor

multidimensionale (fapte, dimensiuni și măsuri) pe structura acestora cu scopul

precis de a alimenta corespunzător depozitul de date.

Capacitatea de a efectua calcule intensive – abilitatea de a aplica algoritmi

complecşi asupra datelor structurate, ceea ce implică posibilitate de adresare

multidimensională directă a locaţiilor şi optimizarea timpului de răspuns.

Orientare în timp (time intelligence) – abilitatea de exploatare

multidimensională, necesară pentru comparaţii şi judecăţi de valoare în orice

analiză economică. Pe baza datelor primare stocate în bazele de date ale

sistemelor informatice se fac agregări de tipul: „cotaţiile de preţ din luna

curentă”, „cotaţiile de preţ din aceeaşi perioadă a anului trecut”, „variaţiile de

preţ ale ultimelor zile”, etc., care trebuie luate în considerare la proiectarea

dimensiunii temporale a cubului.

Conceptual depozitele de date şi tehnologia OLAP au apărut în anii 1990, dar

suportul software disponibil nu era suficient de flexibil şi accesibil utilizatorilor

finali al căror prim obiectiv era luarea unei decizii şi nu manevrarea unor

instrumente sofisticate de agregare şi corelare a datelor.

Procesul de acomodare cu noile tehnologii fiind destul de dificil, tehnologiile

amintite au fost înglobate în multiple aplicaţii dotate cu interfeţe prietenoase,

personalizate, uşor de manevrat. Experienţa dobândită în urma dezvoltării unor

astfel de aplicaţii a stat la baza creării unor instrumente flexibile, accesibile şi

standardizate puse la dispoziţia end-user-ilor într-un context unitar,

asemănător mediului de lucru din a IV a generaţie, organizat în jurul sistemelor

de gestiune a bazelor de date.

De altfel, instrumentele de creare a depozitelor de date şi exploatarea lor prin

tehnologia OLAP sunt incluse în sistemul de gestiune a bazelor de date SQL

Server 7.0, cel mai bun sistem de baze de date cu arhitectură client-server pe

platformele Windows NT, 2000.

49

Într-o abordare orientată către cerințe, schemele multidimensionale se

definesc pe baza obiectivelor instituționale care rezultă din cerințele factorilor

de decizie. De aceea este extrem de important ca sursele de date să parcurgă

cerințele fluxului E-MPAC-TL pentru o mai bună mapare a conceptelor

multidimensionale (fapte, dimensiuni și măsuri) pe structura acestora cu scopul

precis de a alimenta corespunzător depozitul de date.

Capacitatea de a efectua calcule intensive – abilitatea de a aplica algoritmi

complecşi asupra datelor structurate, ceea ce implică posibilitate de adresare

multidimensională directă a locaţiilor şi optimizarea timpului de răspuns.

Orientare în timp (time intelligence) – abilitatea de exploatare

multidimensională, necesară pentru comparaţii şi judecăţi de valoare în orice

analiză economică. Pe baza datelor primare stocate în bazele de date ale

sistemelor informatice se fac agregări de tipul: „cotaţiile de preţ din luna

curentă”, „cotaţiile de preţ din aceeaşi perioadă a anului trecut”, „variaţiile de

preţ ale ultimelor zile”, etc., care trebuie luate în considerare la proiectarea

dimensiunii temporale a cubului.

Conceptual depozitele de date şi tehnologia OLAP au apărut în anii 1990, dar

suportul software disponibil nu era suficient de flexibil şi accesibil utilizatorilor

finali al căror prim obiectiv era luarea unei decizii şi nu manevrarea unor

instrumente sofisticate de agregare şi corelare a datelor.

Procesul de acomodare cu noile tehnologii fiind destul de dificil, tehnologiile

amintite au fost înglobate în multiple aplicaţii dotate cu interfeţe prietenoase,

personalizate, uşor de manevrat. Experienţa dobândită în urma dezvoltării unor

astfel de aplicaţii a stat la baza creării unor instrumente flexibile, accesibile şi

standardizate puse la dispoziţia end-user-ilor într-un context unitar,

asemănător mediului de lucru din a IV a generaţie, organizat în jurul sistemelor

de gestiune a bazelor de date.

De altfel, instrumentele de creare a depozitelor de date şi exploatarea lor prin

tehnologia OLAP sunt incluse în sistemul de gestiune a bazelor de date SQL

Server 7.0, cel mai bun sistem de baze de date cu arhitectură client-server pe

platformele Windows NT, 2000.


50

2.3. Tehnologia Datamining – mineritul datelor stocate

În prezent, marea majoritate a companiilor colectează şi stochează

cantităţi mari de date cu ajutorul tehnologiilor informaţionale. Bazele de date au

dimensiuni ce pot ajunge la un terabyte. Astăzi tehnologia oferă facilităţi

imense de stocare şi computere cu procesoare performante la preţuri foarte

reduse. Principala provocare pentru companii nu este de a colecta şi stoca

volume adecvate de date, ci cum să tragă concluziile cele mai relevante din

aceste cantităţi mari de informaţii. Răspunsul la această provocare este

furnizat de extragerea datelor prin tehnologia Data Mining.

Data mining derivă din similitudinile existente între căutarea de

informaţii valoroase într-o bază de date a unei companii şi extragerea

minereurilor preţioase dintr-un masiv montan. Data mining, extragerea de

informaţii ascunse din baze de date vaste reprezintă o tehnologie care poate

ajuta companiile să se concentreze asupra celor mai importante informaţii din

bazele lor de date. Instrumentele specifice acestei tehnologii identifică trenduri

mai aprofundat decât o simplă analiză. Datorită folosirii unor algoritmi

complicaţi, utilizatorii au posibilitatea de a identifica atribute cheie ale

proceselor organizaţionale.

Data Mining şi alte procese similare pot fi utilizate, în principiu, pe orice

fel de baze de date. Se folosesc însă cu precădere, dacă nu inclusiv, în

depozite de date, explicaţia fiind simplă: pentru ca o operaţiune de data mining

să ofere rezultate, este necesar ca datele să fie de calitate, adică să fie

curăţate, integrate, selectate si transformate. Datele conţinute într-un depozit

de date, îndeplinesc întocmai aceste cerinţe și conduc la rezultate corecte şi

utile, la analizarea lor cu rutine de data mining.

Principiul de funcţionare în data mining este următorul: se prelucrează

datele referitoare la perioadele trecute, examinând o varietate de situaţii care

s-au produs şi ale căror rezultate sau consecinţe sunt deci, bine cunoscute,

pentru a evidenţia caracteristicile acestora şi a permite elaborarea unui model.

Odată construit, modelul poate fi aplicat situaţiilor noi de acelaşi tip. Etapizat,

procesul de curățire a datelor poate fi derulat astfel:

Definirea problemei;

Prepararea datelor: căutarea, selectarea datelor pertinente, eliminarea

datelor necorespunzătoare;

Exploarea datelor: stabilirea modului de acțiune asupra variabilelor;

50

2.3. Tehnologia Datamining – mineritul datelor stocate

În prezent, marea majoritate a companiilor colectează şi stochează

cantităţi mari de date cu ajutorul tehnologiilor informaţionale. Bazele de date au

dimensiuni ce pot ajunge la un terabyte. Astăzi tehnologia oferă facilităţi

imense de stocare şi computere cu procesoare performante la preţuri foarte

reduse. Principala provocare pentru companii nu este de a colecta şi stoca

volume adecvate de date, ci cum să tragă concluziile cele mai relevante din

aceste cantităţi mari de informaţii. Răspunsul la această provocare este

furnizat de extragerea datelor prin tehnologia Data Mining.

Data mining derivă din similitudinile existente între căutarea de

informaţii valoroase într-o bază de date a unei companii şi extragerea

minereurilor preţioase dintr-un masiv montan. Data mining, extragerea de

informaţii ascunse din baze de date vaste reprezintă o tehnologie care poate

ajuta companiile să se concentreze asupra celor mai importante informaţii din

bazele lor de date. Instrumentele specifice acestei tehnologii identifică trenduri

mai aprofundat decât o simplă analiză. Datorită folosirii unor algoritmi

complicaţi, utilizatorii au posibilitatea de a identifica atribute cheie ale

proceselor organizaţionale.

Data Mining şi alte procese similare pot fi utilizate, în principiu, pe orice

fel de baze de date. Se folosesc însă cu precădere, dacă nu inclusiv, în

depozite de date, explicaţia fiind simplă: pentru ca o operaţiune de data mining

să ofere rezultate, este necesar ca datele să fie de calitate, adică să fie

curăţate, integrate, selectate si transformate. Datele conţinute într-un depozit

de date, îndeplinesc întocmai aceste cerinţe și conduc la rezultate corecte şi

utile, la analizarea lor cu rutine de data mining.

Principiul de funcţionare în data mining este următorul: se prelucrează

datele referitoare la perioadele trecute, examinând o varietate de situaţii care

s-au produs şi ale căror rezultate sau consecinţe sunt deci, bine cunoscute,

pentru a evidenţia caracteristicile acestora şi a permite elaborarea unui model.

Odată construit, modelul poate fi aplicat situaţiilor noi de acelaşi tip. Etapizat,

procesul de curățire a datelor poate fi derulat astfel:

Definirea problemei;

Prepararea datelor: căutarea, selectarea datelor pertinente, eliminarea

datelor necorespunzătoare;

Exploarea datelor: stabilirea modului de acțiune asupra variabilelor;


51

Construirea modelului;

Validarea modelului și implicit al rezultatului;

Integrarea cunoștințelor.

Source: https://i-msdn.sec.s-msft.com/dynimg/IC125015.gif

Figura 2.11 – Etapele procesului Datamining

Tehnologia Data mining este o tehnologie relativ nouă, care câştigă din

ce în ce mai mult teren prin capacitatea sa de a descoperi aspecte noi ale

activităţii desfăşurate, aspecte trecute în mod normal cu vederea. Este vorba

în principal, de corelaţiile dintre evenimente, asociaţii între anumite fapte,

secvenţe, tipare de comportament, toate extrem de utile în procesele de luare

a deciziei. Procesarea datelor prin tehnologia data mining se desfăşoară fără

intervenţia utilizatorului, în background, rezultatele fiind stocate pentru

consultare ulterioară la cerere.

2.3.1. Extragerea informațiilor din depozitele de date. Instrumente de extragere

şi transformare a datelor

Data Mining reprezintă procesul de extragere a informaţiilor anterior

necunoscute şi potențial folositoare din depozitele de date. Acest proces

constă în căutarea informaţiilor în volume mari de date, explorarea şi

analizarea lor prin metode automate sau semiautomate, cu scopul de a

descoperi şabloane tendinţe şi reguli folositoare. Procesul nu necesită

stabilirea de ipoteze de plecare care ar trebui verificate. Demersul fără a priori

încearcă să facă să apară, din datele brute, inferențe pe care experimentatorul

e posibil nici să nu le bănuiască și a căror pertinență va trebui să o valideze.

51

Construirea modelului;

Validarea modelului și implicit al rezultatului;

Integrarea cunoștințelor.

Source: https://i-msdn.sec.s-msft.com/dynimg/IC125015.gif

Figura 2.11 – Etapele procesului Datamining

Tehnologia Data mining este o tehnologie relativ nouă, care câştigă din

ce în ce mai mult teren prin capacitatea sa de a descoperi aspecte noi ale

activităţii desfăşurate, aspecte trecute în mod normal cu vederea. Este vorba

în principal, de corelaţiile dintre evenimente, asociaţii între anumite fapte,

secvenţe, tipare de comportament, toate extrem de utile în procesele de luare

a deciziei. Procesarea datelor prin tehnologia data mining se desfăşoară fără

intervenţia utilizatorului, în background, rezultatele fiind stocate pentru

consultare ulterioară la cerere.

2.3.1. Extragerea informațiilor din depozitele de date. Instrumente de extragere

şi transformare a datelor

Data Mining reprezintă procesul de extragere a informaţiilor anterior

necunoscute şi potențial folositoare din depozitele de date. Acest proces

constă în căutarea informaţiilor în volume mari de date, explorarea şi

analizarea lor prin metode automate sau semiautomate, cu scopul de a

descoperi şabloane tendinţe şi reguli folositoare. Procesul nu necesită

stabilirea de ipoteze de plecare care ar trebui verificate. Demersul fără a priori

încearcă să facă să apară, din datele brute, inferențe pe care experimentatorul

e posibil nici să nu le bănuiască și a căror pertinență va trebui să o valideze.


52

Data mining este în același timp un proces interactiv şi iterativ de

identificare în baze mari de date de informatii implicite, valide, noi, potenţial

utile si inteligibile care se pot transforma în cunoştinte. Conceptul de data

mining mai este cunoscut și sub denumirea de Knowledge Discovery in

Databases (KDD)10, extragere de cunoştinţe de baze de date, arheologia

datelor si altele. Extragerea de cunoştinţe, executată corect, conduce la:

reducerea costurilor proceselor de luare a deciziilor,

management inteligent (de o mai bună calitate şi cu decizii mai rapide),

îmbunătaţirea serviciilor către clienţi,

oferirea unui suport valabil proiectelor de reinginerire a afacerii,

îmbunătaţirea managementului firmei în ansamblu,

iar etapele care compun procesul de descoperire a cunoștințelor este redat

sintetic în Figura 2.12.

Figura 2.12. – Etapele procesului de descoperire a cunoștințelor

Sistemele de data mining sau de extragere de cunoştinţe au

următoarele caracteristici esenţiale:

concluziile generate de sistem au o probabilitate foarte mare, pot fi

considerate „sigure”;

în comparaţie cu informaţiile deţinute de utilizator sau de către sistem,

informaţia rezultatâ nu este trivială;

modelele descoperite sunt reprezentate utilizatorului într-o formă

comprehensibilă.

Ca parte a procesului de extragere şi transformare, este nevoie de

instrumente care să poată extrage, transforma, integra, curăţi şi încărca datele

din sistemele sursă în una sau mai multe baze de date ale depozitului. Echipa

data warehouse are mai multe opţiuni privind instrumentele de extragere a

datelor, însă alegerea depinde în principal de următorii factori:

10 http://www.techopedia.com/definition/25827/knowledge-discovery-in-databases-kdd

52

Data mining este în același timp un proces interactiv şi iterativ de

identificare în baze mari de date de informatii implicite, valide, noi, potenţial

utile si inteligibile care se pot transforma în cunoştinte. Conceptul de data

mining mai este cunoscut și sub denumirea de Knowledge Discovery in

Databases (KDD)10, extragere de cunoştinţe de baze de date, arheologia

datelor si altele. Extragerea de cunoştinţe, executată corect, conduce la:

reducerea costurilor proceselor de luare a deciziilor,

management inteligent (de o mai bună calitate şi cu decizii mai rapide),

îmbunătaţirea serviciilor către clienţi,

oferirea unui suport valabil proiectelor de reinginerire a afacerii,

îmbunătaţirea managementului firmei în ansamblu,

iar etapele care compun procesul de descoperire a cunoștințelor este redat

sintetic în Figura 2.12.

Figura 2.12. – Etapele procesului de descoperire a cunoștințelor

Sistemele de data mining sau de extragere de cunoştinţe au

următoarele caracteristici esenţiale:

concluziile generate de sistem au o probabilitate foarte mare, pot fi

considerate „sigure”;

în comparaţie cu informaţiile deţinute de utilizator sau de către sistem,

informaţia rezultatâ nu este trivială;

modelele descoperite sunt reprezentate utilizatorului într-o formă

comprehensibilă.

Ca parte a procesului de extragere şi transformare, este nevoie de

instrumente care să poată extrage, transforma, integra, curăţi şi încărca datele

din sistemele sursă în una sau mai multe baze de date ale depozitului. Echipa

data warehouse are mai multe opţiuni privind instrumentele de extragere a

datelor, însă alegerea depinde în principal de următorii factori:

10 http://www.techopedia.com/definition/25827/knowledge-discovery-in-databases-kdd


53

Bazele de date şi platforma sistemului sursă. Instrumentele de extragere şi

transformare nu pot accesa toate tipurile de surse de date şi toate tipurile de

platforme de operare. Atâta timp cât nu există disponibilităţi pentru investiţii

în componente middleware, opţiunile sunt limitate la acele instrumente care

sunt compatibile cu sistemele sursă din întreprindere.

Funcţionalităţi de extragere şi duplicare existente. Sistemele sursă pot avea

deja posibilităţi de extragere şi duplicare încorporate, fie prin aplicaţiile

folosite, fie prin motorul bazei de date. Disponibilitatea acestor funcţionalităţi

pot reduce dificultăţile legate de procesul de extragere a datelor.

Intervalele de timp în care sistemele operaţionale sunt disponibile. Unele

mecanisme de extragere sunt mai rapide şi mai eficiente decât altele.

Ferestrele de timp din sistemele operaţionale determină timpul disponibil

pentru procesul de extragere şi acest aspect poate limita opţiunile echipei

de dezvoltare în ce priveşte alegerea instrumentelor de extragere. În

practică se întâlnesc două metode de bază pentru extragerea datelor din

sistemele operaţionale:

- Extragerea în masă (bulk extractions) - întregul depozit de date

este împrospătat periodic prin extragerea datelor din sistemele sursă.

Toate datele necesare sunt extrase din sistemele sursă iar depozitul de

date este reconstruit complet. Această tehnică implică mari costuri legate

de transmiterea datelor în reţea, în schimb oferă avantajul unei întreţineri

comode a depozitului de date;

- Replicarea - ia în considerare doar datele noi din sistemele sursă.

în acest caz sunt extrase doar datele noi sau datele care au suferit

modificări de la ultima extragere din sistemele sursă. Această metodă

este eficientă din punctul de vedere al volumului de date care se

vehiculează în reţea, dar necesită aplicaţii complexe care să gestioneze

schimbările intervenite. Instrumentele de transformare transformă datele

extrase întrun format adecvat care este necesar pentru a putea fi stocate

în depozitul de date.

Majoritatea instrumentelor de transformare oferă următoarele

capabilităţi (vezi Tabelul 2.1.):

Partiţionarea şi consolidarea câmpurilor. Anumite secvenţe de date sunt

implementate într-un singur câmp fizic din sistemul sursă, ceea ce duce

la necesitatea partiţionării lor în mai multe câmpuri în depozitul de date.

În acelaşi timp, pot fi cazuri în care mai multe câmpuri din sistemele

53

Bazele de date şi platforma sistemului sursă. Instrumentele de extragere şi

transformare nu pot accesa toate tipurile de surse de date şi toate tipurile de

platforme de operare. Atâta timp cât nu există disponibilităţi pentru investiţii

în componente middleware, opţiunile sunt limitate la acele instrumente care

sunt compatibile cu sistemele sursă din întreprindere.

Funcţionalităţi de extragere şi duplicare existente. Sistemele sursă pot avea

deja posibilităţi de extragere şi duplicare încorporate, fie prin aplicaţiile

folosite, fie prin motorul bazei de date. Disponibilitatea acestor funcţionalităţi

pot reduce dificultăţile legate de procesul de extragere a datelor.

Intervalele de timp în care sistemele operaţionale sunt disponibile. Unele

mecanisme de extragere sunt mai rapide şi mai eficiente decât altele.

Ferestrele de timp din sistemele operaţionale determină timpul disponibil

pentru procesul de extragere şi acest aspect poate limita opţiunile echipei

de dezvoltare în ce priveşte alegerea instrumentelor de extragere. În

practică se întâlnesc două metode de bază pentru extragerea datelor din

sistemele operaţionale:

- Extragerea în masă (bulk extractions) - întregul depozit de date

este împrospătat periodic prin extragerea datelor din sistemele sursă.

Toate datele necesare sunt extrase din sistemele sursă iar depozitul de

date este reconstruit complet. Această tehnică implică mari costuri legate

de transmiterea datelor în reţea, în schimb oferă avantajul unei întreţineri

comode a depozitului de date;

- Replicarea - ia în considerare doar datele noi din sistemele sursă.

în acest caz sunt extrase doar datele noi sau datele care au suferit

modificări de la ultima extragere din sistemele sursă. Această metodă

este eficientă din punctul de vedere al volumului de date care se

vehiculează în reţea, dar necesită aplicaţii complexe care să gestioneze

schimbările intervenite. Instrumentele de transformare transformă datele

extrase întrun format adecvat care este necesar pentru a putea fi stocate

în depozitul de date.

Majoritatea instrumentelor de transformare oferă următoarele

capabilităţi (vezi Tabelul 2.1.):

Partiţionarea şi consolidarea câmpurilor. Anumite secvenţe de date sunt

implementate într-un singur câmp fizic din sistemul sursă, ceea ce duce

la necesitatea partiţionării lor în mai multe câmpuri în depozitul de date.

În acelaşi timp, pot fi cazuri în care mai multe câmpuri din sistemele


54

sursă trebuie consolidate astfel încât datele să fie stocate în depozit într-

un singur câmp.

Standardizarea. Standardele şi convenţiile pentru abrevieri, formate de

date, tipuri de date etc sunt aplicate secvenţelor individuale de date

pentru a creşte uniformitatea conţinutului.

Deduplicarea. Se definesc reguli pentru a identifica înregistrări duplicat.

Când se descoperă un duplicat, două sau mai multe înregistrări sunt

comasate pentru a forma o singură înregistrare în depozitul de date.

Tabel 2.1. – Exemple de transformări de date

Câmp sursă Tipul transformării Depozit de date

Câmpul Adresa:

Str. V.Conta, nr. 4, Craiova,

200450, Dolj, Romania

Partiționare câmpuri

Strada: V. Conta; Nr.: 4

Localitate: Craiova;

Cod: 200450;

Județ: Dolj;

Țara: România

Nume: Ionescu

Prenume: Ioan

Consolidare

câmpuri

Nume-prenume:

Ionescu Ioan

Data nașterii: 15 Apr. 2015

Data nașterii: 15-04-05 Standardizare

Data nașterii:

15 Aprilie 2015

Sistem1, Nume angajat:

Ionescu I. Ioan


Ionescu Ioan

Deduplicare Nume angajat:

Ionescu Ioan

Diverse exemplificări ale procesului de aplicare a procesului de data mining în

diverse domenii:

Advertising ...

Un exemplu tipic de problemă de natură descriptivă este direcţionarea

acţiunilor de advertising. Datele rezultate din corespondenţa promoţională

trecută se folosesc pentru a identifica destinatarii pentru următoarea campanie

promoţională care, pot aduce un maxim de efect.

Tranzacții financiare ...

În schimb, detectarea evoluţiilor de curs spectaculoase, derulate în

ringul de tranzacţionare constituie unul dintre exemplele tipice de aplicaţii

descriptive. Explorarea ansamblului tranzacţiilor permite evidenţierea unui

anumit tipar comportamental considerat normal. De îndată ce un trend iese din

tipar, pot fi emise semnale de avertisment. Este posibil ca trendul semnalat să

54

sursă trebuie consolidate astfel încât datele să fie stocate în depozit într-

un singur câmp.

Standardizarea. Standardele şi convenţiile pentru abrevieri, formate de

date, tipuri de date etc sunt aplicate secvenţelor individuale de date

pentru a creşte uniformitatea conţinutului.

Deduplicarea. Se definesc reguli pentru a identifica înregistrări duplicat.

Când se descoperă un duplicat, două sau mai multe înregistrări sunt

comasate pentru a forma o singură înregistrare în depozitul de date.

Tabel 2.1. – Exemple de transformări de date

Câmp sursă Tipul transformării Depozit de date

Câmpul Adresa:

Str. V.Conta, nr. 4, Craiova,

200450, Dolj, Romania

Partiționare câmpuri

Strada: V. Conta; Nr.: 4

Localitate: Craiova;

Cod: 200450;

Județ: Dolj;

Țara: România

Nume: Ionescu

Prenume: Ioan

Consolidare

câmpuri

Nume-prenume:

Ionescu Ioan

Data nașterii: 15 Apr. 2015

Data nașterii: 15-04-05 Standardizare

Data nașterii:

15 Aprilie 2015


Ionescu I. Ioan


Ionescu Ioan

Deduplicare Nume angajat:

Ionescu Ioan

Diverse exemplificări ale procesului de aplicare a procesului de data mining în

diverse domenii:

Advertising ...

Un exemplu tipic de problemă de natură descriptivă este direcţionarea

acţiunilor de advertising. Datele rezultate din corespondenţa promoţională

trecută se folosesc pentru a identifica destinatarii pentru următoarea campanie

promoţională care, pot aduce un maxim de efect.

Tranzacții financiare ...

În schimb, detectarea evoluţiilor de curs spectaculoase, derulate în

ringul de tranzacţionare constituie unul dintre exemplele tipice de aplicaţii

descriptive. Explorarea ansamblului tranzacţiilor permite evidenţierea unui

anumit tipar comportamental considerat normal. De îndată ce un trend iese din

tipar, pot fi emise semnale de avertisment. Este posibil ca trendul semnalat să


55

nu atragă după sine şi creşteri/descreşteri semnificative ale cotaţiilor; o analiză

ulterioară poate stabili acest lucru dar, în acest stadiu, sistemul, ca urmare a

implementării tehnologiei de extragere a cunoştinţelor, emite semnale de

avertizare pentru a preveni orice consecinţe nedorite pentru managementul

tranzacțiilor.

Distribuție produse ...

Utilizatorul (managerul de vânzări) solicită bazei de date informaţii cu

privire la vânzările totale pe trimestrul curent şi pe trimestrul anterior, precum şi

un calcul al diferenţei şi a procentajului de creştere sau descreştere a

vânzărilor. La o primă interogare a bazei de date el află, de exemplu, că

vânzările au crescut, în ansablu, de la trimestru la trimestru. Mai departe, el

doreşte să afle cum stă evoluţia vânzărilor pe fiecare judeţ, şi cere bazei de

date un raport asemănător, numai că acum defalcat pe judeţe. Primind acest

raport, el află că vânzările au crescut în majoritatea judeţelor, dar au scăzut în

Bacău şi Vrancea. Pentru a afla mai mult, el cere situaţia vânzărilor pentru

fiecare din cei 10 distribuitori din judeţul Bacău, unul din judeţele cu probleme.

Astfel, află că în acest judeţ, 8 din 10 distribuitori au înregistrat scăderi destul

de drastice ale vânzărilor. Mai departe, el cere pentru fiecare din aceşti

distribuitori, o situaţie a evoluţiei vânzărilor pe produse şi observă că declinul

cel mai accentuat se înregistrează la produsul X. Urmărind situaţia vânzărilor

pentru zona Vrancea, utilizatorul descoperă acelaşi lucru: vânzările la produsul

X scad la majoritatea distribuitorilor din acest judeţ. Studiind vânzările

produsului X şi în judeţele unde se înregistrează creşteri de ansamblu ale cifrei

de afaceri, managerul află că în cazul acestui produs, creşterile sunt foarte

reduse, iar în multe cazuri (cca. 30% din totalul judeţelor) s-au produs chiar

scăderi uşoare. Concluzia analizei: produsul X pare a fi un produs-problemă.

Momentan, problema se manifestă mai acut în două zone, dar s-ar putea

extinde în viitor. Aşadar, deşi per ansamblu vânzările firmei au crescut, există

totuşi o problemă importantă, care a fost identificată cu ajutorul procesului de

data mining.

Marketing – profilul consumatorului ...

Caracteristicile clienţilor buni (celor care cumpără de la firmă, regulat şi

în cantităţi mari) sunt utilizate ca variabile de predicţie. Ele îi vor ajuta pe

marketeri să-i “ţintească” pe noii clienţi. Cu ajutorul explorării putem identifica,

55

nu atragă după sine şi creşteri/descreşteri semnificative ale cotaţiilor; o analiză

ulterioară poate stabili acest lucru dar, în acest stadiu, sistemul, ca urmare a

implementării tehnologiei de extragere a cunoştinţelor, emite semnale de

avertizare pentru a preveni orice consecinţe nedorite pentru managementul

tranzacțiilor.

Distribuție produse ...

Utilizatorul (managerul de vânzări) solicită bazei de date informaţii cu

privire la vânzările totale pe trimestrul curent şi pe trimestrul anterior, precum şi

un calcul al diferenţei şi a procentajului de creştere sau descreştere a

vânzărilor. La o primă interogare a bazei de date el află, de exemplu, că

vânzările au crescut, în ansablu, de la trimestru la trimestru. Mai departe, el

doreşte să afle cum stă evoluţia vânzărilor pe fiecare judeţ, şi cere bazei de

date un raport asemănător, numai că acum defalcat pe judeţe. Primind acest

raport, el află că vânzările au crescut în majoritatea judeţelor, dar au scăzut în

Bacău şi Vrancea. Pentru a afla mai mult, el cere situaţia vânzărilor pentru

fiecare din cei 10 distribuitori din judeţul Bacău, unul din judeţele cu probleme.

Astfel, află că în acest judeţ, 8 din 10 distribuitori au înregistrat scăderi destul

de drastice ale vânzărilor. Mai departe, el cere pentru fiecare din aceşti

distribuitori, o situaţie a evoluţiei vânzărilor pe produse şi observă că declinul

cel mai accentuat se înregistrează la produsul X. Urmărind situaţia vânzărilor

pentru zona Vrancea, utilizatorul descoperă acelaşi lucru: vânzările la produsul

X scad la majoritatea distribuitorilor din acest judeţ. Studiind vânzările

produsului X şi în judeţele unde se înregistrează creşteri de ansamblu ale cifrei

de afaceri, managerul află că în cazul acestui produs, creşterile sunt foarte

reduse, iar în multe cazuri (cca. 30% din totalul judeţelor) s-au produs chiar

scăderi uşoare. Concluzia analizei: produsul X pare a fi un produs-problemă.

Momentan, problema se manifestă mai acut în două zone, dar s-ar putea

extinde în viitor. Aşadar, deşi per ansamblu vânzările firmei au crescut, există

totuşi o problemă importantă, care a fost identificată cu ajutorul procesului de

data mining.

Marketing – profilul consumatorului ...

Caracteristicile clienţilor buni (celor care cumpără de la firmă, regulat şi

în cantităţi mari) sunt utilizate ca variabile de predicţie. Ele îi vor ajuta pe

marketeri să-i “ţintească” pe noii clienţi. Cu ajutorul explorării putem identifica,


56

în baza de date cu clienţi, o serie de modele care pot fi aplicate ca criterii de

selectare pentru o bază de date cu clienţi potenţiali. Acei clienţi potenţiali, care

se aseamănă cel mai mult cu “clientul ideal”, vor constitui cei mai buni

candidaţi pentru o campanie de marketing direct, de exemplu. Este de aşteptat

ca beneficiile oferite de produsul firmei, să fie interesante şi pentru ei. Acest

fapt permite eficientizarea campaniilor de marketing, prin direcţionarea lor

către acei potenţiali clienţi care au cea mai mare probabilitate de cumpărare.

Explorarea datelor îi poate ajuta pe detailişti să înţeleagă cum arată “coşul de

produse” al unui cumpărător individual (ce tip de produse şi ce mărci sunt

achiziţionate simultan). Ei pot afla astfel ce produse trebuie expuse pe rafturi şi

cum trebuie expuse. Explorarea poate de asemenea ajuta la măsurarea

eficienţei campaniilor promoţionale ale magazinului.

Managementul clienților - gestiunea relaţiilor cu clienţii ...

Determinând caracteristicile clienţilor pentru care este foarte mare

probabilitatea de a ne părăsi în favoarea unui client, compania poate pune în

practică acţiuni de reţinere a clienţilor, ştiut fiind că reţinerea clienţilor vechi

costă mult mai puţin decât atragerea de noi clienţi.

2.3.2. Metode și tehnici de datamining. Clustering – tehnică de grupare a

datelor multi-dimensionale

Tehnicile de data mining permit extragerea informațiilor și realizarea de

previziuni pornind de la date istorice. Tehnicile de data mining au fost grupate

în trei categorii, în functie de tipul de probleme pe care le pot modela:

Clasificarea și regresia reprezintă cea mai largă categorie de aplicații,

constând în construirea de modele pentru previzionarea apartenenței la un

set de clase (clasificare) sau a unor valori (regresie). Există câteva tehnici

dedicate rezolvării problemelor de clasificare și regresie, dintre care arborii

decizionali, tehnica Bayes, rețelele neuronale și k-NN se bucură de o largă

recunoaștere.

Analiza asocierilor și succesiunilor, denumită uneori analiza coșului de

cumpărături; această tehnică generează modele descriptive care

evidențiază reguli de corelație între atributele unui set de date.

Analiza de tip cluster este o tehnică descriptivă utilizată pentru gruparea

entităților similare dintr-un set de date sau în egală măsura pentru

56

în baza de date cu clienţi, o serie de modele care pot fi aplicate ca criterii de

selectare pentru o bază de date cu clienţi potenţiali. Acei clienţi potenţiali, care

se aseamănă cel mai mult cu “clientul ideal”, vor constitui cei mai buni

candidaţi pentru o campanie de marketing direct, de exemplu. Este de aşteptat

ca beneficiile oferite de produsul firmei, să fie interesante şi pentru ei. Acest

fapt permite eficientizarea campaniilor de marketing, prin direcţionarea lor

către acei potenţiali clienţi care au cea mai mare probabilitate de cumpărare.

Explorarea datelor îi poate ajuta pe detailişti să înţeleagă cum arată “coşul de

produse” al unui cumpărător individual (ce tip de produse şi ce mărci sunt

achiziţionate simultan). Ei pot afla astfel ce produse trebuie expuse pe rafturi şi

cum trebuie expuse. Explorarea poate de asemenea ajuta la măsurarea

eficienţei campaniilor promoţionale ale magazinului.

Managementul clienților - gestiunea relaţiilor cu clienţii ...

Determinând caracteristicile clienţilor pentru care este foarte mare

probabilitatea de a ne părăsi în favoarea unui client, compania poate pune în

practică acţiuni de reţinere a clienţilor, ştiut fiind că reţinerea clienţilor vechi

costă mult mai puţin decât atragerea de noi clienţi.

2.3.2. Metode și tehnici de datamining. Clustering – tehnică de grupare a

datelor multi-dimensionale

Tehnicile de data mining permit extragerea informațiilor și realizarea de

previziuni pornind de la date istorice. Tehnicile de data mining au fost grupate

în trei categorii, în functie de tipul de probleme pe care le pot modela:

Clasificarea și regresia reprezintă cea mai largă categorie de aplicații,

constând în construirea de modele pentru previzionarea apartenenței la un

set de clase (clasificare) sau a unor valori (regresie). Există câteva tehnici

dedicate rezolvării problemelor de clasificare și regresie, dintre care arborii

decizionali, tehnica Bayes, rețelele neuronale și k-NN se bucură de o largă

recunoaștere.

Analiza asocierilor și succesiunilor, denumită uneori analiza coșului de

cumpărături; această tehnică generează modele descriptive care

evidențiază reguli de corelație între atributele unui set de date.

Analiza de tip cluster este o tehnică descriptivă utilizată pentru gruparea

entităților similare dintr-un set de date sau în egală măsura pentru


57

evidențierea entităților care prezintă diferențieri substanțiale față de un grup.

Tehnicile de grupare în clustere se bazează pe algoritmi din sfera rețelelor

neuronale, algoritmi demografici, k-NN etc.

Pentru rezolvarea problemelor de clasificare și regresie există o serie

de tehnici, iar pentru fiecare tehnică sunt disponibili mai mulți algoritmi.

Diferența dintre clasificare și regresie este aceea că în primul caz, outputul

previzionat este apartenența la o anumită clasă, în timp ce în al doilea caz,

outputul estimează valoarea unui atribut.

Clasificarea (clustering) analizează un set de date şi stabileşte un

ansamblu de reguli pe baza cărora vor fi grupate datele obţinute în viitor.

Software-ul de data mining identifică automat clasele (sau “ciorchinii”), studiind

pattern-ul datelor existente (Berkhin, 2002). Odată ce au fost generate clasele

se poate stabili, pe baza unor caracteristici precizate, cărei clase aparţine un

anume obiect din baza de date studiată. De exemplu, o clasă poate fi un

segment de piaţă. Atunci când firma are un client nou ea poate stabili,

cunoscând caracteristicile acestuia, în ce segment se încadrează.

Această tehnică de grupare este utilă pentru sumarizarea unor cantități

mari de informație, fiecare grupă reprezentând mai multe puncte având

caracteristici similare (Barbara, 2000). Clusterele distincte nu se suprapun

(sunt disjuncte). De fapt, analiza clasificării constă dintr-o colecție de algoritmi

ce exploatează mai multe euristici fundamentate în principal pe experiența

noastră „vizuală” în gruparea datelor în „nori de puncte”. În general, pentru a

putea folosi un algoritm de clasificare, este nevoie ca mai întâi să se precizeze:

Un tip de distanță între punctele unui spațiu multidimensional;

O strategie de alegere a punctului reprezentativ (adică a „centrului”)

pentru orice grupare de puncte. Cel mai adesea există tendința de a

alege media aritmetică (adică „centrul de greutate”);

Un tip de distanță între două grupe de date. Cele mai folosite

asemenea distanțe iau în considerare distanța între puncte aleasă

anterior.

Clusterizarea are nevoie de o funcţie de similitudine pentru a măsura

cât de similare sunt două date, sau alternativ, o funcţie depărtare

(disimilaritate) pentru a măsura distanţa dintre două date, întrucât utilizatorul

explorează datele cu scopul de a găsi structuri noi, interesante şi folositoare.

Principala problemă a clusterizării o constituie volumul mare de date care

trebuie procesat, algoritmii de clusterizare fiind în general cu timp de răspuns

57

evidențierea entităților care prezintă diferențieri substanțiale față de un grup.

Tehnicile de grupare în clustere se bazează pe algoritmi din sfera rețelelor

neuronale, algoritmi demografici, k-NN etc.

Pentru rezolvarea problemelor de clasificare și regresie există o serie

de tehnici, iar pentru fiecare tehnică sunt disponibili mai mulți algoritmi.

Diferența dintre clasificare și regresie este aceea că în primul caz, outputul

previzionat este apartenența la o anumită clasă, în timp ce în al doilea caz,

outputul estimează valoarea unui atribut.

Clasificarea (clustering) analizează un set de date şi stabileşte un

ansamblu de reguli pe baza cărora vor fi grupate datele obţinute în viitor.

Software-ul de data mining identifică automat clasele (sau “ciorchinii”), studiind

pattern-ul datelor existente (Berkhin, 2002). Odată ce au fost generate clasele

se poate stabili, pe baza unor caracteristici precizate, cărei clase aparţine un

anume obiect din baza de date studiată. De exemplu, o clasă poate fi un

segment de piaţă. Atunci când firma are un client nou ea poate stabili,

cunoscând caracteristicile acestuia, în ce segment se încadrează.

Această tehnică de grupare este utilă pentru sumarizarea unor cantități

mari de informație, fiecare grupă reprezentând mai multe puncte având

caracteristici similare (Barbara, 2000). Clusterele distincte nu se suprapun

(sunt disjuncte). De fapt, analiza clasificării constă dintr-o colecție de algoritmi

ce exploatează mai multe euristici fundamentate în principal pe experiența

noastră „vizuală” în gruparea datelor în „nori de puncte”. În general, pentru a

putea folosi un algoritm de clasificare, este nevoie ca mai întâi să se precizeze:

Un tip de distanță între punctele unui spațiu multidimensional;

O strategie de alegere a punctului reprezentativ (adică a „centrului”)

pentru orice grupare de puncte. Cel mai adesea există tendința de a

alege media aritmetică (adică „centrul de greutate”);

Un tip de distanță între două grupe de date. Cele mai folosite

asemenea distanțe iau în considerare distanța între puncte aleasă

anterior.

Clusterizarea are nevoie de o funcţie de similitudine pentru a măsura

cât de similare sunt două date, sau alternativ, o funcţie depărtare

(disimilaritate) pentru a măsura distanţa dintre două date, întrucât utilizatorul

explorează datele cu scopul de a găsi structuri noi, interesante şi folositoare.

Principala problemă a clusterizării o constituie volumul mare de date care

trebuie procesat, algoritmii de clusterizare fiind în general cu timp de răspuns


58

mare. Este cazul clusterizării documentelor (Li, Chung 2005) şi a sistemelor de

regăsire a informaţiei (Grossman, Frieder 2004).

Clusterizarea partiţională

Cel mai utilizat algoritm partiţional este algoritmul k-means11

(MacQueen, 1967), care adevenit exponentul unei întregi categorii de

algoritmi. Popularitatea este dată de simplitatea implementării, scalabilitate,

eficienţă şi viteza de convergenţă (MacQueen, 1967).

Avantaje şi dezavantaje. Deşi k-means are marele avantaj că este uşor

de implementat şi eficient, are şi câteva mari neajunsuri. Primul dezavantaj

constă în aceea că poate fi foarte lent din moment ce în fiecare pas distanţa

dintre fiecare dată şi fiecare cluster trebuie calculată, afectând astfel timpul de

execuție. Al doilea dezavantaj este dat de faptul că aceată metodă e foarte

sensibilă la numărul şi iniţializarea clusterelor iniţiale, algoritmul putând să

furnizeze doar un optim local.

Clusterizarea ierarhică

Un alt tip de clusterizare este clusterizarea ierarhică care se bazează

pe o serie de algoritmi de clusterizare ierarhici ce au ca rezultat o ierarhie de

clustere numită dendrogramă12, adică un arbore care reflectă strucura

clusterelelor de date la diferite niveluri de similaritate. Aceasta se poate face

folosind:

Metode aglomerative de clusterizare – presupun o serie de fuziuni a

înregistrărilor inițiale din n clustere (câte înregistrări sunt) în grupuri din

ce în ce mai puține de înregistrări până când se obține numărul de

clustere dorit.

11 http://home.deib.polimi.it/matteucc/Clustering/tutorial_html/kmeans.html 12 http://www.totallab.com/products/samespots/support/faq/dendrogram.aspx

Algoritmul k-means (k, D)

Alege k date ca centroizi iniţiali (centrele clusterelor)

repeat

for each dată x D do

Calculează distanţa de la x la fiecare centroid;

Asociază x la cel mai apropiat centroid // centroidul reprezintă un cluster;

endfor

Recalculează centroidul cu ajutorul membrilor actuali ai clusterului

until criteriul de oprire este îndeplinit

58

mare. Este cazul clusterizării documentelor (Li, Chung 2005) şi a sistemelor de

regăsire a informaţiei (Grossman, Frieder 2004).

Clusterizarea partiţională

Cel mai utilizat algoritm partiţional este algoritmul k-means11

(MacQueen, 1967), care adevenit exponentul unei întregi categorii de

algoritmi. Popularitatea este dată de simplitatea implementării, scalabilitate,

eficienţă şi viteza de convergenţă (MacQueen, 1967).

Avantaje şi dezavantaje. Deşi k-means are marele avantaj că este uşor

de implementat şi eficient, are şi câteva mari neajunsuri. Primul dezavantaj

constă în aceea că poate fi foarte lent din moment ce în fiecare pas distanţa

dintre fiecare dată şi fiecare cluster trebuie calculată, afectând astfel timpul de

execuție. Al doilea dezavantaj este dat de faptul că aceată metodă e foarte

sensibilă la numărul şi iniţializarea clusterelor iniţiale, algoritmul putând să

furnizeze doar un optim local.

Clusterizarea ierarhică

Un alt tip de clusterizare este clusterizarea ierarhică care se bazează

pe o serie de algoritmi de clusterizare ierarhici ce au ca rezultat o ierarhie de

clustere numită dendrogramă12, adică un arbore care reflectă strucura

clusterelelor de date la diferite niveluri de similaritate. Aceasta se poate face

folosind:

Metode aglomerative de clusterizare – presupun o serie de fuziuni a

înregistrărilor inițiale din n clustere (câte înregistrări sunt) în grupuri din

ce în ce mai puține de înregistrări până când se obține numărul de

clustere dorit.

11 http://home.deib.polimi.it/matteucc/Clustering/tutorial_html/kmeans.html 12 http://www.totallab.com/products/samespots/support/faq/dendrogram.aspx

Algoritmul k-means (k, D)

Alege k date ca centroizi iniţiali (centrele clusterelor)

repeat

for each dată x D do

Calculează distanţa de la x la fiecare centroid;

Asociază x la cel mai apropiat centroid // centroidul reprezintă un cluster;

endfor


until criteriul de oprire este îndeplinit


59

Metode divizive de clusterizare – presupune că inițial toate înregistrările

fac parte dint-un singur cluster pe care apoi îl vor împărți în grupuri.

Exemplu de dendogramă:

Avantaje şi dezavantaje. Clusterizarea ierarhică are posibilitatea să

utilizeze orice funcţie distanţă sau similaritate. Un avantaj al acestei tehnici îl

reprezintă posibilitatea de a explora datele la diferite niveluri de granularitate,

Algoritmul Aglomerativ (D)

Inițializează fiecare dată din setul de date D ca fiind un cluster

Compute all pair-wise distances of x1, x2, ..., xn D;

Calculează toate distanțele pereche ale x1, x2, ..., xn D;

repet

Găsește două clustere care sunt cele mai apropiate unul de altul;

Combină cele două clustere și formează un cluster nou c;

Calculează distanța de la clusterul c la toate celelalte clustere;


until există doar un singur cluster rămas

a

b

c

d

e f

D A T E P R I M A R E

a b c d e f

b d

def

bcdef

abcdef

C L U S T E R I Z A R E I E R A R H I C Ă

Metode aglomerative

Metode divizive

59

Metode divizive de clusterizare – presupune că inițial toate înregistrările

fac parte dint-un singur cluster pe care apoi îl vor împărți în grupuri.

Exemplu de dendogramă:

Avantaje şi dezavantaje. Clusterizarea ierarhică are posibilitatea să

utilizeze orice funcţie distanţă sau similaritate. Un avantaj al acestei tehnici îl

reprezintă posibilitatea de a explora datele la diferite niveluri de granularitate,

Algoritmul Aglomerativ (D)

Inițializează fiecare dată din setul de date D ca fiind un cluster

Compute all pair-wise distances of x1, x2, ..., xn D;

Calculează toate distanțele pereche ale x1, x2, ..., xn D;

repet

Găsește două clustere care sunt cele mai apropiate unul de altul;

Combină cele două clustere și formează un cluster nou c;

Calculează distanța de la clusterul c la toate celelalte clustere;


until există doar un singur cluster rămas

a

b

c

d

e f

D A T E P R I M A R E

a b c d e f

b d

def

bcdef

abcdef

C L U S T E R I Z A R E I E R A R H I C Ă

Metode aglomerative

Metode divizive


60

deoarece se reţine toată ierarhia de clustere şi utilizatorul poate alege să

vizualizeze clusterele la orice nivel al arborelui. Unele studii au demonstrat că

clusterizarea ierarhică aglomerativă produce rezultate mai bune decât metoda

k-means, putând detecta clustere de forme arbitrare. Ca puncte slabe,

calitatea clustrizării ierarhice poate fi afectată de efectul de lanţ şi de datele

marginale. Principalele neajunsuri al metodelor de mai sus sunt date de

complexitatea de calcul şi cerinţele de spaţiu, ceea ce le face foarte neeficiente

şi nepractice pentru seturi mari de date, cum este Web-ul.

Tehnologiile descrise în cadrul acestui capitol sunt menite să faciliteze

procesarea datelor din surse multiple și transformarea acestora în informații

inteligibile și valoroase care sprijină procesul de luare a deciziilor. Indiferent de

gradul de complexitate prezentat, folosirea uneia dintre aceste tehnologii în

concordanță cu nevoile informaționale ale întreprinderii duce la creșterea

semnificativă a capacității de reacție la schimbările care au loc în mediul de

afaceri.

Totodată, trebuie să recunoaştem faptul că subiectul „tehnologiilor

informaţionale” nu se poate epuiza în 10 şi nici în 20 sau 30 de pagini, întrucât

acestea au o arie vastă de acţiune şi multiple forme de manifestare, dar scopul

nostru a fost acela de a evidenţia modalitatea şi importanţa acelora care îşi fac

pregnant prezenţa în domeniul asistării deciziilor de management.

60

deoarece se reţine toată ierarhia de clustere şi utilizatorul poate alege să

vizualizeze clusterele la orice nivel al arborelui. Unele studii au demonstrat că

clusterizarea ierarhică aglomerativă produce rezultate mai bune decât metoda

k-means, putând detecta clustere de forme arbitrare. Ca puncte slabe,

calitatea clustrizării ierarhice poate fi afectată de efectul de lanţ şi de datele

marginale. Principalele neajunsuri al metodelor de mai sus sunt date de

complexitatea de calcul şi cerinţele de spaţiu, ceea ce le face foarte neeficiente

şi nepractice pentru seturi mari de date, cum este Web-ul.

Tehnologiile descrise în cadrul acestui capitol sunt menite să faciliteze

procesarea datelor din surse multiple și transformarea acestora în informații

inteligibile și valoroase care sprijină procesul de luare a deciziilor. Indiferent de

gradul de complexitate prezentat, folosirea uneia dintre aceste tehnologii în

concordanță cu nevoile informaționale ale întreprinderii duce la creșterea

semnificativă a capacității de reacție la schimbările care au loc în mediul de

afaceri.

Totodată, trebuie să recunoaştem faptul că subiectul „tehnologiilor

informaţionale” nu se poate epuiza în 10 şi nici în 20 sau 30 de pagini, întrucât

acestea au o arie vastă de acţiune şi multiple forme de manifestare, dar scopul

nostru a fost acela de a evidenţia modalitatea şi importanţa acelora care îşi fac

pregnant prezenţa în domeniul asistării deciziilor de management.


61

CAPITOLUL III


STUDIU DE CAZ

Prin analogie cu sistemele informatice tranzacţionale care funcţionează

într-un mediu asigurat de Sistemele de Gestiune a Bazelor de Date (SGBD),

sistemele informatice de asistare a deciziei vor funcţiona într-un mediu creat

de un Sistem Suport pentru Decizii (SSD).

Realizarea sistemului suport are în vedere abordarea unor elemente cu

caracter tehnic în scopul construirii arhitecturii noului sistem, în mod gradat,

până la definirea efectivă a structurii fizice a bazei de date, a conţinutului bazei

de proceduri, a implementării serviciilor şi mecanismelor de securitate.

Literatura de specialitate13 identifică ca funcţii principale ale unui SSD:

managementul datelor, managementul modelelor, managementul cunoştinţelor

şi managementul dialogului între utilizator şi sistem pe de o parte şi între date,

modele şi cunoştinţe, pe de altă parte (vezi Figura 3.1).

Pe baza acestor funcţionalităţi, sistemul suport care ni l-am propus

pentru asistarea deciziei în managementul de portofoliu va cuprinde în

arhitectura sa, următoarele componente:

Managementul datelor;

Managementul modelelor;

Managementul interfeţelor şi a dialogurilor (interfaţa cu utilizatorul);

Managementul cunoştinţelor – o dată încorporat în arhitectura SSD

conferă acestuia atributul de inteligent, incluzând componente care

furnizează expertiza şi cunoştinţele necesare rezolvării unor probleme

rapide şi complexe.

13 Turban, E., Aronson, J. (2001). Decision Support Systems and Intelligent, Prentice

Hall, USA, page100

61

CAPITOLUL III


STUDIU DE CAZ

Prin analogie cu sistemele informatice tranzacţionale care funcţionează

într-un mediu asigurat de Sistemele de Gestiune a Bazelor de Date (SGBD),

sistemele informatice de asistare a deciziei vor funcţiona într-un mediu creat

de un Sistem Suport pentru Decizii (SSD).

Realizarea sistemului suport are în vedere abordarea unor elemente cu

caracter tehnic în scopul construirii arhitecturii noului sistem, în mod gradat,

până la definirea efectivă a structurii fizice a bazei de date, a conţinutului bazei

de proceduri, a implementării serviciilor şi mecanismelor de securitate.

Literatura de specialitate13 identifică ca funcţii principale ale unui SSD:

managementul datelor, managementul modelelor, managementul cunoştinţelor

şi managementul dialogului între utilizator şi sistem pe de o parte şi între date,

modele şi cunoştinţe, pe de altă parte (vezi Figura 3.1).

Pe baza acestor funcţionalităţi, sistemul suport care ni l-am propus

pentru asistarea deciziei în managementul de portofoliu va cuprinde în

arhitectura sa, următoarele componente:

Managementul datelor;

Managementul modelelor;

Managementul interfeţelor şi a dialogurilor (interfaţa cu utilizatorul);

Managementul cunoştinţelor – o dată încorporat în arhitectura SSD

conferă acestuia atributul de inteligent, incluzând componente care

furnizează expertiza şi cunoştinţele necesare rezolvării unor probleme

rapide şi complexe.

13 Turban, E., Aronson, J. (2001). Decision Support Systems and Intelligent, Prentice

Hall, USA, page100


62

Figura 3.1. - Structura generală a unui Sistem Suport Decizional

Fiecare dintre aceste componente vor fi considerate subsisteme

distincte, între care fluxul de date disponibile şi de cunoştinţe specifice vor

îmbunătăţi procesul de elaborare a deciziilor, conferind soluţii şi aspectelor

calitative, puternic nestructurate din cadrul domeniului bursier.

Totodată, intenţionăm ca pe parcursul acestui capitol să abordăm cu

exactitate fiecare subsistem precizat anterior, în funcţie de specificul

proceselor şi activităţilor pe care le presupune managementul de portofoliu.

pentru ca în finalul lucrării să putem folosii ©XTrade ca un veritabil sistem

interactiv de asistare a deciziei, funcţional şi viabil.

3.1. Definirea obiectivelor sistemului pentru asistarea

managementului de portofoliu

Realizarea unui Sistem suport pentru asistarea deciziei în managementul

de portofoliu are ca scop principal obţinerea unei imagini exhaustive şi corecte

a dinamicii pieţei în general sau a unui anumit derivat financiar, în special.

Informaţiile obţinute în urma prelucrării datelor primare sunt în primul rând

necesare managementului Bursei pentru stabilirea programelor de dezvoltare

a instituţiei şi, în al doilea rând obligatorii în vederea publicării acestora în

Date externe Date interne

Alte sisteme informatice

Internet Intranet Externet

MANAGEMENTUL DATELOR

GESTIUNEA

MODELELOR

GESTIUNEA

CUNOŞTINŢELOR

Modele

INTERFAŢA CU

UTILIZATORUL

Alte sisteme informatice UTILIZATOR

62

Figura 3.1. - Structura generală a unui Sistem Suport Decizional

Fiecare dintre aceste componente vor fi considerate subsisteme

distincte, între care fluxul de date disponibile şi de cunoştinţe specifice vor

îmbunătăţi procesul de elaborare a deciziilor, conferind soluţii şi aspectelor

calitative, puternic nestructurate din cadrul domeniului bursier.

Totodată, intenţionăm ca pe parcursul acestui capitol să abordăm cu

exactitate fiecare subsistem precizat anterior, în funcţie de specificul

proceselor şi activităţilor pe care le presupune managementul de portofoliu.

pentru ca în finalul lucrării să putem folosii ©XTrade ca un veritabil sistem

interactiv de asistare a deciziei, funcţional şi viabil.

3.1. Definirea obiectivelor sistemului pentru asistarea


Realizarea unui Sistem suport pentru asistarea deciziei în managementul

de portofoliu are ca scop principal obţinerea unei imagini exhaustive şi corecte

a dinamicii pieţei în general sau a unui anumit derivat financiar, în special.

Informaţiile obţinute în urma prelucrării datelor primare sunt în primul rând

necesare managementului Bursei pentru stabilirea programelor de dezvoltare

a instituţiei şi, în al doilea rând obligatorii în vederea publicării acestora în

Date externe Date interne

Alte sisteme informatice

Internet Intranet Externet

MANAGEMENTUL DATELOR

GESTIUNEA

MODELELOR

GESTIUNEA

CUNOŞTINŢELOR

Modele

INTERFAŢA CU

UTILIZATORUL

Alte sisteme informatice UTILIZATOR


63

mediile de informare din domeniul financiar, utile investitorilor pe piaţa

derivatelor financiare.

Analiza managementului de portofoliu, prin multitudinea de modele şi

metode folosite, dar şi volumul mare şi eterogen de date, reclamă dezvoltarea

unui sistem interactiv de asistare a deciziei axat pe analiza pieţei derivatelor

financiare, sistem care să răspundă în timp scurt şi cu efecte maxime,

necesităţilor decidentului pentru:

Construirea unui portofoliu strategic de active financiare derivate în

funcţie de performanţele înregistrate de acestea în „ringul Bursei”;

Comparaţia portofoliului strategic cu portofoliul constituit din activele

suport;

Analiza şi prognozarea evoluţiei cotaţiilor produselor financiare derivate

incluse în portofoliu;

Determinarea acelor indicatori şi oscilatori bursieri care asistă trader-ul

în activitatea de tranzacţionare;

Gestiunea ordinelor de vânzare/cumpărare emise ca urmare a derulării

operaţiunilor cu produse financiare derivate.

Cerinţele informaţionale legate de asistarea deciziei şi funcţiile sistemului

suport se bazează pe următoarele solicitări ale managementului de portofoliu:

Modernizarea actului decizional prin preluarea unor date exacte şi operative

furnizate de către sistemul suport;

Asigurarea unui optim global şi pe domenii de activitate, prin intermediul

unor decizii de management de tip tactic, strategic şi operativ;

Rentabilizarea activităţii de tranzacţionare din piaţa derivatelor;

Folosirea unor informaţii de excepţie pentru asigurarea echilibrului, a

stabilităţii Bursei ca sistem şi înscrierea sa în zona de rentabilitate

admisibilă;

Utilizarea datelor furnizate de către noul sistem într-o formă modernă de

informare: rapoarte, indicatori sintetici, grafice mixte, cu un conţinut

relevant, afişabile pe ecranele calculatoarelor;

Asigurarea proceselor decizionale de rutină prin intermediul prelucrărilor

noului sistem, inclusiv asigurarea unei coordonări a sistemului informaţional

şi a celui operant;

Asigurarea unui proces decizional ştiinţific, bazat pe modele matematice

statice şi dinamice dedicate proceselor specifice din domeniul

63

mediile de informare din domeniul financiar, utile investitorilor pe piaţa

derivatelor financiare.

Analiza managementului de portofoliu, prin multitudinea de modele şi

metode folosite, dar şi volumul mare şi eterogen de date, reclamă dezvoltarea

unui sistem interactiv de asistare a deciziei axat pe analiza pieţei derivatelor

financiare, sistem care să răspundă în timp scurt şi cu efecte maxime,

necesităţilor decidentului pentru:

Construirea unui portofoliu strategic de active financiare derivate în

funcţie de performanţele înregistrate de acestea în „ringul Bursei”;

Comparaţia portofoliului strategic cu portofoliul constituit din activele

suport;

Analiza şi prognozarea evoluţiei cotaţiilor produselor financiare derivate

incluse în portofoliu;

Determinarea acelor indicatori şi oscilatori bursieri care asistă trader-ul

în activitatea de tranzacţionare;

Gestiunea ordinelor de vânzare/cumpărare emise ca urmare a derulării

operaţiunilor cu produse financiare derivate.

Cerinţele informaţionale legate de asistarea deciziei şi funcţiile sistemului

suport se bazează pe următoarele solicitări ale managementului de portofoliu:

Modernizarea actului decizional prin preluarea unor date exacte şi operative

furnizate de către sistemul suport;

Asigurarea unui optim global şi pe domenii de activitate, prin intermediul

unor decizii de management de tip tactic, strategic şi operativ;

Rentabilizarea activităţii de tranzacţionare din piaţa derivatelor;

Folosirea unor informaţii de excepţie pentru asigurarea echilibrului, a

stabilităţii Bursei ca sistem şi înscrierea sa în zona de rentabilitate

admisibilă;

Utilizarea datelor furnizate de către noul sistem într-o formă modernă de

informare: rapoarte, indicatori sintetici, grafice mixte, cu un conţinut

relevant, afişabile pe ecranele calculatoarelor;

Asigurarea proceselor decizionale de rutină prin intermediul prelucrărilor

noului sistem, inclusiv asigurarea unei coordonări a sistemului informaţional

şi a celui operant;

Asigurarea unui proces decizional ştiinţific, bazat pe modele matematice

statice şi dinamice dedicate proceselor specifice din domeniul


64

managementului de portofoliu, precum şi utilizarea unor funcţii matematice

adaptabile acestui domeniu;

Urmare a solicitărilor formulate de managementul de portofoliu dar şi

cel al Bursei, sistemul suport decional stabileşte în mod concret următoarele

obiective, grupate în Tabelul 3.1.

Tabel 3.1. – Obiectivele sistemului suport decizional în funcție de solicitările


SOLICITĂRI management de

portofoliu

OBIECTIVE DESCRIERE

Manageriale Funcţionale

Stabilitatea, echilibrul sistemului

Determinarea stării şi comportamentului Bursei, ca sistem

transpunerea în practică a modelului Hicks folosit în studiul stabilităţii şi echilibrului sistemului;

identificarea variabilelor şi parametrilor care acţionează în sistem;

determinarea punctelor de echilibru şi a zonelor de stabilitate din cadrul sistemului;

Modernizarea actului

decizional

Decizii de construire a portofoliilor strategice

analiza istoricului cotaţiilor din piaţa derivatelor financiare şi a pieţei unde se tranzacţionează activele lor suport;

determinarea pentru fiecare contract futures şi/au opţiuni pe contracte futures a indicatorilor ce le caracterizează: rentabilitate, risc, volatilitate;

selecţia acelor derivate financiare care depăşesc punctul critic Ci

determinat de algoritmul „exces de randament”: - includerea în portofoliul strategic

a acelora care îndeplinesc condiţia exces de randament < Ci

- eliminarea celor care nu satisfac condiţia.

64

managementului de portofoliu, precum şi utilizarea unor funcţii matematice

adaptabile acestui domeniu;

Urmare a solicitărilor formulate de managementul de portofoliu dar şi

cel al Bursei, sistemul suport decional stabileşte în mod concret următoarele

obiective, grupate în Tabelul 3.1.

Tabel 3.1. – Obiectivele sistemului suport decizional în funcție de solicitările



portofoliu

OBIECTIVE DESCRIERE

Manageriale Funcţionale

Stabilitatea, echilibrul sistemului

Determinarea stării şi comportamentului Bursei, ca sistem

transpunerea în practică a modelului Hicks folosit în studiul stabilităţii şi echilibrului sistemului;

identificarea variabilelor şi parametrilor care acţionează în sistem;

determinarea punctelor de echilibru şi a zonelor de stabilitate din cadrul sistemului;

Modernizarea actului

decizional

Decizii de construire a portofoliilor strategice

analiza istoricului cotaţiilor din piaţa derivatelor financiare şi a pieţei unde se tranzacţionează activele lor suport;

determinarea pentru fiecare contract futures şi/au opţiuni pe contracte futures a indicatorilor ce le caracterizează: rentabilitate, risc, volatilitate;

selecţia acelor derivate financiare care depăşesc punctul critic Ci

determinat de algoritmul „exces de randament”: - includerea în portofoliul strategic

a acelora care îndeplinesc condiţia exces de randament < Ci

- eliminarea celor care nu satisfac condiţia.


65


portofoliu

OBIECTIVE DESCRIERE

Management portofoliu de produse financiare derivate

determinarea indicatorilor privind rentabilitatea, riscul, volatilitatea portofoliului strategic obţinut realizarea unor corelaţii între

rentabilitate şi risc, pentru contribuţia unui anumit produs la rentabilitatea/riscul portofoliului; comparaţie cu portofoliul alcătuit din

activele care constituie suportul derivatelor intrate în portofoliul strategic conform algoritmului.

Formă modernă de informare

generarea sub formă de rapoarte, indicatori, grafice a ieşirilor sistemului; posibilitatea realizării transmisiuni

date on-line; reprezentarea ieşirilor sistemului

într-o manieră care să satisfacă la maxim specificaţiile decidenţilor.

Coordonarea sistemului

informaţional cu cel operant

Integrarea sistemului

elaborarea unei Scheme directoare pentru obţinerea unei viziuni globale asupra sistemului;

definirea soluţiei de integrare în structura sistemului informatic general al Bursei.

Fundamentarea deciziilor prin

diverse modele matematice

dedicate proceselor decizionale

Asistarea deciziei într-un mediu informatizat

obţinerea prognozelor pentru evoluţiile cursurilor în piaţă folosind regresiile de diferite tipuri;

formularea unor modele matematice pentru fundamentarea deciziei de selecţie a produselor financiare derivate în funcţie de parametri esenţiali care-i definesc;

definirea din punct de vedere matematic a acelor indicatori şi oscilatori care asistă traderii în tranzacţiile din piaţă.

Rentabilizarea activităţii de

tranzacţionare

Realizarea gestiunii bursiere optimale

maximizarea profiturilor şi minimizarea riscurilor în contextul respectării totale a reglementărilor;

supervizarea tranzacţiilor bursiere.

65


portofoliu

OBIECTIVE DESCRIERE

Management portofoliu de produse financiare derivate

determinarea indicatorilor privind rentabilitatea, riscul, volatilitatea portofoliului strategic obţinut realizarea unor corelaţii între

rentabilitate şi risc, pentru contribuţia unui anumit produs la rentabilitatea/riscul portofoliului; comparaţie cu portofoliul alcătuit din

activele care constituie suportul derivatelor intrate în portofoliul strategic conform algoritmului.

Formă modernă de informare

generarea sub formă de rapoarte, indicatori, grafice a ieşirilor sistemului; posibilitatea realizării transmisiuni

date on-line; reprezentarea ieşirilor sistemului

într-o manieră care să satisfacă la maxim specificaţiile decidenţilor.

Coordonarea sistemului

informaţional cu cel operant

Integrarea sistemului

elaborarea unei Scheme directoare pentru obţinerea unei viziuni globale asupra sistemului;

definirea soluţiei de integrare în structura sistemului informatic general al Bursei.

Fundamentarea deciziilor prin

diverse modele matematice

dedicate proceselor decizionale

Asistarea deciziei într-un mediu informatizat

obţinerea prognozelor pentru evoluţiile cursurilor în piaţă folosind regresiile de diferite tipuri;

formularea unor modele matematice pentru fundamentarea deciziei de selecţie a produselor financiare derivate în funcţie de parametri esenţiali care-i definesc;

definirea din punct de vedere matematic a acelor indicatori şi oscilatori care asistă traderii în tranzacţiile din piaţă.

Rentabilizarea activităţii de

tranzacţionare

Realizarea gestiunii bursiere optimale

maximizarea profiturilor şi minimizarea riscurilor în contextul respectării totale a reglementărilor;

supervizarea tranzacţiilor bursiere.


66


portofoliu

OBIECTIVE DESCRIERE

Derularea operativă şi eficientă a tranzacţiilor

bursiere

deschiderea şedinţei de bursă; verificarea sumelor în cont; introducerea datelor din ordinele de

cumpărare şi/sau vânzare în sistemul automat de tranzacţionare şi alocare;

cumularea şi alocarea ordinelor de cumpărare şi/sau vânzare;

trimiterea rapoartelor la Agenţiile de Brokeraj;

confirmarea ordinelor de plată debitoare;

derularea operaţiunilor cu banca de decontare;

închiderea şedinţei de bursă.

3.2. Specificarea ieşirilor şi identificarea intrărilor sistemului suport

Intrările şi ieşirile specifice sistemului suport pentru asistarea deciziei au

în vedere particularităţile activităţilor desfăşurate pentru managementul de

portofoliu cu produse financiare derivate, cerinţele şi restricţiile precizate în

legislaţia Burselor, solicitările informaţionale ale sistemului de management,

particularităţile de organizare şi funcţionare ale Bursei, în corelaţie cu specificul

şi spiritul obiectivelor definite anterior.

Identificarea intrărilor şi specificarea ieşirilor sistemului suport constituie

o etapă esenţială în dezvoltarea oricărui sistem informatic. Este important ca

înainte de a trece la conceperea sistemului să se ştie cu exactitate ce trebuie

să obţinem şi de unde vom prelua datele necesare.

Răspunsuri vom găsi dacă analizăm cu atenţie solicitările

managementului care au stat la baza definirii obiectivelor sistem interactiv de

asistare a deciziilor. După cum se observă, am preferat varianta concordanţei

dintre ieşiri-intrări14, întrucât asigură determinarea conţinutului bazei

informaţionale în funcţie de obiectivele propuse, care se vor reflecta în situaţiile

de ieşire indiferent de forma pe care acestea o vor îmbrăca.

Ieşirile generate de sistemul suport pentru managementul portofoliului se

caracterizează prin reprezentativitate, relevanţă, exactitate, sintetizare şi

îmbracă forma: rapoartelor, situaţiilor centralizatoare, a indicatorilor sintetici, a

graficelor. Fiecare tip de ieşiri este definit prin anumite elemente particulare

14 Lungu I. şi colab. (1994). Sisteme informatice pentru conducere, Ed. SIAJ,

Bucureşti, pag.57

66


portofoliu

OBIECTIVE DESCRIERE

Derularea operativă şi eficientă a tranzacţiilor

bursiere

deschiderea şedinţei de bursă; verificarea sumelor în cont; introducerea datelor din ordinele de

cumpărare şi/sau vânzare în sistemul automat de tranzacţionare şi alocare;

cumularea şi alocarea ordinelor de cumpărare şi/sau vânzare;

trimiterea rapoartelor la Agenţiile de Brokeraj;

confirmarea ordinelor de plată debitoare;

derularea operaţiunilor cu banca de decontare;

închiderea şedinţei de bursă.

3.2. Specificarea ieşirilor şi identificarea intrărilor sistemului suport

Intrările şi ieşirile specifice sistemului suport pentru asistarea deciziei au

în vedere particularităţile activităţilor desfăşurate pentru managementul de

portofoliu cu produse financiare derivate, cerinţele şi restricţiile precizate în

legislaţia Burselor, solicitările informaţionale ale sistemului de management,

particularităţile de organizare şi funcţionare ale Bursei, în corelaţie cu specificul

şi spiritul obiectivelor definite anterior.

Identificarea intrărilor şi specificarea ieşirilor sistemului suport constituie

o etapă esenţială în dezvoltarea oricărui sistem informatic. Este important ca

înainte de a trece la conceperea sistemului să se ştie cu exactitate ce trebuie

să obţinem şi de unde vom prelua datele necesare.

Răspunsuri vom găsi dacă analizăm cu atenţie solicitările

managementului care au stat la baza definirii obiectivelor sistem interactiv de

asistare a deciziilor. După cum se observă, am preferat varianta concordanţei

dintre ieşiri-intrări14, întrucât asigură determinarea conţinutului bazei

informaţionale în funcţie de obiectivele propuse, care se vor reflecta în situaţiile

de ieşire indiferent de forma pe care acestea o vor îmbrăca.

Ieşirile generate de sistemul suport pentru managementul portofoliului se

caracterizează prin reprezentativitate, relevanţă, exactitate, sintetizare şi

îmbracă forma: rapoartelor, situaţiilor centralizatoare, a indicatorilor sintetici, a

graficelor. Fiecare tip de ieşiri este definit prin anumite elemente particulare

14 Lungu I. şi colab. (1994). Sisteme informatice pentru conducere, Ed. SIAJ,

Bucureşti, pag.57


67

care dirijează procesul de stabilire al formatului, structurii şi utilizării lor, pentru

obţinerea unor rezultate adaptate total la cerinţele managementului de

portofoliu. Aşadar, indicăm în Tabelul 3.2. ieşirile specifice sistemului suport,

pentru managementul portofoliului cu produse financiare derivate.

Tabel 3.2. - Ieşirile specifice sistemului suport, pentru managementul de portofoliu

TIP

IEŞIRE DENUMIRE COD DESCRIERE GENERALĂ

Indicatori

analitici

Rentabilitate

activ Ri

- exprimă oscilaţia preţului de cotare,

în valori absolute sau relative, între

2 şedinţe bursiere;

Risc activ σi

- se obţine fie ca dispersie a

rentabilităţilor seriei dinamice faţă

de rentabilitatea medie, fie ca

abatere medie pătratică a seriei

respective, interpretabilă ca o

creştere sau scădere a rentabilităţii,

în funcţie de valorile (pozitive,

respectiv negative) ale abaterilor

individuale.

Risc piaţă σM

- idem σi numai că se are în vedere

seria dinamică a rentabilităţii pieţei,

determinată şi ea în raport de

oscilaţia zilnică a indicelui general

al pieţei (indicele BET);

Volatilitate

activ βi

- coeficient desprins din ecuaţia

modelului de piaţă, important

deoarece furnizează informaţii

privind modificarea rentabilităţii

individuale a unui activ Ri, ca

urmare a modificării cu o unitate a

rentabilităţii generale a pieţei RM;

Indicatori

sintetici

Exces de

randament γi

- exprimă dezirabilitatea unui derivat

financiar în portofoliul strategic în

funcţie de relaţia existentă între risc

şi randament;

67

care dirijează procesul de stabilire al formatului, structurii şi utilizării lor, pentru

obţinerea unor rezultate adaptate total la cerinţele managementului de

portofoliu. Aşadar, indicăm în Tabelul 3.2. ieşirile specifice sistemului suport,

pentru managementul portofoliului cu produse financiare derivate.

Tabel 3.2. - Ieşirile specifice sistemului suport, pentru managementul de portofoliu

TIP


Indicatori

analitici

Rentabilitate

activ Ri

- exprimă oscilaţia preţului de cotare,

în valori absolute sau relative, între

2 şedinţe bursiere;

Risc activ σi

- se obţine fie ca dispersie a

rentabilităţilor seriei dinamice faţă

de rentabilitatea medie, fie ca

abatere medie pătratică a seriei

respective, interpretabilă ca o

creştere sau scădere a rentabilităţii,

în funcţie de valorile (pozitive,

respectiv negative) ale abaterilor

individuale.

Risc piaţă σM

- idem σi numai că se are în vedere

seria dinamică a rentabilităţii pieţei,

determinată şi ea în raport de

oscilaţia zilnică a indicelui general

al pieţei (indicele BET);

Volatilitate

activ βi

- coeficient desprins din ecuaţia

modelului de piaţă, important

deoarece furnizează informaţii

privind modificarea rentabilităţii

individuale a unui activ Ri, ca

urmare a modificării cu o unitate a

rentabilităţii generale a pieţei RM;

Indicatori

sintetici

Exces de

randament γi

- exprimă dezirabilitatea unui derivat

financiar în portofoliul strategic în

funcţie de relaţia existentă între risc

şi randament;


68

TIP


Punct critic Ci

- prag a cărui valoare trebuie

depăşită de valoarea indicatorului

γi determinată în parte pentru

fiecare produs financiar derivat

tranzacţionat în piaţă şi aflat în

sfera de interes al investitorului

şi/sau managerului de portofoliu;

%de investire xi

- investiţia relativă exprimată în % în

fiecare contract futures şi/sau

options;

Volatilitate

portofoliu βp

- media volatilităţii activelor din

portofoliu;

Rentabilitate

portofoliu Rp

- se exprimă ca medie a rentabilităţii

individuale ale tuturor activelor

selectate pentru a defini

componenţa portofoliului.

Indicatori

sintetici Risc portofoliu σp

- depinde de numărul de active

incluse în portofoliu, care urmare a

compensării variaţiilor contrare ale

riscurilor individuale ale activelor

selectate; se obţine ca urmare a

aplicării mediei ponderate a acestor

riscuri.

Rapoarte

Portofoliu

strategic PS

- cuprinde în structura sa acele

derivate financiare al căror γi

depăşeşte Ci, numai pentru acelea

determinându-se o serie de

indicatori specifici care vor asista

managementul de portofoliu.

Portofoliu de

active suport PAS

- se constituie numai pentru activele

suport ale derivatelor financiare

care au intrat în structura

portofoliului strategic; are mai mult

un caracter orientativ.

Diagnostic

produse

financiare

derivate

DPFD

- prezintă nivelul anumitor indicatori

bursieri cu scopul de a caracteriza

evoluţia pentru o anumită perioadă

de timp a derivatelor financiare din

structura portofoliului strategic.

68

TIP


Punct critic Ci

- prag a cărui valoare trebuie

depăşită de valoarea indicatorului

γi determinată în parte pentru

fiecare produs financiar derivat

tranzacţionat în piaţă şi aflat în

sfera de interes al investitorului

şi/sau managerului de portofoliu;

%de investire xi

- investiţia relativă exprimată în % în

fiecare contract futures şi/sau

options;

Volatilitate

portofoliu βp

- media volatilităţii activelor din

portofoliu;

Rentabilitate

portofoliu Rp

- se exprimă ca medie a rentabilităţii

individuale ale tuturor activelor

selectate pentru a defini

componenţa portofoliului.

Indicatori

sintetici Risc portofoliu σp

- depinde de numărul de active

incluse în portofoliu, care urmare a

compensării variaţiilor contrare ale

riscurilor individuale ale activelor

selectate; se obţine ca urmare a

aplicării mediei ponderate a acestor

riscuri.

Rapoarte

Portofoliu

strategic PS

- cuprinde în structura sa acele

derivate financiare al căror γi

depăşeşte Ci, numai pentru acelea

determinându-se o serie de

indicatori specifici care vor asista

managementul de portofoliu.

Portofoliu de

active suport PAS

- se constituie numai pentru activele

suport ale derivatelor financiare

care au intrat în structura

portofoliului strategic; are mai mult

un caracter orientativ.

Diagnostic

produse

financiare

derivate

DPFD

- prezintă nivelul anumitor indicatori

bursieri cu scopul de a caracteriza

evoluţia pentru o anumită perioadă

de timp a derivatelor financiare din

structura portofoliului strategic.


69

TIP


Diagnostic

active suport DAS

- idem DPFD, de data aceasta fiind

vorba de activele suport pentru

derivatele financiare incluse în

portofoliul strategic.

Situaţii

centralizat

oare

Raport de

tranzacţionare RT

- sintetizează tranzacţiile efectuate în

piaţă de trader, pe tipuri de ordine,

pe zile, pe tipuri de contracte

futures şi/sau options.

Centralizator

ordine bursă CO

- colaţionează Ordinele de bursă

emise de trader, pentru a se stabili

cotaţiile în şedinţele de bursă.

Sumarul

tranzacţiilor ST

- centralizează tranzacţiile din piaţă

pe zile sau pe tipuri de contracte.

Grafice

Evoluţia

cotaţiilor G1

- indică trendul cotaţiilor derivatelor

financiare într-o perioadă

specificată.

Oscilatorii

bursieri G2 - indică sensul de evoluţiei al pieţei.

Conţinutul informaţional al rapoartelor şi situaţiilor centralizatoare este

prezentată sub forma Tabelelor 3.2. – 3.9., pentru elaborarea acestora

folosindu-se ca sursă de informare documentaţia pentru sistemul de

tranzacţionare al Bursei.

Tabel 3.2. – Conținut informațional Diagnostic pentru produsele financiare

derivate (cod situaţie: DPFD)

Tip Simbol Rentabilitate Risc Volatilitate

C(10) C(5) N(5) N(5) N(5)

69

TIP


Diagnostic

active suport DAS

- idem DPFD, de data aceasta fiind

vorba de activele suport pentru

derivatele financiare incluse în

portofoliul strategic.

Situaţii

centralizat

oare

Raport de

tranzacţionare RT

- sintetizează tranzacţiile efectuate în

piaţă de trader, pe tipuri de ordine,

pe zile, pe tipuri de contracte

futures şi/sau options.

Centralizator

ordine bursă CO

- colaţionează Ordinele de bursă

emise de trader, pentru a se stabili

cotaţiile în şedinţele de bursă.

Sumarul

tranzacţiilor ST

- centralizează tranzacţiile din piaţă

pe zile sau pe tipuri de contracte.

Grafice

Evoluţia

cotaţiilor G1

- indică trendul cotaţiilor derivatelor

financiare într-o perioadă

specificată.

Oscilatorii

bursieri G2 - indică sensul de evoluţiei al pieţei.

Conţinutul informaţional al rapoartelor şi situaţiilor centralizatoare este

prezentată sub forma Tabelelor 3.2. – 3.9., pentru elaborarea acestora

folosindu-se ca sursă de informare documentaţia pentru sistemul de

tranzacţionare al Bursei.

Tabel 3.2. – Conținut informațional Diagnostic pentru produsele financiare

derivate (cod situaţie: DPFD)

Tip Simbol Rentabilitate Risc Volatilitate

C(10) C(5) N(5) N(5) N(5)


70

Tabel 3.3. – Conținut informațional Diagnostic active suport

(cod situaţie: PAS)

Activ suport

Simbol Rentabilitate Risc Volatilitate

C(10) C(5) N(5) N(5) N(5)

Tabel 3.4. – Conținut informațional Portofoliul strategic de produse

financiare derivate (cod situaţie: PS)

Simbol Rentabilitate Risc Volatilitate Risc

piaţă

Exces de

randament

%

investire

xi

C(5) N(5) N(5) N(5) N(5) N(5) N(5)

PORTOFOLIU

RP σP βP

Tabel 3.5. – Conținut informațional Raport de tranzacţionare

(cod situaţie: RT)

Data Cotaţie Variaţie Tranzacţii Cantitate Volum

C(10) N(5) N(10) N(4) N(4) N(15)

Tabel 3.6. – Conținut informațional Centralizator ordine (cod situaţie: CO)

Ordine de bursă

Client Valoare

Cont pentru

care s-a

executat ordinul

Marja

în cont Data Nr. Tip

D(8) N(6) C(2) C(15) N(10) N(15) N(10)

Tabel 3.6. – Conținut informațional Portofoliul de active suport


70

Tabel 3.3. – Conținut informațional Diagnostic active suport


Activ suport

Simbol Rentabilitate Risc Volatilitate

C(10) C(5) N(5) N(5) N(5)

Tabel 3.4. – Conținut informațional Portofoliul strategic de produse

financiare derivate (cod situaţie: PS)

Simbol Rentabilitate Risc Volatilitate Risc

piaţă

Exces de

randament

%

investire

xi

C(5) N(5) N(5) N(5) N(5) N(5) N(5)

PORTOFOLIU

RP σP βP

Tabel 3.5. – Conținut informațional Raport de tranzacţionare

(cod situaţie: RT)

Data Cotaţie Variaţie Tranzacţii Cantitate Volum

C(10) N(5) N(10) N(4) N(4) N(15)

Tabel 3.6. – Conținut informațional Centralizator ordine (cod situaţie: CO)

Ordine de bursă

Client Valoare

Cont pentru

care s-a

executat ordinul

Marja

în cont Data Nr. Tip

D(8) N(6) C(2) C(15) N(10) N(15) N(10)

Tabel 3.6. – Conținut informațional Portofoliul de active suport



71

Simbol Rentab

Ri Risc σi

Risc

piaţă

σM

Volatilitate

βi

Exces de

randament

% investire

xi

C(5) N(5) N(5) N(5) N(5) N(5) N(5)

EURO

USD

JPY

SIF1

SNP

PORTOFOLIU

RP σP βP

Tabel 3.6. – Conținut informațional Sumarul tranzacţiilor

(cod situaţie: ST)

Data …Data…….

Tip derivat şi scadenţa ………C(25)…………

Număr

contracte

Preţ de

cotare

Cumpărător Vânzător Document

N(4) N(5) C(15) C(15) N(4)

TOTAL *

Preţ deschidere

Preţ închidere

Preţ maxim

Preţ minim

Variaţie

71

Simbol Rentab

Ri Risc σi

Risc

piaţă

σM

Volatilitate

βi

Exces de

randament

% investire

xi

C(5) N(5) N(5) N(5) N(5) N(5) N(5)

EURO

USD

JPY

SIF1

SNP

PORTOFOLIU

RP σP βP

Tabel 3.6. – Conținut informațional Sumarul tranzacţiilor

(cod situaţie: ST)

Data …Data…….

Tip derivat şi scadenţa ………C(25)…………

Număr

contracte

Preţ de

cotare

Cumpărător Vânzător Document

N(4) N(5) C(15) C(15) N(4)

TOTAL *

Preţ deschidere

Preţ închidere

Preţ maxim

Preţ minim

Variaţie


72

Tabel 3.6. – Conținut informațional Centralizator tranzacţii (cod situaţie: CT)

Ordin de bursa

Simb

ol

Cotaţi

e

Cantitat

e

Volu

m

Scadenţ

a

Clien

t

Dat

a

Nr. Tip

D(8) N(6

)

C(2

)

C(4) N(8.4

)

N(6) N(10

)

D(8) C(15)

Pe baza interpretării datelor şi indicatorilor din rapoarte şi situaţiile

centralizatoare managerul (traderul şi/sau brokerul) pot lua diverse tipuri de

decizii, după cum urmează:

în raport cu gradul de certitudine al datelor şi al indicatorilor distingem:

decizii cu caracter cert – datele şi indicatorii conţinuţi sunt siguri,

deciziile din această categorie având un grad maxim de siguranţă şi

verosimilitate (este cazul RT, CO, ST, SC);

decizii cu caracter incert – se iau pe baza unor date probabile cu un

anumit grad de relativitate, elemente ce nu oferă o siguranţă deplină

în luarea deciziilor; de fapt, aceste decizii se iau în condiţii de risc al

operaţiunilor, deoarece datele şi indicatorii folosiţi pentru

fundamentare au un anumit caracter de probabilitate (DPFD, DAS);

în raport cu factorul decizional, pot fi emise decizii de tipul:

decizii computerizate – fundamentate prin intermediul prelucrării

colecţiei de date proprii sistemului interactiv, prin intermediul

programelor; în plus, dacă sistemul suport conţine o bază de

cunoştinţe, atunci se pot folosii elemente decizionale care implică

determinarea soluţiilor prin calcule şi modelare matematică, folosindu-

se însă şi intuiţia şi preferinţele utilizatorilor (este cazul indicatorilor

analitici şi sintetici);

decizii umane – secondează deciziile computerizate, fiind emise de

manager pe baza datelor şi indicatorilor bursieri afişaţi în rapoartele

de ieşire; aceste tipuri de decizii se bazează pe experienţă, intuiţie şi,

uneori, chiar pe preferinţele decidenţilor umani (este cazul PS, PAS);.

Pentru a asigura obţinerea unor rapoarte şi/sau situaţii centralizatoare cu

un conţinut informaţional ca cel specificat prin Tabelele 3.2. – 3.9. sursa

72

Tabel 3.6. – Conținut informațional Centralizator tranzacţii (cod situaţie: CT)

Ordin de bursa

Simb

ol

Cotaţi

e

Cantitat

e

Volu

m

Scadenţ

a

Clien

t

Dat

a

Nr. Tip

D(8) N(6

)

C(2

)

C(4) N(8.4

)

N(6) N(10

)

D(8) C(15)

Pe baza interpretării datelor şi indicatorilor din rapoarte şi situaţiile

centralizatoare managerul (traderul şi/sau brokerul) pot lua diverse tipuri de

decizii, după cum urmează:

în raport cu gradul de certitudine al datelor şi al indicatorilor distingem:

decizii cu caracter cert – datele şi indicatorii conţinuţi sunt siguri,

deciziile din această categorie având un grad maxim de siguranţă şi

verosimilitate (este cazul RT, CO, ST, SC);

decizii cu caracter incert – se iau pe baza unor date probabile cu un

anumit grad de relativitate, elemente ce nu oferă o siguranţă deplină

în luarea deciziilor; de fapt, aceste decizii se iau în condiţii de risc al

operaţiunilor, deoarece datele şi indicatorii folosiţi pentru

fundamentare au un anumit caracter de probabilitate (DPFD, DAS);

în raport cu factorul decizional, pot fi emise decizii de tipul:

decizii computerizate – fundamentate prin intermediul prelucrării

colecţiei de date proprii sistemului interactiv, prin intermediul

programelor; în plus, dacă sistemul suport conţine o bază de

cunoştinţe, atunci se pot folosii elemente decizionale care implică

determinarea soluţiilor prin calcule şi modelare matematică, folosindu-

se însă şi intuiţia şi preferinţele utilizatorilor (este cazul indicatorilor

analitici şi sintetici);

decizii umane – secondează deciziile computerizate, fiind emise de

manager pe baza datelor şi indicatorilor bursieri afişaţi în rapoartele

de ieşire; aceste tipuri de decizii se bazează pe experienţă, intuiţie şi,

uneori, chiar pe preferinţele decidenţilor umani (este cazul PS, PAS);.

Pentru a asigura obţinerea unor rapoarte şi/sau situaţii centralizatoare cu

un conţinut informaţional ca cel specificat prin Tabelele 3.2. – 3.9. sursa


73

datelor necesare obţinerii lor, o constituie intrările necesare sistemului suport

concretizate în:

Lista cotaţiilor – este sursa majorităţii situaţiilor de ieşire şi de fapt este

vorba de mai multe liste nu de una singură, deoarece cotaţiile se referă la

preţul de cotare al produselor financiare derivate şi al activelor lor suport. La

rândul lor, derivatele financiare se grupează în două categorii: contracte

futures şi options ş.a.m.d. Pentru a nu crea ambiguitate, prezentăm schematic

prin Figura 3.2. tipologia cotaţiilor din sistem şi rapoartele cărora acestea le

furnizează date de intrare, iar prin Tabelul 3.6. modelul informaţional.

Tabel 3.6. – Conținut informațional al documentului

Lista Cotaţiilor (cod situaţie: LC) -

Lista cotaţiilor pentru ………………….

Data Preţ

închidere Preţ

deschidere Cotaţie Max Min

Nr. tranzacţii

Volum

73

datelor necesare obţinerii lor, o constituie intrările necesare sistemului suport

concretizate în:

Lista cotaţiilor – este sursa majorităţii situaţiilor de ieşire şi de fapt este

vorba de mai multe liste nu de una singură, deoarece cotaţiile se referă la

preţul de cotare al produselor financiare derivate şi al activelor lor suport. La

rândul lor, derivatele financiare se grupează în două categorii: contracte

futures şi options ş.a.m.d. Pentru a nu crea ambiguitate, prezentăm schematic

prin Figura 3.2. tipologia cotaţiilor din sistem şi rapoartele cărora acestea le

furnizează date de intrare, iar prin Tabelul 3.6. modelul informaţional.

Tabel 3.6. – Conținut informațional al documentului

Lista Cotaţiilor (cod situaţie: LC) -

Lista cotaţiilor pentru ………………….

Data Preţ

închidere Preţ

deschidere Cotaţie Max Min

Nr. tranzacţii

Volum


74

Figura 3.2. - Tipologia cotaţiilor

Rentabilitate activ Ri Volatilitate activ βi Risc activ σi Risc piaţă σm

INDICATORI analitici

DPFD

SC

DAS

Exces de randament γi Punctul critic ci %de investire xi Rentabilitate portofoliu Rm Volatilitate activ βi

Risc portofoliu σi

INDICATORI sintetici

PS PAS

Valute RolUsd RolEuro EuroUsd UsdJpy

Indicele pieţei

Acţiuni DESIF1 DESIF3 DESNP

Dobânzi BUBOR

DERIVATE FINANCIARE

Activul fără risc AF

BET

ACTIVE SUPORT

Valute Usd Euro Yen

Acţiuni SIF1 SIF3 SNP

Dobânzi

Bubor

L

I

S

T

A

C

O

T

A

Ţ

I

I

L

O

R

Contracte futures

Options

GRAFICE

74

Figura 3.2. - Tipologia cotaţiilor

Rentabilitate activ Ri Volatilitate activ βi Risc activ σi Risc piaţă σm

INDICATORI analitici

DPFD

SC

DAS

Exces de randament γi Punctul critic ci %de investire xi Rentabilitate portofoliu Rm Volatilitate activ βi

Risc portofoliu σi

INDICATORI sintetici

PS PAS


Indicele pieţei


Dobânzi BUBOR

DERIVATE FINANCIARE


BET

ACTIVE SUPORT

Valute Usd Euro Yen

Acţiuni SIF1 SIF3 SNP

Dobânzi

Bubor

L

I

S

T

A

C

O

T

A

Ţ

I

I

L

O

R

Contracte futures

Options

GRAFICE


75

Ordinul de bursă – în funcţie de tipul tranzacţiei iniţiat în piaţă este de 2

feluri: Ordin de vânzare şi Ordin de cumpărare. Indiferent de tip, ordinul este

acceptat la tranzacţionare dacă conţine cel puţin următoarele informaţii: tip

ordin, simbol şi descrierea derivatului financiar tranzacţionat, cantitatea, preţ

limită (în lipsă se consideră cel mai bun preţ al pieţei), perioada de valabilitate,

contul pentru care se execută ordinul.

În Figura 3.3 precizăm modalitatea prin care acest document de intrare

alimentează cu date anumite rapoarte, iar în Tabelul 3.7. este prezentat

modelul informaţional exact în forma în care sistemul va prelua datele de

intrare pentru a le prelucra.

Figura 3.3. – Ordinul de bursă: alimentarea cu date din OV şi OC,

direcţionarea informaţiilor către RT,CO,ST

Tabel 3.7. – Conținut informațional al documentului Ordin de Bursă (cod situaţie: OV/OC)

Simbol contract

Preţ Cant Perioada de valabilitate a ordinului

Client Contul pentru

care se execută ordinul

ST

CO

RT Ordin de

vânzare OV

Ordin de cumpărare OC

O R D I N de BURS

Ă

75

Ordinul de bursă – în funcţie de tipul tranzacţiei iniţiat în piaţă este de 2

feluri: Ordin de vânzare şi Ordin de cumpărare. Indiferent de tip, ordinul este

acceptat la tranzacţionare dacă conţine cel puţin următoarele informaţii: tip

ordin, simbol şi descrierea derivatului financiar tranzacţionat, cantitatea, preţ

limită (în lipsă se consideră cel mai bun preţ al pieţei), perioada de valabilitate,

contul pentru care se execută ordinul.

În Figura 3.3 precizăm modalitatea prin care acest document de intrare

alimentează cu date anumite rapoarte, iar în Tabelul 3.7. este prezentat

modelul informaţional exact în forma în care sistemul va prelua datele de

intrare pentru a le prelucra.

Figura 3.3. – Ordinul de bursă: alimentarea cu date din OV şi OC,

direcţionarea informaţiilor către RT,CO,ST

Tabel 3.7. – Conținut informațional al documentului Ordin de Bursă (cod situaţie: OV/OC)

Simbol contract

Preţ Cant Perioada de valabilitate a ordinului

Client Contul pentru

care se execută ordinul

ST

CO

RT Ordin de

vânzare OV

Ordin de cumpărare OC

O R D I N de BURS

Ă


77

3.3.1. Baza de date pentru managementul datelor. Modelul obiectelor.

Modelul dinamic. Modelul funcţional

Sistemul interactiv de asistare a deciziilor, pe care dorim să-l dezvoltăm

în cele ce urmează, pentru definitivarea obiectivelor sale, realizează extracţii

de date din surse interne ale Bursei şi/sau externe acesteia (este vorba de

cotaţiile de la Bursa de Valori Bucureşti), constituindu-şi în cele din urmă, o

bază de date proprie.

Referindu-ne la baza de date a sistemului informatic al BMFMS, analizată

în urma documentării în cadrul Departamentului Informatic, precizăm că

aceasta este construită în conformitate cu principiile modelului relaţional,

prezentând următoarele caracteristici arhicunoscute:

datele sunt reprezentate sub forma unor colecţii de tabele

bidimensionale;

relaţiile dintre tabele sunt exprimate prin valori stocate în tabele, SQL

oferind posibilitatea de a crea dinamic relaţii între date;

datele din tabelele bazei de date respectă prima formă normală.

Deşi modelul de date relaţional folosit are un fundament teoretic foarte

puternic şi câteva puncte tari: simplitate, oportunitate pentru prelucrarea on-

line a tranzacţiilor, suport pentru independenţa datelor, totuşi prezintă multe

puncte slabe care conduc la o reprezentare insuficientă a entităţilor din „lumea

reală” (Ştefănescu L., Ungureanu L., Ştefănescu A. 2004)

Având în vedere solicitările managementului portofoliului (Tabelul 3.1.)

va trebui să construim o aplicaţie software robustă pe care să se sprijine întreg

sistemul suport de asistare a deciziei pe care ni l-am propus spre dezvoltare.

Limbajul C++ este o gazdă perfectă pentru aplicaţiile de acest fel, şi totodată

un bun mediu de implementare a bazelor de date orientate obiect.

Asocierea: baze de date relaţionale - limbaje de programare orientate

spre obiecte, permite desprinderea unor diferenţe care reduc complexitatea şi

facilitând în acelaşi timp utilizarea puternicilor caracteristici ale limbajului:

încapsularea, moştenirea şi polimorfismul. Atunci când am subliniat diferenţele,

ne-am referit la:

diferenţe în sistemul de tipuri de date – semnificând faptul că în cazul

BDR, furnizorul bazei de date este cel care stabileşte tipurile de date, cei

care dezvoltă aplicaţii asupra BDR nu au posibilitatea de a-şi crea

propriile lor tipuri, ca în cazul modelului obiect, în funcţie de necesităţi;

77

3.3.1. Baza de date pentru managementul datelor. Modelul obiectelor.

Modelul dinamic. Modelul funcţional

Sistemul interactiv de asistare a deciziilor, pe care dorim să-l dezvoltăm

în cele ce urmează, pentru definitivarea obiectivelor sale, realizează extracţii

de date din surse interne ale Bursei şi/sau externe acesteia (este vorba de

cotaţiile de la Bursa de Valori Bucureşti), constituindu-şi în cele din urmă, o

bază de date proprie.

Referindu-ne la baza de date a sistemului informatic al BMFMS, analizată

în urma documentării în cadrul Departamentului Informatic, precizăm că

aceasta este construită în conformitate cu principiile modelului relaţional,

prezentând următoarele caracteristici arhicunoscute:

datele sunt reprezentate sub forma unor colecţii de tabele

bidimensionale;

relaţiile dintre tabele sunt exprimate prin valori stocate în tabele, SQL

oferind posibilitatea de a crea dinamic relaţii între date;

datele din tabelele bazei de date respectă prima formă normală.

Deşi modelul de date relaţional folosit are un fundament teoretic foarte

puternic şi câteva puncte tari: simplitate, oportunitate pentru prelucrarea on-

line a tranzacţiilor, suport pentru independenţa datelor, totuşi prezintă multe

puncte slabe care conduc la o reprezentare insuficientă a entităţilor din „lumea

reală” (Ştefănescu L., Ungureanu L., Ştefănescu A. 2004)

Având în vedere solicitările managementului portofoliului (Tabelul 3.1.)

va trebui să construim o aplicaţie software robustă pe care să se sprijine întreg

sistemul suport de asistare a deciziei pe care ni l-am propus spre dezvoltare.

Limbajul C++ este o gazdă perfectă pentru aplicaţiile de acest fel, şi totodată

un bun mediu de implementare a bazelor de date orientate obiect.

Asocierea: baze de date relaţionale - limbaje de programare orientate

spre obiecte, permite desprinderea unor diferenţe care reduc complexitatea şi

facilitând în acelaşi timp utilizarea puternicilor caracteristici ale limbajului:

încapsularea, moştenirea şi polimorfismul. Atunci când am subliniat diferenţele,

ne-am referit la:

diferenţe în sistemul de tipuri de date – semnificând faptul că în cazul

BDR, furnizorul bazei de date este cel care stabileşte tipurile de date, cei

care dezvoltă aplicaţii asupra BDR nu au posibilitatea de a-şi crea

propriile lor tipuri, ca în cazul modelului obiect, în funcţie de necesităţi;


78

diferenţe de limbaj - în modelul relaţional, singurul limbaj folosit este

SQL, dar acesta va rezolva toate problemele: stocarea, analiza şi

regăsirea datelor. SQL nu este un limbaj orientat spre obiecte, neavând

un suport real pentru încapsulare, moştenire şi polimorfism. În modelul

obiect putem folosi limbajul C++ pentru a defini propriile tipuri de date,

pentru a scrie cod care să opereze asupra instanţelor claselor de obiecte,

pentru a crea ierarhii complexe şi reţele de obiecte legate unele de altele.

diferenţe de paradigmă:

modelul relaţional reprezintă lumea ca pe un set de tabele

bidimensionale, datele care nu pot fi reprezentate cu uşurinţă în

formă tabelară pot fi cu greu modelate într-o BDR;

modelul obiectual încearcă să mimeze obiectele din lumea reală, caz

în care nu va trebui să modelăm datele astfel încât să respecte

modelul obiect, ci să realizăm obiecte care să mimeze sau să

reproducă atributele şi caracteristicile din lumea reală.

Astfel, diferenţa de paradigmă devine clară: în cazul modelului relaţional

datele trebuie adaptate astfel încât să corespundă modelului, iar în ceea ce

priveşte modelul obiectual, modelul este cel care se adaptează în funcţie

de date.

diferenţe legate de entităţi elementare de date – semnificând faptul că

între entităţile elementare de date ale celor două modele nu există

corespondenţă. În modelul obiect, entitatea elementară este clasa, în

timp ce în modelul relaţional entitatea elementară este câmpul, iar clasele

de obiecte nu pot fi mapate la câmpuri, ci la tabele.

Toate acestea recomandă folosirea modelului de date orientat obiect

pentru dezvoltarea aplicaţiei de susţinere a managementului de portofoliu,

alegerea tehnologiei fiind impusă de specificitatea acestui domeniu.

Diferenţele sesizate şi eventualele dificultăţi care pot apărea la

interfaţarea modelului relaţional cu modelul obiect s-au transformat în

argumente solide pentru orientarea obiect a bazei de date existent, folosind

tehnica mapării relaţional/obiect.

Deoarece fundamentul aplicaţiei noastre îl constituie baza de date

relaţională implementată prin sistemul informatic al BMFMS, sensul mapării va

fi de la relaţional spre obiectual, speculând punctele similare care există între

cele două abordări, identificate prin Tabelul 3.8.

78

diferenţe de limbaj - în modelul relaţional, singurul limbaj folosit este

SQL, dar acesta va rezolva toate problemele: stocarea, analiza şi

regăsirea datelor. SQL nu este un limbaj orientat spre obiecte, neavând

un suport real pentru încapsulare, moştenire şi polimorfism. În modelul

obiect putem folosi limbajul C++ pentru a defini propriile tipuri de date,

pentru a scrie cod care să opereze asupra instanţelor claselor de obiecte,

pentru a crea ierarhii complexe şi reţele de obiecte legate unele de altele.

diferenţe de paradigmă:

modelul relaţional reprezintă lumea ca pe un set de tabele

bidimensionale, datele care nu pot fi reprezentate cu uşurinţă în

formă tabelară pot fi cu greu modelate într-o BDR;

modelul obiectual încearcă să mimeze obiectele din lumea reală, caz

în care nu va trebui să modelăm datele astfel încât să respecte

modelul obiect, ci să realizăm obiecte care să mimeze sau să

reproducă atributele şi caracteristicile din lumea reală.

Astfel, diferenţa de paradigmă devine clară: în cazul modelului relaţional

datele trebuie adaptate astfel încât să corespundă modelului, iar în ceea ce

priveşte modelul obiectual, modelul este cel care se adaptează în funcţie

de date.

diferenţe legate de entităţi elementare de date – semnificând faptul că

între entităţile elementare de date ale celor două modele nu există

corespondenţă. În modelul obiect, entitatea elementară este clasa, în

timp ce în modelul relaţional entitatea elementară este câmpul, iar clasele

de obiecte nu pot fi mapate la câmpuri, ci la tabele.

Toate acestea recomandă folosirea modelului de date orientat obiect

pentru dezvoltarea aplicaţiei de susţinere a managementului de portofoliu,

alegerea tehnologiei fiind impusă de specificitatea acestui domeniu.

Diferenţele sesizate şi eventualele dificultăţi care pot apărea la

interfaţarea modelului relaţional cu modelul obiect s-au transformat în

argumente solide pentru orientarea obiect a bazei de date existent, folosind

tehnica mapării relaţional/obiect.

Deoarece fundamentul aplicaţiei noastre îl constituie baza de date

relaţională implementată prin sistemul informatic al BMFMS, sensul mapării va

fi de la relaţional spre obiectual, speculând punctele similare care există între

cele două abordări, identificate prin Tabelul 3.8.


79

Tabelul 3.8 – Maparea modelului relațional la modelul orientat obiect

Modelul

orientat obiect

Modelul

relaţional Descriere

Obiect Entitate Obiectul este o entitate cu propria sa

identitate.

Atribute Atribute -

Asocieri Relaţii

Asocierile sunt aceleaşi, în modelarea

obiectuală moştenirea include atât starea

cât şi comportamentul;

Mesaje - Conceptul nu are corespondent pentru

modelul relaţional

Procese Prelucrări Un proces transformă datele şi sunt în

mod uzual implementate ca metode

Clase Tipuri de

entităţi

Clasa descrie o mulţime de obiecte cu

proprietăţi, comportament şi relaţii similare

Instanţe Entităţi -

Încapsulare - Conceptul nu are corespondent pentru

modelul relaţional

Similitudinea existentă, face ca modelul Entitate-Relaţie şi descrierea sa

prezentate în documentaţia de proiectare conceptuală a bazei de date a

BMFMS, să prezinte o bază rezonabilă pentru metodologia de proiectare a

bazei de date proprii sistemului, care va fi orientată spre obiecte. Astfel, după

ce au fost descrise complet intrările şi ieşirile sistemului, se construieşte

modelul de date orientat obiect corespunzător cerinţelor impuse de asistarea

de către calculator a managementului operaţiunilor cu produse financiare

derivate.

Modelul obiectelor

În construirea modelului obiectelor va trebui să parcurgem pas cu pas,

etapele specifice proiectării orientate obiect a bazelor de date (Schach, 2006).

În acest sens, vom proceda la:

Identificarea claselor candidate

O clasă de obiecte corespunde semantic unui concept din sistemul real

ce urmează a fi modelat.

Reprezentarea unei clase trebuie să indice ansamblul de atribute ce

formează structura sa, operaţiile ce-i definesc comportamentul şi relaţiile cu

79

Tabelul 3.8 – Maparea modelului relațional la modelul orientat obiect

Modelul

orientat obiect

Modelul

relaţional Descriere

Obiect Entitate Obiectul este o entitate cu propria sa

identitate.

Atribute Atribute -

Asocieri Relaţii

Asocierile sunt aceleaşi, în modelarea

obiectuală moştenirea include atât starea

cât şi comportamentul;

Mesaje - Conceptul nu are corespondent pentru

modelul relaţional

Procese Prelucrări Un proces transformă datele şi sunt în

mod uzual implementate ca metode

Clase Tipuri de

entităţi

Clasa descrie o mulţime de obiecte cu

proprietăţi, comportament şi relaţii similare

Instanţe Entităţi -

Încapsulare - Conceptul nu are corespondent pentru

modelul relaţional

Similitudinea existentă, face ca modelul Entitate-Relaţie şi descrierea sa

prezentate în documentaţia de proiectare conceptuală a bazei de date a

BMFMS, să prezinte o bază rezonabilă pentru metodologia de proiectare a

bazei de date proprii sistemului, care va fi orientată spre obiecte. Astfel, după

ce au fost descrise complet intrările şi ieşirile sistemului, se construieşte

modelul de date orientat obiect corespunzător cerinţelor impuse de asistarea

de către calculator a managementului operaţiunilor cu produse financiare

derivate.

Modelul obiectelor

În construirea modelului obiectelor va trebui să parcurgem pas cu pas,

etapele specifice proiectării orientate obiect a bazelor de date (Schach, 2006).

În acest sens, vom proceda la:

Identificarea claselor candidate

O clasă de obiecte corespunde semantic unui concept din sistemul real

ce urmează a fi modelat.

Reprezentarea unei clase trebuie să indice ansamblul de atribute ce

formează structura sa, operaţiile ce-i definesc comportamentul şi relaţiile cu


80

alte elemente ale modelului. Utilizăm şi noi simbolul recomandat pentru

reprezentarea grafică a clasei de obiecte, care delimitează trei zone: una

rezervată numelui, alta atributelor şi ultima operaţiilor (vezi Figura 3.5.).

Figura 3.5. - Reprezentarea grafică a unei clase de obiecte

Vom începe prin a identifica principalele tipuri de clase candidate la

modelul obiectelor din specificaţia cerinţelor şi formularea obiectivelor

sistemului suport pentru asistarea deciziei. În mod normal, acest lucru se face

identificând toate substantivele din textul formulării obiectivelor, a solicitărilor

impuse şi funcţiunilor propuse, realizând o clasă pentru fiecare substantiv.

Acestea ar putea fi:

Contracte futures Opţiuni pe contracte futures

Active suport Cotaţii derivate financiare

Cotaţii contracte futures Trader Ordine

Cotaţii active suport Cotaţii options Manager

Clienţi Portofoliu Operaţiune

BMFMS16 Date Alocare

Agenţie de brokeraj Broker Tranzacţii

Păstrarea claselor corecte

Dintre clasele identificate se trece la eliminarea clasele incorecte, adică a

acelora care se încadrează în categoria:

- clase redundante ↔ 2 clase care exprimă aceleaşi informaţii. De exemplu:

Cotaţii contracte futures şi Cotaţii options sunt clase redundante deoarece

16 Bursa Monetar – Financiară şi de Mărfuri Sibiu

nume clasă

atribute

operaţii

COTAŢII DERIVATE

Atribute Atribut: tip Atribut: tip = valoare iniţială

Operaţii Operaţii (listă de argumente): tip

80

alte elemente ale modelului. Utilizăm şi noi simbolul recomandat pentru

reprezentarea grafică a clasei de obiecte, care delimitează trei zone: una

rezervată numelui, alta atributelor şi ultima operaţiilor (vezi Figura 3.5.).

Figura 3.5. - Reprezentarea grafică a unei clase de obiecte

Vom începe prin a identifica principalele tipuri de clase candidate la

modelul obiectelor din specificaţia cerinţelor şi formularea obiectivelor

sistemului suport pentru asistarea deciziei. În mod normal, acest lucru se face

identificând toate substantivele din textul formulării obiectivelor, a solicitărilor

impuse şi funcţiunilor propuse, realizând o clasă pentru fiecare substantiv.

Acestea ar putea fi:

Contracte futures Opţiuni pe contracte futures

Active suport Cotaţii derivate financiare

Cotaţii contracte futures Trader Ordine

Cotaţii active suport Cotaţii options Manager

Clienţi Portofoliu Operaţiune

BMFMS16 Date Alocare

Agenţie de brokeraj Broker Tranzacţii

Păstrarea claselor corecte

Dintre clasele identificate se trece la eliminarea clasele incorecte, adică a

acelora care se încadrează în categoria:

- clase redundante ↔ 2 clase care exprimă aceleaşi informaţii. De exemplu:

Cotaţii contracte futures şi Cotaţii options sunt clase redundante deoarece

16 Bursa Monetar – Financiară şi de Mărfuri Sibiu

nume clasă

atribute

operaţii

COTAŢII DERIVATE

Atribute Atribut: tip Atribut: tip = valoare iniţială

Operaţii Operaţii (listă de argumente): tip


81

exprimă aceleaşi noţiuni ca şi, clasa Cotaţii derivate financiare fapt pentru

care vor fi excluse;

- clase irelevante ↔ clase care nu aduc nici o informaţie necesară în

modelarea problemei. De exemplu: clasa BMFMS descrie mai degrabă

întregul sistem şi nu aduce nici o informaţie în procesul de modelare;

- clase vagi ↔ clase care nu sunt definite clar. De exemplu: clasele Date,

Manager;

- atribute ↔ sunt identificate clase care iniţial descriu obiecte individuale, dar

care pot fi reformulate în termeni de atribute ale altor clase şi nu se vor

păstra (nu este cazul);

- operaţii ↔ au fost identificate clase care de fapt descriu operaţii care se

aplică obiectelor şi nu vor fi păstrate în construirea modelului. De exemplu

clasa Alocare este o operaţie care se aplică clasei Ordine, Tranzacţii,

TraderX.

Descrierea fiecărei clase de obiecte pentru a elimina eventualele interpretări cu

privire la entităţile modelate.

Dicţionarul de date pentru clasele de obiecte rămase în urma selecţiei

este reprezentat în formă tabelară mai jos:

Tabelul 3.9. – Dicționarul de date.

CLASA DE

OBIECTE DESCRIERE

Contracte

futures

- contract standardizat care prevede cumpărarea /vânzarea unui

anumit activ la un preţ stabilit în momentul tranzacţiei, dar cu

lichidarea sa la o dată viitoare

Opţiuni pe

contracte futures

- contracte standardizate care prevede dreptul dar nu şi obligaţia

de a achiziţiona la scadenţă sau oricând până la scadenţă la preţ

de exercitare şi în schimbul unei prime

Active suport17 - titluri de valoare concretizate în acţiuni: SIF1, SIF3, SNP,

obligaţiuni, valute: Euro, Dolar USD, yen JPY

Cotaţii derivate

financiare

- preţul la care se tranzacţionează într-o zi derivatele financiare în

„ringul BMFMS”

Cotaţii active

suport

- preţul la care se tranzacţionează într-o zi activele suport în

„ringul BVB”

17 este vorba numai de activele cotate la BVB şi care constituie suportul produselor financiare derivate tranzacţionate la BMFMS

81

exprimă aceleaşi noţiuni ca şi, clasa Cotaţii derivate financiare fapt pentru

care vor fi excluse;

- clase irelevante ↔ clase care nu aduc nici o informaţie necesară în

modelarea problemei. De exemplu: clasa BMFMS descrie mai degrabă

întregul sistem şi nu aduce nici o informaţie în procesul de modelare;

- clase vagi ↔ clase care nu sunt definite clar. De exemplu: clasele Date,

Manager;

- atribute ↔ sunt identificate clase care iniţial descriu obiecte individuale, dar

care pot fi reformulate în termeni de atribute ale altor clase şi nu se vor

păstra (nu este cazul);

- operaţii ↔ au fost identificate clase care de fapt descriu operaţii care se

aplică obiectelor şi nu vor fi păstrate în construirea modelului. De exemplu

clasa Alocare este o operaţie care se aplică clasei Ordine, Tranzacţii,

TraderX.

Descrierea fiecărei clase de obiecte pentru a elimina eventualele interpretări cu

privire la entităţile modelate.

Dicţionarul de date pentru clasele de obiecte rămase în urma selecţiei

este reprezentat în formă tabelară mai jos:

Tabelul 3.9. – Dicționarul de date.

CLASA DE

OBIECTE DESCRIERE

Contracte

futures

- contract standardizat care prevede cumpărarea /vânzarea unui

anumit activ la un preţ stabilit în momentul tranzacţiei, dar cu

lichidarea sa la o dată viitoare

Opţiuni pe

contracte futures

- contracte standardizate care prevede dreptul dar nu şi obligaţia

de a achiziţiona la scadenţă sau oricând până la scadenţă la preţ

de exercitare şi în schimbul unei prime

Active suport17 - titluri de valoare concretizate în acţiuni: SIF1, SIF3, SNP,

obligaţiuni, valute: Euro, Dolar USD, yen JPY

Cotaţii derivate

financiare

- preţul la care se tranzacţionează într-o zi derivatele financiare în

„ringul BMFMS”

Cotaţii active

suport

- preţul la care se tranzacţionează într-o zi activele suport în

„ringul BVB”

17 este vorba numai de activele cotate la BVB şi care constituie suportul produselor financiare derivate tranzacţionate la BMFMS


82

Tranzacţii - operaţiuni de vânzare şi/sau cumpărare derulate în piaţă

Trader - persoană autorizată de Bursă să tranzacţioneze în nume propriu

şi pe contul lor în piaţa derivatelor financiare

Broker

- persoane fizice, angajaţi ai membrilor Bursei, ce au în atribuţia

lor exclusiv licitarea ofertelor de vânzare/cumpărare în numele

unei agenţii de brokeraj

Ordine - documentul în baza căruia traderul iniţiază operaţiuni de

vânzare/cumpărare

Clienţi - persoană fizică/juridică care derulează prin intermediul brokerilor

operaţiuni de vânzare/cumpărare în ringul bursei

Portofoliu

- grupează la un loc activele financiare deoarece performanţele

managementului cresc dacă acestea sunt urmărite pe ansamblu şi

nu individual

Identificarea asocierilor

Asocierile exprimă existenţa de corelaţii semantice între clasele de

obiecte. O instanţă a unei asocieri este numită legătură (link) şi este un tuplu

de realizări ale obiectelor corespunzătoare. În cazul nostru, se pot forma

următoarele asocieri:

Contractele futures sunt cotate zilnic la BMFMS

Opţiunile pe contracte futures sunt cotate zilnic la BMFMS

Activele suport sunt cotate zilnic la BVB

Cotaţii derivate financiare sunt vizualizate de Brokeri şi/sau Traderi

Cotaţii active suport sunt vizualizate de Brokeri şi/sau Traderi

Ordinele generează Tranzacţii

Traderi derulează Tranzacţii

Brokeri derulează Tranzacţii

Ordinele sunt emise de Clienţi

Ordinele sunt tranzacţionate de Trader/Broker

Clienţi emit Ordine de vânzare/cumpărare

Asocierea se reprezintă printr-o linie continuă între clasele de obiecte

corespunzătoare şi poate avea un nume şi un sens, cu scopul de a specifica

proprietăţile clasei respective la asociere, respectiv: multiplicitatea, ordonarea,

navigabilitatea, vizibilitatea şi modificabilitatea.

82

Tranzacţii - operaţiuni de vânzare şi/sau cumpărare derulate în piaţă

Trader - persoană autorizată de Bursă să tranzacţioneze în nume propriu

şi pe contul lor în piaţa derivatelor financiare

Broker

- persoane fizice, angajaţi ai membrilor Bursei, ce au în atribuţia

lor exclusiv licitarea ofertelor de vânzare/cumpărare în numele

unei agenţii de brokeraj

Ordine - documentul în baza căruia traderul iniţiază operaţiuni de

vânzare/cumpărare

Clienţi - persoană fizică/juridică care derulează prin intermediul brokerilor

operaţiuni de vânzare/cumpărare în ringul bursei

Portofoliu

- grupează la un loc activele financiare deoarece performanţele

managementului cresc dacă acestea sunt urmărite pe ansamblu şi

nu individual

Identificarea asocierilor

Asocierile exprimă existenţa de corelaţii semantice între clasele de

obiecte. O instanţă a unei asocieri este numită legătură (link) şi este un tuplu

de realizări ale obiectelor corespunzătoare. În cazul nostru, se pot forma

următoarele asocieri:

Contractele futures sunt cotate zilnic la BMFMS

Opţiunile pe contracte futures sunt cotate zilnic la BMFMS

Activele suport sunt cotate zilnic la BVB

Cotaţii derivate financiare sunt vizualizate de Brokeri şi/sau Traderi

Cotaţii active suport sunt vizualizate de Brokeri şi/sau Traderi

Ordinele generează Tranzacţii

Traderi derulează Tranzacţii

Brokeri derulează Tranzacţii

Ordinele sunt emise de Clienţi

Ordinele sunt tranzacţionate de Trader/Broker

Clienţi emit Ordine de vânzare/cumpărare

Asocierea se reprezintă printr-o linie continuă între clasele de obiecte

corespunzătoare şi poate avea un nume şi un sens, cu scopul de a specifica

proprietăţile clasei respective la asociere, respectiv: multiplicitatea, ordonarea,

navigabilitatea, vizibilitatea şi modificabilitatea.


83

În Figura 3.6 este reprezentată, pentru exemplificare, asocierea care

exprimă legătura dintre Traderi/Brokeri şi Portofoliul strategic pe care aceştia

doresc să-l obţină. Unul sau mai mulţi (1…*) Traderi/Brokeri pot vizualiza una

sau mai multe (1…*) cotaţii pentru derivatele financiare şi/sau activele suport.

Vizualizând cotaţiile, unul sau mai mulţi (1…*) Traderi/Brokeri pe baza unui

algoritm definit pot constitui portofolii. Portofoliu, nu este o clasă propriu-zisă ci

este o asociere - clasă care posedă proprietăţile unei clase: atribute, operaţii,

sau alte asocieri proprii. Multiplicitatea în această asociere este (1…2) .

Valoarea 1 a multiplicităţii exprimă aici sintagma „constituie un portofoliu” de

produse financiare derivate sau/şi un portofoliu de active suport, deci maxim 2.

Al doilea portofoliu este constituit numai pentru a ilustra o situaţie comparativă

în managementul operaţiunilor cu produse financiare derivate.

Figura 3.6. - Reprezentarea grafică a asocierilor dintre clasele Traderi/Brokeri şi

Portofoliu

Pentru reprezentarea grafică se foloseşte simbolul uzual de clasă,

conectat printr-o linie întreruptă la asocierea respectivă, numele fiind acelaşi

pentru asociere cât şi pentru clasa prin care se realizează.

În metodologia de proiectare a bazei de date pusă a dispoziţie de

Departamentul Informatică, se observă că în modelul ER, relaţiile de tip mulţi –

1..2 BROKERI

………..

………….

COTAŢII Derivate

………..

……….

COTAŢII active suport

………..

…………….

constituie portofoliu►

vizualizează ► 1..* 1..* 1..*

1..2

vizualizează ► 1..* 1..*

1..* constituie portofoliu►

PORTOFOLIU

……….. ……………..

TRADERI

………

…

………..

83

În Figura 3.6 este reprezentată, pentru exemplificare, asocierea care

exprimă legătura dintre Traderi/Brokeri şi Portofoliul strategic pe care aceştia

doresc să-l obţină. Unul sau mai mulţi (1…*) Traderi/Brokeri pot vizualiza una

sau mai multe (1…*) cotaţii pentru derivatele financiare şi/sau activele suport.

Vizualizând cotaţiile, unul sau mai mulţi (1…*) Traderi/Brokeri pe baza unui

algoritm definit pot constitui portofolii. Portofoliu, nu este o clasă propriu-zisă ci

este o asociere - clasă care posedă proprietăţile unei clase: atribute, operaţii,

sau alte asocieri proprii. Multiplicitatea în această asociere este (1…2) .

Valoarea 1 a multiplicităţii exprimă aici sintagma „constituie un portofoliu” de

produse financiare derivate sau/şi un portofoliu de active suport, deci maxim 2.

Al doilea portofoliu este constituit numai pentru a ilustra o situaţie comparativă

în managementul operaţiunilor cu produse financiare derivate.

Figura 3.6. - Reprezentarea grafică a asocierilor dintre clasele Traderi/Brokeri şi

Portofoliu

Pentru reprezentarea grafică se foloseşte simbolul uzual de clasă,

conectat printr-o linie întreruptă la asocierea respectivă, numele fiind acelaşi

pentru asociere cât şi pentru clasa prin care se realizează.

În metodologia de proiectare a bazei de date pusă a dispoziţie de

Departamentul Informatică, se observă că în modelul ER, relaţiile de tip mulţi –

1..2 BROKERI

………..

………….

COTAŢII Derivate

………..

……….

COTAŢII active suport

………..

…………….

constituie portofoliu►

vizualizează ► 1..* 1..* 1..*

1..2

vizualizează ► 1..* 1..*

1..* constituie portofoliu►

PORTOFOLIU

……….. ……………..

TRADERI

………

…

………..


84

la – mulţi şi relaţiile recursive18 au fost îndepărtate, iar toate relaţiile ternare

sau n-are, s-au descompus în relaţii binare. Aceste schimbări nu sunt

necesare pentru modelarea orientată spre obiecte şi pot fi omise. Modificările

au fost introduse datorită puterii de modelare limitate a modelelor de date

tradiţionale.

Identificarea atributelor

Starea curentă a unui obiect este descrisă de unul sau mai multe

atribute sau de variabile de instanţă. Notaţia generală a atributelor este:

vizibilitate nume [multiplicitate] : tip_date = valoare_iniţială {listă proprietăţi}

unde: vizibilitate poate lua una din valorile: + (atribut public), – (atribut

privat, respectând principiul încapsulării), # (atribut

protejat);

[multiplicitate] : indică faptul că atributul respectiv poate avea mai multe

valori. Referindu-ne la numărul de cotaţii pentru un

contract futurea şi/sau options într-o lună de tranzacţii

(excepţie zilele de sâmbătă şi duminică): #Cotaţie

[0…22]: Currency precizează că atributul protejat

Cotaţie poate avea de la 0 la 22 valori diferite de tip

monetar, multiplicitatea 0 indicând că este permisă şi

absenţa valorii pentru acest atribut, respectiv valoarea

null;

: tip_date indică natura datelor în termenii specifici unui anumit

limbaj;

= valoare_iniţială expresie a cărei valoare este atribuită automat în

momentul creării unui obiect din clasa respectivă;

{listă proprietăţi} este o listă de proprietăţi suplimentare atributului;

În procesul de proiectare putem întâlni şi notaţii în genul:

contracte futures.scadenţa ↔ care indică faptul că scadenţa este un

atribut al obiectului contracte futures

După analiza obiectelor se pot asocia acestora următoarele atribute,

respectând modul de reprezentare al acestora într-o clasă (Figura 3.7):

18 sunt numite şi asocieri reflexive exprimând legături între obiecte ale aceleaşi clase

84

la – mulţi şi relaţiile recursive18 au fost îndepărtate, iar toate relaţiile ternare

sau n-are, s-au descompus în relaţii binare. Aceste schimbări nu sunt

necesare pentru modelarea orientată spre obiecte şi pot fi omise. Modificările

au fost introduse datorită puterii de modelare limitate a modelelor de date

tradiţionale.

Identificarea atributelor

Starea curentă a unui obiect este descrisă de unul sau mai multe

atribute sau de variabile de instanţă. Notaţia generală a atributelor este:

vizibilitate nume [multiplicitate] : tip_date = valoare_iniţială {listă proprietăţi}

unde: vizibilitate poate lua una din valorile: + (atribut public), – (atribut

privat, respectând principiul încapsulării), # (atribut

protejat);

[multiplicitate] : indică faptul că atributul respectiv poate avea mai multe

valori. Referindu-ne la numărul de cotaţii pentru un

contract futurea şi/sau options într-o lună de tranzacţii

(excepţie zilele de sâmbătă şi duminică): #Cotaţie

[0…22]: Currency precizează că atributul protejat

Cotaţie poate avea de la 0 la 22 valori diferite de tip

monetar, multiplicitatea 0 indicând că este permisă şi

absenţa valorii pentru acest atribut, respectiv valoarea

null;

: tip_date indică natura datelor în termenii specifici unui anumit

limbaj;

= valoare_iniţială expresie a cărei valoare este atribuită automat în

momentul creării unui obiect din clasa respectivă;

{listă proprietăţi} este o listă de proprietăţi suplimentare atributului;

În procesul de proiectare putem întâlni şi notaţii în genul:

contracte futures.scadenţa ↔ care indică faptul că scadenţa este un

atribut al obiectului contracte futures

După analiza obiectelor se pot asocia acestora următoarele atribute,

respectând modul de reprezentare al acestora într-o clasă (Figura 3.7):

18 sunt numite şi asocieri reflexive exprimând legături între obiecte ale aceleaşi clase


85

Figura 3.7. – Reprezentarea obiectelor şi a atributelor corespunzătoare

Ulterior, acestea mai pot fi modificate în funcţie de o serie de elemente

noi care pot fi descoperite în etapa de analiză, de aceea este bine să:

- se acorde o importanţă mai mare atributelor principale, deoarece

ulterior acestea se vor rafina;

- se ignore atributele derivate;

- se precizeze atributele referinţă, similare cheilor străine din modelul

relaţional.

Ţinând cont de recomandările anterioare se va alcătui dicţionarul

atributelor prin care vom stabili toate detaliile descriptive ale fiecărui atribut,

indiferent de apartenenţa sa la un anume tip de clasă sau de asociere. Astfel

Active suport

simbol denumire

Cotaţii derivate

simbol; data cotaţiei preţ deschidere; preţ cotare; preţ închidere; preţ minim; preţ maxim cantitate

Cotaţii active suport

simbol; data cotaţiei; preţ cotare; ultimul preţ; max52; min52; volum

Trader

cod trader nume

Broker

cod broker nume;ABK

Ordine

număr ordin; tip ordin; data ordin cod; broker/ trader; simbol; cantitate preţ de cotare scadenţa; cont client

Clienţi

cod client denumire adresa cod ABK cod broker

Portofoliu

Simbol; preţ_cotare; scadenţa

Opţiuni pe contracte futures

simbol; unitate tranzacţionare; cotare primă; pasul primei; luna de iniţiere; scadenţa; preţ de exercitare; risc; lichidare

Tranzacţii

număr tranzacţii data tranzacţiei cod trader/ broker; simbol; cantitate; preţ număr ordin v/c

Contracte futures

simbol; unitate tranzacţionare; preţ de cotare; pas de cotare; luna de iniţiere; risc; scadenţa; lichidare

85

Figura 3.7. – Reprezentarea obiectelor şi a atributelor corespunzătoare

Ulterior, acestea mai pot fi modificate în funcţie de o serie de elemente

noi care pot fi descoperite în etapa de analiză, de aceea este bine să:

- se acorde o importanţă mai mare atributelor principale, deoarece

ulterior acestea se vor rafina;

- se ignore atributele derivate;

- se precizeze atributele referinţă, similare cheilor străine din modelul

relaţional.

Ţinând cont de recomandările anterioare se va alcătui dicţionarul

atributelor prin care vom stabili toate detaliile descriptive ale fiecărui atribut,

indiferent de apartenenţa sa la un anume tip de clasă sau de asociere. Astfel

Active suport

simbol denumire

Cotaţii derivate

simbol; data cotaţiei preţ deschidere; preţ cotare; preţ închidere; preţ minim; preţ maxim cantitate

Cotaţii active suport

simbol; data cotaţiei; preţ cotare; ultimul preţ; max52; min52; volum

Trader

cod trader nume

Broker

cod broker nume;ABK

Ordine

număr ordin; tip ordin; data ordin cod; broker/ trader; simbol; cantitate preţ de cotare scadenţa; cont client

Clienţi

cod client denumire adresa cod ABK cod broker

Portofoliu

Simbol; preţ_cotare; scadenţa

Opţiuni pe contracte futures

simbol; unitate tranzacţionare; cotare primă; pasul primei; luna de iniţiere; scadenţa; preţ de exercitare; risc; lichidare

Tranzacţii

număr tranzacţii data tranzacţiei cod trader/ broker; simbol; cantitate; preţ număr ordin v/c

Contracte futures

simbol; unitate tranzacţionare; preţ de cotare; pas de cotare; luna de iniţiere; risc; scadenţa; lichidare


86

pentru fiecare atribut se va stabili identificatorul asociat în mod unic la nivelul

întregii baze de date, tipul, lungimea şi condiţiile de validare, toate aceste

elemente fiind stabilite în funcţie de cerinţele şi restricţiile impuse de sistemul

de gestiune al datelor.

În aceste condiţii, dicţionarul atributelor asociat claselor de obiecte deja

identificate este prezentat sub forma Tabelului 3.10.

Tabelului 3.10 - Dicţionarul atributelor

Denumire Identi-

ficator

Tip,

lung

ime

Condiţii de validare Clasa de obiecte în

care-l regăsim

simbol derivat financiar

simbol C,4 simbol < > ’’

COTAŢIE, DERIVAT,

TRANZACŢIE,

PORTOFOLIU

unitate de

tranzacţionare unit_tranz N,4

1< = unit_tranz < =

1000 PFD

Preţ de cotare cotaţie N,10 cotaţie > 0

COTAŢIE, ORDINV,

ORDINC,COTAŢIEPF,

COTAŢIEAS,

TRANZACŢIE,

CONTRACT FUTURES

pas de cotare pas_cotare N,4 1< pas_cotare < =

1000 CONTRACT FUTURES

luna de

iniţiere luna_i C,9

luna_i = {ian, martie,

iulie, decmbrie} CONTRACT FUTURES

risc creştere/ scădere

risc N,5 risc > 0 PFD

lichidare lichidare C,9

lichidare ={ianuarie,

martie, iulie,

decembrie}

CONTRACT FUTURES

data cotării data_cotaţie D,8 data_cotaţie >

01.01.90 COTAŢIE

preţ deschidere

preţ_desch N,10 preţ_desch > 0 COTAŢIEPFD

preţ închidere preţ_înch N,10 preţ_înch > 0 COTAŢIEPFD

preţ minim preţ_min N,10 preţ_min > 0 COTAŢIEPFD

preţ maxim preţ_max N,10 preţ_max > 0 COTAŢIEPFD

număr de tranzacţii

nr_tranz N,10 nr_tranz > 0 COTAŢIE,

TRANZACŢIE

cotare primă cotare_prim

ă N,10 cotare_primă > 0 Options

pasul primei pas_prima N,10 pas_prima > 0 OPTIONS

86

pentru fiecare atribut se va stabili identificatorul asociat în mod unic la nivelul

întregii baze de date, tipul, lungimea şi condiţiile de validare, toate aceste

elemente fiind stabilite în funcţie de cerinţele şi restricţiile impuse de sistemul

de gestiune al datelor.

În aceste condiţii, dicţionarul atributelor asociat claselor de obiecte deja

identificate este prezentat sub forma Tabelului 3.10.

Tabelului 3.10 - Dicţionarul atributelor

Denumire Identi-

ficator

Tip,

lung

ime


care-l regăsim

simbol derivat financiar

simbol C,4 simbol < > ’’

COTAŢIE, DERIVAT,

TRANZACŢIE,

PORTOFOLIU

unitate de

tranzacţionare unit_tranz N,4

1< = unit_tranz < =

1000 PFD

Preţ de cotare cotaţie N,10 cotaţie > 0

COTAŢIE, ORDINV,

ORDINC,COTAŢIEPF,

COTAŢIEAS,

TRANZACŢIE,

CONTRACT FUTURES

pas de cotare pas_cotare N,4 1< pas_cotare < =

1000 CONTRACT FUTURES

luna de

iniţiere luna_i C,9

luna_i = {ian, martie,

iulie, decmbrie} CONTRACT FUTURES

risc creştere/ scădere

risc N,5 risc > 0 PFD

lichidare lichidare C,9

lichidare ={ianuarie,

martie, iulie,

decembrie}

CONTRACT FUTURES

data cotării data_cotaţie D,8 data_cotaţie >

01.01.90 COTAŢIE

preţ deschidere

preţ_desch N,10 preţ_desch > 0 COTAŢIEPFD

preţ închidere preţ_înch N,10 preţ_înch > 0 COTAŢIEPFD

preţ minim preţ_min N,10 preţ_min > 0 COTAŢIEPFD

preţ maxim preţ_max N,10 preţ_max > 0 COTAŢIEPFD

număr de tranzacţii

nr_tranz N,10 nr_tranz > 0 COTAŢIE,

TRANZACŢIE

cotare primă cotare_prim

ă N,10 cotare_primă > 0 Options

pasul primei pas_prima N,10 pas_prima > 0 OPTIONS


87

Denumire Identi-

ficator

Tip,

lung

ime


care-l regăsim

preţ de exercitare

preţ_exerc N,10 preţ_exerc > 0 OPTIONS

scadenţa scadenţa C,9 scadenţa ={ian, mart,

iulie, dec} PFD

cod client cod_cl N,10 cod_cl > 0 CLIENT

tip operator tip_oper C,6 cont_cl < > ’’ OPERATOR

cont client cont_cl C,15 cont_cl < > ’’ CLIENT, ORDINV,

ORDINC

denumire client

den_cl C,15 den_cl < > ’’ CLIENT

adresa client adresa_cl C,20 adresa_cl < > ’’ CLIENT

cod Agenţie Brokeraj

cod_ABK C,6 cod_ABK < > ’’ ABK

număr ordin nr_ordin N,4 nr_ordin > 0

ORDIN, ORDINV,

ORDINC,

TRANZACŢIE

tip ordin tip_ordin C,2 tip_ordin = { „V” or

„C”} ORDIN

data ordin data_ordin D,8 data_ordin >

01.01.90 ORDIN

cod broker cod_brk N,5 cod_brk > 0 ORDIN, BROKER,

OPERATOR

cod trader cod_trd N,5 cod_trd > 0 ORDIN, TRADER,

OPERATOR

tip derivat tip_drv C,3 tip_drv = { „CF” or

„OPT”} COTAŢIE

cantitate cantitate N,4 cantitate > 0 ORDINV, ORDINC,

TRANZACŢIE

denumire derivat financiar

den_drv C,15 den_drv < > ’’ COTAŢIE

nume broker nume_brk C,15 nume_brk < > ’’ BROKER

nume trader nume_trd C,15 nume_trd < > ’’ TRADER

denumire Agenţie brokeraj

ABK C,15 ABK < > ’’ ABK, BROKER

ultimul preţ preţ_ultim N,10 preţ_ultim > 0 COTAŢIE AS

maxim ultimele 52 cotaţii

Max52 N,10 Max52 > 0 COTAŢIE AS

minim ultimele 52 cotaţii

Min52 N,10 Min52 > 0 COTAŢIE AS

87

Denumire Identi-

ficator

Tip,

lung

ime


care-l regăsim

preţ de exercitare

preţ_exerc N,10 preţ_exerc > 0 OPTIONS

scadenţa scadenţa C,9 scadenţa ={ian, mart,

iulie, dec} PFD

cod client cod_cl N,10 cod_cl > 0 CLIENT

tip operator tip_oper C,6 cont_cl < > ’’ OPERATOR

cont client cont_cl C,15 cont_cl < > ’’ CLIENT, ORDINV,

ORDINC

denumire client

den_cl C,15 den_cl < > ’’ CLIENT

adresa client adresa_cl C,20 adresa_cl < > ’’ CLIENT

cod Agenţie Brokeraj

cod_ABK C,6 cod_ABK < > ’’ ABK

număr ordin nr_ordin N,4 nr_ordin > 0

ORDIN, ORDINV,

ORDINC,

TRANZACŢIE

tip ordin tip_ordin C,2 tip_ordin = { „V” or

„C”} ORDIN

data ordin data_ordin D,8 data_ordin >

01.01.90 ORDIN

cod broker cod_brk N,5 cod_brk > 0 ORDIN, BROKER,

OPERATOR

cod trader cod_trd N,5 cod_trd > 0 ORDIN, TRADER,

OPERATOR

tip derivat tip_drv C,3 tip_drv = { „CF” or

„OPT”} COTAŢIE

cantitate cantitate N,4 cantitate > 0 ORDINV, ORDINC,

TRANZACŢIE

denumire derivat financiar

den_drv C,15 den_drv < > ’’ COTAŢIE

nume broker nume_brk C,15 nume_brk < > ’’ BROKER

nume trader nume_trd C,15 nume_trd < > ’’ TRADER

denumire Agenţie brokeraj

ABK C,15 ABK < > ’’ ABK, BROKER

ultimul preţ preţ_ultim N,10 preţ_ultim > 0 COTAŢIE AS

maxim ultimele 52 cotaţii

Max52 N,10 Max52 > 0 COTAŢIE AS

minim ultimele 52 cotaţii

Min52 N,10 Min52 > 0 COTAŢIE AS


88

Denumire Identi-

ficator

Tip,

lung

ime


care-l regăsim

data tranzacţiei

data_tranz D,8 data_tranz >

01.01.90 TRANZACŢIE

Rafinarea modelului introducând relaţia de moştenire

Rafinarea modelului presupune introducerea relaţiilor de moştenire între

clasele care prezintă aspecte comune, realizând o superclasă sau delimitând o

clasă generală în subclase specializate. Analizând descrierea fiecărei clase,

realizată prin Dicţionarul de date, apare naturală o rafinarea a modelului

obiectelor, creând astfel:

- superclasa: Cotaţii, din care să derive clasele Cotaţii derivate financiare

şi Cotaţii active suport;

- superclasa: Operatori în piaţă, din care să derive clasele Trader, Broker

şi Client, întrucât trader, broker, client sunt principalii operatori implicaţi în

procesul de tranzacţionare;

- superclasa Derivate financiare din care să se desprindă clasa Contracte

futures şi clasa Options

- subclase pentru: Ordine de vânzare şi Ordine de cumpărare, întrucât din

analiza procesului de tranzacţionare s-a dedus că se întocmesc ordine

distincte în funcţie de operaţiunea care se iniţiază în piaţă.

Gruparea claselor în module

Se recomandă atunci când numărul de clase identificate este relativ

important, în caz contrar se poate considera că există un singur modul, care

echivalează cu sistemul. Am preferat să împărţim sistemul în două module

grupând clasele identificate în funcţie de activităţile care se derulează în

aceeaşi sferă. Astfel avem:

- modulul Portofoliu care va grupa activităţile ce conduc la definirea

structurii unui portofoliu strategic;

- modulul Tranzacţii care va grupa activităţile care se declanşează la

derularea tranzacţiilor în ringul Bursei.

88

Denumire Identi-

ficator

Tip,

lung

ime


care-l regăsim

data tranzacţiei

data_tranz D,8 data_tranz >

01.01.90 TRANZACŢIE

Rafinarea modelului introducând relaţia de moştenire

Rafinarea modelului presupune introducerea relaţiilor de moştenire între

clasele care prezintă aspecte comune, realizând o superclasă sau delimitând o

clasă generală în subclase specializate. Analizând descrierea fiecărei clase,

realizată prin Dicţionarul de date, apare naturală o rafinarea a modelului

obiectelor, creând astfel:

- superclasa: Cotaţii, din care să derive clasele Cotaţii derivate financiare

şi Cotaţii active suport;

- superclasa: Operatori în piaţă, din care să derive clasele Trader, Broker

şi Client, întrucât trader, broker, client sunt principalii operatori implicaţi în

procesul de tranzacţionare;

- superclasa Derivate financiare din care să se desprindă clasa Contracte

futures şi clasa Options

- subclase pentru: Ordine de vânzare şi Ordine de cumpărare, întrucât din

analiza procesului de tranzacţionare s-a dedus că se întocmesc ordine

distincte în funcţie de operaţiunea care se iniţiază în piaţă.

Gruparea claselor în module

Se recomandă atunci când numărul de clase identificate este relativ

important, în caz contrar se poate considera că există un singur modul, care

echivalează cu sistemul. Am preferat să împărţim sistemul în două module

grupând clasele identificate în funcţie de activităţile care se derulează în

aceeaşi sferă. Astfel avem:

- modulul Portofoliu care va grupa activităţile ce conduc la definirea

structurii unui portofoliu strategic;

- modulul Tranzacţii care va grupa activităţile care se declanşează la

derularea tranzacţiilor în ringul Bursei.


89

Aceste ultime 2 etape permit definirea modelului obiectelor dar şi

descrierea acestuia. Reprezentarea cunoscută sub denumirea de diagrama

obiectelor este de un real folos atunci când va trebui să definim din punct de

vedere logic şi fizic, structura bazei de date.

Îmbinând facilităţile modelului orientat obiect (structuri de date complexe,

moştenire) cu cele ale modelului relaţional (tabele bidimensionale, acces

optimizat şi concurent, standardizare), modelul obiect-relaţional este soluţia

pentru managementul datelor necesare sistemului suport, ca sistem interactiv

de asistare a deciziei.

Interfaţarea modelului obiect cu modelul relaţional realizează o extensie a

acestuia din urmă aducând o serie de îmbunătăţiri. Principala îmbunătăţire

adusă o constituie tipurile abstracte de date (TAD)19 care permit: partajarea

datelor, utilizarea structurilor complexe de date, încapsularea, moştenirea)

Structura unei baze de date reprezintă aspectul constant, invariabil sau,

mai bine zis, puţin variabil. Un bun model al obiectelor diminuează riscul

modificărilor de amploare în structura tabelelor şi restricţiilor, conferind

stabilitate bazei de date şi diminuând sensibil eforturile de întreţinere

ulterioară, instalării aplicaţiei.

Primul pas în implementarea modelului obiect este declararea claselor de

obiecte, construindu-se în acest sens fişierul antet cu extensia .h şi a unui fişier

cu extensia .cpp care permite descrierea metodelor asociate clasei. În acest fel

clasele C++ permit modelarea unor entităţi elaborate de date şi a relaţiilor

dintre acestea, iar sistemul de baze de date va permite stocarea în tabele ale

instanţelor acestor clase.

Pentru managementul datelor, sistemul suport implementează modelul

obiectelor folosindu-se de SGBD Access pentru încărcarea datelor şi de

ActiveX Data Objects pentru organizarea datelor după modelul orientat obiect

în memoria calculatorului. Maparea unui tabel la o clasă de obiecte C++ este

redată sugestiv în Figura 4.7, iar imediat după aceea listing-ul fişierelor .h şi

.cpp aferente clasei c_active.

19 http://www.cs.ubbcluj.ro/~gabis/sda/Cursuri/Curs1/1_TAD&SD.pdf

89

Aceste ultime 2 etape permit definirea modelului obiectelor dar şi

descrierea acestuia. Reprezentarea cunoscută sub denumirea de diagrama

obiectelor este de un real folos atunci când va trebui să definim din punct de

vedere logic şi fizic, structura bazei de date.

Îmbinând facilităţile modelului orientat obiect (structuri de date complexe,

moştenire) cu cele ale modelului relaţional (tabele bidimensionale, acces

optimizat şi concurent, standardizare), modelul obiect-relaţional este soluţia

pentru managementul datelor necesare sistemului suport, ca sistem interactiv


Interfaţarea modelului obiect cu modelul relaţional realizează o extensie a

acestuia din urmă aducând o serie de îmbunătăţiri. Principala îmbunătăţire

adusă o constituie tipurile abstracte de date (TAD)19 care permit: partajarea

datelor, utilizarea structurilor complexe de date, încapsularea, moştenirea)

Structura unei baze de date reprezintă aspectul constant, invariabil sau,

mai bine zis, puţin variabil. Un bun model al obiectelor diminuează riscul

modificărilor de amploare în structura tabelelor şi restricţiilor, conferind

stabilitate bazei de date şi diminuând sensibil eforturile de întreţinere

ulterioară, instalării aplicaţiei.

Primul pas în implementarea modelului obiect este declararea claselor de

obiecte, construindu-se în acest sens fişierul antet cu extensia .h şi a unui fişier

cu extensia .cpp care permite descrierea metodelor asociate clasei. În acest fel

clasele C++ permit modelarea unor entităţi elaborate de date şi a relaţiilor

dintre acestea, iar sistemul de baze de date va permite stocarea în tabele ale

instanţelor acestor clase.

Pentru managementul datelor, sistemul suport implementează modelul

obiectelor folosindu-se de SGBD Access pentru încărcarea datelor şi de

ActiveX Data Objects pentru organizarea datelor după modelul orientat obiect

în memoria calculatorului. Maparea unui tabel la o clasă de obiecte C++ este

redată sugestiv în Figura 4.7, iar imediat după aceea listing-ul fişierelor .h şi

.cpp aferente clasei c_active.

19 http://www.cs.ubbcluj.ro/~gabis/sda/Cursuri/Curs1/1_TAD&SD.pdf


90

Figura 3.8. – Maparea unei clase C++ la un tabel relaţional

// c_option.h : header file // ///////////////////////////////////////////////////////////////////////////// // c_option DAO recordset class c_option : public CDaoRecordset { public: c_option(CDaoDatabase* pDatabase = NULL); DECLARE_DYNAMIC(c_option) // Field/Param Data //{{AFX_FIELD(c_option, CDaoRecordset) long m_ID; CString m_simbol; COleDateTime m_data; float m_cotatie; float m_pas_prima; float m_pret_exerc; float m_bet; float m_af; //}}AFX_FIELD

c_active m_ID 205 m_data 11.04.2003 m_cotaţie 3100……. ….

……

c_active m_ID 198 m_data 01.04.2003 m_cotaţie 3250….

….

class c_option : public CDaoRecordset {

long m_ID; CString m_simbol; COleDateTime m_data; float m_cotatie; float m_pas_prima; ….. };

90

Figura 3.8. – Maparea unei clase C++ la un tabel relaţional

// c_option.h : header file // ///////////////////////////////////////////////////////////////////////////// // c_option DAO recordset class c_option : public CDaoRecordset { public: c_option(CDaoDatabase* pDatabase = NULL); DECLARE_DYNAMIC(c_option) // Field/Param Data //{{AFX_FIELD(c_option, CDaoRecordset) long m_ID; CString m_simbol; COleDateTime m_data; float m_cotatie; float m_pas_prima; float m_pret_exerc; float m_bet; float m_af; //}}AFX_FIELD

c_active m_ID 205 m_data 11.04.2003 m_cotaţie 3100……. ….

……

c_active m_ID 198 m_data 01.04.2003 m_cotaţie 3250….

….

class c_option : public CDaoRecordset {

long m_ID; CString m_simbol; COleDateTime m_data; float m_cotatie; float m_pas_prima; ….. };


91

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(c_option) public: virtual CString GetDefaultDBName(); // Default database name virtual CString GetDefaultSQL(); // Default SQL for Recordset virtual void DoFieldExchange(CDaoFieldExchange* pFX); // RFX support //}}AFX_VIRTUAL // Implementation #ifdef _DEBUG virtual void AssertValid() const; virtual void Dump(CDumpContext& dc) const; #endif }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_C_OPTION_H__7B06F42B_0247_44F3_BD16_77698EC80620__INCLUDED_) -----------------------------------------------------------------------------------

void CX_TRADEDoc::incarca_option() { c_option rs; int n; rs.m_strFilter = "[simbol]=\"EUROUSD\""; rs.Open(); rs.MoveFirst(); n=0; while (!rs.IsEOF()) { OpTabel::tabel aux; aux.data = rs.m_data; aux.RUEJDD= rs.m_cotatie; aux.BET = rs.m_bet; aux.AF = rs.m_af; op.AddLine(&a_O_EuroUsd,&u_O_EuroUsd,aux); n++; rs.MoveNext(); } n_O_EuroUsd=n; rs.Close(); rs.m_strFilter = "[simbol]=\"ROLUSD\""; rs.Open(); rs.MoveFirst(); n=0; while (!rs.IsEOF()) { OpTabel::tabel aux;

91

// Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(c_option) public: virtual CString GetDefaultDBName(); // Default database name virtual CString GetDefaultSQL(); // Default SQL for Recordset virtual void DoFieldExchange(CDaoFieldExchange* pFX); // RFX support //}}AFX_VIRTUAL // Implementation #ifdef _DEBUG virtual void AssertValid() const; virtual void Dump(CDumpContext& dc) const; #endif }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_C_OPTION_H__7B06F42B_0247_44F3_BD16_77698EC80620__INCLUDED_) -----------------------------------------------------------------------------------

void CX_TRADEDoc::incarca_option() { c_option rs; int n; rs.m_strFilter = "[simbol]=\"EUROUSD\""; rs.Open(); rs.MoveFirst(); n=0; while (!rs.IsEOF()) { OpTabel::tabel aux; aux.data = rs.m_data; aux.RUEJDD= rs.m_cotatie; aux.BET = rs.m_bet; aux.AF = rs.m_af; op.AddLine(&a_O_EuroUsd,&u_O_EuroUsd,aux); n++; rs.MoveNext(); } n_O_EuroUsd=n; rs.Close(); rs.m_strFilter = "[simbol]=\"ROLUSD\""; rs.Open(); rs.MoveFirst(); n=0; while (!rs.IsEOF()) { OpTabel::tabel aux;


92

aux.data = rs.m_data; aux.RUEJDD= rs.m_cotatie; aux.BET = rs.m_bet; aux.AF = rs.m_af; op.AddLine(&a_O_RolUsd,&u_O_RolUsd,aux); n++; rs.MoveNext(); } n_O_RolUsd=n; rs.Close(); };

M o d e l u l d i n a m i c

Modelul obiectelor, singur este insuficient pentru a desăvârşi proiectarea

unei baze de date orientate spre obiecte. Abordarea obiectuală trebuie

suplinită cu o tehnică care identifică şi documentează comportamentul fiecărei

clase de obiecte.

Aceasta implică o analiză detailată a modelului conceptual de prelucrare, care

este corespondentul modelului dinamic din metodologia proiectării bazei de

date relaţionale a sistemului informatic al Bursei.

Vom începe deci construirea modelului dinamic prin căutarea

evenimentelor şi mai apoi gruparea secvenţelor permise de evenimente într-o

diagramă de stare, parcurgând o serie de etape specifice. Este posibil ca

definirea comportamentului, respectiv a interacţiunilor care au loc între clase şi

obiecte, să impună adăugarea de noi asocieri la ceea ce modelul obiectelor

conţine deja în această privinţă.

De menţionat că modelul dinamic este nesemnificativ pentru date statice,

ca de exemplu baze de date, dar este însă foarte important pentru aplicaţiile

interactive, aşa cum este sistemul nostru de asistare a deciziei pentru

managementul operaţiunilor cu produse financiare derivate.

Pregătirea scenariilor

Un scenariu va fi o secvenţă de evenimente. Pentru fiecare eveniment,

se vor identifica actorii (sistemul, utilizatorul sau alt agent externe) care l-au

cauzat şi parametrii evenimentului. Pentru asistarea deciziei în managementul

operaţiunilor putem urmării următoarele scenarii:

92

aux.data = rs.m_data; aux.RUEJDD= rs.m_cotatie; aux.BET = rs.m_bet; aux.AF = rs.m_af; op.AddLine(&a_O_RolUsd,&u_O_RolUsd,aux); n++; rs.MoveNext(); } n_O_RolUsd=n; rs.Close(); };

M o d e l u l d i n a m i c

Modelul obiectelor, singur este insuficient pentru a desăvârşi proiectarea

unei baze de date orientate spre obiecte. Abordarea obiectuală trebuie

suplinită cu o tehnică care identifică şi documentează comportamentul fiecărei

clase de obiecte.

Aceasta implică o analiză detailată a modelului conceptual de prelucrare, care

este corespondentul modelului dinamic din metodologia proiectării bazei de

date relaţionale a sistemului informatic al Bursei.

Vom începe deci construirea modelului dinamic prin căutarea

evenimentelor şi mai apoi gruparea secvenţelor permise de evenimente într-o

diagramă de stare, parcurgând o serie de etape specifice. Este posibil ca

definirea comportamentului, respectiv a interacţiunilor care au loc între clase şi

obiecte, să impună adăugarea de noi asocieri la ceea ce modelul obiectelor

conţine deja în această privinţă.

De menţionat că modelul dinamic este nesemnificativ pentru date statice,

ca de exemplu baze de date, dar este însă foarte important pentru aplicaţiile

interactive, aşa cum este sistemul nostru de asistare a deciziei pentru

managementul operaţiunilor cu produse financiare derivate.

Pregătirea scenariilor

Un scenariu va fi o secvenţă de evenimente. Pentru fiecare eveniment,

se vor identifica actorii (sistemul, utilizatorul sau alt agent externe) care l-au

cauzat şi parametrii evenimentului. Pentru asistarea deciziei în managementul

operaţiunilor putem urmării următoarele scenarii:


93

SCENARIU: Managementul de portofoliu este realizat de un TRADER

Obiectiv: definitivarea structurii portofoliului strategic din contracte futures şi options

Finalizare: insucces

Traderul vizualizează Cotaţiile

contractelor futures şi options

pentru anumite intervale de timp.

Contractele futures şi/sau

Options nu înregistrează Cotaţii

favorabile.


Options nu pot alcătui Portofoliu

strategic

Traderul nu emite Ordine de

tranzacţionare.

Traderul se retrage din piaţă şi

efectuează diverse prognoze ale

cotaţiilor, aşteptând un moment

favorabil.

Finalizare: cu succes


futures şi options pentru anumite

intervale.

Contractele futures şi/sau Options

înregistrează Cotaţii favorabile.

Traderul constituie un Portofoliu

strategic din derivate în funcţie de

performanţele calculate pentru fiecare.


care depăşesc punctul critic alcătuiesc

componenţa Portofoliului strategic.

Traderul emite Ordine

tranzacţionare în funcţie de trendul

pieţei pentru derivatele din structura

portofoliului.

Traderul vizualizează Cotaţii active

pentru compara cu evoluţia

derivatelor.

Ordinele de tranzacţionare

generează Tranzacţii.

Tranzacţiile actualizează Portofoliul.

93

SCENARIU: Managementul de portofoliu este realizat de un TRADER

Obiectiv: definitivarea structurii portofoliului strategic din contracte futures şi options



contractelor futures şi options



Options nu înregistrează Cotaţii

favorabile.


Options nu pot alcătui Portofoliu

strategic

Traderul nu emite Ordine de

tranzacţionare.

Traderul se retrage din piaţă şi



favorabil.



futures şi options pentru anumite

intervale.



Traderul constituie un Portofoliu

strategic din derivate în funcţie de



care depăşesc punctul critic alcătuiesc

componenţa Portofoliului strategic.

Traderul emite Ordine

tranzacţionare în funcţie de trendul

pieţei pentru derivatele din structura

portofoliului.

Traderul vizualizează Cotaţii active

pentru compara cu evoluţia

derivatelor.

Ordinele de tranzacţionare

generează Tranzacţii.

Tranzacţiile actualizează Portofoliul.


94

SCENARIU: Managementul de portofoliu este realizat de BROKER

Obiectiv: definitivarea portofoliului strategic de contracte futures şi options


Client solicită ABK broker pentru

derulare afaceri în ringul Bursei.

ABK repartizează Broker.

Broker vizualizează cotaţii

contracte futures şi/sau options


Contracte futures şi/sau Options

nu înregistrează Cotaţii favorabile.


nu pot alcătui un Portofoliu

strategic.

Broker informează Client.

Client nu emite Ordine

tranzacţionare.

Brokerul se retrage din piaţă şi



favorabil.


Client solicită ABK un broker în vederea

derulării de afaceri în ringul bursei.


Broker vizualizează cotaţii contracte

futures şi/sau options pentru anumite

intervale de timp.



Broker constituie Portofoliu strategic

din derivate financiare în funcţie de


Contracte futures şi/sau Options care

depăşesc punctul critic alcătuiesc

Portofoliu strategic.


Client emite Ordine tranzacţionare în

funcţie de trendul pieţei pentru derivatele

financiare din structura portofoliului.

Broker vizualizează Cotaţii active

suport pentru a compara cu evoluţia

derivatelor.

Ordine tranzacţionare generează

tranzacţii în ringul bursei.

Tranzacţii actualizează structura

Portofoliu.

94

SCENARIU: Managementul de portofoliu este realizat de BROKER

Obiectiv: definitivarea portofoliului strategic de contracte futures şi options


Client solicită ABK broker pentru

derulare afaceri în ringul Bursei.


Broker vizualizează cotaţii

contracte futures şi/sau options



nu înregistrează Cotaţii favorabile.


nu pot alcătui un Portofoliu

strategic.


Client nu emite Ordine

tranzacţionare.

Brokerul se retrage din piaţă şi



favorabil.


Client solicită ABK un broker în vederea

derulării de afaceri în ringul bursei.



futures şi/sau options pentru anumite

intervale de timp.



Broker constituie Portofoliu strategic

din derivate financiare în funcţie de


Contracte futures şi/sau Options care

depăşesc punctul critic alcătuiesc

Portofoliu strategic.


Client emite Ordine tranzacţionare în

funcţie de trendul pieţei pentru derivatele

financiare din structura portofoliului.

Broker vizualizează Cotaţii active

suport pentru a compara cu evoluţia

derivatelor.


tranzacţii în ringul bursei.

Tranzacţii actualizează structura

Portofoliu.


95

Identificarea evenimentelor. Diagrama fluxului de evenimente

Fiecare scenariu a fost prezentat ca o succesiune de evenimente, fiecare

tip de eveniment fiind alocat claselor care l-au trimis, respectiv recepţionat.

Prezentăm în continuare diagrama fluxului de evenimente pentru fiecare modul

în parte, cu scopul detalierii tuturor evenimentelor. (vezi Figura 3.9 şi Figura

3.10).

Figura 3.9 - Diagrama fluxului de evenimente pentru modulul PORTOFOLIU

intră în structură ies din structură COTAŢII

DERIVATE FINANCIARE

derulează

influe

nţe

ază

actu

aliz

ează

OPERATORI TRANZACŢII

PORTOFOLIU

actu

aliz

ează

SCENARIU: Derularea tranzacţiilor în piaţa bursieră

Obiectiv: managementul de portofoliu cu derivate

TRADER

Trader vizualizează Cotaţiile

futures şi contractelor options


Trader emite Ordine

tranzacţionare în funcţie de

trendul pieţei.


Tranzacţii în piață

BROKER

Client solicită ABK un broker pentru

derulare tranzacții pe piață



futures şi/sau options pentru

anumite intervale de timp.


Client emite Ordine tranzacţionare

în funcţie de trendul pieţei

Ordine de tranzacţionare generează

tranzacţii în piață.

95

Identificarea evenimentelor. Diagrama fluxului de evenimente

Fiecare scenariu a fost prezentat ca o succesiune de evenimente, fiecare

tip de eveniment fiind alocat claselor care l-au trimis, respectiv recepţionat.

Prezentăm în continuare diagrama fluxului de evenimente pentru fiecare modul

în parte, cu scopul detalierii tuturor evenimentelor. (vezi Figura 3.9 şi Figura

3.10).

Figura 3.9 - Diagrama fluxului de evenimente pentru modulul PORTOFOLIU

intră în structură ies din structură COTAŢII

DERIVATE FINANCIARE

derulează

influe

nţe

ază

actu

aliz

ează

OPERATORI TRANZACŢII

PORTOFOLIU

actu

aliz

ează

SCENARIU: Derularea tranzacţiilor în piaţa bursieră

Obiectiv: managementul de portofoliu cu derivate

TRADER

Trader vizualizează Cotaţiile

futures şi contractelor options


Trader emite Ordine

tranzacţionare în funcţie de

trendul pieţei.


Tranzacţii în piață

BROKER

Client solicită ABK un broker pentru

derulare tranzacții pe piață



futures şi/sau options pentru

anumite intervale de timp.


Client emite Ordine tranzacţionare

în funcţie de trendul pieţei

Ordine de tranzacţionare generează

tranzacţii în piață.


96

Figura 3.10 - Diagrama fluxului de evenimente pentru modulul TRANZACŢII

Diagrama de stări

Deţine un rol important în paradigma obiectuală, deoarece schimbările de

stare pe care le poate suporta un obiect influenţează comportamentul acestuia,

ceea ce justifică suficient de convingător necesitatea evidenţierii şi studiului lor.

Pentru principalele clase de obiecte, cu comportament dinamic se va

construi o diagramă de stare. Fiecare scenariu sau succesiune de evenimente

corespunde unui drum în această diagramă de stare.

Forma generală a unei diagrame de stări este reprezentată în Figura

3.11., în care se poate observa că există numai două tipuri de componente:

tranziţiile şi stările, printre acestea din urmă evidenţiindu-se două tipuri

particulare: starea iniţială şi starea finală.

Figura 3.11. - Diagrama fluxului de evenimente pentru modulul Tranzacţii

Diagrama de stări pentru clasa Derivat financiar. Un obiect contract

futures EuroUsd parcurge următoarele stări: emis → în curs de tranzacţionare

→ încheiat. Tranziţia spre starea emis este declanşată de evenimentul

înregistrează cotaţii favorabile. Emiterea unui ordin de tranzacţionare constituie

evenimentul care determină tranziţia spre starea următoare: → în curs de

COTAŢII

TRANZACŢII

ORDINE OPERATORI

trimise

execută verifică în

che

ie

influe

nţe

ază

actu

aliz

ează

STARE STARE

Stare iniţială Stare finală

Tranziţie şi eveniment

declanşator

96

Figura 3.10 - Diagrama fluxului de evenimente pentru modulul TRANZACŢII

Diagrama de stări

Deţine un rol important în paradigma obiectuală, deoarece schimbările de

stare pe care le poate suporta un obiect influenţează comportamentul acestuia,

ceea ce justifică suficient de convingător necesitatea evidenţierii şi studiului lor.

Pentru principalele clase de obiecte, cu comportament dinamic se va

construi o diagramă de stare. Fiecare scenariu sau succesiune de evenimente

corespunde unui drum în această diagramă de stare.

Forma generală a unei diagrame de stări este reprezentată în Figura

3.11., în care se poate observa că există numai două tipuri de componente:

tranziţiile şi stările, printre acestea din urmă evidenţiindu-se două tipuri

particulare: starea iniţială şi starea finală.

Figura 3.11. - Diagrama fluxului de evenimente pentru modulul Tranzacţii

Diagrama de stări pentru clasa Derivat financiar. Un obiect contract

futures EuroUsd parcurge următoarele stări: emis → în curs de tranzacţionare

→ încheiat. Tranziţia spre starea emis este declanşată de evenimentul

înregistrează cotaţii favorabile. Emiterea unui ordin de tranzacţionare constituie

evenimentul care determină tranziţia spre starea următoare: → în curs de

COTAŢII

TRANZACŢII

ORDINE OPERATORI

trimise

execută verifică în

che

ie

influe

nţe

ază

actu

aliz

ează

STARE STARE

Stare iniţială Stare finală

Tranziţie şi eveniment

declanşator


97

tranzacţionare. Execuţia în piaţă a ordinului de tranzacţionare declanşează

intrarea în starea finală încheiat.

Figura 3.11. - Diagrama de stări pentru clasa Derivate financiare

Diagrama de stări pentru clasa PORTOFOLIU. Clasa, PORTOFOLIU,

parcurge 3 stări: de constituit → în curs de constituire → constituit. Figura 3.12

conţine diagrama de stare referitoare la portofoliul strategic de contracte

futures şi options. Structura portofoliului este stabilită numai dacă cotaţiile

înregistrate în perioada de timp aleasă îndeplinesc condiţiile stabilite prin

algoritmul modelului decizional. În caz contrar, derivatele financiare ale căror

cotaţii nu sunt favorabile, nu intră în structura portofoliului.

Figura 3.12. - Diagrama de stări pentru clasa PORTOFOLIU

EMIS În curs de tranzacţionare

Stare iniţială

Stare finală

Emitere

ordin

Înregistrează

cotaţii favorabile

Exe

cu

ţie

ord

in

ÎNCHEIAT

constituit

when (suficiente derivate)

[max8 and min1]

derivate intră în

structura portofoliului

Stare finală

Stare iniţială

derivate ies din


if (trend modificat)

[exces de randam < punct

critic]

în curs de constituire de constituit

97

tranzacţionare. Execuţia în piaţă a ordinului de tranzacţionare declanşează

intrarea în starea finală încheiat.

Figura 3.11. - Diagrama de stări pentru clasa Derivate financiare

Diagrama de stări pentru clasa PORTOFOLIU. Clasa, PORTOFOLIU,

parcurge 3 stări: de constituit → în curs de constituire → constituit. Figura 3.12

conţine diagrama de stare referitoare la portofoliul strategic de contracte

futures şi options. Structura portofoliului este stabilită numai dacă cotaţiile

înregistrate în perioada de timp aleasă îndeplinesc condiţiile stabilite prin

algoritmul modelului decizional. În caz contrar, derivatele financiare ale căror

cotaţii nu sunt favorabile, nu intră în structura portofoliului.

Figura 3.12. - Diagrama de stări pentru clasa PORTOFOLIU

EMIS În curs de tranzacţionare

Stare iniţială

Stare finală

Emitere

ordin

Înregistrează

cotaţii favorabile

Exe

cu

ţie

ord

in

ÎNCHEIAT

constituit

when (suficiente derivate)

[max8 and min1]

derivate intră în


Stare finală

Stare iniţială

derivate ies din


if (trend modificat)

[exces de randam < punct

critic]

în curs de constituire de constituit


98

Din starea iniţială, la apariţia unui eveniment constând în intră în structură

conform algoritmului, obiectul Portofoliu strategic, trece în starea în curs de

constituire. Dacă apare evenimentul iese din structură, atunci se revine în

starea de constituit, aşteptând cotaţii favorabile sau efectuând teste pentru alte

produse financiare derivate. Dacă evenimentul intră în structură este valabil

pentru suficient de multe produse financiare derivate pentru a alcătui structura

unui portofoliu strategic, atunci are loc trecerea în starea constituit. Starea

constituit permite derularea de tranzacţii, care vor actualiza structura

portofoliului. Aceasta revine la starea iniţială dacă tranzacţiile schimbă trendul

cotaţiilor, iar acestea din urmă nu mai depăşesc punctul critic.

Modelul funcţional

Dacă modelul dinamic al aplicaţiei pe care o dezvoltăm a arătat când se

întâmplă ceva, şi modelul obiectelor a indicat cui i se întâmplă, modelul

funcţional va desluşi ce se întâmplă în sistem. Modelul funcţional descrie cum

se calculează valorile de ieşire din cadrul sistemului în funcţie de valorile de

intrare, independent de ordinea temporală în care se calculează.

Practica a demonstrat că, în funcţie de tipul sistemului modelat, unul

dintre cele două modele - dinamic sau funcţional – predomină, modelul

obiectelor fiind întotdeauna cel de bază. În cazul nostru, fiind vorba de un

sistem interactiv care va oferi asistenţă pentru managementul de portofoliu şi

nu numai (şi al operaţiunilor), baza de date asociată sistemului va avea un

model funcţional banal deoarece ele nu calculează, ci doar înmagazinează şi

organizează date despre cotaţii, ordine de vânzare/cumpărare emise, tranzacţii

derulate. Pe de altă parte, dacă avem în vedere faptul că nucleul central al

aplicaţiei îl constituie activitatea de constituire a unui portofoliu strategic de

produse financiare derivate, modelul dinamic este banal deoarece acestea vor

funcţiona în acelaşi fel, de fiecare dată când sunt alimentate cu programul

sursă; de bază este modelul funcţional, care va indica modul în care se

calculează şi modul cum se generează codul obiect).

Pornind de la aceste considerente, vom construi modelul funcţional

parcurgând următorii paşi:

98

Din starea iniţială, la apariţia unui eveniment constând în intră în structură

conform algoritmului, obiectul Portofoliu strategic, trece în starea în curs de

constituire. Dacă apare evenimentul iese din structură, atunci se revine în

starea de constituit, aşteptând cotaţii favorabile sau efectuând teste pentru alte

produse financiare derivate. Dacă evenimentul intră în structură este valabil

pentru suficient de multe produse financiare derivate pentru a alcătui structura

unui portofoliu strategic, atunci are loc trecerea în starea constituit. Starea

constituit permite derularea de tranzacţii, care vor actualiza structura

portofoliului. Aceasta revine la starea iniţială dacă tranzacţiile schimbă trendul

cotaţiilor, iar acestea din urmă nu mai depăşesc punctul critic.

Modelul funcţional

Dacă modelul dinamic al aplicaţiei pe care o dezvoltăm a arătat când se

întâmplă ceva, şi modelul obiectelor a indicat cui i se întâmplă, modelul

funcţional va desluşi ce se întâmplă în sistem. Modelul funcţional descrie cum

se calculează valorile de ieşire din cadrul sistemului în funcţie de valorile de

intrare, independent de ordinea temporală în care se calculează.

Practica a demonstrat că, în funcţie de tipul sistemului modelat, unul

dintre cele două modele - dinamic sau funcţional – predomină, modelul

obiectelor fiind întotdeauna cel de bază. În cazul nostru, fiind vorba de un

sistem interactiv care va oferi asistenţă pentru managementul de portofoliu şi

nu numai (şi al operaţiunilor), baza de date asociată sistemului va avea un

model funcţional banal deoarece ele nu calculează, ci doar înmagazinează şi

organizează date despre cotaţii, ordine de vânzare/cumpărare emise, tranzacţii

derulate. Pe de altă parte, dacă avem în vedere faptul că nucleul central al

aplicaţiei îl constituie activitatea de constituire a unui portofoliu strategic de

produse financiare derivate, modelul dinamic este banal deoarece acestea vor

funcţiona în acelaşi fel, de fiecare dată când sunt alimentate cu programul

sursă; de bază este modelul funcţional, care va indica modul în care se

calculează şi modul cum se generează codul obiect).

Pornind de la aceste considerente, vom construi modelul funcţional

parcurgând următorii paşi:


99

Identificarea actorilor, a valorilor de intrare şi ieşire din sistem

Un actor este un obiect activ care generează sau consumă datele. Actorii

implicaţi în cazul nostru sunt: Trader/Broker, Portofoliu şi activităţi ca:

tranzacţii, management de portofoliu, fiind reprezentaţi în diagrama de flux de

date prin dreptunghiuri.

Valorile de intrare sau de ieşire sunt parametri ai evenimentelor dintre

sistem şi lumea exterioară. Intrările şi ieşirile sistemului au fost identificate şi

analizate în paragraful 3.2.. În această etapă le vom prezenta schematic în

Figura 3.13., respectiv Figura 3.14.

INTRĂRILE SISTEMULUI

COTAŢII

pentru:

DERIVATE FINANCIARE

Contracte futures


Acţiuni DESIF1 DESIF3

DESNP

Dobânzi Bubor

Options



Dobânzi Bubor


Indicele pieţei BET

ACTIVE SUPORT

Valute Usd Euro Yen

Acţiuni

SIF1 SIF3 SNP

Dobânzi Bubor

ORDINE

pentru:

Cumpărare

Vânzare

Figura 3.13. – Intrări în sistem suport

99

Identificarea actorilor, a valorilor de intrare şi ieşire din sistem

Un actor este un obiect activ care generează sau consumă datele. Actorii

implicaţi în cazul nostru sunt: Trader/Broker, Portofoliu şi activităţi ca:

tranzacţii, management de portofoliu, fiind reprezentaţi în diagrama de flux de

date prin dreptunghiuri.

Valorile de intrare sau de ieşire sunt parametri ai evenimentelor dintre

sistem şi lumea exterioară. Intrările şi ieşirile sistemului au fost identificate şi

analizate în paragraful 3.2.. În această etapă le vom prezenta schematic în

Figura 3.13., respectiv Figura 3.14.

INTRĂRILE SISTEMULUI

COTAŢII

pentru:

DERIVATE FINANCIARE

Contracte futures


Acţiuni DESIF1 DESIF3

DESNP

Dobânzi Bubor

Options



Dobânzi Bubor


Indicele pieţei BET

ACTIVE SUPORT

Valute Usd Euro Yen

Acţiuni

SIF1 SIF3 SNP

Dobânzi Bubor

ORDINE

pentru:

Cumpărare

Vânzare

Figura 3.13. – Intrări în sistem suport


100

IEŞIRILE SISTEMULUI

INDICATORI

Derivate financiare

/active suport

INDICATORI pentru managementul de

portofoliu RAPOARTE

Rentabilitate activ Ri

Risc activ σi

Risc piaţă σm

Volatilitate activ βi

Exces randament γi

Punct critic Ci

% de investire xi

Rentabilitate Rp

Risc portofoliu σp

Volatilitate portofoliu βp

Portofoliu strategic PS

Portofoliu active suport PAS

Raport de tranzacţionare RT

Centralizator ordine CO

Sumarul tranzacţiilor ST

Diagnostic produse financiare derivate DPFD

Diagnostic active suport DAS

Situaţie comparativă SC

Construirea diagramelor de flux de date

Vom construi acum o diagramă de flux de date ce va reflecta legăturile

stabilite între actori prin intermediul fluxurilor informaţional şi ceea ce este

foarte important cum se calculează fiecare valoare de ieşire din valorile de

intrare.

Menţionăm că procesul decizional aferent deciziilor pe care traderul

trebuie să le formuleze, este structurat astfel:

analiza statistică a evoluţiei cotaţiilor înregistrate de produsele

financiare derivate în ringul bursei şi a evoluţiei pieţei (BET), activului fără risc

(AF), inclusiv a activelor suport;

analiza posibilităţilor de fundamentare a unui portofoliu strategic de

produse financiare derivate, aceasta constând în determinarea unui set de

indicatori specifici activelor financiare (rentabilitate, risc, coeficient beta);

adoptarea deciziei de constituire a portofoliului strategic constând în

declanşarea unui algoritm de selecţie a acelor derivate financiare care

îndeplinesc condiţiile impuse de modelul decizional;

analiza periodică a structurii portofoliului şi constituirea în paralel a unui

portofoliu de active suport pentru comparaţie şi pentru a ţine sub control

investiţia financiară;

managementul de portofoliu pentru obţinerea de performanţe.

Figura 3.14. – Ieșirile sistemului suport

100

IEŞIRILE SISTEMULUI

INDICATORI

Derivate financiare

/active suport

INDICATORI pentru managementul de

portofoliu RAPOARTE

Rentabilitate activ Ri

Risc activ σi

Risc piaţă σm

Volatilitate activ βi

Exces randament γi

Punct critic Ci

% de investire xi

Rentabilitate Rp

Risc portofoliu σp

Volatilitate portofoliu βp

Portofoliu strategic PS

Portofoliu active suport PAS

Raport de tranzacţionare RT

Centralizator ordine CO

Sumarul tranzacţiilor ST

Diagnostic produse financiare derivate DPFD

Diagnostic active suport DAS

Situaţie comparativă SC

Construirea diagramelor de flux de date

Vom construi acum o diagramă de flux de date ce va reflecta legăturile

stabilite între actori prin intermediul fluxurilor informaţional şi ceea ce este

foarte important cum se calculează fiecare valoare de ieşire din valorile de

intrare.

Menţionăm că procesul decizional aferent deciziilor pe care traderul

trebuie să le formuleze, este structurat astfel:

analiza statistică a evoluţiei cotaţiilor înregistrate de produsele

financiare derivate în ringul bursei şi a evoluţiei pieţei (BET), activului fără risc

(AF), inclusiv a activelor suport;

analiza posibilităţilor de fundamentare a unui portofoliu strategic de

produse financiare derivate, aceasta constând în determinarea unui set de

indicatori specifici activelor financiare (rentabilitate, risc, coeficient beta);

adoptarea deciziei de constituire a portofoliului strategic constând în

declanşarea unui algoritm de selecţie a acelor derivate financiare care

îndeplinesc condiţiile impuse de modelul decizional;

analiza periodică a structurii portofoliului şi constituirea în paralel a unui

portofoliu de active suport pentru comparaţie şi pentru a ţine sub control

investiţia financiară;

managementul de portofoliu pentru obţinerea de performanţe.

Figura 3.14. – Ieșirile sistemului suport


101

Toate aceste etape vor fi reflectate în diagrama de flux a datelor, fiind

evidenţiate fluxurile informaţionale declanşate de trader, sensul acestora,

actorii implicaţi, intrările şi ieşirile sistemului.

Figura 3.15. – Diagrama de flux de date

Se remarcă aspectul vizual şi simplitatea reprezentării obţinute prin

diagrama din Figura 3.15, asigurând o descriere destul de completă a felului în

care se desfăşoară circulaţia informaţiilor în sistemul proiectat pentru asistarea

deciziei de management a operaţiunilor. Mai mult, diagrama a fost îmbunătăţită

prin intermediul unor cifre care indică secvenţa sau succesiunea prelucrării, şi

asocierea unui tabel descriptiv (vezi Tabelul 3.11) a fluxurilor informaţionale, a

modului de folosire al diverselor documente şi rapoarte necesare acestei

activităţi.

Tabel 3.11 – Tabel descriptiv pentru succesiunea fluxurilor informaționale

Nr.

flux

ACTORUL Descrierea fluxului de

date realizat

Documente

Situaţii

folosite Emitent Receptor

1 TRADER COTAŢII Vizualizare cotaţii LC

2 TRADER TRANZACŢII

Obţinere situaţii

centralizatoare privind

tranzacţiile derulate în

piaţă

ST, RT

3 COTAŢII TRADER Elaborare algoritmului

de selecţie

Ri , σi , σm ,

βi

4 TRADER TRADER Fundamentare decizie

constituire portofoliu DPFD, DAS

LC (1)

(5)

COTAŢIE TRADER

TRANZACŢIE

(5)

DPFD, DAS (4)

PS, PAS, SC, (6) (7 )

ST, RT (2)

OV/OC, CO (8)

Ri, σi, σM (3)

PORTOFOLIU

101

Toate aceste etape vor fi reflectate în diagrama de flux a datelor, fiind

evidenţiate fluxurile informaţionale declanşate de trader, sensul acestora,

actorii implicaţi, intrările şi ieşirile sistemului.

Figura 3.15. – Diagrama de flux de date

Se remarcă aspectul vizual şi simplitatea reprezentării obţinute prin

diagrama din Figura 3.15, asigurând o descriere destul de completă a felului în

care se desfăşoară circulaţia informaţiilor în sistemul proiectat pentru asistarea

deciziei de management a operaţiunilor. Mai mult, diagrama a fost îmbunătăţită

prin intermediul unor cifre care indică secvenţa sau succesiunea prelucrării, şi

asocierea unui tabel descriptiv (vezi Tabelul 3.11) a fluxurilor informaţionale, a

modului de folosire al diverselor documente şi rapoarte necesare acestei

activităţi.

Tabel 3.11 – Tabel descriptiv pentru succesiunea fluxurilor informaționale

Nr.

flux

ACTORUL Descrierea fluxului de

date realizat

Documente

Situaţii

folosite Emitent Receptor

1 TRADER COTAŢII Vizualizare cotaţii LC

2 TRADER TRANZACŢII

Obţinere situaţii

centralizatoare privind

tranzacţiile derulate în

piaţă

ST, RT

3 COTAŢII TRADER Elaborare algoritmului

de selecţie

Ri , σi , σm ,

βi

4 TRADER TRADER Fundamentare decizie

constituire portofoliu DPFD, DAS

LC (1)

(5)

COTAŢIE TRADER

TRANZACŢIE

(5)

DPFD, DAS (4)

PS, PAS, SC, (6) (7 )

ST, RT (2)

OV/OC, CO (8)

Ri, σi, σM (3)

PORTOFOLIU


102

5 COTAŢII PORTOFOLIU Verificări diverse

6 TRADER PORTOFOLIU Decizia constituire

portofoliu strategic PS, PAS, SC

7 TRADER PORTOFOLIU

Prognoze privind

evoluţia cotaţiilor pentru

derivatele din structura

portofoliului

Grafice

8 TRANZACŢII TRADER

Efectuare tranzacţii

menţine/îmbunătăţii

structura portofoli

OV/OC, CO

Specificarea operaţiilor şi identificarea metodele asociate claselor

Procesele din diagrama fluxului de date vor fi implementate ca operaţii

ale obiectelor considerate în modelul obiectelor. Aceste operaţii garantează că

informaţiile adecvate sunt disponibile pentru obţinerea şi administrarea

eficientă a portofoliului strategic şi pentru a susţine managementul

operaţiunilor cu produse financiare derivate. Aşadar, pentru a finaliza modelul

funcţional, procedăm la specificarea operaţiilor asociate claselor, respectând

modul de reprezentare a acestora.

Figura 3.16. – Operații asociate claselor pentru asistare adeciziei în

managementul de portofoliu

CLIENT

………………

adaugă () şterge () list_date_id ()

OPERATOR

……………….. ………………..adaugă () şterge () cotizează ()

ORDIN

………………………… list () calc_val () sort ()

COTAŢIE

……………….. ……………….

redă_simbol () calc_oscilatie () calcul_val () forecast_cotaţie () selecţie () list_max () list_min () list_înch ()

DERIVAT Financiar

……………… ………………

actual_scad () calc_rentab () calc_risc () calc_volatilit () calc_candidat () calc_%invest ()

TRANZACŢIE

……………….. ………………..

list () calc_val () sumarize ()

PORTOFOLIU

……………… ……………… calc_rentab () calc_risc () calc_volatilit () list ()

102

5 COTAŢII PORTOFOLIU Verificări diverse

6 TRADER PORTOFOLIU Decizia constituire

portofoliu strategic PS, PAS, SC

7 TRADER PORTOFOLIU

Prognoze privind

evoluţia cotaţiilor pentru

derivatele din structura

portofoliului

Grafice

8 TRANZACŢII TRADER

Efectuare tranzacţii

menţine/îmbunătăţii

structura portofoli

OV/OC, CO

Specificarea operaţiilor şi identificarea metodele asociate claselor

Procesele din diagrama fluxului de date vor fi implementate ca operaţii

ale obiectelor considerate în modelul obiectelor. Aceste operaţii garantează că

informaţiile adecvate sunt disponibile pentru obţinerea şi administrarea

eficientă a portofoliului strategic şi pentru a susţine managementul

operaţiunilor cu produse financiare derivate. Aşadar, pentru a finaliza modelul

funcţional, procedăm la specificarea operaţiilor asociate claselor, respectând

modul de reprezentare a acestora.

Figura 3.16. – Operații asociate claselor pentru asistare adeciziei în


CLIENT

………………

adaugă () şterge () list_date_id ()

OPERATOR

……………….. ………………..adaugă () şterge () cotizează ()

ORDIN

………………………… list () calc_val () sort ()

COTAŢIE

……………….. ……………….

redă_simbol () calc_oscilatie () calcul_val () forecast_cotaţie () selecţie () list_max () list_min () list_înch ()

DERIVAT Financiar

……………… ………………

actual_scad () calc_rentab () calc_risc () calc_volatilit () calc_candidat () calc_%invest ()

TRANZACŢIE

……………….. ………………..

list () calc_val () sumarize ()

PORTOFOLIU

……………… ……………… calc_rentab () calc_risc () calc_volatilit () list ()


103

Utilizând cunoştinţele despre operaţiile utile şi modelul obiectelor care a

identificat clasele necesare, acum se pot stabili ce metode sunt necesare şi

căror clase ar trebui să aparţină. În funcţie de operaţiile specificate putem

identifica trei tipuri de metode necesare pentru asigurarea funcţionalităţii

sistemului interactiv de asistare a deciziei:

metode de tip constructori şi destructori - generează noi instanţe ale

clasei, respectiv şterg instanţele care nu mai sunt utile:

adaugă_operator () adaugă_client ()

şterge_operator () şterge_client ()

metode de acces - returnează valoarea unui atribut sau a unui set de

atribute ale instanţei unei clase. Ele pot returna valoarea unui singur

atribut, valorile multiple ale atributelor sau o colecţie de valori. De

exemplu pentru clasa Cotaţie există metoda Get_simbol care returnează

simbolul ataşat unui produs financiar derivat sau în clasa Derivat

financiar există metoda Get_rentabilit, care determină rentabilitatea

tuturor produselor financiare derivate. De asemenea, o metodă de acces

poate deriva date dintr-un atribut, aşa cum este cazul metodei

Get_oscilaţie, care va calcula oscilaţiile de preţ ale activelor din atributul

ce reprezintă preţul.

metode de transformare - schimbă starea instanţei unei clase. De

exemplu metoda Forecast_cotaţii a clasei Cotaţie aproximează evoluţia

preţurilor de cotare cu o valoarea specificată de metoda regresiilor.

3.3.2. Facilităţi de interogare a datelor

Interogarea bazei de date permite transformarea datelor brute ale bazei

de date într-o recoltă bogată de informaţii utile. Este de apreciat modul în care

interogările şi o bază de date bine proiectată, permit satisfacerea cerinţelor de

informaţii care nu au fost anticipate atunci când baza de date a fost creată

pentru prima dată.

Pentru a accesa baza de date proprie sistemului de asistare a deciziei

am utilizat în codul sursă Visual C++ al aplicaţiei un API20 pentru baze de date,

care a oferit posibilitatea de a uni forţele limbajului Visual C++ şi SQL.

20 Applications Programming Interface

103

Utilizând cunoştinţele despre operaţiile utile şi modelul obiectelor care a

identificat clasele necesare, acum se pot stabili ce metode sunt necesare şi

căror clase ar trebui să aparţină. În funcţie de operaţiile specificate putem

identifica trei tipuri de metode necesare pentru asigurarea funcţionalităţii

sistemului interactiv de asistare a deciziei:

metode de tip constructori şi destructori - generează noi instanţe ale

clasei, respectiv şterg instanţele care nu mai sunt utile:

adaugă_operator () adaugă_client ()

şterge_operator () şterge_client ()

metode de acces - returnează valoarea unui atribut sau a unui set de

atribute ale instanţei unei clase. Ele pot returna valoarea unui singur

atribut, valorile multiple ale atributelor sau o colecţie de valori. De

exemplu pentru clasa Cotaţie există metoda Get_simbol care returnează

simbolul ataşat unui produs financiar derivat sau în clasa Derivat

financiar există metoda Get_rentabilit, care determină rentabilitatea

tuturor produselor financiare derivate. De asemenea, o metodă de acces

poate deriva date dintr-un atribut, aşa cum este cazul metodei

Get_oscilaţie, care va calcula oscilaţiile de preţ ale activelor din atributul

ce reprezintă preţul.

metode de transformare - schimbă starea instanţei unei clase. De

exemplu metoda Forecast_cotaţii a clasei Cotaţie aproximează evoluţia

preţurilor de cotare cu o valoarea specificată de metoda regresiilor.

3.3.2. Facilităţi de interogare a datelor

Interogarea bazei de date permite transformarea datelor brute ale bazei

de date într-o recoltă bogată de informaţii utile. Este de apreciat modul în care

interogările şi o bază de date bine proiectată, permit satisfacerea cerinţelor de

informaţii care nu au fost anticipate atunci când baza de date a fost creată

pentru prima dată.

Pentru a accesa baza de date proprie sistemului de asistare a deciziei

am utilizat în codul sursă Visual C++ al aplicaţiei un API20 pentru baze de date,

care a oferit posibilitatea de a uni forţele limbajului Visual C++ şi SQL.

20 Applications Programming Interface


104

Compilatoarele de Visual C++ nu ştiu SQL, iar interpretoarele de SQL

nu ştiu C++. În consecinţă s-a folosit un API21 pentru bazele de date care

funcţionează ca un translator între ele şi oferă programelor C++ o metodă de

comunicare cu bazele de date, realizând translatarea între sistemul de tipuri al

bazei de date şi sistemul de tipuri din C++. În acest fel, se creează o cale de a

trimite bazei de date instrucţiuni SQL care să fie executate de către

interpretorul bazei de date şi apoi, de a aduce setul de rezultate în variabilele

programului C++.

Unele API-uri de baze de date sunt specifice anumitor baze de date şi

sunt create astfel încât să lucreze numai cu bazele de date ale unui anumit

producător. Alte API-uri de baze de date încearcă să ofere o interfaţă deschisă

către mai multe baze de date. ODBC (Open DataBase Conectiviti) este un API

care încearcă să furnizeze o interfaţă deschisă către toate bazele de date, dar

OLE DB (Object Linking Enbending DataBase) este mai nou, mai modern şi

mai bogat în facilităţi, fiind înlocuitorul venerabilului ODBC.

ActiveX Data Objects22 (ADO) este un API de nivel înalt, plasat

deasupra lui OLE DB, care furnizează un model obiect ce încapsulează

procesul de comunicare cu bazele de date atât din programele C++, cât şi din

alte limbaje de programare. În acest sens, ADO oferă o interfaţă dublă, care

face posibilă utilizarea sa atât din limbaje de scriptare, cum sunt VBScript şi

JavaScript, cât şi din C++. În acelaşi timp, modelul ADO pune la dispoziţie un

set de clase care simplifică procesul de creare a secvenţelor de operaţii din

programele C++, cum ar fi:

Conectarea la o sursă de date;

Precizarea unei interogări pentru sursa de date;

Executarea interogării;

Aducerea datelor din interogare într-un obiect de interfaţă care poate

fi accesat cu uşurinţă din programele C++;

Dacă este necesar, actualizarea sursei de date pentru a reflecta

modificările făcute asupra datelor;

Furnizarea unui mecanism general pentru detecţia erorilor.

În ceea ce priveşte baza de date proprie sistemului suport, s-au folosit

obiecte de tip ADO pentru a facilita interogarea acesteia, răspunzând în

acelaşi timp necesităţilor de actualizare a datelor.

21 http://techterms.com/definition/api 22 https://support.microsoft.com/en-us/kb/183606

104

Compilatoarele de Visual C++ nu ştiu SQL, iar interpretoarele de SQL

nu ştiu C++. În consecinţă s-a folosit un API21 pentru bazele de date care

funcţionează ca un translator între ele şi oferă programelor C++ o metodă de

comunicare cu bazele de date, realizând translatarea între sistemul de tipuri al

bazei de date şi sistemul de tipuri din C++. În acest fel, se creează o cale de a

trimite bazei de date instrucţiuni SQL care să fie executate de către

interpretorul bazei de date şi apoi, de a aduce setul de rezultate în variabilele

programului C++.

Unele API-uri de baze de date sunt specifice anumitor baze de date şi

sunt create astfel încât să lucreze numai cu bazele de date ale unui anumit

producător. Alte API-uri de baze de date încearcă să ofere o interfaţă deschisă

către mai multe baze de date. ODBC (Open DataBase Conectiviti) este un API

care încearcă să furnizeze o interfaţă deschisă către toate bazele de date, dar

OLE DB (Object Linking Enbending DataBase) este mai nou, mai modern şi

mai bogat în facilităţi, fiind înlocuitorul venerabilului ODBC.

ActiveX Data Objects22 (ADO) este un API de nivel înalt, plasat

deasupra lui OLE DB, care furnizează un model obiect ce încapsulează

procesul de comunicare cu bazele de date atât din programele C++, cât şi din

alte limbaje de programare. În acest sens, ADO oferă o interfaţă dublă, care

face posibilă utilizarea sa atât din limbaje de scriptare, cum sunt VBScript şi

JavaScript, cât şi din C++. În acelaşi timp, modelul ADO pune la dispoziţie un

set de clase care simplifică procesul de creare a secvenţelor de operaţii din

programele C++, cum ar fi:

Conectarea la o sursă de date;

Precizarea unei interogări pentru sursa de date;

Executarea interogării;

Aducerea datelor din interogare într-un obiect de interfaţă care poate

fi accesat cu uşurinţă din programele C++;

Dacă este necesar, actualizarea sursei de date pentru a reflecta

modificările făcute asupra datelor;

Furnizarea unui mecanism general pentru detecţia erorilor.

În ceea ce priveşte baza de date proprie sistemului suport, s-au folosit

obiecte de tip ADO pentru a facilita interogarea acesteia, răspunzând în

acelaşi timp necesităţilor de actualizare a datelor.

21 http://techterms.com/definition/api 22 https://support.microsoft.com/en-us/kb/183606


105

Specificăm astfel că, pentru conexiunea cu sursa de date s-a utilizat

obiectul ADO Connection care, a oferit, în ipostaza de programator, date

membre pentru numele furnizorului OLE DB, numele sursei de date, numele

utilizatorului, parola şi aşa mai departe. Ideea este că avem posibilitatea de a

seta datele membre ale obiectului Connection pentru a apela funcţia membră

Open stabilind conexiunea, respectiv Close pentru a închide conexiunea,

funcţia Execute pentru trimiterea de interogări, funcţiile AddNew, Update şi

Delete pentru actualizarea bazei noastre de date dar şi Save pentru salvarea

înregistrărilor. Metoda folosită pentru actualizarea înregistrărilor este aceea de

creare a unui obiect Recordset şi de apelare a funcţiilor sale membre pentru a

adăuga, modifica sau şterge. Modificările făcute asupra obiectului Recordset

se aplică asupra bazei de date, astfel că, modificând înregistrările din

Recordset se vor schimba înregistrările din baza de date.

3.4. Managementul modelelor. Structura bazei de modele a sistemului

Ca şi datele, modelele reprezintă una din resursele de elemente, prin

care pot fi cunoscute, înţelese şi rezolvate problemele decizionale.

În interiorul unui sistem suport de asistare a deciziei (SSD) pot coezista

mai multe modele (statistice, financiare, de previziune sau strategice, tactice,

operative, etc.), care conferă sistemului capacitatea de a analiza şi soluţiona

problemele de decizie.

Managementului modelelor îi revine astfel sarcina de a administra şi

exploata modelele grupate într-o bază de modele, dar şi rolul de a crea noi

modele utilizând limbajele de programare, instrumente de asistare a deciziei

sau subrutine, de a actualiza modelele existente, fiind capabil să coreleze

modele prin intermediul unei baze de date.

În concordanţă cu cele exprimate anterior, evidenţiem principalele funcţii

recomandate pentru managementul modelelor de specialişti ca Turban,

Aronson 2001, Marakas 2003 citaţi de Filip, Ghe. în lucrare (Filip, 2002):

- crearea algoritmilor de rezolvare a modelelor în vederea stocării

acestora în baza de modele;

- întreţinerea bazei de modele prin operaţii de actualizare şi extindere;

- selectarea şi pregătirea în vederea execuţiei a unor modele existente şi

a algoritmilor de rezolvare în scopul asistării activităţilor de soluţionare

a problemelor decizionale; această funcţie poate să implice crearea

105

Specificăm astfel că, pentru conexiunea cu sursa de date s-a utilizat

obiectul ADO Connection care, a oferit, în ipostaza de programator, date

membre pentru numele furnizorului OLE DB, numele sursei de date, numele

utilizatorului, parola şi aşa mai departe. Ideea este că avem posibilitatea de a

seta datele membre ale obiectului Connection pentru a apela funcţia membră

Open stabilind conexiunea, respectiv Close pentru a închide conexiunea,

funcţia Execute pentru trimiterea de interogări, funcţiile AddNew, Update şi

Delete pentru actualizarea bazei noastre de date dar şi Save pentru salvarea

înregistrărilor. Metoda folosită pentru actualizarea înregistrărilor este aceea de

creare a unui obiect Recordset şi de apelare a funcţiilor sale membre pentru a

adăuga, modifica sau şterge. Modificările făcute asupra obiectului Recordset

se aplică asupra bazei de date, astfel că, modificând înregistrările din

Recordset se vor schimba înregistrările din baza de date.

3.4. Managementul modelelor. Structura bazei de modele a sistemului

Ca şi datele, modelele reprezintă una din resursele de elemente, prin

care pot fi cunoscute, înţelese şi rezolvate problemele decizionale.

În interiorul unui sistem suport de asistare a deciziei (SSD) pot coezista

mai multe modele (statistice, financiare, de previziune sau strategice, tactice,

operative, etc.), care conferă sistemului capacitatea de a analiza şi soluţiona

problemele de decizie.

Managementului modelelor îi revine astfel sarcina de a administra şi

exploata modelele grupate într-o bază de modele, dar şi rolul de a crea noi

modele utilizând limbajele de programare, instrumente de asistare a deciziei

sau subrutine, de a actualiza modelele existente, fiind capabil să coreleze

modele prin intermediul unei baze de date.

În concordanţă cu cele exprimate anterior, evidenţiem principalele funcţii

recomandate pentru managementul modelelor de specialişti ca Turban,

Aronson 2001, Marakas 2003 citaţi de Filip, Ghe. în lucrare (Filip, 2002):

- crearea algoritmilor de rezolvare a modelelor în vederea stocării

acestora în baza de modele;

- întreţinerea bazei de modele prin operaţii de actualizare şi extindere;

- selectarea şi pregătirea în vederea execuţiei a unor modele existente şi

a algoritmilor de rezolvare în scopul asistării activităţilor de soluţionare

a problemelor decizionale; această funcţie poate să implice crearea


106

unor modele complexe prin compoziţia sau integrarea unor modele

existente.

- execuţia modelelor cu seturile de date, urmată de evaluarea

rezultatelor şi eventuala reluare a calculelor cu alte seturi de date.

Cele arătate mai sus presupun existenţa mai multor elemente: un limbaj

de modelare menit să asigure formularea, compoziţia, integrarea şi încărcarea

modelelor în baza de modele şi algoritmi de rezolvare, o bază de modele şi

algoritmi de rezolvare uşor accesibili, o schemă de manevrare a modelelor şi

algoritmilor care să permită selectarea (apelarea) în vederea execuţiei.

Înainte de a trece la reprezentarea structurii bazei de modele,

considerăm că este necesar ca mai întâi să realizăm o clasificare a modelelor

urmărind criteriile recomandate de literatura de specialitate23, pentru că în

acest fel vom reuşi să identificăm categoriile de modele utilizate de sistemul

suport pentru asustarea deciziei în managementul de portofoliu (Ungureanu

2002), (Jaramillo 2005).

Sublinierile au fost realizate pentru a evidenţia categoria de modele care

alcătuiesc baza de modele a sistemului suport. Astfel, distingem în funcţie de:

- prezenţa sau absenţa variabilei timp în forma modelelor, acestea pot fi

dinamice, respectiv statice. Modelele dinamice pot fi cu timp continuu şi

îmbracă forma unor ecuaţii diferenţiale sau cu timp discret şi îmbracă forma

unor ecuaţii cu diferenţe;

- gradul de incertitudine, distingem modele deterministe şi probabilistice.

Deşi majoritatea situaţiilor decizionale comportă un grad însemnat de

incertitudine, se preferă modelele deterministe deoarece sunt mai simplu de

construit şi de utilizat şi uneori furnizează rezultate considerate satisfăcătoare

prin prisma scopului urmărit. Toate modelele folosite de aplicaţiile sistemului

suport sunt deterministe.

- gradul de generalitate. Din acest punct de vedere, modelele utilizabile

pentru o clasă de probleme decizionale sunt generalizabile iar cele utilizate

numai într-o singură aplicaţie sunt „modele pe măsură”, elaborate anume

deoarece fie nu există modele „de gata” adecvate, fie că a fost nevoie de o

completare a bazei de modele în scopul personalizării. De cele mai multe ori,

modelele pe măsură sunt mai fidele şi mai performante dar au un cost al

instruirii şi întreţinerii mai ridicat. Baza de modele a sistemului suport conţine

23 Hattenschwiler, P., Decision Support Systems, University of Fribourg, Department of

Informatics, DS Group, http://diuf.unifr.ch/ds/courses/dss2002

106

unor modele complexe prin compoziţia sau integrarea unor modele

existente.

- execuţia modelelor cu seturile de date, urmată de evaluarea

rezultatelor şi eventuala reluare a calculelor cu alte seturi de date.

Cele arătate mai sus presupun existenţa mai multor elemente: un limbaj

de modelare menit să asigure formularea, compoziţia, integrarea şi încărcarea

modelelor în baza de modele şi algoritmi de rezolvare, o bază de modele şi

algoritmi de rezolvare uşor accesibili, o schemă de manevrare a modelelor şi

algoritmilor care să permită selectarea (apelarea) în vederea execuţiei.

Înainte de a trece la reprezentarea structurii bazei de modele,

considerăm că este necesar ca mai întâi să realizăm o clasificare a modelelor

urmărind criteriile recomandate de literatura de specialitate23, pentru că în

acest fel vom reuşi să identificăm categoriile de modele utilizate de sistemul

suport pentru asustarea deciziei în managementul de portofoliu (Ungureanu

2002), (Jaramillo 2005).

Sublinierile au fost realizate pentru a evidenţia categoria de modele care

alcătuiesc baza de modele a sistemului suport. Astfel, distingem în funcţie de:

- prezenţa sau absenţa variabilei timp în forma modelelor, acestea pot fi

dinamice, respectiv statice. Modelele dinamice pot fi cu timp continuu şi

îmbracă forma unor ecuaţii diferenţiale sau cu timp discret şi îmbracă forma

unor ecuaţii cu diferenţe;

- gradul de incertitudine, distingem modele deterministe şi probabilistice.

Deşi majoritatea situaţiilor decizionale comportă un grad însemnat de

incertitudine, se preferă modelele deterministe deoarece sunt mai simplu de

construit şi de utilizat şi uneori furnizează rezultate considerate satisfăcătoare

prin prisma scopului urmărit. Toate modelele folosite de aplicaţiile sistemului

suport sunt deterministe.

- gradul de generalitate. Din acest punct de vedere, modelele utilizabile

pentru o clasă de probleme decizionale sunt generalizabile iar cele utilizate

numai într-o singură aplicaţie sunt „modele pe măsură”, elaborate anume

deoarece fie nu există modele „de gata” adecvate, fie că a fost nevoie de o

completare a bazei de modele în scopul personalizării. De cele mai multe ori,

modelele pe măsură sunt mai fidele şi mai performante dar au un cost al

instruirii şi întreţinerii mai ridicat. Baza de modele a sistemului suport conţine

23 Hattenschwiler, P., Decision Support Systems, University of Fribourg, Department of

Informatics, DS Group, http://diuf.unifr.ch/ds/courses/dss2002


107

modele generalizabile dar a fost extinsă pentru a conţine şi modele elaborate

pe măsură pentru a reprezenta procesele specifice managementului

operaţiunilor.

- nivelul decizional, se pot distinge modele strategice care servesc la

asistarea stabilirii obiectivelor şi a resurselor necesare pe termen lung, tactice

pentru asistarea elaborării deciziilor de alocare şi control al resurselor, sunt

aplicabile pentru problemele specifice unor părţi din întreprindere şi au

orizonturi de timp medii şi operative care se folosesc pentru asistarea

elaborării deciziilor ce privesc un orizont scurt de timp (ore, zile).

- tipul de problemă, se identifică următoarele clase de modele bine

susţinute de transpuneri profesionale în produse informatice:

modele pentru aplicaţii financiar-contabile, cum sunt: planificarea

bugetelor, analiza indicatorilor economico-financiari;

modele de analiză a deciziilor pentru recomandarea celei mai bune


modele de prognoză pentru a prezice valorile viitoare ale unor variabile

analizând datele acumulate. Ele sunt bazate fie pe analiza seriilor de

timp, fie pe determinarea relaţiilor cauzale (metode de regresie);

modele de simulare care servesc în primul rând la evaluarea

consecinţelor unor alternative.

De menţionat că aceeaşi problemă decizională poate fi reprezentată

prin mai multe modele, iar acelaşi model poate fi rezolvat de mai mulţi

algoritmi. În consecinţă, soluţia adoptată este de cele mai multe ori

dependentă de caracteristicile particulare ale fiecărei probleme decizionale

şi/sau decident. Exact din acest motiv, baza de modele a sistemului suport

conţine ca, urmare a specificului activităţii de management al portofoliului şi a

obiectivelor definite, următoarele tipuri de modele grupate în trei clase

principale:

- modele de calcul a indicatorilor sintetici şi analitici

- modele de prognoză a trendului cotaţiilor

- modele de analiză a deciziei

Toate acestea vor fi analizate rând pe rând şi detaliat din punct de

vedere al implementării lor, folosind Visual C++, un limbaj performant, de

actualitate care şi-a dovedit pe de plin puterea şi fiabilitatea în programarea

problemelor decizionale de acest fel.

107

modele generalizabile dar a fost extinsă pentru a conţine şi modele elaborate

pe măsură pentru a reprezenta procesele specifice managementului

operaţiunilor.

- nivelul decizional, se pot distinge modele strategice care servesc la

asistarea stabilirii obiectivelor şi a resurselor necesare pe termen lung, tactice

pentru asistarea elaborării deciziilor de alocare şi control al resurselor, sunt

aplicabile pentru problemele specifice unor părţi din întreprindere şi au

orizonturi de timp medii şi operative care se folosesc pentru asistarea

elaborării deciziilor ce privesc un orizont scurt de timp (ore, zile).

- tipul de problemă, se identifică următoarele clase de modele bine

susţinute de transpuneri profesionale în produse informatice:

modele pentru aplicaţii financiar-contabile, cum sunt: planificarea

bugetelor, analiza indicatorilor economico-financiari;

modele de analiză a deciziilor pentru recomandarea celei mai bune


modele de prognoză pentru a prezice valorile viitoare ale unor variabile

analizând datele acumulate. Ele sunt bazate fie pe analiza seriilor de

timp, fie pe determinarea relaţiilor cauzale (metode de regresie);

modele de simulare care servesc în primul rând la evaluarea

consecinţelor unor alternative.

De menţionat că aceeaşi problemă decizională poate fi reprezentată

prin mai multe modele, iar acelaşi model poate fi rezolvat de mai mulţi

algoritmi. În consecinţă, soluţia adoptată este de cele mai multe ori

dependentă de caracteristicile particulare ale fiecărei probleme decizionale

şi/sau decident. Exact din acest motiv, baza de modele a sistemului suport

conţine ca, urmare a specificului activităţii de management al portofoliului şi a

obiectivelor definite, următoarele tipuri de modele grupate în trei clase

principale:

- modele de calcul a indicatorilor sintetici şi analitici

- modele de prognoză a trendului cotaţiilor

- modele de analiză a deciziei

Toate acestea vor fi analizate rând pe rând şi detaliat din punct de

vedere al implementării lor, folosind Visual C++, un limbaj performant, de

actualitate care şi-a dovedit pe de plin puterea şi fiabilitatea în programarea

problemelor decizionale de acest fel.


108

3.4.1. Modele de calcul a indicatorilor sintetici şi analitici

Delimităm structura fiecărei grupe de indicatori pentru a nu crea

ambiguitate în interpretarea lor, şi precizăm că modelele din această clasă

facilitează înţelegerea unor situaţii decizionale, sunt dinamice, deterministe,

construite pe măsură şi au un număr mare de variabile agregate.

De asemenea, realizăm implementarea în Visual C++, a algoritmilor

stabiliţi cu ocazia definirii modelului decizional care susţine, din punct de

vedere teoretic, întregul demers de construire a ©XTrade ca sistem interactiv


Indicatori analitici

Rentabilitate (Ri) active derivate/active suport

Risc (σi) active derivate/active suport

Volatilitate (βi) active derivate/active suport

Risc (σM) piaţă

Rentabilitatea pieţei (RM)

Indicatori sintetici

Exces de randament (γi) Rentabilitate (Rp) portofoliu

Punct critic (Ci) Risc (σp) portofoliu

% de investire (Xi) Volatilitate (βp) portofoliu

Listing-ul codului sursă relevă definirea unor funcţii principale: Get_Ri,

Get_Rm, Get_Rf, Get_Beta, Get_SigmaM, Get_Exces_rand, Get_XI, care vor

memora modelele de calcul ale indicatorilor, necesari stabilirii parametrilor

derivatelor financiare/activelor suport cu scopul de a construi un portofoliu

strategic şi a unuia secundar.

// OpTabel.cpp: implementation of the OpTabel class. ////////////////////////////////////////////////////////// #include "stdafx.h" #include "OpTabel.h" #include <math.h>

#ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif ////////////////////////////////////////////////////////// // Construction/Destruction

108

3.4.1. Modele de calcul a indicatorilor sintetici şi analitici

Delimităm structura fiecărei grupe de indicatori pentru a nu crea

ambiguitate în interpretarea lor, şi precizăm că modelele din această clasă

facilitează înţelegerea unor situaţii decizionale, sunt dinamice, deterministe,

construite pe măsură şi au un număr mare de variabile agregate.

De asemenea, realizăm implementarea în Visual C++, a algoritmilor

stabiliţi cu ocazia definirii modelului decizional care susţine, din punct de

vedere teoretic, întregul demers de construire a ©XTrade ca sistem interactiv


Indicatori analitici

Rentabilitate (Ri) active derivate/active suport

Risc (σi) active derivate/active suport

Volatilitate (βi) active derivate/active suport

Risc (σM) piaţă

Rentabilitatea pieţei (RM)

Indicatori sintetici

Exces de randament (γi) Rentabilitate (Rp) portofoliu

Punct critic (Ci) Risc (σp) portofoliu

% de investire (Xi) Volatilitate (βp) portofoliu

Listing-ul codului sursă relevă definirea unor funcţii principale: Get_Ri,

Get_Rm, Get_Rf, Get_Beta, Get_SigmaM, Get_Exces_rand, Get_XI, care vor

memora modelele de calcul ale indicatorilor, necesari stabilirii parametrilor

derivatelor financiare/activelor suport cu scopul de a construi un portofoliu

strategic şi a unuia secundar.

// OpTabel.cpp: implementation of the OpTabel class. ////////////////////////////////////////////////////////// #include "stdafx.h" #include "OpTabel.h" #include <math.h>

#ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif ////////////////////////////////////////////////////////// // Construction/Destruction


109

////////////////////////////////////////////////////////// OpTabel::OpTabel() { } void OpTabel::AddLine(OpTabel::tabel **a,OpTabel::tabel** u,OpTabel::tabel p) { OpTabel::tabel *q; q=new OpTabel::tabel; q->BET=p.BET; q->data=p.data; q->RUEJDD=p.RUEJDD; q->AF=p.AF; q->next=NULL; if((*a)==NULL) *a=q; else (*u)->next=q; *u=q; }

floatOpTabel::Get_Ri(OpTabel::tabel *a, int n,int type)

{ tabel *aux,*aux2; float ret_val=0.0; if(a==NULL) return 0.0; else if(n==1) return Get_Ri(a,2,type); aux2=a; aux=a->next; int i=2; while((i<n)&&(aux!=NULL)) { aux=aux->next; aux2=aux2->next; i++; } float x,y; if(aux!=NULL) { if(type==2) return aux->RUEJDD; x=aux->RUEJDD;

109

////////////////////////////////////////////////////////// OpTabel::OpTabel() { } void OpTabel::AddLine(OpTabel::tabel **a,OpTabel::tabel** u,OpTabel::tabel p) { OpTabel::tabel *q; q=new OpTabel::tabel; q->BET=p.BET; q->data=p.data; q->RUEJDD=p.RUEJDD; q->AF=p.AF; q->next=NULL; if((*a)==NULL) *a=q; else (*u)->next=q; *u=q; }

floatOpTabel::Get_Ri(OpTabel::tabel *a, int n,int type)

{ tabel *aux,*aux2; float ret_val=0.0; if(a==NULL) return 0.0; else if(n==1) return Get_Ri(a,2,type); aux2=a; aux=a->next; int i=2; while((i<n)&&(aux!=NULL)) { aux=aux->next; aux2=aux2->next; i++; } float x,y; if(aux!=NULL) { if(type==2) return aux->RUEJDD; x=aux->RUEJDD;


110

y=aux2->RUEJDD; ret_val=(x-y)/y; } else return 0.0; return ret_val; } floatOpTabel::Get_Rf(OpTabel:tabel*a, int n,int type) { int date1,date3; tabel *aux,*aux3,*aux1; int i=1; float ret_val; aux=a; if(aux==NULL) return 0.0; while((aux!=NULL)&&(i<n)) { aux=aux->next; i++; } date3=aux->data.GetMonth(); aux3=aux; aux=a; date1=aux->data.GetMonth(); aux1=aux; if(date1==date3) return Get_Rf(a,n+1,type); i=1; while((aux->data.GetMonth()!=date3)&&(aux!=NULL)&&(i<n)) { if(date1!=aux->data.GetMonth()) { date1=aux->data.GetMonth(); aux1=aux; } aux=aux->next; i++; } if(aux->data.GetMonth()==date3) { float x,y; x=aux->AF;

110

y=aux2->RUEJDD; ret_val=(x-y)/y; } else return 0.0; return ret_val; } floatOpTabel::Get_Rf(OpTabel:tabel*a, int n,int type) { int date1,date3; tabel *aux,*aux3,*aux1; int i=1; float ret_val; aux=a; if(aux==NULL) return 0.0; while((aux!=NULL)&&(i<n)) { aux=aux->next; i++; } date3=aux->data.GetMonth(); aux3=aux; aux=a; date1=aux->data.GetMonth(); aux1=aux; if(date1==date3) return Get_Rf(a,n+1,type); i=1; while((aux->data.GetMonth()!=date3)&&(aux!=NULL)&&(i<n)) { if(date1!=aux->data.GetMonth()) { date1=aux->data.GetMonth(); aux1=aux; } aux=aux->next; i++; } if(aux->data.GetMonth()==date3) { float x,y; x=aux->AF;


111

y=aux1->AF; ret_val=(x-y)/y; } return ret_val; } floatOpTabel::Get_Beta(OpTabel::tabel *a,int type) { float sum1=0.0,sum2=0.0; tabel *aux; int i=1; float ret_val; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum1+=Get_A_B(a,i,type); sum2+=Get_B_B(a,i,type); i++; aux=aux->next; } if(type==2) type=2; ret_val=sum1/sum2; return ret_val; } float OpTabel::Get_SigmaM(OpTabel::tabel *a,int type) { float ret_val; float sum=0.0; int i=1; tabel *aux; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum+=Get_Rm_Rm_mediu_B(a,i,type); i++; aux=aux->next; } i--; ret_val=sqrt(fabs(sum/i));

111

y=aux1->AF; ret_val=(x-y)/y; } return ret_val; } floatOpTabel::Get_Beta(OpTabel::tabel *a,int type) { float sum1=0.0,sum2=0.0; tabel *aux; int i=1; float ret_val; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum1+=Get_A_B(a,i,type); sum2+=Get_B_B(a,i,type); i++; aux=aux->next; } if(type==2) type=2; ret_val=sum1/sum2; return ret_val; } float OpTabel::Get_SigmaM(OpTabel::tabel *a,int type) { float ret_val; float sum=0.0; int i=1; tabel *aux; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum+=Get_Rm_Rm_mediu_B(a,i,type); i++; aux=aux->next; } i--; ret_val=sqrt(fabs(sum/i));


112

return ret_val; } floatOpTabel::Get_CI(OpTabel::tabel *a,int type) { float ret_val; int i=1; float sum1=0.0,sum2=0.0; tabel *aux; float SigmaM=Get_SigmaM(a,type); float SigmaI=Get_Sigma_I_Patrat(a,type); SigmaM=SigmaM*SigmaM; SigmaI=SigmaI*SigmaI; float Beta=Get_Beta(a,type); aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum1+=Get_Ri(a,i,type); sum2+=Get_Rf(a,i,type); aux=aux->next; i++; } sum1/=i; sum2/=i; //ret_val=(sum1-sum2)/(Beta*SigmaI)*SigmaM; ret_val=sqrt(SigmaM)*Get_Exces_rand(a,type)/sqrt(SigmaI); ret_val/=1+SigmaM*Beta/SigmaI; return ret_val; } floatOpTabel::Get_ZI(OpTabel::tabel *a,float c_star,int type) { float ret_val; float beta,exces,CI; float sigmaI=Get_Sigma_I_Patrat(a,type); beta=Get_Beta(a,type); exces=Get_Exces_rand(a,type); CI=c_star; ret_val=beta*(exces-c_star)/(sigmaI); return ret_val; } floatOpTabel::Get_Exces_rand(OpTabel::tabel *a,int type) {

112

return ret_val; } floatOpTabel::Get_CI(OpTabel::tabel *a,int type) { float ret_val; int i=1; float sum1=0.0,sum2=0.0; tabel *aux; float SigmaM=Get_SigmaM(a,type); float SigmaI=Get_Sigma_I_Patrat(a,type); SigmaM=SigmaM*SigmaM; SigmaI=SigmaI*SigmaI; float Beta=Get_Beta(a,type); aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { sum1+=Get_Ri(a,i,type); sum2+=Get_Rf(a,i,type); aux=aux->next; i++; } sum1/=i; sum2/=i; //ret_val=(sum1-sum2)/(Beta*SigmaI)*SigmaM; ret_val=sqrt(SigmaM)*Get_Exces_rand(a,type)/sqrt(SigmaI); ret_val/=1+SigmaM*Beta/SigmaI; return ret_val; } floatOpTabel::Get_ZI(OpTabel::tabel *a,float c_star,int type) { float ret_val; float beta,exces,CI; float sigmaI=Get_Sigma_I_Patrat(a,type); beta=Get_Beta(a,type); exces=Get_Exces_rand(a,type); CI=c_star; ret_val=beta*(exces-c_star)/(sigmaI); return ret_val; } floatOpTabel::Get_Exces_rand(OpTabel::tabel *a,int type) {


113

float ret_val; float RI=0.0,RF=0.0; float beta; tabel *aux; int i=1; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { RI+=Get_Ri(a,i,type); RF+=Get_Rf(a,i,type); aux=aux->next; i++; } beta=Get_Beta(a,type); RI/=i; RF/=i; ret_val=(RI-RF)/beta; return ret_val; } floatOpTabel::Get_XI(OpTabel::tabel*a,OpTabel::tabel*b,OpTabel::tabel*c,OpTabel::tabel*d,OpTabel::tabel*e,OpTabel::tabel*f,OpTabel::tabel *k,OpTabel::tabel) { float ret_val; float sum=0.0; float zi=0.0; zi=Get_ZI(a,c_star,1); if(Get_Exces_rand(a,1)-Get_CI(a,1)>0) sum+=zi; else return 0.0; zi=Get_ZI(b,c_star,1); if(Get_Exces_rand(b,1)-Get_CI(b,1)>0) sum+=zi; zi=Get_ZI(c,c_star,1); if(Get_Exces_rand(c,1)-Get_CI(c,1)>0) sum+=zi; zi=Get_ZI(d,c_star,1); if(Get_Exces_rand(d,1)-Get_CI(d,1)>0) sum+=zi; zi=Get_ZI(e,c_star,1); if(Get_Exces_rand(e,1)-Get_CI(e,1)>0)

113

float ret_val; float RI=0.0,RF=0.0; float beta; tabel *aux; int i=1; aux=a; if(aux==NULL) return 0.0; while(aux!=NULL) { RI+=Get_Ri(a,i,type); RF+=Get_Rf(a,i,type); aux=aux->next; i++; } beta=Get_Beta(a,type); RI/=i; RF/=i; ret_val=(RI-RF)/beta; return ret_val; } floatOpTabel::Get_XI(OpTabel::tabel*a,OpTabel::tabel*b,OpTabel::tabel*c,OpTabel::tabel*d,OpTabel::tabel*e,OpTabel::tabel*f,OpTabel::tabel *k,OpTabel::tabel) { float ret_val; float sum=0.0; float zi=0.0; zi=Get_ZI(a,c_star,1); if(Get_Exces_rand(a,1)-Get_CI(a,1)>0) sum+=zi; else return 0.0; zi=Get_ZI(b,c_star,1); if(Get_Exces_rand(b,1)-Get_CI(b,1)>0) sum+=zi; zi=Get_ZI(c,c_star,1); if(Get_Exces_rand(c,1)-Get_CI(c,1)>0) sum+=zi; zi=Get_ZI(d,c_star,1); if(Get_Exces_rand(d,1)-Get_CI(d,1)>0) sum+=zi; zi=Get_ZI(e,c_star,1); if(Get_Exces_rand(e,1)-Get_CI(e,1)>0)


114

sum+=zi; zi=Get_ZI(f,c_star,1); if(Get_Exces_rand(f,1)-Get_CI(f,1)>0) sum+=zi; zi=Get_ZI(k,c_star,2); if(Get_Exces_rand(k,2)-Get_CI(k,2)>0) sum+=zi; zi=Get_ZI(j,c_star,2); if(Get_Exces_rand(j,2)-Get_CI(j,2)>0) sum+=zi; if(zi/sum<0) sum-=zi; if(type==2) { ret_val=Get_ZI(k,c_star,2)/sum; if(ret_val<0) { sum-=Get_ZI(k,c_star,2); ret_val=0; } } if(type==3) { ret_val=Get_ZI(j,c_star,2)/sum; if(ret_val<0) { sum-=Get_ZI(j,c_star,2); ret_val=0; } } if(type==1) ret_val=Get_ZI(a,c_star,1)/sum; return ret_val; } float OpTabel::Get_XI(OpTabel::tabel *a,OpTabel::tabel *b,OpTabel::tabel *c,OpTabel::tabel *d,OpTabel::tabel *e,float c_star,int type) { float ret_val; float sum=0.0; float zi=0.0; zi=Get_ZI(a,c_star,type); sum+=zi; if(Get_Exces_rand(a,1)-Get_CI(a,1)<0) sum-=zi;

114

sum+=zi; zi=Get_ZI(f,c_star,1); if(Get_Exces_rand(f,1)-Get_CI(f,1)>0) sum+=zi; zi=Get_ZI(k,c_star,2); if(Get_Exces_rand(k,2)-Get_CI(k,2)>0) sum+=zi; zi=Get_ZI(j,c_star,2); if(Get_Exces_rand(j,2)-Get_CI(j,2)>0) sum+=zi; if(zi/sum<0) sum-=zi; if(type==2) { ret_val=Get_ZI(k,c_star,2)/sum; if(ret_val<0) { sum-=Get_ZI(k,c_star,2); ret_val=0; } } if(type==3) { ret_val=Get_ZI(j,c_star,2)/sum; if(ret_val<0) { sum-=Get_ZI(j,c_star,2); ret_val=0; } } if(type==1) ret_val=Get_ZI(a,c_star,1)/sum; return ret_val; } float OpTabel::Get_XI(OpTabel::tabel *a,OpTabel::tabel *b,OpTabel::tabel *c,OpTabel::tabel *d,OpTabel::tabel *e,float c_star,int type) { float ret_val; float sum=0.0; float zi=0.0; zi=Get_ZI(a,c_star,type); sum+=zi; if(Get_Exces_rand(a,1)-Get_CI(a,1)<0) sum-=zi;


115

zi=Get_ZI(b,c_star,type); sum+=zi; if(Get_Exces_rand(b,1)-Get_CI(b,1)<0) sum-=zi; zi=Get_ZI(c,c_star,type); sum+=zi; if(Get_Exces_rand(c,1)<Get_CI(c,1)) sum-=zi; zi=Get_ZI(d,c_star,type); sum+=zi; if(Get_Exces_rand(d,1)-Get_CI(d,1)<0) sum-=zi; zi=Get_ZI(e,c_star,type); sum+=zi; if(Get_Exces_rand(e,1)-Get_CI(e,1)<0) sum-=zi; ret_val=Get_ZI(a,c_star,type)/sum; return ret_val; } float OpTabel::Get_rentabilitate(OpTabel::tabel *a,int type) { tabel* aux; float ret_val=0.0; int i=0; aux=a; while(aux!=NULL) { i++; ret_val+=Get_Ri(a,i,type); aux=aux->next; } if(i!=0) ret_val/=i; return ret_val;

3.4.2. Modele de prognoză a trendului cotaţiilor

Modelele de prognoză au drept obiectiv anticiparea trendului pe care se

vor înscrie cotaţiile, pe baza informaţiilor trecute. Ele sunt rezolvate în principal

cu metode statistice care stabilesc relaţii de dependenţă între diverse variabile

115

zi=Get_ZI(b,c_star,type); sum+=zi; if(Get_Exces_rand(b,1)-Get_CI(b,1)<0) sum-=zi; zi=Get_ZI(c,c_star,type); sum+=zi; if(Get_Exces_rand(c,1)<Get_CI(c,1)) sum-=zi; zi=Get_ZI(d,c_star,type); sum+=zi; if(Get_Exces_rand(d,1)-Get_CI(d,1)<0) sum-=zi; zi=Get_ZI(e,c_star,type); sum+=zi; if(Get_Exces_rand(e,1)-Get_CI(e,1)<0) sum-=zi; ret_val=Get_ZI(a,c_star,type)/sum; return ret_val; } float OpTabel::Get_rentabilitate(OpTabel::tabel *a,int type) { tabel* aux; float ret_val=0.0; int i=0; aux=a; while(aux!=NULL) { i++; ret_val+=Get_Ri(a,i,type); aux=aux->next; } if(i!=0) ret_val/=i; return ret_val;

3.4.2. Modele de prognoză a trendului cotaţiilor

Modelele de prognoză au drept obiectiv anticiparea trendului pe care se

vor înscrie cotaţiile, pe baza informaţiilor trecute. Ele sunt rezolvate în principal

cu metode statistice care stabilesc relaţii de dependenţă între diverse variabile


116

şi evoluţiile acestora. În termen statistici, legătura între două sau mai multe

variabile se numeşte corelaţie, iar stabilirea tipului de legătură ale unei

variabile numite dependente de una sau mai multe variabile numite

independente se face prin analiza de regresie.

Dependenţa dintre variabile poate fi liniară, exponenţială sau de altă

natură (hiperbolică, putere), pentru fiecare dintre aceste tipuri existând

instrumente statistice de determinare a elementelor modelului de regresie.

Utilizăm şi noi modelul regresiilor pentru a analiza care dintre tipurile de

regresie (liniară, exponenţială, hiperbolică, putere, parabolică) aproximează cel

mai bine trendul cotaţiilor. Modelul de prognoză implementat, în funcţie de

ecuaţiile specifice regresiilor amintite, calculează coeficienţii aferenţi şi

trasează linia de trend.

Totodată, modelul alege tipul de regresie care aproximează cel mai bine

evoluţia cotaţiilor pentru derivatele financiare incluse în portofoliul strategic.

Pentru a realiza acest lucru, se determină o marjă de eroare calculată ca

diferenţă între aria graficului trasat de cotaţiile bursiere şi a aceluia care

identifică trendul în funcţie de regresii; cea mai mică eroare obţinută semnifică

faptul că aceasta aproximează cel mai bine evoluţia cotaţiilor. În funcţie de

aceasta, se vor realiza extrapolări care să furnizeze informaţii cu privire la

nivelul cotaţiei pentru o dată viitoare sau invers: la ce dată se atinge un anumit

nivel.

În continuare, sunt definite modelele matematice ale regresiilor utilizate

de modelul de prognoză, dar şi modalitatea de implementare a lor. În ceea ce

priveşte implementarea, redăm pentru fiecare tip de regresie utilizat procedura

care determină coeficienţii funcţiilor.

Regresia liniară: ibxay

n

1i

n

1i

ii xbnay

n

1i

n

1i

n

1i

2

iiii xbxaxy

Procedura corespunzătoare:

n

i

n

i

ii xbyn

a1 1

1

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

yxnyx

b

1

2

2

1

1 1 1

116

şi evoluţiile acestora. În termen statistici, legătura între două sau mai multe

variabile se numeşte corelaţie, iar stabilirea tipului de legătură ale unei

variabile numite dependente de una sau mai multe variabile numite

independente se face prin analiza de regresie.

Dependenţa dintre variabile poate fi liniară, exponenţială sau de altă

natură (hiperbolică, putere), pentru fiecare dintre aceste tipuri existând

instrumente statistice de determinare a elementelor modelului de regresie.

Utilizăm şi noi modelul regresiilor pentru a analiza care dintre tipurile de

regresie (liniară, exponenţială, hiperbolică, putere, parabolică) aproximează cel

mai bine trendul cotaţiilor. Modelul de prognoză implementat, în funcţie de

ecuaţiile specifice regresiilor amintite, calculează coeficienţii aferenţi şi

trasează linia de trend.

Totodată, modelul alege tipul de regresie care aproximează cel mai bine

evoluţia cotaţiilor pentru derivatele financiare incluse în portofoliul strategic.

Pentru a realiza acest lucru, se determină o marjă de eroare calculată ca

diferenţă între aria graficului trasat de cotaţiile bursiere şi a aceluia care

identifică trendul în funcţie de regresii; cea mai mică eroare obţinută semnifică

faptul că aceasta aproximează cel mai bine evoluţia cotaţiilor. În funcţie de

aceasta, se vor realiza extrapolări care să furnizeze informaţii cu privire la

nivelul cotaţiei pentru o dată viitoare sau invers: la ce dată se atinge un anumit

nivel.

În continuare, sunt definite modelele matematice ale regresiilor utilizate

de modelul de prognoză, dar şi modalitatea de implementare a lor. În ceea ce

priveşte implementarea, redăm pentru fiecare tip de regresie utilizat procedura

care determină coeficienţii funcţiilor.

Regresia liniară: ibxay

n

1i

n

1i

ii xbnay

n

1i

n

1i

n

1i

2

iiii xbxaxy


n

i

n

i

ii xbyn

a1 1

1

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

yxnyx

b

1

2

2

1

1 1 1


117

cfreg* OpTabel::Coef_lin(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=x; sy+=y; sxy+=x*y; sx2+=x*x; n++; aux=aux->next; if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = (sy - coef->b1*sx)/n; return coef; }

Regresia hiperbolică: x

bay

n

1i i

n

1i

i

x

1ba*ny

n

1i2

i

n

1i i

n

1i i

i

x

1b

x

1*a

x

y


cfreg* OpTabel::Coef_hip(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0;

n

i i

n

i

i

xby

na

11

11

n

i i

n

i i

n

i

n

i

n

i i

ii

i

xn

x

x

yny

xb

12

2

1

1 1 1

11

1

117

cfreg* OpTabel::Coef_lin(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=x; sy+=y; sxy+=x*y; sx2+=x*x; n++; aux=aux->next; if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = (sy - coef->b1*sx)/n; return coef; }

Regresia hiperbolică: x

bay

n

1i i

n

1i

i

x

1ba*ny

n

1i2

i

n

1i i

n

1i i

i

x

1b

x

1*a

x

y


cfreg* OpTabel::Coef_hip(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0;

n

i i

n

i

i

xby

na

11

11

n

i i

n

i i

n

i

n

i

n

i i

ii

i

xn

x

x

yny

xb

12

2

1

1 1 1

11

1


118

OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=1L/x; sy+=y; sxy+=y/x; sx2+=1L/(x*x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = (sy - coef->b1*sx)/n; return coef; }

Regresia putere: bx*ay

n

1i

n

1i

n

1i

i2

iii xlnbxlnalnylnxln


cfreg* OpTabel::Coef_put(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays();

n

i

i

n

i

i xbany11

lnln*ln

n

i

n

i

ii xbyn

a1 1

lnln1

ln

118

OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=1L/x; sy+=y; sxy+=y/x; sx2+=1L/(x*x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = (sy - coef->b1*sx)/n; return coef; }

Regresia putere: bx*ay

n

1i

n

1i

n

1i

i2

iii xlnbxlnalnylnxln


cfreg* OpTabel::Coef_put(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays();

n

i

i

n

i

i xbany11

lnln*ln

n

i

n

i

ii xbyn

a1 1

lnln1

ln


119

y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=log(x); sy+=log(y); sxy+=log(x)*log(y); sx2+=log(x)*log(x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n); return coef; }

Regresia exponenţială: x*be*ay

n

1i

n

1i

ii xbalnnyln

n

1i

n

1i

n

1i

iiii xbxalnylnx


cfreg* OpTabel::Coef_exp(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=x; sy+=log(y); sxy+=x*log(y); sx2+=x*x;

n

i

n

i

iii xbyn

a1 1

ln1

ln

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

yxnyx

b

1

2

2

1

1 1 1

lnln

119

y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=log(x); sy+=log(y); sxy+=log(x)*log(y); sx2+=log(x)*log(x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n); return coef; }

Regresia exponenţială: x*be*ay

n

1i

n

1i

ii xbalnnyln

n

1i

n

1i

n

1i

iiii xbxalnylnx


cfreg* OpTabel::Coef_exp(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=x; sy+=log(y); sxy+=x*log(y); sx2+=x*x;

n

i

n

i

iii xbyn

a1 1

ln1

ln

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

yxnyx

b

1

2

2

1

1 1 1

lnln


120

n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n); return coef; }

Regresia logaritmică: xln*bay

n

1i

n

1i

ii xlnbnay


cfreg* OpTabel::Coef_log(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=log(x)*x; sy+=y; sxy+=log(x)*y; sx2+=log(x)*log(x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n);

i

n

i

n

i

n

i

iii xbxaxy

1 1 1

2lnlnln

n

i

n

i

ii xbyn

a1 1

ln1

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

xynyx

b

1

2

2

1

1 1 1

lnln

lnln

120

n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n); return coef; }

Regresia logaritmică: xln*bay

n

1i

n

1i

ii xlnbnay


cfreg* OpTabel::Coef_log(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,sx,sy,sxy,sx2; x=y=sx=sy=sxy=sx2=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { sx+=log(x)*x; sy+=y; sxy+=log(x)*y; sx2+=log(x)*log(x); n++; } aux=aux->next; } if(((sx*sx-n*sx2)==0)||(n==0)) return NULL; cfreg *coef = new cfreg ; coef->b1 = (sx*sy - n*sxy)/(sx*sx - n*sx2); coef->b0 = exp((sy - coef->b1*sx)/n);

i

n

i

n

i

n

i

iii xbxaxy

1 1 1

2lnlnln

n

i

n

i

ii xbyn

a1 1

ln1

n

i

i

n

i

i

n

i

n

i

n

i

iiii

xnx

xynyx

b

1

2

2

1

1 1 1

lnln

lnln


121

return coef; }

Regresia parabolică: 2cxbxay

n

1i

n

1i

n

1i

2

iii xcxbnay

n

1i

3

i

n

1i

n

1i

n

1i

2

iiii xcxbxbyx

n

1i

n

1i

4

i

3

i

n

1i

2

ii

n

1i

2

ixcxbxayx


cfreg* OpTabel::Coef_par(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,s1,s2,s3,s4,s5,s6,s7,det; x=y=s1=s2=s3=s4=s5=s6=s7=det=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { s1+=x; s2+=x*x; s3+=pow(x,3L); s4+=pow(x,4L); s5+=y; s6+=x*y; s7+=x*x*y; n++; } aux=aux->next; } det=n*s2*s4-s1*s1*s4-pow(s2,3L)+2*s2*s2*s3-n*s3*s3; if(det==0) return NULL; cfreg *coef = new cfreg ; coef->b0 = s2*s4*s5/det-s2*s2*s7/det+s6*s3*s2/det-s3*s3*s5/det+s1*s3*s7/det-s1*s4*s6/det; coef->b1 = n*s4*s6/det-s2*s2*s6/det+s1*s2*s7/det-n*s3*s7/det+s2*s3*s5/det-s1*s4*s5/det; coef->b2 = n*s2*s7/det-s2*s2*s5/det+s1*s3*s5/det-n*s3*s6/det+s1*s2*s6/det-s1*s1*s7/det; return coef; }

121

return coef; }

Regresia parabolică: 2cxbxay

n

1i

n

1i

n

1i

2

iii xcxbnay

n

1i

3

i

n

1i

n

1i

n

1i

2

iiii xcxbxbyx

n

1i

n

1i

4

i

3

i

n

1i

2

ii

n

1i

2

ixcxbxayx


cfreg* OpTabel::Coef_par(OpTabel::tabel *a,COleDateTime data1,COleDateTime data2) { if(data2<data1) return NULL; double x,y,s1,s2,s3,s4,s5,s6,s7,det; x=y=s1=s2=s3=s4=s5=s6=s7=det=0; OpTabel::tabel *aux=a; while(aux && (aux->data<data1)) { aux=aux->next; } int n=0; while(aux && (aux->data<=data2)) { x=(aux->data-data1).GetDays(); y=aux->RUEJDD; if((x>0) && (y>0)) { s1+=x; s2+=x*x; s3+=pow(x,3L); s4+=pow(x,4L); s5+=y; s6+=x*y; s7+=x*x*y; n++; } aux=aux->next; } det=n*s2*s4-s1*s1*s4-pow(s2,3L)+2*s2*s2*s3-n*s3*s3; if(det==0) return NULL; cfreg *coef = new cfreg ; coef->b0 = s2*s4*s5/det-s2*s2*s7/det+s6*s3*s2/det-s3*s3*s5/det+s1*s3*s7/det-s1*s4*s6/det; coef->b1 = n*s4*s6/det-s2*s2*s6/det+s1*s2*s7/det-n*s3*s7/det+s2*s3*s5/det-s1*s4*s5/det; coef->b2 = n*s2*s7/det-s2*s2*s5/det+s1*s3*s5/det-n*s3*s6/det+s1*s2*s6/det-s1*s1*s7/det; return coef; }


122

3.4.3. Modele de analiză a deciziei

Modelele de analiză a deciziei sunt utilizate de sistemul suport întrucât

situaţia decizională formulată implică un număr rezonabil şi finit de alternative.

Astfel că, în funcţie de valorile înregistrate de parametrii fiecărui produs

financiar derivat, decizia constă în a alege cele mai bune derivate în funcţie de

cotaţiile pieţei, pentru a construi un portofoliu strategic.

Modelul care analizează decizia de a face parte sau nu din acest

portofoliu este definit de un algoritm robust al cărui cod sursă Visual C++ este

redat mai jos:

// X_TRADEView.cpp : implementation of the CX_TRADEView class //

#include "stdafx.h"

#include "X_TRADE.h"

#include "X_TRADEDoc.h"

#include "start.h"

#include "cotatii.h"

#include "optabel.h"

OnIndateCotatiicontractefutures)

ON_WM_CHAR()

//}}AFX_MSG_MAP

// Standard printing commands

ON_COMMAND(ID_FILE_PRINT, CView::OnFilePrint)

ON_COMMAND(ID_FILE_PRINT_DIRECT, CView::OnFilePrint)

ON_COMMAND(ID_FILE_PRINT_PREVIEW, CView::OnFilePrintPreview)

END_MESSAGE_MAP()

void CX_TRADEView::OnLButtonDown(UINT nFlags, CPoint point)

{

// TODO: Add your message handler code here and/or call default

CX_TRADEDoc* pDoc = GetDocument();

ASSERT_VALID(pDoc);

if(active_frame=="MAIN")

{

if(Get_Sel_Button(point)=="Subs 1")

{

CDC *dc=this->GetDC();

CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_SUBS_12);

bmp.GetBitmap(&bmpInfo);

fundal.SelectObject(&bmp);

122

3.4.3. Modele de analiză a deciziei

Modelele de analiză a deciziei sunt utilizate de sistemul suport întrucât

situaţia decizională formulată implică un număr rezonabil şi finit de alternative.

Astfel că, în funcţie de valorile înregistrate de parametrii fiecărui produs

financiar derivat, decizia constă în a alege cele mai bune derivate în funcţie de

cotaţiile pieţei, pentru a construi un portofoliu strategic.

Modelul care analizează decizia de a face parte sau nu din acest

portofoliu este definit de un algoritm robust al cărui cod sursă Visual C++ este

redat mai jos:

// X_TRADEView.cpp : implementation of the CX_TRADEView class //

#include "stdafx.h"

#include "X_TRADE.h"

#include "X_TRADEDoc.h"

#include "start.h"

#include "cotatii.h"

#include "optabel.h"

OnIndateCotatiicontractefutures)

ON_WM_CHAR()

//}}AFX_MSG_MAP

// Standard printing commands

ON_COMMAND(ID_FILE_PRINT, CView::OnFilePrint)

ON_COMMAND(ID_FILE_PRINT_DIRECT, CView::OnFilePrint)

ON_COMMAND(ID_FILE_PRINT_PREVIEW, CView::OnFilePrintPreview)

END_MESSAGE_MAP()

void CX_TRADEView::OnLButtonDown(UINT nFlags, CPoint point)

{


CX_TRADEDoc* pDoc = GetDocument();

ASSERT_VALID(pDoc);


{


{


CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_SUBS_12);


fundal.SelectObject(&bmp);


123

if(dc->m_hDC!=NULL)

dc->BitBlt(87, 330, bmpInfo.bmWidth, bmpInfo.bmHeight, &fundal,0, 0,

SRCCOPY);

active_button="Subs 1";

}

}

if((active_frame=="Portofoliu1")||(active_frame=="Portofoliu2"))

{

if(Get_Sel_Button(point)=="Parametrii")

{


CDC aux;

CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_PARAMETRII);


aux.CreateCompatibleDC(dc);

aux.SelectObject(&bmp);

if(dc->m_hDC!=NULL)

dc->BitBlt(64, 186, bmpInfo.bmWidth, bmpInfo.bmHeight, &aux,0, 0,

SRCCOPY);

active_button="Parametrii";

}

if(Get_Sel_Button(point)=="Generare")

{

CDC *dc=this->GetDC(),aux;

CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_GENERARE);




if(dc->m_hDC!=NULL)


SRCCOPY);

active_button="Generare";

}

if(Get_Sel_Button(point)=="Management")

{


CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

123

if(dc->m_hDC!=NULL)

dc->BitBlt(87, 330, bmpInfo.bmWidth, bmpInfo.bmHeight, &fundal,0, 0,

SRCCOPY);

active_button="Subs 1";

}

}


{


{


CDC aux;

CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_PARAMETRII);




if(dc->m_hDC!=NULL)


SRCCOPY);

active_button="Parametrii";

}


{


CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////

bmp.LoadBitmap(IDB_GENERARE);




if(dc->m_hDC!=NULL)


SRCCOPY);

active_button="Generare";

}


{


CBitmap bmp;

BITMAP bmpInfo;

////////////////////////////////////////


124

bmp.LoadBitmap(IDB_MANAGEMENT);




if(dc->m_hDC!=NULL)


SRCCOPY);

active_button="Management";

}

}

if(active_frame=="Management derivate")

{

OpTabel op;

bool ok=false;

if(Get_Sel_Button(point)=="RolUsd")

{

if(op.Get_Exces_rand(pDoc->a_F_RolUsd,1)>op.Get_CI(pDoc-

>a_F_RolUsd,1))

{

if(portofoliu.GetAt(1)=='1')

Select_Box(1,0);

else

Select_Box(1,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="EuroUsd")

{

if(op.Get_Exces_rand(pDoc->a_F_EuroUsd,1)>op.Get_CI(pDoc-

>a_F_EuroUsd,1))

{


Select_Box(2,0);

else

Select_Box(2,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="UsdJpy")

{

if(op.Get_Exces_rand(pDoc->a_F_UsdJpy,1)>op.Get_CI(pDoc-

>a_F_UsdJpy,1))


Select_Box(3,0);

else

Select_Box(3,1);

}

124

bmp.LoadBitmap(IDB_MANAGEMENT);




if(dc->m_hDC!=NULL)


SRCCOPY);

active_button="Management";

}

}


{

OpTabel op;

bool ok=false;

if(Get_Sel_Button(point)=="RolUsd")

{

if(op.Get_Exces_rand(pDoc->a_F_RolUsd,1)>op.Get_CI(pDoc-

>a_F_RolUsd,1))

{


Select_Box(1,0);

else

Select_Box(1,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="EuroUsd")

{

if(op.Get_Exces_rand(pDoc->a_F_EuroUsd,1)>op.Get_CI(pDoc-

>a_F_EuroUsd,1))

{


Select_Box(2,0);

else

Select_Box(2,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="UsdJpy")

{

if(op.Get_Exces_rand(pDoc->a_F_UsdJpy,1)>op.Get_CI(pDoc-

>a_F_UsdJpy,1))


Select_Box(3,0);

else

Select_Box(3,1);

}


125

ok=true;

if(Get_Sel_Button(point)=="Desif1")

{

if(op.Get_Exces_rand(pDoc->a_F_Desif1,1)>op.Get_CI(pDoc-

>a_F_Desif1,1))

{


Select_Box(4,0);

else

Select_Box(4,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Desnp")

{

if(op.Get_Exces_rand(pDoc->a_F_Desnp,1)>op.Get_CI(pDoc-

>a_F_Desnp,1))

{


Select_Box(5,0);

else

Select_Box(5,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Opt EuroUsd")

{


Select_Box(6,0);

else

Select_Box(6,1);

ok=true;

}

if(ok)

{

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

}


{

if(Get_Sel_Button(point)=="Management active")

{

active_frame="Management active";

Draw_fundal();

Fill_Tabel();

125

ok=true;

if(Get_Sel_Button(point)=="Desif1")

{

if(op.Get_Exces_rand(pDoc->a_F_Desif1,1)>op.Get_CI(pDoc-

>a_F_Desif1,1))

{


Select_Box(4,0);

else

Select_Box(4,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Desnp")

{

if(op.Get_Exces_rand(pDoc->a_F_Desnp,1)>op.Get_CI(pDoc-

>a_F_Desnp,1))

{


Select_Box(5,0);

else

Select_Box(5,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Opt EuroUsd")

{


Select_Box(6,0);

else

Select_Box(6,1);

ok=true;

}

if(ok)

{

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

}


{

if(Get_Sel_Button(point)=="Management active")

{

active_frame="Management active";

Draw_fundal();

Fill_Tabel();


126

Re_Draw();

}

}

if(active_frame=="Management active")

{

OpTabel op;

bool ok=false;

if(Get_Sel_Button(point)=="Usd")

{

{


Select_Box(7,0);

else

Select_Box(7,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Euro")

{

if(op.Get_Exces_rand(pDoc->a_F_Euro,1)>op.Get_CI(pDoc-

>a_F_Euro,1))

{


Select_Box(8,0);

else

Select_Box(8,0);

}

ok=true;

}

if(Get_Sel_Button(point)=="Jpy")

{

{


Select_Box(9,0);

else

Select_Box(9,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Sif")

{

{


Select_Box(10,0);

else

Select_Box(10,1);

126

Re_Draw();

}

}

if(active_frame=="Management active")

{

OpTabel op;

bool ok=false;

if(Get_Sel_Button(point)=="Usd")

{

{


Select_Box(7,0);

else

Select_Box(7,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Euro")

{

if(op.Get_Exces_rand(pDoc->a_F_Euro,1)>op.Get_CI(pDoc-

>a_F_Euro,1))

{


Select_Box(8,0);

else

Select_Box(8,0);

}

ok=true;

}

if(Get_Sel_Button(point)=="Jpy")

{

{


Select_Box(9,0);

else

Select_Box(9,1);

}

ok=true;

}

if(Get_Sel_Button(point)=="Sif")

{

{


Select_Box(10,0);

else

Select_Box(10,1);


127

}

ok=true;

}

if(Get_Sel_Button(point)=="Snp")

{

{


Select_Box(11,0);

else

Select_Box(11,1);

}

ok=true;

}

if(ok)

Draw_fundal();

Fill_Tabel();

Re_Draw();

void CX_TRADEView::OnLButtonUp(UINT nFlags, CPoint point) {



{


{

active_button="";

active_frame="Portofoliu1";

}

else

active_button="";

Draw_fundal();

Re_Draw();

}


{


{

active_button="";


Draw_fundal();

Fill_Tabel();

//Invalidate();

Re_Draw();

}

else


{

127

}

ok=true;

}

if(Get_Sel_Button(point)=="Snp")

{

{


Select_Box(11,0);

else

Select_Box(11,1);

}

ok=true;

}

if(ok)

Draw_fundal();

Fill_Tabel();

Re_Draw();

void CX_TRADEView::OnLButtonUp(UINT nFlags, CPoint point) {



{


{

active_button="";


}

else

active_button="";

Draw_fundal();

Re_Draw();

}


{


{

active_button="";


Draw_fundal();

Fill_Tabel();

//Invalidate();

Re_Draw();

}

else


{


128

active_button="";


Draw_fundal();

Fill_Tabel();

Re_Draw();

}

else


{

active_button="";

active_frame="Management derivate";

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

else

if(active_button!="")

{

active_button="";

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

}

3.5. Managementul interfeţelor şi dialogurilor

Indiferent de forma de utilizare a SSD24 şi domeniile pentru care

acestea au fost concepute, componenta managementul interfeţelor şi

dialogurilor este cea care furnizează un suport efectiv pentru situaţii de

decizie insuficient structurate.

Managementul interfeţelor şi dialogurilor este considerat deci, unul

dintre cele mai importante componente ale unui sistem suport de asistare a

deciziei pe care îl dorim un sistem interactiv, flexibil, şi simplu în utilizare,

calităţi care se datorează în special interfeţelor grafice şi dialogului. Dincolo de

eforturile făcute pentru conceperea şi realizarea lui, viaţa acestuia depinde de

utilizatorii săi, ei fiind cei care decid dacă şi cât va fi folosit.

24 SSD – Sisteme suport de asistare a deciziilor

128

active_button="";


Draw_fundal();

Fill_Tabel();

Re_Draw();

}

else


{

active_button="";

active_frame="Management derivate";

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

else

if(active_button!="")

{

active_button="";

Draw_fundal();

Fill_Tabel();

Re_Draw();

}

}

3.5. Managementul interfeţelor şi dialogurilor

Indiferent de forma de utilizare a SSD24 şi domeniile pentru care

acestea au fost concepute, componenta managementul interfeţelor şi

dialogurilor este cea care furnizează un suport efectiv pentru situaţii de

decizie insuficient structurate.

Managementul interfeţelor şi dialogurilor este considerat deci, unul

dintre cele mai importante componente ale unui sistem suport de asistare a

deciziei pe care îl dorim un sistem interactiv, flexibil, şi simplu în utilizare,

calităţi care se datorează în special interfeţelor grafice şi dialogului. Dincolo de

eforturile făcute pentru conceperea şi realizarea lui, viaţa acestuia depinde de

utilizatorii săi, ei fiind cei care decid dacă şi cât va fi folosit.

24 SSD – Sisteme suport de asistare a deciziilor


129

3.5.1. Interfața și dialogul

Interfaţa reprezintă „punctul sau suprafaţa de contact a utilizatorului cu

sistemul informatic”25. Ea este considerată, încă de la începuturile utilizării

SSD, drept partea cea mai importantă a sistemului suport pentru decizii, cea

care poate determina succesul sau insuccesul aplicaţiei. De cele mai multe ori,

în ochii utilizatorului, interfaţa este sistemul însuşi. Principala cerinţă a

acestora este ca interfaţa să fie cât mai intuitivă şi uşor de utilizat. Această

latură este mult mai importantă decât aspectul grafic sau decât folosirea de

tehnologii de ultimă oră; eforturile, substanţiale uneori, depuse în acest sens

pot fi rapid şi iremediabil compromise de un mod de utilizare perceput drept

greoi, complicat sau ilogic de către utilizator. Afirmaţia noastră o putem justifica

prin faptul că, utilizatorul nu este interesat prea mult de echipamentele şi

programele informatice folosite, de modul în care sunt stocate datele în

memoria calculatorului, sau de algoritmii utilizaţi, toate acestea funcţionând

undeva în spatele sistemului, el neavând acces la toate acestea.

Ceea ce îl interesează pe utilizator, poate fi sintetizat în câteva direcţii

pe care noi ne-am propus să le urmărim de fiecare dată, atunci când vom

realiza interfaţa şi dialogul utilizatorului cu sistemul suport pentru

managementul de portofoliu. Distingem, aşadar următorul set de direcţii:

- accesul comod şi eficace la resursele interne ale SSD în timpul

desfăşurării activităţilor de elaborare a deciziilor;

- posibilitatea de a lucra în mod interactiv cu mediul de rezolvare al

problemei, putând furniza parametrii de control în timpul derulării

procesului;

- flexibilitate pentru a permite utilizatorilor să construiască o soluţie ca cel

mai bun răspuns la problema decizională.

În managementul interfeţelor şi dialogurilor dezvoltat pentru sistemul

suport s-a optat, în funcţie de resursele hard şi soft de care am dispus, pentru

folosirea combinată a metodelor de interacţiune recomandate de o serie de

specialişti din domeniu26. Astfel, am considerat că pentru a asigura

interactivitatea utilizatorului cu sistemul suport, dialogul prin meniuri, ferestre,

25 Power, D.J. – Decision Support Systems: Concepts and Resources for Managers,

Quorum Books, Westport, Connecticut, 2002. 26 Steven Alter, Robert Buzzell, Robert Man, John Rockart, De Long David, Ralph

Sprague, Eric Carlson, Edward Tufte, Efraim Turban, R.C. Summers, C. Wood, J.C May, K.L. Norman, A. Porter, B. Shneiderman, V. Zwass – fiecare dintre aceştia oferind pe Internet suficient material bibliografic pe tema interfeţei om-calculator

129

3.5.1. Interfața și dialogul

Interfaţa reprezintă „punctul sau suprafaţa de contact a utilizatorului cu

sistemul informatic”25. Ea este considerată, încă de la începuturile utilizării

SSD, drept partea cea mai importantă a sistemului suport pentru decizii, cea

care poate determina succesul sau insuccesul aplicaţiei. De cele mai multe ori,

în ochii utilizatorului, interfaţa este sistemul însuşi. Principala cerinţă a

acestora este ca interfaţa să fie cât mai intuitivă şi uşor de utilizat. Această

latură este mult mai importantă decât aspectul grafic sau decât folosirea de

tehnologii de ultimă oră; eforturile, substanţiale uneori, depuse în acest sens

pot fi rapid şi iremediabil compromise de un mod de utilizare perceput drept

greoi, complicat sau ilogic de către utilizator. Afirmaţia noastră o putem justifica

prin faptul că, utilizatorul nu este interesat prea mult de echipamentele şi

programele informatice folosite, de modul în care sunt stocate datele în

memoria calculatorului, sau de algoritmii utilizaţi, toate acestea funcţionând

undeva în spatele sistemului, el neavând acces la toate acestea.

Ceea ce îl interesează pe utilizator, poate fi sintetizat în câteva direcţii

pe care noi ne-am propus să le urmărim de fiecare dată, atunci când vom

realiza interfaţa şi dialogul utilizatorului cu sistemul suport pentru

managementul de portofoliu. Distingem, aşadar următorul set de direcţii:

- accesul comod şi eficace la resursele interne ale SSD în timpul

desfăşurării activităţilor de elaborare a deciziilor;

- posibilitatea de a lucra în mod interactiv cu mediul de rezolvare al

problemei, putând furniza parametrii de control în timpul derulării

procesului;

- flexibilitate pentru a permite utilizatorilor să construiască o soluţie ca cel

mai bun răspuns la problema decizională.

În managementul interfeţelor şi dialogurilor dezvoltat pentru sistemul

suport s-a optat, în funcţie de resursele hard şi soft de care am dispus, pentru

folosirea combinată a metodelor de interacţiune recomandate de o serie de

specialişti din domeniu26. Astfel, am considerat că pentru a asigura

interactivitatea utilizatorului cu sistemul suport, dialogul prin meniuri, ferestre,

25 Power, D.J. – Decision Support Systems: Concepts and Resources for Managers,

Quorum Books, Westport, Connecticut, 2002. 26 Steven Alter, Robert Buzzell, Robert Man, John Rockart, De Long David, Ralph

Sprague, Eric Carlson, Edward Tufte, Efraim Turban, R.C. Summers, C. Wood, J.C May, K.L. Norman, A. Porter, B. Shneiderman, V. Zwass – fiecare dintre aceştia oferind pe Internet suficient material bibliografic pe tema interfeţei om-calculator


130

butoane de comandă, butoane de opţiuni, casete de dialog, liste derulante,

imagini (icons) corespunde celor câteva cerinţe legate de realizarea

interfeţelor, cristalizate în timp sub numele de „Regulile de aur ale lui

Shneiderman”27:

- consistenţa: necesitatea execuţiei aceloraşi acţiuni în cazul unor

situaţii similare; se vor executa aceleaşi opţiuni regăsite în cadrul

meniului, vor fi generate aceleaşi mesaje de către sistem;

- existenţa facilităţilor de tip short-cut permiţând utilizatorilor

experimentaţi să aibă la dispoziţie comenzi rapide;

- existenţa unui feedback care să ofere utilizatorilor informaţii asupra

modului de realizare a operaţiei;

- soluţionarea simplă a erorilor: să ofere alternative pentru rezolvarea

erorilor datorate disfuncţionalităţilor hard/soft;

- anularea facilă a efectelor unei comenzi executate;

- asigurarea controlului operaţiilor.

3.5.2. Formate de ecran folosite ca interfață pentru sistemul suport

Proiectarea unei interfeţe este unul dintre domeniile în care

creativitatea şi imaginaţia au un teren extrem de favorabil de manifestare.

Aceasta poate constitui o oportunitate de creştere a valorii percepute de

utilizator prin construirea unei interfeţe originale şi atractive după cum poate

constitui, la fel de bine, o capcană în care, atras de facilităţile grafice din ce în

ce mai bogate, proiectantul să compromită un sistem cu bune funcţionalităţi

printr-o interfaţă excesiv de încărcată sau pretenţioasă.

De aceea am preferat ca interfaţa sistemului suport să aibă în

componenţa sa formate de ecran (forms) şi zone de control (controls). Fiecare

dintre acestea dispun de controale grafice cu un set propriu de proprietăţi,

metode şi evenimente, constituind totodată suportul acestora.

Sistemul suport pentru asistarea deciziei în managementul de

portofoliu, dispune de:

un format de ecran pentru prezentare, care este o instanţă a clasei

Form, se numeşte Startup şi este încărcat de programul principal la

activarea fişierului executabil. Rolul acestui format de ecran este acela

27 Shneiderman B., Designing User Interface for Software, in Proceedings of the

International Conference on System Sciences, Kona, Hawaii, January 1998, page 454

130

butoane de comandă, butoane de opţiuni, casete de dialog, liste derulante,

imagini (icons) corespunde celor câteva cerinţe legate de realizarea

interfeţelor, cristalizate în timp sub numele de „Regulile de aur ale lui

Shneiderman”27:

- consistenţa: necesitatea execuţiei aceloraşi acţiuni în cazul unor

situaţii similare; se vor executa aceleaşi opţiuni regăsite în cadrul

meniului, vor fi generate aceleaşi mesaje de către sistem;

- existenţa facilităţilor de tip short-cut permiţând utilizatorilor

experimentaţi să aibă la dispoziţie comenzi rapide;

- existenţa unui feedback care să ofere utilizatorilor informaţii asupra

modului de realizare a operaţiei;

- soluţionarea simplă a erorilor: să ofere alternative pentru rezolvarea

erorilor datorate disfuncţionalităţilor hard/soft;

- anularea facilă a efectelor unei comenzi executate;

- asigurarea controlului operaţiilor.

3.5.2. Formate de ecran folosite ca interfață pentru sistemul suport

Proiectarea unei interfeţe este unul dintre domeniile în care

creativitatea şi imaginaţia au un teren extrem de favorabil de manifestare.

Aceasta poate constitui o oportunitate de creştere a valorii percepute de

utilizator prin construirea unei interfeţe originale şi atractive după cum poate

constitui, la fel de bine, o capcană în care, atras de facilităţile grafice din ce în

ce mai bogate, proiectantul să compromită un sistem cu bune funcţionalităţi

printr-o interfaţă excesiv de încărcată sau pretenţioasă.

De aceea am preferat ca interfaţa sistemului suport să aibă în

componenţa sa formate de ecran (forms) şi zone de control (controls). Fiecare

dintre acestea dispun de controale grafice cu un set propriu de proprietăţi,

metode şi evenimente, constituind totodată suportul acestora.

Sistemul suport pentru asistarea deciziei în managementul de

portofoliu, dispune de:

un format de ecran pentru prezentare, care este o instanţă a clasei

Form, se numeşte Startup şi este încărcat de programul principal la

activarea fişierului executabil. Rolul acestui format de ecran este acela

27 Shneiderman B., Designing User Interface for Software, in Proceedings of the

International Conference on System Sciences, Kona, Hawaii, January 1998, page 454


131

de a face iniţializările variabilelor globale, de a afişa ecranul de

prezentare timp de 5 secunde, de a închide ecranul Startup şi de a

deschide fereastra de acces;

o forma principală care preia controlul programului din momentul în

care forma de prezentare Startup este descărcată din memorie. Acest

format de ecran este o interfaţă MDI (multipledocument interface -

multidocument) prin faptul că are capacitatea de a activa alte formate.

În fereastra MDI a sistemului sunt plasate mai multe controale grafice:

7 butoane şi 4 imagini corespunzătoare celor 4 subsisteme ale

aplicaţiei. Aceste obiecte de tip buton şi imagine sunt organizate într-o

structură Control Array, fiecare având câte un index, pentru a face o

prelucrare mult mai rapidă a evenimentelor asociate acestora.

format de ecran pentru actualizare, care are ca suport un şablon

comportamental28 al obiectelor şi claselor de obiecte analizate.

Definirea unui şablon facilitează realizarea rapidă a formatelor de ecran

pentru adăugare, modificare şi ştergere a datelor. Şablonul conţine 2

butoane necesare pentru confirmare (Salvare) şi pentru anulare a

acţiunilor (Renunţă). Pentru actualizarea înregistrărilor se adaugă 3

zone de control pentru editarea datelor.

Formate de ecran pentru actualizarea datelor au fost proiectate pentru

tabelele: cotaţii, clienţi, brokeri ale bazei de date.

3.5.3. Controale grafice Visual C++ folosite de sistem ca interfaţă şi pentru

dialogul cu utilizatorii

Controalele grafice specifice limbajului Visual C++, reprezintă arsenalul

de instrumente cu care susţinem o interfaţă robustă, atractivă şi uşor de folosit.

În funcţie de rolul pe care îl pot îndeplinii, controalele grafice permit:

- executarea acţiunilor (butonul de comandă, caseta imagine)

- introducerea şi afişarea informaţiei (eticheta, caseta-text, caseta-listă, caseta

combo)

- selectarea unei opţiuni (caseta şi butonul de opţiune)

- alte operaţii (cronometrul, bara de defilare), etc.

28 Zaharie D., Roşca I., - Proiectarea obiectuală a sistemelor informatice, Editura DualTech, Bucureşti, 2002, pag.211

131

de a face iniţializările variabilelor globale, de a afişa ecranul de

prezentare timp de 5 secunde, de a închide ecranul Startup şi de a

deschide fereastra de acces;

o forma principală care preia controlul programului din momentul în

care forma de prezentare Startup este descărcată din memorie. Acest

format de ecran este o interfaţă MDI (multipledocument interface -

multidocument) prin faptul că are capacitatea de a activa alte formate.

În fereastra MDI a sistemului sunt plasate mai multe controale grafice:

7 butoane şi 4 imagini corespunzătoare celor 4 subsisteme ale

aplicaţiei. Aceste obiecte de tip buton şi imagine sunt organizate într-o

structură Control Array, fiecare având câte un index, pentru a face o

prelucrare mult mai rapidă a evenimentelor asociate acestora.

format de ecran pentru actualizare, care are ca suport un şablon

comportamental28 al obiectelor şi claselor de obiecte analizate.

Definirea unui şablon facilitează realizarea rapidă a formatelor de ecran

pentru adăugare, modificare şi ştergere a datelor. Şablonul conţine 2

butoane necesare pentru confirmare (Salvare) şi pentru anulare a

acţiunilor (Renunţă). Pentru actualizarea înregistrărilor se adaugă 3

zone de control pentru editarea datelor.

Formate de ecran pentru actualizarea datelor au fost proiectate pentru

tabelele: cotaţii, clienţi, brokeri ale bazei de date.

3.5.3. Controale grafice Visual C++ folosite de sistem ca interfaţă şi pentru

dialogul cu utilizatorii

Controalele grafice specifice limbajului Visual C++, reprezintă arsenalul

de instrumente cu care susţinem o interfaţă robustă, atractivă şi uşor de folosit.

În funcţie de rolul pe care îl pot îndeplinii, controalele grafice permit:

- executarea acţiunilor (butonul de comandă, caseta imagine)

- introducerea şi afişarea informaţiei (eticheta, caseta-text, caseta-listă, caseta

combo)

- selectarea unei opţiuni (caseta şi butonul de opţiune)

- alte operaţii (cronometrul, bara de defilare), etc.

28 Zaharie D., Roşca I., - Proiectarea obiectuală a sistemelor informatice, Editura DualTech, Bucureşti, 2002, pag.211


132

Una din metodele prin care proiectanţii de interfeţe grafice, la care noi

am subscris, îşi asigură adeziunea utilizatorilor este folosirea unui design cât

mai apropiat de cel cu care utilizatorii sunt deja obişnuiţi (similar aplicaţiilor

Windows consacrate). De aceea, întocmim o listă (vezi Tabelul 3.12) cu cele

mai frecvent folosite controale grafice Windows şi ActiveX, specificând

funcţionalitatea lor şi câteva indicaţii de utilizare.

Tabelul 3.12 – Controale grafice și funcționalitățile lor

Control grafic Funcţie Observaţii

Buton de comandă Comunicare mesaj

către un control Cel mai simplu element de acţiune

Casetă - text Introducere date Introducere texte, numere, parole

Casetă – text cu

mască de intrare

Numai introducere

date

Introducere informaţie formatată

(valute, date calendaristice, etc)

Rich Text Box Introducere/afişare

date Introducere informaţie formatată

Buton rotativ (Spin

Button) Introducere date

Introducere numere întregi sau fracţii;

de combinat cu o casetă-text

Bara de defilare Introducere date

Setare numere întregi; se utilizează

când datele nu trebuie introduse

„imediat”

Casetă de opţiune Introducere/afişare

date

Alegeri neexclusive; se folosesc în

număr mic

Buton de opţiune Introducere/afişare

date

Alegeri mutual exclusive; un grup cu

mai mult de 5 butoane poate fi

înlocuit cu o casetă-listă cu

proprietatea MultiSelect setată pe

None sau cu o casetă combinată.

Casetă – listă Afişare date

Nu este editabilă direct; este indicat

să nu conţină mai mult de 30 de

elemente

Casetă combinată Introducere/afişare

date Versiune editabilă a unei casete-listă

Caroiaj Afişare date

Nu este editabil direct; se foloseşte

pentru afişarea datelor dispuse pe

linii şi coloane

Caseta dialog Afişare date

132

Una din metodele prin care proiectanţii de interfeţe grafice, la care noi

am subscris, îşi asigură adeziunea utilizatorilor este folosirea unui design cât

mai apropiat de cel cu care utilizatorii sunt deja obişnuiţi (similar aplicaţiilor

Windows consacrate). De aceea, întocmim o listă (vezi Tabelul 3.12) cu cele

mai frecvent folosite controale grafice Windows şi ActiveX, specificând

funcţionalitatea lor şi câteva indicaţii de utilizare.

Tabelul 3.12 – Controale grafice și funcționalitățile lor

Control grafic Funcţie Observaţii

Buton de comandă Comunicare mesaj

către un control Cel mai simplu element de acţiune

Casetă - text Introducere date Introducere texte, numere, parole

Casetă – text cu

mască de intrare

Numai introducere

date

Introducere informaţie formatată

(valute, date calendaristice, etc)

Rich Text Box Introducere/afişare

date Introducere informaţie formatată

Buton rotativ (Spin

Button) Introducere date

Introducere numere întregi sau fracţii;

de combinat cu o casetă-text

Bara de defilare Introducere date

Setare numere întregi; se utilizează

când datele nu trebuie introduse

„imediat”

Casetă de opţiune Introducere/afişare

date

Alegeri neexclusive; se folosesc în

număr mic

Buton de opţiune Introducere/afişare

date

Alegeri mutual exclusive; un grup cu

mai mult de 5 butoane poate fi

înlocuit cu o casetă-listă cu

proprietatea MultiSelect setată pe

None sau cu o casetă combinată.

Casetă – listă Afişare date

Nu este editabilă direct; este indicat

să nu conţină mai mult de 30 de

elemente

Casetă combinată Introducere/afişare

date Versiune editabilă a unei casete-listă

Caroiaj Afişare date

Nu este editabil direct; se foloseşte

pentru afişarea datelor dispuse pe

linii şi coloane

Caseta dialog Afişare date


133

Fiecare control grafic Visual C++ are un set de atribute, numite

proprietăţi; fiecare proprietate poate lua o valoare dintr-un set de valori

permise; valoarea implicită se poate modifica în funcţie de necesităţi, atribuind

o altă valoare din setul de valori permise. setarea iniţială a proprietăţii

controalelor se face cel mai comod în modul Design View.

Prin utilizarea meniurilor, a ferestrelor, butoanelor de comandă şi/sau

de opţiuni, a listelor derulante şi prin scrierea câtorva linii de cod, se oferă

utilizatorului o interfaţă atractivă, intuitivă, extensibilă, uşor de învăţat şi de

utilizat.

Abordarea orientată pe obiecte însușită la proiectarea structurii bazei

de date pentru a reflecta mai bine realitatea, şi-a pus amprenta şi asupra

procesului de realizare a unei interfeţe orientate obiect.

Subliniem că pentru sistemul suport am realizat o interfaţă orientată

obiect în adevăratul sens al cuvântului, fără a ne baza pe faptul că simpla

utilizare a unor controale grafice de genul celor prezentate în Tabelul 3.12.

conferă automat interfeţei caracterul de orientat obiect. Argumentul nostru este

că, în cazul în care utilizatorul trebuie să selecteze anumite informaţii din baza

de date, să le formateze şi apoi să listeze raportul astfel generat, va simţi

avantajele interfeţei orientate obiect în defavoarea unei interfeţe orientate spre

comenzi.

Într-o interfaţă grafică orientată spre comenzi (funcţii), utilizatorului i se

oferă o fereastră dialog (de exemplu o grilă QBE), în care i se cere să specifice

criteriul de selecţie; apoi, utilizatorul poate selecta opţiunile de formatare dintr-

un meniu derulant şi, în fine, poate da comanda de printare. Toate operaţiile se

execută grafic şi sunt puternic centrate pe acţiunile pe care trebuie să le

execute utilizatorul, adică pe comenzile pe care acestea i le transmite

calculatorul, şi nu pe datele efective pe care utilizatorul trebuie să le

manipuleze pentru a obţine raportul. De fapt utilizatorul vede datele pe care

trebuie să le prelucreze numai după executarea şi a ultimului pas din secvenţa

de prelucrări. Este necesar să îşi amintească numele tabelei, structura

câmpurilor, criteriul de selecţie, sintaxa acestuia, etc.

Într-o interfaţă orientată spre obiecte aşa cum este cea proiectată

pentru sistemul suport utilizatorul are la dispoziţie o fereastră-dialog ce conţine

înregistrările care populează baza de date, ceea ce facilitează în mod

semnificativ sarcina acestuia de a-şi aminti conţinutul bazei de date şi de a

compune un criteriu de selecţie corespunzător. Ca urmare, fereastra-dialog

133

Fiecare control grafic Visual C++ are un set de atribute, numite

proprietăţi; fiecare proprietate poate lua o valoare dintr-un set de valori

permise; valoarea implicită se poate modifica în funcţie de necesităţi, atribuind

o altă valoare din setul de valori permise. setarea iniţială a proprietăţii

controalelor se face cel mai comod în modul Design View.

Prin utilizarea meniurilor, a ferestrelor, butoanelor de comandă şi/sau

de opţiuni, a listelor derulante şi prin scrierea câtorva linii de cod, se oferă

utilizatorului o interfaţă atractivă, intuitivă, extensibilă, uşor de învăţat şi de

utilizat.

Abordarea orientată pe obiecte însușită la proiectarea structurii bazei

de date pentru a reflecta mai bine realitatea, şi-a pus amprenta şi asupra

procesului de realizare a unei interfeţe orientate obiect.

Subliniem că pentru sistemul suport am realizat o interfaţă orientată

obiect în adevăratul sens al cuvântului, fără a ne baza pe faptul că simpla

utilizare a unor controale grafice de genul celor prezentate în Tabelul 3.12.

conferă automat interfeţei caracterul de orientat obiect. Argumentul nostru este

că, în cazul în care utilizatorul trebuie să selecteze anumite informaţii din baza

de date, să le formateze şi apoi să listeze raportul astfel generat, va simţi

avantajele interfeţei orientate obiect în defavoarea unei interfeţe orientate spre

comenzi.

Într-o interfaţă grafică orientată spre comenzi (funcţii), utilizatorului i se

oferă o fereastră dialog (de exemplu o grilă QBE), în care i se cere să specifice

criteriul de selecţie; apoi, utilizatorul poate selecta opţiunile de formatare dintr-

un meniu derulant şi, în fine, poate da comanda de printare. Toate operaţiile se

execută grafic şi sunt puternic centrate pe acţiunile pe care trebuie să le

execute utilizatorul, adică pe comenzile pe care acestea i le transmite

calculatorul, şi nu pe datele efective pe care utilizatorul trebuie să le

manipuleze pentru a obţine raportul. De fapt utilizatorul vede datele pe care

trebuie să le prelucreze numai după executarea şi a ultimului pas din secvenţa

de prelucrări. Este necesar să îşi amintească numele tabelei, structura

câmpurilor, criteriul de selecţie, sintaxa acestuia, etc.

Într-o interfaţă orientată spre obiecte aşa cum este cea proiectată

pentru sistemul suport utilizatorul are la dispoziţie o fereastră-dialog ce conţine

înregistrările care populează baza de date, ceea ce facilitează în mod

semnificativ sarcina acestuia de a-şi aminti conţinutul bazei de date şi de a

compune un criteriu de selecţie corespunzător. Ca urmare, fereastra-dialog


134

afişează datele care verifică acel criteriu de selecţie, iar caracterul interactiv al

interfeţei va permite modificarea criteriului şi afişarea datelor care îl verifică în

mod repetat, până când utilizatorul este satisfăcut de rezultat. Analog,

formatarea se face prin modificarea aspectului ferestrei dialog până la

obţinerea formatului dorit. Ultimul pas va fi tot printarea. Rezultatul nu este însă

„la prima vedere”, ci va fi unul cu care utilizatorul este familiarizat graţie feed-

back-ului imediat primit pe parcursul tuturor acestor operaţii centrate, de

această dată, pe datele de prelucrat.

Accentul pus pe abordarea orientată obiect în tot ceea ce a contribuit la

definitivarea sistemului suport pentru asistarea deciziei în managementul de

portofoliu se înscrie în această nouă orientare, care a devenit trăsătura

comună a generaţie actuale de metode de proiectare a sistemelor şi aplicaţiilor

informatice de gestiune. Practica a dovedit ceea ce studiile şi cercetările

teoretice au anticipat, că aplicarea acestui demers conduce la soluţii

superioare calitativ, în special în cazul sistemelor de mari dimensiuni şi

complexitate, aşa cum este sistemul bursier analizat de noi.

3.6. Funcţionalităţile sistemului pentru managementul de

portofoliu. Prezentarea generală a sesiunii de lucru

Dinamica operaţiunilor cu produse financiare derivate şi explozia

informaţională din „ringul bursier”, fac din utilizarea XTrade ca sistem interactiv

de asistare a deciziilor, o necesitate. În ciuda limitărilor impuse de

imposibilitatea reproducerii perfecte de către calculator a raţionamentelor

umane, XTrade reprezintă instrumentul indispensabil managerului modern de

portofoliu, întrucât marea majoritate a activităţilor decizionale de rutină,

volumul total al informaţiilor necesare modelului decizional împreună cu

tehnicile de căutare şi regăsire a informaţiei sunt preluate complet de către

acesta.

Funcţionalităţile oferite de XTrade managementului de portofoliu, dar şi

managementului Bursei, ca urmare a posibilităţilor de integrare a sa în sistemul

informatic general, sunt desprinse din avantajele generale ce decurg din

introducerea sistemelor soft în asistarea deciziilor, cu referire la:

accesul al informaţii pertinente şi controlul accesului;

manipularea informaţiilor şi prezentarea rezultatelor;

134

afişează datele care verifică acel criteriu de selecţie, iar caracterul interactiv al

interfeţei va permite modificarea criteriului şi afişarea datelor care îl verifică în

mod repetat, până când utilizatorul este satisfăcut de rezultat. Analog,

formatarea se face prin modificarea aspectului ferestrei dialog până la

obţinerea formatului dorit. Ultimul pas va fi tot printarea. Rezultatul nu este însă

„la prima vedere”, ci va fi unul cu care utilizatorul este familiarizat graţie feed-

back-ului imediat primit pe parcursul tuturor acestor operaţii centrate, de

această dată, pe datele de prelucrat.

Accentul pus pe abordarea orientată obiect în tot ceea ce a contribuit la

definitivarea sistemului suport pentru asistarea deciziei în managementul de

portofoliu se înscrie în această nouă orientare, care a devenit trăsătura

comună a generaţie actuale de metode de proiectare a sistemelor şi aplicaţiilor

informatice de gestiune. Practica a dovedit ceea ce studiile şi cercetările

teoretice au anticipat, că aplicarea acestui demers conduce la soluţii

superioare calitativ, în special în cazul sistemelor de mari dimensiuni şi

complexitate, aşa cum este sistemul bursier analizat de noi.

3.6. Funcţionalităţile sistemului pentru managementul de

portofoliu. Prezentarea generală a sesiunii de lucru

Dinamica operaţiunilor cu produse financiare derivate şi explozia

informaţională din „ringul bursier”, fac din utilizarea XTrade ca sistem interactiv

de asistare a deciziilor, o necesitate. În ciuda limitărilor impuse de

imposibilitatea reproducerii perfecte de către calculator a raţionamentelor

umane, XTrade reprezintă instrumentul indispensabil managerului modern de

portofoliu, întrucât marea majoritate a activităţilor decizionale de rutină,

volumul total al informaţiilor necesare modelului decizional împreună cu

tehnicile de căutare şi regăsire a informaţiei sunt preluate complet de către

acesta.

Funcţionalităţile oferite de XTrade managementului de portofoliu, dar şi

managementului Bursei, ca urmare a posibilităţilor de integrare a sa în sistemul

informatic general, sunt desprinse din avantajele generale ce decurg din

introducerea sistemelor soft în asistarea deciziilor, cu referire la:

accesul al informaţii pertinente şi controlul accesului;

manipularea informaţiilor şi prezentarea rezultatelor;


135

structurarea informaţiilor sub formă de modele: relaţii între variabile,

sisteme de relaţii, arbori de decizie;

efectuarea de simulări, generarea de alternative (scenarii) şi

evaluarea acestora;

conservarea sub formă de bibliotecă a conceptelor şi informaţiilor

utile în interpretarea rezultatelor;

expertiză automată.

Referindu-ne la sistemul suport dezvoltat cu scopul de a asista

managementul de portofoliu, funcţionalităţile sale ca sistem interactiv de

asistare a deciziei constau în principal în:

culegerea şi prelucrarea rapidă a unui volum mare de date; pentru aceasta

utilizatorul foloseşte casetele de dialog Introducere date pentru…, care oferă

posibilităţi de vizualizarea a site-ului Burse în vederea preluării datelor

referitoare la cotaţiile produselor financiare derivate dar şi posibilitatea de

descărcare (Download) a datelor de pe serverele specializate în furnizarea

cotaţiilor bursiere;

utilizarea metodelor şi modelelor economico-matematice riguroase în analiza

şi interpretarea informaţiilor; în acest sens, nu este lipsit de interes să

precizăm faptul că am utilizat tehnici moderne de modelare a deciziei dar şi o

serie de modele matematice consacrate, astfel:

modelul de piaţă – a constituit punctul de plecare în fundamentarea

studiului privind modelarea situaţiei decizionale expuse;

algoritmul „exces de randament” – derivă din modelul de piaţă şi este

cel care răspunde cu rezultate foarte bune, necesităţii de selecţie dintr-

un lot de produse financiare derivate tranzacţionate, a acelora care

adunate într-un portofoliu strategic să aducă profit investitorului;

funcţiile de regresie – permit previzionarea evoluţiei cursului derivatelor,

indicând valori pe aceste le pot atinge într-o perioadă viitoare, în funcţie

de trendul specificat;

mediile mobile – ajustează seria cronologică în măsura în care setul de

date este suficient de mare; se practică cu succes, dacă intervalul ales

este de cel puţin 200 de zile;

oscilatorii bursieri – asistă cu succes utilizatorul în fundamentarea

deciziei de tranzacţionare, deoarece sunt capabili să sesizeze

intensitatea evoluţiilor de preţ, pe orice trend (fie acesta ascendent sau

descendent).

135

structurarea informaţiilor sub formă de modele: relaţii între variabile,

sisteme de relaţii, arbori de decizie;

efectuarea de simulări, generarea de alternative (scenarii) şi

evaluarea acestora;

conservarea sub formă de bibliotecă a conceptelor şi informaţiilor

utile în interpretarea rezultatelor;

expertiză automată.

Referindu-ne la sistemul suport dezvoltat cu scopul de a asista

managementul de portofoliu, funcţionalităţile sale ca sistem interactiv de

asistare a deciziei constau în principal în:

culegerea şi prelucrarea rapidă a unui volum mare de date; pentru aceasta

utilizatorul foloseşte casetele de dialog Introducere date pentru…, care oferă

posibilităţi de vizualizarea a site-ului Burse în vederea preluării datelor

referitoare la cotaţiile produselor financiare derivate dar şi posibilitatea de

descărcare (Download) a datelor de pe serverele specializate în furnizarea

cotaţiilor bursiere;

utilizarea metodelor şi modelelor economico-matematice riguroase în analiza

şi interpretarea informaţiilor; în acest sens, nu este lipsit de interes să

precizăm faptul că am utilizat tehnici moderne de modelare a deciziei dar şi o

serie de modele matematice consacrate, astfel:

modelul de piaţă – a constituit punctul de plecare în fundamentarea

studiului privind modelarea situaţiei decizionale expuse;

algoritmul „exces de randament” – derivă din modelul de piaţă şi este

cel care răspunde cu rezultate foarte bune, necesităţii de selecţie dintr-

un lot de produse financiare derivate tranzacţionate, a acelora care

adunate într-un portofoliu strategic să aducă profit investitorului;

funcţiile de regresie – permit previzionarea evoluţiei cursului derivatelor,

indicând valori pe aceste le pot atinge într-o perioadă viitoare, în funcţie

de trendul specificat;

mediile mobile – ajustează seria cronologică în măsura în care setul de

date este suficient de mare; se practică cu succes, dacă intervalul ales

este de cel puţin 200 de zile;

oscilatorii bursieri – asistă cu succes utilizatorul în fundamentarea

deciziei de tranzacţionare, deoarece sunt capabili să sesizeze

intensitatea evoluţiilor de preţ, pe orice trend (fie acesta ascendent sau

descendent).


136

realizarea unor corelaţii multiple între elementele şi fenomenele

caracteristice situaţiilor decizionale analizate, corelaţii care oferă

posibilitatea unor analize şi interpretări complex fundamentate,

prezentate într-o manieră deosebit de sugestivă pentru decident;

descrierea şi analiza informaţiilor de bază cu instrumente statistice

(analize de date, previziuni);

obţinerea de rapoarte şi situaţii centralizatoare, pentru analiza şi

interpretarea cărora se foloseşte sintetizarea informaţiilor sub formă

grafică şi tabelară;

Pentru implementarea acestor funcţionalităţi, prima versiune a

sistemului suport oferă utilizatorilor săi, un veritabil instrument pentru asistarea

deciziilor, prezentând numeroase opţiuni de prelucrare a datelor, de analiză a

informaţiilor, având capacitatea de adaptare la nivel individual sau

organizaţional.

În plus, sistemul suport rulează pe o gamă largă de echipamente, nu

neapărat foarte sofisticate sau pretenţioase, fiind capabil să gestioneze volume

mari de date singur şi economic, într-o reţea de calculatoare sau monopost.

Construit pe o tehnologie cu performanţe verificate, baza de date a sistemului

este orientată obiect şi concepută astfel încât să micşoreze costurile de

întreţinere şi exploatare a sistemului de calcul, să gestioneze toate tipurile de

date, să ofere acces rapid la informaţie tuturor tipurilor de utilizatori.

Cu multă convingere, credem că XTrade este de mare ajutor pentru

identificarea şi măsurarea relaţiilor între diferite dimensiuni ale datelor şi în

special ale acelora care au în comun anumite seturi de valori ce pot previziona

la rândul lor, alte seturi de valori. Astfel, cu XTrade se pot obţine relaţii

complexe între date permiţând o analiză calitativă şi cantitativă a datelor

necesare derulării unui management eficient al operaţiunilor cu produse

financiare derivate.

Pentru XTrade am adoptat în realizarea sa, o abordare modulară,

astfel că pentru a rula programul este nevoie de modulele de bază. La acestea

se adaugă programele care definesc structurile de date, încărcarea şi salvarea

acestora pe suportul magnetic.

În ansamblu, la rularea fişierului executabil xtrade.exe se lansează în

execuţie sistemul interactiv de asistare a deciziei denumit XTrade şi proiectat

pentru a susţine utilizatorul – broker, trader, analist, în activitatea sa

decizională.

136

realizarea unor corelaţii multiple între elementele şi fenomenele

caracteristice situaţiilor decizionale analizate, corelaţii care oferă

posibilitatea unor analize şi interpretări complex fundamentate,

prezentate într-o manieră deosebit de sugestivă pentru decident;

descrierea şi analiza informaţiilor de bază cu instrumente statistice

(analize de date, previziuni);

obţinerea de rapoarte şi situaţii centralizatoare, pentru analiza şi

interpretarea cărora se foloseşte sintetizarea informaţiilor sub formă

grafică şi tabelară;

Pentru implementarea acestor funcţionalităţi, prima versiune a

sistemului suport oferă utilizatorilor săi, un veritabil instrument pentru asistarea

deciziilor, prezentând numeroase opţiuni de prelucrare a datelor, de analiză a

informaţiilor, având capacitatea de adaptare la nivel individual sau

organizaţional.

În plus, sistemul suport rulează pe o gamă largă de echipamente, nu

neapărat foarte sofisticate sau pretenţioase, fiind capabil să gestioneze volume

mari de date singur şi economic, într-o reţea de calculatoare sau monopost.

Construit pe o tehnologie cu performanţe verificate, baza de date a sistemului

este orientată obiect şi concepută astfel încât să micşoreze costurile de

întreţinere şi exploatare a sistemului de calcul, să gestioneze toate tipurile de

date, să ofere acces rapid la informaţie tuturor tipurilor de utilizatori.

Cu multă convingere, credem că XTrade este de mare ajutor pentru

identificarea şi măsurarea relaţiilor între diferite dimensiuni ale datelor şi în

special ale acelora care au în comun anumite seturi de valori ce pot previziona

la rândul lor, alte seturi de valori. Astfel, cu XTrade se pot obţine relaţii

complexe între date permiţând o analiză calitativă şi cantitativă a datelor

necesare derulării unui management eficient al operaţiunilor cu produse

financiare derivate.

Pentru XTrade am adoptat în realizarea sa, o abordare modulară,

astfel că pentru a rula programul este nevoie de modulele de bază. La acestea

se adaugă programele care definesc structurile de date, încărcarea şi salvarea

acestora pe suportul magnetic.

În ansamblu, la rularea fişierului executabil xtrade.exe se lansează în

execuţie sistemul interactiv de asistare a deciziei denumit XTrade şi proiectat

pentru a susţine utilizatorul – broker, trader, analist, în activitatea sa

decizională.


137

Sesiunea de lucru XTrade debutează cu fereastra principală, din

Figura 3.17.

Figura 3.17. – Fereastra principală

Fereastra principală a sistemului suport grupează în 3 zone distincte,

grupuri de butoane ce au ataşate imagini de tip .bmp, cu funcţionalitatea

caracteristică butoanelor de comandă. Astfel, la activare generează, conform

codului Visual C++ asociat, proceduri specifice în conformitate cu proprietatea

name atribuită şi declanşează casete de dialog pentru ca utilizatorul să

precizeze datele necesare prelucrărilor.

În continuare, delimităm cele 3 zone ale ferestrei principale şi

prezentăm sintetic funcţionalitatea fiecăreia, pentru familiarizarea viitorilor

utilizatori, cu acest sistem interactiv de asistare a deciziei, proiectat de noi

pentru a susţine managementul operaţiunilor cu produse financiare derivate.

Astfel:

Zona I este reprezentată prin Figura 3.18. şi permite conectarea rapidă

cu ajutorul butoanelor de comandă poziţionate în frame-ul

CONECTEAZĂ, la site-ul BMFMS şi la site-ul Bursei de Valori pentru a

vizualiza cotaţiile aferente derivatelor financiare şi activelor lor suport.

137

Sesiunea de lucru XTrade debutează cu fereastra principală, din

Figura 3.17.

Figura 3.17. – Fereastra principală

Fereastra principală a sistemului suport grupează în 3 zone distincte,

grupuri de butoane ce au ataşate imagini de tip .bmp, cu funcţionalitatea

caracteristică butoanelor de comandă. Astfel, la activare generează, conform

codului Visual C++ asociat, proceduri specifice în conformitate cu proprietatea

name atribuită şi declanşează casete de dialog pentru ca utilizatorul să

precizeze datele necesare prelucrărilor.

În continuare, delimităm cele 3 zone ale ferestrei principale şi

prezentăm sintetic funcţionalitatea fiecăreia, pentru familiarizarea viitorilor

utilizatori, cu acest sistem interactiv de asistare a deciziei, proiectat de noi

pentru a susţine managementul operaţiunilor cu produse financiare derivate.

Astfel:

Zona I este reprezentată prin Figura 3.18. şi permite conectarea rapidă

cu ajutorul butoanelor de comandă poziţionate în frame-ul

CONECTEAZĂ, la site-ul BMFMS şi la site-ul Bursei de Valori pentru a

vizualiza cotaţiile aferente derivatelor financiare şi activelor lor suport.


138

Figura 3.18. – Zona I: Conectare la site-ul Bursei

Zona II este reprezentată prin Figura 3.19. şi cuprinde un grup de

butoane de comandă utilizate pentru introducere de date şi actualizare

bază de date, realizare grafice, generare rapoarte, utilizare diverse

instrumente, furnizare asistenţă soft.

Figura 3.19. – Zona II: Butoane de comandă

La activare, butonul INTRODUCERE DATE, generează caseta de

dialog din Figura 3.20 în care utilizatorul are posibilitatea să vizualizeze

cotaţiile deja introduse în baza de date dar şi să actualizeze înregistrările

acesteia, prin folosirea butoanelor: ADAUGĂ, MODIFICĂ, ŞTERGE. Caseta de

dialog dispune de 5 frame-uri, care grupează operaţiuni de:

- alegere dintr-o listă derulantă a titlului derivat;

- actualizare a bazei de date. Atunci când se doreşte adăugarea de noi

cotaţii în baza de date, frame-ul DATE devine activ şi permite

introducerea de noi informaţii cu privire la cotaţia înregistrată, valoarea

indicelui BET şi a activului fără risc (AF), având posibilitatea de a selecta

data calendaristică dintr-un control de tip Data. Dacă se doreşte

actualizarea prin modificare sau ştergere, se alege înregistrarea în cauză

şi se activează butonul MODIFICĂ sau ŞTERGE.

138

Figura 3.18. – Zona I: Conectare la site-ul Bursei

Zona II este reprezentată prin Figura 3.19. şi cuprinde un grup de

butoane de comandă utilizate pentru introducere de date şi actualizare

bază de date, realizare grafice, generare rapoarte, utilizare diverse

instrumente, furnizare asistenţă soft.

Figura 3.19. – Zona II: Butoane de comandă

La activare, butonul INTRODUCERE DATE, generează caseta de

dialog din Figura 3.20 în care utilizatorul are posibilitatea să vizualizeze

cotaţiile deja introduse în baza de date dar şi să actualizeze înregistrările

acesteia, prin folosirea butoanelor: ADAUGĂ, MODIFICĂ, ŞTERGE. Caseta de

dialog dispune de 5 frame-uri, care grupează operaţiuni de:

- alegere dintr-o listă derulantă a titlului derivat;

- actualizare a bazei de date. Atunci când se doreşte adăugarea de noi

cotaţii în baza de date, frame-ul DATE devine activ şi permite

introducerea de noi informaţii cu privire la cotaţia înregistrată, valoarea

indicelui BET şi a activului fără risc (AF), având posibilitatea de a selecta

data calendaristică dintr-un control de tip Data. Dacă se doreşte

actualizarea prin modificare sau ştergere, se alege înregistrarea în cauză

şi se activează butonul MODIFICĂ sau ŞTERGE.


139

Figura 3.20 Caseta de dialog Actualizare bază de date

- vizualizare a intervalului de analiză, indicându-se prima şi ultima cotaţie

înregistrată în baza de date;

- descărcare a datelor de pe serverul specializat în furnizarea de cotaţii

bursiere; specificăm că această operaţiune este posibilă numai pentru

contractele futures EuroUsd şi UsdJpy oferind informaţii cu privire la

dată, preţ de deschidere, preţ maxim, minim şi de închidere; la activarea

butonului OK datele preluate pot fi adăugate în fişierul bazei de date (vezi

Figura 3.21.)

139

Figura 3.20 Caseta de dialog Actualizare bază de date

- vizualizare a intervalului de analiză, indicându-se prima şi ultima cotaţie

înregistrată în baza de date;

- descărcare a datelor de pe serverul specializat în furnizarea de cotaţii

bursiere; specificăm că această operaţiune este posibilă numai pentru

contractele futures EuroUsd şi UsdJpy oferind informaţii cu privire la

dată, preţ de deschidere, preţ maxim, minim şi de închidere; la activarea

butonului OK datele preluate pot fi adăugate în fişierul bazei de date (vezi

Figura 3.21.)


140

Figura 3.21. – Caseta de dialog Download cotaţii

La activare, butonul GRAFICE realizează analiza grafică a evoluţiei

cotaţiilor futures, prin utilizarea unor tipuri de grafice specifice activităţii de

management al operaţiunilor, precum şi a unor grafice generale, utilizate în

analiza statistică a seriilor cronologice de date. Caseta de dialog Graficele

cotaţiilor futures (vezi Figura 3.22) prezintă graficele aferente cotaţiilor bursiere

înregistrate într-un anumit interval de timp, ale cărui limite sunt precizate în

frame-ul Interval de analiză. La baza zonei de afişare a graficului se află bara

de derulare, ce permite vizualizarea trendului cotaţiilor pentru derivatul

selectat, deplasându-ne de la un capăt la altul al intervalului de analiză.

Frame-ul Setări grafic oferă posibilitatea de a stabili numărul de paşilor de

afişare dar şi de a stabili sau nu un caroiaj pentru zona de vizualizare a

graficelor, cu scopul unei mai bune aprecierii a trendului.

140

Figura 3.21. – Caseta de dialog Download cotaţii

La activare, butonul GRAFICE realizează analiza grafică a evoluţiei

cotaţiilor futures, prin utilizarea unor tipuri de grafice specifice activităţii de

management al operaţiunilor, precum şi a unor grafice generale, utilizate în

analiza statistică a seriilor cronologice de date. Caseta de dialog Graficele

cotaţiilor futures (vezi Figura 3.22) prezintă graficele aferente cotaţiilor bursiere

înregistrate într-un anumit interval de timp, ale cărui limite sunt precizate în

frame-ul Interval de analiză. La baza zonei de afişare a graficului se află bara

de derulare, ce permite vizualizarea trendului cotaţiilor pentru derivatul

selectat, deplasându-ne de la un capăt la altul al intervalului de analiză.

Frame-ul Setări grafic oferă posibilitatea de a stabili numărul de paşilor de

afişare dar şi de a stabili sau nu un caroiaj pentru zona de vizualizare a

graficelor, cu scopul unei mai bune aprecierii a trendului.


141

Figura 3.22. – Caseta de dialog Graficele cotaţiilor futures

Butonul RAPOARTE oferă posibilitatea de a prelua datele din baza de

date, de a le sorta, grupa, rezuma şi analiza pentru a fundamenta decizii

corecte în funcţie de acestea.

Acest buton generează la activare un formular (vezi Figura 3.23) în

care sunt prezente o serie de situaţii centralizatoare şi rapoarte utile

managementului operaţiunilor, scopul principal al acestora fiind acela de a

reuni elementele individuale din baza de date şi de a le prelucra pentru ca

acestea să devină informaţie. Informaţia astfel obţinută va reprezenta date

compilate, pe care managerul de portofoliu le poate folosi pentru a lua decizii,

pentru a lansa studii şi pentru a înţelege mai bine fenomenele şi procesele

care se derulează în ringul bursei. De asemenea, informaţiile obţinute răspund

clar, coincis la întrebările de genul: Câte/Câţi? Cine? Ce se întâmplă? Unde?

Cât timp? Când? De ce?

141

Figura 3.22. – Caseta de dialog Graficele cotaţiilor futures

Butonul RAPOARTE oferă posibilitatea de a prelua datele din baza de

date, de a le sorta, grupa, rezuma şi analiza pentru a fundamenta decizii

corecte în funcţie de acestea.

Acest buton generează la activare un formular (vezi Figura 3.23) în

care sunt prezente o serie de situaţii centralizatoare şi rapoarte utile

managementului operaţiunilor, scopul principal al acestora fiind acela de a

reuni elementele individuale din baza de date şi de a le prelucra pentru ca

acestea să devină informaţie. Informaţia astfel obţinută va reprezenta date

compilate, pe care managerul de portofoliu le poate folosi pentru a lua decizii,

pentru a lansa studii şi pentru a înţelege mai bine fenomenele şi procesele

care se derulează în ringul bursei. De asemenea, informaţiile obţinute răspund

clar, coincis la întrebările de genul: Câte/Câţi? Cine? Ce se întâmplă? Unde?

Cât timp? Când? De ce?


142

Figura 3.23. – Formularul cu rapoarte şi situaţii centralizatoare

La activare, butonul TOOLS lansează în execuţie aplicaţia WinPP, care

permite verificarea stabilităţii şi echilibrului sistemului bursier analizat. Aplicaţia

este ataşată sistemului suport şi constituie un veritabil instrument de analiză

care poate furniza informaţii în orice moment cu privire la «cât de stabilă este

piaţa?» şi «la ce este de făcut având în vedere semnalele arătate?»

Pentru a utiliza cu succes aplicaţia, din fereastra Open care apare

odată cu activarea executabilului, se alege fişierul phase.ode. Se introduc

parametrii, variabilele şi se observă dacă valorile obţinute se înscriu în zona de

stabilitate sau de instabilitate.

În Figura 3.24 se prezintă printr-o captură de ecran aplicaţia WinPP în

execuţie şi rezultatul care se obţine în urma trasării traiectoriilor de fază de

către acesta. Caseta de dialog Fixed Points (Punct de echilibru) indică

STABLE, adică stabilitatea echilibrului în funcţie de datele introduse. În acelaşi

timp, sunt oferite utilizatorului coordonatele punctului de echilibru precum şi

valorile proprii corespunzătoare.

142

Figura 3.23. – Formularul cu rapoarte şi situaţii centralizatoare

La activare, butonul TOOLS lansează în execuţie aplicaţia WinPP, care

permite verificarea stabilităţii şi echilibrului sistemului bursier analizat. Aplicaţia

este ataşată sistemului suport şi constituie un veritabil instrument de analiză

care poate furniza informaţii în orice moment cu privire la «cât de stabilă este

piaţa?» şi «la ce este de făcut având în vedere semnalele arătate?»

Pentru a utiliza cu succes aplicaţia, din fereastra Open care apare

odată cu activarea executabilului, se alege fişierul phase.ode. Se introduc

parametrii, variabilele şi se observă dacă valorile obţinute se înscriu în zona de

stabilitate sau de instabilitate.

În Figura 3.24 se prezintă printr-o captură de ecran aplicaţia WinPP în

execuţie şi rezultatul care se obţine în urma trasării traiectoriilor de fază de

către acesta. Caseta de dialog Fixed Points (Punct de echilibru) indică

STABLE, adică stabilitatea echilibrului în funcţie de datele introduse. În acelaşi

timp, sunt oferite utilizatorului coordonatele punctului de echilibru precum şi

valorile proprii corespunzătoare.


143

Figura 3.24 – Aplicaţia WinPP în execuţie

De asemenea, WinPP facilitează vizualizarea evoluţiei variabilelor în

timp dar şi evoluţia unei variabile în raport de cealaltă. Pentru aceasta, se

apelează meniul Graphics şi comanda View pentru ca, să se precizeze axele

de coordonate (x1, x2 sau t) şi să se obţină un grafic tridimensional în funcţie de

aceste variabile (caseta de dialog din Figura 3.25).

Figura 3.25 – Caseta de dialog View Parametrs

143

Figura 3.24 – Aplicaţia WinPP în execuţie

De asemenea, WinPP facilitează vizualizarea evoluţiei variabilelor în

timp dar şi evoluţia unei variabile în raport de cealaltă. Pentru aceasta, se

apelează meniul Graphics şi comanda View pentru ca, să se precizeze axele

de coordonate (x1, x2 sau t) şi să se obţină un grafic tridimensional în funcţie de

aceste variabile (caseta de dialog din Figura 3.25).

Figura 3.25 – Caseta de dialog View Parametrs


144

La activare, butonul HELP pune la dispoziţia utilizatorului un sistem de

asistenţă soft. Acest sistem oferă informaţii Despre XTrade … şi Cum să …

folosească acest pachet software pentru asistarea deciziei în managementul

operaţiunilor cu produse financiare derivate (Figura 3.26.)

Figura 3.26. – Asistenţa soft realizată de sistemul suport

Se observă că sistemul de asistenţă este realizat în format HTML şi

se prezintă sub forma unui site web. Pentru realizarea acestuia au fost

create fişiere text, de tip .doc care au fost salvate în format .html. Fişierele

de help conţin salturi de la o pagină la alta, explicaţii în cadrul aceleiaşi

pagini asupra unor subiecte, cuvinte cheie cu ajutorul cărora utilizatorul

poate căuta un subiect, referinţe de context

Zona III este redată prin Figura 3.27. şi cuprinde alte 4 butoane de

comandă care segmentează aplicaţia în tot atâtea subsisteme, fiind

vorba despre: PORTOFOLIUL STRATEGIC, PROGNOZE PENTRU

COTAŢIILE FUTURES ŞI OPTIONS, INSTRUMENTE BURSIERE DE

ASISTARE A DECIZIEI şi TRANZACŢII.

144

La activare, butonul HELP pune la dispoziţia utilizatorului un sistem de

asistenţă soft. Acest sistem oferă informaţii Despre XTrade … şi Cum să …

folosească acest pachet software pentru asistarea deciziei în managementul

operaţiunilor cu produse financiare derivate (Figura 3.26.)

Figura 3.26. – Asistenţa soft realizată de sistemul suport

Se observă că sistemul de asistenţă este realizat în format HTML şi

se prezintă sub forma unui site web. Pentru realizarea acestuia au fost

create fişiere text, de tip .doc care au fost salvate în format .html. Fişierele

de help conţin salturi de la o pagină la alta, explicaţii în cadrul aceleiaşi

pagini asupra unor subiecte, cuvinte cheie cu ajutorul cărora utilizatorul

poate căuta un subiect, referinţe de context

Zona III este redată prin Figura 3.27. şi cuprinde alte 4 butoane de

comandă care segmentează aplicaţia în tot atâtea subsisteme, fiind

vorba despre: PORTOFOLIUL STRATEGIC, PROGNOZE PENTRU

COTAŢIILE FUTURES ŞI OPTIONS, INSTRUMENTE BURSIERE DE

ASISTARE A DECIZIEI şi TRANZACŢII.


145

Figura 3.27. – Zona III: Subsistemele sistemului suport în asistarea deciziei de

management portofoliu

Se observă că acestea, de fapt sunt activităţi care considerate în

ansamblul lor, constituie substanţa procesului de management al portofoliului.

3.7. Studiu de caz – prelucrarea şi analiza datelor pentru


Studiul de caz propus, cu scopul de a demonstra aplicabilitatea şi

funcţionalitatea sistemului suport în prelucrarea şi analiza datelor pentru

managementul portofoliului de produse financiare derivate, are ca punct de

plecare următoarele considerente:

PORTOFOLIUL STRATEGIC DE PRODUSE FINANCIARE

DERIVATE constă în primul rând, în construirea prin selecţie, a eşantionului de

produse financiare derivate care vor forma portofoliul strategic. Activând

butonul Parametrii active se determină (în procente) pentru fiecare titlu

tranzacţionat, un set de parametrii (rentabilitate, volatilitate, risc) care vor

indica utilizatorului performanţele individuale ale fiecărui derivat (vezi Figura

3.28.). În funcţie de parametrii determinaţi şi mai ales în funcţie de indicatorul

„exces de randament” care trebuie să fie superior indicatorului „C*, prin

activarea butonului Generare portofoliu strategic în conformitate cu algoritmului

stabilit se construieşte portofoliul strategic de produse financiare derivate.

În Figura 3.28. sunt prezentate rezultatele selecţiei efectuate de

algoritmul implementat, indicându-se acele derivate financiare care pot susţine

145

Figura 3.27. – Zona III: Subsistemele sistemului suport în asistarea deciziei de

management portofoliu

Se observă că acestea, de fapt sunt activităţi care considerate în

ansamblul lor, constituie substanţa procesului de management al portofoliului.

3.7. Studiu de caz – prelucrarea şi analiza datelor pentru


Studiul de caz propus, cu scopul de a demonstra aplicabilitatea şi

funcţionalitatea sistemului suport în prelucrarea şi analiza datelor pentru

managementul portofoliului de produse financiare derivate, are ca punct de

plecare următoarele considerente:

PORTOFOLIUL STRATEGIC DE PRODUSE FINANCIARE

DERIVATE constă în primul rând, în construirea prin selecţie, a eşantionului de

produse financiare derivate care vor forma portofoliul strategic. Activând

butonul Parametrii active se determină (în procente) pentru fiecare titlu

tranzacţionat, un set de parametrii (rentabilitate, volatilitate, risc) care vor

indica utilizatorului performanţele individuale ale fiecărui derivat (vezi Figura

3.28.). În funcţie de parametrii determinaţi şi mai ales în funcţie de indicatorul

„exces de randament” care trebuie să fie superior indicatorului „C*, prin

activarea butonului Generare portofoliu strategic în conformitate cu algoritmului

stabilit se construieşte portofoliul strategic de produse financiare derivate.

În Figura 3.28. sunt prezentate rezultatele selecţiei efectuate de

algoritmul implementat, indicându-se acele derivate financiare care pot susţine


146

un portofoliu strategic. Sursa prelucrărilor efectuate de algoritm o constituie

structura bazei de date xtrade.mdb, ale cărei tupluri sunt reprezentate de

cotaţiile înregistrate de produsele financiare derivate (RolEuro, RolUsd,

Eurousd, UsdJpy, DeSIF1, DeSIF3, DeSNP, Bubor) în „ringul bursei”.

Totodată, se observă cum, în urma prelucrărilor sunt eliminate acele

derivate care nu îndeplinesc condiţiile specifice algoritmului şi sunt păstrate

acelea care prezintă valori favorabile, indicând structura portofoliului. Prin

reiterarea procesului de determinare a parametrilor se poate construi un nou

portofoliu strategic pe baza celor mai recente cotaţii înregistrate în baza de

date a sistemului.

Figura 3.28. – Definirea structurii portofoliului strategic de derivate financiare

O dată determinată componenţa portofoliului strategic, se calculează şi

„% de investire” aferent fiecărui derivat, iar utilizatorul poate realiza asistat de

sistem, un management de portofoliu. În acest sens, are la dispoziţie butonul

Managementul portofoliui care prin activare determină rentabilitatea, riscul şi

volatilitatea portofoliului strategic construit. Interesant este faptul că activând

rând pe rând butoanele de selecţie de acest tip, se determină contribuţia

individuală la managementul de portofoliu dar şi în tandem cu oricare titlu

selectat din eşantion. Astfel, utilizatorul realizează diverse combinaţii şi poate

determina pentru fiecare alegere a sa, indicatorii ce caracterizează situaţia

dată. Caseta galbenă de la baza ferestrei, cu eticheta EXPLICAŢII oferă detalii

în funcţie de simularea efectuată de utilizator.

146

un portofoliu strategic. Sursa prelucrărilor efectuate de algoritm o constituie

structura bazei de date xtrade.mdb, ale cărei tupluri sunt reprezentate de

cotaţiile înregistrate de produsele financiare derivate (RolEuro, RolUsd,

Eurousd, UsdJpy, DeSIF1, DeSIF3, DeSNP, Bubor) în „ringul bursei”.

Totodată, se observă cum, în urma prelucrărilor sunt eliminate acele

derivate care nu îndeplinesc condiţiile specifice algoritmului şi sunt păstrate

acelea care prezintă valori favorabile, indicând structura portofoliului. Prin

reiterarea procesului de determinare a parametrilor se poate construi un nou

portofoliu strategic pe baza celor mai recente cotaţii înregistrate în baza de

date a sistemului.

Figura 3.28. – Definirea structurii portofoliului strategic de derivate financiare

O dată determinată componenţa portofoliului strategic, se calculează şi

„% de investire” aferent fiecărui derivat, iar utilizatorul poate realiza asistat de

sistem, un management de portofoliu. În acest sens, are la dispoziţie butonul

Managementul portofoliui care prin activare determină rentabilitatea, riscul şi

volatilitatea portofoliului strategic construit. Interesant este faptul că activând

rând pe rând butoanele de selecţie de acest tip, se determină contribuţia

individuală la managementul de portofoliu dar şi în tandem cu oricare titlu

selectat din eşantion. Astfel, utilizatorul realizează diverse combinaţii şi poate

determina pentru fiecare alegere a sa, indicatorii ce caracterizează situaţia

dată. Caseta galbenă de la baza ferestrei, cu eticheta EXPLICAŢII oferă detalii

în funcţie de simularea efectuată de utilizator.


147

În Figura 3.29 este prezentată cea mai avantajoasă situaţie, aceea în

care se preferă ca toate derivatele financiare alese în urma algoritmului, să

participe în anumite proporţii (xi) la rentabilitatea (Rp), volatilitatea (p) şi riscul

(σp) portofoliului. Valorile acestor 3 parametrii importanţi se înscriu în limitele

recomandate de literatura de specialitate şi în cele urmărite de practicieni

atunci când tranzacţionează efectiv.

Figura 3.29. – Managementul portofoliului de produse financiare derivate

În acelaşi timp, utilizatorul poate realiza şi un studiu comparativ prin

care decizia sa, poate fi confirmată sau nu. Această posibilitate este oferită de

butonul Comparație active suport care la activare construieşte un portofoliu din

activele suport ale derivatelor aflate în componenţa portofoliului strategic,

respectiv valutele Euro, Usd, Jpy şi acţiunile SIF1 şi SNP. Rezultatele obţinute

sunt comparate şi susţin o decizie corectă de management al portofoliului

strategic de produse financiare derivate.

PROGNOZE PENTRU COTAŢIILE FUTURES ŞI OPTIONS, al-II-lea

subsistem al aplicaţiei, este deosebit de important deoarece, folosind tehnica

regresiilor pot fi previzionate cursurile derivatelor financiare incluse în

portofoliul strategic. În fereastra de lucru a acestui subsistem, utilizatorul

selectează un derivat financiar; automat este afişat intervalul de analiză şi sunt

preluate din baza de date înregistrările aferente; totodată se declanşează o

147

În Figura 3.29 este prezentată cea mai avantajoasă situaţie, aceea în

care se preferă ca toate derivatele financiare alese în urma algoritmului, să

participe în anumite proporţii (xi) la rentabilitatea (Rp), volatilitatea (p) şi riscul

(σp) portofoliului. Valorile acestor 3 parametrii importanţi se înscriu în limitele

recomandate de literatura de specialitate şi în cele urmărite de practicieni

atunci când tranzacţionează efectiv.

Figura 3.29. – Managementul portofoliului de produse financiare derivate

În acelaşi timp, utilizatorul poate realiza şi un studiu comparativ prin

care decizia sa, poate fi confirmată sau nu. Această posibilitate este oferită de

butonul Comparație active suport care la activare construieşte un portofoliu din

activele suport ale derivatelor aflate în componenţa portofoliului strategic,

respectiv valutele Euro, Usd, Jpy şi acţiunile SIF1 şi SNP. Rezultatele obţinute

sunt comparate şi susţin o decizie corectă de management al portofoliului

strategic de produse financiare derivate.

PROGNOZE PENTRU COTAŢIILE FUTURES ŞI OPTIONS, al-II-lea

subsistem al aplicaţiei, este deosebit de important deoarece, folosind tehnica

regresiilor pot fi previzionate cursurile derivatelor financiare incluse în

portofoliul strategic. În fereastra de lucru a acestui subsistem, utilizatorul

selectează un derivat financiar; automat este afişat intervalul de analiză şi sunt

preluate din baza de date înregistrările aferente; totodată se declanşează o


148

procedură care pentru fiecare derivat inclus în portofoliul strategic şi pe baza

cotaţiilor înregistrate în intervalul de analiză, va calcula regresia de tip liniar,

hiperbolică, putere, exponenţială, logaritmică, parabolică. Cea pentru care se

obţine cea mai mică abatere periodică raportată la trendul cotaţiilor, înseamnă

că este cea care aproximează cel mai bine evoluţia în viitor. Utilizatorul va

trebui să bifeze tipul de regresie recomandat şi în zona de reprezentare grafică

se va trasa trendul previzionat prin această tehnică.

În Figura 3.30. este redat cazul în care utilizatorul doreşte să identifice

trendul viitor pentru contractul futures EuroUsd şi indică faptul că, tipul de

regresie liniar este cel care aproximează cel mai bine evoluţia în perioada

cerută (max 30 zile).

Figura 3.20. – Fereastra de lucru Funcţii de regresie pentru prognozarea trendului

INSTRUMENTE BURSIERE DE ASISTARE A DECIZIEI este

subsistemul III al aplicaţiei şi poate fi utilizat cu succes dacă mai întâi s-a

folosit subsistemul care prognozează trendul. Această succesiune a operaţiilor

este necesară deoarece instrumentele de asistare a deciziei utilizează

valoarea cotaţiilor previzionate în intervalul stabilit de utilizator (1, 2, 3 … max

148

procedură care pentru fiecare derivat inclus în portofoliul strategic şi pe baza

cotaţiilor înregistrate în intervalul de analiză, va calcula regresia de tip liniar,

hiperbolică, putere, exponenţială, logaritmică, parabolică. Cea pentru care se

obţine cea mai mică abatere periodică raportată la trendul cotaţiilor, înseamnă

că este cea care aproximează cel mai bine evoluţia în viitor. Utilizatorul va

trebui să bifeze tipul de regresie recomandat şi în zona de reprezentare grafică

se va trasa trendul previzionat prin această tehnică.

În Figura 3.30. este redat cazul în care utilizatorul doreşte să identifice

trendul viitor pentru contractul futures EuroUsd şi indică faptul că, tipul de

regresie liniar este cel care aproximează cel mai bine evoluţia în perioada

cerută (max 30 zile).

Figura 3.20. – Fereastra de lucru Funcţii de regresie pentru prognozarea trendului

INSTRUMENTE BURSIERE DE ASISTARE A DECIZIEI este

subsistemul III al aplicaţiei şi poate fi utilizat cu succes dacă mai întâi s-a

folosit subsistemul care prognozează trendul. Această succesiune a operaţiilor

este necesară deoarece instrumentele de asistare a deciziei utilizează

valoarea cotaţiilor previzionate în intervalul stabilit de utilizator (1, 2, 3 … max


149

30 zile). Pentru asistarea deciziei, sistemul foloseşte ca instrumente MEDIILE

MOBILE şi OSCILATORII BURSIERI, care pot ghida utilizatorul în stabilirea

numărului de contracte ce pot fi tranzacţionate şi în identificarea momentului

de intrare/ieşire din piaţă.

Astfel, utilizând MEDIILE MOBILE, utilizatorul sistemului va primi suport

decizional prin simpla activare a butonului SUGESTII. Codul Visual C++ ataşat

acestui buton de comandă va testa valorile curente ale cotaţiei, valorile de

minim şi/sau maxim cu valorile calculate pentru media mobilă, fie ea, simplă

sau ponderată şi se vor emite sugestii de genul:

Figura 3.31. - Casetele cu sugestii, care asistă pas cu pas utilizatorul

În cazul mediei mobile exponenţiale, se determină punctele de

intersecţie ale graficului său cu graficul cotaţiilor şi se va sugera frecvenţa de

tranzacţionare, astfel: numărul mic de intersecţii indică posibilităţi mici de

pierdere, iar un număr mare de intersecţii indică majorarea numărului de

tranzacţii dar avertizează că şansele de pierdere cresc proporţional.

Utilizând OSCILATORII BURSIERI putem realiza o analiză mai „fină” a

fenomenelor derulate în „ringul bursier”, în sensul că oscilatorul RSI,

STOCHASTIC şi MAC oferă o privire de ansamblu pertinentă a

comportamentului pieţei studiată din interior. În acest fel, utilizatorul dispune de

asistenţă pentru deciziile sale de tranzacţionare în raport cu:

- semnalele de cumpărare/vânzare semnalate de RSI;

- determinarea poziţiilor relative ale preţurilor de închidere în cadrul

maximelor şi minimelor înregistrate pentru un număr specificat de

zile, de către STOCHASTIC;

- indiciile de intrare sau ieşire din piaţă furnizate de MAC.

TRANZACŢII este al-IV-lea subsistem al aplicaţiei care va fi

folosit atunci când utilizatorul a primit suficiente informaţii de la sistemul suport

pentru a adopta decizii. În acest moment el ştie ce are de făcut, având în

vedere că se cunosc:

149

30 zile). Pentru asistarea deciziei, sistemul foloseşte ca instrumente MEDIILE

MOBILE şi OSCILATORII BURSIERI, care pot ghida utilizatorul în stabilirea

numărului de contracte ce pot fi tranzacţionate şi în identificarea momentului

de intrare/ieşire din piaţă.

Astfel, utilizând MEDIILE MOBILE, utilizatorul sistemului va primi suport

decizional prin simpla activare a butonului SUGESTII. Codul Visual C++ ataşat

acestui buton de comandă va testa valorile curente ale cotaţiei, valorile de

minim şi/sau maxim cu valorile calculate pentru media mobilă, fie ea, simplă

sau ponderată şi se vor emite sugestii de genul:

Figura 3.31. - Casetele cu sugestii, care asistă pas cu pas utilizatorul

În cazul mediei mobile exponenţiale, se determină punctele de

intersecţie ale graficului său cu graficul cotaţiilor şi se va sugera frecvenţa de

tranzacţionare, astfel: numărul mic de intersecţii indică posibilităţi mici de

pierdere, iar un număr mare de intersecţii indică majorarea numărului de

tranzacţii dar avertizează că şansele de pierdere cresc proporţional.

Utilizând OSCILATORII BURSIERI putem realiza o analiză mai „fină” a

fenomenelor derulate în „ringul bursier”, în sensul că oscilatorul RSI,

STOCHASTIC şi MAC oferă o privire de ansamblu pertinentă a

comportamentului pieţei studiată din interior. În acest fel, utilizatorul dispune de

asistenţă pentru deciziile sale de tranzacţionare în raport cu:

- semnalele de cumpărare/vânzare semnalate de RSI;

- determinarea poziţiilor relative ale preţurilor de închidere în cadrul

maximelor şi minimelor înregistrate pentru un număr specificat de

zile, de către STOCHASTIC;

- indiciile de intrare sau ieşire din piaţă furnizate de MAC.

TRANZACŢII este al-IV-lea subsistem al aplicaţiei care va fi

folosit atunci când utilizatorul a primit suficiente informaţii de la sistemul suport

pentru a adopta decizii. În acest moment el ştie ce are de făcut, având în

vedere că se cunosc:


150

- derivatele financiare care pot alcătui un portofoliu strategic;

- evoluţiile pe care le vor urma cursurile derivatelor financiare care

alcătuiesc structura portofoliului;

- valorile previzionate ale cotaţiilor bursiere;

- momentele în care poate intra şi/sau ieşi din piaţă;

- tipurile de operaţiuni pe care le poate iniţia: vânzare sau cumpărare.

La activare, butonul TRANZACŢII va genera un formular (vezi Figura

3.32.) în care există controale grafice proiectate pentru a prelua date

referitoare la broker, clientul în numele căruia se acţionează, obiectul

tranzacţiei, ordinul de tranzacţionare. Toate datele de acest tip vor popula cu

înregistrări tabelele bazei de date xtrade.mdb, astfel încât în urma prelucrărilor

pot fi obţinute o serie de situaţii centralizatoare, rapoarte, etc.

Figura 3.32 – Subsistemul IV: TRANZACŢII

150

- derivatele financiare care pot alcătui un portofoliu strategic;

- evoluţiile pe care le vor urma cursurile derivatelor financiare care

alcătuiesc structura portofoliului;

- valorile previzionate ale cotaţiilor bursiere;

- momentele în care poate intra şi/sau ieşi din piaţă;

- tipurile de operaţiuni pe care le poate iniţia: vânzare sau cumpărare.

La activare, butonul TRANZACŢII va genera un formular (vezi Figura

3.32.) în care există controale grafice proiectate pentru a prelua date

referitoare la broker, clientul în numele căruia se acţionează, obiectul

tranzacţiei, ordinul de tranzacţionare. Toate datele de acest tip vor popula cu

înregistrări tabelele bazei de date xtrade.mdb, astfel încât în urma prelucrărilor

pot fi obţinute o serie de situaţii centralizatoare, rapoarte, etc.

Figura 3.32 – Subsistemul IV: TRANZACŢII


151

BIBLIOGRAFIE

[1] Airinei, D. (2002). Depozite de date, Editura Polirom, Iași.

[2] Agavriloaei, I., Craus, M., Alexandrescu, A. (2011). Performance Evaluation

of a Two Step Clustering Method, Buletinul Institutului Politehnic din Iaşi,

Tome LVII (LXI), Fasc. 2: 31–43.

[3] Azam, M., Khan, A.Q., Stefanescu, L. (2014). Determinants of Stock Market

Development in Romania, Journal of Applied Economic Science, Volume IX,

4(30): 555 – 565.

[4] Barbara, D. (2000). An introduction to cluster analysis for data mining,

http://www-users.cs.umn.edu/~han/dmclass/cluster_survey_10_02_00

[5] Berkhin, P. (2002). Survey of Clustering Data Mining Techniques, Accrue

Software, Inc.

[6] Churchman, W.C. (1968). The Systems Approach, Delacorte Press, New

York.

[7] Constantinescu, D., Ungureanu, A. (1998). Management, Editura Tehnică,

Bucureşti.

[8] Constantinescu M., Ungureanu L., Ștefănescu L. (2010). Portfolio optimal

choice under volatility and price risk impact applied to derivative

transactions, Journal of Applied Economic Sciences, 3(13): 184-196.

[9] Coates, C. (1998). Managerul total, Editura Teora.

[10] Connolly T., Begg C., Strachan A. (2001). Baze de date – proiectare,

implementare, gestionare, Editura Teora, Bucureşti.

[11] Filip, Ghe. (2002). Decizie asistată de calculator – decizii, decidenţi,

metode şi instrumente de bază, Editura Tehnică, Bucureşti.

[12] Fishburn, P.C. (1964). Decision and Value Theory. Operations Research

Society of America, Publications in Operations Research, No 10, John

Wiley and Sons, Inc., New York, London, Sidney, 437 S.

[13] Good, P.I. (2011). A Practitioner’s Guide to Resampling for Data Analysis,

Data Mining, and Modeling, Chapman and Hall Book, Taylor and Francisc

Group, CRC Press, ISBN 9781439855508.

[14] Gorunescu, F. (2006). Data mining. Concepte, modele și tehnici, Editura

Albastră, Clu-Napoca.

151

BIBLIOGRAFIE

[1] Airinei, D. (2002). Depozite de date, Editura Polirom, Iași.

[2] Agavriloaei, I., Craus, M., Alexandrescu, A. (2011). Performance Evaluation

of a Two Step Clustering Method, Buletinul Institutului Politehnic din Iaşi,

Tome LVII (LXI), Fasc. 2: 31–43.

[3] Azam, M., Khan, A.Q., Stefanescu, L. (2014). Determinants of Stock Market

Development in Romania, Journal of Applied Economic Science, Volume IX,

4(30): 555 – 565.

[4] Barbara, D. (2000). An introduction to cluster analysis for data mining,

http://www-users.cs.umn.edu/~han/dmclass/cluster_survey_10_02_00

[5] Berkhin, P. (2002). Survey of Clustering Data Mining Techniques, Accrue

Software, Inc.

[6] Churchman, W.C. (1968). The Systems Approach, Delacorte Press, New

York.

[7] Constantinescu, D., Ungureanu, A. (1998). Management, Editura Tehnică,

Bucureşti.

[8] Constantinescu M., Ungureanu L., Ștefănescu L. (2010). Portfolio optimal

choice under volatility and price risk impact applied to derivative

transactions, Journal of Applied Economic Sciences, 3(13): 184-196.

[9] Coates, C. (1998). Managerul total, Editura Teora.

[10] Connolly T., Begg C., Strachan A. (2001). Baze de date – proiectare,

implementare, gestionare, Editura Teora, Bucureşti.

[11] Filip, Ghe. (2002). Decizie asistată de calculator – decizii, decidenţi,

metode şi instrumente de bază, Editura Tehnică, Bucureşti.

[12] Fishburn, P.C. (1964). Decision and Value Theory. Operations Research

Society of America, Publications in Operations Research, No 10, John

Wiley and Sons, Inc., New York, London, Sidney, 437 S.

[13] Good, P.I. (2011). A Practitioner’s Guide to Resampling for Data Analysis,

Data Mining, and Modeling, Chapman and Hall Book, Taylor and Francisc


[14] Gorunescu, F. (2006). Data mining. Concepte, modele și tehnici, Editura

Albastră, Clu-Napoca.


152

[15] Grossman, D., Frieder, O. (2004). Information Retrieval - algorithms and

heuristics (ed. 2nd). The Information Retrieval Series. Springer.

[16] Holsapple, C.W., Andrew B. Whinston, A.B. (Eds) (1993). Recent

Developments in Decision Support Systems, Volume 101, NATO ASI

Series.

[17] Holsapple, C.W., Andrew B. Whinston, A.B. (1996). Decision Support

Systems: A Knowledge-Based Approach, West Publishing Company.

[18] Jaramillo, P. Smith, R.A., Andreu J. (2005). Multi-Decision-Maker

Equalizer. A multiobjective Decision Support System for Multiple Decision-

Makers, Annals of Operations Research, 138(1): 97-111.

[19] Kimball, R. (1996). The Data Warehouse Toolkit, Wiley.

[20] Kudyba, S. (2014). Big Data, Mining, and Analytics: Components of

Strategic Decision Making, Auerbach Publications, Taylor and Francisc


[21] Lepădatu, C (2013). Sistem pentru asistarea deciziilor bazat pe

descoperirea cunoștințelor din date: rezultate experimentale, Academia

Română, Institutul de Inteligență Artificială.

[22] Li, Y., Chung, S. (2005). Text document clustering based on frequent word

sequences. Proceedings of the 14th ACM international conference on

Information and knowledge management (CIKM '05), 293-294, ACM.

[23] Liu, B. (2011). Web Data Mining. Exploring Hyperlinks, Contents, and

Usage Data (Second Edition). New York: Springer.

[24] MacQueen, J.B. (1967). Some Methods for classification and Analysis of

Multivariate Observations. Proceedings of 5th Berkeley Symposium on

Mathematical Statistics and Probability. Berkeley University of California

Press. 1: 281–297. MR 0214227. Zbl 0214.46201.

[25] Maness, T.S., Zietlow, J.T. (2002). Short – Term Financial Management,

2nd Edition South-Weatern Thomson Learning, London.

[26] Mintzberg, H. (1980). The Nature of Managerial Work, Prentice-Hall.

[27] Nagy, I.M., Onaciu, A. (2012). Two Methodologies for Deriving the Data

Warehouse Structure, Proceedings of the 2nd Symposium on Business

Informatics, Austrian Computer Society Conference, 198 – 206, ISBN:

978-3-85403-280-9.

152

[15] Grossman, D., Frieder, O. (2004). Information Retrieval - algorithms and

heuristics (ed. 2nd). The Information Retrieval Series. Springer.

[16] Holsapple, C.W., Andrew B. Whinston, A.B. (Eds) (1993). Recent

Developments in Decision Support Systems, Volume 101, NATO ASI

Series.

[17] Holsapple, C.W., Andrew B. Whinston, A.B. (1996). Decision Support

Systems: A Knowledge-Based Approach, West Publishing Company.

[18] Jaramillo, P. Smith, R.A., Andreu J. (2005). Multi-Decision-Maker

Equalizer. A multiobjective Decision Support System for Multiple Decision-

Makers, Annals of Operations Research, 138(1): 97-111.

[19] Kimball, R. (1996). The Data Warehouse Toolkit, Wiley.

[20] Kudyba, S. (2014). Big Data, Mining, and Analytics: Components of

Strategic Decision Making, Auerbach Publications, Taylor and Francisc


[21] Lepădatu, C (2013). Sistem pentru asistarea deciziilor bazat pe

descoperirea cunoștințelor din date: rezultate experimentale, Academia

Română, Institutul de Inteligență Artificială.

[22] Li, Y., Chung, S. (2005). Text document clustering based on frequent word

sequences. Proceedings of the 14th ACM international conference on

Information and knowledge management (CIKM '05), 293-294, ACM.

[23] Liu, B. (2011). Web Data Mining. Exploring Hyperlinks, Contents, and

Usage Data (Second Edition). New York: Springer.

[24] MacQueen, J.B. (1967). Some Methods for classification and Analysis of

Multivariate Observations. Proceedings of 5th Berkeley Symposium on

Mathematical Statistics and Probability. Berkeley University of California

Press. 1: 281–297. MR 0214227. Zbl 0214.46201.

[25] Maness, T.S., Zietlow, J.T. (2002). Short – Term Financial Management,

2nd Edition South-Weatern Thomson Learning, London.

[26] Mintzberg, H. (1980). The Nature of Managerial Work, Prentice-Hall.

[27] Nagy, I.M., Onaciu, A. (2012). Two Methodologies for Deriving the Data

Warehouse Structure, Proceedings of the 2nd Symposium on Business

Informatics, Austrian Computer Society Conference, 198 – 206, ISBN:

978-3-85403-280-9.


153

[28] Oashott, L. (1998). Essential Quantitative Methods for Business

Management and Finance, MacMillan Business Ltd.

[29] Popescu, I.A., Găvănescu, P., Rădulescu, D. (1983). Introducere în

fundamentarea deciziei, Editura Științifică și Pedagogică, București.

[30] Popescu, I., Ungureanu L., Muscalu, E. (2005). Decizia sau demersul

antientropic de la cauză la efect, Editura Universității Lucian Blaga, Sibiu.

[31] Popîrlan, C.I., Ștefănescu L. (2011). Intelligent software agents for data

analysis in knowledge-based systems, in Intelligent Decision Support

Systems for Managerial Decision Making, Chapter 2, pp. 25-48, ASERS

Publishing.

[32] Power, D.J. (2000). Web-Based and Model-Driven Decision Support

Systems: Concepts and Issues, Association for Information Systems AIS

Electronic Library (AISeL) AMCIS 2000 Proceedings Americas Conference

on Information Systems (AMCIS) 2000.

[33] Radu, F., Pescaru, Gh. (2006). Relația decizie – decident și rolul ei în

managementul militar. Evaluare psihologică, în Profesionalizarea

psihologiei militare românești, București, Editura Centrului Tehnic-Editorial

al Armatei, 207-217.

[34] Schach, S. (2006). Object-Oriented and Classical Software Engineering,

Seventh Edition. McGraw-Hill. ISBN 0-07-319126-4.

[35] Simon, H. (1960). The New Science of Management Decision, Edition

Harper and Bross, NY.

[36] Spradlin, T. (1997). A Lexicon of Decision Making, DSSResources.COM

[37] Spîrcu C., Lopătan I. (1995). Analiza, proiectarea şi programarea orientate

spre obiecte, Editura Teora, Bucureşti.

[38] Șușnea E. (2008). Extragerea cunoştinţelor din baze de date. Etape şi

metode, The 4th International Scientific Conference eLearning and

Software for Education; Bucharest, 14-17 April, 2008.

[39] Ştefănescu, L., Ungureanu, L., Ştefănescu, A. (2004). The use of the

Hicks Model for verifying the stability and balance of the stock market

system, Revista de Informatică Economică, nr.3, Editura Economică,

Bucureşti.

153

[28] Oashott, L. (1998). Essential Quantitative Methods for Business

Management and Finance, MacMillan Business Ltd.

[29] Popescu, I.A., Găvănescu, P., Rădulescu, D. (1983). Introducere în

fundamentarea deciziei, Editura Științifică și Pedagogică, București.

[30] Popescu, I., Ungureanu L., Muscalu, E. (2005). Decizia sau demersul

antientropic de la cauză la efect, Editura Universității Lucian Blaga, Sibiu.

[31] Popîrlan, C.I., Ștefănescu L. (2011). Intelligent software agents for data

analysis in knowledge-based systems, in Intelligent Decision Support

Systems for Managerial Decision Making, Chapter 2, pp. 25-48, ASERS

Publishing.

[32] Power, D.J. (2000). Web-Based and Model-Driven Decision Support

Systems: Concepts and Issues, Association for Information Systems AIS

Electronic Library (AISeL) AMCIS 2000 Proceedings Americas Conference

on Information Systems (AMCIS) 2000.

[33] Radu, F., Pescaru, Gh. (2006). Relația decizie – decident și rolul ei în

managementul militar. Evaluare psihologică, în Profesionalizarea

psihologiei militare românești, București, Editura Centrului Tehnic-Editorial

al Armatei, 207-217.

[34] Schach, S. (2006). Object-Oriented and Classical Software Engineering,

Seventh Edition. McGraw-Hill. ISBN 0-07-319126-4.

[35] Simon, H. (1960). The New Science of Management Decision, Edition

Harper and Bross, NY.

[36] Spradlin, T. (1997). A Lexicon of Decision Making, DSSResources.COM

[37] Spîrcu C., Lopătan I. (1995). Analiza, proiectarea şi programarea orientate

spre obiecte, Editura Teora, Bucureşti.

[38] Șușnea E. (2008). Extragerea cunoştinţelor din baze de date. Etape şi

metode, The 4th International Scientific Conference eLearning and

Software for Education; Bucharest, 14-17 April, 2008.

[39] Ştefănescu, L., Ungureanu, L., Ştefănescu, A. (2004). The use of the

Hicks Model for verifying the stability and balance of the stock market

system, Revista de Informatică Economică, nr.3, Editura Economică,

Bucureşti.


154

[40] Ștefănescu L. (Ed.) 2011. Intelligent Decision Support Systems for

Managerial Decision Making, ASERS Publishing, ISBN 978-606-92386-5-

3, eISBN 978-606-92386-1-5, 216 pp.

[41] Ștefănescu L. (2005). Managementul operaţiunilor cu produse financiare

derivate asistat de calculator, Editura Didactică şi Pedagogică, Bucureşti.

[42] Ştefănescu, A., Ştefănescu, L. (2013). An intelligent agents’ approach to

support the management decision making process in the virtual

organization, AWERProcedia Information Technology & Computer

Science, 3: 1476-1482. Available from: http://www.world-education-

center.org/index.php/P-ITCS

[43] Thuraisingham, B. (2000). A primer for understanding and applying data

mining. IT Professional, 2(1): 28-31.

[44] Turban, E., Aronson, J. (2001). Decision Support Systems and Intelligent

Systems, Sixth Edition, Prentice Hall International, Upper Saddle River,

New Jersey.

[45] Ungureanu, L., Ungureanu, L. (2000). Elemente de dinamică economică,

Editura Universităţii din Piteşti, Piteşti.

[46] Ungureanu, L. (2012). Mathematical Methods in Economics, ASERS

Publishing, Craiova.

[47] Velicanu, M., Muntean, M. (2001). Modelarea multidimensională, Revista

Informatică Economică, 1(17):1-9.

[48] Wilmont P.,Dewynne J., Howison S., Options Princing, Mathematical

models and computation, Oxford Financial Press, 1995

*** http://www3.shore.net/~kht/text/dmwhite/dmwhite.htm

*** http://www.cio.com/archive/051598_mining.html

*** http://www.oracle.com/ip/analyze/warehouse/datamining/

*** http://www-4.ibm.com/software/data/iminer/fordata/about.html

*** http://www.cognos.com/

*** http://www.angoss.com/

*** http://www.microsoft.com/sql/productinfo/datamine.htm

*** http://www.scitegic.com/products_services/pipeline_pilot.htm

*** http://www.anvilinformatics.com/

154

[40] Ștefănescu L. (Ed.) 2011. Intelligent Decision Support Systems for

Managerial Decision Making, ASERS Publishing, ISBN 978-606-92386-5-

3, eISBN 978-606-92386-1-5, 216 pp.

[41] Ștefănescu L. (2005). Managementul operaţiunilor cu produse financiare

derivate asistat de calculator, Editura Didactică şi Pedagogică, Bucureşti.

[42] Ştefănescu, A., Ştefănescu, L. (2013). An intelligent agents’ approach to

support the management decision making process in the virtual

organization, AWERProcedia Information Technology & Computer

Science, 3: 1476-1482. Available from: http://www.world-education-

center.org/index.php/P-ITCS

[43] Thuraisingham, B. (2000). A primer for understanding and applying data

mining. IT Professional, 2(1): 28-31.

[44] Turban, E., Aronson, J. (2001). Decision Support Systems and Intelligent

Systems, Sixth Edition, Prentice Hall International, Upper Saddle River,

New Jersey.

[45] Ungureanu, L., Ungureanu, L. (2000). Elemente de dinamică economică,

Editura Universităţii din Piteşti, Piteşti.

[46] Ungureanu, L. (2012). Mathematical Methods in Economics, ASERS

Publishing, Craiova.

[47] Velicanu, M., Muntean, M. (2001). Modelarea multidimensională, Revista

Informatică Economică, 1(17):1-9.

[48] Wilmont P.,Dewynne J., Howison S., Options Princing, Mathematical

models and computation, Oxford Financial Press, 1995

*** http://www3.shore.net/~kht/text/dmwhite/dmwhite.htm

*** http://www.cio.com/archive/051598_mining.html

*** http://www.oracle.com/ip/analyze/warehouse/datamining/

*** http://www-4.ibm.com/software/data/iminer/fordata/about.html

*** http://www.cognos.com/

*** http://www.angoss.com/

*** http://www.microsoft.com/sql/productinfo/datamine.htm

*** http://www.scitegic.com/products_services/pipeline_pilot.htm

*** http://www.anvilinformatics.com/


sisteme interactive de asistare a deciziei

Documents