2 MODELAREA CONCEPTUALĂ A DATELOR

2.1 Modelul Entitate-Asociere (EA)

Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care sunt
folosite ca suport al unei metodologii de proiectare. Un model conceptual este un ansamblu de concepte
şi reguli de combinare a acestor concepte permiţând reprezentarea realităţii circumscrise domeniului
supus informatizării.
Modelele utilizate se numesc modele semantice şi au drept obiectiv ca prin conceptele oferite să
permită reprezentarea lumii reale.
Modelele semantice utilizează abstracţii reprezentând lumea reală ca pe o colecţie de entităţi şi de
legături, stabilite între acestea. Majoritatea modelelor permit definirea de restricţii descriind aspectele
statice, dinamice sau chiar temporale ale entităţilor. Modelul entitate-asociere (EA) pe care îl vom utiliza
în continuare pentru definirea modelului conceptual al datelor este şi el un model semantic.

Sistem
informaţional
Proceduri
Informaţii

Documentare şi
analiză

Informaţii şi Proceduri şi reguli de

legături dintre gestiune
informaţii

Modelare

Modelul conceptual al Modelul conceptual al

datelor prelucrărilor
- date (MCP)
- tipuri de entităţi
- asocieri între
entităţi

Figura 2.1 Procesul de modelare a datelor

şi prelucrărilor

Modelul EA urmăreşte obţinerea unei reprezentări fidele, utilizând concepte specifice, a realităţii
(problemei de rezolvat ce urmează a fi informatizată). Această reprezentare a lumii reale se va realiza
făcându-se abstracţie de orice restricţie fie ea informatică sau organizatorică. Pornind de la semantica
obiectelor lumii reale şi a legăturilor stabilite între acestea modelul EA serveşte în egală măsură ca un
mijloc de comunicare între modelator (informatician) şi viitorul utilizator al sistemului (beneficiarul
sistemului informatic), care descrie realitatea supusă modelării în conformitate cu propria lui percepţie.
 Concepte de bază ale modelului Entitate Asociere
ENTITATEA reprezintă un obiect al realităţii modelate caracterizat printr-o existenţă proprie, cu o
identitate proprie (care-l face identificabil în raport cu celelalte obiecte de acelaşi tip) şi o mulţime de
caracteristici care exprimă proprietăţile acestuia.
Pentru exemplificare vă propunem ca domeniu de studiu gestiunea poliţelor încheiate de o
societate de asigurări. Entităţile pe care le putem defini sunt: o poliţă de asigurare, instrumente de plată,
etc.
Entitatea poliţă de asigurare nr. 25 se defineşte prin următoarele realizări ale caracteristicilor:
15/03/2002 (data încheierii), Ionescu Costel (numele agentului de asigurare), Popescu Marius (titularul
poliţei de asigurare), 22/03/2002 (data inceperii perioadei asigurate), etc. Entitatea poliţă de asigurare
nr. 25 are propria identitate, distingându-se clar de celelalte entităţi de acelaşi tip (celelalte poliţe
încheiate) prin numărul său şi are o existenţă de sine stătătoare (Figura 2.2).

25 27 117
15/03/2002 10/03/2002 11/03/2002
Ionescu Costel Ionescu Costel Ion Dan
Popescu Marius Popescu Ion Manea Marian
22/03/2002 17/03/2002 18/03/2002

Figura 2.2 Entităţi aparţinând tipului de entitate poliţă de asigurare

În activitatea de modelare interesul se focalizează pe definirea tipurilor de entităţi aparţinând
problemei de rezolvat şi nu pe entităţi care reprezintă realizările tipurilor de entităţi. În locul noţiunii de tip
de entitate, unii autori folosesc conceptul de clasă de entităţi. Modelul abstract pe care ni-l oferă modelul
EA se bazează tocmai pe aceste tipuri generice de entităţi şi a legăturilor stabilite între acestea.
TIP DE ENTITATE reprezintă un concept generic desemnând mulţimea tuturor entităţilor
prezentând aceleaşi caracteristici constructive.
Exemple : produs, comandă, angajat, student, contract, poliţă de asigurare, depozit bancar, ordin
de tranzacţionare la bursă etc.
De această dată tipul de entitate produs desemnează ansamblul produselor aflate în catalogul
firmei, produse descrise plecând de la aceleaşi caracteristici comune: codul produsului, denumirea,
unitatea de măsură, data omologării, procent TVA.
Tipul de entitate student desemnează ansamblul studenţilor caracterizaţi prin aceleaşi trăsături
comune: număr matricol, nume, data-naşterii, localitatea, facultatea, specializarea etc.
POLIŢĂ DE
ASIGURARE TIP DE ENTITATE

Număr ATRIBUTE
Data încheierii
Agentul
Beneficiarul
Data începerii Realizări ale
ENTITĂŢI atributelor

25 27 117
15/03/2002 10/03/2002 11/03/2002
Ionescu Costel Ionescu Costel Ion Dan
Popescu Marius Popescu Ion Manea Marian
22/03/2002 17/03/2002 18/03/2002

Figura 2.3 Entităţi aparţinând aceluiaşi tip

 Atenţionăm asupra faptului că o entitate poate aparţine mai multor tipuri de entităţi diferite. De
exemplu, entitatea cititorului Ionescu poate aparţine şi tipului de entitate profesor şi tipului de entitate
doctoranzi (desemnând ansamblul persoanelor care urmează forma de pregătire doctorală).
Fiecare tip de entitate se defineşte prin mulţimea caracteristicilor comune entităţilor aparţinând
tipului.
ATRIBUTUL defineşte o proprietate distinctă a unei entităţi. Fiecare atribut prezintă un domeniu,
adică o mulţime de valori admise. Într-o entitate se regăsesc realizări corespunzătoare caracteristicilor
definitorii pentru tipul de entitate.
Atributele pot fi clasificate în funcţie de mai multe criterii:
a) După complexitate atributele sunt:
• elementare (simple) ale căror realizări nu pot fi descompuse (exemplu: unitate monetară, preţ unitar,
număr matricol al studentului, marca angajatului, etc).
• decompozabile (complexe) ale căror realizări sunt decompozabile (ex: data calendaristică – se poate
descompune în zi, lună, an; adresa - se poate descompune în stradă, număr, codul de clasificare al
unui mijloc fix, etc).
b) După realizările pe care le pot prezenta atributele pot fi:
1) • obligatorii (trebuie să prezinte obligatoriu o realizare, ceea ce corespunde sintagmei NOT NULL –
orice realizare).
• opţionale ( sunt atribute care pot să nu prezinte nici o valoare (realizare) în cadrul unei entităţi (de
exemplu atributele: telefon, fax, e-mail - nu toate persoanele au telefon, fax, adresă e-mail).
2) • monovaloare: atribute care prezintă o singură valoare în cadrul unei entităţi (exemplu: nume
student, nr. matricol, data naşterii, codul numeric personal etc).
• multivaloare: atribute care prezintă mai multe realizări în cadrul aceleiaşi entităţi (de exemplu, în
tipul de entitate ANGAJAT, entitatea Popescu Marius poate prezenta pentru atributul STUDII mai
multe valori: Facultatea de Mecanică, Facultatea de Finanţe Asigurări Bănci şi Burse de Valori).

CONT BANCAR

Nr. Cont
Tip Cont
Data Deschiderii
Limită credit
Moneda

Figura 2.4. Tipul de entitate Cont Bancar

Problema de modelat este adesea deosebit de complexă în cadrul ei putându-se identifica obiecte
simple, compozite şi/ sau complexe.
În modelul EA obiectelor lumii reale le corespund entităţi, iar entităţile definite prin aceleaşi
caracteristici formează un tip de entitate.
Aceasta înseamnă că obiectelor simple le va corespunde în modelul conceptual al datelor câte
un tip de entitate.
Exemplu: pentru conturile deschise de o bancă se poate defini în cadrul modelului conceptual al
datelor tipul de entitate cont bancar (Figura 2.4).
Clienţilor (persoane fizice) ai unei bănci, deoarece sunt definiţi prin aceleaşi caracteristici (nume
client, cod numeric personal, cod de identificare în cadrul băncii, adresa etc), le va corespunde în
modelul EA un singur tip de entitate, numărul de realizări ale acestuia (de entităţi) fiind egal cu numărul
clienţilor.
Obiectele compozite se caracterizează prin faptul că ele conţin una sau mai multe caracteristici
multivaloare (cărora în modelul EA le vor corespunde atribute multivaloare). Aceasta va determina ca în
modelul conceptual optimizat al datelor acestui obiect compozit să-i corespundă mai multe tipuri de
entităţi (atributele multivaloare se vor regăsi într-un tip de entitate distinct).
 Exemplu:
Documentelor bonuri de consum le va corespunde tipul de entitate bon de consum definit prin
atributele monovaloare: număr bon, data bon, secţia, gestiunea dar şi atributele multivaloare: cod
material, cantitate eliberată, preţ unitar. Aceasta face ca tipul de entitate bon de consum, definit iniţial
prin mulţimea tuturor atributelor mai sus menţionate, să conducă în final la definirea a două tipuri de
entităţi: Bon de consum (documentul în sine) definit prin atributele: număr bon, data bon, secţia,
gestiunea şi tipul de entitate Material eliberat definit prin atributele: cod material, cantitate eliberată, preţ
unitar (Figura 2.5).
Într-un mod asemănător putem reprezenta în modelul EA facturile, comenzile emise de clienţi
pentru livrarea produselor etc.
Obiectele compuse sunt decompozabile ele regrupând în structura lor obiecte simple între care
există o anumită legătură. Chiar dacă în modelul EA iniţial pentru un obiect compus s-a definit un singur
tip de entitate, ulterior acesta se va descompune în tipuri de entităţi de sine stătătoare corespunzătoare
obiectelor elementare care intră în structura obiectului compus (Figura 2.6).

BON DE CONSUM
Obiect compozit Caracteristici multivaloare (un
Nr. bon bon de consum serveşte la
Data bon eliberarea din magazie a mai
Secţia multor materii prime)
Gestiunea
Cod material
Cantitate eliberată
Preţ unitar

Tip de entitate
Bon de consum Material eliberat
Nr bon Cod material
Data bon Cantitate eliberată
Secţia Preţ unitar
Gestiunea

Figura 2.5 Reprezentarea obiectelor compozite sub

formă de tipuri de entităţi

Obiect
compus

TITULAR
CONTRACT DE CREDIT
COD IDENTIFICARE
NR CONTRACT NUME
DATA CONTRACT CNP
TITULAR ADRESA Tipuri de
VALOARE CONTRACT DATA NASTERII entităţi
UNITATE MONETARA
GARANTII
GARANTIE

NR DOCUMENT
DATA EMITERII
BANCA EMITENTA
SUMA

Figura 2.6 Reprezentarea obiectelor compuse sub formă de tipuri de entităţi

 Tipul de entitate contract de credit - definit prin atributele: număr contract, data contract, titular,
valoare contract, unitate monetară, garanţii – corespunde unui obiect compus al realităţii de modelat.
Titularul şi garanţia sunt două obiecte distincte ale problemei de modelat, fiecăruia trebuind să-i
corespundă în MCD un tip de entitate distinct. Ca urmare, se vor include în MCD tipurile de entităţi:
TITULAR definit prin: Cod identificare, nume, cod numeric personal, adresă, data naşterii.
GARANŢIE care poate fi reprezentată, de exemplu, de o scrisoare de garanţie bancară definită
prin atributele: număr document, data emiterii, banca emitentă, termen de valabilitate, sumă.
CONTRACT DE CREDIT definit prin: Nr. Contract, Data contract, Valoare contract, Moneda.
Fiecare tip de entitate prezintă un IDENTIFICATOR reprezentat de un atribut sau un grup minimal
de atribute al cărui rol este de a permite identificarea în mod unic, fără echivoc, a entităţilor.
De multe ori identificatorul este reprezentat de un atribut de tip “număr de ordine” (incrementat cu
1 pentru fiecare nouă valoare atribuită) sau de un cod (construcţie artificială având o anumită
semnificaţie).
Exemple: pentru tipul de entitate STUDENT identificatorul va fi Nr Matricol, în cazul entităţii BON
CONSUM identificatorul va fi atributul Nr. Bon (atribut de tip număr de ordine), etc.
În reprezentarea grafică a tipului de entitate identificatorul este marcat distinct prin subliniere
(Figura 2.7).

STUDENT

Nr matricol
Nume student
Data naşterii
Adresa

Figura 2.7 Tipul de entitate Student

ASOCIEREA dintre entităţi exprimă legătura stabilită dintre acestea şi rolul pe care îl joacă fiecare
entitate participantă la legătură. Exprimând o legătură dintre entităţi ea nu are o existenţă de sine
stătătoare.
O asociere poate prezenta unul sau mai multe atribute proprii cu rol de a caracteriza, explicita,
legătura stabilită între entităţile participante la asociere.
Atributele Data debut şi Data sfârşit caracterizează asocierea Ocupă şi aceasta deoarece ele nu
sunt proprietăţi ale entităţii Camere, aceiaşi cameră cu nr. 10 poate fi ocupată la date diferite şi de către
clienţi diferiţi. Fiecare entitate participantă la asociere joacă un anumit rol. În exemplul prezentat în figura
2.8 entitatea Client joacă rolul Ocupant (clientul x ocupă în data y camera z) iar entitatea Camera
prezintă rolul este ocupată (camera z este ocupată în data y de clientul x).
 TIPUL DE ASOCIERE se defineşte ca ansamblul legăturilor, prezentănd aceeaşi semnificaţie,
dintre entităţile aparţinând la două sau mai multe tipuri de entităţi. Exemplu: tipul de asociere Ocupă din
figura 2.8.

Cardinalităţi

1,n 1,n CAMERE

CLIENŢI Ocupă
Nr cameră
Cod client Data debut Tip
Nume
Data sfarsit Tarif cameră
Adresa Este
CNP ocupată
Ocupant

Roluri

Figura 2.8 Tipul de asociere Ocupă

CARDINALITATEA cuplului entitate-asociere reprezintă cuplul de valori întregi (x,y) astfel încât:
• x (cardinalitate minimală) exprimă numărul minim de realizări ale legăturii (asocierii) existând
pentru o entitate.
• y (cardinalitate maximală) reprezintă numărul maxim de apariţii ale corespondenţei putând
exista pentru o entitate.
•
Cardinalitatea minimală 0 indică faptul că pot exista entităţi care să nu participe la nici o asociere:
Există clienţi potenţiali ai unei firme cărora încă nu li s-au încheiat poliţe de asigurare – cardinalitate
minimală 0, dar sunt clienţi cărora li s-au încheiat mai multe poliţe – cardinalitate maximală n.

CLIENT POLIŢA
0,n 1,1

Cod client Nr. poliţă

incheie
Nume Data poliţă
Adresa Valoare asigurată
CNP

Figura 2.9 Cardinalitatea minimală 0

Cardinalitatea minimală 1 indică faptul că toate realizările tipului de entitate trebuie să participe la
o realizare a tipului de asociere. De exemplu, orice contribuabil aflat în evidenţa administraţiei financiare
are deschis un rol şi numai unul singur (în acest caz şi cardinalitatea maximală este tot 1).

CONTRIBUABIL 1,1 ROL

1,1
Cod-identificare Nr rol
ARE
Nume Data deschiderii
Adresa

Figura 2.10 Cardinalitatea minimală 1

Cardinalitatea maximală 1 indică faptul că numărul de roluri deschise unui contribuabil la administraţia
financiară nu poate fi mai mare de 1. Săgeata din figura 2.10 indică caracterul imuabil al asocierii (rolul
fiscal nu-şi modifică titularul).
Cardinalitatea maximală n indică faptul că mai multe entităţi de un anumit tip participă la o
asociere. Un client emite unul sau mai multe documente de plată (Figura 2.11).

POLIŢA PRIME DE PLATĂ

1,4 1,1
Nr. Poliţă prevede Data scadenţei
Data încheierii Suma de plată
Data început
Data sfârşit
Valoare asigurată

Figura 2.11 Cardinalitatea maximală n

Dar uneori valoarea lui N poate fi specificată clar printr-o constantă. De exemplu, pentru o poliţă
de asigurare (încheiată pe un an) sunt calculate maxim 4 prime de asigurare - câte una pe trimestru
(figura 2.12).
Valorile uzuale pentru exprimarea cardinalităţii sunt : 0,1; 1,1; 0,n;1,n.

CLIENT DOCUMENT
1,n 1,1

Cod client emite Nr doc

Nume Data doc
Adresa Tip doc
CNP Sumă

Figura 2.12 Cardinalitatea maximală 4

Între realizările a două tipuri de entităţi se pot stabili mai multe asocieri prezentând semantică
diferită şi prin urmare cardinalităţi diferite. Exemplu: un profesor lucrează la o disciplină cu un grup de
studenţi, unora dintre aceştia (maxim 10) conducându-le şi proiectul de semestru la disciplina respectivă
(figura 2.13).

PROFESOR 1,n lucrează STUDENT

Cod ID
Nume Nr. Matricol
Grad didactic Nume student
Titlu ştiinţific conduce
1,1
1,10

Figura 2.13

După numărul de tipuri de entităţi participante asocierea poate fi:

• unară (refexivă)
• binară
• complexă
Asocierea reflexivă (ciclică, unară) se caracterizează prin faptul că exprimă legăturile stabilite între
entităţi aparţinând aceluiaşi tip (figura 2.14).
 0,N MATERIAL 0,N

COD
DENUMIRE
Substituie UNIT. DE MĂSURĂ Este
substituit

Substituie

Cantsubstit

Figura 2.14 Asocire reflexivă

Spre exemplu, o materie primă necesară pentru fabricarea unui produs poate fi substituită (dacă
nu există cantitatea necesară în stoc) printr-o altă materie primă (având aceleaşi caracteristici dar spre
exemplu o altă concentraţie) într-o anumită cantitate.

Asocierile binare reprezintă legături (corespondenţe) stabilite între realizările aparţinând la două
tipuri de entităţi diferite.
Exemplu: asocierea Prevede stabilită între tipul de entitate POLIŢĂ şi tipul de entitate PRIMA DE
PLATĂ (figura 2.12) sau asocierile Lucrează şi Conduce din figura 2.13.
Asocierile complexe exprimă legături stabilite între realizările mai multor tipuri de entităţi. Spre
exemplu, o entitate ternară se poate stabili între tipurile de entităţi: CONTRIBUABIL, TAXA, DOCUMENT
DE PLATĂ (DOC PLATA).

1,N
1,1 Doc. plată
Contribuabil Plăteşte

Plătitor
Emis
Plătită 0,N

Taxă

Figura 2.15 Asociere ternară

Se recomandă însă reducerea acestor asocieri complexe la asocieri binare. Astfel asocierea
ternară prezentată în figura 2.15 se descompune conform figurii 2.16 în asocieri binare.
În continuare prezentarea se va referi doar la asocierile binare.
 0,N 1,1

Contribuabil Achită Doc plată

1,N
Datorează
1,N
Suma 1,N
0,N
Taxe Privesc

Figura 2.16 Descompunerea unei asocieri

ternare în asocieri binare

2.2. Restricţii de integritate

Restricţiile de integritate definesc cerinţele pe care datele trebuie să le respecte pentru a fi

corecte şi coerente în raport cu realitatea pe care o reflectă.
Restricţiile de integritate reprezintă o modalitate de integrare a semanticii datelor în mod indirect în
modelul entitate asociere pe care astfel îl îmbogăţesc.
Restricţiile de integritate privesc:
• valorile pe care le pot lua atributele entităţilor şi asocierilor;
• valorile identificatorilor entităţilor;
• rolurile jucate de entităţi în asocierile la care participă;
• asocierile stabilite între entităţi.
Pentru modelul EA prezentat în Figura 2.17 pot fi definite următoarele restricţii de integritate
privitoare la realizările atributelor: data documentului (comenzii) să fie anterioară datei curente sau egală
cu aceasta, cota de TVA poate fi 0 %, sau 19%, produsul cel mai vechi din nomenclatorul de fabricaţie a
fost omologat în 12.12.99, iar numărul gestiunii poate lua valori în mulţimea M={1,2,3}, tipul depozitului
poate fi frigorific/nefrigorific, unităţile de măsură sunt KG şi BUC.
Restricţiile de integritate pot fi statice (se verifică permanent) sau dinamice (privesc evoluţia în
timp a datelor). De exemplu, restricţiile referitoare la numărul gestiunii, tipul depozitului şi unităţile de
măsură sunt statice. Restricţia privind cota de TVA este dinamică ea putându-se modifica în timp în
conformitate cu prevederile fiscale în vigoare.
 1,N 0,N Produs
Comanda
Cuprinde Cod produs
Denumire
Nr doc
Cantitate Preţ catalog
Data-doc
TVA
Data omologării
Unit măsură
Gestiune

Număr gestiune 1,n

1,n
Nume gestionar
Depozitat
Tip depozit

Stoc
Data stoc

Figura 2.17. Model EA

2.2.1. Restricţii de domeniu

Domeniul, ca mulţime de valori pe care le poate lua un atribut, poate fi definit printr-o proprietate
(o condiţie privind un atribut sau un grup de atribute), prin precizarea unui interval de valori sau prin
enumerarea mulţimii de valori admise.
Restricţiile de domeniu reprezintă condiţii (reguli) care privesc ansamblul de valori admise
pentru un atribut în cadrul tipului sau domeniului său. Restricţiile pot viza realizările unui/unor atribute
aparţinând unei aceleiaşi entităţi sau asocieri, caz în care se numesc restricţii intraentitate, sau a
unui/unor atribute aparţinând unor entităţi şi/sau asocieri diferite, caz în care se numesc restricţii
interentităţi. Restricţiile pe domeniu se pot exprima cu privire la:
1. Conţinutul unui singur atribut al unei entităţi sau asocieri:
Exemplu: Unit. Măsură={ “KG”,”Buc”}
TVA = { 0, 19}
Preţ > 10000 şi preţ <10000000
Cantitate > 10 (cantitatea este un atribut definit pentru asocierea CUPRINDE din Figura
2.17).
2. Corelaţiile ce trebuie să se respecte între valorile mai multor atribute sau asocieri
aparţinând aceleiaşi entităţi sau asocieri:
Exemple: Număr gestiune=1 atunci nume gestionar = “Ion Toma”
Cod produs=12 atunci Unit Măsură=”BUC”
3. Corelaţiile care trebuie să existe între atributele aparţinând mai multor entităţi sau asocieri
diferite:
Exemplu:
În gestiunea 1 se stochează doar produsele având codurile în mulţimea {1000, 1001,
1014}.
Data-stoc > data omologării
Cod produs=112 atunci număr gestiune=1
4. Corelaţii realizate pe baza unor valori obţinute prin operaţii de sintetizare (însumare, calculul
mediei, valorii minime /maxime etc.) a unui ansamblu de entităţi:
Exemplu:
Suma cantităţilor comandate pentru un produs nu poate depăşi stocul din data respectivă.
Preţul mediu al produselor >200000
2.2.2. Restricţii structurale

Identificarea entităţilor

Fiecare entitate va trebui să poată fi identificată fără echivoc. Acest lucru impune ca identificatorul
entităţii să ia valori unice diferite de NULL (NULL înseamnă că nu s-a atribuit nici o valoare, deci valoarea
NULL este diferită de zero sau spaţiu).
În definirea modelului EA putem întâlni cazuri mai speciale legate de identificarea entităţilor:
1. Nu putem defini un identificator sub forma unui atribut/grup de atribute pentru un anumit tip de
entitate (Figura 2.18). Exemplu: Pentru fiecare angajat al firmei se consemnează lunar
prezenţa prin reţinerea orelor efectiv lucrate, orelor absentate, orelor de concediu medical.
Identificarea entităţilor Prezenţa se face prin rolul Realizează pe care entitatea Angajat îl joacă
în asocierea Înregistrează
Identificarea prin rol a entităţilor se poate realiza doar dacă asocierea în cauză nu este ciclică
(unară) iar cardinalitatea cuplului entitate identificată-asociere este 1,1 şi cardinalitatea cuplului entitate
identificator - asociere este 1,1 sau 0,1.

1,1 1,1
PREZENŢA
ANGAJAT Înregistrează

Marca Luna Ore efective

Nume Ore absenţe
Funcţie Ore concediu
Salariu Ore medical
Realizeză Aparţine

Figura 2.18

2. Identificarea unei entităţi se poate realiza prin unul sau mai multe atribute proprii împreună cu
rolul jucat de alt tip de entitate (figura 2.19) în cadrul asocierii.

ASIGURARE 1,n 1,1 PRIME

ASIGURARE
Nr. polită
Prevede
Data Data scadenţă
Val. asigurare Sumă de plată

Cuprinde Priveşte
Figura 2.19

O poliţă de asigurare de viaţă presupune pe lângă specificarea numărului, datei încheierii poliţei,
valorii asigurate şi precizarea primelor de plată cu înscrierea datei limită a plăţii precum şi a sumei de
plată ( considerăm că sumele sunt diferite de la o scadenţă la alta). Fiecare poliţă se identifică prin
număr, atribuit în mod unic. Pentru tipul de entitate Scadenţa, atributul Data scadenţei nu poate fi
identificator deoarece, la aceeaşi dată mai multe poliţe au acelaşi termen limită de plată. Identificarea
entităţilor Prime asigurare se va realiza prin valorile atributului propriu Data scadenţei şi rolul Cuprinde
jucat de entitatea Asigurare în asocierea Prevede.
2.2.3. Restricţii de integritate de roluri
În definirea asocierii am subliniat faptul că aceasta exprimă legătura stabilită între entităţi diferite,
fiecare dintre acestea jucând un anumit rol. Plecând de la rolurile jucate de entităţi în cadrul asocierilor
putem defini o serie de restricţii de integritate şi anume de : egalitate, incluziune şi excluziune de roluri.

Restricţia de incluziune de roluri

Restricţia de incluziune de roluri statuează faptul că, dacă o entitate E1 care joacă rolul r1 în
asocierea A1 va trebui să joace şi rolul r2 în asocierea A2. Rezultă că rolul r1 include (implică prin
incluziune) rolul r2 . Pentru reprezentarea restricţiei de incluziune de roluri se va utiliza următoarea
reprezentare grafică:

r1 I r2

Figura 2.20 Incluziune de roluri

Un exemplu îl constituie secvenţa de MCD elaborat pentru o firmă de asigurări. (Figura 2.21).
Clienţii încheie poliţe de asigurare şi primesc despăgubiri la producerea riscului asigurat dacă au
la zi plata primelor de asigurare. Între rolul despăgubită şi rolul achitată se manifestă o restricţie de
incluziune pe rol. De asemenea este o restricţie de integritate pe rolurile despăgubită şi încheiată pe care
le joacă entitatea poliţă.

CLIENT POLIŢA DESPAGUBIRE

încheiată despăgubită
1,n 1,1 1,1 1,1
Cod client Nr poliţa Nr. Document
încheie calculează Data document
Nume client Data poliţa
Adresa Data inceput Sumă despăgubită
calculată
Data sfârşit
Nume agent
I
achitată 1,n
achită

1,1
PLATA PRIME

Nr chitanţă
Data chitanţă
Suma plătită

Figura 2.21. Incluziune de roluri

Restricţia de egalitate de roluri

Egalitatea de roluri presupune ca restricţia de incluziune între roluri să fie reciprocă. Grafic
restricţia de egalitate de roluri se reprezintă conform figurii 2.22.

r1 = r2

Figura 2.22. Egalitatea de roluri

Persoanele care au un rol (fişă) deschis la administraţia financiară, deci joacă rol de posesor în
asocierea Are, înseamnă că au obligaţii fiscale, deci joacă rol de contribuabil în asocierea Datorează,
reciproca fiind valabilă: orice persoană care are obligaţii fiscale trebuie să aibă deschis un rol. Dar nu
Posesor
toate persoanele sunt contribuabili, deci există entităţi ale tipului Persoana care nu joacă rolul de
Posesor în asocierea Are. Grafic, egalitatea de roluri se reprezintă conform figurii 2.23.
Rol
Persoana
1,1
0,1 Nr. rol
CNP Data deschid.
Nume Are
Adresa

Contri-
buabil
0,n =
Impozit
1,n
Cod impozit
Datorează Denumire

Figura 2.23. Egalitate de roluri

Restricţia de excluziune de roluri

Excluziunea de roluri specifică faptul că un rol r1 jucat de o entitate E1 în asocierea A1 exclude

existenţa rolului r2 jucat în asocierea A2.

r1 # r2

Figura 2.24. Reprezentarea excluziunii de roluri

Figura 2.25. Excluziunea de roluri

 Din exemplele prezentate rezultă că restricţiile de integritate de roluri vizează rolurile pe care o
entitate le poate juca în cadrul unor asocieri diferite. Incluziunea de roluri specifică faptul că un rol r2
jucat de entitatea E1 în asocierea A2 este urmarea rolului r1 jucat de aceeaşi entitate în asocierea A1.
Restricţia de egalitate de roluri evidenţiază că rolul r1 jucat de entitatea E1 în asocierea A1 determină
rolul r2 jucat de aceeaşi entitate în asocierea A2, iar rolul r2 determină în acelaşi timp rolul r1. Resticţia
de excluziune de roluri precizează că, dacă o entitate E1 joacă rolul r1 în asocierea A1 nu poate juca
rolul r2 într-o altă asociere numită A2.
Dar aceste restricţii legate de participarea entităţilor la asocieri nu pot fi judecate doar la nivel de
roluri ci este necesară uneori precizarea unor restricţii de integritate la nivelul tipului de asociere, deci a
ansamblului de asocieri prezentând aceeaşi semantică.

2.2.4. Restricţii de integritate de asocieri

Restricţiile analizate în acest subcapitol vizează asocierea însăşi împreună cu entităţile

participante. Altfel spus restricţiile se referă la mulţimea tuturor rolurilor aparţinând asocierii.

Restricţia de incluziune de asocieri

Restricţia de incluziune exprimă faptul că asocierea A1 stabilită între două entităţi va determina
existenţa unei alte asocieri A2 în cadrul modelului EA.
Exemplu: Un broker primeşte ordine de la clientul său şi execută tranzacţii.

ORDINE
BROKER
1,n primeşte 1,1
ID ordin
ID Broker Data ordin
Nume broker Cod acţiune
SVM

1,n

I 1,1
Execută
emite
1,1
1,n
TRANZACŢII
CLIENTUL
Cod tranzactie
Valoare Cod client
Nume client
Adresa

Figura 2.26. Incluziunea de asocieri

Tipul de asociere execută este determinat de existenţa tipului de asociere primeşte (brokerul nu
poate efectua tranzacţia dacă nu a primit ordinul corespunzător).

Restricţia de excluziune de asocieri

Restricţia de excluziune de asocieri exprimă faptul că asocierile aparţinând tipului de asociere A1

exclud asocierile aparţinând tipului A2.
Exemplu: Studenţii din universităţile de stat care achită taxa de şcolarizare nu pot fi bursieri ai
acestor instituţii. Rezultă că între Achită (taxe) şi Încasează (bursă) este o excluziune de asocieri.
 Primitor
STUDENT BURSE
1,1
F 0,n
Cod-stud Încasează Cod bursă
Nume Suma
Adresa

1,n
TAXE SCOLARE
Achită
Plătitor 1,1 Cod TAXĂ
Denumire
Suma taxă

Figura 2.27. Excluziune de asocieri

Restricţia de egalitate de asocieri

Restricţia de egalitate de asocieri exprimă faptul că asocierile aparţinând tipului A1 determină

