问卷解密数据库ER图
Deciphering Database ER Diagram for questionnaire
我正在尝试破译我的一位老师帮助我制作的数据库 ER 图。我主要是想弄清楚如何构建所需的 table 并正确组合它们。
有问题的 ER 图是针对在线问卷的，其中每个问题都基于前一个问题的答案，最终导致 solution/ending。
每个问题都可以有多个答案，同一个问题可以有多个不同的答案，具体取决于前面给出的答案。
组合 table 显示哪些答案与哪个问题相关联，以及下一个问题应该是什么，如果给出特定答案，最终会得出解决方案。
ER 图如下所示：
不明白的地方：
解决方案/问题 table 将包含问题和解决方案，它们可以有不同的实体，但我不明白这是如何完成的？ D是什么？
通往的是一个交汇点table，因为它是答案和[=31=之间的多对多连接]问题/解决方案，但为什么呢？ Combinationtable中没有连接吗？ - table 是否包含了解哪些答案与哪个问题相关以及如果选择了特定答案接下来将出现哪个问题所需的所有信息？
我很难弄清楚如何构建此数据库以使其按需要工作。
您的图表不是正确的 ER 图。特别是，带有 "Specific solution entities here" 和 "Specific question entities here" 的椭圆似乎并不分别表示 Solution 和 Question 的属性。这意味着 Question、Solution 和 Question/Solution 没有任何属性。此外，Combination 实体具有 Answer ID 和 Question/Solution ID 作为属性，而不是与相关实体相关。
让我们快速回顾一下 ER 图的元素。
- 矩形表示实体，椭圆表示属性。
- 带下划线的椭圆形标签表示属性是标识实体的主键的一部分。
- 钻石表示关系。
- 关系由它们相关的实体的关键属性标识。
- 关系也可以有属性。
- 包含
d 或 o 的圆表示不相交或重叠的子类型关系。
根据您的要求，我提出了以下函数和多值依赖项：
- 问题 ID -> 问题文本
- AnswerID -> AnswerText
- AnswerID -> QuestionID（可能的答案）
- 决策 ID -> 问题 ID
- DecisionID ->> AnswerID（可用答案）
- DecisionID、AnswerID -> NextDecisionID
基于此，我建议使用以下 ER 图：
转换为表格模型（我使用相同的行列式对关系进行非规范化，这就是为什么 PossibleAnswers 和 DecisionQuestion 没有 table 的原因）：
使用它，您可以描述任意数量的问题路径，并为每个决定提供一组可用的答案，并参考下一个。解决方案未明确建模，而是没有 NextDecisionID 的 AvailableAnswer 表示解决方案。
我正在尝试破译我的一位老师帮助我制作的数据库 ER 图。我主要是想弄清楚如何构建所需的 table 并正确组合它们。
有问题的 ER 图是针对在线问卷的，其中每个问题都基于前一个问题的答案，最终导致 solution/ending。
每个问题都可以有多个答案，同一个问题可以有多个不同的答案，具体取决于前面给出的答案。
组合 table 显示哪些答案与哪个问题相关联，以及下一个问题应该是什么，如果给出特定答案，最终会得出解决方案。
ER 图如下所示：
不明白的地方：
解决方案/问题 table 将包含问题和解决方案，它们可以有不同的实体，但我不明白这是如何完成的？ D是什么？
通往的是一个交汇点table，因为它是答案和[=31=之间的多对多连接]问题/解决方案，但为什么呢？ Combinationtable中没有连接吗？ - table 是否包含了解哪些答案与哪个问题相关以及如果选择了特定答案接下来将出现哪个问题所需的所有信息？
我很难弄清楚如何构建此数据库以使其按需要工作。
您的图表不是正确的 ER 图。特别是，带有 "Specific solution entities here" 和 "Specific question entities here" 的椭圆似乎并不分别表示 Solution 和 Question 的属性。这意味着 Question、Solution 和 Question/Solution 没有任何属性。此外，Combination 实体具有 Answer ID 和 Question/Solution ID 作为属性，而不是与相关实体相关。
让我们快速回顾一下 ER 图的元素。
- 矩形表示实体，椭圆表示属性。
- 带下划线的椭圆形标签表示属性是标识实体的主键的一部分。
- 钻石表示关系。
- 关系由它们相关的实体的关键属性标识。
- 关系也可以有属性。
- 包含
d或o的圆表示不相交或重叠的子类型关系。
根据您的要求，我提出了以下函数和多值依赖项：
- 问题 ID -> 问题文本
- AnswerID -> AnswerText
- AnswerID -> QuestionID（可能的答案）
- 决策 ID -> 问题 ID
- DecisionID ->> AnswerID（可用答案）
- DecisionID、AnswerID -> NextDecisionID
基于此，我建议使用以下 ER 图：
转换为表格模型（我使用相同的行列式对关系进行非规范化，这就是为什么 PossibleAnswers 和 DecisionQuestion 没有 table 的原因）：
使用它，您可以描述任意数量的问题路径，并为每个决定提供一组可用的答案，并参考下一个。解决方案未明确建模，而是没有 NextDecisionID 的 AvailableAnswer 表示解决方案。