特定または非特定の関係の決定に関する問題

StackOverflow https://stackoverflow.com/questions/1216805

質問

この質問を読みました：違いは何ですか識別関係と非識別関係？

しかし、まだよくわかりません... 私が持っているのは3つのテーブルです。

  1. ユーザー
  2. オブジェクト
  3. 写真

ユーザーは多くのオブジェクトを所有でき、個々のオブジェクトごとに多くの写真を投稿することもできます。 私の直感では、これが識別関係であることを教えてくれます。オブジェクトテーブルにはuserIDが必要で、写真テーブルにはobjectIDが必要だからです。

または私は間違っていますか？他のトピックの説明は、実際のオブジェクトの接続方法ではなく、データベースが既にコード化された後のデータベースの解釈方法の理論的説明に限定されます。データベースをどのように構築するかを考える際に、識別と非識別の決定をどのように行うかについて少し混乱しています。

役に立ちましたか？

解決

どちらも私との関係を識別するような音です。 1対1または1対多、多対多という用語を聞いた場合、 1対関係は関係を識別する、および< strong>多対多の関係は、身元不明の関係です。

  • 子が親を識別する場合、それは識別関係です。指定したリンクで、電話番号がある場合は、その電話番号が誰に属しているかがわかります（電話番号は1つだけです）。

  • 子が親を識別しない場合、それは非識別関係です。リンクでは、状態に言及しています。状態は、気分を表す表の行と考えてください。 ＆quot;ハッピー＆quot;特定の人を特定するのではなく、多くの人を特定します。

編集：その他の実際の例：

  • 1つの住所に多くの人が住んでいる可能性があるため、物理的な住所は非特定の関係です。一方、メールアドレスは（通常は考慮される）識別関係です。
  • 社会保障番号は、1人の個人にのみ属しているため、識別関係です
  • Youtube動画のコメントは1つの動画にのみ属しているため、関係を特定しています。
  • 絵画のオリジナルには所有者が1人しかいない（識別）が、多くの人が絵画の再版を所有している（非識別）。

他のヒント

それを視覚化する簡単な方法は、親なしで子レコードが存在できるかどうかを自問することだと思います。たとえば、注文品目には注文ヘッダーが必要です。したがって、注文品目にはキーの一部として注文ヘッダー識別子が必要であるため、これは識別関係の例です。
一方、電話番号は人の所有権がなくても存在できますが、人は複数の電話番号を持っている場合があります。この場合、電話番号は所有者に関係なく存在できるため、電話番号の所有者は非キーまたは非識別関係です（したがって、電話番号の所有者はnullになりますが、注文品目の例では、注文ヘッダー識別子をnullにすることはできません。

  

NickC Said：1対多の関係は特定の関係であり、多対多の関係は非特定の関係です

説明は私にはまったく間違っているようです。次のものを使用できます。

  • Ono-to-Oneの非識別関係
  • 1対多の非識別関係
  • 1対1の識別関係
  • 1対多の識別関係
  • 多対多の識別関係

customer 、 products 、および feedback というテーブルがあるとします。それらはすべて、 cutomer テーブルにある customer_id に基づいています。したがって、 NickC の定義では、多対多の識別関係は存在しないはずですが、私の例では、次のことが明確にわかります。フィードバックは、関連する製品が存在し、顧客によって購入されているため、顧客、製品、およびフィードバックが識別される必要があります。

MySQLマニュアルをご覧ください。 MySQL Workbenchに外部キーを追加する方法を説明します。

マフディ、あなたの本能は正しい。これは重複した質問であり、この投票された回答は正しくないか完全ではありません。 ここで上位2つの答えを見てください。 非識別の識別の違い

識別と非識別は、識別とは関係ありません。 親なしで子レコードが存在できるかどうかを自問してください。答えが「はい」の場合、それは非特定です。

子の主キーに親の外部キーが含まれるかどうかの中心的な問題。非識別関係では、子の主キー（PK）に外部キー（FK）を含めることはできません。

この質問を自問してください

  • 子レコードは親レコードなしで存在できますか？

親がなくても子が存在できる場合、関係は特定されません。 （ MontrealDevOne より明確に述べてくれてありがとう）

1対1の識別関係

社会保障番号はこのカテゴリにうまく適合します。たとえば、社会保障番号は人なしでは存在できないことを想像してみましょう（おそらく実際には存在しますが、データベースには存在しません）。 person_id は、 name や address などの列を含む、 person テーブルのPKです。 （シンプルにしましょう）。 social_security_number テーブルには、 ssn 列と外部キーとして person_id 列が含まれます。このFKは social_security_number テーブルのPKとして使用できるため、識別関係です。

1対1の非識別関係

大規模なオフィスコンプレックスでは、フロアごとの部屋番号とPKを含む建物番号を含む office テーブルと、別の従業員テーブルがあります。従業員テーブル（子）には、 office テーブルPKの office_id 列であるFKがあります。各従業員のオフィスは1つだけであり（この例では）すべてのオフィスの従業員は1人だけですが、オフィスは従業員なしで存在でき、従業員はオフィスを変更したり現場で働くことができるため、これは非識別関係です。

1対多の関係

1対多の関係は、同じ質問をすることで簡単に分類できます。

多対多の関係

多対多の関係は、常に関係を識別しています。これは直観に反するように思えるかもしれませんが、私には耐えられます。 2つのテーブル libary と books を取ります。各ライブラリには多くの本があり、各本のコピーは多くのライブラリにあります。

これを実現し、関係を特定するものは次のとおりです。 これを実装するには、各テーブルの主キーである2つの列を持つリンクテーブルが必要です。それらを library_id 列および ISBN 列と呼びます。この新しいリンクテーブルには個別の主キーはありませんが、待ってください！リンクテーブル内の重複レコードは無意味になるため、外部キーはリンクテーブルの複数列のプライマリキーになります。 リンクは親なしでは存在できません。したがって、これは識別関係です。わかった、大丈夫？

ほとんどの場合、関係のタイプは重要ではありません。

これまで述べてきたことはすべて、通常は自分がどれを持っているか心配する必要はないということです。適切な主キーと外部キーを各テーブルに割り当てるだけで、リレーションシップが自動的に検出されます。

編集： NicoleC 、回答をリンクしましたが、それは私の意見と一致します。私は約彼のポイントを取る

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top