existenţa asocierilor aparţinând tipului A2 şi invers.
Exemplu:
Fie tipurile de entităţi Cărţi şi Legitimaţii între care se stabilesc tipurile de asocieri Posedă şi
Împrumută. Între aceste asocieri se stabileşte o restricţie de egalitate de asocieri deoarece orice
împrumut de carte implică posesia legitimaţiei de acces la bibliotecă iar posesia legitimaţiei implică
posibilitatea împrumutului de carte (Figura 2.28). Toate rolurile Cititor implică toate rolurile Posesor şi
entităţile participante la asociere.
STUDENT LEGITIMATIE
Nr. Matricol 1,1 Posedă 1,1 Nr. Legitimatie
Nume Data emiterii
posesor

cititor 0,n

Împrumută =

0,n
CARŢI
Cota
Titlu
Editura

Figura 2.28. Restricţie de egalitate de asocieri

2.3. Dependenţe funcţionale

2.3.1. Tipuri de dependenţe funcţionale

Conceptul de dependenţă funcţională (DF) este fundamental în analiza structurii datelor. Studiul
dependenţelor funcţionale stabilite între atribute ne permite obţinerea unei reprezentări formalizate a
structurii de date.
Dependenţele funcţionale evidenţiază raporturile de determinare stabilite între atributele unei
entităţi.
O dependenţă funcţională pune în relaţie două atribute: determinantul şi determinatul.

Determinant
Determinat

Figura 2.29 Dependenţă funcţională

Exemplu:

Nr. rol Nume contribuabil

Agent economic
Cod fiscal

Această df subliniază faptul că unei realizări a atributului Nr. rol îi va corespunde întotdeauna
aceeaşi realizare a atributului Nume contribuabil, iar aceeaşi realizare a atributului Cod fiscal va fi
asociată aceluiaşi Agent economic.
Rezultă că determinantul reprezintă atributul/grupul de atribute din stânga df care prin valoarea sa
determină valoarea luată de atributul cu rol de determinat.
Fie tipul de entitate R, A,B,C… atribute aparţinând lui R, iar X, Y, Z ansambluri de atribute de R.
Spunem că în tipul de entitate R se verifică df X → Y dacă în două realizări ale lui R având aceleaşi
valori pentru X există aceleaşi valori pentru Y.
Rezultă deci că df este o relaţie de determinare stabilită între atributele aparţinând aceluiaşi tip de
entitate.
Dacă valorile atributelor cuprinse în Y sunt cunoscute, atunci ele sunt în funcţie de valorile
atributelor aparţinând lui X pentru că ele sunt determinate în mod unic de acestea din urmă.
Dependenţa funcţională poate implica atribute sau grupuri de atribute.
Dacă:
A → (B,C)
atunci există dependenţele funcţionale:
A→B
A→C
Exemplu:
Nr. Poliţă → Data poliţă, nume agent
Ceea ce ne conduce la identificarea dependenţelor funcţionale:
Nr. Poliţă → Data poliţă
Nr. Poliţă → Nume agent
Dar dacă există df (A,B) → C nu înseamnă că se verifică dependenţele funcţionale:
A→B
şi
A→C
 Exemplu:

Cod secţie Marca

Dacă există dependenţa funcţională:

Cod-material, cod-furnizor Æ preţ-aprovizionare
rezultă că preţul nu depinde numai de codul materialului ci şi de furnizor, acelaşi material putând fi
aprovizionat la preţuri diferite de la furnizori diferiţi.
Df XÆY este o dependenţă funcţională completă dacă Y este dependent funcţional de X fără să
fie dependent funcţional de nici una din componentele lui X (preţul de aprovizionare este determinat atât
de furnizor cât şi de materialul aprovizionat).
Dependenţa funcţională XÆY se numeşte df parţială dacă Y este dependent funcţional atât de X
cât şi de o parte a lui X.
Fie tipul de entitate E definit prin atributele: cod operaţie, cod reper, timp-prelucrare, categorie-
operaţie. Între atributele aparţinând lui E există următoarele df:
Cod operaţie, cod reper Æ timp de prelucrare (df.completă)
Cod operaţie, cod reper Æ categorie-operaţie (df.parţială)
Dependenţa funcţională X Æ Y se numeşte df trivială dacă Y ⊆ X.
În procesul de analiză a datelor pot fi identificate df tranzitive. XÆ A este o df tranzitivă dacă A
este un atribut unic neinclus în X astfel încât există Y ⊄ X, XÆY şi YÆA şi Y nu determină X.
Să analizăm dependenţele funcţionale care se stabilesc între atributele: CNP (cod numeric
personal), Nume persoană, Localitatea de domiciliu, Cod localitate aparţinând tipului de entitate
Persoana. CNP fiind ales drept identificator al entităţii înseamnă că există dependenţele funcţionale:
CNP Æ Nume persoană
CNP Æ Localitatea de domiciliu
CNP Æ Cod localitate
Dar există:
df Localitate de domiciliu Æ Cod localitate
ceea ne conduce la concluzia că df CNP Æ Cod localitate este o df tranzitivă.
Dependenţa multivaloare se manifestă atunci când valorii unui atribut/grup de atribute îi
corepund mai multe valori ale unui alt atribut. Df tranzitivă se reprezintă astfel:
X Y
O dependenţă multivaloare poate să se manifeste în cazul unei entităţi prezentând cel puţin trei
atribute (A,B,C) astfel încât: A determină mai multe valori pentru B, A determină mai multe valori pentru
C; B şi C sunt independente unul de celălalt.
Exemplu:
Să presupunem că dorim să reţinem informaţia referitoare la numărul de inventar al mijloacelor
fixe aflate într-o secţie şi mărcile (codul de identificare) salariaţilor care lucrează în secţia respectivă într-
un tip de entitate numit SECŢII al cărui identificator este atributul cod secţie. Se identifică între aceste
atribute dependenţele funcţionale multivaloare:

Cod secţie Nr inventar

2.3.2. Proprietăţile dependenţelor funcţionale
Proprietăţile dependenţelor funcţionale, numite şi regulile lui Amstrong sunt:
Reflexivitatea:
Dacă Y⊂ X atunci se verifică df XÆY unde X şi Y sunt atribute/grupuri de atribute aparţinând
tipului de entitate R.
Dezvoltarea:
Pentru orice Z ⊂ R dacă se verifică XÆ Y atunci se verifică şi df XZÆ YZ.
Tranzitivitatea:
Dacă se verifică df XÆ Y şi df YÆZ atunci este adevărată şi df XÆZ.
Aditivitatea:
Dacă XÆ Y şi XÆ Z atunci există df XÆ YZ.
Pseudotranzitivitatea:
Dacă există dependenţele funcţionale XÆY şi WYÆZ atunci se verifică df XWÆZ.
Descompunerea:
Dacă se verifică df XÆY atunci se verifică şi df XÆZ dacă Z⊂Y.
Studiul dependenţelor funcţionale se poate realiza utilizând mai multe instrumente. În cele ce
urmează ne propunem să prezentăm două dintre acestea: matricea dependenţelor funcţionale şi
diagrama dependenţelor funcţionale care s-au dovedit complementare.

2.3.3. Matricea dependenţelor funcţionale

Matricea dependenţelor funcţionale poate fi realizată în două variante:
‰ matricea simplificată
‰ matricea completă
Matricea simplificată reprezintă un tablou în care coloanele cuprind determinanţii dependenţelor
funcţionale iar fiecare linie un atribut aparţinând mulţimii atributelor supuse modelării.
Matricea completă reprezintă un tablou asemănător matricii simplificate cu singura deosebire că
numărul de coloane este egal cu numărul liniilor, cu alte cuvinte antet de coloană va fi orice atribut
(regăsit şi ca antet de linie) şi nu doar atributele (grupurile de atribute) cu rol de determinant într-o
dependenţă funcţională.
Să elaborăm matricea simplificată a dependenţelor funcţionale pentru atributele necesare
elaborării MCD privind consumul normat de materii prime stabilit pentru produsele din nomenclatorul de
fabricaţie al firmei.
Mulţimea atributelor corespunzătoare problemei studiate este formată din: cod produs, denumire
produs, cod um, preţ livrare, cod reper, denumire reper, cantitate reper (în realizarea unui produs finit
intră mai multe repere de acelaşi fel sau diferite), cod material, denumire material, cantitate normată pe
reper, denumire um. Pe baza mulţimii atributelor enunţate se identifică dependenţele funcţionale stabilite
între acestea care apoi sunt marcate în matricea simplificată a dependenţelor funcţionale.
DETERMINANTI
ATRIBUTE 1 3 5 8 5+8 1+5
1. Cod produs 1
2. Denumire produs 1
3. Cod um 1 1 1
4. Preţ produs 1
5. Cod reper 1 1
6. Denumire reper 1
7. Cantitate reper 1
8. Cod material 1 1 1
9. Denumire material 1
10. Cantitate normată pe reper 1
11. Denumire unitate de 1
măsură
Figura 2.30 Matricea simplificată a DF
 Analizând Figura 2.30 constatăm că fiecare coloană din matrice a fost rezervată unui determinant
(se poate stabili anterior o listă a DF). Valoarea 1 marchează la intersecţia unei coloane cu o linie
existenţa unei DF între atributul cu rol de determinant precizat în coloană şi atributul determinant înscris
la nivelul liniei.
Una din regulile modelului EA specifică unicitatea atributelor adică obligativitatea ca un atribut să
aparţină unei singure entităţi sau asocieri. Plasarea unui atribut într-o entitate sau alta este determinată
de DF la care participă în legătură cu identificatorul tipului de entitate. Aceasta înseamnă că la nivelul
matricei dependenţelor funcţionale la nivelul fiecărei linii va trebui să fie înscrisă o singură valoare 1. În
mod distinct, prin subliniere, în cadrul matricei au fost marcate câteva valori 1. Ele exprimă proprietatea
de reflexivitate a DF şi sunt marcate la intersecţia coloanei cu linia corespunzătoare aceloraşi atribute (în
cazul nostru determinanţii). O problemă apare în linii de 3 şi 8 unde cod um şi cod material prezintă mai
mulţi determinanţi. Această situaţie atenţionează asupra necesităţii unei analize şi impune alegerea
corectă a determinantului dependenţelor funcţionale puse în evidenţă. Existenţa mai multor valori 1 pe o
linie poate fi şi consecinţa unor DF tranzitive care pun în evidenţă asocieri ierarhice (numite şi restricţii de
integritate funcţională) între entităţile ale căror identificatori sunt în dependenţă funcţională.

Matricea completă a dependenţelor funcţionale

În cazul matricei complete numărul de coloane corespunde cu numărul liniilor.

DETERMINANTI
ATRIBUTE 1 2 3 4 5 6 7 8 9 10 11 5+8 1+5
1. Cod produs 1
2. Den. produs 1 1
3. Cod um 1 1 1
4. Preţ produs 1 1
5. Cod reper 1 1
6. Den. reper 1 1
7. Cantitate reper 1 1
8. Cod material 1 1 1
9. Den. material 1 1
10. Cant. normată 1 1
11. Den. um 1 1
Figura 2.31 Matricea completă a DF

Din analiza matricei complete a DF constatăm:

• diagonala de valori 1 rezultată (aşa cum am precizat şi în cadrul matricei simplificate) este consecinţa
proprietăţii de reflexivitate a df;
• existenţa dependenţelor elementare (prezentând un determinant elementar, format dintr-un atribut);
• existenţa dependenţelor neelementare al căror determinant este format dintr-un grup de atribute în
cazul nostru (Cod produs, cod reper) şi (cod reper, cod material).
• existenţa unor dependenţe tranzitive (cod produs→cod material) şi multivaloare între atributele cod
produs şi cod reper, respectiv între cod reper şi cod material care conduc la apariţia mai multor valori
1 în cadrul liniilor matricei.
Analiza informaţiei din matrice (completă sau simplificată) ne va conduce la definirea unor tipuri de
entităţi optimizate în cadrul cărora să fie eliminate DF complexe.

Diagrama dependenţelor funcţionale

Diagrama dependenţelor funcţionale reprezintă un graf constituit pe baza DF identificate pornind

de la care vom putea defini tipurile de entităţi ale modelului EA astfel încât în cadrul acestora să nu se
mai manifeste DF complexe.
Notaţiile pe care le vom utiliza în cadrul diagramei sunt:
DF
Cvasi DF
 Cvasi dependenţele funcţionale sunt cele pentru care cunoaşterea unei valori pentru determinant
nu antrenează sistematic cunoaşterea unei valori a determinatului.
De exemplu:
Cod produs Cod reper
De multe ori aceste cvasi dependenţe funcţionale sunt reciproce. Un produs este format din mai
multe repere dar un anumit reper participă la realizarea mai multor produse.
Un graf al DF pune în evidenţă DF tranzitive:
Atribut 1
Df 1

Atribut 2
Df 3
Df 2

Atribut 3

Figura 2.32 Graf al DF

Dependenţa tranzitivă DF3 va trebui eliminată din diagrama dependenţelor funcţionale. În cazul
problemei pe care o avem de rezolvat cvasidependenţe funcţionale reciproce sunt:
Dar dependenţa funcţională dintre atributul cod produs şi atributul cod material este tranzitivă şi va
trebui eliminată din diagrama DF.
Pornind de la mulţimea atributelor ce definesc problema de rezolvat (enumerate în paragraful
anterior) putem identifica dependenţele funcţionale pe care le vom grupa în cadrul diagramei în funcţie
de determinanţii pe care îi prezintă.

În aceste condiţii diagrama DF va arăta astfel:

Cod produs Cod reper
Cod reper Cod material

Cod produs Cod material

Trecerea de la diagrama dependenţelor funcţionale la modelul EA se realizează pe baza

următoarelor reguli:

Figura 2.33 Diagrama DF

1. Pentru fiecare DF în care determinantul este elementar se creează un tip de entitate în care
determinantul DF joacă rolul de identificator.
 În cazul problemei de rezolvat se vor defini patru tipuri de entităţi şi anume: Produs, Reper,
Material şi Unităţi măsură prezentând drept identificatori atributele: Cod produs, Cod reper, Cod material
şi respectiv Cod um (Figura 2.34).

PRODUS REPER MATERIAL UNITATI MASURA

Cod produs Cod reper Cod material Cod um

Fig 2.34 Tipuri de entităţi definite.

2. Toate atributele participând la dependenţe funcţionale ce prezintă acelaşi determinant se vor grupa în
cadrul aceluiaşi tip de entitate prezentând drept identificator atributul cu rol de determinant în cadrul
dependenţelor funcţionale.
În urma aplicării acestei reguli obţinem:

PRODUS REPER MATERIAL UNITATI MASURA

Cod produs Cod reper Cod material Cod um
Den produs Den reper Den material Den um
Pret livrare

Figura 2.35 Gruparea atributelor pe tipuri de entităţi

3. Fiecărei dependenţe funcţionale între identificatorii tipurilor de entităţi îi va corespunde în modelul EA

un tip de asociere. Această asociere este ierarhică (restricţie de integritate funcţională) când
cardinalitatea maximală pentru cuplul E1A este 1 iar pentru cuplul E2A este n.
Aplicând această regulă obţinem:

Figura 2.36 Definirea tipurilor de asocieri

4. Pentru fiecare DF neelementară (cu determinantul format dintr-un grup de atribute, identificatorii în
cadrul tipurilor de entităţi definite) se creează un tip de asociere neierarhic (restricţie de integritate
multiplă), definită prin atributul cu rol de determinant în DF.
Aplicând regula obţinem:
 Figura 2.37 Model EA

Realizând matricea simplificată a df vom constata respectarea cerinţelor de validare a modelului

EA:

Figura 2.38 Matricea simplificată a DF

Matricea s-a realizat pe baza DF manifestate în cadrul tipurilor de entităţi definite. Se observă că
prin eliminarea elementelor de reflexivitate pe fiecare linie a matricei rămâne, aşa cum este corect, o
singură valoare semnificând că un atribut prezintă un singur determinant.

2.4. Reguli de verificare şi normalizare a MCD

2.4.1. Reguli de verificare a MCD

Realizarea MCD impune respectarea următoarelor reguli:
• Regula de unicitate a numelor se aplică tuturor elementelor care participă la definirea MCD: tipuri
de entităţi, tipuri de asocieri, atribute, roluri. Această regulă impune eliminarea din model a
omonimelor şi sinonimelor. Aceasta înseamnă că nu vom putea da, în cadrul aceluiaşi MCD, şi unui
atribut şi unui tip de entitate acelaşi nume, de exemplu Student. Vom numi tipul de entitate Student iar
atributul va primi denumirea Nume Student.
• Regula unicităţii atributelor (neredundanţei) impune ca un atribut să definească un singur tip de
entitate sau un singur tip de asociere.
• Regula de unicitate a asocierilor, aplicabilă în cazul asocierilor neierarhice, specifică faptul că
pentru fiecare realizare a asocierii nu poate să existe decât o singură realizare a fiecărei entităţi
participante la asociere.
• Regula proprietăţilor şi determinantului unei entităţi precizează că un atribut care este determinat
de mai mulţi determinanţi, aceştia fiind identificatori ai unor tipuri de entităţi diferite, trebuie să
definească tipul de asociere creat între respectivele tipuri de entităţi.
• Regula atributelor derivabile recomandă evitarea includerii în MCD a atributelor rezultate din
calcule. Prezenţa unor astfel de atribute în MCD se justifică numai dacă ele sunt purtătoare ale unei
informaţii cu o anumită relevanţă şi frecvenţă de utilizare.
• Regula atributelor decompozabile precizează că pot fi menţinute în cadrul MCD atribute complexe
în măsura în care prelucrările nu impun descompunerea lor pe componente elementare. Un exemplu
este reprezentat de atributul adresa care se poate descompune pe următoarele componente: cod
poştal, localitate, stradă, număr, nr. apartament. Într-un SI realizat pentru activitatea unei administraţii
financiare se impune descompunerea atributului adresa pe componentele sale elementare deoarece
contribuabilii sunt adesea selectaţi după criteriul străzii de domiciliu sau numărului. În cazul unui SI
destinat evidenţei angajaţilor unei firme atributul adresa se va reţine ca atare, nefiind necesară
descompunerea sa pe elemente.
• Regula minimizării identificatorilor specifică necesitatea stabilirii cu atenţie a identificatorilor
entităţilor reţinând în grupul de atribute un număr cât mai mic de elemente (atribute).
• Regula valorii NULL. Deoarece există definite în cadrul tipurilor de entităţi atribute care nu prezintă
realizări obligatorii la nivelul fiecărei entităţi, rezultă că MCD poate fi rafinat prin definirea unor
subtipuri de entităţi care să cuprindă doar atributele specifice acelei submulţimi de entităţi. Atributele
cu rol de identificator vor trebui să primească obligatoriu realizări.

2.4.2. Reguli de normalizare a MCD

Normalizarea este considerată o parte importantă a procesului de proiectare a datelor. Modelul EA
este rezultatul unui proces iterativ care a permis identificarea tipurilor de entităţi, atributelor definite în
cadrul acestora, a identificatorilor şi a asocierilor. Normalizarea vizează atributele entităţilor pe care le
analizează cu scopul eliminării anomaliilor asigurându-se astfel definirea unor tipuri de entităţi “libere” de
dependenţe funcţionale tranzitive şi multivaloare.
Procesul normalizării se poate desfăşura urmând una din următoarele abordări:
• Varianta “top down” caracterizată prin urmărirea respectării formelor normale la nivelul
entităţilor;
• Varianta “bottom up” caracterizată prin definirea unui tip de entitate unic înglobând toate
atributele modelului EA la nivelul căruia să se identifice mulţimea dependenţelor funcţionale
existente între ele.
Regulile de normalizare a MCD sunt:
Regula nr. 1 (FN1): Fiecare entitate trebuie să prezinte un identificator prezentând realizări
unice, nenule.
Această regulă este consecinţa directă a definirii tipului de entitate în cadrul MCD. O regulă
suplimentară celei enunţate deja este cea referitoare la caracterul elementar al atributelor.
Regula nr. 2 (FN2): Toate atributele entităţii, altele decât identificatorul, trebuie să fie în
dependenţă funcţională completă şi directă cu identificatorul entităţii.
Altfel spus, în toate realizările tipului de entitate, fiecare atribut trebuie să fie determinat de
identificator şi trebuie să ia o singură valoare şi numai una (nu se admit valori multiple deci dependenţe
funcţionale multivaloare). Sintagma de dependenţă completă exprimă necesitatea ca atributele să fie
determinate de identificator în ansamblul lui, şi nu doar de o parte a lui (nu se admit dependenţe
parţiale).
Din cele menţionate rezultă faptul că o entitate care prezintă identificatorul format dintr-un singur
atribut respectă automat această regulă.
Regula nr. 3 (FN3): Toate atributele unei asocieri trebuie să depindă complet de
identificatorul asocierii (identificatorii entităţilor participante la asociere) iar fiecare atribut trebuie
să depindă de întregul identificator şi nu de o parte a acestuia.
2.5. Dezvoltări ale modelului entitate asociere
Generalizarea şi specializarea

