|
Héros / Héroïne
|
Bonjour, débutante en SGBD, je souhaiterai avoir un petit peu d'aide concernant un MCD et son modèle relationnel. Je fais appel à vous car vous êtes une communauté très dynamique avec beaucoup de compétences dans divers domaines.
L'exemple est classique, c'est la gestion d'un hôtel (vu et revu sur le net, mais ayant un cas un peu différent, je ne sais pas si je peux m'aider de ce que je vois ailleurs.) voici mon MCD: (j'ai oublié de supprimer id_resa, il ne faut pas en tenir compte)  et voici le modèle relationnel que j'ai écris.  Pourriez-vous me dire si cela vous semble juste ou s'il y a des fautes ? Merci beaucoup pr votre aide |
20/03/2008, 22h05
|
débutante - Modele conceptuelle et relationnel SQL
| Suivre |
|
|
Partager | Rechercher |
|
Bagnard
|
Il faut faire gaffe, car imaginons un client 1
Il réserve du 15 au 20. Il pourra également réserver du 16 au 23. Donc du 16 au 20 il sera dédoublé. Ca, c'est permis par ta base, mais après par programmation il faut empécher ce genre de choses (d'ailleurs je suis en plein dedans au boulot...). Qu'est ce que tu appelles un supplément ? Quelque chose acheté par le client ? Dans ce cas, même si on peut retrouver le client qui a occupé la chambre en fonction des dates, il serait peut être bon de lier l'id de réservation avec les suppléments. Voilà. Sinon, ca te plait ton IUT informatique (ou ton BTS informatique de gestion)  ?TOF ? |
|
20/03/2008, 22h45
|
|
Alpha & Oméga
|
Déjà pas vraiment sur la qualité du model, mais c'est un logiciel particulier que tu utilises, ou tu l'as fais sous paint ? Parce que les notation sont assez peu clair.
Ensuite il y'a quelques petits problemes : La cardinalité entre chambre et réserver est mauvaise, c'est du 0.n plutôt non ? Parce que là elle ne peut etre reserver que par un seul client. Alors bon c'est peut etre un hotel pour rockstar à caprice, mais tous de même Après je ne comprend pas bien ce qu'est supplément ? J'aurais tendance à dire que c'est aussi par rapport à un client non ? edit : Citation :
|
|
20/03/2008, 22h46
|
|
Alpha & Oméga
|
Intuitivement, je dirais qu'une chambre peut être réservée par 0 à N clients (enfin c'est comme ça en général dans les hôtels
 ). (Edit : ok, déjà dit, mais je confirme.)Concernant le modèle relationnel, je ne mettais pas de flèches, m'enfin si je devais en mettre, je les ferais pointer dans l'autre sens (à chaque fois). Donc de la clef étrangère vers la clef primaire. |
|
20/03/2008, 22h58
|
|
Alpha & Oméga
|
J'avais pas fais gaffe au model relationnel, mais dessus tu mets bien que Réservation prend la clé de Id_Chambre, donc c'est bien du 1.N pour réserver chambre
|
|
20/03/2008, 23h01
|
|
Alpha & Oméga
|
Risque de doublon de clef également.
Pas exemple si un client reserve une meme chambre (qu'un client veuille la meme chose d'une année sur l'autre me semble fort probable) tu te retrouve avec un doublon sur les clefs. Pareil pour les supplément si lundi je veux un suppléments camembert et mardi pareil tu auras un doublon. Tu peux donc soir rajouter un id soit étendre ta clef à d'autre champ (par exemple la date pour les reservation. |
|
20/03/2008, 23h09
|
|
Oracle
|
J'avais jamais vu de MCD sous cette forme
 Sinon il manque pas l'id_Hotel dans Chambre ? |
|
21/03/2008, 00h25
|
|
Alpha & Oméga
|
Si c'est juste pour une étude de cas ton modèle est une bonne base.
Si c'est pour un véritable hotel, il y a quelques relations majeures qui sont manquantes. Un client doit pouvoir réserver une chambre précise (la 302), un style de chambre (chambre simple, chambre double...) ou une chambre indéfinie. Il te manque donc les catégories de chambres. Tu dois également permettre le surbooking c'est à dire réserver plus de chambres que ce dont dispose l'hôtel. Si ton client est un groupe, tu dois pouvoir lui lier x chambres car ca m'étonnerait que tu cases 20 personnes dans une seule chambre. Le prix des chambres varie également en saison/hors saison. |
|
21/03/2008, 01h46
|
|
Alpha & Oméga
|
supplementes n'ai aps tellement interessant, il vaudrait mieux une table facture separés à laquelle tu rajoutes les dits suppléments.
Tu peux aussi rajouter une table pour définir les periodes de fermetures eventuelles (dans le cas d'un hotel pour le ski), comme dit au dessus, les hautes et basses saison, les promotions, etc etc Ca permet en meme temps de faire la diff entre WE et semaine, ou les prix ne sont souvent pas les memes c'est pas tres lisible la quand meme
|
|
21/03/2008, 06h54
|
|
[SVPPB]
Alpha & Oméga
|
Citation :
Enfin perso je ferais une table par groupe d'objets : 1 table clients avec une clé sur N° de client 1 table chambres avec une clé sur N° de chambre 1 table facture 1 table article (me dite pas que la table article c'est la table chambres, vu qu'il y a des options) et une table réservations, enfin vite fait comme ça.... |
|
21/03/2008, 07h10
|
|
Héros / Héroïne
|
Bonjour à tous et merci pour vos réponses.
Donc, pour répondre à certains, Mot de Passe> Supplément, c'est tout ce qui est petit déjeuné, laverie, ect... Panzerjo> Non, je n'ai pas utilisé de logiciel, j'ai fait cela à la main, via Word ^^' (On nous a appris a le faire comme ceci.) Ah oui, effectivement, j'ai pas fait attention à cette cardinalité, merci  Korgoth> D'accord, j'ai compris le raisonnement des doublons mais je n'ai bien pas compris ta solution. Citation :
étendre quelle clé ? exemple: date pour les réservations, quelle date ? La prof m'a dit que facture serait mieux dans l'association car, une facture est unique, donc, avoir une table, juste pour un chiffre, c'était pas vraiment nécessaire. La prof a également dit que pour les flèches sur le modèle relationnel, c'était de la clé étrangère à la clé primaire, même si pour moi, cela aurait du être le contraire.  Pour tout ce qui est période, saison, je voulais rester dans quelque choses d'assez simple au début, sinon, je risque vite de me noyer déjà que je débute ^^' Et puis, c'est juste une petite étude. Donc, si j'ai bien compris tout ce que vous m'avez dit, comme correction pour le moment: - modifier la cardinalité (1,n) pour les chambres. - rajouter Id_Hotel dans chambre. Merci beaucoup pour votre aide. |
|
21/03/2008, 09h38
|
|
[CPC]
Alpha & Oméga
|
Il serait plus simple d'associer les supplément à la réservation plutôt qu'à la chambre.. |
|
21/03/2008, 11h21
|
|
Héros / Héroïne
|
Guitou:
oui, j'avais fait comme ça au début mais ma prof m'a dit que dans ce cas, le client peut prendre un supplément sans prendre de chambre or, il doit avoir une chambre pr avoir un supplément. donc, ac la date, je pensais que ça devrait marcher. |
|
21/03/2008, 11h32
|
|
[BerK]
Alpha & Oméga
|
personnellement je ferais une relations des suppléments sur la réservation
j'enlèverais la relation <contenir> et je rajouterais un id dans la chambre contenant la fk_hotel_id, Je rajouterais un champs dans la réservation pour transformer celle-ci en séjour  Sinon il me semble qu'une table facture ne sera effectivement pas de trop rien que pour un groupe, une agence de voyage, ou une entreprise qui réserverait pour ton client. En plus si après tu viens greffer la comptabilité sur ton application ou quoi que ce soit d'autres ... sinon je suis pas convaincu par la forme sous word mais si s'est comme ça qu'on t'as appris Citation :
après avoir une table séjour à pars ou rajouter un attribut à la réservation c'est discutable et limite OSEF Et temps que j'y suis je rajouterais aussi un pk_blabla pour les clefs primaires et un fk_ pour les clefs étrangères devant les noms de tes attributs
|
|
21/03/2008, 11h39
|
|
Héros / Héroïne
|
oki, merci pr ces infos, je vais refaire un MCD et un schéma relationnel et je le reposterai rapidement.
|
|
21/03/2008, 12h27
|
|
[cddra]
Alpha & Oméga
|
Citation :
|
|
21/03/2008, 12h32
|
|
Héros / Héroïne
|
j'y jetterai un coup d'oeil, merci
|
|
21/03/2008, 12h36
|
|
[BerK]
Alpha & Oméga
|
Personnellement si tu peux l'avoir à disposition dans ton école je te conseil
RSA
|
|
21/03/2008, 15h36
|
|
Alpha & Oméga
|
Citation :
J'aurais bien mis aussi une table avec toutes les villes et code postaux pour pouvoir preremplir les champs correspondant et eviter les erreurs de rentree de coordonnée Il y a aussi le faite de gerer ou non un restau et/ou le petit dejeuner, qui serait mieux avec une table produit ou consommation avec les prix et une liaison avec les clients pour definir ce qu'ils ont consomme. Les chambres pourraient etre alors un produit. Il faut voir aussi la complexite du truc demande par l'exercice, parce que sur une gestion global d'un hotel, faudrait rajouter beaucoup plus de champs/tables |
|
21/03/2008, 17h20
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|