識別関係と非識別関係の違いは何ですか？

その違いを十分に理解できていません。両方の概念を説明し、実際の例を使用できますか？

• 特定の関係は、子テーブル内の行の存在は、親テーブルの行に依存する場合です。最近では、子テーブルの疑似キーを作成し、子の主キーの親部分への外部キーを作成しないことが一般的であるため、これは混乱を招く可能性があります。正式には、これを行う「正しい」方法は、外部キーを子の主キーの一部にすることです。しかし、論理的な関係は、子供は親なしでは存在できないということです。

  例：AにPersonは1つ以上の電話番号があります。電話番号が1つしかない場合は、の列に格納するだけで済みPersonます。複数の電話番号をサポートする必要があるため、2番目のテーブルを作成します。このテーブルPhoneNumbersのperson_id参照を主キーに含めPersonます。

  電話番号は別のテーブルの属性としてモデル化されていますが、電話番号は人のものであると考える場合があります。これは、これが識別関係であることを示す強力な手がかりです（文字どおりperson_idにの主キーに含めなくてもPhoneNumbers）。

• 非識別関係は、親の主キー属性があるときはならない子の主キー属性になります。この良い例はPerson.state、の主キーを参照する際の外部キーなどのルックアップテーブルですStates.state。 Personはに関する子テーブルStatesです。しかし、行Personはそのstate属性によって識別されません。すなわちstateの主キーの一部ではありませんPerson。

  非識別関係はオプションまたは必須にすることができます。これは、外部キー列がそれぞれNULLを許可または禁止することを意味します。

識別と非識別の関係についてまだ混乱しているに対する私の回答も参照してください

実世界からの別の説明があります：

本は所有者に属し、所有者は複数の本を所有できます。しかし、本は所有者がいなくても存在する可能性があり、その所有権はある所有者から別の所有者に変わる可能性があります。本と所有者の関係は、識別できない関係です。

ただし、本は著者によって作成されたものであり、著者は複数の本を書いた可能性があります。しかし、本は著者によって書かれる必要があります-それは著者なしでは存在できません。したがって、本と著者の関係は識別関係です。

ビルの答えは正しいですが、他のすべての答えの中で誰も最も重要な側面を指摘していないことを見るのは衝撃的です。

何度も何度も言われていることですが、関係を特定することにおいて、子供は親なしでは存在できません。（例：user287724）。これは事実ですが、ポイントを完全に逃しています。これを実現するには、外部キーがnull以外で十分です。主キーの一部である必要はありません。

これが本当の理由です：

識別関係の目的は、外部キーは主キーの一部であるため、決して変更できないことです... したがって識別!!!

識別関係は、子オブジェクトが親オブジェクトなしでは存在できないことを指定します

非識別関係は、オブジェクト間の通常の関連付け、1：1または1：nカーディナリティを指定します。

親テーブルのカーディナリティを設定することで、親が不要な場合、または必須ではない場合に必須として、非識別リレーションシップをオプションとして指定できます...

ここに良い説明があります：

2つのエンティティ間の関係は、「識別」または「非識別」に分類できます。親エンティティの主キーが子エンティティの主キーに含まれている場合、識別関係が存在します。一方、親エンティティの主キーが子エンティティに含まれているが、子エンティティの主キーの一部として含まれていない場合、非識別関係が存在します。さらに、非識別関係は、「必須」または「非必須」のいずれかにさらに分類できます。子テーブルの値をnullにできない場合、必須の非識別関係が存在します。一方、子テーブルの値がnullになる可能性がある場合、必須ではない非識別関係が存在します。

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

以下は、識別関係の簡単な例です。

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

対応する非識別関係は次のとおりです。

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

user287724の答えは、本と著者の関係の次の例を示しています。

しかし、本は著者によって書かれており、著者は複数の本を書いた可能性があります。しかし、本は著者によって書かれる必要があり、著者なしでは存在できません。したがって、本と著者との関係は識別関係です。

