Attention aux clés artificielles

Fondamental

  • en UML : on ne pose jamais de clés artificielles

  • en relationnel : on pose rarement des clé artificielles sauf dans le cas de clés étrangères vraiment trop compliquées

  • en SQL : on peut poser des clés artificielles si on a une bonne raison (ce n'est donc pas systématique, et c'est à justifier)

Clés artificielles et niveau conceptuel

On n'ajoutera pas de clé artificielle en UML au moment de la modélisation conceptuelle des données.

  1. Formellement en UML la notion de clé n'existe pas (contrairement à l'E-A[1]), elle est ajoutée par les pratiquants des BD[2].

  2. Logiquement on a pas besoin de cette notion en UML, les clés artificielles servent en relationnel et dans certains cas uniquement.

  3. Pratiquement cela peut conduire à des situations absurdes (comme enlever au niveau logique des clés artificielles ajoutées au niveau conceptuel) :

    • si on fait du non-relationnel on ne doit pas ajouter de clés artificielles dans certains cas (l'imbrication typiquement) ;

    • cela arrive même en relationnel, avec la transformation de l'héritage (dans certains cas toujours).

  4. Méthodologiquement il faut se concentrer à chaque phase sur ce qui est important, donc au moment du MCD on traduit les besoins, on repère les contraintes explicites (clé, unicité, non nullité...) sans se préoccuper de ce qui sera rendu nécessaire par la suite par la modélisation relationnelle (les clés étrangères par exemple) ou l'implémentation (l'optimisation par exemple). À chaque jour suffit sa peine !

  5. Pédagogiquement, enfin, les "débutants" ont tendance (à cause des environnements de conception graphique, comme phpMyAdmin notamment) à systématiser les clés artificielles en SQL (on pourrait en discuter), mais également à ne pas faire le travail de recherche des clés naturelles (au niveau relationnel notamment, ce qui est une faute de modélisation). Donc au plus tard on fait intervenir les clés artificielles, au plus on a une chance de penser aux clés naturelles.

Clés artificielles et optimisation : est-il toujours plus performant d'utiliser des clés artificielles ?

Soit le modèle relationnel suivant :

1
Etu (#id, numEtu...) avec numEtu clé
2
UV (#id, codeUv...) avec codeUv clé
3
Inscriptions (#id, uv=>UV, etu=>Etu) avec (uv,etu) clé

La question qui permet d'afficher la liste des étudiants (numEtu) avec leurs UVs (codeUv) nécessite une jointure à cause des clés artificielles. Un modèle sans ces clés artificielles aurait été plus performant pour répondre à cette question, puisque toutes les informations se trouvent dans la relation Inscriptions.

1
Etu (#numEtu...)
2
UV (#codeUv...)
3
Inscriptions (#uv=>UV, #etu=>Etu)

Conseil

  • Ne soyez pas systématique.

  • Il est en effet fréquent dans un projet réel d'adopter des clés artificielles presque systématiquement, vous pourrez le faire en connaissance de cause quand vous aurez bien compris pourquoi c'est intéressant et quand ça ne l'est pas.

  • Les clés artificielles sont intéressantes pour autre chose que les performances (l'évolutivité par exemple, choisissez-les quand vous savez pourquoi).

  • Les clés artificielles ne dispensent pas de rechercher les clés naturelles !

  • Les clés artificielles ne sont pas la seule façon d'optimiser une base de données (indexation, dénormalisation...)