スーパータイプ、サブタイプの一部のテーブルで共通化しているフィールドがあるとき

Question

お世話になります。

データベース設計でスーパータイプ、サブタイプというのがありますが、
サブタイプ固有のフィールドの中で一部のテーブルで共通化できるものがある場合、これはスーパータイプに含めるべきでしょうか。

上記は社員テーブルをスーパータイプとして、正社員、アルバイト、契約社員という区分毎でサブタイプを切り出しています。ここで、アルバイトと、契約社員の中で、「hourly_salary」と「working_hours」が共通のフィールドとして、切り出せるのでスーパータイプの「employee」テーブルに含めるというのはありでしょうか。

このような例の場合は、employeeテーブルとpart_time,afreementテーブル間に中間テーブルを入れるという作る方もあるかもしれませんが、これがテーブルの数が増えて、フィールドの数も増えた場合はどうでしょうか。

一部で共通化できるからスーパータイプテーブルに入れるとnullを許容することにもなるので、
問題ではないかと思っています。

このような場合のＤＢ設計について皆様のご意見をお聞かせください。

※上記図はあくまで例として出しているだけなので、スーパータイプ、サブタイプと分けた場合で一部で共通化出来るフィールドをどうするかという質問に対してのご回答をお願いいたします。

Answer 1

私の意見としては、一部共通できるからといってスーパータイプにフィールドを持たすような設計にはしません。

それを許すなら、最初から上記の４つのテーブルは１つでいいじゃないという設計思想になってしまいます。

ボトムアップの設計をすると共通化したいと思うのは理解できます。
共通化したいから親側のテーブルに持たそうという考え方はしないです。

今回の場合、給与の計算方法、月給と時給とで分けるように設計すると思います。
※正社員テーブル、契約社員・アルバイトテーブルの２つ

[追記]

やはり共通フィールドに持たせるようなやり方はしないですかね。

できれば、具体的にどのような問題がおきるかなど教えていただけますでしょうか。

問題というほどのものではないですが、

一部で共通化できるからスーパータイプテーブルに入れるとnullを許容することにもなるので、

問題ではないかと思っています

の部分かなと思っています。nullを許容すること自体は気にしませんが、いわゆる社員区分によって
見るカラムを変更するのが面倒です。（caseでカバーできますが）

それよりも、テーブル単位で見るカラムが同じほうが、私は好みです。

Comments

[annderber]

コメントありがとうございます。

やはり共通フィールドに持たせるようなやり方はしないですかね。
できれば、具体的にどのような問題がおきるかなど教えていただけますでしょうか。

Answer 2

私なら「社員の給料マスタ（employee_salary」として、社員テーブルとは切り離します。

employee_id     // 社員ID
monthly_salary  // 月給（null 可）
hourly_salary   // 時給（null 可）
start_date      // 適用開始日
end_date        // 適用終了日

まあ適用開始・終了までは不要とは思いますが、一応入れときますかね。
月給・時給以外の体系（年棒制等）があることを考慮すると、salary_type と salary の二つの項目にしてしまうかとかは、もう少し業務の内容を見てみないと決められませんかね。
※固定給 + 時給、あるいは固定給＋歩合制、なんてパターンもあるかもしれないので

Comments

[annderber]

コメントありがとうございます。

本文にも記載しましたが、今回の質問はーパータイプ、サブタイプと分けた場合で一部で共通化出来るフィールドをどうするかなので、そのあたりはいかがでしょうか。

[tacsheaven]

スーパータイプ、サブタイプだと分けるとしたら、サブタイプ側に持たせます（同じフィールドになっても）。
その属性はサブタイプ側にあるものであって、スーパータイプでまとめるべきではないからです。