Curs nr. 5 Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează

la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de diagrame,

diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru descrierea

sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de date fizice şi

diagrame ale fluxului de date logice. Altele apelează la combinaţii de diagrame, tabele şi

forme descriptive .

Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat, prin

specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de

entităţi externe sistemului analizat.

1. Diagramele fluxurilor de date (DFD)

Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,

reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent.

Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,

structura lor şi cerinţele funcţionale ale noului sistem.

Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau

depozitele CASE (repository).

Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al

datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale

proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor.

DFD reprezintă doar una din tehnicile de analiză structurată.

Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor

de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare

cu ajutorul calculatorului, adică în instrumente CASE.

1.1 Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru

construirea DFD

În analiza sistemelor se folosesc frecvent reprezentările grafice, de exemplu

diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului informaţional.

1

Proiectarea fluxului informaţional reprezintă circulaţia informaţiei în sistem, transformările

suferite, stocarea informaţiei precum şi scurgerile de informaţie în afara sistemului. Scopul

diagramelor de date DFD pentru o anumită componentă organizatorică sau funcţională la

care se referă (secţie, birou, compartiment, întreaga unitate, o anumită activitate – vânzări,

cumpărări, încasări, plăţi, ş.a) este de a scoate în relief, într-o manieră cât mai sugestivă,

următoarele aspecte :

- sursa datelor de prelucrare;

- operaţiunile de prelucrare prin care trec datele;

- destinaţia datelor prelucrate;

- legătura existentă între prelucrări şi activitatea de stocare a datelor.

Întocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafică a transformării datelor de intrare în date de ieşire

folosind un set de simboluri de reprezentare şi un set de reguli de completare şi validare.

Simboluri folosite în diagramele realizate cu SSADM

proces (transformare): Procesele sunt etichetate cu text ce

sugerează modul de transformare a datelor şi sunt identificate printr-un număr(descriere a funcţiei procesului de prelucrare, începând cu un verb, urmat de o descriere a obiectului funcţiei de prelucrare). În DFD fizică pentru sistemul existent, se va precizaşi locaţia (compartiment / persoană) procesului.

flux de date: este constituit din datele transmise între două

procese. Fluxul de date este etichetat printr-un substantiv ce sugerează informaţia sau pachetul de informaţii transmise.

entitate externă (terminator): sursă / receptor de date. Poate

fi un alt sistem (organizaţie, compartiment).

stoc de date: un depozit temporar sau permanent de date.

Poate fi: - manual: registre, dosare, arhivă de documente - pe suport magnetic: fişiere.

Convenţii folosite în diagramele de reprezentare a fluxurilor de date DFD:

2

− procesele şi stocurile de date sunt numerotate secvenţial, pentru a putea fi

identificate. Numerele asociate proceselor nu semnifică ordinea de execuţie a

acestora;

− pentru a evita fluxurile de date întretăiate şi aspectul de “păienjeniş” al diagramei,

entităţile externe şi stocurile de date pot fi duplicate. O entitate externă duplicată

se reprezintă prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie

suplimentară verticală în partea stângă a cutiei;

− pentru a face diagramele mai lizibile, entităţile externe sunt plasate, pe cât posibil,

în jurul diagramei iar stocurile de date, în partea centrală a diagramei;

− fluxurile de date de la - către stocurile de date sunt unidirecţionale (fie de

adăugare, fie de consultare) şi nu sunt etichetate.

1.2. Descompunerea funcţională şi rafinarea DFD

Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să

realizăm de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele

complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o descompunere

funcţională a sistemului, care este realizată prin rafinarea succesivă a proceselor.

