Capitolul 4

Capitolul 4
Modelul relaţional
Specificitate, operatori relaţionali
Limbaje pentru baze de date relaţionale
Reprezentanţi

Specificitatea modelului relaţional

Modelul relaţional îşi datorează numele noţiunii matematice numită RELAŢIE.

Fie mulţimile M1, M2, M3 ... MN nu neaparat distincte. Se numeşte produs cartezian al
mulţimilor M1, M2, M3 ... MN mulţimea tuturor tuplelor (X1, X2, X3 ... XN) unde X1, X2,... XN
aparţin respectiv mulţimilor M1, M2, M3 ... MN.
Se numeşte relaţie peste mulţimile M1, M2, M3 ... MN o submulţime a produsului
cartezian M1 × M2 × M3 ×...× MN . Fie relaţia REL definită peste aceste mulţimi. Se spune
despre elementele x1, x2, x3 ... xn că sunt în relaţia REL dacă tuplul (x1, x2, x3 ... xn) aparţine
relaţiei REL.
Numărul N al mulţimilor ce intră în relaţie se numeşte gradul relaţiei, iar numărul
N-uplelor ce formează relaţia se numeşte cardinalul relaţiei.
Observăm că o entitate este o relaţie definită peste domeniul atributelor sale, deoarece
fiecare realizare a sa aparţine produsului cartezian al domeniilor D1, D2, D3 ... DN,. Realizările
unei entităţi sunt de forma (a1, a2, a3 ... an) şi aparţin produsului D1 × D2 × D3 ×... × DN,.
Poziţiile atributelor sunt esenţiale. Dacă însă vom conveni să le referim doar prin nume,
atunci o entitate se poate reprezenta în mod foarte eonvenabil sub forma unei tabele care va
avea în antet numele atributelor.
Putem acum să remarcăm faptul că asocierile între entităţi sunt la rândul lor relaţii
(în sensul precizat mai sus): toate perechile (e, f) de realizări ale entităţilor E, F care sunt
legate prin asocierea REL aparţin produsului cartezian E×F. Având în vedere că şi entităţile
sunt relaţii, această asociere poate fi exprimată ca o submulţime a produsului (X1 × X2 × X3
×... × XN) × (Y1 × Y2 × Y3 ×... × YN) unde X1, X2, X3 ... XN sunt domeniile atributelor
entităţii E, iar Y1, Y2, Y3 ... YN, sunt domeniile entităţii F. Având în vedere faptul că produsul
eartezian este asociativ, o asociere este, de fapt, o entitate! Deci şi ea poate fi reprezentată în
formă tabelară.
! De reţinut: corespondenţa noţiunilor relaţie-tabela, tuplu-linie, atribut-coloană.
O relaţie poate fi simbolizată astfel: R(a1,a2,a3,...,an) unde: R=numele relaţiei iar
a1,a2,... ,an = numele atributelor.
Cheia primară a unei relaţii este un atribut (sau grup) care identifică fără ambiguitate
fiecare linie a relaţiei. Atunci când cheia este compusă, nici un atribut al său nu poate fi
eliminat fără distrugerea unicităţii tuplului. Valorile atributelor ce formează cheia primară
trebuie să fie întotdeauna specificate (nu pot avea valori nule).

Dacă într-o relaţie sunt mai multe combinaţii de atribute care conferă unicitate liniilor,
acestea sunt denumite chei candidate.
O cheie străină este un grup de atribute care pune în legătură linii din două relaţii
(tabele).

Baze de Date   22 
Capitolul 4

O schemă relaţională poate fi definită ca un ansamlalu de relaţii asociate semantic

prin domeniul lor de definiţie şi prin anumite restricţii de integritate. Schema relaţională este
independenţa în timp. Pentru păstrarea integrităţii unei baze de date se propune un limbaj
declarativ care memorează reguli de integritate, ce pot fi:

a) pre-condiţii care indică momentul verificării restricţiei (înainte sau după

modificarea bazei de date);
b) restricţii propriu-zise, exprimate prin predicate;
c) unitatea de execuţie, care se ocupă de validarea restricţiei în caz de nerespectarea
acesteia.

Restricţiile de integritate se referă la:

1. restricţiile cheilor- primare - condiţia de unicitate şi de valori non-nule.

2. restricţii referenţiale - apar atunci când o relaţie este în legătură cu altă relaţie
(se pot formula astfel: cheia străină a tabelei referite nu trebuie să aibe valori care
nu se regăsesc drept valori ale cheii primare în tabela de referinţă).
3. restricţii de comportament - puse pe valorile diferitelor atribute sau dintre atribute.

Proceduri stocate: Trigger-ele

O procedură stocată este o secvenţă de program (cod) care face parte integrantă din
baza de date şi se încarcă automat în memorie la deschiderea bazei.
Trigger-ele se folosesc pentru validarea tabelelor, a valorilor unor articole sau
atribute. Numele se poate traduce prin declanşator având în vedere că procedura se invocă
automat când un eveniment (adăugare, înserare, ştergere) modifică o tabelă. Principalul
obiectiv îl constituie păstrarea integrităţii referenţiale a bazei de date.

Exemple

Pentru sistemul informatic al unei şcoli se consideră necesare informaţii despre: clase
(codul, profilul), obiectele de învăţământ (nume), profesorii din şcoală (nume, grad,
specialitate), elevi(clasa, nume, date-personale). Un profesor poate avea mai multe obiecte pe
care le predă la o clasă; un obiect poate fi predat de mai mulţi profesori dar la clase diferite.
O clasă are mai mulţi elevi, dar un elev nu poate aparţine la clase diferite. Definim
următoarele tabele şi legături între ele astfel: codcl = codul clasei. codo = codul obiectului,
codp = codul profesorului.

Cheile unice sunt: codcl (tabela Clase); codo(tabela Obiecte); codp(tabela Profesori).
Cheile străine sunt: codcl(tabela Elevi); codo, codp(tabela Profesori).

Restricţii de cheie:
• Orice valoare a atributului codcl trebuie să identifice o linie în tabela Clase.
• Orice valoare a atributului codo trebuie să identifice o linie în tabela Obiecte.
• Orice valoare a atributului codp trebuie să identifice o linie în labela Profesori.

Baze de Date   23 
Capitolul 4

Restricţiile referenţiale:

• la adăugarea unei linii în labela Incadrare se va verifica dacă valoarea

atributului codp există în tabela Profesori, dacă valoarea atributului codo
există în tabela Obiecte şi dacă valoareaa atributului codcl există în tabela
Clase.
• la ştergerea unei linii din tabela Obiecte se vor şterge liniile cu valoarea cheii
la codo egală cu valoarea cheii primare şterse;
• la ştergerea unei linii din tabela Clase se vor şterge liniile cu valoarea cheii
codcl egală cu valoarea cheii primare şterse;
• la ştergerea unei linii din tabela Profesori se vor şterge liniile cu valoarea cheii
codp egală cu valoarea cheii primare şterse;

Restricţii de comportament, particulare:

• la nivel de atribut: atributul codcl va evea, pe primele două poziţii, cifre pentru
a marca anul şcolar, iar al treilea caracter este o literă mică: Ex. 10a, 9c, 12d.
• la nivel de linie: dacă codcl este "9a"-"9z" profilul aparţine mulţimii "info",
"mate", "bio" altfel profilul este numai "info".

Tabele virtuale (View)

