顧客説明における実体関連図
顧客説明における実体関連図
最近は小説家を志したり、日本人の音楽的アイデンティティを追求したりと、アホなことばかりをやっていたので、たまにはまじめにITを考える。
データベース設計において実体関連図(ER図)を作る。よく悩むのは「顧客や非エンジニアと合意を取るために実体関連図はどの粒度で作るべきか」ということ。概念設計→論理設計→物理設計の順で段階的に合意を取りなさい、ってのは教科書的回答だが、客とのレビュの機会なんてそう何度もないんですよ。
というわけでよく悩む以下の２パターンについて、自分の見解をまとめる。
マスタ間の多対多の依存関連
従業員マスタと部署マスタがあるとする。ある従業員は複数の部署に所属（兼務が可能）、ある部署は複数の従業員を持つ（そりゃそうだ）場合
この関係をそのまま表すとこんな感じ
この段階で賢明なるエンジニア諸君はこのままでは実装ができないことに気づく。そしてお作法に則り、workテーブルを作成し、以下のような図を顧客に見せることになる。
そして「なにこのemployee_dpartment」と言う顧客の疑問に「いや、これはですね、多対多のリレーションを排除するためのですね・・・」とテンパりながら答えるのである。（別に私自身の経験を言っているわけではない）
いや、合ってるのよ。完全に合ってるのよ。
でも顧客に見せる場合は、ER図01の粒度が十分ではないか。そして、親愛なるプログラマにER図02を手渡すのができるシステムエンジニアではないだろうか。
マスタ-トラン間の非依存関連
商品マスタと売上データ（トラン）があるとする。売上データは商品マスタを元に作られるが、発生した時点での実績として保持する必要がある。
この関係をそのまま表すとこんな感じ
賢明なるエンジニア諸君はお作法に則り、あえて非正規化した設計を行っている。この図を顧客に説明をすると「なんで、売上にも商品名が必要なの？冗長じゃない？」と言われる可能性があるが、これはきちんと説明してあげなければならないと思う。
「売上はその時点での情報を持っていなければなりません。本日、Aという商品が売れたとして、将来商品の名前がBに変わった^ 1としても、売上の情報としてはAという名前で売ったことは変わらないようにしなければなりません。そのために売上げデータにも商品名を保持するようにします。売上売価に関しても同様です」
明瞭な回答で打合せを終えた後に、親愛なるプログラマに以下のER図_04を見せるのが、できるシステムエンジニアではないだろうか。^ 2
まとめ
段階的な設計のレビューができない（レビューが一度きり）の場合は
- 顧客や非エンジニアには、概念設計と論理設計の中間くらいの粒度
- プログラマにはガッツリ物理設計の粒度
で合意をとるのがちょうど良いのではないだろうか。
以上
