La normalisation

Dans la pratique, il n'est malheureusement pas suffisant de répartir les données dans quelques tables. Il faut d'abord savoir quelles sont les données qui vont dans tel ou tel table... et ceci répond à des règles de jeux précises.

Il existe 5 - 6 règles appellées "formes de normalisation". Dans les bases de données ont utilise les 3 principales qui sont généralement suffisantes. Ces règles sont formulées dans un langage assez obscur pour le commun des mortels, de sorte que nous allons exprimer cela de façon plus simplifiée (éventuellement même approximative). Inutile d'augmenter la difficulté.

Avertissement:

Tout ne sera peut-être pas compris à la première lecture, ceci n'étant pas dû à un manque d'intelligence... mais plutôt au coté abstrait du sujet!

Le fait de se sentir sensibilisé au problème en se disant "Sapristi, je peux faire beaucoup d'erreurs si je ne tiens pas compte de la modélisation et la normalisation" est déjà un premier pas important.

La mise en oeuvre de ces règles est alors une toute autre histoire et qui demande beaucoup de temps. Et ce temps, il faut absolument le prendre et ne jamais se mettre (ou se laisser mettre) la pression.

Place au plus difficile...

Première forme normale (1FN)

On dit qu'une relation est en 1FN si tous les attributs qui la compose sont atomique.

En langage courant: Tous les champs d'une table doivent être tel pour qu'ils ne soient plus décomposables

Exemple 1 :

Il existe un champ "Adresse" dans une table. Il ne serait pas correct, car "Adresse" peut encore être scindée (par exemple en nom, prénom, rue, code postal, ville...)

Exemple 2 :

De mauvaises saisies peuvent-être réalisées dans des tables dont les champs semblent correctement nommés.

Admettons une entreprise qui possède sa cantine et dont les tables sont numérotées (table 1, table 2, etc.)

• A chaque table sont assis des employés qui possèdent leur numéro personnel, NumPerso (monsieur Durant à le numéro 12, madame Dupont le 56, Leroy le 36 et madame Lafille le 73)
• Chaque personne choisit son menu
• La table possède les champs "NoTable", "NumPerso", "Menu"

Deuxième forme normale (2FN)

On dit qu'une relation est en 2FN si elle est en 1FN et si toutes les dépendances fonctionnelles entre la clé et les autres attributs sont élémentaires.

En langage courant : Restons dans notre précédent exemple 2 et supposons qu'en plus du numéro de table il existe une autre appellation pour qu'un nouveau serveur puisse s'y retrouver plus simplement.

Dans ce cas, la table suivante ne serait pas correcte :

Réflexions suivantes :

• Aucun des champs de cette table n'est un candidat pour être clé primaire, car nous constatons facilement que les trois autres n'en ont pas une totalement dépendance fonctionnelle.
• Le menu a toutefois une totale dépendance fonctionnelle d'une combinaison des champs NoTable et NumPerso. Car, malgré trois commandes du menu viande, dont 2 fois à la même table, cette combinaison du NoTable et du NumPerso conduit à une unicité (1/12, 1/56, 1/36).
  
  Cette combinaison est donc candidat à être clé primaire !!!
  
  En partant du principe que nous créons une table qui n'est destiné qu'à un seul repas, nous pouvons constater qu'aucune combinaison de Table et NumPerso ne peut créer de doublon. Lors du repas du soir ou du lendemain, les mêmes personnes pourraient s'assoir à la même table, nous devrions alors ajouter un champ date et/ou heures et - pour retrouver l'unicité - les ajouter à cette combinaison de Table et NumPerso. Mais ne compliquons pas de trop...
• Qu'en est-il de ce champ "Endroit" ?
  Ce champ Endroit n'est en relation qu'avec la table et donc son numéro, mais non avec la personne et son NumPerso. Ainsi, le champ Endroit n'est pas en relation avec la clé combinée (NoTable + NumPerso) mais uniquement avec une partie de celle-ci (le numéro de table).
  Donc, Endroit n'est en aucun cas candidat à être clé primaire, n'ayant même pas de totale dépendance fonctionnelle du candidat déjà cité (NoTable + NumPerso).
• De ce fait, cette table ne répond pas à la seconde forme normale et doit être modifiée en la scindant (les deux tables seront remises en forme par relation via le champ NoTable).

• Par la même occasion, nous nous créons un nouvel avantage : nous empêchons la redondance (la saisie multiple et inutile de certaines données), car la dénomination "A l'entrée" et "Fenêtre" n'existe plus qu'une seule fois dans une table séparée et ne sont plus représenté que par leur numéro de table.

Troisième forme normale (3FN)

On dit qu'une relation est en 3FN si elle est en 2FN et si toutes les dépendances fonctionnelles entre la clé et les autres attributs sont élémentaires et directes.

En langage courant : Il ne peut y avoir de dépendance fonctionnelle entre les champs non-clé primaire. Ils ne peuvent être dépendant que de la clé primaire. C'est le cas dans l'exemple ci-dessus. Il est inutile de les modier.

Ajoutons un champ supplémentaire, le prix :

Nous obtenons maintenant une situation similaire au cas "Endroit" :

• Le Prix est dépendant du Menu, alors que Menu n'est pas clé primaire. Il apparaît à nouveau de la redondance, car le Prix du Menu est saisi trois fois (et devrait également être modifié trois fois s'il se produit une augmentation ou une baisse).
• Menu est encore dépendant de la clé primaire (NoTable + NumPerso), alors que Prix n'est qu'indirectement lié à cette clé primaire.

Cela ne peut être et demande une nouvelle scission de la table :

<<< Page précédente - Page suivante >>>