Primele trei forme normale: 1NF, 2NF si 3NF

O bază de date bine proiectată nu permite ca datele să fie redundante, adică aceeaşi
informaţie să se găsească în locuri diferite. De asemenea nu se memorează informaţii care
se pot deduce din alte informaţii retinute în baza de date.
In 1970 – 1971 Edgar Codd a definit primele trei forme normale 1NF, 2NF şi 3NF.
Ulterior s-au mai definit formele normale 4NF, 5NF, 6NF care însă sunt rar folosite în
proiectarea bazelor de date.

Prima formă normală

O entitate se găseşte în prima formă normală dacă şi numai dacă:
- nu există atribute cu valori multiple;
- nu există atribute sau grupuri de atribute care se repetă.
Cu alte cuvinte toate atributele trebuie să fie atomice, adică să conţină o singură
informaţie.

adresa este de forma "str. Florilor, bl. 45, sc. A, ap. 28, etaj 3, Braşov, cod 123123", formă
care de fapt conţine mai multe informaţii elementare. Aşadar, în mod normal acest atribut
ar trebui "spart" în mai multe atribute ca în fig din dreapta.
Exemple:
1) Clădirea şcolii( # cod, * nume, * adresa, o sala de clasa) => entitatea Sala_de_clasa
(#numar, *etaj, *suprafata)
2) Client (# codc, * nume, * prenume, o evenimet) => entitatea Eveniment
(#id_eveniment, *nume)

A doua formă normală

O entitate se găseşte în a doua formă normală dacă şi numai dacă se găseşte în prima
formă normală şi în plus orice atribut care nu face parte din UID (unique identifier) va
depinde de întregul UID nu doar de o parte a acestuia.
Observaţie. Dacă o entitate se găseşte în prima formă normală şi UID-ul său este format
dintr-un singur atribut atunci ea se găseşte automat în a doua formă normală.

A treia formă normală

O entitate se găseşte în a treia formă normală dacă şi numai dacă se găseşte în a doua
formă normală şi în plus nici un atribut care nu este parte a UID-ului nu depinde de un alt
atribut non-UID. Cu alte cuvinte nu se acceptă dependenţe tranzitive, adică un atribut să
depindă de UID în mod indirect.

Baze de date relationale (BDR)

 Conceptul de BDR
 Proiectarea de BDR
 Algebra si calculul relational

Conceptul de BDR

BDR implementeaza modelul de date relational. Au aparut odata cu cele 12 reguli ale lui
CODD, in 1970.

Notiuni utilizate in BRD:

1. Modelul de date relational

2. Structura relationala a datelor
1. Domeniul
2. Relatia
3. Tuplul(inregistrarea)
4. Atributul
5. Schema unei relatii
3. Operatorii modelului
4. Restrictiile de integritate ale modelului relational

Modelul de date relational ofera o serie de avantaje printre care si:

 Independenta mare a aplicatiilor fata de date.

 Furnizarea unor tehnici si metode de acces la date si de control la redundante,
folosind normalizarea datelor.
 Facilitati de definire si manipulare a datelor prin limbajele neprocedurale si
procedurale diferite.
  Oferirea unei integritati sporite a datelor.

Structura relationala a datelor consta in cateva elemente cheie ale structurii:

Domeniul – toate datele din BDR au precizate un domeniu de valori care se poate defini
explicit sau implicit.

Ex: D1={„rosu”,”galben”} – definire explicita

D2={x in intervalul [0,256]} – definire implicita

D3={sir_de_caractere} – definire implicita

Relatia (tabela) reprezinta un subansamblu al produsului cartezian, al mai multor domenii

de vaori asociate datelor.

Ex: D1*D2*D3*….*Dn

Tuplul (inregistrarea) reprezinta o combinatie unica a produsului cartezian al domeniilor

de valori asociate relatiei (tabelei). Intr-o relatie nu se admit tupluri duplicat. Numarul
tuplurilor dintr-o relatie reprezinta cardinalul relatiei.

Atributul reprezinta coloana unei tabele caracterizata printr-un nume. Unui atribut i se
asociaza un domeniu de valori.

Schema unei relatii – se reprezinta colectia de date fie precizand atributele si domeniile
asociate sub forma:

R(A1:D1;A2:D2;…..)

Sau sub forma tabelata:

A1:D1 A2:D2 A3:D3 …………..

Operatorii modelului sunt bazati pe operatori din algebra relationala si calcul relational
(vezi curs viitor).

Restrictiile de integritate ale modelului relational se pot clasifica in restrictii:

 Structurale
 De comportament

Proiectarea de BDR
Tehnica normalizarii s-a impus ca principala modalitate de proiectare a unei BDR si se
utilizeaza in principal pentru a elimina o serie de situatii (anomalii) in care datele sunt
preluate necorespunzator. Aceste anomalii pot fi:

 De adaugare
 De modificare
 De stergere

Anomaliile de adaugare apar atunci cand nu se pot adauga valori noi in tabele pentru ca
nu se cunosc toate informatiile utile pentru legatura cu alte tabele

Anomaliile de modificare apar cand datele au o redundanta foarte mare si apar in mai
multe tupluri sau chiar in mai multe tabele.

Anomaliile de stergere apar cand se sterg si alte informatii pe langa cele dorite.

Normalizarea presupune descompunerea de sus in jos a unei colectii de date, pana la

eliminarea completa a anomaliilor de actualizare sau pana la obtinerea unei redundante
minime si controlate a datelor.

DEF1: o tabela este intr-o forma normala i (FNi) daca este in forma normala i-1 (FNi-
1) si respecta cerintele formei normale i.

DEF2: o baza de date este in forma normala i (FNi) (i=1,2,3,4,5) daca toate tabelele
sale sunt in Fni.

Exista 5 FN, plus o forma normala modificata, numita BCNF(Boyce – Codd – Normal –
Form)

FN1

O tabela este in FN1 daca toate atributele sale contin valori elementare si fiecare tuplu nu
are date la nivel de grup sau valori repetitive.

Structurile de tip arborescent se transforma in tabele separate, cu identificator propriu,

pastrandu-se insa legatura prin acest identificator cu tabela de baza.

O tabela in FN1 are inc ao serie de anomalii de actualizare, datorita unor dependente
functionale incomplete.

Ex:

CLIENT COMANDA DATA VALOARE PROUS/SERVICIU

Fiecare din urmatoarele atribute are date la nivel de grup:

CLIENT se imparte in:

 cod client,
 denumire,
 adresa (localitate, strada, cod postal),
 tip,
 identificator.

VALORE se compune din:

 cantitate,
 pret.

PRODUS/SEVICIU se imparte in:

 cod produs/serviciu,
 tip,
 categorie,
 denumire produs,
 um(unitate de masura)

FN2 - o tabela este in forma normala 2 daca este in FN1 si fiecare atribut non-cheie
depinde functional complet de cheia primara.

Avem atributele:

CODCLIENT DENC ADRESA TIPC ID NR_COMANDA DATA CANT

PRET CODP TIP CATEGORIE

DENC, ADRESA, TIPC, ID depind de cheia CODCLIENT

TIP, CATEGORIE depind de CODP

Anomaliile care raman inca nerezolvate sunt cele de verificare si de stergere.

FN3 – o tabela este in forma normala 3 daca este in FN2 si fiecare atribut non-cheie
depinde in mod netranzitiv de cheie.

In FN2 avem 3 tabele: clienti, comenzi, produse:

Clienti comenzi produse

Codc nr_comanda codp

Denc codc tip

Adresa data categorie

Tipc cant

Id pret

Codp

Cant si pret depind inca de codp à tabela comenzi nu este in FN3 si se vor crea 2 tabele
(detalii_comanda si comenzi)

Forma normala 3 exemplu

Principalele anomalii de actualizare se elimina; raman inca o serie de probleme legate de

dependente multi-valoare.

Obs. Majoritatea BD existente in practica sunt in FN3.

BCNF: O tabela e in BCNF daca fiecare atribut determinant este un candidat cheie.

Un atribut determinant este un atribut fata de care celelalte atribute sunt complet
dependente functional.

FN4: o tabela este in FN4 daca este in FN3 si nu exista 2 sau mai multe dependente
multi-valoar.

Intr-o tabela sunt 3 atribute (A,B,C). Exista dependenta multi-valoare daca unui atribut A
ii corespunde o valoare a lui B si mai multe valori ale lui C.

FN5: o tabela este in FN5 daca este in FN4 si fiecare dependenta jonctiune este generata
printr-un candidat cheie al tabelei.

O depedenta jonctiune apare in cazul in care intre atributele (A,B) si (A,C) se mentine o
dependenta multi-valoare.

In ceea ce priveste proiectare BD se pot folosi si alte tehnici:

 Top-down
 Bottom-up

Algebra relationala
Algebra relationala ofera o serie de operatori care se pot utiliza in interogarea datelor

Sunt 2 tipuri de operatori:

 De baza
 Derivati

Operatorii de baza sunt operatorii pe multimi: reuniunea, diferenta, intersectia

Reuniunea este operatia care se realizeaza intre 2 multimi prin care se iau inregistrarile
comune si necomune din ambele multimi

Ex: Sa se afiseze numele si prenumele angajatilor si numele si prenumele clientilor dupa

urmatorul tipar:

Nume prenume tip (angajat/client)

Select nume, prenume, ‘Angajat’ tip

From angajati

Union

Select nume_c, prenume_c, ‘clienti’

From clienti

Order by 1;

1=numarul coloanei dupa care dorim sa se faca ordonarea, pentru ca numele coloanelor
sunt diferite in cele 2 tabele.

Sunt 2 variante impelmentate:

 Union
 Union all

Union ia inregistrarile commune si necomune, dar elimina duplicatele

Union all ia ingeristrarile commune si necomune, fara sa elimine duplicatele.

Diferenta

Se considera ingeristrarile din relatia R1, care nu sunt si in R2. Operatorul implementat
este MINUS (-).
Ex: Sa se afiseze toate produsele care nu au fost comandate.

Select denumire_produs

From produse

Minus

Select p.denumire_produs

From produse p, rand comenzi r,

Where p.id_produs=r.id_produs;