O altă noţiune a modelului relaţional este imaginea sau tabela virtuală. O astfel de
tabelă este o relaţie dinamică fiind definită pe baza unei expresii relaţionale dintre atributele
tabelelor reale. Ea nu păstrează conţinutul tabelelor de bază ci doar schema. Tabelele virtuale
oferă posibilitatea prezentării numai anumitor date (securitatea faţă de anumiţi utilizatori).
Odată definită, tabela virtuală este memorată în baza de date şi poate fi actualizată în sensul
actualizarii simultane a tuturor tabelelor de bază din care este alcătuită.
De exemplu: definim o tabelă virtuală din tabelele Elevi şi Clase care să reţină doar
numele elevilor şi profilul clasei în care învaţă.

Elevi.dbf Clase.dbf Profi.dbf

nume codcl codcl profil nume profil
Albu 9a 9a Info Albu Info
Barbu 9c 9b Mate Barbu Bio
9c Bio

Orice modificare a datelor din tabelele sursă se reflectă automat în tabela virtuală.
Dar, atenţie, s-ar putea ivi anumite probleme la actualizarea imaginilor!
De exemplu vrem să facem următoarea corecţie direct în view: Elevul Albu îşi schimbă
profilul de la "Info" la "Mate". Cum se actualizează tabelele sursă? O primă posibilitate ar fi,
trecerea elevului Albu la clasa "9b" (care are profilul "Mate"). O altă posibilitate este
schimbarea profilului clasei corespunzătoare elevului la noua valoare (se modifică în tabela
Clase pentru "9a" profilul "Mate").

Baze de Date   24 
Capitolul 4

Forme normale
Problema proiectării unei structuri eficiente pentru datele necesare unei probleme este
cheia întregii aplicaţii. În general, în aplicaţiile de gestiune problema cea mai mare nu o
reprezintă implementarea aplicaţiei de exploatare a bazei de date cât proiectarea unei structuri
care să permită accesul cât mai rapid la date şi care să sufere de cât mai puţine anomalii.
După cum se spune şi după cum se poate demonstra practic, dându-se o problemă putem
rezolva 50% din ea proiectând structurile adecvate.

O tabelă de date este o relaţie dacă:

1. în cadrul unei baze de date are nume distinct;
2. fiecare celulă a relaţiei conţine o singură valoare;
3. fiecare atribut are un nume distinct;
4. orice valoare a unui atribut face parte din domeniul pe care a fost definit
acesta;
5. ordinea dispunerii atributelor în relaţie nu prezintă importanţă;
6. orice linie este distinctă;
7. ordinea liniilor nu influenţează conţinutul informaţional al relaţiei.

Dar, nu toate relaţiile sunt egal acceptabile, deoarece anumite relaţii pot fi mai bine
structurate decât altele. Din această cauză operaţia numită normalizare este menită să creeze
relaţii bine structurate cu eliminarea unor eventuale dificultăţi de actualizare.
Exemplu: Fie tabela FACTURI.dbf - cu evidenţa facturilor neachitate la o firmă,

nr_factura valoare tva furnizor adresa cod_fiscal

121 12000 10 All sibiu 123456
123 20000 0 sc. all sibiu 123456
128 15000 2000 sc. Intim cluj 233333

Cheia relaţiei este numărul facturii. Să discutăm posibilităţile de actualizare a datelor:

atunci când se primeşte o factură ea se adaugă în tabel, iar când factura se achită se şterge din
tabel.
• Modificarea adresei sau a codului fiscal pentru un furnizor trebuie realizată în
toale articolele unde apare.
• Introducerea datelor despre un furnizor se face atunci când acesta trimite o
factură. Chiar dacă dorim reţinerea datelor despre un partener nu putem face
acest lucru până când acesta nu trimite o factură.
• Achitarea facturilor presupune şi ştergerea liniilor corespunzatoare din tabel.
Putem pierde astfel informaţii importante despre un fumizor cum ar fi: adresa
sau cod_fiscal.

Anomaliile prezentate pot fi corectate prin împărţirea tabelei în două relaţii: una cu
date despre FACTURI(numar, valoare, fumizor) alta cu informaţii depre FURNIZORI(nume,
adresa, cod_fiscal). Operaţia de ştergere a facturii nu implică şi pierderea informaţiilor despre
fumizor. Pe de altă parte adăugarea unei facturi pe care o trimite un fumizor nou necesită şi
completarea, unică, a datelor despre fumizor în tabela FURNIZORI.
Anomaliile care spar în exemplul anterior provin în realitate din faptul că au fost
aşezate în aceeaşi tabelă informaţii despre obiecte distincte: furnizori şi facturi.

Baze de Date   25 
Capitolul 4

Operaţia de "spargere" a relaţiei care manifestă anomalii în alte relaţii poartă numele
de normalizare.
Fiecare relaţie normalizată are o singură temă. De fiecare dată când se efectuează o
împărţire a relaţiei în altele două, trebuie să se fixeze condiţiile pentru asocierea celor două
noi relaţii astfel încât datele se rămână consistente. Relaţiile pot fi clasificate în funcţie de
tipul anomaliilor la care sunt vulnerabile. Clasele de relaţii şi tehnicile folosite pentru
prevenirea anomaliilor se numesc forme normale.
Procesul de normalizare are la bază noţiunea de dependenţă funcţională.
Vom defmi o dependenţă funcţională o legătură între două atribute din care al
doilea poate fi determinat dacă se cunoaşte primul. De exemplu, pentru tabelul anterior,
între numărul facturii şi valoare există o dependenţă funcţională. Dându-se numărul facturii
putem găsi valoarea acesteia. Spunem, deci, că atributul valoare este dependent funcţional de
numărul facturii şi vom nota (nr_factura)>>>(valoare). De asemenea atributul cod_fiscal
determină funcţional atributele nume_furnizor, adresa, contul_ la_banca, etc.

Prima formă normală se identifică cu noţiunea de relaţie

Să plecăm de la un tabel care conţine codurile produselor solicitate pe o comandă
precum şi numărul, data, valoarea comenzii:

com data furn adr cod1 cod2 cod3 cod4 cant val
006 01.03.98 f1 Bc a23 b66 c33 10 12980
007 01.09.98 f2 Bc c33 12 12000

Verificăm să fie o relaţie conform definiţiei date mai sus: nu sunt linii identice, nu
sunt valori de tipuri diferite în coloane, cheia este atributul com (numar_comanda).
Dar:
a) cine garantează că nu pot fi comenzi cu mai mult de 4 produse ?
b) cine garantează că toate produsele, chiar dacă sunt cel mult 4, au aceeaşi cantitate?
c) Unde punem preţul fiecărui produs ?
d) Prelucrări de felul "valoare totală a comenzilor pentru produsul ‘b66’" necesită
verificarea tuturor coloanelor şi însumarea rezultatelor pentru întreaga bază de date,
lucru care conduce la un timp mare de răspuns.
Deci se impune eliminarea câmpurilor care se repetă şi astfel se ajunge la prima forma
normală:

com data furn adr codprod cant pret val

006 01.03.98 f1 Bc a23 10 100 12980
006 01.03.98 f1 Bc b66 10 200 12980
006 01.03.98 f1 Bc c33 10 150 12980
007 01.09.98 f1 Bc c33 20 150 12000

O relaţie se află în a doua formă normală dacă toate atributele non-cheie sunt
dependente de întreaga cheie.
Deci problema apare când cheia este compusă din mai multe atribute. O relaţie care
are chei simple este în a doua formă normală.
La exemplul nostru cheia este grupul (com, codprod).

Baze de Date   26 
Capitolul 4

Dependenţe funcţionale: (com, codprod)>>>(cant), (com)>>>(data) (com)>>>(valoare).

Observăm că atributele non-cheie nu sunt dependente de întreaga cheie. Normalizăm şi
împărţim tabele în două alte tabele:

