1. Introducere în BD. Tratarea datelor.

Sisteme de gestionare a bazelor

de date. Sisteme bazate pe fişiere
1.1 Introducere

Sistemele de baze de date sunt o componentă esenţială a vieţii de zi cu zi în societatea

modernă. În cursul unei zile, majoritatea persoanelor desfăşoară activităţi care implică interacţiunea
cu o bază de date: depunerea sau extragerea unor sume de bani din bancă, rezervarea biletelor de tren
sau avion, căutarea unei referinţe într-o bibliotecă computerizată, cumpărarea unor produse etc.
Bazele de date pot avea dimensiuni (număr de înregistrări) extrem de variate, de la câteva
zeci de înregistrări (de exemplu, baza de date pentru o agendă cu numere de telefon) sau pot ajunge
la zeci de milioane de înregistrări (de exemplu, baza de date de plată pentru plata taxelor şi a
impozitelor).
Utilizatorii unei baze de date au posibilitatea să efectueze mai multe categorii de operaţii asupra
datelor memorate:
• Introducerea de noi date (insert);
• Ştergerea unora din datele existente (delete);
• Actualizarea datelor memorate (update);
• Interogarea bazei de date (query) pentru a regăsi anumite informaţii, selectate după un criteriu ales.
În sensul cel mai larg, o bază de date (database) este o colecţie de date corelate din punct de
vedere logic, care reflectă un anumit aspect al lumii reale şi este destinată unui anumit grup de
utilizatori. În acest sens, bazele de date pot fi create şi menţinute manual (de exemplu, fişele de
evidenţă a cărţilor dintr-o bibliotecă, aşa cum erau folosite cu ani în urmă) sau computerizat, aşa cum
este majoritatea bazelor de date folosite în momentul de faţă. O definiţie într-un sens mai restrâns a
unei baze de date este următoarea:
O bază de date (database) este o colecţie de date creată şi menţinută computerizat, care
permite operaţii de introducere, ştergere, actualizare şi interogare a datelor.
Simple colecţii de fişe (documente pe hârtie) sau fişiere de date, care conţin înregistrări de date, dar
nu permit operaţii de interogare, nu sunt considerate baze de date. De exempu, datele memorate în
fişiere pe disc de un instrument de calcul tabelar (ca Microsoft Excel) sau documentele memorate de
un editor de text (ca Microsoft Word) nu sunt considerate baze de date.

Modelul relaţional de BD

Există trei modele uzuale de implementare de BD: ierarhic, reţea sau relaţional. Fiecare se
bazează pe conceptul de date stocate ca set sau mulţime de înregistrări. Imaginaţi-vă un set de fişe,
de exemplu. Modelele ierarhic şi reţea se bazează pe parcurgerea legăturilor dintre date pentru a
lucra cu baza de date; de regulă sunt utilizate pentru sisteme-cadru generale, vaste şi nu fac obiectul
cursului nostru.
Sistemele de gestionare a bazelor de date relaţionale (SGBDR) au cunoscut o largă
răspândire, datorită modelului simplu, relaţional de date pe care-l utilizează:
 Datele se prezintă sub forma unei colecţii (unui set) de relaţii
 Fiecare relaţie are forma unui tabel (cea mai importantă componentă a unei BD)
 Rândurile (înregistrările) tabelului reprezintă entităţi
 Coloanele (câmpurile) tabelului sunt atribute/proprietăţi ale acestor entităţi
 Fiecare tabel are un set de atribute, care împreună reprezintă o “cheie” care defineşte fiecare
entitate în mod unic.

1
 De exemplu, o societate poate avea în baza sa de date un tabel cu angajaţii săi, cu un
rând/înregistrare pentru fiecare angajat. Ce atribute ar fi de interes? Depinde, desigur, de scopul
pentru care a fost creat tabelul, şi atributele sunt stabilite la momentul configurării bazei de date. Ca
exemplu aplicaţia poate fi un ştat de plată, deci va fi nevoie, în afară de nume, cod angajat şi de
informaţii referitoare la adresă şi salariu.

1.2 Tratarea datelor prin sisteme bazate pe fişiere

Superioritatea administrării datelor dintr-o organizaţie cu ajutorul unui sistem de gestionare

de baze de date (SGBD) rezultă dintr-o scurtă comparaţie între sistemele tradiţionale de date, bazate
pe fişiere şi sistemele de gestionare a bazelor de date (SGBD).

Sistemul bazat pe fişiere este o colecţie de programe de aplicaţie care efectuează servicii
pentru utilizatorii finali, cum ar fi producerea de rapoarte. Fiecare program defineşte şi gestionează
propriile date.

Exemplu: o firmă care furnizează componente pentru diferite proiecte/clienţi.

Compartimentul magazie (al firmei) va ţine fişiere cu:
- componentele în stoc, pe fişa fiecărei componente apărând denumirea, seria, costul, nr. bucăţi
etc.
Compartimentul contabilitate (al firmei) va ţine fişiere cu:
- componentele în stoc, documentele de achiziţie, intrare, denumirea, seria, costul, nr. bucăţi
etc.
- ieşirile de componente, cu caracteristicile şi cantităţile de componente, documentaţie
însoţitoare de ieşire (inclusiv numele proiectelor/clienţilor către care se furnizează)
Compartimentul vânzări (al firmei) va ţine fişiere cu:
- numele proiectelor către care se livrează, inclusiv nume clienţi, număr contract, tipuri de
componente livrate
- cerinţele clienţilor, cu detalierea componentelor necesare, inclusiv descrierea componentelor,
gradul de urgenţă şi prioritate etc.

Rezultă următoarele limitări ale sistemelor bazate pe fişiere:

- Separarea şi izolarea datelor. Atunci când datele sunt izolate în fişiere separate, cele care ar
trebui să fie disponibile sunt mai greu de accesat. De exemplu dacă vrem să aflăm care
componente până la o anumită limită de preţ şi în ce cantitate se află în stoc pentru un anumit
proiect, va trebui sa extragem date din fişierul cu proiecte şi apoi din cel cu stocuri (fişiere
existând la compartimente diferite), va trebui să creăm un fişier temporar care să cuprindă
toate aceste date. Extragerea corectă de date este dificilă, necesitând sincronizarea prelucrării
(în compartimente diferite) a două sau mai multe fişiere.

- Dublarea datelor. Din cauza modului de abordare descentralizat, specific fiecărui

compartiment, tratarea datelor pe bază de fişiere a dus la dublarea necontrolată a datelor.
Observăm în exemplul nostru, că mai multe compartimente au introdus aceleaşi date în
fişierele lor. Dublarea datelor este de nedorit din următoarele cauze:
o Risipă: introducerea datelor de mai multe ori costă timp şi bani, ocupă spaţiu
suplimentar de stocare, deci alte costuri;
o Alterarea integrităţii datelor, prin dublare, deci datele nu mai concordă. De exemplu,
dacă intrarea unor componente cu preţ nou nu este comunicată de către

2
 compartimentul contabilitate celor de la magazie, aceleaşi componente vor apărea în
fişierele diferitelor compartimente cu preţ diferit.

- Dependenţa de date. Dacă este necesară modificarea structurii unui fişier (de ex. mărimea
unui câmp), atunci trebuie identificate toate programele care lucrează cu acest fişier, pentru a
opera modificările respective în fiecare dintre ele. Această caracteristică a sistemelor bazate
pe fişiere se numeşte dependenţă program-date.

- Incompatibilitatea fişierelor. Este posibil ca fiecare compartiment să-şi genereze fişiere în alt
limbaj de programare; structura fişierelor va fi dependentă de limbajul în care este scris
programul. De exemplu, dacă compartimentul vânzări vrea să afle detaliile legate de stocul
existent pentru o anume componentă, va încerca să acceseze fişierul corespunzător al
compartimentului magazie, plecând de la câmpul “denumire componente” existent în fişierele
ambelor compartimente; dacă fişierele sunt generate cu limbaje diferite, va trebui să intervină
un programator care să scrie un program de transformare a fişierelor într-un format comun.

- Interogarea fixă sau proliferarea programelor de aplicaţie. Tratarea datelor prin sisteme de
fişiere a reprezentat un progres semnificativ faţă de sistemele manuale. Au crescut cererile de
interogări noi sau modificate, care necesitau de fiecare dată intervenţia programatorului, care
trebuia să scrie interogările. Astfel au apărut două situaţii. Pentru a limita volumul de lucru al
programatorilor, s-a ajuns la fixarea numărului de interogări disponibile. Pentru a satisface
numărul crescând de cereri de interogări, a proliferat numărul de aplicaţii; au rezultat
programe ineficiente, scrise în grabă, cu documentaţie limitată şi dificil de întreţinut. Accesul
la fişiere este limitat la un singur utilizator o dată, deci nu exista partajarea accesului pentru
mai mulţi utilizatori din acelaşi compartiment.

Limitările tratării datelor bazată pe fişiere au două cauze:

(1) definiţia datelor este încorporată în programele de aplicaţie, în loc de a fi stocată independent;
(2) nu există control asupra accesului şi manipulării datelor dincolo de cel impus de programele
de aplicaţie.

Ca urmare a apărut o nouă tratare a datelor, prin baze de date (BD), gestionate de sisteme de
gestionare a bazelor de date (SGBD).

1.3 Tratarea datelor prin baze de date (BD)

Baza de date este o colecţie partajată de date între care există relaţii logice (şi o descriere a
acestor date), proiectată pentru a satisface necesităţile informaţionale ale unei organizaţii.

Baza de date nu mai este deţinută de un singur compartiment al unei organizaţii, ci este o
resursă comună, partajată. Datele sunt integrate, cu o dublare minimă. BD conţine datele
operaţionale ale organizaţiei şi descrierea acestora.
O bază de date este deci o colecţie autodescrisă de înregistrări integrate. Această
caracteristică BD este cunoscută şi ca independenţa program - date.

O BD relaţională conţine entităţile, atributele şi relaţiile logice dintre acestea, reprezentate

printr-o diagramă entitate – relaţie (ER). Vom reveni în detaliu asupra modelului ER de BD.

3
1.4 Sistemul de gestionare a bazei de date (SGBD)

SGBD este un sistem de programe care permite utilizatorului definirea, crearea şi întreţinerea
bazei de date şi accesul controlat la aceasta.

SGBD constă în elemente de software care interacţionează cu programele de aplicaţie ale

utilizatorului pe de o parte şi cu baza de date pe cealaltă.

Un SGBD oferă o serie de facilităţi:

- permite definirea BD printr-un limbaj de definire a datelor (DDL)
- permite inserarea, reactualizarea, ştergerea şi extragerea de date printr-un limbaj de
manipulare a datelor (DML). BD fiind un depozit unic şi central de date şi descrieri de date,
DML poate oferi o interogare generală a acestor date, numită limbaj de interogare. Un astfel
de limbaj de interogare este SQL, care elimină utilizarea unui set fix de interogări
disponibile, ca în cazul tratării datelor prin sisteme de fişiere.
- Oferă accesul controlat la BD. Astfel SGBD poate furniza:
o Un sistem de securitate, pentru a împiedica accesul utilizatorilor neautorizaţi
o Un sistem de integritate, care menţine concordanţa datelor stocate;
o Un sistem de control al utilizării simultane, care permite accesul partajat la BD;
o Un sistem de control al refacerii, care restaurează BD într-o stare precedentă
concordantă, ca urmare a unei defecţiuni hard sau soft;
o Un catalog accesibil utilizatorilor, care conţine descrieri ale datelor din BD
- Oferă generarea de vederi/views numite şi moduri de vizualizare a BD prin mecanismul de
vizualizare. Astfel se vor afişa numai acele date din BD care sunt utile utilizatorului,
eliminându-se încărcarea rezultatului unei interogări cu date existente în BD, dar care nu
interesează utilizatorul. Modurile de vizualizare oferă şi alte avantaje:
o Un anumit nivel de securitate; se exclud date care nu trebuie văzute de anumiţi
utilizatori;
o O personalizare a aspectului BD. De exemplu redenumirea câmpurilor după
preferinţele utilizatorului;
o O imagine coerentă, neschimbată a structurii BD, chiar dacă BD însăşi este
modificată; prin modul de vizualizare se va afişa în continuare structura prestabilită a
BD.

1.5 Componentele mediului SGBD

Un sistem de baze de date (Database System) este un sistem computerizat de menţinere a

