Universitatea Petre Andrei

Facultatea de Economie

BAZE DE DATE
Suport de curs

Lect.univ.dr. VIRGIL FATU

STUDIUL BD I AL SGBD
Organizarea datelor n fiiere, dei este destul de utilizat, are o serie de neajunsuri care
limiteaz eficiena i eficacitatea aplicaiilor utilizator. Dintre acestea amintim redundana
ridicat a datelor, lipsa integrrii datelor, dependena datelor fa de programele de aplicaii,
costul ridicat de ntreinere etc.
Redundana ridicat a datelor. Fiiere de date independente conin o mulime de date
care se repet. Aceleai date (exemplu: nume furnizor, adresa furnizor, cont la banca, etc.) sunt
nregistrate i stocate n mai multe fiiere ceea ce reclam programe distincte pentru actualizarea
fiecrui fiier. n plus duplicarea datelor conduce la un consum mare de memorie i incoeren la
trecerea datelor stocate dintr-un fiier n altul.
Sintetic efectele imediate ale acestui neajuns sunt:
1. gestionarea complex a datelor;
2. actualizarea greoaie a datelor;
3. monopolizarea inutil a spaiului de memorie.
Neintegrarea datelor. Dispersia datelor n diverse fiiere independente complic accesul
utilizatorilor la informaiile cerute ad-hoc, necesitnd crearea de programe particulare pentru
extragerea datelor solicitate. n lipsa acestor programe, pentru obinerea informaiilor dorite
utilizatorul procedeaz la extragerea manual.
Dependena datelor de programe. Organizarea fiierelor, adresarea fizic n memorie i
programele de aplicaii folosite pentru accesarea fiierelor sunt interdependente. Astfel,
schimbrile legate de dispunerea pe suportul de memorie, structura datelor i modificarea
nregistrrilor unui fiier presupun modificri n toate programele n care este referit fiierul
respectiv. ntreinerea acestor programe este dificil putnd genera incoerene n fiierele de date.
Incoerena i lipsa de integritate sunt extrem de dificil de corectat deoarece nu exist un
dicionar central pentru urmrirea definirii datelor.
Costul de ntreinere. Exploatarea fiierelor independente presupune un cost ridicat att n
ceea ce privete resursele informatice (hardware i software) ct i cele legate de personalul
utilizat.
Toate aceste probleme care apar n sistemul ce prelucreaz fiiere i gsesc rezolvarea prin
folosirea bazelor de date i a sistemelor de gestiune a bazelor de date. Datele stocate n baze de
date sunt independente att fa de programele de aplicaii care le folosesc, ct i fa de tipul de
memorie utilizat.

Sintetiznd cele de mai sus rezult c principalele beneficii ale bazelor de date constau
1

n :
1. integrarea n aceeai structur a tuturor datelor pertinente ale unui sistem;
2. gestionarea acestor date printr-un soft specializat (SGBD);
3. oferirea unei vederi pariale asupra ansamblului de date, necesar fiecrui
utilizator;
4. asigurarea partajrii datelor ntre diferii utilizatori.
Baza de date reprezint un ansamblu integrat de nregistrri sau de fiiere reunite i
structurate n mod logic. n felul acesta datele stocate anterior n fiiere independente /distincte
sunt concentrate ntr-un fond comun de nregistrri cu posibilitatea utilizrii lor n numeroase
aplicaii.
Conceptul de baz de date a aprut n 1964 n cadrul primului raport CODASYL prezentat
la lucrrile unei Conferine pe probleme de limbaje de gestiune a datelor Development and
Management of Computer centered data-base. La aceast conferin a fost lansat ideea
organizrii datelor prin intermediul unui fiier de descriere global numit dicionar de date care
are menirea de a asigura independena programelor fa de date i a datelor fa de programe2.
Accesul utilizatorului la informaiile despre structura unei anumite baze de date se realizeaz
prin intermediul unui software de aplicaii care ofer un ajutor apreciabil gestiunii datelor, n
general, i bazelor comune de date, n special, numit dicionar de date.
Prin intermediul dicionarului de date, dup caz, sistemul stocheaz informaii referitoare la:
1. relaiile bazei de date (denumire, descriere etc.);
2. atributele relaiei (denumire, domenii, tip, chei primare i secundare);
3. utilizatorii care au drepturi de acces la o anumit relaie;
4. optimizarea bazei de date (prin fiiere index, tehnica clustering etc.).
n principal, un dicionar ndeplinete urmtoarele funcii:
1. definirea i gestionarea datelor elementare ale ntreprinderii (cod, denumire,
atribute, reprezentare etc.);
2. definirea i gestionarea ansamblurilor de date;
3. definirea i gestionarea relaiilor, de dependen sau ierarhice, dintre date;
4. descrierea utilizrii datelor din trei puncte de vedere:
1. administrativ: care sunt posturile de lucru ce vor apela datele i care va fi
utilizarea acestor date?
2. logic: care sunt fiierele sau bazele de date n care intr elementele descrise ?;
3. organic: n care uniti de prelucrare vor fi utilizate elementele descrise?
1
2

Saleh, I., Les bases de donnes relationnelles, Edition Hermes, Paris, 1995, p. 303
Lungu, I. .a., Baze de date Organizare, proiectare i implementare, Editura All, Bucureti, 1995, p.13

Legtura dintre aceste funcii este prezentat n figura nr. 4.1.

Lista posturilor de
lucru-utilizator
Elemente descrise
prin
DICIONARUL
DE DATE

Fiiere sau baze de date n

care intervin elementele
Uniti de prelucrare n
care intervin elementele

Fig.4.1 Elementele dicionarului de date

(Prelucrare dup Lesca, H., Peaucelle, J. L., Elements dinformatique applique a la gestion, Edition
Dalloz, Paris, 1988, p. 139)

Abordarea corect a bazelor de date presupune i tratarea urmtoarelor elemente: entitatea

(articol, nregistrare logic), atributele (caracteristic, cmp) i valoarea /realizare3.
Prin entitate se nelege un obiect concret sau abstract (operaie economic, mijloc
economic etc.) reprezentat prin proprietile sau nsuirile sale. Orice proprietate poate fi
exprimat printr-o pereche atribut-valoare sau caracteristic-realizare. O entitate este identificat
printr-un nume i cuprinde, n general, mai multe valori sau realizri.
Atributul are rolul de a descrie nsuirile sau proprietile obiectului stabilind natura
valorilor pe care acesta le poate lua.
Valoarea reprezint mrimea ce se atribuie fiecrei caracteristici din cadrul unei entiti.
Reunite aceste elemente sunt prezentate ntr-un exemplu n tabelul nr. 4.1.
Tabelul nr. 4.1 Elemente specifice bazelor de date

Entitate

PRODUS

Realizri (valori)

Caracteristici (atribute)
Cod produs
Denumire produs
Unitate de masura
Pret unitar
Cantitate
Valoare
Nr. Factur
Data receptie

11112
Pantofi
Per
350000
100
35000000
2452
1-12-1999

11116
Ghete
Per
550000
100
55000000
2147
18-12-1999

O baz de date trebuie s satisfac cinci condiii eseniale4:

Aceste elemente sunt numite diferit n literatura de specialitate - vezi Roca, I., .a., Baze de date i SGBD,
Bucureti, 1986; Lungu, I., .a., Baze de date Organizare, proiectare i implementare, Editura All, Bucureti,
1995; Fotache, M., Baze de date relaionale, Editura Junimea, Iai, 1997
4
Morjon, J., Principes et conception dun base de donnes relationnelle, Les Editions dorganisation, Paris, 1992,
p. 20

1.
2.
3.
4.

5.

bun reprezentare a realitii nconjurtoare; o baz de date trebuie s ofere

ntotdeauna o imagine fidel a realitii prin informaii fiabile i actualizate;
non-redundana informaiei; informaia coninut n baza de date trebuie s fie unic
din punct de vedere semantic i fizic;
independena datelor fa de prelucrri; datele constituie imaginea fidel a lumii reale,
programele de aplicaii trebuind s fie concepute n raport cu aceast structur a datelor;
securitatea i confidenialitatea datelor; securitatea datelor trebuie asigurat prin
proceduri fizice, iar confidenialitatea prin proceduri care s mpiedice accesul
utilizatorilor neautorizai;
performane n exploatare; orice cerere de prelucrare trebuie s fie satisfcut ntr-un

timp convenabil utilizatorului, ceea ce presupune folosirea unor tehnici de optimizare

pentru reducerea timpului de prelucrare.
O baz de date special conceput prin agregarea tuturor datelor unei ntreprinderi n
vederea sprijinirii procesului de fundamentare a deciziilor constituie aa numitul depozit de date
data warehouse.
Ideea depozitelor de date nu este recent, ea s-a conturat i dezvoltat n anii 90. William
Inmon este cel care definete pentru prima oar termenul de data warehose.
Depozitul de date poate fi considerat ca un sistem de baze de date special conceput pentru
analiza datelor i fundamentarea deciziilor prin agregarea tuturor datelor ntreprinderii.
Depozitele de date sunt aadar, enciclopedii informaionale n care datele sunt introduse
continuu, utilizatorul putndu-le accesa n funcie de necesiti.
n depozitele de date se memoreaz urmtoarele tipuri de date:
1. date curente din sistemele operaionale /tranzacionale;
2. date de detaliu privind perioadele precedente (date din arhive);
3. date agregate necesare sprijinirii procesului decizional pe toate nivelurile
manageriale preluate din surse interne i externe (baze de date publice, sondaje,
date de prognoz etc.);
4. metadate care asigur exploatarea depozitelor de date prin reguli de extragere i
conversie, reguli de agregare etc.
Spre deosebire de coleciile de date utilizate n sistemul operaional orientate spre
optimizarea i sigurana procesrii datelor, datele din depozitul de date sunt organizate ntr-o
manier care s permit analiza lor. Rezult c depozitul de date acoper un orizont temporal mai
mare, conine att date interne ct i date externe i este optimizat pentru a rspunde complexelor
interogri ale unei game diversificate de utilizatori. Schematizat, fluxul datelor ntr-un depozit de
date este prezentat n figura nr. 4.2.

n cazul depozitelor de date, prelucrrile /exploatrile (data mining) sunt bazate pe modele
performante de selectare i agregare a datelor coninute.
Practica ofer trei soluii de organizare a depozitelor de date5:
5. la nivelul entitii social-economice (data warehouse);
6. la nivelul unei structuri funcionale: filial, departament, serviciu, birou (data
marts);
7. la nivelul evenimentelor elementare (tranzacionale).
n implementarea unui depozit de date pot fi folosite mai multe variante:
8. implementarea unui sistem descentralizat n care datele sunt pstrate n uniti
independente (data marts); aceste uniti conin date relevante pentru un anumit
aspect al operaiunilor derulate n entitatea social-economic;
9. implementarea unei surse de date unice la care au acces utilizatorii din toate
structurile funcionale;
10. implementarea unei surse de date centralizate la nivelul entitii social-economice
cu existena unor uniti dependente (dependent data marts) care prezint subseturi
ale datelor (din depozitul central de date) ce au fost selectate i organizate pe
domenii de aplicaii.

Baze de date
operaionale

Achiziie /Extragere

STOCARE
5

Florescu, V. .a. Baze de date, Editura Economic, Bucureti, 1999, p. 32

n depozitul de date

tergere

Prelucrare

Arhivare

(data mining)

Agregare

Fig. nr. 4.2 Fluxul datelor ntr-un depozit de date

Utilizarea depozitelor se concretizeaz n obinerea unor rapoarte (la cerere sau pe baza
unui abonament cu o anumit periodicitate), extragerea unor date pentru a fi utilizate n aplicaii
de birotic (programe de calcul tabelar, procesare de texte etc.), dar mai ales pentru realizarea
unor aplicaii specializate de analiz a datelor.
Principalul inconvenient al depozitului de date este dimensiunea sa enorm, de ordinul
giga sau teraocteilor, datorat nmagazinrii datelor detaliate la cel mai analitic nivel.
Segmentul de pia legat de depozitele de date are o rat anual de cretere de circa 35%.
Pentru a putea fi exploatat de ctre utilizatori, o baz de date trebuie s aib asociat un set
de programe care s permit exploatarea raional a datelor coninute. Este vorba despre sistemul
de gestiune a bazelor de date, denumit generic SGBD.
SGBD-ul este definit ca un ansamblu coordonat de programe care permite descrierea,
memorarea, manipularea, interogarea i tratarea datelor coninute ntr-o baz de date. El trebuie,
de asemenea, s asigure securitatea i confidenialitatea datelor ntr-un mediu multi-utilizator6.
Pentru a-i ndeplini aceste funcii SGBD-ul interacioneaz cu structura bazei de date,
sistemul de calcul, sistemul de operare, programele de aplicaii i utilizatorii constituindu-se
banca de date. Se pot organiza bnci de date n toate sferele de activitate: baze de date
bibliografice, de documentare statistic, evidene finanfiar-contabile i bancare, diagnosticare i
informare medical, rezervarea tichetelor de cltorie i a locurilor n staiunile turistice etc.

MODELE CONCEPTUALE DE STRUCTURARE I ORGANIZARE A

DATELOR N BAZE DE DATE
Pentru descrierea structurii datelor unei baze de date i a relaiilor dintre acestea sunt
folosite procedee formale, concretizate n modele conceptuale. Acestea se particularizeaz prin
terminologia utilizat i prin relaiile dintre date.

Morjon, J., Op. cit., p. 26

Tipuri de relaii i structuri de reprezentare a relaiilor n cadrul unei

baze de date
Entitile aceluiai sistem informaional sunt rareori izolate unele de altele, ele antrennd,
cel mai adesea, legturi sau relaii. ntre datele diverselor tipuri de entiti pot exista dou
categorii de legturi sau relaii. Prima privete relaiile dintre datele aparintoare aceleiai
entiti, iar a doua se refer la relaiile dintre mai multe entiti care pot fi i de tipuri diferite.
Dup numrul entitilor care intr n legtur, relaiile pot fi binare i n-are.
Relaiile binare presupun existena unui domeniu, a unui codomeniu i a unei
corespondene ntre entitile acestora. n practica bazelor de date se disting patru tipuri de relaii
binare: 1-1, 1-n, n-1, n-n.
n relaiile 1-1 (una-la-una) unei realizri din domeniu i corespunde o realizare i numai
una din codomeniu (figura nr. 4.4).
Y1
Y2

X1
X2

Yn

Xn
Domeniu

Codomeniu

Fig. nr. 4.4 Relaia de tip 1-1

n relaiile 1-n (una-la-mai-multe) unei realizri din domeniu i corespund 0, una sau mai
multe realizri din codomeniu (figura nr. 4.5).

Y1
Y2
.Y3.
Y4
Y5

X1

X2
Domeniu

Codomeniu

Fig. nr. 4.5 Relaii de tip 1-n

n relaiile n-1 (mai-multe-la-una) mai multe nregistrri din domeniu corespund unei
realizri din codomeniu. (figura nr. 4.6).

