Capitolul 4.

Modelarea datelor logice

Modelarea datelor logice este una din cele mai puternice metode de a stabili
i a menine controlul asupra resurselor de date. Exist mai multe tehnici de
modelare a datelor logice. La sfritul capitolului vom enumera cteva dintre
ele. Pentru a ilustra proprietile 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 abordri de modelare.
Modelele de date logice pot fi reprezentate att prin diagrame ct i
prin instruciuni de limbaj. Noi am ales diagramele.
4.1. Introducere
Modelarea este o tehnic important pentru a defini cerinele de a
analiza proiectrile alternative. Un model reprezint caracteristici de interes
particular suprimnd 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 semnificaiei datelor ntr-un anumit domeniu de interes. Se mai
numete model semantic de date deoarece accentul modelului cade pe
semnificaia datelor (i.e. semantica). Un model de date logice tipic reprezint
entiti, atribute si relaii. 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 pstrm fapte. Un atribut este o
proprietate sau o caracteristic a unei entiti. Un model de date logice este
reprezentat tipic folosind o tehnologie grafic. De exemplu, cutiile pot
reprezenta entiti iar sgeile pot reprezenta relaii intre entiti (fig. 3.5.).
Modele de date fizice. Modelele de fizice reprezint implementarea
structurilor de date i vizeaz optimizarea resurselor, cum ar fi spaiul de
memorie i timpii de acces. Elementele lor includ, n general, nregistrri
fizice, fiiere, 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 funcie sau modele
proces) care reprezint procese (mai de grab dect date) i relaiile lor.
Aceste modele se reprezint tipic printr-o notaie grafic n care cutiile (sau
43

cercurile) reprezint activiti iar arcele ntre cutii reprezint fluxul

activitilor. Fig.3.5. reprezint un model de activitate.
Un model de actvitate se focalizeaz pe procese mai mult dect pe
fluxul ntre procese. Modelele de date, pe de alt parte, se focalizeaz pe
semnificaiile entitilor, atributelor i a relaiilor de date. Tehnicile de
modelare a datelor reprezint, uzual activititile care folosesc datele. Dac
nu indicm altfel, vom folosi termenul de model de date pentru a referi un
model de date logic (mai de grab dect 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 comunicaiile
despre date i de a ajuta n descoperirea semanticii datelor.
Comunicarea semnificaiei datelor. Doarece ele sunt reprezentri
riguroase, modelele de date pot fi folosite pentru a transmite unei alte
persoane nelegerea semnificaiei datelor. Atta timp ct persoanele ce
comunic sunt familiare cu notaia folosit n model, comunicarea va fi
neleas. Companiile i standardizeaz modul n care modeleaz datele,
selectnd 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 rspunde la ntrebri despre entiti i relaii. Fcnd aa,
modelatorii descoper semnificaia datelor organizaiei, care exist indiferent
dac se ntmpl sau nu ca ele s fie nregistrate ntr-un model formal de date.
Entitile i relaiile lor sunt fundamentale pentru toate organizaiile; totui,
semnificaia datelor poate rmne nedescoperit (i probabil prost neleas)
pn cnd organizaia nu le documenteaz cu succes.
Un model de date face mai uoar descoperirea semanticii datelor.
Fr un mod de a reprezenta entiti i relaii, este uor s spunem. O, da,
suntem cu toii de acord c aceasta arat cum se leag produsele cu
distribuitorii, fr a ti ntr-adevr cu ce suntem de acord i nici nu este
simplu ca distribuitorii reprezint produsele. De exemplu, anumii
distribuitori pot reprezenta anumite produse; anumite tipuri de produse pot fi
reprezentate numai de anumii distribuitori; distribuitorii unui produs se pot
schimba n timpul vnzrii, i aa mai departe.
4.3. Aplicarea modelrii de date logice
Facilitnd comunicaiile i descoperind semantica datelor, modelarea datelor
este util pentru:
creterea nelegerii datelor unei organizaii i a operaiilor asupra lor
documentarea resurselor de date

44

folosirea pachetelor software

planificarea sistemelor de informaii
proiectarea sistemelor informatice
integrarea resurselor de date
proiectarea i implementarea bazelor de date
nelegerea datelor. Atunci cnd se dezvolt modele de date, att
personalul de prelucrare date ct i utilizatorii care sunt experi n domeniul
modelului, sunt necesari. Un model de date construit de personalul care
prelucreaz date singuri i fcut pentru a portretiza date despre produse este
diferit de unul fcut de ingineri, productori 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 comunicaii, 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 dect limbajele naturale.
Evaluarea software-ului. Pe msur ce pachetele software devin
mai populare, companiile se ntreab tot mai des: Se va potrivi acest
software n mediul nostru?. Rspunsul depinde de ce face software-ul i de
modelul de date rezultat. De exemplu, un pachet de contabilitate care
presupune un angajat este pltit dintr-un singur cont (al proiectului la care
lucreaz) nu se va potrivi bine ntr-o companie ai crei angajai sunt pltii
din mai multe conturi. Dac pachetul de contabilitate a fost bine documentat
cu un model de date logice i dac cumprtorul candidat este familiar cu
modelul de date logice i dac cumprtorul poate prezice mai bine dac un
pachet particular de contabilitate este sau nu alegerea potrivit.
Planificarea sistemelor informatice. Deoarece faciliteaz
comunicaiile 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, entitile de nivel nalt sunt apoi
mapate pe uniti organizatorice (cine este responsabil pentru ce date?),
activitate (ce funcii se fac pentru ce date?) i fiiere 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 ctre fiecare proiect.
Proiectarea sistemelor informatice. Un proiect de implementare
poate aduga la un model de planificare date de nivel nalt detalii despre
atribute, volume i frecvene de acces pentru datele din domiul su. Modelul

45

detaliat rezultat poate fi transformat ntr-o proiectare de baz de date fizic.

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 invenie. De exemplu, fig.4.1. ilustreaz n mod simplu modelele
prezent i viitor. Fr 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. maini de scris) i un mediu n care
responsabilitile distribuitorului au fost expandate pentru a include mai
multe tipuri de produse (de ex. maini de scris, procesoare de texte,
calculatoare). n general, un model de date pentru viitor nu este o pur
invenie ci el imprtete mult din modelul rdcin al prezentului. Figura
4.2. arat un mediu existent n care studentii fr licena (undergraduate) nu
se pot nscrie la cursuri postuniversitare i un mediu viitor n care cursurile
graduate au fost deschise pentru acetia.
Produs

Produs

este vndut de

este vndut de

Vnztor

Vnztor

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, aa cum s-a artat n capitolul 3. Dac modelele
produse de ctre 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 inconsistenele i redundanele
pot fi identificate i rezolvate.

46

Modelul de date integrate dezvoltat de ctre o intreprindere este

