web-dev-qa-db-ja.com

1：1：Nの三項関係をリレーショナルスキーマにマッピングする

（概念的）n項関係の（論理）関係へのマッピングについて質問があります。

メンバー、機器、タイムスロットの3つの強力なエンティティタイプと、それらの間に予約という名前の関係があると仮定します。

属性は関係ありません（IDキー属性があると仮定してください）が、カーディナリティの比率は次のとおりです。

enter image description here

つまり：

  • メンバーは複数のタイムスロット（N）で特定の機器を予約できます。
  • 機器は特定のタイムスロットで1人のメンバー（左側の1）だけが予約できます。
  • メンバーは、タイムスロットごとに1つの機器のみを予約できます（右側の1つ）。

また、参加に制限はありません。

表記全体を見渡して（私は信じています）：

enter image description here

この関係をリレーショナルデザインの関係にマッピングしようとしています。次のようになります。

RESERVES
(MEMBER.Id, EQUIPMENT.Id, TIME_SLOT.Id)

3つの属性がそれぞれの外部キーである場合、MEMBER、EQUIPMENTおよびTIME_SLOTに対応する関係。

しかし、何が主キーであるべきでしょうか？

Elmasri、Ramez、Shamkant B. Navathe。 2015.データベースシステムの基礎（第7版）。ピアソン。読み取り、p。 296：

Sの主キー[n項関係Rから関係モデルへのマッピングから生じる関係]は、通常、参加するエンティティタイプを表す関係を参照するすべての外部キーの組み合わせです。ただし、Rに参加しているエンティティタイプEのカーディナリティ制約が1の場合、Sの主キーには、E（…）に対応するリレーションE 'を参照する外部キー属性を含めないでください。

このレシピを盲目的に適用すると、TIME_SLOT.Idだけが主キーであることがわかります。これはまったく意味がありません（2つの異なる機器を同時に！）.

3つの属性が主キーであることは、1つの機器を同じタイムスロットで複数回予約することができないという事実を反映していません。

database-designerd
2
Clément

リレーションの候補キーは、リレーションのすべてのタプル（レコード）が他のすべてのタプルの値とは異なる値を持つ必要があるような属性のセットです。

主キーは、関係のさまざまな候補キーから選択することも、関係のすべてのレコードを一意に区別するために考案された人工的な識別子である代理キーにすることもできます。

確かに、主キーはnotを厳密なスーパーキーにする必要があります。つまり、1つ以上の属性を削除して、残りの属性がリレーションのすべてのタプルを一意に識別できるようにするキーです。

次に、主キーを見つけるために、最初に尋ねる必要があります。この関係の候補キーはどれですか。この場合、候補キーは_(EQUIPMENT_ID, TIME_SLOT_ID)_と_(MEMBER_ID, TIME_SLOT_ID)_の2つだけです。実際、それらのそれぞれは、関係のすべてのタプルに対して一意である必要があります。そして、他の候補キーはありません（実際、_(EQUIPMENT_ID, MEMBER_ID)_は厳密なスーパーキーですが、_(MEMBER_ID, EQUIPMENT_ID, TIME_SLOT_ID)_は、すでに述べたように、単一の属性として重複する要素を持つことができます）。

したがって、この場合の主キーは次のようになります。a）カップル_(EQUIPMENT_ID, TIME_SLOT_ID)_; b）カップル_(MEMBER_ID, TIME_SLOT_ID)_; c）_RESERVES_ID_のような代理キー。別の属性を代理キーとして導入する特別な理由がない場合は、2つの属性の組み合わせのいずれかを主キーとして使用し、他のペアを一意として宣言できます。

最後に、正規化理論を適用すると、2つの重要な機能依存関係_MEMBER_ID, TIME_SLOT_ID -> EQUIPMENT_ID_および_EQUIPMENT_ID, TIME_SLOT_ID -> MEMBER_ID_があり、それらから関係がBoyce Codd正規形であり、2つのカップルが一意であることを導出できます。候補キー。

[〜＃〜]編集済み[〜＃〜]

あなたの質問が本当に：例のようなカーディナリティを持つ一般的な三元関係の場合、そのような関係の候補キーである3つの外部キーとの関係として表されますか？

答えは、カーディナリティーによって推論される機能の依存関係を考慮することで得られます。 3つの属性（外部キー）A、B、およびCを呼び出して、2つの値BCに対して最大でAの値、2つの値ACに対して最大でBの値、および任意の数を持つことができると仮定します。いくつかの値ABに対するCの値のセット（これは、例では1：1：Nの関係をモデル化したもので、Aはメンバー、Bは補数、Cはタイムスロットです）。これは、機能の依存関係に関して次のように変換できます。

_BC -> A
AC -> B
_

（技術的には、これは関係を保持する依存関係のセットのカバーと呼ばれます。つまり、この場合、他の重要な機能依存関係は保持されません）。

このことから、関係にはACとBCの2つの候補キーしかないことが簡単にわかります。したがって、リレーショナルデータベースシステムの観点から、それらのいずれかを主キーとして選択し、他の一意の制約を宣言できます。

3
Renzo

制約とインデックスだけでこれを実装しようとしている場合、私には、この動作を実施するために同じデータ項目に対して複数の制約が必要になるように思えます。以下で説明します。

メンバーは複数のタイムスロット（N）で特定の機器を予約できます

3つのフィールドすべてに主キーを配置すると、このルールの要件を満たすことができます。これにより、3つのフィールドすべての組み合わせが1回だけ発生するように強制されます。

機器は、特定のタイムスロットで1人のメンバー（左側の1つ）だけが予約できます。

これを実現するには、TIME_SLOT.idおよびEQUIPMENT.idに対する一意の制約が必要です。これにより、タイムスロットごとに1回だけ機器を予約できるようになります。

メンバーは、タイムスロットごとに1つの機器のみを予約できます（右側の1）。

これを実現するには、TIME_SLOT.idおよびMEMBER.idに対する一意の制約が必要です。これにより、メンバーは同じ時間帯を複数回予約することができなくなります。

これにより、次のようなテーブルが表示されます。

CREATE TABLE RESERVES
(
   MEMBER_ID INT NOT NULL REFERENCES MEMBER(ID),
   EQUIPMENT_ID INT NOT NULL REFERENCES EQUIPMENT(ID),
   TIME_SLOT_ID INT NOT NULL REFERENCES TIME_SLOT(ID),

   PRIMARY KEY(MEMBER_ID, EQUIPMENT_ID, TIME_SLOT_ID),
   UNIQUE KEY (MEMBER_ID, TIME_SLOT_ID),
   UNIQUE KEY (EQUIPMENT_ID, TIME_SLOT_ID)
);

私はリレーショナル理論のコースを一度も行ったことがないので、以下がナイーブに見えても、あなたの関係が実際には1：1：Nではない場合は失礼します。すべてのエンティティが複数回発生する可能性があり、関係の組み合わせのみが制約を生成するためです。

したがって、MEMBER、EQUIPMENT、TIME_SLOTの順序を想定します。

  • 主キーは実際には1:1:1 です。
    • 1人のメンバーが1つの時間帯に1つの機器を予約できます。
  • セカンダリキー1:0:1 [.____があります。]
    • 1人のメンバーが1つの時間枠を予約できます。
  • そして、3番目のキー0:1:1
    • タイムスロットごとに1つの機器を予約できます。
2
Mr.Brownstone