X1
X2

X3
Domeniu

Codomeniu
Fig. nr. 4.6 Relaia n-1

n relaiile n-m (mai-multe-la-mai-multe) unei realizri din domeniu i corespund 0, una

sau mai multe realizri din codomeniu, iar unei realizri din codomeniu i corespund 0, una sau
mai multe realizri din domeniu (figura nr. 4.7).
X1

Y1
Y2
.Y3.
Y4

X2
Domeniu

Codomeniu

Fig. nr. 4.7 Relaia n-m

Relaiile n-are presupun existena unei interdependene logice ntre realizrile mai multor
entiti.
Mecanismul de selecie i de identificare a componentelor unei baze de date presupune
existena unei structuri de date. Concret o structur de date reprezint o colecie de date ntre
care s-au stabilit anumite relaii. Structurile de date care au aceeai organizare i sunt supuse
prelucrrilor cu un grup de operatori de baz cu o semantic predefinit formeaz un anumit tip
de structur.

Niveluri de abstractizare a datelor

Spre deosebire de fiiere n care datele erau organizate pe dou niveluri logic i fizic,
pentru proiectarea bazelor de date sunt definite trei niveluri de abstractizare: conceptual, logic i
fizic.
Nivelul conceptual permite specificarea regulilor de gestiune pentru acoperirea ntregii
structuri a datelor i satisfacerea cerinelor tuturor utilizatorilor concomitent cu asigurarea unei
redundane minime a datelor. Modelele utilizate sunt de natur semantic i nu in seama de
tehnicile ce vor fi utilizate la darea n exploatare a bazei de date.

nainte de a realiza integrarea n schema conceptual, pe acest nivel se procedeaz la

elaborarea de modele pariale sau vederi externe de date.
Nivelul logic permite descrierea structurii nregistrrilor logice n cadrul coleciilor, adic a
modului n care utilizatorii i creeaz structurile de date pentru propriile aplicaii. Aceste
structuri sunt orientate spre o clas de soluii fiind mai informatice i in cont de tehnicile de
optimizare folosite (ci de acces, volume, frecven)7.
Nivelul fizic permite descrierea structurii sub care coleciile de date se regsesc efectiv pe
suprafaa de memorare (memorie intern i/sau extern). La acest nivel se va trece de la
descrierea logic la o descriere ce va utiliza concret posibilitile sistemului de gestiune a bazelor
de date.
Dintr-o alt perspectiv nivelul conceptual anterior poate fi divizat intr-un nivel extern pe
care se definesc vederile externe propuse de utilizatori i un nivel conceptual care d viziunea
global sau de ansamblu. n acelai timp este posibil regruparea nivelului logic i fizic ntr-un
nivel intern.
Legtura dintre aceste niveluri este prezentat n figura nr. 4.8.
Realitatea
nconjurtoare

Schema
conceptual

Vederi
externe

Schema logic

Baza de
date

Fig. nr. 4.8. Niveluri de abstractizare a datelor

Modele de organizare a datelor n bazele de date

Un model este un ansamblu de concepte ce permite stabilirea reprezentrii modului de
percepere a lumii nconjurtoare. Acesta posed, n general, un formalism grafic de reprezentare.
n practic sunt disponibile dou clase de modele:
7

Morjon, J., Op. cit., pp. 22-23

modele care privesc reprezentarea la nivel conceptual, rspunznd preocuprilor

semantice (modelul Entitate-Asociaie, modelul binar, modelul reea semantic etc.);
2.
modele care privesc memorarea la nivel logic i fizic rspunznd preocuprilor
informatice propriu-zise (modelul relaional, modelul reea i modelul ierarhic).
Modelele de date ajut la conceperea fizic a unei baze de date, inclusiv elaborarea
programelor de aplicaii, prin intermediul unor cadre logice numite scheme i sub-scheme.
Schema reprezint o vedere logic global a relaiilor dintre datele unei baze, n timp ce
sub-schema este o vedere logic a relaiilor necesare ntre date pentru susinerea anumitor
programe de aplicaii prin care utilizatorii vor avea acces la aceast baz de date. Simplificat,
legturile dintre vederile logice, fizice i interfaa logic a unui sistem de prelucrare organizat pe
1.

baz de date, n cadrul unei bnci este prezentat n figura nr.4.9:

Apl. 1

Apl. 2

Apl. n
Vederi logice ale utilizatorului
Sub-scheme

Model 1

Model 2

Model de ansamblu

SGBD

Schema

Interfaa logic

Vederi fizice ale datelor

Fig. nr. 4.9 Legturile dintre vederile logice, fizice i interfaa sistem

Modelul ierarhic
Modelul ierarhic este primul model utilizat pentru organizarea datelor n baze de date. El
se bazeaz pe structura arborescent i pe relaiile 1-1 i 1-n, prezentndu-se sub forma unui
arbore, n care se regsesc pe un prim nivel rdcina (nod-printe), iar pe nivelurile urmtoare
diferite elemente subordonate (noduri-copil).
Nodul-printe poate avea subordonate mai multe noduri-copil n timp ce un nod-copil nu
poate avea dect un singur printe. Rezult c relaia printe-copil poate fi de tip 1-n, iar relaia
copil printe poate fi doar de tip 1-1. Acest model asigur organizarea datelor pe orice tip de
suport magnetic i reducerea timpului de acces la nregistrri.

Modelul ierarhic are o serie de limite, n special n operaiile de actualizare cnd adugarea
de noi nregistrri - cu excepia celor din colecia de date rdcin - se poate efectua numai cu
specificarea coleciilor de date superioare, iar tergerea unei nregistrri duce la eliminarea fizic
a tuturor nregistrrilor subordonate. n figura nr. 4.10 este prezentat modelul ierarhic.
Departament
CONTABILITATE

Gestiune
MATERIALE

PL 1

PL 2

Gestiune
MARFURI

PL 3

PL 4

SALARII

PL 5

PL 6

Fig. nr. 4.10 Modelul ierarhic

Din acest exemplu rezult c departamentul CONTABILITATE (nod-printe) este

constituit din mai multe aplicaii i posturi de lucru (noduri-copil) n timp ce fiecare nod-copil
este subordonat unui singur nod-printe.
Modelul reea
Modelul reea elimin redundanele specifice modelului ierarhic i se bazeaz pe structurile
reea i pe relaiile de tip 1-1, 1-n i n-m. Caracteristica principal a acestui model este c accept
ca orice colecie de date s se situeze pe nivelul 1, astfel fiind permis accesul direct la realizrile
coleciilor superioare -operaie imposibil n modelul ierarhic. n plus, prin acest model este
permis reprezentarea unic a realizrilor n baza de date.
Legturile fizice pe suport sunt asigurate prin intermediul unor caracteristici care exprim
pointer-ul (adresa de pe suport) realizrii superioare sau al realizrii subordonate. Astfel, reeaua
este un graf orientat alctuit din noduri conectate prin arce. Nodurile corespund tipurilor de
nregistrare, iar arcele pointer-ilor. n felul acesta este permis introducerea nregistrrilor
artificiale pentru a reprezenta legturile n-are (n>2) - vezi figura nr. 4.11.

Departament
CONTABILITATE

PL 1

Departament
INFORMATIC

PL 2

Gestiune
MATERIALE

PL 3

Gestiune
MARFURI

Fig. nr. 4.11 Modelul reea

Dup cum se observ din figura nr. 4.11 modelul admite relaii de tip n-m, ceea ce are ca
efect reducerea redundanei datelor. Modelele ierarhic i reea nu permit realizarea unei
independene logice satisfctoare ntre date i programe, deoarece relaiile dintre date exist i
sunt referite n programele de aplicaii.
Modelul relaional
Modelul relaional a fost fundamentat n 1970, de E.F. Codd i se bazeaz pe teoria
matematic a relaiilor i pe calculul relaional. Ideea unui model ansamblist a datelor a fost
lansat nc din 1968 de ctre Childs D.F. care arta c orice structur de date poate fi
reprezentat sub form de tabele (una sau mai multe) n interiorul crora trebuie s existe i
informaie de legtur8. Acest model va fi dezvoltat n capitolul 5.
Modelul Entitate-Asociaie (E-A)
Acest model a fost introdus n 1976 de ctre cercettorul american Chen care a avut ca
obiectiv crearea unui model care s permit o viziune unificat, global asupra datelor 9. Este
un model semantic de date, simplu i atractiv datorit reprezentrii sale grafice, fiind utilizat n
mai multe metode de analiz i proiectare (MERISE, AXIAL etc.) i dispunnd de mai multe
extensii. Modelul opereaz cu urmtoarele concepte de baz: atribut, entitate /proprietate,
entitate-tip, asociaie.
Atributul reprezint o informaie elementar definit pe un domeniu.
Entitatea este considerat un obiect concret sau abstract din lumea observat avnd o
existen proprie, care poate fi identificat i descris printr-un ansamblu de atribute, independent
de alte obiecte.
8
9

Lungu, I. .a., Op. cit., p. 96

Fotache, M., Op. cit., p. 63

Literatura de specialitate nu ofer ns o definiie unanim acceptat pentru acest concept,

fiind totui subliniate urmtoarele caracteristici10:
3. entitate are o existen proprie;
4. este abstract sau concret;
5. aparine unei familii de obiecte de aceeai natur (clas sau entitate tip);
6. ntr-o entitate tip (denumit i clas) fiecare membru (denumit realizarea entitii)
este definit fr ambiguiti.
Clasa de entiti (denumit i entitate tip) reprezint un ansamblu de entiti de aceeai
natur, deci cu aceleai atribute, fiecare entitate fiind identificat ntr-o manier unic. Numrul
de atribute este stabilit de ctre proiectant. Reprezentarea unei clase de entiti se realizeaz
printr-un nume i printr-un ansamblu de atribute de descriere.
De exemplu, clasa ANGAJAT se definete prin atributele: Numr marc, Nume, Prenume,
Funcie, Data angajrii i se poate reprezenta astfel:
Angajat
Numr marc
Nume
Prenume
Funcie
Data angajrii

Identificarea unic a unei clase de entiti se realizeaz cu ajutorul unuia sau a mai multor
atribute permindu-se distingerea ntr-o manier unic a fiecreia dintre realizrile clasei. n
exemplul de mai sus identificarea unic a fiecrui angajat poate fi realizat prin Numr marc
sau prin Nume.
Asociaia (relaia) reprezint o legtur semantic definit ntre dou sau mai multe
entiti. Asociaiile de acelai tip formeaz o clas de asociaii. O asociaie se caracterizeaz prin
dimensiune i cardinalitate.
Dimensiunea unei asociaii reprezint numrul de clase de entiti implicate ntr-o clas de
asociaii. Clasele de asociaii pot fi:
1.
unare - relaiile se stabilesc ntre entitile aceleiai clase;
2.
binare - relaiile se stabilesc ntre entitile aflate n dou clase diferite;
3.
n-are - relaiile se stabilesc ntre n clase de entiti.
Cardinalitatea reprezint un cuplu de valori (M:N) desemnnd numrul (minim i maxim)
de entiti din fiecare clas ce pot fi implicate ntr-o asociaie. Cuplul de valori (M:N) specific
pe de o parte dac asociaia este parial (M=0) sau total (M=1) i, pe de alt parte, dac relaia

10

Saleh, J., Les bases de donnees relationnelles, Edition Hermes, Paris, 1995, p. 22

reprezint o funcie monovaloare (N=1) sau multivaloare (N>1). Pot exista 4 tipuri de
cardinaliti (tabelul nr. 3.2).
Tabelul nr. 3.2 Tipuri de cardinaliti

Cardinalitate minimal

Cardinalitate maximal

0
1
0
1

1
1
N
N

Utilizarea acestui model este n mare parte intuitiv. El nu este un model teoretic de
reprezentare, ci mai curnd o interfa prietenoas de schiare a structurii datelor. Adesea este
utilizat pentru ilustrarea grafic a modelului relaional.
Absena limbajului de manipulare a datelor bine formalizat i adaptat a antrenat numeroase
propuneri, preferina mergnd spre limbajele relaionale. Raiunea principal este relativa
uurin de transformare a modelului E-A n model relaional. Practic se construiete o schem
E-A care se transform n schem relaional. n felul acesta se combin simplitatea de descriere
a primului model cu puterea limbajului celui de al doilea model.
n cadrul modelului E-A, descrierea textual a entitilor i a relaiilor lor este uneori
greoaie. n practic se apeleaz la o reprezentare mai comod sub forma unor scheme de sintez
ce faciliteaz comunicarea, cunoscute sub denumirea de formalisme. Principalele formalisme
sunt Merise, Chen, Ross, Case*Methode, Perkinson etc. Prezentm n continuare doar
formalismele Merise i Chen.
Formalismul Merise
Aa cum rezult din figura nr. 4.12 simbolurile grafice pentru formalismul Merise sunt:
1. dreptunghiul pentru reprezentarea claselor de entiti. n interior se specific un
nume (pentru identificarea entitilor), sub care sunt enumerate atributele;
2. elipsa pentru reprezentarea claselor de asociaii. n interiorul elipsei se nscrie
numele clasei, sub care pot aprea eventualele atribute;
3. liniile pentru unirea simbolurilor precedente; pe aceste linii se nscriu cifre care
exprim cardinalitile claselor de asociaii.

PRODUS
1,N

0,N
Cod produs
Denumire produs
Pre unitar

STOC

COMANDA
Data comanda

1,N

1,N

DEPOZIT
Cod depozit
Denumire depozit
Adresa depozit

CLIENT
Cod client
Nume client
Localitate

Fig. nr. 4.12 Formalismul grafic Merise

Se observ c o asociaie este reprezentat printr-o elips, unind entitile implicate.

Fiecare legtur semnific relaia dintre entitate i asociaie. Lng entiti se nscriu
cardinalitile, adic numerele maxime i minime de realizri posibile.
Din exemplul nostru din figura nr. 4.12 rezult c entitatea PRODUS are cardinalitatea 0,N
ceea ce nseamn c un produs poate s nu fie comandat (valoarea 0) sau s apar n una, dou
sau N comenzi.
Formalismul grafic Chen
n notaia grafic Chen sunt folosite urmtoarele simboluri:
1. dreptunghiurile pentru clase de entiti. n interior se specific identificatorii
respectivelor clase;
2. elipsele sau cercurile pentru atribute. n interior se specific numele acestora;
3. romburile pentru clasele de asociaii. Au nscrise n interior numele acestora;
4. liniile pentru unirea simbolurilor precedente;
5. sgeile pentru reprezentarea cardinalitii.
O asociaie poate fi legat de mai multe entiti de acelai tip, fiecare tip fiind identificabil.
Cardinalitatea unei entiti dintr-o relaie este definit printr-o cifr plasat pe linia asociaiei. Ea
poate fi 1:1, 1:N i M:N.
n figura nr. 4.13 este reprezentat grafic o diagram Entitate-Asociaie dup formalismul
Chen.

