|
Chapitre 7 :
les relations |
|
|
1 - Introduction |
|
|
|
|
|
Nous
avons vu, au chapitre précédent, comment établir le schéma relationnel d'une
base de données. Pour implémenter ce schéma dans un SGBD, il faut créer des
tables et des relations. Les tables ayant fait l'objet du chapitre 2 et de
ses annexes, il nous faut maintenant apprendre à créer les relations. |
|
|
|
|||
|
|
2 - Un exemple simple |
|
|||||||
|
|
|
Nous
commençons par un cas simple, celui où la base ne contient que deux tables
liées par une relation 1-n. Pour ce faire, nous réutilisons l'exemple traité
au chapitre 4. Une table intitulée "Personnes" contient les
champs "Nom", "Prénom", et "Commune". Une personne
habite dans une commune et une seule, mais une commune peut héberger
plusieurs personnes. Pour éviter la saisie redondante du nom de la commune
dans la table "Personnes", nous avons le choix entre deux méthodes.
Toutes deux impliquent la création d'une seconde table, que nous intitulerons
"Communes", et qui contiendra le champ "Commune". Nous
pouvons : |
|
||||||
|
|
|
|
|
||||||
|
|
|
Cet
exemple simple nous montre qu'une liste de choix externe n'est pas
différente, dans son principe, d'une relation 1-n entre deux tables.
Les différences se manifestent sur le plan pratique, car les
techniques utilisées pour créer une liste externe et une relation ne sont pas
exactement les mêmes. Nous examinerons ces différences en détail dans le
chapitre suivant. |
|
||||||
|
|
|||||||||
|
|
3 - La création d'une relation |
|
|
|
|
|
Les
deux tables "Personnes" et "Communes" étant créées, et la
fenêtre "Base de données" étant active, nous ouvrons la fenêtre
"Relations" en cliquant sur le bouton |
|
|
|
|
Pour
créer la relation désirée entre les deux tables, nous cliquons sur le champ
"Commune" de l'une d'elles, et nous tirons le curseur (le bouton
gauche de la souris maintenu enfoncé) vers le champ "Commune" de
l'autre table. Une fenêtre intitulée "Modification des relations"
s'ouvre, comme le montre la figure ci-dessous. |
|
|
|
|||
|
|
|||
|
|
|||
|
|
|
Il
suffit de cliquer sur le bouton "Créer" pour que la relation
apparaisse, comme le montre la figure suivante. |
|
|
|
|||
|
|
|||
|
|
|||
|
|
|
Pour
supprimer une relation : nous ouvrons la fenêtre "Relations", nous
sélectionnons la relation d'un clic droit, nous choisissons
"Supprimer" dans la liste qui s'affiche, et nous confirmons la
suppression. |
|
|
|
|||
|
|
4 - L'utilisation de la clé |
|
|
|
|
|
|
|
|
|
|
La
bonne démarche consiste à poser une clé sur le champ "Commune" de
la table "Communes". Il en résulte que les doublons sont interdits,
et que le champ est trié par ordre alphabétique croissant. C'est
indispensable pour que le champ puisse servir de côté 1 dans la relation 1-n.
Nous avons expliqué, au chapitre 4, comment on pose une clé sur un
champ. Rappelons-le brièvement : il faut ouvrir la table
"Communes" en mode modification, sélectionner le champ
"Commune", et cliquer sur l'icône |
|
|
|
|
Pour
vérifier que la relation est bien du type 1-n, il faut ouvrir la fenêtre
"Relations", effectuer un clic droit sur la relation, choisir
"Modifier une relation...", de telle sorte que la fenêtre
"Modification des relations s'ouvre. Nous constatons alors que, dans le
bas de cette fenêtre, la propriété "Type de relation :" est passée
de "Non définie" à "Un-à-plusieurs".
Le SGBD sait désormais que la relation est du type 1-n, et que le côté 1 est
du côté de la clé. |
|
|
|
|
Dans
la fenêtre "Relations", la présence de la clé est révélée par le
fait que le nom du champ correspondant est écrit en caractères gras, comme le
montre la figure ci-dessous. |
|
|
|
|||
|
|
|||
|
|
|||
|
|
|
La
présence de la clé a un autre effet, qu'illustre le paragraphe suivant. |
|
|
|
|||
|
|
5 - La sous-table |
|
|
|
|
|
Si
nous ouvrons la table "Communes", nous constatons que nous pouvons
faire apparaître "Personnes" en sous-table.
Nous pouvons ainsi saisir des données dans les deux tables, sans avoir à
passer de l'une à l'autre (seule la table "Communes" est ouverte).
La figure ci-dessous explicite cette situation. |
|
|
|
|||
|
|
|||
|
|
|||
|
|
|
Introduisons
quelques données dans la table, puis faisons l'expérience suivante :
refermons la sous-table, sélectionnons la première
ligne et supprimons-la. Le SGBD ne proteste pas. Dans la table
"Personnes", l'enregistrement de M. Trombe Jean, qui habite
Grenoble, est toujours présent, alors que Grenoble ne figure plus dans la
liste des communes. |
|
|
|
|
Dans
la table "Personnes", nous pouvons introduire un enregistrement
avec un nom de commune qui ne figure pas dans la table "Communes",
et le SGBD ne proteste toujours pas. |
|
|
|
|
En pareil cas, on dit que la base de
données manque de cohérence. La
relation entre les deux tables n'est pas assez contraignante, et l'opérateur
peut faire un peu n'importe quoi. Pour
remédier à cette situation, il faut renforcer la relation, comme expliqué au
paragraphe suivant. |
|
|
|
|||
|
|
6 - L'intégrité référentielle |
|
|||||||
|
|
|
Dans
la fenêtre "Modification des relations", un choix s'offre à nous,
celui de l'intégrité référentielle. Ce terme
implique que le SGBD effectue un certain nombre de contrôles, pour assurer la
cohérence interne de la BDD. Si nous appliquons l'intégrité
référentielle : |
|
||||||
|
|
|
|
|
||||||
|
|
|
Nous
cochons donc la case "Appliquer l'intégrité référentielle", puis
nous appuyons sur le bouton "OK". Dans la fenêtre
"Relations", la présence des signes 1 et infini traduit
l'application de l'intégrité référentielle, comme le montre la figure
ci-dessous. On remarquera que le nom du champ qui porte la clé (et qui se
trouve du côté 1 de la relation) est toujours écrit en caractères gras. |
|
||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|
Attention ! le SGBD refusera
d'appliquer l'intégrité référentielle si les deux champs liés par la relation
ne possèdent pas le même type de données. Seule exception : si le champ côté 1 est du type NuméroAuto, il doit être du type numérique (entier long)
du côté n. De même, le SGBD refusera d'appliquer l'intégrité
référentielle si les tables contiennent déjà des données, dont certaines ont
des valeurs empêchant l'intégrité référentielle de s'appliquer.
Exemple : un nom de commune dans la table "Personnes" ne
figure pas dans la table "Communes". |
|
||||||
|
|
|
Si
nous demandons l'intégrité référentielle (et il est très fortement
conseillé de le faire !), le système nous propose deux autres choix.
Le premier, "Mettre à jour en cascade les champs correspondants", signifie que si
nous modifions l'écriture du nom d'une commune du côté 1 de la relation,
cette modification sera reportée partout du côté n. D'une manière
générale, il est recommandé d'activer cette mise à jour en cascade. Si nous
ne le faisons pas, et si nous tentons de modifier un nom de commune (pour
corriger une faute d'orthographe, par exemple), le système nous arrêtera,
avec le message suivant : "Impossible de supprimer ou de modifier
l'enregistrement car la table 'Personnes' comprend des enregistrements
connexes". C'est clair, n'est-ce pas ? |
|
||||||
|
|
|
Le
second choix, "Effacer en cascade les enregistrements correspondants",
signifie que si nous supprimons une donnée du côté 1 de la relation,
tous les enregistrements utilisant cette donnée du côté n seront
supprimés. Cela implique que, si nous supprimons par erreur un nom de commune
dans la table "Communes", nous supprimons en même temps de la table
"Personnes" toutes les personnes habitant cette commune. Il ne faut
donc pas activer cette option, sauf momentanément et en cas de besoin
spécifique. |
|
||||||
|
|
|
Supposons
par exemple que des noms de fournisseurs se trouvent du côté 1 de la
relation, et des noms de produits du côté n. Si un fournisseur disparaît,
nous pouvons activer l'effacement en cascade. Quand nous supprimons le nom du
fournisseur côté 1, tous ses produits disparaissent du côté n. Nous
effectuons ainsi la mise à jour de la base. Ensuite, nous décochons
l'effacement en cascade pour éviter tout risque d'effacement involontaire. |
|
||||||
|
|
|
Remarque
: le bouton "Type jointure..." ouvre la boite de dialogue intitulée
"Propriétés de la jointure". Nous étudierons la notion de jointure au chapitre 13, dans le cadre
des requêtes. |
|
||||||
|
|
|||||||||
|
|
7 - Conclusion |
|
|
|
|
|
Nous
avons vu, sur un exemple simple (deux tables liées par une
relation 1-n), comment créer une relation et la doter des propriétés qui
assurent la cohérence de la base de données (intégrité référentielle). Nous
avons reconnu au passage des notions que nous avions déjà rencontrées à
propos des listes (chapitre 4) : l'usage de la clé, les sous-tables. Il serait maintenant bon que nous étudiions
ce que les listes et les relations ont en commun, et ce qui les différencie.
Ce sera l'objet du prochain chapitre. |
|
|
|
|||