Text fara alineat
68Proiectarea sistemelor informatice
67Proiectarea sistemelor informaticeConceperea 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:
NiveleViziuni
ComunicaiiDatePrelucrri
ConceptualMCCMCDMCP
LogicMLCMLDMLP
FizicMFCMFDMFP
Obiectivele S.I.F.M. [footnoteRef:1] [1: Subcapitol publicat
parial n [FRAT98]]
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: 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 SIFMPentru 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.
Modelarea conceptual 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 credit5
dosar spre aprobare6 analiz + decizie final
2 cerere creditare7 dosar de creditare returnat
3 acte dosar credit inspectorului de credit
4 analiz dosar de credit + referat8 deschidere cont i creditare
cont
9 contract semnat13 foaie de vrsmnt + semntura
10 foaie de retragere + bani14 foaie de vrsmnt + bani
11 foaie de retragere + extras15 foaie de vrsmnt + semntura
12 foaie de vrsmnt + bani
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.
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:[footnoteRef:2] [2: Adaptare dupa
[DAVI98]]
a) Varianta intrri-ieiriAsigur includerea n MCD a
proprietilor/atributelor n funcie de intrrile sistemului preluate
din obiectivele 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-intrriPornind 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 mixtPe 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. 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 atributeAre 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
cerine[footnoteRef:3]: [3: Prezentare detaliat n [ROSC01]]
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; concizia
codurilor este dat de utilizarea unui numr adecvat (minim dar
suficient) de caractere.
b) Stabilirea entitilor conceptuale n cadrul MCDAtributele
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 [FRAT96-1]:
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 reguli[footnoteRef:4]:
[4: Adaptare dupa [ROSC93]]
atributele vor avea un nume unic pentru caracterizarea
proprietilor pe parcursul rulrii aplicaiilor; nu apar n entiti
conceptuale dect atribute preluate; 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:(nr_doc>0 AND nr_doc{01.01.2003} )Pentru
activitatea de creditare am determinat urmtoarele atribute
calculate [FRAT98].
AtributFormul
rulaj lunar debitorrulld(c) =
rulaj lunar creditorrullc(c) =
sold zilnic final debitorsoldz_fd(c) = soldzd(c) + rulzd(c)
sold zilnic final creditorsoldz_fc(c) = soldzc(c) + rulzc(c)
rata lunarrata_l(c) = round(valimp/nrrate)
dobnda lunardob_l(c) = suma_ram(c) * proc_dob /100/12
rata totalrata_t(c) = rata_l(c) + dob_l(c)
suma platitsuma_pl(c) = suma_pl(c + rata_l(c)
suma rmas de rambursatsuma_ram(c) = suma_ram(c) - rata_l(c)
rulaj zilnic debitorrulzd(c) = rulzd(c) + suma(c)
rulaj zilnic creditorrulzc(c) = rulzc(c) + suma(c)
n tabel am folosit urmtoarele notaii:
NotaieSemnificaie
CNumrul de cont al titularului
ZZiua operaiunii bancare
soldzdSold zilnic debitor
soldzcSold zilnic creditor
valimpValoarea mprumutat (valoarea creditului acordat)
nrrateNumrul de rate de rambursat
suma_ramSuma rmas de restituit din valimp
proc_dobProcent de dobnd folosit pentru rambursarea
creditului
sumaSuma 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 ntre entiti conceptuale n cadrul
MCDPe 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:
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:
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 roluri[footnoteRef:5].
[5: Prezentare detaliat n [ROSC01]]
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
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.
Excluziunea: rolurile r1 i r2 pe care le joac entitatea E n dou
asocieri diferite, A1 i A2, se exclud reciproc.
Exemplu: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: Dac asocierea Efectueaz exist (fiind determinat de
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).
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.
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
[footnoteRef: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]]
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_clientNume_clientTip_depData_depSumaDob
12371AnghelD-1-L02/03/04100.12
12456TudorD-3-L05/04/0470.13
15542VasileD-6-L07/06/04150.14
17823ZaineaD-12-L05/07/04300.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.Considerm urmtoarea relaie
utilizat pentru gestiunea activitii de depozite bancare: Client
{Serie_CI_cl, Nr_CI_cl, Nume_cl, Tip_dep, Data_dep, Suma, Dob}
Serie_CI_clNr_CI_clNume_clTip_depData_depSumaDob
AC153268AnghelD-1-L02/03/04100.12
AZ542689TudorD-3-L05/04/0470.13
ST159834VasileD-6-L07/06/04150.14
AC153268AnghelD-6-L02/05/04100.14
SZ483267ZaineaD-12-L05/07/04300.15
Modificarea datelor specifice clientului (seria i numrul crii de
identitate) trebuie s se fac n toate tuplurile n care intervin
valorile modificate.
Anomalii la tergere: prin tergerea unui tuplu dintr-o entitate,
se pot terge i informaii utile existente n acel tuplu. Considerm
urmtoarea relaie utilizat pentru gestiunea activitii de depozite
bancare: Client {Cod_client, Nume_client, Tip_dep, Data_dep, Suma,
Dob}
Cod_clientNume_clientTip_depData_depSumaDob
123715AnghelD-1-L02/03/04100.12
124568TudorD-3-L05/04/0470.13
155423VasileD-6-L07/06/04150.14
178233ZaineaD-12-L05/07/04300.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:1. Descompunerea
atributelor compuse n atribute elementare i nlocuirea acestora n
cadrul relaiei2. 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_clNume_clPren_clAdresa_clTip_depNr_dep
123715AnghelMarinCluj, str. Turda, nr. 8D-1-L345
124568TudorDragosIasi, str. Unirii, nr. 2D-6-L690
Den_depData_depSumaDobCod_angajatNume_angajat
Depozit la 1 luna06/04/0320.10123Ion Maria
Depozit la 6 luni05/06/0350.12125Radu Victor
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.
Soluia const n crearea a dou relaii:Client {Cod_cl, Nume_cl,
Pren_client, Localit_cl, Adr_loc_cl}.
Cod_clNume_clPren_clLocalit_clAdr_loc_cl
123715AnghelMarinClujstr. Turda, nr. 8
124568TudorDragosIasistr. Unirii, nr. 2
Depozite {Cod_cl, Tip_dep, Nr_dep, Den_dep, Data_dep, Suma, Dob,
Cod_angajat, Nume_angajat}
Cod_clTip_depNr_depDen_depData_depSuma
123715D-1-L345depozit la 1 luna06/04/032
123715D-6-L690depozit la 6 luni05/06/035
DobCod_angajatNume_angajat
0.10123Ion Maria
0.12125Radu Victor
Dei am obinut dou entiti (relaii) care respect FN1, totui apar
unele probleme, nerespectndu-se cerinele FN2.
Anomalii la adugareDac 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 modificareDac 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 tergereDac 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-cheie[footnoteRef:7] este
complet dependent de cheia primar. [7: Prin atribut non-cheie se
nelege orice atribut al relaiei, diferit 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}
Cod_clTip_depNr_depDen_depData_depSuma
123715D-1-L345depozit la 1 luna06/04/042
123715D-6-L690depozit la 6 luni05/06/045
123715D-3-L723depozit la 3 luni07/06/043
DobCod_angajatNume_angajat
0.10123Ion Maria
0.12125Radu Victor
0.11456Ion 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.Soluia const n crearea a dou relaii: Depozite
{Cod_cl, Tip_dep, Nr_dep, Den_dep, Data_dep, Suma, Dob,
Cod_angajat}
Cod_clientTip_depNr_depDen_depData_depSumaDobCod_angajat
123715D-1-L345depozit la 1 luna06/04/0320.10123
123715D-6-L690depozit la 6 luni05/06/0350.12125
123715D-3-L723depozit la 3 luni07/06/0430.11456
Angajati {Cod_angajat, Nume_angajat}
Cod_angajatNume_angajat
123Ion Maria
125Radu Victor
456Ion Maria
Dei am obinut dou entiti (relaii) care respect FN2, totui apar
unele probleme, nerespectndu-se cerinele FN3.
Anomalii la adugareDac 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 modificareDac 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 tergereDac 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.
Etapele de aducere a unei relaii din FN2 n FN3 sunt:1.
Determinarea atributelor aflate ntr-o dependen tranzitiv fa de
cheia primar2. Crearea unor noi relaii, determinate de atributele
stabilite anterior i atributele pe care le determin, la care se
adaug identificatorul entitii iniiale3. 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_clTip_depNr_depDen_depData_depSumaDobCod_angajat
123715D-1-L345depozit la1 luna06/04/0320.10123
123715D-6-L690depozit la6 luni05/06/0350.12125
Se constat apariia dependenelor tranzitive: Tip_dep, Nr_dep
Den_dep
Soluia const n crearea a dou relaii:
Contracte_dep {Cod_cl, Tip_dep, Nr_dep, Den_dep, Data_dep, Suma,
Dob, Cod_angajat}
Cod_clTip_depNr_depData_depSumaDobCod_angajat
123715D-1-L34506/04/0320.10123
123715D-6-L69005/06/0350.12125
Fel_dep {Tip_dep, Nr_dep, Den_dep}
Tip_depNr_depDen_dep
D-1-L345depozit la 1 luna
D-6-L690depozit 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
cheie-candidat. 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_clientNr_contr_creditNr_contr_dep_colat
...
1231126456
123B
1597824
....
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_creditCod_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_clientNr_contr_dep_colat
...
123456
123824
....
Contr_dep {Nr_contr_dep_colat, Nr_contr_credit}
Nr_contr_dep_colatNr_contr_credit
...
4561126
8241597
....
A patra form normal (FN4)O relaie se afl n form normal 4 (FN4)
dac este n FNBC i nu coninedependene multiple.
Exemplu [footnoteRef:8]: [8: Prelucrare dup [BDAS02]]
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_angFunctieDepartament
..
456ofiter creditecredite pf
457directorcredite pf
457directorcredite pj
459economistmarketing
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 DepartamentAcesta determin
anomalii la adugare: adugarea unui nou departament n sarcina unui
angajat va determina adugarea unui nou tuplu.
Soluia const n crearea a dou relaii: Angajati_functii {Cod_ang,
Functie}
Cod_angFunctie
..
456ofiter credite
457director
458economist
Angajati_dept {Cod_ang, Departament}
Cod_angDepartament
..
456credite pf
457credite pf
457credite pj
458marketing
A cincea form normal (FN5)[footnoteRef:9] [9: Preluare din
[OPRE99]]
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.
Soluia const n eliminarea anomaliilor la
adugare/modificare/tergere i la reducerea redundanei bazei de
date.Exemplu[footnoteRef:10]: [10: Prelucrare dup [DAVI98]]
Pentru gestionarea depozitelor bancare la nivel de central
bancar, se consider relaia:Depozite {Cod_cl, Nr_cont,
Sucursala}Cod_cl = CIF + NRCNr_cont = Grupa + Subgrupa +
Simbol_contSucursala = Cod + Simbol
Cod_clNr_contSucursala
..
456123765Bucuresti Unirii
456567234Bucuresti Unirii
456123765Bucuresti Izvor
457156333Bucuresti 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_contSucursala Cod_clientSucursala
Nr_contCod_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 + NRCApar 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_clNr_cont
..
456123765
456567234
457156333
Dep_cont_suc {Nr_cont, Sucursala}
Nr_contSucursala
..
123765Bucuresti Unirii
567234Bucuresti Unirii
123765Bucuresti Izvor
156333Bucuresti Unirii
Dep_cl_suc {Cod_cl, Sucursala}
Cod_clSucursala
..
456Bucuresti Unirii
456Bucuresti Izvor
457Bucuresti 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 entitiDescrierea tipurilor de relaii
Tipul de entitateIdentificatorTipul de proprietateNatura,
lungimeaTip relaieIdentificatorCardi-nalitateColecie
ClientiCNP_cl, N,13Nume_cl, T,20Prenume_cl, T,20Judet_cl,
T,10Localitate_cl, T, 10Adr_loc,_cl, T, 10
incheie
efectueaza
1,n1,11,n1,1
CLIENTICONTRACTECLIENTIINCAS_PLATI
ContracteNumar_contr, N, 6 Data_contr, D, 8Suma_contr, N,
9Dob_contr, N, 3Per_contr, N, 3
incheie
gireaza
genereaza1,11,n1,n1,n1,n1,1CONTRACTECLIENTICONTRACTEGIRANTICONTRACTEINCAS_PLATI
Incas_platiTip_doc, T, 10Numar_doc, N, 6Data_doc, D, 8Suma_doc,
N, 9Explicatii_doc, T, 10CNP_cl, N,13CNP_g, N,13efectueaza
genereaza
platesc
1,11,n1,11,n1,10,n
INCAS_PLATI CLIENTIINCAS_PLATI CONTRACTEINCAS_PLATIGIRANTI
GirantiCNP_g, N,13Nume_g, T,20Prenume_g, T,20Judet_g,
T,10Localitate_gl, T, 10Adr_loc_g, T, 10gireaza
platesc
1,n1,n0,n1,1
GIRANTICONTRACTEGIRANTICONTRACTE
Pe baza acestor elemente se propune MCD simplificat, aferent
activitii de creditare.
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: 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.
OperaiaOrice 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.
SincronizareaSincronizarea 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.
ProceseleProcesele 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.
Modelarea logicModelarea logic a comunicaiilor (MLC)
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
niveluri[footnoteRef:11]. [11: Prelucrare dup [ILIE00]]
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 financiar-bancare 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.
Exemplu:n cazul operaiunilor de decontri intrabancare, salariaii
bncii de la serviciul de relaii cu clienii (conturi-viramente)
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.
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.
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).
n condiiile dezvoltrii sistemelor informatice financiar-bancare,
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
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); 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: 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 aceste limbaje
numite limbaje de programare orientate spre baze de date (Oracle) s
fie deosebit de utile la scrierea aplicaiilor.
Limitrile bazelor de date distribuitentr-o baz de date
distribuit se pot stabili cteva restricii pentru amri 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 (read-only) 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; 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 (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.
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.
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, Prenume_cl, Judet_cl, Localitate_cl,
Strada_cl, Numar_cl, Bloc_cl, Apartament_cl)Contracte (Numar_contr,
Data_contr, Suma_contr, Dob_contr, Per_contr, CNP_cl)Giranti
(CNP_g, Nume_g, Prenume_g, Judet_g, Localitate_g, Strada_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]:
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]:
MCPMLP
ActivitiActiviti
Evenimente de I / EEvenimente de I / E
SincronizareSincronizare
Procese complexeOperaii sau faze
Procese elementareAciuni sau sarcini
Reguli de emisieReguli 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). 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_opDenumire _opTipFrecvena
Op1Cerere acordare creditMA
Op2Decizie de creditareMA
Op3ntocmire grafic de rambursareAA
Op4Rambursare creditSAL
Op5Rambursare restaneSAA
Modelarea fizicModelarea fizic a comunicaiilor (MFC)
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 LANCARACTERIZARE GENERALA
STEA (Star)Exist un singur punct comun de conexiune, care este n
acelai timp un punct de control al reelei (de exemplu, un
dispozitiv hub).
INEL (Ring)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.
MAGISTRAL (Bus)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 elemente specifice:1 -
interconectarea topologiilor de tip LAN;2 - securitatea LAN.
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; 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
aspecte[footnoteRef:12]: [12: Adaptare dup [FRAT03-1]]
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;
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).
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.
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);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
urmtoarele[footnoteRef:13]: [13: Adaptare dup [FRAT98]]
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 unui SIFB (sistem informatic
financiar-bancar).
NUMETIPNIVPROCEDURIFUNCIE
PROCEDUREXT. *INT. **REFCOMPONENTE
SIFB*1def_menuparola- creare meniu principal de lucru- apel
procedur de verificare a parolelor- creare meniuri de lucru pentru
principalele operaiuni bancare
PAROLA*2- verificare parol de acces la sistem
DEF_MENU *2op_crtlistarevizualizareiesire- definire meniu
principal- activare meniu principal
IESIRE*3- ieire din program
OP_CRT*3tranzdesc_ctinch_zirestaurare- definire meniu operaiuni
specifice activitii bancare
LISTARE*3jurnaljur_itbkjur_casajur_comextras_ctsit_con- listare
rapoarte de ieire
VIZUALIZARE*3- vizualizare elemente specifice ale bncii i ale
tranzactilor
TRANZ*4depozitcasacreditedec_itbkintr_locintr_s_tintr_s_pstornare-
nregistrare tranzacii efectuate n activitatea bancar
DESC_CT*4- nregistrare deschidere de conturi pentru clienii
bncii
INCH_ZI*4- actualizare conturi utilizate n ziua respectiv-
salvare date aferente zilei curente
RESTAURARE*4- refacere zi de lucru de pe suportul extern
JURNAL*4- editare jurnal contabil
JUR_ITBK*4- editare jurnal decontri interbancare
JUR_CASA*4- editare jurnal operaiuni prin cas
JUR_COM*4- editare jurnal comisioane
EXTRAS_CT*4- editare extras de cont
SIT_CON*4- editare situaie conturi
CASA*4casa_inccasa_pl- nregistrare operaiuni prin cas (ncasri i
plti)
DEC_ITBK*5itbk_incitbk_pl- nregistrare decontri interbancare
DEPOZIT*5- nregistrare deschidere de depozit
STORNARE*5st_plst_depst_dibkst_debk- stornare operaiuni pentru
pli prin cas, depozite, decontri intrabancare i compensri
intrabancare
CREDITE*5def_mcred_vcred_noicred_sctitularimod_doblist_displist_prn-
nregistrare, actualizare i listare elemente specifice ale
procesului de acordare a creditelor
INTR_LOC*5- nregistrare decontri intrabancare locale
INTR_S_T*5- nregistrare decontri intrabancare prin sucursale
alte judee (intrate)
INTR_S_P*5- nregistrare decontri intrabancare prin sucursale
alte judee (primite)
CASA_INC*6- nregistrare operaiuni de ncasare prin cas
CASA_PL*6- nregistrare operaiuni pli prin cas
ITBK_INC*6- nregistrare operaiuni de ncasare rezultate din
activitatea de compensare interbancar
ITBK_PL*6- nregistreaz operaiuni de pli rezultate din
activitatea de compensare intrabancar
ST_PL* 6- stornare operaiuni de pli prin cas
ST_DIBK*6- stornare operaiuni decontri intrabancare
ST_DEP* 6- stornare operaiuni deschidere de cont
ST_DEBK*6- stornare operaiuni decontri interbancare
DEF_M*6- definire meniu principal pentru gestionarea
creditelor
CRED_V*6- nregistrare acordare credit pentru un client care are
cont deschis la banc
CRED_NOI*6- nregistrare acordare credit pentru un client nou
CRED_SC*6- creare fiier de scadene
TITULARI*6- actualizare informaii despre titulari
MOD_DOB*6- actualizare procent de dobnd
LIST_DISP*6- vizualizare grafic de rambursare pe ecran
LIST_PRN*6- listare grafic de rambursare n fiierul gr_ramb
* EXT. = EXTERNA** INT. = INTERNA
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);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
2. Operaii de ncasari / pli n cont
3. Operaii de nchidere cont curent
D1 cerere deschidere contul curent clientD2 fia specimenelor de
semnturiD3 dosar deschidere cont curent clientD4 cerere deschidere
cont curent client acceptatD5 cerere deschidere cont curent client
respinsD6 fi cont curent clientD7 fi cont curent client
actualizatD8 foaie de vrsmnt D9 foaie de vrsmnt vizatD10 foaie de
retragere D11 foaie de retragere vizatD12 extras de contD13 cerere
nchidere cont curent client
Modelul logic al comunicaiilor (MLC)Se va folosi:arhitectura
Client-server de nivel 3;SGBDR Access 2003limbaj 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)
Modelul logic al prelucrrilor (MLP)
Cod operaieDenumire operaieTipFrecvena
Op. 1Depunere cerere deschidre contMA
Op. 2nregistrare clientSAA
Op. 3Activare cont curent clientAA
Op. 4Derulare operaiuni pe cont curentSAA
Op. 5Eliberare extras de contAA
Op. 6Cerere nchidere cont curent clientMA
Op. 7Eliberare extras de contAA
Modelul fizic al comunicaiilor (MFC)
Modelul fizic al datelor (MFD)
Modelul fizic al prelucrrilor (MFP)
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Client
CNP
Nume
Pren
Adresa
..
gireaza
Client girant
Client girat
0,n
0,n
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Client
CNP
Nume
..
------
Contract
Nr_contr Data_contr
..
------
Incheie
1,n
1,1
1,1
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Depune
Cerere_credit
Nr_cerere
Data_cerere
Suma_cerere
..
------
Client
CNP
Nume
.
..
------
Solicitant
O
1,n
Platitor / beneficiar
1,1
Incas-pl
Tip_doc
Nr_doc
Efectueaza
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Deponent
Debitor
1,n
Efectueaza
1,1
1,n
1,1
Incheie
Incas-pl
Tip_doc
Nr_doc Data_doc
..
------
Contract
Nr_contr
Data_contr
Suma_contr
...
------
Client
CNP
Nume
..
------
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Cumparator
Vanzator
1,n
Cmp_val
1,1
1,1
Vz_val
Ordin_valuta
Tip_ordin
Nr_ordin
Data_ordin
Suma_ordin
..
------
Client
CNP
Nume
..
------
1,n
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
1,n
Efectueaza
1,1
1,n
1,1
Depune
Incas-pl
Tip_doc
Nr_doc Data_doc
..
------
Cerere_credit
Nr_cerere
Data_cerere
Suma_cerere
..
------
Client
CNP
Nume
------
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
1,n
Efectueaza
1,1
1,n
1,1
Incheie
Incas-pl
Tip_doc
Nr_doc Data_doc
..
------
Contract
Nr_contr
Data_contr
Suma_contr
..
------
Client
CNP
Nume
..
------
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Efectueaza
1,n
1,1
1,n
Incheie
Incas-pl
Tip_doc
Nr_doc
....
------
Contract_credit
Nr_contr
Data_contr
....
------
Client
CNP_cl
Nume_cl
..
------
Girant
CNP_g
Nume_g
..
------
Contract_depozit
Nr_contr_dep
Data_contr_dep
..
------
Plateste
Deschide
1,n
1,n
1,n
1,1
1,1
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Restrictii statice:
Nr_contr > 0
Data_contr > 01.01.2003
Suma_contr > 1.000.000 (lei)
Dob_contr > 0
Per_contr < 60 (luni)
Contract
Nr_contr
Data_contr
Suma_contr
Dob_contr
Per_contr
------
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Cod operaie
Denumire operaie
Aciuni
Reguli de emisiune
R1 | R2 | R3 | | Rn
E1
Em
E3
E2
Evenimente rezultat
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
a(b(c(d(e(f
Contract de credit
Documentatie de credit
GARANTII
pe 3 luni
BALANTA
BILANT
Cerere de credit
utilizare credit
Documentatie
OK NOT OK
- intocmire contract de credite
- analiza si avizarea documentatiei de catre seful serviciu
credite
- analiza si avizarea documentatiei de creditare de catre
inspector credite
Op1 | ACORDAREA SI RAMBURSAREA CREDITELOR BANCARE
b
c
d
e
f
a
Adev. Venit
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Logica
aplicaiei
Interfaa
Nivelul Client
Baza de
date
Server de date
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Servere de baze de date
Client
Web browser
Monitor tranzacii
Server
Web
Server de
aplicatie
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Casa
WS
WS
WS
WS
WS
WS
Bridge/Router
WS
WS
Serviciu clientel
Serviciu credite
Comitet de credite
1,1
9
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
Gireaza
Numar_contr, N, 6
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
Strada_g, T, 10
Numar_g, N, 3
Bloc_g, T, 4
Apartament_g, N, 3
Clienti
CNP_cl, N,13
Nume_cl, T,20
Prenume_cl, T,20
Judet_cl, T,10
Localitate_cl, T, 10
Strada_cl, T, 10
Numar_cl, N, 3
Bloc_cl, T, 4
Apartament_cl, N, 3
Contracte
Numar_contr, N, 6
Data_contr, D, 8
Suma_contr, N, 9
Dob_contr, N, 3
Per_contr, N, 3
Incas_plati
Tip_doc, T, 10
Numar_doc, N, 6
Data_doc, D, 8
Suma_doc, N, 9
Explicatii_doc, T, 10
CNP_cl, N,13
CNP_g, N,13
Server de
aplicatie
Baza de
date
Server de date
Servicii
Logica Aplicaiei
Server de aplicatii
Client
Nivelul Client
Logica
aplicaiei
Client
Nivelul Client
Baza de
date
Server de date
Logica
aplicaiei
Interfaa
5
2
1
Comitet de acordare a creditelor
Casa
Servicii credite
Client
Giranti
7
3
10
11
12
13
4
6
8
14
15