計算列是否會破壞 3NF（第三範式）？

根據我對 3NF 的理解，不應該有任何傳遞依賴。

但是，這是我從AdventureWorks2012數據庫Production.WorkOrder表中找到的。由於StockedQtyis 依賴於OrderQtyand ScrappedQty，因此該表中存在傳遞依賴關係，對嗎？

上述表格的 DDL 如下：

CREATE TABLE [Production].[WorkOrder](
       [WorkOrderID] [int] IDENTITY(1,1) NOT NULL,
       [ProductID] [int] NOT NULL,
       [OrderQty] [int] NOT NULL,
       [StockedQty]  AS (isnull([OrderQty]-[ScrappedQty],(0))),
       [ScrappedQty] [smallint] NOT NULL,
       [StartDate] [datetime] NOT NULL,
       [EndDate] [datetime] NULL,
       [DueDate] [datetime] NOT NULL,
       [ScrapReasonID] [smallint] NULL,
       [ModifiedDate] [datetime] NOT NULL,
    CONSTRAINT [PK_WorkOrder_WorkOrderID] PRIMARY KEY CLUSTERED 
   (
       [WorkOrderID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   ) ON [PRIMARY]

我的問題是：

1. 考慮到使用者不能手動更新這樣的列，計算列實際上是否違反了 3NF？
2. 如果它確實違反了 3NF，那麼為什麼上面的範例中顯示了計算列？
3. 忽略計算列是否違反3NF的因素，查詢時在計算列與計算之間選擇的度量標準是什麼？

計算列不是關係模型的構造，因此嘗試使用 3NF 等關係模型術語評估它們是沒有意義的。計算列是一些供應商添加的對 SQL 的專有擴展，並且由於它們不是邏輯儲存的（儘管您可能會物理地保存它們），它們不是元組的一部分，因為它們不是關係的屬性，而是基於某些表達式在上面。

順便說一句 - 如果這是您在 AdventureWorks 和大多數其他範例數據庫中發現的唯一建模缺陷，請仔細查看:-)

高溫高壓

引用自：https://dba.stackexchange.com/questions/247095