MySQL Workbenchダイアグラムでのスーパークラス/サブクラス（またはスーパータイプ-サブタイプ）の関係の表現
状況
superclass/subclassまたはに関する1対1（1：1）の関係を表す方法を理解しようとしていますMySQL Workbenchで作成された種類のエンティティ関係図（ERD）のsupertype-subtype構造（ご存じのように、これは具体的なSQL実装により近く見えます）オリジナルのPPチェン図）。
私はこれが初めてなので、すべての属性を入力する必要があるかどうかわかりません1 再びサブクラスエンティティ（またはsubtypes）、つまりMANAGERおよびDRIVER、またはconnectingに属性を取得してsuperclassから属性を取得する方法があるかどうか（またはsupertype）これらが関連していることをより明確にするために、外部キーのようなものだと思います。
1. EMPLOYEEの各属性はMANAGERとDRIVERに適用されますが、MANAGERとDRIVERにはextraEMPLOYEEエンティティタイプ（または実装された後のテーブル）の特性ではない属性。
現在の図
以下は、これまでに作成したERDです。
質問
では、このような関係を図でどのように正確に表すことができますか？
これは、ER用語で「一般化/専門化」と呼ばれるものです。これは、オブジェクトモデルが「スーパークラス/サブクラス」と呼んでいるものと同じです。 2つの分離可能な問題があります。 1つ目は図をどのように描画するか、2つ目はテーブルをどのように設計するかです。
ダイアグラムの描画に関する限り、1つの例外を除いて、あなたが持っているのと同じ方法でそれを描画します。マネージャーとドライバーからつながるラインは、従業員に個別には行きません。代わりに、私はgen/specボックスと呼ぶものに行きます。次の sample は、gen/specケースを表す1つの方法を示しています。次に、1行でgen/specボックスとEmployeesテーブルを接続します。それはすべて、あなたや図を見る他の人にとってどちらがよりシンプルで明確に見えるかに依存します。
テーブルに関する限り、これまでに示したように、3つのテーブルを作成できます。これは、「クラステーブルの継承」と呼ばれることもあります。 「共有主キー」と呼ばれる、恩恵を受けることができるテクニックがあります。この手法では、マネージャーテーブルとドライバーテーブルには、独自のidフィールドがありません。代わりに、各サブクラステーブルにEmployee_idのコピーがあり、employee_idはこのテーブルの主キーであると同時に、Employeesを参照する外部キーでもあると宣言されています。
共有主キーを使用すると、いくつかのメリットがあり、コストがかかります。
それはあなたにマネージャー-従業員またはドライバー-従業員に対する1対1の制限の施行を買います。結果として生じる結合が高速化する可能性があります。また、外部キーとして従業員IDを使用する4番目のテーブルを、ドライバーまたはマネージャーに直接結合できます。関係のない従業員は参加を辞退します。
ドライバーやマネージャーを挿入するたびに、正しいemployee_idのコピーを取得して使用する必要があるという点でコストがかかります。
また、ドライバ属性とマネージャ属性を従業員テーブルにパックし、無関係なフィールドをNULLのままにすることもできます。その結果、結合は少なくなりますが、マイナス面もあります。従業員テーブルが少し大きく、遅くなります。また、WHERE句でnull許容フィールドを使用する場合は、SQLが3つの値を持つロジック（True、False、およびUnknown）をどのように実行するかを学ぶ必要があります。一部の人にとって、これは非常に理解するのが難しいです。私は3つの重要なロジックを自分で避けようとしています。