CAPITOLUL 1.

CONCEPTE PRIVIND BAZELE DE DATE ŞI

SISTEMUL DE GESTIUNE AL BAZELOR DE DATE

1.1. Conceptul de bază de date

Utilizarea calculatoarelor electronice în activitatea practică din organizaţii impune elaborarea

unor sisteme informatice în conformitate cu cerinţele solicitate de utilizatorii lor. Aplicaţiile
informatice din domeniul economic au de regulă un volum relativ mare de date, care se
organizează cel mai bine în baze de date. De altfel, există o părere unanimă a specialiştilor că
bazele de date reprezintă unul dintre cele mai moderne şi mai eficiente mijloace de stocare şi
gestiune modernă a datelor referitoare la un anumit domeniu particular (de exemplu: evidenţa
resurselor umane, evidenţa livrărilor de mărfuri, evidenţa mijloacelor fixe etc.).
Baza de date poate fi definită ca o colecţie de date, referitoare la un domeniu de activitate
particular, în care proprietăţile datelor precum şi relaţiile semantice dintre date sunt specificate
utilizând concepte propuse de un anumit model. Un model se poate defini ca o reprezentare
abstractă a informaţiei şi, eventual, a operatorilor pentru manipularea informaţiei. Conceptul de
model de date este esenţial, opţiunea pentru o anume bază de date fiind făcută pornind de la
modelul care va sta la baza ei.
În literatura de specialitate există mai multe definiţii date bazei de date, fiecare definiţie
evidenţiind anumite elemente, astfel:
 C. Delobel a definit baza de date drept un „ansamblu structurat de date înregistrate pe
suporturi accesibile calculatorului pentru a satisface simultan mai mulţi utilizatori de o
manieră selectivă şi într-un timp oportun”.
 G. Gardarin precizează: „pentru ca un ansamblu de date independente să fie o bază de
date, trebuie să fie interogabile prin conţinut, după orice criteriu precum şi să fie posibilă
regăsirea structurii datelor”.
În timp au fost definite mai multe modele de date care au reprezentat punctul de pornire în
organizarea bazelor de date. Amintim următoarele modele:
- modelul ierarhic;
- modelul reţea;
- modelul relaţional;
- modelul relaţional-obiectual;
- modelul orientat obiect.
Aceste modele au o serie de particularităţi, aşa cum rezultă din figura 1.1.
 Model ierarhic Model reţea

Se particularizează prin reprezentarea Este o extensie a modelului ierarhic.

datelor sub formă arborescentă Prezintă în plus conexiunea dintre
descendentă. Una dintre caracteristici elemente (legături transversale).
este imposibilitatea de a separa nivelul
logic de cel fizic.
Model relaţional Model orientat obiect

Reprezentarea datelor se realizează prin Reprezentarea datelor se face sub formă

tabele având două coordonate: linii şi de obiecte. Un obiect încorporează atât
coloane. Fiecare tabel descrie o entitate date cât şi comportamente (prelucrări).
din lumea reală. Modelul permite
reprezentarea asocierilor dintre aceste
entităţi.
Figura 1.1 Particularităţile modelelor de date
Grupul de normalizare ANSI/X3/SPARC a stabilit trei niveluri de descriere a datelor în cazul
unei baze de date:
 Nivelul extern – care descrie viziunea particulară (view) a unui utilizator sau grup de
utilizatori asupra bazei de date (este vorba de acea parte a bazei de date pentru care
utilizatorul are acces). În consecinţă, pot fi definite mai multe scheme externe fiecare
reprezentând un subansamblu de date accesibile unui utilizator;
 Nivelul conceptual - corespunde unei structurări semantice a datelor descriind lumea
reală, fără a lua în considerare restricţii specifice implementării bazei de date pe un
anumit calculator. Cu alte cuvinte, corespunde unei viziuni a datelor independente de
aplicaţiile individuale şi de modul în care datele sunt stocate;
 Nivelul fizic (intern) care corespunde unei structuri de stocare a datelor pe suporturi
(organizare şi mod de acces fizic). Acest nivel este responsabil de organizarea fizică a
fişierelor la nivelul memoriei externe precum şi de utilizarea unei metode de acces la
date cât mai eficiente.
Pentru o bază de date se pot defini mai multe niveluri (scheme) externe, un nivel conceptual şi un
nivel fizic (intern).
Fiecare nivel de abstractizare este protejat la modificările în structura din nivelul inferior.
Nivelurile de abstractizare menţionate asigură independenţa datelor, autorizează manipularea
datelor, garantează integritatea datelor şi optimizează accesul la date.
Independenţa datelor poate fi:
- independenţă logică - care protejează modificările în structura logică de date;
- independenţă fizică - care protejează modificările în structura fizică de date.
Asigurarea independenţei datelor este unul dintre beneficiile importante aduse de sistemele de
gestiune a bazelor de date.
Utilizatorii unei baze de date pot fi:
- Utilizatorii finali – toate persoanele care au acces doar la interfaţa oferită de SGBD şi/sau
execută aplicaţii;
- Programatorii de aplicaţii - specialiştii care proiectează şi realizează aplicaţiile ce
interacţionează cu SGBD-ul;
- Administratorul bazei de date - este un utilizator privilegiat care:
 Cunoaşte schemele logice/fizice;
 Răspunde de problemele de securitate ale bazei de date, stabileşte şi acordă
autorizările privind accesul şi drepturile utilizatorilor în baza de date;
 Asigură disponibilitatea datelor şi, la nevoie, recuperarea datelor;
 Monitorizează parametrii bazei de date şi adaptează baza de date în funcţie de
cerinţele nou apărute.
1.2. Sistemul de Gestiune al Bazei de Date

Gestiunea şi accesul la baza de date sunt asigurate de un ansamblu de programe care formează
sistemul de gestiune al bazei de date (SGBD).
Sistemul de gestiune al bazei de date se defineşte ca un instrument de asamblare, codificare,
aranjare, protecţie şi regăsire a datelor în bazele de date. In acelaşi timp, SGBD mai poate fi
definit ca un ansamblu de programe speciale cu ajutorul cărora se creează, actualizează,
interoghează şi protejează o bază de date.
Principalele avantaje oferite de SGBD pot fi sintetizate astfel:
- independenţa datelor: aplicaţiile nu sunt afectate de detalii, şi implicit modificările,
de reprezentare şi stocare a datelor;
- coerenţa datelor prin implementarea unor reguli explicite sau implicite (restricţii de
integritate) pe care datele trebuie să le respecte de-a lungul evoluţiei lor;
- asigurarea gestiunii tranzacţiilor: o tranzacţie este o secvenţă atomică de acţiuni
asupra bazei de date (citire/scriere). O tranzacţie executată asigură aducerea bazei
de date într-o stare consistentă. După orice modificare în baza de date sunt
verificate toate regulile de coerenţă asupra tuturor datelor;
- asigurarea confidenţialităţii datelor: fiecare utilizator cu drept de acces la baza de
date are definite anumite drepturi;
- limitarea redundanţei datelor (dublarea memorării unor date este controlată);
- acces eficient la date: SGBD-ul utilizează metode sofisticate de stocare şi acces la
date asigurând optimizarea accesului la date;
- integritatea şi securitatea datelor asigurate prin implementarea restricţiilor de
integritate şi a controalelor de acces la date;
- acces concurent la date;
- stochează un volum mare de date;
- oferă facilităţi de gestiune a meta-datelor prin intermediul dicţionarului de date1.
Meta-datele privesc datele referitoare la: schema bazei de date (în cazul SGBD-
urilor relaţionale spre exemplu privesc relaţii, atribute, restricţii, view-uri), view-
uri, utilizatori (identificarea şi drepturile utilizatorilor) şi sistemul în ansamblu
(informaţii statistice);
- timp redus pentru realizarea aplicaţiilor;
- administrarea uniformă a datelor asigurată de către administratorul bazei de date;
- recuperarea şi restaurarea datelor: SGBD-ul oferă facilităţi de restaurare a bazei de
date în cazul afectării parţiale sau totale a conţinutului acesteia.
SGBD-ul trebuie să asigure două funcţii de bază şi anume: descrierea bazei de date şi
manipularea bazei de date. Descrierea bazei de date se realizează prin intermediul limbajului de
1
Meta-datele pot fi definite ca date care descriu date. Tot ceea ce descrie baza de date, prin opoziţie cu conţinutul
bazei de date, sunt meta-date. Spre exemplu: nume de coloane, nume de utilizatori etc.
descriere a datelor (LDD). Manipularea bazei de date se realizează prin intermediul limbajului
de manipulare a datelor (LMD) care dispune de două componente: limbajul de interogare şi
limbajul de actualizare a bazei de date.

1.3. Modelul relaţional

Modelul relaţional a fost elaborat de E. F. Codd în 1970. Este un model simplu şi intuitiv bazat
pe o viziune tabelară asupra datelor. Întregul model relaţional are la bază teoria matematică a
relaţiilor şi algebra relaţională.
În cele ce urmează se prezentă în sinteză principalele concepte specifice modelului relaţional.
O relaţie (tabel) este un subansamblu al produsului cartezian de n domenii (un domeniu este un
ansamblu de valori) conform următoarei formule:

R (D1 x D2 x D3 x … x Dn)

Exemplu:
Entităţii din lumea reală numită PRODUSE îi va corespunde relaţia (tabelul) PRODUSE
definită prin produsul cartezian al domeniilor, CODPRODUS, DENUMIREPRODUS, UM,
PRET,
adică:
CODPRODUS x DENUMIREPRODUS x UM x PRET
Relaţia este reprezentată sub forma unui tablou dezvoltat pe linii şi coloane (de unde şi
denumirea de tabel). Relaţia este formată dintr-un ansamblu de n-tupluri. Fiecare tuplu
reprezintă un rând în cadrul tabelului. Fiecare coloană corespunde unui atribut, descriind o
caracteristică a entităţii din lumea reală, aşa cum rezultă din figura 1.2.
Atribute

PRODUSE
COD PRODUS DENUMIRE UM PRET
PRODUS
100 P1 Buc 4
300 P2 Kg 6,5
200 P3 Mc 7
150 P4 Buc 1,5
700 P5 Kg 2

domeniu tuplu
Figura 1.2. Structura relaţiei PRODUSE
Conform modelului relaţional, în cadrul unei relaţii se utilizează următoarele concepte:
Atributul (câmpul) – o variabilă care ia valori într-un anumit domeniu. Aceste valori corespund
unor caracteristici ale lumii reale.
Tuplul – totalitatea valorilor atributelor de pe o linie dintr-un tabel. Tuplul se mai numeşte şi
înregistrare.
Cardinalitatea relaţiei este egală cu numărul de linii sau tupluri conţinute de un tabel.
Cheia primară - câmpul (grupul de câmpuri) cu valori unice şi nenule ce serveşte la
identificarea înregistrărilor unui tabel. Orice relaţie (tabel) are o cheie primară. În exemplul
prezentat în figura 1.2., cheia primară este atributul COD PRODUS.
Cheia candidat - un câmp (altul decât cheia primară) ce îndeplineşte condiţiile necesare cheii
primare. Dintre cheile candidate se va alege, de fapt, cheia primară.
Cheia externă - câmpul (grup de câmpuri) ce serveşte la realizarea legăturii cu alt tabel în care
acesta este cheie primară. Valorile asociate atributului cu rol de cheie externă pot fi duplicate sau
nule.
Exemplu: Se consideră o bază de date formată din tabelele Furnizori şi Facturi, a căror structură
este reprezentată în modelul de mai jos:

Furnizori (CodFz, NumeFz, Localitate, Telefon, ContBancar)

cheia primară cheia candidat

Facturi (NrFact, DataFact, DataScad, CodFz)

cheia primară cheie externă

Figura 1.3. Reprezentarea modelului relaţional detaliat

La baza definirii legăturilor dintre tabele stă conceptul de restricţie de integritate referenţială
(Referential Integrity), care presupune că valorile unei chei externe trebuie să se regăseacă
printre valorile cheii primare corespondente sau să fie nule. Aşa cum se poate observa în
exemplul anterior (figura 1.3) între relaţiile Furnizori şi Facturi s-a definit o legătură pe baza
câmpului comun CodFz cu implementarea conceptului de restricţie de integritate referenţială
(valorile atributului cu rol de cheie externă CodFz din tabelul Facturi se regăsesc în domeniul
cheii primare corespondente CodFz din tabelul Furnizori).

Elemente de algebră relaţională

Algebra relaţională oferă un ansamblu de operatori permiţând operarea asupra conceptelor
modelului relaţional. Rezultatul obţinut prin utilizarea operatorilor algebrei relaţionale este un
tabel virtual. Având în vedere fundamentele matematice ale modelului relaţional, algebra
relaţională utilizează operatori clasici de manipulare a ansamblurilor de date (reuniune,
intersecţie, diferenţă, produs cartezian) şi introduce operatori proprii bazelor de date (selecţie,
proiecţie, compunere, diviziune).
Operatorii algebrei relaţionale se definesc şi utilizează după cum urmează:
a) Operatori de asamblare
 Reuniunea

Operatorul de reuniune crează un nou tabel T plecând de la două tabele R (conţinând m tupluri)
şi S (conţinând n tupluri) prezentând aceeaşi structură. Rezultatul, tabelul T prezintă aceeaşi
structură cu a tabelelor sursă dar conţine m+n tupluri:
T= R U S
Tabelul Studenţi (R)
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

Tabelul Transferări (S)

Matricola Nume Media
230 Pop Geta 9,15
190 Marin Dana 8,25

Tabelul FinalStudenţi (T= R U S)

Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25
230 Pop Geta 9,15
190 Marin Dana 8,25

 Intersecţia

Intersecţia a două tabele R şi S (R ∩ S) prezentând aceeaşi structură, unde R prezintă m tupluri

iar S prezintă n tupluri generează relaţia T (cu aceeaşi structură) conţinând tuplurile identice din
R şi S.

T= (R ∩ S)
Tabelul Bursieri (R)
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25
112 Toma Ene 8,80

Tabelul Căminişti (S)

Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25
130 Ionescu Angela 8,15
127 Manea Ion 8,30

Tabelul BursieriCăminişti (T= R ∩ S)

Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

 Diferenţa

Diferenţa a două tabele (relaţii) R şi S prezentând aceeaşi structură conduce la obţinerea

tabelului (relaţiei) T conţinând tuplurile lui R care nu se regăsesc în S.
T= (R – S)
Tabelul BursieriNecăminişti (T= R - S)
Matricola Nume Media
112 Toma Ene 8,80
 Produs Cartezian

Produsul cartezian al tabelelor R şi S conduce la obţinerea unui tabel T stocând mulţimea

perechilor obţinute din concatenarea înregistrărilor lui R şi S:
T= (R x S)
Tabelul Căminişti (R)
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

Tabelul Camere (S)

Camin Camera
C1 1
C1 2
C2 1

Tabelul Repartiţii T= (R x S)
Matricola Nume Medie Cămin Camera
110 Dan Ion 8,75 C1 1
110 Dan Ion 8,75 C1 2
110 Dan Ion 8,75 C2 1
111 Denilescu Ana 9,25 C1 1
111 Denilescu Ana 9,25 C1 2
111 Denilescu Ana 9,25 C2 1

Operatori unari

 Proiecţia

Operatorul de proiecţie aplicat asupra tabelului R conţinând m atribute conduce la obţinerea

rtabelului T cu acelaşi număr de tupluri ca şi R, dar cu un număr redus de atribute.
T = ∏ (R; A,B) unde A şi B sunt atribute aparţinând lui R.
Dacă se doreşte obţinerea listei conţinând numele studenţilor transferaţi se aplică operatorul de
proiecţie astfel:
T= ∏ (Transferări, Nume)

Tabelul Transferări (R)

Matricola Nume Media
230 Pop Geta 9,15
190 Marin Dana 8,25

