Discussion :

[NGMAROON]

Bonjour j'ai un projet qui consiste à automatiser la gestion de voitures dans une entreprise.
Cahier de charges:
Une entreprise de vente automobile souhaite se procurer une application qui automatise la gestion du catalogue des voitures présentées à la vente. Ces voitures peuvent être neuves ou d’occasion. Toute voiture est caractérisée par un numéro, un modèle d’une marque donnée, un prix, une couleur, le type de carburant, la date de sa mise en vente. Elle intègre des options dont le prix est déjà inclus dans celui de la voiture. Pour toute voiture d’occasion, on doit préciser le kilométrage parcouru et l’année de sa construction. Quant aux voitures neuves, on peut leur ajouter des options, parmi celles offertes par le vendeur. Chaque option a un prix, qui s’ajoute au prix de la voiture.
L’application à développer doit permettre au vendeur de gérer les voitures, les modèles et les options, et à l’internaute de chercher une voiture en lui proposant plusieurs critères de recherche et de passer une commande en précisant la (ou les) voiture(s) choisie(s) et éventuellement les options demandées de chacune d’elles. L’internaute peut également demander un rendez-vous pour tester la voiture si elle est d’occasion.

Voici mon mcd :


je suis ouvert à toutes les critiques.

[fsmrel]

Bonsoir NGMAROON,

Bon début. A priori, votre MCD n’a pas l’air mal. Vous présentez votre sujet, ce sur quoi les utilisateurs du forum schéma font trop souvent l’impasse, vous méritez donc un gros pouce vert...

Vous avez quand même confondu MCD et MLD : votre entité-type MODELE est porteuse d’un attribut id_marque : il doit disparaître. C’est l’AGL qui se chargera de le faire figurer dans l’en-tête de la table MODELE issue de l’entité-type MODELE lors de la génération du MLD : id_marque sera alors un attribut de cette table et composera la clé étrangère faisant référence à la clé primaire {id_marque} de la table MARQUE issue de l’entité-type MARQUE lors de la génération du MLD. Si vous conserviez l’attribut id_marque dans l’en-tête de l’entité-type MODELE, alors vous l’auriez en double dans la table générée (l’AGL nommant évidemment autrement l’attribut généré par lui et l’affectant du type INT).

Toutes choses égales, cette remarque vaut pour les attributs id_voiture (entité-type COMMANDE), id_modele, id_option (entité-type VOITURE). Entre parenthèses, la présence d’id_option signifie qu’une voiture a au plus une option...

Après génération du MLD, c’est la table CONSTITUER qui sera porteuse de la paire d’attributs {id_voiture, id_option}.

Que cache « plusieurs liens » ? Merci de bien préciser les règles de gestion des données correspondantes, pour qu’on puisse dénouer tout ça...

A quoi correspond exactement l’attribut PRIX dans l’association EST_MODELE ? (en passant, nom d’association à changer, car EST_MODELE fait accroire qu’une voiture est un modèle...)

Evitez les nombres en virgule flottante, passez à la virgule fixe si c’es nécessaire (cas de la TVA par exemple), et au type INTEGER pour les nombres entiers (kilométrage, prix...)

Evitez le type BLOB (cf. mot de passe).

Quelle version de JMerise utilisez-vous ?

[CinePhil]

En plus des remarques toujours pertinentes du grand expert fsmrel, j'en ajouterai quelques autres...

Toute voiture est caractérisée par un numéro, un modèle d’une marque donnée, un prix, une couleur, le type de carburant, la date de sa mise en vente.

1) Vous aurez probablement plusieurs fois la même couleur et le même carburant. Vous devriez donc externaliser la couleur et le carburant dans des entités-types de référence, selon ces règles de gestion :
R1 : Une voiture est peinte d'une couleur et une couleur peut peindre plusieurs voitures.
R2 : Une voiture utilise un carburant et un carburant peut être utilisé par plusieurs voitures.

MCD :
voiture -1,1----peindre----0,n- couleur
|----------1,1----utiliser----0,n- carburant

Ainsi, au lieu d'écrire dans votre table voiture X fois la couleur "Anthracite" (10 caractères, soit 11 octets au moins en VARCHAR chez MySQL par exemple), vous ne l'écrirez qu'une fois pour toutes dans la table des couleurs et la table voiture ne contiendra qu'une clé étrangère de type entier (4 octets ou moins parce que vous pourrez choisir un SMALLINT de 2 octets si vous avez moins de 32767 couleurs) référençant l'identifiant de la couleur.

