3

次のシナリオを検討してください。ペットの飼い主は複数の猫を飼っている場合もあれば、複数の犬を飼っている場合もあります。一部の犬は、同じ所有者の一部の猫と関係があります (つまり、ケンカします:-)) 。

次のリレーショナル設計では、異なる所有者の猫と犬が関連している可能性があるため、この制限はありません。リレーショナル設計によってこの制限を課す方法はありますか?

ここに画像の説明を入力

4

1 に答える 1

1

識別関係を使用して、所有者の PK を菱形の依存関係の「側面」と「底」の両方に移行する必要があります。

ここに画像の説明を入力

は 1 つのフィールドにすぎないためCatDog.OwnerId、行ごとに複数の所有者を識別することはできません。また、両方の種類の動物に対する FK であるため、この 1 つの所有者は猫と犬の両方の所有者と一致する必要があります。

言い換えれば、猫は同じ飼い主の犬にのみ関係を持つことができます。

ご覧のとおり、猫と犬は、おそらく予想していたものとは異なって識別されます。猫は飼い主によって識別され、同じ飼い主の他の猫とは によって区別されますCatNo。犬についても同様です。

「より単純な」キーが必要な場合は、いつでも代理キーを追加することができます。または、代わりに、UNIQUE 制約を移行する目的でのみ完全に削除CatNoして「悪用」することもできます。DogNoOwnerId

ここに画像の説明を入力

(U1は UNIQUE 制約を示します。)

動物をより簡潔に識別できるようになりましたが、欠点があります。一意性を強制するという観点からすると、UNIQUE 制約は完全に冗長です。これは PK のスーパーセットであり、PK はそれ自体で一意性を適切に強化しています。UNIQUE 制約の唯一の目的は、 (および)CatDog.OwnerIdを参照できるようにすることです。ほとんどの DBMS では、外部キーの親エンドポイントをキーにする必要があります。Cat.OwnerIdDog.OwnerId

一部の DBMS ( Oracle ) では、1 つのインデックスのみを使用して PK と UNIQUE 制約の両方を適用できますが、ほとんどの場合はそうではありません。インデックスを追加するたびに、挿入/更新/削除のパフォーマンスが低下します。

于 2012-09-27T17:31:42.930 に答える