Cap.

3 MODELUL RELAIONAL AL BAZELOR DE DATE

Sistemele relaionale se bazeaz pe un formalism sau o teorie numit modelul de

date relaional. Adeseori, modelul relaional este descris ca avnd urmtoarele trei
caracteristici:
Caracteristica structural: datele din baza de date sunt percepute de utilizator sub
form de tabele i numai tabele.
Caracteristica de asigurare a integritii: aceste tabele satisfac anumite restricii
de integritate.
Caracteristica de asigurare a manipulrii: operatorii pui la dispoziie
utilizatorilor ca s manipuleze aceste tabele de exemplu, n scopul consultrii datelor
deriv tabele din alte tabele. Dintre aceti operatori, trei sunt deosebii de importani, i
anume: selecia (restricia), proiecia i uniunea.
O baz de date relaional simpl, cum este cea pentru departamente i angajai, este
prezentat n Figura 3.1. Dup cum se poate observa, baza de date este ntr-adevr
perceput sub form de tabele. n Figura 3.2 sunt prezentate cteva exemple de operaii
de restricie, proiecie i uniune efectuate n baza de date din Figura 3.1 mai jos sunt
prezentate (n mare) definiiile acestor operaii:
Operaia de restricie permite extragerea anumitor rnduri din tabel. Restricia
este numit i selecie; preferm termenul de restricie deoarece operatorul nu este identic
cu operaia SELECT din limbajul SQL.
Operaia de proiecie permite extragerea coloanelor specificate din tabel.
Operaia de uniune permite combinarea a dou tabele ntr-una singur, pe baza
valorilor comune din cadrul unei colane comune.

DEPT

DEPT# NUMED BUGET

D1 Marketing 10M
D2 Dezvoltare 12M
D3 Cercetare 5M

ANG

ANG# NUMEA DEPT# SALARIU

E1 Lopez D1 40K
E2 Cheng D1 42K
E3 Finzi D2 30K
E4 Saito D2 35K

Figura 3.1 Baza de date pentru departamente i angajai

1
Restricia tabelei DEPT unde BUGET > 8M

Rezultat:

DEPT# NUMED BUGET

D1 Marketing 10M
D2 Dezvoltare 12M

Proiecia tabelei DEPT dup DEPT#, BUGET

DEPT# BUGET

D1 10M
D2 12M
D3 5M

Uniunea tabelelor DEPT i ANG dup DEPT#

Rezultat:

DEPT# NUMED BUGET ANG# NUMEA SALARIU

D1 Marketing 10M E1 Lopez 40K

D1 Marketing 10M E2 Cheng 42K
D2 Dezvoltare 12M E3 Finzi 30K
D2 Dezvoltare 12M E4 Saito 35K

Figura 3.2 Operaiile de restricie, proiecie i uniune (exemple)

