識別関係 は、子テーブル内の行の存在が親テーブル内の行に依存する場合です。最近では子テーブルの擬似キーを作成するのが一般的な方法ですが、notが外部キーを子の主キーの親部分にするため、これは混乱を招くことがあります。正式には、これを行うための「正しい」方法は、外部キーを子の主キーの一部にすることです。しかし論理的な関係は、子供が親なしでは存在できないということです。
例：
Personには1つ以上の電話番号があります。電話番号が1つしかない場合は、それをPersonの列に単純に格納できます。複数の電話番号をサポートしたいので、2つ目のテーブルPhoneNumbersを作成します。このテーブルの主キーには、Personテーブルを参照するperson_idが含まれています。電話番号は、別のテーブルの属性としてモデル化されていても、その人に属するものと考えることができます。これは、これが識別関係であることを強く示唆するものです（たとえ文字通り
PhoneNumbersの主キーにperson_idが含まれていなくても）。非識別関係 は、親の主キー属性不可が子の主キー属性になる場合です。この良い例は、
Person.stateの主キーを参照するStates.stateの外部キーなどのルックアップテーブルです。PersonはStatesに関して子テーブルです。しかし、Person内の行は、そのstate属性によって識別されません。すなわちstateは、Personの主キーの一部ではありません。非識別関係は、 optional または mandatory にすることができます。これは、それぞれ外部キー列でNULLが許可されるか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
ser287724's answer は、次の本と著者の関係の例を示します。
しかし、本は著者によって書かれており、著者は複数の本を書いているかもしれません。しかし、本は著者によって書かれる必要があり、著者なしでは存在できません。したがって、本と著者の関係は、識別関係です。
これは非常にわかりにくい例であり、間違いなくidentifying relationshipの有効な例ではありません。
はい、bookは少なくとも1つのauthorなしでは記述できませんが、authorのbook（外部キー）はNOT IDENTIFYINGです= bookテーブルのbooks！
author（FK）をbook行から削除しても、他のフィールド（ISBN、ID、...など）によって本の行を識別できます。 しかし、本の著者ではない!!
identifying relationshipの有効な例は、（productsテーブル）と（特定の製品詳細テーブル）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はproducts.idテーブルを参照するFKと見なされ、printers_detailsテーブルのALSO a PKと見なされます。プリンターテーブルのProduct_ID（FK）IS IDENTIFYING子テーブル内の行であるため、識別関係です。子テーブルからproduct_idを削除することはできません。プライマリキーをなくしたため、行を特定できなくなりました
2行に入れたい場合：
識別関係とは、子テーブルのFKが子テーブルのPK（または識別子）と見なされ、親テーブルをまだ参照している場合の関係です。
別の例国データベースのインポートとエクスポートに3つのテーブル（インポート-製品-国）がある場合
importテーブルは、これらのフィールド（product_id（FK）、country_id（FK）、インポートの量、価格、インポートされた単位、 transport（air、sea））we may use the (product_id, thecountry_id`）インポートの各行を「同じ年にすべての場合」識別するために、ここで両方の列が子テーブルの主キーを一緒に構成できます（ imports）そして、親テーブルも参照します。
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の間でも。
親が削除されたときに子アイテムを削除する必要があると考えると、それは識別関係になります。
親が削除されても子項目を保持する必要がある場合、それは非識別の関係です。
例として、私は研修生、研修、卒業証書、および研修セッションを含む研修データベースを持っています。
- 研修生は研修会と識別関係にあります
- トレーニングはトレーニングセッションと特定の関係にあります
- しかし、研修生は卒業証書と非特定の関係にあります
関連する研修生、研修または卒業証書のいずれかが削除された場合は、研修セッションのみを削除する必要があります。
識別関係は、子エンティティが親エンティティの存在に完全に依存していることを意味します。アカウントテーブルpersonテーブルとpersonaccountの例。personアカウントテーブルは、accountとpersonテーブルの存在のみによって識別されます。
非識別関係とは、子テーブルが親テーブルの存在によって識別されないことを意味します。accountTypeというテーブルがあり、account.accounttypeテーブルは、存在するアカウントテーブルによって識別されません。
親から子へ移行した属性を表示しますか 識別1 子供？
- yes の場合、識別依存関係が存在し、関係は識別中であり、子エンティティは「弱い」です。
- not の場合：識別依存関係が存在しない場合、関係は識別不可能で、子エンティティは "強い"ことになります。
識別依存は存在依存を意味しますが、その逆はありません。 NULL以外のすべてのFKは、子が親なしでは存在できないことを意味しますが、それだけでは関係を特定することはできません。
これに関するさらなる情報（およびいくつかの例）は、 ERwinメソッドガイド の「識別関係」のセクションをご覧ください。
P.S私は（非常に）パーティーに遅刻していることを実感しますが、他の答えは完全に正確ではない（識別依存ではなく存在依存の観点から定義する）か、やや蛇行していると感じます。うまくいけば、この回答がより明確になるでしょう...
1 子のFKは、子のPRIMARY KEYまたは（NULL以外の）UNIQUE制約の一部です。
以下のリンクでよく説明されているように、識別関係は、ER概念モデルにおけるその親に対する弱いエンティティタイプの関係にやや似ています。データモデリングのためのUMLスタイルのCADはERのシンボルや概念を使用していません、そして関係の種類は次のとおりです。識別、非識別および非特定。
識別されているものは、子が弱い実体のような種類の親子関係であり（伝統的なERモデルでもその識別関係と呼ばれる）、それはそれ自身の属性によって本当の主キーを持たず、したがってそれ自身によって一意に識別できない。物理モデル上の子テーブルへのすべてのアクセスは、親の主キーに依存し（意味的に）、それは子の主キーの一部または全体（外部キーでもある）になり、一般的に複合キーになります。子供側に。子自体の最終的に存在するキーは、疑似キーまたは部分キーにすぎず、親のPKなしでは、そのタイプのエンティティまたはエンティティセットのインスタンスを識別するのに十分ではありません。
非識別関係は、完全に独立したエンティティセットの通常の関係（部分的または全体的）であり、そのインスタンスは部分的または全体的な関係に外部キーを必要とする可能性があります。子の主キーとして。子には独自の主キーがあります。親のアイデンティティどちらも独立しています。関係のカーディナリティーに応じて、一方のPKは他方へのFKとして進み（N側）、部分的な場合はnullになることがあり、合計の場合はnullになることはできません。しかし、このような関係では、識別関係が当てはまる場合のように、FKが子のPKになることはありません。
http://docwiki.embarcadero.com/ERStudioDA/XE7/ja/Creating_and_Editing_Relationships
良い例は注文処理から来ています。顧客からの注文には通常、注文を識別する注文番号、注文日や顧客IDなどの注文ごとに1回発生するデータ、および一連の明細があります。各品目には、注文内の品目を識別する品目番号、注文された製品、その製品の数量、製品の価格、および品目の金額が含まれます。価格。
広告申込情報を識別する番号は、単一注文のコンテキストでのみ表示されます。すべての注文の最初の行項目は、項目番号 "1"です。品目の完全な識別情報は、品目番号とそれを構成する注文番号です。
したがって、注文と明細の間の親子関係は識別関係です。 ERモデリングにおける密接に関連した概念は、 "subentity"という名前で行われます。ここで、広告申込情報は注文のサブエンティティです。通常、サブエンティティは、それが従属するエンティティに対して必須の親子識別関係を持ちます。
古典的なデータベース設計では、LineItemsテーブルの主キーは（OrderNumber、ItemNumber）です。今日のデザイナーの中には、アイテムに主キーとして機能し、DBMSによって自動インクリメントされる個別のItemIDを指定する人がいます。この場合はクラシカルデザインをお勧めします。
これらのテーブルがあるとしましょう。
user
--------
id
name
comments
------------
comment_id
user_id
text
これら2つのテーブル間の関係は関係を識別します。なぜなら、コメントはその所有者にのみ属し、他のユーザーには属し得ないからです。例えば。各ユーザーには独自のコメントがあり、ユーザーが削除されると、このユーザーのコメントも削除されます。
識別関係は2つの強い実体の間にあります。非識別関係は、常に強い存在と弱い存在の間の関係であるとは限りません。子自体が主キーを持っていても、そのエンティティの存在がその親エンティティに依存している場合があります。
例えば、本が売り手によって販売されている売り手と本との間の関係は、売り手がそれ自身の主キーを有することができるが、そのエンティティは本が販売されているときにのみ作成される場合に存在し得る
Bill Karwinに基づく参照