UniversalなDB設計は幻想

http://watanabek.cocolog-nifty.com/blog/2006/09/post_d032.html
http://d.hatena.ne.jp/habuakihiro/20060903#1157265393

とりあえず、はぶ先生と渡辺先生のER図やら渡辺先生ところに書き込んでる人の意見やらHATさんの意見やらT-ER図法やらを比較検討してみたが、現段階ではUniversalなDB設計は幻想だというのは確定的みたいね。

ということは「DB設計は○○が常識」みたいな見解は、おおむね個人的な見解とみなしてもよいということだろうか？

まぁ、第三正規形に関してはどの方の考えでも満たされているわけだから、そこまでは常識の範囲でOKだと考えていいのだと思う。と、いいつつパフォーマンスのためには非正規化も許されると書いてあるＤＢ設計の本はたくさんあるわけでこれすら怪しいところではあるけれど。まぁ、その場合であっても正規化で設計した後に実装として非正規化することを念頭に書かれているし、非正規化した方が適切なＤＢ設計であると主張している人はいないと思うので、正規化が常識であるいう点までは同意がとれているものと考えていいだろう。

とりあえず、ここを出発点としたとき、はぶ先生と渡辺先生のER図の違いは何かを見てみると

1. 複合主キーか否か
2. リソース間にイベントがあるかどうか
3. 倉庫に対する商品を在庫とみるのか、棚に対する商品を在庫とみるのか
4. 入庫・出庫があるか否か

というところかな。

複合主キーか否かというのは、設計そのものには基本的には関係ない*1ので、とりあえず置いておくとしよう。

1と4は、はぶ先生の設計手法はイベントによって初めてリソースが結合されるという思想の元に考えられていることが原因だろう。渡辺先生は、静的な側面（＝マスタ）からモデルを設計しているのに対し、はぶ先生は動的な側面（＝トランザクション）からモデルを設計しているようにも見える。いまのところ、どっちが良いのかはよくわからない。

3は、在庫の定義の問題という気もする。在庫を「倉庫に存在する商品数」と定義すれば前者だし、「棚にある商品の合計数」だと定義すれば後者のモデルになる。私は要素還元主義者なので、後者の方が正しいように感じる。データベースがそもそも要素の積み上げであって、概念がありそれをドリルダウンしていくような仕組みではないと考えるべきではないか。

*1:というのが私の主張なのだが、どうもはぶ先生は違うと主張してそうな雰囲気。たしかにはぶ先生の設計思想を考えると、IDであることには重要な意味があるので、それはそうかもしれない。ただ、IDを付けることの実利はT-ERをID方式化しても同様に得られるメリットなので、ここではそのように考えておく。