BAza de Date

CAPITOLUL 1
INTRODUCERE ÎN BAZE DE DATE
1.1. EVOLUŢIA PROCESULUI DE ORGANIZARE A DATELOR
Organizaţiile gestionează colecţii de date în scopul satisfacerii cerinţelor informaţionale

la toate nivelele decizionale (operaţional, tactic, strategic). În absenţa datelor asupra
funcţionării interne şi asupra mediului extern, o organizaţie nu ar putea supravieţui.
O colecţie de date reuneşte date despre o anumită clasă de obiecte (reale sau
conceptuale). De exemplu, în domeniul contabilităţii financiare, colecţia de date
CONTURI conţine informaţiile referitoare la clasa de obiecte conturi: simbolul contului
(SIMB_CONT), denumirea contului (DEN_CONT), tipul contului (TIP_CONT), soldul iniţial
debitor (SID) şi respectiv soldul iniţial creditor (SIC). Evident, un cont dat va avea soldul
iniţial fie debitor, fie creditor. Pentru exemplificare, considerăm colecţia de date
CONTURI.
SIMBOL_CONT DENUMIRE_CONT TIP_CONT SID SIC

121 Profit şi pierderi B 0 1000
O realizare a colecţiei de date CONTURI
Într-o întreprindere sunt identificate mai multe colecţii de date, de exemplu:

PERSONAL – conţine informaţii despre persoanele angajate în firmă;
PRODUSE - conţine informaţii despre produsele realizate;
STOCURI - conţine informaţii despre stocurile existente de materii prime,
materiale, produse finite, etc.
TRANZACŢII - conţine informaţii privind intrările/ieşirile în/din stocuri.
Procesul de organizare a datelor presupune:

 definirea, structurarea, ordonarea şi gruparea datelor în colecţii de date omogene;
 stabilirea relaţiilor între date, între elementele unei colecţii, între colecţii de date;
 stocarea datelor pe suport informational.
Organizarea datelor este necesară pentru:

 minimizarea timpului de acces la date;
 asigurarea unicităţii datelor;
 sistemul de organizare a datelor adoptat trebuie să reflecte cât mai fidel toate
legăturile dintre obiectele, fenomenele, procesele economice pe care aceste date le
reprezintă;
 asigurarea flexibilităţii datelor.
12 Baze de date
Etapele evoluţiei procesului de organizare a datelor

Procesul de organizare şi prelucrare a datelor a parcurs mai multe etape, până s-a ajuns
la soluţia dominantă în prezent, care constă în organizarea datelor în baze de date.
Principalele etape ale evoluţiei tehnicilor de organizare şi prelucrare a datelor sunt:

 Prima etapă – se caracterizează prin adaptarea tipurilor de organizare a datelor
existente în sistemele de prelucrare manuală la condiţiile tehnice impuse de
calculator. În această etapă, apare fişierul organizare secvenţială, iar ca suport de
memorare externă se utilizează benzile magnetice. Este caracteristică
prelucrarea pe loturi (batch processing).
 A doua etapă – este marcată de separarea dintre structura logică de date şi

structura fizică. Rezultă independenţa fizică a datelor. În această etapă se
utilizează fişiere secvenţial-indexate, fişiere directe, fişiere inverse, etc. Ca suport
de memorare externă apare discul magnetic.
Se asigură independenţa aplicaţiilor de modificările echipamentelor hardware
(bandă, disc, etc.). Apar primele facilităţi de protecţie a datelor. Apare şi
posibilitatea de lucru în mod conversaţional. O facilitate importantă pusă la
dispoziţia utilizatorilor este generarea automată de rapoarte. Apare o separare
(parţială) între modul în care un fişier este privit de utilizator (nivelul logic) şi
modul de memorare pe suportul magnetic (nivelul fizic).
O caracteristică comună a primelor două etape: fiecare aplicaţie lucrează cu propriile

fişiere, fără a avea nici o legătură cu fişierele utilizate de alte aplicaţii. Aceasta aduce
inconvenienţe majore legate de:
 redundanţa datelor - prezenţa aceloraşi date în mai multe fişiere, crează
probleme evidente în operaţiile de actualizare;
 inconsistenţa datelor - aceeaşi informaţie este memorată diferit în fişiere diferite
(mai ales când informaţia se modifică);
 absenţa unor legături logice între datele din grupuri diferite de fişiere, număr
mare de fişiere, timp mare de prelucrare;
 flexibilitate redusă a sistemului la apariţia unei noi aplicaţii.
 A treia etapă – este definită de apariţia fişierelor integrate (sisteme de fişiere). Se

reduce redundanţa şi implicit inconsistenţa datelor - aceleaşi date fizice pot fi
utilizate în comun de către mai multe aplicaţii. Apar proceduri care gestionează
relaţiile dintre fişierele din sistem, rezultând astfel o structură logică unitară.
Rămân însă deficienţele comune primelor două etape, legate de gestiunea
fişierelor care uneori este realizată cu programe scrise în diferite limbaje de
programare. Structura fişierului trebuie precizată în programul de gestiune, ceea
ce conduce la modificarea programului în cazul modificării structurii fişierului.
Notă. Structura integrată stă la originea noţiunii de model conceptual (modelul ce

conţine descrierile tuturor datelor şi a legăturilor dintre ele).
Introducere în baze de date 13
În concluzie, sistemele bazate pe fişiere (file based) au următoarele caracteristici:

 fiecare program defineşte şi gestionează propriile date;
 datele sunt descrise independent în toate fişierele în care apar;
 fiecare fişier de date este descris în toate programele care îl accesează;
 nu există control al accesului şi al manipulării datelor, în afara celui impus prin
programele de aplicaţie.
Din aceste carcateristici decurg următoarele dezavantaje ale organizării datelor după
modelul file based:
 redundanţa şi inconsistenţa datelor;
 dificultatea accesului – în cazul în care o informaţie este exploatată de mai mulţi
utilizatori, fişierele tradiţionale nu permit accesarea datelor după mai multe
criterii specifice diferiţilor utilizatori sau grupuri de utilizatori;
 complexitatea actualizărilor – într-un mediu multiutilizator (multiuser)
efectuarea unei actualizări (modificare, adăugare sau ştergere) poate conduce la
situaţii conflictuale atunci când doi utilizatori vor să modifice simultan aceeaşi
dată; acest gen de conflicte poate fi rezolvat printr-un program supervizor al
prelucrărilor;
 probleme de securitate – crearea unor mecanisme de protecţie a datelor
împotriva accesului neautorizat este dificilă;
 asigurarea integrităţii datelor – presupune crearea unor proceduri de analiză a
restricţiilor semantice la care sunt supuse datele; acestea formează mecanismul
de integritate;
 dificultatea de a obţine răspunsuri rapide la probleme ad-hoc simple – presupune
realizarea unor programe utilizând limbaje procedurale pentru a obţine
răspunsul la o interogare;
 inflexibilitatea faţă de schimbările ulterioare din sistemul informaţional;
 costul ridicat – datorat gradului de redundanţă a datelor şi efortului necesar
interconectării fişierelor de date pentru a realiza un nivel minim de integritate şi
securitate a datelor.
 A patra etapă – este etapa bazelor de date. Sintagma bază de date apare în
anul 1964, în titlul conferinţei Development and Management of a Computer –
Centered Data Base organizată la Santa Monica (California) de System
Development Corporation. Momentul consacrării termenului DATA BASE este
1969, când la CODASYL (Conference On DAta SYstems Language) se prezintă
într-un raport conceptul de bază de date.
14 Baze de date
1.2. BAZE DE DATE - CONCEPTE GENERALE
Definiţia 1.1. DATA reprezintă înregistrarea unei observaţii, obiect, fenomen, imagine,
sunet sau text, într-o formă convenabilă unei prelucrări, interpretări sau transmiteri prin
mijloacele informaticii. Datele reprezintă aspecte elementare nesupuse unei prelucrări şi
neevaluate din punct de vedere al utilităţii.
Definiţia 1.2. INFORMAŢIA este semnificaţia ce poate fi ataşată sau poate fi dedusă
dintr-un ansamblu de date pe baza corelaţiilor dintre acestea, având un scop bine
determinat, de satisfacere a cerinţelor utilizatorilor.
Definiţia 1.3. BAZA DE DATE (Database) este un ansamblu structurat de colecţii de date
operaţionale înregistrate pe suport adresabil, aflate în interdependenţă logică, împreună
cu descrierea datelor şi a relaţiilor dintre ele şi care sunt prelucrate în aplicaţiile
informatice ale unei organizaţii. Baza de date permite operaţii de introducere, ştergere,
actualizare şi interogare a datelor.
BAZA DE DATE este un ansamblu de date:

 structurate;
 coerente, adică există legături (interdependenţe) logice între diferitele colecţii
ce alcătuiesc baza de date; coerenţa bazei de date este dată de restricţiile de
integritate care sunt verificate la fiecare operaţie de actualizare;
 persistente, adică datele rămân memorate pe suport magentic, independent
de execuţia programelor de aplicaţii, fiind păstrate pentru o anumită perioadă
de timp;
 neredundante - condiţia de neredundanţă este în general înlocuită de o
condiţie mai slabă: redundanţă minimă şi controlată în scopul de a mări viteza
de acces la date;
 independente de programul de aplicaţie;
 direct accesibile după mai multe criterii;
 simultan accesibile de către mai mulţi utilizatori.
În gestiunea bazelor de date există două tipuri de baze de date:
BAZE DE DATE OPERAŢIONALE – sunt utilizate cu precădere în prelucrarea on-line a

tranzacţiilor (on-line transaction processing – OLTP), adică în situaţii cînd este necesară
colectarea, modificarea şi întreţinerea zilnică a bazelor de date. Datele stocate într-o
bază de date operaţională sunt de tip dinamic, ceea ce înseamnă că se modifică în
permanenţă şi reflectă întotdeauna informaţii actualizate în timp real.
BAZE DE DATE ANALITICE - sunt utilizate mai ales în aplicaţiile de prelucrare analitică on-
line (on-line analytical processing – OLAP), când este necesară stocarea şi urmărirea
datelor istorice şi dependente de timp. Sunt importante cînd este necesară urmărirea
tendinţelor, vizualizarea datelor statistice pe o perioadă mai lungă de timp sau
efectuarea unor previziuni tactice sau strategice de afaceri. Datele stocate într-o bază de
date analitică sunt de tip static, adică nu se modifică niciodată (sau foarte rar). Bazele de
date analitice utilizează frecvent bazele de date operaţionale ca sursă principală de date.
ARHITECTURA UNUI SISTEM DE BAZE DE DATE (Database System) cuprinde:

 baza de date propriu-zisă în care se memorează datele
 software-ul format din Sistemul de Gestiune al Bazei de Date (SGBD) şi aplicaţiile
de baze de date (Database Application)
 metabaza de date - dicţionarul datelor (DD), conţine informaţii despre date,
structura acestora, documentaţie
 hardware-ul utilizat
 utilizatorii bazei de date: administratorul bazei de date, programatorul de
aplicaţii (administratorul aplicaţiei) şi utilizatorii finali (nespecialişti)
 reglementările legislative ce permit buna funcţionare a sistemului.
Cerinţele minimale care se impun unei baze de date sunt:
 furnizarea în timp util a informaţiilor solicitate; se referă la timpul de răspuns la o

interogare efectuată;
 costuri minime de prelucrare şi întreţinere a informaţiei;
 capacitatea de a satisface, cu aceleaşi date necesităţile informaţionale ale unui
număr mare de utilizatori;
 flexibilitatea - posibilitatea de adaptare la cerinţe noi, de a da răspunsuri la
interogări neprevăzute iniţial;
 integrarea – baza de date poate fi considerată o unificare a mai multor fişiere –
altfel diferite – redundanţa acestor fişiere fiind parţial sau total eliminată;
 asigurarea unei redundanţe minime şi controlate a datelor – rezultă din cerinţa
de integrare; menţinerea mai multor copii ale aceloraşi date poate fi impusă de
motive de ordin tehnic, însă această redundanţă minimă trebuie controlată cu
atenţie, ceea ce presupune ca sistemul de gestiune al bazei de date să o
cunoască şi să-şi asume responsabilitatea de a propaga actualizările;
 partajarea şi sincronizarea – posibilitatea de partajare şi exploatare simultană a
datelor de către mai mulţi utilizatori; se realizează astfel posibilitatea de acces
concurent la date;
 confidenţialitatea – asigurarea securităţii datelor prin mecanisme de protecţie
împotriva accesului neautorizat;
 integritatea – presupune existenţa unor proceduri de validare şi recuperare a
datelor după accidente; problema integrităţii este de a garanta (atât cât este
posibil) că datele din baza de date sunt corecte;
 compatibilitatea şi expandabilitatea – posibilitatea de valorificare a eforturilor
anterioare şi anticiparea nevoilor de dezvoltare;
 permisivitatea – posibilitatea de ierarhizare a datelor după criteriul frecvenţei
acceselor sau reorganizarea datelor în scopul creşterii performanţelor bazei de
date.
16 Baze de date
Utilizatorii bazei de date sunt:
 Administratorul bazei de date (DBA - DataBase Administrator) este responsabil

de menţinerea funcţionalităţii bazei de date: prin efectuarea operaţiilor
periodice de salvare a datelor (backup) şi de refacerea a datelor în cazul apariţiei
unui incident (rollback) şi prin urmărirea performanţelor sistemului; autorizează
drepturile de acces pentru diferitele categorii de utilizatori, ajută la definirea
cerinţelor utilizatorilor, etc.
 Programatorul de aplicaţii (administratorul aplicaţiei) este cel care dezvoltă

aplicaţiile de baze de date folosind limbaje de programare de nivel înalt,
generatoare de aplicaţii şi biblioteci care permit încorporarea operaţiilor de
acces la baza de date; aplicaţiile care rezultă pot fi cu execuţie independentă
(batch-processing) sau pot fi aplicaţii interactive (on-line) destinate utilizatorilor
finali.
 Utilizatorii finali (nespecialişti) accesează baza de date prin intermediul unui

program de aplicaţie care le dă drepturi limitate de acces la date pentru anumite
operaţii de prelucrare; utilizatorii finali, în general, efectuează un număr mare de
operaţii tranzacţionale asupra bazei de date utilizând interfeţe de comunicare cu
baza de date apropiate de limbajul natural, dar nu cunosc structura bazei de date
şi nici modul efectiv de lucru cu baza de date.
Arhitectura internă a unui sistem de baze de date (figura 1.1) - conţine trei nive niveluri
de abstractizare şi percepţie a datelor, introduse în anul 1975, prin raportul ANSI/SPARC
DBMS – Report of the Study Group on Data Base Management Systems (Acronimul
ANSI/SPARC înseamnă American National Standards Institute / Standards Planning And
Requirements Committee):
 Nivelul intern (Internal Schema) – specifică modul de stocare a datelor în sistem.

Vederea internă este o reprezentare de nivel inferior a întregii baze de date şi
este descrisă prin intermediul schemei interne, care defineşte diversele tipuri de
înregistrări stocate, specifică indexurile care există, modul în care sunt
reprezentate câmpurile stocate, în ce secvenţă fizică se află înregistrările stocate,
etc. Schema internă este scrisă folosind un limbaj de definire a datelor - limbajul
DDL intern. Administratorul bazei de date este responsabil cu crearea schemei
interne, adică proiectarea fizică a bazei de date.
 Nivelul extern (External Schema, User’ View) – este nivelul logic al utilizatorului
individual, care este cel mai apropiat de utilizator. Acesta poate fi un
programator de aplicaţii (administratorul aplicaţiei) sau un utilizator final.
Fiecare utilizator are la dispoziţie un limbaj:
- pentru programatorul de aplicaţii (administratorul aplicaţiei) limbajul poate
fi Java, C++, PL/I, etc.
- pentru utilizatorul final limbajul va fi ori unul de interogare (SQL), ori unul
specializat adaptat cerinţelor utilizatorului.
Un sistem de baze de date acceptă mai multe limbaje gazdă. Un sublimbaj de

date (DSL – Data SubLanguage) este un subset al limbajului complet, care se
referă în mod specific la obiectele şi operaţiile bazei de date. Sublimbajul de date
este înglobat în limbajul gazdă corespunzător. Unul dintre sublimbajele de date
acceptat de către majoritatea sistemelor curente este SQL. Limbajul SQL, care va
fi prezentat în Capitolul 4, poate fi folosit interactiv, ca limbaj de interogare
autonom, cât şi înglobat în alte limbaje, cum ar fi Java, C++, PL/I, etc.
De exemplu, sistemul de baze de date Oracle are 6 precompilatoare (C, Pascal,
Ada, Cobol, Pl/1, Fortran) care permit includerea de instrucţiuni SQL sau blocuri
PL/SQL în programele scrise în limbajele gazdă.
Orice sublimbaj de date conţine două limbaje subordonate:
- un limbaj de definire a datelor (DDL –Description Data Language) pentru
definirea obiectelor bazei de date;
- un limbaj de manipulare a datelor (DML – Data Manipulation Language) care
realizează prelucrarea acestor obiecte.
Observăm că graniţele dintre: a) limbajul gazdă şi sublimbajul de date şi b)

limbajele DDL şi DML sunt de natură conceptuală. Important este ca aceste
limbaje să fie transparente pentru utilizator.
 Nivelul conceptual (Conceptual Schema) – corespunde unei reprezentări

abstracte a întregului conţinut informaţional al bazei de date. Schema
conceptuală este scrisă folosind un limbaj DDL conceptual şi conţine definiţii ale
conţinutului informaţional, care includ caracteristici suplimentare, cum ar fi
constrângerile de securitate şi de integritate. Proiectarea logică sau conceptuală
a bazei de date reprezintă responsabilitatea administratorului de date (DA – Data
Administrator). Administratorul de date (numit şi administratorul întreprinderii)
este persoana care “înţelege” datele şi necesităţile întreprinderii referitoare la
ele. Are ca sarcină să decidă ce date trebuie stocate în baza de date şi să
stabilească regulile de întreţinere şi de tratare a acestor date.
18 Baze de date
Utilizator A1 Utilizator A2 Utilizator B1
Limbaj Limbaj Limbaj

gazdă + gazdă + gazdă +
DSL DSL DSL
Schema Schema
externă A - Vederea externă externă B - Vederea externă
interfaţa cu A interfaţa cu B
utilizatorul utilizatorul
Corespondenţa extern/
conceptual pentru B
Corespondenţa extern/
conceptual pentru A
Schema Vederea
conceptuală conceptuală
Sistemul de
Corespondenţa
gestiune a
conceptual/intern
bazelor de date
(SGBD)
Definiţia
structurii de
stocare Baza de date stocată
(schema
(vederea internă)
internă)
Fig.1.1. Arhitectura unui sistem de baze de date

(sursa: Date C.J., Baze de date)
1.3. SISTEMUL DE GESTIUNE AL BAZEI DE DATE (SGBD)
Definiţia 1.4. Sistemul de gestiune al bazei de date (DBMS - Database Management

System) este un ansamblu de programe (produs software) care permite definirea,
actualizarea şi consultarea datelor din baza de date.
Sistemul de gestiune al bazei de date tratează accesul la baza de date după următorul
algoritm:
Pasul 1. Utilizatorul lansează o cerere de acces, folosind un sublimbaj de date (de regulă
SQL).
Pasul 2. Sistemul SGBD acceptă cererea şi o analizează.
Pasul 3. SGBD-ul analizează pe rând schema externă, corespondenţa extern-conceptual,
schema conceptuală, corespondenţa conceptual-intern şi definiţia structurii de
stocare.
Pasul 4. SGBD-ul execută operaţiile necesare în baza de date stocată.
Obiectivele unui SGBD:
 Independenţa fizică. SGBD-ul are ca obiectiv central asigurarea independenţei

dintre structurile de stocare a datelor şi structurile de date din lumea reală,
adică dintre schema internă şi schema conceptuală. Cele două scheme descriu
aceleaşi date, dar la nivele diferite. Independenţa fizică dă posibilitatea
modificării schemei interne fără a modifica schema conceptuală, ţinând cont
doar de criterii de performanţă şi flexibilitate a accesului.
 Independenţa logică – este un obiectiv important şi reprezintă posibilitatea de

a modifica schema externă fără a modifica schema conceptuală. Asigură
deasemenea independenţa între utilizatori, fiecare având o anumită viziune
asupra bazei de date. Avantajele independenţei logice sunt următoarele:
- permite fiecărui grup de utilizatori să vadă datele aşa cum şi le doresc;
- permite evoluţia schemei externe a unui grup de utilizatori fără a
modifica schema conceptuală;
- permite evoluţia unei scheme externe, fără a afecta celelalte scheme
externe.
În rezumat, este posibil de a adăuga / şterge atribute, de a adăuga / şterge
asociaţii, de a adăuga / şterge entităţi, în schemele externe, dar şi în schema
conceptuală, fără să se modifice cea mai mare parte a aplicaţiilor.
 Partajabilitatea datelor – obiectivul este de a permite ca aplicaţiile să partajeze

datele din baza de date, în timp şi simultan. O aplicaţie poate folosi date ca şi
cum ar fi singura care le utilizează, fără a şti că o altă aplicaţie, concurent, le
poate modifica.
20 Baze de date
 Integritatea şi coerenţa datelor – obiectivul este ca informaţiile să respecte

restricţiile de integritate definite. Conceptul de integritate a datelor se referă la
calitatea informaţiei înregistrate. Constrângerile de integritate sunt specificate
în definirea schemei bazei de date. Acestea sunt reguli care precizează valorile
permise pentru anumite date, eventual în funcţie de alte date, apartenenţa la
un anumit domeniu, la un anumit tip de date sau pot fi constrângeri
referenţiale, etc. Se asigură în acest mod coerenţa bazei de date
 Manipularea datelor de utilizatorii finali – are ca obiectiv utilizarea de către

nespecialişti a unor limbaje cât mai apropiate de limbajul natural (limbaje
neprocedurale) care să permită exploatarea cu uşurinţă a bazei de date şi
efectuarea interogărilor fără a preciza algoritmul de acces.
Funcţiile unui SGBD:
 Definirea datelor – SGBD-ul acceptă definiţiile datelor (schemele externe,

schema conceptuală, schema internă şi toate corespondenţele asociate) în
format sursă şi le transformă în format obiect. Pentru aceasta există o
componentă procesor sau compilator DDL (Data Definition Language) pentru
fiecare dintre limbajele de definire a datelor.
Dicţionarul de date (Data Dictionnary) – este o adevărată bază de date pentru
sistem şi conţine date despre date (numite şi metadate). Metabaza de date sau
dicţionarul de date este organizat sub formă de bază de date şi conţine definiţii
ale obiectelor din sistem, diverse scheme şi corespondenţe (externe,
conceptuale) precum şi restricţiile de securitate şi integritate.
 Optimizarea şi execuţia – cererile DML vor fi prelucrate de optimizator pentru a

realiza o implementare eficientă a cererii. Cererile optimizate sunt executate
apoi sub controlul unui program numit manager de execuţie.
 Gestiunea tranzacţiilor – tranzacţia este o funcţie care realizează trecerea unei

baze de date dintr-o stare S1 într-o stare S2. Un sistem de gestiune a bazelor
de date trebuie să asigure trei proprietăţi pentru această funcţie:
- atomicitatea tranzacţiei (Transaction Atomicity) este proprietatea ca o
tranzacţie să fie executată în totalitate sau deloc;
- corectitudinea tranzacţiilor (Transaction Correctness) este proprietatea
de respectare a coerenţei bazei de date la sfârşitul execuţiei tranzacţiei;
- izolarea tranzacţiilor (Transaction Isolation) este proprietatea tranzacţiei
de a nu lăsa vizibile modificările produse înainte de sfârşitul tranzacţiei.
 Securitatea şi confidenţialitatea datelor – presupune existenţa unor proceduri

de identificare şi autorizare a utilizatorilor pentru a proteja datele de un acces
neautorizat sau rău intenţionat. Acestea constituie limbajul de control al
datelor (DCL – Data Control Language). Cererile utilizatorilor sunt monitorizate
pentru a depista şi respinge orice încercare de încălcare a constrângerilor de

securitate.
Scheme şi Cereri DML Cereri DML neplanificate

corespondenţe-sursă planificate (ad-hoc)
Procesoare DDL Procesoare DML Procesorul

limbajului de
interogare
Cereri
compilate
Impunerea
Scheme şi corespon-
denţe sursă şi obiect
Optimizator constrângerilor de
securitate şi
integritate
Cereri
optimizate
Manager de Metadate
execuţie
Baza de date
Date
Metadate (dicţionar de date)
Fig.1.2. SGBD - Funcţiile şi componentele principale

(sursa: Date C.J., Baze de date)
22 Baze de date
 Manipularea datelor - presupune instrumente şi mecanisme ce permit

comunicarea: bază de date - utilizatori. SGBD-ul are o componentă procesor
sau compilator DML (DML – Data Manipulation Language) care permite
specificarea operaţiilor de introducere, actualizare, ştergere şi interogare a
datelor din baza de date. Cererile DML pot fi planificate (interogări prevăzute
anterior) şi neplanificate (interogări ad-hoc).
Interfeţele sunt alte forme de comunicare care permit SGBD-ului să transmită
date către alte limbaje de programare (Pascal, Java, C++, Cobol etc.). Aceste
interfeţe permit accesul şi manipularea datelor dintr-o bază de date plecând de
la un program scris într-un limbaj de programare clasic (procedural).
 Refacerea datelor şi concurenţa – presupune existenţa în sistem a unor

componente software care să permită controlul refacerii bazei de date după
incidente, precum şi controlul accesului concurent la date. Aceste mecanisme
sunt bazate pe înregistrarea operaţiunilor realizate asupra bazei de date şi
reexecutarea lor automată în caz de incident. Cererile de acces simultane sunt
înregistrate într-un fir de aşteptare şi sunt deservite într-o anumită ordine.
 Transformarea datelor (Data mapping) – este o funcţie care permite trecerea

datelor din formatul corespunzător unui nivel în formatul altui nivel. Deoarece
există trei niveluri (extern, conceptual şi intern) vor exista două niveluri de
transformare:
- transformarea conceptual – intern permite trecerea datelor din formatul
conceptual în formatul intern şi reciproc;
- transformarea extern - conceptual permite trecerea datelor din formatul
conceptual în formatul extern şi reciproc;
În sinteză, scopul general al Sistemului de gestiune a bazelor de date este de a furniza

interfaţa cu utilizatorul pentru sistemul de baze de date. Interfaţa cu utilizatorul se află
la nivel extern şi poate fi definită ca o graniţă a sistemului, dincolo de care totul este
invizibil pentru utilizator.
1.4. ARHITECTURA FUNCŢIONALĂ A UNUI SGBD
Arhitectura funcţională clasică a sistemelor de gestiune a bazelor de date integrează

cele trei niveluri:
 nivelul intern (baza de date fizică)

 nivelul conceptual (schema conceptuală)
 nivelul extern (vizualizarea).
Arhitectura este articulată pe dicţionarul datelor şi cuprinde două părţi:
 un ansamblu de module (numite procesoare) care permite descrierea datelor şi

deci constituirea dicţionarului datelor;
 o parte care asigură manipularea datelor, adică interogarea şi actualizarea bazei
de date.
În fiecare din părţi se regăsesc cele trei niveluri intern, conceptual şi extern.
Georges Gardarin (2003) propune o arhitectură funcţională de referinţă apropiată de