2) Vues les propriétés de votre entité-type voiture, si vous devez enregistrer 2 voitures identiques, vous ne saurez pas les distinguer. L'id_voiture auto-incrémenté étant un identifiant technique sans signification réservé à la base de données, je pense que, lorsque le cahier des charge dit que "Toute voiture est caractérisée par un numéro", il s'agit d'un numéro déterminé selon une certaine règle. Il peut s'agir du numéro de série de la voiture ou d'un numéro de gestion genre "2018-0054" pour la 54ème voiture de l'année 2018. Ceci est à faire préciser par celui qui a établi le cahier des charges mais ce qu'on peut dire est que vous avez oublié ce numéro signifiant dans votre modèle. Il sera probablement de type CHAR ou VARCHAR et d'une longueur à déterminer.

Elle intègre des options dont le prix est déjà inclus dans celui de la voiture.

3) Pourquoi avoir choisi le verbe "constituer" dans votre MCD pour l'association entre voiture et option alors que c'est le verbe "intégrer" qui figure dans les exigences ?
Un MCD doit pouvoir se lire comme une série de phrases et donc coller au plus près des exigences spécifiées.

Pour toute voiture d’occasion, on doit préciser le kilométrage parcouru et l’année de sa construction.

4) Votre texte opère à partir de cette phrase un distinguo entre les voitures neuves et celles d'occasion. Il existe des propriétés spécifiques aux voitures d'occasion (kilométrage et année de construction) qui ne sont pas exigées (car peut-être jugées non pertinentes) pour les voitures neuves, même si elles peuvent être connues et donc enregistrables pour ces dernières.
En toute rigueur, il conviendrait donc de faire un héritage, selon ces règles de gestion :
R3: Une voiture neuve est une voiture et une voiture peut être une voiture neuve.
R4: Une voiture d'occasion est une voiture et une voiture peut être une voiture d'occasion.

MCD :
voiture_neuve -(1,1)----être----0,1- voiture
voiture_occasion -(1,1)----être----0,1---|

Les cardinalités entre parenthèses signifient que les entités voiture_neuve et voiture_occasion n'ont pas d'identifiant propre. Les tables qui en découlent auront leur clé primaire qui sera également une clé étrangère référençant l'identifiant de la voiture.

Conformément au texte des exigences, les propriétés km et date_construct seront déplacées de voiture vers voiture_occasion.

Toute voiture est caractérisée... Elle intègre des options dont le prix est déjà inclus dans celui de la voiture.
...
Quant aux voitures neuves, on peut leur ajouter des options, parmi celles offertes par le vendeur. Chaque option a un prix, qui s’ajoute au prix de la voiture.

5) Il y a là une ambiguïté qu'il faudrait clarifier !
Faut-il enregistrer les options de toutes les voitures ou seulement celles qu'on ajoute aux voitures neuves ?
Surtout que ça a une incidence sur le prix !

L’internaute peut également demander un rendez-vous pour tester la voiture si elle est d’occasion.

6) Vous n'avez pas traité complètement cette partie dans votre MCD.
Vous avez indiqué une date de rendez-vous mais on parle ici d'une demande de rendez-vous dont la date n'est pas connue puisqu'elle doit être compatible entre le client et le vendeur.
Je vous laisse réfléchir à la manière de modéliser cela...

gestion du catalogue des voitures présentées à la vente.

7) Pour les voitures neuves, j'imagine que ce catalogue ne mentionnera pas chaque voiture du modèle M1, carburant Ca1 et couleur Co2 proposé à la vente mais seulement le modèle M1, carburant Ca1 et couleur Co2. L'entreprise se chargeant de commander la voiture souhaitée au constructeur si elle n'est pas disponible sur son stock.
Vous pouvez vous faire préciser ce point qui peut entraîner des modifications lourdes sur votre MCD.


Autre point non lié au texte des exigences :
8) De la même manière que la voiture aura probablement un numéro de gestion signifiant pour les humains qui gèreront les ventes de voitures, je pense que la commande aura aussi un numéro signifiant de gestion qui ne sera pas l'identifiant de la commande en base de données.

[NGMAROON]

Bonsoir NGMAROON,

Bon début. A priori, votre MCD n’a pas l’air mal. Vous présentez votre sujet, ce sur quoi les utilisateurs du forum schéma font trop souvent l’impasse, vous méritez donc un gros pouce vert...

Vous avez quand même confondu MCD et MLD : votre entité-type MODELE est porteuse d’un attribut id_marque : il doit disparaître. C’est l’AGL qui se chargera de le faire figurer dans l’en-tête de la table MODELE issue de l’entité-type MODELE lors de la génération du MLD : id_marque sera alors un attribut de cette table et composera la clé étrangère faisant référence à la clé primaire {id_marque} de la table MARQUE issue de l’entité-type MARQUE lors de la génération du MLD. Si vous conserviez l’attribut id_marque dans l’en-tête de l’entité-type MODELE, alors vous l’auriez en double dans la table générée (l’AGL nommant évidemment autrement l’attribut généré par lui et l’affectant du type INT).

