Baze de Date - Iacob

Paul IACOB
Introducere
Aplicaţii tradiţionale bazate pe fişiere; limitări

Pentru o mai bună înţelegere a evoluţiei prelucrărilor de date vom rezerva câteva
rânduri la începutul cursului nostru pentru o scurtă trecere în revistă a metodelor tradiţionale
de prelucrare a masivelor de date, aşa-numitele sisteme tradiţionale bazate pe fişiere.
În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfârşit calcule
laborioase în care nu erau implicate cantităţi prea mari de date, aşa-numitele calcule
ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a posibilităţii stocării de mari cantităţi
de informaţie pe suport magnetic adresabil (memorie externa) s-a pus şi problema
eficientizării prelucrării acestora. De data aceasta nu calculele creşteau costul în timp al
prelucrărilor ci manipularea datelor, respectiv regăsirea, actualizarea, etc. S-a constatat că un
factor important al creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor.
De aici şi până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date n-
a mai fost decât un pas.
Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe organizarea
datelor sub forma înregistrărilor în fişiere tradiţionale pe suport adresabil. În această variantă
se elaborau programe de aplicaţie care defineau şi manipulau propriile date şi aveau în general
ca scop elaborarea de rapoarte pentru diverşi beneficiari. Aceste programe au avut menirea de
a înlocui prelucrarea sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele
locuri cum ar fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat
pe fişiere copiau în mare măsură metodele manuale de prelucrare. Evident că puterea de
calcul şi memorare caracteristică sistemelor de calcul au făcut ca gama prelucrărilor să
crească simţitor, la aceasta adăugându-se viteza şi siguranţa prelucrărilor.
Cu toate că la momentul respectiv abordarea tradiţională bazată pe fişiere a fost un
evident progres, putem să amintim aici şi o serie de limitări ale acestui sistem de prelucrare a
datelor:
Separarea şi izolarea datelor
Duplicarea datelor
Dependenţa datelor
Incompatibilitatea fişierelor
Interogări fixe / proliferarea aplicaţiilor
Comentăm pe scurt în continuare semnificaţia acestora.
Accesul la date care se află în fişiere diferite este dificil deoarece cade în sarcina
programatorului să sincronizeze înregistrările din fişiere în aşa fel încât datele extrase să fie
corecte.
Duplicarea datelor
În situaţia în care se realizează prelucrări descentralizate de date, pe compartimente,
este posibil să fie necesară duplicarea datelor. Totuşi duplicarea este de evitat din următoarele
motive:
- necesită costuri mari în timp şi spaţiu de memorie.
- duce la pierderea integrităţii datelor. Datele nu mai sunt consistente, deci nu se mai
poate conta pe ele.
1
Dependenţa datelor
Aşa cum am subliniat deja, structura fizică şi modul de memorare al datelor este
definit în fiecare program de aplicaţie în parte. Este evident cât de dificile sunt schimbările în
structura datelor. Toate programele trebuie ajustate la noua structură de date. O simplă
modificare a lungimii unui câmp poate genera probleme. Dependenţa se referă aşadar la
dependenţa program-date.
Această limitare se trage tot din dependenţa de programe a structurii fişierelor.
Structura fiind descrisă în programe ea depinde de limbajul de programare. De exemplu,
structura unui fişier declarată într-un program COBOL diferă de structura unui fişier generat
de un program C. Dacă e necesară prelucrarea de date din ambele fişiere, programatorul este
obligat să scrie programe de conversie, pentru a aduce fişierele la un format comun posibil de
prelucrat.
Deoarece prelucrarea masivelor de date a devenit mai uşoara şi mai rapida cu ajutorul
calculatorului, beneficiarii au lărgit gama prelucrărilor lansând interogări noi sau modificând
interogări mai vechi, pentru obţinerea de informaţii mai complexe. Orice interogare nouă sau
orice modificare a unei interogări mai vechi se rezolvă în sistemele tradiţionale prin realizarea
de noi programe de către programatorul de aplicaţie. Inutil de subliniat cât de costisitoare sunt
acestea. Un efect secundar era că se înmulţeau programele aplicaţiei şi de multe ori şi fişierele
de prelucrat.
Obiectivele cursului
Cursul de baze de date este un curs de bază pentru meseria de informatician. La
sfârşitul acestui curs, studenţii vor fi capabili să:
 Proiecteze o baz ă de date
 Programeze cereri în SQL
 Realizeze un sistem cu bază de date
Cerinţe preliminare
Cursul se va susţine studenţilor după cursul de structuri de date.
Cunoştinţele acumulate la acest curs pot fi utile la un curs de informatică de
gestiune.
Resurse
Pentru a proiecta un sistem cu baz ă de date vom folosi sistemul ACCESS de la
Microsoft şi ORACLE 10G Express edition.
2
Structura cursului
Cursul de baze de date este structurat în trei module, astfel: primul modul cuprinde
patru unităţi de învăţare, al doilea modul cuprinde două unităţi de învăţare, al
treilea modul cuprinde două unităţi de învăţare, al patrulea modul cuprinde două
unităţi de învăţare, iar al cincilea modul cuprinde şase unităţi de învăţare. La
rândul său, fiecare unitate de învăţare cuprinde: obiective, aspecte teoretice privind
tematica unităţii de învăţare respective, exemple, teste de autoevaluare precum şi
probleme propuse spre discuţie şi rezolvare.
La sfârşitul fiecărui modul sunt date teste de autoevaluare. Rezolvarea acestor teste
se găseşte la sfârşitul cărţii.
Durata medie de studiu individual

Parcurgerea de către studenţi a unităţilor de învăţare ale cursului de baze de date
(atât aspectele teoretice cât şi rezolvarea testelor de autoevaluare şi rezolvarea
problemelor propuse) se poate face în 1-4 ore pentru fiecare unitate.
Evaluarea
La sfârşitul semestrului, fiecare student va primi o notă, care va cuprinde: un
examen scris cu materia din modulele 1, 3 şi 4 care va deţine o pondere de 60% în
nota finală şi notele aferente celor două capitole de la laborator ACCESS şi
ORACLE.
3
CUPRINS
Modulul 1. Sisteme de Gestiune a Bazelor de Date (SGBD) ................................ ..................... 5
Unitatea de învăţare 1. Istoric; comentarii ................................ ................................ ......... 6
Criterii minimale de definire a unui SGBDR ................................ ................................ ... 10
Unitatea de învăţare 1.2 Abstractizarea datelor ................................ ................................ 14
Unitatea de învăţare 1.3 Principalele componente şi funcţiuni ale unui SGBD ............... 19
Unitatea de învăţare 1.4 Baze de date distribuite ................................ ............................. 27
Modulul 2. Modele de descriere a datelor ................................ ................................ ................ 37
Unitatea de învăţare 2.1. Generalităţi ................................ ................................ ............... 38
Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship) ................................ ......... 41
Modulul 3. Limbaje de cereri. ................................ ................................ ................................ .. 53
Unitatea de învăţare 3.1 Algebra relaţională. ................................ ................................ ... 54
Unitatea de învăţare 3.2 SQL ................................ ................................ ........................... 65
Modulul 4. Normalizarea................................ ................................ ................................ .......... 85
Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem
normalizarea. ................................ ................................ ................................ .................... 86
Unitatea de învăţare 4.2 Forme normale ................................ ................................ ......... 93
Modulul 5. Metodologia de proiectare a bazelor de date relaţionale ................................ ...... 99
Unitatea de învăţare U5.1 Generalităţi şi proiectarea conceptuală................................ . 101
Unitatea de învăţare U5.2 Proiectarea logică. ................................ ................................ 111
Unitatea de învăţare U5.3 Proiectarea fizică. ................................ ................................ . 122
Unitatea de învăţare U5.4 Tranzacţii şi concurenţă................................ ........................ 126
Unitatea de învăţare U5.5 Metode de control al concurenţei. ................................ ........ 131
Unitatea de învăţare U5.6. Securitate şi integritate ................................ ........................ 139
Raspunsuri la testele de autoevaluare. ................................ ................................ .................... 147
Bibliografie................................. ................................ ................................ ............................ 164
4
Modulul 1. Sisteme de Gestiune a Bazelor de Date
(SGBD)
Cuprins
Introducere ................................ ................................ ................................ ...................... 3
Obiectivele modului ................................ ................................ ................................ ........ 3
U1.1. Istoric; comentarii
U1.2. Abstractizarea datelor
U1.3. Principalele componente şi funcţiuni ale unui SGBD
U1.4 Baze de date distribuite
Introducere
Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de
necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce
mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere,
memorare, transmitere şi prelucrare a datelor. Cel mai important domeniu al
aplicaţiilor calculatorului este cel al bazelor de date.
M1. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:
 Distingă gradul de relaţional al unui SGBD
 descrie componenţa unui Sistem de Gestiune al Bazei de Date
 cunoască obiectivele unui SGBD
 cunoască şi să utilizeze funcţiunile unui SGBD
 înţeleagă ce este o bază de date distribbuită
 cum se proiectează o bază de date distribuită

5
Unitatea de învăţare 1. Istoric; comentarii
M1.U1.1. Introducere
Este important să ştim cum a evoluat modelul şi softul pentru bazele de date. Ne
ocupăm, în acest curs, de cel mai important dintre modele şi anume modelul
relaţional.
M1.U1.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 Înţeleagă nivelul la care au ajuns bazele de date
 Distingă gradul de relaţional al unui SGBD.
Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
Istoric şi comentarii
Se pare că sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de
aselenizare Apollo. Deoarece pe atunci nu există un astfel de sistem, North American
Aviation (actualmente Rockwell International) a dezvoltat un pachet de programe cunoscut
sub numele GUAM (Generalized Update Access Method), care se baza pe date organizate în
mod ierarhic. Modelul de date ierarhic, unul din modelele abstracte ale bazelor de date, îşi are
originea în acest proiect.
In anii ‘60 General Electric a dezvoltat sistemul IDS (Integrated Data Store).
Conducător de proiect: Charles Bachmann. Proiectul a condus la mod elul de date reţea.
În 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea
reprezentanţi ai guvernului USA şi reprezentanţi ai lumii afacerilor şi comerţului, a reuşit să
stabilească un grup de lucru, cunoscut din 1967 sub numele Data Base Task Group (DBTG).
Sarcina acestui grup era să stabilească specificaţii cu rol de standarde pentru un mediu care ar
permite crearea de baze de date şi manipularea datelor.
Conceptul de bază de date s-a definit în 1969 cu ocazia prezentării primului proiect de
raport CODASYL (Raportul final s-a prezentat în 1971). Ideea principală în organizarea
datelor se baza pe existenţa a trei nivele de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de date
 subschema - care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de
programele de aplicaţie
 un limbaj de gestionare a datelor - care definea caracteristicile datelor, structura lor şi care
manipula datele
Pentru standardizare, s-au propus trei limbaje:
 un limbaj de definire a datelor (LDD) la nivel de schemă
 un limbaj la nivel de subschemă
6
 un limbaj de manipulare a datelor (LMD)
Cu toate că nu a fost adoptată formal de ANŞI (American National Standard Institute)
propunerea DBTG a fost aplicată într-o serie de sisteme dezvoltate ulterior şi ea stă la baza
conceptului modern de bază de date.
Proiectul ierarhic şi cel prezentat de CODASYL reprezintă prima generaţie de Sisteme de
Gestiune a Bazelor de Date (SGBD).
În 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o
influenţă covârşitoare în dezvoltarea bazelor de date. Lucrarea trata despre modelul de date
relaţional.
De aici încolo s-au proiectat multe sisteme dintre care menţionăm System R dezvoltat la
IBM's San Jose Research Laboratory din California, la sfârşitul anilor '70. Acest proiect a dus
la:
 dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un
standard pentru sistemele relaţionale;
 producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2 şi
SQL/DS de la IBM şi ORACLE de la ORACLE Corporation.
Alte exemple de sisteme relaţionale: INGRES de la Relaţional Technology Inc., Informix de
la Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sistemele relaţionale pentru
microcalculatoare enumerăm aici: Paradox şi dBase IV de la Borland, Access de la Microsoft,
FoxPro şi R:base de la Microrim. Toate acestea constituie generaţia a doua de SGBD.
Definirea sistemelor de gestiune ale bazelor de date relaţionale
Într-o primă încercare de definire, se poate considera un sistem de gestiune a bazelor de
date relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de
organizare a datelor modelul relaţional. Astfel spus, un SGDBR reprezintă un sistem care
suportă modelul relaţional.
Definiţia de mai sus este prea generală pentru a putea fi operaţională, deoarece modul de
implementare a modelului relaţional diferă, de regulă atât între diferitele SGBDR, cât şi în
raport cu modelul “ teoretic”, cel definit în cadrul teoriei relaţionale, datorită eforturilor
producătorilor de a realiza sisteme cât mai performanţe care să satisfacă cerinţele şi
exagerările utilizatorilor. Cât de aproape (sau de departe) de modelul relaţional teoretic
trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că SGBD-ul
respectiv utilizează sau nu modelul relaţional, deci este sau nu SGBDR?
Diversitatea modelelor relaţionale operaţionale au determinat, în mod natural existenţa
unei mari diversităţii de SGBDR, pentru a căror prezentare a fost necesară nuanţarea
terminologiei. Au apărut o serie de sintagme precum: sisteme cu interfaţă relaţională, sisteme
pseudorelaţionale, sisteme complet relaţionale.
Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei relaţionale între care
se pot stabili analogii
Organizarea datelor în fişiere SGBDR Teoria relaţională

Fişier Tabelă Relaţie
Record(înregistrare) Linie Tuplu
Câmp Coloană Atribut
În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale

operaţionale diferă de cele din cadrul teoriei relaţionale. Figura de mai sus prezintă
7
comparativ conceptele organizării datelor în fişiere, concepte SGBDR şi ale teoriei
relaţionale.
Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi
conceptele relaţionale, i-au determinat pe unii producători să prezinte sisteme fără nici o
legătură cu modelul relaţional drept SGBDR, în scopul asigurării succesului comercial al
acestor sisteme.
Regulile lui Codd
Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte
un SGBD pentru a putea fi considerat relaţional. În acest sens, Codd a formulat 13 reguli care
exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. Deşi reguli au
stârnit o serie de controverse, eu le voi prezenta în continuare, ele fiind deosebit de utile în
evaluarea unui SGBDR.
R0: Regula privind gestionarea datelor la nivel de relaţie
Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale.
Acest lucru înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin
manipulări în care unitatea de informaţie să fie mulţimea (relaţia), adică să utilizeze limbaje,
precum SQL, care să opereze la un moment dat pe o întreagă relaţie. Dec i SGBD nu trebuie să
accepte operaţii non-relaţionale care să îndeplinească operaţiile de definire şi manipulare a
datelor.
Unele sisteme utilizează mecanisme relaţionale numai pentru o parte din funcţii, în special
pentru interogare. Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR.
R1: Regula privind reprezentarea logică a datelor
Toate datele din baza de date relaţională trebuie să fie reprezentate explicit la nivel
logic, într-un singur mod, şi anume ca valori în tabele de date. Ac este lucru înseamnă că toate
datele trebuie să fie memorate şi prelucrate în acelaşi mod. Informaţiile privind numele de
tabele,coloane, domenii, definiţiile tabelelor virtuale, restricţii de integritate trebuie să fie
memorare tot în tabele de date (cataloage). Referinţa la 'nivelul logic' înseamnă că construcţia
fizică nu este reprezentată şi nu necesită explicaţie.
R2: Regula privind garantarea accesului la date.
Orice dată din baza de date relaţională trebuie să poată fi accesată prin specificarea
numelui da tabelă, valorii cheii primare şi numelui de coloană.
Această regulă exprimă cerinţa ca limbajul de cereri al SGBDR să permită accesul la
fiecare valoare atomică din baza de date.
R3: Regula privind valorile null
Sistemele trebuie să permită declararea să manipularea sistematică a valorilor null, cu
semnificaţia unor date lipsă sau inaplicabile. Valorile null, care diferă de şirurile de caractere '
spaţiu' sau de şirurile vide da caractere sunt deosebit de importante în implementarea
restricţiilor de integritate (integritatea entităţii şi integritatea referenţială).
R4: Regula privind metadatele
Descrierea bazei de date trebuie să se prezinte la nivel logic în acelaşi mod cu descrierea
datelor propiu-zise, astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi
operaţii ca şi asupra datelor obişnuite.
Această regulă specifică că trebuie să existe un unic limbaj de manipulare a metadatelor şi
a datelor propui-zise, mai mult, există o unică structură logică folosită pentru a depozita
informaţiile de sistem.
Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şi a metadatelor,
utilizând o singură structură, şi anume cea relaţională.
R5: Regula privind facilităţile limbajelor utilizate
Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în mai multe
moduri. Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată
8
exprima oricare din următoarele operaţii: definirea tabelelor de date, definirea tabelelor
virtuale, manipularea datelor (interactiv dau prin program), definirea restricţiilor de
integritate, autorizarea accesului, precizarea limitelor tranzacţiilor. A se nota aici că noul
standard O/I pentru SQL furnizează toate aceste funcţii, deci orice limbaj care acceptă acest
standard va satisface automat această regulă.
R6: Regula privind actualizarea tabelelor virtuale.
Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să poată fi efectiv
actualizabile. Nu toate atributele din cadrul unei tabele virtuale, deci nu toate tabele virtuale
sunt teoretic actualizabile.
R7: Regula privind inserările, modificările şi ştergerile în baza de date
Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nu
numai în cadrul operaţiilor de regăsire, ci şi în acţiuni de inserare, modificare şi ştergere a
datelor.
Această regulă exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se
lucreze la un moment dat pe o întreagă relaţie.
R8: Regula privind independenţa fizică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de
reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu
trebuie să blocheze funcţionarea programelor de aplicaţie.
R9: Regula privind independenţa logică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra
relaţiilor bazei de date, schimbări care conservă datele şi care teoretic garantează valabilitatea
programelor de aplicaţie existente.
R10: Regula privind restricţiile de integritate
Restricţiile de integritate trebuie să fie definite în limbajul utilizat de sistem pentru
definirea datelor ţi să fie memorate în cadrul bazei de date şi nu în cadrul programului de
aplicaţie.
R11: Regula privind distribuirea geografică a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situaţia în
care datele sunt distribuite, programele de aplicaţie să fie logic aceleaşi cu cele utilizate în
cazul în care datele sunt fizic centralizate.
Utilizatorul trebuie să perceapă datele ca fiind centralizate. Sarcina de localizare a
datelor, atunci când acestea sunt distribuite geografic precum şi sarcina recompunerii datelor
trebuie să revină sistemului şi nu utilizatorului.
R12: Regula privind prelucrarea datelor la nivelul de bază
Dacă sistemul posedă un limbaj de bază (de nivel scăzut) orientat pe prelucrare de
recorduri (tupluri) şi nu pe prelucrarea mulţimilor (relaţiilor), acest limbaj nu trebuie s ă fie
utilizat pentru a se evita restricţiile de integritate sau restricţiile introduse prin utilizarea
limbajelor de nivel înalt, adică accesul la toate datele va fi controlat de SGBDR, altfel
integritate bazelor de date nu poate fi compromisă fără cunoa şterea utilizatorului sau a
administratorului bazei de date.
Pe parcursul anilor regulile lui Codd au generat o seamă de controverse. Câteva
argumente sunt că aceste reguli nu sunt mai mult decât nişte exerciţii academice. Unele
revendicări ale produselor existente sunt că ele pot îndeplini cea mai mare parte din reguli,
dar nu toate. Această discuţie a generat o dispută între utilizatori şi teoreticienii asupra
proprietăţilor esenţiale ale unui SGBDR.
Pentru a accentua implicaţia regulilor lui Codd în analiza unui SGBDR, aceste reguli
au fost reorganizate în cinci categorii, şi anume:
 Reguli fundamentale,
9
 Reguli structurale,
 Reguli privind integritatea datelor,
 Reguli privind manipularea datelor,
 Reguli privind independenţa datelor.
Să ne reamintim...
Abordarea tradiţională bazată pe fişiere are o serie de limitări cum ar fi

Duplicarea datelor
Dependenţa datelor
Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de
aselenizare Apollo
Ideea principală în organizarea datelor se baza pe existenţa a trei componente

de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de date
 subschema - care reprezenta o parte a bazei de date aşa cum e văzută de
utilizator sau de programele de aplicaţie
 un limbaj de gestionare a datelor - care definea caracteristicile datelor,
structura lor şi care manipula datele
Pentru standardizare avem trei limbaje:
 un limbaj de definire a datelor (LDD) la nivel de schemă
 un limbaj la nivel de subschemă
 un limbaj de manipulare a datelor (LMD)
Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei
relaţionale între care se pot stabili analogii
Organizarea datelor în SGBDR Teoria relaţională

fişiere
Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte

un SGBD ca să fie relaţional.
Criterii minimale de definire a unui SGBDR
Nici unul dintre SGBDR disponibile astăzi nu respectă întru totul cerinţele exprimate de
Codd, în cadrul celor 13 reguli. De aceea pentru caracterizarea unui SGBD nu sunt utilizate
10
regulile lui Codd, fiind formulate în schimb o serie de cerinţe minimale pa care trebuie să la
satisfacă un sistem de gestiune a bazelor de date pentru a putea fi considerat relaţional.
Un SGBD este minimal relaţional dacă satisface următoarele condiţii:
1. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,
2. Nu există pointeri observabili de către utilizatori în tabele, în sensul că operaţiile cu relaţii
nu fac apel la pointeri, indecşi, fişiere inverse, etc.
3. Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără limitări
impuse de considerente interne (cum ar fi de exemplu, necesitatea indexării atributelor).
Unitatea de informaţie cu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia.
Un SGBD este complet relaţional dacă este minimal relaţional şi satisface în plus
următoarele condiţii:
4. Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări impuse de
considerente interne.
5. Sistemul suportă două dintre restricţiile de integritate de bază al modelului relaţional şi
anume unicitatea cheii unei relaţii şi restricţia referenţială.
Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. şi 3.

Un SGBD cu interfaţă relaţională este un SGBD are satisface condiţiile 1. şi 3., cu
observaţia că cerinţa 3. Este îndeplinită numai în raport cu funcţia de interogare
În ultimii ani, ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu baze de
date (încurajată şi de progresele apărute în programare o dată cu programarea orientata obiect)
au apărut modelul de date orientat obiect (Object-Oriented Data Model - OODM) şi modelul
de date relaţional extins (Extended Relaţional Data Model - ERDM). Cu toate că modelul de
date ce sta la baza noilor modele nu este atât de clar că în cazul modelului relaţional, se poate
considera că aceste din urma dezvoltări reprezintă generaţia a patra de SGBD.
In esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date
aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre
ele), colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi (sau
organizaţii).
Baza de date trebuie să îndeplinească următoarele condiţii:
- să asigure o independenţă sporită a datelor faţă de programe şi invers;
- structura bazei de date trebuie astfel concepută încât să asigure informaţiile necesare şi
suficiente pentru cerinţele de informare şi decizie;
- să asigure o redundanţă minimă şi controlată a datelor;
- să permită accesul rapid la informaţiile stocate în bază.
Bazele de date sunt extrem de variate în funcţie de criteriile luate în considerare. Prezentăm
câteva criterii de clasificare:
- după orientare: generalizate, specializate;
- după modelul de date: ierarhice, reţele, relaţionale, orientate obiect;
- după amploarea geografica: locale, distribuite;
Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care

permite, pe de o parte, definirea, crearea şi întreţinerea bazei de date şi pe de alta parte,
permite accesul controlat la informaţiile din baza de date în cauză. SGBD este format din
11
programe de software care interacţionează cu programele de aplicaţie ale utilizatorilor şi cu
baza de date. Sistemul de gestiune al bazei de date asigură realizarea următoarelor activităţi:
- definirea structurii bazei de date;
- încărcarea datelor în baza de date;
- accesul la date (interogare, actualizare);
- întreţinerea bazei de date (colectarea şi reutilizarea spatiilor goale, refacerea bazei de
date în cazul unui incident);
- reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces);
- integritatea datelor;
- securitatea datelor.
Aşadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe
care asigură interfaţa între o bază de date şi utilizatorii acesteia.
Clasificarea SGBD se poate realiza din mai multe puncte de vedere.

Din punctul de vedere al sistemelor de calcul pe care se implementează. SGBD pot fi:
 sisteme de gestiune pentru calculatoarele mari;
 sisteme de gestiune pentru minicalculatoare;
 sisteme de gestiune pentru microcalculatoare.
In prezent se manifesta tendinţa ca marea majoritate a sistemelor de gestiune a bazelor de
date să fie compatibile pe platforme cât mai largi de sisteme de calcul.
2. Din punctul de vedere al limbajului pe care îl utilizează, sunt: sisteme cu limbaj gazdă;
sisteme cu limbaj autonom.
Sistemele cu limbaj gazdă realizează activităţile de creare, actualizare şi interogare a
bazei de date, utilizând limbajele de nivel înalt sau extensii ale acestora, proprii sistemului de
calcul pe care se implementează baza de date. Avantajul acestor sisteme constă în
posibilităţile sporite ce le oferă limbajele de nivel înalt la elaborarea unor proceduri complexe.
Sistemele cu limbaj gazdă prezintă dezavantajul că formularea cerinţelor nu este atât de
simplificată ca în cazul sistemelor cu limbaj autonom.
3. Din punctul de vedere al concepţiei de organizare a datelor pe care le gestionează, SGBD
se clasifică în: sisteme de gestiune a bazelor de date cu structuri ierarhice şi reţea; sisteme de
gestiune a bazelor de date relaţionale; sisteme de gestiune a bazelor de date orientate obiect.
4. Din punctul de vedere al modului de localizare a bazelor de date avem: sisteme de gestiune
a bazelor de date centralizate; sisteme de gestiune a bazelor de date distribuit e.
Marea majoritate a sistemelor de gestiune apărute în ultima perioadă dispun şi de o
componentă de gestiune distribuită a datelor.
Să ne reamintim...
Un SGBD este minimal relaţional dacă satisface următoarele condiţii:
Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,
Nu există pointeri observabili de către utilizatori în tabele, în sensul că
operaţiile cu relaţii nu fac apel la pointeri, indecşi, fişiere inverse, etc.
Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără
limitări impuse de considerente interne (cum ar fi de exemplu, necesitatea
indexării atributelor). Unitatea de informaţie cu care se lucrează în cadrul
acestor operaţii trebuie să fie relaţia.
Un SGBD este complet relaţional dacă este minimal relaţional şi satisface
în plus următoarele condiţii:
12
Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări
impuse de considerente interne.
Sistemul suportă două dintre restricţiile de integritate de bază al modelului
relaţional şi anume unicitatea cheii unei relaţii şi restricţia referenţială.
În esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată

de date aflate în interdependenţă logică (împreună cu o descriere a acestor date
şi a relaţiilor dintre ele), colecţie desemnată pentru a rezolva nevoia de
informatizare a unei întreprinderi.
Clasificarea SGBD se poate realiza din mai multe puncte de vedere: din punctul
de vedere al sistemelor de calcul pe care se implementează. SGBD, din punctul
de vedere al limbajului pe care îl utilizează şi din punctul de vedere al
concepţiei de organizare a datelor pe care le gestionează
M1.U1.6. Rezumat
Conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date

aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a
relaţiilor dintre ele), colecţie desemnată pentru a rezolva nevoia de
informatizare a unei întreprinderi.
Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de

aselenizare Apollo
Ideea principală în organizarea datelor se baza pe existenţa a trei componente
de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de date
 subschema - care reprezenta o parte a bazei de date aşa cum e văzută de
utilizator sau de programele de aplicaţie
 un limbaj de gestionare a datelor - care definea caracteristicile datelor,
structura lor şi care manipula datele
Pentru standardizare avem trei limbaje:
 un limbaj de definire a datelor (LDD) la nivel de schemă
 un limbaj la nivel de subschemă
 un limbaj de manipulare a datelor (LMD)
Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei
relaţionale între care se pot stabili analogii
Organizarea datelor în SGBDR Teoria relaţională

fişiere
13
Unitatea de învăţare 1.2 Abstractizarea datelor
Un scop important al unui sistem de gestiune al bazelor de date este să poată
asigura o viziune abstractă asupra realităţii. Este necesar să se reţină din mulţimea
vastă de informaţii doar acelea care sunt necesare unei anumite aplicaţii.

 înţeleagă care este structura pe trei nivele a bazei de date
 înţeleagă ce este independenţa logică şi ce este cea fizică şi de ce este
importantă această independenţă
Durata medie de parcurgere a primei unităţi de învăţare este de 2 or e.
Se poate face referire spre exemplu la încercarea de modelare a unei aplicaţii într-o
întreprindere. Trebuie modelate 'obiectele' şi relaţiile dintre ele. Nu realitatea complexă în
totalitatea ei intră în discuţie ci doar o mică parte a ei, constituită din anumite 'obiecte' şi
pentru acele obiecte se iau în considerare doar o parte din caracteristici (acele caracteristici
care sunt importante pentru aplicaţia în cauza). Astfel în cazul modelării 'obiectului' (sau
entităţii) angajat, trebuie alese doar acele proprietăţi (sau atribute) care interesează. Acestea
ar putea fi, de exemplu: numele, adresa, salariul. O mulţime impresionantă de informaţii, care
contribuie la descrierea unei persoane anume, nu sunt luate în seamă, deoarece nu prezintă
interes pentru întreprindere.
Exemple
De exemplu, nu interesează dacă persoana are ochii albaştri, dacă este blondă
sau brunetă, dacă ascultă cu plăcere muzică sau dacă este o fire sentimentală.
Ce credeţi că ar interesa să memorăm despre studenţi într-o bază de date a

facultăţii?
Ce nu ar trebui memorat?
Mai mult decât faptul că realitatea este reprezentată codificat şi foarte simplificat,
deoarece baza de date este o resursă partajată, este foarte probabil ca fiecare utilizator s ă
dorească doar o parte din informaţiile stocate, funcţie de aplicaţia pe care o dezvoltă.
14
Pentru a se rezolva aceste cerinţe, se apelează la reprezentarea pe nivele a organizării
informaţiilor într-o baza de date. În general este acceptată arhitectura pe trei nivele ANSI-
SPARC.
Componentele bazei de date pot fi structurate pe trei nivele, în funcţie de clasa
utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei, după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea
programatorului de aplicaţii, care realizează programele de aplicaţii pentru manipularea
datelor la nivel de structură logică (subschema) corespunzătoare descrierii datelor aplicaţiei;
- nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care
realizează structura conceptuală (schema) corespunzătoare descrierii întregii baze de date şi
administrează componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza
de date şi ce relaţii sunt stabilite între date. Nivelul conceptual reprezintă:
- toate entităţile, atributele lor şi relaţiile dintre ele;
- restricţiile impuse datelor
- informaţiile semantice despre date
- informaţiile privitoare la securitatea şi integritatea datelor.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică
corespunzătoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt
memorate datele în baza de date. Nivelul intern se ocupă de:
- alocarea spaţiului de memorie pentru date şi indecşi;
- descrierea înregistrărilor pentru memorare;
- plasarea înregistrărilor pe suport;
- tehnicile de compresie şi de criptare a datelor.
Utilizator 1 Utilizator 2
Nivel
View 1 View 2 ….. View n
extern
Nivel Schema
conceptual conceptuala
Nivel Schema
intern interna
Organizarea la
nivel fizic a datelor Baza de
date
15
Arhitectura ANSI-SPARC pe trei nivele
Să ne reamintim...
Componentele bazei de date pot fi structurate pe trei nivele, în funcţie

de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,
după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de
viziunea programatorului de aplicaţii
- nivelul conceptual (global). Este dat de viziunea administratorului bazei
de date, care realizează structura conceptuală (schema) corespunzătoare
descrierii întregii baze de date şi administrează componentele baz ei de date.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează
structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic).
Scheme, corespondenţe şi instanţe
Descrierea generala a unei baze de date se numeşte schema bazei de date. Conform
nivelelor de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date. La
nivelul cel mai înalt există (în general) mai multe scheme externe (numite şi subscheme)
care descriu diferitele view-uri ale bazei de date. La nivelul conceptual există schema
conceptuală iar la nivelul cel mai de jos de abstractizare există schema internă.
Pentru fiecare bază de date o singura schemă conceptuală descrie datele şi relaţiile
între ele, precum şi restricţiile de integritate. Schemei conceptuale îi corespunde o schemă
internă care descrie organizarea fizică a datelor.
SGBD realizează corespondenţa între cele trei nivele de abstractizare, realizând

corespondenţa între cele trei tipuri de scheme. Astfel corespondenţa conceptual / intern
leagă schema conceptuală de schema internă. Datorită acestei corespondenţe se identifică
înregistrarea sau combinaţia de înregistrări la nivel fizic, care constituie înregistrarea logică
în schema conceptuală, împreună cu restricţiile de integritate corespunzătoare. Analog, fiecare
schemă externă este legată de schema conceptuală prin corespondenţa extern / conceptual.
Aceasta corespondenţă permite SGBD să facă legătura între numele din view-urile utilizator
şi partea corespunzătoare relevantă din schema conceptuală. Este de reţinut că trebuie să
facem distincţie între descrierea bazei de date (schema bazei de date) şi baza de date propriu-
zisă. Numim instanţa (în cazul unei baze de date) datele aflate în baza de date la un anumit
moment dat. Altfel spus, mai multe instanţe pot să corespundă aceleiaşi scheme conceptuale
pentru o bază de date.
16
Să ne reamintim...
Descrierea generala a unei baze de date se numeşte schema bazei de date.

Conform nivelelor de abstractizare a datelor există trei tipuri de scheme
pentru fiecare bază de date. La nivelul cel mai înalt există (în general) mai
multe scheme externe (numite şi subscheme) care descriu diferitele view-uri
ale bazei de date. La nivelul conceptual există schema conceptuală iar la
nivelul cel mai de jos de abstractizare există schema internă.
Independenţa datelor
Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea
independenţei datelor. O aplicaţie, în general, este dependentă de date în sensul că
modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi
aplicaţia. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele
considerente:
- diferite aplicaţii au nevoie de viziuni diferite asupra aceloraşi date;
- administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare
sau strategia de acces, ca răspuns la cerinţe (schimbări de standarde, priorităţile aplicaţiilor,
unităţile de memorare etc.), fără a modifica aplicaţiile existente, baza de date existentă,
precum şi programele de exploatare a ei, care au fost folosite o perioadă de timp şi care
reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor.
De aceea, se impune ca atunci când apar noi cerinţe în cadrul sistemului informaţional,
sistemele informatice să poată funcţiona cu programele şi procedurile existente, iar datele
existente să poată fi convertite.
Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi
independenţa logică a datelor.
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să
poată fi modificate fără a determina rescrierea programelor de aplicaţie. Aşadar independenţa
fizică a datelor reprezintă gradul de imunitate a schemei conceptuale la schimbările suferite
de schema internă.
Independenţa logică a datelor se refera la posibilitatea adăugării de noi înregistrări sau la
extinderea structurii conceptuale (globale), fără ca acest lucru să impună rescrierea
programelor existente. Cu alte cuvinte independenţa logică a datelor reprezintă gradul de
imunitate a schemelor externe la schimbările suferite de schema conceptuală.
Să ne reamintim...
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de

memorarea să poată fi modificate fără a determina rescrierea programelor de
aplicaţie.
Independenţa logică a datelor se referă la posibilitatea adăugării de noi

înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest lucru
să impună rescrierea programelor existente.
17
M1.U1.6. Rezumat
Componentele bazei de date pot fi structurate pe trei nivele, în funcţie
de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,
după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern.
- nivelul conceptual (global
- nivelul fizic
Descrierea generală a unei baze de date se numeşte schema bazei de

date. Conform nivelelor de abstractizare a datelor există trei tipuri de scheme
pentru fiecare bază de date. Există (în general) mai multe scheme externe
(numite şi subscheme) care descriu diferitele view-uri ale bazei de date. La
nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos de
abstractizare există schema internă.
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de
memorarea să poată fi modificate fără a determina rescrierea programelor de
aplicaţie.
Independenţa logică a datelor se referă la posibilitatea adăugării de noi
înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest
lucru să impună rescrierea programelor existente.
M1.U1.2. Test de autoevaluare a cunoştinţelor

1.2.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?
1.2.2 Ce nu ar trebui memorat despre profesori într-o bază de date a
facultăţii?
1.2.3 Ce este arhitectura pe trei nivele?
Răspunsurile se găsesc la sfârşit la pag 147
18
Unitatea de învăţare 1.3 Principalele componente şi funcţiuni al e unui SGBD
Pentru a concepe şi a utiliza o bază de date trebuie să ştim ce putem cere de la o
bază de date şi de la un SGBD:

 descrie componenţa unui Sistem de Gestiune al Bazei de Date
 cunoască obiectivele unui SGBD
 cunoască şi să utilizeze funcţiunile unui SGBD
Durata medie de parcurgere a primei unităţi de învăţare es te de 2 ore.
Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune, care se diferenţiază:
- prin limbajele utilizate,
- prin anumite componente ce imprimă diferite facilităţi de exploatare a bazei de date,
- şi prin faptul că unele oferă posibilitatea lucrului în regim de teleprelucrare, altele
numai în regim local, iar altele atât în regim local cât şi în regim de teleprelucrare,
ajungem la concluzia că nu poate fi stabilită o arhitectură unică, valabilă pentru toate
sistemele, ci apar particularităţi de la un sistem la altul.
Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde

internaţionale. O astfel de arhitectură generală cuprinde următoarele componente:
- baza de date propriu-zisă în care se memorează colecţia de date;
- sistemul de gestiune al bazei de date, care este un ansamblu de programe (soft) care
realizează gestiunea şi prelucrarea complexă a datelor;
- un set de proceduri manuale şi automate, precum şi reglementările administrative,
destinate bunei funcţionări a întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine informaţii despre date,
structura acestora, elemente de descriere a semanticii, statistici, documentaţie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate
(administrator), analişti - programatori, gestionari, operatori).
Arhitectura bazei de date dă o imagine despre modul general de organizare şi funcţionare a ei.
Să detaliem câteva din componentele prezentate mai sus.
19
Limbajele utilizate într-un SGBD sunt de două tipuri: Limbajul de definire a datelor
(Data Definition Language - DDL) şi Limbajul de manipulare a datelor (Data Manipulation
Language - DML). Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu
includ construcţii adecvate oricăror necesităţi de calcul, asemănătoare cu structurile puse la
dispoziţie de limbajele de nivel înalt.
Multe SGBD au facilitatea de a incorpora sublimbajul într-un limbaj de nivel înalt
(numit limbaj gazdă) cum ar fi COBOL, Fortran, Pascal, Ada, C. Pentru compilare, comenzile
sublimbajului sunt înlocuite în limbajul gazdă cu apeluri de funcţii. Fişierul preprocesat este
compilat, plasat într-un modul obiect, link-editat cu o bibliotecă în care se află funcţiile
înlocuite, furnizate o dată cu SGBD, şi este executat când este necesar.
Limbajul de Definire a Datelor (LDD) este un limbaj descriptiv care permite
administratorului bazei de date sau utilizatorilor să descrie şi să denumească entităţile şi
relaţiile care se pot stabili între acestea.
Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilării declaraţiilor
în acest limbaj este constituit dintr-o serie de tabele memorate într-un Fişier special numit
dicţionar de date (se mai utilizează şi termenii de catalog de date sau director de date).
Datele memorate în acest dicţionar sunt date despre date şi de aceea se mai numesc şi
metadate. Definiţiile din dicţionarul de date se refera la înregistrări, la datele din înregistrări
şi la alte obiecte ce compun baza de date. SGBD consulta dicţionarul de date înaintea oricărui
acces la informaţii.
Teoretic, se poate identifica cate un LDD pentru fiecare nivel de abstractizare al
datelor, în realitate există un singur limbaj care tratează toate aspectele definirii datelor.
Limbajul de manipulare a datelor (LMD) furnizează un set operaţii care suporta
operaţiile de manipulare de baza asupra datelor din baza de date. Operaţii de baza sunt
inserarea, ştergerea, modificarea şi regăsirea datelor în baza de date. Manipularea datelor se
aplica la nivel conceptual şi extern.
Se cunosc doua tipuri de LMD: procedural şi non-procedural. Un LMD procedural
tratează înregistrările individual şi specifica cum trebuie obţinut rezultatul unei interogări. Cu
alte cuvinte trebuie să se specifice un algoritm de prelucrare a înregistrărilor cu ajutorul
operaţiilor puse la dispoziţie de limbaj.
În contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obţinut.
SGBD translatează cererea din limbaj non-procedural transformând-o într-o procedura sau
într-o serie de proceduri care manipulează datele conform cererii utilizatorului. Limbajele
non-procedurale sunt mai uşor de utilizat deoarece scutesc utilizatorii de la a cunoaşte
implementarea interna a structurilor de date şi de la a stabili algoritmi de obţinere a
informaţiilor.
Partea componenta a unui LMD care se refera la regăsirea datelor se numeşte limbaj
de interogare. Înţelegem prin interogare orice cerere de acces la datele din baza de date,
formulata într-un limbaj de interogare.
4GL
4GL înseamnă Fourth-Generation Language (Limbaj de Generaţia a Patra). Nu există
încă un consens asupra semnificaţiei acestei denumiri. în general 4GL desemnează un limbaj
de programare de mare rapiditate pentru programator. Ceea ce se programează în sute de linii
de program într-un limbaj de generaţia a treia, poate să constituie câteva zeci de linii de
program într-un limbaj de generaţia a patra. Limbajele 4GL sunt non-procedurale şi se
20
bazează pe tools-uri performante. Utilizatorul trebuie să definească parametri pentru aceste
tools-uri iar acestea generează programe de aplicaţie pe baza parametrilor respectivi. Un
avantaj important al utilizării limbajelor 4GL este o productivitate deosebita în programare.
Un 4GL cuprinde:
- limbaje de interogare;
- generatoare de ecrane;
- generatoare de rapoarte;
- limbaje specializate cum ar fi spreadsheet-urile şi limbajele specifice bazelor de date;
- generatoare de aplicaţii, etc.
Exemple de limbaje de interogare 4GL sunt SQL şi QBE, limbaje comerciale asupra
cărora vom reveni ulterior.
Generatoare de ecrane
Un generator de ecrane este un tool cu ajutorul căruia se pot crea uşor şi rapid ecrane
pentru culegerea (introducerea) informaţiilor necesare programelor sau chiar pentru
introducerea şi modificarea datelor din baza de date.
Generatoare de rapoarte
Un generator de rapoarte ajuta la crearea de rapoarte (liste) pornind de la datele
memorate în baza de date. Se cunosc doua tipuri de generatoare de rapoarte: orientat pe limbaj
şi orientat visual. în primul caz se utilizează comenzile unui sublimbaj pentru a defini datele
ce se vor include în raport, în al doilea caz, acelaşi lucru se realizează cu ajutorul unei
facilităţi grafice similare cu generatorul de ecrane.
Generatoare de grafice
Un astfel de generator este o facilitate care regăseşte date din baza de date şi afişează
aceste date sub forma unor grafice.
Generatoare de aplicaţii
Utilizarea unui generator de aplicaţii poate reduce timpul necesar realizării unei
aplicaţii unitare. Generatoarele de aplicaţii constau în module predefinite care cuprind
majoritatea funcţiilor de baza ce sunt prezente în majoritatea programelor. Aceste module
constituie o biblioteca de funcţii la dispoziţia utilizatorilor.
21
Să ne reamintim...
Arhitectura unui SGBD cuprinde următoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de
date;
- sistemul de gestiune al bazei de date, care este un ansamblu de
programe (soft) care realizează gestiunea şi prelucrarea
complexă a datelor;
- un set de proceduri manuale şi automate, precum şi
reglementările administrative, destinate bunei funcţionări a
întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine
informaţii despre date, structura acestora, elemente de descriere
a semanticii, statistici, documentaţie etc.
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analişti -
programatori, gestionari, operatori).
Obiectivele unui SGBD

După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea,
transmiterea, stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor electronice de
calcul, în scopul satisfacerii diferitelor nivele de conducere cu informaţii necesare luării
deciziilor, în condiţii de eficienta economica sporita.
In aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de
cerinţe prin care să se asigure:
- minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la
întrebările solicitate de utilizatori;
- adaptarea facilă a sistemului informatic la evoluţia în timp a sistemului informaţional
din care face parte;
- posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanţii de
sistem;
- posibilitatea folosirii sistemului de informare dispunând de un minim de cunoştinţe
despre modul lui de organizare în general şi despre informatica în special;
- integritatea şi securitatea datelor etc.
In acest context, sistemului de gestiune al bazei de date îi revin o serie de obiective, cum sunt:
1. Asigurarea independenţei datelor.
Aşa cum am arătat mai devreme, acest obiectiv consta în linii mari din îndeplinirea următoarei
cerinţe: modificările care se fac la un anumit nivel de structura de date nu trebuie să fie
'vizibile' la nivelul de organizare imediat superior.
22
2. Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.
Spre deosebire de sistemele clasice de prelucrare automata a datelor, stocarea datelor în cazul
bazelor de date se face astfel încât, pe cât posibil, fiecare informaţie să apară o singură dată.
Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performante sporite (mai ales în
ce priveşte timpul de acces la date şi implicit, timpul de răspuns la solicitările utilizatorilor) să
se accepte o anumita redundanta a datelor. în acest caz se va institui insa un control automat al
redundantei în vederea asigurării coerenţei datelor din baza.
3. Asigurarea unor facilităţi sporite de utilizare a datelor . Aceasta presupune:
- folosirea datelor de câtre mai mulţi utilizatori în diferite scopuri (aplicaţii);
- accesul cât mai simplu al utilizatorilor la date, fără ca aceştia să fie nevoiţi să cunoască
structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei
de date;
- existenta unor limbaje performante de regăsire a datelor, care permit exprimarea cu
uşurinţă a criteriilor de selecţie a datelor şi indicarea unor reguli cât mai generale pentru
editarea informaţiilor solicitate;
- spre deosebire de sistemul tradiţional bazat pe Fişiere, unde există un singur criteriu
de adresare (cel care a stat la baza organizării Fişierului) în cazul bazelor de date,
sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial, fără sortări
suplimentare. Modificarea criteriului la fişierele clasice implică, în majoritatea
cazurilor, reorganizarea lor;
- utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării
bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod
facil a bazei de date şi de câtre utilizatorii neinformaticieni.
4. Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele.
Administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai prin
canale corespunzătoare, şi poate, totodată, defini verificări de autorizare care să se realizeze
oricând se încearcă accesul la anumite date.
5. Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,
prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor
proceduri de refacere a bazei de date după incidente.
6. Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie înţeleasă nu numai sub
aspectul asigurării accesului mai multor utilizatori la aceleaşi date, ci şi sub acela al
posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.
Să ne reamintim...
Obiectivele unui SGBD sunt:

Asigurarea independentei datelor.
Asigurarea unei redundante minime şi controlate a datelor din
baza de date.
Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta
presupune:
Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate
sau neintenţionate.
Asigurarea partajabilităţii datelor.
23
Funcţiile unui SGBD
Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea
numeroaselor operaţii necesare funcţionării optime a sistemului. În funcţie de natura lor şi de
scopul urmărit, operaţiile pot fi grupate pe activităţi. Activităţile acceptă şi ele o grupare pe
funcţii (una sau mai multe activităţi, relativ omogene, re alizează o anumita funcţie).
Ţinând seama de complexitatea sistemului de gestiune, de facilităţile oferite de acesta, de
limbajele utilizate şi de tipul bazei de date ce urmează a fi gestionată de SGBD, gruparea
activităţilor pe funcţii are un oarecare caracter relativ. În situaţia sistemelor de gestiune ce
utilizează limbaje gazdă de nivel înalt, identificarea şi delimitarea funcţiilor nu este atât de
evidentă. Totuşi, în ciuda acestor particularităţi, se pot prezenta câteva funcţii cu caracter de
generalitate pentru toate sistemele de gestiune a bazelor de date şi anume:
1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul
limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic.
Aceasta funcţie asigură:
- descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,
- descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiaşi
entităţi,
- definirea eventualelor criterii de validare a datelor,
- definirea metodelor de acces la date,
- definirea aspectelor referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc.
Toate acestea se concretizează în schema bazei de date, memorată în cod intern.
2. Funcţia de manipulare a datelor este cea mai complexa funcţie şi realizează următoarele
activităţi:
- crearea (încărcarea) bazei de date;
- adăugarea de noi înregistrări;
- ştergerea unor înregistrări;
- modificarea valorilor unor câmpuri;
- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc.
Funcţia de manipulare a datelor se realizează prin intermediul limbajului de
manipulare a datelor.
3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor
utilizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Aceştia reprezintă categoria beneficiarilor de
informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date într-o
formă simplistă. Ei apar ca utilizatori neinformaticieni;
- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea
ce priveşte funcţionarea optimă a întregului ansamblu.
24
4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de
competenţa administratorului bazei de date.
Să ne reamintim...
Funcţiunile unui SGBD sunt:

Funcţia de descriere a datelor permite definirea structurii bazei de
date cu ajutorul limbajului de definire.
Funcţia de manipulare a datelor.
Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date.
Funcţia de administrare a bazei de date apare ca o funcţie
complexă şi este de competenţa administratorului bazei de date.
M1.U1.6. Rezumat
Arhitectura unui SGBD cuprinde următoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de date;
- sistemul de gestiune al bazei de date, care este un ansamblu de
programe (soft) care realizează gestiunea şi prelucrarea complexă
a datelor;
- un set de proceduri manuale şi automate, precum şi
reglementările administrative, destinate bunei funcţionări a
întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine
informaţii despre date, structura acestora, elemente de descriere a
semanticii, statistici, documentaţie etc.
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analişti -
programatori, gestionari, operatori).
Obiectivul informaticii îl constituie culegerea, verificarea, transmiterea,
stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor
electronice de calcul, în scopul satisfacerii diferitelor nivele de
conducere cu informaţii necesare luării deciziilor, în condiţii de
eficienta economica sporita.
Obiectivele sunt:
Asigurarea independentei datelor.
Acest obiectiv consta în îndeplinirea cerinţei ca modificările care se fac
la un anumit nivel de structura de date să nu fie 'vizibile' la nivelul de
organizare imediat superior.
Asigurarea unei redundante minime şi controlate a datelor din
25
baza de date.
Pe cât posibil, fiecare informaţie să apară o singură dată. Nu sunt
excluse nici cazurile în care să se accepte o anumită redundanţă a
datelor.
Asigurarea unor facilităţi sporite de utilizare a datelor.
Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau
neintenţionate, prin intermediul unor proceduri de validare, a unor
protocoale de control concurent şi a unor proceduri de refacere a bazei
de date după incidente.
Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie
înţeleasă şi sub aspectul posibilităţii dezvoltării unor aplicaţii fără a se
modifica structura bazei de date.
Funcţiunile unui SDGBD sunt
Funcţia de descriere a datelor care permite definirea structurii bazei
de date cu ajutorul limbajului de definire.
Funcţia de manipulare a datelor este cea mai complexă funcţie şi
realizează următoarele activităţi:
- crearea (încărcarea) bazei de date;
- adăugarea de noi înregistrări;
- ştergerea unor înregistrări;
- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări
virtuale etc.
Funcţia de manipulare a datelor se realizează prin intermediul
limbajului de manipulare a datelor.
Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date. Sunt recunoscute mai
multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Ei apar ca utilizatori
neinformaticieni;
- utilizatori programatori, care utilizează limbajele de manipulare,
realizând proceduri complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are
rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului
ansamblu.
Funcţia de administrare a bazei de date apare ca o funcţie complexă
şi este de competenţa administratorului bazei de date.
1.3.1 Care sunt obiectivele unui SGBD?
1.3.2 Care sunt funcţiunile unui SGBD?
26
Unitatea de învăţare 1.4 Baze de date distribuite
M1.U1.4 Introducere
O baza de date distribuită (BDD) este o colecţie logic corelată de date
partajate, distribuite fizic pe o reţea de calculatoare.
Un sistem de gest iune al unei baze de date distribuite (SGBDD) este un
sistem software care permite gestionarea BDD şi face distribuirea transparentă
pentru utilizator.
Sistemele de date distribuite sunt menite să rezolve problema "insulelor de
informaţii". Ele au apărut ca o necesitate, în special in cazul reţelelor de
calculatoare, pentru a sprijini gestionarea datelor în situaţia când acestea se
regăsesc fizic în diferite puncte ale reţelei.

 înţeleagă ce este o bază de date distribbuită
 cum se proiectează o bază de date distribuită
Durata medie de parcurgere a primei unităţi de învăţare este de 2 o re.
Generalităţi
Primele sisteme de baze de date distribuite au fost INGRES/STAR, versiune
distribuită a lui INGRES, SQL*STAR versiune distribuită a lui ORACLE şi R* versiune
distribuita a lui DB2.
Sistemul fizic (reţeaua) care constituie suportul unei baze de date distribuite poate fi
format din calculatoare personale, minicomputere, staţii de lucru, etc. toate legate în reţea şi
numite generic site-uri.
Putem reformula definiţia de la început spunând ca un sistem de baze de date
distribuite constă dintr-o colecţie de site-uri, fiecare putând participa la executarea
tranzacţiilor care accesează datele de pe un site sau de pe mai multe site -uri.
Printre cerinţele pe care trebuie să le asigure un sistem de baze de date distribuite
menţionăm: autonomia locala în organizarea şi prelucrarea datelor, neutilizarea unei
centralizări a evidenţei şi a datelor, posibilitatea de lucru continuu al site-urilor independent
de schimbările in configuraţiile de lucru (adăugari sau eliminari de site-uri), independenţa
localizării şi fragmentării datelor (transparenţa fizică), posibiliăţti de replicare (copiere) şi
independenţa copiilor, prelucrarea distribuită a cererilor, administrarea distribuită a
tranzacţiilor, independenţa de hardware, de sistemul de operare, de reţea şi de sistemul de
gestiune a bazelor de date.
27
Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente,
eventual unele fragmente sunt multiplicate, şi fiecare fragment sau copie se pastrează pe unul
sau mai multe site-uri, sub controlul unui SGBD local. Fiecare site este capabil sa proceseze
interogări utilizator în regim local, independent de restul reţelei, sau este capabil să participe
la procesarea unor date situate în alte site-uri din reţea. Pentru a spune că un SGBD este
distribuit trebuie să existe cle puţin o cerere globală.
Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi
tranzacţii globale după site-urile pe care le solicită excutarea lor.
O configuratie pe retea reprezinta o baza de date distribuita daca diversele site-uri sunt
"constiente" de existenta celorlalte site-uri şi daca fiecare site ofera un mediu in care se pot
executa tranzactii locale şi globale.
Avantajele distribuirii bazelor de date:
- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor
organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de
vedere geografic
- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală
- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se
semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să
continue să funcţioneze în condiţii satisfăcătoare
- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând
replici aflate pe alte site-uri
- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în
paralel a unor interog[ri
- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile
implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem
centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest
lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la
nevoile organiza’iei (dac[ de exemplu este necesară adăugarea unor site-uri în plus) decât
un calculator central de putere asemănătoare
- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau
rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta
deloc) mersul activităţilor pe ansamblul sistemului distribuit.
Printre dezavantajele distribuirii amintim complexitatea crescuta a unui astfel de sistem.
Acesta este un dezavantaj major din care decurg unele dezavantaje "consecinta" dintre care:
- este mai greu de gestionat şi de implementat un sistem distribuit
- costurile legate de un astfel de sistem sunt mult mai mari decat in cazul centralizat. Deja la
nivelul proiectarii şi implementarii sistemului este necesar mai mult timp şi personal
specializat. Ambele lucruri necesita costuri mai mari in bani. La aceste costuri se pot
adauga acelea care vin din necesitatea asigurarii echipamentelor hardware performante şi
a soft-ului necesar. De asemenea, in cazul exploatarii sistemului la costurile obisnuite se
vor adauga costuri destul de ridicate de comunicatii.
- potential marit de erori. La erorile obisnuite in lucrul cu baze de date se pot adauga o serie
de erori cum ar fi de exemplu cele generate de algoritmi distribuiti.
28
- este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre site-
uri şi a coordonarii acestora in general
- securitatea unui sistem distribuit este mai greu de asigurat decat in cazul unui sistem
centralizat. Datele sunt mai usor disponibile unor persoane neautorizate deoarece se poate
incerca acces la ele prin intermediul accesului intre calculatoare. Controlul la nivel fizic
administrativ are mai putina pondere decat in cazul unui sistem centralizat.
- intergitatea datelor este de asemenea mai greu de realizat intr-un sistem distribuit.
Integritatea se exprima de obicei in termeni de restrictii (reguli, conditii) pe care trebuie sa
le verifice datele din baza de date. Datorita costurilor mari de comunicatii (in timp şi bani)
uneori se renunta la verificarea unor reguli in detrimentul consistentei bazei de date.
- lipsa standardelor. Nu se poate vorbi de o lipsa totala de standarde dar, lucrul cu sisteme
de date distribuite inca nu are la baza standarde internationale unanim acceptate. De aici
decurg dezavantaje cum ar fi: probleme de comunicare care se pun deoarece standardele
de comunicatii şi protocoalele de acces la date inca nu au standarde fixate şi acceptate pe
scara larga. Nu exista foarte multa experienta privind lucrul distribuit şi proiectarea,
gestionarea şi exploatarea unui sistem distribuit sunt mai dificile decat in cazul centralizat.
- un alt dezavantaj pe care il mentionam aici il constituie posibilitatea aparitiei unui flux
mare de informatii intre site-uri şi de aici necesitatea rezolvarii unor probleme cum ar fi
sincronizarea mesajelor, detectarea şi corectarea unor perturbari, eliminarea unor
inconsistente datorate redundantelor, etc.
Functiile şi arhitectura unui SGBDD
Enumeram mai jos functiile principale ale unui SGBDD:
- toate functiile pe care le atribuim unui SGBD centralizat
- sa extinda comunicatiile pentru a furniza acces la site-urile din retea şi sa permita
transferul de date şi realizarea interogarilor
- sa gestioneze un dictionar de date extins pentru detalii legate de modul de distribuire a
datelor
- sa permita şi sa sustina procesarea distribuita a interogarilor
- sa faciliteze un control extins al concurentei in scopl mentinerii unui grad satisfacator al
consistentei datelor
- sa ofere servicii de recovery extinse care sa rezolve caderi ale site-urilor şi ale
comunicatiilor
Arhitectura ANSI-SPARC pe trei nivele a unei baze de date distribuite este redata grafic in
pagina urmatoare, Fig 7.1. Dam mai jos cateva explicatii referitoare la unele elemente
prezente in schema:
- schema conceptuala globala este o descriere logica a intregii baze de date, fara a se
evidentia aspectul distribuit. La acest nivel se definesc entitatile, relatiile, restrictiile de
integritate, informatiile generale de securitate a datelor.
- schemele de fragmentare descriu modelul logic al partitionarii bazei de date iar alocarea
descrie repartizarea fragmentelor şi a eventualelor copii ale acestora pe site -urile retelei
- schemele locale de mapare redau fragmentele din schema de alocare in "obiecte" externe
bazei de date locale. Aceasta descriere este independenta de SGBD-ul ales şi datorita
acestui fapt se poate vorbi de SGBD heterogene.
29
Ca o paranteza mentionam aici clasificarea SGBD-urilor distribuite in heterogene şi
omogene.
SGBD omogene reprezinta situatia cand pe toate site-urile din retea este hardware similar,
sistem de operare identic si, cel mai important, SGBD local identic.
În cazul SGBD heterogene exista mai multe situatii dupa cum difera dotarea hardware,
sistemele de operare si/sau SGBD-urile utilizate local pe site-uri. Diferentele pot fi impinse
pana la a avea structuri ale bazei de date diferite (date de modele de date diferite) dar, evident,
lucrul in acest caz este destul de greoi şi este supus multor limitari.
În cadrul unui SGBDD putem identifica urmatoarele componente:
- o componentă locală SGBD (LSGBD)
- o componentă de comunicaţii de date (CD)
- un dicţionar de date global (DDG). Acest dicţionar are aceeaşi funcţionalitate ca şi und
dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare
la fragmentare şi la alocarea datelor. Şi DDG poate fi fragmentat şi replicat ca orice altă
informaţie din baza de date distribuită
- componente de SGBD distribuit (SGBDD)
Proiectarea unei baze de date relaţionale distribuite

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele
cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate
pe diferite site-uri în reţea
- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor
- alocarea fragmentelor şi a replicilor pe diferite site-uri
Definirea fragmentelor şi alocarea acestora pe site-uri au ca obiective:
- realizarea, pe cat posibil a accesului in regim de referinte locale. Acolo unde este necesar
şi unde permite aplicaţia se recomanda utilizarea de copii ale fragment elor
- obtinerea unei fiabilitati şi a unei disponibilitati deosebite ale bazei de date prin utilizarea
optima a replicarii fragmentelor
- realizarea unor parametri deosebiti de performanta. Daca se aloca prost datele pe site-uri
se ajunge fie la suprasolicitarea unui site (loc ingust) fie la utilizarea resurselor la un nivel
inferior
- optimizarea capacitatii şi a costurilor de stocare. Capacitatea şi costuril de stocare trebuie
puse in balanta cu tendinta de a avea referinte locale, deoarece au efecte contrare.
- optimizarea costurilor de comunicare. Aici sunt de luat in considerare mai ales costurile
interogarilor intre site-uri. Trebuie sa se aiba in vedere ca, daca se pot micsora costurile de
regasire atunci cand referintele sunt mai ales locale (sau cand fiecare site are propriile
copii ale datelor) in schimb actualizarile in aceeasi situatie pot creşte costurile foarte mult
(si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate
site-urile.
Alocarea datelor
30
Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:
1. centralizat
Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur
DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai
este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales
costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în
vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga
activitate în reţea pe această direcţie.
2. fragmentat (partiţionat)
Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale
- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat
- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute
3. replicat complet
Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:
- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime
- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de
actualizare
4. replicat selectiv
Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de
a se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.
Definirea replicilor şi a fragmentelor, precum şi alocarea acestora trebuie sa se bazeze pe
modul de utilizare a datelor din baza de date. In faza de analiza, la proiectarea bazei de date
trebuie sa se tina cont de cele mai frecvent utilizate aplicaţii deoarece nu se poate realiza o
alocare care sa optimizeze toate aplicaţiile simultan.
Printre criteriile care duc la decizia corecta de alocare a bazei de date:
- frecventa cu care se ruleaza o aplicaţie
- site-urile de la care se ruleaza cel mai frecvent aplicaţia
- modul de lucru al tranzactiilor executate de aplicaţie şi tipurile de acces la date
- etc.
Fragmentarea
La baza fragmentarii bazei de date exista, printre altele, urmatoaele motivari:
- mod de utilizare – in general intr-o aplicaţie utilizatorii au acces mai mult la view-uri
decat la intreaga baza de date
- eficienta – se doreste ca datele sa fie stocate acolo unde sunt utilizate mai frecvent
- paralelism – o tranzactie poate fi divizata in mai multe subinterogari care opereaza pe
fragmente in paralel şi astfel se castiga timp
31
- securitate – datele care nu sunt necesare sunt stocate in alta parte, deci nu sunt la
dispozitia accesului neautoarizat
Dezavantajele lucrului cu fragmente ale bazei de date:
- performantele pot fi destul de scazute daca sunt necesare date ce apar in diverse
fragmente
- controlul integritatii datelor este mai dificil daca datele şi dependentele functionale
sunt fragmentate şi localizate pe diferite site-uri
Reguli de bază care duc la o fragmentare corectă a bazei de date:
1. completitudine – dacă relaţia R este descompusă în fragmentele R 1, R 2, …,R n, trebuie
luate măsuri care să prevină pierderea de informaţii
2. reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit
cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.
3. disjuncţie – dacă data di apare în fragmentul R i atunci nu este permis să apară în nici
un alt fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie
este fragmentată pe verticală.
Tipuri de fragmentare:
- pe orizontală
- pe verticală
- combinată
Fragmentarea pe orizontală:
Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:
Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor

relaţiei respective.
Un fragment orizontal se produce prin selecţie:
Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte
reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.
R= R 1R2…Rn
In general fragmentele unei relaţii R sunt disjuncte.
Fragmentarea pe verticală
Un fragment vertical dintr-o relaţie consta dintr-o relaţie care are ca atribute o submulţime a
atributelor relaţiei iniţiale.
Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci r1   S1 ( R) şi r2   S 2 ( R) .
32
Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din
submulţimile S1 şi S2.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.
r ( R )  r1 X N r2
Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care
asigură o descompunere fără pierderi la joncţiune.
In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se
admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare
(respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinităţilor
între atribute, încă din faza de analiză.
Fragmentarea combinată (mixtă, hibridă, compusă)
1. fragmente verticale fragmentate orizontal
Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai
sus) este:  P ( A1 ,..., An ( R))
2. fragmente orizontale fragmentate vertical
Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai
sus) este:  A1 ,..., An ( P ( R))
Transparenţa în SGBDD
Prima regula, considerată regula de baza in sistemele distribuite, este cerinta ca
aspectul distribuit trebuie sa fie transparent pentru utilizator.
Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date
distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de
baze de date.
În realitate transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de
transparenţă:
1. transparenţa distribuirii
2. transparenţa tranzacţiilor
3. transparenţa performanţelor
Transparenţa distribuirii
33
Dacă se realizează transparenţa distribuirii, utilizatorul percepe baza de date ca pe o
entitate unitară din punct de veder logic.
Acest tip de transparenţă se poate descompune în două aspecte: utilizatorul nu trebuie
să cunoască faptul că există fragmentarea datelor (transparenţa fragmentării) sau utilizatorul
nu ştie de localizarea datelor pe reţea (transparenţa localizării).
Transparenţa fragmentării este cel mai înalt grad de transparenţa. Utilizatorul se
adresează cu interogări bazei de date ca şi când ar fi localizată centralizat, deci nu trebuie să
se preocupe de existenţa fragmentelor.
Transparenţa fragmentării este strâns legată de acordarea numelor (identificatorilor) în
cadrul bazei de date distribuite. Şi într-o bază de date distribuită (ca şi în cazul centralizat)
numele diferitelor "obiecte" trebuie să fie unic. Două site-uri nu pot conţine obiecte cu nume
identice.
Sunt cateva solutii posibile:
1. Se poate crea un server central de nume care are menirea sa sigure ca numele date in
aplicaţii distribuite sunt nume unice pe toata baza de date. Aceasta abordare are
dezavantajele ca se pierde autonomia locala a site-urilor, se poate ajunge la o
suprasolicitarea serverului de nume (se creeaza un asa-numit loc ingust - "bottleneck") şi
disponibilitatea bazei de date este redusa (daca serverul de nume iese din uz temporar, se
blocheaza accesul la date)
2. Alternativa la solutia de mai sus este sa se recurga la prefixarea obiectelor cu un
identificator de site, de fragment, de copie.
Exemple
Prin notatia s1.client.f3.c2 se poate desemna copia a doua a
fragmentului 3 a tabelei client care se afla pe site-ul s1.
Consecinta cea mai grava a acestui mod de a numi obiectele este pierderea completa a
transparentei. In aceasta situatie mai exista un mod prin care se poate "indulci" situatia: se
utilizeaza alias-uri. De exemplu s1.client.f3.c2 poate avea ca alias numele client_local pentru
utilizatorii site-ului s1.
Transparenta localizarii reprezinta un nivel mediu de transparenta. In aceasta situatie
utilizatorul stie cum este fragmentata baza de date dar nu stie unde sunt plasate diferitele
fragmente sau copii ale acestora.
În interogari vor aparea numele fragmentelor dar nu se vor face referiri la localizare. O
interogare poate avea un format asemanator cu cel de mai jos:
select A1,…An
from f1
where conditie1
union
select A1,…An
from f2
………
Avantajul major in cazul de mai sus consta in faptul ca se poate oricand reorganiza
baza de date (ca locatii) fara ca aplicaţiile ce o utilizeaza sa trebuiasca modificate.
34
Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite.
Utilizatorul trebuie sa specifice şi numele fragmentelor şi localizarea datelor.
Transparenţa tranzacţiilor
Acest tip de transparenţa asigură faptul că toate tranzacţiile distribuite păstrează
integritatea şi consistenţa BDD.
O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Fiecare
tranzacţie e divizata în sub-tranzacţii, câte una pentru fiecare site accesat. Sub-tranzacţiile se
execută în paralel pe site-uri şi în mod concurent pe fiecare site. SGBDD are sarcini deosebite
în legătură cu gestionarea tranzacţiilor distribuite dar acestea nu vor fi tratate in acest capitol.
În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa
concurenţei şi transparenţa erorilor. SGBDD oferă transparenţă concurenţei dacă rezultatele
tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic
echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând, într-o
ordine serială arbitrară.
Transparenţa erorilor necesită şi un mecanism de recovery care ne să asigure că
tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei
tranzacţii ori nici o operaţie nu este executată. Odată ce o tranzacţie s-a executat,
transformările operate de ea asupra bazei de date sunt durabile (permanente).
Transparenţa performanţelor
Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă
performanţe comparabile cu ale unui sistem centralizat. În această situaţie trebuie ca SGBDD
să determine strategia cea mai eficientă de a executa fiecare interogare în parte. În acest scop
un DQP (Distributed Query Processor) mapeaza o cerere de date într-o secvenţă ordonată de
operatii asupra bazei de date. DQP decide ce fragment se accesează, ce copie se utilizează,
care locaţie se utilizează. DQP produce o strategie de execuţie care este optimizată relativ la o
funcţie de cost. Costul asociat cu o interogare distribuita include:
- timp de acces (input/output) la accesarea datelor fizice pe suportul respectiv,
- timp CPU la executatrea operatiilor asupra datelor in memoria principala,
- costuri de comunicatii asociate cu transmiterea datelor prin retea.
M1.U1.6. Rezumat
O baza de date distribuită (BDD) este o colecţie logic corelată de date partajate,
distribuite fizic pe o reţea de calculatoare.
Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi
tranzacţii globale după site-urile pe care le solicită excutarea lor.
Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă
cerinţele cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi
stocate pe diferite site-uri în reţea
35
Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională
distribuită:
centralizat
fragmentat (partiţionat)
replicat complet
replicat selectiv
Tipuri de fragmentare:
- pe orizontală
- pe verticală
- combinată
Prima regula, considerata regula de baza in sistemele distribuite, este cerinta ca
aspectul distribuit trebuie sa fie transparent pentru utilizator.
Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date
distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei
astfel de baze de date.
În realitate transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de
transparenţă:
 transparenţa distribuirii
 transparenţa tranzacţiilor
 transparenţa performanţelor

1.4.1 Ce este o bază de date distribuită?
1.4.2 Care sunt avantajele unui sistem distribuit?
1.4.3 Cum se poate face proiectarea alocării datelor?
1.4.4 Cum se face o fragmentare corectă?
1.4.5 Ce este fragmentarea?
36
Modulul 2. Modele de descriere a datelor
Cuprins
Introducere
Obiectivele modulului
U2.1 Generalităţi
U2.2 Modelare E-R (Entity-Relaţionship)
Introducere
Numim model de date o colecţie integrată de concepte pentru
descrierea datelor, de relaţii între date şi de restricţii asupra datelor,
toate într-o organizare unitară.
Un model de date este o abstracţie. Un model de date are în
principal rolul de a furniza conceptele de bază şi notaţiile care să
permită proiectanţilor şi utilizatorilor bazei de date să comunice în
mod neambiguu legat de modul de organizare a datelor.

 aleagă ce model de date vor folosi pentru baza concretă de date
 distingă modele la diferite nivele
 descrie structura bazei de date cu ajutorul unui model grafic
 să aleagă cheia unei relaţii în mod optim
37
Unitatea de învăţare 2.1. Generalităţi
Un model de date cuprinde trei părţi:
(1) o parte referitoare la structură, care constă într-un set de reguli ce impun
modul de alcătuire al bazei de date;
(2) o parte referitoare la manipularea datelor, care defineşte tipul de operaţii care
sunt permise asupra datelor. Sunt incluse aici operaţiile care sunt utilizate
pentru a actualiza sau a regăsi datele în baza de date precum şi operaţiile
pentru schimbarea structurii bazei de date;
(3) o parte referitoare la integritatea datelor, parte care cuprinde reguli de
integritate care asigura acurateţea datelor.

 aleagă ce model de date vor folosi pentru baza concretă de date
 distingă modele la diferite nivele
Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.
Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel putem vorbi de:
 model extern de date (care reprezintă aşa-numitul univers al discursului, adică punctul de
vedere al utilizatorului);
 model de date conceptual (care reprezintă structura logica a bazei de date, independenta de
sistemul de gestiune ales);
 model de date intern (care reprezintă schema conceptuala într-un mod în care poate fi
perceputa de SGBD).
Dintre diversele modele propuse în literatura de specialitate menţionam aici: modelele de
date bazate pe obiecte, modelele de date bazate pe înregistrare, ambele modele fiind utilizate
pentru descrierea organizării datelor la nivel extern şi conceptual. Trebuie să menţionam şi
modelele fizice de date, care descriu datele la nivel intern.
Aceste modele utilizează concepte specifice modelului E-R şi anume: entităţi, atribute,
relaţii. Cele mai cunoscute modele de date sunt: modelul entitate-relaţie, modelul semantic,
modelul funcţional, modelul orientat obiect.
Modele de date bazate pe înregistrare
Într-un astfel de model baza de date consta dintr-un număr de înregistrări de format fix
de tipuri eventual diferite. Fiecare tip de înregistrare defineşte un număr fix de câmpuri,
38
fiecare fiind în general de lungime fixa. Exista trei tipuri importante de modele de date bazate
pe înregistrare: modelul de date relaţional, modelul de date reţea şi modelul ierarhic de
date.
Modelele ierarhic şi reţea au fost dezvoltate mai întâi, modelul relaţional apărând cu o
întârziere de un deceniu.
Modele fizice de date

Aceste modele descriu efectiv modul în care datele sunt memorate în calculator, la
nivel fizic. Informaţia furnizata de aceste modele este cea referitoare la înregistrările fizice, la
căi de acces, la organizarea înregistrărilor, etc.
Se considera că schema conceptuala sta la baza structurării unei baze de date. O

schema conceptuala completa şi bine gândită permite o reprezentare interna eficienta şi
permite realizarea de view-uri utilizator fără dificultate.
Modelarea conceptuala sau proiectarea conceptuala a bazei de date este procesul de
construire a unui model care să reprezinte modul în care este utilizata informaţia de câtre
beneficiar, reprezentare care este independenta de detaliile de implementare cum ar fi
programele de aplicaţie, limbajele de programare, SGBD-ul utilizat sau orice alte consideraţii
fizice. Un astfel de model se numeşte model de date conceptual sau model logic.
Modelare E-R (Entity-Relaţionship)

Modelul E-R (Entity-Relaţionship) este un model conceptual de nivel înalt, dezvoltat
de Chen în 1976. Primele idei legate de utilizarea modelului E-R la proiectarea unei baze de
date au fost expuse de Chen (1977) şi au fost continuate de Sakai (1980). Conceptele de
specializare şi generalizare au fost introduse de Smith şi Smith (1977) şi au fost utilizate
ulterior de Lenzerini şi Santucci (1983) la definirea restricţiilor de cardinalitate. Având în
vedere limitele modelului E-R, vom discuta un model mai complex, modelul EE-R şi
conceptul principal asociat acestuia, conceptul de specializare/generalizare.
M2.U2.1. Rezumat
Putem vorbi de:

 model extern de date (adică punctul de vedere al utilizatorului);
 model de date conceptual (care reprezintă structura logica a bazei de date,
independenta de sistemul de gestiune ales);
 model de date intern (care reprezintă schema conceptuala într-un mod în care
poate fi perceputa de SGBD).
Modelele de date bazate pe obiecte sunt: modelul entitate-relaţie, modelul
semantic, modelul funcţional, modelul orientat obiect.
Exista trei tipuri importante de modele de date bazate pe înregistrare: modelul de
date relaţional, modelul de date reţea şi modelul ierarhic de date.
Modele fizice de date descriu efectiv modul în care datele sunt memorate în
calculator, la nivel fizic.
39
2.1.1 Care sunt modele de date bazate pe înregistrare?
40
Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship)
Modelul E-R constituie un mod de reprezentare a bazelor de date relaţionale
şi de aceea este un instrument util în proiectarea acestora. În acest capitol, vom
descrie conceptele primare care stau la baza modelului E-R, după care vom
identifica problemele care pot apărea prin utilizarea unui astfel de model. Vom
discuta de asemenea problemele generate prin utilizarea modelul E-R la
reprezentarea unor aplicaţii.

 descrie structura bazei de date cu ajutorul unui model grafic
 să aleagă cheia unei relaţii în mod optim
