ARCHIP LORENA

CAPITOLUL VIII

Modelarea conceptuală a datelor

(diagramele entitate-relaţie, DER)

Obiective:
Discutarea necesităţii şi conţinutului modelării conceptuale a datelor
Prezentarea conceptelor utilizate în construirea diagramelor entitate-relaţie
Înţelegerea modului de transpunere a regulilor economice în modelul conceptual al datelor
Prezentarea unui model general al DER pentru sistemele informaţionale economice

După o abordare multiplă a sistemelor informaţionale, a importanţei lor într-un organism

economic, am continuat cu prezentarea elementelor-cheie ale dezvoltării sistemelor
informaţionale, şi chiar am redat modalităţile determinării cerinţelor unui sistem. În momentul
de faţă discutăm despre structurarea lor, aflându-ne la unul dintre cele mai importante
momente şi obiecte din viaţa sistemului. Importanţa rezidă, îndeosebi, în statutul obiectului
supus discuţiei: datele.
În capitolul anterior ne-am referit doar la structurarea logică a proceselor de prelucrare din
organizaţie (enumerarea şi legarea lor), regăsită şi cu denumirea de modelarea logică a
prelucrărilor.
Elementele esenţiale erau diagramele – ca instrument de lucru – şi datele ca obiect de
prelucrare. Insistăm asupra acestui aspect, deoarece se produce un salt esenţial în abordarea
sistemelor: abandonarea proceselor ce au loc în sisteme (ca importanţă în activităţile de
analiză şi proiectare) şi trecerea datelor pe primul plan. De fapt, era chiar un paradox: se
încerca realizarea unor sisteme cât mai stabile pe baza celor mai instabile componente ale lor,
procesele.
Ideea de structurare a sistemului oricum va rămâne. Din această cauză considerăm că se
cuvine să evidenţiem poziţia datelor în abordarea sistemelor.

8.1 Aplicarea principiului abstractizării în modelarea datelor

În acest paragraf vom încerca să evidenţiem necesitatea şi conţinutul modelării
conceptuale a datelor. În acest sens, va trebui să explicăm în ce constă aplicarea principiului
abstractizării în modelarea datelor. De fapt, acesta reprezintă unul din principiile fundamentale
aplicate în proiectarea sistemelor informatice, el fiind utilizat şi la proiectarea arhitecturii
programelor. Aplicarea principiului abstractizării permite stăpânirea complexităţii sistemului,
prin luarea în considerare, în mod eşalonat, a diferitelor aspecte ale acestuia. La un moment
dat, analiştii se vor concentra doar asupra anumitor aspecte, ignorându-le pe celelalte, dar care
vor fi luate în considerare ulterior.
Concret, aplicarea principiului abstractizării în modelarea datelor presupune operarea pe
trei niveluri, prezentate în figura 8.1: conceptual, logic şi fizic. Corespunzător celor trei
niveluri, pot fi identificate trei activităţi esenţiale în proiectarea bazelor de date:
 analiza cerinţelor sistemului şi modelarea conceptuală a datelor,
 modelarea logică a datelor sau proiectarea logică a bazei de date şi
 modelarea fizică a datelor sau proiectarea fizică a bazei de date.
 MODELAREA CONCEPTUALĂ A DATELOR 17
Cerinţele de date ale
sistemului

Modelul conceptual al datelor

Modelul conceptual
(modelul entitate -alrelaţie)
datelor
Regulile şi conceptele (modelul entitate - relaţie)
modelului relaţional Cerinţele de calitate
(flexibilitate, stabilitate etc.)

Modelul logic al datelor

Cerinţele nefuncţionale şi
de performanţă
Modelul
(modelullogic al datelor
relaţional pur)
(modelul relaţional pur)
Facilităţile SGBD-ului ales

Modelul fizic
Modelul al datelor
fizic al datelor
(structura fizică
(structura a da
fizică telor)
a da telor)

Fig. 8.1 Nivelurile de abstractizare a datelor

Prin modelarea conceptuală a datelor se urmăreşte construirea unui model al datelor care
să asigure transpunerea exactă a realităţii din domeniul analizat, fără a lua în considerare
cerinţele specifice unui model de organizare a datelor (cum este modelul relaţional), criteriile
de calitate privind organizarea datelor, cerinţele nefuncţionale ale sistemului şi criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul conceptual al datelor înseamnă o
formă de reprezentare a datelor organizaţiei astfel încât el să reflecte regulile de derulare a
afacerilor în firma respectivă. 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 conceptuală a datelor este diagrama
entitate-relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea
orientate-obiect.
Modelul conceptual este unul abstract, care nu poate fi implementat direct pe calculator.
De exemplu, modul în care vor fi implementate legăturile dintre entităţile de date nu
interesează în acest moment, atenţia fiind îndreptată doar spre identificarea şi descrierea lor.
Ulterior, acest model trebuie transformat într-o schemă a bazei de date sub formă de tabele,
coloane şi restricţii de integritate, reprezentând modelul logic al datelor.
Modelarea logică presupune organizarea datelor în tabele şi coloane, conform regulilor
modelului relaţional (acesta fiind cel mai popular model de organizare a datelor). După cum se
poate observa din figura 8.1, proiectarea logică a bazei de date presupune transformarea
modelului conceptual al datelor, prin aplicarea regulilor şi conceptelor specifice modelului
relaţional şi a criteriilor de calitate ale modelului logic al datelor, aspecte ignorate în etapa
modelării conceptuale. De exemplu, modelul relaţional nu permite implementarea relaţiilor
multe-la-multe dintre două entităţi de date, motiv pentru care acestea trebuie transformate în
două relaţii unu-la-multe.
Scopul urmărit constă în obţinerea unui model relaţional pur, nealterat de cerinţele
nefuncţionale şi cele de performanţă în stocarea şi accesarea datelor, nici de facilităţile oferite
de diferite SGBDR-uri existente pe piaţă. Toate aceste aspecte vor fi considerate abia la
construirea modelului fizic al datelor. Principalele criterii de calitate utilizate la evaluarea
modelului logic al datelor se referă la completitudine, non-redundanţă, reutilizare, flexibilitate
şi simplitate.
Modelul fizic al datelor, rezultat în urma proiectării fizice, este invizibil utilizatorilor şi
programatorilor. El specifică modul de stocare şi accesare fizică a datelor, utilizând facilităţile
oferite de un anumit SGBD. De exemplu, date din tabele diferite pot fi stocate pe disc
împreună pentru a putea fi transferate în memoria calculatorului printr-o singură operaţiune.
Aşadar, obiectivul principal urmărit în cadrul acestei activităţi constă în optimizarea
performanţelor bazei de date, în ceea ce priveşte stocarea fizică şi accesul la date.
Luarea în considerare a acestor aspecte poate implica „alterarea” modelului logic (adică a
modelului relaţional pur), presupunând uneori prejudicierea aspectelor calitative ale acestuia.
În unele situaţii, timpii de acces ceruţi pot fi obţinuţi prin intermediul indecşilor, însă, de multe
ori, este necesară modificarea structurii logice a datelor, prin procesul denormalizării. Dacă, la
proiectarea schemei logice, s-a urmărit prezervarea integrităţii datelor, prin procesul de
normalizare, acum poate deveni necesară introducerea unui anumit nivel de redundanţă a
datelor sau a câmpurilor calculate în schema bazei de date. Principala provocare constă în
găsirea compromisului între uşurinţa păstrării integrităţii datelor şi performanţele bazei de date,
prin prisma stocării şi accesării datelor. Soluţia ideală ar presupune obţinerea performanţelor
cerute în condiţiile păstrării aspectelor calitative ale modelului logic, ceea ce este posibil
numai în condiţiile separării nivelului logic al bazei de date de cel fizic. O astfel de facilitate
este oferită doar de unele SGBD-uri din categoria Sql-Base, precum Oracle.
De asemenea, la proiectarea fizică vor fi luate în considerare şi facilităţile oferite de
SGBD-ul ales. Diferenţele dintre diferite SGBD-uri se referă adesea la tipurile de date
suportate, reprezentarea sau nu a relaţiilor dintre clase şi subclase, implementarea relaţiilor
recursive. De exemplu, în mediul Oracle nu se poate lucra cu date de tip boolean (logic).
Aşadar, construirea modelului conceptual al datelor constituie doar o primă activitate în
proiectarea bazei de date. În continuare, ne vom concentra asupra analizei cerinţelor sistemului
şi construirea modelului conceptual al datelor, respectiv a diagramei entitate-relaţie. Mai întâi
vom vedea care sunt informaţiile care trebuie colectate, în scopul modelării conceptuale a
datelor, iar apoi care sunt conceptele, regulile şi demersul pentru transpunerea lor în diagrama
entitate-relaţie.

ASAFTEI CARMEN

8.2 Culegerea informaţiilor pentru

modelarea conceptuală a datelor
Culegerea cerinţelor informaţionale se realizează în faza de analiză a sistemului, prin
intervievarea utilizatorilor sau pe alte căi. 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.
Obiectivele majore ale analizei cerinţelor privind datele vizează 1:
 descrierea cerinţelor de date ale sistemului în termenii entităţilor de date;
 colectarea informaţiilor care descriu entităţile de date şi relaţiile dintre ele;
 determinarea tranzacţiilor de prelucrare ce vor fi efectuate asupra bazei de date şi
descrierea interacţiunii dintre tranzacţii şi entităţile de date;
 definirea cerinţelor nefuncţionale ale bazei de date, cum ar fi cele legate de
performanţe, integritate, securitate, administrarea datelor;
 specificarea platformei hardware şi software pe care va fi implementată baza de date.
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,

1. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco, 1999, p. 46-47.
şi nu se va opri asupra detaliilor privind modul în care sunt folosite în organizaţie ecranele,
rapoartele sau documentele.
Literatura2 recomandă mai multe modalităţi de formulare a întrebărilor astfel încât să se
obţină informaţiile necesare. În sinteză, ele pot fi redate astfel:
1. Ce obiecte/subiecte sunt într-o întreprindere? Ce tipuri de persoane, locuri, lucruri,
materiale ş.a. se folosesc sau interacţionează într-o unitate economică şi este necesară
culegerea datelor despre ele pentru a fi păstrate o anumită perioadă de timp? Câte
cazuri (instanţe) pot exista pentru fiecare obiect? – entităţi de date şi descrierea lor.
2. Ce caracteristică (caracteristici) unică (unice) ajută la diferenţierea obiectelor de
acelaşi tip? Elementul care ajută la diferenţierea obiectelor de acelaşi tip are caracter
permanent sau este unul temporar? Elementul caracteristic al unui obiect poate lipsi
atunci când noi ştim cu certitudine că obiectul există? – cheia primară.
3. Ce caracteristici se folosesc pentru descrierea fiecărui obiect? În ce mod se vor
efectua referirile, selecţiile, calificările, sortările şi clasificările obiectelor? Ce trebuie
să se ştie despre fiecare obiect astfel încât să se asigure buna funcţionare a unităţii? –
chei secundare.
4. Cum vor fi folosite datele nominalizate? Care este sursa datelor? Cine va face referire
la ele? Cine le poate modifica sau distruge? Cine nu are drept de folosire a lor? Cine
este responsabil cu corectitudinea datelor? – controale de securitate şi cunoaşterea
celor care au controlul semnificaţiei datelor.
5. Care ar fi perioada de apartenenţă a datelor ce ne interesează? Este necesară
cunoaşterea trendului datelor sau numai valoarea lor la un moment dat şi/sau valorile
estimate/proiectate ale lor? Când o caracteristică a unui obiect se schimbă în timp,
trebuie cunoscută ulterior valoarea anterioară? – cardinalitatea şi dimensiunea
temporală a datelor.
6. Toate cazurile („instanţierile”) sub care poate să existe un obiect sunt identice?
Există obiecte cu un comportament special în organizaţie? Există unele obiecte care
sintetizează sau reflectă forma combinată a altor obiecte mult mai detaliate? –
supertipuri, subtipuri şi agregări.
7. Ce evenimente contribuie la asocierea obiectelor între ele? Ce activităţi fireşti sau
care activități economice presupun folosirea datelor despre câteva obiecte de acelaşi
tip sau de tipuri diferite? – relaţiile, precum şi cardinalitatea şi gradul lor.
8. Fiecare activitate sau eveniment are aceeaşi formă de manifestare sau există şi forme
ce caracterizează anumite circumstanţe? Un eveniment presupune implicarea doar a
unor obiecte asociate sau acestea trebuie să existe în totalitate? Asocierile dintre
obiecte se schimbă de-a lungul timpului? Valorile ce scot în relief caracteristicile unor
date sunt exprimabile în cadrul unor limite? – reguli de integritate, cardinalitate
minimă şi maximă, dimensiunea temporală a datelor.
În afara tehnicilor enumerate anterior, 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.
În caseta 8.1 se regăseşte un model de descriere narativă pentru sistemul de gestiune a
clienţilor, prezentat în capitolele anterioare, însă el este uşor orientat spre cerinţele privind
datele. Pe baza lui, vom încerca să punem în evidenţă, pe parcursul paragrafelor următoare,
activităţile desfăşurate pentru construirea DER şi modul în care poate fi citită această
documentaţie.

2. Aranow, E.B. – „Developing Good Data Definitions”, in Database Programming & Design, 2, August 1988, pp.
36-39; Sandifer, A., Von Halle, B. – „A Rule by Any Other Name”, in Database Programming & Design, 4,
March 1991, pp. 11-13; Sandifer, A., Von Halle, B. – „Linking Rules to Models”, in Data and Knowledge
Engineering, 7, 1991, pp. 47-83.
 În cazul utilizării produselor CASE, construirea DER porneşte de la analiza diagramelor
fluxurilor de date şi a detaliilor cuprinse în depozitul de metadate.
Caseta nr. 8.1 – Descrierea cerinţelor sistemului de gestiune a clienţilor
A. Descrierea activităților/operațiilor şi a prelucrărilor din sistem
Principalele clase de operații înregistrate în sistemul de gestiune a clienţilor sunt:
1. Primirea comenzilor de la clienţi. Livrarea produselor se face numai în baza unei comenzi, emisă
de un client, iar o comandă poate conţine unul sau mai multe produse. La primirea comenzii,
sistemul va verifica situaţia contului pentru clientul respectiv şi existenţa unor stocuri suficiente
pentru produsele de livrat. În funcţie de rezultatele celor două operaţiuni de verificare, se va stabili
starea comenzii, respectiv de onorat, amânată sau respinsă. Din momentul acceptării comenzii, se
înregistrează obligaţia firmei de a o onora, conform termenelor de livrare specificate.
2. Onorarea comenzilor. În cazul în care comanda a fost acceptată, ea va fi onorată la termenul
specificat prin livrarea produselor şi a cantităţilor prevăzute, operaţiune înregistrată pe baza
facturii emise la depozit. Conform politicii firmei, nu se acceptă decât onorarea printr-o singură
livrare a întregii comenzi, însă pot exista situaţii în care printr-o singură livrare să fie onorate mai
multe comenzi, dar ale aceluiaşi client. De asemenea, întreaga livrare se va efectua de la un singur
depozit, chiar dacă un produs poate exista în stoc la mai multe depozite. Odată cu înregistrarea
livrării, se vor efectua următoarele operaţiuni de actualizare:
 modificarea stării comenzii în onorată, pentru ca sistemul să permită o evidenţă clară a
comenzilor onorate şi a celor de onorat;
 modificarea stocului pentru fiecare produs livrat, în sensul diminuării lui cu cantităţile livrate;
 modificarea soldului clientului, în sensul incrementării lui cu valoarea livrării.
 modificarea tipului clientului, dacă este prima livrare, iar clientul respectiv a fost înregistrat
anterior drept client potenţial.
3. Returnarea produselor de către clienţi. În cazul în care clientul constată unele defecţiuni la
produsele primite sau că ele nu corespund cu cele comandate, el va avea posibilitatea returnării
lor, însoţite de nota de refuz. Sunt posibile atât situaţia returnării parţiale, cât şi integrale, a
produselor livrate. Clientul este obligat să efectueze toate demersurile pentru returnare în cel mult
trei zile de la primirea produselor şi să specifice factura în baza căreia s-a făcut livrarea. În acest
fel, sistemul va fi în măsură să ofere informaţii despre livrările cărora le corespunde o returnare, în
vederea stabilirii persoanelor vinovate. În baza notei de refuz, pentru fiecare returnare se va
întocmi o factură de stornare, parţială sau integrală, de către depozitul care a emis factura, ce
corespunde unei singure livrări. Odată cu înregistrarea facturii de stornare, se va actualiza soldul
clientului şi stocul de produse.
Legendă: roşu = entitate; verde = relaţie; albastru = cardinalitate
B. Descrierea documentelor primare din sistem
În cadrul sistemului, se utilizează următoarele documente:
1. Comanda este emisă de client şi conţine următoarele categorii de date: datele de identificare a
comenzii (numărul şi data), datele de identificare a clientului (numele şi adresa), datele privind
produsele comandate (codul, denumirea, unitatea de măsură, cantitatea comandată) şi condiţiile de
livrare (termenul de livrare).
2. Factura reprezintă documentul de însoţire a produselor livrate şi conţine: datele de identificare a
facturii (număr şi data), datele de identificare a clientului (nume, adresa, cod fiscal, număr registru
comerţ), datele privind produsele livrate (cod, denumire, unitate de măsură, cantitate livrată, preţ,
valoare) şi alte date (valoare TVA, valoare totală factură). Acest document este utilizat şi pentru
consemnarea produselor returnate.
3. Nota de refuz este întocmită de client în cazul returnării parţiale sau integrale a produselor livrate.
Acest document conţine următoarele categorii de date: date de identificare a documentului (număr
şi data), datele de identificare a clientului (numele şi adresa), datele de identificare a produselor
returnate (cod, denumire, unitate de măsură, cantitate returnată) şi alte date (motivele returnării,
numărul facturii cu care au fost livrate anterior produsele).
C. Descrierea principalelor rapoarte generate de sistem
În urma solicitării utilizatorilor, sistemul va furniza următoarele rapoarte:
1. Raportul privind comenzile de onorat este elaborat la începutul fiecărei săptămâni şi conţine
informaţii despre comenzile ce urmează a fi onorate în săptămâna respectivă. Aceste informaţii se
 referă la: codul, numele şi adresa clientului; codul, denumirea şi unitatea de măsură a produselor;
cantităţile de livrat; data livrării.
2. Raport privind potenţialii clienţi, întocmit lunar sau la cererea conducerii, conţine informaţii
despre clienţii care au solicitat cataloage de produse, dar care nu au iniţiat încă nici o comanda de
cumpărare. În acest raport se includ numele şi adresa .
3. Raport privind vânzările, întocmit la cererea utilizatorilor, conţine informaţii despre livrările
efectuate într-o perioadă dată, pe depozite sau la nivelul firmei. În raport se includ codul şi numele
depozitului; numărul şi data facturii; codul, denumirea, unitatea de măsură şi preţul produselor;
cantităţile livrate; valoarea vânzării; totalul vânzărilor pe depozite şi totalul general al vânzărilor.

ATANASOV MIRELA

8.3 Introducere în cadrul conceptual al

diagramelor entitate-relaţie (DER)
Deşi diagramele entitate-relaţie (DER) se cunosc de către mulţi specialişti din lumea
bazelor de date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării
structurate şi, ca atare, provin din acest domeniu. De fapt, una din lucrările de referinţă ale lui
P.P. Chen, autorul modelului, este destul de relevantă: Entity-Relationship Approach to
Systems Analysis and Design (Metoda entitate-relaţie în analiza şi proiectarea sistemelor),
apărută în anul 1980, deşi modelul a fost conceput în anii 1976-1977.
După cum reiese și din citirea numelui diagramei, scopul ei este de a evidenţia entităţile
de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile ce există între ele.
De remarcat diferenţa dintre diagrama fluxului de date şi diagrama entitate-relaţie. În timp
ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât şi entităţile de date
(redate sub forma locurilor de stocare), DER tratează doar entităţile de date. Din această cauză,
DER poate fi considerată şi ca diagrama modelului datelor sau diagrama conceptuală a datelor.
În plus, DER evidenţiază şi descrie relaţiile dintre entităţile de date, aspecte ignorate în DFD.
Întotdeauna, crearea unei DER presupune găsirea răspunsului la întrebarea: „Care sunt
entităţile despre care sunt necesare datele de stocat?”. Răspunsul poate fi destul de simplu.
Depinde de aria de întindere a sistemului analizat. Ele ar putea fi: CLIENT, PRODUS,
SALARIAT, STOC, FURNIZOR ş.a.
În sistemul analizat, pentru descrierea DER se apelează la simbolul dreptunghi, pentru
fiecare entitate. Se recomandă ca numele entităţii să fie redat printr-un substantiv la singular
(CLIENT, PRODUS, SALARIAT etc.).
După ce se identifică entităţile, se continuă cu împerecherea lor, fiecare cu fiecare, pentru
a descrie ce relaţii există între ele. Relaţiile dintre entităţi pot fi reprezentate printr-un romb.
De exemplu, pentru a arăta că o anumită vânzare se referă doar la un client, deşi există
mult mai multe acte de vânzare, implicit mai mulţi clienţi, relaţia poate fi redată schematic ca
în fig. 8.2. Acest aspect face referire la cardinalitate, concept care va fi detaliat în unul din
paragrafele următoare şi care este pus în evidenţă prin cele două perechi de valori cuprinse
între paranteze.

