データベースモデリングネタです。
皆さんは、業務アプリケーションを作成する上で、[社員]のデータをどのように取り扱っていますか。[社員]というテーブルを使って格納しているよ、という読者の皆様、本当にそれでいいのでしょうか。
DOAやOOAをやっている人にとってみれば、[社員]というエンティティ（テーブル・クラス）がいきなり定義できるというのは不気味なことだと思います。もちろん業務アプリケーションの要件にも大きく依存するので[社員]というテーブルを定義することが必ずしも誤っていると断言したいというものでもありません。
考えていただきたいのは、[社員]というのは、まず、「契約」によって成立するものだということです。[人]と[会社]の[雇用契約]によって定義されるべきものです。また、[雇用契約]が成立しても、[社員]として活動する限り、状態が変化するデータの一種であることです。企業規模にもよりますが、部署の移動・役職の変更・住所の変更、などなど、その社員が会社に勤務し続ける間、その社員の属性は時系列で変化します。この時系列の変化をどのように管理しますか。たとえば、[社員]が次のようなデータで構成されていたら、時系列の変化を管理するのは難しくなります。
社員
+------------------+
| 社員コード(PK) |
+------------------+
| 氏名 |
| 部署名 |
| 上司のコード(FK)|
| 住所 |
| 生年月日 |
| ・以下省略・・ |
+------------------+
このモデルを見て「これ、おかしいですねぇ」と気が付けば、少なくとも正規化ができていないことを理解していると思います。では、もう少し変えてみましょう。
社員
+------------------+
| 社員コード(PK) |
+------------------+ 部署
| 氏名 | +----------------------+
| 部署コード(FK) |●-----| 部署コード(PK) |
| 上司のコード(FK)| +----------------------+
| 住所 | | 部署名 |
| 生年月日 | | 上位部署のコード(FK)|
| ・以下省略・・ | | ・以下省略・・ |
+------------------+ +----------------------+
初期のデザインよりもよくなりました。部署というのが再利用できるからです。
ここでは、[部署]１に対して、所属する[社員]がｎ人であることを示しています。
でも、これでもまだまだ問題があります。同じ社員が別の部署に同時に所属するという業務命令が発せられたらどうするのでしょう。
社員
+------------------+
| 社員コード(PK) |
+------------------+ 部署
| 氏名 | +----------------------+
| 部署コード(FK) |●---●| 部署コード(PK) |
| 上司のコード(FK)| +----------------------+
| 住所 | | 部署名 |
| 生年月日 | | 上位部署のコード(FK)|
| ・以下省略・・ | | ・以下省略・・ |
+------------------+ +----------------------+
ここでは、[部署]ｎに対して、所属する[社員]がｎ人であることを示しています。
多対多の関係になってしまいました。さて、困ったどうしよう。
ここで問題です。解答は第２回で述べたいと思いますが、皆さんも考えてみてください。
問題１：[人]と[会社]の[雇用契約]をベースに[社員]を定義するとどのようになるでしょうか。
問題２：このデータベースを人事部が利用するとして、その[社員]がどのように部署を移動したのか履歴をトラッキングするにはどうしたらいいのでしょうか。
問題３：このデータベースを人事部が利用するとして、その[社員]がどのように役職上、昇格（あるいは降格）したのか履歴をトラッキングするにはどうしたらいいのでしょうか。
問題４：[社員]が結婚し、苗字が変更になりました。でも社内では旧姓のままその人を管理したいと考えています。どうすればいいでしょうか。
問題５：[社員]に子供が生まれ、扶養家族が増えました。どのように管理したらいいでしょうか。
問題６：[社員]のレポート先（報告先上司）が二人以上存在するとします。どのように管理したらいいでしょうか。