Discussion :

[mezoo]

Bonjour

je recherche à réaliser le MCD d'un cabinet de courtage en assurance avant de créer la la base de données.
J'ai trouvé un peu partout des bribes de schéma.
J'en cherche d'un peu plus complet.
Je me pose notament la question, faut il faire une simple entité assuré ou bien faut il crée un entité souscripteur lié à une autre entité assuré par l'entité "contrat" ?

Merci

[JPhi33]

Bonjour mezoo,

On ne peut pas obtenir un MCD à partir de rien. Un modèle est l'abstraction d'une réalité. Sans la description de cette réalité, tu ne peux rien faire.

La description est généralement consignée dans un cahier des charges mais ce peut être aussi un énoncé d'exercice, des notes prises lors d'interviews dans une entreprise, etc.

Je me pose notament la question, faut il faire une simple entité assuré ou bien faut il crée un entité souscripteur lié à une autre entité assuré par l'entité "contrat" ?

Oui dans certains cas, non dans d'autres cas. La réponse à cette question se trouve en analysant le cahier des charges...

[mezoo]

Voici en pièce jointes ce que j'ai pu faire d'après ce que j'ai récolté (je n'ai pas de cahier des charges), mais c'est le fonctionnement type d'un contrat d'assurance.

Sauriez vous me dire s'il y a des incohérences flagrantes ?

