UNIVERSITATEA “SPIRU HARET”

FACULTATEA DE CONTABILITATE SI FINANTE

SPECIALIZAREA CIG ANUL III

SINTEZA CURSULUI LA DISCIPLINA SISTEME INFORMATICE DE

GESTIUNE

Lect univ drd Dragomir Robert

robert.dragomir@spiruharet.ro

1. Managementul afacerii şi tehnologia informaţiei

În desfăşurarea oricărei activităţi economice, financiare sau bancare nu se poate
imagina fără utilizarea unui puternic suport informaţional care să asigure avantajul
concurenţial în raport cu ceilalţi competitori de pe piaţă. A dobândi cunoaştere prin
informaţia obţinută este rolul tehnologiei informaţiei (TI).
De aceea o atenţie sporită se acordă astăzi problemelor legate de managementul
sistemului informatic care se ocupă cu planificarea dezvoltării sistemului informatic la
nivel de firmă, şi folosirea TI cu scopul susţinerii personalului specializat în prelucrarea
datelor în vederea obţinerii informaţiilor necesare luării deciziilor .
Plecând de la exemplul unei firme vom constata că modul de desfăşurare a
afacerii se schimbă ca urmare a acţiunii conjugate a următorilor factori: globalizare,
competiţie de nivel înalt, informaţia devenită resursă cheie a oricărei firme, spaţiul virtual
de muncă şi chiar derularea activităţii în condiţiile companiei virtuale, comerţ electronic,
existenţa în cadrul firmei a personalului specializat în procesarea datelor şi analiză
(knowledge workei), un nou tip de relaţie cu banca prin care se obţin servicii şi produse
noi ca urmare a promovării noilor soluţii TI etc
Funcţionarea firmei în condiţii optime a condus la structurarea unui model
sistemic al întreprinderii format din trei componente: subsistemul decizional, subsistemul
informaţional şi subsistemul operaţional.

1
 Subsistemul decizional pune în valoare informaţiile obţinute de la subsistemul
informaţional şi le foloseşte în derularea actului decizional. La nivelul subsistemului
decizional se restructurează modul de pregătire, adoptare, aplicare şi evaluare a deciziilor,
astfel încât fiecare manager, după implementarea sistemului de management al calităţii,
ştie cu mai multa claritate care este poziţia lui in cadrul subsistemului decizional al
organizaţie.
Subsistemul informaţional are un dublu rol:
- asigură tot suportul informaţional necesar luării oricăror decizii la toate
nivelurile (conducere, control) – flux ascendent
- asigură căile de comunicare între subsistemul operaţional şi subsistemul
decizional – flux descendent
La nivelul subsistemului informaţional se produc schimbări in modul de colectare
a datelor si de structurare a informaţiilor necesare pentru luarea deciziilor si pentru
desfăşurarea activităţii, apar modificări ale circuitelor si fluxurilor informaţionale astfel
încât sa crească viteza de luare a unor decizii precum si capacitatea de răspuns a
organizaţiei la diverşii factori care influenţează profitabilitatea organizaţiei;
Subsistemul operaţional este locul unde practic se culeg datele (din activităţile
economice specifice fiecărui agent economic) ce sunt transmise (ascendent)
subsistemului informaţional. Subsistemul organizatoric al organizaţiei consta in
ansamblul elementelor de natura organizatorica ce asigura cadrul, divizarea, combinarea
si funcţionalitatea proceselor de munca in vederea realizării obiectivelor previzionate.

2
 Exemplu organizarea procesuală a unei instituţii

Exemplu: Noua relaţie cu banca: în ultimii ani se constată efortul constant al

băncilor de a ridica la un nou standard relaţia client-bancă. Internetul a devenit un
important canal de distribuţie permiţând diversificarea produselor şi serviciilor oferite
clienţilor. Utilizarea noilor tehnologii asigură posibilitatea realizării transferurilor
electronice de fonduri, asistarea deciziilor clienţilor în gestiunea portofoliului, mai buna
cunoaştere a clienţilor şi adaptarea ofertei în funcţie de nevoile acestora,
confidenţialitatea informaţiei gestionate, prevenirea şi blocarea tranzacţiilor ilegale,
etc.Sunt utilizate astăzi servicii de tipul: home banking, internet-banking, mobile-
banking.

2. Sistem informaţional, sistem informatic, sistem informatic integrat

Putem defini informatica ştiinţa prelucrării automate a datelor, instrument al

conducerii. Conceptele de bază cu care operează informatica sunt:
- (cunoştinţa = informaţia, după momentul aflării ei) este reflectarea

      

în conştiinţa noastră a elementelor lumii reale, înconjurătoare; informaţia este

sursa de date supuse prelucrărilor, pe de o parte şi interpretarea rezultatelor
obţinute prin prelucrarea datelor, pe de altă parte.
- = data este informaţia (cunoştinţa) înregistrată,

       
  


respectiv reprezentarea scrisă sau grafică a informaţiei obţinută din lumea

3
 înconjurătoare; este materia primă din care se obţine, prin prelucrarea şi
interpretarea rezultatelor acesteia, altă informaţie.
Prelucrarea datelor reprezintă procesul de transformare a datelor în alte date care,
prin interpretare, devin informaţii care stau la baza deciziilor. Prelucrarea datelor folosind
tehnica de calcul este cunoscută sub numele de prelucrarea automată a datelor.
Un sistem reprezintă un ansamblu de elemente (componente) interdependente,
între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv.

Sistemul informaţional economic poale fi definit ca un sistem integrat de

oameni de specialitate, mijloace si procedee adecvate, privind culegerea şi înregistrarea
datelor tehnico-economice si financiare, care privesc patrimoniul unităţilor şi economiei
raţionale în ansamblul acestora, prelucrarea şi analiza acestora, obţinerea de informaţii
utile in vederea conducerii si gestionarii eficiente a acestuia, stocarea si păstrarea datelor
si a informaţiilor pentru documentari si controale ulterioare.
Sistemul informatic este un ansamblu structurat si corelat de proceduri si
echipamente electronice de calcul, care permit culegerea, transmiterea si prelucrarea
datelor, obţinerea de informaţii.
Datele şi informaţiile proprii circuitului economic al patrimoniului sunt
consemnate in documente. În raport de modul de întocmire şi rolul lor în cadrul
sistemului informational, documentele pot fi justificative, de evidenta contabila sau de
sinteza si raportare.
Documentele justificative asigura datele de intrare in sistemul informaţional
contabil, consemnează operaţiile economice şi financiare în momentul efectuării lor, cu
scopul de a servi ca dovada a înfăptuirii lor şi ca instrument de fundamentare a
înregistrării contabile
Prin registrele contabile se formează şi materializează înregistrările proprii
sistemului de conturi. în condiţiile folosirii unor tehnici de prelucrare diferite, ceea ce
diferenţiază un registru de altul este forma de prezentare a informaţiei, conţinutul
rămânând acelaşi. Principalele registre ce se folosesc în contabilitate sunt: registrul
jurnal, registrul inventar şi cartea mare.

4
 Documentele de sinteză şi raportare reprezintă un sistem de indicatori economico-
financiari, ce caracterizează situaţia patrimoniului şi rezultatele obţinute. Se compun din:
bilanţul contabil, contul de rezultate, anexa la bilanţ şi raportul de gestiune
Interfaţa între documentele contabile se realizează prin forma de contabilitate,
reprezentată printr-un sistem de formulare, corelate între ele, care servesc la înregistrarea
şi prelucrarea, după anumite reguli, a datelor privind starea şi mişcarea elementelor
patrimoniale.
Legislaţia şi literatura de specialitate economico-financiară este necesar să fie
bine cunoscute înainte de programarea şi desfăşurarea fiecărei activităţi.
Programarea (planificarea) şi previziunea diferitelor activităţi se bazează atât
pe cunoaşterea legislaţiei şi literaturii economico-financiare, cât şi pe informaţiile
obţinute din evidenţa economică.
Cele mai importante programe la nivel de întreprindere sunt următoarele: programe de
investiţii, programe de aprovizionare şi vânzare de bunuri, servicii şi de marketing,
programe de cercetare-dezvoltare, programe de producţie şi costuri, programe de
salarizare şi personal, programe de impozite, taxe şi alte sume cuvenite bugetului statului
şi celui de asigurări sociale,bugetul de venituri şi cheltuieli al unităţii programe de
creştere sau descreştere a capitalurilor proprii, programe de încasări şi plăţi, de credite
obţinute şi acordate, etc
Pentru aplicaţiile de proiectare există o legătură directă între obiectele lumii reale
şi entităţile definite, datele sunt ierarhizate, manipulându-se legăturile între obiect şi
componentele sale.
Mijloacele de prelucrare a datelor economice reprezintă ansamblul de tehnici şi
echipamente de culegere, prelucrare şi transmitere a informaţiilor.
Metodele şi procedurile de prelucrare referă partea logică a prelucrării datelor în
vederea obţinerii informaţiilor. Evoluţia tehnicii de calcul a adus o varietate de procedee
pentru obţinerea şi prelucrarea datelor, în vederea utilizării lor în gestionarea unei unităţi
economice. Mai mult, se poate asigura simularea evoluţiei diverşilor indicatori sub
acţiunea factorilor de influenţă.

5
 Studiul mediului concurenţial demarează prin stabilirea firmelor concurente,
incluzând organizaţiile care intenţionează să pătrundă pe piaţă şi producătorii de produse
substitute.
Analiza internă a organizaţiei, prin implicarea funcţiei birotice de prelucrare şi
comandă-control, permite managerului să cunoască punctele forte, dar şi cele slabe ale
firmei, elemente care influenţează puterea competitivă a organizaţiei.
3. Sistemul informatic
Sistemul Informatic are funcţia de prelucrare automată a datelor pentru
obţinerea informaţiilor necesare procesului de conducere şi pentru informare.
Pornind de la funcţia sa, sistemul informatic are următoarea structură generală:
• INTRĂRI: totalitatea datelor supuse prelucrărilor;
• PRELUCRĂRI: totalitatea operaţiilor efectuate asupra datelor pentru
obţinerea informaţiilor care stau la baza deciziilor;
• IEŞIRI: rezultatele prelucrărilor efectuate asupra datelor, prin interpretarea
cărora se obţin informaţiile care fundamentează deciziile.
Ca arhitectură (model constructiv), sistemul informatic este alcătuit din:
• HARDWARE: Sistemul de calcul (calculator şi echipamente periferice);
• SOFTWARE: Sistemul de Operare (SO): Windows (98,ME,2000,XP), Apple MAC,.
- programe pentru dezvoltarea de aplicaţii: Sisteme de Gestiune a
Bazelor de Date – SGBD-uri (Access, Fox, etc.) etc.
- limbaje de programare (Visual Basic, C++ etc.);
- programe sau aplicaţii de utilizator (salarii, contabilitate, secretariat,
conturi clienţi, valută etc.)
• COLECŢII ORGANIZATE DE DATE: Baze de Date – BD;
• SISTEM DE COMUNICAŢII: intranet, internet, telecomunicaţii etc.;
• RESURSE UMANE: personal tehnic, personal de exploatare, utilizatori etc.;
• CADRU ORGANIZATORIC.

6
4. Principii utilizate in proiectarea sistemelor informatice

Desfasurarea unei activitati riguroase si performante de proiectare si realizare de

sisteme informatice de financiar bancare impune respectarea unor principii:

. Fiind vorba de reali-
                       

a

zarea unui sistem informatic al firmei se impune definirea mai intai

a unei solutii globale de informatizare ceea ce va conduce la reali-
zarea unei solutii informatice integrate, stabilirea unei structuri flexi-
bile a sistemului informatic, precizarea prioritatilor in realizarea
componentelor sistemului informatic;



     

      

 
   
         
   

    


               
 

      
     

  
   
    


a



  
    
   
    
   

 



  
  

. Acest lucru va asigura pe de o parte o buna

   
 
    
        

functionare a sistemului. Daca insa exista particula-ritati deosebite privitoare la

modul de organizare a activitatii si acest lucru se repercuteaza asupra fluxuiui
informational si procesului de prelucrare a datelor sistemul informatic va trebui sa
raspunda acestor particularitati;


 
    
    
  
    
       


  
    

. O astfel de participare
   
     

 
   
    


a
asigura formularea clara a specificatiilor necesare proiectarii si validarea
esalonata a solutiilor propuse de proiectant toate acestea asigurand in final un
produs care sa corespunda
deplin cerintelor utilizatorului;

. Fiind vorba de sisteme informatice
 
             


devine obligatorie realizarea evidentelor in cadrul

firmei, calcularea indicatorilor si intocmirea lucrarilor de sinteza in
conformitate cu reglementarile aflate in vigoare.

7
5. Arhitectura sistemelor informatice

Arhitectura sistemului informatic reprezinta solutia generica privitoare la
procesele de prelucrare a datelor ce trebuie sa se realizeze si modul de integrare a
datelor si prelucrarilor.

In definirea arhitecturii sistemului informatic s-au cristalizat in timp trei strategii
 Strategia descendenta
 Strategia ascendenta
 Stategia mixta

Strategia descendenta numita top-down pleaca de la principiul descompunerii
sistemului informatic complex in componente prezentand o complexitate mai
redusa parcurgandu-se succesiv mai multe nivele de detaliere in cadrul fiecarei
componente definite

Strategia ascendenta numita si bottom up promoveaza initiativa la nivelul fiecarui

domeniu. Strategia ascendentă (botton-up) este opusă metodei top-down având la bază
principiul agregării şi constă în identificarea de jos în sus a componentelor unui sistem şi

8
asamblarea succesivă a modulelor definite pe diferite nivele ierarhice şi a relaţiilor dintre
acestea astfel încât se ajunge la un singur modul corespunzător sistemului. Combinată cu
metoda ascendentă a condus la „ strategia mixtă”care îmbină elemente de la ambele
promovează iniţiativa la nivelul fiecărui domeniu de gestiune. Această strategie
presupune identificarea problemelor organizaţiei şi a posibilităţilor oferite pentru
definirea proiectelor. Se dezvoltă soluţii informatice la nivelul fiecărui domeniu de
gestiune (contabilitate, comercial, producţie etc.) fără a exista o soluţie cadru şi o
arhitectură definită pentru sistemul informatic global la nivel de organizaţie.
Sistemele de gestiune se realizează şi exploatează independent pe măsura
finalizării lor, răspunzând cerinţelor de gestiune ale domeniilor pentru care au fost
realizate, urmând ca ulterior să se treacă la integrarea acestora în cadrul sistemului
informatic global al organizaţiei. Metoda cere un timp mai scurt şi este mai ieftină, având
avantajul de a se şti cu exactitate problemele cu care se confruntă unitatea. Datorită lipsei
unei strategii unitare în plan hardware şi software, a unei soluţii unitare de proiectare şi
realizare există riscul unui grad redus de integrare a subsistemelor de gestiune cuprinse în
cadrul sistemului informatic al organizaţiei. Ca dezavantaj se consideră lipsa unui punct
de vedere de ansamblu, la nivel de unitate.

Stategia mixta reprezinta o combinare a celor doua strategii, descendenta si
ascendenta, retinandu-se punctele lor forte. În această abordare se optează pentru o
definire a componentelor sistemului informatic în conformitate cu cerinţele strategiei
descendente, urmând ca proiectarea, realizarea şi integrarea acestor componente să se
realizeze urmând cerinţele strategiei ascendente.

6. Strategii de dezvoltare a sistemelor informatice

Considerăm că dacă s-ar porni de la conceptul filosofic de “Existenţă
Fundamentală”, ceea ce DeMarco numea „forma solidului" - cu trimitere la obiectele
palpabile - ajungem la Substanţă, Energie, Informaţie. Informaţia este văzută de
DeMarco, în 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor
informaţionale sau prin trei dimensiuni: date, funcţii, comportament.
Datele sunt surprinse prin prisma structurii lor sub formă de atribute şi înseamnă,
de fapt, ceea ce sistemul are stocat şi-şi poate „reaminti" oricând despre fenomenele sau
procesele studiate. Ele reflectă structura statică a sistemului informaţional.

9
 Funcţiile scot în evidenţă, în mod limitat, ceea ce face sistemul. Ele pot fi văzute
şi ca procese, întrucât elementele sistemului despre care se păstrează datele de rigoare
sunt supuse unor transformări funcţionale, prin intermediul proceselor.
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a
sistemului, tot limitată, pentru surprinderea stărilor comportamentale prin care acesta ar
trece, reliefându-se influenţa evenimentelor, ceea ce ar sugera dinamica lui.
Pornind de la aspectul tridimensional al sistemelor informaţionale, se poate afirma
că acestea pot fi axate pe una, două sau toate cele trei dimensiuni, ceea ce îndreptăţeşte pe
Whitmire25 să spună că, atunci când aplicaţiile sunt net dominate de una dintre cele trei
dimensiuni, ele sunt data-strong, function-strong sau control-strong. Tot el adaugă că,
atunci când dimensiunea dominantă, nu este clară, ele pot fi considerate aplicaţii hibride.
Preluând comportamentul hologramelor, la care însă nu face nici o referire, reţine că
obiectele luate individual păstrează caracteristicile întregii aplicaţii.

Strategia descompunerii funcţionale (orientate-funcţii)

Strategia descompunerii funcţionale a sistemelor informatice, care este orientată pe
funcţii, nu poate să conducă la conceperea unor sisteme suficient de stabile. Totuşi, pe
lângă problema complexităţii, stabilitatea arhitecturii programelor este una din
principalele mize ale acestei abordări. În acest sens, trebuie amintit conceptul de
independenţă funcţională care stă la baza proiectării arhitecturale a programelor.
Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi
analizei structurate. Fiecare funcţie este descompusă în subfuncţii etc., până când se obţin
forme uşor de transpus în instrucţiunile limbajelor de programare.
Descompunerea funcţională (DF) este văzută ca o sumă de funcţii, subfuncţii şi
interfeţe funcţionale, sub forma unei ecuaţii:

     
   

    
  
  



Metoda are ca puncte tari simplitatea, obţinerea destul de uşoară a cerinţelor

utilizatorului şi generarea de soluţii pe diferite niveluri de abstractizare (sistem,
subsistem, funcţie, subfuncţie).
Ca puncte slabe putem considera concentrarea eforturilor spre funcţii (ceea ce
conduce la culegerea multor date redundante), inexistenţa unor reguli precise de

10
 descompunere şi evidenţierea anevoioasă a interacţiunilor non-ierarhice din sistemele
complexe.
Strategia fluxurilor de date (orientate-proces)
O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului
problemei şi responsabilităţilor sistemului printr-o specificaţie tehnică este metoda
orientată spre procese, deseori descrisă ca „analiza structurată".
Ecuaţia metodei este:

     
     
 
     

       
      
        


 

       
   
        

       
      

         

       
     
   

Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale
fluxurilor de date şi cerculeţe pentru procese. În timp, s-au conturat două strategii în
analiza structurată. Se vorbeşte despre o metodă „veche" şi despre o metodă „modernă"
de analiză structurată, lansată în dezbateri la nivelul anului 1982 şi prin materialele
editate în 1984 - reprezentative fiind lucrările autorilor McMenamin&Palmer, din 1984,
şi a lui Yourdon, “Analiza modernă structurată” din 1989. În ultima variantă sunt definite
cu claritate evenimentele din lumea reală la care sistemul trebuie să răspundă, o formă
embrionară a actualelor interacţiuni dintre utilizator şi sistem, bazate pe mesaje. Sunt
incluse de asemenea, fluxurile datelor şi transformările la nivel inferior prin intermediul
dicţionarului de date, respectiv al specificaţiilor proceselor.
Cum metoda orientată pe procese are încă un mare grad de asemănare cu
descompunerea funcţională, criticile metodei descrise anterior se reportează şi în cazul de
faţă. Oricum, după cum se va vedea ulterior, multe elemente ale acestei metode sunt
preluate de către metodele orientate-obiect.
Strategii orientate spre informaţii (orientate-date)
Majoritatea specialiştilor consideră ca se poate obţine un plus de stabilitate dacă
structura propriu-zisă a sistemului informatic se limitează la descrierea datelor şi a bazei
de date, presupunându-se că tipurile de date utilizate în cadrul organizaţiei sunt supuse
mai puţin schimbării decât prelucrările din sistem.
Această orientare a dus la apariţia strategiei orientate pe date. Chiar dacă
valoarea datelor se schimbă în mod constant, structura datelor nu presupune modificări

11
esenţiale, dacă ea a fost bine proiectată de la început. De regulă, clasele de entităţi în
legătură cu care se vor memora datele în sistem nu se schimbă, rareori fiind necesară
introducerea unei noi clase de entităţi, caz în care structura nu suferă transformări
esenţiale, ci presupune doar adăugarea noii clase la structura existentă.
Termenul „obiect", folosit în modelarea informaţiilor sau modelarea semantică a
datelor, este un simbol prin care se reprezintă una sau mai multe „ocurenţe" (cazuri) ale
„entităţilor" lumii reale. Metoda este identificată prin următoarea ecuaţie28:
     
         

 
       
  

  

  

 
   
 

Coad şi Yourdon spun că şi în acest caz se poate vorbi despre existenţa a două
strategii. Strategia veche se bazează pe conceperea listei atributelor, gruparea lor în
obiecte, stabilirea de relaţii între „ocurenţe" (cazuri), folosirea supertipurilor/subtipurilor
pentru extragerea atributelor comune şi definirea obiectelor asociative pentru reliefarea
relaţiilor sigure.
Noua strategie este destul de apropiată de precedenta, cu excepţia primului pas,
care îşi propune mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor
cu ajutorul atributelor. Specialiştii apreciază salturile înregistrate însă, în acelaşi timp, fac
inventarul conceptelor inexistente, cum ar fi: servicii, mesaje, moştenire, structură.
Strategii orientate-obiect
Strategia orientată-obiect pune în centrul atenţiei noţiunea de obiect, considerată
drept o entitate care se poate distinge dintre alte entităţi şi care are o semnificaţie în
contextul aplicaţiei modelate. Obiectul asociază datele şi prelucrările în cadrul aceleiaşi
entităţi, rămânând vizibilă doar interfaţa obiectului.
Un obiect comportă un aspect static, reprezentat prin intermediul unor variabile de
stare numite atribute şi un aspect dinamic, reprezentat de comportamentul obiectului.
Aspectul static este ascuns de aspectul dinamic.
Sintagma „orientat-obiect" este destul de greu de definit din cauza accepţiunilor
diferite care i s-au atribuit de diverse discipline. Numai în domeniul informaticii există
vreo trei variante: una folosită în modelarea informaţiilor, alta în programare şi a treia
este cea de faţă, utilizată în analiza şi proiectarea sistemelor. Fiind un domeniu relativ

12
nou, este normal să existe o mare diversitate de opinii până şi asupra termenului „obiect".
Ecuaţia ce caracterizează metoda, o redăm în cele ce urmează29:



 
   
  

    
    
   

=

Conceptele de obiect şi clasă sunt interdependente: un obiect aparţine unei clase

(este o instanţă a clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi
structură şi un
comportament similar. Un obiect este şi
 
  
     
    

 

poate fi descris astfel30:


 



     
 


  

= 

Identitatea obiectului se realizează printr-un al obiectului, care este



  
 

un atribut invariabil ce permite ca obiectul să fie referit independent de celelalte obiecte.

Identificatorul este generat de sistem la crearea obiectului.
obiectului este o valoare care poate fi simplă (de exemplu, un literal) sau

  

structurată (de exemplu, o listă). In ultimul caz, ea poate fi compusă din valori simple,
referinţe la alte obiecte sau valori care ele însăşi sunt structurate.
unui obiect este definit printr-un set de operaţiuni ce-i pot fi
    
 

 

aplicate şi este descris în clasa căreia îi aparţine obiectul.

Concluzionând, putem afirma că obiectul este o abstractizare a datelor elementare,
caracterizat printr-un identificator unic, invariabil, o clasă căreia îi aparţine şi o
stare reprezentată printr-o valoare simplă sau structurată.

Deschiderea catre utilizarea tehnologiilor moderne este urmarea intelegerii
necesitatilor bancare:

Regandirea relatiei cu clientii

Reorganizarea interna a activitatii privind procesele legate de exploatarea
si limitarea restrictiilor spatio-temporale in raport cu clientii

Capitalizarea si difuzarea cunostintelor in cadrul bancii

Schimbarea planului managementului bancar

Cresterea operativitatii, sigurantei si eficientizarii tranzactiilor intra si
interbancare

Alinierea la standardele europene si mondiale privind efectuarea
tranzactiilor bancare si a schimbului de informatii

13

Arhitectura noilor sisteme informatice bancare are la baza o noua abordare
caracterizata prin orientarea pe client, nu pe conturi sau produse si vizeaza in
principal obiectivele bancii:
introducerea la timp a noilor produse si servicii specificate in strategia de dezvoltare,
posibila datorita parametrizarii si flexibilitatii deosebite ale solutiei
standardizarea produselor oferite prin intermediul tuturor canalelor de distributie,
posibila datorita modului de lucru centralizat
automatizarea tranzactiilor complexe, posibila prin caracteristica de STP a solutiei
posibilitatea de a raspunde la cerinte unicat venite din partea clientilor individuali sau
corporate, utilizarea de valori specifice pentru parametrii definiti la nivel de client,
contract sau chiar operatiune
minimizarea riscurilor operationale, prin utilizarea politicilor multiple de securitate si
a urmaririi modificarilor din sistem
capacitatea de procesare a volumelor mari de tranzactii, prin scalabilitatea dovedita a
solutiei
oferirea de servicii bancare non-stop, prin posibilitatea de a genera tranzactii in regim
24x7 integrarea tuturor proceselor bancare intr-un singur sistem, prin functionalitatea
extinsa, end-to-end a solutiei.

OPERATIUNI

Conturi curente

Home banking

Decontari electronice

Depozite

Certificate de depozit

Carduri

Casa

Alte operatii (decontari facturi, incasari facturi etc)

CLIENTI, subsistem ce permite actualizarea permanenta a datelor privind clientii
bancii, prin gestiunea unica a clientilor

CREDITE, asigurand gestiunea contractelor de credite cu doua module

14

Gestiunea riscului

Gestiunea propriu-zisa

JURIDIC, dezvoltat pe doua module

Legislativ

Gestiunea creditelor litigioase

CONTABILITATE, cu urmatoarele functiuni de baza:

Actualizarea planului de conturi

Definirea conditiilor de dobanda la nivelul conturilor sintetice si analitice

Definirea monografiei de operatiuni bancare

Deschiderea si inchiderea conturilor interne

Calculul, inregistrarea si plata/incasarea dobanzilor

Situatii contabile de sinteza si raportare

PERSONAL, asigurand gestiunea personalului si calculul salariilor

MARKETING, oferind informatii specifice activitatii de conducere

MANAGEMENT BANCAR, subsistem specializat in determinarea si
monitorizarea indicatorilor de rating bancar

7. Ciclul de viaţă a unui sistem informatic

Sistemul informatic (SI) ca orice entitate a lumii reale prezintă propriul său ciclu
de viaţă. Ciclul de viaţă presupune parcurgerea unor etape, descompunerea la rândul lor
în faze, care asigură: conceperea, realizarea, implementarea, exploatarea şi întreţinerea
sistemului.
Diferitele abordări au condus la precizarea unor faze comune ale ciclului de viaţă:
1. Definirea cerinţelor utilizatorului
2. Specificaţia cerinţelor sistemului
3. Specificaţia cerinţelor software
4. Proiectarea generală
5. Proiectarea de detaliu
6. Realizarea componentelor SI
7. Testarea componentelor
8. Integrarea componentelor

15
 9. Implementarea şi testarea produsului
10. Exploatarea şi întreţinerea sistemului
11. Dezvoltarea SI

8. Strategii de parcurgere a etapelor din ciclul de viaţă în realizarea sistemelor

informatice
Pornind de la ciclul de viaţă al sistemelor spre cel al obiectelor, surprindem o
sintagmă esenţială în activitatea de analiză şi proiectare a sistemelor, respectiv ciclul de
viaţă al dezvoltării sistemelor (CVDS) sau ciclul dezvoltării sistemelor (CDS).
Ciclul de viaţă al dezvoltării sistemelor este „o metodologie comună de dezvoltare
a sistemelor din multe organizaţii, caracterizată prin câteva faze care marchează evoluţia
eforturilor de analiză şi proiectare a sistemelor".
Prin parcurgerea materialelor de specialitate, am putut constata că numărul
fazelor/etapelor variază de la trei (de exemplu: analiză, proiectare, implementare) la peste
douăzeci. Firesc, în cel de-al doilea caz, nici simpla enumerare a lor nu este edificatoare.
Totuşi, s-ar putea formula o concluzie: în fazele incipiente de abordare a sistemelor,
numărul etapelor se situa la aproximativ şase. Ele erau descompuse pe activităţi,
subactivităţi, operaţiune firească, apreciem noi, datorită influenţei gândirii bazate pe
descompunerea funcţională, care era la modă. Prin trecerea la orientarea-procese şi
orientarea-date, considerăm că s-au înregistrat două fenomene: diversificarea etapelor;
revizuirea modelului sub care se manifestă ciclicitatea.
Datorită marii diversităţi a opiniilor, considerăm binevenită o descriere sumară a
mai multor modele, cu atât mai mult cu cât în literatura noastră subiectului de faţă nu i se
acordă importanţa cuvenită.
Modelul cascadă este unul de referinţă, asigurând trecerea de la o etapă la alta,
ce-i drept mai mult teoretică, în ordine secvenţială. Realitatea a demonstrat că
parcurgerea etapelor/fazelor într-o astfel de ordine nu este o regulă, întrucât, de cele mai
multe ori, se înregistrează reveniri la etapele anterioare sau parcurgerea în paralel a unora
dintre ele.

16
 Modelul V este o variantă a modelului cascadă, prin care se introduc conceptele
de sistem şi componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic
pentru creşterea controlului asupra modului în care se desfăşoară etapele.
Tocmai această înlesnire constituie o latură a literei V. Prima este latura din
stânga, parcursă descendent, şi conţine treptele propriu-zise, iar cea de-a doua latură, din
dreapta, se parcurge ascendent, pe ea realizându-se verificările şi validările elementelor
create anterior. Acest model punctează cu mai multă claritate separările dintre ceea ce
implică participarea utilizatorului, modelul arhitectural şi cel al implementării.
Utilizatorul este implicat doar în fazele din partea superioară a V-ului.

Modelul incremental, este o altă variantă a modelului cascadă care promovează ideea
proiectării şi realizării independente a componentelor după definirea arhitecturii globale a
SI. Proiectarea şi realizarea SI se face astfel în conformitate cu principiile metodelor top-

17
down. Sistemul va putea fi livrat beneficiarului şi etapizat pe măsura realizării
componentelor (în funcţie de priorităţile formulate de beneficiar) dar, într-o astfel de
abordare pot apărea dificultăţi legate de integrarea componentelor în sistemul final.

Modelul spirală este lansat de unul dintre specialiştii cu preocupări mai vechi
legate de ciclul de viaţă, B.W. Boehm. Acesta s-a ocupat de aşa-zisele modele
tradiţionale încă din anul 1981, iar în 1986 anunţă modelul spirală şi publică rezultatele
cercetării sale în 1988. El se bazează pe două convingeri: natura iterativă a dezvoltării şi
nevoia de planificare şi evaluare a riscurilor fiecărei iteraţii; deficienţa înregistrată la
modelul V, în care validarea se efectuează prea târziu, îl face să propună, dimpotrivă,
realizarea acesteia cât mai devreme posibil, de cât mai multe ori, prin construirea
prototipurilor, conform modelului simplificat din figura de mai jos:

In principiu, modelul evolutiv constă în efectuarea unei investigaţii iniţiale, elaborarea

unei strategii pentru descompunerea proiectului în părţi/segmente, fiecare cu o valoare
deosebită pentru client. Ele sunt realizate şi livrate în mod iterativ şi contribuie la sporirea
treptată a performanţelor sistemului. Formele obţinute pentru părţile componente nu sunt
foarte puternic detaliate, lăsându-se loc pentru adaptări şi modificări ulterioare.

18
 Modelul tridimensional a fost lansat în Franţa şi susţinut de adepţii acestei şcoli.
El a fost introdus odată cu metoda Merise. Susţinători ai modelului (Bouzeghoub,
Gardarin, Valduriez) aceştia consideră că este singurul model care ţine cont de aspectele
impuse de bazele de date, prin încorporarea clară a nivelurilor ANSI/SPARC. Modelul
surprinde dezvoltarea sistemelor printr-o redare grafică bazată pe trei axe, descriind ciclul
de viaţă al sistemului, ciclul de viaţă al proiectului şi ciclul de viaţă al abstractizării .

19
Modelul X îşi propune să extindă aria performanţelor obţinute prin modelele cascadă şi
V, ambele fiind considerate ca exemple de modele ale procesului de dezvoltare care, la
rândul lui, ar fi parte integrantă a unui proces mai larg, al livrării sistemelor, pentru care
Hodgson, în 1991, propune un model special. Modelul X exprimă două mari categorii
de cicluri de activităţi: una derulată înainte (forward activity), care sintetizează sistemul
nou (sau modificat) şi o activitate derulată înapoi (reverse activity) pentru dobândirea
sistemelor şi a componentelor lor, pentru catalogarea diverselor modele, arhitecturi şi
componente ale activităţii finalizate pentru o posibilă reutilizare. Ingineria preventivă
(forward engineering) de la nivelul fiecărui stadiu al procesului încearcă să reutilizeze -
prin selecţie, adaptare, rafinare - acumulările anterioare care se regăsesc în bibliotecile
sistemelor. Schematic, modelul X este prezentat în figura de mai jos.

20
 Modelul fântână arteziană îşi are originea în modelul spirală şi în altele care au
reprezentat îmbunătăţiri ale acestuia. Ne referim la modelul spirală ierarhic şi vârtej de
apă.

21
Tema - exemplu
         
  
                 

1.    
                
      

În conceperea şi realizarea SI,     
            (PG) deţine o pondere deosebită,

deoarece aceasta defineşte structura şi funcţionalitatea noului sistem în raport cu obiectivele
şi cerinţele solicitate de către beneficiar.

Etapa de PG a unui SI are ca obiectiv elaborarea concepţiei logice a SI, adică defineşte
SI atât structural, cât şi funcţional.

Cu alte cuvinte,     
            asigură modelarea conceptuală a noului sistem,

inclusiv stabilirea componentelor de sistem (subsisteme şi unităţi funcţionale), a legăturilor
dintre acestea şi a funcţionalităţii structurii sale în aşa fel, încât întregul sistem să acţioneze
ca un tot unitar. Astfel, la etapa de proiectare generală sunt definite obiectivele noului SI, se
determină structura bazei informaţionale, se asigură formalizarea atributelor de intrare şi se
proiectează organigrama noului sistem.

Organizarea şi conducerea proiectării generale presupune stabilirea unui colectiv

pentru realizarea proiectării generale şi elaborarea unui plan de realizare a acestei etape.
Managerul de proiect asigură planificarea, organizarea, coordonarea şi urmărirea întregii
activităţi, elaborează graficul de desfăşurare a fazelor proiectării generale, stabileşte, pentru
fiecare fază, termenul de realizare, obiectivele specifice şi personalul implicat.
PG presupune folosirea unor variante de abordare, utilizate în funcţie de următorii
factori:
• Complexitatea obiectivelor stabilite;
• Aria de cuprindere a noului SI;
• Posibilităţile de modificare a ieşirilor solicitate de unitatea beneficiară (UB).
Aceste variante sunt bazate pe aplicarea anumitor principii, şi anume:
• IEŞIRI – INTRĂRI;
• INTRĂRI – IEŞIRI;
• MIXTĂ.
începe cu precizarea obiectivelor noului SI, în raport


    
             

cu cerinţele UB. Obiectivele sunt concretizate în ieşirile sistemului ale căror atribute
formează baza informaţională (BI) de ieşire care este analizată în raport de modul de
obţinere a atributelor de ieşire, în scopul definirii BI de intrare.
Prin urmare, această variantă presupune parcurgerea următoarelor faze:
• Definirea obiectivelor SI;

22
 • Definirea ieşirilor SI;
• Definirea BI;
• Formalizarea atributelor, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare.
• Definirea structurii funcţionale a SI;
• Elaborarea documentaţiei PG.
  

 acestei variante se explică prin furnizarea unui conţinut complet al BI de
intrare, determinat strict pe baza ieşirilor solicitate.
      

 – imposibilitatea obţinerii de noi rapoarte sau indicatori. În cazul
schimbării conţinutului şi setului de ieşiri informaţionale de către UB, este necesară o
reexaminare a conţinutului BI de intrare.
porneşte de la determinarea obiectivelor, iar apoi se


    
             

determină mulţimea intrărilor necesare, structurate sub forma BI de intrare, care este
analizată în vederea BI de ieşire.
Adică, această variantă include următoarele faze:
• Definirea obiectivelor SI;
• Inventarierea tuturor atributelor de intrare şi a legăturilor sau corespondenţelor
dintre acestea pe baza documentelor de intrare utilizate;
• Definirea BI de intrare;
• Formalizarea atributelor, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare.
• Definirea ieşirilor SI;
• Definirea structurii funcţionale a SI;
• Elaborarea documentaţiei PG.
  

 acestei variante – flexibilitatea conţinutului BI de intrare în condiţiile apariţiei
de modificări ale ieşirilor informaţionale.
      

 – BI este supradimensionată, ceea ce implică timp mare de realizare ,
costuri ridicate de proiectare, realizare şi o sporire a complexităţii prelucrărilor SI.
are în vedere definirea modelului conceptual al SI folosind avantajele


    
     

celor două variante prezentate.

Varianta include următoarele faze:

23
 • Definirea obiectivelor SI;
• Definirea iniţială a BI;
• Formalizarea atributelor de intrare şi ieşire, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare;
o Definirea BI de ieşire şi stabilirea ieşirilor prezente şi previzibile;
• Redefinirea BI iniţiale şi stabilirea structurii finale a acesteia;
• Definirea structurii funcţionale a SI;
• Elaborarea documentaţiei PG.
Analizând variantele prezentate rezultă că, fazele PG sunt comune tuturor variantelor de
abordare, dar succesiunea lor este diferenţiată de la o variantă la alta. În general, se optează
pentru una dintre variante, având în vedere:
• Obiectivele SI;
• Dimensiunea SI;
• Volumul atributelor BI;
• Costurile şi termenul de realizare a SI, etc.
       , buna desfăşurare a etapei de proiectare conceptuală obligă conducerea
unităţii beneficiare să analizeze pe parcurs stadiul lucrărilor, să sintetizeze toate cerinţele
utilizatorului într-un mod cât mai eficient, să evalueze toate variantele, să selecteze şi să
avizeze cea mai bună cale de obţinere a informaţiilor necesare.

     
       
      
          
 

Obiectivul     
       
       presupune transformarea modelului conceptual

al noului sistem într-un model operaţional (tehnic, de detaliu), în concordanţă cu un sistem de
gestiune a datelor şi un sistem electronic de calcul.
Proiectarea de detaliu este una din cele mai dificile etape a ciclului de viaţă al
sistemului informatic, de aceea necesită un deosebit efort managerial privind organizarea,
urmărirea şi controlul activităţilor vizate. Acesta presupune organizarea colectivelor de
specialişti şi repartizarea sarcinilor, atribuţiilor şi responsabilităţilor, supravegherea
activităţilor de proiectare de detaliu a unităţilor funcţionale şi unităţilor de prelucrare,
supravegherea termenelor, respectării metodologiilor de elaborare, evaluarea soluţiei

24
optime de gestiune a datelor şi a sistemului electronic de calcul, validarea rezultatelor
obţinute în raport cu cerinţele, normativele şi standardele prestabilite.
Astfel, printre activităţile etapei de PD pot fi enumerate următoarele:
• Proiectarea ieşirilor şi intrărilor SI;
• Proiectarea BI;
• Definirea sistemului de fişiere şi / sau bazei de date;
• Realizarea programelor;
• Organizarea procesului tehnologic de prelucrare a datelor.

Notă: Caracteristica detaliată a acestor activităţi, va fi prezentată în tema ce va urma.

9. Implementarea şi exploatarea sistemului informatic.

În literatura de specialitate se menţionează că etapa de implementare este “piatra de

încercare” a sistemului informatic. Obiectivul implementării presupune testarea (verificarea)
sistemului proiectat şi realizat fizic în condiţiile reale din unitatea beneficiară şi aducerea la
stadiul de funcţionare şi exploatare efectivă.
Această etapă include multe aspecte specifice care impun deosebite activităţi
manageriale, materializate prin planificarea implementării şi prin asigurarea condiţiilor
organizatorice, financiare, materiale, informaţionale şi informatice necesare implementării,
inclusiv asigurarea operativităţii, calităţii şi acurateţei datelor de intrare. De asemenea, aceste
activităţi includ şi verificarea performanţelor sistemului informatic proiectat. Elaborarea
planului de implementare asigură repartizarea în timp a lucrărilor, resurselor şi sarcinilor
personalului care realizează punerea în funcţiune a sistemului proiectat. De asemenea, se
stabileşte succesiunea procedurilor şi activităţilor presupunând realizarea implementării şi
conversiei în condiţii de maximă eficienţă şi minime de timp.
Exploatarea curentă şi menţinerea în funcţiune a sistemului informatic include
activităţile vizând utilizarea propriu-zisă a sistemului informatic din unitatea beneficiară şi
activităţile de perfecţionare şi menţinere în stare funcţională şi operaţională a acestuia, până la
înlocuirea sa cu un alt sistem informatic mai performant, adică până la finele ciclului de viaţă
al sistemului.

Exemplu       
  
          
            
               

25
Concepţia şi optimizarea sistemelor informatice financiar bancare trebuie să se realizeze pe 3
niveluri:
- decizional
- datawarehouse & reporting
- front office – back office

1. Decizional (nivelul conducerii)

Priorităţile sunt reprezentate de flexibilitatea structurilor de date, serverele puternice,
prelucrările au ca scop actualizarea permanentă a datelor.
2. Datawarehouse & reporting (nivelul conducerii)
Datawarehouse
– depozite de date (baze de date multidimensionale)
- permite prin instrumentele sale specifice (analiza multidimensională) explorarea
informaţiilor stocate şi crearea legăturilor dintre datele actuale şi cele istorice.
- structurile de date oferă o interogare performantă a cererilor multiple.
Exemplu: Orice bancă dispune de o colecţie mare de date despre clienţii săi, dar este
gestionată dispersat.
3. Front office / Back office
Front office
– relaţia clientului cu banca (telefon, suport de hârtie, e-mail, web)
- interfaţa utilizatorului pentru operaţiuni de cont curent, gestionarea portofoliului,
asistenţă
Middle office
- permite circulaţia datelor în dublu sens reţinându-le prin două imagini separate ale
datelor
- rolul de bază este a) colectarea, agregarea şi consolidarea informaţiilor
b) asigurarea managementului calităţii
c) asigurarea distribuţiei informaţiei şi raportarea
Back office
- stocarea şi prelucrarea datelor
- locul unde se execută procesele tranzacţionale
- aici se găsesc aplicaţiile şi bazele de date
- locul de unde îşi i-a informaţia Front office-ul

26
 10. Definiţia şi conţinutul metodologiilor

Metodele şi conceptele fundamentale de realizare a sistemelor informatice financiar bancare

au la bază termenii de metodă şi metodologie asociaţi direct domeniului financiar bancar.
Aceşti termeni se definesc ţinând cont de:
- specificul domeniului financiar bancar
- evoluţia cadrului legislativ
- dinamica activităţii de informatică şi tendinţele fundamentale de evoluţie a sistemelor
financiar bancare.
 
   – reprezintă totalitatea conceptelor, modelelor, nivelelor, etapelor şi tehnicilor
specifice de formalizare necesare pentru definiţiile, listele, comunicaţiile, datele şi
prelucrările specifice unui sistem informatic financiar bancar.
 
        – reprezintă setul finit particular definitoriu al unei metode prin intermediul
unui sistem coerent de formulare şi/sau de procese informatice prin care se modelează şi
formalizează unu sistem informatic financiar bancar.
Metodele de proiectare se pot clasifica în trei mari categorii: metode structurate, metode
sistemice şi metode orientate obiect.
Metodele structurate sau ierarhice folosesc descompunerea progresivă descendentă top-
down. Concepţia constă în crearea unui ansamblu unitar în interacţiune, având fiecare o
funcţie clar definită.
Avantajele acestor metode constau în simplitatea şi buna adaptare la cerinţele utilizatorului.
Dezavantajele pornesc de la conceperea sistemelor informatice conform cerinţelor analizei
funcţionale, ceea ce determină un efort de analiză şi proiectare mai mare asupra prelucrărilor
în condiţiile în care acestea sunt cele mai supuse modificări în timp, iar modelarea datelor este
trecută în planul secund.
Cea mai reprezentativă dintre metode este SADT (Structured Analisys and Design Tehnique).
Metodele sistemice permit vizualizarea şi înţelegerea organizării datelor. Specific acestor
metode este utilizarea teoriei sistemelor în abordarea întreprinderii. Sistemul informatic este
abordat sub două aspecte complementare – datele şi prelucrările – analizate şi modelate
independent, reuniunea lor făcându-se cât mai târziu posibil.
Metodele sistemice acordă o mai mare importanţă datelor care trebuie să respecte următoarele
niveluri de abstractizare:
- Nivelul conceptual
- Nivelul logic

27
 - Nivelul fizic.

         
  are ca obiectiv identificarea regulilor de gestiune şi definirea modelului

conceptual al datelor şi prelucrărilor.
          urmăreşte validarea modelului conceptual al datelor şi evidenţierea
particularităţilor organizatorice.
          fixează reguli de ordin tehnic privitoare la sistemul informatic, definitivează
soluţia de implementare a modelului datelor şi definirea procedurilor.

MCD – modelul conceptual al datelor

MLD – modelul logic al datelor

DATELOR

MFD – modelul fizic al datelor Metodel

MODELUL
e
obiectua
MCP – modelul conceptual al prelucrărilor le a treia
generaţie
de
PRELUCRĂRILOR MLP – modelul logic al prelucrărilor
metode
de
MFP – modelul fizic al prelucrărilor proiectar
e.
Primele concepte apărute în 1980 privea tehnologia OO (orientate obiect). Caracteristic
acestor metode este faptul că sistemul informatic este gândit ca un ansamblu de obiecte
autonome care se organizează şi cooperează între ele. Datele şi prelucrările (metodele) se
găsesc încapsulate (inaccesibile celorlalte obiecte) în cadrul aceleiaşi structuri – obiectul.
Avantajele metodelor obiectuale sunt reutilizarea componentelor de program şi posibilitatea
utilizării obiectelor complexe.
Dezavantajele acestor metode decurg din aspectul că nu totdeauna realitatea poate fi
reprezentată prin obiecte.

28
11. MODELAREA CONCEPTUALĂ A DATELOR
Modelul Entitate-Asociere (EA)
Modelul conceptual al datelor este un ansamblu de concepte şi reguli de combinare a acestora
permiţând reprezentarea realităţii.
Modelul Entitate-Asociere (EA) urmăreşte obţinerea unei reprezentări fidele a realităţii.
Conceptele de bază utilizate de către modelul EA
ENTITATEA – reprezintă un obiect al realităţii modelate, caracterizat de o existenţă proprie,
cu o identitate proprie şi o mulţime de caracteristici care exprimă proprietăţile acestuia.
Ex. În gestiunea produselor finite putem defini entităţi ca: un produs, un bon de comandă, , o
comandă.
În activitatea de modelare interesul se focalizează pe definirea tipului de entităţi aparţinând
problemei de rezolvat şi nu pe entităţi care reprezintă realizările tipurilor de entităţi.
TIP DE ENTITATE – reprezintă un concept generic desemnând mulţimea tuturor entităţilor
prezentând aceleaşi caracteristici constructive.
Ex contract, depozit bancar, ordin de tranzacţionare.
ATRIBUTUL – defineşte o proprietate distinctă a unei entităţi. Fiecare atribut are un
domeniu, adică un set de valori posibile admise.
Clasificarea atributelor.
a) după complexitate
- elementare (simple) ale căror realizări nu mai pot fi descompuse
Ex. unitate monetară, numărul de cont
- decompozabile (complexe)
Ex data calendaristică se descompune în zi, lună, an
b) după realizări
- obligatorii: să prezinte obligatoriu o valoare NOT NULL
- opţionale: pot să nu aibă nici-o realizare Ex telefon, e-mail
- monovaloare: are o singură valoare în cadrul entităţii Ex. CNP, nr cont
- multivaloare: prezintă mai multe realizări în cadrul aceleiaşi entităţi Ex conturi la
bănci

Din punct de vedere al rolului pe care îl îndeplineşte acel atribut în cadrul modelului
distingem atribute cu rol de:
a. chei candidate – sunt acele atribute care prin natura lor sunt susceptibile de a juca
rolul de cheie primară sau de identificator în cadrul unui tip de entitate;

29
 b. cheie primară sau identificator – reprezintă acel atribut sau grup de atribute, care în
cadrul tipului de entitate reuşeşte, prin valorile pe care le ia, să scoată în evidenţă o anumită
entitate din mulţimea entităţilor care prezintă acelaşi comportament. Rezultă că o cerinţă
esenţială pentru valorile pe care le poate lua acest gen de atribut, este ca acestea să fie unice în
toată mulţimea valorilor pe care le poate lua acel atribut. Ex: atributul cod numeric personal,
prin valorile pe care le poate lua poate conduce la identificarea în mod unic a entităţii
Georgescu din mulţimea entităţilor care formează tipul de entitate Client;
c. cheie externă – reprezintă un atribut sau o multime de atribute definite pe aceiasi
multime de valori ca şi cheia primară, rolul său fiind acela de a putea stabili o asociere între
două sau mai multe tipuri de entităţi care în realitatea modelată, interacţionează între ele.
Atributul este perceput ca o variabilă care poate lua valori într-un anumit domeniu.
Putem spune că        reprezintă mulţimea tuturor valorilor posibile pe care le poate lua
un atribut într-o anumită perioadă de timp.
Câteva precizări cu privire la cheile candidate şi cheile primare sunt prezentate în cele
ce urmează. Să considerăm că în realitatea modelată putem identifica un tip de entitate numit
Societăţi comerciale. Mulţimea atributelor care definesc acest tip de entitate sunt Codul unic
de înregistrare, Numărul de înregistrare, Cod IBAN, Numele societăţii, Adresa societăţii.
Modul de reprezentare a acestui tip de entitate

Societăţi comerciale

Cod unic de înregistrare

Numărul de înregistrare
Cod IBAN
Numele societăţii
Adresa societăţii

MCD-ul care se realizează folosind conceptele prezentate reprezintă, în mod grafic-

schematic, modelul semantic, abstract, al domeniului de informatizat: organismul economic
sau compartimentul specializat al acestuia pentru care seproiectează sistemul informatic de
gestiune. Prin urmare, la realizarea acestuia se folosesc simbolurile grafice ale conceptelor de
bază, rolul fundamental în construirea acestuia revenind cuplului ET - AST.
Două cupluri ET - AST, formate din două ET diferite care participă la aceeaşi AST,
definesc un bloc conceptual elementar, care se notează sub forma ET - AST - ET. MCD-ul
construit pentru un domeniu de gestiune al unui organism economic este practic format dintr-

30
o succesiune de blocuri conceptuale elementare. Figura 5.2 prezintă schema unui bloc
conceptual elementar dintr-un MCD.

În modelul EA obiectelor le corespund entităţi. Obiectele sunt de mai multe feluri:

- obiecte simple cărora le corespund un tip de entitate
- obiecte compozite cu atribute multivaloare
- obiecte compuse ce sunt decompozabile dar au in structura lor tot atribute simple

31
Asocierea dintre entităţi arată legătura dintre acestea şi rolul entităţii participante la legătură.
Tipul de asociere reprezintă ansamblul legăturilor cu aceeaşi semnificaţie dintre entităţile
aparţinând la două sau mai multe tipuri de entităţi .

11. Relaţii sau asocieri între date

Prin natura a ceea ce reprezintă atributele interactionează, relaţionează între ele

formând un tot unitar numit entitate. Conceptul care descrie această relaţie între atribute
poartă denumirea de dependenţă functională.
                   reprezintă o proprietate a semnificaţiei sau a semanticii
atributelor, indicând modul în care sunt legate atributele unele de altele.
Numim                          o legătură stabilită între două atribute notate
A şi B apartinand unei relatii R, pentru fiecare valoare cunoscută a atributului A se
antrenează în mod sistematic asocierea aceleiaşi valori pentru atributul B.
Reprezentarea grafică pentru o astfel de dependenţă funcţională este simbolizată
printr-o săgeată având o orientare de la atributul A către atributul B.

32
 Un tip aparte de dependenta functionala o reprezinta        
  
     

 
        .
Fie atributele A, B, si C aflate intr-o relatie R, exista o dependenta functionala
multivaloare atunci cand pentru fiecare valoare a atributului A exista o multime de valori
pentru atributul B si o multime de valori pentru atributul C. Totusi, multimile de valori ale
atributelor B si C sunt independente unele de altele.
Vom reprezenta o dependenta functionala multivaloare printr-o săgeata dubla de la
determinant catre determinat

Legăturile sau asocierile care se stabilesc între mai multe tipuri de entităţi.
Într-o bază de date relaţionlă, datele sunt stocate în mai multe tabele, deci este
importnt ca sistemul să poată reuni corect informaţiile între care există legături. Astfel
relaţiile se constituie prin precizarea unei legături între un câmp sau o combinaţie de
câmpuri ale unui tabel şi câmpurile corespunzătoare din alt tabel.

                  

1.Relaţia unu-la-unu (one-to-one), se mai numeşte şi biunivocă. Două tabele unite

printr-o relaţie unu la unu sunt similare, în practică, cu un tabel care cuprinde toate câmpurile
celor două tabele.
2. Relaţia unu-la-mulţi (one-to-many). În practică acest tip de asociere este cel mai des
întâlnit. Într-o asociere de tipul unu-la-mulţi o înregistrare din tabelul A îi corespunde mai
multe înregistrări din tabelul B, iar unei înregisrări din tabelul B îi corespunde cel mult o
înregistrare din tabela A.
3. Relaţia mulţi-la-mulţi (many-to-many). Acest tip de relaţie are un caracter mai
general, unei înregistrări din tabelul A îi pot corespunde mai multe înregisrări din tabelul B,

33
iar unei înregistrări din tabelul B îi pot corespunde, de asemenea, mai multe înregistrări din
tabelul A.
În mod uzual reprezentarea grafică a unei asocieri între două tipuri de entităţi se simbolizează
printr-o elipsă în care se trece numele asocierii.

A B A B A B

a x a x a x
d b y b y
b y c z c z
e d t d t
c z e w e w

Asociere 1:1 Asociere 1:n Asociere m:n

Strâns legat de asocieri îl reprezintă conceptul de cardinalitate. Putem defini

cardinalitatea ca fiind un cuplu de numere întregi de forma (x,y), care exprimă numărul
minim (x) şi numarul maxim (y) de realizări ale unei instanţe (realizări) ale tipului de entitate
care participa la o asociere.
X se numeşte cardinalitate minimală, desemnând obligativitatea unei realizări de a
participa la o asociere, iar Y se numeşte cardinalitate maximală fiind percepută ca volumul
participării la asociere.

12. CARDINALITATEA

Cardinalilatea unui cuplu entitate-asociere se defineşte ca fiind cuplul de valori

întregi (x,y), astfel încât:
- x reprezintă cardinalitatea minimală şi exprimă numărul minim de realizări ale
legăturii (asocierii) ce există pentru o entitate.
- y reprezintă cardinalitatea maximală şi exprimă numărul maxim de apariţii ale
corespondenţei ce pot exista pentru o entitate.
Valorile uzuale sunt:
a) Cardinalitatea minimală 0, va putea exista în cazul în care există entităţi care să nu
participe la nici-o asociere. Exemplu există potenţiali clienţi ai unei firme cărora
încă nu li s-a încheiat poliţe de asigurare, deci cardinalitate minimală 0.

34
b) Cardinalitate minimală 1, va putea exista în cazul în care toate realizările tipului de
entitate trebuie să participe la o realizare a tipului de asociere. Exemplu orice
contribuabil aflat în evidenţa administraţiei financiare are deschis un rol şi numai
unul singur.

c) Cardinalitate maximală 1, arată faptul că toate entităţile participă la o asociere şi

numai la una. Exemplu numărul de roluri deschis unui contribuabil nu poate fi mai
mare de 1.
d) Cardinalitate maximală n, indică faptul că mai multe entităţi de un anumit tip
participă la o ascociere. Un client emite unul sau mai multe ordine de plată.

35
 Furnizori 1,n Furnizează 0, n Mat_prime

1,n 0,n
Clienţi Cumpără Produse
Cantit_cumpărat

13. Reguli de verificare a Modelului Conceptual al Datelor:

1. Unicitatea numelor – se aplică tuturor elementelor ce participă la definirea MCD: ET,
AST, AT, roluri: se elimină din model omonimele şi sinonimele. Ex.: un atribut tip şi o
entitate tip nu pot avea acelaşi nume Produs, entitatea tip o vom numi Produs iar atrib
Nume_produs
2. Unicitatea atributelor (neredondanţa) – AT trebuie să def o sg ET sau AST
3. Unicitatea asocierilor –fiecărei asocieri îi corespunde o sg. entitate a ET participante la
AST; o asociere nu poate exista decat o sg data intre aceleasi entitati;
4.Atributul tip al unei asocieri tip – este atributul determinat de mai mulţi determinanţi, ID
ai ET def de aceştia (caracterizează AST creată între ET definite de determinanţii săi)
5. Evitarea includerii în MCD a atributelor rezultate din calcule- prez ac tipuri de atribute
se justifică numai dacă sunt relevante şi frecvent utiliz; Ex: la app salarii e utilă def unei entit
tip ( Salarii) care are ca atrib tip calculate Salariul brut, Baza de calcul, Baza de
impozitare, Deduceri personale, necesare pt realiz lunară a stetelor de sal, a unor rap
statistice, întocmirea fişelor fiscale, elib de adeverinţe, etc.
6.Atributele decompozabile – se pot menţine în MCD dacă prelucrările nu impun desc lor pe
componente; Ex: atrib tip Adersa într-un Si pt. Administraţia Financiară se desc pe
componente deoarece contribuabilii sunt adesea select pe sect, străzi şi nr; în cazul unui Si pt.
secretariatul unei Fac ac atrib nu se desc pt că nu interesează componentele lui.
7. Identificatorii ET – trebuie să fie formaţi din nr. min de atribute, trebuie sa aiba val unice
si nenule

36
 8. Val NULL (NULL înseamnă nici o valoare/realizare/înregistrare, e dif de zero sau spaţiu):
- AT cu rol de ID sunt obligatorii ( trebuie să aibă val/realizări);
- există ET care au AT opţionale ( tel, eMail); în cadrul tipului de entit se pot def subtipuri de
entit care cuprind doar atrib tip specifice acelei submulţimi de entit;

14. Restricţii de integritate

Restricţiile de integritate definesc cerinţele pe care datele trebuie să le respecte pentru a fi
corecte şi coerente în raport cu realitatea de modelat.
Restricţiile de integritate surprind următoarele aspecte:
- valorile atributelor entităţii şi asocierile
- valorile identificatorilor entităţilor
- rolurile entităţilor în asocieri
- asocierile stabilite între entităţi
Restricţiile de integritate pot fi
- statice (se verifică permanent)
- dinamice (privesc evoluţia în timp a datelor)
Exemple de restricţii:
•   
             (condiţiile valorile admise ale atributelor în cadrul domeniului)
Exemplu Unitatea Măsura – KG, BUC
•   
     

    ( implica două aspecte a)identificarea entităţilor, b) tipul de
entitate prezentă
•   
        
   

       

•   
        
   

         

15. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR (MCP)

Prelucrările reprezintă partea dinamică a sistemului informaţional.
Pentru modelarea conceptuală, abstractă, a prelucrărilor se foloseşte un model semantic de
reprezentare a prelucrărilor. Acest model se bazează pe semnificaţia acestora în lumea reală.
Întrebarea la care trebuie să răspundă sistemul informatic economic este CE ? prelucrări au
loc pentru a descrie corect şi complet ceea ce face sistemul vis-a-vis de obiectivul economic
propus.
Modelul conceptual al prelucrărilor prezintă:
- activităţile desfăşurate de sistemul economic pentru realizarea obiectivului propus
- evenimentele şi succesiunea lor de declanşare a acestora

37
 - operaţiile pe care le presupune fiecare dintre activităţile desfăşurate şi înlănţuirea lor
în timp
- sincronizarea timpului cu legislaţia şi regulile în vigoare
- rezultatele obţinute în urma execuţiei operaţiilor

Modelul conceptual al prelucrarilor este modelul "eveniment-rezultat" al metodei Merise, ce

repune in discutie procedurile (elementele) abordate de MCD formuland pentru fiecare
element intrebari de forma:

- acest element este indispensabil si ce se intampla daca il suprimam;

- exista posibilitatea de a-l suprima (atentie la normele juridice si reglemantarile legale;
- cat costa mentinerea acestui elemet in procedura sau ce avantaje se obtin din mentinerea lui.

Modelul conceptual al prelucrarilor, vede Cerere de

intreaga prelucarare ca o succesiune ordonata si logica credit
de proceduri inlantiute, toate in concordanta stricta cu
legislatia in vigoare (este vorba de un demers tipic de
analiza a valorilor).

Operati
Nu se poate trece cu vederea impactul utilizarii
a
instrumentului informatic (SGBD) asupra MCP. Astfel, Reguli de emisiune
anumite validari pot fi efectuate inca de la culegerea
datelor, in loc sa se constate ulterior ca datele sunt
complete sau eronate, deci anumite operatii din MCP
pot fi eliminate. Credit
acordat
Concepte de baza

Ca si în cazul modelului conceptual al datelor,

A si B
formalismul modelelor de prelucrare se bazeaza pe
construirea unei diagrame având trei elemente de baza:

a) evenimentul declansator, reprezentat grafic printr-o elipsa, de la care pleaca o

sageata de legatura pentru simplificare, daca este necesar, elipsa poate fi omisa

38
 b) operatia, reprezentata grafic printr-un dreptunghi ;
c) rezultatul (evenimentul emis), reprezentat tot printr-o elipsa
d) sincronizarea, reprezentata grafic printr-un triunghi orientat catre operatie.

Evenimentul declansator

Desemneaza un fapt a carui aparitie declanseaza o reactie în cadrul organizatiei;

aparitia unui eveniment va antrena derularea de activitati, de operatii, reprezentând
“motorul” unei actiuni, al unei operatii ( de ex. sosirea unui document).
Pentru ca MCP sa fie cât mai stabil, el trebuie sa fie independent de aspectele
organizatorice si tehnologice, chiar geografice.
De ex. Sosirea unei comenzi de la un client este un eveniment declansator, de
natura extern. A satisface aceasta cerere înseamna a o transforma într-o livrare de
produse. Descrierea continutului prelucrarilor necesare trebuie sa fie independenta de:

 aspectele tehnologice (se utilizeaza calculatorul sau nu ?)

 aspectele “geografice” (comanda este prelucrata la depozit sau în
alta parte ?)
 aspecte organizatorice (livrarea este facuta de X la serviciul
comercial sau de Y la magazie ?)
 aspecte temporale (livrarea se face dimineata sau seara ?).
Tip eveniment

Este un concept generic descriind toate aparitiile

evenimentelor de aceeasi natura. Capacitatea sistemului de a
percepe aceste aparitii este exprimata de doi parametri :
   

  indica numarul maxim de aparitii ale acestui tip de eveniment care pot fi
percepute de sistem si
     
 indica legea de manifestare a acestor aparitii.

Categorii de evenimente

Un eveniment poate fi :

39
  extern (receptionat din exterior) : primirea unui CEC, a unui aviz
de plata, solicitarea unui credit, etc.

 intern (generat de activitatea sistemului întreprindere) : pana unei

masini, gasirea unei solutii, etc.

  
              

          
    
    
 

- sa se întâmple ceva (în afara sau în interiorul întreprinderii)

- acest ceva trebuie sa fie perceput de sistem (care trebuie sa fie
dotat cu mijloace capabile sa îl perceapa) - întreprinderea sa fie interesata, vazând în el
un posibil eveniment declansator al activitatii sale.

Operatia

Se numeste operatie orice actiune (sau secventa continua de actiuni),

producatoare de evenimente rezultat, care se executa fara întrerupere, ca reactie la un
eveniment declansator (sau a mai multor evenimente declansatoare sincrone). O
operatie constituie un bloc neîntrerupt (nu trebuie sa apara rezultate intermediare în
interiorul unei operatii).
Tip de operatie

O categorie de operatii ce prezinta aceleasi caracteristici. Un anumit numar de

parametri caracteristici permit specificarea unui anumit tip de operatie:

- desemnarea operatiei însasi;

- durata exprimata în unitati de timp
- actiunile elementare constitutive
- evenimentele emise si conditiile de emitere.

O operatie se finalizeaza întotdeauna prin emiterea de evenimente functie de

situatiile identificate pe parcurs si de conditiile exprimate de aceste situatii (asa-numitele
reguli de emisiune).

40
       O operatie se desfasoara în timp, având o anumita durata. La un
moment dat ea poate fi :

- în asteptarea executiei;
- în curs de executie si
- terminata.
cod Denumire
operatie operatie
Actiune ( Actiuni)
Reguli de emisiune

Rvenimente emise - rezultate

Rezultatul (evenimentul emis) .

Numim rezultat produsul executarii unei operatii. Întotdeauna trebuie respectata

urmatoarea regula: o operatie produce unul sau mai multe rezultate. Descompunerea
unei operatii în mai multe operatii distincte implica aparitia unor rezultate
intermediare. Un eveniment emis poate fi în acelasi timp un eveniment declansator
pentru o alta operatie ( sau alte operatii). De aceea se si utilizeaza acelasi formalism.
Reguli de obtinere a rezultatului

În MCP toate operatiile trebuie sa aiba rezultat. În anumite cazuri obtinerea

unuia sau mai multor rezultate poate fi supusa îndeplinirii anumitor conditii. În aceasta
situatie este necesar sa fie definite, formulate asa numitele reguli de emisiune sau reguli
de actiune. (vezi fig. de mai sus).
Exemple :

41
- Relatia date-rezultate este supusa anumitor conditii logice : daca valoarea facturata
este mai mare de 1 milion, atunci se acorda o remiza de 1o%, daca nu, se acorda un
scont de 2%.
- Lansarea unei livrari poate fi diferita daca stocul este insuficient. În acest caz comanda
este plasata în asteptare (nu se întocmeste dispozitie de livrare). Conditia “stoc
suficient” defineste o regula de emisiune a rezultatului cu doua cazuri diferite (“stoc
suficint”; “stoc insuficient”).
Reprezentarea regulilor de emisiune

Conform figurii de mai jos, diferitele reguli de emisiune sunt reprezentate

în partea inferioara a dreptunghiului ce descrie operatia.
Reprezentarea este analoga unei formulari de genul :
Daca              

atunci Rezultat A si Rezultat B

altfel (               

Rezultat B si Rezultat C

Operatie
Regula de Regula de
emisiune 1 emisiune 2

A B C

Sincronizarea

În anumite cazuri, declansarea unei operatii poate solicita producerea simultana

a mai multor evenimente. Cu alte cuvinte, o anumita operatie nu poate avea loc decât
daca sunt îndeplinite anumite conditii privind manifestarea evenimentelor ce concura la
declansarea operatiei respective. Expresia acestor conditii se numeste sincronizare.

Principiul sincronizarii

42
 Sincronizarea exprima sub forma unei propozitii logice faptul ca operatia poate fi
declansata sau nu. Ea se exprima printr-o expresie booleana ce leaga evenimentele ce
declanseaza operatia.
Modul de functionare

Daca E1, E2 si E3 sunt evenimente declansatoare pentru operatia Oi si daca a, b,

c sunt aparitii corespunzatoare evenimentelor E1, E2 sI respectiv E3, atunci
sincronizarea :

a si ( b sau c) , adica a ∧ ( b ∨ c)

indica faptul ca operatia Oi este declansata daca o aparitie a evenimentului E1 exista

simultan cu una din aparitiile evenimentelor E2 sau E3.
Sincronizarea se exprima deci sub forma unei propozitii logice care trebuie sa respecte
anumite reguli, dintre care cele mai importante sunt:

- conditia trebuie pusa pe evenimentele participative conjugate si

- trebuie sa existe situatii care permit declansarea.

Conceptul de sincronizare exprima o logica si o dinamica a prelucrarilor. La un

moment dat, propozitia logica poate fi verificata. Atunci sincronizarea este activa si
operatia este declansata. La un alt moment este posibil ca un singur eveniment
declansator sa fie realizat; în acest caz sincronizarea este în asteptarea realizarii altor
evenimente care sa declanseze operatia. Daca nici un eveniment nu are loc,
sincronizarea este inactiva.

43
 Evenimentul A Evenimentul B Sfarsit
operatie

Timp
t1 t2 t3

Sincronizare Sincronizare
in asteptare activa (operatie Sincronizare
Sincronizare
declansata) inactiva
inactiva

Exemplu

Vom considera ca exemplificare procedura de acordare a unui credit.

Utilizând formalismul de mai sus vom defini modelul din figura 1.

                   
   

           
              
  
 

                                            
   


44
 Cerere
de credit

OP 1 Instruire formala

c1 c2 c3

Scrisoare Dosar Informatii

de refuz deschiz suplimentare

Analiza
OP 2 solvabilitatii

c4 c5

Credit Credit
refuzat acordat

Comentarii la figura 1

O data cu primirea cererii de credit (eveniment) , are loc o operatie de instruire

formala a deschiderii unui dosar de creditare care se finalizeaza dupa caz (functie de
regulile de emisiune care au valorile c1 si respectiv c2 si c3) printr-un refuz (cerere
nerezolvabila), prin deschiderea efectiva a unui dosar de creditare si în sfârsit, printr-o
cerere de informare suplimentara.
c1 : nu exista plafon de credite

45
c2 : exista plafon de credite pe termen scurt c3 : exista plafon de credite pe
termen lung

Acest dosar face sistematic obiectul unei operatii de instruire, care, functie de
solvabilitatea clientului (c4 - client nesolvabil sau C5 - client solvabil) se finalizeaza
printr-o respingere sau acceptare a dosarului.
Notiunea de “Proces”

Un proces descrie dinamica prelucrarilor dintr-o activitate determinata. El este

format din operatii executate ca reactie la evenimente si producând rezultate.

Un proces este:

-       operatiile si rezultatele concura la o finalitate comuna.

-    

are granite marcate de evenimentele de origine si de rezultatele
terminale.
Etapele elaborarii unui proces.

Procesul este MCP ce corespunde unui domeniu de activitate. El este

construit printr-un demers metodologic de modelare (analiza, abstractizare,
conceptie), ce cuprinde urmatoarele etape:
1.      
       
    
  



În cadrul acestei etape trebuie precizate granitele domeniului

de care sunt legate activitatile care intereseaza.
2.    
                          
 

Aici trebuie revazute principalele evenimente externe si interne ale

procesului; acestea sunt elemente cheie în realizarea modelului.
3.   
    
             
    

 

Acest tablou permite definirea continutului procesului , precizând

pe coloane, evenimentele, actiunile induse si rezultatele.
4.    
                      
     

Tabloul evenimente-rezultate, în coloana centrala, permite deja identificare

actiunilor induse de evenimentele declansatoare. O analiza mai complecta a

46
contextului permite relevarea regulilor de gestiune, care sunt adesea elemente ale
operatiilor.
5.                        .
Aparent, mai multe evenimente distincte pot sa declanseze aceeasi
operatie. O data stabilite aceste elemente se poate construi schema de baza
pentru fiecare operatie. Aceasta schema se numeste bloc
operatie.
             
        
         

    

Se cauta, printre regulile de gestiune, acelea care definesc conditii

de obtinere a rezultatelor. Se completeaza apoi schema de baza cu
elementele respective.
7.
                    
  .
Structura generala a procesului decurge din cronologia
evenimentelor. Deci evenimentele trebuie ordonate cronologic. Acest
fapt permite ordonarea diferitelor blocuri-operatie si legarea lor conform
principiului : un rezultat ( al operatiei n-1) declanseaza operatia urmatoare
(operatia n).
8.


                           

Se verifica daca:
- orice operatie duce la cel putin un rezultat;
- orice operatie este declansata de cel putin un eveniment;
- toate blocurile sunt legate.
Validarea modelului se face de catre persoanele implicate în proces. Numai ele
pot judeca pertinenta modelului propus.
Exemplu.

   

Domeniul care ne intereseaza este gestiunea clientilor privind comenzile pentru

produse de panificatie (figura 2). Deci nu vor fi luate în considerare nici actualizarea
stocurilor, nici activitatile contabile, întrucât nu apartin strict de gestiunea clientilor.

   

Pot fi identificate în principal:

trei evenimente externe :

47
 1. Sosirea unei comenzi de la un client.
2. Existenta unui mijloc de transport disponibil în care sa se încarce
marfa.
3. Sfârsitul zilei;
trei evenimente interne:
1. Acceptarea comenzii.
2. Decizia de livrare.
3. Sfârsitul activitatii de livrare.

    Tabloul evenimente -rezultate

Evenimente Actiuni induse Rezultate

1. Sosirea Controleaza identitatea Comanda acceptata
comenzii de la si pretul sau nu
client
2. Existenta unui Efectueaza livrarea Livrare efectuata
mijloc de transport
disponibil
3. Sfârsitul zilei Examineaza comenzile Comanda de
în asteptare fabricatie
1.Acceptarea Consultarea stocurilor Comanda livrabila
comenzii de produse sau nu
2.Decizie de Pregatirea livrarii Marfa gata de
livrare plecare
3. Sfârsitul Expedierea marfii si Livrare expediata
activitatii de pregatirea facturii Factura
livrare
4. Comanda în Examinarea Comanda de
asteptare comenzilor în asteptare fabricatie

48

   

Se regasesc 6 operatii si anume:

OP 1 - Controleaza identitate client si pret;

OP 2 -Examineaza stoc
OP 3 - Pregateste livrarea
OP 4 - Factureaza
OP 5 - Expediaza marfa
OP 6 - Examineaza comenzile în asteptare

Obs. Au fost retinute doar aspectele conceptuale, eliminându-se operatiile de tip

organizational sau tehnic.

49
 Sosirea
comenzii

OP1 Controlea
za
identitate
N D

Coman Comand
da a

Op Examineaza
Sufucue Insufucue

Comand Comanda Sfarsitul zilei

a in
a b
Pregatir A si B
OP
ea
Examinea
Livrar Mijloc OP
za
e de comenzi
c d
C si
OP Factura Comanda
de
OP Expediaza
Factu Catre alt
proces
Livrare
efectuata

  

Vom exemplifica lucrul din aceasta etapa doar pentru un singur bloc operatie, si
anume cel corespunzator operatiei 2 (“efectueaza livrarea”).

50
 Livrare pregatita Mijloc de transport

a
b

A si b

Efectueaza
OP 5 livrarea

Livrare
efectuata

   

Putem avea de ex. urmatoarele reguli de gestiune:

a) “daca comanda este acceptata”. Aceasta regula defineste
controlul de identitate si pret si conditioneaza rezultatul (comanda acceptata ,
respectiv refuzata);
b) “daca stocul este suficient”, regula asemanatoare
referitoare la marimea stocurilor.

   

Schema procesului este prezentata în figura 2.

  


Se constata în figura de mai sus ca sunt îndeplinite regulile de modelare în

sensul ca orice operatie este declansata de cel putin un eveniment sI fiecare
operatie are cel putin un rezultat (eveniment emis)
Descrierea detaliata a procesului

51
 Schema procesului prezentata în figura 3 permite o perceptie rapida a
ansamblului prelucrarilor. Daca se doreste însa o prezentare mai detaliata atunci este
recomandat ca aceasta detaliere sa se faca la nivel de bloc operatie, fara sa mai urmeze o
înlantuire a blocurilor detaliate, întrucât o schema detaliata a procesului ar fi greu de
urmarit, de perceput. În acest caz se utilizeaza pentru eveniment urmatorul formalism.
Descrierea detaliata a blocului corespunzator operatiei “examinarea comenzilor în
asteptare” este prezentata în continuare :

Nume
eveniment
Nr max de Termen
aparitii limita

Aceasta maniera de abordare aduce complemente asupra restrictiilor de timp si volum.

Schema poate fi completata cu descrierea continutului operatiei, dar de aceasta data sub
forma de “fisa a operatiei”, al carei continut este prezentat în continuare

52
 Comanda
in asteptare

20 1 zi Sfarsitul
zilei
a b
a si b

OP 6 Examinarea
comenzilor in
asteptare

Cerere de
fabricatie

30 1 zi

Descrierea operatiei Denumire: Examinarea comenzilor în asteptare

Numar : 6
Proces : Gestiunea clientilor
________________________________________________________________

Mod de sincronizare

- la sfârsitul zilei (ora 17)

- pentru toate comenzile în asteptare
________________________________________________________________

Descrierea regulilor de gestiune

53
R1. Pentru fiecare produs:
- daca totalul cerut este mai mic decât cantitatea din stoc
solicitati livrarea;
- daca nu, cereti fabricarea.
R2. Comenzile de fabricatie sunt emise cel mai târziu a doua zi dupa examinarea
comenzilor.
________________________________________________________

Descrierea regulilor de emisiune

R1. Starea cererilor de fabricatie

Astfel de scheme trebuie elaborate pentru fiecare operatie. Se aplica aici
principiul cunoscut al ierarhizarii, mergând de la general (schema procesului) catre
particular (descrierea operatiei).
Revenind la reprezentarea grafica de mai sus putem afirma ca parametri exprimând
dinamica procesului puneau restrictii doar la nivelul “nodurilor” si anume:

- la nivelul sincronizarii (propozitia logica, durata limita) si

- la nivelul operatiilor pentru emisiunea de rezultate (reguli de emisiune care
orienteaza fluxurile catre o cale sau alta).

Acesti parametri pot fi completati cu altii plasati pe sagetile de legatura, în

amonte si în aval de operatie. Astfel vom avea ca parametri suplimentari:

- participarea si durata limita (pe sageata eveniment -->

sincronizare) si
- cardinalitatea (pe arcul operatie --> rezultat)
Participare si durata limita (reglarea în amonte)

Uneori sincronizarea, pentru a fi activata, are nevoie de existenta unui “lot” de

aparitii ale evenimentului declansator. Acest numar constituie participarea tipului de
eveniment la tipul de sincronizare. Timpul de activabilitate a acestui lot se numeste
durata limita.

54
 Cardinalitatea evenimentelor (reglarea în aval)

Operatiile emit rezultate (evenimente emise). Uneori este posibil ca acestea sa fie
emise în mai multe exemplare identice. Numarul de exemplare exprima cardinalitatea
tipului de eveniment rezultat al operatiei.

16. Validarea modelelor

Modelele externe ale datelor

Fiecare prelucrare are propriul/propriile sale modele externe (subscheme) de date ≡

MCD construit prin prisma unei singure prelucrari. MED se construieste independent
de MCD.

prel MED1
Realitate modelare MCD

prel MED2

O prelucrare are ME distincte pentru fiecare consultare si pentru fiecare actualizare.

Atât pentru consultare cât si pentru actualizare, ME se construiesc pe baza blocurilor
logice de date corespunzatoare.


          
 fluxurile de date vehiculate de o anumita prelucare.

      
      
                          

             
  

  

  
 

     
           
          
           
       

      

  

 

55
 e1 e2 BLD E1 E2

e3 e4 BLD E3 E4

Reguli pentru construirea ME

1) Un ME pentru fiecare consultare sau actulaizare efectuata de o

prelucrare. 2) Fiecare ME se construieste pe baza BLD folosind formalismul
EA.
3) Entitatile din ME pot sa nu aiba identificatori.
4) Atributele, entitatile si asocierile externe pot sa nu fie atribute, entitati
sau asocieri conceptuale. 5) Atributele externe echivalente atributelor
conceptuale trebuie sa aiba acelasi nume.
Ex: modele externe pentru OP1
consultare : verificare identitate client

56
 NUME
DenClient
1,n

CORESP

1,1
CLIENT
CodClient
AdresaClient
Cod fiscal
Star
e
actualizare: acceptare comanda de la client

57
 COMANDA
Nr
Data
comandac-da
De clien
nAdresa-
t
Val-
livr
totala 1,n

CUPRIND
E

1,1
LINIE-COMANDA
Cod
Den
produs
UM
produs
Cantitate c-data
Pret vânz
Valoar
e
Principiul validarii modelelor

Fiecare model extern trebuie sa fie deductibil din MCD

Model extern

calcul echivalenta

Model conceptual

58
 CLIENT PRODU
S produs
Cod
CodClient
Den produs
DenClient U
AdresaClient P
Mret vânz
CodFiscal
Stare
0,n
0,n

TRANSMITE PRODUS-C-
DAT
Cantitate c-data

COMAND
1,1 A comanda
Nr 1,n
Data c-da

corespondenta directa:                   


  
 ...



-calcul:


       


  
   
  

∑
 

 

        

-echivalenta:          ≡         

17. Reguli de validare în consultare

Atributele externe trebuie sa fie atribute conceptuale.

Daca nu:
- omisiuni ⇒ se completeaza MCD;
- date calculate ⇒ se înlocuieste în ME cu atributele conceptuale necesare calcularii sale;
daca acestea nu apar în totalitate în MCD, se adauga;
- date ce nu trebuie memorate ⇒ se elimina din ME, urmând sa fie tastate direct
Trebuie sa existe posibilitatea de-a avea acces la date în structura necesara

59
 Accesul poate fi facut:
- pe baza identificatorului;
- prin parcurgerea entitatilor sau asocierilor, una câte una
⇒ se verifica existenta criteriilor de selectie necesare si se compeleteaza
MCD daca este nevoie.

Daca se fac consultari pentru care criteriul de acces nu este identificatorul,

se adauga în MCD o noua entitate al carei identificator este acest criteriu de acces si
asocierea necesara pentru consultare (cai de acces impuse de utilizare si nu de DF).

Cardinalitatile asocierilor externe trebuie sa fie incluse în cardinalitatile

asocierilor conceptuale ce le corespund semantic.

18. Reguli de validare în actualizare

Orice atribut extern trebuie sa serveasca fie la identificarea elementului

conceptual de actualizat fie la obtinerea valorii de adaugat sau de modificat a unui
atribut conceptual:
-se suprima atributele externe care nu servesc nici unuia din
scopurile amintite;
-se adauga cele absente.

Cardinalitatile asocierilor externe trebuie sa fie incluse în cardinalitatile

asocierilor conceptuale ce le corespund semantic.

Orice atribut conceptual trebuie sa poata fi inserat (modificat sau sters)

prin cel putin un model extern. Daca nu, se adauga modelele externe adecvate.
Ex: entitati si asocieri inserate prin ME   
                

60
 CLIEN PRODU
T S
Cod
CodClien
produs
Den
tDenClien
produs
U
AdresaClien
t M
Pret
tCodFisca vânz
lStar
e
0,
0,
n
n
TRANSMITE
PRODUS-C-
DAT
Cantitate c-
data
COMAND
1, A 1,
Nr
1 n
comanda
Data c-
da
Trebuie adaugate MCP si ME corespunzatoare pentru actualizarea produselor si
clientilor.

19. Modelarea logica a datelor

         

                  
                       
        
      

    
   
               

      
        
    
        
   

  
     
       
     

61
 Expresia MCD în termenii unui anumit tip de solutie informatica
constituie modelul logic al datelor (MLD).
Deoarece aplicatiile informatice de gestiune se caracterizeaza prin stocarea
si prelucrarea relativ simpla a unor volume mari sau foarte mari de date, tipurile de
solutii luate în considerare vizeaza modalitatile de gestionare a datelor pe suporturile de
memorie externa.
COMAND PROD-C-
CUPRINDE
ANr 1, 1, DAT
comanda n 1
Data Cant
comanda 0, comandata
1,
1
SE-REFERA-LA
CORESPUNDE

0,
n
0, PRODU
n
FACTUR PROD- S
Cod
1, 0,
A FACTURAT Den
produs
Nr n Cantitate n U
Data
factura Pret
facturata
M
factura unitar

Modelul relational

Domeniu: o multime de elemente de tip similar.

Exemple:

62
 NUME ZILE ORARE

Atribut:
- o submultime a unui domeniu careia i s-a atribuit un nume. Numele
exprima rolul sau semnificatia atribuite elementelor domeniului respectiv.
Ex:
- pentru domeniul
    , pot fi definite atributele       
       ,       

  
  
  ,       
     

Aeroport origine Aeroport destinatie Escala

Bucuresti Arad
Bucuresti Barcelona
Paris Bucuresti Timisoara

Relatie: o multime

R = {(a1,a2,..,an):(a1 ∈ A1, a2 ∈ A2, ...an ∈ An) ∧ P(a1,a2,...an) = adevarat}

unde A1,A2...An sunt domenii.

Ex 1: A1: domeniul compozitorilor; A2: domeniul simfoniilor;

63


P(a1,a2) =   

             .
P(Beethoven,Eroica)=       
;
P(Vivaldi,Simfonia fantastica)=     .
Ex 2:
personal(MARCA,NUME,PRENUME,DATA-NASTERII)
daca (m,n,p,d) ∈ personal
atunci o persoana cu marca (m), numele (n), prenumele (p) este nascuta la data (d).

Relatiile se reprezinta grafic sub forma de tabele, în care se disting:

•         
   : numarul de atribute utilizate

•        

     
   : numarul de tupluri (linii în tabel).
Cardinalitatea unei relatii este variabila în timp datorita operatiilor de actualizare care
pot adauga sau sterge tupluri.

Pentru o relatie pot exista 3 tipuri de chei:

• cheie primara: cel mai mic ansamblu de atribute (eventual
unul singur) care permite identificarea fara univoc al fiecarui tuplu al
unei relatii; atributele care compun cheia primara nu pot
avea valori nule.
• cheie candidat: o alta posibila cheie primara, care nu a
fost însa retinuta ca atare.
• cheie externa: un ansamblu de atribute (eventual unul
singur) care  
          

   
    
  .

Restrictie de integritate referentiala:

daca între un atribut A si o cheie primara B exista o RIR atunci A nu
poate lua decât valori care exista si în B. Prin definitie, cheile externe sunt
supuse RIR în raport cu cheile primare corespunzatoare.

64
 Gra
Atribut
d e
MARC NUM PRENUM DATA
A 12 PE opesc E Vasil NAST
22/10/6
512 u
Popesc eAdrian 817/5/6
833 u
C o ste aIo 58/12/6
641 aIonesc n
Ma r i 330/4/6
7 u a 4
Cardinalitat Tupl
e u

20. Trecerea de la MCD la MLD relational

a. ENTITATI
Fiecare entitate devine o relatie.
Atributele entitatii devin atribute ale relatiei.
Identificatorul entitatii devine cheia primara a relatiei.

65
 E
Ae11
A
1 e1
.2.
.
E1 Ae1 ,Ae12,
( 1 ...)
b. ASOCIERI
b.1 Cazul general

1) Asocierea devine o relatie.

2) Atributele proprii ale asocierii (daca exista) devin atribute ale
relatiei.
3) Cheile primare ale entitatilor participante la asociere devin chei
externe.
4) Identificatorul asocierii devine cheia primara a relatiei.

_,n _,n
Ae11 ASO Ae21
Ae12 CA1 Ae22
... ...

ASOC Ae11 ,A1

( ,Ae21 )
E1( Ae11 ,Ae12, ...)

E2( Ae21 ,Ae22, ...)

66
 Ex 1 :

STUDENT EXAMEN DISCIPLINA

1,n 0,n
Nr matricol Data examen Cod discipl
Nume sustine Nota cursant Nume discipl
Prenume

STUDENT(Nr matricol, Nume, Prenume)

DISCIPLINA(Cod disciplina, Nume disciplina)

EXAMEN(    
    *,            *, Data examen, Nota)

Ex : 2
STRUCTURA
-FABRICATI
ECantitate
nec
compus- component-
din ARTICO in
0, L
Cod 0,
n Den
articol n
Tip
articol
U
articol

ARTICOL(Cod articol, Den articol, Tip articol, UM)

STRUCT-FABRICATIE(    
           
         


Cantitate necesara)
b.2. Asocieri binare având cel putin o cardinalitate maximala 1.

67
Se adauga la atributele relatiei corespunzatoare entitatii cu cardinalitatea maximala 1
identificatorul celeilalte entitati (cheia primara a relatiei corespunzatoare acesteia), care
devine cheie externa.
Daca asocierea are atribute proprii, acestea se adauga la rândul lor relatiei care
reprezinta entitatea cu cardinalitate maximala 1.

E E
_,1 _,n
1 ASO 2
Ae11 Ae21
Ae12 C A1 Ae22
... ...

E1 Ae1 ,
( 1 Ae12,...,Ae21,A1)
E2 Ae2 ,Ae22,...
( 1 )

Ex 1

ANGAJA COMPARTIMEN
T
Marc LUCREAZ T
Num 1, 0, Cod
ã A
Data
Prenum
e 1
lucreaza- loc- n compartiment
încadrãrii Den
Data
e la munca
Salariul compartiment
nasterii
lunar

COMPARTIMENT(Cod compartiment, Den compartiment)

ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar, Cod compartiment*, Data

încadrarii)

68
 Ex 2
0,n FILIATIE
1,1

tat copil
a

PERSOAN
Ã
Cod
persoanã
Num
e
Prenum
e
Data
nasterii
Se
x
PERSOANA(Cod persoana, Nume, Prenume, Data nasterii, Sex,          


 *)
c. SUBTIPURI DE ENTITATI (Generalizarea/specializarea)

c.1. Reprezentarea simpla a legaturilor dintre tip si subtip

Se aplica regulile de la b.2. conform urmatoarei schemei generale:

Entitat Entitat
e e

≡ 0,
0,

Subti Subti
p p 1,
1,
Subti Subti
p p

c.2. Reprezentarea mostenirii

69
 Reprezentarea mostenirii ca proces de transfer al proprietatilor generice ale
tipului spre subtipuri nu beneficiaza de o solutie relationala dedicata. Din aceasta cauza,
este necesar sa se recurga la defactorizarea proprietatilor comune.

a)                          : tipul de entitate generica dispare

iar atributele sunt adagate la fiecare dintre subtipuri.
BUN-
proprietat IMOBILIAR
Nr bun
1, Adres
1 Suprafat
a
POSED
A #
DE- DE-
VANZARE INCHIRIAT
Chirie
proprieta 1, Pret
n Avans
lunara
r Star
solicitat
CLIEN Durata
minimal
T minima
Nr
Nume
Adresa
client
No
telefon
BUN-DE-VANZARE( Nr bun , Adresa, Suprafata, Pret solicitat, Stare, Nr
Client)
BUN-DE-INCHIRIAT( Nr , Adresa, Suprafata,
bun Chirie lunara, Avans minimal, Durata minima, Nr
Client)

b)                           :

• tipul de entitate generica preia si atributele specializate care, în

functie de subtipul reprezentat, primesc valori nule.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Pret solicitat, Stare,

Chirie lunara, Avans minimal, Durata minima, Nr client*)
• atât tipul cât si subtipurile sunt conservate ca atare.

70
 BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Nr client*)

BUN-DE-VÂNZARE(Nr bun vânzare, Pret solicitat, Stare)

BUN-DE-ÎNCHIRIAT(Nr bun inchiriat, Chirie lunara, Avans

minimal, Durata minima)

          si          
trebuie sa respecte restrictiile de

integritate referentiala în raport cu     .

71