web-dev-qa-db-ja.com

計算カラムは3NF（第3正規形）を壊しますか？

私の3NFの理解から、推移的な依存関係はないはずです。

ただし、これはAdventureWorks2012データベースProduction.WorkOrder テーブル。 StockedQtyはOrderQtyと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を侵害しているかどうかの要因を無視して、クエリ時に計算列より計算列を選択するための測定基準は何ですか？

sql-serverdatabase-designsql-server-2012normalizationrelational-theory
4
c448548

計算された列はリレーショナルモデルの構成要素ではないため、3NFなどのリレーショナルモデルの用語を使用して列を評価しようとしても意味がありません。計算された列は、一部のベンダーによって追加されたSQLの独自の拡張機能であり、論理的に格納されないため（物理的に永続化することはできます）、関係の属性ではないためタプルの一部ではありませんが、式に基づくその上に。

ところで-それがアドベンチャーワークスで見つけた唯一のモデリングの欠陥であり、その問題のための他のほとんどのサンプルデータベースであるなら、もっとよく見てください:-)

HTH

4
SQLRaptor

Vérace ：計算列はデータベースの正規化プロセスでの考慮から除外する必要があると思います。それらは単にデータベースに対する開発を容易にする方法です-実際には必要になることはありません。

たとえば、full_name = title + first_name + middle_name + surname + name_suffix便宜上。

これは、開発者がfull_name、何を含めるかを心配する必要はありません。すべて完了です。 suffixが存在するかどうかを確認するチェックはありません＆c。 -それは均一です-つまり、常に同じです、すべて時間です！

計算された列はfantasticですが、正規化に関してnotを考慮する必要があります！

1
user126897