(1,1) (0,M)
CLIENT
CLIENT Participă VÂNZARE

Fig. 8.2 DER pentru relaţia Participă între entităţile CLIENT şi VÂNZARE

O vânzare, la rândul ei, constă din unul sau mai multe produse, dar şi produsele pot
constitui subiecte ale mai multor vânzări, deci între entităţile VÂNZARE şi PRODUS ambele
perechi de valori ce reprezintă cardinalitatea vor conţine valoarea M (adică multe). Continuăm
cu descrierea legăturilor/relaţiilor posibile: un PRODUS este în legătură directă doar cu o
18 ANALIZA SISTEMELOR INFORMAŢIONALE

singură înregistrare STOC, şi invers. Antrenând în sfera discuţiilor şi comanda de

aprovizionare, COMANDĂ_APROVIZIONARE, şi furnizorul, FURNIZOR, s-ar putea
construi diagrama entitate-relaţie din fig. 8.3.
Entităţile conţin în structura lor atributele (caracteristicile) prin care ele sunt descrise. De
exemplu, entitatea CLIENT este descrisă prin intermediul atributelor nume, adresa, cod fiscal
etc. În acest caz se pune, firesc, întrebarea: dacă o entitate poate avea unul sau mai multe
atribute, relaţiile pot avea atribute? Dacă da, prin ce diferă ele de cele ale entităţilor?
Sublinierile sunt binevenite, întrucât problema pusă în discuţie este de o importanţă deosebită.
O serie de analişti fac distincţie netă între cele două tipuri de atribute, ale entităţilor şi ale
relaţiilor, în timp ce alţii nici nu le sesizează prezenţa. Elementele de derută provin şi din
existenţa unor entităţi despre care se poate spune că descriu relaţii. În exemplul de mai sus,
despre entitatea COMANDĂ_APROVIZIONARE se poate spune că deţine informaţii despre
relaţia „cumpărat de la” dintre PRODUS şi FURNIZOR. Concluzia la care se poate ajunge:
există entităţi „purtătoare” de relaţii dintre alte entităţi; deci, cu alte cuvinte, printr-o entitate se
poate prezenta o relaţie.

(1,1) (0,M)
CLIENT
CLIENT Participă VÂNZARE
VÂNZARE

(0,M)

Conţine

(1,M)

(0,1) (1,1)
STOC
STOC Are PRODUS
PRODUS

(1,M)

Conţine

(0,M)

(1,1) (0,M) COMANDĂ_

FURNIZOR Implică
FURNIZOR APROVIZIONARE

Fig. 8.3 Diagrama entitate-relaţie pentru

operaţiunea de vânzare-cumpărare

Analiza entitate-relaţie este o operaţiune deosebit de importantă pentru scoaterea în relief

a datelor, de fapt a structurii lor. În unele metodologii, cum ar fi „ingineria informaţiei”,
aceasta constituie principalul instrument analitic, în timp ce în altele analizele entitate-relaţie
se folosesc în combinaţie cu analizele fluxurilor de date.

8.4 Conţinutul şi etapele activităţii de modelare

conceptuală a datelor
După cum s-a putut observa anterior, DER este construită pe baza a trei tipuri de obiecte:
entităţi de date, relaţii între entităţi şi atribute care descriu entităţile şi relaţiile. Prin urmare,
modelarea conceptuală a datelor presupune parcurgerea următoarelor etape:
 identificarea entităţilor de date,
 descrierea entităţilor de date prin intermediul atributelor,
 definirea relaţiilor dintre entităţi şi
 descrierea relaţiilor, apelând la conceptele grad, cardinalitate, rol, atribut.
 În continuare, vom descrie pe larg fiecare din aceste etape, ocazie cu care vom introduce
atât conceptele, cât şi regulile pentru construirea DER.

8.4.1 Identificarea entităţilor de date

După exemplele date, considerăm că semnificaţia entităţii este destul de clară. Să spunem
doar că o entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul de
activitate al 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. Fiecărui tip de entitate i se atribuie un nume, conform
descrierilor şi exemplelor anterioare. Cât timp numele reprezintă o clasă sau un set de cazuri, el
este singular. Şi încă o convenţie. Cum referirea generală la elementele ce pot fi catalogate ca
entităţi se face prin noţiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi
proiectării orientate- obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se
vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător entităţii.
O instanţiere a entităţii sau o instanţă, numită de noi, î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 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 stocate în baza de date. Noi vom
utiliza termenii de entitate şi instanţă a entităţii.

BARONCEA ADRIANA
În sistemele informaţionale economice, majoritatea entităţilor de date pot fi clasificate în
trei categorii distincte3: resursele utilizate în cadrul firmei, evenimentele (activităţile
economice) în care este angajată firma şi agenţii participanţi la aceste evenimente.
Resursele sunt acele obiecte care au valoare economică şi care sunt necesare pentru
desfăşurarea activităţii din firmă. Stocurile de materii prime şi produse, mijloacele fixe,
disponibilităţile băneşti sunt exemple comune de entităţi-resursă.
Evenimentele se referă la activităţile economice care afectează resursele şi în legătură cu
care conducerea doreşte să se colecteze informaţii, în vederea exercitării funcţiilor de
planificare şi control. Majoritatea evenimentelor reţinute în DER se încadrează în una din
următoarele două categorii: activități/operații economice (economic exchanges) şi obligaţii-
angajamente (commitments). Activitățile economice sunt acele acțiuni care afectează în mod
direct resursele. De exemplu, operația de vânzare implică scăderea stocurilor, iar cea de
încasare va genera o sporire a disponibilităţilor băneşti. În schimb, angajamentele nu afectează
imediat nici o resursă, ele reprezentând o promisiune din partea firmei de participare la
activitatea viitoare. De exemplu, comanda primită de la un client va genera ulterior una sau mai
multe operații de vânzare. În afara faptului că aceste entităţi stochează date despre obligaţiile
firmei derivate din relaţiile de afaceri, ele sunt importante şi în activităţile de control şi
planificare. De regulă, astfel de evenimente preced activitățile economice, iar modelul
conceptual poate îngloba cerinţele de implementare a unor proceduri de control. De exemplu,
nu se va admite derularea unei operații de vânzare fără existenţa în prealabil a unei comenzi.
De asemenea, astfel de entităţi oferă informaţiile necesare activităţii de planificare. Pe baza
informaţiilor despre comenzi se va realiza planificarea vânzărilor.
Agenţii reprezintă persoane sau organizaţii care participă în evenimentele reţinute în
sistem şi în legătură cu care se doreşte memorarea de date, din considerente de planificare,
control sau evaluare. Angajaţii, clienţii sau furnizorii, băncile sunt exemple de entităţi-agent.

3. Romney, M.B., Steinbart, P.J. – Accounting Information Systems, 9th Edition, Prentice Hall, Upper Saddle River,
New Jersey, 2003, p. 116.
 Unii autori propun o a patra categorie de entităţi, respectiv locul în care se realizează un
eveniment, în timp ce alţii consideră că nu mai este necesară introducerea acestei categorii,
deoarece astfel de entităţi se referă adesea la resursele angajate în evenimentul respectiv 4 sau la
agenţii angajaţi într-un eveniment (completarea noastră). Exemple de astfel de entităţi sunt
depozite, secţie de producţie etc. Depozitul reprezintă locul în care este înregistrată o operație
de intrare sau ieşire a bunurilor materiale din stoc.
În afara acestor entităţi, să le spunem concrete, există şi alte entităţi care nu se încadrează
în nici una din cele trei categorii şi pe care noi le numim entităţi-abstracte. Entitatea
CONSUM-SPECIFIC, care memorează date despre consumurile specifice de materiale pentru
obţinerea fiecărei unităţi de produs finit, reprezintă un astfel de exemplu.
Identificarea entităţilor reprezintă o activitate dificilă, mai puţin formalizată. Realizarea ei
presupune citirea cu atenţie a documentaţiei sistemului, în special a părţii în care sunt descrise
activitățile şi prelucrările din sistem. Se vor urmări activitățile (evenimentele economice) în
legătură cu care se doreşte memorarea de informaţii sau documentele care le consemnează,
resursele şi agenţii implicaţi în derularea fiecărui eveniment reţinut în sistem. De exemplu, din
analiza documentaţiei prezentată în caseta 8.1, pentru evenimentul primirea comenzii se vor
reţine în sistem, pe lângă entitatea-eveniment Comanda, entitatea-agent Client şi entitatea-
resursă Produs.
Entităţile de date potenţiale sunt evidenţiate în caseta 8.1 prin utilizarea caracterelor de
culoare roşie. Ele vor fi trecute într-o listă separată, din care vor fi eliminate cele care se
repetă, fiind păstrată o singură dată, sau cele care apar sub nume diferite, cum este cazul pentru
livrare şi factură.
Rezultatul acestei activităţi este prezentat în caseta 8.2.
Caseta nr. 8.2 – Lista entităţilor de date pentru sistemul de gestiune a
clienţilor Entităţi-eveniment:
1. Comanda,
2. Livrare
3. Returnare
Entităţi-resursă:
4. Produs
Entităţi-agent:
5. Client
6. Depozit.

8.4.2 Descrierea entităţilor de date prin intermediul atributelor

Fiecare 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.
Iată câteva nume de entităţi şi unele dintre atributele lor posibile:
ANGAJAT: MARCA, NUME, CNP, ADRESA, MESERIA
CONT: SIMBOL, TIP, DENUMIRE
Ca şi numele entităţilor, numele atributelor sunt substantive scrise cu majuscule, 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 date despre
proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.
Entitatea ANGAJAT poate fi reprezentată în diagramă, conform unuia din modelele
prezentate în figura 8.4. În reprezentarea sub formă de tabel (figura 8.4.a), pe prima linie se

