Baze de Date

Proictarea Bazelor de Date
Curs
Specializarea Ingineria Informaiei - anul IV-A
Facultatea de Electronica, Telecomunicatii si

Tehnologia Informatiei
Prof. Felicia Ionescu

http://info.tech.pub.ro/~fionescu/
Bibliografie
Felicia Ionescu, Baze de date relationale si aplicatii, Editura Tehnica,
Bucureti, 2004
C. J. Date, An Introduction to Database Systems, 8th Edition, 2004
R. Elmasri and S. B. Navathe, Fundamentals of Database Systems,
Fourth Edition, 2004
J. Ullman, J. Windom, A First Course In Database Systems, Prentice
Hall, 1997
Kevin Kline, Daniel Kline, SQL In A Nutshell, OReilly, 2001
Oracle 11g Documentation http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html
MySQL Documentation - http://dev.mysql.com/doc/

PostgreSQL Documentation - http://www.postgresql.org/docs/manuals/
Microsoft SQL Server Books Online MSDN - Academic Alliance
Cap.1 - Introducere in Baze de date
Capitolul 1: Introducere
Definiii baze de date, sisteme de baze de date
Componentele sistemelor de baze de date
Arhitectura interna a sistemelor de baze de date
Avantajele oferite de sistemele de baze de date
Clasificari ale sistemelor de baze de date
Clasificare dupa modelul de date
Clasificare dupa numarul de utilizatori
Clasificare dupa numarul de statii pe care este memorata baza de date
Modelarea datelor
Modele conceptuale de nivel inalt
Modele specifice de date
Evolutia sistemelor de baze de date
Sisteme de baze de date

Bazele de date se folosesc in aproape toate domeniile de activitate actuale:
Activitati bancare si comerciale (depozite bancare, vanzari produse)
Productie (gestiunea stocurilor, gestiunea financiar-contabila, salarizare etc.)
Evidenta populatiei, taxe si impozite
Servicii (servicii medicale, rezervari bilete de calatorie etc.)
Definitie (in sens larg): O baza de date (database) este o colecie de date
corelate din punct de vedere logic, care reflecta un anumit aspect al lumii
reale i este destinata unui anumit grup de utilizatori. In acest sens pot fi
considerate ca fiind baze de date:
Fise de evidenta (mentinute manual)
Fisiere de documente sau foi de calcul tabelar (Microsoft Word, Microsoft Excel)
Baze de date mentinute computerizat
Definitie (in sens restrans): O baz de date este o colecie de date creat i
meninut computerizat, care permite operaii de:
Introducere (insert)
Stergere (delete)
Actualizare (update)
Interogare (query)
Componentele unui Sistem de Baze de Date (1)

Un sistem de baze de date (Database System) este un sistem
computerizat de meninere a evidenei unei anumite activiti, folosind baze
de date
Componentele unui sistem de baze de date sunt: hardware, software,
utilizatori si date persistente
Hardware:
Sistemele de baze de date sunt instalate pe calculatoare de uz general
Bazele de date sunt memorate fizic ca fisiere pe discuri magnetice (hard-discuri)
Software:
Sisteme de operare, biblioteci, instrumente de dezvoltare, interfete
Sistemul de Gestiune a Bazelor de Date (SGBD) (Database Management
System DBMS) - recepioneaz cererile utilizatorilor de acces la baza de date,
le interpreteaz, execut operaiile corespunztoare i returneaz rezultatul
Aplicatii de baze de date: (Database Applications) sunt programe care ofer
anumite utilizari ale unei baze de date
Componentele unui Sistem de Baze de Date (2)

Baza de date
Utilizator
final
Date
Program
aplicaie
Date
SGBD
Date
Date
Utilizatori:
Programatori de aplicatii
Utilizatori finali
Administratorul bazei de date
Analisti si proiectanti ai bazelor de date
Datele persistente sunt memorate in fisiere pe hard-disk

Limbaje conceptuale pentru lucrul cu bazele de date:
Limbaje pentru Definirea Datelor(LDD) (Data Definition Languages DDL)
Limbaje pentru Manipularea Datelor (LMD) (Data Manipulation Languages
DML)
Arhitectura interna a unui Sistem de BD

Arhitectura pe 3 niveluri relativ independente: nivelul intern, nivelul
conceptual i nivelul extern (Standard ANSI/X3/SPARC -1975)
Schema descrierea datelor pe un anumit nivel: schema interna,
conceptuala si scheme externe (vedere utilizator)
Corespondente intre niveluri (mappings)
Nivelul extern
Nivelul conceptual
Vedere
utilizator #1
Vedere
utilizator #2
Vedere
utilizator #n
Schema conceptual
SGBD
Nivelul intern
Schema intern
Date
memorate
Avantaje oferite de Sistemele de BD

Compactitate ridicat a datelor
Reprezentarea unor asocieri complexe intre date
Timp de dezvoltare a bazelor de date redus
Viteza mare de actualizare si regasire a datelor
Redundanta controlata a datelor (si cat mai scazuta)
Flexibilitate, mentinerea datelor actualizate la zi
Independenta datelor fata de suportul hardware utilizat
Securitatea datelor: autentificarea utilizatorilor si autorizarea accesului
Impunerea de restrictii (constrangeri) de integritate la introducerea si
actualizarea datelor
Mentinerea integritatii datelor in caz de defecte: salvare si refacere
Posibilitatea de partajare a datelor intre mai multe categorii de utilizatori
Posibilitatea de introducere a standardelor
Clasificarea Sistemelor de Baze de Date (1)

Clasificare dupa modelul de date:
Modelul ierarhic de date
Modelul de date retea
Modelul relational
Modelul obiect-orientat
Modelul obiect-relational
Clasificare dupa numarul de utilizatori

Sisteme mono-utilizator
Sisteme multi-utilizator
Clasificare dupa numarul de statii pe care este memorata baza de date:

Baze de date centralizate
Baze de date distribuite
Arhitectura client-server:
Server (back-end): SGBD-ul si baza de date
Client (front-end): program (programe) de aplicatie
Clasificarea Sistemelor de Baze de Date (2)

Aplicaie
Client
Aplicaie
Client
Aplicaie
Client
Aplicaie
Client
Reea
de comunicaie
Server
Server
SGBD
SGBD
BD
BD
Sisteme de baze de date centralizate: a- mono-utilizator; b- multi-utilizator

Aplicaie
Client
Aplicaie
Client
Aplicaie
Client
Reea
de comunicaie
Server
Server
SGBD
SGBD
BD
BD
Sistem de baze de date distribuit

10
Modelarea datelor
Un model este o abstractizare a unui sistem:
capteaz cele mai importante trsturi caracteristice ale sistemului (concepte)
conceptele trebuie sa fie relevante din punct de vedere al scopului pentru care
se definete modelul respectiv
Tehnica de identificare a trsturilor caracteristice eseniale ale unui sistem

se numete abstractizare
Un model de date stabilete regulile de organizare i interpretare a unei
colecii de date.
n proiectarea bazelor de date se folosesc 2 categorii de modele:
Modele conceptuale de nivel nalt (modelul Entitate-Asociere, modelul
Entitate-Asociere Extins) descriu concis colectiile de date care modeleaz
activitatea dorit fr s detalieze modul de reprezentare sau de prelucrare a
datelor - schem conceptual de nivel nalt
Modele specifice (modelul ierarhic, modelul reea, modelul relaional, etc.) descriu reprezentarea mulimilor de entiti i a asocierilor dintre acestea prin
structuri de date specifice implement[rii - schem conceptual (logic)
Trecerea de la modelul conceptual de nivel nalt la un model de date

specific proiectare logic a bazei de date.
11
Modelul Entitate-Asociere
Modelul Entitate-Asociere (Entity-Relationship Model) defineste multimile
de entiti i asocierile dintre ele, dar nu impune nici un mod specific de
structurare i prelucrare (gestiune) a datelor; Introdus n 1976 de P.S. Chen
O entitate (entity) este orice exista in realitatea obiectiva si poate fi
identificat n mod distinctiv
Exemple: o persoana, o planta, o activitate, un concept etc.
Un atribut (attribute) este o proprietate care descrie un anumit aspect al

unei entiti
Exemple: persoanele au nume, prenume, adresa etc.
Tip de entitate (entity type): se refera la entittile similare, care pot fi

descrise prin aceleasi atribute
Exemple: tipul persoana, tipul planta
Multime de entitati (entities set): colecia tuturor entitilor de acelai tip

dintr-o baz de date constituie o mulime de entiti
Exemple: multimea tuturor persoanelor, multimea tuturor plantelor
O entitate este o instanta a unui tip de entitate si un element al multimii de

entitati de acel tip
In exprimarea curenta, adeseori nu se face diferentierea dintre entitate, tip
de entitate si multime de entitati, dar diferenta este evidenta
Asemanare cu modelul obiect: tip de entitate - clasa; entitate - obiect
12
Asocieri
O asociere (relationship) este o legtur (coresponden) ntre entiti din
dou sau mai multe mulimi de entiti; asocierile pot avea atribute
Tipul asocierii (relationship type) se refera la asocierile similare, care pot
fi definite intre entitati din 2 sau mai multe multimi de entitati
Multime de asocieri (relationship set): multimea asocierilor de acelasi tip
O asociere este o instanta a unui tip de asociere si un element al multimii
de asocieri de acel tip
In exprimarea curenta, adeseori nu se face diferentierea dintre asociere, tip
de asociere si multime de asocieri, dar diferenta este evidenta
Gradul unui (tip de) asociere (degree): numrul de (mulimi de) entiti
asociate; dupa grad, asocierile pot fi:
binare (de gradul 2, ntre 2 mulimi de entiti) majoritatea asocierilor
multiple (ntre k mulimi de entiti, k > 2)
Categorii (tipuri) de asocieri binare - dup numrul elementelor din fiecare

dintre cele dou mulimi puse n coresponden:
unul-la-unul (one-to-one) 1:1; exemplu: sot-sotie

unul-la-multe (one-to-many) 1:N; exemplu: parinte-fii
multe-la-unul (many-to-one) N:1; exemplu: fii-parinte
multe-la-multe (many-to-many) M:N; exemplu: profesori-studenti
13
Categorii de asocieri binare (1)
unul-la-unul 1:1
unul-la-multe- 1:N
Asocieri binare intre multimile de entitati A si B

14
Categorii de asocieri binare (2)
multe-la-unul- N:1
multe-la-multe- M:N
Asocieri binare intre multimile de entitati A si B

15
Cardinalitatea asocierilor
Cardinalitatea (multiplicitatea) unei asocieri fa de o mulime de entiti
(cardinality, multiplicity) este numrul maxim de elemente din acea mulime
care pot fi asociate cu un element din alt mulime a asocierii
Exemplu: asocierea unul-la-multe dintre mulimile A i B prezint multiplicitatea
1 fa de mulimea A i multiplicitatea N (se nelege o valoare oarecare N > 1)
fa de mulimea B
Raport de cardinalitate (cardinality ratio): raportul dintre valorile

cardinalitilor unei asocieri fa de dou din mulimile de entiti asociate
Exemple pentru asocieri binare: 1:1, 1:N, N:1, M:N
Asocierile multiple (k-are, k > 2) prezint cte un raport de cardinalitate pentru
fiecare pereche de mulimi de entiti pe care le asociaz.
16
Diagrama Entitate-Asociere
Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezint
grafic modelul Entitate-Asociere prin mulimile de entiti i asocierile dintre
acestea
Multimi (tipuri) de entitati:
Puternice (de sine statatoare)
Slabe (depind de alte multimi de entitati)
Notatii:
Tip de entitate puternic
Tip entitate
Tip entitate
Tip de entitate slab
Nume
atribut
Atribut
Asociere binar 1:N

ntre 2 tipuri de entiti
17
Exemplu de diagrama Entitate-Asociere (1)

Multimi de entitati puternice:
SECTII (Numar, Nume, Buget)
ANGAJATI (Nume, Prenume, DataNasterii, Adresa, Functie, Salariu)
PROIECTE (Denumire, DataInceperii, Termen, Buget)
Multimi de entitati slabe: DEPENDENTI (Nume, Prenume, DataNasterii, GradRud)

Buget
Numr
Salariu
Nume
1
SECTII
Cuprind
ANGAJATI
1
M
Lucreaza
Intretin
N
N
DEPENDENTI
Nume
GradRudenie
PROIECTE
Denumire
Buget
18
Exemplu de diagrama Entitate-Asociere (2)

Asocieri:
Asocierea SECTII - ANGAJATI - 1:N
Asocierea ANGAJATI - PROIECTE - M:N
Asocierea ANGAJATI - DEPENDENTI - 1:N
Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel

nct s reflecte ct mai corect modul de organizare a activitii modelate
Modul de stabilire a tipurilor de entiti i a asocierilor nu este unic: aceeai
funcionalitate se poate obine printr-o varietate de diagrame E-A
O mulime de entiti se denumeste printr-un substantiv, iar o asociere se
denumeste (de regul) printr-un verb, deoarece o asociere reprezint o
interaciune ntre entiti
Modelul E-A nu precizeaz modul cum sunt realizate asocierile ntre
mulimile de entiti: acest aspect depinde de modelul de date specializat
utilizat pentru definirea bazei de date
Exemple: n modelul ierarhic asocierile sunt realizate explicit, prin pointeri de la o
entitate la entitile asociate; n modelul relaional asocierile se realizeaz prin
egalitatea valorilor unor atribute comune ale multimilor de entiti (chei)
19
Modelul Entitate-Asociere Extins

Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model)
permite definirea de subtipuri ale unui tip de entiti, care motenesc
atribute de la tipul de entitate respectiv
Crearea ierarhiilor: specializare si generalizare
Tipurile i a subtipurile formeaza ierarhii de tipuri de entiti complexe,
organizate pe mai multe niveluri
Diagrama Entitate-Asociere Extinsa
Nume
Prenume
DataNasterii
Adresa
Salariu
ANGAJAT
d
SECRETARA
VitezaRedactare
TEHNICIAN
INGINER
Calificare
Specialitate
20
Modelul de date ierarhic

Modelul ierarhic (Hierarchical Model): baza de date se reprezinta printr-o
structur ierarhic de nregistrri (records) conectate prin legturi (links).
A fost primul model folosit pentru dezvoltarea bazelor de date
Cel mai cunoscut SGBD ierarhic: sistemul IMS (Information Management
System) dezvoltat de IBM n programul de cercetri Apollo, n perioada anilor
1960
O nregistrare de date n modelul ierarhic este o instan a unui tip de

nregistrare (record type) i const dintr-o colecie de cmpuri (fields),
fiecare cmp coninnd valoarea unui atribut.
Un tip de legtur n modelul ierarhic: tip de asociere cu raportul de
cardinalitate 1:N (printe-fiu) ntre dou tipuri de nregistrri
Schema conceptual a unei baze de date n modelul ierarhic se reprezint
printr-un numr oarecare de scheme ierarhice
O schem ierarhic este un arbore direcionat, reprezentat pe mai multe
niveluri, n care nodurile sunt tipuri de nregistrri, iar arcele sunt tipuri de
legturi
21
Baze de date ierarhice

FACULTATI
FACULTATI
FACULTATI
f1
1
N
PROFESORI
f2
f3
PROFESORI
PROFESORI
p1
p2
p3
STUDENTI
N
STUDENTI
(a) Diagrama E-A
STUDENTI
s1
(b) Schema ierarhica
s2
s3
s1
s2
s4
(c) Arbori de instantiare

a datelor
Numai legturi de tipul printe-fiu, care corespund asocierilor 1:1 i 1:N din
modelul E-A
Asocierile M:N se pot reprezenta prin multiplicarea nregistrrilor de tip fiu,
atunci cnd sunt referite de mai multe nregistrri de tip printe
mare redundan a datelor
Avantaje: simplitatea i eficiena de calcul

Deficiente:
nu exista separare intre descrierea logica si fizica a datelor
interogarile trebuie s fie prevzute explicit in structura datelor
Utilizari actuale - aplicatii specializate, baze de date XML

22
Modelul de date retea

Modelul reea (Network Model) folosete o structur de graf pentru
definirea schemei conceptuale a bazei de date
Modelele ierarhic si retea modele pre-relationale
Standardizat n 1971, de o comisie DBTG (Database Task Group).
Sisteme de gestiune comerciale in modelul retea: IDS II (Honeywell),
UNISYS (Burroughs), IDMS (Computer Associates)
Nodurile grafului sunt tipuri de entiti (nregistrri - records), iar muchiile
reprezint asocierile (legturile-links) dintre tipurile de entiti
Asocierile M:N se reprezint fr duplicarea nregistrrilor, fiecare
nregistrare putnd fi referit de mai multe nregistrri, ceea ce elimin
FACULTATI
(micoreaz) redundana
Dezavantaje:
f1
f2
f3
aceleasi ca si la modelul ierarhic, la care se adauga

complexitatea mare in reprezentarea datelor
PROFESORI
p1
Actualmente modelul retea:
p2
p3
STUDENTI
este rar utilizat pentru baze de date de uz general

se utilizeaza pentru aplicaii specializate
s1
de ex, pentru baze de date grafice (scene virtuale)

s2
s3
s4
Modelul retea
23
Modelul de date relational

Modelul relaional (Relational Model) se bazeaz pe noiunea de relaie
(relation) din matematic, care corespunde unei mulimi de entiti
Fundamentat de E.F. Codd (IBM), prin lucrarea "Un Model Relaional de
Date pentru Bnci Mari de Date Partajate" (1970)
Dezvoltare extraordinara a sistemelor de gestiune a bazelor de date
relationale, datorit simplitii i a fundamentrii matematice a modelului
Alte lucrri ale cercetatorilor C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R.
Fagin, W. Armstrong, M. Stonebraker etc. au perfecionat modelul relaional
Primul Sistem de Gestiune a Bazelor de Date Relaionale (SGBDR) a fost
prototipul System R (IBM, 1970)
Dup aceasta numeroase companii au realizat sisteme de gestiune
relaionale: Oracle, Microsoft, Ingres, Sybase, IBM, Informix
SGBDR folosesc limbajul SQL (Structured Query Language), pentru care
au fost emise mai multe standarde ANSI (American National
Standardization Institute) si ISO (International Standardization Office)
Majoritatea SGBD-urilor relaionale actuale implementeaz versiunea SQL2
(SQL92) sau versiuni ulterioare (SQL-1999, SQL-2003, SQL-2006)
24
Modelul obiect-orientat
Modelul obiect (Object Model) este un concept unificator
Necesar in domenii n care se manipuleaz date de tipuri complexe:
proiectarea sistemelor de calcul: programare, hardware, interfete
proiectarea asistat de calculator (CAD-CAM)
sisteme de informaii geografice
fizic, biologie, medicin i altele
Strategii pentru dezvoltarea sistemelor de gestiune a bazelor de date

obiect-orientate (SGBDOO):
Extinderea unui limbaj de programare obiect-orientat cu capaciti de
administrare a obiectelor persistente: sistemul GemStone (extinde Java si C++)
Extinderea unui limbaj de programare relaional cu capaciti de orientare spre
obiecte. Exemplu: limbajul OQL (Object Query Language) (sau Object SQL),
Exist mai multe astfel de sisteme, cum sunt: Ontos, Versant, O2.
Dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou: SIM
(Semantic Information Manager).
Dificultati:
Complexitate in dezvoltare a bazei de date i a aplicaiilor
Interogarile trebuie s fie prevzute explicit in structura datelor
Utilizare SGBDOO: cam 5% din sistemele de gestiune actuale

25
Modelul obiect-relational
Modelul obiect-relaional (Object-Relational Model) reprezint extinderea
modelului relaional cu caracteristici ale modelului obiect
Modelul obiect-relaional pstreaz structurarea datelor n relaii, si, in plus:
permite definirea unor noi tipuri de date, ca domenii ale atributelor
permite extinderea tipurilor de date prin motenire
Sistemele de gestiune a bazelor de date obiect-relaionale (SGBDOR) se

realizeaz prin extinderea sistemelor relaionale, de regula n mod gradat,
adugndu-se de la o versiune la alta ct mai multe caracteristici posibile
ale modelului obiect
Aceasta abordare asigur rularea n continuare a aplicaiilor relaionale
existente n noile versiuni de sisteme SGBDOR, ceea ce permite
productorilor s-i pstreze clienii i domeniile de utilizare
Limbajele de programare pentru SGBDOR sunt implementri de standarde
mai recente ale limbajului SQL: SQL3 (SQL-1999), SQL-2003, SQL-2006
26
Complexitatea datelor si a interogarilor

Clasificare propusa de M. Stonebraker (1996)
Complexitatea
interogrilor
SGBDR
SGBDOR
Sisteme de fiiere
SGBDOO
Complexitatea
datelor
SGBDR prelucreaz tipuri simple de date, dar permit interogri complexe

SGBDOO prelucreaz tipuri de date complexe, dar n care rezolvarea
interogrilor este destul de dificil
SGBDOR permit prelucrarea datelor complexe i rezolvarea interogrilor
complexe; sistemele de baze de date obiect-relaionale sunt considerate
sisteme de baze de date universale
27
Evolutia sistemelor de baze de date

1960
Modele prerelationale: ierarhic si retea

Primele produse de baze de date (DBOM, IMS, IDS, Total, IDMS)
Standarde Codasyl
1970
Modelul relational prototipuri de SGBDR

Lucrari teoretice asupra modelului relational
Arhitectura interna pe 3 niveluri a bazelor de date (ANSI and Codasyl)
Modelul Entitate-Asociere
1980
Dezvoltarea SGBDR comerciale

Primul standard SQL (1986 - ANSI, ISO)
Baze de date distribuite
1990
Arhitectura client/server a sistemelor de baze de date (two-tier arch.)

Baze de date obiect-orientate
Baze de date obiect-relationale
Standarde SQL: SQL 92, SQL 99
2000
Arhitectura pe 3 niveluri a sistemelor de baze de date (three-tier arch.)

Baze de date in sistemul WWW (World Wide Web)
28
Sisteme de Gestiune a Bazelor de date

Sisteme Comerciale
Oracle ($$$$)
DB2 (IBM) ($$$)
SQL Server (Microsoft) ($$)
Sisteme Open Source
PostgreSQL
MySQL
29
30
Capitolul 2: Baze de date relaionale

Relaii, atribute, domenii; schema relaiei
Reprezentarea relaiilor prin tabele
Limbajul SQL:
Convenii lexicale
Expresii, operatori, functii
Instructiuni de definire a datelor: CREATE, ALTER, DROP
Instructiuni de manipulare a datelor: SELECT, INSERT, UPDATE, DELETE
Constrngerile de integritate ale relaiilor

Constrngeri de domeniu
Constrngeri de tuplu: cheia primar chei secundare
Constrngeri de integritate referenial chei strine
Indexarea relaiilor
Indexul primar
Indexuri secundare
Cap. 2 - Baze de date relationale
Relaii Atribute Domenii

Modelul relaional: E.F.Codd, 1970 IBM
O baz de date relaional este compus dintr-o mulime finit de relaii
fiecare relaie reprezinta o mulime (tip) de entitati sau o mulime (tip) de asocieri
fiecare relaie este unica intr-o baza de date
o relaie se defineste prin intermediul atributelor sale
Atributele unei relaii corespund atributelor tipului de entitate sau de

asociere pe care l reprezint relaia respectiv
fiecare atribut are un nume (Ai) i un domeniu de definiie D(Ai)
pentru o entitate data, un atribut poate lua o singur valoare (scalar)
Atributele pot fi: simple (un element) sau compuse (o submulime de atribute)
Domeniu: o mulime de valori D = {di | i = 1,, n }, definit printr-o specificare
de tip, unde:
D este numele domeniului
di este un element al domeniului care satisface anumite constrngeri
Elementele domeniilor sunt atomice (indivizibile)
O valoare speciala, null, poate apartine oricarui domeniu (inseamna lipsa de
informatie sau valoare necunoscuta)
Schema relaiei
Schema relaiei: descriere a unei relaii (tipul, intensiunea relaiei)
Schema relaiei: R(A1,A2,...Ai,...An), unde:
R este numele schemei relaiei
lista ordonat a atributelor sale A1,A2,...Ai,..An
fiecare atribut Ai definit pe domeniul su de definiie, D(Ai)
Gradul relaiei: numrul de atribute ale schemei acelei relaii (n)
Exemplu: STUDENTI (Nume, Prenume, DataNasterii, Adresa, Facultatea)
O relaie r definita prin schema R(A1,A2,...Ai,...An) este:

o mulime finita de n-tupluri t
tuplul t este o list ordonat de n valori: t = <v1,v2,...vi,...vn>, unde 1 i n
vi este o valoare a atributului Ai, vi D(Ai)
Relaia r(R): r este variabila, instanta a schemei (tipului) R

Valoarea variabilei: starea sau extensiunea relaiei
Numarul de tupluri ale unei relaii: cardinalitatea relaiei
Fiecare tuplu este unic intr-o relaie (nu exista tupluri duplicat)
Corespondenta: relaiemulime de entitati (sau de asocieri); tuplu entitate
n mod curent: se foloseste R atat pentru schema cat i pentru relaia insasi
Reprezentarea relaiilor prin tabele

Un tabel (table) = reprezentarea grafic a unei relaii; compus din:
Numele tabelului - identic cu numele relaiei
Coloanele corespund atributelor relaiei
Capul tabelului- contine numele atributelor (coloanelor) schema relaiei
O mulime de linii, fiecare linie corespunznd unui tuplu starea relaiei
Valori ale atributelor fiecarui tuplu
Exemplu: Tabelul care reprezinta relaia (starea relaiei) STUDENTI

Valori
atribute
Coloane - Atribute
Numele
STUDENTI
Nume
Prenume
DataNasterii
Adresa
Facultatea
Anghelescu
Octavian
1999
Bucuresti
ETTI
Beldiman
Cristina
1998
Bucuresti
ETTI
Boeru
Marius
1999
null
ETTI
Capul
tabelului
Linii - tupluri
Tabelul sugereaz ordonarea atributelor (coloanelor) i a tuplurilor (liniilor)

ceea ce nu corespunde modelului matematic (relaie = mulime de tupluri)
Afiarea tabelelor
SGBD-urile ofer instrumnente de proiectare i afisare a tabelelor
De exemplu, afiarea tabelului Employees din baza de date Northwind folosind
toolset-ul SQL Query Analyser din Microsoft SQL Server
Ordonarea valorilor atributelor n tupluri

