● 非正規形には、「複写 （replication）」 と 「導出 （derivation）」 がある。

　データ 設計では、「論理設計」 と 「物理設計」 という 2つの段階を考慮することが多い。
　「論理 （logical）」 というのは、「特定の」 ハードウェア や OS や ソフトウェア （たとえば、DBMS） を考慮しないことをいい、「物理 （physical）」 とは、具体的な（言い換えれば、「実際に使っている」） ハードウェア や OS や ソフトウェア の機能を加味して 「論理」 を調整することをいう。

　システム・エンジニア が目的としなければならない点は、「論理＝物理」 を実現することにある。そのために、エンジニア として、技術を駆使するのである。ただ、データベース は、技術的な ツール であると同時に セールス の プロダクト でもある。最高級の機能を搭載している ツール が、かならずしも、プロダクト として普及する訳ではない。言いかたを換えれば、データベース を導入する ユーザ 企業でも、「費用対効果」 を加味して、プロダクト を選ぶ。つまり、限られた投資のなかで、プロダクト を選ぶ。
　したがって、高 パフォーマンス を実現する機能を搭載した最高級の データベース が、かならずしも、導入されている訳ではない。

　逆に言えば、データ の正規形が崩されれば崩されるほど、データベース の性能が悪い （あるいは、システム・エンジニア の技術力が悪い）、と判断してよい。

　ただ、「完全な」　正規形を実装することは （現時点では） あり得ない、と思ってよい。非正規形には、以下の 2つがある。

　　　（1） 導出項目 （derivation）
　　　（2） 複写 （duplication）

　
[ 参考 ]
　非正規形には、以上の 2つのほかにも、「多義 （繰返項目）」 や 「サブセット の まじわり （AND 関係）」 も あるが、いずれも、「事実」 そのものが交錯している状態である──したがって、「形式的構成」 では、なんらかの対応をしなければならないが、本 ページ の テーゼ と離れるので、その対応の説明は割愛する （「FAQ」 のなかの しかるべき ページ を参照されたい）。「事実」 を起点にして、「事実」 から導き出される項目として、以上の 2つ （導出項目と複写） を典型例として扱う。

　
● 「導出項目 （derivation）」 は、データ 項目として定義することがある。

　たとえば、「在庫残高 （誘導法を使った帳簿記録）」 は導出項目である。したがって、「完全な」 正規形のなかでは、定義してはいけない。しかし、企業の設立時点から現時点に至るまで、入庫 トランザクション のすべてと出庫 トランザクション をすべてを対象にして在庫残高を計算することは 「現実的」 ではない。いっぽうで、（制度会計上、公認会計士の） 実査立会があるので、期末の在庫残高を 「事実 （データ）」 として認知するのが普通である。
　「完全な」 正規形では、かりに、期首の在庫残高を 「事実」 として認知しても、期中の在庫残高は導出項目なので、（在庫残高を データ 項目として定義しないで） 計算することなる。しかしながら、そうすれば、「在庫引当」 に対応することがむずかしい。

　したがって、在庫残高という導出項目を データ 項目として定義するのが （事業のなかでは） 「健全な」 措置である。ただし、「在庫」 ファイル が、データ 構造のなかで、いきなり、記述されているのは適切ではない。「在庫」 は、データ 構造のなかでは、倉庫と棚と製品から導出される テーブル であり、在庫残高 （数量） は、入庫 （入荷） と出庫 （出荷） と倉庫間移動と （減耗などの） 調整から導出される項目である。それらの導出関係が、データ 構造のなかで、記述されていなければならない。

　　　　「在庫 （倉庫. 棚. 製品. 対照表）」
　　　　｛倉庫 コード (R)、棚番号 (R)、製品 コード (R)、DATE、数量 （D）｝

　（D） は、derivation の略である。ちなみに、「倉庫. 棚. 製品. 対照表」 が、データ 構造上の導出を記述しており、数量 （D） が、計算上の導出を記述している。

　
● 「複写 （replication）」 も 「事実」 からの 「導出 （derivation）」 である。

　データ 重複に関しては、たとえば、以下の データ 構造を例にする。

　[ 例-1 ]

　品目　｛品目番号、品目名称、単価｝ [ R ]
　受注　｛受注番号、品目番号 (R)、受注日、受注数｝ [ E ]

　
　[ 例-2 ]

　品目　｛品目番号、品目名称｝ [ R ]
　受注　｛受注番号、品目番号 (R)、受注日、受注数、単価｝ [ E ]

　
　[ 例-3 ]

　品目　｛品目番号、品目名称、単価｝ [ R ]
　受注　｛受注番号、品目番号 (R)、受注日、受注数、単価｝ [ E ]

　
　以上の 3つの例では、単価が帰属している entity がちがう。
　「例-1」 では、品目という 「resource」 のなかに単価が帰属しているので、単価は 「定価」 を意味しているし （──製造なら、標準原価を意味しているし──）、「例-2」 では、受注という 「event」 のなかに単価が帰属しているので、単価は 「時価 （オープン・プライス）」 を意味している （──製造なら、実際原価を意味している）。「例-3」 では、単価は品目にも受注にも定義されているので、定価がきめられているが、営業の判断次第で、値引きができることを意味している （──製造なら、標準原価と実際原価の ふたつを適用して、原価差異を計算することを意味している）。

　Ｔ字形 ER手法が 「正規形 （Ｔ字形ＥＲ手法がいう正規形）」 を大切にする理由は、「正規形＝事業解析」 を実現する点にある。つまり、「正規形を読めば、事業を判断できる」 という点をＴ字形 ER手法は目的としている。

　たとえば、或る企業では、「例-1」 が 「事実 （事業の実態）」 であった、とする。しかし受注の データ 件数が膨大なので、いちいち、品目に アクセス して単価を入手すれば、データベース の高 パフォーマンス を実現できない、というふうに システム・エンジニア が勝手に判断して、品目の単価を受注のなかに複写して、以下の データ 構造を生成したとする。

　品目　｛品目番号、品目名称、単価｝ [ R ]
　受注　｛受注番号、品目番号 (R)、受注日、受注数、単価｝ [ E ]

　
　この データ 構造を読めば、（「事実」とは違う） 事業形態を想像してしまう。一人の システム・エンジニア の価値観のために、「事実」 を歪曲しないでほしい。もし、データベース の性能が悪いので、高 パフォーマンス を実現できないのであれば──ただし、品目番号を対象にして、「INDEX-only」 を使って、受注と品目を join すれば、高 パフォーマンス を実現できるのだが──、「複写」したことを示すために、以下のような記述にしてほしい。

　品目　｛品目番号、品目名称、単価｝ [ R ]
　受注　｛受注番号、品目番号 (R)、受注日、受注数、単価 (D)｝ [ E ]

　
　Ｔ字形 ER図では、複写 （replication） も、「事実」 から導出された項目として扱う。
　Ｔ字形 ER図では、「事実」 と 「事実以外」 を混同しないようにして記述し、「事実以外」 が、（単純な） 複写項目なのか、あるいは、計算式を使う導出項目なのか、という点は アトリビュート・リスト で記述する。