Question

我刚刚阅读了@ PerformanceDBA的论点：6NF和E-A-V。我很好奇。我以前对6NF持怀疑态度，因为它只是“仅仅”在表格上粘贴了一些时间戳列。

我一直使用数据字典，不需要被说服使用数据字典，也不需要生成SQL代码。所以我希望答案需要一个用于生成代码的字典（或目录）。

所以我想知道6NF如何处理一个极其简单的例子。项目，描述和价格表。价格随时间而变化。

无论如何，在转换为6NF时，Items表是什么样的？什么是“桌子爆炸？”发生在这里？

如果这个示例不适用于这个简单的表格，请随意添加必要的内容。

Answer 1

简而言之，6NF意味着每个关系都包含一个候选键加上不超过一个其他（键或非键）属性。举个例子，如果ProductCode标识了“item”，而其他属性是Description和Price，则6NF模式将包含两个关系（*表示每个关键字）：

ItemDesc {ProductCode*, Description}
ItemPrice {ProductCode*, Price}

这可能是一种非常灵活的方法，因为它可以最大限度地减少依赖关系。这也是它的主要缺点，特别是在SQL数据库中。 SQL使得强制执行许多多表约束变得困难或不可能。使用上述模式，在大多数情况下，将无法强制执行每个产品必须始终具有描述和价格的业务规则。同样，您可能无法强制执行一些应该应用的复合键（因为它们的属性可以拆分为多个表）。

因此，在考虑6NF时，您必须权衡哪些依赖关系和完整性规则对您很重要。在许多情况下，您可能会发现坚持使用5NF更加实用和有用，并且不会超过标准化。

Answer 2

我以前对6NF持怀疑态度因为它被呈现为“仅仅” 坚持一些时间戳列表。

我不太清楚这种明显的误解来自哪里。也许6NF是由Date，Darwen和Lorentzos的“时间数据和关系模式”一书引入的？无论如何，我希望这里的其他答案已经澄清，6NF不仅限于时态数据库。

我想说的是，尽管6NF“在学术上是可敬的”并且总是可以实现的，但它可能不一定导致每种情况下的最佳设计（而不仅仅是在考虑使用SQL的实现时）。甚至上述6NF的发现者和支持者似乎都同意，例如

Chris Date：“出于实际目的，坚持5NF（和6NF）。”

Hugh Darwen：“围绕日期的6NF分解[不是这个人！]会有点过分......足球俱乐部的最佳设计是...... 5-and-bit-NF！”< / p>

Hugh Darwen：“我们在5NF但不在6NF，5NF就足够了”（几个类似的例子）。

然后，我也可以找到相反的证据：

Chris Date：“Darwen和我有一段时间都觉得所有基础重新武装都应该在6NF”。

实际上，我最近扩展了我们其中一个产品的SQL架构，以添加一个次要功能。我采用了一个6NF来避免可空列，最后得到六个新表，其中大多数（所有？）我的同事会使用一个可以为空的列的表（或者可能扩展现有的表）。尽管我证明了几个“助手”存储过程和一个带有VIEW触发器的“非规范化”INSTEAD OF，但每个必须在SQL级别使用此功能的编码器都已经不用诅咒我：）

Answer 3

这些家伙把它弄下来了：Anchor Modeling。关于这一主题的优秀学术论文，结合实际案例。他们的着作最终促使我考虑在即将开展的项目中在6nf中建立一个DW。我所做的POC工作已经验证（至少对我来说）6nf的巨大好处不会超过成本。

想用一个例子来理解6NF

4 个答案: