Agence De Voyage

Bonsoir tout le monde , je fait mes efforts a comprendre ces points et par suite créer un MCD (Piece Joint) qui satisfait ces contraintes et je tombe sur ce modéle mais j'ai toujours un soucis . aidez moi a bien comprendre est ce que je répond au cahier de charge ou non . Merci d'avance
1- Recherche de circuits par critéres (destination,type de voyage,date depart ,budget)
2-sélection de voyages via un panier électronique

et un autre question concernant mon exercices est le suivant , j'ai un formulaire de contact et un login et mot de passe pour gérer l'application pour but de ajouter des circuits et comme ca et j'ai résolu ca avec deux autres tableaux independant de la base donnees qui est dans l'image . est ce que ca marche ou non . Merci bcp

Bonjour,

L'énoncé est très insuffisant, vous ne pouvez pas faire un MCD avec si peu d'informations. Communiquez le texte complet de votre exercice

Citation:

---

Envoyé par escartefigue

Bonjour,

L'énoncé est très insuffisant, vous ne pouvez pas faire un MCD avec si peu d'informations. Communiquez le texte complet de votre exercice

---

Merci pour votre réponse , c'est juste ca qu'on a dans l'enoncé . Merci d'avance

regardez les sujets qui ont obtenu des réponses et vous comprendrez tout ce qu'il manque dans le votre

La modélisation d'une base de données n'est pas un art divinatoire, rien ne sort d'une boule de cristal ou des entrailles d'un lapin, il faut des règles de gestion rédigées en bonne et due forme pour pouvoir travailler.

Je n'imagine pas que votre professeur vous aie donné si peu d'instructions, soit vous avez oublié une partie de l'énoncé, soit... changez de professeur voire d'école !

Bonjour,
D’après le sujet très succinct : destination, type de voyage, date depart et budget sont des attributs du circuit (chaque circuit a 1 et 1 seul(e) destination, type de voyage, date de début et de fin, budget).
Donc pas d’asso * — * entre circuit et critère et pas de critère d’aiilleurs. Juste des circuits avec tout dedans.
On met date de début et de fin pour le circuit, comme ça la recherche avec une date de départ permet de de choisir les circuits adaptés.
En deuxième approche, on peut distinguer le circuit concret avec un prix et des dates et un type de circuit auquel il se raccroche (comme ça on factorise une information commune à deux circuits identiques à des dates différentes). L’association sera 1-----*

Aucun lien entre circuit et client : a priori on n’enregistre pas les recherche du client dans la BD !

Par contre, on a un panier qui joue le rôle classique de la commande. Le panier concerne un utilisateur (asso 1—* de panier à client)
Le panier concerne un circuit : (asso 1—* de panier à circuit).
Si le panier peut concerner plusieurs circuit, il faudra une asso *—* qui deviendra une table : la classique table des détails de commande.

Bref : TypeCircuit * — 1 Circuit * — * Panier 1 — * Client

Bon courage !

Faute d'éléments supplémentaires, on ne peut se focaliser que sur quelques fondamentaux

Entité-type Clients

• pour nommer les entité-type utilisez un singulier : "client" plutôt que "clients"
• Le courriel et le téléphone ne sont pas en dépendance fonctionnelle du client : un client peut ne pas avoir de téléphone, en avoir plusieurs...
  il faut donc créer une nouvelle entité-type "MEDIA" et créer une relation 0,n ou 1,n de "CLIENT" vers "MEDIA", il faut également une ET "TYPE-MEDIA" et une relation 1,1 de "MEDIA" vers "TYPE-MEDIA". "TYPE-MEDIA" permettra de distinguer un tél fixe pro, d'un fixe domicile, d'un portable pro, d'un courriel etc...

Relation rechercher

• Je ne suis pas certain que la recherche soit ce qui vous intéresse, n'est-ce pas plutôt le circuit finalement retenu par le client qui est intéressante ?
  Si la rcecherche vous intéresse, il faut un attribut d'horodatage (un client doit pouvoir faire plusieurs recherches y compris pour le même circuit), sinon, cette relation est redondante avec celle qui passe par le panier
• Les cardinalités sont à revoir, un circuit n'a pas forcément trouvé son client ou son panier (cas d'espèce : le circuit nouvellement ajouté au catalogue) il faut donc une cardinalité mini de zéro coté circuit. Coté client, ne sachant pas à partir de quel moment une personne devient "client", difficile de savoir s'il faut un mini zéro ou un

entité-type circuit

• là encore, l'attribut "type_circuit" ne dépend pas fonctionellement de l'identifiant du circuit (plusieurs circuits pouvant être du même type).
  il faut donc externaliser cette information en créant une entité-type "TYPE-CIRCUIT" et une relation 1,1 de "CIRCUIT" vers "TYPE-CIRCUIT"

entité-type étape

• Parler de circuit sans parler d'étape est un oubli à corriger impérativement !

Je sais qu'il s'agit d'un exercice, mais nulle part il n'est question du nombre de personnes participantes, du nombre d'adultes, d'enfants, de vaccins obligatoires, de documents obligatoires... toutes information généralement requises pour voyager.

entité-type étape
Parler de circuit sans parler d'étape est un oubli à corriger impérativement !


entité-type critères

• mettre dans une même ET les différents critères ne va pas du tout, ça vous oblige à prévoir toutes les combinaisons possibles de durée/destination/type_voyage/budget
  Ne retenez que ce qui caratérise un circuit et créez autant d'entité-type à mettre en relation avec l'entité-type "CIRCUIT"
  Mais il est probable que de nombreuses caractéristiques (ou critères) soient non pas en relation avec le circuit, mais avec l'étape (typiquement : la durée du circuit est la conséquence de la durée de chaque étape, la destination du circuit est celle de la dernière étape...)
• le budget (on parle plutôt de tarif) dépend du circuit mais aussi d'autres éléments comme les saisons pleines/creuses, l'age du client, les réductions spéciales (handicapés, famille nombreuse etc...)
• le type FLOAT est inadapté pour des montants, car la partie décimale du type FLOAT est approximative. A remplacer par du DECIMAL