Toutes choses égales, cette remarque vaut pour les attributs id_voiture (entité-type COMMANDE), id_modele, id_option (entité-type VOITURE). Entre parenthèses, la présence d’id_option signifie qu’une voiture a au plus une option...

Après génération du MLD, c’est la table CONSTITUER qui sera porteuse de la paire d’attributs {id_voiture, id_option}.

Que cache « plusieurs liens » ? Merci de bien préciser les règles de gestion des données correspondantes, pour qu’on puisse dénouer tout ça...

A quoi correspond exactement l’attribut PRIX dans l’association EST_MODELE ? (en passant, nom d’association à changer, car EST_MODELE fait accroire qu’une voiture est un modèle...)

Evitez les nombres en virgule flottante, passez à la virgule fixe si c’es nécessaire (cas de la TVA par exemple), et au type INTEGER pour les nombres entiers (kilométrage, prix...)

Evitez le type BLOB (cf. mot de passe).

Quelle version de JMerise utilisez-vous ?

-j'utilise la version 0.5 de JMerise.
-le prix dans l'association est_modele est le prix du modèle qui est affecter directement à la voiture , bon je crois que je vais l'enlever.
-Le type varchar peut-il faire l'affaire pour le mot de passe?
-je comprends pas trop ce que vous dites par <<Merci de bien préciser les règles de gestion des données correspondantes, pour qu’on puisse dénouer tout ça...>>.

[NGMAROON]

2) Vues les propriétés de votre entité-type voiture, si vous devez enregistrer 2 voitures identiques, vous ne saurez pas les distinguer. L'id_voiture auto-incrémenté étant un identifiant technique sans signification réservé à la base de données, je pense que, lorsque le cahier des charge dit que "Toute voiture est caractérisée par un numéro", il s'agit d'un numéro déterminé selon une certaine règle. Il peut s'agir du numéro de série de la voiture ou d'un numéro de gestion genre "2018-0054" pour la 54ème voiture de l'année 2018. Ceci est à faire préciser par celui qui a établi le cahier des charges mais ce qu'on peut dire est que vous avez oublié ce numéro signifiant dans votre modèle. Il sera probablement de type CHAR ou VARCHAR et d'une longueur à déterminer.

Vous avez raison, c'est plus pratique avec les numéros de séries.

3) Pourquoi avoir choisi le verbe "constituer" dans votre MCD pour l'association entre voiture et option alors que c'est le verbe "intégrer" qui figure dans les exigences ?
Un MCD doit pouvoir se lire comme une série de phrases et donc coller au plus près des exigences spécifiées.

J'ai mis constituer parce que vus le cahier de charge les voitures d'occasions peuvent aussi avoir des options me^me si ont peut pas les en ajouter.

4) Votre texte opère à partir de cette phrase un distinguo entre les voitures neuves et celles d'occasion. Il existe des propriétés spécifiques aux voitures d'occasion (kilométrage et année de construction) qui ne sont pas exigées (car peut-être jugées non pertinentes) pour les voitures neuves, même si elles peuvent être connues et donc enregistrables pour ces dernières.
En toute rigueur, il conviendrait donc de faire un héritage, selon ces règles de gestion :
R3: Une voiture neuve est une voiture et une voiture peut être une voiture neuve.
R4: Une voiture d'occasion est une voiture et une voiture peut être une voiture d'occasion.

MCD :
voiture_neuve -(1,1)----être----0,1- voiture
voiture_occasion -(1,1)----être----0,1---|

Les cardinalités entre parenthèses signifient que les entités voiture_neuve et voiture_occasion n'ont pas d'identifiant propre. Les tables qui en découlent auront leur clé primaire qui sera également une clé étrangère référençant l'identifiant de la voiture.
Conformément au texte des exigences, les propriétés km et date_construct seront déplacées de voiture vers voiture_occasion.

je pensais qu'avoir une seule entité de type voiture était la meilleure solution car il suffit juste de mettre à nul certains attributs et le tour est joué.

5) Il y a là une ambiguïté qu'il faudrait clarifier !
Faut-il enregistrer les options de toutes les voitures ou seulement celles qu'on ajoute aux voitures neuves ?
Surtout que ça a une incidence sur le prix !

je suis parti sur le fait qu'une voiture peut avoir des options à la base mais qu'on peut en intégrer d'autres.

6) Vous n'avez pas traité complètement cette partie dans votre MCD.
Vous avez indiqué une date de rendez-vous mais on parle ici d'une demande de rendez-vous dont la date n'est pas connue puisqu'elle doit être compatible entre le client et le vendeur.
Je vous laisse réfléchir à la manière de modéliser cela...

