Capitolul 4.

Modelarea datelor logice

Modelarea datelor logice este una din cele mai puternice metode de a stabili
şi a menţine controlul asupra resurselor de date. Există mai multe tehnici de
modelare a datelor logice. La sfârşitul capitolului vom enumera câteva dintre
ele. Pentru a ilustra proprietăţile datelor unei intreprinderi pe care un model
de date logice le poate captura, vom descrie o tehnică grafică, care va explica,
de asemenea, şi multe din celelalte abordări de modelare.
Modelele de date logice pot fi reprezentate atât prin diagrame cât şi
prin instrucţiuni de limbaj. Noi am ales diagramele.

4.1. Introducere

Modelarea este o tehnică importantă pentru a defini cerinţele de a

analiza proiectările alternative. Un model reprezintă caracteristici de interes
particular suprimând detalii considerate relativ neimportante. Diferitele
tehnici de modelare se concentrează asupra diferitelor tipuri de caracteristici
ale unui sistem, de exemplu asupra datelor, sau asupra proceselor sau asupra
dinamicii.
Modele de date logice. Un model de date logice este o reprezentare
riguroasă a semnificaţiei datelor într-un anumit domeniu de interes. Se mai
numeşte model semantic de date deoarece accentul modelului cade pe
semnificaţia datelor (i.e. semantica). Un model de date logice tipic reprezintă
entităţi, atribute si relaţii. Asa cum am spus in capitolul 1, o entitate este ceva
care există in lumea reala, un concept, o persoana, un loc, un lucru sau un
eveniment despre care noi vrem să păstrăm fapte. Un atribut este o
proprietate sau o caracteristică a unei entităţi. Un model de date logice este
reprezentat tipic folosind o tehnologie grafică. De exemplu, cutiile pot
reprezenta entităţi iar săgeţile pot reprezenta relaţii intre entităţi (fig. 3.5.).
Modele de date fizice. Modelele de fizice reprezintă implementarea
structurilor de date şi vizează optimizarea resurselor, cum ar fi spaţiul de
memorie şi timpii de acces. Elementele lor includ, în general, înregistrări
fizice, fişiere, adrese şi pointeri. Le vom discuta în capitolul 10.
Modele de activitate. Modelele de date logice şi fizice pot fi
contrastate cu modele de activitate (numite şi modele funcţie sau modele
proces) care reprezintă procese (mai de grabă decât date) şi relaţiile lor.
Aceste modele se reprezintă tipic printr-o notaţie grafică în care cutiile (sau

43
cercurile) reprezintă activităţi iar arcele între cutii reprezintă fluxul
activităţilor. Fig.3.5. reprezintă un model de activitate.
Un model de actvitate se focalizează pe procese mai mult decât pe
fluxul între procese. Modelele de date, pe de altă parte, se focalizează pe
semnificaţiile entităţilor, atributelor şi a relaţiilor de date. Tehnicile de
modelare a datelor reprezintă, uzual activitităţile care folosesc datele. Dacă
nu indicăm altfel, vom folosi termenul de model de date pentru a referi un
model de date logic (mai de grabă decât model de date fizic) ceea ce este
consistent cu terminologia general folosită în domeniul bazelor de date.

4.2. Folosirea modelelor de date logice

Modelele de date au două scopuri principale: de a facilita comunicaţiile

despre date şi de a ajuta în descoperirea semanticii datelor.
Comunicarea semnificaţiei datelor. Doarece ele sunt reprezentări
riguroase, modelele de date pot fi folosite pentru a transmite unei alte
persoane înţelegerea semnificaţiei datelor. Atâta timp cât persoanele ce
comunică sunt familiare cu notaţia folosită în model, comunicarea va fi
înţeleasă. Companiile îşi standardizează modul în care modelează datele,
selectând o abordare particulară pentru modelarea datelor şi folosind-o peste
tot în eforturile lor de dezvoltare a sistemelor şi a bazelor de date.
Descoperirea semanticii datelor. Construirea unui model de date
cere a se răspunde la întrebări despre entităţi şi relaţii. Făcând aşa,
modelatorii descoperă semnificaţia datelor organizaţiei, care există indiferent
dacă se întâmplă sau nu ca ele să fie înregistrate într-un model formal de date.
Entităţile şi relaţiile lor sunt fundamentale pentru toate organizaţiile; totuşi,
semnificaţia datelor poate rămâne nedescoperită (şi probabil prost înţeleasă)
până când organizaţia nu le documentează cu succes.
Un model de date face mai uşoară descoperirea semanticii datelor.
Fără un mod de a reprezenta entităţi şi relaţii, este uşor să spunem. “O, da,
suntem cu toţii de acord că aceasta arată cum se leagă produsele cu
distribuitorii”, fără a şti într-adevăr cu ce suntem de acord şi nici nu este
simplu ca “distribuitorii reprezintă produsele”. De exemplu, anumiţi
distribuitori pot reprezenta anumite produse; anumite tipuri de produse pot fi
reprezentate numai de anumiţi distribuitori; distribuitorii unui produs se pot
schimba în timpul vânzării, şi aşa mai departe.

4.3. Aplicarea modelării de date logice

Facilitând comunicaţiile şi descoperind semantica datelor, modelarea datelor

este utilă pentru:
 creşterea înţelegerii datelor unei organizaţii şi a operaţiilor asupra lor
 documentarea resurselor de date
 folosirea pachetelor software

44
 planificarea sistemelor de informaţii
 proiectarea sistemelor informatice
 integrarea resurselor de date
 proiectarea şi implementarea bazelor de date
Înţelegerea datelor. Atunci când se dezvoltă modele de date, atât
personalul de prelucrare date cât şi utilizatorii care sunt experţi în domeniul
modelului, sunt necesari. Un model de date construit de personalul care
prelucrează date singuri şi făcut pentru a portretiza date despre produse este
diferit de unul făcut de ingineri, producători şi distribuitori. De fapt, modelul
de date construit numai de personalul de prelucrare date este incorect şi/sau
inexact. Astfel utilizatorii cruciali pentru dezvoltarea cu succes a modelelor
de date.
Documentarea datelor. Ca un vehicul de comunicaţii, un model de
date este adesea un bun mod de a explica documentat datele. Dacă tehnica de
modelare este capabilă şi clară, atunci modelele sale pot fi considerabil mai
valabile ca şi documentare decât limbajele naturale.
Evaluarea software-ului. Pe măsură ce pachetele software devin
mai populare, companiile se întreabă tot mai des: “ Se va potrivi acest
software în mediul nostru?”. Răspunsul depinde de ce face software-ul şi de
modelul de date rezultat. De exemplu, un pachet de contabilitate care
presupune un angajat este plătit dintr-un singur cont (al proiectului la care
lucrează) nu se va potrivi bine într-o companie ai cărei angajaţi sunt plătiţi
din mai multe conturi. Dacă pachetul de contabilitate a fost bine documentat
cu un model de date logice şi dacă cumpărătorul candidat este familiar cu
modelul de date logice şi dacă cumpărătorul poate prezice mai bine dacă un
pachet particular de contabilitate este sau nu alegerea potrivită.
Planificarea sistemelor informatice. Deoarece facilitează
comunicaţiile şi descoperirea, modele de date sunt instrumente puternice
pentru planificarea sistemelor informatice şi a bazelor de date. Modelele de
date sunt folosite în BSP (Business Systems Planning - IBM), SPM
(Strategic Planning Methodology - Janus Martin) şi RAP (Requirements
Analysis and Planning - DACOM) pentru a identifica ariile principale de date
ale unei intreprinderi.
Ca parte a procesului de planificare, entităţile de nivel înalt sunt apoi
mapate pe unităţi organizatorice (cine este responsabil pentru ce date?),
activitate (ce funcţii se fac pentru ce date?) şi fişiere şi sisteme existente
(unde sunt datele stocate şi gestionate?). Planificarea sistemelor informatice
poate include identifcarea proiectelor de implementare şi descrierea
domeniului datelor care se implementează de către fiecare proiect.
Proiectarea sistemelor informatice. Un proiect de implementare
poate adăuga la un model de planificare date de nivel înalt detalii despre
atribute, volume şi frecvenţe de acces pentru datele din domiul său. Modelul
detaliat rezultat poate fi transformat într-o proiectare de bază de date fizică.

45
Modelarea datelor poate fi folosită efectiv pentru a documenta mediul
pertinent existent de date şi de a ajuta la proiectarea viitorului mediu de
date. Modelarea datelor folosită pentru a captura mediul prezent este un
proces de descoperire, iar modelarea datelor folosită pentru a proiecta viitorul
mediu cere invenţie. De exemplu, fig.4.1. ilustrează în mod simplu modelele
prezent şi viitor. Fără a explica tehnica de diagramare în acest punct, figura
scoate în evidenţă un mediu nou descoperit în care un distribuitor vinde
numai un singur tip de produs (de ex. maşini de scris) şi un mediu în care
responsabilităţile distribuitorului au fost expandate pentru a include mai
multe tipuri de produse (de ex. maşini de scris, procesoare de texte,
calculatoare). În general, un model de date pentru viitor nu este o pură
invenţie ci el impărtăşeşte mult din modelul rădăcină al prezentului. Figura
4.2. arată un mediu existent în care studentii fără licenţa (undergraduate) nu
se pot înscrie la cursuri postuniversitare şi un mediu viitor în care cursurile
graduate au fost deschise pentru aceştia.
Produs Produs

este vândut de este vândut de

Vânzător Vânzător

a)mediul prezent b) mediul viitor

Fig.4.1. Modelele prezent şi viitor

Integrarea resurselor de date. Modelele de date pot ajuta, de

asemenea, la integritatea resursei de date şi sunt folosite pentru a reprezenta
schemele conceptuale, aşa cum s-a arătat în capitolul 3. Dacă modelele
produse de către proiectele de implementare folosesc o sintaxă consistentă şi
clară, atunci aceste modele împreună dau o vedere de ansamblu despre modul
în care se potrivesc datele lor împreună, iar inconsistenţele şi redundanţele
pot fi identificate şi rezolvate.
Modelul de date integrate dezvoltat de către o intreprindere este
schema sa conceptuală. Această vedere neutră de date poate fi mapată pe

46
diferite structuri de baze de date fizice (scheme interne), aşa cum sunt ele
implementate şi pe vederi utilizator (scheme externe), aşa cum sunt ele
identificate. Poate fi dificil a integra resursele de date fără a folosi modele de
date. Structurile fizice, de exemplu, nu prezintă o imagine completă.
Structurile baze de dat fizice, ca şi structurile de fişiere convenţionale, sunt
proiectate pentru a se întâlni cu obiectivele de performanţă ale aplicaţiilor
particulare şi nu pentru a oglindi structurile logice. De exemplu în figura 4.3.
înregistrarea PARTE din fişierul A conţine un grup repretitiv cu distribuitorii
acelei părţi. Aplicaţiile care folosesc fişierul A accesează datele despre
distribuitori pentru părţi particulare. Fiecare parte are mai mulţi distribuitori
asociaţi. Din contră înregistrarea DISTRIBUITOR din fişierul B este într-o
structură de înregistrare care spune să fiecare distribuitor oferă mai multe
părţi. Aplicaţiile care folosesc fişierul B accesează date despre părţi pantru
distribuitori particulari. Fiecare distribuitor are mai multe părţi asociate.

Student Curs postuniversitar

Fãrã diplomã Cu diplomă ia/este luat de

Fig.4.3a. Relaţii mai mulţi la mai mulţi

Combinaţia acestor două vederi indică faptul că există mai multe

relaţii “mai mulţi la mai mulţi” între părţi şi distribuitori, aşa cum se arată în
fig.4.3.c. Fiecare cutie din figură reprezintă o entitate iar arcul repreintă o
relaţie între entităţi. Punctele groase de la sfârşitul arcului indică că relaţia
este “mai mulţi la mai mulţi”.
Această structură înseamnă că o parte particulară poate fi oferită
demai mulţi distribuitori şi că orice distribuitor poate oferi mai multe părţi.
Nici o structură de fişier fizic nu arată imaginea completă ci numai modelul
de date logice superpus arată integrarea celor două orientări vedere de date.

47
 Detectarea structurii logice adevărate a datelor din structurile fizice
devine chiar mai grea atunci când relaţiile inter-înregistrări sunt îngropate în
codul aplicaţiilor. De exemplu, dacă părţile din fişierul PARTI sunt legate de
distribuitorii din fişierul DISTRIBUITORI printr-o tabelă codificată
complicat într-o aplicaţie program, atunci descoperirea relaţiei logice între
părţi şi distribuitori depinde de descifrarea acelei tabele. O primă abordare în
proiectarea bazei de date este de a construi modelul de date şi apoi de a-l
folosi ca temelie pentru proiectarea şi implementarea bazei de date fizice.
Utilizatorii trebuie să contribuie la modelarea datelor, chiar dacă ei nu trebuie
să fie implicaţi în proiectarea bazei de date fizice.
Ar putea fi util, de asemenea, să se construiască un model de date
pentru un domeniu deja suportat de către fişierele şi bazele de date fizice.
Acest model de date poate fi apoi mapat pe structurile fizice; structurile fizice
sunt folosite pentru domeniu; modelul de date este folosit pentru
documentarea semanticii datelor; maparea este folosită pentru a documenta
modul de stocare al datelor. Modelul de date poate arăta cum sunt legate
datele din diferite baze de date fizice şi fişiere.

Student Curs postuniversitar

ia

este luat

Fără diplomă Cu diplomă

Fig.4.3b. Relaţii mai mulţi la mai mulţi

Susţinerea proiectării bazelor de date fizice. Un model de date dă

proiectantului de baze de date fizice informaţii despre ce date ar trebui
incluse în baza de date, ce tipuri de relaţii structurează baza de date şi cum se
leagă baza de date de alte baze de date. A construi un model de date
înseamnă în primul rând a introduce date corecte în baza de date. Tehnicile

48
de proiectare bază de date fizice se folosesc apoi pentru a asigura un acces
eficient la date.

Păstrarea consistentă a tehnicii. Organizaţiile care folosesc modelarea

datelor au avut beneficii folosind consistent o tehnică de modelare particulară
pentru planificarea sistemelor informatice, planificarea proiectării şi a
implementării bazelor de date. Invers, atunci când mai multe tehnici de
modelare sunt folosite pentru aceste diferite faze ale dezvoltării sistemelor,
pot apare probleme în traducerea semnificaţiei modelului construit cu o
tehnică într-un model reprezentat într-o altă tehnică.

4.4. Caracteristicile tehnicilor de modelare de date logice

O tehnică de modelare date tehnice trebuie:

 să producă diagrame grafice
 să ofere o reprezentare explicită a semanticii
 să fie la un nivel potrivit de detaliere
 să fie independentă de DBMS
 să aibă un suport automatizat
 să fie uşor de învăţat şi folosit
Diagrame grafice. Majoritatea tehnicilor de modelare de date aflate
în folosinţă astăzi oferă atât un limbaj de modelare (cu o sintaxa bine definită,
cuvinte cheie, etc.) cât şi diagrame grafice ale modelelor. Pictogramele
constau din cutii sau cercuri pentru a reprezenta entităţi şi din arce sau linii
pentru a reprezenta relaţii. Anumite tehnici folosesc forme diferite pentru
diferite forme de entităţi: dreptunghiuri şi dreptunghiuri rotunjite pot fi
folosite în acelaşi model pentru a distinge între entităţi independente de
identificator şi entităţi dependente de alte entităţi pentru identificarea lor.
Anumite tehnici folosesc convenţii diferite pentru linii pentru
diferite tipuri de relaţii, de exemplu, linii unice pentru grupări şi linii duble
pentru relaţii “este un fel de”.
Alte tehnici folosesc un simbol special, ca de exemplu un cerc,
pentru a arăta atributele.
Reprezentarea explicită a semanticii. Există un domeniu de
preferinţă personală pentru a reprezenta grafic cât mai bine semantica datelor.
Anumite persoane preferă o mulţime de simboluri diferite, fiecare cu o
semnificaţie specială, pe când alţii preferă un munăr mai mic de simboluri,
care fac ca diagramele modelului să apară mai simple. Tehnica ideală de
modelare de date produce diagrame model care reprezintă clar semnificaţiile
datelor. Diagramele pot să fie neschimbătoare, dar un simbol nu poate avea
mai multe semnificaţii diferite.
Nivelul potrivit de detaliere. O tehnică de modelare trebuie să
ofere detalii la nivelul potrivit pentru folosinţa utilizatorului. Modelele de

49
date pentru planificarea sistemelor informatice de nivel înalt (la nivelul
companiei sau diviziei) trebuie să păstreze mai puţine detalii decât modelele
pentru proiectarea bazelor de date fizice. Tehnicile de modelare de date cele
mai flexibile suportă diferite nivele de detalii. De exemplu, ele pot fi folosite
pentru a construi modele care arată numai entităţile şi relaţiile de nivel înalt,
dar şi modele care arată toate entităţile, atributele detaliate şi relaţiile rafinate.
Independenţa DBMS-ului. O tehnică de modelare de date trebuie
să fie independentă de orice DBMS particular şi trebuie să fie capabilă să
reprezinte modele care pot fi suportate de o varietate de DBMS-uri. Multe
din tehnicile de modelare a datelor sunt independente de DBMS. Câte o dată,
tehnicile de modelare a datelor folosite cu un DBMS particular sunt
considerate de nivel general, aşa cum sunt modelul ierarhic, modelul reţea şi
modelul relaţional. Problema majoră a acestor trei tehnici este existenţa de
limitări în semantica datelor pe care le pot reprezenta.
Suport automatizat. Tehnica de modelare de date ideală are suport
automatizat pentru a desena diagrame, a găsi inconsistenţe şi redondanţă în
modele, a combina modele din mai multe surse, a raporta pe model
componente şi caracteristici, şi aşa mai departe. A avea suport automatizat
înseamnă, în general, a oferi atât un limbaj pentru modele specificae cât şi a
oferi interfeţe utilizator bazate pe grafică. Tehnicile de modelare de date
aflate astăzi în folosinţă sunt parţial automatizate.

4.5. Concepte de bază în modelarea datelor

Conceptele de bază în modelarea datelor, introduse în primele capitole, sunt

conceptele de entităţi, instanţe de entităţi şi atribute:
 o instanţă de entitate descrie un obiect specific, fie acesta real sau abstract
 este util să distingem între entităţi şi instanţe de entităţi. instanţele sunt
obiecte, iar entităţile clase de obeicte care au toate aceleaşi proprietăţi.
 proprietăţile unei instanţe se numesc atribute
 o entitate are un nume, care este un substantiv
 o entitate are unul sau mai multe atribute ale căror valori identifică unic,
sau disting, o instanţă de entitate de alta.

4.6.Entităţi

Entitatea este conceptul de bază în modelarea datelor şi ea poate fi o clasă de

obiecte reale sau abstracte. De exemplu, următoarele sunt nume de entităţi
care reprezintă obiecte “reale”:
ANGAJAT CONSTRUCTIE DEPARTAMENT CAMERA
PROFESOR CLIENT STUDENT PRODUS
pe când următoarele sunt nume de entităţi care reprezintă obiecte “abstracte”:
INVESTITIE ANGAJARE IST_SALARIU PROGRAM_GRADAT
VANZARE CUMPARARE EXP_MUNCA OPţIUNE_CULOARE

50
 Fiecare din obiectele abstracte au o semnificaţie reală dar ele nu sunt
obiecte fizice.
Tehnicile de modelare date nu disting între entităţi reale şi abstracte
ci le reprezintă în acelaşi mod. Noi vom folosi DMT - Data Modeling
Tehnique al D. Appleton Company, Inc. (DACOM). Ea se bazează pe
Logical Database Design Tehnique, creată de Robert G. Brown în 1984 într-
un produs numit Janus, dezvoltat de DACOM şi DBDG (Data Base Design
Group, Inc.) pentru Bank of America.
Aici, o entitate este întotdeuna reprezentată de o cutie
dreptunghiulară. Numele entităţii este scris deasupra cutiei şi entităţii îi poate
fi asigurat un număr de etichetă, care apare după nume, separat prin slash.
(fig. 4.4.a). Din punctul de vedere al gestiunii datelor, este împortant să
distingem între ocurenţe individuale de lucruri şi clase de lucruri care au
aceleaşi proprietăţi. Instanţele de entităţi individuale nu se reprezintă
niciodată într-un model de date, acesta fiind conceput pentru reprezentarea
claselor.

4.7. Atribute

Proprietăţile unei entităţi se numesc atributele sale. Fiecare instanţă de

entitate are câte o valoare pentru fiecare din atributele sale. Atributele se
reprezintă într-o diagramă model ptrintr-o listă cu numele lor în cutia
entităţii. (fig.4.4.b).

Angajat / 49 Angajat / 49

Număr_buletin
Nume_Angajat
Marca_Angajat
Data_Naşterii
Locul_Naşterii
Greutatea
Data_Angajării
Funcţia
Compartimentul

Fig.4.4. Entităţi şi atribute

Tehnicile de modelare de date presupun că două atribute cu un acelaşi nume

sunt acelaşi atribut. Astfel, dacă LOCUL apare ca un atribut în entitatea
ANGAJAT cât şi în entitatea DEPARTAMENT, software-ul de modelare de
date trebuie să semnaleze atributul ca fiind redundant sau inconsistent folosit

51
sau chiar să şteargă una din apariţiile atributului. Dacă două apariţii nu par a
fi acelaşi atribut, atunci trebuie folosite nume de atribute mai precise. De
exemplu, se pot folosi LOCUL_ NASTERII în entitatea ANGAJAT şi
LOCUL_COMPARTIMENTULUI în entitatea DEPARTAMENT. Mai
încolo, vorbind despre atributele cheie străină vom arăta că uneori într-un
model, un atribut poate să apară în mai mult de o entitate. În aceste cazuri,
apariţiile multiple au o semnfifcaţie definită şi indică o relaţie între entităţile
în care apar.
Nuluri. Este important de ştiut când poate avea un atribut o valoare
nulă. Cu toate că s-a depus multă muncă în definirea tipurilor de valori nule,
este suficient pentru scopurile noastre să înţelegem că o valoare nulă este o
valoare “necunoscută” sau “inaplicabilă”, şi nu o valoare numerică egală cu
zero!
Un atribut cu o valoare nulă nu are o valoare cunsocută la un
moment dat dar ea există conceptual în modelul de date. În tehnica noastră de
modelare de date, un atribut care poate avea o valoare nulă este adnotat cu
(0). De exemplu, dacă un angajat poate sau nu poate avea o valoare pentru
atributul NUMAR_TELEFON_PRIVAT_# atunci atributul poate fi listat ca
NUMAR_TELEFON_PRIVAT _# (0).
Domenii. Valorile unui atribut sunt luate dintr-un domeniu care
determină mulţimea validă de valori pentru unul sau mai multe atribute.
Anumite atribute pot avea toate acelaşi domeniu. De exemplu, atributele
DATA_NASTERII, DATA_ANGAJARII, DATA_INTALNIRII sunt toate
luate din domeniul DATE iar PRET_VANZARE şi LISTA_PRETURI sunt
luate din domeniul BANI. Un domeniu arată domeniul de valori al unui
atribut. Un domeniu poate avea mai multe reprezentări alternative pentru
valorile sale. De exemplu, valorile din domeniul BANI pot fi reprezentate în
diverse monede (dolari, marci, lei, etc.), valorile din domeniul LUNGIMI pot
fi reprezentate în cm, metri, mile, etc. iar cele din domeniul DATE ca date în
diferite formate, american (luna-zi-an), european (zi-luna-an), etc. Pot exista
moduri de a converti valorile dintr-o reprezentare a domeniului în alta.
Domeniile pot fi deasemenea, compuneri de domenii. De exemplu, domeniul
DATE ar putea fi compus din trei subdomenii LUNA, ZI si AN şi la rândul
lui, domeniul LUNA ar putea avea mai multe reprezentări: numerice (1, ..,
12) şi alfabetice (“JAN”, .., “DEC” sau “Ianuarie”, .. ,“Decembrie”). Un
model de date complet dezvoltat implică domenii pentru fiecare din atributele
modelului.
Un model de date folosit pentru a ghida proiectarea bazei de date
fizice trebuie condus până la acest nivel. Domeniile:
1. determină operaţiile permise asupra unui atribut
2. determină care atribute pot fi comparate sau folosite în combinaţii
3. determină mulţimea permisă de valori pentru un atribut
4. pot fi folosite pentru a determina mărimile şi formatele pentru câmpurile
din baza de date fizică corespunzătoare.

52
4.8. Chei candidate

Instanţele unei entităţi se disting între ele prin valorile cheilor lor candidate.
O cheie candidată este pur şi simplu o mulţime de atribute ale căror valori
identifică unic instanţele unei entităţi. Pot exista mai multe chei candidate
pentru o entitate. De exemplu, cheile candidate pentru entitatea ANGAJAT
pot fi atributul MARCA_ANGAJAT sau colectiv NUME_ANGAJAT,
DATA_NASTERII, LOCUL_NASTERII. Oricare din aceste chei candidate
identifică unic instanţele entităţii ANGAJAT. Două instanţe diferite ale unei
entităţi nu pot avea aceaşi valoare a cheii candidate, deoarece astfel cheia
candidată nu ar fi un identificator unic.
Termenul cheie se foloseşte ca prescurtare pentru cheie candidată.
Să notăm că o cheie candidată nu trebuie să fie un unic atribut. Se pot folosi
mai multe atribute, ale căror valori formează împreună identificatorul unic. O
cheie candidată construită din mai mult de un atribut se numeşte cheie
compusă. O parte a unei chei candidate nu poate fi, de asemenea, cheie
candidată. Ce este şi ce nu este potrivit pentru o cheie candidată depinde de
domeniul de interes. De exemplu, dacă baza de date include angajaţi dintr-un
holding având în componenţă mai multe intreprinderi, atunci probabil
MARCA_ANGAJAT nu ar fi suficientă pentru o cheie candidată.
MARCA_ANGAJAT şi NUME_COMPANIE împreună ar putea fi cerute
pentru a forma identificatorul unic. Identificarea cheilor candidate depinde,
deci de datele care se modelează.

Angajat /49

NUMAR_BULETIN

MARCA_ANGAJAT(Ak1)
NUME_ANGAJAT(Ak2)
DATA_NAŞTERII(Ak2)
LOCUL_NAŞTERII(Ak2)
GREUTATE
DATA_ANGAJĂRII
FUNCŢIA
NUME_COMPARTIMENT

Fig.4.5. Exemple de chei.

53
 Chei primare şi chei alternate. Una din cheile candidate ale unei
entităţi este selectată ca fiind cheia primară. În exemplul cu entitatea
ANGAJAT, MARCA_ANGAJAT ar putea fi cheia primară. Celelalte chei
candidate sunt chei alternate. În exemplul nostru, DMT, cheile sunt afişate
în acelaşi mod ca şi celelalte atribute în cutia entităţii. Cheia primară apare
deaspura liniei, iar cheile alternate apar sub linie, sufixate de notaţia AK
(Alternate Key).

Specificaţie Proprietate

FILE# SUBDIVIZIE#
LOT#(Ak1)
DRAWING(Ak1) NUME_ORAª#(Ak1)
PART#(Ak1,Ak2)
SPEC#(Ak2)
NUME_SUBDIVIZIE(Ak1)
COD_ZONĂ

a)Chei alternate care b)Cheie primară care coincide în

coincid în parte parte cu cheie alternatã

Fig.4.6. Exemple de chei care coincid în parte.

Fig.4.5. arată entitatea ANGAJAT, cu NUMAR_BULETIN ca şi

cheie primară. MARCA_ANGAJAT este o cheie alternată iar o altă cheie
alternată este colectiv, NUME_ANGAJAT, DATA_NASTERII,
LOCUL_NASTERII. Deoarece pot exista mai multe chei alternate, DMT le
distinge între ele asignându-le câte un număr. Fig.4.6. arată două chei
alternate, notate AK1 şi AK2, respectiv Fig.4.6.a cu chei alternate care
coincid în parte, iar cheia primară a entităţii SPECIFICATIE este FISIER#. O
cheie alternată este DESEN#, PARTE# iar altă cheie alternată este PARTE#,
SPEC#. Fig.4.6.b arată o cheie alternată care coincide în parte cu cheia
primară. O PROPRIETATE poate fi identificată prin cheia sa primară
SUBDIVIZIE#. LOT#, NUME_ORAS sau prin cheia sa alternată
NUME_SUBDIVIZIE, LOT#, NUME_ORAS. Două sau mai multe entităţi
pot avea acelaşi atribute pentru cheile lor primare. De exemplu, STUDENT şi
STUDENT_DSA sunt entităţi diferite deoarece ele au atribute diferite. Ele
pot avea, totuşi aceeaşi cheie primară, NUMAR_MATRICOL. Similar
ANGAJAT şi PRESTATOR_SERVICII sunt entităţi diferite, dar au aceaşi
cheie primară NUMAR_BULETIN.
Conceptele de bază ale cheilor candidate într-un model de date sunt,
astfel, următoarele:

54
1. Instantele unei entităţi sunt distinse una de alta prin valorile cheilor lor
candidate.
2. O cheie candidată este o mulţime de unul sau mai multe atribute ale căror
valori împreună identifică în mod unic instanţele unei entităţi.
3. Nici o parte a unei chei candidate nu poate fi ea însăşi o cheie candidată.
4. Dacă două instanţe ale unei entităţi au aceaşi valoare a cheii candidate,
atunci ele sunt aceaşi instanţă.
5. Pentru o entitate pot exista mai multe chei candidate.
6. Una din cheile candidate este selectată ca fiind cheia primară.
7. Celelalte chei sunt cunoscute a fi chei alternate.
8. Fiecare instanţă de entitate trebuie să aibă una şi numai una valoare de
cheie primară.
9. Un atribut cheie primară nu poate avea niciodată valoare nulă.
10. Entităţi multiple pot avea aceaşi cheie primară.

4.9. Relaţii

Relaţiile într-un model de date sunt asociaţii între entităţi şi sunt reprezentate
în mod uzual prin linii între cutiile cu entităţi (fig.4.7.a). Alte tehnici de
modelare date folosesc un simbol special, ca un diamant, pentru a reprezenta
relaţiile (fig.4.7.b).
Departament

DEPARTAMENT

angajează Angajează

Angajat

ANGAJAT

a)Sintaxă reprezentată prin b)Sintaxă arătând o relaţie

linie arătând o relaţie reprezentată de diamant

Fig.4.7. Sintaxa relaţiei

55
 Există două tipuri de relaţii, conectare şi categorie. O relaţie de
conectare asociază entităţi diferite, de exemplu, DEPARTAMENT şi
ANGAJAT. O relaţie de categorie asociază entităţi similare, de exemplu,
STUDENT, STUDENT_COLEGIU şi STUDENT_4ANI. Categoriile pot fi
gândite ca relaţii “este de tipul”. De exemplu:
 studentul la învăţământ de lungă durată este un tip de student
 studentul la colegiu este de asemenea un tip de student
 un student poate fi înscris la colegiu sau la învăţământ de lungă durată.
Conectările, pe de altă parte, nu reprezintă relaţii de subtipuri. Interpretarea
lor ar fi:
 departamentul angajează angajaţi
 angajatul lucrează la un departament
 studentul este înscris la un curs
 cursul este frecventat de student.

4.10. Relaţii de conectare

O relaţie de conectare:
 are un nume de verb
 are o cardinalitate, care arată câte instanţe ale uneia din entităţi sunt
legate de câte instanţe ale celeilalte entităţi.
În plus, o relaţie de conectare între entităţile A şi B:
 poate avea o dependenţă de existenţă, ceea ce înseamnă că entitatea B
nu poate exista dacă nu există entitatea A.
 poate avea o dependenţă de identificator, ceea ce înseamnă că cheia
primară a entităţii B include cheia primară a entităţii A. Dependenţa de
identificator implică dependenţa de existenţă.
O relaţie de conectare cu dependenţă de existenţă trebuie să adere la regula
integrităţii referenţiale:
Instanţele entităţii B nu pot exista fără ca o instanţă a entităţii A să
existe de asemenea şi valorile atributelor particulare ale entităţii B
trebuie să se potrivească cu cheia primară din entitatea A.
În DMT, o relaţie de conectare este desenată prin “linie cu punct
mare”. Figura 4.7.a a prezentat o relaţie de conectare. Linia terminată cu un
punct mare la un capăt se citeşte: “O instanţă a entităţii DEPARTAMENT
este conectată prin relaţia ANGAJEAZA la mai multe instanţe ale entităţii
ANGAJAT”. Mai uzual, se citeşte: “Fiecare departament angajează mai mulţi
angajaţi”. Să notăm că interpretarea corectă a relaţiei este aceea că fiecare
angajat este conectat de un singur departament.
Figura.4.8. are o linie de conectare cu câte un punct mare la ambele
capete. Această relaţie poate fi citită ca “mai multe instanţe ale entităţii
DEPARTAMENT sunt conectate prin relaţia ANGAJEAZA la mai multe
instanţe ale entităţii ANGAJAT”. Dar, în mod uzual se va citi: “Fiecare

56
departament angajează mai mulţi angajaţi şi fiecare angajat poate fi angajat la
mai multe departamente” sau “Există o relaţie mai mulţi la mai mulţi între
departamente şi angajaţi”. Toate acestea sunt interpretări ale diagramei.
Există o diferenţă majoră între relaţiile de conectare unul-la-mai-
mulţi (fig.4.7.a) şi relaţiile de conectare mai-mulţi-la-mai-mulţi (fig.4.8.): ele
nu au aceaşi semnificaţie. Cea care reprezintă corect între departamente şi
angajaţi este determinată de către regulile de afaceri din lumea reală care se
modelează.
Cardinalitate. O tehnică de modelare de date care foloseşte linii
pentru a reprezenta relaţii într-o diagramă de model utilizează, în mod tipic,
un simbol le sfârşitul liniei pentru a reprezenta cardinalitatea relaţiei.
Cardinalitatea oricărei conectări date între entităţile A şi B este una din
următoarele:
 o instanţă a lui A este conectată la mai multe instanţe ale lui B.
 o instanţă a lui A este conectată la cel puţin o instanţă a lui B.
 o instanţă a lui A este conectată exact la n instanţe ale lui B.
 o instanţă a lui A este conectată la între n şi m instanţe ale lui B.

Departament Student graduate

angajează are la dosar

Angajat P
Scrisoare recomandare

Fig.4.8. Relaţii de conectare . Fig.4.9. Relaţie de conectare cu

mai-mulţi-la-mai-mulţi cardinalitate pozitivă (P).

De exemplu, în fig.4.7.a. linia terminată fără un simbol la o cutie de entitate

înseamnă “o instanţă a acestei entităţi”. Simbolul terminal punct mare
înseamnă “mai multe instanţe ale acestei entităţi”. Mai precis, punctul mare
înseamnă “0,1 sau mai mulţi”. Cardinalitatea unei relaţii de conectare poate fi
specificată mai precis prin adnotarea punctului mare. De exemplu, figura 4.9.

57
prezintă faptul că un student la DSA trebuie să aibă la dosar cel puţin o
scrisoare de recomandare. Punctul mare este acompaniat de p, indicând
pozitiv. În anumite relaţii de conectare, o instanţă a uneia din entităţi este
conectată la un anumit număr de instanţe ale celeilalte entităţi. În acest caz în
DMT punctul mare se adnotează cu numărul respectiv. De exemplu, în figura
4.10. linia de conectare este terminată cu un punct mare adnotat cu numărul
12, şi poate fi citită “o instanţă a entităţii DEPARTAMENT se conectează
prin relaţia ARE la 12 instanţe ale entităţii BUGET_LUNAR”. Mai uzual, ea
se poate citi “Fiecare departament are 12 bugete lunare”. Să notăm, din nou,
că fiecare buget lunar este pentru un singur departament. În anumite relaţii de
conectare, o instanţă a uneia din entităţi poate fi conectată la un domeniu de
număr de instanţe al altei entităţi şi în DMT se adnotează punctul mare cu
acel domeniu de numere.

Departament Luna

are are
12 28-31
Buget lunar Zi

Fig.4.10. Relaţie de conectare cu Fig.4.11. Relaţie de conectare cu

cardinalitate exactă (n = 12). domeniu de cardinalitate (28 - 31)

De exemplu, figura 4.11. prezintă o linie de conectare terminată cu

un punct mare şi intervalul 28 - 31. Acest exemplu poate fi citi ca “Fiecare
lună are între 28 şi 31 de zile”. Ocazional, un domeniu de cardinalitate este
zero-la-unu. DMT notează acest caz special printr-un punct mare cu un “z”,
aşa cum se vede în fig.4.12., care poate fi citită ca “Fiecare manager are fie o
secretară, fie nici una”. Să notăm că interpretarea corectă a modelului implică
de asemenea că o secretară nu lucrează pentru mai mult de un manager.
Alte convenţii pentru a reprezenta domenii de cardinalitate sunt
prezentate în figurile 4.13.a şi 4.13.b. Prima poate fi citită: “Fiecare curs
poate avea maximum 45 de studenţi iar fiecare student se poate înscrie la

58
maximum 7 cursuri”. A doua poate fi citită “Fiecare profesor ţine cel puţin
două cursuri şi fiecare curs este ţinut de câte un singur profesor”.
Manager Secretara
are
Z

Fig.4.12. Relaţie de conectare cu cardinalitate zero-la-unu (2)

Să notăm că un model cu cardinalitate reprezintă mai explicit

semantica datelor decât o face un model fără cardinalitate şi că, cardinalitatea
este o formă de restricţie care poate fi folosită pentru a verifica şi menţine
calitatea datelor.
Grupa
Profesor

<=7
inrolează Predă
<=45 >=2
Grupa
Student

a) Domeniu de cardinalitate în b) Cardinalitate minimã într-o

relatii de conectare mai-multi- relatie de conectare unul-la-
la-mai-multi mai-multi

Fig.4.13. Exemple de cardinalităţi.

59
 Cardinalitatea unei relaţii este o aserţiune asupra instanţelor entităţii.
Această aserţiune poate fi aplicată atunci când baza de date este actualizată,
pentru a determina dacă actualizările violează sau nu regulile stabilite de
semantica datelor. De exemplu, să considerăm aserţiunile făcute de
cardinalitatea relaţiilor din fig.4.13. Şi 4.9. O actualizare care încearcă să
adauge al 46-lea student la un curs va fi respinsă, la fel ca una care încearcă
să adauge un al 8-lea curs la un student sau o actualizare care încearcă să
şteargă singura scrisoare de recomandare de la dosarul unui student.

Rezolvarea relaţiilor mai-mulţi-la-mai-mulţi. Relaţiile mai-mulţi-

la-mai-mulţi sunt rezolvate (impărţite) în componente relaţii unul-la-mai-
mulţi atunci când modelul de date este rafinat pentru a prezenta mai multe
detalii. Rezoluţia acestor relaţii este prezentată în fig.4.14. care sparge relaţia
mai-mulţi-la-mai-mulţi între entităţile GRUPA şi STUDENT din fig.4.13.a în
două relaţii unul-la-mai-mulţi care au aceaşi entitate de bază. O instanţă a
acestei entităţi de bază INSCRIERE reprezintă înscrierea unui student la o
grupă de studii. Fiecare grupă are mai multe înscrieri din acestea, până la
numărul maxim de 45. Fiecare student are mai multe înscrieri, până la
maximum 7.

Grupa Student

se înrolează în
are
<=7
<=45

Înrolare

Fig.4.14. Rezoluţia relaţiei mai-mulţi-la-mai-mulţi din fig.4.13.a în două

conectări unul-la-mai-mulţi.

60
 Un alt exemplu de rezolvare a relaţiei mai-mulţi-la-mai-mulţi este
prezentat în fig.4.15. Aici conectarea mai-mulţi-la-mai-mulţi între entităţile
CONSILIER şi CURS este spartă în două relaţii unul-la-mai-mulţi care
partajează o aceaşi entitate ASISTENT. O instanţă a acestei entităţi de bază
reprezintă un sfat al consilierului unei clase particulare cu un asistent.
Entitatea de la un capăt al relaţiei unul-la-mai-mulţi (“unul”) se
numeşte uzual entitatea tată a relaţiei iar entitatea de la capătul “mai mulţi”
se numeşte entitate copil (sau fiu).

CONSILIER CURS
CONSILIER

Z are
supervizează
conduce

CURS ASISTENT

a) b)

Fig.4.15. Rezoluţia unei relaţii zero-sau-unul-la-mai-mulţi.

Atribute cheie străină. După ce relaţiile mai-mulţi-la-mai-mulţi au

fost rezolvate, pot fi identificate atributele cheie străină. Un atribut al unei
entităţi care se găseşte în cheia primară a unei alte entităţi se numeşte atribut
cheie străină. Partajarea acelui atribut indică o relaţie între entităţi.
Regula este:
Când două entităţi sunt asociate (înlănţuite) printr-o relaţie de
conectare, atributele de cheie primară a entităţii tată migrează în
entitatea fiu, devenind acolo atribute de cheie străină.
Să notăm că nu apare nici o migraţie cu o relaţie de conectare mai-mulţi-la-
mai-mulţi, deoarece nu se poate face o distincţie între entităţi tată şi fiu.
De exemplu, în fig.4.13.b atributul cheie primară al lui PROFESOR,
ID_FACULTATE migrează în entitatea CURS, devenind un atribut de cheie

61
străină. În fig.4.9. atributul cheie primară al lui STUDENT_DSA MATRIC#,
migrează în entitatea SCRISOARE_DE_RECOMANDARE, devenind acolo
un atribut de cheie străină. Cheile nu pot, totuşi, să migreze prin relaţia mai-
mulţi-la-mai-mulţi din fig.4.13.a.
Unul din testele de validitate ale atributului de cheie străină este:
O instanţă de entitate poate avea numai o singură valoare pentru
fiecare din atributele sale de cheie străină.
Aceasta indică direcţia în care migrează cheia într-o relaţie. De exemplu,
dacă cheia primară a lui CURS - CURS#, SECTIE# - trebuie să migreze în
PROFESOR, acolo devenind un atribut cheie străină, acest test nu va fi
satisfăcut. Fiecare profesor predă cel puţin două secţiuni de curs şi deci
fiecare instanţă a entităţii PROFESOR trebuie să aibă cel puţin două valori
pentru CURS#, SECTIE#.
Regula este:
Cheia primară migrează întotdeauna de la entitatea din “partea cu o
instanţă” la entitatea din “partea cu mai multe instanţe” ale unei
relaţii, devenind acolo o cheie străină.

Oraº Oraº

Cod_oraº

Este Este Este Este

plecare sosire plecare sosire
pentru pentru pentru pentru

Segment zbor Segment zbor

ZBOR#
COD_ORAŞ_PLECARE.COD_ORAŞ(FK)
COD_ORAŞ_SORIRE.COD_ORAŞ(FK)
ORA_PLECARE.PLANIFICARE
ORA_SOSIRE.PLANIFICARE
TIP_AVION
a) după relaţii
conectând două entităţi

b)Folosirea numelor de roluri

pentru COD_ORAŞ ca şi atribute
cheie străină
Fig.4.16. Nume de roluri.

62
 Nume de roluri. Când există mai mult de o relaţie între o pereche
de entităţi, atributelelor cheie străină li se asignează nume de roluri. Acestea
permit distincţia între diferitele apariţii ale unui nume de atribut cheie străină
într-o entitate. Deoarece entităţile migrează în diferite relaţii, ele au
semnificaţii diferite. De exemplu, fig.4.16.a modelează două relaţii găsite
într-o planificare de zboruri. Fiecare oraş poate să fie oraş de plecare pentru
mai multe segmente de zbor şi oraş de sosire pentru alte segmente de zbor.
Fiecare segment de zbor are exact un oraş de plecare şi un oraş de sosire.
Modelul prezintă două entităţi, ORAS şi SEGMENT_ZBOR de două ori.
Cheia primară a lui ORAS migrează în SEGMENT_ZBOR de două ori, o
dată prin relaţia ESTE_PUNCT_DE_PLECARE_PENTRU şi o dată prin
relaţia ESTE_PUNCT_DE_SOSIRE_PENTRU.
Pentru a distinge între cele două apariţii ale atributului cheie străină
COD_ORAS în entitatea SEGMENT_ZBOR, unei apariţii îi este dat numele
de rol COD_ORAS_PLECARE iar celeilalte îi este dat numele de rol
COD_ORAS_SOSIRE. Fără nume de roluri, COD_ORAS ar fi apărut de
două ori în SEGMENT_ZBOR. O ocurenţă ar fi fost eliminată de regula
“acelaşi nume, aceeaşi semnificaţie” şi una din relaţii ar fi fost pierdută în
proces. Fig.4.16.b prezintă mai complet numele de roluri asumate de către
atributul COD_ORAS în entitatea SEGMENT_ZBOR. DMT foloseşte
convenţia de “punctare” a numelui de rol, de exemplu
COD_ORAS_PLECARE.COD_ORAS pentru a arăta, de asemenea, numele
său sursă.
Dependenţa de existenţă. O relaţie de conectare poate avea
dependenţă de existenţă. Dacă există o dependenţă de existenţă între două
entităţi A şi B, atunci regula este:
Fiecare instanţă a entităţii B trebuie să aibă o instanţă
corespunzătoare a entităţii A.
Entitatea B se spune a fi dependentă în existenţă de entitatea A. Să notăm că
entitatea A trebuie să fie tatăl entităţii B în relaţia de conectare şi că o
dependenţă de existenţă apare când cheia străină pentru relaţie nu poate fi
nulă.
Dacă există o dependenţă de existenţă în fig.4.13.b asociată cu
relaţia “predă” atunci o instanţă de entitate GRUPA nu poate exista fără a fi
asociată cu o instanţă de entitate PROFESOR. Fiecare instanţă de entitate
GRUPA trebuie să aibă un non-nul FACULTATE# pentru profesorul său.
Dacă există o dependenţă de existenţă în fig.4.9. asociată cu relaţia
“are la dosar”, atunci o instanţă de entitate
SCRISOARE_DE_RECOMANDARE nu poate exista fără a fi asociată cu o
instanţă de entitate STUDENT_DSA. Fiecare instanţă de