Durata medie de parcurgere a primei unităţi de învăţare est e de 3 ore.
Concepte de bază
Conceptele primare ale modelului E-R includ : tip de entitate (mulţime-entitate), tip de
relaţie (mulţime-relaţie), atribute.
Numim entitate un obiect sau un concept ce se poate identifica în mod unic.
Noţiunea de entitate este un concept de baza în cadrul modelului E-R. Ea reprezintă 'obiecte'
concrete (cu existenta fizica) sau abstracte (cu existenta conceptuala).
Exemple
 Popescu Ion, posesor al buletinului de identitate seria ABC, numărul: 444555
este o entitate deoarece identifica în mod unic o persoana în acest univers.
Ce este studentul Ion Ion?
Ce este grupa 7172?
O entitate care reprezintă un obiect ceva mai abstract poate fi, de exemplu, un cont la
banca identificabil în mod unic prin numărul sau şi numele băncii.
Numim tip de entitate sau mulţime-entitate un set de entităţi de acelaşi tip.
Exemple
Mulţimea tuturor persoanelor care sunt studenţi ai Facultăţii de Ştiinţe pot defini
mulţimea-entitate sau tipul de entitate student.
Mulţimea tuturor profesorilor Facultăţii de Ştiinţe formează ce?
41
Tipul de entitate reprezintă o mulţime de 'obiecte' ce aparţin lumii reale şi care sunt descrise
de aceleaşi proprietatea.
Orice obiect care aparţine unui tip de entitate şi care este identificabil în mod unic este numit
simplu entitate. (se mai întâlnesc denumirile: apariţia unei entităţi sau instanţa unei entităţi).
Un tip de entitate conţine mai multe entităţi. O baza de date este o colecţie de tipuri de entitat e
din care fiecare conţine un număr neprecizat de entităţi de acelaşi tip.
Tipurile de entitate nu sunt neapărat disjuncte. Aceasta înseamnă că pot exista entităţi care să
aparţină mai multor tipuri de entitate.
Exemple
Se pot defini următoarele tipuri de entitate: profesor, corespunzător tuturor
cadrelor didactice ale Facultăţii de Ştiinţe şi student, corespunzător tuturor
studenţilor aceleiaşi facultăţi. Se observa uşor că pot exista studenţi care sunt
în acelaşi timp şi cadre didactice (studenţi la master care sunt preparatori sau
asistenţi).
Arătaţi că nici tipurile de entitate personal auxiliar şi profesor nu sunt

disjuncte.
Un tip de entitate se identifică printr-un nume şi o listă de proprietatea. O bază de date

conţine în general mai multe tipuri de entităţi.
Numim atribute proprietăţile ataşate unui tip de entitate.
Exemple
Entitatea student poate fi descrisă de atributele: nume_student,
prenume_student, data_nasterii, sex, adresa, telefon, număr_matricol, grupa.
Cum aţi descrie entitatea materii?
Prin domeniul atributului înţelegem mulţimea valorilor care pot fi atribuite unui atribut
simplu.
Atributele unei entităţi conţin valorile care descriu fiecare entitate şi cu ajutorul cărora fiecare
entitate se poate identifica în mod unic. Aceste valori reprezintă cea mai mare parte a datelor
memorate într-o baza de date.
Domeniul unui atribut nu se poate defini întotdeauna foarte exact. De exemplu, atributul
nume_student trebuie să fie un şir de caractere dar poate lua ca valori doar un nume de familie
existent. Unele domenii se pot descompune în mai multe subdomenii. De exemplu
data_naşterii se poate descompune în subdomeniile: an, lună, zi.
In general putem considera că fiecare entitate este reprezentabila cu ajutorul unei mulţimi de
perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut ataşat
tipului de entitate corespunzător.
42
Exemple
O entitate a tipului de entitate student poate fi reprezentata de mulţimea:
{(nume_student, Popescu), (prenume_student, Ion), (data_nasterii, 15.11.1981),
(sex, masculin), (adresa, B-dul Garii, 12, Brasov, cod 2200, judetul Brasov),
(telefon, 068/444555), (număr_matricol, 31455), (grupa, 7211)}
Reprezentaţi o entitate a tipului de entitate materii.
Atributele se pot clasifica în simple sau compuse; cu o singură valoare sau cu mai multe
valori; respectiv derivate.
Numim atribut simplu orice atribut care are doar o singură componentă şi o existenţă
independentă.
Aceste atribute nu se pot diviza în mai multe atribute distincte. Ele se mai numesc şi atribute
atomice.
Exemple
Atributul sex corespunzător tipului de entitate student.
Arătaţi alte atribute simple ale tipului de entitate materii.
Numim atribut compus orice atribut care are mai multe componente, fiecare cu o existenţă
independentă.
Aceste atribute se pot diviza în general în mai multe atribute simple.
Exemple
Atributul adresă se poate descompune în atributele: strada, număr, oraş,
cod_poştal şi judeţ.
Arătaţi alte atribute compuse.
Decizia ca un atribut compus să se descompună în mai multe atribute simple este dependentă
de modul în care se va utiliza acel atribut: pe componente, sau ca un întreg.
Numim atribut cu o singură valoare orice atribut care poate lua cate o singură valoare
pentru fiecare entitate.
Majoritatea atributelor sunt atribute cu o singură valoare.
Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru
fiecare entitate.
Pentru atributele cu mai multe valori trebuie precizate numărul minim şi numărul maxim de
valori pe care le poate lua atributul respectiv.
Exemple
Atributul telefon poate fi un atribut cu mai multe valori. În acest caz se poate
limita de exemplu numărul numerelor de telefon la care poate fi găsit studentul la
43
minim 0 şi la maxim 3. Deci se pot stabili numărul minim şi numărul maxim de
valori pe care le poate lua atributul.
Arătaţi alte atribute cu mai multe valori.
Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai
multe alte atribute. Aceste atribute nu trebuie neapărat să descrie entitatea căreia ii corespunde
atributul derivat.
Exemple
Valoarea pentru atributul vârsta este derivată din valoarea atributului
data_naşterii şi din data curentă.
Arătaţi alte atribute derivate.
Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile

înregistrate.
Să ne reamintim...
 entitate care reprezintă un obiect ceva mai abstract poate fi, de
exemplu, un cont la banca identificabil în mod unic prin numărul sau şi
numele băncii.
 Numim tip de entitate sau mulţime-entitate un set de entităţi de
acelaşi tip.
 Prin domeniul atributului înţelegem mulţimea valorilor care pot fi
atribuite unui atribut simplu.
 Numim atribut simplu orice atribut care are doar o singură componentă
şi o existenţă independentă
 Numim atribut compus orice atribut care are mai mu lte componente,
fiecare cu o existenţă independentă.
 Numim atribut cu mai multe valori orice atribut care poate lua mai
multe valori pentru fiecare entitate.
 Numim atribut derivat orice atribut a cărui valoare se poate calcula din
unul sau mai multe alte atribute.
Reprezentare grafică - diagrame E-R
Întreaga structura logica a unei baze de date poate fi reprezentata grafic cu ajutorul
diagramelor E-R. O astfel de diagrama conţine elemente grafice cum ar fi:
 dreptunghiuri, care reprezintă tipuri de entitate;
 elipse, care reprezintă atribute;
 linii, care au rolul de a evidenţia legăturile între elementele diagramei.
Dreptunghiurile şi elipsele sunt etichetate cu numele 'obiectului' reprezentat. Acestea nu sunt
singurele elemente grafice utilizate într-o diagrama E-R. Pe măsură ce vom defini noi
concepte vom reveni cu precizări legate de modul de a le reprezenta.
Un atribut se reprezintă printr-o elipsă, legată de entitatea căreia îi este asociat cu o linie şi
etichetată cu numele atributului. Elipsa este trasata cu linie punctată, dacă atributul este un
atribut derivat şi respectiv cu linie dublă, daca atributul poate lua mai multe valori.
44
Dacă un atribut este compus, atunci componentele atributului se reprezintă prin elipse legate
cu cate o linie de atributul compus.
Exemple
numãr
num bloc
e locatari adres
a
numãr adres
apartam scara
matric a
ol ent etaj
adres
a
adres
a
Reprezentarea cu diagrama E-R a entităţii locatari
adres
În exemplu entitatea locatari are următoarele atribute: număr_matricol, nume şi
a
adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se
descompune în număr_bloc, scara, etaj adresşi apartament. Explicaţia sublinierii
a
atributului număr_matricol se va da în secţiunea care se ocupa de chei, tot în
această unitate de învăţare.
Desenaţi structura corespunzătoare tipului de entitate student.
Numim tip de relaţie orice asociere între tipuri de entităţi.

Numim relaţie orice asociere între entităţi, când asocierea include cate o entitate pentru toate
tipurile de entitate participante.
Fie E1, E2, ..., E n tipuri de entitate. Formal, un tip de relaţie este o submulţime a următoarei
mulţimi:
{( e1, e2, ..., e n) | unde e1E1, e2E2, ..., e nEn }
ceea ce înseamnă că ( e 1, e2, ..., e n) reprezintă formal o relaţie.
Exemple
Într-o aplicaţie care ar servi unor evidente în cadrul asociaţiilor de locatari putem
considera tipul de entitate locatari descris de atributele: nume, adresa şi
număr_matricol şi tipul de entitate scări descris de atributele număr_de_bloc şi
scara. Între tipul de entitate scări şi tipul de entitate locatari se poate stabili un
tip de relaţie numit este_locuita_de. Acest tip de relaţie va conţine relaţii de tipul
('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu
Ion".
Descrieţi relaţiile care apar între student şi catalog.
45
Numim gradul relaţiei numărul entităţilor participante în relaţie. Aşadar relaţia reprezentată
mai sus are gradul n. Entităţile implicate într-o relaţie se numesc participanţi. Dacă într-o
relaţie sunt doi participanţi, atunci relaţia se numeşte binară.
Tipurile de relaţii se reprezintă în diagramele E-R cu ajutorul romburilor care sunt etichetate
cu numele tipului de relaţie.
Exemple
nume
numă
r de scar număr
a matric adre
ol sa
bloc
scări este locatari
locuită
1 M
Reprezentarea cu diagrama E-R a relaţiei este_locuita_de

Reprezentaţi relaţia dintre student şi catalog.
Funcţia pe care o joaca o entitate într-o relaţie se numeşte rolul entităţii. în general nu este
necesar să se specifice rolul entităţilor într-o relaţie, deoarece acesta este în general implicit.
Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. în
acest caz este necesar să se precizeze rolurile entităţilor implicate. În cazul relaţiilor recursive,
în diagrama E-R corespunzătoare, cele două arce de la entitate la relaţie şi înapoi, primesc
diferite etichete, care sunt importante în înţelegerea corectă a relaţiei.
Exemple
Dacă am considera entităţile lucrători şi manageri care se refera la personalul
aceleiaşi întreprinderi, am face constatarea că sunt descrise de aceleaşi atribute
deci aparţin aceluiaşi tip de entitate şi anume angajaţi. Relaţia binara
lucrează_pentru, stabilita între lucrători şi manageri este o relaţie recursiva.
Rolurile jucate de fiecare entitate se pot stabili recurgându-se la perechi ordonate
(muncitor, manager).
Exemple
lucrator
angajaţi lucrează
manager pentru
46
Reprezentarea cu diagrama E-R a relaţiei recursive lucrează_pentru
Astfel relaţia ('Popescu Ion', 'Ionescu Gheorghe') se interpretează "Popescu Ion
lucrează pentru (este subordonatul lui) Ionescu Gheorghe".
Daţi un exemplu de relaţie recursivă legată de entitatea profesor.
Unui tip de relaţie i se pot asocia atribute descriptive în acelaşi mod în care se pot asocia
atribute unui tip de entitate.
Exemple
Tipului de relaţie este_locuita_de, care implica tipurile de entitate scări şi
locatari, i se poate asocia atributul data care să retina data la care locatarul L s-a
mutat pe scara S. După cum se observa, acest atribut descrie exclusiv tipul de
relaţie şi el nu mai are sens în afara ei.
Să ne reamintim...
 Numim relaţie orice asociere între entităţi, când asocierea include cate o
entitate pentru toate tipurile de entitate participante.
 Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile
implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi
participanţi, atunci relaţia se numeşte binară.
 Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în
roluri diferite. în acest caz este necesar să se precizeze rolurile entităţilor
implicate.
Restricţii structurale
Este posibil să se stabilească diverse restricţii la care conţinutul unei baze de date
trebuie să se conformeze. Vom trata în continuare restricţiile care se pot impune entităţilor
participante într-o relaţie. Aceste restricţii trebuie să reflecte caracteristicile relaţiilor aşa cum
se percep în 'lumea reala'. Doua tipuri importante de restricţii sunt de menţionat aici: restricţii
de cardinalitate şi restricţii de participare.
a) Restricţii de cardinalitate Numim cardinalitate (polaritate) numărul relaţiilor posibile

pentru o entitate participantă. Altfel spus, cardinalitatea exprima numărul entităţilor la care o
alta entitate poate fi asociata prin intermediul unei relaţii.
Observaţie: Am utilizat în definiţia de mai sus referiri la entităţi şi la relaţii pentru a fi mai
expliciţi. Restricţiile structurale se refera insa în mod evident la tipurile de relaţie şi la tipurile
de entitate asociate. Această observaţie rămâne valabila şi în consideraţiile ce urmează.
Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz poate fi de tipurile:
unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-multe (M:N).
Relaţiile unu-la-unu:
47
În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel mult
o entitate din celalalt tip de entitate implicat în relaţia respectiva. Implicarea fiecarei entitati
într-o relaţie data este numita "participarea entitatii".
In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu cardinalul
relaţiei; în cazul relaţiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.
Relaţiile unu-la-mai-multe:
In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de entitate, este legată
de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie.
Exemple
Exemplificăm acest tip de relaţie prin relaţia este_locuita_de dintre tipurile de
entităţi scari, respectiv locatari. în reprezentarea grafică a acestui tip de
relaţie, arcul dinspre tipul de entitate scări se etichetează cu 1 iar arcul dinspre
tipul de entitate locatari se etichetează cu M
nume
numă
r de scar număr
a matric adre
ol sa
bloc
scări este locatari
locuită
1 M
Modelul semantic din figură reprezintă relaţia unu-la-mai-multe

este_locuita_de.
Din exemplul de mai sus se observă uşor că dacă relaţia directă este de unu-la-mai-
multe, atunci relaţia inversă este de unu-la-unu.
Relaţiile mai-multe-la-mai-multe:
Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia
inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă şi relaţia directă şi relaţia
inversă sunt de tipul unu-la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-
multe şi se notează cu (N:M).
Daţi un exemplu de n la m între student şi materii.
Exemple
atribu scări este locuita locatari atribu

te
nr_blo de
R1 tenr_ma
c Sc.  Fam t
scara A .1 numel
R2 e
nr_blo Sc.B R3  Fam

c .2 nr_ma
scara Sc.C t
numel
 Fam e
nr_blo 48 .3
c
scara nr_ma
t
Reprezentarea cu reţele semantice a relaţiei 1:M este_locuita_de
Reprezentaţi cu reţea semantică relaţia dintre student şi catalog.
Să ne reamintim...
Restricţii de cardinalitate
 Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o
entitate participantă.
 Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz
poate fi de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-
multe-la-mai-multe (M:N).
 În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este
legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia
respectiva
 In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de
entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de -al
doilea tip de entitate participant la relaţie.
 Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-
multe prin faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-
mai-multe. Deci, dacă şi relaţia directă şi relaţia inversă sunt de tipul unu -
la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-multe şi
se notează cu (N:M).
b) Restricţii de participare
Numim restricţii de participare acele restricţii prin care se determină dacă existenţa
unui tip de entitate depinde de faptul că este legat sau nu de un alt tip de entitate prin
intermediul relaţiei în discuţie.
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca
existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. În caz
contrar participarea se numeşte parţială. Termenii participare totala şi participare parţială pot
fi înlocuiţi cu participare obligatorie respectiv participare opţionala. În diagrama E-R aceste
tipuri de relaţii se reprezintă prin arc cu linie dublă pentru participarea totală, respectiv cu
linie simplă pentru participarea parţială. Pentru participarea parţială, există un mod de notaţie
prin care se etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul, respectiv
maximul entităţilor participante la relaţie.
Exemple
Daca se considera filialele unei firme oarecare ca entităţi în tipul de entitate
filiala şi daca se considera tipul de entitate personal (unde entităţile reprezintă
personalul firmei respective) se poate defini tipul de relaţie are_alocat stabilit
între o filiala concreta şi personalul firmei. În acest caz, daca se considera că
fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate
filiala în relaţia are_alocat este totala. Daca insa admitem că unii membri ai
personalului (de exemplu vânzătorii) nu lucrează în birourile nici unei filiale,
atunci participarea tipului de entitate personal în relaţia are_alocat este parţiala.
49
Discutaţi participarea în relaţia student cu materii.
Să ne reamintim...
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca
existenta entităţii respective necesita existenta unei entităţi asociate în relaţia
dată. În caz contrar participarea se numeşte parţială.
c) Dependenţele de existenţă
Numim tip slab de entitate un tip de entitate, a cărui existenţă este dependentă de
existenta unui alt tip de entitate.
Numim tip tare de entitate un tip de entitate, a cărui existenţă nu depinde de existenta nici
unui alt tip de entitate.
Entităţile slabe se mai numesc existenţial dependente sau subordonate iar entităţile tari se
mai numesc părinte sau dominante.
În diagrama E-R tipurile de entitate tari se reprezintă cu un dreptunghi trasat cu linie simpla.
Pentru tipurile de entitate slabe conturul dreptunghiului este trasat cu linie dubla. De
asemenea aceasta notaţie se extinde şi la relaţii. Astfel: o relaţie care leagă doua tipuri de
entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaţia care leagă un tip de
entitate tare de un tip de entitate slab este reprezentata cu un romb trasat cu linie dubla.
Chei
Conceptual este evident că entităţile şi relaţiile individuale care participa la modelarea
unei baze de date sunt distincte între ele. Diferenţa între entităţi sau diferenţa între relaţii se
exprima cu ajutorul atributelor care le descriu.
Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de
atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în mod unic a
oricărei entităţi în cadrul tipului de entitate luat în considerare.
Este evident ca, daca o submulţime de atribute formează o supercheie, atunci orice
mulţime de atribute care include supercheia este tot o supercheie.
Numim cheie candidat orice supercheie care conţine un număr minim de atribute.
Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. Putem spune că o
cheie candidat este caracterizata de următoarele proprietatea:
- unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate în parte;
Daţi exemple de chei în entitatea profesor.
Să ne reamintim...
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala
daca existenta entităţii respective necesita existenta unei entităţi asociate în
relaţia dată. În caz contrar participarea se numeşte parţială.
 Numim supercheie asociata unui tip de entitate, orice submulţime a
mulţimii de atribute ce descriu tipul de entitate, submulţime care poate
duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de
50
entitate luat în considerare.
 Numim cheie candidat orice supercheie care conţine un număr minim
de atribute. Pentru o cheie candidat nici o submulţime proprie nu mai
este supercheie.
 Pentru un tip de entitate este posibil să se poată determina una sau mai
multe chei candidat.
 Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de
identificare a entităţilor în cadrul tipului de entitate respectiv.
 Numim cheie compusă orice cheie candidat care conţine cel puţin două
atribute.
 Numim discriminatorul unui tip de entitate slab, un set de atribute care
permite realizarea unei distincţii între entităţile care depind de o anume
entitate tare. Aşadar, cheia primara a unui tip de entitate slab este
formata din cheia primara a tipului de entitate tare de care este
dependenta existenţial, la care se adaugă mulţimea atributelor care
compun discriminatorul tipului de entitate slab.
 Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic
relaţiile individuale.
 Cheia primara a tipului de relaţie este formata din reuniunea
mulţimilor de atribute care formează cheile prim are ale tipurilor de
entitate participante.
- ireductibilitatea, deoarece nici o submulţime proprie de atribute ale cheii nu are

proprietatea de unicitate.
Observaţie: Faptul că valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi
determinat decât cu ajutorul informaţiilor semantice referitoare la valorile atributelor ce
formează cheia. Trebuie să se cunoască semnificaţiile din lumea reala a atributelor ce
formează cheia pentru a se stabili daca acestea vor avea valori unice. Doar faptul ca, pentru o
mulţime oarecare de entităţi concrete, valorile diferă între ele nu este de ajuns.
Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei
candidat. Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de identificare a
entităţilor în cadrul tipului de entitate respectiv. Cheia primară este în general cea mai scurtă
dintre cheile candidat. In diagrama E-R atributele care intră în componenţa cheii primare, se
evidenţiază prin sublinierea numelui atributului.
Numim cheie compusă orice cheie candidat care conţine cel puţin două atribute.
Probleme se ivesc atunci când trebuie să identificam în mod unic entităţile unui tip de entitate
slab. Să observam că un tip de entitate tare are întotdeauna o cheie primara, deci are
întotdeauna cel puţin o cheie candidat. Un tip de entitate slab nu are cheie primara.
Numim discriminatorul unui tip de entitate slab, un set de atribute care permite
realizarea unei distincţii între entităţile care depind de o anume entitate tare. Aşadar, cheia
primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare
de care este dependenta existenţial, la care se adaugă mulţimea atributelor care compun
discriminatorul tipului de entitate slab.
51
M2.U2.2. Rezumat
Numim relaţie orice asociere între entităţi, când asocierea include cate o entitate
pentru toate tipurile de entitate participante.
Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile
implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi
participanţi, atunci relaţia se numeşte binară.
Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri
diferite. în acest caz este necesar să se precizeze rolurile entităţilor impli cate.
Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate
participantă.
Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz poate fi
de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-
multe (M:N).
În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel
mult o entitate din celalalt tip de entitate implicat în relaţia respectiva
In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de
entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip
de entitate participant la relaţie.
Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-multe prin
faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă
şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe, atunci relaţia
directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M).
Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de
atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în
mod unic a oricărei entităţi în cadrul tipului de entitate luat în considerare.
Numim cheie candidat orice supercheie care conţine un număr minim de
atribute. Pentru o cheie candidat nici o submulţime proprie nu mai este
supercheie.
Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei
candidat.
Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de identificare
a entităţilor în cadrul tipului de entitate respectiv.
Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic relaţiile

individuale. Cheia primara a tipului de relaţie este formata din reuniunea mulţimilor de
atribute care formează cheile primare ale tipurilor de entitate participante.
M2.U.2.2 Test de autoevaluare a cunoştinţelor

2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi cheia primară.
2.2.2 Daţi exemple de relaţii unu la unu, unu la mai mulţi şi mulţi la mulţi.
2.2.3 Stabiliţi domeniul fiecărui atribut din tabela profesor.
52
Modulul 3. Limbaje de cereri.
Cuprins
Introducere
Obiectivele modului
U3.1 Algebra relaţională.

U3.2 SQL.
M3. Introducere
Una din funcţiunile importante ale SGBD+urilor este regăsirea datelor. Pentru
aceasta trebuie să facem cereri la baza de date. Modelul matematic al acestor
cereri la baza de date relaţională este algebra relaţională, iar limbajul standardizat
de cereri este SQL.

 Facă operaţii în algebra relaţională
 Exprime cereri în algebra relaţională
 Exprime cereri în SQL
 exprime actualizări ale bazei de date
53
Unitatea de învăţare 3.1 Algebra relaţională.
In cadrul bazelor de date relaţionale, datele sunt organizate sub forma unor
tablouri bidimensionale (tabele) de date, numite relaţii. Asocierile dintre relaţii se
reprezintă explicit prin atribute de legătură. Aceste atribute figurează într -una din
relaţiile implicate in asociere (de regulă, în cazul legaturilor de tip "unu la mulţi")
sau sunt plasate într-o relaţie distinctă, construită special pentru exprimarea
legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). O bază de date
relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă atât
datele cât şi legăturile dintre date.
Operatorii modelului relaţional definesc operaţiile care se pot efectua asupra
relaţiilor, în scopul realizarii funcţiilor de prelucrare asupra bazei de date,
respectiv consultarea, inserarea, modificarea şi ştergerea datelor.
Restricţiile de integritate ale modelului relaţional permit definirea st ărilor
coerente ale bazei de date.
În continuare, vor fi prezentate pe larg aceste componente.

 Facă operaţii în algebra relaţională
 Exprime cereri în algebra relaţională
Structura relaţionala a datelor

Prezentarea structurii relaţionale a datelor impune reluarea noţi unilor de: domeniu,
relaţie, atribut şi schemă a unei relaţii.
Domeniul reprezintă un ansamblu de valori, caracterizat printr -un nume. Un domeniu
se poate defini explicit, prin enumerarea tuturor valorilor apartinând acestuia sau implicit, prin
precizarea proprietăţilor pe care le au valorile din cadrul domeniului respectiv.
54
Exemple
Sa considerăm, de exemplu domeniile D1, D2, D3, definite astfel:
D1: ("F","M")
D2 : (x / x aparţine N, x aparţine [0,100])
D3 :(s/s=şir de caractere)
În cazul lui D1 s-a recurs la o definire explicită, în timp ce pentru D2 şi D3 s-a
utilizat definirea implicită.
Pentru un ansamblu de domenii D1, D2, ..., Dn produsul catezian al acestora

reprezinta ansamblul tuplurilor <v1, v2, ..., vn>, unde: v1 este o valoare apartinând
domeniului D1, v2 este o valoare din D2 s.a.m.d.
Exemple
De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,
<"Vasile","M",20>, <"Vasile", "F",100> aparţin produsului cartezian: D3 x D1 x
D2
Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1, D2, D3,

definite anterior.
Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane,
D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde numele unor persoane.
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o
semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi persoane.
Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul
poate avea o semnificaţie, dacă presupunem că există o singură persoană cu
acest nume.
Se desprinde de aici necesitatea definirii unei submulţimi de tupluri, din cadrul
produsului cartezian al domeniilor, submulţime care să cuprindă numai tuplurile cu
semnificaţie.
Relaţia reprezintă un subansamblu al produsului cartezian al mai multor domenii,
subansamblu caracterizat printr-un nume şi care conţine tupluri cu semnificatie. Considerând
de exemplu că nu se cunosc decât două persoane definim realţia R prin tuplurile care descriu
aceste persoane şi anume:
R : (<"Maria", "F", 30>, <"Vasile", "M", 35>)
Intr-o relaţie, tuplurile trebuie să fie distincte (nu se admit duplicări ale
tuplurilor) .
O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în care
liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).
Exemple
Relaţie reprezentată sub forma unei tabele de date
55
Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor,
întrucat este uşor de înţeles şi de utilizat.
În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte concepte,
extrem de bine cunoscute în domeniul prelucrării automate a datelor precum cel de fişier.
Relaţia poate avea semnificaţia unui fişier,tuplul poate fi considerat drept o înregistrare, iar
valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înre gistrare.
În cadrul modelului relaţional nu intereseaza decat relaţiile finite, chiar dacă
în construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr -o
relaţie reprezinta cardinalul relaţiei, în timp ce numărul valorilor dintr -un tuplu defineste
gradul relaţiei.
In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate apare de mai
multe ori în produsul cartezian pe baza căruia este definită relaţia.
Exemple
Să considerăm, de exemplu că pentru o persoana dispunem de urmatoarele date:
nume,sex, vârsta şi numele soţului/soţiei.
O posibilitate de organizare a acestor date o reprezintă relaţia din figură
R: D3 D1 D2
“Maria” “F” 30
“Vasile” “M” 35
Relatia PERS reprezintă un subansamblu al produsului cartezian:

D3 x D1 x D2 x D3.
Semnificaţia valorilor din cadrul unui tuplu se stabileşte
Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza
domeniului de care aparţin valorile, ci şi in funcţie de poziţia ocupată în cadrul tuplului.
Dependenţa fată de ordine a datelor inseamnă o reducere a flexibiltăţii organizarii datelor.
Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor din cadrul tabele i de date
nu trebuie să prezinte nici o importanţă. Pentru a diferenţia coloanele care conţin valori ale
aceluiaşi domeniu şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază
fiecarei coloane un nume distinct, ceea ce duce la aparitţa n oţiunii de atribut.
Atributul reprezintă coloana unei tabele de date, caracterizată printr -un nume. Numele
coloanei (atributului) exprimă de obicei semnificaţia valorilor din cadrul coloanei respective.
Schema unei relaţii
Prin schema unei relaţii se întelege numele relaţiei, urmat de lista atributelor, pentru
fiecare atribut precizându-se domeniul asociat. Astfel, pentru o relaţie R, cu atributele A1, A2,
..., An şi domeniile: D1, D2,..., Dm, cu m <= n, schema relaţiei R poate fi reprezentată într -
una din formele
R(A1:D1, …, A n:Dm) A1:D1 … An:Dm
a) b)
Operatorii modelului relaţional.

Modelul relaţional oferă două colecţii de operatori pe relaţii şi anume:
- algebra relaţionala;
- calculul relaţional.
56
La rândul sau, calculul relaţional este de două tipuri:
- calcul relaţional orientat pe tuplu;
calcul relaţional orientat pe domeniu.
Ne limităm, în cele ce urmează, la elemente de algebră relaţională.
Algebra relaţională şi extensiile sale
E. F. Codd a introdus algebra relaţionala (AR) cu operaţii pe relaţii, fiecare operaţie
având drept operanzi una sau mai multe relaţii şi
producând ca rezultat o altă relaţie.
Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. În acest sens,
putem vorbi de:
- operaţii de bază, precum: reuniunea, diferenţa, produsul cartezian etc.
- operaţii derivate, ca: intersecţia, diviziunea etc.
Codd a introdus aşa numita AR standard, constituită din 6 operaţii de bază: reuniunea,
diferenţa, produsul cartezian, proiecţia, selecţia şi joncţiunea precum şi din două operaţii
derivate: intersecţia şi diviziunea.
Ulterior, la operaţiile AR standard au fost adăugate şi alte operaţii, aşa
numitele operaţii "adiţionale" sau extensii ale AR standard, precum:comple -
mentara unei relaţii, splitarea (spargerea) unei relaţii, închiderea tranzitivă etc.
În continuare vor fi prezentate principalele operaţii ale AR, precum şi modul lor de
utilizare.
1. Reuniunea. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 a mbele cu
o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică
cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată.
Notaţia uzuală pentru reuniune este: R1 U R2
Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.
Exemple
Reuniunea relatiilor ORASE şi MUNICIPII
Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele cu o

aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu schema identică cu a
operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în
relaţia R2.
Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1 -R2
57
Exemple
Diferenţa relaţiilor ORAŞE şi MUNICIPII
3. Produs cartezian. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,

operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine prin
concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile
tuplurilor din R1 cu cele din R2.
Notaţia uzuală pentru desemnarea operaţiei este: R1xR2
Exemple
TRANSPORT
ORAŞ:D1 JUDEŢ: D1 TRANSPORT:D3 TARIF:D4

Braşov Braşov tramvai 30
Târgovişte Dâmboviţa tramvai 30
Braşov Braşov autobuz 50
Târgovişte Dâmboviţa autobuz 50
Braşov Braşov troleibuz 50
Târgovişte Dâmboviţa troleibuz 50
ANSP:D3 TARIF:D3
ORAŞ:D1 JUDEŢ:D1 X tramvai 30
Braşov Braşov autobuz 50
Târgovişte Dâmboviţa troleibuz 50
ORAŞE:
TARIFE
Produsul cartezian al relaţiilor ORAŞE şi TARIFE
58
4. Proiecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie care constă
din construirea unei noi relaţii P, în care se regăsesc unele atribute din R, înseamnă efectuarea
unor tăieturi verticale asupra lui R, care pot avea ca efect apariţia unor tupluri duplicate ce se
cer a fi eliminate.
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei.
Notaţia uzuală pentru operaţia de proiecţie este:
ΠAi,Aj,…,Am (R)
Exemple
Proiectia relaţiei ORAŞE pe atributul "Judeţ"
5. Selecţia. Roprezintă o operaţie din AR definită asupra unei relaţii R,

operaţie care constă din construierea unei relaţii S, a cărei schemă este identică
cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o
condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai adesea, nu toate tuplurile din
R satisfac, această condiţie, selecţia înseamnă efectuarea unor tăieturi orizontal e asupra
relaţiei R, adică eliminarea de tupluri. Condiţia precizată în cadrul operaţiei de selecţie este în
general de forma:
unde: "operator de comparaţie" poate fi: <, <=, >=, > sau <>.
Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este următoarea:
Σ(conditie)R
59
Exemple
Selecţie efectuata asupra relaţiei ORAŞE
6. Joncţiunea (Joinul). Reprezintă o operaţie din AR defin ită pe două relaţii: R1 şi

R2, operaţie care constă din construirea unei noi relaţii R3, prin concatenarea unor
tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 şi R2 care satisfac o
anumita condiţie, specificată explicit în cadrul operaţiei. Extensia relaţiei R3 va contine deci
combinaţiile acelor tupluri care satisfac condiţia de concatenare.
Notaţiiile uzuale pentru desemnarea operaţiei de joncţiune sunt:
Reprezentarea grafica a operaţiei de joncţiune

In general, condiţia de concatenare menţionata in cadrul operaţiei de joncţiune este de
forma:
In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare, joinul

poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei mai frecvente
utilizări este equijoinul.
Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:
Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi

selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei selecţii operate asupra unui produs
cartezian, adică:
60
JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie)
Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea ce face
ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este posibil. Cu toate că
apare drept o operaţie derivată, joinul este prezentat de obicei drept o operaţie de bază din
AR, dată fiind importanţa sa in cadrul sistemelor relaţionale, în special la construirea relaţiilor
virtuale.
In cadrul fig.3.9. este ilustrată operaţia de equijoin.
Au fost definite numeroase variante ale operaţiei de joncţiune, variante care dife ră nu
numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de definire a schemei şi
respectiv, extensiei relaţiei rezultate prin joncţiune.
Exemple
Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI
Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate atributele celor
doi operanzi (fig.3.10.) În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două
valori egale. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală, ca
operaţie definită pe două relaţii: R1 şi R2, prin care este construită o noua relaţie R3, a cărei
schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi
nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea
tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi
nume.
Notaţia uzuală pentru joncţiunea naturală este:

Reprezentarea grafică a acestei operaţii este prezentată în fig. 3.10.
Reprezentarea grafică a operaţiei de joncţiune
61
Exemple
7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2 ambele cu aceeaşi

schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu a
operanzilor şi cu extensia formată din tuplurile comune lui R1 şi R2.
Notaţile uzuale folosite pentru desemnarea operaţiei de intersecţie sunt:
Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.12., iar

un exemplu de intersecţie a doua relaţii figurează în fig. 3.13.
Reprezentarea grafica a operatiei de intersectie
62
Exemple
Intersecţia relatiilor ORAŞE şi MUNICIPII
Intersecţia reprezintă o operaţie derivată, care poate fi exprimată prin intermediul unor
operaţii de bază. De exemplu, operaţia de intersecţie se poate exprima prin intermediul
operaţiei de diferenţă, cu ajutorul următoarelor echivalenţe:
R1 R2=R1-(R1-R2)
R1 R2=R2-(R2-R1)
M3.U3.1. Rezumat
Reuniunea reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 ambele
cu o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu
schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate
impreună o singură dată.
Diferenţa reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele
cu o aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu
schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale
relaţiei R1 care nu se regăsesc şi în relaţia R2.
Produs cartezian reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,
operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine
prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate
combinaţiile tuplurilor din R1 cu cele din R2.
Proiecţia reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie
care constă din construirea unei noi relaţii P, în care se regăsesc unele atribute
din R, înseamnă efectuarea unor tăieturi verticale asupra lui R, care pot avea ca
efect apariţia unor tupluri duplicate ce se cer a fi eliminate.
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit
operaţiei.
Selecţia reprezintă o operaţie din AR definită asupra unei relaţii R,
operaţie care constă din construierea unei relaţii S, a cărei schemă este identică
63
cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care
satisfac o condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai
adesea, nu toate tuplurile din R satisfac, această condiţie, selecţia înseamnă
efectuarea unor tăieturi orizontale asupra relaţiei R, adică eliminarea de tupluri.
Joncţiunea (Joinul) reprezintă o operaţie din AR definită pe două relaţii: R1 şi
R2, operaţie care constă din construirea unei noi relaţii R3, prin
concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele
tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în
cadrul operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri
care satisfac condiţia de concatenare.
Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate
atributele celor doi operanzi În toate tuplurile relaţiei rezultat vor exista de aceea
cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus
joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este
construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea
atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată)
şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1
cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi
nume.
3.1.1 Cosideraţi instanţe ale tabelei student, profesor,materii şi catalog.
a) Faceţi selecţie din student după grupa …
b) Faceţi proiecţie la student şi la profesor după nume. La acestea două din
urmă faceţi reuniunea.
c) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi
materii.
d) Faceţi selecţia tabelei de mai nainte după nota < 5.
3.1.2 Să se exprime în algebra relaţională cererile:
a) Studenţii grupei 7271
b) Studenţii care sunt şi profesori
c) Studenţii corigenţi
d) Studenţii integralişti
64
Unitatea de învăţare 3.2 SQL
SQL (Structured Query Language), a fost conceput iniţial de firma IBM,
pentru produsul dBASE, ca un limbaj standard de descriere a datelor şi de
acces la informţtiile din bazele de date. Limbaj de interogare a bazelor de
date relaţionale, SQL a fost utilizat pe scară largă şi pană în prezent au fost
dezvoltate şapte versiuni ale standardului SQL, trei dintre ele aparţinînd
Institutului National American de Standarde (ANSI), celelalte fiind
concepute de firme de prestigiu ca IBM, Microsoft şi Borland sau de cãtre
consorţii ca SAG (The SQL Access Group) şi X/Open.
Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut
sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua
denumire: ANSI-SQL'92.

 Exprime cereri în SQL
 exprime actualizări ale bazei de date
Cereri de interogare simple