evidenţei unei anumite activităţi, folosind baze de date. Componentele unui sistem de baze de date
sunt: hardware, software, utilizatori, date persistente.
Hardware. Sistemele de baze de date sunt instalate, de regulă, pe calculatoare de uz general,
de la calculatoare PC standard, până la staţii multiprocesor puternice. Bineînţeles, performanţele
generale de operare ale calculatorului (numărul şi viteza procesoarelor, dimensiunea şi viteza de
operare a memoriei principale etc.) influenţează în mod corespunzător performanţele sistemului de
baze de date. Dar, ceea ce interesează în mod deosebit în utilizarea unui calculator pentru un sistem
de baze de date, este volumul (capacitatea) memoriei secundare, utilizată pentru memorarea colecţiei
de date persistente ale bazei de date.
Dat fiind că într-un sistem de baze de date este necesar accesul rapid la oricare din
înregistrările de date, pentru memorarea acestora se folosesc discurile magnetice (hard-discuri).
Benzile magnetice (care oferă acces secvenţial la înregistrările de date) sunt utilizate numai pentru
duplicarea (back-up) şi salvarea/restaurarea datelor.

4
 Software. Între baza de date (colecţia de date memorate fizic în fişiere pe hard-discuri) şi
utilizatorii sistemului există un nivel software, numit Sistem de Gestiune a Bazei de Date (SGBD) -
(Database Management System -DBMS)

Baza de date
Utilizator Program
SGBD Date
final aplicatie

Fig. 1.1. Componente ale unui sistem de baze de date.

Sistemul de gestiune a bazei de date - SGBD - (Database Management System - DBMS)

recepţionează cererile utilizatorilor de acces la baza de date (pentru operaţii de introducere,
ştergere, modificare sau interogare), le interpretează, execută operaţiile corespunzătoare şi
returnează rezultatul către utilizatori.

Sistemul SGBD oferă utilizatorilor o viziune (vedere - view) a bazei de date la un nivel înalt
şi îi eliberează de necesitatea de a cunoaşte organizarea particulară a sistemului (driverele de disc,
structura înregistrărilor de date, etc.).

1.6 Arhitectura internă a sistemelor de baza de date

Arhitectura internă a unui sistem de baze de date propusă prin standardul ANSI/X3/SPARC
(1975) conţine trei niveluri funcţionale: nivelul extern, nivelul conceptual şi nivelul intern (fig. 1.2).
Nivelul extern este o colecţie de scheme externe, care sunt vederi ale diferitelor grupuri de utilizatori,
existând câte o vedere individuală a datelor pentru fiecare grup; nivelul conceptual conţine schema
conceptuală (logică) a bazei de date, iar nivelul intern conţine schema internă (fizică) a bazei de date.
O schemă externă (vedere utilizator) (external schema, user’s view) conţine o subschemă
conceptuală a bazei de date, mai precis descrierea datelor care sunt folosite de acel grup de
utilizatori.
Schema conceptuală a bazei de date (conceptual schema) corespunde unei reprezentări
unice (pentru toţi utilizatorii) şi abstracte a datelor, descriind ce date sunt stocate în baza de date şi
care sunt asocierile dintre acestea.
Schema internă (fizică) a bazei de date (internal schema) specifică modul de reprezentare a
datelor pe suportul fizic.
Un sistem de baze de date suportă o schemă internă, o schemă conceptuală şi mai multe
scheme externe; toate aceste scheme sunt descrieri diferite ale aceleiaşi colecţii de date, care există
doar în nivelul intern.

5
corespondenţe (mappings): între schemele externe şi schema conceptuală şi între schema conceptuală
şi schema internă.
Unele sisteme SGBD nu separă complet cele trei niveluri funcţionale ale bazelor de date,
existând posibilitatea de a specifica detalii ale schemei interne sau ale schemelor externe în cadrul
schemei conceptuale.

1.7 Avantajele oferite de sistemele de baze de date

Faţă de vechile metode de înregistrare a datelor privind diferite activităţi pe fişe (documente
scrise) sau chiar în fişiere pe disc, sistemele de baze de date oferă avantaje considerabile, ceea ce
explică extinsa utilizare a acestora. Câteva dintre avantajele oferite sunt prezentate în continuare.

• Compactitate ridicată: volumul ocupat de sistemele de baze de date este mult mai redus decât
volumul ocupat de documente scrise sau de fişiere necorelate.

• Viteză mare de regăsire şi actualizare a informaţiilor.

• Redundanţă scăzută a datelor memorate, care se obţine prin partajarea datelor între mai mulţi
utilizatori şi aplicaţii. În stocarea pe fişe sau în fişiere a datelor, fiecare aplicaţie conţinea propriile
seturi de date. În sistemele de baze de date, mai multe aplicaţii pot folosi date comune, memorate o
singură dată. De exemplu, o aplicaţie de personal şi o aplicaţie de rezultate la examene dintr-o
universitate care exploatează o singură bază de date, pot folosi aceleaşi informaţii referitoare la
structurarea facultăţilor şi a secţiilor.

• Posibilitatea de introducere a standardelor privind modul de stocare a datelor, ceea ce permite

interschimbul informaţiilor între diferite organizaţii.

6
• Menţinerea integrităţii datelor prin politica de securitate (drepturi de acces diferenţiate în funcţie
de rolul utilizatorilor), prin gestionarea tranzacţiilor şi prin refacerea datelor în caz de funcţionare
defectuoasă a diferitelor componente hardware sau software.

• Independenţa datelor faţă de suportul hardware utilizat. Sistemele de gestiune a bazelor de date
oferă o vedere (view) externă a datelor, care nu se modifică atunci când se schimbă suportul de
memorare fizic, ceea ce asigură imunitatea structurii bazei de date şi a aplicaţiilor la modificări ale
sistemului hardware utilizat.

1.8 Clasificarea sistemelor de baze de date

Se pot lua în consideraţie mai multe criterii de clasificare ale sistemelor de baze de date.
Clasificare după modelul de date. Majoritatea sistemelor de baze de date actuale sunt
realizate în modelul de date relaţional sau în modelul de date obiect. Dezvoltarea continuă a acestor
modele a condus către o nouă categorie de baze de date, numite obiect-relaţionale, care combină
caracteristicile modelului relaţional cu cele ale modelului obiect. De asemenea, mai sunt încă în
funcţiune baze de date în modele mai vechi (modelul ierarhic sau modelul reţea). Modelele de date
utilizate de sistemele SGBD vor fi prezentate în secţiunea următoare.
Clasificare după numărul de utilizatori. Majoritatea sistemelor de baze de date sunt sisteme
multiutilizator, adică permit accesul concurent (în acelaşi timp) a mai multor utilizatori la aceeaşi
bază de date. Un număr redus de sisteme de baze de date sunt de tip monoutilizator, adică suportă
accesul doar al unui singur utilizator (la un moment dat).
Clasificare după numărul de staţii pe care este stocată baza de date. Există două categorii
de sisteme de baze de date: centralizate şi distribuite.
Un sistem de baze de date centralizat (Centralized Database System) este un sistem de baze
de date în care datele şi sistemul de gestiune sunt stocate pe o singură staţie (calculator).
Un sistem centralizat poate suporta unul sau mai mulţi utilizatori, dar, în orice situaţie, datele
şi sistemul de gestiune rezidă în întregime pe o singură staţie.
Un sistem de baze de date distribuit (Distributed Database System) poate avea atât datele,
cât şi sistemul de gestiune, distribuite în mai multe staţii interconectate printr-o reţea de
comunicaţie.
Sistemele de baze de date pot fi reprezentate din punct de vedere al funcţionării lor printr-o
arhitectură de tip client-server.
Într-un sistem centralizat (fig. 1.3) există un singur server, care este chiar sistemul SGBD,
care răspunde cererilor unui singur client (în sistemele mono-utilizator, fig. 1.3, a) sau mai multor
clienţi (în sistemele multi-utilizator, fig. 1.3, b), care accesează baza de date respectivă. Clienţii sunt
programe de aplicaţii oferite de furnizorul sistemului de gestiune sau dezvoltate de programatori.
Aplicaţiile client pot fi executate pe staţii diferite, conectate printr-o reţea de comunicaţie cu
staţia pe care rulează serverul. Această arhitectură permite o prelucrare distribuită a datelor şi, mai
mult, o configurare a sistemului adaptată cerinţelor de calcul particulare. Astfel, serverul bazei de
date poate fi un sistem puternic, echipat corespunzător (cu volum mare de memorie secundară), în
timp ce fiecare client este o staţie personală, cu putere de calcul adecvată aplicaţiei executate.

7
 Sistemele de baze de date distribuite pot fi reprezentate într-un mod asemănător din
perspectiva structurării client-server (fig. 1.4).
O bază de date distribuită este o colecţie de date care aparţin din punct de vedere logic
aceluiaşi sistem, dar care pot să fie, din punct de vedere fizic, memorate în mai multe staţii de calcul
(locaţii - sites) conectate printr-o reţea de comunicaţie. Sistemul software care gestionează o astfel de
bază de date se numeşte Sistem de Gestiune a Bazei de Date Distribuite - SGBDD - (Distributed
Database Management System - DDBMS). Aplicaţiile client rulează pe alte staţii din reţea şi solicită
servicii de la sistemul de gestiune distribuit.

8
 Există numeroase avantaje ale sistemelor de baze de date distribuite (creşterea capacităţii de
stocare şi prelucrare a datelor, creşterea disponibilităţii şi a partajării datelor, etc.), dar şi o creştere
considerabilă a complexităţii acestora.
Cea mai importantă cerinţă pe care trebuie să o îndeplinească sistemele de gestiune a bazelor
de date distribuite este de a asigura administrarea transparentă a datelor. Transparenţa se referă la
capacitatea unui sistem distribuit de a ascunde detaliile de implementare, astfel încât utilizatorii să
poată accesa datele pe baza unui model de nivel înalt, fără a fi necesară cunoaşterea exactă a modului
de amplasare, replicare sau comunicare a datelor.
Sistemele de gestiune a bazelor de date distribuite comerciale nu oferă în momentul de faţă
un nivel suficient de transparenţă a localizării datelor, dar dezvoltarea continuă a acestora va putea să
asigure în viitor această cerinţă.

1.9 Modelarea datelor

Un model este o abstractizare a unui sistem, care captează cele mai importante trăsături
caracteristice ale sistemului (concepte), relevante din punct de vedere al scopului pentru care se
defineşte modelul respectiv. Tehnica de identificare a trăsăturilor caracteristice esenţiale ale unui
sistem se numeşte abstractizare.
Un model de date stabileşte regulile de organizare şi interpretare a unei colecţii de date. În
proiectarea bazelor de date se folosesc, de regulă, mai multe modele de date, care se pot clasifica în
două categorii: modele conceptuale de nivel înalt şi modele specializate.
Un model conceptual de nivel înalt al datelor conţine o descriere concisă a colecţiilor de date
care modelează activitatea dorită (numită schemă conceptuală de nivel înalt), fără să detalieze modul
de reprezentare sau de prelucrare a datelor.
Modelele specializate de date (cum sunt: modelul ierarhic, modelul reţea, modelul relaţional,
etc.) impun anumite structuri speciale de reprezentare a mulţimilor de entităţi şi a asocierilor dintre
acestea, structuri pe baza cărora sunt dezvoltate sistemele de gestiune a bazelor de date. Într-un astfel
de model de date, o bază de date este reprezentată printr-o schemă conceptuală (logică) specifică.
Trecerea de la modelul conceptual de nivel înalt la un model de date specific reprezintă etapa de
proiectare logică a bazei de date care asigură corespondenţa dintre schema conceptuală de nivel înalt
a bazei de date şi schema conceptuală specifică modelului de date respectiv.

1.9.1 Modele conceptuale de nivel înalt

Cel mai utilizat model conceptual de nivel înalt este modelul Entitate-Asociere (E-A) care
reprezintă schema conceptuală de nivel înalt a bazei de date prin mulţimi de entităţi şi asocieri dintre
acestea. Dezvoltarea acestui model, astfel încât să permită extinderea tipurilor de entităţi, este
cunosută sub numele de model Entitate-Asociere Extins (E-AE). Proiectarea modelului E-A sau al
modelului E-AE este, de regulă, una din primele etape în proiectarea bazelor de date, etapă numită
proiectarea schemei conceptuale.

1.9.1.1 Modelul Entitate-Asociere

Modelul Entitate-Asociere (Entity-Relationship Model), introdus în 1976 de P.S. Chen, este

un model conceptual de nivel înalt al unei baze de date, care defineşte mulţimile de entităţi şi
asocierile dintre ele, dar nu impune nici un mod specific de structurare şi prelucrare (gestiune) a
datelor.
Elementele esenţiale ale modelului Entitate-Asociere folosit în proiectarea bazelor de date
sunt entităţile (entities) şi asocierile dintre acestea (relationships).

