Un tabel prost proiectat repetă datele și creează contradicții. Normalizarea îl împarte în tabele mici, curate, în trei etape (FN1 → FN2 → FN3), fiecare eliminând un tip de problemă.
Când toate datele stau într-un singur tabel gras, aceleași informații se repetă. De aici, trei feluri de necazuri.
Orașul Anei apare pe 20 de rânduri. Se mută în alt oraș → trebuie schimbat în toate; ratezi unul → date contradictorii.
Vrei să adaugi un produs nou care n-a fost încă comandat — dar nu poți, fiindcă n-ai id_comanda. Datele „se blochează".
Ștergi ultima comandă a unui client și, fără să vrei, pierzi și adresa lui — era ținută doar acolo.
Pornim de la un tabel de comenzi „nenormalizat" și îl aducem, pe rând, la FN1, FN2, FN3. Apasă butoanele și urmărește cum se sparge.
Fiecare formă normală o presupune pe cea dinainte.
Fiecare celulă conține o SINGURĂ valoare — fără liste, fără grupuri care se repetă. Un rând per produs, nu mai multe produse într-o celulă.
Se aplică la chei compuse: fiecare atribut non-cheie trebuie să depindă de cheia ÎNTREAGĂ, nu doar de o parte a ei. (prețul depinde de produs, nu de comandă.)
Niciun atribut non-cheie nu depinde de alt atribut non-cheie. (orașul depinde de client, nu de id_comanda → se mută.)
Șase întrebări despre normalizare.
Formele normale, condensat.