Carte PSI - Capitol Merise PT Studenti Oct 2014

Proiectarea sistemelor informatice
1 Conceperea unui sistem informaional

financiar-monetar utiliznd metoda Merise
Merise este o metod de proiectare sistemic, dezvoltat
n Frana n anii 80. Metoda are o structur matriceal,
fiind de forma:
Nivele
Conceptual
Logic
Fizic
Viziuni
Date
MCD
MLD
MFD
Comunicaii
MCC
MLC
MFC
1.1 Obiectivele S.I.F.M.
Prelucrri
MCP
MLP
MFP
Obiectivele sistemului informatic reprezint scopuri

imediate i de perspectiv privind perfecionarea activitii
n general, precum i conducerea activitii n vederea
ridicrii nivelului de informare operativ i previzional a
structurilor organizatorice, a perfecionrii metodelor i
proceselor tehnico-informaionale i de conducere pentru a
asigura o eficien maxim a unitii bancare beneficiare.
Obiectivele sistemului informatic presupun abordarea i
rezolvarea informatic a unor probleme cu caracter
sintetic, ntr-o manier sistematic. Aceste obiective au
caracteristici generale i specifice care depind de cadrul
legislativ-normativ, dotarea cu tehnic de calcul i cerinele
dezvoltrii economice, imediate i de perspectiv, ale
unitii bancare n cauz.
Aceste obiective se pot grupa n urmtoarele categorii:
1 Subcapitol publicat parial n [FRAT98]
obiective de conducere, care urmresc restabilirea

permanent a activelor economice, perfecionarea
activitii de conducere n vederea asigurrii unui
optim global al ntregii activiti, fundamentarea
deciziilor de conducere, tactica strategic i operativ
pe baza informaiilor obinute ca urmare a
prelucrrilor
sistemului
informatic,
degrevarea
conducerii de procesele decizionale de rutin;
obiective funcionale, fundamental dependente de
specificul activitii bancare.
SIFM are obiective manageriale i funcionale pentru
urmtoarele activiti principale:
deschiderea de conturi bancare;
constituirea i actualizarea depozitelor bancare;
pli i decontri n lei sau valut;
acordarea i rambursarea creditelor bancare;
nchiderea unei zi de activitate bancar.
Intrrile i ieirile SIFM
Pentru fiecare tip de activitate i obiectiv managerial sau

funcional se identific, ieirile i intrrile folosite de
sistemul SIFM.
n acest scop se iau in calcul diferite criterii [FRAT95-2]:
specificul societii financair-monetare;
cerinele informaionale ale conducerii instituiei,
ale compartimentelor sale funcionale;
obiectivele manageriale i funcionale ale SIFM;
cadrul
legislativ
n
materie,
reglementrile
elaborate de Ministerul Finanelor Publice;
necesitatea msurrii amplitudinii i dinamicii
fenomenelor financiar-monetare.
n principiu, intrrile i ieirile standard ale unui SIFM

sunt stabilite i n funcie de specificaiile din MCC, fiind
folosite pentru determinarea tipurilor de entiti, relaii i
atribute din MCD.
Intrrile SIFM sunt reflectate prin intermediul
documentelor de intrare, n timp ce ieirile SIFM sunt
redate sub forma rapoartelor de ieire.
1.2 Modelarea conceptual

1.2.1 Modelarea conceptual a comunicaiilor (MCC)
MCC realizeaz o reprezentare grafic a procesului

supus informatizrii. O imagine incomplet sau eronat va
genera erori n funcionarea produsului final.
MCC trebuie s respecte o sum de reguli [FRAT97-2]:
s respecte normele i prevederile legislative din
domeniu;
s respecte regulamentele i procedurile interne ale
firmei (regulamentul de ordine interioar, fiele de
post);
s detalieze procesul n ntregime, din momentul
declanrii, pn la ultimele elemente specifice pe
care le induce.
MCC utilizeaz actori i fluxuri informaionale. Actorii
pot fi actori interni sau actori externi (din structura intern
i respectiv extern a SIFM).
n cadrul activitii financiar-monetare, actorii interni
sunt identificai cu departamentele instituiei sau lucrtori
(de ex. inspector credite, ofier de cont, director, contabil).
Actorii externi pot fi instituii financiar-monetare

corespondente, bnci, B.N.R, societi de asigurri, clieni
persoane fizice sau juridice.
Uneori, prin dezvoltarea activitii firmei, este posibil ca
un actor extern s devin actor intern.
Exemplu:
Societile de servicii de investiii financiare (S.S.I.F.) au
avut la un moment dat rolul de client (actor extern), care
intr n relaie cu banca n cadrul procesului de decontare
bursier. Pe msura dezvoltrii activitii bursiere, S.S.I.F.
este asimilat de organismul bancar i devine entitate n
cadrul grupului financiar i va fi perceput ca actor intern.
n acest caz, trebuie adaptat fluxul de documente din
cadrul S.S.I.F. la fluxul de documente bancare sau se
realizeaz o reorganizare n cadrul departamentului Pia
de capital din cadrul bncii.
ntre actori se schimb informaii sub forma fluxurilor
informaionale.
Diagramele de flux sunt reprezentri grafice ce reflect
legturile stabilite ntre actori. De regul, aceste fluxuri
sunt concretizate n documente de intrare-ieire din sistem
sau n/din subsisteme. Documentele pot fi standardizate
sau nestandardizate.
n condiiile n care se folosesc diferite mesaje ntre
actori, este indicat a se asocia documente formale. Astfel
de documente pot fi note contabile, note interne sau
notificri. Importana acestor documente const n faptul
c se poate evidenia stadiul n care s-a ajuns n derularea
procesului dar se pot stabili i responsabilitile n
condiiile n care apar disfuncionaliti.
Fluxurile informaionale se reprezint sub forma unor
arce orientate, de la actorul emitent la actorul destinatar.
Pe arc se utilizeaz o notaie numeric, aferent succesiunii
n timp a proceselor i codificarea documentelor, ca obiecte
ale fluxurilor informaionale .
Realizarea MCC poate fi considerat ca fiind un proces

iterativ, n condiiile n care fenomenul economic analizat
este complex. Astfel, MCC elaborat ntr-o prim faz la
nivel global, se poate detalia n mai multe MCC aferente
activitilor de baz ale unitii financiar-bancare
Un MCC complet realizat creaz premisele elaborrii
corecte a modelului conceptual de prelucrare (MCP).
Exemplu: MCC aferent activitii de creditare.
Detalierea fluxurilor financiare este urmtoarea:
1 nelegere client-giranti
pentru
girare contract de credit
2 cerere creditare
3 acte dosar credit
4 analiz dosar de credit +
referat
9 contract semnat
10 foaie de retragere +
bani
11 foaie de retragere +
extras
12 foaie de vrsmnt +
bani
5 dosar spre aprobare

6 analiz + decizie final
7 dosar de creditare
returnat
inspectorului de credit
8 deschidere cont i
creditare cont
semntura
bani
semntura
n condiiile n care sistemul financiar-monetar are

complexitate ridicat, dar modulele funcionale sunt relativ
independente, se pot trata separat aceste module la nivel
conceptual, urmnd ca n final s se realizeze conectarea
modulelor n cadrul unei singure aplicaii.
1.2.2 Modelarea conceptual a datelor (MCD)
MCD stabilete tipurile de entiti conceptuale,

atributele i asocierile necesare pentru SIFM, independent
de mjloacele de stocare i de modul de acces la date
[REYN92].
Variante de determinare a proprietilor MCD: 2
a) Varianta intrri-ieiri
Asigur includerea n MCD a proprietilor/atributelor n
funcie de intrrile sistemului preluate din obiectivele
2 Adaptare dupa [DAVI98]
SIFM i documentele de intrare, fiind independent de

ieirile sistemului.
n
urma
analizei
coninutului
informaional
al
documentelor de intrare se stabilete mulimea atributelor
noului sistem.
Considerm ca aceast variant se adapteaza cel mai
bine sistemelor deschise. Ofer posibilitatea unor
prelucrri ulterioare i determinarea unei mulimi de
parametri care nu sunt suficient analizai n etapele de
nceput ale analizei sistemului informaional. Dar nu
trebuie exagerat n crearea unor mulimi de variabile de
intrare care nu vor fi prelucrate i care vor ocupa resursele
sistemului.
b) Varianta ieiri-intrri
Pornind de la ieirile SIFM (indicatori, rapoarte) n
corelaie cu obiectivele sistemului, se va determina
mulimea atributelor. Aceast mulime va conine atribute
calculate pe baza unor algoritmi i atribute necalculate.
Acest variant este utilizat n cazul n care dispunem
de resurse limitate din punct de vedere al culegerii, stocrii
i prelucrrii datelor. Astfel vor fi determinate un numr
minim dar suficient de variabile de intrare care, prin
prelucrare, vor asigura determinarea paramentrilor de
ieire. Un astfel de sistem este mai uor de dezvoltat
ulterior, datorit suficienei variabilelor de intrare.
c) Varianta mixt
Pe baza documentelor de intrare, a ieirilor noului sistem
(indicatori, rapoarte, ieiri ctre alte sisteme) n corelaie
cu obectivele stabilite se va determina mulimea atributelor
utilizate att la intrarea ct i la ieirea din sistem. Aceast
mulime va cuprinde atribute necalculate, atribute
calculate i operanzi. Astfel, aceste atibute vor fi incluse n
tipul de entiti i de proprieti.
10
Pentru a elimina neajunsurile variantelor anterioare, se

utilizeaz varianta mixt, cea mai echilibrat variant,
asigurnd optimul ntre multimea variabilelor de intrare
necesare a fi prelucrate n scopul realizrii variabilelor i
situaiilor de iesire. Sistemul poate fi dezvoltat ntr-un mod
mai simplu, variabilele de intrare neutilizate oferind un bun
suport informaional.
Modelarea conceptual a datelor cuprinde urmtoarele
etape:
a) Determinarea bazei de atribute;
b) Stabilirea entitilor conceptuale n cadrul MCD;
c) Determinarea asocierilor ntre entiti conceptuale n
cadrul MCD;
d) Stabilirea cardinalitilor pentru asocieri.
a) Determinarea bazei de atribute
Are n vedere studierea structurii informaionale a
intrrilor i ieirilor specifice SIFM, sub aspectul
semanticii, tipului, lungimii maxime, al modului de calcul i
al stabilirii unui sistem de calcul asociat pentru
intrri/ieiri, precum i a structurii bazei de date.
Pentru fiecare tip de atribut calculat se vor prezenta
algoritmul de calcul i operanzii primari necesari.
Pornind de la documentele primare pe baza crora s-au
evideniat fluxurile informaionale n MCC, se determin
atributele entitilor.
Atributele vor fi codificate, respectnd urmtorele
cerine3:
unicitatea codurilor stabilirea unui simbol unic
pentru fiecare atribut al bazei informaionale;
stabilitatea codurilor utilizarea unui singur tip de
cod pentru a caracteriza un atribut pe toat durata de
via a sistemului;
facilitatea utilizrii codurilor codurile trebuie s fie
uor de neles i de aplicat;
3 Prezentare detaliat n [ROSC01]
11
concizia codurilor este dat de utilizarea unui numr