9
 O entitate (entity) este „orice poate fi identificat în mod distinctiv"; o entitate se referă la un
aspect al realităţii obiective care poate fi deosebit de restul universului şi poate reprezenta un obiect
fizic, o activitate, un concept, etc. Orice entitate este descrisă prin atributele sale.
Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entităţi.
Atributele prin care este descrisă o entitate se aleg pe baza criteriului relevanţei relativ la
domeniul de interes pentru care se defineşte modelul respectiv, astfel încât să asigure diferenţierea
acelei entităţi faţă de restul universului.
Toate entităţile similare, care pot fi descrise prin aceleaşi atribute, aparţin unui acelaşi tip de
entitate (entity type), iar colecţia tuturor entităţilor de acelaşi tip dintr-o bază de date constituie o
mulţime de entităţi (entities set). În general, în modelul E-A se foloseşte aceeaşi denumire atât pentru
un tip de entitate cât şi pentru mulţimea entităţilor de acel tip.
De exemplu, tipul de entitate „angajat” (al unei instituţii) reprezintă orice persoană angajată a
instituţiei, care are o anumită funcţie şi primeşte un anumit salariu. Acest tip de entitate poate fi
descris prin mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei
(Nume,Prenume,DataNasterii,Adresa), iar altele sunt atribute legate de activitatea acesteia în
instituţia respectivă (Functie,Salariu).
Prin analogie cu modelul obiect, se poate spune că un tip de entitate corespunde unei clase, o
entitate este o instanţă a unui tip de entitate şi corespunde unui obiect, iar mulţimea entităţilor de un
tip dat corespunde mulţimii obiectelor (instanţelor) unei clase.
În proiectarea bazelor de date se consideră două categorii de entităţi: entităţi normale
(puternice, obişnuite - regular entities) şi entităţi slabe (dependente - weak entities).
Entităţile normale au o existenţă proprie în cadrul modelului, în timp ce entităţile slabe nu pot
exista decât dacă există o entitate normală (puternică) cu care sunt asociate. De exemplu, o entitate
„dependent” poate să reprezinte o persoană care depinde de un angajat al unei instituţii (adică se află
în întreţinerea acestuia). O entitate „angajat” este o entitate puternică, deoarece ea există în mod
normal în modelul activităţii instituţiei, în timp ce o entitate “dependent” este o entitate slabă: nu se
va înregistra o astfel de persoană decât dacă părintele (susţinătorul) acesteia este angajat în acea
instituţie.
În proiectarea bazelor de date se definesc asocieri între mulţimile de entităţi componente,
pentru a reprezenta anumite aspecte ale realităţii pe care baza de date o modelează.
O asociere (relationship) este o corespondenţă între entităţi din două sau mai multe mulţimi
de entităţi.
Gradul unei asocieri este dat de numărul de mulţimi de entităţi asociate. Asocierile pot fi
binare (de gradul 2, între 2 mulţimi de entităţi) sau multiple (între k mulţimi de entităţi, k > 2).
Asocierile binare sunt, la rândul lor, de trei categorii, după numărul elementelor din fiecare
dintre cele două mulţimi puse în corespondenţă de asocierea respectivă (fig. 1.5). Fiind date două
mulţimi de entităţi, E1 şi E2, se definesc următoarele categorii de asocieri binare:
• Asocierea “unul-la-unul” (one-to-one) este asocierea prin care unui element
(entitate) din mulţimea E1 îi corespunde un singur element din mulţimea E2, şi reciproc; se
notează cu 1:1.
• Asocierea „unul-la-multe” (one-to-many) este asocierea prin care unui element din
mulţimea E1 îi corespund unul sau mai multe elemente din mulţimea E2, dar unui element din
E2 îi corespunde un singur element în mulţimea E1; se notează cu 1:N.
• Asocierea „multe-la-multe” (many-to-many) este asocierea prin care unui element
din mulţimea E1 îi corespund unul sau mai multe elemente din mulţimea E2 şi reciproc; se
notează cu M:N.
Cardinalitatea (multiplicitatea) unei asocieri faţă de o mulţime de entităţi (cardinality,
multiplicity) este numărul maxim de elemente din acea mulţime care pot fi asociate cu un element
din altă mulţime a asocierii.

10
 Fig. 1.5. Categorii de asocieri între două mulţimi de entităţi: a - asociere 1:1; b - asociere 1:N; c-
asociere M:N.
De exemplu, asocierea 1:N dintre mulţimile E1 şi E2 prezintă multiplicitatea 1 faţă de
mulţimea E1 şi multiplicitatea N (se înţelege o valoare oarecare N > 1) faţă de mulţimea E2. Raportul
dintre valorile cardinalităţilor unei asocieri binare faţă de cele două mulţimi de entităţi se numeşte
raport de cardinalitate (cardinality ratio). Se poate observa că cele trei categorii de asocieri descrise
mai sus diferă între ele prin raportul de cardinalitate.
Asocierile multiple (k-are, k > 2) prezintă câte un raport de cardinalitate pentru fiecare
pereche de mulţimi de entităţi pe care le asociază.
O asociere între două sau mai multe mulţimi de entităţi este, în acelaşi timp, o asociere între
tipurile de entităţi corespunzătoare.

Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezintă modelul Entitate-

Asociere prin mulţimile de entităţi şi asocierile dintre acestea.
Există numeroase variante de notaţii pentru redarea diagramei E-A. Una dintre cele mai
folosite notaţii reprezintă un tip de entitate (precum şi mulţimea de entităţi de acel tip) printr-un
dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continuă la acesta (fig.
1.6). Pentru entităţile puternice se utilizează un dreptunghi încadrat cu o linie simplă, iar pentru
entităţile slabe se utilizează un dreptunghi încadrat cu linie dublă.

Fig. 1.6. Notaţiile diagramei Entitate-Asociere (E-A).

11
 O asociere (tip de asociere) dintre două sau mai multe tipuri de entităţi se reprezintă printr-un
romb conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) la tipurile de
entităţi asociate. O asociere poate să aibă sau nu un nume; dacă are un nume, acesta poate fi înscris în
rombul respectiv sau în vecinătatea acestuia. Categoria asocierii se notează prin înscrierea
multiplicităţii pe fiecare link care conduce la un tip de entitate. Este posibil ca o asociere să prezinte
ea însăşi atribute, şi aceste atribute se reprezintă prin elipse conectate la asocierea respectivă.

Exemplu. În continuare se exemplifică dezvoltarea modelului conceptual de nivel înalt al

unei baze de date a unei instituţii şi diagrama E-A corespunzatoare, definind câteva tipuri de entităţi
şi asocierile între acestea. Diagrama E-A a acestui mic model de bază de date este prezentată în
figura. 1.7.

Fig. 1.7. Exemplu de diagramă E-A.

Tipul de entitate „secţie” reprezintă o unitate de organizare a instituţiei şi este un tip de

entitate puternică (de sine stătătoare). Acest tip se caracterizează prin mai multe atribute, de
exemplu, un număr al secţiei, numele secţiei şi bugetul alocat. Mulţimea de entităţi care grupează
toate entităţile de acest tip se poate denumi SECTIE sau SECTII (oricare variantă poate fi folosită) şi
este caracterizată prin aceleaşi atribute care caracterizează tipul entităţii:
SECTIE(Numar,Nume,Buget)
Tipul de entitate „angajat” reprezintă o persoană angajată în instituţie şi este de asemenea un
tip de entitate puternică. Acest tip de entitate, ca şi mulţimea de entităţi care grupează toate entităţile
de acest tip, se poate defini astfel
ANGAJAT(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu)
Tipul de entitate „proiect” reprezintă o activitate a instituţiei, şi este de asemenea un tip de
entitate puternică, care poate fi caracterizat prin numele proiectului, data începerii, termen de
realizare, bugetul proiectului:

12
 PROIECT(Nume,DataInceperii,Termen,Buget)
Tipul de entitate „dependent” reprezintă o persoană care depinde de un angajat al instituţiei
(adică se află în întreţinerea acestuia). Acest tip de entitate este un tip de entitate slabă: nu se va
înregistra o astfel de persoană decât dacă întreţinătorul acesteia este angajat în acea instituţie. Acest
tip se poate defini astfel:
DEPENDENT(Nume,Prenume,DataNasterii,GradRudenie)
Asocierea SECTIE-ANGAJAT este o asociere 1:N, dacă se consideră că o secţie cuprinde
mai mulţi angajaţi, iar un angajat aparţine unei singure secţii.
Asocierea ANGAJAT-PROIECT este o asociere M:N, dacă se consideră că la fiecare proiect
lucrează mai mulţi angajaţi, şi fiecare angajat poate lucra la mai multe proiecte.
Asocierea ANGAJAT-DEPENDENT este o asociere de tipul 1:N, deoarece un angajat poate
întreţine mai multe persoane (fii, părinţi etc.), iar o persoană dependentă este în întreţinerea unui
singur susţinător.
Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel încât să reflecte cât
mai corect modul de organizare a activităţii modelate. De exemplu, asocierea ANGAJATI-
PROIECTE are raportul de cardinalitate M:N dacă în instituţia respectivă se admite ca un angajat să
lucreze la mai multe proiecte; dacă s-ar impune ca un angajat să lucreze la un singur proiect, atunci
asocierea respectivă ar avea raportul de cardinalitate N:1. În ambele situaţii se admite că la un proiect
lucrează mai mulţi angajaţi.
Sunt de remarcat câteva caracteristici generale ale modelului E-A:
a) Modul de stabilire a tipurilor de entităţi şi a asocierilor dintre acestea nu este unic,
deoarece graniţa dintre entităţi şi asocieri nu este, în general, una bine precizată. Aceeaşi
funcţionalitate se poate obţine printr-o varietate de diagrame E-A, depinzând de felul în care
proiectantul dezvoltă modelul conceptual. O asociere poate fi considerată şi ca un tip de entitate. De
exemplu, pentru baza de date a unei facultăţi (şcoli) se definesc tipurile (mulţimile) de entităţi:
STUDENTI(Nume,Prenume,Adresa,...)
DISCIPLINE(Denumire,Credite,...)
Între aceste mulţimi de entităţi se poate defini asocierea STUDENTI-DISCIPLINE, cu
raportul de cardinalitate M:N. Această asociere reprezintă (în general) studierea unor discipline de
către studenţi, cu atribute ca: Nota (examenului la disciplina respectivă), DataExamen, etc. Dar, la fel
de bine, este posibil să se definească tipul de entitate NOTE, aflat în asociere N:1 cu fiecare din
tipurile de entităţi STUDENTI şi DISCIPLINE (fig. 1.8).

Fig. 1.8. Diferite moduri de definire a tipurilor de entităţi şi a asocierilor:

a- asociere M:N între mulţimile de entităţi STUDENTI şi DISCIPLINE;
b - mulţimea de entităţi EXAMENE este asociată cu raportul de cardinalitate N:1
cu fiecare din mulţimile de entităţi STUDENTI şi DISCIPLINE.

b) În modelul E-A, tipul de entitate (şi mulţimea de entităţi corespunzătoare) semnifică un

substantiv, în timp ce o asociere semnifică un verb. Bineînţeles, nu este obligatoriu ca numele dat
unei asocieri să fie un verb (şi, de cele mai multe ori, nici nu este), dar o asociere reprezintă o
interacţiune între tipurile de entităţi (şi mulţimile de entităţi corespunzătoare), care poate fi exprimată
printr-un verb. De exemplu, în diagrama E-A din figura 1.7, asocierea SECTIE-ANGAJAT poate fi
exprimată prin verbul cuprinde, asocierea ANGAJATI-DEPENDENTI poate fi exprimată prin
verbul întreţine, asocierea ANGAJATI-PROIECTE poate fi exprimată prin verbul lucrează etc.

13
 c) Modelul E-A nu precizează modul cum sunt realizate asocierile între mulţimile de entităţi.
Acest aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date. De
exemplu, în modelele ierarhic şi reţea, asocierile sunt realizate explicit, prin pointeri de la o entitate
la entităţile asociate, în timp ce în modelul relaţional asocierea se realizează prin egalitatea valorilor
unor atribute comune ale entităţilor (chei).

1.9.1.2 Modelul Entitate-Asociere Extins

Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de

subtipuri ale unui tip de entităţi, care moştenesc atribute de la tipul de entitate pe care il extind (şi
care, în acest context, se numeşte supertip) şi au în plus atribute specifice semnificaţiei lor. Prin
definirea tipurilor şi a subtipurilor de entităţi se pot crea ierarhii de tipuri de entităţi pe mai multe
niveluri.
Modelul E-A prezentat în capitolul precedent este suficient pentru modelarea aplicaţiilor de
baze de date „tradiţionale”, adică bazele de date utilizate pentru activităţi financiare şi industriale, în
care se folosesc tipuri de date simple. Odată cu dezvoltarea sistemelor de baze de date, domeniile în
care acestea se folosesc au devenit tot mai numeroase, ca, de exemplu: telecomunicaţiile, proiectarea
tehnologică, sistemele de informaţii geografice, seviciul Web, etc. Tipurile de entităţi definite în
astfel de baze de date sunt mult mai complexe şi pentru reprezentarea lor cât mai intuitivă şi mai
compactă au fost propuse mai multe concepte noi, care au fost introduse în modelul E-A extins.
Modelul E-A extins se reprezintă printr-o diagramă E-A extinsă. Ierarhiile de tipuri se pot crea prin
specializare sau generalizare.
Specializarea (specialization) este un proces de abstractizare a datelor prin care, pornind de
la un tip de entitate dat, se definesc unul sau mai multe subtipuri, diferenţiate între ele în funcţie de
rolul specific pe care îl au în modelul de date.
De exemplu, pornind de la tipul de entitate ANGAJAT se definesc prin specializare
subtipurile SECRETARA, TEHNICIAN, INGINER, pentru a diferenţia funcţiile pe care angajaţii le
pot avea în întreprinderea respectivă (fig. 1.9). Litera “d” din marcajul de specializare a tipurilor
indică o constrângere de disjuncţie impusă specializării, care va fi descrisă mai jos.
Subtipurile de entităţi moştenesc atribute ale tipului iniţial şi fiecare dintre ele are atribute
suplimentare, specifice rolului lor. De exemplu, atributele (Nume, Prenume, DataNasterii, Adresa,
Salariu) ale tipului de entitate ANGAJAT sunt moştenite de fiecare din subtipurile acestuia. Atributul
Functie nu este moştenit, deoarece specializarea subtipurilor s-a efectuat după acest atribut. Ca
atribute specifice, subtipul SECRETARA are atributul VitezaRedactare, care este o măsură a
calificării, subtipul TEHNICIAN are atributul Calificare, care reprezintă gradul de calificare, iar
subtipul INGINER are atributul Specialitate, care este o precizare a domeniului in care lucrează
(mecanic, electric, etc.).
Generalizarea (generalization) este procesul de abstractizare invers specializării, prin care
se crează un supertip de entitate pornind de la mai multe tipuri de entităţi.
Pentru definirea unei generalizări, se identifică atributele comune ale mai multor tipuri de
entităţi şi aceste atribute vor caracteriza supertipul de entitate, iar atributele care diferă de acestea
rămân specifice fiecărui tip.
De exemplu, dacă au fost definite tipurile de entităţi: AUTOMOBIL (NrInregistrare, Marca,
VitezaMaxima, Pret, NumarPasageri) şi CAMION(NrInregistrare, Marca, VitezaMaxima, Pret,
Tonaj), se poate defini un supertip al acestor tipuri: VEHICUL (NrInregistrare, Marca,
VitezaMaxima, Pret). Acest tip va cuprinde toate atributele comune, iar tipurile iniţiale,
AUTOMOBIL şi CAMION, devin subtipuri ale tipului VEHICUL, fiecare conţinând atributele
specifice (NumarPasageri pentru tipul AUTOMOBIL şi Tonaj pentru tipul CAMION).
Rezultatul obţinut prin generalizare este, ca şi în cazul specializării, o ierarhie de tipuri de
entităţi; ceea ce diferă este modul în care se definesc nivelurile ierarhiei.

14
 Fig.1.9. Diagrama E-A extinsă cu ierarhie de tipuri de entităţi.

Moştenirea atributelor. Proprietatea principală a ierarhiilor de tipuri de entităţi create prin

specializare sau generalizare este moştenirea atributelor: atributele tipurilor de entităţi de nivel
ridicat (supertipuri) sunt moştenite de tipurile de entităţi de nivel scăzut (subtipuri).
Moştenirea dintre un subtip de entităţi şi supertipul acestuia se reprezintă în diagrama E-A
extinsă printr-o legătură (link) între subtip şi supertipul de entitate corespunzător pe care este plasat
un semicerc orientat către subtip (aşa cum se poate vedea în figura 1.9).
Este evidentă asemănarea dintre ierarhiile de tipuri de entităţi din modelul E-A extins şi
ierarhiile de clase din modelul obiect-orientat, dar modelul E-A extins este un model de date mult
mai general (de nivel inalt), care poate fi transpus în diferite modele de date specializate, inclusiv
modelul obiect-orientat. Aceste transpuneri se fac în funcţie de suportul oferit de modelul specializat
respectiv pentru reprezentarea entităţilor, asocierilor, moştenirilor, etc.

1.9.2 Modele specializate de date

1.9.2.1 Modelul de date ierarhic

În modelul ierarhic (Hierarchical Model) o bază de date se reprezintă printr-o structură

ierarhică de înregistrări de date (records) conectate prin legături (links).
Modelul de date ierarhic a fost primul model folosit pentru dezvoltarea bazelor de date. Cea
mai cunoscută realizare de SGBD ierarhic este sistemul IMS (Information Management System)
dezvoltat de firma IBM în cadrul programului de cercetări Apollo, în perioada anilor 1960.
O înregistrare de date în modelul ierarhic este o instanţă a unui tip de înregistrare (record
type) şi constă dintr-o colecţie de câmpuri (fields), fiecare câmp conţinând valoarea unui atribut. Un
tip de înregistrare corespunde unui tip de entitate, iar o înregistrare corespunde unei entităţi din
modelul E-A.
Un tip de legătură în modelul ierarhic este un tip de asociere cu raportul de cardinalitate 1:N
(de tip părinte-fiu) între două tipuri de înregistrări. Tipul de înregistrare din partea cu multiplicitatea
1 a asocierii este numit tip de înregistrare părinte, iar tipul din partea cu multiplicitatea N a asocierii
este numit tip de înregistrare fiu.
Schema conceptuală a unei baze de date în modelul ierarhic se reprezintă printr-un număr
oarecare de scheme ierarhice (fig. 1.12). O schemă ierarhică este un arbore direcţionat, reprezentat pe
15
mai multe niveluri, în care nodurile sunt tipurile de înregistrări, iar arcele sunt tipurile de legături.
Fiecare nod (cu excepţia nodului rădăcină) are o singură legătură către un nod de pe un nivel superior
(nodul părinte) şi fiecare nod (cu excepţia nodurilor frunză) are una sau mai multe legături către
noduri de pe nivelul imediat inferior (noduri fii).
Se poate stabili o corespondenţă între o schemă conceptuală ierarhică şi o diagramă E-A:
tipurile de înregistrări corespund tipurilor de entităţi, iar tipurile de legături corespund tipurilor de
asocieri. (fig. 1.12, a şi b).
În modelul ierarhic nu sunt admise decât legături de tipul părinte-fiu, care corespund
asocierilor 1:1 şi asocierilor 1:N din modelul E-A. Asocierile M:N din modelul E-A nu se pot
reprezenta în mod direct în modelul ierarhic, ci numai prin multiplicarea înregistrărilor de tip fiu,
atunci când sunt referite de mai multe înregistrări de tip părinte. Acest lucru conduce la o mare
redundanţă a datelor.
Corespunzător schemei ierarhice a unei baze de date se pot reprezenta mai mulţi arbori de
instanţiere a datelor, care sunt, de asemenea, arbori direcţionaţi (fig. 1.12, c). Fiecare arbore de
instanţiere contine ierarhii pe mai multe niveluri de înregistrări între care există legături de tipul
părinte-fiu.

Fig. 1.12. Bază de date ierarhică: a - diagrama E-A;

b - schema conceptuală a bazei de date ierarhice; c - arbori de instanţiere a datelor.

Corespunzător schemei ierarhice a unei baze de date se pot reprezenta mai mulţi arbori de
instanţiere a datelor, care sunt, de asemenea, arbori direcţionaţi (fig. 1.12, c). Fiecare arbore de
instanţiere contine ierarhii pe mai multe niveluri de înregistrări între care există legături de tipul
părinte-fiu.
Avantajele modelul ierarhic sunt simplitatea şi eficienţa de calcul, dar în momentul de faţă,
pentru realizarea bazelor de date sunt preferate modele de date mai puternice (modelul relaţional,
modelul obiect-orientat).

1.9.2.2 Modelul de date reţea

Modelul reţea (Network Model) foloseşte o structură de graf pentru definirea schemei
conceptuale a bazei de date; nodurile grafului sunt tipuri de entităţi (înregistrări - records), iar
muchiile grafului reprezintă în mod explicit asocierile (legăturile-links) dintre tipurile de entităţi.

16
 Apărut după modelul ierarhic, modelul reţea de reprezentare a bazelor de date a fost
standardizat în 1971, de o comisie DBTG (Database Task Group). Modelul reţea a avut mai multe
implementări ca sisteme de gestiune comerciale: IDS II (Honeywell), UNISYS (Burroughs), IDMS
(Computer Associates).
Deosebirea faţă de modelul ierarhic constă în aceea că în modelul reţea asocierile M:N se
reprezintă fără duplicarea înregistrărilor, fiecare înregistrare putând fi referită de mai multe
înregistrări, ceea ce elimină redundanţa.
La fel ca şi la modelul ierarhic, dezavantajul principal al modelului reţea este acela că fiecare
interogare trebuie să fie prevăzută încă din faza de proiectare, prin memorarea explicită a legăturilor
între tipurile de entităţi. În plus, complexitatea reprezentării datelor în modelul reţea este deosebit de
ridicată, iar programatorii trebuie să o cunoască pentru a putea realiza aplicaţiile necesare.
În momentul de faţă modelul de date reţea este foarte rar utilizat pentru baze de date de uz
general (care implică operaţii de interogare), dar există unele domenii în care structurarea ca graf a
datelor permite o parcurgere eficientă a acestora. De exemplu, majoritatea bazelor de date grafice
folosite în modelarea scenelor tridimensionale din realitatea virtuală sunt baze de date reţea [Ion96a].

1.9.2.3 Modelul de date relaţional

Modelul relaţional (Relational Model) se bazează pe noţiunea de relaţie (relation) din

matematică, care corespunde unei mulţimi de entităţi de acelaşi tip.
Modelul de date relaţional a fost propus de cercetătorul E.F. Codd de la compania IBM, care
a publicat în anul 1970 lucrarea "Un model Relaţional de Date pentru Bănci Mari de Date Partajate"
[Codd70]. Alte lucrări ale lui Codd, ca şi ale altor cercetători (C.J. Date, P. Chen, R. Boyce, J.D.
Ullman, R. Fagin, W.W. Armstrong, M. Stonebraker, etc.) au perfecţionat modelul de date relaţional
şi au permis dezvoltarea fără precedent a sistemelor de gestiune a bazelor de date, datorită simplităţii
şi a fundamentării matematice a modelului.
Primul Sistem de Gestiune a Bazelor de Date Relaţionale (SGBDR) a fost prototipul System
R, dezvoltat la compania IBM în anii 1970, după care numeroase companii au realizat sisteme de
gestiune relaţionale (Oracle, Microsoft, Ingres, Sybase, etc.) iar aplicaţiile de baze de date relaţionale
au căpătat o amploare deosebită.
Pe lângă avantajul unui model de date precis şi simplu, sistemele de baze de date relaţionale
mai beneficiază şi de un limbaj de programare unanim recunoscut şi acceptat, limbajul SQL
(Structured Query Language), pentru care au fost emise mai multe standarde de către ISO
(International Standardization Office). Majoritatea SGBD-urilor relaţionale actuale implementează
versiunea SQL92 (sau SQL2).

1.9.2.4 Modelul de date obiect-orientat

Modelul obiect (Object Model) este un concept unificator în ştiinţa calculatoarelor, fiind
aplicabil în programare, în proiectarea hardware-ului, a interfeţelor, a bazelor de date, etc.
Sistemele de baze de date obiect- orientate se bazează pe limbaje de programare obiect-orientate cu
capacităţi de persistenţă, în care datele sunt independente de timpul de viaţă al programelor care le
creează, prin memorare pe suport magnetic (disc).
Oricât de folositor este modelul de date relaţional pentru realizarea bazelor de date, există
unele domenii (în special acele domenii în care se manevrează tipuri de date complexe), în care
modelul relaţional s-a dovedit a fi insuficient de expresiv şi cu performanţe de execuţie reduse.
Domenii ca: proiectarea asistată de calculator, sisteme de informaţii geografice, medicină (şi altele)
au impulsionat cercetări pentru găsirea unor modele mai performante, dintre care modelul obiect-
orientat şi modelul obiect-relaţional au cunoscut şi cunosc în continuare o dezvoltare semnificativă.

17
 Caracteristicile importante ale modelului obiect (abstractizarea, moştenirea, încapsularea,
modularitatea) sunt intens dezbătute şi analizate mai ales din perspectiva proiectării şi programării
obiect-orientate.
Din perspectiva realizării bazelor de date, o altă proprietate a modelul obiect, persistenţa, este
aceea care asigură memorarea transparentă pe suport magnetic a obiectelor care alcătuiesc o bază de
date obiect-orientată.
Pentru dezvoltarea unui sistem de gestiune a bazelor de date obiect- orientate (SGBDOO) se
poate aborda una din următoarele strategii:

• Extinderea unui limbaj de programare obiect-orientat cu capacităţi de administrare a

obiectelor persistente. Sistemul GemStone este un astfel de SGBDOO, dezvoltat prin
extinderea limbajelor C++ şi Java.

• Extinderea unui limbaj de programare relaţional cu capacităţi de orientare spre obiecte. Un

astfel de limbaj este limbajul ODL (Object Query Language) (sau Object SQL), specificat
prin standardul propus de consorţiul Object Database Management Group, din care fac
parte principalii producători de sisteme de baze de date obiect-orientate. Există mai multe
astfel de sisteme, cum sunt: Ontos, Versant, O2.

• Dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou, care să asigure
crearea şi interogarea obiectelor persistente. Există şi astfel de produse, ca de exemplu
sistemul SIM (Semantic Information Manager).

Dintre avantajele cele mai importante ale sistemelor de baze de date dezvoltate în modelul
obiect se evidenţiază capacitatea acestora de a defini şi manevra tipuri de date complexe (clase), care
se pot extinde prin mecanismul de moştenire, ceea ce contribuie la creşterea performanţelor în
aplicaţiile de baze de date avansate.
Există, bineînţeles, şi dezavantaje ale sistemelor de baze de date obiect-orientate, care le fac
să aibă o utilizare limitată, mult mai redusă decât cea a sistemelor de baze de date relaţionale (sub
5% din piaţa sistemelor de baze de date). Principalul dezavantaj îl constitue complexitatea de
dezvoltare a bazei de date şi a aplicaţiilor, datorită faptului că proiectanţii şi programatorii trebuie să
prevadă în structura obiectelor toate asocierile (legăturile) necesare tuturor interogărilor. Cu cât
interogările sunt mai complexe, cu atât sunt necesare mai multe asocieri între obiecte şi deci se
complică structura acestora. La acest dezavantaj se adaugă şi altele, cum ar fi lipsa unui standard de
limbaj de interogare care să fie unanim (sau cât mai larg) acceptat.

1.9.2.5 Modelul de date obiect-relaţional

Modelul obiect-relaţional (Object-Relational Model) reprezintă extinderea modelului

relaţional cu caracteristici ale modelului obiect, extindere necesară pentru realizarea bazelor de
date care definesc şi prelucrează tipuri de date complexe.
În esenţă, modelul obiect-relaţional păstrează structurarea datelor în relaţii (reprezentate ca
tabele), dar adaugă posibilitatea definirii unor noi tipuri de date, pentru domeniile de valori ale
atributelor. Tipurile de date definite de utilizator pot fi extinse prin mecanismul de moştenire şi
pentru fiecare tip sau subtip se pot defini metode pe care le pot executa obiectele de acel tip.
În general, dezvoltarea sistemelor de gestiune a bazelor de date obiect-relaţionale (SGBDOR) se
realizează prin extinderea sistemelor relaţionale, de cele mai multe ori în mod gradat, adăugându-se
de la o versiune la alta cât mai multe caracteristici posibile ale modelului obiect şi păstrând în
continuare toate caracteristicile modelului relaţional.

18
 O astfel de abordare asigură rularea în continuare a aplicaţiilor relaţionale existente în noile
versiuni de sisteme SGBDOR, ceea ce permite producătorilor să-şi păstreze clienţii şi domeniile de
utilizare. Mai mulţi dintre principalii producători de sisteme de gestiune (Oracle, Informix şi IBM)
au extins în acest mod sistemele lor relaţionale pentru a deveni sisteme obiect-relaţionale. Este o
tendinţă firească, dat fiind că prin aceasta se păstrează toată experienţa şi rezultatele obţinute cu
sistemele relaţionale şi se pot dezvolta şi aplicaţii complexe, obiect-relaţionale.
Standardele limbajelor de programare pentru sistemele de gestiune obiect-relaţionale sunt extensii
ale standardului SQL (ca de exemplu, versiunea din anul 1999, denumită SQL3).

1.10 Avantajele şi dezavantajele SGBD

Avantaje
- Controlul redundanţei datelor; nu se elimină în întregime redundanţa, ci se controlează
volumul inerent al acesteia în BD.
- Coerenţa datelor; datorită eliminării redundanţei, orice reactualizare a unui articol (stocat o
singură dată) se face o singură dată, eliminându-se incoerenţa. Dacă articolul este stocat de
mai multe ori, SGBD garantează coerenţa tuturor exemplarelor din articolul respectiv.
- Mai multe informaţii obţinute de la aceeaşi cantitate de date; ca urmare a integrării datelor
operaţionale, două sau mai multe fişiere pot fi integrate, extrăgându-se mai multe informaţii.
- Partajarea datelor; fişierele sunt deţinute de compartimentele organizaţiei care le utilizează,
dar fiind parte din BD, ele sunt la dispoziţia tuturor utilizatorilor interesaţi.
- Integritatea crescută a datelor; se referă la validitatea şi coerenţa datelor stocate. Integritatea
este exprimată prin constrângeri, care reprezintă reguli de coerenţă pe care BD nu are voie să
le încalce.
- Securitatea crescută; se referă la protecţia BD faţă de utilizatorii neautorizaţi. Fără sisteme de
securitate, integrarea ar face datele foarte vulnerabile. Securitatea se realizează prin nume de
utilizatori plus parole. Se poate limita tipul de operaţie efectuată.
- Aplicarea standardelor; prin integrare se pot aplica standarde organizaţionale, naţionale sau
internaţionale, ca de ex. formatul datelor, convenţii referitoare la denumire, pt. a facilita
schimburi între sisteme.
- Economia de scală; în loc de bugete pentru fiecare compartiment pentru crearea unui sistem
propriu de BD bazat pe fişiere, există un buget unic combinat, care permite alocarea
fondurilor economisite pentru îmbunătăţirea sistemului.
- Echilibrul între cerinţele aflate în conflict; cerinţele posibil în conflict ale diferitelor
compartimente referitoare la utilizarea BD sunt gestionate la nivel de DBA, care va lua
deciziile ce se impun şi va acorda prioritate aplicaţiilor majore.
- Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns; limbajele de interogare şi
generatoare de rapoarte asociate SGBD oferă utilizatorilor posibilitatea unor interogări ad-
hoc, fără a apela la programator.
- Productivitatea crescută; SGBD furnizează standardele necesare aplicaţiei, economisind
timpul programatorului.
- Capacitatea de întreţinere îmbunătăţită, prin independenţa de date; într-un SGBD descrierile
datelor sunt separate de aplicaţii, aplicaţiile fiind imune la modificarea descrierii datelor; este
caracteristica de independenţă program-date, care uşurează întreţinerea aplicaţiilor din BD.
- Concurenţa/simultaneitatea îmbunătăţită; se garantează alterarea datelor în situaţia când
acelaşi fişier este utilizat simultan de mai mulţi utilizatori.
- Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere. Se minimizează pierderile
apărute ca urmare a unor defecţiuni. Nu este necesară realizarea zilnică de copii de siguranţă.

19
Dezavantaje
- Complexitatea; pt. ca un SGBD să fie funcţional, acesta va evolua într-un sistem soft extrem
de complex. Funcţionalitatea trebuie cunoscută de către toţi cei implicaţi în BD, de la DA la
utilizatorul final, pentru a o putea exploata. Dacă SGBD este greşit înţeles, BD proiectată
poate fi greşită, cu toate consecinţele acestei situaţii.
- Dimensiunea; Fiind un element soft foarte complicat, SGBD ocupă mult spaţiu pe disc şi
necesită multă memorie pentru a funcţiona eficient.
- Costul SGBD; variază în funcţie de mediu şi funcţionalitate. De la 150 USD pt. un PC cu un
utilizator, la 750.000 USD pt. un sistem mainframe cu sute de utilizatori. Se adaugă cheltuieli
periodice anuale de întreţinere.
- Costurile adiţionale pentru elemente hardware; pentru a sigura performanţele SGBD poate fi
nevoie de achiziţionarea unui calculator mai mare, chiar dedicat rulării SGBD, cu disc şi
memorie mai mari.
- Costul conversiei; la implementarea unui nou sistem SGBD şi/sau a unei noi configuraţii
hard, conversia poate costa semnificativ mai mult decât noile elemente hard. Se include
costul instruirii personalului, angajarea de personal specializat. Apare termenul de sistem
moştenit, adică un sistem mai vechi, inferior, de care organizaţia se cramponează din motive
de costuri de conversie.
- Performanţa; SGBD (spre deosebire de cel bazat pe fişiere) este general, creat pentru a
permite diverse aplicaţii; astfel unele pot funcţiona mai puţin rapid decât în cazul sistemului
bazat pe fişiere, creat pentru o anume aplicaţie.
- Impactul crescut al unei defecţiuni. Centralizarea (partajarea) resurselor creşte
vulnerabilitatea SGBD. Eşecul oricărei componente poate duce la sistarea tuturor operaţiilor.

1.11 Complexitatea datelor şi a interogărilor

M. Stonebraker a oferit o reprezentare în patru cadrane a universului bazelor de date (fig.

1.13) deosebit de simplă şi de interesantă, bazată numai pe complexitatea datelor şi a interogărilor.
Propusă în anul 1996, această clasificare nu include modelele prerelaţionale (modelul ierarhic şi
modelul reţea), considerate depăşite în această fază de dezvoltare a bazelor de date.
Pe abscisa diagramei este reprezentată capacitatea de definire a tipurilor de date complexe, iar
pe ordonată este reprezentată capacitatea de interogare a bazelor de date.
În cadranul din stânga jos sunt acele aplicaţii care prelucrează tipuri de date simple şi nu
necesită interogarea datelor. Astfel de tipuri de aplicaţii (cum sunt procesoarele de texte – Word,
Framemaker) folosesc direct sistemul de fişiere al sistemului de operare pentru memorarea datelor
persistente.

Fig. 1.13. Clasificarea sistemelor de gestiune a bazelor de date.

20
 În cadranul din stânga sus sunt sistemele de gestiune a bazelor de date relaţionale (SGBDR),
care prelucrează tipuri simple de date, dar permit interogări complexe.
În cadranul din dreapta jos sunt sistemele de gestiune a bazelor de date obiect-orientate
(SGBDOO), care prelucrează tipuri de date complexe, dar în care rezolvarea interogărilor este destul
de dificilă, dat fiind că pentru fiecare interogare trebuie să fie prevăzute legăturile necesare în
structura obiectelor.
În cadranul din dreapta sus sunt reprezentate sistemele obiect-relaţionale (SGBDOR), care
permit prelucrarea datelor complexe şi rezolvarea interogărilor complexe. Modelul obiect-relaţional
este, evident, cel mai complet, deoarece admite atât tipuri de date definite de utilizator cât şi
interogări complexe. În aceeaşi lucrare, Stonebraker denumeşte sistemele de gestiune a bazelor de
date obiect-relaţionale ca fiind sisteme de baze de date universale.
În momentul de faţă este evidentă tendinţa producătorilor de sisteme de gestiune a bazelor de
date de a trece la sisteme obiect-relaţionale şi, în general, această trecere se realizează prin adăugarea
treptată a caracteristicilor modelului obiect în sistemele de gestiune relaţionale. Oferta de sisteme de
gestiune a bazelor de date este deosebit de generoasă, pe o scară extinsă de performanţe şi costuri, de
la sisteme care se pot folosi gratuit (fără licenţă sau cu licenţă publică), până la sisteme cu înalte
performanţe, a căror utilizare necesită plata licenţelor respective. Chiar şi pentru astfel de sisteme
există versiuni de test (trial versions) care pot fi obţinute gratuit prin Internet (de la adrese care sunt
indicate în Bibliografie), astfel încât pot fi folosite pentru a înţelege şi a executa exemplele propuse
în această lucrare.
Sistemul Oracle este un sistem de gestiune a bazelor de date multi-utilizator puternic, cu
implementări pe toate platformele (Windows, Unix, Linux), care oferă atât performanţe de execuţie
ridicate, cât şi un grad înalt de protecţie şi securitate a datelor. În toate versiunile, Oracle oferă
implementarea completă a caracteristicilor modelului relaţional (conform standardului SQL2), iar
ultimele versiuni (Oracle8i, Oracle9i şi Oracle 10g) sunt sisteme de gestiune obiect-relaţionale
distribuite, implementând extensiile obiect-orientate prevăzute în standardul SQL3 şi oferind
posibilitatea de dezvoltare a bazelor de date distribuite. Sistemele de gestiune Oracle, ca şi diferite
instrumente de dezvoltare a aplicaţiilor de baze de date (Oracle Application Server, JDeveloper,
Oracle Forms etc.), se pot obţine de la adresa http://www.oracle.com şi termenii licenţei permit
utilizarea acestor sisteme în scopuri necomerciale pe o perioadă nelimitată; pentru utilizarea în
scopuri comerciale trebuie să fie plătite licenţele corespunzătoare
SQL Server este sistemul de gestiune a bazelor de date relaţionale dezvoltat de firma
Microsoft pentru sistemele de operare Windows. Au existat mai multe versiuni, versiunea actuală
(2007) fiind SQL Server 2005. În toate versiunile sistemul SQL Server suportă complet standardul
SQL2, cu implementarea performantă a trăsăturilor avansate de stocare şi prelucrare a datelor
(integritate referenţială, subinterogări, triggere, gestiunea tranzacţiilor, etc). De la adresa
http://www.microsoft.com/sql se poate obţine gratuit o versiune de test a sistemului SQL Server sau
se poate cumpăra o versiune completă. În plus, pachetul de dezvoltare .NET SDK (.NET Software
Development Kit), care se poate obţine gratuit de la adresa http://msdn.microsoft.com/downloads
conţine o versiune mai simplă de server de baze de date numit Microsoft SQL Server 2000 Desktop
Engine (MSDE 2000) care poate fi folosită pentru dezvoltarea şi execuţia exemplelor prezentate în
lucrare.
Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date
relaţionale pe platforme de calculatoare personale. MS Access dispune de un sistem de control al
bazei de date (database engine) şi o interfaţă grafică pentru interacţiunea cu utilizatorul. Aplicaţiile
de baze de date în MS Access se pot dezvolta cu multă uşurinţă datorită generatoarelor de aplicaţii
(Wizards) care permit proiectarea vizuală a bazelor de date şi a formularelor (forms) pentru
interfeţele grafice. MS Access este folosit în special pentru aplicaţii personale sau pentru mici afaceri
şi licenţa acestuia se poate cumpăra odată cu licenţa produsului Microsoft Office.

21
 MySQL este un sistem de gestiune a bazelor de date relaţionale cu implementări pentru
sistemele de operare Windows, Linux, Unix. La adresa http://www.mysql.com se găseşte ultima
versiune şi documentaţia sistemului de gestiune a bazelor de date MySQL care se poate utiliza
gratuit (este open source). Acest sistem este compatibil cu standardul SQL2, dar unele prevederi ale
standardului sunt implementate parţial. Versiunea actuală 2007 este versiunea 5.0 care ofera vederi,
proceduri stocate, triggere (caracteristici care lipseau in versiunile precedente).

22
 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
M participare parţială
FILIALA 1 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

SA1 r1 r4
S1 F1

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
F1 SA1 P1

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 Relaţia PROPRIETATE_
Entităţile
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
 5. METODOLOGIA DE PROIECTARE CONCEPTUALĂ A
BAZELOR DE DATE
Proiectarea unei baze de date cuprinde următoarele etape:
-proiectarea conceptuală
- proiectarea logică
- proiectarea fizică.

5.1. Proiectarea conceptuală a bazei de date

Proiectarea conceptuală a bazei de date este procesul de construire a unui model al
informaţiilor utilizate în întreprindere, independent de consideraţiile de ordin fizic (SGBDul
utilizat).

5.1.1. Construirea modelului de date conceptual local pentru fiecare vedere a

utilizatorilor
De regulă vederea unui utilizator este o zonă funcţională a întreprinderii (de exemplu
producţia, marketingul, vânzările, resursele umane, contabilitatea, aprovizionarea etc.).
utilizatorul este o persoană reală individuală sau un grup de persoane. identificarea vederilor
utilizatorilor se realizează prin examinarea diagramelor de flux şi prin chestionarea
utilizatorilor.
Modelul de date conceptual corespunzător vederii unui utilizator se numeşte model de
date conceptual local corespunzător vederii respective. Fiecare model de date conceptual
local cuprinde elementele enumerate în tabelul de mai jos, din care se desprind sarcinile de
proiectare conceptuală.

Elemente ale modelului de Sarcini pentru construirea modelului conceptual local

date conceptual local (Paşi)
Tipuri de entităţi 1.1. Identificarea tipurilor de entităţi (t.e.)
Tipuri de relaţii 1.2. Identificarea tipurilor de relaţii (t.r.)
Atribute 1.3. identificarea şi asocierea atributelor cu t.e. şi t.r.
Domeniile atributelor 1.4. Determinarea domeniilor atributelor
Cheile candidat 1.5. Determinarea atributelor chei candidat şi chei primare
Cheile primare
1.6. Specializarea/generalizarea t.e. (opţional)
1.7. Desenarea diagramei ER
1.8. Revizuirea modelului conceptual local cu utilizatorii

5.1.2. Identificarea tipurilor de entităţi (t.e.)

Modalităţi de identificare:
- studierea specificaţiei cerinţelor utilizatorului referitor la funcţia utilizatorului în
întreprindere; se caută substantivele în specificaţia cerinţelor utilizatorului (de
exemplu Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.)
- se caută obiectele principale de interes, excluzându-se calităţile; se grupează (de
exemplu Nr_Personal şi NumeP vor aparţine aceluiaşi tip de entitate Personal)
- se identifică obiectele care există pe cont propriu (de exemplu Personal există
indiferent de Nr_Personal, NumeP, etc.)
- discuţii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat =
Personal)

1
 Documentarea t.e.: după identificarea t.e. li se atribuie denumiri evidente, care se trec
într-un dicţionar de date.

5.1.3. Identificarea tipurilor de relaţii (t.r.)

- Identificarea relaţiilor: de regulă relaţiile sunt indicate de expresii verbale în
specificaţia utilizatorului. De exemplu: filiale are personal; personal administrează
proprietate; chiriaş vizitează proprietate etc. Interesează numai relaţiile dintre entităţi
cerute. Majoritatea relaţiilor sunt binare. Este bine de verificat fiecare pereche de
tipuri de entităţi, pentru a găsi o posibilă relaţie între ele.
- Determinarea cardinalităţii (1:1; 1:M; M:N) şi constrângerilor de participare (totală,
parţială); eventual se specifică şi valorile limită ale cardinalităţii.
- Documentarea tipurilor de relaţii. Pe măsură ce sunt identificate, li se atribuie
denumiri evidente; acestea, precum şi constrângerile se trec în dicţionarul de date.
- Vizualizarea pe parcurs a t.e. şi t.r. identificate prin modelarea ER.

5.1.5. Identificarea şi asocierea atributelor cu t.e. sau t.r.

- Identificare: Se caută substantive sau expresii substantivale în specificaţia cerinţelor
utilizatorilor care să caracterizeze t.e. şi t.r. găsite. Atributele sunt proprietăţi, calităţi,
caracteristici identificatoare ale unei entităţi sau relaţii. Se deosebeşte între atribute
simple, compuse, derivate. Atributele derivate trebuie reprezentate în modelul
conceptual pentru a nu pierde informaţii.
- Documentarea atributelor: pe măsură ce sunt identificate li se atribuit denumiri
evidente şi semnificative pentru utilizatori. Pentru fiecare atribut se trec în dicţionarul
de date: denumirea, sinonime sau aliasuri, tipul de date şi lungimea, eventuale valori
prestabilite (default value), dacă se acceptă Null-uri (required), dacă e compus sau
derivat, formula de calcul, dacă are valori multiple.

5.1.6. Determinarea domeniilor atributelor

- Determinarea: Domeniul este un recipient de valori din care unul sau mai multe
atribute îşi iau valorile. De exemplu domeniul numerelor de filială valabile este
compus din 3 caractere, literă-cifră-literă. Domeniul va include şi mulţimea valorilor
permise, dimensiunea şi formatul câmpului.
- Documentarea domeniului atributelor: se înregistrează denumirea şi caracteristicile
domeniilor atributelor în dicţionarul de date.

5.1.7. Determinarea atributelor chei candidat şi chei primare

- identificare: pentru fiecare entitate se identifică toate cheile candidat şi se secţionează
dintre ele cheia primară. O cheie candidat este o submulţime minimă de atribute ale
unei entităţi, care identifică în mod unic fiecare apariţie a acesteia. Cheia primară
aleasă va îndeplini următoarele criterii:
o va cuprinde un set minim de atribute
o va fi cheia candidat cu cea mai mică probabilitate de modificare a valorilor
o va fi cheia candidat cu cea mai mică probabilitate de a-şi pierde caracterul
de unicitate
o va fi cheia candidat cu cele mai puţine caractere
o va fi cheia candidat cel mai uşor de utilizat d.p.d.v. al utilizatorilor
Unei entităţi tari i se poate identifica o cheie primară, nu şi unei entităţi slabe. Unei
entităţi slabe i se poate identifica o cheie primară numai prin plasarea în ea a unei chei
străine, în cadrul relaţiei sale cu entitatea tare.
Cheile candidat care nu sunt selectate cheie primară devin chei alternative.

2
 - Documentarea cheilor primare şi alternative prin înregistrare în dicţionarul de date.

5.1.8. Specializarea/generalizarea tipurilor de entităţi (opţional)

Acest pas este dictat de reprezentarea cât mai clară a entităţilor importante şi a
relaţiilor dintre ele. Diagrama ER finală trebuie să fie cât mai lizibilă.
Modelul ER din figura 5.1 a conţine entităţile Proprietate_de_Inchiriat şi
Proprietate_de_Vanzare. Se generalizează prin crearea entităţii Proprietate (fig. 5.1 b.)

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător
Tip Tip

M N Proprietate Proprietate M 1
Chiriaş Cumpără Cumpărător
Închiriază de închiriat de vânzare

Nr.
Nr. M M Proprietate
Proprietate
Deţine
Adresa Adresa
1
Proprietar

Nr.
a) Proprietar

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător

M N Proprietate Proprietate M 1
Chiriaş Cumpără Cumpărător
Închiriază de închiriat de vânzare

d
Tipul
M 1
Proprietate Deţine Proprietar

Adresa
Nr.
Proprietate Nr.
Proprietate
b)

Fig. 5.1. Exemplu de generalizare a tipului de entitate

Entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare devin subclase ale entităţii

Proprietate în baza atributelor comune (Tipul, Adresa, cheia primară) şi în baza relaţiilor
comune asociate fiecăreia (Proprietar_deţine_Proprietate).

3
Entităţile subclasă au şi atribute diferite (Chirie respectiv Preţ) şi relaţii diferite (Inchiriaza
respectiv Cumpara).

5.1.9. Desenarea diagramei ER

Diagrama ER care se desenează va fi reprezentarea conceptuală a vederii unui
utilizator asupra întregii întreprinderi. Diagrama ER va reprezenta modelul de date
conceptual local bazat pe o anumită vedere a utilizatorului asupra întreprinderii.

5.1.10. Revizuirea modelului de date conceptual local împreună cu utilizatorii

Acest pas este necesar pentru a garanta că modelul este o reprezentare „adevărată” a
întreprinderii d.p.d.v. al utilizatorului.

5.1.11. Rezumat
Proiectarea conceptuală a bazei de date este procesul de construire a unui model al
informaţiilor utilizate în întreprindere, independent de consideraţiile de ordin fizic.
Proiectarea conceptuală începe prin crearea unui model de date conceptual al întreprinderii,
complet independent de detaliile de implementare. Pentru fiecare vedere a utilizatorilor
asupra întreprinderii este creat un model de date conceptual local.
O vedere a utilizatorului constă în datele cerute de către un anumit utilizator pentru a
lua o decizie sau a efectua o anumită sarcină. De regulă vederea unui utilizator este o zonă
funcţională a întreprinderii. Un utilizator poate fi o persoană sau un grup de persoane care
utilizează în mod direct sistemul.
Vederile utilizatorilor se pot identifica utilizând diagrame de flux de date – care
definesc zonele funcţionale şi eventual funcţiile individuale – sau/şi prin chestionarea
utilizatorilor, examinarea procedurilor, rapoartelor şi observarea întreprinderii.
Fiecare model de date conceptual local cuprinde tipurile de entităţi, tipurile de relaţii,
atributele, domeniile atributelor, cheile candidat şi primare.
Fiecare model de date conceptual local este susţinut de către o documentaţie, cum ar fi
dicţionarul de date, care este realizat pe parcursul dezvoltării modelului.

5.2. Proiectarea logică

Proiectarea logică este procesul de construire a unui model al informaţiilor utilizate în
întreprindere pe baza unui anumit model de date, dar independent de SGBD şi de alte
consideraţii de ordin fizic.

5.2.1 Construirea şi validarea modelului de date logic pentru fiecare vedere a

utilizatorilor
Acest pas este bazat pe modelul de date conceptual al vederii utilizatorului asupra
întreprinderii. Se efectuează modificarea structurii modelului conceptual conform cerinţelor
modelului de date relaţional (conform cerinţelor caracteristice unui sistem de gestionare
relaţional).

5.2.1.1 Transpunerea modelului de date conceptual local într-un model de date logic
local
Se rafinează modelul de date conceptual local prin eliminarea caracteristicilor
nedorite.

4
5.2.1.1.1 Eliminarea relaţiilor de tip M:N
O relaţie M:N (de mai mulţi la mai mulţi) se descompune pentru a identifica o relaţie
intermediară. Relaţia M:N se înlocuieşte cu două relaţii 1:M.
Exemplu: Relaţia Ziar Face Reclama Proprietate (fig. 5.2. a) este de cardinalitate M:N,
deoarece un ziar poate face reclamă mai multor proprietăţi, iar unei proprietăţi i se poate face
reclamă in mai multe ziare.
Relaţia se descompune conform figurii 5.2. b, unde Reclama este o entitate slabă a
cărei existenţă depinde de existenţa celorlalte două entităţi tari.

Nr.
Nume ziar Proprietate

M N
Ziar Face reclama Proprietate

a)
Nr.
Nume ziar Proprietate

1 N M 1
Ziar Listeaza Reclama Reclama In Proprietate

b)

Fig. 5.2. Relaţia de cardinalitate M:N se descompune în 2 relaţii de cardinalitate 1:M

Apar două tipuri de relaţii noi: Listeaza şi respectiv ReclamaIn care leagă entitatea
slabă de cele 2 entităţi tari.

5.2.1.1.2 Eliminarea relaţiilor complexe

O relaţie complexă include cel puţin trei tipuri de entităţi. Ea trebuie descompusă
pentru a identifica o relaţie intermediară. Relaţia complexă se înlocuieşte cu un număr
corespunzător de relaţii binare de cardinalitate 1:M.
În exemplul din figura 5.3. relaţia complexă Inchiriaza s-a descompus în trei relaţii
1:M, anume Organizeaza, AsociatCu şi Ţine; s-a identificat o entitate slabă:
Acord_de_Inchiriere care este legată de entităţile tari (iniţiale) prin cele trei relaţii binare de
cardinalitate 1:M identificate. Analizaţi constrângerile de participare din fig. 5.3. a şi 5.3. b!

5
 Nr.
Nr. Personal Proprietate

M M
Personal Inchiriaza Proprietate

Chirias

Nr. Chirias

a)

Nr.
Nr. Personal Proprietate

1 M M 1
Personal Organizeaza Proprietate Asociat cu Proprietate

Ţine

Chirias

Nr. Chirias

b)

Fig. 5.3. Relaţie complexă M:N descompusă în trei relaţii binare 1:M.

5.2.1.1.3 Eliminarea relaţiilor recursive

Acesta este un tip particular de relaţie care trebuie descompusă pentru a identifica o
relaţie intermediară. În exemplul din figura 5.4. relaţia recursivă Supravegheaza este
eliminată prin identificarea unei relaţii adiţionale denumită SupravegheatDe şi a unei entităţi
slabe: Personal_Alocat.

6
 Supervizează

1 M

Personal

Nr_Personal

a)

Personal_Alocat
1 M

SupravegheatDe Supervizează

1 1

Personal

Nr_Personal

b)
Fig. 5.4. Eliminarea unei relaţii recursive

5.2.1.1.4 Eliminarea relaţiilor cu atribute

Atunci când o relaţie are asociat un atribut, acest lucru sugerează existenţa unui tip de
entitate neidentificat. Exemplul din figura 5.5 se referă la determinarea numărului de ore
lucrate de angajaţii temporari atribuiţi fiecărei filiale. Relaţia LucreazaLa are atributul Ore-
Lucrate şi este de cardinalitate M:N. Se descompune în două relaţii binare de cardinalitate
1:M. Acum atributul Ore_Lucrate aparţine noii entităţi slabe identificate: Alocaţie_Filiala.
Analizaţi constrângerile de participare din fig. 5.5 a şi 5.5. b!

7
 Ore_Lucrate Nr. Filială
Nr. Personal

M N
Personal Lucrează La Filiala

a)

Ore_Lucrate Nr. Filială

Nr. Personal

N M N
1
Personal Atribuit La Alocaţie_ Necesită Filiala
Filiala

b)

Fig. 5.5. Eliminarea unei relaţii cu atribut

5.2.1.1.5 Eliminarea atributelor cu valori multiple

Este vorba de atribute cu mai multe valori pentru o singură entitate. Acest atribut
trebuie descompus pentru a identifica o nouă entitate. Exemplul din figura 5.6. se referă la
evidenţa filialelor, unde o filială poate avea mai multe numere de telefon. Se identifică o nouă
entitate: Telefon, legată de entitatea Filiala prin relaţia Are.

Nr. Telefon Nr. Filială

Adresă

Filiala

Nr. Filială
Nr. Telefon

M 1
Telefon Are Adresa
Filiala

Fig. 5.6. Eliminarea atributelor cu valori multiple

5.2.1.5 Reexaminarea relaţiilor 1:1

Asemenea relaţii pot indica existenţa a două relaţii care să reprezinte acelaşi obiect în
cadrul întreprinderii. De exemplu entităţile Filiala şi departament pot fi sinonime. În astfel de

8
situaţii cele două entităţi se îmbină, selectând una din cheile primare, dacă acestea nu coincid.
Cealaltă cheie primară devine alternativă.

5.2.1.1.7 Eliminarea relaţiilor redundante

O relaţie este redundantă atunci când aceeaşi informaţie se poate obţine şi prin alte
relaţii. Trebuie deci de aflat dacă există mai mult decât o singură cale între două entităţi. Dacă
se identifică 2 căi, nu înseamnă neapărat că una din relaţii este redundantă. Trebuie de ţinut
cont şi de semnificaţia temporală a relaţiilor.

1 1
Bărbat CăsătoritCu Femeie

1 1

Tatăl lui Mama lui

1
M M
Copil

Fig. 5.7. Relaţie neredundantă!

În exemplul din figura 5.7. relaţia este neredundantă, deşi există 2 căi intre entitatea
Copil şi Barbat. Tatăl ar putea avea copii dintr-o căsătorie precedentă, sau ar putea să nu fie
căsătorit cu mama copilului, iar în figură se modelează numai căsătoria curentă a tatălui.

5.2.1.2 Extragerea relaţiilor (tipurilor de entităţi) din modelul de date logic local
În urma 5.2.1.1 s-a obţinut modelul de date logic local, ca urmare a rafinării modelului
de date conceptual.
La 5.2.1.2. se extrag relaţiile pentru a reprezenta entităţile care le compun.
Componenţa fiecărei relaţii va fi descrisă utilizând un limbaj de definire a bazelor de date
(DBDL). Într-un DBDL apare denumirea relaţiei, apoi între paranteze atributele simple. Se
identifică cheia primară, cheile alternative şi/sau cheile străine ale relaţiei. Se trece relaţia
care conţine cheia străină ca şi cheie primară.

Relaţia pe care o entitate o are cu altă entitate este exprimată prin mecanismul cheie
primară – cheie străină. Adică cheia primară din entitatea părinte devine cheie străină în
entitatea copil.
În continuare se prezintă cum relaţiile care reprezintă entităţile şi relaţiile acestora
sunt extrase din structurile de date posibile, prezentate în modelul de date logic (fig. 5.8.).

9
 Strada Oraşul
Prenume
Nume
Nume_ CodPoştal
Adresa
Prenume

Nr_Filială
Adresa
Funcţie Administrează
1
1
Salariu Personal Filiala
M Nr. Fax
Are 1
Sex 1
Nr_Personal Nr. Tel.

ÎnruditCu

Rudenie M
Rudă
Apropiată
NumeR
Nr. Tel.
Adresa

Fig. 5.8. Model de date logic

Din acest model de date logic se extrag:

a. Tipuri de entităţi tari:

Pentru fiecare entitate tare (obişnuită) se creează o relaţie care să cuprindă toate
atributele sale simple.
Exemplu: entitatea tare Personal
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
Cheie primară Nr_Personal

b. Tipuri de entităţi slabe: Ruda_Apropiata.

Pentru fiecare entitate slabă se creează o relaţie care să cuprindă toate atributele sale simple.
În plus se include cheia primară a entităţii părinte (sau proprietar) ca şi cheie străină.

Compoziţia acestei relaţii va fi:

Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie)
Cheie primară Nr_Personal împreună cu NumeR
Cheie străină Nr_Personal se referă la Personal (Nr_Personal)

10
c. Tipuri de relaţii binare unu la unu (1:1)
În relaţia de cardinalitate 1:1 Personal Administreaza Filiala entitatea părinte este
Personal, deoarece are participare parţială. Ca urmare se plasează o copie a cheii primare din
Personal în Filiala, unde devine cheie străină sub denumirea Nr_Personal_Manager.

Compoziţia acestor relaţii va fi:

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
Cheie primară Nr_Personal
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

d. Tipuri de relaţii binare unu-la-mai-mulţi (1:M)

Pentru fiecare relaţie binară 1:M între entităţile E1 şi E2 se plasează o copie a cheii
primare din E1 în E2, unde devine cheie străină. Entitatea aflată în partea notată cu „1” este
entitatea părinte, iar cea din partea cu „M” este entitatea copil. Întotdeauna cheia primară din
entitatea părinte devine cheie străină în entitatea copil.

Exemplu: Filiala Are Personal, unde Filiala este părinte iar personal este copil.

Compoziţia acestor relaţii va fi:

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala)
Cheie primară Nr_Personal
Cheie străină Nr_Filiala se referă la Filiala (Nr_Filiala)
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

5.2.1.2. se încheie cu documentarea relaţiilor şi atributelor chei străine.

Compoziţia relaţiilor extrase din modelul de date logic se documentează utilizând DBDL.
Sintaxa poate fi extinsă pentru a exprima constrângerile de integritate asupra cheilor străine
(vezi 5.2.1.6). Şi dicţionarul de date trebuie reactualizat cu noile atribute cheie identificate la
5.2.1.2

5.2.1.3 Validarea modelului prin utilizarea normalizării

Normalizarea este o procedură de stabilire a atributelor care aparţin împreună unui tip
de entitate. Prin normalizare datele sunt organizate conform dependenţelor lor funcţionale şi
se elimină riscul anomaliilor de reactualizare. În prima formă normală se elimină grupurile
repetitive.

5.2.1.4 Validarea modelului conform tranzacţiilor utilizatorului

Modelul trebuie să accepte tranzacţiile cerute de către vederile utilizatorului.
Tranzacţiile se determină din specificaţiile cerinţelor utilizatorilor. Prin folosirea diagramei
ER, a dicţionarului de date şi a legăturilor cheie primară/cheie străină prezentate în relaţii se
încearcă efectuarea manuală a tranzacţiilor.

11
5.2.1.5 Desenarea diagramei ER
Se desenează varianta finală a diagramei ER, validată prin normalizare şi conform cu
tranzacţiile pe care trebuie să le accepte.

5.2.1.6 Definirea constrângerilor de integritate

Prin impunerea de constrângeri se protejează baza de date faţă de riscul de incoerenţă.
Se consideră 5 tipuri de integritate, anume referitoare la:
a. datele cerute
b. domeniile atributelor
c. integritatea entităţilor
d. integritatea referenţială
e. constrângerile întreprinderii

a. Datele cerute
Unele atribute nu admit Null-uri. În aceste situaţii se selectează proprietatea de câmp
required, care cere date pentru câmpul respectiv. Se verifică dacă aceste constrângeri au fost
identificate şi documentate în dreptul atributelor în dicţionarul de date (vezi 5.1.2)

