Cap 1. Teoria Bd Relationale [606782]

CAPITOLUL 1.

TEORIA BAZELOR DE DATE RELA ȚIONALE

1.1. MODELUL RELA ȚIONAL

Modelul rela țional a fost propus de că tre IBM și a revolu ționat
reprezentarea datelor f ăcând trecerea la genera ția a doua de baze de date.
Modelul este simplu , are o solid ă fundamentare teoretic ă fiind bazat
pe teoria seturilor (ansamblurilor) și pe logica matematic ă. Pot fi
reprezentate toate tipurile de structur i de date de mare complexitate, din
diferite domenii de activitate.
Modelul relaț ional este definit prin: struct ura de date, operatorii care
acționează asupra structurii și restricțiile de integritate.
1) Conceptele utilizate pentru definirea structurii de date sunt:
domeniul, tabela (rela ția), atributul, tuplul, cheia și schema tabelei.
Domeniu este un ansamblu de valori caracterizat prin tr-un nume. El
poate fi explicit sau implicit.
Tabela/rela ția este un subansamblu al pr odusului cartezian al mai
multor domenii, caracterizat printr-un nu me, prin care se definesc atributele
ce aparțin aceleaș i clase de entit ăți.
Atributul este coloana unei tabele, caracterizat ă printr-un nume.
Cheia este un atribut sau un ansamblu de atribute care au rolul de a
identifica un tuplu dintr-o tabel ă. Tipuri de chei: primare/alternate,
simple/comune, externe.
Tuplul este linia dintr-o tabel ă și nu are nume. Or dinea liniilor
(tupluri) și coloanelor (atribute) dintr-o tabel ă nu trebuie s ă prezinte nici-o
importanță.
Schema tabelei este format ă din numele tabelei, urmat între
paranteze rotunde de lista atributelor, ia r pentru fiecare atribut se precizeaz ă
domeniul asociat.
Schema bazei de date poate fi reprezentat ă printr-o diagram ă de
structură în care sunt puse în eviden ță și legăturile dintre tabele. Definirea
legăturilor dintre tabele se face logic construind asocieri între tabele cu
ajutorul unor at ribute de leg ătură. Atributele implicat e în realizarea
legăturilor se g ăsesc fie în tabelele asociate, fie în tabele distincte construite
special pentru leg ături. Atributul din tabela ini țială se numește cheie extern ă
iar cel din tabela final ă este cheie primar ă. Legă turile posibile sunt 1:1, 1:m,
m:n. Potenț ial, orice tabelă se poate lega cu orice tabel ă, după orice atribute.

Legăturile se stabilesc la momentul descrierii datelor prin limbaje de
descriere a datelor (LDD) , cu ajutorul restric țiilor de integritate. Practic, se
stabilesc și legături dinamice la momentul execu ției.
2) Operatorii modelului rela țional sunt operatorii din algebra
relațională și operatorii din calculul rela țional.
Algebra rela țională este o colecț ie de opera ții formale aplicate
asupra tabelelor (rela țiilor), și a fost conceput ă de E.F.Codd. Opera țiile sunt
aplicate în expresiile algebrice rela ționale care sunt cereri de reg ăsire.
Acestea sunt compuse din operatorii rela ționali și operanzi. Operanzii sunt
întotdeauna tabele (una sau mai multe). Rezultatul evaluării unei expresii
relaționale este format dintr-o singur ă tabelă.
Algebra rela țională are cel pu țin puterea de reg ăsire a calcului
relațional. O expresie din calculul rela țional se poate transforma într-una
echivalentă din algebra rela țională și invers.
Codd a introdus șase operatori de bază (reuniunea, diferen ța,
produsul cartezian, selec ția, proiec ția, joncțiunea) și doi operatori derivați
(intersecț ia și diviziunea). Ulterior au fost introdu și și alți operatori deriva ți
(speciali ). În acest context, o peratorii din algebra rela țională pot fi grupa ți
în două categorii: pe mul țimi și speciali.
Operatori pe mul țimi (R1, R2, R3 sunt relaț ii (tabele)) sunt:
• Reuniunea . R3 = R1 ∪ R2, unde R3 va con ține tupluri din R1
sau R2 luate o singur ă dată;
• Diferența. R3 = R1 \ R2, unde R3 va con ține tupluri din R1 care
nu se regă sesc în R2;
• Produsul cartezian. R3 = R1 × R2, unde R3 va con ține tupluri
construite din perechi (x1x2), cu x1 ∈R1 și x2∈R2;
• Intersecț ia. R3 = R1 ∩ R2, unde R3 va conț ine tupluri care se
găsesc în R1 și R2 în acela și timp, etc.
Operatori rela ționali speciali sunt:
• Selecția. Din R1 se ob ține o subtabelă R2, care va con ține o
submulțime din tuplurile ini țiale din R1 ce satisfac un predicat
(o condiție). Numărul de atribute din R2 este egal cu num ărul de
atribute din R1. Num ărul de tupluri din R2 este mai mic decât
numărul de tupluri din R1.
• Proiecția. Din R1 se ob ține o subtabel ă R2, care va con ține o
submulțime din atributele ini țiale din R1 și fără tupluri
duplicate. Num ărul de atribute din R2 este mai mic decât
numărul de atribute din R1.
• Joncțiunea este o deriva ție a produsului cart ezian, ce presupune
utilizarea unui calificator care s ă permită compararea valorilor

unor atribute din R1 și R2, iar rezultatul în R3. R1 și R2 trebuie
să aibă unul sau mai multe atribute comune care au valori
comune.
Algebra rela țională este prin defini ție neprocedural ă (descriptiv ă),
iar calculul rela țional permite o manier ă de c ăutare mixtă
(procedural ă/neprocedural ă).
Calculul rela țional se bazeaz ă pe calculul predicatelor de ordinul
întâi (domeniu al logicii) și a fost propus de E.F. Codd. Predicatul este o
relație care se stabile ște între anumite elemente și care poate fi confirmat ă
sau nu. Predicatul de ordinul 1 este o rela ție care are drept argumente
variabile care nu sunt predicate. Variabila poate fi de tip tuplu (valorile sunt
dintr-un tuplu al unei tabele) sau domeni u (valorile sunt dintr-un domeniu al
unei tabele). Cuantificatorii (operatorii) utilizaț i în calculul rela țional sunt:
universal ( ∀) și existențial (∃).
Construcția de bază în calculul rela țional este expresia rela țională de
calcul tuplu sau domeniu (func ție de tipul variab ilei utilizate).
Expresia rela țională de calcul este format ă din: opera ția de efectuat,
variabile (tuplu respectiv domeniu), condiț ii (de compara ție, de existen ță),
formule bine definite (opera nzi-constante, variabile, funcț ii, predicate;
operatori), cuantificatori.
Pentru implementarea acestor operatori exist ă comenzi specifice în
limbajele de manipulare a datelor (LMD) din sistemele de gestiune a bazelor
de date rela ționale (SGBDR). Aceste come nzi sunt utilizate în opera ții de
regăsire (interogare).
După tehnica folosit ă la manipulare, LMD sunt bazate pe:
• calculul rela țional (QUEL în Ingres, ALPHA propus de Codd);
• algebra rela țională (ISBL, RDMS);
• transformare (SQL, SQUARE);
• grafică (QBE, QBF).
Transformarea oferă o putere de reg ăsire echivalentă cu cea din
calculul și algebra rela țională. Se bazeaz ă pe transformarea (mapping) unui
atribut sau grup de atribute într-un atribut dorit prin intermediul unor rela ții.
Rezultatul este o rela ție (tabelă) care se poate utiliza într-o alt ă transformare.
Grafica oferă interactivitate mare pentru constrirea cererilor de
regăsire. Utilizatorul specific ă cerea alegând sau completând un ecran
structurat grafic. Poate fi folosit de că tre toate categoriile de utilizatori în
informatic ă.
3) Restric țiile de integritate ale modelului rela țional sunt
structurale ș i comportamentale.

Restricțiile structurale sunt:
• Restricția de unicitate a cheii. Într-o tabelă nu trebuie s ă existe
mai multe tupluri cu aceea și valoare pentru ansamblul cheie;
• Restricția referen țială. Intr-o tabel ă t1 care refer ă o tabelă t2,
valorile cheii externe trebuie s ă figureze printre valorile cheii
primare din t2 sau s ă ia valoarea nul l (neprecizat);
• Restricția entității. Intr-o tabel ă, atributele din cheia primar ă nu
trebuie să ia valoarea NULL.
Cele trei restric ții de mai sus sunt minimale .
Pe lângă acestea, exist ă o serie de alte restric ții structurale care se
referă la dependen țele dintre date: func ționale, multivaloare, joncț iune etc.
(sunt luate în considerare la tehnic ile de proiectare a bazelor de date
relaționale – BDR).
Restricțiile de comportament sunt cele care se definesc prin
comportamentul datelor și țin cont de valorile din BDR:
• Restricția de domeniu. Domeniul corespunză tor unui atribut dintr-
o tabelă trebuie să se încadreze între anumite valori;
• Restricții temporare . Valorile anumitor atribute se compar ă cu
niște valori temporare (rezultate din calcule etc.).
Restricțiile de comportament fiind fo arte generale se gestioneaz ă fie
la momentul descrierii datelor (de exem plu prin clauza CHECK), fie în afara
modelului la momentul execu ției.
Restricțiile de integritate s uportate de Oracle sunt:
• NOT NULL nu permite valori NUL L în coloanele unei tabele;
• UNIQUE nu sunt permise valori duplicat în coloanele unei
tabele;
• PRIMARY KEY nu permite valori duplicate sau NULL în coloana sau coloanele definite astfel;
• FOREIGN KEY presupune ca fiecar e valoare din coloana sau
setul de coloane defini astfel s ă aibă o valoare corespondent ă
identică în tabela de leg ătură, tabelă în care coloana
corespondent ă este definit ă cu restric ția UNIQUE sau
PRIMARY KEY;
• CHECK elimin ă valorile care nu sa tisfac anumite cerin țe
(condiții) logice.
Termenul de chei (keys) este folosit pentru de finirea câtorva
categorii de constrângeri și sunt: primary key, unique key, foreign key,
referenced key.
Se consider ă că modelul rela țional are o serie de limite cum ar fi:
• Simplitatea modelului îl face difici l de aplicat pentru noile tipuri

de aplicații (multimedia, internet etc.);
• Nu asigur ă o independen ță logică totală a datelor de aplica ție;
• Poate crește redundan ța datelor.

1.2. BAZE DE DATE RELA ȚIONALE

Bazele de date rela ționale (BDR) utilizeaz ă modelul de date
relațional și noțiunile aferente. BDR au o solid ă fundamentare teoretic ă, în
special prin cercetă rile de la IBM conduse de E.F.Codd.
BDR este un ansamblu organizat de tabele (relații) împreun ă cu
legăturile dintre ele.
Concepte utilizate la organizarea datelor în BDR și respectiv fi șiere
sunt prezentate în tabelul 1.1.

Concepte utilizate în organizarea datelor
Tabelul 1.1.
Fișiere fișier înregistrare câmp valori
BDR tabelă(relație) tuplu (linie) atribut(coloan ă) domeniu valori

Avantajele BDR față de fișiere sunt prezentate în tabelul 1.2.

Avantajele BDR
Tabelul 1.2.
CRITERIU BDR FIȘIERE
Independen ța datelor logică și fizică fizică
Niveluri de structurare conceptual, logic și fizic logic și fizic
Deschidere și portabilitate mare mică
Reprezentarea și utilizarea datelor simplificat prin model complicat
Structura de date se p ăstrează în dicționarul BDR în programe.

