Discussion :

[laurent_42]

Bonjour à toutes et à tous,

Le contexte
Je débute en matière de base de données puisque pour l'instant je n'en ai fait qu'une seule.

Je travaille en recherche clinique. On me demande de concevoir les bases des études que nous gérons.
Une étude c'est un cahier d'observation permettant de recueillir les données de la recherche et une base associée.
Un cahier d'observation est constitué de bordereau. Chaque bordereau se divise en paragraphe et chaque paragraphe en question. Les réponses aux questions peuvent être des textes, des nombres, des listes de choix à réponse unique ou des dates.
Tout ceci est donc très structuré.

Je me suis donc dit qu'il pourrait être tout à fait intéressant de concevoir une base de méta-données des études de manière à tenter d'automatiser la création du cahier d'observation et la création de la base associée.

Ce que j'ai fait (je n'oserai pas appeler ça un modèle...)
J'ai créé :
- une table d'études MD_ETUDE stockant le titre et le nom de l'étude ;
- une table des bordereaux MD_BORDEREAU avec titre, type de bordereau, numéro d'ordre, nombre de page souhaité. Le type de bordereau est un acronyme de 3 lettres ; le nombre de page est là pour divisé le futur formulaire en plusieurs pages, histoire de ne pas trop jouer avec la molette de la souris ;
- une table des paragraphes MD_PARAGRAPHE avec titre, numéro d'ordre et numéro de la page du bordereau sur laquelle le paragraphe devra apparaitre
- une table MD_QUESTION précisant le numéro d'ordre de la question, le libellé de la question, le branchement logique éventuel de la question (question du genre Sexe H/F Si c'est une femme, est-elle enceinte ?)
- une table réponse MD_REPONSE avec :

le nom de la table qui devra stocker la variable ci-dessous

le nom de la variable qui devra stocker la réponse à la question dans la base de l'étude

le type de la réponse

la description de la réponse

le message en cas d'erreur

si le null est interdit