T= ∏ (Transferări, Nume)
Nume
Pop Geta
Marin Dana

 Selecţia

Aplicarea operatorului de selecţie asupra tabelului R generează tabelul T prezentând aceeaşi

structură cu R dar conţinând doar tuplurile ce corespund unei condiţii precizate:

T= Sel (R; <condiţie>)

Dacă se doresc informaţii despre studenţii căminişti având medii peste 8,50 operatorul de selecţie
va fi:

T = Sel (Căminişti; Media>8,50)

Tabelul Căminişti (R)
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25
130 Ionescu Angela 8,15
127 Manea Ion 8,30

T = Sel (Căminişti; Media>8,50)

Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

Operatori de extensie
 Compunerea (Join)

Compunerea a două tabele R şi S, după valorile egale ale unui atribut comun A, conduce la
obţinerea unui tabel T ale cărei tupluri s-au format prin produsul cartezian al tuplurilor din R şi S
prezentând valori egale pe atributul de compunere A.
Tabelul Căminişti
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

Tabelul CamereStudenţi
Camin Camera Matricola
C1 1 110
C2 10 111

T= Join (Căminişti, CamereStudenţi; Căminişti. Matricola=CamereStudenţi.Matricola)

Matricola Nume Media Cămin Camera
110 Dan Ion 8,75 C1 1
111 Denilescu Ana 9,25 C2 10
  Diviziunea

Fiind date tabelele R (cu schema r) şi S (cu schema s), aplicarea operatorului de diviziune va
genera tabelul (R  S) de grad r-s ale cărui tupluri concatenate cu tuplurile lui S vor genera
tupluri aparţinând lui R.
Exemplu:
Fie tabelul R din exemplul anterior:
Matricola Nume Media Cămin Camera
110 Dan Ion 8,75 C1 1
111 Denilescu Ana 9,25 C2 10

Prin aplicarea operatorului diviziune prin tabelul Căminişti se va genera tabelul Camere:
Tabelul Căminişti (S)
Matricola Nume Media
110 Dan Ion 8,75
111 Denilescu Ana 9,25

Tabelul Camere (R  S)
Cămin Camera
C1 1
C2 10

CAPITOLUL 2. PROIECTAREA MODELULUI RELAŢIONAL

AL DATELOR PRIN NORMALIZARE

În literatura de specialitate, în funcţie de complexitatea bazei de date sunt abordate

următoarele metode de proiectare:
 proiectarea modelului relaţional printr-un model static (utilizând limbajul UML);
 proiectarea modelului relaţional printr-un model conceptual (utilizând modelul entitate –
asociere);
 proiectarea modelului relaţional prin procesul de normalizare.
În continuare este prezentată proiectarea modelului relaţional prin procesul de normalizare.
Normalizarea este procesul care presupune descompunerea unui tabel relaţional alcătuit
dintr-un set de atribute, în două sau mai multe tabele care vor forma baza de date, cu scopul de a
elimina redundanţele (memorarea repetată a aceloraşi date) şi anomaliile care pot apărea în
operaţiile de adăugare, modificare sau ştergere de înregistrări. Acest proces se fundamentează pe
conceptele:
 dependenţă funcţională
 dependenţă multivaloare
 forme normale.
Ideea centrală care stă la baza proiectării unei baze de date relaţionale este aceea de dependenţă
a datelor [Dollinger]. Aceasta se referă la faptul că între atributele unei relaţii (tabel relaţional)
sau între atribute din relaţii diferite pot exista anumite legături logice (dependenţe), iar aceste
legături influenţează proprietăţile relaţiilor în raport cu operaţiile curente care apar în exploatarea
bazei de date, cum ar fi: adăugarea, modificarea şi ştergerea înregistrărilor.
Exemplu:
Fie relaţia Aprovizionare (Cod_Fz, Nume-fz, Adresa_Fz, DenMarfa, PretFact):
Cod_Fz Nume_Fz Adresa_Fz DenMarfa PretFact
100 SC ALFA SRL Bucuresti Portocale 5
100 SC ALFA SRL Bucuresti Banane 3
101 SC BETA SRL Brasov Portocale 4.8
102 SC GAMA SRL Galati Kiwi 6
----------- ---------- --------- --------
Analizând această relaţie se observă o redundanţă a datelor pentru aprovizionările realizate cu
acelaşi furnizor. Altfel spus valorile asociate atributelor Nume_Fz şi Adresă_Fz se repetă la
fiecare marfă livrată de acel furnizor. Mai mult această redundanţă a datelor conduce la apariţia
următoarelor anomalii:
 Anomalia de adăugare – nu se poate înregistra un furnizor atât timp cât acesta nu
livrează o marfă.
 Anomalia de ştergere – dacă se şterg toate mărfurile livrate de un furnizor, atunci se
pierd, în mod neintenţionat, şi caracteristicile acelui furnizor (numele furnizorului, adresa
furnizorului).
 Anomalia de modificare – dacă se modifică, spre exemplu, adresa unui furnizor, atunci
este necesară parcurgerea întregii relaţii pentru a opera modificarea la nivelul tuturor
înregistrărilor.
Aceste anomalii pot fi eliminate, dacă tabelul iniţial Aprovizionare este supus unui proces de
normalizare, în urma căruia va fi descompus în următoarele tabele:
Furnizori (Cod_Fz, Nume_Fz, Adresa_Fz)
Livrare (Cod_fz, DenMarfa, PretFact)
Furnizori
Cod_Fz Nume_Fz Adresa_Fz
 100 SC ALFA SRL Bucureşti
