是否允许在第三范式(3NF)中使用“子”表的函数依赖？

Question

考虑两个简单的表，OrderHeader和OrderDetail，它们分别包含如下所示的数据：

OrderHeader

| OrderHeaderID | CustomerID | OrderTotal |
|---------------|------------|------------|
| 1             | 124        | 14.5       | 
| 2             | 525        | 35.6       |
| etc           |            |            |

OrderDetail

| OrderDetailID | OrderHeaderID | ProductID |
|---------------|---------------|-----------|
| 1             | 1             | 415       |
| 2             | 1             | 52        |
| etc           |               |           |

OrderTotal列可以通过从OrderDetail表中添加每个产品的价格来计算。这听起来像是功能性依赖！ie：

• SUM(OrderDetail.Product.Price) → OrderHeader.OrderTotal

...but afaik这不是违反3NF。

这真的允许吗？如果是，它是否不允许在更高的标准形式？

Answer 1

有一个非正式的依赖，但它不是一个功能依赖。有关形式定义，请参见wiki文章。以下是一个简单的摘录：

简单地说，如果x属性的值是已知的(假设它们是x)，那么与x对应的Y属性的值可以通过在包含x的任何R元组中查找它们来确定。

没有正常的表单定义，无法对父记录中的子记录值进行汇总。然而，很多人会建议不要在事务性数据库中这样做，特别是当一个子记录可能被更新(或者删除，或者添加了更多的子记录)时，这样做可能会导致父级属性与子记录的总价值不一致。

如果您的OrderHeader表有一个CustomerName列，那么由于传递函数依赖于CustomerID，这将违反3NF。

许多人会说OrderTotal是非正式的，因为它容易受到类似插入、更新和删除异常的影响，因此人们会将其与规范化和普通形式的正式定义进行比较(因为这也是为了避免insert/ update /delete异常)。不过，也有一些粘贴者坚持认为，避免父记录中的摘要属性与规范化本身并不是一回事。