我对我的 E-R 模式和第二范式中的表有疑问。 该表有一个依赖于另一个的属性，我不知道是否 这会导致标准化出现问题。
表结构是这样的：
| 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 中吗？
【问题讨论】：
标签： mysql database entity-relationship normalization database-normalization
我不明白为什么它不应该是 2NF。 要保持 2NF，不应部分依赖复合/复合主键中的任何列（此处不是这种情况）。
您的问题更可能是 3NF 的问题。
【讨论】：
2NF 或 3NF 没有涵盖它，但该模型违反了域/密钥范式。如果间隔始终为一年，则只需删除一个属性或添加检查约束。
例如CHECK (end_date - start_date = 365)，365 是财政年度，日历年不是一个常数。
【讨论】：
同一行中其他列的计算列违反了3-NF。有些人会告诉您不要将计算的列存储在数据库中以符合 3-NF，这对于 current 模型确实有效。但是，您必须评估这是否对您的业务有效。假设3个月后，业务规则发生变化，end_date不再等于start_date+1年，你会怎么做？
【讨论】：
可以说它不是 2NF（大概start_date 是唯一的），但它不是 3NF，因为你可以使用表达式
adddate(start_date, interval 1 year)
或者最好用end_date作为这个表达式来创建一个视图。
您还必须问自己有关数据完整性的问题：如果由于同样的错误您的结束日期不是开始日期后一年，您的数据库会发生什么？如果计算了结束日期，那么这种情况是不可能的 - 您将获得内置的数据完整性。
如果结束日期是一个单独的列，则应检查这些列的每次插入和更新的正确性，这是更多的工作并且可能存在更多的错误。
最后，如果不存储结束日期，每一行都会变小，这会带来很小的性能提升，尽管提升可能微不足道。
【讨论】：
这不违反 2NF，但它确实违反了 3NF。您不需要在数据库中存储计算字段。话虽如此，您也没有计算数据库中的值所需的所有信息。如上所述，我会删除end_date，但我会添加一个contract_term 字段。现在很容易做到，因为它们都是 1 年或 12 个月，或者您选择如何计算它，而不是将来它们可能会改变。那么即使业务需求发生变化，您也将能够忠实地计算到期日期，而且您没有存储计算字段。另外，由于contract_term 描述了您没有违反 2NF 或 3NF 的实体。
【讨论】：
如果 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。
【讨论】：