Discussion :

[francky74]

Bonjour,

Je poste là un questionnement sur la multiplicité 1,1.

Pour illustrer, je prends l'exemple d'une PERSONNE qui a un SEXE .... et j'énonce les règles de gestion suivantes :

-Une personne possède forcément un sexe (pas de commentaires ! cela va de soi même si on prend en compte les opérations chirurgicales qui n'agissent pas, de toute manière, sur le type originel de sexe de la personne ...)
-Un sexe est possédé par une ou plusieurs personnes, mais si vous ne rentrez que des hommes ou que des femmes dans l'entité personne, vous pouvez vous retrouver avec un sexe non attribué (donc cardinalité minimale = 0).

Du coup, cela donne un MCD comme celui-ci :

PERSSONNES ---1,1---posséder---0,N---SEXE

Par contre, si on se met dans la peau d'une secrétaire qui va utiliser un outil informatique lié à cette BDD, on peut se dire que lorsqu'elle va enregistrer une personne dans le système, on peut lui autoriser que le sexe ne soit pas forcément rempli dans son formulaire.
Mais si on a mis la multiplicité 1,1, le système devrait rejeter sa demande d'enregistrement car la BDD veut qu'une personne ait forcément un sexe ....

Donc, il me semble qu'il est normalement conseillé de penser en terme d'utilisation du système plutôt que de penser en terme de logique élémentaire. . . .
n'est-ce pas ?

[Logan Mauzaize]

Donc, il me semble qu'il est normalement conseillé de penser en terme d'utilisation du système plutôt que de penser en terme de logique élémentaire. . . . n'est-ce pas ?

C'est tout le principe de l'analyse. Le résultat, la conception et l'implémentation qui en découlera devront représenter les opérations du système et non la physique (ou même les lois !).
La modélisation ne tend pas à modéliser le monde réel mais le système étudié, c'est-à-dire les processus liés aux activités des acteurs.

Ici dans ton cas, une personne n'est pas une personne "physique" (ou au sens litéral) mais un client, un patient, etc. Tu lui as donné le nom "Personne" à cette entité mais tu aurais aussi bien pu l'appeler autrement.

Autre point, il ne faut jamais confondre l'absence d'une relation (ici possédé) par son contraitre (ne possède pas). En son absence, tout ce que l'on peut dire c'est qu'elle est "indéterminée". Si l'absence est une information en elle (cela peut-être le cas !), il sera utile de le préciser dans l'analyse, voir de le modéliser.
Par exemple, on peut stocker la composition d'un foyer (nombre d'enfant et répartition par sexe), en sus de la liste des enfants. La liste peut être incomplète, cela ne signifie pas que c'est incohérent mais juste qu'on possède qu'une partie des informations.

[francky74]

Merci pour votre réponse

[CinePhil]

Tu pars de ce MCD :

PERSONNE ---1,1---posséder---0,N---SEXE

Puis tu dis :

Par contre, si on se met dans la peau d'une secrétaire qui va utiliser un outil informatique lié à cette BDD, on peut se dire que lorsqu'elle va enregistrer une personne dans le système, on peut lui autoriser que le sexe ne soit pas forcément rempli dans son formulaire.

Autrement dit, dans le système étudié, l'entité-type personne peut ne pas être associée à l'entité-type sexe, ce qui aboutit au MCD suivant :
PERSONNE ---0,1---posséder---0,N---SEXE

Et comme tu as lu mon billet, tu sais que cela engendrera la création d'une table associative dont la clé primaire sera l'identifiant de la personne.

[francky74]

Tout à fait !