Atunci când dorim s ă realizăm o bază de date rela țională trebuie s ă
știm clar ce avem de f ăcut, adică să stabilim obiectivele activit ății noastre.
În acest sens, câteva dintre cele mai importante obiective , le prezent ăm în
continuare:
• Partiționarea semnific ă faptul că aceleași date trebuie s ă poată fi
folosite în moduri diferite de c ătre diferiți utilizatori;
• Deschiderea se refer ă la faptul c ă datele trebuie s ă fie ușor
adaptabile la schimb ările care pot apă rea (actualizarea structurii,
tipuri noi de date etc.);
• Eficiența are în vedere stocarea ș i prelucrarea datelor, care trebuie

să se facă la costuri cât mai sc ăzute, costuri care s ă fie inferioare
beneficiilor ob ținute;
• Reutilizarea înseamnă faptul că fondul de date existent trebuie s ă
poată fi reutilizat în diferite aplicaț ii informatice;
• Regăsirea este o actvitate frecvent ă pe bazele de date și de aceea
cererile de reg ăsire trebuie s ă poată fi adresate u șor de către toate
categoriile de utilizatori, dup ă diferite criterii;
• Accesul înseamn ă modul de localizare a datelor și acest lucru
trebuie să poată fi realizat prin diferite moduri de acces, rapid și
ușor;
• Modularizarea presupune faptul că realizarea BDR trebuie s ă se
poată face modular pentru generalitate și posibilitatea lucrului în
echipă;
• Protecția bazei de date trebuie asigurat ă sub ambele aspecte:
securitatea și integritatea datelor;
• Redundan ța se asigur ă în limite acceptabile prin implementarea
unui model de date pentru baze de date și prin utilizarea unei
tehnici de proiectare a BDR. Se asigur ă astfel, o redundanță
minimă și controlat ă;
• Independen ța datelor fa ță de programe trebuie asigurat ă atât la
nivel logic cât și și fizic.
Bazele de date rela ționale au evoluat ca un tip special de aplica ții
informatice, și anume cele care au organizarea datelor în memoria extern ă
conform unui model de date specific. De aceea, în metodologia de realizare
a BDR se parcurg, în cea mai mare parte, cam acelea și etape ca la realizarea
unei aplica ții informatice, cu o serie de aspecte specifice. Pe de alt ă parte, în
literatura de specialitate, sunt diferite propuneri de metodologii de realizare
a bazelor de date.
Ținând cont de cele dou ă aspecte de mai sus, sunt propuse câteva
actvivități care trebuie parcurse la real izarea unei baze de date. Aceste
activități vor fi regă site, sub aceeaș i denumire sau sub denumiri diferite, în
majoritatea metodologiilor de realizare a bazelor de date, din literatura de
specialitate.
Activitățile (etapele) parcurse pentru realizarea unei BDR sunt:
analiza de sistem, proiectarea noului sistem, realizarea componentelor
logice, punerea în func țiune, dezvoltarea.
1) Scopul analizei de sistem este de a eviden ția cerințele aplica ției și
resursele utilizate (studiul), precum și de a evalua aceste cerin țe prin
modelare (analiza).

Studiul situaț iei existente se realizeaz ă prin: definirea
caracteristicilor generale ale unit ății, identificarea activit ăților desfășurate,
identificarea resurselor existente (informa ționale, umane, energetice,
echipamente, financiare etc.), identificarea necesit ăților de prelucrare.
Analiza este o activitate de modelare (conceptual ă) și se realizeaz ă
sub trei aspecte: structural, dinamic și funcțional.
a) Analiza structural ă evidențiază, la nivel conceptual, modul de
structurare a datelor ș i a legăturilor dintre ele. Cea mai utilizat ă tehnică este
entitate-asociere . Aceasta con ține:
• Identificarea entit ăților: fenomene, procese, obiecte concrete sau
abstracte (substantivele din prezentarea activit ății descrise)
(exemple de entit ăți: Persoane, Produse, Beneficiari).
• Identificarea asocierilor dintre entit ăți ca fiind leg ăturile
semnificative de un anumit tip (verbele din prezentarea activit ății
descrise).
• Identificarea atributel or ce caracterizeaz ă fiecare entitate în parte
(exemple de atribute: Marca, Nume, Adres ă).
• Stabilirea atributelor de identificare unic ă a realiz ărilor entit ății,
drept chei.
Rezultatul analizei structurale este modelul static (structural) numit
și diagrama entitate-asociere. Diagrama entitate-asociere (Entity-
Relationship) poate fi generat ă cu produse software tip CASE (Computer
Aided Software Engineering), ca de exem plu Oracle Designer. Pornind de la
o astfel de diagram ă, se pot construi, în actvitatea de proiectare, schemele
relațiilor (tabelelor).
b) Analiza dinamic ă eviden țiază comportamentul elementelor
sistemului la anumite evenimente. Una din tehnicile utilizate este diagrama
stare-tranzi ție. Aceasta presupune:
• Identificarea st ărilor în care se pot afla componentele sistemului.
• Identificarea evenimentelor care determin ă trecerea unei
componente dintr-o stare în alta.
• Stabilirea tranzi țiilor admise între st ări.
• Construirea diagramei stare-tranzi ție.
Rezultatul analizei dinamice este modelul dinamic.
c) Analiza func țională evidențiază modul de asigurare a cerin țelor
informaționale (fluxul prelucr ărilor) din cadrul sistem ului, prin care intr ările
sunt transformate în ie șiri. Cea mai utilizat ă tehnică este diagrama de flux al
datelor. Conform acestei tehnici se delimiteaz ă:
• Aria de cuprindere a sistemului.
• Se identifică sursele de date.

