3NF一对一关系争议

时间:2016-05-10 04:20:12

标签: database database-design database-normalization 3nf

尝试在3NF中设计时,我遇到了数据库问题。 3NF中的数据库具有以下特征: -it是第二范式。 - 它的表只包含非传递依赖于主键的列

我一直在网上看到很多人声称,如果你有一对一的关系,你应该强烈考虑分析为什么它不仅仅是一张桌子,但我对3NF的理解就是这样做。到目前为止,这是我的数据库: enter image description here 我试图在3NF中创建这个数据库,但到目前为止我不确定是否正确分割BOOK_STATS和BOOK_DETAILS表。我已经对它进行了分析,并确定文件类型和质量等内容完全不依赖于本书,因此我不得不将它们分开。这是正确的还是我需要更加深入地了解它们被分裂的原因?

1 个答案:

答案 0 :(得分:2)

将表拆分为多个具有相同主键的表既不违反任何正常形式,也不会治愈潜在的违规行为。通过考虑规范化尚未规范化的表所需的步骤,可以很容易地使这变得合理:所有这些方法都引入了具有与原始表不同的主键的表。因此,引入具有相同主键的表不能成为规范化步骤。

我属于声称1-1关系应被视为合并到一个表的分数,除非有很强的语义或物理原因将它们分开。但是,可能会询问有关您的book_details表格的以下问题:

  • " book"的概念可以指两件事:逻辑实体,即作者,标题,内容或物理实例。正如您的模型所示,文件中包含的书籍也有同样的区别。 Orwell的1984可能出现在多个文件中,一个质量好的PDF,以及一个平庸质量的epub,具有不同的文件大小。或者,大型图书可能会分成多个文件。我不知道你的模型和应用程序的目的,但我会尝试覆盖这样的现实世界现象,因为稍后添加它们会影响应用程序的大部分并且成本很高。所以我可以想象将你的book_detail表转换为与本书有1:n甚至m:n关系的media表。

  • 是否有file_qualityfile_type的预定义值范围,例如"优秀,优秀,平庸,糟糕"," pdf,epub, txt,..."?在这种情况下,这些值应该是另一个表的一部分,而您的bookbook_detail只会将该表中的ID作为外键包含。