4. Romney, M.B., Steinbart, P.J. – op.cit., p. 117.

află numele entităţii, urmată de atributele care o descriu, primul reprezentând cheia primară,
scrisă cu caractere îngroşate.
CNP
NUME ADRESA

MARCA ANGAJAT
ANGAJAT MESERIA

a) reprezentarea sub formă de diagramă

ANGAJAT
ANGAJAT

MARCA
MARCA
NUME
NUME
CNP
CNP
ADRESA
ADRESA
MESERIA
MESERIA

b) reprezentarea sub formă de tabel

ANGAJAT(MARCA, NUME, CNP, ADRESA, MESERIA)

c) reprezentarea sub formă de listă

Fig. 8.4 Modele de reprezentare a entităţilor în DER

Cheie-candidat şi cheie-primară
O entitate este descrisă prin intermediul a două tipuri de atribute: identificatori (chei) şi
descriptori. Un identificator sau o cheie candidat este un atribut sau o combinaţie de atribute
prin care se poate identifica în mod unic un caz (o instanţă) a entităţii respective. Fiecare
entitate trebuie să aibă un identificator prin care să se efectueze diferenţierea instanţelor de
acelaşi tip. În schimb, descriptorii specifică proprietăţi ne-unice ale instanţelor unei entităţi.
Redăm mai jos, ca exemplu, entitatea ANGAJAT cu două instanţe. Ele au valori diferite
pentru caracteristica MARCA, aceasta fiind identificatorul entităţii (cheia primară), chiar dacă
este vorba despre doi angajaţi care au acelaşi nume.
MARCA NUME CNP ADRESA MESERIA
1001 Ion I Ion 1700806040021 Florilor, 54 Strungar
1002 Ion I Ion 1670904372271 Nationala,194 Sudor

Sunt entităţi care pot avea două sau mai multe chei-candidat. În exemplul nostru, pot fi
chei-candidat MARCA şi CNP. Atunci când sunt mai multe chei-candidat, analistul trebuie să
decidă care dintre ele va fi folosită drept cheie-primară. O cheie-primară este o cheie-candidat
care a fost selectată pentru a servi ca identificator al instanţelor în cadrul unei entităţi.
Selecţia cheii-primare trebuie efectuată după anumite proceduri 5, grupate în caseta 8.3.

Caseta nr. 8.3 – Proceduri de selecţie a cheii-primare

SELECŢIA CHEII-PRIMARE
1. Alegeţi o cheie-candidat care să nu-şi schimbe propria valoare în timpul vieţii cazului/instanţei entităţii
respective.
2. Alegeţi acea cheie-candidat care, pentru fiecare caz/instanţă al/a entităţii, garantează faptul că atributul
sau grupul de atribute are o valoare corectă şi nu este nulă.

5. Bruce, T.A. – Designing Quality Databases with IDEF1X Information Models, Dorset House Publications, New
York, 1992.
 3. De evitat aşa-zisele chei-secrete, care preiau în structura lor părţi ale unor atribute care semnifică
clasificări, locuri, coduri ş.a., întrucât ele se pot schimba frecvent, şi nici nu sunt publice.
4. Preferaţi formele scurte în locul celor complexe, formate din mai multe atribute, dacă este posibil.

BRANOAEA BEATRICE

În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce
formează cheia primară, numele respective se subliniază (vezi MARCA din entitatea
ANGAJAT). În cel de-al doilea model, prezentat în figura 8.4, cheia primară este plasată pe a
doua linie şi scrisă cu caractere îngroşate, după numele entităţii respective, iar în al treilea, ea
este subliniată.
Depistarea entităţilor unui sistem nu reprezintă o activitate tocmai uşoară. În multe situaţii
analistul trebuie să decidă dacă un obiect reprezintă o entitate sau un atribut al unei entităţi. Să
luăm, drept exemplu, obiectul LOCALITATE; el reprezintă o entitate sau un atribut? În
sistemul de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entităţii furnizor.
La clasificarea entităţilor şi atributelor, trebuie respectate următoarele două reguli:
 entităţile trebuie să conţină informaţii descriptive. Conform acestei reguli, dacă pentru
un obiect există informaţii descriptive (adică mai multe atribute care să o
caracterizeze), atunci el constituie o entitate, altfel acel obiect va reprezenta un atribut
al unei entităţi. Dacă pentru obiectul LOCALITATE sunt necesare mai multe
informaţii descriptive (cum ar fi judeţul, comuna, codul poştal etc.), atunci el trebuie
clasificat ca entitate. Dacă se solicită doar numele localităţii, atunci el va fi doar un
atribut al unei entităţi (cum ar fi FURNIZOR, ANGAJAT etc.).
 un atribut trebuie ataşat acelei entităţi pe care o descrie în modul cel mai direct. De
regulă, o proprietate se referă la o singură entitate, deci un atribut va fi regăsit doar la o
singură entitate. În sistemul de aprovizionare, de exemplu, entitatea COMANDA nu va
conţine nici numele furnizorului (sau codul acestuia), nici denumirea materialului (sau
codul acestuia); aceste atribute caracterizează mai direct entităţile FURNIZOR,
respectiv Material. Nu intră sub incidenţa acestei reguli sinonimele. Un exemplu, în
acest sens, poate fi atributul adresa: el poate caracteriza atât entitatea ANGAJAT, cât
şi entitatea FURNIZOR.
Aşadar, clasificarea unui obiect ca entitate sau atribut presupune analiza cu multă atenţie a
documentaţiei sistemului în care sunt formulate şi detaliate cerinţele informaţionale.
Identificarea atributelor descriptive ale entităţilor presupune, în primul rând, analiza
documentaţiei privind intrările şi ieşirile din sistem, respectiv a documentelor primare şi a
rapoartelor. Mai concret, în acestă activitate ne interesează cerinţele privind structura acestora.
Aşadar, în caseta 8.1, vor fi analizate părţile B şi C din documentaţie.
O atenţie deosebită trebuie acordată alegerii entităţii căreia îi va fi ataşat fiecare atribut.
Nu trebuie uitat că unele atribute nu reprezintă caracteristica nici unei entităţi, ci a unei relaţii
dintre entităţi, aşa cum este cazul atributelor cantitate comandată sau cantitate livrată. Mai
trebuie reţinut că fiecare atribut trebuie asociat unei singure entităţi şi că atributele calculate,
precum valoarea vânzării, nu vor fi păstrate în DER. Problema includerii câmpurilor calculate
se pune abia în faza proiectării fizice a bazei de date, ea urmând a fi discutată în capitolul
dedicat acestei teme în volumul următor.
Identificarea atributelor necesare sistemului este mult uşurată în cazul utilizării CASE,
deoarece se poate analiza direct structura fluxurilor care accesează locurile de stocare, puse în
evidenţă în diagramele fluxurilor de date.
După identificarea atributelor fiecărei entităţi, trebuie ales unul sau mai multe dintre
acestea care vor juca rolul de cheie primară (simplă sau compusă). Dacă nici unul dintre
atribute nu poate fi cheie, atunci se introduce un atribut special care să joace acest rol. O astfel
de situaţie găsim în exemplul nostru la entitatea Comanda.
Rezultatul acestei activităţi, pentru sistemul analizat, este prezentat în figura 8.5. Cheile
primare sunt evidenţiate prin caractere îngroşate.
 O problemă importantă legată de descrierea entităţilor se referă la completitudinea
modelului. Altfel spus, cum putem fi siguri că nu am omis nici un atribut necesar sistemului.
Rezolvarea acestei probleme este extrem de simplă în cazul utilizării produselor CASE,
majoritatea lor oferind facilităţi pentru a verifica dacă diagramele fluxurilor de date, pe de o
parte, şi DER, pe de altă parte, sunt balansate. În urma acestei verificări, analistul va putea să
vizualizeze o listă cu atributele din DER care nu sunt utilizate în diagramele fluxurilor de date
(adică nu apar în structura nici unui flux de accesare a locurilor de stocare), dar şi invers.
Produs
Client Comanda
CodProdus DenProdus UM CodClient CodComanda
StocCurent PretUnitar NumeClient NrComanda
Adresa DataComanda
CodFiscal TermenLivrare
Sold StareComanda
LimitaCredit
TipClient
Returnare
NrFactura DataFactura NrNotaRefuz DataRefuz Motivatie
Livrare Depozit
NrFactura
CodDepozit
DataFactura
NumeDepozit

Figura 8.5 Descrierea entităţilor sistemului de gestiune a clienţilor

8.4.2.1 Atribute cu valori multiple

Un atribut cu valori multiple poate să aibă mai mult decât o valoare pentru fiecare
caz/instanţă al/a tipului entităţii. De exemplu, atributul MESERIA poate lua valorile
ZUGRAV, MOZAICAR, FAIANŢAR, ZIDAR pentru o singură persoană (adică pentru o
singură instanţă a entităţii ANGAJAT). Din această cauză, în timpul proiectării conceptuale se
foloseşte un simbol sau o notaţie specială pentru a reflecta prezenţa atributelor cu valori
multiple sau multivaloare. Sunt utilizabile două modalităţi:
1. Folosirea liniilor duble pentru marcarea conturului elipsei, ceea ce s-ar concretiza într-
o diagramă ca în figura 8.6.
CNP
NUME ADRESA

MARCA ANGAJAT
ANGAJAT MESERIA

Fig. 8.6 Reprezentarea atributelor cu valori multiple în DER

2. Separarea datelor care se repetă într-o entitate distinctă şi va purta numele de entitate
slabă sau entitate atributivă. Ea va fi unită printr-o legătură de asociere de entitatea
iniţială.
Metoda este folosită şi în cazul câtorva atribute care se repetă laolaltă, formând un grup
repetat. Dacă aceleiaşi entităţi i-am asocia şi atributul ÎNTREŢINUT, care se referă la
persoanele aflate în întreţinere, fiecare dintre acestea fiind reperate prin
NUME_ÎNTREŢINUT, VÂRSTA_ÎNTREŢINUT, noua formă ar putea fi redată prin
modalităţile din figura 8.7, a) şi b).
CNP ADRESA

NUME MESERIA

MARCA ANGAJAT
ANGAJAT
NUME_ÎNTREÞINUT,, VÂRSTA ÎNTREŢINUT

