Discussion :

[thomasdo]

Bonjour, je réalise une application Access de gestion de covoiturage pour les employés d'une grosse entreprise. Je rencontre quelques difficultés de modélisation concernant la gestion des offres et des demandes de covoiturage.
Voici une courte explication du problème.

Un pilote dépose une offre de covoiturage:

- Création d'un trajet : On souhaite retenir le nombre de places pour le Trajet pour chaque jour de la semaine concernés par le trajet

-Un trajet est composé d'étapes, c'est à dire un certain nombre de Villes

- Un trajet peut être de type "Allez" (le point d'arrivée étant l'entreprise) ou "Retour" (dans ce cas, l'entreprise est le point de départ).

-> Je souhaiterais que les agents puissent effectuer des demandes concernant uniquement l'Allez ou le Retour, ou les deux.

J'ai donc pensé à effectuer un héritage sur Trajet:
Trajet_Allez et Trajet_Retour
Cependant, cela complique grandement mon MCD et je ne suis à présent plus sur qu'il soit viable.

Je vous envoie une screenshot de mon MCD (réalisé sous Win'design), merci de me faire part de vos commentaires!



En attendant vos réponses, merci de votre attention. cordialement

[JPhi33]

Bonjour thomasdo,

Ton postulat est qu'un trajet peut être systématiquement emprunté dans les deux sens, aller et retour. Je pense que ce postulat doit être remis en cause : ce n'est pas parce que le pilote effectue A --> B --> Entreprise le matin qu'il va emprunter le même chemin en sens inverse le soir ; il peut préférer Entreprise --> C --> A pour de multiples raisons, à cause des embouteillages, parce qu'il doit passer à la crèche récupérer son enfant, etc.

Ensuite, le fait d'ordonner les étapes (entité Etape) type obligatoirement le trajet : il est soit de type aller, soit de type retour.

Trajet
Pour ces deux raisons, il me semble qu'il est plus judicieux de considérer que chaque trajet est typé aller ou retour, ce qui se modélise :

[ Trajet ]--1,1----( )----0,n->[ Sens ]

l'entité Sens contenant les deux occurrences ALLER et RETOUR.

Ce n'est pas pour autant qu'il faut jeter la spécialisation aux orties, comme on va le voir plus loin.


Horaires
Il y a 3 horaires, heureDépart et heureArrivée pour un trajet aller, heureRetour pour un trajet retour, dont la signification est aisément compréhensible. Du fait de la spécificité de ces horaires, il faut conserver la spécialisation en Trajet_Aller et Trajet_Retour mais pas comme tu l'as modélisée. Il ne faut qu'une seule spécialisation (improprement "héritage"), représentée par le symbole triangulaire, à laquelle les deux entités sont liées : c'est UNE spécialisation en deux entités.

Trajet_Aller contient la propriété heureArrivée qui est l'heure à laquelle le pilote arrive à l'entreprise. Symétriquement, Trajet_Retour contient la propriété heureRetour qui est l'heure à laquelle le pilote part de l'entreprise.

Pour heureDépart on peut trouver une place beaucoup plus judicieuse que dans l'entité Trajet_Aller. En effet, dans cette entité, elle désigne seulement l'heure de départ du début du trajet. Mais si on la place dans l'entité Etape, on obtient l'heure à laquelle on passe à cette étape. Dans l'exemple du début, on aurait ainsi un horaire pour A (le départ) et un pour B (la 2e étape) ce qui permet aux agents qui habitent B d'être renseignés sur l'horaire de passage à B des covoiturages qui viennent de plus loin. Du coup, on a la même chose pour les retours.


Autres entités
Les entités Jour et Demande doivent être liées à Trajet dont chaque occurrence est maintenant un aller ou un retour. Donc une demande ne peut pas porter sur l'aller et le retour mais que l'un des deux.

Chaque Trajet n'est lié qu'à un Pilote, donc si plusieurs pilotes proposent le même trajet, il y aura autant d'occurrences de Trajet, ce qui est le mieux en cas de modification du trajet par un pilote.

[thomasdo]

Bonjour JPhi33 et merci pour votre réponse.
J'ai bien pris note de vos remarques et j'ai modifié mon MCD en conséquence.
J'ai repris la plupart de vos idées que je trouve très bonnes et j'ai avancé dans ma reflexion de mon côté.
Voila, je me suis dit qu'un agent pouvait effectuer une demande pour une offre non existante (non proposée par un pilote), j'ai donc spécialisé mon entité Demande: Demande_Offre_Existante et Demande_Offre_Non_Existante.
Une Demande_Offre_Non_Existante sera identifiée par la Ville et le jour requéttés par l'agent.
Les pilotes pourrons consulter ces demandes et proposer une offre.
Voila, je poste le nouveau MCD en question, en vous remerciant d'avance pour vos précieux conseils.
Cordialement

[JPhi33]

j'ai donc spécialisé mon entité Demande: Demande_Offre_Existante et Demande_Offre_Non_Existante.

Attention, ici encore, c'est UNE spécialisation en DEUX entités (et non pas deux spécialisations).


Justement, en ce qui concerne les Demande_Offre_Existante, il y a quelques inconvénients. En l'état actuel du MCD :
- je peux créer une demande portant sur un trajet défini pour lundi et mardi et lier ma demande au mercredi. Ce n'est pas cohérent
- je ne peux pas créer une demande pour mercredi et jeudi
- je peux créer une demande sur un trajet complet (plus de place libre dans le véhicule)

[thomasdo]

Bonjour JPhi33 et merci pour vos précisions ,
Pour répondre aux inconvénients soulevés:

Je suis concient de ces remarques (il y en aurais dailleurs d'autres à faire comme le fait qu'il est possible pour un agent de proposer 2 trajets pour le même jour) mais je ne souhaite pas les modéliser dans le schèma de la base de donnée, les contraintes posant souvent des problèmes lors de la génération du script à partir du mcd.

Je comptait en fait gérer ces execptions au cas par cas au cours du développement de l'application.

Concernant votre remarque
"je ne peux pas créer une demande pour mercredi et jeudi"
Cette fois-ci c'est volontaire: une demande ne concernant qu'un jour au maximum. Une demande pour mercredi et une autre pour jeudi donc.

Voila, n'hésitez pas à me dire si vous voyez des améliorations à apporter.
Merci pour votre attention, cordialement