Proiectare Baze de Datepdf

7/14/2019 Proiectare Baze de date.
pdf
Proiectarea Bazelor de Date

Curs
Facultatea de Electronica, Telecomunicatii

si Tehnologia Informatiei
Anul IV – A (INF)
Prof. Felicia Ionescu
http://info.tech.pub.ro/~fionescu
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf 1/194
7/14/2019 Proiectare Baze de date.pdf
Capitolul 1: Introducere

Definitii – 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
Baze de date, 2008 Prof. Felicia Ionescu 2

Sisteme de baze de date

 Bazele de date se folosesc in aproape toate domeniile de activitate actuale:
● Activitati bancare si comerciale (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 colecţie 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 colecţie de date creată şi
menţinută computerizat, care permite operaţii de:
● Introducere (insert)
● Stergere (delete)
● Actualizare (update)
●
Interogare (query)
Componentele unui Sistem de Baze de Date (1)
 Un sistem de baze de date (Database System) este un sistem

computerizat de menţinere a evidenţei unei anumite activităţi, 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) - recepţionează cererile utilizatorilor de acces la baza de date,
le interpretează, execută operaţiile corespunzătoare şi returnează rezultatul
● Aplicatii de baze de date: (Database Applications) – sunt programe care ofer ă
anumite utilizari ale unei baze de date

Componentele unui Sistem de Baze de Date (2)

Baza de date
Date Date
Utilizator Program
SGBD
final aplicaţie
Date Date
 Utilizatori:
● Programatori de aplicatii
● Utilizatori finali
● Administratorul bazei de date
● Analisti si proiectanti ai bazelor de date
 Datele persistente – sunt memorate in fisiere pe hard-disk
 Limbaje conceptuale pentru lucrul cu bazele de date:
● Limbaje pentru Definirea Datelor(LDD) (Data Definition Languages – DDL)
● Limbaje pentru Manipularea Datelor (LMD) (Data Manipulation Languages –
DML)
Arhitectura interna a unui Sistem de BD


Arhitectura
conceptual şpe 3 niveluri
i nivelul relativ
extern independente:
(Standard nivelul intern,
ANSI/X3/SPARC nivelul
-1975)
 Schema Ædescrierea datelor pe un anumit nivel: schema interna,
conceptuala si scheme externe (vedere utilizator)
 Corespondente intre niveluri (mappings)
Vedere Vedere Vedere
Nivelul extern utilizator #1 utilizator #2 utilizator #n
Nivelul conceptual Schema conceptuală

SGBD
Nivelul intern Schema internă
Date
memorate

Avantaje oferite de Sistemele de BD
 Compactitate ridicată a datelor

 Reprezentarea unor asocieri complexe intre date
 Timp de dezvoltare a bazelor de date redus
 Viteza mare de actualizare si regasire a datelor

 Redundanta controlata a datelor (si cat mai scazuta)
 Flexibilitate, mentinerea datelor actualizate la zi
 Independenta datelor fata de suportul hardware utilizat
 Securitatea datelor: autentificarea utilizatorilor si autorizarea accesului
 Impunerea de restrictii (constrangeri) de integritate la introducerea si
actualizarea datelor
 Mentinerea integritatii datelor in caz de defecte: salvare si refacere
 Posibilitatea de partajare a datelor intre mai multe categorii de utilizatori
 Posibilitatea de introducere a standardelor

Clasificarea Sistemelor de Baze de Date (1)
 Clasificare dupa modelul de date:

● Modelul de 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

7/14/2019
Clasificarea Sistemelor de Baze de Date (2) Proiectare Baze de date.pdf
Aplicaţie Aplicaţie Aplicaţie Aplicaţie

Client Client Client Client
Reţea
de comunicaţie
Server Server
SGBD SGBD
BD BD
a b
Sisteme de baze de date centralizate: a- mono-utilizator; b- multi-utilizator
Aplicaţie Aplicaţie Aplicaţie

Client Client Client
Reţea
de comunicaţie
Server Server
SGBD SGBD
BD BD
Sistem de baze de date distribuit

Modelarea datelor
 Un model este o abstractizare a unui sistem:
● captează cele mai importante tr ăsături caracteristice ale sistemului (concepte)
● conceptele trebuie sa fie relevante din punct de vedere al scopului pentru care
se defineşte modelul respectiv
 Tehnica de identificare a tr ăsăturilor caracteristice esenţiale ale unui sistem
se numeşte abstractizare.
 Un model de date stabileşte regulile de organizare şi interpretare a unei
colecţii 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ă f ăr ă să detalieze modul de reprezentare sau de prelucrare a datelor -
schemă conceptual ă de nivel înalt
● Modele specializate (modelul ierarhic, modelul reţea, modelul relaţional, etc.) -

descriu reprezentarea mulţimilor de entităţi şi a asocierilor dintre acestea prin
structuri de date specifice - schemă conceptual ă (logic ă )
● Trecerea de la modelul conceptual de nivel înalt la un model de date
specific Æ proiectare logică a bazei de date.
7/14/2019
Modelul Entitate-Asociere
Proiectare Baze de date.pdf
 Modelul Entitate-Asociere (Entity-Relationship Model ) defineste multimile

de entităţi ş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 entităţi(attribute) este o proprietate care descrie un anumit aspect al

uneiatribut
● Exemple: persoanele au nume, prenume, adresa etc.
 Tip de entitate (entity type): se refera la entitătile similare, care pot fi
descrise prin aceleasi atribute
● Exemple: tipul persoana, tipul planta
 Multime de entitati (entities set ): colecţia tuturor entităţilor de acelaşi tip
dintr-o bază de date constituie o mulţime de entităţi
● Exemple: multimea tuturor persoanelor, multimea tuturor plantelor
 O entitate
entitati de este o instanta a unui tip de entitate si un element al multimii 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
7/14/2019
Asocieri
 O asociere (relationship) este o corespondenţă între entităţi din două sau

mai multe mulţimi de entităţi; asocierile pot avea atribute
Tipul asocierii (relationship type) – se refera la asocierile similare, care pot
fi definite intre 2 sau mai multe multimi de entitati
 Multime de asocieri (relationship set ): multimea asocierilor de acelasi tip
 O
deasociere
asocieri este o instanta
de acel tip a unui tip de asociere si un element al multimii
 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): numărul de (mulţimi de) entităţi
asociate; dupa grad, asocierile pot fi:
● binare (de gradul 2, între 2 mulţimi de entităţi) – majoritatea asocierilor
● multiple (între k mulţimi de entităţi, k > 2) – destul de rare
 Categorii de (tipuri de) asocieri binare - după numărul elementelor din
fiecare dintre cele două mulţimi 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
7/14/2019
Categorii de asocieri binare (1)
“unul-la-unul” – 1:1 “unul-la-multe”- 1:N
Asocieri binare intre multimile de entitati A si B
7/14/2019
Categorii de asocieri binare (2)
“multe-la-unul”- N:1 “multe-la-multe”- M:N
Asocieri binare intre multimile de entitati A si B

7/14/2019
Cardinalitatea asocierilor
 Cardinalitatea (multiplicitatea) unei asocieri faţă de o mulţime de entităţi

(cardinality, multiplicity ) este numărul maxim de elemente din acea mul ţ ime
care pot fi asociate cu un element din alt ă mul ţ ime a asocierii
● Exemplu: asocierea “unul-la-multe” dintre mulţimile A şi B prezintă multiplicitatea
1 ţă ţimea A şi multiplicitatea N (se înţelege o valoare oarecare N > 1)

fafa
ţă dede mul
mulţimea B
 Raport de cardinalitate (cardinality ratio): raportul dintre valorile
cardinalităţilor unei asocieri faţă de două din mulţimile de entităţi asociate
● Exemple pentru asocieri binare: 1:1, 1:N, N:1, M:N
● Asocierile multiple (k-are, k > 2) prezintă câte un raport de cardinalitate pentru
fiecare pereche de mulţimi de entităţi pe care le asociază.
7/14/2019
Diagrama Entitate-Asociere Proiectare Baze de date.pdf
 Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezintă

grafic modelul Entitate-Asociere prin mulţimile de entităţi şi asocierile dintre
acestea
 Multimi (tipuri) de entitati:
● Puternice (de sine statatoare)
● Slabe (depind de alte multimi de entitati)
 Notatii:
Tip entitate Tip de entitate puternică
Tip entitate Tip de entitate slabă
Nume
atribut Atribut
A B Asociere binar ă 1:N

1 N între 2 tipuri de entităţi
7/14/2019 Exemplu de diagrama Entitate-Asociere (1) Proiectare Baze de date.pdf
 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)
Număr Buget Nume Salariu
1 N
SECTII ANGAJATI
Cuprind 1 M
Intretin Lucreaza
N N
DEPENDENTI PROIECTE
Nume GradRudenie Denumire Buget
7/14/2019
Exemplu de diagrama Entitate-Asociere (2) Proiectare Baze de date.pdf
 Asocieri:
● Asocierea SECTII - ANGAJATI - 1:N
● Asocierea ANGAJATI - PROIECTE - M:N
● Asocierea ANGAJATI - DEPENDENTI - 1:N
 Raportul
încât de cardinalitate
să reflecte al uneimodul
cât mai corect de este
asocieri stabilit de proiectant astfel
organizare a activităţii modelate
 Modul de stabilire a tipurilor de entităţi şi a asocierilor nu este unic: aceeaşi
funcţionalitate se poate obţine printr-o varietate de diagrame E-A
 O mulţime de entităţi se denumeste printr-un substantiv, iar o asociere se
denumeste (de regula) printr-un verb, deoarece o asociere reprezintă o
interacţiune între entităţi
 Modelul E-A nu precizează modul cum sunt realizate asocierile între
mulţimile de entităţi: 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 entităţile asociate; în modelul relaţional asocierile se realizează prin
egalitatea valorilor unor atribute comune ale multimilor de entităţi (chei)
7/14/2019 Modelul Entitate-Asociere Extins Proiectare Baze de date.pdf
 Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model )

permite definirea de subtipuri ale unui tip de entităţi, care moştenesc
atribute de la tipul de entitate respectiv
 Crearea ierarhiilor: specializare si generalizare
 Tipurile şi a subtipurie formeaza ierarhii de tipuri de entităţi complexe,
organizate pe mai multe niveluri
 Diagrama Entitate-Asociere Extinsa
Nume Prenume DataNasterii Adresa Salariu
ANGAJAT
SECRETARA TEHNICIAN INGINER
VitezaRedactare Calificare Specialitate
7/14/2019 Modelul de date ierarhic
 Modelul ierarhic (Hierarchical Model ): baza de date se reprezinta printr-o

structur ă ierarhică de înregistr ări (records) conectate prin legături (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 programulde cercetări 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 colecţie de câmpuri (fields),
fiecare câmp conţinând valoarea unui atribut.
 Un tip de legătur ă în modelul ierarhic: tip de asociere cu raportul de
cardinalitate 1:N (părinte-fiu) între două tipuri de înregistr ări
 Schema conceptuală a unei baze de date în modelul ierarhic se reprezintă
printr-un num r oarecare de scheme ierarhice
ă
 O schemă ierarhică este un arbore direcţionat, reprezentat pe mai multe
niveluri, în care nodurile sunt tipuri de înregistr ări, iar arcele sunt tipuri de
legături
7/14/2019
Baze de date ierarhice
FACULTATI
FACULTATI FACULTATI
f 1 f 2 f 3
1
N PROFESORI
PROFESORI PROFESORI
p1 p2 p3
M
N STUDENTI
STUDENTI STUDENTI s1 s2 s3 s1 s2 s4
(a) Diagrama E-A (b) Schema ierarhica (c) Arbori de instantiare

a datelor
 Numai
modelullegături de tipul părinte-fiu, care corespund asocierilor 1:1 şi 1:N din
E-A
 Asocierile M:N se pot reprezenta prin multiplicarea înregistr ărilor de tip fiu,
atunci când sunt referite de mai multe înregistr ări de tip părinte
● mare redundanţă a datelor
 Avantaje: simplitatea şi eficienţa de calcul
 Deficiente:
● nu exista separare intre descrierea logica si fizica a datelor
● interogarile trebuie să fie prevăzute explicit in structura datelor
 Utilizari actuale - aplicatii specializate, baze de date XML
7/14/2019
Modelul de date retea
 Modelul reţ ea (Network Model ) foloseşte o structur ă de graf pentru

definirea
Modelele schemei
ierarhic siconceptuale a bazei
retea Æ modele de date
pre-relationale
 Standardizat în 1971, de o comisie DBTG (Database Task Group).
 Sisteme de gestiune comerciale in modelul retea: IDS II (Honeywell),

UNISYS
Nodurile (Burroughs), IDMSde
grafului sunt tipuri (Computer Associates)
entităţi (înregistr
ări - records), iar muchiile
reprezintă asocierile (leg ăturile-links) dintre tipurile de entităţi
 Asocierile M:N se reprezintă f ăr ă duplicarea înregistr ărilor, fiecare
înregistrare putând fi referită de mai multe înregistr ări, ceea ce elimină
redundanţa
 Dezavantaje:
● aceleasi ca si la modelul ierarhic, la care se adauga
● complexitatea mare in reprezentarea datelor
 Actualmente modelul retea este rar utilizat pentru baze de date de uz
general, care necesita interogari
 Există domenii în care modelul retea este util, de exemplu, pentru
reprezentarea scenelor virtuale (baze de date grafice)
7/14/2019 Modelul de date relational
 Modelul relaţ ional (Relational Model ) se bazează pe noţiunea de relaţ ie

(relation) din matematică, care corespunde unei mulţimi de entităţi
 Fundamentat de E.F. Codd (IBM), prin lucrarea "Un model Relaţional de
Date pentru Bănci Mari de Date Partajate" (1970)
 Dezvoltare extraordinara a sistemelor de gestiune a bazelor de date
relationale, datorită simplităţii şi a fundamentării matematice a modelului
 Alte lucr ări ale cercetatorilor C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R.
Fagin, W. Armstrong, M. Stonebraker etc. au perfecţionat modelul relaţional
 Primul Sistem de Gestiune a Bazelor de Date Relaţionale (SGBDR) a fost
prototipul System R (IBM, 1970)
 După aceasta numeroase companii au realizat sisteme de gestiune
relaţionale: Oracle, Microsoft, Ingres, Sybase
 SGBDR folosesc limbajul SQL (Structured Query Language), pentru care
au fost emise mai
Standardization multe standarde
Institute) ANSI (American
si ISO (International National Office)
Standardization
 Majoritatea SGBD-urilor relaţionale actuale implementează versiunea SQL2
(SQL92) si/sau SQL3 (SQL99)
Modelul obiect-orientat
 Modelul obiect (Object Model ) este un concept unificator

 Necesar in domenii in care se manipuleaza date de tipuri complexe:
● proiectarea sistemelor de calcul: programare, hardware, interfete, baze de date
● proiectarea asistată de calculator in alte domenii
● sisteme de informaţii geografice
● medicină şi altele
 Strategii pentru dezvoltarea sistemelor de gestiune a bazelor de date
obiect-orientate (SGBDOO):
● Extinderea unui limbaj de programare obiect-orientat cu capacităţi de
administrare a obiectelor persistente: sistemul GemStone (extinde Java si C++)
● Extinderea unui limbaj de programare relaţional cu capacităţi de orientare spre
obiecte. ExemplU: limbajul ODL (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 aplicaţiilor
● Interogarile trebuie să fie prevăzute explicit in structura datelor
 Utilizare SGBDOO: cam 5% din sistemele de gestiune actuale

7/14/2019
Modelul obiect-relational
 Modelul obiect-relaţ ional (Object-Relational Model ) reprezintă extinderea

modelului relaţional cu caracteristici ale modelului obiect
 Modelul obiect-relaţional păstrează structurarea datelor în relaţii, si, in plus:
● permite definirea unor noi tipuri de date, ca domenii ale atributelor
● permite extinderea tipurilor de date prin mo ştenire

 Sistemele de gestiune a bazelor de date obiect-relaţionale (SGBDOR) se
realizează prin extinderea sistemelor relaţionale, de regula în mod gradat,
adăugându-se de la o versiune la alta cât mai multe caracteristici posibile
ale modelului obiect
 Aceasta abordare asigur ă rularea în continuare a aplicaţiilor relaţionale
existente în noile versiuni de sisteme SGBDOR, ceea ce permite
producătorilor (Oracle, Informix şi IBM) să-şi păstreze clienţii şi domeniile de
utilizare
 Limbajele de programare pentru SGBDOR sunt standarde mai recente ale
limbajului SQL: SQL3 (SQL1999), SQL-2003, SQL-2006
7/14/2019
Complexitatea datelor si a interogarilor Proiectare Baze de date.pdf
 Clasificare propusa de M. Stonebraker (1996)

Complexitatea
interogărilor
SGBDR SGBDOR
Sisteme de fişiere SGBDOO
Complexitatea
datelor
 SGBDR prelucrează tipuri simple de date, dar permit interogări complexe

 SGBDOO prelucrează tipuri de date complexe, dar în care rezolvarea
interogărilor este destul de dificilă
 SGBDOR permit prelucrarea datelor complexe şi rezolvarea interogărilor
complexe; sistemele de baze de date obiect-relaţionale sunt considerate
sisteme de baze de date universale
7/14/2019
Evolutia sistemelor de baze de dateProiectare Baze de date.pdf
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 (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)
7/14/2019
Sisteme de Gestiune a Bazelor de date Proiectare Baze de date.pdf
Sisteme Comerciale
Oracle ($$$$)
DB2 (IBM) ($$$)
SQL Server (Microsoft) ($$)
Sisteme Open Source
PostgreSQL
MySQL
7/14/2019
Capitolul 2: Modelul Relational
 Relatii, atribute, domenii; schema relatiei

 Reprezentarea relatiilor prin tabele
 Limbajul SQL:
● Conventii lexicale
● Expresii, operatori, functii
● Instructiuni de definire a datelor: CREATE, ALTER, DROP
● Instructiuni de manipulare a datelor: SELECT, INSERT, UPDATE, DELETE
 Constrangerile de integritate ale relatiilor
● Constrangeri de domeniu
● Constrangeri de tuplu: cheia primara – chei secundare
● Constrangeri de integritate referentiala – chei straine
 Indexarea relatiilor
● Indexul primar
● Indexuri secundare
Relatii – Atribute – Domenii
 Modelul relational: E.F.Codd, 1970 – IBM

 O baz ă de date relaţ ional ă este compusă dintr-o mulţime finită de relaţii
● fiecare relaţie reprezinta o multime (tip) de entitati sau o multime (tip) de asocieri
● fiecare relatie este unica intr-o baza de date
● o relatie se defineste prin intermediul atributelor sale
 Atributele unei relaţii corespund atributelor tipului de entitate sau de
asociere pe care îl reprezintă relaţia respectivă
● fiecare atribut are un nume (Ai) si un domeniu de definiţie D(Ai)
● pentru o entitate data, un atribut poate lua o singur ă valoare (scalar)
 Atributele pot fi: simple (un element) sau compuse (o submultime de atribute)
 Domeniu: o multime 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 constrangeri
● Elementele domeniilor sunt atomice (indivizibile)
● O valoare speciala, null, apartine oricarui domeniu (inseamna lipsa de informatie
sau valoare necunoscuta)
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf
Schema relatiei 31/194
 Schema relaţiei: descriere a unei relaţii (tipul, intensiunea relaţiei)

Schema relaţiei: R(A1,A2,...Ai,...An), unde:
● R este numele schemei relaţiei
● lista ordonată a atributelor sale A1,A2,...Ai,..An
● fiecare atribut Ai definit pe domeniul său de definiţie, D(Ai)
● Gradul relaţiei: numărul de atribute ale schemei acelei relatii (n)

● Exemplu: STUDENTI (Nume, Prenume, DataNasterii, Adresa, Facultatea)
 O relaţie r definita prin schema R(A1,A2,...Ai,...An) este:
● o mulţime 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)
 Relatia r(R): r este variabila, instanta a schemei (tipului) R
● Valoarea variabilei: starea sau extensiunea relatiei
● Numarul de tupluri ale unei relatii: cardinalitatea relatiei
● Fiecare tuplu este unic intr-o relatie (nu exista tupluri duplicat)
● Corespondenta: relatieÆmultime de entitati (sau de asocieri); tuplu Æ entitate
 In mod curent: se foloseste R atat pentru schema cat si pentru relatia insasi
Reprezentarea relatiilor prin tabele
 Un tabel (table) = reprezentarea grafica a unei relaţii; compus din:

● Numele tabelului - identic cu numele relaţiei
● Coloanele corespund atributelor relatiei
● Capul tabelului- contine numele atributelor (coloanelor) Æ schema relatiei
● O mulţime de linii, fiecare linie corespunzând unui tupluÆ starea relatiei
● Valori ale atributelor fiecarui tuplu
 Exemplu: Tabelul care reprezinta relatia (starea relatiei) STUDENTI
Numele Coloane - Atribute Valori
atribute
STUDENTI
Capul
Nume Prenume DataNasterii Adresa Facultatea tabelului
Anghelescu Octavian 1999 Bucuresti ETTI
Beldiman Cristina 1998 Bucuresti ETTI Linii - tupluri
Boeru Marius 1999 null ETTI
 Tabelul sugereaza ordonarea atributelor (coloanelor) si a tuplurilor (liniilor) –

ceea ce nu corespunde modelului matematic (relatie = multime de tupluri)
Afisarea tabelelor
 SGBD-urile ofera instrumnente de proiectare si afisare a tabelelor

● De exemplu, afisarea tabelului Employees din baza de date Northwind folosind
toolset-ul SQL Query Analyser din Microsoft SQL Server
Ordonarea valorilor atributelor in tupluri
 Din punct de vedere logic, ordinea valorilor atributelor într-un tuplu nu

conteaza; această structurare poate fi exprimată prin următoarele definiţii:
 Schema relaţiei: R = {A1,A2, ...Ai,...An} (o mulţime de atribute)
 Relaţia r(R): o mulţime de n-tupluri t, unde:
● fiecare tuplu t este o mulţime 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)
 Observatii asupra celor doua definitii:
● A doua definitie a relaţiei este mult mai generală decat prima definitie
● Dar prima definitie simplifică notaţiile şi corespunde reprezentării prin tabel a
relaţiei şi de aceea va fi folosită în continuare destul de frecvent
● În implementările reale, există o anumită ordine a valorilor atributelor memorate
in fisiere, dar aceasta nu este relevantă din punct de vedere logic
Limbajul SQL 35/194
 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 si ISO:
Anul Denumire Caracteristici
1986 SQL-86 Publicat de ANSI (SQL1); ratificat de ISO in 1987
1989 SQL-89 Revizii minore
1992 SQL-92 Revizii majore, redenumit SQL2
1999 SQL-1999 Redenumit SQL3, adauga unele caracteristici

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

micşorează gradul de portabilitate a aplicaţiilor
 În diferitele implementări ale limbajului SQL pot să lipsească unele comenzi
prevăzute în standard, dar pot exista extensii specifice
Caracteristicile generale ale limbajului SQL

 Limbajul
care esteSQL
mai foloseste reprezentarea
simplă şi mai prin tabele
intuitivă (foloseste a relatabel,
termenii ţiilor, reprezentare
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 SQL este un limbaj neprocedural:
● modul
o instruc ţiune SQL în
(procedura) specific ă ce
care se ă ţii trebuie să fie setate sau obţinute, nu
informa
opereaz
● limbajul SQL nu conţine instrucţiuni de control al fluxului execuţiei (instrucţiuni ca
for, while, if, etc)
 Pentru aplica iile de baze de date, s-au dezvoltat extensii procedurale ale
limbajului SQL,ţ biblioteci şi interfeţe de programare care integrează
instrucţiunile SQL
Structura lexicala a limbajului SQL

 O instrucţiune SQL (statement ) este o secvenţă de elemente - de regula

terminată cu semnul punct şi virgulă (;)
 Fiecare instrucţiune SQL conţine o comand ă SQL (command ), care specifică
ce acţiune se efectuează, urmată de alte elemente, care specifică operaţii,
clauze, parametri etc.
● Exemplu: SELECT * FROM ANGAJATI;
 Elementele (tokens) instrucţiunilor SQL
● cuvânte cheie (key words): CREATE, INSERT, SELECT , WHERE, FROM etc.
● identificatori (identifiers):
● simpli - numai caractere alfa-numerice si 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: *, ., ;
 Spaţiile albe (whitespaces) separa elementele: spaţiu, linie nouă, tab
 O instructiune se poate scrie pe una sau mai multe linii, iar într-o linie se pot
introduce una sau mai multe instructiuni
 Limbajul SQL este case-insensitive (nu deosebeste literele mici de cele mari)
cu exceptia identificatorilor delimitati (quoted ) care sunt case-sensitive
Expresii si operatori in limbajul SQL

7/14/2019  O expresie SQL constă dintr-unul sau mai mulţi operanzi, operatori şi
paranteze.
● Parantezele se pot folosi pentru a preciza o anumită ordine a operaţiilor, dacă
aceasta este diferită de ordinea implicită data de precedenta operatorilor.
 Un operand poate fi:
● numele unei coloane – in acest caz se foloseste valoarea memorata in 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 cuvânt cheie; exemple: AND, OR, NOT, LIKE etc.
 Operatori SQL: binari sau unari (dupa numarul de operanzi)
 Operatori SQL: aritmetici, logici, de comparaţie SQL, relationali
● 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 relationali: UNION, INTERSECT, MINUS
Operatori SQL 39/194
7/14/2019
 Toti operatorii de comparaţie returneaza valori logice: Proiectare Baze de date.pdf
● true (1), dacă condiţia este îndeplinită

● false (0) dacă condiţia nu este îndeplinită
● null dacă ambii operanzi au valoarea null
 Operatorii logici (NOT, AND, OR):

● se aplică unor variabile logice trivalente (cu 3 valori: true (1), false (0) şinull -
lipsa de informatie)
● returnează o valoare logică trivalentă
A B A and B A or B A 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
Functii SQL 40/194
 Funcţii SQL: funcţii agregat şi funcţii scalare.
 Funcţiile agregat calculează un rezultat din mai multe linii ale unui tabel
● Aceste funcţii vor fi detaliate ulterior, la descrierea instrucţiunii SELECT.
 Funcţiile scalare:
● Primesc unul sau mai multe argumente şi returnează valoarea calculată sau NULL
în caz de eroare
● Argumentele funcţiilor pot fi constante (literale) sau valori ale atributelor specificate
prin numele coloanelor corespunzatoare
 Tipuri de funcţii scalare SQL:
● Funcţii de calcul trigonometric (sin, cos, tan etc.), funcţii de calcul al logaritmului
(ln, log), al puterii (power ), funcţii de rotunjire (floor , ceil), etc.
● Funcţii pentru manipularea şirurilor de caractere: concat, replace, upper etc.
● Funcţii pentru data calendaristică şi timp: add_months, next_day, last_day etc.

● Funcţii de conversie: to_number , to_char etc.
 Funcţiile scalare se folosesc în expresii, care pot să apar ă în diferite clauze
ale instrucţiunilor SQL
Tipuri de date SQL (1) 41/194
 Tipuri de date SQL2: numeric, şiruri de caractere, şiruri de biţi, data
(calendaristică), timp
 Tipul numeric:
● numere întregi: integer sau int (4 octeţi), smallint (2 octeţi)
● numere reale reprezentate în virgulă flotanta: float (4 octeţi), real şi double
[precision] (8 octeţi)
● 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 numărul total de cifre, iar s (scara) este numărul 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 biţi - secvenţe 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
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 câmpuri (year,
month, day), în formatul yyyy-mm-dd; se admit numai date valide
● Tipul time: memorarea timpului, folosind trei câmpuri (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 câmpul 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 - număr întreg pe 1 octet
● SGBD Oracle: varchar2 - şir de caractere de lungime variabilă
 Standardul SQL2 nu suportă tipuri de date şi operaţii definite de utilizator

Standardul SQL3 suport
sunt caracteristice ă tipuri de
ale modelului dedate i operaţii definite
dateşobiect-rela ţional de utilizator, care
 Actualmente, producătorii de sisteme de baze de date relaţionale introduc
treptat diferite caracteristici ale modelului obiect-relaţional cuprinse in SQL3
Domenii SQL 43/194
 In SQL2 domeniile atributelor se specifică pe baza tipurilor de date

predefinite ale limbajului SQL, deci nu corespund intru totul cu noţiunea de
domeniu relaţional
 Standardul SQL2 prevede comanda CREATE DOMAIN, care defineste un
domeniu pe baza unui tip predefinit SQL2 şi cu unele constrângeri
 Această comandă nu prea este implementată în sistemele de gestiune
actuale, care prefer ă alte soluţii de definire a domeniilor. De exemplu:
● In SQL Server, se pot crea aşa-numitele “tipuri definite de utilizator” (user-
defined types), echivalente cu domeniile create cu comanda SQL CREATE
DOMAIN, folosind o procedur ă stocată
● În Oracle (8i, 9i, 10g) se pot crea tipuri de date noi, folosind comanda CREATE
TYPE, care permite gruparea sub un anumit nume a mai multor atribute, de
diferite tipuri (predefinite sau definite de utilizator)
● In PostgreSQL se pot crea tipuri de date noi, folosind comanda CREATE TYPE
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf Conventii de notatie 44/194

7/14/2019
 Pentru prezentarea limbajului SQL si a altor limbaje, biblioteci si interfete
[ ] (paranteze drepte) Element opţional al instrucţiunii

{ } (acolade) Element obligatoriu al instrucţiunii
| (bar ă verticală) Separ ă elementele din parantezele drepte sau
acolade;
introducenumai unulţiunea
în instruc dintrerespectiv
acesteaăse poate
[ , . . . n] Elementul precedent poate fi repetat de n ori;
elementele repetate sunt separate prin virgulă
element1, . . . . . . . Listă de n elemente de acelaşi tip;
elementn elementele repetate sunt separate prin virgulă
lista_elemente Listă de elemente de acelaşi tip separate prin virgulă
 Caracterele folosite pentru a specifica o anumită convenţie sintactică

(paranteze, bara verticală, virgula, etc.) nu apar în instrucţiunile propriu-zise
 Listele de elemente (compuse din mai multe elemente separate prin virgulă)
vor fi exprimate fie folosind una cele trei din construcţiile de mai sus, care se
potriveşte cel mai bine instrucţiunii respective
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf Instrucţiuni SQL 45/194

7/14/2019  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, ALTER FUNCTION, ALTER PROCEDURE
DROP TABLE, DROP VIEW, DROP INDEX, DROP USER
DROP FUNCTION, DROP PROCEDURE, DROP TRIGGER
 Componenta de manipulare a datelor din limbajul SQL (Limbajul de Manipulare
a Datelor - LMD) conţine comenzile: SELECT, INSERT, UPDATE si DELETE
 Instructiunile SQL se transmit SGBD-ului:
● de catre diferite programe client (client grafic, linie de comanda, program executabil)
● SGBD-ul executa instructiunea SQL
● si returneaza un raspuns (rezultatul operatiei sau un cod de eroare)
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf Crearea tabelelor 46/194

 Instrucţiunea CREATE TABLE are următoarea sintaxă:

CREATE TABLE nume_tabel (
col1 domeniu1 [constrangeri_coloana],
col2 domeniu2 [constrangeri_coloana],
.................................
coln domeniun [constrangeri_coloana],
[constrangeri_tabel] );
 Constrângerile impuse fiecărei coloane (atribut), ca şi constrângerile de
tabel, sunt opţionale şi vor fi discutate în sectiunea următoare. Exemplu:
CREATE TABLE ANGAJATI (
Nume varchar(20),
Prenume varchar(20),
DataNasterii date,
Adresa varchar(50),
Functie varchar(20),
Salariu numeric);
 Instrucţiunea CREATE TABLE defineşte atât tipul relaţiei cât şi o variabilă
relaţie care iniţial este vidă (nu conţine nici un tuplu)
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf Crearea vederilor 47/194

7/14/2019
 Tabelele create cu instrucţiunea CREATE TABLE: Proiectare Baze de date.pdf
● se numesc şi tabele de baz ă (base tables)

● ele sunt memorate în fişierele bazei de date şi pot fi accesate pentru
introducerea, modificarea şi regăsirea (interogarea) datelor
 Un tabel vedere (view ) este un tabel virtual care:
● nu este memorat fizic în fişiere
● reprezintă o selecţie (după un anumit criteriu) a datelor memorate în unul sau
mai multe tabele de bază
 Un tabel vedere secreeaza cu instrucţiunea SQL:
CREATE VIEW nume_vedere AS (SELECT...);
 Formatul comenzii SELECT va fi descris în capitolul următor
 Datele (valorile atributelor) sunt memorate o singur ă dată, în tabelele de
bază, dar pot fi accesate atât prin tabelele de bază cât şi prin tabelele
vederi
 Un tabel vedere este întotdeauna actualizat ("la zi"), adică orice modificare
efectuată în tabelele de bază se regăseşte imediat în orice tabel vedere
creat pe baza acestora
Modificarea si stergerea tabelelor si a vederilor

7/14/2019
 Comanda de modificare a tabelelor (ALTER TABLE) permite:
● adăugarea sau ştergerea unor atribute

● modificarea domeniilor unor atribute
● adăugarea, modificarea sau ştergerea unor constrângeri ale tabelului
 Pentru
urmata adaugare
de numeleunei coloane
coloanei intr-un tabel
si numele se foloseste
domeniului clauza
(tipul SQL) ADD,
atributului
corespunzator. Exemplu:
ALTER TABLE ANGAJATI ADD DataAngajarii date;
 Pentru ştergerea unei coloane dintr-un tabel se foloseşte clauzaDROP,

urmata de numele coloanei care se va sterge. Exemplu:
ALTER TABLE ANGAJATI DROP DataAngajarii;
 Instrucţiunile de ştergere a tabelelor de bază şi a vederilor sunt:
DROP TABLE nume_tabel;
DROP VIEW nume_vedere;
Instructiunea SELECT 49/194
7/14/2019  SELECT - instrucţiune de interogare, prin care se regăsesc informaţiile 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 adevărată (are valoarea TRUE).
 Instructiunea SELECT are urmatoarele secţiuni (clauze):
● Clauza SELECT defineşte lista de coloane a tabelului rezultat
Clauza indic lista de tabele din care se selecteaz rezultatul
● FROM ă ă
● Clauza WHERE defineşte condiţia pe care trebuie să o îndeplinească fiecare
linie a tabelului rezultat
● Clauze secundare (ORDER BY, GROUP BY, HAVING): permit ordonări sau
grupări ale tuplurilor (liniilor) rezultate
Clauza SELECT 50/194
7/14/2019  Clauza SELECT specifica: Proiectare Baze de date.pdf
● lista coloanelor unor tabele (date in “lista_tabele”)

● expresii care vor fi calculate şi afişate
 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
caracterul coloanelor produsului
ca si “lista_coloane”. cartezian al tabelelor date - cu
Exemplu:
SELECT * FROM city;
 În clauza SELECT se pot redenumi coloanele tabelelor sau se pot specifica
nume pentru expresii, folosind următoarea sintaxă:
SELECT nume1 [AS] noul_nume1 [,...n] FROM lista_tabele [alte_clauze];
SELECT ID, Name Oras, CountryCode ‘Cod Tara’ FROM city;
Functii agregat 51/194
7/14/2019  În clauza SELECT se pot introduce şi funcţii agregat (totalizatoare).
Funcţiile agregat definite în limbajul SQL2 sunt următoarele:
Functia Valoarea returnata

COUNT Numarul de linii al tabelului rezultat
SUM Suma valorilor din coloana data ca argument
MAX Valoarea maxima din coloana data ca argument
MIN Valoarea minima din coloana data ca argument
AVG Valoarea medie din coloana data ca argument
 Exemple:
SELECT COUNT(*) FROM city;
SELECT MAX(Population) FROM city;
SELECT MIN(Population) FROM city;
SELECT AVG(Population) FROM city;
Clauzele FROM si WHERE

7/14/2019
 Clauza FROM specifica “lista_tabele” din care se selecteaza 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
apar ţin - 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 comparaţiei între doi operanzi folosind un
operator de comparaţie
● un operand poate fi un atribut (nume de coloană), o constantă, valoarea unei expresii
aritmetice sau o valoare returnată de o funcţie
● operatorii de comparaţie pot fi operatori aritmetici sau operatori SQL de comparaţie
 Exemple:
SELECT * FROM city WHERE Population > 1000;
SELECT * FROM city
WHERE Population BETWEEN 1000 AND 100000 AND CountryCode='NLD';
Clauze secundare 53/194
7/14/2019
 Clauza ORDER BY specifica numele atributului după care se face
ordonarea liniilor tabelului rezultat

SELECT * FROM city order by CountryCode;
 Ordonarea în ordine crescătoare: parametrul ASC (implicit); in ordine
descrescatoare:
SELECT * FROMDESC. Exemplu:
city order by CountryCode DESC;
 Clauza GROUP BY se foloseşte pentru gruparea rezultatelor funcţiilor
agregat dupa valoarea uneia sau mai multor coloane. Exemplu:
SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode;
Clauza HAVING inlocuieste clauza WHERE atunci cand in conditia care
trebuie sa fie indeplinita se folosesc functii agregat. Exemplu:
SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode
HAVING AVG(Population) >800000;
Instructiunea INSERT 54/194
 Instrucţiunea INSERT se foloseşte pentru introducerea datelor în tabele şi
are urm toarea sintax :
ă ă
INSERT INTO nume_tabel(col1,col2,...coln) VALUES(val1,val2,...valn);
 Între valori şi numele de coloane trebuie să existe o corespondenţă
pozitionala. 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 si în această situatie:
● ordinea valorilor introduse trebuie să respecte ordinea coloanelor tabelului
● ordinea coloanelor provine din ordinea de definire a atributelor prin instrucţiunea
CREATE TABLE, precum şi din operaţiile ulterioare de alterare a tabelului
● ordinea coloanelor se poate afla prin instrucţiunea DESCRIBE nume_tabel.
 De exemplu, introducerea unei linii în tabelul
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Functia,Salariu)
se poate face cu instrucţiunea:
INSERT INTO ANGAJATI VALUES(100,‘Mihailescu’,
‘Mihai’,‘1950-04-05’,‘Craiova’,’Inginer’, 3000);
Instructiunile UPDATE si DELETE

7/14/2019  Instruc ţ iunea UPDATE permite actualizarea valorilor coloanelor (atributelor)
din una sau mai multe linii ale unui tabel si are sintaxa:
UPDATE nume_tabel SET col1 = expr1 [, . . . n] [WHERE conditie];
 Clauza WHERE: actualizarea valorilor se efectueaza numai asupra acelor linii
care îndeplinesc condiţia dată. Exemplu:
UPDATE ANGAJATI SET Adresa = ‘Bucuresti’ WHERE Nume = ‘Popescu’;
 Dacă este omisă clauza WHERE, vor fi modificate valorile coloanelor din toate
liniile tabelului.
 Instruc ţ iunea 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 condiţia dată în clauza WHERE.
Dacă este omisă clauza WHERE, vor fi sterse toate liniile din tabel.
 Exemplu:
DELETE FROM ANGAJATI WHERE Nume =‘Ionescu’;
Constrangeri de integritate (1)

 Constrângerile de integritate (integrity constraints) sunt reguli care:
● se definesc la proiectarea bazei de date

● trebuie să fie respectate de orice stare a acesteia
● astfel incat datele memorate să corespundă cat mai bine celor din realitate
 Clasificare dupa locul unde se definesc: constrangeri de coloana si
constrangeri de tabel (in instructiunea CREATE TABLE)
 Clasificare dupa numarul de relatii implicate: constrângeri intra-relaţie şi
constrângeri inter-relaţii.
 Constrângerile intra-relaţie - reguli care se impun în cadrul unei singure
relaţii; de trei categorii:
● Constrângeri de domeniu - condiţii ce se impun valorilor domeniilor atributelor
● Constrângeri de tuplu - condiţii ce se impun tuplurilor unei relaţii prin chei
(primare sau secundare).
● Constrângeri impuse prin dependenţe de date (dependenţe funcţionale,
multivalorice sau de joncţiune); acestea sunt constrângeri intre valorile atributelor
dintr-o relaţie
 Constrângerile inter-relaţii - reguli care se impun între două sau mai multe
rela ii; asigura integritarea referen ial prin intermediul cheilor str ine
ţ ţ ă ă
Constrangeri de integritate (2)

 Clasificare din punct de vedere al modului de definire: constrângeri
inerente, implicite şi explicite.

 Constrângerile inerente sunt cele ale modelului de date însu şi, care nu
trebuie să fie specificate la definirea relaţiilor, dar sunt respectate prin
modul în care se construiesc relaţiile
● De exemplu: în modelul relaţional constrângerea ca valoarea fiecărui atribut să
fie atomică (indivizibilă) este o constrângere inerentă
 Constrângerile implicite sunt reguli care se definesc odată cu definirea
schemelor relaţiilor, sunt memorate în baza de date şi sistemul de gestiune
verifică şi impune automat respectarea acestora
● Exemple: connstrângerile de domeniu, constrângerile de tuplu şi constrângerile
de integritate referenţială sunt constrângeri implicite.
 Constrângerile explicite sunt constrângeri suplimentare pe care trebuie s ă
le respecte
sistemul relaţiile
SGBD, unei baze
ci necesit de date speciale
ă proceduri
şi care nu sunt impuse automat de
de verificare şi impunere
● Exemple:dependenţele de date care nu sunt determinate de cheile relaţiilor
Constrangeri de domeniu (1)

 Constrângerile de domeniu : constrângerea NOT NULL, constrângerea de
7/14/2019
valoare implicită (DEFAULT), constrângerea de verificare (CHECK)
 Constrângerea NOT NULL însemna că atributul respectiv nu poate lua

valoarea NULL în nici un tuplu al relaţiei.
 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 cunoaşte valoarea unui atribut in momentul inserarii tuplului, dar aceasta
va fi cunoscuta si completată ulterior
 La crearea unui tabel opţiunea NULL este implicită (nu se specifică nimic),
sau se poate introduce explicit; optiunea NOT NULL se introduce explicit.
 Optiunile NULL si NOT NULL se introduc ca si constrangeri de coloana in
instructiunea SQL CREATE TABLE. Exemplu:
Nume varchar(20) NOT NULL,
Prenume varchar(20) NOT NULL,
DataNasterii date NULL,
Adresa varchar(50) NOT NULL,
Functie varchar(20),
Salariu numeric);
Constrangeri de domeniu (2)

 Constrangerea de valoare implicita a unui atribut (DEFAULT): daca la
7/14/2019
inserarea unui tuplu nu se specifică valoarea unui atribut, atunci:
● atributul primeşte valoarea implicită (dacă a fost definită) sau valoarea NULL
(dacă nu a fost definită o valoare implicită, dar sunt admise valori NULL);
● dacă nu a fost definită o valoare implicită şi nici nu sunt admise valori NULL, se
generează o eroare. Exemplu:
CREATE TABLE STUDENTI (
Nume varchar (20) NOT NULL,
Prenume varchar (20) NOT NULL,
Tara varchar (20) DEFAULT (‘Romania’) NULL ) ;
 Constrângerea de verificare (CHECK) – pentru verificarea valorilor
atributelor printr-o conditie care trebuie sa ia valoarea TRUE.
 Se introduce ca o constrangere de tabel in instructiunea CREATE TABLE:
[CONSTRAINT nume_constrangere] CHECK (conditie); Exemplu:
Salariu numeric,
CONSTRAINT Verificare_Salariu CHECK (Salariu >= 1500 ));
MySql 5.0 nu face verificarea CHECK, chiar daca admite acest cuvânt cheie
Constrangeri de tuplu
 O relaţie = mulţime de tupluri Æ tuplurile unei relaţii trebuie să fie distincte
7/14/2019
(nu pot exista două sau mai multe tupluri identice)
 O supercheie (superkey ) este o submulţime SK de atribute ale relaţiei care

prezintă proprietatea de unicitate (orice combinaţie de valori ale atributelor
supercheii este unică pentru orice stare a relaţiei), adică:
ti[SK] ≠ tj[SK] dacă i ≠ j, unde ti si tj sunt 2 tupuri ale relatiei
 Rezulta că, dacă se cunoaşte valoarea (combinaţia de valori ale atributelor)
supercheii, atunci acel tuplu poate fi identificat în mod unic
 O cheie candidat ă (candidate key ) este o supercheie ireductibilă:
● Unicitate: nu există două tupluri diferite ale relaţiei care să conţină aceeaşi
combinaţie de valori ale atributelor cheii CK;
● Ireductibilitate: nu există nici o submulţime proprie, nevidă a cheii CK care să
aibă proprietatea de unicitate.
 O cheie candidat ă este o supercheie minimală (ireductibilă) si poate fi

