Discussion :

[Sonia_]

Bonjour,
merci de m'aider à corriger ce diagramme de classe pour la création d'un site web de rservation de chambre d'hotel
merci d'avance

[escartefigue]

Bonjour,

Un diagramme qu'il soit de formalisme Merise ou UML n'est qu'une traduction sous forme de schéma de règles de gestion.

Où sont ces règles de gestion, où est le cahier des charges ou l'énoncé ?

[Sonia_]

Bonsoir,
Je n'ai pas un cahier de charge. C'est un mini projet dont le but est la création d'un diagramme de classe puis la création d'un site web.

[escartefigue]

Un remarque préalable : les classes d'entité doivent porter un nom au singulier "client" plutôt que "clients" et "chambre" plutôt que "chambres". En effet, il s'agit d'un type d'entité et on se doute bien que chaque classe aura potentiellement plusieurs instances.

Ensuite, votre modèle autorise plusieurs réservations d'une même chambre à la même date, ça ne va pas.

Par ailleurs, il ne sert à rien de faire 3 classes "client", "manager" et "personne" avec les mêmes attributs.
Il faut mutualiser ce qui leur est commun dans une classe unique et utiliser l'héritage en créant un sous-type pour ce qui est particulier.
Dans le modèle que je propose, j'ai créé un type d'entité "personne" et un sous-type "employé", la personne effectue des réservations mais seul le sous-type "employé" peut enregistrer cette réservation.

Les chambres d'hotel sont ce qu'on appelle des "entité-type faibles" : si l'hotel disparait, la chambre disparait aussi.
Ce faisant, on peut identifier la chambre relativement à l'hotel.

Idem pour les réservations qu'on peut identifier relativement à la personne qui effectue cette réservation.

Enfin, à titre didactique, j'ai externalisé les adresses courriel et téléphone des hotels dans une entité-type "media".
En effet, pour les grands hôtels, on peut facilement imaginer avoir besoin d'un téléphone de l'accueil, d'un autre pour la comptabilité, un troisième pour les services techniques, éventuellement plusieurs adresses courriel, des n° de fax, etc.
Je n'ai pas fait de même pour les clients, car les concernant, on n'aura le plus souvent besoin que d'un numéro de tel et d'une adresse courriel.

Ce qui donne le modèle conceptuel suivant selon le formalisme Merise :



Le type d'entité CA_calendrier est ce qu'on appelle une entité-type fictive : elle ne deviendra pas une table (ce serait inutile), elle n'est utile que pour participer à la PK (primary key) de la table résultante de l'association ternaire CO_concerner
La flèche partant de CO_concerner et en direction de RS_reservation matérialise la contrainte selon laquelle une même chambre à une même date ne peut faire l'objet que d'une seule réservation.

Ce modèle Merise donne le diagramme UML suivant :

[escartefigue]

Remarque supplémentaire : il ne faut pas d'attribut nombre de chambres dans la classe "hotel", car c'est une redondance et donc un risque d'incohérence. Il faut le calculer en comptant les chambres associées à l'hôtel.
Stocker une valeur calculée est presque toujours une erreur de modélisation (à l'exception des comptages de type inventaire, c'est à dire les valeurs figées pour une date).

[Sonia_]

Bonsoir,
Merci pour votre réponse
Je n'ai pas compris comment je peux faire ça avec poweramc designer

Le type d'entité CA_calendrier est ce qu'on appelle une entité-type fictive : elle ne deviendra pas une table (ce serait inutile), elle n'est utile que pour participer à la PK (primary key) de la table résultante de l'association ternaire CO_concerner
La flèche partant de CO_concerner et en direction de RS_reservation matérialise la contrainte selon laquelle une même chambre à une même date ne peut faire l'objet que d'une seule réservation.

De plus j'ai ajouté un attribut état à la classe chambre (énumération), pour afficher par la suite au clients que les chambres ayant l'état libre à une date donnée et pour éviter de réserver une même chambre à la même date .
mercid'avance

[escartefigue]

Quand j'utilisais Power AMC il y a quelques années, on ne pouvait pas le faire au niveau du MCD. Il fallait intervenir dans le MLD pour éliminer de la PK de la table résultante l'identifiant de la réservation. Sauf si Power AMC a évolué depuis, il est en retrait sur ce point comparativement à Looping.

Il ne faut surtout pas ajouter un attribut pour savoir si une chambre est libre ou pas.
La seule façon fiable de savoir si une chambre est libre, c'est de vérifier qu'il n'exite pas de réservation pour la période qui nous intéresse.
On consultera pour ce faire la table issue de l'association CO_concerner