Matricol
Titlu
Nume

STUDENT

NSCRIERE

STUDENT

Departament

Adres
Secie
An studiu
NSCRIERE

PROFESOR

Nume profesor

Catedra

Fig. nr. 4.13 Diagrama Entitate-Asociaie n formalismul Chen

. Modelul obiectual
Apariia acestui model este efectul orientrii spre multimedia i spre aplicaii de proiectare
asistate de calculator care solicit prelucrarea tipurilor neconvenionale de date.
La baza modelului orientat pe obiecte st noiunea de entitate conceptual definit ca un
obiect descris printr-o colecie de proprieti. Principalele concepte care stau la baza unui model
orientat pe obiecte sunt: obiectul, ncapsularea, persistena, clasa, tipul, motenirea,
polimorfismul, identitatea, domeniul.
Un obiect poate fi definit ca o abstractizare a unei entiti particulare sau ca un ansamblu
de date, mpreun cu procedurile de prelucrare a acestora. Privite din acest punct de vedere
procedurile poart denumirea de metode, iar datele obiectului se numesc proprieti.
Un obiect este caracterizat prin atribute i comportament. Atributele reprezint starea sa i
legturile care-l unesc cu alte obiecte, iar comportamentul se constituie din metodele i operaiile
care pot fi aplicate atributelor.
Avnd n vedere cele de mai sus, putem concluziona c un obiect corespunde unei entiti
care are un nume, stocheaz o stare (atribute) i rspunde unui ansamblu definit de mesaje.
Pot fi identificate trei tipuri de obiecte:
1. elementare: 20 (ntreg), an I (ir de caractere), N (boolean);
2. compuse: nume, secie, adres;
3. complexe: student.
Un obiect este format din structura de date, specificarea operaiilor i implementarea
operaiilor.

Interfaa obiectului cu mediul o reprezint mesajele care, de fapt sunt cereri adresate
obiectului pentru a returna o valoare, sau pentru a-i schimba starea. Mesajele sunt implementate
prin intermediul metodelor, care generic reprezint programe de manipulare a obiectelor sau de
indicare a strii acesteia.
ncapsularea reprezint o caracteristic ce ofer utilizatorului o imagine funcional
simplificat a obiectului, ascunznd complexitatea acestuia. Practic are loc divizarea obiectului
n dou pri: interfaa reprezentat de mesajele adresate obiectului i coninutul obiectului
reprezentat de starea intern i de metodele acestuia. Interfaa permite unui utilizator din exterior
s solicite obiectului realizarea unei aciuni prin emiterea unui mesaj specific metodei asociate
aciunii respective. Structura unei date obiect poate fi prezentat ca n fig. nr. 4.14.
ncapsularea urmrete ca datele unui obiect s poat fi modificate doar prin intermediul
metodelor proprii obiectului respectiv. n acest fel se realizeaz un control strict asupra
obiectului, eliminndu-se eventualele surse de erori provenite din nefolosirea necorespunztoare
a proprietilor11.
CONINUT
INTERFAA

Date i metode
Operaii posibile
Fig. nr.4.14 Structura unei date obiect

Persistena este proprietatea prin care datele i obiectele, ca existen i stare, depesc
procesul care le-a creat, putnd fi refolosite ulterior n alte procese.
Tipurile i clasele de obiecte sunt concepte care reunesc obiectele cu acelai fel de
atribute i comportament. Din aceast perspectiv practica prezint dou categorii de sisteme
orientate pe obiecte:
1. sisteme bazate pe conceptul de tip (C++, Simula, vBase);
2. sisteme bazate pe conceptul de clas (Smalltalk, Gemstone, Vision, Orion, GBase).
Tipul sintetizeaz elementele comune ale obiectelor care au aceleai caracteristici i
dispune de dou componente: interfaa i implementarea. Interfaa se constituie dintr-o list de
operaii, iar implementarea asigur descrierea structurii interne a datelor, obiectului i realizarea
procedurilor relative la operaiile interfeei.
Clasa are aceeai semnificaie cu cea de tip, fiind asociat mai mult fazei de execuie,
presupunnd generarea de obiecte i stocarea setului de obiecte. Rezult c o clas descrie o
colecie de obiecte ce au aceleai atribute i acelai comportament. Pentru a comunica ntre ele i
11

Dima, G., Dima, M., Bazele Visual FoxPro 5.0, Editura Teora, Bucureti, 1999, p. 182

pentru a accede la informaiile unei alte entiti, obiectele i trimit mesaje. Acestea reprezint
numele metodelor i argumentele lor. Realizarea aciunii asociate unui mesaj depinde de obiectul
receptor care i administreaz propriile atribute folosind metode proprii12.
Descrierea unei clase const dintr-un set de structuri de date comune (variabile de instan,
care au propria identitate, identificatorii lor nefiind accesibili utilizatorilor), un protocol comun
(set de mesaje la care vor rspunde instanele clasei) i un set de metode pentru implementarea
operaiilor comune. n felul acesta descrierea clasei servete ca ablon pentru crearea noilor
obiecte. Ca urmare, obiectele din aceeai clas rspund la acelai mesaj, au aceleai atribute i
folosesc aceleai metode.
O problem aparte este legat de accesul utilizatorului la membrii unei clase printr-un
mecanism de control care s asigure protecia membrilor. Din acest punct de vedere membrii
unei clase pot fi:
1.
publici accesibili att din interiorul ct i din exteriorul clasei respective (dar din
domeniul n care clasa a fost definit);
2.
protejai accesibili din interiorul clasei respective i a subclaselor construite pe
baza acesteia (prin motenire);
3.
ascuni accesibili doar din interiorul clasei respective.
Clasele sunt organizate ierarhic, fiecare nou clas fiind subordonat unei clase existente.
Orice subclas motenete structurile i metodele superclasei din care face parte.
Motenirea reprezint mecanismul de definire a unei clase prin preluarea variabilelor de
instan i a metodelor din una sau mai multe clase existente deja. n primul caz este vorba de o
motenire simpl, iar n cel de-al doilea de o motenire multipl. Clasa de la care sunt motenite
(preluate) instanele (structurile de date) i metodele reprezint o supraclas. Clasa ce se creeaz
motenete toate datele i metodele supraclasei, la care se vor aduga unele noi, definite pentru
noua clas. Astfel, pe baza principiului motenirii pot fi create ierarhii de clase, ncepnd cu cele
mai generale i ajungnd la cele particulare, specializate n rezolvarea unei anumite sarcini de
prelucrare.
Polimorfismul are n vedere comportamentul obiectelor care, la primirea unui mesaj,
determin alegerea dinamic a metodei de aplicat, n funcie de clasa corespunztoare. Dei
noiunea exist de mai mult timp (polimorfism ad-hoc, polimorfism parametric) ea a fost
popularizat n special prin limbajele obiect. Polimorfismul asigur manipularea simpl i
coerent a seturilor eterogene de obiecte.
Utilizarea polimorfismului n cazul motenirii multiple permite definirea unor forme
complexe de comportament asigurnd combinarea metodelor proprii mai multor clase de obiecte.

12

Gaudel, M-C., .a., Prcis de gnie logiciel, Edition Masson, Paris, Milan, Barcelon, 1996, p. 35

Identitatea reprezint modalitatea de distingere a obiectelor ntre ele, asigurnd persistena

datelor. Prin identitate obiectele pot fi referite recursiv deoarece aceasta este independent de
valorile atributelor obiectelor. Identitatea unic a obiectelor se realizeaz prin intermediul unui
identificator intern (numit ID Object sau Pointer), generat de sistem i inaccesibil utilizatorului.
La ora actual nu exist un model propriu-zis pentru structurarea i funcionarea unei baze
de date orientate pe obiecte i aceasta n primul rnd datorit naturaleei tehnologiei obiectuale13.

13

Lungu, I. .a., Op. cit., p. 220

ELEMENTELE MODELULUI RELAIONAL

Modelul relaional a fost fundamentat n 1970 de E.F. Codd i se bazeaz pe teoria
matematic a relaiilor i pe calculul relaional. Ideea unui model ansamblist a datelor a fost
lansat ns n 1968 de ctre Childs D.F. care arta c orice structur de date poate fi reprezentat
sub form de tabele n interiorul crora trebuie s existe i informaie de legtur14.
Conform modelului relaional datele i relaiile dintre ele sunt organizate sub forma unor
tabele constituite din linii i coloane, fiecare reprezentnd un element distinct al bazei. Tabelele
posed o independen fizic total ceea ce asigur independena dintre date i prelucrri.
Manipularea datelor are loc prin intermediul unui ansamblu de operatori algebrici pentru care
relaiile sunt operanzii i rezultatele15.
Acest model se delimiteaz de celelalte modele prin reguli, cunoscute sub denumirea de
normalizare sau forme normale, care aplicate structurii stabilite prin tabele permit definirea
optim a coninutului lor.
Cea mai mare parte a bazelor de date i a SGBD-urilor comercializate la ora actual fac
apel la concepte i reguli propuse de modelul relaional. n plus, pentru a face fa noului context
informaional i organizaional au fost propuse diverse extensii ale acestui model: modele
relaionale cu valori structurate, modelul relaional Fuzzy etc.
Avantajele modelului relaional n comparaie cu celelalte tipuri de modele sunt:
1. independena sporit a programelor de aplicaie fa de modul de reprezentare
intern a datelor i de metodele de acces la date;
2. definirea unei structuri conceptuale optime, minimaliznd redundana datelor i
erorile la actualizare (prin tehnica de normalizare);
3. utilizarea unor limbaje procedurale bazate pe algebra relaional i a unor limbaje
neprocedurale care contribuie la mbuntirea comunicrii dintre sistem i
utilizatorii neinformaticieni;
4. integritatea i confidenialitatea datelor prin folosirea unor mecanisme proprii;
5. utilizarea paralelismului n prelucrarea datelor, deoarece manipularea datelor se
realizeaz numai la nivel de relaie.

14

Lungu, I. .a., Baze de date Organizare, proiectare i implementare, Editura ALL, Bucureti, 1995, p. 96
Morjon, J., Principes et conception dune base de donnes relationnelle, Les Editions dorganisation, Paris, 1992,
p. 32
15

O baz de date relaional poate fi definit ca un ansamblu de tabele aflate n legtur.

Fiecare tabel este identificat printr-un un nume propriu avnd linii i coloane la intersecia
crora se introduc valori atomice.
391
Structurarea datelor dup modelul relaional impune folosirea urmtoarelor noiuni:
domeniu, relaie (tabel), atribut, tuplu (n-tuplu sau n-uplu) i schema relaional16. Elementele
modelului relaional sunt prezentate n fig. nr. 5.1.
nume relatie

atribut

Obiecte-inventar

Cod-Furnizor Cod-ob-inv Den-ob-inv. UM

211
202
211
237
192
213
192
211

311
291
321
312
357
345
314
291
391

Etajere
Scaune
Cuiere
Dulapuri
Salopete
Manusi
Ochelari
Birouri

buc
buc
buc
buc
buc
buc
buc
buc

PU

Cantitate

235000
95000
47000
450000
85000
18000
15000
150000

12
10
5
4
14
12
10
3

schema
relatiei

tuplu
n-tupluri

domeniu
valoarea
din domeniu

Fig. nr. 5.1. Elementele modelului relaional

Literatura de specialitate prezint mai multe definiii, toate ns exprimnd aspectele de

esen. Prezentm n continuare cteva astfel de abordri.
Domeniul este definit ca ansamblul valorilor acceptate (autorizate) pentru un element
component al relaiei(tabelei).17
Un domeniu este caracterizat printr-un nume i poate fi definit explicit (n extensie) sau
implicit (n intensie). Definirea explicit se realizeaz prin enumerarea tuturor valorilor sale, iar
definirea implicit se realizeaz prin precizarea proprietilor pe care le au valorile din domeniul
respectiv.
Exemplu:
1. definirea n extensie: UNIVERSITATE = {ECONOMIE, LITERE, MATEMATIC, DREPT
};

2. definirea n intensie: INTREG, REAL

Dou domenii sunt declarate compatibile dac sunt semantic comparabile, adic dac
ansamblurile care le definesc nu sunt disjuncte. Dou domenii identice sau legate prin inclusiune
sunt compatibile.
16
17

Morjon, J., Op. cit., p. 32

Fotache, M., Baze de date relaionale, Editura Junimea, Iai, 1997, pag. 122

Relaia (tabela) reprezint un subansamblu al produsului cartezian al unei liste de domenii

caracterizat printr-un nume i corespunde unei restricii semantice din universul real modelat
deoarece fiecare obiect din acest univers trebuie s fie identificat ntr-o manier unic i
difereniat n raport cu alte obiecte.
Atributul reprezint numele dat unui domeniu dintr-o relaie i determin ansamblul de
valori pe care acesta l poate lua. Noiunea de atribut nu trebuie confundat cu cea de domeniu.
ntr-o relaie numele atributelor este unic, ceea ce asigur precizarea fr ambiguitate a rolului
jucat de fiecare domeniu al relaiei. Orice atribut al unei tabele oarecare trebuie s fie atomic,
adic s nu mai poat fi descompus n alte atribute.
Tuplul sau n-uplu reprezint un rnd sau o linie distinct de valori din cadrul unei tabele
(relaie) rezultnd c o relaie este un ansamblu de tupluri care poate fi definit extensiv (prin
indicarea listei tuturor tuplurilor ce o compun) i intensiv (prin indicarea predicatului de
apartenen a unui tuplu la relaia respectiv).
Dintr-un alt punct de vedere o relaie este ansamblul m-tuplurilor de valori definit astfel:
R = { t1, t2 , , tk, .tm },
unde tk = (dk1 , dk2 ,, dki,, dkn ), iar dk1 este o valoare n D1, d k2 este o valoare n
D2 , , dkn este o valoare n Dn;
n care:
n- reprezint ordinul lui R;
m- este cardinalitatea lui R.
Rezult c numrul tuplurilor dintr-o relaie reprezint cardinalitatea relaiei, n timp ce
numrul valorilor dintr-un tuplu definete gradul sau ordinul relaiei.
Dou tupluri sunt identice dac i numai dac pentru fiecare domeniu ele au aceeai
valoare.
Ansamblul minimal de atribute prin care se poate identifica n mod unic orice tuplu dintr-o
relaie reprezint cheia relaiei. Orice relaie poseda cel puin o cheie. Cnd cheia este constituit
dintr-un singur atribut, poart numele de cheie simpl, iar atunci cnd este format din mai multe
atribute ea se numete cheie compus.
Cheia primar a unei relaii (tabele) este un atribut sau grup de atribute care identific
fr ambiguitate fiecare tuplu (linie) a relaiei (tabelei)18.
La alegerea unei chei primare administratorul bazei de date trebuie s aib n vedere criterii
prin care s se asigure identificarea efectiv a tuplurilor (lungime, natur) .
Exist trei restricii pe care trebuie s le verifice cheia primar:
1. unicitatea o cheie identific un singur tuplu (linie) a relaiei;