63
SCRISOARE_DE_RECOMANDARE trebuie să aibă un non-nul MATRIC#
pentru studentul asociat cu ea.
Relaţiile de conectare mai-mulţi-la-mai-mulţi nu evidenţiază
dependenţe de exiatenţă. De exemplu, nu există nici o dependenţă de
existenţă asociată cu relaţia “inscrie” din fig.4.14. a. O grupă va exista chair
fără studenţi înscrişi în ea (cel puţin până când este ştearsă) şi un student va
exista chiar dacă nu este înscris în nici o grupă.
Să notăm, totuşi, că există dependenţă de existenţă în rezoluţia
acestei relaţii mai-mulţi-la-mai-mulţi din fig.4.14. O instanţă INSCRIERE nu
poate exista fără a fi asociată cu o instanţă GRUPA şi cu o instanţă student.
Un alt exemplu de relaţii de conctare fără dependenţă de existenţă
este prezentat în fig.4.15.a. Acest model poate fi citit astfel: “un consilier
poate conduce mai multe cursuri, dar un curs nu poate fi condus de mai mult
de un consilier”. Astfel, un curs există dacă este condus sau nu de un
consilier iar un consilier va continua să existe dacă conduce sau nu un curs.
Această relaţie poae fi rezolvată în două relaţii care au dependenţă de
existenţă, aşa cum se vede în fig.4.15.b. Aici entitatea ASISTENT este
dependentă de existenţa atât a entităţii CONSILIER cât şi de cea a entităţii
CURS. O persoană nu poate fi asistent dacă nu i se asignează un curs de către
consilier. Să notăm că procesul de rezoluţie folosit aici este acelaşi cu cel
folosit în obţinerea fig.4.14 din fig.4.13.a.
Relaţiile mai-mulţi-la-mai-mulţi şi relaţiile de conectare zero-sau-
unul-la-mai-mulţi sunt numite uneori relaţii nespecifice, deoarece ele
maschează dependenţele de existenţă.
Aceste relaţii sunt specificate prin rezoluţia unei relaţii nespecifice
în două relaţii specifice, transformând o conectare mai-mulţi-la-mai-mulţi în
două conectări unul-la-mai-mulţi. O conectare zero-sau-unu-la-mai-mulţi
devine o relaţie unu-la-mai-mulţi şi o relaţie unu-la-zero-sau-unu.
Notăm cu E1 entitatea tată a unei relaţii şi cu E2 entitata fiu. Cheia
primară a lui E1 este mulţimea de atribute A, care este deasemenea o cheie
străină în E2. Dacă atributele A din E2 nu pot fi nule, atunci E2 este
dependentă de existenţa lui E1. Dacă există o instanţă a lui E2, ea trebuie să
fie asociată cu o instanţă a lui E1. Pe de altă parte, dacă unul sau mai multe
atribute ale lui A în E2 pot fi nule, atunci E2 nu este dependent de existenţa
lui E1. O instanţă a lui E2 poate exista fără ca ea să fie asociată cu o instanţă
a lui E1.
Dependenţa de identificator. O relaţie de conectare poate avea
dependentă de identificator. Dacă există o relaţie între entităţile A şi B, atunci
entitatea B se zice dependentă de identificator de entitatea A, dacă şi numai
dacă: cheia primară a lui A, apărând ca un atribut de cheie străină în B, este
complet conţinută în cheia primară a lui B.
Cheia migratoare a entităţii A este astfel o parte esenţială a identificatorului
entităţii B. În DMT, distincţia între relaţiile care au dependenţă de
identificator şi cele care nu au, este făcută prin linie continuă şi linie punctată.

64
De exemplu, modelul din fig.4.14. cu atributele de chei este prezentat
fig.4.17. Ambele relaţii sunt relaţii de identificare iar cheile primare apar
ambele în cheia primară a relaţiei fiu.
GRUPA STUDENT
SECŢIE# MATRIC#
CURS#

INROLARE
SECŢIE#
CURS#
MATRIC#

Fig.4.17. Model de date logice cu două relaţii de conectare de

identificare.

În fig.4.18. una din relaţii are dependenţă de identificator şi una nu o

are. Cheia primară a lui PO_LINE include cheia primară a lui PO dar nu
include cheia primară a lui PART.
DMT are o opţiune care suprimă tipărirea atributelor de cheie străină
pe diagrame. Atunci când această opţiune se foloseşte, trebuie să existe o
distincţie, alta decât plasarea atributelor, pentru a indica dependenţa de
identificator. Aici distincţia este făcută prin arce solide sau întrerupte.
O entitate care nu este dependentă de identificator de nici o altă
entitate este desenată cu colţuri drepte, iar o entitate care este dependentă de
identificator de cel puţin o altă entitate este desenată cu colţuri rotunjite.
Entităţile care nu sunt dependente de identificator pot sta singure, dar
entităţile dependente de identificator sunt întotdeauna găsite cu alte entităţi.
Să notăm că dependenţa de identificator implică întotdeauna
dependenţa de existenţă.
Integritatea referenţială. Integritatea referenţială este o restricţie
care trebuie să fie satisfăcută pentru relaţii de conectare cu dependenţă de
existenţă (sau de identificator). Integritatea referenţială este aserţiunea că,
dacă entitatea B este dependentă de existenţa entităţii A, atunci
valorile atributelor de cheie străină într-o instanţă a entităţii B
trebuie să fie egale cu valoarea cheii primare din instanţa asociată a
entităţii A.

65
De exemplu, dacă ANGAJAT este dependent de existenţă de
DEPARTAMENT în fig.4.7., integritatea referenţială spune că:
pentru orice instanţă a entităţii ANGAJAT, valoarea atributului de
cheie străină DEPARTAMENT# trebuie să se potrivească cu
valoarea de cheie primară DEPARTAMENT# din instanţa de
entitatea DEPARTAMENT asociată.
Similar, pentru relaţiile din fig.4.15.b. dacă ASISTENT este dependentă de
existenţa lui CONSILIER şi CURS, atunci integritatea referenţială spune că
pentru fiecare instanţă a entităţii ASISTENT, valoarea atributului de
cheie străină CONSILIER_ID trebuie să se potrivească cu valoarea
din cheia primară din instanţa de entitate CONSILIER asociată, şi
pentru fiecare instanţă a entităţii ASISTENT, valoarea atributului
CURS# trebuie să se potrivească cu valoarea din cheia primară din
instanţa de entitate CURS asociată

Po Part
Po# Part#

conţine apare în

Po_Line

Po#(Fk)
Line#

Part#(Fk)
Qty

Fig.4.18. Model de date logice cu o relaţie de identificare şi una de

neidentificare.

Reprezentarea restricţiei de integritate referenţială într-un model de date este

importantă deoarece
1. un model care exprimă restricţia de integritate referenţială reprezintă mai
explicit semantica datelor decât unul care nu o face.
2. integritatea referenţială poate fi folosită pentru a verifica şi menţine
calitatea datelor.

66
 Integritatea referenţială este o aserţiune despre instanţele entităţilor.
Această aserţiune poate fi aplicată atunci când baza de date este actualizată,
pentru a determina dacă actualizarea violează regulile semantice stabilite.
De exemplu, o actualizare a bazei de date modelată în fig.4.7. poate
fi rejectată dacă ea încearcă să adauge o instanţă ANGAJAT cu un
DEPARTAMENT# care încă nu există ca şi o cheie primară a unei instanţe
din DEPARTAMENT. Orice actualizare care leagă o instanţă de ANGAJAT
cu o instanţă de DEPARTAMENT, fără o potrivire de DEPARTAMENT# va
fi de asemenea rejectată. O actualizare va fi rejectată dacă ea încearcă să
şteargă o instanţă de DEPARTAMENT pentru care continuă să existe
instanţe de ANGAJAT. Instanţele de ANGAJAT nu pot să existe fără a fi
asociate cu instanţe de DEPARTAMENT. Să notăm că modificarea valorii
DEPARTAMENT# din instanţa ANGAJAT este o modalitate validă de a
asocia instanţă cu o altă instanţă DEPARTAMENT.

