Discussion :

[Zidane7]

Je fais un traitement d'un MCD d'assurance automobile dont voici le schéma:

J'aimerais avoir vos remarques et suggestion pour mon schéma.
Merci par avance.

[Zidane7]

Voici une version plus amerioré que la précédente:RC= Responsabilité civile en circulation.
DATETARIF= est la date de la tarification des véhicules.
DATEAP= est la date d'appartenance du véhicule à un assuré.

[fsmrel]

Bonjour Zidane7,

Prenons le cas de mon propre véhicule V. Le système en connaît la puissance, mais pas la catégorie. Comment le système détermine-t-il ma responsabilité civile ? La date de tarification concernant V ?

[Zidane7]

Bonsoir Monsieur.
Merci Monsieur par rapport à votre question, voici la version plus claire que la précédente.
Le tarif est déterminé par rapport au des intervalles de puissances et de catégorie.
La valeur de la RC n'existe qu'une seule fois dans un intervalle de puissance et dans une et une seule catégorie.
On ne peut pas avoir un le même tarif dans deux intervalles de puissance et de catégorie différente.
Merci pour la compréhension.

[fsmrel]

Bonjour Zidane7,

Le tarif est déterminé par rapport au des intervalles de puissances et de catégorie.

Donc pour l’intervalle de puissance i1 et la catégorie c1, le tarif est unique, t1 (nommons P1 cette proposition).

Selon votre MCD, pour le véhicule v1, la catégorie c1 et le tarif t1, c’est l’intervalle i1 qui est unique (nommons P2 cette proposition).

Il y a contradiction entre les propositions P1 et P2. P1 étant la seule proposition valable, le MCD est à revoir. Il va falloir mettre en oeuvre une entité-type INTERVALLE qui sera à associer à l’entité-type CATEGORIE. Cette association permettra de déterminer le tarif pour chaque paire (catégorie, intervalle).

Question : Soit t1 la valeur du tarif déterminé à la date initiale d1 par la paire (c1, i1). La valeur t1 est-elle figée dans le temps ? où au contraire, peut-elle être remplacée par la valeur t2 à une date d2 ?

[fsmrel]

Zidane7,

En examinant la liste des attributs des entités-types de votre MCD, on constate que les identifiants sont manifestement des codes (Code_Categorie, Code_Vehicule, Code_Contrat, etc.). Il s’agit là d’attributs « naturels », c’est-à-dire dont les valeurs sont fournies par les utilisateurs.

Par référence à la règle d’or du très grand Merisien Yves Tabourier, les identifiants des entités-types doivent très préférablement être des attributs artificiels, tandis que les attributs naturels (propriétés naturelles chez Tabourier) tels que Code_Categorie, etc. sont à ravaler au rang d’identifiants alternatifs, garantissant évidemment eux aussi la règle d’unicité des identifiants.

Ces identifiants alternatifs ne seront que des points d’entrée dans la base de données, dont les valeurs (uniques et modifiables) ne s’y propageront pas. Les valeurs des identifiants artificiels sont calculées par le système (le SGBD en l’occurrence) n’ont aucune signification sémantique, et n’ont donc aucune raison d’être modifiées. Les valeurs prises par ces identifiants artificiels, devenus clés primaires au stade SQL, pourront se propager par le mécanisme de l’intégrité référentielle.

Je cite Tabourier (page 80 de son remarquable ouvrage De l’autre côté de Merise, Les Éditions d’organisation, 1986) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Dans votre MCD, l’entité-type CATEGORIE est à doter d’un identifiant artificiel, tandis que Code_Categorie devient identifiant alternatif. A cet effet, avec Looping : dans la boîte « Rubrique », décocher la case « Identifiant » et cocher la case « UNIQUE » (et bien entendu la case « NOT NULL »). Même principe pour les autres entités-types.

[Zidane7]

Je viens d’améliorer mon modèle de la manière ci-dessous:

Donc pour l’intervalle de puissance i1 et la catégorie c1, le tarif est unique, t1 (nommons P1 cette proposition).

Selon votre MCD, pour le véhicule v1, la catégorie c1 et le tarif t1, c’est l’intervalle i1 qui est unique (nommons P2 cette proposition).

Il y a contradiction entre les propositions P1 et P2. P1 étant la seule proposition valable, le MCD est à revoir. Il va falloir mettre en oeuvre une entité-type INTERVALLE qui sera à associer à l’entité-type catégorie. Cette association permettra de déterminer le tarif pour chaque paire (catégorie, intervalle).

Question : Soit t1 la valeur du tarif déterminé à la date initiale d1 par la paire (c1, i1). La valeur t1 est-elle figée dans le temps ? où au contraire, peut-elle être remplacée par la valeur t2 à une date d2 ?

