Principes de base de la normalisation des bases de données

Cet article explique la terminologie de normalisation des bases de données pour les utilisateurs débutants. Une connaissance élémentaire de cette terminologie est utile lors de la discussion de la structure d'une base de données relationnelle.

REMARQUE : Microsoft propose également une présentation technique en ligne abordant les principes de base de la normalisation des bases de données. Pour afficher cette présentation technique en ligne, reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) :

Description de la normalisation

La normalisation correspond au processus d'organisation des données dans une base de données. Ce processus comprend la création de tables et l'établissement de relations entre celles-ci conformément à des règles conçues à la fois pour protéger les données et pour rendre la base de données plus flexible grâce à l'élimination de la redondance et des dépendances incohérentes.

Les données redondantes entraînent un gaspillage d'espace disque et créent des problèmes de maintenance. Lorsque des données existant en plusieurs endroits doivent être modifiées, elles doivent l'être exactement de la même façon dans tous ces emplacements. Une modification d'adresse de client est beaucoup plus facile à implémenter lorsque ces données sont stockées dans la table Clients et nulle part ailleurs dans la base de données.

Qu'est-ce qu'une « dépendance incohérente » ? Bien qu'il puisse être intuitif pour un utilisateur de rechercher dans la table Clients l'adresse d'un client donné, il ne serait pas très logique d'y rechercher le salaire de l'employé chargé du dossier de ce client. Le salaire de l'employé est lié à (ou dépend de) l'employé et doit par conséquent être déplacé dans la table Employés. Les dépendances incohérentes peuvent rendre l'accès aux données plus difficile car le chemin d'accès à ces données peut être manquant ou rompu.

Il existe plusieurs règles de normalisation des bases de données. Ces règles sont connues sous le nom de « formes normales ». Si la première règle est respectée, la base de données sera considérée comme étant en « première forme normale ». Si les trois premières règles sont respectées, la base de données sera considérée comme étant en « troisième forme normale ». Bien que d'autres niveaux de normalisation soient possibles, la troisième forme normale est considérée comme étant le niveau le plus élevé nécessaire à la plupart des applications.

Comme c'est le cas avec de nombreuses règles et spécifications formelles, les scénarios du monde réel n'autorisent pas toujours une conformité parfaite. En général, la normalisation exige des tables supplémentaires, ce qui peut être incommode aux yeux de certains clients. Si vous décidez d'enfreindre une des trois premières règles de normalisation, assurez-vous que votre application anticipe les problèmes pouvant survenir, tels que la présence de données redondantes ou de dépendances incohérentes.

Les descriptions suivantes incluent des exemples.

Première forme normale

• Éliminer la répétition de groupes dans les différentes tables.
• Créer une table distincte pour chaque jeu de données connexes.
• Identifier chaque jeu de données connexes à l'aide d'une clé primaire.

Ne pas utiliser plusieurs champs d'une même table pour stocker des données semblables. Par exemple, pour assurer le suivi d'un article en stock pouvant provenir de deux sources différentes, un enregistrement de stock peut contenir des champs pour le Code de fournisseur 1 et le Code de fournisseur 2.

Que se passe-t-il lorsque vous ajoutez un troisième fournisseur ? Ajouter un champ ne constitue pas la bonne solution. Cela exige des modifications de programme et de table et ne convient pas parfaitement à une quantité dynamique de fournisseurs. Au lieu de cela, vous devez placer toutes les informations relatives aux fournisseurs dans une table distincte nommée Fournisseurs, puis lier le stock aux fournisseurs à l'aide d'une clé de numéro d'article ou lier les fournisseurs au stock à l'aide d'une clé de code de fournisseur.

Deuxième forme normale

• Créer des tables distinctes pour les jeux de valeurs qui s'appliquent à plusieurs enregistrements.
• Établir une relation entre ces tables à l'aide d'une clé étrangère.

Les enregistrements ne doivent dépendre que de la clé primaire d'une table (une clé composée, si nécessaire). Par exemple, prenons l'adresse d'un client dans un système de comptabilité. L'adresse est nécessaire à la table Clients, mais aussi aux tables Commandes, Expédition, Factures, Comptes clients et Encaissement. Au lieu de stocker l'adresse du client en tant qu'entrée distincte dans chacune de ces tables, stockez-la dans un emplacement, soit dans la table Clients, soit dans une table Adresses séparée.

Troisième forme normale

• Éliminer les champs qui ne dépendent pas de la clé.

Les valeurs d'un enregistrement qui ne font pas partie de la clé de cet enregistrement ne devraient pas se trouver dans la table. En général, dès lors que le contenu d'un groupe de champs peut s'appliquer à plusieurs enregistrements de la table, vous devez envisager le déplacement de ces champs dans une autre table.

