ER図かんがえる - s5ot's blog

部署と従業員のER図。
簡単な入門書とかだとこんな感じかな。

その1

これは、見た瞬間に疑問が湧くわけで。
部署に所属してない従業員の部署IDはNULL？ダミー値？
NULLにした場合、SQLの世界だとTRUE/FALSE/NULLの3値論理なのでイヤーな感じです。
ダミー値にした場合、参照キーであるのに参照元にないキーってのもイヤーな感じ。
ダミー値は破られるためにある、と思うし。破られたときに大変。
というわけで改善案を考える。

その2

この場合、部署に所属している従業員だけ所属部署エンティティのレコードを作成します。
部署に所属してない従業員は所属部署エンティティのレコードはない。
画面で従業員詳細とか出すときに部署も表示するならLEFT OUTER JOINしなきゃいけないですね。
ひとりの従業員が複数の部署に所属することができない、ってのは困るかも。
改善案ー

その3

これの場合、部署に所属してない社員は所属部署エンティティのレコードはない。
ひとりの従業員が複数の部署に所属できる。
となりました。
でも、いつ、その部署に所属になったのかとか、いつからいつまではこの部署に所属してたとかの履歴管理は
デキナイ。
そうするともうちょっと。

その4

「いつ所属した」ってのを所属エンティティで管理。
これまでの３つでは、部署と所属のデータ構造を表現するのみだったけど、
部署と所属を関連付ける「所属」ってイベントを見つけました。

で、どうしよう

ものすごい妥協な感じですが、
外部キーがNULLになる可能性がない！ぜったいない！の場合は、その１にする。
外部キーがNULLになる可能性がある〜ありそうだ〜の場合は、その２にする。
関連がN:1とかN:Nなんですぅの場合は、その3にする。
日付とか履歴とかも必要なんだYO！の場合はその4にする。
これでいけないかな。。。

追記

外部キーがNULLにならないなんて保障できないよなあ。
受注-売上で、売上に受注IDが外部キーで入ってても、受注がなくても売上は立てたい！って普通にあるし。
そうするとその２かその３だなあ。
コッド博士とかチェン氏とかの理論に触れてなくてバカっぽいエントリだなあ・・（ｗ