a) Reprezentarea unui grup repetat, cu valori multiple, prin elipsă dublată

 CNP ADRESA
NUME_ÎNTREŢINUT VÂRSTA_ÎNTREŢINUT
NUME MESERIA

MARCA ANGAJAT
ANGAJAT Are ÎNTREŢINUT
ÎNTREŢINUT
(1,1) (0,M)

b) Reprezentarea unui grup repetat, cu valori multiple, printr-o entitate atributivă

Fig. 8.7 Modalităţi de redare în DER a grupurilor repetate cu valori multiple

Observaţi că separarea grupului repetat conduce la obţinerea unei relaţii a cărei

cardinalitate de partea entităţii atributive este „zero sau multe”, reflectând faptul că unui
angajat îi pot corespunde zero sau mai multe persoane aflate în întreţinere.

CARARE ANDREEA
8.4.3 Identificarea şi descrierea relaţiilor dintre entităţi
O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe
entităţi. Relaţiile nu au o existenţă fizică sau conceptuală, ci depind de entităţile asociate.
Altfel spus, existenţa relaţiilor depinde de existenţa entităţilor asociate (în schimb, existenţa
unei entităţi nu depinde de existenţa unei relaţii cu o altă entitate). Un caz particular al unei
relaţii se mai numeşte instanţa relaţiei sau ocurenţa relaţiei. Instanţa relaţiei se referă la
legătura dintre instanţele entităţilor asociate. De regulă, relaţiile sunt redate prin verbe şi sunt
simbolizate printr-un romb. Pentru simplificarea realizării DER, îndeosebi în produsele CASE,
nu se mai foloseşte un simbol anume pentru redarea relaţiei (cum este rombul), ci se scriu
verbele direct pe liniile care surprind existenţa relaţiilor dintre entităţi. Alteori, nici acestea nu
se mai scriu, relaţia fiind evidentă sau lăsată la interpretarea celui ce citeşte diagrama.
Exemple de relaţii sunt: EMITE, între entităţile FACTURA şi FURNIZOR; CONŢINE,
între entităţile FACTURA şi PRODUS; CONDUCE, între entităţile ANGAJAT şi
DEPARTAMENT sau orice verb care descrie conexiunea dintre entităţi. O instanţă a relaţiei
EMITE face referire la legătura dintre o anumită factură şi furnizorul care a emis-o.
Descrierea unei relaţii presupune specificarea următoarelor elemente: gradul (ordinul),
cardinalitatea, rolul şi eventualele atribute care o caracterizează. În continuare, ne vom opri pe
rând asupra fiecărui element descriptiv.
8.4.3.1 Gradul relaţiilor
Gradul unei relaţii (degree of a relationship) este dat de numărul de entităţi care participă
la relaţie. Cele mai întâlnite relaţii în modelele entitate-relaţie sunt:
 unare (grad unu), numite şi recursive sau relaţii ale entităţii cu ea însăşi; acest tip de
relaţie leagă două instanţe ale aceleiaşi entităţi.
 binare (grad doi); acest tip de relaţii sunt de departe cele mai întâlnite în lumea reală.
Mai mult, unele metode utilizează doar relaţii binare la construirea DER.
 ternare (grad trei); relaţiile ternare sunt mai rar întâlnite în lumea reală, ele fiind
utilizate atunci când nu este suficientă utilizarea relaţiilor binare pentru descrierea cu
acurateţe a semanticii relaţiei respective.
Pot exista relaţii cu grade şi mai mari, dar în practică acestea sunt foarte greu de întâlnit.
Cele trei tipuri de relaţii sunt prezentate în exemplul din figura 8.8 (cardinalitatea relaţiilor nu
a fost reprezentată). Asupra relaţiilor ternare vom reveni spre sfârşitul acestui capitol.

Este căsătorit cu
PERSOANA ANGAJAT
PERSOANA ANGAJAT Conduce

Unu-la-unu Unu-la-multe

a) Relaţie unară
 FURNIZOR Emite FACTURA
FACTURA
FURNIZOR

b) Relaţie binară

Fig. 8.8 Exemple de relaţii unare, binare, ternare

PIESA
PIESA

FURNIZOR DEPOZIT
FURNIZOR Transportat DEPOZIT

CANTITATE

c) Relaţie ternară
Fig. 8.8 Exemple de relaţii unare, binare, ternare
Referirea la gradul unei relaţii se mai face şi în alte moduri, cum ar fi ordin sau rang al
relaţiilor.

8.4.3.2 Cardinalitatea relaţiilor

Următorul concept utilizat pentru descrierea relaţiilor îl reprezintă cardinalitatea.
Presupunem că există două entităţi, A şi B, între care există o linie de legătură pentru a marca
relaţia. Cardinalitatea unei relaţii este dată de un număr al cazurilor/instanţelor entităţii B care
pot sau care ar putea să fie asociate cu fiecare caz al entităţii A. Pentru o relaţie dată, trebuie
specificată cardinalitatea pentru fiecare entitate asociată. Cardinalitatea relaţiei pentru o
entitate este sugerată printr-o pereche de valori, în cazul relaţiilor binare trebuind specificate
două astfel de perechi de valori. Valorile care compun o astfel de pereche semnifică:
 cardinalitatea minimă, pentru care sunt posibile valorile „0” sau „1”,
 cardinalitatea maximă, pentru care sunt posibile valorile „1” sau „M” (adică „multe”).
Trimiterea la cardinalitate se face în moduri destul de diferite, în funcţie de notaţia
folosită. Recomandăm citirea cu atenţie a diagramelor şi descifrarea elementelor strict necesare
înţelegerii, îndeosebi pentru reflectarea cardinalităţii. De exemplu, ea poate fi notată cu semne
(0, 1, M, N) sau prin simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de
săgeată pentru M. Alteori, 1 se reprezintă prin linie simplă şi M prin vârf de săgeată). În multe
materiale, inclusiv produse CASE, se foloseşte notaţia model-date, cunoscută mai mult sub
numele laba-gâştei, conform căreia cardinalitatea se reprezintă prin următoarele simboluri:
obligatoriu 1
opţional 0 sau 1

n obligatoriu multe (n; unde n ia valori de la 1 la M)

n opţional 0 sau multe (n poate lua valori de la 0 la M).
În continuare, vom utiliza semnele 0, 1, M şi N pentru reprezentarea cardinalităţii care,
considerăm noi, face o DER mai uşor de citit.
Să luăm drept exemplu relaţia emitere dintre entităţile FURNIZOR şi FACTURA,
prezentată în figura 8.9. Cardinalitatea minimă a relaţiei pentru entitatea FACTURA este „1”,
iar cea maximă este tot „1”; cardinalitatea relaţiei pentru entitatea FURNIZOR este „0”,
respectiv „M”. Prin urmare, în relaţia emitere, unui furnizor (care este o instanţă a entităţii
FURNIZOR) îi poate corespunde minim „0” şi maxim „multe” facturi (adică instanţe ale
entităţii FACTURA), în timp ce unei facturi îi corespunde un furnizor şi numai unul.
 Factura
Factura (0,M) (1,1) Furnizor
Emitere Furnizor

Figura 8.9 Cardinalitatea relaţiilor

Observaţi reprezentarea grafică inversă a cardinalităţii. Cardinalitatea entităţii FACTURA
este plasată lângă entitatea FURNIZOR şi invers. Aplicarea acestei reguli facilitează citirea
unei DER.
Clasificarea relaţiilor în funcţie de cardinalitatea maximă
O importanţă deosebită în proiectarea bazelor de date o prezintă clasificarea relaţiilor în
funcţie de cardinalitate, atât cea maximă, cât şi minimă. Astfel, în cazul relaţiilor unare
(recursive) şi al celor binare, vom avea trei tipuri de relaţii, în funcţie de cardinalitatea
maximă:
 relaţii de tipul 1:1 (unu-la-unu), adică o instanţă a entităţii X este asociată unei singure
instanţe a entităţii Y şi reciproc. Un exemplu se regăseşte în figura 8.10.
 relaţii de tipul 1:M (unu-la-multe), însemnând că o instanţă a entităţii X poate fi
asociată la n instanţe ale entităţii Y, în timp ce o instanţă a entităţii Y va fi asociată
doar unei singure instanţe a entităţii X. Acest tip de relaţii este cel mai des întâlnit în
lumea reală, un exemplu fiind deja prezentat în figura 8.9.
 relaţii de tipul M:N (multe-la-multe), care presupun că orice instanţă a entităţii X poate
fi asociată mai multor instanţe ale entităţii Y, iar o instanţă a entităţii Y poate, de
asemenea, să aibă asociate mai multe instanţe ale entităţii X (vezi figura 8.11).

(1,1) (0,1)
FACTURA Are RECEPŢIE
FACTURA

Figura 8.10 Relaţie de tipul 1:1(unu-la-unu)

(0,M) (1,M)
Conţine
FACTURA PRODUS

Figura 8.11 Relaţie de tipul M:N (multe-la-multe)

CHIRIAC LIDIA

Relaţii opţionale şi obligatorii

Uneori, relaţiile dintre entităţi nu-şi fac simţită prezenţa în toate situaţiile. Astfel, relaţiile
dintre entităţi pot fi clasificate după cardinalitatea minimă în două tipuri: relaţii opţionale şi
relaţii obligatorii. Altfel spus, participarea unei entităţi într-o relaţie poate să existe sau nu;
participarea opţională este pusă în evidenţă prin cardinalitatea minimă „0”, iar cardinalitatea
minimă „1” semnifică faptul că acea entitate este obligatoriu să participe într-o relaţie.
Cardinalitatea minimă are o semnificaţie importantă în proiectarea bazelor de date, ea
fiind legată de conceptul de restricţie de dependenţă6. Dacă existenţa instanţei x din entitatea
X depinde de existenţa instanţei y din entitatea Y, se spune că x este dependentă de y. Ea
indică dacă o instanţă dintr-o entitate trebuie legată de cel puţin o instanţă a entităţii aflate la
celălalt capăt al relaţiei. Cardinalitatea minimă „0” ne arată că pentru entitatea respectivă poate
exista o instanţă fără ca ea să fie legată de vreo instanţă a celeilalte entităţi. Dimpotrivă, în
cazul cardinalităţii minime „1” fiecare instanţă a entităţii respective trebuie să fie legată de cel
puţin o instanţă a celeilalte entităţi. Rezultă că ştergerea entităţii y atrage automat ştergerea