arhitectura sistemelor de gestiune a bazelor de date actuale, bazată pe două niveluri:
schema şi vizualizările. Schema corespunde integrării schemelor internă şi conceptuală,
iar vizualizarea este o schemă externă.
Din punct de vedere al descrierii datelor, un SGBD gestionează un dicţionar de date,

numit şi metabaza de date, care este organizat ca o bază de date care descrie alte baze.
Dicţionarul de date este alimentat prin comenzi de definire a schemei (CREATE ENTITY,
CREATE RELATIONSHIP, CREATE INDEX) şi prin comenzi de definire a vizualizărilor
(DEFINE VIEW). Aceste comenzi sunt analizate şi tratate de un procesor numit analizor,
mai exact de partea procesorului ce tratează limbajul de descriere a datelor.
Din punct de vedere al manipulării datelor, cererile (de exemplu: APPEND, MODIFY,
DELETE ) sunt tratate de analizorul de cereri, care realizează analiza sintactică (conform
gramaticii) şi analiza semantică (conform vizualizării referite sau schemei) şi le traduce
în format intern. O cerere în format intern, care se referă la o vizualizare, este tradusă în
una sau mai multe cereri care fac referinţă la obiecte ce există în baza de date. Această
funcţie este realizată de către un procesor-translator numit controlor de cereri, care
modifică cererile şi în plus asigură controlul drepturilor de acces (autorizează
citirea/scrierea unui obiect) şi controlul integrităţii în cazul actualizărilor. Controlul
integrităţii constă în verificarea dacă baza de date nu a fost “poluată” în timpul
actualizării, adică regulile de coerenţă a datelor se verifică şi după actualizare.
24 Baze de date
Analiza sintactică
Analizor Analiza semantică
Gestiunea schemelor
Modificarea cererilor
Controlor Controlul integrităţii
Controlul automatizării
Dicţionarul Optimizare
datelor Optimizor Elaborarea planului
(metabaza)
Execuţia planului
Executor Metode de acces
Controlul concurenţei
Atomicitatea tranzacţiilor
BD
Fig.1.3. Arhitectura unui SGBD

(sursa: Gardarin G., Bases des données)
Optimizatorul de cereri este un procesor cheie al sistemului de gestiune al bazei de date.

Are ca rol esenţial elaborarea unui plan de acces optimizat pentru tratarea cererilor.
Acest procesor descompune cererea în operaţii de acces elementare (de exemplu:
selectare de index, citire articol,...) şi stabileşte o ordine de execuţie optimă sau aproape
de optim pentru aceste operaţii. Procesorul alege şi metodele de acces care vor fi
utilizate. Pentru a efectua cea mai bună alegere, optimizatorul se bazează pe modele de
cost care permit evaluarea costului unui plan de acces înainte de execuţia sa. Rezultatul
optimizării (planul de acces optimizat) poate fi salvat în memorie pentru execuţii
multiple ulterioare sau executat direct şi apoi distrus.
Executorul este un procesor care are rolul de a executa planul de acces ales şi elaborat
de optimizator. El se bazează pe metodele de acces care permit accesul la fişiere prin
intermediul indecşilor şi / sau legăturilor. La acest nivel este gestionat controlul
accesului concurent şi atomicitatea tranzacţiilor.
1.5. ARHITECTURA CLIENT - SERVER
Scopul general al unui sistem de gestiune de baze de date este de a asigura dezvoltarea
şi execuţia aplicaţiilor pentru baze de date. După apariţia sistemelor distribuite
(Distributed Database System), arhitecturile operaţionale care s-au impus au fost
arhitecturile client – server.
Arhitectura client – server a fost proiectată de o echipă din cadrul ANSI/X3/SPARC,

numită DAFTG (Datbase Arhitecture Framework Task Group). Această arhitectură,
utilizată la sfârşitul anilor 80 de mai mulţi constructori de sisteme de gestiune de baze
de date, poate fi privită ca având două părţi: un server (numit şi back-end) şi un set de
clienţi (numiţi şi front-end) [DAT05].
Arhitectura client – server (Fig.1.4.) include nucleul unui sistem de gestiune de baze de
date numit DMCS (Description Manipulation and Control Sub-system), care funcţionează
în mod server [GAR03]. Limbajul DL (Data Language) este limbajul standard de acces la
SGBD.
Utilizatori finali
Aplicaţii Clienţi
SGBD Server
Baza de date
Fig.1.4. Arhitectura client – server (monoutilizator)

(sursa: Ionescu F., Baze de date relaţionale şi aplicaţii)
Serverul – este sistemul de gestiune al bazei de date, care asigură funcţiile prezentate în
paragraful 1.3. În acest context, noţiunea de server reprezintă doar o altă denumire a
sistemului de gestiune al bazei de date.
Clienţii – sunt diverse programe de aplicaţii, furnizate de realizatorul SGBD-ului sau

dezvoltate de utilizatori. Din punct de vedere al serverului, nu există nicio diferenţă între
26 Baze de date
aplicaţiile scrise de utilizator şi cele încorporate – toate folosesc aceeaşi interfaţă cu

serverul (interfaţa la nivel extern).
Aplicaţie Aplicaţie Aplicaţie

client client client
Reţea de comunicaţii
Server
SGBD
BD
Fig.1.5. Un calculator server şi mai multe calculatoare client

Sistem de baze de date centralizat multiutilizator
(Centralized Database System – Multiuser)
Aplicaţiile client pot fi executate pe staţii diferite, conectate printr-o reţea de

comunicaţie cu staţia pe care rulează serverul (Fig.1.5.). Această arhitectură permite o
prelucrare distribuită a datelor şi astfel, o configurare a sistemului adaptată cerinţelor
de calcul particulare. Serverul bazei de date poate fi un sistem puternic, iar fiecare client
este o staţie personală cu o putere de calcul adecvată aplicaţiei executate.
Un sistem de baze de date distribuit (Distributed Database System) poate avea atât
datele cât şi sistemul de gestiune al bazei de date, distribuite pe mai multe staţii
interconectate printr-o reţea de comunicaţie. Un astfel de sistem poate fi reprezentat
asemănător prin prisma structurării client-server (Fig.1.6.).
Aplicaţie Aplicaţie Aplicaţie