b. Constrângerile privind domeniile atributelor

Se verifică dacă s-au identificat şi documentat la 5.1.4

c. Integritatea entităţilor
Cheia primară a unei entităţi nu poate conţine Null-uri. Se verifică 5.1.5

d. Integritatea referenţială
Se referă la relaţia entitate părinte – entitate copil. Se ştie că cheia primară din părinte
se copiază în copil unde devine cheie străină.

Integritatea referenţială înseamnă ca o valoare nenulă a cheii străine din entitatea copil
trebuie să se refere la (să coincidă cu) o valoare existentă în entitatea părinte.
Dacă entitatea copil are participare totală în relaţie, nu sunt permise Null-uri în câmpul cheie
străină. Se admit atunci când entitatea copil are participare parţială.

Asigurarea integrităţii referenţiale se realizează prin constrângeri de existenţă. Acestea

definesc condiţiile în care poate fi inserată, reactualizată (modificată) sau ştearsă o cheie
candidat sau o cheie străină.

Se ia ca exemplu relaţia Personal Administrează Proprietate, de cardinalitate 1:M.

Entitate părinte (Ep): Personal, cheie primară: Nr_Personal
Entitate copil (Ec): Proprietate, cheie străină: Nr_Personal, copie a cheii primare din
Personal.

Cazul 1. Inserarea unei apariţii în relaţia (entitatea) copil

Pentru a asigura integritatea referenţială se verifică dacă atributul Nr_Personal din apariţia
nou inserată în Ec este stabilit ca Null sau are o valoare existentă în Ep.

Cazul 2. Ştergerea unei apariţii din relaţia (entitatea) copil

Se poate efectua fără probleme, nu afectează integritatea referenţială.

12
Cazul 3. Reactualizarea cheii străine în relaţia (entitatea) copil
Similar cazului 1.

Cazul 4. Inserarea unei apariţii în relaţia (entitatea) părinte

Se poate efectua fără probleme. Ep are participare parţială, deci poate exista un membru al
personalului care nu administrează o proprietate.

Cazul 5. Ştergerea unei apariţii din relaţia (entitatea) părinte.

Dacă apariţie care urmează a fi ştearsă din Ep îi corespunde o apariţie (sau mai multe) din Ec,
atunci integritatea referenţială se pierde prin ştergere.
Posibile strategii de luat în considerare:

NO ACTION Blocarea ştergerii apariţiei din Ep, dacă are corespondent(i) în Ec

CASCADE Dacă o apariţie în Ec se şterge, se şterg automat corespondenţii din Ec.

Dacă Ec acţionează ca Ep în altă relaţie, ştergerea se propagă în
cascadă.

SET NULL Când se şterge o apariţie din Ep, valorile cheii străine în Ec sunt setate
la Null. Are loc o reactualizare prin setare la Null a valorilor atributelor
selectate din cheia străină a Ec. Această strategie se poate aplica numai
dacă atributele cheie străină acceptă Null-uri.

SET DEFAULT Când se şterge o apariţie din Ep, valorile cheii străine corespunzătoare
din Ec sunt setate la valori prestabilite (default).
Exemplu: se şterge un membru al personalului în Ep (Personal) şi
automat proprietăţile pe care acestea le-a administrat trecute în Ec
(Proprietăţi) se setează la atributul Nr_Pers la valoarea corespunzătoare
managerului.

NO CHECK Nu are loc nici o verificare de integritate. Când se şterge o apariţie din
Ep nu este garantată menţinerea integrităţii referenţiale.

Cazul 6. Reactualizarea cheii primare în relaţia (entitatea) părinte

Dacă valorii reactualizate a cheii primare în Ep îi corespundeau una (mai multe) valori ale
cheii străine în Ec, integritatea referenţială este pierdută. Se va aplica una din strategiile de la
cazul 5.

e. Constrângerile întreprinderii
Sunt de fapt regulile de afaceri care pot uneori genera reactualizări ele entităţilor. De
exemplu agenţia imobiliară poate stabili ca un membru al personalului să administreze
maxim 10 proprietăţi.
5.2.1.6. se încheie cu documentarea tuturor constrângerilor de integritate. Aceasta
se face în dicţionarul de date, pentru a fi luate în considerare la implementarea fizică.

5.2.1.7 Revizuirea modelului de date logic local împreună cu utilizatorii

Se verifică dacă modelul de date logic local este o reprezentare „adevărată” a vederii
utilizatorului. Modelul de date logic local trebuie să fie complet şi in întregime documentat.
Modelul şi documentaţia se revăd împreună cu utilizatorul.

13
5.2.2. Construirea şi validarea modelului de date logic global

În această etapă se construieşte un model de date logic global prin îmbinarea modelelor de
date logice locale individuale, care au fost realizate pentru a reprezenta fiecare vedere a
utilizatorilor.
După îmbinare trebuie rezolvate conflictele dintre vederi, ca şi orice suprapuneri existente.
Va rezulta o reprezentare a întregii întreprinderi independentă de orice utilizator sau aplicaţie.

5.2.2.1. Îmbinarea modelelor de date logice locale individuale într-un singur model de
date logic global al întreprinderii

(1) Revizuirea denumirilor entităţilor şi cheilor primare din modelele locale.

Pot exista două sau mai multe entităţi care au aceeaşi denumire dar sunt de fapt diferite,
respective acre au denumiri diferite, dar sunt aceleaşi. Se compară conţinutul de date al
fiecărui tip de entitate. Se utilizează cheile primare pentru a identifica tipurile de entităţi
echivalente, dar cu denumiri diferite.
(2) Revizuirea denumirilor relaţiilor. Se procedează ca la (1).
(3) Îmbinarea entităţilor din vederile locale
Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară (fig. 5.9)
Astfel de entităţi reprezintă de regulă acelaşi obiect în lumea reală. La fuziune se
includ atributele entităţilor iniţiale, eliminându-se dublurile.

(Vederea 1)
Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)
Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vedere Globală)
Personal (Nr_Personal, Prenume, Nume, Adresa, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.9. Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară

În versiunea globală obţinută prin îmbinare s-a utilizat versiunea descompusă a atributului
Nume_Prenume (în urma consultării cu utilizatorii).

Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite (fig. 5.10)

Astfel de entităţi nu au aceeaşi cheie primară, dar au chei candidat similare. Rezultă
aceeaşi vedere globală ca în fig. 5.9.

14
 (Vederea 1)
Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nume_Prenume
Cheie alternativă Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)
Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)
Cheie primară Nr_Personal
Cheie alternativă Prenume, Nume
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.10. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite

Îmbinarea entităţilor cu denumiri diferite, cu chei primare similare sau diferite

Astfel de entităţi se pot identifica atunci când: denumirile sunt diferite, dar indică
acelaşi scop, după cheia primară, după participarea în anumite relaţii.
Exemplu: Entităţile Personal şi Angajaţi.

(4) Includerea (fără îmbinare) a entităţilor unice din fiecare vedere locală
Toate entităţile care nu au echivalent se includ nemodificate în modelul global.

(5) Îmbinarea relaţiilor din vederile locale

Se examinează toate relaţiile (denumire, scop, constrângeri structurale) din toate
vederile locale şi se elimină conflictele, prin:
- Îmbinarea relaţiilor cu aceeaşi denumire şi acelaşi scop, apoi
- Îmbinarea relaţiilor cu denumiri diferite dar acelaşi scop

(6) Includerea (fără îmbinare) a relaţiilor unice din fiecare vedere locală
Relaţiile pentru care nu s-au găsit relaţii identice în alte vederi se includ nemodificate
în modelul global.

(7) Căutarea entităţilor şi relaţiilor lipsă

Identificarea entităţilor şi relaţiilor lipsă dintre diversele vederi ale utilizatorilor şi care
nu apar în nici una dintre vederi este o operaţiune dificilă:
Acestea pot rezulta din modelul de date general, dacă există.
Când se consultă utilizatorii asupra unei anumite vederi, ei trebuie rugaţi să
examineze şi entităţile şi relaţiile din alte vederi.
Se examinează atributele fiecărui tip de entitate şi se compară cu atributele entităţilor
din alte vederi. Poate exista un atribut al unei entităţi dintr-o vedere care corespunde unui
atribut cheie primară, cheie alternativă sau unui atribut simplu al unei entităţi din altă
vedere. Dintr-o astfel de corespondenţă rezultă existenţa unei relaţii neidentificate,
construibilă prin mecanismul cheie primară/cheie străină.

(8) Verificarea cheilor străine

Se verifică dacă cheile străine din entităţile copil mai sunt corecte şi se efectuează
modificările necesare.

15
 (9) Verificarea constrângerilor de integritate
Se verifică dacă constrângerile de integritate ale modelului global nu intră în conflict
cu constrângerile de integritate din vederile utilizatorilor. Conflictele se rezolvă prin
consultarea cu utilizatorii.

(10) Desenarea modelului de date logic global

Se desenează diagrama ER a modelului de date logic global, care reprezintă îmbinarea
tuturor modelelor de date logica locale.

(11) Reactualizarea documentaţiei

Documentaţia trebuie reactualizată în urma modificărilor intervenite la realizarea
modelului global. Documentaţia trebuie să reflecte întotdeauna modelul de date curent.

5.2.2.2 Validarea modelului de date logic global

Se realizează prin utilizarea normalizării şi conform tranzacţiilor cerute, dacă este
necesar. Este un pas echivalent cu 5.2.1.3 respectiv 5.2.1.4, anume se fac aceleaşi validări
dar acum pentru modelul de date logic global.

5.2.2.3 Verificarea în vederea dezvoltării locale

Se determină dacă este probabil ca în viitorul previzibil să apară modificări şi se
evaluează capacitatea modelului de date logic global de a cuprinde aceste modificări.
Modelul de date logic global trebuie să poată fi extins cu uşurinţă. Modelul creat trebuie să
fie extensibil, să poată evolua în condiţiile afectării minime a utilizatorului. Se
incorporează modificări numai dacă utilizatorul o cere.

5.2.2.4 Desenarea diagramei ER finale

Diagrama ER finală reprezintă modelul de date logic global al întreprinderii. Se
desenează după ce modelul de date logic global a fost validat. Documentaţia (schema
relaţională şi dicţionarul de date) trebuie reactualizată şi completată.

5.2.2.5 Revizuirea modelului de date logic global împreună cu utilizatorii

Revizuirea va garanta faptul că modelul de date logic global este o reprezentare
„adevărată” a întreprinderii. Modelul împreună cu documentaţia se revizuiesc în colaborare
cu utilizatorii, pentru a confirma că sunt corecte şi complete.

5.2.3. Rezumatul capitolului 5.2.

Proiectarea logică a bazelor de date este procesul de construire a unui model al

informaţiilor utilizate în cadrul unei întreprinderi, bazat pe un anumit model de date, dar
independent de un anumit SGBD şi de alte consideraţii de ordin fizic.
Principalele etape cuprind: construirea şi validarea unui model de date logic local
corespunzător fiecărei vederi a utilizatorilor (5.2.) şi construirea şi validarea unui model de
date logic global (5.2.2).
Rafinarea unui model de date conceptual pentru a obţine un model de date logic
include: eliminarea relaţiilor de tip M:N, a relaţiilor complexe, recursive, cu atribute, a

16
atributelor cu valori multiple, reexaminarea relaţiilor de tip 1:1 şi eliminarea relaţiilor
neredundante.
Modelul de date logic se validează prin normalizare, prin care se garantează că
modelul reprezintă fidel întreprinderea, este coerent, cu redundanţă minimă şi stabilitate
maximă.
Constrângerile de integritate se impun pentru a proteja BD faţă de a deveni
incoerentă. Există 5 tipuri de constrângeri de integritate: asupra datelor necesare, ale
domeniilor atributelor, de integritate a entităţilor, de integritate referenţială şi ale
întreprinderii.
Integritatea referenţială se asigură prin constrângeri de existenţă, care definesc în
ce condiţii poate fi o cheie candidata sau străină inserată, reactualizată sau ştearsă.
Există mai multe strategii care pot fi aplicate atunci când o apariţie a entităţii părinte pe care
vrem să o ştergem are corespondent în entitatea copil: NO ACTION, CASCADE, SET
NULL, SET DEFAULT şi NO CHECK.
Constrângerile întreprinderii se numesc uneori şi reguli de afaceri.
Modelul de date logic este susţinut de către documentaţie, cum ar fi dicţionarul de
date sau schema relaţională, care sunt realizate pe parcursul construirii modelului.

17