schema sa conceptual. Aceast vedere neutr de date poate fi mapat pe
diferite structuri de baze de date fizice (scheme interne), aa cum sunt ele
implementate i pe vederi utilizator (scheme externe), aa cum sunt ele
identificate. Poate fi dificil a integra resursele de date fr a folosi modele de
date. Structurile fizice, de exemplu, nu prezint o imagine complet.
Structurile baze de dat fizice, ca i structurile de fiiere convenionale, sunt
proiectate pentru a se ntlni cu obiectivele de performan ale aplicaiilor
particulare i nu pentru a oglindi structurile logice. De exemplu n figura 4.3.
nregistrarea PARTE din fiierul A conine un grup repretitiv cu distribuitorii
acelei pri. Aplicaiile care folosesc fiierul A acceseaz datele despre
distribuitori pentru pri particulare. Fiecare parte are mai muli distribuitori
asociai. Din contr nregistrarea DISTRIBUITOR din fiierul B este ntr-o
structur de nregistrare care spune s fiecare distribuitor ofer mai multe
pri. Aplicaiile care folosesc fiierul B acceseaz date despre pri pantru
distribuitori particulari. Fiecare distribuitor are mai multe pri asociate.
Student

Fr diplom

Curs postuniversitar

Cu diplom

ia/este luat de

Fig.4.3a. Relaii mai muli la mai muli

Combinaia acestor dou vederi indic faptul c exist mai multe
relaii mai muli la mai muli ntre pri i distribuitori, aa cum se arat n
fig.4.3.c. Fiecare cutie din figur reprezint o entitate iar arcul repreint o
relaie ntre entiti. Punctele groase de la sfritul arcului indic c relaia
este mai muli la mai muli.
Aceast structur nseamn c o parte particular poate fi oferit
demai muli distribuitori i c orice distribuitor poate oferi mai multe pri.
47

Nici o structur de fiier fizic nu arat imaginea complet ci numai modelul

de date logice superpus arat integrarea celor dou orientri vedere de date.
Detectarea structurii logice adevrate a datelor din structurile fizice
devine chiar mai grea atunci cnd relaiile inter-nregistrri sunt ngropate n
codul aplicaiilor. De exemplu, dac prile din fiierul PARTI sunt legate de
distribuitorii din fiierul DISTRIBUITORI printr-o tabel codificat
complicat ntr-o aplicaie program, atunci descoperirea relaiei logice ntre
pri 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 implicai 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 ctre fiierele 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 arta cum sunt legate
datele din diferite baze de date fizice i fiiere.
Student

Curs postuniversitar
ia
este luat

Fr diplom

Cu diplom

Fig.4.3b. Relaii mai muli la mai muli

Susinerea proiectrii bazelor de date fizice. Un model de date d
proiectantului de baze de date fizice informaii despre ce date ar trebui
incluse n baza de date, ce tipuri de relaii structureaz baza de date i cum se
48

leag baza de date de alte baze de date. A construi un model de date nseamn
n primul rnd a introduce date corecte n baza de date. Tehnicile de
proiectare baz de date fizice se folosesc apoi pentru a asigura un acces
eficient la date.
Pstrarea consistent a tehnicii. Organizaiile care folosesc modelarea
datelor au avut beneficii folosind consistent o tehnic de modelare particular
pentru planificarea sistemelor informatice, planificarea proiectrii i a
implementrii bazelor de date. Invers, atunci cnd mai multe tehnici de
modelare sunt folosite pentru aceste diferite faze ale dezvoltrii sistemelor,
pot apare probleme n traducerea semnificaiei 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 uor de nvat i folosit
Diagrame grafice. Majoritatea tehnicilor de modelare de date aflate
n folosin astzi ofer att un limbaj de modelare (cu o sintaxa bine definit,
cuvinte cheie, etc.) ct i diagrame grafice ale modelelor. Pictogramele
constau din cutii sau cercuri pentru a reprezenta entiti i din arce sau linii
pentru a reprezenta relaii. Anumite tehnici folosesc forme diferite pentru
diferite forme de entiti: dreptunghiuri i dreptunghiuri rotunjite pot fi
folosite n acelai model pentru a distinge ntre entiti independente de
identificator i entiti dependente de alte entiti pentru identificarea lor.
Anumite tehnici folosesc convenii diferite pentru linii pentru
diferite tipuri de relaii, de exemplu, linii unice pentru grupri i linii duble
pentru relaii este un fel de.
Alte tehnici folosesc un simbol special, ca de exemplu un cerc,
pentru a arta atributele.
Reprezentarea explicit a semanticii. Exist un domeniu de
preferin personal pentru a reprezenta grafic ct mai bine semantica datelor.
Anumite persoane prefer o mulime de simboluri diferite, fiecare cu o
semnificaie special, pe cnd alii prefer un munr 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 semnificaiile
datelor. Diagramele pot s fie neschimbtoare, dar un simbol nu poate avea
mai multe semnificaii diferite.
49

Nivelul potrivit de detaliere. O tehnic de modelare trebuie s

ofere detalii la nivelul potrivit pentru folosina utilizatorului. Modelele de
date pentru planificarea sistemelor informatice de nivel nalt (la nivelul
companiei sau diviziei) trebuie s pstreze mai puine detalii dect 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 entitile i relaiile de nivel nalt,
dar i modele care arat toate entitile, atributele detaliate i relaiile rafinate.
Independena 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. Cte o dat,
tehnicile de modelare a datelor folosite cu un DBMS particular sunt
considerate de nivel general, aa cum sunt modelul ierarhic, modelul reea i
modelul relaional. Problema major a acestor trei tehnici este existena de
limitri n semantica datelor pe care le pot reprezenta.
Suport automatizat. Tehnica de modelare de date ideal are suport
automatizat pentru a desena diagrame, a gsi inconsistene i redondan n
modele, a combina modele din mai multe surse, a raporta pe model
componente i caracteristici, i aa mai departe. A avea suport automatizat
nseamn, n general, a oferi att un limbaj pentru modele specificae ct i a
oferi interfee utilizator bazate pe grafic. Tehnicile de modelare de date
aflate astzi n folosin sunt parial automatizate.
4.5. Concepte de baz n modelarea datelor
Conceptele de baz n modelarea datelor, introduse n primele capitole, sunt
conceptele de entiti, instane de entiti i atribute:
o instan de entitate descrie un obiect specific, fie acesta real sau abstract
este util s distingem ntre entiti i instane de entiti. instanele sunt
obiecte, iar entitile clase de obeicte care au toate aceleai proprieti.
proprietile unei instane se numesc atribute
o entitate are un nume, care este un substantiv
o entitate are unul sau mai multe atribute ale cror valori identific unic,
sau disting, o instan de entitate de alta.
4.6.Entiti
Entitatea este conceptul de baz n modelarea datelor i ea poate fi o clas de
obiecte reale sau abstracte. De exemplu, urmtoarele sunt nume de entiti
care reprezint obiecte reale:
ANGAJAT
PROFESOR

