第二范式的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。