Angajat

Tip_compensaţie

Angajat cu ora Angajat cu salariu

Fig.4.19.a. Exemple de relaţii de categorie.

Pentru baza de date modelate în fig.4.15.b., următoarele actualizări

vor fi rejectate:
 adăugarea unei instanţe ASISTENT pentru care ori CURS# ori
CONSILIER_ID nu se potriveşte cu cheia dintr-o instanţă CURS sau
CONSILIER existentă.

67
 legarea unei instanţe ASISTENT de o instanţă CURS sau CONSILIER
fără o potrivire în CURS# respectiv CONSILIER_ID.
 ştergerea unei instanţe CURS pentru care există o instanţă ASISTENT.
 ştergerea unei instanţe CONSILIER pentru care există instanţe
ASISTENT.

4.11. Relaţii de categorie

Relaţiile de conectare asociază tipuri diferite de entităţi, pe când relaţiile de

categorie asociază entităţi similare.
O relaţie de categorie are următoarele caracteristici:
1. este numită “TREBUIE_SA_FIE_UN” sau “POATE_FI_UN”.
2. leagă o entitate generică de o entitate subtip.
3. are o cardinalitate unu-la-zero-sau-unu.
4. are un discriminator de subtip.
5. atributele entităţii generice sunt moştenite implicit de entitatea subtip.
6. are dependenţă de existenţă.
7. trebuie să se conformeze restricţiei de integritate referenţială.
8. poate avea dependenţă de identificator.
DMT foloseşte un cerc pentru a reprezenta o relaţie de categorie.
Fig.4.19.a. modelează o situaţie în care există două tipuri de
angajaţi, cu ora şi salariaţi. Fiecare angajat poate fi un angajat cu ora sau un
angajat salariat, dar nu poate fi amândouă la un loc. Atributele entităţii
generice ANGAJAT sunt aplicabile, de asemenea, entităţilor subtip
ANGAJAT_CU_ORA şi ANGAJAT_CU_SALAR.
Fig.4.19.b. modelează o altă situaţie în care există trei tipuri de
angajaţi student, profesor şi personal administrativ. Un angajat poate fi un
student, un profesor, un membru al personalului administrativ sau nici unul
dintre aceştia.
În lumea reală, o instanţă a entităţii STUDENT reprezintă exact
acelaşi obiect ca şi instanţa entităţii ANGAJAT cu care ea este asociată în
această relaţie. Pe de altă parte, o relaţie de conectare asociază întotdeauna
instanţe care reprezintă obiecte diferite din lumea reală. De exemplu, o
instanţă SEGMENT_ZBOR din fig.4.16. reprezintă un obiect din lumea reală
diferit de cele reprezentate de instanţele ORAS cu care el este legat.
Discriminator de subtip. O diagramă a unei relaţii arată entitatea
generică în vârf, cu un cerc conţinând un atribut al entităţii generice ale cărei
valori determină în ce subtip rezidă o instanţă de entitate dependentă
particulară. Acest atribut se numeşte discriminator de subtip. În fig.4.19.a
disciminatorul de subtip este atributul TIP_COMPENSATIE ale cărei valori
determină dacă un angajat particular este angajat cu ora sau permanent. În
fig.4.19.b. disciminatorul de subtip este atributul STATUS, a cărui valoare
determină când un angajat particular este un student, un profesor sau un

68
 Angajat

administrator. Să notăm că discriminatorul de subtip este un atribut al entităţii

generice, şi nu al relaţiei.

Angajat

Status

Student Profesor Administrativ

Fig.4.19.b. Exemple de relaţii de categorie.

O mulţime de relaţii de categorii cu acelaşi discriminator de subtip

se numeşte clasă de categorii. Fig.4.19.a. are două relaţii de categorii,
ambele într-o clasă. Fig.4.19.b. are trei relaţii de categorie, toate în aceaşi
clasă. Fiecare cerc de categorie într-o diagramă DMT reprezintă o clasă de
relaţii de categorie. O entitate poate avea mai mulţi discriminatori de subtip,
ca în fig.4.20. Aici există două subclasificări de clădiri: TIP_FOLOSIRE
dintr-o instanţă CLADIRE indică dacă aceasta este rezidenţială, birouri,
magazine sau alte scopuri; TIP_CONSTRUCTIE indică dacă este din
cărămizi, prefabricate sau altele. O instanţă cladire dată poate avea valori atât
pentru TIP_FOLOSIRE cât şi pentru TIP_CONSTRUCTIE, de exemplu o
cladire din caramidă pentru birouri sau o cladire din prefabricate rezidenţială.
Punând împreună modelele din fig.4.19.a. Şi 4.19.b. obţinem de asemenea, o
entitate cu mai mult de un singur discriminator de subtip.
Exclusivitate mutuală. Un discriminator de subtip poate avea
numai o valoare pentru orice instanţă a entităţii generice. Astfel, o instanţă a
entităţii generice poate fi legată dfe o singură instanţă de subtip într-o clasă
de categorii. În concordanţă cu fig.4.20. o construcţie nu poate fi atât una de

69
birouri cât şi una rezidenţială, şi nici nu poate fi construită atât din cărămizi
cât şi din prefabricate. Dacă aceste reguli nu sunt adevărate, atunci modelul
nu reflectă corect realitatea. Acest model nu reprezintă o cladire care e parţial
de birouri, parţial rezidenţială şi parţial magazine.

Clădire

Tip construcţie
Tip folosire

Clădire Clădire de Clădire de Clădire din Clădire din

rezidenţială birouri vânzare cărămizi prefabricate

Fig.4.20. Exemplu de entitate cu două ierarhii de categorii.

Similar, modelul din fig.4.21.a. spune că o persoană poate fi sau un

student sau un profesor şi nu poate prezenta situaţia în care o persoană poate
fi atât profesor cât şi student. Fig.4.21.b. modelează această situaţie adăugând
o regulă atributului discriminator, indicând că instanţa PERSOANA poate
avea mai mult de o valoare pentru STATUS. Această convenţie pentru a
relaxa restricţia de exclusivitate mutuală este rar folosită, o categorizare mai
judicioasă eliminând deasemenea problema.
Exclusivitatea mutuală poate fi folosită pentru a verifica şi menţine
calitatea datelor. Astfel, o actualizare a bazei de date modelate în fig.4.20. va
fi rejectată dacă ea încearcă să descrie o clădire atât de birouri cât şi
rezidenţială.
Totalitate. O clasă de categorii se spune a fi totală dacă orice
valoare validă a discriminatorului de subtip are o etichetă subtip

70
corespunzătoare. DMT reprezintă o clasă totală de categorii desenând o linie
dublă sub cercul de relaţie de categorie.

Persoana Persoana

Status Status(>=0)

Student Profesor Student Profesor

b) Relaxarea regulii de
a) Subtipuri mutual exclusivitate mutualã prin
exclusive adăugarea regulii >=0 pentru
atributul discriminator

Fig.4.21. Exemple de ierarhie de categorie.

De exemplu, fig.4.22. arată o mulţime completă de subtipuri de

student. Domeniul valorilor pentru discriminatorul de subtip şi entităţile
subtip prezentate în model determină împreună dacă o clasă de categorii este
totală.
Dependenţa de existenţă. Dependenţa de existenţă are loc
întotdeuna într-o relaţie de categorie. Pentru ca o instanţă a unui subtip să
existe, ea trebuie să aibă o instanţă asociată a entităţii generice. O cladire de
birouri nu poate exista fără a fi o clădire; un angajat cu ora nu poate exista
fără a fi un angajat.
Dacă pentru un discriminator de subtip se permite a avea o valoare
nulă şi/sau mulţimea valorilor este mai mare decât numărul subtipurilor
(adică, clasa categoriilor nu este totală) atunci existenţa unei entităţi generice
nu implică necesar existenţa entităţii subtip corespunzătoare. De exemplu, o
valoare nulă în TIP_CONSTRUCTIE din fig.4.20. va indica faptul că o

71
instanţă dată de CLADIRE nu este nici din caramizi, nici din prefabricate.
Tipul de construcţie poate fi de asemenea necunoscut sau nedisponibil.

Student

Status

Doctorand Undergraduate Neclasificat

Fig.4.22. Exemple de relaţii de categorie cu mulţime totală de subtipuri.

Fiecare valoare a acestui atribut discriminator are o entitate subtip
potrivită.

Integritatea referenţială. O relaţie de categorie trebuie să se

conformeze întotdeauna restricţiei de integritate referenţială. Cheile primare
migrează pentru a deveni atribute de cheie străină în relaţiile de categorie în
acelaşi mod cum o fac şi în relaţiile de conectare. O instanţă de entitate subtip
trebuie să fie asociată cu o instanţă de entitate generică a cărei valoare de
cheie primară se potriveşte cu valoarea atributului de cheie străină a
subtipului.
Dependenţa de identificator. O relaţie de categorie poate sau nu
poate avea dependenţă de identificator. De exemplu, fig.4.23. prezintă o
situaţie în care dependenţa de identificator nu are loc. Entitatea generică este
INVESTITIE, cu cheia primară DATA, SURSA şi TIPUL. Entităţile subtip
sunt BURSA, CONTRACT, IMOBILIAR şi C.D. Cu toate că ele moştenesc
cheia primară a entităţii generice (la fel, implicit, restul atributelor sale)
atributul de cheie străină nu este parte a cheilor primare ale subtipurilor.
Acest exemplu arată că o entitate subtip poate fi la rândul ei o entitate
generică. Entitatea IMOBILIAR are două entităţi subtip,
PROP_COMERCIALA şi PROP_REZIDENTIALA. Dacă se cere pentru

