juin
2013
Un article de alassanediakite
Terminologie
Association, relation, dépendance, liaison, jointure, clé étrangère, clé secondaire sont des noms utilisés pour designer le fait que les lignes d’une table T1 sont associées aux lignes d’une autre tables T2.
Exemple :
- Pour une clinique, on a une table contenant les patients et une autre contenant les visites des patients. Chaque visite est liée à un et un seul patient. Un patient peut faire plusieurs visites.
- Pour un commerce, il existe une table « facture » et une autre « règlement ». Une facture peut avoir plusieurs règlements ou ne pas en avoir du tout. Un règlement est lié à une et une seule facture.
Mais les termes ci-dessus sont-ils pertinents ?
- « Relation » n’est pas bon car source de confusion. En effet, avec le modèle relationnel, une table de la base prend le nom de relation.
- « Dépendance » n’est pas bon car ce terme est utilisé par rapport aux propriétés (attributs, champs, colonne) définissant une entité. Il s’agit de la dépendance fonctionnelle.
- « Jointure » est plutôt un terme SQL. (Nous y reviendrons)
- « Liaison » n’est ni suffisant ni techniquement correcte.
- « Clé étrangère » est une mise en œuvre du concept.
- « Clé secondaire » n’a rien à voir dans ce contexte. C’est une grosse confusion que beaucoup de débutants trainent avec eux. J’ai été une victime pendant longtemps.
- « Association » est le meilleur et est le plus utilisé. Ce qui amène d’ailleurs à corriger le terme « Entité-relation » en « Entité-association ».
Mise en œuvre
L’un des point fort du modèle relationnel est la résolution du problème d’association plusieurs à plusieurs. Le modèle hiérarchique ne le permet pas et le modèle réseau apporte une solution qui engendre des redondances.
Le modèle relationnel représente l’association par de simples attributs. On dit que le modèle relationnel est un modèle à valeurs (pas d’objet, pas de pointeur) ?
Les jointures dans les requêtes
Pour avoir les factures avec leurs règlements on fait une jointure entre les tables « facture » et « règlement ».
I. Les factures et leurs règlements (on n’aura pas les factures qui n’ont pas de règlements)
1 2 | … facture INNER JOIN règlement ON facture.IDfacture=règlement.IDfacture |
II. Toutes les factures et leurs règlements (pour les factures sans règlements, les colonnes de règlements seront vides)
1 2 | … facture LEFT OUTER JOIN règlement ON facture.IDfacture=règlement.IDfacture |
III. Tous les règlements et les factures correspondantes (pour les règlements qui ne sont liés à aucune facture, les colonnes de factures seront vides)
1 2 | … facture RIGHT OUTER JOIN règlement ON facture.IDfacture=règlement.IDfacture |
Pour ce troisième cas. Il n’est pas normal d’avoir des règlements qui ne sont liés à aucune facture. Pour éviter une telle situation il faut faire recours à l’intégrité référentielle (chaque règlement fait référence obligatoirement à une facture). Ainsi, lors de la création de la table règlement et dans la définition de la clé étrangère, il faut demander au SGBD:
- Soit d’empêcher la suppression de toute facture qui à un règlement
- Ou de supprimer les règlements lors de la suppression des factures correspondantes.
Auto-jointure
Imaginer une communauté qui veut une base de données de sa population, dont l’une des fonctionnalités est le suivi des liens de parentés.
On peut aisément imaginer une table personne de cette manière…
pk->Primary key, fk->foreign key
Dans la même table on trouve une personne et tous descendants et ancêtres.
Pour avoir les parents de…
| IDpersonne | IDpere | IDmere | prenom | nom | datenais | sexe |
| 47 | 23 | 26 | Amadou | Kanté | 12/03/1974 | M |
, il me faut chercher (dans la même table) la personne d’identifiant 23 (pour avoir le père) et la personne d’identifiant 26 (pour avoir la mère).
Dans la requête nous utiliserons des alias (ou copie) de la table de cette manière…
1 2 3 | … personne AS enfant INNER JOIN personne AS pere ON enfant.IDpere=pere.IDpersonne INNER JOIN personne AS mere ON enfant.IDmere=mere.IDpersonne |
Commentaires récents
- dans Personnaliser la connexion d’un projet adp ACCESS
- dans [Bases de données] présentation de SQL
- dans [ACCESS] Numérotation automatique de courriers par an (janvier à décembre)
- dans [ACCESS] Numérotation automatique de courriers par an (janvier à décembre)
- dans [ACCESS] Numérotation automatique de courriers par an (janvier à décembre)