Discussion :

[new_wave]

Bonjour,
Ma question est la suivante:

Parmi des collaborateurs d'un laboratoire (au niveau commercial) on compte des visiteurs médicaux, des délégués régionaux et des responsables de secteurs.
Les délégués régionaux sont des visiteurs à part entière qui occupent une part de leur temps à l'amélioration des activités des visiteurs.
Par contre , les responsable de secteurs ne sont pas du tout des visiteurs.
J'ai crée une contrainte de totalité entre une entité générique COLLABORATEUR et trois sous entités VISITEUR, DELEGUE_REGIONAL et RESPONSABLE_SECTEUR.
Cette contrainte signifie: un collaborateur peut être soit un visiteur, soit un delegue regional ou soit un responsable de secteur.
Il peut également être l'un et l'autre , mais ne peut pas être autre chose qu'un visiteur, un delegue regional ou un responsable de secteur.

S'il est vrai qu'un délegué regional peut être en même temps un visiteur, ceci ne s'applique pas à responsable de secteur et visiteur(un responsable de secteur ne peut pas être en même temps un visiteur dans l'existant du laboratoire).
Y-a-t-il pour autant un faux sens strictement?

Il existe une autre solution qui serait de placer sous l'entité collaborateur, deux sous entités :visiteur et delegue regional et de placer une absence de contrainte entre ces sous entités et l'entité générique;cette contrainte se comprendrait ainsi: : un collaborateur peut être soit un visiteur, soit un délégué regional , soit les deux.
Il peut être également autre chose, c'est à dire , dans notre cas, un responsable de secteur.
Quelle solution privilègeriez-vous, sachant que dans le deuxième cas, l'entité responsable de secteur n'apparaît pas ?

Vous remerciant beaucoup de votre réponse et de votre aide,

Cordialement.

New wave

[Richard_35]

Bonjour New_wave,

Intéressant...

Il y a une contradiction entre

Les délégués régionaux sont des visiteurs à part entière

et

S'il est vrai qu'un délegué regional peut être en même temps un visiteur

==> il est fondamental de la lever !

Si les délégués régionaux sont forcément des visiteurs particuliers :