adecvat (minim dar suficient) de caractere.
b) Stabilirea entitilor conceptuale n cadrul MCD
Atributele determinate n cazul bazei de atribute
(dicionarul atributelor) se grupeaz n entiti conceptuale
respectnd cerinele de normalizare.
Gruparea se face innd cont de diferite criterii [FRAT961]:
gruparea atributelor se poate face pe documente
(ordin de plat, foaie de vrsmnt, cec de
numerar, contracte de credit);
gruparea
atributelor
se
poate
face
dup
semnificaie, de exemplu, pe baza nomenclatoarelor
(tipuri de depozite care pot fi deschise, tipuri de
credite care pot fi acordate).
Atributele utilizate de sistemul informaional sunt de
dou tipuri: preluate sau calculate.
Atributele preluate sunt sub forma n care se gsesc n
documentele primare i sunt determinate n baza
informaional.
Atributele calculate respect algoritmi de calcul i nu
apar n entitile conceptuale. Algoritmii de calcul vor fi
detaliai pn la nivel de operanzi primari.
Atributele care apar n entitile conceptuale trebuie s
respecte urmtoarele reguli4:
atributele
vor
avea
un
nume
unic
pentru
caracterizarea proprietilor pe parcursul rulrii
aplicaiilor;
nu apar n entiti conceptuale dect atribute
preluate;
4 Adaptare dupa [ROSC93]
12
atributele sunt elementare (atomice); atributele

compuse se descompun pn la nivel de atribut
elementar;
acelai atribut nu poate aprea n dou entiti
conceptuale diferite;
lista de atribute trebuie s fie neredundant, fr
atribute sinonime sau omonime.
Asupra atributelor pot fi stabilite anumite restricii cu
privire la evoluia acestora, domeniul sau valorile pe care le
pot lua (interval sau list). Aceste condiii de validare pot fi
clasificate ca simple, compuse, statice i dinamice, locale
sau globale, n funcie de variabilele (statice/dinamice) la
care se face raportarea respectiv aria la care se
circumscrie atributul, i anume la nivel de entitate/relaie
sau ntregul MCD.
Condiiile simple sunt determinate de natura atributului,
intervalul/lista de valori etc.
Exemple:
den_cli<> ;
nr_doc>0; data_doc>={01.01.2005};
tip_valuta ={LEI, USD, EUR,YEN}
Condiiile compuse se determin prin folosirea
operatorilor (matematici, logici, relaionali) i se stabilesc
n funcie de semantic, natura atributului, intervalul / lista
de valori etc.
Exemple :
operatori matematici : +, -, *, /, ^(ridicare la putere),
()
operatori logici : AND, OR, NOT, ( ), etc.
operatori relationali: =, <, >, <=, >=, #, $, = =
conditii de validare pentru un document primar:
13
(nr_doc>0 AND nr_doc<99999) AND (data_doc NOT

empty() and data_doc>{01.01.2003} )
Pentru
activitatea
de
creditare
am
determinat
urmtoarele atribute calculate [FRAT98].
Atribut
Formul
rulaj lunar debitor
31
soldzd(c, z)
rulld(c) =
rulaj lunar creditor
z 1
31
rullc(c) =
soldzc(c, z)
z 1
sold zilnic final

debitor
soldz_fd(c) = soldzd(c) + rulzd(c)
sold zilnic final

creditor
soldz_fc(c) = soldzc(c) + rulzc(c)
rata lunar
rata_l(c) = round(valimp/nrrate)
dobnda lunar
dob_l(c) = suma_ram(c) * proc_dob /

100/12
rata total
rata_t(c) = rata_l(c) + dob_l(c)
suma platit
suma_pl(c) = suma_pl(c + rata_l(c)
suma rmas de
rambursat
suma_ram(c) = suma_ram(c) rata_l(c)
rulaj zilnic debitor
rulzd(c) = rulzd(c) + suma(c)
rulaj zilnic creditor
rulzc(c) = rulzc(c) + suma(c)
n tabel am folosit urmtoarele notaii:

Notaie
Semnificaie
Numrul de cont al titularului
Ziua operaiunii bancare
soldzd
Sold zilnic debitor
soldzc
Sold zilnic creditor
valimp
Valoarea mprumutat (valoarea creditului
14
acordat)
nrrate
Numrul de rate de rambursat
suma_ram
Suma rmas de restituit din valimp
proc_dob
Procent de dobnd folosit pentru

rambursarea creditului
suma
Suma operat zilnic
n cadrul entitilor unele atribute vor ndeplini funcia

de identificator.
Identificatorul entitii este acel atribut prin care se
identific n mod unic o nregistrare. Identificatorul poate fi
un singur atribut sau poate fi determinat de mai multe
atribute (identificator multiplu).
Reguli pentru stabilirea identificatorilor:
identificatorul trebuie s fie nevid;
identificatorul trebuie s fie format dintr-un numr
minim de atribute;
n condiiile n care se pot alege identificatori
diferii pentru aceeai entitate, dar de natur
diferit, se vor prefera cei care au un numr minim
de atribute sau sunt mai uor de manipulat.
Exemplu:
n cadrul entitii Clienti_persoane_fizice, idetificatorul
entitii poate fi atributul Cod numeric personal (CNP) sau
identificator
multiplu
Serie
i
numar
carte
de
identitate/buletin (serie_BI, numar_BI). innd cont c CNP
apare pe toate actele de identificare a clientului (carte de
identitate, buletin sau paaport), este indicat utilizarea
CNP ca identificator al entitii Client.
c) Determinarea
asocierilor
conceptuale n cadrul MCD
ntre
entiti
15
Pe baza dependenelor funcionale ntre atributele bazei

informaionale, se determin asocierile ntre entitile
conceptuale.
Asocierile reprezint legturi ce se stabilesc ntre
entitile conceptuale. O asociere nu are o existen
proprie. Exist numai n msura n care exist realizrile
entitilor pe care le leag. Pot avea atribute proprii.
Cardinalitile
exprim
participarea
realizrilor
entitilor n cadrul asocierilor.
Cardinalitile sunt minimale (0,1; 1,1) sau maximale
(0,n; 1,n). Asocierile de tipul mn se rezolv prin
intermediul a dou asocieri 1,n si 1,m (1,n).
Colecia unei asocieri este dat de entitile participante.
Gradul (ordinul) asocierii este dat de numrul de entiti
participante.
Un caz aparte l genereaz asocierile reflexive. Sunt
asocieri care apar ntre realizri diferite ale aceleiai
entiti. n acest caz, trebuie specificate rolurile pe care le
joac entitatea n cadrul asocierii, roluri care arat
participarea entitii la asociere. n cadrul sistemului
informatic bancar astfel de asocieri sunt rare.
Exemplu:
16
Un client poate fi girant pentru un alt client al bncii. n

acest caz, rolurile sunt client girant i client girat.
Restriciile de integritate sunt reguli care trebuiesc
respectate de elemente (atribute, asocieri, entiti), iar
includerea acestora n fazele timpurii ale proiectrii duc la
o mai rapid depanare a eventualelor erori care pot apare
n rularea aplicaiilor [FRAT96-1].
Restriciile de integritate pot fi:
restricii de integritate structurale;
integritatea entitii;
integritatea referenial;
integritate de roluri;
integritate de asocieri;
restricii de integritate semantice.
Restriciile de integritate structural se refer la condiii
impuse conceptelor folosite n modelare.
Integritatea entitii implic existena unui identificator
unic i nevid pentru fiecare entitate.
Exemplu:
Pentru
entitatea
Contract{Nr_contr,
Data_contr,
Suma_contr, Dob_contr, Per_contr}, identificatorul entitii
este Nr_contr i nu poate lua valori vide. n entitate se
nregistreaz doar creditele acordate.
Integritatea referenial implic existena asocierii
determinat doar de existena realizrilor entitilor
participante la asociere.
Exemplu:
Client
CNP
Nume
..
1,n
1,1
Incheie
17
Contract
Nr_contr
Data_contr
..
Asocierea Incheie exist doar n msura n care exist o

realizare a entitii Client i o realizare corespondent a
entitii Contract.
Restriciile de integritate de roluri se refer la rolurile
jucate de o entitate n cadrul mai multor asocieri i se
manifest sub trei forme: incluziune, egalitate i excluziune
de roluri5.
Incluziunea: Dac entitatea E joac rolul r1 n asocierea
A1, atunci joac i rolul r2 n asocierea A2.
Exemplu:
Dac entitatea Client joac rolul de Platitor / beneficiar

n asocierea Efectueaz, atunci joac i rolul de Solicitant
n asocierea Depune
5 Prezentare detaliat n [ROSC01]
18
Egalitatea: Implic o incluziune de roluri r1 i r2 n

ambele sensuri ale asocierilor la care particip entitatea E.
Exemplu:
Mulimea deponenilor (pltitori) include mulimea
debitorilor, cei care au credite n derulare si i achit
ratele scadente.Mulimea debitorilor include i deponenii
care i achit ratele la creditele contractate.
Se constat o incluziune de roluri n dublu sens, deci o
egalitate de roluri pentru rolurile Debitor i Deponent
jucate de entitatea Client.
Client
CNP
Nume
..
1,n
Incheie
Debitor
1,n
------
Deponent
1,1
Efectueaza
1,1
Contract
Nr_contr
Data_contr
Suma_contr
...
Incas-pl
Tip_doc
-----Nr_doc
Data_doc
..
Excluziunea: rolurile r1 i r2 pe care le joac entitatea E

n dou asocieri diferite, A1 i A2, se exclud reciproc.
19
Exemplu:
Client
CNP
Nume
1,n
1,1
Vanzator
..
1,1
1,n
------
Ordin_valuta
Tip_ordin
Nr_ordin
Data_ordin
Suma_ordin
..
Vz_val
Cmp_val
Cumparator
------
Un Client nu poate fi n acelai timp i cumprtor i

vnztor de valut pentru acelai instrument financiar
utilizat (Ordin de cumprare/vnzare valut n acest
exemplu).
Restriciile de integritate de asocieri se refer la
condiionrile dintre dou asocieri i se manifest sub trei
forme: incluziune, egalitate i excluziune de roluri.
Incluziunea: Dac asocierea A1 exist, atunci i asocierea
A2 exist.
Exemplu:
Client
CNP
Nume
1,n
Depune
1,n
------
1,1
1,1
Efectueaza
Cerere_credit
Nr_cerere
Data_cerere
Suma_cerere
..
Incas-pl
Tip_doc
Nr_doc
Data_doc
..
------
Dac asocierea Efectueaz exist (fiind determinat de
20
realizarile entitilor Client i Incas_pl), atunci exist i

asocierea Depune (existnd n mod corespunztor realizri
ale entitilor Client i Cerere_credit, fiind vorba despre
acelai
client
care
a
efectuat
operaiunea
de
ncasare/plat).
Egalitatea: Dou asocieri A1 i A2 se condiioneaz
reciproc (exist n acelai timp).
Exemplu:
Un client cruia i s-a aprobat un credit poate efectua
operaiuni de ncasare/plat, iar un client care efectueaz o
operaiune de ncasare/plat n cadrul activitii de
creditare, a ncheiat anterior un contract de credit.
Excluziunea: Dou asocieri diferite, A1 i A2, se exclud