COMENZI
com data furn adr valoare
006 01.03.98 f1 Bc 12980
007 01.09.98 f2 Bc 12000
PRODUSE
com codprod cant pret
006 a23 10 100
006 b66 10 200
006 c33 10 150
007 c33 12 150

O relaţie se află în a treia formă normală dacă se află în forma a doua şi nu prezintă
dependinţe tranzitive.
Urmărind exemplul, observăm: cheia relaţiei la tabela COMENZI este com. Ştiind
numărul de comandă putem afla numele furnizorului. Deci (com)>>>(furn). Ştiind furnizorul
putem determina adresa (furn)>>>(adr).
Se pare că adresa depinde funcţional prin tranzitivitate de comandă ceea ce nu este
adevărat. Vom normaliza în continuare şi obţinem alte două tabele:

FURNIZORI COMENZI
furn adr com data furn val
f1 Bc 006 01.03.98 f1 12980
f2 Gl 007 01.09.98 f2 12000

Sa recapitulăm:
=> Prima formă normală se identifică cu definiţia unei relaţii.
=> A doua formă normală impune ca toate atributele non-cheie să fie dependente de întreaga cheie.
=> A treia formă normală presupune inexistenţa dependenţelor tranzitive între atribute.

În concluzie:
Parcurgând formele normale, spectrul anomaliilor de care suferă o relaţie se restrânge foarte
mult. Toate aceste forme normale sunt folositoare dar nici una nu garantează că au fost eliminate toate
anomaliile.

Baze de Date   27 
Capitolul 4

Exerciţii Propuse

P2 *Normalizaţi următoarea relaţie cu situaţia închirierii sălilor dintr-un complex sportiv de

către studenţi.

student nume_sala taxa

popa biliard 1200
ion minigolf 2000
gaby tenis 3000
popa cafenea 1200

Un student poate închiria mai multe săli; o sală poate fi închiriată de mai mulţi studenţi.

P3 *Evidenţa cazărilor turiştilor în hotelurile unei staţiuni este tabela TURIST. Credeţi că
este corectă ?

turist bi hotel taxa/loc

apopei eduard as123456 lido 1200
domeanu mihai gf345675 lido 1200
enache sorin bv512345 parc 1400

P4* Fie un alt tabel care evidenţiază situaţia stocurilor pe depozite. Normalizaţi!

depozit material fumizor stoc

d1 suruburi Astra 10
d1 suruburi Zalau 20
d2 carcase Metalcar 19

Un depozit poate avea mai multe materiale, un material poate sosi de la mai mulţi fumizori,
dar un furnizor este specializat pentru un material.

P5* Relaţia STUDENT reţine informaţiile despre specializările unor studenţi şi activitaţile
sportive pe care aceştia le desfasoară. Ce anomalii poate avea?

student specializari sporturi

Popa muzica atletism
Popa muzica tenis
Lucy fizica atletism
Lucy fizica tenis

Un student poate avea mai multe specializări şi poate desfaşura mai multe sporturi. Cheia
relaţiei poate fi doar atributul Student.

P6. Fie următoarea tabelă cu informaţii despre elevi. Este corectă?

ELEVI
clasa nume_elev adresa diriginte
11a popa iasi albu
11a iancu bacau albu

Baze de Date   28 
Capitolul 4

P7. Fie tabela următoare cu numele cursurilor, profesorii, taxa acestor cursuri precum şi
numele studenţilor care au optat pentru cursuri. Normalizaţi:
STUDENT
nume_curs nume_prof nume_stud taxa grad
Astrologie popa albu 100 prof.univ
Astrologie popa barbu 100 prof.univ
Meteorologie florea doltu 200 lector

P8. În tabela cu medicamente au fost introduse şi informaţii despre patronul farmaciilor.

Este Corect? Ce anomalii pot apărea?
MEDCAM
nr_farm patron buletin adresa medicam pret cant
111 Lupu 12345 str. Pacii Pyram 12 100
111 Lupu 12345 str. Pacii Aspirina 25 300

