« 開発者が「コード体系」に関与する必要はない | トップページ

2019.04.19

部門と従業員のデータモデリング

 どんな業務システムでも扱われる情報の代表が、「部門」や「従業員」である。常用的であるだけでなく、データモデリングの基礎を学ぶには最適と思われるのであらためて取り上げよう。

 まずは単純なモデルを示そう(図1)。従業員は所属部門コードを持っていて、これが部門コードへの参照キー(外部キー)になっている。また、部門毎に上位部門が指定されていて、部門はいわゆる「自己参照」の形をとっている。

▼図1.部門と従業員
20190419_1

 小規模事業所向けであればこれでも足りるが、ちょっとした問題がある。過去や未来の情報を扱えない。つまり、過去の経緯もわからないし、未来の情報をあらかじめ登録しておくこともできない。本格的な業務システムでは致命的といっていい。

 そこで、テーブルの識別子に「時間軸」を組み込むことを考える。部門階層や従業員の所属が月の途中で変わるとは考えにくいので「年月」を組み込もう(図2)。この形なら過去の経緯も保存されるし、将来の予定もあらかじめ登録できる。

▼図2.主キーに年月を含む部門階層
20190419_2

 開始年月から最終年月までで規定される「期間」の重複(部分的でも時期が重なること)やギャップ(期間の隙間)を許すかどうかについては、データ要件として明確にしておいたほうがよい。ひとつの部門に注目した際に、異なる上位部門が同じ期間に存在しているケースは管理上避けるべきなので、部門階層について期間の重複やギャップは許さないほうがいい。

 図2の「最終年月」がカッコ書きされている点に注意してほしい。これはこの項目が「導出項目」であることを示している(*1)。「その部門向けの次の部門階層の開始年月の前月(続く期間が存在しなければ最大値か部門の廃止年月)」として動的に設定されるものだ。{部門コード,開始年月}によって同一部門向けに開始年月が重なることもないので、結果的に期間の重複やギャップは起こり得ない。

 つづいて「従業員の所属部門」を考えてみよう。まずは、期間の重複を許す形で「兼任」を表現してみる。次図では源頼朝が鎌倉殿と侍所(さむらいどころ)の2部門に期間重複で所属していることが示されている。

▼図3.所属部門の期間重複を許す
20190419_3

 しかしよく考えてみると、同年月において複数部門に所属しているというのは、それらの部門の「管理者」を兼任しているといえそうだ。部長が複数部門を兼任することはありそうなことだが、一般メンバーが複数部門に同時に所属するのは考えにくい(というか組織運営上許すべきではない)。そこで、「部門の管理者」を部門の属性として位置づけたうえで、所属の期間重複を許さない形にしてみよう(図4)。

▼図4.所属部門の期間重複を許さない
20190419_4

 このモデルでは、ひとりの従業員がいくつもの部門の管理者であることが許されている。言い換えると、部門管理者はその部門の所属メンバーではなくてもいいということなので、所属部門に期間重複を許すべき理由もない。最終年月が導出項目になっているのはそのためだ。

 さらに次図のように、上位部門コードだけでなく管理者コードも、そして従業員の所属部門だけでなく役職についても、期間を含む識別子に関数従属するとみなしてもよい。この場合、それらのいずれかの属性が変わる時点で期間別データを追加することになる。図1よりずいぶん複雑だが、データ要件をうまく捉えている。無駄に複雑であってはいけないが、データモデリングに限っていえば「シンプルイズベスト」が通用しないことがおわかりだろうか。

▼図5.期間別属性を組み込む
20190419_5

 これほど単純かつ局所的なDB設計でも、「複合主キー」を適宜用いることで効果的に検討できる点に注意してほしい。このモデルをID方式(テーブルの主キーをすべてオブジェクトIDとするやり方)で実装するのは簡単ではない。要請されるユニーク制約や更新制約を慎重に組み込まないと、DBは矛盾したデータを平然と受け入れてしまう。少なくともデータ要件を探る段階では、複合主キーを許す形でモデリングすべきである。「ID」の一本槍では複雑なデータ要件を論理制約として捉えきれないからだ。


*1.導出項目をどう実装するかは利用される基盤次第である。テーブルの拡張定義として導出項目を定義できるのであれば理想的だ。なぜなら1回定義すれば、アプリ毎に同じロジックを書く必要がないからだ。

|

« 開発者が「コード体系」に関与する必要はない | トップページ

コメント

コメントを書く



(ウェブ上には掲載しません)




« 開発者が「コード体系」に関与する必要はない | トップページ