Instructiunile de regăsire reprezintă una din categoriile cele mei importante ale
limbajului de interogare SQL. Indiferent dacă sunt simple sau complexe, punctul de plecare al
interogărilor îl constituie fraza SELECT, prin care se r egăsesc şi se afişeaza informaţiile
dorite de utilizator.
Pentru definirea interogărilor de selecţie simple se utilizează următoarea sintaxă a
instrucţiunii SELECT:
SELECT [domeniu] lista_selecţie
FROM nume_tabela1,nume_tabela2…
[WHERE criteriu_de_selecţie}
ORDER BY câmpuri_criteriu [ASC/DESC]];
Domeniu:
- Determină stabilirea modalităţii de manipulare a înregistrărilor din baza de date asupra
căreia se efectuează selecţia şi poate fi:
ALL - permite includerea tuturor inregistrărilor ce indeplinesc condiţiile impuse. Este
folosit foarte rar deoarece este implicit.
DISTINCT - are ce efect eliminarea înregistrărilor care conţin duplicate în câmpurile
selectate; astfel se va afişa doar o apariţie a datei multiple ( ceea ce este în concordanţă cu
algebra relaţională).
DISTINCTROW - are în vedere înregistrările duplicate în ansamblul lor, nu numai pe cele
care au câmpuri duplicate.
65
Lista_selecţie
Cuprinde toate câmpurile care vor aparea în tabela cu rezulta tele interogării.
Atenţie! }n list[ vor ap[rea numai aatribute ale tabelelor din clauya FROM.
Clauzele SQL SELECT, FROM şi WRERE pot fi puse în corespondenţă cu operatorii din
algebra relaţională, după cum urmează:
Clauza SELECT menţionează o listă de atribute şi corespunde proiecţiei din algebra
relaţională;
Clauza FROM menţionează o listă de relaţii (tabele) şi corespunde produsului cartezian din
algebra relaţională;
Clauza WRERE descrie un predicat de selecţie şi corespunde selecţiei din algebra relaţi onală.
Înţelesul diferit al termenului “select” utilizat în SQL şi în algebra relaţională este un fapt
istoric nefericit. În SQL, ”select” desemnează proiecţia, iar în algebra relaţională acelaşi
termen desemnează selecţia după un predicat de selecţie.
Lista de atribuire care apare în clauza SELECT din SQL poate fi înlocuită cu simbolul *
dacă se doreşte selectarea tuturor atributelor care apar în relaţiile din clauza FROM.
Clauza ORDER BY
Utilizată atunci când se doreşte ca rezultatele interogării să fie ordonate în mod
crescător (ASC) sau descrescător (DESC). Sortarea este opţională şi se poate realiza dupa
unul sau mai multe câmpuri_criteriu (definite drept chei de sortare). Componenta BY a
clauzei nu poate să lipsească atunci când se doreşte sotrarea rezultatelor interogării SQL.
Rezultatul unei interogări SQL este întotdeauna o relaţie (o tabelă).
Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de închiriere casete
video. Avem următoarele tabele:
Clienti (Cod_client , Nume, Prenume, Strada, Nr, Bloc, Scara, Apartament, Oras, Seria_BI,
Nr_BI, Data_ nasterii, Telefon)
Casete (Cod_caseta,Pret, Disponibila)
Filme ( Cod_film, Titlu, An_aparitie, Tara. Gen)
Casete-Filme (Cod_casetafilm, Cod_caseta, Cod_film)
Actori (Cod_actor,Nume, Sex)
Filme_Actori (Cod_filmactor, Cod_film, Cod_actor)
Imprumuturi (Cod_imprumut, Cod_client, Data_imprumut, Stare)
Plati (Cod_plata, Cod_imprumut, Data , Suma)
Casete imprumutate (Cod_imprcaseta, Cod_imprumut, Cod_caseta, Restituita)
Exemple
Să se afişeze toate datele despre toţi clienţii.
SELECT *
FROM Clienţi
.Să se afişeze toate datele despre toţi actorii.
Exemple
Să se afişeze oraşele de reşedinţă ale tuturor clienţilor
SELECT Oraş
FROM Clienţi
66
Să se afişeze toate genurile filmelor. Ce puteţi spune despre numărul genurilor
faţă de numărul genurilor.
Ca rezultat al acestei interogări se va obţine o tabelă cu o singură coloană, care conţine
numele oraşelor de reşedinţă ale clienţilor. Se va observa că se repetă numele oraşelor,
deoarece se vor afişa oraşele pentru fiecare client în parte din tabela clienţi.
Exemple
Să se afişeze oraşele de reşedinţă ale clienţilor, dar să apară fiecare ora ş o singură
dată în tabela-rezultat.
SELECT DISTINCT Oraş
FROM Clienti
Să se afişeze toate genurile distincte ale filmelor.
Exemple
Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a
titlurilor filmelor
SELECT *
FROM Filme
ORDER BY Titlu,ASC
Afişaţi, ca mai sus, dar în ordine descendentă.
Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a titlurilor filmelor
SELECT *
FROM Filme
ORDER BY Titlu,ASC
A se observa că dacă ar fi lipsit menţiunea ASC, ordinea tuplelor ar fi fost
aceeaşi deoarece ordinea ascendentă este implicită.
În scrierea interogărilor de selecţie simple SQL se pot folosi şi funcţii totalizatoare,
cunoscute şi sub numele de funcţii standard sau funcţii agregat, care apar în clauza SELECT
şi se aplică atributelor din tabelele implicate în interogare. Funcţii standard sunt:
valoarea medie – AVG
valoarea minima – MIN
valoarea maxima –MAX
total (sumare) – SUM
numaratoare – COUNT
Nu este permisă utilizarea acestor funcţii în clauza WHERE deoarece ele acţionează la nivel
de atribut şi nu la nivel tuplu.
Exemple
Care este suma minimă plătită?
SELECT MIN (suma)
67
FROM plati
.Care este suma maximă plătită?
Exemple
Care este preţul mediu al casetelor?
SELECT AVG(Pret)
FROM Casete
Care este suma medie încasată.
Exemple
Care este suma totală plătită pentru împrumutul cu cod ’30’?
SELECT SUM (suma)
FROM plati
WHWRE Cod_imprumut=’30’
Care este valoarea totală a casetelor.
Exemple
Cate tulpe conţine tabela de casete?
SELECT COUNT (*)
FROM Casete
Câte tupe conţine tabela clienti.
Exemple
Cate genuri de filme sunt înregistrate pentru filmele din baza de date?
SELECT COUNT (DISTINCT Gen)
FROM Filme
Cereri de interogare complexe
Limbajul de interogare SQL permite, pe lângă definirea de interogări de selecţie simple,

crearea unor interogări cu o structura complexă, cum ar fi cele în care regăsim funcţiile
agregate, asocierile (JOIN) sau combinările (UNION).
Funcţiile de grup(agregat)
68
Funcţiile de grup agregat permit construirea unor interogări SQL complexe, prin care
utilizatorul poate să efectueze diverse calcule pentru grupuri de înregistrări care au câmpuri cu
aceeasi valoare. În cazul utilizării lor se foloseşte următoarea formă a frazei SELECT:
SELECT [domeniu] [funcţie agregată (nume_câmp) AS alias [,lista_selecţie]

F ROM nume_tabela1, nume_tabela2…
GROUP BY câmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY câmpuri_criteriu [ASC/DESC]];
Dupa cum se observă, singurele elemente obligatorii într-o interogare SQL sunt clauzele
SELECT cu lista de atribute ce vor fi extrase şi clauza FROM cu relaţiile din care fac parte
atributele. Aşadar o interogare SQL trebuie să conţină cel puţin următoarele informaţii:
SELECT <lista de atribute>

FROM <lista de relatii>
restul clauzelor sunt opţionale.
Lista selecţie
Se va referi la una sau mai multe funcţii agregate care au ca argumente nume de câmpuri ale
bazei de date. Există restricţia ca aceste câmpuri sa fie întotdeauna de tip num eric.
AS alias
Asociază un pseudonim (nume) rezultatului utilizării funcţiei agregat
Clauza GROUP BY şi HAVING

În unele cazuri, utilizatorul doreşte anumite situatii sintetice, cum ar fi obţinerea de totaluri şi
subtotaluri. Pentru aceste operaţii, limbajul SQL permite utilizarea clauzelor GROUP BY şi
HAVING.
Aceste clauze organizează tuplele în grupuri asupra cărora se pot realiza anumite
operaţii, în special prin aplicarea funcţiilor agregat.
Clauza GROUP BY grupeaza tuplele din relaţie după atributele cu aceeaşi valoare
care sunt specificate în clauză, şi generează un tuplu pentru fiecare grup de tuple cu aceeaşi
valoare pe atribut
Atributele care apar în clauza SELECT pot fi de două feluri:
-atribute care alcătuiesc baza pentru grupare (cele care apar în clauza GROUP BY);
-atribute care nu participa la gruparea rezultatelor.
Exemple
În ce orase exista clienti ai centrului de închiriere casete video?
SELECT Oras
FROM Clienti
GROUP BY Oras
În urma executarii vor aparea orasele din tabela clientilor listate o singură dată.
Din câte ţări avem filme.
Exemple
Câţi clienţi au sediul în fiecare oras?
SELECT Oras,COUNT(*)
69
FROM Client
GROUP BY Oras
Câte filme sunt din fieare ţară.
Exemple
În care case locuiesc cel puţin 3 clienţi?
SELECT Oras,COUNT(*)
FROM Clienti
GROUP BY Oras
HAVING COUNT(*)>=3
Clauza GROUP BY se poate folosi şi cu ORDER BY şi WHERE.
Din ce ţări avem cel puţin 2 filme.
Exemple
Să se afişeze în ordine alfabetică oraşele în care există clienţi ai centrului.
SELECT Oras
FROM Clienti
GROUP BY Oras
ORDER BY Oras
Să se afişeze în ordine alfabetică ţările din care avem filme.
Exemple
Care sunt clienţii care au împrumutat casete înainte de data de 6/5/2004?
SELECT Cod_client
FROM Imprumuturi
WHERE Data_imprumut<#6/5/2002#
GROUP BY Cod_client
Care sunt împrumuturile făcute după data 01/01/2009 .
Clauza FROM are forma generală:

FROM <<nume relatie>/<nume view>[alias]…>
şi specifică relaţiile (pot fi şi nume view) din care vor fi regăsite datele. În cazul în care se
operează cu mai multe tabele, este utilă atribuirea unor prescurtări, (numite alias) ale numelor
de tabele ce vor fi utilizate în interogare.
Exemple
Să se afişeze codurile casetelor, numele clienţilor, codul împrumutului şi data
împrumutului pentru clienţii care au cel puţin un împrumut.
70
SELECTC Cod_caseta, [Nume] &””& [Prenume] AS Numele,
Cod_imprumut, B.Data_imprumut
FROM Clienti A, Imprumuturi B, [casete imprumutate] C
WHERE A.Cod_client=B.Cod_client AND B.Cod_imprumut=C. Cod_imprumut
A se observa că nu s-a mai utilizat notaţia cu alias pentru atributele Nume şi
Prenume din tabela Clienti deoarece nu este pericol de confuzie. În schimb s-a
utilizat notaţia pentru a deosebi atributul Cod_client din tabela Clienti de
atributul cu acelaşi nume din tabela Imprumuturi.
Să se afişeze actorii care joacă cel puţin într-un film.
Pentru a restrânge tuplele ce apar în tabela-rezultat, se specifică o condiţie de cautare prin

utilizarea unui predicat de selecţie în clauza WHERE.
Clauza WHERE are forma generala:
WHERE <predicat> / <expresie>;

Numai tuplele care satisfac predicatul de selecţie vor fi incluse în tabela-rezultat. Predicatul
de cautare poate fi specificat printr-o condiţie logica în care se utilizeaza urmatoarele
elemente:
Operatori:
-aritmetici:+ - / * ** ^
-relaţionali: < > <= >= <> != =
-logici:NOT AND OR
-operatori SQL:IN,EXISTS,ALL,ANY
Sub-interogări(exprimate prin interogări SQL)cu observatia ca acestea vor
fi primele evaluate şi tabela-rezultat trebuie sa corespunda operatorilor ce i se aplica în
continuare.
Operatori aritmetici
Ace;ti operatori sunt binecunoscuţi şi menţionăm aici doar faptul ca şi ^ si ** reprezint[

ridicarea la putere.
Ca operanzi, se pot utiliza atribute,constante,funcţii sau expresii algebrice. Expresiile
algebrice pot aparea în clauzele SELECT sau WHERE.
Operatori relaţionali
< mai mic
> mai mare
! negarea operatorilor <,>,=. Se obţin operatorii: != (diferit),!< (nu mai mic),!> (nu mai
mare).
<= mai mic sau egal
=> mai mare sau egal
<> diferit
Facem observaţia că valorile comparate trebuie să aparţină unor tipuri de date compatbile
(care se pot compara între ele.).
Exemple
Sa se afişeze codurile şi titlurile filmelor de gen acţiune.
SELECT Cod_film<Titlu
FROM Filme
WHERE Gen=”actiune”
71
Să se afişeze filmele din Romania.
Operatori logici
Dacă o clauza WHERE conţine mai multe condiţii formate prin utilizarea aceluiaşi tip de
operator logic, evaluarea se va face de la stânga la dreapta. Tipul de operator logic este dat de
precedenţa operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de OR şi AND
care practic sunt de priorităţi egale. Pentru a schimba ordinea de evaluare a unei expresii se
utilizează parantezele rotunde ().
Exemple
Sa se afişeze codul şi titlul filmelor din SUA care au anul apariţiei mai mare
decât 2000.
SELECT Cod_film,Titlu
FROM Filme
WHERE Tara=”SUA”AND An_aparitie>2000
Să se afişeze plăţile mai mari de 100 lei făcut în anul 2009.
Exemple
Sa se afişeze codul şi titlul filmelor din SUA sau care au anul apariţiei mai mare
decât 2000.
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=”SUA”OR An_aparitie>2000
A se observa că ultima interogare este echivalentă cu interogarea :
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=”SUA”OR NOT An_aparitie<=2000
Operatorul IN permite simplificarea predicatului de căutare. Predicatul IN testează dacă

valoarea unui atribut specficat în lista de atribute din clauza WHERE se potriveşte uneia din
valorile listei specificate în predicatul IN (testeaza apartenenţa la o mulţime).
Exemple
Să se afişeze toate datele despre clienţii care au sediul în Râşnov sau în
Braşov.
SELECT *
FROM Clienti
WHERE Oras IN (“Rasnov”,”Brasov”)
72
Să se afişeze, în două moduri, toate datele despre clienţii care au sediul în
Râşnov sau în Braşov sau în B ucuresti.
Asocierile (interogările JOIN)

Una dintre operaţiile cele mai frecvente realizate cu mai multe tabele este joncţiunea
sau produsul cartezian. Joncţiunea aminteşte de operaţiile din algebra relaţională şi chiar e ste
posibil de realizat (urmând anumite structuri ale interogării SQL) oricare dintre tipurile de
joncţiune prezentate teoretic în cadrul algebrei relaţionale. Se pot de asemenea realiza operaţii
ca reuniunea, intersectia şi diferenţa. Sintaxa interogării SQL diferă de la un SGBD la altul
dar sub o formă directă sau printr-o construcţie sintactică specifică se pot realiza oricare dintre
operaţiile amintite.
Putem distinge mai multe categorii de joncţiuni:CROSS (încrucişată) - mai
puţin utilizată, cu rol în ilustrarea elementelor specifce proprietăţilor combinatorii ale tuturor
asocierilor; ECHIVALENTĂ (echijoncţiunea)-cea mai folosită, presupune folosirea clauzei
WHERE (pentru selecţia înregistrărilor) asociată cu o egalitate dorită; NEECHIVALENTA
(non echijoncţiune) - care, spre deosebire de precedenta, face apel în clauza WHERE la
oricare operator de comparare în afară de semnul (“=”). Acest din urmă tip de joncţiune este
în general foarte rar de utilizat.
Sintaxa generală pentru joncţiunile echivalente şi neechivalente este următoarea:

FROM nume_tabela1,nume_tabela 2…
WHERE criteriul_de_asociere]
[ORDER BY câmpuri_criteriu[ASC?DESC];
Deoarece în instrucţiunile SQL care descriu joncţiunea se utilizeaza câmpuri ce fac

parte din tabele diferite, este necesara întotdeauna spacificarea tabelei la care apartin. Forma
generala de descriere a unui câmp va fi urmatoarea:nume_tabela.nume_câmp. Se pot folosi şi
alias-uri.
Exemple
Sa se afişeze numele clientilor şi codurile imprumuturilor pentru
imprumuturile neterminate.
SELECT[Nume]&””&[Prenume] AS Numele,b.Cod_imprumut
FROM Clienti 1,Imprumuturi b
WHERE 1.Cod_client=b.Cod_client AND Stare=Yes
Sa se afişeze filmele şi casetele pe care se găsesc.
Exemple
Care filme au acelasi gen cu filmul “Titanic”? A se observa că această interogare
necesită realizarea produsului cartezian al tabelei cu ea însăşi.
SELECT p1.Titlu,p2.Titlu,p1.Gen.p2.Gen
FROM Filme p1,Filme p2
WHERE p1.Gen=p2.Gen AND p2.Titlu=”Titanic”
73
O altă abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe
(OUTER JOIN). Primele determină o asociere a înregistrărilor din tabele, astfel încat sa
rezulte un numar total de înregistrări din fiec are tabela. Joncţiunile externe, la randul lor, sunt
de doua tipuri: de stanga (LEFT OUTER JOIN) şi de dreapta (RIGHT OUTER JOIN) fiind
destul de puţin utilizate.
În acest mod de abordare al joncţiunulor sintaxa va avea forma:

FROM num_tabela1
JOIN nume_tabela2
ON criteriu_de_asociere
[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3
ON criteriu_de_asociere]…
[WHERE criteriu_de_selecţie]
[ORDER BY câmpuri_criteriu {ASC/DESC]]:
De remarcat faptul ca SQL acceptă scrierea interogărilor externe fără specificarea

explicită a lui OUTER.
JOIN – specifică tabela care va fi asociată (nume_tabela2,nume_tabela3…) tabelei preciată în

clauza FROM ON criteriu_de_asociere – arată relaţia dintre câmpurile pe care se bazează
joncţiunea. Unul se află în tabela asociată, iar celălalt există într-o altă tabelă din lista cu
numele tabelelor. Expresia criteriul_de asociere conţine un operator de comparaţie de tip
egalitate (=) şi va returna valorile logice TRUE sau FALSE
Exemple
Sa se afişeze codul casetelor, preţul şi filmele de pe casete, pentru casetele care
sunt disponibile.
SELECT Casete.Cod_caseta,Filme.Titlu,Casete.Pret
FROM Filme INNER JOIN (Casete INNER JOIN [Casete-Filme] ON
Casete.Cod_caseta=[Casete-Filme].Cod_caseta)ON Filme.Cod_film=[Casete-
Fiml].Cod_film
WHERE (((Casete.disponibile)=Yes));
Sa se afişeze filmele şi casetele pe care se găsesc. Procedaţi ca mai sus.
Combinările (interogările UNION)

Clauza UNION permite realizarea reuniunii de tabele. În cazul când dorim să reunim
două sau mai multe tabele, este obligatoriu ca acestea să fie daschise de scheme de relatie
identică (acelaşi număr de atribute şi corespunzator – de la stanga la dreapta – atributele din
tabele au aceleasi nume şi aceeaşi descriere). Aceste condiţii sunt impuse tabelelor implicate
în operaţiile intersecţie şi minus (diferenţă). Operaţiile reuniune, intersecţie şi diferenţă de
tabele acţionează analog cu aceleaşi operaţii aplicate în mulţimi.
Forma generală a reuniunii de tabele este:
74
SELECT A1,…,Am
FROM
[WHERE…]
UNION
SELECT A1,…,Am
FROM…
[WHERE…]
Exemple
Să se afişeze numele clienţilor care sunt fie din Râşnov fie din Braşov şi adresa
lor.
SELECT [Nume]&””&[Prenume]AS Nume,Clienti.Strada,Clienti.Nr,
Clienti.Bloc,Clienti.Scara,Clienti.Apartament,Clienti.Oras,Clienti.Telefon
FROM Clienti
WHERE Oras=”Rasnov”
UNION (SELECT [Nume] &””&[Prenume] AS Numele, Clienti.
Strada,Clienti.Apartament, Clienti.Oras,Clienti.Telefon
FROM Clienti
WHERE Oras=”Brasov”);
Cereri de interogare imbricate (subinterogări)

Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare
este acela că oferă posibilitatea construirii interogărilor complexe, formate din mai multe
subinterogări simple.
Aceste interogări complexe sunt construite prin includerea în clauza WHERE a încă
unei clauze SELECT. Forma generală a unei astfel de construcţii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
Se observă că această construcţie a fost deja utilizată în exemplul de mai sus car e
ilustrează o clauză UNiON.
În construcţia de mai sus clauza SELECT interioară generează valorile pentru condiţia de
căutare a clauzei SELECT exterioare care o conţine. Clauza SELECT exterioară generează o
relaţie pa baza valorilor generate de către clauza interioară. Modul de construire a interogării
exterioare depinde de numărul valorilor returnate de către interogarea interioară. În acest sens,
putem distinge:
 subinterogări care returnează o singură valoare;
 subinterogări care returnează mai multe valori.
Din punctul de vedere al ordinii de evaluare al interogărilor putem distinge:
 Subinterogări simple
Interogarea interioara este evaluata prima, independent de interogarea exterioara.
Rezultatul evaluarii interogării interioare este utilizat de catre nterogarea
exterioara.
 Subinterogări corelate
Valorile returnate de catre interogarea interioară depind de valorile returnate de catre
interogarea exterioară. Interogarea interioară este evaluată reletat pentru fiecare tuplu cercetat
de interogarea exterioara.
75
Subinterogări simple care returneaza o singura valoare
Aceste interogări au urmatoarea sintaxă:
SELECT <lista atribute>
FROM <lista relatii>
WHERE <atribut> 0 (<subinterogare>)
unde 0 este un operator relaţional: =,< > >= <= !=
Exemple
Sa se afişeze numarul împrumuturilor neîncheiate pentru clienta Ciurar Cristina.
SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]
FROM Imprumuturi
WHERE (((Imprumuturi.Cod_client)=SELECT Clienti.Cod_client
FROM Clienti
WHERE [Nume] & “ “ &
[Prenume]=’Ciurar Cristina’)));
Sa se afişeze casetelew care au filme din USA.
Procesul de evaluare a acestei interogări se desfasoară astfel:

Se evalueaza în primul rînd interogarea interioară. Condiţia de evaluare a interogării
interioare este [Nume] & “ ” & [Prenume]=’Ciurar Cristina’.
Valoarea obţinută pentru atributul Cod_client este stocata într-o tebelă temporară.
Rezultatul evaluării interogării interioare devine condiţie de căutare pentru interogarea
exterioară, care ar putea fi exprimată în această fază ca:
SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]
FROM Imprumuturi
WHERE (Imprumuturi.Cod_client)=6
În urma executării interogării exterioare este creată o relaţie finală, ce va contine
tuplele ale căror Cod_client este acelaşi cu valoarea stocată în tabela temporară.
Interogarea interioară poate conţine în clauza WHERE şi condiţii complexe, formate
prin utilizarea operatorilor logici (NOT,AND, OR) şi a funcţiilor agregat (AVG,MAX,…).
Exemple
Sa se afişeze codul casetelor, pretul şi titlurile filmelor, pentru casetele care au un
pret maxim.
SELECT Casete.Cod_caseta,Casete.Pret,Filme.Titlu
FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON
Casete.Cod_caseta=[Casete-Filme].Cod_caseta) ON
Filme.Cod_film=[Casete-ilme].Cod_film
WHERE Pret=(SELECT MAX(Pret) FROM Casete);
Să se afişeze filmele din casetele, cu preţ minim, împrumutate şi nerestiruite.
Suinterogări simple care returnează mai multe valori.

Principiul de construire a acestui tip de interogare imbricate utilizează în clauza
WHERE condiţii, care evaluate, generează o mulţime de valori. În această categorie intră
operatorii (NOT) IN, (NOT) ANY,(NOT) AND,(NOT) EXISTS.
76
Exemple
Care sunt clienţii care mai au de restituit casete.
SELECT [Nume]&””&[Prenume]AS Numele
FROM Clienti
WHERE Cod_client IN
(SELECT Cod_client
FROM Imprumuturi INNER JOIN [casete imprumutate]
ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut
WHERE restituit=NO);
Care sunt actorii care joacă în casetele împrumutate.
Exemple
Care clienţi nu mai au nimic de restituit.
SELECT [Nume]&””&[Prenume]AS Numele
FROM Clienti
WHERE Cod_client NOT IN
(SELECT Cod_client
FROM Imprumuturi INNER JOIN [casete imprumutate]
ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut
WHERE restituit=NO);
A se observa ce cele două interogări diferă doar prin operatorul logic NOT. De
asemenea se poate remarca faptul că prima interogare aminteşte de apartenenţa din teoria
mulţimilor iar a doua interogare corespunde operaţiei minus (diferenţa). Dacă versiunea SQL
nu are un cuvânt rezervat pentru operaţia diferenţa inter tabele, se poate construi aceasta
operaţie cu ajutorul predicatului NOT IN ca în exemplul de mai sus.
Subinterogări corelate
În exemplele de până acum, interogarea interioară era evaluată prima, după care
valoarea, sau valorile, rezultate erau utilizate de către clauza WHERE din interogarea
exterioară.
Exista şi o altă forma de subinterogare şi anume Subinterogarea corelată, caz în care
interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară.
De fiecare dată când este transmisă o valoare, este evaluată interogarea interioară.
Dacă ambele interogări acceseaza acelaşi table, trebuie asigurate alias-uri pentru fiecare
referinţa la tabelul respectiv. Ambele interogări accesează tuple diferite din acelaşi table în
acelaşi moment.
Exemple
Sa se afişeze codurile imprumuturilor, data imprumutului, data unei plaţi şi suma
plătită, pentru sumele maxime care s-au plătit, ordonate după data împrumutului.
SELECT Imprumuturi.Cod_imprumut, Imprumuturi.Data_ imprumut,

plati.data,plati.suma
FROM Imprumuturi INNER JOIN plati ON Imprumuturi.Cod
77
_imprumut=plati.cod_imprumut
WHERE suma=
(SELECT MAX(suma)
FROM plati
WHERE Imprumuturi.Cod_ Imprumut=plati.cod_ Imprumut) ORDER BY
Imprumuturi..Data_ Imprumut;
Restricţionare subinterogărilor
Operatorii ANY şi ALL
Operatorul ANY poate fi utilizat în cobinaţie cu oricare dintre operatorii relaţionali (=
< > <= >= !=) pentru a se varifica dacă valorile unui atribut este egală, mai mică, mai mare,
etc. decât oricare dintre valorile menţionate o dată cu operatorul. Urmatoarele predicate sunt
echivalente:
=ANY si IN
!=ANY si NOT IN
Operatorul ALL returnează tuplele pentru care valorile atributului din clauza WHERE
sunt mai mici, mai mari, mai mici sau egale, ect. decât toate valorile generate de interogarea
interioară. Să facem observaţia că acest operator nu poate fi utilizat cu operatorul relaţional =,
ceea ce ar corespunde cazului banal în care toate valorile din listă sunt identice.
Pentru a stabili mai exact modul în care se selectează valorile cu operatorii ANY şi ALL dăm
mai jos o serie de cazuri concrete.
Să presupunem ca interogarea este de forma:
SELECT…
FROM …
WHERE x <ALL (1,2,3,4)
Să observăm că dacă înlocuim operatorul ALL cu expresia verbală toate putem citi
“Valorile lui x trebuie să fie mai mici decât toate valorile d in paranteza ce urmeaza după
ALL”.
Atunci vom lua în considerare urmatoarele situaţii:
Expresia din clauza WHERE Valori ale lui x care corespund

X<ALL 0,-1,-2,…
X<=ALL 1,0,-1,-2,…
X>ALL 5,6,7,…
X>=ALL 4,5,6,…
Daca vom studia o interogare de forma:
SELECT…
FROM …
WHERE x <ANY (1,2,3,4)
Să observăm că dacă înlocuim operatorul ANY cu expresia verbală oricare putem citi
“Valorile lui x trebuie să fie mai mici decât oricare dintre valorile din paranteza ce urmeaza
dupa ALL”.
78
Vom lua în considerare următorul table:
Expresia din clauza WHERE Valori ale lui x care corespund

X<ANY 3,2,1,0,-1,-2,…
X<=ANY 4,3,2,1,0,-1,-2,…
X>ANY 2,3,4,5,6,7,…
X>=ANY 1,2,3,4,5,6,…
Exemple
Exemple:
Să se afişeze titlul filmelor, anul apariţiei şi genul, pentru filmele din SUA,
care au anul apariţiei maxim.
SELECT Filme.Titlu,Filme.An_aparitie,Filme.Gen
FROM Filme
WHERE An_aparitie<ALL
(SELECT An_aparitie
FROM Filme
WHERE Tara=’SUA’);
Exemple
Să se afişeza codul casetelor, preţul, titlurile filmelor pentru
Casetele disponibile, din care le excludem pe cele de preţ maxim.
SELECT Casete.Cod_caseta,Casete.Pret,Casete.disponibil,Filme.titlu
FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON
Casete.Cod_caseta=[ Casete-Filme].Cod_caseta) ON Filme.Cod_film= [Casete-
Filme].Cod_film
WHERE disponibil=Yes AND Pret<ANY
(SELECT Pret
FROM Casete
WHERE disponibil=YES);
Operatorul EXISTS
Operatorul EXISTS verifică dacă pentru fiecare tuplu al relaţiei există tuple care
satisfac condiţia interogării interioare. În cazul în care există asemenea tuple, EXISTS ia
valoarea de adevar TRUE. Astfel, operatorul EXISTS permite specificarea mai multor
attribute în interogarea interioară. Acest lucru este posibil deoarece nu se verifică valoarea
unui atribut, ca în cazurile anterioare, ci se generează o valoare de adevar ( TRUE sau
FALSE), după cum există sau nu există o anumită valoare într-o relaţie diferită de cea
utilizată în interogarea exterioară.)
Ca şi operatorii ANY şi ALL, operatorul EXISTS apare în clauza WHERE.
Exemple
Să se afişeze titlui filmelor, anul aparitiei şi genul pentru filmele care au un an de
apariţie mai mare sau egal cu anul maxim de apariţie al fi lmelor de gen fabula.
79
SELECT Titlu,An_aparitie,Gen
FROM Filme f
WHERE NOT EXISTS
(SELECT *
FROM Filme
WHERE Gen=’fabula’ AND An_aparitie>f.An_aparitie);
Interogarea SELECT interioară defineşte o tabelă care conţine tuple pentru care se
verifică condiţia din clauza WHERE internă.
Actualizări ale bazei de date.

SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru actualizarea
bazelor de date. Comenzile pentru actualizări nu sunt atât de complexe ca declaraţia SELECT.
Declaraţiile SQL aferente actualizării unei baze de date se referă la modificările unei tabele
(adăugare sau ştergere de linii, modificarea datelor dintr -o tabelă):
Adăugarea se face cu declaraţia INSERT care are două forme prima accepta
adăugarea unei singure linii, iar a doua adăugarea mai multor linii.
I. Adăugarea unei singure linii
INSERT INTO nume_tabela [(lista_atribute)]
VALUES (lista_valorilor_datelor)
Nume_tabela reprezintă numele unei tabele din baza de date sau o vedere actualizată a
acesteia, lista_atribute reprezintă o listă de una sau mai multe nume ale coloanelor tabelei
separate prin virgulă. Dacă această listă nu este specificată SQL consideră toate atributele
tabelei în ordinea în care au fost create în tabela originală. În cazul în care sp ecificăm această
listă atributele pe care dorim să le omitem trebuie să le declarăm ca NULL. Numărul de
elemente din cele două liste trebuie să coincidă, să aibă aceaşi ordine de declarare şi să fie
compatibile ca tip.
Exemple
Exemplu:
Inseraţi o nouă înregistrare în tabela Conducere completând datele pentru toate
atributele:
INSERT INTO Conducere
VALUES (‘cd16’, ‘Ionescu’, ‘Alex’, ‘George Enescu 37, ap.4, Bucuresti’, ‘021 -
456-12456’,’director economic’,’m’, date ’01.07.1945’)
Inseraţi o nouă înregistrare în tabela casete.
Exemple

80
II. Adăugarea mai multor linii prin copierea lor dintr -o tabelă sau mai multe tabele într-o altă
tabelă
SELECT …
Nume_tabela şi lista de atribute sunt definite la fel ca la cazul anterior, iar clauza SELECT
poate fi orice declaraţie validă.
Exemple
Inseraţi o nouă înregistrare în tabela Conducere completând datele doar pentru
atributele obligatorii cod, Nume, Prenume, Functie
INSERT INTO Conducere
VALUES (‘cd44’, ‘Aduducai’, ‘Maria’, NULL, NULL,’asisent manager’,NULL,
NULL)
Exemplu:
Exemple
Presupunând că în tabela ContConducere conţine numele celor din
conducere şi numărul serviciilor pe care le au în subordine populaţi tabela
ContConducere folosind detalii din tabelele Conducere şi PorpServicii o nouă
înregistrare în tabela Conducere completând datele pentru toate atributele:
INSERT INTO ContConducere
(SELECT s.id, nume, prenume, COUNT(*)
FORM Conducere s, PropServicii p
WHERE s.id=p.id
GROUP BY s.id, nume, prenume)
UNION
(SELECT id, nume, prenume, 0
FORM Conducere
WHERE id NOT IN
(SELECT DISTINCT id
FROM PropServicii))
Modificarea se face cu declaraţia UPDATE care permite modificarea datelor unor

înregistrări existente într-o tabelă dată. Sintaxa acestei comenzi este:
UPDATE nume_tabela
SET nume_atribut1=valoare1[,nume_atribut2=valoare2 ….]
[WHERE conditie_cautare]
Clauza SET specifică numele unui atribut sau a mai multor atribute care urmează a fi
modificate, WHERE este o clauză opţională, prin omiterea ei se consideră că toate că toate
înregistrările for fi modificate pentru atributele alese la clauza SET, iar dacă ea este
specificată atunci doar acele înregistrări care îndeplinesc condiţiile de căutare. Tipul datelor
valoare1,…. trebuie să fie compatibile cu cele ale atributelor corespunzătoare.
81
Exemple
Modificarea tuturor înregistrărilor pentru mărirea salariior tuturor celor din
conducere cu 3%.
UPDATE CONDUCERE
SET salariu = salariu*1.03
Modificarea preţului la casetele cu preţul maxim prin reducere cu 10%.
2. Modificarea doar a unor înregistrări specificate

UPDATE CONDUCERE
SET salariu = salariu*1.05
WHERE functie=’manager’
Modificarea înregistrărilor pentru mai multe atribute
UPDATE CONDUCERE
SET functie=’manager’, salariu = 18.000.000
WHERE id=’cd73’
Ştergerea se face cu declaraţia DELETE , sintaxa acestei comenzi este :
DELETE FROM nume_tabela
WHERE conditie_cautare
Dacă opţiunea WHERE lipseşte atunci se şterg toate înregistrările darn nu şi tabelul,
pentru a şterge un tabel folosim declaraţia DROP TABLE. Se poate şterge un tabel numai
dacă nu mai are înregistrări.
Exemple
1. Ştergerea tuturor înregistrărilor din tabela vedere (view)
DELETE FROM viewing;
2. Ştergerea anumitor înregistrări din tabela vedere (view)
DELETE FROM viewing;
WHERE id = ‘cd72’
Ştergerea tuturor înregistrărilor din tabela casete.

