Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor 1 CAPITOLUL 2 MODELAREA DATELOR Proiectarea corectă a structurii unei baze de date… [606265]

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor
1 CAPITOLUL 2

MODELAREA DATELOR

Proiectarea corectă a structurii unei baze de date relaționale este o premisă fundamentală
în scrierea programelor de aplicație și in function area lor fara anomalile care pot apare in
cazul unei structuri defectuoase. Acest capitol pre zinta un model de date folosit in
proiectarea conceptuala de nivel inalt numit modelul entitate asociere (EA) in varianta
clasica (cu unele extensii). Intr-un alt capitol vo r fi prezentate regulile de transformare din
modelul entitate-asociere in modelul relational.

2.1. Etapele dezvoltarii unei aplicatii

Proiectarea structurii bazelor de date relationale este un domeniu in care cercetarile au
evoluat spre elaborarea unor metodologii teoretice și a unor instrumente software care
asigura un grad ridicat de normalizare a schemelor de relatie, pastrarea integritatii,
evitarea anomaliilor datorate unei proiectari nesis tematice și eliminarea subiectivismului
proiectantului prin inlocuirea lui cu exactitatea m etodei.

Pana la aparitia unor astfel de metodologii se porn ea de la o colectie de tabele și de la
dependentele functionale și multivalorice asociate și se ajungea, prin aplicarea unor
algoritmi sau metode de normalizare la schema dorit a a bazei de date. Aceasta abordare
de tip bottom-up creaza insa dificultati in cazul b azelor de date complexe in care numarul
de tabele și de dependente este mare. Probabilitate a ca unele interdependente intre date
sa nu fie sesizate in procesul de proiectare este i n aceste cazuri ridicat rezultand in
exploatare anomalii care duc la reluari ale ciclulu i analiza cerintelor → schema bazei de
date → programe de aplicatie.

Cercetarile in domeniul proiectarii schemei concept uale s-au concentrat pe gasirea unor
metodologii top-down pentru obtinerea unei structur i optime a BD. Ele au fost
influentate de rezultatele obtinute in domenii care folosesc bazele de date: inteligenta
artificiala, proiectarea asistata de calculator, ab ordarea orientata pe obiecte.

Impactul conceptelor de abstractizare și generaliza re precum și elaborarea unui model de
descriere informala a datelor, și anume modelul ent itate-asociere (EA), au dus la gasirea
unor cai algoritmizabile de proiectare optima a baz elor de date. Modelul entitate-asociere
este in acest moment cel mai popular model de comun icare a structurii bazelor de date
datorita intuitivitatii și simplitatii elementelor sale. Imbunatatiri sale ulterioare prin

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

2 folosirea abstractizarilor și generalizarilor au du s la crearea de variante ale modelului,
doua dintre acestea fiind descrise in acest capitol .

Extensiile modelului EA au aparut și pentru alte ne cesitati:
• modelarea cerintelor de secretizare a datelor,
• documentarea programelor de aplicatie și usurarea c omunicarii intre
proiectantul de sistem și utilizatorul obisnuit,
• proiectarea bazelor de date complexe pe portiuni și integrarea ulterioara a
acestora (asa numita integrare a vederilor).

Avantajul principal al modelului EA este acela al s implitatii sale și al caracterului sau
intuitiv. Rezultatul proiectarii consta intr-o diag rama entitate-asociere care poate fi apoi
translatata in modelul de date folosit de sistemul de gestiune a bazelor de date ales pentru
dezvoltarea aplicatiei.

Figura 2.1. prezinta schematic etapele proiectarii unei noi aplicatii care gestioneaza o baza
de date, cu accentul pe partea de proiectare a stru cturii acesteia. Aceste etape sunt
detaliate in paragrafele urmatoare.

2.1.1. Analiza de sistem

In aceasta etapa se realizeaza analiza segmentului din lumea reala care va fi gestionat de
aplicatia respectiva. Rezulta o specificatie neform alizata a cerintelor constand din doua
componente:

1. Cerinte privind continutul bazei de date: categoriile de date care vor fi stocate și
interdependentele dintre acestea.
2. Cerinte privind prelucrarile efectuate de aplicatie : prelucrarile efectuate asupra
datelor, arborele de meniuri al aplicatiei, machete le formatelor de introducere și
prezentare a datelor și ale rapoartelor tiparite de aceasta.

In general aceasta etapa nu poate fi asistata prin programe de tip CASE dar exista reguli
care ajuta proiectantul in realizarea sa. Activitat ile desfasurate includ:
• Analiza activitatii desfasurate la momentul respect iv de beneficiarul aplicatiei sau de o
multime reprezentativa de beneficiari in cazul apli catiilor de uz general.
• Analiza continutului de date și a functionalitatii aplicatiilor software – daca exista –
care vor fi inlocuite de noua aplicatie incluzand m eniuri, machete ecran și machete de
rapoarte.
• Analiza formularelor tipizate și a altor documente utilizate de beneficiar pentru
realizarea activitatii respective.
• Identificarea tuturor interdependentelor dintre dat ele care vor fi stocate in baza de
date și a restrictiilor privind valorile pe care le pot lua anumite categorii de date.
• Identificarea – daca este cazul – a prelucrarilor c are se declanseaza automat atat in
cazul modificarii bazei de date cat și la momente p restabilite de timp (de exemplu
sfarsit de luna, de an, etc.)
• Identificarea operatiilor care sunt necesare benefi ciarului in activitatea curenta dar
care in acest moment nu sunt realizate prin interme diul aplicatiilor software folosite
precum si a operatiilor care pot fi incluse in mod natural in noua aplicatie.

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

3

Independent de
platforma folosită

Dependent de
platforma folosită

Fig. 2.1. Etapele proiectării unei aplicații

Cerințe func ționale
ale aplicației Cerințe privind
baza de date
Diagrama EA Analiza de
sistem
Proiectarea
conceptuală
Transformare în
model relațional
Schema candidat a
bazei de date
Normalizare
Schema bazei de
date
Implementare
specifică SGBD-
ului folosit Proiectarea
funcțională
Diagrame de
specificare
funcțională
Realizare
programe de
aplicație
Programele
aplicației Baza de date a
aplicației

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

4 • Identificarea bazelor de date existente care pot fi folosite de noua aplicatie – direct sau
printr-un import initial de date – evitandu-se in a cest fel reintroducerea manuala a
acestora.
• Identificarea modalitatilor de transfer de date int re noua aplicatie și alte aplicatii care
ruleaza deja la beneficiar și care vor fi folosite și in viitor de catre acesta.
• Identificarea necesitatilor privind datele și prelu crarile care pot fi in viitor necesare
beneficiarului, deci a posibilelor dezvoltari in ti mp ale aplicatiei.

Aceasta etapa este efectuata de personal calificat avand in vedere ca rezultatele sale sunt
baza de la care se pleaca in etapele urmatoare, eve ntualele erori putand fi corectate
ulterior cu costuri semnificative.

2.1.2. Proiectarea conceptuală a bazei de date

In aceasta etapa, pornind de la rezultatele analize i de sistem, se realizeaza modelarea
cerintelor privind datele folosind un model de nive l inalt. Cel mai popular model folosit
pentru aceasta este modelul entitate-asociere (EA). Actualmente exista pe piata
numeroase instrumente CASE care folosesc diverse va riante ale modelului. Motivele
pentru care a fost ales sunt urmatoarele:
• Nu este legat direct de nici unul dintre modelele f olosite de sistemele de gestiune a
bazelor de date (relational sau orientat obiect) da r exista algoritmi bine pusi la punct
de transformare din model EA in celelalte modele de date.
• Este intuitiv, rezultatul modelarii fiind o diagram a care defineste atat datele stocate in
baza de date cat și interdependentele dintre aceste a.
• Poate fi usor de inteles de nespecialisti. Aceasta caracteristica este foarte importanta
in momentul in care se face punerea de acord cu ben eficiarul asupra structurii bazei
de date a aplicatiei, evitandu-se in acest fel o pr oiectare neconforma cu realitatea sau
cu cerintele exprimate de acesta.
• Proiectarea se poate face pe portiuni, diagramele p artiale rezultate putand fi apoi
integrate pe baza unor algoritmi și metode bine pus e la punct.

2.1.3. Transformare în model relațional

In aceasta etapa entitatile și asocierile care form eaza diagrama EA se transforma pe baza
unor reguli clare in structura relationala a bazei de date. Rezulta schema preliminara a
acesteia formata din tabele (relatii in terminologi a relationala), coloanele acestora (atribute
ale relatiilor) și constrangerile de integritate ca re pot fi deduse automat din diagrama
incluzand unele interdependente intre date numite ș i dependente functionale . In
capitolul 3 este descrisa o metoda de transformare din modelul EA clasic in modelul
relational. In cazul variantei specifice uneltelor CASE transformarea se face automat de
catre acestea.

2.1.4. Normalizare

Exista o serie de reguli care descriu ce inseamna o structura corecta a unei tabele și care
definesc asa numitele forme normale . Pe baza structurii bazei de date și a dependentel or
rezultate atat din transformarea in model relationa l cat și a altor dependente identificate
de proiectant in analiza de sistem se poate face o operatie numita normalizare
modificand structura bazei de date astfel incat toa te tabelele din aceasta sa fie in forma
normala dorita. Capitolul 3 contine definitia forme lor normale uzuale și descrierea unor

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

5 algoritmi de normalizare care sunt folositi de unel tele CASE pentru efectuarea automata
a operatiei.

2.1.5. Implementarea specifică sistemului de gestiu ne folosit

