Sunteți pe pagina 1din 200

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

Prof. Felicia Ionescu

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

Prof. Felicia Ionescu

Cap.1 - Introducere in 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)

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in 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)
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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.
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze 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
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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.

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Atribut

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

GradRudenie

Cap.1 - Introducere in Baze de date

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)
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

TEHNICIAN

INGINER

Calificare

Specialitate

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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)


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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)
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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


Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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
Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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)

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

28

Sisteme de Gestiune a Bazelor de date


Sisteme Comerciale
Oracle ($$$$)
DB2 (IBM) ($$$)
SQL Server (Microsoft) ($$)
Sisteme Open Source
PostgreSQL
MySQL

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

29

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

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

Prof. Felicia Ionescu

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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);
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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);

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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:
CREATE TABLE ANGAJATI (
Nume
varchar(20) NOT NULL,
Prenume
varchar(20) NOT NULL,
DataNasterii
date NULL,
Functie
varchar(20),
Salariu
numeric);
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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:
CREATE TABLE ANGAJATI (
Nume
varchar(20) NOT NULL,
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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
varchar(50) NOT NULL,
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:
CREATE TABLE ANGAJATI (
IdAngajat
int PRIMARY KEY AUTO_INCREMENT,
Nume
varchar(20)
NOT NULL,
Prenume
varchar(20)
NOT NULL,
DataNasterii
Date,
Adresa
varchar(50),
Salariu
numeric) ;
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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}
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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:
CREATE TABLE ANGAJATI (
IdAngajat
int PRIMARY KEY,
Nume
varchar(20) NOT NULL,
Prenume
varchar(20) NOT NULL,
IdSecie
int,
CONSTRAINT FK FOREIGN KEY (IdSectie) REFERENCES SECTII(IdSectie));
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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:
CREATE TABLE ANGAJATI (
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);
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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,..)

Prof. Felicia Ionescu

(6)(Ionescu,.)

(3)(Carol,...)

Cap. 2 - Baze de date relationale

(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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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)
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

46

Indexuri secundare (2)


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)
Prof. Felicia Ionescu

(Ene) (L5)
Cap. 2 - Baze de date relationale

(Marin) (L4)

(Popa) (L2)
47

Indexuri secundare (3)


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
Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

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

Prof. Felicia Ionescu

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.
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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.
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu
Cap. 3 - Interogarea bazelor de
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:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
INTERSECT
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Diferenta:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
MINUS
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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;
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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;
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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.

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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;
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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)
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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;
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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.... ;
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


date

20

Exemplu: interogare in trei relatii (2)

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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);
Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


date

22

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de


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
Prof. Felicia Ionescu

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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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


Prof. Felicia Ionescu

Instruciuni de descriere a datelor

Testarea datelor
Cap. 4 - Dezvoltarea sistemelor
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

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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)

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

INGINERI

SECRETARE

FURNIZORI

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


de baze de date

Diagrama logic a bazei de date


INTREPRINDERE (1)
Dezvoltata in Microsoft Access

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


de baze de date

Diagrama logic a bazei de date


INTREPRINDERE (2)
Dezvoltata in MySQL Workbench

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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)
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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)
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


de baze de date

12

Proiectarea asocierilor (2)


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


Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


de baze de date

13

Proiectarea asocierilor (3)


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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


Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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)
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

REPEAT...UNTIL
WHILE
BREAK
CONTINUE

FOR

Cap. 4 - Dezvoltarea sistemelor


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)
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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;
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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');


Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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 ;
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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:


FETCH cursor_examene INTO id_student, media;
WHILE done = 0 AND id_student <> student DO
FETCH cursor_examene INTO id_student, media;
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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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.

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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).
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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)

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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

Prof. Felicia Ionescu

Driver

Sursa
de date

SGBD i Baza
de date

Cap. 4 - Dezvoltarea sistemelor


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
Prof. Felicia Ionescu

Protocoale de acces
specifice SGBD-urilor
Cap. 4 - Dezvoltarea sistemelor
de baze de date

32

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor


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


Prof. Felicia Ionescu

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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


Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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))
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

T2

write(X) w2(X)
Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

(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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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

Prof. Felicia Ionescu

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

Cap. 5 - Gestiunea tranzactiilor

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)
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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 ;
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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)

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

29

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

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
Prof. Felicia Ionescu

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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}
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
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 ;

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
BEGIN DECLARE done INT DEFAULT 0;
DECLARE l_salariu DECIMAL;
DECLARE cursor_AFS CURSOR FOR
SELECT Salariu FROM AFS WHERE Functia = s_functia;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
SET error = 0; OPEN cursor_AFS;
REPEAT FETCH cursor_AFS INTO l_salariu;
IF s_salariu <> l_salariu THEN SET error = 1; END IF;
UNTIL done = 1 OR error = 1
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 ;
Prof. Felicia Ionescu
Cap. 6 - Normalizarea relatiilor
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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
SET error = 0; OPEN cursor_EDP;
REPEAT FETCH cursor_EDP INTO l_Disciplina;
IF s_Disciplina <> l_Disciplina THEN SET error = 1; END IF;
UNTIL done = 1 OR error = 1
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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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.
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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)
BEGIN DECLARE done INT DEFAULT 0;
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 ;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
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;
UNTIL done = 1 OR error = 1
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 ;
Prof. Felicia Ionescu
Cap. 6 - Normalizarea relatiilor
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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

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
Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

35

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

36