D'autre part, je n'ai pas intégré d'entité prospect, que pouvez vous me suggérer ?
En fait un client peu venir faire un devis (qu'il acceptera ou non), on veut quand même garder ces infos alors qu'il n'a pas souscrit (pour prospection)

De plus les contrats peuvent porter sur autre chose que des véhicule (habitation, crédit, vie, mutuelle, ...) comment le modélise t on ds ce schéma ?
Dernière chose, chose dans le cadre d'un mutuelle comment précise t on que le souscripteur assure également ces enfants et/ou son conjoint ?

Merci d'avance

[JPhi33]

Bonjour,

Avec un schéma, c'est un peu plus clair.

Sauriez vous me dire s'il y a des incohérences flagrantes ?

L'association Modifier entre Contrat et Avenant est de type x,1 --- y,n. Une telle association ne doit pas contenir de donnée, on peut considérer cela comme une erreur de modélisation. Quand bien même, lors de la transformation en MLD, celles-ci "migreront" vers la table correspondant à l'entité côté 1,1 donc ici vers Avenant.

Idem pour l'association Modifier entre Utilisateur et Souscripteur.

La présence de l'entité Compagnie est surprenante. Que faut-il comprendre ? Qu'un contrat porte sur un produit fourni par une autre compagnie ? Pourquoi ?

D'autre part, je n'ai pas intégré d'entité prospect, que pouvez vous me suggérer ?
En fait un client peu venir faire un devis (qu'il acceptera ou non), on veut quand même garder ces infos alors qu'il n'a pas souscrit (pour prospection)

Quelles infos ? Celles du prospect uniquement (1) ou aussi celle des devis (2) ?

(1) Une entité généralisée, Personne par exemple, peut convenir :

Code :

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

1
2
3
4
[ Souscripteur ] ===> |          |
                      | Personne |
    [ Prospect ] ===> |          |

A lire comme suit : un Souscripteur est une Personne et un Prospect est une Personne. Toutes les informations (i.e. propriétés et associations) connues aussi bien pour des souscripteurs que pour des prospects sont rattachées à Personne. Les informations spécifiques à l'un ou l'autre ne sont rattachées qu'à l'une des deux entités. Exemples :
- si NSecu n'est pas requis pour un prospect, cette propriété doit faire partie de l'entité Souscripteur
- à l'inverse, si Nom et Prénom sont connus systématiquement dans le cas d'un prospect et dans le cas d'un Souscripteur, ces propriétés doivent faire partie de Personne.

C'est la même chose pour les associations :
- supposons que le RIB ne soit pas demandé aux prospects, alors l'association Appartenir (RIB) n'est liée qu'à Souscripteur
- par contre, si la situation familiale concerne aussi bien les prospects que les souscripteurs, alors l'association Situer (SituationFamiliale) doit être liée à Personne.


(2) Un devis est comme un contrat avec moins d'informations.

[mezoo]

Bonjour,

Déjà merci de l'intérêt porté à ma question

La présence de l'entité Compagnie est surprenante. Que faut-il comprendre ? Qu'un contrat porte sur un produit fourni par une autre compagnie ? Pourquoi ?

Oui il s'agit d'un courtier en assurance donc que les produits proposés ne sont pas les siens.

Quelles infos ? Celles du prospect uniquement (1) ou aussi celle des devis (2) ?

Je dirais les deux, on doit pouvoir savoir quel devis a été fait quand le prospect revient.

Idem pour l'association Modifier entre Utilisateur et Souscripteur

Une fiche de souscripteur peut être modifier par un utilisateur, je souhaiterais garder une trace des modifications, ce n'est pas de cette manière que celà doit être représenté ?

J'avais une idée pour l'entité Personne maintenant c'est bien clair, mais comment modélise t on qu'un prospect passe souscripteur ?

[JPhi33]

La suite...

Oui il s'agit d'un courtier en assurance donc que les produits proposés ne sont pas les siens.

Soit

Une fiche de souscripteur peut être modifier par un utilisateur, je souhaiterais garder une trace des modifications

Le MCD dit effectivement qu'un souscripteur peut être modifié par un ou plusieurs utilisateurs mais il dit aussi qu'un utilisateur doit modifier un seul Souscripteur et une seule fois... Est-ce bien ce qui doit être modélisé ? Si oui, alors DateEdition et Commentaire sont des propriétés de l'entité Utilisateur à cause de la cardinalité 1,1.

Au contraire, si un utilisateur peut modifier plusieurs souscripteurs, alors la modélisation doit être :

[ Utilisateur ]--0,n----( Modifier )----0,n--[ Souscripteur ]

Cette fois, les propriétés DateEdition et Commentaire peuvent faire partie de l'association. Mais attention, un utilisateur donné ne pourra modifier un souscripteur donné qu'une seule fois. A titre d'exercice, trouver comment faire pour qu'un utilisateur puisse modifier un même souscripteur plusieurs fois.

[...] mais comment modélise t on qu'un prospect passe souscripteur ?

Tout d'abord, il s'agit d'une transition du système (une action), cela ne concerne pas le modèle statique (le MCD), il n'y a donc pas de modélisation du MCD correspondant à cela. Pour répondre concrètement à la question, il n'y a pas de secret : il faut transférer l'occurrence Prospect concernée dans l'entité Souscripteur ce qui, en base de données, se traduit par un INSERT dans la table Souscripteur suivi d'un DELETE dans la table Prospect.


Autres remarques

L'entité Cylindrée semble bien mal nommée. Véhicule ne serait-il pas plus approprié ?

Les garanties du contrat devraient dépendre du produit sur lequel porte le contrat. C'est-à-dire qu'on ne devrait pas pouvoir rattacher une garantie à un contrat sans que celle-ci soit prévue dans le produit. Donc l'entité Produit devrait elle aussi être liée à l'entité Garantie.

[mezoo]

Au contraire, si un utilisateur peut modifier plusieurs souscripteurs

Effectivement c'est le plus logique.
Pour l'exercice, je dirais que l'association devrait être une entité "Modification" ?

L'entité Cylindrée semble bien mal nommée. Véhicule ne serait-il pas plus approprié ?

La aussi je m'en suis douté, c'est "véhicule" qui est plus approprié

Donc l'entité Produit devrait elle aussi être liée à l'entité Garantie.

J'imaginais que les franchises sont dépendantes du contrant mais c'est peu problable, elles sont sans doute liées au produit effectivement.

Pour répondre concrètement à la question, il n'y a pas de secret : il faut transférer l'occurrence Prospect concernée dans l'entité Souscripteur ce qui, en base de données, se traduit par un INSERT dans la table Souscripteur suivi d'un DELETE dans la table Prospect.

Ok, mais dans ca cas je perdrais les infos du devis ? d'ailleurs faut il en faire une entité "Devis" dont les données seront reporté ds l'entité "Contrat" ?

Merci encore, toutes ces infos me sont précieuses

[JPhi33]

Bonjour mezoo,

Pour l'exercice, je dirais que l'association devrait être une entité "Modification" ?

Tu réfléchis en termes de tables, pas en termes de modélisation conceptuelle...

La solution consiste à ajouter, à l'association Modification, une entité DateModification (à supposer qu'un utilisateur ne modifie un souscripteur qu'une fois par jour au maximum) ou DateHeureModification (ce qui autorise plusieurs modifications à la même date). A noter que cette entité est d'un type particulier que José MOREJON nomme "Propriété spatio-temporelle" (Merise : Vers une modélisation orientée objet, Les Editions d'Organisation, 1995) car elle ne contient que l'identifiant Date (ou DateHeure) et n'est pas nommée. Elle se représente comme ceci :

Code :

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

1
2
3
4
+-------------+
| DateEdition |
+-------------+

alors qu'une entité classique possède un nom :

Code :

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

1
2
3
4
5
6
+----------------+
|  Souscripteur  |
|----------------|
| idSouscripteur |
+----------------+

L'association Modifier se traduit effectivement en une table du MLD dont la clé est {id_Souscripteur, id_Utilisateur, DateEdition}. Une propriété spatio-temporelle ne donne pas lieu à une table du MLD.

J'imaginais que les franchises sont dépendantes du contrant mais c'est peu problable, elles sont sans doute liées au produit effectivement.

Au produit et au Contrat. L'association avec Produit donne la liste des garanties du produit, l'association avec Contrat donne la liste des garanties effectivement souscrites. Par exemple, un produit peut proposer les garanties Vol, Incendie, Bris de glace, Dommages et le souscripteur ne choisir que les garanties Vol et Incendie dans son contrat.

Ok, mais dans ca cas je perdrais les infos du devis ?

Oui, si le devis n'est lié qu'au prospect. Mais pourquoi un souscripteur ayant un contrat pour assurer une voiture ne pourrait-il pas demander un devis pour assurer une moto ?

d'ailleurs faut il en faire une entité "Devis" [...]

Devis n'est pas égal à Prospect, il faut distinguer ces deux groupes d'informations, donc une entité Devis s'impose. Pour qu'un devis soit aussi pertinent pour un prospect que pour un souscripteur, il faut associer l'entité Devis à l'entité Personne.

dont les données seront reporté ds l'entité "Contrat" ?

Reportées ou recopiées, cela dépend des règles de conservation des devis.

[mezoo]

J'ai oublié de te remercier pour toutes les infos,
J'ai corrigé selon tes remarques
Merci !