Je fais le modèle conceptuel d'une base de données d'enquête.

Le but est de stocker les réponses données par les utilisateurs (ça va être une application Android).

J'ai trois entités: utilisateur, question et option.

Une question aura une ou plusieurs options (par exemple: combien d'employés avez-vous? 1-40, 40-1000, +1000).

Les options auront un texte (1-40) et une valeur (la valeur sélectionnée par l'utilisateur).

L'utilisateur sélectionnera une (ou plusieurs) de ces options.

Ma conception est:

Je ne sais pas comment associer une réponse à un utilisateur.

Comment puis-je représenter cette relation?
Ai-je une autre entité pour représenter la valeur de l'option?

Ce modèle stockera des questions et des réponses prédéfinies (réponses proposées) et leur permettra d'être réutilisées dans différentes enquêtes.

Je dois représenter une question comme celle-ci:

Cette question est liée à celle-ci: Conception de la base de données de l'enquête: première version. Y a-t-il des erreurs?

Vous devez faire une distinction entre les réponses possibles et les réponses sélectionnées .

La Optiontable doit être composée de deux tables. Le Optiontableau doit être de 1: M à Questionet doit inclure les réponses possibles à cette question.

Ensuite, vous devez créer une nouvelle entité d'intersection, appelez-la Selected_Optionqui se trouve entre Useret Option.

Si votre question donne à l'utilisateur la possibilité de remplir une valeur comme réponse (c'est-à-dire "AUTRE: ..."), cette valeur sera stockée dans le Selected_Optiontableau. Sinon, la valeur choisie par l'utilisateur serait la valeur trouvée dans Option.

ÉDITER:

Basé sur la clarification des exigences par OP: Ce dont vous avez besoin ne ressemble pas à un modèle de questionnaire typique des manières suivantes:

• Vos questions ont toutes les mêmes ensembles de réponses (colonnes)
• Certaines de vos réponses (colonnes) sont regroupées.
• Des blocs de questions sont regroupés.

Prenant votre instantané de formulaire comme guide, j'ai divisé les éléments de votre formulaire en entités que j'ai codées par couleur:

Cela pourrait être pris en charge par l'ERD logique suivant:

Notez que j'ai codé par couleur les entités dans l'ERD pour correspondre à l'instantané de votre exemple de formulaire pour montrer la corrélation.

L'une des hypothèses de ce modèle est que chaque bloc n'a qu'un seul ensemble de questions (c'est-à-dire une QUESTION_GROUP) qui correspond à la colonne de gauche du bloc. C'est un peu une hypothèse simplificatrice.

Schéma de la base de données d'enquête.

C'est un vrai classique, fait par des milliers. Ils semblent toujours «assez simples» au départ, mais pour être bon, c'est en fait assez complexe. Pour ce faire, dans Rails, j'utiliserais le modèle illustré dans le diagramme ci-joint. Je suis sûr que cela semble beaucoup plus compliqué pour certains, mais une fois que vous en avez construit quelques-uns, au fil des ans, vous vous rendez compte que la plupart des décisions de conception sont des modèles très classiques, mieux traités par une structure de données dynamique flexible au début.
Plus de détails ci-dessous:

Détails du tableau pour les tableaux clés

réponses

Le tableau des réponses est essentiel car il capture les réponses réelles des utilisateurs. Vous remarquerez que les réponses répondent aux liens vers les options de questions , pas les questions . C'est intentionnel.

types_entrée

types_entrée sont les types de questions. Chaque question ne peut être que d'un seul type, par exemple toutes les numérotations radio, tous les champs de texte, etc. option ou une telle combinaison. Étiquetez les deux questions dans la vue des utilisateurs comme une, mais en interne, vous avez deux questions, une pour les appels radio, une pour la case à cocher. La case à cocher aura un groupe de 1 dans ce cas.

groupes_options

option_groups et option_choices vous permettent de créer des groupes «communs». Par exemple, dans une demande immobilière, il pourrait y avoir la question «Quel âge a la propriété?». Les réponses peuvent être souhaitées dans les plages: 1-5 6-10 10-25 25-100 100+

Ensuite, par exemple, s'il y a une question sur l'âge de la propriété adjacente, alors l'enquête voudra «réutiliser» les plages ci-dessus, de sorte que le même groupe d'options et les mêmes options soient utilisés.

unités de mesure

units_of_measure est comme ça sonne. Que ce soit des pouces, des tasses, des pixels, des briques ou autre, vous pouvez le définir une fois ici.

FYI: Bien que de nature générique, on peut créer une application en plus de cela, et ce schéma est bien adapté au framework Ruby On Rails avec des conventions telles que "id" pour la clé primaire de chaque table. De plus, les relations sont toutes simples de one_to_many avec pas de traversées many_to_many ou has_many nécessaires. J'ajouterais probablement has_many: throughs et / ou: delegates pour obtenir des choses comme survey_name d'une réponse individuelle facilement sans.multiple.chaining.

Jetez un œil à cette idée générale:

(Seuls les champs les plus essentiels sont inclus dans le modèle ci-dessus, par souci de concision.)

Ce modèle présente les caractéristiques suivantes:

• Une même question peut être partagée entre plusieurs enquêtes (et une enquête unique, bien sûr, peut contenir plusieurs questions). SURVEY_QUESTION est la table "link" qui implémente cette relation M: N.
• L'ordre des questions dans l'enquête est déterminé par SURVEY_QUESTION.QUESTION_NO. Étant donné que {SURVEY_NO, QUESTION_NO} est une clé (alternative), indiquée U1dans le diagramme ci-dessus, deux questions ne peuvent pas occuper le même "créneau" dans la même enquête. Différentes enquêtes peuvent avoir les mêmes questions dans un ordre différent.
• Chaque question a une série de réponses ou "options" possibles. L'ordre visuel des options est déterminé par OPTION.OPTION_NO, et comme il est dans le PK, deux options ne peuvent pas occuper le même "slot" sous la même question.
• Différents utilisateurs peuvent fournir différentes réponses à la même question (et, bien sûr, un utilisateur peut répondre à plusieurs questions). Cette relation M: N est implémentée via la table "link" ANSWER.
• Un utilisateur répond à la question en choisissant au plus une de ses options. Ceci est assuré en excluant OPTION_NO du PK de la RÉPONSE. Si vous souhaitez autoriser l'utilisateur à sélectionner plusieurs options, incluez OPTION_NO dans le PK.

Il n'y a rien dans ce modèle de données qui oblige l'utilisateur à répondre à toutes les questions - c'est quelque chose que vous devrez faire au niveau de l'application. Néanmoins, ce modèle devrait être un bon début pour ce que vous devez faire ...

Vous aurez besoin d'un autre tableau pour contenir les réponses des utilisateurs.

user_answers
------------
  user_answer_id - clé primaire unique
  user_id - FK vers la table des utilisateurs
  selected_option_id - FK vers la table des options
  question_id - FK à la table des questions

Si vous décidez que vous voulez que les utilisateurs puissent sélectionner "Autre" comme option et remplir leur propre valeur, je recommanderais un tableau séparé pour cela:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - texte que l'utilisateur a entré pour une option "autre".
  user_answeR_id - FK vers la table user_answers

[Je ne peux pas encore commenter, donc ceci comme réponse]

Pour la solution présentée par VansFannel, j'y ai réalisé un modèle plus complet.

Veuillez le vérifier ici .