+ All Categories
Transcript

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


Top Related