101 SC BETA SRL Brasov
102 SC GAMA SRL Galaţi

Livrare
Cod_Fz Den_Marfa PretFact
100 Portocale 5
100 Banane 3
101 Portocale 4.8
102 Kiwi 6
2.1. Dependenţe funcţionale

2.1.1. Dependenţa funcţională simplă

Între două atribute X şi Y există o dependenţă funcţională simplă, notată , dacă şi

numai dacă fiecărei valori a atributului X îi corespunde o singură valoare a atributului Y.
Atributul X se numeşte „determinantul” iar Y „determinatul” dependenţei.
De exemplu, pentru o valoare asociată unui CodMarfa îi corespunde o singură valoare pentru
DenMarfa. În acest caz, este vorba despre o dependenţă funcţională ce se stabileşte între cele
două atribute, reprezentată astfel: CodMarfa → DenMarfa.
Alte exemple de dependenţe funcţionale sunt reprezentate mai jos:
NrFact → Datafact
NrFact → CodFz.
CodMarfa, Nrfact → PretFact
Tipuri de dependenţe funcţionale:
 Dependenţa funcţională totală. Dependenţa funcţională X→Y este totală dacă nu există
nici un subset Z al atributului X astfel încât Z→Y.
Exemplu: NrFact → Datafact
NrFact → CodFz
CodMarfa, Nrfact → PretFact
 Dependenţa funcţională parţială. Dependenţa funcţională este parţială dacă
există un subset Z al atributului X (Z  X) astfel încat Z→Y.
Exemplu: CodMarfa, Nrfact → Codfz este o dependenţă parţială deoarece există subsetul
Nrfact care determină funcţional CodFz.
 Dependenţa funcţională trivială. Dependenţa funcţională este trivială dacă
există un subset Y al atributului X (Y  X) astfel încat X→Y.
Exemplu: CodMarfa, Nrfact →Nrfact este o dependenţă trivială, care nu aduce nici un
plus de informaţie.
Dependenţele funcţionale pot fi deduse folosind un set de reguli, numite axiomele lui
Armstrong [Dollinger]:
1. Reflexivitate: Dacă Y  X, atunci X→ Y.
Exemplu: Dacă Nrfact  (CodMarfa, Nrfact), atunci
(CodMarfa, Nrfact) → Nrfact.
Această axiomă generează dependenţele funcţionale triviale.
2. Augmentare (Amplificare): Dacă X →Y, atunci X  Z →Y  Z
Exemplu: Dacă NrFact → CodFz , atunci
(Nrfact, Nrdocplata) →(Codfz, Nrdocplata).
 3. Tranzitivitate: Dacă X→Y şi Y→Z, atunci X→Z.
Exemplu: Dacă NrFact → CodFz şi Codfz →Denfz, atunci Nrfact→Denfz. Această
axiomă este utilizată în aplicarea formelor normale.
2.1.2. Dependenţa funcţională multiplă

Între două atribute X şi Y există o dependenţă funcţională multiplă, notată

X Y, dacă şi numai dacă pentru o valoare a atributului X corespund două sau mai multe
valori a atributului Y.
De exemplu, pentru o valoare asociată unui CodFz vor corespunde mai multe valori pentru
NrFact, deoarece la date calendaristice diferite unui furnizor i se pot emite mai multe facturi. În
acest caz, este vorba despre o dependenţă funcţională multiplă ce se stabileşte între cele două
atribute, reprezentată astfel:
CodFz NrFact. De asemenea, pe o factură se pot regăsi mai multe mărfuri aprovizionate,
fapt pentru care putem spune că între atributele Nrfact şi CodMarfa se stabileşte o dependenţă
funcţională multiplă (Nrfact CodMarfa).

2.2. Dependenţe multivaloare

Se consideră relaţia R(X,Y,Z), unde X,Y,Z sunt atributele acesteia (simple sau compuse). Fie
xi,yi,zi valorile atributelor X,Y şi Z [Dollinger].
Spunem că există o dependenţă multivaloare a atributului Z faţă de Y, notată Y→→Z, dacă
pentru orice valori x1, x2, y, z1 şi z2, x1≠x2, z1≠z2, astfel încât tuplurile (x1,y,z1) şi (x2,y,z2) fac
parte din relaţia R, atunci şi tuplurile (x1,y,z2) şi (x2,y,z1) fac parte din relaţia R.
Din simetria definiţiei rezultă că dependenţa multivaloare Y→→Z implică dependenţa
multivaloare Y→→X.
De exemplu, în relaţia R(Serie_Facultate, NrMatricolStudent, NumeProfesor) există
dependenţe multivaloare, deoarece la seria unei facultăţi sunt înscrişi mai mulţi studenţi, care
studiază cu mai mulţi profesori la materii diferite. Dacă fiecare student studiază cu toţi profesorii,
atunci există următoarele dependenţe multivaloare:
Serie_Facultate →→ NrMatricolStudent
Serie_Facultate →→ NumeProfesor
În mod practic, dacă există tuplurile (EAM_SeriaA, NrMatricol1, Profesor_Info) şi
(EAM,_SeriaA, NrMatricol2, Profesor_Mate) atunci vor exista şi tuplurile (EAM_SeriaA,
NrMatricol1, Profesor_Mate) şi (EAM_SeriaA, NrMatricol2, Profesor_Info).
În general dependenţele multivaloare sunt mai dificil de identificat şi mai rar întâlnite în practică,
fapt ce ne determină să nu insistăm mai mult asupra lor.
2.3 Formele normale

