Mon modèle de réservation de chambres est-il correct?

**aurelius91** · 19/03/2009, 18h11

Bonsoir à tous !!

Je suis étudiant et dans le cadre d'un cours de bases de données, je dois réaliser un MCD concernant la gestion d'un ensemble de stations de ski...
Voici ci-dessous le sujet...

Le responsable de la gestion des réservations d’un ensemble de stations de ski désire vous confier une mission d’audit de la gestion des stations, des hôtels et de ses processus de réservation de chambres pendant toute l’année. Cette mission va consister à analyser un cahier des charges pour en extraire un schéma Entité-Association décrivant les données à gérer.

Une station a un numéro unique et un nom. Une station se situe dans une région. Une région a un nom unique et est caractérisée par une altitude. Dans la même région, plusieurs stations peuvent exister.

Chaque station a un ensemble d’hôtels pour accueillir les skieurs en hiver, ou les amateurs de montagne en été. Un hôtel est identifié par un numéro unique et a un nom, une adresse et une catégorie (« 1 étoile », « 2 étoiles », ..., « 5 étoiles »).

Chaque hôtel a un ensemble de chambres numérotés de 1 jusqu’au nombre de chambres de l’hôtel en question. Les chambres ont un certain nombre de lits et une salle d’eau privée ou publique (partagée avec d’autres chambres). Si la chambre inclue un salon, elle est de type « Suite», sinon de type « Simple ». Le prix d’une chambre par nuit varie en fonction de la saison. Une saison est identifiée par un nom unique (par exemple « Haute-saison »). Elle est caractérisée par une date de début, une date de fin et un prix.

Les clients sont identifiés de manière unique par un numéro. Ils ont un nom, une adresse et un téléphone.

Les clients qui le souhaitent, peuvent devenir «très bons clients» d’une station pendant un an et s’abonner à la station pour pouvoir la fréquenter avec un prix réduit.

Les chambres sont réservées pour une semaine identifiée par un numéro de 1 à 52.

J'ai réalisé le MCD (avec Publisher pour le moment, désolé), que je mets en PJ... Pouvez-vous me dire ce que vous en pensez svp (j'ai notamment du mal à gérer le statut client qui entraîne une tarification différente...) ?

Merci beaucoup.

**JPhi33** · 22/03/2009, 17h22

Bonjour,

Quelques premières remarques.

Prends l'habitude de souligner systématiquement les identifiants des entités ; pour certaines ce n'est pas fait (station, région, chambre, ...)
A quoi correspondent les doubles associations entre Réservation et Date, d'une part, et entre Saison et Date, d'autre part ? Plus généralement, à quoi sert l'entité Date ?
Une propriété ne doit apparaître qu'une seule fois dans un MCD. Plusieurs propriétés contreviennent à cette règle :
- n° unique
- nom
- date début
- date fin
- prix
- ...

Envoyé par aurelius91

Une station se situe dans une région.

Donc la cardinalité est 1,1 et non pas 0,1.

Envoyé par aurelius91

Un hôtel est identifié par un numéro unique et a un nom, une adresse et une catégorie

Il serait plus logique que l'entité Type Hotel se nomme CategorieHotel.

Envoyé par aurelius91

Chaque hôtel a un ensemble de chambres numérotés de 1 jusqu’au nombre de chambres de l’hôtel en question.

Donc plusieurs hôtels ont la chambre n° 1. Or, dans ton MCD, une chambre n'est associée qu'à un seul hôtel donc un seul hôtel pourra avoir la chambre n°1 (il va y avoir de la bagarre entre les gérants

). Tu as donc un problème de modélisation... et 2 solutions pour le résoudre. Je te mets sur la piste :

La technique dite "du numéro bidon" : peu élégante car non sémantique
La technique de l'identification relative : élégante, sémantique et, de plus, performante en base de données.

Envoyé par aurelius91

Si la chambre inclue un salon, elle est de type « Suite», sinon de type « Simple ».