6. Korth, H.F., Silberschatz, A. – Sistemes de gestion de bases de donees, McGraw-Hill, Paris, 1988, citat în
Fotache, M. – Bze de date relaţionale. Organizare şi interogare, Ed. Junimea, Iaşi, 1996, p. 69.
entităţii x din baza de date. Se spune că existenţa instanţei x depinde de existenţa instanţei y.
Entitatea Y este denumită entitate dominantă, iar entitatea X este numită entitate dependentă.
Revenind la exemplul din figura 8.9, se observă că, în relaţia Emitere, entitatea
FACTURA are cardinalitatea minimă „1”, deci este obligatorie participarea oricărei instanţe
(facturi) într-o relaţie, în timp ce cardinalitatea minimă pentru entitatea FURNIZOR este „0”,
ceea ce înseamnă că nu este obligatorie participarea fiecărui furnizor în relaţia emitere (va
putea exista un furnizor care să nu aibă în corespondenţă nici o factură). De asemenea, putem
spune că entitatea FACTURA este dependentă de entitatea FURNIZOR, sau că FURNIZOR
este entitatea dominantă. Ştergerea unei facturi nu atrage automat şi ştergerea furnizorului care
a emis-o, deoarece este posibil ca în baza de date să mai rămână facturi primite de la furnizorul
respectiv. În schimb, ştergerea unui furnizor atrage după sine ştergerea tuturor facturilor
aferente acestuia. De asemenea, adăugarea unei facturi noi poate fi făcută numai dacă ea este
legată de un furnizor.
Cardinalitatea minimă poate fi redată şi grafic. Cercul suprapus pe latura entităţii indică,
de fapt, poziţia zero (valoarea minimă poate fi şi zero), conferind relaţiei caracterul opţional.
Simbolul folosit pentru a marca relaţiile obligatorii este acelaşi cerc, cu deosebirea că este
haşurat.
8.4.3.3 Rolul relaţiilor
Rolul defineşte funcţia care atrage două sau mai multe entităţi într-o relaţie. Pentru o
relaţie se poate specifica rolul fiecărei entităţi asociate, iar prin combinarea rolurilor jucate de
entităţile asociate se obţine numele relaţiei. De exemplu, revenind la relaţia dintre FACTURA
şi FURNIZOR, numele acestei relaţii poate fi descris sub forma emite/este emisă, după cum se
poate observa şi în figura 8.12. Rolul entităţii FURNIZOR este Emite, iar cel al entităţii
FACTURA este este emisă.
Factura
Factura (0,M) Emite/este emisa (1,1) Furnizor
Furnizor

Figura 8.12 Rolul relaţiilor

Specificarea rolurilor jucate de entităţi în DER nu prezintă o importanţă deosebită în
proiectarea bazelor de date, însă ajută la clarificarea aspectelor semantice ale modelării datelor,
precum şi la citirea relaţiilor. Relaţia dată poate fi citită în ambele sensuri, după cum urmează:
„Fiecare factură este emisă de un furnizor şi numai unul.”
„Fiecare furnizor emite 0 sau mai multe facturi.”
Toate relaţiile dintre entităţi pot fi exprimate sintetic prin două fraze scurte, fiecare fiind
inversa celeilalte, dar fiecare încadrându-se în forma generală:
„Fiecare nume-entitate
descrierea-relaţiei-lângă-entitate
marcaj-legătură-celălalt-capăt
celălalt-nume-entitate”.
În exemplul nostru, am utilizat două nume pentru a pune în evidenţă rolul fiecărei entităţi
în cadrul relaţiei. Unele metode recomandă utilizarea unui singur nume pentru o relaţie, stabilit
prin alegerea unui verb care să reflecte logica legăturii dintre entităţile respective. De exemplu,
pentru aceeaşi relaţie, în figura 8.8 am utilizat numele Emitere. În această variantă, rolul
fiecărei entităţi nu mai este specificat în mod explicit, însă el rezultă implicit din numele
atribuit relaţiei. În lipsa unui verb semnificativ pentru logica relaţiei, se poate alege un nume
format din iniţialele entităţilor asociate. În cazul în care se utilizează doar o linie simplă pentru
reprezentarea relaţiilor (fără simbolul romb), rolurile sunt plasate pe linie, de o parte şi/sau de
cealaltă a ei.
19 ANALIZA SISTEMELOR INFORMAŢIONALE

Necesitatea specificării rolului relaţiilor este evident atunci când între două entităţi există
mai multe relaţii. De exemplu, s-ar putea spune că „FURNIZOR oferă PRODUS”, dar şi
„PRODUS este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. nr. 8.13.
Oferă

(0,M) (0,M)

PRODUS FURNIZOR
PRODUS FURNIZOR

(0,M) (0,M)
Este cumpărat de la

Fig. 8.13 Descrierea relaţiilor multiple între două entităţi

8.4.3.4 Relaţii purtătoare de atribute (entităţi asociative)

În sfârşit, descrierea relaţiilor impune şi specificarea atributelor asociate, dacă ele există.
Considerăm concludente următoarele exemple:
1) Cazul prezentat la relaţia ternară, în figura 8.8(c). Se observă că relaţia ternară nu
înseamnă acelaşi lucru cu trei relaţii binare. De exemplu, atributul CANTITATE este asociat
relaţiei Transportă. Atributul nu poate fi asociat nici uneia dintre cele trei posibile relaţii
binare dintre cele trei tipuri de entităţi (FURNIZOR, PIESA, DEPOZIT), întrucât
CANTITATE reprezintă o valoare atribuită unei PIESA anume transportată de la un
FURNIZOR anume la un DEPOZIT anume.
2) Cazul „Are componente” (Has Components) al relaţiei unare multe-la-multe, redat în
figura 8.14.
(0,M)
Are componente
ARTICOL
ARTICOL CANTITATE

(0,M)
a) Relaţie unară multe-la-multe
A
A B
B

V V X
(1)X (2)Y (1) Y X X Y (2)Z
(1)Y Z (1)

U U (2)ZZ(1) U U (3)T T (1) U U (3)VV(1)

b) Două cazuri/instanţe ale relaţiei a)

Fig. 8.14 Relaţia unară de tip „Are componente”
Notă: Valorile din parantezele ataşate componentelor reprezintă cantităţile înglobate în componenta
superioară.

Să punem în discuţie un alt exemplu, cel al relaţiei Emite dintre entităţile FACTURA şi
PRODUS. Un produs poate fi conţinut în mai multe facturi, după cum şi o factură poate
conţine mai multe produse. Prezentăm, mai jos, câteva dintre datele concrete:
NUMĂR_FACTURĂ DENUMIRE_PRODUS CANTITATE
1111 Produs A 25
1111 Produs B 15
2222 Produs A 70
2222 Produs C 40
Din analiza cazurilor rezultă că factura 1111 conţine două produse, A şi B, cu cantităţi
diferite (25, respectiv 15), deci CANTITATE nu este o proprietate a entităţii FACTURA. Dar
nu este nici o proprietate a entităţii PRODUS, cât timp acelaşi produs poate fi conţinut în două
sau mai multe facturi cu cantităţi diferite (produsul A se regăseşte pe ambele facturi, cu
cantităţile 25 şi 70). În schimb, CANTITATE este o proprietate a relaţiei dintre FACTURA şi
PRODUS. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în figura 8.15.

CANTITATE

FACTURA (0,M) (1,M)

FACTURA Conţine PRODUS

Fig. 8.15 Asocierea unui atribut la o relaţie

De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau asociativă
care, de fapt, este o relaţie folosită de analist în model ca un tip de entitate. În astfel de cazuri,
se foloseşte un simbol special: dreptunghi cu romb în interior, în care se scrie numele entităţii
(fig. 8.16).

CANTITATE

(0,M) (1,M)
FACTURA
FACTURA Con
Con ţine PRODUS
PRODUS

Fig. 8.16 Redarea unei entităţi gerundive (asociative)

Relaţii purtătoare de atribute pot fi întâlnite doar în cazul relaţiilor de tipul „multe-la-
multe” sau al relaţiilor ternare. Relaţiile binare de tipul „unu-la-unu” sau „unu-la-multe” nu pot
avea atribute.

CURCA SOFIA

8.4.4 Modelul general al DER pentru sistemele informaţionale

În figura 8.17, este prezentat un model general al DER pentru sistemele informaţionale
economice, care evidenţiază relaţiile existente între cele trei tipuri de entităţi, precum şi
cardinalitatea tipică a acestor relaţii. Prin acest model 7 dorim să oferim un punct de plecare în
modelarea conceptuală a datelor din sistemele informaţionale economice şi construirea DER.
Desigur, trebuie luate în considerare şi analizate cu atenţie particularităţile ce pot interveni în
regulile de derulare a afacerilor din firme.

7. Modelul prezentat este adaptat şi completat după Romney, M.B., Steinbart, P.J. – op.cit.
 (1,1)
Particip ă Agent extern
Agent extern

(0,M)
(1, ?) (0,M) Obţinere resursã A
Obţinere
Resursa Intrare
AResursa A resursã A
(?,?) (1,1)
(0,M) Particip ă

intern
Agent intern

Dualitate
(0,M)
Particip ă(1,1)
Furnizare resursă B
Furnizare
Resursa Ieşire
BResursa B resursă B
(1, ?) (0,M)
(?,?) (0,M)

Particip ă Agent extern

(1,1)

Fig. 8.17 Modelul general al DER pentru sistemele informaţionale economice

