Discussion :

[dev_lan]

Bonjour à tous,

je dois réaliser une bdd et je ne suis pas sur de mon MCD, voici mon problème. Je dois créer une application qui informera l'utilisateur sur l'état de disponibilité des stades. Cela se présentera sous la forme d'un numéro vert que l'utilisateur pourra appeler et l'application devra l'informer de la situation (à l'aide d'une synthèse vocale). Il y a 3 possibilités pour l'état de disponibilité*:

- Du lundi au vendredi les stades peuvent se trouver dans l'état «*planning normal*» ou «*plan B*» ou «*arrêté municipal*»
- Le week-end les stades peuvent se trouver dans l'état «*planning normal*» ou «*arrêté municipal »

Un arrêté municipal est pris sur une tranche horaire (heure_debut / heure_fin) pour une date donnée (date_jour) et peut concerner un ou plusieurs stades.

Du lundi au vendredi les jours sont divisés en «*demi-journée*» car un plan B concerne au minimum une demi journée et peut s'étendre sur plusieurs jours. Les plans B n'existent pas pour les week-end.
L'appli donnera l'information en fonction du jour ou l'utilisateur appelle, par exemple si l'utilisateur appelle le lundi matin, l'appli lui donnera la situation des stades pour lundi matin, si il appelle le samedi l'appli lui donnera la situation des stades pour le samedi.

Par exemple*:
En semaine un utilisateur décide d'appeler le numéro, selon la situation la synthèse vocale lui indiquera «*Les stades sont disponibles selon le planning normal*» ou «*Les stades sont disponible suivant le plan B*» ou encore «*Un arrêté municipal a été pris (sur tel stade) de tel heure à tel heure*»
En week-end, la synthèse vocale indiquera soit «* Les stades sont disponibles selon le planning normal*» ou «*Un arrêté municipal a été pris (sur tel stade) de tel heure à tel heure*».


Voici le mcd que j'ai réalisé*:



Et voici l'interface graphique de l'administrateur pour vous donner une idée du fonctionnement de l'application*:






Merci d'avance pour votre aide, si vous avez besoin de précisions n'hésitez pas.

[Richard_35]

Bonjour Dev_lan,

je dois réaliser une bdd...

==> OK, le MCD, donc la BdD, entraînera une logique de saisie des arrêtés et des états pour les stades.

Je dois créer une application qui informera l'utilisateur sur l'état de disponibilité des stades.

==> l'application exploitera la BdD pour informer l'utilisateur (requêtes).

Suggestion :


Dans l'idéal, il faut contrôler le non-chevauchement des périodes...

[dev_lan]

Salut Richard_35, merci d'avoir pris le temps de répondre, j'ai quelques questions par rapport à ton mcd.

Tout d'abord je pense que je me suis mal exprimé, un état concerne d'abord des périodes de temps et non les stades directement. Le planning normal est celui par défaut, un plan b est appliqué par demi-journée (voir l'interface graphique dans mon 1er post). Un arrêté concerne d'abord une date puis une plage horaire puis un ou plusieurs stades. Je suis d'accord avec ta partie du mcd concernant les arrêtés, mes questions portent plus sur la gestion planning normal / plan b.

Dans ton mcd, je mettrais les cardinalités 1,n entre les entités Stade et Etat, un stade est forcément dans un Etat.

De plus, si j'ai bien compris, les boutons radios fonctionneraient de la façon suivante : sur planning normal de "Date_Debut_1" à "Date_Debut_2" et sur plan B de "Date_fin_1" à "Date_fin_2" ? Peut on prendre en compte les demi-journées avec les types DATE ?

Enfin le trigger qui gère la contrainte "pas de plan b le week end" est-il nécessaire étant donné que le bouton radio "Plan B" n'est pas présent dans les jours du week-end dans l'interface ?

[Richard_35]

Bonjour Dev_lan,

...un état concerne d'abord des périodes de temps et non les stades directement...

==> cela veut-il dire qu'un état concerne des périodes de temps tous stades confondus ?

Le planning normal est celui par défaut

==> cela veut-il dire qu'un planning existe déjà ?
Si oui, existe-t-il déjà un MCD liant les stades à un planning ?
Si oui, peux-tu le présenter ?

Dans ton mcd, je mettrais les cardinalités 1,n entre les entités Stade et Etat, un stade est forcément dans un Etat.

==> OK. Mais, si tu crées un nouveau stade, il sera, temporairement, sans état. Mais bon, cela n'a pas beaucoup d'incidence.

De plus, si j'ai bien compris, les boutons radios fonctionneraient de la façon suivante : sur planning normal de "Date_Debut_1" à "Date_Debut_2" et sur plan B de "Date_fin_1" à "Date_fin_2" ?

==>

• Date_Debut : date de début de l'état ;
• Date_Debut_1 : matin (booléen) ;
• Date_Debut_2 : après-midi (booléen) ;
• Date_Fin : date de fin de l'état ;
• Date_Fin_1 : matin (booléen) ;
• Date_Fin_2 : après-midi (booléen).

Boutons radio sur Date_Debut_1/Date_Debut_2 et Date_Fin_1/Date_Fin_2 (impossibilité de cocher les 2).

Enfin le trigger qui gère la contrainte "pas de plan b le week end" est-il nécessaire étant donné que le bouton radio "Plan B" n'est pas présent dans les jours du week-end dans l'interface ?

==> rejoint la deuxième observation. L'interface présentée s'appuie donc sur une base de données. MCD ?

[dev_lan]

==> cela veut-il dire qu'un état concerne des périodes de temps tous stades confondus ?

Alors pour les états planning normal et plan B oui c'est le cas, mais pour un arrêté l'administrateur peut choisir les stades concernés (minimum 1 maximum tous)

==> cela veut-il dire qu'un planning existe déjà ?
Si oui, existe-t-il déjà un MCD liant les stades à un planning ?

Alors, oui le planning normal est déjà créé et utilisé, le "plan b" est un planning secondaire (utilisé en cas de fortes intempéries par exemple) déjà défini aussi. Ils sont définis sur "Google Calendar" mais aucun mcd n'a été fait à ma connaissance.

Le but de mon projet est justement de créer une application pour que les utilisateurs aient accès aux disponibilités des stades sans devoir contacter la personne chargée de ces plannings.
L'interface présentée à été réalisée en tant que maquette par moi-même, et je compte intégrer la BdD que je réalise à cette maquette.

D'accord pour les boutons radios, j'avais une autre approche je pensais à sélectionner l'état avec un bouton radio puis gérer les demi-journées avec un datetime.

Encore merci pour ton aide, ça me fait avancer !

[Richard_35]

Partie Arrêté :




Partie Etat :

[dev_lan]

Bonjour Richard_35,

c'est vrai que je n'avais pas pensé à dissocier en deux parties le mcd, ce que tu proposes me semble tout à fait correct ! Une petite précision concernant la création de la BdD, un identifiant relatif se modélise-t-il grâce à une clé étrangère ?

Merci encore, je vais pouvoir commencer à implémenter ma BdD.

[Richard_35]

Bonjour Dev_lan,

un identifiant relatif se modélise-t-il grâce à une clé étrangère ?

==> la clé étrangère est à intégrer à la table Date_Etat finale et ne se modélise pas dans le MCD (de mon point de vue).

Dans l'idéal, il faudrait contrôler le non-chevauchement des périodes saisies...

[dev_lan]

Dans l'idéal, il faudrait contrôler le non-chevauchement des périodes saisies...

Par rapport aux dates et à l'heure des arrêtés je suppose ? Pour ce qui est du planning normal / plan B le chevauchement n'est pas possible car si on change la valeur d'un bouton radio, cela supprime l'état précédent.

Pour ce qui est de l'entité Date_Etat il me semble bon mais me paraît un peu dur à manipuler, j'ai du mal à le comprendre. Ce ne serait pas plus simple de faire correspondre une demi-journée avec un état plutôt que délimiter les états par leurs dates ? (Exemple : lundi matin = plan b / lundi après-midi = plan normal, etc ...) .

Sinon pour ce qui des booléens, ne peut-on pas les regrouper en un seul : si il a pour valeur 0 alors c'est le matin, si il a pour valeur 1 alors c'est l'après-midi ?

[Richard_35]

Par rapport aux dates et à l'heure des arrêtés je suppose ?

==> Oui.
Peut-il exister 2 arrêtés pour la même date avec des tranches horaires différentes ?

Pour ce qui est du planning normal / plan B le chevauchement n'est pas possible car si on change la valeur d'un bouton radio, cela supprime l'état précédent.

==> à l'intérieur du même enregistrement de Date_Etat, oui, mais pas si l'utilisateur créé un autre enregistrement dans Date_Etat.

Pour ce qui est de l'entité Date_Etat il me semble bon mais me paraît un peu dur à manipuler, j'ai du mal à le comprendre. Ce ne serait pas plus simple de faire correspondre une demi-journée avec un état plutôt que délimiter les états par leurs dates ? (Exemple : lundi matin = plan b / lundi après-midi = plan normal, etc ...).

==> tu ne souhaites pas gérer les lundis différemment les uns des autres et conserver un historique ?

Sinon pour ce qui des booléens, ne peut-on pas les regrouper en un seul : si il a pour valeur 0 alors c'est le matin, si il a pour valeur 1 alors c'est l'après-midi ?

==> si, c'est possible, mais cela me paraissait plus clair de les différencier, surtout pour les requêtes à venir.

[dev_lan]

Peut-il exister 2 arrêtés pour la même date avec des tranches horaires différentes ?

Oui, exemple : un terrain doit accueillir 3 matchs dans la journée, un seul match a été annulé celui du "milieu" , l'administrateur doit alors "créer" deux arrêtés pour le même jour avec des heures différentes.

==> à l'intérieur du même enregistrement de Date_Etat, oui, mais pas si l'utilisateur créé un autre enregistrement dans Date_Etat.

C'est à dire qu'il ne pourrait pas revenir sur une décision ? Pourtant un état est bien enregistré en fonction de la date, si on sélectionne cette date on retrouve l'état, ou ce n'est pas le cas car la date n'est pas identifiant ?

==> tu ne souhaites pas gérer les lundis différemment les uns des autres et conserver un historique ?

Un historique n'a pas été demandé, par contre le lundi de la semaine à venir et le lundi dans deux semaines doivent être gérés différemment je pense selon leurs états.

==> si, c'est possible, mais cela me paraissait plus clair de les différencier, surtout pour les requêtes à venir.

C'est vrai que j'ai du mal à me projeter dans les futures requêtes, il est peut-être plus sage de les différencier dans ce cas.

[Richard_35]

Peut-il exister 2 arrêtés pour la même date avec des tranches horaires différentes ?

Oui, exemple : un terrain doit accueillir 3 matchs dans la journée, un seul match a été annulé celui du "milieu" , l'administrateur doit alors "créer" deux arrêtés pour le même jour avec des heures différentes.

==> Ma question était incomplète : peut-il exister, pour le même stade, 2 arrêtés pour la même date avec des tranches horaires différentes ?

==> à l'intérieur du même enregistrement de Date_Etat, oui, mais pas si l'utilisateur créé un autre enregistrement dans Date_Etat.

C'est à dire qu'il ne pourrait pas revenir sur une décision ? Pourtant un état est bien enregistré en fonction de la date, si on sélectionne cette date on retrouve l'état, ou ce n'est pas le cas car la date n'est pas identifiant ?

==> non, un état est enregistré en fonction d'une période, Date_Debut à Date_Fin, où Date_Debut et Date_Fin peuvent être différentes.

==> tu ne souhaites pas gérer les lundis différemment les uns des autres et conserver un historique ?

Un historique n'a pas été demandé, par contre le lundi de la semaine à venir et le lundi dans deux semaines doivent être gérés différemment je pense selon leurs états.

==> je ne omprends pas trop. Dans les règles de gestion initiales tu précisais :

Du lundi au vendredi les jours sont divisés en «*demi-journée*» car un plan B concerne au minimum une demi journée et peut s'étendre sur plusieurs jours. Les plans B n'existent pas pour les week-end.

==> il faut donc bien gérer, pour un état particulier, une période de {date de début matin ou après-midi} à {date de fin matin ou après-midi}.

[dev_lan]

==> Ma question était incomplète : peut-il exister, pour le même stade, 2 arrêtés pour la même date avec des tranches horaires différentes ?

Oui, un terrain peut être interdit de 8h a 10h puis de 15h a 17h mais disponible entre ces deux tranches horaires, il faudra donc deux arrêtés.

==> il faut donc bien gérer, pour un état particulier, une période de {date de début matin ou après-midi} à {date de fin matin ou après-midi}.

C'est vrai, mais je prends un peu d'avance en pensant à l'application finale ou l'administrateur choisira demi-journée par demi-journée, il ne choisira pas une date de début et une date de fin j'aurais du le préciser. L'administrateur n'effectuera son organisation que sur quelques jours voir 2/3 semaines je ne pense pas que cela soit trop embêtant de devoir choisir l'état de chaque demi-journée. Sinon je ne vois pas vraiment en quoi c'est incohérent, l'état d'un lundi A peut-être différent d'un lundi B ou le même.
Au final, je ne sais pas si avoir la "période" des états est nécessaire, sachant que le service doit donné l'état des stades au moment ou l'utilisateur appelle ?


En espérant avoir éclairci un peu plus le sujet !

[Richard_35]

Bonjour Dev_lan,

Reprenons, d'abord pour les arrêtés :

Dans l'idéal, il faudrait contrôler le non-chevauchement des périodes saisies...

Par rapport aux dates et à l'heure des arrêtés je suppose ?

==> Oui.
Peut-il exister 2 arrêtés pour la même date avec des tranches horaires différentes ?

==> Ma question était incomplète : peut-il exister, pour le même stade, 2 arrêtés pour la même date avec des tranches horaires différentes ?

Oui, un terrain peut être interdit de 8h a 10h puis de 15h a 17h mais disponible entre ces deux tranches horaires, il faudra donc deux arrêtés.

==> donc, dans le futur système, l'utilisateur devra saisir :

• un arrêté (un enregistrement dans la table) pour ce terrain, cette date, de 8h00 à 10h00 ;
• un autre arrêté (un autre enregistrement dans la table) pour ce terrain, cette date, de 15h00 à 17h00.

Lors de la saisie du second enregistrement, il faudra bien contrôler que l'utilisateur ne saisi pas, par erreur, 9h00 à 15h00 (c'est un exemple) sinon il y a chevauchement d'heure...

