Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Les colonnes contiennent effectivement les traductions. C'est vrai que ca a pas mal évolué depuis le début ! Un peu grâce à vous je dirais.Envoyé par fsmrel
Bonsoir,
Considérons à nouveau votre table LANGUAGE :
Les colonnes language_name_english, language_name_french, ..., etc., contiennent-elles la traduction en anglais, en français, etc., du texte contenu dans la colonne language_name_vo ?
Cela dit, on observera que le diagramme a pas mal évolué au fil du temps...
Langues
Bonsoir,
Bon, alors on doit avoir des tables dont le contenu ressemble à ceci :
LANGUAGE
TRADUCTIONlanguage_id language_name_vo ----------- ---------------- 1 français 2 español 3 english 4 deutsch ... ...
language_id traduction_id language_code language_name ----------- ------------- ------------- ------------- 1 1 eng french 1 2 spa francés 1 3 deu französisch 1 4 chi Fàguó 2 5 eng spanish 2 6 fra espagnol 2 7 deu spanisch 2 8 chi Xibanyá yu 3 9 fra anglais 3 10 spa inglés 3 11 deu englisch 3 12 chi Yingyu 4 13 fra allemand 4 14 eng german 4 15 spa alemán 4 16 chi Déguó ... ... ... ...
Diagramme correspondant :
Script SQL de création des tables :
CREATE TABLE LANGUAGE ( language_id INT NOT NULL , language_name_vo VARCHAR(24) NOT NULL , CONSTRAINT LANGUAGE_PK PRIMARY KEY (language_id) ) ; CREATE TABLE TRADUCTION ( language_id INT NOT NULL , traduction_id INT NOT NULL , language_code CHAR(3) NOT NULL , language_name VARCHAR(24) NOT NULL , CONSTRAINT TRADUCTION_PK PRIMARY KEY (traduction_id) , CONSTRAINT TRADUCTION_AK UNIQUE (language_id, language_code) , CONSTRAINT TRADUCTION_LANGUAGE_FK FOREIGN KEY (language_id) REFERENCES LANGUAGE (language_id) ) ;
Exemple de requête SQL :
=>SELECT language_name_vo, language_code, language_name FROM LANGUAGE JOIN TRADUCTION ON LANGUAGE.language_id = TRADUCTION.language_id ;
language_name_vo language_code language_name ---------------- ------------- ------------- français chi Fàguó français deu französisch français eng french français spa francés español chi Xibanyá yu español deu spanisch español eng spanish español fra espagnol english chi Yingyu english deu englisch english fra anglais english spa inglés deutsch chi Déguó deutsch eng german deutsch fra allemand deutsch spa alemán
Un peu seulement ?
Bonjour fsmrel,
Très bien! En tout cela me donne ceci:
J'ai pensé aussi rajouter un système de vote pour les utilisateurs. Chaque client, après le transfert bien effectué, peut voter en laissant une note entre 1 et 5 sur son chauffeur et laisser un commentaire. Le score total de chaque chauffeur se calculera lors de l'affichage.
Bonsoir,
N’a-t-on pas besoin de savoir si les informations ont été fournies, soit par le chauffeur, soit par le client ?
Son client ?
Quel est le rôle de l’association CLIENT_DRIVER_DETAIL, correspond-elle au compte client ?
La patte connectant l’entité-type DRIVER et l’association CLIENT_DRIVER_DETAIL est porteuse d’une cardinalité maximale 1 : dans le cadre de cette association, un chauffeur ne peut donc avoir qu’un seul client.
La patte connectant l’entité-type CLIENT et l’association CLIENT_DRIVER_DETAIL est porteuse d’une cardinalité maximale 1 : dans le cadre de cette association, un client ne peut donc être en relation qu’avec un seul chauffeur.
Qu’en est-il en réalité ?
On interprète ceci comme quoi un client ne crée pas forcément de compte. La patte connectant l’entité-type CLIENT et l’association CLIENT_DRIVER_DETAIL devrait donc être porteuse d’une cardinalité minimale 0 (mêm chose pour l'autre patte).
Soit, mais en l’état un client peut voter pour un chauffeur avec lequel il n’a jamais été en relation : il va falloir modéliser en sorte qu’un client ne puisse voter que pour un chauffeur avec lequel il a été en relation.
Pourriez-vous expliquer le attributs de l’entité-type TRANSFER_BOOKING ? Le chauffeur a besoin de connaître un numéro de vol ?
Ah si justement, d'où le role de driver_id et client_id.
Un chauffeur peut lui aussi avoir un compte client, avec sa même adresse email.
La patte connectant l’entité-type CLIENT et l’association CLIENT_DRIVER_DETAIL est porteuse d’une cardinalité maximale 1, car un client ne peut pas qu'un mot de passe, email, nom, prenom etc et même chose pour le chauffeur.
L’association CLIENT_DRIVER_DETAIL est de rassembler les détails des clients et des chauffeurs, leurs mots de passes, emails, nom, prenom etc.
Dans transfer_booking on a "coldate" qui enregistre la date de la réservation, "origin" le lieu de départ, "destination" le lieu d'arrivé, "pickupdate" et "pickuptime" le jour et heure de prise en charge du client. "flightnumber" le numéro de vol du client si le client arrive à un aéroport et que le chauffeur doit vérifier son vol, "service" le nom du service par exemple "transfer - Economy class", "price" le prix total qui a été calculé grace au prix par km ou autre, "comments" les commentaires du client, "accepted" si la réservation a été accepté, "driver_id" par quel chauffeur, "vehicle" le type de véhicule choisie pour cette course (si le client en a choisie un en particulier).
Bonjour,
Je suis philosophiquement contre ce genre de vote, je ne vois pas comment la sincérité du votant peut être avérée.
Certains hôteliers ou restaurateurs, pourtant très bon professionnels, ont payé cher ce type de système : des clients peux scrupuleux qui leur ont réclamé des avantages indus et ne les ont pas obtenu, ne se sont pas gênés pour noter ces professionnels très sévèrement !
Si toutefois vous souhaitez utiliser ce système de cotation, il faut modéliser une entité-type qui référence les notes, et leur signification
Bonsoir Nike,
Je ne vous oublie pas, mais j'ai plein de fers au feu, à bientôt j'espère.
Moi c'est pour des raisons commerciales.
Aucun problème. En attente de votre aide.
Bonsoir,
Hum... Considérons cette partie de votre MCD :Les tables client et chauffeur sont associées avec une association "client_driver_communicate" où ils peuvent indiquer plusieurs numéros de tel, emails et adresses
N’a-t-on pas besoin de savoir si les informations ont été fournies, soit par le chauffeur, soit par le client ?
A partir du MCD, un AGL produit le MLD, et en particulier — à partir de l’association CLIENT_DRIVER_COMMUNICATE — la table CLIENT_DRIVER_COMMUNICATE, dont la clé primaire est composée des attributs composant eux-mêmes les clés primaires des tables générées DRIVER et CLIENT. Dans le style de MySQL Workbench :
Passons aux instances :
Table DRIVER
driver_id description --------- ----------- 1 chauffeur 1 2 chauffeur 2
table CLIENT
client_id promo --------- ------- 1 promo 1 2 promo 2 3 promo 3
Supposons qu’on ait la situation suivante pour la table CLIENT_DRIVER_COMMUNICATE :
Du fait de la structure du MLD inférée de celle du MCD, la clé de la table CLIENT_DRIVER_COMMUNICATE est la paire {driver_id, client_id}, ce que confirme votre diagramme MySQL Workbench.driver_id client_id client_driver_communicate_id email phone address --------- --------- ---------------------------- ----- ----- ------- 2 3 1 0123456789
Remarque 1 : du fait des cardinalités 1,N, tout chauffeur communique (ou a communiqué) nécessairement avec au moins un client et un client communique (ou a communiqué) nécessairement avec un chauffeur. Qu’en est-il quand un chauffeur est tout nouveau ? Quand un client est tout nouveau ?
Remarque 2 : le chauffeur 2 et le client 3 ne pourront pas communiquer une 2e fois car, par construction, la clé {driver_id, client_id} ne peut pas héberger un doublon <2, 3>.
Remarque 3 : on peut supposer que l’attribut client_driver_communicate_id est là pour résoudre la problème précédent, mais ça n’est pas avec le MCD que vous proposez que ça sera possible.
Remarque 4 : dans l’exemple ci-dessus, à qui appartient le téléphone "0123456789" ? Au chauffeur ? Au client ? Au vu de la modélisation il est impossible de le savoir : il faut donc mettre en œuvre un attribut permettant de savoir qui est à l’origine de la communication, par exemple "driver", "client" (je vire l’attribut client_driver_communicate_id) :
Ainsi, on sait cette fois-ci que c’est le client 3 qui est à l’origine de la communication.driver_id client_id origine email phone address --------- --------- ------- ----- ---------- ------- 2 3 client 0123456789
Remarque 5 : je suppose qu’il serait utile d’horodater les communications, donc d’ajouter un attribut de type TIMESTAMP dans l’en-tête de CLIENT_DRIVER_COMMUNICATE :
driver_id client_id origine horodatage email phone address --------- --------- ------- ------------------- ----- ---------- ------- 2 3 client 2016-01-25:07:25:00 0123456789
Remarque 6 : dans cet exemple, un des deux intervenants dans la communication a fourni un numéro de téléphone, mais rien pour l’adresse et l’adresse de courriel, car ce seul numéro de téléphone convenait aux partenaires. Autrement dit il y aura une déperdition de place (un peu plus de 500 octets en l’occurrence). Pour éviter le gaspillage, on peut mettre en œuvre une table NATURE_DONNEE :
NatureDonneeId Libelle -------------- ------------------- 1 Numéro de téléphone 2 Adresse de courriel 3 Adresse postale
De telle sorte que la table CLIENT_DRIVER_COMMUNICATE lui fasse référence et que le numéro de téléphone soit une valeur du nouvel attribut Valeur de la table CLIENT_DRIVER_COMMUNICATE :
driver_id client_id origine horodatage NatureDonneeId Valeur --------- --------- ------- ------------------- -------------- ---------- 2 3 client 2016-01-25:07:25:00 2 0123456789
Mais comme à un moment donné, un des protagonistes peut aussi transmettre plusieurs numéros de téléphone (pourquoi pas ?) ainsi qu’une une adresse postale ou une adresse de courriel, il est temps de mettre en œuvre un identifiant propre à la table, et c’est maintenant que l’attribut client_driver_communicate_id va rendre service, dont j’abrège le nom en communicate_id. Exemple : à 2 moments différents, le client 3 a transmis deux numéros de téléphone au chauffeur 2, ainsi qu’une adresse postale et une adresse de courriel et le chauffeur lui a transmis un numéro de téléphone :
=>communicate_id driver_id client_id origine horodatage NatureDonneeId Valeur -------------- --------- --------- ------- ------------------- -------------- ------------------- 1 2 3 client 2016-01-25:07:25:00 1 0123456789 2 2 3 client 2016-01-25:07:25:00 2 toto@truc.fr 3 2 3 client 2016-01-25:07:25:00 3 1 rue Machin, Brest 4 2 3 client 2016-01-25:08:12:00 1 0678901234 5 3 2 driver 2016-01-25:09:00:00 1 0698765432
Maintenant, si vous n’avez pas la possibilité d’horodater, vous limitez à la date. Et si ça n’est pas possible de dater, eh bien vous supprimez l’attribut horodatage...
Je n’ai pas compris cette partie de la phrase : « car un client ne peut pas qu'un mot de passe ». Que voulez-vous dire ?
Je suppose qu’il faut lire ceci : « L’objet de l’association CLIENT_DRIVER_DETAIL est de rassembler les détails des clients et des chauffeurs... »
Sur la base de votre MCD que je reprends ci-dessous, il y aura logiquement génération d’une table CLIENT_DRIVER_DETAIL ayant pour clé primaire soit {driver_id}, soit {client_id}. Supposons qu’il s’agisse de {client_id} : dans ces conditions, {driver_id} est clé alternative. De toute façon cette modélisation ne convient pas, car pour chaque ligne de la table il y aura obligatoirement un partenariat d’un chauffeur et d’un client.
Avant d’aller plus loin, j’ai besoin que vous confirmiez qu’il s’agit bien d’héberger dans la table CLIENT_DRIVER_DETAIL les données communes aux clients et aux chauffeurs, plutôt que d’vor ces données d’une part dans la table DRIVER, d’autre part dans la table CLIENT.
Bonjour,
Oui très bonne idée le driver_client_communicate.
Ce que je disais "La patte connectant l’entité-type CLIENT et l’association CLIENT_DRIVER_DETAIL est porteuse d’une cardinalité maximale 1, car un client ne peut avoir qu'un mot de passe, email, nom, prénom, etc. et même chose pour le chauffeur." J'avais oublié un mot, désolé!
Le chauffeur peut avoir un compte client avec la même adresse email et le même mot de passe qu'il utilise pour son compte chauffeur. Le client aussi. Donc il peut s'inscrire comme client, et lorsqu'il sera inscrit il pourra se connecter en tant que chauffeur, sur l'espace chauffeur, avec les même détails qu'il utilise pour son compte client.
Selon vous "driver_id" et "client_id" dans CLIENT_DRIVER_DETAIL sont seulement facultatif?
Bonsoir,
J’avais posé la question suivante :
L’association CLIENT_DRIVER_DETAIL permet certes, de gérer des noms, des prénoms, des mots de passe etc., mais je répète, représente-t-elle le compte client ? Sinon, à quelle entité-type ou association du MCD correspond ce compte client ? A défaut, à quelle table du diagramme MySQL Workbench ?
En attendant, puisque vous souhaitez modéliser en un seul endroit les noms, prénoms, etc. des clients et des chauffeurs, ça n’est pas avec l’association CLIENT_DRIVER_DETAIL que vous pourrez le faire, puisque par définition, par vocation, elle associe obligatoirement un chauffeur à un client.
Partons des structures que vous aviez présentées au cours de la discussion :
Conceptuellement vous pouvez définir une entité-type PERSONNE (ou INTERVENANT, ou tout autre nom à votre convenance), laquelle portera les attributs communs aux clients et aux chauffeurs. PERSONNE joue le rôle de surtype vis-à-vis des entités-types CLIENT et DRIVER qui jouent alors le rôle de sous-types. Les sous-types héritent des propriétés du surtype, notamment de l’identifiant, qui n’est donc à définir que pour l’entité-type PERSONNE. Les attributs propres aux sous-types figurent bien sûr dans les sous-types. Vous noterez l’association SITUER connectant les entités-types PERSONNE et VILLE : on suppose ici que la localisation dans une ville concerne non seulement les chauffeurs mais aussi les clients. Par contre, si cette localisation ne concerne que les chauffeurs, on revient à la situation précédente, on ne met pas en œuvre l’association SITUER et on rétablit l’association initiale entre CHAUFFEUR et VILLE.
Côté MySQL Workbench, le MCD ci-dessus donne lieu au diagramme :
A noter que l’attribut driver_id de la table DRIVER est hérité de l’attribut personne_id de la table PERSONNE, de même que l’attribut client_id de la table DRIVER est hérité lui aussi de l’attribut personne_id de la table PERSONNE : ainsi une personne est soit un chauffeur, soit un client (ou les deux à la fois au besoin). {driver_id} est clé primaire de la table DRIVER et clé étrangère par rapport à la clé primaire {personne_id} de la table PERSONNE (même principe pour {client_id}, mutatis mutandis).
On serait donc en phase avec les diagrammes ci-dessus...
Bon... Espérons que le concept de compte client n’est pas mis à mal dans les diagrammes ci-dessus...
Que nenni ! Ces attributs participant aux clés primaires, ils doivent toujours être renseignés, sinon ça serait un désastre ! Et tout SGBD relationnel interdit les clés primaires non renseignées.
Bonjour,
Après une longue réflexion sur la création de compte chauffeur et client, nous avons finalement changé d'avis (désolé de vous avoir fait perdre du temps...), le chauffeur ne pourra avoir qu'un seul compte chauffeur et AUCUN compte client avec la même adresse mail. Le client ne pourra avoir qu'un seul compte client et AUCUN compte chauffeur avec la même adresse mail. Ceci évitera certaines mauvaises intentions sur le site.
EDIT: J'ai finalement séparé complètement DRIVER et CLIENT.
==> Si je veux rajouter un prix "forfait", c'est à dire que le chauffeur rentre deux lieux différents et que le prix soit calculé en fonction de la course entre ces deux lieux. Le chauffeur pourra par exemple mettre "Paris, Hauts-de-Seine, Versailles", dans un autre champs "Aéroport Charles de Gaulle" et son prix dans une troisième case "50€". Les courses entre "Paris", "Hauts-de-Seine" ou "Versailles" et "Aéroport Charles de Gaulle" seront donc tous à 50€.
Dans l'entité PRICE suffit-il d'ajouter "price_forfait" ou faut-il aujouter en quelque sorte un deuxième lieu dans PRICE_PLACE?
- Un chauffeur doit obligatoirement uploader une license et un permis de conduire (il y a différents types de licences aussi).
DRIVER -> upload 1,N -> DRIVER_LICENSE -> chaque licence uploadé est associé à 1,1 -> DRIVER
et
DRIVER_LICENSE -> est associé à 1,1 -> DRIVER_LICENSE_NAME -> est associé à 0,N -> DRIVER_LICENSE
- J'ai ajouté USER_PHOTO pour que les clients et les chauffeurs puissent ajouter leurs photo de profile. "up_filename" constitue le chemin vers le fichier.
DRIVER -> upload 0,1 -> USER_PHOTO -> chaque photo est uploadé par 1,1 -> DRIVER
et pareil pour CLIENT.
- J'ai aussi le code promo.
Chaque CLIENT -> peut ajouter 0,N -> PROMO -> chaque code est ajouté par 0,N -> CLIENT
J'ai donc une association CLIENT_PROMO.
CLIENT_PROMO -> chaque code promo associé à un client peut réduire le cout de 1,1 -> TRANSFER_BOOKING -> chaque réservation peut être associé à 0,1 -> CLIENT_PROMO
Voir MCD ci-dessous:
Avec transfer_booking et le code promo:
En attente de vos suggestions et corrections.
Merci pour votre aide!
PS: @escartefigue, j'ai laissé "origin" et "destination" en varchar et non en latlng, car le client veut voir exactement le même nom d'adresse qu'il avait rentré au départ. J'ai essayé avec l'aéroport CDG par exemple. Je rentre "Aéroport Charles-de-Gaulle" dans l'adresse et avec les coordonnés GPS obtenues je demande l'adresse et ca me renvoie "337 Route des Badauds". Ni le chauffeur, ni le client va comprendre qu'il s'agit d'un aéroport.
S'il s'agit de latitudes et longitudes alors il faut 2 attributs distincts, et certainement pas du varchar et encore moins 255
Vous devez donc avoir dans une entité des lieux, un attribut latitude, un attribut longitude, éventuellement des unités de mesure si ces données peuvent être exprimées dans différentes unités
Dans cette entité, la notion d'origine et destination n'aura pas de sens puisqu'un meme lieu, selon le trajet peut être un point de départ, une étape, ou une arrivée.
D'accord, mais vous auriez pu modéliser une entité lieux (code lieu, ligne(s) adresse, code postal, code pays...) et mettre en relation votre association transfert_booking avec cette entité
Je vois que vous ne modélisez pas la notion d'étape, Est-ce volontaire ? n'y a -t- il pas à gérer des cas où le client souhaite aller de A vers B en passant par une ou plusieurs étapes ?
Bonsoir,
Vous pouviez conserver le MCD, mais en ajoutant une contrainte d’exclusion comme quoi une personne ne peut être à la fois chauffeur et client :
Mais cela nécessite au stade SQL de développer des triggers pour garantir la contrainte. En conséquence, si vous préférez complètement séparer DRIVER et CLIENT : pas de problème.
Association PRICE_PLACE
Jusqu’ici je n’ai pas prêté attention au comportement de l’association PRICE_PLACE. En y regardant de plus près, j’ai l’impression de me retrouver dans la situation du gars qui voudrait vendre des pantalons à une seule jambe, mais qui donc voudrait lui en acheter ? ^^
Autrement dit,
PRICE_CATEGORY category_id category_name ----------- ------------- 1 ecocar 2 ecovan 3 buscar PRICE category_id price_id price_km ... ----------- -------- -------- ... 1 1 0.75 ... 1 2 0.80 ... 1 3 0.90 ... PLACE place_id place_name -------- -------------- 1 Paris 2 Hauts-de-Seine 3 Versailles PRICE_PLACE place_id category_id price_id 1 1 1 2 1 1 3 1 2 DRIVER driver_id driver_name --------- ----------- 1 Fernand DRIVER_PRICE driver_id category_id price_id --------- ----------- -------- 1 1 1 1 1 3
C'est-à-dire que pour la catégorie ecocar, Raoul pratique le tarif à 0.75 euro du kilomètre, ainsi que le tarif à 0.90 euro.
C'est-à-dire par ailleurs que pour la catégorie ecocar, pour la ville de Paris, le tarif est à 0.75 euro du kilomètre, même chose pour les Hauts-de-Seine, tandis que pour Versailles, c’est 0.80 euro du kilomètre.
Mais quel sens donner à ces phrases ? Où est la notion de parcours ? A supposer que le point de départ soit la ville V1 dans laquelle est basé le chauffeur (définie par l’association entre DRIVER et CITY), calculez-vous le montant du parcours en fonction de V1 et de la ville V2 où réside le client ? Sinon, quelle est la règle de calcul ?
En relation avec ce qui précède, au vu du diagramme des tables, je ne vois pas comment vous pouvez déterminer le point de départ (par exemple Versailles) et le point d’arrivée (aéroport Charles de Gaulle) pour le parcours que vous souhaitez forfaiter... Pour le moment, je sais seulement que le chauffeur est basé par exemple à Vanves (association entre DRIVER et CITY).
Table DRIVER_LICENSE_NAME :
il s’agit du nom du chauffeur ? Du nom du type de licence ? si c’est le nom du type de licence, d’accord.
Table USER_PHOTO :
Pas d’accord ; En effet, selon votre diagramme, une photo donnée, par exemple celle du chauffeur Raoul, doit aussi appartenir à un client...
Il faudrait remplacer la table USER_PHOTO par une table DRIVER_PHOTO et une table CLIENT_PHOTO :
[DRIVER]--||------------o|--[DRIVER_PHOTO]
[CLIENT]--||------------o|--[CLIENT_PHOTO]
Hum... Supposons que le client Hubert ait les promos P1, P2, P3, et qu’il a effectué une réservation R1 le 25/01/2016 et une réservation R2 le 03/02/2016. A vous lire, si la promo P1 a servi pour R1, elle ne pourra plus servir pour R2. Qu’en est-il ?
Hum... A vous lire, la réservation R1 du 25/01/2016 ne peut faire référence qu’à une seule promo (par exemple P1) du client Hubert. Qu’en est-il ?
Remarque concernant la table TRANSFER_BOOKING :
La génération spontanée n’existe pas : le losange accompagnant l’attribut client_id ne peut pas être évidé, autrement dit l’association avec CLIENT est obligatoire. Par ailleurs, pour quelle raison l’association avec DRIVER est-elle facultative ?
Table TRANSFER_BOOKING : qu’est-ce que l’attribut id_disposal_booking ?
Le calcule est basé sur le lieu de départ. Si Fernand a indiqué Paris dans "place_name" et que le lieu de départ de la course est Paris, le lieu de destination est "Nantes", alors "price_km" de 0.75 se calculera en fonction de la distance parcouru entre Paris et Nantes: 384,6 km * 0,75 € = 288,45 € payé au chauffeur.
Si le lieu de départ est Nantes et le lieu d'arrivé Paris, alors Fernand n'apparaîtra même pas dans les résultats de recherche et il n'y a aucune chance qu'un calcule se fera.
Si le price_minimum est 20€ et la distance est de 2km, le total sera 1,5€, mais personne ne voudra effectuer une course à ce prix. C'est à ce moment que price_minimum s'affichera et pour 2km le prix affiché deviendra 20€.
Ceci est effet bien un problème... il faudrait rajouter une table spécifique pour le forfait? PRICE_PLACE_FORFAIT et un PLACE_FORFAIT avec place_name_1 et place_name_2 ?
PLACE_FORFAIT
place_forfait_id place_name_1 place_name_2 1 Paris Nantes 2 Hauts-de-Seine Yvelines 3 Versailles Roissy
PRICE_PLACE_FORFAIT
place_forfait_id category_id price_id 1 1 1 2 1 1 3 1 2
J'ai donc corrige comme ceci:
Le code promo P1 de Hubert en effet ne peut servir que pour R1. Une fois utilisé pour R1 elle ne pourra plus servir pour R2.
Mais en effet R1 peut faire référence pas seulement à P1, mais aussi à P2 ou P3.
P1, P2 ou P3 peuvent être utilisé sur R1.
Donc je me corrige: chaque réservation peut être associé à 0,n -> CLIENT_PROMO
C'est vrai qu'une réservation doit obligatoirement avoir un CLIENT et elle est obligatoirement liée à un DRIVER
Bonsoir,
D’accord, mais alors dans le diagramme, représentez les cardinalités en conséquence.
Au lieu de :
[DRIVER]--|o----------------|<-[TRANSFER_BOOKING]->|----------------o|--[CLIENT]
Il faut les représenter ainsi :
[DRIVER]--||----------------o<-[TRANSFER_BOOKING]->0----------------||--[CLIENT]
Passons aux promos. Si l’on s’en tient à votre diagramme, une instance de CLIENT_PROMO ne peut exister que si elle fait référence à une instance de TRANSFER_BOOKING, alors qu’en réalité, ce n’est qu’au moment de la création d’une réservation, c'est-à-dire d’une instance de TRANSFER_BOOKING qu’on pourra établir le lien avec une promo d’un client. Pour arriver à cela, il faut définir une table d’association entre CLIENT_PROMO et TRANSFER_BOOKING :
Vous noterez que la clé primaire de TRANSFER_BOOKING est la paire {client_id, id_transfer_booking}, ce qui permet que la paire {client_id, id_transfer_booking} de la table d’association CLIENT_PROMO_TRANSFER_BOOK soit clé étrangère par rapport à la clé primaire de TRANSFER_BOOKING. D’autre part, la paire {client_id, promo_id} est à la fois clé primaire de la table CLIENT_PROMO_TRANSFER_BOOK et clé étrangère par rapport à la clé primaire de la table CLIENT_PROMO : cette structure de la table CLIENT_PROMO_TRANSFER_BOOK permet d’empêcher d’affecter des promos de Raoul à des réservations de Fernand.
Je ne sais toujours pas à quoi correspond l’attribut id_disposal_booking, ni quelles règles de gestion le gouvernent. Que vous en ayez fait un élément clé me laisse dubitatif, pour ne pas dire septique, voire inquiet...
Les lieux de départ et de destination sont déterminés par les attributs origin et destination de la table TRANSFER_BOOKING ?
Concernant les forfaits, qui décide de créer les parcours ? Quelqu’un de votre entreprise ? Les chauffeurs ? Même question quant au montant des forfaits...
C'est exactement cela. Mais un code promo P1 peut être utilisé par Raoul et Fernand pour leurs propres réservations. Soit R1 et R2 les réservations de Raoul et R3 et R4 les réservations de Fernand:
P1 peut être utilisé par Raoul sur R1 OU R2., mais pas les deux.
P1 peut être utilisé par Fernand sur R3 OU R4, mais pas les deux.
Raoul ne pourra biensûr en aucun cas utiliser P1 sur R3 ou R4.
Voici le schéma complet avec DISPOSAL_BOOKING en plus:
id_disposal_booking est liée à l'entité: DISPOSAL_BOOKING
Ceci est autre entité de réservation pour toutes les mises à dispositions. Les clients peuvent réserver sur un système de réservation à pars de celui dédié aux transferts d'un point A à un point B. DISPOSAL_BOOKING concerne les réservations où le client a besoin d'un véhicule mis à disposition avec un chauffeur pendant un certain nombre d'heures par jour.
pick_up_loc = le lieu de départ
drop_off_loc = le lieu de destination
hoursday = le nombre d'heures par jour du véhicule mis à disposition avec chauffeur
nb_days = le nombre de jours au total du véhicule mis à disposition avec chauffeur
C'est exactement cela!
Concernant les forfaits, seulement le chauffeur peut créer son parcours. Il y a seulement un lieu de départ et de destination, mais aucune étape entre les deux. Si le client veut un transfert de Nantes à Paris, mais qu'il veut passer par Rouen sur le chemin, pour déjeuner ou autre, la seule solution pour lui serait de négocier directement avec le chauffeur. Le chauffeur indique son prix sur le site uniquement par un forfait "Départ" -> "Destination". Aucune étape intermédiaire.
Quand le client effectue sa recherche sur le site pour un transfert de Paris à Roissy CDG par exemple, ce sont uniquement les chauffeurs qui auront mis pour lieu de départ "Paris" et de destination "Roissy CDG" (ou l'inverse) qui appaitrons dans les résultats (pour les prix sur "forfait") - et les autres chauffeurs qui auront mis pour lieu de départ "Paris" (pour les prix sur "km") apparaîtrons aussi.
Les prix "forfait" prennent l'avantage sur les prix "km", c'est à dire que si un chauffeur, Raoul, a dans son forfait: 50€ pour "Paris <-> Roissy CDG" et dans ses prix "km": 1,75€ par km pour les lieux de départs "Paris, Hauts-de-Seine, Versailles, Roissy CDG, Colombes". Ca sera le prix du forfait de 50€ de Raoul qui s'affichera pour le client et pas son prix "km".
Dans l'attente de votre réponse.
Merci beaucoup et passez une bonne journée.
Bonsoir,
Je réponds vite fait, car je suis pas mal pris par ailleurs...
On est d’accord, c’est bien sur la base de ce scénario que j’ai proposé le diagramme. Je suppose maintenant que si Raoul utilise la promo P1 pour la réservation R1, il ne doit pas pouvoir utiliser P1 pour une mise à disposition (disposal booking)... Qu’en est-il ?
Je vais me pencher sur le problème des forfaits dès que j’ai un moment...
Quel SGBD utilisez-vous ?
Bonsoir fsmrel,
OK. Et si on ajoutait juste un boolean pour savoir si le code promo a déjà été utilisé? Comme sur l'image en dessous:
Merci beaucoup !
J'utilise MySQL
Bonne soirée à vous.
Forfaits
Bonsoir Nike,
Les règes suivantes donnent lieu au diagramme ci-dessous, j’espère qu’elles conviennent...
Le chauffeur Fernand décide lui-même de ses forfaits. Il peut le faire par catégorie. Un forfait concerne un lieu de départ et un lieu d’arrivée. Fernand décide lui-même du montant de chaque forfait.
Ces règles donnent lieu à la mise en œuvre d’une table, nommée DRIVER_TARIF_FORFAIT dans le diagramme.
Exemple (pour faciliter la lecture, j’ai remplacé les id par les libellés correspondants) :
driver_id categorie_id depart_id destination_id montant_forfait --------- ------------ --------- -------------- --------------- Fernand ecocar Paris Nantes 230 Fernand ecovan Paris Nantes 250 Fernand buscar Paris Nantes 280 Fernand ecocar Paris Caen 120 Fernand buscar Paris Caen 140 Fernand ecocar Paris Cannes 500 Fernand ecovan Paris Cannes 150 Fernand ecocar Versailles Nantes 240 Raoul ecocar Paris Nantes 200 ... ... ... ... ...
La clé primaire de la table DRIVER_TARIF_FORFAIT est le quadruplet {driver_id, categorie_id, depart_id, destination_id}.
Les règles utilisées sont-elles en conformité avec votre système de gestion des forfaits ?
N.B. Je viens de voir votre proposition concernant les promos, je vais regarder ça.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager