Accueil » Base de données » Les formes normales en base de données

Les formes normales en base de données

Derrière ce nom barbare se cache un principe qui permet à votre schéma de base de données d’éviter la redondance des données et d’avoir les données les plus cohérentes possibles, à l’instant T et dans la durée.

Il existe de multiples paliers de formes normales, il me semble qu’on en compte huit. Je ne présenterai que les trois premières car c’est celles qui vont régir vos base de données, qui ont le plus d’impact sur la nonredondance et la cohérence des données. Enfin, pour ne pas rebuter les débutants, ce sont les plus simples à mettre en œuvre.

A non-key field must provide a fact about the key, us the whole key, and nothing but the key. In addition, the record must satisfy first normal form.

william Kent – Septembre 1982

Cette citation de William Kent se réfère au trois premières formes normales, que l’on nomme généralement 1NF, 2NF et 3NF.

La première forme normale – 1NF

La plus simple à mettre en place, elle est la première étape qui vous permettra d’obtenir une base de données facile à manipuler.

Contre-exemple de la 1NF

Ici, on peut dire qu’il y a deux exemples de ce qu’il ne faut pas faire. Dans un premier temps, la 1NF est relative à la forme même d’un enregistrement. Ici, j’ai un champ « client » qui contient à la fois le nom et le prénom du client alors que la première forme dit que chaque attribut (colonne) des entités (tables) contient une valeur atomique (non composée). Ici nous violons donc cette règle puisque nous avons la valeur composée du nom plus du prénom.

Ici, le « client » a été remplacé par deux colonnes distinctes « nom » et « prenom » pour satisfaire cette première forme.

Pour aller plus loin, nous pourrions faire la même chose avec le champ « adresse« , ici composée de l’adresse complète alors que nous pourrions séparer : l’adresse, le complément, le code postal, la ville et le pays et la mettre dans une table différente. Ce serait l’idéal dans le cas d’une normalisation d’une adresse ou de la réutilisation possible d’une adresse dans plusieurs cas. Également, si vous utilisez un système tiers pour les adresses, c’est même indispensable pour avoir le même format pour toutes les entrées. Enfin, on remplacera le champ « adresse » dans la table ici présente par le champ « id_adresse » qui fera référence à l’entrée correspondante dans la table « adresse« .

Simple non ? Qu’en dites-vous ?

La deuxième forme normale – 2NF

La 2NF est déjà un peu plus technique et peut sembler plus abstraite que la seconde. Sachez, que pour être 2NF, il faut auparavant être 1NF compliant.

Ici, vous pouvez voir une table qui fait le lien entre des commandes et les produits contenus dans ces commandes. La clé primaire est composée des deux champs id_commande et id_produit.

La commande 1 et 2 contiennent le même produit, ID 1. On peut y voir la même description produit. (Normal vous me direz, c’est le même produit…). Outre la redondance d’informations inutiles, on remarque surtout que le champ « description_produit » dépend de l’id_produit mais pas du tout de id_commande. On a une dépendance fonctionnelle avec seulement une partie de la clé primaire, ce n’est pas bon !

Les attributs (colonnes) de cette table doivent être dépendant de l’entièreté de la clé primaire et non seulement d’une partie.

Pour corriger ça, c’est assez simple. Il fait retirer la colonne description_produit de cette table et laisser les deux champs id_commande et id_produit. Dans une autre table, avec en clé primaire l’id_produit, vous mettez la description_produit. Ainsi, vous avez deux tables, où il n’y a aucune redondance des données. Si la description du produit change, elle sera modifiée partout.

La troisième forme normale – 3NF

De la même manière que pour être 2NF, il faut être 1NF; pour être 3NF, il faut être 2NF.

Ce point est encore plus abstrait que le précédent mais c’est le dernier que l’on abordera car être 3NF est suffisant dans la plupart des cas. On peut toujours aller plus loin, mais déjà tellement peu de base de données 3NF compliant que ce sera déjà pas mal si vous appliquez ces trois premiers principes.

Contre exemple 3NF

Ici, table très simple qui contient les informations de nos produits. Quelque chose vous choque ? La colonne localisation dépend de la colonne catégorie et non de la clé primaire !

Ce genre de schéma peut poser quelques soucis. Dans un premier temps, redondance de données. Ensuite, si votre catégorie change de localisation (entrepôt ou magasin par exemple) ou même de nom, vous devez changer sa localisation et son nom partout. Il peut y avoir d’autres soucis, ce n’est pas exhaustif.

Comment corriger ça ? Rien de plus simple, on ajoute une table categorie et on y met donc un id_categorie, le nom de la catégorie, sa localisation. Ainsi, dans notre table produit, on supprime les champs catégorie et localisation pour la remplacer par une colonne id_categorie.

Conclusion

Comme je l’ai dis plus haut, il existe d’autres formes normales pour les base de données relationnelles. Ces trois premières formes sont une bonne étape à franchir afin d’avoir des bases de données saines et cohérentes sur la durée. Il faut y penser dès la conception de votre application, site web ou tout autre projet car un schéma de base de données est très compliqué à modifier sur une base de données déjà remplies, il y a souvent de la casse.

Aujourd’hui, avec l’avènement des ORM et compagnie, j’ai l’impression qu’on perd un peu cette étape de conception de la base de données qui est bien souvent le cœur de votre projet. C’est regrettable car une base de données mal conçue vous promet de belles péripéties pour les évolutions ou résolutions de bugs à venir.

Également, certaines solutions sortent en version finale en ne respectant pas ces formes normales, inquiétant ! N’hésitez pas à commenter pour en discuter !

Image par mcmurryjulie de Pixabay

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.