32
Introduction pratique aux bases de données relationnelles
Les clés
étrangères
traduisent les liens
entre les tables
La clé étrangère (foreign key, en anglais) dans une table est
formée à partir d'un attribut ou d'une concaténation d'attributs qui sert
de clé d'identification de la même table ou d'une table différente. En
d’autres termes, la clé d’identification d’une table doit donc figurer
dans toutes les tables auxquelles elle doit être reliée.
La figure 2-8 illustre l’application des règles 1 et 2 dans un
exemple concret. Les ensembles d'entités, DÉPARTEMENT, EMPLOYÉ
et PROJET, sont traduits en trois tables portant les mêmes noms
respectifs. Nous créons ensuite une table pour chacune des entités de
liens, CHEF DE DÉPARTEMENT, AFFECTATION et APPARTENANCE.
Dans les tables CHEF DE DÉPARTEMENT et AFFECTATION, les clés
étrangères sont le numéro de département et le numéro d'employé. La
table APPARTENANCE utilise les clés d'identification des tables
EMPLOYÉ et PROJET comme clés étrangères, et contient un attribut
supplémentaire appelé «% Participation».
La clé
d’identification
des tables
correspondant aux
ensembles de liens
Étant donné que chaque département est dirigé par un seul chef,
le numéro de département D# suffit pour former la clé d'identification
de la table CHEF DE DÉPARTEMENT. De même, le numéro d'employé
E# suffit pour définir la clé d'identification de la table AFFECTATION,
car chaque employé est affecté à un seul département.
Contrairement aux tables CHEF DE DÉPARTEMENT et
AFFECTATION, la clé d'identification de la table APPARTENANCE doit
être formée par la concaténation de deux clés étrangères : le numéro
d'employé et le numéro du projet. La raison est qu’un employé peut
participer à plusieurs projets, et qu’inversement, un projet peut
impliquer plusieurs employés.
Quand faut-il
définir une table
distincte pour un
ensemble de
liens ?
L'application des règles de passage 1 et 2 ne conduit pas toujours
à un schéma de base de données relationnelle optimal. Selon les
circonstances, elle pourrait engendrer un grand nombre de tables. En
se référant à la figure 2-8, on peut se demander par exemple s'il était
vraiment nécessaire de créer une table distincte pour la fonction de
chef de département. Dans la prochaine section, nous verrons qu'en
vertu de la règle de passage 5, nous renoncerons en fait à créer la table
CHEF DE DÉPARTEMENT. La fonction «Chef de département» sera
intégrée dans la table DÉPARTEMENT tout simplement comme un
Introduction pratique aux bases de données relationnelles
Les clés
étrangères
traduisent les liens
entre les tables
La clé étrangère (foreign key, en anglais) dans une table est
formée à partir d'un attribut ou d'une concaténation d'attributs qui sert
de clé d'identification de la même table ou d'une table différente. En
d’autres termes, la clé d’identification d’une table doit donc figurer
dans toutes les tables auxquelles elle doit être reliée.
La figure 2-8 illustre l’application des règles 1 et 2 dans un
exemple concret. Les ensembles d'entités, DÉPARTEMENT, EMPLOYÉ
et PROJET, sont traduits en trois tables portant les mêmes noms
respectifs. Nous créons ensuite une table pour chacune des entités de
liens, CHEF DE DÉPARTEMENT, AFFECTATION et APPARTENANCE.
Dans les tables CHEF DE DÉPARTEMENT et AFFECTATION, les clés
étrangères sont le numéro de département et le numéro d'employé. La
table APPARTENANCE utilise les clés d'identification des tables
EMPLOYÉ et PROJET comme clés étrangères, et contient un attribut
supplémentaire appelé «% Participation».
La clé
d’identification
des tables
correspondant aux
ensembles de liens
Étant donné que chaque département est dirigé par un seul chef,
le numéro de département D# suffit pour former la clé d'identification
de la table CHEF DE DÉPARTEMENT. De même, le numéro d'employé
E# suffit pour définir la clé d'identification de la table AFFECTATION,
car chaque employé est affecté à un seul département.
Contrairement aux tables CHEF DE DÉPARTEMENT et
AFFECTATION, la clé d'identification de la table APPARTENANCE doit
être formée par la concaténation de deux clés étrangères : le numéro
d'employé et le numéro du projet. La raison est qu’un employé peut
participer à plusieurs projets, et qu’inversement, un projet peut
impliquer plusieurs employés.
Quand faut-il
définir une table
distincte pour un
ensemble de
liens ?
L'application des règles de passage 1 et 2 ne conduit pas toujours
à un schéma de base de données relationnelle optimal. Selon les
circonstances, elle pourrait engendrer un grand nombre de tables. En
se référant à la figure 2-8, on peut se demander par exemple s'il était
vraiment nécessaire de créer une table distincte pour la fonction de
chef de département. Dans la prochaine section, nous verrons qu'en
vertu de la règle de passage 5, nous renoncerons en fait à créer la table
CHEF DE DÉPARTEMENT. La fonction «Chef de département» sera
intégrée dans la table DÉPARTEMENT tout simplement comme un