In aceasta etapa se realizeaza crearea structurii b azei de date obtinuta in etapa precedenta
pe baza facilitatilor oferite de sistemul de gestiu ne a bazelor de date ales. Rezultatul ei
este programul de creare scris in limbajul de defin itie a datelor acceptat de SGBD-ul
utilizat. Iata un exemplu:
Schema conceptala:
Student(CodStudent:Numeric , Nume:Șir, DataNasterii:Dată)
Program de creare (SQL-Oracle):
Create table Student(
CodStudent Number(5) Primary Key,
Nume Varchar2(40),
DataNasterii Date);
Programul contine atat definirea tabelelor cat și d efinirea celorlalte obiecte ale bazei de
date și a interdependentelor dintre acestea (de exe mplu constrangerile de integritate intra-
tabela și inter-tabele).
De asemenea aici se fac și toate operatiile privind proiectarea la nivel fizic a bazei de date.
In cazul folosirii de unor unelte CASE programul de creare poate fi generat și executat
automat.

Prezentam in continuare elementele care definesc mo delul entitate asociere in cele doua
variante: clasic și specific instrumentelor CASE.

2.2. Modelul entitate-asociere clasic

Acest model a fost introdus de P. P. Chen in 1976 ( [Ch 76]). El se constituie intr-o
abordare de tip grafic a proiectarii bazelor de dat e si a fost adoptat de comunitatea
stiintifica precum si de producatorii de software i n domeniu datorita simplitatii si
expresivitatii sale.

2.2.1. Elementele modelului

Modelul entitate-asociere permite reprezentarea inf ormatiilor despre structura bazelor de
date folosind trei elemente de constructie: entitat i, atribute ale entitatilor și asocieri intre
entitati. Definitia lor informala este urmatoarea:

Entitatile modeleaza clase de obiecte concrete sau abstracte despre care se colecteaza
informatii, au existenta independenta și pot fi ide ntificate in mod unic. Exemple de
entitati: Studenti, Orase, Angajati, etc. Ele defin esc de obicei persoane, amplasamente,
obiecte sau evenimente cu importanta informationala . Membrii unei clase care formeaza
o astfel de entitate poarta numele de instante ale acelei entitati. De remarcat ca intreaga
literatura de specialitate defineste intii conceptu l de multime de entitati (sau tip de
entitati) pentru ca apoi sa adopte pentru usurinta exprimarii prescurtarea de entitate
pentru acest concept. Deci entitatea este un obiect generic care reprezinta multimea
tuturor instantelor sale.
Entitatile sunt de doua categorii:

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

6 1. Entitati independente (sau tari) sunt cele care au existenta independenta de alte
entitati,
2. Entitati dependente (sau slabe) sunt formate din in stante care isi justifica incadrarea
in clasa respectiva doar atita timp cit intr-o alta entitate (tata) exista o anumita
instanta de care sunt dependente. De exemplu in caz ul unei baze de date de personal,
fiecare instanta a entitatii COPII ramine in clasa respectiva (copiii angajatilor) atit
timp cit in entitatea ANGAJATI exista instanta repr ezentand pe tatal/mama acelui
copil.

Element al
modelului Tip Reprezentare Exemplu
Tare

Entitate
Slaba

De identificare

Atribut
De Descriere

Asociaza 1-2
entitati Nume asociere

Inscris_La Asociere
Asociaza mai
mult de 2
entitati
(exemplu: 3
entitati) 3: 6:

. . . . . . .

Alocare

Fig. 2.2. Conventia de reprezentare a elementelor m odelului EA

Atributele modeleaza proprietati atomice distincte ale entita tilor. De exemplu entitatea
STUDENTI poate avea ca atribute Matricola, Nume, Pr enume, Varsta, Anul, Grupa, etc.
In procesul de modelare vor fi luate in considerare doar acele proprietati ale entitatilor
care sunt semnificative pentru aplicatia respectiva . Din acest motiv, la entitatea
STUDENTI nu vom lua in considerare caracteristici c a Talia sau Culoarea_parului
acestea nefiind necesare pentru baza de date a univ ersitatii (astfel de atribute ar putea
exista de exemplu intr-o baza de date privind perso nalul militar).

Atributele unei entitati sunt de doua feluri:
• atributele de identificare (formand impreuna identificatorul entitatii ) reprezinta
acea multime de atribute care permit distinctia int re instantele aceleiasi entitati Nume entitate STUDENT
Nume entitate COPIL
CodStudent Nume
atribut
Nume
atribut Nume

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

7 • atributele de descriere (sau descriptori) sunt folositi pentru memorarea
caracteristicilor suplimentare ale instantelor.
In exemplul de mai sus Matricola este atribut de id entificare (deoarece nu pot exista doi
studenti cu aceeasi matricola intr-o facultate) pe cand celelalte atribute sunt descriptori.

