Discussion :

[sorcade]

bjr,
je dois réaliser une base de données pour des horaires de bus: je vois bien les objets lignes et arrêts avec une ligne a n arrêts et une station a 1,n ligne. Il y a aussi un objet période (semaine, dimanche...). Mais ensuite je trouve rien de "propre" pour les horaires ! J'ai bien imaginé une table trajet qui aurait en clé primaire : ligne/période/id_trajet mais ensuite je me retrouve avec des cases vides ! En effet, en fonction des périodes, le bus ne s'arrete pas forcement aux mm arrets et pire les lignes différentes ont un nombre d'arrets différents !

ligne période id_trajet h1 h2 h3 h4 h5 h6 h7 h8
1 1 1 6h10 6h11 6h15 6h20 6h22 6h24
1 1 2 6h18 6h19 6h23 6h28 6h30 6h32
1 2 1 6h10 6h11 6h17
2 1 1 5h45 5h48 5h49 6h00
2 2 1 5h50 5h51 5h54 6h03

pour voir le tableau ci dessus avec mise en forme, voir l'image)



un grand merci à tt ceux qui m'aideront.

[hed62]

Il te faut une entité HoraireDePassage, qui a une association avec la Ligne, l'arret, une heure et une période.

Tu pourra ainsi obtenir les informations souhaitées.

[sorcade]

bonjour et désolé de n'avoir répondu plus tot (3 semaines de vac)
voici en fichier joint un mpd que je vous soumets à critique. Je trouve que mon problème est assez difficile à modéliser, enfin quand je pense aux traitements qu'il y aura derrière...
La table trajet me sert à numéroter les passages successifs des bus aux arrets
Merci de vos aides (précieuses)

[JPhi33]

Bonjour sorcade,

La plupart des difficultés rencontrées en modélisation provient d'une définition approximative ou erronée des termes (concepts) utilisés. Lorsqu'on fait l'effort de réfléchir à la signification (la sémantique) de chaque information pour aboutir à une définition exacte, le reste suit presque sans difficulté.

je dois réaliser une base de données pour des horaires de bus: je vois bien les objets lignes et arrêts avec une ligne a n arrêts et une station a 1,n ligne. Il y a aussi un objet période (semaine, dimanche...).

Termes à définir :
- ligne
- arrêt
- station
- période

J'ai bien imaginé une table trajet qui aurait en clé primaire : ligne/période/id_trajet mais ensuite je me retrouve avec des cases vides ! En effet, en fonction des périodes, le bus ne s'arrete pas forcement aux mm arrets et pire les lignes différentes ont un nombre d'arrets différents !

Terme à définir :
- trajet

Lorsque chaque terme aura reçu sa définition (complète, précise, non ambigüe) le travail de modélisation s'en trouvera grandement facilité. En cours de réflexion, d'autres termes risquent d'apparaître (oubli, nécessité de précision, ...)

Bon courage et fais-nous part de tes réflexions.


JPhi33

[sorcade]

definitions des objets:

ligne (de bus): comme le dico = parcours géographique d'un bus déservant plusieurs stations soit en "aller" soit en "retour";
station: = arrêt physique des bus à des horaires théoriques précis.
ligne-station: mise en relation des stations appartenant aux lignes avec un ordre de passage
periode: periode de l'année déterminant un (ou pas de) passage et les horaires qui y sont relatifs.
trajet: passages successifs d'un bus dans une journée (1er passage, 2nd passage ...)
horaire: condionné par une station d'une ligne à une période donnée et à un trajet précis; ex: la station "mairie" est déservie par la ligne 3 lors de son 3eme passage de la période "vacances scolaires"

Que pensez vous de mon mpd ?
merci

[JPhi33]

Le MLD me semble en cohérence avec les définitions données.

Il comporte une erreur sur la table horaire. En effet, rien n'interdit la création d'un horaire pour une station non désservie par une ligne. Un petit exemple pour illustrer cela :

La Ligne 3 dessert les stations "Mairie" et "Eglise" mais pas la station "Rue Sorcade". Ceci est matérialisé par la présence des deux premières stations et l'absence de la 3e dans la table ligne_station pour la ligne 3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Table ligne_station

id_ligne l_sens id_station n_ordre
======== ====== ========== -------
3        aller  Mairie     1
3        aller  Eglise     2

Mais rien n'interdit de créer la ligne (en rouge) ci-dessous dans la table horaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Table horaire

id_ligne l_sens id_station  id_periode id_trajet horaire
======== ====== =========== ========== ========= -------
3        aller  Mairie      semaine    1         6h30
3        aller  Eglise      semaine    1         6h37
3        aller  Rue Sorcade semaine    1         6h30

Pour éviter ce type d'erreurs, il faudra contrôler par traitement la validité de chaque ligne avant la créer dans la table horaire.

Il existe une solution offrant le double avantage :
- d'éviter la mise en place de ces contrôles par traitement
- de rendre le modèle plus sémantique

Pourquoi plus sémantique ? Parce qu'une définition n'a pas été traduite correctement, ou du moins pas complètement, dans le modèle (d'où l'importance des définitions précises, complètes et non ambiguës que je rappelais dans mon précédent message). La voici :

horaire: condionné par une station d'une ligne...

Cette partie de définition sous-entend que la station doit être desservie par la ligne, information que l'on obtient dans la table "ligne_station". En conséquence, la table "horaire" doit référencer la table "ligne_station" et non pas "ligne" et "station" indépendemment l'une de l'autre. Ceci garantit l'impossibilité de créer un horaire pour une station non desservie par la ligne.

Tu noteras que cette modélisation laisse inchangées les clés de la table "horaire".


JPhi33

[sorcade]

bonjour et merci de ta réponse judicieuse et développée. Bonne continuation

[orwen]

une petite chose m'étonne:
dans ta table site_ref_ligne, tu prends le soin de mettre le sens comme clé primaire.
Mais le sens n'est pas une information qui à trait à la ligne mais au rapport entre la ligne et la station.
la ligne l traverse la station s dans le sens x.
Cela tombe d'autant mieux que ta table horaire se base désormais sur ta table ligne_station. tu éviterais ainsi une redondance.

[sorcade]

En prévision de pouvoir désactiver un aller ou un retour indépendamment