simplă (un singur atribut), sau compusă (mai multe atribute)
 Proprietatea de unicitate a cheii (candidate) este o constrângere de
integritate a tuplurilor
Chei primare si secundare (1)

 Atunci când există mai multe chei candidate, una dintre ele se alege ca şi
cheie primar ă, celelalte chei candidate fiind numite chei secundare (sau unice)
 O cheie primar ă ( primary key ) este o cheie candidată căreia proiectantul îi
confer ă un rol special de identificare a tuplurilor si are următoarele restricţii:
● Nici o valoare a atributelor cheii primare nu poate fi modificată prin operaţii de
actualizare
● Nu se admit valori de NULL pentru nici unul dintre atributele cheii primare
 O cheie secundar ă (alternativă, unică) (secondary , alternate, unique key )
este o cheie candidată care nu a fost desemnată ca şi cheie primar ă; cheile
secundare admit valori NULL pentru unele din atributele lor
 Alegerea cheii primare dintre mai multe chei candidate este arbitrar ă, dar, din
motive de eficienta, se alege cheia cu cel mai mic număr de atribute
 Cheile primare pot fi naturale sau artificiale:
● O cheie primar ă alcatuita din atributele existente ale tipului de entitate se numeşte
cheie naturală; in general, cheile naturale sunt chei compuse
● O cheie primar ă artificială este un atribut care se adaugă în schema relaţiei special
pentru identificarea unică a tuplurilor

 De exemplu, atributul compus {Nume, Prenume, DataNasterii, Adresa} din
relaţia ANGAJATI (IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu)

poate fi considerat cheie candidata si poate fi desemnat ca si cheie primara
 O solutie mai eficienta este adaugarea unei chei primare artificiale, IdAngajat:
ANGAJATI (IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu)
 Cheia primar ă se introduce prin instructiunea CREATE TABLE
● In general, cheia primar ă se defineste ca o constrângere de tabel sub forma:
[CONSTRAINT nume_constr] PRIMARY KEY (lista_atribute)
Dac cheia primar este simpl (format dintr-un singur atribut), ea se poate
● specifica
ă ă
si ca o constrângere ă ă
de coloana
 Cheile secundare se definesc folosind specificatorul UNIQUE în locul
specificatorului PRIMARY KEY.

Exemplu:
CREATE TABLE SECTII (
IdSectie int PRIMARY KEY,
Buget numeric);

 Exemplu:
7/14/2019 CREATE TABLE ANGAJATI ( Proiectare Baze de date.pdf
IdAngajat int PRIMARY KEY AUTO_INCREMENT,

DataNasterii Date,
Adresa varchar(50),
Salariu numeric,
[CONSTRAINT UK] UNIQUE [KEY] (Nume,Prenume,DataNasterii,Adresa));
 Modul de asigurare a unicităţii valorii cheii primare artificiale depinde de
sistemul SGBD folosit. De exemplu:
• In Microsoft SQL Server se pot ob ine valori unice ale cheii primare folosind
parametrul IDENTITY, care asigur ţă incrementarea valorii atributului cheii la
introducerea fiecărei 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
•
In MySQL, unice
numerelor se foloseste parametrul
pentru cheile AUTO_INCREMENT pentru generarea
primare.
 SGBD-urile interzic introducerea liniilor (tuplurilor) care vau valori identice
ale cheilor primare sau secundare (daca nu exista valori NULL) (Exemple)
Constrangeri inter -relatii
 Asocierile (relationships) 1:N între multimile de entităţi (din modelul Entitate-
Asociere) se realizează în modelul relaţional prin chei str ăine
 Exemplu: Pentru a realiza asocierea 1:N dintre relaţiile SECTII si ANGAJATI,

se adaugă în relaţia ANGAJATI atributul IdSectie, care reprezintă
identificatorul (numărul) secţiei în care lucrează angajatul respectiv:
ANGAJATI (IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu, IdSectie)
SECTII
IdSectie Nume Buget
1 N
SECTII ANGAJATI 1 Productie 400000
2 Proiectare 300000
Diagrama E-A 3 Cercetare 200000
4 Documentare 100000
ANGAJATI
IdAngajat Nume Prenume DataNasterii Adresa Salariul IdSectie
1 Ionescu Ion 1960.01.05 Bucuresti 4000 1
2 Popescu Petre 1965.02.97 Bucuresti 3200 1
3 Vasilescu Ana 1961.03.06 Bucuresti 2000 2
4 Ionescu Ion 1970.03.98 Bucuresti 2000 3
Cheia straina
 Fie doua relatii R1 si R2, intre care exista o asociere cu raportul 1:N
O cheie str ăină (foreign key ) este o submulţime FK de atribute ale relaţiei R2
care refer ă rela

● atributele ţiastr
cheii R1 (relatia
ăine referita)
FK sunt i satisface
definiteşpe următoarele
domenii compatibile cu condi ţii:
cele ale
atributelor unei cheii candidate CK a relaţiei R1
● valorile atributelor FK într-un tuplu din relaţia R2, fie sunt identice cu valorile
atributelor CK a unui tuplu oarecare din starea curentă a relaţiei R1, fie sunt NULL

 Cheia str ăină reprezint
Două domenii ă o constrângere
sunt compatibile dacă ele referen ţială intre cele
sunt comparabile din 2punct
relatiide
vedere semantic (are sens sa fie comparate)
 În limbajul SQL verificarea domeniilor se rezumă la verificarea tipurilor de
date, iar compatibiltatea semantică trebuie să fie asigurată de proiectant
 Cheia str ăină se specifică la crearea tabelului printr-o constrângere de tabel:
[CONSTRAINT nume_constr] FOREIGN KEY (cheie_straina)
REFERENCES relatia_referita (cheie_candidata)
 Exemplu:
IdAngajat int PRIMARY KEY,
IdSecţie int,
UNIQUE (Nume,Prenume),
CONSTRAINT FK FOREIGN KEY (IdSectie) REFERENCES SECTII(IdSectie));
Mentinerea integritatii referentiale a relatiilor (1)

 Integritatea referenţ ial ă (referential integrity ) este proprietatea bazei de
date prin care orice cheie str ăina:

● fie are o valoare care se regăseşte printre valorile cheii candidate referite
● fie are valoarea NULL
 Pentru mentinerea integritatii referentiale trebuie sa fie inpuse restrictii
operaţiilor de modificare a stării relaţiilor (INSERT, DELETE, UPDATE)
 Restricţiile care se impun operaţiilor de modificare a relaţiilor depind de rolul
relaţiei (relaţie care refer ă, relaţie referită, sau poate avea ambele roluri)
 Operaţia INSERT:
● într-o relaţie referită se poate face f ăr ă restricţii
● într-o relaţie care refer ă (care conţine o cheie str ăină): trebuie să se verifice că în
relaţia referită există un tuplu care are valorile atributelor cheii referite egale cu
valorile atributelor cheii str ăine a tuplului de introdus; dacă această condiţie nu
este satisf ăcută, operaţia de introducere este refuzată.
 Operatia DELETE:
● Intr-o relatie care refera se poate face fara restrictii
● Intr-o relatie referita se poate face ştergere restric ţ ionat ă sau ştergere în
cascad ă.
Mentinerea integritatii referentiale a relatiilor (2)

 Ş tergerea restric ţ ionat ă interzice ştergerea unui tuplu din relaţia referită
7/14/2019
dacă acesta este referit de un tuplu din relaţia care o refer ă
 Ş tergerea în cascad ă permite ştergerea unui tuplu din relaţia referită; dacă
tuplul şters era referit de unul sau mai multe tupluri, atunci se şterg şi
acestea din relaţia care o refer ă; dacă tuplurile şterse din relaţia care refer ă
sunt, la rândul lor referite de alte tupluri, atunci trebuie să fie şterse şi

acestea, ş.a.m.d.; se execută deci o ştegere în cascadă
Operaţia UPDATE poate fi privită ca o ştergere urmată de o introducere,
deci restricţiile de actualizare reprezintă combinaţia restricţiilor de
introducere şi de ştergere
 In limbajul SQL se specifica opţiunile ON DELETE si ON UPDATE
constrîngerii de cheie str ăină; valorile posibile ale acestor opţiuni sunt:
● RESTRICT - pentru ştergerea restricţionată (este valoare implicita)
● CASCADE - pentru ştergerea în cascadă;
 Exemplu:
IdAngajat int PRIMARY KEY,
Nume varchar (20) NOT NULL,
........................
CONSTRAINT FK FOREIGN KEY (IdSectie) REFERENCES SECTII(IdSectie) ,
ON DELETE CASCADE );
Indexarea relatiilor
 Timpul de execuţie a operatiilor asupra datelor din relatii depinde de modul
de reprezentare
inregistrari a mul
in fisiere peţimii
discde elemente (tupluri) ale relaţiilor, memorate ca
 Operaţiile de căutare, inserare şi ştergere a elementelor într-o mulţime se
execută mai rapid dacă elementele mulţimii sunt reprezentate printr-o
colecţie ordonată, ca de exemplu arbori sau tabele de dispersie (hash table)
 Deşi o relaţie nu presupune ordonarea tuplurilor sale, pentru accelerarea
operaţiilor de căutare, inserare şi ştergere, se folosesc colecţii ordonate
 Un index al unei relaţii este o structur ă auxiliar ă memorată în baza de date
care permite accesul rapid la tuplurile relaţiei prin ordonarea acestora
 Structuri folosite in indexare: arbori binari ordonati, tabele de dispersie
(hash-tables) etc.
 Exista două categorii de indexuri:
● un index primar al relaţiei, care determină localizarea tuplurilor în fişierele bazei
de date
● zero, unul sau mai multe indexuri secundare, care nu modifică localizarea
tuplurilor, dar sunt folosiţi pentru regăsirea rapida a tuplurilor după un criteriu dat
Indexul primar si indexuri secundare

 Indexul primar ( primary index ) se defineşte pe unul sau mai multe atribute ale 69/194
relaţiei şi reprezintă cheia (eticheta) după care se ordonează tuplurile relaţiei
 In general, sistemele SGBD definesc în mod implicit indexul primar pe cheia
primar
ă a rela ţiei
 Operaţiile de interogare care se fac dupa valoarea atributului index primar se
execută eficient, fiind o cautare intr-o multime ordonata dupa acea valoare
● Exemplu: “Care este numele angajatului cu identificatorul 2?”
 Operatiile de interogare care se fac dupa valoarea altor atribute (decat indexul
primar) se executa mult mai ineficient, fiind o cautare intr-o multime
neordonata dupa acea valoare
● Exemplu: “Care este adresa angajatului cu numele ‘Ionescu’ ?”
 Pentru rezolvarea mai eficientă a unor astfel de interogări se pot defini indexuri
secundare pe acele atribute care intervin frecvent în interogări
 Un index secundar pe un atribut A al unei relaţii (secondary index ) este o
structur ă care conţine o mulţime de perechi (v,L) ordonate după v; fiecare
pereche corespunde unui tuplu al relaţiei, v este valoarea atributului A, iar L
este adresa tuplului respectiv în structura indexului primar al relaţiei
 Un index secundar nu modifică adresa de memorare a unui tuplu (care este
conţinută în structura indexului primar), dar conţine informaţii care permit
identificarea
Baze de date, 2008 rapidă a unui tuplu
Prof.dup ă valoarea
Felicia Ionescu atributului acestui index 41
Definirea indexurilor secundare

 Indexurile secundare au avantaje si dezavantaje:
● Avantaje: Accelereaza operatiile de interogare care se fac dupa valoarea indexului
● Dezavantaje: ocupa spatiu de memorie si consuma timp la actualizarea relatiilor

 În general, se recomandă utilizarea unui număr cât mai mic de indexuri
secundare, definite pe atributele care intervin cel mai frecvent în interogari
 Indexurile sunt folosite pentru îmbunătăţirea performanţelor bazelor de date şi
nu fac parte din modelul relaţional de bază.
 Majoritatea sistemelor SGBD conţin instrucţiuni pentru crearea indexurilor:
CREATE [optiuni] INDEX nume_index ON tabel (lista_atribute);
 Forma exactă şi opţiunile acestei instrucţiuni variază de la un sistem SGBD la
altul. Una din opţiunile care se pot introduce în instrucţiunea CREATE INDEX
este opţiunea UNIQUE, care specifică faptul că nu pot exista două tupluri cu
aceeaşi combinaţie de valori ale atributelor indexului, deci acele atribute
reprezintă o cheie unică a relaţiei.
 Unele sisteme SGBD adaugă câte un index secundar pentru fiecare cheie
unică, definită prin constrângerea UNIQUE din comanda CREATE TABLE:
ALTER TABLE angajati ADD UNIQUE INDEX Pr (Prenume);
Capitolul 3: Interogarea bazelor de date

 Limbaje de interogare
 Algebra relationala si calculul relational
 Operatiile pe multimi ale algebrei relationale
● Reuniunea
● Intersectia
● 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
Limbaje de interogare
 Interogarea (query ): operaţ ia prin care se obţ in informatiile dorite dintr-o
baz ă de date, selectate conform unui anumit criteriu (condi ţi e);
 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 mulţime de operaţii
care au ca operanzi relaţii, iar rezultatul este tot o relaţie
 Calculul relaţ ional (relational calculus) - bazat pe calculul predicatelor -
exprimă o interogare definind rezultatul dorit ca expresie de calcul relaţional
 Calculul relational al tuplurilor foloseste variabile de tuplu (variabile
definite pe mulţimea tuplurilor unei relaţii)
 Calculul relational al domeniilor foloseste variabile de domeniu (variabile
definite pe domenii de definiţie 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 combinaţie a acestora.
 De exemplu, limbajul SQL2 este în cea mai mare parte bazat pe algebra
relaţională, dar mai conţine şi construcţii derivate din calculul relaţional.
Algebra relationala
 Algebra relaţională (relational algebra) - interogările sunt expresii compuse
din operatii care au ca operanzi relatii si rezultatul este o relatie
7/14/2019
 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 acţionează asupra relaţiilor văzute ca mulţimi
(de tupluri), f ăr ă a lua în consideraţie compoziţia fiecărui tuplu; acestea sunt:
● Reuniunea
● Intersecţia
● Diferenţa
● Produsul cartezian
 Opera
formateiile
dinrela
ţ ţionale speciale iau în consideraţie compoziţia tuplurilor,
valori ale atributelor relaţiilor; acestea sunt:
● Restricţia
● Proiecţia
● Joncţiunea
● Diviziunea
 Proprietatea de închidere: operanzii (unul sau doi operanzi) sunt relatii,
rezultatul este o relaţie; această proprietate permite operaţii imbricate:
proiecţia unei joncţiuni etc.
Operatia de Reuniune
 Reuniunea (union) a două relaţii compatibile r(R) şi s(S):
q = r ∪ s = { t | t ∈ r or t ∈ s}
7/14/2019
Pentru ca r si s sa fie compatibile, trebuie ca: Proiectare Baze de date.pdf
● r si s sa aiba acelasi grad (acelasi numar de atribute)

● Atributele corespondente (in ordine pozitionala) sa fie compatibile
 Tuplurile care apar ţin ambelor relaţii se introduc în relaţia 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 B A B A B
α 1 α 2 α 1
α 2 β 3 α 2
β 1 s β 1
r β 3
Baze de date, 2008 Prof. Felicia Ionescu r ∪ s 4
Operatiile de Intersectie si Diferenta

 Intersectia (set-intersection) a două relaţii compatibile r(R) şi s(S):
q r ∩ s { t | t ∈ r and t ∈ s}
7/14/2019
Exemplu: Proiectare Baze de date.pdf
A B A B A B
α 1 α 2 α 2
α 2 β
β 1 s3 r ∩ s
r
 Diferenta (set-difference) a două relaţii compatibile r(R) şi s(S):
q = r - s = { t | t ∈ r and t ∉ s}
 Exemplu:
A B A B A B
α 1 α 2 α 1
α 2 β 3 β 1
β 1 s
r r-s
 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
Operatia de Produs Cartesian

 Produsul cartesian (Cartesian-Product ) a două relaţii r(R) şi s(S):
q = r x s = { tp | t ∈ r and p ∈ s}, Q = R ∪ S
7/14/2019  Se presupune ca 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 relaţiei rezultat se obtin prin concatenarea valorilor atributelor fiecărui
tuplu din prima relaţie cu valorile atributelor tuturor tuplurilor din a doua relaţie
 Relatia rezultata are numarul de tupluri (cardinalitatea) egal cu produsul
numarului de tupluri ale relatiilor operand

Exemplu: A B C D E A B C D E
α 1 α 10 a
α 1 α 10 a α 1 β 10 a
β 10 a α 1 β 20 b
β 2
r β
γ 20
10 b
b α
β 1
2 γ
α 10
10 b
a
β 2 β 10 a
s
β 2 β 20 b
β 2 γ 10 b
Baze de date, 2008 Prof. Felicia Ionescu rxs 6
Exprimarea operatiilor pe multimi in SQL (1)

 Reuniunea:
SELECT lista_coloane1 FROM tabel1 [WHERE condiţie1]
7/14/2019 UNION Proiectare Baze de date.pdf
SELECT lista_coloane2 FROM tabel2 [WHERE condiţie2];

Exemplu (MySQL, Intreprindere):
SELECT Nume, Prenume, Adresa FROM FURNIZORI
UNION
SELECT Nume, Prenume, Adresa FROM CLIENTI;
Afiseaza numele tuturor furnizorilor si al clientilor, precum si adresa acestora
 Intersectia:

INTERSECT
 Diferenta:
MINUS
Exprimarea operatiilor pe multimi in SQL (2)

 Produsul Cartesian:
7/14/2019
SELECT * from R, S; Proiectare Baze de date.pdf
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 operaţiile pe mulţimi;
in SQL Server 2000 si in MySQL 5.0 nu sunt implementate operaţiile
INTERSECT şi MINUS
Operatia de Selectie
 Selectia (sau restrictia – select, restriction) intr-o relatie r(R) - definita astfel:
7/14/2019 σ p(r) = {t | t ∈ r and p(t)} Proiectare Baze de date.pdf
unde p, predicatul selectiei , este o formula de calcul propozitional compusa din
termeni conectati prin operatorii and (∧), or (v)‚ not (¬)
 Fiecare termen este de forma:
<atribut> op <atribut> sau
<atribut> op <constanta>, unde
op este un operator de comparatie: =, ≠, >, ≥. <. ≤
Tuplul t este selectat (introdus in rezultat) daca p(t)=TRUE

InSELECT
limbajul* SQL:
FROM tabel WHERE p;
În termenii folosiţi în limbajul SQL, restric ţ ia 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;
Operatia de Proiectie
 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
7/14/2019  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:
A B C A C A C
α 10 1 α 1 α 1
r α 20 1 α 1 = β 1
β 30 1 β 1 β 2
β 40 2 β 2 ∏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;
Operatia de jonctiune naturala (1)

 Jonctiunea naturala (natural join) combina tuplurile din doua relatii
 Fie multimile de atribute: A = {A1,A2,...Am} , B= {B1,B2,...Bn}, C={C1,C2,…Ck}
7/14/2019 si doua relatii r(R) si s(S), unde: Proiectare Baze de date.pdf
● R ={A, B}, S = {B, C}

● deci atributele R ∩ S = B = {B1, B2,...Bn} sunt comune celor două relaţii
 ><
Jonc
● seiunea
ţ natural
calculeaz
ă este o relatie q = r
ă produsul s, care
cartesian al celor doua relatii:sep ob
= r ine
ţ
x s, în
P =felul urmăS.B,
{A, R.B, tor: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 in cele doua relatii;
daca sunt compatibile, ele se considera 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 straina – cheia primara (candidata) referita
Operatia de jonctiune naturala (2)

 Exemplul 1: r >< s = Π A,B,C,D,E σ (r.D = s.D ) (r x s)
7/14/2019
A B C D D Proiectare
E Baze de date.pdf A B C D E
α 1 α a a α α 1 α a α
β 2 γ a b β β 2 γ a α
γ 4 β b c γ γ 4 β b β
α 1 γ a d δ a α α 1 γ
δ 2 β b e ∈ b β δ 2 β
r s r >< s
 In SQL trebuie sa fie introduse explicit lista atributelor rezultatului si conditiile
de egalitate
SELECT ale atributelor
A,B,C,D,E FROM R, comune:
S WHERE R.D = S.D;
 Exemplul 2: ANGAJATI >< SECTII; cheia straina: ANGAJATI.IdSectie
SELECT IdAngajat, Nume, Prenume, DataNasterii, Adresa, Functia, Salariul,
ANGAJATI.IdSectie, Denumire, Buget FROM ANGAJATI, SECTII
WHERE ANGAJATI.IdSectie=SECTII.IdSectie;
 Exemplul 3: (MySQL - SAKILA) city >< country; cheia straina: city.country_id
SELECT city_id, city, city.country_id, city.last_update, country, country.last_update
from city, country where city.country_id=country.country_id order by city;
Operatia de diviziune
 Fie relatiile r(R) si s(S), unde:
● R = {A, B} unde A={A1,A2,..Am}, B={ B1,B2,..Bn}
7/14/2019
● S = {B} Proiectare Baze de date.pdf
 Relaţia q = r ÷ s are schema Q = R – S = {A} si:

r ÷ s = { t | t ∈ ∏ R-S (r) ∧ ∀ u ∈ s ( tu ∈ r ) }
 Înunde tu inseamna
limbajul concatenarea
SQL, diviziunea tupluriloră tprintr-o
se exprim si u instrucţiune SELECT,
introducând explicit toate conditiile impuse valorilor atributelor
 Exemplu:
A B B A
α 1 1 α
α 2 2 β
α 3 s r ÷ s
β 1
2
β
δ 1
δ 3
r
Concluzii: operatiile algebrei relationale

 Algebra relaţională este o colecţie de operaţii asupra relaţiilor
 Cele opt operaţii propuse de E.F.Codd nu constituie o mul ţime minimă de
operaţii ale algebrei relaţionale
7/14/2019
 Mulţimea minimă de operaţii ale algebrei relaţionale consta din cinci operaţii
primitive, pe baza cărora se poate construi orice expresie de algebra

relaţionala:
● Reuniunea
● Diferenţa
● Produsul Cartesian
● Restricţia (selectia)
● Proiecţia
 Celelalte operaţii se pot exprima prin intermediul acestora:
● Intersecţia se poate exprima prin expresia: R ∩ S = R – (R – S);
● Joncţiunea este o proiecţie a unei restricţii a produsului cartezian al relaţiilor;
● Diviziunea este o proiecţie a unei restricţii asupra relaţiei deîmpăr ţit
 Si celelalte
încât trei opera ţii sunt deosebit de utile în formularea interogărilor,
astfel algebra rela ţională a păstrat toate cele opt operaţii propuse de
E.F.Codd, la care s-a adăugat operaţia de redenumire a atributelor
Formularea interogarilor
 Interogarea este operatia prin care se obtin informaţiile dorite (care
indeplinesc o anumita conditie) dintr-o bază de date. O interogare:
● se formuleaza mai intai în limbaj natural,
7/14/2019 ● apoi se exprima într-un limbaj abstract de interogare (algebra relaţională sau
calculul relaţional),
● 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 relaţională o interogare se formulează printr-o expresie care
defineste următoarele elemente:
● Lista atributelor relaţiei rezultat, care se numesc atribute de proiecţie;
● Lista relaţiilor din care se extrag informaţiile
● Condiţiile pe care trebuie să le îndeplinească tuplurile relaţiei rezultat.
 Sunt posibile două situaţii:
● interogări care se rezolvă în cadrul unei singure relaţii
● interogări care se rezolvă folosind două sau mai multe relaţii ale bazei de date
Interogari intr -o singura relatie

 Interogare in relatia r(R):
● Expresia de algebra relationala: q = ∏ lista_atribute σ p(r)
● Instructiunea SQL: SELECT lista_atribute FROM R WHERE p = TRUE;
 Exemplul 1: Fie relaţia ANGAJATI şi interogarea: „Care sunt numele şi

prenumele angajaţilor care au un salariu mai mare sau egal cu 2000?”.
● Expresia de algebr ă relaţională: q = ∏ Nume, Prenume σ Salariul >= 2000 (ANGAJATI)
● Instrucţiunea SQL:
● SELECT Nume, Prenume, Salariul FROM ANGAJATI WHERE Salariul >= 2000;
 Exemplul 2: (MySQL - WORLD): “Care sunt numele si populatia oraselor din
tara cu codul ‘ROM’ ?”
● Expresia de algebr ă relaţională: q = ∏ Name, Population σ country_id=‘ROM’ (city)
● Instructiunea SQL:
● SELECT Name, CountryCode, Population FROM city
WHERE CountryCode=‘ROM';

Exemplul 3:siFie
prenumele adresa
relaţia
angaja
ANGAJATI
ţilor care
şi interogarea:
lucreaza in sectia
„Carenumarul
sunt numele,
1?”.
● Expresia de algebr ă relaţională: q = ∏ Nume, Prenume, Salariul σ IdSectie = 1 (ANGAJATI)
● Instructiunea SQL:
● SELECT Nume, Prenume, Adresa FROM ANGAJATI WHERE IdSectie=1;
Interogari in doua sau mai multe relatii

 Daca atributele de proiecţie şi atributele din condiţia de interogare nu apar ţin
unei singure relaţii, pentru rezolvarea interogării trebuie să fie folosite toate
7/14/2019
acele relaţiile care, împreună, conţin aceste atribute
 Conceptual, o astfel de interogare se rezolvă astfel:

● se construieste mai întâi o relaţie care să conţină toate atributele implicate prin
combinarea relaţiilor necesare, folosind operaţii de produs cartezian sau jonc ţiuni;
● in relatia obtinuta se aplica o selectie (restrictie) (cu condiţia de interogare p);
● apoi se face proiecţia (pe atributele de proiecţie).
 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 str ăină - cheie candidata)
atunci se vor face operaţii de joncţiune:
q = Πlista_atribute σp AND conditii-join(r >< s >< t...)
 In limbajul SQL, o interogare se exprima prin forma generala a instructiunii
SELECT, in care clauza WHERE combina atat conditiile impuse valorilor
atributelor (predicatul p) cat si conditiile de jonctiune naturala (egalitatea
valorilor atributelor comune)
Exemplu: interogare in doua relatii

 Fie interogarea: Care sunt numele, prenumele, func ţia, salariul şi denumirea
secţiei în care lucrează angajaţii?
 Expresia de algebr ă relaţională este:
7/14/2019 q = ∏ Nume, Prenume, Functia, Salariul, Denumire (ANGAJATI
Proiectare Baze de date.pdf >< SECTII)
 Instructiunea SQL corespunzatoare acestei interogări:

SELECT Nume, Prenume, Functia, Salariul 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 Salariul IdSectie
SECTII
Buget Denumire IdSectie
 Fie interogarea: Care sunt numele, prenumele, func ţia şi salariul angajaţilor
care lucrează în secţia cu denumirea ‘Productie’?
q = ∏ Nume, Prenume, Functia, Salariul σDenumire= ‘Productie’ (ANGAJATI >< SECTII)
SELECT Nume, Prenume, Functia, Salariul FROM ANGAJATI, SECTII
WHERE SECTII.IdSectie = ANGAJATI.IdSectie AND Denumire = ‘Productie’;
Exemplu: interogare in trei relatii (1)

 Fie urmatoarele relatii asociate din baza de date SAKILA (MySQL):
● film (film_id, title, description, release_year, ....)
7/14/2019 ● category (category_id, name, Proiectare
last_update)
Baze de date.pdf
● film_category (film_id, category_id, last_update)
film 1 N film_category N 1 category
 Interogarea: “Care sunt titlul (film.title) si categoria(category.name) filmelor

din baza de date sakila ?”
q = ∏ title,name (film >< film_category >< category)
 Instructiunea SQL:
SELECT title, name
FROM film, film_category, category
WHERE film.film_id=film_category.film_id AND
category.category_id= film_category.category_id;
Exemplu: interogare in trei relatii (2)

 Detalierea interogarii: Care sunt titlurile filmelor, numele categoriei (name) şi
anul lansării (release_year) pentru cele din categoria actiune (Action)?
 Care sunt filmele (film_id, title, description etc) şi category_id acestora?
7/14/2019 q1(Q1) = film >< film_category Proiectare Baze de date.pdf
• unde Q1 ={film_id, title, description, release_year, ...., category_id, last_update}

● Atributul comun pe care s-a efectuat jonctiunea este scris ingrosat (bold)
 Care sunt filmele si numele categoriei (name) acestora?”

q2(Q2) = q1 >< category = film >< film_category >< category
unde Q2 = {film_id, title, description, release_year, ...., category_id,
film_category.last_update, name, category.last_update}

Care sunt‘Action’?
categoria titlurile filmelor, numele categoriei şi anul lansării filmelor din
q(Q) = σ name = ‘Action’ (q2) = σ name = ‘Action’ (film >< film_category >< category )
 Instructiunea SQL:
SELECT
WHEREtitle, name, release_year
film.film_id FROM film, film_category,
= film_category.film_id AND category
film_category.category_id = category.category_id AND
name = ‘Action’;

Capitolul 4: Dezvoltarea sistemelor de baze de date

Fazele de dezvoltare a bazelor de date
 Colectarea si analiza cerintelor
7/14/2019
 Proiectarea bazelor de date Proiectare Baze de date.pdf
● 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
Dezvoltarea sistemelor de baze de date (1)

 Sistemul informatic (information system) al unei organizatii include toate
resursele acelei organizaţii care sunt implicate în colectarea, administrarea,
utilizarea şi diseminarea informaţiilor
7/14/2019  Sistemele informatice: Proiectare Baze de date.pdf
● Pana in anii 1970 erau sisteme de fişiere (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 protecţia 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 aplicaţiilor 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 definiţiile obiectelor bazei de date
(tabele, vederi, etc.) şi se implementează aplicaţiile software
● Testarea şi validarea: noul sistem de baze de date este testat şi validat cât 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
Dezvoltarea sistemelor de baze de date (2)

 Fazele importante de dezvoltare a sistemelor de baze de date sunt:
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf Cerinţe de 95/194
Faza 1: Colectarea şi Cerinţe de date prelucrare
analiza cerinţelor
Faza 2: Proiectare Proiectarea schemei conceptuale şi a Proiectarea tranzacţiilor

conceptuală schemelor externe (independente de SGBD) (independente de SGBD)
Faza 3: Alegerea
unui SGBD
Faza 4: Proiectare Proiectarea schemei conceptuale şi a Proiectarea tranzacţiilor
logică schemelor externe (dependente de SGBD) (dependente de SGBD)
Faza 5: Proiectare Proiectarea schemei interne

fizică (dependentă de SGBD)
Faza 6: Implementare Instrucţiuni de descriere a datelor Implementarea tranzacţiilor

(LDD) (dependente de SGBD) (dependente de SGBD)
Faza 7: Testare si validare Testarea datelor Testarea tranzactiilor
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 aşteaptă utilizatorii potenţiali să obţină de la baza de date
7/14/2019
respectivă Proiectare Baze de date.pdf
● ce informaţii primare sunt disponibile pentru acestea
● ce aplica
aplica ţii se
ţii de urmvor executa
ărire (aplicaţii de
a consumurilor, gestiune
aplica ţii de a aplicaţii contabile,
stocurilor,etc.).
salarizare,
 Toate acestea sunt informaţii slab structurate, în general în limbaj natural,
pe baza cărora 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
Proiectarea conceptuala a bazelor de date

 Proiectarea bazelor de date:
● Proiectarea schemei conceptuale a bazei de date
●
Proiectarea schemelor externe (vederi ale urilizatorilor)
7/14/2019
● Proiectarea tranzactiilor Proiectare Baze de date.pdf
 Dependenta proiectarii de SGBD-ul folosit:

● Proiectarea schemei conceptuale si a schemelor externe independente de SGBD
● (scheme conceptuale
Proiectarea de nivel inalt)
schemei conceptuale si si a tranzactiilor
a schemelor independente
externe de SGBD
dependente de SGBD
(scheme logice) si a tranzactiilor dependente de SGBD
 Este recomandabil să se proiecteze mai întâi schema conceptuală de nivel
înalt independentă de SGBD, care este o descriere stabilă a bazei de date
 Definirea schemei conceptuale:
● proiectare prin integrarea cerinţelor
● proiectare prin integrarea schemelor externe
 Moduri de proiectare conceptuala:
● Proiectare ascendenta (bottom-up): se porneste de la schema conceptuala
universala, care se rafineaza
● Proiectare descendenta (up-bottom) : se porneste de la diagrama E-A, definita pe
baza tipurilor de entitati si a asocierilor dintre acestea
Exemplu de proiectare a unei baze de date

 Baza de date INTREPRINDERE cu multimile de entitati puternice:
● SECTII(Nume,Buget)
● ANGAJATI(Nume, Prenume, DataNasterii, Adresa, Functie, Salariu)
7/14/2019 ● PROIECTE(Denumire,Termen,Proiectare
Buget) Baze de date.pdf
● PRODUSE(Denumire, Descriere)
● COMPONENTE(Denumire, Descriere)
● FURNIZORI(Nume,Prenume,Adresa) ; CLIENTI(Nume, Prenume, Adresa)
 Diagrama E-A:
SECTII PROIECTE COMPONENTE
M
1 ACTIVITATI M COMPOZITII
N
N N M
ACHIZITII
PRODUSE
ANGAJATI P
N M
1 VANZARI
d
P
N N
DEPENDENTI INGINERI SECRETARE FURNIZORI CLIENTI
Alegerea unui SGBD

 Factori pentru alegerea unui SGBD: tehnici, economici şi administrativi
 Factorii tehnici:
● Modelul de date (ierarhic, reţea, relaţional, obiect-orientat, obiect-relaţional)
7/14/2019
● Capacitatea de stocare a datelor Proiectare Baze de date.pdf
● Posibilităţile de control al concurenţei şi de refacere a datelor

● Configuraţia hardware-software necesar ă
● Cerinţe de dezvoltare a programelor de aplicaţii (limbaje, compilatoare etc.)
 Factorii economici şi administrativi:
● Costul de achiziţie a software-ului, care include costul de bază, la care se adaugă
diferite opţiuni (opţiuni de salvare-refacere, documentaţie, limbaje şi interfeţe de
programare, drivere, etc.)
● Costul de întreţinere, pentru a obţine serviciul furnizorului de menţinere la zi a
versiunii SGBD.
● Costul de pregătire a personalului se refer ă la cursurile care se organizează pentru
persoanele care se ocupă cu întreţinerea şi operarea sistemului
● Cunoştinţele de programare a personalului într-un anumit SGBD
 Beneficiile achiziţionării unui anumit SGBD nu sunt uşor de apreciat sau de
măsurat, dar analiza raportului cost-performanţe poate da o imagine a
rezultatelor obţinute
Proiectarea logica a bazelor de date

 Se porneste de la schema conceptuală şi schemele externe de nivel înalt
independente de SGBD (diagrama E-A), si se realizează schema logica
(diagrama logica) si schemele (vederile) externe pentru sistemul SGBD ales
7/14/2019
 Proiectarea logică poate fi realizată în două subfaze:
● Transpunerea schemei logice în modelul de date al sistemului SGBD ales, dar

independent de sistemul de gestiune propriu-zis
● Rafinarea schemei logice şi a schemelor externe obţinute anterior, astfel încât să
se utilizeze cât mai multe din facilităţile oferite de sistemul SGBD ales (modul de
generare a cheilor primare, definirea constrângerilor, etc.)
 Transpunerea modelului Entitate-Asociere (diagrama E-A) în model relaţional:
● Proiectarea relaţiilor corespunzătoare mulţimilor de entităţi din diagrama E-A
● Proiectarea asocierilor; asocierile se pot reprezenta prin chei str ăine sau prin relaţii
de asociere; acestea sunt relaţii suplimentare care se adaugă în schema
conceptuală a bazei de date relaţionale pentru a reprezenta asocierile M:N
 In mod frecvent, etapele de proiectare conceptuala si proiectare logica se
efectueaza impreuna, proiecatand schema (diagrama) logica a bazei de date
cu ajutorul toolset-urilor de dezvoltare oferite de SGBD-ul utilizat
Diagrama logica a bazei de date

INTREPRINDERE (1)
 Dezvoltata in Microsoft Access
Diagrama logica a bazei de date

INTREPRINDERE (2)
 Dezvoltata in MySQL Workbench
Proiectarea relatiilor
 Mulţimile de entităţi puternice (normale) din diagrama E-A devin relaţii:
● Numele fiecărei relaţii trebuie să fie unic în baza de date
● Atributele relatiei corespund atributelor entităţilor din multimea de entitati data
7/14/2019
● Cheia primar ă se defineşte: Proiectare Baze de date.pdf
● fie ca o cheie primara naturală (combinaţie de atribute care definesc în mod unic un tuplu)
● fie ca o cheie primar ă artificială
● De exemplu, în rela ţiile ANGAJATI, SECTII, PROIECTE, COMPONENTE, PRODUSE,
FURNIZORI, CLIENTI s-a adăugat câte o cheie primar ă artificială (IdAngajat, IdSectie etc.)
 Mulţimile de entităţi slabe din diagrama E-A devin relaţii aflate în asociere N:1
cu relaţia corespunzătoare mulţimii de entităţi de care acestea depind
● Pentru realizarea acestei asocieri, în relaţia dependentă se adaugă o cheie str ăină
care refer ă cheia primar ă a relaţiei puternice referite; de exemplu: cheia straina
dAngajat in introdusa in relatia DEPENDENTI . De ex:
DEPENDENTI( IdAngajat , Nume, Prenume, DataNasterii, GradRudenie)
● Cheia primar ă a relaţiei dependente poate fi:

● o combinaţie formată din atributul cheie str ăină ş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)
Proiectarea asocierilor (1)

 Asocierea binar ă 1: N dintre dou ă mul ţ imi de entit ăţ i puternice se
realizeaza prin intermediul unei chei str ăine în a doua relaţie (cea cu
multiplicitatea N a asocierii) care refer ă cheia primar ă din prima relaţie
● De exemplu, asocierea 1:N între relaţiile SECTII – ANGAJATI se realizează prin
cheia str ăină IdSec ţ ie din relatia ANGAJATI
 Asocierea binar ă 1: N intre relaţia corespunzătoare unei mulţimi de entităţi

puternice si relatia corespunzătoare unei mulţimi de entităţi slabe se

realizeaza la fel, printr-o cheie straina in relatia multimii de entitati slabe
Asocierea binar ă M:N dintre două mulţimi de entităţi se realizeaza cu o
noua relaţie, numită relaţ ie de asociere
 Aceasta are rapoartele de multiplicitate M :1, respectiv N :1 cu fiecare din
cele două relaţii date, prin intermediul a două chei str ăine
 Cheia primar ă a unei relaţii de asociere poate fi:
● o cheie primara artificială
● sau poate fi compusă din cheile str ăine, împreună cu alte atribute ale relaţiei

Exemplu: asocierea
realizeaza cu o relaţie
M:Nde dintre
asociere,
relaţnumit
iile COMPONENTE-PRODUSE
ă COMPOZITII se
● Relatia COMPOZITII contine cheile str ăine IdComponenta şi IdProdus
● Cheia primar ă a relaţiei COMPOZITII poate fi compusă din cheile str ăine
IdComponenta şi IdProdus sau poate fi o cheie artificiala (IdCompozitii )

 Asocierea binar ă 1:1 între dou ă mul ţ imi de entit ăţ i puternice se poate
transpune în modelul relaţional în două moduri:
● fie prin intermediul unei chei str ăine (caz particular al asocierii 1:N),
● fie printr-o relaţie de asociere (caz particular al unei asocierii M:N).
 Exemplu: intre relaţiile 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ă relaţii folosind o relatie de asociere
De exemplu: CASATORII(IdSot , IdSotie, DataCasatoriei)
 Asocierea binar ă 1:1 dintre o mulţime de entităţi de subtip şi mulţimea de
entităţi supertip este tot o asociere1:1 între relaţiile corespunzătoare
 Se realizeaza prin definirea în relaţia corespunzătoare subtipului de entitati a
unei chei str ăine, care este în acelaşi timp şi cheie primar ă
De exemplu: INGINERI(IdAngajat , Specialiatea)
 Exemple de date in tabele asociate

 Asocierea multipl ă M:N:P:…. se realizează la fel ca asocierea binar ă, prin
intermediul unei noi relaţii care se află în asociere M:1, N:1, P:1, etc, cu fiecare
din relaţiile date.
 Pentru aceasta, in relatia de asociere se introduc chei straine care refera
7/14/2019 relatiile care se asociaza, fiecare cheie str ăină referind cheia primar ă dintr-una
din relaţiile asociate.


Cheia primar
● o cheie
ă a unei
primara relaăţii de asociere multiplă poate fi:
artificial
● sau poate fi compusă din toate cheile str ăine, eventual împreună cu alte atribute
● De exemplu: asocierea între relaţiile COMPONENTE, FURNIZORI, ANGAJATI se
realizeaza prin relatia ACHIZITII (IdComponenta, IdFurnizor , IdAngajat , Data,
NrComponente, PretUnitar)
 In concluzie, în modelul relaţional toate asocierile se realizează prin chei str ăine
 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
Proiectarea relatiilor normalizate in prima

forma normala
 O relaţie este normalizată în prima formă normală (FN1) dacă fiecare
atribut ia numai valori atomice şi scalare din domeniul său de definiţie.
 O situaţie frecvent întâlnită este aceea în care un atribut poate lua mai
7/14/2019
multe valori pentru fiecare entitate Proiectare Baze de date.pdf
● De exemplu, în mulţimea de entităţi PERSOANE (Nume, Prenume, Adresa,
NrTelefon)
acas atributul NrTelefon
ă, al telefonului de la birou,poate lua mai multe
al telefonului etc) (numărul telefonului de
mobil,valori
 Relaţia în care un atribut poate avea valori multiple (un vector de valori)
este o relaţie nenormalizată, care nu este admisă de SGBD relaţionale
 Transformarea unei relaţii nenormalizate în relaţie normalizată în prima
forma normală (FN1):
● se înlocuieşte atributul care ar putea avea valori multiple cu câte un atribut
pentru fiecare din posibilităţile existente: Exemplu: PERSOANE (IdPersoana,
Nume, Prenume, Adresa,TelefonAcasa, TelefonBirou, TelefonMobil)
● se înlocuieşte atributul care ar putea avea valori multiple cu o nouă relaţie care
refer ă relaţia iniţială printr-o cheie str ăină. Exemplu: PERSOANE(IdPersoana,
Nume, Prenume, Adresa), TELEFOANE(NrTelefon, IdPersoana, Descriere)
 Exemple de date in tabele cu diferite tipuri de asocieri
Proiectarea fizica a bazelor de date

 Fiecare SGBD ofer ă o varietate de opţiuni de organizare a fişierelor şi a
modului de acces la datele stocate:
● indexuri
7/14/2019
● tipuri de fisiere Proiectare Baze de date.pdf
● gruparea înregistr ărilor corelate în aceleaşi blocuri pe disc (clustering)


Proiectarea fizică a bazei
structuri de memorare deacces
şi de date este
la fişprocesul de alegere
ierele bazei de date,apentru
acestor
a ob ţine
performanţe cât mai bune pentru SGBD-ul ales, pentru cât mai multe din
aplicaţiile proiectate

Parametrii generali de alegere a opţiunilor proiectului fizic al bazei de date:
● Timpul de r ăspuns: intervalul de timp dintre lansarea în execuţie a unei tranzacţii
şi primirea r ăspunsului la acea tranzacţii
● Utilizarea spaţiului de memorare: dimensiunea spaţiului pe disc utilizat de
fi ierele bazei de date i de structurile de acces la date
ş ş
● Capacitatea tranzacţională (transaction throughput): numărul mediu de tranzacţii
care pot fi prelucrate pe minut de către sistemul de baze de date
Implementarea bazelor de date

 În faza de implementare a bazelor de date relaţionale:
● Se creează obiectele principale ale bazei de date (tabele, vederi, indexuri), pe
baza
(LDD)proiectului logic şi aSGBD
proiectului
oferit de sistemul ales, fizic, folosind limbajul
sau toolset-uri grafice de
(dedescriere
ex. table aeditor
datelor
)
109/194
7/14/2019
sau prin executia scriptului generat de un toolset de proiectare
● Se implementează procedurile care asigur ă verificarea şi for ţarea tuturor

constrângerilor explicite (aser ţiuni, dependenţe de date care nu sunt determinate
de chei ale relaţiilor), a căror previziune şi documentare a fost realizată în faza
de proiectare logică a bazei de date
● Se populeaza baza de date cu informatii ob ţinute prin conversia unor date
existente sub formă de fişiere sau introduse direct în tabele
 Tot în această fază programatorii de aplicaţii implementează, pe baza
specificaţiilor conceptuale ale tranzacţiilor, programele de aplicaţii, în diferite
tehnologii de programare disponibile (limbaje procedurale de extensie a
limbajului SQL, limbajul SQL integrat, interfeţe şi biblioteci de programare)
 După crearea şi popularea bazei de date şi implementarea programelor de
aplicaţii se poate trece la etapa de testare si operare a sistemului de baze
de date, în paralel cu monitorizarea şi întreţinerea acestuia
Dezvoltarea aplicatiilor de baze de date

 Aplicaţiile de baze asigura:
● interfaţa (grafică) cu utilizatorii
● implementarea algoritmilor de calcul necesari
● interfaţa cu sistemele de gestiune a bazelor de date
7/14/2019
Aplicatie de baza
SGBD
de date Instr. SQL
•Limbajul SQL
Utilizatori •Limbajul SQL integrat
•
(Embeded
•Interfete de SQL) Extensii
ale procedurale
limbajului SQL
programare a Rezultate
aplicatiilor (API)
 Limbajul SQL, folosit in SGBD-uri este un limbaj neprocedural, adica nu

prevede instrucţiuni de control al ordinii de execuţie a operaţiilor
 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)
Limbaje procedurale de extensie a SQL

 Extensiile procedurale ale limbajului SQL:
● combină instrucţiuni SQL cu instrucţiuni pentru controlul ordinii de execuţie
(bucle while, instrucţiuni condiţionale if etc.)
● ofera suport de crearea cursoarelor, a procedurilor stocate, a funcţiilor definite de
utilizator şi a declanşatorilor (triggere)

utilizator şi a declanşatorilor (triggere)
7/14/2019
 Un cursor (cursor ) este o structur Proiectare
ă care permite memorarea (intr-un buffer
Baze de date.pdf
în memorie) a unei mulţimi de linii returnate de o instrucţiune de interogare,

urmata de extragerea si prelucrarea (eventual repetata) in programele de
aplicatii a fiecarei linii (sau a unui grup de linii)
 Cursoarele se pot crea folosind:
● Limbajul SQL sau extensiile procedurale ale acestuia
● Limbajul SQL integrat (Embedded SQL)
● Interfeţele si bibliotecile de programare a aplicaţiilor (ODBC, JDBC)
 Instrucţiunile 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;
Cursoare
 Cursoarele pot fi memorate:
● la server, iar clientul primeşte câte o linie (sau un grup de linii) de la server la
fiecare instrucţiune de extragere
● la client şi liniile sunt folosite direct în programul respectiv
 Cursoarele create prin intermediul limbajului SQL (sau a unei extensii a

acestuia) sunt cursoare la server i pot fi definite in func ii i proceduri
stocate in server ş ţ ş
 Prin intermediul interfeţelor de programare se pot defini atât cursoare la
server cât şi cursoare la client
 In general, cursoarele la server suntnecesit
mai avantajoase decât
client, deoarece cursoarele la client ă ca întreaga mulcursoarele
ţime de liniila
rezultat să fie transferată dintr-o dată de la server la client, chiar dacă
ulterior, din diferite cauze, clientul nu va folosi decât o parte din liniile pe
care le-a primit prin reţea şi le-a memorat
Proceduri stocate
 O procedur ă stocată (stored procedure) este o procedur ă care
implementează o parte din algoritmii de calcul ai aplicaţiilor ş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 c ătre un client (aplicaţie) produce
execuţia de catre SGBD a tuturor instrucţiunilor procedurii şi returnarea
rezultatrlor in parametrii OUT si INOUT
 Avantaje - imbunatatirea performantelor sistemului prin:
● Scaderea comunicaţiei între aplicaţie şi serverul bazei de date
● Scaderea timpului de execuţie 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 aplicaţii executa operaţiile de prelucrare pe
server prin intermediul procedurilor stocate
Functii definite de utilizator

 O func ţ ie definit ă de utilizator (user-defined function) este o funcţie
memorată in baza de date, la fel ca o procedur ă stocată
 O funcţiefiare numai parametri de intrare, returneaz ă întotdeauna o valoare
şi poate folosit ă direct în expresii
(o procedur ă stocată poate să returneze 114/194
7/14/2019
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
CREATE FUNCTIONIF Func_Media(disc
EXISTS Func_Media$$
varchar(4)) RETURNS float BEGIN
DECLARE nota_medie float;
SELECT AVG(nota) INTO nota_medie FROM DISCIPLINE, EXAMENE
WHERE DISCIPLINE.idDiscipline = EXAMENE.idDiscipline
AND nota_medie;
RETURN Acronim = disc;
END$$ DELIMITER ;
 Utilizarea intr-o expresie: select Func_Media('PBD')*2;
Triggere
 Un trigger este o procedur ă stocată specială, care este executată automat
atunci când se efectuează operaţii de actualizare a relaţiilor (INSERT,
DELETE, UPDATE)
 Triggerele pot fi create folosind extensiile procedurale ale limbajului SQL;
7/14/2019 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 capacităţii SGBD-ului de menţinere a integrităţii datelor relaţionale -
impunerea constrângerile explicite cum sunt dependenţele de date (dependenţe
funcţionale 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
legătur ă cu accesarea relaţiilor .
Domenii si variabile locale

 Domenii locale: proceduri stocate, functii, triggere, blocuri (delimitate prin
instructiunile: BEGIN ... END); un bloc este considerat o instructiune
compusa
 Variabilele locale sunt folosite pentru stocarea in memorie a unor valori
care pot fi testate sau modificate (ca în orice alt limbaj) şi, în plus, pentru
7/14/2019 transferul datelor către şi de la tabelele bazei de date
 Variabilele locale au ca domeniu de definiţie blocul procedura, functia sau

trigger-ul
O variabilăînlocal
careăau
sefost declarate
declar
ă si se initializeaza diferit de la un SGBD la altul.
De exemplu:
• in Transact SQL:
DECLARE @contor INT
SELECT @contor = 0
• in PL/SQL (Oracle): DECLARE CONTOR := 1;
• in MySQL: DECLARE contor INT;
SET contor = 0;
 Ordinea de execu ţ ie a instruc ţ iunilor este controlată prin instrucţiuni ca:
BEGIN...END REPEAT...UNTIL FOR
GOTO WHILE
IF...ELSE BREAK
RETURN CONTINUE
Instructiuni SQL extinse

 Extensiile procedurale definesc clauze suplimentare in instructiunile SQL,
astfel încât acestea să poată fi folosite în combinaţie cu variabilele locale
 De exemplu - instrucţiunea SELECT prin care se incarca valori ale unor
atribute selectate din baza de date in variabile locale:
• In Transact-SQL: SELECT @var1 = col1, @var2 = col2, ... @varn = coln
7/14/2019
FROM lista_tabele WHERE conditie
• In PL/SQL (Oracle): SELECT lista_coloane INTO lista_variabile

FROM lista_tabele [WHERE conditie] [optiuni]
• In MySQL: SELECT lista_coloane INTO lista_variabile
FROM lista_tabele [WHERE conditie] [optiuni]
 Astfel de instrucţiuni sunt utile pentru interogările 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 când o interogare returnează o mulţime 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)
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;
Exemplu: Cursor intr -o procedura stocata MySQL (1)

 Procedura: Calculul mediei unui student dat (nume, prenume)
DELIMITER $$
DROP
CREATEPROCEDURE
PROCEDURE IF EXISTS Medii_Studenti
Medii_Studenti(OUT $$ float, IN s_nume varchar(20),
media
IN s_prenume varchar(20))
7/14/2019 BEGIN Proiectare Baze de date.pdf
DECLARE done INT DEFAULT 0; DECLARE student, id_student INT;

/*Crearea
DECLAREcursorului*/
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 ;
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:
SET @nume = 'Popescu', @prenume = 'Marius';
call Medii_Studenti(@media, 'Popescu', 'Marius');
select @nume, @prenume, @media;

Se obtine rezultatul: @nume @prenume @media
Popescu Marius 6.5
 Parcurgerea liniilor cursorului se poate face si cu instructiunea while:

WHILE done = 0 AND id_student <> student DO
END WHILE;
 Declararea unei variabile locale (cu instructiunea DECLARE) se poate face
numai intr-un bloc BEGIN ... END si numai la inceputul acestuia
 Declaratiile trebuie sa fie facute intr-o anumita ordine: cursoarele se declara
inaintea declararii handler-elor, iar variabilele locale inaintea declararii
cursoarelor si a handler-elor
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 $$
7/14/2019
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).
Limbajul SQL integrat (Embeded SQL)

 În limbajul SQL integrat (Embeded SQL) instrucţiunile 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 operaţii este realizat prin instrucţiunile limbajului gazdă,
7/14/2019 iar operaţiile cu baza de date sunt realizate prin instrucţiuni SQL

Instrucţiunile
prelucrate de SQL integrate în
un instrument programul
software scris(numit
adecvat în limbajul gazdă sunt
preprocesor), fiind
transformate în apeluri de funcţii ale unei biblioteci speciale a SGBD-ului
 Rezultatul preprocesării 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
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
independente de SGBDspecifice unui anumit SGBD si interfete
 Interfete specifice unui anumit SGBD sunt biblioteci care contin funcţii şi
7/14/2019
macrodefiniţii ce permit aplicaţiilor să interacţioneze 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)
 Interfe ţe 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)
Exemplu: Client pentru MySQL C API

 Programul client se link-eaza cu biblioteca libmysql si comunica cu serverul
pentru a introduce, citi si modifica datele din tabele
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include mysql.h
7/14/2019 char pwd[ ] = “...."; Proiectare Baze de date.pdf
int main(){
MYSQL * mysql ;
MYSQL_RES * res ;
MYSQL_ROW row ; int i;
mysql = mysql_init(NULL);
mysql_real_connect (mysql, “localhost”, “root”, pwd, “intreprindere”, 0, NULL, 0);
mysql_query (mysql, "select * from ANGAJATI");
while((row = mysql_fetch_row (res))){
for (i=0;i<mysql_num_fields(res); i++) printf("%s ", row[i]);
printf("\n");
}
mysql_close(mysql);
}
 Programul client apeleaza functiile din biblioteca pentru conectare la server,
interogare, parcurgerea liniilor rezultat, inchiderea conexiunii
Interfata ODBC
 Tehnologia ODBC (Open Database Connectivity) - interfaţă de programare a
aplicaţiilor prin apel de funcţii independente de sistemul SGBD folosit

Independenţă se obţine prin drivere specifice fiecărui SGBD
 Driverul transformă apelurile de funcţii ODBC în comenzi SQL (sau într-un
limbaj procedural de extensie a limbajului SQL) si le transmite SGBD-ului
Interfaţa ODBC
Aplicaţie
Administrator de drivere
Driver Driver Driver
Sursa Sursa Sursa

de date
de date de date
SGBD şi Baza SGBD şi Baza SGBD şi Baza

de date de date de date
Tipuri de date si functii ODBC

 ODBC defineşte două seturi de tipuri de date si corespondenta intre ele:
• tipuri ODBC SQL - corespund tipurilor SQL în care sunt memorate datele în tabelele
bazei de date
• tipuri ODBC C - corespund tipurilor C ale variabilelor (locale) în care se încarcă şi se126/194
prelucrează datele în programele de aplicaţii
7/14/2019
 Identificatorii ODBC: SQLHANDLE cu mai multe variante:
•
SQLHENV (HENV) - identificator al mediului de executie a operatiilor ODBC
• SQLHDBC (HDBC) - identificator al unei conexiuni cu o sursă de date
• SQLHSTMT (HSTMT) - identificator al unei instrucţiuni SQL
 Alocarea identificatorilor se face cu functia: SQLAllocHandle ( )
 Instructiunile ODBC (HSTMT) pot fi statice si dinamice (parametrizate)
 Instructiunile statice se pot executa:
• direct: SQLExecDirect (SQLHSTMT hstmt, SQLCHAR *instr, SQLINTEGER len);
•
SQLPrepare(SQLHSTMT hstmt, SQLCHAR *instr, SQLINTEGER len);

cu preparare: SQLExecute (SQLHSTMT hstmt);
 Instructiunile dinamice folosesc prepararea si marcarea (cu ?) a parametrilor
Exemplu: program ODBC (1)

#include <windows.h> #include <stdio.h> #include <string.h> #include <sql.h>
#include <sqlext.h> #define LEN 128
int main () {
SQLRETURN rc; // Cod de retur al apelurilor ODBC
SQLHENV henv;
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf // Handle pentru environment 127/194
SQLHDBC hdbc; // Handle de conectare
SQLHSTMT hstmt; // Handle pentru instrucţiuni ODBC
SQLCHAR comanda[LEN]; // Buffer comanda SQL
SQLCHAR sursaDate[ ] = “intreprindere”;
SQLCHAR szUID[ ] = “root”, szAuthStr[]= “parola”;
SQLCHAR sNume[LEN], sPrenume[LEN], sAdresa[LEN];
SQLINTEGER nId, cbNume, cbPrenume, cbAdresa, cbId=0;
// Alocare handler HENV
SQLAllocHandle (SQL_HANDLE_ENV, SQL_NULL_HENV,&henv);
// Setarea versiunii driverului ODBC3
SQLSetEnvAttr (henv, SQL_ATTR_ODBC_VERSION,
(SQLPOINTER)SQL_OV_ODBC3, SQL_IS_INTEGER);
SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
SQLConnect (hdbc, sursaDate, SQL_NTS, szUID, (SWORD)strlen((const char*)
(szUID)), szAuthStr,(SWORD)strlen((const char*)(szAuthStr)));
Exemplu: program ODBC (2)

// Alocare handle HSTMT
SQLAllocHandle (SQL_HANDLE_STMT,hdbc, &hstmt);
// Actualizarea tabelului ANGAJATI
strcpy ((char*)comanda,
“UPDATE ANGAJATI SET Adresa = ‘Bacau’ WHERE IdAngajat=1”);
SQLExecDirect (hstmt, comanda, SQL_NTS);
7/14/2019
strcpy ((char*)comanda, Proiectare Baze de date.pdf
“UPDATE ANGAJATI SET Adresa = ‘Cluj’ WHERE IdAngajat=2”);
SQLExecDirect (hstmt, comanda, SQL_NTS);
// Afisarea liniilor tabelului ANGAJATI
strcpy ((char*)comanda, “select * from ANGAJATI”);
SQLPrepare (hstmt, comanda, strlen((const char*)comanda));
rc = SQLExecute (hstmt);
while ((rc=SQLFetch(hstmt))!= SQL_NO_DATA){
SQLGetData(hstmt, 1, SQL_C_LONG, &nId, 0, &cbId);
SQLGetData(hstmt, 2, SQL_C_CHAR, sNume, LEN, &cbNume);
SQLGetData(hstmt, 3, SQL_C_CHAR, sPrenume, LEN, &cbPrenume);
SQLGetData(hstmt, 5, SQL_C_CHAR,sAdresa, LEN, &cbAdresa);
printf(“%10d %20s %20s %20s\n”, nId, sNume, sPrenume, sAdresa);
}
SQLFreeStmt (hstmt, SQL_DROP); SQLDisconnect (hdbc);
SQLFreeConnect (hdbc); SQLFreeEnv (henv); }
Capitolul 5: Normalizarea relatiilor

 Dependentele de date si formele normale ale relatiilor
 Redundanta datelor si anomaliile de actualizare a relatiilor
 Dependentele functionale (DF)
● Tipuri de DF
7/14/2019
● Multimi de DF Proiectare Baze de date.pdf
● DF si cheile relatiilor
 Descompunerea relatiilor
● Descompunere fara pierdere de informatie la jonctiune
● Descompunere cu conservarea DF

Formele
● FN1
normale ale relatiilor determinate de DF:
● FN2
● FN3
● FNBC
 Dependente multivalorice – forma normala FN4
 Dependente de jonctiune – forma normala FN5
Dependentele de date
 Dependenţ ele de date (data dependencies) reprezintă constrângeri care se
impun valorilor atributelor unei relaţii şi care determină proprietăţile relaţiei în
raport cu operaţiile de inserare, ştergere şi actualizare a tuplurilor.
 O formă normal ă a unei relaţ ii (normal form) presupune anumite condiţii pe
care le îndeplinesc valorile atributelor şi dependenţele de date definite pe
7/14/2019
acea relaţie Proiectare Baze de date.pdf

Dependentele
● Dependentede date: E.F. Codd a propus trei forme normale: FN1, FN2, FN3;
functionale:
apoi a fost introdusă forma normală Boyce-Codd (FNBC)
● Dependenţelor multivalorice: forma normala 4 (FN4)
● Dependenţelor de joncţiune: forma normala 5 (FN5)
 Formele normale ale relaţiilor formează o colecţie ordonată (FN1, FN2, FN3,
FNBC, FN4, FN5), şi ele impun condiţii din ce în ce mai restrictive asupra
dependenţelor de date

Ordonarea
aflată în FN2 formelor
este înnormale de rela
FN1, orice la FN1
ţie înlaFN3
FN5este
înseamn ă căşi orice
în FN1 relaţie
FN2 etc.
 Normalizarea relaţ iilor (normalization) constă în descompunerea lor, astfel
încât relaţiile să fie in forme normale cât mai avansate
Redundanta datelor si anomaliile de actualizare

 In relatia AP, cu cheia primara PK={IdAngajat, IdProiect} sunt valori
redundante ale atributelor: Nume, prenume, Adresa
● Anomalii
prenumele,deadresa)
inserare : nu
dac seexist
ă nu pot introduce
ă cel puţindate desprelauncare
un proiect angajat (numele,
acesta să lucreze
● Anomalii de ştergere: dacă se şterg toate tuplurile referitoare la un anumit, se
pot pierde toate datele referitoare la acei angajaţi care lucrează doar la proiectul
7/14/2019
respectiv Proiectare Baze de date.pdf
● Anomalii de actualizare
atributele care : dacă se modific
au valori redundante, stareaă rela
într-un tuplu valoarea
ţiei poate unuia din ă
deveni inconsistent
IdAngajat Nume Prenume Adresa IdProiect Ore
1 Ionescu Ion Bucuresti P1 100

2 Popescu Petre Ploiesti P1 80
3 Marinescu Marin Craiova P1 200
1 Ionescu Ion Bucuresti P2 100
2 Popescu Petre Ploiesti P2 120
Eliminarea anomaliilor datorate redundantei

 Eliminarea anomaliilor provocate de redundanta datelor se poate face:
● Fie prin prevederea unor proceduri stocate (sau triggere) care sa verifice
● corectitudinea fiecarei operatii

Fie prin descompunerea de care
relatiilor actualizare
prezintaa redundante
relatiilor in relatii mai simple;
exemplu: descompunerea relatiei AP in 2 relatii, A si P
A P
IdAngajat Nume Prenume Adresa IdAngajat IdProiect Ore

1 Ionescu Ion Bucuresti 1 P1 100
2 Popescu Petre Ploiesti 2 P1 80
3 Marinescu Marin Craiova 3 P1 200
1 P2 100
2 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 numărul 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)
 Dependentele func Dependente functionale

ţ ionale (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)
7/14/2019 X→Y Proiectare Baze de date.pdf
valorilor
exista in atributelor
R daca si numai
X din doua
dacatupluri
pentrut 1orice
si t2 din
stare
r (ta1 ∈
relatiei
r si t2 r(R),
∈ r) implica
egalitatea
egalitatea valorilor atributelor Y din acele tupluri, adica:
t1[X] = t2 [X] ⇒ t1[Y ] = t2 [Y ]
 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 relaţiilor:
 se pot preciza explicit (şi atunci ele implică DF corespunzătoare)
 pot fi deduse din mulţimea DF stabilite de proiectant, folosind diferiti algoritmi
Tipuri de dependenţe funcţionale

 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
 Dependenţe funcţionale triviale si ne-triviale
● O dependenta functionala este triviala daca este satisfacuta de orice stare a
relatiei; in general X → Y este triviala daca Y ⊆ X
● Celelalte dependente (in care Y nu este o submultime a lui X) sunt ne-triviale
 Dependenţele funcţionale par ţiale si totale
● O dependenţă funcţională X →Y este par ţială ( partial dependency ) dacă există o
submulţime proprie Z a lui X (Z ⊆ X) care determină funcţional pe Y (Z → Y)
● O dependenţă funcţională X → Y este totală (full dependency ), dacă nu există nici
o submulţime proprie Z a lui X care să determine funcţional pe Y . Rezulta:
● dacă atributul X este simplu, dependenţa funcţională X → Y este totală
● dacă X este o cheie candidată a lui R, atunci dependenţa X → R este totală
 Atributele care apar ţin unei chei se numesc atribute prime, iar celelalte se
numesc atribute neprime
Multimi de dependente functionale (1)

 Proiectantul bazei de date specifică acele dependenţe funcţionale între
atribute care sunt evidente din punct de vedere semantic; de ex, in AP:
(a)
(b) IdAngajat
IdAngajat →Nume
→
Prenume
(c) IdAngajat → Adresa
7/14/2019
(d) {IdAngajat,IdProiect} →Ore Proiectare Baze de date.pdf

Din acestea
(inferen se pot deduce
ţă - inference rules)siale
alteluiDF, folosind regulile de deducere
Armstrong:
 1. Reflexivitatea (reflexivity ): dacă Y ⊆ X, atunci X →Y; prin această
regulă se deduc DF triviale; de exemplu în relaţia AP:
(e) {IdAngajat,IdProiect}
(f) {IdAngajat,
→IdAngajat
IdProiect}→IdProiect
 2. Augmentarea (augmentation): dacă X →Y, atunci (X ∪ Z) →(Y ∪ Z);
următoarele DF (g şi h) sunt deduse prin augmentare, pornind de la
dependenţele funcţionale (a) şi respectiv (b), augmentate cu Z = {Nume},
respectiv Z = {Prenume} (se stie ca Nume ∪ Nume = Nume etc.)
(g) {IdAngajat, Nume} →Nume
(h) {IdAngajat, Prenume} →Prenume
Multimi de dependente functionale (2)

 3. Tranzitivitatea (transitivity ): dacă X→Y şi Y→Z, atunci X→Z. De
exemplu, din DF (a) şi (e) rezultă:
{IdAngajat,IdProiect} →Nume
 Aceste trei reguli sunt suficiente pentru calculul tuturor dependenţelor
funcţionale pe care le implică o mulţime dată de DF
7/14/2019
 Din aceste reguli de bază se pot deduce şi alte reguli; de exemplu:
Proiec ţ ia ( projection): dacă X→(Y ∪ Z), atunci X→Y şi X→Z

Reuniunea (union): dacă X→Y şi X→Z, atunci X→(Y ∪ Z)
Pseudo-tranzitivitatea ( pseudo-transitivity ): dacă X→Y şi (W ∪ Y) →Z, atunci
(W ∪ X) →Z.

Reprezentarea dependentelor functionale:
Nume
Prenume
IdAngajat
Adresa
IdProiect
Ore
Inchiderea unei multimi de DF

 Fiind dat ă o mul ţ ime F de DF, mul ţ imea tuturor DF care sunt implicate de F se
numeşte închiderea mul ţ imii 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 X→Y poate fi dedusă dintr-o mulţime F de DF, se afla
închiderea F+ a mulţimii F şi se testează dacă (X→Y)∈F+
7/14/2019
● Două mul ţ imi 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 mul ţ ime G de DF este minimă dac ă satisface următoarele condi ţ ii:
● membrul drept al oric ărei DF din G este un atribut simplu;
● orice dependenţă func ţ ional ă din G este total ă;
● mul ţi mea G este ireductibil ă, adic ă, dac
ă se exclude o DF din G, mul ţ imea rezultat ă
H nu este echivalent ă cu G (adic ă H ≠ G+).
+
 Acoperirea minimă a unei mul ţ imi F de DF (minimal cover of a set F of

DFs) este o mul ţi me minimă de dependenţ e func ţi onale G care este
echivalent ă cu F, adic ă G+ = F+
● Pot exista mai multe acoperiri minime ale unei mulţimi de DF
Dependenţele funcţionale şi cheile relaţiilor

 In orice relaţie pot exista două categorii de DF:
● DF determinate de cheile relaţiei; astfel de DF nu produc redundanţa datelor şi nici
anomalii de actualizare a relaţiei
● DF în care atributul determinant nu este o cheie a relaţiei; astfel de DF produc
redundanţa datelor şi anomalii de actualizare a relaţiei
7/14/2019  DF determinate de chei (primar ă sau secundara) sunt constrângeri implicite,
conţinute în definiţia relaţiei şi sunt verificate şi impuse automat de SGBD

● Proiectantul bazei de date nu trebuie să prevadă nimic suplimentar pentru ca
aceste constrângeri să fie satisf ăcute de orice stare a relaţiei
 DF în care atributul determinant nu este o cheie sunt constrângeri 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 funcţii în programele de aplicaţii
(b) Se descompune relatia in relatii mai simple, in care nu mai exista astfel de DF, dar
trebuie verificate conditiile de descompunere reversibila
Inchiderea unui atribut fata de o multime de DF (1)

 Închiderea unui atribut faţă de o mul ţ ime F de DF (the closure of an
atribute under F ). Fie un atribut X al unei relaţ ii pe care este definit ă
mul ţ imea F de DF ; mul ţ imea X+ a tuturor atributelor determinate de X
(X→X+) se numeşte închiderea lui X în raport cu F
 Algoritmul prin care se poate deduce inchiderea unui atribut :
1. se setează X+ =X
7/14/2019 2. repetă Proiectare Baze de date.pdf
P_X+ = X+
pentru fiecare DF Y→Z din F
dacă Y ⊆ X+ atunci X+ = X+ ∪ Z
până când P_X+ == X+
 Se aplică acest algoritm pentru dependenţele funcţionale din relatia AP:
F AP = {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}
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ă funcţional nici un alt atribut (nu apare în partea stângă a nici
unei DF) este chiar atributul respectiv:
{Nume}+ = {Nume}, {Prenume}+ = {Prenume}, {Adresa}+ = {Adresa}, {Ore}+ = {Ore}
■ Algoritmul de calcul al închiderii unui atribut faţă de o mulţime F de DF
poate fi folosit pentru a verifica dacă o DF dată X→Y este consecinţa logică
7/14/2019
a mulţimii F (daca (X→Y) ∈ F+) Proiectare Baze de date.pdf
■ Pentru aceasta, se calculeaz ă X + faţă de F; dacă Y ⊆ X+, atunci (X→Y)∈ F+,

deci X→Y este consecinţa logică a lui F
■ Acest algoritm poate fi folosit şi pentru a verifica dac ă un atribut K (simplu
sau compus) este supercheie a relaţ iei R cu mul ţ imea F de DF
■ Pentru aceasta
supercheie în Rse calculează K în raport cu F; daca K = R, atunci K este
+ +
■ Dintr-o supercheie se pot deduce cheile relaţiei, testând condiţia de

ireductibilitate pentru fiecare din atributele componente ale supercheii
■ Algoritmul
inchiderea de găatribut
unui sire a cheilor
fata deunei relaţii din
o multime muleste
de DF ţimeaprezentat
DF bazatinpe
continuare
Aflarea cheilor unei relaţii din multimea DF

■ Fiind dată o relaţie cu schema R şi mulţimea F a DF pe această relaţie, cheile
candidate K ale relaţiei se pot afla cu urmatorul algoritm:
1. se setează K = R şi se selectează din K un atribut X (preferabil nedeterminant);
2. se testează (K – X) pe baza multimii F: dacă (K – X) este supercheie a relaţiei R,
atunci K = (K – X), altfel K nu se modifica
3. se selectează un alt atribut X din K şi se reia pasul 2, pana cand (K-X) nu mai este
supercheie in R
Prinrela
■ ale parcurgerea
ţiei. Dacă repetată a multe
există mai paşilorchei
2 şi candidate,
3, se găseşatunci
te unaordinea
din cheile candidate
găsirii cheilor
candidate depinde de atributul selectat în pasul 1 al algoritmului
■ De exemplu, se aplică algoritmul de mai sus pentru găsirea cheii primare a
relaţiei AP cu mulţimea F AP a DF (definita la inceputul capitolului)
■ Se porneşte cu K = R = {IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore},
se selectează X = Nume şi se verifică dacă {K – X} este supercheie in R
● Pt. aceasta se calculeaza {K – X}+ = {IdAngajat, Nume, Prenume, Adresa, IdProiect,
Ore} = R, deci {IdAngajat, Prenume, Adresa, IdProiect, Ore} este supercheie in R
■ Se
atribute
repeta
potpasul
fi eliminate,
2 pentrusiXse= obtine
Prenume,
K = apoi
{IdAngajat,
X = Adresa
IdProiect}
si X = Ore; aceste
■ Atributele IdProiect, IdAngajat nu se pot elimina din supercheia K, deci K e
cheie
Descompunerea relatiilor
 O descompunere D = {R1, R2,..Ri,...Rk} a schemei de relaţ ie R (relation
schema decomposition) este format ă din submul ţ imi 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 relaţ i ei r(R) pe
aceste submul ţ imi de atribute
 Fie o relaţie cu schema R şi mulţimea F de DF ale acesteia; o descompunere
7/14/2019 a relaţiei r(R) este reversibil ă dacă are proprietăţile de:
● Jonc ţi une f ăr ă pierdere de informaţ ie (conservarea informatiei); inseamna ca

r = r1 >< r2 >< …ri >< …rk
● Conservarea dependenţ elor func ţi onale: dac ă oricare din dependenţ ele din F se
reg ăseşte sau poate fi dedusă din DF ale relaţ iilor cu schemele R1,R2,...Ri,…Rk

Teorema lui Ullman. Descompunerea
R este o descompunere D informa
f ăr ă pierdere de ţ ie laa jonc
= {R1, R2} uneiţ iune
scheme de rela
în raport cuţ ie
mul ţ imea F de DF, dac ă şi numai dac ă este îndeplinit ă una din condi ţ iile:
(a) ((R1 ∩ R2) → (R1 -  R2)) ∈ F+, sau (b) ((R1 ∩ R2) → (R2 - R1)) ∈ F+
● Dacă R1 ∩ R2 este o cheie a uneia dintre relaţiile R1 sau R2, atunci
descompunerea
● Demonstratie: este f ăr ă pierdere de informaţie la joncţiune;
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
Jonctiune fara pierdere de informatie

 Lipsa acestei proprietăţi se manifestă în mod paradoxal prin apariţia unor
tupluri noi (parazite) în relaţia obţinută prin joncţiunea relaţiilor r1,r2,...ri,...rk,
tupluri care nu existau în relaţia r(R)
 Exemplu: descompunerea relaţiei AP în relaţiile A şi P:
A ∩ P = {IdAngajat},
A − P = {Nume,Prenume,Adresa}; P − A = {IdProiect,Ore}
7/14/2019
Din DF IdAngajat→Nume, IdAngajat→ Prenume, 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 f ăr ă pierdere de informaţie la joncţiune
 Descompunerea succesivă f ăr ă pierdere de informaţie la joncţiune
● Dacă o descompunere D = {R1,R2,...Ri,...Rk} a unei scheme R este f ăr ă pierdere
de informaţie la joncţiune în raport cu mulţimea F de DF
● şi D1 = {Q1,Q2,...Qm} este o descompunere f ăr ă pierdere de informaţie la
joncţiune a lui R1 în raport cu proiecţia lui F pe R1,
● atunci descompunerea D2 = {Q1,Q2,...Qm,R2,...Rk} este o descompunere f ăr ă
pierdere de informaţie a lui R în raport cu F
 Această proprietate permite descompunerea f ăr ă pierdere de informaţie la
joncţiune a unei relaţii în mai multe etape (mai întâi in două relaţii, apoi
fiecare dintre acestea se descompune în alte două relaţii, ş.a.m.d)
Conservarea dependenţelor funcţionale

 O descompunere D = {R1, R2, ...Ri,...Rk} a unei scheme de relaţ ie R prezint ă
proprietatea de conservare a mul ţ imii F de DF, dac ă reuniunea proiec ţ iilor lui
F pe schemele de relaţ ii Ri (unde 1 ≤ i ≤ k) este echivalent ă cu F, adic ă:
((ΠR1(F)) ∪ (ΠR2(F)) ... ∪ (ΠRk(F)))+ = F+
 Proiec ţ ia unei mul ţ imi de dependenţ e func ţ ionale. Fiind dat ă mul ţ imea F
de DF definite pe R, şi o descompunere D = {R1,R2,..Rk} a lui R, proiec ţi a lui
+
F pe Ri (unde 1 ≤ i ≤ k), notat ă ΠRi(F), este mul ţ imea de DF X→Y ∈ F , astfel
7/14/2019 încât X ⊆ Ri şi Y ⊆ Ri Proiectare Baze de date.pdf
 Exemplu: descompunerea relaţiei AP in relaţiile A şi P:

F AP = {IdAngajat→Nume, IdAngajat→Prenume,
IdAngajat→ Adresa,{IdAngajat,IdProiect}→Ore}
Proiecţiile mulţimii F AP pe A si P sunt:
Π A(F AP) = {IdAngajat→Nume, IdAngajat→Prenume, IdAngajat→ Adresa}
ΠP(F AP) = {{IdAngajat,IdProiect}→Ore}
Dat fiind că Π A(F AP)∪ ΠP(F AP) = F AP, rezultă că această descompunere conservă DF

Dacă, prin descompunerea
verificarea lor, trebuie să seunei relaţii, mai
efectueze se pierd una ţsau
întâi jonc mai
iunea multe
rela ţiilor DF, pentru
obtinute
 Cele două proprietăţi ale unei descompuneri, conservarea informaţiei şi
conservarea dependenţelor funcţionale, sunt independente
Formele normale ale relatiilor (FN1 si FN2)

 O relaţ ie este normalizat ă în prima formă normal ă (FN1) dac ă fiecare atribut
ia numai valori atomice şi scalare din domeniul său de defini ţi e
● Sistemele SGBD relaţionale nu admit relaţii care să nu fie cel puţin în FN1, dar
proiectarea relaţiilor normalizate în FN1 este intotdeauna posibila
 Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaţ ie
r(R) este normalizat ă în FN2, dac ă este în FN1 şi dac ă în F + nu exist ă nici o
DF par ţ ial ă a unui atribut neprim faţă de o cheie a relaţ iei
7/14/2019
 Exemplu: relatia AP cu multimea F AP de DF este in FN1, dar nu este in FN2:
F AP = {IdAngajat → Nume, IdAngajat → Prenume,

IdAngajat → Adresa, {IdAngajat, IdProiect} → Ore}
● Cheia primara este {IdAngajat, IdProiect}, deci {IdAngajat, IdProiect}→Nume
● Această DF se poate deduce din F AP; cf. reflexivitatii, {IdAngajat, IdProiect} →
IdAngajat; cf.tranzitivitatii, daca IdAngajat→Nume, {IdAngajat, IdProiect}→Nume
● DF {IdAngajat, IdProiect}→Nume este par ţială deoarece exista: IdAngajat→Nume
● Rezultă că relaţia 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
Impunerea DF in relatia nenormalizata AP (1)

 Dacă relaţia AP nu se normalizează, atunci trebuie să se prevadă proceduri
speciale care să verifice şi să impună DF care nu sunt determinate cheia PK
 La orice operaţie de actualizare un trigger verifica valorile care urmează să fie
introduse şi nu se admit doi sau mai mulţi angajaţi cu acelasi identificator
(IdAngajat) dar cu nume, prenume sau adresă diferite
 Trigger-ul pentru relatia AP arata astfel:
DELIMITER $$ DROP TRIGGER normalizare . trigger_AP $$
CREATE TRIGGERdone
BEGIN DECLARE `trigger_AP` AFTER0;INSERT ON `normalizare`.`AP` FOR EACH ROW
INT DEFAULT
DECLARE error INT DEFAULT 0;
DECLARE l_nume, l_prenume, l_adresa VARCHAR(20);
DECLARE cursor_AP CURSOR FOR SELECT Nume, Prenume, Adresa FROM AP
WHERE IdAngajat = NEW.IdAngajat;
OPEN cursor_AP;
REPEAT FETCH cursor_AP INTO l_nume, l_prenume, l_adresa;
IF NEW.Nume <> l_nume OR NEW.Prenume != l_prenume OR NEW.Adresa <> l_adresa
THEN SET error = 1; END IF;
UNTIL done = 1 OR error = 1
END REPEAT; CLOSE cursor_AP;
IF error = 1 THEN
DELETE FROM AP WHERE IdAngajat=NEW.IdAngajat AND IdProiect=NEW.IdProiect; END IF;
END $$ DELIMITER ;
Impunerea DF in relatia nenormalizata AP(2)

 Trigger-ul este de tip AFTER INSERT, astfel ca linia dorita se insereaza mai
intai in tabel, cu verificarea de catre SGBD a unicitatii cheii primare

Dupa inserare
valoarea se citesc(NEW.IdAngajat)
nou inserata intr-un cursor toate liniile care au pentru IdAngajat
 Se parcurg liniile cursorului si se verifica daca valorile nou introduse ale
atributelor Nume, Prenume, Adresa (NEW.Nume, NEW.Prenume,

NEW.Adresa) difera de cele
Daca, dupa parcurgerea existente;
tuturor daca difera,error=1,
liniilor cursorului, se seteaza error linia
se sterge = 1 nou
introdusa, deci in final, linia nu este inserata in tabel.
 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,’Popescu’,’Mihai’,’Bucuresti’,4,60), ceea ce inseamna ca angajatul cu IdAngajat =1
este nedeterminat (este Ionescu Ion sau Popescu Mihai?)
● Aceasta linie nu se poate insera daca s-a activat trigger-ul trigger_AP

A treia forma normala (FN3)
Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaţ ie
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,
F AFS={IdAngajat Nume, Prenume,
→Nume, IdAngajat→Prenume,Adresa, Functie,
IdAngajat Salariu)
→ Adresa,
IdAngajat→Functie, Functie→Salariu}.
● Cheia primar ă a relaţiei este IdAngajat, şi poate fi dedusă din F AFS
7/14/2019 Primele patru DF sunt totale, deci rela ia Baze
Proiectare este în FN2
de date.pdf
●
● Relaţia nu este în FN3 datorita DF Functieţ →Salariu; 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 F AFS:
F AF={IdAngajat→Nume,IdAngajat→Prenume,IdAngajat → Adresa,IdAngajat→Functie}
FFS = {Functie→Salariu} si se deduc (sau se verifica) cheile relatiilor
● PK AF={IdAngajat}, PKFS={Functie}, deci AF si FS sunt in FN3
● F AF ∪ FFS = F AFS deci descompunerea conserva DF
● AF ∩ FS = {Functie} si ( Functie → Salariu) ∈ F AFS, deci, cf. regulii lui Ullman,
descompunerea este fara pierdere de informatie la jonctiune

