• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/09/2019

Mettez en œuvre les différents types de relations à l'aide des clés étrangères

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Je vous ai présenté les associations entre les classes avec l'approche orientée objet (AOO), il est temps maintenant de vous montrer comment les traduire dans un modèle relationnel et donc dans votre base de données.

Le principe général de mise en œuvre d'une relation est le suivant : utiliser une référence vers le tuple lié dans un attribut ad hoc. C'est ce que l'on appelle une clé étrangère ou foreign key (FK) en anglais.

Clé étrangère, clé primaire... je ne suis pas serrurier !

Clé primaire, clé étrangère... ça commence à faire beaucoup de clés tout ça... Mais rassurez-vous, cela n'a rien de compliqué. ;)

La valeur de la clé étrangère dans un tuple n'est rien d'autre que la valeur de la clé primaire du tuple lié. 

Je vous ai perdu... ? Voici un exemple illustrant tout cela.

Imaginez l'association pilote/machine suivante entre un Motard et une Moto.

Association « pilote/machine » entre un « Motard » et une « Moto »
Association « pilote/machine » entre un « Motard » et une « Moto »

Voici les tables correspondantes :

Tuples des tables « motard » et « moto »
Tuples des tables « motard » et « moto »

Le but est de matérialiser les liens suivants entre les tuples de motards et de motos :

Relation entre les pilotes et leur machine (tuples)
Relation entre les pilotes et leur machine (tuples)

Pour enregistrer quelle est la machine (rôle de la classe Moto dans l'association) associée à chaque pilote (rôle de la classe Motard dans l'association), il suffit de créer un attribut machine_id en tant que clé étrangère (FK) dans la table motard et d'y enregistrer la valeur de la clé primaire de la moto correspondante :

Ajout de la clé étrangère « machine_id » dans la table « motard »
Ajout de la clé étrangère « machine_id » dans la table « motard »

Il est désormais possible de demander à la base de données de nous renvoyer un tableau contenant le nom de chaque pilote et le modèle de la machine qui lui est associé :

nom

modele

Édouard Bracame

Honda CB 750

Jean Manchzeck

Norton Commando 850

Jean-Raoul Ducable

Kawasaki 750 H2

Mettez en œuvre différents types de relation

Vous vous souvenez des trois catégories d'associations que je vous ai présentées dans un des chapitres précédents ?

  • un à un (one-to-one)

  • un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :

  • plusieurs à plusieurs (many-to-many) :

Eh bien, nous avons désormais tous les ingrédients pour les mettre en œuvre.

L'association un à un (one-to-one)

L'association un à un (one-to-one) est une association qui possède 1 comme cardinalité maximum de part et d'autre de celle-ci.

Si je reprends l'exemple de l'association Conducteur / Voiture :

Association « un à un » (one-to-one)
Association « un à un » (one-to-one)
  • Un conducteur conduit une et une seule voiture à la fois

  • Une voiture n'est pas conduite (en stationnement) ou conduite par un seul conducteur à la fois

Sa mise en œuvre correspond à celle que je vous ai montrée en exemple dans la section précédente avec la relation Motard / Moto.

Comme il n'est possible d'associer qu'une seule Voiture à un Conducteur et qu'un seul Conducteur à une Voiture, à vous de choisir dans quel sens vous voulez matérialiser la relation (conducteur -> voiture ou voiture -> conducteur). En général on prend le sens privilégié dans le domaine fonctionnel.

Ici on peut considérer plus « naturel » de faire monter un conducteur dans une voiture que de mettre la voiture autour du conducteur :p.

Je prendrais donc l'option de mettre une clé étrangère conducteur_id dans la table voiture.

MPD ‒ Relation « un à un » (one-to-one)
MPD ‒ Relation « un à un » (one-to-one)

L'association un à plusieurs (one-to-many)

L'association un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) est une association qui possède 1 comme cardinalité maximum d'un côté et une cardinalité maximum supérieure à 1 (cardinalité multiple) de l'autre côté de celle-ci.