Teoria clasică a normalizării este construită în jurul a cinci forme normale. E.F.Codd, părintele
modelului relaţional, a definit iniţial trei forme normale [Fotache]: FN1, FN2 şi FN3. Apoi,
forma normală Boyce-Codd, numită astfel după numele celor doi specialişti în domeniu, s-a dorit
a fi o formă generalizată a FN2 şi FN3. Aceste patru forme normale sunt asociate dependenţelor
funcţionale.
Formele normale 4 şi 5 (FN4, FN5), asociate în literatura de specialitate cu numele cercetătorului
Fagin, se bazează pe dependenţele multivaloare.
Mulţi specialişti consideră că pentru elaborarea unei baze de date relaţionale sunt suficient de
parcurs primele trei forme normale. Plecând de la acestă prezumţie, în continuare vom prezenta
doar primele trei forme normale (FN1, FN2 FN3).
Forma normală 1 (FN1) – O relaţie (tabel) este în prima formă normală dacă toate atributele
sale sunt atomice (elementare, care nu se mai pot descompune) şi nerepetitive. Un atribut este
considerat elementar atunci când descompunerea lui nu prezintă interes pentru aplicaţia ce se va
dezvolta.
Exemplu: Fie tabelul Furnizor (CodFz, DenFz, Adresa)

Localitate Strada Număr

CodFz DenFz Adresa
1 SC Agro SA Bucureşti, str. Popa Nan, nr.3
2 SC Muntenia SA Bucureşti, str. Alexandriei, nr.36
3 SC Tram SA Braşov, str. Biserica Neagră, nr.10
---------- -------------- --------------

Tabelul Furnizor nu respectă FN1 dacă există cerinţe privind gruparea furnizorilor după
localităţi, deoarece este mult mai greu să extragi această informaţie dintr-o adresă completă.
Forma normală 2 (FN2). O relaţie este în cea de-a doua formă normală dacă respectă FN1 şi
orice atribut non-cheie este total dependent faţă de cheia primară a relaţiei.
Exemplu:
Fie tabelul Marfuri_Facturi (NrFact, CodMarfa, DenMarfa, UM, Calitate, CantFact).
NrFact CodMarfa DenMarfa UM Calitate CantFact
10 100 Portocale kg 1 70
10 200 Kiwi kg 1 90
11 400 Pomelo buc 2 50
 11 100 Portocale kg 1 100
--------- --------------- ---------------- ---- ----------- ---------------

Analizând această relaţie, pot fi identificate următoarele dependenţe funcţionale:

 CodMarfa DenMarfa, UM, Calitate, deoarece fiecare cod unic de marfă determină o
valoare pentru denumirea mărfii, unitate de măsură, calitate.
 NrFact, CodMarfa CantFact, atributul compus (Nrfact, CodMarfa) determină
funcţional CantFact.În mod practic, unei facturi nu i se poate asocia o cantitate facturată
totală, altfel spus între NrFact şi CantFact nu poate exista o dependenţă funcţională.
Pornind de la aceste dependenţe se deduce că relaţia Marfuri_Facturi are o cheie primară
compusă, formată din atributele NrFact şi CodMarfa.
În mod practic, tabelul Marfuri_Facturi nu respectă FN2 deoarece se poate observa
dependenţa funcţională a atributelor DenMarfa, UM, Calitate faţă de CodMarfa, ceea ce implică
dependenţa parţială a acestor atribute faţă de cheia relaţiei formată din NrFact şi CodMarfa.
Această dependenţă funcţională parţială are drept consecinţe o serie de anomalii:
 anomalia de adăugare – nu se pot adăuga noi mărfuri atâta timp cât acestea nu sunt
aprovizionate, altfel spus nu apar pe o factură;
 anomalia de ştergere - dacă se şterge înregistrarea corespunzătoare pentru o singură
marfă existentă, atunci se pierd şi informaţiile referitoare la denumire marfă, unitate de
măsură şi calitate;
 anomalia de modificare - dacă se cere modificarea calităţii pentru o marfă, trebuie
căutate toate înregistrările în care se regăseşte aceasta, ceea ce implică parcurgerea
relaţiei în întregime.

Figura 2.1 Dependenţe funcţionale identificate

Aceste anomalii se pot elimina prin descompunerea relaţiei Marfuri_Facturi în relaţiile:
Marfuri (CodMarfa, DenMarfa, UM, Calitate)
MarfurFacturate (NrFact, CodMarfa, CantFact)
Forma normală 3 (FN3). O relaţie este în FN3 dacă respectă FN2 şi toate atributele non-cheie
sunt dependente direct de cheia primară. Altfel spus FN3 interzice dependenţele tranzitive.

Exemplu:
Fie tabelul Facturi_Furnizori (NrFact, DataFact, CodFz, DenFz, Localitate)

NrFact DataFact CodFz DenFz Localitate

10 01/03/2009 1 SC Agro SA Bucureşti
11 05/03/2009 1 SC Agro SA Bucureşti
12 12/03/2009 2 SC Tram SA Braşov
---------- -------------- --------------

Pot fi identificate următoarele dependenţe funcţionale:

 NrFact DataFact, CodFz, deoarece fiecare număr de factură determină o valoare
pentru data facturii şi codul furnizorului care a emis acea factură.
 CodFz DenFz, Localitate, deoarece fiecare cod unic de furnizor determină o valoare
pentru denumirea furnizorului şi Localitatea acestuia.
Se observă ca între atributele NrFact şi DenFz, Localitate apar dependenţe tranzitive, fapt ce ne
determină să afirmăm că tabelul Facturi_Furnizori nu respectă FN3.
Aceste dependenţe funcţională tranzitive au drept consecinţe o serie de anomalii identificabile la
adăugarea, modificarea sau ştergerea înregistrărilor din cadrul acestui tabel.
Aceste anomalii pot fi eliminate prin descompunerea relaţiei Facturi_Furnizori în relaţiile:
Facturi (NrFact, DataFact, CodFz)
Furnizori (CodFz, DenFz, Localitate)
2.4 Cadrul metodologic de proiectare a modelului relaţional prin normalizare

Proiectarea unei baze de date relaţionale prin normalizare se poate realiza prin:
 descompunerea tabelului relaţional iniţial în mai multe tabele, utilizând formele normale
(FN1, FN2, FN3, FN4, FN5);
 descompunerea tabelului relaţional iniţial în mai multe tabele, utilizând matricea
dependenţelor funcţionale sau graful dependenţelor.

2.4.1 Proiectarea modelului relaţional prin normalizare utilizând formele normale

Paşii recomandaţi a fi realizaţi pentru proiectarea modelului relaţional prin normalizare, utilizând
formele normale sunt [Fotache]:
1. Inventarierea atributelor şi constituirea tabelului relaţional iniţial (relaţiei universale).
Se vor prelua toate atributele care fac obiectul problemei de rezolvat, din documentele
primare şi situaţiile de ieşire.
2. Se determină cheia primară a relaţiei şi se reprezintă toate dependenţele funcţionale ce
decurg de aici.
3. Se elimină atributele calculabile şi cele repetitive astfel încât tabelul iniţial să respecte
FN1.
4. Se elimină dependenţele funcţionale parţiale prin descompunerea tabelului iniţial în
tabele cu structuri mai simple, care să respecte FN2.
5. Se elimină dependenţele funcţionale tranzitive prin descompunerea tabelelor din etapa
anterioară astfel încât acestea să respecte FN3.
6. Se identifică eventualele dependenţe multivaloare şi se elimină astfel încât să tabelele să
respecte FN4, respectiv FN5.

2.4.2 Proiectarea modelului relaţional prin normalizare utilizând matricea dependenţelor

funcţionale
Demersul metodologic de proiectare a unui model relaţional prin normalizare utilizând matricea
dependenţelor funcţionale sau graful dependenţelor presupune parcurgerea următoarelor etape:
1. Inventarierea atributelor. Într-un dicţionar al datelor se vor prelua toate atributele care
fac obiectul problemei de rezolvat, din documentele primare şi situaţiile de ieşire.
 2. Specificarea regulilor de gestiune – diverse restricţii/condiţii impuse datelor. La nivelul
acestei etape, algoritmii de calcul sunt asociaţi şi ei regulilor de gestiune.
3. Întocmirea dicţionarului de date de către proiectantul bazei de date care va urmări
respectarea următoarelor reguli:
 atributele sunt înscrise o singură dată;
 sunt eliminate atributele sinonime;
 sunt eliminate atributele calculate.
4. Stabilirea cheilor primare.
5. Stabilirea dependenţelor funcţionale – ce pot fi descrise printr-un graf al dependenţelor
sau în cadrul unei matrice a dependenţelor funcţionale.
6. Pentru atributele izolate se vor căuta grupuri de atribute ce pot constitui determinanţi
ai acestora.
7. Formarea tabelelor - cu fiecare cheie primară şi atributele determinate direct şi
netranzitiv se va forma un tabel.
8. Identificarea atributelor cu rol de cheie externă.
9. Definitivarea modelului relaţional.

EXEMPLU:
O societate comercială doreşte să-şi informatizeze activitatea de aprovizionare cu mărfuri de la
furnizori. Furnizorii societăţii, se identifică printr-un cod unic, nume, localitate, telefon şi cont
bancar.
Aprovizionarea cu mărfuri se realizează în baza facturilor primite de la furnizori, fiecare Factură
identificându-se printr-un număr unic, dată factură, data scadenţei, codul, denumirea, contul
bancar al furnizorului, codul, denumirea şi contul clientului, codul, denumirea, unitatea de
măsură, cantitatea şi preţul mărfurilor facturate, valoarea acestora, valoare TVA şi valoarea
totală a facturii. Pentru fiecare zi de întârziere (faţă de data scadenţei) a plăţii facturii, furnizorii
percep o penalizare de 1% din valoarea totală a facturii.
Nomenclatorul mărfurilor include referinţe la codul de marfă, denumire marfă, unitatea de
măsură şi calitate. Nomenclatorul va conţine maxim 100 de mărfuri distincte ale căror unităţi de
măsură sunt exprimate în kg, buc, litri.
Plata facturii se realizează printr-o Chitanţă, conform facturii emise, în care se precizează
numărul chitanţei, data chitanţei, suma plătită, denumirea şi contul emitentului, denumirea şi
contul beneficiarului (furnizorului). Societatea plăteşte cu un astfel de document o singură
factură.
Se cere să se proiecteze baza de date relaţională prin normalizare utilizând matricea
dependenţelor funcţionale.
În acest scop s-au parcurs paşii următori (descrişi în cadrul metodologic de proiectare a
modelului relaţional prin normalizare):
1. Inventarierea atributelor. Pe baza informaţiilor referitoare la activitatea de aprovizionare cu
mărfuri de la furnizori, se poate întocmi dicţionarul de atribute:
 Nr. Atribut Semnificaţie