• Se identifică modul de circula ție și prelucrare a datelor.
• Se identifică apoi rezultatele ob ținute.
Rezultatul analizei func ționale este modelul func țional.
2) Proiectarea structurii bazei de date se face pe baza modelelor
realizate în activitatea de analiz ă. Inainte de proiectar ea bazei de date se
alege tipul de sistem de gestiune a bazei de date. Alegerea SBGD-ului se
face ținând cont de dou ă aspecte: cerinț ele aplica ției (utilizatorului) ș i
performan țele tehnice ale SGBD-ului.
Cerințele aplica ției se refer ă la: volumul de date estimat a fi
memorat și prelucrat în BDR; complexitatea problemei de rezolvat;
ponderea și frecvența operaț iilor de intrare/ie șire; condi țiile privind protec ția
datelor; opera țiile necesare (înc ărcare/validare, actualizare, reg ăsire etc.);
particularit ățile activității pentru care se realizeaz ă baza de date.
Performan țele tehnice ale SGBD-ului se refer ă la: modelul de date
pe care-l implementeaz ă; ponderea utiliz ării SGBD-ului pe pia ță și tendința;
configuraț ia de calcul minim ă cerută; limbajele de programare din SGBD;
facilităț ile de utilizare oferite pentru diferite categorii de util izatori; limitele
SGBD-ului; optimiz ările realizate de SGBD; facilit ățile tehnice; lucrul cu
mediul distribuit și concuren ța de date; elementele multimedia;
instrumentele CASE; interfe țele de comunicare; posibilitatea de
autodocumentare; instrumentele specifice oferite.
Proiectarea BDR se realizeaz ă prin proiectarea schemelor BDR și
proiectarea modulelor func ționale specializate.
Schemele bazei de date sunt: conceptual ă, externă și internă.
a) Proiectarea schemei conceptuale pornește de la identificarea
setului de date necesar sistemului. Aceste date sunt apoi integrate și
structurate într-o schem ă (exemplu: pentru BDR rela ționale cea mai utilizat ă
tehnică este normalizarea ). Pentru acest lucru se parcurg pa șii:
• Stabilirea schemei conceptuale ini țiale care se deduce din modelul
entitate-asociere (vezi analiza structural ă). Pentru acest lucru, se
transform ă fiecare entitate din model într-o colec ție de date
(fișier), iar pentru fiecare asociere se definesc cheile aferente.
Dacă rezultă colecț ii izolate, acestea se vo r lega de alte colec ții
prin chei rezultând asocieri ( 1:1, 1:m, m:n) .
• Ameliorarea progresiv ă a schemei conceptuale prin eliminarea
unor anomalii (exemplu: cele cinci forme normale pentru BDR
relaționale).
• Stabilirea schemei conceptuale finale trebuie s ă asigure un
echilibru între cerin țele de actualizare și performan țele de
exploatare (exemplu: o form ă normală superioar ă asigură

performan țe de actualizare, dar timpul de r ăspuns va fi mai mare).
Tehnica de normalizare este utilizat ă în activitatea de proiectare a
structurii BDR și constă în eliminarea unor anomalii (neajunsuri) de
actualizare din structur ă.
Anomaliile de actualizare sunt situa ții nedorite care pot fi generate
de anumite tabele în procesul proiect ării lor:
• Anomalia de ștergere semnifică faptul că stergând un tuplu dintr-
o tabelă, pe lâng ă informațiile care trebuie ș terse, se pierd și
informațiile utile existente în tuplul respectiv;
• Anomaliile de ad ăugare semnific ă faptul că nu pot fi incluse noi
informații necesare într-o tabel ă, deoarece nu se cunosc și alte
informații utile (de exemplu valo rile pentru cheie);
• Anomalia de modificare semnific ă faptul că este dificil de
modificat o valoare a unui atri but atunci când ea apare în mai
multe tupluri.
Normalizarea este o teorie construit ă în jurul conceptului de forme
normale (FN), care ameliorează structura BDR prin înl ăturarea treptat ă a
unor neajunsuri și prin imprimarea unor facilit ăți sporite privind
manipularea datelor.
Normalizarea utilizeaz ă ca metod ă descompunerea (top-down) unei
tabele în dou ă sau mai multe tabele, p ăstrând informa ții (atribute) de
legătură.
FN1. O tabelă este în FN1 dac ă toate atributele ei con țin valori
elementare (nedecompozabile), adic ă fiecare tuplu nu trebuie s ă aibă date la
nivel de grup sau repetitiv . Structurile de tip arborescent și rețea se
transform ă în tabele cu atribute elemntare.
O tabelă în FN1 prezint ă încă o serie de anomalii de actualizare
datorită eventualelor dependen țe funcționale incomplete.
Fiecare structură repetitivă genereaz ă (prin descompunere) o nou ă
tabelă, iar atributele la nivel de grup se înl ătură, rămânând doar cele
elemntare.
FN2. O tabelă este în FN2 dac ă și numai dac ă este în FN1 și fiecare
atribut noncheie al tabelei este dependent func țional complet de cheie. Un
atribut B al unei tabele depinde func țional de atributul A al aceleiaș i tabele,
dacă fiecărei valori a lui A îi corespunde o singur ă valoare a lui B, care îi
este asociat ă în tabelă. Un atribut B este dependent funcț ional complet de un
ansamblu de atribute A în cadrul aceleia și tabele, dac ă B este dependent
funcțional de întreg ansamblul A (nu nu mai de un atribut din ansamblu).
O tabelă în FN2 prezint ă încă o serie de anomalii de actualizare,
datorită eventualelor dependen țe tranzitive.

