Discussion :

[voxben]

Bonjour,
ci joint un exo que j'essaie de resoudre,
mon MCD me parait juste...
par contre je plante concernant les propriétés date_fin et montant_contrat
pour moi ce sont des propriétés calculées :
date_fin = date_debut + durée
montant_contrat = (prix_journalier de la table type_vehicule ) * (duree de la table type_duree) + (prime de la table type_vehicule)

j'imagine bien les calcules se faire en SQL au niveau de la base de donnée ou au niveau d'un logiciel avec un language quelconque
par contre je n'arrive pas a les exprimer au niveau du MCD.

la question 3 (qui n'en est pas une) me parrait bizarre.

Merci.

[escartefigue]

Bonjour,

Concernant le 1er point, en effet, un période peut s'exprimer de deux façons

• soit d'une date de début à une date de fin
• soit à partir d'une date de début et pour une durée, avec éventuellement une unité de mesure de la durée si elle peut varier (en jours, mois...)

Mais il ne faut pas avoir à la fois une date de fin et une durée, car c'est un risque d'incohérence.

Par ailleurs, l'énoncé est bourré de fautes de français, le rédacteur aurait quand même pu se relire .

Enfin, concernant le MCD

• il n'est a priori pas utile de créer une entité-type [TYPE_DUREE], il suffit d'avoir soit un attribut "durée" soit un attribut "date de fin" dans l'entité-type [CONTRAT]
• à l'inverse le type de contrat devrait être externalisé dans une entité-type spécifique qui sera en relation avec le contrat :
  [CONTRAT] 1,1 --- (typer) --- 0,n [TYPE_CONTRAT]
• l'adresse ne peut pas être un attribut unique, il faut la structurer selon la norme de la poste, norme que l'on peut trouver gratuitement sur la toile.
  sachant qu'une même ville pouvant participer à plusieurs adresses, il faudra créer une entité-type [VILLE] en relation avec l'adresse
• une même marque peut correspondre à un grand nombre de véhicules, il faut donc modéliser une entité-type [MARQUE] en relation avec l'entité-type [VEHICULE]
• la phrase de l'énoncé "un assuré peut établir un ou plusieurs contrats selon les véhicules qui lui'il possède" signifie très probablement que l'assuré peut avoir plusieurs véhicules, mais que chaque véhicule ne fait l'objet que d'au plus un contrat. Les cardinalités sont donc [CONTRAT] 1,1 --- (concerner) --- 0,1 [VEHICULE]

[voxben]

Merci pour votre reponse.

precision cependant pour

[CONTRAT] 1,1 --- (concerner) --- 0,1 [VEHICULE]

comment un VEHICULE peut ne pas avoir de CONTRAT
si on considere le point de vue coté assureur,
j'aurais tendance a y voir un 1,1 au lieu de 0,1

[Paprick]

Bonsoir,

Si un véhicule possède un et un seul contrat et qu'un contrat concerne 1 et 1 seul véhicule, alors les classes d'entités véhicule et contrat doivent être regroupées en une seule classe d'entité.
Ainsi les rubriques du véhicule viennent compléter la classe contrat.
Mais je pense plutôt qu'un véhicule peut avoir plusieurs contrats avec des dates d'effet différentes.

Bonne continuation !

[voxben]

au vu de vos suggestions mon mcd devient comme suit :
Merci

[escartefigue]

Bonjour Voxben

Si comme le suggérait Paprick, un véhicule peut posséder plusieurs contrats, alors les cardinalités sont à revoir.
Autre interprétation possible de l'énoncé (qui décidément est peu clair), c'est qu'il faille prévoir des contrats de type "flotte", ce qui est courant pour les entreprises : un même contrat couvre alors plusieurs véhicules.
Et dans votre modèle, un assuré peut établir un contrat pour un véhicule qu'il ne possède pas, pourquoi pas, mais ce n'est pas précisé dans l'énoncé.


Dans l'entité-type véhicule, si "matricule" est l'immatriculation, alors c'est un mauvais choix d'identifiant : l'immatriculation est issue d'une nomenclature externe, à ce titre, elle est susceptible de changer. Or, un identifiant doit être stable, car il se propage au travers des contraintes dans les tables liées.
D'ailleurs, les anciennes immatriculations changeaient à chaque changement de propriétaire du véhicule, et il en reste encore en circulation.
Il faut donc choisir un identifiant technique c'est à dire un type compteur dans looping, qui se traduira par un identity (DB2, SQL Server), auto_increment (MySQL), serial (Postgre) ou number (Oracle).


Les cardinalités entre adresse et ville sont inversées : une adresse ne correspond qu'à une seule ville, à l'inverse, une ville peut concerner plusieurs adresses.

Point de détail : de "marque" vers "appartenir" je préfère une cardinalité minimale de zéro plutôt que un. En effet, "marque" est un référentiel externe, on chargera probablement toutes les marques dans la table issue de l'entité-type, et on doit pouvoir enregistrer une marque, même si aucun véhicule à un instant "t" n'est rattaché à cette marque.

[voxben]

Bonjour,

Je constate que l'énoncé en effet peut donner lieu à différentes interprétations, cela compliqué inutilement ma démarche d'apprentissage.

Mon but final étant de réaliser une base de données pour mon activité réelle, je crois qu'il est temps d'exposer ma problématique en postant directement mon "cahier des charges"...

Encore merci pour vos efforts.

[escartefigue]

C'est souvent le cas dans la vie professionnelle : l'expression de besoin qui semble claire pour son rédacteur, l'est beaucoup moins pour celui qui la prend en charge, et il est nécessaire de faire plusieurs allers et retours entre la MOA et la MOE pour s'assurer d'avoir bien compris ce qu'il en est.

Pensez à marquer le sujet à "résolu" avec le bouton prévu à cet effet si c'est bien le cas.

Vous pouvez aussi voter pour les réponses qui vous ont aidé en cliquant sur le pouce vert .