L'entité TypeChambre est justifiée mais elle n'est pas correctement identifiée.
Pourquoi inclure "N°Hotel" dans l'identifiant ? Au passage, l'identifiant d'un Hotel est "N°unique" (même s'il est incorrect car redondant avec l'identifiant de la Station) et non pas N°Hotel.

Un prix est un mauvais identifiant pour une entité (TarifChambre) car il variera très probablement au cours du temps.

Il y a d'autres remarques mais j'arrête là pour l'instant faute de temps.

JPhi33

**aurelius91** · 22/03/2009, 18h27

Bonjour,

Merci de vos réponses, ravi d'avoir les retours d'un pro !

J'ai essayé de résoudre les problèmes que vous m'avez pour le moment soumis :

A quoi correspondent les doubles associations entre Réservation et Date, d'une part, et entre Saison et Date, d'autre part ? Plus généralement, à quoi sert l'entité Date ?

J'avais mis cette entité date pour faciliter la gestion des dates de début et de fin des réservations... Notamment, comment gérer la consigne "Les chambres sont réservées pour une semaine identifiée par un numéro 1 à 52" ??
J'ai supprimé cette entité Date et mis à la place "DateDebut, Datefin et Semaine" dans l'entité Réservation... suis-je sur la bonne piste ?

Une propriété ne doit apparaître qu'une seule fois dans un MCD. Plusieurs propriétés contreviennent à cette règle :
- n° unique
- nom
- date début
- date fin
- prix
- ...

Normalement, les propriétés sont correctes maintenant.

Donc plusieurs hôtels ont la chambre n° 1. Or, dans ton MCD, une chambre n'est associée qu'à un seul hôtel donc un seul hôtel pourra avoir la chambre n°1 (il va y avoir de la bagarre entre les gérants

). Tu as donc un problème de modélisation... et 2 solutions pour le résoudre. Je te mets sur la piste :

La technique dite "du numéro bidon" : peu élégante car non sémantique
La technique de l'identification relative : élégante, sémantique et, de plus, performante en base de données.

J'ai utilisé la 2ème solution, j'espère l'avoir bien comprise et appliquée.

L'entité TypeChambre est justifiée mais elle n'est pas correctement identifiée.
Pourquoi inclure "N°Hotel" dans l'identifiant ?

J'ai essayer d'utiliser également une identification relative à ce niveau-là.

Un prix est un mauvais identifiant pour une entité (TarifChambre) car il variera très probablement au cours du temps.

Là malheureusement, je sèche complètement... Je ne sais pas du tout comment gérer le prix en fonction : de la saison, du type de chambre et de la qualité du client "fidèle ou pas"...

Merciii

**f-leb** · 22/03/2009, 20h49

bonsoir,

Je ne sais pas du tout comment gérer le prix en fonction : de la saison, du type de chambre et de la qualité du client "fidèle ou pas"...

C'est parce que vous êtes pas aidé, l’énoncé de votre exercice concernant les tarifs, il ne dit que ça:

Le prix d’une chambre par nuit varie en fonction de la saison. Une saison est identifiée par un nom unique (par exemple « Haute-saison »). Elle est caractérisée par une date de début, une date de fin et un prix.

et c'est tout ?
J'ai bien lu

? Une colonne prix/nuitée dans la table ‘saison’ donc.
Ben moi qui me contentait bêtement en haute-saison de mon 1 étoile avec toilette ‘publique’ au fond de la cours alors qu’en même temps, pour le même prix, je pouvais bénéficié d’une suite dans un palace 5 étoiles.

Ah je vois quand même dans votre MCD une table 'Tarif' en relation avec hotel, typechambre et saison. C'était donc mon esprit retord qui interprétait mal votre énoncé

Vous êtes sûr de nous avoir donné l’énoncé de l’exercice en entier ?

A part ça je vois des associations étranges 1,1. Par exemple un hotel est concerné par une réservation maxi

