Bonsoir Zizoua,
Entité-type ASSURE : vous avez défini un identifiant id_massure. Mais un identifiant ne doit pas être significatif, il ne doit donc pas être défini par l’utilisateur, ni contrôlé par celui-ci : en conséquence, il faut ajouter un identifiant alternatif, le numéro d’assuré défini par l’assureur et dont celui-ci fait ce qu’il veut.
Evitez de préfixer le nom des entités-types par la lette « T », ça a une connotation dont on doit se passer au niveau supérieur (modèle conceptuel).
Entité-type CONTRAT : mêmes remarques. Ne confondons pas le numéro de contrat et l’identifiant du contrat.
Ces remarques valent pout toutes les entités-types. En passant, concernant la lettre « T », vous m’objecterez peut-être qu’elle permet de repérer visuellement une table au stade SQL : mais alors pourquoi ne pas avoir ajouté cette lettre en tête des noms des associations donnant lieu à des tables, telles que EST_SOUSCRIT, etc. ?
Envoyé par
Zizoua
(5) Un COURTIER peut être ASSURE mais n’a plus droit en ce moment à une commission donc il perd la fonction de COURTIER (il est en ce moment un simple ASSURE) ;
Du point de vue de l’application, si une personne exerce bien la fonction de courtier, c’est qu’elle n’est pas assurée chez vous. Comme elle ne peut pas être non plus apporteur (cf. votre message #32) ou producteur, on peut conclure qu’elle n’est pas souscripteur.
Envoyé par
Zizoua
(9) Un APPORTEUR peut être un ASSURE en ce moment il est un simple ASSURE, il n’a plus droit à une commission ou prime sur ce contrat ;
Autrement dit, si un apporteur est un assuré, je suppose qu’il perd la fonction d’apporteur s’il l’a déjà, auquel cas on peut dire plus généralement que quelqu’un ne peut pas être connu comme étant à la fois à la fois apporteur et assuré : êtes-vous d’accord avec cette règle ?
si oui, un MCD pourrait être celui-ci :
Sinon, précisez bien les règles, afin qu’on trouve une alternative.
Vous observerez que du point de vue du MCD, un producteur peut aussi être connu en tant qu’assuré : pour respecter la règle : « un producteur ne peut pas produire (faire) son propre contrat d’assurance », on mettra en œuvre la contrainte qui va bien au niveau SQL (cf. la contrainte CONTRAT_CHK01 ci-dessous).
Envoyé par
Zizoua
Un ASSURE ne peut pas être à la fois PRODUCTEUR et ASSURE (ici un ASSURE, s’il est
Comment se termine cette phrase ?
Envoyé par
Zizoua
PRODUCTEUR ne peut pas produire (faire) son propre contrat d’assurance
Si on utilise la spécialisation des personnes, pour garantir cette règle, avec MS SQL Server, il suffit d’ajouter une contrainte pour la table CONTRAT (contrainte CONTRAT_CHK01 ci-dessous), sinon on ne sait pas faire :
CREATE TABLE CONTRAT
(
id_police INT IDENTITY NOT NULL,
num_police CHAR(12) NOT NULL,
date_effet DATE NOT NULL,
id_assure INT NOT NULL,
id_producteur INT NOT NULL,
CONSTRAINT CONTRAT_PK PRIMARY KEY (id_police),
CONSTRAINT CONTRAT_AK UNIQUE (num_police),
CONSTRAINT CONTRAT_CHK01 CHECK (id_assure <> id_producteur)
);
INSERT INTO CONTRAT (num_police, date_effet, id_assure, id_producteur) VALUES ('A047-2016-03', '2016-03-01', 12, 12) ;
=>
Msg 547, Level 16, State 0, Line 16
The INSERT statement conflicted with the CHECK constraint "CONTRAT_CHK01".
Envoyé par
Zizoua
si encore vous trouvez l'ajout d'une table personne est nécessaire alors je tiendrai compte.
Sans l’entité-type PERSONNE, sa spécialisation et les contraintes de partitionnement, par exemple on ne sait pas empêcher qu’un courtier en exercice soit en même temps assuré chez vous, qu’il soit producteur, qu’un producteur soit en même temps apporteur, etc.
Partager