Mysql 第二范式的E-R模式

我对我的E-R模式和第二范式中的表有疑问。 该表有一个依赖于另一个属性的属性，我不知道 这会导致规范化出现问题

表结构如下所示：

| contract_id | start_date | end_date |

主键是*contract\u id*。 问题是*end\u date*的值正好在*start\u date*之后1年

行示例：

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

---

这个表是2NF吗？

我不明白为什么它不应该是2NF。 对于2NF，不应该对复合/复合主键中的任何列存在部分依赖关系（这里不是这种情况）

---

您的问题更可能是3NF关注的问题。

2NF或3NF未涵盖此问题，但此模型违反了域/密钥范式。如果间隔始终为一年，只需删除其中一个属性，或添加检查约束。

---

e、 g.检查（结束日期-开始日期=365），365是财政年度，日历年不是常数

来自同一行中其他列的计算列冲突。有些人会告诉您不要将计算列存储在数据库中，以符合3-NF的要求，这对于当前的模型确实有效。但是，您必须评估这是否适用于您的业务。假设在3个月后，业务规则发生变化，并且结束日期不再等于开始日期+1年，您会怎么做？

可以说它不是2NF（假定

开始日期是唯一的），但它不是3NF，因为您可以使用表达式

adddate(start_date, interval 1 year)

或者最好创建一个带有
end\u date
的视图

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

如果结束日期是一个单独的列，那么应该检查这些列的每次插入和更新的正确性，这将需要更多的工作，并且可能会有更多的bug

最后，如果未存储结束日期，则每一行都将变小，这将提供较小的性能增益，尽管增益可能微不足道。
这不会违反2NF，但会违反3NF。您不需要在数据库中存储置换字段。也就是说，您也没有计算数据库中的值所需的所有信息。如上所述，我会删除
结束日期
，但我会添加一个
合同期限
字段。现在很容易做到，因为它们都是1年或12个月，或者按照您选择的方式计算，而不是在将来它们可能会改变。然后，即使业务需要更改，您也可以忠实地计算过期日期，而且您没有存储计算字段。另外，由于
contract\u term
描述了您没有违反2NF或3NF的实体。
如果开始日期->结束日期和结束日期->开始日期，那么（开始日期，结束日期）就不是候选键，因为该组合不会是最小超键。因此，满足2NF，因为任何候选密钥的适当子集都不是行列式

3NF意味着对于需要满足的每个依赖项，行列式是一个超级键，或者依赖属性是候选键的一部分。因此，相关的问题是开始日期和结束日期是否都是候选键。当且仅当它们满足时，则满足3NF。如果开始日期和结束日期是非优先键（不是候选键），那么您的表满足2NF而不是3NF。
谢谢您的回答。是的，我知道这可能是一个3NF问题，但我也怀疑2NF。那么，3NF呢？是的，间隔总是一年，有一个触发器来检查它。它是一个业务规则，因此可以更改，并且有可能删除该规则。这就是我保留这两个属性的原因。我认为从开始日期计算结束日期更好，但存储其他约束的间隔是有意义的。如果规则更改，我将编辑检查它的触发器。但是如果规则被删除，并且没有更多的功能依赖性，我需要end_date属性。我的观点是，您应该评估添加一个新列将如何影响您的系统可用性、重新开发成本、测试等。在这种情况下，我现在就添加该列（除非您看到尚未提及的真正危害）.有一些触发器检查数据的正确性，我知道这意味着更多的工作和错误。问题是：如果规则被删除，我需要end_date属性，该怎么办？谢谢，也许这是最好的解决方案。