Formation PUB220 : Modélisation de données, 2018 La normalisation

5.3 Pourquoi la clé primaire doit-elle être un numéro qui ne sert qu'à ça ?


La clé primaire, c'est l'information qui sera stockée dans la clé étrangère d'une autre table pour matérialiser une relation entre ces deux tables.

Par exemple, pour gérer les abonnements des usagers dans une application de formation en ligne, on aura une table formations et une table usagers avec une relation de plusieurs à plusieurs entre les deux.

Cette relation sera matérialisée, dans le schéma logique de données, par une table pivot abonnements. La table pivot contiendra une clé étrangère vers la table usagers et une autre vers la table formations.

Schéma logique usagers formations

Si on désire abonner l'usager toto à la formation modélisation de données, on ajoutera un enregistrement dans la table des abonnements. Dans cet enregistrement, la clé étrangère usager_id contiendra la valeur de la clé primaire de toto.

Dans cet exemple, l'identifiant de l'usager est un champ nommé id qui contient un nombre dont la valeur est unique dans la table. Ce nombre n'a pas de sens en soi et c'est ce que nous voulons. Le rôle de la clé primaire consiste à identifier chaque enregistrement de façon unique et établir des liens entre les enregistrements de différentes tables, et rien d'autre.

Utiliser le code d'usager comme clé primaire ? Mauvaise idée !

Certaines personnes pourraient être tentées d'utiliser le code de l'usager comme clé primaire. Après tout, ce champ contient une information dont la valeur est unique dans la table. Il permet donc d'identifier chaque enregistrement de façon unique.

Mauvais choix de clé primaire

Ceci est une mauvaise idée. Voici un exemple vécu qui illustre ce qui peut arriver si la clé primaire est un champ dont la valeur a un sens, par exemple le code d'usager.

Dans la toute première version d'Apical, en 2008, la clé primaire de la table usagers était le code d'usager. Lorsqu'on abonnait un usager à une formation, c'était le code d'usager qui était stocké dans la clé étrangère de la table pivot. Par exemple, pour abonner l'usager toto à la formation modélisation de données, on stockait la valeur toto dans la clé étrangère. Vous imaginez que la clé primaire était utilisée dans une foule d'autres relations, par exemple pour relier un usager avec un commentaire.

Le problème de ce mode de fonctionnement est apparu le jour où toto a voulu changer son code d'usager. Cette opération était impossible car cela aurait impliqué de changer la valeur des clés étrangères dans toutes les tables impliquées.

Comme le besoin était important, les modifications ont été apportées dans Apical. Voici ce que cette erreur de modélisation a causé :

  • 3 jours de programmation
  • une journée entière de tests
  • 13 tables modifiées (structure et données)
  • 23 programmes modifiés
  • 14 procédures stockées modifiées
N'aurait-il pas été plus simple de bien modéliser la base de données dès le départ ?

 

▼Publicité

Veuillez noter que le contenu de cette fiche vous est partagé à titre gracieux, au meilleur de mes connaissances et sans aucune garantie.
Merci de partager !
Soumettre