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.
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. Chaque règle est appelée une « forme normale ». Si la première règle est respectée, la base de données est dite « en première forme normale ». Si les trois premières règles sont respectées, la base de données est 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 le niveau le plus élevé nécessaire pour la plupart des applications.
Comme c’est le cas avec de nombreuses règles et spécifications formelles, les scénarios réels ne permettent 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 l’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 fournisseur 1 et le code 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 à un nombre dynamique de fournisseurs. En lieu et place, 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 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 distincte.
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 n’ont pas leur place 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, envisagez de déplacer 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. Vous devez toutefois 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 imparfaite, sans toutefois nuire à ses performances.
Normalisation d’un exemple de table
Les étapes suivantes démontrent le processus de normalisation d’une table d’étudiants fictive.
Table non normalisée :
N° d’étudiant Conseiller Salle-Conseiller Cours1 Cours2 Cours3 1022 Legros 412 101-07 143-01 159-02 4123 Lopez 216 101-07 143-01 179-04 Première forme normale : aucun groupe répétitif
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. En lieu et place, 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 :
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 101-07 4123 Lopez 216 143-01 4123 Lopez 216 179-04 Deuxième forme normale : éliminer les données redondantes
Notez les valeurs multiples N° de cours pour chaque valeur 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 tables suivantes démontrent la deuxième forme normale :
Étudiants :
N° d’étudiant Conseiller Salle-Conseiller 1022 Legros 412 4123 Lopez 216 Inscription :
N° d’étudiant N° de cours 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 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 :
N° d’étudiant Conseiller 1022 Legros 4123 Lopez Faculté :
Nom Room Département Legros 412 42 Lopez 216 42