Discussion :

[dix77]

Bonjour,

je souhaite créer un MCD pour gérer un hôtel et je bloque sur un point :
pour chaque chambre, il y a un prix de base pour une nuit et je voudrais pouvoir gérer le fait qu'on puisse fixer un prix exceptionnel pour une chambre, une nuit et un jour particuliers
par exemple, la chambre 217 a comme prix de base 70 euros pour une nuit mais pour la nuit du 31 décembre 2012 au 1 janvier 2013, je souhaite que le prix soit de 90 euros
Dans mon MCD, j'ai pensé à créer 2 entités "CHAMBRE" et "JOUR" et entre ces 2 entités une relation "A POUR PRIX EXCEPTIONNEL"
les cardinalités sont 0..n de chaque côtés
Dans mon modèle relationnel des données, je vais donc avoir 3 relations :
- CHAMBRE (id_chambre, ..., prix_de_base)
- JOUR (id_jour, date_jour)
- A_POUR_PRIX_EXCEPTIONNEL (id_chambre, id_jour, prix_exceptionnel)

Ce qui va donc me générer 3 tables au niveau de mon SGBDR alors qu'on pourrait regrouper les tables JOUR et A_POUR_PRIX_EXCEPTIONNEL, ce qui donnerait :
- CHAMBRE (id_chambre, numéro, ..., prix_de_base)
- A_POUR_PRIX_EXCEPTIONNEL (id_chambre, date_jour, prix_exceptionnel)

Que préconisez-vous et comment feriez-vous ?

Merci d'avance,
dix77

[CinePhil]

Si tu veux établir un calendrier ou un planning avec toutes les dates, tu auras besoin de la table JOUR. Si par contre tu n'as pas de tels besoins, alors la solution regroupée est acceptable.

[Richard_35]

Bonjour Dix77 et Philippe,

Je me permets de m'immiscer, Philippe...

Ajoutons que si, à terme, les jours exceptionnels possèdent des attributs particuliers, alors il faudra une entité JOUR. Par exemple, tu pourrais établir une majoration (en %) pour ces jours exceptionnels :

CHAMBRE (id_chambre, ..., prix_de_base)
JOUR(id_jour, date_jour, Majoration, ...)
A_POUR_PRIX_EXCEPTIONNEL (#id_chambre, #id_jour, prix_exceptionnel)

C'est seulement un exemple, mais d'autres attributs propres aux jours exceptionnels pourraient être nécessaires.

[dix77]

Si tu veux établir un calendrier ou un planning avec toutes les dates, tu auras besoin de la table JOUR. Si par contre tu n'as pas de tels besoins, alors la solution regroupée est acceptable.

Ajoutons que si, à terme, les jours exceptionnels possèdent des attributs particuliers, alors il faudra une entité JOUR. Par exemple, tu pourrais établir une majoration (en %) pour ces jours exceptionnels :

CHAMBRE (id_chambre, ..., prix_de_base)
JOUR(id_jour, date_jour, Majoration, ...)
A_POUR_PRIX_EXCEPTIONNEL (#id_chambre, #id_jour, prix_exceptionnel)

C'est seulement un exemple, mais d'autres attributs propres aux jours exceptionnels pourraient être nécessaires.

Merci pour vos réponses et votre réactivité
je suis entièrement d'accord avec vous deux
mais du coup, comment faire au niveau du MCD pour avoir au final 2 tables dans le SGBDR ?
parce que si, dans le MCD, je laisse 2 entités "CHAMBRE" et "JOUR" et entre ces 2 entités une relation "A POUR PRIX EXCEPTIONNEL" (cardinalité 0..n de chaque côté), si j'utilise un outil de génération, le modèle relationnel de données aura 3 relations et donc au final 3 tables dans le SGBDR

[CinePhil]

Je reprends ton modèle à deux tables :

- CHAMBRE (id_chambre, numéro, ..., prix_de_base)
- A_POUR_PRIX_EXCEPTIONNEL (id_chambre, date_jour, prix_exceptionnel)

On pourrait plus simplement appeler la seconde table "PRIX_EXCEPTIONNEL" et on voit que l'identifiant de la chambre participe à la clé primaire de celle table. La première chose qu'on peut dire est donc qu'il y a une identification relative du prix exceptionnel par rapport à la chambre. Idem dans l'autre sens mais "JOUR" correspondrait plutôt à une "pseudo-entité" de date, selon ce modèle :
CHAMBRE -0,n----avoir----(1,1)- PRIX_EXCEPTIONNEL -(1,1)----concerner----0,n- [JOUR]

J'ai mis JOUR entre crochet pour signifier qu'il s'agit en quelque sorte d'une entité type fictive mentionnée ici juste pour servir d'identifiant relatif.

Une autre représentation contestable, mais peut-être acceptée par le logiciel de modélisation, consiste à directement mettre la propriété JOUR dans l'entité-type PRIX_EXCEPTIONNEL et la mettre en clé primaire. L'identification relative, représentée ci-dessus par les cardinalités (1,1) entre parenthèses, ramènera l'identifiant de la chambre dans la table "PRIX_EXCEPTIONNEL" lors du passage au MLD avec génération des clés étrangères.

À tester.

[Richard_35]

comment faire au niveau du MCD pour avoir au final 2 tables dans le SGBDR ?

==> peux-tu nous expliquer pourquoi tu sembles ne vouloir que deux tables ?

[fsmrel]

Bonjour à tous,


Je m’immisce à mon tour simplement pour repasser par la case Départ avant toute autre considération.

Il ne faut pas oublier qu’une date n’est jamais qu’une valeur du type (domaine) DATE, tout comme un entier n’est jamais qu’une valeur du type ENTIER et le prix une valeur du type PRIX. D’une manière générale, dans un MCD, DATE fait l’objet d’une entité-type quand la date doit participer à l’identification d’une entité-type de dimension > 2. Voyez la discussion entité Date ou attribut date. Qui plus est, lors de la dérivation du MCD en MLD, la prétendue entité-type DATE ne fait évidemment pas l’objet d’une table dans le MLD (et pas Modèle Relationnel de Données qui est une théorie, une branche des mathématiques appliquées !)

Dans votre cas, puisque votre MLD ressemble à ceci :




Par rétro-conception, un MCD possible est le suivant (selon PowerAMC) :




Dans lequel la date se cantonne à son statut de propriété relevant du type DATE. L’entité-type PRIX_EXCETIONNEL est une entité-type « faible » (weak entity), une propriété multivaluée de l’entité-type CHAMBRE, par convention identifiée relativement à CHAMBRE.

Chaque AGL a évidemment sa notation. Avec WinDesign :




Avec OPenModel Sphere :



Etc.

_________________

[Edit]
Je n'avais pas lu le message #5 dû à CinePhil : pas de problème, nous sommes synchrones.

[dix77]

==> peux-tu nous expliquer pourquoi tu sembles ne vouloir que deux tables ?

c'est un peu plus simple et ça économise une jointure
mais peut etre que le gain de temps et de simplicité sont négligeables
outre le fait qu'on perd en évolutivité car si par la suite on veut rajouter des attributs à l'entité JOUR, avec le modèle à 2 tables, on est coincé

je n'ai pas énormément de connaissances en la matière donc je peux pas affirmer que tel modèle est mieux qu'un autre

si vous me dites avec des arguments solides que le modèle à 3 tables est mieux, je prends ce modèle

peut-être aussi que les 2 modèles se défendent ...

[Richard_35]

c'est un peu plus simple et ça économise une jointure

==> le but n'est pas d'économiser des jointures, mais d'établir un modèle pertinent.

mais peut etre que le gain de temps et de simplicité sont négligeables

==> c'est négligeable, en effet.

outre le fait qu'on perd en évolutivité car si par la suite on veut rajouter des attributs à l'entité JOUR, avec le modèle à 2 tables, on est coincé

==> si tu évoques cette possibilité, c'est que tu l'envisages... tu n'as donc pas le choix : le modèle à trois tables s'impose.

peut-être aussi que les 2 modèles se défendent ...

==> cela dépend si, réellement, tu envisages les possibilités d'évolution précédemment évoquées.

[fsmrel]

si j'utilise un outil de génération, le modèle relationnel de données aura 3 relations et donc au final 3 tables dans le SGBDR.

Tout dépend du SGBD, mais par exemple avec PowerAMC vous pouvez lui demander de ne pas générer la table DATE dès lors que vous n’en avez pas l’usage.

[dix77]

fsmrel, ça a l'air pas mal du tout ce que tu proposes
c'est également ce que proposait CinePhil

mais avec le MCD généré par PowerAMC, comment sait-on que l'identifiant de CHAMBRE va faire partie de la clé primaire dans la table PRIX_EXCEPTIONNEL ?

[dix77]

==> le but n'est pas d'économiser des jointures, mais d'établir un modèle pertinent.
==> c'est négligeable, en effet.
==> si tu évoques cette possibilité, c'est que tu l'envisages... tu n'as donc pas le choix : le modèle à trois tables s'impose.
==> cela dépend si, réellement, tu envisages les possibilités d'évolution précédemment évoquées.

complètement d'accord avec toi
en fait, ce n'est pas pour un vrai projet, c'est une question que je me posais en guise d'exercice
ça pourra devenir un projet dans quelque temps mais la priorité aujourd'hui c'est de trouver un taf, d'ailleurs si vous connaissez une société qui cherche un développeur PHP, faites moi signe

[fsmrel]

Ajoutons que si, à terme, les jours exceptionnels possèdent des attributs particuliers, alors il faudra une entité JOUR. Par exemple, tu pourrais établir une majoration (en %) pour ces jours exceptionnels :
CHAMBRE (id_chambre, ..., prix_de_base)
JOUR(id_jour, date_jour, Majoration, ...)
A_POUR_PRIX_EXCEPTIONNEL (#id_chambre, #id_jour, prix_exceptionnel)

Pourquoi ne pas tenir compte des minorations, rabais, remises et promotions exceptionnelles ? Au sens premier, « Prix exceptionnel » est parfaitement pertinent sauf peut-être si dix77 grave dans le marbre que seules des prix majorés peuvent être pris en compte. Cochon qui s'en dédie...

[Richard_35]

Pourquoi ne pas tenir compte des minorations, rabais, remises et promotions exceptionnelles ? Au sens premier, « Prix exceptionnel » est parfaitement pertinent sauf peut-être si dix77 grave dans le marbre que seules des prix majorés peuvent être pris en compte. Cochon qui s'en dédie...

==> exact !...... Le but était de montrer, par un exemple simple, qu'une date pouvait posséder des attributs propres, quel qu'ils soient.

Nous pouvons, bien entendu, examiner l'ensemble des cas possibles de prix exceptionnels et tenter de les modéliser.

[fsmrel]

fsmrel, ça a l'air pas mal du tout ce que tu proposes
c'est également ce que proposait CinePhil

mais avec le MCD généré par PowerAMC, comment sait-on que l'identifiant de CHAMBRE va faire partie de la clé primaire dans la table PRIX_EXCEPTIONNEL ?

Tout simplement parce que la cardinalité 1,1 portée par la patte connectant l’association-type R et l’entité-type PRIX_EXCEPTIONNEL est mise entre parenthèses (suffixée par "R" dans le cas de WinDesign, soulignée sans le cas d'OMS, etc.) : l’AGL comprend ainsi qu’on utilise l’identification relative et donc par construction, la clé primaire de la table PRIX_EXCEPTIONNEL aura pour éléments l’attribut ChambreId identifiant l’entité-type forte CHAMBRE et l’attribut DatePrixExcep identifiant partiellement l’entité-type PRIX_EXCEPTIONNEL : la clé primaire de la table PRIX_EXCEPTIONNEL est bien la paire {ChambreId, DatePrixExcep}.

[dix77]

Pourquoi ne pas tenir compte des minorations, rabais, remises et promotions exceptionnelles ? Au sens premier, « Prix exceptionnel » est parfaitement pertinent sauf peut-être si dix77 grave dans le marbre que seules des prix majorés peuvent être pris en compte. Cochon qui s'en dédie...

ce que j'avais identifié au niveau des prix, c'est :
1) un prix de base c'est-à-dire u prix par défaut
2) la possibilité de fixer un prix exceptionnel valable juste pour un jour et qui "écrase" le prix de base (ce prix exceptionnel peut être supérieur ou inférieur au prix de base)
3) un prix remisé valable juste pour un jour qui écrase les deux autres prix

Dans mon MCD initial, j'avais donc 2 entités "CHAMBRE" et "JOUR" et 2 relations "A POUR PRIX EXCEPTIONNEL" et "A POUR PRIX REMISé"

[dix77]

Tout simplement parce que la cardinalité 1,1 portée par la patte connectant l’association-type R et l’entité-type PRIX_EXCEPTIONNEL est mise entre parenthèses (suffixée par "R" dans le cas de WinDesign, soulignée sans le cas d'OMS, etc.) : l’AGL comprend ainsi qu’on utilise l’identification relative et donc par construction, la clé primaire de la table PRIX_EXCEPTIONNEL aura pour éléments l’attribut ChambreId identifiant l’entité-type forte CHAMBRE et l’attribut DatePrixExcep identifiant partiellement l’entité-type PRIX_EXCEPTIONNEL : la clé primaire de la table PRIX_EXCEPTIONNEL est bien la paire {ChambreId, DatePrixExcep}.

ok
merci pour cette précision

[fsmrel]

==> peux-tu nous expliquer pourquoi tu sembles ne vouloir que deux tables ?

Pour ma part, je dirais qu’avec deux tables le principe d’essentialité est respecté. En effet, vu les règle de gestion initiales (message 1), une 3e table est inessentielle, c’est un poids mort et comme disait Guillaume d’Ockham : « Pluralitas non est ponenda sine necessitate ».

Maintenant, une fois le principe des deux tables acquis, si vous enrichissez le corpus des règles, une 3e table s’imposera seulement si la normalisation en BCNF est violée et qu’une décomposition de la table PRIX_EXCEPTIONNEL est possible (décomposition sans perte de règles de gestion).

Pour reprendre votre exemple :

A_POUR_PRIX_EXCEPTIONNEL (#id_chambre, #id_jour, prix_exceptionnel)

Parce qu’il existe maintenant la dépendance fonctionnelle :

{id_jour} -> {prix_exceptionnel}

alors la BCNF est violée et il faudra appliquer le théorème de Heath, donc décomposer la table. Bref, ne mettons pas la charrue avant les bœufs, il faut modéliser et normaliser en fonction du corpus des règles existant et remettre l'ouvrage sur le métier au fur et à mesure que le corpus s'étoffe.