Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article explique la terminologie de normalisation des bases de données pour les débutants. Une compréhension de base de cette terminologie est utile lors de la présentation de la conception d’une base de données relationnelle.
Description de la normalisation
La normalisation est le processus d’organisation des données dans une base de données. Il inclut la création de tables et l’établissement de relations entre ces tables conformément aux règles conçues pour protéger les données et rendre la base de données plus flexible en éliminant la redondance et la dépendance incohérente.
Les données redondantes gaspillent l’espace disque et créent des problèmes de maintenance. Si les données qui existent dans plusieurs emplacements doivent être modifiées, les données doivent être modifiées de la même façon dans tous les emplacements. Une modification d’adresse client est plus facile à implémenter si ces données sont stockées uniquement dans la table Customers et nulle part ailleurs dans la base de données.
Qu’est-ce qu’une « dépendance incohérente » ? Bien qu’il soit intuitif pour un utilisateur de regarder dans la table Customers pour l’adresse d’un client particulier, il peut ne pas être judicieux de rechercher le salaire de l’employé qui appelle ce client. Le salaire de l’employé est lié à l’employé ou en dépend, et doit donc être déplacé vers la table des Employés. Les dépendances incohérentes peuvent rendre les données difficiles à accéder, car le chemin d’accès à la recherche des données peut être manquant ou rompu.
Il existe quelques règles pour la normalisation de la base de données. Chaque règle est appelée « forme normale ». Si la première règle est observée, la base de données est dite « première forme normale ». Si les trois premières règles sont observées, la base de données est considérée comme « de troisième forme normale ». Bien que d’autres niveaux de normalisation soient possibles, le troisième formulaire normal est considéré comme le niveau le plus élevé nécessaire pour la plupart des applications.
Comme 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 nécessite des tables supplémentaires et certains clients trouvent cela fastidieux. Si vous décidez de violer l’une des trois premières règles de normalisation, assurez-vous que votre application prévoit tous les problèmes susceptibles de se produire, tels que les données redondantes et les dépendances incohérentes.
Les descriptions suivantes incluent des exemples.
Première forme normale
- Éliminez les groupes répétés dans les tables individuelles.
- Créez une table distincte pour chaque jeu de données associées.
- Identifiez chaque jeu de données associées avec une clé primaire.
N’utilisez pas plusieurs champs dans une table unique pour stocker des données similaires. Par exemple, pour suivre un élément d’inventaire qui peut provenir de deux sources possibles, un enregistrement d’inventaire peut contenir des champs pour le code du fournisseur 1 et le code du fournisseur 2.
Que se passe-t-il quand vous ajoutez un troisième fournisseur ? L’ajout d’un champ n’est pas la réponse ; il nécessite des modifications de programme et de table et ne prend pas en charge un nombre dynamique de fournisseurs. Au lieu de cela, placez toutes les informations du fournisseur dans une table distincte appelée Fournisseurs, puis liez l’inventaire aux fournisseurs avec une clé de numéro d’élément, ou les fournisseurs à l’inventaire avec une clé de code de fournisseur.
Deuxième formulaire normal
- Créez des tables distinctes pour les ensembles de valeurs qui s’appliquent à plusieurs enregistrements.
- Associez ces tables à une clé étrangère.
Les enregistrements ne doivent pas dépendre d'autre chose que de la clé primaire d'une table (clé composée, si nécessaire). Par exemple, considérez l’adresse d’un client dans un système de comptabilité. L'adresse est requise par la table Customers, mais également par les tables Commandes, Expéditions, Factures, Comptes à recevoir et Regroupements. Au lieu de stocker l’adresse du client en tant qu’entrée distincte dans chacune de ces tables, stockez-la à un emplacement unique, dans la table Customers ou dans une table Adresses distincte.
Troisième forme normale
- Éliminez 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 être dans la table. En général, chaque fois que le contenu d’un groupe de champs peut s’appliquer à plus d’un enregistrement unique dans la table, envisagez de placer ces champs dans une table distincte.
Par exemple, dans un tableau de recrutement de personnel, le nom et l'adresse de l'université d'un candidat peuvent être inclus. Mais vous avez besoin d’une liste complète des universités pour les publipostages de groupe. Si les informations universitaires sont stockées dans la table Candidats, il n’existe aucun moyen de répertorier les universités sans candidats actuels. Créez une table Universités distincte et liez-la à la table Candidates avec une clé de code universitaire.
EXCEPTION : L’adhésion à la troisième forme normale, bien que théoriquement souhaitable, n’est pas toujours pratique. Si vous avez une table de clients et que vous souhaitez éliminer toutes les dépendances entre champs possibles, vous devez créer des tables distinctes pour les villes, les codes postaux, les représentants commerciaux, les classes de clients et tout autre facteur susceptible d’être dupliqué dans plusieurs enregistrements. En théorie, la normalisation vaut la peine de poursuivre. Toutefois, de nombreuses petites tables peuvent dégrader les performances ou dépasser les capacités de fichier et de mémoire ouvertes.
Il peut être plus possible d’appliquer un troisième formulaire normal uniquement aux données qui changent fréquemment. Si certains champs dépendants restent, concevez votre application pour demander à l’utilisateur de vérifier tous les champs associés lorsqu’un champ est modifié.
Autres formes de normalisation
Quatrième forme normale, également appelée Boyce-Codd formulaire normal (BCNF), et cinquième formulaire normal existent, mais sont rarement considérés dans la conception pratique. Ignorer ces règles peut entraîner une conception de base de données inférieure à parfaite, mais ne doit pas affecter les fonctionnalités.
Normalisation d’un exemple de table
Ces étapes illustrent le processus de normalisation d'un tableau d'étudiants fictif.
Table nonnormalisée :
Étudiant# Conseiller Adv-Room Classe1 Class2 Class3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Première forme normale : aucun groupe répétitif
Les tables ne doivent avoir que deux dimensions. Étant donné qu’un étudiant possède plusieurs classes, ces classes doivent être répertoriées dans un tableau distinct. Les champs Class1, Class2 et Class3 dans les enregistrements ci-dessus sont des indications de problèmes de conception.
Les feuilles de calcul utilisent souvent la troisième dimension, mais les tables ne doivent pas. Une autre façon d'aborder ce problème est d'utiliser une relation un-à-plusieurs : ne combinez pas le côté unique et les côtés multiples dans la même table. Au lieu de cela, créez une autre table dans la première forme normale en éliminant le groupe répétitif (Class#), comme illustré dans l’exemple suivant :
Étudiant# Conseiller Adv-Room Classe # 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Deuxième formulaire normal : Éliminer les données redondantes
Notez les valeurs Class# multiples pour chaque valeur Student# dans le tableau ci-dessus. Class# n’est pas fonctionnellement dépendant de Student# (clé primaire), donc cette relation n’est pas sous la deuxième forme normale.
Les tableaux suivants illustrent la deuxième forme normale :
Étudiants:
Étudiant# Conseiller Adv-Room 1022 Jones 412 4123 Smith 216 Inscription:
Étudiant# Classe# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Troisième formulaire normal : Éliminer les données qui ne dépendent pas de la clé
Dans le dernier exemple, Adv-Room (numéro de bureau du conseiller) dépend fonctionnellement de l’attribut Advisor. La solution consiste à déplacer cet attribut de la table Students vers la table Faculty, comme indiqué ci-dessous :
Étudiants:
Étudiant# Conseiller 1022 Jones 4123 Smith Faculté:
Nom Salle Département Jones 412 42 Smith 216 42