Par exemple, dans une table Recrutement des employés, le nom et l'adresse de l'université d'un candidat peuvent être inclus. Mais vous devez posséder une liste complète des universités pour le publipostage. Si les informations relatives aux universités sont stockées dans la table Candidats, il n'y a aucun moyen de dresser la liste des universités ne possédant pas de candidat actuellement. Créez une table Universités distincte et liez-la à la table Candidats avec une clé de code d'université.

EXCEPTION : le respect de la troisième forme normale, bien que théoriquement souhaitable, n'est pas toujours réalisable. Si vous possédez une table Clients et souhaitez éliminer toutes les dépendances interchamps possibles, vous devez créer des tables distinctes pour les villes, les codes postaux, les représentants de commerce, les classes de clientèle et tout autre facteur pouvant être dupliqué dans plusieurs enregistrements. En théorie, la normalisation est un objectif louable. Toutefois, la présence de nombreuses petites tables peut amoindrir les performances ou excéder les capacités mémoire ou de fichiers ouverts.

Il sera sans doute plus faisable d'appliquer la troisième forme normale uniquement aux données qui changent fréquemment. S'il reste des champs dépendants, concevez votre application de sorte que l'utilisateur doive vérifier tous les champs connexes lorsque l'un d'entre eux est modifié.

Autres formes de normalisation

Il existe une quatrième forme normale, également nommée Boyce Codd Normal Form (BCNF) et une cinquième forme normale, mais elles sont rarement prises en compte en pratique. Le non-respect de ces règles peut engendrer une structure de base de données moins que parfaite, mais la fonctionnalité de la base de données ne devrait pas en souffrir.

Normalisation d'un exemple de table

Les étapes suivantes démontrent le processus de normalisation d'une table d'étudiants fictive.

1. Table non normalisée :
   
   
   Réduire ce tableauAgrandir ce tableau

   N° d'étudiant	Conseiller	Salle-Conseiller	Cours1	Cours2	Cours3
   1022	Legros	412	101-07	143-01	159-02
   4123	Lopez	216	201-01	211-02	214-01

2. Première forme normale : aucune répétition de groupe
   
   Les tables ne doivent avoir que deux dimensions. Un étudiant ayant plusieurs cours, trois cours doivent être répertoriés dans une table distincte. Les champs Cours1, Cours2 et Cours3 des enregistrements ci-dessus sont l'indication d'un problème conceptuel.
   
   Les feuilles de calcul utilisent souvent la troisième dimension, mais les tables ne le doivent pas. Une autre manière d'analyser ce problème est de l'envisager comme une relation un-à-plusieurs ; vous ne devez pas placer le côté un et le côté plusieurs dans la même table. Au lieu de cela, créez une autre table en première forme normale en éliminant le groupe répété (N° de cours), tel qu'illustré ci-dessous :
   
   
   Réduire ce tableauAgrandir ce tableau

   N° d'étudiant	Conseiller	Salle-Conseiller	N° de cours
   1022	Legros	412	101-07
   1022	Legros	412	143-01
   1022	Legros	412	159-02
   4123	Lopez	216	201-01
   4123	Lopez	216	211-02
   4123	Lopez	216	214-01

3. Deuxième forme normale : éliminer les données redondantes
   
   Notez les valeurs multiples de N° de cours pour chaque valeur de N° d'étudiant dans la table ci-dessus. N° de cours ne dépend pas fonctionnellement de N° d'étudiant (clé primaire) ; cette relation n'est donc pas en deuxième forme normale.
   
   Les deux tables suivantes démontrent la deuxième forme normale :
   
   Étudiants :
   
   
   Réduire ce tableauAgrandir ce tableau

   N° d'étudiant	Conseiller	Salle-Conseiller
   1022	Legros	412
   4123	Lopez	216

   
   
   Inscription :
   
   
   Réduire ce tableauAgrandir ce tableau

   N° d'étudiant	N° de cours
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. Troisième forme normale : éliminer les données qui ne dépendent pas de la clé
   
   Dans le dernier exemple, Salle-Conseiller (le numéro du bureau du conseiller) dépend de manière fonctionnelle de l'attribut Conseiller. La solution consiste à déplacer cet attribut de la table Étudiants à la table Faculté, tel qu'illustré ci-dessous :
   
   Étudiants :
   
   
   Réduire ce tableauAgrandir ce tableau

   N° d'étudiant	Conseiller
   1022	Legros
   4123	Lopez

   
   
   Faculté :
   
   
   Réduire ce tableauAgrandir ce tableau

   Nom	Salle	Département
   Legros	412	42
   Lopez	216	42