「何をエンティティにするのか」は、やはり明文化できないのだろうか
実践的データモデリング入門 (DB magazine selection) を読了。
「入門」とあるが、初学者が読んで即DB設計するのはきついという意味で、入門レベルの本ではないと思う。
これは多くの入門書に共通する壁なのだが、「何をエンティティにすればよいのか」がはっきり提示されていない。
一通りのモデルを組んだ後で、正規化のチェックをするとか、属性の割り振りをするとか、そういった手順は詳しく書いてあるが、とっかかりのモデルを組む技法は職人芸ということになっている。
P-66
何をエンティティとして抽出すればよいかは、実務の中で経験を積んでいくしかないと思いますが、
目安として大きく２つに分するすることができます。
何をエンティティとするかのルールが明文化できないうちは、DB設計は「みんな違ってみんないい」という金子みすず的な世界にある。
つまり「俺の設計も正しいが貴方の設計も素晴らしい」というのがあり得る世界だ。オブジェクトモデリングみたいに。
初学者にとっては、自分の作図が合ってるのか・惜しいのか・ぜんぜんダメなのかの判別が難しい世界だ。
結論、初学者にはやはりT字形ER手法がいいんじゃないかと思う。
T字形ER手法は「identifier*1 のあるものだけが entity である」と決めてしまうことで、「何をエンティティとするのか」問題に（強引に）決着をつけている。
コード体系に従って機械的に resource を切り、resource と resource*2を機械的に組み合わせて event を生成する。
現場で認知されているコードがある限り、作成したER図中に、絶対に間違いないと確信できる領域を確保できる。
identifierのないテーブルも多々必要になるが、それらは全て上記の領域から導出できる。この切れ味はすさまじいものがある。
