我已经阅读过其他问题：
Is it fine to have foreign key as primary key?
Primary and Foreign Key at the same time
然而，在我看来，答案是完全不同的，并且答案是否可以将密钥设为主要和外来取决于具体数据库和包含密钥的表的目的。
这是作为考试项目的一部分完成的，我必须能够解释我的数据库设计或者为我的演示提出其他的东西。
我的问题是：
您如何最好地证明我的数据库中的“selected_answers”表格？即它有意义吗？
是否还处于第3范式？
在实现当前表的相同目的和功能的同时，我可以使它变得与众不同吗？
这是我目前的关系模型：
这是我当前的SQL表脚本：
我们的想法是创建一个数据库，该数据库可以将“审计”数据存储在想要审核他们遵守GDPR的公司的情况。这是考试的作业。
我有“选择答案”的原因是我可以将用户的选定答案与提出的问题进行比较。
密钥既是主密钥又是外键，因此数字是“唯一的”，同时仍然引用审计和问题表。
数据库也应该能够单独存储每个审核及其答案。
对于更多上下文，我用“测试数据”填充了我的表，以便我可以使用存储的触发器，过程和函数。
所有问题都预先设置为question_ID 1 - 12，所有答案均为answer_ID 1-5。 所以这些数字肯定会重复，但是为了存储审计和回答的内容。
这是数据库计算的最终结果： 公司名称和注册号（CVR - 丹麦语），审核时间（通过存储的触发器更新），答案的平均分数和基于平均分数的“合规水平”。
我希望我已经提供了足够的信息来帮助我:-)如果你还需要查看存储过程，函数和触发器告诉我，我会上传它们。
答案 0 :(得分：0)
你的桌子很有意义。您可以将其视为审计和问题之间的多对多关系（每个审计可以回答许多问题;每个问题都可以在许多审计中得到解答），其中一个属性指示审计对问题的答案是什么，受限制（通过答案表的外键）是许多预定义答案之一。我还建议你写下relvar谓词，看看它们是否有意义。
它在3NF，除非你没有告诉我们有奇怪的功能依赖（FD）。似乎有一个非平凡的FD，{Audit_ID, Answer_ID} -> {Answer_ID}，左侧是一个超级钥匙（实际上是一个关键），所以该表是Boyce-Codd的正常形式，这意味着3NF。 （我真的不知道为什么人们在有BCNF时会为3NF而烦恼。）
我想不出任何满足相同要求的简单解决方案。由于使用代理键和缺少自然键，您的设计可能会出现问题，但这是一个不同的问题。