18

Fotache ,M., Op. Cit., pp. 125-126

2. compoziia minimal atunci cnd cheia primar este compus, nici un atribut din
cheie nu poate fi eliminat fr distrugerea unicitii tuplului n cadrul relaiei (n
cazuri limit o cheie poate fi alctuit din toate atributele relaiei);
3. valorile non-nule valorile atributului sau ale ansamblului de atribute ce
desemneaz cheia primar sunt ntotdeauna specificate, deci ne-nule; nici un atribut
din compoziia cheii primare nu poate avea valori nule.
Dac ntr-o relaie exist mai multe combinaii de atribute care confer unicitate tuplului,
acestea sunt denumite chei candidate. Atunci cnd o cheie candidat nu este cheie primar este
considerat cheie alternativ (secundar).
Legtura ntre tuplurile din relaii diferite se realizeaz prin atribute sau combinaii de
atribute numite chei strine (externe). Cheile strine (coloanele de referin) sunt, aadar,
atribute sau combinaii de atribute care pun n legtur linii (tupluri) din relaii diferite.
n figura nr. 5.2 sunt prezentate cteva tabele i cheile asociate acestora pentru stabilirea
relaiilor dintre ele i pentru identificarea tuplurilor din coninutul lor.
FURNIZORI
COD-FURN NUME-FURNIZOR LOCALITATE CONT-BANCA

FACTURI
NR-FACTURA DATA-FACTURA COD-FURN

CONT-BANCA VALOARE

NOMEN-OBINV
COD-OBINV

DEN-OBINV UM

OBINV-RECEPT
NR-FACTURA

COD-OBINV

CANT

PRET-UNIT

Fig. nr. 5.2 Relaii i tipuri de chei

n relaia FURNIZORI:
1. COD-FURN cheie primar
2. NUME-FURNIZOR cheie alternativ
n relaia FACTURI:
3. NR-FACTURA cheie primar
4. COD-FURN cheie strin ctre relaia FURNIZORI
n relaia NOMEN-OBINV:

5. COD-OBINV cheie primar

n relaia OBINV-RECEPT:
6. NR-FACT i CODOBINV cheie primar
7. NR-FACT cheie strin ctre relaia FACTURI
8. COD-OBINV cheie strin ctre relaia NOMEN-OBINV
Schema relaiei se constituie din numele relaiei urmat de lista atributelor i eventual de
definirea domeniului lor19, fiind posibile mai multe reprezentri. Schema este cunoscut sub
numele de intensia relaiei. Ea este expresia proprietilor comune i invariante ale tuplurilor
care compun relaia. Spre deosebire de intensie, extensia unei relaii reprezint ansamblul
tuplurilor care compun la un moment dat relaia i este variabil n timp.
Extensia unei relaii (coninutul propriu-zis) este stocat fizic de obicei n spaiul asociat
bazei de date relaionale, este definit explicit i poart numele de relaie de baz. Dac nu este
memorat n baza de date (cazul aa-numitelor relaii virtuale) ea poart numele de relaii
derivate sau viziuni, necesitnd precizarea unei expresii relaionale care este evaluat la stabilirea
efectiv a tuplurilor care compun acest tip de relaie.
Schema relaional este un ansamblu de relaii semantic legate prin domeniul lor de
definire sau prin reguli de integritate.
Conceptul de relaie permite pe de o parte reprezentarea unei entiti din universul modelat
i o legtur semantic inter-entitate. ntr-o entitate, fiecrei legturi semantice i corespunde o
relaie. n teoria sistemelor, adugarea unui nou tuplu determin modificarea fizic a relaiei, n
timp ce din punct de vedere semantic, aceasta rmne neschimbat. Pentru definirea, fr
ambiguiti semantice, a unei relaii nu este suficient noiunea de domeniu.
Regulile de integritate constituie un anumit numr de controale care ar trebui s fie
satisfcute de ctre datele bazei, pentru a putea fi considerate coerente i concrete n raport cu
lumea real pe care o reflect20.
Modelul relaional se bazeaz pe urmtoarele restricii minimale: unicitatea cheii,
restricia referenial i restricia de entitate.
Unicitatea cheii. Ansamblul minim de atribute a crui cunoatere permite identificarea
unui n-uplet unic al relaiei se numete cheie. Conform acestei reguli ntr-o relaie R care are
cheia K, oricare ar fi tuplurile t1 i t2 trebuie satisfcut inegalitatea: t1(K) t2(K). Altfel spus,
dou n-upluri nu pot avea aceeai valoare pentru atributul cheie.
Restricia referenial (integritatea referirii). Dac un acelai atribut apare ntr-o relaie ca
cheie i ntr-o alt relaie ca non-cheie, orice valoare a atributului non-cheie trebuie s existe n

19
20

Morjon, J., Op. cit., p. 34

Date, C. J., Referencial integrity, 7th International on VLDB, Cannes, September, 1981, pp. 2-12

atributul cheie21. Respectnd aceast regul ntr-o relaie R1, care refer o relaie R2, valorile
cheii externe trebuie s figureze printre valorile cheii primare din relaia R2, sau s fie valori
nedefinite null.
Considerm pentru exemplificare urmtoarele trei relaii: STUDENT, SIT.SC i
EXAMEN. Restriciile refereniale sunt ilustrate n figura 5.3.
n relaia STUDENT NR_MATRICOL este cheie; iar cheia relaiei SIT.SC este format
din ansamblul atributelor NRMATRICOL, CODEXAMEN I DATAEX. Orice valoare pentru
NRMATRICOL din relaia SIT.SC trebuie s existe n NRMATRICOL din STUDENT (idem
pentru CODEXAMEN).
STUDENT NR. MATRICOL NUME STUDENT DATA NAST SECTIE

SIT. SC

EXAMEN

NR. MATRICOL COD EXAMEN

COD EXAMEN

DATA EX NOTA

DISCIPLINA

Fig. 5.3 Restricie referenial

Atributul NRMATRICOL (CODEX) n relaia STUDENT este numit cheie primar, iar n
relaia EXAMEN este numit cheie strin. Relaia SIT.SC poate fi numit i refereniat sau
desemnat, n timp ce relaiile STUDENT i EXAMEN pot fi numite refereniale sau
desemnante.
Restricia de entitate. Valorile oricrui atribut care face parte dintr-o cheie primar
trebuie s fie nenule. Unicitatea cheii impune ca la ncrcarea unui tuplu, valoarea cheii s fie
cunoscut. n felul acesta se elimin duplicarea tuplurilor. Restricia de integritate a entitii nu
se aplic cheilor externe dintr-o relaie, dac acestea nu aparin cheii primare.
Plecnd de la restricia de entitate, rezult c restricia de referin poate fi: forte i slab. O
restricie de referin este forte dac atributul cheii strine nu poate lua o valoare nul. O
restricie de referin este slab dac atributul cheii strine poate lua o valoare nul.
Pe lng restriciile minimale, modelul relaional poate oferi i restricii referitoare la
dependena datelor i de comportament.
Restriciile referitoare la dependena datelor privesc datele ce depind unele de altele i
pot fi: funcionale, multivaloare i de jonciune.

21

Morjon, J., Op. cit., p.35

Dependenele funcionale permit identificarea unui atribut sau grup de atribute prin
intermediul altui atribut sau grup de atribute.
Dependenele multivaloare se stabilesc ntre datele n care un atribut sau grup de atribute
poate prezenta mai multe valori pentru o singur valoare a unui alt atribut sau grup de atribute.
Dependenele de jonciune apar atunci cnd nu se pot manifesta dependene funcionale
sau multivaloare, exprimnd o relaie mai general.
Restriciile de comportament, la rndul lor pot fi, cel mai adesea, de domeniu i
temporale. Cele de domeniu impun ca valorile unui atribut s se ncadreze ntre anumite limite.
Cele temporale impun ca valorile rezultate n urma actualizrii s fie altele dect cele anterioare
actualizrii.
Avnd n vedere aspectele teoretice de mai sus prezentm n continuare cele 1 3 r e g u l i
(numerotate de la 0 la 12) prin care E.F. Codd definete i caracterizeaz modelul relaional22:
R0 regula de fundamentare (regula de baz): un sistem relaional de administrare a
bazelor de date trebuie s poat administra bazele de date n ntregime prin funciile sale
relaionale; aceasta nseamn c un SGBD relaional nu trebuie s mixeze caracteristicile
relaionale cu cele nerelaionale, el cuprinznd o parte de definire a datelor (DDL), o parte de
manipulare a datelor (DML) i o parte de integritate i control a datelor (DCL); totui, n practic
se constat c nici o implementare curent de SGBD nu respect aceast regul, deoarece conin
att caracteristici relaionale ct i nerelaionale;
R1 regula reprezentrii informaiei (The Information Rule): toate informaiile dintr-o
baz de date relaionale sunt reprezentate la nivel logic, explicit ca valori n tabele; datele sunt
stocate sub forma unor structuri tabelare, numite relaii, formate din rnduri (tupluri) i coloane
(atribute) ; o astfel de structur ofer o serie de avantaje precum: claritate, generalitate
(majoritatea tipurilor de date pot fi reprezentate sub aceast form), flexibilitate (structura poate
fi modificat att pe rnduri ct i pe coloane); folosind o astfel de structur, asupra datelor pot fi
aplicate operaii din teoria mulimilor ca: selecia, proiecia, produsul cartezian, reuniunea,
intersecia etc.; Codd apreciaz c un SGBD care nu respect aceast regul nu poate fi
considerat relaional;
R2 regula accesului garantat la date (Guaranteed Access): ntr-o baz de date relaional
orice valoare are accesul garantat dac se folosete o combinaie ntre numele tabelului (relaiei),
valoarea cheii primare i numele atributului; fiecare relaie trebuie s conin o cheie primar,
adic un atribut sau o combinaie de atribute, care s identifice n mod unic un tuplu (este de
remarcat, totui, faptul c n majoritatea implementrilor de SQL este permis duplicarea);

22

Perkins, J., Morgan, B., SQL fr profesor, n 14 zile, Editura Teora, Bucureti, 1997, p. 23

R3 regula prelucrrii sistematice a valorii nule (Systematic Null Value Support),

cunoscut i sub numele de regula reprezentrii informaiei necunoscute: SGBD-ul asigur un
suport sistematic pentru tratamentul valorilor denumite NULL (date necunoscute sau
neaplicabile la momentul respectiv), fcnd diferena dintre o valoare fixat intenionat pe 0
(zero) sau un ir vid de caractere i o valoare necunoscut; majoritatea implementrilor actuale
de SQL respect parial aceast regul; facem precizarea c pentru realizarea integritii datelor
n modelul relaional sunt folosite cheile primare i secundare care nu permit utilizarea tipului de
date NULL;
R4 regula dicionarului - catalogului relaional activ on-line (Active On-line Relational
Catalog): descrierea bazei de date i a componentelor sale este realizat la nivel logic sub form
de tabele, putnd fi interogat n timp real prin intermediul limbajului de manipulare a bazei de
date; toate informaiile ce privesc relaiile, vizualizrile, indexrile etc. trebuie s poat fi stocate
sub forma unor relaii ce formeaz un catalog de sistem (dicionar), i prin urmare s poat fi
accesate n acelai mod ca i datele propriu-zise prin intermediul acelorai comenzi;
implementrile actuale de SQL respect aceast regul, interogarea datelor realizndu-se prin
intermediul frazei SELECT;
R5 regula limbajului de interogare sau regula sublimbajului multilateral al datelor
(Comprehensive Data Sublanguage): trebuie s existe cel puin un limbaj multilateral, cu o
sintax bine definit i care s permit definirea i manipularea datelor, stabilirea regulilor de
integritate, autorizarea accesului i realizarea tranzaciilor; aceast regul cere ca manipularea
datelor dintr-o baz de date s se fac prin intermediul unui limbaj de nivel nalt; n general toate
implementrile SQL respect aceast regul;
R6 regula actualizrii tabelelor virtuale /vederi relaionale (View Updating Rule): un
SGBD trebuie s stabileasc dac o tabel virtual poate fi actualizat i s stocheze rezultatul
interogrii ntr-un dicionar de tipul unui catalog de sistem; majoritatea implementrilor SQL
permit crearea unei relaii ce conine detalii referitoare la tabelele virtuale, detalii n baza crora
s se accepte sau nu operaiunea de actualizare;
R7 regula limbajului de nivel nalt sau regula inserrii, actualizrii i tergerii la nivel
de mulimi (Set Level Insertion, Update and Deletion): SGBD-ul permite pe lng regsirea
datelor la nivel de mulimi i manipularea datelor prin inserri, actualizri i tergeri; aceste
operaii trebuie s poat fi aplicate att n mod interactiv ct i prin intermediul unui limbaj
gazd;
R8 regula independenei fizice a datelor (Physical Data Independence): ntr-un SGBD
trebuie s se separe aspectul fizic al datelor(stocarea i accesarea datelor) de aspectul logic
(programele de aplicaii); deteriorarea metodelor de acces fizic sau a structurilor de memorare
nu afecteaz din punct de vedere logic programele de aplicaie i utilizrile bazei;

R9 regula independenei logice a datelor (Logical Data Independence): modificarea