Dintre exemplele din Figura 3.2, singurul care necesit explicaii suplimentare
este cel de uniune. Uniunea necesit ca cele dou tabele s aib o coloan comun, aa
cum se ntmpl n cazul tabelelor DEPT i ANG (ambele au o coloan pentru DEPT#),
astfel nct pot fi unite pe baza valorilor comune din aceasta. Mai exact, un anumit rnd

2
din tabela DEPT va fi unit cu un anumit rnd din tabela ANG (pentru a produce un rnd
din tabela rezultat) dac i numai dac cele dou rnduri au o valoare comun pentru
DEPT#. De exemplu, rndurile DEPT i ANG:

DEPT# NUMED BUGET

D1 Marketing 10M

ANG# NUMEA DEPT# SALARIU

E1 Lopez D1 40K

sunt unite pentru a produce rndul rezultat:

DEPT# NUMED BUGET ANG# NUMEA SALARIU

D1 Marketing 10m E1 Lopez 40k

deoarece au aceeai valoare, D1, n coloana comun. Observm c valoarea comun

apare n rndul rezultat o singur dat, nu de dou ori. Rezultatul general al operaiei de
uniune conine toate rndurile posibile care pot fi obinute n acest mod i nici un alt rnd
suplimentar. Observm, n particular, c din moment ce nici un rnd din tabela ANG nu
are valoarea D3 n coloana DEPT# (adic nici un angajat nu este atribuit acestui
departament), n rezultat nu apare nici un rnd pentru valoarea D3, dei exist n tabela
DEPT un rnd care conine valoarea D3.
Un aspect prezentat clar n Figura 3.2 este c rezultatul fiecreia dintre cele trei
operaii este o alt tabel (cu alte cuvinte, operatorii sunt cu adevrat de tipul celor care
deriv tabele din tabele, aa cum am artat mai sus). Aceasta este proprietatea de
nchidere a sistemelor relaionale i este foarte important. n esen, deoarece rezultatul
oricrei ieiri este acelai tip de obiect ca intrarea toate sunt tabele ieirea unei
operaii poate deveni intrare pentru alt operaie. Astfel, este posibil, de exemplu, s se
efectueze o proiecie a unei uniuni, o uniune a dou restricii, o restricie a unei proiecii
etc. Cu alte cuvinte, se pot scrie expresii relaionale imbricate adic, expresii
relaionale n care operanzii nii sunt reprezentai prin expresii relaionale, nu neaprat
prin simple nume de tabele.
Exist nc dou aspecte care trebuie evideniate n legtur cu exemplul de baz
de date din Figura 3.1:
Sistemele relaionale necesit doar ca baza de date s fie perceput de utilizator
sub forma unor tabele. Tabela reprezint structura logic dintr-un sistem relaional, nu
structura fizic. De fapt, la nivel fizic, sistemul este liber s stocheze datele dup cum i
place - folosind fiiere secveniale, indexri, dispersri, nlnuiri de pointeri etc. doar
cu condiia s poat realiza corespondena dintre aceast reprezentare stocat i tabelele
de la nivelul logic. Putem exprima acelai lucru i prin faptul c tabelele reprezint o
abstractizare a modului n care datele sunt stocate fizic o abstractizare n care
numeroase detalii la nivel de stocare sunt ascunse fa de utilizator.
Bazele de date relaionale respect un principiu foarte interesant, numit principiul
informaiei: ntregul coninut informaional al bazei de date este reprezentat numai ntr-
un singur mod i anume, ca valori explicite ale coloanelor poziionate pe rndurile
unor tabele. Aceast metod de reprezentare este singura disponibil (la nivel logic,

3
desigur) ntr-un sistem relaional. n particular, nu exist pointeri, care s conecteze o
tabel cu alta. De exemplu, n Figura 3.1 exist o legtur ntre rndul D1 din tabela
DEPT i rndul E1 din tabela ANG, deoarece angajatul E1 lucreaz n departamentul D1.
Dar aceast legtur este reprezentat nu printr-un pointer, ci prin apariia valorii D1 n
poziia DEPT# din rndul ANG pentru valoarea E1. prin contrast, n sistemele
nonrelaionale, astfel de informaii sunt reprezentate, de obicei, printr-un tip oarecare de
pointer, care este vizibil explicit pentru utilizator.
Vom considera din nou baza de date pentru departamente i angajati, din Figura 3.1.
practic, ar putea fi necesar ca aceast baz de date s satisfac orice numr de restricii de
integritate de exemplu, salariile angajailor ar putea fi cuprinse ntre 25K i 95K,
bugetele departamentelor ar putea fi cuprinse ntre 1M i 15M, .a.m.d. Dar, cteva dintre
aceste restricii prezint o importan pragmatic att de mare nct se bucur de o
nomenclatur special. Mai exact:
1. Fiecare rnd din tabela DEPT trebuie s includ o valoare DEPT# unic; de
asemenea, fiecare rnd din tabela ANG trebuie s cuprind o valoare ANG# unic.
Spunem c cele dou coloane, DEPT# i ANG#, din tabelele DEPT, respectiv ANG, sunt
chei primare pentru tabelele respective.
2. Fiecare valoare DEPT# din tabela ANG trebuie s existe ca valoare DEPT# n tabela
DEPT, pentru a reflecta faptul c fiecare angajat trebuie atribuit unui departament
existent. Spunem c n tabela ANG, coloana DEPT# este o cheie strin, care se refer la
cheia primar a tabelei DEPT.
Sistemele relaionale se bazeaz pe modelul relaional. La rndul su, modelul
relaional este o teorie abstract despre date, care se bazeaz pe anumite aspecte
matematice (n principal, teoria mulimilor i logica predicatelor).
Principiile modelului relaional au fost stabilite iniial n perioada 1969-70, de
ctre E.F. Codd, pe atunci cercettor la IBM. La sfritul anului 1968, Codd un
matematician prin formaie a descoperit c matematica ar putea fi utilizat pentru a
insera o serie de principii solide i riguroase ntr-un domeniu (gestiunea bazelor de date)
care, nainte de acel moment, era mult prea deficitar n aceast privin. Ideile lui Codd
au fost expuse pe larg prima dat n cadrul unui articol, devenit acum clasic, intitulat A
Relational Model of Data for Large Shared Data Banks.
De atunci, aceste idei acum aproape universal acceptate au avut o influen
larg n aproape fiecare aspect al tehnologiei bazelor de date, ca i n alte domenii, cum ar
fi inteligena artificial, prelucrarea n limbaj natural i proiectarea sistemelor hardware.
n modelul relaional, aa cum a fost formulat iniial de ctre Codd, erau utilizai
anumii termeni cum ar fi cel de relaie, tuplu, atribut. Termenul de tuplu corespunde
aproximativ noiunii de rnd, tot aa cum termenul de relaie corespunde aproximativ
noii de tabel. n acelai context, modelul relaional nu utilizeaz termenul de cmp; n
schimb folosete termenul de atribut, care putem spune c ar corespunde aproximativ
noiunii de coloan dintr-o tabel.