P9. Observaţi tabela următoare. În ce formă normală este?

CEC
nrc titular b_i adr dn dataop tipop suma sold
11 Popa 1212 Dej 01.01.76 07.09 D 30 100
11 Popa 1212 Dej 01.01.76 08.09 R 50 50

Baze de Date   29 
Capitolul 4

Operatori relaţionali
Comparativ cu operatorii clasici ai sistemelor de prelucrare automată a datelor
(duplicate, conversie, sortare, fuzionare, separare, asociere, scindare, ştergere şi actualizare)
care au un caracter mult mai sintactic, operatorii relaţionali posedă o orientate semantică.
Cercetările în acest domeniu au demonstrat că operatorii relaţionali plus sortarea pot
răspunde tuturor solicitărilor din domeniul prelucrării automate a datelor. Prin definirea şi
utilizarea acestor operatori, teoria relaţiilor permite fundamentarea cercetărilor ce se
efectuează în domeniul proiectării bazelor de date relaţionale şi a conceperii limbajelor
relaţionale.
Reuniunea a două relaţii; X cu n realizări şi Y cu m realizări are ca rezultat o
mulţime Z cu m+n realizări. Colecţia pentru gestiunea materialelor de cod între 1-20 reunită
cu colecţia pentru gestiunea materialelor între 20-25 are ca rezultat colecţia cu materialele
între 1-25.
Intersecţia a două relaţii X şi Y presupune realizarea colecţiei noi cu Z elemente
comune celor două colecţii iniţiale. Colecţia de materiale având coduri între 1-20 intersectată
cu colecţia materialelor de cod între 15-25 are ca rezultat colecţia materialelor având coduri
între 15-20.
Produsul a două relaţii X şi Y este reprezentat de mulţimea perechilor posibil de
realizat, prin concatenarea unei realizări x din X cu o proprietate y din Y. Fie o colecţie
PERSOANE şi o colecţie COPII. Produsul acestora este o nouă colecţie unde fiecare
persoana are copilul ei.

PERS COPII PRODUS

cod nume_parinte cod nume1 nume2 nume_parinte nume_copil
100 Popa 100 Ion Ioana Popa Ion
200 Radu 200 Mircea Popa loana
300 Ababei 300 Ana Mihai Radu Mircea
Ababei Ana

Diviziunea realizează operaţia inversă produsului adică dintr-o relaţie de grad m+n
obţinem două relaţii de grade m, respectiv n. Avem colecţia PERS în care apare numele şi
prenumele copiilor şi extragem separat numele de familie şi separat prenumele copiilor.

PERS FAMILII COPII

nume prenume nume prenume
Popa Ion Popa Ion
Popa Ioana Radu Ioana.
Radu Mircea Ababei Mircea
Ababei Ana Ana
Ababei Mihai Mihai

Compunerea-(joncţiunea) se aplică asupra a două relaţii X şi Y care au în structura

lor o caracteristică comuna permiţând obţinerea unei noi relaţii cu o structură mai largă,
formată din atributele relaţiilor. Pentru o colecţie ELEVI şi una PROIECTE care au numărul
matricol ca legătură se poate obţine relaţia ASOCIERE.

Baze de Date   30 
Capitolul 4

ELEVI PROIECTE ASOCIERE

matr nume adresa matr tema nota matr nume tema nota

100 Nucu Ion Iasi 100 matrici 10 100 Nucu Ion matrici 10

200 Popa Ion Iasi 200 grafuri 9 200 Popa Ion grafuri 9

Selecţia aplicată asupra unei relaţii X cu n realizări are ca rezultat o relaţie Y definită
pe aceeaşi structură de caracteristici dar cu m realizări în funcţie de satisfacerea unor condiţii.

Exemplu: pe relaţia ELEVI aplicăm selector adresa="Iasi"

ELEVI Selectia prin adresa = "Iasi"

