2.

Proiectarea bazelor de date

2.1 PROIECTAREA BD – SCHIMBAREA DE PARADIGMĂ

Structura unei BD (entităţile, atributele, relaţiile) este determinată în timpul proiectării

BD. Abordarea proiectării unei BD este diferită de cea a sistemelor pe bază de fişiere, unde totul
era dictat de nevoile aplicative ale departamentelor individuale. În cazul BD trebuie de
considerat întâi datele apoi aplicaţiile. Această schimbare a modului de tratare se numeşte
schimbare de paradigmă.
Cauza principală a eşecurilor sistemelor informaţionale este lipsa aplicării unei
metodologii de proiectare a BD în mod structurat. Astfel rezultă BD ineficiente pentru cerinţele
aplicaţiilor, documentaţia este limitată, întreţinerea dificilă.

2.1.1 Poziţiile persoanelor din mediul BD

În acest paragraf se examinează a 5-a componentă a mediului SGBD, anume persoanele.

Se pot identifica patru tipuri distincte de persoane implicate în mediul SGBD:
- administratorii de date şi de BD;
- proiectanţii de BD;
- programatorii de aplicaţii;
- utilizatorii finali.

Administratorii de date şi de BD
BD şi SGBD sunt resurse comune care trebuie gestionate ca orice resursă.
Sarcinile administratorului de date (DA = data administrator):
- responsabil cu gestionarea resurselor de date: planificarea, elaborarea şi
întreţinerea strategiilor şi procedurilor bazei de date
- responsabil cu proiectarea conceptuală/logică a BD
- consultarea şi îndrumarea managerilor superiori cu privire la direcţia de
dezvoltare a BD, a.î BD să sprijine obiectivele generale ale organizaţiei.
Administratorul de baze de date (DBA – data base administrator) este responsabil cu
realizarea fizică a BD, având următoarele sarcini:
- proiectarea şi implementarea BD,
- securitatea şi controlul integrităţii BD,
- întreţinerea sistemului operaţional,
- asigurarea de performanţe satisfăcătoare pentru aplicaţii şi utilizatori;
Rolul DBA este mai tehnic şi necesită cunoaşterea în detaliu a SGBD şi a mediului acestuia.

Proiectanţii de BD
Există proiectanţi de BD logice şi proiectanţi de BD fizice.

1
Proiectanţii de BD logice: “ce anume?”
- se ocupă cu identificarea datelor (entităţi şi atribute) şi relaţiilor dintre acestea, şi
de constrângerile asupra celor care vor fi stocate în BD;
- trebuie să cunoască foarte bine datele organizaţiei şi a regulilor de operare ale
organizaţiei;
- trebuie să implice toţi posibilii utilizatori ai BD în modelul creat.

Etape de proiectare a BD logice:

a) proiectarea conceptuală a BD, independent de detaliile de implementare (de ex. SGBD
utilizat, programele de aplicaţie, limbajele de programare etc.)
b) proiectarea logică a BD, care se bazează pe un anumit model, de ex. relaţional, ierarhic,
în reţea, orientat pe obiecte.

Proiectanţii de BD fizice (“Cum anume?”) preia modelul logic şi stabileşte realizarea fizică:
- transpunerea modelului logic de date într-un set de tabele şi constrângeri privind
integritatea;
- selectarea de structuri de stocare şi metode de acces specifice, a.î. să se obţină
performanţe bune ale datelor in activităţile legate de BD;
- măsuri referitoare la securitatea datelor.
Proiectarea fizică a unei BD trebuie să ţină cont de SGBDul avut în vedere; proiectantul trebuie
să cunoască funcţionalitatea acestui SGBD şi avantajele şi dezavantajele fiecărei variante de
implementare a BD. Strategia de stocare aleasă trebuie să ţină cont de modul de utilizare.

Programatorii de aplicaţii
Odată realizată BD trebuie implementate programele de aplicaţie ce conferă
funcţionalitatea cerută de utilizatorii finali. Aceasta este sarcina programatorilor de aplicaţii.
Fiecare program conţine instrucţiuni care îi cere SGBD să efectueze o operaţie oarecare în BD
(extragere, inserare, reactualizare, ştergere de date). Programele pot fi scrise într-un limbaj de
generaţia a treia sau a patra.

Utilizatorii finali
Sunt clienţii pentru care a fost proiectată, implementată şi este întreţinută BD, pentru a le
satisface necesităţile informaţionale.
Utilizatorii simpli nu sunt conştienţi de SGBD. Accesează BD prin programe de aplicaţie
speciale, simplificatoare. Ei folosesc comenzi simple, opţiuni din meniu. Utilizatorul simplu nu
ştie nimic despre BD sau SGBD (de ex. vânzătorul care citeşte codul de bare pentru a afla preţul
unui produs. Există totuşi un program care citeşte codul de bare, caută preţul articolului respectiv
în BD, modifică câmpul cu stocul de articole, afişează preţul la casă).
Utilizatorii sofisticaţi sunt familiarizaţi cu structura BD şi facilităţile SGBD. Pot utiliza un limbaj
de interogare de nivel înalt (SQL). Pot scrie programe de aplicaţie pentru uz personal.

2
2.2. O METODOLOGIE CLASICĂ DE DEZVOLTARE A APLICAŢIILOR

Până acum am punctat importanţa datelor în sistemul informaţional al organizaţiilor,

nivelurile la care se poate aborda structura şi conţinutul unei baze de date, precum şi locul
"stratului" date în aplicaţiile informatice actuale. În acest capitol vom încerca să încadrăm
activitatea (activităţile) de proiectare a bazei de date în demersul mai larg al dezvoltării de
aplicaţii.
De la bun început trebuie precizat că subiectul paragrafului de faţă constituie obiect de
studiu pentru cel puţin două domenii ale informaţiei aplicate în organizaţii, sau, mai bine spus,
ale sistemelor informaţionale în organizaţii. Mai întâi, este vorba de ceea ce în literatura anglo-
saxona se numeşte software engineering, în franceză genie logiciel, iar la noi dezvoltare de
aplicații software. Este un domeniu conturat încă din anii '60 şi aflat de atunci, cel puţin după
spusele marilor specialişti, într-o permanentă criză, ce nu dă semne de epuizare.
Al doilea domeniu este mai larg şi ţinteşte mult mai mult decât realizarea de aplicaţii,
deşi aceasta reprezintă totuşi un obiectiv central. Este vorba de analiza şi proiectarea sistemelor
informaţionale. Analiza şi proiectarea se ocupă, printre altele, şi cu investigarea tuturor
proceselor, operaţiunilor şi tranzacţiilor dintr-o firmă sau instituţie, cerinţelor utilizatorilor şi
perspectivelor organizaţionale, astfel încât toate aceste aspecte să fie luate în calcul în realizarea
unui sistem informaţional coerent, aliniat misiunii, obiectivelor şi politicilor firmei. Cu alte
cuvinte, analiza şi proiectarea pornesc mai din amonte, de la utilizatori, procese, tranzacţii
economice, încercând să formalizeze/modeleze realitatea sub forma unei largi game de diagrame,
scheme, specificaţii pe care le vor înainta realizatorilor modulelor de interfaţă, prelucrări şi date.
Una dintre cele mai cunoscute scheme de realizare (dezvoltare) a aplicaţiilor de lucru cu
baze de date sau, altfel spus, schema de principiu a ciclului de viaţă al aplicaţiilor cu BD este cea
rezentată în figura 2.1.
Amploarea activităţilor din ciclul de viaţă a unei BD depinde de anvergura aplicaţiei.
Când sistemul dezvoltat vizează un numar redus de utilizatori şi se referă la un ansamblu
de funcţii nu din cale-afară de complex, multe etape sunt sărite sau parcurse sumar.