これは非常に混乱する例であり、間違いなくの有効な例ではありませんidentifying relationship。

はい、book少なくとも一つせずに書き込むことはできないauthorが、author（それは外部キーです）のbookれる識別用しないbookでbooksテーブル！

あなたは削除することができますauthorから（FK）をbook行し、まだいくつかの他のフィールド（で本の行を識別することができISBN、ID、...等）、本の著者ではありません！

私はの有効な例は思うidentifying relationship（製品テーブル）との関係だろうと（特定の製品の詳細テーブル）1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

この例ではProduct_IDではprinters_details、テーブルFK参照考えられるproducts.idテーブルとALSO PKでprinters_detailsテーブル、これが原因特定関係であるProduct_IDプリンタテーブル内（FK）識別して、子テーブル内の行は、我々は削除できませんproduct_id子テーブルから、我々はそれの主キーを失ったので、我々はそれ以上の行を識別することはできませんので、

2行にしたい場合：

識別関係は、子テーブルのFKが親テーブルを参照しながら子テーブルのPK（または識別子）と見なされる場合の関係です。

別の例としては、いくつかの国のデータベースのインポートとエクスポートに3つのテーブル（インポート-製品-国）がある場合があります。

import表は、これらのフィールド（持つ子であるproduct_id（FK）、country_id（FK）、単位は輸入輸入量、価格、輸送の方法（空気、海）） we may use the (PRODUCT_ID , theそれぞれを識別するためcountry_id`）をインポートの行「すべてが同じ年にある場合」ここでは、両方の列が子テーブル（インポート）の主キーを構成し、親テーブルを参照することもできます。

私はようやくの概念を理解して満足しているしてくださいidentifying relationshipとnon identifying relationship、私はこれらのために投票アップのすべてと間違っている私に教えないでください完全に無効例

はい、論理的には著者なしでは本を書くことはできませんが、本なしでは本を特定できます。実際、著者によって本を特定することはできません。

本の列から著者を100％削除しても、本を特定できます。。

身元不明の関係

非識別関係とは、子が親に関連しているが、自分自身で識別できることを意味します。

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

ACCOUNTとPERSONの関係は識別できません。

関係の特定

識別関係とは、親が子にアイデンティティを与える必要があることを意味します。子供は親のためだけに存在します。

これは、外部キーも主キーであることを意味します。

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

ITEM_LANGとITEMの関係は識別されています。そして、ITEM_LANGとLANGUAGEの間もです。

親が削除されたときに子アイテムを削除する必要があると考える場合、それは識別関係です。

親が削除されても子アイテムを保持する必要がある場合、それは非識別関係です。

例として、研修生、トレーニング、卒業証書、トレーニングセッションを含むトレーニングデータベースがあります。

• 研修生は、研修セッションとの特定の関係を持っています
• トレーニングには、トレーニングセッションとの特定の関係があります。
• 研修生は卒業証書と特定できない関係を持っています

関連する研修生、トレーニング、または卒業証書のいずれかが削除された場合は、トレーニングセッションのみを削除する必要があります。

関係を特定することは、子エンティティが親エンティティの存在に完全に依存していることを意味します。勘定テーブルの個人テーブルと個人アカウントの例。個人アカウントテーブルは、アカウントと個人テーブルの存在のみによって識別されます。

非識別リレーションシップは、子テーブルが親テーブルの存在によって識別されないことを意味します。例として、accounttypeとしてtableがあり、account.accounttypeテーブルはaccountテーブルの存在によって識別されません。

以下のリンクでよく説明されているように、識別関係は、ER概念モデルでの親に対する弱いエンティティタイプの関係に似ています。データモデリング用のUMLスタイルCADは、ERシンボルまたは概念を使用せず、関係の種類は、識別、非識別、および非特定です。

識別は、親/子の関係であり、子は弱いエンティティの一種であり（従来のERモデルでさえ、その識別関係と呼ばれます）、固有の属性によって実際の主キーを持たないため、独自で一意に識別できません。 。物理モデルでの子テーブルへのすべてのアクセスは、親の主キーに依存し（意味的には包括的）、子の主キー（外部キーでもある）の一部または全体になり、通常は複合キーになります。子供の側に。子自体の最終的な既存のキーは、疑似または部分的なキーにすぎず、親のPKがないと、そのタイプのエンティティまたはエンティティセットのインスタンスを識別するには不十分です。

非識別関係は、完全に独立したエンティティセットの通常の関係（部分的または全体的）であり、そのインスタンスは一意に識別される相互の主キーに依存しませんが、部分的または全体的な関係には外部キーが必要になる場合がありますが、子供の主キーとして。子には独自の主キーがあります。親idem。どちらも独立しています。関係のカーディナリティーに応じて、一方のPKはもう一方（N側）へのFKとして扱われ、部分的である場合、nullになる可能性があり、合計である場合、nullであってはなりません。しかし、このような関係では、識別関係がそうであるように、FKが子のPKになることはありません。

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Doが子供のヘルプに親から移行した属性を識別する¹子を？

• 場合はい：識別依存性が存在し、関係が識別され、子エンティティは、「弱い」です。
• そうでない場合：識別依存が存在せず、関係は非識別であり、子エンティティは「強力」です。

識別依存性は存在依存性を意味しますが、その逆は意味しません。NULL以外のすべてのFKは、子が親なしでは存在できないことを意味しますが、それだけでは関係を識別できません。

これ（およびいくつかの例）の詳細については、ERwinメソッドガイドの「関係の識別」セクションを参照してください。

PS私はパーティーに（非常に）遅れていることを認識していますが、他の回答は完全に正確ではない（識別依存ではなく存在依存の観点から定義する）か、やや蛇行しているように感じます。うまくいけば、この回答がより明確になります...

¹子のFKは、子の主キーまたは（非NULL）UNIQUE制約の一部です。

良い例は注文処理です。顧客からの注文には、通常、注文を識別する注文番号、注文日や顧客IDなどの注文ごとに1回発生するいくつかのデータ、および一連のラインアイテムがあります。各ラインアイテムには、注文内のラインアイテムを識別するアイテム番号、注文された製品、その製品の数量、製品の価格、およびラインアイテムの金額が含まれます。これらは、数量に価格。

ラインアイテムを識別する番号は、単一の注文のコンテキストでのみそれを識別します。すべての注文の最初のラインアイテムはアイテム番号「1」です。ラインアイテムの完全なIDは、アイテム番号と、それが含まれる注文番号です。

したがって、オーダーとラインアイテム間の親子関係は、識別関係です。ERモデリングで密接に関連する概念は、「サブエンティティ」という名前で呼ばれます。ここで、ラインアイテムは注文のサブエンティティです。通常、サブエンティティには、それが従属しているエンティティとの必須の親子識別関係があります。

従来のデータベース設計では、LineItemsテーブルの主キーは（OrderNumber、ItemNumber）です。今日のデザイナーの一部は、主キーとして機能し、DBMSによって自動インクリメントされる個別のItemIDをアイテムに与えます。今回はクラシカルなデザインをお勧めします。

これらのテーブルがあるとしましょう：

user
--------
id
name


comments
------------
comment_id
user_id
text

これら2つのテーブル間の関係は、関係を識別します。なぜなら、コメントは他のユーザーではなく、その所有者にのみ属することができるからです。例えば。各ユーザーには独自のコメントがあり、ユーザーが削除されると、このユーザーのコメントも削除されます。

識別関係は、2つの強力なエンティティ間の関係です。非識別関係は、常に強いエンティティと弱いエンティティ間の関係であるとは限りません。子自体に主キーがあるが、そのエンティティの存在がその親エンティティに依存している場合があります。

例：販売者が本を販売している場合、販売者と本の関係が存在する場合があります。販売者は独自の主キーを持っている可能性がありますが、そのエンティティは本が販売されている場合にのみ作成されます。

ビル・カーウィンに基づく参考文献