semantic a schemei bazei (ex. normalizarea relaiilor pentru creterea performanelor) nu
afecteaz din punct de vedere logic datele prin operaiile de manipulare;
R10 regula independenei datelor din punct de vedere al
integritii (Integrity
Independence): limbajul bazei de date definete regulile de integritate care trebuie respectate i
memorate n catalogul relaional on-line (dicionarul de date) i nu n programe; un SGBD
trebuie s permit operaii de validare a datelor, operaii gestionate prin intermediul cataloagelor
de sistem (dicionare); aceste operaii nu trebuie fcute prin scrierea de programe, ci prin
intermediul limbajului relaional, n particular SQL;
R11 regula independenei datelor din punct de vedere al distribuirii (Distribution
Independence): distribuirea datelor pe mai multe calculatoare dintr-o reea nu trebuie s afecteze
programele de aplicaii; SGBD-ul relaional trebuie s respecte independena de distribuie avnd
un limbaj care s permit aplicaiilor s rmn logic nemodificate atunci cnd datele sunt
transferate de la o baz de date local la una distribuit sau atunci cnd datele sunt distribuite;
aceast regul este considerat ca fiind cea mai dur i printre cele mai dificil de respectat ( de
altfel ANSI-SQL nu o menioneaz n specificaiile sale);
R12 regula versiunii procedurale a SGBD sau regula de nesubversiune (Nonsubvertion):
orice component procedural a unui SGBD trebuie s respecte aceleai restricii de integritate
ca i componenta relaional (de ex. dac la manipularea datelor o dat dintr-o coloan este de
tipul NOT NULL nici o metod de accesare a acestei coloane nu trebuie s permit
introducerea unei valori NULL ; atunci cnd SGBD posed un limbaj de nivel inferior (codmain i de asamblare) acesta nu poate nclca regulile de integritate definite prin limbajul
relaional al bazei de date.
n literatura de specialitate se obinuiete ca n funcie de tipul cerinelor exprimate regulile
s fie grupate n 5 categorii23:
1. reguli de baz (fundamentale) R0 i R12;
2. reguli structurale R1 i R6;
3. reguli privind integritatea datelor R3 i R10;
4. reguli privind manipularea datelor R2, R4, R5, R7;
5. reguli privind independena datelor R8, R9, R11.
Dr. E.F. Codd a extins numrul acestor reguli de la 13 publicate n 1986, la un numr de
100 n 1990. Trebuie remarcat ns, c nici un sistem de gestiune a bazelor de date comercializat,
nu respect absolut toate regulile definite de Codd.24 Astfel, la un SGBD trebuie apreciat

23
24

Lungu, I. .a., Op. cit., p. 135

Pascu, C., Pascu, A. , Totul despre SQL, Editura Tehnic, Bucureti, 1994, p. 22

msura n care acesta este relaional, deci, numrul regulilor respectate. De exemplu produsul
DB2 respect doar apte reguli din cele 13 prezentate mai sus.

NORMALIZAREA BAZELOR DE DATE RELAIONALE

Normalizarea. Coninut i obiective
Normalizarea unei relaii const n reprezentarea acesteia sub o form canonic, respectnd
anumite criterii de definire semantic a structurii bazei de date, precum i integritatea datelor25.
Uzual, prin normalizare se desemneaz procesul de stabilire a structurii tabelelor unei
BDR, a cheilor primare, a cheilor strine i a altor restricii. Obiectivele normalizrii sunt:
1. Eliminarea anomaliilor de actualizare.
2. Diminuarea nevoii de reorganizare periodic a modelului.
3. Reprezentarea diverselor conexiuni dintre atributele bazei.
4. Suport pentru utilizarea unor algoritmi eficieni privind cutarea tuplurilor care
ndeplinesc anumite condiii specificate (interogarea BD).
nscris de obicei n activitile de analiz i proiectare ale bazelor de date, normalizarea a
constituit obiectul a numeroase studii; nu se poate afirma c exist o unanimitate de idei i
instrumente. Pe de alt parte, importana normalizrii nu trebuie absolutizat. Fragmentarea
tabelelor n altele mai simple are n vedere i optimizarea vitezei de acces, reducerea traficului pe
reea etc. n plus, preocupri de dat mai recent vizeaz nglobarea, n normalizare, a unor
concepte privind gestiunea domeniilor atributelor i extinderea sa ctre tehnologia obiectual.
Teoria clasic a normalizrii este construit n jurul a cinci forme normalizate. Codd,
printele modelului relaional de organizare a datelor, a definit iniial trei forme normalizate 26,
notate prin 1FN, 2FN i 3FN. ntruct, ntr-o prim formulare, definiia 3FN ridica ceva
probleme, Codd i Boyce au elaborat o nou variant, cunoscut sub numele Boyce-Codd
Normal Form (BCNF).
Dei este vorba, n principiu, de o formulare mai riguroas a aceleai 3FN, BCNF este
prezentat, n majoritatea lucrrilor, separat.
Formele 4 i 5, care sunt legate de numele lui Fagin, sunt tratate mai cu reinere n
literatura consacrat analizei bazelor de date relaionale. Ba chiar unele lucrri, cu tent mai
pragmatic, se opresc, declarat, la 3FN pe care o consider suficient n rezolvarea majoritii
cazurilor practice.
25

Filip, M., Grama, A., Medii de programare. Abordri teoretice, Editura Fides, Iai, 1998, p.204
Codd, E.F., Further normalization of the database relational model, DataBase Systems, Courant Computer
Science Symposia Series, Vol.6, Englewood Cliffs, N.J.,Prentice-Hall, 1972
26

Fundamentul normalizrii BDR l constituie dependenele dintre atribute. Primele trei

forme normalizate pot fi determinate pe baza dependenelor funcionale elementare (totale) i
tranzitive. Forma a patra (4FN) se bazeaz pe dependenele multivaloare, n timp ce a cincea
form normalizat (5FN) pe dependenele de jonciune.
Prin normalizare, o relaie este descompus reversibil, obinndu-se o schem relaional
optim. Metodologia de normalizare nu este unic i a constituit domeniu de cercetare pentru o
serie ntreag de autori precum P.A. Bernstein, E.F. Codd, C. Delobel, A. Zaniola etc.

Prima form normalizat (1FN)

Unele lucrri definesc o relaie aflat n 1FN ca acea relaie n care fiecare atribut conine
o valoare atomic, altfel spus, toate atributele sunt ne-decompozabile.
n tabela FP (figura nr. 5.13) toate atributele (datele) sunt atomice. Ar putea exista o
obieciune, relativ la atributul Adresa, n sensul c acesta trebuie descompus n atributele:
Strada, Numr, ba chiar i Bloc, Scar, Etaj, Apartament, (exist SRL-uri care au ca sediu
declarat locuina proprietarilor). Avnd n vedere aceast diversitate de situaii, am preferat un
singur atribut atotcuprinztor, Adresa. De aici ncolo, va fi ceva mai greu s aflm o serie de
informaii, de genul: "care dintre clieni au sediul pe strada Libertii" sau "care dintre furnizori
au sediul la etajul 3". S nu uitm, ns, c n asemenea interogri poate fi folosit, n SQL,
operatorul LIKE.
FP
Numr
Factur
17254
8828
27447
17261
87663
87665
17320
17295

Cod
Furnizor
1003
1001
1004
1003
1008
1008
1006
1003

Nume
Furnizor

Adresa

OCCO SRL
TEXTILA SA
FILATURA SA
OCCO SRL
ALFA SRL
ALFA SRL
EPSILON SRL
OCCO SRL

Pcurari, 155
B-dul Copou, 87
B-dul Unirii, 105
Pcurari, 155
Prosperitii, 15
Prosperitii, 15
Corupiei, nr.12
Pcurari, 155

Cod
Potal

Localitate

6600
6600
5300
6600
5725
5725
6750
6600

Iai
Iai
Focani
Iai
Pacani
Pacani
Iai
Iai

Jude

Data

Valoare

Iai
Iai
Vrancea
Iai
Iai
Iai
Iai
Iai

17.06.99
17.06.99
18.06.99
18.06.99
18.06.99
19.06.99
20.06.99
24.06.99

17000000
2850000
5850000
28500000
35700000
8700000
11000000
3000000

Fig. nr.
5.13. Structura tabelei FP n 1FN

Prin urmare, n unele cazuri, declararea unui atribut ca fiind atomic sau nu ine de intenia
celui care proiecteaz BD sau de flexibilitatea SGBD-ului. Spre exemplu, "pe vremuri",
atributele de tip dat calendaristic erau supuse unei nemiloase descompuneri n trei atribute
vdit atomice, Zi, Lun, An. Astzi, ns, orice SGBD "lucreaz" cu atribute, variabile i
constante de tip dat calendaristic, astfel nct suntem scutii de atomizarea de mai sus.
Ali autori adaug la definiia anterioar, legat de atributele atomice, i restricia: toate
atributele ce compun relaia s fie n dependen funcional fa de cheia relaiei, dei este,
oarecum, o tautologie, ntruct una din "poruncile" ce trebuie ndeplinite de orice tabel care vrea

s fie relaional este cea cunoscut sub numele restricia de entitate, potrivit creia ntr-o relaie
nu pot exista dou tupluri identice sau, altfel spus, ntr-o relaie trebuie s existe un atribut sau
combinaie de atribute ale cror valori s deosebeasc orice tuplu de toate celelalte sau orice
relaie posed o cheie primar.
n figura nr. 5.14, tabela LINII_ARTICOLE_CONTABILE2, conine, pe primele dou
linii, grupuri repetitive, pentru atributele ContDebitor, respectiv ContCreditor, datorit faptului
c operaiunile (nregistrrile) contabile din nota 150 sunt compuse.
LINII_ARTICOLE_CONTABILE2
NotaContabil
150
150
151

Data
30.11.99
30.11.99
01.12.99

Operaiune
1
2
1

ContDebitor
300, 4426
401
5121

ContCreditor
401
5311, 5121
700

Suma
1 180 000
1 180 000
525 000

Fig. nr.

5.14. Tabela LINII_ARTICOLE_CONTABILE2

O alt accepiune dat grupurilor repetitive este legat de extinderea pe orizontal a

tabelelor, prin duplicarea forat a unor atribute. Revenim la figura nr. 5.14. Pentru a nltura
grupurile repetitive de pe primele dou linii, putem fi tentai s modificm structura tabelei, ca n
figura nr. 5.15.
LINII_ARTICOLE_CONTABILE3
Nota
Contabil
150
150
151

Data

Operaiune

30.11.99
30.11.99
01.12.99

1
2
1

Cont
Debitor1
300
401
5121

Cont
Debitor2
4426

Cont
Creditor1
401
5311
700

Cont
Creditor2
5121

Suma
1 180 000
1 180 000
525 000

Fig. nr.

5.15. Tabela LINII_ARTICOLE_CONTABILE3

Soluia e ct se poate de nefericit. Dei tabela se afl n prima form normalizat, preul
pltit este mult prea mare. Deoarece, n practic, o nregistrare (operaiune) contabil poate avea
10-15 conturi pe debit sau pe credit, modificarea structurii tabelei ar deveni de-a dreptul hilar.
n concluzie, tabela LINII_ARTICOLE_CONTABILE din figura nr. 5.14 este n prima
form normalizat (1FN).
Observaii
1. Atomicitatea atributelor ntr-o baz de date relaional constituie o limit serioas a modelului,
datorit imposibilitii adaptrii BDR la specificul unor domenii ca multimedia, CAD etc.
2. Nu orice tabel este n 1FN, chiar dac toate valorile atributelor sunt atomice. n conformitate cu
restricia de entitate, tuplurile relaiei trebuie s fie distincte. n plus, atributele care alctuiesc
cheia primar nu pot avea valori nule.

Tabela FP, a crei schem este prezentat n figura nr. 5.13, se afl n 1FN, cheia sa
primar fiind desemnat prin perechea (NumrFactur, CodFurnizor).
Implicit, deci, exist dependenele funcionale:

(1)
(2)
(3)
(4)
(5)
(6)
(7)

(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)
(NumrFactur, CodFurnizor)

NumeFurnizor
Adresa
CodPotal
Localitate
Jude
Data
Valoare

Structura tabelei FP prezint cteva neajunsuri, legate, n primul rnd, de faptul c nici un
atribut ce face parte din cheia primar nu poate avea valori nule.
Din aceast cauz apar probleme la adugarea unui tuplu n relaia FP. Spre exemplu, la
magazia ntreprinderii au fost recepionate cteva materiale care au sosit cu un Aviz de expediie
trimis de un nou furnizor. Fiind vorba de un furnizor nou, se pune problema de a-l introduce n
baza de date. I se atribuie codul 1010, i se cunoate denumirea i sediul (adresa, localitatea).
Deoarece materialele au sosit numai cu avizul de expediie, pn la primirea facturii ne este
imposibil s introducem datele despre furnizor n tabela FP. De ce oare? Deoarece cheia primar
a relaiei este compus (NumrFactur, CodFurnizor), i nu cunoatem valoarea atributului
NumrFactur, care prezint, deocamdat, valoarea NULL (necunoscut). Astfel, pentru a
introduce date despre un nou furnizor, trebuie s ateptm s soseasc prima factur de la acesta,
chiar dac produsele descrise n factur pot sosi cu zile sau chiar sptmni nainte.
Probleme serioase apar i la modificarea unor linii. Astfel, furnizorul ALFA SRL i mut
sediul de la adresa "Prosperitii, 15", noua adres fiind "Iacobov se ntoarce, nr. 13 bis", n
cadrul aceleai localiti (Pacani).
Un client nu poate avea, la un moment dat, dect o singur adres. Am definit n capitolul
anterior, n cadrul tabelei FP dependena funcional
CodFurnizor Adresa.

Or, dac n tabel ar co-exista i adresa veche a furnizorului, i cea nou, la o aceeai
valoare a atributului CodFurnizor ar exista dou valori distincte ale atributului Adresa.
Ce facem n acest caz ? Fie renunm la DF de mai sus, fie modificm toate vechile valori
ale atributului Adresa, actualizndu-le.
Prima variant prezint marele dezavantaj c altereaz partea de analiz a BDR, i, n unele
cazuri, atrage revizuirea ntregii scheme a BDR, deoarece vizeaz aspectul constant al relaiei,
structura sa.
A doua variant ridic, la rndul su, nite probleme deloc nltoare. Astfel, va trebui s
modificm valoarea atributului Adresa pentru toate facturile primite de la furnizorul respectiv,
ceea ce nu e chiar simplu. i ce-ai zice dac modificarea adresei se produce n luna mai 1997 i
avem, arhivate, facturi primite de la acest furnizor nc din anul 1993 ?
Nici operaiunea de tergere a unei linii din tabela FP nu este scutit de discuii. S
presupunem c trebuie s tergem linia aferent facturii 17320, primit de la furnizorul

EPSILON SRL. Dup cum se observ n figura nr. 5.12, aceasta este singura factur primit n
acest an de la furnizorul EPSILON SRL, iar facturile anului precedent au fost deja arhivate
pentru a descongestiona baza de date. tergerea singurei facturi aferente acestui furnizor atrage,
inevitabil, pierderea oricrei date despre EPSILON SRL. Ulterior tergerii, la o eventual
consultare prin care s-ar dori extragerea tuturor furnizorilor firmei, EPSILON SRL nu ar mai fi
"prezent", dei, de fapt, EPSILON reprezint un furnizor important pentru care, ntmpltor, n
primele dou luni ale anului curent nu exist nici o factur primit.

A doua form normalizat (2FN)

ncepnd cu a doua form normalizat, relaiile pot fi decupate n sub-relaii, n scopul
diminurii problemelor legate de stocare i actualizare.
Heath a demonstrat27 c orice relaie alctuit din trei atribute, notat R(X, Y, Z), n care
exist dependenele funcionale X Y i X Z, poate fi descompus n dou relaii
R1(X, Y) i R2(X, Z). R1 i R2 reprezint proieciile relaiilor R pe atributele X i Y, respectiv X
i Z.
Esenial este faptul c descompunerea se face fr pierderi de informaii, adic R poate fi
"recompus" prin jonciunea tabelelor R1 i R2.
O relaie se afl n 2FN dac:
Se afl n 1FN.
Toate DF ce leag cheia primar la celelalte atribute sunt DF elementare (totale).
Problema trecerii unei relaii din 1FN n 2FN se pune numai cnd cheia primar a relaiei
este compus din mai multe atribute.
Trecerea de la 1FN la 2FN se poate realiza dup urmtoarea succesiune de pai:
a) Se stabilesc dependenele totale (elementare), inclusiv cele tranzitive, cu excepia celor
n care destinaia este un atribut component al cheii primare.
b) Se trec n revist toate dependenele care au ca surs (determinant) un atribut sau subansamblu de atribute din cheia primar.
c) Pentru fiecare atribut (sau sub-ansamblu) al cheii de la pasul b), se creeaz o relaie care
va avea drept identificator primar atributul (subansamblul) respectiv, iar celelalte
atribute vor fi cele care apar ca destinaii n dependenele de la pasul b).
n figura nr. 5.13 a fost prezentat structura tabelei FP care este n 1FN, cheia sa primar
fiind desemnat prin perechea (NumrFactur, CodFurnizor).

27

Heath, I. J., Unacceptable File Operations in a Relational Database, Proc.1971 ACM SIGFIDET Workshop on Data
Description, Access and Control, nov. 1971

Conform definiiei cheii primare, exist dependenele funcionale (1)-(7) identificate n

paragraful 5.4.2. ntr-un paragraful anterior am vzut c primele cinci dintre ele nu sunt
elementare, datorit existenei dependenelor:
(8)
(9)
(10)
(11)
(12)

CodFurnizor
CodFurnizor
CodFurnizor
CodFurnizor
CodFurnizor

NumeFurnizor
Adresa
CodPotal
Localitate
Jude

ntruct, n FP exist dependene funcionale ne-elementare (pariale), rezult ca aceasta nu

este n 2FN.
Aplicm cei trei pai pentru aducerea relaiei FP n 2FN:
a) Dependenele totale (elementare), inclusiv cele tranzitive sunt cele apte prezentate n
exemplul 1 din paragraful precedent.
b) Dependenele care au ca surs un atribut/sub-ansamblu din cheia primar sunt (8), (9),
(10), (11) i (12).
c) Dac, pentru fiecare atribut component al cheii care apare ca surs n dependene
funcionale, se creeaz o relaie ce are drept identificator primar atributul respectiv,
celelalte atribute fiind destinaiile dependenelor de la punctul b), relaia universal FP
se sparge n dou tabele, FP1 i FP2, ale cror structuri sunt prezentate n figura nr. 5.16.
FP1
NumrFactur
17254
8828
27447
17261
87663
87665
17320
17295

CodFurnizor
1003
1001
1004
1003
1008
1008
1006
1003

Data
17.06.95
17.06.95
18.06.95
18.06.95
18.06.95
19.06.95
20.06.95
24.06.95

Valoare
1700000
285000
585000
2850000
3570000
870000
1100000
300000

FP2
CodFurnizor
1003
1001
1004
1008
1006

NumeFurnizor
OCCO SRL
TEXTILA SA
FILATURA SA
ALFA SRL
EPSILON SRL

Adresa
Pcurari, 155
B-dul Copou, 87
B-dul Unirii, 10
Prosperitii, 15
Corupiei, nr.14

CodPotal
6600
6600
5300
5725
6750

Localitate
Iai
Iai
Focani
Pacani
Iai

Jude
Iai
Iai
Vrancea
Iai
Iai

Fig. nr.
5.16. Tabelele FP1 i FP2 n 2FN

Avantaje ale 2FN

Structura prezentat n figura nr. 5.16 elimin multe din problemele ridicate de 1FN.
Astfel, putem introduce date despre un nou furnizor, pn la sosirea primei facturi de la acesta,

deoarece singura tabel implicat este FP2 a crei cheie primar este constituit din atributul
CodFurnizor.
Modificarea adresei unui furnizor afecteaz o singur linie din tabela FP2, deci au fost
eliminate multe dintre anomaliile care apreau la actualizarea valorii unor atribute.
De asemenea, tergerea unei facturi primite - care presupune eliminarea unei linii din
tabela FP1 - nu mai prezint riscul eliminrii definitive a datelor generale depre un furnizor,
deoarece acestea se gsesc n tabela FP2.
Problemele care persist sunt legate de tabela FP2, n sensul repetrii valorilor atributelor
Localitate i Jude pentru toi furnizorii ce provin dintr-o aceeai localitate.

A treia form normalizat

O relaie se afl n 3FN dac:
Se afl n 1FN.
Toate atributele care nu aparin cheii primare nu depind funcional de un alt atribut
(ansamblu de atribute) care nu face parte din cheie.
A doua condiie poate fi exprimat i n maniera: toate dependenele funcionale care leag
cheia primar de celelalte atribute sunt directe (netranzitive).
Trecerea din 2FN n 3FN se face, pentru o relaie, n urmtoarea manier:
a) Se identific toate atributele ce nu fac parte din cheie i care sunt surse ale unor
dependene funcionale.
b) Pentru toate atributele identificate la punctul a), se constituie cte o relaie n care cheie
primar va fi atributul respectiv, iar celelate atribute destinaiile din dependenele
considerate.
Observaie
Operaiile a) i b) se repet i pentru relaiile "proaspt" obinute prin descompunere.

n paragraful anterior, pornind de la tabela FP, aflat n 1FN (structura sa este prezentat n
figura nr. 5.13), au fost obinute dou tabele, FP1 i FP2, ambele aflate n 2FN.
S analizm structura tabelei FP2. Dependenele
CodFurnizor Localitate
CodFurnizor Jude

sunt tranzitive, deoarece exist:

CodPotal Localitate
CodPotal Jude

Prin urmare, relaia FP2 nu este n a treia form normalizat. Aplicm algoritmul descris
mai sus:
a) atributul CodPotal nu face parte din cheie i constituie surs ntr-o serie de dependene
funcionale;

b) tabela FP2 se sparge n tabelele FP21 i FP22, ale cror structuri sunt prezentate n
figura nr. 5.17.
FP21
CodFurnizor
1003
1001
1004
1008
1006

NumeFurnizor
OCCO SRL
TEXTILA SA
FILATURA SA
ALFA SRL
EPSILON SRL

Adresa
Pcurari, 155
B-dul Copou, 87
B-dul Unirii, 10
Prosperitii, 15
Corupiei, nr.14

CodPotal
6600
6600
5300
5725
6750

FP22
Cod-Potal
6600
5300
5725
6750

Jude
Iai
Vrancea
Iai
Iai

Localitate
Iai
Focani
Pacani
Tg. Frumos

Fig. nr. 5.17. Tabelele FP21 i FP22

n concluzie, tabela FP, adus n 3FN, se prezint sub forma a trei tabele, FP1, FP21 i
FP22, cu structurile descrise n figura nr. 5.18.
FP1
NumrFactur

CodFurnizor

Data

Valoare

FP21
CodFurnizor

NumeFurnizor

Adresa

CodPotal

FP22
CodPotal

Localitate

Jude

Fig. 5.18. Structura tabelelor FP1, FP21 i FP22 aflate n 3FN

Cele trei forme normalizate prezint o importan deosebit, considerndu-se, c, n

general, o baz de date aflat n 3FN are o structur satisfctoare, din punct de vedere al
raportului anomalii de stocare - vitez de acces (numr de jonciuni pentru obinerea
informaiilor).

COMENZI PENTRU INTEROGAREA BAZELOR DE DATE.

FRAZA SELECT
n SQL o interogare se formuleaz printr-o fraz SELECT. Aceasta prezint trei clauze
principale: SELECT, FROM i WHERE.
SELECT corespunde operatorului proiecie din algebra relaional, fiind utilizat
pentru desemnarea listei de atribute (coloanele) din tabela-rezultat;
FROM este cea care permite enumerarea relaiilor din care vor fi extrase informaiile
aferente consultrii;
prin WHERE se desemneaz predicatul selectiv al algebrei relaionale, relativ la
atribute ale relaiilor care apar n clauza FROM.
La modul general o consultare simpl n SQL poate fi prezentat astfel:
SELECT C1, C2, ..., Cn
FROM R1, R2, ..., Rm
WHERE P
Execuia unei fraze SELECT se concretizeaz n obinerea unei tabele (relaii) rezultat.
Acest poate fi o tabel propriu-zis sau o tabel temporar (care, de obicei, nu poate fi
actualizat), dar i o tabel derivat (imagine). Uneori tabela rezultat poate fi obinut sub
"forma" unei variabile-tablou.
Ci - reprezint coloanele (care sunt atribute sau expresii de atribute) tabelei-rezultat;
Rj - sunt relaiile ce trebuie parcurse pentru obinerea rezultatului;
P - este predicatul (condiia) simplu sau compus ce trebuie ndeplinit de tupluri pentru a
fi incluse n tabela-rezultat.
Cnd clauza WHERE este omis, se consider implicit c predicatul P are valoarea logic
"adevrat".
Dac n locul coloanelor C1, C2, ... Cn apare simbolul "*", n tabela-rezultat vor fi incluse
toate coloanele (atributele) din toate relaiile specificate n clauza FROM. De asemenea, n
tabela-rezultat, nu este obligatoriu ca atributele s prezinte nume identic cu cel din tabela
enumerat n clauza FROM. Schimbarea numelui se realizeaz prin opiunea AS.
Rezultatul unei fraze SELECT l vom considera ca fiind sub forma unei tabele oarecare.
Trebuie avut n vedere, ns, c rezultatul interogrii poate fi obinut i sub forma unei tabele

temporare sau chiar a unei variabile-tablou (matrice). n unele SGBD-uri, cum ar fi FoxPro,
formatul general al frazei SELECT conine i clauza INTO.
SELECT
FROM
INTO destinaie
WHERE

Destinaie specific dac se va obine o tabel "normal", o tabel temporar (tabel care
se terge automat la nchiderea sa) sau o variabil-tablou. Dac clauza INTO nu este utilizat,
atunci n urma interogrii se obine o tabel temporar cu numele predeterminat (Query).
Uneori, tabela rezultat ("normal" sau temporar) "ncalc" poruncile modelului relaional.
Conform restriciei de entitate, ntr-o relaie nu pot exista dou linii identice. Or, n SQL, tabela
obinut dintr-o consultare poate conine dou sau mai multe tupluri identice.
Spre deosebire de algebra relaional, n SQL nu se elimin automat tuplurile identice
(dublurile) din tabela-rezultat. Pentru aceasta este necesar utilizarea opiunii DISTINCT:
SELECT DISTINCT C1, C2, ..., Cn
FROM R1, R2, ..., Rm
WHERE P

LOCALITI
CodPostal

Jude

Localitate

6600

Iai

Iai

5300

Focani

Vrancea

5725

Pacani

Iai

6750

Tg. Frumos

Iai

CLIENI
CodClient
1001

NumeClient
TEXTILA SA

Adresa
Bld. Copou, 87

CodPostal
6600

1002

MODERN SRL

Bld. Grii, 22

5300

1003

OCCO SRL

NULL

6600

1004

FILATURA SA

Bld. Unirii, 145

5300

1005

INTEGRATA SA

I.V.Viteazu, 115

5725

1006

AMI SRL

Galaiului, 72

6750

1007

AXON SRL

Silvestru, 2

6600

1008

ALFA SRL

Prosperitii, 15

5725

FACTURIEMISE
NrFactur

CodClient

Data

ValoareTotal

TVAColectat

111111

1003

17.06.2000

17000000

2714286

111112

1001

17.06.2000

2850000

455042

111113

1004

18.06.2000

5850000

934034

111114

1003

18.06.2000

28500000

4550420

111115

1008

18.06.2000

35700000

5700000

111116

1008

19.06.2000

8700000

1389076

111117

1006

20.06.2000

11000000

1756303

111118

1007

23.06.2000

15000000

2394958

111119

1005

24.06.2000

47250000

7544118

111120

1003

24.06.2000

3000000

478992

111121

1001

24.06.2000

4250000

678571

111122

1007

24.06.2000

8750000

1397059

111123

1006

25.06.2000

6600000

1053782

111124

1004

25.06.2000

38650000

6171008

111125

1003

30.06.2000

12850500

2051761

111126

1002

01.07.2000

54250000

8661765

Figura nr. 6.1. Baza de date utilizat n exemple

n concluzie, o fraz SELECT, n forma n care a fost prezentat, corespunde:

unei selecii algebrice (clauza WHERE - P)
unei proiecii (SELECT - Ci)
unui produs cartezian (FROM - R1 R2 ... Rm)
i conduce la obinerea unei noi relaii (tabele-rezultat) cu n coloane, fiecare coloan fiind:
un atribut din R1, R2, ..., Rm sau
o expresie calculat pe baza unor atribute din R1, R2, ..., Rm.
n exemplele incluse n acest capitol se va utiliza baza de date prezentat n figura 6.1.
Exemplu
Care este, pentru fiecare factur emis, valoarea fr TVA ?

SELECT NrFactur, ValoareTotal - TVAColectata AS ValFaraTVA

FROM FACTURIEMISE

Tabela rezultat din figura 6.2 conine dou atribute: NrFactur i ValFaraTVA. Ultimul
este un cmp calculat.

Figura nr. 6.2. Exemplu de cmp calculat (ValFaraTVA)

Interogri care utilizeaz operatorii asambliti din algebra relaional

Reuniunea
SELECT *
FROM R1
UNION
SELECT *
FROM R2

Operatorul pentru reuniune este deci UNION. De remarcat c, la reuniune, SQL elimin
automat dublurile, deci nu este necesar utilizarea clauzei DISTINCT. Operatorul UNION este
prezent n toate SGBD-urile importante.

Intersecia
Pentru realizarea interseciei a dou tabele, R1 i R2 se utilizeaz operatorul INTERSECT:
SELECT *
FROM R1
INTERSECT
SELECT *
FROM R2

Dac n produsele profesionale, precum DB2 (IBM) sau Oracle operatorul este prezent, n
schimb multe din cele din categoria uoar, precum Visual Fox Pro, INTERSECT rmne un
deziderat, funcionalitatea sa realizndu-se prin subconsultri (operatorii IN i EXISTS) sau,
uneori, prin jonciune.

Diferena
Diferena dintre tabelele R1 i R2 se realizeaz utiliznd operatorul MINUS sau EXCEPT.
Fraza SELECT urmtoare funcioneaz n Oracle.
SELECT *
FROM R1
MINUS
SELECT *

FROM R2

n DB2 MINUS trebuie nlocuit cu EXCEPT, iar n Visual FoxPro exist nici MINUS i
nici EXCEPT, astfel nct, ca i n cazul interseciei, este necesar a se recurgere la ali operatori,
precum IN sau EXISTS.

Produsul cartezian
n SQL nu exist operator explicit pentru efectuarea produsului cartezian. Dac n clauza
FROM apar dou relaii, R1 i R2, atunci, n lipsa unei condiii de jonciune formulat n clauza
WHERE, tabela rezultat va conine liniile obinute din produsul cartezian R1 R2.
SELECT *
FROM R1, R2

Interogri care utilizeaz operatorii relaionali din algebra relaional

Selecia
Exemplu 1
Care sunt localitile din judeul Iai n care firma are clieni ?
Tabela n care se afl rezultatul i asupra creia se aplic predicatul de selecie este LOCALITI.
Predicatul este Jude = "Iai". Fraza SELECT va avea forma:
SELECT *
FROM LOCALITI
WHERE Jude = "Iai"
Rezultat:

CodPostal
6600
5725
6750

Jude

Localitate
Iai
Pacani
Tg. Frumos

Iai
Iai
Iai

Exemplu 2
Care dintre facturile emise dup 23.06.98 prezint valoarea mai mare sau egal cu
3 000 000 lei ?
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND ValoareTotala >= 3000000
Rezultat:
NrFactur
CodClient
111119
1005

Data
24.06.2000

ValoareTotal
4 725 000

TVAColectat
850 500

111124
111126

1004
1002

25.06.2000
01.07.2000

3 850 000
5 425 000

693 000
976 500

Dup cum se observ, operatorul AND a fost utilizat pentru a introduce un "I" logic, dup
cum OR se utilizeaz pentru SAU logic. n SQL, pentru comparare, n afara operatorilor
"clasici" specificai mai sus, pot fi utilizai i ali operatori, dintre care n acest paragraf ne vom
opri la:
BETWEEN (ntre, cuprins ntre),
LIKE (ca i, la fel ca),
IN (n) i
IS NULL.
Operatorul BETWEEN
Acest operator permite specificarea unui interval de valori n care trebuie s se ncadreze
cmpul/expresia testat. Acest interval se refer la valori numerice sau la date calendaristice.
Exemplu 3
Se reformuleaz ultima interogare:
Care sunt facturile emise dup 23.06.2000 i care au valoarea cuprins ntre 3 000 000 i
4 000 000 lei ?
Fr operatorul BETWEEN fraza SELECT se scrie:
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND
ValoareTotala >= 3000000 AND ValoareTotala <= 4000000
Utiliznd operatorul BETWEEN se poate scrie:
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND ValoareTotala BETWEEN 3000000 AND
4000000

Operatorul LIKE
Acest operator se folosete pentru a compara un atribut de tip ir de caractere (ex.
NumeClient, Adresa, Localitate) cu un literal (constant de tip ir de caractere). Astfel, dac se
dorete obinerea unei tabele-rezultat care s conin numai clienii ai cror nume ncepe cu litera
M, putem scrie predicatul din clauza WHERE sub forma: NumeClient LIKE "M%". Deoarece
dup litera M apare semnul "%", se vor extrage din tabela CLIENI toate tuplurile pentru care
valoarea atributului NumeClient ncepe cu litera M, indiferent de lungimea acestuia (ex.
MELCRET, MIGAS, MITA, MATSUSHITA etc.). Despre semnul "%" se spune c este un
specificator multiplu, joker sau masc.

Un alt specificator multiplu utilizat n multe versiuni SQL este liniua de subliniere ("_").
Spre deosebire de "%", "_" substituie un singur caracter. Diferena dintre cei doi specificatori
multipli este pus n eviden n exemplele urmtoare.
Exemplu 4
Care sunt clienii ai cror nume este format din apte caractere, ncepe cu litera A i sunt
societi cu rspundere limitat (SRL-uri) ?
SELECT *
FROM CLIENI
WHERE NumeClient LIKE "A__ SRL"
Rezultatul va fi cel din figura 6.3.

Figura nr. 6.3. Utilizarea specificatorului multiplu "_"

Dac s-ar fi utilizat simbolul "%":

SELECT *
FROM CLIENI
WHERE NumeClient LIKE "A%SRL",
rezultatul ar fi fost cel din figura 6.4.

Figura nr. 6.4. Utilizarea specificatorului multiplu "%"

n concluzie, "_" nlocuiete (substituie) un singur caracter, n timp ce "%" nlocuiete un

ir de caractere de lungime variabil (ntre 0 i n caractere). Cei doi specificatori multipli pot fi
utilizai mpreun.
Operatorul IN
Format general:
expresie1 IN (expresie2, expresie3, ...)

Rezultatul evalurii unui predicat ce conine acest operator va fi "adevrat" dac valoarea
expresiei1 este egal cu (cel puin) una din valorile: expresie2, expresie3, ... Este util atunci cnd
condiiile de selecie sunt mai complexe.
Exemplu 6
Care sunt localitile din judeele Iai i Vaslui?
Fr utilizarea operatorului IN interogarea se scrie:
SELECT *
FROM LOCALITI
WHERE Jude = "Iai" OR Jude = "Vaslui"
Utiliznd operatorul IN:
SELECT *
FROM LOCALITI
WHERE Jude IN ("Iai", "Vaslui")

Operatorul IS NULL
O valoare nul este o valoare nedefinit. Este posibil ca la adugarea unei linii ntr-o
tabel, valorile unor atribute s fie necunoscute. n aceste cazuri valoarea atributului pentru
tuplul respectiv este nul. Reamintim c, prin definiie, nu se admit valori nule pentru grupul
atributelor care constituie cheia primar a relaiei.
Exemplu 7
Dac se dorete aflarea clienilor pentru care nu s-a introdus adresa, interogarea se poate scrie:
SELECT *
FROM CLIENTI
WHERE Adresa IS NULL
Cum n baza noastr de date, numai clientului OCCO SRL nu-i cunoatem adresa, rezultatul
interogrii este cel din figura 6.5.

Figura nr. 6.5. Extragerea valorilor NULLe

Observaii
1. Valoarea NULL nu se confund cu valoarea zero (pentru atributele numerice) sau cu valoarea
"spaiu" (pentru atributele de tip ir de caractere)
2. Operatorul NULL se utilizeaz cu IS i nu cu semnul "=". Dac s-ar utiliza forma expresie =
NULL i nu expresie IS NULL, rezultatul evalurii va fi ntotdeauna fals, chiar dac
expresia nu este nul !

Proiecia. Opiunea ORDER BY

Coloanele tabelei-rezultat al consultrii sunt specificate n clauza SELECT, fiind separate

prin virgul.
Exemplu 1
Care sunt judeele n care firma are clieni ?
Este necesar parcurgerea relaiei LOCALITI, singurul atribut care intereseaz fiind Jude.
Deoarece SQL nu elimin dublurile automat, dac se dorete ca n tabela-rezultat o localitate s
figureze o singur dat, se utilizeaz opiunea DISTINCT:
SELECT DISTINCT Jude
FROM LOCALITI
Exemplu 2
Care este denumirea fiecrei localiti i judeul n care se afl ?
SELECT Localitate, Jude
FROM LOCALITI

Prezentarea localitilor n ordinea alfabetic a numelui acestora este posibil prin apelnd
la clauza ORDER BY:
SELECT Localitate, Jude
FROM LOCALITI
ORDER BY Localitate

Pentru ordonarea liniilor tabelei-rezultat n funcie de jude i, n cadrul aceluiai jude, n

ordinea invers a localitii (de la Z la A), fraza SELECT se formuleaz astfel:
SELECT *
FROM LOCALITI
ORDER BY Jude ASCENDING, Localitate DESCENDING

Figura nr. 6.6. Clauza ORDER BY

Opiunile ASCENDING (cresctor) i DESCENDING (descresctor) indic deci modul

n care se face ordonarea tuplurilor tabelei-rezultat al interogrii.
Prioritatea de ordonare este stabilit prin ordinea atributelor specificate n ORDER BY:
ordonarea "principal" se face n funcie de valorile primului atribut specificat; n cadrul grupelor
de tupluri pentru care valoarea primului atribut este identic, ordinea se stabilete dup valoarea
celui de-al doilea atribut specificat .a.m.d.
Dac n ORDER BY lipsesc opiunile ASCENDING/DESCENDING, ordonarea se face
cresctor.

onciunea
SQL nu prezint clauze sau operatori speciali pentru realizarea theta-jonciunii, echijonciunii sau jonciunii naturale. Dar, aa cum am vzut, o jonciune este o combinaie de
produs cartezian i selecie.
Exemplu 1
Revenind la exemplele din algebra relaional, echi-jonciunea tabelelor FURNIZOR1 i
FURNIZOR2 n SQL se realizeaz prin fraza SELECT:
SELECT *
FROM FURNIZOR1, FURNIZOR2
WHERE FURNIZOR1.CodF = FURNIZOR2.CodF
Observaie:
n SQL2, echijonciunea poate fi realizat prin clauza INNER JOIN plasat n clauza FROM.
Astfel, ultima fraz SELECT se poate redacta, n SQL2, fr clauza WHERE:
SELECT *
FROM FURNIZOR1 INNER JOIN FURNIZOR2 ON
FURNIZOR1.CodF = FURNIZOR2.CodF
Exemplu 2
Care sunt clienii din municipiul Focani ?
SELECT *
FROM CLIENI INNER JOIN LOCALITI
ON CLIENI.CodPostal = LOCALITI.CodPostal
WHERE Localitate=Focsani

Produsul cartezian al tabelelor CLIENI i LOCALITI este prezentat n figura 6.7.

Figura nr. 6.7. Produsul cartezian CLIENI LOCALITI

Din cele 32 de linii sunt selectate cele care ndeplinesc condiia de jonciune, CLIENI.CodPostal = LOCALITI.CodPostal, i pe cea suplimentar - Localitate=Focsani.
n final, rezultatul este cel din figura 6.8.

Figura nr. 6.8. Rezultatul final al jonciunii i al seleciei suplimentare

Exemplu 3
Care sunt facturile emise clienilor din judeul Iai ?
SELECT NrFactura
FROM FACTURIEMISE, CLIENI, LOCALITI
WHERE FACTURIEMISE.CodClient = CLIENI.CodClient
AND CLIENI.CodPostal = LOCALITI.CodPostal

AND Jude=Iai

Soluia este echivalent cu urmtoarea:

SELECT NrFactura
FROM FACTURIEMISE FE INNER JOIN CLIENI C
ON FE.CodClient = C.CodClient
INNER JOIN LOCALITI L
ON C.CodPostal = L.CodPostal
WHERE Jude=Iai
Exemplu 4
Care sunt facturile emise n aceeai zi ca i factura 111113 ?
Problema propus poate fi rezolvat relativ uor folosind o subconsultare, dup cum va fi
prezentat n paragraful urmtor. Pn una-alta, soluia pe care o avem n acest moment la
ndemn se bazeaz pe autojonciune. Autojonciune nseamn jonciunea unei tabele cu eansi, practic, jonciunea a dou instane ale unei aceleai tabele:
SELECT FE1.NrFactura, FE1.Data
FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2
ON FE1.Data= FE2.Data AND FE2.NrFactura=111113
Soluia de mai sus conduce la rezultatul din figura 6.9. S vedem prin ce mecanism.

Figura nr. 6.9. Facturile emise n aceeai zi ca i 111113

Jonciunea celor dou instane, FE1 i FE2, ale tabelei FACTURIEMISE dup condiia
FE1.Data = FE2.Data:
SELECT *
FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2
ON FE1.Data= FE2.Data

conduce la un rezultat precum cel din figura 6.10.

Figura nr. 6.10. Auto-jonciunea, dup valorile Data, tabelei FACTURIEMISE

Din cele 38 de linii, prin predicatul FE2.NrFactura=111113 rmn numai 3, cele din
figura 6.9.
Exemplu 5
Care sunt clienii crora NU le-am ntocmit facturi pe 18/06/2000 ?

La aceast problem se pot formula mai multe soluii. Una ar fi bazat pe diferena dintre
toi clienii (extrai din tabela CLIENI) i cei crora le-am trimis facturi pe 18 iunie. innd
seama c numele clientului este cheie alternativ, deci unic, se poate scrie:
SELECT NumeClient
FROM CLIENTI
MINUS
SELECT NumeClient
FROM CLIENTI INNER JOIN FACTURIEMISE
ON CLIENTI.CodClient=FACTURIEMISE.CodClient AND Data={^2000/06/18}

O asemenea soluie funcioneaz n Oracle (folosind funcia de conversie TO_DATE pentu

constant), DB2 (nlocuind, n plus, MINUS cu EXCEPT), nu ns i n Visual FoxPro. Avnd n

vedere c nu avem cunotine privind subconsultrile, putem recurge la un artificiu bazat pe o

form interesana a jonciunii, i anume jonciunea extern.
S examinm fraza SELECT urmtoare i rezultatul acesteia din figura 6.11.
SELECT *
FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE
ON C.CodClient=FE.CodClient AND Data={^2000/06/18}

Figura nr. 6.11. O jonciune extern

Prima observaie: n rezultat sunt incluse toi clienii, adic, toate nregistrrile din tabela
CLIENI. A doua observaie: jonciunea nu mai este de tip INNER i LEFT OUTER, adic
extern la stnga. Cum dintre CLIENI i FACTURIEMISE, cea de la stnga este prima, rezult
c n rezultat sunt extrase toate liniile din aceasta, chiar dac nu au linii corespondente n tabela
din dreapta. n cazul nostru, TEXTILA SA, MODERN SRL, INTEGRATA SA, AMI SRL
AXON SRL nu au fcut cumprturi de la firma noastr pe 18 iunie 2000. Ne dm seama de
acest lucru observnd c pe liniile coresponde acestora, valorile atributelor preluate din FACTURIEMISE sunt NULL.
Astfel nct, pentru a rspunde punctual la problema pus, ar trebui extrase liniile n care,
n urma jonciunii externe, FE.NrFactur (sau oricare alt atribut din FE) este NULL. Paradoxal
sau nu, fraza urmtoare nu obine rezultatul scontat n VFP:
SELECT *
FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE
ON C.CodClient=FE.CodClient AND Data={^2000/06/18}
WHERE FE.NrFactura IS NULL

n schimb, se poate folosi un artificiu prin ntrebuinarea funciei NVL:

SELECT *
FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE
ON C.CodClient=FE.CodClient AND Data={^2000/06/18}
WHERE NVL(FE.NrFactura,0) = 0

Funcia NVL convertete valorile nule ale atributului NrFactura n 0. Principial, soluia
bazat pe NVL are acelai mecanism ca i precedenta interogare. Cu singura diferen c
funcioneaz, dup reiese din figura 6.12.

Figura nr. 6.12. Clienii fr facturi pe 18 iunie 2000

Firete, pentru a obine numai numele clienilor, este necesar nlocuirea asteriscului din
clauza SELECT cu atributul NumeClient.
Ar mai fi de adugat c exist trei tipuri de jonciune extern: la stnga (LEFT OUTER
JOIN), la dreapta (RIGHT OUTER JOIN) i total (FULL OUTER JOIN). La jonciunea
extern la dreapta sunt extrase liniile echi-jonciunii plus liniile tabelei din dreapta ce nu
ndeplinesc condiia formulat prin predicatul de jonciune. Jonciunea extern total reprezint,
n fapt, reuniunea (cu eliminarea dublurilor) jonciunilor la stnga i la dreapta.

Sub-consultri. Operatorul IN
O alt facilitate deosebit de important a limbajului SQL o constituie posibilitatea
includerii (imbricrii) a dou sau mai multe fraze SELECT, astfel nct pot fi formulate
interogri cu mare grad de complexitate.
Operatorul IN poate fi utilizat i pentru includerea unei fraze SELECT ntr-o alt fraz
SELECT.
Exemplu 1
Care sunt facturile emise n aceeai zi n care a fost ntocmit factura 111113 ?
SELECT *
FROM FACTURIEMISE
WHERE Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113)

Sub-consultarea
SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111114

are ca rezultat o tabel alctuit dintr-o singur coloan (Data) i o singur linie ce conine
valoarea atributului Data pentru factura 111113, ca n figura 6.13:

Figura nr. 6.13. Rezultatul sub-consultrii

Clauza WHERE Data IN determin cutarea n tabela FACTURIEMISE a tuturor

tuplurilor (liniilor) care au valoarea atributului Data egal cu una din valorile tuplurilor (n cazul
nostru, egal cu valoarea tuplului) din tabela obinut prin "sub-consultare" (n cazul nostru,
tabela din figura 6.13). Cu alte cuvinte, n acest caz WHERE Data IN va selecta toate facturile
pentru care data emiterii este 18/06/2000 figura 6.14.

Figura nr. 6.14. Facturile emise n aceeai zi ca i 111113

Exemplu 2
Care sunt facturile emise n alte zile dect cea n care a fost ntocmit factura 111113?
SELECT *
FROM FACTURIEMISE
WHERE Data NOT IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113)

S-a utilizat negaia, testndu-se non-apartenena la o relaie creat printr-o sub-fraz

SELECT (vezi figura nr. 6.15).

Figura nr. 6.15. Facturile emise n alte zile dect factura 111113

Exemplu 3
Care sunt clienii crora li s-au trimis facturi ntocmite n aceeai zi cu factura 111113?
SELECT DISTINCT NumeClient
FROM CLIENI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE
WHERE Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113))

Am ilustrat modul n care pot fi imbricate (nlnuite, incluse) trei fraze SELECT. Soluia
este valabil n SGBD-urile profesionale (DB2, Oracle), nu ns i n VFP, n care orice
interogare poate fi desfutata pe maximum dou nivele (SELECT-ul principal, plus un nivel de
sub-consultri). Pentru a reduce numrul straturilor de corelare, se poate folosi, n acest caz,
jonciunea:
SELECT DISTINCT NumeClient
FROM CLIENI, FACTURIEMISE
WHERE CLIENI.CodClient=FACTURIEMISE.CodClient
AND Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactura=111113)

Rezultatul din figura 6.16 demonstreaz c soluia este viabil.

Figura nr. 6.16. Clieni pentru care exist mcar o factur

ntocmit n aceeai zi cu 111113

Se poate reine, ca regul general, c aproape orice consultare poate fi redactat n mai
multe moduri, n funcie de experiena i imaginaia celui care o formuleaz.

Funcii de agregare: COUNT, SUM, AVG, MAX, MIN

Formatul general al unei fraze SELECT ce conine funcii predefinite este:
SELECT funcia-predefinit1, ... , funcia-predefinitN
FROM list-tabele
WHERE condiii

Rezultatul oricrei fraze SELECT este o nou relaie (tabel). n lipsa opiunii GROUP
BY, dac n clauza SELECT este prezent o funcie predefinit, tabela rezultat va conine o
singur linie.
Funcia COUNT contorizeaz valorile unei coloane, altfel spus, numr, ntr-o relaie,
cte valori diferite de NULL are coloana specificat.
Exemplu 1
Ci clieni are firma ?
SELECT COUNT (CodClient) AS Nr_Clienti
FROM CLIENTI

n funcia COUNT se poate utiliza ca argument, n locul numelui unei coloane, semnul *;
n acest caz se va determina cte linii are tabela la care se aplic funcia respectiv.
Exemplu 2
La ci clieni s-au trimis facturi ?
SELECT COUNT ()
FROM CLIENTI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE)

Rezultatul corect poate fi ns obinut i prin utilizarea clauzei DISTINCT astfel:

SELECT COUNT (DISTINCT CodClient)
FROM FACTURIEMISE

Funcia SUM calculeaz suma valorilor unei coloane.

Exemplu 3
Care este valoarea total a facturilor emise ?
SELECT SUM (ValoareTotala) AS Total_FP
FROM FACTURIEMISE

Figura 6.17. Totalul vnzrilor

Exemplu 4
Care este totalul valorii facturilor trimise clientului AXON SRL ?
SELECT SUM (ValoareTotala) AS Total_FE_AXON
FROM FACTURIEMISE, CLIENTI
WHERE FACTURIEMISE.CodClient = CLIENTI.CodClient
AND NumeClient = "AXON SRL"

Funciile MAX i MIN. Determin valorile maxime, respectiv minime ale unei coloane n
cadrul unei tabele.
Exemplu 5
Care este cea mai mic valoare a unei facturi emise ?
SELECT MIN(ValoareTotala)
FROM FACTURIEMISE
Exemplu 6
Care este factura emis ce are cea mai mare valoare ?
SELECT NrFactura, ValoareTotala
FROM FACTURIEMISE
WHERE ValoareTotala =
(SELECT MAX (ValoareTotala)
FROM FACTURIEMISE)

Subconsultarea extrage valoarea total maxim a unei facturi, valoare ce va fi utilizat ca

argument pentru SELECT-ul principal. Rezultatul este cel din figura 6.18.

Figura nr. 6.18. Factura cea mai valoroas

Atenie ! Varianta urmtoare nu este corect:

SELECT NrFactura, MAX(ValoareTotala )
FROM FACTURIEMISE

Dac n Oracle sau DB2 la execuia acestei interogri se afieaz un mesaj de eroare, n
Visual FoxPro nu, aa c unii utilizatori s-ar putea baza pe rezultatul afiat.

Gruparea tuplurilor. Clauzele GROUP BY i HAVING

SQL permite utilizarea clauzei GROUP BY pentru a forma grupe (grupuri) de tupluri ale
unei relaii, pe baza valorilor comune ale unei coloane. n frazele SELECT formulate pn n
acest paragraf, prin intermediul clauzei WHERE au fost selectate tupluri din diferite tabele.
Prin asocierea unei clauze HAVING la o clauz GROUP BY este posibil selectarea
anumitor grupe de tupluri ce ndeplinesc un criteriu.
Rezultatul unei fraze SELECT ce conine clauza GROUP BY este o tabel care va fi
obinut prin regruparea tuturor liniilor din tabelele enumerate n FROM, care prezint o aceeai
valoare pentru o coloan sau un grup de coloane.
Formatul general este:
SELECT coloan 1, coloan 2, ...., coloan m
FROM tabel
GROUP BY coloan-de-regrupare
Exemplu 1
Care este totalul zilnic al valorii facturilor emise ?
SELECT Data, SUM (ValoareTotala) AS Total_Zilnic
FROM FACTURIEMISE
GROUP BY Data

n acest caz tabela-rezultat va avea un numr de linii egal cu numrul de date calendaristice
distincte din tabela FACTURIEMISE. Pentru toate facturile aferente unei zile se va calcula suma
valorilor, datorit utilizrii funciei SUM(ValoareTotala).
Succesiunea pailor este urmtoarea:
1. Se ordoneaz liniile tabelei FACTURIEMISE n funcie de valoarea atributului Data figura 6.19.

Figura nr. 6.19. Pasul 1 al gruprii

2. Se formeaz cte un grup pentru fiecare valoare distinct a atributului Data - vezi figura
6.20.

Figura nr. 6.20. Al doilea pas al gruprii

3. Pentru fiecare din cele nou grupuri se calculeaz suma valorilor atributului
ValoareTotala. Tabela rezultat va avea nou linii, ca n figura 6.21.

Figura nr. 6.21. Rezultatul final al gruprii

Exemplu 2
Care este numrul facturilor emise pentru fiecare client ?
SELECT NumeClient, COUNT(NrFactura)
FROM FACTURIEMISE INNER JOIN CLIENTI
ON FACTURIEMISE.CodClient = CLIENTI.CodClient
GROUP BY FACTURIEMISE.CodClient

Pn la standardul SQL99 i publicarea Amendamentului OLAP la acest standard, n SQL

nu pot fi calculate, prin GROUP BY, subtotaluri pe mai multe niveluri. Pentru aceasta este
necesar scrierea de programe n SGBD-ul respectiv.
Clauza HAVING permite introducerea unor restricii care sunt aplicate grupurilor de
tupluri, deci nu tuplurilor "individuale", aa cum "face" clauza WHERE. Din tabela rezultat sunt
eliminate toate grupurile care nu satisfac condiia specificat.
Clauza HAVING "lucreaz" mpreun cu o clauz GROUP BY, fiind practic o clauz
WHERE aplicat acesteia.
Formatul general este:
SELECT coloan 1, coloan 2, .... , coloan m
FROM tabel
GROUP BY coloan-de-regrupare
HAVING caracteristic-de-grup

Exemplu 3
Pentru facturile emise intereseaz valoarea zilnic a acestora (n funcie de data la care au fost
ntocmite, dar numai dac aceasta (valoarea zilnic) este de mai mare de cinci milioane lei.
SELECT Data, SUM(ValoareTotala)
FROM FACTURIEMISE
GROUP BY Data
HAVING SUM(ValoareTotala) > 15000000
La execuia acestei fraze, se parcurg cei trei pai prezentai la exemplul 1, apoi, din cele nou
tupluri obinute prin grupare, sunt extrase numai cele care ndeplinesc condiia
SUM(ValoareTotala)>15000000. Rezultatul final este cel din figura 6.22.

Figura 6.22. Rezultatul consultrii - exemplul 3

Exemplu 4
S se afieze ziua n care s-au ntocmit cele mai multe facturi.
SELECT Data
FROM FACTURIEMISE
GROUP BY Data
HAVING COUNT(*) >= ALL
(SELECT COUNT(*)
FROM FACTURIEMISE
GROUP BY Data)

Din pcate, nici acest tip de interogare (prezena subconsultrilor n clauza HAVING) nu
este agreat de Visual FoxPro, astfel nct este necesar utilizarea mai multor fraze SELECT i
salvarea rezultatelor intermediare fie n tabele derivate (view-uri), fie n cursoare
(NR_PE_ZILE) care, n VFP sunt tabele temporare a cror via este limitat de nchiderea lor,
explicit sau implicit:

SELECT Data, COUNT(*) AS Nr ;

FROM FACTURIEMISE ;
INTO CURSOR NR_PE_ZILE ;
GROUP BY Data

SELECT Data, Nr ;
FROM NR_PE_ZILE ;
WHERE Nr >= ;
(SELECT MAX(Nr) ;
FROM NR_PE_ZILE)

Coninutul cursorului NR_PE_ZILE, precum i rezultatul final sunt cele din figura 6.23.

Figura 6.23. Obinerea n VFP a zilei cu cele mai multe facturi

COMENZI PENTRU ACTUALIZAREA BAZELOR DE DATE

SQL prezint comenzi specifice pentru modificarea coninutului unei tabele, nelegnd
prin aceasta trei aciuni prin care se actualizeaz baza:
a) adugarea de noi linii la cele existente ntr-o tabel,
b) tergerea unor linii,
c) modificarea valorii unui atribut.

Adugarea de nregistrri
Exemplu 1
S presupunem c, la un moment dat, ntreprinderea vinde produse i firmei RODEX SRL care
are sediul pe strada Sapienei, nr.44 bis, n localitatea Iai.

Acest nou client trebuie "introdus" n baza de date, operaiune care n SQL, se realizeaz
prin comanda:
INSERT
INTO CLIENI
VALUES (1009, RODEX SRL, Sapienei, 44 bis, 6600)

Fraza INSERT de mai sus poate fi scris i sub forma

INSERT
INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal)
VALUES (5009, RODEX SRL, Sapienei 44 bis, 6600).

Dup cum se observ, dup numele tabelei (CLIENI) au fost enumerate toate atributele
pentru care se introduc valori prin clauza VALUES. Dac nu s-ar fi cunoscut adresa clientului
RODEX, atunci fraza INSERT ar fi avut una din formele:
INSERT
INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal)
VALUES (5009, "RODEX SRL", NULL, 6600)

sau
INSERT
INTO CLIENI (CodClient, NumeClient, CodPostal)
VALUES (5009, RODEX SRL, 6600)

n noua linie a tabelei CLIENI valoarea atributului Adresa va fi NULL.

tergerea de nregistrri
Operaiunea de eliminarea a una sau mai multe linii dintr-o tabel, pe baza unui predicat,
se realizeaz n SQL prin comanda DELETE care are sintaxa:
DELETE
FROM nume-tabel
WHERE predicat

Exemplu 2
S se elimine din tabela CLIENI linia aferent clientului MODERN SRL (cod 1002).
DELETE
FROM CLIENI
WHERE CodClient = 1002
Exemplu 3
S se tearg datele referitoare la fiecare vnzare de produs pentru clienii din oraul Focani.
DELETE
FROM FACTURIEMISE
WHERE CodClient IN
(SELECT CodClient
FROM CLIENI, LOCALITI
WHERE CLIENI.CodPostal=LOCALITI.CodPostal AND
Localitate = "Focani"))

Nici aceast form nu funcioneaz n VFP. n general, tergerea unor linii trebuie privit
cu mult circumspecie, deoarece atunci cnd linia de ters conine valori ale unor atribute ce
apar n alte tabele ca i chei strine, exist riscul pierderii integritii refereniale.
Standardul SQL92 (nu i dialectul SQL din VFP) permite la crearea unei tabele descrierea
aciunii care se va derula la tergerea unei linii printe n cazul n care exist linii-copil. Spre
exemplu, se poate refuza tergerea de linii din tabela CLIENI, dac la crearea tabelei
FACTURIEMISE se specific:
CREATE TABLE FACTURIEMISE
(NrFactura

DECIMAL(8) NOT NULL,

DataFactura

DATE,

CodClient

DECIMAL(6) NOT NULL,

ValoareTotala DECIMAL(15) not NULL,

TVAColectata DECIMAL(14) ,
PRIMARY KEY (NrFactura),
FOREIGN KEY (CodClient) REFERENCES CLIENTI
ON DELETE RESTRICT)

Modificarea valorilor unor atribute

Pentru modificarea valorilor unuia sau multor atribute dintr-o tabel, comanda utilizat este
UPDATE care are formatul general:
UPDATE tabel
SET atribut = expresie
WHERE predicat

Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind
cele care rezult n urma evalurii expresiei; modificarea se va produce pe toate liniile tabelei
care ndeplinesc condiia specificat n predicat.
Exemplu 4
n tabela CLIENI, fiecrui client i-a fost atribuit un cod unic, ncepnd cu 1001. Dac din
diferite motive, se dorete ca "numerotarea" clienilor s nceap de la 3001, pstrndu-se
ordinea, se poate articula fraza UPDATE urmtoare:
UPDATE CLIENI
SET CodClient = CodClient + 2000

Exemplul este suficient de neinspirat, deoarece n practic modificarea codului clienilor

antreneaz modificarea valorilor acestui atribut n toate tabelele n care apare (n cazul nostru
FACTURIEMISE), datorit faptului c este o cheie strin.