|
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 : |
|
|
|
| |
 |
créer une liste de choix externe dans la table "Personnes", les noms de communes provenant du champ
"Commune" de la table "Communes" ; |
|
|
relier les deux tables "Communes" et "Personnes" par une relation 1-n portant sur leur champ
"Commune". |
|
|
|
|
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
 du même nom. Si les deux tables n'apparaissent pas, nous cliquons sur
le bouton  "Afficher la table". Une fenêtre du même nom
s'ouvre, qui nous permet d'ajouter les deux tables. |
|
|
|
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é |
|
| |
|
Telle quelle, la relation que nous venons de créer ne sert pas à grand'chose, parce qu'elle est dépourvue de
propriétés. En particulier, le SGBD ne sait pas que la relation est du type 1-n. |
|
|
|
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  "Clé primaire". |
|
|
|
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é fait 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 : |
|
|
|
| |
|
un nom de commune ne provenant pas de la table "Communes" sera refusé dans la table "Personnes" ; |
|
|
il ne sera pas possible de supprimer un nom de commune dans la table "Communes" s'il a été utilisé dans la table
"Personnes". |
|
|
|
|
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. |
|
|