Din punct de vedere logic, ordinea valorilor atributelor ntr-un tuplu nu
conteaza; aceast structurare poate fi exprimat prin urmtoarele definiii:
Schema relaiei: R = {A1,A2, ...Ai,...An} (o mulime de atribute)
Relaia r(R): o mulime de n-tupluri t, unde:
fiecare tuplu t este o mulime de n perechi ordonate <Ai,vi>, unde 1 i n,
t = {<A1,v1>,<A2,v2>,...<Ai,vi>, ...<An,vn>}
vi este valoarea atributului Ai, vi D(Ai)
Observaii asupra celor dou definiii:

A doua definiie a relaiei este mult mai general decat prima definitie
Prima definiie simplific notaiile i corespunde reprezentrii prin tabel a relaiei
i de aceea va fi folosit n continuare destul de frecvent
n implementrile reale, exist o anumit ordine a valorilor atributelor memorate
n fiiere, dar aceasta nu este relevant din punct de vedere logic
Limbajul SQL
Limbajul IBM Sequel dezvoltat ca parte a proiectului System R la IBM San
Jose Research Laboratory (1970)
Redenumit Structured Query Language (SQL)
Standarde SQL - ANSI i ISO:
Anul
Denumire
Caracteristici
1986
SQL-86
Publicat de ANSI (SQL1); ratificat de ISO n 1987
1989
SQL-89
Revizii minore
1992
SQL-92
Revizii majore, redenumit SQL2
1999
SQL-1999
Redenumit SQL3, adauga unele caracteristici

obiect-relaionale
2003
SQL-2003
Adauga unele trasaturi referitoare la limbajul XML
2006
SQL-2006
Utilizare SQL n conjunctie cu XML
Fiecare SGBDR implementeaz un dialect al limbajului SQL, ceea ce

micoreaz gradul de portabilitate a aplicaiilor
n diferitele implementri ale limbajului SQL pot s lipseasc unele comenzi
prevzute n standard, dar pot exista extensii specifice SGBD-ului respectiv
Caracteristicile generale ale limbajului SQL

Limbajul SQL foloseste reprezentarea prin tabele a relaiilor, reprezentare
care este mai simpl i mai intuitiv (foloseste termenii tabel, linie, coloan)
Limbajul SQL cuprinde:
Componenta de descriere a datelor (Limbaj de Descriere a Datelor LDD)
Componenta de manipulare a datelor (Limbaj de Manipulare a Datelor LMD)
Alte componente: controlul tranzactiilor, controlul securitatii, protectia datelor etc.
Limbajul SQL2 este un limbaj neprocedural:

o instruciune SQL2 specific ce informaii trebuie s fie setate sau obinute, nu
modul (procedura) n care se opereaz
limbajul SQL2 nu conine instruciuni de control al fluxului execuiei (instruciuni
ca for, while, if, etc)
Standardul SQL3 prevede instructiuni de control i crearea de tipuri definite

de utilizator, fiind implementat n SGBD-urile obiect-relaionale
Pentru aplicaiile de baze de date, s-au dezvoltat extensii procedurale ale
limbajului SQL, biblioteci i interfee de programare care integreaz
instruciunile SQL
Structura lexicala a limbajului SQL

O instruciune SQL (statement) este o secven de elemente - de regula
terminat cu semnul punct i virgul (;)
Fiecare instruciune SQL conine o comand SQL (command), care specific
ce aciune se efectueaz, urmat de alte elemente, care specific operaii,
clauze, parametri etc.
Exemplu: SELECT * FROM ANGAJATI;
Elementele (tokens) instruciunilor SQL

cuvnte cheie (key words): CREATE, INSERT, SELECT , WHERE, FROM etc.
identificatori (identifiers):
simpli - numai caractere alfa-numerice i underscore(_): ANGAJATI, Nume, Prenume etc.
delimitati (quoted) - pot contine orice caracter, foloseste ghilimele : Nume, Prenume etc.
constante (literali): 1000, 100.5, Ionescu, NULL

caractere speciale: *, ., ;
Spaiile albe (whitespaces) separa elementele: spaiu, linie nou, tab

O instructiune se poate scrie pe una sau mai multe linii, iar ntr-o linie se pot
introduce una sau mai multe instructiuni
Limbajul SQL este case-insensitive (nu deosebeste literele mici de cele mari)
cu exceptia identificatorilor delimitati (quoted) care sunt case-sensitive
Expresii i operatori n limbajul SQL

O expresie SQL const dintr-unul sau mai muli operanzi, operatori i
paranteze
Parantezele se pot folosi pentru a preciza o anumit ordine a operaiilor, dac
aceasta este diferit de ordinea implicit data de precedenta operatorilor.
Un operand poate fi:

numele unei coloane n acest caz se foloseste valoarea memorata n acea
colona intr-una sau mai multe linii ale tabelului
o constant (literal)
valoarea returnat de o functie
Un operator SQL este exprimat prin:

unul sau mai mai multe caractere speciale; exemple: +, -, *, /, %, <= etc.
un cuvnt cheie; exemple: AND, OR, NOT, LIKE etc.
Operatori SQL: binari sau unari (dupa numarul de operanzi)

Operatori SQL: aritmetici, de comparaie SQL, relaionali, logici
Operatori aritmetici de operatii cu numere intregi sau reale: +, -, *, /, %, ^

Operatori aritmetici orientati pe biti: ~, &, |, #
Operatori aritmetici de comparatie: <, >, =, <> (sau !=), <=, >=
Operatori de comparatie SQL: IS NULL, IS NOT NULL, BETWEEN, IN, LIKE
Operatori relaionali: UNION, INTERSECT, MINUS
10
Operatori SQL
Operatorii de comparaie returneaz valori logice:
true (1), dac condiia este ndeplinit
false (0) dac condiia nu este ndeplinit
null dac ambii operanzi au valoarea null
Operatorii logici (NOT, AND, OR):

se aplic unor valori logice trivalente (cu 3 valori: true (1), false (0) i null - lipsa de
informatie)
returneaz o valoare logic trivalent
A
A and B
A or B
not A
true
true
true
true
true
false
true
false
false
true
false
true
true
null
null
true
null
null
false
false
false
false
false
null
false
null
null
null
null
null
11
Funcii SQL
Funcii SQL: funcii agregat i funcii scalare.
Funciile agregat calculeaz un rezultat din mai multe linii ale unui tabel
Aceste funcii vor fi detaliate ulterior, la descrierea instruciunii SELECT
Funciile scalare:
Primesc unul sau mai multe argumente i returneaz valoarea calculat sau NULL
n caz de eroare
Argumentele funciilor pot fi constante (literale) sau valori ale atributelor specificate
prin numele coloanelor corespunzatoare
Tipuri de funcii scalare SQL:

Funcii de calcul trigonometric (sin, cos, tan etc.), funcii de calcul al logaritmului
(ln, log), al puterii (power), funcii de rotunjire (floor, ceil), etc.
Funcii pentru manipularea irurilor de caractere: concat, replace, upper etc.
Funcii pentru data calendaristic i timp: add_months, next_day, last_day etc.
Funcii de conversie: to_number, to_char etc.
Funciile scalare se folosesc n expresii, care pot s apar n diferite clauze

ale instruciunilor SQL
12
Tipuri de date SQL (1)

Tipuri de date SQL2: numeric, iruri de caractere, iruri de bii, data
(calendaristic), timp
Tipul numeric:
numere ntregi: integer sau int (4 octei), smallint (2 octei)
numere reale reprezentate n virgul flotanta: float (4 octei), real i double
[precision] (8 octei)
numere zecimale reprezentate cu precizia dorit (tipul numeric sau decimal,
memorate ca ir de caractere): numeric[(p,s)] (sau decimal [(p,s)]), unde p
(precizia) este numrul total de cifre, iar s (scara) este numrul de cifre dup
punctul zecimal
Siruri de caractere:
character(n), prescurtat, char(n) - ir de caractere de lungime fix (n)
character varying(n), prescurtat varchar(n) - ir de caractere de lungime variabil,
maximum n
Siruri de bii - secvene de cifre binare (care pot lua valoarea 0 sau 1):
bit(n)) - sir de biti de lungime fix (n)
bit varying(n) sir de biti lungime variabil, maxim n
13
Tipuri de date SQL (2)

Tipurile SQL pentru data calendaristic i timp sunt: date, time, timestamp,
interval:
Tipul date: memorarea datelor calendaristice prin utilizarea a trei cmpuri (year,
month, day), n formatul yyyy-mm-dd; se admit numai date valide
Tipul time: memorarea timpului, folosind trei cmpuri (hour, minute, second) n
formatul HH:MM:SS; se admit numai valori valide
Tipul timestamp(p): memorarea combinat a datei calendaristice i a timpului,
cu precizia p pentru cmpul second. Valoarea implicit a lui p este 6
Tipul interval este utilizat pentru memorarea intervalelor de timp
Variante de tipuri de date SQL specifice n diferite sisteme SGBD; Exemple:

SGBD Microsoft SQL Server: tinyint - numr ntreg pe 1 octet
SGBD Oracle: varchar2 - ir de caractere de lungime variabil
Standardul SQL2 nu suport tipuri de date i operaii definite de utilizator

Standardul SQL3 suport tipuri de date i operaii definite de utilizator, care
sunt caracteristice ale modelului de date obiect-relaional
Actualmente, productorii de sisteme de baze de date relaionale introduc
treptat diferite caracteristici ale modelului obiect-relaional cuprinse n SQL3
14
Domenii SQL
n SQL2 domeniile atributelor se specific pe baza tipurilor de date
predefinite ale limbajului SQL, deci nu corespund ntru totul noiunii de
domeniu relaional
Standardul SQL2 prevede comanda CREATE DOMAIN, care definete un
domeniu pe baza unui tip predefinit SQL2 i cu unele constrngeri
Standardul SQL3 prevede comanda CREATE TYPE care creaz tipuri
definite de utilizator (user-defined types)
n SGBD-urile actuale sunt implementate diferite versiuni din standarde:
n SQL Server se pot crea domenii ale atributelor cu comanda SQL CREATE
DOMAIN
n Oracle (8i, 9i, 10g,11g) se pot crea tipuri de date noi, folosind comanda
CREATE TYPE, care permite gruparea sub un anumit nume a mai multor
atribute i operatii
n PostgreSQL de asemenea se pot crea tipuri de date noi, folosind comanda
CREATE TYPE
15
Conventii de notatie
Pentru prezentarea limbajului SQL i a altor limbaje, biblioteci i interfete
[
] (paranteze drepte)
Element opional al instruciunii
} (acolade)
Element obligatoriu al instruciunii
| (bar vertical)
Separ elementele din parantezele drepte sau

acolade; numai unul dintre acestea se poate
introduce n instruciunea respectiv
[ , . . . n]
Elementul precedent poate fi repetat de n ori;

elementele repetate sunt separate prin virgul
element1, . . . . . . .
elementn
List de n elemente de acelai tip;

elementele repetate sunt separate prin virgul
lista_elemente
List de elemente de acelai tip separate prin virgul
Caracterele folosite pentru a specifica o anumit convenie sintactic

(paranteze, bara vertical, virgula, etc.) nu apar n instruciunile propriu-zise
Listele de elemente (compuse din mai multe elemente separate prin virgul)
vor fi exprimate folosind una cele trei din construciile de mai sus, care se
potrivete cel mai bine instruciunii respective
16
Instruciuni SQL
Componenta de definire a datelor din SQL (LDD - Limbajul de Definire a Datelor):
Crearea (CREATE), modificarea (ALTER) i distrugerea (DROP) obiectelor bazei de
date
Obiectele bazei de date sunt: tabele de baz (TABLE), tabele vedere (VIEW), indexuri
(INDEX), proceduri (PROCEDURE), trigere (TRIGGER), utilizatori (USER)
Exemple de comenzi SQL de definire a datelor:

CREATE TABLE, CREATE VIEW,
CREATE INDEX,
CREATE USER
CREATE FUNCTION, CREATE TRIGGER, CREATE PROCEDURE

ALTER TABLE, ALTER VIEW,
DROP TABLE,
DROP VIEW,
DROP FUNCTION,
ALTER FUNCTION,
DROP INDEX,
DROP PROCEDURE,
ALTER PROCEDURE
DROP USER
DROP TRIGGER
Componenta de manipulare a datelor din limbajul SQL (Limbajul de Manipulare a

Datelor - LMD) conine comenzile: SELECT, INSERT, UPDATE i DELETE
Instructiunile SQL se transmit SGBD-ului:
de ctre diferite programe client (client grafic, linie de comanda, program executabil)
SGBD-ul compileaz i execut instructiunea SQL
returneaz un rspuns (rezultatul operaiei sau un cod de eroare)
17
Crearea tabelelor
Instruciunea CREATE TABLE are urmtoarea sintax:
CREATE TABLE nume_tabel (
col1 domeniu1 [constrngeri_coloana],
col2 domeniu2 [constrngeri_coloana],
.................................
coln domeniun [constrngeri_coloana],
[constrngeri_tabel] );
Constrngerile impuse fiecrei coloane (atribut), ca i constrngerile de

tabel, sunt opionale i vor fi discutate n sectiunea urmtoare. Exemplu:
CREATE TABLE ANGAJATI (
Nume
varchar(20),
Prenume
varchar(20),
DataNasterii
date,
Adresa
varchar(50),
Functia
varchar(20),
Salariu
numeric);
Instruciunea CREATE TABLE definete att tipul relaiei ct i o variabil

relaie de acel tip care iniial este vid (nu conine nici un tuplu)
18
Crearea vederilor
Tabelele create cu instruciunea CREATE TABLE:
se numesc i tabele de baz (base tables)
ele sunt memorate n fiierele bazei de date i pot fi accesate pentru introducerea,
modificarea i regsirea (interogarea) datelor
Un tabel vedere (view) este un tabel virtual care:

nu este memorat fizic n fiiere
reprezint o selecie (dup un anumit criteriu) a datelor memorate n unul sau mai
multe tabele de baz
Un tabel vedere se creeaza cu instruciunea SQL:

CREATE VIEW nume_vedere AS (SELECT...);
Formatul comenzii SELECT va fi descris n capitolul urmtor

Datele (valorile atributelor) sunt memorate o singur dat, n tabelele de baz,
dar pot fi accesate att prin tabelele de baz ct i prin tabelele vederi
Un tabel vedere este ntotdeauna actualizat ("la zi"), adic orice modificare
efectuat n tabelele de baz se regsete imediat n orice tabel vedere creat
pe baza acestora
19
Modificarea i stergerea tabelelor i a vederilor

Comanda de modificare a tabelelor (ALTER TABLE) permite:
adugarea sau tergerea unor atribute
modificarea domeniilor unor atribute
adugarea, modificarea sau tergerea unor constrngeri ale tabelului
Pentru adugare unei coloane ntr-un tabel se folosete clauza ADD,

urmata de numele coloanei i numele domeniului (tipul SQL) atributului
corespunztor. Exemplu:
ALTER TABLE ANGAJATI ADD DataAngajarii date;
Pentru tergerea unei coloane dintr-un tabel se folosete clauza DROP,

urmata de numele coloanei care se va sterge. Exemplu:
ALTER TABLE ANGAJATI DROP DataAngajarii;
Instruciunile de tergere a tabelelor de baz i a vederilor sunt:

DROP TABLE nume_tabel;
DROP VIEW nume_vedere;
20
Instruciunea SELECT
SELECT - instruciune de interogare, prin care se regsesc informaiile din
unul sau mai multe tabele ale bazei de date dupa un criteriu (conditie) dat
Sintaxa general:
SELECT [DISTINCT] lista_coloane
[FROM lista_tabele]
[WHERE conditie]
[clauze_secundare];
SELECT returneaza un tabel cu coloanele din lista_coloane

ale acelor linii (tupluri) ale produsului cartezian al tabelelor din lista_tabele
pentru care expresia logic conditie este adevrat (are valoarea TRUE).
Instructiunea SELECT are urmatoarele seciuni (clauze):

Clauza SELECT definete lista de coloane a tabelului rezultat
Clauza FROM indic lista de tabele din care se selecteaz rezultatul
Clauza WHERE definete condiia pe care trebuie s o ndeplineasc fiecare
linie a tabelului rezultat
Clauze secundare (ORDER BY, GROUP BY, HAVING): permit ordonri sau
grupri ale tuplurilor (liniilor) rezultate
21
Clauza SELECT
Clauza SELECT specific:
lista coloanelor unor tabele (date n lista_tabele)
expresii care vor fi calculate i afiate
Exemple:
SELECT ID, Name, CountryCode, District from city;
SELECT 3*4, cos(45), floor(12.45);
Eliminarea liniilor duplicat cu parametrul DISTINCT. Exemplu:

SELECT [DISTINCT] CountryCode FROM city;
Selectarea tuturor coloanelor produsului cartezian al tabelelor date - cu

caracterul * ca i lista_coloane. Exemplu:
SELECT * FROM city;
n clauza SELECT se pot redenumi tabelele i coloanele tabelelor sau se pot

specifica nume pentru expresii, folosind urmtoarea sintax:
SELECT nume1 [AS] noul_nume1 [,...n] FROM lista_tabele [alte_clauze];
SELECT ID, Name Oras, CountryCode Cod Tara FROM city;
22
Clauzele FROM i WHERE

Clauza FROM specific lista_tabele din care se selecteaz rezultatul
Numele coloanelor din lista_coloane (clauza SELECT) trebuie s fie distincte
Dac nu sunt distincte, se calific unele coloane cu numele tabelului caruia i
aparin - folosind operatorul punct (.). De exemplu:
SELECT ANGAJATI.Nume, SECTII.Nume FROM ANGAJATI, SECTII;
Clauza WHERE specifica conditia pe care trebuie sa o ndeplinesca rezultatul:

conditia este o expresie logic compusa din valori logice, operatori logici (NOT, AND,
OR) i paranteze
o valoare logic se obtine ca rezultat al comparaiei ntre doi operanzi folosind un
operator de comparaie
un operand poate fi un atribut (nume de coloan), o constant, valoarea unei expresii
aritmetice sau o valoare returnat de o funcie
operatorii de comparaie pot fi operatori aritmetici sau operatori SQL de comparaie
Exemple:
SELECT * FROM city WHERE Population > 1000;
SELECT * FROM city WHERE (Population > 200000) AND (CountryCode=ROM);
23
Clauze secundare funcii agregat

Clauzele secundare sunt: ORDER BY, GROUP BY, HAVING
Clauza ORDER BY specific numele atributului dup care se face ordonarea
liniilor tabelului rezultat
SELECT * FROM city order by CountryCode;
Ordonarea n ordine cresctoare: parametrul ASC (implicit); n ordine

descrescatoare: DESC. Exemplu:
SELECT * FROM city order by CountryCode DESC;
Clauzele GROUP BY i HAVING se folosesc mpreun cu funciile agregat

Funciile agregat definite n limbajul SQL2 sunt urmtoarele:
Functia
Valoarea returnata
COUNT
Numarul de linii al tabelului rezultat
SUM
Suma valorilor din coloana dat ca argument
MAX
Valoarea maxima din coloana dat ca argument
MIN
Valoarea minima din coloana dat ca argument
AVG
Valoarea medie din coloana dat ca argument
24
Funcii agregat
Exemple de funcii agregat fr clauze secundare:
SELECT COUNT(*) FROM city;
-- returneaza numarul de linii din tabel
SELECT COUNT(col) FROM city;
-- return nr de valori dif de null din acea col.
SELECT MAX(Population) FROM city;

SELECT MIN(Population) FROM city;
SELECT AVG(Population) FROM city;
Clauza GROUP BY se folosete pentru gruparea rezultatelor funciilor agregat

dupa valoarea uneia sau mai multor coloane. Exemplu:
SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode;
Clauza HAVING nlocuiete clauza WHERE atunci cnd n condiia care

trebuie s fie ndeplinit se folosesc funcii agregat. Exemplu:
SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode
HAVING AVG(Population) >800000;
25
Instruciunea INSERT
Instruciunea INSERT se folosete pentru introducerea datelor n tabele i are
urmtoarea sintax:
INSERT INTO nume_tabel (col1,col2,...coln) VALUES(val1,val2,...valn);
ntre valori i numele de coloane trebuie s existe o coresponden

pozitional. De exemplu:
INSERT INTO SECTII (Numar, Nume, Buget) VALUES (1,Productie, 40000);
Lista de coloane poate s lipseasc dac se introduc valori n toate coloanele

tabelului i n aceast situatie:
ordinea valorilor introduse trebuie s respecte ordinea coloanelor tabelului
ordinea coloanelor provine din ordinea de definire a atributelor prin instruciunea
CREATE TABLE, precum i din operaiile ulterioare de alterare a tabelului
ordinea coloanelor se poate afla prin instruciunea DESCRIBE nume_tabel.
De exemplu, introducerea unei linii cu toate valorile n tabelul

ANGAJATI (IdAngajat,Nume,Prenume,DataNasterii,Adresa,Functia,Salariu)
se poate face cu instruciunea:
INSERT INTO ANGAJATI
VALUES(100,Mihailescu, Mihai,1950-04-05,Craiova,Inginer, 3000);
26
Instruciunile UPDATE i DELETE

Instruciunea UPDATE permite actualizarea valorilor coloanelor (atributelor)
din una sau mai multe linii ale unui tabel i are sintaxa:
UPDATE nume_tabel SET col1 = expr1 [, . . . n] [WHERE conditie];
Clauza WHERE: actualizarea valorilor se efectueaza numai asupra acelor linii

care ndeplinesc condiia dat. Exemplu:
UPDATE ANGAJATI SET Adresa = Bucuresti WHERE Nume = Popescu;
Dac este omis clauza WHERE, vor fi modificate valorile coloanelor din toate
liniile tabelului.
Instruciunea DELETE permite tergerea uneia sau mai multor linii dintr-un
tabel i are sintaxa:
DELETE FROM nume_tabel [WHERE conditie];
Din tabel se terg acele linii care ndeplinesc condiia dat n clauza WHERE.
Dac este omis clauza WHERE, vor fi sterse toate liniile din tabel.
Exemplu:
DELETE FROM ANGAJATI WHERE Nume =Ionescu;
27
Constrngeri de integritate (1)

Constrngerile de integritate (integrity constraints) sunt reguli care se impun
pentru ca datele memorate s corespund ct mai bine celor din realitate:
se definesc la proiectarea bazei de date
trebuie s fie respectate de orice stare a acesteia
Clasificare dup locul unde se definesc: constrngeri de coloana i

constrngeri de tabel
Clasificare dup numrul de relaii implicate: constrngeri intra-relaie i
constrngeri inter-relaii.
Constrngerile intra-relaie - reguli care se impun n cadrul unei singure relaii;
sunt de trei categorii:
Constrngeri de domeniu - condiii ce se impun valorilor domeniilor atributelor
Constrngeri de tuplu - condiii ce se impun tuplurilor unei relaii prin chei (primare
sau secundare)
Constrngeri impuse prin dependene de date (dependene funcionale,
multivalorice sau de jonciune); acestea sunt constrngeri intre valorile atributelor
dintr-o relaie
Constrngerile inter-relaii - reguli care se impun ntre dou sau mai multe
relaii; asigura integritarea referenial prin intermediul cheilor strine
28
Constrngeri de integritate (2)

Clasificare din punct de vedere al modului de definire i de verificare a
respectrii constrngerilor: inerente, implicite i explicite.
Constrngerile inerente sunt cele ale modelului de date nsui, care nu
trebuie s fie definite deoarece sunt incluse n sistemul de gestiune
De exemplu: n modelul relaional constrngerea ca valoarea fiecrui atribut s
fie atomic (indivizibil) este o constrngere inerent
Constrngerile implicite sunt reguli specifice fiecrui sistem de gestiune;

acestea se definesc de ctre proiectant, iar sistemul de gestiune le verific
i le impune automat
Exemple: connstrngerile de domeniu, constrngerile de tuplu i constrngerile
de integritate referenial sunt constrngeri implicite.
Constrngerile explicite sunt constrngeri suplimentare, specifice bazei

de date respective; proiectantul definete constrngerile explicite precum i
procedurile de verificare ale accestora (funcii, proceduri stocate, triggere)
Exemple: dependenele de date care nu sunt determinate de cheile relaiilor
29
Constrngeri de domeniu (1)

Constrngerile de domeniu: constrngerea NOT NULL, constrngerea de
valoare implicit (DEFAULT), constrngerea de verificare (CHECK)
Constrngerea NOT NULL nsemna c atributul respectiv nu poate lua
valoarea NULL n nici un tuplu al relaiei.
Valoarea NULL a unui atribut ntr-un tuplu semnific faptul c valoarea acelui
atribut nu este cunoscut pentru acel tuplu. Exemple:
nu se cunoaste deloc data de nastere a unei personalitati istorice;
nu se cunoate valoarea unui atribut n momentul inserarii tuplului, dar aceasta va fi
cunoscuta i completat ulterior
La crearea unui tabel opiunea NULL este implicit (nu se specific nimic), sau
se poate introduce explicit; optiunea NOT NULL se introduce explicit.
Optiunile NULL i NOT NULL se introduc ca i constrngeri de coloana n
instructiunea SQL CREATE TABLE. Exemplu:
Nume
varchar(20) NOT NULL,
Prenume
DataNasterii
date NULL,
Functie
varchar(20),
Salariu
numeric);
30
Constrngeri de domeniu (2)

Constrangerea de valoare implicit a unui atribut (DEFAULT): dac la
inserarea unui tuplu nu se specific valoarea unui atribut, atunci:
atributul primete valoarea implicit (DEFAULT), dac a fost definit
atributul primete valoarea NULL, dac nu a fost definit valoare implicit, dar sunt
admise valori NULL
se genereaz o eroare, dac nu a fost definit o valoare implicit i nici nu sunt
admise valori NULL. Exemplu:
CREATE TABLE STUDENTI (
Nume
varchar (20) NOT NULL,
Prenume varchar (20) NOT NULL,
Tara
varchar (20) DEFAULT Romania ) ;
Constrngerea de verificare (CHECK) pentru verificarea valorilor atributelor

