Discussion :

[safyne]

Bonjour à tous,

Je travaille actuellement sur la conception d'une application web de vente de véhicules d'occasion et j'aimerais obtenir vos avis sur mon Modèle Conceptuel de Données (MCD).


Voici quelques explications pour certaines entités :

Contact : représente les clients qui peuvent contacter le vendeur via un formulaire de contact s'ils sont intéressés par un véhicule spécifique.
Equipements : inclut les équipements standards des véhicules.
Transmission : correspond au type de boîte de vitesses (automatique, manuelle).
Catégorie : définit les types de véhicules (berline, SUV, etc.).
Statut : indique si un véhicule est vendu, disponible, etc.

J'ai externalisé plusieurs attributs en entités séparées pour permettre un filtrage efficace lors de la recherche de véhicules (par exemple, par catégorie, carburant, couleur, etc.). Je me demande cependant si cette approche n'a pas conduit à une surabondance d'entités et si le modèle est trop complexe. Cette externalisation est-elle justifiée par le besoin de filtrage ou devrais-je simplifier le modèle ?


Je souhaite m'assurer que mon MCD est bien structuré et optimisé pour les fonctionnalités souhaitées, en particulier le filtrage. Vos avis et suggestions seraient grandement appréciés.

Merci d'avance pour votre aide !

[escartefigue]

Bonjour safyne

Avec cette modélisation, il faut décrire la motorisation, la transmission et la catégorie autant de fois que vous avez de véhicules du même modèle.
Il serait plus judicieux d'associer ces caractéristiques au modèle.
Dans le même ordre d'idée, le carburant devrait être lié à la motorisation et non pas au véhicule : un même moteur peut équiper plusieurs modèles (y compris de marques différentes : les moteurs Peugeot équipent de nombreux modèles Citroën).
Pour les véhicules d'occasion, il est intéressant de mentionner s'il s'agit ou non d'une première main.

Sinon, l'usage est de nommer les types d'entités au singulier : [MODELE] plutôt que [MODELES], [VEHICULE] plutôt que [VEHICULES] etc.
Également, si vous conservez les noms conceptuels comme noms d'objets SQL, alors évitez les accents, ça vous simplifiera la vie en évitant d'avoir à ajouter des délimiteurs autour des noms.
Pour les noms d'associations, surtout celles qui deviendront des tables, préférez un verbe à l'infinitif, ça simplifiera la nomenclature : (DOTER) plutôt que (EST DOTE), (EQUIPER) plutôt que (EST EQUIPE), etc.

Voyez dans ce fil de discussion, réponse 7, un MCD qui pourra vous aider pour ce qui concerne les marques, modèles, variantes, motorisations, carburants, transmissions et exemplaires (l'exemplaire est le véhicule, chez vous porteur d'une immatriculation)

[safyne]

Bonjour escartefigue,

Merci beaucoup pour votre réponse et vos précieux conseils. J'ai intégré vos recommandations dans la modélisation de mon application. J'ai notamment associé les caractéristiques telles que la motorisation, la transmission et la catégorie directement au modèle, ce qui permet d'éviter les répétitions. De plus, le carburant( entité rebaptisé energie) est désormais lié à la motorisation.

Toutefois, je n'ai pas suivi la suggestion de relier le moteur à la marque comme mentionné dans le MCD du fil de discussion que vous avez référencé. Je n'ai pas poussé la modélisation à ce niveau de détail, peut-être à tort. Je comprends que certains constructeurs automobiles proposent des modèles dont le moteur et la boîte de vitesses sont fournis par d'autres constructeurs.

J'ai ajouté d'autres attributs tels que nbrePlaces et nbrePortes dans l'entité Modele, ainsi que rejetCO2, puissanceFiscale, puissanceReelle, nbreCylindres,consommationVille, et consommationAutoroute dans l'entité Motorisation.

[escartefigue]

C'est mieux

La consommation ne saurait être un attribut du moteur : le même moteur installé dans une Clio ne pesant que 1200 kg ou dans un gros monospace de 1700 kg n'a évidemment pas le même consommation.
C'est donc un attribut du modèle, du moins à vitesse stabilisée bien sûr, car ça dépend aussi de la conduite .

Selon votre MCD on sait à quel modèle appartient le véhicule, mais on ne sait pas quelle est sa finition.
Il faut donc ajouter une association entre modèle et finition en ajoutant une contrainte d'inclusion entre cette nouvelle association et l'association (proposer) pour vérifier qu'on associe un véhicule à une finition correspondant au modèle.

[safyne]

Je ne suis pas certain de bien comprendre la contrainte d'inclusion, car c'est un concept nouveau pour moi . Pourquoi la nouvelle association (appartenir) doit-elle être entre Modele et Finition, plutôt qu'entre Vehicule et Finition ? Pourriez-vous fournir plus d'explications, s'il vous plaît ? Par ailleurs, comment cette contrainte se matérialise-t-elle dans le modèle logique de données (MLD) et comment l'implémenter en SQL ? Merci

[fsmrel]

Bonsoir,