CONSTRUCTIE
CLIENT

DEPARTAMENT
STUDENT

CAMERA
PRODUS

pe cnd urmtoarele sunt nume de entiti care reprezint obiecte abstracte:

50

INVESTITIE
VANZARE

ANGAJARE
CUMPARARE

IST_SALARIU
EXP_MUNCA

PROGRAM_GRADAT
OPIUNE_CULOARE

Fiecare din obiectele abstracte au o semnificaie real dar ele nu sunt

obiecte fizice.
Tehnicile de modelare date nu disting ntre entiti reale i abstracte
ci le reprezint n acelai 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 ntrun 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 entitii este scris deasupra cutiei i entitii i poate
fi asigurat un numr 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 ocurene individuale de lucruri i clase de lucruri care au
aceleai proprieti. Instanele de entiti individuale nu se reprezint
niciodat ntr-un model de date, acesta fiind conceput pentru reprezentarea
claselor.
4.7. Atribute
Proprietile unei entiti se numesc atributele sale. Fiecare instan de
entitate are cte o valoare pentru fiecare din atributele sale. Atributele se
reprezint ntr-o diagram model ptrintr-o list cu numele lor n cutia entitii.
(fig.4.4.b).
Angajat / 49

Angajat / 49
Numr_buletin
Nume_Angajat
Marca_Angajat
Data_Naterii
Locul_Naterii
Greutatea
Data_Angajrii
Funcia
Compartimentul

Fig.4.4. Entiti i atribute

Tehnicile de modelare de date presupun c dou atribute cu un acelai nume
sunt acelai atribut. Astfel, dac LOCUL apare ca un atribut n entitatea

51

ANGAJAT ct i n entitatea DEPARTAMENT, software-ul de modelare de

date trebuie s semnaleze atributul ca fiind redundant sau inconsistent folosit
sau chiar s tearg una din apariiile atributului. Dac dou apariii nu par a
fi acelai 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 strin vom arta c uneori ntr-un
model, un atribut poate s apar n mai mult de o entitate. n aceste cazuri,
apariiile multiple au o semnfifcaie definit i indic o relaie ntre entitile
n care apar.
Nuluri. Este important de tiut cnd 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 nelegem 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 mulimea valid de valori pentru unul sau mai multe atribute.
Anumite atribute pot avea toate acelai 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 reprezentri 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 rndul
lui, domeniul LUNA ar putea avea mai multe reprezentri: 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 pn la acest nivel. Domeniile:
1. determin operaiile permise asupra unui atribut
2. determin care atribute pot fi comparate sau folosite n combinaii
3. determin mulimea permis de valori pentru un atribut
52

4. pot fi folosite pentru a determina mrimile i formatele pentru cmpurile

din baza de date fizic corespunztoare.
4.8. Chei candidate
Instanele unei entiti se disting ntre ele prin valorile cheilor lor candidate.
O cheie candidat este pur i simplu o mulime de atribute ale cror valori
identific unic instanele unei entiti. 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 instanele entitii ANGAJAT. Dou instane diferite ale unei
entiti nu pot avea aceai valoare a cheii candidate, deoarece astfel cheia
candidat nu ar fi un identificator unic.
Termenul cheie se folosete ca prescurtare pentru cheie candidat.
S notm c o cheie candidat nu trebuie s fie un unic atribut. Se pot folosi
mai multe atribute, ale cror valori formeaz mpreun identificatorul unic. O
cheie candidat construit din mai mult de un atribut se numete 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 angajai dintr-un
holding avnd 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_NATERII(Ak2)
LOCUL_NATERII(Ak2)
GREUTATE
DATA_ANGAJRII
FUNCIA
NUME_COMPARTIMENT

Fig.4.5. Exemple de chei.

53

Chei primare i chei alternate. Una din cheile candidate ale unei
entiti 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 afiate
n acelai mod ca i celelalte atribute n cutia entitii. Cheia primar apare
deaspura liniei, iar cheile alternate apar sub linie, sufixate de notaia AK
(Alternate Key).
Specificaie

Proprietate

FILE#

SUBDIVIZIE#
LOT#(Ak1)
NUME_ORA#(Ak1)

DRAWING(Ak1)
PART#(Ak1,Ak2)
SPEC#(Ak2)

a)Chei alternate care

coincid n parte

NUME_SUBDIVIZIE(Ak1)
COD_ZON
b)Cheie primar care coincide n
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 asignndu-le cte un numr. 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 entitii 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 entiti
pot avea acelai atribute pentru cheile lor primare. De exemplu, STUDENT i
STUDENT_DSA sunt entiti diferite deoarece ele au atribute diferite. Ele
pot avea, totui aceeai cheie primar, NUMAR_MATRICOL. Similar
ANGAJAT i PRESTATOR_SERVICII sunt entiti diferite, dar au aceai
cheie primar NUMAR_BULETIN.

54

Conceptele de baz ale cheilor candidate ntr-un model de date sunt,

astfel, urmtoarele:
1. Instantele unei entiti sunt distinse una de alta prin valorile cheilor lor
candidate.
2. O cheie candidat este o mulime de unul sau mai multe atribute ale cror
valori mpreun identific n mod unic instanele unei entiti.
3. Nici o parte a unei chei candidate nu poate fi ea nsi o cheie candidat.
4. Dac dou instane ale unei entiti au aceai valoare a cheii candidate,
atunci ele sunt aceai 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. Entiti multiple pot avea aceai cheie primar.
4.9. Relaii
Relaiile ntr-un model de date sunt asociaii ntre entiti i sunt reprezentate
n mod uzual prin linii ntre cutiile cu entiti (fig.4.7.a). Alte tehnici de
modelare date folosesc un simbol special, ca un diamant, pentru a reprezenta
relaiile (fig.4.7.b).
Departament
DEPARTAMENT

Angajeaz

angajeaz
Angajat

ANGAJAT

a)Sintax reprezentat prin

linie artnd o relaie

b)Sintax artnd o relaie

reprezentat de diamant

55

Fig.4.7. Sintaxa relaiei

