Discussion :

[figarojuju]

Bonjour,
je me permets de demander de l'aide à la communauté de ce forum. En effet, ma femme doit réaliser une enquête sur les pratiques agricoles des cultivateurs maliens par rapport à l'échalote du pays Dogon.
Elle doit rentrer ses données d'enquête dans une base de donnée.
Elle m'a fourni son questionnaire et j'ai essayé de réaliser le MCD (non terminé mais avant d'avancer plus, je souhaitais avoir des avis).
MCD.pdf
Questionnaire.pdf

C'est une ébauche, mais j'ai rencontré des difficultés :
-1) souvent elle utilise comme des sauts conditionnels dans son questionnaire et je ne sais pas comment modéliser ça correctement ? dois-je mettre des valeurs nulles si jamais il n'existe pas de valeur pour remplir la table ?

-2) Comment tenir compte du fait qu'il puisse exister deux cultures d'échalote, l'une principale et l'autre secondaire, ou bien simplement une seule culture ? problème de cardinalité ?

-3) Elle utilise souvent des listes de choix, dois-je créer des entités à chaque fois qu'elle souhaite remplir son questionnaire de cette manière ?

Je vous remercie par avance et vous souhaite une bonne soirée

[JPhi33]

Bonjour figarojuju,

Il s'agit d'enregistrer des réponses à des questions pré-établies invariables. Il suffit donc d'enregistrer les réponses dans une (en fait plusieurs, voir plus loin) entité Réponse. La modélisation normale aboutirait à une association Réponse entre Question et Agriculteur :

[ Question ]--0,n----( Réponse )----0,n--[ Agriculteur ]

mais on va voir plus loin qu'il faut spécialiser Réponse. Il est donc beaucoup plus simple que Réponse soit une entité. Cependant, en utilisant l'identification relative, on peut reproduire artificiellement l'association :

[ Réponse ]-(1,1)---( )----0,n->[ Agriculteur ]
[ Réponse ]-(1,1)---( )----0,n->[ Question ]

Sans identifiant propre, Réponse est identifiée par {idProducteur, idQuestion} c'est-à-dire le même identifiant que cette entité avait été une association (identifiants soulignées) :

Code :

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

1
2
3
4
idProducteur idQuestion Réponse
------------ ---------- ---------------
1            I.1        <quelque chose>

-1) souvent elle utilise comme des sauts conditionnels dans son questionnaire et je ne sais pas comment modéliser ça correctement ? dois-je mettre des valeurs nulles si jamais il n'existe pas de valeur pour remplir la table ?

Si le couple {idProducteur, idQuestion} n'existe pas dans Réponse, c'est que l'agriculteur n'a pas répondu à la question. Le problème des sauts conditionnel est résolu. Exemple : si le producteur a1 répond Non à la question II.1, il est normal que les couples {a1, II.2} et {a1, II.3} soient absents. On n'aura donc pas de problème de Null, simplement des absences de couples {idProducteur, idQuestion} .

-2) Comment tenir compte du fait qu'il puisse exister deux cultures d'échalote, l'une principale et l'autre secondaire, ou bien simplement une seule culture ? problème de cardinalité ?

Si l'agriculteur a1 interrogé ne cultive pas de seconde variété, tous les couples {a1, IV.x} seront absents. A mon avis, il manque une question qui serait "Cultivez-vous une seconde variété ?".

-3) Elle utilise souvent des listes de choix, dois-je créer des entités à chaque fois qu'elle souhaite remplir son questionnaire de cette manière ?

En fait, il y a 4 types de réponses :
1) choix unique parmi une liste (I.1, I.3, I.4, etc.)
2) choix multiples parmi une liste (I.7)
3) réponse libre (I.2, I.5)
4) un mélange 1) + 3) ou 2) + 3)

