Am spus ca nu folosesc ultimele forme nu ca nu folosesc nici una.

Normalizarea aia nu e lege, de multe ori se ajunge sa se denormalizeze pentru a mari viteza de procesare de
exemplu. 
Si inca o data,  4NF si 5NF se folosesc in cazuri exceptionale in practica si banuiesc ca de niste "guru" in
proiectare, deci nu iti pune tu probleme de genul asta: ca nu e tabelul in NF4 sau NF5.
Pur si simplu ignora Boyce-Codd NF, NF4 si NF5 pentru ca nu se aplica in practica pentru ca ai ajunge la
jdemii de tabele de cele mai multe ori fara nici un castig.
Uite sa-ti dau un exemplu de denormalizare(de fapt multi o practica instinctiv    )
ai tabelul users(id, username, adresa, cod_postal, oras);

1.e 1FN deoarece 

-are o cheie primara
-nu are grupuri repetitive
-toate campurile contin valori atomice*
2. e in 2FN deoarece:
-e in 1FN
-nu exista dependente partiale fata de cheia primara(adica un camp sa depinda partial de cheia
primara, caz posibil doar in cazul in care cheia primara este formata din cel putin doua campuri, aici
este formata doar dintr-un singur camp-id)
3. nu e in 3FN pentru ca contine dependente functionale tranzitive: un camp depinde printr-un un
altul de cheia primara: codul postal depinde de adresa si oras si prin ele de id

Solutia:
mai faci un tabel ce contine campurile adresa oras cod_postal si scoti cod_postal din users.
Ceea ce probabil ca de cele mai multe ori nu se merita.
*Campul adresa este cu siguranta alcatuit din mai multe valori-deci nu este atomic, adica users nu este nici
macar in 1FN daca e sa privesti strict lucrurile. Ca sa fie ar insemna sa mai faci un tabel separat cu strada,
bl., ap, etaj. Ceea ce nu are nici un rost in marea majoritate a cazurilor pentru ca te intereseaza adresa ca
ansamblu nu la ce apartamente stau utilizatori cu numele Ionescu. 
 Formele normale ale bazelor de date

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.