Clé primaire multichamp

Yves MARCOUX - EBSI - Université de Montréal

Voici un exemple de cas où une clé primaire multichamp est non seulement naturelle, mais entraîne même des bénéfices intéressants.

Une table doit contenir de l'information sur des cours offerts à l'Université de Montréal. Les sigles de cours sont composés de trois lettres indiquant la discipline et d'un numéro unique à l'intérieur de la discipline. La discipline n'est une information redondante ni avec le département (l'EBSI offre des cours en ARV, SCI et INU), ni avec le programme (au moins deux programmes différents comprennent des cours obligatoires en INU). On ne peut donc pas la laisser tomber.

Deux alternatives s'offrent: stocker le sigle au complet en un seul champ et en faire la clé primaire, ou encore scinder la discipline et le numéro unique et faire de la combinaison de ces deux champs la clé primaire. La seconde alternative a un avantage, c'est de permettre de faire du champ "Discipline" une clé externe vers une table éventuelle qui donnerait de l'information sur les disciplines en tant que telles (par exemple, les intitulés en plusieurs langues, une courte description, des pointeurs vers des ressources définitoires en ligne, etc.). L'existence de cette relation de clé externe permet une meilleure validation des codes de disciplines saisis. Cette structure permet en outre l'expression d'une condition de jointure beaucoup plus naturelle entre les cours et les disciplines, rendant par le fait même, et par exemple, beaucoup plus aisée la formulation de recherches de cours sur des critères de disciplines (exemple, cours appartenant à la discipline dont l'intitulé contient la chaîne "archiv").

Notons que l'avantage n'est pas vraiment au niveau de la recherche par code de discipline, puisqu'on peut aussi effectuer ce type de recherche dans le premier cas, en utilisant la troncature.