Primul nivel (nivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care defineşte

graniţele între sistemul analizat si mediu.

Nivelele următoare se obţin prin rafinarea proceselor complexe într-o diagramă de

nivel inferior.

Pentru aplicaţia DECONTĂRI au rezultat următoarele diagrame:

3

Fig. 1. Diagrama contextuală pentru aplicaţia Decontări

Fig. 2. Diagrama fluxului de date de nivel 1 pentru aplicaţia Decontări

Fig. 3. Diagrama fluxului de date de nivel 2 pentru aplicaţia Decontări

4

Definirea direcţiilor de perfecţionare a actualului sistem

Pe baza activităţilor de evaluare şi analiză critică se identifică neajunsurile actualului

sistem şi se propun soluţii de înlăturare a acestora se formulează variante de soluţii, iar în

cadrul acestora se definesc cerinţele şi restricţiile de realizare a sistemului informatic.

Definirea direcţiilor de perfecţionare presupune:

1. specificarea obiectivelor şi a performantelor sistemului informatic;

2. stabilirea domeniilor de probleme şi a principalelor funcţiuni ale sistemului informatic;

3. definirea cerinţelor si restricţiilor informaţionale pe domenii de probleme şi funcţiuni

care constă în:

− definirea principalelor intrări/ ieşiri;

− definirea soluţiei de organizare a datelor;

− definirea variantelor tehnologice de prelucrare;

− definirea restricţiilor informaţionale şi de control.

4. formularea condiţiilor pentru realizarea sistemului informatic, care constă în:

− specificarea termenelor şi duratelor solicitate;

− precizarea priorităţilor în realizarea obiectivelor sistemului informatic;

− specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu alte

sisteme, gradul de generalizare al sistemului.

Pentru fiecare variantă de soluţie informatică se procedează la:

− evaluarea resurselor necesare (costurile de sistem);

− evaluarea efectelor economice directe si indirecte;

− calculul indicatorilor de eficientă economică.

2. Modelarea sistemului curent Indiferent de tipul sistemului analizat, manual sau informatizat, acesta va fi înlocuit

de un nou sistem. Oricât de ineficient, vechiul sistem trebuie să transfere celui nou o serie

de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic actual

efectuează în parte sau în întregime ceea ce-şi propune să facă noul sistem fizic, dar la alt

nivel de performanţă. Necesitatea trecerii de la vechiul la noul sistem ne obligă să decidem

asupra celor două elemente specificate anterior, date şi proceduri, ceea ce conduce la

5

obligativitatea constituirii unui model logic al sistemului propus, care să conţină una sau

mai multe DFD, un model de date şi logica procesului de prelucrare. O modalitate de

abordare constă în prezentarea detaliată a sistemului fizic curent, după care să se realizeze

construirea modelului logic curent, prin abstractizarea celui fizic existent. Se va continua cu

scoaterea în relief a ceea ce trebuie neapărat schimbat din sistemul curent şi ceea ce trebuie

să se realizeze în cel nou. Pornind de la modelul fizic, se derivă modelul logic în cadrul

căruia se realizează:

− pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul cum

funcţionează sistemul în implementarea actuală;

− pune în evidenţă funcţiunile de bază ale sistemului;

− permite identificarea şi eliminarea problemelor legate de redundanţa datelor şi

duplicarea proceselor de prelucrare;

− permite stabilirea cu o mai mare precizie a graniţelor sistemului prin eliminarea

proceselor manuale care nu pot fi automatizate complet.

Derivarea modelului logic al sistemului existent

Construirea modelului logic presupune transformarea diagramei de flux a datelor

fizice în diagrama de flux a datelor logice.

Procesul de derivare a diagramei logice va începe de la ultimul nivel de

descompunere alcătuit de la procesele “frunză” şi va continua prin agregarea proceselor

către nivelurile superioare. Se parcurg următorii paşi :

1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea

într-un stoc logic de date a entităţilor înrudite sau utilizate frecvent.

După identificarea stocurilor logice de date se construiesc:

− diagrama de corespondenţă între stocuri logice şi entităţile din modelul logic;

− diagrama de corespondenţă între stocuri fizice şi stocuri logice de date.

2. Înlăturarea dependenţelor fizice şi temporale din denumirea proceselor şi a fluxurilor de

date: din DFD la nivel fizic (se observă că nu există referinţe fizice şi temporale în aplicaţia

decontări).

3. Derivarea proceselor logice:

− scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi

automatizate (deciziile);

6

− înlocuirea proceselor care nu realizează nici o transformare asupra fluxurilor de

date cu fluxurile propriu-zise;

− combinarea proceselor care realizează prelucrări asemănătoare sau multiple care

se execută împreună sau în secvenţă;

− înlăturarea proceselor care ţin de implementarea actuală şi a proceselor

redundante.

În cazul aplicaţiei prezente:

− se combină procesele “Înregistrare încasări în numerar” şi “Înregistrare încasări

prin virament” deoarece realizează prelucrări asemănătoare;

− se înlătură procesele redundante “Înregistrare încasări în jurnal” si “Înregistrare

plăti în jurnal”.

4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu

fluxul de informaţii utilizate efectiv de proces.

5. Gruparea proceselor elementare şi transformarea diagramei fizice în diagramă logică,

aplicând cei 5 paşi.

Relaţia existentă între DFD şi modelul datelor

După cum reiese din prezentările anterioare, fiecare săgeată din DFD reprezintă un

flux al datelor, în sensul unui traseu pe care structurile datelor elementare sau grupate se vor

deplasa în sistem. De exemplu, Facturi desfacere este o dată grupată. Când numele ei se

plasează pe un flux de prelucrare trebuie să vedem şi obligativitatea ca acel flux să fie

descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile

documentului. Similar va fi abordat şi simbolul pentru stocare. La prima vedere, el

reprezintă locul unde se realizează operaţiunea, dar foarte important este să prezentăm

structura datelor păstrate. Firesc, şi în cazul fluxului de date, şi în cel al stocării lor nu

trebuie uitată descrierea semnificaţiei economice. Structura datelor trebuie să fie redusă la a

treia formă normalizată, iar conţinutul locurilor de stocare a datelor să fie prezentat prin

reduceri la unul sau mai multe tabele relaţionale în forma a treia normalizată .

În cazul aplicaţiei DECONTĂRI, se obţine nivelul elementar al DFD a sistemului

logic pentru Decontări cu beneficiarii reprezentată în figura 4. Nivelele superioare ale DFD

a sistemului logic sunt identice.

Tabel 1 Aplicaţia Decontări

7

Sursa Destinaţia Nume flux Continutul fluxului

1.1. Înregistrare facturi desfacere

D2 FACTURI DESFACERE desfaceri

CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, DATAFACTD, NRFACTD, TOTALFACTD

D2 FACTURI DESFACERE

1.3. Analiza situaţie client desfaceri

CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, NRFACTD, TOTALFACTD

Figura 4. Diagrama fluxului de date

2.1 Modelarea logicii proceselor

După ce au fost descrise procesele de conversie a datelor în informaţii, prin

intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează şi logica internă

a proceselor, oricât ar fi de detaliate, chiar şi la nivelul proceselor primare, se impune

apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise

încât să poată fi convertite în programe prin intermediul limbajelor de programare.

8

În faza de analiză, modelarea logicii proceselor se va derula cât mai detaliat şi

complet posibil, dar operaţiunea nu va respecta structura sau sintaxa unui anumit limbaj de

programare: aceasta se va realiza într-o etapă ulterioară şi anume proiectarea. Modelarea

logicii proceselor ca şi diagramele fluxurilor de date fac parte din etapa de analiză a

sistemului.

În analiza structurată, rezultatele obţinute în urma modelării proceselor sunt descrieri

şi diagrame structurate care vor prezenta logica fiecărui proces, precum şi diagrame care vor

evidenţia dimensiunea temporală a sistemelor, când apar procesele sau evenimentele şi

modul în care aceste evenimente schimbă starea sistemului.

Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în

următoarele elemente ale documentaţiei :

− reprezentarea în engleza structurată;

− reprezentarea logicii proceselor prin tabele de decizie;

− reprezentarea logicii proceselor prin arbori de decizie;

− tabelul sau diagrama stărilor de tranziţie.

Reprezentarea logicii proceselor prin engleza structurată

Engleza structurată este o formă mult simplificată şi modificată a limbii engleze,

folosită pentru descrierea conţinutului casetelor care marchează procesele (prelucrările) din

diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită în

conceperea procedurilor componente ale sistemelor informatice . Se folosesc verbe pentru

cuvintele cheie şi substantive pentru descrierea structurii datelor.

Nu există o formă standard de engleză structurată, fiecare analist ar putea apela la o

formă proprie, dar scopul este de a înlesni accesul mai multor persoane la rezultatele

analizei înglobate în documentaţie. Utilizarea englezei structurate pentru procesul “Analiza

situaţie client” din decontări cu beneficiarii este reprezentată mai jos.

Analiza situaţie client

WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI

READ (FACTURI_DESF)

cod = FACTURI_DESF.codclient;

den = FACTURI_DESF.denclient;

9

adr = FACTURI_DESF.adresac;

cont = FACTURI_DESF.contc;

banca = FACTURI_DESF.bancac;

while (not eof (FACTURI_DESF))

{

if (cod!=FACTURI_DESF.codclient)

{ CLIENTI.codclient = cod;

CLIENTI.denclient = den;

CLIENTI.adresac = adr;

CLIENTI.contc = cont;

CLIENTI.banca_c = banca;

CLIENTI.sold = sold;

cod = FACTURI_DESF.codclient;

den = FACTURI_DESF.denclient;

adr = FACTURI_DESF.adresac;

cont = FACTURI_DESF.contc;

banca = FACTURI_DESF.bancac;

}

else

{

READ(ÎNCASĂRI);

vb=0; vb1=0;

while (not eof (ÎNCASĂRI) AND vb=0)

{

if (cod=ÎNCASĂRI.client AND

FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd AND

FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd)

{ if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata)

{ sold = sold+ FACTURI_DESF.totalfactd -

ÎNCASĂRI.sumaincasata}

vb1=1;

}

10

else if (vb1=1) vb=1

READ (ÎNCASĂRI)

}

MOVE FIRST LINE ÎNCASĂRI

READ (FACTURI_DESF)

}

CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)

3. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)

În cadrul modelării conceptuale a datelor se va renunţa la abordarea proceselor şi se

va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul modelării

proceselor şi modelării logicii proceselor elementele esenţiale vor fi diagramele.

James Martin şi Carma McClure, atunci când reliefează importanţa tehnicilor

structurate prin obiectivele ce şi le propun, consideră că o parte a acestora au legătură şi cu

datele, şi anume :

− Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se

referă la structurarea corectă a datelor, la uniformitatea modalităţilor de definire şi

proiectare a datelor la nivel de întreprindere şi nu a sistemului. Corect

efectuate, acestea accelerează procesele de analiză şi proiectare şi permit să se

utilizeze în comun componentele esenţiale ale sistemelor: resursele.

− Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică

problemele de structurare a lor şi conduc la structuri stabile ale acestora,

concretizate prin costuri reduse ale realizării sistemelor. Dacă baza de date a

unităţii este deosebit de importantă, atunci pe analiza datelor trebuie să se pună un

accent aparte, ea fiind întotdeauna realizată înaintea proiectării programelor.

Firesc, dacă ştim care sunt cerinţele unui sistem (ieşirile), imediat ne vom pune

întrebarea din ce se obţin acestea (intrările) şi apoi vom urmări cum se pot obţine

ieşirile (procesele).