OK ?

[dev_lan]

Ah oui d'accord ! Je pourrais probablement gérer cette erreur avec un trigger qui se lance à chaque fois que l'on veut ajouter un élément dans la table arrêté et qui vérifie, grâce à une fonction, en premier lieu si un autre arrêté a déjà été enregistré pour cette date puis si l'heure de début est bien supérieure à l'heure de fin du 1er arrêté ?

[Richard_35]

Je pourrais probablement gérer cette erreur avec un trigger qui se lance à chaque fois que l'on veut ajouter un élément dans la table arrêté et qui vérifie, grâce à une fonction, en premier lieu si un autre arrêté a déjà été enregistré pour cette date puis si l'heure de début est bien supérieure à l'heure de fin du 1er arrêté ?

==> c'est cela même...
Arrêté :

...de devoir choisir l'état de chaque demi-journée.

==> ce qui donnerait :
Etat :


L'obligation de saisir les états jour par jour pourrait être pénalisant, mais bon... à toi de voir.

[dev_lan]

Je vais tout de même choisir la solution "jour par jour" car elle me paraît plus simple et que ce sera comme ça que l'application sera construite.

Merci beaucoup pour ton aide Richard_35, je me lance dans la réalisation de la Base de Données de ce pas et je marque ce sujet résolu.