教科書的な正規化ではstableなデータ構造は得られない

データベースの設計指針として我々に与えられている兵器は「正規化」しかない。
しかし教科書的な正規化だけでは兵力不足だ。
正規化すればデータの整合性は保証されるが、データ構造の安定性までは保証されないのだ。

ある部門が名前を変えることになったとき、正規化されたデータベースならば、古い名前を格納しているただ一つのカラムを変更するだけで更新作業が完了する。しかし、カンパニー制の導入によりある部門の上位組織が「全社」から「ｘｘカンパニー」に変わった時、そのデータベースにはカンパニーCodeを収納する場所がないために、データ構造を変更せざるを得ないだろう。

組織構造の変動に対して安定的なデータ構造は、「正規化」というルールからは導けないのだ。
「アナリシスパターン」の「責任関係パターン」はstableな組織構造を表現するパターンだが、教科書的な正規化という視点からは、こんな構造は出てこない。minimalではない、冗長だ、と判定されるだろう。
そこでT字形なわけですよ。T字形の最大の特徴である対照表が、stableなデータ構造を実現する。

SQLでは null=null にならない理由

ジョー・セルコのプログラマのためのSQLは非常に好きな本。全部読んでないけど。
この本で初めて、SQLでは null=null が true ではなく unknown である理由について、納得のいく説明が得られた。
P103にこんな話が載っている：

従業員テーブルに、「車の色」「髪の色」という列があるとする。
「車を持っていない人」「禿の人」の場合、これらの列の値は null である。
ここで、「車と髪の色が同じ人」を検索しようとして

	SELECT * FROM 従業員 WHERE 車の色＝髪の色

を発行する。
もしnull=nullであれば、「車を持っていない禿の人」が「車と髪の色が同じ人」に該当してしまう。
これは変でしょう。