Discussion :

[Hilz57]

Bonjour,

J'ai la tâche de modéliser une base de données pour un centre équestre.
Pour l'instant tout se passe bien, mais il y a une chose que je ne sais pas modéliser, il est possible que la solution se trouve dans merise2 mais je ne la connais pas. Après plusieurs recherches infructueuses, je me permets donc de solliciter votre aide :

Voici le problème :
- Un client peut monter plusieurs chevaux différents mais il ne peut en monter que un par leçon (leçon = table reprise). Voici la partie concernée de mon MCD :



Comment puis-je traduire qu'un client peut monter plusieurs chevaux mais un seul à la fois (un seul par leçon) ?





En vous remerciant par avance pour vos réponses,

Cordialement.

[fsmrel]

Bonsoir,


Selon l’association-type Monte, le cheval Zaza ne peut être monté par le client Albert qu’une seule fois, ce qui paraît un peu trop restrictif.

Albert peut suivre des leçons qui ne concernent pas Zaza.

Il y a donc quelques contraintes à prendre en compte lors de la modélisation.

Je vais me situer au niveau logique, car j’y suis plus à l’aise pour examiner votre problème, et donc je parlerai de tables plutôt que de types d’entités et des relations qu’elles entretiennent.

On a déjà trois tables correspondant à vos entités-types Leçon, Cheval, Client :

Leçon {LeçonId, ....}
Cheval {ChevalId, ....}
Client {ClientId, ....}

(Les clés primaires sont soulignées).

Appelons Horaire le couple formé par la date et l’heure des leçons.

La paire {Leçon, Horaire} préexiste aux participations des clients aux leçons. En ce sens, il faudrait prévoir une table hébergeant les différentes valeurs de cette paire. Cette table aurait la structure suivante :

LH {LeçonId, HoraireValeur, Duree}

L’attribut LeçonId est lié à son homologue de la table Leçon par clé étrangère, au motif de l’intégrité référentielle.

Une question au passage : une leçon a-t-elle toujours la même durée ? Si oui, l’attribut Duree doit être transféré dans la table Leçon.

Ensuite, on peut établir une relation entre les tables LH, Cheval et Client, d’où la structure de la table correspondante :

MONTE {ClientId, ChevalId, LeçonId, HoraireValeur}

(La table comportant plus d’une clé, les souligner serait cause d’ambiguïté, donc on s’abstiendra.)

On peut raisonnablement penser qu’à un instant t un cavalier monte un seul cheval et suit une seule leçon. De la même façon, à un moment donné, un cheval est monté par un seul cavalier et ne participe qu’à une seule leçon. Ceci se traduit par les dépendances fonctionnelles :

{ClientId, HoraireValeur} → {ChevalId, LeçonId}

{ChevalId, HoraireValeur} → {ClientId, LeçonId}

En conséquence, la table MONTE a deux clés candidates :

CK1 : {ClientId, HoraireValeur}

CK2 : {ChevalId, HoraireValeur}

Et trois clés étrangères (exprimant les contraintes d’intégrité référentielle) :

FK1 : {LeçonId, HoraireValeur}
FK2 : {ChevalId}
FK3 : {ClientId}

Par concession au modèle SQL, on retiendra CK1 comme clé primaire, au hasard, CK2 devenant alors clé alternative.

Maintenant, pour la rétroconception du MLD en MCD, sans perte de règles, les choses ne pas si simples du fait de la présence des deux clés CK1 et CK2 et des contraintes de préexistence (conduisant à brancher une association avec une association). Je doute que l’on y parvienne de façon naturelle, même avec Merise 2.

Un MLD :

[Hilz57]

Salut,

Merci pour ta réponse. Je ne m'imaginais pas recevoir de réponse aussi complète.

Elle m'a bien aidée, j'ai réussi à résoudre, en partie, mon problème.

Merci à toi.