Planificarea bazei de date

Planificarea BD presupune eşalonarea paşi1or ciclului de viată pentru atingerea unui

maximum de eficacitate. Ca şi în cazul planificării software-ului, planificarea BD presupune
identificarea şi evaluarea activităţilor ce trebuie derulate (întreprinse), resurselor necesare
derulării activităţilor, fondului de timp, specialiştilor şi banilor disponibili. Planificarea BD
trebuie integrată în strategia de ansamblu a firmei, unul dintre obiectivele esenţiale fiind
catalizarea activităţilor, politicilor şi strategiei unităţii.

3
 Planificarea BD

Definirea sistemului

Colectarea şi analiza cerinţelor

Proiectarea BD
Proiectarea conceptuală
Selectarea Proiectarea
SGBD Proiectarea logică aplicaţiei

Proiectarea fizică

Prototipizare Implementare

Încărcarea şi
conversia datelor

Testare

Întreţinere operaţională

Fig. 2.1 Ciclul de viaţă a aplicaţiilor ce utilizează baze de date

Definirea sistemului

Definirea sistemului presupune specificarea domeniului şi graniţelor aplicaţiei ce

lucrează cu baza de date, utilizatorilor, aplicabilităţii sale, precum şi a celorlalte componente ale
sistemului informaţional la care se va conecta noul subsistem.

4
Colectarea şi analiza cerinţelor

Aceasta etapă implică adunarea şi analiza cerinţelor aplicaţiilor din partea utilizatorilor.
Cerinţa reprezintă o opţiune, un element ce trebuie inclus, tratat în noul sistem. Proiectarea BD
se bazează pe informaţii despre organizaţii, informaţii ce trebuie preluate şi gestionate de bază.
Acestea pot fi culese în diferite moduri :

• intervievarea personalului din întreprindere, cu precădere a celor mai apropiaţi, prin

specificul activităţii lor, de profilul aplicaţiei, avându-se în vedere acordarea unei atenţii
mărite experţilor din compartimentele funcţionale considerate;
• observarea modului de derulare a operaţiilor în cadrul firmei ;
• examinarea documentelor, în principal a celor purtătoare de informaţii (primare,
rapoarte) ;
• folosirea chestionarelor pentru preluarea informaţiilor de la un mare număr de
utilizatori;
• utilizarea experienţei acumulate la proiectarea unor sisteme similare.

Informaţia culeasă trebuie să includă: principalele domenii (zone) şi grupuri de

utilizatori; documentaţia utilizată sau generată de şi despre aceste domenii/grupuri de utilizatori;
detaliile tranzacţiilor reclamate de fiecare domeniu/grup; o listă de cerinţe, pe priorităţi a fiecărui
domeniu/grup.
Rezultatul acestei activităţi îl reprezintă specificaţiile cerinţelor organizaţionale,
prezentate, de obicei, sub forma unui set de documente în care sunt descrise, din diferite
unghiuri, operaţiile întreprinderii. De obicei, cerinţele specificate se prezintă într-o formă puţin
structurată şi necesită transformarea utilizând tehnici consacrate, cum ar fi cele de tip SAD -
Structured Analisys and Design (analiză şi proiectare structurată), DFD - Data Flow Diagrams
(diagrame ale fluxurilor de date), diagrame HIPO - Hierarchical Input Process Output (ierarhice -
intrări-prelucrări-ieşiri) etc.

Proiectarea bazei de date

Aceasta include proiectarea logică şi fizică a BD. În urma acestei etape va fi elaborat
modelul BD care va constitui suportul obiectivelor şi operaţiunilor organizaţiei. Principalele
obiective ale proiectării BD sunt:

• reprezentarea datelor şi a relaţiilor dintre date, formulare pe diferitele zone ale aplicaţiei
şi ale grupurilor de utilizatori ;
• furnizarea unui model al datelor care să permită orice tranzacţie autorizată asupra
acestora ;

5
 • construirea unui proiect care va atinge cerinţele de performanţă ale sistemului, cum ar
fi: securitatea, timpul de răspuns etc.

Deseori însă, realizarea unui obiectiv se face în detrimentul altuia. Spre exemplu, un nivel
ridicat de securitate atrage după sine scăderea vitezei de răspuns.
Există două abordări majore ale proiectării BD. Abordarea bottom-up porneşte de la
nivelul elementar, cel al atributelor, care sunt grupate în clase de entitati şi asociaţii.
Normalizarea este un exemplu tipic de demers bottom-up, care dă rezultate bune atunci când
numărul atributelor nu este prea mare.
Când numărul de atribute este ridicat, mai nimerită este abordarea top-down, care
dezvoltă mai întâi un model sintetic, simplificat al datelor. Cele câteva entităţi sunt descompuse
ulterior în mai multe etape, până la identificarea atributelor şi entităţilor elementare. Modelarea
folosind diagrame E-R are la bază abordarea top-down.
Există şi alte abordări ale proiectării BD; spre exemplu, inside-out (de la interior către
exterior) seamănă cu bottom-up, dar diferă prin faptul că mai întâi se stabileşte un set de
concepte majore şi apoi analiza se lărgeşte prin includerea în model şi a altor concepte care se
afla în relatie cu cele majore. Strategia mixtă utilizează deopotrivă, pentru diferitele părţi ale
modelului, şi bottom-up, şi top-down, combinând rezultatele.
După cea mai mare parte a autorilor, proiectarea bazelor de date este de două tipuri,
logică şi fizică, în timp ce după alţii există trei tipuri: conceptuală, logică, fizică.

Selectarea sistemului de gestiune a bazei de date

Considerată un pas opţional, selectarea SGBD presupune alegerea celui mai adecvat
SGBD pentru realizarea şi exploatarea aplicaţiei. Nu toate SGBD-urile satisfac cerinţele
aplicaţiei, iar, pe de altă parte, cele mai performante sunt şi cele mai scumpe. Cerinţele de
funcţionalitate trebuie coroborate cu resursele disponibile, în vederea identificării celui mai
adecvat SGBD comercial pentru realizarea şi exploatarea aplicaţiei.

Proiectarea aplicaţiei

Proiectarea aplicaţiei se referă la conceperea secvenţelor de cod (instrucţiuni în limbaje

de programare) ce vor lucra cu baza. Din figura 2.1 se observă că proiectarea BD şi proiectarea
aplicaţiei sunt activităţi distincte, paralele ale ciclului de viaţă al aplicaţiilor cu BD. În cea mai
mare parte a cazurilor, proiectarea aplicaţiei nu poate fi finalizată înainte de proiectarea bazei. Pe
de altă parte, informaţiile proiectării vor fi transmise proiectării BD.
În această etapă trebuie verificat dacă toate funcţiile specificate în cerinţele utilizatorului
se regăsesc în proiectul aplicaţiei. Proiectarea aplicaţiei include şi activitatea de proiectare a

6
tranzacţiilor. De asemenea, tot acum se elaborează şi modelul interfeţei cu utilizatorul a
aplicaţiei.

Prototipizarea

Deşi opţională, prototipizarea se poate dovedi deosebit de utilă prin construirea unui
model de lucru iniţial simplificat, model ce permite dezvoltatorilor şi utilizatorilor să testeze şi să
amelioreze incremental noua aplicaţie. Un mare avantaj al prototipizarii este gradul mult mai
mare de acceptare a noului sistem la final, acesta fiind dezvoltat împreună cu utilizatorii ce pot
să-şi exprime pe parcurs doleanţele. Etapele prototipizarii sunt descrise în figura 2.2.

Dezvoltarea Repetare de Abandonarea

modelului de lucru câte ori este aplicaţiei
necesar

Construirea Implementarea
prototipului aplicaţiei
Decizie

Testarea şi utilizarea Re-dezvoltarea

prototipului aplicaţiei

Revizuirea Dezvoltarea unui nou

prototipului prototip

Fig. 2.2 Schema de principiu a prototipizării

Implementarea

Implementarea presupune crearea definiţiilor BD la nivelurile conceptual, extern, intern,

precum şi punerea în lucru a programelor (aplicaţiei), fiind realizată utilizând limbajul de
definire a datelor (DDL) pus la dispozitie de SGBD-ul selectat. Implementarea aplicaţiei se
realizează într-un mediu de programare utilizand un limbaj de tip 3GL sau 4GL.

Conversia şi încărcarea datelor

Acest pas este necesar atunci când sistemul (aplicaţia) dezvoltat înlocuieşte un altul.
Datele trebuie transferate din vechea aplicaţie în cea nouă, operaţie ce implică de multe ori
schimbarea structurii fişierelor, a formatului, logic şi fizic, al datelor, în concordanţă cu cerinţele

7
noii aplicaţii, dar şi ale noului SGBD. Uneori sunt necesare (şi posibile) şi conversii ale unor
programe din vechiul în noul sistem. Majoritatea SGBD-urilor actuale au module de import-
export din/în alte SGBD-uri. Conversia aplicaţiilor este, în general, mult mai complexă atunci
când se schimbă limbajul/mediul de programare.

Testarea

Testarea este operaţiunea sistematică de verificare a funcţionalităţii sistemului, a gradului

de adecvare la cerinţele utilizatorilor. Prin testare, aplicaţia este lansată în execuţie, urmărindu-se
depistarea eventualelor erori şi ameliorarea unor parametri precum viteza, securitatea etc.
Urmând o metodologie riguroasă, măsurătorile din cadrul testării dau posibilitatea evaluării
calităţii şi fiabilităţii software-ului.
Este de preferat ca utilizatorii aplicaţiei să fie pe deplin implicaţi în procesul testării, iar
aplicaţia testată să fie instalată pe un alt sistem decât cel pe care a fost concepută; în orice caz,
trebuie avut în vedere şi un mecanism de recuperare a datelor corupte în caz de avarie.
Există mai multe strategii de testare a corectitudinii şi funcţionalităţii unei ap1icaţii de
lucru cu BD ce pot fi aplicate individual sau combinate în cadrul aceluiaşi sistem:

• top-down;
• bottom-up;
• fire de execuţie ;
• test de stres.

Testarea top-down începe de la nivelul superior al funcţiilor majore ale aplicaţiei. Este
utilă în verificarea arhitecturii sistemului, reproiectările majore fiind semnalate din primele
momente ale testării.
Testarea bottom-up începe cu modulele elementare şi continuă pe verticală cu modulele
compozite până la nivelul general al aplicaţiei.
Testarea firelor de execuţie este foarte importantă în sistemele de prelucrare în timp real,
în care sunt rulate simultan o serie de procese ce cooperează. Acest tip de testare este mult mai
complex, fiind legat de detaliile tehnice ale sistemului de operare. Fiecarui proces i se alocă un
fir de execuţie (thread) care este urmărit de la declanşarea sa, acordându-se o mare importanţă
punctelor de întâlnire cu celelalte fire executate pe sistem.
Testul de stres presupune suprasolicitarea bazei şi aplicaţiilor. Astfel, BD se încarcă
automat cu un număr extrem de mare de înregistrări, iar la aplicaţie se conectează cât mai mulţi
utilizatori. Astfel se depistează până la ce limite rezistă aplicaţia.

8
Întreţinerea operaţională

Această activitate se derulează pe toată durata de utilizare a aplicaţiei. În afară de

monitorizarea BD, a programelor, de "curăţarea" periodica şi repararea eventualelor erori
hard/soft, tot în această activitate sunt încorporate operaţiunile de actualizare a datelor şi
programelor (ca urmare a unor noi oportunităţi tehnologice), modificarea unor parametri
(procente TVA, impozite etc.). Monitorizarea performanţei sistemului se realizează prin
raportarea la un nivel prestabilit de acceptare. Dacă este cazul, o situare a performanţei generale
sub acest punct critic poate antrena reorganizarea BD. Altminteri, chiar şi în cazul funcţionării în
parametri normali, BD trebuie optimizată, având în vedere şi facilităţile oferite de SGBD.
Întreţinerea şi actualizarea aplicaţiei sunt necesare în mai mare sau mai mică măsură.
Spre exemplu, într-un mediu economic şi legislativ dinamic, cum este cel din ţara noastră,
deseori este necesară modificarea unor părţi importante ale aplicaţiei. Uneori, modificarea
presupune reluarea unora sau tuturor paşilor din ciclul de viaţă al aplicaţiei de lucru cu BD.

2.2 PRIVIRE DE ANSAMBLU ASUPRA PROIECTĂRII BAZELOR DE DATE

Deși au fost publicate destule cărți dedicate proiectării bazelor de date, subiectul continuă
să fie departe de epuizare. Chiar dacă unii autori s-au străduit să aducă rigurozitate, uneori cu
prețul unei anume rigidități, proiectarea bazelor de date rămâne preponderent o artă și mai puțin
o știință. Problema proiectarii unei baze de date ține de elaborarea unei structuri logice și a alteia
fizice în vederea întâmpinării nevoilor informaționale ale utilizatorilor într-o organizație, pentru
un set definit de aplicaţii.
Există mai multe curente de idei în ceea ce privește proiectarea bazelor de date. Unul
dintre acestea împarte procesul de proiectare în două direcții: modelarea logică a datelor și
proiectarea bazelor de date relaționale, definind modelarea logică a datelor ca procedură pentru
reprezentarea cerințelor informaționale într-un format corect, consistent și stabil, iar proiectarea
BD relaționale drept procedură de transformare a modelului logic al datelor într-o schemă
relațională stabilă. Aici apare o inadvertență, considerându-se că o schemă relațională alcătuită
din tabele și restricțiile la care sunt supuse datele din tabele nu ar corespunde nivelului logic al
bazei de date, ci nivelului fizic. În această abordare, metodologia de modelare logica a datelor
(MLD) se deruleaza în 12 paşi:
1. identificarea entităților majore ;
2. determinarea relațiilor dintre entități;
3. determinarea cheilor primare şi alternative;
4. determinarea cheilor străine;
5. determinarea celor mai importante reguli organizaționale (key business rules) ;
6. adăugarea celorlalte atribute (atributele non-cheie) ;
7. validarea perspectivelor utilizatorului folosind normalizarea ;
8. determinarea domeniilor (restricțiilor asupra valorilor autorizate ale atributelor) ;

9
 9. determinarea operațiunilor declanşatoare (regulile care guvernează efectele
modificărilor asupra atributelor şi entităților) ;
10. combinarea perspectivelor utilizatorului;
11. integrarea cu modelele de date existente ;
12. analiza stabilității şi dezvoltărilor ulterioare.

Este evident că, deşi se separă artificial proiectarea logică a bazei de date de proiectarea
bazei de date relaționale, o parte dintre paşii modelării logice sunt raportați explicit la modelul
relațional. Perspectiva poate fi explicată prin faptul că, la nivelul anilor ‘80, modelul suveran în
materie de gestiune a bazelor de date era cel relațional (suveranitate manifestată din plin şi
astăzi), iar SGBD-urile ce puteau exploata baze de date obiectuale erau ca şi inexistente.
Cea de a doua direcție, proiectare a bazei de date relaționale (PBDR), care continuă
operațiunile derulate în MLD, presupune următorii pași:

1. identificarea tabelelor ;
2. identificarea atributelor;
3. adaptarea structurii datelor la specificul SGBD-ului folosit ;
4. inventarierea regulilor organizaționale privind entitățile;
5. inventarierea regulilor organizaționale privind relațiile (asociațiile) dintre entități ;
6. inventarierea regulilor adiționale despre atribute ;
7. optimizarea structurii în vederea unui mecanism de acces cât mai eficient ;
8. definirea secvenţelor de "înmănunchiere" (clustering);
9. definirea cheilor pentru calcularea adreselor logice ale înregistrărilor în tabele (hash
keys) ;
10. adăugarea indexurilor;
11. adăugarea de date redundante;
12. redefinirea coloanelor;
13. redefinirea tabelelor.

Literatura de specialitate și practica se raportează însă preponderent la doar două

componente majore ale proiectarii bazelor de date: proiectarea logica și proiectarea fizică. Din
acest punct de vedere, cele 12 etape din MLD și primele 6 din așa-numita PBDR ar corespunde,
în linii mari, proiectării logice a bazei, în timp ce etapele următoare (7-13) din PBDR -
proiectării fizice.
O altă abordare, structurează ciclul de viață al bazelor de date pe următoarele etape:

1. analiza cerinţelor;
2. proiectarea logică, ce se materializează în schema globală ce conține datele și relațiile
dintre ele, fiind derulată astfel :
a) modelarea E-R;

10
 b) integrarea perspectivelor utilizator;
c) conversia diagramelor E-R în tabele;
d) normalizarea tabelelor ;
3. proiectarea fizică: selectarea indexurilor, metodelor de acces, cluster-elor de date; tot
aici, se include și denormalizarea;
4. distribuirea datelor, materializată în schema de fragmentare și schema de alocare a
datelor ;
5. implementarea, monitorizarea și modificarea ulterioară a bazei de date. Și aici apar
dubii legate de modul de derulare a normalizării (2.d), o dată ce prin conversia
diagramelor E-R se obțin deja tabelele relaționale (2.c).

Ambele abordări sunt legate îndeosebi de paradigma relațională folosind în primele etape
modelul E-R, mai apropiat de lumea reală.
Mai nou, proiectarea bazelor de date este privită pornind de la cele trei modele în vogă
astăzi: relațional, obiectual şi relațional-obiectual. Din această perspectivă, procesul proiectării
bazelor de date este prin excelență unul iterativ, incremental, într-o măsura cu atât mai mare cu
cât ne apropiem de obiectual. Fiecare iterație se materializează într-o formă a schemei bazei,
pornindu-se de la modelare, apoi trecându-se de la proiectare la construcție (implementare). Cu
toate acestea, activitățile principale ale ciclului de viață al bazei de date nu diferă prea mult, cel
puțin la nivel general:

• analiza cerinţelor informaționale;

• modelarea datelor ;
• proiectarea şi optimizarea bazei de date (proiectare logică și fizică) ;
• testarea și revizuirea bazei ;
• certificarea bazei de date;
• întreținerea şi ameliorarea bazei.

Specifică acestei dezvoltări este activitatea de certificare a bazei care se constituie ca un