Tupluri

Vom ncepe prin a defini termenul de tuplu. Considerm o mulime nevid de

simboluri, notat cu U, ale crei elemente se vor numi nume de atribute.

4
 Fie U={A1, A2, , An}. Pentru fiecare nume de atribut Ai se asociaz un tip Ti
,i=1,2, , n, unde Ti nu sunt neaprat distincte. Un tuplu t este o mulime de triplete
ordonate, de forma <Ai, Ti, vi>, unde Ai este numele unui atribut, Ti este numele unui tip
iar vi este o valoare de tipul Ti.
Valoarea n reprezint gradul sau aritatea lui t.
Tripletul ordonat < Ai, Ti, vi> este o component a lui t.
Perechea ordonat < Ai, Ti> este un atribut al lui t i este identificat n mod unic
de ctre numele atributului Ai (numele atributelor Ai i Aj sunt aceleai numai dac i=j).
Valoarea vi este valoarea atributului Ai al lui t. Tipul Ti este tipul atributului
corespunztor.
Mulimea complet de atribute este antetul lui t.
Mai jos este prezentat un exemplu de tuplu:

MAJOR_C# : C# MINOR_C : C# CANT : CANT

C2 C4 7

Aici numele atributelor sunt MAJOR_C#, MINOR_C# i CANT; numele tipurilor

corespunztoare sunt C#, C# i Cant; valorile corespunztoare sunt C2, C4, i 7.
Gradul acestui tuplu este trei. Antetul s este:

MAJOR_C# : C# MINOR_C : C# CANT : CANT

Observaie n contextele lipsite de formalism, se obinuiete s se omit numele

din antetul tuplului, indicnd doar numele atributelor. Prin urmare, mai puin formal, am
putea reprezenta tuplul anterior astfel:

MAJOR_C# MINOR_C CANT

Proprietile tuplurilor:
Fiecare tuplu conine exact o valoare (de tipul adecvat) pentru fiecare dintre
atributele sale.
Nu exist o ordonare de la stnga la dreapta a componentelor tuplului. Aceast
proprietate se datoreaz faptului c tuplul este definit ca o mulime de componente iar n
matematic, mulimile nu au o ordine a elementelor.
Fiecare submulime a unui tuplu este un tuplu (iar fiecare submulime a unui antet
este un antet).
Dou tupluri t1 i t2 sunt egale (adic expresia t1=t2 este adevrat) dac i numai
dac au aceleai atribute A1, A2, , An i, pentru toi indicii i (i=1,2, , n), valoarea vi1 a
lui Ai din t1 este egal cu valoarea vi2 a lui Ai din t2.
Tuplurile t1 i t2 sunt duplicate dac i numai dac sunt egale.