Eliminarea dependen țelor incomplete se face prin descompunerea
tabelei ini țiale în două tabele, ambele con ținând atributul intermediar (B).
FN3. O tabelă este în FN3 dac ă și numai dac ă este în FN2 și fiecare
atribut noncheie depinde în mod netranzitiv de cheia tabelei. Într-o tabelă T,
fie A,B,C trei atribut e cu A cheie. Dac ă B depinde de A (A Æ B) și C
depinde de B (B Æ C) atunci C depinde de A în mod tranzitiv .
Eliminarea dependen țelor tranzitive se face prin descompunerea tabelei
inițiale în dou ă tabele, ambele con ținând atributul intermediar (B).
O tabelă în FN3 prezint ă încă o serie de anomalii de actualizare,
datorate eventualelor dependen țe multivaloare.
O definiție mai riguroas ă pentru FN3 a fost dată prin forma
intermediar ă BCNF (Boyce Codd Normal Form): o tabel ă este în BCNF
dacă fiecare determinant este un candi dat cheie.Determinantul este un
atribut elementar sau compus fa ță de care alte atribute sunt complet
dependente funcț ional.
FN4. O tabelă este în FN4 dac ă și numai dac ă este în FN3 ș i nu
conține două sau mai multe dependen țe multivaloare. Într-o tabel ă T, fie
A,B,C trei atribute. În tabela T se men ține dependen ța multivaloare A dac ă
și numai dac ă mulțimea valorilor lui B ce corespunde unei perechi de date
(A,C), depinde numai de o valoare a lui A și este independent ă de valorile
lui C.
FN5. O tabelă este în FN5 dac ă și numai dac ă este în FN4 și fiecare
dependen ță joncțiune este generat ă printr-un candidat ch eie al tabelei. În
tabela T (A,B,C) se men ține dependenț a joncțiune (AB, AC) dac ă și numai
dacă T menț ine dependen ța multivaloare A –>> B sau C.
Dependen ța multivaloare este caz particular al dependen ței
joncțiune. Dependen ța funcțională este caz particular al dependen ței
multivaloare.
b) Proiectare schemei externe are rolul de a sp ecifica viziunea
fiecărui utilizator asupra BDR. Pentru acest lucru, din schema conceptual ă
se identific ă datele necesare fiec ărei viziuni. Datele ob ținute se structureaz ă
logic în subscheme ț inând cont de facilităț ile de utilizare și de cerin țele
utilizator. Schema externă devine operaț ională prin construirea unor viziuni
(view) cu SGBD-ul și acordarea drepturilor de a cces. Datele într-o viziune
pot proveni din una sau mai multe colec ții și nu ocupă spațiul fizic.
c) Proiectarea schemei interne presupune stabilirea structurilor de
memorare fizic ă a datelor și definirea c ăilor de acces la date. Acestea sunt
specifice fie SGBD-ului (scheme de al ocare), fie sistemului de operare.
Proiectarea schemei interne înseamn ă estimarea spațiului fizic pentru BDR,
definirea unui model fizic de alocare (a se vedea dac ă SGBD-ul permite
explicit acest lucru) și definirea unor indecși pentru accesul direct, dup ă

cheie, la date.
Proiectarea modulelor funcț ionale ține cont de concep ția general ă a
BDR, precum și de schemele proiectate an terior. În acest sens, se
proiecteaz ă fluxul informa țional, modulele de înc ărcare și manipulare a
datelor, interfe țele specializate, integrarea elementelor proiectate cu
organizarea și funcționarea BDR.
3) Realizarea componentelor logice. Componentele logice ale unei
BD sunt programele de aplica ție dezvoltate, în cea mai mare parte, în
SGBD-ul ales. Programele se realizeaz ă conform modulelor func ționale
proiectate în etapa anterioar ă. Componentele logice țin cont de ie șiri, intrări,
prelucrări și colecțiile de date. În paralel cu dezvoltarea programelor de
aplicații se întocmesc și documenta țiile diferite (tehnic ă, de exploatare, de
prezentare).
4) Punerea în func țiune și exploatarea. Se testeaz ă funcțiile BDR
mai întâi cu date de test, apoi cu date reale. Se încarc ă datele în BDR și se
efectueaz ă procedurile de manipulare, de c ătre beneficiar cu asisten ța
proiectantului. Se definitiveaz ă documenta țiile aplica ției. Se intr ă în
exploatare curent ă de că tre beneficiar conform documenta țiiei.
5) Dezvoltarea sistemului. Imediat dup ă darea în exploatare a BDR,
în mod continuu, pot exista fact ori perturbatori care genereaz ă schimbări în
BDR. Factorii pot fi: organizatorici, datora ți progresului tehnic, rezulta ți din
cerințele noi ale beneficiarului, din schimbarea metodologiilor etc.

1.3. DEFINIREA SISTEMULUI DE GESTIUNE A BAZELOR DE
DATE RELAȚIONALE (SGBDR)

Teoria rela țională , foarte bine pusă la punct într-un domeniu de
cercetare distinct, a dat o fundamentare solid ă realizării de SGBD-uri
performante. La sfâr șitul anilor 80 și apoi în anii 90 au ap ărut, în special o
dată cu pătrunderea în mas ă a microcalculatoarelor, numeroase SGBDR-uri.
Aceasta a însemnat o evolu ție de la SGBD-urile de genera ția întâi
(arborescente și rețea) spre cele de genera ția a doua (rela ționale). Această
evoluție s-a materializat, în principal în: oferirea de limbaje de interogare
neprocedurale, îmbun ătățirea integrit ății și securității datelor, optimizarea și
simplificarea acceselor.
Teoria rela țională este un ansamblu de concepte, metode și
instrumente care a dat o fundamentare riguroas ă realizării de SGBDR
performante.
Paralela între conceptele utilizate în evolu ția organiz ării datelor în
memoria extern ă până la sistemele rela ționale este prezentata in tabelul 1.3:

Tabelul 1.3
FIȘIERE TEORIA BD TEORIA
RELAȚIONALĂ SGBDR
Fișier Colecție de date Relație Tabela
Înregistrare Familie de
caracteristici Tuplu Linie
Câmp Caracteristic ă Atribut Coloană
Valoare Domeniu de valori Domeniu Domeniu

Regulile lui Codd
E.F. Codd (cercet ător la IBM) a formul at 13 reguli care exprim ă
cerințele maximale pentru ca un SGBD s ă fie relațional. Regulile sunt utile
pentru evoluarea performan țelor unui SGBDR. Acestea sunt:
R0. Gestionarea datelor la nivel de rela ție: limbajele utilizate trebuie
să opereze cu rela ții (unitatea de informa ție).
R1. Reprezentarea logic ă a datelor: toate informa țiile din BDR
trebuie stocate și prelucrate ca tabele.
R2. Garantarea accesului la date: LMD trebuie s ă permită accesul la
fiecare valoare atomic ă din BDR (tabel ă, coloană, cheie).
R3. Valoarea NULL: trebuie s ă se permit ă declararea și prelucrarea
valorii NULL ca date lips ă sau inaplicabile.
R4. Metadatele: informa țiile despre descrierea BDR se stochează în
dicționar și tratează ca tabele ,la fel ca datele propiu-zise.
R5. Limbajele utilizate: SGBDR trebuie să permită utilizarea mai
multor limbaje, dintre care cel pu țin unul să permită definirea tabelelor (de
bază și virtuale), definirea restric țiilor de integritate, manipularea datelor,
autorizarea accesului, tratarea tranzac țiilor.
R6. Actualizarea tabelelor virtuale: trebuie s ă se permit ă ca tabelele
virtuale s ă fie și efectiv actualizabile, nu nu mai teoretic actualizabile
(exemplu atributul “v aloare” dintr-o tabel ă virtuală nu poate fi actualizat).
R7. Actualizările în baza de date: mani pularea unei tabele trebuie s ă
se facă prin opera ții de regăsire dar și de actulizare.
R8. Independen ța fizică a datelor: schimbarea stucturii fizice a
datelor (modul de reprezentare (organizare) și modul de ac ces) nu afecteaz ă
programele.
R9. Independen ța logică a datelor: schimbarea structurii de date
(logice) a tabelelor nu afecteaz ă programele.
R10. Restricțiile de integritate: acestea, trebuie s ă fie definite prin
LDD și stocate în dic ționarul (catalogul) BDR.
R11. Distribuirea geografic ă a datelor: LMD trebuie s ă permită ca

programele de aplica ție să fie acelea și atât pentru date distribuite cât și petru
date centralizate (alocarea și localizarea datelor vor fi în sarcina SGBDR-
ului).
R12. Prelucrarea datelor la nivel de baz ă (scă zut): dacă SGBDR
posedă un limbaj de nivel sc ăzut (prelucrarea datelor se face la nivel de
înregistrare), acesta nu trebuie utilizat pentru a evita restric țiile de
integritate.
Regulile lui Codd pot fi grupate, conform cerin țelor exprimate în
cinci categorii, conform tabelului 1.4 .

Tabelul 1.4 . Gruparea regulilor lui Codd
R0R1R2R3R4R5R6R7R8R9R10R11R12
1.Reguli de
bază (funda-
mentale) da da
2.Reguli structurale da da
3.Reguli privind integritatea datelor
da da
4.Reguli privind manipularea datelor
da da da da
5.Reguli privind independen ța
datelor da da da

Regulile lui Codd sunt greu de indeplinit în totalitate de c ătre
SGBDR. Pornind de la cele 13 reguli de mai sus, au fost formulate o serie
de criterii (cerin țe) pe care trebuie s ă le îndeplineasc ă un SGBD pentru a
putea fi considerat rela țional într-un anumit grad. S-a ajuns astfel, la mai
multe grade de rela țional pentru SGBDR: cu interfa ță relațională (toate
datele se reprezint ă în tabele, exist ă operatorii de selec ție, proiec ție și
joncțiune doar pentru interogare), pseudorelaț ional (toate datele se
reprezintă în tabele, există operatorii de selec ție, proiec ție și joncțiune fără
limitări), minimal rela țional (este pseudorela țional și în plus, opera țiile cu
tabele nu fac apel la pointeri observabili de utilizatori), complet rela țional
(este minimal rela țional și în plus, exist ă operatorii de re uniune, intersec ție
și diferență, precum și restricțiile de integritate privind unicitatea cheii și
restricția referen țială).
În concluzie, SGBDR este un sistem software complet care
implementez ă modelul de date rela țional și respectă cerințele impuse de
acest model. El este o interfa ță între utilizatori și baza de date.

1.4. CARACTERIZAREA SGBDR

Sistemele rela ționale îndeplinesc func țiile unui SGBD cu o serie de
aspecte specifi ce care rezult ă din definirea unui SGBDR.
Caracterizarea SGBDR se poate face pe dou ă niveluri: global
(sistemele rela ționale sunt privite ca o categorie distinct ă de SGBD) și
particular (fiecare SGBDR are aspecte individuale comparativ cu altele
similare).
A. Mecanismele și instrumentele care ajut ă la caracterizarea
globală a SGBDR-urilor s unt: limbajele rela ționale, protec ția datelor,
optimizarea cererilor de reg ăsire, utilitarele specializate.
1) Limbajele rela țional
SGBDR ofer ă seturi de comenzi pentru descrierea și manipularea
datelor. Acestea pot fi incl use într-un singur limbaj relaț ional (SQL, QUEL,
QBE, SQUARE, ALPHA, ISBL) sau separate în LDD ș i LMD. În ambele
situații, comenzile pentru definirea datelo r sunt distincte de cele pentru
manipularea datelor.
Limbajele rela ționale de definire a datelor (LDD) sunt simplificate,
cu puț ine comenzi. Descrierea datelor este memorat ă în BDR, sub form ă de
tabele, în dic ționarul (metabaza) ba zei de date. Facilit ăți de descriere sunt
prezente în SGBDR prin comenzi, care definesc anumite opera ții, la
nivelurile: conceptual, logic, fizic.
Limbajele rela ționale de manipulare a datelor (LMD) pot fi
caracterizate dup ă criterii generale, func ționale și calitative.
a) Caracterizarea general ă a LMD se face dup ă modul de tratare a
datelor, operatorii rela ționali, realizatorii și utilizatorii limbajului.
Modul de tratare a datelor. Toate LMD rela ționale realizeaz ă o
tratare la nivel de ansamblu a datelor: unitatea de informative pentru lucru
este tabela . Avantajele sunt date de posibilitatea gestion ării automat a
tuplurilor duplicate și prelucrarea paralel ă a ansamblurilor.
La comunicarea unui LMD relational cu un limbaj universal,
avantajele se pierd deoarece comunicarea se poate face doar tuplu cu tuplu
și nu la nivel de ansamblu. Deoa rece limbajele universale ofer ă alte
avantaje legate de proceduralitate, solu ția este de a integra în acestea un
limbaj rela țional. Cursorul este solu ția în SGBDR pentru a face trecerea de
la tratarea la nivel de ansamblu la cea la nivel de înregistrare (tuplu).
Operatorii rela ționali implementaț i. SGBDR s-au dezvoltat, din
punct de vedere rela țional, având la baz ă calculul rela țional orientat pe tuplu
(ALPHA, QUEL), calculul rela țional orientat pe domeniu (QBE), algebra
relațională (ISBL), transformarea (mapping) (SQL, SQUARE). Limbajele
bazate pe calculul rela țional sunt neprocedurale, cele bazate pe algebra

relațională sunt procedurale, celelalte sunt combina ții.
Realizatorii limbajelor rela ționale s-au orientat pe domenii precise
din teoria rela țională. Astfel, au rezultat: limbaje rela ționale standardizate
internațional (exemplu SQL – ANSI), limbaje cu standard de utilizare impus
de constructor (exemplu QUEL), limbaj e nestandardizate (celelalte limbaje
relaționale).
Utilizatorii limbajelor rela ționale sunt mu lt diversifica ți. SGBDR
oferă atât elemente procedurale (pentru speciali ști) cât și neprocedurale
(pentru nespecialil ști).
b) Caracterizarea func țională a LMD se face după facilitățile de
interogare, actualizare a datelor, etc.
Facilitățile de interogare a datelor. Acestea sunt puternice și oferite
prin comenzi pentru interogarea tabelelor de baz ă (exemplu SELECT) și
interogarea tabelelor virt uale (exemplu SELECT).
Facilitățile de actualizare a datelor. Acestea se refer ă la
actualizarea tabelelor de baz ă și a tabelelor virtuale prin comenzile: INSERT
INTO (adaugă rânduri la sfâr șitul unei tabele); UPDATE ( modific ă rânduri
dintr-o tabelă ); DELETE FROM ( șterge rânduri dintr-o tabel ă). Unele
SGBDR nu permit actualizarea tabelelor vi rtuale (exemplu Foxpro), altele
permit acces lucru cu o serie de restric ții pentru ca opera ția să se propage
spre tabelele de bază fără ambiguităț i (exemplu DB2, Oracle).
Alte facilit ăți funcționale . La facilit ățile relaționale de mai sus,
SGBDR-urile oferă și alte facilit ăți pe care le au toate limbajele de
programare procedurale cum sunt: calculu l aritmetic prin operatorii specifici
(+, -, *, /, **); agregarea prin func ții standard (SUM) și prin comenzi
(COMPUTE OF expr ); comenzi de intrare/ie șire standard
(ACCEPT…PROMPT…).
c) Caracterizarea calitativ ă a LMD se face dup ă puterea selectiv ă,
ușurința de învățare, utlizare și eficiența limbajului.
Puterea selectiv ă a LMD rela ționale este dat ă de posibilitatea
selectării datelor dup ă criterii (filtre) complexe (exemplu comanda
SELECT).
Ușurința de învățare și utilizare este nuan țată în funcție de tipul
LMD-ului rela țional. Cele bazate pe calculul rela țional sunt neprocedurale
(descriptive), deci u șor de înv ățat și utilizat (apropiat, ca stil, de limbajul
natural) (exemplu QUEL) iar cele bazate pe algebra rela țională sunt
procedurale (algoritmice), deci mai greu de înv ățat și utilizat (exemplu
ISBL). Cele intermediare promoveaz ă stilul neproce dural dar accept ă și
elemente de control procedural (exemp lu SQL) iar cele bazate pe grafic ă
oferă primitive grafice pentru machetarea cererilor de reg ăsire, deci u șor de
utilizat (exemplu QBE).

Eficiența utilizării este determinat ă de posibilitatea optimiz ării
cererilor de reg ăsire. LMD bazate pe calculul rela țional lasă compilatorul s ă
aleagă ordinea de execu ție a opera țiilor, deci rezult ă o eficien ța mare. LMD
bazate pe algebra rela țională au o ordine impus ă pentru execu ția operațiilor,
deci rezult ă o eficiență mica.
2) Protecția datelor
Aspectele privind protec ția datelor sunt foarte importante pentru un
sistem de baz ă de date și ele trebuie implementate de c ătre SGBDR.
Protecția bazei de date se refer ă la integritatea datelor (integritatea
semantică, concuren ța la date, salvarea/restaurarea) și securitatea datelor
(autorizarea accesului, viziunile, proc edurile speciale, criptarea).
a) Integritatea semantic ă. Definirea restricț iilor de integritate se
face, conform cerinț elor modelului rela țional, în LDD (exemplu CREATE
TABLE, ALTER TABLE). Utilizarea restricț iilor de integritate se face cu
ajutorul unor mecanisme care controleaz ă validitatea regulilor pentru fiecare
nouă stare a BD. Aceste mecanisme sunt metode de detectare a
inconsisten ței datelor (se verific ă restrcițiile de integritate) la sfâr șitul
tranzacțiilor, care se realizeaz ă automat de SGBDR și puncte de verificare a
integrității fixate de utili zator, acolo unde dore ște el în program.
b) Concuren ța la date (coeren ța). Unitatea de lucru pentru
asigurarea coeren ței datelor este tranzacția. Aceasta este un ansamblu de
comenzi tratate unitar. Tranzac ția se execută în totalitate sau deloc. Coeren ța
poate fi afectată la actualizarea concurent ă sau la incidente.
Mecanismele utilizate de SGBDR pent ru asigurarea coeren ței
datelor (controlul accesului concurent) sunt:
• Blocarea la diferite niveluri: baz ă de date, tabelă , tuplu, atribut;
• Definirea unor puncte de sa lvare în interiorul tranzac țiilor (exemplu
comanda savepoint);
• Tranzacții explicite (begin și end transaction) și implicite (comenzile
de actualizare);
• Fișiere jurnal.
3) Optimizarea reg ăsirii
Cererile de reg ăsire se exprim ă în SGBDR în diferite limbaje
relaționale. Pentru a se ob ține un rezultat op tim, se utilizeaz ă interfețe
automate de rescriere a cererilor de reg ăsire, prin parcurgerea a doi pa și:
• Exprimarea cererilor de reg ăsire sub forma unor expresii algebrice
relaționale, care are la baz ă echivalen ța dintre calculul ș i algebra
relațională .
• Aplicarea unor transform ări algebrice rela ționale asupra
expresiilor construite în pa sul anterior, pentru a se ob ține expresii