printr-o conditie care trebuie sa ia valoarea TRUE.
Se introduce ca o constrangere de tabel n instructiunea CREATE TABLE:
[CONSTRAINT nume_constrangere] CHECK (conditie); Exemplu:
Nume
Prenume varchar(20) NOT NULL,
Salariu
numeric,
CONSTRAINT Verificare_Salariu CHECK (Salariu >= 1500 ));
MySql 5.0 nu face verificarea CHECK, chiar daca admite acest cuvnt cheie
31
Constrngeri de tuplu
O relaie = mulime de tupluri tuplurile unei relaii trebuie s fie distincte (nu
pot exista dou sau mai multe tupluri identice)
Pentru ca tuplurile unei relaii s fie distincte se folosete cte o cheie primar
(primary key) n fiecare relaie
O cheie primar PK a unei relaii este un atribut (simplu sau compus) al acelei
relaii care are proprietatea de unicitate, adic fiecare valoare a cheii primare
este unic n acea relaie. Aceasta nseamn c:
Nu exist dou tupluri distincte (diferite) care s aib aceeai valoare a cheii primare
(sau combinaie de valori) pentru orice stare a relaiei, adic:
ti[PK] tj[PK] dac i j, unde ti i tj sunt 2 tupuri diferite ale relaiei
Proprietatea de unicitate a cheii primare este o constrngere de integritate a

tuplurilor: fiecare tuplu poate fi identificat n mod precis i se pstreaz
integritatea acestuia, dac se cunoate valoarea cheii sale primare
Cheia primar este o constrngere implicit: se definete de proiectant la
crearea tabelului i este verificat de SGBD (s nu existe duplicate, etc)
Cheia primar mai are urmtoarele restricii:
Este ireductibil: nu exist o submulime proprie nevid a cheii PK care s aib
proprietatea de unicitate
Nici o valoare a atributelor cheii primare nu poate fi modificat prin operaii de
actualizare (UPDATE)
Nu se admit valori de NULL pentru nici unul dintre atributele cheii primare
32
Chei primare naturale i artificiale (1)

Se pot defini chei primare naturale sau chei primare artificile, cu condiia ca
acestea s ndeplineasc condiia de unicitate
O cheie primar natural este un atribut (simplu sau compus) al relaiei:
reprezint o proprietate a tipului de entitate (sau asociere) reprezntat de acea relaie
are n mod natural valori unice: nu exist dou tupluri cu aceeai valoare a cheii
primare, deoarece nu exist dou entiti cu acceai valoare a proprietii respective
O cheie primar artificial este un atribut (de obicei simplu) care nu reprezint o
proprietate a tipului de entitate sau asociere reprezentat de relaie, ci se adaug
n schema relaiei special pentru identificarea unic a tuplurilor
Exemplu:
ANGAJATI (IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu):
IdAngajat este o cheie primar artificial
Ar putea fi definite i chei primare naturale prin atribute simple sau compuse care au
proprietatea de unicitate n anumite condiii:
atributul simplu {CNP} valabil numai pentru persoanele din Romania
atributul compus {Nume, Prenume, DataNasterii, Adresa}
Din motive de eficien a operaiilor de identificare a tuplurilor, se prefer chei

primare cu un numr ct mai mic de atribute (atribut simplu)
33
Chei primare naturale i artificiale (2)

Modul de asigurare a unicitii valorii cheii primare artificiale depinde de
sistemul SGBD folosit. De exemplu:
n Microsoft SQL Server se pot obine valori unice ale cheii primare folosind
parametrul IDENTITY, care asigur incrementarea valorii atributului cheii la
introducerea fiecrei linii noi
n sistemele Oracle se pot genera chei artificiale folosind obiecte SEQUENCE; un
obiect SEQUENCE geneaza un numar unic la fiecare apel al metodei NEXTVAL
n MySQL, se foloseste parametrul AUTO_INCREMENT pentru generarea
numerelor unice pentru cheile primare.
SGBD-urile interzic introducerea liniilor (tuplurilor) care au valori identice ale

cheilor primare
34
Definirea cheii primare

Cheia primar se defineste prin instructiunea CREATE TABLE ca o
constrngere de tabel sau ca o constrngere de coloan
Definirea cheii primare ca o constrngere de tabel:
[CONSTRAINT nume_constr] PRIMARY KEY (lista_atribute)
Exemplu:
CREATE TABLE SECTII (
IdSectie int,
Nume
Buget
numeric,
CONSTRAINT PK PRIMARY KEY (IdSectie)
);
Dac cheia primar este simpl (format dintr-un singur atribut), ea se poate
specifica i ca o constrngere de coloan; exemplu:
IdAngajat
int PRIMARY KEY AUTO_INCREMENT,
Nume
varchar(20)
NOT NULL,
Prenume
varchar(20)
NOT NULL,
DataNasterii
Date,
Adresa
varchar(50),
Salariu
numeric) ;
35
Superchei, chei candidate

O supercheie (superkey) este o submulime SK de atribute ale unei relaii care
prezint proprietatea de unicitate (orice combinaie de valori ale atributelor
supercheii este unic pentru orice stare a relaiei)
Dac se cunoate valoarea (combinaia de valori ale atributelor) supercheii, atunci
acel tuplu poate fi identificat n mod unic
Orice relaie are cel puin o supercheie, care este mulimea tuturor atributelor sale
O cheie candidat (candidate key) este o supercheie ireductibil:

Unicitate: nu exist dou tupluri diferite ale relaiei care s conin aceeai
combinaie de valori ale atributelor cheii CK;
Ireductibilitate: nu exist nici o submulime proprie, nevid a cheii CK care s aib
proprietatea de unicitate
O cheie candidat poate fi simpl (un atribut), sau compus (mai multe atribute)
Exemplu: ANGAJATI (IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa,
Functia, Salariu)
SK1 = {IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu}
SK2 = {CNP, Nume, Prenume, DataNasterii, Adresa}; SK3 = {IdAngajat, CNP}
CK1= {Nume, Prenume, DataNasterii, Adresa}; CK2 = {CNP}; CK3 ={IdAngajat}
36
Chei candidate, primare i secundare

Atunci cnd exist mai multe chei candidate (cu proprietile de unicitate i
ireductibilitate), una dintre ele se alege ca i cheie primar, iar celelalte chei se
pot defini ca i chei secundare
Cheia primar este o cheie candidat aleas (desemnat) de proiectant la
definirea tabelului
O cheie secundar (alternativ, unic) (secondary, alternate, unique key) este
o cheie candidat definit de proiectant
Cheile secundare se definesc n instruciunea CREATE TABLE folosind specificatorul
UNIQUE [KEY] n loc de PRIMARY KEY
Alegerea cheii primare dintre mai multe chei candidate este arbitrar, dar, din
motive de eficien, se alege cheia cu cel mai mic numr de atribute
Cheile secundare se deosebesc de cele primare prin:
Pot fi modificate prin instruciuni UPDATE, dac se respect proprietatea de unicitate
Cheile secundare compuse admit valori NULL pentru unele din atributele lor
37
Constrngeri inter-relaii
Asocierile (relaionships) 1: N ntre dou mulimi de entiti (din modelul
Entitate-Asociere) se realizeaz n modelul relaional prin chei strine
Exemplu: Pentru a realiza asocierea 1: N dintre relaiile SECTII i ANGAJATI,
se adaug n relaia ANGAJATI cheia strin IdSectie, care reprezint
identificatorul (numrul) seciei n care lucreaz angajatul respectiv:
ANGAJATI (IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu, IdSectie)
SECTII
SECTII
ANGAJATI
Diagrama E-A
IdSectie
Nume
Buget
Productie
400000
Proiectare
300000
Cercetare
200000
Documentare
100000
ANGAJATI
IdAngajat
Nume
Prenume
DataNasterii
Adresa
Functia
Salariul
IdSectie
Ionescu
Ion
1960.01.05
Bucuresti
inginer
4000
Popa
Petre
1965.02.97
Bucuresti
tehnician
3200
Carol
Ana
1961.03.06
Bucuresti
secretara
2000
Marin
Radu
1970.03.98
Bucuresti
inginer
4000
38
Cheia strin
Fie dou relaii R1 i R2, ntre care exista o asociere cu raportul 1: N.
O cheie strin (foreign key) este o submulime FK de atribute ale relaiei R2
care refer cheia CK din relaia R1 i satisface urmtoarele condiii:
atributele cheii strine FK sunt definite pe domenii compatibile cu cele ale atributelor
cheii candidate CK a relaiei R1
valorile atributelor FK ntr-un tuplu din relaia R2, fie sunt identice cu valorile atributelor
CK ale unui tuplu oarecare din starea curent a relaiei R1, fie sunt NULL
Dou domenii sunt compatibile dac ele sunt compatibile din punct de vedere al
tipului de date i compatibile semantic (are sens s fie comparate)
n limbajul SQL verificarea domeniilor se rezum la verificarea tipurilor de date, iar
compatibiltatea semantic trebuie s fie asigurat de proiectant
Cheia strin reprezint o constrngere referenial ntre cele 2 relaii

Relaia referit (R1) relaie printe, relaia care refer (R2) relaie fiu
Cheia strin se specific n comanda CREATE TABLE sau ALTER TABLE:

[CONSTRAINT nume_constr] FOREIGN KEY (cheie_strina)
REFERENCES relaia_referita (cheie_candidata)
Exemplu:
IdAngajat
int PRIMARY KEY,
Nume
Prenume
IdSecie
int,
CONSTRAINT FK FOREIGN KEY (IdSectie) REFERENCES SECTII(IdSectie));
39
Mentinerea integritii refereniale a relaiilor (1)

Integritatea referenial (referential integrity) este proprietatea bazei de date
prin care orice cheie strin:
fie are o valoare care se regsete printre valorile cheii candidate referite
fie are valoarea NULL
Pentru meninerea integritii refereniale trebuie s fie inpuse restrictii

operaiilor de modificare a strii relaiilor (INSERT, DELETE, UPDATE)
Restriciile care se impun operaiilor de modificare a relaiilor depind de rolul
relaiei (relaie care refer, relaie referit, sau poate avea ambele roluri)
Operaia INSERT:
ntr-o relaie care nu refer alt relaie, inserarea se poate face fr restricii
ntr-o relaie care refer (care conine o cheie strin): SGBD-ul permite introducerea
unui tuplu nou numai dac: (a) valoarea cheii strine a tuplului nou este NULL sau
(b) exist o valoare a cheii referite egal cu valoarea cheii strine a tuplului nou
Operatia DELETE:
ntr-o relaie care nu este referit tergerea se poate face fr restricii
ntr-o relaie referit se admite: tergere restricionat, tergere n cascad,
anularea (SET NULL) a cheilor strine care refereau tuplul ters
tergerea restricionat interzice tergerea unui tuplu din relaia referit dac
acesta este referit de un tuplu din relaia care o refer
40
Mentinerea integritii refereniale a relaiilor (2)

tergerea n cascad permite tergerea unui tuplu din relaia referit; dac
tuplul ters era referit de unul sau mai multe tupluri, atunci se terg i acestea
din relaia care o refer; dac tuplurile terse din relaia care refer sunt, la
rndul lor referite de alte tupluri din alte relaii, atunci trebuie s fie terse i
acestea, .a.m.d.; se execut deci o tegere n cascad
Operaia UPDATE este o tergere urmat de o introducere, deci restriciile de
actualizare reprezint combinaia restriciilor de introducere i de tergere
n limbajul SQL se specific opiunile ON DELETE i ON UPDATE constrngerii
de cheie strin; valorile posibile ale acestor opiuni sunt:
RESTRICT tergerea restricionat (este valoare implicit)

CASCADE tergerea n cascad;
SET NULL anularea cheilor strine care refereau tuplul ters
NO ACTION se admit valori care nu respect integritatea relaional
Exemplu:
IdAngajat
int PRIMARY KEY,
Nume
varchar (20) NOT NULL,
........................
Sectie
int,
CONSTRAINT FK FOREIGN KEY (Sectie) REFERENCES SECTII (IdSectii) ,
ON DELETE CASCADE ON UPDATE RESTRICT);
41
Indexarea relaiilor (1)

Timpul de execuie a operatiilor asupra datelor din relaii depinde de modul de
reprezentare a mulimii de elemente (tupluri) ale relaiilor
Operaia de cutare a unui element ntr-o mulime se execut mai rapid dac
elementele mulimii sunt reprezentate printr-o colecie ordonat, cum sunt liste,
arbori, tabele de dispersie (hash table). De exemplu:
Timpul de cutare a unui element ntr-o mulime neordonat de N elemente este
proportional cu N: TC = k1 * N = O(N)
Timpul de cutare al unui element memorat ntr-o structur arbore binar de cutare
ordonat dup valoarea etichetei (cheii) de ordonare este TC = k2* log N = O(log N)
Un arbore binar ordonat complet cu d niveluri:

pe nivelul 0 are 20 = 1 nod
pe nivelul 1 are 21 = 2 noduri
pe nivelul j are 2j noduri
Nivelul 0
Nr. total noduri N = 20 + 21 + 2j + 2d-1 = 2d 1

Nivelul 2
d = log (N + 1)
Nivelul 1
1
Pentru cutare se parcurg max d pai, deci

timpul de cutare TC = k2* log N = O(log N)
42
Indexarea relaiilor (2)

Rezult c, dei o relaie nu presupune ordonarea tuplurilor sale, pentru
accelerarea operaiei de cutare (SELECT) a unui tuplu se folosesc colecii
ordonate
i celelate operaii (INSERT, UPDATE, DELETE) se execut mai rapid n
colecii ordonate
Pentru inserarea unui tuplu se verific mai nti s nu existe deja un tuplu cu aceeai
valoare a cheii
Pentru modificarea unui tuplu se caut mai nti tuplul dorit, apoi se fac modificrile
Pentru tergere se caut mai nti tuplul dorit i apoi se terge
Un index al unei relaii este o structur auxiliar, memorat n baza de date,

care permite accesul rapid la tuplurile relaiei prin ordonarea acestora
Structuri folosite n indexare: arbori binari de cutare, arbori BTREE, arbori
RTREE, tabele de dispersie (HASH) etc.
Exista dou categorii de indexuri ale unei relaii:
un index primar, care determin localizarea tuplurilor n fiierele bazei de date
zero, unul sau mai multe indexuri secundare, care nu modific localizarea tuplurilor,
dar sunt folosii pentru regsirea rapid a tuplurilor dup valorile unor atribute
43
Indexul primar (1)

Indexul primar (primary index) se definete pe cheia primar a relaiei
Fiecare element al indexului primar corespunde unui tuplu al relaiei i
elementele sunt ordonate dup valoarea cheii primar PK
De exemplu, pentru o structur arbore binar ordonat a indexului primar al unei
relaii cu ckeia primar PK i atributele (A, B, C, ...), un element (nod) Ni este
memorat la adresa Li pe hard-disk i conine:
Valoarea cheii primare a tuplului (pki), care este i eticheta de ordonare a arborelui
Valorile celorlalte atribute ale tuplului (ai, bi, ci, ...)
Adresele fiilor (Lj, Lk) (locaiile de memorare pe hard-disk a nodurilor fii)
(Li)
(pki) (ai, bi, ci, ...)
(Lj) (Lk)
(4)(Marin, .)
(2)(Popa, .)
(Lj)
(Lk)
(1)(Ionescu,..)
(6)(Ionescu,.)
(3)(Carol,...)
(5)(Ene,.)
(7)(Dobre,.)
44
Indexul primar (2)

Structura indexului primar este memorat mpreun cu tuplurile relaiei
Operaiile de interogare care se fac dup indexul primar (cheia primar) se
execut eficient, fiind o cutare ntr-o mulime ordonat dup acea valoare
Exemplu: Care sunt funcia i salariul angajatului cu cheia primara 3?
Se caut nodul arborelui care are valoarea etichetei de ordonare (care este i cheia
primar a relaiei) egal cu valoarea dat (3)
Dup gsirea nodului se extrag valorile atributelor tuplului memorat n acel nod
Sunt necesari maximum d (log N) pai de cutare (N este nr total de tupluri ale relaiei)
Operatiile de interogare care se fac dup valoarea altor atribute (dect indexul
primar) se execut mult mai ineficient, fiind o cutare ntr-o mulime neordonat
dup acea valoare
Exemplu: Care sunt funcia i salariul angajatului cu numele Dobre ?
Pentru cutare se vor parcurge pe rnd toate tuplurile relaiei (memorate n nodurile
arborelui - exist astfel de algoritmi de parcurgere) pentru a gsi tuplul (sau tuplurile)
cu valoarea atributului Nume egal cu Dobre
Sunt necesari maximum N pai (N este nr total de tupluri ale relaiei)
Pentru rezolvarea mai eficient a unor astfel de interogri se definesc indexuri

secundare pe acele atribute care intervin n clauza WHERE din interogri
45
Indexuri secundare (1)

Un index secundar pe un atribut al unei relaii (secondary index) este o
structur ordonat dup valoarea acelui atribut; un element al unui index
secundar conine:
valoarea atributului indexat (care este etichet de ordonare)
adresa (sau adresele) tuplurilor care conin acea valoare a atributului respectiv
Sunt dou categorii de indexuri secundare: unice (UNIQUE) i normale

Un index secundar UNIQUE este definit pe un atribut A (simplu sau compus) al
relaiei care ia valori unice (cum este o cheie unic - secundar sau alternativ)
Un element (nod) al indexului este compus din valoarea ai atributului indexat A i
adresa (Li) a unui singur tuplu care are acea valoare a atributului A
Dac relaia are N tupluri, indexul va avea M = N elemente
Index secundar normal (care nu este unic - nu are o denumire specific) este
definit pe un atribut A care nu ia valori unice (nu este cheie unic)
Un element (nod) al indexului este compus din valoarea ai a atributului indexat A i
lista (Li1 , Li2 , ) a adreselor (pe hard-disk) a tuplurilor ti1, ti2, care au valoarea ai
a atributului A
Dac relaia are N tupluri, indexul va avea M N elemente
Pentru o structur arbore binar a indexului, fiecare nod mai conine i adresele
nodurilor fii (stnga, dreapta) (nereprezentate n figura urmtoare)
46

Exemplu: indexul secundar (cu structur arbore binar) definit pe atributul Nume al
relaiei ANGAJATI, al crei index primar este cel dat n figura precedent
La interogarea Care sunt functia i salariul angajailor cu numele Dobre ? se
parcurge indexul secundar definit pe atributul Nume i se afl adresa unui singur tuplu
(L7)
La interogarea Care sunt functia i salariul angajatilor cu numele Ionescu ? se
parcurge indexul secundar definit pe atributul Nume i se afl adresele tuplurilor (L1 i
L6) care au valoarea atributului Nume egal cu Ionescu
Dac indexul are o structur arbore binar ordonat, se vor executa max (log N) pai
Un index secundar nu modific adresa de memorare a unui tuplu (care se afl n

indexul primar), dar conine informaii pentru gsirea rapid a unui tuplu dup
valoarea acestui index
(Ionescu) (L1, L6)
(Dobre) (L7)
(Carol) (L3)
(Ene) (L5)
(Marin) (L4)
(Popa) (L2)
47

Un index secundar se poate crea cu comanda CREATE TABLE (ca o
costrngere de tabel), cu ALTER TABLE sau cu CREATE INDEX; ex.:
CREATE [optiuni] INDEX nume_index ON nume_tabel (lista_atribute_index);
Una din opiunile care se pot introduce n CREATE INDEX este UNIQUE
n general, sistemele SGBD adaug:

Un index secundar UNIQUE pentru fiecare cheie candidat (definit prin
constrngerea UNIQUE KEY)
Un index secundar normal pentru fiecare cheie strin; un astfel de index secundar
ajut la gsirea rapid a tuturor tuplurilor asociate cu o valoare a cheii strine (Care
sunt angajaii care lucreaz n secia cu numrul (identificatorul IdSectie) 1?
n sistemele SGBD avansate (obiect-relaionale), pot exista i indexuri

secundare speciale, cum sunt
Indexuri spaiale (indexarea obiectelor reprezentate n spaiul bi sau tridimensional)
Indexuri de context (indexarea textelor)
Indexuri XML (indexarea documentelor XML)
Indexurile secundare au avantaje i dezavantaje:

Avantaje: accelereaz operaiile de interogare care se fac dup valoarea indexului
Dezavantaje: ocup spaiu de memorie i consum timp la actualizarea relaiilor
n general, se recomand utilizarea unui numr ct mai mic de indexuri

secundare, definite pe atributele care intervin cel mai frecvent n interogri
48
Capitolul 3: Interogarea bazelor de date

Limbaje de interogare
Algebra relationala si calculul relational
Operatiile pe multimi ale algebrei relationale
Reuniunea
Intersecia
Diferenta
Produsul Cartesian
Operatiile speciale ale algebrei relationale
Selectia
Proiectia
Jonctiunea
Diviziunea
Interogarea bazelor de date

Interogarea intr-o singura relatie
Interogarea in doua sau mai multe relatii
Cap. 3 - Interogarea bazelor de

date
Limbaje de interogare
Interogarea (query): operaia prin care se obin informatiile dorite dintr-o
baz de date, selectate conform unui anumit criteriu (condiie);
Limbaje de interogare: abstracte si concrete (reale - implementari in diferite
SGBD-uri)
Limbaje de interogare abstracte: algebra relationala si calculul relational
Algebra relationala (relational algebra) - const dintr-o mulime de operaii
care au ca operanzi relaii, iar rezultatul este tot o relaie
Calculul relaional (relational calculus) - bazat pe calculul predicatelor exprim o interogare definind rezultatul dorit ca expresie de calcul relaional
Calculul relational al tuplurilor foloseste variabile de tuplu (variabile
definite pe mulimea tuplurilor unei relaii)
Calculul relational al domeniilor foloseste variabile de domeniu (variabile
definite pe domenii de definiie ale atributelor)
Cele trei limbaje formale sunt echivalente din punct de vedere al interogarilor
Limbajele de interogare reale sunt definite pe baza unuia sau altuia din
limbajele de interogare abstracte, sau pe o combinaie a acestora.
De exemplu, limbajul SQL2 este n cea mai mare parte bazat pe algebra
relaional, dar mai conine i construcii derivate din calculul relaional.

date
Algebra relaional
Algebra relaional (relational algebra) - interogrile sunt expresii compuse
din operatii care au ca operanzi relatii si rezultatul este o relatie
Operatiile algebrei relationale: operatii pe multimi si operatii speciale, la care
se adauga operatia de redenumire (rename) a atributelor (E.Codd)
Operatiile relationale pe multimi acioneaz asupra relaiilor vzute ca mulimi
(de tupluri), fr a lua n consideraie compoziia fiecrui tuplu; acestea sunt:
Reuniunea
Intersecia
Diferena
Produsul cartezian
Operaiile relaionale speciale iau n consideraie compoziia tuplurilor, formate

din valori ale atributelor relaiilor; acestea sunt:
Restricia
Proiecia
Jonciunea
Diviziunea
Proprietatea de nchidere: operanzii (unul sau doi operanzi) sunt relaii,

rezultatul este o relaie; aceast proprietate permite operaii imbricate:
proiecia unei jonciuni etc.

date
Operaia de reuniune
Reuniunea (union) a dou relaii compatibile r(R) i s(S):
q = r s = { t | t r or t s}
Pentru ca r si s sa fie compatibile, trebuie ca:
r si s s aiba acelasi grad (acelasi numar de atribute)
Atributele corespondente (n ordine pozitional) s fie compatibile
Tuplurile care aparin ambelor relaii se introduc n relaia rezultat o singur

dat (nu se duplic)
Relatia rezultat are un numar de tupluri (cardinalitatea) mai mic sau egal cu
suma numerelor de tupluri ale celor doi operanzi
Exemplu:
A
rs

date
Operaiile de intersecie i diferen

Intersectia (set-intersection) a dou relaii compatibile r(R) i s(S):
q = r s = { t | t r and t s}
Exemplu:
A
1
2
1
2
3
rs
r
Diferena (set-difference) a dou relaii compatibile r(R) i s(S):
q = r - s = { t | t r and t s}
Exemplu:
B
1
2
1
2
3
B
1
1
r-s
r
Reuniunea si intersectia sunt comutative si asociative (r s = s r ;
r (s t) = (r s) t); diferenta nu este nici nici comutativa, nici asociativa

date
Operatia de produs Cartesian

Produsul Cartesian (Cartesian-Product) a dou relaii r(R) i s(S):
q = r x s = { tp | t r and p s}, Q = R S
Se presupune c multimile R si S sunt disjuncte, adica R S =
Daca atributele din R si S nu sunt disjuncte, atunci (unele):
se pot redenumi (RENAME nume_atribut AS noul_nume_atribut) sau
se pot califica cu numele relatiei careia ii apartin (folosind operatorul punct)
Tuplurile relaiei rezultat se obtin prin concatenarea valorilor atributelor fiecrui

tuplu din prima relaie cu valorile atributelor tuturor tuplurilor din a doua relaie
Relaia rezultat are numrul de tupluri (cardinalitatea) egal cu produsul
numarului de tupluri ale relatiilor operand
A B C D E
Exemplu:
C
D
E
A B
1 10 a
10 a
1 10 a
1
10 a
1 20 b
2
20 b
1 10 b
r
10 b
2 10 a
2 10 a
s
2 20 b
2 10 b
rxs
6
date
Exprimarea operatiilor pe multimi in SQL (1)

Reuniunea:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
UNION
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];
Exemplu (MySQL, Intreprindere):

SELECT Nume, Prenume, Adresa FROM FURNIZORI
UNION
SELECT Nume, Prenume, Adresa FROM CLIENTI;
Afiseaza numele tuturor furnizorilor si al clientilor, precum si adresa acestora
Intersectia:
INTERSECT
Diferenta:
MINUS

date
Exprimarea operatiilor pe multimi in SQL (2)

Produsul Cartesian:
SELECT * from R, S;
SELECT lista_col_R, lista_col_S from R, S;
Exemplu (MySQL, Intreprindere):
SELECT * FROM ANGAJATI, SECTII;
SELECT IdAngajat, Nume, Prenume, DataNasterii, Adresa, Functia,
Salariu, ANGAJATI.IdSectie, SECTII.IdSectie, Denumire, Buget
FROM ANGAJATI, SECTII;
Produsul Cartesian este implementat in toate SGBD-urile