Obiectivul principal al ingineriei informaţiei este crearea unui set de metodologii care

să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască modele

ale datelor la nivel de întreprindere, iar sistemele proiectate izolat să se integreze în aceste

modele.

11

Datele trebuie să fie unice. Asupra lor, la nivel de întreprindere, pot fi văzute două

categorii mari de operaţiuni:

− asigurarea datelor (creare, actualizare);

− utilizarea datelor (obţinere de documente, de diverse rapoarte, analize „What-If”,

sprijin decizional, diferite căutări de informaţii, control şi auditare întreprindere).

Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor

organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi legăturile

existente între date.

Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-

relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea

orietată-obiect.

Modelarea datelor prin DER prezintă caracteristicile şi structura datelor independent

de modul în care acestea sunt memorate în calculator. Modelul se creează iterativ. De cele

mai multe ori, operaţiunea are loc la nivel de întreprindere, prin apelarea la o categorie

foarte largă de date neglijându-se detaliile exagerate. Doar în etapele următoare, în speţă

când se trece la definirea proiectului, are loc construirea unui model anume entitate-relaţie

prin care să fie scoasă în evidenţă aria de întindere a proiectului. În timpul structurării

cerinţelor, un model entiatate-relaţie reprezintă cerinţele conceptuale de date pentru sistemul

luat în discuţie. După ce sunt descrise complet intrările şi ieşirile sistemului în cadrul

proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relaţie, este rafinat

înainte de a fi trecut într-un format logic (de regulă, un model relaţional al datelor) din care

se definesc bazele de date şi are loc proiectarea fizică a acestora.

Se consideră că, în timpul modelării conceptuale a datelor, se produc şi se analizează

cel puţin patru diagrame entitate-relaţie:

1. DER care să acopere datele necesare aplicaţiei proiectului. Ea va permite stabilirea

necesarului de date ale aplicaţiei proiectului, fără să se ţină seama de constrângerile sau

confuziile generate de detaliile care nu sunt încă necesare.

2. DER pentru aplicaţia ce va fi înlocuită. Diferenţele dintre aceste diagrame arată ce

schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicaţie. Nu se

aplică în cazul sistemelor complet noi.

3. DER care să scoată în relief întreaga bază de date din care noua aplicaţie îşi va extrage

datele. Cât timp mai multe aplicaţii pot folosi aceeaşi bază de date, această diagramă şi

12

prima evidenţiază modul în care noua aplicaţie apelează la conţinutul unor baze de date

mult mai extinse.

4. DER pentru întreaga bază de date din care aplicaţia curentă îşi extrage datele necesare.