Je ne suis pas certain de bien comprendre la contrainte d'inclusion, car c'est un concept nouveau pour moi .

 
Pour bien comprendre, il existe fondamentalement l’ouvrage remarquable de D. Nanci et B. Espinasse Ingénierie des systèmes d'information - Merise deuxième génération, c’est l’ouvrage de référence. Le chapitre à étudier est le chapitre 7 (« IID. chapitre 7 Modélisation logique des données ») ; voyez par exemple la figure 7.33 (paragraphe II-D-3-r-v. Inclusion de participations d'une entité à plusieurs relations).

[escartefigue]

Pardon Safyne, j'aurais du me relire, car je vous ai induit en erreur :

Selon votre MCD on sait à quel modèle appartient le véhicule, mais on ne sait pas quelle est sa finition.
Il faut donc ajouter une association entre modèle et finition entre véhicule et finition en ajoutant une contrainte d'inclusion entre cette nouvelle association et l'association (proposer) pour vérifier qu'on associe un véhicule à une finition correspondant au modèle.

Là je n'ai pas looping sous la main ni d'autre outil de modélisation, du coup voici un MCD créé sous Visio, j'espère qu'il est correct, car évidemment, avec un outil de dessin, c'est sans contrôle.



J'en profite pour noter qu'une finition ne devrait correspondre qu'à un et un seul modèle, elle pourrait même être une entité-type faible du modèle et donc identifiée relativement au modèle.
C'est pourquoi j'ai modifié les cardinalité de l'association entre modèle et finition dans mon MCD : 1,1(R) coté (finition).

[safyne]

Bonjour Escartefigue,
Un grand merci pour le temps que vous avez pris pour clarifier les détails autour de mon MCD et pour les recommandations pertinentes que vous avez partagées. Les ajustements que j’ai effectués grâce à vos conseils sont reflétés dans le MCD mis à jour que je joins ici.

Je tiens également à exprimer ma gratitude pour ce forum et pour tous ceux qui y participent activement. Votre volonté de venir en aide et de partager votre expertise fait de cet espace une ressource inestimable.

[escartefigue]

Bonjour,

Les vendeurs et les contacts sont des personnes partageant les mêmes attributs, aussi, on peut fusionner ces deux types d'entité et établir les deux associations (annoncer) et (interesser) depuis ce nouveau type fusionné, appelons le [personne].
Ça évitera les redondances si une personne ayant publié une annonce est intéressée par une autre annonce.
Par contre, il faudra contrôler que la personne qui publie n'est pas la même que celle intéressée par une annonce, il faudra donc ajouter une contrainte à cet effet, qui au stade SQL deviendra un trigger ou une contrainte check associée à une fonction UDF.

Voici un extrait du MCD correspondant :




Et le script DDL correspondant, décliné pour SQL server :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
CREATE TABLE MA_marque(
   MA_ident INT IDENTITY,
   MA_code CHAR(6) NOT NULL,
   MA_nom VARCHAR(128) NOT NULL,
   PRIMARY KEY(MA_ident),
   UNIQUE(MA_code)
);
 
CREATE TABLE PE_personne(
   PE_ident INT IDENTITY,
   PE_nom VARCHAR(50) NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(PE_ident)
);
 
CREATE TABLE MD_modele(
   MD_ident INT IDENTITY,
   MD_nom VARCHAR(50) NOT NULL,
   MA_ident INT NOT NULL,
   PRIMARY KEY(MD_ident),
   FOREIGN KEY(MA_ident) REFERENCES MA_marque(MA_ident)
);
 
CREATE TABLE FI_finition(
   MD_ident INT,
   FI_seqn SMALLINT,
   FI_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(MD_ident, FI_seqn),
   FOREIGN KEY(MD_ident) REFERENCES MD_modele(MD_ident)
);
 
CREATE TABLE VH_vehicule(
   VH_ident INT IDENTITY,
   VH_immat CHAR(10),
   PE_ident INT NOT NULL,
   MD_ident INT NOT NULL,
   FI_seqn SMALLINT NOT NULL,
   MD_ident_1 INT NOT NULL,
   PRIMARY KEY(VH_ident),
   UNIQUE(VH_immat),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident),
   FOREIGN KEY(MD_ident, FI_seqn) REFERENCES FI_finition(MD_ident, FI_seqn),
   FOREIGN KEY(MD_ident_1) REFERENCES MD_modele(MD_ident)
);
 
CREATE TABLE IN_interesser(
   VH_ident INT,
   PE_ident INT,
   PRIMARY KEY(VH_ident, PE_ident),
   FOREIGN KEY(VH_ident) REFERENCES VH_vehicule(VH_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
alter table VH_vehicule
   add constraint VHKF01MD
   foreign key (MD_ident, FI_seqn)
   references FI_finition(MD_ident, FI_seqn)
;

À noter : les photos sont très probablement stockées en dehors de la base de données, et donc gérées par l'OS et non pas par le SGBD lui même.

Ce faisant, il y a un risque de destruction de photos liées à des véhicules, de photos déplacées dans d'autres répertoires, de photos renommées...
Pour éviter ce genre de mésaventures, il faut utiliser un SGBD qui permet de sécuriser les objets hors BDD, SQL server le permet grâce à File Stream qui permet d'autoriser ou non l'OS à modifier (supprimer, renommer, déplacer) certains fichiers. Oracle propose aussi une solution, mais moins complète, à l'inverse MariaDB et MySQL ne le proposent pas.
Ce genre de choses peut être essentiel pour un site d'annonces