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 exemplu, 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

1
  Fiecare tabel are un set de atribute, care împreună reprezintă o “cheie” care definește fiecare
entitate în mod unic.
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;

2
 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
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.

3
 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.

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

4
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.
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 final Program aplicatie SGBD
Date

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 corespunzătoare, 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 SECȚIE sau SECȚII (oricare variantă poate fi folosită) și
este caracterizată prin aceleași atribute care caracterizează tipul entității:
SECȚIE(Număr, 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, DataNașterii, Adresa, Funcție, 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, DataÎnceperii, 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, DataNașterii, GradRudenie)
Asocierea SECȚIE-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 ANGAJAȚI-
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:
STUDENȚI(Nume ,Prenume, Adresa,...)
DISCIPLINE(Denumire, Credite,...)
Între aceste mulțimi de entități se poate defini asocierea STUDENȚI-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 STUDENȚI ș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 STUDENȚI ș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 STUDENȚI ș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 SECȚIE-ANGAJAT poate fi
exprimată prin verbul cuprinde, asocierea ANGAJAȚI-DEPENDENȚI poate fi exprimată prin
verbul întreține, asocierea ANGAJAȚI-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 îl 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, serviciul 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, DataNașterii, Adresa,
Salariu) ale tipului de entitate ANGAJAT sunt moștenite de fiecare din subtipurile acestuia. Atributul
Funcție nu este moștenit, deoarece specializarea subtipurilor s-a efectuat după acest atribut. Ca
atribute specifice, subtipul SECRETARA are atributul VitezăRedactare, 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 creează 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 (NrÎnregistrare, Marca,
VitezaMaximă, Preț, NumărPasageri) și CAMION(NrÎnregistrare, Marca, VitezaMaximă, Preț,
Tonaj), se poate defini un supertip al acestor tipuri: VEHICUL (NrÎnregistrare, Marca,
VitezaMaximă, Preț). 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 (NumărPasageri 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 înalt), 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 conține 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.

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.
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).

16
 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ă.
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.

17
 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 constituie 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.
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

18
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ță.

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

19
 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.

Î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.

20
 Î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.
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

21
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 oferă vederi,
proceduri stocate, triggere (caracteristici care lipseau in versiunile precedente).

22