Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
TUTORIEL cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Formation > Tutoriels > Bases de données relationnelles > Les relations (début)
        Révision : 22 janvier 2003
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
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.          
Comme précédemment, nous utilisons le logiciel Access de l'éditeur Microsoft comme support de ce tutoriel (encore appelé "cours en ligne" ou tutorial).
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.
Fenêtre Modification des relations
Il suffit de cliquer sur le bouton "Créer" pour que la relation apparaisse, comme le montre la figure suivante.
Relation entre les deux tables
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.
Le champ possédant la clé est écrit en gras
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.          
Tabe "Communes" et sous-table "Personnes"
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.
La relation après application de l'intégrité référentielle
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.          
Chapitre précédent Plan du tutoriel Liste des tutoriels Chapitre suivant
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
Copyright © CERIG/EFPG 1996-2003
Réalisation et mise en page : J.C. Sohm