Ştergerea înregistrărilor din tabela casete cu preţ minim.
82
M3.U3.2. Rezumat
Pentru definirea interogǎrilor de selecţie simple se utilizeazǎ urmǎtoarea sintaxǎ
a instrucţiunii SELECT:
SELECT[domeniu]lista_selecţie
FROMnume_tabela1,nume_tabela2…
[WHERE criteriu_de_selecţie}
ORDER BY câmpuri_criteriu [ASC/DESC]];
Funcţiile de grup agregat permit construirea unor interogǎri SQL
complexe, prin care utilizatorul poate sǎ efectueze diverse calcule pentru grupuri
de înregistrǎri care au câmpuri cu aceeasi valoare. În cazul utilizǎrii lor se
foloseşte urmǎtoarea formǎ a frazei SELECT:
SELECT [domeniu] [funcţie agregatǎ (nume_câmp) AS alias [,lista_selecţie]

FROM nume_tabela1, n ume_tabela2…
GROUP BY câmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY câmpuri_criteriu [ASC/DESC]];
Sintaxa generalǎ pentru joncţiuni este urmǎtoarea:
FROM nume_tabela1,nume_tabela 2…
WHERE criteriul_de_asociere]
[ORDER BY câmpuri_criteriu[ASC?DESC];
O altǎ abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe
(OUTER JOIN). Primele determinǎ o asociere a înregistrǎrilor din tabele, astfel
încat sa rezulte un numar total de înregistrǎri din fiecare tabela. Joncţiunile
externe, la randul lor, sunt de doua tipuri: de stanga (LEFT OUTER JOIN) şi de
dreapta (RIGHT OUTER JOIN) fiind destul de puţin utilizate.
În acest mod de abordare al joncţiunulor sintaxa va avea forma:
FROM num_tabela1
JOIN nume_tabela2
ON criteriu_de_asociere
[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3
ON criteriu_de_asociere]…
[WHERE criteriu_de_selecţie]
[ORDER BY câmpuri_criteriu {ASC/DESC]]:
Unul din motivele pentru care SQL este considerat un limbaj puternic de
interogare este acela cǎ oferǎ posibilitatea construirii interogǎrilor complexe,
formate din mai multe subinterogǎri simple.
Aceste interogǎri complexe sunt construite prin includerea în clauza
WHERE a încǎ unei clauze SELECT. Forma generalǎ a unei astfel de
construcţii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru
actualizarea bazelor de date. Comenzile pentru actualizǎri nu sunt atât de
complexe ca declaraţia SELECT.
Adǎugarea se face cu declaraţia INSERT care are douǎ forme prima accepta
adǎugarea unei singure linii, iar a doua adǎugarea mai multor linii.
83
I. Adǎugarea unei singure linii
VALUES (lista_valorilor_datelor)
Nume_tabela reprezintǎ numele unei tabele din baza de date sau o vedere
actualizatǎ a acesteia, lista_atribute reprezintǎ o listǎ de una sau mai multe nume
ale coloanelor tabelei separate prin virgulǎ. Dacǎ aceastǎ listǎ nu este specificatǎ
SQL considerǎ toate atributele tabelei în ordinea în care au fost create în tabela
originalǎ. În cazul în care specificǎm aceastǎ listǎ atributele pe care dorim sǎ le
omitem trebuie sǎ le declarǎm ca NULL. Numǎrul de elemente din cele douǎ
liste trebuie sǎ coincidǎ, sǎ aibǎ aceaşi ordine de declarare şi sǎ fie compatibile
ca tip.
Modificarea se face cu declaraţia UPDATE care permite modificarea datelor
unor înregistrǎri existente într-o tabelǎ datǎ. Sintaxa acestei comenzi este:
UPDATE nume_tabela
SET nume_atribut1=valoare1[,nume_atribut2=valoare2 ….]
[WHERE conditie_cautare]
Ştergerea se face cu declaraţia DELETE , sintaxa acestei comenzi este:
DELETE FROM nume_tabela
WHERE conditie_cautare

Se dau următoarele relaţii cu schemele lor:
-Scări (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)
- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume
Să se exprime în SQL cererile:
3.2.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1
3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34
3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp
3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi
pe scara 1 a aceluiaşi bloc
84
Modulul 4. Normalizarea
Cuprins
Introducere
Obiectivele modului
U4.1 De ce este nevoie de normalizare şi cu ce instrumente facem normalizarea.

U4.2 Forme normale
M4 Introducere
La proiectarea unei baze de date, un obiectiv foarte important, care trebuie
urmarit cand se gandeste un model de date, este realizarea unei reprezentari
corecte a datelor, a relatiilor dintre date şi a restrictiilor impuse asupra datelor.
Pentru realizarea acestui obiectiv se utilizeaza tehnica normalizarii, care are ca
scop principal identificarea setului celui mai adecvat de relatii care sa modeleze
realitatea dorita.

 descopere dependenţele funcţionale între atribute, şi să le pună în
evidenţă proprietăţile
 descopere anomaliile din descrierea unei baze de date
 aducă o bază de date la formele normale 1, 2 şi 3. descopere
anomaliile din descrierea unei baze de date
aducă o bază de date la formele normale 1, 2 şi 3.
85
Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem
normalizarea.
Procesul de normalizare este o metodă formală care identifica relaţiile
bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF)
şi pe dependenţele funcţionale care exista intre atributele acestor relatii.
Normalizarea sprijina proiectantul bazei de date, dandu-i posibilitatea sa aplice o
serie de teste asupra relatiilor individuale, asa incat schema relaţionala poate fi
normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la
actualizare.

 realizeze importanţa normalizării
 descopere dependenţele funcţionale între atribute, şi să le pună în
evidenţă proprietăţile
Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.
Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul informatic
Asociatie de locatari.
Partea cea mai importantă la proiectarea bazei de date este gruparea atributelor în relaţii cu
scopul de a minimiza redundanţa informaţiilor şi (odata cu aceasta) spaţiul ocupat de relatii
(tabele sau fişiere) pe suportul magnetic.
Exemple
Fie relaţia Furnizori_Cheltuieli exemplificată mai jos. In exemple se vor
simplifica numele atributelor.
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare
F100 Romgaz R1234567 C15 Incalzire 30.06.99

2,150,000
F100 Romgaz R1234567 C16 Apa calda 30.06.99
500,000
F110 Renel R7654321 C10 Iluminat 30.06.99
3,000,000
F110 Renel R7654321 C11 Lift 30.06.99
200,000
Relaţia Furnizori_Cheltuieli instanţiată
Sa presupunem ca aplicaţia pe care o vom studia ca exemplu contine datele organizate intr-o
singura relatie descrisa de urmatoarele schema de relatie:
86
Furnizori_Cheltuieli = (Cod_furn, Den_furn, Cod_fiscal, Cod_chelt, Den_chelt, Data,
Valoare)
Dintre atribute, cele evidentiate constituie cheia primara pentru relatia respectiva.
Relatia Furnizori_Cheltuieli are cheia compusa din atributele Cod_furn, Cod_Chelt şi Data.
Datele sunt prost organizate in relatia prezentata.
Informaţia despre furnizori din relatia Furnizori_Cheltuieli este redundantă. Detaliile
despre furnizor se repetă la fiecare introducere a unei cheltuieli noi.
Nu este insa singura problema pe care o organizare nepotrivita a datelor o poate
genera.
O altă consecinta a redundanţei informatiilor din baza de date, o reprezinta problemele de
actualizare a informaţiei stocate. Enumeram mai jos o parte dintre acestea.
Anomalii de adaugare
Anomaliile de inserare se pot clasifica în două tipuri:
 Pentru a adauga detaliile despre o cheltuială către un furnizor, în relaţia
Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre furnizorul în cauză,
chiar dacă ele există deja în baza de date. Această anomalie poate duce la apariţia de
informatii diferite despre acelasi furnizor în înregistrări diferite. Informatia despre furnizor
isi pierde in acest mod consistenta, nu ne mai putem baza pe corectitudinea datelor despre
furnizor in baza de date.
 Pentru a adăuga detalii despre un furnizor nou în relaţia Furnizori_Cheltuieli, trebuie
neapărat adăugată şi o cheltuială pentru asociaţia de locatari către acel furnizor. În cazul în
care încă nu a sosit factura de la furnizor, nu se poate înregistra nici o cheltuială şi deci
trebuie introduse valori nule. Este nerecomandabil sa se lucreze cu valori nule deoarece se
genereaza probleme la regasirea şi actualizarea informatiilor.
Anomalii de ştergere
În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou (tot in cadrul
relatiei Furnizori_Cheltuieli ), se va şterge şi furnizorul. Deci toate detaliile introduse despre
acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nouă
folosire al acelui furnizor.
Anomalii de modificare
Dacă în relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui atribut al unui
furnizor, va trebui să schimbăm datele pentru fiecare apariţie a acelui furnizor. De exemplu
dacă dorim să schimbăm codul fiscal al furnizorului cu codul F100, va trebui să schimbăm
acest atribut în toate tuplele in care apare furnizorul F100. Din nou , este posibil ca datele sa
nu fie modificate corect. Este posibil sa ramana tuple cu datele nemodificate sau este posibil
sa se modifice datele respective cu valori diferite in locuri diferite. (Nu dorim sa insistam
asupra cauzelor care pot duce la aceste situatii.).
Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a două relatii
distincte: Cheltuieli şi Furnizori. În acest caz dacă trebuie modificat un atribut al unui
furnizor, modificarea se va xecuta intr-un singur loc în relatia Furnizori. Asemanator, daca e
necesara o stergere in relatia Cheltuieli, aceasta nu va mai afecta furnizorii din relatia
Furnizori. De asemenea orice cheltuiala adaugata şi orice furnizor nou adaugat nu se vor mai
conditiona reciproc in nici un fel.
Descompuneri cu pierderi de informatii
87
În urma analizarii anomaliilor de actualizare prezentate mai sus am tras concluzia ca o
descompunere a relatiilor care ne fac probleme este binevenita şi duce la rezolvarea
problemelor. Este bine insa sa tratam descompunerile de relatii cu prudenta deoarece o
descompunere neglijenta ne poate crea probleme la fel de mari cu acelea de care tocmai ne-
am ocupat. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se
realizeaza descompunerea.
În general se poate urmari ca in fiecare relatie sa se reprezinte informatii despre o
singura multime-entitate. Criteriul este mai mult de ordin intuitiv şi el nu ne este de mare
ajutor in cazul reprezentarii multimilor-relatie. In acest caz, intr-o relatie se intalnesc date
despre mai multe multimi-entitate. Este necesar sa se stabileasca o modalitate riguroasa de a
decide care sunt informatiile care trebuie sa alcatuiasca o astfel de relatie.
Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema oarecare
de relatie. Un set de scheme de relatie reprezinta o descompunere a lui R şi se noteaza {R 1,
R2, …, R n} daca
n
Ri = R
i 1
Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel
putin o schema de relatie din descompunere. Daca ne raportam la relatiile care se bazeaza pe
schemele de mai sus, fie r relatia construita pe schema R sie fie relatiile r 1, r2, …, rn construite
pe schemele de relatie ce formeaza descompunerea. In termenii algebrei relaţionale se poate
considera egalitatea;
ri =  Ri
(r) pentru toti 1in.
Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de relatie R i.
Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu
pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru a clarifica
lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta
functionala.
Dependenţe funcţionale
Unul din cele mai importante concepte asociate cu normalizarea este conceptul de
dependenţă funcţională. Dependenţa funcţională descrie un anumit tip de legatura care se
stabileste intre atributele aceleiasi relatii.
Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se verifica A R
şi BR. Spunem ca B depinde functional de A şi scriem AB daca pentru orice relatie legala
r, construita pe schema de relatie R, se verifica urmatoarea situatie: pentru orice pereche de
tuple t1 şi t2 din r, pentru care t 1[A]=t2[A], are loc intotdeauna şi t 1[B]=t2[B].
Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute A)
aceeasi valoare cu alt tuplu t2, obligatoriu cele doua tuple vor avea aceeasi valoare şi pe
submultimea de atribute B. Valorile din B sunt in mod unic determinate de valorile din A.
Numim determinant al unei dependente funcţionale, atributul, sau mulţimea
atributelor din partea stângă a săgeţii.
Exemple O parte dintre dependenţele funcţionale pentru relaţia
Furnizori_Cheltuieli sunt:
Cod_furn  Den_furn
88
Cod_furn  Cod_fiscal
Cod_chelt Den_chelt
Cod_chelt, Cod_furn, Data  Valoare
Numele furnizorului este determinat in mod unic de codul furnizorului. La coduri
egale, numele sunt identice.
Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod
cheltuiala, cod furnizor şi data. Intr-o anume data, un anumit furnizor, pentru un
anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine
determinata de bani. Nici una dintre valori nu poate determina valoarea şi nici in
combinatii de cate doua. Daca nu se iau cele trei informatii impreuna se pot crea
confuzii in legatura cu valoarea. (Acelasi cod de cheltuiala poate corespunde la
valori diferite in date diferite. Acelasi furnizor poate avea chiar şi coduri de
cheltuiala diferite darmite valoarea care le reprezinta, s.a.m.d. …)
Notiunea de dependenta functionala generalizeaza notiune de cheie. Se poate da

urmatoarea definitie a supercheii:
Spunem ca submultimea deatribute K din schema de relatie R este o supercheie daca
KR, adica pentru orice pereche de tuple t 1 şi t2 din r, pentru care t 1[K]=t2[K], are loc
intotdeauna şi t1[R]=t2[R].
Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor pe care nu
le putem exprima cu ajutorul cheilor. Dependenţa funcţională este o proprietate legata de
semantica atributelor în relaţii. Dependentele functionale pot fi stabilite de cine cunoaste exact
legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaţia şi
semnificatia informatiilor din relatii.
Nu se pot da retete pentru stabilirea dependentelor functionale, dar se pot da metode
de a determina toate dependentele functionale dintr-o relatie daca se cunosc cateva
dependente de la care poate porni algoritmul.
O metoda de a determina multimea tuturor dependentelor functionale dintr-o relatie se
bazeaza pe asa-numitele Axiome ale lui Armstrong.
Regulile (Axiomele) lui Armstrong:
1) regula reflexivitatii – daca X este un subset de atribute din R şi YX, atunci are loc
XY;
2) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca XY atunc
WXWY;
3) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi
YZ atunci are loc şi XZ.
Cele trei reguli sunt suficiente şi formeaza un set complet pentru a se putea determina
toate dependentele functionale daca se porneste de la un set de baza initial. Totusi se mai
utilizeaza in mod obisnuit şi reguli suplimentare (care pot fi deduse din primele trei) deoarece
usureaza calculele.
Astfel:
4) regula reuniunii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi XZ
89
atunci şi XYZ;
5) regula descompunerii – daca daca X, Y şi Z sunt subseturi de atribute din R şi daca
XYZ atunci au loc şi XY şi XZ;
6) regula pseudotranzitivitatii - daca X, Y, W şi Z sunt subseturi de atribute din R şi daca
XY şi WYZ atunci şi WXZ
Exemple
EXEMPLU:
Fie schema de relatie R={A, B, C, G, H, I} şi fie setul de dependente initial notat
cu F şi format din dependentele: AB, AC, CGH, CGI, BH.
Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:
 AH, utilizand regula tranzitivitatii aplicata la dependentele AB şi BH;
 CGHI, utilizand regula reuniunii pentru dependentele CGH şi CGI;
si asa mai departe… …
Daca se noteaza cu F setul initial de dependente functionale, cu F+ se va nota

inchiderea lui F (deci toate dependentele functionale care se pot defini pentru relatia in cauza.)
Putem reveni in acest moment pentru a trata descompunerile de relatii. Am subliniat
mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita pierderea de
informatii.
Descompuneri fara pierderi la joncţiune
Fie o descompunere oarecare {R1, R 2, …, R n} a relatiei R, asa cum am definit-o
formal la inceputul acestui capitol. Pentru o descompunere oarecare se verifica intotdeuna
relatia:
n
r X ri
i 1
unde prin X s-a notat produsul cartezian, operatie din algebra relaţionala. Altfel spus, orice
tuplu din relatia r duce, prin descompunere, la cate un tuplu t i in fiecare relatie ri. Cand se
realizeaza produsul cartezian cu toate relatiile ri, se obtin in general mai multe tuple decat au
fost in relatia initiala r, deoarece produsul cartezian are ca rezultat toate combinatiile posibile
intre elementele participante.
Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii sau
conditii, care sa asigure corectitudinea informatiilor din respectiva baza de date.
În general spunem ca o relatie este legala daca satisface toate regulile sau restrictiile
care sunt impuse la proiectarea bazei de date.
Fie C un set de restrictii asupra bazei de date. O descompunere {R 1, R 2, …, Rn} a unei
scheme de relatie R este o descompunere fara pierderi la jonctiune pentru R, daca pentru toate
relatiile r definite pe schema R (care sunt legale sub restrictiile C) se verifica:
n
r= X  Ri (r)
i 1
Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o
descompunere fara pierderi la jonctiune sau nu.
90
Definitie. Fie R o schema de relatie şi fie descompunerea lui R reprezentata de {R1, R2}.
Aceasta descompunere este fara pierderi la jonctiune daca cel putin una dintre urmatoarele
dependente functionale se gasesc in F +:
R1R2R1
R1R2R2
Descompuneri cu pastrarea dependentelor
Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza de date.
Se pot impune restrictii care permit sistemului sa verifice la orice actualizare a informatiilor
ca nu se va crea o relatie ilegala.
Fie F setul initial de dependente functionale, definit pe o schema de relatie R. şi fie
{R1, R 2, …, Rn} o descompunere a lui R. Notam cu F i restrictia la R i a multimii de dependente
functionale F. (Se cere ca dependentele functionale din F i sa includa doar atribute care se
regasesc in relatia R i).
n
Vom obtine un set de multimi de dependente functionale F1, F2, …, Fn. Fie F'= Fi,
i 1
reuniunea seturilor de dependente funtionale. In general F'F. Dar s-ar putea ca sa se verifice
relatia F'+=F+. Daca se intampla asa atunci spunem ca descompunerea este o descompunere cu
pastrarea dependentei.
M4.U4.1. Rezumat
Din cauza proiectării incorecte pot apărea anomalii la in serare de noi
ănregistrări, la şterger şi la modificări.
In urma analizarii anomaliilor de actualizare prezentate mai sus am tras
concluzia ca o descompunere a relatiilor care ne fac probleme este binevenita
şi duce la rezolvarea problemelor. Este posibil sa pierdem informatii daca nu
suntem atenti la modul in care se realizeaza descompunerea.
Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema
oarecare de relatie. Un set de scheme de relatie reprezinta o descompunere a
lui R şi se noteaza {R 1, R2, …, R n} daca
n
Ri = R
i 1
Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste

in cel putin o schema de relatie din descompunere. Daca ne raportam la
relatiile care se bazeaza pe schemele de mai sus, fie r relatia construita pe
schema R sie fie relatiile r1, r2, …, rn construite pe schemele de relatie ce
formeaza descompunerea. In termenii algebrei relaţionale se poate considera
egalitatea;
ri =  Ri
(r) pentru toti 1in.
Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de

relatie R i.
Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu
pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru
91
a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii
de dependenta functionala.
Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se
verifica AR şi BR. Spunem ca B depinde functional de A şi scriem AB
daca pentru orice relatie legala r, construita pe schema de relatie R, se verifica
urmatoarea situatie:
pentru orice pereche de tuple t1 şi t2 din r, pentru care t 1[A]=t2[A], are loc
intotdeauna şi t1[B]=t2[B].
Regulile (Axiomele) lui Armstrong:
7) regula reflexivitatii – daca X este un subset de atribute din R şi YX,
atunci are loc XY;
8) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca
XY atunc WXWY;
9) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi
daca XY şi YZ atunci are loc şi XZ.

4.1.1 Descoperiţi dependenţele funcţionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))
92
Unitatea de învăţare 4.2 Forme normale
M4.U4.2 Introducere
Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniţial s-au propus
trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai târziu, prin enuntarea
unei definitii mai tari a formei normale trei, s-a obtinut forma Boyce-Codd, după
numele celor care au introdus aceasta forma normala: R. Boyce şi E. F. Codd
(1974). Toate aceste forme normale se bazeaza pe dependentele functionale
stabilite intre atributele unei relatii.
Formele normale cele mai folosite sunt: forma normală 3 şi forma normală
Boyce-Codd. Există şi forme normale mai tari - forma normală 4 (4NF) şi forma
normală 5 (5NF) - dar acestea se folosesc foarte rar.

 descopere anomaliile din descrierea unei baze de date
 aducă o bază de date la formele normale 1, 2 şi 3.
Normalizarea este un proces de organizare a datelor in relatiile unei baze de d ate.

Acest proces presupune respectarea unor reguli prin care baza de date se poate normaliza până
la un anumit grad, adica se aduce la o anumita forma normala.
Normalizarea se execută trecând prin toate formele normale, până la forma normală cerută. La
proiectarea unei baze de date e recomandabil sa se ajunga cel puţin pana la forma normală
trei. Aceasta asigura evitarea anomaliilor descrise la inceputul acestui capitol.
Forma Normală Unu (1NF)
Numim Formă Nenormalizată (UNF) orice tabelă care conţine una sau mai multe grupuri
repetitive pe atribute.
Forma Normală Unu (1NF): Spunem ca o relaţie se gaseste in Forma normala unu daca
orice atribut este atomic, adica nu exista nici atribute compuse nici repetitive.
Pentru a transforma tabela din exemplul următor în forma normală unu, identificăm şi
ştergem grupurile repetitive din tabelă. Eliminarea acestor grupuri repetitive se poate realiza
în două moduri:
Exemple 4.2.1
Pentru relaţia Furnizori_Cheltuieli:
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data
Valoare
2,150,000
C16 Apa calda 30.06.99 500,000
3,000,000
93
C11 Lift 30.06.99 200,000
Tabela nenormalizată Furnizori_Cheltuieli.
Conform primei modalităţi, eliminăm grupurile repetitive, prin crearea altor

înregistrări, în care să fie introduse valorile din aceste grupuri, împreună cu celelalte valori ale
atributelor din înregistrarea la care se lucrează. Tabele astefel rezultată va fi în formă normală
unu.
În a doua modalitate, fiecere valoare a grupurilor repetitive le copiem într-o nouă
relaţie împreună cu cheia primară din tabela iniţială. Putem avea mai mu lte grupuri repetitive.
În acest caz creăm mai multe relaţii noi. Aceste relaţii noi, precum şi tabela normalizată vor fi
în formă normală unu.
Observăm că pentru furnizorul "Romgaz" avem două tipuri de cheltuieli. La fel şi
pentru furnizorul "Renel".
Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la fiecare
intersecţie linie coloană.
Daca vom normaliza dupa prima metoda, vom scrie repetiţiile pe diferite rânduri iar
coloanele care nu conţin repetiţii, vor fii copiate corespunzator pe fiecare rând
Exemple 4.2.2
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data
Valoare
2,150,000
F100 Romgaz R1234567 C16 Apa calda 30.06.99
500,000
3,000,000
F110 Renel R7654321 C11 Lift 30.06.99
200,000
Tabela Furnizori_Cheltuieli în 1NF
În tabela normalizatã, cheia va fi (Cod_furn, Cod_chelt, Data).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu
informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două
tabele vor fi următoarele:
Exemple 4.2.3
Furnizori (Cod_furn, Den_furn, Cod_fiscal)
Cheltuieli (Cod_furn, Cod_chelt, Data, Den_chelt, Valoare)
Cele două tabele astfel create sunt în 1NF:
Cheltuieli
Cod_furn. Cod_chelt Data Den_chelt Valoare
F100 C15 30.06.99 Incalzire 1500000
F100 2 C16 30.06.99 Apa calda 500000
F110 3 C10 30.06.99 Iluminat 3000000
F110 4 C11 30.06.99 Lift 200000
Furnizori
Cod_furn Den_furn Cod_fiscal
F100 Romgaz R1234567
94
F110 Renel R7654321
Relaţiile Cheltuieli şi Furnizori, create prin metoda a doua de normalizare.
Pentru a demonstra trecerea la forma normală doi şi mai departe, vom folosi relaţia
Furnizori_Cheltuieli, prezentata în exemplul 4.2.2.
Forma Normală Doi (2NF)
Forma normală doi se obtine utilizand conceptul de dependenţă funcţională tot ală.
Dependenţa funcţională totală. Dacă A este un subset de doua sau mai multe atribute şi B
este atribut (sau subset de atribute) al aceleiasi relaţii, spunem ca B este total dependent
funcţional de grupul de atribute A, dacă B este dependent funcţional de A, dar nu este
dependent funcţional de nici un subset de atribute din A.
Exemple 4.2.4
De exemplu să luăm următoarea dependenţă funcţională:
Cod_chelt, Cod_furn, Data  Valoare
Dependenţa funcţională este totala pentru ca Valoare nu depinde functional de
nici un subset de atribute al grupului Cod_chelt, Cod_furn, Data.
Forma normală doi trebuie verificată doar la relaţiile care au cheie compusă pe poziţie
de cheie primară. Relaţia la care cheia primară se compune dintr-un singul atribut, este în 2NF
daca este in 1NF.
Forma Normală Doi (2NF). O relaţie este în forma normală doi, dacă este în forma normală
unu şi fiecare atribut care nu aparţine cheii primare, este total dependent funcţional de cheia
primară.
Vom demonstra aducerea la forma normală doi, folosind relaţia Furnizori_Cheltuieli.
Putem trece la forma normală doi prin ştergerea atributelor care nu depind total de cheia
primară şi trecerea lor într-o altă tabelă împreună cu determinantul lor. După efectuarea
acestor transformări, vom obtine următoarele relaţii:
Exemple Relatia Cheltuieli:

Cod_furn. Cod_chelt Data Valoare
F100 C15 30.06.99 1500000
F100 C16 30.06.99 500000
F110 C10 30.06.99 3000000
F110 C11 30.06.99 200000
Relaţia Furnizori:
Cod_furn Den_furn Cod_fiscal
F100 Romgaz R1234567
F110 Renel R7654321
Relatia Tip_cheltuiala:
Cod_Chelt Den_chelt
C15 Incalzire
C16 Apa calda
C10 Iluminat
C11 Lift
Figura 5.5. Relaţiile rezultate după trecerea la 2NF a relaţiei
Furnizori_Cheltuieli.
Relaţiile rezultate au următoarele scheme de relatie:
Furnizori = (Cod_furn., Den_furn, Cod_fiscal)
95
Tip cheltuială = (Cod_Chelt., Den_chelt)
Cheltuieli = (Cod_furn, Cod_chelt, Data, Valoare)
Forma Normală Trei (3NF)

Forma normală doi chiar dacă nu conţine atâta redundanţă ca forma normală unu,
totuşi există cazuri în care pot apărea anomalii la actualizare. Aceste anomalii apar din cauza
redundanţei generate de dependenţa tranzitivă.
Dependenţă tranzitivă. Dacă atributele A, B, C sunt în relaţiile AB şi BC, atunci
spunem că atributul C este dependent tranzitiv de atributul A, via B.
Forma Normală Trei (3NF). Spunem ca o relaţie este în formă normala trei daca este deja in
forma normală doi şi nici un atribut care nu aparţine cheii p rimare nu este tranzitiv dependent
de cheia primara.
În cazul existenţei dependenţei tranzitive, ştergem coloanele care sunt tranzitiv
dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane, împreună cu
determinantul lor, adică cheia primară.
Examinând relaţiile în forma normală de mai sus, observăm că nu există dependenţe
tranzitive. Deci relaţiile sunt în formă normală trei.
Exemple
Să considerăm tabela cu schema:
Carte=(cod_car,titlu,cod_dom,denumire_domeniu)
Cheia este cod_car.
Avem depemdenţele funcţionale:
cod_car cod_dom
cod_car titlu
cod_dom denumiredomeniu
vedem că dependeţa lui denumire_domeniu de cod_car este tranzitivă (via
cod_dom)
Descompunerea acestei scheme pentru a ajunge la formă normală trei e ste:
Carte=(cod_car,titlu,cod_dom)
Cu cheia cod_car.
Domenii=( cod_dom,denumire_domeniu)
Cu cheia cod_dom.
Forma Normală Boyce-Codd (BCNF)

Baza de date trebuie proiectată astfel încât să nu conţină dependenţe parţiale sau
tranzitive, pentru că altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului.
Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. O relaţie cu o
singură cheie candidat în formă normală trei este şi în formă normală Boyce -Codd.
Forma normală Boyce-Codd (BCNF). Spunem ca o relaţie este în forma normală Boyce-
Codd dacă şi numai dacă orice determinant din relaţie este cheie candidat.
Să căutăm determinanţii din exemplul de mai sus:
Cod_furn  Den_furn, Cod_fiscal
Cod_chelt  Den_chelt
Cod_furn, Cod_chelt, Data  Valoare
96
Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. Deci relatiile din
exemplul de mai sus sunt în formă normală Boyce-Codd. Relaţiile în formă normală trei sunt
în general şi în formă normală Boyce-Codd. În cazul în care relaţia nu este în formă normală
Boyce-Codd, trecerea la BCNF se realizează prin ştergerea din relaţia iniţială a atributelor
care sunt asociate unui determinant care nu este cheie candidat şi crearea unei noi relaţii cu
aceste atribute şi determinantul lor.
Există situaţii când este foarte greu de descompus relatiile, ca să ajungem la BCNF. În
aceste situaţii este indicata rămânerea la forma normală trei.
M4.U4.2. Rezumat
Forma Normală Unu (1NF)
Trebuie să căutăm toate intersecţiile de linii şi coloane, unde există repetiţii.
Aceste repetiţii se pot elimina prin două madalităţi:
 Crearea de noi înregistrări pentru fiecare valoare a repetiţiei, după care se caută
o nouă cheie primară.
 Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care vor
conţine atributele şterse, precum şi cheia primara din relaţia iniţială.
Forma Normală Doi (2NF)
Se caută dependenţele totale de cheia primara, adică toate atributele care depind
funcţional de un subset de atribute a cheii primare. Dacă cheia primară este
compusă dintr-un singur atribut, atunci relaţia este în forma normală doi, daca
este deja in forma normala unu. Dacă există dependenţe partiale, ştergem
atributele care depind parţial de cheia primara şi creăm o relaţie nouă care să se
compună din atributele şterse împreună cu determinantul lor.
Forma Normală Trei (3NF)
Pentru a trece la forma normală trei, trebuie să eliminăm dependenţele tranzitive.
Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv de cheia
primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi
determinantul lor.
Forma Normală Boyce-Codd (BCNF)
Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie să
fie cheie candidat. În cazul în care nu este îndeplinită această cerinţă, vom şterge
atributele dependente funcţional de determinantul care nu este cheie candidat şi
creăm o nouă relaţie în care să avem atributele şterse şi determinantul lor. În
unele cazuri trecerea la forma normală Boyce-Codd complică foarte mult baza de
date, caz în care este de preferat rămânerea la forma normală trei.
97
4.2.1) Aduceţi la forma normală 1 urmărtoarea tabelă:
Relaţia Furnizori_Cheltuieli:
Cod Denumire Cod Nr. Cod Denumire Valoare
Furn. fiscal Crt. Chelt. Cheltuială
F100 Romgaz R1234567 1 C15 Chelt pt. 1500000
Încălzire
2 C16 Chelt pt. 500000
Bucătării
F110 Renel R7654321 3 C10 Chelt cu 3000000
iluminatul
4 C11 Chelt pt. 200000
Func. liftului
4.2.2 Aduceţi la forma normală 2 schema:

(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod,
Valoare)
4.2.3 Aduceţi la forma normală 3 schema:
carte = (c_carte, titlu, cod_domeniu, den_domeniu)
4.2.4 Aduceţi, pe rând, la formă nprmală 1, 2 şi 3 tabela:
98
Modulul 5. Metodologia de proiectare a bazelor de date
relaţionale
Cuprins
Introducere
Obiectivele modului
U5.1 Generalităţi şi proiectarea conceptuală
U5.2 Proiectarea logica
U5.3 Proiectarea fizica
U5.4 Tranzacţii şi concurenţă
U5.5 Metode de control al concurenţei.
M5. Introducere
Metodologia de proiectare este o aproximare structurată, care utilizează
proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul de
proiectare.
Metodologia de proiectare se compune din etape, care la rândul lor se
compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de
date.
În mod obişnuit, un sistem SGBD deserveşte mai mulţi utilizatori, care accesează
concurent datele din tabele. Accesul concurent al utilizatorilor este asigurat prin
capacitatea de multiprogramare a sistemului de operare al calculatorului gazdă, care
permite execuţia concurentă a mai multor procese. Execuţia concurentă a mai multor
procese poate avea loc atât într-un sistem uniprocesor, prin partajarea (împărţirea)
timpului de execuţie al procesorului între mai multe procese, cât şi într-un sistem
multiprocesor în care mai multe procese pot fi executate în mod real simultan, pe mai
multe procesoare ale sistemului. Indiferent de numărul de procesoare ale sistemului,
accesul concurent al mai multor utilizatori la datele memorate în tabelele unei baze de
date necesită tehnici de menţinere a consistenţei (corectitudinii) şi a siguranţei datelor
memorate.

 respecte o metodologie de proiectare
 creeze modelul conceptual al unui sistem informatic
 realizeze proiectul logic local
 realizeze proiectul logic global
 aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.
99
 descrie corect structura fizică a bazei de date
 proiecteze cereri
 proiecteze formulare
 proiecteze rapoarte
 construiască tranzacţii corecte
 aleagă cea mai bună metodă de control al concurenţei
 introducă regulile de integritate
 să impună măsuri de securitate
100
Unitatea de învăţare U5.1 Generalităţi şi pro iectarea conceptuală
M5U1 Introducere
Metodologia de proiectare are o mare importanţă în ordonarea muncii grele de
proiectare a unui sistem informatic. Prima etapă, mai puţin standardizată şi care
depinde esenţial de experienţa celui care o îdeplineşte, este proiectarea
conceptuală, în care trebuie să aflăm cum funcţionează intreprinderea şi ce parte
din circuitul informaţional va fi automatizată.
M5.U1. Obiectivele unităţii de învăţare

 respecte o metodologie de proiectare
 creeze modelul conceptual al unui sistem informatic
În orice domeniu folosirea unei metodologii are o mare importanţă. O metodologie

este o cale de a apllica în proiectare metoda divide et impera. Separarea în paşi asigură
divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat, iar partea de
impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul
nostru, realizarea modelului logic global. Un alt avantaj îl constitue faptul că la terminarea
activităţii de proiectare, avem o mare parte din documentaţia proiectului realizată. De
asemenea urmărirea uinei metodologii face posibil lucru în echipă prin divizarea sarcinilor ţi
posibibilitatea urmăririi stadiului la care s-a ajuns.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi
proiectarea fizică.
Definiţie: Proiectare logică: Procesul de construcţie a unui model de informaţii folosite într-o
întreprindere, bazată pe modelul de date, dar independent de particularizările sistemului de
gestiune a bazei de date şi a altor considerente fizice.
Proiectarea logică începe cu crearea modelului conceptual al bazei de date, care este
independent de implementarea într-un SGBD. Modelul conceptual este apoi proiectat pe un
model logic, care va influenţa mai târziu modelul de date în care se va implementa.
Definiţie: Proiectare fizică: Este procesul de descriere a implementării bazei de date
într-un SGBD.
În această etapă a proiectării este creată baza de date într-un SGBD, împreună cu
procedurile de actualizare. În această etapă există un feedback între proiectarea fizică şi cea
logică, pentru că deciziile luate la implementarea fizică pot afecta baza de date logice.
Pe parcursul activităţii de proiectare trebuie să fie satisfăcute mai multe cerinţe, multe dintre ele fiind
contradictorii şi dificil de îndeplinit: obţinerea unu i timp de răspuns la interogări cât mai mic, şi, în
acelaşi timp, utilizarea unui spaţiu de memorare cât mai redus; asigurarea unui mod de acces la date
cât mai simplu dar intuitiv, etc.
101
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai multe ori,
procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Prin contrast, proiectul
rezultat trebuie să conţină schema bazei de date precis definită, dat fiind că, după implementarea
aplicaţiilor, modificarea bazei de date este mult mai dificilă.
Terminologia folosită în domeniul proiectării bazelor de date este destul de variată, existând şi
unele ambiguităţi privind denumirile etapelor sau ale tipurilor de scheme ale bazelor de date. Cel mai
frecvent, pentru proiectul conceptual al unei baze de date se folosesc denumirile de schemă
conceptuală de nivel înalt sau schemă conceptuală independentă de SGBD sau, chiar mai simplu,
schemă conceptuală. Proiectul logic al unei baze de date este denumit schemă logică sau schemă
conceptuală dependentă de SGBD în cele mai multe lucrări din domeniul proiectării bazelor de date.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă
utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile
pentru aceasta. De asemenea, este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune
a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salar izare, etc.).
În general, în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. De regulă, persoana cea
mai avizată din cadrul fiecărui grup de utilizatori este cooptată ca participant în
activităţile ulterioare de colectare şi analiză a cerinţelor.
• Revederea documentaţiei existente privind aplicaţiile dorite, în afară de documentaţiile
aplicaţiilor dorite se studiază şi alte documentaţii şi interviuri. Se colectează
răspunsuri scrise de la utilizatorii potenţiali la diferite seturi de întrebări şi se
organizează interviuri cu persoanele care reprezintă diferitele grupuri de utilizatori,
în felul acesta, proiectanţii pot înţelege care sunt priorităţile de proiectare a
bazei de date, importanţa diferitelor aplicaţii şi performanţele dorite de la acestea.
Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii,

formularele existente de introducere a datelor, rapoartele utilizate în controlul activităţii
respective, etc.), pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date.
• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.
Această activitate include analiza fluxului de informaţii în cadrul sistemului, precum
şi analiza tipurilor de tranzacţii şi a frecventei de lansare a acestora. Deosebit de
importantă este şi stabilirea volumului de date conţinute în mod tipic de baza de
date, a volumului şi frecvenţei datelor actualizate precum şi a volumului datelor
retumate de interogări şi a frecvenţei acestora.
Chestionare structurate, în general în limbaj natural, pe baza cărora se pot construi diagrame, tabele,
grafice, etc., manual sau folosind diferi te instrumente software de proiectare. Această fază este puternic
consumatoare de timp, dar este crucială pentru succesul sistemului informatic.
102
Să ne reamintim...
O metodologie este o cale de a apllica în proiectare metoda divide et
impera. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai
mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de
succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,
realizarea modelului logic global.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea
logică şi proiectarea fizică.
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai
multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.
Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce
rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce
informaţii primare sunt disponibile pentru aceasta.
în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele
activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.
• Revederea documentaţiei existente privind aplicaţiile dorite
• şi interviuri.
• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a
întreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate în controlul activităţii respective, etc.), pentru a se decide dacă
aceste aspecte influenţează cerinţele bazei de date.
• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.
Prezentarea metodologiei
Prima dată să vedem care sunt paşii de urmat în proiectare:
Pasul 1. Proiectarea logică a bazei de date relaţionale: Crearea unui model conceptual
local, pentru vederile utilizatorilor.
Pasul 1.1. Identificarea tipurilor de entităţi.
Pasul 1.2. Identificarea tipurilor de relaţii.
Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de
relaţii.
Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.
Pasul 1.6. Specializare/generalizare (pas opţional).
Pasul 1.7. Desenarea diagramei entity-relationship.
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 2. Crearea şi validarea modelului logic local.
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utilizând normalizarea.
Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.
Pasul 2.5. Desenarea diagramei ER.
103
Pasul 2.6. Definirea regulilor de integritate a bazei de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 3. Crearea şi validarea modelului logic global de date.
Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.
Pasul 3.2. Validarea modelului logic global.
Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
Pasul 3.4. Desenarea diagramei ER finale.
Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
Pasul 4. Proiectarea fizică şi implementarea bazei de date relaţionale: Translatarea
modelului logic global în SGBD.
Pasul 4.1. Proiectarea relaţiilor de bază în SGBD.
Pasul 4.2. Crearea regulilor de integritate în SGBD.
Pasul 5. Proiectarea şi implementarea reprezentării fizice.
Pasul 5.1. Analizarea tranzacţiilor.
Pasul 5.2. Alegerea organizării fişierelor.
Pasul 5.3. Alegerea indecsilor secundari.
Pasul 5.4. Introducerea unei redundanţe comntrolate.
Pasul 5.5. Estimarea spaţiului pe disc.
Pasul 6. Proiectarea şi implementarea unui mechanism de securitate.
Pasul 6.1. Crearea view-urilor pentru utilizatori.
Pasul 6.2. Proiectarea regulilor de acces la baza de date.
Pasul 7. Verificarea sistemului operaţional.
Proiectarea logică a bazei de date se divide în trei paşi mari. Primul pas are ca
obiectiv, descompunerea proiectării sistemului informatic în vederi, care se pot discuta cu
utilizatorii sistemului. Modelul de date astfel creat, se validează prin normalizare şi prin
tranzacţii în pasul doi. În final, se generează modelul global al întreprinderii, care este la
rândul lui validat şi verificat cu ajutorul utilizatorului sistemului.
Factori critici pentru succesul proiectării logice:
 Lucrul interactiv cu utilizatorul sistemului.
 Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.
 Încorporarea regulilor de integritate în modelul logic de date.
 Combinarea validării conceptuale, prin normalizare şi prin tranzactii, la proiectarea