matr nume adresa matr nume adresa
100 Nucu Ion Iasi 100 Nucu Ion lasi
200 Popa Ana Iasi 200 Popa Ana Iasi
600 Amariei Gelu Vaslui 700 Vlad Nicu Iasi
500 Luca Paul Bacau
700 Vlad Nicu Iasi

Proiecţia aplicată asupra unei relaţii X cu N realizări are ca rezultat o relaţie Y

definită prin eliminarea realizărilor duplicat şi cu o structură simplificată. Pe relaţia "elevi"
aplicăm proiecţia "adresa":

ELEVI Proiectia prin adresa

matr nume adresa adresa
100 Nucu Ion Iasi Iasi
200 Popa Ana Iasi Vaslui
600 Amariei gelu Vaslui Bacau
500 Luca Paul Bacau
700 Vlad Nicu Iasi

Scăderea sau diferenţa a două relaţii este dată de mulţimea de N realizări care
aparţin primei relaţii şi nu aparţin celei de-a doua. Pentru aceleaşi colecţii de gestiune a
materialelor (prima cu numere de cod între 1001-2000, iar a doua între 1500-2500) a face
diferenţa înseamnă a realiza colecţia cu materiale de cod între 1001-1500.

Llmbaje relaţionale
Modelul relaţional a adus o revoluţie nu numai în organizarea informaţiei ci şi în
modalitatea de interogare a acestora. Până la consacrarea SGBDR pentru extragerea
informaţiilor din baza de date era necesar să se utilizeze exclusiv aplicaţii scrise în limbajele
procedurale pentru care trebuia să se precizeze atât datele căutate cât şi metodele de căutare şi
de extragere a acestora.
Generalizarea SGBDR-urilor a condus şi la elaborarea şi implementarea unor noi
limbaje performante pentru manipularea datelor - limbaje de interogare, neprocedurale.
Utilizatorul îşi defineşte datele ce trebuie extrase, sarcina căutării şi extragerii revenind
exclusiv SGBD-ului,

Baze de Date   31 
Capitolul 4

Clasificarea limbajelor relaţionale:

1. ansambliste: fondate pe teoria ansamblurilor şi algebrei relaţionale (SQL, Chamberlin-1976);

2. predicative; fondate pe teoria predicatelor. Sunt divizate în două clase:
• orientate asupra tuplurilor (ALPHA (Codd-1970), QUEL(Stonebraker1976);
• orintate pe domenii care pot fi:
• non-grafice - la care reprezentarea unei consultări ale lor "în linie" prin dispunerea
succesivă a operatorilor, atributelor şi relaţiilor (ILL(Lacroix-1970), FQL (Pirotte-
1976))
• grafice - la care consultarea se poate face interactiv, nu prin scrierea unei linii de
comandă ci printr-un sistem de meniuri QBE(Zloof-1975)

Trăsături generale ale limbajelor relaţionale

a) operatorii relaţionali se aplică asupra relaţiilor luate în globalitatea lor, adică

întregului ansamblu de tupluri ce alcătuiesc relaţiile respective;
b) rezultatul fiecărui operator este o nouă relaţie care poate servi ca argument
într-o nouă consultare;
c) operatorii sunt bazaţi pe valorile atributelor ca singurul mod de acces la
acestea.