si le champ est requis (vous aurez reconnu les champs d'Access)

si les contrôles sur la variable devront être poussés

un champ de liaison vers les propriétés de la réponse selon son type

Les différents types de réponses sont stockés dans une table MD_TYPE et les propriétés de la réponse dans des tables MD_CHOIX (listes de choix à réponse unique), MD_OUINON (variante très courante de la réponse MD_CHOIX), MD_DATE, MD_MEMO, MD_TEXTE, MD_NUM. Dans ces tables on retrouve les infos propres au type de réponse (format, masque, valeur par défaut, valide si, limites max et min absolues et relatives pour les dates et les nombres, nombre de ligne pour la réponse pour les textes et les mémos, etc...). Enfin une dernière table MD_CHOIX_CODAGE, liée à la table MD_CHOIX permet d'associer un codage aux éléments de la liste (exemple Sexe : Homme codé 1 et Femme codé 2).

Je vous joins le schéma relationnel.
Relation.pdf

Mes difficultés
Mes difficultés commencent aux tables MD_QUESTION et MD_REPONSE. Oui c'est à partir de là évidemment que la structure mérite d'être bien pensée, bien réfléchie, que ça se complexifie un peu...

J'avoue avoir du mal avec les relations de manière générale et notamment avec le type de relation dans Access. Entre MD_QUESTION et MD_REPONSE, formellement j'ai plutôt une relation 1 à 1 : pour une question je n'ai qu'une seule réponse et pour une réponse j'ai une seule question, notamment parce que dans la table réponse, j'ai le nom de la variable qui stockera la réponse à la question dans la base de l'étude. Mais dans Access, je n'ai pas vraiment compris comment faire. Et entre MD_REPONSE et mes tables de propriétés, formellement je peux avoir un enregistrement de la table MD_NUM pour plusieurs réponses (par exemple si on pose plusieurs fois la même question au cours du temps) mais dans les faits, je ne pense pas réutiliser le même enregistrement. Simplement parce que je ne sais pas comment le retrouver facilement. Du coup j'envisageais de définir un enregistrement de propriété pour chaque réponse. Du coup je bascule plutôt sur une relation 1 à 1, non ?

Je sais que mon modèle n'est pas bon pour l'instant. Il suppose que pour chaque réponse je doive peupler toutes les tables de propriétés selon le type de réponse MD_DATE, MD_NUM, MD_CHOIX, etc... En fait je me demande s'il ne vaudrait pas mieux faire le lien entre la clé primaire des enregistrement de la table MD_REPONSE et une clé étrangère dans les tables de propriétés selon le type de réponse... Quand je vous dis que j'ai du mal avec les relations, je ne vous mens pas !!!

Du coup, si vous avez des idées, des conseils (notamment de lecture) ou si vous avez repéré des "erreurs" de conception, bref, si vous avez le temps de me filer un coup de main, je suis définitivement preneur !!!

Merci de m'avoir lu jusqu'au bout et merci d'avance pour votre aide !

Bonne journée
Laurent

[laurent_42]

Bonjour,

Votre silence m'inquiète : est-ce que je fais tellement fausse route qu'il n'est pas possible de repartir de si loin ??? Aie aie aie !!! Ou est-ce que mon message n'était pas clair ???

J'ai essayé de réfléchir un peu.

Est-ce qu'il ne vaudrait pas mieux rassembler les entités question et réponse dans une seule en mettant dans cette unique entité tous les renseignements que j'avais divisés en plusieurs tables mais en ne remplissant que ceux qui sont nécessaire pour la question ?

Merci d'avance !

Laurent

[ClaudeLELOUP]

Bonjour,

J'ai le sentiment que ce que tu veux faire se rapproche du sujet traité dans cette discussion.

Si c'est le cas, je te donnerai volontiers un coup de main si nécessaire.

[laurent_42]

Bonjour Claude (et aux autres aussi !)

Bonjour,

J'ai le sentiment que ce que tu veux faire se rapproche du sujet traité dans cette discussion.

Je viens de regarder. De ce que j'ai compris, je dirais "Moui, ça s'en rapproche". Effectivement je veux aussi une base pour administrer les différentes études que nous suivons. Mais je ne sais pas si ça se rapproche plus que ça.
Les données de ma base sont les questions de l'étude et leur réponse. Par exemple question : Température. Sa réponse est un nombre à 3 chiffres dont une décimale, l'unité est le degré Celsius représenté par "°". Le nombre est compris entre 30 et 44°. Quand je veux faire apparaitre la question et la réponse, je veux quelque chose ressemblant à :
Température : |__|__|,|__| °
J'ai effectivement la question, la réponse à 3 chiffres dont une décimale et l'unité. Et je veux un contrôle sur les valeurs extrêmes lors de la saisie.
Autre exemple de question :
Etiologie dont la réponse est Etiologie1 codée par 1, Etiologie2 codée par 2, Etiologie3 codée par 3 et Etiologie4 codée par 4 (il n'est pas possible d'avoir plusieurs réponses à une seule question, c'est dans les procédures). Je veux que le choix de la réponse apparaisse dans une liste déroulante.
Autre exemple : Date de naissance (JJ/MM/AAAA) : |__|__|/|__|__|/|__|__|__|__| avec les limites appropriées.
Je peux aussi avoir des questions du type "Expliquez : ................................................................................"

Et mon problème réside dans la modélisation de cet ensemble question/réponse. Dans un premier temps j'avais prévu de faire d'une part des questions et d'autre part des réponses. Et puis ce n'était pas satisfaisant. Surtout que je ne suis pas très à l'aise avec les relations. Mais je me suis dit qu'en fait il fallait peut-être fondre les questions et les réponses dans la même entité.

Oui je me répète. Mais vraiment je n'ai pas réussi à voir le lien entre le problème de Sandra et le mien.

Mais merci !!!

A bientôt
Laurent

[ClaudeLELOUP]

Bonjour,



Si toutes des données sont du même acabit que les exemples que tu donnes, alors oui, c'est beaucoup plus simple : une seule table va suffire !

Vois l'exemple en annexe.

[laurent_42]

Bonjour,

Merci pour la réponse.

Mais en fait je ne veux pas faire la base des données de l'étude mais la base des études. Donc mes données ne sont pas la température, la date de naissance, etc... Mes données sont les questions de l'étude et les réponses attendues ou le type de réponse. Je rappelle ce que j'écrivais dans mon tout premier post :

Une étude c'est un cahier d'observation permettant de recueillir les données de la recherche et une base associée.
Un cahier d'observation est constitué de bordereau. Chaque bordereau se divise en paragraphe et chaque paragraphe en question. Les réponses aux questions peuvent être des textes, des nombres, des listes de choix à réponse unique ou des dates.
Tout ceci est donc très structuré.

Je me suis donc dit qu'il pourrait être tout à fait intéressant de concevoir une base de méta-données des études de manière à tenter d'automatiser la création du cahier d'observation et la création de la base associée.

Donc la base que je cherche à faire est celle qui me permettra de créer la base de l'étude.

Si je reprends l'exemple de la température, dans ma base de méta-données, j'ai un enregistrement qui contient la question "Température", la réponse "|__|__|,|__|°". A partir de cet enregistrement je vais définir une base dans laquelle j'aurai une variable dont le libellé sera "Température", il s'agira d'un numérique à une décimale, etc... En gros dans la base des méta-données, je veux stocker toutes les infos qui permettent de construire la base que tu m'as envoyé.

Je ne suis pas sur d'être très clair...

A bientôt
Laurent

[ClaudeLELOUP]

Désolé, je ne sais comment t'aider.

J'espère que quelqu'un prendra le relais.

[laurent_42]

Bonjour,

Tant pis ! Merci d'avoir essayé.

Bonne fin de journée
Laurent

[alassanediakite]

Salut à tous.
Le modèle suivant (en pièce jointe) peut-il faire l'affaire? Le dossier compressé contient un fichier au format JMerise
C'est un petit modèle pour un questionnaire (statistique, évaluation d'apprenant...)
@+

[laurent_42]

Bonjour alassanediakite et les autres,

Avant d'aller plus loin, je crois qu'il m'est nécessaire de travailler un peu plus les concepts des bases de données. Je ne suis pas sur de bien comprendre le schéma envoyé et donc de répondre à la question "Le modèle suivant peut-il faire l'affaire ?" J'ai voulu aller sans doute un peu trop vite.

Désolé du bruit... Et merci de votre aide.

A bientôt
Laurent

[alassanediakite]

Salut
J'avais pas vu votre schéma. Je trouve que c'est très bien. A mon avis il faut juste enlever certaine tables.
Voyons le processus tel que le perçois.
1->La clinique crée un cahier de charge de l'enquête (les questions et analyse statistiques):

(de façon simpliste) un document word divisé en bordereau, paragraphe, question et réponses éventuelles aux questions

2->Ce document est imprimer pour servir de formulaire à remplir pendant l'enquête.
3->Vous créer une base à partir du cahier de charge. Juste le schéma, aucune donnée (ni du cahier, ni les résultats de l'enquête). Mais vous ajoutez dans les schéma la possibilité d'enregistrer les réponses recueillies et les identifiants de l'origine de la réponse (les éléments de la population étudiée):

(de façon simpliste) les tables bordereau, paragraphe, question, réponses éventuelles aux questions,identification et réponse.
A cela il faut ajouter les requêtes et les états pour les analyses statistiques

4->Le spécialiste responsable de l'enquête enregistre le cahier de charge dans la base.
5->Les agents de saisie enregistre les données de l'enquête (identification et réponse) dans la base.
A l'étape 3, vous avez votre base méta-données. Maintenant libre à vous de :

1. mettre toutes les études dans une seule base de données en ajoutant la table étude
2. utiliser une copie vide de la base pour chaque étude.

Alors, suis-je dans la bonne direction...
@+

[accessisgood]

Remarques:
> le type de reponse devrait etre un champ de la table MD_QUESTION, car a priori on peut anticiper dans la question le type de reponse attendue (oui/non, text...)
> si il n'y a qu'une seule reponse a la question, comme presente dans le modele, alors les tables MD_QUESTION et MD_REPONSE peuvent etre fusionnees
> je recommanderais d'eviter le champ Memo, car avec 250 char, le champ texte peut etre suffisant
> pareil pour le champ Num, sauf si on veut imposer un format

Piste pour eviter ces tables de meta-donnees:
> en creant un champ de chaque type dans la table MD_REPONSE: ReponseOuiNon, ReponseTexte, ReponseMemo, ReponseDate et ReponseNum, plus un Champ ReponseType (qui reprend le type de MD_QUESTION) et un champ Calcule Reponse qui reprend la valeur attendue en fonction de ReponseType

[laurent_42]

Bonjour à toutes et à tous,

Merci beaucoup pour vos dernières réponses.

Pour l'instant j'ai du mettre "un peu" en sourdine ce travail. Je n'ai donc pas pu étudier vos suggestions de près et encore moins les tester.

Je vous refais signe dès que je peux me redégager du temps pour ce projet.

Merci encore !

Bien à vous,
Laurent

[laurent_42]

Bonjour,

Me revoilà pour vous répondre mais malheureusement je n'ai pas eu l'occasion de retravailler à ce projet et donc de tester les solutions suggérées. Désolé de ce long silence qui ne marque en aucun cas un manque d'intérêt à vos réponses ou au projet.

@ alassanediakite :
Le processus est effectivement proche de ce que vous décrivez. En gros résumé (et au risque de me répéter... mais je ne suis pas sûr d'avoir réussi à me faire comprendre... Si vous avez compris le contexte, vous pouvez passer directement à la réponse à accessisgood) voici ce qu'il se passe en ce moment (et que j'aimerais modifier) :

1. A partir d'une idée d'un médecin un protocole de recherche est accepté
2. Sur la base de ce protocole, un cahier d'observation (CRF) est rédigé et validé. Il s'agit effectivement d'un document texte, divisé en bordereau. Chaque bordereau est lui même divisé en paragraphe. Dans chaque paragraphe on trouve les questions et les réponses possibles. Les seules réponses que l'on ne prévoit pas sont les réponses aux questions de type "Expliquez", "Autre cause, précisez", etc... Sinon les questions et les réponses sont du genre :
   Poids(kg) |_|_|_| (la réponse est donc un nombre entier à 3 chiffres)
   Anesthésie générale Oui(1)/non(0) (la réponse est donc 1 ou 0, 1 codant la réponse Oui et 0 la réponse Non. Evidemment dans le formulaire c'est oui ou non qui apparaissent, pas 1 ou 0)
   Date de la visite |_|_| |_|_| |_|_|_|_| (la réponse est donc une date sur le format JJ MM AAAA)
   Ce document est imprimé ou non, peu importe.
3. Je developpe une base pour la saisie des données de l'étude, en m'appuyant sur le CRF. Je fais même plus que m'appuyer : je crée finalement une version électronique du CRF en proposant en outre un contrôle de vraisemblance des données et en stockant les données saisies. La base représente uniquement l'étude en cours, pour laquelle elle a été développée. Je ne crée pas de table qui corresponde nécessairement à un bordereau, je ne crée pas de table paragraphe, etc... Je crée les tables nécessaires à l'étude et les formulaires qui reprennent rigoureusement le cahier d'observation papier. Au final la base remplace la version papier en évitant une étape de remplissage du formuaire papier ET une étape de saisie des données recueillies sur papier.
   Je prévois en outre l'extraction des données pour le jour où l'étude sera terminée.
4. L'étude se déroule ; les données sont saisies et enregistrées dans la base par des opérateurs. Ils ont devant eux la version électronique du cahier d'observation papier et remplissent directement la base.
5. En fin d'étude, quand les corrections nécessaires ont été apportées, la base de données est gelée et les statisticiens de l'équipe font leur travail d'analyse.

Vu qu'un cahier d'observation est un objet très structuré (toujours selon la même structure) et que le modèle conceptuel de la base d'une étude est le même d'une étude à l'autre (ou avec des modifications à la marge), je souhaiterais ne pas redévelopper à chaque fois une base (point 3). Surtout que les infos nécessaires ont toutes été saisies lorsque le cahier d'observation a été rédigé. Du coup j'ai l'impression de faire plusieurs fois le même travail. Donc mon idée est de saisir les informations du cahier d'observation une seule fois. Et à partir de cette saisie de "publier" un cahier d'observation dans un document texte (il nous faut impérativement une version texte) et de créer la base de données de l'étude : la base de données d'une étude c'est un nom de champ, une légende (dans mon cas la question du point 2), un type de champ avec les formats associés éventuels (i.e. la réponse du point 2), le nom de la table dans laquelle ce champ sera stocké et les relations entre les différentes tables. Finalement il s'agit de données que je peux structurer dans une base. C'est cette base que j'essaie de concevoir en ce moment et c'est la modélisation de mes questions et de mes réponses qui me posent problème. Au final, j'aimerais qu'à partir de cette base, le cahier d'observation soit "rédigé" automatique et la structure de la base créé aussi automatiquement (tables et champ définis, relation entre tables établies). Donc je veux une base contenant les données des bases des études, une méta-base de données.

Est-ce que je réussis à me faire comprendre sur mon besoin ??? J'espère !!!

@ accessisgood
Je crois que l'idée est dans votre réponse.

Tout d'abord, je comprends la remarque pour les champs mémo. Ils nous sont malheureusement nécessaire pour les questions de type "Décrire les symptômes".

Oui pour le champ numérique qui me permet de définir un format, ce qui déjà peut constituer un contrôle de la donnée saisie (type on rentre la taille en mètre alors que l'unité attendue est le centimètre).

Oui encore : le type de réponse est anticipé par la question ou le type de question. Oui toujours il n'y a qu'une réponse par question. Donc si je comprends bien, vous validez l'idée de fusionner les tables questions et réponses. Mais c'est là que je bloque. Est-ce que je fusionne toutes les tables MD_QUESTION, MD_REPONSE et les tables de types de réponse ?
En fait je ne comprends pas l'idée de votre dernier paragraphe :

Piste pour eviter ces tables de meta-donnees:
> en creant un champ de chaque type dans la table MD_REPONSE: ReponseOuiNon, ReponseTexte, ReponseMemo, ReponseDate et ReponseNum, plus un Champ ReponseType (qui reprend le type de MD_QUESTION) et un champ Calcule Reponse qui reprend la valeur attendue en fonction de ReponseType

OK pour le champ ReponseType qui fait le lien avec la table MD_QUESTION. Par contre je ne comprends pas les champs ReponseOuiNon, ReponseTexte, etc... ni le champ CalculeReponse. Le champ CalculeReponse est une espèce de champ calculé (comme son nom l'indique) qui crée à partir des infos fournies le texte de la réponse pour le document texte ? Mais que contiennent les champs ReponseOuiNon, etc ??? S'agit-il des liens vers les tables correspondantes ? Je suis "un peu" perdu...

Merci de vous être penché sur mon problème et de votre aide et désolé pour ce long silence indépendant de ma volonté.

Bien à vous,
Laurent

[alassanediakite]

Salut à vous

> si il n'y a qu'une seule reponse a la question, comme presente dans le modele, alors les tables MD_QUESTION et MD_REPONSE peuvent etre fusionnees

On ne peut en aucun cas fusionner les tables "question" et "reponse"! Pour cause, pour une méta-données de statistique (étude), deux tables modélise les réponses:

• listes des réponses possibles par questions
• réponse ou mesure de l'échantillon

Pour le cas d'un méta-données de questionnaire (évaluations de candidats), on à le choix entre...

• mettre la réponse dans la question (un champ de plus dans la table) et créer la tables de réponses à afficher par questions
• dans la table des réponses à afficher, ajouter le champ permettant de savoir les bonnes réponses

Je developpe une base pour la saisie des données de l'étude, en m'appuyant sur le CRF. Je fais même plus que m'appuyer : je crée finalement une version électronique du CRF en proposant en outre un contrôle de vraisemblance des données et en stockant les données saisies. La base représente uniquement l'étude en cours, pour laquelle elle a été développée.

C'est cela qui pose le problème...

Vu qu'un cahier d'observation est un objet très structuré (toujours selon la même structure) et que le modèle conceptuel de la base d'une étude est le même d'une étude à l'autre (ou avec des modifications à la marge), je souhaiterais ne pas redévelopper à chaque fois une base (point 3). Surtout que les infos nécessaires ont toutes été saisies lorsque le cahier d'observation a été rédigé. Du coup j'ai l'impression de faire plusieurs fois le même travail. Donc mon idée est de saisir les informations du cahier d'observation une seule fois.

Alors...

• Vous devez "juste" créer un logiciel d'étude à l'image de sphinx ou CS pro
• Les spécialistes du domaine d'étude créent l'étude dans ton logiciel et imprime les formulaires de saisie
• Les agents de saisies utilise cette étude pour saisir les réponses ou mesures des échantillons

@+
.

[alassanediakite]

Salut
J'oubliais

... Oui toujours il n'y a qu'une réponse par question.

Non!
Les questions du genre "Êtes-vous soumis à un régime? si oui lesquelles" ou "Quels langages maitrisez-vous?" peuvent avoir plusieurs réponses.
@+

[laurent_42]

Bonjour,

Et merci pour les réponses apportées.

Mais par contre soit je ne comprends rien à votre réponse soit j'ai l'impression qu'on ne parle pas du tout de la même chose.

Dans la base en question, on ne parle pas de statistique. Par contre de ce que je comprends de votre réponse, j'ai l'impression qu'on est plus proche de méta-données de questionnaire.

Et non je ne veux pas faire un outil qui couterait plusieurs milliers d'euro dans le commerce. Je n'en ai pas les compétences, ni le temps. Non je veux juste à partir d'un fichier de données créer un document texte et créer des tables. Mais au lieu de mettre mes données dans un tableur, je préférerais concevoir une base pour stocker ces données.

Non!
Les questions du genre "Êtes-vous soumis à un régime? si oui lesquelles" ou "Quels langages maitrisez-vous?" peuvent avoir plusieurs réponses.
@+

Ben non : promis, nos questions n'ont qu'une seule réponse. Les exclamations n'y changeront rien. J'en suis vraiment désolé.

Les règles de conception de questionnaire dans notre domaine recommandent très fortement (pour ne pas dire interdisent) des questions du genre "Quels langages maitrisez-vous ? Langage A, Langage B, Langage C". On les remplace par "Maitrisez-vous le langage A ? Oui/Non Le langage B ? Oui/Non Le langage C ? Oui/Non".
Un premier avantage est qu'il n'y a pas de code compliqué à mettre en oeuvre pour distinguer les différentes combinaisons de réponses (cf les codes des droits d'accès dans le monde *NIX). Et l'autre gros avantage c'est que l'on sait précisément de quoi il en retourne, l'information est plus complète : avec nos règles, si on n'a pas de réponse à Langage B c'est que la donnée est manquante. Avec une seule question et plusieurs réponses possibles (1er cas), si je n'ai pas d'info sur le langage B, j'ignore si c'est un oubli dans la réponse (donc donnée manquante) ou si la personne ne maitrise pas le langage B. Pour nous la différence est importante.

Reste les questions du genre "Préciser"/"Autre"/"Expliquer", etc..., en gros toutes les questions pour lesquelles il est illusoire voire erroné d'essayer d'établir une liste prédéfinie de réponses. Mais là encore je n'ai formellement, conceptuellement, qu'une seule réponse dans une seule variable, dans un seul champ qui est un texte ou un mémo (dans l'exemple donné). Evidemment le contenu du mémo varie (c'est précisément pour cette raison que nous n'avons pas établi de liste de réponses). Mais la donnée, le contenu est représenté par une seule variable. Je n'ai qu'une seule réponse à ma question. Avec une infinité de contenu.

Il en est de même d'ailleurs pour "Température" ou "Taille" ou "Hémoglobine" ou "Pression artérielle", etc... Je sais juste, pour reprendre l'exemple de la température, qu'elle est bornée et que si elle s'exprime en °C, elle est constituée de 3 chiffres dont une décimale. J'ai une seule réponse avec un grand nombre de possibilité.

Bonne journée,

Laurent

[alassanediakite]

OK
Désolé pour le temps perdu.
@+

[laurent_42]

Bonjour,

Je reviens avec mes questions sur la base de méta-données. Je n'ai pas abandonné le projet, j'ai essayé de faire murir tout ça en m'en éloignant un peu. Sans grand résultat...

Je pense que la réponse d'accessisgood va dans la bonne direction. Mais malheureusement je ne suis pas sur de comprendre sa réponse complètement... Des trucs m'échappent.

Le type de réponse est anticipé par la question ou le type de question. Et oui il n'y a qu'une réponse par question. OK pour la fusion des tables questions et réponses. Mais c'est là que je bloque. Est-ce que je fusionne toutes les tables MD_QUESTION, MD_REPONSE et les tables de types de réponse ?

En fait je ne comprends pas l'idée du dernier paragraphe :

Piste pour eviter ces tables de meta-donnees:
> en creant un champ de chaque type dans la table MD_REPONSE: ReponseOuiNon, ReponseTexte, ReponseMemo, ReponseDate et ReponseNum, plus un Champ ReponseType (qui reprend le type de MD_QUESTION) et un champ Calcule Reponse qui reprend la valeur attendue en fonction de ReponseType

OK pour le champ ReponseType qui fait le lien avec la table MD_QUESTION. Par contre je ne comprends pas les champs ReponseOuiNon, ReponseTexte, etc... ni le champ CalculeReponse. Le champ CalculeReponse est une espèce de champ calculé (comme son nom l'indique ???!!!) qui crée à partir des infos fournies le texte de la réponse pour le document texte ? Mais que contiennent les champs ReponseOuiNon, etc ??? S'agit-il des liens vers les tables correspondantes ? Je suis "un peu" perdu... et je fais difficilement le lien avec la 1ere partie de la réponse.

Si pour vous la réponse est claire, vos lumières me seraient d'un grand secours !!!

Merci d'avance et à bientôt

Laurent

[laurent_42]

Bonjour,

Grâce à l'aide du forum ALM/Modélisation/Schéma, je suis arrivé à un modèle pour mon besoin. Je me suis appuyé sur l'identification relative des types de réponse par rapport à une entité générique "Réponse" et la spécialisation de l'entité générique "Réponse" en réponse numérique, texte, heure, etc... Alors pour conclure la conversation à ce vieux sujet, je partage le modèle auquel j'ai abouti.

Merci encore à tous pour votre aide !

Laurent