În figura 8.17 se regăsesc toate cele trei tipuri de entităţi specifice sistemelor
informaţionale economice: evenimente, resurse şi agenţi. La identificarea entităţilor trebuie
acordată o atenţie deosebită obiectelor (evenimente, resurse sau agenţi) diferite dar omogene
(adică descrise de aceleaşi atribute), care pot fi reunite în aceeaşi entitate. De exemplu,
entităţile-resursă MATERIAL, OBIECT_INVENTAR_DEPOZIT şi PRODUS_FINIT pot fi reunite
în aceeaşi entitate, numită eventual BUN_MATERIAL, deoarece toate aceste resurse sunt
descrise de regulă prin aceleaşi atribute (Cod, Denumire, UM, Preţ, Stoc). Asemănător, pot fi
reunite entităţile-agent FURNIZORI şi CLIENŢI.
În modelul propus, se regăsesc trei tipuri de relaţii din punctul de vedere al entităţilor
implicate. În primul rând, fiecare entitate-eveniment este legată de o entitate-resursă. De
exemplu, entitatea-eveniment VÂNZARE este legată de entitatea-resursă PRODUS, pentru a
reflecta diminuarea stocului de produse finite. Un alt eveniment, COMANDA, care reflectă un
angajament pe viitor al firmei, va fi legat tot de resursa PRODUS, ce va fi afectată la o dată
ulterioară prin respectarea angajamentului.
În al doilea rând, fiecare entitate-eveniment este legată de două entităţi-agent. Agentul
intern este reprezentat de angajatul care are responsabilitatea gestionării resursei afectate sau a
autorizării evenimentului respectiv şi care, implicit, va avea dreptul să introducă sau să
modifice datele în baza de date. De regulă, ea este regăsită sub forma entităţii UTILIZATOR,
care va avea ca instanţe angajaţii firmei, inclusiv datele privind responsabilităţile acestora. Tot
ca agenţi interni se vor regăsi şi diferitele subunităţi organizatorice implicate în efectuarea
operațiilor interne. De exemplu, în evenimentul consum de materiale sunt implicate depozitul,
care eliberează materialele, şi departamentul care le solicită. Agentul extern se referă la terţul
din afara firmei care este implicat în derularea evenimentului respectiv. Entitatea-eveniment
VÂNZARE va fi legată de entitatea-agent CLIENT.
Al treilea tip de relaţie se referă la legăturile dintre entităţile-eveniment, care reflectă
natura economică duală a majorităţii evenimentelor din cadrul sistemelor informaţionale
economice de tipul intrare-ieşire. De exemplu, evenimentul VANZARE, care implică
decrementarea resursei PRODUS, este legat de evenimentul ÎNCASARE, care presupune
incrementarea resursei FOND_BĂNESC. Se reflectă astfel principiile de desfăşurare a
afacerilor care implică adesea consumarea unor resurse în vederea obţinerii altora. De
asemenea, pot să apară relaţii între entităţile-eveniment care reflectă un angajament pe viitor şi
cele care privesc activitățile economice realizate în baza angajamentului. O astfel de relaţie
este cea dintre entităţile COMANDA şi VÂNZARE. Prin introducerea unor asemenea relaţii în
modelul conceptual al datelor şi specificarea cardinalităţii, se poate arăta faptul că nu se
acceptă înregistrarea unei operații (vânzări) fără existenţa unui angajament anterior (comanda).
 Alte aspecte relevante privind modul de desfăşurare a afacerilor de către organizaţii sunt
reflectate prin cardinalitatea relaţiilor. În continuare, vom pune în discuţie cardinalitatea pentru
fiecare dintre cele trei tipuri de relaţii amintite anterior.
Cardinalitatea relaţiilor dintre entităţile agent şi eveniment
În figura 8.17 se poate observa că atât minimul, cât şi maximul cardinalităţii asociate
entităţilor-eveniment în fiecare relaţie eveniment-agent este 1 (după cum ştiţi deja,
cardinalitatea este reprezentată invers în diagramă). Această situaţie este întâlnită aproape
întotdeauna, reflectând faptul că trebuie să existe un agent, şi numai unul, care să fie implicat
în orice eveniment pentru ca organizaţia să evidenţieze responsabilitatea derulării
evenimentului respectiv. O instanţă VÂNZARE trebuie să aibă în corespondenţă un CLIENT şi
numai unul, astfel încât să se poată identifica în mod cert creanţa creată. Aceeaşi cardinalitate
va fi şi în relaţia cu agentul intern, pentru a se putea şti cu exactitate angajatul responsabil de
operaţia respectivă de vânzare.
Perechea (0,M) reprezintă cardinalitatea tipică asociată entităţii agent în relaţiile agent-
eveniment. Cardinalitatea maximă M asociată unui agent intern este pe deplin justificată,
deoarece este de aşteptat ca un angajat să autorizeze mai multe evenimente de un anumit tip
(de exemplu vânzări). De asemenea, un agent extern va avea cardinalitatea maximă M pentru
că organizaţia se angajează în relaţii de afaceri repetate cu acelaşi furnizor sau client.
Cardinalitatea minimă 0 este explicată prin două raţionamente. Mai întâi, organizaţia doreşte să
poată adăuga date despre un client sau furnizor chiar dacă el nu a fost implicat încă în nici un
eveniment. Cel de-al doilea motiv este legat de faptul că entităţile-eveniment reprezintă de fapt
fişiere de tranzacţii (sau temporare), în timp ce entităţile-agent sunt fişiere nomenclatoare (sau
permanente). La anumite intervale regulate de timp (de exemplu, la sfârşitul anului), conţinutul
fişierelor de tranzacţii este şters după ce s-a efectuat arhivarea, în timp ce informaţiile despre
agenţi sunt permanente. Prin urmare, la începutul unei perioade de timp (de exemplu, la
începutul anului) nici un agent nu va avea în corespondenţă vreun eveniment.
Cardinalitatea relaţiilor dintre entităţile resursă şi eveniment
După cum rezultă din figura 8.17, perechea (0,M) este cardinalitatea tipică asociată
entităţilor-resursă în relaţiile resursă-eveniment, din aceleaşi motive prezentate anterior pentru
entităţile-agent. Un anumit produs poate face obiectul mai multor operaţii de vânzare, la fel
cum poate să nu se regăsească pe nici una.
Cardinalitatea minimă asociată entităţilor-eveniment este de regulă 1, ceea ce înseamnă că
fiecare eveniment trebuie să implice cel puţin o instanţă a entităţii-resursă cu care este în
legătură, adică el va afecta cel puţin o resursă. O vânzare va conţine cel puţin un produs, iar o
încasare va afecta cel puţin un cont de disponibilităţi. Excepţii de la această regulă generală
apar în cazul relaţiilor alternative dintre entităţi, însă aceste tipuri de relaţii le vom prezenta în
paragraful următor. În schimb, nu există o regulă generală în ce priveşte cardinalitatea maximă
asociată entităţilor-eveniment, motiv pentru care am apelat la simbolul „?”. Ea depinde de
natura resursei implicate sau de regulile de desfăşurare a afacerilor din organizaţie. De
exemplu, o încasare va avea în corespondenţă un singur cont de disponibilităţi băneşti
(cardinalitatea maximă va fi 1), în timp ce o vânzare poate conţine mai multe produse
(cardinalitatea maximă va fi M).

DUPALAU ROBERT
Cardinalitatea relaţiilor dintre entităţile eveniment
Pentru relaţiile dintre două entităţi-eveniment orice cardinalitate este posibilă, neexistând
reguli generale, tipice. Totuşi, o regulă ce poate fi reţinută pentru relaţiile dintre două
evenimente este cea care relevă caracterul temporal: cardinalitatea minimă a evenimentului
care se realizează primul în timp va fi 0, deoarece la momentul respectiv celălalt eveniment nu
a avut loc; cel mai adesea, dar nu întotdeauna, cardinalitatea minimă corespunzătoare celui de-
al doilea eveniment ca desfăşurare în timp va fi 1, reflectând faptul că desfăşurarea celui de-al
doilea eveniment poate avea loc numai dacă primul eveniment s-a realizat anterior. Pentru
exemplificare, să luăm relaţia dintre evenimentele COMANDA şi VÂNZARE: ca ordine de
desfăşurare, operaţiunea de vânzare are loc după primirea comenzii, deci entitatea COMANDA
va avea cardinalitatea minimă 0, dat fiind că operaţiunea de vânzare are loc ulterior şi, până
atunci, comanda respectivă nu va avea în corespondenţă nici o vânzare, iar entitatea
VÂNZARE va avea cardinalitatea minimă 1. Totuşi, dacă regulile afacerii din organizaţie
acceptă derularea de vânzări fără primirea unei comenzi ferme în prealabil, atunci şi
cardinalitatea minimă asociată entităţii VÂNZARE va fi 0.
Acum, după ce ne-am familiarizat cu conceptele utilizate pentru descrierea relaţiilor dintre
entităţi, precum şi cu modelul general al DER pentru sistemele informaţionale economice,
suntem în măsură să finalizăm DER-ul pentru sistemul nostru. Rezultatul este prezentat în
figura 8.18.
Câteva comentarii mai sunt necesare în legătură cu modul de construire a diagramei.
Mai întâi, identificarea relaţiilor dintre entităţi reprezintă o activitate extrem de
anevoioasă, solicitând multă experienţă din partea analistului. Dificultatea este cu atât mai
mare, cu cât în diagramele fluxurilor de date şi în depozitul de date nu se face nici o referire la
relaţiile dintre entităţi. Singurul model care le evidenţiază este diagrama entitate-relaţie. Pe de
altă parte, orice relaţie specificată în plus sau în minus va avea consecinţe, uneori grave, asupra
proiectării bazei de date. Un demers mai formal nu există, aşa că nu ne rămâne decât să citim
cu multă atenţie documentaţia sistemului.
În caseta 8.1, partea de text care sugerează relaţii între entităţi este scrisă cu caractere de
culoare verde. Acelaşi text va sugera şi rolul (numele) fiecărei relaţii.
În al doilea rând, după identificarea unei relaţii, se va mai citi o dată textul pentru a
desprinde informaţiile necesare pentru stabilirea cardinalităţii relaţiei. În cazul în care nu
găseşte astfel de informaţii, analistul va trebui să le afle şi să completeze documentaţia.
În al treilea rând, se poate observa că, odată cu introducerea relaţiilor, s-au specificat şi
atributele asociate relaţiilor.
În caseta 8.1, informaţiile relevante pentru stabilirea cardinalităţii relaţiilor sunt scrise cu
caractere de culoare albastră.
Odată ce am obţinut forma finală a DER pentru sistemul nostru, se cuvine să mai zăbovim
un pic asupra legăturii dintre diagrama fluxurilor de date şi DER. Dacă vom compara diagrama
din figura 8.18 cu diagrama de nivel 0 din caseta 5.4, vom constata că există multe asemănări,
dar şi unele diferenţe. Între cele două modele există o legătură directă, în sensul că entităţile de
date se vor regăsi în diagrama fluxurilor de date sub forma locurilor de stocare. În general, se
poate urmări obţinerea unei relaţii biunivoce între mulţimea entităţilor de date şi cea a locurilor
de stocare, dar nu este obligatorie.
Dacă DER conţine prea multe entităţi, prevederea a câte unui loc de stocare pentru fiecare
din ele ar spori complexitatea şi încărcarea diagramelor fluxurilor de date, nu doar prin
numărul mare de locuri de stocare, ci şi printr-un număr mult mai mare de fluxuri de accesare a
lor. Aşadar, se poate opta pentru gruparea logică a două sau mai multe entităţi, cărora să le
corespundă un singur loc de stocare. În exemplul nostru, entităţile Livrare, Returnare şi
Produs au fost reunite într-un singur loc de stocare, Nomenclator produse.
 Comanda