Ea este discutată doar pentru sistemele care există şi pentru care se urmăreşte

îmbunătăţirea.

Metodele de determinare a cerinţelor trebuie să fie orientate, prin întrebările puse,

prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor. La

început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de

modul în care va afla cât mai multe informaţii despre datele necesare viitorului sistem

pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel formulate încât să se

realizeze o bună înţelegere a regulilor după care vor fi folosite datele în noul sistem, ce

politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii de genul: când şi cum sunt

prelucrate sau folosite datele, pentru a se realiza modelarea datelor.

Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere .

Un prim punct de vedere, formulat în literatură sub numele de metoda top-down, va

scoate în evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte clară a naturii

afacerii, şi nu se va opri asupra detaliilor privind modul în care ecranele, rapoartele sau

documentele sunt folosite în organizaţie.

În afara metodei top-down, informaţiile necesare construirii modelului datelor se pot

obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din interiorul

sistemului. Acest proces este cunoscut în literatura de specialitate sub numele de metoda

bottom-up.

Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi

evidenţiate datele prelucrate în sistem şi de aici va rezulta necesarul de date menţinute în

baza de date a sistemului.

3.1. Modelul Entitate/Relaţie (E/R) Cercetările efectuate pentru definirea unui model de date care să permită

reprezentarea cât mai fidelă a realităţii au condus la definirea conceptului de model semantic

încă din 1976 când Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astăzi o

tehnică larg acceptată pentru proiectarea bazelor de date.

13

Modelul E/R permite proiectantului bazei de date să elaboreze un model conceptual

de nivel înalt, fără a ţine seama de anumite constrângeri impuse de utilizarea unui anumit

SGBD, de o anumită platformă hardware, sau de anumite considerente de eficienţă privind

exploatarea bazei de date, ceea ce permite o reprezentare mai fidelă a realităţii avute în

vedere, constituind astfel o etapă intermediară în proiectarea unei baze de date, fiind din

acest punct de vedere asemănător pseudocodului utilizat în activitatea de programare.

Modelul Entitate/Relaţie (E/R) permite reprezentarea schematică a realităţii avute în

vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază: tip de

entitate, tip de relaţie (legătură, corelaţie), atribut.

Tipuri de entităţi, entităţi

Tipul de entitate reprezintă o clasă de obiecte sau un concept cu o existenţă de sine

stătătoare, este identificat printr-un nume şi este definit de un set de proprietăţi numite

atribute. O entitate este un obiect particular al clasei de obiecte, reprezintă o instanţă a

tipului de entitate şi este definit de valori corespunzătoare ale atributelor ce definesc tipul de

entitate. Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în cazul

nostru). Obiectele se caracterizează printr-o existenţă de-a lungul timpului, iar evenimentele

îşi fac simţită prezenţa la un moment dat. La rândul lor, obiectelor li se pot asocia cel puţin

două evenimente: apariţia şi dispariţia lor. Exemple: încheierea şi încetarea contractului de

muncă; predarea produselor la secţia expediţie şi desfacerea lor la beneficiari ş.a.

Evenimentelor le corespund asocieri între două sau mai multe obiecte. Exemplu: CLIENT

COMANDĂ PRODUS. Raportat la o anumită organizaţie, o entitate este o persoană, un loc,

un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care

organizaţia doreşte să păstreze anumite date. Se cuvine precizată diferenţa dintre tipurile

entităţilor (entity types) şi cazurile/instanţele entităţii (entity instances) . Tipul entităţii,

cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi care au proprietăţi sau

caracteristici comune. Referirea generală la elementele ce pot fi catalogate ca entităţi se va

realiza printr-un substantiv denumit cu litere majuscule, plasate în interiorul dreptunghiului

corespunzător entităţii.

O instanţiere a entităţii sau instanţă, denumită în continuare, caz al entităţii sau caz,

este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o singură dată

prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate

14

prin datele stocate în bazele de date. De exemplu, există o singură entitate CLIENT, dar ea

poate să aibă sute sau mii de cazuri/instanţe ale acestei entităţi stocate în baza de date.

Atribute

Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o proprietate

sau o caracteristică a unei entităţi care prezintă interes pentru organizaţie. La rândul lor, şi

relaţiile pot avea propriile lor atribute.

Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele posibile:

CLIENT : CodClient, DenClient, AdresaClient

Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu

majuscule (eventual + minuscule), plasate în interiorul elipselor, legate de entitatea căreia i

se asociază. De multe ori însă, chiar şi în cazul folosirii produselor CASE, pentru a nu se