Association « un à plusieurs » (one-to-many)
Association « un à plusieurs » (one-to-many)
  • Un journal contient aucun (journal en préparation), un ou plusieurs articles

  • Un article est contenu dans aucun (en cours d'écriture) ou un seul journal

Sa mise en oeuvre est la même qu'avec une association un à un (one-to-one), sauf que le sens est imposé. Vous devez créer la clé étrangère dans la table correspondant à la cardinalité maximum supérieure à 1 (cardinalité multiple).

MPD ‒ Relation « un à plusieurs » (one-to-many)
MPD ‒ Relation « un à plusieurs » (one-to-many)

Il est ainsi possible de référencer plusieurs fois le même journal dans des articles différents (cardinalité *), et un article ne peut être lié qu'à un seul journal au maximum (cardinalité 0..1) :

Tuples montrant la relation « un à plusieurs » (one-to-many)
Tuples montrant la relation « un à plusieurs » (one-to-many)

L'association plusieurs à plusieurs (many-to-many)

L'association plusieurs à plusieurs (many-to-many) est une association qui possède une cardinalité maximum supérieure à 1 (cardinalité multiple) de part et d'autre de celle-ci.

Association « plusieurs à plusieurs » (many-to-many)
Association « plusieurs à plusieurs » (many-to-many)
  • Un musicien constitue aucun, un ou plusieurs groupes

  • Un groupe est constitué de un ou plusieurs musiciens

Il n'est ici plus possible de faire ce simple lien d'une table à l'autre, en témoigne l'exemple ci-dessous :

Tuples montrant la relation « plusieurs à plusieurs » (many-to-many)
Tuples montrant la relation « plusieurs à plusieurs » (many-to-many)

Nous voyons bien qu'un musicien comme Jack White entre dans la composition de plusieurs groupes (The White Stripes, The Raconteurs). Et inversement, un groupe comme Led Zeppelin est composé de plusieurs musiciens (Page, Jones, Plant, Bonham).

La solution consiste à créer une table ad hoc, matérialisant les liens multiples en créant une clé primaire composée des clés étrangères pointant vers les tables musicien et groupe.

Il s'agit de la table composition dans l'exemple ci dessous :

MPD ‒ Relation « plusieurs à plusieurs » (many-to-many)
MPD ‒ Relation « plusieurs à plusieurs » (many-to-many)
Ajout d'une table matérialisant la relation « plusieurs à plusieurs » (many-to-many)
Ajout d'une table matérialisant la relation « plusieurs à plusieurs » (many-to-many)

La classe d'association

Il est possible d'ajouter des attributs à une association grâce à une classe d'association.

Imaginez une association représentant les concerts donnés par un groupe de musique dans des lieux de spectacle : à chaque fois que j'ai un lien entre un Groupe et un Lieu, cela représente un Concert. En créant la classe d'association Concert, je peux ajouter, par exemple, un attribut date qui spécifie la date du concert.

Classe d'association « Concert »
Classe d'association « Concert »

Une classe d'association se traduit dans le MPD comme une association plusieurs à plusieurs (many-to-many) : en créant une table du nom de la classe d'association avec une clé primaire composée et contenant les attributs de la classe d'association :

MPD ‒ La classe d'association « Concert » devient une table comme pour une relation « plusieurs à plusieurs » (many-to-many)
MPD ‒ La classe d'association « Concert » devient une table comme pour une relation « plusieurs à plusieurs » (many-to-many)

Il y a de nombreux cas où les classes d'association sont utiles, par exemple enregistrer le numéro de siège dans une relation Passager/Vol, etc.

Une autre utilité des classes d'association

Je vous disais précédemment qu'il n'y a pas de notion d'historique dans les associations. Le lien entre deux instances existe ou n'existe pas. Point !

Cependant, avec une classe d'association, il est possible de simuler une sorte d'historique en ajoutant des attributs comme dateDebut et dateFin par exemple. Le lien existera toujours, mais on va désormais pouvoir interpréter son « effectivité » en se basant sur cette plage de dates.

Je peux ainsi modéliser le changement du batteur dans le groupe Matmatah en 2003, en utilisant cette approche :

MPD ‒ Ajout de dates à l'association « Musicien / Groupe » (many-to-many)
MPD ‒ Ajout de dates à l'association « Musicien / Groupe » (many-to-many)
Tuple de la table « composition »
Tuple de la table « composition »

On voit que :

  • Fañch est entré dans le groupe Matmatah dès le début du groupe (debut = NULL) et en a fait partie jusqu'en 2002.

  • Scholl est entré dans le groupe en 2003 et en fait toujours partie (fin = NULL).

Exemple de certificat de réussite
Exemple de certificat de réussite