「CommonChild」エンティティがサブタイプ A または B のいずれかの子になることができるが、C ではないという上記の問題を考えてみましょう。リレーショナル [SQL] データベースで物理モデルを設計するにはどうすればよいでしょうか?
理想的には、ソリューションは...
- CommonChild とそれに関連するサブタイプとの間の識別関係。
- 1:N の関係。
可能な解決策
サブタイプをスーパータイプに追加し、サブタイプ A と B を新しいサブタイプの下に移動します。CommonChild は、新しく作成されたサブタイプに対して FK 制約を持つことができます。上記の場合は機能しますが、サブタイプ A および C との関係を持つことができるが B とは関係を持たない追加のエンティティが追加された場合は機能しません。
CommonChild と SuperType の間に FK 制約を追加します。新しいタプルを CommonChild に許可する前に、スーパータイプの識別子に対してトリガーまたはチェック制約 (UDF を使用) を使用します。単純なように見えますが、CommonChild はほとんど新しいサブタイプそのもののように見えます (そうではありません)。
私のモデルには根本的な欠陥があります。改造すれば問題はなくなるはずです。
他の可能な解決策、または既に提案した上記の解決策のいずれかの確認を探しています。
ありがとう!
編集
Branko Dimitrijevic が提供する専用の外部キー ソリューションを実装します (受け入れられた回答を参照)。
この場合、次のように少し変更します。
- スーパータイプ、サブタイプ、および「CommonChild」はすべて同じ PK を持ちます。
- PK は 3 列のコンポジットです。
変更は、サブタイプと "CommonChild" (Dimitrijevic によって提供された正確なモデルから "CommonChild" の属性を差し引いたもの) の間で排他的 FK 制約を適用することだけが役割を持つ中間テーブルを作成することです。CommonChild の PK には、中間テーブルに対する通常の FK 制約があります。
これにより、"CommonChild" が 2 セットの 3 列の複合 FK を持つことができなくなります。さらに、識別関係はスーパータイプから「CommonChild」まで維持されるため、[読み取り] クエリは中間テーブルを完全に無視できます。