Ici si une voiture est neuve ou si le client n'a pas pris de rendez-vous pour une voiture d'occasion alors la date de rendez-vous est à nul et le commentaire indique ''pas de rendez-vous''.

7) Pour les voitures neuves, j'imagine que ce catalogue ne mentionnera pas chaque voiture du modèle M1, carburant Ca1 et couleur Co2 proposé à la vente mais seulement le modèle M1, carburant Ca1 et couleur Co2. L'entreprise se chargeant de commander la voiture souhaitée au constructeur si elle n'est pas disponible sur son stock.
Vous pouvez vous faire préciser ce point qui peut entraîner des modifications lourdes sur votre MCD.

Cette partie n'est pas pris en compte, je crois bien que je vais la mettre dans mon cahier de charges.


mes réponses sont en rouges.

[NGMAROON]

Bonsoir NGMAROON,

Que cache « plusieurs liens » ? Merci de bien préciser les règles de gestion des données correspondantes, pour qu’on puisse dénouer tout ça...

j'avais oublier <<plusieurs liens >> est juste une erreur de frappe.

[CinePhil]

J'ai mis constituer parce que vus le cahier de charge les voitures d'occasions peuvent aussi avoir des options me^me si ont peut pas les en ajouter.

On peut dire "équiper" mais qu'une option constitue une voiture, je trouve ça bizarre ! Mais ce n'est pas très important.

je suis parti sur le fait qu'une voiture peut avoir des options à la base mais qu'on peut en intégrer d'autres.

Par contre, il faut vraiment clarifier cette histoire d'options !
Si je cherche une voiture d'occasion, ça peut autant m'intéresser de savoir qu'elle a un GPS intégré que si c'est une voiture neuve ! Par contre, effectivement, je ne vais pas demander au vendeur d'ajouter un GPS s'il n'y en a pas sur la voiture d'occasion disponible !

je pensais qu'avoir une seule entité de type voiture était la meilleure solution car il suffit juste de mettre à nul certains attributs et le tour est joué.

fsmrel va vous tomber dessus avec sa sulfateuse à NULL !
Le bonhomme NULL est un cancer qu'il faut éradiquer de vos tables !

Ici si une voiture est neuve ou si le client n'a pas pris de rendez-vous pour une voiture d'occasion alors la date de rendez-vous est à nul et le commentaire indique ''pas de rendez-vous''.

Idem ci-dessus pour le NULL. Et c'est peu productif d'écrire x (milliers de fois) "Pas de rendez-vous" dans la colonne commentaire !
Il vaut mieux une propriété booléenne demandeRdv, par défaut à FALSE. Avec ça on peut ensuite gérer les rendez-vous et si on veut le faire informatiquement, une date dans cette table n'est pas suffisante. Rendez-vous avec quel vendeur ? Jours et heures de disponibilité ?...

Cette partie n'est pas pris en compte, je crois bien que je vais la mettre dans mon cahier de charges.

Ah c'est vous qui faites le cahier des charges ?
Vous mentionnez être étudiant et je pensais qu'il s'agissait soit d'un exercice scolaire soit un travail de stagiaire.
Si vous n'êtes pas vous-même le client final de cette application, faites vous préciser quand même les points à clarifier par votre donneur d'ordre !

[NGMAROON]

Voici quelques modifications effectuées sur mon mcd :

[CinePhil]

1) Pourquoi encore cette mention "plusieurs liens" qui traîne sur le MCD ?

2) Je dirais qu'une commande peut comprendre plusieurs voitures et qu'une voiture peut être comprise dans une commande... mais c'est pas grave.

3) Plus important, il n'y a toujours pas de numéro de voiture. Et comme votre association Constituer a des cardinalités 0,n, 0,n, votre entité-type ne représente plus une voiture physique mais un ensemble {modèle, carburant, couleur, liste d'options} qui peut être vendue plusieurs fois.
On peut aussi s'étonner au passage qu'une commande puisse comprendre zéro voiture !

4) Je constate que vous n'avez pas tenu compte de mes remarques sur la demande de rendez-vous et l'éventuelle gestion d'un calendrier de rendez-vous qui nécessiterait un peu plus qu'une simple date de rendez-vous dans la table commande !


Bref, c'est mieux sur certains points mais moins bien sur d'autres et ça n'a pas tout résolu.

[rabDev]

Bonjour à toute et à tous,
La mention "plusieurs liens" apparait lorsque vous avez deux pattes (deux liens) superposées avec les mêmes cardinalités et qui relient une entité type et une relation type.
donc, NGMAROON, vérifiez si vous voulez bien laisser ces deux liens entre (voiture et constituer ) ou il faut supprimer un lien ..... (ça aura un impact sur la génération du script SQL).

Bonne journée à toutes et à tous