Asocierile modeleaza interdependentele dintre clasele de obie cte reprezentate prin
entitati. De exemplu intre entitatile STUDENTI și F ACULTATI se poate figura o
asociere INSCRIS_LA care descrie impartirea student ilor pe facultati.
In crearea diagramei nu vor fi luate in considerati e decit interdependentele care sunt
necesare aplicatiei respective, in lumea reala puta nd exista intre entitatile diagramei și alte
asocieri care nu sunt semnificative in contextul da t.

Figura 2.2. prezinta conventia de reprezentare graf ica a celor trei tipuri de constructii care
participa la formarea unei diagrame EA. Se observa ca:

• Entitatile se reprezinta prin dreptunghiuri in care este inscris numele entitatii. In cazul
entitatilor dependente (slabe), conturul va fi cu l inie dubla.
• Atributele se reprezinta prin cercuri (sau ovale) i n interiorul carora apare numele
atributului. Ele sunt conectate cu un segment de dr eapta la entitatea de care apartin.
Pentru a distinge atributele de identificare de cel e de descriere, numele primelor va fi
subliniat.
• Asocierile se reprezinta prin romburi (daca conecte aza una sau doua entitati) sau
poligoane regulate (daca conecteaza mai mult de dou a entitati) conectate prin
segmente de dreapta la entitatile asociate, avand i nscris in interior (sau alaturi) numele
asocierii. Alte elemente grafice specificand caract eristici suplimentare ale asocierilor
vor fi introduse in paragrafele urmatoare.

2.2.2 Extensii ale modelului

Modelul entitate-asociere clasic are unele lipsuri in ceea ce priveste posibilitatea modelarii
caracteristicilor asociate unor subclase de obiecte modelate prin simple entitati. Pentru
aceasta, la modelul original au fost adaugate doua noi concepte: ierarhia de generalizare
și ierarhia de incluziune . Prima defineste partitionarea instantelor unei en titati in n
subclase diferite iar a doua permite clasarea unora dintre instantele unei entitati in m
subclase care nu reprezinta o partitie in sens mate matic. Din punct de vedere formal, cele
doua concepte se pot defini astfel:

Definitie (ierarhia de incluziune): O entitate E 1 este o submultime a entitatii E (sau
este inclusa in entitatea E) daca fiecare instanta a lui E1 este de asemenea o instanta a lui
E.
Un exemplu de incluziune este definirea in cadrul e ntitatii ANGAJATI a unor subclase
modelate prin entitatile INGINERI, ECONOMISTI si CO LABORATORI.
In cazul ierarhiei de incluziune entitatile fiu pot sa nu fie disjuncte doua cite doua: pentru
exemplul dat, exista angajati ingineri si care sunt incadrati cu contract de colaborare. De
asemenea reuniunea lor poate sa nu acopera in intre gime entitatea tata: exista angajati
care nu sunt nici ingineri, nici economisti si nici colaboratori.

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

8 Definitie (ierarhia de generalizare): O entitate E este generalizarea entitatilor E 1, E 2,
…, E n daca orice instanta a lui E este de asemenea insta nta in una și numai una din
entitatile E 1, E 2, …, E n.
Un exemplu de generalizare este clasarea instantelo r entitatii ANGAJATI in subclasele
BARBATI și FEMEI.
Caracteristica ierarhiei de generalizare este ca di n punct de vedere matematic entitatile fiu
reprezinta o partitie a entitatii tata:
a. E1 ∪ E 2 ∪ … ∪ E n = E și
b. Ei ∩ E j = ∅ pentru orice i ≠ j din intervalul 1..n

Ierarhiile de incluziune și generalizare se foloses c doar in cazul in care pentru subclasele
unor clase modelate prin entitati este nevoie de st ocarea unor informatii suplimentare
specifice.
In cazul unei baze de date de personal este nevoie de exemplu sa fie memorat numarul de
copii ai fiecarui angajat. Acest fapt se poate mode la in doua feluri: fie prin adaugarea la
entitatea ANGAJATI a unui atribut suplimentar NumarCopii (care va avea valoarea 0
pentru angajatii fara copii) fie prin aparitia unei entitati suplimentare CU_COPII aflata
intr-o relatie de incluziune cu entitatea ANGAJATI și care va avea ca atribute de
identificare pe cele ale tatalui iar ca atribut des criptiv numarul de copii, acesta fiind
atributul specific subclasei.

Element Reprezentare Exemplu
Ierarhie
de
incluziune

Ierarhie
de
generali-
zare

Fig. 2.3. Conventia grafica de reprezentare grafica a ierarhiilor

Vom alege a doua varianta in cazul in care numarul angajatilor cu copii este mult mai mic
decit numarul total al angajatilor, fapt care va du ce la economie de spatiu pe disc: in acest E
E1 E2 E3 Angajati
Economisti Ingineri Colab.
E
E1 E2 Criteriu Angajati
Barbati Femei Sex

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

9 caz o noua entitate – din care va rezulta o tabela a bazei de date – va ocupa mai putin
spatiu decat un atribut suplimentar – din care rezu lta o coloana suplimentara a tabelei
SALARIATI.
Conventia grafica de reprezentare a celor doua tipu ri de ierarhii se gaseste in fig. 2.3.

2.2.3. Caracteristici ale elementelor modelului

Asa cum entitatile au atribute care specifica diver sele proprietati ale clasei de obiecte
modelate, și asocierile au caracteristici care aduc informatii suplimentare. Acestea sunt
urmatoarele:

Gradul asocierii

Este o valoare numerica intreaga si este dat de num arul de entitati care participa la acea
asociere. Asocierile de grad 1, 2 și 3 se mai numes c si asocieri unare , binare si respectiv
ternare .

Pentru exemplificare vom considera o baza de date c ontinand informatii despre studenti,
proiectele realizate de acestia, calculatoarele pe care au alocate ore de lucru si facultatile la
care sunt inscrisi. De asemenea vom considera ca un ii dintre studenti au un tutor care ii
indruma, acesta fiind un student dintr-un an mai ma re.
Diagrama EA a bazei de date este prezentata in figu ra 2.4. Pentru simplificarea figurii, nu
s-au reprezentat decit entitatile și asocierile din tre ele nu și atributele fiecarei entitati in
parte.

Tutor Inscris_la

Alocare

Fig. 2.4. Exemple de asocieri de grad 1, 2 si 3

Asocierea TUTOR este o asociere unara deoarece la e a participa doar entitatea
STUDENT. Aceasta asociere arata cine este tutorul f iecarui student (daca exista).
Asocierea INSCRIS_LA este o asociere binara intre e ntitatile STUDENT și
FACULTATE si arata la ce facultate/facultati este i nscris fiecare student.
Asocierea ALOCARE este o asociere ternara intre ent itatile STUDENT, PROIECT și
CALCULATOR. Ea modeleaza pe ce calculatoare are alo cate ore de lucru fiecare student
pentru fiecare proiect.

Un exemplu de asociere de grad mai mare ca trei est e orarul unui an de studiu al unei
facultati. Acesta este o asociere intre urmatoarele entitati: PROIECT FACULTATE STUDENT
CALCULATOR

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

10 • GRUPE. Fiecare grupa are un cod unic.
• SALI. Salile sunt etichetate printr-un indicativ al fanumeric.
• INTERVALE ORARE. Un interval orar este un triplet ( Zi, De la ora, La ora)
• ACTIVITATE. Este o activitate prezenta in orar (cur s, laborator, seminar, proiect).
• PROFESOR. Este cadrul didactic titular pentru o act ivitate

Modelarea acestor clase de obiecte ca entitati pres upune faptul ca in baza de date sunt
stocate si alte informatii despre ele. Diagrama EA este prezentata in figura 2.5. Ea
modeleaza programarea activitatilor didactice efect uate de profesori pe intervale orare,
sali si grupe.

Orar

Fig. 2.5. Asociere de grad 5

Conectivitatea asocierii

Este specifica fiecarei ramuri a unei asocieri și p oate avea una din urmatoarele doua
valori: unu sau multi . Determinarea ei pentru ramura spre o entitate E s e face astfel:
fixand arbitrar cite o instanta pentru celelalte en titati care participa la asociere se pune
intrebarea: cite instante ale lui E pot fi conectat e cu acestea? Daca poate fi cel mult una,
conectivitatea ramurii este unu , altfel conectivitatea este multi .

Pentru exemplul din figura 2.4.:
• Asocierea TUTOR este unu-unu sau multi-uni dupa cum un student poate fi tutor
pentru un singur alt student sau pentru mai multi s tudenti de an inferior.
• Asocierea INSCRIS_LA este multi-unu (multi spre STU DENT) sau multi-multi dupa
cum un student poate fi inscris la una sau mai mult e facultati.
• Asocierea ternara ALOCARE (aplicam definitia):
• ramura spre STUDENT: fiind dat un proiect si un cal culator, citi studenti au ore
alocate pe acel calculator pentru respectivul proie ct? Presupunand ca mai multi
studenti lucreaza pentru acelasi proiect pe acelasi calculator ramura va fi multi .
• ramura spre PROIECT: fiind dat un student și un cal culator, la cite proiecte are
acesta alocate ore pe acel calculator? Presupunand ca pentru fiecare proiect exista
un calculator dedicat, ramura va fi unu .
• ramura spre CALCULATOR: fiind dat un student și un proiect, pe cate
calculatoare are alocate acesta ore pentru realizar ea proiectului? Presupunand ca
la un proiect se lucreaza pe un singur calculator, ramura va fi unu .
Deci asocierea ALOCARE este multi-unu-unu. SALA ACTIVITATE GRUPA
INTERVAL
PROFESOR

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

