Documente Academic
Documente Profesional
Documente Cultură
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.
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
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.
- 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.
- 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.
2
- 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.
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).
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.
SGBD este un sistem de programe care permite utilizatorului definirea, crearea şi întreţinerea
bazei de date şi accesul controlat la aceasta.
3
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.
Baza de date
Utilizator Program
SGBD Date
final aplicatie
4
Fig. 1.1. Componente ale unui sistem de baze de date.
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.).
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.
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.
• 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.
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.
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ţă.
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.
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.
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.
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ă.
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).
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).
14
Fig.1.9. Diagrama E-A extinsă cu ierarhie de tipuri de entităţi.
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).
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].
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:
• 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.
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).
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.
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