Exist dou tipuri de relaii, conectare i categorie. O relaie de
conectare asociaz entiti diferite, de exemplu, DEPARTAMENT i
ANGAJAT. O relaie de categorie asociaz entiti similare, de exemplu,
STUDENT, STUDENT_COLEGIU i STUDENT_4ANI. Categoriile pot fi
gndite ca relaii este de tipul. De exemplu:
studentul la nvmnt 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 nvmnt de lung durat.
Conectrile, pe de alt parte, nu reprezint relaii de subtipuri. Interpretarea
lor ar fi:
departamentul angajeaz angajai
angajatul lucreaz la un departament
studentul este nscris la un curs
cursul este frecventat de student.
4.10. Relaii de conectare
O relaie de conectare:
are un nume de verb
are o cardinalitate, care arat cte instane ale uneia din entiti sunt
legate de cte instane ale celeilalte entiti.
n plus, o relaie de conectare ntre entitile 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 entitii B include cheia primar a entitii A. Dependena de
identificator implic dependena de existen.
O relaie de conectare cu dependen de existen trebuie s adere la regula
integritii refereniale:
Instanele entitii B nu pot exista fr ca o instan a entitii A s
existe de asemenea i valorile atributelor particulare ale entitii B
trebuie s se potriveasc cu cheia primar din entitatea A.
n DMT, o relaie de conectare este desenat prin linie cu punct
mare. Figura 4.7.a a prezentat o relaie de conectare. Linia terminat cu un
punct mare la un capt se citete: O instan a entitii DEPARTAMENT
este conectat prin relaia ANGAJEAZA la mai multe instane ale entitii
ANGAJAT. Mai uzual, se citete: Fiecare departament angajeaz mai muli
angajai. S notm c interpretarea corect a relaiei este aceea c fiecare
angajat este conectat de un singur departament.

56

Figura.4.8. are o linie de conectare cu cte un punct mare la ambele

capete. Aceast relaie poate fi citit ca mai multe instane ale entitii
DEPARTAMENT sunt conectate prin relaia ANGAJEAZA la mai multe
instane ale entitii ANGAJAT. Dar, n mod uzual se va citi: Fiecare
departament angajeaz mai muli angajai i fiecare angajat poate fi angajat la
mai multe departamente sau Exist o relaie mai muli la mai muli ntre
departamente i angajai. Toate acestea sunt interpretri ale diagramei.
Exist o diferen major ntre relaiile de conectare unul-la-maimuli (fig.4.7.a) i relaiile de conectare mai-muli-la-mai-muli (fig.4.8.): ele
nu au aceai semnificaie. Cea care reprezint corect ntre departamente i
angajai este determinat de ctre regulile de afaceri din lumea real care se
modeleaz.
Cardinalitate. O tehnic de modelare de date care folosete linii
pentru a reprezenta relaii ntr-o diagram de model utilizeaz, n mod tipic,
un simbol le sfritul liniei pentru a reprezenta cardinalitatea relaiei.
Cardinalitatea oricrei conectri date ntre entitile A i B este una din
urmtoarele:
o instan a lui A este conectat la mai multe instane ale lui B.
o instan a lui A este conectat la cel puin o instan a lui B.
o instan a lui A este conectat exact la n instane ale lui B.
o instan a lui A este conectat la ntre n i m instane ale lui B.
Departament

Student graduate

angajeaz

are la dosar
P
Scrisoare recomandare

Angajat

Fig.4.8. Relaii de conectare

mai-muli-la-mai-muli

57

Fig.4.9. Relaie de conectare cu

cardinalitate pozitiv (P).

De exemplu, n fig.4.7.a. linia terminat fr un simbol la o cutie de entitate

nseamn o instan a acestei entiti. Simbolul terminal punct mare
nseamn mai multe instane ale acestei entiti. Mai precis, punctul mare
nseamn 0,1 sau mai muli. Cardinalitatea unei relaii de conectare poate fi
specificat mai precis prin adnotarea punctului mare. De exemplu, figura 4.9.
prezint faptul c un student la DSA trebuie s aib la dosar cel puin o
scrisoare de recomandare. Punctul mare este acompaniat de p, indicnd
pozitiv. n anumite relaii de conectare, o instan a uneia din entiti este
conectat la un anumit numr de instane ale celeilalte entiti. n acest caz n
DMT punctul mare se adnoteaz cu numrul respectiv. De exemplu, n figura
4.10. linia de conectare este terminat cu un punct mare adnotat cu numrul
12, i poate fi citit o instan a entitii DEPARTAMENT se conecteaz
prin relaia ARE la 12 instane ale entitii BUGET_LUNAR. Mai uzual, ea
se poate citi Fiecare departament are 12 bugete lunare. S notm, din nou,
c fiecare buget lunar este pentru un singur departament. n anumite relaii de
conectare, o instan a uneia din entiti poate fi conectat la un domeniu de
numr de instane al altei entiti i n DMT se adnoteaz punctul mare cu
acel domeniu de numere.
Luna

Departament

are
12
Buget lunar

Zi

Fig.4.10. Relaie de conectare cu

cardinalitate exact (n = 12).

are
28-31

Fig.4.11. Relaie de conectare cu

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,
aa cum se vede n fig.4.12., care poate fi citit ca Fiecare manager are fie o
58

secretar, fie nici una. S notm c interpretarea corect a modelului implic

de asemenea c o secretar nu lucreaz pentru mai mult de un manager.
Alte convenii 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 studeni iar fiecare student se poate nscrie la
maximum 7 cursuri. A doua poate fi citit Fiecare profesor ine cel puin
dou cursuri i fiecare curs este inut de cte un singur profesor.
Manager

Secretara
are
Z

Fig.4.12. Relaie de conectare cu cardinalitate zero-la-unu (2)

S notm c un model cu cardinalitate reprezint mai explicit
semantica datelor dect o face un model fr cardinalitate i c, cardinalitatea
este o form de restricie care poate fi folosit pentru a verifica i menine
calitatea datelor.
Grupa
Profesor

<=7
inroleaz
<=45

Pred
>=2
Grupa

Student

a) Domeniu de cardinalitate n
relatii de conectare mai-multila-mai-multi

b) Cardinalitate minim ntr-o

relatie de conectare unul-lamai-multi
59

Fig.4.13. Exemple de cardinaliti.

Cardinalitatea unei relaii este o aseriune asupra instanelor entitii.
Aceast aseriune poate fi aplicat atunci cnd baza de date este actualizat,
pentru a determina dac actualizrile violeaz sau nu regulile stabilite de
semantica datelor. De exemplu, s considerm aseriunile fcute de
cardinalitatea relaiilor 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 relaiilor mai-muli-la-mai-muli. Relaiile mai-mulila-mai-muli sunt rezolvate (imprite) n componente relaii unul-la-maimuli atunci cnd modelul de date este rafinat pentru a prezenta mai multe
detalii. Rezoluia acestor relaii este prezentat n fig.4.14. care sparge relaia
mai-muli-la-mai-muli ntre entitile GRUPA i STUDENT din fig.4.13.a n
dou relaii unul-la-mai-muli care au aceai entitate de baz. O instan a
acestei entiti de baz INSCRIERE reprezint nscrierea unui student la o
grup de studii. Fiecare grup are mai multe nscrieri din acestea, pn la
numrul maxim de 45. Fiecare student are mai multe nscrieri, pn la
maximum 7.
Student

Grupa

se nroleaz n
<=7

are
<=45

nrolare

60

Fig.4.14. Rezoluia relaiei mai-muli-la-mai-muli din fig.4.13.a n dou

conectri unul-la-mai-muli.
Un alt exemplu de rezolvare a relaiei mai-muli-la-mai-muli este
prezentat n fig.4.15. Aici conectarea mai-muli-la-mai-muli ntre entitile
CONSILIER i CURS este spart n dou relaii unul-la-mai-muli care
partajeaz o aceai entitate ASISTENT. O instan a acestei entiti de baz
reprezint un sfat al consilierului unei clase particulare cu un asistent.
Entitatea de la un capt al relaiei unul-la-mai-muli (unul) se
numete uzual entitatea tat a relaiei iar entitatea de la captul mai muli
se numete entitate copil (sau fiu).
CURS

CONSILIER
CONSILIER

Z
conduce

supervizeaz

CURS

are

ASISTENT

a)

b)

Fig.4.15. Rezoluia unei relaii zero-sau-unul-la-mai-muli.

Atribute cheie strin. Dup ce relaiile mai-muli-la-mai-muli au
fost rezolvate, pot fi identificate atributele cheie strin. Un atribut al unei
entiti care se gsete n cheia primar a unei alte entiti se numete atribut
cheie strin. Partajarea acelui atribut indic o relaie ntre entiti.
Regula este:

61

Cnd dou entiti sunt asociate (nlnuite) printr-o relaie de

conectare, atributele de cheie primar a entitii tat migreaz n
entitatea fiu, devenind acolo atribute de cheie strin.
S notm c nu apare nici o migraie cu o relaie de conectare mai-muli-lamai-muli, deoarece nu se poate face o distincie ntre entiti 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
strin. n fig.4.9. atributul cheie primar al lui STUDENT_DSA MATRIC#,
migreaz n entitatea SCRISOARE_DE_RECOMANDARE, devenind acolo
un atribut de cheie strin. Cheile nu pot, totui, s migreze prin relaia maimuli-la-mai-muli din fig.4.13.a.
Unul din testele de validitate ale atributului de cheie strin este:
O instan de entitate poate avea numai o singur valoare pentru
fiecare din atributele sale de cheie strin.
Aceasta indic direcia n care migreaz cheia ntr-o relaie. De exemplu,
dac cheia primar a lui CURS - CURS#, SECTIE# - trebuie s migreze n
PROFESOR, acolo devenind un atribut cheie strin, acest test nu va fi
satisfcut. Fiecare profesor pred cel puin dou seciuni de curs i deci
fiecare instan a entitii PROFESOR trebuie s aib cel puin 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 instane ale unei
relaii, devenind acolo o cheie strin.
Ora

Ora
Cod_ora

Este
plecare
pentru

Este
sosire
pentru

Este
plecare
pentru

Segment zbor

Este
sosire
pentru
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 relaii
conectnd dou entiti
62

b)Folosirea numelor de roluri

pentru COD_ORA ca i atribute
cheie strin
Fig.4.16. Nume de roluri.

Nume de roluri. Cnd exist mai mult de o relaie ntre o pereche

de entiti, atributelelor cheie strin li se asigneaz nume de roluri. Acestea
permit distincia ntre diferitele apariii ale unui nume de atribut cheie strin
ntr-o entitate. Deoarece entitile migreaz n diferite relaii, ele au
semnificaii diferite. De exemplu, fig.4.16.a modeleaz dou relaii gsite
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 entiti, ORAS i SEGMENT_ZBOR de dou ori.
Cheia primar a lui ORAS migreaz n SEGMENT_ZBOR de dou ori, o
dat prin relaia ESTE_PUNCT_DE_PLECARE_PENTRU i o dat prin
relaia ESTE_PUNCT_DE_SOSIRE_PENTRU.
Pentru a distinge ntre cele dou apariii ale atributului cheie strin
COD_ORAS n entitatea SEGMENT_ZBOR, unei apariii i este dat numele
de rol COD_ORAS_PLECARE iar celeilalte i este dat numele de rol
COD_ORAS_SOSIRE. Fr nume de roluri, COD_ORAS ar fi aprut de
dou ori n SEGMENT_ZBOR. O ocuren ar fi fost eliminat de regula
acelai nume, aceeai semnificaie i una din relaii ar fi fost pierdut n
proces. Fig.4.16.b prezint mai complet numele de roluri asumate de ctre
atributul COD_ORAS n entitatea SEGMENT_ZBOR. DMT folosete
convenia de punctare a numelui de rol, de exemplu
COD_ORAS_PLECARE.COD_ORAS pentru a arta, de asemenea, numele
su surs.
Dependena de existen. O relaie de conectare poate avea
dependen de existen. Dac exist o dependen de existen ntre dou
entiti A i B, atunci regula este:
Fiecare instan a entitii B trebuie s aib o instan
corespunztoare a entitii A.
Entitatea B se spune a fi dependent n existen de entitatea A. S notm c
entitatea A trebuie s fie tatl entitii B n relaia de conectare i c o
dependen de existen apare cnd cheia strin pentru relaie nu poate fi
nul.
Dac exist o dependen de existen n fig.4.13.b asociat cu
relaia pred atunci o instan de entitate GRUPA nu poate exista fr a fi
63

asociat cu o instan de entitate PROFESOR. Fiecare instan de entitate

GRUPA trebuie s aib un non-nul FACULTATE# pentru profesorul su.
Dac exist o dependen de existen n fig.4.9. asociat cu relaia
are
la
dosar,
atunci
o
instan
de
entitate
SCRISOARE_DE_RECOMANDARE nu poate exista fr a fi asociat cu o
instan
de
entitate
STUDENT_DSA.
Fiecare
instan
de
SCRISOARE_DE_RECOMANDARE trebuie s aib un non-nul MATRIC#
pentru studentul asociat cu ea.
Relaiile de conectare mai-muli-la-mai-muli nu evideniaz
dependene de exiaten. De exemplu, nu exist nici o dependen de
existen asociat cu relaia inscrie din fig.4.14. a. O grup va exista chair
fr studeni nscrii n ea (cel puin pn cnd este tears) i un student va
exista chiar dac nu este nscris n nici o grup.
S notm, totui, c exist dependen de existen n rezoluia
acestei relaii mai-muli-la-mai-muli din fig.4.14. O instan INSCRIERE nu
poate exista fr a fi asociat cu o instan GRUPA i cu o instan student.
Un alt exemplu de relaii de conctare fr 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
relaie poae fi rezolvat n dou relaii care au dependen de existen, aa
cum se vede n fig.4.15.b. Aici entitatea ASISTENT este dependent de
existena att a entitii CONSILIER ct i de cea a entitii CURS. O
persoan nu poate fi asistent dac nu i se asigneaz un curs de ctre consilier.
S notm c procesul de rezoluie folosit aici este acelai cu cel folosit n
obinerea fig.4.14 din fig.4.13.a.
Relaiile mai-muli-la-mai-muli i relaiile de conectare zero-sauunul-la-mai-muli sunt numite uneori relaii nespecifice, deoarece ele
mascheaz dependenele de existen.
Aceste relaii sunt specificate prin rezoluia unei relaii nespecifice
n dou relaii specifice, transformnd o conectare mai-muli-la-mai-muli n
dou conectri unul-la-mai-muli. O conectare zero-sau-unu-la-mai-muli
devine o relaie unu-la-mai-muli i o relaie unu-la-zero-sau-unu.
Notm cu E1 entitatea tat a unei relaii i cu E2 entitata fiu. Cheia
primar a lui E1 este mulimea de atribute A, care este deasemenea o cheie
strin n E2. Dac atributele A din E2 nu pot fi nule, atunci E2 este
dependent de existena 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 existena
lui E1. O instan a lui E2 poate exista fr ca ea s fie asociat cu o instan
a lui E1.
Dependena de identificator. O relaie de conectare poate avea
dependent de identificator. Dac exist o relaie ntre entitile A i B, atunci
64

entitatea B se zice dependent de identificator de entitatea A, dac i numai

dac: cheia primar a lui A, aprnd ca un atribut de cheie strin n B, este
complet coninut n cheia primar a lui B.
Cheia migratoare a entitii A este astfel o parte esenial a identificatorului
entitii B. n DMT, distincia ntre relaiile care au dependen de
identificator i cele care nu au, este fcut prin linie continu i linie punctat.
De exemplu, modelul din fig.4.14. cu atributele de chei este prezentat
fig.4.17. Ambele relaii sunt relaii de identificare iar cheile primare apar
ambele n cheia primar a relaiei fiu.
STUDENT

GRUPA
SECIE#
CURS#

MATRIC#

INROLARE
SECIE#
CURS#
MATRIC#

Fig.4.17. Model de date logice cu dou relaii de conectare de

identificare.
n fig.4.18. una din relaii 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 opiune care suprim tiprirea atributelor de cheie strin
pe diagrame. Atunci cnd aceast opiune se folosete, trebuie s existe o
distincie, alta dect plasarea atributelor, pentru a indica dependena de
identificator. Aici distincia este fcut prin arce solide sau ntrerupte.
O entitate care nu este dependent de identificator de nici o alt
entitate este desenat cu coluri drepte, iar o entitate care este dependent de
identificator de cel puin o alt entitate este desenat cu coluri rotunjite.
Entitile care nu sunt dependente de identificator pot sta singure, dar
entitile dependente de identificator sunt ntotdeauna gsite cu alte entiti.
S notm c dependena de identificator implic ntotdeauna
dependena de existen.
Integritatea referenial. Integritatea referenial este o restricie
care trebuie s fie satisfcut pentru relaii de conectare cu dependen de
65

existen (sau de identificator). Integritatea referenial este aseriunea c,

dac entitatea B este dependent de existena entitii A, atunci
valorile atributelor de cheie strin ntr-o instan a entitii B
trebuie s fie egale cu valoarea cheii primare din instana asociat a
entitii A.
De exemplu, dac ANGAJAT este dependent de existen de
DEPARTAMENT n fig.4.7., integritatea referenial spune c:
pentru orice instan a entitii ANGAJAT, valoarea atributului de
cheie strin DEPARTAMENT# trebuie s se potriveasc cu
valoarea de cheie primar DEPARTAMENT# din instana de
entitatea DEPARTAMENT asociat.
Similar, pentru relaiile din fig.4.15.b. dac ASISTENT este dependent de
existena lui CONSILIER i CURS, atunci integritatea referenial spune c
pentru fiecare instan a entitii ASISTENT, valoarea atributului de
cheie strin CONSILIER_ID trebuie s se potriveasc cu valoarea
din cheia primar din instana de entitate CONSILIER asociat, i
pentru fiecare instan a entitii ASISTENT, valoarea atributului
CURS# trebuie s se potriveasc cu valoarea din cheia primar din
instana de entitate CURS asociat
Part

Po

Part#

Po#

conine

apare n
Po_Line
Po#(Fk)
Line#
Part#(Fk)
Qty

Fig.4.18. Model de date logice cu o relaie de identificare i una de

neidentificare.
Reprezentarea restriciei de integritate referenial ntr-un model de date este
important deoarece
66

1. un model care exprim restricia de integritate referenial reprezint mai

explicit semantica datelor dect unul care nu o face.
2. integritatea referenial poate fi folosit pentru a verifica i menine
calitatea datelor.
Integritatea referenial este o aseriune despre instanele entitilor.
Aceast aseriune poate fi aplicat atunci cnd 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 instane
din DEPARTAMENT. Orice actualizare care leag o instan de ANGAJAT
cu o instan de DEPARTAMENT, fr 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 instane
de ANGAJAT. Instanele de ANGAJAT nu pot s existe fr a fi asociate cu
instane de DEPARTAMENT. S notm c modificarea valorii
DEPARTAMENT# din instana ANGAJAT este o modalitate valid de a
asocia instan cu o alt instan DEPARTAMENT.
Angajat

Tip_compensaie

Angajat cu ora

Angajat cu salariu

Fig.4.19.a. Exemple de relaii de categorie.

67

Pentru baza de date modelate n fig.4.15.b., urmtoarele actualizri

vor fi rejectate:
adugarea unei instane ASISTENT pentru care ori CURS# ori
CONSILIER_ID nu se potrivete cu cheia dintr-o instan CURS sau
CONSILIER existent.
legarea unei instane ASISTENT de o instan CURS sau CONSILIER
fr o potrivire n CURS# respectiv CONSILIER_ID.
tergerea unei instane CURS pentru care exist o instan ASISTENT.
tergerea unei instane CONSILIER pentru care exist instane
ASISTENT.
4.11. Relaii de categorie
Relaiile de conectare asociaz tipuri diferite de entiti, pe cnd relaiile de
categorie asociaz entiti similare.
O relaie de categorie are urmtoarele 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 entitii generice sunt motenite implicit de entitatea subtip.
6. are dependen de existen.
7. trebuie s se conformeze restriciei de integritate referenial.
8. poate avea dependen de identificator.
DMT folosete un cerc pentru a reprezenta o relaie de categorie.
Fig.4.19.a. modeleaz o situaie n care exist dou tipuri de
angajai, cu ora i salariai. Fiecare angajat poate fi un angajat cu ora sau un
angajat salariat, dar nu poate fi amndou la un loc. Atributele entitii
generice ANGAJAT sunt aplicabile, de asemenea, entitilor subtip
ANGAJAT_CU_ORA i ANGAJAT_CU_SALAR.
Fig.4.19.b. modeleaz o alt situaie n care exist trei tipuri de
angajai student, profesor i personal administrativ. Un angajat poate fi un
student, un profesor, un membru al personalului administrativ sau nici unul
dintre acetia.
n lumea real, o instan a entitii STUDENT reprezint exact
acelai obiect ca i instana entitii ANGAJAT cu care ea este asociat n
aceast relaie. Pe de alt parte, o relaie de conectare asociaz ntotdeauna
instane 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 instanele ORAS cu care el este legat.
Discriminator de subtip. O diagram a unei relaii arat entitatea
generic n vrf, cu un cerc coninnd un atribut al entitii generice ale crei
valori determin n ce subtip rezid o instan de entitate dependent

68

Angajat

particular. Acest atribut se numete discriminator de subtip. n fig.4.19.a

disciminatorul de subtip este atributul TIP_COMPENSATIE ale crei valori
determin dac un angajat particular este angajat cu ora sau permanent. n
fig.4.19.b. disciminatorul de subtip este atributul STATUS, a crui valoare
determin cnd un angajat particular este un student, un profesor sau un
administrator. S notm c discriminatorul de subtip este un atribut al entitii
generice, i nu al relaiei.
Angajat

Status

Student

Profesor

Administrativ

Fig.4.19.b. Exemple de relaii de categorie.

O mulime de relaii de categorii cu acelai discriminator de subtip
se numete clas de categorii. Fig.4.19.a. are dou relaii de categorii,
ambele ntr-o clas. Fig.4.19.b. are trei relaii de categorie, toate n aceai
clas. Fiecare cerc de categorie ntr-o diagram DMT reprezint o clas de
relaii de categorie. O entitate poate avea mai muli discriminatori de subtip,
ca n fig.4.20. Aici exist dou subclasificri de cldiri: TIP_FOLOSIRE
dintr-o instan CLADIRE indic dac aceasta este rezidenial, birouri,
magazine sau alte scopuri; TIP_CONSTRUCTIE indic dac este din
crmizi, prefabricate sau altele. O instan cladire dat poate avea valori att
pentru TIP_FOLOSIRE ct i pentru TIP_CONSTRUCTIE, de exemplu o
cladire din caramid pentru birouri sau o cladire din prefabricate rezidenial.

69

Punnd mpreun modelele din fig.4.19.a. i 4.19.b. obinem 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 entitii generice. Astfel, o instan a
entitii generice poate fi legat dfe o singur instan de subtip ntr-o clas
de categorii. n concordan cu fig.4.20. o construcie nu poate fi att una de
birouri ct i una rezidenial, i nici nu poate fi construit att din crmizi
ct i din prefabricate. Dac aceste reguli nu sunt adevrate, atunci modelul
nu reflect corect realitatea. Acest model nu reprezint o cladire care e parial
de birouri, parial rezidenial i parial magazine.
Cldire

Tip construcie
Tip folosire

Cldire
rezidenial

Cldire de
birouri

Cldire de
vnzare

Cldire din
crmizi

Cldire din
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 situaia n care o persoan poate
fi att profesor ct i student. Fig.4.21.b. modeleaz aceast situaie adugnd
o regul atributului discriminator, indicnd c instana PERSOANA poate
avea mai mult de o valoare pentru STATUS. Aceast convenie pentru a
relaxa restricia de exclusivitate mutual este rar folosit, o categorizare mai
judicioas eliminnd deasemenea problema.

70

Exclusivitatea mutual poate fi folosit pentru a verifica i menine

calitatea datelor. Astfel, o actualizare a bazei de date modelate n fig.4.20. va
fi rejectat dac ea ncearc s descrie o cldire att de birouri ct i
rezidenial.
Totalitate. O clas de categorii se spune a fi total dac orice
valoare valid a discriminatorului de subtip are o etichet subtip
corespunztoare. DMT reprezint o clas total de categorii desennd o linie
dubl sub cercul de relaie de categorie.

Persoana

Persoana

Status(>=0)

Status
Student

Student

Profesor

Profesor

b) Relaxarea regulii de
exclusivitate mutual prin
adugarea regulii >=0 pentru
atributul discriminator

a) Subtipuri mutual
exclusive

Fig.4.21. Exemple de ierarhie de categorie.

De exemplu, fig.4.22. arat o mulime complet de subtipuri de
student. Domeniul valorilor pentru discriminatorul de subtip i entitile
subtip prezentate n model determin mpreun dac o clas de categorii este
total.
Dependena de existen. Dependena de existen are loc
ntotdeuna ntr-o relaie de categorie. Pentru ca o instan a unui subtip s
existe, ea trebuie s aib o instan asociat a entitii generice. O cladire de
birouri nu poate exista fr a fi o cldire; un angajat cu ora nu poate exista
fr a fi un angajat.
71

Dac pentru un discriminator de subtip se permite a avea o valoare

nul i/sau mulimea valorilor este mai mare dect numrul subtipurilor
(adic, clasa categoriilor nu este total) atunci existena unei entiti generice
nu implic necesar existena entitii subtip corespunztoare. De exemplu, o
valoare nul n TIP_CONSTRUCTIE din fig.4.20. va indica faptul c o
instan dat de CLADIRE nu este nici din caramizi, nici din prefabricate.
Tipul de construcie poate fi de asemenea necunoscut sau nedisponibil.
Student

Status

Doctorand

Undergraduate

Neclasificat

Fig.4.22. Exemple de relaii de categorie cu mulime total de subtipuri.

Fiecare valoare a acestui atribut discriminator are o entitate subtip
potrivit.
Integritatea referenial. O relaie de categorie trebuie s se
conformeze ntotdeauna restriciei de integritate referenial. Cheile primare
migreaz pentru a deveni atribute de cheie strin n relaiile de categorie n
acelai mod cum o fac i n relaiile de conectare. O instan de entitate subtip
trebuie s fie asociat cu o instan de entitate generic a crei valoare de
cheie primar se potrivete cu valoarea atributului de cheie strin a
subtipului.
Dependena de identificator. O relaie de categorie poate sau nu
poate avea dependen de identificator. De exemplu, fig.4.23. prezint o
situaie n care dependena de identificator nu are loc. Entitatea generic este
INVESTITIE, cu cheia primar DATA, SURSA i TIPUL. Entitile subtip
sunt BURSA, CONTRACT, IMOBILIAR i C.D. Cu toate c ele motenesc
72

cheia primar a entitii generice (la fel, implicit, restul atributelor sale)
atributul de cheie strin nu este parte a cheilor primare ale subtipurilor.
Acest exemplu arat c o entitate subtip poate fi la rndul ei o entitate
generic.
Entitatea
IMOBILIAR
are
dou
entiti
subtip,
PROP_COMERCIALA i PROP_REZIDENTIALA. Dac se cere pentru
toate relaiile de categorie a avea dependen de identificator atunci va fi
posibil s modelm numai ierarhii de categorii i nu reele de categorii. Toate
exemplele prezentate au fost n fapt ierarhii.
Investiie
Data
Sursa

