継承と再帰による拡張されたERモデルスーパータイプ/サブタイプモデリングの問題
投稿する前に、インターネットで良い解決策を探し、この投稿を3日間続けて作成し、この投稿の前にそれについて考えていました。ですので、見逃したり、間違えたりした場合は、ご理解ください。
SQL Server 2014とVisual Studio 2013を使用して請求書（PDF形式）を作成するための請求データベースをモデル化する必要があります。私の会社は、他のビジネス、つまりビジネスエンティティのみを操作および操作しています。
次の状況をモデル化する方法がわかりません。
販売者（サービスプロバイダー）が顧客に請求書を発行XOR代表者（XOR =排他的OR）
会社とそのすべてに関する情報を追跡する必要があります。販売者、顧客、または担当者は、最初は同じ属性を持っています。私はSellerID、CustomerID、RepresentativeIDのようなそれらの識別子を思い付くことができますが、スーパークラス（会社）からIDを継承しているため、それが考えられないので、それが正しいことかどうかわかりませんその他の一意の属性。
次のようなビジネスルールがあります。
- 販売者（現時点では1つのみ-私の会社）は、顧客または担当者に請求書を発行します。
- 顧客は1つのみまたはなし代表を持つことができ、1人の代表は多くの顧客を表すことができます。
- 代表者はお客様、会社は
- 発行された請求書と会社に関する情報を追跡する必要があります。もちろん、銀行口座、請求書項目、サービス、契約（契約や注文の場合もあります）などの他のエンティティもあります。
ここにエンティティがあります：
- 会社（スーパータイプ）
- 販売者（サービスプロバイダー）（会社のサブタイプ）
- 顧客（会社のサブタイプ）
- 代表（顧客のサブタイプまたは会社のサブタイプ-詳細については写真を参照してください...）（おそらくこれは再帰的な関係である必要があります）
質問：
- ここにスーパータイプ/サブタイプが必要ですか（サブタイプエンティティには一意の属性がないため、頭痛の種になるため）？
- 再帰関係にある1つのエンティティで継承を実装する方法-たとえば、顧客/担当者が再帰関係にある場合（リレーショナルテーブルの例が必要）
- いくつかの例（データを含むテーブルのような）を使ってリレーショナルソリューション（EERからリレーショナルへ）を教えてもらえますか？.
私は次のEERモデルを考え出しました：
そして今、私は次の2つのモデリングオプションの1つを欠いています（よりうまく機能し、初心者に優しくない他のいくつかの提案）...
これは、継承と部分的な分離を備えたfull_disjointです。
そして、これは完全に重なり合っています（画像の説明に「p」が1つ欠けています）。
あなたのビジネスルールの1つに注意を喚起します。代表者は顧客であり、会社です。
これはスーパークラス/サブクラスの状況のように思えますが、ERモデリングに関しては、EERダイアグラムは手元にあると思います。物事が面白くなり始める（そして少し厄介な）のは、ERモデル（抽象的で実装に中立）からリレーショナルモデル（そうではない）に切り替えようとするときです。
この時点で、リレーショナルモデルに継承が組み込まれていないという事実を補う、よく知られたいくつかの手法から選択する必要があります。元の質問にこのタグを含めることができます： subtypes
簡単に言うと、単一のテーブルの継承、クラステーブルの継承、共有主キーの3つの手法があります。
単一のテーブル継承は、すべてのサブクラスを1つのテーブルにまとめます。特定のインスタンスに関連しないデータはNULLのままになります。
クラステーブルの継承には、スーパークラス用に1つのテーブルと、各サブクラス用に1つのテーブルがあります。一般化されたデータはスーパークラステーブルに入り、特殊化されたデータは適切なサブクラステーブルに入ります。
共有主キーは、各サブクラスとスーパークラス間の関係の1対1の性質を強化します。また、データベースの別の場所にある外部キーが、どのサブクラスに属しているかがわからなくても、スーパークラスを参照できます。
このテーマの適切な扱いについては、WebでMartin Fowlerの扱いを調べてください。
フィードバックに基づいて編集
どのERモデルが「正しい」かという問題は、通常、データベース設計チームが主題を分析し、それが「現実の世界」でどのように機能するかを表すモデルを考え出すことによって決定されます。これは、データベースがまだ設計されていないことを前提としていますが、ビジネス自体はすでに設計されており、ビジネスデザインは変更されません。あなたのコメントは、データベースだけでなくビジネス自体を設計（または再設計）していると思います。もしそうなら、問題はデータベース設計の専門知識の外にあります。
あなたが尋ねた質問をより具体的に扱うには：
- ここにスーパータイプ/サブタイプが必要ですか（サブタイプエンティティには一意の属性がないため、頭痛の種になるため）
サブタイプに特化した属性がない場合、（データの観点から）継承は必要ありません。したがって、リレーショナルデザインに影響はありません。頭痛の種をしないでください。あなたのビジネスに合ったモデルを選び、手放してください。
- 再帰関係にある1つのエンティティで継承を実装する方法-たとえば、顧客/担当者が再帰関係にある場合（リレーショナルテーブルの例が必要）
お客様と担当者が同じエンティティの場合は、共通の名前を付けます。 2つの名前を持つ1つのエンティティは混乱します。エンティティが異なる場合は、質問を言い換えます。質問1に対する私の回答から、継承の実装が必要なのはなぜですか？
「再帰的関係」と「再帰的関係」は同じものですか？そうでない場合は、質問を明確にしてください。
- いくつかの例（データを含むテーブルのような）を使ってリレーショナルソリューション（EERからリレーショナルへ）を教えてもらえますか？.
それが私が最初に答えていたと思っていたものです。ファウラーによる継承/関係の問題の扱いは、Webで入手できます。 ここ および ここ 。彼の例は、顧客や代表ではなく、選手やクリケット選手に関するものですが、リレーショナルシステムでの継承（実際には疑似継承）の実装に関する問題は、ケースに依存しません。