Q&A
>所属部署が消滅したりすると紐づいている従業員の行き場が無くなります。
次の行き場が決まり、配置転換が済んだ後、削除すれば？
現在、ACCESSを用いて会社内での従業員管理を行おうとしております。
「組織テーブル」と「従業員テーブル」を関連づける際の考え方について御意見をお聞かせいただければと思います。
前提
「組織テーブル」と「従業員テーブル」を関連づける際に
のような構成を考えたのですが、これだと所属部署が消滅したりすると紐づいている従業員の行き場が無くなります。
組織変更や従業員の異動などに、柔軟に対応できる構成にしたいのです。
そこで、
のように中間テーブル？を置いて対応しようと思いました。
質問
1. このような中間テーブルを置くような構成は一般的に用いられるのでしょうか？
もっとよいテーブル構成があったら教えてください。
2. このような中間テーブルを置くと、このテーブルでレコード数がかなりの数になります。
(単純計算で【「部署数」×「従業員数」×「変更数」】)
（表現が難しいのですが）そういうもの、と割り切って考えるものなのでしょうか？
よろしくお願いします。
> 組織変更や従業員の異動などに、柔軟に対応できる構成にしたいのです。
過去の所属を記録したり、所属部署が複数になったりに対応する必要がある感じでしょうか？
>次の行き場が決まり、配置転換が済んだ後、削除すれば？
そのような運用は現在考えておりません。
＞過去の所属を記録したり、所属部署が複数になったりに対応する必要がある感じでしょうか？
そのようなことも考えて、所属テーブルに From列、To列などを設け、日時を入力しようかとも考えていますが、それ以前にこのような中間テーブルを作成し、運用するような構成が妥当かどうかが知りたいです。
回答4件
0
ベストアンサー
「組織テーブル」と「従業員テーブル」
1. このような中間テーブルを置くような構成は一般的に用いられるのでしょうか？
一般的な人事管理システムであれば、[従業員テーブル]と[組織テーブル]を直接関連付けるのではなく、
- いつ
- どの従業員が
- どの組織/支店/部署/勤務地に
- どの役職/職種として
- どのような形態で
- 採用されたか/配置転換されたか/退職したか
といった従業員の異動に関する記録を残すための[異動履歴テーブル]を定義するでしょう。
2. このような中間テーブルを置くと、このテーブルでレコード数がかなりの数になります。
例えば入社したての従業員については、採用時における異動履歴を示すレコードが[異動履歴テーブル]に1件追加されることになります。
入社後しばらくしてどこかの組織に異動することになった際には新しいレコードを1件追加し、そのレコードがその従業員にとっての「最新の所属状況」を表すものとなります。
（表現が難しいのですが）そういうもの、と割り切って考えるものなのでしょうか？
そうしなければ、それぞれの従業員の（過去から現在に至るまでの全ての）異動の流れを記録、追跡することが出来ません。
これだと所属部署が消滅したりすると紐づいている従業員の行き場が無くなります。
それは[組織テーブル]上で各組織に関する情報をどのように管理するかを考える方が先です。
例えば、廃止された組織のレコードを削除するのではなく、[廃止フラグ]なり[廃止年月日]なりのフィールドの値によって、廃止された組織であるか否かを区別するという方式もあるでしょう。
投稿2023/10/16 02:07
編集2023/10/16 02:17
総合スコア744
どうもありがとうございます。参考になります。
仰られた「異動履歴テーブル」を参考にして、「T_所属」にフィールドを更新すると、
所属ID(主キー)、従業員ID(外部キー)、部署ID(外部キー)、From(日付型、開始日を表す)、To(日付型、終了日を表す)、
役職ID(外部キー)、雇用形態ID(外部キー)
となって、各々の従業員の情報を包括的に参照するのは、「T_所属」を基にしたクエリーとなると考えます。
このような理解で合っておりますでしょうか？ よろしくお願いします。
（画像を添付します）
> From(日付型、開始日を表す)、To(日付型、終了日を表す)
SQLの予約語と同じ名前や、何の期間の開始日/終了日を示しているのか
分かりにくいような名前をつけるのは、なるべく避けた方がよいでしょう。
> 各々の従業員の情報を包括的に参照する
ここでの「各々の従業員の情報」の範囲や「包括的」の意味合いが
よく分かりませんので、今のところお答えいたしかねます。
> 画像を添付します
リレーションシップに関しては、概ねそのようなイメージでよいと思います。
・〈役職〉と〈職種〉は異なる概念、属性であるので、必要であれば[職種テーブル]を
別途定義し、[職種ID]をキーとして[異動履歴テーブル]と紐づけるようにする。
・「採用」「昇格」「降格」「配置転換」「転勤」「兼任」「出向」「解雇」
「退職」「再雇用」といった〈異動の種類〉を記録する場合も同様である。
どうもありがとうございます。大変参考になりました。予約語などについても単語自体は知っていましたが、実際に指摘して頂くと色々と勉強になります。
0
それ以前にこのような中間テーブルを作成し、運用するような構成が妥当かどうかが知りたいです。
所属部署が複数になりうることが前提であれば必須です。
投稿2023/10/15 15:22
編集2023/10/15 15:23総合スコア145184
どうもありがとうございます。質問2に関しては、いかがでしょうか？ 一つ一つの部署、従業員各々、変更の都度、などレコード数が膨大なものになることが想像できますが、当然のこととして割り切るものなのでしょうか？
はい。
どうもありがとうございます。参考になります。
0
参考例
[従業員]{従業員ID},氏名
[組織]{組織ID},組織名,上位組織ID
[役職]{役職ID},役職名
[従業員所属]{従業員ID,組織ID},役職ID
投稿2023/10/16 12:59
総合スコア164
0
投稿2023/10/16 04:26
総合スコア50
> 組織変更や従業員の異動などに、柔軟に対応できる構成にしたいのです。
何を設計したの？ 中間テーブルに何でもかんでも詰め込むだけなら、最初から『制約について』設計するつもりは無かったんでしょうね。
あなたの回答
tips
プレビュー