pourrait convenir (quoique je ne suis pas trop d'accord avec le SQL généré par JMerise).

ou bien :



Le second cas, plus tard.

[fsmrel]

Bonjour,

Il existe une autre solution qui serait de placer sous l'entité collaborateur, deux sous entités :visiteur et delegue regional et de placer une absence de contrainte entre ces sous entités et l'entité générique;cette contrainte se comprendrait ainsi: : un collaborateur peut être soit un visiteur, soit un délégué regional , soit les deux.
Il peut être également autre chose, c'est à dire , dans notre cas, un responsable de secteur.
Quelle solution privilègeriez-vous, sachant que dans le deuxième cas, l'entité responsable de secteur n'apparaît pas ?

Si l’on suit votre raisonnement, la modélisation qui en résulte est la suivante (aucune contrainte symbolisée au sein de la demi-lune) :




On est alors le non dit quant aux responsables de secteur. On infère qu’un collaborateur est un responsable si et seulement si il n’est ni visiteur ni délégué, ce qui dans un monde idéal est possible, mais concrètement plutôt léger au stade opérationnel. En effet, à ce stade rien n’empêche qu’un responsable soit aussi visiteur et/ou délégué.

Il y a une contradiction entre :
Les délégués régionaux sont des visiteurs à part entière
Et
S'il est vrai qu'un délégué régional peut être en même temps un visiteur

Effectivement, c’est la différence qu’il y a entre un prédicat quantifié soit par « ∀ » soit par « ∃ »...

Du point de vue de Merise, un MCD ne doit pas comporter de redondance d’attributs, IdCollaborateur doit donc être évacué des entités-types Visiteur, DelegueRegional et ResponsableSecteur.

Par ailleurs, le concept d’auto-incrément est du niveau SGBD (MPD donc) et doit être évacué lui aussi du MCD.

En toute logique, si DelegueRegional est un sous-type de Visiteur, alors il manque un triangle sur la patte les connectant. Si c’est l’outil qui permet d’en faire l’économie, alors le triangle connectant Collaborateur et ses sous-types doit disparaître (auquel cas on retrouve la notation UML). Si l’outil permet de panacher les représentations, alors il y a là perte d’intégrité conceptuelle (cf. The Mythical Man-Month). Autrement dit, passer ça au rasoir d'Ockham.

Que vient faire ici cette CIF (inférable du reste du fait cardinalités maximales 1) ? Comment repérer la source, la portée, le pivot ? S’il s’agit d’exprimer la totalité et l’exclusion, il faudrait remplacer « CIF » par « XT » (ou « + » symbole utilisé par l’Afcet (journée du 15 novembre 1990) pour le « ou exclusif », valant pour, je cite, « totalité et exclusion mutuelle »).

Les observations faites à propos de la redondance d’attributs et de l’auto-incrémentation valent évidemment ici.

[Richard_35]

Bonjour Fsmrel et New_wave (et Rabdev),

Du point de vue de Merise, un MCD ne doit pas comporter de redondance d’attributs, IdCollaborateur doit donc être évacué des entités-types Visiteur, DelegueRegional et ResponsableSecteur.

==> merci . Du coup, ma remarque

(quoique je ne suis pas trop d'accord avec le SQL généré par JMerise)

est caduque. En effet, dans JMerise, le fait de ne pas répéter IdCollaborateur dans les tables "filles", génère un SQL de création de table correct (désolé, Rabdev).


En revanche, si

le concept d’auto-incrément est du niveau SGBD (MPD donc) et doit être évacué lui aussi du MCD

==> alors, le CREATE TABLE n'est pas correct pour les attribut du champ IdCollaborateur. Laissons-le donc au niveau MCD.

Que vient faire ici cette CIF (inférable du reste du fait cardinalités maximales 1) ? Comment repérer la source, la portée, le pivot ? S’il s’agit d’exprimer la totalité et l’exclusion, il faudrait remplacer « CIF » par « XT » (ou « + » symbole utilisé par l’Afcet (journée du 15 novembre 1990) pour le « ou exclusif », valant pour, je cite, « totalité et exclusion mutuelle »).

==> c'est vrai. Le texte de l'objet "CIF" ne semble pas modifiable dans JMerise. Peut-être est-ce une idée d'évolution.

[CinePhil]

En toute logique, si DelegueRegional est un sous-type de Visiteur, alors il manque un triangle sur la patte les connectant.

Euh... je vois bien un triangle sous l'entité type Visiteur qui constitue l'extrémité du trait entre Visiteur et DelegueRegional !
Tu parles d'un autre triangle ?

Le schéma de Richard me semble correct, une fois débarrassé des identifiants des entités types filles, puisque, en présence d'un héritage de données, il y a identification relative.

[fsmrel]

Bonsoir,

le concept d’auto-incrément est du niveau SGBD (MPD donc) et doit être évacué lui aussi du MCD.

==> alors, le CREATE TABLE n'est pas correct pour les attribut du champ IdCollaborateur. Laissons-le donc au niveau MCD.

Vous n’y êtes évidemment pour rien, mais c’est à l’outil de respecter le principe de l’intégrité conceptuelle. Une fonctionnalité du niveau physique n’a pas à polluer le niveau conceptuel.

Que vient faire ici cette CIF (inférable du reste du fait cardinalités maximales 1) ? Comment repérer la source, la portée, le pivot ? S’il s’agit d’exprimer la totalité et l’exclusion, il faudrait remplacer « CIF » par « XT » (ou « + » symbole utilisé par l’Afcet (journée du 15 novembre 1990) pour le « ou exclusif », valant pour, je cite, « totalité et exclusion mutuelle »).

==> c'est vrai. Le texte de l'objet "CIF" ne semble pas modifiable dans JMerise. Peut-être est-ce une idée d'évolution.

Il ne s’agit pas de faire évoluer l’outil, mais bien d’y corriger une anomalie.

Euh... je vois bien un triangle sous l'entité type Visiteur qui constitue l'extrémité du trait entre Visiteur et DelegueRegional !
Tu parles d'un autre triangle ?

Je parle de cohérence dans la notation.

Ou bien un outil propose une notation telle que celle-ci (façon WinDesign, PowerAMC) et il s’y tient :




Ou bien un outil propose la notation ULM :




Mais on s’en tient à une notation, l'outil ne devrait pas permettre des mélanges pouvant déstabiliser le lecteur.