識別関係または非識別関係を決定する際の問題
私はこの質問を読みました： 識別関係と非識別関係の違いは何ですか？
しかし、まだよくわかりません...私が持っているのは3つのテーブルです。
- ユーザー
- オブジェクト
- ピクチャー
ユーザーは多くのオブジェクトを所有でき、個々のオブジェクトごとに多くの写真を投稿することもできます。私の直感は、これが識別関係であることを示しています。これは、オブジェクトテーブルにuserIDが必要であり、画像テーブルにobjectIDが必要だからです...
それとも私は間違っていますか？他のトピックの説明は、オブジェクトが実際にどのように接続されているかではなく、データベースがすでにコーディングされた後にデータベースを解釈する方法の理論的な説明に限定されています。データベースをどのように構築するかを考えるときに、識別するかどうかを決定する方法について少し混乱しています。
どちらも私との関係を特定しているように聞こえます。 1対1または1対多、および多対多という用語を聞いたことがある場合、1対関係は関係の識別、および- 多対多の関係は非識別関係です。
子供がその親を識別する場合、それは識別関係です。あなたが与えたリンクで、あなたが電話番号を持っているなら、あなたはそれが誰に属しているかを知っています（それは1つだけに属します）。
子供がその親を識別しない場合、それは非識別関係です。リンクでは、状態について言及しています。状態を、気分を表すテーブルの行と考えてください。 「幸せ」は特定の人を識別しませんが、多くの人を識別します。
編集：その他の実際の例：
- 多くの人が1つの住所に住んでいる可能性があるため、物理的な住所は識別できない関係です。一方、電子メールアドレスは（通常は）識別関係です。
- 社会保障番号は1人の人物にしか属していないため、識別関係です。
- Youtube動画へのコメントは、1つの動画にしか属していないため、関係を特定しています。
- 絵画のオリジナルには所有者が1人しかいませんが（識別）、多くの人が絵画の再版を所有している可能性があります（識別なし）。
それを視覚化する簡単な方法は、親なしで子レコードが存在できるかどうかを自問することだと思います。たとえば、注文明細には注文ヘッダーが存在する必要があります。したがって、注文明細には、そのキーの一部として注文ヘッダーIDが必要です。したがって、これは識別関係の例です。
一方、電話番号は、人が複数の電話番号を持っている場合でも、人の所有権がなくても存在する可能性があります。この場合、電話番号を所有する人は、所有者に関係なく電話番号が存在する可能性があるため、非キーまたは非識別関係になります（したがって、電話番号の所有者はnullになる可能性がありますが、注文明細の例では、注文ヘッダー識別子をnullにすることはできません。
NickC Said：1対関係は識別関係であり、多対多関係は非識別関係です
説明は私には完全に間違っているようです。あなたが持つことができます：
- 小野対1の非識別関係
- 1対多の非識別関係
- 1対1の識別関係
- 1対多の識別関係
- 多対多の識別関係
次のテーブルがあるとします：customer、products、およびfeedback。それらはすべて、cutomerテーブルに存在するcustomer_idに基づいています。したがって、NickCの定義により、多対多の識別関係は存在しないはずですが、私の例では、次のことがはっきりとわかります。 ：フィードバックは、関連する製品が存在し、顧客が購入した場合にのみ存在する可能性があるため、顧客、製品、およびフィードバックは識別する必要があります。
MySQL Manual を見て、MySQLWorkbenchに外部キーを追加する方法も説明しています。
マハディ、あなたの本能は正しいです。これは重複した質問であり、この賛成票の回答は正しくないか、完全ではありません。ここで上位2つの答えを見てください： 識別しないものを識別することの違い
識別と非識別は、アイデンティティとは何の関係もありません。親なしで子レコードが存在できるかどうかを自問してみてください。答えが「はい」の場合、それは識別できません。
子の主キーに親の外部キーが含まれるかどうかの中心的な問題。非識別関係では、子の主キー（PK）に外部キー（FK）を含めることはできません。
この質問を自問してください
- 親レコードなしで子レコードが存在できますか？
子が親なしで存在できる場合、関係は識別されません。 （ありがとう MontrealDevOne より明確に述べてくれて）
1対1の識別関係
社会保障番号はこのカテゴリにうまく適合します。 たとえば、社会保障番号は人なしでは存在できないと想像してみてください（おそらく実際には存在しますが、データベースには存在しません）person_idはpersonのPKになりますnameやaddressなどの列を含むテーブル。 （シンプルにしましょう）。 social_security_numberテーブルには、外部キーとしてssn列とperson_id列が含まれます。このFKはsocial_security_numberテーブルのPKとして使用できるため、識別関係になります。
1対1の非識別関係
大規模なオフィス複合施設では、フロアごとの部屋番号とPK付きの建物番号を含むofficeテーブルと、別のemployeeテーブルがある場合があります。従業員テーブル（子）には、officeテーブルPKのoffice_id列であるFKがあります。各従業員には1つのオフィスしかなく、（この例では）すべてのオフィスに1人の従業員しかいませんが、オフィスは従業員なしで存在でき、従業員はオフィスを変更したり、現場で作業したりできるため、これは非識別関係です。
1対多の関係
1対多の関係は、同じ質問をすることで簡単に分類できます。
多対多の関係
多対多の関係は常に関係を識別しています。これは直感に反しているように見えるかもしれませんが、私には耐えてください。 2つのテーブルlibaryとbooksを取ります。各ライブラリには多くの本があり、各本のコピーは多くのライブラリに存在します。
これがその理由と関係の識別です：これを実装するには、各テーブルの主キーである2つの列を持つリンクテーブルが必要です。それらをlibrary_id列および[〜＃〜] isbn [〜＃〜]列と呼びます。この新しいリンクテーブルには個別の主キーはありませんが、お待ちください。リンクテーブル内の重複レコードは無意味であるため、外部キーはリンクテーブルの複数列の主キーになります。 リンクは、親なしでは存在できません。したがって、これは識別関係です。わかってるよね？
ほとんどの場合、関係のタイプは重要ではありません。
そうは言っても、通常は自分が持っているものについて心配する必要はありません。各テーブルに適切な主キーと外部キーを割り当てるだけで、関係がそれ自体を発見します。
編集： NicoleC 、私はあなたがリンクした answer を読みました、そしてそれは私のものと一致します。私はSSNについて彼の主張を受け入れ、それが悪い例であることに同意します。そこで、別のより明確な例を考えてみます。ただし、データベースの関係を定義する際に実際のアナロジーを使用し始めると、アナロジーは常に崩壊します。 SSNが個人を識別するかどうかは重要ではなく、外部キーとして使用したかどうかも重要です。