reciproc.
Exemplu:
n cazul derulrii unei activiti de creditare, banca nu
accept constituirea de depozite la termen pentru un client
debitor n condiiile n care acesta nu i achit obligaiile
de plat i se impune executarea garaniilor (giranilor).
21
Restriciile de integritate semantice sunt reguli de

gestiune impuse atributelor. Se maifest sub form de
restricii statice sau dinamice.
Restriciile statice privesc atributele, fr a ine cont de
evoluia lor n timp.
Exemplu:
Considernd entitatea Contract, putem stabili restricii
statice.
22
Restriciile dinamice in cont de evoluia n timp a

datelor.
Exemplu:
Considerm entitatea Contract, putem stabili restricii
dinamice.
Atributul Dob_contr se actualizeaz periodic de ctre
banc, n funcie de rata dobnzilor practicat pe piaa
financiar-bancar. Pentru contractele de credit deja
ncheiate, rata dobnzii se actualizeaz dup urmtoarea
regul: dac rata dobnzii de pe pia crete, rata dobnzii
aferente
contractului
de
credit
se
majoreaz
corespunztor; dac rata dobnzii de pe pia scade, rata
dobnzii aferente contractului de credit rmne constant.
Rafinarea MCD se face aplicnd tehnica normalizrii.
Normalizarea 6 este definit ca o tehnic de modelare
conceptual care are ca scop prelucrarea atributelor n
cadrul entitilor, n scopul eliminrii anomaliilor de ordin
logic i fizic. Astfel, se va mbunti etapa de modelare
conceptual a datelor, avnd ca rezultat ameliorarea
structurii bazei de date i implicit eliminarea unor
neajunsuri, cum ar fi: redundane, anomalii care pot apare
n procesele de actualizare a bazei de date (anomalii de
adugare, modificare, tergere a atributelor).
6 Adaptare dup [VELI03] i [BASC97]
23
Exist opinii diferite privind ncadrarea etapei de

normalizare n cadrul activitii de proiectare: n cdrul
etapei de modelare conceptual sau a etapei de modelare
logic. innd cont de faptul c are loc perfecionarea
modelului conceptual al datelor, cu transformarea
entitilor conceptuale n entiti conceptuale organizate
superior, care respect anumite reguli de organizare
(cerinele specifice formelor normale), este considerat mai
potrivit ncadrarea acestei etape n cadrul proiectrii
conceptuale.
n cadrul normalizrii, vom folosi pentru termenul de
entitate conceptual i termenul de relaie pentru entiti.
Relaia este o mulime de domenii plus o mulime de
perechi de nume-valoare, cte o pereche pentru fiecare
domeniu, iar valoarea se ncadreaz n domeniul numelui
[OPRE99].
Exemple de anomalii care pot aprea n procesul de
actualizare a bazei de date:
Anomalii la adugare: nu se permite introducerea de
noi informaii ntr-o tabel deoarece nu se cunosc alte
informaii utile pentru inserarea unui nou tuplu n acea
tabel.
Astfel, adugarea datelor financiare specifice unui nou
depozit (sum, dobnd, perioad) implic cunoaterea i
actualizarea a elementelor specifice pentru titularul
contractului
de
depozit
(cod_client,
nume_client,
adres_client).
Considerm urmtoarea relaie utilizat pentru gestiunea
activitii de depozite bancare: Client {Cod_client,
Nume_client, Tip_dep, Data_dep, Sum, Dob}
Cod_clie
nt
12371
Nume_clie
nt
Anghel
Tip_de
p
D-1-L
Data_de
p
02/03/04
Suma
Dob
10
0.12
24
12456
15542
17823
Tudor
Vasile
Zainea
D-3-L
D-6-L
D-12-L
05/04/04
07/06/04
05/07/04
7
15
30
0.13
0.14
0.15
Nu se pot introduce datele referitoare la depozitele pe 12

luni, pn cnd nu sunt introduse datele pentru primul
client care deschide un depozit de acest tip. Acest situaie
poate fi eliminat prin modificri asupra relaiei Client,
conform specificaiilor formelor normale.
Anomalii la modificare: nu pot fi modificate valorile
unui atribut al unei entiti, fr a face modificrile
echivalente n toate entitile n care apare acel atribut.
activitii de depozite bancare: Client {Serie_CI_cl,
Nr_CI_cl, Nume_cl, Tip_dep, Data_dep, Suma, Dob}
Serie
_
CI_cl
AC
AZ
ST
AC
SZ
Nr_CI
_cl
Nume_
cl
Tip_de
p
Data_de
p
Sum
a
Dob
15326
8
54268
9
15983
4
15326
8
48326
7
Anghel
D-1-L
10
0.12
Tudor
D-3-L
0.13
Vasile
D-6-L
15
0.14
Anghel
D-6-L
10
0.14
Zainea
D-12-L
02/03/0
4
05/04/0
4
07/06/0
4
02/05/0
4
05/07/0
4
30
0.15
Modificarea datelor specifice clientului (seria i numrul

crii de identitate) trebuie s se fac n toate tuplurile n
care intervin valorile modificate.
25
Anomalii la tergere: prin tergerea unui tuplu dintr-o

entitate, se pot terge i informaii utile existente n acel
tuplu.
activitii de depozite bancare: Client {Cod_client,
Nume_client, Tip_dep, Data_dep, Suma, Dob}
Cod_
client
12371
5
12456
8
15542
3
17823
3
Nume_
client
Anghel
Tip_dep
Data_dep
Suma
Dob
D-1-L
02/03/04
10
0.12
Tudor
D-3-L
05/04/04
0.13
Vasile
D-6-L
07/06/04
15
0.14
Zainea
D-12-L
05/07/04
30
0.15
n condiiile n care nu exist o entitate n care s se

memoreze informaiile despre dobnzile practicate,
tergerea informaiilor despre clientul Anghel poate duce la
pierderea informaiilor privind dobnda practicat de
banc la data 02.03.2004 pentru depozitele la termen de o
lun.
Normalizarea are la baz teoria formelor normale.
Primele trei forme normale au fost definite de Codd, iar a
patra i a cincea form normal au fost definite de Fagin.
Prima form normal (FN1)
O relaie este n prima form normal (FN1) dac toate
atributele conin valori elementare, nedecompozabile.
Totodat oricare dintre tupluri nu trebuie s aib grupuri
repetitive.
Etapele de aducere a unei relaii n FN1 sunt:
26
1. Descompunerea atributelor compuse n atribute

elementare i nlocuirea acestora n cadrul relaiei
2. Crearea unei noi relaii pentru atributele repetitive
3. Stabilirea identificatorului noii relaii, care va fi format
din identificatorul relaiei iniiale, la care se adaug un
numr minim de atribute, pentru delimitarea unui
identificator multiplu.
Exemplu:
Considerm relaia Client {Cod_cl, Nume_cl, Pren_cl,
Adresa_cl, Tip_dep, Nr_dep, Den_dep, Data_dep, Suma,
Dob, Cod_angajat, Nume_angajat}.
Cod_cl
12371
5
12456
8
Nume_
cl
Anghel
Pren_c
l
Marin
Tudor
Dragos
Adresa_cl
Cluj, str. Turda,
nr. 8
Iasi, str. Unirii,
nr. 2
Den_dep
Data_d
ep
Sum
a
Dob
Depozit la 1
luna
Depozit la 6
luni
06/04/0
3
05/06/0
3
2
5
Tip_d
ep
D-1-L
Nr_de
p
345
D-6-L
690
Nume_anga
jat
0.10
Cod_
angaja
t
123
0.12
125
Radu Victor
Ion Maria
Se constat c atributul Adresa_client nu respect

cerinele FN1. Ca urmare se va decompune acest atribut n
dou atribute Localit_client si Adr_loc_client. Acest fapt va
avea ca rezultat obinerea unor situaii mai clare privind
fondurile atrase de banc i scadenele acestora, pe
anumite zone geografice ale rii (localiti).
Totodat, se constat c relaia nu respect cerinele
FN1 i datorit faptului c atributele Tip_dep, Data_dep,
Suma, Dob iau valori multiple.
27
Soluia const n crearea a dou relaii:

Client
{Cod_cl,
Nume_cl,
Pren_client,
Adr_loc_cl}.
Cod_cl
12371
5
12456
8
Nume_
cl
Anghel
Tudor
Localit_cl,
Pren_c Localit_c
Adr_loc_cl
l
l
Marin
Cluj
str. Turda, nr. 8
Dragos
Iasi
str. Unirii, nr. 2
Depozite {Cod_cl, Tip_dep, Nr_dep, Den_dep, Data_dep,

Suma, Dob, Cod_angajat, Nume_angajat}
Cod_cl
Tip_dep
Nr_dep
Den_dep
12371
5
12371
5
D-1-L
345
D-6-L
690
depozit la 1
luna
depozit la 6
luni
Dob
Cod_anga
jat
123
125
0.10
0.12
Data_de
p
06/04/03
Sum
a
2
05/06/03
Nume_anga
jat
Ion Maria
Radu Victor
Dei am obinut dou entiti (relaii) care respect FN1,

totui apar unele probleme, nerespectndu-se cerinele
FN2.
Anomalii la adugare
Dac dorim s inserm noi date privind un nou anagjat,
acest lucru este posibil doar n msura n care va fi un
client care va lucra cu angajatul respectiv. Atributul Cod_cl
face parte din identificatorul multiplu al relaiei Depozite.
Anomalii la modificare
28
Dac se va schimba numele unui angajat (de exemplu o

angajat i schimb numele prin cstorie), trebuie
actualizate toate tuplurile care conin informaii despre
angajatul respectiv.
Anomalii la tergere
Dac un client a optat pentru un anumit tip de depozit,
iar n cursul zilei reziliaz sau transform acest contract de
depozit, clientul i angajatul vor fi teri din baza de date.
Poate fi o situaie limit, dac clientul respectiv a fost
primul client care a lucrat cu angajatul respectiv, situaie n
care codul i numele angajatului vor fi terse din baza de
date.
A doua form normal (FN2)
O relaie este n form normal 2 (FN2) dac respect
cerintele FN1 i orice atribut non-cheie7 este complet
dependent de cheia primar.
Etapele de aducere a unei relaii din FN1 n FN2 sunt:
1. Determinarea dependenelor pariale ntre atribute
cheie i atribute non-cheie.
2. Crearea de noi relaii, care vor include identificatorul
entitii iniiale, atributele care sunt determinate n etapa
anterioar i toate atributele pe care le determin.
3. Stabilirea identificatorilor noilor relaii, care vor fi
formai
din
identificatorul
relaiei
iniiale
i
atributul/grupul de atribute dependente n mod direct de
identificator, stabilite la etapa 1.
Exemplu:
Considerm relaia Depozite {Cod_cl, Tip_dep, Nr_dep,
Den_dep,
Data_dep,
Suma,
Dob,
Cod_angajat,
Nume_angajat}
7 Prin atribut non-cheie se nelege orice atribut al relaiei,
diferit de cheia primar
Cod_cl
Tip_dep
12371
5
12371
5
12371
5
D-1-L
Nr_de
p
345
D-6-L
690
D-3-L
723
Dob
0.10
0.12
0.11
Cod_anga
jat
123
125
456
Den_dep
depozit la 1
luna
depozit la 6
luni
depozit la 3
luni
29
Data_de
p
06/04/04
Sum
a
2
05/06/04
07/06/04
Nume_anga
jat
Ion Maria
Radu Victor
Ion Maria
Se constat c relaia Depozite nu respect cerinele

FN2, deoarece apar dependene pariale. Astfel, atributul
Nume_angajat este determinat de Cod_client, Tip_dep,
Nr_dep si Cod_angajat.
n relaia de mai sus apar doi angajai cu acelai nume,
dar de fapt sunt persoane diferite.
Depozite {Cod_cl, Tip_dep, Nr_dep, Den_dep, Data_dep,
Suma, Dob, Cod_angajat}
Cod_
clien
t
1237
15
1237
15
1237
15
Tip_
dep
D-1L
D-6L
D-3L
Nr_
de
p
345
Den_de
p
Data_
dep
Sum
a
Dob
0.10
Cod_
angaj
at
123
0.12
125
0.11
456
depozit 06/04/0
la 1 luna
3
690 depozit 05/06/0
la 6 luni
3
723 depozit 07/06/0
la 3 luni
4
Angajati {Cod_angajat, Nume_angajat}
30
Cod_angaja
t
123
125
456
Nume_angajat
Ion Maria
Radu Victor
Ion Maria
Dei am obinut dou entiti (relaii) care respect FN2,

totui apar unele probleme, nerespectndu-se cerinele
FN3.
Anomalii la adugare
Dac se dorete inserarea de noi date privind un nou tip
de depozit, se poate face doar n msura n care va fi un
client care s solicite acest lucru. Atributul Cod_cl face
parte din identificatorul multiplu al relaiei Depozite.
Anomalii la modificare
Dac se va schimba dobnda pentru un anumit tip de
depozit, de exemplu depozitul la vedere (overnight), trebuie
actualizate toate tuplurile care conin acest tip de dobnd.
Anomalii la tergere
Dac un client a optat pentru un anumit tip de depozit,
iar n cursul zilei reziliaz sau transform acest contract de
depozit, el va fi ters din baza de date pentru tipul de
depozit pentru care a optat iniial. Clientul respectiv a fost
primul client care a optat pentru tipul respectiv de depozit,
situaie n care caracteristicile tipului de depozit respectiv
vor fi terse din baza de date.
A treia form normal (FN3)
O relaie este n form normal 3 (FN3) dac respect
cerinele FN2 i nu conine dependene tranzitive ale
atributelor non-cheie fa de cheia primar.
31
Etapele de aducere a unei relaii din FN2 n FN3 sunt:

1. Determinarea atributelor aflate ntr-o dependen
tranzitiv fa de cheia primar
2. Crearea unor noi relaii, determinate de atributele
stabilite anterior i atributele pe care le determin, la care
se adaug identificatorul entitii iniiale
3. Stabilirea identificatorului noilor relaii, care va fi
format din identificatorul relaiei iniiale i atributul/grupul
de atribute dependente n mod direct de identificator,
stabilite la etapa 1.
Exemplu:
Considerm relaia Depozite {Cod_cl, Tip_dep, Nr_dep,
Den_dep, Data_dep, Suma, Dob, Cod_angajat}
Cod_
cl
Tip_
dep
Nr_
dep
Den_de
p
Data_d
ep
Sum
a
Do
b
12371
5
D-1-L
345
06/04/0
3
0.1
0
12371
5
D-6-L
690
depozit
la
1 luna
depozit
la
6 luni
05/06/0
3
0.1
2
Cod_
angaj
at
123
125
Se constat apariia dependenelor tranzitive: Tip_dep,

Nr_dep Den_dep
Contracte_dep {Cod_cl, Tip_dep,
Data_dep, Suma, Dob, Cod_angajat}
Cod_c
l
Tip_de
p
Nr_de
p
Data_de
p
Nr_dep,
Sum
a
Do
b
Den_dep,
Cod_
angaja
t
32
12371
5
12371
5
D-1-L
345
06/04/03
D-6-L
690
05/06/03
0.1
0
0.1
2
123
125
Fel_dep {Tip_dep, Nr_dep, Den_dep}

Tip_dep
D-1-L
Nr_dep
345
D-6-L
690
Den_dep
depozit la 1
luna
depozit la 6
luni
Forma normal Boyce-Codd (FNBC)

O relaie este n form normal Boyce-Codd (FNBC),
dac i numai dac fiecare determinant este o cheiecandidat.
Pentru dezvoltarea formelor normale, Boyce i Codd au
introdus conceptul de determinant. Un determinant va fi
orice atribut, simplu sau compus, prin care orice alt atribut
este total dependent funcional [OPRE99].
Exemplu:
Se urmrete gestiunea activitii de creditare, cu
garanii realizate prin folosirea depozitelor colaterale.
Se
utilizeaz
relaia
Client_cr_dep
{Cod_client,
Nr_contr_credit, Nr_contr_dep_colat}
A
Cod_client
...
123
123
....
B
Nr_contr_credit
Nr_contr_dep_colat
1126
1597
456
824
33
Se observ c relaia Client_cr_dep respect cerinele

FN2 i cerinele FN3.
n relatia Client_cr_dep, pot fi uilizate dou chei
candidat, din care numai una va fi selectat drept cheie
primar.
Cod_client + Nr_contr_credit
Cod_client + Nr_contr_dep_colat
Nr_contr_dep_colat este determinant, iar atributul
Nr_contr_credit este total dependent funcional de
determinant.
n aceast relaie apar anomalii la actualizare.
Dac se dorete actualizarea datelor despre client, n
condiiile n care se solicit acest lucru datorit
modificrilor din tuplul A, nu vor fi actualizate n mod
corepunztor datele despre client din tuplul B.
Rezolvarea const n crearea a dou relaii:
Client_dep {Cod_client, Nr_contr_dep_colat}
Cod_clien
t
...
123
123
....
Nr_contr_dep_col
at
456
824
Contr_dep {Nr_contr_dep_colat, Nr_contr_credit}

Nr_contr_dep_col
at
456
Nr_contr_cred
it
...
1126
34
824
1597
....
A patra form normal (FN4)

O relaie se afl n form normal 4 (FN4) dac este n
FNBC
i
nu
conine
dependene multiple.
Exemplu 8:
Serviciul Resurse umane din cadrul bncii dorete s in
o eviden despre repartizarea pe departamente i funciile
ndeplinite de personalul bancar.
Se creaz o relaie de forma:
Angajati {Cod_ang, Functie, Departament}
Cod_an
g
..
456
457
457
459
Functie
Departame
nt
ofiter
credite
director
director
economist
credite pf
credite pf
credite pj
marketing
Deoarece toate atributele formeaz identificatorul, nu

sunt probleme privind dependenele pariale sau tranzitive,
astfel c relaia respect cerinele FN2 i FN3. Totodat
nu se pune problema pentru un atribut s fie determinant,
aa c nu apar condiiile specifice FNBC.
Se constat c, n condiiile cumulului de funcii, apar
dependene multivaloare:
Cod_ang, Functie Departament
8 Prelucrare dup [BDAS02]
35
Acesta determin anomalii la adugare: adugarea unui

nou departament n sarcina unui angajat va determina
adugarea unui nou tuplu.
Angajati_functii {Cod_ang, Functie}
Cod_an
g
..
456
457
458
Functie
ofiter
credite
director
economist
Angajati_dept {Cod_ang, Departament}

Cod_an
g
..
456
457
457
458
Departame
nt
credite pf
credite pf
credite pj
marketing
A cincea form normal (FN5)9

O relaie se afl n form normal 5 (FN5) dac este n
FN4 i dac informaiile coninute nu pot fi reconstruite din
alte relaii mai mici dect dac au aceiai cheie.
Practic se descompune relaia iniial n mai multe
relaii, pe baza unor proiecii realizate dup cheile
candidat.
9 Preluare din [OPRE99]
36
Soluia
const
n
eliminarea
anomaliilor
la
adugare/modificare/tergere i la reducerea redundanei
bazei de date.
Exemplu10:
Pentru gestionarea depozitelor bancare la nivel de
central bancar, se consider relaia:
Depozite {Cod_cl, Nr_cont, Sucursala}
Cod_cl = CIF + NRC
Nr_cont = Grupa + Subgrupa + Simbol_cont
Sucursala = Cod + Simbol
Cod_c
l
..
456
Nr_con
t
Sucursala
123765
456
567234
456
123765
457
156333
Bucuresti
Unirii
Bucuresti
Unirii
Bucuresti
Izvor
Bucuresti
Unirii
Deoarece toate atributele formeaz identificatorul, nu

sunt probleme privind dependenele pariale sau tranzitive,
astfel c relaia respect cerinele FN2 i FN3. Totodat
nu se pune problema pentru un atribut s fie determinant,
aa c nu apar condiiile specifice FNBC i nu apar nici
dependene multivaloare, fiind respectate cerinele FN4.
n cadrul identificatorului, apar dependene funcionale
multivaloare:
Cod_cl Nr_cont
Sucursala Cod_client
10 Prelucrare dup [DAVI98]
37
Sucursala Nr_cont
Cod_cl reprezint codul clientului i este format prin
juxtapunerea codului unic de inregistrare (CUI) i a
numrului de la Registrul Comerului (NRC).
Cod_cl = CUI + NRC
Apar probleme (anomalii) la actualizare.
Anomalii la adugare.
O sucursal nu poate fi adaugat dect dac exist un
client (primul) care s deschid depozite la acea sucursal.
Anomalii la modificare.
Dac datele despre un client se modific (NRC),
trebuiesc actualizate toate tuplurile privind acel client, nu
numai cele corespunztoare depozitelor nou deschise.
Anomalii la tergere.
Dac un client va fi ters din diferite cauze (retragere
depozit sau depozit la scaden), datele despre sucursala
respectiv pot fi terse.
Soluia const n crearea a trei relaii:
Dep_cl_cont {Cod_cl, Nr_cont}
Cod_c
l
..
456
456
457
Nr_con
t
123765
567234
156333
Dep_cont_suc {Nr_cont, Sucursala}

Nr_con
t
..
Sucursala
38
123765
567234
123765
156333
Bucuresti
Unirii
Bucuresti
Unirii
Bucuresti
Izvor
Bucuresti
Unirii
Dep_cl_suc {Cod_cl, Sucursala}

Cod_c
l
..
456
456
457
Sucursala
Bucuresti
Unirii
Bucuresti
Izvor
Bucuresti
Unirii
n practic, de regul, se transform entitile prin

respectarea cerinelor FN1-FN4. Uneori sunt cazuri n care
se va face o denormalizare a entitilor, care duce la
apariia unor redundane printre atributele modelului, ns
acest lucru, dei nerecomandat, are ca efect obinerea mai
facil a anumitor situaii de ieire cerute de managementul
bncii la un moment dat.
Descrierea MCD se face utiliznd un tabel de forma
(exemplu pentru activitatea de creditare):
Descrierea tipurilor de
entiti
Descrierea tipurilor de relaii
Tipul de
entitate
Identifica
tor
Clienti
Contracte
Incas_plat
i
Tipul de
proprietate
Natura,
lungimea
CNP_cl, N,13
Nume_cl, T,20
Prenume_cl,
T,20
Judet_cl, T,10
Localitate_cl, T,
10
Adr_loc,_cl, T, 10
Numar_contr, N,
6
Data_contr, D, 8
Suma_contr, N,
9
Dob_contr, N, 3
Per_contr, N, 3
Tip_doc, T, 10
Numar_doc, N, 6
Data_doc, D, 8
Suma_doc, N, 9
Explicatii_doc, T,
10
Tip
relaie
Identifica
tor
incheie
efectueaza
incheie
gireaza
genereaza
efectueaza
genereaza
platesc
Cardinalita
te
Colecie
1,n
1,1
1,n
1,1
CLIENTI
CONTRACTE
CLIENTI
INCAS_PLAT
I
1,1
1,n
1,n
1,n
1,n
1,1
CONTRACTE
CLIENTI
CONTRACTE
GIRANTI
CONTRACTE
INCAS_PLAT
I
1,1
1,n
1,1
1,n
1,1
0,n
INCAS_PLAT
I CLIENTI
INCAS_PLAT
I
CONTRACTE
INCAS_PLAT
I
GIRANTI
1,n
1,n
0,n
1,1
GIRANTI
CONTRACTE
GIRANTI
CONTRACTE
CNP_cl, N,13
CNP_g, N,13
Giranti
CNP_g, N,13
Nume_g, T,20
Prenume_g, T,20
Judet_g, T,10
Localitate_gl, T,
10
Adr_loc_g, T, 10
gireaza
platesc
39
Pe baza acestor elemente se propune MCD simplificat,

aferent activitii de creditare.
40
1.2.3 Modelarea conceptual a prelucrrilor (MCP)
MCP asociat unui SIFB conine detalierea proceselor n

operaii i operaiilor complexe n operaii simple,
succesiunea i finalitatea acestor procese. Prin intermediul
unui formalism grafic sunt redate elementele participante:
actori, evenimentele surs care sincronizate determin
declanarea unor activiti i operaiuni, condiii de emisie
(funcionare), reguli de verificare i rezultate emise.
La un eveniment este interesant de urmrit frecvena de
apariie i capacitatea lui (numrul maxim de apariii ale
acestui tip de eveniment).
Exemplu:
41
eveniment extern, generat de evoluia sistemului

primrirea de documente de plat cec, OP, pli
valutare, determin apelarea unor activiti specifice,
respectiv operaiuni de pli inter/intr bancare;
eveniment intern crearea graficului de rambursare
determin plata ratelor i a dobnzilor la termenele
scadente fie de ctre client, fie prin reinerea sumelor
din contul curent de ctre banc.
Operaia
Orice domeniu reacioneaz la stimuli. Modul de
comportament al domeniului este reliefat de operaiile ce
se execut. Aadar operaia este o aciune/o mulime de
aciuni care se execut ca urmare a manifestrii unor
evenimente declanatoare sincronizate, aciuni care vor
produce evenimente rezultat. Un ansmblu legat de
evenimente declanatoare, sincronizri, operaii cu
activiti
i evenimente rezultat alctuiesc un bloc
operaie.
Operaiile pot fi descompuse n operaii elementare
specifice unui domeniu. Pentru fiecare operaie intereseaz
aciunile
constitutive,
condiiile
pentru
emiterea
rezultatelor, evenimentele rezultat, durata operaiilor.
Tipuri de operaii elementare: decizii, aciuni asupra
datelor (variabilelor) de lucru.
42
Sincronizarea
Sincronizarea exprim faptul c o operaie nu poate fi
declanat dect n anumite condiii existena simultan a
dou sau mai multe evenimente declanatoare. Aceste
evenimente sunt legate ntr-o expresie cu operatori de tip
boolean. Bineneles, analiza sistemului trebuie s plece de
la date reale i concrete, deci i evenimentele sincronizate
trebuie s fie valide, adic s prezinte momente n
dinamica i evoluia lor n care pot lua anumite valori, plaje
de valori sau sincronizri cu alte evenimente, astfel nct
fac posibile anumite operaiuni.
Sincronizarea poate prezenta mai multe forme :
sincronizarea este inactiv atunci cnd nu se produce
nici
un
eveniment
component
al
relaiei
declanatoare;
sincronizarea este n ateptare atunci cnd se produc
doar o parte din evenimentele componente ale relaiei
declanatoare;
sincronizarea este activ atunci cnd se produc toate
evenimentele componente ale relaiei declanatoare i
deci operaia va fi declanata.
Procesele
43
Procesele reprezint ansambluri de operaii complexe

executate ca reacie la evenimente, i care produc rezultate
succesive n vederea atingerii unui scop final.
Construcia unui model conceptual de prelucrare trebuie
s aib n vedere respectarea unor reguli i elaborarea
unor etape.
Trebuie avute n vedere urmtoarele reguli: orice actor
emite cel puin un eveniment i primete cel puin un
rezultat; orice operaie este declanat de ctre un
eveniment, dintr-o sincronizare sau printr-un rezultat;
sincronizarea presupune prelucrarea unei expresii logice;
orice rezultat constituie un mesaje pentru un actor fie un
eveniment pentru o sincronizare sau o operaie.
Etapele urmrite n elaborarea MCP:
identificarea
actorilor
i
a
evenimentelor
declanatoare;
construirea tabelului evenimente - rezultate;
descrierea proceselor, a operaiilor complexe i a
operaiilor elementare;
stabilirea relaiilor de sincronizare;
rezultate i mesaje asociate;
condiii de realizare a rezultatelor;
verificarea i validarea modelului.
Exemplu de bloc-operaie pentru activitatea de acordare
a creditelor bancare.
44
1.3 Modelarea logic

1.3.1 Modelarea logic a comunicaiilor (MLC)
45
MLC are ca scop stabilirea modului de organizare a

datelor n cadrul sistemului informatic.
n acest scop se vor lua n calcul urmtoarele criterii
[FRAT96-7]:
dimensiunea societii bancare;
natura i specificul prelucrrilor SIFB;
gradul de distribuire n timp i spatiu al prelucrrilor
SIFB;
tipul de organizare al societii bancare (sediu
central, filiale, sucursale, agenii, reprezentane);
arhitectura constructiv a cldirii n care i are sediul
societatea bancar.
Cele dou mari direcii care sunt folosite sunt
organizarea datelor n baze de date relaionale i baze de
date distribuite.
n cadrul MLC, se vor stabili tipul de arhitectur folosit,
SGBD i limbajele de interogare utilizate.
Arhitectura client-server este cea mai des ntlnit n
aplicaiile financiar-bancare. Arhitectura Client-server
poate fi pe mai multe niveluri11.
Arhitectura Client-Server de nivel 1 implic existena
unui FS (file server) i a unei WS (work station - statie de
lucru). FS conine baza de date i aplicaiile financiarbancare specifice, iar WS conine numai o interfa de
comunicaie cu FS. Pentru fiecare utilizator i WS se vor
acorda drepturi de acces specifice.
n acest caz, upgradarea aplicaiilor este facil, ns vor
apare timpi de nefuncionare pentru FS, ceea ce va afecta
modul de satisfacere a cererilor formulate de WS.
11 Prelucrare dup [ILIE00]
46
Exemplu:
n cazul operaiunilor de decontri intrabancare,
salariaii bncii de la serviciul de relaii cu clienii (conturiviramente) opereaz documentele prezentate de clieni
(ordine de plat, cecuri, bilete la ordin) prin apelarea
aplicaiilor aflate pe FS. Cu aceasta ocazie se actualizez
on-line soldurile conturilor clienilor, astfel nct orice
operator va putea lucra ulterior contul real al clientului.
Arhitectura Client-server de nivel 2 difer prin faptul c
pe WS sunt implementate aplicaiile financiar-bancare, iar
FS va conine baza de date. Cererile formulate de ctre WS
ctre FS se vor face utiliznd un limbaj de interogare
(SQL). Este o structur care implic partajarea aplicaiilor
pe WS dedicate pentru diverse activiti (acordare de
credite, contabilitate, administrativ), aplicaii care nu
trebuie i nu este nevoie s fie lansate de ctre alte servicii
dect cele direct interesate.
47
Exemplu:
Inspectorii de credite nu sunt interesai de calculul
amortizrilor investiiilor sau calculul impozitului pe profit
calculat de economitii din compartimentul contabilitate.
Nici pe acetia din urm nu-i intereseaz etapele
preliminare acordrii unor credite analiza indicatorilor de
solvabilitate, constituirea de garanii, calculul graficului de
rambursare pe diferite perioade de acordare a creditului
etc.
Rularea aplicaiilor n mod independent de la WS nu
afecteaz funcionarea SIFB n cazul actualizrii
aplicaiilor, blocajului sau defeciunii unei WS.
Dezavantajele se manifest prin faptul c o aplicaie
dezvoltat (upgradat) trebuie s fie implementat pe toate
WS care solicit acest lucru, innd cont de particularitile
acestora (hardware i software), ceea ce nseamn o
cheltuial sporit de resurse (umane, financiare, timp).
Arhitectura Client-server de nivel 3 presupune existena
a trei nivele de legtur.
48
Serverul de aplicaii implementeaz logica aplicaiei,

transmite cererile de la Client catre Server dar i rezultatul
interogarilor (prelucrrilor) serverului la aceste cereri.
Astfel, se evit aglomerarea i blocarea serverului de date,
prin implementarea aplicaiilor pe serverul de aplicaii.
Implementarea i actualizarea aplicaiilor se va face mult
mai rapid, aplicaiile pot fi implementate n limbaje de
programare diferite, n funcie de solicitrile clienilor. n
cazul unor SIFB complexe, un numr mare de WS i BD
mari, se propune partajarea aplicaiilor ntre mai multe
servere de aplicaii i partajarea bazelor de date pe mai
multe servere de date sau n cadrul serverului curent, dup
diferite criterii (de exemplu frecvena de apelare).
49
n condiiile dezvoltrii sistemelor informatice financiarbancare, prin extinderea serviciilor de internet banking, se
pot utiliza arhitecturi client-server pe mai multe nivele,
care conin servere de aplicaii, servere de baze de date,
servere de Web, monitoare pentru tranzacii, etc [ILIE00].
Arhitectura peer-to-peer folosete principiile de calcul
distribuit pentru implementarea aplicaiilor i a bazelor de
date. Echipamentele din reea realizeaz funciile FS (care,
n realitate, nu sunt distincte). Sistemele sunt deosebit de
flexibile, astfel nct orice WS poate fi privit i ca FS.
Modul de organizare a datelor n baze de date
relaionale i baze de date distribuite
SGBD relaional este destul de mult utilizat n domeniul
financiar-bancar, tiut fiind faptul c foarte greu se schimb
un sistem informatic financiar, n condiiile n care
funcioneaz fr erori i satisface cerinele utilizatorilor.
Problema schimbrii SGBD apare n condiiile n care
SGBD existent nu mai face fa cerinelor, nu se pot realiza
i conecta noi module, aplicaiile nu mai rspund n timp
real, apar pierderi de timp n prelucrri ale aplicaiilor.
n condiiile utilizrii unui SGBD relaional, trebuie ales
i un limbaj de interogare. Cel mai utilizat este SQL.
O importan deosebit o reprezint utilizarea sistemelor
de baze de date distribuite.
O baz de date distribuit este o colecie de baze de date
care din punct de vede logic apare ca o singur baz de
date, ns din punct de vedere fizic este format din multe
componente independente. Conform lui M.T.Ozsu, ele se
definesc ca o colecie de baze de date logic interconectate,
distribuite peste o reea de calculatoare [OZSU91]. Aceste
componente includ baze date de sine stttoare situate la
50
distan, servere situate la distan, servere locale i

clieni.
Fiecare nod (baz de date) al unei baze de date
distribuite este administrat separat i independent de
celelalte i trebuie sa aib control asupra datelor proprii,
ca i cum bazele de date componente nu ar fi legate n
reea. Fiecare baz de date este ntreinut independent
de celelalte baze de date, posed propriul sistem de
securitate, propriile planuri i proceduri de efectuare a
copiilor de siguran, de integritate i reconstituire, de
optimizare. Activitatile care privesc ntreinerea bazei de
date locale sunt efectuate n timp ce sistemul lucreaz, fr
s ncetineasc prea mult activitatea acestuia.
Dei bazele de date lucreaz mpreun cea mai mare
parte a timpului, ele sunt depozite de date distincte.
Independena bazelor de date locale asigur un nivel de
protecie mpotriva defectrii calculatoarelor din celelalte
noduri. Practic, se realizeaz o protejare reciproc i o
funcionare independent de defeciunile celorlali.
n procesul de stabilire a locatiilor trebuie avute n
vedere mai multe criterii:
performanele i integritatea reelei;
cantitatea de date utilizat de fiecare nod;
viteza nodurilor i capacitatea discurilor lor;
numrul de tranzacii din fiecare locaie;
amploarea impactului pe care l-ar avea cderea
reelei.
Problema proiectrii bazelor de date distribuite const n
fragmentarea bazelor de date, descompunerea relaiilor
initiale n subrelaii i apoi alocarea acestor fragmente n
nodurile retelei.
Distribuirea datelor poate fi:
distribuire prin fragmentare (orizontal, vertical,
mixt);
51
distribuire prin replicare;

distribuire mixt;
distribuire prin ncrcare.
Software-ul de gestiune a bazelor de date pe server,
pentru aplicaii cu baze de date n arhitectura client/server,
poate fi Oracle Server, Informix Online, DB2 etc.
Software-ul pentru client cuprinde produsele care pot
accesa baze de date dintr-o reea. Acesta poate fi un
software realizat ntr-un sistem de gestiune a bazelor de
date (FoxPro, Paradox, Oracle, Access), programe scrise n
TPascal, C++,
programe scrise n limbaje de tip
visual(Visual Basic).
Sistemele informatice pot fi pstrate pe unul sau mai
multe servere, n funcie de complexitatea sistemului. Din
acest punct de vedere, sistemele pot fi sisteme centralizate
i sistme distribuite.
Sistemul centralizat
Presupune existena unui singur server de aplicaii, pe
care este stocat ntreg sistemul de prelucrare a datelor. n
cele mai multe cazuri acest server nu este folosit i ca
server pentru baza de date. n cazul alegerii acestei
variante, trebuie dedicat un calculator performant care s
poat prelucra toate cererile adresate.
Sistem distribuit
Se realizeaz pentru sistemele complexe prin crearea
mai multor servere de aplicaii, fiecare coninnd un
subsistem informatic. Aceast soluie se adopt n cazul n
care subsistemele nu interacioneaz puternic i diferite
categorii de utilizatori folosesc funcionalitatea unui anumit
subsistem. De exemplu - utilizarea unui server de aplicaii
pentru fiecare departament beneficiar al sistemului
informatic.
n cazul n care se opteaz pentru o aplicaie distribuit,
trebuie s se aib n vedere urmtoarelor aspecte:
52
realizarea schemei de alocare a modulelor pe

calculatoare;
proiectarea comunicrii ntre serverele de aplicaii, n
cazul trecerii de la un modul la altul;
realizarea procedurilor de refacere n caz de incident;
identificarea performanelor serverelor de aplicaie.
Procesarea distribuit a cererilor are drept scop
obinerea unei strategii de execuie corespunztoare
pentru o interogare a bazelor de date distribuite, care s
minimizeze costurile de comunicaie. Strategia este
descris n termenii operatorilor din algebra relaional
folosind i primitive de comunicaie (send/receive) aplicate
bazelor de date locale.
Procesul este compus din urmtoarele etape:
descompunerea cererilor;
normalizare;
analiz semantic;
eliminarea redundanei;
rescriere;
localizarea datelor;
optimizarea global i local a cererilor.
Pentru implementarea unui sistem distribuit de baze de
date este necesar un limbaj de date relaional (SQL) bazat
fie pe algebra relaional, fie pe calculul relaional. Pentru
scrierea aplicaiilor complexe SQL nu este suficient i de
aceea interfaarea cu un limbaj de programare (procedural)
este de obicei necesar. Un astfel de limbaj de programare
este PASCAL/R, care conine un nou tip de variabil, numit
relation.
Limbajele de generatia a 4-a (4GL) sunt limbaje de nivel
nalt care combin operatorii din algebra relaional cu
construcii de program. Posibilitatea de a utiliza variabile
temporare i construcii puternice de program face ca
53
aceste limbaje numite limbaje de programare orientate

spre baze de date (Oracle) s fie deosebit de utile la
scrierea aplicaiilor.
Limitrile bazelor de date distribuite
ntr-o baz de date distribuit se pot stabili cteva
restricii
pentru
a
mri performanele, cum ar fi:
1) Limitarea numrului de tranzacii distribuite per nod.
Aceast valoare trebuie monitorizat pentru a fi siguri c
toate tranzaciile distribuite sunt procesate i nu sunt
refuzate datorit unei valori a acestui parametru. Pe de alt
parte, daca n toate nodurile valoarea acestui parametru
este prea mare, poate surveni o suprasolicitare care poate
duce la cderea acesteia.
2) Analiza punctelor de finalizare pentru fiecare instan.
Aceasta
este
necesar pentru a face astfel nct serverul cel mai
important s nu fie blocat n cazul unei cderi n timpul
unei finalizri n dou faze.
Este necesar a se analiza numrul de tranzacii eronate
determinate de accesri cu solicitri eronate sau ilegale
care pot afecta funcionarea reelei. Pentru creterea
vitezei
de
lucru
(rspuns)
se
indica
utilizarea
instantaneelor. Un instantaneu este o imagine static (readonly) a unui tabel. Sistemele distribuite permit
reproducerea unui tabel principal n alte noduri, de ctre
un numr nelimitat de instantanee. ntr-o baza de date
distribuit sistemul efectueaz urmtoarele aciuni atunci
cnd creeaz un instantaneu:
n nodul instantaneului, este creat un tabel de baz
pentru pstrarea liniilor conform interogrii de
definiie a instantaneului;
n nodul instantaneului, este creat o vedere read-only
a acestui tabel de baz;
54
la nivel local, sistemul creeaz o vedere a tabelului

principal situat la distan. Aceasta vedere este
utilizat pentru a remprospata instantaneul.
Instantaneele sunt utilizate n cazul tabelelor ale cror
date se modifica rar, ns sunt accesate masiv din noduri
situate la distan.
Avantajele utilizrii instantaneelor ntr-o aplicaie sunt
majore:
reducerea ncrcrii reelei;
timpul de rspuns se mbuntete, deoarece se
face referire la un instantaneu local.
La crearea unui sistem de baze de date distribuite
utilizatorii trebuie s in cont de urmtoarele aspecte:
Independena de hardware. Nu treibuie s aib
importan ce tip de hardware e folosit pentru server.
Trebuie s se permit combinaia de echipamente
hardware rspndite n sistem, n funcie de dotrile
utilizatorilor;
Independena de sistemul de operare. Nu trebuie s
aib importan care este sistemul de operare folosit
pe server. Poate fi Windows NT, OS/2 i orice variant
de Unix, OS./4OO, VMS, VM, MVS;
Independena de reea. Protocoalele folosite pentru
construirea reelei nu trebuie s influeneze
funcionarea bazelor de date distribuite;
Independena de DBMS. Ar trebui s existe
posibilitatea s se combine oricum serverele SQL - un
server s poata rula DB/2, un altul Microsoft SQL
Server, un al treilea Oracle, etc.
n cadrul activitii bancare, este justificat folosirea
bazelor de date distribuite. Se utilizeaz fragmentarea
mixt. Astfel, pentru activitatea de decontare, pentru a
mri viteza de lucru i a evita blocajele pe reea, se aplic
fragmentarea orizontal, dup criteriul tipul clientului
55
(persoan fizic sau persoan juridic) i innd cont de

numrul de operaiuni efectuate de un client ntr-o zi
lucrtoare. Astfel, observm o expandare a bazelor de date
aferente clienilor persoane juridice, respectiv un numr
mare de operaiuni efectuate la societile de distribuie.
Comparativ cu acestea, menionm c persoanele fizice
efectueaz un numr mic de operaiuni n decursul unei
luni, acestea fiind de regul de alimentare cont curent,
plata unor utiliti sau constituire de depozite la termen.
Pentru activitatea de creditare se aplic fragmentarea pe
vertical, fiind determinat de caracteristicile diferite ale
activitilor de creditare pentru persoane fizice i persoane
juridice (date de identificare, documentaie, indicatori
specifici, garanii).
Operaiunile da casierie sunt partajate, deoarece
observm faptul c cele mai multe pli n numerar sunt
efectuate de persoane fizice.
Pentru o mai bun gestionare a depozitelor la termen,
este indicat a se realiza fragmentarea acestora n depozite
n lei sau valut i dup criteriul maturitii la o lun, trei,
ase, nou i doisprezece luni.
1.3.2 Modelarea logic a datelor (MLD)
MLD asigur transformarea MCD ntr-o structur logic

a bazei de date, determinarea ordinii de actualizare a bazei
de date i a ordinii de listare a ieirilor SIFB n mai multe
faze:
a) transformarea MCD prin intermediul regulilor de
trecere de la MCD la MLD n funcie de cardinalitile
existente n MCD;
b) stabilirea ordinii de actualizare a bazei de date prin
intermediul ponderilor stabilite n MLD i a unei matrici
care conine aceste ponderi;
c) determinarea ordinii de listare a ieirilor sistemului
prin metoda grafic.
56
Exemplu:
Pentru activitatea de creditare, pornind de la MCD
propus anterior, aplicnd regulile de trecere la MLD, se
obine urmatoarea schem MLD:
Clienti
(CNP_cl,
Nume_cl,
Localitate_cl, Strada_cl,
Prenume_cl,
Judet_cl,
Numar_cl, Bloc_cl, Apartament_cl)
Contracte
(Numar_contr,
Dob_contr, Per_contr,
Data_contr,
Suma_contr,
CNP_cl)
Giranti
(CNP_g,
Nume_g,
Localitate_g, Strada_g,
Prenume_g,
Judet_g,
Numar_g, Bloc_g, Apartament_g)
Gireaza (Numar_contr, CNP_g)

Incasari_plati (Tip_doc, Numar_doc, data_doc, Suma_doc,
Explicatii_doc,
CNP_cl, CNP_g)
Regulile de trecere de la MCD la MLD se pot prezenta

sintetizat [FRAT04]:
57
1.3.3 Modelarea logic a prelucrrilor (MLP)
MLP rezult din transformarea MCP prin stabilirea

