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

Utilisateurs débutants : Cet article requiert des connaissances de l'interface utilisateur des ordinateurs à utilisateur unique.

Cet article fournit les bases de la terminologie de la normalisation des bases de données. Il est souhaitable de posséder des connaissances de base dans cette terminologie lors de la conception d'une base de données relationnelle.

Description de la normalisation

La normalisation est le processus par lequel les données sont organisées dans une base de données. Ceci comprend la création de tables et l'établissement de relations entre ces tables selon certaines règles. Ces règles sont conçues pour protéger les données et rendre l'utilisation de la base de données plus souple en éliminant deux facteurs : la redondance et la dépendance incohérente.

La redondance de données gaspille de l'espace disque et crée des problèmes de maintenance. Si des données existant à plus d'un emplacement doivent être modifiées, il est nécessaire qu'elles le soient de la même manière à chacun de ces emplacements. Il est beaucoup plus facile de prendre en compte la modification d'une adresse client si cette donnée n'est enregistrée que dans la table Clients et à aucun autre emplacement dans la base de données.

Qu'est-ce qu'une " dépendance incohérente" ? Alors qu'il serait naturel pour l'utilisateur de chercher l'adresse d'un client dans la table Clients, il ne penserait pas à y chercher le salaire de l'employé qui rend visite à ce client. Son salaire est lié à (ou dépendant de) l'employé lui-même, et devrait donc être enregistré dans la table Employés. Des dépendances incohérentes peuvent compliquer l'accès aux données ; le chemin de ces données peut être manquant ou interrompu.

Il y a quelques règles à suivre pour normaliser une base de données. Ces règles sont connues sous le nom de " formats de normalisation ". Si la première règle est respectée, la base de données sera considérée comme étant en " premier format de normalisation ". Si les trois premières règles sont respectées, la base de données sera considérée comme étant en " troisième format de normalisation ". Bien que d'autres niveaux de normalisation soient possibles, le troisième format de normalisation est considéré comme étant le niveau le plus élevé nécessaire à la plupart des applications.

Comme pour beaucoup de règles et de spécifications formelles, vous ne pourrez pas toujours atteindre la conformité parfaite dans une situation réelle. En général, la normalisation nécessite des tables supplémentaires et est considérée comme trop fastidieuse par certains clients. Si vous décidez de violer l'une des trois premières règles de normalisation, assurez-vous que votre application anticipe tous les problèmes qui pourraient en découler, tels que des données redondantes ou des dépendances incohérentes.

REMARQUE : Les descriptions suivantes comprennent des exemples de normalisation.

Premier format de normalisation

• Éliminez les groupes récurrents dans des tables individuelles.
• Créez une table séparée pour chaque jeu de données liées.
• Identifiez chaque jeu de données liées à l'aide d'une clé primaire.

N'utilisez pas de champs multiples pour enregistrer des données similaires dans une table simple. Par exemple, pour rechercher un élément d'inventaire qui pourrait provenir de deux sources possibles, un enregistrement d'inventaire peut contenir des champs pour Code Vendeur 1 et Code Vendeur 2.

Mais que se passe-t-il lorsque vous ajoutez un troisième vendeur ? L'ajout d'un champ n'est pas la solution ; cette action nécessiterait des modifications de programmes et de tables, et ne s'adapte pas de manière idéale à un nombre dynamique de vendeurs. Enregistrez plutôt toutes les données concernant les vendeurs dans une table séparée nommée Vendeurs, puis liez l'inventaire aux vendeurs à l'aide d'une clé Numéro d'élément, ou inversement les vendeurs à l'inventaire à l'aide d'une clé Code vendeur.

Deuxième format de normalisation

• Créez des tables séparées pour les groupes de valeurs s'appliquant à des enregistrements multiples.
• Reliez ces tables à l'aide d'une clé étrangère.

Les enregistrements doivent dépendre uniquement de la clé primaire d'une table (clé composite si nécessaire). Prenons comme exemple l'adresse d'un client dans un système de comptabilité. L'adresse doit figurer dans la table Clients, mais aussi dans les tables Commandes, Livraisons, Facturation, Comptes clients et Rentrées. Au lieu d'enregistrer l'adresse du client comme entrée séparée dans chacune de ces tables, enregistrez-la à un seul emplacement, dans la table Clients ou dans une table Adresses séparée.

Troisième format de normalisation

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

Les valeurs d'un enregistrement ne dépendant pas de la clé de cet enregistrement ne doivent pas apparaître dans la table. En général, lorsque le contenu d'un groupe de champs s'applique à plus d'un enregistrement dans la table, il est préférable de placer ces champs dans une table séparée.

Par exemple, dans une table Recrutement, il se peut que le nom et l'adresse de l'université d'un candidat soient inclus. Mais vous avez besoin d'une liste complète des universités pour votre publipostage. Si les coordonnées des universités sont enregistrées dans la table Candidats, vous n'avez aucun moyen de les répertorier sans candidats. Créez une table Universités et liez-la à la table Candidats à l'aide d'une clé code université.

EXCEPTION : Quoiqu'en théorie souhaitable, le troisième format de normalisation n'est pas toujours pratique. Si vous disposez d'une table Clients et souhaitez éliminer toutes les dépendances inter-champs possibles, vous devrez créer des tables séparées pour les villes, codes postaux, représentants de commerce, classes de clients et tout autre facteur qui pourrait être dupliqué dans des enregistrements multiples. En théorie, le processus de normalisation vaut la peine d'être poursuivi ; néanmoins un grand nombre de petites tables peut provoquer une diminution des performances, ou dépasser les capacités d'ouverture de fichiers et de mémoire.

Il peut être plus pratique de n'appliquer le troisième format de normalisation qu'aux données modifiées fréquemment. Si quelques champs dépendants persistent, concevez votre application de manière à ce que l'utilisateur ait à vérifier tous les champs liés dès que l'un de ces champs est modifié.

Autres formats de normalisation

Il existe un quatrième format de normalisation, également appelé Format de normalisation Boyce Codd (BCNF), et un cinquième, mais ils sont rarement utilisés dans la pratique. La non-conformité à ces règles peut provoquer des imperfections dans les bases de données, mais sans toutefois affecter leur fonctionnalité.

1. Premier format de normalisation : PAS DE GROUPES RÉCURRENTS
   
   Les tables ne doivent avoir que deux dimensions. Chaque étudiant suivant plusieurs cours, ces cours doivent être répertoriés dans une table séparée. Les champs Cours 1, Cours 2 et Cours 3 dans l'enregistrement ci-dessus sont des indications d'un problème de conception de la table.
   
   La troisième dimension est souvent utilisée pour les tableurs, mais elle n'est pas indiquée pour les tables. Une autre façon de considérer ce problème : Avec une relation un-à-plusieurs, ne placez pas le côté " un " et le côté " plusieurs " dans la même table. Créez plutôt une autre table en premier format de normalisation en éliminant les groupes récurrents (Cours n°), comme suit :

    Étudiant n°   Conseiller   Salle-Conseiller   Cours n°
    -------------------------------------------------------
    1022          Jean           412               101-07
    1022          Jean           412               143-01
    1022          Jean           412               159-02
    4123          Dupont         216               201-01
    4123          Dupont         216               211-02
    4123          Dupont         216               214-01

2. Deuxième format de normalisation : ÉLIMINER LES DONNÉES REDONDANTES
   
   Notez les nombreuses valeurs Cours n° pour chaque valeur Étudiant n° dans la table ci-dessus. Cours n° n'est pas fonctionnellement dépendant de la valeur Étudiant n° (la clé primaire), et donc cette relation n'est pas en second format de normalisation.
   
   Les deux tables suivantes illustrent le second format de normalisation :

    Étudiants :   Étudiant n°   Conseiller   Salle-Conseiller
                  -------------------------------------------
                  1022            Jean         412
                  4123            Dupont       216
   
    Inscription : Étudiant n°   Cours n°
                  ----------------------
                  1022          101-07
                  1022          143-01
                  1022          159-02
                  4123          201-01
                  4123          211-02
                  4123          214-01 

3. Troisième format de normalisation : ÉLIMINER LES DONNÉES QUI NE DÉPENDENT PAS DE LA CLÉ
   
   Dans le dernier exemple, la valeur Salle-Conseiller (le numéro du bureau du conseiller) est fonctionnellement dépendante de l'attribut Conseiller. La solution est de déplacer cet attribut de la table Étudiants vers la table Université, comme indiqué ci-dessous :

    Étudiants :   Étudiant n°   Conseiller
                  ------------------------
                  1022           Jean
                  4123           Smith
   
    Université :  Nom     Salle     Département
                  ---------------------------
                  Jean     412        42
                  Dupont   216        42 

" Guide du développeur FoxPro 2 A ", Hamilton M. Ahlo Jr. et al., pages 220-225, M & T Books, 1991

" Utiliser Access sous Windows ", par Roger Jennings, pages 799-800, Que Corporation, 1993