(instructiunea SQL SELECT)
In sistemul Oracle sunt implementate toate operatiile pe multimi
In alte SGBD-uri nu sunt implementate toate operaiile pe mulimi;
in SQL Server 2000 si in MySQL 5.0 nu sunt implementate operaiile
INTERSECT i MINUS

date
Operaia de selecie
Seleca (sau restricia select, restriction) ntr-o relatie r(R) - definita astfel:
p(r) = {t | t r and p(t)}
unde p, predicatul selectiei, este o expresie logic compus din termeni conectati prin
operatorii and, or not (i, eventual, paranteze)
Fiecare termen este o valoare logic obinut ca rezultat al unei operaii de

comparaie de forma:
<atribut> op <atribut> sau
<atribut> op <constanta>, unde
op este un operator de comparatie aritmetic (=, , >, . <. ) sau special(IS NULL etc.)
Tuplul t este selectat (introdus in rezultat) daca p(t) = TRUE
n limbajul SQL:
SELECT * FROM tabel WHERE p;
n termenii folosii n limbajul SQL, restricia selecteaz o parte din liniile tabelului
operand
Exemple (MySQL - WORLD):

SELECT * FROM city where CountryCode=ROM;
SELECT * FROM country WHERE Continent='Europe';
SELECT * FROM country WHERE Continent='Europe' and Population > 10000000;

date
Operatia de proiecie
Proiectia (project) pe atributele A1, A2, .. Ak intr-o relatie r(R) se noteaz:
A1, A2, Ak (r), unde A1 R, A2 R, Ak R
Rezultatul este o relatie cu k atribute, cele din lista data
Daca {A1, A2, Ak} nu contine o supercheie, pot sa apara tupluri duplicat;
teoretic, tuplurile duplicat se elimina, dat fiind ca rezultatul este o multime
Exemplu:
10
20
30
40
A,C (r)
In limbajul SQL proiectia se exprima astfel:

SELECT DISTINCT A1, A2, Ak FROM R
Daca nu se introduce parametrul DISTINCT, nu se elimina tuplurile duplicat
Exemplu (MySQL, WORLD):

SELECT DISTINCT CountryCode FROM City;

date
10
Operaia de jonciune natural (1)

Jonciunea natural (natural join) combin tuplurile din doua relatii
Fie multimile de atribute: A = {A1,A2,...Am} , B= {B1,B2,...Bn}, C={C1,C2,Ck}
si doua relatii r(R) si s(S), unde:
R ={A, B}, S = {B, C}
deci atributele R S = B = {B1, B2,...Bn} sunt comune celor dou relaii
Jonciunea natural este o relatie q = r s, care se obine n felul urmtor:

se calculeaz produsul cartesian al celor doua relatii: p = r x s, P = {A, R.B, S.B, C};
din tuplurile produsului cartesian se selecteza acele tupluri care au valori egale
pentru atributele comune (B1, B2,...Bn): R.B = S.B, adic R.B1=S.B1, R.B2=S.B2,..
se face proiectia rezultatului pe multimea de atribute R S = {A, B, C}
Schema relatiei rezultat este Q = R S = {A, B, C}

q = r s = A,B,C (r.B1=s.B1 AND r.B2=s.B2 AND r.Bn = s.Bn) (r x s)
Atributele comune R.B si S.B trebuie s fie compatibile n cele doua relatii;
dac sunt compatibile, ele se consider identice chiar dac au denumiri
diferite, si n reuniunea atributelor R S se introduc o singur dat
Cazul cel mai frecvent de jonctiune naturala: intre doua relatii asociate (1: N),
atributul comun fiind cheia strain cheia primar (candidat) referit

date
11
Operatia de jonctiune naturala (2)

Exemplul 1: r s = A,B,C,D,E (r.D = s.D ) (r x s)
A
1
2
4
1
2
a
a
b
a
b
r s
s
r
In SQL trebuie sa fie introduse explicit lista atributelor rezultatului si conditiile
de egalitate ale atributelor comune:
1
2
4
1
2
a
a
b
a
b
a
b
c
d
e
SELECT A,B,C,R.D,E FROM R, S WHERE R.D = S.D;
Exemplul 2: ANGAJATI SECTII; cheia straina: ANGAJATI.IdSectie

SELECT IdAngajat, ANGAJATI.Nume, Prenume, DataNasterii, Adresa, Salariu,
ANGAJATI.IdSectie, SECTII.Nume, Buget FROM ANGAJATI, SECTII
WHERE ANGAJATI.IdSectie=SECTII.IdSectie;
Exemplul 3:(MySQL-WORLD) city country; cheia straina: city.countryCode

SELECT ID, city.Name Oras, CountryCode 'Cod Tara', city.Population, country.Name
Tara, Continent from city, country where city.countryCode=country.CODE order by
country.Name;
Daca nu se afiseaza toate atributele jonciunii, nseamna ca s-a combinat cu o proiecie

date
12
Jonciuni interne i externe

Jonciunea natural se mai numete i jonciune intern i se mai poate
exprima in SQL cu cuvintele cheie INNER JOIN
Exemplu de jonciune (combinat cu o proiecie si o selectie)(MySQL world)
SELECT city.Name Oras, Code 'Cod Tara', country.Name Tara, Continent
FROM city INNER JOIN country ON CountryCode=Code
WHERE Continent='Antarctica' OR Continent = 'Europe' ORDER BY Continent;
Jonciunea extern introduce n plus toate liniile care exit n prima relaie
(pentru LEFT OUTER JOIN) sau n cea de-a doua relaie (pentru RIGHT
OUTER JOIN) i pentru care nu exist linii n ceallalt relaie care s
ndeplineasc condiia de join; exemplu:
SELECT city.Name Oras, Code 'Cod Tara', country.Name Tara, Continent
FROM city RIGHT OUTER JOIN country ON CountryCode=Code
WHERE Continent='Antarctica' OR Continent = 'Europe' ORDER BY Continent;
Se vor afia si rile care nu au nici un oras nscris n tabelul city.

date
13
Operaia de diviziune
Fie relaiile r(R) si s(S), unde:
R = {A, B} unde A={A1,A2,..Am}, B={ B1,B2,..Bn}
S = {B}
Relaia q = r s are schema Q = R S = {A} si:

r s = { t | t R-S (r) u s ( tu r ) }
unde tu inseamna concatenarea tuplurilor t si u
n limbajul SQL, diviziunea se exprim printr-o instruciune SELECT,

introducnd explicit toate conditiile impuse valorilor atributelor
Exemplu:
A
B
A B
1
2
3
1
2
1
3
1
2
rs
r

date
14
Concluzii: operatiile algebrei relationale

Algebra relaional este o colecie de operaii asupra relaiilor
Cele opt operaii propuse de E.F.Codd nu constituie o mulime minim de
operaii ale algebrei relaionale
Mulimea minim de operaii ale algebrei relaionale consta din cinci operaii
primitive, pe baza crora se poate construi orice expresie de algebra
relaionala:
Reuniunea
Diferena
Produsul Cartesian
Restricia (selectia)
Proiecia
Celelalte operaii se pot exprima prin intermediul acestora:

Intersecia se poate exprima prin expresia: R S = R (R S);
Jonciunea este o proiecie a unei restricii a produsului cartezian al relaiilor;
Diviziunea este o proiecie a unei restricii asupra relaiei demprit
Si celelalte trei operaii sunt deosebit de utile n formularea interogrilor,

astfel nct algebra relaional a pstrat toate cele opt operaii propuse de
E.F.Codd, la care s-a adugat operaia de redenumire a atributelor

date
15
Formularea interogarilor
Interogarea este operatia prin care se obtin informaiile dorite (care
indeplinesc o anumita conditie) dintr-o baz de date. O interogare:
se formuleaza mai intai n limbaj natural,
apoi se exprima ntr-un limbaj abstract de interogare (algebra relaional sau
calculul relaional),
se transpune n limbajul de interogare al SGBD-ului folosit (ex., limbajul SQL),
iar aplicatia client transmite SGBD-ului instructiunea (sau instructiunile) obtinute
Sistemul SGBD prelucreaza programul interogarii n mai multe faze:
analiza lexical, sintactic i semantic

optimizarea interogarii
generarea codului
executia si returnarea rezultatului
n algebra relaional o interogare se formuleaz printr-o expresie care

defineste urmtoarele elemente:
Lista atributelor relaiei rezultat, care se numesc atribute de proiecie;
Lista relaiilor din care se extrag informaiile
Condiiile pe care trebuie s le ndeplineasc tuplurile relaiei rezultat.
Sunt posibile dou situaii:

interogri care se rezolv n cadrul unei singure relaii
interogri care se rezolv folosind dou sau mai multe relaii ale bazei de date

date
16
Interogri ntr-o singur relaie

Interogare in relatia r(R):
Expresia de algebra relationala: q = lista_atribute p(r)
Instructiunea SQL: SELECT lista_atribute FROM R WHERE p;
Exemplul 1: Fie relaia ANGAJATI i interogarea: Care sunt numele i

prenumele angajailor care au un salariu mai mare sau egal cu 2000?.
Expresia de algebr relaional: q = Nume, Prenume Salariu >= 2000 (ANGAJATI)
Instruciunea SQL:
SELECT Nume, Prenume FROM ANGAJATI WHERE Salariu >= 2000;
Exemplul 2: (MySQL - WORLD): Care sunt numele si populatia oraselor din

tara cu codul ROM ?
Expresia de algebr relaional: q = Name, Population CountryCode=ROM (city)
Instructiunea SQL:
SELECT Name, Population FROM city WHERE CountryCode=ROM';
Exemplul 3: Fie relaia ANGAJATI i interogarea: Care sunt numele,

prenumele si adresa angajailor care lucreaza in sectia numarul 1?.
Expresia de algebr relaional: q = Nume, Prenume, Adresa IdSectie = 1 (ANGAJATI)
Instructiunea SQL:
SELECT Nume, Prenume, Adresa FROM ANGAJATI WHERE IdSectie=1;

date
17
Interogri n dou sau mai multe relaii

Daca atributele de proiecie i atributele din condiia de interogare nu aparin
unei singure relaii, pentru rezolvarea interogrii trebuie s fie folosite toate
acele relaiile care, mpreun, conin atributele i asocierile necesare
Conceptual, o astfel de interogare se rezolv astfel:
se construieste mai nti o relaie care s conin toate atributele implicate prin
combinarea relaiilor necesare, folosind operaii de produs cartezian sau jonciuni;
in relatia obtinuta se aplica o selectie (restrictie) (cu condiia de interogare p);
apoi se face proiecia (pe atributele de proiecie).
Expresia generala de algebra relationala a interogarii este:

q = lista_atribute p(r x s x t...)
Daca intre relatiile din produsul cartesian exista atribute comune care trebuie sa
aiba valori egale (de regula, perechile cheie strin - cheie candidata) atunci se
pot face operaii de jonciune:
q = lista_atribute p1 AND conditii-join(r x s x t...) = lista_atribute p1 (r s t...)
O interogare poate conine una sau mai multe subinterogri

In limbajul SQL, o interogare se exprima prin instructiuni SELECT in care:
Clauza WHERE combina atat conditiile impuse valorilor atributelor cat si conditiile de
jonctiuni
Jonctiunile se pot specifica i n clauza FROM (cu INNER JOIN, OUTER JOIN)

date
18
Exemplu: interogare n dou relaii

Fie interogarea: Care sunt numele, prenumele, funcia, salariul i denumirea
seciei n care lucreaz angajaii?
Expresia de algebr relaional este:
q = Nume, Prenume,Salariu, Denumire (ANGAJATI SECTII)
Instructiunea SQL corespunzatoare acestei interogri:
SELECT Nume, Prenume, Salariul, Denumire FROM ANGAJATI, SECTII
WHERE SECTII.IdSectie = ANGAJATI.IdSectie
Se efectueaza o navigare n baza de date, pe atributul comun (IdSectie)

ANGAJATI
IdAngajat
Nume
Prenume
DataNasterii
Adresa
Salariu
IdSectie
SECTII
Buget
Denumire IdSectie
Fie interogarea: Care sunt numele, prenumele, funcia i salariul angajailor

care lucreaz n secia cu denumirea Productie?
q = Nume, Prenume, Functia, Salariu Denumire= Productie (ANGAJATI SECTII)
SELECT Nume, Prenume, Functia, Salariu FROM ANGAJATI, SECTII
WHERE SECTII.IdSectie = ANGAJATI.IdSectie AND Denumire = Productie;

date
19
Exemplu: interogare in trei relatii (1)

Fie urmatoarele relatii asociate din baza de date SAKILA (MySQL):
FILM (film_id, title, description, release_year, ....)
ACTOR (actor_id, first_name, last_name, last_update)
FILM_ACTOR (film_id, actor_id, last_update)
FILM
FILM_ACTOR
ACTOR
Interogarea: n ce filme au jucat fiecare din actorii din baza de date sakila ?
q = first_name, last_name, title (film film_actor actor)
Instructiunea SQL:
SELECT first_name, last_name, title
FROM FILM, FILM_ACTOR, ACTOR
WHERE FILM.film_id = FILM_ACTOR.film_id
AND ACTOR.actor_id = FILM_ACTOR.actor_id ORDER BY FILM.film_id;
Se poate folosi i sintaxa INNER JOIN:

SELECT first_name, last_name, title
FROM (FILM INNER JOIN FILM_ACTOR ON FILM.film_id=FILM_ACTOR.film_id)
INNER JOIN ACTOR ON ACTOR.actor_id = FILM_ACTOR.actor_id ORDER BY.... ;

date
20
Exemplu: interogare in trei relatii (2)

date
21
Subinterogri
Subinterogrile sunt operaii care determin diferite date (valori scalare,
tabele rezultat, numr de elemete etc.) folosite n interogarea de baz
Subinterogrile pot conine la rndul lor alte subinterogri
Exemplul 1: Care sunt angajaii (nume, prenume, adresa) care lucreaz
n aceeai secie cu angajatul cu numele Ionescu i prenumele Ion?
Se determin printr-o subinterogare n ce secie lucreaz angajaul dat
Se selecteaz toi angajaii din acea secie:
SELECT Nume, Prenume, Adresa FROM ANGAJATI
WHERE IdSectie = (SELECT IdSectie FROM ANGAJATI WHERE Nume = 'Ionescu'
AND Prenume = 'Ion');
Exemplul 2: Care sunt numele, prenumele, denumirea seciei i salariul

angajailor care au salariul egal cu salariul maxim pe una din secii:
Se determin printr-o subinterogare tabelul cu valori maxime ale salariului n
fiecare secie
Se selectez angajaii care au salariul n mulimea salariilor maxime pe sectii:
SELECT Nume, Prenume, Salariul, Denumire FROM ANGAJATI INNER JOIN SECTII ON
ANGAJATI.IdSectie=Sectii.IdSectie
WHERE Salariul IN (SELECT MAX(Salariul) FROM ANGAJATI Group By IdSectie);

date
22

date
23
Capitolul 4: Dezvoltarea sistemelor de baze de date

Fazele de dezvoltare a bazelor de date
Colectarea si analiza cerintelor
Proiectarea bazelor de date
Proiectarea conceptuala a bazelor de date

Alegerea unui SGBD
Proiectarea logica a bazelor de date
Proiectarea fizica a bazelor de date
Implementarea bazelor de date
Dezvoltarea aplicatiilor de baze de date

Limbaje procedurale de extensie a limbajului SQL
Limbajul Transact-SQL
Cursoare, proceduri stocate, functii, triggere
Limbajul SQL integrat (Embeded SQL)

Interfete de programare a aplicatiilor de baze de date
Interfata ODBC
Interfata JDBC
Cap. 4 - Dezvoltarea sistemelor

de baze de date
Dezvoltarea sistemelor de baze de date (1)

Sistemul informatic (information system) al unei organizatii include toate
resursele acelei organizaii care sunt implicate n colectarea, administrarea,
utilizarea i diseminarea informaiilor
Sistemele informatice:
Pana in anii 1970 erau sisteme de fiiere (pe disc sau band magnetic)
Actual se folosesc sisteme de baze de date, care permit gestionarea unor
volume de date mari ntr-un timp redus, cu protecia si securitatea datelor
Fazele de dezvoltare a sistemelor de baze de date:

Analiza i definirea sistemului: definirea scopului sistemului de baze de date, a
utilizatorilor i a aplicaiilor acestuia
Proiectarea sistemului: n aceast etap se realizeaz proiectul logic i proiectul
fizic al sistemului, pentru un anumit SGBD ales
Implementarea: este etapa n care se scriu definiiile obiectelor bazei de date
(tabele, vederi, etc.) i se implementeaz aplicaiile software
Testarea i validarea: noul sistem de baze de date este testat i validat ct mai
riguros posibil
n mod tipic, dezvoltarea unui sistem de baze de date const din:

dezvoltarea structurii si a continutului bazei de date
dezvoltarea modulelor de prelucrare a datelor

de baze de date
Dezvoltarea sistemelor de baze de date (2)

Fazele importante de dezvoltare a sistemelor de baze de date sunt:
Faza 1: Colectarea i
analiza cerinelor
Faza 2: Proiectare
conceptual
Cerine de date
Proiectarea schemei conceptuale i a schemelor

conceptuale externe (independente de SGBD)
Cerine de
prelucrare
Proiectarea conceptual a
tranzaciilor (indep. de SGBD)
Faza 3: Alegerea
unui SGBD
Faza 4: Proiectare
logic
Proiectarea schemei logice i a schemelor

logice externe (dependente de SGBD)
Faza 5: Proiectare
fizic
Proiectarea schemei interne
Faza 6: Implementare
Faza 7: Testare si validare

Instruciuni de descriere a datelor
Testarea datelor
de baze de date
Proiectarea tranzaciilor
(dependente de SGBD)
Implementarea tranzaciilor
Testarea tranzactiilor
3
Colectarea si analiza cerintelor

nainte de a se proiecta efectiv o baz de date (in cadrul unui sistem
informatic sistem de baze de date), este necesar s se cunoasc:
ce rezultate se ateapt utilizatorii poteniali s obin de la baza de date
respectiv
ce informaii primare sunt disponibile pentru acestea
ce aplicaii se vor executa (aplicaii de gestiune a stocurilor, aplicaii contabile,
aplicaii de urmrire a consumurilor, aplicaii de salarizare, etc.).
Toate acestea sunt informaii slab structurate, n general n limbaj natural,

pe baza crora se pot construi diagrame, tabele, grafice etc., manual sau
folosind diferite instrumente software de proiectare
Dar din aceste informatii trebuie sa fie extrase date precise de proiectare a
bazelor de date si a aplicatiilor
Aceast faz este puternic consumatoare de timp, dar este crucial pentru
succesul sistemului informatic

de baze de date
Proiectarea conceptual a bazelor de date

Proiectarea conceptual a bazei de date:
Proiectarea schemei conceptuale a bazei de date
Proiectarea schemelor conceptuale externe (vederi ale urilizatorilor)
Proiectarea conceptual a tranzactiilor
Proiectul conceptual este independent de modelul de date i de SGBD i

reprezint o descriere principial i stabil a bazei de date, care poate fi utilizat
pentru particularizarea pentru orice model de date sau SGBD
Moduri de proiectare conceptual:
Proiectare descendenta (up-bottom) : se definete diagrama E-A, pe baza tipurilor de
entitati si a asocierilor dintre acestea
Proiectare ascendenta (bottom-up): se porneste de la o schem conceptual
universal (care conine toate atributele din baza de date), care se rafineaz (se
mparte n relaii)

de baze de date
Exemplu: proiectarea conceptual a unei baze de date

Baza de date INTREPRINDERE cu multimile de entitati puternice:
SECTII(Nume,Buget)
ANGAJATI(Nume, Prenume, DataNasterii, Adresa, Functie, Salariu)
PROIECTE(Denumire,Termen, Buget)
PRODUSE(Denumire, Descriere)
COMPONENTE(Denumire, Descriere)
FURNIZORI(Nume,Prenume,Adresa) ; CLIENTI(Nume, Prenume, Adresa)
Diagrama E-A:
SECTII
1
COMPONENTE
PROIECTE
COMPOZITII
ACTIVITATI
ACHIZITII
ANGAJATI
PRODUSE
N
VANZARI
N
DEPENDENTI
INGINERI
SECRETARE
FURNIZORI

de baze de date
M
N
CLIENTI
6
Alegerea unui SGBD

Factori pentru alegerea unui SGBD: tehnici, economici i administrativi
Factorii tehnici:
Modelul de date (ierarhic, reea, relaional, obiect-orientat, obiect-relaional)
Capacitatea de stocare a datelor
Posibilitile de control al concurenei i de refacere a datelor
Configuraia hardware-software necesar
Cerine de dezvoltare a programelor de aplicaii (limbaje, compilatoare etc.)
Factorii economici i administrativi:

Costul de achiziie a software-ului, care include costul de baz, la care se adaug
diferite opiuni (opiuni de salvare-refacere, documentaie, limbaje i interfee de
programare, drivere, etc.)
Costul de ntreinere, pentru a obine serviciul furnizorului de meninere la zi a
versiunii SGBD.
Costul de pregtire a personalului se refer la cursurile care se organizeaz pentru
persoanele care se ocup cu ntreinerea i operarea sistemului
Cunotinele de programare a personalului ntr-un anumit SGBD
Beneficiile achiziionrii unui anumit SGBD nu sunt uor de apreciat sau de

msurat, dar analiza raportului cost-performane poate da o imagine a
rezultatelor obinute

de baze de date
Proiectarea logic a bazelor de date

Se porneste de la schema conceptual i schemele conceptuale externe
independente de SGBD (diagrama E-A), si se realizeaz schema logica
(diagrama logica) si schemele logice externe pentru sistemul SGBD ales
Proiectarea logic poate fi realizat n dou subfaze:
Transpunerea schemei conceptuale n schem logic a modelului de date dorit, dar
independent de un anumit SGBD
Rafinarea schemei logice i a schemelor logice externe pentru un anumit SGBD
ales (modul de generare a cheilor primare, definirea constrngerilor, etc.)
Transpunerea modelului Entitate-Asociere (diagrama E-A) n model relaional:

Proiectarea relaiilor corespunztoare mulimilor de entiti din diagrama E-A
Proiectarea asocierilor; asocierile se pot reprezenta prin chei strine sau prin relaii
de asociere; acestea sunt relaii suplimentare care se adaug n schema
conceptual a bazei de date relaionale pentru a reprezenta asocierile M:N
In mod frecvent, etapele de proiectare conceptuala si proiectare logica (cu cele

dou subfaze) se efectueaza impreuna, proiectand direct schema (diagrama)
logica a bazei de date cu ajutorul toolset-urilor de dezvoltare oferite de SGBDul utilizat

de baze de date
Diagrama logic a bazei de date

INTREPRINDERE (1)
Dezvoltata in Microsoft Access

de baze de date
Diagrama logic a bazei de date

INTREPRINDERE (2)
Dezvoltata in MySQL Workbench

de baze de date
10
Proiectarea relatiilor
Mulimile de entiti puternice (normale) din diagrama E-A devin relaii:
Numele fiecrei relaii trebuie s fie unic n baza de date
Atributele relatiei corespund atributelor entitilor din multimea de entitati data
Cheia primar se definete:
fie ca o cheie primara natural (combinaie de atribute care definesc n mod unic un tuplu)
fie ca o cheie primar artificial
De exemplu, n relaiile ANGAJATI, SECTII, PROIECTE, COMPONENTE, PRODUSE,
FURNIZORI, CLIENTI s-a adugat cte o cheie primar artificial (IdAngajat, IdSectie etc.)
Mulimile de entiti slabe din diagrama E-A devin relaii aflate n asociere N:1
cu relaia corespunztoare mulimii de entiti de care acestea depind
Pentru realizarea acestei asocieri, n relaia dependent se adaug o cheie strin
care refer cheia primar a relaiei puternice referite; de exemplu: cheia straina
dAngajat in introdusa in relatia DEPENDENTI . De ex:
DEPENDENTI( IdAngajat, Nume, Prenume, DataNasterii, GradRudenie)
Cheia primar a relaiei dependente poate fi:

o combinaie format din atributul cheie strin i alte atribute care asigur posibilitatea de
identificare unic a unui tuplu sau poate fi o cheie artificial. De ex: (IdAngajat, Nume,
Prenume )
sau o cheie primara artificiala (de ex. idDependenti)

de baze de date
11
Proiectarea asocierilor (1)

Asocierea binar 1: N dintre dou mulimi de entiti puternice se
realizeaza prin intermediul unei chei strine n a doua relaie (cea cu
multiplicitatea N a asocierii) care refer cheia primar din prima relaie
De exemplu, asocierea 1:N ntre relaiile SECTII ANGAJATI se realizeaz prin
cheia strin IdSecie din relatia ANGAJATI
Asocierea binar 1: N intre relaia corespunztoare unei mulimi de entiti

puternice si relatia corespunztoare unei mulimi de entiti slabe se
realizeaza la fel, printr-o cheie straina in relatia multimii de entitati slabe
Asocierea binar M:N dintre dou mulimi de entiti se realizeaza cu o
noua relaie, numit relaie de asociere
Aceasta are rapoartele de multiplicitate M :1, respectiv N :1 cu fiecare din
cele dou relaii date, prin intermediul a dou chei strine
Cheia primar a unei relaii de asociere poate fi:
o cheie primara artificial
sau poate fi compus din cheile strine, mpreun cu alte atribute ale relaiei
Exemplu: asocierea M:N dintre relaiile COMPONENTE-PRODUSE se

realizeaza cu o relaie de asociere, numit COMPOZITII
Relatia COMPOZITII contine cheile strine IdComponenta i IdProdus
Cheia primar a relaiei COMPOZITII poate fi compus din cheile strine
IdComponenta i IdProdus sau poate fi o cheie artificiala (IdCompozitii)

de baze de date
12

Asocierea binar 1:1 ntre dou mulimi de entiti puternice se poate
transpune n modelul relaional n dou moduri:
fie prin intermediul unei chei strine (caz particular al asocierii 1:N),
fie printr-o relaie de asociere (caz particular al unei asocierii M:N).
Exemplu: intre relaiile SOTI, SOTII, se realizeaza o asociere 1:1 cu o cheie

straina introdusa intr-una dintre relatii:
SOTI (IdSoti, Nume, Prenume, DataNasterii, Adresa)
SOTII (IdSotii,Nume, Prenume, DataNasterii, Adresa, IdSoti)
Realizarea asocierii 1:1 ntre dou relaii folosind o relatie de asociere

De exemplu: CASATORII(IdSot, IdSotie, DataCasatoriei)
Asocierea binar 1:1 dintre o mulime de entiti de subtip i mulimea de

entiti supertip este tot o asociere1:1 ntre relaiile corespunztoare
Se realizeaza prin definirea n relaia corespunztoare subtipului de entitati a
unei chei strine, care este n acelai timp i cheie primar
De exemplu: INGINERI(IdAngajat, Specialiatea)
Exemple de date in tabele asociate


de baze de date
13

Asocierea multipl M:N:P:. se realizeaz la fel ca asocierea binar, prin
intermediul unei noi relaii care se afl n asociere M:1, N:1, P:1, etc, cu fiecare
din relaiile date.
Pentru aceasta, in relatia de asociere se introduc chei straine care refera
relatiile care se asociaza, fiecare cheie strin referind cheia primar dintr-una
din relaiile asociate.
Cheia primar a unei relaii de asociere multipl poate fi:
o cheie primara artificial
sau poate fi compus din toate cheile strine, eventual mpreun cu alte atribute
De exemplu: asocierea ntre relaiile COMPONENTE, FURNIZORI, ANGAJATI se
realizeaza prin relatia ACHIZITII (IdComponenta, IdFurnizor, IdAngajat, Data,
NrComponente, PretUnitar)
In concluzie, n modelul relaional toate asocierile se realizeaz prin chei strine

Proiectare directa (forward engineering): se proiecteaza schema logica, se
exporta un script, care se poate executa si se obtine baza de date
Proiectare inversa (reverse engineering): se creeaza baza de date (de
exemplu, in Msql Query Browser), se genereaza scriptul (cu comanda
mysqldump u root p database_name > script_name.sql), se importa scriptul
(de ex. in Msql Workbench), care va desena diagrama logica a bazei de date

de baze de date
14
Proiectarea relatiilor normalizate in prima

forma normala
O relaie este normalizat n prima form normal (FN1) dac fiecare
atribut ia numai valori atomice i scalare din domeniul su de definiie.
O situaie frecvent ntlnit este aceea n care un atribut poate lua mai
multe valori pentru fiecare entitate
De exemplu, n mulimea de entiti PERSOANE (Nume, Prenume, Adresa,
NrTelefon) atributul NrTelefon poate lua mai multe valori (numrul telefonului de
acas, al telefonului de la birou, al telefonului mobil, etc)
Relaia n care un atribut poate avea valori multiple (un vector de valori)
este o relaie nenormalizat, care nu este admis de SGBD relaionale
Transformarea unei relaii nenormalizate n relaie normalizat n prima
forma normal (FN1):
se nlocuiete atributul care ar putea avea valori multiple cu cte un atribut
pentru fiecare din posibilitile existente: Exemplu: PERSOANE (IdPersoana,
Nume, Prenume, Adresa,TelefonAcasa, TelefonBirou, TelefonMobil)
se nlocuiete atributul care ar putea avea valori multiple cu o nou relaie care
refer relaia iniial printr-o cheie strin. Exemplu: PERSOANE(IdPersoana,
Nume, Prenume, Adresa), TELEFOANE(NrTelefon, IdPersoana, Descriere)
Exemple de date in tabele cu diferite tipuri de asocieri


de baze de date
15
Proiectarea fizica a bazelor de date

Fiecare SGBD ofer o varietate de opiuni de organizare a fiierelor i a
modului de acces la datele stocate:
indexuri
tipuri de fisiere
gruparea nregistrrilor corelate n aceleai blocuri pe disc (clustering)
Proiectarea fizic a bazei de date este procesul de alegere a acestor

structuri de memorare i de acces la fiierele bazei de date, pentru a obine
performane ct mai bune pentru SGBD-ul ales, pentru ct mai multe din
aplicaiile proiectate
Parametrii generali de alegere a opiunilor proiectului fizic al bazei de date:
Timpul de rspuns: intervalul de timp dintre lansarea n execuie a unei tranzacii
i primirea rspunsului la acea tranzacii
Utilizarea spaiului de memorare: dimensiunea spaiului pe disc utilizat de
fiierele bazei de date i de structurile de acces la date
Capacitatea tranzacional (transaction throughput): numrul mediu de tranzacii
care pot fi prelucrate pe minut de ctre sistemul de baze de date

de baze de date
16
Implementarea bazelor de date

n faza de implementare a bazelor de date relaionale:
Se creeaz obiectele principale ale bazei de date (tabele, vederi, indexuri), pe
baza proiectului logic i a proiectului fizic, folosind limbajul de descriere a datelor
(LDD) oferit de sistemul SGBD ales, sau toolset-uri grafice (de ex. table editor)
sau prin executia scriptului generat de un toolset de proiectare
Se implementeaz procedurile care asigur verificarea i forarea tuturor
constrngerilor explicite (aseriuni, dependene de date care nu sunt determinate
de chei ale relaiilor), a cror previziune i documentare a fost realizat n faza
de proiectare logic a bazei de date
Se populeaza baza de date cu informatii obinute prin conversia unor date
existente sub form de fiiere sau introduse direct n tabele
Tot n aceast faz programatorii de aplicaii implementeaz, pe baza

specificaiilor conceptuale ale tranzaciilor, programele de aplicaii, n diferite
tehnologii de programare disponibile (limbaje procedurale de extensie a
limbajului SQL, limbajul SQL integrat, interfee i biblioteci de programare)
Dup crearea i popularea bazei de date i implementarea programelor de
aplicaii se poate trece la etapa de testare si operare a sistemului de baze
de date, n paralel cu monitorizarea i ntreinerea acestuia

de baze de date
17
Dezvoltarea aplicatiilor de baze de date

Aplicaiile de baze asigura:
interfaa (grafic) cu utilizatorii
implementarea algoritmilor de calcul necesari
interfaa cu sistemele de gestiune a bazelor de date
Aplicatie de baza
de date
Utilizatori
Limbajul SQL integrat

(Embeded SQL)
Interfete de
programare a
aplicatiilor (API)
Instr. SQL
SGBD
Limbajul SQL
Rezultate
Extensii procedurale
ale limbajului SQL
Limbajul SQL, folosit in SGBD-uri este un limbaj neprocedural, adica nu

prevede instruciuni de control al ordinii de execuie a operaiilor
De aceea SGBD-urile mai folosesc si extensii procedurale a limbajului SQL:
PL/SQL in sistemele Oracle, PL/PLGSQL in sistemele PostGreSQL
Transact-SQL in sistemele Microsoft SQL Server
Extensie SQL in MySQL (asemanatoare cu Transact SQL) etc.
Aplicatiile de baze de date folosesc:

Limbajul SQL integrat intr-un limbaj de nivel inalt (Embeded SQL)
Interfete de programare a aplicatiilor (API) (call level interface)

de baze de date
18
Limbaje procedurale de extensie a SQL

Extensiile procedurale ale limbajului SQL definesc:
Variabile, instructiuni pentru controlul ordinii de execuie (bucle while, instruciuni
condiionale if etc.), instruciuni SQL extinse
ofera suport de crearea cursoarelor, a procedurilor stocate, a funciilor definite de
utilizator i a declanatorilor (triggere)
Variabilele sunt folosite pentru stocarea in memorie a unor valori care pot fi
testate sau modificate i pot fi folosite pt transferul datelor ctre i de la tabele
Variabilele locale au ca domeniu de definiie blocul, procedura, functia sau
trigger-ul n care au fost declarate
Un bloc este un grup de instructiuni delimitat prin instructiunile: BEGIN ... END;
un bloc este considerat o instructiune compusa
O variabil local se declar si se initializeaza diferit de la un SGBD la altul. ex:
in Transact SQL:
DECLARE @contor INT
in PL/SQL (Oracle): DECLARE CONTOR := 1;
in MySQL:
DECLARE contor INT;
SELECT @contor = 0
SET contor = 0;
Ordinea de execuie a instruciunilor este controlat prin instruciuni ca:

BEGIN...END
GOTO
IF...ELSE
RETURN
REPEAT...UNTIL
WHILE
BREAK
CONTINUE
FOR

de baze de date
19
Instructiuni SQL extinse

Extensiile procedurale definesc clauze suplimentare in instructiunile SQL,
astfel nct acestea s poat fi folosite n combinaie cu variabilele locale
De exemplu - instruciunea SELECT prin care se incarca valori ale unor
atribute selectate din baza de date in variabile locale:
In Transact-SQL:
In PL/SQL (Oracle):
In MySQL:
SELECT @var1 = col1, @var2 = col2, ... @varn = coln

FROM lista_tabele WHERE conditie
SELECT lista_coloane INTO lista_variabile
FROM lista_tabele [WHERE conditie] [optiuni]
SELECT lista_coloane INTO lista_variabile
FROM lista_tabele [WHERE conditie] [optiuni]
Astfel de instruciuni sunt utile pentru interogrile care returneaz o singur

linie, deoarece variabilele locale sunt setate cu valorile atributelor din prima
linie a rezultatului, iar valorile din celelalte linii se pierd. De ex. (in MySQL):
DECLARE id_angajat int; DECLARE s_nume, s_prenume varchar(20);
SET id_angajat = 5;
SELECT Nume, Prenume INTO s_nume, s_prenume
FROM ANGAJATI WHERE IdAngajat = id_angajat
Atunci cnd o interogare returneaz o mulime de linii, se foloseste un cursor

Variabilele locale mai pot fi folosite n clauza WHERE a instructiunii SELECT
precum si in instructiunile INSERT sau UPDATE (ca valori introduse)

de baze de date
20
Proceduri stocate
O procedur stocat (stored procedure) este o procedur care
implementeaz o parte din algoritmii de calcul ai aplicaiilor i care este
memorat in baza de date, la fel ca i alte obiecte ale bazei de date
Procedurile stocate se definesc folosind extensiile procedurale ale SQL:
In Transact-SQL: CREATE PROCEDURE nume_proc [parametri] AS instructiune
In PL/SQL (Oracle): CREATE PROCEDURE nume_proc [parametri] AS instructiune
In MySQL: CREATE PROCEDURE nume_proc [parametri] instructiune_compusa
Parametrii pot fi de intrare (IN), de iesire (OUT) sau de intrare-iesire

(INOUT); apelul unei proceduri stocate de ctre un client (aplicaie) produce
execuia de catre SGBD a tuturor instruciunilor procedurii i returnarea
rezultatrlor in parametrii OUT si INOUT
Avantaje - imbunatatirea performantelor sistemului prin:
Scaderea comunicaiei ntre aplicaie i serverul bazei de date
Scaderea timpului de execuie a sarcinii respective, dat fiind c procedura
stocat este deja compilat, optimizat si memorata, putand fi apelata oricand,
de oricati clienti
Dezavantaje: congestionarea serverului si scaderea performantelor

acestuia, dac prea multe aplicaii executa operaiile de prelucrare pe
server prin intermediul procedurilor stocate

de baze de date
21
Exemplu: Procedura stocata in MySQL

Folosim tabelele: Studenti, Examene, Discipline:
Procedura stocata: Calculul mediei notelor la o disciplina data:

DELIMITER $$ /* se redefineste delimitatorul deoarece ; este obligatoriu intre instr. din blocuri */
DROP PROCEDURE IF EXISTS SP_Media $$
CREATE PROCEDURE SP_Media (OUT media float, IN disciplina varchar(4))
BEGIN
SELECT AVG(nota) INTO media
FROM DISCIPLINE, EXAMENE
WHERE DISCIPLINE.idDiscipline = EXAMENE.idDiscipline AND Acronim = disciplina;
END$$
DELIMITER ;
Apelul procedurii:
call SP_Media(@media, 'PBD'); /* o variabila precedata de @ este implicit locala */
select @media;

de baze de date
22
Functii definite de utilizator

O funcie definit de utilizator (user-defined function) este o funcie
memorat in baza de date, la fel ca o procedur stocat
O funcie are numai parametri de intrare, returneaz ntotdeauna o valoare
i poate fi folosit direct n expresii (o procedur stocat poate s returneze
zero, una sau mai multe valori prin parametrii de tip OUT sau INOUT)
Functiile se definesc folosind extensiile procedurale ale limbajului SQL:
In Transact-SQL: CREATE FUNCTION nume_func [parametri] AS instructiune
In PL/SQL (Oracle): CREATE FUNCTION nume_func [parametri] AS instructiune
In MySQL: CREATE FUNCTION nume_func [parametri] instructiune_compusa
Exemplu de creare a unei functii in MySQL:

DELIMITER $$
DROP FUNCTION IF EXISTS Func_Media$$
CREATE FUNCTION Func_Media(disc varchar(4)) RETURNS float BEGIN
DECLARE nota_medie float;
SELECT AVG(nota) INTO nota_medie FROM DISCIPLINE, EXAMENE
WHERE DISCIPLINE.idDiscipline = EXAMENE.idDiscipline
AND Acronim = disc;
RETURN nota_medie;
END$$ DELIMITER ;
Utilizarea valorii returnate de o functie: select Func_Media('PBD');


de baze de date
23
Cursoare
Un cursor (cursor) este o structur (un buffer) care permite memorarea unei
mulimi de linii returnate de o instruciune de interogare, urmata de extragerea
si prelucrarea (eventual repetata) in programele de aplicatii a fiecarei linii
Cursoarele se pot crea folosind limbajul SQL sau extensiile procedurale ale
acestuia
Instruciunile SQL de definire i de operare a cursoarelor:
Definire cursor:
DECLARE nume_cursor [OPTIUNI] CURSOR FOR instructiune_select;
Deschidere cursor (popularea cu datele din tabele): OPEN nume_cursor;
Extragerea unei (sau mai multor) linii dintr-un cursor de la pozitia curenta:
FETCH [FROM] nume_cursor INTO lista_variabile;
Inchiderea cursor: CLOSE nume_cursor;
Cursoarele pot fi memorate:

la server, iar clientul primete cte o linie (sau un grup de linii) de la server la
fiecare instruciune de extragere
la client i liniile sunt folosite direct n programul respectiv
In general, cursoarele la server sunt mai avantajoase dect cursoarele la

client, deoarece cursoarele la client necesit ca toate liniile rezultat s fie
transferate dintr-o dat de la server la client

de baze de date
24
Exemplu: Cursor intr-o procedura stocata MySQL (1)

Procedura: Calculul mediei unui student dat (nume, prenume)
DELIMITER $$
DROP PROCEDURE IF EXISTS Medii_Studenti $$
CREATE PROCEDURE Medii_Studenti(OUT media float, IN s_nume varchar(20),
IN s_prenume varchar(20))
BEGIN
DECLARE done INT DEFAULT 0; DECLARE student, id_student INT;
/*Crearea cursorului*/
DECLARE cursor_examene CURSOR FOR
SELECT idStudenti, avg(nota) FROM EXAMENE GROUP BY idStudenti;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
SELECT idStudenti INTO student FROM STUDENTI WHERE Nume = s_nume
AND Prenume = s_prenume;
OPEN cursor_examene;
REPEAT
FETCH cursor_examene INTO id_student, media;
UNTIL done = 1 OR id_student = student
END REPEAT;
CLOSE cursor_examene;
END$$
DELIMITER ;

de baze de date
25
Exemplu: Cursor intr-o procedura stocata MySQL (2)

Pentru parcurgerea liniilor cursorului se defineste un handler pentru conditia
de terminare a parcurgerii liniilor cursorului (not found); un handler este un
fel de rutina de tratare a exceptiilor
Apelul procedurii:
call Medii_Studenti(@media, 'Popescu', 'Marius');
select @media;
Se obtine rezultatul:
@media
6.5
Parcurgerea liniilor cursorului se poate face si cu instructiunea while:

WHILE done = 0 AND id_student <> student DO
END WHILE;
Declararea unei variabile locale (cu instructiunea DECLARE) se poate face

numai intr-un bloc BEGIN ... END si numai la inceputul acestuia
Declaratiile trebuie sa fie facute intr-o anumita ordine: cursoarele se declara
inaintea declararii handler-elor, iar variabilele locale inaintea declararii
cursoarelor si a handler-elor

de baze de date
26
Triggere
Un trigger este o procedur stocat special, care este executat automat
atunci cnd se efectueaz operaii de actualizare a relaiilor (INSERT,
DELETE, UPDATE)
Triggerele pot fi create folosind extensiile procedurale ale limbajului SQL;
sintaxa difera de la un SGBD la altul (sunt neportabile):
In Transact-SQL: CREATE TRIGGER nume_trigger ON nume_tabel
{FOR|AFTER|INSTEAD OF} {[DELETE][,INSERT][,UPDATE]} AS instructiuni
In Pl/SQL (Oracle): CREATE TRIGGER nume_trigger {BEFORE|AFTER} [INSERT,
DELETE, UPDATE] [FOR EACH ROW [WHEN conditie]] CALL procedura
In MySQL: CREATE TRIGGER nume_trigger ON tabel FOR EACH ROW instructiune
Utilizarea triggerelor:
Extinderea capacitii SGBD-ului de meninere a integritii datelor relaionale impunerea constrngerile explicite cum sunt dependenele de date (dependene
funcionale sau multivalorice care nu sunt determinate de chei)
Generarea automat a unor valori care rezult din valori ale altor atribute
Jurnalizarea transparent a evenimentelor sau culegerea de date statistice n
legtur cu accesarea relaiilor.

de baze de date
27
Exemplu: trigger in MySQL

Se defineste un trigger care genereaza coloana nota in tabelul
examene_2(idExamene, idDiscipline, notaLab, notaExam, nota):
DELIMITER $$
DROP TRIGGER IF EXISTS calcul_nota $$
CREATE TRIGGER calcul_nota BEFORE UPDATE ON `examene_2`
FOR EACH ROW BEGIN
SET NEW.nota = NEW.notaLab + NEW.notaExam;
END; $$
DELIMITER ;
Instructiunile dupa FOR EACH ROW se executa de fiecare data cand triggerul
este activat, ceea ce se intampla la fiecare linie afectata de instructiunea de
declansare a triggerului (UPDATE in exemplul dat):
update examene_2 set notaLab = 2 , notaExam = 5
where idStudenti=1 AND idDiscipline = 2;
Cuvintele cheie OLD si NEW permit accesarea coloanelor din linia afectata:
pentru triggere INSERT se poate folosi numai NEW,
pentru triggere DELETE numai OLD,
pentru triggere UPDATE se poate folosi OLD (pentru valorile dinainte de UPDATE)
sau NEW (pentru valorile actualizate).

de baze de date
28
Limbajul SQL integrat (Embeded SQL)

n limbajul SQL integrat (Embeded SQL) instruciunile limbajului SQL sunt
incluse direct n codul programului surs scris ntr-un limbaj gazd de nivel
nalt (Ada, PL/1, Pascal, Fortran, Cobol, C)
Controlul fluxului de operaii este realizat prin instruciunile limbajului gazd,
iar operaiile cu baza de date sunt realizate prin instruciuni SQL
Instruciunile SQL integrate n programul scris n limbajul gazd sunt
prelucrate de un instrument software adecvat (numit preprocesor), fiind
transformate n apeluri de funcii ale unei biblioteci speciale a SGBD-ului
Rezultatul preprocesrii este un program surs n limbajul gazd, care
poate fi compilat cu compilatorul limbajului gazd respectiv i apoi legat
(link) cu bibliotecile de sistem i bibliotecile SGBD-ului
Standardul SQL2 specific suport integrat pentru limbajele PL/1, C, Pascal,
Cobol, Fortran, Mumps. Pentru produsele Oracle, limbajul SQL a fost
integrat n limbajul Java, sub numele de SQLJ
Pentru sistemele Microsoft SQL Server se poate folosi limbajul ESQL/C
(Embedded SQL for C), pentru MySQL exista biblioteca mysqld

de baze de date
29
Interfete si biblioteci de programare a

aplicatiilor de baze de date
In general se folosesc 2 categorii de interfete de programare a aplicatiilor de
baze de date: interfete specifice unui anumit SGBD si interfete
independente de SGBD
Interfete specifice unui anumit SGBD sunt biblioteci care contin funcii i
macrodefiniii ce permit aplicaiilor s interacioneze cu serverul bazei de
date. De exemplu:
Biblioteci dezvoltate pentru limbajul C ( biblioteca C pentru sistemul Microsoft
SQL Server - DB-Library for C, biblioteca MySQL C API)
Biblioteci pentru alte limbaje (C++, Perl, PHP, etc)
Interfee independente de SGBD, cu un grad ridicat de generalitate, care

pot fi folosite pentru mai multe tipuri de SGBD-uri; cele mai cunoscute sunt:
Interfata ODBC (Open DataBase Connectivity)
Interfata JDBC (Java DataBase Connectivity)

de baze de date
30
Interfata ODBC
Tehnologia ODBC (Open Database Connectivity) - interfa de programare a
aplicaiilor prin apel de funcii independente de sistemul SGBD folosit
Independen se obine prin drivere specifice fiecrui SGBD
Driverul transform apelurile de funcii ODBC n comenzi SQL (sau ntr-un
limbaj procedural de extensie a limbajului SQL) si le transmite SGBD-ului
Interfaa ODBC
Aplicaie
Administrator de drivere
Driver
Sursa
de date
SGBD i Baza
de date
Driver
Sursa
de date
SGBD i Baza
de date

de baze de date
Driver
Sursa
de date
SGBD i Baza
de date
31
Interfaa JDBC
JDBC este o interfa de programare a aplicaiilor de baze de date
independent de platform i de sistemul SGBD
Interfaa JDBC const din clase si obiecte Java i permite interaciunea cu
baze de date relaionale, precum i cu alte surse de date n format tabelar
Arhitectura JDBC const din mai multe niveluri care asigur independena
funciilor de acces apelate din programele de aplicaie de SGBD
Interfaa
JDBC
Program de aplicatie Java
Administratorul de drivere
(DriverManager)
Driver JDBC
de retea
Punte JDBCODBC
Driver
combinat
Driver
Java pur
Driver ODBC
Protocol JDBCmiddleware
Protocoale de acces
specifice SGBD-urilor
de baze de date
32

de baze de date
33
Capitolul 5: Gestiunea tranzactiilor

Tranzactii
Anomalii de acces concurent la bazele de date
Actualizare pierduta
Citire improprie
Citire irepetabila
Citire fantoma
Proprietatile tranzactiilor
Operatiile efectuate de tranzactii
Starile tranzactiilor
Planificarea tranzactiilor
Tehnici de control al concurentei
Controlul concurentei prin blocare
Controlul concurentei prin marci de timp
Tehnici de refacere a bazelor de date

Cap. 5 - Gestiunea tranzactiilor
Tranzactii
n mod obinuit, un sistem SGBD deservete mai muli utilizatori, care
acceseaz concurent datele din tabele
Execuia concurent a mai multor procese poate avea loc:
ntr-un sistem uniprocesor, prin partajarea (mprirea) timpului de execuie al
procesorului ntre mai multe procese (multiprogramare)
ntr-un sistem multiprocesor, n care mai multe procese pot fi executate n mod
real simultan, pe mai multe procesoare ale sistemului (multiprocesare)
O tranzacie (transaction) este o unitate logic de prelucrare indivizibil

(atomic) a datelor unei baze de date prin care se asigur consistena
acesteia
O tranzacie trebuie s asigure consistena bazei de date in diferite situatii:
tranzactia se execut individual sau concurent cu alte tranzacii
apar defecte ale sistemului n cursul execuiei tranzaciei
O tranzacie este o operaie indivizibil de acces la baza de date care:

fie se execut cu succes toate aciunile i se termin cu o validare a modificrilor
efectuate asupra bazei de date (commit)
fie nu poate efectua (din diferite motive) toate aciunile i este abandonat i
anulat (abort, rollback)
Exemplu de tranzactie
Exemplu: un sistem de rezervare a locurilor la curse aeriene
PASAGERI (IdPasager, Nume, Prenume, Adresa)
CURSE (IdCursa, AeroportPlecare, AeroportSosire, DataCursa, NrLocuriLibere)
FACTURI (IdFactura, IdPasager, IdCursa, DataFactura, Pret)
Pentru rezervarea unui loc se efectueaz mai multe operaii:
1.
Se insereaz o linie nou n tabelul PASAGERI, cu datele pasagerului
2.
Dac exist locuri libere la cursa dorit, atunci se face propriu-zis rezervarea,
prin inserarea unei linii noi n tabelul FACTURI; altfel, nu se face rezervarea
3.
Se tipreste factura
4.
Se emite (tiprete) biletul
Probleme care pot sa apara:
Dac sistemul se defecteaz dup ce s-a executat pasul 2, s-a fcut o rezervare,
dar biletul nu a fost facturat i nici emis
Dac defeciunea are loc dup pasul 3, clientului i se trimite factura, dar el nu a
primit biletul
Dac nu se defecteaz sistemul, dar doi ageni de vnzri atribuie acelai loc la
doi pasageri diferii, atunci vor fi probleme la mbarcarea pasagerilor
Astfel de probleme ar disparea dac toate actiunile efectuate pentru o

rezervare ar fi grupate ca o operaie indivizibil (atomic)
Anomalii de acces concurent la bazele de date (1)

Unitatea de transfer a datelor ntre discul magnetic i memoria principal a
sistemului este un bloc, care corespunde unui sector de pe disc si in care
se memoreaza mai multe inregistrari (tupluri)
Un articol (data item) este un cmp care memoreaz valoarea unui atribut
dintr-o nregistrare (tuplu), dar poate fi o nregistrare ntreag sau chiar o
grupare de inregistrari memorate intr-un bloc
Operaiile de acces la un articol X al bazei de date pot fi:
read(X): citete articolul X din baza de date ntr-o variabil a programului; pentru
simplificarea notaiilor se va considera c variabila n care se citete articolul X
este notat, de asemenea, cu X.
write(X): scrie variabila de program X n articolul X al bazei de date.
Tranzaciile lansate de diferii utilizatori se pot executa concurent i este

posibil s actualizeze aceleai articole ale bazei de date
Dac execuia concurent a tranzaciilor este necontrolat, este posibil ca
baza de date s ajung ntr-o stare inconsistent (incorect), chiar dac:
fiecare tranzacie n parte a fost executat corect
nu au aprut defecte de funcionare ale sistemului
Anomalii de acces concurent la bazele de date (2)

