Curs 2 - Modelul relaional

2.1. Structura unui tabel (a unei relaii)

Conform modelului relaional emis de E.F. Codd n 1970, o relaie este descris
ca un tabel bidimensional, ce utilizeaz urmtoarele concepte:

a) cmp = o coloan a tabelului (numrul total de cmpuri formeaz gradul

relaiei);
b) tuplu/nregistrare =o linie a tabelului (numrul total de nregistrri formeaz
cardinalitatea relaiei)
c) realizare = o valoare a unui cmp (valoarea NULL = valoare inexistent <> 0)
d) domeniu = ansamblul valorilor permise unui atribut.

ntr-o relaie nu conteaz ordinea cmpurilor i nici ordinea nregistrrilor.

Cmpuri remarcabile (chei):

- cheie primar = cmpul (grupul de cmpuri) cu valori unice i nenule ce
servete la identificarea nregistrrilor unui tabel;
- chei candidate = cmpuri (altele dect cheia primar) ce indeplinesc condiile
necesare cheii primare;
- cheie extern = cmp (grup de cmpuri) ce servete la realizarea legturii cu alt
tabel n care acesta este cheie primar.
Exemplu practic: se consider o baz de date format din tabelele Angajat i
Compartiment, a cror structur este reprezentat n modelul de mai jos:

Angajat (Marca, Nume, Funcie, SalBaz, CodComp)

cheia primar cheia candidat cheia extern

Compartiment (CodComp, DenComp)

Modelul relaional detaliat asociat acestor tabele este reprezentat n figura:

Figura. Model relaional detaliat

 2.2. Proiectarea modelului relaional

n funcie de complexitatea bazei de date exist 3 metode de proiectare:

proiectarea modelului relaional printr-un model static (utiliznd limbajul
UML)
proiectarea modelului relaional printr-un model conceptual (utiliznd
modelul entitate asociere)
proiectarea modelului relaional prin procesul de normalizare.

Normalizarea este procesul care presupune aplicarea formelor normale asupra

unui set de atribute ce formaz iniial un singur tabel. Ideea de baz a procesului de
normalizare este de a nlocui o tabel iniial prin mai multe tabele, iar scopul final este
de a garanta coerena bazei de date. Acest proces se fundamenteaz pe conceptele:
1. dependen funcional
2. dependen multivaloare
3. forme normale.
Ideea centrala care sta la baza proiectarii unei BD relationale este aceea de dependenta a
datelor. Aceasta se refera la faptul ca intre atributele unei relatii sau intre atribute din
relatii diferite pot exista anumite legaturi logice (dependente), iar aceste legaturi
influenteaza proprietatile relatiilor in raport cu operatii curente care apar in exploatarea
BD: adaugare, modificare, stergere.

Exemplu:
Fie relatia Aprovizionare( Nume-fz, Adresa_Fz, Material, Pret)
unde se observa existenta unei dependente a atributului Adresa_Fz fata de Nume_Fz.

Aceasta relatie introduce o redundanta relativ la atributul Adresa_Fz a carui valoare este
repetata la fiecare material livrat de acel furnizor. Aceasta redundanta conduce la aparitia
urmatoarelor anomalii:
Anomalia de adaugare nu se poate inregistra adresa unui furnizor atata timp cat
acesta nu livreaza un material.
Anomalia de stergere daca se sterg toate materialele livrate de un furnizor,
atunci se pierde, in mod neintentionat, si adresa acelui furnizor.
Anomalia de modificare daca se modifica adresa unui furnizor, atunci este
necesara parcurgerea intregii relatii pentru a opera modificarea.

Problemele puse in evidenta se pot elimina daca relatia Aprovizionare este descompusa
in:
Furnizori (Nume_Fz, Adresa_Fz)
Livrare (Nume_fz, Material, Pret)
 Dependena funcional

Atributul X determina functional atributul Y, si notam , daca si numai daca

oricarei valori a atributului X ii corespunde o singura valoare a atributului Y.

Dependenta functionala este totala daca nu exista nici un subset Z al atributului X

astfel incat (respectiv este partiala, in caz contar).

Exemple: CodMat DenMat

CodMat, Nrfact Pret
NrFact Datafact
NrFact CodFurnizor.
Obs:
1. Daca atunci pentru orice subset Z, al lui Y, avem .
2. Daca si X este un atribut simplu, atunci Y este dependent functional total fata
de X.
3. Daca Y este dependent functional total fata de Z, atunci avem pentru orice
atribut compus X care contine pe Z.