conversiilor dintre elementele specifice MCP i MLP. Astfel,
conversia de la MCP la MLP este prezentat succint n
tabelul urmtor [FRAT98]:
MCP
MLP
58
Activiti
Activiti
Evenimente de I / Evenimente de I / E
E
Sincronizare
Sincronizare
Procese
Operaii sau faze
complexe
Procese
Aciuni sau sarcini
elementare
Reguli de emisie
Reguli de emisie
- Frecvena operaiilor
- Compartimentele implicate
- Tipul operaiei (M - manual,
SA semiautomat,
A automat)
n elaborarea modelului logic al prelucrrilor se pornete

de la caracterul complex dar unitar al sistemului
informatic, astfel nct i acesta s contribuie la asigurarea
funcionrii optime a unitii bancare.
Astfel, sistemul are prelucrri omogene dar i specifice.
Prelucrrile furnizeaz rezultate specifice subactivitii
compartimentelor analizate dar i rezultate ce se constituie
n date de intrare pentru alte prelucrri.
Exemplu:
n cadrul bncii definim activiti ce privesc gestiunea
depozitelor
bancare,
gestiunea
opraiunilor
de
ncasri/pli, gestiunea opraiunilor intr i interbancare,
gestiunea contractelor de creditare, etc.
Actualizarea bazelor de date se face recursiv, fiecare
baz fiind supus operaiunilor de adugare, modificare,
tergere, salvare sau restaurare, la care se adaug
operaiuni de prelucrare i consultare (calcul pe baza unor
algoritmi, indexare, sortare, finalizate prin prezentarea
rezultatelor afiare pe monitor, listare la imprimant).
59
Operaiunile care se execut au frecvene aleatoare sau o

frecven determinat prin norme i reglementri n
domeniul financiar-fiscal.
Exemplu:
Operaiunile de deschidere de conturi, operaiunile de
ncasri / pli se fac aleator (n mod curent), la solicitarea
clienilor. Operaiunile prin care se calculeaz numerele de
dobnzi, se creaz situaia cu ratele creditelor restante, se
acord credite overdraft, se cumpr valut la licitaii
valutare cu frecven zilnic; operaiunile prin care se
creaz balana de verificare, se calculeaz amortizarea,
salariile personalului bancar au frecven lunar;
trimestrial se va calcula impozitul pe profit; semestrial se
va ntocmi bilanul contabil.
Pentru reprezentarea MLP se poate utiliza reprezentarea
blocurilor-operaie
sau
se
poate
adopta
varianta
completrii tabelare, variant mai practic.
MLP pentru activitatea de creditare:
Cod_o
p
Op1
Op2
Op3
Op4
Op5
Denumire _op
Tip
Cerere
acordare
credit
Decizie
de
creditare
ntocmire grafic de
rambursare
Rambursare credit
Rambursare
restane
Frecven
a
A
SA
SA
L
A
1.4 Modelarea fizic

1.4.1 Modelarea fizic a comunicaiilor (MFC)
60
MFC face referire la topologia LAN, aferent SIFB, n

structura creia numrul posturilor de lucru depinde de
numrul compartimentelor funcionale i/sau de numrul
persoanelor ce vor utiliza sistemul.
MFC poate fi implementat printr-o tehnologie mixt,
pornind de la trei topologii LAN de baz [REYN92]: stea,
inel i magistral.
TOPOLOGIA
LAN
STEA (Star)
INEL (Ring)
MAGISTRAL
(Bus)
CARACTERIZARE
GENERALA
Exist un singur punct comun de
conexiune, care este n acelai timp
un punct de control al reelei (de
exemplu, un dispozitiv hub).
Nodurile reelei sunt conectate prin
intermediul unui cerc continuu,
realizat fizic printr-un cablu de
transmisie comun. Semnalele sunt
transmise unidirecional de la un nod
la altul prin intermediul cablului de
transmisie. Inelul de control central
este denumit generic bucl.
Nodurile reelei sunt conectate
direct prin intermediul unui cablu.
Reeaua are un control distribuit sau
un control central. Magistrala are un
rol pasiv deoarece semnalele nu sunt
regenerate sau retransmise de/ctre
fiecare nod.
MFC presupune realizarea urmtoarelor

specifice:
1 - interconectarea topologiilor de tip LAN;
2 - securitatea LAN.
61
elemente
1) Interconectarea topologiilor de tip LAN

specificate la nivel MLC are n vedere urmtoarele
caracteristici generale previzibile la nivelul unei societi
bancare [FRAT96-7]:
reelele de calculatoare amplasate la nivelul unei
societi bancare sunt proiectate, realizate i coordonate de la o singur locaie central;
interfeele
necesare
pentru
conectare
sunt
dependente de numrul compartimentelor funcionale
interconectate, numrul i varietatea staiilor de lucru
i de dezvoltrile ulterioare ale SIFB;
sunt utilizabile tehnologii variate de realizare a reelei
de calculatoare, n scopul constituirii interfeelor;
este prezent o eterogenitate relativ, dependent de
specificul topologiei reelei i de tipul de software
utilizat;
Aceast interconectare a topologiilor de tip LAN (definite
la nivel MLC) se poate realiza (la nivel MFC) n mai multe
variante:
interconectarea direct este efectuat din dou sau
mai multe LAN-uri aflate fizic n acelasi sediu de
banc, etaj de cldire sau arie geografic, pentru a
forma un LAN EXTINS;
interconectarea prin reea backbone const n
principiu dintr-o reea LAN la care sunt atasate dou
sau mai multe alte reele de tip LAN, situaie n care
noua retea astfel constituit va avea o vitez de
transmisie mai mare dect viteza LAN-urilor
individuale;
62
interconectarea prin WAN asigur conectarea

societilor bancare, filialelor, ageniilor etc. situate n
zone geografice diferite.
Astfel se pot folosi facilitile de telecomunicaie ce
permit viteze de transmisie de 1,544 MB/secund. n acest
mod pot fi conectate dou reele de tip LAN ETHERNET
aflate geografic n dou orae sau ri diferite.
2) Securitatea LAN este un domeniu extrem de sensibil
deoarece presupune operaiuni de citire, modificare i

actualizare a aplicaiilor i a SGBD, n condiii de grad
maxim de siguran si confidenialitate. Trebuie avute n
vedere toate riscurile privind accesul neautorizat att din
interiorul ct i din exteriorul SIFB n vederea accesrii,
modificrii sau distrugerii datelor.
Analiza efectuat are n vedere serviciile de securitate
oferite i mecanismele de implementare a acestora.
Standardul ISO 7498-2 stabilete urmtoarele servicii de
securitate de baz: controlul accesului, autentificarea,
confidenialitatea
datelor,
integritatea
datelor,
nonrepudierea.
Mecanismele de securitate OSI au n vedere
urmtoarele aspecte12:
Criptarea este operaia de cifrare efectuat prin
intermediul unui mecanism de securitate utilizarea
cheilor publice i private, folosit pentru securitatea
fluxului de trafic i confidenialitatea datelor;
Semnatura digital este format dintr-un grup de
date adugate mesajelor surs, ce permit unui
receptor
s
verifice
emitentul
(autentificarea
utilizatorului) i integritatea datelor;
12 Adaptare dup [FRAT03-1]
63
Controlul
accesului
folosete
identitatea
autentificat n scopul determinrii i validrii
drepturilor de acces ale respectivei entiti;
Integritatea datelor permite verificarea datelor sub
aspectul integritii cmpului sau unitii de date;
Schimburile de autentificare asigur verificarea
entitii accesate prin folosirea de parole;
Completarea traficului implic generarea unui trafic
aleator pentru a se realiza o rat constant a
traficului;
Controlul dirijarii permite soluia fizic a cilor
alternative de comunicaie;
Notarea datelor comunicate ntre dou sau mai
multe entiti implic autentificarea acestora sub
aspectul originii, integritii, timpului i destinaiei.
Pentru situaia curent exemplificm M.F.C. prin
interconectarea direct. Aceasta foloseste cuplarea de LAN
Ethernet prin intermediul unui bridge (router).
64
1.4.2 Modelarea fizic a datelor (MFD)
MFD asigur descrierea tuturor tabelelor din baza de

date.
Videoformatele de intrare/ieire sunt folosite la nivelul
procedurilor automate fie pentru actualizarea bazei de
date, fie pentru listarea datelor din baza de date sub form
de rapoarte sau indicatori sintetici.
Meniurile de prelucrare asigur interfaa cu utilizatorul
prin activarea unor proceduri automate de prelucrare sau
execuia unei secvene de comenzi.
Exemplu: MFD pentru activitatea de creditare.
65
1.4.3 Modelarea fizic a prelucrrilor (MFP)
MFP preia toate elementele specifice modelrii fizice

(modelul fizic de comunicaii, modelul fizic de date,
videoformatele de intrare/ieire i meniurile de prelucrare)
i de a le transpune ntr-un sistem operaional de proceduri
automate, structurabile la rndul lor n modele de
prelucrare.
Criteriile utilizate n realizarea procedurilor SIFB sunt
urmtoarele:
a) Tipologia i natura prelucrrilor specifice activitilor
principale (fundamentale) asociate unei societi bancare
(deschiderea de conturi, ncasri i pli prin cas,
acordarea i rambursarea creditelor bancare, nchiderea
zilei bancare);
66
b) Natura i specificul intrrilor, ieirilor i prelucrrilor

fiecrei aplicaii informatice, care au fost asociate
activitilor principale specifice unei societi bancare;
c) Necesitatea asigurrii unui control centralizat i
integral al tuturor prelucrrilor efectuate asupra bazei de
date prin folosirea eficient a meniurilor de prelucrare
determinate anterior;
d) Minimizarea numrului de proceduri n condiiile
efecturii tuturor prelucrrilor necesare asupra bazei de
date.
Criteriile utilizate n realizarea procedurilor SIFB sunt
urmtoarele13:
a) Tipologia i natura prelucrrilor specifice activitilor
principale asociate unei societi bancare (deschiderea de
conturi, ncasri i pli prin cas, acordarea i
rambursarea creditelor bancare, nchiderea zilei bancare,
etc.);
b) Natura i specificul intrrilor, ieirilor i prelucrrilor
fiecrei aplicaii informatice, care au fost asociate
activitilor principale specifice unei societi bancare;
c) Necesitatea asigurrii unui control centralizat i
integral al tuturor prelucrrilor efectuate asupra bazei de
date prin folosirea eficient a meniurilor de prelucrare
determinate anterior;
d) Minimizarea numrului de proceduri n condiiile
efecturii tuturor prelucrrilor necesare asupra bazei de
date.
Exemplu: MFP corespunztor
informatic financiar-bancar).
13 Adaptare dup [FRAT98]
unui
SIFB
(sistem
NUME
PROCEDUR
SIFB
PAROLA
TIP
EXT.
*
DEF_MENU
IESIRE
INT. **
NI
V
RE
F
PROCEDURI
COMPONEN
TE
def_menu
parola
2
*
OP_CRT
LISTARE
VIZUALIZAR
E
TRANZ
op_crt
listare
vizualizar
e
iesire
tranz
desc_ct
inch_zi
restaurar
e
jurnal
jur_itbk
jur_casa
jur_com
extras_ct
sit_con
depozit
casa
credite
dec_itbk
intr_loc
intr_s_t
intr_s_p
67
FUNCIE
creare
meniu
principal de lucru
- apel procedur de
verificare
a
parolelor
- creare meniuri de
lucru
pentru
principalele
operaiuni bancare
- verificare parol de
acces la sistem
definire
meniu
principal
activare
meniu
principal
- ieire din program
- definire meniu
operaiuni specifice
activitii bancare
- listare rapoarte de
ieire
vizualizare
elemente
specifice
ale bncii i ale
tranzactilor
nregistrare
tranzacii efectuate
n
activitatea
bancar
68
DESC_CT
INCH_ZI
RESTAURAR
E
stornare
JURNAL
JUR_ITBK
JUR_CASA
JUR_COM
EXTRAS_CT
SIT_CON
CASA
casa_inc
casa_pl
itbk_inc
itbk_pl
DEC_ITBK
DEPOZIT
STORNARE
st_pl
st_dep
st_dibk
st_debk
CREDITE
def_m
nregistrare
deschidere
de
conturi
pentru
clienii bncii
- actualizare conturi
utilizate
n
ziua
respectiv
salvare
date
aferente
zilei
curente
- refacere zi de lucru
de
pe
suportul
extern
editare
jurnal
contabil
editare
jurnal
decontri
interbancare
editare
jurnal
operaiuni prin cas
editare
jurnal
comisioane
- editare extras de
cont
- editare situaie
conturi
nregistrare
operaiuni prin cas
(ncasri i plti)
nregistrare
decontri
interbancare
nregistrare
deschidere
de
depozit
- stornare operaiuni
pentru pli prin
cas,
depozite,
decontri
intrabancare
i
compensri
intrabancare
nregistrare,
INTR_LOC
INTR_S_T
INTR_S_P
CASA_INC
CASA_PL
ITBK_INC
ITBK_PL
ST_PL
ST_DIBK
ST_DEP
cred_v
cred_noi
cred_sc
titulari
mod_dob
list_disp
list_prn
actualizare i listare
elemente
specifice
ale procesului de
acordare
a
creditelor
nregistrare
decontri
intrabancare locale
nregistrare
decontri
intrabancare
prin
sucursale alte judee
(intrate)
nregistrare
decontri
intrabancare
prin
sucursale alte judee
(primite)
nregistrare
operaiuni
de
ncasare prin cas
nregistrare
operaiuni pli prin
cas
nregistrare
operaiuni
de
ncasare
rezultate
din activitatea de
compensare
interbancar
nregistreaz
operaiuni de pli
rezultate
din
activitatea
de
compensare
intrabancar
de pli prin cas
decontri
intrabancare
deschidere de cont
69
70
ST_DEBK
DEF_M
CRED_V
CRED_NOI
CRED_SC
TITULARI
MOD_DOB
LIST_DISP
LIST_PRN
* EXT. = EXTERNA
** INT. = INTERNA
decontri
interbancare
definire
meniu
principal
pentru
gestionarea
creditelor
nregistrare
acordare
credit
pentru
un
client
care
are
cont
deschis la banc
nregistrare
acordare
credit
pentru un client nou
- creare fiier de
scadene
actualizare
informaii
despre
titulari
- actualizare procent
de dobnd
- vizualizare grafic
de rambursare pe
ecran
- listare grafic de
rambursare
n
fiierul gr_ramb
71
72
1.5 Studii de caz aplicarea metodelor sistemice

(Merise) n proiectarea sistemelor informatice
financiar-monetare
Aplicaia 1 - Sistem informaional pentru operaiuni
de cont curent
Banca Alfa S.A. dorete realizarea unui sistem informaional privind operaiunile de cont
curent.
Pentru a putea efectua operaiuni cu banca Alfa S.A., clientul trebuie s deschid un cont
curent la banc.
n acest scop, clientul va depune o cerere la banc, n care se vor specifica:
datele de identificare ale bncii;

datele de identificare ale clientului, persoan fizic
sau juridic;
pentru persoanele fizice se vor ataa copii dup
cartea/buletinul de identitate;
pentru persoanele juridice se vor ataa copii dupa
actul constitutiv al societii i eventualele acte
adiionale, certificatul de nmatriculare, hotrrea
judectoreasc
privind
nfiinarea
societii
comerciale;
specimenele de semnturi pentru clieni i pentru
imputernicii;
codul contului deschis pentru client;
dobanda bonificat, comisioanele percepute;
opional datele de identificare al imputerniciilor pe
cont i drepturile acestora.
Conturile pot fi deschise n lei sau n valut (vor fi specificate valutele n cerere), codurile
conturilor prezentnd analitice distincte pe fiecare moned. Operaiunile curente privesc operaiuni
de incasri sau pli efectuate cu diferite instrumente financiar-bancare.
n situaia n care clientul dorete s renune la colaborarea cu banca, acesta va depune o cerere
pentru nchiderea contului.
Modelul conceptual al comunicaiilor (MCC)

Actori interni:
serviciul conturi-viramente;
casieria;
directorul;
serviciul compensari inter i intrabancare.
Actori externi:
client;
mputernicit;
bnci corespondente.
Fluxurile informaionale:
1. cerere deschidere cont + documentaie client persoan fizic sau persoan juridic;
2. verificare acte i deschidere cont;
3. foaie de vrsmnt pentru o depunere minimal in contul curent;
4. foaie de vrsmnt exemplarul 2;
5. foaie de vrsmnt prezentat ofierului de cont;
6. contract cont curent;
7. prezentare instrument de ncasare plat;
8. verificare document, verificare sold cont, viz ofier de cont;
9. solicitare derulare operaiune pe cont descoperit;
10. aviz favorabil / nefavorabil pentru operaiune pe cont descoperit;
11. nregistrare operaiune i vizarea documentului din partea bncii (prin ofierul de cont);
73
74

12. exemplar 3 (din ordinul de plat) napoiat clientului;
13.instrumente de ncasare-plat prezentate serviciul Compensare interbancar;
14. instrumete de ncasare-plat n compensare cu bnci corespondente;
15. raportul edinei de compensare, cu instrumente de ncasare-plat acceptate sau refuzate;
16. raport de compensare pentru actualizri interne;
17. actualizri conturi clieni;
18. foaie de retragere;
19. foaie de retragere exemplarul 2;
20. solicitare nchidere cont;
21. calcul sold final;
22. foaie de retragere;
23. foaie de retragere exemplarul 2;
24. nchidere cont curent client.
Modelul conceptual al datelor (MCD)
Modelul conceptual al prelucrrilor (MCP)

1. Deschiderea contului curent
75
76
2. Operaii de ncasari / pli n cont
3. Operaii de nchidere cont curent
77
78
D1 cerere deschidere contul curent client

D2 fia specimenelor de semnturi
D3 dosar deschidere cont curent client
D4 cerere deschidere cont curent client acceptat
D5 cerere deschidere cont curent client respins
D6 fi cont curent client
D7 fi cont curent client actualizat
D8 foaie de vrsmnt
D9 foaie de vrsmnt vizat
D10 foaie de retragere
D11 foaie de retragere vizat
D12 extras de cont
D13 cerere nchidere cont curent client
Modelul logic al comunicaiilor (MLC)

Se va folosi:
arhitectura Client-server de nivel 3;

SGBDR Access 2003
limbaj de interogare SQL
Arhitectura Client-server de nivelul 3 implic existena a trei nivele de legtur.
Nivelul intermediar implementeaz logica aplicaiei. Transmite cererile de la Client ctre
Server i rspunsul serverului la aceste cereri.
Modelul logic al datelor (MLD)
79
80
Modelul logic al prelucrrilor (MLP)

Cod
Denumire operaie
Tip
Frecve
opera
ie
Op. 1
Op. 2
Op. 3
Op. 4
Op. 5
Op. 6
Op. 7
81
na
Depunere cerere deschidre cont
nregistrare client
Activare cont curent client
Derulare operaiuni pe cont curent
Eliberare extras de cont
Cerere nchidere cont curent client
Eliberare extras de cont
Modelul fizic al comunicaiilor (MFC)
Modelul fizic al datelor (MFD)
M
SA
A
SA
A
M
A
A
A
A
A
A
A
A
82
Modelul fizic al prelucrrilor (MFP)
83

Carte PSI - Capitol Merise PT Studenti Oct 2014

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Carte PSI - Capitol Merise PT Studenti Oct 2014

Încărcat de

Drepturi de autor:

Formate disponibile

Proiectarea sistemelor informatice

1 Conceperea unui sistem informaional

1.1 Obiectivele S.I.F.M.

Obiectivele sistemului informatic reprezint scopuri

Proiectarea sistemelor informatice

obiective de conducere, care urmresc restabilirea

Pentru fiecare tip de activitate i obiectiv managerial sau

Proiectarea sistemelor informatice

n principiu, intrrile i ieirile standard ale unui SIFM

1.2 Modelarea conceptual

MCC realizeaz o reprezentare grafic a procesului

Proiectarea sistemelor informatice

Actorii externi pot fi instituii financiar-monetare

Proiectarea sistemelor informatice

Realizarea MCC poate fi considerat ca fiind un proces

5 dosar spre aprobare

Proiectarea sistemelor informatice

n condiiile n care sistemul financiar-monetar are

MCD stabilete tipurile de entiti conceptuale,

Proiectarea sistemelor informatice

SIFM i documentele de intrare, fiind independent de

Proiectarea sistemelor informatice

Pentru a elimina neajunsurile variantelor anterioare, se

Proiectarea sistemelor informatice

concizia codurilor este dat de utilizarea unui numr

4 Adaptare dupa [ROSC93]

Proiectarea sistemelor informatice

atributele sunt elementare (atomice); atributele

Proiectarea sistemelor informatice

(nr_doc>0 AND nr_doc<99999) AND (data_doc NOT

rulaj lunar debitor

sold zilnic final

soldz_fd(c) = soldzd(c) + rulzd(c)

sold zilnic final

soldz_fc(c) = soldzc(c) + rulzc(c)

dob_l(c) = suma_ram(c) * proc_dob /

rata_t(c) = rata_l(c) + dob_l(c)

suma_pl(c) = suma_pl(c + rata_l(c)

suma_ram(c) = suma_ram(c) rata_l(c)

rulaj zilnic debitor

rulzd(c) = rulzd(c) + suma(c)

rulaj zilnic creditor

rulzc(c) = rulzc(c) + suma(c)

n tabel am folosit urmtoarele notaii:

Numrul de cont al titularului

Ziua operaiunii bancare

Sold zilnic debitor

Sold zilnic creditor

Valoarea mprumutat (valoarea creditului

Proiectarea sistemelor informatice

Numrul de rate de rambursat

Suma rmas de restituit din valimp

Procent de dobnd folosit pentru

Suma operat zilnic

n cadrul entitilor unele atribute vor ndeplini funcia

Proiectarea sistemelor informatice

Pe baza dependenelor funcionale ntre atributele bazei

Proiectarea sistemelor informatice

Un client poate fi girant pentru un alt client al bncii. n

Proiectarea sistemelor informatice

Asocierea Incheie exist doar n msura n care exist o

Dac entitatea Client joac rolul de Platitor / beneficiar

Proiectarea sistemelor informatice