Actualizare pierduta (lost update): rezulta X=X-M (b) in loc de valoarea
corecta X= X+N-M (a)
Citire improprie (dirty read): T2 citeste X+N, desi X=X+N nu a fost validata (c)
Timp
T1
T2
T1
T2
T1
read(X)
read(X)
read(X)
X=X+N
X=X+N
X=X+N
write(X)
read(X)
X=X-M
write(X)
write(X)
X=X-M
read(X)
T2
read(X)
write(X)
X=X-M
write(X)
write(X)
abort
(a)
(b)
(c)
Citire irepetabil (nonrepetable read): o tranzacie citete un articol de dou

ori, iar ntre cele dou citiri, o alt tranzacie a modificat chiar acel articol
Citire fantom (phantom read): o tranzacie prelucreaz un set de linii
rezultat al unei interogri si n timpul acestei prelucrri o alt tranzacie
insereaza sau sterge o linie
Proprietatile tranzactiilor (ACID)

Atomicitatea (atomicity): proprietatea unei tranzacii de a reprezenta o
unitate de execuie indivizibil, adic de a executa totul sau nimic
Consistena (consistency): proprietatea unei tranzactii de a efectua
modificri corecte ale bazei de date
o tranzacie transform baza de date dintr-o stare consistent n alt stare
consistent
starea unei baze de date este consistent dac respect toate constrngerile de
integritate implicite sau explicite
Izolarea (isolation): proprietatea unei tranzacii de a face vizibile modificrile

efectuate numai dup ce a fost validat (committed)
Dac rezultatele pariale ale unei tranzacii sunt vizibile altor tranzacii nainte de
validarea acesteia i dac se ntmpl ca aceast tranzacie s fie abandonat i
anulat (rollback), atunci toate tranzaciile care au accesat rezultatele pariale ale
acesteia vor trebui s fie anulate
Aceste operaii de anulare pot produce, la rndul lor alte anulri, .a.m.d.
Durabilitarea (durability): proprietatea prin care, dup validarea unei

tranzacii, modificrile efectuate de aceasta n baza de date nu vor mai fi
pierdute datorit unor defectri ulterioare a sistemului
Operatiile efectuate de tranzactii

Operaiile efectuate de o tranzacie i nregistrate de administratorul de
refacere (recovery manager):
begin: nceputul execuiei unei tranzacii
read sau write: operaii de citire sau scriere a articolelor din baza de date
end: marcheaz terminarea operaiilor de scriere sau citire din baza de date,
ceea ce nseamn c tranzacia se poate termina; totui, este posibil s fie
necesare unele operaii de verificare nainte de validarea (commit) tranzaciei.
commit: terminarea cu succes a tranzaciei, validarea tuturor modificrilor
efectuate n baza de date i vizibilitatea modificrilor efectuate pentru alte
tranzacii; din acest moment, modificrile efectuate nu mai pot fi anulate, nici
pierdute printr-o defectare ulterioar a sistemului
rollback (sau abort): semnifica faptul c tranzacia a fost abandonat i c orice
efect pe care tranzacia l-a avut asupra bazei de date trebuie s fie anulat (printro rulare napoi a operaiilor).
undo: operaie similar operaiei rollback, dar se aplic unei singure operaii, nu
unei ntregi tranzacii.
redo: specific faptul c unele operaii ale unei tranzacii trebuie s fie executate
din nou pentru a se putea valida ntreaga tranzacie.
Ultimele dou operaii sunt necesare numai n anumite tehnici de refacere

Starile tranzactiilor
Diagrama de stare a unei tranzactii:
read,
write
begin
end
ACTIV
abort
PARTIAL
VALIDAT
commit
VALIDAT
abort
ABANDONAT
TERMINAT
Pentru refacerea bazei de date, sistemul SGBD menine un fiier jurnal (log
file), n care memoreaz operaiile efectuate de fiecare tranzacie,
identificat printr-un identificator unic (T) generat de sistem
Fiierul jurnal este memorat pe disc i nu este afectat de erori de execuie,
cu excepia unei defectri catastrofice a discului
Fiierul jurnal este salvat periodic pe un suport auxiliar (band magnetic)
Planificarea tranzactiilor
O planificare (schedule, sau istorie - history) S a n tranzacii
T1,T2,..Ti,...Tn este o ordonare a operaiilor tranzaciilor astfel nct:
Pentru orice tranzacie Ti care particip n S, operaiile lui Ti n S
respect ordinea iniial din Ti
Alte operaii (ale altor tranzacii Tj, unde j i) pot fi ntreesute cu
operaii ale tranzaciei Ti
Dou operaii dintr-o planificare sunt conflictuale (conflicting

operations) dac aparin unor tranzacii diferite, acceseaz acelai
articol i cel puin una dintre operaii este operaie de scriere
Planificri seriale (serial schedules): o planificare S se numete
serial dac pentru orice tranzacie T participant n planificare,
toate operaiile din T se execut consecutiv n S; altfel, planificarea
se numete neserial
Pentru n tranzactii pot exista n! planificari seriale
Orice planificare seriala a unor tranzactii corecte este corecta, dar
nu permite ntreeserea operaiilor i concurena tranzaciilor
De aceea, n cazul sistemelor de baze de date cu utilizatori multipli
se folosesc planificrile serializabile, care admit concurena,
asigurnd n aceelai timp consistena bazei de date
Planificari seriale ale tranzactiilor

Planificarile seriale posibile ale tranzactiilor T1 si T2 sunt SA si SB:
T1
T2
T1
T2
read(X) r1(X)
read(X) r2(X)
X=X-N
X=X+M
write(X) w1(X)
write(X) w2(X)
read(Y) r1(Y)
SA
Y=Y+N
write(Y) w1(Y)
read(X) r1(X)
X=X-N
SB
write(X) w1(X)
read(X) r2(X)
read(Y) r1(Y)
X=X+M
Y=Y+N
write(X) w2(X)
write(Y) w1(Y)
Notam operaiile de begin, read, write, commit i abort cu b, r, w, c, a, cu indice

numarul tranzaciei i ca parametru articolul pe care l-a citit sau scris:
SA: b1; r1(X); w1(X); r1(Y); w1(Y); c1; b2; r2(X); w2(X); c2;
SB: b2; r2(X); w2(X); c2; b1; r1(X); w1(X); r1(Y); w1(Y); c1;
Perechile de operaii conflictuale sunt:

in SA: ((r1(X), w2(X)), w1(X), r2(X)), (w1(X), w2(X));
in SB: (r2(X), w1(X)), (w2(X), r1(X)), (w2(X), w1(X))
10
Planificari serializabile ale tranzactiilor (1)

O planificare a n tranzacii se numte serializabil dac este
echivalent cu o planificare serial a celor n tranzacii
Dou planificri sunt echivalente (din punct de vedere al conflictelor)
dac operaiile din oricare pereche de operatii conflictuale se execut
n aceeai ordine n cele dou planificri
Planificarile SC si SD sunt planificari echivalente cu SA, deci sunt
serializabile
T1
T2
T1
read(X) r1(X)
read(X) r1(X)
X=X-N
X=X-N
write(X) w1(X)
write(X) w1(X)
read(X) r2(X)
SC
read(Y) r1(Y)
SD
X=X+M
read(X) r2(X)
write(X)- w2(X)
X=X+M
read(Y) r1(Y)
Y=Y+N
Y=Y+N
write(Y) w1(Y)
write(Y) w1(Y)
T2
write(X) w2(X)
11
Planificari serializabile ale tranzactiilor (2)

Planificarile SE si SF nu sunt sunt echivalente nici cu SA nici cu SB,
deci sunt neserializabile
T1
T1
T2
read(X) r1(X)
read(X) r1(X)
X=X-N
X=X-N
read(X) r2(X)
read(X) r2(X)
write(X) w1(X)
T2
SE
X=X+M
X=X+M
write(X) w1(X)
write(X)- w2(X)
read(Y) r1(Y)
read(Y) r1(Y)
Y=Y+N
Y=Y+N
write(Y) w1(Y)
SF
write(X) w2(X)
write(Y) w1(Y)
Testarea echivalentei unei planificri cu o planificare seriala prin testarea ordinii

operatiilor din toate perechile de operatii conflictuale este foarte costisitoare
DAR s-a demonstrat ca se poate asigura echivalenta planificarilor (deci
serializabilitatea lor) prin tehnici de control al concurenei tranzaciilor, care
interzic execuia n ordine incorect a operaiilor din perechile conflictuale
De exemplu: n SE se interzice execuia r2(X) naintea de w1(X)
12
Tehnici de control al concurentei tranzactiilor

Pentru a asigura proprietile ACID ale tranzaciilor i, prin aceasta, consistena
datelor, este necesar controlul execuiei concurente a tranzaciilor
Cele mai utilizate tehnici de control al concurenei sunt:
Tehnici bazate pe blocarea accesului la date prin zvoare (locks)
Tehnici bazate pe mrci de timp (timestamps)
Protocoalele de control al concurenei sunt implementate de SGBD-uri:

programatorii de aplicaii nu opereaz explicit cu zvoare sau mrci de timp
ei stabilesc opiunile prin care sistemul SGBD executa anumite operatii de control
Un zvor (lock) este o variabil L(X) asociat cu un articol X al bazei de date

care descrie starea acelui articol n raport cu operaiile care i se pot aplica
Tipuri de zavoare utilizate in SGBD-uri:
zvoare binare, zvoare cu stri multiple
Un zvor binar (binary lock) L(X) poate avea dou stri:

L(X) = 1 - liber (sau neblocat - free, unlocked) se poate accesa articolul X
L(X) = 0 - ocupat (sau blocat - busy, locked) nu se poate accesa articolul X
Asupra unui zvor binar L(X) se pot executa dou operaii:

operaia de blocare, lock(X) trece zvorul n starea blocat (ocupat)
operaia de eliberare, unlock(X) trece zvorul n starea neblocat (liber)
13
Zavoare binare
Dac zvorul articolului X este liber (L(X)=1), atunci tranzactia:
achiziioneaz zvorul (trecndu-l n starea ocupat prin operatia lock )
execut operaiile necesare asupra articolului X
elibereaz zvorul (trcndu-l in starea liber prin operaia unlock)
Dac zvorul articolului X este ocupat (L(X)=0), atunci tranzacia:

ateapt pn ce acesta este eliberat (de o alt tranzacie, care i-a terminat
operaiile de acces la acel articol),
dup care execut aceeai secven de operaii: blocarea zvorului, execuia
operaiilor care acceseaz articolul respectiv i eliberarea zvorului
Operaia de blocare se executat ca operaie indivizibil (folosind

instruciuni speciale ale procesoarelor de tip TestAndSet)
Regulile respectate de fiecare tranzacie care folosete un zvor binar:
1. O tranzacie trebuie s blocheze zvorul articolului X (prin operatia lock(X)),
nainte de a efectua orice operaie de citire sau de scriere a articolului X
2. O tranzacie trebuie s elibereze zvorul unui articol X (prin operaia unlock(X))
dup ce a efectuat toate operaiile de citire sau de scriere a articolului X
3. O tranzacie nu poate achizitiona un zvor pe care l deine deja
4. O tranzacie nu poate elibera un zvor pe care nu l deine
14
Zvoare cu stri multiple (1)

Tehnica zvoarelor binare este prea restrictiv i limiteaz n mod nejustificat
concurena n execuia tranzaciilor
De exemplu, mai multe tranzacii pot efectua operaii de citire n mod
concurent asupra aceluiai articol, fr ca acest lucru s afecteze consistena
bazei de date, dar acest lucru este interzis n tehnica zvoarelor binare
De aceea, multe sisteme de gestiune a bazelor de date utilizeaz zvoare cu
stri multiple
Un zvor cu stri multiple (multiple-mode lock) M(X) poate fi ntr-una din
urmtoarele trei stri:
liber (neblocat, unlocked): zvorul nu este deinut de nici o tranzacie i prima
tranzacie care lanseaz o operaie de blocare l poate obine
blocat pentru citire (sau blocat partajat,read-locked): oricte tranzacii pot deine
zvorul respectiv i pot efectua operaii de citire a articolului X, dar nici o tranzacie
nu poate scrie n acest articol
blocat pentru scriere (sau blocat exclusiv, write-locked): o singur tranzacie
poate deine zvorul i poate citi sau scrie n articolul X, nici o alt tranzacie
neputnd accesa articolul respectiv, nici pentru scriere nici pentru citire
Operatiile cu zvoarele cu stri multiple:

read_lock(X) - blocarea pentru citire (partajat) a zvorului M(X)
write_lock(X) - blocarea pentru scriere (exclusiv) a zvorului M(X)
unlock(X) - deblocarea zvorului M(X)
15
Zvoare cu stri multiple (2)

Orice tranzacie care utilizeaz un zvor cu stri multiple M(X)
trebuie s respecte urmtoarele reguli:
1. O tranzacie trebuie s execute o operaie de blocare partajat sau
exclusiv a zvorului articolului X (read_lock(X) sau write_lock(X))
nainte de a efectua orice operaie de citire a articolului X
2. O tranzacie trebuie s execute o operaie de blocare exclusiv a
zvorului articolului X (write_lock(X)) nainte de a efectua orice operaie
de scriere a lui X
3. O tranzacie trebuie s elibereze zvorul unui articol X (unlock(X)) dup
ce a efectuat toate operaiile de citire sau de scriere a articolului X
Operaia de eliberare a unui zvor poate fi executata numai de o

tranzactie care deine (n mod exclusiv sau partajat) acel zavor
16
Blocarea folosind zvoare binare

Fie tranzactiile T3,T4, o planificarea serial (a) si planificarile neseriale (b) si (c)
Daca se foloseste un singur zavor binar pentru toate articolele grupate (XY) si se
respecta protocolul de utilizare a zavoarelor, se obtin planificari serializabile (b)
Daca se folosesc mai multe zavoare, se pot obtine planificari neserializabile (c), chiar
daca se respecta protocolul de utiliz. a zavoarelor
T3
T4
T3
T3
T4
T4
lock(Y)
read(Y)
lock(XY)
read(Y)
read(X)
read(Y)
unlock(Y)
X=X+Y
read(X)
write(X)
read(X)
(a)
lock(X)
lock(XY)
X=X+Y
T4 blocata
read(X)
(b)
unlock(X)
read(Y)
write(X)
lock(Y)
Y=X+Y
unlock(XY)
read(Y)
write(Y)
Fie: X=20, Y=30:
read(X)
Y=X+Y
read(Y)
write(Y)
Y=X+Y
unlock(Y)
write(Y)
lock(X)
unlock(XY)
read(X)
planificarile (a) si (b): rezultat corect (X=50, Y=80)

planificarea neseriala(c): rezultat eronat (X=50,Y=50)
(c)
X=X+Y
write(X)
unlock(X)
17
Protocolul de blocare in doua faze (1)

Pentru a asigura serializabilitatea planificrilor tranzactiilor care folosesc mai
multe zavoare, pe lng regulile de utilizare a zvoarelor, mai este necesar
s se respecte un protocol privind ordinea operatiilor de blocare i de
eliberare a zvoarelor, cum este protocolul de blocare in doua faze
Protocolul de blocare n dou faze (two-phase locking) impune ca fiecare
tranzactie sa respecte protocolul de utilizare a zavoarelor si toate operaiile de
blocare a zvoarelor sa preceada prima operaie de eliberare a unui zvor
O astfel de tranzacie poate fi divizat n dou faze:
faza de cretere (growing phase), n care pot fi achiziionate noi zvoare ale
articolelor care vor fi accesate, dar nici un zvor nu poate fi eliberat
faza de descretere (shrinking phase), n care zvoarele deinute pot fi eliberate,
dar nici un alt zvor nu mai poate fi achiziionat.
S-a demonstrat c, dac fiecare tranzacie a unei planificri respect

protocolul de blocare n dou faze, atunci planificarea este serializabil
Planificarea tranzaciilor din figura precedenta (c) nu respect protocolul de
blocare n dou faze deoarece:
T3 elibereaz zvorul articolului Y (unlock(Y) ) naintea achiziionrii zvorului
pentru scrierea articolului X (lock(X))
T4 elibereaz zvorul articolului X (unlock(X) ) naintea achiziionrii zvorului
pentru scrierea articolului Y (lock(Y))
Aceasta planificare este neserializabil, cu rezultat al execuiei incorect, aa

cum s-a artat mai nainte
18
Protocolul de blocare in doua faze (2)

Planificarea din figura alaturata este
serializabil, echivalent cu planificarea serial
T3, T4 (cu rezultat corect X=50, Y=80)
Daca T3 lanseaz operaia de blocare a
zvorului articolului X naintea tranzaciei T4,
tranzacia T4 este blocata, asteptnd
eliberarea zvorului articolului X, dup care
efectueaza restul operaiilor
Probleme care apar la utilizarea zvoarelor:
impasul (deadlock): blocarea execuiei
tranzaciilor atunci cnd dou sau mai multe
tranzacii se ateapt una pe ceallalt ca s
elibereze un zvor; exista tehnici de prevenire si
de eliminare a impasului
amnarea permanent (nfometare) (livelock, indefinit postponement, starvation): o
tranzacie se afl n stare de amnare nedefinit
dac ea nu poate continua execuia o perioad
lung de timp, n timp ce toate celelalte
tranzacii se execut normal; prevenirea se face
prin asigurarea unei politici echilibrate de
obtinere (blocare) a zavoarelor
T3
T4
lock(Y)
read(Y)
lock(X)
lock(X)
unlock(Y)
T4 blocata
read(X)
X=X+Y
write(X)
unlock(X)
read(X)
lock(Y)
unlock(X)
Y=X+Y
write(Y)
unlock(Y)
19
Controlul concurentei bazat pe marci de timp

O marc de timp (timestamp) este un identificator unic al unei tranzacii,
creat de sistemul de gestiune a bazei de date, care se bazeaz pe timpul de
start al tranzaciei
O marc de timp se poate crea:
fie folosind valoarea curent a ceasului sistemului de operare
fie folosind un numrtor care este incrementat la fiecare asignare a unei noi
mrci, n ordinea de lansare a tranzaciilor
O tranzacie T va avea o marc de timp unic, notat TS(T)

Pentru fiecare articol X al bazei de date se definesc dou mrci de timp:
R_TS(X) - marca de timp de citire a articolului X; este cea mai mare marc de
timp dintre toate mrcile de timp ale tranzaciilor care au citit articolul X
W_TS(X) - marca de timp de scriere a articolului X; este cea mai mare marc de
timp dintre toate mrcile de timp ale tranzaciilor care au scris n articolul X
Serializabilitatea planificrilor se obine dac se impun anumite condiii

ordinii de accesare a articolelor de mai multe tranzacii concurente, n funcie
de mrcile de timp ale acestora
20
Ordonarea operatiilor dup mrcile de timp

La lansarea unei operaii de citire a articolului X (read(X)):
Dac TS(T) < W_TS(X), atunci tranzacia T trebuie s fie abandonat i rulat
napoi, deoarece o alt tranzacie cu o marc de timp mai mare a scris deja n
articolul X, nainte ca T s fi avut ansa s citeasc articolul X
Dac TS(T) >= W_TS(X), atunci T va executa operaia de citire din articolul X i
va seta marca R_TS(X) la cea mai mare dintre valorile TS(T) i R_TS(X)
La lansarea unei operaii de scriere a articolului X (write(X)):

Dac TS(T) < R_TS(X) , atunci tranzacia T trebuie s fie abandonat i rulat
napoi, deoarece o alt tranzacie cu o marc de timp mai mare (deci lansat
dup T) a citit deja valoarea lui X, nainte ca T s fi avut ansa s scrie n X
Dac TS(T) < W_TS(X), atunci tranzacia T nu va executa operaia de scriere, dar
va putea continua cu celelalte operaii. Aceasta, deoarece o alt tranzacie, cu o
marc de timp mai mare a scris deja o valoare n articolul X, care este mai
recent, iar valoarea pe care ar dori s o nscrie T este deja perimat
Dac nu a aprut nici una din situaiile precedente, atunci T va executa operaia
de scriere n articolul X i va seta W_TS(X) = TS(T)
Ulterior, o tranzacie T care a fost anulat i rulat napoi va fi relansat, dar

cu o nou marc de timp, corespunztoare noului moment de lansare
Ordonarea dup mrcile de timp garanteaz serializabilitatea planificrilor
In acest protocol nu poate sa apara impasul, dar poate apare amnarea
indefinit
21
Controlul tranzactiilor
Tehnicile de gestiune a tranzaciilor i de refacere a datelor sunt incluse n
SGBD-uri, iar aplicaiile de baze de date au un control limitat asupra
tranzaciilor prin intermediul unor comenzi SQL
Comenzi SQL pentru tranzacii:
SET TRANSACTION: setare optiuni :
Nivelul de izolare a tranzaciilor (ISOLATION LEVEL)
Modul de refacere a datelor (SET CONSTRAINTS)
Modul de acces la articole - cu valorile posibile READ ONLY, READ WRITE
COMMIT [WORK] terminarea tranzactiei
ROLLBACK [WORK] abandonarea si rularea inapoi a tranzactiei
Pentru orice nivel de izolare

(ISOLATION LEVEL)
este interzisa pierderea
actualizarilor, dar se admit
unele citiri incorecte, asa
cum se vede in tabel
Nivel de izolare
Citire
impropie
Citire
nerepetabila
READ
UNCOMMITTED
DA
DA
DA
READ
COMMITTED
NU
DA
DA
REPEATABLE
READ
NU
NU
DA
SERIALIZABLE
NU
NU
NU
Citire
fantoma
22
Exemplu de tranzactie in MySQL (1)

In mod MySQL o tranzactie se lanseaza cu comanda START TRANSACTION
Fie baza de date ZBORURI cu tabelele descrise la inceputul capitolului:
Se defineste o tranzactie pentru rezervarea unui loc la o cursa aeriana in

procedura stocata sp_rezervari()
Daca tabelul CURSE contine linia (1, Bucuresti, Paris, 2008-12-30,1) si se
apeleaza: sp_rezervari(@rez, 100, Ionescu, Ion, Craiova, Bucuresti,
Paris, 2009-12-30, 500) atunci:
Se obtine @rez=1 (executie corecta)
NrLocuriLibere in tabelul CURSE este decrementat cu 1 (mai sunt 0 locuri)
Tabelul PASAGERI va contine si linia (100, Ionescu, Ion, Craiova)
Tabelul FACTURI va contine si linia: (1, 100,1,2008-12-28,500)
Daca se incearca inca o rezervare, se obtine @rez=0 si nicio modificare in

tabele (s-a executat rollback)
23
Exemplu de tranzactie in MySQL (2)

DELIMITER $$ DROP PROCEDURE IF EXISTS `zboruri`.`sp_rezervari` $$
CREATE PROCEDURE `zboruri`.`sp_rezervari`(OUT rezultat INT, s_pasager INT,
s_nume varchar(20), s_prenume varchar(20), s_adresa varchar(20), plecare
varchar(20), sosire varchar(20), s_data date, s_pret decimal)
BEGIN DECLARE l_cursa, l_locuri INT;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET autocommit = 0;
START TRANSACTION;
INSERT INTO PASAGERI values(s_pasager, s_nume, s_prenume, s_adresa);
SELECT IdCursa, NrLocuriLibere INTO l_cursa, l_locuri FROM CURSE
WHERE AeroportPlecare=plecare AND AeroportSosire=sosire
AND DataCursa = s_data;
IF l_locuri > 0 THEN BEGIN
UPDATE CURSE SET NrLocuriLibere = l_locuri - 1;
INSERT INTO FACTURI(IdPasager,IdCursa, DataFactura,Pret)
values (s_pasager, l_cursa, CURDATE(), s_pret);
COMMIT;
SET rezultat = 1; END;
ELSE BEGIN ROLLBACK; SET rezultat = 0; END; END IF;
END $$
DELIMITER ;
24
Proiectarea tranzactiilor
Tranzaciile sunt corecte dac las baza de date ntr-o stare consistent
Tranzaciile sunt cu att mai eficiente cu ct sunt mai scurte (ca timp de
execuie i ca numr de articole ale bazei de date accesate) deoarece astfel:
se limiteaza frecvena de apariie a impasului (n cazul folosirii zvoarelor)
creste eficienei operaiilor de anulare i de blocare a resurselor
Ori de cte ori se poate nlocui o tranzacie complex, cu numr mare de

operaii i timp de execuie ridicat, cu mai multe tranzacii scurte, este indicat
s se fac aceast transformare
De asemenea, pentru meninerea tranzaciilor ct mai scurte posibil, se
recomand ca o tranzacie s nu fie pornit pn ce nu au fost pregtite toate
datele (citirea datelor de intrare, parcurgerea, analiza i prelucrarea acestora)
Toate operaiile de gestiune a tranzaciilor i de refacere a datelor sunt
prevzute n diferitele componente ale sistemelor SGBD (administratorul de
tranzacii, administratorul de refacere), iar aplicaiile:
trebuie s se prevad tranzacii corecte
pot selecta diferite opiuni de control al tranzaciilor i de refacere a datelor oferite
de sistemul de gestiune respectiv
25
Tehnici de refacere a bazelor de date

Refacerea unei baze de date dup producerea unui defect (database
recovery) nseamn aducerea bazei de date ntr-o stare precedent corect,
din care, eventual, se poate reconstrui o nou stare corect i ct mai
apropiat de momentul apariiei defectului
Tehnicile de refacere a bazelor de date sunt, n general, integrate cu tehnicile
de control al concurenei si depind de SGBD
Pentru operaiile de refacere se folosete fiierul jurnal (log file), i (sau) o
copie de rezerv a bazei de date (database backup) stocat n general pe
band magnetic
Un punct de validare (commit point) este punctul atins de o tranzacie care
a executat cu succes toate operaiile sale i le-a nregistrat n fiierul jurnal
ntr-un astfel de punct, o tranzacie T nscrie n fiierul jurnal operaia [commit,T]
i, de asemenea, trebuie s scrie blocul din bufferul de scriere n fiierul jurnal
Un punct de control (checkpoint) este nscris n fiierul jurnal atunci cnd se