Un subtip (o subclasă) de entităţi reprezintă un grup de entităţi aparţinând unui tip, reprezentate
distinct în cadrul modelului, ele prezentând anumite trăsături caracteristice ce le detaşează,
individualizează, de celelalte entităţi.
Definirea subtipurilor de entităţi se poate face pe două căi:
- plecând de la valoarea unui atribut (valorile unor atribute);
- utilizând criterii precizate de utilizator.
Prin această grupare a entităţilor aparţinând unui tip se ajunge la definirea unor supertipuri de
entităţi dominante în raport cu subtipurile (subclasele) acestora. Subclasele sunt rezultanta unei
specializări la nivelul entităţilor, ele conservând însă capacitatea de a moşteni de la supertipul lor
elementele comune definitorii.
Pentru a clarifica importanţa definirii în modelul EA a tipurilor şi subtipurilor de entităţi vă
propunem următorul exemplu:
O bancă lucrează atât cu clienţi persoane fizice cât şi cu clienţi persoane juridice. Fiecare client al
băncii primeşte un număr unic de identificare (cod ID), are un nume. Dacă este persoană fizică se reţine
codul numeric personal (CNP) şi data naşterii (DataN), dacă este persoană juridică se reţine codul fiscal
(CodF) şi codul din registrul comerţului (CodC).

CLIENŢI
Cod ID Tip (Supertip)
Nume

0,1
0,1

Este o Este o

1,1 1,1

PERS FIZICĂ PERS JURIDICĂ

CNP CodF Subtipuri de
DataN CodC entităţi

Figura 2.39 Subtipuri de entităţi

Cele două subtipuri - PERS FIZICĂ şi PERS JURIDICĂ - moştenesc toate caracteristicile definite pentru
supertip (CLIENŢI) şi anume Cod ID şi Nume.

Generalizarea

Generalizarea reprezintă un proces de modelare a cărui finalitate este reprezentată de definirea

unui supertip regrupând toate atributele comune şi a mai multor subtipuri regrupând atributele specifice
unui subansamblu de realizări ale unui tip generic de entităţi.
 DOCUMENT

NUMĂR
DATA DOC
0,1 EMITENT
BENEFICIAR 1,1

Este un
Este un
1,1
1,1
Sgaranţie
OrdinPlată

Nr zile Cont Plătitor

Suma Cont Benef
Banca Pl.
Banca Benef.

Figura 2.40 Generalizarea în modelul EA

Conceptul de generalizare provine de la reprezentarea cunoştinţelor sub formă de reţele

semantice şi se materializează printr-un predicat de forma “este un” (mai este numită şi relaţie IS-A după
forma engleză a predicatului).
Să luăm un exemplu: orice document se identifică prin număr, data emiterii, emitent, destinatar
dar fiecare tip de document consemnează un eveniment cu o anumită natură şi conţinut. Astfel o
scrisoare de garanţie bancară indică perioada de valabilitate pentru care se garantează plata pentru o
sumă precizată. Un ordin de plată va aduce ca informaţie specifică: numărul contului plătitor, banca
plătitoare, contul beneficiar, banca acestuia, suma plătită. Se pot reprezenta astfel în mod distinct
proprietăţile comune ale tuturor documentelor (elementelor de identificare) de cele specifice (Figura
2.40).
Generalizarea permite în cadrul modelului EA tocmai definirea acestor caracteristici comune în
cadrul unui supertip de entitate urmând ca elementele specifice să rămână a fi descrise la nivelul
subtipurilor de entităţi.
Pentru că orice scrisoare de garanţie bancară sau ordin de plată se definesc prin număr, data,
emitent, beneficiar rezultă că subtipurile de entităţi Sgaranţie şi OrdinPlată vor moşteni atributele sus-
menţionate de la supertipul DOCUMENT.
Generalizarea prezintă o serie de proprietăţi, parţial comentate deja:
• Moştenirea atributelor semnificând faptul că orice entitate E1 (Sgaranţie/OrdinPlată) având cu o altă
entitate E (DOCUMENT) o relaţie de generalizare, de forma E1 este un E, moşteneşte atributele lui E;
• Atributele supertipului nu aparţin subtipului;
• Nu există moştenire colaterală (între Sgaranţie şi OrdinPlată)
Figura 2.40. cuprinde şi precizarea restricţiei de integritate de excluziune (o scrisoare de garanţie
nu poate fi un ordin de plată).

Specializarea

Specializarea reprezintă operaţia opusă generalizării permiţând realizarea unei decupări a unui
tip de entitate E (care va deveni SUPERTIP) în subtipuri de entităţi diferenţiate prin atribute proprii sau
prin anumite realizări aparţinând unui atribut. Specializarea şi generalizarea sunt două abordări diferite
ale aceluiaşi proces de modelare.
În măsura în care dorim să cuprindem în modelul EA informaţia existentă în documentele
Scrisoare de garanţie bancară şi ordin de plată (emis de agentul economic) putem crea iniţial un tip de
entitate document definit prin mulţimea atributelor corespunzătoare problemei analizate (mulţimea tuturor
atributelor celor două tipuri de documente).
Tipul de entitate DOCUMENT (Figura 2.41) este un concept generic, el cuprinzând elementele
caracteristice celor două documente aparţinând lumii reale, Scrisoarea de garanţie şi Ordinul de plată.
Chiar dacă pot exista atribute cu realizări opţionale în cadrul unui tip de entitate, atât timp cât privesc
caracteristici particulare ale unor entităţi este necesară “gruparea” acestora în subtipuri (de entităţi). La
nivelul tipului de entitate (Document) vor rămâne doar atributele comune subtipurilor definite. Obţinem
astfel subtipurile de entităţi Sgaranţie şi OrdinPlată ajungând astfel la modelul EA prezentat în figura
2.40.

Operaţia de specializare poate fi: totală sau parţială.

Document

Număr
Data
Emitent
Beneficiar
Nr. zile
Suma
Cont benef.
Banca benef.
Cont plătitor
Banca plătit.

Figura 2.41

• Specializarea totală corespunde situaţiei în care orice entitate a supertipului face parte dintr-un subtip.
Grafic se marchează printr-o linie dublă.
• Specializarea parţială corespunde situaţiei în care pot exista realizări ale supertipului care nu aparţin
nici unui subtip (spre exemplu o realizare a tipului document este un document de tip bon de consum
căruia nu-i corespunde nici un subtip din cele definite – în exemplul nostru Sgaranţie şi OrdinPlată).
Grafic se reprezintă printr-o linie simplă.
Să presupunem că secretariatul unei facultăţi doreşte să evidenţieze cele trei categorii de studenţi pe
care îi gestionează: studenţii de la forma de învăţământ zi, studenţii cursurilor postuniversitare şi studenţii
doctoranzi. Toţi aceşti studenţi se definesc printr-o serie de atribute comune: număr matricol, nume,
adresă, data naşterii care se reţin la nivelul tipului de entitate STUDENT. Atributele specifice fiecărui grup
de studenţi aparţinând unei anumite forme de pregătire se vor reţine în subtipurile specifice. Astfel,
studenţii de la cursurile de zi se definesc prin: an (de studii), grupa, categorie (student înscris pe loc
bugetat sau cu taxă), tip bursă. Studenţii cursurilor doctorale se caracterizează prin: cursul urmat, tema
aleasă pentru dizertaţie iar studenţii doctoranzi se definesc prin: specializare, conducător ştiinţific, tema
tezei, anul înscrierii.
 Student

Nr. matricol
Nume
Adresă
Data naşterii

0,1 0,1
0,1

# #
Este un
Este un Este un

1,1 1,1 1,1

Postuniv. Doctoranzi
Zi
Cursul Specializare
An Tema dizertaţiei Conducător
Grupă Anul înscrierii
Categorie Tema
Tip bursă

Figura 2.42. Specializare totală

Figura 2.42 evidenţiază faptul că orice entitate aparţinând tipului student îşi găseşte corespondent
într-o realizare a unui subtip. S-a marcat distinct şi de această dată restricţia de integritate de excluziune
dintre subtipurile de entităţi (dacă este un student la zi nu poate fi student la un curs postuniversitar sau
doctorand). Există situaţii în care între cele două subtipuri de entităţi având acelaşi supertip pot apărea şi
restricţii de incluziune, deci realizările cele două subtipuri nu sunt disjuncte (figura 2.43).
Şeful unui compartiment din structura organizatorică a firmei poate fi economist deci apare relaţia
de incluziune între cele două subtipuri definite – ŞEF şi ECONOMIST.
Angajat

Cod id
Nume
Funcţie
0,1 Salariu

0,1

Este un
Este un

1,1
1,1

Şef
Economist
Indemnizaţie
Specializarea

Figura 2.43 Restricţie de integritate de excluziune

 STUDIU DE CAZ

Se doreşte realizarea modelului conceptual al datelor pentru sistemul informatic al unei societăţi
de valori mobiliare ştiind că:
- Ordinele de tranzacţionare se primesc de la clienţi, fiecare client fiind definit printr-un cod unic
de identificare, nume, adresa, banca, cont.
- Ordinele de tranzacţionare vizează societăţile cotate pe piaţă, societăţi pentru care se reţine
codul, denumirea, capitalul social, cotaţia maximă şi respectiv cotaţia minimă înregistrată.
- Ordinele clienţilor privesc o anume societate tranzacţionată şi pot fi de vânzare, (caz în care
acesta poate specifica preţul minim pe care îl acceptă) sau de cumpărare, pentru care poate
preciza un preţ maxim. Ordinele primesc un număr unic la nivelul SVM-ului şi cuprind: data şi
ora emiterii, numărul de acţiuni, societatea vizată.
- Ordinele sunt executate de un broker, clienţii lucrând fiecare cu un anume broker din societate,
pentru care se reţin următoarele caracteristici: cod şi nume.
- Tranzacţiile realizate pe baza ordinelor primite prezintă: un număr, data tranzacţiei, numărul
acţiunilor care au făcut obiectul tranzacţiei, preţul la care s-a realizat tranzacţionarea.
- Un ordin poate fi acoperit prin mai multe tranzacţii realizate pe piaţă.

În MCD s-au definit următoarele tipuri de entităţi:

Client definit prin atributele: Cod-client (identificator), nume-client, adresa, cont, banca. Societăţi definit
prin: Cod soc (identificator), denumire, capital, cotaţia maximă, cotaţia minimă (aceste două ultime
atribute au rol informativ iar prin cerinţele problemei nu s-a cerut şi reţinerea datelor la care s-au
înregistrat aceste valori).
Ordin definit prin: Nr-ordin (identificator), data ordin, ora, nr-acţiuni. Se remarcă în cadrul MCD
specializarea totală (cu specificarea restricţiei de excluziune între entităţile subtipurilor) prin definirea
subtipurilor Vânzare şi Cumpărare necesare reţinerii preţului minim de vânzare respectiv preţului maxim
de cumpărare.
Tranzacţii: Nr-tranz (identificator), data tranz, nr. acţiuni, preţ tranz.
Broker: Cod-broker (identificator), nume broker.