11 Observam ca raspunsul la fiecare din cele trei intr ebari se da in functie de realitatea
modelata. Aceeasi asociere poate avea conectivitati diferite in cazuri diferite: daca exista
chiar si un singur proiect la care un student are o re alocate pe mai mult de un calculator,
ramura spre CALCULATOR va fi multi iar asocierea va fi multi-unu-multi.

Conventia de reprezentare grafica a conectivitatii folosita in aceasta prezentare este
urmatoarea: ramurile 'unu' vor fi reprezentate sub forma de sageata. In figura 2.6. sunt
prezentate cele trei asocieri avand figurata și con ectivitatea. S-a presupus ca asocierile
TUTOR si INSCRIS_LA sunt unu-unu respectiv multi-un u.

Tutor Inscris_la

Alocare

Fig. 2.6. Reprezentarea conectivitatii

Obligativitatea asocierii

Ca și conectivitatea, aceasta se determina pentru f iecare ramura și poate avea doar una
din urmatoarele valori: obligatorie sau optionala . Determinarea ei pentru ramura spre o
entitate E se face astfel: fixand arbitrar cite o i nstanta pentru celelalte entitati care
participa la asociere se pune intrebarea: este obli gatoriu sa existe o instanta a lui E
asociata cu acestea? Daca raspunsul este 'Da' ramu ra este obligatorie altfel este
optionala .

In exemplul anterior ramurile asocierilor TUTOR si ALOCARE sunt optionale iar cele
ale asocierii INSCRIS_LA sunt obligatorii deoarece:
• Pentru asocierea TUTOR: exista studenti care nici n u au un tutor nici nu sunt tutori
pentru alti studenti
• Pentru asocierea ALOCARE:
– Un student la un proiect poate sa nu aiba alocate ore pe nici calculator (de exemplu
in cazul unui proiect la o materie umanista)
– Un student si un calculator respectiv un calculat or si un proiect pot sa nu fie asociati
prin alocare de ore de lucru (de exemplu pentru cal culatoarele din birourile cadrelor
didactice)
• Pentru asocierea INSCRIS_LA: nu exista studenti car e nu sunt inscrisi la nici o
facultate si nici facultati fara studenti inscrisi.

Conventia de reprezentare grafica a clasei de apart enenta folosita in continuare este
urmatoarea: ramurile obligatorii vor fi reprezentat e prin linie continua iar cele optionale
prin linie intrerupta. In figura 2.7 este prezentat a diagrama anterioara avand figurata si
obligativitatea. PROIECT FACULTATE STUDENT
CALCULATOR

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

12 Daca gradul și conectivitatea unei asocieri sunt fo losite in proiectarea conceptuala a
schemei bazei de date, obligativitatea se modeleaza pentru definirea unui criteriu de
integritate specificand posibilitatea de aparitie a valorilor nule: la transformarea diagramei
EA in model relational atributele tabelelor care mo deleaza informatia reprezentata de
asocieri pot avea sau nu valori nule dupa cum ramur ile acestora sunt optionale sau
obligatorii.

Atributele asocierilor

In unele cazuri o anumita informatie descriptiva nu este asociata cu o clasa de obiecte ci
cu un ansamblu de clase diferite modelate fiecare p rin entitati. In acest caz aceasta va fi
modelata ca un atribut al asocierii dintre entitati le respective. Sa luam de exemplu cazul
unei asocieri multi-multi A_ABSOLVIT intre entitati le STUDENT și FACULTATE
care contine informatii privind facultatile absolvi te anterior de unii studenti.

A_Absolvit

In acest caz informatii ca anul absolvirii, media, specializarea nu pot fi conectate nici la
STUDENT (pentru ca un student poate fi absolventul mai multor facultati in ani diferiti,
cu medii diferite, etc.) si din motive similare nic i la FACULTATE. Ele descriu asocierea
unui student cu o facultate si de aceea vor fi atas ate asocierii A_ABSOLVIT. Toate
atributele unei asocieri sunt atribute descriptive, neexistand in acest caz un identificator al
asocierii.

Rolul

In cazul in care de la o asociere pornesc mai multe ramuri catre aceeasi entitate, fiecareia
dintre acestea i se poate asocia un rol. Acesta ara ta semnificatiile diferite pe care le are
aceeasi entitate in cadrul asocierii respective.

tutor
Tutor Inscris_la

discipol

Alocare

Fig. 2.7. Reprezentarea obligativitatii. Roluri
PROIECT FACULTATE STUDENT
CALCULATOR FACULTATE STUDENT
AnAbsolvire Medie Specializare

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

13 In cazul asocierii TUTOR cele doua ramuri pot fi et ichetate de exemplu cu tutor si
discipol aratand ca instante diferite ale aceleiasi entitat i au rolurile respective (fig. 2.7.).