Reprezentanţi ai SGBDR-urilor
Primele încercări pentru implementarea unui sistem de gestiune relaţional al bazelor
de date s-au concretizat într-un produs al firmei IBM numit System/R (anii 1974-1978) de la
care pleacă apoi DB2, unul dintre cele mai cunoscute SGBDR. Limbajul SQL a fost lansat ca
primul limbaj structurat de interogare în 1975 sub numele SEQUEL dar continuu
perfecţionat.
Între timp compania Relation Software Inc. dezvoltă un produs bazat pe limbajul
SQL numit Oracle şi lansat în 1979. Marele avantaj al firmei a fost orientarea sa către
minicalculatoare Vax mult mai ieftine decât mainframe-urile firmei IBM. Astfel succesul a
fost total. Astăzi firma redenumită Oracle Corporation este liderul produselor software
dedicate mediilor de lucru cu baze de date.
Tot în perioada de pionierat a "relaţionalului" au fost INGRES, QUERY BY
EXEMPLE, RDMS, etc.
Până în anii '80 SGBDR-urile au stat în umbra bazelor de date în reţea motivul fiind
viteza mai mică, parametru esenţial în sistemele confruntate cu sute sau mii de utilizatori.
Câştigul de viteza şi limbajele de generaţie 4 au lărgit continuu segmentul ocupat de SGBDR,
astăzi acesta fiind estimat la cca 60% din piaţă. Astfel:

1. SGBDR pentru mainframe-uri:

Pentru sistemele informaţionale complexe instalate pe mainframe-uri şi minicalculatoare
care permit accesul simultan a sute sau mii de utilizatori, sistemul de operare este
UNIX. Piaţa SGBDR pentru UNIX este împărţită între giganţi precum Oracle, Informix,
Sybase, Ingres, Progress, IBM.

Baze de Date   32 
Capitolul 4

2. SGBDR tip server pentru grupuri de lucru:

Pentru accesul simultan a 20-30 utilizatori din intreprinderi mici şi mijlocii sunt produse
dedicate sistemelor de operare Windows NT, Netware, OS/2 dintre care cele mai
cunoscute sunt: Oracle, Microsoft, Gupta, Computer Associates.

3. SGBDR pentru microcalculatoare:

Pentru utilizatorii individuali obişnuiti, neprofesionişti sau ca medii de lucru în staţiile
client din reţelele unei intreprinderi sunt produsele sub MS/DOS, Windows dintre care
amintim: dBASE, FoxBase, Paradox, Clipper, FoxPro, Access, FileMaker Pro.

O tendinţă a pieţii SGBD-urilor ţine de micşorarea distanţei dintre produsele dedicate

mainframe-urilor şi cele de tip server pentru grupurile de lucru. Majoritatea produselor pot
rula şi pe platforme UNIX şi Windows NT.

Baze de Date   33 
Capitolul 4

Întrebări şi exerciţii recapitulative

Ö Ce înţelegeţi prin "trigger-e"? Ce sunt restricţiile de integritate?
Ö Care sunt operatorii tradiţionali pentru colecţii de date? Care sunt operatorii relaţionali?
Ö Ce limbaje sunt folosite pentru bazele de date relationale? Când a apărut limbajul SQL?
Ö Enumeraţi câteva produse reprezentative pentru Mainframe-uri:
Ö Care sunt produsele de gestiune pentru microcalculatoare?

P10. Realizaţi schema unei baze de date relaţionale pentru o agenţie teatrală din localitatea X
ştiind că:
Ö se desfaşoară activităţi de planificare a spectacolelor pe săli şi date calendaristice;
spectacolele sunt ale diverselor trupe de teatru din ţară.
Ö se informează prompt clienţii despre spectacolele programate în stagiunea curentă (care
este trupa de teatru care a montat spectacolul, ce distribuţie, ce regizor are spectacolul,
unde s-a mai jucat, când, în ce stagiuni, care spectacol are succesul de casă cel mai
mare).
Ö se informează clienţii despre "stelele" teatrului (unde stau, cand s-au născut (când au
murit !), în ce spectacole au jucat/joacă, ce roluri au avut,...).
Ö se eliberează bilete la spectacolele săptămânii următoare, se calculează gradul de
ocupare a sălilor.

P11. Fie următoarea schemă a unei baze de date în model reţea pentru un inspectorat şcolar.
Să se transforme într-o schemă relaţională!

Observaţi legăturile făcute prin coduri. Este o schemă completă? Mai trebuie atribute? Dar tabele?

Baze de Date   34