fel de atestat de bună funcționare acordat bazei, atestat menit a întări încrederea beneficiarilor
bazei.
În altă idee recentă se definesc trei componente ale proiectării bazelor de date:
proiectarea conceptuală, ce ține de construirea unui model informațional independent de orice
considerent privind aspectul fizic al datelor; proiectarea logică, ce constă în construirea unui
model informațional pe calapodul unui model de date consacrat (E-R, relaţional, OO, OR), dar
independent de tipul SGBD-ului ales şi de celelalte aspecte fizice ale modelului; proiectarea
fizică, ce se materializează în implementarea efectivă a bazei pe suportul de stocare, inclusiv
aspecte ce țin de asigurarea unui acces eficient şi a securității.
În acest curs, alegând varianta mai simplă, cu cele două tipuri de proiectare, logică şi
fizică, vom discuta aproape exclusiv despre proiectarea logică.

11
 2.3 CONSTRUIREA DE DIAGRAME ENTITATE-RELAŢIE

Prima etapă pentru realizarea unei baze de date constă în analiza sistemului. Se cunosc
mai multe tehnici de analiză, dar cea mai des întâlnită este tehnica entitate-relaţie.
Prin tehnica entiate-relaţie (denumită şi entitate-asociere) se construieşte o diagramă
entiate-relaţie (notată E-R) prin parcurgerea următorilor paşi:
a) identificarea entităţilor (componentelor) din sistemul proiectului;
b) identificarea asocierilor (relaţiilor) dintre entităţi şi calificarea lor;
c) identificarea atributelor corespunzătoare entităţilor;
d) stabilirea atributelor de identificare a entităţilor.

a) Identificarea entităţilor

Prin entitate se înţelege un obiect concret sau abstract reprezentat prin proprietăţile sale.
Prin convenţie, entităţile sunt substantive, se scriu cu litere mari şi se reprezintă prin
dreptunghiuri. Într-o diagramă nu pot exista două entităţi cu acelaşi nume, sau o aceeaşi entitate
cu nume diferite.
Pentru o bază de date din domeniul imobiliar, se pot pune în evidenţă următoarele
entităţi:
- DATE_PERSOANĂ – entitate care stochează date personale ale ofertantului
(vânzătorului) sau ale clientului (cumpărătorului);
- CERERI_ OFERTE – conţine ofertele sau cererile imobiliare propuse de vânzători,
respectiv cumpărători;
- DESCRIERE_IMOBIL – stochează informaţiile referitoare la imobile;
- JUDEŢE – entitate ce conţine judeţele în care sunt amplasate imobilele;
- LOCALITĂŢI - entitate ce conţine localităţile în care sunt amplasate imobilele;
- STRĂZI - entitate ce precizează străzile în care sunt amplasate imobilele;
- FACTURI – formularul necesar unei tranzacţii de cumpărare-vânzare.
Figura următoare prezintă o primă formă a diagramei entitate-asociere (E-R).

DATE_ FACTURI
PERSOANA

LOCALITATI
CERERI_ OFERTE

JUDETE

DESCRIERE_IMO
STRAZI
BIL

Fig. 2.3. Diagrama E-R pentru domeniul imobiliar (prima formă)

12
 b) Identificarea asocierilor dintre entităţi şi calificarea lor

Între majoritatea componentelor (adică a entităţilor) unui sistem economic se stabilesc

legături (asocieri).
Exemplu: Există o asociere între entităţile CERERI_OFERTE şi FACTURI deoarece facturile
reprezintă finalizarea unei cereri/oferte. Această asociere se reprezintă ca în figura de mai jos.

(1,1) (0,1)
CERERI_OFERTE sunt finalizate FACTURI

prin

Fig. 2.4. Prezentarea asocierii dintre entităţile CERERI_OFERTE şi FACTURI

Sunt necesare precizarea câtorva notaţii şi noţiuni utilizate în exemplul de mai sus:
- legăturile (asocierile) se reprezintă prin arce neorientate între entităţi;
- fiecărei legături i se acordă un nume plasat la mijlocul arcului şi simbolizat printr-un
romb (semnificaţia legăturii);
- numerele simbolizate deasupra arcelor se numesc cardinalităţi şi reprezintă tipul
legăturii;
- cardinalitatea asocierilor exprimă numărul minim şi maxim de realizări a unei entităţi
cu cealaltă entitate asociată.
Exemplu: Cardinalitatea (1,1) ataşată entităţii CERERI_OFERTA înseamnă că o factură poate fi
rezultatul tranzacţionării a minim unei cereri/oferte şi a unui număr maxim de tot o cerere/ofertă.
Cardinalitatea (0,1) ataşată entităţii FACTURI înseamnă că o cerere se poate finaliza prin maxim
o factură sau prin nici una (0 facturi) . Această cardinalitate reiese din analiză:

CERERI_OFERTE FACTURI

• 1 • F1
• 2 • F2
• 3

Fig. 2.5. Determinarea cardinalităţii asocierii dintre entităţile CERERI_OFERTE şi

FACTURI

Maximele unei cardinalităţi sunt cunoscute şi sub denumirea de grad de asociere, iar
minimele unei cardinalităţi, obligativitatea participării entităţilor la asociere.

Tipuri de asocieri (legături) între entităţi

Asocierile pot fi de mai multe feluri, iar odată cu asocierea, se impune stabilirea
calificării acesteia. Asocierea dintre entităţi se face în funcţie de
13
 i) cardinalitatea asocierii;
ii) numărul de entităţi distincte care participă la asociere.
i. După cardinalitatea asocierii
În funcţie de maxima cardinalităţii (gradul de asociere), se cunosc trei tipuri de asocieri,
care, la rândul lor, sunt de două tipuri, în funcţie de minima cardinalităţii (gradul de obligativitate
al participării la asociere):
• asocieri de tip „unu la unu”;
o asocieri parţiale de tip „unu la unu”
o asocieri totale de tip „unu la unu”
• asocieri de tip „unu la mai mulţi”
o asocieri parţiale de tip „unu la mulţi”
o asocieri totale de tip „unu la mulţi”
• asocieri de tip „mulţi la mulţi”
o asocieri parţiale de tip „mulţi la mulţi”
o asocieri totale de tip „mulţi la mulţi”.
ii. După numărul de entităţi distincte care participă la asociere:
• asocieri binare (între două entităţi distincte);
• asocieri recursive (asocieri ale entităţilor cu ele însele);
• asocieri complexe (între mai mult de două entităţi distincte).
În continuare se descriu asocierile grupate după cardinalitatea ei.

Asocieri în funcţie de cardinalitatea legăturii

1. Asocieri de tip „unu la unu” sunt asocieri în care maximele cardinalităţii au

valoarea 1.