Pour résoudre ce problème, il faut spécialiser Réponse au moyen de 3 entités correspondant aux types 1), 2) et 3) car l'enregistrement des réponse ne se fait pas de la même manière dans chaque cas. On pourra prévoir une propriété dans Réponse pour indiquer le type de réponse attendu.

[figarojuju]

Et bien merci beaucoup !!
je n'avais absolument pas pensé à modéliser le questionnaire !
j'avais pensé modéliser la situation agriculture/production de l'échalotte et technique utilisée !!

Mais c'est vrai que la vrai question, c'est peut-être la question du questionnaire et non pas de la situation derrière le questionnaire.

En tout cas merci beaucoup, il faut que je potasse toutes ces informations correctement.
Merci encore et bonne journée

[figarojuju]

Bonjour,
j'ai à nouveau pu avancer un peu...
j'ai essayé de tenir compte des remarques et j'ai réalisé le MCD ci joint

Sans identifiant propre, Réponse est identifiée par {idProducteur, idQuestion} c'est-à-dire le même identifiant que cette entité avait été une association (identifiants soulignées)

Je ne comprends pas le but de cette démarche si cela ne change rien par rapport à une association. Pourriez-vous m'expliquer ce que cela apporte ?
est-ce pour spécialiser l'entité reponse :

En fait, il y a 4 types de réponses :
1) choix unique parmi une liste (I.1, I.3, I.4, etc.)
2) choix multiples parmi une liste (I.7)
3) réponse libre (I.2, I.5)
4) un mélange 1) + 3) ou 2) + 3)

Pour résoudre ce problème, il faut spécialiser Réponse au moyen de 3 entités correspondant aux types 1), 2) et 3) car l'enregistrement des réponse ne se fait pas de la même manière dans chaque cas. On pourra prévoir une propriété dans Réponse pour indiquer le type de réponse attendu.

Si on fait on spécialisation de l'entité reponse, alors est-ce utile de créer une propriété type de réponse ?

Je vous remercie de votre aide !!


@bientôt

[JPhi33]

Bonsoir,

Sans identifiant propre, Réponse est identifiée par {idProducteur, idQuestion} c'est-à-dire le même identifiant que cette entité avait été une association (identifiants soulignées)

Je ne comprends pas le but de cette démarche si cela ne change rien par rapport à une association. Pourriez-vous m'expliquer ce que cela apporte ?
est-ce pour spécialiser l'entité reponse :

Oui mais je l'avais déjà dit :

mais on va voir plus loin qu'il faut spécialiser Réponse. Il est donc beaucoup plus simple que Réponse soit une entité.

En effet, on a vu que Réponse est en réalité une association. La spécialisation d'association étant un concept plutôt difficile à manipuler, j'ai trouvé plus simple de faire une petite entorse à la modélisation formelle et de transformer, certes artificiellement, Réponse en entité.

Il y a encore une autre solution : celle de doter Réponse d'un identifiant artificiel idRéponse (de type numéro à suivre, par exemple).

Si on fait on spécialisation de l'entité reponse, alors est-ce utile de créer une propriété type de réponse ?

Le type de réponse n'est pas nécessaire car, pour un couple {idProducteur, idQuestion} donné, une jointure (externe) sur toutes les entités spécialisées donnera forcément la réponse quel que soit son type. Néanmoins, dans certains cas ça peut être plus simple de disposer du type de réponse.

La réponse à cette question n'est donc pas catégorique ; elle dépend des traitements à effectuer. Dans une démarche Merise globale, c'est lors de la phase de validation données/traitements que l'on ajuste ces détails.



Le MCD2 est presque correct.
L'entité Questionnaire telle qu'associée (à Question) n'apporte rien : chaque questionnaire contient toujours l'ensemble des questions. En revanche, le MCD2 ne permet pas de savoir quels enquêteurs ont interrogé quels producteurs.
Par conséquent, l'entité Questionnaire devrait être associée à Agriculteur :

[ Questionnaire ]<-1,n----( )----1,1--[ Agriculteur ]