多対多結合に関連付けられたテーブルの子のサブセットのテーブルを結合します。

Question

多対多関係の標準結合テーブルがあります。主テーブルは2つのフィールドの複合キーです。 2つのフィールドは、結合された各テーブルのIDです。

結合されたテーブルの1つに、別のテーブルにある多くの子があります。標準的な一対多の関係。

これはすべて問題ありません。しかし今、私はこれらの子のサブセットを指定して、多対多の関係の遠い側のテーブルに関連付ける必要があります。具体的には：

---

表：競馬場
PK：ID

表：厩舎
PK：ID

表：StablesToRaceCourses

RaceCourseIDと
StableID

表：馬
PK：ID
FK：StableID

---

PKは、2つの外部キーの複合キーであります

それはすべて罰金です - 馬は単一の安定地に属し、競走馬はいくつかの厩舎にアクセスできます。しかし、難しい部分は：各RaceCourseは、それがアクセスする安定から馬のサブセットを選択することができます。理想的には、この新しいテーブルは、馬が馬の安定に既にリンクされている馬コースを関連付けることのみを許可します。

ような何か：

表：HorsesForRaceCourses
FK：StablesToRaceCourses.StableID
にStableIDリンク FK：馬にHorseIDリンク
FKをStablesToRaceCourses.RaceCourseIDするRaceCourseIDリンクに.ID

ここで、PKは3つの外部キーの複合です。これは妥当と思われますか？私はMS Accessを使用していますが、 "プライマリテーブルの参照フィールドに一意のインデックスが見つかりません"という私に参照整合性を強制することはありません。このテーブルからStableIDを削除して（そしてRaceCourseに直接リンクして）、これを動作させることができますが、RaceCourseがすでにそのHorseのStableに関連付けられていない限り、RaceCourseがHorseに関連付けられていないことを保証するアプリケーションロジックに頼る必要があります。たぶん私はこのためにデータベースをあまりにも多く求めているのでしょうか？

Answer 1

これは非常に良い質問です。

データベースにできるだけ多くの関係を強制させる非常に良い理由があります。しかし、データベースの宣言的性質には限界があります。従業員テーブルと組織単位テーブルがあるとします。オルグニットには多くの従業員がいますが、最大で1つのタイプのスーパーバイザーもいます。宣言的に世界でもっとも簡単なことではありません。

あなたが何を記述しているかは、概念的には「関連」と呼ばれるものです。ビデオ、店舗、顧客を考えてみましょう。 < - OMGそう、1990年代だよ。ストアには多くの映画があります。店には多くの顧客がいます。レンタルテーブルには、3つのPKがすべて含まれています。レンタルテーブルには、日付と期日、有料料金なども含まれています。

PowerDesigner Meriseモデリング方法論の文書

アソシエーションは、各々が明確に定義されたオブジェクトを表すいくつかのエンティティを接続するために使用され、そのように明確に別のエンティティによって表されることがないかもしれないイベントによって連結されている。

あなたのケースでは、 "選択"はそのイベントです。 "RaceCourseは"

ビデオレンタルの例では、おそらく顧客と店舗との関連性があり、その店舗に「所属」している顧客のみがレンタルできます。その事実は私のレンタルテーブルを変更しません。

OK、これはあなたのケースに似た正確なものではありませんが、その点が分かります。

純粋なモデリングの観点からは、複数の馬を所有する馬小屋があります。複数の馬小屋と厩舎で働くレーストラックがあります。それは3番目の通常のものの終わりです。

これで、選択というプロセスができました。私があなただったら、これをスタースキーマとしてモデル化します。

「事実」に加えて、3つのキーをすべて入れます。日付選択、日付選択の終了、契約番号、安定した日付の通知など。これにより、いつどの馬の日付などをいつレポートするのかが簡単になります。その情報は、あなたがStableのためのFKを含み、それを見つけるために参加することに頼っていないので反映されます。

Answer 2

私はAccessでこれをどのようにしても試してみましたが、「複合外来キー」はSQL Serverでのアクセス方法では機能しません。あなたはそれらを設定することができます、彼らはちょうどこの場合には動作しません。私はこれについて実際の情報源を見つけることはできませんが、このアプローチを試みたデータベースの問題を研究した後、古い帽子がこれを避けることを知っていることを示す多くのフォーラム投稿を読んだことがあります。

外部キーによって参照される必要がある任意のテーブルで複合主キーを使用する代わりに、通常はIDと呼ばれる単一フィールドAutonumber主キーを使用します。さらに、複数のフィールドに一意のインデックスを追加すると、はとなります。

これは機能的には同等ですが、「実際の」外部キーを取得するためにクエリでさらにテーブルを結合する必要があることがあります。