, pour un type de chambre il n’ y a qu’une chambre maxi.

Une réservation peut concerner plusieurs chambres mais qu’un seul type de chambre ? C'est possible ça?

voilà ce sera tout pour moi ce soir...

**aurelius91** · 23/03/2009, 11h01

Bonsoir f-leb, et merci de votre réponse également

Je ne sais pas du tout comment gérer le prix en fonction : de la saison, du type de chambre et de la qualité du client "fidèle ou pas"...

C'est parce que vous êtes pas aidé, l’énoncé de votre exercice concernant les tarifs, il ne dit que ça:

Le prix d’une chambre par nuit varie en fonction de la saison. Une saison est identifiée par un nom unique (par exemple « Haute-saison »). Elle est caractérisée par une date de début, une date de fin et un prix.

et c'est tout ?
J'ai bien lu? Une colonne prix/nuitée dans la table ‘saison’ donc.

éh oui l'énoncé est bien en entier... d'un côté ça me rassure parce que l'énoncé n'est pas assez précis, de l'autre côté je m'inquiète de savoir comment je vais gérer ces prix

A part ça je vois des associations étranges 1,1. Par exemple un hotel est concerné par une réservation maxi, pour un type de chambre il n’ y a qu’une chambre maxi. Une réservation peut concerner plusieurs chambres mais qu’un seul type de chambre ? C'est possible ça?

C'est corrigé, en effet, l'heure avancée à laquelle j'ai mis ces cardinalités n'a pas dû m'aider, même si je n'ai pas d'excuse ;-)...

Ci-joint la version modifiée, qui progresse bien grâce à vous

!

**JPhi33** · 24/03/2009, 01h13

Bonjour aurelius91,

Ton MCD a bien progressé. Revoyons un par un les points déjà évoqués.

Soulignement des identifiants
Il n'y en a qu'un qui a échappé à ta vigilence : l'identifiant de CLIENTS (C_num)

Entité Date
Effectivement, cette entité n'était pas pertinente. Sa suppression (et son cortège de double associations) était la meilleure chose à faire.

Unicité des propriétés
Il reste encore des doublons :

H_num dans CHAMBRE
Ch_num dans TYPE CHAMBRE

Nous verrons plus loin comment éliminer ces redondances afin de respecter la règle fondamentale d'unicité des propriétés.

Passons aux points plus délicats.

Les chambres
Un point essentiel : l'entité CHAMBRE est correctement identifiée ; tu as donc appliqué correctement le principe de l'identification relative. Il y a juste un problème de représentation graphique qui provoque la redondance de H_num et contrevient à la règle d'unicité des propriétés dont j'ai parlé plus haut.

Une entité (CHAMBRE) identifiée relativement à une autre (HOTEL) se nomme "entité faible" et se représente graphiquement d'une manière particulière, ce qui permet d'éliminer la redondance. La représentation graphique varie d'un logiciel de modélisation à un autre :

avec certains logiciels (comme PowerAMC), on note la cardinalité côté entité faible entre parenthèses donc : (1,1)
avec d'autre logiciels la cardinalité 1,1 est accompagnée de la lettre R
indépendemment des logiciels, il existe une autre notation qui consiste à représenter la "boîte" de l'entité faible avec des tirets (au lieu de traits pleins) et de noter dans l'association un symbole mathématique d'appartenance

Personnellement, quand je n'utilise pas de logiciel de modélisation, j'adopte la notation 3 mais je remplace le symbole d'appartenance par un "R" (plus simple), ce qui donne ceci :
Nom : Ident_Relative.gif
Affichages : 1421
Taille : 4,4 Ko

Nom : Ident_Relative.gif
Affichages : 1421
Taille : 4,4 Ko

Le type de chambre
Pourquoi ajouter le numéro de chambre dans l'identifiant de TYPE CHAMBRE ? L'association entre CHAMBRE et TYPE CHAMBRE est du même genre que celle qui aurait pu exister entre CHAMBRE et TYPE SALLE D'EAU si tu avais modélisé cette entité :

