第二范式的ER模式

Question

我对我的ER模式和第二种正常形式的表有疑问。 该表的属性取决于另一个属性，我不知道这是否会导致规范化问题。

表结构如下：

| contract_id | start_date | end_date |

主键是* contract_id *。 问题是* end_date *的值正好是* start_date *之后的1年。

行示例：

| 1 | 2013-01-01 | 2014-01-01 |
| 2 | 2012-02-03 | 2013-02-03 |

该表是2NF版本吗？

Answer 1

我不明白为什么它不应该是2NF。 为了保留2NF，在复合/复合主键中的任何列上都不应部分依赖（这里不是这种情况）。

您的问题很可能是3NF的问题。

Answer 2

它不受2NF或3NF的保护，但是此模型违反了Domain / Key正常形式。 如果间隔始终为一年，则只需删除一个属性，或添加检查约束。
例如CHECK（end_date-start_date = 365），365是会计年度，日历年不是常数。

Answer 3

同一行中其他列的计算列违反3-NF 。 有人会告诉您不要将计算所得的列存储在数据库中以符合3-NF的要求，这对于当前模型确实有效。 但是，您必须评估这是否对您的业务有效。 假设在3个月的时间内，业务规则发生了变化，并且end_date不再等于start_date + 1年，那么您会怎么做？

Answer 4

可以说它不是2NF（大概start_date是唯一的），但不是3NF，因为您可以使用表达式

adddate(start_date, interval 1 year)

或者最好用end_date作为此表达式创建一个视图。

您还必须问自己有关数据完整性的问题：如果由于同样的错误，结束日期不晚于开始日期，则数据库会发生什么变化？ 如果计算了结束日期，则不可能出现这种情况-内置了数据完整性。

如果结束日期是一个单独的列，则应检查这些列的每次插入和更新的正确性，这会增加工作量并可能会导致更多错误。

最后，如果没有存储结束日期，则每一行都将较小，这将带来较小的性能提升，尽管该收益可能微不足道。

Answer 5

不会违反2NF，但会违反3NF。 您无需在数据库中存储带算字段。 也就是说，您也不具备计算数据库中值所需的所有信息。 我将如上所述删除end_date ，但会添加一个contract_term字段。 现在，它们都是1年或12个月，或者不管您选择计算它，而不是在将来可能发生变化的情况下，现在都很容易做到。 那么即使业务需求发生变化，您也将能够如实地计算到期日期，而且您无需存储计算字段。 同样，由于contract_term描述的是您未违反2NF或3NF的实体。

Answer 6

如果start_date-> end_date和end_date-> start_date，则（start_date，end_date）不是候选键，因为该组合不是最小的超键。 因此满足2NF，因为任何候选密钥的正确子集都不是决定因素。

3NF意味着对于您需要满足的每个依赖关系，行列式是超键，或者依赖属性是候选键的一部分。 因此，相关的问题是start_date和end_date是否都是候选键。 当且仅当它们满足时，才满足3NF。 如果start_date和end_date是非质数（不是候选键），则表满足2NF，但不满足3NF。