modelului logic de baze de date.
 Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile.
 Crearea dicţionarului de date, ca supliment al modelului de date.
Crearea modelului logic

Pasul 1. Crearea modelului conceptual local, pentru utilizatori.
Deşi nu este obligatoriu, această fază se poate menţine independentă de SGBD şi produce un
model de date de nivel înalt, care va fi implementat după transpunerea lui într-un model de date
specific. Chiar dacă proiectanţii pot porni direct cu scheme conceptuale specifice unui anumit SGBD
(care se mai numesc şi scheme logice), este totuşi recomandabil să se realizeze mai întâi schema
conceptuală de nivel înalt independentă de SGBD, datorită u rmătoarelor motive:
• Scopul proiectării schemei conceptuale este înţelegerea cât mai completă a structurii
bazei de date, a asocierilor şi a constrângerilor de către proiectanţi şi programatori. Acest
deziderat se obţine mult mai bine independent de un anumit SGBD, deoarece un model
de date de nivel înalt este mult mai general şi mai expresiv, în timp ce fiecare SGBD
104
are propriile restricţii şi soluţii particulare, care nu trebuie să influenţeze proiectul
schemei conceptuale.
Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilior.
Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru
realizarea sistemului, ceea ce putem culege, discutând cu viitorii utilizatori ai bazei de date.
Acrastă discuţie presupune o despărţire în vederi, a bazei de date, vederi care pot lucra
separat.
Despărţirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza
datelor globale şi găsirea de părţi relativ independente. O altă modalitate ar fi analiza
rapoartelor, procedurilor cerute şi/sau observarea sistemului existent în lucru.
Modelele conceptuale locale trebuie să conţină:
 tipuri de entităţi,
 tipuri de relaţii,
 atribute,
 domeniile atributelor,
 cheile candidat,
 chei primare
Paşii din prima etapă a proiectării logice sunt:
 Pasul 1.1. Identificarea tipurilor de entităţi.
 Pasul 1.2. Identificarea tipurilor de relaţii.
 Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de
relaţii.
 Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
 Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.
 Pasul 1.6. Specializare/generalizare (pas opţional).
 Pasul 1.7. Desenarea diagramei entity-relationship.
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 1.1. Identificarea tipurilor de entităţi
Obiectivul: Identificarea tipurilor de entităţi principale în vederile utilizatorilor.
Primul pas în proiectarea bazei de date este identificarea entităţiilor din datele
furnizate de utilizatori. De exemplu, dacă avem informaţiile Nr_Mat, Nr_Bloc, Scara, Etaj,
Apartament şi Nume, putem identifica entitatea Locatari. În general putem identifica
entităţiile în mai multe moduri. De exemplu în locul entităţii Locatari, am pu tea crea o entitate
Locatari cu atributele Nr_Mat şi Nume, iar celelelte informaţii în entitatea
ProprietateLocatari.
Există cazuri când entităţiile sunt greu de identificat, pentru că modul de prezentare a
viitorilor utilizatori necesită explicaţii. Utilizatorii descriu aceste entităţi, folosind sinonime şi
omonime, ceea ce îngreunează identificarea entităţilor. Sinonimele prin care se descrie aceaşi
entitate, se pot considera sinonime şi la crearea modelului logic, evidenţiind aceste sinonime
ca diverse aliasuri ai entităţiilor.
Documentarea tipurilor de entităţi
După identificarea entităţiilor, le dăm câte un nume, iar aceste nume le vom evidenţia
în dicţionarul de date, împreună cu explicaţiile despre entităţi, precum şi posibilele aliasuri.
Pasul 1.2. Identificarea tipurilor de relaţii
Obiectivul: Identificarea relaţiilor importante dintre entităţi.
După identificarea entităţiilor, va trebui să identificăm şi relaţiile importante dintre
aceste entităţi. Relaţiile se descriu printr-un verb al relaţiei. De exemplu:
105
Exemple
 Scările sunt Locuite de Locatari
 Furnizorii Provoacă Cheltuieli
Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi facultate.

Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi note.
La identificarea relaţiilor vom lua în considerare doar relaţiile care ne interesează.

Degeaba există şi alte relaţii care să se poată identificate, dacă nu prezintă importanţă pentru
problema noastră, atunci nu le luăm în consideraţie.
În cele mai multe din cazuri, relaţiile sunt binare, adică se realizează întrea exact două
entităţi. Există şi relaţii mai complexe, care se realizează între mai multe entităţi, sau relaţii
recursive, care pune în relaţie o singură entitate cu ea însăşi.
Determinarea cardinalităţii şi a participării la tipurile de relaţii
După identificarea tipurilor de relaţii, trebuie să determinăm cardinalitatea lor, alegând
dintre posibilităţiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dacă se
cunosc valori specifice ale cardinalităţiilor, aceste valori se scriu la documentarea relaţiilor. În
continuare determinăm şi participarea la relaţie, care poate fii totală, sau parţială.
Care este cardinalitatea relaţiei dintre student şi facultate.
Care este cardinalitatea relaţiei dintre student şi note.
Documentarea tipurilor de relaţii

După identificarea tipurilor de relaţii, le denumim şi le introducem în dicţionarul de
date, împreună cu cardinalitatea şi participarea lor.
Utilizarea modelării ER
Pentru vizualizarea sistemelor complicate, utilizăm diagrama ER, pentru că este mult
mai uşor de a cuprinde toate informaţiile. Vă propunem ca să utilizaţi întotdeauna diagrama
ER, pentru o mai bună vizualizare a datelor.
Pasul 1.3. Identificarea şi asocierea de atribute la tipurile de entităţi şi tipurile de
relaţii
Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii.
Următorul pas în metodologie este identificarea atributelor. Aceste atribute se
identifică în aceeaşi mod ca şi entităţiile. Pentru o mai uşoară identificare, trebuie să luăm
entităţiile şi relaţiile ra rând şi să ne punem următoarea întrebare: Ce informaţii deţinem
despre această … ? Răspunsul la această întrebare ne va da atributele căutate.
Atribute simple sau compuse
Este important să notăm dacă un atribut este simplu sau compus. Conform acestei
informaţii va trebui să luăm decizii referitoare la acel atribut. Dacă un atribut este compus,
atunci putem opta pentru descompunerea sa, dacă este necesară prelucrarea separată a detelor
compuse, sau putem să-l lăsăm compus în caz contrar.
Exemple
De exemplu, atributul Adresă conţine informaţiile (Nr_Bloc, Scara, Etaj,
Apartament). Noi va trebui să prelucrăm aceste informaţii separat, deci vom
descompune acest atribut în cele patru atribute simple.
Descompuneţi atributul adresă din tabela student.
106
Putem avea cazuri în care atributele simple să le compunem.
Exemple
De exemplu în cazul atributelor Nume_Familie şi Prenume, neavând nevoie de
aceste informaţii separat, le vom compune în atributul Nume.
Ce puteţi spune despre atributul nume din tabela student.
Atribute derivate (calculate)

Sunt acele atribute, care se pot calcula din alte atribute existente în baza de date.
Exemple
De exemplu numărul locatarilor de pe o scară se poate număra în tipul de entitate
Locatari. Deci acest atribut este atribut derivat.
Ce puteţi spune despre atributul vârsta din tabela student.
În general aceste atribute nu trebuie incluse în modelul de date, pentru că în cazul în

care se modifică atributul din care se calculează atributul derivat, trebuie să se modifice şi
acesta. În cazul în care nu se modifică, baza de date devine inconsistentă. De aceea este
important de a menţiona dacă un atribut este sau nu derivat.
Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau relaţii, ne
întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care să asociem atributul
respectiv.
În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va trebui să
decidem dacă generalizăm sau nu aceste entităţi, proces care este descris la pasul 1.6.
Documentarea atributelor
După identificarea atributelor, le asociem un nume, şi le înregistrăm în dicţionarul de
date, împreună cu următoarele informaţii:
 numele şi descrierea atributului,
 toate aliasurile şi sinonimele prin care este cunoscut atributul,
 tipul de date şi lungimea,
 valorile iniţiale ale atributelor (dacă există),
 dacă atributul acceptă sau nu valoarea nulă,
 dacă atributul este sau nu compus, şi dacă este atunci atributele simple care îl compun,
 dacă atributul este sau nu derivat şi atributul din care derivă,
 dacă atributul acceptă sau nu mai multe valori.
Pasul 1.2. Determinarea domeniului atributelor
Obiectivul: Determinarea domeniului atributelor în modelul conceptual local.
Domeniul atributului este o mulţime de valori pe care o poate lua. Pentru a controla în
totalitate domeniul atributelor, se poate evidenţia următoarele:
 setul de valori admisibile pentru un atribut,
 operaţiile admisibile asupra unui atribut,
107
 ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte atribute,
 mărimea şi formatul câmpului atributului.
Documentarea domeniilor atributelor
Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui atribut.
Pasul 1.5. Determinarea atributelor care compun cheile candidat şi primare
Obiectivul: Identificarea cheilor candidat pentru fiecare entitate şi alegerea cheilor
primare în cazul în care sunt mai multe chei candidat.
Identificarea cheilor şi selectarea cheilor primare
O cheie candidat este un atribut, sau un grup de atribute care identifică unic fiecare
înregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. În acest
caz trebuie să alegem dintre ele o cheie primară. Cheile candidat care nu sunt primare, se vor
numi chei alternante. Pentru alegerea unei chei ca fiind cheie primară, vom ţine cont de
următoarele:
 cheia candidat, care are un număr minim de atribute,
 cheia candidat, care îşi va schimba cel mai rar valoarea,
 cheia candidat, care este cel mai puţin probabil să sufere modificări în viitor,
 cheia candidat, care este compusă din cele mai puţine caractere (în cazul atributelor de tip
caracter),
 cheia candidat, care este cel mai uşor de folosit din punctul de vedere al utilizatorului.
Care ar fi cheile candidat ale tabelei student. Care va fi cheia principală.
Prin procesul de identificare a cheilor primare, deducem şi dacă o entitate este entitate
“tare”, sau entitate “slabă”. Dacă reuşim să identificăm o cheie primară, atunci entitatea este
tare, altfel este slabă. O entitate slabă nu poate exista fără o entitate tare, care să-i fie
“părinte”. Cheia primară a entităţii slabe este derivată parţial sau total din cheia primară a
entităţii tari.
Documentarea cheilor primare şi alternante
Înscriem cheile primare şi pe cele alternante în dicţionarul de date.
Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional)
Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă, între entităţiile
apropiate.
În acest pas putem opta pentru a continua modelarea ER, folosind procesul de
generalizare sau specializare. Dacă alegem procesul de specializare, vom încerca să definim
una, sau mai multe subclase ale entităţii respective. Dacă însă alegem procesul de
generalizare, vom căuta superclase pentru acea entitate.
Un exemplu pentru procesul de generalizare ar fii entităţiile Şef_de_scară şi Familii.
Ambele entităţi au atribuite următoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament şi
Nume. Pe lângă aceste atribute, entitatea Şef_de_scară mai are asociate atributul
Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente şi Nr_chei.
Deci, cele două entităţi având atribute în comun, le putem generaliza în entitatea Locatari,
care va conţine atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar
atributele diferite - particularizările faţă de superclasă.
Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptuală a
vederilor utilizatorilor despre întreprindere.
În momentul acesta suntem în măsură să prezentăm o giagramă completă a modelului
bazat pe vederile utilizatorilor despre întreprindere.
108
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului
Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a
vedea dacă modelul este o reprezentare adevărată a vederii utilizatorului despre întreprindere.
Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest

model include diagrama ER şi documentaţia anexată. În cazul în care apare orice fel de
anomalie, repetăm procesul de mai înainte şi remediem problema.
Să ne reamintim...
 Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
 Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.
M5.U5.1. Rezumat
O metodologie este o cale de a apllica în proiectare metoda divide et
impera. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai
mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de
succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,
realizarea modelului logic global.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică
şi proiectarea fizică.
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai
multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.
Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce
rezultate se aşteaptă utilizatorii potenţiali să obţină de la b aza de date respectivă şi ce
informaţii primare sunt disponibile pentru aceasta.
în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele
activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.
• Revederea documentaţiei existente privind aplicaţiile dorite
• şi interviuri.
109
• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a
întreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate în controlul activităţii respective, etc.), pentru a se decide dacă aceste
aspecte influenţează cerinţele bazei de date.
Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.
 Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
 Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.

5.1.1. Realizaţi paşii de proiectare conceptuala locală pentru subsistemul
didactic din facultate.
110
Unitatea de învăţare U5.2 Proiectarea logică.
M5U2 Introducere
În faza de proiectare logică a unei baze de date se realizează schema conceptuală
globală şi schemele conceptuale (vederile) externe pentru sistemul SGBD ales, pornind de
la schema conceptuală şi schemele externe de nivel înalt independen te de SGBD, proiectate
în faza precedentă.
M5.U2. Obiectivele unităţii de învăţare

 realizeze proiectul logic local
 realizeze proiectul logic global
Durata medie de parcurgere acestei unităţi de învăţare este de 3 ore.
Această fază de proiectare logică poate fi realizată în două subfaze:

 Transpunerea schemei conceptuale în modelul de date al sistemului SGBD ales, dar
independent de sistemul de gestiune propriu-zis. în cazul modelului relaţional,
transpunerea se face prin corespondenţa dintre elementele schemei conceptuale de
nivel înalt reprezentată prin diagrama Entitate-Asociere (tipuri de entităţi, atribute,
asocieri) şi elementele modelului relaţional (relaţii, atribute, referinţe). Se obţine un
proiect logic dependent de modelul de date, dar independent de sistem, în această
subfazâ se face şi analiza normalizării relaţiilor, normalizarea fiecărei relaţii până la
nivelul adecvat şi documentarea tuturor dependenţelor de date care nu
sunt determinate de chei ale relaţiilor (necesară pentru proiectarea procedurilor de
verificare şi impunere a dependenţelor respective).
 Rafinarea schemei conceptuale şi a schemelor externe obţinute anterior, astfel
încât să se utilizeze unele (sau cât mai multe) din facilităţile oferite de sistemul
SGBD ales (modul de generare a cheilor primare, definirea constrângerilor, etc.).
Rezultatul acestei faze de proiectare îl constituie schema conceptuală şi schemele externe
ale bazei de date, dependente de sistemul SGBD ales şi de modelul de date al acestuia.
Pasul 2. Crearea şi validarea modelului logic local
Obiectivul: Crearea unui model logic local bazată pe modelul conceptual al
utilizatorilor asupra întreprinderii şi validarea ei prin procesul de normalizare şi prin tehnica
tranzacţiilor cerute.
În acest pas verificăm modelul conceptual creat în pasul anterior şi eliminăm din el
structurile care sunt dificil de realizat într-un SGBD. Dacă la sfârşitul acestui proces modelul
ete alterat, vom corecta aceste probleme şi ne vom referi în continuare la modelul rezultat, ca
fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare şi a
tranzacţiilor.
Activităţile din acest pas sunt:
 Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
 Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
111
 Pasul 2.3. Validarea modelului, utilizând normalizarea.
 Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.
 Pasul 2.5. Desenarea diagramei ER.
 Pasul 2.6. Definirea regulilor de integritate ale bazei de date.
 Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local
Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care
se pot implementa greu într-un SGBD şi proiectarea modelului rezultat la modelul logic local.
În pasul întâi am pregătit un model conceptual bazat pe informaţiile date de utilizator.
Acest model trebuie prelucrat, pentru a putea fi uşor de prelucrat de sistemul de gestiune a
bazelor de date. Obiectivele acestui pas sunt:
(1) Eliminarea relaţiilor M:N.
(2) Eliminarea relaţiilor complexe.
(3) Eliminarea relaţiilor recursive.
(4) Eliminarea relaţiilor cu atribute.
(5) Reexaminarea relaţiilor 1:1.
(6) Eliminarea relaţiilor redundante.
(1) Eliminarea relaţiilor multe-la-multe
Dacă în modelul de date apar relaţii de tipul multe-la-multe (M:N), trebuie
descompuse în două relaţii unu-la-multe (1:M) prin adăugarea unei noi entităţi suplimentare.
Exemple
De exemplu, pot exista mai multe cheltuieli pentru o scară, dar şi o cheltuială
(factură) poate să se refere la mai multe scări. Deci relaţia dintre entitatea Scări şi
entitatea Cheltuieli este de M:N, ceea de este evidenţiat în figură.
Scari Cheltuieli
Nr_Bloc Nr_Crt
Scara Cod_Cheltuiala (FK)
Lift Cod_Furnizor (FK)
Nr_factura
Data_factura
Valoare_factura
Sunt platite de
Scari Cheltuieli
Nr_Bloc Nr_Crt
Pe scari
Scara Cod_Furnizor (FK)
Scara (FK)
Lift Nr_Crt (FK) Cod_cheltuiala
Nr_Bloc (FK) Nr_factura
Data_factura
Valoare_factura
Au cheltuieli Se calculeaza
a). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două relaţii 1:M.
112
Desfiinţaţi relaţia dintre student şi note.
Această relaţie se poate elimina, prin crearea unui tip de entitate suplimentar,
care să facă legătura dintre scări şi cheltuieli. Diagrama acestor relaţii se vede în figura b).
Notăm, că tipul de entitate nou creat - Pe_scări - este tip de entitate slabă, pentru că
depinde atît de tipul de entitate Scări, cât şi de tipul de entitate Cheltuieli.
(2) Eliminarea relaţiilor complexe
O relaţie complexă este o relaţie între mai mult de couă tipuri de entităţi. Dacă în
modelul conceptual apar relaţii complexe, acestea trebuie eliminate. Se pot elimina prin
crearea unui nou tip de entitate, care să fie în relaţie de tipul 1:M cu fiecare tip de entitate din
relatia iniţială, partea cu M a relaţiei fiind spre tipul de entitate nou creat.
(3) Eliminarea relaţiilor recursive
Relaţiile recursive sunt nişte relaţii particulare, prin care un tip de entitate este în
relaţie cu el însuşi. Dacă apare o astfel de relaţie în modelul conceptual, ea trebuie eliminată.
Eliminarea se poate rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare
entitate care este legată de entitatea din tipul de entitate iniţial. În acest caz vom avea o relaţie
de tipul 1:M între tipul de entitate iniţial şi tipul de entitate nou creat şi o relaţie de tipul 1:1
între tipul de entitate nou creat şi tipul de entitate iniţial.
(4) Eliminarea relaţiilor cu atribute
Dacă în modelul conceptual avem relaţie cu atribute, putem descompune această
relaţie, identificând un nou tip de entitate în care să înregistrăm atributele necesare.
(5) Reexaminarea relaţiilor de tipul 1:1
În modelul conceptual putem avea entităţi între care să avem relaţie de tipul 1:1. Se
poate întâmpla ca aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. Dacă suntem
în acest caz, unim cele două entităţi, cheia primară devenind cheia primară al uneia dintre
entităţi.
(6) Eliminarea relaţiilor redundante
O relaţie este redundantă dacă se poate ajunge de la un tip de entitate la alt tip de
entitate pe mai multe drumuri. Vă amintim că noi vrem să ajungem la un model minimal şi
deci relaţiile redundante nu sunt necesare. Decizia că o relaţie este redundantă trebuie să fie
precedată de o analiză amănunţită a relaţiilor care compun cele două drumuri dintre cele două
entităţi, pentru că pot apărea situaţii, când o relaţie este aparent redundantă, dar în realitate
este nevoie de ea.
În finalul acestui pas putem spune că am eliminat din modelul conceptual acele
structuri care sunt dificil de implementat şi deci este mai corect ca în continuare să ne referim
la acest model ca fiind un model logic local de date.
Pasul 2.2. Crearea de relaţii peste modelul logic local
Obiectivul: Crearea de relaţii peste modelul logic.
Relaţia pe care un tip de entitate o are cu alt tip de entitate este reprezentată prin
mecanismul cheie primară/cheie străină. Cheia străină pentru o entitate este reproducerea
cheii primare a altei entităţi. Pentru a decide entităţiile unde vom include copia cheii primare a
altei entităţi, trebuie înainte să identificăm entităţile “părinte” şi “fiu”. Entităţile “părinte” se
referă la acele entităţi ale căror chei primare se vor copia în entităţile “fiu”.
Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database
Definition Language - DDL). În acest limbaj, specificăm prima dată numele entităţii, urmat de
atributele asociate între paranteze. După aceea identificăm cheia primară şi toate cheile
alternante, precum şi/sau cheile străine.
113
Tipuri de entitaţi tari
Pentru tipurile de entităţi tari în modelul logic crearea unei relaţii include toate
atributele entităţii. Pentru atributele compuse al unei entităţi, vom include numai atributele
simple din compunerea atributului compus în descrierea entităţii.
Exemple
De exemplu tipul de entitate Familii, prezentată în figură se descrie în următorul
mod.
Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,
Nr_pers_prezente, Nr_chei)
Cheie primară: Nr_mat
Descrieţi relaţia dintre student şi catalog.
Tipurile de entităţi slabe

Descrierea tipurilor de entităţi slabe se face la fel ca şi tipurile de entităţi tari, cu o
completare şi anume, evidenţierea cheii străine.
Exemple
De exemplu descrierea tipului de entitate de mai sus se descrie astfel:
Plăţi (Data, Nr_mat, Valoare, Restanţă)
Cheie primară: Data, Nr_mat
Cheie străină: Nr_mat se referă la Familii(Nr_mat)
Descrieţi tabela catalog.
Menţionăm că în cazul acesta cheia străină este şi în compunerea chei primare. Deci
înainte de introducerea cheii străine, cheia primară nu identifica unic o entitate. La terminarea
acestui pas, putem identifica cheile prinare pentru toate tipurile de entităţi din modelul logic.
Tipurile de relaţii binare de tipul unu-la-unu (1:1)
Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de entitate E1 şi E2
găsim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub
denumirea de cheie străină. Identificarea tipului de entitate “părinte” şi a tipului de entitate
“fiu” depinde de participarea entităţilor la relaţie. Tipul de entitate care participă parţial la
relaţie este desemnat ca fiind “părinte” iar cel cu participare totală “fiu”. Dacă ambele tipuri
de entitate participă parţial sau total la relaţie, atunci tipurile de entităţi se pot evidenţia ca
fiind “părinte” sau “fiu” arbitrar. În cazul în care participarea este totală, putem încerca să
combinăm cele două tipuri de entităţi într-una singură. Această compunere poate să fie
posibilă în cazul în care nici unul dintre cele două tipuri de entităţi nu mai ia parte la altă
relaţie.
Tipurile de relaţii binare de tipul unu-la-multe 1:M
Pentru toate relaţiile 1:M între două entităţi E1 şi E2 în modelul logic de date, vom
avea copia cheii primare a entităţii E1 în compunerea entităţii E2. Totdeauna e ntitatea de
partea unu a relaţiei este considerată entitate “părinte”, iar cealaltă entitate “fiu”.
Atributele cu mai multe valori
114
Pentru ficarea atribut A care permite mai multe valori din entitatea E1 în modelul
logic de date, creăm o nouă relaţie care va conţine atributul A împreună cu cheia primară a
entităţii E1 pe post de cheie străină. Cheia primară a noii relaţii va fi atributul A, sau dacă este
necesar, compunerea ei cu cheia primară al lui E1.
Documentarea relaţiilor şi a atributelor din cheile străine
Actualizăm dicţionarul de date, întroducând fiacare atribut nou introdus în
compunerea unei chei la acest pas.
Pasul 2.3. Validarea, utilizând normalizarea
Obiectivul: Validarea modelului logic, utilizând tehnica normalizării.

Examinăm procesul de normalizare după cum am descris în capitolul 5 Prin
normalizare trebuie să demonstrăm că modelul creat este consistent, conţine redundanţă
minimală şi are stabilitate maximă.
Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână
înpreună. Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru
că există o relaţie logică între ele. Câteodată baza de date nu este cea mai eficientă. Acesta se
argumentează prin următoarele:
 Proiectarea normalizată organizează datele în funcţie de dependenţele funcţionale. Deci
acest proces este situat undeva între proiectarea conceptuală şi cea fizică.
 Proiectul logic nu este un proiect final. El ajută priectantul să înţeleagă natura datelor în
întreprindere. Proiectul fizic poate fi diferit. Există posibilitatea ca unele tipuri de entităţi
să se denormalizeze. Totuşi normalizarea nu este un timp pierdut.
 Proiectul normalizat este robust şi independent de anomaliile de actualizare prezentate
înunitatea de învăţare anterioară..
 Calculatoarele moderne au mult mai multă putere de calcul, ca cele de acum câţiva ani.
Din această cauză, câteodată este mai convenabilă implementarea unei baze de date cu
puţină redundanţă, decât suportarea cheltuielilor pentru procedurile adiţionale.
 Normalizarea produce o bază de date care va fi uşor extensibilă în viitor.
Pasul 2.2. Validarea modelului prin tranzacţii
Obiectivul: Verificarea ca modelul de date suporte toate tranzacţiile cerute de
utilizator.
În acest pas se validează baza de date prin verificarea tranzacţiilor ce se cer de catre
utilizator. Luând în considerare tipurile de entităţi, relaţiile, cheile primare şi străine, încercăm
să rezolvăm manual cerinţele utilizatorilor. Dacă reuşim să rezolvăm fiecare tranzacţie cerută,
atuci înseamnă că modelul creat este valid. Dacă nu putem rezolva o tranzacţie, atunci este
foarte posibil să fi omis un atribut, o relaţie, sau o entitate din modelul de date.
Trebuie să examinăm dacă baza de date suportă tranzacţiile cerute. Mai întâi ar fi prin
rezolvarea de tranzacţii.
Exemple
De exemplu să luăm relaţia dintre Furnizori şi Cheltuieli exemplificată în figură
115
Cheltuieli Furnizori
Nr_Crt Cod_Furnizor Exemplu de relaţie
pentru validarea prin
Cod_Furnizor (FK) Denumire
tranzacţii.
Cod_cheltuiala Cod_fiscal (AK1)
Nr_factura Cont
Data_factura Banca
Valoare_factura Strada
Nr
Bl
Sc
Provoaca Ap
Localitate
Judet
Dar mai bine se descriu tranzacţiile prin fraze SQL.

Inserarea de detalii despre un nou furnizor.
Cheia primară al acestei entităţi este Nr_furnizor. Deci prima dată verific dacă
numărul introdus nu există deja; după care, în caz că nu există acest cod, inserez detaliile
despre furnizor. Dacă există deja codul, nu admit inserarea. Pot verifica şi existenţa codului
fiscal, care pentru această entitate este cheie alternantă.
Ştergerea detaliilor despre un furnizor
Se caută codul furnizorului de şters. Dacă există se şterge furnizorul, actualizându-se
şi cheia străină în entitatea Cheltuieli. Dacă nu există codul cerut, atunci apare un mesaj de
eroare şi nu este şters nici un furnizor.
A doua modalitate de verificare trebuie folosită în cazul în care avem entităţi care nu
iau parte direct la nici o tranzacţie. Pentru verificarea acestor entităţi, vom verifica nişte
interogări pregătie special.
Obiectivul: Desenarea diagramei Entity-Relationship, care este reprezentarea logică a
vederilor utilizatorilor aspra întreprinderii.
Pasul 2.6. Identificarea regulilor de integritate.
Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra
întreprinderii.
Regulile de integritate sunt importante pentru a proteja baza de date împotriva
posibilelor inconsistenţe. Dacă este necesar, putem produce un proiect fizic de bază de date,
pentru a putea vedea mai uşor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
 necesitatea datelor,
 reguli asupra domeniului atributelor,
 integritatea entităţilor,
 integritatea referinţelor,
 regulile întreprinderii.
Necesitatea datelor
Există atribute care nu pot conţine valoarea nulă, ci trebuie să aibă totdeauna o
valoare. De exemplu fiecare cheltuială înregistrată trebuie să aibă asociat un furnizor al
serviciilor sau al obiectelor ce se plătesc prin acea cheltuială.
Aceste reguli deja le-am identificat, când am documentat atributele în pasul 1.3.
116
Reguli asupra domeniului atributelor.
Unele atribute au un domeniu de definiţie bine definit. Aceste domenii trebuie
respectate. Domeniile de definiţie au fost deja identificate când am documentat domeniile
atributelor în pasul 1.2.
Integritatea entităţilor.
Cheia primară a entităţilor nu poate lua valori nule. De exemplu fiecare furnizor
trebuie să aibă un cod diferit de zero.
Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul
1.5.
Integritatea referinţelor
Cheia străina din tipul de entitate “fiu” face ligătura cu o entitate din tipul de entitate
“părinte”. Deci, dacă cheia străină conţine o valoare, ea trebuie neapărat să se regăsească şi în
tipul de entitate “părinte”. De exemplu tipul de entitate Cheltuieli conţine cheia străină
Cod_furnizor, care se referă la Furnizori(Cod_furnizor). Dacă această cheie nu este nu lă,
atunci trebuie să găsim un furnizor care să aibă acel cod.
Prima întrebare pe care trebuie să ne-o ponem este: Poate fii cheia străină nulă? În
cazul exemplului nostru asta ar însemna că există cheltuieli care nu se prătesc nimănui. Aceste
cazuri nu sunt admise de lege, deci nu putem avea valoare nulă în cheia străină din tipul de
entitate Cheltuieli.
În general dacă pariciparea tipului de entitate “fiu” este totală, atunci nu putem avea
valoare nulă în cheia străină. În caz contrar putem avea valoare nulă.
Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaţia de mai
sus dintre Furnizori şi Cheltuieli, care este de tipul 1:M. Considerăm următoarele cazuri:
Cazul 1: Inserarea unei entităţi în tipul de entitate “fiu” (Cheltuieli): Pentru a verifica
integritatea referinţei, verificăm dacă atributele din componenţa cheii străine (Cod_furnizor)
sunt vide, sau să existe entitate în tipul de entitate “părinte” care să aibă valoare cheii primare
egală cu valoare cheii străine.
Cazul 2: Ştergerea unei entităţi din tipul de entitate “fiu” (Cheltuieli): Ştergerea unei
entităţi din tipul de entitate “fiu” nu creează probleme la integritatea referinţelor.
Cazul 3: Actualizarea cheii străine în tipul de entitate “fiu” (Cheltuieli): Acest caz
este similar cazului 1.
Cazul 4: Stergerea unei entităţi din tipul de entitate “părinte” (Furnizori): Dacă se
şterge o entitate din tipul de entitate “părinte”, integritatea referinţelor se strică în cazul în
care există entităţi în tipul de entitate “fiu”, care se referă la entitatea ştearsă. Există strategii
severe de a rezolva integritatea referinţelor:
 FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte, dacă
acesta este referit de o entitate din tipul de entitate fiu. În cazul nostru, nu se acceptă
ştergerea furnizorului, dacă el are o factură de încasat.
 CASCADĂ Dacă o entitate din tipul de entitate părinte este ştearsă, se şterg automat
toate entităţiile din tipurile de entităţi fiu. Dacă tipurile de entităţi fiu au şi ei la rândul lor
alte tipuri de entităţi fiu, se va efectua ştergerea în cascadă în toate tipurile de entităţi fiu,
până la ultimul nivel. Cu alte cuvinte, dacă se şterge un furnizor, atunci automat se şterge
fiacare factură pe carea are de încasat acest furnizor.
 SETARE LA NUL Dacă o entitate din tipul de entitate părinte se şterge, atunci se vor seta
la valoare nulă toate cheile străine ai tipurilor de entităţi fiu în cascadă până la ultimul
nivel. În exemplul nortru, dacă se şterge un furnizor, atunci se vor seta la valoare nulă toate
referinţele la acest furnizor în tipul de entitate Cheltuieli. Acesta înseamnă că nu vom ştii
ca anumite cheltuieli la ce furnizor trebuie plătite.
117
 SETARE IMPLICITĂ Este analog cazului de setare la nul, cu diferenţa că aici se
setează cheia străină la o valoare implicită în loc de valoare nulă. În exemplul nostru putem
seta cheia străină din Cheltuieli la o valoare a cheii primare din Furnizori, care să conţină
un furnizor predefinit - de exemplu cu numele de “Furnizor şters”.
 FĂRĂ MODIFICARE În cazul ştergerii unei entităţi din tipul de antitate părinte, nu se
actualizează deloc cheile străine din tipurile de entităţi fiu.
Cazul 6: Modificarea cheii primare în tipul de entitate părinte (Furnizori): Dacă se
modifică cheia primară din tipul de entitate părinte, integritatea referinţelor se strică. Pentru
menţinerea integrităţii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este
folosirea cazului CASCADĂ.
Regulile întreprinderii.
În final evidenţiem acele reguli care sunt date de realitatea ce se va modela în baza de
date.
Documentarea tuturor regulilor de integritate.
Trecem toate regulile de integritate în dicţionarul de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Obiectivul: Convingerea că modelul creat reprezintă în totalitate realitatea care trebuie
modelată în baza de date.
La acest pas modelul local logic este clomplet şi este bine documentat. Înainte de a
trece la pasul 3, trebuie verificat modelul, să fie conform cu realitatea. În cazul în care se
găsesc diferenţe, ne vom reîntoarce la paşii anteriori şi modificăm cele necasare.
Să ne reamintim...
Activităţile proiectării logice locale sunt:
Pasul 3. Crearea şi validarea modelului global logic de date.

Obiectivul: Combinarea modelelor locale logice într-un model logic global care să
reprezinte întreprinderea care este modelată.
A treia activitate majoră în proiectarea bazei de date logice este crearea modelului
logic global, prin compunerea tuturor modelelor locale. După combinarea modelelor locale,
trebuie validat modelul global prin tehnica de normalizare şi după aceea, prin tehnica
tranzacţiilor. Acest proces utilizează aceleaşi tehnici pe care le -am descris la paşii 2.3. şi 2.2.
Acest proces este foarte important în proiectarea bazei de date, pentru că el
demonstrează că reprezentarea întreprinderii este independentă de orice utilizator, funcţie sau
aplicaţie. Activităţile din acest pas sunt:
 Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.
 Pasul 3.2. Validarea modelului logic global.
 Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
118
 Pasul 3.2. Desenarea diagramei ER finale.
 Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.
Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al
întreprinderii.
În cazul unui sistem mic, cu puţine vederi ai utilizatorilor, este relativ uşor de a
compune modelele logice locale. În cazul unui sistem mai mare însă, trebuie să urmăm un
proces sistematic de realizare a modelului global. Paşii acestui proces sunt următoarele:
(1) Verificarea numelor entităţilor şi a cheilor lor primare.
(2) Verificarea numelor relaţiilor.
(3) Compunerea entităţilor de pe view-urile locale.
(4) Includerea (fără compunere) a entităţilor care apar pe doar una dintre view -uri.
(5) Compunerea relaţiilor de pe view-urile locale.
(6) Includerea (fără compunere) a relaţilor care apar pe doar una dintre view -uri.
(7) Căutarea entităţilor şi a relaţilor care lipsesc (dacă există).
(8) Căutarea cheilor străine.
(9) Căutarea regulilor de integritate.
(10) Desenarea modelului logic global.
(11) Actualizarea documentaţiei.
Cel mai uşor de compus mai multe modele locale este compunerea succesivă a două
câte două dintre modele.
(1) Verificarea numelor entităţilor şi a cheilor lor primare.
Această verificare se face folosind şi dicţionarul creat în decursul paşilor de dinainte.
Probleme apar doar atunci când:
 Două entităţi au acelaşi nume, dar sunt de fapt diferiţi.
 Două entităţi sunt aceleaşi, dar nu au aceleaşi nume.
Probabil va fi necesară analizarea atributelor antităţilor, prntru a rezola această
problemă. În particular, putem utiliza cheia primară şi numele entităţii, pentru a identifica
entităţile echivalente.
(2) Verificarea numelor relaţiilor.
Această activitate este asemănătoare celei descrise la entităţi.
(3) Compunerea entităţilor de pe view-urile locale.
Examinăm numele şi atributele entităţilor ca vor fi compuse. Activităţile care se includ
în acest pas sunt:
 Compunerea entităţilor cau au aceleaşi nume şi aceleaşi chei primare.
 Compunerea entităţilor care au aceleaşi nume, dar cu chei primare diferite.
 Compunerea entităţilor care au nume diferite, cu chei primare egale sau diferite.
Compunerea entităţilor care au aceleaşi nume şi aceleaşi chei primare. În general
entităţile cu aceleaşi chei primare reprezintă “lumea reală”, şi deci pot fi compuse. Atributele
care apar în entităţile de pe ambele view-uri, vor fi trecute doar o singură dată. Dacă într-un
view apare un atribut compus, iar într-un alt view acelaşi atribut dar descompus în atribute
simple, atunci vom întreba, dacă se poate, utilizatorii pentru a decide asupra formei de
utilizare a atributului.
Compunerea entităţilor care au aceleaşi nume, dar au chei primare diferite. În astfel
de situaţii, căutăm două entităţi care au aceleaşi nume şi nu au aceleaşi chei primare, dar au
aceleaşi chei candidat. Cele două entităţi pot fi compuse, urmând ca după compunere să
alegem o cheie primară, restul rămănând chei alternante.
119
Compunerea entităţilor care nu au nume comune şi nu au aceleaşi chei primare.
Aceste entităţi se pot depista prin analiza atributelor celor două entităţi.
(4) Includerea (fără compunere) a entităţilor care apar doar într-un view.
Pasul anterior identifică toate entităţile comune. Celelalte entităţi, se vor include în
modelul logic global exact aşa cum apar în view-ul respectiv.
(5) Compunerea relaţiilor de pe modelele locale.
În acest pas analizăm similitudinile dintre relaţii de pe diferite modele locale. În
timpul compunerii relaţiilor trebuie rezolvate şi conflictele dintre relaţii, ca şi regulile de
cardinalitate şi participare. Putem compune relaţii care au aceleaşi nume şi acelaşi scop, sau
acelaşi scop, dar nume diferite.
(6) Includerea (fără compunere) a relaţiilor care apar doar pe un view.
Relaţile care au rămas neincluse în modelul global după pasul anterior, se includ în
modelul global fără modificare.
(7) Căutarea entităţilor şi relaţilor care lipsesc.
Este unul din cei mai grei paşi din crearea modelului global. Trebuie căutate acele
entităţi şi relaţii, care s-au omis la paşii anteriori şi n-au ajuns în modelul global.
(8) Căutarea cheilor străine.
În decursul paşilor anterioare, s-au modificat entităţi, chei primare şi chei străine. În
acest pas verificăm dacă cheile străine sunt corecte în fiecare entitate fiu şi efectuăm toate
modificările necesare.
(9) Căutarea regulilor de integritate
Verificăm dacă regulile de integritate a modelului global nu sunt în conflict cu regulile
definite la modelele locale. Fiecare problemă de acest gen se rezolvă cu ajutorul utilizatorului
sistemului.
(10) Desenarea diagramei ER.
Acum desenăm diagrama ER pentru modelul global de date.
(11) Actualizarea documentaţiei.
Actualizăm documentaţia, ca să reflecte toate modificările aduse în acest pas
modelului.
Pasul 3.2. Validarea modelului logic global.
Obiectivul: Validarea modelului global logic de date, folosind normalizarea, după care
folosind tranzacţile cerute.
Acest pas este schivalent cu paşii 2.3. şi 2.4., unde am validat modelul local de date.
Pasul 3.3. Verificarea posibilităţilor de extindere a bazei de date în viitor.
Obiectivul: Determinarea ca dacă modelul se acomodează uşor la modificări oricât de
mari ce pot intervenii în viitor.
Este important ca modelul creat să fie expansibil în viitor. Dacă modelul nu are
această calitate, viaţa lui poate fi scurtă şi pentru o mai mare modificare va trebui refăcută de
la început.
Pasul 3.4. Desenarea diagramei Entity-Relationship finale.
Obiectivul: Desenarea unei diagrame ER, care să reprezinte modelul global de date al
întreprinderii.
Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.
Obiectivul: Verificarea că modelul global reprezintă în totalitate realitatea.
În acest moment modelul global este complet şi documentat. Împreună cu utilizatorul
sistemului se verifică acest model şi se aduc eventualele corecturi prin întoarcerea la paşii în
cauză.
120
Să ne reamintim...
Activităţile proiectării logice globale sunt:
M5.U5.2. Rezumat
Activităţile proiectării logice locale sunt:
Activităţile proiectării logice globale sunt:

5.2.1 Faceţi proiectul logic local pentru subsistemul didactic al
facultăţii.
121
Unitatea de învăţare U5.3 Proiectarea fizică.
M5U5.3 Introducere
Proiectarea fizică a bazei de date este procesul de alegere a structurilor de memorare
şi de acces a fişierelor bazei de date, pentru a obţine performanţe cât mai bune, pentru cât
mai multe din aplicaţiile proiectate. De asemenea, în această fază, se sciu programele care
dau cereri, formulare şi rapoarte.

 aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.

 descrie corect structura fizică a bazei de date
 proiecteze cereri
 proiecteze formulare
 proiecteze rapoarte
Fiecare SGBD oferă o varietate de opţiuni de organizare a fişierelor şi a modului de acces

la datele stocate: indexuri, gruparea înregistrărilor corelate în aceleaşi blocuri pe disc (clustering),
tabele de dispersie (hashing), etc.
După alegerea sistemului SGBD, în faza de proiectare fizică a bazei de date se aleg
structurile fişierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv, cele mai
potrivite cu cerinţele de proiectare a sistemului de baze de date.
Ca parametri generali de alegere a opţiunilor proiectului fizic al unei baze de date relaţionale se
pot enumera:
Timpul de răspuns. Acesta este intervalul de timp dintre lansarea i execuţie a unei tranzacţii
şi primirea răspunsului la acea tranzacţie. Cea mai mare pondere în timpul de răspuns o are
execuţia operaţiilor în sistemul SGBD, dar există şi factori care nu se află sub controlul
acestuia (viteza de operare a procesorului, dimensiunea memorie; principale, planificarea
sarcinilor de către sistemul de operare, timpi:
de comunicaţie, etc.).
Utilizarea spaţiului de memorare. Aceasta este dimensiunea spaţiului pe disc utilizat de
fişierele bazei de date şi de structurile de acces l date.
Capacitatea tranzacţionala (transaction throughput). Acesta este numărul mediu de
tranzacţii care pot fi prelucrate pe minut de către sistemul de baze de date, măsurat în
momentele de vârf ale încărcării. Acesta este un parametru critic în multe aplicaţii, în particular
în acele aplicaţii în care există un număr mare de utilizatori care accesează concurent baza
de date (aplicaţii bancare, rezervări de bilete, etc.).
122
In mod obişnuit, trebuie să fie specificate valorile medii şi limitele în cazurile cele mai
defavorabile ale acestor parametri în cadrul cerinţelor de performanţe ale sistemului. Pentru
compararea valorilor acestor parametri, corespunzătoare diferitelor decizii de proiectare
fizică, se fac diferite evaluări analitice sau măsurători experimentale (prototipuri, simulări).
Pentru o schemă conceptuală dată există o multitudine de alternative ale proiectului fizic
pentru un SGBD dat. Deciziile de proiectare fizică se pot lua numai după o analiză a
aplicaţiilor care se vor executa şi în principal a interogărilor şi tranzacţiilor pe care acestea le
vor lansa, în continuare se vor prezenta câteva aspecte ale analizei interogărilor şi tranzacţiilor
necesare pentru a stabili opţiunile proiectului fizic al unei baze de date relaţionale.
Analiza atributelor accesate de interogări şi tranzacţii trebuie să evidenţieze:
Atributele de proiecţie, atributele care sunt conţinute în condiţiile de interogare şi atributele
comune a două sau mai multe relaţii pe care se execută joncţiunile. Astfel de atribute sunt
candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare) care
să accelereze operaţiile de interogare.
Atributele pe care sunt specificate condiţii de selecţie pentru operaţii de ştergere sau
actualizare. La fel ca mai sus, astfel de atribute sunt candidate pentru definirea unor
structuri suplimentare de acces (indexuri secundare).
• Atributele ale căror valori se modifică în cursul operaţiilor de actualizare. Este
recomandabil ca pe astfel de atribute să nu se definească structuri suplimentare de acces
(indexuri secundare) deoarece ar trebui ca şi acestea să fie actualizate la fiecare operaţie de
actualizare a relaţiilor.
Analiza frecvenţei estimate de invocare a interogărilor şi a tranzacţiilor, împreună cu listele
de atribute care intervin în interogări şi tranzacţii, permit obţinerea unei situaţii globale
privind frecvenţa estimată de accesare a atributelor relaţiilor, în general, pentru volume mari de
prelucrări, se respectă regula "80-20". Această regulă stipulează că 80% din operaţiile de
prelucrare sunt executate în 20% din interogările şi tranzacţiile tuturor aplicaţiilor
implementate. De aceea, în cazurile practice nu sunt necesare statistici exhaustive ale
frecvenţelor de invocare a tuturor interogărilor şi a tranzacţiilor, ci este suficient să fie
determinate cele mai importante 20% dintre acestea.
Analiza constrângerilor de timp ale interogărilor trebuie să evidenţieze care dintre interogări
şi tranzacţii trebuie să se termine într-un anumit interval de timp. De exemplu, o tranzacţie
trebuie să se termine în mai puţin de 5 secunde în 95% din cazuri şi să nu depăşească niciodată
durata de 20 de secunde. Astfel de constrângeri pot fi folosite pentru a adăuga priorităţi
suplimentare atributelor candidate pentru indexare. Atributele de selecţie utilizate de interogări
şi tranzacţii cu constrângeri de timp devin candidate cu mare prioritate pentru indexare.
Tot în faza de proiectare fizică se poate rafina procesul de normalizare a relaţiilor, folosind
informaţiile de frecvenţă a invocării interogărilor şi tranzacţiilor şi constrângerile de timp
impuse unora dintre acestea, în general, pentru obţinerea unor timpi de răspuns mai mici
pentru unele interogări, se efectuează o denormalizare a unor relaţii, adică se combină două
sau mai multe relaţii existente într-o singură relaţie cu un grad de normalizare mai redus, în care
apar, bineînţeles, date redundante şi sunt posibile anomalii de actualizare. Odată cu
denormalizarea unor relaţii trebuie să se prevadă şi procedurile necesare (care depind de
SGBD) pentru verificarea datelor şi evitarea anomaliilor.
Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de:
Definirea datelor
Gestiunea cheilor primare Specificarea cheilor străine Tipuri de date disponibile
Extensibilitatea tipurilor de date Specificarea domeniilor Uşurinţa restructurării Mecanism de
tabele derivate Controlul integrităţii Dicţionar de date Independenţa datelor Tipul de model de
date utilizat
Accesibilitate
123
Suport pentru standardele SQL Interfaţă cu 3GL Mulţi utilizator Securitate:
controlul accesului
mecanism de autorizare
Utilitare
Măsurarea performanţei Acordare (run/ng)/optimizare Facilităţi de încărcare/descărcare Suport
pentru administrarea BD
Dezvoltare
Instrumente 4GL
Instrumente CASE
Facilităţi vizuale
Proceduri de stocare, declanşatoare
Instrumente de dezvoltare Web
Controlul tranzacţiilor
Rutine de salvare şi restaurare Puncte de salvare intermediare Suport pentru jurnalizare
Granularitatea accesului simultan Strategia de rezolvare a interblocajelor Procesare paralelă a
interogărilor
Definirea fizică
Structuri fizice disponibile
întreţinerea structurii de fişiere
Uşurinţa reorganizării
Indexare
Atribute/înregistrări de mărime variabilă
Compresia datelor
Rutine de criptare
Cerinţe de memorie
Alte facilităţi/opţiuni
Evolutivitate
Stabilitatea furnizorului
Baza de utilizatori
Pregătire şi suport pentru utilizatori
Documentare
Sistem de operare cerut
Cost
Help oniine
Standarde utilizate
Managementul versiunilor
Optimizare a interogărilor
Scalabilitate
Suport pentru instrumente OLAP
Interoperabilitate cu alte SGBD
Integrare Web
Utilitare de replicare
Facilităţi de distribuire
Portabilitate
Cerinţe hardware
Suport pentru reţea
Facilităţi de orientare pe obiect
Arhitecturi pe două, trei... straturi
Performanţă
Rata de tranzacţii pe secundă (minut)
124
Număr maxim de utilizatori simultani
Suport pentru XML
M5.U5.3. Rezumat
Pasul 8. Proiectarea fizică şi implementarea bazei de date relaţionale:
Translatarea modelului logic global în SGBD.
Pasul 8.1. Proiectarea relaţiilor de bază în SGBD.
Pasul 8.2. Crearea regulilor de integritate în SGBD.
Pasul 9. Proiectarea şi implementarea reprezentării fizice.
Pasul 9.1. Analizarea tranzacţiilor.
Pasul 9.2. Alegerea organizării fişierelor.
Pasul 9.3. Alegerea indecsilor secundari.
Pasul 9.4. Introducerea unei redundanţe comntrolate.
Pasul 9.5. Estimarea spaţiului pe disc.
Pasul 10. Proiectarea şi implementarea unui mecanism de securitate.
Pasul 10.1. Crearea view-urilor pentru utilizatori.
Pasul 10.2. Proiectarea regulilor de acces la baza de date.
Pasul 11. Verificarea sistemului operaţional.
Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de
calităţile SGBD-ului legatede Definirea datelor, Accesibilitate, Utilitare,
Dezvoltare, Definirea fizică şi Alte facilităţi/opţiuni

5.3.1 Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.
125
Unitatea de învăţare U5.4 Tranzacţii şi concurenţă
M5 U5.4 Introducere
O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă

(atomică) a datelor unei baze de date prin care se asigură consist enţa acesteia.
În principiu, orice execuţie a unui program care accesează o bază de date poate fi
considerată o tranzacţie, dacă baza de date este într -o stare consistentă atât înainte cât şi
după execuţie. O'tranzacţie trebuie să asigure consistenţa bazei de date indiferent dacă a
fost executată individual sau concurent cu alte tranzacţii precum şi în condiţiile în care au
apărut defecte ale sistemului hardware în cursul execuţiei tranzacţiei.

 construiască tranzacţii corecte
Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator sau un
program, care accesează sau schimbă conţinutul bazei de date.
Tranzacţia este o unitate logică de lucru a bazei de date. Nu există reguli de stabilire
automată a acestei unităţi. Pentru a demonstra acest concept o să dăm următoarele exemple.
Fie schemele:
Personal = (nrmat, nume, adresă, salariu)
Proprietate = (nrprop, stradă, oraş, tip, nrmat)
care leagă proprietatea de o persoană prin nrmat printr -o relaţie de cardinalitate n la 1,
Putem avea următoarele tranzacţii:
Exemple 5.4.1
cit (nrmat = x, salariu)
salariu = salariu * 1,1
scrie (nrmat = x, salariu)
care măreşte salariul cu 10%


126
Exemple 5.4.2
cit (nrmat =x )
şterge (nrmat = x )
pentru toate înregistrările din Proprietate
begin
cit ( nrprop, nrmat)
dacă (nrmat = x ) atunci
şterge (nrprop)
end
care şterge persoana x şi toate proprietăţile ei
O tranzacţie trebuie să transforme întotdeauna baza de date dintr-o stare consistentă

într-o altă stare tot consistentă.
O tranzacţie se poate termina în două moduri. Dacă tranzacţia s-a terminat cu succes,
atunci spunem că tranzacţia a făcut ‘commit’ şi baza de date a trecut în noua stare consistentă.
Dacă tranzacţia nu s-a terminat cu succes atunci, ea este întreruptă şi, în acest caz , baza de
date trebuie să fie readusă în starea consistentă în care era înainte să înceapă tranzacţia.
Spunem, în acest caz, că tranzacţia face ‘roll back’ este derulată înapoi. O tranzacţie care a
făcut ‘commit’ nu mai poate fi întreruptă, dar o tranzacţie întreruptă poate fi reluată mai târziu
şi atunci s-ar putea să se termine cu succes.
Un SGBD trebuie să aibă posibilitatea de a defini şi mânui tranzacţii.
Găsim astfel cuvintele cheie cu semnificaţie imediată BEGIN TRANSACTION, COMMIT,
ROLLBACK.
Proprietăţile tranzacţiilor.
Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să respecte
proprietăţile ACID.
 Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o unitate indivizibilă
care se execută în întregime sau deloc.
 Consistenţă o tranzacţie trebuie să transforme baza de date dintr-o formă consistentă
într-o altă formă tot consistentă.
 Independenţă o tranzacţie se execută inependent de oricare alta, adică efectele
parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie.
 Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în
baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior.
Dacă fiecare tranzacţie lucrează pe rînd, se pierde timp când calculatorul stă să aştepte
terminarea unei operaţii de intrare/ieşire, sau în timpul altei întreruperi. Pe de altă parte,
dacă lăsăm să lucreze deodată, fiecare în timpul lăsat liber de cel din nainte, zicem că
avem tranzacţii concurente. Concurenţa va mări randamentul timpului de lucru al
calculatorului dar ea trebuie controlată pentru că altfel poate da naştere la inconsistenţă.
Prezentăm în continuare, trei exemple în care arătăm cum se poate pierde cinsistenţa.
În primul exemplu tranzacţia T 1 citeşte contul lui x (bal x) şi scade 10 din cont.
Tranzacţia T2 citeşte contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100,
evident că dacă se executa mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost
100-10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să
considerăm următorul plan de tranzacţii.
127
Un plan de tranzacţii este o secvenţă posibilă în timp a modului de execuţie a
tranzacţiilor. Putem observa, în timpii înscrişi în stânga, cum evoluează contul din ultima
coloană.
Exemple 5.4.3
Time T1 T2 balx
A t1 begin_transaction 100
A t2 begin_transaction cit(bal x) 100
A t3 cit(bal x) bal x = balx + 10 100
A t4 bal x = balx - 10 scrie(bal x) 200
A t5 scrie(bal x) commit 90
A t6 commit 90

Problema se numeşte problema pierderii actualizării.

Problema dependenţei de o tranzacţie neterminată apare când o tranzacţie este
lăsatăsă ‘vadă’ rezultatele intermediare alei alte tranzacţii înainte ca ea să facă ‘commit’.
Aceleaşi tranzacţii ca în figura precedentă se desfăşoară acum după un alt plan.
Exemple 5.4.4
Time T3 T4 balx
A t2 cit(bal x) 100
A t3 bal x = balx + 10 100
A t4 begin_transaction scrie(bal x) 200
A t5 cit(bal x) 200
A t6 bal x = balx - 10 rollback 100
A t7 scrie(bal x) 190
A t8 commit 190
Rezultatul este 190, aţi putea spune că este bun, dar ţineţi cont că tranzacţia 4 a fost întreruptă
şi, când se va relua, va mai mări cu 100 contul ceea ce va deveni incorect.
Chiar şi când unele tranzacţii numai citesc baza de date se pot întâmpla neplăceri.
Această problemă este problema analizei inconsistente sau problema ‘citirii murdare’.
De exemplu tranzacţiile T5 şi T6 executate serial, adică una după alta, ar trebui să dea
rezultatele:
T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175
sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35
şi putem vedea în figura următoare ce se poate întâmpla încazul concurenţei libere,
necontrolate:
128
Exemple 4.4.5
Time T5 T6 balx baly balz sum
A t1 begin_transaction 100 50 25
A t2 begin_transaction sum = 0 100 50 25 0
A t3 cit(bal x) cit(bal x) 100 50 25 0
A t4 bal x = balx - sum = sum + 100 50 25 100
10 balx
A t5 scrie(bal x) cit(bal y) 90 50 25 100
A t6 cit(bal z) sum = sum + 90 50 25 150
baly
A t7 bal z = balz + 90 50 25 150
10
A t8 scrie(bal z) 90 50 35 150
A t9 commit cit(bal z) 90 50 35 150
A t10 sum = sum + 90 50 35 185
balz
A t11 commit 90 50 35 185
Nu putem, deci, lăsa concurenţa necontrolată, dar nici nu este profitabil să o

desfiinţăm de tot. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una
după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de tranzacţii este
neserial când tranzacţiile sînt concurente , adică între operaţiile unei tranzacţii se intercalează
operaţiile alteia. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat
acelaşi cu unul executat serial; acesta se va numi serializabil. Aveţi deja exemple de planuri
neserializabile.
129
M5.U5.4. Rezumat
 Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator
sau un program, care accesează sau schimbă conţinutul bazei de date.
Tranzacţiile trebuie să respecte proprietăţile ACID.
 Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o
unitate indivizibilă care se execută în întregime sau deloc.
 Consistenţă o tranzacţie trebuie să transforme baza de date dintr-
o formă consistentă într-o altă formă tot consistentă.
 Independenţă o tranzacţie se execută inependent de oricare alta,
adică efectele parţiale ale unei tranzacţii incomplete nu trebuie să
influenţeze o altă tranzacţie.
 Durabilitate efectele unei tranzacţii terminată cu succes sunt
definitiv înregistrate în baza de date şi nu se mai pot pierde în
tranzacţiile întrerupte ulterior.
Problemele concurenţei fără control sunt:
 problema pierderii actualizării.
 problema dependenţei de o tranzacţie neterminată
 problema analizei inconsistente sau problema ‘citirii murdare’.
Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una
după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de
tranzacţii este neserial când tranzacţiile sînt concurente , adică între operaţiile
unei tranzacţii se intercalează operaţiile alteia. Vom spune că un plan de tranzacţii
este corect atunci când el are ca rezultat acelaşi cu unul executat serial; acesta se
va numi serializabil.
M5.U5.4 Test de autoevaluare a cunoştinţelor

5.4.1 Daţi exemple de pierdere a consistenţei.
130
Unitatea de învăţare U5.5 Metode de control al concurenţei.
M5U5.5 Introducere
Am văzut că problemele apar atunci când o tranzacţie ‘vede’ (citeşte) sau scrie
într-un moment nepotrivit. Ideile de a controla concurenţa sînt legate de a nu lăsa
pe celălalt (de a bloca) sau de a ţine cont de momente (de a marca timpul).

 aleagă cea mai bună metodă de control al concurenţei
Ce înseamnă să blocăm ? Când o tranzacţie blochează partajat (part_bloc) o anumită

unitate de memorie, o altă tranzacţir nu mai poate să rescrie tot acolo, iar când o tranzacţie
blochează exclusiv (ex_bloc) o alta nu mai poate nici să o citească.
Despre ce unitate de memorie este vorba? Aceasta este problema granularităţii la
care se face blocajul. Blocajul se poate face la nivel de:
- întreaga bază de date
- tabela(fişier)
- înregistrare (cel mai des)
- câmp din înregistrare
Mai spunem că avem granularitate dinamică atunci când SGBD-ul poate să schimbe
granularitatea în timpul unei tranzacţii.
Cititorul poate să demonstreze singur pe un exemplu (vezi problema ) că numai
simpla blocare urmată cândva de deblocare (debloc) nu asigură serializabilitatea.
Serializabilitatea este asigurată dacă se respectă protocolul de blocare în două faze.
Acesta constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a
doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se
mai pot face blocări.
Următoarele trei exemple reiau tranzacţiile T1 şiT2 din exemplul 5.4.1respectiv T 3 şi
T4 din exemplul 5.4.2 şi T 5 şi T6 din exemplul 5.4.3 cu protocolul în două faze şi realizează
planuri serializabile.
131
Exemple 5.5.1
Time T1 T2 balx
A t2 begin_transaction ex_bloc(bal x) 100
A t3 ex_bloc(bal x) cit(bal x) 100
A t4 AŞTEAPTĂ bal x = balx +100 100
A t5 AŞTEAPTĂ scrie(bal x) 200
A t6 AŞTEAPTĂ debloc(bal x) 200
A t7 cit(bal x) commit 200
A t8 bal x = balx -10 200
A t10 deblo c(balx) 190
A t11 commit 190
Exemple 5.5.2
Time T3 T4 balx
A t2 ex_bloc(bal x) 100
A t3 cit(bal x) 100
A t4 begin_transaction balx = balx +100 100
A t5 ex_bloc(bal x) scrie(bal x) 200
A t6 AŞTEAPTĂ debloc(bal x) 100
A t7 AŞTEAPTĂ rollback 100
A t8 cit(bal x) 100
A t9 bal x = balx -10 100
A t11 debloc(bal x) 90
A t12 commit 90
132
Exemple 5.5.3
Time T5 T6 balx baly balz sum
A t1 begin_transaction 100 50 25
A t2 begin_transaction sum = 0 100 50 25 0
A t3 100 50 25 0
ex_bloc(balx)
A t4 cit(bal x) part_bloc(bal x) 100 50 25 0
A t5 bal x = balx - AŞTEAPTĂ 100 50 25 0
10
A t6 scrie( balx) AŞTEAPTĂ 90 50 25 0
A t7 AŞTEAPTĂ 90 50 25 0
ex_bloc(balz)
A t8 cit(bal z) AŞTEAPTĂ 90 50 25 0
A t9 bal z = balz + AŞTEAPTĂ 90 50 25 0
10
A t10 scrie(bal z) AŞTEAPTĂ 90 50 35 0
A t11 debloc(bal x AŞTEAPTĂ 90 50 35 0
, balz)
A t12 commit AŞTEAPTĂ 90 50 35 0
A t13 cit(bal x) 90 50 35 0
A t14 sum = sum + bal x 90 50 35 90
A t15 part_bloc(bal y) 90 50 35 90
A t16 cit(bal y) 90 50 35 90
A t17 sum = sum + bal y 90 50 35 140
A t18 part_bloc(bal z) 90 50 35 140
A t19 cit(bal z) 90 50 35 140
A t20 sum = sum + bal z 90 50 35 175
A t21 90 50 35 175
debloc(balx,baly,balz)
A t22 commit 90 50 35 175
Protocolul de blocare în două faze asigură serializanilitatea dar nu ne scuteşte de

probleme. Pezentăm în cele două exemple următoare rollback-ul în cascadă şi blocajul
ciclic.
Observaţi, în figura 9.7 la momentul t14 tranzacţia T 7 face rollback (dintr-un motiv
extern) şi, pentru că T 8 este dependentă de T7 care a citit o înregistrare care a fost
actualizată de T7, trebuie să facă şi T 8 rollback, ceea ce pe urmă se întâmplă şi cu T 9.
133
Exemple 5.5.4
Time T7 T8 T9
A t1 begin_transaction
A t2 ex_bloc(bal x)
A t3 cit(bal x)
A t4 part_bloc(bal y)
A t5 bal x = baly +
balx
A t6 scrie(bal x)
A t7 debloc(bal x) begin_transaction
A t8 … ex_bloc(bal x)
A t9 … cit(bal x)
A t10 … bal x = balx +100
A t11 … scrie(bal x)
A t12 … debloc(balx)
A t13 … …
A t14 rollback …
A t15 rollback begin_transaction
A t16
part_bloc(balx)
A t17 …
A t18 rollback
O altă problemă este blocarea ciclică prezentată în exemplul următor. Cele

două trnzacţii T 10 şi T 11 se blochează reciproc.
Exemple 5.5.5
Time T10 T11
A t2 ex_bloc(bal x) begin_transaction
A t3 cit(bal x) ex_bloc(bal y)
A t4 bal x = balx -10 cit(bal y)
A t5 scrie(bal x) bal y = bal y +100
A t6 ex_bloc(bal y) scrie(bal y)
A t7 AŞTEAPTĂ ex_bloc(bal x)
A t8 AŞTEAPTĂ AŞTEAPTĂ
A t10 … AŞTEAPTĂ
A t11 … …
Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de precedenţă care arată
dependenţa între tranzacţii în felul următor:
- se crează un nod pentru fiecare tranzacţie
- se crează o muchie direcţionată Ti  Tj dacă tranzacţia Ti aşteaptă să blocheze
o înregistrare care este deja blocată de Tj.
Pe acest graf se detectează un blocaj ciclic dacă există un circuit. Pentru figura 9.8 graful ar fi
următorul:
134
Exemple 5.5.6
y
T10 T11
x
O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este protocolul cu

marcarea timpului (time stamp). Acest protocol ataşează un timp (timpul real din calculator
sau un număr care se măreşte autmat de câte ori este solicitat) fiecărei tranzacţii (marc(T)) şi
timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Deci
fiecare tranzacţie va avea o valoare de marcj şi fiecare înregiistrare prelucrată va avea două
marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care
spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).
Numai în următoarele trei situaţii se pun probleme deosebite:
1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie
cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început
mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă
trebuie întreruptă.
2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie
care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea
să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o
foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.
3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie
care a început mai târziu, adică marc(T) < scri_marc(x). Este o încercare de a scrie o
valoare perimată şi în acest caz se ignoră această scriere.
În figura următoare se poate observa cum funcţionează acest protocol.
Exemple 5.5.7
Time Op T7 T8 T9
A t2 cit(balx) cit(bal x)
A t3 balx = balx bal x = balx
+10 +100
A t4 scrie(bal x) scrie(bal x) begin-
_transaction
A t5 cit(baly) cit(bal y)
A t6 baly = baly bal y = baly begin-
+20 +20 _transaction
A t7 cit(baly) cit(baly)
A t8 scrie(bal y) scrie(bal y)**
A t9 baly = baly bal y = baly
+30 +30
A t10 scrie(bal y) scrie(bal y)
A t11 balz=100 bal z=100
A t12 scrie(bal z) scrie(bal z)
A t13 balz=50 bal z=50 commit
A t14 scrie(bal z) scrie(bal z)* begin-
135
_transaction
A t15 cit(baly) commit cit(bal y)
A t16 baly = baly bal y = baly
+20 +20
A t17 scrie(bal y) scrie(baly)
A t18 commit
* la timpul t8 scrierea de către tranzacţia T 13 violează regula 2 şi de aceea este întreruptă

şi reluată la momentul t 14
** la timpul t14 scrierea de către tranzacţia T 12 poate fi ignorată conform celei de a treia
reguli
9.4 Tehnici optimiste.
Nu întotdeuna este necesar să pierdem timp în calculator controlând concurenţa.
Atunci când conflictele între tranzacţii sînt rare putem adopta aşa-numitele tehnici optimiste.
Asta înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure
serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’ să efectuăm un control care să
determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă
şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor
fi, şi ele, rare.
Distingem trei faze ale unui control optimist al concurenţei.
 Faza de citire. Această fază durează de la începutul tranzacţiei până înainte de
‘commit’. Tranzacţia citeşte valorile de care are nevoie din baza de date şi le stochează
in variabile locale. Actualizările nu sînt făcute direct în baza de date ci într-o copie
locală.
 Faza de validare. Urmează după faza de citire şi controlează dacă nu s–ar încălca
serializabilitatea în cazul că s-ar aplica actulizarea în baza de date. Dacă avem o
tranzacţie care numai citeşte baza (adică nu scrie), controlul constă în a verifica dacă
datele citite sînt încă datele curente în bază şi, dacă este aşa, atunci se face ‘commit’,
altfel se întrerupe şi se reia mai târziu. Dacă trnzacţia face şi rescrieri în bază, atunci se
verifică dacă se păstrează serializabilitatea şi dacă baza de date rămâne într-o stare
consistentă; dacă acest lucru nu se întâmplă, atunci se întrerupe.
 Faza de scriere. Este o fază care este necesară numai la tranzacţiile care fac rescrieri.
Dacă faza anterioară s-a terminat cu succes, atunci actualizările efectuate în copia
locală, sînt înregistrate definitiv în baza de date.
Iată cum se desfşoară acest tip de control:
Fiecărei tranzacţii îi este ataşat, la începutul primei faze, un marcaj start(T), la
începutul celei de a doua faze, valid(T) şi la sfârşit fin(T), după scriere în copia locală,
dacăeste cazul. Ca să treacă faza de validare trebuie să avem una din următoare le situaţii:
1) Toate tranzacţiile cu un marcaj mai mic, trebuie să se fi terminat înainte ca

tranzacţia T să fi început; adică fin(S) < start(T).
2) Dacă tranzacţia start(S) < start(T) (S a început înaintea lui T) şi nu s-a terminat
adică fin(S) < fin(T) atunci:
136
a. Datele scrise de tranzacţia anterioară S nu sînt cele citite de cea curentă
T şi
b. Tranzacţia anterioară S îşi completează faza de scriere înainte ca
tranzacţia curentă T să intre în faza de validare adică start(T) < fin(S) <
valid(T).
Deşi tehnicile optimiste sînt eficiente când conflictele sînt rare totuşi pot apărea multe
reluări (rollback); să reţinem că aceste reluări nu sînt în cascadă pentru că se lucrează pe o
coppie locală.
Ce ne facem dacă apar totiţi inconsistenţe? Trebuie s{ [putem recupera baza de date
într-o stare anterioară consistentă.
Controlul recuperării.
Din diferite motive se poate întâmpla ca baza de date să ajungă într-o stare incorectă
sau să se piardă de tot. Un SGBD trebuie să prevadă mecanisme de recuperare automată sau
manuală de recuperare a unei stări corecte a bazei de date şi posibilitatea de ajunge la zi cu
actualizările ulterioare.
O tranzacţie este formată din paşi mici care se execută pe rând şi când a început
acţiunea ‘commit’ ea nu s-a şi terminat. Datele sînt mai întâi duse într-un buffer (o memorie
internă intermediară) şi pe urmă scrise în bază (pe disc). Dacă între scrierea în buffer şi
scrierea pe disc apare vreo cădere, atunci SGBD-ul trebuie să reia scrierea (redo), iar dacă nu
s-au umplut bufferele şi a apărut o cădere atunci SGBD-ul trebuie să facă întreruperea şi
reluarea tranzacţiei (undo sau rollback).
Un SGBD trebuie să aibă un mecanism care să facă copii ale bazei de date şi jurnale
ale tranzacţiilor după care ele să poată fi refăcute. Copiile se fac autmat, fără intervenţii
manuale, şi recuperarea, în multe cazuri, trebuie să se facă tot automat.
M5.U5.5. Rezumat
 Avem două tipuri de tehnici pentru controlul concurenţei.
 Controlul pesimist se poate face cu blocaje prin protocolul în două faze sau cu
marcarea timpului.
 Protocolul de blocare în două faze impune ca, într-o tranzacţie, după ce s-a făcut o
deblocare sa nu se mai facă nici o deblocare. putem, în acest caz să avem blocare
ciclică sau ROLLBACK în cascadă.
 Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii
(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a
unei înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare
înregistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut
tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia
care a scris-o (scri_marc).
 O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem
întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă
‘commit’, să efectuăm un control care să determine dacă a avut loc un conflict. Dacă
a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că
137
aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.
M5 U5.5 Test de autoevaluare a cunoştinţelor

5.5.1 Ce este blocajul?
5.5.2 Ce este blocaju ciclic? Exemplu.
5.5.3 Ce este protocolul de blocare în două faze?
5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?
5.5.5 Ce este o tehnică optimistă de control al concurenţei?
138
Unitatea de învăţare U5.6. Securitate şi integritate
M5U5.6 Introducere

 introducă regulile de integritate
 să impună măsuri de securitate
Integritate
Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune
detectarea, corectarea şi prevenirea diferitelor erori care pot afecta datele introduse în bazel e
de date. Cand facem referiri la integritatea datelor, întelegem că datele sunt consistente relativ
la toate restrictiile formulate anterior (care se aplica datelor respective) şi ca urmare a acestui
fapt, datele sunt considerate valide.
Conditiile de integritate numite şi reguli sau restrictii de integritate nu permit
introducerea in baza de date a unor date aberante şi sunt exprimate prin conditii puse asupra
datelor.
În general sunt acceptate mai multe criterii de clasificare a regulilor de integritate .
O serie de conditii sunt de tip structural, legate de anumite egalitati intre valori, şi exprimate
prin dependente functionale sau prin declararea unor campuri cu valori unice (de cele mai
multe ori aceste campuri sunt chei).
O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si, in acest
caz, exista restrictii pe domenii (ce privesc anumite valori pentru atribute) sau restrictii pe
tabele (relatii). Restrictiile pe tabele pot fi unituplu (se refera la fiecare tuplu in parte) sau
multituplu (se refera la combinatii de mai multe tupluri).
O restrictie de integritate de relatie unituplu impune ca in fiecare tuplu al unei relatii
de baza, in campurile corespunzatoare cheii primare, sa apara valori diferite de valorile nule
corespunzatoare. Aceasta regula se mai poate enunta şi sub forma: "intr-o baza de date
relaţionala nu se inregistreaza nici o informatie despre ceva ce nu poate fi identificat."
Un exemplu de restrictie de integritate de relatie de tip multituplu este restrictia
referentiala care se exprima prin conditia ca, pentru cheile externe, daca nu sunt nule, sa se
admita valori corespunzatoare uneia din cheile primare existente in relatia referita. Verificarea
139
acestei conditii are loc de cate ori se insereaza un nou tuplu ce contine o cheie externa sau se
modifica valoarea unei chei externe a unui tuplu, semnalandu-se eventualele neconcordante şi
anuland modificarile. Verificarea unicitatii cheii primare şi restrictiile rezultate din
dependentele functionale şi multivaloare sunt alte exemple de acelasi tip.
Un alt criteriu de clasificare este acela prin care se deosebesc regulile de integritate ce
se refera la diferitele stari ale bazei de date de regulile ce se refera la tranzitia dintr-o stare in
alta.
Restrictiile pot fi clasificate şi din punct de vedere al momentului in care se aplica ele,
astfel avem reguli imediate (ce se verifica in momentul in care se efectueaza operatia indicata)
sau reguli amanate (ce se verifica numai dupa ce au fost executate şi alte operatii asociate dar
inainte de a se modifica baza de date).
În functie de aria de aplicare, restrictiile pot fi impartite in restrictii generale,
aplicabile tuturor relatiilor din baza de date şi restrictii particulare, care se pot aplica numai la
anumite relatii.
Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate efectiv datele bazei
de date. Dintre regulile generale cel mai des folosite in modelul relaţional sunt regulile ce
privesc cheile primare (vezi unicitatea valorilor cheilor primare in cadrul relatiei) şi cheile
externe.
Analizam in continuare cateva tipuri de restrictii de integritate.
I. Restrictii pentru integritatea entitatii
Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate avea valori nule.
Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa fie unice. In
majoritatea SGBD unicitatea cheii primare şi integritatea entitatii sunt conditii obligatorii.
II. Restrictii pentru integritatea referentiala
Enunt: Daca exista o cheie externa intr-o relatie, ori valoarea cheii externe trebuie sa se
potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de origine, ori valoarea
cheii externe trebuie sa fie nula.
Cu late cuvinte, daca o valoare exista intr-o relatie pe post de cheie externa, ori ea trebuie sa
se potriveasca cu valoarea unei chei primare dintr-o alta relatie ori sa fie nula.
Probleme serioase apar in momentul cand sunt de efectuat modificari sau stergeri de valori ale
cheilor primare.
Daca se actualizeaza o cheie primara sau se sterge intregul tuplu şi daca
1) valoarea cheii primare nu apare nicaieri ca şi cheie externa
atunci se permite efectuarea operatiei
2) valoarea cheii primare apare in alta parte ca şi cheie externa
atunci
a) nu se permite efectuarea operatiei
b) se permite efectuarea operatiei dar de asemenea se seteaza aparitiile cheii externe
la valorile nule sau o valoare implicita (daca s-a specificat vreuna)
c) se permite efectuarea operatiei dar de asemenea
140
(i) in cazul actualizarii – se propaga valoarea schimbata la aparitiile cheii
externe unde cheia externa este o parte a cheii primare a relatiei si, de
asemenea, se propaga schimbarile acolo unde aceasta din urma cheie
primara este cheie externa intr-o alta relatie
(ii) in cazul stergerilor – se propaga stergerea , adica se sterg tuplele care au
valori ale cheii externe care se potrivesc cu cheia primara
d) se intra in dialog cu utilizatorul
Toate acestea sunt reguli generale care, dupa caz, pot suferi mici transformari, in functie de
aplicaţia concreta.
Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaţiei sau se pot include in SGBD
utilizand mecanismul trigger-elor. Mai multe SGBD permit sa se creeze şi sa se memoreze
proceduri referitoare la baza de date şi aceste proceduri pot fi invocate cand au loc anumite
evenimente, cum ar fi actualizari şi stergeri ale unor atribute.
Standardul SQL furnizeaza controale pentru integritatea referentiala in declaratiile de creare a
tabelelor.
III. Restrictiile de domeniu
Aceste restrictii sunt intotdeauna restrictii de stare imediate. Aceste restrictii se pot referi la
tipul de date pentru un atribut, la o lista de valori posibile, la un ordin de marime, la un format
sau o forma, la o conditie exprimata cu o formula logica sau la o procedura care este apelata
de cate ori are loc o modificare pentru domeniul specificat.
Exemplu: Restrictiile de domeniu referitoare la o data calendaristica pot fi exprimate
(eventual) in felul urmator:
create domain ZI char(2)