E1 (...,1) A (...,1) E2

Fig. 2.6. Asociere de tip unu la unu

Exemplu: Asocierea din figura 2.5 este asociere de tip „1 la 1”.

2. Asocieri de tip „unu la mai mulţi” sunt asocieri în care maxima cardinalităţii
unei entităţi este unu, iar a celeilalte entităţi are valoarea „mulţi”.

(...,1) (...,n) (...,n) (...,1)

E1 A E2 E1 A E2

Fig. 2.7. Asociere de tipul unu la mai mulţi

14
Exemplu:

A B
LOCALITATI CERERI_OFERTE

• L1 • 1
• L2 • 2
• L3 • 3

(1,1) îi (0,n)
LOCALITATI CERERI_OFERTE
corespunde

Fig. 2.8. Asociere de unu la mai mulţi între entităţile LOCALITĂŢI şi CERERI_OFERTE

3. Asocieri de tipul „mulţi la mulţi” sunt asocieri în care maximele cardinalităţii au

valoarea „mulţi”.

E1 (...,n) A (...,n) E2

Fig. 2.9. Asociere de tipul mulţi la mulţi

Exemplu:

DEPOZIT PRODUS

• D1 • P1
• D2 • P2
• D3 • P3

(0,n) (0,n)
În magazie PRODUS
DEPOZIT
nează

Fig. 2.10. Asociere de tipul mulţi la mulţi între entităţile DEPOZIT

şi PRODUS

15
 Observaţie: Uneori (în cazul utilizării unor SGBD), asocierea de tip „mulţi la mulţi” se
transformă în două asocieri de tipul „unul la mulţi” fiind, de regulă, mai uşor de implementat şi
de utilizat şi anume:

(...,n) (...,n) (...,1) (...,n) (...,n) (...,1)

Din E1 A E2 în E1 A1 E’ A2 E2

a) b)
Fig. 2.11. Transformarea unei asocieri de tipul mulţi la mulţi (a)
în asocieri de tipul unu la mulţi (b)

Exemplu: În cazul exemplului de mai sus (vezi figura 2.10), transformarea asocierii „mulţi la
mulţi” în asocieri de tipul „unu la mulţi” se poate realiza prin construirea unei noi entităţi
DEPOZIT_PRODUS astfel:

DEPOZIT_
PRODUS
DEPOZIT PRODUS
(0,1) (0,n) (0,n) (0,1) • P1
asociază
• D1-P1 asociază • P2
• D1
• D1-P3 • P3
• D2
• D2-P1 • P4
• D3
• D4 • D3-P4

Fig. 2.12. Transformarea asocierii de tipul mulţi la mulţi în asocieri de tipul unu la mulţi

Asocieri parţiale şi totale

Printr-o asociere parţială se înţelege o asociere în care nu există obligativitatea

participării la această asociere a tuturor entităţilor vizate, ci numai a unora dintre ele sau a nici
uneia. Asocierea parţială se caracterizează prin faptul că minima cardinalităţii ataşată unei
entităţi este zero.
Observaţii (asupra minimei cardinalităţii)
- minima cardinalităţii este zero, are drept rezultat lipsa obligativităţii participării
partenerului la această asociere;
- minima cardinalităţii este mai mare decât zero, are drept rezultat obligativitatea
participării.

(0,…) (…,…) (…,…) (0,…)

E1 A E2 E1 A E2

a) b)
Fig. 2.13 Asocieri parţiale între entităţile E1 şi E2

16
Exemplu: Asocierea dintre entităţile CERERI_OFERTE şi FACTURI din fig. 2.5 reprezintă o
asociere parţială, deoarece participarea entităţii FACTURI nu este obligatorie, minima
caracteristicii corespunzătoare entităţii CERERI_OFERTE fiind 0.

O asociere este totală dacă toate entităţile au obligativitatea să participe la asociere, adică
minima cardinalităţii este mai mare decât zero.

(1,…) (1,…)
E1 A E2
a)

(1,…) (n,…) (n,…) (1,…)

E1 A E2 E1 A E2
b) c)

(n,…) (n,…)
E1 A E2
d)

Fig. 2.14 Asocieri totale între entităţile E1 şi E2

În continuare se dau câteva exemple de asocieri totale, respectiv parţiale.

Exemplu: Asocieri parţiale de tip unu la unu

CERERI_OFERTE FACTURI

• 1 • F1
• 2 • F2
• 3

Exemplu: Asocieri totale de tip unu la unu

CERERI_OFERTE DESCRIERE_IMOBIL

• 1 • I1
• 2 • I2
• 3 • I3

17
Exemplu: Asocieri parţiale de tip unu la mulţi

LOCALITATI CERERI_OFERTE

• L1 • 1
• L2 • 2
• L3 • 3

Exemplu: Asocieri totale de tip unu la mulţi

ELEVI
CLASE
• E1
• C1
• E2
• C2
• E3
• C3
• E4

Exemplu: Asocieri parţiale de tip mulţi la mulţi

DEPOZIT PRODUS

• D1 • P1
• D2 • P2
• D3 • P3
• D4

Exemplu: Asocieri totale de tip mulţi la mulţi

STUDENTI
CURSURI
• S1
• C1 • S2
• C2 • S3
• C3 • S4

Fig. 2.13 Asocieri după gradul şi obiectivitatea lor

18
 În exemplul bazei de date AGENTIE_IMOBILIARA, tipurile de asocieri dintre entităţi
stabilite în funcţie de modul în care se desfăşoară activitatea modelată sunt:
- JUDETE-LOCALITATI 1:n – deoarece unui judeţ îi corespund mai multe
localităţi;
- LOCALITATI-STRAZI 1:n - deoarece unei localităţi îi corespund mai multe
străzi;
- STRAZI-CERERI_OFERTE 1:n – deoarece unei străzi îi pot corespunde mai
multe oferte/cereri;
- FACTURI-CERERI_OFERTE 1:1 – deoarece fiecare factură conţine doar câte o
ofertă/cerere;
- CERERI_OFERTE-DECRIERE_IMOBIL 1:1 – fiecărei cereri i se face o singură
descriere de imobil;
- FACTURI- DATE_PERSOANA 1:1 – o factură este încheiată de o singură
persoană;
- DATE_PERSOANA -CERERI 1:n – o persoană poate lansa mai multe cereri sau
oferte de imobil.

c) Identificarea atributelor entităţilor şi a asocierilor dintre entităţi

