Banière du site

[koala01.free.fr]->Tutoriaux->Initiation aux base de données ->Les relations entre tables

Image d'imprimante   image d'enveloppe

3.1 Qui l'eut crut?

Je vous parlais, dans la page d'introduction, de l'acronyme (S)GBDR, en vous indiquant que le R signifiait «relationnelle».

Ce terme condense à lui seul le but principal de toute base de données, à savoir le fait de créer des relations entre les données des différentes tables.

Quand on décide de ne pas recourir à l'informatique pour gérer ses informations, il est parfois nécessaire d'utiliser plusieurs systèmes de classement pour retrouver une information précise.

Ainsi que j'en donnais l'exemple dans la page précédente, si l'on souhaite contacter la personne avec qui l'on a rendez-vous à dix heures, il faudra généralement commencer par vérifier dans l'agenda avec qui le rendez-vous est fixé, avant de pouvoir aller dans le carnet d'adresse pour trouver son numéro de téléphone.

La gestion des données par informatique permet justement de mettre des informations aussi diverses que les rendez-vous que l'on a en relation avec les personnes que l'on connait, le tout dans un grand ensemble de travail

fleche haut

3.2 Les «clés primaires»

Pour pouvoir mettre ces informations en relation les unes par rapport aux autres, on se rend tout de suite compte qu'il importe de prévoir un moyen pour identifier de manière unique et non ambigüe chaque enregistrement que l'on peut trouver dans n'importe quelle table.

Le moyen utilisé pour identifier ainsi les enregistrement s'appelle la «clé primaire».

Cette clé primaire sera un champ, ou un ensemble de champs, dont la (ou les) valeur(s) sera (seront) unique(s) pour chaque enregistrement.

Dans la pratique courrante, il pourrait s'agir d'un champs numérique, incrémenté de manière automatique, mais aussi d'un nombre donné de champs dont on est certain qu'il n'existera pas plusieurs fois la même séquence.

fleche haut

3.3 Mono ou multicomposant

Rien n'empêche de se baser sur plusieurs champs, éventuellement de type différent, pour créer une clé primaire.

On pourrait effectivement très bien envisager (c'est ce qui a été fait pour ce site) de créer une table dans laquelle deux ou trois (quatre, cinq six…cueillir de cerises) champs serviraient à trouver une unicité de référence.

Chaque champs pourrait alors être géré séparément sans aucun problème, mais seule l'utilisation de tous ces champs donnerait l'assurance de n'avoir qu'un seul enregistrement.

Quand la clé primaire n'est composée que d'un seul champ, nous avons une «clé primaire monocomposant» et, quand elle fait appel à plusieurs champs, nous obtenons logiquement une «clé primaire multicomposant».

fleche haut

3.4 Ses particularités

A partir du moment où un champ (ou un groupe de champs) est déclaré comme clé primaire, le système veillera d'ailleurs à ce que les valeurs introduites restent uniques.

Ainsi, si vous veniez (ce qui n'est vraiment pas à faire) à utiliser les champs "nom" et "prenom" comme clé primaire, le système refuserait que vous introduisiez deux fois un dénommé Durant Jean, et ce, même s'il s'agissait réellement de deux personnes différentes.

De plus, toutes les clé primaires sont d'office indexées, ce qui permet de rendre l'accès à leur valeur plus rapide, mais ce sujet sera traîté ultérieurement.

fleche haut

3.5 Voyage en absurdie

Moi, tout con, j'croyais que Gerard Lambert, c'était un nom que j'avais inventé…

J'croyais…

Rien qu'à Paris, dans l'bottin, y en a 7000, des Gérard Lambert…

Bon p'tetre pas 7000 mais une demi-douzaine…

Renaud, Un Olympia pour moi tout seul, 1982 (introduction à la chanson "le retour de gérard lambert")

L'excemple que je vous présente est ici tiré d'un cas, vécu et, malheureusement tout à fait réel.

J'ai personnellement connu une demoiselle (dont je tairai ici le nom) qui s'est un jour étonnée de ne pas recevoir sa déclaration d'impôts.

Elle s'est donc rendue au service des contributions pour s'inquiéter de la raison qui avait mené à cette situation.

Le fonctionnaire s'est absenté pendant une bonne demi heure, et, quand il est revenu, il lui a dit, d'un air visiblement embeté que, "Mademoiselle, c'est normal que vous n'ayiez pas reçu votre déclaration, parce que, j'ai la lourde tâche de vous apprendre que vous êtes morte depuis deux ans…".

Le fonctionnaire devait pourtant reconnaître que cette demoiselle se portait étonnammant bien pour une personne décédée…

La personne, quant à elle, estimait à juste titre que, si elle était morte, elle en aurait sans doute été tenue au courent…

Renseignements pris, il est apparu que cette situation, qui n'aurait jamais du se produire, a été induite par un fonctionnaire inattentif.

En effet, bien qu'elle ne se soient jamais connues, il y avait deux personnes, nées le même jour, portant le même nom et le même prénom, et qui ont "osé pousser le vice" jusqu'à habiter dans la même rue.

Lors du décès de l'une d'elle (pas celle que je connais, l'autre), l'administration des impôts en a été prévenue par le truchement habituel.

Un fonctionnaire, sans doute quelque peu distrait, a(sans doute) effectué une recherche sur le nom et le prénom de la personne, trouvé une personne pour laquelle la commune et la date de naissance correspondait, et déduit que c'était la bonne…

Sauf que, en l'occurence, la personne sur laquelle il a arrêté son choix était, elle, bien vivante.

En étant un peu plus attentif, il se serait rendu compte que le numéro dans la rue ne correspondait pas, à moins qu'il n'ait cru à une erreur d'encodage.

En tout état de cause, il aurait du effectuer sa recherche sur base du seul élément en sa possession pour déterminer l'unicité de la personne: son numéro de registre national.

Cet exemple, absurde s'il en est montre clairement deux choses:

Maintenant que l'on est en mesure de choisir un enregistrement unique dans une table, il faut etre en mesure de mettre cet enregistrement en relation avec d'autres informations qui se trouvent dans une autre table.

Il s'agira simplement de prévoir un (groupe de ) champs du meme type (et, pourquoi pas du meme nom) que la clé primaire de la table de référence, et d'y mettre la valeur de la clé primaire.

fleche haut

3.6 Etat des lieux

Nous sommes maintenant en présence de deux tables qui se trouvent en relation, et, grâce à certaines requetes, il y a moyen de retrouver les informations d'une personne avec qui on a rendez-vous à une heure donnée.

Seulement, un dernier détail peut venir déranger le système, c'est le fait que, pour autant que l'on mette dans le champ une valeur du type attendu, il n'y a aucune vérification de la validité de cette valeur.

Si donc, vous avez (par exemple) décidé de créer une clé primaire numérique à incrémentation automatique sur la table qui contient les contacts, et que vous avez donc prévu tout logiquement un champs numérique qui a pour but de prendre la valeur du contact avec qui vous avez rendez-vous dans la table des rendez-vous, rien ne vous empêche de mettre une valeur numérique qui n'est pas utilisée comme valeur de clé primaire dans la table contact (si vous avez 100 contacts, rien ne vous empêche de mettre la valeur 1000 dans la table rendez-vous)

Pour résoudre ce problème (car, comment avoir rendez-vous avec un contact qui n'existe pas), il y a moyen de forcer le système à vérifier que la valeur introduite corresponde bien à une valeur existante.  La relation s'appellera alors une jointure.

fleche haut

3.7 Les jointures

Les jointures sont des relations entre tables bien plus fortes que les relations habituelles.

En effet, on se trouve souvent confronté au fait que la valeur du champs d'une table, si elle est fournie, doit exister comme clé primaire (qui est le seul moyen, rappelons-le d'identifier un enregistrement de manière unique et non ambigüe) d'une autre table.

Plus haut, je posais la question de comment avoir un rendez-vous avec un contact qui n'existe pas, mais, comment un client pourrait-il envisager la commande d'un article qui n'existe pas, comment pourriez vous commander quelque chose chez un fournisseur qui ne vous fournit pas, comment écouter la chanson d'un artiste que vous n'avez pas, ou regarder le film d'un acteur ou d'un réalisateur qui n'a jamais existé (pour le système du moins) sont autant de questions similaires.

Si l'on souhaite que les informations fournies par la base de données restent cohérentes, il faut trouver le moyen de dire au système de n'accepter que des valeurs qui existent.

De cette manière, le système, s'il avait un peu le sens de l'humour, viendrait vous taper derrière l'oreille en vous disant "imbécile, j'ai pas ce contact là en stock… sois attentif".

C'est ce à quoi servent les jointures.

Pour pouvoir mettre une jointure en place, il faut donner au champ qui crée la relation avec la table de référence le statut de clé étrangère.

fleche haut

3.8 Les «clés étrangères»

Quand un champ est défini comme clé étrangère, il subit des contraintes telles que le système, qui sera toujours plus têtu que vous, n'acceptera que l'on effetue certaines opérations que si certaines conditions sont remplies.

Evidemment, rien n'empêche d'utiliser une clé étrangère vers une table de référence comme élément de clé primaire de la table sur laquelle on est en train de travailler.

Il faudra enfin veiller à ce que l'ensemble des champs permettant d'identifier une clé primaire multicomposant soit repris, si d'aventure il fallait utiliser une telle clé primaire comme clé étrangère.

En effet, si nous venions à ne pas utiliser l'ensemble des champs composant la clé primaire sur une table, le système refuserait de travailler correctement sous prétexte que la clé étrangère utilisée ne représente pas une référence unique.

Cela nous permettra de gérer ce que l'on appelle l'intégrité référencielle.

fleche haut

3.10 L'intégrité référencielle

Ce terme un peu pompeux représente tout simplement la réaction que doit avoir le système si l'on essaye de modifier ou de supprimer l'enregistrement d'une table qui sert de référence à une autre table.

Pour présenter les choses simplement, l'intégrité référencielle va définir ceraitnes actions qui seront appliquées si, par exemple, nous venions à essayer de modifier le champs d'identification d'un contact avec lequel nous aurions déjà eu un rendez-vous.

Cela répond donc simplement à des questions du genre "que se passe-t-il si j'essaye de supprimer un contact" ou "que va-t-il se passer si j'essaye de modifier l'identifiant (clé primaire) d'un contact".

Imaginons quelques instants que nous souhaitions supprimer un contact du carnet d'adresses.

Si nous n'avons jamais eu de rendez-vous ou de contact avec lui, il n'y a, a priori, aucune objection à le retirer… Même s'il pourrait alors être intéressant de savoir ce qu'il fait dans les contacts.

Si par contre, nous avions déjà eu un rendez-vous avec, le fait de laisser le rendez-vous mais de supprimer le contact fera que nous aurons dans l'agenda un rendez-vous avec quelqu'un qui… n'existe pas.

Nous nous rendons donc compte que la seule suppression d'un contact avec lequel nous aurions déjà eu un rendez-vous n'est pas réalisable.

Mais, peut-être peut-on envisager une alternative passant par la suppression de tous les rendez-vous avec ce contact?

Cette alternative n'est envisageable que si il ne nous importe peu d'avoir des trous dans notre emploi du temps.

En effet, si nous devions avoir une troisième table qui permet de gérer la facturation de nos rendez-vous, la suppression d'un rendez-vous provoquerait le fait de facturer un rendez-vous qui… n'a jamais eu lieu, et il faudrait donc envisager de supprimer cette facturation, pour garder la cohérence, mais cette suppression d'information de facturation risque encore de provoquer la suppression d'une rentrée d'argent etc.

Cela s'appelle la suppression d'enregistrements en cascade.

On se rend clairement compte qu'il n'est pas, dans ce contexte, envisageable d'effectuer la suppression d'un contact avec lequel nous aurions déjà eu un rendez-vous.

Tout au plus, pourrions-nous prévoir un champ supplémentaire stipulant si nous considérons pouvoir encore avoir des contacts avec lui.

Cependant, il n'est pas exclu que nous nous trouvions face à des cas dans lesquels une telle suppression d'enregistrements en cascade puisse être envisagée (il faudra cependant réfléchir très sérieusement à toutes les implications, et avoir l'assurance que cette suppression en cascade ne posera pas de problème) .

L'autre question que l'on peut se poser est "que se passera-t-il si je décide de modifier le numéro identifiant d'un de mes contacts?"

Autrement dit, que se passerait-il si je décidais d'un seul coup que mon contact n°88 devenait mon contact n°103? (étant entendu que 103 est une valeur qui ne sert pas encore pour la clé primaire).

Là encore, on constate tout de suite qu'il est impossible de ne modifier que la clé primaire d'un contact avec lequel nous aurions déjà eu un rendez-vous…

En effet, si nous ne modifions la valeur que dans la table qui contient les contacts, nous retomberons sur le problème d'avoir eu des rendez-vous avec le contact 88 … qui n'existe pas aux yeux du système.

Par contre, rien n'empêche de modifier la valeur du contact dans toute la table des rendez-vous… Pour autant que les informations de la table des rendez-vous ne servent pas pour la facturation, auquel cas, il faudra aussi modifier les valeurs dans cette troisième table, et dans les suivantes.

Cela s'appelle la mise à jour d'enregistrements en cascade .

3.11 En résumé

Exceptionnellement, j'ai décidé de faire un petit résumé de tout ce que j'ai pu écrire sur cette page, du fait de la complexité des concepts.

fleche haut

image d'imprimante   image de mail   fleche haut

Evaluation donnée par les visiteurs
Cette page a été évaluée 4 fois et a obtenu une moyenne de compréhensible, sans plus
Mon appréciation sur la compréhensibilitéde cette page est:
  • incompréhensible
  • mal expliquée
  • compréhensible, sans plus
  • bien expliquée
  • très bien expliquée

fleche haut

[koala01.free.fr]->Tutoriaux->Initiation aux base de données ->Les relations entre tables

Copyright (©) 2005 (Philippe Dunski)

Ce cours est libre, vous pouvez le redistribuer et/ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation (version 2 ou bien toute autre version ultérieure choisie par vous).

Ce cours est distribué car potentiellement utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les garanties de commercialisation ou d'adaptation dans un but spécifique. Reportez-vous à la Licence Publique Générale GNU pour plus de détails.

Cependant, l'auteur apprécierait grandement que vous lui fassiez part de toute modification apportée à son contnu

Vous pouvez le contacter par mail à l'adresse koala01@free.fr

Vous pouvez trouver une adaptation française de la licence GNU/GPL à l'URL http://www.linux-france.org/article/these/gpl.html