Impunerea DF in relatia nenormalizata AFS (1)
Dacă relaţia AFS nu se normalizează, atunci trebuie să se prevadă proceduri
speciale care să verifice şi să impună DF care nu sunt determinate de cheia PK
 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`(INOUT error INT, s_id INT, s_nume VARCHAR(20), s_prenume
7/14/2019
VARCHAR(20), s_adresa VARCHAR(20),Proiectare
s_functia VARCHAR(20), s_salariu DECIMAL)
Baze de date.pdf
BEGIN DECLARE done INT DEFAULT 0;
DECLARE l_functia VARCHAR(20); DECLARE l_salariu DECIMAL;
DECLARE cursor_AFS CURSOR FOR
SELECT Functia, Salariu FROM AFS WHERE Functia = s_functia;
OPEN cursor_AFS;
REPEAT FETCH cursor_AFS INTO l_functia, l_salariu;
IF s_salariu <> l_salariu THEN SET error = 1; END IF;
END REPEAT;
CLOSE cursor_AFS;
IF error = 0 THEN
INSERT INTO AFS VALUES (s_id, s_nume, s_prenume, s_adresa, s_functia, s_salariu);END IF;
END$$ DELIMITER ;
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 exista si anomalii: se poate insera linia (1, ‘Mateescu’,
7/14/2019
’Viorel’,’Bucuresti’,‘inginer’, 2100), care nu respecta DF Functie → Salariu: pentru
functia ‘inginer’ se admite si salariul 2000 si salariul 2100

 Inserarea liniilor in tabelul AFS prin apelul procedurii stocate sp_AFS inlatura
aceasta anomalii

De exemplu, la apelul
SET @error = 0; procedurii stocate:
call sp_AFS(@error, 5, 'Druga', 'Ciprian', 'Bucuresti','inginer', 2001);
select @error;
se obtine @error=1 si linia respectiva nu va fi introdusa in tabelul AFS
Forma normala Boyce-

Boyce-Codd (FNBC)
 Fie schema de relatie R si multimea F de DF definite pe aceasta. O relaţ ie
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 relaţ iei
 Este evident că o relaţie în FNBC este în FN3, dar o relaţie în FN3 poate să
fie sau nu în FNBC
 Exemplu: relaţia EDP(IdElev, IdDisciplina,IdProfesor), cu cheia PK= {IdElev,
IdDisciplina} şi cu mulţimea F de DF:

IdDisciplina} şi cu mulţimea FEDP de DF:
FEDP = {{IdElev,IdDisciplina}→IdProfesor, IdProfesor →IdDisciplina}
 Se consider ă că relaţia este în FN1; din FEDP se observă că nu există DF
par ţiale faţă de cheia relaţiei (deci relaţia este în FN2) şi nu există nici o DF
a unui atribut neprim faţă de un alt atribut neprim, deci relaţia este în FN3
 Relaţia 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
IdProfesor →IdDisciplina (profesorul 1 preda si disciplina 1 si disciplina 2)
Impunerea DF in relatia nenormalizata EDP

■ Dacă relaţia EDP nu se normalizeaza, atunci trebuie să se prevadă o
procedura care să verifice şi să impună DF (IdProfesor →IdDisciplina) care nu
este determinata de cheia relatiei, pentru operatiile de INSERT si UPDATE
 De ex: se inlocuieste operatia INSERTcu apelul unei proceduri stocate careDF
verifica mai intai valorile si executa INSERT numai daca acestea respecta
DELIMITER $$
DROP PROCEDURE IF EXISTS `sp_EDP`$$
CREATE PROCEDURE `sp EDP`(INOUT error INT, s Elev INT, s Disciplina INT, s Profesor INT)
CREATE PROCEDURE sp_EDP (INOUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT)
BEGIN DECLARE
DECLARE done INTCURSOR
cursor_EDP DEFAULTFOR
0; DECLARE l_Disciplina INT;
SELECT IdDisciplina FROM EDP WHERE IdProfesor = s_Profesor;
OPEN cursor_EDP;
REPEAT FETCH cursor_EDP INTO l_IdProfesor;
IF s_Disciplina <> l_Disciplina THEN SET error = 1; END IF;
END REPEAT;
CLOSE cursor_EDP;
IF error = 0 THEN INSERT INTO EDP VALUES (s_Elev, s_Disciplina, s_Profesor);
END IF; END$$ DELIMITER ;
■ Pentru verificare: se sterge linia(1,2,1) (daca exista) si se executa:
● set @error=0; call sp_EDP(@error,1,2,1); select @error;
● se obtine @error = 1 si nu s-a inserat acest tuplu
Normalizarea relatiei EDP

■ Normalizarea relaţiei EDP astfel încât relaţiile obţinute 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ă relaţiile rezultate în oricare din aceste descompuneri
sunt relaţii în FNBC (fiind relaţii formate din două atribute).
■ Dintre cele trei descompuneri, descompunerea D1 prezintă proprietatea de
joncţiune f ăr ă pierdere de informaţie. Într-adevăr, EP ∩ PD = {IdProfesor},
PD − EP = {IdDisciplina} şi IdProfesor →IdDisciplina, deci este îndeplinită
condiţia lui Ullman de conservare a informaţiei.
■ Celelalte descompuneri, D2 şi D3, nu îndeplinesc această condiţie.
■ In oricare din aceste descompuneri se pierde dependenţa funcţională
{IdElev,IdDisciplina}→IdProfesor, deci relaţia EDP nu poate fi descompusă
în mod reversibil în relaţii FNBC.
Impunerea
Impunerea constrangerilor pierdute prin descompunere (1)
■ Dacă relaţia 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`(INOUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT)155/194
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 ;
OPEN
REPEAT cursor_EP_PD;
FETCH cursor_EP_PD INTO l_Elev, l_Profesor, l_Disciplina;
IF s_Elev = l_Elev AND s_Disciplina = l_Disciplina AND s_Profesor <> l_Profesor THEN
SET error = 1; END IF;
END REPEAT;
CLOSE cursor_EP_PD;
IF error = 0 THEN
INSERT INTO EP VALUES (s_Elev, s_Profesor);
INSERT INTO PD VALUES (s_Profesor, s_Disciplina);
END IF; END$$ DELIMITER ;
Impunerea
Impunerea constrangerilor pierdute prin descompunere (2)
■ Procedura sp_EP_PD primeşte ca argumente un flag de eroare şi valorile
celor trei atribute IdElev, IdDisciplină, IdProfesor care trebuie sa respecte
constrângerea {IdElev, IdDisciplina} → IdProfesor
■ În această procedura se creează un cursor în care se încarcă rezultatul
joncţiunii naturale între relaţiile EP şi PD pe atributul comun IdProfesor
■ Pentru fiecare linie a rezultatului joncţiunii EP >< PD se verifică respectarea
constrângerii dorite, testând valorile existente în linia respectivă cu noile valori
care urmeaz
● daca ă să fie introduse:
această constrângere este respectată, atunci se execută două instrucţiuni
INSERT, cate una in foiecare din tabelele EP si PD
● daca această constrângere nu este respectată, nu se introduce nici o linie
■ Exemplu: daca
prin INSERT setabelul EP contine
pot introduce linia (1,1)
si valorile si pentru
(1,1,2) tabelul (IdElev,
(PD) contine linia (1,1),
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: set @error = 0; call sp_EP_PD(@error, 1,1,2); select
@error; produce @error=1 si nu se introduce nici o linie
Dependente multivalorice
 O dependenţă multivaloric ă - DMV- (multivalued dependency ) X→→Y
specificat ă pe schema de relatie R = {X,Y,Z} stabileşte următoarele
constrângeri pe care trebuie să le respecte orice relaţ ie r(R): dac ă exist ă
dou
t3 şi ăt4tupluri cu urm i t2 în r propriet
t1ăştoarele astfel ca
ăţ it1[X]
: = t2[X]= x, atunci vor exista şi tuplurile
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 egalităţilor de mai sus, rezulta că, dacă într-o relaţie cu
schema R există DMV X→→Y, atunci există şi X→→Z, unde Z = R−(X∪Y)
 O DF este un caz particular al unei DMV: DF X→Y este o DMV X →→ Y cu
restricţia că unei valori a lui X îi corespunde o singur ă valoare a lui Y
 O relaţ ie cu schema R este în a patra formă normal ă (FN4) în raport cu o
mul ţ ime F de DF şi DMV dac ă este în FN1 şi dac ă, pentru orice DMV
netrivial ă X→→Y din F+, X este cheie a relaţ iei r(R).
 Asemănarea acestei definiţii cu definiţia FNBC: pentru FNBC se impun
restricţii DF, iar pentru FN4 se impun restricţii DMV
 Dacă o schemă de relaţie respectă condiţia de FN4, atunci înseamnă că ea
respectă şi condiţia de FNBC
Dependente de jonctiune
 Fie o schema de relaţ ie R şi R1,R2,...Rk submul ţ imi de atribute ale lui R,
unde R1 ∪ R2 ∪...∪ Rk = R. Se spune c ă exist ă o dependenţă de jonc ţi une
(DJ) pe R, notat ă *(R1,R2,...Rk), dac ă şi numai dac ă orice relaţ ie r (R ) este
egal ă cu jonc ţ iunea proiec ţ iilor relaţ iei pe submul ţ imile 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
7/14/2019
proiecţiile pe R1,R2,...Rk este f ăr Proiectare
ă pierdere de informaţie la jonctiune
Baze de date.pdf
● Relaţia r(R) este k -decompozabilă f ăr ă pierdere de informaţie 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 X→→Y în relaţia 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 mulţime dată
 Datorită acestor aspecte, analiza DJ are un pronunţat caracter intuitiv
Forma normala FN5

 O relaţ ie cu schema R este în a cincea formă normal ă (FN5) în raport cu o
mul ţ ime F de dependenţ e func ţi onale, multivalorice sau de jonc ţi une dac ă
este în FN1 şi dac ă, pentru orice dependenţă de jonc ţ iune *(R1,R2,...

Ri,...Rk) din F +, Ri (unde 1 ≤ i ≤ k) este o cheie a relaţ iei r(R)
 Având în vedere faptul că o dependenţă multivalorică este un caz special
de dependenţă de joncţiune, iar o dependenţă funcţională este un caz
7/14/2019
special
în FN5, de dependen
este în multivaloric
implicit ţă FN4, deci şăi ,înseFNBC,
poate şafirma
.a.m.d.că o relaţie care este
 S-a demonstrat că orice relaţie poate fi transformată în relaţii FN5 (FN4,

FNBC etc.) printr-o descompunere f ăr ă pierdere de informaţie, dar nu se

asigura conservarea
Conditiile tuturor
de normalizare DF
in FNBC, FN4 si FN5 se pot rezuma la faptul că
într-o relaţie nu trebuie să existe decât dependenţe determinate de chei
Proiectarea relatiilor normalizate

 Normalizarea relaţiilor 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 garanţie că s-a realizat cel mai bun model
 Proiectarea
conduce, în bazelor
general,de
la date
relaţiipornind de la diagrama
normalizate, deoarece:Entitate-Asociere
● Relaţiile corespunzătoare mulţimilor de entităţi sunt, de regulă, relaţii
normalizate, dat fiind că toate atributele descriu tipul de entitate respectiv.
● Relaţiile de asociere binar ă, care conţin două chei str ăine care refer ă cheile
7/14/2019
primare din cele două relaţii pe care le asociază, rezultă tot ca relaţii normalizate
● Relaţiile care modelează asocierile multiple pot să rezulte nenormalizate şi

necesită operaţii de normalizare suplimentare
 Dar, cu cât nivelul de normalizare creşte, cu atât se obţin mai multe relaţii
cu grad
opera maijonc
ţii de micţiune,
şi pentru
ceeafiecare
ce faceinterogare
ca timpulsunt necesare
de execu mai multe
ţie a interogărilor să
crească; in general, se recomandă ca:
● relaţiile asupra cărora se efectuează operaţii de actualizare frecvente să fie
normalizate într-o formă normală cât mai avansată
● rela
formţiile
ă deasupra cărora mai
normalizare redusă ă interogări frecvente pot fi păstrate într-o
se efectueaz
 Mentinerea unei relaţii într-o formă de normalizare mai redusă se numeşte
“denormalizare”, şi are scopul de a obţine performanţe ridicate la interogări

Algoritmi de normalizare
Analiza normalizării relaţiilor trebuie să fie facuta pentru orice proiect de
baze de date, pentru a asigura func ţionarea corectă a acesteia:
● Dacă o relaţie se păstrează într-o formă de normalizare mai redusă, atunci
trebuie să se prevadă proceduri de verificare şi impunere a dependenţelor de
date care nu sunt determinate de cheile relaţiei (ca si constrângeri explicite)
● Dacă se normalizeaza o relaţie, dar prin descompunere se pierd unele DF,
acestea pot fi impuse explicit prin proceduri stocate sau funcţii în programele de
aplicaţie, care execută joncţiunea între relaţiile rezultate şi impun constrângerea
7/14/2019
respectiva Proiectare Baze de date.pdf
 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 DF; algoritmul foloseste
notiunea de inchiderea unui atribut fata de o multime F de DF
Descompunerea fara pierdere de informatie la jonctiune (1)

 Fiind dată o relaţie cu schema R şi mulţimea F de DF, o descompunere D
f ăr ă pierdere de informaţie la joncţiune în relaţii într-o formă normală dorită
(FNBC, FN4, FN5) se poate obţine aplicând algoritmul următor:
1. se setează D = {R};
2. atât timp cât în D există o relaţie Q (cu mulţimea FQ a DF) care nu se află în
forma normală dorită:
+
7/14/2019 -mul
seţimea
alegeYo=DF
X+X X; Y din FQ şi se
–→ construie
Proiectare şte închiderea X a atributului X şi
Baze de date.pdf
- în D se înlocuieşte relaţia Q cu două relaţii: Q1 = X ∪ Y şi Q2 = X ∪ Z, unde

Z = Q – (X ∪ Y);

Demonstra ţie:
• La fiecare pas de execuţie a algoritmului, o relaţie Q se descompune în două
relaţii Q1 şi Q2, astfel încât Q1 ∩ Q2 = X, şi Q1 − Q2 = Y
• Din definiţia închiderii unui atribut rezultă că X→Y, deci, conform teoremei lui
Ullman, această descompunere este f ăr ă pierdere de informaţie la joncţiune
• Astfel de descompuneri succesive păstrează caracterul de descompuneri f ăr ă
pierdere de informaţie la joncţiune
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 mulţimea F de DF
F = {IdAngajat→Nume,IdAngajat→Preume, IdAngajat→ Adresa,IdAngajat→Functie,
Functie→Salariu, {IdAngajat,IdProiect}→Ore}
 Executia algoritmului:
• Se setează D = {R}
7/14/2019 • Din F se alege DF IdAngajat→Nume care
Proiectare Baze denu respectă condiţia impusă de FNBC
date.pdf
• Î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) = {IdProiect,Ore}.
• Se obtine descompunerea D a relaţiei 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 relaţia R11, in relatiile R111 si R112:
R
R112 =
111 {Functie, Salariu};
= {IdAngajat, Nume, este in FNBC
Prenume, Adresa, Functie}; este in FNBC
 Se poate demonstra usor ca descompunerea obtinuta D= (R111, R112, R12)
conserva si dependentele functionale
Capitolul 6: Gestiunea tranzactiilor

 Tranzactii
 Anomalii de acces concurent la bazele de date
● Actualizare pierduta
● Citire improprie
● Citire irepetabila
● Citire fantoma
7/14/2019
 Proprietatile tranzactiilor Proiectare Baze de date.pdf
 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
Tranzactii
 În mod obişnuit, un sistem SGBD deserveşte mai mulţ i utilizatori, care
accesează concurent datele din tabele
 Execuţ ia concurentă a mai multor procese poate avea loc:
● într-un sistem uniprocesor, prin partajarea (împăr ţ irea) timpului de execuţ ie 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)
7/14/2019
 O tranzac ţi e (transaction) este o unitate
logic ă de prelucrare indivizibil ă
(atomic ă) a datelor unei baze de date prin care se asigur ă consistenţ a
acesteia

O●tranzac ţ ie trebuie să asigure consistenţ a bazei de date in diferite situatii:
tranzactia se execută individual sau concurent cu alte tranzacţ ii
● apar defecte ale sistemului în cursul execuţ iei tranzacţ iei
 O tranzac ţi e este o operaţ ie indivizibilă de acces la baza de date care:
● fie se execut
efectuate ă cu bazei
asupra succesdetoate
dateac ţ iunile )şi se termină cu o validare a modificărilor
(commit
● fie nu poate efectua (din diferite motive) toate acţ iunile şi este abandonată şi
anulată (abort , rollback )

Exemplu
Exemplu: un sistem de
de rezervare tranzacti
a locurilor la curseeaeriene
● 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 operaţ ii:
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,
7/14/2019 prin inserarea unei linii noi în tabelul
ProiectareFACTURI;
Baze de date.pdf altfel, nu se face rezervarea
3. Se tipăreste factura
4. Se emite (tipăreşte) biletul
 Probleme care pot sa apara:
● Dacă sistemul se defectează după ce s-a executat pasul 2, s-a f ăcut o rezervare,
dar biletul nu a fost facturat şi nici emis
● Dacă defecţ iunea are loc după pasul 3, clientului i se trimite factura, dar el nu a
primit biletul
● Dac ă nu se defecteaz
doi pasageri ă sistemul,
diferiţ i, atunci dar doi agen
vor fi probleme ţ i de vânzări
la îmbarcarea atribuie acelaşi loc la
pasagerilor
 Astfel de probleme ar disparea dacă toate actiunile efectuate pentru o
rezervare ar fi grupate ca o operaţ ie indivizibilă (atomică)
Anomalii de acces concurent la bazele de date (1)

 Unitatea de transfer a datelor între discul magnetic şi memoria principală a
sistemului este un bloc, care corespunde unui sector de pe disc si in care

se
Un memoreaza mai multe
articol (data item) inregistrari
este un câmp care (tupluri)
memorează valoarea unui atribut
dintr-o înregistrare (tuplu), dar poate fi o înregistrare întreagă sau chiar o
grupare de inregistrari memorate intr-un bloc
7/14/2019
 Operaţ iile de acces la un articol X al bazei de date pot fi:
● read(X): citeşte articolul X din baza de date într-o variabilă a programului; pentru
simplificarea notaţ iilor se va considera că variabila în care se citeşte articolul X
este notată, de asemenea, cu X.
● write(X): scrie variabila de program X în articolul X al bazei de date.

 Tranzacţ iile lansate de diferiţ i utilizatori se pot executa concurent şi este
posibil să actualizeze aceleaşi articole ale bazei de date
 Dacă execuţ ia concurentă a tranzacţ iilor este necontrolată, este posibil ca
baza de date să ajungă într-o stare inconsistentă (incorectă), chiar dacă:
● fiecare tranzacţ ie în parte a fost executată corect
● nu au apărut defecte de funcţ ionare ale sistemului
Anomalii de acces concurent la bazele de date (2)

 Actualizare pierduta (lost update): rezulta X=X-M (b) in loc de valoarea
corecta X= X+N-M (a)
 Citire improprie (dirty read ): T2 citeste X+N, desi X=X+N nu a fost validata (c)
Timp T1 T2 T1 T2 T1 T2
read(X) read(X) read(X)
X=X+N
X=X+N X=X+N 169/194
7/14/2019
write(X) read(X)
write(X)
read(X) X=X-M read(X)
X=X-M write(X) X=X-M
write(X) write(X) write(X)
abort
(a) (b) (c)
 Citire irepetabil ă (nonrepetable read ): o tranzacţ ie citeşte un articol de două
ori, iar între cele două citiri, o altă tranzacţ ie a modificat chiar acel articol
 Citire fantomă ( phantom read ): o tranzacţ ie prelucrează un set de linii
rezultat al unei interogări si în timpul acestei prelucr ări o altă tranzacţ ie
insereaza sau sterge o linie
Proprietatile tranzactiilor (ACID)

 Atomicitatea (atomicity ): proprietatea unei tranzac ţi i de a reprezenta o
unitate de execuţ ie indivizibil ă, adic ă de a executa “totul sau nimic”
 C onsistenţ a (consistency ): proprietatea unei tranzactii de a efectua

modific ări corecte ale bazei de date
● o tranzacţ ie transformă baza de date dintr-o stare consistentă în altă stare
consistentă
● starea uneiimplicite
integritate baze desau
date este consistent
explicite ă dacă respectă toate constrângerile de
 I zolarea (isolation): proprietatea unei tranzac ţi i de a face vizibile modific ările

efectuate numai după ce a fost validat ă (committed )
● Dacă rezultatele par ţ iale ale unei tranzacţ ii sunt vizibile altor tranzacţ ii înainte de
validarea acesteia şi dacă se întâmplă ca această tranzacţ ie să fie abandonată şi
anulată (rollback ), atunci toate tranzacţ iile care au accesat rezultatele par ţ iale ale
acesteia vor trebui să fie anulate
● Aceste operaţ ii de anulare pot produce, la rândul lor alte anulări, ş.a.m.d.
 Durabilitarea (durability ): proprietatea prin care, după validarea unei

tranzacţ ii, modificările efectuate de aceasta în baza de date nu vor mai fi
pierdute datorită unor defectări ulterioare a sistemului
Operatiile efectuate de tranzactii

 Operaţ iile efectuate de o tranzacţ ie şi înregistrate de administratorul de
refacere (recovery manager ):
● begin : începutul execuţ iei unei tranzacţ ii
● read sau write: operaţ ii de citire sau scriere a articolelor din baza de date
● end : marchează terminarea operaţ iilor de scriere sau citire din baza de date,
ceea ce înseamnă că tranzacţ ia se poate termina; totuşi, este posibil să fie
necesare unele operaţ ii de verificare înainte de validarea (commit) tranzacţ iei.
● commit : terminarea cu succes a tranzacţ iei, validarea tuturor modificărilor
efectuate în baza de date şi vizibilitatea modificărilor efectuate pentru alte
tranzacţ ii; din acest moment, modificările efectuate nu mai pot fi anulate, nici
pierdute printr-o defectare ulterioar ă a sistemului
● rollback (sau abort ): semnifica faptul că tranzacţ ia a fost abandonată şi că orice
efect pe care tranzacţ ia l-a avut asupra bazei de date trebuie să fie anulat (printr-
o “rulare înapoi” a operaţ iilor).
● undo : operaţ ie similar ă operaţ iei rollback, dar se aplică unei singure operaţ ii, nu
unei întregi tranzacţ ii.
● redo : specifică faptul că unele operaţ ii ale unei tranzacţ ii trebuie să fie executate
din nou pentru a se putea valida întreaga tranzacţ ie.
 Ultimele două operaţ ii sunt necesare numai în anumite tehnici de refacere
Starile tranzactiilor
 Diagrama de stare a unei tranzactii:
read,
write
begin end PARTIAL commit

Ă VALIDAT Ă
ACTIV VALIDAT Ă
abort
abort
ABANDONAT Ă TERMINAT Ă
 Pentru refacerea bazei de date, sistemul SGBD menţ ine un fi şier jurnal (log
file), în care memorează operaţ iile efectuate de fiecare tranzacţ ie,
identificat ă printr-un identificator unic (T) generat de sistem
 Fişierul jurnal este memorat pe disc şi nu este afectat de erori de execuţ ie,
cu excepţ ia unei defectări catastrofice a discului
 Fişierul jurnal este salvat periodic pe un suport auxiliar (band ă magnetică)
Planificarea tranzactiilor
 O planificare (schedule, sau istorie - history ) S a n tranzacţ ii T1,T2,..Ti,...Tn
este o ordonare a operaţ iilor tranzacţ iilor astfel încât:
● Pentru orice tranzacţ ie Ti care participă în S, operaţ iile lui Ti în S respectă
ordinea iniţ ială din Ti
● Alte operaţ ii (ale altor tranzacţ ii Tj, unde j ≠ i) pot fi întreţ esute cu operaţ ii ale
tranzacţ iei Ti
 Două operaţ ii dintr-o planificare sunt conflictuale (conflicting operations)
dacă apar ţi n unor tranzacţ ii diferite, accesează acelaşi articol şi cel puţ in
7/14/2019
una dintre operaţ ii este operaţ ie de scriere Proiectare Baze de date.pdf
 Planific ări seriale (serial schedules): o planificare S se numeşte serială

dacă pentru orice tranzacţ ie T participantă în planificare, toate operaţ iile din
T se execută consecutiv în S; altfel, planificarea se numeşte neserială
 Orice planificare seriala a unor tranzactii corecte este corecta, dar nu
permite întreţ eserea operaţ iilor şi concurenţ a tranzacţ iilor

De aceea,
folosesc în cazul
ărilesistemelor
planific de, baze
serializabile de date
care admit cu utilizatori
concuren multipli se
ţ a, asigurând în
aceelaşi timp consistenţ a bazei de date

Planificar i seriale ale tranzactiilor
Planificarile SA si SB ale tranzactiilor T1 si T2 sunt seriale
T1 T2 T1 T2
read(X) read(X)
X=X-N X=X+M
write(X) write(X)
read(Y) read(X)
http://slidepdf.com/reader/full/proiectare-baze-de-datepdf SA SB 174/194
Y=Y+N X=X-N
7/14/2019 write(Y) write(X)
read(X) read(Y)
X=X+M Y=Y+N
write(X) write(Y)
 Daca notam operaţ iile de read, write, commit şi abort cu r, w, c, a, cu indice
numarul tranzacţ iei şi ca parametru articolul pe care l-a citit sau scris, atunci:
SA: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); c2;
SB: r2(X); w2(X); c2; r1(X); w1(X); r1(Y); w1(Y); c1;
 In SA, perechile de operaţ ii: (r1(X), w2(X)), ( r2(X), w1(X)) şi (w1(X), w2(X))
sunt conflictuale

Planificar i serializabile
serializabile ale tranzactiilor
O planificare a n tranzac ţ ii se numşte serializabil ă, dac ă este echivalent ă cu o
planificare serial ă a celor n tranzac ţ ii
 Două planificări sunt echivalente (din punct de vedere al conflictelor) dac ă
oricare pereche de operaţ ii conflictuale se execută în aceeaşi ordine în cele
două planificări
 Planificarile SC si SD sunt planificari echivalente cu SA, deci sunt serializabile
 Testarea echivalentei unei planificări cu o planificare seriala este costisitoare,
dar se poate asigura serializabilitatea prin controlul concurenţ ei tranzacţ iilor
T1 T2 T1 T2
read(X) read(X)
X=X-N X=X-N
write(X) write(X)
read(X) SC read(Y) SD
X=X+M read(X)
write(X) X=X+M
read(Y) Y=Y+N
Y=Y+N write(Y)
write(Y) write(X)
Tehnici de control al concurentei

 Pentru a asigura proprietăţ ile ACID ale tranzacţ iilor şi, prin aceasta, consistenţ a
datelor, este necesar controlul execuţ iei concurente a tranzacţ iilor
 Cele mai utilizate tehnici de control al concuren ţ ei sunt:
● Tehnici bazate pe blocarea accesului la date prin zăvoare (locks)
● Tehnici bazate pe mărci de timp (timestamps)
 Protocoalele de control al concurenţ ei sunt implementate de SGBD-uri:
● programatorii de aplicaţ ii nu operează explicit cu zăvoare sau mărci de timp
● ei stabilesc opţ iunile prin care sistemul SGBD adoptă anumite tehnici de control
 Un zăvor (lock ) este o variabilă L(X) asociată cu un articol X al bazei de date
care descrie starea acelui articol în raport cu opera ţ iile care i se pot aplica
 Tipuri de zavoare utilizate in SGBD-uri:
● zăvoare binare
● zăvoare cu stări multiple
 Un z ăvor binar (binary lock ) poate avea două stări: liber (sau neblocat - free,
unlocked ) şi ocupat (sau blocat - busy , locked ) sau, mai simplu, stările 1 şi 0
 Asupra unui zăvor binar L(X)se pot executa două operaţ ii:
● operaţ ia de blocare, lock(X)
● operaţ ia de eliberare, unlock(X)
Zavoare binare
 Dacă zăvorul articolului X este liber (L(X)=1), atunci tranzactia:
● achiziţ ionează zăvorul (trecându-l în starea ocupat prin operatia lock )
● execută operaţ iile necesare asupra articolului X
● eliberează zăvorul, prin operaţ ia unlock
 Dacă zăvorul articolului X este ocupat (L(X)=0), atunci tranzacţ ia:
● aşteaptă până ce acesta este eliberat (de o altă tranzacţ ie, care şi-a terminat
operaţ iile de acces la acel articol),
● după care execută aceeaşi secvenţă de operaţ ii: blocarea zăvorului, execuţ ia
7/14/2019 operaţ iilor care accesează articolul respectiv
Proiectare şi eliberarea zăvorului
Baze de date.pdf
 Operaţ ia de blocare se executată ca operaţ ie indivizibilă (folosind

instrucţ iuni speciale de tip TestAndSet)
 Regulile pe care trebuie să le respecte fiecare tranzacţ ie care foloseşte un
zăvor binar:
1. O tranzacţ ie trebuie să blocheze zăvorul articolului X (prin operatia lock(X)),
înainte de a efectua orice operaţ ie de citire sau de scriere a articolului X
2. dup ă ce aţ iefectuat
O tranzac să elibereze
e trebuietoate operaţ iilezăde
vorul unui
citire sauarticol X (prin
de scriere operaţ ia unlock(X))
a articolului X
3. O tranzacţ ie nu poate cere un zăvor pe care îl deţ ine deja
4. O tranzacţ ie nu poate elibera un zăvor pe care nu îl deţ ine
Zavoare cu stari multiple (1)

 Tehnica zăvoarelor binare este prea restrictivă şi limitează în mod nejustificat
concurenţ a în execuţ ia tranzacţ iilor
 De exemplu, mai multe tranzacţ ii pot efectua operaţ ii de citire în mod
concurent, f ăr ă ca acest lucru să afecteze consistenţ a bazei de date, dar
acest lucru este interzis în tehnica zăvoarelor binare
 De aceea, multe sisteme de gestiune a bazelor de date utilizează si zăvoare
cu stări multiple
 Un z ăvor cu st ări multiple (multiple mode lock ) poate fi într-una din
7/14/2019
următoarele trei stări: Proiectare Baze de date.pdf
● liber (neblocat, unlocked ): zăvorul nu este deţ inut de nici o tranzacţ ie şi prima

tranzacţ ie care lansează o operaţ ie de blocare îl poate obţ ine
● blocat pentru citire (read-locked ):oricâte tranzacţ ii pot deţ ine zăvorul respectiv şi
pot efectua operaţ ii de citire a articolului protejat de acesta, dar nici o tranzacţ ie nu
poate scrie în acel articol
● blocat pentru scriere (write-locked ): o singur ă tranzacţ ie poate deţ ine zăvorul şi
poate citi sau scrie în articolul protejat de acesta, nici o altă tranzacţ ie neputând
accesa articolul respectiv, nici pentru scriere nici pentru citire
■ Operatiile de blocare pentru citire, blocare pentru scriere si deblocare a unui
zavor multiplu al articolului X se noteaza: read_lock(X), write_lock(X) si
unlock(X)
Zavoare cu stari multiple (2)

 Orice tranzacţ ie care utilizează un zăvor cu stări multiple trebuie să
respecte următoarele reguli:
1. O tranzacţ ie trebuie să execute o operaţ ie de blocare partajată sau exclusivă a
ăvorului articolului X (read_lock(X) sau write_lock(X)) înainte de a efectua orice
zopera ţ ie de citire a articolului X
2. O tranzacţ ie trebuie să execute o operaţ ie de blocare exclusivă a zăvorului
articolului X (write_lock(X)) înainte de a efectua orice operaţ ie de scriere a lui X
3. O tranzacţ ie trebuie să elibereze zăvorul unui articol X (unlock(X)) după ce a
ţ ţ
efectuat toate operaţ iile de citire sau de scriere a articolului X; operaţ ia de
7/14/2019 eliberare a unui zăvor poate fi executata
Proiectare Baze numai
de date.pdf de o tranzactia care de ţ ine (în
mod exclusiv sau partajat) acel zavor

4. O tranzacţ ie nu poate executa o operaţ ie read_lock(X) dacă deţ ine deja, în mod
partajat sau exclusiv, zăvorul articolului X; această cerinţă poate fi slăbită
(relaxata) astfel: o tranzacţ ie care deţ ine un zăvor partajat pentru articolul X
poate să întărească (upgrade) această deţ inere la o deţ inere exclusivă prin
operaţ ia write_lock(X)
5. O tranzacţ ie nu poate lansa o operaţ ie write_lock(X) dacă deţ ine deja, în mod
partajat sau exclusiv, zăvorul articolului X; la fel ca şi cerinţ a precedentă,
această cerinţă poate fi slăbită astfel:o tranzacţ ie care deţ ine un zăvor exclusiv
pentru articolul X poate să slăbească (downgrade) această deţ inere la o deţ inere
partajată prin operaţ ia read_lock(X)
 Fie tranzactiile Blocarea folosind

T3,T4, o planificarea seriala (a)zavoare
si planificarile neseriale (b) si (c)
● Daca se foloseste un singur zavor 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 T4 T3 T4 read_lock(Y)
read(Y) write_lock(XY) read(Y)
read(X) read(Y) unlock(Y)
X=X+Y read(X) read lock(X)
7/14/2019 write(X) write_lock(XY)
Proiectare Baze de date.pdf read(X)
(a) (b) (c)
read(X) X=X+Y T4 blocata unlock(X)
read(Y) write(X) write_lock(Y)
Y=X+Y unlock(XY) read(Y)

write(Y) read(X) Y=X+Y
read(Y) write(Y)
Y=X+Y unlock(Y)
write(Y) write_lock(X)
unlock(XY) read(X)
 Fie: X=20, Y=30:
X=X+Y
● planificarile (a) si (b): rezultat corect (X=50, Y=80)
● planificarea neseriala(c): rezultat eronat (X=50,Y=50) write(X)
unlock(X)
 Protocolul
Pentru de blocare
a asigura serializabilitatea planificăin
rilordoua faze
tranzactiilor care(1)
folosesc mai
multe zavoare, pe lângă regulile de utilizare a zăvoarelor, mai este necesar
să se respecte un protocol privind ordinea operatiilor de blocare şi de
eliberare a zăvoarelor, 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 opera ţ iile de
blocare a zăvoarelor sa preceada prima operaţ ie de eliberare a unui zăvor
 O astfel de tranzacţ ie poate fi divizată în două faze:
● faza de creştere (growing phase), în care pot fi achizi ţ ionate noi zăvoare ale
ă
articolelor care vor fi accesate, dar nici un z vor nu poate fi eliberat
7/14/2019 ● faza de descreştere (shrinking phase ),Baze
Proiectare în decare zăvoarele deţ inute pot fi eliberate,
date.pdf
dar nici un alt zăvor nu mai poate fi achiziţ ionat.
 S-a demonstrat că, dacă fiecare tranzacţ ie a unei planificări respectă
protocolul de blocare în două faze, atunci planificarea este serializabilă
 Planificarea tranzacţ iilor din figura precedenta (c) nu respectă protocolul de
blocare în două faze deoarece:
● T3 eliberează zăvorul articolului Y înaintea achiziţ ionării zăvorului pentru scrierea
articolului X (write_ lock(X))
● articolului
T4 elibereaz ă zăvorul articolului X înaintea achiziţ ionării zăvorului pentru scrierea
Y (write_lock(Y))
 Aceasta planificare este neserializabilă, cu rezultat al execuţ iei incorect, aşa
cum s-a ar ătat mai înainte
Protocolul de blocare in doua faze (2)

 Planificarea din figura alaturata este T3 T4
serializabilă, echivalentă cu planificarea serială
T3, T4 (cu rezultat corect X=50, Y=80) read_lock(Y)
 Daca T3 lansează operaţ ia de blocare a read(Y)

zăvorului articolului X înaintea tranzacţ iei T4, write_lock(X)
tranzacţ ia T4 este blocata, asteptând read_lock(X)
eliberarea zăvorului articolului X, după care
efectueaza restul operaţ iilor unlock(Y) T4 blocata
read(X)
 Probleme care apar la utilizarea zăvoarelor:
7/14/2019
● impasul (deadlock ): blocarea execu ţ iei
Proiectare Baze de date.pdf X=X+Y
tranzacţ iilor atunci când două sau mai multe write(X)
tranzacţ ii se aşteaptă una pe cealălaltă ca să
elibereze un zăvor; exista tehnici de prevenire si unlock(X)
de eliminare a impasului read(X)

● amânarea permanent ă (“înfometare”) - write_lock(Y)
(livelock, indefinit postponement, starvation): o
tranzacţ ie se află în stare de amânare nedefinită unlock(X)
dacă ea nu poate continua execuţ ia o perioadă Y=X+Y
lung ă de timp, în timp ce toate celelalte write(Y)
tranzac ţ ii se execută normal; prevenirea se face
prin asigurarea unei politici echilibrate de unlock(Y)
obtinere (blocare) a zavoarelor
Controlul concurentei bazat pe marci de timp

 O marc ă de timp (timestamp) este un identificator unic al unei tranzacţ ii,
creat de sistemul de gestiune a bazei de date, care se bazează pe timpul de
start al tranzacţ iei
 O marcă de timp se poate crea:
● fie folosind valoarea curentă a ceasului sistemului de operare
● fie folosind un număr ător care este incrementat la fiecare asignare a unei noi
mărci, în ordinea de lansare a tranzacţ iilor
7/14/2019
 O tranzacţ ie T va avea o marcă de timp unică, notată TS(T)
 Pentru fiecare articol X al bazei de date se definesc două mărci de timp:

● read_TS(X) - marca de timp de citire a articolului X; este cea mai mare marcă de
timp dintre toate mărcile de timp ale tranzacţ iilor care au citit articolul X
● write_TS(X) - marca de timp de scriere a articolului X; este cea mai mare marcă
de timp dintre toate mărcile de timp ale tranzacţ iilor care au scris în articolul X
 Serializabilitatea planificărilor se obţ ine dacă se impun anumite condiţ ii
ordinii de accesare a articolelor de mai multe tranzacţ ii concurente, în funcţ ie
de mărcile de timp ale acestora
Ordonarea
■ La operatiilor
lansarea unei opera ţ ii de scriere a dupa
articoluluimarci le de
X (write(X)): timp
● Dacă read_TS(X) > TS(T), atunci tranzacţ ia T trebuie să fie abandonată şi rulată
înapoi, deoarece o altă tranzacţ ie 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ă write_TS(X) > TS(T), atunci tranzac ţ ia T nu va executa operaţ ia de scriere,
dar va putea continua cu celelalte operaţ ii. Aceasta, deoarece o altă tranzacţ ie, 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 apărut nici una din situaţ iile precedente, atunci T va executa operaţ ia
de scriere în articolul X şi va seta write_TS(X)=TS(T).
7/14/2019 ■ La lansarea unei operaţ ii de citire aProiectare
articolului X (read(X)):
Baze de date.pdf
● Dacă write_TS(X) > TS(T), atunci tranzac ţ ia T trebuie să fie abandonată şi rulată
înapoi, deoarece o altă tranzacţ ie 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ă write_TS(X) <= TS(T), atunci T va executa operaţ ia de citire din articolul X şi
va seta marca read_TS(X) la cea mai mare dintre valorile TS(T) şi read_TS(X).
■ Ulterior, o tranzacţ ie T care a fost anulată şi rulată înapoi va fi relansată, dar
cu o nouă marcă de timp, corespunzătoare noului moment de lansare
■ Ordonarea după mărcile de timp garantează serializabilitatea planificărilor
■ In acest protocol nu poate sa apara impasul, dar poate apare amânarea
indefinită
 Tehnicile de gestiune Controlul tranzactiilor

a tranzacţ iilor şi de refacere a datelor sunt incluse în
SGBD-uri, iar aplicaţ iile de baze de date au un control limitat asupra
tranzacţ iilor prin intermediul unor comenzi SQL

Comenzi SQL pentru tranzac
● SET TRANSACTION: setareţ ioptiuni
i: :
Nivelul de izolare a tranzacţ iilor (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
Nivel de izolare Citire Citire Citire

Pentru orice nivel de izolare
(ISOLATION LEVEL) este impropie nerepetabila fantoma
READ DA DA DA
prevenita pierderea actualizarilor, UNCOMMITTED
dar se admit unele citiri incorecte,
READ NU DA DA
asa cum se vede in tabel COMMITTED
REPEATABLE NU NU DA
READ
SERIALIZABLE NU NU NU
Exemplu de tranzacti e 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:
7/14/2019 ■ 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)
Exemplu de tranzacti e 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 autoc ommit = 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
7/14/2019
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;
ELSE SET rezultat

BEGIN = 1; END;SET rezultat = 0; END; END IF;
ROLLBACK;
END $$
DELIMITER ;
Proiectarea tranzactiilor
■ Tranzacţ iile sunt corecte dacă lasă baza de date într-o stare consistentă
■ Tranzacţ iile sunt cu atât mai eficiente cu cât sunt mai scurte (ca timp de
execu ţ ie şi ca număr de articole ale bazei de date accesate) deoarece astfel:
● se limiteaza frecvenţ a de apariţ ie a impasului (în cazul folosirii zăvoarelor)
● creste eficienţ ei operaţ iilor de anulare şi de blocare a resurselor
■ Ori de câte ori se poate înlocui o tranzac ţ ie complexă, cu număr mare de
operaţ ii şi timp de execuţ ie ridicat, cu mai multe tranzacţ ii scurte, este indicat
să se facă această transformare
■ De asemenea, pentru menţ inerea tranzacţ iilor cât mai scurte posibil, se
recomandă ca o tranzacţ ie să nu fie pornită până ce nu au fost pregătite toate
datele (citirea datelor de intrare, parcurgerea, analiza şi prelucrarea acestora)
■ Toate operaţ iile de gestiune a tranzacţ iilor şi de refacere a datelor sunt
prevăzute în diferitele componente ale sistemelor SGBD (administratorul de
tranzacţ ii, administratorul de refacere), iar aplica ţ iile:
● trebuie să se prevadă tranzacţ ii corecte
● pot selecta diferite opţ iuni de control al tranzacţ iilor şi de refacere a datelor oferite
de sistemul de gestiune respectiv

Tehnici
Refacerea dederefacere
unei baze a bazelor
date după producerea de (date
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 cât mai
apropiată de momentul apariţ iei defectului
 Tehnicile de refacere a bazelor de date sunt, în general, integrate cu tehnicile
de control al concurenţ ei si depind de SGBD
 Pentru operaţ iile de refacere se foloseşte fişierul 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 tranzacţ ie care
7/14/2019
a executat cu succes toate operaţ Proiectare
iile sale şi le-a înregistrat în fişierul jurnal
Baze de date.pdf
● Într-un astfel de punct, o tranzacţ ie T înscrie în fişierul jurnal operaţ ia [commit,T]

şi, de asemenea, trebuie să scrie blocul din bufferul de scriere în fişierul jurnal
 Un punct de control (checkpoint ) este înscris în fişierul jurnal atunci când se
scriu în fişierele bazei de date toate rezultatele operaţ iilor de scriere ale
tranzacţ iilor validate
● Aceasta înseamnă că toate tranzacţ iile care au înregistrarea [commit,T] înscrisă în
fişierul jurnal
scriere înaintea
în cazul unui ăpunct
unei defect de control nu vor necesita reluarea operaţ iilor de
ri a sistemului
 Administratorul de refacere al SGBD-ului (recovery manager ) decide la ce
interval de timp (sau după câte tranzacţ ii) introduce un nou punct de control
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 modificărilor care au produs inconsistenţ a (prin operaţ ii undo)
● executarea din nou a modificărilor care s-au pierdut (prin operaţ ii redo)
 În acest caz nu este necesar ă copia de rezervă, ci se foloseşte starea actuală
a bazei de date şi fişierul jurnal
 Exista două tehnici de refacere a datelor dupa defecte necatastrofice:
● Refacerea cu actualizare amânată (deferred update)
● Refacerea cu actualizare imediată (immediate update)
7/14/2019
■ Pentru refacerea cu actualizare amanata se executa urmatoarele operatii:
● Se parcurge fişierul jurnal în sens invers, începând de la ultima înregistrare, până

se întâlneşte primul punct de control
● Se construieste o listă a tranzacţ iilor validate, în care se introduc toate tranzacţ iile
T care au o înregistrare de tipul [commit,T] în fişierul jurnal între punctul de control
considerat şi sfâr şitul fişierului jurnal,
● Se construieste o listă a tranzacţ iilor nevalidate, în care se introduc toate
tranzacţ iile T’ care au o înregistrare de start ([begin,T’]) în fişierul jurnal, dar nu au
şi înregistrarea corespunzătoare de validare.
● Dup ă aceasta, se execută reluarea (REDO) tuturor operaţ iilor de scriere (write(X))
ale tranzacţ iilor validate, în ordinea în care apar în fişierul jurnal, iar tranzacţ iile
nevalidate sunt relansate
Refacerea cu actualizare imediata

 In tehnicile de refacere cu actualizare imediată, atunci când o tranzacţ ie
lansează o comandă de actualizare a bazei de date, actualizarea este
efectuată imediat, f ăr ă să se mai aştepte ajungerea la un punct de validare
 In majoritatea acestor tehnici se impune ca modificarea să fie mai întâi
memorată în fişierul jurnal (pe disc), înainte de a fi aplicat ă bazei de date;
această regulă este cunoscută sub numele de “protocol de scriere în avans
a fişierului jurnal” (write-ahead log protocol )
 Dacă se admite actualizarea imediată, atunci la refacere trebuie să se poată
7/14/2019
anula (prin operaţ ii undo) modificările efectuate de o tranzacţ ie, dacă
aceasta eşuează ulterior din diferite motive

 In felul acesta se efectueaza rularea înapoi (rollback) a tranzacţ iei
 Tehnica de refacere cu actualizare imediată are avantajul simplităţ ii
operaţ iilor de scriere, care se efectuează direct în baza de date, f ăr ă să fie
necesar să se aştepte atingerea unui punct de validare pentru transferarea
datelor în baza de date
 Dezavantajul acestei metode este faptul că pot apare anulări în cascadă,
care necesită operaţ ii complicate de refacere
Refacerea datelor dupa defecte catastrofice

 Dacă baza de date a fost puternic distrusă datorită unei defectări 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
 Totuşi, tranzacţ iile efectuate de la ultima operaţ ie de salvare până în
momentul apariţ iei defectului se pierd
 Deoarece fişierul jurnal este mult mai mic decât fişierele bazei de date, se
7/14/2019
obişnuieşte ca acesta să fie salvat mai des decât baza de date însăşi şi să
fie iniţ ializat la fiecare operaţ ie de salvare a bazei de date

 In această situaţ ie, după încărcarea ultimei copii salvate a bazei de date se
foloseşte fişierul jurnal pentru a reface toate tranzacţ iile validate existente în
copia salvată a fişierului jurnal (care este mai recentă decât copia salvată a
bazei de date)

Proiectare Baze de Datepdf

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proiectare Baze de Datepdf

Încărcat de

Drepturi de autor:

Formate disponibile

7/14/2019 Proiectare Baze de date.

Proiectarea Bazelor de Date

Facultatea de Electronica, Telecomunicatii

Prof. Felicia Ionescu

 Arhitectura interna a sistemelor de baze de date

 Avantajele oferite de sistemele de baze de date

● Clasificare dupa numarul de utilizatori

Baze de date, 2008 Prof. Felicia Ionescu 2

Sisteme de baze de date

Componentele unui Sistem de Baze de Date (1)

 Un sistem de baze de date (Database System) este un sistem

Baze de date, 2008 Prof. Felicia Ionescu 4

Componentele unui Sistem de Baze de Date (2)

Arhitectura interna a unui Sistem de BD

Nivelul conceptual Schema conceptuală

Nivelul intern Schema internă

Baze de date, 2008 Prof. Felicia Ionescu 6

Avantaje oferite de Sistemele de BD

 Compactitate ridicată a datelor

 Viteza mare de actualizare si regasire a datelor

Baze de date, 2008 Prof. Felicia Ionescu 7

Clasificarea Sistemelor de Baze de Date (1)

 Clasificare dupa modelul de date:

● Client (front-end): program (programe) de aplicatie

Aplicaţie Aplicaţie Aplicaţie Aplicaţie

Aplicaţie Aplicaţie Aplicaţie

Sistem de baze de date distribuit

● Modele specializate (modelul ierarhic, modelul reţea, modelul relaţional, etc.) -

 Modelul Entitate-Asociere (Entity-Relationship Model ) defineste multimile

 Un entităţi(attribute) este o proprietate care descrie un anumit aspect al

 O asociere (relationship) este o corespondenţă între entităţi din două sau

“unul-la-unul” – 1:1 “unul-la-multe”- 1:N

Asocieri binare intre multimile de entitati A si B

Baze de date, 2008 Prof. Felicia Ionescu 13

“multe-la-unul”- N:1 “multe-la-multe”- M:N

Asocieri binare intre multimile de entitati A si B

 Cardinalitatea (multiplicitatea) unei asocieri faţă de o mulţime de entităţi

1 ţă ţimea A şi multiplicitatea N (se înţelege o valoare oarecare N > 1)

Baze de date, 2008 Prof. Felicia Ionescu 15

 Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezintă

Tip entitate Tip de entitate puternică

Tip entitate Tip de entitate slabă

A B Asociere binar ă 1:N

Baze de date, 2008 Prof. Felicia Ionescu 16

 Multimi de entitati puternice:

Număr Buget Nume Salariu

Nume GradRudenie Denumire Buget

Baze de date, 2008 Prof. Felicia Ionescu 17

 Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model )

SECRETARA TEHNICIAN INGINER

VitezaRedactare Calificare Specialitate

Baze de date, 2008 Prof. Felicia Ionescu 19

 Modelul ierarhic (Hierarchical Model ): baza de date se reprezinta printr-o

Baze de date, 2008 Prof. Felicia Ionescu 20

(a) Diagrama E-A (b) Schema ierarhica (c) Arbori de instantiare

 Modelul reţ ea (Network Model ) foloseşte o structur ă de graf pentru

Baze de date, 2008 Prof. Felicia Ionescu 22

 Modelul relaţ ional (Relational Model ) se bazează pe noţiunea de relaţ ie

Baze de date, 2008 Prof. Felicia Ionescu 23

 Modelul obiect (Object Model ) este un concept unificator

(Semantic Information Manager).

 Utilizare SGBDOO: cam 5% din sistemele de gestiune actuale

 Modelul obiect-relaţ ional (Object-Relational Model ) reprezintă extinderea