Par rapport à votre question, la RC est unique entre un intervalle de puissance et pour une et une seule catégorie. Mais le même intervalle peut être dans une autre catégorie. La RC est unique non seulement par rapport à l'intervalle de puissance mais aussi à la catégorie.
RC peut être changé mais cela prend plusieurs années.
Avez-vous d’autres suggestions ou questions ?
Merci par avance.

[fsmrel]

la RC est unique entre un intervalle de puissance et pour une et une seule catégorie.

Donc cette RC ne dépendant bien que de l’intervalle de puissance et de la catégorie, votre MCD est faux puisque l’intervalle y dépend du véhicule, ce qui fait que, transitivement, la RC dépend à tort du véhicule.

le même intervalle peut être dans une autre catégorie.

Dans la mesure où selon la règle de gestion correspondante, nommons-la RG01, deux catégories distinctes peuvent être associées au même intervalle, il n’y a pas de problème. Exemple sous forme tabulaire :

catégorie    intervalle    rc
c1           i1            rc1
c2           i1            rc2
c3           i2            rc3

Maintenant, si la règle RG01 n’est pas pertinente, merci d’en fournir la rédaction correcte.

[Zidane7]

Merci Monsieur,
Je vous envoie un exemple de TARIF qui va vous permetre de bien comprendre mon problème.
Dans ce TARIF prenez seulement la puissance qui est donnée par intervalle, la RC par Catégorie et par puissance et est unique.
Merci par avance.

[fsmrel]

Bonjour Zidane7,

Nos deux tableaux sont en phase : une paire {catégorie, puissance fiscale} détermine une responsabilité civile.

Pour modéliser cela :

[PUISSANCE]---1,N---(PFC (responsabilite_civile, ...) )---1,N---[CATEGORIE]

Exemple tabulaire (clés soulignées) :

PUISSANCE
puissanceId   puissanceIntervalle   
1             [0:2]
2             [3:6]
3             [7:10]
4             [11:14]
5             [15:23]
6             [24:999]


CATEGORIE
catId   catCode   catLibelle
1       c1        Affaires & promenades
2       c2        Transport pour le compte de l’assuré


PFC
catId   puissanceId   responsabiliteCivile
1       1             203657
1       2             244399
1       3             285114
...
2       2             401383
2       3             563124

Passons aux véhicules et à leur association aux responsabilités civiles. Un véhicule détermine une responsabilité civile, donc une paire {catId, puissanceId} dans PFC :

VEHICULE
vehiculeId   vehiculeSerie   vehiculePuissance   catId   puissanceId
v1           s1              5                   1       2

En notant que le véhicule v1, de série s1 et de puissance 5 détermine sa catégorie, 1 (Affaires & promenades) et et son intervalle de puissance, 2 (3 à 6 CV).

Comment traduire cela dans le MCD ? Il faut établir une association entre VEHICULE et PFC, mais Merise interdit cette association car PFC est elle-même une association...

Même pas grave, on va demander à Looping de transformer PFC en entité-type, il suffit de cliquer sur l’icône prévue à cet effet :

Au résultat :

PFC n’a pas d’identifiant en propre, car du fait de l’identification relative, son identifiant est la paire {catId, puissanceId}.

Pour l’étude de l’identification relative, reportez-vous aux pages 130 (identifiant relatif) et 255 de l’ouvrage de référence de D. Nanci et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

De son côté, Looping ne manque pas de fournir la bonne traduction MLD et SQL de la chose (structure tabulaire).

[Paprick]

Bonjour François,
Toujours aussi efficace avec Looping !

[Zidane7]

Bonjour Messieurs,
Merci pour vos remarques et suggestions.
Voici les différentes modifications que j'ai faite. Que pensez vous?
Merci par avance.

[fsmrel]

Bonjour Zidane7,

D’accord donc pour la responsabilité civile.
Via PFC, pour un véhicule donné V, on sait quelle est la catégorie C à laquelle il appartient. Question : Les sous-catégories de C valent-elles toutes pour V, ou bien seulement certaines d’entre elles ?

Cette catégorie C fait référence à 1,N garanties. Ces garanties valent-elles toutes pour V, ou bien seulement certaines d’entre elles ? (Quid des sous-garanties ?)


Une remarque concernant les identifiants :

Dans le post #6, j’ai écrit :

Les valeurs des identifiants artificiels sont calculées par le système (le SGBD en l’occurrence) n’ont aucune signification sémantique, et n’ont donc aucune raison d’être modifiées. Les valeurs prises par ces identifiants artificiels, devenus clés primaires au stade SQL, pourront se propager par le mécanisme de l’intégrité référentielle.

J’apporte une précision :

Quand j’écris « n’ont donc aucune raison d’être modifiées », je sous-entends « modifiées par l’utilisateur ». Pour sa part, le SGBD fait ce qu’il veut et peut changer comme bon lui semble les valeurs des identifiants (à l’occasion par exemple d’une réorganisation, d’une remise à plat, d’une réparation, etc.) En revanche, il a pour contrainte de respecter systématiquement l’intégrité référentielle (référencement des étrangères par rapport aux clé primaires). Conséquence pour nous : ne jamais utiliser les valeurs des identifiants contrôlés par le SGBD, ces valeurs doivent rester cachées, et les forums sont bien fournis en pleurs et gémissements de ceux qui n’ont pas respecté cette règle. En contrepartie, il n’est pas inutile de mettre en oeuvre des codes « naturels » pour accéder aux données des tables. Par exemple, pour l’entité-type CLIENT, vous avez défini l’identifiant artificiel clientId, dont les valeurs devront exclusivement être gérées par le SGBD, dans le cadre du mécanisme de l’auto-incrémentation, disons de la clé primaire (SERIAL de PostgreSQL, IDENTITY de DB2 et SQL Server, AUTO_INCREMENT de MySQL, COUNTER d’ACCESS, etc.). Dans ces conditions, pour accéder aux données du client, vous devrez utiliser tout ou partie des attributs de CLIENT : nomClient, prenomClient, adresseClient, telephoneClient. Ça n’est guère pratique et le mieux serait sans doute de définir un attribut codeClient, servant de clé alternative (propriété UNIQUE).

Exemple (Looping) :

L’utlisateur accède alors aux données d’un client au moyen de son code (attribut codeClient). En SQL, pour accéder aux véhicules de ce client, on passe la main au SGBD au moyen d’une jointure avec la table POSSÉDER mettant en jeu l’attribut clientId, etc.

[Zidane7]

Merci pour votre réponse.

Code :

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

1
2
D’accord donc pour la responsabilité civile.
Via PFC, pour un véhicule donné V, on sait quelle est la catégorie C à laquelle il appartient. Question : Les sous-catégories de C valent-elles toutes pour V, ou bien seulement certaines d’entre elles ?

Réponse : Les sous-catégories de C ne valent pas toutes de V mais seulement certaines d’entre elles.
Voici un exemple de Catégorie et de son sous-catégorie.
Aussi le schéma de la Catégorie et de son sous-catégorie.
Voici les modifications dont j'ai apporté au MDC.
Avez vous d'autres suggestions?
Merci par avance.

[fsmrel]

Bonsoir Zidane7,

J’essaie d’interpréter la catégorie 4 : il s’agirait des « taxis urbains et inter urbains ».
Il semble que les termes « Taxis 4 places » et « Taxis 5 places » correspondent chacun à une sous-catégorie de la catégorie 4. Mon interprétation est-elle correcte ? Si oui, le montant de la responsabilité civile et celui de la défense recours diffèrent manifestement selon la sous-catégorie. Quelle est votre position à ce sujet ?


Concernant les identifiants :

