12

Capitolul 1:Modelul rela!ional

Modelul rela!ional reprezint" datele sub forma unor structuri bidimensionale, asem"n"toare
tabelelor. Apari!ia sa s-a datorat nevoii de a u#ura concep!ia, accesarea #i procesarea datelor.
Modelele de date existente anterior (ierarhic #i re!ea) erau extrem de complexe #i necesitau personal
extrem de specializat pentru a concepe #i a naviga n baza de date. De asemenea, datorit" faptului c"
performan!ele acestor tipuri de baze de date erau dependente de proiectarea #i designul lor, pentru a
asigura o performan!" corespunz"toare trebuia investit foarte mult efort n activitatea de proiectare.
Aceste motive f"ceau ca disponibilitatea de personal adecvat s" fie foarte limitat". n plus, datorit"
complexit"!ii lor, sistemele care foloseau aceste modele erau foarte greu de instalat. n sfr#it, dar
nu n ultimul rnd, modelele ierarhice #i re!ea necesitau ca programatorul aplica!iei s" cunoasc"
implementarea fizic" a bazei de date (leg"turile existente ntre nregistr"ri) #i cuno#tin!e despre
limbajul de manipulare a datelor corespunz"tor.

Modelul rela!ional este o solu!ie pentru rezolvarea acestor probleme. De#i sistemul software necesar
unui model rela!ional este foarte complex, nv"!area limbajului de definire a datelor #i a celui de
manipulare a datelor necesit" mult mai pu!in timp #i efort dect cele corespunz"toare modelelor
ierarhic #i re!ea. De asemenea, proiectarea unui sistem care folose#te modelul rela!ional este
flexibil", astfel nct modific"rile sunt destul de u#or de implementat, reducndu-se astfel efortul
corespunz"tor fazei de proiectare a bazei de date. n plus, simplitatea modelului rela!ional #i a
limbajului sau de manipulare a datelor permite utilizatorilor s" execute propriile lor manipul"ri.

Conceptele teoretice care formeaz" baza modelului rela!ional au ap"rut la nceputul anilor 70, n
principal datorit" lui Edgar F. Codd. Acest model difer" de modelele precedente prin aceea c" nu se
bazeaz" pe dependen!ele de secven!" #i cale. Modelele existente anterior permiteau accesul la date
prin c"i specificate de o schem". Cum programele asociate depindeau de c"ile diferitelor nregistr"ri
din baza de date, dac", datorit" unei schimb"ri de design, calea de acces pentru o nregistrare se
schimba, era necesar" #i modificarea programului de acces la datele respective, pentru a lua n
considerare aceast" schimbare. Pe de alt" parte, modelul rela!ional nu folose#te c"ile de acces n
structura sa logic" sau n limbajul sau de manipulare a datelor. De asemenea, n modelele ierarhic #i
re!ea datele puteau fi accesate n mai mult de o secven!", iar programele de aplica!ie utilizau
secven!a respectiv" a datelor. Evident, dac" secven!a datelor era schimbat", programul trebuia
schimbat pentru a lua n considerare noua secven!". Modelul rela!ional nu utilizeaz" o anumit"
secven!" n structura sa logic" sau n limbajul s"u de manipulare. Aceast" independen!" sporit" a
datelor permite o tranzi!ie mai u#oar" la noi rela!ii ntre date.

Modelul rela!ional nu este orientat spre sistemul de calcul, adic" modelul nu include regulile,
structurile #i opera!iile referitoare la implementarea fizic" a unui sistem de baze de date. De fapt,
unul dintre principalele obiective ale sistemului rela!ional este separarea clar" ntre aspectele fizice
#i cele logice ale unei baze de date. Spre deosebire de modelele men!ionate anterior, utilizatorul
poate ob!ine date specifice din modelul rela!ional folosind un limbaj ne-procedural care i permite
s" descrie datele cerute n loc de naviga!ia folosit".

n acela#i timp, modelul rela!ional #i opera!iile folosite de c"tre acesta au la baz" o riguroas"
fundamentare matematic"; s-au creat algebra rela!ional" #i calculul rela!ional. Totu#i, pe lng"
avantajele clare ale rigurozit"!ii matematice, matematizarea excesiv" a modelului #i a limbajului de
manipulare creeaz" o problem" datorit" faptului c" n afara mediului academic doar un procent mic
de utilizatori au preg"tirea necesar" pentru a le n!elege. Din fericire, folosirea modelului rela!ional
nu necesit" neap"rat n!elegerea n profunzime a matematicii pe care este bazat. Opera!iile de
manipulare a datelor pot fi privite ca o serie de opera!ii de proiec!ie, filtrare, reuniune, intersec!ie,
etc. asupra datelor din tabele.

13
De#i are la rndul lui imperfec!iuni, modelul rela!ional a devenit n ultima vreme principalul model
de baze de date #i a fost adoptat de majoritatea produc"torilor de software din acest domeniu.
Principalele sale avantaje sunt simplitatea, fundamentarea matematic" riguroas" #i independen!a
datelor, adic" separarea aspectelor logice ale acestora de cele fizice.
1.1. Concepte de baz" ale modelului rela!ional

n general, definirea unui model de date presupune precizarea #i identificarea urm"toarelor
elemente:
Structurile de date folosite
Operatorii care ac!ioneaz" asupra structurilor de date
Restric!iile care trebuie impuse pentru men!inerea corectitudinii datelor, numite #i restric!ii de
integritate.
Aceast" sec!iune prezint" pe larg fiecare dintre aceste componente ale modelului rela!ional.

n modelul rela!ional datele sunt reprezentate ca structuri bidimensionale, numite rela!ii. O rela!ie
este alc"tuit" dintr-un num"r fix de elemente numite atribute, fiecare dintre acestea putnd lua
valori ntr-o mul!ime finit", numit" domeniu. Num"rul de atribute al unei rela!ii se nume#te aritatea
rela!iei.

rela!ie (atribut_1, atribut_2, ..., atribut_n)

De exemplu datele despre angaja!ii unei firme se pot reprezenta ca o rela!ie de aritate 7, dup" cum
urmeaz":

salariat (cod_salariat, nume, prenume, adresa, dat"_na#tere, sex, cod_departament)

Elementele unei rela!ii se numesc tupluri sau nregistr"ri. De obicei rela!iile sunt reprezentate sub
forma unor tabele, n care fiecare rnd reprezint" un tuplu #i fiecare coloan" reprezint" valorile
tuplurilor corespunz"toare unui anumit atribut.

salariat
cod_
salariat
nume prenume Adresa dat"_na#tere sex cod_
departament
S1 Ion Cosmin Str. Jiului Nr.3 01/01/1970 M D1
S2 Popescu Vasile 15/11/1956 M D1
S3 Ionescu Gina Str. Valea Alb" Nr.4 28/02/1976 F D2
S4 Costache Viorel Str. Cri#ana Nr. 11 12/02/1975 M D1

Rela!iile ce constituie o baz" de date trebuie s" satisfac" mai multe condi!ii, dup" cum urmeaz":

1. Fiecare atribut trebuie s" poarte un nume, care este unic n cadrul rela!iei. Modelul rela!ional nu
permite ca dou" atribute din cadrul aceleia#i rela!ii s" poarte acela#i nume. Pe de alt" parte, este
posibil ca dou" atribute din dou" rela!ii diferite s" poarte acela#i nume.

2. Fiecare atribut poate avea doar valori atomice, deci care nu se pot descompune din punct de
vedere logic. S" presupunem, de exemplu, c" un produc"tor de automobile atribuie fiec"rui
automobil fabricat un cod de identificare, care se ob!ine prin concatenarea mai multor coduri,
reprezentnd marca automobilului, culoarea, fabrica unde este produs, seria #i num"rul de
fabrica!ie, etc. Atunci, definirea acestui cod de identificare ca atribut al unei rela!ii ar nc"lca
14
aceast" regul", deoarece fiecare valoare a atributului s-ar putea descompune n mai multe valori
cu semnifica!ie logic".

3. Fiecare tuplu este unic. Nu sunt permise tupluri identice (duplicat). n plus, unicitatea unui tuplu
nu este limitat" la datele existente: fiecare tuplu trebuie s" fie unic tot timpul.

Aceasta nseamn" c" ntr-o rela!ie exist" ntotdeauna unul sau mai multe atribute care asigur" c"
tuplul va r"mne unic tot timpul. Un atribut sau set de atribute care identific" n mod unic un tuplu
se nume#te cheie candidat" sau mai simplu cheie. Pentru fiecare rela!ie se alege din mul!imea
cheilor candidate o cheie care se nume#te cheie primar" a rela!iei. Eventualele alte chei candidate,
diferite de cheia primar", se numesc chei alternative. Cnd mai mult de un singur atribut este
necesar pentru a crea o cheie, se spune c" avem o cheie compus". n cazul unei chei compuse,
atributele care fac parte din cheie sunt alese astfel nct nici unul s" nu fie n plus, adic" nici un
atribut nu poate fi #ters din cheia candidat" astfel nct partea din cheia candidat" care r"mne s"
identifice nc" n mod unic tuplurile; de aceea, se spune c" o cheie trebuie sa fie minimal".

Uneori, n unele tupluri dintr-o rela!ie, un atribut poate fi necunoscut sau neaplicabil. Pentru a
reprezenta un astfel de atribut se folose#te o valoare conven!ional", notat" cu Null. Ca regul"
general", nici unul dintre atributele care alc"tuiesc cheia primar" nu poate avea valoarea Null pentru
nici unul din tuplurile rela!iei.

Exemplu:
Pentru rela!ia salariat definit" mai sus, o cheie candidat" este cod_salariat. Dac" se
presupune c" nume, prenume #i dat!_na"tere identific" n mod unic salariatul, atunci
combina!ia acestor trei atribute este o alt" cheie candidat", care, datorit" faptului c" este alc"tuit"
din mai multe atribute, se nume#te #i cheie compus". Dac" cheia cod_salariat este aleas" cheie
primar", atunci combina!ia celor trei atribute (nume, prenume #i dat!_na"tere) devine cheie
alternativ".
n alegerea cheilor candidate s-a !inut cont de principiul minimalit"!ii n sensul c" din cheia
compus" nume, prenume #i dat!_na"tere nu poate fi #ters nici un atribut #i nici nu mai
trebuie ad"ugat altul, aceste trei atribute identificnd n mod unic tuplurile. De exemplu, combina!ia
(nume, prenume, dat!_na"tere, cod_departament) nu este o cheie a rela!iei salariat
pentru c" #i n absen!a atributului cod_departament, un salariat este identificat n mod unic de
primele trei atribute. Observ"m c" tuplul identificat prin valoarea cheii primare egal" cu S2 are
atributul adresa necunoscut, adic" acesta are valoarea Null. Prin urmare, atributul adresa nu
poate fi cheie primar" #i nici nu poate intra n componen!a unei chei compuse care este #i cheie
primar".

Se nume#te cheie str"in" un atribut sau o mul!ime de atribute ale unei rela!ii R1 care exist" #i ntr-o
alt" rela!ie R2, nu neap"rat distinct" de R1, #i care formeaz" cheia primar" a rela!iei R2. n cazul
acesta, cheia str"in" din R1 se spune c" face referin!" la cheia primar" din R2. Valorile pe care le ia
cheia str"in", dac" nu sunt nule, trebuie s" se g"seasc" printre valorile cheii primare la care face
referin!".

Exemplu:
Dac" mai definim o rela!ie de aritate 3, dup" cum urmeaz":

departament (cod_departament, denumire, localitate)

cod_departament denumire localitate
D1 Analiz" financiar" Bucure#ti
15
D2 Depozit Pite#ti
D3 Contabilitate Constan!a
D4 Magazin Pite#ti

pentru eviden!a departamentelor din firm", atributul cod_departament din rela!ia salariat
devine cheie str"in" care face referin!" la cheia primar" a rela!iei departament. Valoarea cheii
str"ine cod_departament din rela!ia salariat trebuie ori s" fie ori Null, ori s" coincid" cu o
valoare a cheii primare la care face referin!". Prin urmare, dac" atributul cod_departament din
rela!ia salariat ar fi avut pentru un anumit tuplu valoarea D5, valoare ce nu se reg"se#te printre
valorile cheii primare cod_departament din rela!ia departament, atunci s-ar fi nc"lcat o
regul" de integritate.

Exist" posibilitatea ca o cheie str"in" s" fac" referin!" la cheia primar" a propriei rela!ii. Pentru a
ilustra acest lucru, s" ad"ug"m la rela!ia salariat un nou atribut cod_manager, reprezentnd
codul superiorului ierarhic al salariatului (facem presupunerea c" un angajat poate avea cel mult un
superior ierarhic).

cod_
salariat
nume prenume . . . . . cod_manager
S1 Ion Cosmin . . . . .
S2 Popescu Vasile . . . . . S1
S3 Ionescu Gina . . . . . S1
S4 Costache Viorel . . . . . S2

Deci salariatul cu codul S1 este superiorul ierarhic al salaria!ilor cu codurile S2 #i S3, salariatul cu
codul S2 este superiorul ierarhic al salariatului cu codul S4, iar S1 nu are un superior ierarhic.

4. Naviga!ia n cadrul modelului rela!ional se face prin intermediul valorii pe care o ia un atribut.
Aceasta nseamn" c" limbajul de interogare va prelua ca parametri de intrare doar numele unor
atribute #i valorile posibile ale acestora, corespunz"toare cerin!ei utilizatorului, #i va returna
tuplurile care satisfac aceast" cerin!". Spre deosebire de alte modele, nu exist" leg"turi ntre
tupluri #i deci nu exist" dependen!" de calea urmat".

5. Tuplurile pot fi prezentate utilizatorului n orice ordine. Deci acesta nu trebuie s" fac" nici o
presupunere n privin!a ordinii tuplurilor.

6. Atributele pot fi prezentate n orice ordine, deci utilizatorul nu trebuie s" fac" nici o presupunere
n privin!a ordinii acestora. Cu alte cuvinte, n modelul rela!ional nu exist" dependen!" de
secven!". De exemplu, de#i rela!iile

Salariat (cod_salariat, nume, prenume, adresa, dat"_na#tere, sex, cod_departament)
#i
Salariat (cod_salariat, nume, prenume, cod_departament, dat"_na#tere, sex, adresa)

par diferite, ele sunt echivalente func!ional pentru c" au atribute identice, chiar dac" sunt n alt"
ordine.

7. Rela!iile pot fi manipulate pentru a furniza utilizatorului diferite vederi asupra datelor, rezultatul
fiind noi rela!ii. Cu alte cuvinte, rezultatul manipul"rii rela!iilor sunt noi rela!ii. n plus, rela!iile
produse ca rezultat al comenzilor limbajului de interogare a datelor satisfac toate regulile la care
sunt supuse rela!iile ini!iale.
16
1.2. Constrngeri de integritate

Pentru asigurarea integrit"!ii datelor, o baz" de date trebuie s" satisfac" un num"r de constrngeri,
numite constrngeri de integritate. Constrngerile de integritate ale modelului rela!ional se pot
mp"r!i n dou" clase: constrngeri structurale, care trebuie satisf"cute de orice baz" de date care
folose#te modelul rela!ional #i constrngeri de comportament, care sunt specifice fiec"rei baze de
date particulare.

Constrngerile de integritate structurale exprim" propriet"!i fundamentale, inerente modelului
rela!ional #i sunt n general specificate la definirea bazei de date, ca parte a schemei bazei de date.
n modelul rela!ional exist" dou" tipuri de constrngeri structurale: de entitate #i de referin!". Ele au
fost men!ionate mai nainte, cnd am vorbit despre propriet"!ile sistemului rela!ional, f"r" ns" a le
men!iona explicit numele.

1. Integritatea entit"!ii: O cheie primar" nu poate con!ine atribute ce pot avea valoarea Null. n plus,
prin ns"#i defini!ia unei chei primare, ea trebuie s" fie unic" #i minimal".

2. Integritatea referirii: Valoarea unei chei str"ine trebuie ori s" fie ori Null, ori s" coincid" cu o
valoare a cheii primare la care face referin!".

Aceste dou" tipuri de constrngeri pot fi impuse n Oracle prin simpla lor ad"ugare la defini!ia
tabelelor respective, vezi sec!iunea 6.1.3.

Constrngerile de integritate de comportament sunt specifice unei anumite baze de date #i !in cont
de semnifica!ia valorilor atributelor din baza respectiv". De exemplu, constrngerile de domeniu
restric!ioneaz" valorile unui atribut la o anumit" mul!ime, iar constrngerile sintactice se pot referi
la tipul datelor, lungimea atributelor, etc. Constrngerile de comportament pot exprima leg"turi
ntre valorile unor atribute diferite, de exemplu valoarea unui atribut este dependent" de valoarea
altui atribut sau set de atribute sau o expresie format" din valorile mai multor atribute trebuie s" se
ncadreze n anumite limite, etc.

Constrngerile de comportament pot fi impuse n Oracle fie prin ad"ugarea lor la defini!ia tabelelor
(vezi sec!iunea 6.1.3), fie prin definirea unor secven!e de program, numite declan#atori (triggers)
care sunt ata#ate tabelelor #i care intr" n ac!iune la nc"lcarea acestor constrngeri, mpiedicnd
opera!iile care ar duce la nc"lcarea integrit"!ii (vezi sec!iunea 9.16).
1.3. Operatorii sistemului rela!ional

n afara rela!iilor #i a propriet"!ilor acestora, modelul rela!ional este definit #i prin setul de opera!ii
care se pot efectua asupra acestor rela!ii. Exist" dou" moduri de descriere matematic" a acestor
operatori, #i anume algebra rela!ional" #i calculul rela!ional, vezi [3] [Basca97].

Algebra rela!ional", introdus" de c"tre Codd, este format" dintr-o mul!ime de opt operatori, ce
ac!ioneaz" asupra rela!iilor #i genereaz" tot o rela!ie. Operatorii algebrei rela!ionale sunt fie
operatorii tradi!ionali pe mul!imi (UNION, INTERSECT, DIFFERENCE, PRODUCT), fie
operatori rela!ionali speciali (PROJECT, SELECT, JOIN, DIVISION). Cum ie#irea generat" de
fiecare dintre ace#ti operatori este tot o rela!ie, este posibil" combinarea #i compunerea lor. Cinci
dintre operatori (PROJECT, SELECT, DIFFERENCE, PRODUCT, UNION) sunt operatorii
primitivi ai limbajului, iar ceilal!i trei (JOIN, DIVISION, INTERSECT) sunt operatori deriva!i,
putnd fi defini!i n func!ie de primii. Unii dintre operatori se aplic" unei singure rela!ii (operatori
unari), iar al!ii opereaz" asupra a dou" rela!ii (operatori binari).
17

Calculul rela!ional reprezint" o adaptare a calculului predicatelor la domeniul bazelor de date
rela!ionale. Ideea de baz" este de a identifica o rela!ie cu un predicat. Pe baza unor predicate ini!iale,
prin aplicarea unor operatori ai calculului cu predicate (conjunc!ia, disjunc!ia, nega!ia,
cuantificatorul existen!ial #i cel universal) se pot defini noi predicate, adic" noi rela!ii.

Algebra rela!ional" #i calculul rela!ional sunt echivalente unul cu cel"lalt, n sensul c" orice rela!ie
care poate fi definit" n algebra rela!ional" poate fi definit" #i n calculul rela!ional #i reciproc.
1.3.1 Algebra rela!ional" #i limbajul SQL

n prezent, limbajul dominant folosit pentru interogarea bazelor de date rela!ionale este SQL
(Structured Query Language), care este un limbaj bazat pe opera!iile algebrei rela!ionale. Cu alte
cuvinte, orice operator al algebrei rela!ionale poate fi descris folosind comanda SELECT a
limbajului SQL cu diverse clauze. n ceea ce urmeaz" vom defini operatorii algebrei rela!ionale #i
vom exemplifica modul de implementare a acestor operatori n SQL. Pentru o explica!ie a sintaxei
comenzii SELECT din limbajul SQL vezi sec!iunea 8.1.

Not": Comanda SELECT din limbajul SQL nu reprezint" acela#i lucru #i nu trebuie confundat" cu
operatorul SELECT din algebra rela!ional".

Operatorul PROJECT (proiec!ia)

Acesta este un operator unar care are ca parametri un atribut sau mai multe atribute ale unei rela!ii #i
care elimin" din rela!ie toate celelalte atribute, producnd o submul!ime pe vertical" a acesteia.
Datorit" faptului c" suprimarea unor atribute poate avea ca efect apari!ia unor tupluri duplicate,
acestea vor fi eliminate din rela!ia rezultat" deoarece, prin defini!ie, o rela!ie nu poate con!ine
tupluri cu valori identice. Nota!iile folosite de obicei pentru acest operator sunt !
X
(R) #i
PROJECT(R, X) unde R reprezint" rela!ia, iar X este atributul sau mul!imea de atribute care
constituie parametrii proiec!iei.

Exemplu
R A B C C A !
C,A
(R) C A
x1 y1 z1 z1 x1 z1 x1
x1 y1 z2
Proiec!ie
z2 x1
Eliminare duplicate
z2 x1
x1 y2 z2 z2 x1 z1 x2
x2 y2 z1 z1 x2

n SQL, proiec!ia f"r" dubluri se ob!ine folosind comanda SELECT cu specifica!ia DISTINCT:

SELECT DISTINCT C, A
FROM R;

n cazul folosirii comenzii SELECT f"r" clauza DISTINCT se va ob!ine proiec!ia cu dubluri:

SELECT C, A
FROM R;

Operatorul SELECT (selec!ia)

18
Acesta este un operator unar care este utilizat pentru extragerea tuturor tuplurilor dintr-o rela!ie care
satisfac o condi!ie specificat", producnd astfel o submul!ime pe orizontal" a rela!iei. Condi!ia
este o formul" logic" ce poate con!ine nume de atribute, constante, operatori logici (AND, NOT,
OR), operatori de compara!ie (<, =, >, <=, >=, !=). Spre deosebire de alte limbaje de programare,
cum ar fi Pascal, limbajul SQL acord" operatorilor de compara!ie o prioritate mai mare dect
operatorilor logici, reducndu-se astfel num"rul de paranteze necesare pentru expresii complexe.
Nota!iile folosite de obicei pentru acest operator sunt "
C
(R) sau SELECT(R, C), unde R reprezint"
rela!ia, iar C este condi!ia care trebuie satisf"cut" de tuplurile selectate.

Exemplu
R A B C "
A=x1 OR B=y1
(R) A B C
x1 y1 z1 x1 y1 z1
x1 y1 z2

x1 y1 z2
x1 y2 z2 x1 y2 z2
x2 y2 z1


n SQL, selec!ia se ob!ine folosind comanda SELECT cu clauza WHERE:

SELECT *
FROM R
WHERE A = x1 OR B = y1;

Combinarea selec!iei cu proiec!ia f"r" dubluri se face n modul urm"tor:

SELECT DISTINCT C, A
FROM R
WHERE A = x1 OR B = y1;

R A B C A B C C A
x1 y1 z1 x1 y1 z1 z1 x1
x1 y1 z2
selec!ie
x1 y1 z2
proiec!ie cu
z2 x1
x1 y2 z2 x1 y2 z2
eliminarea duplicatelor

x2 y2 z1


Combinarea selec!iei cu proiec!ia cu dubluri se face n modul urm"tor:

SELECT C, A
FROM R
WHERE A = x1 OR B = y1;

R A B C A B C C A
x1 y1 z1 x1 y1 z1 z1 x1
x1 y1 z2
selec!ie
x1 y1 z2
proiec!ie f"r"
z2 x1
x1 y2 z2 x1 y2 z2
eliminarea duplicatelor
z2 x1
x2 y2 z1


PRODUCT (produsul cartezian)

19
Acesta este un operator binar. Produsul cartezian a dou" rela!ii R #i S este mul!imea tuturor
tuplurilor care se ob!in prin concatenarea unui tuplu din R cu un tuplu din S. Prin urmare, dac"
aritatea rela!iei R este m, iar aritatea rela!iei S este n, atunci produsul cartezian dintre R #i S va avea
aritatea m + n. Nota!iile folosite de obicei pentru acest operator sunt R # S, PRODUCT(R, S),
TIMES(R, S).

Exemplu
R A B C S D E R # S A B C D E
x1 y1 z1 z1 u1 x1 y1 z1 z1 u1
x2 y1 z2

z2 u2

x1 y1 z1 z2 u2
x3 y2 z1

x2 y1 z2 z1 u1
x2 y1 z2 z2 u2
x3 y2 z1 z1 u1
x3 y2 z1 z2 u2

Produsul cartezian poate fi exprimat n SQL printr-o comand" SELECT pe mai multe tabele f"r"
clauza WHERE:

SELECT *
FROM R, S;

Compatibilitate la reuniune
Dou" rela!ii R #i S se numesc compatibile la reuniune dac" ele con!in acela#i num"r de atribute (au
aceea#i aritate) #i atributele cu acela#i num"r de ordine din fiecare rela!ie au acela#i domeniu din
care pot lua valori. Operatorii UNION, INTERSECT, DIFFERENCE, prezenta!i n continuare, sunt
operatori binari ce nu pot fi aplica!i dect asupra rela!iilor compatibile la reuniune.


UNION (reuniunea)

Reuniunea a dou" rela!ii R #i S este mul!imea tuplurilor apar!innd fie lui R, fie lui S. Reuniunea
celor dou" mul!imi va cuprinde fiecare tuplu o singur" dat", chiar dac" el face parte din amndou"
mul!imile. Reuniunea se poate aplica doar rela!iilor compatibile la reuniune. Nota!iile folosite de
obicei pentru acest operator sunt R $ S sau UNION(R, S). Reuniunea este o opera!ie binar"
comutativ", adic" R $ S = S $ R.

Exemplu
R A B S C D R $ S A B
x1 y1 x1 y1 x1 y1
x2 y1

x1 y2

x2 y1
x3 y1

x3 y1
x1 y2

n SQL reuniunea se poate exprima folosind operatorul UNION:

SELECT A, B
FROM R
UNION
SELECT C, D
FROM S;

20

DIFFERENCE (diferen!a)

Diferen!a a dou" rela!ii R #i S este mul!imea tuplurilor care apar!in lui R, dar nu apar!in lui S.
Diferen!a este o opera!ie binar" ne-comutativ", adic" R S % S R, care se poate aplica doar
rela!iilor compatibile la reuniune. Nota!iile folosite de obicei pentru acest operator sunt R - S,
DIFFERENCE(R, S), MINUS(R, S).

Exemplu
R A B S C D R S A B
x1 y1 x1 y1 x2 y1
x2 y1

x1 y2

x3 y1
x3 y1



n SQL diferen!a se poate exprima folosind operatorul MINUS:

SELECT A, B
FROM R
MINUS
SELECT C, D
FROM S;

n plus, diferen!a poate fi simulat" #i prin operatorul NOT EXISTS. De exemplu, comanda SQL de
mai sus este echivalent" cu urm"toarea:

SELECT A, B
FROM R
WHERE NOT EXISTS
(SELECT *
FROM S
WHERE R.A = S.C AND R.B = S.D);

Not": Pentru simplitate, n comanda SQL de mai sus am presupus c" nici un atribut din rela!iile R
sau S nu poate avea valoarea Null. Dac", de exemplu, atributul A din rela!ia S #i atributul C din
rela!ia S pot avea valoarea Null, atunci expresia R.A = S.C trebuie nlocuit" cu R.A = S.C OR (R.A
IS NULL AND S.C IS NULL). Acest lucru se datoreaz" faptului c" n SQL, expresia NULL =
NULL are valoarea False.

INTERSECT (intersec!ia)

Intersec!ia a dou" rela!ii R #i S este mul!imea tuplurilor care apar!in att lui R ct #i lui S. Intersec!ia
este o opera!ie binar" comutativ" care se poate aplica doar rela!iilor compatibile la reuniune.
Nota!iile folosite de obicei pentru acest operator sunt R & S, INTERSECT(R, S), AND(R, S).
Intersec!ia este un operator derivat, putnd fi exprimat cu ajutorul reuniunii #i diferen!ei: R & S = R
(R S) sau R & S = S (S R)

Exemplu
R A B S C D R & S A B
x1 y1 x1 y1 x1 y1
x2 y1

x1 y2


x3 y1


21

n SQL diferen!a se poate exprima folosind operatorul INTERSECT:

SELECT A, B
FROM R
INTERSECT
SELECT C, D
FROM S;

n plus, intersec!ia poate fi simulat" #i prin operatorul EXISTS. De exemplu, comanda SQL de mai
sus este echivalent" cu urm"toarea:

SELECT A, B
FROM R
WHERE EXISTS
(SELECT *
FROM S
WHERE R.A = S.C AND R.B = S.D);

n cazul cnd operatorii UNION, DIFFERENCE sau INTERSECT se aplic" unor rela!ii care sunt
ob!inute prin selec!ie din aceea#i rela!ie, atunci ace#tia pot fi simula!i prin aplicarea operatorilor
logici corespunz"tori (OR, AND NOT, AND) asupra condi!iilor de selec!ie. De exemplu,
urm"toarele comenzi sunt echivalente:

SELECT A, B
FROM R
WHERE A = x1
MINUS
SELECT A, B
FROM R
WHERE B = y1;

SELECT A, B
FROM R
WHERE A = x1 AND NOT B = y1;

DIVISION (diviziunea)

Diviziunea este o opera!ie binar" care se aplic" asupra a dou" rela!ii R #i S, astfel nct mul!imea
atributelor lui R include mul!imea atributelor lui S. Dac" R este o rela!ie cu aritatea m, iar S o rela!ie
cu aritatea n, unde m > n, atunci diviziunea lui R la S este mul!imea tuplurilor de dimensiune m n
la care, ad"ugnd orice tuplu din S, se ob!ine un tuplu din R. Nota!iile utilizate cel mai frecvent sunt
R S, DIVISION(R, S), DIVIDE(R, S).

Exemplu
R A B C S C R S A B
x1 y1 z1 z1 x1 y1
x1 y2 z1

z2


x1 y1 z2


x2 y1 z2


x2 y2 z2


22

Diviziunea este o opera!ie derivat" care se exprim" cu ajutorul diferen!ei, produsului cartezian #i
proiec!iei: R S = R
1
R
2
, unde R
1
= !
X
(R), R
2
= !
X
((R
1
# S) R), iar X este mul!imea
atributelor lui R care nu exist" n S. Pentru exemplul de mai sus:

R
1
A B R
1
# S A B C (R
1
# S) - R A B C
x1 y1 x1 y1 z1 x2 y1 z1
x1 y2 x1 y2 z1 x2 y2 z1
x2 y1 x2 y1 z1 x1 y2 z2
x2 y2 x2 y2 z1
x1 y1 z2
x1 y2 z2
x2 y1 z2
x2 y2 z2

R
2
A B R
1
R
2
A B
x2 y1 x1 y1
x2 y2


x1 y2

Operatorul DIVISION este legat de cuantificatorul universal (') care nu exist" n SQL, dar care
poate fi simulat cu ajutorul cuantificatorului existen!ial ((), care exist" n SQL, utiliznd rela!ia: ' x
P(x) ) NOT ( x NOT P(x). Pentru a ilustra exprimarea operatorul DIVISION n cele dou" moduri
(folosind cuantificatorul universal #i cuantificatorul existen!ial), s" consider"m rela!iile
student_curs #i curs_fundamental de mai jos:

curs_student curs_fundamental
cod_student Curs curs
S1 matematica matematica
S1 Fizica fizica
S1 Mecanica
S2 matematica
S2 informatica
S3 Fizica
S4 matematica
S4 Fizica

curs_student curs_fundamental
curs
S1
S4

Atunci rela!ia curs_student curs_fundamental poate fi definit" prin urm"toarea
ntrebare: care sunt studen!ii care urmeaz" toate cursurile fundamentale? Alternativ, aceast" rela!ie
poate fi definit" prin ntrebarea: care sunt studen!ii pentru care nu exist" curs fundamental care s"
nu fie urmat de c"tre ace#tia? Utiliznd a doua formulare, rezult" c" operatorul DIVISION poate fi
simulat n SQL prin doi operatori NOT EXISTS:

SELECT DISTINCT cod_student
FROM curs_student cs1
23
condi!ie
WHERE NOT EXISTS
(SELECT *
FROM curs_fundamental cf
WHERE NOT EXISTS
(SELECT *
FROM curs_student cs2
WHERE cf.curs = cs2.curs
AND cs1.cod_student = cs2.cod_student));

JOIN (compunerea, jonc!iunea)

Operatorul de compunere permite reg"sirea informa!iei din mai multe rela!ii corelate. Compunerea
este o opera!ie binar" care are ca rezultat o nou" rela!ie n care fiecare tuplu este o combina!ie a
unui tuplu din prima rela!ie cu un tuplu din a doua rela!ie.

Operatorul JOIN este un operator derivat, putnd fi simulat printr-o combina!ie de produs cartezian,
selec!ie #i proiec!ie. n general, se construie#te un produs cartezian, se elimin" tupluri prin selec!ie #i
se elimin" atribute prin proiec!ie. Dup" modalit"!ile n care se face selec!ia #i proiec!ia, se disting
mai multe tipuri de compunere: THETA-JOIN, NATURAL-JOIN, SEMI-JOIN, OUTER-JOIN.
Fiecare dintre acestea vor fi prezentate n continuare.

THETA-JOIN

Operatorul THETA-JOIN combin" perechile de tupluri din dou" rela!ii, cu condi!ia ca ntre valorile
atributelor specificate s" existe o anumit" leg"tur", adic" s" satisfac" o anumit" condi!ie specificat"
explicit n cadrul opera!iei. n cadrul condi!iei operatorului THETA-JOIN se poate folosi orice
operator de compara!ie (>, >=, <, <=, <>, =). n cazul n care este folosit operatorul de compara!ie
=, tipul de compunere se nume#te EQUI-JOIN. Operatorul THETA-JOIN se reprezint" de obicei cu
ajutorul simbolului sub care se scrie condi!ia, R S sau prin JOIN(R, S, condi!ie).

Exemplu
R A B C S D E

R S
C < D
A B C D E
x1 y1 1 2 z1 x1 y1 1 2 z1
x2 y2 3

4 z2

x1 y1 1 4 z2
x3 y3 5

x2 y2 3 4 z2

Urm"torul exemplu ilustreaz" realizarea operatorului THETA-JOIN n SQL:

SELECT *
FROM R, S
WHERE R.C < S.D;

NATURAL-JOIN (Compunerea natural")

Compunerea natural" este o opera!ie binar" comutativ" care combin" tupluri din dou" rela!ii, R #i S,
cu condi!ia ca atributele comune s" aib" valori identice. n cazul compunerii naturale atributele
specificate trebuie s" aib" acela#i nume. Practic diferen!a dintre NATURAL-JOIN #i EQUI-JOIN
const" n faptul c" n primul caz numele atributelor sunt identice iar n cel de al doilea caz acestea
sunt diferite. De obicei, compunerea natural" se noteaz" prin R S sau JOIN(R, S).

24
Pentru dou" rela!ii R #i S, compunerea natural" pe un set de atribute comune X const" n efectuarea
succesiv" a urm"toarelor opera!ii:
1. Se calculeaz" produsul cartezian R # S.
2. Se selecteaz" din R # S acele tupluri ob!inute pentru care valorile atributelor X din tuplul R sunt
identice cu valorile atributelor X din tuplul S.
3. Deoarece n rela!ia astfel ob!inut" atributele X apar de dou" ori (o dat" provenind din R #i o dat"
din S), se elimin" una dintre apari!iile acestor atribute.

Exemplu
lucr!tor atelier
nr_lucr"tor cod_sec!ie nr_atelier cod_sec!ie nr_atelier denumire
1 S1 1 S1 1 Proiectare
2 S1 2 S1 2 Informatica
3 S2 1 S2 1 Mecanica
4 S1 2 S2 2 Electrotehnica
5 S1 1

lucr!tor atelier
nr_lucr"tor cod_sec!ie nr_atelier denumire
1 S1 1 Proiectare
2 S1 2 Informatica
3 S2 1 Mecanica
4 S1 2 Informatica
5 S1 1 Proiectare

n exemplul de mai sus, {cod_sec#ie, nr_atelier} este cheie primar" n tabelul atelier #i
cheie str"in" n tabelul lucr!tor.

Urm"torul exemplu ilustreaz" realizarea compunerii naturale n SQL:

SELECT lucr"tor.nr_lucr"tor, lucr"tor.cod_sec!ie, lucr"tor.nr_atelier, atelier.denumire
FROM lucr"tor, atelier
WHERE lucr"tor.cod_sec!ie = atelier.cod_sec!ie
AND lucr"tor.nr_atelier = atelier.nr_atelier;

SEMI-JOIN (semi-compunerea)

Opera!ia de semi-compunere aplicat" asupra a dou" rela!ii R #i S genereaz" o rela!ie care con!ine
toate tuplurile din R corelate cu oricare din tuplurile din S. Opera!ia nu este comutativ" #i se noteaz"
de obicei prin SEMI-JOIN(R, S).

Exemplu
R A B C S B C D

SEMIJOIN(R, S) A B C
x1 y1 z1 y1 z1 u1 x1 y1 z1
x2 y1 z1

y2 z2 u2

x2 y1 z1
x3 y2 z1 y2 z2 u3

x4 y2 z2
x4 y2 z2



Urm"torul exemplu ilustreaz" realizarea compunerii naturale n SQL:

SELECT DISTINCT R.A, R.B, R.C
25
FROM R, S
WHERE R.B = S.B
AND R.C = S.C

OUTER-JOIN (compunere extern")

Opera!ia de compunere extern" este o extindere a compunerii naturale. n cazul aplic"rii
operatorului NATURAL-JOIN se pot pierde tupluri atunci cnd exist" un tuplu ntr-una din rela!ii
care nu este corelat cu nici un tuplu din cealalt" rela!ie. Operatorul OUTER-JOIN elimin" acest
inconvenient. Practic, la aplicarea operatorului OUTER-JOIN, se realizeaz" compunerea natural" a
celor dou" rela!ii, la care se adaug" tuplurile din S care nu sunt con!inute n compunere, completate
cu valori Null pentru atributele r"mase din R. Operatorul se noteaz" cu OUTERJOIN(R, S). Exist"
#i alte variante ale acestui operator, de exemplu o alt" variant" adaug" la tuplurile ob!inute din
compunerea natural" a lui R #i S att tuplurile din R care nu sunt con!inute n compunere ct #i
tuplurile din S care nu sunt con!inute n compunere, completnd restul cu Null. n mod evident,
aceast" variant" a operatorului se poate ob!ine cu u#urin!" din varianta prezentat" de noi. Operatorul
OUTER-JOIN, n varianta prezentat" de noi, este ne-comutativ.

Exemplu:
student facultate
nr_stud nume Prenume cod_facult cod_facul
t
nume_facult localitate
1 Popescu Ion F1 F1 Matematica Bucure#ti
2 Ionescu Vasile F1 F2 Fizica Bucure#ti
3 Ionescu Viorel F2 F3 Informatica Pite#ti
4 Costache Ion F2 F4 Mecanica Ploie#ti
5 Matache Mihai F1

OUTERJOIN (student, facultate)
nr_stud nume Prenume cod_facult nume_facult localitate
1 Popescu Ion F1 Matematica Bucure#ti
2 Ionescu Vasile F1 Matematica Bucure#ti
3 Ionescu Viorel F2 Fizica Bucure#ti
4 Costache Ion F2 Fizica Bucure#ti
5 Matache Mihai F1 Matematica Bucure#ti
Null Null Null F3 Informatica Ploie#ti
Null Null Null F4 Mecanica Ploie#ti

n versiunea SQL folosit" de Oracle, operatorul OUTER JOIN este specificat prin sufixul (+)
ad"ugat la cmpul dup" care se face compunerea, corespunz"tor tuplului ale c"rui atribute pot fi
completate cu Null:

SELECT student.nume_stud, student.nume, student.prenume,
facultate.cod_facult, facultate.nume_facult, facultate.localitate
FROM student, facultate
WHERE student.cod_facult (+) = facultate.cod_facult;

1.4 Tabele, rnduri, coloane

26
Modelul rela!ional este bazat pe matematica rela!ional" #i acest lucru se reflect" n terminologia pe
care am prezentat-o pn" acum. Pe de alt" parte, folosirea acestui model n economie, unde
conceptele matematice sunt foarte pu!in sau deloc utilizate #i n!elese, a necesitat o nou"
terminologie. A#a c", odat" cu preluarea modelului rela!ional de c"tre economie are loc o
transformare a terminologiei rela!ionale ntr-una care poate fi u#or n!eleas" de cei f"r" o preg"tire
special" n domeniu. Pentru cei care nu sunt exper!i n procesarea datelor, rela!iile devin tabele,
tuplurile devin rnduri #i atributele devin coloane. Acesta este #i terminologia pe care o vom folosi
n continuare n aceast" carte.
1.5. Sisteme de Gestiune a Bazelor de Date Rela!ionale (SGBDR).

n principiu, un sistem de gestiune a bazelor de date rela!ionale (SGBDR) este un SGBD care
utilizeaz" drept concep!ie de organizare a datelor modelul rela!ional. n mod evident ns", aceast"
defini!ie este mult prea general" pentru a putea fi folosit" n practic", deoarece modul de
implementare a modelului rela!ional difer" de la un produc"tor la altul. n 1985, Codd a publicat un
set de 13 reguli n raport cu care un SGBD poate fi apreciat ca rela!ional. Trebuie remarcat c" nici
un SGBD comercializat n prezent nu satisface n totalitate regulile lui Codd, dar aceasta nu
mpiedic" etichetarea acestora drept rela!ionale. Cu alte cuvinte, regulile lui Codd nu trebuie
folosite pentru a aprecia dac" un sistem este sau nu rela!ional, ci m"sura n care acesta este
rela!ional, adic" num"rul regulilor lui Codd respectate de c"tre acesta.
1.5.1. Regulile lui Codd

Regula 1. Regula reprezent"rii logice a datelor:
ntr-o baz" de date rela!ional", toate datele sunt reprezentate la nivel logic ntr-un singur mod, #i
anume sub form" de valori atomice n tabele.

Deci toate datele trebuie memorate sub form" de tabele, iar valoarea corespunz"toare intersec!iei
dintre un rnd #i o coloan" trebuie s" fie atomic", adic" s" nu mai poat" fi descompus" din punct de
vedere logic. A#a cum am discutat mai nainte, un exemplu de nc"lcare a acestei reguli este
stocarea ca o singur" coloan" a unui cod al automobilului, ob!inut prin concatenarea mai multor
coduri, reprezentnd marca automobilului, culoarea, fabrica unde este produs, seria #i num"rul de
fabrica!ie, etc. Uneori aceast" regul" este nc"lcat" n practic", dar acest lucru este de cele mai multe
ori semnul unui design de calitate slab", crend probleme de integritate a bazei de date.

Aceast" regul" este cea mai important" dintre cele definite de Codd, iar un SGBD care nu respect"
aceast" regul" nu poate fi n nici un caz considerat rela!ional.

Regula 2. Regula accesului la date:
Toate datele individuale din tabele trebuie s" fie accesibile prin furnizarea numelui tabelului,
numelui coloanei #i valorii cheii primare.

Conform modelului rela!ional, ntr-un tabel nu pot exista rnduri identice, iar fiecare rnd poate fi
identificat prin valoarea cheii primare. n consecin!", orice dat" individual" poate fi identificat"
folosind numele tabelului, al coloanei #i valoarea cheii primare. Oracle nu respect" aceast" regul"
deoarece permite existen!a a mai multe rnduri identice n acela#i tabel. Totu#i, acest lucru poate fi
evitat, de exemplu prin definirea unei chei primare, care elimin" implicit #i posibilitatea existen!ei
rndurilor identice. Pe de alt" parte, aceast" regul" este nc"lcat" n Oracle #i de existen!a
identificatorului de rnd, ROWID, care poate fi folosit pentru accesarea rndului respectiv.

Regula 3. Regula reprezent"rii valorilor necunoscute:
27
Un sistem rela!ional trebuie s" permit" declararea #i manipularea sistematic" a valorilor Null, cu
semnifica!ia unor valori necunoscute sau inaplicabile.

Aceast" regul", implic", de exemplu, c" un SGBDR trebuie s" fac" diferen!a ntre valoarea
numeric" 0 #i Null sau ntre #irul de caractere spa!iu #i valoarea Null. Valoarea Null trebuie s"
reprezinte absen!a informa!iei respective #i are un rol important n implementarea restric!iilor de
integritate structural" (integritatea entit"!ii #i integritatea referirii). Oracle respect" aceast" regul",
limbajul SQL permi!nd declararea #i manipularea valorilor Null.

Regula 4. Regula dic!ionarului de date:
Descrierea bazei de date (dic!ionarul de date) trebuie s" fie reprezentat" la nivel logic tot sub
form" de tabele, astfel nct asupra acesteia s" se poat" aplica acelea#i opera!ii ca #i asupra
datelor propriu-zise.

Cu alte cuvinte, dic!ionarul de date trebuie s" fie organizat la nivel logic #i accesat la fel ca orice
tabel din baza de date. Aceast" regul" este respectat" de c"tre Oracle, dic!ionarul de date constnd
din tabele #i tabele virtuale (vederi) care pot fi interogate la fel ca oricare alte tabele sau vederi,
folosind comanda SELECT.

Regula 5. Regula limbajului de acces:
ntr-un sistem rela!ional trebuie s" existe cel pu!in un limbaj de accesare a datelor, care s" asigure
urm"toarele opera!ii: definirea tabelelor de baz" #i a tabelelor virtuale (vederilor), manipularea #i
interogarea datelor (att interactiv ct #i prin program), definirea restric!iilor de integritate,
autorizarea accesului la date, delimitarea tranzac!iilor.

Limbajul SQL folosit de c"tre Oracle permite definirea tabelelor (comenzile CREATE TABLE,
ALTER TABLE, DROP TABLE), a vederilor (comenzile CREATE VIEW, ALTER VIEW, DROP
VIEW), manipularea (comenzile INSERT, UPDATE, DELETE) #i interogarea acestora (comanda
SELECT), definirea restric!iilor de integritate (clauza CONSTRAINT folosit" la definirea
tabelelor), autorizarea accesului la date (printr-un set de privilegii de sistem #i la nivel de obiect),
delimitarea tranzac!iilor (opera!iile COMMIT #i ROLLBACK).

Regula 6. Regula de actualizare a tabelelor virtuale (vederilor).
Un SGBD trebuie s" poat" determina dac" o vedere poate s" fie actualizat" sau nu.

Un tabel virtual (vedere) este un tabel logic, n sensul c" el organizeaz" datele sub forma unor
rnduri #i coloane, ca orice alt tabel, dar n schimb el nu stocheaz" datele, fiind construit pe baza
unor interog"ri asupra unuia sau mai multor tabele de baz". De exemplu s" consider"m tabelul :

salariu(cod_salariat, salariu_brut, zile_totale, zile_lucrate).

Pe baza acestui tabel se poate defini vederea

salariu_r(cod_salariat, salariu_brut, salariu_realizat)

unde salariu_realizat este definit ca

salariu_realizat = salariu_brut*zile_totale/zile_lucrate.

S" presupunem acum c" se dore#te actualizarea coloanei salariu_brut din vedere. Acest lucru este
posibil, datorit" faptului c" actualizarea se propag" napoi la coloana din tabelul de baz",
producndu-se #i actualizarea acesteia. Pe de alt" parte, nu este posibil" actualizarea coloanei
28
salariu_realizat, datorit" faptului c" schimbarea valorii acesteia s-ar putea produce datorit"
schimb"rii valorilor mai multor coloane (salariu_brut, zile_totale sau zile_lucrate), SGBD-ul
ne#tiind care din aceste coloane trebuie actualizat" n tabelul de baz". Oracle respect" aceast"
regul", existnd un set de reguli care determin" dac" o coloan" a unei vederi poate sau nu s" fie
actualizat".

Regula 7. Regula manipul"rii datelor:
Un sistem rela!ional trebuie s" ofere posibilitatea proces"rii tabelelor (de baz" sau virtuale) nu
numai n opera!iile de interogare a datelor ct #i n cele de inserare, actualizare #i #tergere.

Aceasta nseamn" c" opera!iile de manipulare a datelor (inserare, actualizare #i #tergere) trebuie s"
se poat" efectua asupra oric"rei mul!imi de rnduri dintr-un tabel, pornind de la ntregul tabel #i
terminnd cu un singur rnd sau cu nici unul. Deci, un SGBD rela!ional nu oblig" utilizatorul s"
caute ntr-un tabel rnd cu rnd pentru a reg"si, modifica sau #terge informa!ia dorit", deoarece
opera!iile prin care se manipuleaz" con!inutul bazei de date lucreaz" la nivel de mul!ime de rnduri.
Limbajul SQL asigur" aceast" facilitate prin instruc!iunile: INSERT cu subinterogare, UPDATE #i
DELETE (vezi sec!iunile 8.2, 8.3 #i 8.4).

Regula 8. Regula independen!ei fizice a datelor:
Programele de aplica!ie nu trebuie s" depind" de modul de stocare #i accesare fizic" a datelor.

Deci un SGBD rela!ional trebuie s" separe complet aspectele de ordin fizic ale datelor (modul de
stocare #i modul de acces la date) de cele de ordin logic. Cu alte cuvinte, programele de aplica!ie nu
trebuie s" depind" de stocarea fizic" a datelor. De exemplu, dac" un fi#ier care con!ine un tabel de
date este mutat pe o alt" unitate de disc sau i este schimbat numele, aceasta nu trebuie s" aib" vreun
efect asupra aplica!iilor care folosesc acel tabel, utilizatorilor fiindu-le transparent" aceast"
schimbare. n mare, Oracle respect" aceast" regul", de#i stocarea fizic" a datelor trebuie luat" n
considera!ie la proiectarea bazei de date.

Regula 9. Regula independen!ei logice a datelor:
Programele de aplica!ie nu trebuie s" fie afectate de nici o restructurare logic" a tabelelor bazei de
date care conserv" datele.

Deci orice modificare efectuat" asupra unui tabel care conserv" datele din acesta (de exemplu, dac"
un tabel trebuie divizat n dou", din ra!iuni de cre#tere a performan!elor) nu trebuie s" afecteze
func!ionarea programelor de aplica!ie. Aceast" regul" este respectat" de c"tre Oracle prin
posibilitatea definirii vederilor: dac" un tabel este divizat n dou", atunci se poate crea o vedere care
al"tur" cele dou" tabele, astfel nct aceast" mp"r!ire nu va avea nici un efect asupra aplica!iei.

Regula 10. Regula independen!ei datelor din punctul de vedere al integrit"!ii:
Regulile de integritate a bazei de date trebuie s" fie definite n limbajul utilizat de sistem pentru
definirea datelor #i nu n cadrul aplica!iilor individuale; n plus, aceste reguli de integritate trebuie
stocate n dic!ionarul de date.

Cu alte cuvinte, restric!iile de integritate trebuie impuse la definirea tabelelor bazei de date #i nu n
cadrul aplica!iilor care folosesc aceste tabele. n general, Oracle respect" aceast" regul", la definirea
tabelelor (n cadrul comenzii CREATE TABLE) putndu-se defini att restric!iile de integritate
structural" (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY) ct #i unele restric!ii de
comportament (CHECK). Informa!ii despre aceste restric!ii sunt stocate n dic!ionarul bazei de date.

Regula 11. Regula independen!ei datelor din punctul de vedere al distribuirii:
29
Programele de aplica!ie nu trebuie s" fie afectate de distribuirea pe mai multe calculatoare a bazei
de date.

Cu alte cuvinte, baza de date trebuie s" mearg" corect indiferent dac" se g"se#te pe un singur
calculator sau este distribuit" n mai multe noduri ale unei re!ele. Aceast" regul" este o extensie a
regulii 8, privind independen!a programelor de aplica!ie fa!" de modul de stocare fizic" a datelor.
Aceast" regul" este n general respectat" de Oracle, existnd totu#i restric!ii privind accesarea unor
obiecte aflate n alt nod al re!elei. n plus, n Oracle exist" posibilitatea replic"rii locale a tabelelor
aflate n alte noduri ale re!elei, evitndu-se astfel transmiterea n mod repetat a informa!iilor prin
re!ea.

Regula 12. Regula privind prelucrarea datelor de c"tre un limbaj de nivel inferior.
Orice limbaj nerela!ional folosit pentru accesarea datelor trebuie s" respecte acelea#i condi!ii de
integritate ca #i limbajul rela!ional de acces.

De exemplu, dac" sistemul posed" un limbaj de nivel inferior, prin care se acceseaz" datele la nivel
de rnd #i nu, potrivit sistemului rela!ional, la nivelul mul!imilor de rnduri, acest limbaj nu poate fi
folosit pentru evitarea restric!iilor de integritate (integritatea entit"!ii, integritatea referen!ial",
restric!ii de comportament) pe care trebuie s" le respecte limbajul procedural de acces la date.
Aceast" regul" este respectat" de c"tre Oracle prin faptul c" singurul limbaj de accesare a datelor
este SQL, care este un limbaj rela!ional.


Dac" un SGBD ndepline#te principiile sistemului rela!ional (folose#te ca structuri de date tabele
conforme cu modelul rela!ional, suport" cele dou" reguli de integritate structural" #i opera!iile
rela!ionale) #i respect" aceste 12 reguli, atunci el poate fi numit rela!ional. Codd rezum" aceste
lucruri prin regula zero:

Regula 0. Regula de baz":
Un SGBD Rela!ional trebuie s" fie capabil s" gestioneze baza de date exclusiv pe baza
caracteristicilor sale rela!ionale.

Aceasta nseamn" c" sistemul trebuie s"-#i ndeplineasc" toate func!iile prin manipul"ri n care
unitatea de procesare s" fie tabelul (mul!imea de rnduri), asupra c"ruia s" se efectueze opera!iile
specifice modelului rela!ional. Trebuie spus c" regula 0 nu este respectat" n totalitate de nici un
SGBD existent pe pia!", inclusiv Oracle, implementarea acestora folosind att caracteristici
rela!ionale ct #i nerela!ionale.

Se obi#nuie#te ca, n conformitate cu tipul de cerin!e pe care le exprim", regulile s" fie grupate n
cinci categorii, #i anume:

1. reguli de baz": Regula 0 #i Regula 12;
2. reguli structurale: Regula 1 #i Regula 6;
3. reguli privind integritatea datelor: Regula 3 #i Regula 10;
4. reguli privind manipularea datelor: Regula 2, Regula 4, Regula 5 #i Regula 7;
5. reguli privind independen!a datelor: Regula 8, Regula 9 #i Regula 11.

Trebuie spus c" nici unul dintre SGBD-urile existente n prezent nu satisface n totalitate toate cele
13 reguli ale lui Codd. De aceea, n practic" nu sunt utilizate regulile lui Codd, fiind formulate n
schimb un set de cerin!e minimale pe care trebuie s" le satisfac" un sistem SGBD pentru a putea fi
considerat rela!ional.
Un SGBD este denumit minimal rela!ional, dac" satisface urm"toarele condi!ii:
30
1. Toate datele din cadrul bazei de date sunt reprezentate prin valori n tabele.
2. Nu exist" pointeri ntre tabele observabili de c"tre utilizator.
3. Sistemul suport" operatorii rela!ionali de proiec!ie, selec!ie #i compunere natural", f"r" limit"ri
impuse de considerente interne.
Un SGBD este denumit complet rela!ional dac" este minimal rela!ional #i satisface n plus
urm"toarele condi!ii:
4. Sistemul suport" toate opera!iile de baz" ale algebrei rela!ionale, f"r" limit"ri impuse de
considerente interne.
5. Sistemul suport" restric!iile de integritate de baz" ale modelului rela!ional (integritatea entit"!ii
#i integritatea referen!ial")

SGDB-ul Oracle este complet rela!ional #i chiar se apropie destul de mult de un SGBD rela!ional
ideal, definit prin regulile lui Codd.