2.2.4. Criterii de modelare

a. Clasificarea in entitati și atribute

Desi definitia notiunilor de entitate, atribut, aso ciere este destul de simpla, in practica
modelarii apar dificultati in clasificarea diversel or informatii intr-una din aceste categorii.
De exemplu in cazul sediilor unei banci localizate in diverse orase: obiectul ORAS este
entitate distincta sau atribut descriptiv al entita tii SEDIU?

Pentru a putea clasifica corect informatiile, exist a citeva reguli care trebuie respectate și
pe care le prezentam in continuare. Prima regula da un criteriu general de impartire in
entitati și atribute, urmatoarele doua semnaleaza e xceptii iar ultimele doua reguli au un
caracter mai putin normativ ci mai degraba orientat iv.

Regula 1. Entitatile au informatii descriptive, pe cand atrib utele nu poseda astfel de
informatii.
Daca exista informatii descriptive despre o anumita clasa de obiecte, aceasta va fi
modelata ca o entitate. In cazul in care pentru pen tru acea clasa de obiecte nu este nevoie
decit de un identificator (codul, denumirea, etc), ea va fi modelata ca un atribut. De
exemplu daca despre un ORAS este necesara stocarea in baza de date unor informatii ca
JUDET, POPULATIE, etc. atunci ORAS va fi o entitate . Daca singura informatie
necesara este numele sau atunci NUME_ORAS va fi un atribut al altei entitati.

Regula 2. Atributele multivalorice vor fi reclasificate ca en titati.
Daca la o valoare a unui identificator corespund ma i multe valori ale unui descriptor,
acesta va fi clasat ca entitate. De exemplu, in caz ul unei baze de date privind localizarea in
teritoriu a unor banci, daca se memoreaza informati i doar despre banci care au un singur
sediu, LOCALITATE este atribut al entitatii BANCA.

Bucu resti, Cluj, Iasi

Daca insa se memoreaza informatii despre banci care au sucursale și filiale in diverse
localitati, deci pentru o singura banca (o valoare a identificatorului entitatii BANCA)
avem mai multe localitati in care aceasta are sedii (mai multe valori ale descriptorului
LOCALITATE), atunci LOCALITATE va fi entitate disti ncta desi nu are decat un
singur atribut. Pentru a modela localizarea sediilo r in diverse localitati intre cele doua
entitati va exista o asociere binara unu-multi (unu spre BANCI) numita de exemplu
ARE_SEDIU_IN.

Are_Sediu_ In

BANCA Localitate
LOCALITATE BANCA Nume

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

14 Regula 3. Atributele unei entitati care au o asociere multi-u nu cu o alta entitate vor fi
reclasificate ca entitati.
Asa cum am vazut asocierile pot lega doar entitati. Daca un descriptor al unei entitati este
intr-o relatie multi-unu cu o alta entitate acel de scriptor va fi trecut in categoria entitatilor.
De exemplu, daca avem entitatile BANCA avand ca atr ibut descriptiv monovaloric
LOCALITATE și JUDET, daca se doreste modelarea apar tenentei la judete a localitatilor
va exista o asociere multi-unu intre atributul LOCA LITATE și entitatea JUDET.

In acest caz LOCALITATE va fi reclasificata ca enti tate desi nu sunt necesare alte
informatii in afara numelui localitatii.

Regula 4. Atributele vor fi atasate la entitatile pe care le descriu in mod nemijlocit. De
exemplu, UNIVERSITATE va fi atasat ca atribut al en titatii FACULTATE și nu al
entitatilor STUDENT sau PROFESOR.

Regula 5. Folosirea identificatorilor compusi va fi evitata. Identificatorul unei entitati
este acea submultime de atribute ale acesteia care identifica in mod unic fiecare instanta a
sa. In model relational pentru atributele de acest fel se construiesc de regula structuri de
cautare rapida (indecsi) care functioneaza cu atat mai lent cu cat complexitatea indecsului
creste. Aplicarea acestei reguli se poate face in d iverse moduri:
1. Daca identificatorul unei entitati este compus din mai multe atribute care sunt toate
identificatori in alte entitati, acea entitate se e limina. Informatia continuta de aceasta
va fi modelata sub forma unei asocieri intre acele entitati.
2. Daca identificatorul unei entitati este compus din mai multe atribute care nu sunt
toate identificatori in alte entitati, exista doua solutii:
• Entitatea respectiva se elimina și este inlocuita p rin alte entitati si asocieri astfel
incit pe ansamblu informatia modelata in varianta o riginara sa fie pastrata.
• Entitatea respectiva ramine in forma originara, cu dezavantaje insa in privinta
vitezei operatiilor.

Se vede ca procedura clasificarii obiectelor in ent itati și atribute este iterativa:
• se face o prima impartire conform primei reguli
• parte din atributele astfel obtinute se reclasifica in entitati conform regulilor 2 si 3
• se face o rafinare finala conform regulilor 4 si 5.
JUDET BANCA Localitate
JUDET BANCA LOCALITATE Nume

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

15 b. Identificarea ierarhiilor de generalizare și inc luziune.

In cazul in care despre anumite subclase ale unei c lase de obiecte exista informatii
specifice, clasa și subclasele (care la pasul anter ior au fost catalogate ca entitati) sunt
interconectate intr-o ierarhie de incluziune sau ge neralizare, dupa cum este cazul. La acest
pas se face și o reatasare a atributelor pentru evi tarea redundantei, astfel:
• La entitatea tata vor fi atasate atributele care fo rmeaza identificatorul și descriptorii
care modeleaza informatii specifice intregii clase.
• La entitatile fiu vor fi atasate atributele de iden tificare (aceleasi ca ale tatalui) și
atributele care modeleaza informatii specifice doar acelei subclase de obiecte.

Sa consideram o ierarhie care imparte studentii dup a in caministi si necaministi (fig. 2.7.).
In acest caz atributul NUME trebuie eliminat de la entitatea NECAMINIST deoarece el
este prezent deja la tata.

Fig. 2.8. Atributele entitatilor unei ierarhii

Rezulta urmatoarele reguli:
1. Tatal și fii unei ierarhii au acelasi identificator .
2. Descriptorii care apar și la tata și la fii se elim ina de la fii.
3. Descriptorii care apar la toti fii unei ierarhii de generalizare și nu apar la tata se
muta la tata.

c. Identificarea asocierilor

In aceasta etapa se trateaza informatiile care nu a u fost clasificate ca entitati sau atribute
ci reprezinta interdependente intre clase de obiect e. Ele sunt modelate ca asocieri intre
entitati. Pentru fiecare asociere se specifica grad ul, conectivitatea, obligativitatea si daca
este cazul si atributele asocierii precum si roluri le ramurilor sale. STUDENT
CAMINIST Rezidenta Matricola Nume
Matricola
Camin Camera NECAMINIST
Matricola Adresa

Florin Rădulescu – Baze de date Capitolul 2 – Modelarea da telor

16
Ca și in cazul clasificarii in entitati și atribute , existe citeva reguli de urmat in operatia de
definire a asocierilor:

Eliminarea asocierilor redundante . In cazul in care o asociere poate fi dedusa din a lte
asocieri deja catalogate, aceasta se elimina. De re tinut ca intre doua entitati pot sa existe
oricite asocieri și ele nu sunt considerate redunda nte atit timp cit au semnificatie diferita.
Un caz des intilnit de redundanta este cel al compu nerii (tranzititatii) asocierilor.
Prezentam un exemplu:

Urmeaza_profilul

Inscris_la

Are_profilul

Fig. 2.9. Asocieri redundante

In acest exemplu, asocierea INSCRIS_LA modeleaza ap artenenta fiecarui student la o
facultate a unui institut de invatamint superior. F iecare facultate are un profil unic descris
de asocierea ARE_PROFILUL. Ambele asocieri sunt mul ti-unu in sensul
STUDENT /barb2rightFACULTATE /barb2rightPROFIL. Deoarece asocierile multi-unu (ca și cele u nu-
unu) sunt din punct de vedere matematic functii, di n compunerea lor putem afla profilul
la care este inscris fiecare student. Rezulta ca as ocierea URMEAZA_PROFILUL care are
chiar aceasta semnificatie este redundanta și trebu ie eliminata.

Asocieri de grad mai mare ca 2 . Asocierile ternare (sau de grad mai mare ca trei) se
folosesc doar atunci cand sunt strict necesare. Est e de multe ori posibil ca o aceeasi
informatie sa fie modelata ca o asociere ternara sa u ca un ansamblu de asocieri binare si
unare. In cazul acesta, este de preferat ca sa se o pteze pentru a doua varianta. Doar cand
asocierile binare nu pot modela intreaga semnificat ie dorita se va opta pentru asocieri de
grad mai mare ca doi. Aceasta cerinta deriva din fa ptul ca la trecerea in modelul relational
asocierile de grad superior devin scheme de relatii de sine statatoare, marind numarul de
tabele din baza de date pe cand cele de grad unu și doi (cu exceptia celor multi-multi) nu
au acest efect.

d. Integrarea vederilor.

In cazul proiectarii bazelor de date complexe, acti vitatea se desfasoara uneori de catre
mai multe colective simultan, fiecare modeland o po rtiune distincta a bazei de date.
Deoarece in final trebuie sa se obtina o singura di agrama a bazei de date, dupa terminatea
modelarii pe portiuni diagramele rezultate sunt int egrate eliminandu-se redundantele si
inconsistentele.
FACULTATE STUDENT
PROFIL