Tip. investiie

Bursa
Companie
Grad
Data(Fk)
Sursa(Fk)

Contract

Imobiliar
Locaia
Data(Fk)
Sursa(Fk)

Contract#
Data(Fk)
Sursa(Fk)

Prop_comercial

C.D.
C.D.I.D
Data(Fk)
Sursa(Fk)

Prop_rezidenial
Locaia(Fk)

Locaia(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 cteva sunt folosite de ctre companii i organizaii.
n aceast seciune vom descrie tehnicile cele mai cunoscute.
73

Modelul reea. Modelul reea a fost dezvoltat de ctre CODASYL

(Conference on Data System Languages) DBTG (Data Base Task Group) la
sfritul anilor 60 i la nceputul anilor 70 i de ctre Cincom Systems, Inc.,
cu sistemul su comercial de gestiune a bazelor de date TOTAL. Modelul
reea ncearc s ridice preocuparea de gestiune a datelor deasupra nivelului
de structuri de fiiere fizice, considernd structuri logice. Astzi, el nu este
considerat n totalitate a fi o tehnic semantic de modelare a datelor
deoarece este puternic legat de capacitile unui DBMS particular i are
posibiliti limitate de expresii semantice.
El lucreaz cu tipuri de nrgistrri. item-uri de date i tipuri de
mulimi care sunt n mare analoage cu entiti, atribute i relaii. Pn la
sfritul anilor 70 exista un amestec puternic de parametri de baz de date
logic i fizic ntr-un singur model reea. l vom studia n detaliu n
capitolele 7 i 12.
Modelul relaional. Modelul relaional a fost introdus de ctre E.F.
Codd de la IBM la nceputul anilor 70 i el ofer o abordare simpl i totui
riguroas matematic a modelrii datelor. El lucreaz cu datele n termeni de
tabele iar relaiile n tabele se formeaz prin partajarea atributelor, uzual prin
atribute de cheie strin. Modelul relaional a reinut atenia multor
cercettori n baze de date i este nc n vog prntre DBMS-uri comerciale.
Dar, n ciuda largii sale folosiri, astzi modelul relaional nu mai este n
general considerat o tehnic logic de modelare date, n primul rnd datorit
posibilitilor sale reduse de exprimare semantic. l vom studia n detaliu n
capitolele 5, 6 i 11.
Modelul Entitate-Mulime. Una din tehnicile de nceput n
modelarea logic a datelor a fost modelul entitate-mulime introdus n 1973
de ctre cercetorii de la IBM. Acest model recunoate entitile ca i colecii
de perechi nume-entitate = valoare-entitate. Ne exist conceptul de atribut,
orice (de ex: nume, vrst, departament) este o entitate. Relaiile sunt binare,
adic orice relaie poate asocia numai dou entiti. O dezvoltare a acestei
tehnici este produsul Information Analysis (IA) al lui Control Data
Corporation.
Modelul Entitate-Relaie. A fost introdus n 1975 de ctre Peter
Chen ca o alternativ la modelele relaional, reea i entitate-mulime. El
deseneaz entiti, atribute i relaii. Relaiile sunt n-are, adic orice relaie
dat poate asocia una, dou sau mai multe entiti iar un model poate
prezenta dependena de existen ntre entiti.
Modelul abstractizrii al lui Smith. Prima constribuie a acestui
model publicat n 1977 este distincia ntre relaiile de agregare i
generalizare, pe care noi le denumim relaii de conectare i de categorie.
Modelul introduce convenia ca entitile s aib un nume de substantiv i
include o notaie grafic pentru reelele agregare i generalizare.
Modelul de date semantice. Modelul de date semantice publicat n
1978 introduce un alt nivel de explcitare n reprezentarea constructelor de
74

modelare date loghice, recunoscnd trei tipuri de entiti (numite clase):

obiecte concrete (fizice), abstractizri (generalizri) i agregate (colecii
omogene). Acest model introduce, de asemenea conceptul de evenimente,
care sunt aciuni la care particip obiectele i identific trei tipuri de atribute.
IDEF1. IDEF1 (ICAM - Integrated Computer-Aided Manufacturing
- Definition Language -1) a fost dezvoltat la sfritul anilor 70 sub auspiciile
U.S.Air Force. El este un hibrid practic ntre modelul entitate-relaie i
modelul relaional i are metode companion pentru modelarea activitilor
IDEF0 i a dinamicii sistemelor IDEF2. O generaie ulterioar a lui IDEF1
este IDEF1-Extended (IDEFIX) i este derivat din DMT, care i are
rdcinile n IDEF1.
Modelul de date funcionale. Modelul de date funcionale i
limbajul su de modelare DAPLEX, publicate n 1981 ofer un cadru riguros
pentru a modela date ca entiti. El exprim relaiile ntre entiti ca funcii
care pot fi imbricate, de exemplu Rang (Instructor (Curs)). Ca i modelul
entitate-mulime, aici nu exist conceptul de atribut, mai mult, proprietile
unei entiti rezult aplicnd funcii entitii. DAPLEX poate fi folosit pentru
a descrie modele de date, pentru a defini restricii ntr-un model de date i
pentru a pune ntrebri 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 entiti, iar arcele
reprezint relaii. Proiectantul de date genereaz modele de date normalizate
(vezi cap.6) bazate pe dependene de intrare ntre atribute.
Gestionarul de proiectare (Design Manager). Este un produs
comercial sub licen MPS, Ltd. care lucreaz n conjuncie cu dicionarul 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 proiectri de baze de date.
4.13. Comentarii finale
Succesul tehnicilor de modelare de date comerciale certific recunoaterea
crescnd a importanei modelrii datelor n comunicaii i n descoperirea
semanticii datelor. Modelarea datelor este folosit rutinier pentru:
a crete nelegerea datelor i a semnficaiei lor de ctre o organizaie.
a documenta resursele de date.
a evalua din exterior pachete software.
a planifica sisteme informatice.
a proiecta sistemele informatice.
a integra resursele de date
75

 a proiecta i a implementa baza de date fizice

Modelarea datelor logice este o parte esenial 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
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 modelrii datelor pot fi
apoi transformate n proiectri de baze de date fizice.
Memento
Model de activitate
Relaie de agregare
Cheie alternat
Aseriune
Atribut
Cheie candidat
Relaie de categorie
Clas de categorii
Cheie compus
Relaie de conectare
Entitate
Dependen de existen
Atribut cheie strin
Model funcie
Model semantic de date
Discriminator de subtip

Relaie de generalizare
Entitate generic
Model ierarhic
Dependen de identificator
Cheie
Model de date logice
Model reea
Model de date fizice
Cheie primar
Model de proces
Integritate referenal
Model relaional
Relaie
Nume de rol
Semantic

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