別のテーブルの同じ主キーを参照する2つの外部キーがテーブルにある場合、これはどのようなタイプの関係ですか?1対多?または1対1?
例えば:
テーブル作成者には主キーAUTHOR_IDがあります
テーブルブックには、2つの外部キーPRIMARY_AUTHOR_IDとSECONDARY_AUTHOR_IDがあり、どちらもAUTHOR_IDを参照します。
これはどのような関係ですか?
*著者の本の例をより適切に処理できることはわかっています。例としてこれらのフィールドを使用しています。
別のテーブルの同じ主キーを参照する2つの外部キーがテーブルにある場合、これはどのようなタイプの関係ですか?1対多?または1対1?
例えば:
テーブル作成者には主キーAUTHOR_IDがあります
テーブルブックには、2つの外部キーPRIMARY_AUTHOR_IDとSECONDARY_AUTHOR_IDがあり、どちらもAUTHOR_IDを参照します。
これはどのような関係ですか?
*著者の本の例をより適切に処理できることはわかっています。例としてこれらのフィールドを使用しています。
書籍とその著者の間に1..[1-2]の関係を設定しているようです。つまり、本と主著者の間には1..1の関係があり、本と副著者の間には事実上1..[0-1]の関係があります。その結果、あなたは本とその著者との間に1..[1-2]の関係を持っていると主張することができます。
明らかに著者は複数の本を持つことができるため、これは方程式の一方向のみを考慮します。したがって、実際の関係は、表記に応じて、本(複数形)と著者の間のN..[1-2]のようになります。使用する方法論。
質問できるように、例を考案したばかりだと思います。この構成の使用に関しては、N..M関係のより一般的な構成(Booksとその作成者の間)を検討する必要があることをお勧めします。設計の観点から、あなたがしたくないことの1つです。構造表現にビジネスロジックをハードコーディングしすぎることはありません。最初のビジネスルールでは、限られた(1..1または1..N)関係があり、後でビジネス要件(微妙にまたはおそらくそうではない)があることを示唆するのが一般的です。微妙に)N..Mをモデル化できるようにする必要があるように変更します。これは、スキーマの変更を意味します。これは確かに可能ですが、場合によっては回避可能であり、脆弱性を減らすオプションがあります。時期尚早の最適化がすべての悪の根源であるという別の言い方です。)
N..Mに到達するには、BOOKSテーブルから両方の外部キーを削除し、3番目のテーブルBOOKS_AUTHORSを導入します。これは、テーブルへの外部キーを持ちます。 BOOKS(BOOK_ID)ともう1つはAUTHORS(AUTHOR_ID)です。また、著者の順序を指定したり、著者を順序付けたり、一次、二次、三次などの列を追加したりすることもできます。
(注:テーブルはコレクションであり、BookはBOOKSテーブルのメンバーとしての行であるため、複数形を使用してテーブルに名前を付ける傾向があります。もちろん、OOPからは、を使用してクラスに名前を付ける傾向があります。単数形、たとえばBOOKの場合、BookはBOOKクラスのインスタンスです。ほとんどの場合、用語にすぎません。)