Discussion :

[nike7414]

Bonjour,

J'ai commencé la discussion ici: http://www.developpez.net/forums/d15...e-blabla-like/
et je me suis rendu compte qu'il faut que je change ma BDD.

L'utilisateur fait une recherche pour trouver un transporteur dans sa ville, département ou région (en France ou dans d'autres pays d'Europe). Donc il tape son adresse complète à l'aide de Google Map Autocomplete API on souhaiterai récupérer cette adresse pour afficher les transporteurs qui se situent dans cette ville/département/région concernée.

J'ai modifié la structure de ma base de donnée à l'aide des cours sur ce site. Comme vous voyez sur la capture d'écran ci-dessous chaque ville est liée à une catégorie de prix. Le transporteur rentre ses prix qui sont catégorisés par type de véhicule, puis à la zone où il souhaite transporter des clients (soit des villes, des départements, des régions ou dans tout le pays). Les villes sont soient liées à des départements ou à des régions (les villes dans les autres pays d'Europe ne sont pas liés à des départements, mais à des régions).

Ci-dessous capture d'écran de la BDD avec les prix, les villes et les départements uniquement:



Ci-dessous capture d'écran de la BDD avec les prix, les villes, les départements, les régions et les pays :



Ci-dessous capture d'écran des réservations. Je n'ai pas réussi à mettre TIME() pour l'heure de prise en charge du client ("pickuptime" et "returntime"), donc j'ai laissé VARCHAR... Je recois l'erreur "TIME() contains errors and cannot be accepted. The previous value is kept instead.", comment ca se fait vous pensez?
Le chauffeur peut rentrer différentes marques de véhicules pour différentes catégories de véhicules dans "driver_vehicles", avec le nombre de bagages et de places disponibles dans chaque catégories de véhicules.
La table "driver_payment" correspond aux types de paiements acceptés par le chauffeur pour tous ses services.
"vehicle" dans "transfers_booking" correspond au véhicule que le client a choisie pour ce transfert (si jamais il veut en choisir un). Et "accepted" indique si un chauffeur a accepté cette course.



Vous avez des conseils encore pour améliorer encore la structure ?

En attente de votre réponse. Merci d'avance.

[fsmrel]

Bonsoir nike,

je me suis rendu compte qu'il faut que je change ma BDD.

Comme disait Jean dans les Tontons flingueurs, « Quand ça change, ça change... ». Essayons donc d’alléger la modélisation.

Vous avez représenté 3 catégories de prix : ecocar, ecovan, buscar, avec de nombreuses tables par catégorie : quand vous créerez une nouvelle catégorie, il y aura pas mal de travail pour faire évoluer la structure la base de données, et quand vous aurez plusieurs catégories supplémentaires, ça deviendra l’horreur...

En ce qui concerne les prix, les villes, les départements, les régions et les pays, je propose ceci :





La table TARIF contient les tarifs par catégorie de prix, même principe pour les tables DRIVER_TARIF et LIEU_TARIF.

Table LIEU : un lieu est soit un pays, une région, un département ou une ville. La table REGION_DEPT permet de rattacher une ville soit à un département, soit à une région.


Remarques

Vous ne prenez pas en compte les dates d’application des tarifs, la TVA et ses dates d’application. Est-ce normal ?

Vous ne prenez pas en compte le type de la monnaie. Les prix sont tous en euros ?


Je regarderai les réservations un peu plus tard.

[nike7414]

Bonsoir nike,




Comme disait Jean dans les Tontons flingueurs, « Quand ça change, ça change... ». Essayons donc d’alléger la modélisation.

Vous avez représenté 3 catégories de prix : ecocar, ecovan, buscar, avec de nombreuses tables par catégorie : quand vous créerez une nouvelle catégorie, il y aura pas mal de travail pour faire évoluer la structure la base de données, et quand vous aurez plusieurs catégories supplémentaires, ça deviendra l’horreur...

En ce qui concerne les prix, les villes, les départements, les régions et les pays, je propose ceci :


La table TARIF contient les tarifs par catégorie de prix, même principe pour les tables DRIVER_TARIF et LIEU_TARIF.

Table LIEU : un lieu est soit un pays, une région, un département ou une ville. La table REGION_DEPT permet de rattacher une ville soit à un département, soit à une région.


Remarques

Vous ne prenez pas en compte les dates d’application des tarifs, la TVA et ses dates d’application. Est-ce normal ?

Vous ne prenez pas en compte le type de la monnaie. Les prix sont tous en euros ?


Je regarderai les réservations un peu plus tard.

Merci pour votre réponse! En effet ca m'a l'air beaucoup plus simple avec moins de tables.

Pour les lieux je n'ai pas très bien compris... Vous pouvez mieux m'expliquer?
J'ai pensé stoker des listes de villes, pays, régions et départements dans une table chacune correspondante dans ma base de donnée.
Avec le modèle que vous me proposez je stockerai tous les noms des villes, pays, régions et départements seulement dans une seule table "LIEU" ?
Tous les noms vont être mélangés et surtout si j'ai plein de pays différents ca va faire une table chargée, non?

J'ai refait le schéma par moi même:




EDIT:
Pour le moment c'est le chauffeurs qui proposent leurs propre prix et les clients payent sur place avec le chauffeur. Mais nous pensons dans l'avenir faire payer le client sur le site une commission qui sera ajoutée sur le total du tarif de la course. Le client pourra ensuite payer le chauffeur sur place.
Le chauffeur pourra cocher une option s'il est auto-entrepreneur, donc pas de TVA. Mais sinon il devra indiquer son taux de TVA qui est par défaut inclus dans le prix. Donc le prix que nous indiquons dans la BDD est par défaut en TTC. Il devra cependant indiquer son taux de TVA pour que nous puissions le transmettre sur les factures.

En ce qui concerne le type de monnaie, pour le moment on garde l'euro pour l'Europe mais on rajoutera usd plus tard pour les USA.

En attente de votre réponse.

[escartefigue]

le 2ème modèle qui concerne les réservations me pose pas mal de soucis :
- vous associez la capacité en bagages (table driver_lugage) à un conducteur (table driver), la capacité est liée à un véhicule, pas à son conducteur
- de même, vous associez le nombre de place assises (table driver seats) au paiement (table driver_payement), là encore c'est un attribut du véhicule
- je n'ai pas compris à quoi correspond fonctionnellement la table driver-vehicle ? quoi qu'il en soit cette table semble mal modélisée pourquoi avoir 7 colonnes varchar(100) en fonction du type de véhicule, plutôt qu'une seule colonne dans une table issue d'une association, et dont la clef serait composée en partie du type de véhicule. Répeter les colonnes dans une table implique de modifier la table si un nouveau type de véhicule apparait
- même remarque pour la table driver_lugage, il ne faut pas répéter les colonnes mais avoir une table ayant pour clef le n° de véhicule (que ce soit un bus, une berline ou une moto) et pour attribut sa capacité en bagages (capacité en volume ET en poids).

votre schéma est déjà au niveau MLD, l'étape MCD (conceptuelle donc) est un pré-requis souvent nécessaire, et dans votre cas obligatoire, vu la complexité du modèle

autre remarque : la colonne returntime, si elle a vocation a stocker des heures, doit être définie en format time et non varchar
Attention à bien utiliser les bons formats de colonnes

Edit :
les colonnes transfert_booking.origin et transfert_booking.destination sont je suppose les lieux de départ et d'arrivée, auquel cas remplacez les par des codes lieux
- vous serez gagnant en fiabilité des infos, les codes lieux pointant sur une table renvoyant les libellés
- vous serez gagnant en stabilité des infos, les noms de rue, de régions et moins souvent mais ça arrive de pays, peuvent changer, les codes beaucoup moins.
- vous serez gagnant en perfs, les tables seront plus petites, au bénéfice de votre réseau et de votre espace disque

La colonne flightnumber, est probablement de type numérique plutôt que varchar

Les tables clients et driver ne doivent pas contenir l'adresse
- un client ou conducteur peut avoir plusieurs adresses
- un client qui habite Clermont Ferrand, peut avoir besoin de réserver un véhicule à Compiègne
vous devez donc avoir une table des adresses et un lien client-adresse

Les tables clients et driver ne doivent pas contenir les moyens de contact (téléphone, mail etc...)
même argumentaire que les adresses

[nike7414]

le 2ème modèle qui concerne les réservations me pose pas mal de soucis :
- vous associez la capacité en bagages (table driver_lugage) à un conducteur (table driver), la capacité est liée à un véhicule, pas à son conducteur
- de même, vous associez le nombre de place assises (table driver seats) au paiement (table driver_payement), là encore c'est un attribut du véhicule
- je n'ai pas compris à quoi correspond fonctionnellement la table driver-vehicle ? quoi qu'il en soit cette table semble mal modélisée pourquoi avoir 7 colonnes varchar(100) en fonction du type de véhicule, plutôt qu'une seule colonne dans une table issue d'une association, et dont la clef serait composée en partie du type de véhicule. Répeter les colonnes dans une table implique de modifier la table si un nouveau type de véhicule apparait
- même remarque pour la table driver_lugage, il ne faut pas répéter les colonnes mais avoir une table ayant pour clef le n° de véhicule (que ce soit un bus, une berline ou une moto) et pour attribut sa capacité en bagages (capacité en volume ET en poids).

votre schéma est déjà au niveau MLD, l'étape MCD (conceptuelle donc) est un pré-requis souvent nécessaire, et dans votre cas obligatoire, vu la complexité du modèle

autre remarque : la colonne returntime, si elle a vocation a stocker des heures, doit être définie en format time et non varchar
Attention à bien utiliser les bons formats de colonnes

Edit :
les colonnes transfert_booking.origin et transfert_booking.destination sont je suppose les lieux de départ et d'arrivée, auquel cas remplacez les par des codes lieux
- vous serez gagnant en fiabilité des infos, les codes lieux pointant sur une table renvoyant les libellés
- vous serez gagnant en stabilité des infos, les noms de rue, de régions et moins souvent mais ça arrive de pays, peuvent changer, les codes beaucoup moins.
- vous serez gagnant en perfs, les tables seront plus petites, au bénéfice de votre réseau et de votre espace disque

La colonne flightnumber, est probablement de type numérique plutôt que varchar

