我正在为一个电子学习平台创建一个消息传递系统，有一些设计问题我希望得到一些反馈。
首先，对我和我的系统来说， future 高度可修改是很重要的。因此，在我的表中保持相当高的规范化很重要。
关于我的系统将如何工作:
- 所有成员(学生或教师)都是虚拟教室的一部分。
- 教师可以在这些教室中创建任务和练习，并将它们分配给一个或多个学生(
member_task表未说明)。 - 学生可以通过向类教师发送消息来请求特定任务或练习的帮助。
- 学生发送的消息会发送给所有教师。他们无法向特定教师发送消息。
- 教师发送的消息可以发送给一名或多名学生。
- 学生不能向其他学生发送消息。
- 消息的行为类似于聊天，这意味着学生和所有教师在发送消息时会开始私有(private)对话。
这是我制作的 ER 图:
所以我的问题是，此表是否已针对我的目的进行了适当的规范化？有什么办法可以减少表中的数据冗余吗？出于好奇，它在 BCNF 中吗？
另一个问题:我不打算在我的系统中的任何地方实现删除功能。仅在所述教室/任务/成员/消息/任何被隐藏/停用的地方“存档”。那么有什么理由实际使用 FK 吗？
编辑:另外，一位 friend 提醒我，Conversations 表可能是多余的，我感觉是这样。想法？
谢谢。
最佳答案
为了回应您对“可修改性”的强调，我认为这是关于应用程序和模式演变的意思，我实际上将提出一个相当极端的解决方案。在此之前，请注意您提到的某些方面。首先，外键代表数据中有意义的约束。它们应该始终被定义和执行。外键不仅仅用于级联删除。其次，Conversations 表可以说是多余的。如果您有一个与对话相对应的聊天“ session ”概念，那将是有意义的。否则，您只会在整个时间内收到一堆消息。例如，如果您想要同时涵盖多个练习的聊天，Conversation 表还可以在消息和任务/练习之间启用多对多关系。
现在是极端的建议。你可以使用 6NF。特别是，您可能会在 anchor modeling 中查看它的化身。 .这种方法最显着的区别是每个属性都被建模为不同的表。 6NF 支持时态数据库(通过“历史化”属性/联系在 anchor 建模中得到支持)。这意味着处理诸如学生现在与任务相关联但以后不会导致他们所有消息消失的情况。与您最相关的是，所有架构修改都是非破坏性和附加的，因此在您进行更改时不会破坏旧代码。
有缺点。首先，它有点奇怪，特别是锚定建模(有点无缘无故？)引入了一堆新术语。其次，它会为大多数关系数据库生成奇怪的查询，而这些查询可能无法很好地优化。这有时可以通过物化 View 来解决。第三，在物理层面，每个属性实际上都可以为空。最后，工具和支持虽然存在，但还很年轻。特别是对于 MySQL，您可能只会从锚定建模站点上提供的内容中获得“启发”。
就实际的数据库模型而言，它看起来大致相似。 anchor 建模使用术语“ anchor ”来表示与实体大致相同的事物，而使用“联系”来表示与关系大致相同的事物。为简单起见，删除 Conversation 关系(从而直接将 Message 连接到 Task)，图像将是相似的:您将有一个 Classroom、Member、Message 和 Task 的 anchor ，以及一个替换 Recipient 的领带，您可以称之为 ReceivedMessage 代表“成员收到消息消息”的关系。您的实体上的属性将是属性节点。使消息 anchor 上的消息属性历史化将允许在需要时编辑消息并支持修订历史。
关于mysql - 数据库设计和规范化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34918443/