Returnare
CodComanda NrComanda DataComanda TermenLivrare StareComanda Livrare Returnare DataRefuz Motivatie
NrFactura DataFactura NrNotaRefuz
(1,M) Onorare (0,1) Livrare (1,1) Corespunde (0,1) NrFactura
NrFactura
NrFactura
DataFactura DataFactura
DataFactura NrNotaRefuz
(0,M) (0,M) DataRefuz
(0,M) Motivatie
(0,M)
Cantitate returnata
Emite
Emite Conţine
Stoc curent

(1,1) Depozit (1,M)

(1,M)
Client Client CodDepozit Produs
NumeDepozit Este în stocCodProdus DenProdus UM
CodClient CodClient CodProdus
NumeClientNumeClient PretUnitar
(0,M) DenProdus
Adresa Adresa UM
CodFiscalCodFiscal Conţine (1,1) PretUnitar
Sold Sold (1,M)
Depozit
LimitaCredit
LimitaCredit
CodDepozit
TipClient TipClient
NumeDepozit
Cantitate comandata

Figura 8.18 Diagrama entitate-relaţie pentru

sistemul de gestiune a clienţilor

Pe de altă parte, se poate observa că există locuri de stocare care nu-şi găsesc
corespondentul în DER, cum ar fi Promoţii şi Catalog. Explicaţia este următoarea: funcţiile
(procesele de prelucrare) care accesează acele locuri de stocare nu sunt vizate pentru
informatizare, deci nu prezintă interes imediat din perspectiva dezvoltării sistemului
informatic. Prin urmare, s-a considerat că nu este nevoie de memorarea datelor în legătură cu
cele două entităţi. Aceste date se vor regăsi doar pe hârtie.
Legătura strânsă dintre cele două tipuri de diagrame, şi într-un sens, şi în celălalt, reclamă
construirea lor în paralel. Se va începe mai întâi cu diagrama fluxurilor de date pentru a pune
în evidenţă principalele funcţii şi procese din sistem, însă, când se ajunge la un nivel suficient
de detaliere, se poate trece la construirea DER. Apoi se revine cu modificări şi completări
asupra diagramei fluxurilor de date. Astfel de treceri, de la un model la altul, vor fi realizate ori
de câte ori este nevoie.

ENACHE IONELA
8.4.5 Alte situaţii întâlnite în modelarea conceptuală a datelor
Scopul diagramelor entitate-relaţie este de a surprinde cele mai complete sensuri posibile
ale datelor necesare sistemului informaţional din organizaţie. Aplicarea tuturor conceptelor
prezentate anterior permite descrierea suficient de clară a entităţilor şi relaţiilor identificate în
domeniul analizat, însă, problematica poate fi mult mai amplă decât a fost redată în capitolul
de faţă. În acest paragraf, vom reda alte câteva situaţii ce pot fi întâlnite în lumea modelată şi
maniera în care ele pot fi reprezentate în DER.
8.4.5.1 Cardinalitatea relaţiilor ternare
Dacă, în cazul unei relaţii de ordinul 2, avem trei tipuri de relaţii din punctul de vedere al
cardinalităţii maxime, pentru relaţiile ternare vom avea patru tipuri de relaţii: 1:1:1 (unu-la-
unu-la-unu), 1:1:M (unu-la-unu-la-multe), 1:M:N (unu-la-multe-la-multe) şi M:N:P(multe-la-
multe-la-multe). Generalizând, se poate afirma că o relaţie de ordinul n va înregistra n+1 tipuri
de relaţii din punctul de vedere al cardinalităţii maxime, cu excepţia relaţiilor unare.
 Disciplina
Disciplina

Examineaza
Profesor Student
Profesor 1 N Student

Fig. 8.19 Exemplu de relaţie ternară de tipul 1:M:N

În figura 8.19 este prezentată un exemplu de relaţie ternară de tipul 1:M:N. Această relaţie
poate fi citită astfel:
„un profesor poate examina un student la mai multe discipline” (de aici M-ul din partea
entităţii DISCIPLINA),
„un profesor examinează la o disciplină mai mulţi studenţi”,
„un student este examinat la o disciplină de un singur profesor”.
Se observă că, la determinarea cardinalităţii, se ia în considerare numărul maxim (unu sau
multe) de instanţe ale unei entităţi care corespund unei perechi formate din câte o instanţă a
celorlalte două entităţi. De exemplu, întrebarea poate fi formulată astfel: Câte discipline pot
corespunde unui anumit profesor şi unui anumit student?
8.4.5.2 Relaţii redundante
Două sau mai multe relaţii sunt considerate redundante atunci când ele sunt utilizate
pentru a reprezenta acelaşi concept. Un exemplu de relaţie redundantă este cea dintre
FURNIZOR şi DOCUMENT_PLATĂ din figura 8.20. Această relaţie este mai curând una
indirectă, dacă plăţile sunt urmărite pe fiecare factură în parte. În momentul în care unei plăţi i
se asociază o anumită factură, implicit i se va asocia şi furnizorul care a emis factura
respectivă, prin intermediul legăturii dintre entităţile FURNIZOR şi FACTURA. Dacă s-ar ţine
o evidenţă globală a datoriilor către furnizori, neinteresând factura ce este plătită, ci doar
furnizorul, atunci ar trebui eliminată relaţia dintre FACTURA şi DOCUMENT_PLATĂ.
Oricum, indiferent de tipul de evidenţă utilizat în firmă, una din cele două relaţii trebuie
eliminată. Existenţa unei relaţii redundante poate fi sesizată şi din urmărirea rolurilor celor trei
relaţii, observându-se că ambele relaţii au acelaşi nume, respectiv Se plăteşte.
FURNIZOR (1,1) Se plăteşte DOCUMENT_
(0,M) DOCUMENT_ PLATĂ
FURNIZOR
PLATĂ
(1,1) (0,M)

(0,M) FACTURA (1,M) Se plăteşte

Emite FACTURA

Fig. 8.20 Exemplu de relaţie redundantă

În schimb, în figura 8.21 nici una dintre cele trei relaţii nu este redundantă atât timp cât
membrii unei asociaţii pot locui în altă localitate decât cea în care îşi are sediul asociaţia. Dacă
ar exista restricţia ca toţi membrii unei asociaţii să locuiască în localitatea de reşedinţă a
asociaţiei, atunci relaţia dintre MEMBRU şi LOCALITATE ar fi redundantă.
MEMBRU (0,M) (1,1) LOCALITATE
MEMBRU Locuieşte LOCALITATE

(1,M) (1,1)

(0,M) ASOCIAŢIE (0,M) Are Sediul în

Aparţine ASOCIAŢIE
 Fig. 8.21 Exemplu de relaţii neredundante
Pentru o mai bună clarificare, revenim la sistemul de gestiune a relaţiilor cu clienţii şi la
DER prezentată în figura 8.18. La o primă vedere, s-ar putea considera că unele relaţii au fost
omise. Este vorba, îndeosebi, despre relaţia dintre entităţile Livrare şi Client, considerându-se
că, prin lipsa ei, nu se va putea şti care este clientul către care s-a efectuat o anumită livrare.
O astfel de observaţie nu ar fi tocmai corectă, atât timp cât între entităţile Livrare şi Comandă,
pe de o parte, Comanda şi Client, pe de altă parte, există relaţii. Vom putea face legătura între
o livrare şi un client, dar indirect, prin intermediul entităţii Comanda.
Observaţia ar fi fost întemeiată dacă firma ar fi acceptat livrări şi fără primirea prealabilă
a unei comenzi. Într-o asemenea situaţie, legătura indirectă între client şi livrare nu mai poate fi
stabilită, atât timp cât comanda poate să lipsească. Atunci, cardinalitatea relaţiei dintre Livrare
şi Comanda ar trebui modificată, în sensul înlocuirii cardinalităţii minime „1”, aflată în partea
entităţii Comanda, cu „0”, şi adăugării relaţiei dintre entităţile Livrare şi Client.
Să mai spunem că relaţii redundante pot apare numai în modelul fizic al datelor, în scopul
creşterii vitezei de acces la baza de date. Însă, acum ne aflăm abia în faza elaborării modelului
conceptual al datelor.

Rezumat
Aplicarea principiului abstractizării presupune modelarea datelor pe trei niveluri: conceptual, logic
şi fizic. Modelarea pe aceste trei niveluri de abstractizare este justificată de necesitatea stăpânirii
complexităţii sistemului, analistul având posibilitatea de a se concentra, la un moment dat, doar asupra
anumitor aspecte, ignorându-le momentan pe celelalte. În faza de analiză se efectuează doar modelarea
conceptuală a datelor, celelalte două modele fiind realizate pe parcursul fazei de proiectare.
Modelarea conceptuală a datelor presupune transpunerea exactă a realităţii din domeniul analizat,
fără a lua în considerare cerinţele specifice unui model de organizare a datelor sau criteriile de
performanţă privind stocarea şi accesarea datelor. Modelul rezultat trebuie să reflecte regulile de derulare
a afacerilor în firma respectivă sub forma entităţilor de date şi a legăturilor dintre ele.
Pentru reprezentarea modelului conceptual se apelează la diagrama entitate relaţie (DER),
construită prin utilizarea a trei tipuri de obiecte: entităţi de date, relaţii între entităţi şi atribute.
Realizarea DER implică parcurgerea a patru etape: identificarea entităţilor de date, descrierea lor prin
intermediul atributelor, definirea relaţiilor dintre entităţi şi descrierea lor prin specificarea eventualelor
atribute, dar şi prin apelarea la conceptele grad, cardinalitate şi rol.
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. Entităţile pot fi încadrate în una
din următoarele patru categorii: resurse, evenimente, agenţi şi entităţi-abstracte.
O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe entităţi, ea
neavând o existenţă fizică sau conceptuală de sine stătătoare, ci depinde de entităţile asociate. Din acest
motiv, identificarea relaţiilor reprezintă o activitate dificilă, care solicită multă experienţă şi atenţie.
Odată identificate, relaţiile sunt descrise prin intermediul gradului, cardinalităţii, atributelor şi rolului.