列部分確定另一列的接受值，應該以某種方式標準化嗎？
我有一個描述一組屬性的表（是的，它是元數據，在這種情況下，有充分的理由將它放在數據庫中）；除其他事項外，我會告訴可以分配給它們的數據類型（類型）和預設值。因此，預設值的有效值受 Type 列的限制，但預設值是表的真正屬性，它們不是由 Type 列唯一確定的。
不過，我不確定，這應該以某種方式規範化還是按原樣正確？
*編輯：*這裡是數據庫相關部分的目前結構的大致描述，根據要求。不要介意值表，這是一個單獨的問題。只需考慮 ValueType 限制了一組 DefaultValue 允許值。
另外，僅將此視為範例，我對一般問題感興趣，問題是列限制另一列的有效值集但不能確定其確切值，據我所知不構成多值依賴關係（但是，順便說一句，有一個強制執行限制的完整性約束會很有用——我不確定這個問題是否可以與前者分開）。
Properties ( ID int PRIMARY KEY Name varchar(100) ValueType int REFERENCES ValueTypes(ID) DefaultValue int REFERENCES Values(ID) ) ValueTypes ( ID int PRIMARY KEY Name varchar(100) ... ) Values ( ID int PRIMARY KEY ... )
下面我將通過高達 4NF 的規範化規則來採用這種結構。
我將假設您使用 properties.ID 作為代理鍵，並且 properties.Name 是有效的候選鍵。我的意思是，在實踐中，給定的“名稱”只會有 1 個值，例如通過創建唯一約束。
- 1NF：通過；所有值都是原子的
- 2NF：通過；候選鍵是 {ID} 和 {Name}；這些都不是複合鍵。
- 3NF：傳球；3NF 需要對非主要屬性的功能依賴，而且似乎沒有；有關類似問題，請參閱我對 3NF 的解釋。
- BCNF：通過；像 3NF 一樣，它需要對非主要屬性的功能依賴，並且沒有。
- 4NF：我將在下面詳細解釋 4NF。
4NF的規則是：
一個表在 4NF 中當且僅當，對於它的每一個非平凡的多值依賴 XY，X 是一個超鍵——也就是說，X 是一個候選鍵或其超集。
對於此表，您的超級鍵是 {ID}、{Name}、{ID, Name}、{ID, ValueType}、{ID, DefaultValue}、{Name, ValueType}、{Name, DefaultValue}、{ID, Name, ValueType}、{ID、Name、DefaultValue} 和 {ID、Name、ValueType、DefaultValue}。
ValueType 和 DefaultValue 是對 ID 和 Name 的多值依賴。但是，因為這兩個都是超級鍵，所以這個表仍然是 4NF。
因此，您的數據庫模式被標準化為 4NF。
評估設計的範式需要您向我們提供關係模式和適用的 FD。
此外，不要錯誤地認為“規範化”意味著“正確”。繞過引擎的類型系統，通常是為了最大限度地減少表的數量而被誤導，通常離“正確”還很遠。通常更傾向於採用完全錯誤的抽象。