une chambre a un type de salle d'eau
une chambre a un type de chambre

C'est ce qu'on appelle une association de type "a-un" ("has-a" en anglais).

Tu as choisi de ne pas modéliser d'entité pour le type de salle d'eau, pourquoi le faire pour le type de chambre ?
A noter que la meilleure modélisation est celle de l'entité car elle permet de modifier les libellés correspondants avec un impact minimum. Si, au cours de la vie de la base de données, on souhaite transformer le libellé "salle d'eau publique" en "salle d'eau commune", il suffira de modifier le libellé contenu dans la table correspondant à l'entité TYPE SALLE D'EAU, alors que sans cette entité, il faudra mettre à jour toutes les chambres ayant une salle d'eau publique.

Le prix des chambres

Envoyé par aurelius91

Le prix d’une chambre par nuit varie en fonction de la saison.

Donc, a priori, il ne varie pas en fonction du type de chambre. Donc il ne faut pas associer TARIF CHAMBRE et TYPE CHAMBRE.

Comme on peut aisément imaginer que le prix d'une suite dans un 5 étoiles n'est pas le même que celui d'une chambre simple dans un 1 étoile, que faut-il comprendre de l'énoncé (qui est quand même plutôt confus à ce sujet) ? La seule solution est que le prix est déterminé pour chaque chambre de manière individuelle.

En conclusion, le prix dépend de la chambre, de manière individuelle, et de la saison. La modélisation correspondante est :

[ CHAMBRE ]--0,n----( Tarif )----0,n--[ SAISON ]

L'association Tarif contient la propriété Prix. Ainsi, le prix peut varier d'une chambre à l'autre et en fonction de la saison. L'entité TARIF CHAMBRE doit disparaître.

Reste la phrase mystère :

Envoyé par aurelius91

Une saison [...] est caractérisée par une date de début, une date de fin et un prix.

Si le prix dépendait de la saison, toutes les chambres auraient le même tarif dans la même saison ! Je pense donc qu'il s'agit d'une erreur dans l'énoncé (à confirmer par le rédacteur du sujet).

Pour terminer ce MCD, il restera à voir les clients et les réservations.

JPhi33

**aurelius91** · 28/03/2009, 21h41

Bonsoir Jphi33,

merci encore de votre aide et de toutes ces explications !!

Je viens seulement de voir votre réponse, d'où cette réponse 4 jours après... désolé.

Je vais réétudier et corriger tout ceci pour vous proposer une nouvelle version de mon MCD. Je suis occupé toute la semaine (un autre gros projet...

) donc j'étudierai tout ceci en fin de semaine prochaine... et reviendrai avec une V3 de mon MCD à ce moment-là.

Merci beaucoup !

**aurelius91** · 08/04/2009, 15h08

Bonjour,

J'ai retravaillé mon MCD...

Les chambres
Un point essentiel : l'entité CHAMBRE est correctement identifiée ; tu as donc appliqué correctement le principe de l'identification relative. Il y a juste un problème de représentation graphique qui provoque la redondance de H_num et contrevient à la règle d'unicité des propriétés dont j'ai parlé plus haut.

Une entité (CHAMBRE) identifiée relativement à une autre (HOTEL) se nomme "entité faible" et se représente graphiquement d'une manière particulière, ce qui permet d'éliminer la redondance. La représentation graphique varie d'un logiciel de modélisation à un autre

J'utilise AMCDesigner, la représentation est donc celle avec les parenthèses côté entité faible. J'ai donc intégré des parenthèses sur mon MCD et supprimé la propriété H_num de l'entité CHAMBRE.

