UMLからER図への抽象クラス。可能 ？どのように？

一般化をデータベースモデルに変換するには、基本的に3つの選択肢があります

1。具体的なクラスごとに1つのテーブル

テーブルを作成するAdmin 、Teacher およびStudent 。これらの各テーブルには、Userのすべての属性と関係の列が含まれています

• プロ
  • 具象サブクラスのすべてのフィールドは同じテーブルにあるため、すべての生徒のデータを取得するために結合する必要はありません
  • 簡単なデータ検証の制約（Studentの必須フィールドなど） ）
• Con
  • Userのすべてのフィールド 各サブクラステーブルで複製されます
  • Userへの外部キー 3つのFKフィールドに分割する必要があります。 Admin用に1つ 、Teacher用に1つ 1つはStudent用です 。

2。一般化セット全体のテーブル上

この場合、Userを呼び出すテーブルは1つだけです。 Userのすべてのフィールドが含まれています +Userのすべてのサブクラスのすべてのフィールド

• プロ
  • すべてのフィールドが同じテーブルにあるため、すべてのUserを取得するために結合する必要はありません。 データ
  • FKをUserに分割しない
• Con
  • 使用されないフィールドがたくさんあります。 Studentに固有のすべてのフィールド およびTeacher Adminsに入力されることはありません 逆もまた同様です
  • Studentなどの具体的なクラスの必須フィールドなどのデータ検証 単純なNot Nullではなくなったため、かなり複雑になります 制約。

3。具象クラスごとに1つのテーブル、およびスーパークラス用に1つのテーブル

この場合、具体的なサブクラスごとにテーブルを作成し、クラスUserのテーブルを作成します。 。各具象サブクラステーブルには、Userに必須のFKがあります。

• プロ
  • 最も正規化されたスキーマ：ユーザーの属性に繰り返されるフィールドや未使用のフィールドはありません。
  • FKをUserに分割しない
  • 簡単なデータ検証の制約（Studentの必須フィールドなど） ）
• Con
  • Studentのすべてのデータが必要な場合は、2つのテーブルをクエリする必要があります
  • 各Userを確認するための複雑な検証ルール レコードには1つのAdminがあります 、Teacher またはStudent 記録します。

これらのオプションのどれを選択するかは、サブクラスの数、サブクラスまたはスーパークラスの属性の数、スーパークラスへのFKの数、そしておそらく私がしなかった他のいくつかのことなど、いくつかのことによって異なります。考えてみてください。