我正在为调查数据库做概念模型。

目标是存储用户给出的答案（这将是一个Android应用程序）。

我有三个实体：用户，问题和选项。

一个问题将有一个或多个选项（例如：您有多少名员工？ 1-40，40-1000，+1000）。

选项将包含一个文本（1-40）和一个值（用户选择的值）。

用户将选择一个（或多个）这些选项。

我的概念设计是：

我不知道如何将答案与用户相关联。

我如何代表这种关系？
我是否有另一个实体代表期权价值？

该模型将存储问题和预制答案（提供的答案），并允许它们在不同的调查中重复使用。

我必须代表这样的问题：

这个问题与此有关：调查数据库设计：第一个版本。有错误吗？

您需要区分可能的答案和所选的答案。

该Option表必须是两个表。该Option表应为1：M，Question并应包括该问题的可能答案。

然后，您需要创建一个新的相交实体，将其命名为Selected_Option位于User和之间Option。

如果您的问题使用户有机会填写一个值作为答案（即“ OTHER：...”），则该值将存储在Selected_Option表中。否则，用户选择的值将是中的值Option。

编辑：

根据OP对要求的说明：在以下方面，您需要的不是典型的问卷模型：

• 您的所有问题都有相同的答案（列）
• 您的某些答案（列）被组合在一起。
• 问题块组合在一起。

以您的表单快照为指南，我将表单的元素划分为使用颜色编码的实体：

以下逻辑ERD可解决此问题：

请注意，我已经对ERD中的实体进行了颜色编码，以与示例表单的快照相对应以显示相关性。

此模型中的一个假设是，每个块只有一组问子（即一个QUESTION_GROUP），与该块的左列相对应。这是一个简化的假设。

调查数据库架构。

这是成千上万的经典作品。从一开始，它们似乎总是“非常简单”，但是要好，实际上它非常复杂。为此，我将使用附图中显示的模型。我敢肯定，对于某些人来说，这似乎过于复杂，但是多年来，一旦您构建了其中的一些，您就会意识到，大多数设计决策都是非常经典的模式，最好通过解决方案中的动态灵活数据结构来解决。开始。
以下是更多详细信息：

关键表的表详细信息

答案

该答案表是至关重要的，因为它抓住了用户的实际响应。您会注意到，答案链接到question_options，而不是问题。这是故意的。

input_types

input_types是问题的类型。每个问题只能是一种类型，例如所有的无线电拨号盘，所有的文本字段等。对于（例如）有5个无线电拨号和1个“包括”复选框，请使用其他问题。选项或此类组合。在用户视图中将两个问题标记为一个，但在内部有两个问题，一个是无线电拨号，一个是复选框。在这种情况下，该复选框的组为1。

option_groups

使用option_groups和option_choices可以构建“公用”组。举一个例子，在房地产应用中，可能会有一个问题：“该物业有多老？”。可能需要以下范围的答案：1-5 6-10 10-25 25-100 100+

然后，例如，如果对相邻物业的年龄存在疑问，则调查将要“重用”上述范围，以便使用相同的option_group和options。

度量单位

听起来像是units_of_measure。无论是英寸，杯子，像素，砖头还是其他，您都可以在此处定义一次。

仅供参考：尽管本质上是通用的，但可以在此基础上创建一个应用程序，并且该模式非常适合Ruby On Rails框架，其约定为每个表的主键使用“ id”之类的约定。而且，这些关系都是简单的one_to_many的关系，不需要many_to_many或has_many贯穿。我可能会添加has_many：throughs和/或：delegates，以便在没有.multiple.chaining的情况下轻松地从单个答案中获取诸如Survey_name之类的信息。

看一看这个总体思路：

（为简便起见，以上模型仅包含最重要的字段。）

该模型具有以下特征：

• 一个问题可以在多个调查中共享（当然，一个调查可以包含多个问题）。SURVEY_QUESTION是实现此M：N关系的“链接”表。
• 调查中问题的顺序由SURVEY_QUESTION.QUESTION_NO确定。由于{SURVEY_NO，QUESTION_NO}是一个（备用）键，U1如上图所示，因此在同一调查中没有两个问题可以占据相同的“位置”。不同的调查可以以不同的顺序提出相同的问题。
• 每个问题都有一系列可能的答案或“选项”。选项的视觉顺序由OPTION.OPTION_NO确定，并且由于它在PK中，因此在同一问题下，没有两个选项可以占据相同的“插槽”。
• 不同的用户可以对同一问题提供不同的答案（当然，一个用户可以回答多个问题）。通过“链接”表ANSWER实现此M：N关系。
• 用户最多选择一个选项来回答问题。通过从ANSWER的PK中排除 OPTION_NO 可以确保这一点。如果要允许用户选择多个选项，请在PK中包含OPTION_NO。

该数据模型中没有任何内容可以迫使用户回答所有问题-这是您需要在应用程序级别执行的操作。但是，此模型应该是您需要做的一个良好的开始。

您将需要另一个表来保存用户的答案。

user_answers
------------
  user_answer_id-唯一主键
  user_id-FK到用户表
  selected_option_id-FK到选项表
  question_id-FK到问题表

如果您决定希望用户能够选择“其他”作为选项并填写自己的值，那么我建议为此使用一个单独的表：

user_alt_answers
----------------
  user_alt_answer_id-PK
  alt_answer_text-用户为“其他”选项输入的文本。
  user_answeR_id-FK到user_answers表

[我还不能发表评论，因此这是一个答案]

对于VansFannel提出的解决方案，我在那里做了一个更完整的模型。

请在这里检查。