Les tables clients et driver ne doivent pas contenir l'adresse
- un client ou conducteur peut avoir plusieurs adresses
- un client qui habite Clermont Ferrand, peut avoir besoin de réserver un véhicule à Compiègne
vous devez donc avoir une table des adresses et un lien client-adresse

Les tables clients et driver ne doivent pas contenir les moyens de contact (téléphone, mail etc...)
même argumentaire que les adresses

escartefigue,

Merci pour votre réponse.

- J'associe la capacité en bagages (table driver_lugage) à un conducteur (table driver), car le conducteur peut lui même entrer le nombre de valises qui est associé à la catégorie. Chaque conducteur définie la quantité de bagages et de sièges dans son véhicule.

- On le voit peut être mal sur mon image mais la table driver seats est associée elle aussi à un conducteur (table driver).

- Dans driver_vehicle le chauffeur indique toutes les marques des véhicules qu'il dispose de chaque catégorie (ou dans la catégorie qu'il souhaite).
Je vais faire les modifs comme vous m'avez conseillé pour voir ce que ca donne.

- Pour returntime j'ai un soucis technique qui me pose problème, donc je vais essayer de régler ca plus tard.

- Pour la colonne flightnumber j'ai mis en varchar pour les numéros de vol de type AF123 ou SK578. Il n'y a pas que des chiffres.

- Concernant les colonnes transfert_booking.origin et transfert_booking.destination je ne vois pas trop de ce que vous voulez dire par des codes lieux, car une addresse complètement ne dispose pas de code lieu comme les départements ou les régions, mais plutot des coordonnées longitude et latitude.
Dailleurs, ces address sont récupérés par Google Places API et pas google map comme j'avais indiqué plus haut. C'est un formulaire de recherche où le client tape son addresse et l'api l'Autocomplete avec Google Places.

Pour les tables client et driver il faudrait donc ajouter une table séparée où on stock toutes les addresses.
On aurait aussi une table téléphone et une table email, ca ne fait pas trop de tables?

[fsmrel]

Bonsoir nike et escartefigue,


Voici un premier lot de réponses.

Vous voulez dire que c'est le chauffeur qui rentre le nom de sa ville/région/département sans qu'elle existe déjà dans la base de donnée?

Dans le diagramme que j’ai proposé, je ne considère que le QUOI et certainement pas le COMMENT, c’est un principe de base quand on modélise les données. Cela dit, peut-être voulez-vous dire qu’il manque une association entre les entités-types DRIVER et VILLE (mais je n’en vois pas dans vos diagrammes). Si tel est le cas, je complète le diagramme en associant les deux entités-types (et j’en profite pour ajouter le code postal dans l’entité-type VILLE) :

L'étape MCD (conceptuelle donc) est un prérequis souvent nécessaire.

C’est exact, c’est pourquoi je n’omets d’en produire un, car la dimension sémantique y est incomparablement plus présente (même si de son côté MySQL Workbench prétend se rattacher à l’approche « entité-relation étendue » (sic !)) :




Ce MCD a été réalisé avec PowerAMC, mais si vous préférez une version DB-MAIN (gratuit), pas de problème pour changer de dialecte.

Remarque à propos de ce MCD :

Les différents types de lieux ont fait l’objet de ce qu’on appelle en modélisation une généralisation (cf. l’ouvrage téléchargeable de D. Nanci et B. Espinasse, Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001) :

Les entités-types DEPARTEMENT et REGION ont fait l’objet d’une généralisation en une entité-type REGION_DEPT, elles en deviennent de sous-types et héritent automatiquement des propriétés de REGION_DEPT. Cet héritage est symbolisé par la lunule connectant les deux sous-types et leur surtype. Cette lunule comporte un symbole d’exclusion souligné, ce qui exprime le partitionnement (exclusion et totalité) des sous-types. Ce qui se traduit ainsi selon le formalisme cher à Pierre Dac in Essais, Maximes, Conférences :

Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde.

Sic locutus est Petrus.

De la même façon, les entités-types PAYS, REGION_DEPT et VILLE ont fait l’objet d’une généralisation en une entité-type LIEU, elles en deviennent de sous-types et héritent automatiquement des propriétés de LIEU. Ainsi, les attributs communs aux différentes entités-types sont « factorisées » dans le surtype lieu, en l’occurrence le nom d’un lieu, c'est-à-dire nom de pays, de région, de département, de ville. L’association TYPER permet de savoir à quel type de lieu de rapporte un nom. Bien sûr, on pourrait ce passer de cette association (donc de l’entité-type TYPE_LIEU), c’est une redondance, mais elle est commode. Cela veut dire aussi qu’au stade SQL il faudra prévoir une ASSERTION (ou des triggers si le SGBD ne propose pas l’instruction CREATE ASSERTION), pour s’assurer que, si un lieu est par exemple une ville, la valeur de l’attribut lieu_id de la table LIEU sera bien une valeur de l’attribut ville_id de la table VILLE, et uniquement de cette table.

L’intérêt de la généralisation est aussi dans votre cas de factoriser les associations avec les tarifs (entité-type TARIF).

A noter que l’entité-type DRIVER est associée à l’entité-type VILLE, mais pas aux entités-types DEPARTEMENT, REGION et PAYS : si on veut connaître le département ou la région ou le pays d’une ville, grâce aux associations V_DR, D_R et R_P, on sait répondre et on évite les redondances (sempiternelles ennemies des bases de données).

[escartefigue]

- J'associe la capacité en bagages (table driver_lugage) à un conducteur (table driver), car le conducteur peut lui même entrer le nombre de valises qui est associé à la catégorie. Chaque conducteur définie la quantité de bagages et de sièges dans son véhicule.

Je rejoins sur ce point la remarque de Fsmrel : au niveau conceptuel, il ne faut pas se préoccuper de qui fait, ni de quand ni de comment, mais seulement de qui/quoi est en relation avec qui/quoi et quelles sont les natures de ces relations (obligatoires, facultatives, uniques, multiples, exclusives etc...)
Le fait que le conducteur saisisse ce type d'information ne change en rien que la capacité en poids et volume et bien un attribut du véhicule, il faut donc le modéliser en ce sens.
Et comme je le répète souvent, toute quantité doit être accompagnée d'une unité de mesure

- Dans driver_vehicle le chauffeur indique toutes les marques des véhicules qu'il dispose de chaque catégorie (ou dans la catégorie qu'il souhaite).
Je vais faire les modifs comme vous m'avez conseillé pour voir ce que ca donne.

Je doute qu'il soit intéressant de connaitre les marques par chauffeur et catégorie, mais même si cette analyse peut avoir un intérêt, ce n'est pas pour autant qu'il en résulte une entité conceptuelle
encore une fois, identifiez les entités et leurs liens, sans vous préoccuper dans une premier temps des extractions et autres rapports que vous aurez à produire

- Pour returntime j'ai un soucis technique qui me pose problème, donc je vais essayer de régler ca plus tard.

Les aspects techniques n'ont aucune incidence au niveau de modèle conceptuel, il peuvent intervenir mais bien plus tard

- Pour la colonne flightnumber j'ai mis en varchar pour les numéros de vol de type AF123 ou SK578. Il n'y a pas que des chiffres.

comme cette information n'a pas de sens si le véhicule est autre chose qu'un avion, il faut modéliser soit une entité spécifique, soit un sous-type qui possèdera cet attribut

- Concernant les colonnes transfert_booking.origin et transfert_booking.destination je ne vois pas trop de ce que vous voulez dire par des codes lieux, car une addresse complètement ne dispose pas de code lieu comme les départements ou les régions, mais plutot des coordonnées longitude et latitude.
Dailleurs, ces address sont récupérés par Google Places API et pas google map comme j'avais indiqué plus haut. C'est un formulaire de recherche où le client tape son addresse et l'api l'Autocomplete avec Google Places.

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.

Pour les tables client et driver il faudrait donc ajouter une table séparée où on stock toutes les addresses.
On aurait aussi une table téléphone et une table email, ca ne fait pas trop de tables?

Le nombre de tables n'a pas d'importance (sans tomber dans l'excès bien sur) et il vaut mieux plus de tables bien découpées, que des tables fourre tout, dites "obèses" (perfs dégradées, problèmes de concurrence d'accès, etc...)
Cela dit, concentrez vous sur le conceptuel, et oubliez (pour l'instant) ce que seront les tables

Une remarque d'ordre général : vous pouvez découper les citations : il suffit de copier/coller les balises de début et fin (balises QUOTE et /QUOTE), ca facilite la lecture, on voit mieux la correspondance des questions et des réponses

[fsmrel]

Un autre lot de remarques...


J’observe que dans vos diagrammes, les attributs des tables peuvent le plus souvent être marqués Null : tous les losanges blancs doivent devenir bleus...

Il y a vraisemblablement des cardinalités minimales 0 à mettre en place. Par exemple, dans votre dernier diagramme, une instance de PRICE est en relation avec au moins une instance de DRIVER_PRICE : est-ce bien le cas dans la réalité ?

Toujours dans votre dernier diagramme, vous avez établi une bijection entre DRIVER et CLIENT_DRIVER_DETAILS : si c’est bien ce que vous voulez, alors vous ne devriez les fondre une seule table.

Vous avez établi une bijection entre PLACE et CITY : tout lieu (place) est donc une ville (city). Clairement, ça n’est pas le cas, il faut remplacer la bijection par une injection (voyez mes diagrammes).


Votre diagramme comporte un erreur. La table REGION_DEPARTEMENT doit être débarrassée des attributs region_id et departement_id, car chaque valeur prise par l’attribut place_id dans cette table est soit une valeur de region_id (table REGION), soit une valeur de departement_id (table DEPARTEMENT) :




Exemple correct :


TYPE_PLACE

type_place_id    type_place_name
-------------    ---------------
1                pays
2                région
3                département
4                ville
5                canton

PLACE

place_id    place_name               type_place_id
--------    ---------------------    -------------
1           Nîmes                    4
2           Lyon                     4
3           Brest                    4
4           Finistère                3
5           Crans-sur-Sierre         4
6           Gard                     3
7           Languedoc-Roussillon     2
8           Valais                   5
9           France                   1
10          Rhône                    3
11          Suisse                   1
12          Bretagne                 2
13          Rhône_Alpes              2
...         ...                      ...

COUNTRY

contry_id    contry_code
---------    -----------
9            FR
11           CH
...          ...

REGION_DEPARTEMENT

place_id 
--------
4
6
7
8
10
12
13
...

REGION

region_id    region_code    country_id
---------    -----------    ----------
7            ?             9
8            ?             11
12           ?             9
13           ?             9
...          ...           ...

DEPARTEMENT

departement_id    dept_code    region_id
--------------    ---------    ---------
4                 29           12
6                 30           7
10                59           13
...               ...          ...

CITY

city_id    place_id    code_postal    latitude    longitude
-------    --------    -----------    --------    ---------
1          6           30000          43.8333     5.35
2          13          59000          45.7500     4.85
3          4           29000          48.4000     -4.4833
5          8           3963           46.3075     7.468
...        ...         ...            ...         ...

[escartefigue]

Pour mieux éclairer le propos concernant votre remarque :

- J'associe la capacité en bagages (table driver_lugage) à un conducteur (table driver), car le conducteur peut lui même entrer le nombre de valises qui est associé à la catégorie. Chaque conducteur définie la quantité de bagages et de sièges dans son véhicule.

Il faut vous poser la question suivante : quand j'ai identifié un conducteur, admettons par son nom et son prénom même si dans les faits ce n'est pas la bonne méthode, est-ce que je peux en déduire la capacité en bagages ?
Non
Car le conducteur peut posséder plusieurs véhicules
A l'inverse, quand j'ai identifié un véhicule, je peux en déduire sa capacité en bagages
Bien sur il faut identifier le véhicule, la clio rouge que M. Dupond a acheté l'année dernière, que je peux identifier par exemple par son numéro de carte grise, et non pas le modèle de véhicule (la clio en général qui a pu avoir des versions différentes avec des volumes de coffre différents en fonction des millésimes ou équipements)

Ceci renvoie, encore, à Merise, et plus précisément à la 2ème forme normale.
Règle à appliquer systématiquement, elle ne soufre aucune exception

[fsmrel]

Bonsoir,


A propos des catégories de véhicules :

il ne faut pas répéter les colonnes mais avoir une table ayant pour clef le n° de véhicule (que ce soit un bus, une berline ou une moto) et pour attribut sa capacité en bagages (capacité en volume ET en poids).

Exact ! Répéter les colonnes n’est pas modéliser correctement. En effet, lors des opérations de maintenance, il vaut mieux avoir à ajouter une ligne dans une table, opération anodine, qu’une colonne dans l’en-tête de celle-ci, opération périlleuse s'il en est ! De ce point de vue, les tables driver_vehicles et driver_seats sont peccamineuses.

On doit donc préférer mettre en œuvre une entité-type, appelons-la par exemple CATEGORIE_VEHICULE, permettant de connaître les catégories de véhicules :

CATEGORIE_VEHICULE

categorie_vehicule_id    categorie_vehicule_nom
---------------------    ----------------------
1                        ecocar
2                        ecovan
3                        buscar
4                        busvan
5                        luxcar
6                        moto
7                        coach

Dans ces conditions, ajouter un nouveau type de véhicule ne pose aucun problème. Maintenant, la capacité en bagages — en volume et en poids (mais pour simplifier, j’en resterai au nombre de valises) — n’est certainement pas directement liée à la catégorie de véhicule, car cela voudrait dire que, quels que soient les véhicules, pour le type ecocar, le type moto, etc., c’est tant de valises, point barre. Si on passe à un maille plus fine, c'est-à-dire au modèle du véhicule, c’est moins déraisonnable.

Je cite nike : « le chauffeur indique toutes les marques des véhicules dont il dispose dans chaque catégorie ».

Plutôt qu’en rester à la marque, je pense qu’on peut descendre au niveau du modèle. Je suppose encore que nike n’a pas l’intention de gérer le catalogue des marques et modèles, aussi laissera-t-on le chauffeur commettre des fautes d’orthographe et écrire « Renaud Cliau IV fase 1 » ou définir des modèles imaginaires, se planter dans la capacité en bagages ou dans le nombre de places : tant pis pour lui...

Exemple :


DRIVER

driver_id    driver_nom    ...
---------    ----------    ----
1            Fernand       ...
2            Raoul         ...
3            Paul          ...

DRIVER_VEHICULE

driver_vehicule_id    driver_id    categorie_vehicule_id    marque      modele             capacite    seats
------------------    ---------    ---------------------    ------      ---------------    --------    -----
1                     1            3                        Renault     Clio IV phase 1    3           5
2                     1            3                        Renault     Clio III phase 2   3           5
3                     1            3                        Citroën     C3 II              4           5
4                     1            6                        Terrot      350 HST            1           1
5                     2            3                        Renault     Clio III phase 2   3           5
...

Je ne sais pas si cet exemple est pertinent, mais il correspond à la modélisation suivante :






Il y a du viol de troisième forme normale dans l’air, mais bon... On pourra revenir là-dessus.

[nike7414]

Exemple correct :

Bonjour,

Merci j'ai enfin compris grâce à votre super exemple !

Il y a vraisemblablement des cardinalités minimales 0 à mettre en place. Par exemple, dans votre dernier diagramme, une instance de PRICE est en relation avec au moins une instance de DRIVER_PRICE : est-ce bien le cas dans la réalité ?

J'ai fait les modifs nécessaires pour le manque de des cardinalités minimales 0 et les autres problèmes de relation.
J'espère que ma modification correspond bien à vos corrections.

J'ai aussi ajouté une table "category_characteristics" qui correspond aux caracteristiques de chaque catégorie. Je rajouterai moi même par exemple "wifi", "water", "magazines", "candies" ou autre au fur et à mesure. Ces noms sont liés à des icones qui s'afficherons sur le site, donc dans "category_characteristics_icone" je spécifie le chemin vers chaque icone (par exemple "img/icones/wifi.png").

J'ai ajouté un tableau "driver_payment". Le chauffeur coche s'il accepte le paiement en espèces ou par carte bancaire directement sur place. Il peut aussi cocher si son prix n'inclus pas la TVA (auto-entrepreneur), sinon il indique le taux de TVA qui est inclus dans le prix et ce taux s'enregistre dans "vat_rate".
Je rappel que les prix dans la table "price" sont tous en TTC.

J'ai ajouté une table "driver_languages". J'aurai une liste de langues qui s'affichera sur le site et le chauffeur cochera les langues qu'il parle. Elles s'enregistreront ensuite dans la table.

votre schéma est déjà au niveau MLD, l'étape MCD (conceptuelle donc) est un pré-requis souvent nécessaire, et dans votre cas obligatoire, vu la complexité du modèle

En effet votre MCD m'a aidé à mieux comprendre! Je vais essayer de refaire ceci avec un des logiciels.


Vous avez des corrections ou des suggestions ?

[escartefigue]

Comme déjà mentionné :
- il est préférable de sortir les éléments de la table driver (ou toute autre table) qui peuvent être multiples : adresse, téléphone, email etc..
- pensez à systématiquement ajouter des unités de mesure, quand vous avez des quantités, prix, poids, montants etc...
- latitude et longitude ne doivent pas être des varchar mais des numériques avec décimales

[fsmrel]

Bonsoir,


Votre diagramme s’aère, on y voit plus clair !

En ce qui concerne les lieux, ça va mieux côté cardinalités Mais attention, vous avez perdu le lien entre COUNTRY et REGION, il faut donc le rétablir.

J'ai ajouté un tableau "driver_payment". Le chauffeur coche s'il accepte le paiement en espèces ou par carte bancaire directement sur place.

Vous avez défini deux attributs, cash_onboard et card_onboard : ils peuvent prendre à la fois la valeur 1, c'est-à-dire que le chauffeur accepte en ce cas indifféremment les deux modes de paiement. C’est bien cela ? Par ailleurs, ceci concerne le paiement sur place, mais peut-on payer autrement que de cette façon (cash_onboard = 0 et card_onboard= 0) ?

Il peut aussi cocher si son prix n'inclus pas la TVA (auto-entrepreneur), sinon il indique le taux de TVA qui est inclus dans le prix et ce taux s'enregistre dans "vat_rate".

La valeur prise par l’attribut no_vat se déduit automatiquement de la valeur prise par l’attribut vat_rate :

Si vat_rate = 0 (cas de l’auto-entrepreneur), alors no_vat vaut nécessairement 0, et si vat_rate est > 0 alors no_vat vaut nécessairement 1. En conséquence, l’attribut no_vat ne sert à rien et on le dégage.

J'ai ajouté une table "driver_languages".

D’accord, mais si l’on utilise des exemples, on se rend compte qu’on pourrait mettre en œuvre une table des langues, il n’y en a quand même pas des dizaines...

Exemple :


DRIVER

driver_id    driver_nom    ...
---------    ----------    ----
1            Fernand       ...
2            Raoul         ...
3            Paul          ...
4            Théo          ...
5            Pascal        ...

LANGUAGE

language_id    language_name_VO    language_name_VF
-----------    ----------------    ----------------
1              français            français
2              español             espagnol
3              italiano            italien
4              gaeilge             gaëlique (irlandais)
5              gàidhlig            gaëlique (écossais) 
6              português           portugais
7              deutsch             allemand
8              pусский             russe
9              brezhoneg           breton 
...            ...                 ...

DRIVER_LANGUAGE

driver_id    language_id
---------    -----------
1            1
1            2
1            3
2            1
2            8
3            1
4            1
4            7
5            1
5            3
...          ...

=>

votre schéma est déjà au niveau MLD, l'étape MCD (conceptuelle donc) est un prérequis souvent nécessaire, et dans votre cas obligatoire, vu la complexité du modèle

En effet votre MCD m'a aidé à mieux comprendre!

Euh... Ce MCD est mon enfant...

Cela dit, n’oubliez pas de suivre les recommandations d’escartefigue.

j'ai enfin compris grâce à votre super exemple !

Alors n’hésitez pas à cliquer sur les pouces verts !


A suivre...

[nike7414]

D’accord, mais si l’on utilise des exemples, on se rend compte qu’on pourrait mettre en œuvre une table des langues, il n’y en a quand même pas des dizaines...

Exemple :


DRIVER

driver_id    driver_nom    ...
---------    ----------    ----
1            Fernand       ...
2            Raoul         ...
3            Paul          ...
4            Théo          ...
5            Pascal        ...

LANGUAGE

language_id    language_name_VO    language_name_VF
-----------    ----------------    ----------------
1              français            français
2              español             espagnol
3              italiano            italien
4              gaeilge             gaëlique (irlandais)
5              gàidhlig            gaëlique (écossais) 
6              português           portugais
7              deutsch             allemand
8              pусский             russe
9              brezhoneg           breton 
...            ...                 ...

DRIVER_LANGUAGE

driver_id    language_id
---------    -----------
1            1
1            2
1            3
2            1
2            8
3            1
4            1
4            7
5            1
5            3
...          ...

Bonsoir,

Comme vous voyez ci-dessous, dans la table "language" j'ai ajouté toutes les traductions des langues, car mon site sera traduit en plusieurs langues grâce à Poedit. C'est peut être mieux dans ce cas, pour le choix des langues du chauffeur, de les traduire puis de les insérer ensuite dans la table "language"?

Comme déjà mentionné :
- il est préférable de sortir les éléments de la table driver (ou toute autre table) qui peuvent être multiples : adresse, téléphone, email etc..
- pensez à systématiquement ajouter des unités de mesure, quand vous avez des quantités, prix, poids, montants etc...
- latitude et longitude ne doivent pas être des varchar mais des numériques avec décimales

Merci pour les explications. J'ai créé un schéma MCD avec AnalyseSi ci-dessous. Les tables client et chauffeur sont associés avec une association "client_driver_communicate" où ils peuvent indiquer plusieurs numéros de tel, emails et adresses. Alors que l'association "client_driver_detail" ne peut se répéter qu'une fois par chauffeur ou client.
Un chauffeur peut cependant avoir un compte client avec son même adresse email, mdp, prénom, nom, numéro de tel.

Pour les réservations, le client est obligé de créer un compte ou de se connecter pour la valider. Une fois validé c'est envoyé par email au chauffeur qu'il a choisie. Si le chauffeur n'accepte pas avant un délais de 2h l'email est envoyé à tous les autres chauffeurs situés dans la même zone d'activité que celui-ci (soit ville, dept, région ou pays - selon la zone d'activité qu'il a défini depuis son back-office)
Une fois la réservation accepté "accepte" change de valeur est devient 1 (par défaut la valeur est 0).
Dans cette table "transfer_booking" j'ai aussi "client_id (fk)" et "driver_id (fk)" qui prennent la valeur du client et du chauffeur destiné, puis change pour prendre la valeur du chauffeur qui a finalement accepté la course.

Le MCD ci-dessous est-il bien correct?



En attente impatiente de vos réponses pertinentes.

Merci pour votre aide.

[escartefigue]

bonjour,

Pour ce qui concerne les langues, vous devriez modéliser comme ceci :



L'association "parler une langue" peut être porteuse d'une propriété niveau (scolaire, courant, bilingue....)
elle deviendra de ce fait une table dont l'identifiant sera hérité de driver et de language

Je reviendrai vers vous pour la suite

[nike7414]

L'association "parler une langue" peut être porteuse d'une propriété niveau (scolaire, courant, bilingue....)
elle deviendra de ce fait une table dont l'identifiant sera hérité de driver et de language

Escartefigue,

Bonne idée!

Voila ce que ca donne pour les langues:



Et voici ce que ca donne quand j'ajoute un code promo à mes réservations:
Le client peut entrer plusieurs codes promo mais chaque code peut être utilisé qu'une fois par client.
Chaque réservation peut être liée qu'à un seul code promo.



Et en passant sur Mysql Workbench:



Vous avez des remarques par rapport à ceci?

Merci pour votre aide qui m'est très bénéfique!

En attente de votre réponse.

[escartefigue]

Encore quelques remarques avant le WE

Pour le niveau de langue : vous ne pouvez pas gérer plusieurs booléens pour une même notion dans une même entité
(au risque que 2 booléens soient activés en même temps, ce qui ne voudrait rien dire)
Le niveau de langue doit donc etre une seule colonne pouvant prendre plusieurs valeurs, par exemple 1 à 4
Ces valeurs sont en relation avec une entité "niveau linguistique" ayant pour identifiant le code (de 1 à 4 dans mon exemple) et pour attribut le libellé (exemple 1:scolaire, 2:moyen, 3:confirmé, 4:expert)

Pour les dates et heures, votre projet étant international, il faut préciser le fuseau horaire de chaque horodatage (ou imposer à tous le même, ce qui est peu crédible)

Pour les moyens de contact, vous pouvez modéliser comme suit :



Cette modélisation peut aussi être appliquée pour les adresses
Je mis rel1, rel2 etc... dans les relations par manque d'imagination, vous trouverez bien quelque chose de plus parlant
Attention, les cardinalités sont à adapter à vos règles de gestion : par exemple, j'ai supposé que tout chauffeur avait forcément au moins un email, ce n'est peut être pas le cas
L'attribut priority dans les associations REL1 et REL2, permet de donner une priorité aux moyens de contact (n° de téléphone favori, mail favori)
L'attribut type dans les entités téléphone et mail, permettent de préciser : téléphone fixe professionnel, fixe domicile, portable pro, portable d'astreinte etc...
le libellé de chaque typologie est décrit dans une entité-type qui va bien (tel_type et email_type)

Les adresses de vos chauffeurs et de vos clients peuvent être modélisées sur le même principe que les téléphones et les mails :
Une entité type "drivers"
Une entité type "address"
Une relation "driver_address" porteuse d'une propriété type d'adresse (adresse de domicile, de facturation, de livraison etc....) et qui peut être temporelle si besoin (valide du ... au...)
Une entité "address_type" qui décrit les type d'adresses

[fsmrel]

Bonsoir,

L'association "parler une langue" peut être porteuse d'une propriété niveau (scolaire, courant, bilingue....)
elle deviendra de ce fait une table dont l'identifiant sera hérité de driver et de language

C'est-à-dire qu’on retrouvera au stade MySQL Workbench (~MLD des merisiens) ce que j’avais proposé, avec le niveau (level) en plus (voire d’autres attributs si le besoin s’en faisait sentir) :





Mais dans ces conditions, afin qu’on n’y mette pas n’importe quoi, l’attribut level doit faire l’objet d’une contrainte au stade SQL (sans oublier que la contrainte CHECK n’existe pas avec MySQL). Quitte à utiliser un MCD merisien, il faut en passer par la définition d’une entité-type LEVEL, ce qui de facto conduit à mettre en œuvre une association ternaire avec une CIF (contrainte d’intégrité fonctionnelle) à la clé, mais en Merise c’est le prix à payer... La CIF est symbolisée ci-dessous par la flèche rouge, et contraint à ce que pour une paire {DRIVER, LANGUAGE}, il n’y ait un seul niveau (level), en termes merisiens : DRIVER X LANGUAGE → LEVEL :





=> La clé primaire de la table SPEAKS est bien la paire {driver_id, language_id} :





Exemple :

DRIVER

driver_id    driver_nom    ...
---------    ----------    ----
1            Fernand       ...
2            Raoul         ...
3            Paul          ...
4            Théo          ...
5            Pascal        ...

LANGUAGE

language_id    language_name_VO    language_name_VF
-----------    ----------------    ----------------
1              français            français
2              español             espagnol
3              italiano            italien
4              gaeilge             gaëlique (irlandais)
5              gàidhlig            gaëlique (écossais) 
6              português           portugais
7              deutsch             allemand
8              pусский             russe
9              brezhoneg           breton 
...            ...                 ...

LEVEL

level_id    level_value
--------    -----------
1            basic     
2            fluent    
3            awful     

SPEAKS

driver_id    language_id    level_id
---------    -----------    --------
1            1              2
1            2              1
1            3              2
2            1              2
2            8              3
3            1              2
4            1              2
4            7              2
5            1              2
5            3              2
...          ...            ... 
 

Tous les AGL ne savent pas dériver une CIF en clé primaire. WinDesign et DB-MAIN savent faire, pour les autres, je ne sais pas (quant à PowerAMC, avec Merise, il ne permet pas de définir de CIF ). A ce propos, quel est le vôtre ?

[nike7414]

Tous les AGL ne savent pas dériver une CIF en clé primaire. WinDesign et DB-MAIN savent faire, pour les autres, je ne sais pas (quant à PowerAMC, avec Merise, il ne permet pas de définir de CIF ). A ce propos, quel est le vôtre ?

Bonsoir,

Merci pour vos précisions.
En effet c'est peut être mieux de mettre les différents niveaux dans une autre table.
J'utilise AnalyseSI qui ne permet pas ce genr de relation malheureusement... C'est un logiciel très simple.

Les adresses de vos chauffeurs et de vos clients peuvent être modélisées sur le même principe que les téléphones et les mails :
Une entité type "drivers"
Une entité type "address"
Une relation "driver_address" porteuse d'une propriété type d'adresse (adresse de domicile, de facturation, de livraison etc....) et qui peut être temporelle si besoin (valide du ... au...)
Une entité "address_type" qui décrit les type d'adresses

Oui, c'est vrai que c'est mieux de cette facon si on veut utiliser plusieurs types d'emails ou d'adresses.

Pour le code promo et le "transfer_booking" vous n'avez aucune remarque?

Vous avez défini deux attributs, cash_onboard et card_onboard : ils peuvent prendre à la fois la valeur 1, c'est-à-dire que le chauffeur accepte en ce cas indifféremment les deux modes de paiement. C’est bien cela ? Par ailleurs, ceci concerne le paiement sur place, mais peut-on payer autrement que de cette façon (cash_onboard = 0 et card_onboard= 0) ?

Pour le paiement à bord j'ai que deux options oui, j'ai donc supprimé cash_onboard. Si card_onboard = 0 alors forcément cash_onboard = 1.
Dans le future on pense rajouter un pourcentage de commission sur toutes réservations effectuées et un troisième mode de paiement où le client pourra choisir de payer la totalité du prix du transfer en ligne.

Voici finalement ce que ca donne:



Passez un bon weekend !

[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 ?

Quoi qu’il en soit, une fois de plus il va falloir mettre en lignes ce qui est correspond aux colonnes language_name_english, language_name_french, ..., etc. A défaut, si un jour il faut par exemple ajouter une colonne language_name_portuguese, ça impactera les requêtes dans lesquelles la table est partie prenante, d’où un travail de vérification minutieux dont on se passerait volontiers...


Cela dit, on observera que le diagramme a pas mal évolué au fil du temps...