încărca o diagramă entitate-relaţie, se evită prezentarea atributelor. Operaţiunea se face, în

schimb, în repository, depozitul de informaţii despre proiect. Aici orice atribut se descrie

separat, ca orice obiect distinct.

Cheie candidat şi cheie primară

Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se

efectueze diferenţierea fiecărui caz de acelaşi tip.

Un set de atribute ale căror valori identifică în mod unic instanţele unui tip de

entitate, constituie o cheie candidat pentru acel tip de entitate. Având în vedere faptul că

pentru un tip de entitate pot exista mai multe chei candidat, una dintre chei se va desemna

drept cheie primară.

O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca

identificator de cazuri în cadrul unui tip de entitate .

În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce

formează cheia primară, numele respective se subliniază (vezi CodClient din entitatea

CLIENT ).

Un tip de relaţie reprezintă o asociere între două sau mai multe tipuri de entităţi şi

defineşte legătura care există între tipurile respective de entităţi. Fiecare tip de relaţie este

identificat printr-un nume care descrie funcţia sa şi poate conţine atribute. O relaţie sau o

instanţă a unui tip de relaţie este o legătură între instanţe ale tipurilor de entităţi asociate în

cadrul tipului de relaţie corespunzător. Dacă R este un tip de relaţie definit pe tipurile de

entităţi E1, E2,…,En, atunci R este funcţional faţă de Ei (1 ≤ i ≤ n) dacă orice instanţă a

15

tipului de entitate Ei este determinată univoc de instanţe ale tipurilor de entităţi E1,…,Ei-

1,Ei+1,…,En prin relaţia R. Un tip de relaţie R definit pe tipurile de entităţi E1, E2,…,En, poate

fi funcţional sau nu faţă de fiecare din tipurile de entităţi Ei (1 ≤ i ≤ n).

Un atribut defineşte o proprietate a unui tip de entitate sau a unui tip de relaţie şi

poate fi: atribut simplu sau elementar, atribut compus (format din mai multe componente,

fiecare având o existenţă independentă), atribut derivat (valorile sale se obţin plecând de la

valorile altor atribute).

Pentru reprezentarea unor probleme complexe de tip bază de date, apărute începând

din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultând

astfel modelul entitate relaţie extins EER. În acest sens la conceptele de bază au fost

adăugate conceptele suplimentare de superclasă, subclasă şi moştenire.

O superclasă reprezintă un tip de entitate care conţine subclase distincte care trebuie

să fie reprezentate în cadrul modelului, iar o subclasă este un membru al unei superclase. O

subclasă, fiind un tip de entitate distinct, poate avea la rândul său subclase, astfel încât se

pot construi ierarhii de clase. O subclasă moşteneşte toate atributele superclasei, putând

avea în plus şi alte atribute. În diagrama EER, pentru subclase se vor reprezenta numai

atributele specifice subclasei.

Pentru elaborarea unei diagrame EER, se utilizează o serie de simboluri reprezentate

în figura 5.

16

Reprezentare tip entitate cu numele <nume tip entitate>

Reprezentare atribut cheie cu numele <nume atribut>

<nume tip entitate>

<nume atribut> Reprezentare atribut cu numele <nume atribut>

<nume atribut>

<nume tip relaţie> Reprezentare tip de relaţie cu numele <nume tip relaţie>

Relaţia R funcţională faţă de tipul

Relaţia R nefuncţională faţă de tipul

E R

E R

Superclasa

Subclasa

Apartenenţa subclasei la

<nume tip entitate>

<nume atribut>

Apartenenţa atributului <nume atribut> la tipul de entitate <nume tip entitate>

<nume atribut> Reprezentare atribut derivat cu numele <nume atribut>

Reprezentare atribut compus <nume atribut> format din componentele <atribut1>, <atribut2>

<nume atribut>

<atribut1> <atribut2>

Figura 5. Simboluri utilizate în reprezentarea unei diagrame EER

17

Un exemplu de reprezentare a unui tip de entitate prin diagramă este ilustrat în figura

6.

CLIENT

DenClient

AdresaClient CodClient

Figura 6. Model de reprezentare a atributelor prin DER

Relaţiile entităţilor

O relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de

entităţi care prezintă interes pentru organizaţie. Ele se reprezintă printr-un romb ca în

exemplul din figura 7.

PRODUSE FURNIZORI

Figura 7. Reprezentare relaţie Oferte între entităţile FURNIZORI, PRODUSE

Oferte

18