Figura 2.44
2.6 Reprezentarea timpului
Modulul EA nu oferă formalisme specializate pentru reprezentarea timpului. Dar elementul timp
trebuie de cele mai multe ori să se regăsească în cadrul modelului conceptual definit. Aşa se explică
faptul că modelul EA permite atât reprezentări sincronice (care aduc o viziune atemporală) sau
diacronice (care surprind elementul timp în MCD).
Să presupunem că dorim să realizăm un MCD care să permită reprezentarea consumului specific
de materii prime necesare fabricării fiecărui subansamblu din componenţa unui produs finit (Figura 2.45).
Modelul conceptual din figura 2.45 este o reprezentare sincronică. Realitatea modelată nu a impus
integrarea în MCD a elementului timp.
Sunt însă situaţii în care în cadrul MCD este necesar să integrăm şi elementul timp. Să
presupunem că dorim să reprezentăm cursele realizate de fiecare aeronavă a unei companii de
transporturi aeriene. Ne interesează să cunoaştem ce aeronavă a asigurat fiecare din cursele
programate. Vor fi utilizate în cadrul modelului două tipuri de entităţi AVION şi CURSA între cele două
stabilindu-se tipul de asociere REALIZEAZĂ.

Produs 0,n 1,n Componentă

Cod produs Compus Cod

Denumire Den. compon.
Preţ catalog Nr. compon.

1,n

Necesită

Cantitate

MaterPrimă
1,n
Codmat
Den mat

Figura 2.45 Reprezentare sincronică

Aeronavă 1,n 1,n Cursă

Nr-id Nr cursă
Marca Realizează Destinaţie
Tip Ora-plecării
Km parcurşi Ora-sosirii
Data reparaţiei

Figura 2.46

Reprezentarea sincronică din figura 2.46 evidenţiază ce curse au fost realizate de fiecare
aeronavă din dotare dar nu şi când. Cursa cu numărul 123 având destinaţia Paris se efectuează în
fiecare zi de joi a săptămânii şi deci nu putem identifica cu ce aeronavă s-a realizat într-o numită zi. Dacă
însă dorim să avem o evidenţă clară a curselor realizate de o anumită aeronavă această reprezentare se
dovedeşte neacoperitoare. Realizările tipului de asociere se identifică după Nr-ID şi Nr cursă. Cum
acelaşi avion poate realiza aceeaşi cursă, de mai multe ori identificarea realizărilor tipului de asociere nu
se mai poate realiza. Acest lucru impune introducerea în cadrul modelului a unui tip de entitate
temporală.
 Caracteristic pentru entităţile temporale este faptul că ele sunt definite adesea printr-un singur
atribut (data calendaristică). În cazul în care prezintă mai multe atribute, fiecare dintre acestea reprezintă
o unitate de măsură a timpului (zi, oră, minut) iar ansamblul acestor atribute formează identificatorul
tipului de entitate.
Observăm că introducerea timpului de entitate temporală a condus la transformarea tipului de
asociere binară existent iniţial între AVION şi CURSA într-o asociere ternară.

Data cursei

Data

Aeronavă 1,n Cursă

Nr-id Nr cursă
Marca Realizează Destinaţie
Tip Ora-plecării
Km parcurşi Ora-sosirii
Data reparaţiei
1,n 1,n
Figura 2.47 Reprezentare diacronică

O altă modalitate de a introduce elementul timp în cadrul modelului EA este reprezentată de

introducerea evenimentelor datate. Din activitatea practică cunoaştem faptul că fiecare eveniment produs
(o aprovizionare, încheierea unui contract, etc.) se concretizează într-un document care pe lângă număr
şi prezentarea conţinutului prezintă şi o dată.
Să luăm cazul unei societăţi de asigurări şi să ne limităm la gestiunea doar a poliţelor de asigurare
a bunurilor. În cadrul MCD trebuie să cuprindem atât clienţii societăţii, bunurile pe care aceştia le asigură
şi riscurile pentru care se face asigurarea. Evenimentul asigurare bun care are loc se consemnează
într-un document numit poliţă de asigurare. Acest eveniment se va regăsi în cadrul MCD sub forma unui
tip de entitate (Poliţă).

1,n 1,1
Client
Poliţă
Cod client Încheie
Nume Nr poliţă
Tip Data poliţă
Adresă
1,n

1,n

Precizează
Asigură

1,n

1,1
Riscuri
Bun asigurat
Cod risc
Denumire Denrisc
Adresa
Val bun
Val asigurată

Figura 2.48 Introducerea evenimentelor datate în modelul EA

2.7 Validarea modelelor externe
Validarea MCD nu se realizează doar prin regulile de validare şi normalizare (prezentate într-un
capitol anterior) vizând elemente de “construcţie” ale modelului ci şi prin controlul completitudinii
modelului. Trecerea la etapa modelării logice nu se poate face fără verificarea completitudinii modelului
conceptual.
MCD este definit prin prisma unei singure prelucrări a datelor, ori în realitate diverşii utilizatori
prelucrează datele în conformitate cu propriile lor nevoi având o percepţie diferită (modele externe)
asupra datelor.

Realitate

Model Model
Extern 1 Extern n
Model
Extern 2

Model
Conceptual

Figura 2.49. Modele externe ale datelor

Fiecărei prelucrări (consultare sau actualizare) realizate de un utilizator îi corespunde un model

extern al datelor (MED) care reflectă viziunea particulară a utilizatorului asupra realităţii. Acest model
extern propriu unei anumite prelucrări implică un bloc logic de date constituit pe baza formalismului EA.
Dacă în urma definirii modelelor externe constatăm că fiecare dintre acestea este deductibil din MCD
definit înseamnă că modelul conceptual al datelor răspunde criteriului de completitudine.
În construirea modelelor externe se recomandă utilizarea următoarelor reguli:
- se defineşte un model extern pentru fiecare consultare sau actualizare impusă de o prelucrare;
- modelul extern se construieşte utilizând formalismul EA. În construirea modelului EA
corespunzător ME se ţine seama de faptul că :
- entităţile ME pot să nu prezinte identificatori;
- atributele, entităţile şi asocierile ME pot să nu-şi găsească un corespondent în
MCD;
- atributele ME corespunzătoare celor aparţinând MCD vor trebui să prezinte acelaşi
nume cu acestea.

În cazul unei actualizări ME construit va reda spre exemplu, fluxul de date implicat în cadrul
prelucrării. În cazul operaţiei de actualizare privind facturile emise clienţilor ME se prezintă astfel:
 Factura
NR FACTURĂ
Data factură
Client
Val-factură

1,n
CUPRINDE

1,1

COD PROD
DEN PROD
UM
CANT FACT
PREŢ
VAL-PRODUS
TVA-PRODUS
TOTAL-PRODUS

Figura 2.50 ME al operaţiei de actualizare

Din analiza ME prezentat în figura 2.50 constatăm că unele atribute îşi găsesc corespondent
direct în MCD, altele sunt atribute calculate (VAL-PRODUS, TVA-PRODUS, TOTAL-PRODUS) iar unele
atribute, deşi definesc aceleaşi caracteristici, sunt definite cu nume diferite de cele utilizate în MCD
(Client în loc de DEN CLIENT de exemplu), deci prin echivalenţă îşi găsesc un corespondent în MCD.

Figura 2.51 Verificarea completitudinii

MCD
Atributele calculate aparţinând ME vor fi descompuse în conformitate cu algoritmii de calcul
utilizaţi în vederea identificării operanzilor.
Se verifică apoi măsura în care atributele se regăsesc direct sau prin echivalenţă în MCD.
În măsura în care ME cuprinde şi atribute care nu se regăsesc în MCD este necesară completarea
acestuia cu atributele omise.
 Reguli de validare a modelelor externe

CONSULTARE
1. Atributele externe trebuie să fie atribute conceptuale
2. Se verifică existenţa în MCD a atributelor necesare identificării datelor în procesul consultării.
3. Cardinalităţile asocierilor externe trebuie să fie incluse în cardinalităţile asocierilor aparţinând
MCD corespunzătoare semantic.
ACTUALIZARE
1. Orice atribut extern serveşte fie la identificarea unui element conceptual de actualizare
(atribut, entitate) fie la obţinerea valorii de actualizare a unui element conceptual.
Această regulă permite identificarea atributelor omise ce vor completa MCD precum şi la
identificarea atributelor ME care vor fi şterse deoarece nu servesc niciunuia din scopurile amintite.
2. Cardinalităţile asocierilor externe trebuie să se includă în cardinalităţile asocierilor
conceptuale corespunzătoare semantic.
3. Orice element conceptual trebuie să poată fi actualizat (inserat, modificat, şters) prin cel
puţin un model extern.
Se vor defini modele externe omise care realizează actualizarea elementelor conceptuale.

2.8 Probleme recapitulative

Probleme rezolvate
Problema 1
În cadrul subsistemului informatic privind calculaţia costurilor se urmăreşte evidenţierea
consumului de materii prime aferent comenzilor de produse lansate în fabricaţie. Ştiind că :
• În comandă se precizează secţia producătoare şi cantitatea de fabricat din produsul respectiv;
• Eliberarea materiilor prime din gestiune pentru consum se face pe baza bonului de consum în
care se specifică: numărul şi data bonului, gestiunea care eliberează materialele, comanda de
producţie pentru care se eliberează materialele, cantităţile şi preţurile materiilor prime date în
consum;
• Orice produs din nomenclatorul de fabricaţie se defineşte prin: cod, denumire, preţ de livrare;
• Materiile prime se definesc prin: codul materiei prime, denumire, unitate de măsură, gestiunea
în care se depozitează;
• Intrările de materii prime în gestiuni se realizează pe baza documentului Notă de recepţie şi
constatare de diferenţe (NRCD) în care se consemnează: numărul şi data documentului,
furnizorul, gestiunea primitoare, materia primă recepţionată, cantitatea şi preţul de
aprovizionare.
Restricţii:
• O comandă de producţie se referă la un singur produs;
• O materie primă poate fi stocată în mai multe depozite;
• Preţul fiecărei materii prime diferă de la un furnizor la altul;
• Un depozit are un singur gestionar.
Se cere:
1. Identificaţi mulţimea atributelor aparţinând problemei de rezolvat;
2. Realizaţi diagrama dependenţelor funcţionale;
3. Realizaţi modelul EA pe baza dependenţelor funcţionale identificate.
REZOLVARE:
1. Atributele care definesc realitatea modelată sunt:
Cod produs Den prod Preţ livrare
Nr. comandă Data lansării cdă Secţia de
producţie
Cantitate produs Nr. bon consum Data bon
Gestiune Cod material Den material
Cantitate eliberată Nr NRCD Cantitate intrată
Preţ intrare Furnizor Gestionar
2. Diagrama dependenţelor funcţionale este:

