1対多の関係で3番目のテーブルが必要なのはなぜですか？
良い一日、
Univeristyのdb教授は常に、片側の（0、M）との1対多の関係には、それらを関連付けるための3番目のテーブルが必要であると述べています。私は当時彼に尋ねなかったが今はできないが、なぜ彼がそれを主張するのか知りたいのか？ （特にmustの部分）。
単純なセンサー-メジャー-キャンペーンデータベースをモデル化していますが、本当に困惑しています。私のモデルについてどう思いますか、期待どおりに機能しますか？これは私の質問に関連しています。私は教えられたこととはまったく異なることをしていて、壊れたモデルを構築することを恐れているからです。
センサーには0またはMのメジャーがあり、メジャーは1つのセンサーに正確に属します。キャンペーンには0個またはM個のセンサーがあります。センサーは0個またはN個のキャンペーンに含まれている可能性があります。キャンペーンには0またはMのメジャーがあり、メジャーは1つのキャンペーンに正確に属しています。
教授のアプローチを使用して、6つのテーブル（各ペアの中間テーブル）を取得します。これらのテーブルのうち2つは必要ないようですが、それを理解することがこの質問の目的です。
彼を無視して、私はキャンペーンとセンサーをメジャーと別のテーブル（多対多の3番目のテーブル、私はInstrumentと呼びました）の両方で関連付けました。メジャーとインストルメントの両方がキャンペーンとセンサーへのFKを持っていることに注意して（インストゥルメントは空のメジャー、IMOのようになる）、そのような二重の関係を持つのは間違っていると思います。
私は潜在的に任意の組み合わせ（特定のキャンペーンのセンサー/メジャーと特定のセンサーのメジャー）をクエリする必要があり、簡単に（？）実行できると思います（メジャーが含まれている場合はサブクエリを使用）。また、キャンペーンやセンサーを削除すると、その測定値が削除され、on deleteカスケードを使用して簡単に達成できるようにしたいと考えています。欠点は何でしょうか？
初心者の質問でごめんなさい、どんな助けでもありがたいです。私はすでにグーグルで何も見つかりませんでした。おそらく間違った用語を使用しました。ここでスパムするふりはしていません。おかげで、少なくともGoogle検索へのよりスマートなクエリが評価されます。
あなたの教授が本当に言ったことを私は知りません。あなたのモデルを理解しているかどうかはわかりません。しかし、おそらく以下は興味深いです。
記事 T.J Teory、D。Yang、およびJ.P. Fryによる拡張エンティティリレーションシップモデルを使用したリレーショナルデータベースの論理設計方法論 は、エンティティリレーションシップダイアグラムをリレーション（およびテーブル）に変換する方法について説明しています。図8f（pdfのp 13）には、1：n関係の次の例があります。
各エンジニアは最大1人の秘書を持つことができます。 1人の秘書が数人のエンジニアのために働くことができました。
エンティティ「secreatry」と「engineer」の間には「work-for」関係があります。
- 「秘書」「働く」「エンジニア」。
- 各「エンジニア」には、最大で1人の「秘書」がいて、「働く」ことができます。 「エンジニア」が彼女のために「働く」「秘書」を持っていないかもしれません。
- 「秘書」は「働く」ことができ、「エンジニア」は1人、複数、または「なし」
記事では、著者はこれを次のように表現することを提案しています
ENGINEER(*EMP-NO,...,SEC-EMP-NO)
SECRETAY(*EMP-NO,...)
*でマークされたフィールドはキーです。フィールドSEC-EMP-NOは、SECRETARYからのEMP-NOを参照し、nullabelです。
しかし、 null値は関係で許可されるべきではない という意見を持つ著者もいます。 null値を避けたい場合は、次のモデルを作成するための3番目の関係が必要です。
ENGINEER(*EMP-NO,...)
SECRETAY(*EMP-NO,...)
WORKS-FOR(*ENG-EMP-NO,SEC-EMP-NO)
ENG-EMP-NOはENGINEERのEMP-NOを参照し、SEC-EMP-NOはSECRETARYのEMP-NOを参照します。
「エンジニア」が「彼女のために働く」「秘書」を常に持っている場合、2つの関係を持つ最初の表現にはnull値が含まれません。
編集：図にリンクするコメントが投稿に見つかりました（ http://i.imgur.com/gIG2D3h。あなたの教授のjpg ）：実際、彼はここで説明されているようにnull値を避けるために3番目のテーブルを導入しています。
分析と設計を注意深く区別したい。データベースに格納される各値から「意味がある」ように主題を分析します。データベースを機能させるためのコンテナー（テーブル）とリンケージ（外部キー）を作成し、分析中に検出した値を保持するために、データベースを設計します。
私はあなたの主題を知りません。私はあなたの言葉に私の理解を基にしています：
センサーには0またはMのメジャーがあり、メジャーは1つのセンサーに正確に属します。キャンペーンには0個またはM個のセンサーがあります。センサーは0個またはN個のキャンペーンに含まれている可能性があります。キャンペーンには0またはMのメジャーがあり、メジャーは1つのキャンペーンに正確に属しています。
これは私が混乱したところです。
分析A：3つのエンティティ（センサー、メジャー、およびキャンペーン）と2つの関係（センサー-メジャーとメジャー-キャンペーン）があります。センサーとキャンペーンには1つまたは複数の測定値が共通する場合があるという事実が反映されて、センサーとキャンペーン間には間接的な関係があります。
分析B：3つのエンティティ（センサー、メジャー、キャンペーン）と3つの関係（センサー-メジャー、メジャー-キャンペーン、およびセンサー-キャンペーン、つまり計測器）があります。センサーとキャンペーンには1つまたは複数の測定値が共通する場合があるという事実が反映されて、センサーとキャンペーン間には間接的な関係があります。センサーとキャンペーンの間には、間接的な関係の有無に関係なく、直接的な関係もあります。
現在、これらの分析の1つまたは両方は、明らかに間違っています。私はAの方に傾いています。しかし、それはあなたの呼び出しです。
なぜ分析をそれほど重視するのですか？なぜなら、分析が間違っていると、設計はかなり破滅してしまうからです。
Aの解釈には、3つのテーブルと2つの外部キーのみが必要です。 2つの外部キー（SensorIdとCampaignId）はどちらも、他の列と共にMeasuresテーブルに入力されます。
B解釈では、MeasuresとInstrumentsの間の1つのリンケージの代わりに、表示する単一のリンケージの代わりに、Measureをセンサーとキャンペーンに直接結び付ける2つの外部キーがあることを除いて、あなたが描いたテーブルのような4つのテーブルが必要です。
第一に、あなたは誤解している、または教授のポイントを誤って記憶していると思います。 1対多（1-m）の関係では、片側がゼロの場合、それは「m」側でなければなりません。 1つは、まあ、1つです。定義により、ゼロを含む他の値にすることはできません。 1 mの関係では、「多く」にはゼロが含まれると一般に理解されています。「1」レコード以外の理由で最初にレコードを挿入する必要がない場合、最初の関連レコードが挿入されるまで、関係カウントはゼロになります。
多対多（m-n）の関係では、 番目のテーブルが必要 ですが、どちらかの側の参照カウントがゼロの場合は、異常な状態になるため、これを防ぐ必要があります。
教授がそのような主張をした場合、彼は確かに例を提供した。そのような例について何か覚えていますか？
あなたの図に関する限り、あなたの説明（コメントの必要な説明を含む）によれば、独立したエンティティはInstrumentとCampaignです。センサーは計測器に関連し、メジャーはセンサーとキャンペーンに関連します。
これにより、少なくとも測定の値とタイムスタンプの属性が追加された状態で、センサーとキャンペーン間のm-n関係を確立する交差テーブルが測定されます。
さて、これは特定の設計上の制約よりもビジネスルールです。センサーを削除すると、そのセンサーに関連付けられているすべての測定値が削除されます。これは、そのセンサーで行われた過去のすべての測定値がデータベースから消えることを意味します。それは本当にあなたが起こりたいことですか？おそらく違います。正確な履歴を維持することが最も確実に必要になります。
ただし、キャンペーンの削除時にすべての測定値を削除することは許可される可能性があります。しかし、繰り返しになりますが、これらはビジネスルールです。これらはあなたの決定ではありません。
更新：すべてのコメントと参照を読んで、私は答えを見つけたと思います-または少なくとも混乱を少なくする方法でそれを表現できます。
1対多（1-n）の関係は、「XエンティティはエンティティYに対してゼロまたは1つの関係を持ち、エンティティYはエンティティXに対してゼロ、1つまたは多くの関係をもつ可能性がある」ことを私たちは皆知っています。 @ miracle173の例を使用するために、エンジニアには最大1人の秘書が割り当てられ、秘書は多くのエンジニアに割り当てられる場合があります。
これは通常、「1つの」タプルのポインタで実装されます。
Engineer( EmpID, SecyID,...)
Secretary( EmpID, ...)
SecIDフィールドが[〜＃〜] null [〜＃〜]の場合、そのエンジニアには秘書が割り当てられていません（ゼロ条件）。しかし、[〜＃〜] null [〜＃〜]sの有用性について、あいまいで、主に学術的な議論があります。 （私はその議論の主張の前提に同意しませんが、それは完全に異なる主題です。）miracle173のリンクのテキストは、[〜＃〜] null [〜の使用として問題を誤って示しています。 ＃〜]sの関係。代わりに、一般的には[〜＃〜] null [〜＃〜]の使用に関する問題です。
しかし、この特定の関係における[〜＃〜] null [〜＃〜]の使用を排除したいとしましょう。
1対多の関係は、特別な交差テーブルを使用して実装することもできます。
create table Eng_Secy(
EngID int not null references Engineers( EmpID ),
SecyID int not null references Secretaries( EmpID ),
constraint UQ_Eng_Secy_Eng unique( EngID )
);
（一意の制約は、EngIDをPKにすることで実装することもできます。どちらの方法でも、エンジニアは1度しかリストできません。）
これは、技術者と秘書間の1対nの関係を完全に実装しますが、1つの違いがあります。秘書が割り当てられていないエンジニアの場合、エンジニアタプルの[〜＃〜] null [〜＃〜]の代わりに、単に交差テーブルにそのエンジニアのレコードがまったくありません。
したがって、実際のアサーションは次のとおりです：1-n関係のゼロ条件を表すために-[〜＃〜] nullを使用せずに[〜＃〜]値-その関係は、3番目のテーブルを介して実装する必要があります。次に、ゼロ条件は、そのテーブルにエントリがないことで表されます。
それは教授が言っていたのですか？