L'avantage d'une base de données relationnelle est d'éviter au maximum les répétitions ou les redondances d'information. Cela implique que les données sont séparées en plusieurs tables. Des relations entre celles-ci permettent d’avoir une base de données qui est plus efficace. La normalisation sert à s’assurer que les champs sont dans les bonnes tables. Il s’agit de vérifier leur emplacement et le contenu des champs et possiblement de trouver des tables qui n’avaient pas encore été découvertes. Les tests sont appelés des formes normales (1ère, 2ième, 3ième ...) Pour le moment, nous allons seulement regarder les trois premières formes normales.
Pour atteindre la première forme normale, il faut s’assurer qu’il y a seulement une valeur à l’intérieur de chaque champ. Par exemple, vous ne pouvez pas avoir un champ nommé « Nom » dont le contenu est « Jean Richard ». Pouvez-vous me dire quel est le nom de famille et quel est le prénom ? Le travail à accomplir pour atteindre la première forme normale est de s’assurer qu’il y a seulement une valeur possible par champs. Dans ce cas, on restructure la table pour avoir un champ « Nom » et « Prénom ». Une valeur = un champ. Il faut éviter complètement les répétitions d'entrée de données à l’intérieur d’un champ.
Comme autre exemple, une facture peut contenir plusieurs produits.
Numéro de facture |
Numéro de produit |
1 |
1, 3, 5 |
2 |
2, 3 |
3 |
1, 2, 5 |
Selon cet exemple, il peut avoir plusieurs numéros de produits pour une même facture. Cette structure n’est pas optimale pour une base de données relationnelle. Ceci est de la redondance et ce n'est pas une forme appropriée pour conserver de l'information dans une base de données relationnelle. Comment fera-t-on ensuite pour relier une modification au bon produit? Il faut donc mettre Numéro de produit dans une table autre que Facture. On peut en même temps déplacer les champs similaires dans l'autre table.
Reprenons l’exemple de la page sur le diagramme entité-association et du schéma relationnel qui analyse les données d’une facture de location de véhicules. Il y a plusieurs « entité » ou tables qui y sont reliées. Parmi celles-ci, il y a une relation plusieurs à plusieurs (N-M) entre les tables Facture et Véhicule. Une facture peut contenir plusieurs véhicules et un véhicule peut se retrouver sur plusieurs factures.
Une table intermédiaire nommée Item permet de régler la relation N-M entre ces tables. Item a une clé primaire composée des clés primaires des deux tables mentionnées. La deuxième forme normale (2FN) s’assure que tous les champs de cette table dépendent de toutes les composantes de la clé primaire composée et non juste d’une partie.
Les champs ITEM_Km_début, ITEM_km_fin, ITEM_date_début et ITEM_date_fin dépendent d’une facture en particulier pour un véhicule précis au moment de la location. Ces informations seront différentes pour une autre facture ou pour un autre véhicule.
Pour respecter la deuxième forme normale, on ne peut pas y inclure un champ tel que VÉHICULE_Description puisque cette information est spécifique au véhicule et non à la facture. Cela ne répond pas au critère ou tout champ de la table doit être associé à toutes les composantes de la clé primaire composée; FACTURE_No et VÉHICULE_No dans ce cas. Le champ EMPLOYÉ_No n’aurait aussi pas sa place puisqu’il n’est pas associé ni a l’une ou l’autre des composantes de la clé primaire composée.
Je vous rappelle que cette règle s’applique seulement aux tables ayant une clé primaire composée. Si vous analysez une table ayant une clé primaire composée d’un seul champ, vous pouvez passer directement à la troisième forme normale (3FN).
Le test de la troisième forme normale est de s’assurer que tous les champs de la table dépendent de la clé primaire. Si vous avez un cas comme celui-ci :
Les champs EMPLOYÉ_Nom et EMPLOYÉ_Prénom ne devraient pas être dans la table Facture. Ces champs ne sont pas associés à la clé primaire Facture_No.
Si vous n’aviez pas encore déterminé que la table Employé était requise, ce test vous a permis de le faire. Remarquez que vous allez « ressortir » des tables inconnues avec ce test. Vous devez vérifier chaque champ de la table pour voir si vous pouvez l’associer à la clé primaire.
Vous pourriez croire que le champ CLIENT_No aussi n’est pas associé à la clé primaire FACTURE_No. En fait, elle a une autre mission. Elle permet de relier la table Client à la table Facture. Il s’agit d’une clé externe. Donc, revenus sur la définition du test de la troisième forme normale : « s’assurer que tous les champs de la table, SAUF les clés externes, dépendent de la clé primaire. » Les champs CLIENT_No et EMPLOYÉ_No sont des clés externes dans la table Facture pour permettre une relation aux autres tables.