check is_integer(ZI) and num(ZI) >= 1 and num(ZI) <= 31;
create domain LUNA char(2)
check is_integer(LUNA) and num(LUNA) >= 1 and num(LUNA) <= 12;
create domain AN char(2)
check is_integer(AN) and num(AN) >= 0 and num(AN) <= 99;
create domain DATA(ZZ domain(ZI), LL domain(LUNA), AA domain(AN))
check if num(LL) in (1,3,5,7,8,10,12) then num(ZZ) < 31;
check if num(LL) in (4,6,9,11) then num(ZZ) < 30;
check if num(LL) = 2 and mod(num(AA),4) = 0 and
mod(num(AA),100) <> 0 then num(ZZ) < 29;
check if num(LL) = 2 and mod(num(AA),4) <> 0
then num(ZZ) < 28;
Restrictiile de integritate pot fi exprimate prin intermediul limbajului de prelucrare a datelor
sub forma unei egalitati sau ca o relatie intre rezultatele a doua cereri.
Integritatea datelor este strans corelata cu securitatea datelor unei baze de date.
Daca se definesc controalele de securitate in absenta celor de integritate, validitatea şi
consistenta datelor se bazeaza exclusiv pe utilizarea corecta şi de buna credinta a sistemului
de catre utilizatorii autorizati. Daca insa se definesc numai controale de integritate, datele au
sansa sa fie consistente dar sunt susceptibile la pericolele care provin din lipsa securitatii.
141
Este important de mentionat aici ca restrictiile de integritate nu garanteaza corectitudinea
datelor. Aceasta deoarece este aproape imposibil (in multe situatii) ca verificarea
corectitudinii sa fie realizata automat.
Exemplu: Nu se poate verifica automat daca numele unei persoane este "Pop" sau "Popa",
cum nu se poate verifica automat daca data nasterii este "10.01.2001" sau "01.01.2001", et c.
Pentru a asigura un grad multumitor de integritate a datelor trebuie prevazute restrictii de
integritate in asociere cu principalele momente in care datele respective sunt manipulate, cum
ar fi: introducerea, actualizarea şi stergerea. Acestea sunt operatii susceptibile de introducerea
de date inconsistente in baza de date.
Restrictiile de integritate pot fi memorate in multe cazuri chiar in SGBD, dar gradul in care
acest lucru este posibil depinde de SGBD.
Asociata cu integritatea datelor este şi protectia datelor impotriva unor evenimente de avarie
cum ar fi caderea sistemului cauzata de defectarea unor componente hardware sau software.
Pierderea accidentala de consistenta a datelor poate rezulta din:
-incidente ce apar pe parcursul executarii tranzactiilor,
-anomalii datorate accesului concurent la baza de date,
-anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr-o retea,
-erori logice care apar din programele utilizator,
si altele.
Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente in
general, majoritatea bazelor de date se copiaza periodic pe medii magnetice ce se pastreaza in
locuri sigure. De asemenea se tine o evidenta a tuturor transformarilor efectuate in baza de
date de cand s-a efectuat ultima copie. Fisierul care contine aceste modificari se numeste
jurnal. Fiecare inregistrare din jurnal contine un identificator al programului care a facut
modificarea, fosta valoare şi noua valoare introdusa pentru un element. Tot in jurnal se mai
pastreaza diferitele momente importante din desfasurarea programelor (inceput, sfarsit,
terminarea unor operatii, etc.). Toate mecanismele mentionate in acest paragraf sunt
caracteristice lucrului cu tranzactii. La terminarea unei tranzactii, indiferent daca ea s-a
incheiat normal sau prin eroare, baza de date trebuie sa aiba acelasi grad de integritate ca la
momentul inceperii executiei tranzactiei respective.
Se spune despre o tranzactie ca este comisa daca au fost terminate toate calculele
produse de ea in aria de lucru şi s-a facut o copie a rezultatelor ei in jurnal. Aparitia unor
caderi dupa ce o tranzactie a fost comisa nu afecteaza continutul bazei de date deoarece se
poate reconstitui baza de date cu ajutorul ultimei copii şi a jurnalului in care se gasesc toate
rezultatele tranzactiilor comise. Modificarile tranzactiilor abandonate sau necomise nu sunt
luate in considerare la parcurgerea jurnalului pentru restaurarea bazei de date.
Se defineste strategia de comitere in doua faze astfel: o tranzactie poate sa scrie intr-o
baza de date numai dupa ce a fost comisa şi o tranzactie poate fi comisa numai dupa ce a
inregistrat in jurnal toate schimbarile de elemente produse de ea.
Securitate
Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva folosirii
neautorizate a lor şi in special a modificarilor şi distrugerilor nedorite de date şi a citirilor
142
nepermise de date. Pentru realizarea securitatii datelor din baza de date se utilizeaza controale
tehnice şi administrative.
Securitatea este in general asociata cu urmatoarele situatii:
-acces fraudulos la date,
-pierderea confidentialitatii (secretului) datelor,
-pierderea caracterului privat al datelor,
-pierderea integritatii datelor,
-pierderea disponibilitatii datelor
Este mai dificila protejarea datelor impotriva accesului rauvoitor, intentionat. Se
recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii şi masuri de securitate
mai eficiente sau mai putin eficiente.
Forme de acces intentionat şi rauvoitor la datele unei baze de date:
-citire neautorizata a unor date,
-modificari neutorizate de date,
-distrugeri de date.
Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor, pe
cand integritatea se refera la evitarea pierdelor accidentale de consistenta. Adevarul este insa
undeva la mijloc.
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe
nivele:
-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de accesul
persoanelor neautorizate;
-la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu multa grija şi
sa se tina evidente stricte ale persoanelor autorizate
-la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de operare
trebuie eliminate sau compensate de alte masuri
-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia datelor
Tehnici de asigurare a securitatii datelor:
1. Identificarea utilizatorilor.
Fiecarui utilizator in parte i se acorda anumite drepturi de operare pe diferite portiuni din baza
de date la diferite nivele cum ar fi relatia, inregistrarea, pagina, atributul, etc. Drepturile se
refera la posibilitatea citirii, inserarii, stergerii sau modificarii datelor respective. Identificarea
se face de obicei prin parole stabilite fie de administratorul bazei de date fie de utilizator.
2. Protejarea datelor prin codificare (criptare).
Deoarece s-ar putea ajunge la date şi prin alte mijloace decat prin intermediul SGBD-ului (de
exemplu prin citirea directa a mediului magnetic) se poate face o protectie prin pastrarea
codificata a datelor pe mediul magnetic. Decodificarea datelor se poate face numai dupa
identificarea utilizatorului prin garzi asociate lui.
3. Utilizarea view-urilor in aplicaţii.
143
Abilitatea view-urilor de a "ascunde" o parte din informatiile din baza de date poate fi
utilizata şi pentru stabilirea unui anumit grad de securitate a datelor. Astfel se poate vorbi de
acces la nivel de relatie (tabela) sau acces la nivel de view.
In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor. Astfel de view-uri
se numesc read-only (numai pentru citire) şi sunt utilizate mai ales in aplicaţiile in care datele
pot fi citite de toti utilizatorii (baze de date publice) dar modificarile se fac numai cu
aprobarea administratorului/proprietarului bazei de date.
Modificarile din view-uri nu sunt in general admise deoarece pot duce la efecte laterale ce
privesc parti din baza de date ce nu apar in view-uri. De exemplu stergerea unui element din
view poate sa duca la eliminarea unui alt element care are singura legatura cu elemntul sters şi
care nu se afla in view.
4. Administrarea şi transmiterea drepturilor.
Se tine evidenta stricta a drepturilor de acces ale fiecarui utilizator la portiuni din baza de
date şi se fixeaza reguli de transmitere de la un utilizator la altul a dreptului de acces.
Forme de autorizare:
-autorizare la citire (consultare)
-autorizare la inserare (adaugare)
-autorizare la actualizare (care exclude stergerile)
-autorizare la stergeri (la nivel de tuplu)
În situatiile de mai sus nu se pune problema modificarilor la nivel de schema a bazei
de date.
Daca consideram şi acest aspect putem vorbi de:
-autorizare la nivel de index (creare-stergere de indexi)
-autorizare la nivel de relatii (creare)
-autorizare de modificari la nivel de relatii (stergeri sau adaugari de atribute in cadrul
relatiilor)
-autorizari de stergeri ale relatiilor
Diferitele protectii pot fi indicate prin intermediul limbajului de prelucrare a datelor.
Portiunile din baza de date ce pot fi folosite de utilizator pot fi definite prin operatii de selectie
şi proiectie care fac invizibile alte portiuni ale bazei de date.
Conducerea organizatiei, care este proprietara bazei de date, trebuie sa ia masuri de
securitate care reduc riscul de a se pierde informatii sau de a se distruge informatii. Prin
pierdere de informatii se poate intelege ca se pierde caracterul privat al informatiilor, ele
devin accesibile unui grup mai mare de persoane decat cel prevazut. Nu intotdeauna
"scurgerile" de informatii lasa urme, deci nu se materializeaza intotdeauna in schimbari
detectabile la nivelul bazei de date.
Problema securitatii cuprinde aspecte legale, sociale şi etice, aspecte privind controlul
fizic (paza şi posibilitati de blocarea accesului la terminale), aspecte de politie (fixarea
conditiilor de acces), aspecte operationale (modul de stabilire a parolelor), aspecte privind
controlul hard (modul de acces hard la diferite componente), securitatea sistemului de operare
(protejarea informatiilor şi anularea rezultatelor intermediare pentru pastrarea secretului
144
datelor) aspecte privind notiunea de proprietate asupra datelor din baza de date şi altele
asemanatoare.
Trebuie sa mentionam aici ca furturile şi fraudele nu sunt neaparat legate de baza de
date, ele sunt un factor de risc pentru intreaga organizatie, gravitatea acestor fapte depinzand
şi de profilul organizatiei in cauza.
În Comunitatea Europeana exista o preocupare serioasa legata de actualizarea
legislatiei la noile nevoi generate de utilizarea intensiva a calculatoarelor. Se incearca in
principal sa se adopte legi care sa protejeze persoana sau organizatia şi sa tina seama de
nevoia ca anumite informatii sa aiba caracter privat, deci sa nu fie accesibile publicului larg
sau nici macar unui grup relativ restrans, daca acest fapt ar dauna proprietarului informatiilor
respective. Putem enumera aici o paleta larga de domenii care lucreaza cu informatii al caror
caracter privat trebuie neaparat pastrat: domeniul bancar, domeniul medical, evidente
administrativ-financiare, domeniul productiei in majoritatea firmelor de marca, etc.
M5.U5.6. Rezumat
Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune
detectarea, corectarea şi prevenirea diferitelor erori care pot afecta datele introduse
în bazele de date. Cand facem referiri la integritatea datelor, întelegem că datele sunt
consistente relativ la toate restrictiile formulate anterior (care se aplica datelor
respective) şi ca urmare a acestui fapt, datele sunt considerate valide.
Tipuri de restrictii de integritate.
Restrictii pentru integritatea entitatii.
Restrictii pentru integritatea referentiala
Restrictiile de domeniu
Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva
folosirii neautorizate a lor şi in special a modificarilor şi distrugerilor nedorite de
date şi a citirilor nepermise de date.
Securitatea este in general asociata cu urmatoarele situatii:
-pierderea confidentialitatii (secretului) datelor,
-pierderea integritatii datelor,
-pierderea disponibilitatii datelor
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai
multe nivele:
-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de
accesul persoanelor neautorizate;
-la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu
multa grija şi sa se tina evidente stricte ale persoanelor autorizate
-la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de
operare trebuie eliminate sau compensate de alte masuri
145
-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia
datelor
Tehnici de asigurare a securitatii datelor:
1. Identificarea utilizatorilor.
2. Protejarea datelor prin codificare (criptare).
3. Utilizarea view-urilor in aplicaţii.
4. Administrarea şi transmiterea drepturilor.

5.6.1 Care sunt restricţiile de integritate?
5.6.2 Ce înseamnă integritatea entitatii?
5.6.3 Ce înseamnă integritatea referentiala?
5.6.4 Ce înseamnă restrictiile de domeniu?
5.6.5 Care este deosebirea între integritate şi securitate?
5.6.6 Cum poate fi încălcată securitatea datelor într-o baza de date ?
5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.
5.6.8 Enumeraţi forme de autorizare.
146
Raspunsuri la testele de autoevaluare.
Unitatea 1.2
1.2.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?
Nume, adresa,adresa de e-mail,grad didactic,sex
1.2.2 Ce nu ar trebui memorat despre profesori într-o bază de date a facultăţii?
Pasiuni, înălţime, greutate, culoarea părului
1.2.3 Ce este arhitectura pe trei nivele?
Nivel
View 1 View 2 ….. View n
extern
Nivel Schema
conceptual conceptuala
Nivel Schema
intern interna
Organizarea la
nivel fizic a datelor Baza de
date
Arhitectura ANSI-SPARC pe trei nivele
Unitatea 1.3
1.3.1 Care sunt obiectivele unui SGBD?
Bazei de date îi revin o serie de obiective, cum sunt:
-Asigurarea independenţei datelor.
-Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.
147
- Asigurarea unor facilităţi sporite de utilizare a datelor
- Sporirea gradului de securitate a datelor împotriva accesului neautorizat la date.
-Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,
prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor
proceduri de refacere a bazei de date după incidente.
-Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie inţeleasă nu numai
sub aspectul asigurarii accesului mai multor utilizatori la aceleaşi date, ci şi acela al
posibiliăţtii dezvoltarii unor aplicaţii fără a se modifica structura bazei de date.
1.3.2 Care sunt funcţiunile unui SGBD?

1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul
limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic.
Aceasta funcţie asigură:
-descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,
-descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiasi
entităţi,
-definirea eventualelor criterii de validare a datelor,
-definirea metodelor de acces la date,
-definirea aspectelor referitoare la asigurarea integrităţii si confidenţi alităţii datelor, etc.
2. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează
urmatoarele activităţi:
- crearea (incarcarea) bazei de date;

- adaugarea de noi inregistrări;
- ştergerea unor inregistări;
- căutarea, sortarea şi editarea parţială sau totală a unei inregistrări virtuale etc.
3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor
utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de
informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date intr-o
formă simplistă. Ei apar ca utilizatori neinformaticieni;
- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are rolul hotarâtor în ceea
ce priveşte funcţionarea optimă a întregului ansamblu.
4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa
administratorului bazei de date.
148
Unitatea 1.4
1.4.1 Ce este o bază de date distribuită?
1) Un SGBDD constă dintr-o singură bază de date care este descompusă în
fragmente, eventual unele fragmente sunt multiplicate, şi fiecare fragment sau
copie se pastrează pe unul sau mai multe site-uri, sub controlul unui SGBD local.
Fiecare site este capabil sa proceseze interogări utilizator în regim local,
independent de restul reţelei, sau este capabil să participe la procesarea unor date
situate în alte site-uri din reţea. Pentru a spune că un SGBD este distribuit trebuie
să existe cle puţin o cerere globală.
1.4.2 Care sunt avantajele unui sistem distribuit?

2) Avantajele distribuirii bazelor de date sunt:
- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor
organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de
vedere geografic
- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală
- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se
semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să
continue să funcţioneze în condiţii satisfăcătoare
- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând
replici aflate pe alte site-uri
- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în
paralel a unor interog[ri
- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile
implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem
centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest
lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la
nevoile organiza’iei (dacă de exemplu este necesară adăugarea unor site-uri în plus) decât
un calculator central de putere asemănătoare
- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau
rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta
deloc) mersul activităţilor pe ansamblul sistemului distribuit.
1.4.3 Cum se poate face proiectarea alocării datelor?

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele
cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate
pe diferite site-uri în reţea
Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:
149
a!. centralizat
Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur
DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai
este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales
costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în
vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga
activitate în reţea pe această direcţie.
a2. fragmentat (partiţionat)
Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale
- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat
- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute
a3. replicat complet
Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:
- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime
- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de
actualizare
a4. replicat selectiv
Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de a
se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.
1.4.4 Cum se face o fragmentare corectă?

Reguli de bază care duc la o fragmentare corectă a bazei de date:
- completitudine – dacă relaţia R este descompusă în fragmentele R 1, R 2, …,R n, trebuie
luate măsuri care să prevină pierderea de informaţii
- reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit
cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.
- disjuncţie – dacă data d i apare în fragmentul R i atunci nu este permis să apară în nici un alt
fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie este
fragmentată pe verticală.
1.4.5 Ce este fragmentarea?

Tipurile de fragmentare sunt:
- pe orizontală
- pe verticală
- combinată
Fragmentarea pe orizontală:
150
Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:
Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor

relaţiei respective.
Un fragment orizontal se produce prin selecţie:
Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte
reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.
R= R 1R2…Rn
In general fragmentele unei relaţii R sunt disjuncte.
Fragmentarea pe verticală
Un fragment vertical dintr-o relaţie constă dintr-o relaţie care are ca atribute o submulţime a
atributelor relaţiei iniţiale.
Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci r1   S1 ( R) şi r2   S 2 ( R) .
Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din
submulţimile S1 şi S2.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.
r ( R )  r1 X N r2
Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care
asigură o descompunere fără pierderi la joncţiune.
In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se
admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare
(respectiv cheile externe).
Fragmentarea combinată (mixtă, hibridă, compusă)
Se poate face din fragmente verticale fragmentate orizontal:
Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai
sus) este:  P ( A1 ,..., An ( R))
Sau se poate face din fragmente orizontale fragmentate vertical
151
Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai
sus) este:  A1 ,..., An ( P ( R)) .
Unitatea 2.1
2.1.1 Care sunt modele de date bazate pe înregistrare?
Exista trei tipuri importante de modele de date bazate pe inregistrare: modelul de date
relaţional, modelul de date retea şi modelul ierarhic de date.
Unitatea 2.2
2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi cheia primară.
Student=(nrmatricol,cnp,nume,adresa,nrtelefon,sex,grupa,datanasterii)
chei candidat:
nrmatricol
cnp
nume,adresa
nrtelefon
cheia principală va fi nrmatricol pentru că:
cnp este mai lung
nume,adresa are două componente şi adresa se poate schimba
nrtelefon se poate schimba.
2.2.2 Daţi exemple de relaţii unu la unu, unu la mai mulţi şi mulţi la mulţi.
Relaţia editură carte este de unu la mai mulţi pentru că o editură editează mai mul te cărţi dar o
anumită carte este scoasă de o singură editură (vez ISBN care este unic),
Relaţia student materii este de mulţi la mulţi pentru că un student face mai multe materii şi o
materie ete făcută de mai mulţi studenţi.
2.2.3 Stabiliţi domeniul fiecărui atribut din tabela profesor.
profesor=(Nume, adresa,adresa de e-mail,grad didactic,sex)
nume Alfabetic
adresa compus
adresa de e-mail şir de caractere urmat de @ şi de alt şir de caractere
grad didactic La alegere din mulţimea(preparator,asistent,lectoe,conferenţiar,profesor)
sex una din două M sau F
Unitatea 3.1
Cosideraţi instanţe ale tabelei student, profesor,materii şi catalog.
1 Ion ion 7271
5 Dan soc 7271
7 Pan tor 7273
15 Prof1 Bv lunga 22
23 Prof2 Fag oltet 34
1 Baze de date
2 Algoritmica
152
3 Structuri de date
nrmatricol codmaterie nota

1 1 5
1 2 8
5 3 4
7 1 3
7 3 9
e) Faceţi selecţie din student după grupa 7271

1 Ion ion 7271
5 Dan soc 7271
f) Faceţi proiecţie la student şi la profesor după nume. La acestea două din urmă fac eţi
reuniunea.
Ion ion
Dan soc
Pan tor
Prof1
Prof2
g) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi materii.
nrmatricol numestd grupa codmaterie denmaterie nota

1 Ion ion 7271 1 Baze de date 5
1 Ion ion 7271 2 Algoritmica 8
5 Dan soc 7271 3 Structuri de 4
date
7 Pan tor 7273 1 Baze de date 3
7 Pan tor 7273 3 Structuri de 9
date
h) Faceţi selecţia tabelei de mai nainte după nota < 5.

nrmatricol numestd grupa codmaterie denmaterie nota
5 Dan soc 7271 3 Structuri de 4
date
7 Pan tor 7273 1 Baze de date 3
3.1.2 Să se exprime în algebra relaţională cererile:

e) Studenţii grupei 7271
 grupa=7271 (student)
f) Studenţii care sunt şi profesori
153
 nume (student)   nume (profesor)
g) Studenţii corigenţi
 ( nume j
(student N catalog
nota<5 j note))
N
h) Studenţii integralişti
 nume5 (student) \  (
nume nota<5 (student j catalog j note))
N N
Unitatea 3.2
Se dau următoarele relaţii cu schemele lor:

-Scări (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)
- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume
Să se exprime în SQL cererile:
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=3) and (scari.scara= locatar.scara)

select nume

select nume
3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34

select nume
union select nume
union select nume
154
3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp

select Nr_bloc,Scara,Apartament
from apartamente
where suprafaţa > 50
3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi pe scara 1 a

aceluiaşi bloc
select nume
and not in ( select nume
where (scari.bloc=34) and(scari.bloc locatari.bloc)
and (scari.scara=1) and (scari.scara= locatar.scara))
Unitatea 4.1
4.1.1 Dependenţele funcţionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota)) sunt:
nrmatricol nume
nrmatricol adresa
nrmatricol,codmaterie nota
codmaterie denumirematerie
4.2.1 Fie tabela din enunţ:

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000
2 C16 Chelt pt. Bucătării 500000
F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000
4 C11 Chelt pt. Func. liftului 200000
În această tabelă observăm că pentru furnizorul “Romgaz” avem două tipuri de

cheltuieli. Grupul de atribute (nr.crt., cod chelt., denumire cheltuială, valoare) apare de mai
multe ori. Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la
fiecare intersecţie linie coloană.
În cazul primei modalităţi, scriem repetiţiile pe diferite rânduri iar coloanele care nu
conţin repetiţii, vor fi copiate pe fiecare rând. După despărţirea repetiţiilor pe mai multe
rânduri, identificăm o nouă cheie.
F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000
F100 Romgaz R1234567 2 C16 Chelt pt. Bucătării 500000
F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000
F110 Renel R7654321 4 C11 Chelt pt. Func. liftului 200000
Tabela Furnizori_Cheltuieli în 1NF creată prin prima modaliate de transformare.
155
În tabela normalizată, noua cheie va fi (Cod Furn., Nr. Crt ., Cod Chelt.).
Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu
informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două
tabele vor fi următoarele:
Furnizori (Cod Furn., Denumire, Cod fiscal)
Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuială, Valoare)
Cele două tabele astfel create sunt în 1NF:
4.2.2 Fie R = (Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt.,
Cod, Valoare)
Vom avea dependentele functionale:
K = (Cod Furn., Cod Chelt., Nr. Crt.)  R deci K este cheie.
d1 Cod Chelt  Denumire cheltuială
d2 Cod Furn  (Denumire, Cod fiscal)
Dependenţele d1 şi d2 sunt dependenţe parţiale de cheie.
Relaţiile rezultate au următoarea formă:
Furnizori = (Cod Furn., Denumire, Cod fiscal)
Tip cheltuială = (Cod Chelt., Denumire cheltuială)
Cheltuieli = (Nr. Crt., Cod Furn., Cod Chelt., Valoare)
Fie relaţia din enunţ:
carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. În afara dependenţelor
care definesc cheia mai avem dependenţa:
cod_domeniu  den_domeniu şi pentru că c_carte este cheie avem şi

c_carte  cod_domeniu deci den_domeniu depinde tranzitiv de cheie.
Prin descompunere rezultă două scheme 3NF:
carte1 = (c_carte, titlu, cod_domeniu) şi
domeniu = (cod_domeniu, den_domeniu).
Fie relaţia:
Are grup repetitiv deci nu este FN1.
se descompune în:
stud1=( nrmatricol,nume,adresa) care este FN3 şi
stud2=( nrmatricol,codmaterie,denumirematerie,nota) unde avem dependenţele funcţionale:
nrmatricol,codmaterie nota
codmaterie denumirematerie aceasta fiind dependenţă parţială de cheie deci nu este FN2
se obţine forma finaţă:
stud1=( nrmatricol,nume,adresa)
catalog=( nrmatricol,codmaterie,nota)
materii=( codmaterie,denumirematerie)
Unitatea 5.1
5.1.1 Faceţi proiectul conceptual local pentru subsistemul didactic al facultăţii.
Pasul 1.1. Identificarea tipurilor de entităţi.
tipurile de entităţi sunt:
student, materii, profesori, orar, sali
156
Identificarea tipurilor de relaţii.
În continuare identificăm tipurile de relaţii. Tipurile de relaţii se reprezintă prin verbe
ale relaţiilor.
În continuare vom determina cardinalul şi participarea relaţiilor prezentate în tabelele
de mai sus. Cardinalul poate să fie unul dentre următoarele: unu-la-unu (1:1), unu-la-multe
(1:M), sau multe-la-multe (M:N). Participarea poate să fie parţială sau totală.
Tip de entitate Tip de relaţie Tip de entitate cardinalitate participare

student face Materii N:M P:T
profesor preda Materii N:1 T:T
orar Relaţie Zile, Sali, ore,
complexă cu materii
Atributele tipurilor de entităţi
Tip de entitate Atribute domeniu

student nrmatricol Numeric de 5
nume text
adresa text
sex M sau F
grupa Numeric de 4
…
materii Codmaterie Numeric de 3
Denmaterie Text
… ….
Pasul 1.7. Desenarea modelului ER.
157
student materii profesori
N M N 1
orar
sali zile ore
Unitatea 5.2
5.2.1 Faceţi proiectul logic local pentru subsistemul didactic al facultăţii.
Pasul 2.1. Proiectarea modelului local conceptual în modelul local logic.
În acest pas eliminăm acele structuri din baza de date, care sunt dificil de implementat
în sistemul de gestiune al bazelor de date. Pentru a rezolva această problemă, se vor urma
următorii paşi:
(1) Eliminarea relaţiilor de tipul N:M.
Este cazul relaţiei dintre student şi materii. Apare entitatea catalog.
student catalog materii

N 1 1 N
(2) Eliminarea relaţiilor complexe.

Avem relaţia cu orarul. Se modifică în felul următor:
158
zile ore
1 1
Sali
N zileore N 1
1
materii
N zioresali N 1
1
N orar N
(3) Eliminarea relaţiilor recursive. Nu avem.

(4) Eliminarea relaţiilor cu atribute. Nu avem.
(5) Reexaminarea relaţiilor de tipul 1:1. Nu avem
Desenarea diagramei ER.
Modelul conceptual care este reprezentat anterior s-a modificat în acest pas. Am
eliminat din acest model, toate structurile greu de implementat într-un sistem de gestiune a
bazelor de date. Diagrama modificată se va numi în continuare modelul local logic al bazei de
date.
student materii profesori
N M N 1
zile ore
1 1
Sali
N zileore N 1
1
N zioresali N
1
N orar N
159
Pasul 2.2. Crearea de relaţii peste modelul logic local.
În acest pas vom crea relaţiile între entităţile din modelul logic local de date, cu
ajutorul mecanismului chei primare/chei străine. de exemplu:
Student=(nrmatricol,nume,adresa,sex,grupa)
Cheie primară nrmatricol
Catalog=(nrmatricol,codmaterie,nota)
Cheie primară nrmatricol,codmaterie
Cheie străină nrmatricol referă nrmatricol din student
Cheie străină codmaterie referă codmaterie din materii
materii=(codmaterie,denmaterie)
Cheie primară codmaterie
…
Pasul 2.3. Validarea modelului prin normalizare.
În acest pas validăm baza de date prin normalizare. Procesul de normalizare este
descris amănunţit în capitolul 4.
 Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.
 Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia primară.
 Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de cheia primară.
 Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rămas.
Trebuie să analizăm fiecare relaţie care este descrisă în anexa 6.3.5. Verificăm dacă
relaţiile sunt în forma normală Boyce-Codd, iar dacă găsim una care nu satisface această
formă normală, ne întoarcem la paşii precedenţi şi rezolvăm problema.
În cazul nostru toate tabelele sunt în FN3
Pasul 2.2. Validarea modelului prin tranzacţiile cerute.
Tranzacţiile vor fi:
T1 Tabel nominal cu studenţii grupei…
T2 Catalogul grupei.. la materia…
…
Pentru fiecare tranzacţie vom da fraza SQL:
T1 SELECT nume
FROM student
WHERE grupa=…
T2 SELECT student.nume,denmaterie,nota
FROM student,catalog,materii
WHERE grupa=… AND denmaaterie=…
AND student.nrmatricol=catalog.nrmatricol
AND catalog.codmaterie)materii.codmaterie
…
Unitatea 5.3
Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.
Se vor urmări paşii din Access la purtător [8]
160
Unitatea 5.4
5.4.1 Daţi exemple de pierdere a consistenţei.
1) Tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont. Tranzacţia T 2 citeşte
contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se
execută mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-
10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să
considerăm următorul plan de tranzacţii.
Time T1 T2 balx
A t2 begin_transaction cit(bal x) 100
A t3 cit(b alx) bal x = balx + 10 100
A t4 bal x = balx - 10 scrie(bal x) 200
A t5 scrie(bal x) commit 90
A t6 commit 90
Se ved că bal x are valoarea greşită 90.
Unitatea 5.5
5.5.1 Ce este blocajul?
1) Când o tranzacţie blochează partajat o anumită unitate de memorie, o altă tranzacţie nu
mai poate să rescrie tot acolo, iar când o tranzacţie blochează exclusiv o alta nu mai
poate nici să o citească.
5.5.2 Ce este blocaju ciclic? Exemplu.
1) Blocarea ciclică este prezentată în exemplul următor. Cele două trnzacţii T 10 şi T11 se
blochează reciproc.
Time T10 T11
A t2 ex_bloc(bal x) begin_transaction
A t3 cit(bal x) ex_bloc(bal y)
A t4 bal x = balx -10 cit(bal y)
A t5 scrie(bal x) bal y = bal y +100
A t6 ex_bloc(bal y) scrie(bal y)
A t7 AŞTEAPTĂ ex_bloc(bal x)
A t10 … AŞTEAPTĂ
A t11 … …
5.5.3 Ce este protocolul de blocare în două faze?

1) Protocolul de blocare în două faze constă din împărţirea tranzacţiei în două faze una
de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă
că după ce s-a făcut prima deblocare nu se mai pot face blocări.
5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?

Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii
(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei
161
înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare
prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o
(cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).
Numai în următoarele trei situaţii se pun probleme deosebite:
1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o
tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie
care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă
deci trnzacţia respectivă trebuie întreruptă.
2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o
tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă
că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută
mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.
3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o
tranzacţie care a început mai târziu, adică marc(T) < scri_marc(x). Este o
încercare de a scrie o valoare perimată şi în acest caz se ignoră această scriere.
5.5.5 Ce este o tehnică optimistă de control al concurenţei?

O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri
care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’, să
efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc
un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste
conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.
Unitatea 5.6
5.6.1 Care sunt restricţiile de integritate?
integritatea entitatii
- integritatea referentiala
- restrictiile de domeniu
- restricţiile de intreprindere
5.6.2 Ce înseamnă integritatea entitatii?
1) Intr-o relaţie de baza nici un atribut al unei chei primare nu poate avea valori nule.
5.6.3 Ce înseamnă integritatea referentiala?
Daca exista o cheie externa intr-o relaţie, ori valoarea cheii externe trebuie să se potriveasca
cu valoarea unei chei candidat a vreunui tuplu în relaţia de origine, ori valoarea cheii externe
trebuie să fie nulă.
5.6.4 Ce înseamnă restrictiile de domeniu?
Aceste restricţii se pot referi la tipul de date pentru un atribut, la o listă de valori
posibile, la un ordin de mărime, la un format sau o formă, la o condiţie exprimată cu o
formulă logică sau la o procedură care este apelată de cate ori are loc o modificare
pentru domeniul specificat.
5.6.5 Care este deosebirea între integritate şi securitate?
Noţiunea de securitate a bazei de date este de obicei asociată cu accesul răuvoitor, pe cand
integritatea se refera la evitarea pierdelor accidentale de consist enţă
162
5.6.6 Cum poate fi încălcată securitatea datelor într-o baza de date ?
Securitatea este in general asociată cu urmatoarele situaţii:
-pierderea confidenţialitatii (secretului) datelor,
-pierderea disponibiliţatii datelor.
5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.
Pentru protectia bazei de date se pot lua masuri de asigurare a securităţii la mai multe nivele:
-la nivel fizic - locurile în care se afla calculatoarele trebuie protejate de accesul
persoanelor neautorizate;
-la nivel uman – este recomandabil sa se acorde autorizaţiile de acces cu multa grijă şi
să se ţină evidenţe stricte ale persoanelor autorizate
-la nivel sistem de operare – slăbiciunile protecţiei la nivel de sistem de operare
trebuie eliminate sau compensate de alte măsuri
-la nivel SGBD – sistemul ofera anumite facilităţi care sprijina protecţia datelor.
5.6.8 Enumeraţi forme de autorizare.
Forme de autorizare:
-autorizare la citire (consultare)
-autorizare la inserare (adăugare)
-autorizare la actualizare (care exclude ştergerile)
-autorizare la ştergeri (la nivel de tuplu)
In situaţiile de mai sus nu se pune problema modificarilor la nivel de schemă a bazei de date.
Dacă considerăm şi acest aspect putem vorbi de:
-autorizare la nivel de index (creare-ştergere de indecşi)
-autorizare la nivel de relaţii (creare)
-autorizare de modificări la nivel de relaţii (ştergeri sau adăugari de atribute în cadrul
relaţiilor)
-autorizări de ştergeri ale relaţiilor.
163
Bibliografie.
[1] L.Ţâmbulea - Structuri de date şi bănci de date, Universitatea Babeş -Bolyai, Cluj, 1992
[2] H.F.Korth, A.Silberschatz - Database System Concepts, McGraw Hill, New York, 1987
[3] T.Connoly,C.Begg,A.Strachan – Database Systems, Assison-Wesley, 1997
[4] O.Bâscă – Baze de date,All,1997
[5] Lungu I. Bodea C. Badescu G. Ionita C. Baze de date Ed.ALL 1995
[6] Iacob P.Baze de date pentru începători. Ed. Universităţii din Piteşti. 2000
[8]iacob P. Access la purtător Ed.Lux libris 2007
[9]iacob P. Oracle la purtător Ed.Lux libris 2008
[10] M. Stanescu şi colectiv - Limbaje de programare şi bănci de date, ASE, Bucuresti, 1992
[11] R Steiner - Theorie und Praxis relationaler Datenbanken, Vieweg Verlag, 1994
[12] J.L.Harrington,Relational database design,AP PROFESSIONAL,1998.
164

Baze de Date - Iacob

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze de Date - Iacob

Uploaded by

Copyright:

Available Formats

Paul IACOB

Aplicaţii tradiţionale bazate pe fişiere; limitări

Durata medie de studiu individual

M1. Obiectivele modulului

M1.U1.2. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Organizarea datelor în fişiere SGBDR Teoria relaţională

În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale

Abordarea tradiţională bazată pe fişiere are o serie de limitări cum ar fi

Ideea principală în organizarea datelor se baza pe existenţa a trei componente

Organizarea datelor în SGBDR Teoria relaţională

Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte

Criterii minimale de definire a unui SGBDR

Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. şi 3.

Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care

Clasificarea SGBD se poate realiza din mai multe puncte de vedere.

În esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată

Conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date

Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de

Organizarea datelor în SGBDR Teoria relaţională

M1.U1.2. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare este de 2 or e.

Ce credeţi că ar interesa să memorăm despre studenţi într-o bază de date a

Componentele bazei de date pot fi structurate pe trei nivele, în funcţie

Scheme, corespondenţe şi instanţe

SGBD realizează corespondenţa între cele trei nivele de abstractizare, realizând

Descrierea generala a unei baze de date se numeşte schema bazei de date.

Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de

Independenţa logică a datelor se referă la posibilitatea adăugării de noi

Descrierea generală a unei baze de date se numeşte schema bazei de

M1.U1.2. Test de autoevaluare a cunoştinţelor

M1.U1.3. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare es te de 2 ore.

Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde

Arhitectura unui SGBD cuprinde următoarele componente:

Obiectivele unui SGBD

Obiectivele unui SGBD sunt:

Funcţiunile unui SGBD sunt:

Arhitectura unui SGBD cuprinde următoarele componente:

M1.U1.4. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare este de 2 o re.

Proiectarea unei baze de date relaţionale distribuite

Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor

Un fragment vertical se produce prin proiecţie:

2. fragmente orizontale fragmentate vertical

M1.U1.4. Test de autoevaluare a cunoştinţelor

M3. Obiectivele modulului

M2.U2.1. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.

Modele fizice de date

Se considera că schema conceptuala sta la baza structurării unei baze de date. O

Modelare E-R (Entity-Relaţionship)

Putem vorbi de:

M2.U2.2. Obiectivele unităţii de învăţare

Durata medie de parcurgere a primei unităţi de învăţare est e de 3 ore.

Mulţimea tuturor profesorilor Facultăţii de Ştiinţe formează ce?

Arătaţi că nici tipurile de entitate personal auxiliar şi profesor nu sunt

Un tip de entitate se identifică printr-un nume şi o listă de proprietatea. O bază de date

Cum aţi descrie entitatea materii?

Reprezentaţi o entitate a tipului de entitate materii.

Arătaţi alte atribute simple ale tipului de entitate materii.

Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile

Desenaţi structura corespunzătoare tipului de entitate student.