Relaii

5
 O relaie este o mulime de tupluri toate avnd acelai antet. Cardinalitatea
mulimii de tupluri este cardinalitatea relaiei r (n general, cardinalitatea unei mulimi
reprezint numrul de elemente ale acesteia).

O relaie este format dintr-un antet i un cuprins.

Antetul relaiei r este antetul unui tuplu, aa cum a fost definit anterior. Relaia
are aceleai atribute (i prin urmare, aceleai nume i tipuri de atribute) i acelai grad ca
i acest antet.
Cuprinsul relaiei r este mulimea de valori ale tuplurilor.

Mai jos este prezentat un exemplu de relaie :

MAJOR_C# : C# MINOR_C : C# CANT : CANT

C1 C2 5
C1 C3 3
C2 C3 2
C2 C4 7
C3 C5 4
C4 C6 8

n contextele lipsite de formalism, se obinuiete s se omit numele tipurilor din

antetul relaiei, indicnd doar numele atributelor. Prin urmare, am putea reprezenta relaia
anterioar astfel:

MAJOR_C# MINOR_C CANT

C1 C2 5
C1 C3 3
C2 C3 2
C2 C4 7
C3 C5 4
C4 C6 8

Proprietile relaiilor:
Fiecare tuplu conine exact o valoare (de tipul adecvat) pentru fiecare atribut.
Nu exist ordonare a atributelor de la stnga la dreapta.
Nu exist o ordonare a tuplurilor de jos n sus.
Nu exist tupluri duplicat.

Relaii i tabele

n acest subparagraf vom prezenta o list a ctorva dintre deosebirile principale

dintre obiectul formal reprezentat de o relaie i obiectul neformal reprezentat de o tabel,
care constituie o imagine neformal, pe hrtie, a acestui obiect formal.
Fiecare atribut din antetul unei relaii presupune un nume al tipului, dar aceste
nume de tipuri sunt omise din imaginile sub form de tabel.

6
 Fiecare component a fiecrui tuplu din cuprinsul unei relaii presupune un nume
i un tip al atributului, dar acestea sunt omise din imaginile sub form de tabel.
Coloanele unei tabele au o ordine de la stnga la dreapta, dar atributele unei relaii
nu.
Rndurile unei tabele au o ordine de sus n jos, dar tuplurile unei relaii nu.
O tabel poate conine rnduri duplicat, dar o relaie nu conine tupluri duplicat.
Tabelele sunt considerate ca avnd cel puin o coloan, n timp ce nu este
obligatoriu ca relaiile s aib cel puin un atribut.
Tabelele cel puin n limbajul SQL pot cuprinde null-uri, n timp ce relaiile nu.
Din toate cele de mai sus, rezult c, pentru a putea accepta faptul c o imagine de
forma unei tabele poate fi privit ca reprezentnd o relaie, trebuie s cdem de acord
privind modul de citire a unei stfel de imagini; cu alte cuvinte, trebuie s acceptm
anumite reguli de interpretare a cestor imagini. Mai exact, trebuie s acceptm c, pentru
fiecare coloan exist un tip aflat la baz; c fiecare valoare a unui atribut este o valoare
de tipul adecvat; c ordonrile rndurilor i ale coloanelor nu sunt relevante i c nu sunt
permise rnduri duplicat.
Acum putem vedea c tabela i relaia nu sunt chiar acelai lucru (dei, adeseori,
este comod s pretindem c ar fi). n schimb, relaia este ceea ce arat definiia sa, adic
un tip de obiect abstract, n timp ce tabela este o imagine concret, de regul pe hrtie, a
unui astfel de obiect abstract. Ele nu sunt acelai lucru.
Un avantaj major al modelului relaional const n aceea c obiectul d de baz
abstract relaia are o reprezentare att de simpl pe hrtie. Aceast reprezentare
simpl este cea care face ca sistemele relaionale s fie uor de utilizat i de neles i cea
care face ca nelegerea modului de comportare a sistemelor relaionale s fie simpl.