Je rappelle qu’une entité-type (ou classe d’entités avec Looping) a un identifiant naturel (codeClient pour l’entité-type CLIENT dans mon exemple du post #13). Pour suivre Tabourier, il est prudent et urgent de doter aussi cette entité-type d’un identifiant artificiel, nommons-le idClient (ou clientId, peu importe). Comme je l’ai écrit dans le post #13, cet identifiant artificiel sera valorisé de préférence par le SGBD. Une entité-type telle que CLIENT se retrouve donc avec deux identifiants : codeClient (naturel, contrôlé par l’utilisateur) et idClient (artificiel, contrôlé par le SGBD).

Avec Looping, pour définir l’identifiant naturel, se reporter à la figure du post #13.

Pour définir l’identifiant artificiel :

[Zidane7]

Bonjour,
Merci pour votre contribution.

J’essaie d’interpréter la catégorie 4 : il s’agirait des « taxis urbains et inter urbains ».
Il semble que les termes « Taxis 4 places » et « Taxis 5 places » correspondent chacun à une sous-catégorie de la catégorie 4. Mon interprétation est-elle correcte ? Si oui, le montant de la responsabilité civile et celui de la défense recours diffèrent manifestement selon la sous-catégorie. Quelle est votre position à ce sujet ?

Vous avez parfaitement raison, à mon avis la sous-catégorie dépend elle aussi de la

PFC

car chaque sous-catégorie à un montant de la responsabilité civile et défense recours différent de celui de sa catégorie.
Par rapport à votre question voici l'exemple de la catégorie 4 et de ses sous-catégories en fonction du nombre de place.
Regardez le schéma ci dessous.
NB: La defense recours est égale à 5% de la RC.
La seule chose qui ne varie pas c'est la

RC, Cout de police et CEDEAO

J'ai effectué des modifications sur le schéma dont voici ci-dessous.
Merci par avance.

[fsmrel]

Bonsoir Zidane7,

à mon avis la sous-catégorie dépend elle aussi de la PFC

Je dirai que c’est plutôt l’inverse :

Une responsabilité civile (PFC) dépend en fait soit d’une catégorie (si celle-ci n’a pas de sous-catégorie), soit d’une sous-catégorie si la catégorie a des sous-catégories. Ce « soit, soit » conduit à mettre en oeuvre une entité-type, nommons-la CAT_SCAT, qui est une généralisation des entités-types CATEGORIE et SOUS_CATEGORIE, et c’est à cette nouvelle entité-type que PFC va faire référence.

Dans ce schéma, on a utilisé l’héritage, dont le concept est bien documenté dans l’ouvrage de référence de D. Nanci (RIP) et B. Espinasse : Ingénierie des systèmes d'information, Merise deuxième génération (4e édition, 2001), au chapitre 7 (« Modélisation conceptuelle des données », paragraphe « Généralisation », page 112. Quant à la partie SQL, regardez bien ce que produit Looping. Notez que les entités-types CATEGORIE et SOUS_CATEGORIE n’ont pas d’identifiant (artificiel) en propre, elles héritent en effet de celui de CAT_SCAT. La techniqe utilisée dans cette partie peut vous paraître nouvelle et compliquée, mais avec l’ouvrage en question, ça devrait aller. Maintenant, Paprick et le Capitaine Escartefigue ont peut-être une solution plus sioux...
Concernant les garanties, on est en présence d’une situation sans doute analogue à celle des catégories : une garantie (ou une sous-catégorie) intervient-elle dans le calcul des montants ?

[Zidane7]

Bonjour Monsieur
Merci infiniment pour vos interventions.
Je voudrais faire une suggestion par rapport à cette situation de catégorie et sous-catégorie.
Comme la catégorie 4 varie en fonction du nombre de place, est ce on peut créer un champ nombre de place dans la catégorie pour palier à ce genre de problème?
Ensuite ici les champs non calculés sont les suivants: La RC(Responsabilité Civile), Cout de police et la CEDEAO.
Voici la modification que j'ai apportée au schéma.
Avez vous d'autres remarques?
Merci par avance.

[fsmrel]

Bonsoir Zidane7,

Vous avez défini un attribut nombrePlacesCategorie pour l’entité-type CATEGORIE. Cela veut dire que sémantiquement parlant, cela vaut pour chaque catégorie, or ça n’est pas le cas. Par exemple, les catégories 1 et 2 ne sont pas concernées.

En outre, l’attribut nombrePlacesCategorie ne peut prendre qu’une valeur par catégorie, ce qui revient à dire qu’il ne peut y avoir qu’une seule sous-catégorie par catégorie, ce qui est évidemment faux dans le cas de la catégorie 4. Votre montage ne fonctionne pas.

Concernant le coût de la police et CEDEAO, si le montant est le même pour tous les véhicules, il s’agit de constantes, que vous pouvez faire figurer dans le MCD à l’aide d’entités-types ad-hoc, sans relation avec les autres entités-types. Si les montants peuvent évoluer dans le temps, ces entités-types auront deux attributs, dateMontant, montant, avec dateMontant pour identifiant.

[escartefigue]

Bonjour Zidane7, bonjour François

Concernant l'entité-type véhicule, s'il s'agit du véhicule assuré, identifié par un numéro de chassis, de moteur et d'immatriculation, alors l'énergie, le nombre de places et la marque doivent être externalisés
Le nombre de places doit être un attribut d'une nouvelle entité-type modèle
La marque doit également faire l'objet d'une nouvelle entité-type en lien avec le modèle
Idem pour l'énergie

Ce qui donne (PK soulignées) :

[MA_MARQUE (MA_ident, MA_nom...) 0,n --- proposer --- 1,1(R) [MO_MODELE (MO_ident, MO_nom, MO_places...)] 0,n --- appartenir --- 1,1(R) [VH_VEHICULE(VH_ident, VH_immatriculation, VH_date_immat...)]

et

[MO_MODELE (MO_ident, MO_nom, MO_places...)] 1,1 --- utiliser --- 0,N [EN_energie(EN_ident, EN_code, EN_libelle...)]


Les cardinalités suffixées (R) matérialisent l'identification relative.

Exemple de modèle : CLIO 4 millésime 2016 finition RXE (CLIO seul ne saurait suffire à déterminer une énergie ou un nombre de places )