client client client
Reţea de comunicaţii
Server Server
SGBD SGBD
BD BD
Fig.1.6. Sistem de baze de date distribuit (arhitectură client-server pe două nivele

Sistemul software care gestionează o astfel de bază de date se numeşte sistem de

gestiune al bazei de date distribuite – SGBDD (Distributed Database Management
System – DDBMS). Aplicaţiile client rulează pe alte staţii din reţea şi solicită servicii de la
sistemul de gestiune distribuit.
Dintre avantajele sistemelor de baze de date distribuite amintim.

 creşterea capacităţii de stocare şi prelucrare a datelor;
 creşterea disponibilităţii şi a partajării datelor.
28 Baze de date
Sistemele de baze de date distribuite sunt sisteme cu o complexitate crescută, care

trebuie să asigure o cerinţă importantă - administrarea transparentă a datelor.
Transparenţa se referă la capacitatea unui sistem distribuit de a ascunde detaliile de
implementare, astfel încât utilizatorii să poată accesa datele fără a cunoaşte exact
modul de amplasare, replicare sau comunicare a datelor.
Multe aplicații Web utilizează o arhitectură pe trei nivele (three-tier architecture) care
adaugă un nivel intermediar între client şi serverul bazei de date (figura 1.7). Acest nivel
intermediar, în funcție de aplicație, este numit server de aplicație și, uneori, server Web.
Acest server joacă un rol intermediar, prin stocarea regulilor (proceduri şi resticţii) care
sunt utilizate pentru accesul datelor din serverul de baze de date. Se poate realiza astfel
o îmbunătățire a securităţii bazelor de date prin verificarea clientului înainte de a
transmite o cerere către serverul de baze de date. Clientul posedă interfeţe GUI
(Graphical User Interface) și aplicaţii Web specifice. Serverul intermediar acceptă cereri
din partea clientului, procesează cererea și trimite comenzile la serverul de baze de
date.
Client GUI, interfeţe Web
Serverul de aplicaţie programe de aplicaţie.

Web server pagini Web
Serverul Baze de date SGBD
Fig.1.7. Arhitectură client-server pe trei nivele

(sursa: Elmasri R., Navathe S., Fundamentals of Datebase Systems)
1.6. MODELE DE BAZE DE DATE
Un model de date reprezintă o colecţie integrată de concepte, utilizate în descrierea

datelor, relaţiilor dintre date şi constrângerilor asupra datelor.
Tipologia SGBD-urilor este în general funcţie de tipurile de structuri ale datelor pe care
le suportă. Dintre modelele cele mai des întâlnite amintim [ION04]:
 modelul ierarhic
 modelul reţea
 modelul relaţional
 modelul orientat-obiect
 modelul obiect relaţional
Modelul ierarhic (Hierarchical Model). Baza de date se reprezintă printr-o structură

ierarhică de înregistrări de date conectate prin legături. Modelul ierarhic a fost primul
model folosit pentru dezvoltarea bazelor de date. Cea mai cunoscută realizare de SGBD
ierarhic este sistemul IMS (Information Management System) dezvoltat de firma IBM în
anii ‘60, în cadrul programului Apollo. Modelul permite reprezentarea claselor sau
ansamblelor de obiecte printr-o structură ierarhică de înregistrări, având la bază
structura arborescentă, în care asocierile între clase de tip "tată-fiu" sunt de tip 1:N sau
1:1. Ansamblul claselor se constituie într-un arbore direcţionat în care nodurile sunt
tipurile de înregistrări, iar arcele sunt tipurile de legături.
PRODUSE
MATERIALE CLIENTI
FURNIZORI COMENZI APROVIZIONARE
Fig.1.8. Bază de date ierarhică

30 Baze de date
Modelul reţea (Network Model). Baza de date utilizează o structură de graf pentru
definirea schemei conceptuale a bazei de date. A apărut după modelul ierarhic şi a fost
standardizat în 1971 de o comisie DBTG (Database Task Group). Nodurile grafului sunt
tipurile de entităţi, iar muchiile reprezintă legăturile dintre tipurile de entităţi. Asocierile
sunt de tipul M:N şi se reprezintă fără duplicarea înregistrărilor, fiecare înregistrare
putând fi referită de mai multe înregistrări. Acest model este în prezent rar folosit
pentru baze de date generale care implică operaţii de interogare. Aplicarea modelului
reţea se întâlneşte în bazele de date grafice utilizate în modelarea realităţii virtuale.
CLIENTI FURNIZORI (F)

(CLI)
CONTRACTE NOTE COMANDA (NC)

(CON)
PRODUSE (P) MATERIALE (M)
Fig.1.9. Bază de date reţea
Structura de reprezentare reţea poate fi descompusă la nivel logic în structuri ierarhice,

prin acceptarea unei creşteri a redundanţei datelor. Această transformare este posibilă,
deoarece orice asociere de tipul M:N poate fi descompusă în mai multe asocieri de tipul
1:N. În figura 1.10 se prezintă modul de descompunere a structurii din figura 1.9, în
două structuri ierarhice.
CLI F CLI F
CON NC = CON NC + CON NC
P M P P M M
Fig.1.10. Descompunerea structurii reţea în două structuri ierarhice

Modelul ierarhic şi modelul reţea au dezavantajul că fiecare interogare trebuie să fie

prevazută încă din faza de proiectare, prin memorarea explicită a legăturilor între
tipurile de entităţi. În plus, complexitatea reprezentării datelor în modelul reţea este
deosebit de ridicată, iar programatorii trebuie să o cunoască pentru a putea realiza
aplicaţiile necesare.
Modelul relaţional (Relational Model) – permite vizualizarea unei baze de date ca un

ansamblu de tabele bidimensionale. Modelul se bazează pe noţiunea de relaţie din
matematică, care corespunde unei mulţimi de entităţi de acelaşi tip. Limbajele
relaţionale de manipulare a datelor sunt limbaje neprocedurale – utilizatorul, de
exemplu, formulează interogarea fără să indice procedura (algoritmul) de rezolvare.
Sistemele de gestiune a bazelor de date relaţionale (SGBDR) oferă un limbaj de
programare unanim recunoscut şi acceptat, limbajul SQL, bazat pe algebra relaţională.
Pentru limbajul SQL au fost emise mai multe standarde de către International
Standardization Office (ISO).
Modelul orientat-obiect (Object Model) – este un concept unificator în informatică, fiind

aplicabil în programare, în proiectarea hardware-ului, a bazelor de date, etc. Sistemele
de de gestiune a bazelor de date orientate obiect (SGBDOO) se bazează pe limbajele de
programare orientate obiect. Au o utilizare limitată, mai redusă decât cea a sistemelor
de baze de date relaţionale. Pentru bazele de date orientate obiect există un limbaj
standard de interogare OQL (Object Query Language) propus de ODMG (Object
Database Management Group).
Modelul obiect-relaţional (Object-Relational Model) – este considerat următorul mare

val în dezvoltarea şi întreţinerea bazelor de date. Construcţia se poate realiza
dezvoltând sistemul relaţional prin adăugarea caracteristicilor obiectuale necesare sau
pornind de la un sistem orientat obiect şi adăugând caracteristicile relaţionale. În
general, dezvoltarea sistemelor de gestiune a bazelor de date obiect-relaţionale
(SGBDOR) se realizează prin extinderea sistemelor relaţionale, gradat, prin adăugare de
caracteristici ale modelului obiect. Aceasta asigură continuarea aplicaţiilor relaţionale
existente în noile versiuni de sisteme SGBDOR, ceea ce permite producătorilor să-şi
păstreze clienţii şi domeniile de utilizare. Mari producători de sisteme de gestiune
(Oracle, Informix, IBM) au extins în acest mod sistemele lor relaţionale pentru a deveni
sisteme obiect-relaţionale. Standardele în domeniul sistemelor de gestiune a bazelor de
date obiect-relaţionale sunt extensii ale standardului SQL. Versiunea din anul 1999,
denumită SQL3, conţine extensii de orientare spre obiecte a limbajului SQL.
Stonebraker B. şi Brown P. dau în 1996 o reprezentare a universului bazelor de date,

(figura 1.11), bazată pe complexitatea interogărilor şi complexitatea datelor [ION04].
Această reprezentare nu include modelele prerelaţionale (modelul ierarhic şi modelul
reţea) considerate depăşite în această fază de dezvoltare a bazelor de date.
32 Baze de date
Complexitatea
interogărilor
SGBDR SGBDOR
Sisteme de SGBDOO
fişiere
Complexitatea
interogărilor
Fig.1.11. Clasificarea SGBD-urilor
Exemple de Sisteme de de gestiune a bazelor de date
Microsoft SQL Server este un sistem de gestiune a bazelor de date relaţionale

multiutilizator dezvoltat de firma Microsoft pentru sistemele de operare Windows. SQL
Server 7.0 a fost primul server de baze de date bazat pe interfaţă grafică (Graphical User
Interface sau GUI). O variantă de SQL Server 2000 a fost prima variantă comercială
pentru arhitectura Intel. In anii următori, s-au lansat și alte versiuni, ce au adus
îmbunătățiri de performanță: SQL Server 2005, SQL Server 2008, SQL Server 2012 și SQL
Server 2014. Ultima versiune (până în prezent) este SQL Server 2016.
Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date
relaţionale pe platforme de calculatoare personale. Microsoft Access dispune de un
sistem de control al bazei de date şi o intefaţă grafică pentru interacţiunea cu
utilizatorul. Aplicaţiile de baze de date în MS Access se pot dezvolta cu multă uşurinţă
datorită generatoarelor de aplicaţii (wizards) care permit proiectarea vizuală a bazelor
de date, a formularelor (forms) pentru interfeţele grafice şi a rapoartelor (reports).
Licenţa se cumpără odată cu cumpărarea licenţei produsului Microsoft Office.
MySQL este un sistem de gestiune a bazelor de date relaţionale, produs de compania

suedeză MySQL AB. Sistemul are implementări pentru sistemele de operare Linux, Unix,
Windows. Acest sistem este open source, adică se poate utiliza gratuit. Sistemul este
compatibil cu standardul SQL2, dar unele prevederi ale standardului sunt implementate
parţial. Scrierea aplicaţiilor se poate face şi în alte limbaje de programare pentru
accesarea bazelor de date MySQL, cum ar fi: C, C++, C#, Java, Perl, PHP.
Sistemul Oracle este un sistem de gestiune al bazelor de date relaţionale produs de

Oracle Corporation. Este un sistem foarte puternic, cu implementări pe toate
platformele (Windows, Linux, Unix), care oferă atât performanţe de execuţie ridicate,
cât şi un grad mare de protecţie şi securitate a datelor. În toate versiunile, Oracle oferă
implementarea completă a caracteristicilor modelului relaţional, conform standardului

SQL2, iar ultimele versiuni sunt sisteme de gestiune obiect-relaţionale (SGBDOR)
distribuite, implementând extensiile orientate obiect prevăzute în standardul SQL3 şi
oferind posibilitatea de dezvoltare a bazelor de date distribuite.
În anul 2013, Oracle a lansat Oracle Database 12c, prima bază de date concepută pentru
Cloud. Această soluţie oferă o nouă arhitectură multiutilizator, construită pe o platformă
de administrare a datelor rapidă, scalabilă1, stabilă şi sigură. Oracle Database 12c oferă
o arhitectură de maximă disponibilitate, prin operarea a sute de baze de date simultan.
Conectarea la Cloud prin intermediul Oracle Database 12c permite clienţilor să-şi
îmbunătăţească performanţa şi calitatea aplicaţiilor, să economisească timp cu
administrarea datelor2.
1.7. CLOUD COMPUTING
Cloud computing este un concept modern în domeniul informaticii, apărut în practică

prin anii 2006-2007, care reprezintă un ansamblu distribuit de servicii de calcul, aplicații,
acces la informații și stocare de date, fără ca utilizatorul să aibă nevoie să cunoască
amplasarea și configurația fizică a sistemelor care furnizează aceste servicii.
Expresia cloud computing derivă dintr-o reprezentare grafică simbolică a Internetului
des întâlnită în formă de nor („the cloud”), folosită atunci când detaliile tehnice ale
Internetului pot fi ignorate. Nu există, până în prezent, un termen în limba română care
să desemneze acest concept3.
Conexiunea permanentă a utilizatorului la Internet a devenit foarte răspândită, astfel

încât acum aproape toate resursele disponibile se pot plasa în Internet și partaja, uneori
chiar între utilizatori complet independenți unii de alții: software (programele) și
datele/informațiile sunt aduse din Internet pe calculatorul utilizatorului la cerere (on
demand), ca și cum ar fi vorba de servicii publice banale precum apa sau energia
electrică.
Executarea aplicațiilor de computer online în Internet și nu pe stația de lucru

(workstation) proprie, reprezintă o nouă schimbare de paradigmă, comparabilă cu cea
din anii 1980, când s-a trecut de la mainframes la conceptul client-server. Dacă interfața
pusă la dispoziție de furnizorul (provider) de cloud computing este de bună calitate,
1
Scalabilitatea este o proprietate a unui sistem, a unei rețele sau a unui proces, care arată
capacitatea acelui sistem de a suporta corect un volum mai mare de încărcare sau de a permite
mărirea sau extinderea sa (https://ro.wikipedia.org/wiki/Scalabilitate).
2
http://www.agora.ro/stire/oracle-a-lansat-oracle-database-12c-prima-baza-de-date-
conceputa-pentru-cloud
3
https://ro.wikipedia.org/wiki/Cloud_computing
34 Baze de date
atunci utilizatorul e eliberat de sarcina de a fi un expert în tehnologia și infrastructura

folosite. De exemplu, el nu mai trebuie să-și actualizeze software-ul, deoarece aceasta
se face central, la furnizor.
Cloud computing folosește noi metode de oferire și consumare a serviciilor IT în

Internet, servicii care de obicei pot fi dimensionate dinamic și care includ resurse
virtualizate. Este de fapt doar o posibilitate secundară, urmare a ușurinței cu care se pot
acum accesa toate serverele și centrele de calcul interconectate prin intermediul
Internetului.
Furnizorii tipici de cloud computing pun la dispoziție, de exemplu, aplicații comerciale

standard; utilizatorul are acces la acestea doar prin intermediul unui browser local,
deoarece atât aplicația cât și datele proprii ale utilizatorului sunt găzduite în cloud, pe
serverul furnizorului de servicii. În aceste condiții asigurarea confidențialității și
drepturilor de acces la date în contextul Internetului atotprezent joacă un rol primordial.
Deseori furnizorii de clouds prevăd și servicii suplimentare, consolidând toate ofertele

lor, pentru toți clienții lor, într-o singur loc (pagină sau sit web). Ofertele comerciale
trebuie în general să îndeplinească standardele de calitate cerute de clienți, ca de ex.
așa numitele Service Level Agreements (SLA) și altele. Cei mai mari furnizori din acest
domeniu sunt companiile Microsoft, Salesforce, Skytap, HP, IBM, Amazon și Google.
Există două seturi de modele care permit clasificarea serviciilor de tip cloud [GRE15]:
 Modelele de implementare – cu referire la forma de proprietate, localizarea și
modul de gestionare a infrastructurii de tip cloud: public, privat, hibrid etc.;
 Modelele de servicii – cu referire la tipurile de servicii care sunt oferite clienților
prin prin intermediul implementărilor cloud: SaaS, PaaS, IaaS etc.
Modelele de implementare
 Cloud-ul public este bazat pe investițiile unei companii mari de software și
destinat consumatorilor globali indiferent de dimensiune șI domeniu de
activitate;
 Cloud-ul privat este bazat pe investițiile unei companii sau unui grup de companii
verticalizate, destinat în mare parte exclusiv consumatorilor din interiorul
companiei;
 Cloud-ul hibrid este bazat pe folosirea unor servicii oferite de cloud-ul public
interconectate cu entități informaționale interne, destinat în mare parte
companiilor de dimensiuni foarte mari și vizează extinderea anumitor capacități
de procesare internă în scopul satisfacerii cerinţelor consumatorilor din interiorul
companiei.
 Cloud-ul de comunitate – bazat pe partajarea în comun a resurselor unui grup de
organizații din cadrul aceluiași domeniu de activitate economico-socială.
Fig.1.12. Diagrama conceptuală a Cloud Computing

(sursa: https://ro.wikipedia.org/wiki/Cloud_computing, autor Sam Johnston
Modelele de servicii
 SaaS (Software as a Service) reprezintă unul din cele mai utilizate modele de
servicii în cloud prin faptul că permite unui număr mare de utilizatori să
beneficieze în mod gratuit sau plătit de un set de aplicații specifice, standardizate
și necesare în derularea activităților curente. Accesul la aplicații se realizează prin
intermediul browser-elor web sau pentru altele prin intermediul aplicațiilor
client dedicate (ex. Outlook, Skype, DropBox, Google Drive etc.).
 PaaS (Platform as a Service) reprezintă unul din cele mai complexe modele de
servicii cloud pentru că este o suită de aplicații și servicii destinate construirii
altor aplicații și servicii, oferind programatorilor seturi specifice de API-uri
(Application Programming Interface). În acest model de servicii dezvoltatorii nu
au nevoie să își instaleze și configureze propriile servere de prelucrare
(middleware), de persistență (baze de date) sau de prezentare (servere web).
 IaaS (Infrastructure as a Service) reprezintă unul din cele mai noi modele de
servicii în cloud și permite clienților crearea propriilor infrastructuri de
calculatoare, echipamente de rețea și de stocare. Este cunoscut și sub denumirea
de HaaS (Hardware as a Service) pentru că pune la dispoziție posibilitatea de
configurare a echipamentelor prin specificarea numărului de procesoare și a
tipului lor, cantitatea de memorie RAM alocată, dimensiunea spațiului de stocare
și modul de conectare în rețea.
36 Baze de date
Fig.1.13. Modele de servicii în Cloud Computing

(sursa: www.researchgate.net/publication/289952478, autor Greavu-Şerban V.)
Avantaje și dezavantaje [W5]

Avantaje:
 Sincronizarea datelor utilizatorului care folosește mai multe dispozitive legate la
cloud (de ex. un smartphone, o tabletă, un notebook, dar și un PC) este simplificată.
 Documentele online din cloud se pot prelucra cu ajutorul unor aplicații web.
 Viteză de calcul și capacitate de stocare sporite, dar fără investiții în propria
configurație.
 Datele nu pot fi furate, purtătorul de date nu se poate defecta etc.
Dezavantaje:
 E necesară o legătură la Internet rapidă și stabilă.
 Securitatea necesară a datelor din cloud poate prezenta probleme și poate produce
neîncrederea utilizatorilor.
 Situația legală este de obicei complexă, deoarece utilizatorul nu află nici măcar în ce
țară sau în ce țări se află serverele care îi găzduiesc datele sale.
1.8. MODELUL ENTITATE – ASOCIERE (E-A)
În literatura de specialitate se întâlneşte şi denumirea “entitate-relaţie”, dar datorită

confuziilor ce pot apare cu conceptul de relaţie vom folosi denumirea entitate –
asociere.
Modelul Entitate – Asociere (Entity-Relationship Model), introdus în 1976 de Peter Chen,
este un model conceptual care defineşte mulţimile de entităţi şi asocierile (legăturile)
dintre ele.
Definiţia 1.5. Entitatea este “ceva ce poate fi identificat ca distinct”. O entitate se referă
la un aspect al realităţii obiective şi poate reprezenta un obiect fizic, o activitate, un
concept, etc.
Definiţia 1.6. Atributul este o proprietate care descrie un anumit aspect al unei entităţi.
O entitate se diferenţiază de alte entităţi printr-un ansamblu de atribute care permit
descrierea precisă a acesteia. Atributele prin care este descrisă o entitate se aleg astfel
încât să fie relevante relativ la domeniul de interes pentru care se defineşte modelul
respectiv.
Definiţia 1.7. Tip de entitate. Toate entităţile similare, care pot fi descrise prin aceleaşi
atribute, aparţin unui tip de entitate.
Definiţia 1.8. Mulţime de entităţi. Este colecţia tuturor entităţilor de acelaşi tip
În proiectarea bazelor de date există două tipuri de entităţi: entităţi tari (puternice,
normale) şi entităţi slabe (dependente). Entitatea tare are o existenţă proprie în cadrul
modelului, în timp ce entitatea slabă nu poate exista decât dacă există o entitate tare cu
care să fie asociată.
Definiţia 1.9. Asocierea este o corespondenţă (corelaţie, legătură) între entităţi din două
sau mai multe mulţimi de entităţi.
Definiţia 1.10. Gradul unei asocieri este dat de numărul de mulţimi de entităţi asociate.
Vom presupune în continuare, pentru simplitate, că asocierile au gradul 2.
Considerăm două mulţimi de entităţi E1 şi E2. Asocierile de gradul 2 pot fi de trei
categorii:
 asociere 1:1 (one-to-one) – unei entităţi din E1 îi corespunde o singură entitate
din E2 şi reciproc (de exemplu, asocierea de tip soţ – soţie, mai exact căsătoria
monogamă, sau persoana – ROL la administraţia financiară)
38 Baze de date
Persoana
ROL
Fig.1.14. Asociere 1:1 (one-to-one)
 asociere 1:N (one-to-many) – unei entităţi din E1 îi corespund una sau mai
multe entităţi din E2, dar fiecărei entităţi din E2 îi corespunde o singură entitate
din E1 (relaţie de tip tată – fiu, sau grupa – student).
Grupa
Student 1 Student 2 Student n
Fig.1.15. Asociere 1:N (one-to-many)
 asociere M:N (many-to-many) – unei entităţi din E1 îi corespund una sau mai
multe entităţi din E2 şi reciproc (relaţie de tip client – produs, adică un client
poate cumpăra mai multe produse şi un produs poate fi cumpărat de mai mulţi
clienţi)
Produs 1 Produs 2 Produs n
Client 1 Client 2 Client n
Fig.1.16. Asociere M:N (many-to-many)
Diagrama entitate-asociere prezintă modelul entitate-asociere prin mulţimile de entităţi

şi asocierile dintre acestea. În literatura de specialitate se propun mai multe variante de
notaţii pentru diagrama entitate-asociere (Chen, Ross, LBMS, etc.). Una dintre cele mai
folosite este redată în Fig.1.17.
entitate tare
entitate slabă
atribut
asociere 1:N
E1 1 A N E2 între 2 tipuri
de entităţi
Fig.1.17. Reprezentarea diagramei entitate-asociere
Exemplificăm construcţia diagramei entitate-asociere pentru modelarea activităţii

didactice şi de cercetare pe bază de proiecte dintr-o facultate (Fig.1.18.). Este un model
simplificat în care se consideră patru tipuri de entităţi: Facultate, Cadru didactic, Proiect,
Curs.
Asocierea Facultate-Cadru didactic este de tipul 1:N, deoarece într-o facultate sunt mai
multe cadre didactice, iar un cadru didactic aparţine unei singure facultăţi.
Asocierea Cadru didactic-Proiect este de tipul M:N, deoarece la un proiect de cercetare
pe bază de contract lucrează mai multe cadre didactice şi fiecare cadru didactic poate
lucra la mai multe proiecte.
Asocierea Cadru didactic-Curs este de tipul 1:N, deoarece un cadru didactic are în norma
didactică mai multe cursuri şi fiecare curs are un singur cadru didactic titular.
În modelul prezentat, asocierile sunt reprezentate prin verbele: cuprinde, predă,
lucrează:
 facultatea cuprinde mai multe cadre didactice;
 un cadru didactic predă mai multe cursuri;,
 un cadru didactic lucrează la mai multe proiecte de cercetare.
40 Baze de date
nume buget nume salariu
cuprinde
1 N
Facultate Cadru didactic
M
1
predă lucrează
N N
Curs Proiect
denumire program nume buget

studiu
Fig.1.18. Exemplu de diagramă E-A
1.9. BAZĂ DE DATE sau BANCĂ DE DATE ?
Există în literatura de specialitate mai multe abordări ale celor două concepte. Modul lor
de tratare este departe de a fi unitar. În unele lucrări, se consideră că banca de date
este formată din:
 Baza de date,
 Sistemul de gestiune al bazei de date (SGBD).
Alţi autori extind noţiunea de bancă de date şi consideră banca de date formată din :
 Baza de date,
 Sistemul de gestiune al bazei de date (SGBD),
 Hardware – ul necesar funcţionării sistemului,
 Programele de aplicaţii,
 Utilizatorii.
În cartea L’art des bases de données, autorii S.M. Miranda, J.M. Busta fac o distincţie
clară între cele două concepte *MIR88+:
Baza de date conţine date primare care sunt exploatate cu ajutorul unui SGBD. În cazul
unei interogări, sistemul de gestiune al bazei de date furnizează direct răspunsul.
Banca de date date conţine date referenţiale şi accesul este asigurat cu ajutorul unui
sistem documentar (SD). Sistemul documentar permite o direcţionare către un text
(carte, articol, referinţă web,...) şi după consultare se obţine răspunsul la interogarea

formulată.
Exemplul prezentat în lucrarea mai sus citată, [MIR88], clarifică cele două abordări:
Considerăm o colecţie de date care conţine informaţii despre preşedinţii statelor lumii.
Printre atributele care caracterizează tipul de entitate preşedinte avem atributul “stare
de sănătate” , care poate lua mai multe valori, printre care {...., nebun, ...}.
Dacă formulăm interogarea:
“Care a fost starea de sănătate a preşedintelui Wilson (SUA)
între 1914-1918 ?”
Răspunsul dat de banca de date va fi de genul: Istoria contemporană a SUA, pag. 152,
ed. 1980, iar răspunsul efectiv se obţine în urma consultării lucrării indicate.
În cazul unei baze de date răspunsul va fi obţinut direct pe baza unei interogări
(formulată într-un limbaj neprocedural) care va da valoarea atributului “stare de
sănătate” = nebun.
1.10. SCURTĂ ISTORIE A BAZELOR DE DATE
1961 - apariţia sistemului IDS (Integrated Data Storage) al firmei General Electric.
Terminologia utilizată (tipul record şi tipul set) va sta la baza modelului reţea dezvoltat la
"Conference On DAta SYstems and Languages Data Base Task Group" (CODASYL DBTG).
1965-1970 - dezvoltarea sistemelor de gestiune a fişierelor generalizate. IBM dezvoltă
modelul ierarhic şi sistemul IMS (Information Management System). În acceasşi
perioadă apare IMS DB/DC (DataBase/DataCom) care suportă modelul reţea.
În anii 70, domeniul bazelor de date şi sistemelor de gestiune a bazelor de date se
dezvoltă foarte mult, ajungând să fie disciplină universitară şi de cercetare. Apar
numeroase produse comerciale care implementează propunerile raportului CODASYL
DBTG: ISD II (HoneyWell), DMS1100 (UNIVAC), DMS II (Burroughs), etc.
1970 - apare modelul relaţional de date, anunţat de E.F.Codd în articolul A Relational
Model of Data for Large Shared Databanks, publict în CACM, vol. 13, no.6, 1970.
1972 – prima conferinţă internaţională organizată de ACM SIGMOD (Association of
Computing Machinery, Special Interest Group on Management Of Data).
1975 - prima conferinţă internaţională VLDB (Very Large Data Base); publicarea
raportului ANSI-SPARC.
1976 - publicarea modelului Entitate – Asociere de P.P.Chen în articolul The Entity-
Relationship Data Model: Toward a Unified View of Data, apărut în ACM-TODS, vol.1,
no.1, 1976.
1975 - 1980 - dezvoltarea sistemelor relaţionale experimentale: SYSTEM-R (IBM) şi
INGRES (Berkeley, University of California).
1980 - .... apariţia şi comercializarea a numeroase SGBD-uri relaţionale ce au înlocuit
SGBD-urile ierarhice şi reţea. SGBD-urile pot fi utilizate pe microcalculatoare şi se
realizează sisteme din generaţia a patra cu instrumente şi interfeţe multiple.
1990 - .... se dezvoltă numeroase produse a căror complexitate creşte, la un preţ tot mai
scăzut: PowerBuilder (SYSBASE), Oracle Developer, VB (Microsoft), etc. Se dezvoltă
42 Baze de date
modelul client-server, ce se foloseşte în tot mai multe aplicaţii economice. Se dezvoltă şi

produse sotftware ca Exce/, Access (Microsoft) pentru scop personal de o complexitate
mai scăzută.
1990-1995 - apar baze de date pentru Internet. Sunt utilizate conceptele client-server şi
astfel complexitatea Internet-ului creşte exponenţial.
2000 - pentru aplicaţiile pe Internet apar o serie de instrumente cum ar fi Active Server
Pages, Java Servlets, JDBC, Enterprise Java Beans, ColdFusion, Dream Weaver, Oracle
Developer 2000, Apache, MySQL. Se dezvoltă procesarea tranzacţiilor online (OLTP)
precum şi procesarea analitică de tip OLAP.
După 2000 - se dezvoltă aplicaţii pe arhitectura client-server pentru PDA-uri, tranzacţii
cu POS-uri, telefoane mobile. Companiile cele mai reprezentative din domeniu rămân:
IBM, Microsoft şi Oracle.
În ultimii ani – apare un nou concept Sistemele NoSQL. Acest concept este legat de
necesitatea prelucrării unor volume mari de date (Big Data) de ordinul Terra Bytes, care
ridică problema celor 3V (Volumul, Viteza de acces şi Varietatea datelor). Odată cu
dezvoltarea tehnologiilor Cloud Computing, bazele de date de tipul NoSQL devin tot mai
atractive suportului pentru scalabilitate, arhitecturi distribuite şi a serviciilor oferite pe
modelul pay-as-you-go4.
Sistemele NoSQL sunt într-o fază de evoluție naturală, dar sub nici o formă nu înlocuiesc
sistemele mature relaționale, ci le complementează. Inițial, particula “No” se referea la
faptul că limbajul SQL pentru manipularea datelor nu este suportat, dar, în ultima
perioadă, “No” se identifica cu “Not Only”, transmițând ideea că pe alocuri acestea pot fi
manipulate prin interogări de tipul SQL. Dintre cele mai populare soluții NoSQL
enumerăm: Riak, Couchbase, Hypertable şi Cassandra.
Teorema CAP (Consistency, Availability, Partition tolerance), datorată lui Eric Brewer şi
Seth Gibert, formulează constrângerile acestor sisteme de baze de date şi demonstrează
că aceste proprietăţi de consistenţă, disponibilitate şi toleranţă la partiţionare nu pot fi
îndeplinite simultan5.
 Consistenţa se referă la consistenţa datelor din punctul de vedere al clienţilor
sistemului. Altfel spus, toţi clienţii văd aceleaşi date tot timpul.
 Disponibilitatea presupune că fiecare cerere va primi un răspuns.
 Toleranţa la partiţionare este proprietatea sistemului de a funcţiona atunci când
noduri din sistem cad.
Spre exemplu, sistemele care sunt consistente și disponibile nu pot garanta toleranța la
partiționare. Este cazul bazelor de date relaționale, unde datele sunt consistente în
întregul sistem, sunt disponibile tot timpul, dar dacă apare o partiționare, tradusă printr-
o întrerupere a conexiunii între două sau mai multe noduri, funcționarea sistemului ca
ansamblu nu mai este garantată.
4
http://andrei.clubcisco.ro/cursuri/f/f-sym/5master/aac-cc/4_PaaS.pdf
5
http://ctrl-d.ro/tips-and-tricks/introducere-in-tematica-bazelor-de-date-in-cloud/
BAZE DE DATE OLAP. MODELUL MULTIDIMENSIONAL
Sistemele informatice pentru prelucrarea tranzacţiilor (TPS) reprezintă un factor extrem de
important în activitatea unei organizaţii. Bazele de date operaţionale asigură prelucrarea on-line
a tranzacţiilor (on-line transaction processing – OLTP), care presupune toate operaţiile legate de
colectarea, modificarea, trasmiterea şi întreţinerea zilnică a datelor. Aceste baze de date sunt
proiectate pentru optimizarea proceselor curente din organizaţie şi mai puţin pentru analiza
decizională a informaţiilor. În timp, la nivelul unei organizaţii se acumulează un volum
important de date stocate care provin din procesele interne, dar şi din mediul extern. S-au
dezvoltat astfel noi sisteme de aplicaţii de prelucrare analitică on-line (on-line analytical
processing – OLAP) destinate analizei datelor, care reprezintă suportul pentru procesele de
decizie din organizaţie. Din volumele mari de date rezultate din procesele operaţionale,
sistemele OLAP extrag informaţiile necesare procesului decizional.
Aceste sisteme suport pentru decizie, facilitează stocarea şi analiza unor mari volume de date.
Elementul central al unui sistem OLAP este baza sa de date multidimensională (multi-
dimensional database) care conţine informaţii reprezentabile sub forma unui cub de date (data
cube) ce permite analize în mai multe dimensiuni.
Definirea principalelor concepte

Baza de date multidimensională (BDM). Un ansamblu de date constituit prin extracţie sau
transformare de date din bazele de date operaţionale sau externe, variind în timp, organizate
multidimensional şi explorate folosind interogări convenţionale sau tehnici de analiză simplă
(OLAP) sau de analiză avansată (Data Mining) [GBD02].
Termenul de OLAP a fost introdus de Codd în anul 1993 şi este definit în *CON01+: Sinteza,
analiza şi consolidarea dinamică a unor volume vaste de date multidimensionale.
În 1995, Consiliul OLAP defineşte conceptul OLAP: O categorie de instrumente software care
permite analiştilor şi managerilor să înţeleagă esenţa datelor printr-un acces rapid, consistent şi
interactiv la o mare varietate de viziuni posibile ale informaţiilor, care au fost obţinute prin
transformarea datelor primare astfel încât să reflecte dimensiunile reale ale organizaţiei aşa
cum o percepe şi înţelege utilizatorul [SAB08].
Depozit de date (Data Warehouse). Definiţia lui W. H. Inmon, considerat părintele conceptului,
este: Un depozit de date este o colecţie de date orientate pe subiecte, integrate, istorice şi
nevolatile, fiind destinată fundamentării deciziei manageriale [SAB08].
Mineritul datelor (Data Mining) desemnează tehnici de căutare avansată a informaţiilor ascunse
în datele dintr-un depozit de date [GBD02].
Un sistem OLAP efectuează analize complexe asupra unor mari volume de date stocate în
depozite de date. Aceste analize sunt multidimensionale deoarece studiază un fapt (de
exemplu, vânzările) în funcţie de dimensiuni (de exemplu oraş, produs, timp).
1
Tehnologiile de tip OLAP permit analiștilor și managerilor din organizații să aibă un acces rapid
și interactiv la depozitul de date. Aceste tehnologii de centralizare au scopul de a transforma
informațiile obișnuite în informații de sinteză putându-se face apoi o analiză mai ușoară.
Funcționalitatea OLAP este caracterizată de o analiză dinamică multidimensională a datelor
consolidate din organizație, ce sprijină activitățile analitice și de căutare și regăsire a
informațiilor desfășurate de utilizatorul final:
 Calcule și modele ce se aplică dimensiunilor transversale prin intermediul ierarhiilor sau
membrilor;
 Analiza tendințelor;
 Analiza unor submulțimi obținute prin secționare;
 Analiza unor date prin adâncirea nivelurilor de consolidare a datelor;
 Analiza bazată pe comparații dimensionale.
O analiză comparativă între sistemele de prelucrare OLTP şi OLAP este prezentată în figura 6.8.
Caracteristici OLTP OLAP

Volumul de date Mic Important (poate ajunge la
miliarde de articole)
Cererile Simple, predefinite şi Complexe, ad-hoc,
repetitive “one use”
Frecvenţa cererilor Mare Mică (rară)
Utilizatorii Agenţi operaţionali Analişti / decidenţi
(numeroşi) (mai puţin numeroşi)
Granularitatea (nivelul de Date detaliate Date agregate pe
detaliere a datelor) mai multe niveluri
Accesul Citire/scriere date curente Citire date istorice
Scopul Depinde de aplicaţie Luarea deciziilor
Figura 6.8. Comparaţie OLTP - OLAP
Depozitul de date (Data Warehouse) conține atât date istorice cât și actuale. Datele sunt
ierarhizate şi structurate pentru a putea fi oricând disponibile activităților de prelucrare
analitică on-line, mineritului de date, interogărilor, rapoartelor sau altor aplicații destinate luării
deciziilor.
Noțiunea de depozitare a datelor vizează întregul proces de creare, menținere și exploatare a
unui depozit de date. Alimentarea cu date a depozitului de date se realizează în principal din
bazele de date operaţionale ale organizaţiei cu ajutorul unor instrumente de manipulare a
datelor numite E.T.L. (Extract Transform and Load) care permit:
 extragerea datelor sursă din bazele de date operaţionale;
 structurarea şi transformarea datelor pentru omogenizare prin aplicarea unor reguli de
gestiune bine precizate;
 încărcarea datelor sursă în depozitul de date.
2
Datele, plecând de la bazele sursă, tranzitează către un ODS (Operational Data Store), apoi
către DWH (Data Warehouse) şi în final către magazinele de date (DataMarts)1.
Datele din ODS (Operational Data Store) sunt o simplă copie a datelor din bazele de date
operaţionale OLTP.
Datele din magazinele de date (DataMarts) constituie subansamble din depozitele de date care
oferă o vedere funcţională limitată la un domeniu al organizaţiei, de exemplu informaţii strict
legate de vânzări.
Principalele caracteristici ale datelor dintr-un depozit de date (Data Warehouse) sunt:
 Datele sunt orientate subiect.
 Datele sunt integrate prin definirea unui referenţial unic; de exemplu, sumele încasate
din activităţi de export în diferite valute sunt transformate într-o monedă unică.
GBP
CHF EUR
USD
Figura 6.9. Exemplu de integrare a datelor
 Datele nu sunt volatile, ceea ce permite trasabilitatea datelor şi a deciziilor luate.
încărcare acces
Figura 6.10. Non-volatilitatea datelor
 Datele sunt istorice şi persistente în timp.

 Inconvenient: datorită volumului foarte mare de date, depozitul de date în ansamblul
său nu poate fi utilizat direct de decidenţi, deoarece conţine mai mult decât este
necesar pentru o clasă de decidenţi. Pentru a răspunde nevoilor unui anumit sector sau
unei funcţii organizaţionale se pot crea subansamble (datamarts) ale unui depozit de
date (figura 6.11).
1
http://www.expert-only.com/business-intelligence/concepts/entrepots-de-donnees-ou-
datawarehouses-dwh
3
DataMarts
Compartimentul MK
DataMart
Compartimentul RU
Depozit de date
Figura 6.11. Datamarts pentru compartimentele organizaţiei
Cu aceste elemente, procesul de luare a deciziilor poate fi prezentat ca în figura 6.12.
Decizia
Baze de Depozit Baze de date Analize, simulări,

date de date multidimensionale previziuni
OLTP
Figura 6.12. Procesul de luare a deciziilor
Modelarea multidimensională
Modelarea multidimensională este o tehnică de proiectare logică folosită pentru vizualizarea
modelelor de date sub forma unui set de variabile cheie pentru activitatea analizată. Aceste
variabile sunt descrise în funcţie de aspectele caracteristice ale activităţii (proces/procese)
analizate [VEL01].
Elementele unui model multidimensional sunt [SAB08], [VEL01] :

 Cubul n-dimensional (hypercubul). La nivel conceptual, datele sunt văzute sub formă de
puncte într-un spaţiu cu mai multe dimensiuni. Fiecare dată reprezintă o celulă a cubului.
Marginile cubului reprezintă axele de analiză a datelor şi au mai multe gradaţii pentru a
permite observarea datelor potrivit diferitelor niveluri de detaliere.
 Dimensiunile sunt reprezentate prin axele cubului. Dimensiunile furnizează informaţii despre
fiecare măsură (variabilă). Dimensiunile conţin în general date statice. La nivelul fiecărei
dimensiuni există mai multe atribute (membrii). Un număr mare de atribute dimensionale va
4
permite analize mai complexe şi mai variate. Granularitatea cubului este dată de
granularitatea dimensiunilor, adică de gradul de detaliere al datelor stocate. Evident, un grad
mare de detaliere a datelor conduce la creşterea volumului depozitului de date.
În procesul de analiză, la nivelul cubului n-dimensional, se poate realiza:
- o dezagregare a datelor prin introducerea unei noi dimensiuni în analiză (operaţia drill-
down);
- o reagregare a datelor prin eliminarea unei dimensiuni în analiză (operaţia roll-up).
 Ierarhiile permit aranjarea atributelor (membrilor) unei dimensiuni pe mai multe niveluri în
structuri arborescente. De exemplu, în majoritatea analizelor economice o dimensiune
importantă o reprezintă timpul. Pentru dimensiunea timp membrii naturali sunt: anul,
semestrul, trimestrul, luna, săptămâna, ziua. O ierarhie posibilă este prezentată în figura 6.13.
An
Sem. 1 Sem. 2
Trim. 1 Trim. 2 Trim. 3 Trim. 4
L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 L11 L12
Figura 6.13. Ierahia pe 4 niveluri pentru dimensiunea Timp
 Gradul de împrăştiere al datelor este dat de numărul de celule ale cubului pentru care nu
avem date şi de modul de poziţionare al celulelor care conţin date.
 Măsurile (variabilele) sunt atribute numerice ale elementelor din colecţia de fapte şi
reprezintă indicatorii prin care se măsoară performanţele procesului analizat. De exemplu,
într-o analiză a vânzărilor înregistrate într-o reţea de magazine, indicatorii analizaţi sunt:
volumul vînzărilor şi cantitatea vândută.
 Colecţia de fapte este un ansamblu format din variabile şi din date de context. Un fapt poate
fi:
- un eveniment (de exemplu o vânzare: ce a fost cumpărat, unde, când, cine a
cumpărat, care a fost preţul),
- starea unui obiect (de exemplu starea stocului: ce este stocat, de când este stocat,
unde este stocat, ce cantitate este stocată),
- modificarea stării unui obiect (de exemplu modificările stocului: cantităţi intrate,
cantităţi ieşite).
Colecţiile de fapte asociate evenimentelor se numesc colecţii de fapte fără fapte şi sunt de
fapt colecţii de fapte fără variabile (măsuri).
Exemplu de cub de date

În figura 6.14 se prezintă un exemplu de cub de date care permite analiza publicaţiilor ştiinţifice
realizate de cadre didactice de la toate universităţile din ţară ţară. Cubul are trei dimensiuni:
Autori, Manifestări, Timp şi conţine în celule numărul de publicaţii.
5
Autori
Timp
Manifestări
Figura 6.14. Exemplu de cub de date
Fapta Publicaţii este compusă din măsura (variabila) Numărul_de_publicaţii.

Axele de analiză sunt reprezentate de cele trei dimensiuni, fiecare având atribute aranjate în
ierarhii:
 dimensiunea Autori are următoarea ierarhie:
Universitate
Facultate ... Facultate
Departament ... Departament ... ... ... Departament ... ...
 dimensiunea Manifestări are următoarea ierarhie:
Reviste Conferinţe
Reviste ISI Reviste BDI Internaţionale Naţionale
 dimensiunea Timp are următoarea ierarhie:
Anul
Semestrul I (lunile 1-6) Semestrul II (lunile 7-12)
Notă. Au fost precizate lunile pentru a nu se confunda cu semestrele universitare.
6
CAPITOLUL 2
BAZE DE DATE RELAŢIONALE
2.1. CONCEPTE GENERALE
Modelul relaţional al datelor propus de E. F. Codd, a fost perfecţionat în anii următori

printr-un număr mare de rezultate teoretice şi practice de C. J. Date, R. Boyce, R. Fagin,
W. W. Armstrong şi alţii. Modelul are ca obiectiv esenţial creşterea independenţei
programelor în raport cu reprezentarea datelor.
Caracteristicile modelului relaţional:

 datele sunt percepute de utilizatori ca tabele;
 simplitate şi precizie în definirea elementelor de bază (relaţii, atribute, domenii);
 operatorii relaţionali generează un tabel rezultat din tabelele operanzi;
 restricţiile de integritate, normalizarea relaţiilor, controlul concurenţei permit
crearea structurii datelor şi a prelucrării lor într-un mod consistent şi asigură
integritatea şi protecţia acestora.
În Tabelul 2.1. sunt prezentate elementele ce caracterizează modelul relaţional şi

corespondenţa lor în conceptele de bază ale ingineriei software.
Tabelul 2.1.
Modelul relaţional Inginerie software
structura relaţională a datelor informaţie
operatorii modelului relaţional proces
restricţiile de integritate integritate
Pentru claritatea expunerii prezentăm în Tabelul 2.2. corespondenţele formal - uzual -

fizic dintre diferitele concepte utilizate pentru a descrie elementele de bază ale
organizării datelor în modelul relaţional.
Tabelul 2.2
Formal Uzual Fizic
relaţie tabel fişier
tuplu linie articol
atribut coloană câmp
domeniu tip de dată tip de dată
Definiţia 2.1. BAZA DE DATE RELAŢIONALĂ este un ansamblu organizat de tabele

(relaţii), variabile în timp, împreună cu legăturile dintre ele. Fiecare tabel (relaţie)
reprezintă un tip de entitate sau o asociere dintre două sau mai multe tipuri de entităţi.
44 Baze de date
E. F. Codd formulează, în anul 1985, 13 reguli pentru evaluarea performanţelor unui

sistem de gestiune a bazelor de date relaţionale (SGBDR) [POI01]. Aceste reguli exprimă
cerinţele maximale ca un SGBDR să fie relaţional. Se apreciază că niciun sistem de
gestiune a bazelor de date pus în vânzare pe piaţa comercială nu respectă absolut toate
regulile definite de Codd, dar acest lucru nu împiedică etichetarea acestor sisteme drept
relaţionale. Nu trebuie apreciat un SGBD ca fiind relaţional sau nu, ci măsura în care
acesta este relaţional, în funcţie de numărul regulilor lui Codd pe care le respectă
[POI01].
R1. Regula gestionării datelor. Un SGBD relaţional trebuie să fie capabil să gestioneze o
bază de date numai prin posibilităţile sale relaţionale.
Practic, se apreciază că nicio implementare actuală de SGBDR nu respectă această
regulă, deoarece implementările conţin atât caracteristici relaţionale cât şi caracteristici
nerelaţionale.
R2. Regula reprezentării informaţiei. Într-o bază de date relaţională, informaţia este
reprezentată la nivel logic sub forma unor tabele ce poartă numele de relaţii.
Codd apreciază această regulă ca fiind cea mai importantă. Un SGBD care nu respectă
acestă regulă nu poate fi considerat relaţional.
R3. Regula accesului garantat la date. Fiecare valoare dintr-o bază de date relaţională
trebuie să poată fi adresată în mod logic printr-o combinaţie formată din numele relaţiei,
valoarea cheii primare şi numele atributului.
Limbajul de manipulare a datelor (DML) trebuie să permită accesul la orice valoare
atomică din baza de date relaţională.
R4. Regula reprezentării informaţiei necunoscute. Un sistem relaţional trebuie să
permită utilizatorului definirea unui tip de date numit NULL pentru reprezentarea unei
informaţii necunoscute la momentul respectiv.
Într-un SGBDR trebuie făcută diferenţa la nivelul unui atribut între valoarea zero, un şir
vid de caractere (şir de spaţii) şi o valoare necunoscută la un moment dat (valoarea
NULL).
R5. Regula dicţionarelor de date. Asupra descrierii bazelor de date (informaţii relative la
relaţii, vizualizări, indecşi etc.) trebuie să se poată aplica aceleaşi operaţii ca şi asupra
datelor din baza de date.
Descrierea bazei de date este reprezentată la nivel logic sub forma unor tabele care pot
fi accesate în acelaşi mod ca şi datele efective.
R6. Regula limbajului de interogare. Trebuie să existe cel puţin un limbaj pentru
prelucrarea bazei de date.
Toate implementările SQL respectă această regulă. Limbajul permite utilizatorilor să
definească relaţii şi vizualizări, să regăsească informaţia şi să o actualizeze.
R7. Regula de actualizare a vizualizării. Un SGBD trebuie să poată determina dacă o
vizualizare poate fi actualizată şi să stocheze rezultatul interogării într-un dicţionar de
tipul unui catalog de sistem.
Implementările SQL pot stabili, în funcţie de parametrii de selecţie utilizaţi, dacă
anumite vizualizări pot fi actualizate sau nu.
Baze de date relaţionale 45
R8. Regula limbajului de nivel înalt. Regulile de manipulare asupra unei relaţii luată ca
întreg sunt valabile atât pentru operaţiile de regăsire a datelor, cât şi asupra operaţiilor
de inserare, actualizare şi ştergere a datelor.
Într-un SGBDR operaţiile de manipulare a datelor pot fi aplicate atât în mod interactiv,
cât şi prin program, într-un limbaj gazdă.
R9. Regula independenţei fizice a datelor. Programele de aplicaţie şi activităţile
utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date.
Într-un SGBDR schimbarea structurii fizice a datelor (stocare sau acces la date) nu
trebuie să afecteze programele.
R10. Regula independenţei logice a datelor. Programele de aplicaţie trebuie să fie
transparente la modificările de orice tip efectuate asupra datelor.
Modificările efectuate asupra unei relaţii, nu trebuie să afecteze operaţiile de
manipulare a datelor.
R11. Regula independenţei datelor din punct de vedere al integrităţii. Regulile de
integritate trebuie să fie definite într-un sublimbaj relaţional, nu în programul de
aplicaţie. Restricţiile de integritate trebuie să fie definite prin limbajul de definire a
datelor (DDL) şi stocate în catalogul sistemului.
R12. Regula independenţei datelor din punct de vedere al distribuirii. Distribuirea
datelor pe mai multe calculatoare dintr-o reţea de comunicaţii de date, nu trebuie să
afecteze programele de aplicaţie.
Standardul ANSI-SQL nu menţionează această regulă în specificaţiile sale, deoarece este
greu de respectat.
R13. Regula versiunii procedurale a unui SGBD. Orice componentă procedurală a unui
SGBD trebuie să respecte aceleaşi restricţii de integritate ca şi componenta relaţională.
Nu se permite ca printr-o metodă procedurală (de exemplu, un limbaj de nivel inferior)
să se distrugă regulile de integritate exprimate într-un limbaj relaţional. De exemplu,
dacă într-o relaţie valoarea unui atribut este not null, orice altă metodă procedurală de
accesare nu trebuie să permită introducerea unei valori null în această coloană.
Deoarece cele 13 reguli ale lui Codd sunt dificil de respectat s-au definit condiţii
minimale pentru ca un SGBD să fie relaţional. Acestea sunt:
 să implementeze modelul de date relaţional prin DDL (Data Definition Language)
şi DML (Data Manipulation Language);
 să implementeze un limbaj de interogare relaţional.
Sistemul de gestiune a bazelor de date relaţionale a devenit elementul software

dominant utilizat azi în prelucrarea datelor, cu o cifră a vânzărilor (estimată la începutul
anilor 2000), aproximativ între 8 şi 10 miliarde de dolari şi cu o rată de creştere de 25%
pe an [CON01].
În Fig. 2.1. se prezintă arhitectura funcţională a unui sistem de gestiune a bazelor de

date relaţional.
46 Baze de date
Interfaţa utilizatorului
Gestiunea vederilor
R
E
Z Integritatea semantică
U Control
L Autorizarea accesului
T
A
T Optimizarea cererilor
E
Gestiunea planurilor
de execuţie
Tratarea
cererilor
Controlul execuţiei
Executarea
operatorilor algebrici
Gestiune buffer
Gestiunea
Mecanisme de acces accesului
Gestiunea accesului
concurent Securitate
Jurnalizarea
Fig. 2.1. Arhitectura funcţională a unui SGBD relaţional
Definiţia 2.2. Domeniul este un ansamblu de valori atomice de acelaşi tip, având o
anumită semnificaţie. Domeniul poate fi definit explicit prin enumerarea tuturor
valorilor sau implicit prin precizarea proprietăţilor pe care le au valorile domeniului
respectiv.
Exemple:
D1 = {“MK”, “ECTS”, “FB”, “CIG”, “IE”, “MN” }
D2  x | x  N , x 0 ,100 
D3 = {0, 5, 9, 20}
 domeniul D1 este definit explicit prin enumerarea programelor de studii care au în
plan disciplina Baze de date;
 domeniul D2 este definit implicit prin specificarea proprietăţilor care pot fi luate de
valorile domeniului;
 domeniul D3 este definit explicit prin enumerarea valorilor posibile (în procente) ale
cotelor de TVA (în momentul decembrie 2016).
D1  D2  ...  Dn  V1 ,V2 ,...,Vn , unde V1 D1 ,...,Vn Dn 

Fiecărui domeniu i se asociază un atribut Ai : f : Ai  Di , f Ai  Di .
Definiţia 2.3. Relaţia este o mulţime de tupluri ce aparţine produsului cartezian

D1  D2  ... Dn , astfel spus R  D1  D2  ... Dn .
În modelul relaţional, relaţiile sunt utilizate pentru a păstra informaţii despre obiectele
care vor fi reprezentate în baza de date. Liniile tabelului corespund înregistrărilor
individuale, iar coloanele corespund atributelor. Atributele pot apărea în orice ordine,
relaţia rămânând neschimbată, adică păstrând acelaşi înţeles.
Relaţia se poate memora într-un tabel bidimensional:

R A1 A2 ..... An
t1 a11 a12 a1n
t2 a21 a22 a2n
... ... ... ...
tm am1 am2 ..... amn
Liniile tabelului formează elementele relaţiei numite şi tupluri. Pentru elementul t i ,

ai 1 , ai 2 , ..., ain reprezintă valorile pe care le iau atributele corespunzătoare A1 , A2 ,..., An .
Notăm: tuplul i prin t i  ai 1 , ai 2 ,..., ain  .
O valoare aparte a unui atribut este valoarea Null.
Null reprezintă valoarea unui atribut care este necunoscută. Poate însemna că o valoare
nu este aplicabilă unui anumit tuplu sau că deocamdată nu s-a atribuit nicio valoare.
Null nu este acelaşi lucru cu o valoare numerică egală cu zero sau cu un şir de caractere
(text) completat cu spaţii, deoarece zero şi spaţiile sunt valori, pe când un null semnifică
absenţa unei valori. Null-urile crează probleme de implementare, deoarece modelul
relaţional se bazează pe calculul predicatelor de ordinul întâi, care reprezintă o logică
bivalentă, unde singurele valori admise sunt adevăr sau fals. Introducerea null-urilor
înseamnă că trebuie să lucrăm cu o logică trivalentă în care avem adevăr (true), fals
(false) şi necunoscut (unknown). Codd tratează valorile Null ca parte integrantă a
48 Baze de date
modelului relaţional, acest lucru fiind precizat cu claritate în regula R4. (Regula
reprezentării informaţiei necunoscute) [CON01].
Tabelele de adevăr în logica trivalentă (în care avem valorile True, False, Null) ale
operatorilor logici NOT, OR şi AND sunt:
NOT OR T F Null AND T F Null

T F T T T T T T F Null
F T F T F Null F F F F
Null Null Null T Null Null Null Null F Null
Definiţia 2.4. Schema relaţiei (schema relaţională) este un element invariant în timp şi
reprezintă mulţimea numelor atributelor corespunzătoare unei relaţii. Pentru fiecare
atribut se precizează domeniul asociat.
Notăm schema unei relaţii cu: R A1 : D1 , A2 : D2 ,..., An : Dn 

sau pe scurt: R A1 , A2 ,..., An .
Definiţia 2.5. Schema bazei de date relaţionale este formată de mulţimea tuturor
schemelor relaţionale corespunzătoare unei aplicaţii, iar conţinutul curent al relaţiilor la
un moment dat se numeşte bază de date relaţională.
Definiţia 2.6. Cardinalul unei relaţii reprezintă numărul de tupluri din relaţie.
Definiţia 2.7. Gradul unei relaţii (aritatea relaţiei) este numărul de atribute din relaţie.
Definiţia 2.8. Relaţia virtuală (relaţie derivată, viziune) este o relaţie definită implicit pe
baza altor relaţii, prin intermediul unei expresii relaţionale. Stabilirea efectivă a
tuplurilor care compun relaţia virtuală se realizează prin evaluarea expresiei relaţionale
în momentul în care utilizatorul apelează la această relaţie.
Definiţia 2.9. Două relaţii sunt compatibile cu reuniunea dacă au acelaşi grad (aritate) şi
atributele corespondente iau valori pe aceleaşi domenii.
Relaţia se prezintă ca o mulţime de tupluri. Logic, această mulţime nu poate conţine

elemente identice, cu alte cuvinte, relaţia nu poate avea tupluri duplicate. Necesitatea
identificării unui tuplu a condus la noţiunea de cheie.
Definiţia 2.10. Cheia unei relaţii reprezintă ansamblul minimal de atribute cu rol de
identificare unică a tuplurilor dintr-o relaţie. Într-o relaţie pot exista mai multe atribute /
combinaţii de atribute cu rol de identificare unică a tuplurilor, există deci mai multe chei
candidate. Dintre aceste chei candidate se alege cheia primară, celelalte devin chei
secundare sau alternante. Orice relaţie are cel puţin o cheie.
Orice cheie candidat K, pentru o relaţie R are două proprietăţi:

 unicitate – în fiecare tuplu al relaţiei R, valorile cheii K identifică în mod unic acel
tuplu;
 ireductibilitate – nu există submulţimi a cheii K care să aibă proprietatea de uni-
citate.
Identificarea unei chei candidat necesită cunoaşterea înţelesului din lumea reală a
atributului sau atributelor implicate, astfel încât să se poată stabili dacă sunt posibile
duplicate. Numai prin utilizarea acestor informaţii semantice, putem fi siguri că o
combinaţie de atribute constituie o cheie candidat.
Definiţia 2.11. Cheia simplă este cheia formată dintr-un singur atribut, iar cheia compusă
este formată din mai multe atribute.
Definiţia 2.12. Supercheia unei relaţii este o submulţime de atribute cu rol de

identificare unică a tuplurilor dintr-o relaţie. Orice relaţie are cel puţin o supercheie:
mulţimea tuturor atributelor din relaţie.
Observaţie. Conform Definiţiei 2.10 o cheie este o supercheie ireductibilă.
Definiţia 2.13. Domeniul primar este domeniul pe care este definită cheia primară.
Definiţia 2.14. Cheia externă este un atribut/grup de atribute dintr-o relaţie, ale
cărui/căror valori sunt definite pe domeniul primar al altei relaţii.
Definiţia 2.15. Relaţia primară. O relaţie RP este primară, dacă există o altă relaţie R,
legată semantic de ea, care are drept cheie externă, cheia primară a relaţiei considerate
(RP).
Exemple
1. Fie relaţia STUDENT [ NrMatricol, Nume, Facultate, Grupa, Sectia, CNP, Adresa]
Atributele NrMatricol şi CNP au rol de identificare unică a tuplurilor din relaţie;
reprezintă chei candidate. Alegem drept cheie primară atributul NrMatricol, care are
domeniul format din 4 caractere numerice şi este mai uşor de operat. Atributul CNP,
format din 13 caractere numerice devine cheie secundară (alternantă).
Atributele (NrMatricol, Nume) formează o supercheie - are rol de identificare unică a
tuplurilor din relaţie, dar nu este ireductibilă, deoarece atributul NrMatricol, singur,
realizează identificarea unică a tuplurilor.
La limită, se poate considera o supercheie şi mulţimea tuturor atributelor din relaţie:
(NrMatricol, Nume, Facultate, Grupa, Sectia, CNP, Adresa).
2. Se consideră relaţiile (tabelele):

PRODUSE [ IDprodus, Denumire, UM]
CONTRACTE [ NrContract, IDprodus, IDclient, Data, Cantitate, PretUnitar]
CLIENTI [ IDclient, Nume, CIF, Adresa, Cont, Tel, Email]
50 Baze de date
 relaţia PRODUSE are cheia primară - IDprodus;

 relaţia CONTRACTE are cheia primară - NrContract, iar atributele IDprodus şi
IDclient sunt chei externe ;
 relaţia CLIENTI are cheia primară - IDclient, iar atributul CIF (cod de înregistrare
fiscală) este cheie secundară;
 PRODUSE şi CLIENTI sunt relaţii primare.
Pentru acest exemplu prezentăm în schema legăturilor dintre tabelele bazei de date:
PRODUSE
CONTRACT
# IDprodus
# NrContract Denumire
• IDprodus UM
• IDclient
Data
Cantitate CLIENTI
PretUnitar
# IDclient
Nume
CIF
Adresa
Cont
Tel
Email
Fig.2.2. Schema legăturilor dintre relaţiile (tabelele) din exemplul 2.
2.2. RESTRICŢIILE DE INTEGRITATE ŞI SECURITATEA DATELOR
Informaţiile stocate în baza de date trebuie să fie coerente, adică să corespundă

realităţii. Restricţiile de integritate minimale sunt reguli pe care trebuie să le satisfacă
datele din baza de date.
A. Integritatea domeniului – constă din controlul sintactic şi semantic al unei date

oarecare şi se referă la definiţia tipului domeniului. În cazul unui domeniu definit
explicit prin enumerarea valorilor, trebuie să ne asigurăm că valorile atributului
respectiv fac parte din mulţimea enumerată. De exemplu, valorile atributului
program de studiu pentru o facultate economică pot fi enumerate:“MK”, “ECTS”,
“MN”, “FB”, “CIG”, “IE”, “AI”, “BA”. Sau, în cazul unui domeniu definit implicit, se
poate verifica, de exemplu, dacă numărul unei facturi aparţine unui interval dat.
Dintre restricţiile de integritate ale domeniului amintim [ION04], [RIO05]:

 Restricţia NOT NULL. Valoarea NULL pentru un atribut arată că ea nu este
cunoscută la un moment dat. De exemplu, în tabela cu candidaţii la admitere
valorile pentru atributul Nota_proba_scrisă sunt necunoscute în momentul
înscrierii la facultate, acestea urmând a fi completate ulterior după corectarea
probei scrise. O altă situaţie poate apare în cazul unei baze de date ALUMNI1.
De exemplu, dacă valoarea atributului telefon, nu este cunoscută pentru unii
absolvenţi, aceasta nu va împiedica definirea atributului, care pentru
majoritatea absolvenţilor va avea valori cunoscute.
Restricţia NOT NULL impusă unui atribut la crearea tabelei înseamnă că
atributul nu poate lua valoare NULL pentru nicio linie din tabelă.
 Valori implicite ale atributelor. Dacă la inserarea unei linii nu se specifică
valoarea unui atribut, atunci atributul primeşte valoarea implicită (dacă a fost
definită) sau valoarea NULL (dacă nu a fost definită o valoare implicită pentru
atributul respectiv, dar sunt admise valori NULL). De exemplu, la formularul
online de înscriere la facultate, atributul cetăţenie are valoarea implicită
română, valoare care poate fi evident modificată în alte situaţii. Dacă nu a fost
definită o valoare implicită şi nici nu este admisă valoare NULL, atunci se
generează un mesaj de eroare. Este situaţia întâlnită la completarea unor
formulare online în care apar câmpuri obligatorii de completat.
 Restricţia de verificare. La completarea valorii unui atribut se admit numai
valorile pentru care condiţia de verificare ia valoarea TRUE. În SQL se realizează
la definirea tabelei prin clauza CONSTRAINT… CHECK….
B. Integritatea entităţii – se referă la restricţii asupra cheii primare. Aceasta trebuie

să fie unică şi nenulă (atributele cheii primare trebuie să fie diferite de valoarea
null).
O cheie primară formată din atributele existente ale tipului de entitate se
numeşte cheie naturală. În general, aceste chei sunt chei compuse şi scad
eficienţa operaţiilor de manipulare a tabelelor bazei de date. În practică se
folosesc de multe ori chei artificiale, de exemplu: IDcontract, IDprodus, sub
forma de numere de identificare. Acestea sunt atribute care se adaugă în schema
relaţiei cu rol de identificare unică a tuplurilor (liniilor) din relaţie (tabelă).
În SQL restricţiile de cheie primară (PRIMARY KEY) şi cheie secundară (UNIQUE)
se introduc la definirea relaţiei (tabelei).
C. Integritatea referirii – impune ca valorile cheii externe să figureze printre valorile

cheii primare din relaţia referită (relaţia primară).
Tuplurile care conţin chei externe care nu au corespondent printre cheile
primare din relaţia referită se numesc entităţi orfane [RIO05]. Există patru căi
prin care pot apărea entităţile orfane:
1
Alumnus (elev în limba latină, alumni la plural) este un fost elev sau student al unei instituţii de
învăţământ.
52 Baze de date
 Un tuplu este adăugat cu o cheie externă care nu are corespondent în relaţia

referită.
 O valoare a cheii externe se schimbă cu o valoare care nu este în relaţia
referită.
 Se schimbă cheia primară din relaţia referită.
 Un tuplu referit din relaţia primară (referită) este şters.
Evident, apariţia entităţilor orfane trebuie evitată în operaţiile de manipulare a
datelor din baza de date.
În SQL, integritatea referirii se realizează la crearea relaţiei printr-o restricţie
(CONSTRAINT) în care se specifică cheia externă (FOREIGN KEY) şi cheia primară
din relaţia referită (REFERENCES).
Problema securităţii datelor presupune [GBD02]:

 Asigurarea integrităţii semantice care a fost parţial abordată în cadrul restricţiei
de integritate a domeniului.
 Asigurarea sincronizării accesului concurent la baza de date, presupune că
acţiunile concurente ale utilizatorilor nu aduc prejudicii altor utilizatori.
 Asigurarea siguranţei în funcţionare, adică în urma unei defecţiuni fizice (cădere
de curent, ...) baza de date rămâne în stare coerentă.
 Asigurarea securităţii în utilizare presupune că baza de date este manipulată de
utilizatori care au drepturi de acces.
Starea de coerenţă a bazei de date relaţionale poate fi asigurată prin utilizarea

tranzacţiilor. Proprietatea de atomicitate a tranzacţiei, prezentată în §1.3., presupune
ca setul de operaţii pe care îl reprezintă tranzacţia să fie executat în întregime sau deloc.
Operaţiile cuprinse într-o tranzacţie nu pot fi executate parţial – dacă una din ele
eşuează celelalte sunt anulate. De exemplu, transferul unei sume de bani din contul A în
contul B, presupune două actualizări: retragerea sumei din contul A şi depozitarea în
contul B. Cele două actualizări făcând parte din aceeaşi tranzacţie, sistemul garantează
efectiv fie că ambele sunt efectuate, fie că nu este efectuată nici una, chiar dacă
sistemul cade la jumătatea procesului [DAT05].
Astfel, o tranzacţie poate fi [GBD02]:

 salvată (commited) – toate operaţiile tranzacţiei au fost încheiate cu succes, iar
baza de date este actualizată cu noile modificări;
 derulată înapoi (rollback) – toate operaţiile din respectiva tranzacţie sunt
anulate, iar baza de date este restaurată la starea dinaintea tranzacţiei.
Acest mod de lucru asigură starea de coerenţă a bazei de date şi este foarte importantă
în sistemele multiutilizator, în care datele actualizate printr-o tranzacţie nu sunt vizible
altor utilizatori decât numai la salvarea tranzacţiei.
CAPITOLUL 3
ALGEBRA RELAŢIONALĂ
3.1. INTRODUCERE
Interogarea (query) este operaţia prin care se obţin datele dorite dintr-o bază de date,
selectate conform unor criterii. Deoarece aceasta este cea mai importantă operaţie,
limbajele de manipulare a datelor sunt denumite şi limbaje de interogare.
Pentru formularea conceptuală a interogărilor în bazele de date relaţionale s-au

dezvoltat două limbaje abstracte de interogare: algebra relaţională şi calculul relaţional.
Algebra relaţională (relational algebra), introdusă de Codd în 1970, defineşte cadrul

formal al limbajelor relaţionale pentru baze de date. Algebra relaţională introduce o
colecţie de operatori algebrici care se aplică relaţiilor (tabelelor). Fiecare operaţie din
algebra relaţională are drept operanzi una sau mai multe relaţii, iar rezultatul este tot o
relaţie. Această uniformitate (proprietatea algebrică de închidere) permite aplicarea de
combinaţii de operatori relaţiilor.
Prin analogie, cu un compilator care plecând de la un program sursă produce un

program executabil, rezultatul compilării unei interogări (cereri) de către un SGBD
relaţional este o expresie algebrică care va fi evaluată. În cadrul modelului relaţional se
consideră limbaje relaţionale complete numai acele limbaje de interogare care permit
implementarea tuturor operaţiilor prevăzute de unul din limbajele abstracte de
interogare. Limbajele de interogare reale implementate în sistemele de baze de date
relaţionale sunt limbaje definite pe baza limbajelor abstracte de interogare.
Cunoaşterea limbajului abstract de interogare bazat pe algebra relaţională este

obligatorie pentru înţelegerea aprofundată a modului de execuţie a interogărilor.
Algebra relaţională conţine două tipuri de operaţii:

 operaţii pe mulţimi: reuniunea, intersecţia, diferenţa şi produsul cartezian.
Pentru a determina reuniunea, intersecţia şi diferenţa a două relaţii, acestea
trebuie să fie compatibile cu reuniunea, adică trebuie să aibă acelaşi număr de
atribute (acelaşi grad) şi atributele corespondente să fie definite pe domenii
compatibile (formatul datelor să fie identic).
 operaţii relaţionale: selecţia, proiecţia, joncţiunea, diviziunea şi redenumirea.
Operaţii de bază - reprezintă un ansamblu minimal de operaţii, în sensul că niciuna din

operaţii nu poate fi exprimată ca o combinaţie a celorlalte operaţii. Pentru algebra
relaţională există mai multe ansambluri minimale. În continuare, prezentarea va
54 Baze de date
considera ca operaţii de bază trei operaţii pe mulţimi: reuniunea, diferenţa, produsul

cartezian şi două operaţii relaţionale unare: selecţia şi proiecţia. Operatorii de
intersecţie, joncţiune şi diviziune pot fi obţinuţi din cei cinci operatori de bază.
Notă. În definirea operatorilor algebrei relaţionale vom nota cu:

t – un tuplu din relaţia R
t(A) – un subtuplu din R relativ la atributul A.
Fiecare operator al algebrei relaţionale va fi descris prin numărul şi tipul operanzilor,

precum şi tipul rezultatului.
3.2. OPERATORII ALGEBREI RELAŢIONALE
3.2.1. UNION. Reuniunea a două relaţii R1 şi R2, compatibile cu reuniunea, este dată de
mulţimea tuplurilor care aparţin fie relaţiei R1, fie relaţiei R2, fie ambelor relaţii.
Tuplurile care aparţin ambelor relaţii se introduc în reuniune o singură dată,
adică nu se duplică.
Operatorul este definit: Relaţie x Relaţie → Relaţie
R3  R1  R2  t | t ∈R1 sau t ∈R2 
R3
R1 R2
Sintaxa:
R3 = UNION (R1, R2), rezultatul R3 este o relaţie.
Exemplu:
R1 A B R2 A B R3 A B
a b d f a b
c d x y c d
x y h r x y
c d d f
h r
Algebra relaţională 55
3.2.2. DIFFERENCE. Diferenţa a două relaţii R1 şi R2, compatibile cu reuniunea, este

dată de mulţimea tuplurilor care aparţin relaţiei R1 şi nu aparţin relaţiei R2..
R3  R1 - R2  t | t ∈R1 si t  R2 
R3
R1 R2
Sintaxa:
R3 = DIFFERENCE (R1, R2), rezultatul R3 este o relaţie.
Exemplu:
a b d f a b
c d x y
x y h r
c d
3.2.3. INTERSECT. Intersecţia a două relaţii R1 şi R2, compatibile cu reuniunea, este

dată de mulţimea tuplurilor care aparţin atât relaţiei R1, cât şi relaţiei R2.
R3  R1  R2  t | t ∈R1 si t ∈R2 
R3
R1 R2
56 Baze de date
Sintaxa:
R3 = INTERSECT (R1, R2), rezultatul R3 este o relaţie.
Exemplu:
a b d f c d
c d x y x y
x y h r
c d
Observaţie. Intersecţia poate fi exprimată cu ajutorul operatorului de diferenţă

(operator de bază):
R  S  R  R  S   S  S  R 
sau cu ajutorul operatorilor de reuniune şi diferenţă:
R  S  R  S   R  S   S  R  .
3.2.4. PRODUCT. Produsul cartezian a două relaţii R1 şi R2, produce o nouă relaţie care
are ca atribute, reuniunea atributelor din cele două relaţii (atributele comune
vor fi luate separat, calificările fiind făcute cu numele relaţiei), iar fiecare
element din R1 se combină (concatenează) cu fiecare element din R2.
Relaţia produs cartezian rezultată are cardinalul egal cu: card (R1) x card (R2).
Astfel, dacă relaţia (tabela) R1 are 1.000 de tupluri (linii) iar relaţia (tabela) R2 are
5.000 de tupluri (linii), rezultă în urma produsului cartezian o relaţie (tabelă) cu
5.000.000 de tupluri (linii).
R3  R1  R2   t 1 ,t 2 | t 1 ∈R1 si t 2 ∈R2 
R3
R1 R2
Sintaxa:
R3 = PRODUCT (R1, R2), rezultatul R3 este o relaţie.
Avem:
card (R3) = card (R1) x card (R2) şi
grad (R3) = grad (R1) + grad (R2)
Exemplu:
R1 A B R2 A R3 R1. A B R2.A
a b a a b a
c d d c d a
x y x y a
a b d
c d d
x y d
3.2.5. SELECT. Selecţia este o operaţie unară de restricţie care selectează din tuplurile
relaţiei R, acele tupluri care satisfac o condiţie specificată. Condiţia este o
expresie logică (predicat) specificată asupra atributelor relaţiei R. Condiţia poate
cuprinde nume de atribute, constante, operatori logici (and, or, not), operatori
aritmetici de comparare (<, >, =, ≤, ≥, ≠).
Operatorul este definit: Relaţie x Expresie logică → Relaţie
S   conditie  R   t | t ∈R si t A  
unde: t A  defineşte condiţia de selecţie (  este un operator aritmetic de

comparare, iar  un tuplu care poate fi înlocuit de un atribut sau valoarea unui
atribut).
condiţie
Sintaxa:
S = SELECT (R; condiţie), rezultatul S este o relaţie.
Exemplu: S   B' x'  R 

iar în limbajul algebrei relaţionale avem: S = SELECT ( R; B=’x’)
58 Baze de date
R A B C S A B C
x y z t x a
t x a z x b
z x b
c u w
Observaţii.
1. Această operaţie nu trebuie confundată cu instrucţiunea SELECT, care este
instrucţiunea generală de interogare din limbajele de manipulare a datelor.
2. În termenii limbajului de interogare SQL, operaţia de selecţie realizează o
decupare pe orizontală a tabelei operand R.
3. Cardinalul relaţiei rezultat S este mai mic sau egal decât cardinalul relaţiei R.
Egalitatea poate apare în situaţia în care condiţia este adevărată pentru toate
tuplurile din relaţie.
3.2.6. PROJECT. Proiecţia este o operaţie unară de restricţie prin care se selectează din
relaţia R, numai acele atribute specificate explicit în cadrul operaţiei. Relaţia
rezultată P va avea ca atribute submulţimea selectată.
Operatorul este definit: Relaţie x Listă atribute → Relaţie
Fie R  A1 , A2 ,..., An  şi    A1 ,..., Ak  ⊂A1 , A2 ,..., An 

P    R   t  a1 ,...,ak  
lista atribute
Sintaxa:
P = PROJECT (R; lista atribute), rezultatul P este o relaţie.
Exemplu: P   A ,C R 
În limbajul algebrei relaţionale avem: P = PROJECT ( R; A,C )
R A B C P’ A C P A C
x u x x x x x
z x y z y z y
x z x x x
z y y z y
x t x x x
Observaţii.
1. Dacă în lista atributelor de proiecţie există o cheie a relaţiei operand R, atunci
relaţia rezultat are toate tuplurile distincte, adică relaţiile R şi P vor avea acelaşi
cardinal.
2. Dacă în lista atributelor de proiecţie nu există o cheie a relaţiei operand R, atunci
în relaţia rezultat P pot apare tupluri duplicate care vor fi eliminate. În exemplul
prezentat, după eliminarea tuplurilor duplicate din relaţia intermediară P’ s-a
obţinut relaţia P care conţine două tupluri distincte.
3. Relaţia rezultat P are gradul k, dat de numărul atributelor din listă.
4. În termenii limbajului de interogare SQL, operaţia de proiecţie realizează o
decupare pe verticală a tabelei operand R.
3.2.6.1. EXTENDED – PROJECT. Proiecţia extinsă este o operaţie unară de restricţie prin
care se selectează din relaţia R, atributele specificate explicit în cadrul
operaţiei. Relaţia rezultată P are ca atribute submulţimea selectată, la fel ca la
operatorul PROJECT şi poate conţine în plus:
- atribute noi rezultate din operaţii aritmetice efectuate asupra atributelor din
relaţia R; aceste operaţii vor fi prezentate explicit în lista de atribute;
- apariţii multiple ale unor atribute din relaţia R.
Sintaxa:
P = EXTENDED-PROJECT (R; lista atribute), rezultatul P este o relaţie.
Exemplu: P   AC D ,AA1,B ,AA2 R 

În limbajul algebrei relaţionale avem: P = PROJECT ( R; AxC→D,A→A1,B,A→A2 )
R A B C P D A1 B A2
1 x 20 20 1 x 1
2 z 5 10 2 z 2
3 y 30 90 3 y 3
4 x 15 60 4 x 4
3 u 5 15 3 u 3
60 Baze de date
3.2.7. JOIN (THETA-JOIN). Joncţiunea este o operaţie definită pe două relaţii R1 şi R2.
Relaţia rezultat R3 va fi construită prin concatenarea unor tupluri din R1 cu
tupluri din R2 care satisfac o anumită condiţie (condiţia de joncţiune -  )
specificată explicit în cadrul relaţiei. Condiţia de joncţiune -  este o expresie
logică (predicat) specificată asupra atributelor relaţiilor R1 şi R2. Condiţia de
joncţiune -  poate cuprinde nume de atribute, constante, operatori logici (and,
or, not), operatori aritmetici de comparare (<, >, =, ≤, ≥, ≠).
Operatorul este definit: Relaţie x Relaţie x  expresie → Relaţie
Fie relaţiile R1  A , B1  şi R2  B2 ,C  , unde B1 şi B2 sunt atribute definite pe acelaşi

domeniu. Atunci: R3  R1  R2  t | t R1  R2 si t B1  t B2 
Observaţie. Joncţiunea se poate exprima în funcţie de operaţiile de bază: produs

cartezian şi selecţie astfel:
R1  R2    R1  R2 
R3
θ
R1 R2
Sintaxa:
R3 = THETA - JOIN (R1, R2; θ - expresie), rezultatul R3 este o relaţie.
Exemplu:
R3  R1  R2 unde  : R1 .A  R2 .A
În limbajul algebrei relaţionale avem: R3 = THETA - JOIN ( R1, R2; R1.A > R2.A )
R1 A B C R2 D E A R3 R1. A B C D E R2. A
a x c 0 11 a b y c 0 11 a
b y c 1 13 a b y c 1 13 a
d z g 3 11 a b y c 3 11 a
4 11 d d z g 0 11 a
6 12 d d z g 1 13 a
7 13 c d z g 3 11 a
d z g 7 13 c
În continuare se prezintă patru forme ale operaţiei de joncţiune.

3.2.7.1. EQUI – JOIN. Joncţiunea de egalitate este un caz particular al lui THETA – JOIN ,
când  este egalitate.
Sintaxa:
R3 = EQUI - JOIN (R1, R2; θ - expresie) , rezultatul R3 este o relaţie.
Exemplu:
R3  R1  R2 unde  : R1 .A  R2 .A
În limbajul algebrei relaţionale avem: R3 = EQUI - JOIN ( R1, R2; R1.A > R2.A )
a x c 0 11 a a x c 0 11 a
b y c 1 13 a a x c 1 13 a
d z a 3 11 a a x c 3 11 a
4 11 d d z a 4 11 d
6 12 d d z a 6 12 d
7 13 c
3.2.7.2. NATURAL – JOIN. Joncţiunea naturală este o joncţiune pe egalitate (EQUI –

JOIN) pentru toate atributele cu acelaşi nume din cele două relaţii, urmată de o
proiecţie pe reuniunea atributelor celor două relaţii. În cazul EQUI – JOIN
schema relaţiei rezultat conţine toate atributele celor doi operanzi şi rezultă că
în fiecare tuplu al relaţiei rezultat vor exista cel puţin două valori egale.
Introducerea joncţiunii naturale va elimina această redundanţă.
Schema relaţiei rezultat R3 se obţine prin reuniunea atributelor celor două
relaţii R1 şi R2 (atributele cu acelaşi nume se iau o singură dată), iar extensia
relaţiei R3 va conţine tuplurile obţinute prin concatenarea tuplurilor din R1 cu
tupluri din R2, care au aceleaşi valori pentru atributele cu acelaşi nume.
Joncţiunea naturală este joncţiunea cea mai utilizată în practică şi poate fi definită cu
ajutorul operaţiilor de bază: proiecţie, selecţie şi produs cartezian.
Dacă se notează cu:
 - condiţia de egalitate între valorile atributelor din intersecţia schemelor relaţiilor
R1 şi R2 (coloanele comune),
atr - reuniunea atributelor celor două scheme (atributele cu acelaşi nume se iau o
singură dată),
atunci:
R3  R1  R2  atr   R1  R2 
Sintaxa:
R3 = NATURAL - JOIN (R1, R2; atribut(e) joncţiune*), rezultatul R3 fiind o relaţie.
* pentru mărirea clarităţii va apare atributul / atributele de joncţiune.
62 Baze de date
Exemple:
1. Se dau relaţiile: R1 A , B ,C  şi R2 B ,C , D
şi condiţia   R1 .B  R2 .B and R1 .C  R2 .C  .
Avem atr  A , B ,C , D .
Exprimăm în limbajul algebrei relaţionale:

R3 = NATURAL-JOIN ( R1, R2; B, C )
R1 A B C R2 B C D R3 A B C D
a b c b c d a b c d
d b c b c e a b c e
b b f a d b d b c d
c a d d b c e
c a d b
2. Se dau relaţiile: R1 A , B ,C  şi R2 D , E , A
şi condiţia   R1 .A  R2 .A
Avem atr  A , B ,C , D , E .
Exprimăm în limbajul algebrei relaţionale:

R3 = NATURAL-JOIN ( R1, R2; A )
R1 A B C R2 D E A R3 A B C D E
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
7 13 c
Observaţie.
Selecţia este un caz particular de joncţiune naturală a unei relaţii cu o relaţie constantă.
Înţelegem prin relaţie constantă o relaţie care are un singur tuplu, eventual redus la o
singură valoare.
3.2.7.3. SEMI – JOIN. Semi-joncţinea este joncţiunea dintre două relaţii R1 şi R2 ,

urmată de o proiecţie pe atributele relaţiei R1. Semi-joncţiunea conservă
atributele unei relaţii participante la joncţiune (R1). Semi–joncţiunea mai poate
fi privită ca o generalizare a operaţiei de selecţie, rezultatul fiind o selecţie
asupra relaţiei R1 , realizată pe baza valorilor din R2 ale atributului de joncţiune.
Sintaxa:
R3 = SEMI-JOIN (R1, R2; θ - expresie), rezultatul R3 fiind o relaţie.
R3
θ
R1 R2
Exemplu.
R3  R1  R2 unde  : R1 .A  R2 .A
R1 A B C R2 D E A R3 A B C
a x c 0 11 a a x c
b y c 1 13 a a x c
d z a 3 11 a a x c
4 11 d d z a
6 12 d d z a
7 13 c
Observaţie.
Considerăm joncţiunea naturală dintre R1  A , B1  şi R2  B2 ,C  unde B1 şi B2 sunt
atributele de joncţiune.
 Dacă B1  B2   , atunci joncţiunea corespunde produsului cartezian.

 Dacă A  C   , atunci joncţiunea corespunde intersecţiei.
 Dacă A   sau C   (dar nu amândouă), atunci operaţia este o
semi-joncţiune.
3.2.7.4. OUTER – JOIN. Joncţiunea dintre două relaţii R1 şi R2 poate conduce la pierdere
de tupluri, dacă relaţiile participante la joncţiune nu au proiecţii identice pe
atributul de joncţiune, adică nu au aceleaşi valori în relaţiile care se joncţionează.
Joncţiunea externă (R3) conţine joncţiunea naturală dintre R1 şi R2, la care se
adaugă tuplurile din R1 şi R2, care nu au participat la joncţiune. În aceste tupluri
se va atribui valorea null pentru atributele relaţiei corespondente.
Sintaxa:
R3 = OUTER-JOIN (R1, R2; atribut(e) joncţiune), rezultatul R3 fiind o relaţie.
64 Baze de date
R3
ext
R1 R2
Exemplu.
R3  R1 ext R2
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
7 13 c b y c null null
c null null 7 13
Observaţii.
În urma joncţiunii naturale se pierd informaţiile din tuplurile < b, y, c > din R1 şi
< 7, 13, c > din R2. Aceste tupluri se adaugă în cazul joncţiunii externe şi se completează
cu null pe atributele relaţiei corespondente. Acest tip de joncţiune externă se mai
numeşte FULL OUTER-JOIN.
Există şi LEFT OUTER-JOIN în care se adaugă numai tuplurile din R1 care nu au participat
la joncţiune:
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
Analog, se introduce şi RIGHT OUTER-JOIN în care se adaugă numai tuplurile din R2 care
nu au participat la joncţiune. Pentru exemplul considerat se obţine:
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
7 13 c c null null 7 13
ALGEBRA RELAŢIONALĂ (2)
3.2.8. DIVISION. Diviziunea este o operaţie definită pe două relaţii care au schemele:
 
R1 A1 , A2 ,..., An  şi R2 A p1 , A p2 ,..., An .
 
Relaţia rezultat R3  R1  R2 are schema R3 A1 , A 2 ,..., A p şi este formată din
toate tuplurile care, concatenate cu fiecare tuplu din R2 , dau întotdeauna un
tuplu din R1.
Notăm: 
ATR1  A1 , A2 ,..., Ap1 , AP2 ,..., An 
ATR2  Ap1 , AP2 ,..., An 
Definiţia 1. t  R1  R2 dacă t 2 R2 t 1 R1 , astfel încât  ATR1 ATR2 t 1   t şi
 ATR2 t 1   t 2 .
sau altfel spus:
R1  R2   t |   t 2 R2   t ,t 2 R1 ,
unde am notat prin <…> un tuplu dintr-o relaţie.
Definiţia 2. Diviziunea se poate exprima în funcţie de operaţiile de bază: produs

cartezian, diferenţă şi proiecţie astfel:
 
R1  R2   ATR1 ATR2 R1    ATR1 ATR2  ATR1 ATR2 R1  R2  R1 
Sintaxa:
R3 = DIVISION (R1, R2) , rezultatul R3 este o relaţie.
R3
R1 R2
1
În limbajul algebrei relaţionale, diviziunea a două relaţii se poate exprima conform
definiţiei 2, astfel:
Q1 = PROJECT (R1; A1, A2,…, Ap)

S = PRODUCT (Q1, R2)
T = DIFFERENCE (S, R1)
Q2 = PROJECT (T; A1, A2,…, Ap)
R = DIFFERENCE (Q1, Q2)
Într-o formă agregată, exprimarea pas cu pas de mai sus, se poate scrie:
R = DIVISION (R1, R2) = DIFFERENCE (PROJECT (R1; A1, A2,…, Ap), PROJECT (DIFFERENCE
(PRODUCT (PROJECT (R1; A1, A2,…, Ap), R2), R1); A1, A2,…, Ap))
Problemă (Exemplu de diviziune)

Fie relaţia R1 K , P  , unde atributul K are ca valori codurile angajaţilor unui institut de
cercetare, iar atributul P conţine codurile proiectelor în derulare. Un cercetător poate
lucra la unul sau mai multe proiecte. Să se determine codurile angajaţilor angrenaţi
simultan în proiectele P3 şi P4.
Rezolvare.
Construim relaţia R2 P  care va conţine două tupluri: <P3> şi <P4>.
Codurile angajaţilor care lucrează la proiectele P3 şi P4 sunt date de rezultatul diviziunii
R1  R2 .
R1 K P R2 P
17 P1 P3
17 P2 P4
17 P3
17 P4
29 P1
29 P3
53 P3
53 P4
80 P3
Calculăm diviziunea conform definiţiei 2: R1  R2  Q1  Q2
Pasul 1. Calculăm Q1   ATR1 ATR2 R1 

Pasul 2. Calculăm S  Q1  R2
2
Q1 K S K P
17 17 P3
29 29 P3
53 53 P3
80 80 P3
17 P4
29 P4
53 P4
80 P4
Pasul 3. Calculăm T  S  R1
Pasul 4. Calculăm Q2   ATR1 ATR2 T 
T K P Q2 K
29 P4 29
80 P4 80
Pasul 5. Calculăm R1  R2  Q1  Q2
R1 : R2 K
17
53
Rezultatul interogării: angajaţii cu codul <17> şi <53> lucrează simultan în proiectele
<P3> şi <P4>.
3.2.9. RENAME. Redenumirea este un operator care crează o nouă schemă unei relaţii.
Dată relaţia R 2 cu schema relaţiei R2 B1 , B 2 ,..., Bn operatorul  dă o nouă
schemă relaţiei cu numele de R1 :
R1 : R1 A1 ,A2 ,...,An  R2  sau în notaţie simplificată R1 A1 , A2 ,..., An :  R2 .
R1 va fi o relaţie cu atributele A1 , A2 ,..., An şi aceleaşi tupluri ca şi relaţia R 2 .
Operatorul RENAME permite redenumirea numelui unui atribut pentru a putea
aplica operatorii din teoria mulţimilor. Operatorul RENAME modifică doar
numele atributelor, conţinutul tuplurilor din relaţie rămâne neschimbat.
Operatorul este definit: Relaţie → Relaţie
Sintaxa:
R1 = RENAME (R2; A1, A2,..., An) , rezultatul R1 este o relaţie.
sau R1 = RENAME (R2), dacă atributele păstrează acelaşi nume.
3
R1
A1, A2,..., An
R2
Exemplu.
Se dă relaţia R 2 , cu schema R2 B1 , B 2 , B 3. Aplicăm operatorul  pentru a obţine
relaţia R1 având schema R1 A1 , B2 , A3 .
Notăm aceasta prin: R1 A1 , B2 , A3 : R2 sau R1 = RENAME (R2; A1, B2, A3).
R2 B1 B2 B3 R1 A1 B2 A3
a x c a x c
b y c b y c
d z a d z a
Problemă (Exemplu de redenumire)
Fie relaţia CARTE [titlu, an], unde atributul an reprezintă anul apariţiei cărţii. Să se afle
titlul celei mai vechi cărţi.
Rezolvare.
Relaţia rezultat este dată de:
R  titlu CARTE   C 1.titlu  C 1.anC 2.an C 1 CARTE   C 2 CARTE 

În limbajul algebrei relaţionale avem:
P1 = PROJECT (CARTE; titlu)

C1 = RENAME (CARTE)
C2 = RENAME (CARTE)
R1 = PRODUCT (C1, C2)
S = SELECT (R1; C1.an>C2.an)
P2 = PROJECT (S; C1.titlu)
R = DIFFERENCE (P1, P2)
sau utilizînd operatorul de joncţiune THETA-JOIN:

P1 = PROJECT (CARTE; titlu)
C1 = RENAME (CARTE)
C2 = RENAME (CARTE)
4
T = THETA-JOIN (C1, C2; C1.an>C2.an)
P2 = PROJECT (S; C1.titlu)
R = DIFFERENCE (P1, P2)
Exemplu. Din relaţia (tabela, fişierul) CARTE:
CARTE titlu an
Analiza 2005
Modelarea 1999
Proiectarea 2015
Implementarea 2011
Dorim să determinăm titlul celei mai vechi cărţi.
Pasul 1. P1 = PROJECT (CARTE; titlu)
P1 titlu
Analiza
Modelarea
Proiectarea
Implementarea
Pasul 2. C1 = RENAME (CARTE)

C2 = RENAME (CARTE)
C1 titlu an C2 titlu an
Analiza 2005 Analiza 2005
Modelarea 1999 Modelarea 1999
Proiectarea 2015 Proiectarea 2015
Implementarea 2011 Implementarea 2011
Pasul 3. R1 = PRODUCT (C1, C2)
R1 C1.titlu C1.an C2.titlu C2.an

Analiza 2005 Analiza 2005
Analiza 2005 Modelarea 1999
Analiza 2005 Proiectarea 2015
Analiza 2005 Implementarea 2011
Modelarea 1999 Analiza 2005
Modelarea 1999 Modelarea 1999
Modelarea 1999 Proiectarea 2015
Modelarea 1999 Implementarea 2011
Proiectarea 2015 Analiza 2005
Proiectarea 2015 Modelarea 1999
5
Proiectarea 2015 Proiectarea 2015
Proiectarea 2015 Implementarea 2011
Implementarea 2011 Analiza 2005
Implementarea 2011 Modelarea 1999
Implementarea 2011 Proiectarea 2015
Implementarea 2011 Implementarea 2011
Pasul 4. S = SELECT (R1; C1.an>C2.an)
S C1.titlu C1.an C2.titlu C2.an

Analiza 2005 Modelarea 1999
Proiectarea 2015 Analiza 2005
Proiectarea 2015 Modelarea 1999
Proiectarea 2015 Implementarea 2011
Implementarea 2011 Analiza 2005
Implementarea 2011 Modelarea 1999
Pasul 5. P2 = PROJECT (S; C1.titlu)
P2 C1.titlu
Analiza
Proiectarea
Implementarea
Pasul 6. R = DIFFERENCE (P1, P2)
R titlu
Modelarea
Observaţie.
În a doua variantă, paşii 3 şi 4 (produsul cartezian şi selecţia) sunt înlocuiţi de joncţiunea
T = THETA-JOIN (C1, C2; C1.an>C2.an), iar pasul 5 devine: P2 = PROJECT (T; C1.titlu).
3.2.10. RESTRICT. Restricţia este un operator care crează două relaţii plecând de la o
relaţie R şi o condiţie. Se obţin relaţiile: R1 care conţine tuplurile relaţiei R care
verifică condiţia şi R 2 care conţine tuplurile relaţiei R care nu verifică condiţia.
Acest operator este considerat o extensie a algebrei relaţionale.
Operatorul este definit: Relaţie x Conditie → Relaţie x Relaţie

R1  conditie  R   t | t ∈R si t satisface conditia
R2  conditie  R   t | t ∈R si t nu satisface conditia
6
R1 R2
condiţie non condiţie
R
Sintaxa:
R1, R2 = RESTRICT (R; condiţie), rezultatul este format din relaţii R1 şi R2.
Este echivalent cu aplicarea pe o relaţie de două ori a operatorului de selecţie, SELECT:

R1 = SELECT (R; condiţie)
R2 = SELECT (R; non-condiţie).
3.2.11. TRANSITIVE CLOSURE. Închiderea tranzitivă a unei relaţii este un operator

special care permite adăugarea de tupluri unei relaţii. Acest operator nu aparţine
algebrei relaţionale, dar poate fi considerat ca o extensie a acesteia. Acest
operator nu poate fi exprimat printr-un număr fix (determinat) de operaţii ale
algebrei relaţionale. Închiderea tranzitivă se poate realiza printr-o serie de
joncţiuni – proiecţii - reuniuni, numărul acestora depinzând de conţinutul
relaţiei. Unii autori consideră un neajuns al algebrei relaţionale, imposibilitatea
de a exprima închiderea tranzitivă printr-o expresie constantă de operaţii
elementare.
Operatorul este definit: Relaţie → Relaţie, astfel:

- dacă R [ A1 : D, A2 : D ] este o relaţie cu două atribute care au acelaşi domeniu,
închiderea tranzitivă a relaţiei R constă din adăugarea la această relaţie a tuturor
tuplurilor care se pot deduce succesiv prin tranzitivitate, altfel spus dacă tuplurile <a, b>
şi <b, c> aparţin relaţiei R, atunci la aceasta se va adăuga tuplul <a, c>.
Pentru realizarea închiderii tranzitive se execută de mai multe ori ciclul de operaţii
joncţiune – proiecţie - reuniune până la obţinerea închiderii complete. Exprimat în
limbaj algoritmic avem:
input R [ A1, A2 ]
τ (R) = RENAME (R; A3, A4 )
while τ (R) se modifică
do T = THETA-JOIN (R, τ (R); A2 = A3)
P = PROJECT (T; A1, A4)
S = RENAME (P; A3, A4 )
τ (R) = UNION (τ (R), S)
endwhile
output τ (R) {închiderea tranzitivă a relaţiei R}.
7
Sintaxa:
τ(R) = CLOSE (R), rezultatul este relaţia iniţială la care se adaugă tuplurile
rezultate prin tranzitivitate.
De exemplu, plecând de la relaţia PARINTI [ parinte, copil ], această operaţie permite

determinarea relaţiei ARBORE [ ascendent, descendent ] care descrie filiaţia cunoscută a
unei persoane. Închiderea tranzitivă a relaţiei PARINTI este determinată prin joncţiuni –
proiecţii – reuniuni succesive a relaţiei PARINTI cu ea însăşi până la saturaţie, adică până
la obţinerea unei relaţii stabile, τ (R), în care nu se mai pot adăuga noi tupluri.
Arborele relaţiei PARINTI:

O I
V A
PARINTI parinte copil
I D
O D
D R
R V
R A
După primul ciclu de operaţii se obţine relaţia τ(PARINTE), denumită ARBORE :
ARBORE ascendent descendent

I D
O D
D R
R V
R A
I R
O R
D V
D A
Al doilea ciclu de operaţii conduce la obţinerea închiderii tranzitive pentru relaţia

PARINTE:
8
ARBORE ascendent descendent
I D
O D
D R
R V
R A
I R
O R
D V
D A
I V
I A
O V
O A
Aplicarea în continuare a ciclului de operaţii nu mai adaugă niciun tuplu relaţiei ARBORE,
deci procesul de determinare a închiderii tranzitive pentru relaţia PARINTE s-a încheiat.
Observăm că după primul ciclu de operaţii s-au adăugat tuplurile care conţin “nepoţii”,
iar după cel de-al doilea ciclu de operaţii s-au adăugat tuplurile care conţin “strănepoţii”.
3.3. OPERAŢII DE CALCUL
La operaţiile descrise anterior se pot adăuga operaţii de calcul pe relaţii. Aceste operaţii
sunt justificate de numeroasele interogări (cereri) mai complexe care necesită operaţii
de calcul. Operaţiile de calcul sunt implementate în toate limbajele de interogare. Aceşti
operatori de calcul formează deci o extensie a operatorilor de bază şi nu pot fi exprimaţi
cu ajutorul acestora.
3.3.1. COUNT - este o operaţie care permite numărarea tuplurilor dintr-o relaţie
(liniilor dintr-o tabelă) care au aceeaşi valoare pe atributul considerat (sau
aceleaşi valori pe atributele considerate). Relaţia rezultantă va conţine numai
atributul (atributele) de regrupare Xi , iar tuplurile vor fi formate din valorile
distincte şi numărul de apariţii.
Notăm:
T  COUNTX 1 ,..., X n ( R ) , unde X1,...,Xn sunt atributele de regrupare.
9
T
Count
Operaţia COUNT
Exemplu.
R A B C CountB(R) B Count CountB,C(R) B C Count

a n 17 n 2 n 17 2
b o 14 m 2 m 20 1
c n 17 o 1 m 10 1
d p 13 p 1 o 14 1
e m 20 p 13 1
f m 10
Dacă nu este precizat niciun atribut de regrupare, operaţia COUNT va determina

numărul de tupluri din relaţie:
Count(R) Count
6
Operaţia este definită: Relaţie → Relaţie
Sintaxa:
R1 = COUNT (R; X1, X2, ..., Xn), rezultatul R1 este o relaţie.
Relaţia rezultată are schema R1 X 1 , X 2 ,..., X n ,Count  .
R1 = COUNT (R), rezultatul R1 este un număr. Acesta poate fi interpretat ca o

relaţie cu un singur atribut şi un singur tuplu, care are ca valoare numărul de linii
din tabelă. Relaţia rezultată are schema R1 Count .
3.3.2. SUM – este o operaţie care permite efectuarea sumei valorilor atributului Y
pentru fiecare din valorile diferite ale atributelor de regrupare X1,...,Xn . Atributul
Y trebuie să fie numeric.
Notăm:
T  SUM X 1 ,..., X n ( R ,Y ) , unde X1,...,Xn sunt atributele de regrupare.
10
Dacă nu este precizat niciun atribut de regrupare, operaţia SUM va determina suma
valorilor atributului Y.
Sum
Operaţia SUM
Exemplu.
R A B C SumB(R,C) B Sum Sum(R,C) Sum

a n 17 n 34 91
b o 14 m 30
c n 17 o 14
d p 13 p 13
e m 20
f m 10
Operaţia este definită: Relaţie → Relaţie

Sintaxa:
R1 = SUM (R, Y; X1, X2, ..., Xn), rezultatul R1 este o relaţie.
Relaţia rezultată are schema R1 X 1 , X 2 ,..., X n , Sum.
R1 = SUM (R, Y), rezultatul R1 este un număr. Poate fi interpretat ca o relaţie cu

un singur atribut şi un singur tuplu, care are ca valoare suma valorilor atributului
Y din toate liniile tabelei). În acest caz relaţia rezultată are schema R1 Sum  .
3.3.3. MEAN – este o operaţie care permite efectuarea mediei aritmetice a valorilor
atributului Y pentru fiecare din valorile diferite ale atributelor de regrupare
X1,...,Xn . Atributul Y trebuie să fie numeric.
Notăm:
T  MEAN X 1 ,...,X n ( R ,Y ) , unde X1,...,Xn sunt atributele de regrupare.
11
Dacă nu este precizat niciun atribut de regrupare, operaţia MEAN va determina media
aritmetică a valorilor atributului Y din toată relaţia.
Mean
...
Operatorul MEAN
Exemplu.
R A B C MeanB(R,C) B Mean Mean(R,C) Mean

a n 17 n 15 15
b o 9 o 9
c p 21 p 17
d n 13
e p 20
f p 10
Sintaxa:
R1 = MEAN (R, Y; X1, X2, ..., Xn), rezultatul R1 este o relaţie;
Relaţia rezultată are schema R1 X 1 , X 2 ,..., X n , Mean .
R1 = MEAN (R, Y), rezultatul R1 este un număr. Poate fi interpretat ca o relaţie cu

un singur atribut şi un singur tuplu, care are ca valoare media aritmetică a
valorilor atributului Y din toate liniile tabelei. În acest caz, relaţia rezultată are
schema R1 Mean .
3.3.4. MAX sau MIN - este o operaţie care permite determinarea valorii maxime /
minime a atributului Y pentru fiecare din valorile diferite ale atributelor de
regrupare X1,...,Xn . Atributul Y trebuie să fie numeric.
Notăm:
T  MAX X 1 ,...,X n ( R ,Y ) , unde X1,...,Xn sunt atributele de regrupare.
T  MIN X 1 ,...,X n ( R ,Y ) , unde X1,...,Xn sunt atributele de regrupare.
12
Dacă nu este precizat niciun atribut de regrupare, operaţia MAX (MIN) va determina
maximul (minimul) valorilor atributului Y din toată relaţia.
T
Max
Operatorul MAX (MIN)

Exemplu.
R A B C MinB(R,C) B Min Max(R,C) Max

a n 17 n 13 21
b o 9 o 9
c p 21 p 10
d n 13
e p 20
f p 10
Sintaxa:
R1 = MAX (R, Y; X1, X2, ..., Xn), rezultatul R1 este o relaţie;
Relaţia rezultată are schema R1 X 1 , X 2 ,..., X n , Max  .
R1 = MAX(R, Y), rezultatul R1 este un număr. Poate fi interpretat şi ca o relaţie

cu un singur atribut şi un singur tuplu, care are ca valoare maximul valorilor
atributului Y din toate liniile tabelei. În acest caz relaţia rezultată are schema
R1 Max 
Observaţie. Pentru operaţia MIN sintaxa este analoagă.
13
3.4. PROPRIETĂŢILE OPERATORILOR ALGEBREI RELAŢIONALE
Prezentăm în continuare o serie de proprietăţi ale operatorilor algebrei relaţionale [W1]

[W2], care stau la baza optimizării interogărilor.
1. Comutativitatea
 Operaţiile de reuniune (UNION) , intersecţie (INTERSECT) şi produs cartezian
(PRODUCT) sunt comutative:
R1  R2  R2  R1
R1  R2  R2  R1
R1  R2  R2  R1 .
 Operaţia de joncţiune (JOIN) poate fi considerată comutativă:

R1  R2  R2  R1 .
Ullman [99] consideră că operaţia de joncţiune este într-un sens necomutativă, dacă se
consideră ordinea atributelor (coloanelor) din relaţia rezultat. De exemplu, date relaţiile:
R1 A , B şi R2 B , C  , joncţiunea naturală R1  R2 cu  : R1 .B  R2 .B conduce la relaţia
RA , B , C  , iar în cazul R2  R1 cu  : R1 .B  R2 .B conduce la relaţia RB , C , A .
 Operaţia de diferenţă (DIFFERENCE) nu este comutativă:

R1  R2  R2  R1 .
 Operaţia de selecţie (SELECT) este comutativă:

 conditie 1  conditie 2 R    conditie 2  conditie 1 R    conditie 1 AND conditie 2 R 
2. Asociativitatea
 Operaţiile de reuniune (UNION) , intersecţie (INTERSECT) şi produs cartezian
(PRODUCT) sunt asociative:
R1  R2   R2  R1  R2  R3 
R1  R2   R2  R1  R2  R3 
R1  R2   R2  R1  R2  R3  .
 Operaţia de joncţiune (JOIN) nu este întotdeauna asociativă. De exemplu, date

relaţiile:
R1 A , B, R2 B , C  şi R3 A , D , considerăm operaţia de joncţiune naturală definită de:
R1  1 R2   2 R3 cu  1 : R1 .B  R2 .B şi  2 : R.A  R3 .A , unde RA , B , C  este
rezultatul joncţiunii R1  1 R2  .
Aceasta nu este egală cu R1  1 R2  2 R3  deoarece relaţiile R2 B , C  şi R3 A , D nu
conţin atribute comune pe care să se realizeze joncţiunea.
În anumite situaţii operaţia de joncţiune este asociativă. De exemplu, date relaţiile:
R1 A , ... , R2 B , C ,...  şi R3 D ,... , se poate demonstra că:
R1  1 R2   2 R3  R1  1 R2  2 R3  , unde  1 : A  B şi  2 : C  D .
14
 Operaţia de diferenţă (DIFFERENCE) nu este asociativă:
R1  R2   R3  R1  R2  R3 
3. Compunerea
 Compunerea proiecţiilor (PROJECT):
 A1,A2 ,...,Am  B1,B2 ,...,Bn R    A1,A2 ,,...,Am R 
unde A1, A2 ,..., Am  B1, B2 ,..., Bn.
4. Comutarea
 Comutarea selecţiei cu proiecţia:
 A1,A2 ,...,Am  conditie R    conditie  A1,A2 ,...,Am R 
unde atributele din conditie aparţin mulţimii A1, A2 ,..., Am.
 Comutarea selecţiei cu produsul cartezian:

Dacă toate atributele care apar în condiţia de selecţie aparţin lui R1 , atunci:
 conditie R1  R2    conditie R1   R2 .
Dacă condiţia de selecţie este de forma conditie1 AND conditie2 şi conditie1 conţine
numai atribute din R1 , iar conditie2 conţine numai atribute din R 2 , atunci:
 conditie 1 AND conditie 2 R1  R2    conditie 1 R1    conditie 2 R2  .
numai atribute din R1 , iar conditie2 conţine atribute atât din R1 cât şi din R 2 , atunci:
 conditie 1 AND conditie 2 R1  R2    conditie 2  conditie 1 R1   R2  .
 Comutarea selecţiei cu joncţiunea:

numai atribute din R1 , iar conditie2 conţine numai atribute din R 2 , atunci:
 conditie 1 AND conditie 2 R1  R2    conditie 1 R1    conditie 2 R2  .
 Comutarea selecţiei cu reuniunea:

 conditie R1  R2    conditie R1    conditie R2 
 Comutarea selecţiei cu diferenţa:

 conditie R1  R2    conditie R1    conditie R2 
 Comutarea proiecţiei cu reuniunea:

 A1,A2 ,...,Am R1  R2    A1,A2 ,...,Am R1    A1,A2 ,...Am R2 
 Comutarea proiecţiei cu produsul cartezian:

Dacă A1, A2 ,..., Am sunt atribute din R1 şi B1, B2 ,..., Bn sunt atribute din R 2 , atunci:
 A1,A2 ,...,Am ,B1,B2 ,...,Bn R1  R2    A1,A2 ,...,Am R1    B1,B2 ,...Bn R2 
15
 Comutarea proiecţiei cu joncţiunea:
Dacă A1, A2 ,..., Am , D sunt atribute din R1 , B1, B2 ,..., Bn, D sunt atribute din R 2 şi
 : R1 .D  R2 .D , atunci:
 A1,A2 ,...,Am,B1,B2 ,...,Bn ,D R1  R2    A1,A2 ,...,Am,D R1    B1,B2 ,...Bn ,D R2 
3.5. OPTIMIZAREA INTEROGĂRILOR
Din proprietăţile operatorilor algebrei relaţionale rezultă mai multe reguli care pot fi
aplicate pentru a realiza optimizarea interogărilor [W1]:
R1. Operaţiile de selecţie se execută cât mai repede, deoarece reduc dimensiunile
relaţiilor (numărul de tupluri).
R2. Se recomandă înlocuirea operaţiei de produs cartezian cu operaţia de joncţiune,
pentru a nu mări inutil numărul de tupluri din relaţia rezultată. În cazul produsului
cartezian:
R  R1  R2 , numărul numărul de tupluri (linii) din relaţia (tabela) rezultată este:
card R   card R1   card R2  .
R3. În cazul unor operaţii succesive de joncţiune, se recomandă să se execute prima cea
care are condiţia cea mai puternică (cea mai restrictivă). Aceasta va conduce la
micşorarea numărului de tupluri din relaţia rezultată. Stabilirea celei mai puternice
condiţii poate rezulta din analiza statistică a datelor conţinute în tabelele bazei de date.
R4. În cazul relaţiilor cu grad mare, adică un număr mare de atribute (coloane) se poate
reduce numărul acestora prin operaţia de proiecţie. Un atribut dintr-o relaţie care nu
este utilizat în operaţiile ulterioare şi nici nu face parte din raportul final poate fi
eliminat. Operaţiile de proiecţie se pot executa la început pentru a reduce gradul
relaţiilor implicate în interogare.
De exemplu, se dau relaţiile:

FURNIZORI [cod_furnizor, nume_furnizor]
FACTURI_PRIMITE [nr_factura, cod_furnizor, data, valoare]
şi presupunem că relaţia FURNIZORI are cardinalul 200 (numărul de tupluri din relaţie
sau numărul de linii din tabelă), iar relaţia FACTURI PRIMITE are cardinalul 3000. Mai
presupunem că după 29.11.2016 s-au primit 20 de facturi de la furnizorul cu codul
‘F171’.
Pentru interogarea Ce facturi s-au primit de la furnizorul cu codul F171 după
29.11.2016? se pot da mai multe soluţii de rezolvare în limbajul algebrei relaţionale:
Soluţia 1.
R1 = PRODUCT (FURNIZORI, FACTURI_PRIMITE)
R2 = SELECT (R1; FURNIZORI.cod_furnizor = FACTURI_PRIMITE.cod_furnizor)
R3 = SELECT (R2; (data > 29.11.2016) and (cod_furnizor = ’F171’))
R4 = PROJECT (R3; nr_factura, nume_furnizor, data, valoare)
16
Observaţie. Produsul cartezian al celor două relaţii generează o nouă relaţie (R1) cu
200 x 3000 = 600000 de tupluri.
Soluţia 2.
R1 = NATURAL JOIN (FURNIZORI, FACTURI_PRIMITE; cod_furnizor)
Observaţie. Relaţia R1 rezultat al joncţiunii are 3000 de tupluri, iar relaţia R2 rezultată
după operaţia de selecţie are, conform presupunerii, 20 de tupluri.
Soluţia 3.
R1 = SELECT (FACTURI_PRIMITE; (data > 29.11.2016) and (cod_furnizor = ’F171’))
R2 = NATURAL JOIN (FURNIZORI, R1; cod_furnizor)
Observaţie. Conform presupunerii făcute, relaţia R1 rezultat al selecţiei va avea 20 de
tupluri, iar relaţia R2 obţinută după operaţia de joncţiune va avea tot 20 de tupluri (linii).
3.6. ARBORELE DE INTEROGARE (Relational Tree)
Interogările exprimate sub forma unei secvenţe de operaţii ale algebrei relaţionale pot fi
reprezentate printr-un arbore relaţional (relational tree), numit şi arbore de interogare.
Nodurile arborelui corespund reprezentărilor grafice ale operaţiilor prezentate (§3.2 şi
§3.3), iar arcele corespund fluxurilor de date între operaţii. Frunzele arborelui sunt
operanzii (relaţiile), iar rădăcina arborelui (o relaţie) reprezintă rezultatul interogării. Aşa
după cum am prezentat în §3.5 trei soluţii pentru interogarea formulată, pot exista mai
mulţi arbori relaţionali echivalenţi pentru o interogare.
Mai mulţi arbori echivalenţi pot fi deduşi dintr-un arbore dat pe baza proprietăţilor
operatorilor algebrei relaţionale. Astfel, comutarea selecţiei cu joncţiunea, prezentată în
§3.4, este una din cele mai importante transformări de optimizare. Această
transformare cunoscută sub numele restriction pushing, realizează “împingerea”
operaţiei de selecţie la nivelele inferioare ale arborelui de interogare.
Proprietăţile operatorilor algebrei relaţionale permit ca în unele situaţii să nu fie necesar
să se aştepte rezultatul operaţiei precedente pentru a executa operaţia următoare.
Operatorii situaţi pe ramuri distincte ale arborelui pot să fie executaţi în paralel, în mod
independent. Reprezentarea prin arbori realaţionali pune în evidenţă posibilităţile de
calcul paralel, din care rezultă optimizarea interogărilor în acest context.
Prezentăm în continuare arborii relaţionali construiţi pentru cele trei soluţii, prezentate
în paragraful anterior, de rezolvare a interogării Ce facturi s-au primit de la furnizorul cu
codul F171 după 29.11.2016?
Pentru o urmărire mai uşoară a echivalenţei arborele relaţional  limbajul algebrei
relaţionale, reluăm soluţiile prezentate în §3.5 de rezolvare a interogării.
17
Soluţia 1 (limbajul algebrei relaţionale)
R1 = PRODUCT (FURNIZORI, FACTURI_PRIMITE)

R2 = SELECT (R1; FURNIZORI.cod_furnizor = FACTURI_PRIMITE.cod_furnizor)
Soluţia 1 (arborele relaţional)
R4
nr_factura, nume_furnizor,
data, valoare
R3
(data > 29.11.2016) and
(cod_furnizor = ’F171’)
R2
FURNIZORI.cod_furnizor =
FACTURI_PRIMITE.cod_furnizor
R1
FURNIZORI FACTURI_PRIMITE
În ipotezele:
I1. cardinal (FURNIZORI) = 200,
I2. cardinal (FACTURI PRIMITE) = 3000,
I3. după 29.11.2016 s-au primit 20 de facturi de la furnizorul cu codul ‘F171’.
Vom avea:
cardinal (R1) = 600000 gradul relaţiei R1 = 6
18
R1 = NATURAL JOIN (FURNIZORI, FACTURI_PRIMITE; cod_furnizor)

R3
data, valoare
R2
(data > 29.11.2016) and

R1
cod_furnizor
FURNIZORI FACTURI_PRIMITE
În ipotezele anterioare avem:

19
R1 = SELECT (FACTURI_PRIMITE; (data > 29.11.2016) and (cod_furnizor = ’F171’))

R2 = NATURAL JOIN (FURNIZORI, R1; cod_furnizor)
R3
data, valoare
R2
cod_furnizor R1
FURNIZORI
(data > 29.11.2016) and
FACTURI_PRIMITE
În ipotezele anterioare avem:

Se observă importanţa transformării de optimizare restriction pushing, care “împinge”

operaţia de selecţie la ultimul nivel al arborelui de interogare.
20
CAPITOLUL 4
LIMBAJUL SQL
4.1. INTRODUCERE
SQL (Structured Query Language - Limbaj Structurat de Interogare) este un limbaj de

programare neprocedural specific bazelor de date.
Limbajul SQL este standardizat ANSI-ISO (fiind cel mai popular limbaj de manipulare a
bazelor de date relaţionale) şi poate fi utilizat în: MySQL, SQL Server, MS Access, Oracle,
DB2, etc.
Pentru a înţelege diferenţa dintre limbajul natural, limbajul procedural şi un limbaj

neprocedural, să considerăm tabela ANGAJATI cu structura:
ANGAJATI [IDangajat, nume, CNP, localitate, cod_loc_munca, cod_functie]

şi următorul exemplu:
1. În limbaj natural: “Să se selecteze angajaţii care au domiciliul în Braşov”
2. În limbaj neprocedural (SQL):

SELECT nume
FROM angajati
WHERE localitate = ‘Brasov’
3. În limbaj procedural (algoritmic):

INIT angajati
WHILE NOT EOF(angajati)
DO BEGIN
READ angajati
IF localitate = ‘Brasov’
THEN WRITE nume
END IF
END
CLOSE angajati
STOP
Observăm că în limbaj procedural trebuie să precizăm CUM obţinem lista angajaţilor

care au domiciliul în Braşov. Algoritmul prezentat presupune pregătirea fişierului
angajati pentru consultare (INIT) şi apoi parcurgerea secvenţială a articolelor fişierului.
După citirea fiecărui articol, se verifică condiţia localitate = ‘Brasov’ şi dacă este
86 Baze de date
adevărată se listează numele angajatului. După “atingerea” marcajului de sfârşit de fişier

(EOF – End Of File) fişierul va fi închis până la o viitoare consultare (CLOSE).
În limbaj neprocedural (SQL) am formulat numai CE dorim să obţinem, precizând

atributul care ne interesează (nume), unde se află această informaţie (fişierul angajaţi) şi
ce condiţie trebuie îndeplinită (localitate = ‘Brasov’).
Pe lângă versiunile standardizate ale limbajului SQL, există şi o mulţime de dialecte şi

variante caracteristice diferitelor SGBD-uri.
Limbajul SQL permite:

 descrierea structurii datelor;
 modificarea structurii datelor;
 interogarea bazelor de date;
 actualizarea datelor.
Pentru prezentarea sintaxei limbajului neprocedural SQL se folosesc următoarele

elemente de metalimbaj:
*…+ - conţinutul cuprins între parantezele pătrate este opţional;
,…- - conţinutul cuprins între parantezele acolade este obligatoriu;
| - bara verticală separă elementele cuprinse între paranteze drepte sau
acolade; numai unul din elemente separate prin bara verticală poate
fi introdus în instrucţiune;
*…n] - arată că elementul precedent cuprins între paranteze drepte se poate
repeta de mai multe ori; în această situaţie, elementele se despart prin
virgulă.
4.2. DESCRIEREA ŞI MODIFICAREA STRUCTURII DATELOR

4.2.1. CREAREA UNEI TABELE
Instrucţiunea CREATE TABLE este utilizată pentru a crea o nouă tabelă. Această
comandă este utilizată cu precădere dacă mediul de lucru nu posedă instrumente
pentru crearea şi modificarea tabelelor într-o manieră mai facilă, aşa cum are spre
exemplu Microsoft Access.
Sintaxa generală a instrucţiunii CREATE TABLE este:
CREATE TABLE nume_tabela (col1 dom1 [constrângeri_coloană],

col2 dom2 [constrângeri_coloană],
...
coln domn [constrângeri_coloană]);
Limbajul SQL 87
unde: col1, col2, ... , coln - reprezintă atributele (coloanele) tabelei

dom1, dom2, ... , domn - reprezintă domeniile fiecărui câmp (atribut)
constrângeri_coloană - este un parametru opţional care specifică alte
constrângeri de integritate, ca:
 NOT NULL – precizează că valorile corespunzătoare atributului nu pot fi de tip null;
 PRIMARY KEY – precizează că atributul specificat va fi cheie primară;
 FOREIGN KEY – indică necesitatea ca fiecare valoare din coloana precizată să existe
într-o coloană corespondentă din tabela referită; această
constrângere face referire doar la coloane care sunt PRIMARY KEY
sau UNIQUE în tabela referită;
 DEFAULT – impune o valoare implicită pentru un atribut.
Exemplul 1. Dacă dorim crearea unei tabele cu numele ANGAJATI1, cu următoarele

câmpuri:
vom avea:
CREATE TABLE angajati1 (id_angajat int,

nume varchar(250),
adresa varchar (250),
localitate varchar(250),
sal_brut int,
id_dep varchar (10),
data_angajarii date);
Rezultatul afişat pentru exemplul 1
4.2.2. MODIFICAREA STRUCTURII TABELEI
Pentru modificarea structurii unei tabele se utilizează instrucţiunea ALTER TABLE.

Această instrucţiune permite adăugarea sau ştergerea unor câmpuri, modificarea
88 Baze de date
domeniilor unor câmpuri, precum şi adăugarea sau ştergerea unor constrângeri ale
tabelei.
Instrucţiunea ALTER TABLE are următoarele sintaxe:

 pentru adăugarea unui nou câmp:
ALTER TABLE nume_tabela ADD nume_coloană domeniu;
O nouă coloană adaugată prin această comandă va avea valoarea null în toate
înregistrările care existau în tabelă.
 pentru ştergerea unui câmp:
ALTER TABLE nume_tabela DROP nume_coloană;
 pentru modificarea constrângerilor unui câmp:
ALTER TABLE nume_tabela
ALTER COLUMN nume_coloană domeniu;
Exemplul 2. Pentru a adăuga în tabela ANGAJATI1 un câmp nou, numit bonus, de tip
integer vom avea:
ALTER TABLE angajati1 ADD bonus int;
Exemplul 3. Modificarea în tabela ANGAJATI1 a câmpului bonus din integer în varchar cu

lungimea maximă de 10 caractere se face astfel:
ALTER TABLE angajati1 ALTER COLUMN bonus varchar(10);

Limbajul SQL 89
Exemplul 4. Dacă dorim ştergerea din tabela ANGAJATI1 a câmpului numit bonus vom
avea:
ALTER TABLE angajati1

DROP bonus;
4.2.3. ŞTERGEREA UNEI TABELE
Pentru ştergerea unei tabele se utilizează instrucţiunea DROP TABLE. Această

instrucţiune va face ştergerea efectivă a întregii tabele cu toate datele conţinute.
Sintaxa generală a instrucţiunii DROP TABLE este:
DROP TABLE nume_tabela;

90 Baze de date
Exemplul 5. Dacă dorim ştergerea tabelei ANGAJATI1 vom avea:
DROP TABLE angajati1;
4.3. REALIZAREA INTEROGĂRILOR
SELECT este instrucţiunea de interogare a datelor din limbajul SQL. Utilizarea acestei
instrucţiuni generează o tabelă virtuală, numită vedere (view, query). În query se
regăsesc toate informaţiile dorite din una sau mai multe tabele ale bazei de date. Un
query se recrează de fiecare dată când este apelat, pe baza definiţiei stocate în baza de
date.
Sintaxa generală a instrucţiunii SELECT este:
SELECT [DISTINCT] col1, col2, ... , coln

FROM tab1, tab2, ... , tabm
[WHERE condiţie]
[GROUP BY coloana1, coloana2….]
[HAVING conditie_de_grup]
[ORDER BY coloana1 *ASC|DESC+,…+
unde: col1, col2, ... , coln – sunt coloanele (atributele) dorite din tabelele specificate în
clauza FROM;
tab1, tab2, ... , tabm - sunt tabelele din care se face selecţia.
Clauza SELECT defineşte coloanele tabelei rezultat. Rezultatul selecţiei este format din
coloanele col1, col2, ... , coln cu datele rezultate din produsul cartezian al tabelelor tab1,
tab2, ... ,tabm pentru care se respectă eventuala condiţie specificată în clauza WHERE.
Observăm că doar clauzele SELECT şi FROM sunt obligatorii, celelalte reprezentând
opţiuni.
În termenii algebrei relaţionale, clauzele SELECT şi FROM realizează produsul cartezian al
mai multor tabele, urmat de o proiecţie pe coloanele (atributele) dorite din tabelele
specificate. Următoarele secvenţele sunt echivalente:
SELECT col1, col2, ... , coln R1 = PRODUCT (tab1, tab2, ... , tabm)
FROM tab1, tab2, ... , tabm R2 = PROJECT (col1, col2, ... , coln)
Exemplele următoare vor fi construite pentru tabelele ANGAJATI si DEPARTAMENTE:

Limbajul SQL 91
Tabela ANGAJATI
Tabela DEPARTAMENTE
Exemplul 6. Dacă dorim afişarea tuturor datelor din tabelă vom avea:
SELECT id_angajat, nume, adresa, localitate, sal_brut, id_dep, data_angajarii

FROM angajati;
sau
SELECT * FROM angajati;
Observaţie. În cazul al doilea, simbolul * afişează toate câmpurile din tabelă.
Exemplul 7. Dacă dorim afişarea tuturor angajaţilor din localitatea Braşov care au salariul
mai mare de 1500 vom avea:
SELECT id_angajat, nume, localitate, sal_brut

FROM angajati
WHERE localitate="brasov" AND sal_brut>1500;

92 Baze de date
Exemplul 8. Dacă dorim afişarea tuturor persoanelor angajate după data de 01.01.2015,
vom avea:
SELECT id_angajat, nume, data_angajarii

FROM angajati
WHERE data_angajarii>=#01-01-2015#;
În clauza SELECT se pot utiliza următoarele funcţii agregat:

 COUNT - numără liniile din tabela rezultat
 SUM - calculează suma valorilor dintr-o coloană
 MAX - returnează valoarea maximă dintr-o coloană
 MIN - returnează valoarea minimă dintr-o coloană
 AVG - returnează media aritmetică a valorilor dintr-o coloană.
Exemplul 9. Dacă dorim afişarea numărului de angajaţi vom avea:
SELECT count(*)
FROM angajati;
Exemplul 10. Dacă dorim afişarea mediei aritmetice a salariului brut vom avea:
SELECT AVG(sal_brut)
FROM angajati;

Limbajul SQL 93
Observaţie. În instrucţiunea SELECT poate să nu apară clauza FROM, dacă datele nu sunt
conţinute de nicio tabelă. În acest caz, instrucţiunea SELECT conţine o listă de expresii pe
care le calculează.
Exemplul 11. Dacă dorim afişarea rezultatului produsului 50x25 vom avea:
SELECT 50*25;
Dacă se doreşte, în tabela rezultat se pot redenumi coloanele sau se pot denumi
anumite expresii, utilizând clauza AS.
Exemplul 12. Dacă dorim afişarea rezultatului produsului 50x25, iar numele tabelei să fie
REZULTAT vom avea:
SELECT 50*25 AS rezultat;
Clauza FROM este obligatorie, dacă în clauza SELECT se doreşte afişarea unor coloane
din tabele. Dacă se doreşte selectarea unor coloane din tabele diferite, acestea vor fi
toate enumerate în clauza FROM, despărţite prin virgulă. În cazul în care numele unui
câmp apare în mai multe tabele, atunci pentru a se cunoaşte din ce tabelă se doreşte
respectivul câmp, în clauza FROM, calificarea câmpului se va face prin specificarea
numelui tabelei, de forma:
nume_tabelă.nume_câmp
În clauza WHERE se specifică toate condiţiile necesare pentru datele din tabela rezultat.
În clauza WHERE se pot utiliza şi operatori logici (AND, OR, NOT) şi paranteze.
Exemplul 13. Dacă dorim afişarea angajaţilor din Brasov sau Predeal vom avea:
SELECT nume, localitate

FROM angajati
WHERE localitate="Brasov" or localitate="Predeal";
94 Baze de date
Clauza ORDER BY face ordonarea liniilor din tabela rezultat după coloana ce urmează
clauzei. Implicit, ordonarea se face în ordine crescătoare sau alfabetică (ordinea
lexicografică), dacă tipul câmpului după care se face ordonarea este de tip text. În cazul
în care se doreşte ordonare invers lexicografică (descrescătoare), atunci numele
coloanei trebuie urmat de cuvântul DESC.
Exemplul 14. Dacă dorim afişarea angajaţilor în ordine descrescătoare vom avea:
SELECT nume
FROM angajati
ORDER BY nume DESC;
Clauza GROUP BY se utilizează pentru gruparea rezultatelor funcţiilor agregat, în funcţie

de valoarea unei sau mai multor coloane.
Clauza GROUP BY se utilizează la sfârşitul instrucţiunii, fiind urmată de câmpul pentru
care se face gruparea rezultatelor funcţiei agregat.
Limbajul SQL 95
Exemplul 15. Dacă dorim numărul de angajaţi din fiecare localitate vom avea:
SELECT COUNT(*) AS numar, localitate

FROM angajati
GROUP BY localitate;
Clauza HAVING se utilizează în loc de clauza WHERE, atunci când în instrucţiune se

utilizează funcţii agregat. Clauza HAVING este asemănătoare clauzei WHERE, adică
introduce o condiţie pe care trebuie să o respecte liniile din tabela rezultat şi în plus
permite utilizarea funcţiilor agregat în expresia condiţională.
Exemplul 16. Dacă dorim numărul de angajaţi din Braşov şi Predeal vom avea:
SELECT COUNT(*) AS numar, localitate

FROM angajati
GROUP BY localitate
HAVING localitate="Brasov" OR localitate="Predeal";
Subinterogările reprezintă instrucţiuni SELECT în alte interogări de tip SELECT. Numim

această tehnică imbricare. Astfel, instrucţiunile SELECT se pot imbrica pe mai multe
niveluri, o instrucţiune având ca argument rezultatul unei alte instrucţiuni, numită şi
subinterogare.
Exemplul 17. Dacă dorim numele angajatului care are salariul egal cu salariul maxim vom
avea:
96 Baze de date
SELECT nume, sal_brut

FROM angajati
WHERE sal_brut IN
(SELECT MAX(sal_brut) FROM angajati);
Clauzele IN şi NOT IN specifică dacă valorile unui câmp aparţin sau nu, unei mulţimi
precizate. Această mulţime poate fi formată prin enumerarea elementelor sau printr-o
subinterogare.
Exemplul 18. Dacă dorim numele angajaţilor din Brasov, Bucuresti şi Predeal vom avea:
SELECT nume, localitate

FROM angajati
WHERE localitate IN ("Brasov", "Bucuresti", "Predeal");
Interogări care necesită joncţiuni de tabele

Exemplele prezentate până acum au ca sursă de date o singură tabelă. În general,
interogările complexe presupun extragerea informaţiilor din mai multe tabele legate
prin condiţii de joncţiune definite pe atributele (coloanele) diferitelor tabele. În mod
uzual, joncţiunile se realizează între atributele din două tabele ce definesc legături de
tipul cheie externă – cheie primară. Condiţia de joncţiune cea mai utilizată este
egalitatea (=).
Limbajul SQL 97
Sintaxa:
SELECT [domeniu] lista_de_selecţie
FROM tabela1
{ INNER | LEFT [OUTER] | RIGHT [OUTER] } JOIN tabela2
ON condiţie_joncţiune
[WHERE listă_criterii_selecţie];
unde:
lista_de_selectie := { * | nume_atribut [ AS alias] | expresie [ AS alias + - *,… n]
domeniu := { [ ALL | DISTINCT ] [ TOP n [ PERCENT] ] }
condiţie_joncţiune – defineşte legătura dintre atributele diferitelor tabele; în situaţia
unor nume identice de atribute în două tabele distincte, calificarea se va
face cu numele tabelei, de exemplu: tabela1.atribut1; condiţiile de
joncţiune pot fi exprimate prin comparaţii ( <, <=, =, >, >=, <> ) sau
apartenenţă (BETWEEN, IN, NOT IN, LIKE) la un interval sau la valorile
unui atribut dintr-o altă tabelă;
listă_criterii_selecţie – specifică eventuale filtre asupra înregistrărilor (liniilor, tuplurilor)
generate prin procesul de joncţiune.
INNER JOIN – extrage liniile corespondente ce rezultă din condiţia de joncţiune a celor
două tabele;
LEFT JOIN – extrage liniile corespondente ce rezultă din condiţia de joncţiune a celor
două tabele, la care se adaugă liniile care nu au participat la joncţiune din
tabela aflată în partea stângă a operaţiei de joncţiune; specificaţia OUTER
este opţională;
RIGHT JOIN – extrage liniile corespondente ce rezultă din condiţia de joncţiune a celor
două tabele, la care se adaugă liniile care nu au participat la joncţiune din
tabela aflată în partea dreaptă a operaţiei de joncţiune; specificaţia
OUTER este opţională;
FULL JOIN – pentru a evita pierderea de informaţie în urma procesului de joncţiune,
se adaugă în tabela rezultată liniile care nu au participat la joncţiune din
ambele tabele implicate în operaţia de joncţiune; este o combinație între
LEFT JOIN și RIGHT JOIN şi corespunde joncţiunii externe (OUTER JOIN)
prezentată la algebra relaţională.
Observaţie
Operaţia de joncţiune INNER JOIN poate fi simulată prin operaţia de produs cartezian
(FROM) urmată de o selecţie (WHERE). Astfel, sintaxele următoare sunt echivalente:

FROM tabela1 INNER JOIN tabela2
ON condiţie_joncţiune
[WHERE listă_criterii_selecţie];

FROM tabela1, tabela2
WHERE condiţie_joncţiune [ AND listă_criterii_selecţie];
98 Baze de date
Exemplul 19. Dacă dorim numele angajaţilor împreuna cu denumirea completă a

departamentului vom avea:
SELECT nume, denumire
FROM angajati INNER JOIN departamente
ON angajati.id_dep=departamente.id_dep;
sau echivalent:
FROM angajati, departamente
WHERE angajati.id_dep=departamente.id_dep;
Exemplul 20. Dacă dorim numele angajaţilor împreună cu denumirea completă a

departamentului, inclusiv a celor care nu au un id_dep, vom avea:
- pentru exemplificare, introducem angajatul MIHAI care nu are nici o valoare la câmpul
id_dep
Introducerea angajatului MIHAI fără id_dep

FROM angajati LEFT JOIN departamente
ON angajati.id_dep=departamente.id_dep;
Limbajul SQL 99
Exemplul 21. Dacă dorim numele şefului pentru fiecare departament:
SELECT angajati.nume AS nume_sef, departamente.id_dep

WHERE angajati.id_dep=departamente.id_dep
AND
departamente.id_sef=id_angajat;
Exemplul 22. Dacă dorim numele şefului pentru fiecare angajat:
SELECT id_angajat, angajati.nume, tmp1.id_sef, tmp1.nume_sef

FROM angajati,
(SELECT angajati.nume AS nume_sef, departamente.id_dep
AND departamente.id_sef=id_angajat) AS tmp1
WHERE angajati.id_dep=tmp1.id_dep;
100 Baze de date
Observaţie. În rezultatul afişat apar toate numele angajaţilor, inclusiv ale şefilor, de
exemplu Maria (id_angajat = 13) este singură în departament şi este şefă (id_sef = 13).
Dacă dorim să nu mai apară în lista angajaţilor şefii departamentelor, interogarea

devine:
SELECT angajati.id_angajat, angajati.nume, tmp1.id_sef, tmp1.nume_sef

FROM angajati,
(SELECT angajati.nume AS nume_sef, departamente.id_sef,
departamente.id_dep
AND departamente.id_sef=id_angajat) AS tmp1
WHERE angajati.id_dep=tmp1.id_dep
AND angajati.id_angajat<>tmp1.id_sef;
Rezultatul afişat pentru exemplul 22 (modificat)

Limbajul SQL 101
4.4. ACTUALIZAREA DATELOR

4.4.1. INTRODUCEREA DATELOR ÎN TABELĂ
Instrucţiunea INSERT este utilizată pentru introducerea datelor în tabelă. Instrucţiunea

INSERT are următoarea sintaxă:
INSERT INTO nume_tabela (col1, col2, ... , coln) VALUES (val1,val2,..., valn);
unde:
col1, col2, ... , coln - reprezintă atributele (coloanele) tabelei în care se vor introduce
datele;
val1,val2,..., valn - reprezintă valorile corespunzătoare coloanelor col1, col2, ... , coln.
Observaţie. Între valori şi numele coloanelor trebuie să existe o corespondenţă

biunivocă.
Exemplul 23. Dacă dorim introducerea în tabela ANGAJAŢI a unui nou angajat cu datele:
18, EMILIA, str. O.Goga nr. 3, bucuresti, 1300, prod, 05.05.2009

vom avea:
INSERT INTO angajati

VALUES (18, "EMILIA", "str. O.Goga nr. 3", " Bucuresti", 1800,
" prod", #5/5/2014#);
Dacă se doreşte introducerea datelor în altă ordine decât cea implicită a coloanelor din
tabelă sau nu se cunoaşte această ordine, trebuie specificată ordinea câmpurilor după
numele tabelei.
Exemplul 24. Dacă dorim introducerea în tabela ANGAJAŢI a unui nou angajat cu datele:
19, str. Agriselor, Constanta, RALUCA, 1600, prod, 10.08..2015

102 Baze de date
vom avea:
INSERT INTO angajati (id_angajat, adresa, localitate, nume, sal_brut,
id_dep, data_angajarii)
VALUES (19, "str. Agriselor nr. 3", " Constanta", "RALUCA", 1600,
" prod", #10/8/2015#);
4.4.2. MODIFICAREA VALORILOR DIN COLOANELE UNEI TABELE
Instrucţiunea UPDATE permite modificarea valorilor din coloanele unei tabele pentru
anumite condiţii. Sintaxa generală este:
UPDATE nume_tabela SET col1=val1 [col2=val2 , ... , coln=valn] [WHERE condiţie]

Clauza WHERE impune ca actualizarea valorilor să se facă doar asupra liniilor care
îndeplinesc o serie de condiţii. Dacă lipseşte clauza WHERE, se vor modifica toate liniile
din tabelă.
Exemplul 25. Dacă dorim modificarea tuturor salariilor angajaţilor din departamentul
"prod" la valoarea de 1000 lei vom avea:
UPDATE angajati
SET sal_brut=2000
WHERE id_dep="prod";

Limbajul SQL 103
Valoarea poate fi schimbată şi cu valoarea unei expresii calculate.
Exemplul 26. Dacă dorim modificarea tuturor salariilor angajaţilor din departamentul
"conta" printr-o creştere cu 15% vom avea:
UPDATE angajati
SET sal_brut=sal_brut*115/100
WHERE id_dep="conta";
4.4.3. ŞTERGEREA UNEI LINII DINTR-O TABELĂ
Instrucţiunea DELETE este utilizată pentru ştergerea uneia sau a mai multor linii dintr-o
tabelă.
Sintaxa instrucţiunii DELETE este:
DELETE FROM nume_tabela [WHERE condiţie];
Utilizând această instrucţiune se vor şterge toate liniile care îndeplinesc condiţia
specificată în clauza WHERE. Dacă este omisă clauza WHERE se vor şterge toate liniile
din tabelă.
Exemplul 27. Dacă dorim ştergerea tuturor angajaţilor din departamentul "conta" vom
avea:
DELETE FROM angajati

WHERE id_dep="conta"
104 Baze de date
4.5. IMPLEMENTAREA OPERATORILOR RELAŢIONALI ÎN SQL
Implementarea operatorilor algebrei relaţionale se realizează în limbajul SQL, în general,

cu ajutorul instrucţiunii de interogare SELECT. Prezentăm modul de implementare în SQL
Access a operatorilor algebrei relaţionale, prin reluarea unor exemple utilizate în
capitolul 3.
Reuniunea R3 = UNION (R1, R2)
a b d f a b
c d x y c d
x y h r x y
c d d f
h r
Soluţia 1.
(1) SELECT R1.* INTO R3 FROM R1;
(2) INSERT INTO R3 SELECT R2.* FROM R2;
(3) SELECT * FROM R3;
Limbajul SQL 105
Comentariu. Reuniunea se realizează prin două cereri:

(1) prima cerere de tip make-table crează o nouă tabelă R3;
(2) se adaugă în tabela creată anterior tabela R2;
(3) se listează tabela R3.
Observăm că elementele (liniile) duplicate nu au fost eliminate. Eliminarea se poate face

prin: (3’) SELECT DISTINCT * FROM R3;
Soluţia 2.
(1) SELECT * INTO R3
FROM (SELECT * FROM R1 UNION SELECT * FROM R2);
Comentariu. Reuniunea se realizează:
(1) cu ajutorul lui UNION şi se crează tabela R3 care nu conţine elemente duplicate;
(2) se listează tabela R3.
Soluţia 3.
(1) SELECT * FROM R1 UNION SELECT * FROM R2;
Comentariu. Reuniunea se realizează cu ajutorul lui UNION prin generarea unei tabele
virtuale (query) care nu conţine elemente (linii, tupluri) duplicate:
106 Baze de date
Diferenţa R3 = DIFFERENCE (R1, R2)
a b d f a b
c d x y
x y h r
c d
Soluţia 1.
(1) SELECT DISTINCT R1.*
FROM R1 LEFT JOIN R2 ON R1.A=R2.A
WHERE R2.A IS NULL;
Soluţia 2.
(1) SELECT DISTINCT R1.*
FROM R1
WHERE R1.A NOT IN (SELECT A FROM R2);
Comentariu. În ambele soluţii se consideră că atributul A este cheie primară în R1 şi în

R2. Altfel spus, dacă există tuplul <c, d> în R1, valoarea c a atributului A în R2 nu poate
apare decât în tuplul <c, d>.
Intersecţia R3 = INTERSECT (R1, R2)
a b d f c d
c d x y x y
x y h r
c d
Soluţia 1.
(1) SELECT tmp.* INTO R3
FROM [SELECT R1.* FROM R1 INNER JOIN R2 ON R1.A=R2.A]. AS tmp;
Comentariu. Se generează o tabelă virtuală tmp, ca rezultat al joncţiunii naturale a
relaţiilor R1 şi R2 pe atributul A (atribut cheie). Tabela tmp va fi memorată în R3. În final
tabela R3 este listată.
Limbajul SQL 107
Soluţia 2.
(1) SELECT R1.* from R1, R2
WHERE R1.A=R2.A AND R1.B=R2.B;
Comentariu. Se generează un query care va conţine tuplurile comune selectate din
produsul cartezian R1 x R2.
Produsul cartezian R3 = PRODUCT (R1, R2)
R1 A B R2 A R3 R1. A B R2.A
a b a a b a
c d d c d a
x y x y a
a b d
c d d
x y d
Soluţia 1.
(1) SELECT R1.A, B, R2.A FROM R1, R2;
Soluţia 2.
(1) SELECT R1.A, B, R2.A INTO R3
FROM R1, R2;
108 Baze de date
Comentariu. Soluţia 1 generează o tabelă virtuală (query), iar în soluţia 2 rezultatul

produsului cartezian este memorat în R3. În final, tabela R3 este listată.
Selecţia S = SELECT ( R; B = ’x’)
R A B C S A B C
x y z t x a
t x a z x b
z x b
c u w
Soluţia.
(1) SELECT * FROM R WHERE R.B=’x’;
Proiecţia P = PROJECT ( R; A,C )
R A B C P’ A C P A C
x u x x x x x
z x y z y z y
x z x x x
z y y z y
x t x x x
Soluţia.
(1) SELECT distinct R.A, R.C FROM R;
Limbajul SQL 109
Jonctiunea THETA-JOIN R3 = THETA - JOIN ( R1, R2; R1.A > R2.A )
a x c 0 11 a b y c 0 11 a
b y c 1 13 a b y c 1 13 a
d z a 3 11 a b y c 3 11 a
4 11 d d z a 0 11 a
6 12 d d z a 1 13 a
7 13 c d z a 3 11 a
d z a 7 13 c
Soluţia 1.
(1) SELECT R1.A, B, C, D, E, R2.A INTO R3
FROM R1, R2 WHERE R1.A>R2.A;
Soluţia 2.
(1) SELECT R1.A, B, C, D, E, R2.A INTO R3
FROM R1 INNER JOIN R2 ON R1.A>R2.A;
Comentariu. În soluţia 1 joncţiunea este realizată prin produs cartezian urmat de o

selecţie. Rezultatul este memorat în tabela R3, care apoi este listată.
În soluţia 2 este generată utilizând instrucţiunea de joncţiune, o tabelă virtuală (query).
110 Baze de date
Joncţiunea LEFT OUTER-JOIN R3 = LEFT OUTER-JOIN (R1, R2; A)
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
Soluţia.
(1) SELECT R1.*, D, E INTO R3
FROM R1 LEFT JOIN R2 ON R1.A = R2.A;
Jonctiunea RIGHT OUTER-JOIN R3 = RIGHT OUTER-JOIN (R1, R2; A)
a x c 0 11 a a x c 0 11
b y c 1 13 a a x c 1 13
d z a 3 11 a a x c 3 11
4 11 d d z a 4 11
6 12 d d z a 6 12
7 13 c c null null 7 13
Soluţia.
(1) SELECT R2.A, B, C, D, E INTO R3
FROM R1 RIGHT JOIN R2 ON R1.A = R2.A;
NORMALIZAREA RELAŢIILOR (2)
5.2. A DOUA FORMĂ NORMALĂ (2NF)
Definiţia 5.11. O relaţie este în a doua formă normală notată (2NF), dacă şi numai dacă:
 relaţia este în 1NF şi
 oricare dintre atributele care nu aparţine cheii primare este complet dependent
funcţional de cheie (nu depinde de o parte a cheii).
Observaţie. O relaţie în 2NF nu conţine dependenţe funcţionale parţiale între atributele

cheie şi celelate atribute.
Exemplu. Redundanţe care apar în cazul unei relaţii 1NF, care nu este 2NF.
Fie R [A, B, C, D] în care cheia primară este (A, B) şi se manifestă dependenţele:
(A, B) → C (A, B) → D B→C

A B C D
a1 b1 c1 d1
a2 b1 c1 d2
a3 b2 c3 d2
a4 b2 c3 d3
Teorema 5.2. (Teorema de descompunere fără pierdere de informaţie)

Fie R [A1, A2, ..., An] o relaţie în 1NF şi K = {A1, A2, ..., Ap} cu p < n este o cheie primară.
Presupunem că există   A  A1 , A2 ,..., An ,   K   , adică  este un atribut
noncheie şi    cu   K (  este complet dependent funcţional de o submulţime
strictă de atribute din cheie). Atunci dependenţa    se poate elimina
descompunând relaţia R în următoarele două relaţii:
R1        R 
R2 A      A R 
Observaţie. Conform teoremei de mai sus, relaţia R [A, B, C, D] din exemplul precedent,
în care se manifestă (conform definiţiei 5.3) dependenţa parţială (A, B) → C cu
dependenţa argument dfp B → C, se poate descompune fără pierdere de informaţie în:
R1 [ B, C] şi R2 [A, B, D]
1
Algoritmul 2NF - de aducere a unei relaţii 1NF în 2NF
(eliminarea dependenţelor funcţionale parţiale)
Pasul 1. Pentru fiecare dependenţă funcţională argument dfp se crează o nouă relaţie,
cu schema constituită din determinantul şi determinatul acestei dependenţe.
Dacă există mai multe dependenţe funcţionale argument dfp cu acelaşi
determinant se va crea o singură relaţie formată din determinant luat o singură
dată şi determinaţii dependenţelor considerate.
Pasul 2. Din relaţia iniţială se elimină atributul / atributele care formează determinatul
dependenţelor funcţionale argument dfp.
Pasul 3. Se stabileşte cheia primară a fiecărei noi relaţii create la Pasul 1. Aceasta va fi
formată din determinantul dependenţei funcţionale argument dfp.
Aplicaţie.
Pentru evidenţa autoturismelor închiriate de o firmă se consideră următoarea relaţie:
AUTO [ IDclient, nume_client, adresa, nr_auto, marca, data ]
Exemplificăm relaţia (tabela) AUTO prin popularea ei cu cinci tupluri (linii):
IDclient Nume client Adresa Nr auto Marca Data

C234 Smith A Castelului 12, BV 21 XXI Logan 1.4 22.05.2015
Brasov
C145 Lungu M Libertatii 14, BV 19 XIX Ford Focus 17.04.2016
Predeal
C679 Tudor A Armoniei 23, CJ 12 XII Audi A6 23.05.2016
Iasi
C089 Stan D Cosbuc 45, CT 07 VII Opel Astra 07.04.2014
Cluj
C445 Bondescu I Caragiale 66, BV 61 LXI VW Golf 26.04.2015
Arad
Cheia relaţiei este (IDclient, nr_auto), iar dependeţele funcţionale care se manifestă
sunt:
(1) (IDclient, nr_auto) → nume_client

(2) (IDclient, nr_auto) → adresa
(3) (IDclient, nr_auto) → marca
(4) (IDclient, nr_auto) → data
(5) IDclient → nume_client
(6) IDclient → adresa
(7) nr_auto → marca
2
Observaţie.
 relaţia AUTO este în forma normală 1;
 dependenţa funcţională (1) este parţială deoarece se manifestă şi dependenţa
funcţională argument dfp (5);
funcţională argument dfp (6);
funcţională argument dfp (7).
Aplicarea Algoritmului 2NF - de aducere a unei relaţii 1NF în 2NF, bazat pe Teorema 2,
conduce la spargerea relaţiei AUTO, în trei relaţii în 2NF:
EVIDENTA [ IDclient, nr_auto, data ]

CLIENT [ IDclient, nume_client, adresa ]
AUTO [ nr_auto, marca ]
EVIDENŢA
IDclient Nr auto Data
C234 BV 21 XXI 22.05.2015
C145 BV 19 XIX 17.04.2016
C679 CJ 12 XII 23.05.2016
C089 CT 07 VII 07.04.2014
C445 BV 61 LXI 26.04.2015
CLIENT
IDclient Nume client Adresa
C234 Smith A Castelului 12, Brasov
C145 Lungu M Libertatii 14, Predeal
C679 Tudor A Armoniei 23, Iasi
C089 Stan D Cosbuc 45, Cluj
C445 Bondescu I Caragiale 66, Arad
AUTO
Nr auto Marca
BV 21 XXI Logan 1.4
BV 19 XIX Ford Focus
CJ 12 XII Audi A6
CT 07 VII Opel Astra
BV 61 LXI VW Golf
3
5.3. A TREIA FORMĂ NORMALĂ (3NF)
Definiţia 5.12. O relaţie este în a treia formă normală notată (3NF)dacă:

 relaţia este în 2NF şi
 orice atribut care nu aparţine cheii primare nu depinde tranzitiv de cheie.
Observaţie. O altă exprimare: orice atribut ce nu aparţine cheii primare depinde direct
de cheie.
Fie R o relaţie, K cheia primară şi presupunem că β este un atribut ce depinde tranzitiv

de cheie. Aceasta înseamnă că există un atribut α, astfel încât există dependenţele
funcţionale:
K   şi   
Deoarece relaţia R este în 2NF rezultă că  este complet dependent funcţional de cheia
relaţiei şi deci K     , adică  este un atribut noncheie.
Exemplu. Redundanţe care apar în cazul unei relaţii 2NF, care nu este 3NF.
Fie R [A, B, C] în care cheia primară este A şi se manifestă dependenţele:
A→B A→C B→C
A B C
a1 b1 c1
a2 b1 c1
a3 b2 c2
a4 b2 c2
Teorema 5.3. (Teorema lui Casey – Delobel, de descompunere fără pierdere de

informaţie)
Fie R [A1, A2, ..., An] o relaţie în 2NF şi K este o cheie primară. Dacă există atributul
  A  A1 , A2 ,..., An,   K   , şi    cu   K (  depinde tranzitiv de cheie),
atunci dependenţa    se poate elimina descompunând relaţia R în următoarele
două relaţii:
R1        R 
R2 A      A R 
4
Observaţie. Conform teoremei de mai sus, relaţia R [A, B, C] din exemplul precedent, în
care se manifestă dependenţa tranzitivă B → C se descompune fără pierdere de
informaţie în:
R1 [B, C] şi R2 [ A, B]
Algoritmul 3NF - de aducere a unei relaţii 2NF în 3NF

(eliminarea dependenţelor funcţionale tranzitive)
Pasul 1. Pentru fiecare dependenţă funcţională tranzitivă din cadrul relaţiei considerate,
se crează o nouă relaţie, formată din atributele implicate în această dependenţă.
Pasul 2. Se stabileşte cheia primară a fiecărei noi relaţii create la Pasul 1.
Pasul 3. Se introduc în relaţia iniţială în locul atributelor transferate la Pasul 1, cheile
primare determinate la Pasul 2.
Aplicaţie.
Pentru evidenţa rezultatelor examenului de licenţă, se consideră relaţia:
EXAMEN [nr_matricol, nume_student, program_studiu, nota, prof_coordonator,

departament]
Exemplificăm relaţia (tabela) EXAMEN prin popularea ei cu cinci tupluri (linii):

Nr Nume Program Profesor
Nota Departament
matricol student studiu coordonator
2345 Ionescu M ECTS 9.45 Zamfir R MKTS
5678 Popescu V MK 9.30 Tiron A MKTS
7890 Lungu D CIG 9.70 Oancea C FBC
4567 Costin R FB 9.60 Cristea D FBC
3456 Marinescu H CIG 9.20 Andreescu M MNIE
Cheia relaţiei este nr_matricol, iar dependeţele funcţionale care se manifestă sunt:
(1) nr_matricol → nume_student

(2) nr_matricol → program_studii
(3) nr_matricol → nota
(4) nr_matricol → prof_coordonator
(5) nr_matricol → departament
(6) prof_coordonator → departament
Observaţie.
 relaţia EXAMEN este în 2NF, deoarece toate valorile atributelor sunt atomice, nu
avem atribute repetitive (1NF) şi nu există dependenţe funcţionale parţiale (2NF)
 dependenţele (4) şi (6) arată că atributul departament depinde tranzitiv de cheia
primară a relaţiei.
5
Grafic, această dependenţă tranzitivă poate fi exprimată astfel:
prof_coordonator
dependenţa
nr_matricol funcţională
tranzitivă
departament
Aplicarea Algoritmului 3NF - de aducere a unei relaţii 2NF în 3NF bazat pe Teorema 3,
conduce la spargerea relaţiei EXAMEN, în două relaţii în 3NF:
REZULTAT [nr_matricol, nume_student, program_studiu, nota, prof_coordonator]

PROFESOR [prof_coordonator, departament]
REZULTAT
Profesor
Nr matricol Nume student Program Nota
coordonator
2345 Ionescu M ECTS 9.45 Zamfir R
5678 Popescu V MK 9.30 Tiron A.
7890 Lungu D CIG 9.70 Oancea C
4567 Costin R FB 9.60 Cristea D
3456 Marinescu H CIG 9.20 Andreescu M
PROFESOR
Profesor Departament
coordinator
Zamfir R MKTS
Tiron A. MKTS
Oancea C FBC
Cristea D FBC
Andreescu M MNIE
6
Proprietăţile unei descompuneri în forma normală trei.
Dependenţele funcţionale sunt reguli invariabile în timp care trebuie verificate de
valorile atributelor din relaţie. Rezultă astfel necesitatea ca o descompunere să conserve
aceste reguli.
Altfel spus, dacă R1, R2 ,..., Rn este descompunerea relaţiei R, închiderea tranzitivă a
mulţimii F de dependenţe funcţionale (DF) a lui R trebuie să fie identică cu reuniunea
dependenţelor funcţionale a mulţimii de relaţii R1, R2 ,..., Rn.
A treia formă normală (3NF) este importantă, deoarece orice relaţie are cel puţin o
descompunere în forma normală trei cu următoarele proprietăţi:
 descompunerea conservă dependenţele funcţionale;
 descompunerea este fără pierdere de informaţie.
Rezumat asupra primelor trei forme normale

1NF toate atributele sunt atomice şi nu există atribute repetitive
2NF 1NF + orice atribut noncheie este complet dependent funcţional de cheie
(nu există dependenţe funcţionale parţiale)
3NF 2NF + atributele care nu aparţin cheii nu depind tranzitiv de cheie
(nu există dependenţe funcţionale tranzitive, adică nu există dependenţe
funcţionale între atributele noncheie)
5.4. FORMA NORMALĂ BOYCE – CODD (BCNF)
C. J. Date arată în *DAT05+ că definiţia iniţială a lui Codd pentru forma normală 3NF nu
tratează satisfăcător cazul general al unei relaţii care satisface simultan condiţiile:
1. are două sau mai multe chei candidate

2. o parte din cheile candidate sunt compuse (formate din mai multe atribute)
3. cheile compuse au atribute în comun.
Definiţia iniţială a formei 3NF a fost înlocuită de definiţia lui Boyce-Codd, în care este
luat în considerare şi acest caz. Reamintim că un determinant este un atribut sau grup
de atribute de care depinde funcţional un alt atribut al relaţiei (determinat). Cu alte
cuvinte, determinantul este o sursă de dependenţe funcţionale.
Definiţia 5.13. O relaţie este în forma normală Boyce-Codd notată (BCNF), dacă şi numai
dacă orice determinant este o cheie candidat.
Definiţia 5.13’. O relaţie este în forma normală Boyce-Codd notată (BCNF), dacă şi
numai dacă, pentru orice dependenţă funcţională totală A → B, A este o cheie a relaţiei.
Notă. Combinaţia condiţiilor 1,2 şi 3 nu apare foarte des în practică. Pentru o relaţie în
care nu apare, formele 3NF şi BCNF sunt echivalente.
7
Exemplu. Redundanţe care apar în cazul unei relaţii care nu este BCNF.
Fie R [A, B, C, D] în care cheia primară este (A,B) şi se manifestă dependenţele:

(A,B) → C (A,B) → D C→B
Relaţia nu este în forma normală Boyce-Codd, deoarece conform definiţiei 5.13, în
dependenţa C → B atributul C este un determinant care nu este o cheie candidat.
Relaţia R
A B C D
a1 b1 c1 d1
a2 b1 c1 d2
a1 b2 c2 d3
a1 b3 c3 d4
a2 b4 c4 d5
a3 b1 c5 d2
a2 b3 c6 d5
Relaţia R se descompune, pe baza dependenţei funcţionale C → B în BCNF în două

relaţii R1 [A, C, D+ şi R2 [C, B] , având cheile (A, C), respectiv (C, B).
Relaţia R1 Relaţia R2
A C D C B
a1 c1 d1 c1 b1
a2 c1 d2 c2 b2
a1 c2 d3 c3 b3
a1 c3 d4 c4 b4
a2 c4 d5 c5 b1
a3 c5 d2 c6 b3
a2 c6 d5
Algoritmul BCNF - de aducere a unei relaţii 3NF în BCNF

(eliminarea dependenţelor funcţionale noncheie) [POI01]
Pasul 1. Dacă relaţia conţine unul sau cel mult două atribute, nu pot exista dependenţe
noncheie şi deci relaţia este în BCNF.
Pasul 2. Dacă relaţia conţine mai mult de două atribute se caută dacă ea conţine
dependenţe noncheie. Dacă nu există dependenţe noncheie atunci relaţia este
în BCNF.
Pasul 3. Pentru fiecare dependenţă noncheie X → Y se crează două relaţii: una formată
din atributele {X,Y} implicate în această dependenţă, iar cealaltă va avea
schema formată din toate atributele relaţiei iniţiale, mai puţin Y.
Pasul 4. Se reiau paşii 1, 2, 3 pentru relaţiile rezultate la Pasul 3.
8
Observaţie. Pentru ca o relaţie să fie adusă în BCNF nu este obligatoriu să fie în 3NF. Se
pot aduce în BCNF şi relaţii aflate în 1NF şi 2NF deoarece dependenţele funcţionale
parţiale şi cele tranzitive sunt dependenţe noncheie, adică dependenţe funcţionale ale
căror determinanţi nu sunt chei candidat [POI96].
Aplicaţie.
Pentru organizarea activităţii într-o şcoală de muzică instrumentală să considerăm
relaţia:
SCOALA [nr_matricol, cod_instrument, marca_profesor]

şi următoarele reguli:
a) fiecare elev (identificat prin nr_matricol) are la un instrument pe care îl studiază
un singur profesor (identificat prin marca_profesor);
b) un profesor predă un instrument (identificat prin cod_instrument);
c) un elev poate să studieze mai multe instrumente.
Cheia relaţiei SCOALA este: (nr_matricol, cod_instrument).
SCOALA
nr_matricol cod_instrument marca_profesor
E29 I1 P1
E17 I1 P1
E53 I1 P3
E29 I2 P2
E17 I2 P2
E53 I2 P4
Pe baza regulilor definite constatăm următoarele dependenţe funcţionale:
(nr_matricol, cod_instrument) → marca_profesor (1)

marca_profesor → cod_instrument (2)
Comentarii.
1. Relaţia SCOALA este în 1NF deoarece atributele sale sunt atomice şi nu există
grupuri repetitive.
2. Nu avem dependenţe funcţionale parţiale, deci relaţia este 2NF.
3. Nu avem dependenţe funcţionale tranzitive, deci relaţia este 3NF.
4. La o analiză mai atentă identificăm şi cheia candidat:
(nr_matricol, marca_profesor).
9
Astfel, suntem în condiţiile definite de C.J.Date, în cazul unei relaţii care satisface
simultan condiţiile:
 are două chei candidate: (nr_matricol, cod_instrument), (nr_matricol,
marca_profesor)
 cele două chei candidate sunt compuse (formate din câte două atribute)
 cheile compuse au în comun atributul nr_matricol.
Relaţia SCOALA nu este BCNF, datorită dependenţei funcţionale (2), care ne arată că
există un determinant (marca_profesor) care nu este o cheie candidată.
Relaţia SCOALA prezintă redundanţă a datelor şi anomalii de actualizare:

- redundanţă: există mai multe tupluri care conţin o anumită valoare pentru
marca_profesor, deoarece mai mulţi elevi studiază cu acelaşi profesor; de fiecare dată
este înregistrat şi instrumentul (cod_instrument) pe care îl predă profesorul respectiv;
- anomalii de inserare: nu putem înregistra instrumentul (cod_instrument) pe care îl
predă un profesor, dacă nu există cel puţin un elev care studiază instrumentul
respectiv;
- anomalii de ştergere: dacă ştergem toate tuplurile elevilor care studiază un anumit
instrument vom pierde informaţia despre instrumentul predat de profesorii respectivi;
- anomalii de actualizare: dacă se modifică instrumentul predat de un anumit profesor,
atunci vor fi actualizate toate tuplurile care se referă la acel profesor.
Pentru a aduce relaţia SCOALA în BCNF se descompune relaţia în următoarele două
relaţii:
R1 [nr_matricol, marca_profesor]
R2 [marca_profesor, cod_instrument]
Relaţia R1 Relaţia R2
nr_matricol marca marca cod_instrument
profesor profesor
E29 P1 P1 I1
E17 P1 P2 I2
E53 P3 P3 I1
E29 P2 P4 I2
E17 P2
E53 P4
Descompunerea relaţiei SCOALA în R1 şi R2 se face fără pierdere de informaţie la

joncţiune, adică:
NATURAL–JOIN (R1, R2; marca_profesor) = SCOALA
Acest rezultat se demonstrează cu ajutorul Teoremei lui Ullman [ION04].
10
Teorema 5.4. (Teorema lui Ullman)
Descompunerea D = {R1, R2} a unei relaţii R este o descompunere fără pierdere de
informaţie la joncţiune în raport cu mulţimea F a dependenţelor funcţionale, dacă şi
numai dacă este îndeplinită una din condiţiile:
(a) R1  R2  R1  R2F  sau

(b) R1  R2  R2  R1F 
În cazul nostru, R1  R2  {marca_profesor}, R2 – R1 = {cod_instrument} şi există

dependenţa funcţională marca_profesor → cod_instrument, ceea ce demonstrează,
conform Teoremei lui Ullman, condiţia (b), că descompunerea relaţiei SCOALA în R1 şi R2
se face fără pierdere de informaţie la joncţiune.
5.7. DEPENDENŢE MULTIVALOARE. FORMA NORMALĂ PATRU (4NF)
Dependenţe multivaloare (MVD)

S-a constatat că forma normală BCNF nu este suficientă pentru eliminarea completă a
redundanţelor şi anomaliilor de actualizare.
De exemplu, presupunem că există o mulţime de avioane şi o mulţime de piloţi. Orice
pilot poate conduce orice avion pe orice zbor. Pentru orice zbor poate fi alocat orice
avion. Să considerăm următoarea relaţie:
ZBOR [numar_zbor, avion, pilot]

ZBOR NR_ZBOR AVION PILOT
102 AIRB320 Olteanu
102 B737 Ardeleanu
102 AIRB320 Ardeleanu
102 B737 Olteanu
109 AIRB320 Moldoveanu
118 B727 Ardeleanu
Acest exemplu arată insuficienţa noţiunii de dependenţă funcţională, care nu permite

sesizarea independenţei dintre atributele avion şi pilot. Pentru aceasta se generalizează
noţiunea de dependenţă funcţională prin aceea de dependenţă multivaloare (MVD).
Definiţia 5.14. Dependenţa multivaloare. Fie relaţia R  A1 , A2 ,..., An  şi X, Y două

mulţimi de atribute din R. Spunem că X  Y (Y depinde multivaloare de X, sau X
multidetermină pe Y), dacă fiind date valorile lui X există un ansamblu de valori Y
asociate şi acest ansamblu este independent de alte atribute Z  R  X  Y ale relaţiei R.
11
O altă definiţie mai puţin “fuzzy” pentru dependenţa multivaloare:
Definiţia 5.15. Fie relaţia R  A1 , A2 ,..., An  şi X, Y, Z trei mulţimi de atribute simple sau
compuse din R. Spunem că Y depinde multivaloare de X, sau X multidetermină pe Y dacă
şi numai dacă:
X Y    x , y , z  si  x , y' , z'  R  x , y' , z  si  x , y , z'  R
pentru orice valori x , y , y' , z , z' cu y  y' , z  z'.
Comentarii.
Din simetria definiţiei 5.15 rezultă că dependenţa multivaloare X  Y implică şi
dependenţa multivaloare complementară X  Z .
Dacă notăm prin:
Yx  y |  x , y , z   R şi Z x  z |  x , y , z   R
atunci definiţia 5.15 arată că o valoare dată x a atributului X formează tupluri cu fiecare
element al produsului cartezian Yx  Z x . Aceasta înseamnă că mulţimile Yx şi Z x sunt
independente între ele [DOL98].
O dependenţă multivaloare caracterizează o independenţă între două mulţimi de
atribute (Y şi Z) corelate printr-o a treia mulţime X.
O consecinţă importantă a acestei independenţe, aplicabilă în recunoaşterea
dependenţelor multivaloare, este faptul că dacă există dependenţa multivaloare
X  Y împreună cu dependenţa multivaloare complementară X  Z , atunci între
atributele Y şi Z nu poate exista nicio dependenţă funcţională *DOL98+.
Propoziţia 5.1. Orice dependenţă funcţională este şi o dependenţă multivaloare. (Altfel

spus, dependenţa funcţională este un caz particular de dependenţă multivaloare).
Demonstraţie.
X  Y    x , y , z  si  x , y' , z'  R  y  y'
deci X  Y    x , y , z  si  x , y' , z'  R  x , y' , z  si  x , y , z'  R
rezultă X  Y   X  Y  .
Ca şi în cazul dependenţelor funcţionale (unde există axiomele lui Armstrong), pentru

dependenţele multivaloare există un set de reguli de inferenţă care permit deducerea
tuturor dependenţelor multivaloare.
Axiomele de inferenţă pentru dependenţele multivaloare [ELN04]:

Axioma 1. Complementaritatea. X  Y   X  R  X  Y 
Axioma 2. Creşterea. X  Y  şi V  W   XW  YV 
Axioma 3. Tranzitivitatea. X  Y  şi Y  Z   X  Z  Y  .
12
Definiţia 5.16. Dependenţa multivaloare X  Y a relaţiei R este o dependenţă
multivaloare elementară dacă:
1. Y   şi Y  X  
2. Relaţia R nu conţine nicio altă dependenţă multivaloare de tip X '  Y ' , cu
X '  X şi Y '  Y .
Observaţie. În exemplul prezentat cu relaţia ZBOR, dependenţele nr_zbor  avion şi

nr_zbor  pilot sunt dependenţe multivaloare elementare.
Forma normală patru (4NF)

Definiţia 5.17. O relaţie este în forma normală patru dacă şi numai dacă singurele
dependenţe multivaloare elementare sunt cele în care o super-cheie determină un
atribut (o super-cheie este un ansamblu de atribute care conţine o cheie).
Deoarece o dependenţă funcţională este un caz particular de dependenţă multivaloare,

o relaţie este în forma normală patru (4NF) dacă:
 este în forma normală Boyce-Code (BCNF) şi
 orice dependenţă multivaloare este o dependenţă funcţională.
O relaţie BCNF este în 4NF dacă pentru orice dependenţă multivaloare elementară
X  Y , X este o super-cheie a lui R.
Regula de descompunere în relaţii 4NF.

Fie relaţia R cu schema RX ,Y , Z  şi fie o dependenţă multivaloare elementară X  Y
, care nu este de forma cheie  atribut . Relaţia R poate fi descompusă prin proiecţie
în două relaţii:
R1   X Y R  şi R2   X Z R 
astfel încât R  R1 conditie R2 , unde conditie  R1.X  R2.X .
Aplicarea regulii de descompunere în 4NF pentru exemplul prezentat în relaţia ZBOR

conduce la:
R1 nr _ zbor , avion  , cu cheia (nr_zbor, avion) şi
R2 nr _ zbor , pilot , cu cheia (nr_zbor, pilot).
Exemplu de descompunere în 4NF [DOL98]

Fie relaţia CURS cu schema CURS [profesor, disciplina, limba], care conţine cursurile şi
limbile străine în care pot fi susţinute de profesorii dintr-un department. Un profesor
susţine mai multe cursuri şi în mod normal, un profesor care cunoaşte mai multe limbi
străine poate susţine cursurile în oricare dintre acestea.
13
Un exemplu de populare a tabelei:
CURS Profesor Disciplina Limba

Moldoveanu Baze de date Engleză
Moldoveanu Programare Engleză
Ardeleanu Programare Franceză
Ardeleanu Programare Engleză
Ardeleanu Programare Germană
Ardeleanu Baze de date Franceză
Ardeleanu Baze de date Engleză
Ardeleanu Baze de date Germană
Olteanu Comerţ electronic Italiană
Olteanu Comerţ electronic Germană
Constatăm:
 Relaţia (tabela) CURS are cheia compusă (profesor, disciplina, limba).
 Relaţia CURS este în BCNF deoarece nu există niciun atribut care să depindă
funcţional de un alt atribut.
 Conform definiţiei dependenţei multivaloare se identifică în relaţia dată două
dependenţe multivaloare:
profesor  disciplina şi profesor  lim ba
deci, relaţia CURS nu este în forma normală patru.
 Există un mare grad de redundanţă a datelor, care generează anomalii în
operaţiile de actualizare. De exemplu:
- dacă Ardeleanu preia şi cursul de Comerţ electronic atunci trebuie
adăugate în relaţie (tabelă) trei tupluri (linii), presupunând că acest curs
poate fi ţinut în cele trei limbi străine cunoscute (anomalie de adăugare);
- orice operaţie de actualizare necesită modificări în mai multe tupluri;
- dacă Olteanu renunţă la cursul de Comerţ electronic ştergerea celor două
tupluri (linii) din tabelă duce la pierderea informaţiei legate de limbile
străine cunoscute de acesta (anomalie de ştergere).
Conform regulii de descompunere în 4NF, relaţia CURS se descompune în două relaţii:
R1 profesor , disciplina, care are cheia (profesor, disciplina) şi

R2 profesor , lim ba, care are cheia (profesor, limba).
Observaţie.
Joncţiunea celor două relaţii R1 şi R2 conduce la relaţia iniţială:
CURS  R1 conditie R2 , unde condiţie: R1.profesor = R2.profesor
ceea ce arată că descompunerea s-a făcut fără pierdere de informaţie.
14
5.8. DEPENDENŢE DE JONCŢIUNE. FORMA NORMALĂ CINCI (5NF)
Formele normale prezentate realizau trecerea de la o formă la alta prin eliminarea

depedenţelor funcţionale şi multivaloare. Există situaţii în care o relaţie aflată în 4NF
conţine totuşi redundanţe care generează anomalii în operaţiile de actualizare, datorită
existenţei dependenţelor de joncţiune.
Definiţia 5.18. Dependenţa de joncţiune. Fie relaţia R  A1 , A2 ,..., An  şi R1, R2 ,..., Rp o
mulţime de scheme relaţionale care nu sunt disjuncte şi a căror reuniune este R.
Spunem că există o dependenţă de joncţiune de ordinul p între R1, R2 ,..., Rp , notată:
 R1, R2 ,..., Rp dacă şi numai dacă R reprezintă în orice moment joncţiunea
proiecţiilor sale pe R1, R2 ,..., Rp , adică:
R   atr1 R  cond  atr2 R  cond ... cond  atr p R 
unde: atri , i  1,2 ,..., p reprezintă mulţimea atributelor corespunzătoare relaţiei Ri ;
cond – este condiţia de joncţiune pe egalitate între atributele comune din
relaţiile care intră în joncţiune.
Observaţii.
 Dacă p = 2 dependenţa de joncţiune devine dependenţă multivaloare.
În relaţia R cu schema RX ,Y , Z , fie o dependenţă multivaloare X  Y ; avem
deci şi X  Z . Acestea corespund dependenţei de joncţiune  X  Y , X  Z .
 o dependenţă de joncţiune poate exista numai în cadrul acelor relaţii 4NF care
prezintă chei compuse şi atribute comune în chei.
Propoziţia 5.2. [DAT05].

Fie relaţia R cu schema RX ,Y , Z  şi notăm cu R1X ,Y  , R2Y , Z  şi R3X , Z  trei relaţii
obţinute din R prin proiecţie.
Afirmaţia: Relaţia R este egală cu joncţiunea proiecţiilor sale R1, R2, R3 adică
R  R1, R2 , R3, este echivalentă cu :
dacă  x1, y1   R1,
 y 1 , z1   R 2 ,
 x 1 , z1   R 3 ,
atunci  x1, y1, z1   R .
Propoziţia 5.2. poate fi rescrisă ca o constrângere a relaţiei RX ,Y , Z . Avem astfel:

Propoziţia 5.3. [DAT05].
R  R1, R2 , R3 este echivalentă cu :
dacă  x1, y1, z 2   R
 x 2 , y 1 , z1   R
 x 1 , y 2 , z1   R
atunci  x1, y1, z1   R.
15
Exemplu.
Fie relaţia RX ,Y , Z  populată cu patru tupluri:
R X Y Z
x1 y1 z2
x2 y1 z1
x1 y2 z1
x1 y1 z1
Relaţia este formată numai din chei şi nu presupune nicio dependenţă funcţională sau
dependenţă multivaloare, fiind prin urmare în 4NF.
Relaţiile rezultate în urma proiecţiei şi eliminării tuplurilor duplicate sunt:
R1 X Y R2 Y Z R3 X Z
x2 y1 y1 z2 x1 z2
x1 y2 y2 z1 x2 z1
x1 y1 y1 z1 x1 z1
Joncţiunea dintre R1 şi R2 pe atributul Y conduce la: Q  R1 R1.Y R 2.Y R2
Q X Y Z
x1 y1 z2
x2 y1 z2
x2 y1 z1
x1 y2 z1
x1 y1 z1
Observăm că relaţia Q conţine în plus faţă de relaţia iniţială R tuplul  x 2 , y1, z 2  .

Joncţiunea dintre Q şi R3 pe atributele comune conduce la relaţia iniţială R:
R  Q ( Q.X R 3.X ) AND ( Q.Z R 3.Z ) R3
R X Y Z
x1 y1 z2
x2 y1 z1
x1 y2 z1
x1 y1 z1
Rezultă că relaţia R este egală cu joncţiunea proiecţiilor sale R1, R2, R3 adică,
R  R1, R2 , R3, dar nu este egală cu joncţiunea oricăror două dintre acestea.
16
Forma normală cinci (5NF)
Definiţia 5.19. [DAT05]
Dependenţa de joncţiune de ordinul p pentru R,  R1, R2 ,..., Rp , este banală, dacă şi
numai dacă, există Ri  R .
Definiţia 5.20. [DAT05]

O relaţie R este în 5NF dacă şi numai dacă cheile candidat ale relaţiei R implică fiecare
dependenţă de joncţiune nebanală care este satisfăcută de R.
Cu alte cuvinte, cheile candidat ale relaţiei R implică dependenţa de joncţiune
 R1, R2 ,..., Rp dacă şi numai dacă fiecare dintre mulţimile de atribute corespun-
zătoare atr1 , atr2 ,..., atrp este o supercheie a lui R.
Următorul exemplu preluat din *DOL98+ este sugestiv pentru analiza unei relaţii în forma
normală cinci.
Fie relaţia R cu schema:
R [ profesor, student, disciplina, limba, nota ]
Facem ipotezele:
 un student studiază orice disciplină cu un singur profesor într-o limbă dată;
 studentul primeşte o singură notă pentru disciplina respectivă;
 există situaţia în care o disciplină este predată la acelaşi program de studiu de
doi profesori în limbi diferite (de exemplu, situaţia unui profesor invitat care
predă în limba engleză şi studenţii optează pentru parcurgerea disciplinei
respective în limba română sau engleză).
Rezultă că avem cheia relaţiei R compusă din două atribute (student, disciplina).
Se identifică următoarele dependenţe funcţionale:
student, disciplina → profesor
student, disciplina → limba
student, disciplina → nota.
Observăm că în relaţia R nu există alte dependenţe funcţionale, decât cele rezultate din:
orice atribut non-cheie depinde de cheie şi nu există dependenţe multivaloare. Rezultă
că relaţia R este în 4NF.
În cadrul acestei relaţii există o dependenţă de joncţiune de ordinul 3, care permite
descompunerea relaţiei R în trei relaţii fără pierderi de informaţie:
R  R1, R2 , R3 cu: R1 [student, disciplina, profesor ]

R2 [student, disciplina, limba ]
R3 [student, disciplina, nota ].
Constatăm că cheia relaţiei R implică dependenţa de joncţiune prezentată

 R1, R2 , R3, adică fiecare dintre mulţimile de atribute corespunzătoare celor trei
relaţii R1, R2, R3 sunt superchei ale lui R.
17
Conform Definiţiei 5.20 relaţia R este în forma normală cinci (5NF) şi nu mai este
necesară descompunerea în cele trei relaţii R1, R2, R3 deoarece nu mai prezintă interes
din punctul de vedere al normalizării. Existenţa dependenţei de joncţiune
R  R1, R2 , R3 nu produce anomalii în operaţiile de actualizare a bazei de date.
Concluzie.
Formele normale 4NF şi 5NF sunt mai dificil de aplicat. În general, în cazurile practice
normalizarea se opreşte la 3NF sau BCNF. Din punct de vedere al performaţei, procesul
de normalizare în fazele superioare nu este întodeauna optimal. De aici a apărut şi ideea
denormalizării.
Denormalizarea este o tehnică de a implementa joncţiunea a două sau mai multe relaţii
în locul relaţiilor individuale iniţiale. Denormalizarea conduce la redundanţe de care
trebuie să ţină cont programele de aplicaţii. Avantajul acestui proces apare în operaţiile
de interogare a bazelor de date, joncţiunea tabelelor fiind înlocuită de o selecţie directă
pe tabela rezultat a joncţiunii.
18

BAza de Date

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BAza de Date

Încărcat de

Drepturi de autor:

Formate disponibile

CAPITOLUL 1

INTRODUCERE ÎN BAZE DE DATE

1.1. EVOLUŢIA PROCESULUI DE ORGANIZARE A DATELOR

Organizaţiile gestionează colecţii de date în scopul satisfacerii cerinţelor informaţionale

SIMBOL_CONT DENUMIRE_CONT TIP_CONT SID SIC

Într-o întreprindere sunt identificate mai multe colecţii de date, de exemplu:

Procesul de organizare a datelor presupune:

Organizarea datelor este necesară pentru:

Etapele evoluţiei procesului de organizare a datelor

Principalele etape ale evoluţiei tehnicilor de organizare şi prelucrare a datelor sunt:

 A doua etapă – este marcată de separarea dintre structura logică de date şi

O caracteristică comună a primelor două etape: fiecare aplicaţie lucrează cu propriile

 A treia etapă – este definită de apariţia fişierelor integrate (sisteme de fişiere). Se

Notă. Structura integrată stă la originea noţiunii de model conceptual (modelul ce

În concluzie, sistemele bazate pe fişiere (file based) au următoarele caracteristici:

1.2. BAZE DE DATE - CONCEPTE GENERALE

BAZA DE DATE este un ansamblu de date:

În gestiunea bazelor de date există două tipuri de baze de date:

BAZE DE DATE OPERAŢIONALE – sunt utilizate cu precădere în prelucrarea on-line a

ARHITECTURA UNUI SISTEM DE BAZE DE DATE (Database System) cuprinde:

Cerinţele minimale care se impun unei baze de date sunt:

 furnizarea în timp util a informaţiilor solicitate; se referă la timpul de răspuns la o

Utilizatorii bazei de date sunt:

 Administratorul bazei de date (DBA - DataBase Administrator) este responsabil

 Programatorul de aplicaţii (administratorul aplicaţiei) este cel care dezvoltă

 Utilizatorii finali (nespecialişti) accesează baza de date prin intermediul unui

 Nivelul intern (Internal Schema) – specifică modul de stocare a datelor în sistem.

Un sistem de baze de date acceptă mai multe limbaje gazdă. Un sublimbaj de

Observăm că graniţele dintre: a) limbajul gazdă şi sublimbajul de date şi b)

 Nivelul conceptual (Conceptual Schema) – corespunde unei reprezentări

Utilizator A1 Utilizator A2 Utilizator B1

Limbaj Limbaj Limbaj

Fig.1.1. Arhitectura unui sistem de baze de date

1.3. SISTEMUL DE GESTIUNE AL BAZEI DE DATE (SGBD)

Definiţia 1.4. Sistemul de gestiune al bazei de date (DBMS - Database Management

Obiectivele unui SGBD:

 Independenţa fizică. SGBD-ul are ca obiectiv central asigurarea independenţei

 Independenţa logică – este un obiectiv important şi reprezintă posibilitatea de

 Partajabilitatea datelor – obiectivul este de a permite ca aplicaţiile să partajeze

 Integritatea şi coerenţa datelor – obiectivul este ca informaţiile să respecte

 Manipularea datelor de utilizatorii finali – are ca obiectiv utilizarea de către

Funcţiile unui SGBD:

 Definirea datelor – SGBD-ul acceptă definiţiile datelor (schemele externe,

 Optimizarea şi execuţia – cererile DML vor fi prelucrate de optimizator pentru a

 Gestiunea tranzacţiilor – tranzacţia este o funcţie care realizează trecerea unei

 Securitatea şi confidenţialitatea datelor – presupune existenţa unor proceduri

pentru a depista şi respinge orice încercare de încălcare a constrângerilor de

Scheme şi Cereri DML Cereri DML neplanificate

Procesoare DDL Procesoare DML Procesorul

Metadate (dicţionar de date)

Fig.1.2. SGBD - Funcţiile şi componentele principale

 Manipularea datelor - presupune instrumente şi mecanisme ce permit

 Refacerea datelor şi concurenţa – presupune existenţa în sistem a unor

 Transformarea datelor (Data mapping) – este o funcţie care permite trecerea

În sinteză, scopul general al Sistemului de gestiune a bazelor de date este de a furniza

1.4. ARHITECTURA FUNCŢIONALĂ A UNUI SGBD

Arhitectura funcţională clasică a sistemelor de gestiune a bazelor de date integrează

 nivelul intern (baza de date fizică)

Arhitectura este articulată pe dicţionarul datelor şi cuprinde două părţi:

 un ansamblu de module (numite procesoare) care permite descrierea datelor şi

Georges Gardarin (2003) propune o arhitectură funcţională de referinţă apropiată de

Din punct de vedere al descrierii datelor, un SGBD gestionează un dicţionar de date,

Fig.1.3. Arhitectura unui SGBD