Crt.
1. CodFz Cod Furnizor
2. CodBenef Cod Beneficiar
3. NumeFz Nume Furnizor
4. Localitate Localitate Furnizor
5. Telefon Telefon Furnizor
6. ContBancar Cont Bancar Furnizor
7. NrFact Număr Factură
8. DataFact Data Facturii
9. DataScad Data Scadenţă Factură
10. CantitateFact Cantitate Facturată
11. PretFact Pret Facturare
12. CotaTVA Cota TVA
13 Valoaremarfa Valoare Marfă Facturată
14. TVA Valoare TVA
15. ValoareFactura Valore Totală Factură
16. CodMarfa Cod Marfă
17. DenMarfa Denumire Marfă
18. UM Unitate de Măsură
19. Calitate Calitate Marfă
20. Nrchit Număr Chitanţă
21. DataChit Data Chitanţă
22. SumaPl Suma Plătită
23. TotalSumePl Sume Totale Plătite
24. Penalizare Penalizare Factură
25 Nr_zile-intarz Nr. Zile de Întârziere

2. Specificarea regulilor de gestiune:

 O factură este emisă de un singur furnizor.
 O factură poate conţine mai multe mărfuri, iar o marfă se poate regăsi pe mai
multe facturi.
  O factură poate fi plătită eşalonat.
 O chitanţă este conformă cu o factură emisă de furnizor.
Algoritmi de calcul:
Valoare_Marfă=CantitateFact*PretFact
TVA=CotaTVA*Valore_Marfa
ValoareFactura=Valoare_Marfa+TVA
Nr_zile_întarz=DataChit - DataScad
Penalizare =Nr_zile_intarziere*ValoareFactura*1/100
Totalsumepl= suma pl

3. Întocmirea dicţionarului de date, se va realiza pe baza următoarelor reguli:

 fiecare atribut este înscris o singură dată;
 sunt eliminate atributele sinonime (în exemplul prezentat, CodFz şi CodBenef sunt
sinonime, deci se va reţine doar unul dintre acestea – CodFz);
 nu sunt preluate atributele calculate (Valoare_Marfa, TVA, ValoareFactura,
Nr_zile_întarz, Penalizare, Totalsumepl).

Dicţionarul de date (DD): CodFz, NumeFz, Localitatea, ContBancar, Telefon, NrFact, DataFact,
DataScad, CantitateFact, PretFact, CotaTVA, CodMarfa, DenMarfa, UM, Calitate, NrChit,
DataChit, SumaPl.

4. Stabilirea cheilor primare: CodFz, NrFact, CodMarfa, NrChit.

5. Stabilirea dependenţelor funcţionale.
a. Graful dependenţelor funcţionale simple:

b. Graful dependenţelor funcţionale multiple:

Nrfact CodFz CodMarfa NrFact
NrFact NrChit NrFact CodMarfa
 6. Atributele izolate: CantitateFact, PretFact şi CotaTVA vor fi determinate de un grup de
atribute aşa cum sunt reprezentate mai jos.

Ne punem întrebarea „De ce Nrfact nu determină funcţional, spre exemplu, Cantitatefact?”.

În mod practic, o factură poate conţine mai multe mărfuri achiziţionate şi, prin urmare, Nrfact nu
va determina o singură valoare pentru CantitateFact. Pentru o factură (NrFact) se poate asocia o
valoare totală facturată, dar nu se pot însuma cantitaţile, preţurile, CotaTva a mărfurilor
facturate.
Atributul compus (Nrfact, CodMarfa) reprezintă o cheie primară care se va adăuga cheilor
identificate în etapa precedentă.
Dependenţele funcţionale identificate anterior se vor reprezenta într-o Matrice a
dependenţelor funcţionale (reprezentată într-o formă simplificată, fără a include dependenţele
funcţionale multiple şi dependenţele funcţionale multiple tranzitive, în figura 2.2). Liniile şi
coloanele acestei matrici sunt reprezentate de atributele din dicţionarul de date şi atributele
compuse care au fost identificate ca fiind chei primare. Cheile primare sunt marcate prin
caracterul #. Pentru fiecare cheie primară, pe acea linie, sunt reprezentate tipurile de dependenţe
funcţionale identificate astfel:
1- dependenţele funcţionale simple

1T - dependenţele funcţionale simple tranzitive

 Figura 2. 2 Matricea dependenţelor funcţionale

7. Formarea tabelelor. Fiecare cheie primară şi atributele determinate direct şi netranzitiv

vor forma un tabel.
8. Identificarea cheilor externe (atributele subliniate prin linie discontinuă la nivelul
modelului relaţional).
9. Definitivarea modelului relaţional.
FURNIZORI (CodFz, NumeFz, Localitate, Telefon, ContBancar)
FACTURI (NrFact, DataFact, DataScad, CodFz)
MARFURI(CodMarfa, DenMarfa, UM, Calitate)
MARFURIFACTURATE (CodMarfa, NrFact, CantitateFact, PretFact, CotaTVA)
CHITANTE (NrChit, DataChit, SumaPl, NrFact)