CraigLarmanの著書「ApplyingUMLwithPatterns」では、この問題に対する3つの一般的な解決策について説明しています。
あなたの例は特に役に立ちません-データベースで人の名前を管理する3つの異なる方法がある論理的な理由はありません（これはデータのインポート/エクスポートの奇妙さのために定期的に発生しますが）。
ただし、従業員（employee_idを持つ）、連絡先（prospectsテーブルへのリンクを持つ）、または顧客（customer_idとordersテーブルへのリンクを持つ）である可能性のある「person」エンティティが存在することは非常に一般的です。 。
ラーマンの本では、彼は3つの解決策を示しています。
すべてを統治する1つのテーブル ここでは、すべての既知の列を含む単一のテーブルを作成します。これにより、乱雑なテーブルが作成され、各サブクラスを永続化するルールを知る責任がアプリケーション層にプッシュされます。データベースは、顧客がcustomer_idを持つ必要性を強制しません。ただし、結合がはるかに簡単になります。人にリンクする必要のあるテーブルは、人のテーブルにリンクできます。
スーパークラステーブル これは、共通の属性を単一のテーブルに抽出することによって、物事をクリーンアップします-例： "person"-サブクラス固有のフィールドをサブクラステーブルにプッシュします。したがって、スーパークラステーブルとして「person」があり、特定のサブクラスデータを持つ「contact」、「employee」、および「customer」テーブルがある場合があります。サブクラステーブルには、スーパークラステーブルにリンクするための「person_id」列があります。これはより複雑です-通常、データを取得するときに追加の結合が必要です-しかし、エラーが発生しにくくなります-「従業員」に無効な属性を書き込むバグでデータモデルを誤って破損することはありません。
サブクラスごとのテーブル -これはあなたが説明したことです。これにより、データモデルにかなりの量の重複が導入され、条件付き結合が発生することがよくあります。「person type =yの場合、テーブルxに結合する」ため、データアクセスコードが複雑になる可能性があります。