72
toate relaţiile de categorie a avea dependenţă de identificator atunci va fi
posibil să modelăm numai ierarhii de categorii şi nu reţele de categorii. Toate
exemplele prezentate au fost în fapt ierarhii.

Investiţie
Data
Sursa

Tip. investiţie

Bursa Contract Imobiliar C.D.

Companie Contract# Locaţia C.D.I.D
Grad Data(Fk) Data(Fk) Data(Fk)
Data(Fk) Sursa(Fk) Sursa(Fk) Sursa(Fk)
Sursa(Fk)

Prop_comercială Prop_rezidenţială

Locaţia(Fk) Locaţia(Fk)

Fig.4.23. Exemplu de ierarhie de categorii.

4.12. Alte tehnici de modelare disponibile

În literatura tehnică despre baze de date au fost propuse multe tehnici de

modelare date, dar numai câteva sunt folosite de către companii şi organizaţii.
În această secţiune vom descrie tehnicile cele mai cunoscute.
Modelul reţea. Modelul reţea a fost dezvoltat de către CODASYL
(Conference on Data System Languages) DBTG (Data Base Task Group) la
sfârşitul anilor 60 şi la începutul anilor 70 şi de către Cincom Systems, Inc.,
cu sistemul său comercial de gestiune a bazelor de date TOTAL. Modelul
reţea încearcă să ridice preocuparea de gestiune a datelor deasupra nivelului

73
de structuri de fişiere fizice, considerând structuri logice. Astăzi, el nu este
considerat în totalitate a fi o tehnică semantică de modelare a datelor
deoarece este puternic legat de capacităţile unui DBMS particular şi are
posibilităţi limitate de expresii semantice.
El lucrează cu tipuri de înrgistrări. item-uri de date şi tipuri de
mulţimi care sunt în mare analoage cu entităţi, atribute şi relaţii. Până la
sfârşitul anilor 70 exista un amestec puternic de parametri de bază de date
logică şi fizică într-un singur model reţea. Îl vom studia în detaliu în
capitolele 7 şi 12.
Modelul relaţional. Modelul relaţional a fost introdus de către E.F.
Codd de la IBM la începutul anilor 70 şi el oferă o abordare simplă şi totuşi
riguroasă matematic a modelării datelor. El lucrează cu datele în termeni de
tabele iar relaţiile în tabele se formează prin partajarea atributelor, uzual prin
atribute de cheie străină. Modelul relaţional a reţinut atenţia multor
cercetători în baze de date şi este încă în vogă prntre DBMS-uri comerciale.
Dar, în ciuda largii sale folosiri, astăzi modelul relaţional nu mai este în
general considerat o tehnică logică de modelare date, în primul rând datorită
posibilităţilor sale reduse de exprimare semantică. Îl vom studia în detaliu în
capitolele 5, 6 şi 11.
Modelul Entitate-Mulţime. Una din tehnicile de început în
modelarea logică a datelor a fost modelul entitate-mulţime introdus în 1973
de către cercetăţorii de la IBM. Acest model recunoaşte entităţile ca şi
colecţii de perechi nume-entitate = valoare-entitate. Ne există conceptul de
atribut, orice (de ex: nume, vârstă, departament) este o entitate. Relaţiile sunt
binare, adică orice relaţie poate asocia numai două entităţi. O dezvoltare a
acestei tehnici este produsul Information Analysis (IA) al lui Control Data
Corporation.
Modelul Entitate-Relaţie. A fost introdus în 1975 de către Peter
Chen ca o alternativă la modelele relaţional, reţea şi entitate-mulţime. El
desenează entităţi, atribute şi relaţii. Relaţiile sunt n-are, adică orice relaţie
dată poate asocia una, două sau mai multe entităţi iar un model poate
prezenta dependenţa de existenţă între entităţi.
Modelul abstractizării al lui Smith. Prima constribuţie a acestui
model publicat în 1977 este distincţia între relaţiile de agregare şi
generalizare, pe care noi le denumim relaţii de conectare şi de categorie.
Modelul introduce convenţia ca entităţile să aibă un nume de substantiv şi
include o notaţie grafică pentru reţelele agregare şi generalizare.
Modelul de date semantice. Modelul de date semantice publicat în
1978 introduce un alt nivel de explcitare în reprezentarea constructelor de
modelare date loghice, recunoscând trei tipuri de entităţi (numite clase):
obiecte concrete (fizice), abstractizări (generalizări) şi agregate (colecţii
omogene). Acest model introduce, de asemenea conceptul de evenimente,
care sunt acţiuni la care participă obiectele şi identifică trei tipuri de atribute.

74
 IDEF1. IDEF1 (ICAM - Integrated Computer-Aided Manufacturing
- Definition Language -1) a fost dezvoltat la sfârşitul anilor 70 sub auspiciile
U.S.Air Force. El este un hibrid practic între modelul entitate-relaţie şi
modelul relaţional şi are metode companion pentru modelarea activităţilor
IDEF0 şi a dinamicii sistemelor IDEF2. O generaţie ulterioară a lui IDEF1
este IDEF1-Extended (IDEFIX) şi este derivată din DMT, care îşi are
rădăcinile în IDEF1.
Modelul de date funcţionale. Modelul de date funcţionale şi
limbajul său de modelare DAPLEX, publicate în 1981 oferă un cadru riguros
pentru a modela date ca entităţi. El exprimă relaţiile între entităţi ca funcţii
care pot fi imbricate, de exemplu Rang (Instructor (Curs)). Ca şi modelul
entitate-mulţime, aici nu există conceptul de atribut, mai mult, proprietăţile
unei entităţi rezultă aplicând funcţii entităţii. DAPLEX poate fi folosit pentru
a descrie modele de date, pentru a defini restricţii într-un model de date şi
pentru a pune întrebări modelelor de date.
Proiectantul de date (Data Designer). Este un produs comercial
sub licenţă Knowledgeware, Inc., fostul Database Design, Inc. (DDI). Este un
instrument de proiectare automată şi combină modelele de date cu vederi
utilizator. El se bazează pe tehnica diagramelor cu bule dezvoltată de James
Martin (bubble - charting), în care ovalele reprezintă entităţi, iar arcele
reprezintă relaţii. Proiectantul de date generează modele de date normalizate
(vezi cap.6) bazate pe dependenţe de intrare între atribute.
Gestionarul de proiectare (Design Manager). Este un produs
comercial sub licenţă MPS, Ltd. care lucrează în conjuncţie cu dicţionarul de
date MPS, Data Manager, pentru memorarea şi analiza modelelor de date.
Oferă suport automat pentru descrierea modelelor de date şi pentru
transformarea lor în proiectări de baze de date.

4.13. Comentarii finale

Succesul tehnicilor de modelare de date comerciale certifică recunoaşterea

crescândă a importanţei modelării datelor în comunicaţii şi în descoperirea
semanticii datelor. Modelarea datelor este folosită rutinier pentru:
 a creşte înţelegerea datelor şi a semnficaţiei lor de către o organizaţie.
 a documenta resursele de date.
 a evalua din exterior pachete software.
 a planifica sisteme informatice.
 a proiecta sistemele informatice.
 a integra resursele de date
 a proiecta şi a implementa baza de date fizice
Modelarea datelor logice este o parte esenţială a ciclului de viaţă al
proiectului bază de date şi este folosită pentru a documenta mediile existente
şi pentru a planifica viitoarele resurse de date. Modelarea datelor este

75
folosită, de asemenea, pentru a dezvolta proiecte modele de date şi pentru a
integra aceste modele într-o schemă conceptuală în dezvoltare, care este un
scop special al modelului de date logice. Rezultatele modelării datelor pot fi
apoi transformate în proiectări de baze de date fizice.

Memento

Model de activitate Relaţie de generalizare

Relaţie de agregare Entitate generică
Cheie alternată Model ierarhic
Aserţiune Dependenţă de identificator
Atribut Cheie
Cheie candidată Model de date logice
Relaţie de categorie Model reţea
Clasă de categorii Model de date fizice
Cheie compusă Cheie primară
Relaţie de conectare Model de proces
Entitate Integritate referenâală
Dependenţă de existenţă Model relaţional
Atribut cheie străină Relaţie
Model funcţie Nume de rol
Model semantic de date Semantică
Discriminator de subtip

Bibliografie

1. D. Appleton Company, Inc. (1985) Data Modeling Technique Reference

Manual, PCFS - DMT 3.0, Manhattan Beach, CA.
2. Database Design Inc. (1981) Data Designer. User Guide, Ann Arbor,
Mich.
3. Martin, J. (1977) Computer Data Base Organisation, Englewood Cliffs,
N.J. Prentice Hall.

76