「正規化の実用的なルール」を考える

参考：

E．F．Codd の遺産−ECObjectsのDB設計ウラ話

http://www.class.co.jp/column/backnm07.html

↑の一番下に、ECOの設計指針が紹介されております。

◆正規化の実用的なルール
（1）基本的には第 1正規形のままでよい
　それをViewを駆使してキーを１意にしたり、キーを抽出したりするデータモデルがフレシキブルでよい
（2）第 1→第 2、第 2→第 3にする時には、そうしなくてはならない明確な理由が必要
（3）トランザクションデータは正規化しない

ぱっと見ると普通のデータモデリングしている身としてはショッキングなわけですが、これはデータ構造が安定しているという前提に立つ「正規化」の弱点を直視した結果ではないかと思います。その弱点とは・・・。

「関係従属、推移従属」が普遍ではない！。いつか変わるときが来る！

ということではないかと。たとえば、商品ひとつにIDを振って、「商品IDが決まれば単価が決まる」という従属性があった場合、それは商品マスタとなるのでしょう。が、ある日突然、「明日から単価変わるけど、過去に販売済みの商品価格データは変更しない！。履歴も管理する！」とかに変わると、その従属性は商品IDとある時刻（ある一定の期間）にも従属するように変わっちゃうわけです。

いつか変わるかもしれない「関係従属、推移従属」にもとずいて正規化すれば、その「関係従属、推移従属」が崩れたときに正規化してある構造が困ったことになるのは自明の理。そこで・・・。

「データとその関係従属、推移従属はデータを登録した時点でのみ正しいのであって、それ以上意味はない」

ということにすると、むしろ正規化しちゃいけないことになるわけです。だって正規化の前提となる「関係従属、推移従属」が変わるのですから・・・。未来永劫普遍な「関係従属、推移従属」なら正規化しても問題ないのですが、いやそれは言いすぎですか。システムのライフサイクル程度「関係従属、推移従属」が維持されれば正規化しても問題ないでしょう。

ん？。逆か？。「関係従属、推移従属」が崩れるときがシステム寿命の尽きるときなのか・・・。

プロセス中心アプローチから、データ中心アプローチに変わりました。しかしデータの永続化にRDBを選択した結果、どれだけシステムが安定してる期間が増えたのかというと・・・。

「ビジネスの処理内容（プロセス）」が変わる程度から、「関係従属、推移従属」が変わる程度までに長くなった程度ではないかなぁ、と思う次第です。そして現代は、意外に「関係従属、推移従属」も安定しない方向なのではないかと。

そういう認識に立てば、「正規化の実用的なルール」も納得がいくような・・・。

（1）基本的には第 1正規形のままでよい
　　　「関係従属、推移従属」が普遍ではないというのが「基本的」なデータだから。「関係従属、推移従属」はわりと不安定。（という前提）

（2）第 1→第 2、第 2→第 3にする時には、そうしなくてはならない明確な理由が必要
　　　「関係従属、推移従属」が普遍（またはシステムの寿命以上普遍）という明確な理由があるなら第2,3正規化OK。

（3）トランザクションデータは正規化しない
　　　トランザクションデータは、データエントリーした時点でしか「関係従属、推移従属」が成り立たないようなデータだから。（という前提）

真理は上記と思いますが、今はまだRDBの性能が足りないでしょう。ムーアの法則あと10年続けば、「正規化は第1正規化」が常識になるのかもしれません・・・。

＃マジ？(^^;