Cod produs

Den produs
Cantitate comandă

Preţ livrare

Nr. comandă Nr bon consum

Data bon
Data lansării

Secţia

Cantit. eliberată
Cod material
Furnizor
Den material

Unit. măsură
NRCD

Gestiune
Cantit. Intrată,
Gestionar Pret Intrare
Modelul EA este:

PRODUS
COMANDĂ
0,N 1,1
Cod produs
Den prod Cuprinde Nr cda
Preţ livrare Data lansare
Cant cdă
Secţia

NRCD 1,N

Nr NRCD
Data NRCD Necesită
Furnizor
1,1

1,N BON CONSUM

Cuprinde
Intrate Cant elib. Nr bon
Data bon
1,N
Cant intr
Preţ intr 0,N
1,N

MATERIALE
0,N
1,N
Cod material
Den material

1,N

Stochează
Stoc iniţial

1,N

GESTIUNE

Nr Gestiune
Gestionar

Problema 2
Să se elaboreze MCD pentru evidenţa poliţelor de asigurare încheiate de o societate specializată
în asigurări de bunuri ştiind că:
• Un client poate încheia una sau mai multe poliţe de asigurare de bunuri. Fiecare client primeşte un
cod unic şi este definit prin nume, adresă, cod numeric personal;
• O poliţă de asigurare se întocmeşte pentru unul sau mai multe bunuri de către un agent de asigurări
şi cuprinde numărul, data întocmirii, perioada asigurării bunului;
• Pentru fiecare bun asigurat se specifică: numele bunului, adresa unde se află, valoarea bunului,
valoarea pentru care se asigură, riscul/riscurile pentru care se asigură (furt, incendiu, inundaţie etc);
• Pentru fiecare poliţă încheiată se stabileşte: valoarea primelor de asigurare pe care clientul urmează
să le achite şi data limită a plăţii, data de la care operează asigurarea, data de sfârşit a perioadei de
asigurare;
• Plata primelor de asigurare se face pe bază de documente (chitanţă, ordin de plată, filă cec etc
identificate prin număr şi dată).
REZOLVARE:

Notă: Entităţile Bun şi PRIMĂ nu prezintă indentificator propriu. Ele se vor identifica prin valoarea
atributului Numele bunului şi rolul pe care entitatea POLIŢĂ îl joacă în asocierea Priveşte şi respectiv
valoarea atributului Nr primă şi rolul pe care îl joacă entitatea POLIŢĂ în asocierea Prevede.

Problema 3
O societate de turism doreşte să implementeze un sistem informatic privind gestiunea hotelieră.
Să se elaboreze MCD ştiind că se doreşte realizarea evidenţei spaţiului de cazare (camerele sunt de
tipuri diferite – simplă, dublă, apartament – iar tariful diferă de la cameră la cameră chiar dacă sunt de
acelaşi tip), a serviciilor suplimentare oferite în unele camere (televizor, fax, frigider etc) care se tarifează
separat. Nota de plată se întocmeşte clientului în funcţie de camera ocupată, numărul zilelor de cazare,
serviciilor suplimentare solicitate. Rezervările se fac pe camere şi nu pe locurile din cameră. Verificaţi
modelul EA elaborat pe baza matricei simplificate a dependenţelor funcţionale.
REZOLVARE:

CLIENT

CAMERĂ Cod numeric

1,n Nume
Nr cameră 1,n Adresă
Ocupă
Tip Act identitate
Tarif cameră data debut
data sfârşit
0,n
0,n

Are
Primeşte
SERVICII
1,n 1,1
Tip serviciu
Tarif/zi NOTĂ PLATĂ
0,n
1,n
Nr notă
Priveşte Data

Matricea simplificată a dependenţelor funcţionale este:

1 6 10 12 1+6
1. Nr cameră 1
2.Tip cameră 1
3. Tarif cameră 1
4. Dată debut sejur 1
5. Dată sfârşit sejur 1
6. Cod numeric personal 1
7. Nume client 1
8. Adresă 1
9. Act identitate 1
10. Nr. notă plată 1
11. Data notă plată 1
12. Tip serviciu 1
13. Tarif serviciu/zi 1

Problema 4
Un spital doreşte să implementeze un sistem informatic de gestiune prin care va putea avea o
evidenţă clară a: pacienţilor (date personale, diagnostic), medicilor şi responsabilităţile lor pe saloane,
medicaţiei şi procedurilor de tratament prescrise pacienţilor, repartizării medicilor şi saloanelor pe secţii.
Reguli de gestiune:
• Un pacient, în decursul unei internări, este sub supravegherea aceluiaşi medic şi rămâne în
acelaşi salon;
• Pacienţii din acelaşi salon sunt sub îngrijirea aceluiaşi medic;
• Un medic are o singură specialitate şi lucrează în cadrul unei singure secţii;
• O procedură se poate efectua într-un singur cabinet, în ziua şi ora fixată.
Realizaţi diagrama dependenţelor funcţionale şi apoi modelul EA.

REZOLVARE:

Modelul EA elaborat pe baza diagramei dependenţelor funcţionale este:

 Cod medic Cod pacient Cod diagnostic

Nume

Nume medic
Den diagnostic
Adresă
Cod Secţie
Cod
Data medicament
Nume secţie naşterii

Denumire

Nr salon Doză
Preţ
Act identit.

Cod procedură
Capacitate
Nume procedură
Pacient
Data, ora
data internării
Cod-id data externării
Nume Sala
0,n 0,n Proceduri
Adresă
Data naşterii
Face Cod procedură
Act identit.
Nume procedură
Data,ora Cabinet

1,n
0,n
Internat
Medic
Data int, Data
Cod-medic extern
Nume
Specialitate
0,n Primeşte

Secţie Dozaj
1,1
Cod secţie
0,n
Nume secţie

Lucreză Medicament
1,n
Cod medicament
1,n Den medicament
Preţ
1,n
Are

1,1
1,1
Răspunde

Salon

Nr salon
Capacitate
Probleme propuse

1. Ştiind că S.C. Agroprod este organizată pe mai multe ferme, fiecare fermă lucrând cu angajaţi
permanenţi să se elaboreze MCD privind evidenţa personalului şi calculul salariilor aferente timpului
lucrat. Un angajat ocupă un post pentru care s-a stabilit funcţia şi salariul. Fiecare post are un număr unic
în cadrul fermei, iar fiecare fermă are un şef. Unor angajaţi li se fac reţineri reprezentând chirii, popriri,
rate pe baza documentelor emise de creditori pentru care se reţine: nr.doc, data doc, tip reţinere,
emitent, suma datorată. Pentru fiecare angajat se reţine codul unic de identificare, numele, o dată a
angajării în firmă, data naşterii. În fiecare lună se consemnează în documentul Foaie colectivă de
prezenţă pentru fiecare angajat numărul orelor lucrate, numărul orelor absentate, numărul orelor de
concediu de odihnă, numărul orelor de concediu medical.

2. Să se elaboreze MCD pentru sistemul informatic privind gestiunea mărfurilor într-o firmă. Modelul va
trebui să evidenţieze informaţiile privitoare la: cantităţile şi preţurile de aprovizionare ale mărfurilor de la
furnizori, livrările de mărfuri către clienţi (preţul de livrare al mărfurilor este diferit de cel de achiziţionare).
Mărfurile se stochează în depozite. Fiecare depozit are un singur gestionar. Pentru fiecare marfă se
cunoaşte stocul iniţial la începutul perioadei şi depozitul în care se află. O anumită marfă este stocată în
unul sau mai multe depozite. Fiecare client este înscris într-un nomenclator cu numele, adresa, telefonul,
contul, banca şi codul de identificare.

3. Pentru un magazin de muzică se doreşte crearea unei baze de date cuprinzând oferta acestuia.
Realizaţi MCD necesar ştiind că baza de date va stoca următoarele informaţii: numele fiecărui album,
casa producătoare, anul înregistrării, preţul (care diferă în funcţie de suport: CD sau casetă), genul în
care se încadrează albumul (rap, dance, rock etc), melodiile cuprinse, durata fiecărei melodii, interpretul,
compozitorul. Menţionăm că o melodie poate avea mai mulţi autori şi poate fi interpretată de mai mulţi
cântăreţi.

3. Fie următorul MCD:

CONTRACTE
PRODUSE
Nr contract
Cod produs Data contract
Den produs PRIVESC Cantitate contractată
Unit. măsură Cod produs
Preţ Data livrării
TVA

LIVRARE
ÎNCHEIE

CLIENŢI
FACTURA
Cod client
Nr factură Den client
Data factura Adresă
Cantitate livrată

Ştiind că:
• Obiectul unui contract este reprezentat de unul sau mai multe produse pentru care se specifică
cantitatea contractată;
• Data livrării se referă la întregul contract;
 • Livrarea produselor se face pe bază de factură care cuprinde cantitatea facturată şi preţul de
facturare pentru produsele livrate (într-o factură pot fi înscrise unul sau mai multe produse).

Se cere:
- Stabiliţi cardinalităţile.
- Elaboraţi matricea simplificată a dependenţelor funcţionale şi pe baza informaţiilor astfel obţinute
stabiliţi dacă MCD este corect elaborat. În caz contrar oferţi soluţia corectă pentru MCD. Precizaţi
restricţiile de integritate corespunzătoare.
- Dezvoltaţi MCD ştiind că obiectul de activitate este reprezentat de fabricarea de produse şi
prestarea de servicii; contractele încheiate precizând produsele sau serviciile solicitate de clienţi.
Realizaţi specializările implicate de această precizare.

4. Elaboraţi MCD pentru sistemul informatic privind gestiunea depozitelor bancare constituite de clienţii
unei bănci comerciale. Depozitele se pot constitui în lei sau valută (dolari USA sau Euro). Soldul
minim pentru un depozit în lei este de 1000000 iar în valută 1000. Depozitele se constituie pe termen
de 30, 60, 90, 180, 360 de zile, fără capitalizare, dobânda fiind de 30% pe an pentru termene sub 90
de zile şi 33% pentru restul termenelor. Un client poate avea oricâte depozite. Sistemul va reţine
numărul şi data documentelor de plată a dobânzii aferente depozitelor. Stabiliţi restricţiile impuse de
problema de rezolvat. Dobânzile neridicate la scadenţă se înregistrează într-un cont la vedere
deschis pe numele titularului depozitului bancar. Fiecare cont astfel deschis are un număr unic.