A noter que la meilleure modélisation est celle de l'entité car elle permet de modifier les libellés correspondants avec un impact minimum. Si, au cours de la vie de la base de données, on souhaite transformer le libellé "salle d'eau publique" en "salle d'eau commune", il suffira de modifier le libellé contenu dans la table correspondant à l'entité TYPE SALLE D'EAU, alors que sans cette entité, il faudra mettre à jour toutes les chambres ayant une salle d'eau publique.

Concernant le type de chambre, j'ai ajouté une entité supplémentaire TYPE SDB, afin de faciliter les éventuels changements futurs que vous m'avez soumis.

En conclusion, le prix dépend de la chambre, de manière individuelle, et de la saison. La modélisation correspondante est :

[ CHAMBRE ]--0,n----( Tarif )----0,n--[ SAISON ]

Pourriez-vous m'expliquer les cardinalités 0,n que vous avez placé ici s'il vous plaît ?
Le prix d'une chambre étant également dépendant de la remise dont peuvent bénéficier les "très bons clients", j'ai également relié ( Tarif ) à l'entité STATUT CLIENT... Est-ce correct ?

Reste la phrase mystère :

Une saison [...] est caractérisée par une date de début, une date de fin et un prix.

Si le prix dépendait de la saison, toutes les chambres auraient le même tarif dans la même saison ! Je pense donc qu'il s'agit d'une erreur dans l'énoncé (à confirmer par le rédacteur du sujet).

Je pense que les deux phrases de l'énoncé suivantes reviennent au même :
- "Le prix d’une chambre par nuit varie en fonction de la saison."
- "Une saison [...] est caractérisée par une date de début, une date de fin et un prix."
La deuxième phrase aurait du être : "Une saison [...] est caractérisée par une date de début, une date de fin. De plus, un prix différent s'applique aux chambres selon la saison".

Pour terminer ce MCD, il restera à voir les clients et les réservations.

Ca progresse !! merci encore

**JPhi33** · 09/04/2009, 00h46

Bonjour aurelius91,

Envoyé par aurelius91

Pourriez-vous m'expliquer les cardinalités 0,n que vous avez placé ici s'il vous plaît ?

Les cardinalités maximales sont n car une chambre a plusieurs tarifs (un par saison) et, de même, pour une saison le prix plusieurs chambres est fixé.

Mais je suppose que la question porte plutôt sur les cardinalités minimales à 0. Lorsqu'on fixe une cardinalité minimale à 1, on s'impose :

de fixer le prix de chaque chambre (cardinalité 1,n côté CHAMBRE)
d'associer chaque saison à des chambres (cardinalité 1,n côté SAISON)

Si on imagine mal une saison pour laquelle il n'y aurait aucune chambre tarifée (il faut donc une cardinalité mini 1 côté SAISON --> il y donc une erreur sur le schéma que j'ai proposé), on pourrait, par contre, envisager qu'une chambre donnée n'ait pas de tarif parce qu'elle est en construction, par exemple, ou en cours de rénovation, et qu'on n'en a pas encore fixé le tarif. Dans ce cas, si la cardinalité mini côté CHAMBRE est 1, on serait quand même obligé de fixer un tarif. On devrait alors fixer un tarif bidon ce qui n'est pas très satisfaisant puisqu'on a les moyens de faire autrement.

En résumé, voici le schéma correspondant à ce que je viens d'exposer :

[ CHAMBRE ]--0,n----( Tarif )----1,n--[ SAISON ]

Envoyé par aurelius91

Le prix d'une chambre étant également dépendant de la remise dont peuvent bénéficier les "très bons clients", j'ai également relié ( Tarif ) à l'entité STATUT CLIENT... Est-ce correct ?

Oui et non. En fait, l'énoncé n'est pas assez précis pour le dire (mais j'ai quand même mon idée sur la question). On sait seulement :

qu'il existe 2 statuts : "Très bon client" (TBC) et, disons, "Client normal"
que les TBC bénéficient d'un prix réduit

A mon avis, ces informations sont insuffisantes pour s'obliger de définir un tarif TBC pour toutes les chambres de tous les hotels de toutes les station et pour toutes les saisons. Car c'est bien ce que tu fais en associant STATUT CLIENT à CHAMBRE et SAISON par l'association Tarif.
De plus, cette solution impose le même tarif à tous les TBC (pour une même chambre dans la même saison).
On n'est vraiment pas dans la souplesse...

Personnellement, je pencherais plus pour la modélisation d'un pourcentage de réduction associé au client. J'y vois 2 avantages :

le tarif d'une chambre est calculé sur la base du tarif normal et on s'épargne la définition d'un 2e tarif
on peut définir des pourcentages de réduction différents selon les clients

Mais ça reste une supposition car, encore une fois, l'énoncé n'est pas assez précis.

Envoyé par aurelius91

Je pense que les deux phrases de l'énoncé suivantes reviennent au même :
- "Le prix d’une chambre par nuit varie en fonction de la saison."
- "Une saison [...] est caractérisée par une date de début, une date de fin et un prix."
La deuxième phrase aurait du être : "Une saison [...] est caractérisée par une date de début, une date de fin. De plus, un prix différent s'applique aux chambres selon la saison".

Bien vu. C'est aussi mon avis.

Le client
Le statut du client n'est pas modélisé correctement. L'entité STATUT CLIENT est identifiée par Type client. Quelles en sont les valeurs ? Pourquoi STATUT CLIENT est-il associé à STATION ?
Essaie de revoir cette modélisation avec les phrases suivantes :
- un client peut être TBC d'une station
- une station peut avoir de 0 à plusieurs TBC
- quand un client est TBC d'une station on définit une date de début et une date de fin et, si on retient ma proposition plus haut, un pourcentage de réduction
- le statut normal ne justifie pas d'association avec l'entité STATION (c'est le statut par défaut des tous les clients)

La réservation
Elle n'est pas non plus modélisée correctement. Que sait-on ?

Les chambres sont réservées pour une semaine identifiée par un numéro de 1 à 52.

Une chambre est évidemment réservée par un client mais rien ne dit dans l'énoncé que la réservation a quelque chose à voir avec la catégorie de l'hôtel ou la station. La semaine de réservation est identifiée par un numéro de 1 à 52, on ne parle pas de date de début ni de fin ; à la limite elles peuvent être des propriétés de la semaine.

Essaie de modéliser à partir de cette reformulation de l'énoncé :

Un client réserve une chambre pour une semaine (identifiée par un numéro de 1 à 52).

Bon courage.

**aurelius91** · 21/04/2009, 21h21

Bonsoir,

J'ai retravaillé mon MCD sur vos conseils.

J'ai supprimé quelques associations qui semblaient inutiles (entre CATEGORIE HOTEL et RESERVATION notamment)

Egalement, j'ai supprimé l'entité STATUT CLIENT et ai rajouté ( ABONNEMENT ) entre les entités CLIENTS et STATION avec les propriétés DateDébut, DateFin et %Remise... Suis-je sur la bonne piste ?

Merci beaucoup

**JPhi33** · 22/04/2009, 11h00

Bonjour,

Envoyé par aurelius91

J'ai supprimé quelques associations qui semblaient inutiles (entre CATEGORIE HOTEL et RESERVATION notamment)

Effectivement, ça s'imposait.

Envoyé par aurelius91

Egalement, j'ai supprimé l'entité STATUT CLIENT et ai rajouté ( ABONNEMENT ) entre les entités CLIENTS et STATION avec les propriétés DateDébut, DateFin et %Remise... Suis-je sur la bonne piste ?

Cette option est valide au regard de l'énoncé, lequel est suffisamment flou pour laisser le choix d'autres options mais on s'en tiendra là.

Concernant la réservation, là aussi il y a une autre possibilité (qui est de faire porter la réservation sur une seule chambre) mais ton choix est valide du point de vue de l'énoncé.

Il me semble que tu es parvenu au stade final de ce MCD.