scriu n fiierele bazei de date toate rezultatele operaiilor de scriere ale
tranzaciilor validate
Aceasta nseamn c toate tranzaciile care au nregistrarea [commit,T] nscris n
fiierul jurnal naintea unui punct de control nu vor necesita reluarea operaiilor de
scriere n cazul unei defectri a sistemului
Administratorul de refacere al SGBD-ului (recovery manager) decide la ce

interval de timp (sau dup cte tranzacii) introduce un nou punct de control
26
Refacerea datelor dupa defecte necatastrofice

Dac baza de date nu este distrus fizic, dar a devenit inconsistent datorit
unui defect necatastrofic, atunci strategia de refacere const n:
anularea modificrilor care au produs inconsistena (prin operaii undo)
executarea din nou a modificrilor care s-au pierdut (prin operaii redo)
n acest caz nu este necesar copia de rezerv, ci se folosete starea actual

a bazei de date i fiierul jurnal
Exista dou tehnici de refacere a datelor dupa defecte necatastrofice:
Refacerea cu actualizare amnat (deferred update)
Refacerea cu actualizare imediat (immediate update)
Pentru refacerea cu actualizare amanata se executa urmatoarele operatii:

Se parcurge fiierul jurnal n sens invers, ncepnd de la ultima nregistrare, pn
se ntlnete primul punct de control
Se construieste o list a tranzaciilor validate, n care se introduc toate tranzaciile
T care au o nregistrare de tipul [commit,T] n fiierul jurnal ntre punctul de control
considerat i sfritul fiierului jurnal,
Se construieste o list a tranzaciilor nevalidate, n care se introduc toate
tranzaciile T care au o nregistrare de start ([begin,T]) n fiierul jurnal, dar nu au
i nregistrarea corespunztoare de validare.
Dup aceasta, se execut reluarea (REDO) tuturor operaiilor de scriere (write(X))
ale tranzaciilor validate, n ordinea n care apar n fiierul jurnal, iar tranzaciile
nevalidate sunt relansate
27
Refacerea cu actualizare imediata

In tehnicile de refacere cu actualizare imediat, atunci cnd o tranzacie
lanseaz o comand de actualizare a bazei de date, actualizarea este
efectuat imediat, fr s se mai atepte ajungerea la un punct de validare
In majoritatea acestor tehnici se impune ca modificarea s fie mai nti
memorat n fiierul jurnal (pe disc), nainte de a fi aplicat bazei de date;
aceast regul este cunoscut sub numele de protocol de scriere n avans
a fiierului jurnal (write-ahead log protocol)
Dac se admite actualizarea imediat, atunci la refacere trebuie s se poat
anula (prin operaii undo) modificrile efectuate de o tranzacie, dac
aceasta eueaz ulterior din diferite motive
In felul acesta se efectueaza rularea napoi (rollback) a tranzaciei
Tehnica de refacere cu actualizare imediat are avantajul simplitii
operaiilor de scriere, care se efectueaz direct n baza de date, fr s fie
necesar s se atepte atingerea unui punct de validare pentru transferarea
datelor n baza de date
Dezavantajul acestei metode este faptul c pot apare anulri n cascad,
care necesit operaii complicate de refacere
28
Refacerea datelor dupa defecte catastrofice

Dac baza de date a fost puternic distrus datorit unei defectri serioase a
discului, atunci se restaureaz starea bazei de date din copia de rezerv a
bazei de date (database backup)
Ultima copie salvat se ncarc de pe band pe disc (dup ce acesta a fost
nlocuit sau reparat) i sistemul este repornit
Totui, tranzaciile efectuate de la ultima operaie de salvare pn n
momentul apariiei defectului se pierd
Deoarece fiierul jurnal este mult mai mic dect fiierele bazei de date, se
obinuiete ca acesta s fie salvat mai des dect baza de date nsi i s
fie iniializat la fiecare operaie de salvare a bazei de date
In aceast situaie, dup ncrcarea ultimei copii salvate a bazei de date se
folosete fiierul jurnal pentru a reface toate tranzaciile validate existente n
copia salvat a fiierului jurnal (care este mai recent dect copia salvat a
bazei de date)
29
30
Capitolul 6: Normalizarea relatiilor

Dependentele de date si formele normale ale relatiilor
Redundanta datelor si anomaliile de actualizare a relatiilor
Dependentele functionale (DF)
Tipuri de DF
Multimi de DF
DF si cheile relatiilor
Descompunerea relatiilor
Descompunere fara pierdere de informatie la jonctiune
Descompunere cu conservarea DF
Formele normale ale relatiilor determinate de DF:

FN1
FN2
FN3
FNBC
Dependente multivalorice forma normala FN4

Dependente de jonctiune forma normala FN5
Cap. 6 - Normalizarea relatiilor
Dependentele de date
Dependenele de date (data dependencies) reprezint constrngeri care se
impun valorilor atributelor unei relaii i care determin proprietile relaiei n
raport cu operaiile de inserare, tergere i actualizare a tuplurilor.
O form normal a unei relaii (normal form) presupune anumite condiii pe
care le ndeplinesc valorile atributelor i dependenele de date definite pe
acea relaie
Dependentele de date:
Dependente functionale: E.F. Codd a propus trei forme normale: FN1, FN2, FN3;
apoi a fost introdus forma normal Boyce-Codd (FNBC)
Dependenelor multivalorice: forma normala 4 (FN4)
Dependenelor de jonciune: forma normala 5 (FN5)
Formele normale ale relaiilor formeaz o colecie ordonat (FN1, FN2, FN3,
FNBC, FN4, FN5), i ele impun condiii din ce n ce mai restrictive asupra
dependenelor de date
Ordonarea formelor normale de la FN1 la FN5 nseamn c orice relaie
aflat n FN2 este n FN1, orice relaie n FN3 este n FN1 i FN2 etc.
Normalizarea relaiilor (normalization) const n descompunerea lor, astfel
nct relaiile s fie in forme normale ct mai avansate
Redundanta datelor si anomaliile de actualizare

In relatia AP, cu cheia primara PK={IdAngajat, IdProiect} sunt valori
redundante ale atributelor: Nume, prenume, Adresa
Anomalii de inserare: nu se pot introduce date despre un angajat (numele,
prenumele, adresa) dac nu exist cel puin un proiect la care acesta s lucreze
Anomalii de tergere: dac se terg toate tuplurile referitoare la un anumit
proiect, se pot pierde toate datele referitoare la acei angajai care lucreaz doar la
proiectul respectiv
Anomalii de actualizare: dac se modific ntr-un tuplu valoarea unuia din
atributele care au valori redundante, starea relaiei poate deveni inconsistent
IdAngajat
Nume
Prenume
Adresa
IdProiect
Ore
Ionescu
Ion
Bucuresti
P1
100
Popescu
Petre
Ploiesti
P1
80
Marinescu
Marin
Craiova
P3
200
Ionescu
Ion
Bucuresti
P2
100
Popescu
Petre
Ploiesti
P3
120
Eliminarea anomaliilor datorate redundantei

Eliminarea anomaliilor provocate de redundanta datelor se poate face:
Fie prin prevederea unor proceduri stocate (sau triggere) care sa verifice
corectitudinea fiecarei operatii de actualizare a relatiilor
Fie prin descompunerea relatiilor care prezinta redundante in relatii mai simple;
exemplu: descompunerea relatiei AP in 2 relatii, A si P
A
P
IdAngajat Nume
Prenume
Adresa
IdAngajat
IdProiect Ore
Ionescu
Ion
Bucuresti
P1
100
Popescu
Petre
Ploiesti
P1
80
Marinescu Marin
Craiova
P1
200
P2
100
P2
120
Relatiile A si P au un grad de normalizare mai ridicat si nu mai au anomalii

Dar unele interogari sunt mai ineficiente in A si P decat in AP
z Exemplu: Care este numrul de ore lucrate de Ionescu la proiectul P1 ?:
Q1 = Ore Nume ='Ionescu' AND IdProiect ='P1 (AP)
Q2 = Ore Nume ='Ionescu' AND IdProiect ='P1 (A P)
Dependente functionale (1)

Dependentele funcionale (functional dependencies) sunt constrangeri in
relatii, prin care valoarea unui anumit set de atribute determina in mod unic
valoarea altor atribute
Fie R o schema de relatie si doua submultimi ale atributelor sale:
X R and Y R . Dependenta functionala (DF) X Y
exista in R daca si numai daca pentru orice stare a relatiei r(R), egalitatea
valorilor atributelor X din doua tupluri t1 si t2 din r (t1 r si t2 r) implica
egalitatea valorilor atributelor Y din acele tupluri, adica:
t1[X] = t2 [X] t1[Y ] = t2 [Y ]
Atributul din stnga se numete determinant, cel din dreapta, determinat
Dependentele functionale sunt generalizarea notiunilor de chei ale relatiilor:
orice cheie determina o DF in acea relatie
Daca Y = R, atunci X este o cheie a relatiei
Reciproc, daca X este o cheie, Y = R (X R)
In acest caz t1[X] = t2 [X] t1 = t2 ,dar, cum intr-o relatie nu pot exista doua
tupluri identice, rezulta ca t1 si t2 sunt unul si acelasi tuplu
Cheile relaiilor:
se pot preciza explicit (i atunci ele implic DF corespunztoare)
pot fi deduse din mulimea DF stabilite de proiectant, folosind diferiti algoritmi
Dependene funcionale (2)

O multime F de dependente functionale in R defineste constrangerile
pe care trebuie sa le respecte orice relatie r(R) pentru a fi legala
(corecta)
Se spune ca F se mentine in R daca toate relatiile legale pe R ( r(R))
satisfac multimea de dependente functionale F
Reciproc, o relatie r este legala in raport cu o multime de dependente
functionale F, daca r satisface F
Proiectantul bazei de date specific acele DF pe care le doreste s

fie respectate i care sunt evidente din punct de vedere semantic;
De exemplu, n relaia AP se pot defini DF:
a) IdAngajat Nume
(b) IdAngajat Prenume
(c) IdAngajat Adresa
(d) {IdAngajat, IdProiect} Ore
Primele 3 impun ca un identificator IdAngajat s identifice un singur

angajat, iar ultima impune ca un angajat efectueaz un anumit numar
de ore la fiecare din proiectele la care lucreaz
Tipuri de dependene funcionale

Atributele care aparin unei chei se numesc atribute prime, iar celelalte
se numesc atribute neprime
Dependene funcionale triviale si ne-triviale
O dependenta functional este trivial daca este satisfacuta de orice stare
a relatiei; in general X Y este triviala daca Y este o submultime (proprie
sau nu) a lui X, adic Y X; ex. {IdAngajat, IdProiect} IdAngajat sau
Nume Nume
Celelalte dependente (in care Y nu este o submultime a lui X) sunt netriviale; ex: IdAngajat Nume
Dependenele funcionale pariale si totale

O dependen funcional X Y este parial dac exist o submulime
proprie Z a lui X (Z X i Z X) care determin funcional pe Y (Z Y);
ex: {IdAngajat,IdProiect} Nume este partiala deoarece IdAngajat Nume
O dependen funcional X Y este total, dac nu exist nici o
submulime proprie Z a lui X care s determine funcional pe Y
Cazuri particulare:
dac atributul X este simplu, dependena funcional X Y este total;
ex: IdAngajat Nume
dac X este o cheie candidat a lui R, atunci dependena X Y este total;
ex: {IdAngajat, IdProiect} Ore
Multimi de dependente functionale (1)
Dintr-o mulime dat de DF se pot deduce si alte DF, folosind

regulile de deducere (inferen - inference rules) ale lui Armstrong:
1. Reflexivitatea (reflexivity): dac Y X, atunci X Y; prin
aceast regul se deduc DF triviale; de ex. n relaia AP n care au
fost definite DF:
(a) IdAngajat Nume
(b) IdAngajat Prenume
(c) IdAngajat Adresa
(d) {IdAngajat,IdProiect} Ore
se pot deduce prin reflexivitate si DF:

(e) {IdAngajat, IdProiect} IdAngajat
(f) {IdAngajat, IdProiect} IdProiect
2. Augmentarea (augmentation): dac X Y, atunci (X Z)

(Y Z); urmtoarele DF (g i h) sunt deduse prin augmentare,
pornind de la dependenele funcionale (a) i respectiv (b),
augmentate cu Z = {Nume}, respectiv Z = {Prenume} (se stie ca
Nume Nume = Nume etc.)
(g) {IdAngajat, Nume} Nume
(h) {IdAngajat, Prenume} Prenume
Multimi de dependente functionale (2)
3. Tranzitivitatea (transitivity): dac XY i YZ, atunci XZ. De

exemplu, din DF (e) i (a) rezult:
{IdAngajat,IdProiect} Nume
Aceste trei reguli sunt suficiente pentru calculul tuturor dependenelor

funcionale pe care le implic o mulime dat de DF
Din aceste reguli de baz se pot deduce i alte reguli; de exemplu:
Proiecia (projection): dac X(Y Z), atunci XY i XZ
Reuniunea (union): dac XY i XZ, atunci X(Y Z)
Pseudo-tranzitivitatea (pseudo-transitivity): dac XY i (W Y) Z, atunci
(W X) Z.
Reprezentarea dependentelor functionale:

Nume
IdAngajat
IdProiect
Prenume
Adresa
Ore
Inchiderea unei multimi de DF

Fiind dat o mulime F de DF, mulimea tuturor DF care sunt implicate de F
se numete nchiderea mulimii F (closure set of F) i se noteaz F+
F+ se poate deduce prin aplicarea repetat a regulilor de inferen asupra DF din F
Pentru a testa daca o DF XY poate fi dedus dintr-o mulime F de DF, se afla
nchiderea F+ a mulimii F i se testeaz dac (XY)F+
Dou mulimi de DF, E i F sunt echivalente dac nchiderile lor sunt egale
(E+ = F+); adica: DF E DF F+ i DF F DF E+
O mulime G de DF este minim dac satisface urmtoarele condiii:

membrul drept al oricrei DF din G este un atribut simplu;
orice dependen funcional din G este total;
mulimea G este ireductibil, adic, dac se exclude o DF din G, mulimea
rezultat H nu este echivalent cu G (adic H+ G+).
Acoperirea minim a unei mulimi F de DF (minimal cover of a set F of

DFs) este o mulime minim de dependene funcionale G care este
echivalent cu F, adic G+ = F+
Pot exista mai multe acoperiri minime ale unei mulimi de DF
10
Dependenele funcionale i cheile relaiilor

In orice relaie pot exista dou categorii de DF:
DF determinate de cheile (candidate) ale relaiei; astfel de DF nu produc redundana
datelor i nici anomalii de actualizare a relaiei; de ex. {IdAngajat, IdProiect} Ore
DF n care atributul determinant nu este o cheie a relaiei; astfel de DF produc
redundana datelor i anomalii de actualizare a relaiei; de ex. IdAngajat Nume
DF determinate de cheile candidate sunt constrngeri implicite, coninute n

definiia relaiei i sunt verificate i impuse automat de SGBD
Proiectantul bazei de date nu trebuie s prevad nimic suplimentar pentru ca aceste
constrngeri s fie satisfcute de orice stare a relaiei
DF n care atributul determinant nu este o cheie sunt constrngeri explicite,

care nu sunt verificate i nici impuse de SGBD
Pentru DF n care atributul determinant nu este o cheie, se aplica una din
urmatoarele solutii:
(a) Se accepta astfel de DF, dar se asigura verificarea i impunerea lor procedurala,
prin triggere, proceduri stocate, sau funcii n programele de aplicaii
(b) Se descompune relatia in relatii mai simple, in care nu mai exista astfel de DF, dar
trebuie fcut o descompunere corecta (cel puin fr pierdere de informaie la
jonciune sau, dac se poate, reversibil)
11
Inchiderea unui atribut fata de o multime de DF (1)

nchiderea unui atribut fa de o mulime F de DF (the closure of an
atribute under F). Fie un atribut X al unei relaii pe care este definit
mulimea F de DF; mulimea X+ a tuturor atributelor determinate de X
(XX+) se numete nchiderea lui X n raport cu F
Algoritmul prin care se poate deduce inchiderea unui atribut:
1. se seteaz X+ = X i P_F = F
2. repet
se extrage o DF YZ din P_F
(adica se alege o DF YZ din P_F si se seteaza P_F = P_F (YZ) )
dac Y X+ atunci X+ = X+ Z
pn cnd P_F =
Se aplic acest algoritm pentru dependenele funcionale din relatia AP:

FAP = {IdAngajat Nume, IdAngajat Prenume, IdAngajat Adresa,
{IdAngajat, IdProiect} Ore}
Se obtin inchiderile atributelor astfel:

{IdAngajat}+ = {IdAngajat, Nume, Prenume, Adresa}
{IdAngajat, IdProiect}+ = {IdAngajat, IdProiect, Nume, Prenume, Adresa, Ore}
{Nume}+ = {Nume}, {Prenume}+ = {Prenume}, {IdProiect}+ = {IdProiect};
{Adresa}+ = {Adresa}, {Ore}+ = {Ore}
12
Inchiderea unui atribut fata de o multime de DF (2)

Din algoritmul de mai sus se poate deduce c nchiderea unui atribut care
nu determin funcional nici un alt atribut (nu apare n partea stng a nici
unei DF) este chiar atributul respectiv:
{Nume}+ = {Nume}, {Prenume}+ = {Prenume}, {Adresa}+ = {Adresa}, {Ore}+ = {Ore}
Acest algoritm poate fi folosit pentru a verifica dac o DF dat XY este

consecina logic a mulimii F (daca (XY) F+)
Pentru aceasta, se calculeaz X+ fa de F; dac Y X+, atunci (XY) F+, deci
XY este consecina logic a lui F
Acest algoritm poate fi folosit i pentru a verifica dac un atribut K (simplu

sau compus) este supercheie a relaiei R cu mulimea F de DF
Pentru aceasta se calculeaz K+ n raport cu F; daca K+ = R, atunci K este
supercheie n R
Pentru aflarea cheilor candidate ale unei relaii din mulimea DF:
se consider o supercheie a relaiei
se testeaza condiia de ireductibilitate pentru fiecare din atributele componente
ale supercheii si se elimin orice atribut care poate fi eliminat fr s se piard
proprietatea de unicitate a cheii
Acest algoritm de aflare a cheilor candidate ale unei relaii din mulimea DF
este prezentat in continuare
13
Aflarea cheilor unei relaii din multimea DF

Fiind dat o relaie cu schema R i mulimea F a DF pe aceast relaie, cheile
candidate K ale relaiei se pot afla cu urmatorul algoritm:
1. Se seteaz supercheia K = R
2. Pentru fiecare atribut X din K se testeaza daca (K X) este supercheie n R
3. Dac (K X) este supercheie, atunci K = (K X), altfel K nu se modifica
Prin parcurgerea repetat a pailor 2 i 3, se gsete una din cheile candidate

ale relaiei; dac exist mai multe chei candidate, atunci ordinea gsirii cheilor
candidate depinde de atributul selectat n pasul 2 al algoritmului
De exemplu, se aplic algoritmul de mai sus pentru gsirea unei chei candidate
a relaiei AP cu mulimea FAP a DF (definita la inceputul capitolului)
Se pornete cu K = R = {IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore}, se
selecteaz X = Nume;
{K X} = {IdAngajat, Prenume, Adresa, IdProiect, Ore}
{K X}+ = {IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore} = R,
deci K - X este supercheie in R, deci se repet paii 2 i 3 pentru alte atribute
Se repeta pasii 2 si 3 pentru X = Prenume, apoi X = Adresa si X = Ore; aceste

atribute pot fi eliminate, si se obtine K = {IdAngajat, IdProiect}
Atributele IdProiect, IdAngajat nu se pot elimina din K, deci {IdProiect, IdAngajat}
e cheie candidat (chiar primar)
14
Descompunerea relatiilor
O descompunere D = {R1, R2,..Ri,...Rk} a schemei de relaie R (relation
schema decomposition) este format din submulimi proprii ale lui R (R1 R,
R2 R,Rk R a caror reuniune este egala cu R (R = R1 R2 Rk)
Proiectiile relatiei r(R) pe submultimile R1, R2,...Ri, Rk (r1 = R1(r), r2 =
R2(r), .. ri = Ri(r), rk = Rk(r)) reprezinta descompunerea relaiei r(R) pe
aceste submulimi de atribute
Fie o relaie cu schema R i mulimea F de DF ale acesteia; o descompunere
a relaiei r(R) este reversibil dac are proprietile de:
Conservarea informatiei (descompunere fr pierdere de informaie la jonciune)
inseamna ca r = r1 r2 ri rk
Conservarea dependenelor funcionale: dac oricare din dependenele din F se
regsete sau poate fi dedus din DF ale relaiilor cu schemele R1,R2,...Ri,Rk
Teorema lui Ullman. Descompunerea D = {R1, R2} a unei scheme de relaie

R este o descompunere fr pierdere de informaie la jonciune n raport cu
mulimea F de DF, dac i numai dac este ndeplinit una din condiiile:
(a) ((R1 R2) (R1 - R2)) F+, sau (b) ((R1 R2) (R2 - R1)) F+
Dac R1 R2 este o supercheie a uneia dintre relaiile R1 sau R2, atunci
descompunerea este fr pierdere de informaie la jonciune;
Demonstratie: dac (R1 R2) este o supercheie n R1, atunci ea determina functional
orice submultime de atribute din R1, inclusiv (R1 - R2) adic (R1 R2) (R1 - R2);
La fel se demonstreaza daca (R1 R2) este o supercheie n R2
15
Descompunere fr pierdere de informaie la jonctiune

Lipsa acestei proprieti se manifest n mod paradoxal prin apariia unor
tupluri noi (parazite) n relaia obinut prin jonciunea relaiilor r1,r2,...ri,...rk,
tupluri care nu existau n relaia r(R)
Exemplu: descompunerea relaiei AP n relaiile A i P:
A P = {IdAngajat},
A P = {Nume,Prenume,Adresa}; P A = {IdProiect,Ore}
Din DF IdAngajatNume, IdAngajatPrenume, IdAngajat Adresa
Se deduce: IdAngajat{Nume, Prenume, Adresa} (cf. regulii de reuniune a DF)
Rezult: ((A P)(A P)) F+
Deci, conform teoremei lui Ullman desc. este fr pierdere de informaie la jonciune
Descompunerea succesiv fr pierdere de informaie la jonciune

Dac o descompunere D = {R1,R2,...Ri,...Rk} a unei scheme R este fr pierdere
de informaie la jonciune n raport cu mulimea F de DF
i D1 = {Q1,Q2,...Qm} este o descompunere fr pierdere de informaie la
jonciune a lui R1 n raport cu proiecia lui F pe R1,
atunci descompunerea D2 = {Q1,Q2,...Qm,R2,...Rk} este o descompunere fr
pierdere de informaie a lui R n raport cu F
Aceast proprietate permite descompunerea fr pierdere de informaie la

jonciune a unei relaii n mai multe etape (mai nti in dou relaii, apoi
fiecare dintre acestea se descompune n alte dou relaii, .a.m.d)
16
Conservarea dependenelor funcionale

O descompunere D = {R1, R2, ...Ri,...Rk} a unei scheme de relaie R prezint
proprietatea de conservare a mulimii F de DF, dac reuniunea proieciilor lui
F pe schemele de relaii Ri (unde 1 i k) este echivalent cu F, adic:
((R1(F)) (R2(F)) ... (Rk(F)))+ = F+
Proiecia unei mulimi de dependene funcionale. Fiind dat mulimea F
de DF definite pe R, i o descompunere D = {R1,R2,..Rk} a lui R, proiecia lui
F pe Ri (unde 1 i k), notat Ri(F), este mulimea de DF XY F+, astfel
nct X Ri i Y Ri
Exemplu: descompunerea relaiei AP in relaiile A i P:
FAP = {IdAngajatNume, IdAngajatPrenume,
IdAngajatAdresa,{IdAngajat,IdProiect}Ore}
Proieciile mulimii FAP pe A si P sunt:
A(FAP) = {IdAngajatNume, IdAngajatPrenume, IdAngajatAdresa}
P(FAP) = {{IdAngajat,IdProiect}Ore}
Dat fiind c A(FAP) P(FAP) = FAP, rezult c aceast descompunere conserv DF
Dac, prin descompunerea unei relaii, se pierd una sau mai multe DF, pentru
verificarea lor, trebuie s se efectueze mai nti jonciunea relaiilor obtinute
Cele dou proprieti ale unei descompuneri, conservarea informaiei i
conservarea dependenelor funcionale, sunt independente
17
Formele normale ale relatiilor (FN1 si FN2)

O relaie este normalizat n prima form normal (FN1) dac fiecare atribut
ia numai valori atomice i scalare din domeniul su de definiie
Sistemele SGBD relaionale nu admit relaii care s nu fie cel puin n FN1, dar
proiectarea relaiilor normalizate n FN1 este intotdeauna posibila
Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaie

r(R) este normalizat n FN2, dac este n FN1 i dac n F+ nu exist nici o
DF parial a unui atribut neprim fa de o cheie a relaiei
Exemplu: relatia AP cu multimea FAP de DF este in FN1, dar nu este in FN2:
FAP = {IdAngajat Nume, IdAngajat Prenume,

IdAngajat Adresa, {IdAngajat, IdProiect} Ore}
Cheia primara este {IdAngajat, IdProiect}, deci {IdAngajat, IdProiect}Nume
Aceast DF se poate deduce din FAP; cf. reflexivitatii, {IdAngajat, IdProiect}
IdAngajat; cf.tranzitivitatii, daca IdAngajatNume, {IdAngajat, IdProiect}Nume
DF {IdAngajat, IdProiect}Nume este parial deoarece exista: IdAngajatNume
Rezult c relaia AP nu este n FN2, deci prezinta redundante si anomalii
Anomaliile se pot evita prin (a) normalizare sau (b) prin impunerea DF
Normalizarea relatiei AP prin descompunere in relatiile A si P:
A(IdAngajat, Nume, Prenume, Adresa)
P(IdAngajat, IdProiect, Ore),
S-a demonstrat ca aceasta descompunere prezinta proprietatile de jonctiune fara
pierdere de informatie si conservarea DF si se poate arata ca A si P sunt in FN2
18
Impunerea DF in relatia nenormalizata AP (1)

Dac relaia AP nu se normalizeaz, atunci trebuie s se prevad proceduri
speciale care s impun DF care nu sunt determimate de chei
De exemplu, daca la inserare nu se admit doi sau mai muli angajai cu acelasi
identificator (IdAngajat) dar cu nume, prenume, adres diferite se defineste
urmatorul trigger (trigger_AP)
Trigger-ul trigger_AP arata astfel:
DELIMITER $$ DROP TRIGGER IF EXISTS `normalizare`.`trigger_AP`$$
CREATE TRIGGER `trigger_AP` BEFORE INSERT ON `normalizare`.`AP` FOR EACH ROW
BEGIN DECLARE done INT DEFAULT 0;
DECLARE error INT DEFAULT 0;
DECLARE l_nume, l_prenume, l_adresa VARCHAR(20);
DECLARE cursor_AP CURSOR FOR SELECT Nume, Prenume, Adresa FROM AP
WHERE IdAngajat = NEW.IdAngajat;
OPEN cursor_AP;
REPEAT FETCH cursor_AP INTO l_nume, l_prenume, l_adresa;
IF NEW.Nume <> l_nume OR NEW.Prenume != l_prenume OR NEW.Adresa <> l_adresa
THEN SET error = 1; END IF;
UNTIL done = 1 OR error = 1
END REPEAT; CLOSE cursor_AP;
IF error = 1 THEN SET NEW.IdAngajat = NULL;
END IF;
END $$ DELIMITER ;
19
Impunerea DF in relatia nenormalizata AP(2)

Trigger-ul este de tip BEFORE INSERT, astfel ca linia dorita se insereaza in
tabel numai daca verificarile facute de trigger permit inserarea
In trigger se citesc intr-un cursor toate liniile care au valoarea atributului
IdAngajat egal cu valoarea de inserat (NEW.IdAngajat)
Se parcurg liniile cursorului si daca valorile de inserat ale atributelor Nume,
Prenume, Adresa (NEW.Nume, NEW.Prenume, NEW.Adresa) difera de cele
existente in tabel, se seteaza error = 1. Daca dupa parcurgerea cursorului:
error = 0, se termin triggerul (instructiunea END), apoi se introduce linia noua
error=1, se seteaza SET NEW.IdAngajat = NULL, apoi se termin triggerul
(instructiunea END); dup aceasta SGBD-ul nu va introduce linia noua deoarece un
atribut al cheii primare este NULL (IdAngajat)
Exemplu:
Fie tabelul AP cu liniile (1,Ionescu,Ion, Bucuresti,1,50), (1,Ionescu,Ion,
Bucuresti,2,100) si (1,Ionescu,Ion,Bucuresti,3,80)
Se observa redundanta datelor: valorile Ionescu, Ion, Bucuresti sunt memorate
pentru fiecare proiect la care lucreaza angajatul cu IdAngajat = 1
Anomalia de inserare: daca nu se activeaza trigger-ul, se poate insera si linia
(1,Marinescu,Mihai,Bucuresti,4,60), ceea ce inseamna ca angajatul cu
IdAngajat =1 este nedeterminat (este Ionescu Ion sau Marinescu Mihai?)
Aceasta linie nu se poate insera daca s-a activat trigger-ul trigger_AP
20
A treia forma normala (FN3)

Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaie
r(R) este normalizat n FN3, dac este n FN2 i dac oricare DF din F+ a unui
atribut neprim este determinata de o cheie a relatiei
Exemplu: AFS(IdAngajat, Nume, Prenume, Adresa, Functie, Salariu)
FAFS={IdAngajatNume, IdAngajatPrenume, IdAngajat Adresa,
IdAngajatFunctie, FunctieSalariu}.
Cheia primar a relaiei este IdAngajat, i poate fi dedus din FAFS
DF fa de cheia primar (primele patru DF) sunt totale, deci relaia este n FN2
Relaia nu este n FN3 datorita DF FunctieSalariu; prezinta redundante si anomalii
Normalizare prin descompunere in:

AF(IdAngajat, Nume, Prenume, Adresa, Functie)
FS(Functie, Salariu)
Se demonstreaza ca AF si FS sunt in FN3 si ca descompunerea este reversibila

Proiectiile multimii FAFS:
FAF={IdAngajatNume,IdAngajatPrenume,IdAngajat Adresa,IdAngajatFunctie}
FFS = {FunctieSalariu} si se deduc (sau se verifica) cheile relatiilor
PKAF={IdAngajat}, PKFS={Functie}, deci AF si FS sunt in FN3
FAF FFS = FAFS deci descompunerea conserva DF
AF FS = {Functie} si ( Functie Salariu) FAFS, deci, cf. regulii lui Ullman,
descompunerea este fara pierdere de informatie la jonctiune
21
Impunerea DF in relatia nenormalizata AFS (1)

Dac relaia AFS nu se normalizeaz, atunci trebuie s se prevad proceduri
speciale care s verifice i s impun DF care nu sunt determinate de chei
Se poate inlocui operatia de INSERT cu apelul unei proceduri stocate care
verifica mai intai valorile si executa INSERT numai daca acestea respecta DF
Procedura stocata pentru relatia AFS arata astfel:
DELIMITER $$ DROP PROCEDURE IF EXISTS sp_AFS $$
CREATE PROCEDURE `sp_AFS`(OUT error INT, s_id INT, s_nume VARCHAR(20), s_prenume
VARCHAR(20), s_adresa VARCHAR(20), s_functia VARCHAR(20), s_salariu DECIMAL)
DECLARE l_salariu DECIMAL;
DECLARE cursor_AFS CURSOR FOR
SELECT Salariu FROM AFS WHERE Functia = s_functia;
SET error = 0; OPEN cursor_AFS;
REPEAT FETCH cursor_AFS INTO l_salariu;
IF s_salariu <> l_salariu THEN SET error = 1; END IF;
END REPEAT;
CLOSE cursor_AFS;
IF error = 0 THEN
INSERT INTO AFS VALUES (s_id, s_nume, s_prenume, s_adresa, s_functia, s_salariu);END IF;
END$$ DELIMITER ;
22
Impunerea DF in relatia nenormalizata AFS (2)

Fie tabelul AFS care contine liniile: (1, Ionescu,Ion,Bucuresti,inginer,2000),
(2, Popescu,Petre,Craiova,inginer,2000)
Se observa redundanta datelor: valoarea salariului este memorata de fiecare
data pentru o functie anume, desi trebuie sa fie aceeasi (conform DF
Functie Salariu)
Datorita redundantei pot apare anomalii: se poate insera linia (3, Mateescu,
Viorel,Bucuresti,inginer, 2100), care este admis de SGBD, dei nu respect
DF Functie Salariu: pentru functia inginer se admite si salariul 2000 si salariul
2100; (se sterge apoi linia inserata eronat, pentru ca ulterior sa functioneze bine
procedura stocata)
Inserarea liniilor in tabelul AFS prin apelul procedurii stocate sp_AFS inlatura
aceasta anomalii
De exemplu, la apelul procedurii stocate cu aceleasi valori:
call sp_AFS(@error, 7, Mateescu', Irinel', 'Bucuresti','inginer', 2100);
select @error;
se obtine @error=1 si linia respectiva nu va fi introdusa in tabelul AFS
23
Forma normala Boyce-Codd (FNBC)

Fie schema de relatie R si multimea F de DF definite pe aceasta. O relaie
r(R) este n forma normal Boyce-Codd (FNBC) n raport cu F dac este n
FN1 i dac orice DF netrivial din F+ este determinata de o cheie a relaiei
Este evident c o relaie n FNBC este n FN3, dar o relaie n FN3 poate s
fie sau nu n FNBC
Exemplu: relaia EDP(IdElev, IdDisciplina,IdProfesor), cu cheia PK= {IdElev,
IdDisciplina} i cu mulimea FEDP de DF:
FEDP = {{IdElev,IdDisciplina}IdProfesor, IdProfesorIdDisciplina}
Se consider c relaia este n FN1; din FEDP se observ c nu exist DF

pariale fa de cheia relaiei (deci relaia este n FN2) i nu exist nici o DF
a unui atribut neprim fa de un alt atribut neprim, deci relaia este n FN3
Relaia EDP nu este n FNBC, datorit DF a atributului prim IdDisciplina fa
de atributul neprim IdProfesor; aceasta relatie prezint redundante de date
i anomalii de actualizare
Exemplu: fie starea in care tabelul EDP contine liniile (1,1,1) si (2,1,1)
redundanta: disciplina (1) predata de profesorul 1 este memorata de doua ori in
tuplurile (1,1,1) si (2,1,1)
anomalie de inserare: se poate insera si tuplul (1,2,1) care nu respecta DF
IdProfesorIdDisciplina (profesorul 1 preda si disciplina 1 si disciplina 2)
24
Impunerea DF in relatia nenormalizata EDP

Dac relaia EDP nu se normalizeaza, atunci trebuie s se prevad o
procedura care s verifice i s impun DF (IdProfesorIdDisciplina) care nu
este determinata de cheia relatiei, pentru operatiile de INSERT si UPDATE
De ex: se inlocuieste operatia INSERTcu apelul unei proceduri stocate care
verifica mai intai valorile si executa INSERT numai daca acestea respecta DF
DELIMITER $$
DROP PROCEDURE IF EXISTS `sp_EDP`$$
CREATE PROCEDURE `sp_EDP`(INOUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT)
BEGIN DECLARE done INT DEFAULT 0; DECLARE l_Disciplina INT;
DECLARE cursor_EDP CURSOR FOR
SELECT IdDisciplina FROM EDP WHERE IdProfesor = s_Profesor;
SET error = 0; OPEN cursor_EDP;
REPEAT FETCH cursor_EDP INTO l_Disciplina;
IF s_Disciplina <> l_Disciplina THEN SET error = 1; END IF;
END REPEAT;
CLOSE cursor_EDP;
IF error = 0 THEN INSERT INTO EDP VALUES (s_Elev, s_Disciplina, s_Profesor);
END IF; END$$ DELIMITER ;
Pentru verificare: se sterge linia(1,2,1) (daca exista) si se executa:

call sp_EDP(@error,1,2,1); select @error;
se obtine @error = 1 si nu s-a inserat acest tuplu
25
Normalizarea relatiei EDP

Normalizarea relaiei EDP astfel nct relaiile obinute s fie n FNBC se
poate face prin descompunerea acesteia. Se pot ncerca trei descompuneri:
D1 = {EP,PD}, unde EP = {IdElev, IdProfesor},
PD = {IdProfesor, IdDisciplina};
D2 = {ED,PD}, unde ED = {IdElev, IdDisciplin},
PD = {IdProfesor, IdDisciplina};
D3 = {EP,ED}, unde EP = {IdElev, IdProfesor},
ED = {IdElev, IdDisciplina}.
Se poate observa c relaiile rezultate n oricare din aceste descompuneri

sunt relaii n FNBC (fiind relaii formate din dou atribute).
Dintre cele trei descompuneri, descompunerea D1 prezint proprietatea de
jonciune fr pierdere de informaie. ntr-adevr, EP PD = {IdProfesor},
PD EP = {IdDisciplina} i IdProfesorIdDisciplina, deci este ndeplinit
condiia lui Ullman de conservare a informaiei.
Celelalte descompuneri, D2 i D3, nu ndeplinesc aceast condiie.
In oricare din aceste descompuneri se pierde dependena funcional
{IdElev,IdDisciplina}IdProfesor, deci relaia EDP nu poate fi descompus
n mod reversibil n relaii FNBC.
26
Impunerea constrangerilor pierdute prin descompunere (1)

Dac relaia EDP se normalizeaza prin descompunerea (EP, PD) atunci trebuie
s se prevad o procedura care s verifice i s impun constrangerea pierduta
Se pot inlocui operatiile de INSERT in tabelele EP, PD cu apelul unei proceduri
stocate care verifica mai intai valorile si executa INSERT numai daca acestea
respecta constrangerea: {IdElev, IdDisciplina} IdProfesor
DELIMITER $$ DROP PROCEDURE IF EXISTS `sp_EP_PD`$$
CREATE PROCEDURE `sp_EP_PD`(OUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT)
DECLARE l_Elev, l_Profesor, l_Disciplina INT;
DECLARE cursor_EP_PD CURSOR FOR
SELECT IdElev, EP.IdProfesor, IdDisciplina FROM EP, PD
WHERE EP.IdProfesor = PD.IdProfesor ;
SET error = 0; OPEN cursor_EP_PD;
REPEAT FETCH cursor_EP_PD INTO l_Elev, l_Profesor, l_Disciplina;
IF s_Elev = l_Elev AND s_Disciplina = l_Disciplina AND s_Profesor <> l_Profesor
THEN
SET error = 1; END IF;
END REPEAT;
CLOSE cursor_EP_PD;
IF error = 0 THEN
INSERT INTO EP VALUES (s_Elev, s_Profesor);
INSERT INTO PD VALUES (s_Profesor, s_Disciplina);
END IF; END$$ DELIMITER ;
27
Impunerea constrangerilor pierdute prin descompunere (2)

Procedura sp_EP_PD primete ca argumente un flag de eroare i valorile
celor trei atribute IdElev, IdDisciplin, IdProfesor care trebuie sa respecte
constrngerea {IdElev, IdDisciplina} IdProfesor
n aceast procedura se creeaz un cursor n care se ncarc rezultatul
jonciunii naturale ntre relaiile EP i PD pe atributul comun IdProfesor
Pentru fiecare linie a rezultatului jonciunii EP PD se verific respectarea
constrngerii dorite, testnd valorile existente n linia respectiv cu noile valori
care urmeaz s fie introduse:
daca aceast constrngere este respectat, atunci se execut dou instruciuni
INSERT, cate una in foiecare din tabelele EP si PD
daca aceast constrngere nu este respectat, nu se introduce nici o linie
Exemplu: daca tabelul EP contine linia (1,1) si tabelul (PD) contine linia (1,1),
prin INSERT se pot introduce si valorile (1,1,2) pentru (IdElev, IdDisciplina,
IdProfesor) adica liniile: (1,2) in EP si (2,1) in PD; dar aceste valori nu
respecta constrangerea {IdElev, IdDisciplina} IdProfesor deoarece:
in liniile existente (IdElev, IdDisciplina) = (1,1), iar IdProfesor = 1
in valorile de inserat (IdElev, IdDisciplina) = (1,1), iar IdProfesor = 2
In schimb apelul procedurii: call sp_EP_PD(@error, 1,1,2); select @error;

produce @error=1 si nu se introduce nici o linie
28
Dependente multivalorice
O dependen multivaloric - DMV- (multivalued dependency) XY
specificat pe schema de relatie R = {X,Y,Z} stabilete urmtoarele
constrngeri pe care trebuie s le respecte orice relaie r(R): dac exist
dou tupluri t1 i t2 n r astfel ca t1[X] = t2[X]= x, atunci vor exista i tuplurile
t3 i t4 cu urmtoarele proprieti:
t3[X] = t4[X] = t1[X] = t2[X] = x;
t3[Y] = t1[Y] = y1 i t4[Y] = t2[Y] = y2 ;
t3[Z] = t2[Z] = z2 i t4[Z] = t1[Z] = z1 .
Datorit simetriei egalitilor de mai sus, rezulta c, dac ntr-o relaie cu

schema R exist DMV XY, atunci exist i XZ, unde Z = R(XY)
O DF este un caz particular al unei DMV: DF XY este o DMV X Y cu
restricia c unei valori a lui X i corespunde o singur valoare a lui Y
O relaie cu schema R este n a patra form normal (FN4) n raport cu o
mulime F de DF i DMV dac este n FN1 i dac, pentru orice DMV
netrivial XY din F+, X este cheie a relaiei r(R).
Asemnarea acestei definiii cu definiia FNBC: pentru FNBC se impun
restricii DF, iar pentru FN4 se impun restricii DMV
Dac o schem de relaie respect condiia de FN4, atunci nseamn c ea
respect i condiia de FNBC
29
Dependente de jonctiune
Fie o schema de relaie R i R1,R2,...Rk submulimi de atribute ale lui R,
unde R1 R2 ... Rk = R. Se spune c exist o dependen de jonciune
(DJ) pe R, notat *(R1,R2,...Rk), dac i numai dac orice relaie r(R) este
egal cu jonciunea proieciilor relaiei pe submulimile R1,R2,..Rk, adic
r = R1(r) R2(r)... Rk(r).
Rezulta ca:
*(R1,R2,...Rk) este o DJ pe R dac i numai dac descompunerea lui R n
proieciile pe R1,R2,...Rk este fr pierdere de informaie la jonctiune
Relaia r(R) este k-decompozabil fr pierdere de informaie dac exist o DJ

*(R1,R2,...Rk)
Tipuri de DJ (dupa valoarea lui k):

Cazul k = 1 reprezint o DJ trivial
Cazul k = 2 al unei DJ este o DMV; o DMV XY n relaia r(R) reprezint o DJ
*(XY, XZ), unde Z = R(X Y).
In cazul k > 2, DJ nu mai sunt echivalente cu DMV
DJ sunt dificil de identificat i nu exist reguli de deducere (inferen) care

s genereze toate DJ pornind de la o mulime dat
Datorit acestor aspecte, analiza DJ are un pronunat caracter intuitiv
30
Forma normala FN5

O relaie cu schema R este n a cincea form normal (FN5) n raport cu o
mulime F de dependene funcionale, multivalorice sau de jonciune dac
este n FN1 i dac, pentru orice dependen de jonciune *(R1,R2,... Ri,...Rk)
din F+, Ri (unde 1 i k) este o cheie a relaiei r(R)
Avnd n vedere faptul c o dependen multivaloric este un caz special de
dependen de jonciune, iar o dependen funcional este un caz special de
dependen multivaloric, se poate afirma c o relaie care este n FN5, este
implicit n FN4, deci i n FNBC, .a.m.d.
S-a demonstrat c orice relaie poate fi transformat n relaii FN5 (sau FN4,
sau FNBC) printr-o descompunere fr pierdere de informaie la jonciune, dar
nu se asigura conservarea tuturor DF
Conditiile de normalizare in FNBC, FN4 si FN5 se pot rezuma la faptul c ntro relaie normalizat nu exist dect dependene determinate de chei:
O relaie este n FNBC dac orice DF este determinat de o cheie a relaiei
O relaie este n FN4 dac orice DF sau DMV este determinat de o cheie a relaiei
O relaie este n FN5 dac orice DF, DMV sau DJ este determinat de o cheie a
relaiei
31
Proiectarea relatiilor normalizate

Normalizarea relaiilor asigur un proiect al bazei de date mai concis i de
aceea se consider c a normaliza este avantajos, chiar dac normalizarea
nu este o garanie c s-a realizat cel mai bun model
Proiectarea bazelor de date pornind de la diagrama Entitate-Asociere
conduce, n general, la relaii normalizate, deoarece:
Relaiile corespunztoare mulimilor de entiti sunt, de regul, relaii
normalizate, dat fiind c toate atributele descriu tipul de entitate respectiv.
Relaiile de asociere binar, care conin dou chei strine care refer cheile
primare din cele dou relaii pe care le asociaz, rezult tot ca relaii normalizate
Relaiile care modeleaz asocierile multiple pot s rezulte nenormalizate i
necesit operaii de normalizare suplimentare
Dar, cu ct nivelul de normalizare crete, cu att se obin mai multe relaii

cu grad mai mic i pentru fiecare interogare sunt necesare mai multe
operaii de jonciune, ceea ce face ca timpul de execuie a interogrilor s
creasc; in general, se recomand ca:
relaiile asupra crora se efectueaz operaii de actualizare frecvente s fie
normalizate ntr-o form normal ct mai avansat
relaiile asupra crora se efectueaz interogri frecvente pot fi pstrate ntr-o
form de normalizare mai redus
Mentinerea unei relaii ntr-o form de normalizare mai redus se numete

denormalizare, i are scopul de a obine performane ridicate la interogri
32
Algoritmi de normalizare
Analiza normalizrii relaiilor trebuie s fie facuta pentru orice proiect de
baze de date, pentru a asigura funcionarea corect a acesteia:
Dac o relaie se pstreaz ntr-o form de normalizare mai redus, atunci
trebuie s se prevad proceduri de verificare i impunere a dependenelor de
date care nu sunt determinate de cheile relaiei (ca si constrngeri explicite)
Dac se normalizeaza o relaie, dar prin descompunere se pierd unele DF,
acestea pot fi impuse explicit prin proceduri stocate sau funcii n programele de
aplicaie, care execut jonciunea ntre relaiile rezultate i impun constrngerea
respectiva
S-a demonstrat si exista algoritmi prin care orice relatie poate fi

descompusa reversibil (cu conservarea informatiei si conservarea DF) in
relatii in formele normale FN2 sau FN3
S-a demonstrat si exista algoritmi prin care orice relatie poate fi
descompusa in relatii FN2, FN3, FNBC, FN4 sau FN5 fara pierdere de
informatie la jonctiune, dar se pot pierde unele dependene
33
Descompunerea fara pierdere de informatie la jonctiune (1)

Fiind dat o relaie cu schema R i mulimea F de DF, o descompunere D
fr pierdere de informaie la jonciune n relaii ntr-una din formele normale
FN2, FN3 sau FNBC se poate obine aplicnd algoritmul urmtor:
1. se seteaz D = {R};
2. att timp ct n D exist o relaie Q (cu mulimea FQ a DF) care nu se afl n
forma normal dorit:
- se alege o DF X W din FQ care nu respecta forma normala dorita i se
construiete nchiderea X+ a atributului X i mulimea Y = X+ X;
- n D se nlocuiete relaia Q cu dou relaii: Q1 = X Y i Q2 = X Z, unde
Z = Q (X Y);
Demonstraie:
La fiecare pas de execuie a algoritmului, o relaie Q se descompune n dou
relaii Q1 i Q2, astfel nct Q1 Q2 = X, i Q1 Q2 = Y
Din definiia nchiderii unui atribut rezult c XY, deci, conform teoremei lui
Ullman, aceast descompunere este fr pierdere de informaie la jonciune
Astfel de descompuneri succesive pstreaz caracterul de descompuneri fr
pierdere de informaie la jonciune
Exist algoritmi similari pentru descompunerea far pierdere de informatie

la jonciune a unei relaii in relaii n forme normale FN4 sau FN5
34
Descompunerea fara pierdere de informatie la jonctiune (2)

Exemplu de aplicare a algoritmului pentru descompunerea in relatii FNBC a
relatiei R = {dAngajat, Nume, Prenume, Adresa, Functie, Salariu, IdProiect,
Ore} cu PK = {IdAngajat, IdProiect}, aflata n FN1 i cu mulimea F de DF
F = {IdAngajatNume,IdAngajatPreume, IdAngajatAdresa,IdAngajatFunctie,
FunctieSalariu, {IdAngajat,IdProiect}Ore}
Executia algoritmului:
Se seteaz D = {R}
Din F se alege DF IdAngajatNume care nu respect condiia impus de FNBC
nchiderea atributului X=IdAngajat este [IdAngajat]+= {IdAngajat, Nume,
Prenume, Adresa, Functie, Salariu} i rezult Y = X+ X = {Nume,Prenume,
Adresa, Functie, Salariu} i Z = R (X Y) = R - X+ = {IdProiect,Ore}.
Se obtine descompunerea D a relaiei R: D = {R11, R12}, unde
R11 = X Y = {IdAngajat, Nume, Prenume, Adresa, Functie, Salariu}; in FN2
R12 = X Z = {IdAngajat, IdProiect, Ore}; in FNBC
In acelasi mod se descompune relaia R11, in relatiile R111 si R112:
R111 = {Functie, Salariu}; este in FNBC
R112 = {IdAngajat, Nume, Prenume, Adresa, Functie}; este in FNBC
Se poate demonstra usor ca descompunerea obtinuta D= (R111, R112, R12)

conserva si dependentele functionale
35
36

Baze de Date

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

Uploaded by

Copyright:

Available Formats

Proictarea Bazelor de Date

Facultatea de Electronica, Telecomunicatii si

Prof. Felicia Ionescu

MySQL Documentation - http://dev.mysql.com/doc/

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Evolutia sistemelor de baze de date

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Sisteme de baze de date

Activitati bancare si comerciale (depozite bancare, vanzari produse)

Productie (gestiunea stocurilor, gestiunea financiar-contabila, salarizare etc.)

Evidenta populatiei, taxe si impozite

Servicii (servicii medicale, rezervari bilete de calatorie etc.)

Fise de evidenta (mentinute manual)

Baze de date mentinute computerizat

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Componentele unui Sistem de Baze de Date (1)

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Componentele unui Sistem de Baze de Date (2)

Datele persistente sunt memorate in fisiere pe hard-disk

Cap.1 - Introducere in Baze de date

Arhitectura interna a unui Sistem de BD

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Avantaje oferite de Sistemele de BD

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Clasificarea Sistemelor de Baze de Date (1)

Clasificare dupa numarul de utilizatori

Clasificare dupa numarul de statii pe care este memorata baza de date:

Cap.1 - Introducere in Baze de date

Clasificarea Sistemelor de Baze de Date (2)

Sisteme de baze de date centralizate: a- mono-utilizator; b- multi-utilizator

Sistem de baze de date distribuit

Cap.1 - Introducere in Baze de date

Tehnica de identificare a trsturilor caracteristice eseniale ale unui sistem

Trecerea de la modelul conceptual de nivel nalt la un model de date

Cap.1 - Introducere in Baze de date

Un atribut (attribute) este o proprietate care descrie un anumit aspect al

Tip de entitate (entity type): se refera la entittile similare, care pot fi

Multime de entitati (entities set): colecia tuturor entitilor de acelai tip

O entitate este o instanta a unui tip de entitate si un element al multimii de

Cap.1 - Introducere in Baze de date

Categorii (tipuri) de asocieri binare - dup numrul elementelor din fiecare

unul-la-unul (one-to-one) 1:1; exemplu: sot-sotie

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Categorii de asocieri binare (1)

Asocieri binare intre multimile de entitati A si B

Cap.1 - Introducere in Baze de date

Categorii de asocieri binare (2)

Asocieri binare intre multimile de entitati A si B

Cap.1 - Introducere in Baze de date

Raport de cardinalitate (cardinality ratio): raportul dintre valorile

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Tip de entitate slab

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

Asociere binar 1:N