La normalisation en pratique - quand séparer les données

Tu connais déjà les trois formes normales. Voyons maintenant comment les appliquer avec discernement dans une vraie Bibliothèque - car la normalisation n'est pas une formule à répéter mécaniquement, mais l'art de maintenir l'ordre.

Un fait - un seul endroit

La règle d'or de la normalisation est : écrire chaque fait une seule fois. Le nom de catégorie « Philosophie » ne devrait pas se retrouver copié dans une centaine de parchemins de livres - une seule fois suffit, dans la table kategorie, et les livres n'ont qu'à pointer vers elle grâce à kategoria_id.

Le coût de la répétition (redondance)

Si le nom de la catégorie était répété dans chaque livre, changer « Philosophie » en « Philosophie antique » exigerait de corriger des centaines de lignes d'un coup. En oublier une - et la Bibliothèque perd sa cohérence : certains parchemins disent une chose, d'autres une autre. C'est une anomalie de mise à jour, que la normalisation évite.

Une clé composite et la 2FN

Rappelle-toi la 2FN : elle concerne les tables ayant une clé composite. Dans wypozyczenia, la clé naturelle pourrait être la paire ksiazka_id + czytelnik_id. Si nous y conservions le titre du livre, il ne dépendrait que de ksiazka_id - c'est-à-dire d'une partie de la clé. Cela enfreint la 2FN. Le titre appartient à ksiazki, et seul le renvoi reste dans wypozyczenia.

Relier les tables séparées

Après la séparation, nous récupérons les données avec la commande JOIN - c'est JOIN qui recoud les rayons séparés en un seul résultat :

1SELECT k.tytul, kat.nazwa
2FROM ksiazki k
3JOIN kategorie kat ON k.kategoria_id = kat.id;

Une modération raisonnable

Nous normalisons pour éviter les répétitions et les anomalies - mais nous ne séparons pas indéfiniment. Les trois premières formes normales suffisent pour la grande majorité des projets. C'est exactement ainsi qu'est construite notre base de données biblioteka : propre, cohérente et sans duplication inutile.