Atributele unei entităţi reprezintă proprietăţi ale acestora. Atributele sunt substantive, iar
pentru fiecare atribut i se va preciza tipul fizic (integer, float, char, string etc.)
Exemplu: Entitatea LOCALITĂŢI are următoarele atribute: codul localităţii, notat „cod_loc”,
simbolul de identificare al judeţului „simbol_judeţ” şi denumirea localităţii „nume_loc”.

d) Stabilirea atributelor de identificare a entităţilor

Un atribut de identificare (numit cheie primară), reprezintă un atribut care se

caracterizează prin unicitatea valorii sale pentru fiecare instanţă a entităţii.
În cadrul diagramei entitate-asociere, un atribut de identificare se marchează prin
subliniere sau prin marcarea cu simbolul # plasat la sfârşitul numelui acestuia.

a E a# E
(a) (b)

Fig. 2.16. Notaţii uzuale pentru atributele de identificare

Exemplu: Ca atribut de identificare putem considera codul numeric personal „cnp” pentru
entitatea DATE_PERSOANĂ.
Pentru ca un atribut să fie atribut de identificare, acesta trebuie să satisfacă unele cerinţe:
- oferă o identificare unică în cadrul entităţii;

19
 - este uşor de utilizat:
- este scurt (de cele mai multe ori, atributul de identificare apare şi în alte entităţi, drept
cheie externă).
Pentru o entitate pot exista mai multe atribute de identificare, numite atribute (chei)
candidate. Dacă există mai mulţi candidaţi cheie se va selecta unul, preferându-se unul cu valori
mai scurte şi mai puţin volatile.

Exemplu: În urma analizării celor 4 etape necesare construirii diagramei entitate-asociere:

• identificarea entităţilor domeniului sau a sistemului economic;
• identificarea asocierilor dintre entităţi;
• identificarea atributelor aferente entităţilor şi asocierilor dintre acestea;
• stabilirea atributelor de identificare a entităţilor,
se poate prezenta forma completă a diagramei asociate domeniului ales în exemplu.

(0,n) (1,1) (0,n) (1,1)

are asociată are asociată
STRAZI LOCALITATI JUDETE

(1,1)

se regăseşte

(1,n)

(1,1)
DATE_PERSOANA
CERERI_ (1,n) conţin

OFERTE (1,1)
incheie
(1,1) (0,1)
(1,1)
finisate (0,1) FACTURI

conţin

(1,1)

DESCRIERE
_IMOBIL

Fig. 2.17. Diagrama E-R pentru domeniul imobiliar (a doua formă)

În cazul în care se doreşte o diagramă care să conţină şi atributele fiecărei entităţi însoţite
de precizarea atributelor de identificare (adică a cheilor primare), pentru a nu încărca imaginea,
diagrama proiectului se poate fragmenta pe mici domenii, după cum este cazul entităţii
OFERTE, prezentat în figura 2.18. (S-au considerat un număr relativ mic de atribute).

20
 id_co#

tipul

cnp

data_inreg

cod_loc
CERERI_OFERTE
id_strada

nr_imobil

pret_min

pret_max

tip_solutionare

Fig. 2.18. Reprezentarea atributelor aferente entităţii CERERI_OFERTE (detaliu dintr-o

diagramă E-R)

În reprezentarea atributelor aferente entităţii CERERI_OFERTE semnificaţia atributelor

este următoarea: cheia primară a entităţii „id_co” reprezintă numărul de ordine al cererii sau
ofertei de imobil lansată de o anumită pesoană, atributul „tipul” specifică dacă este vorba de o
cerere sau de o ofertă, prin „cnp” se precizează codul numeric personal al clientului,
„data_inreg” reprezintă data la care s-a înregistrat oferta/cererea, apoi uremază câteva date legate
de imobil: codul străzii „id_strada”, numărul imobilului „nr_imobil”, preţul minim, respectiv
preţul maxim al imobilului „pret_min”, „pret_max”. Ultimul atribut, „tip_solutionare” precizează
dacă cererea/oferta respectivă a fost soluţionată; pentru o cerere/oferta nou introdusă, acest
atribut se va completa cu explicaţia de ”nesoluţionat”.
Astfel, diagrama bazei de date AGENŢIE IMOBILIARĂ conţine 7 entităţi a căror
asociere a fost prezentată în figura 2.19.

21
 DATE_PERSOANA STRĂZI LOCALITATI JUDETE

cnp# id_strada# cod_loc# simbol_judet#

numele cod_loc# simbol_judet nume_judet

adresa nume_str nume_loc

_
nr_telefon

email

banca_client CERERI-OFERTE DESCRIERE_IMOB IL

nr_cont_client id_co # id_co#

tip tip_imobil

cnp etaj
FACTURI
data_inreg nr_camere
nr_factura#
tip_solutionare suprafata
id_oferta
cod_loc garaj
data_factura
id_strada centrala_termica
cnp
nr_imobil termopane
pret
pret_min
TVA
pret_max
total

Fig. 2.19. Baza de date AGENŢIE IMOBILIARĂ- entităţi şi atribute

2.3.1 Reprezentarea constrângerilor de participare în diagramele E-R

Constrângerile de participare determină dacă existenţa unei entităţi depinde de legătura
sa de altă entitate prin intermediul unei relaţii.

22
 Există două tipuri de constrângeri de participare (a unei entităţi într-o relaţie):
- participare totală sau obligatorie (reprezentată printr-o linie dublă)
- participare parţială sau opţională (reprezentată printr-o linie simplă).

Participarea unei entităţi într-o relaţie este totală, dacă existenţa unei entităţi necesită
(este condiţionată de) existenţa altei entităţi prin intermediul unei anumite relaţii. Altfel
participarea este parţială.
Exemplu. În relaţia binară FILIALA Este Alocat PERSONAL (fig. 2.20) o filială poate
exista, evident, numai dacă are alocat personal. Deci existenţa entităţii FILIALA este
condiţionată de existenţa entităţii PERSONAL. Ca urmare entitatea FILIALA va participa total
(obligatoriu) în relaţia Este Alocat, şi se va reprezenta cu linie dublă.

Conform regulilor de afaceri

Nr. Filiala Nr. Personal ale organizaţiei, pot însă
exista membri de personal
care nu sunt alocaţi unei
anumite filiale. Entitatea
PERSONAL va avea deci
1 M participare parţială
FILIALA Este Alocat PERSONAL
(opţională) în relaţia Este
Alocat, şi se va reprezenta cu
linie simplă.
Fig. 2.20. Constrângeri de participare

O reprezentare alternativă a
Nr. Filiala Nr. Personal
constrângerilor de
participare rezultă din fig.
2.21, unde pe liniile de
legătură sunt trecute
valorile minimă şi maximă
(5,N) (0,1) cu care pot participa
FILIALA Este Alocat PERSONAL
entităţile în relaţie.

