「お持ち帰りご注文用紙」をT字形ER図にする

T字形


スキャナを買ってきた。これから時々手書きT字形ER図を描いては公開します。
ツールで描いているとぜんぜん思ったとおりの絵にならないので、汚いけど手書きで行きます。
初回の題材は、以下のページの問題。
楽々ERDレッスン 第1回：「お持ち帰りご注文用紙」編
http://codezine.jp/a/article.aspx?aid=154


描いた絵はこれ：

(スキャンしたらきったねえ仕上がりになってしまった。 俺の字はほんとはもっときれいなんだ!)


上記ページの元の絵と違うところについて。

  • 顧客の名前と電話番号は、顧客の住所が変わってもよいように、「顧客」と「注文ヘッダ」に重複して持たせている。
  • 商品区分IDは「商品」から対照表「商品.商品区分」に移動する。１商品が複数区分を持てるように。

（「商品」の商品区分フィールドをビット型として実装すれば、対照表に切り出す必要はない。
元の絵で商品区分が「商品」に置かれているのは、ビット型で実装することを念頭においているからだと思う。
T字形では、作図時点でここまで考えてはいけないのだろうか？）

  • 「商品」と「カテゴリ」の間に対照表を生成する。

これはT字形だからこうしましたというだけで、なぜそうした方がよいのかは説明できない。
同一商品を複数カテゴリに含めやすいとか、テストデータを作りやすいとか（個人的に、対照表のこの点がすごく
気に入っている）、そういうことだろうか。

  • 注文はヘッダと明細に分ける。

元の絵にはヘッダがないが、顧客の名前・電話番号を注文eventに保存したかったので作った。
あと、ヘッダがあると注文総額に対する値引きに対応しやすいから。


T字形ER「手法」で解析するなら、

  • 商品ID
  • 顧客ID

などの「認知されていないidentifier」を安易に導入できないのだが、それを気にするとT字形ぽい絵が描きにくいので、勝手に導入した。
今の私は、実際のプロジェクトでもこの手の代理キーを絶対導入する。
論理設計段階での代理キー導入を否定する流派もあるが（＝この本には「常識」とまで書いてあるが）、正直意味が分からない。
だって、図に代理キーを書き込むかどうかで、正規化の度合いが変わってくるではないですか。ということは、異常なデータをinsertしてしまわない責任がアプリケーションとデータベースのどちらにあるのか、も変わってしまうではないですか。であれば抽象度の高いドキュメントにも代理キーの存在を書き込んでおかないとただのお絵かきになってしまいませんか。...長くなりそうなので別途エントリします。