Modèle Logique de données

[Cisman]

Bonjour,

Voici un énoncé pour réaliser un modèle logique de base de données.

1. Propositions :

Un client possède un contrat d'assurance au seins de la compagnie d’assurance.

Chaque contrat est basé sur une formule (type de contrat) prévoyant une ou plusieurs garanties.

Un dossier de sinistre est associé à un seul contrat.

Un sinistre peut engendrer plusieurs interventions à des dates différentes.

Une intervention peut dans certains cas de figure (par ex un carambolage) couvrir plusieurs sinistres.

Chaque intervention est effectuée par un expert.

Chaque dossier de sinistre est géré par un correspondant joignable.


2. Concevoir avec visual paradigm le MLD en respectant les formes normales.


3. La liste de proposition n'est pas exhaustive, certains attributs doivent être déduits et ajoutés afin d'optimaliser la DB.


Et voici ce que j'ai fait. Qu'en pensez-vous?

[escartefigue]

Bonjour,

Quelques remarques rapidement :

règles de gestion
Elles sont malheureusement incomplètes, par exemple

Un client possède un contrat d'assurance au seins de la compagnie d’assurance.

La règle complète est-elle
R001 : un client possède un et un seul contrat d'assurance au sein de la compagnie d’assurance, c'est ce que vous avez modélisé

ou bien
R001 : un client possède au moins un contrat d'assurance au sein de la compagnie d’assurance

Il en va de même par exemple pour les formules et les garanties. Il est assez probable qu'une même garantie puisse être proposée dans plusieurs formules, mais vos règles de gestion ne permettent pas de le savoir et ce n'est pas ce que vous avez modélisé. A préciser.


Typage des attributs
Evitez le varchar(255) systématique, préférez du char si la longueur varie peu et reste modeste (en deça de 15-20 caractères), ou du varchar adapté au besoin si la longueur est plus importante et qu'elle change souvent.


Tables EXPERT, CLIENT et CORRESPONDANT
Ces personnes partagent l'essentiel de leurs attributs. Il est donc préférable d'utiliser l'héritage en modélisant une table "personne" qui possèdera tous les attributs communs aux experts, clients et correspondants (identifiant, nom, prénom...) et, si nécessaire, une table "expert", une table "client" et une table "correspondant" pour les attributs spécifiques à chaque sous-type.
Là aussi il convient de compléter les règles de gestion pour préciser si chaque sous-type est exclusif ou non (un client peut il être expert...)


Table INTERVENTION
l'identifiant du dossier de sinistre ne doit pas apparaitre ici puisqu'il peut y avoir plusieurs dossiers pour une même intervention, je vous cite :

Une intervention peut dans certains cas de figure (par ex un carambolage) couvrir plusieurs sinistres.

C'est donc bien votre table associative "Intervention_Dossier_Sinistre" qui permet de faire le lien entre l'intervention et le dossier sinistre.


Table CONTRAT
Que représentent les deux attributs "client_numero_national" et "client_numero_national2" ?


Respect des formes normales
Votre énoncé stipule :

2. Concevoir avec visual paradigm le MLD en respectant les formes normales.

C'est bien la moindre des choses, mais ce n'est pas le cas dans votre modèle qui viole la 2NF.
En effet, le numéro de téléphone et l'adresse courriel ne dépendent pas seulement de l'identifiant d'une personne mais également de l'identifiant du "type de média" (qui permet de savoir s'il s'agit d'un téléphone fixe domicile, fixe travail, portable privé, courriel pro, courriel privé etc...).
Une personne peut posséder zéro (c'est rare) à plusieurs téléphones et zéro à plusieurs adresses courriel.
Il convient donc de modéliser une table des média qui aura pour clef étrangère l'identifiant de la personne d'une part et l'identifiant du type de média d'autre part
Au niveau conceptuel : PERSONNE 0,n --- posseder --- (1,1) MEDIA 1,1 --- typer --- 0,n TYPE_MEDIA

[fsmrel]

C'est bien la moindre des choses, mais ce n'est pas le cas dans votre modèle qui viole la 2NF.
En effet, le numéro de téléphone et l'adresse courriel ne dépendent pas seulement de l'identifiant d'une personne mais également de l'identifiant du "type de média" (qui permet de savoir s'il s'agit d'un téléphone fixe domicile, fixe travail, portable privé, courriel pro, courriel privé etc...).
Une personne peut posséder zéro (c'est rare) à plusieurs téléphones et zéro à plusieurs adresses courriel

En ce qui me concerne, en tant que client, mon assureur n’a connaissance que d’un et un seul de mes numéros de téléphone et d’une et une seule adresse courriel, il n’a pas à gérer l’ensemble des téléphones et autres moyens de communication de ses clients. En l’état, je constate que la table CLIENT est normalisée 5NF.

[escartefigue]

En ce qui me concerne, en tant que client, mon assureur n’a connaissance que d’un et un seul de mes numéros de téléphone et d’une et une seule adresse courriel, il n’a pas à gérer l’ensemble des téléphones et autres moyens de communication de ses clients. En l’état, je constate que la table CLIENT est normalisée 5NF.

Les nombreuses personnes qui n'ont pas de courriel (notamment chez les personnes agées mais pas seulement) font donc l'objet de marqueurs nuls activés en masse
Et cet assureur est dans l'incapacité d'appeler un assuré plusieurs téléphones, c'est plutôt restrictif.
Mais pourquoi pas