Discussion :

[Hisoka17]

Bonjour à toutes et tous,

Je suis novice en conception et développement c'est l'un de mes premiers projets en termes de conception. Mes connaissance de la méthode Merise sont très limitées et j'ai encore beaucoup de mal à définir quelles entités devraient être liées et la logique à adopter de manière générale.

Le concept en bref: Réalisation d'une application web pour une salle de sport. Cette application a pour priorité un site vitrine (présentation des services, tarifs, prise de contact) mais je souhaite également offrir diverses fonctionnalités aux utilisateurs du site (s'enregistrer, consulter le planning des entraînements, consulter les exercices donnés pour un entraînement planifié et les participants, consulter des ressources, réserver un produit, réserver une séance..).

Voici quelques règles de gestion:

• Un visiteur doit pouvoir s'enregistrer, se connecter;
  
• Un utilisateur doit disposer d'un et un seul rôle (membre avec abonnement, membre sans abonnement, instructeur, administrateur);
  
• Un utilisateur pourra consulter des ressources en fonction de son rôle. Ressources qui peuvent inclure des fichiers;
  
• Des images et fichiers pourraient être stockées sur le serveur pour être mis à disposition dans différents contextes;
  
• Un utilisateur dispose d'informations de contacts et sera assigné à une salle en particuliers (pour l'instant il n'existe qu'une seule salle, mais en prévision d'un développement potentiel une salle comporte des informations de contacts également);
  
  
• La salle propose des produits en vente sur place, le site devra permettre d'exposer les produits et les informations qui les concernent;
  
• Un membre avec abonnement (ne peut disposer que d'un seul abonnement à la fois) pourra réserver une quantité unique par modèle;
  
• Un abonnement donne droit à un nombre limité de séances par semaine;
  
• Les produit seront classés par catégorie;
  
• En fonction de l'abonnement choisi une catégorie sera assignée pour un membre donné.
  
  
• Une activité comprend un entraînement et un groupe de participants (nombre de participants limités par entraînement);
  
• Un entraînement est composé de un ou plusieurs exercices, exercices dont les records (meilleures performances) peuvent être affichés pour une salle donnée;
  
• Il y à différents types d'entraînements qui pourront être suivis par la catégorie de membres adaptée;
  
• Une réservation fait référence à un créneau qui est fixé pour une activité. Cependant il peut y avoir plusieurs activités en même temps si un jour plusieurs instructeurs seront actifs pour une même salle;
  
• Une réservation ciblera un et un seul créneau en particuliers. Créneau qui sera bloqué pour une activité donnée.
  
• Le planning devra être affiché mensuellement et quotidiennement;
  
• Les exercices pour un entraînement d'un créneau spécifié pourront être affichés de manière automatique par rétro-projecteur dans la salle qui dispense ce cours.

L'utilisateur ayant un rôle d'un administrateur pourra concrètement:

• Disposer de fonctions d'ajout, consultation, modification, suppression sur toutes les entités qui nous intéressent (articles / des utilisateurs / entraînements / activités / exercices / abonnement / réservation);

Pour le moment mes priorités se portent sur:

• La conception de la partie vitrine du site;
  
• Les fonctionnalités liées aux rôles pour la consultation de contenu pour les membres;

Ultérieurement selon ma progression et mes capacités:

• Travailler sur la partie réservation (avec paiement intégré) et planning;
  
• Elaboration de programmes d'entraînement automatiques;

J'espère avoir apporté assez d'informations pour clarifier le contexte. J'ai beaucoup d'idées mais je vais procéder par étapes.

Merci d'avance pour vos commentaires et suggestions.

[Hisoka17]

Bonjour,

Entre temps j'ai fait quelques modifications pour certains éléments que j'avais omis à savoir:

• Retrait de tous les attributs "type" que l'on pouvait retrouver dans différentes entités du fait de la présence d'une entité "type" dédiée.
• Ajout d'attributs omis dans la table produit,
• Changement du verbe utilisé pour l'association entre Catégorie et Abonnement => dans la logique, en souscrivant à un abonnement un membre est "associé" à une catégorie en particuliers et sera amené à suivre les entraînements adaptés à cette catégorie (un senior suivra peu probablement les entraînements de haute intensité),
• Ajout de propriétés oubliées dans l'entité réservation,
• J'ai finalement inséré l'attribut quantité dans la table produit car comme je l'ai lu du fait d'une relation 1,N il serait préférable de faire l'ajout du côté 1,1 de la relation avec Modèle,

Bonne journée

[fsmrel]

Bonsoir Hisoka17

Selon votre MCD, une réservation détermine un utilisateur et un utilisateur détermine un abonnement :
une réservation détermine donc un abonnement. Dans ces conditions, pourquoi mettre en oeuvre une association (permettre) entre les entités-types Reservation et Abonnement ?

L’association désigner entre les entités-types Creneau et Reservation est redondante, car une réservation détermine une activité et une activité détermine un créneau : une réservation détermine donc un créneau. L’association désigner entre les entités-types Creneau et Reservation est donc une redondance, c’est-à-dire à évacuer.

[Hisoka17]

Bonsoir Hisoka17

Selon votre MCD, une réservation détermine un utilisateur et un utilisateur détermine un abonnement :
une réservation détermine donc un abonnement. Dans ces conditions, pourquoi mettre en oeuvre une association (permettre) entre les entités-types Reservation et Abonnement ?

L’association désigner entre les entités-types Creneau et Reservation est redondante, car une réservation détermine une activité et une activité détermine un créneau : une réservation détermine donc un créneau. L’association désigner entre les entités-types Creneau et Reservation est donc une redondance, c’est-à-dire à évacuer.

Bonjour fsmrel,

Merci pour votre réponse. Je prends note de vos remarques.

Dans mes réflexions la logique était:

- Un utilisateur va choisir un type d'abonnement, selon cette abonnement il pourra poser des réservations en fonction de cet abonnement (par exemple sur un abonnement type senior, il pourra uniquement s'inscrire à des cours dédiés aux seniors. Cela défini en quelques sortes le "type" d'utilisateur. et les possibilités qui s'offrent à lui.

En parallèle de cela j'ai tout de même conservé la relation entre les entités Utilisateur et Réservation car il existe des offres sans abonnement (essai gratuit, offres pour un nombre de séances données), de plus l'utilisateur va souvent être amené à poser des réservations et donc des traitements se feront fréquemment entre ces entités. Est-il réellement moins fastidieux en terme de développement de fonctionner de cette manière ou c'est inévitablement un doublon à retirer ?

-En effet, d'autant plus que le planning est fixe à l'heure actuelle je perçois mieux l'erreur.

Encore merci pour vos conseils.

[escartefigue]

Bonjour Hisoka17,

À mon sens, l'abonnement n'est associé qu'à un seul utilisateur et chaque abonnement est d'un certain type.
Ensuite la réservation concerne un équipement (le sauna, la salle de musculation, la piscine...) pour une une plage horaire et une date.
Et ce n'est pas l'abonnement, mais le type d'abonnement qui permet de réserver un équipement.
Par exemple, un abonnement de type "prémium" permet de réserver le sauna, ce que ne permet pas l'abonnement de base.

Il faudra donc vérifier que l'utilisateur qui veut réserver tel équipement, bénéficie d'une abonnement d'un type qui autorise la réservation de cet équipement.

Sommes nous d'accord sur ce qui précède ?

N'hésitez pas à donner des exemples pour éclairer nos lanternes