relaționale echivalente și eficiente.
Transformarea se poate realiza prin doua strategii de optimizare :
generale, specifice.
Strategiile generale sunt independente de modul de memorare a
datelor. Ele se bazeaz ă pe propietăț ile operațiilor din algebra rela țională
(comutativitatea, asociativ itatea, compunerea ). Astf el de strategii sunt:
selecția înaintea jonc țiunii, proiec ția înaintea jonc țiunii, selec ția înaintea
proiecției, combinarea selec ției multiple.
Strategiile specifice țin cont de modul de memorare a datelor și ele
sunt caracteristice unui SGBDR. Elementele care influen țează executarea
operațiilor ce intervin la o cerere de reg ăsire sunt: accesul direct, reguli de
ordonare a expresiilor algebr ice specifice unui SGBDR.
4) Utilitarele specializate
Posibilitatile de utilizare ale unui SGBDR sunt influen țate de
utilitarele specializate pe care le are, pentru diferitele categorii de utilizatori
(în Oracle: Developer pentru d ezvoltatori, Designer pentru anali ști,
Administration Tools și Utilities pentru admi nistrator etc.).
B. Pentru a face o caracterizare particular ă,un anumit SGBDR
vom lua în considerare o seri e de criterii de compara ție. Aceste criterii se
vor urmări, grupate pe anumite categorii, pentru câteva SGBDR-uri care ne
intereseaz ă. După această analiză vom avea un argument serios pentru a
putea alege un SGBDR în scopul dezvolt ării unei aplica ții cu baze de date.
Gruparea caracteristicilor particulare de compara ție a SGBDR-urilor
o vom face în func ție de facilit ățile de descriere, manipulare, utilizare și
administrare a datelor.
Caracteristicile în func ție de facilităț ile de descriere sunt: modul de
implementare a modelului rela țional; conceptul de baz ă de date utilizat în
schemă; definirea metadatelor; definirea rela țiilor virtuale; actualizarea
schemei rela ției; restric țiile de integritate ce pot fi declarate.
Caracteristicile în func ție de facilit ățile de manipulare sunt: LMD
relațional implementat; func țiile de calcul aritmetic și funcț iile agregate;
modurile de acces la date; programarea orientată -obiect; tratarea valorii
NULL; optimizarea cererilor de reg ăsire; actualizarea rela țiilor de baz ă și
virtuale.
Caracteristicile în func ție de facilit ățile de utilizare și administrare
sunt: instrumentele de dezvoltare; instrumentele CASE; instrumentele
analize statistice; software-ul pentru acces de la distan ță; utilitarele de
întreținere; mecanismele pentru au torizarea accesului la date.

Oracle . Este realizat de firma Oracle Corporation USA. Sistemul
este complet rela țional, robust, se bazeaz ă pe SQL standard extins.
Arhitectura sistemului este client/server, perm țând lucrul, cu obiecte și
distribuit. Are BD Internet și modul de optimizare a reg ăsirii. Ultima
versiune este Oracle 10g.
DB2. Este realizat de firma IBM. Sistemul respect ă teoria
relațională, este robust și se bazeaz ă pe SQL standard. Permite lucrul
distribuit și are modul de optimizare a regă sirii.
Informix. Este realizat de firma Informix, respect ă teoria rela țională
și permite lucru distribuit.
Progress. Este realizat de firma Progress Software. Are limbaj
propriu (Progress 4GL) dar suport ă și SQL. Ruleaz ă pe o gam ă largă de
calculatoare sub diferite sisteme de operare.
SQL Server. Este realizat de firma Microsoft. Se bazeaz ă pe SQL și
rulează în arhitectura client/server.
Ingress II. Este realizat de firma Co mputer Associates. Este un
SGBDR complet, implementeaz ă două limbaje rela ționale (întâi QUEL și
apoi SQL) și este suportat de diferite sist eme de operare (Windows, UNIX).
Lucrează distribuit în arhitectura clien t/server, are extensie cu facilit ăți
orientate obiect și permite aplica ții de tip Internet. Organizarea fizic ă a
tabelelor se face prin sistemul de operare.
Visual FoxPro . Este realizat de firma Microsoft. Are un limbaj
procedural propiu foarte puternic, o extensie orientată obiect, programare
vizuală și nucleu extins de SQL.
Access. Este realizat de fi rma Microsoft. Se bazeaz ă p e S Q L , a r e
limbajul procedural gazd ă (Basic Access) ș i instrumente de dezvoltare.
Paradox. Este realizat de firma Borland. Are limbaj procedural
propiu (PAL) și suportă SQL.

1.5. EXEMPLE DE SISTEME DE GESTIUNE A BAZELOR DE DATE
RELAȚIONALE