Fig. 2.21 Constrângeri de participare, notaţie alternativă

În cazul exemplului, o filială poate avea minim 5 şi maxim nedefinit (N) angajaţi. Un
angajat poate să nu fie alocat unei filiale (valoare minimă 0) sau să fie alocat unei filiale, şi
numai uneia (valoare maximă 1).

23
2.3.2 Problemele modelului ER

În proiectarea unui model de date conceptual pot apărea aşa-numite capcane de

conectare, datorită interpretării eronate a sensului unei relaţii.

2.3.2.1 Capcane în evantai

Capcanele în evantai sunt acele capcane de conectare care într-un model ER reprezintă
o relaţie dintre tipuri de entităţi, dar căile dintre anumite apariţii ale entităţilor sunt ambigue.

SECŢIE
1 1 Capcanele în evantai apar când două sau mai multe
relaţii 1:M provin din aceeaşi entitate (fig. 2.22).

Din model nu rezultă la ce filială este alocat un

Este alocat Coordonează anumit membru al personalului dintr-o secţie,
ştiind că o secţie coordonează mai multe filiale.
M M

PERSONAL FILIALA

Fig. 2.22 Capcană în evantai

Examinăm modelul la nivel de apariţii individuale prin intermediul reţelei semantice (fig.
2.23).

Entităţile Relaţia Entităţile Relaţia Entităţile

PERSONAL Este alocat SECŢIE Coordonează FILIALA

r1 r4
SA1 F1
S1

r2 r5 F2
SA2

SA3 r3 S2 r6 F3

Fig. 2.23. Reţeaua semantică a modelului ER din fig. 2.22

Se poate observa capcana în evantai: Angajatul SA1 este alocat secţiei S1, dar secţia S1
coordonând filialele F1 şi F3, nu se ştie la care dintre aceste două filiale este alocat SA1.

24
 FILIALA
Capcana se rezolvă prin restructurarea modelului
M 1
ER, a.î. acesta să reprezinte corect asocierile dintre
entităţi (fig. 2.24).
Coordonează Este alocat Se observă care secţie coordonează care filiale, şi ce
personal este alocat fiecărei filiale.

1 M

SECŢIE PERSONAL

Fig. 2.24. Model ER restructurat

Reţeaua semantică a modelului restructurat (corect) este cea din fig. 2.25.

Entităţile Relaţia Entităţile Relaţia Entităţile

SECŢIE Coordonează FILIALA Este alocat PERSONAL

r4 r1
S1 F1 SA1

r5 r2
F2 SA2

S2 r6 r3 SA3
F3

Fig. 2.25. Reţeaua semantică a modelului ER din fig. 2.24.

Angajatul SA1 este alocat filialei F1, coordonată de secţia S1.

2.3.2.2 Capcane de întrerupere

Capcanele de întrerupere sunt acele capcane de conectare în care un model sugerează

existenţa unei relaţii între tipurile de entităţi, dar nu există căi între anumite apariţii ale acestor
entităţi.

25
 Capcanele de întrerupere apar când în calea prin care sunt legate entităţile intervine o
entitate cu participare parţială.

Exemplu. Din modelul din fig. 2.26 se observă următoarele:

Pe ramura din stânga:

- unei singure filiale îi sunt alocaţi mai mulţi angajaţi (relaţie 1:M)
- filiale există numai dacă are personal, fiecare membru al personalului este obligatoriu
alocat unei filiale (participări totale – linii duble de legătură).

Pe ramura din dreapta:

- Un angajat (membru al personalului) poate superviza mai multe proprietăţi, o proprietate

poate fi supravegheată de un membru al personalului (relaţie 1: M)
- Nu fiecare membru al personalului supraveghează obligatoriu proprietăţi şi nu toate
proprietăţile sunt supravegheate obligatoriu de un membru al personalului (participări
parţiale – linii simple de legătură).

PERSONAL
M 1 Din modelul din fig. 2.26 nu se poate deduce
ce proprietăţi sunt disponibile la care filiale.

Este alocat Supervizează

1 M

FILIALA Proprietate
de închiriat

Fig. 2.26 Capcană de întrerupere

Modelul ER sugerează existenţa unei relaţii între entităţile FILIALA şi

PROPRIETATE_DE_ÎNCHIRIAT, dar, aşa cum rezultă din reţeaua semantică asociată (fig.
2.27) nu există căi între anumite apariţii ale entităţilor.

26
 Entităţile
PROPRIETATE_
Entităţile Relaţia Entităţile Relaţia DE_ÎNCHIRIAT
FILIALA Este alocat PERSONAL Supervizează

r1 r4
SA1 P1
F1

F2 r2
SA2 P2

F3 r3 r5 P3
SA3

Fig. 2.27. Reţeaua semantică a modelului ER din fig. 2.26.

Lipsa căilor între anumite apariţii ale entităţilor FILIALA şi Proprietate_de_Inchiriat se

observă clar din reţeaua semantică din figura 2.27.

Nu se poate deduce la ce filială este disponibilă proprietatea P2.

Participarea parţială a entităţilor PERSONAL şi PROPRIETATE_DE_ÎNCHIRIAT în

relaţia Supravegheaza are ca efect faptul că unele proprietăţi nu pot fi asociate cu o filială prin
intermediul unui membru al personalului.

Pentru rezolvarea acestei

PERSONAL capcane de întrerupere trebuie
M 1 identificată relaţia care lipseşte.
Aceasta este relaţia Are dintre
entităţile FILIALA şi
Este alocat Supervizează
PROPRIETATE_DE_ÎNCHIRI
AT.
M Se restructurează modelul ER,
1
PROPRIETATE_
introducând relaţia nou
FILIALA Are DE_ÎNCHIRIAT identificată Are între entităţile
între care lipseau căile (fig.
2.28).

Fig. 2.28. Model ER restructurat pentru eliminarea capcanei de întrerupere.

27
 Entităţile
Entităţile Relaţia Entităţile Relaţia PROPRIETATE_
FILIALA Este alocat Supervizează DE_ÎNCHIRIAT
PERSONAL

r1 r4
F1 SA1 P1

F2 r2
SA2 P2

F3 r3 r5 P3
SA3

Relaţia Are

r1

r2

r3

Fig. 2.29. Reţeaua semantică a modelului ER restructurat din fig. 2.28.

Acum la nivelul apariţiilor individuale, adică din reţeaua semantică, se poate stabili că
proprietatea P2 este disponibilă la filiala F2 (fig. 2.29).

28