Dependena multivaloare

Atributul X determina multivaloric atributul Y, si notam X Y, daca si numai daca

pentru o valoare a atributului X corespund doua sau mai multe valori a atributului Y.

Exemple: CodFurnizor NrFact

Nrfact CodMat
Codmat NrFact.

Forme normale

Forma normal 1 (FN1) O tabel este n FN1 dac conine numai elemente atomice
(elementare, care nu se mai pot descompune) i nerepetitive. Un atribut este considerat
elementar atunci cnd descompunerea lui nu prezint interes pentru aplicaia ce se va
dezvolta.
Exemplu: Furnizor (CodFurnizor, DenFz, Adresa)

Localitate Strada Numar ...

Dac pentru tabela exemplificat exist cerine privind gruparea furnizorilor dup
localiti, atunci aceast tabela nu respect FN1 deoarece este mult mai greu s extragi
aceast informaie dintr-o adres complet.

Forma normal 2 (FN2). O tabel este n FN2 dac respect FN1 i orice atribut non-
cheie este total dependent fa de cheia primar a relaiei.
Exemplu: Fie tabela Profesori_Note (Nume_prof, Functie, Salar, Nume_stud, Nota)

Pot fi identificate urmatoarele dependente functionale:

Nume_prof Functie, deoare fiecare cadru didactic are o fucntie (asistent,
lector, conferentiar, prof)
Functie Salariul, salarizarea se stabileste dupa functia pe care o are fiecare
Nume_prof Salariul
Nume_prof, Nume_stud Nota, in ipoteza ca fiecare profesor acorda unui
student o singura nota.
Pornind de la aceste dependente se deduce ca relatia Profesori_Note are o singura cheie
compusa, formata din atributele Nume_prof si Nume_stud.
Se obs dependenta functionala a atributelor Functie si Salariul fata de atributul
Nume_prof , ceea ce implica dependenta partiala a acestor atribute fata de cheia relatiei
formata din Nume_prof si Nume_stud.
Aceasta dependenta functionala partiala are drept consecinte o serie de anomalii:
anomalia de adaugare nu se pot adauga noi cadre didactice cu functia si salariul
sau atata timp cat acestea nu acorda cel putin o nota unui sutdent.
anomalia de stergere - daca se sterge tupla corespunzatoare singurei note acordate
de un profesor, atunci se pierd si informatiile referitoare la functia si salariul sau.
anomalia de modificare - daca se cere modificarea salariului unui profesor, tb
cautate toate tuplele in care se regaseste acesta, ceea ce implica parcurgerea
relatie in intregime.

Aceste anomalii se pot elimina inlocuind relatia Profesori _Note cu relatiile:

Profesori (Nume_prof, Functie, Salariul)
Note (Nume_prof, Nume_stud, Nota)

Forma normal 3 (FN3). O tabel este n FN3 dac respect FN2 i toate atributele non-
cheie sunt dependente direct de cheia primar. Altfel spus FN3 interzice dependenele
tranzitive.

Exemplu:
Relatia Profesori din exemplul precedent prezinta o serie de anomalii cauzate de
dependenta dintre atributele Functie si Salariul.
 anomalia de adaugare nu se pot adauga valaoarea salariului unui profesor atata
timp cat in relatie nu exista un profesor avand functia respectiva.
anomalia de stergere - daca se sterge tupla corespunzatoare singurului cadru
didactic cu o anumita functie se pierde informatia referitoare la salariul
corespunzator functiei resp.
anomalia de modificare - daca se cere modificarea salariului unui profesor, tb
cautate toate tuplele in care se regaseste acesta, ceea ce implica parcurgerea
relatie in intregime.
Aceste anomalii pot fi eliminate prin descompunerea relatiei Profesori in:
Prof (Nume_prof, Functie)
Functii(Functie, Salariul)

Proiectarea modelului relaional prin normalizare

Demersul metodologic de proiectare a unui model relaional prin normalizare

presupune parcurgerea urmtoarelor etape:
1. inventarierea atributelor. ntr-un dicionar al datelor se vor prelua toate atributele
care fac obiectul problemei de rezolvat, din documentele primare i situaiile de
ieire.
Exemplu: Nrfact; Datafact; cod furnizor; denumire furnizor; adresa

2. specificarea regulilor de gestiune diverse restricii/condiii impuse datelor.

La nivelul acestei etape, algoritmii de calcul sunt asociai i ei regulilor de gestiune.
Exemplu: O factur este emis de un singur furnizor.

3. ntocmirea dicionarului de date, proiectantul urmrind respectarea

urmtoarelor reguli:
atributele sunt nscrise o singur dat
sunt eliminate atributele sinonime
sunt eliminate atributele calculabile.
4. stabilirea dependenelor funcionale ce pot fi descrise printr-un graf al
dependenelor sau n cadrul unei matrici a dependenelor funcionale.
 Fig. Matricea dependentelor functionalecv xv bxdxcd

Obs: In acest caz dependentele functionale dintre atribute sunt reprezentate prin
valoarea 1, iar cele tranzitive au fost marcate cu 1T.
5. pentru atributele izolate se vor cuta grupuri de cmpuri ce pot constitui
determinani ai acestora.

6. stabilirea cheilor primare.

Exemplu: Cod fz, Nr fact

7. formarea tabelelor - cu fiecare cheie primar i atributele determinate direct i

netranzitiv se va forma un tabel.
Exemplu: Furnizor (Cod fz, Denumire fz, Adresa)
Factura (Nr fact, Data fact, Cod Fz)

8. identificarea atributelor cu rol de cheie extern.

Exemplu: Furnizor (Cod fz, Denumire fz, Adresa)
Factura (Nr fact, Data fact, Cod Fz)

9. definitivarea modelului relaional.

 Exemplu practic: O societate comercial i propune proiectarea unui sistem
informatic privind activitatea de aprovizionare cu materiale de la furnizori.

1. Inventarieirea atributelor. Datele care fac obiectul acestei teme, culese din
documentele primare (Comanda, Factura) i situaiile de ieire sunt specificate n tabelul:

Nr. Atribut Semnificaie

Crt.
1. Nrfact Numrul facturii
2. Dataf Data facturii
3. Codfz Codul furnizorului
4. Denfz Denumire furnizor
5. Adresa Adresa fz
6. CodMat Codul materialului
7. DenMat Denumire material
8. UM Unitate de msur
9. Cantfact Cantitate facturat
10. Pretfact Pretul de pe factur
11. NrCom Numrul comenzii
12. DataCom Data comenzii
13. CantCom Cantitate comandat
14. TermenL Termen livrare
15. ValFact Valoare factur
16. TVA TVA
17. TotalFact Totalul facturii

1. Specificarea regulilor de gestiune

a. O comand este adresat unui singur furnizor.
b. O comand poate conine mai multe materiale.
c. Pentru fiecare material inclus n comand, exist un termen de livrare
specific.
d. O factur este emis pe baza unei comenzi primite anterior.
e. O factur va conine unul sau mai multe materiale.

Algoritmi de calcul:
ValFact= cantfact*pretfact
TVA=VALFACT*19/100
TotalFact=TVA+Valfact

2. ntocmirea dicionarului de date.

Dd (Nrfact, Dataf, Codfz, Denfz, Adresa, CodMat, DenMat, UM, Cantfact, Pretfact,
NrCom, DataCom, CantCom, TermenL).

3. Stabilirea dependenelor [Link] dependenelor funcionale:

Atributele izolate: CantFact, PretFfact, CantCom, TermenL sunt determinate de un grup
de atribute aa cum se regsesc reprezentate mai jos.

Stabilirea cheilor primare: Codfz, NrCom, Nrfact, CodMat, NrCom+CodMat,

NrFact+CodMat.

sau o alt soluie o poate reprezenta Matricea dependenelor funcionale:

n cadrul acestui tabel, coloanele 1 -15 sunt tocmai atributele de pe linie, iar
dependenele funcionale dintre atribute sunt reprezentate prin cifra 1 i cele tranzitive cu
1T.

4. Formarea tabelelor, identificarea cheilor externe.

Furnizor (Codfz, Denfz, Adresa)

Comanda (Nrcom, Datacom, Codfz)
Factura (Nrfact, Dataf, Nrcom)
Materiale (Codmat, Denmat, UM, Pret)
Liniecomanda (Nrcom, CodMat, Cantcom, TermenL)
Liniefactura (Nrfact, Codmat, Cantfact, Pretfact)