识别和非识别关系有什么区别？
我还没有能够完全把握分歧。 你能描述两个概念并使用现实世界的例子吗？
-
一个识别关系是当一个子表中的行的存在取决于父表中的一行时。 这可能会让人困惑，因为现在很普遍的做法是为子表创build一个伪密码，但是不要将子键的父键赋给外键。 从forms上来说，这样做的“正确”方式就是把孩子的主键作为外键。 但逻辑关系是孩子没有父母就不能生存。
例如：一个
Person有一个或多个电话号码。 如果他们只有一个电话号码，我们可以简单地将它存储在Person一列中。 由于我们要支持多个电话号码，因此我们创build第二个表PhoneNumbers，其主键包括引用Person表的person_id。我们可能会将电话号码视为属于一个人，即使他们被build模为一个单独的表的属性。 这是一个强烈的线索，这是一个确定的关系（即使我们不字面包含
person_id的主键person_id）。 -
非标识关系是指父项的主键属性不能成为子项的主键属性。 一个很好的例子就是查找表，比如引用
Person.state的主键的States.state上的外键。Person是一个关于States的子表。 但Person的一行不是由其state属性标识的。 即state不是人的主要关键的一部分。非标识关系可以是可选的或强制的 ，这意味着外键列分别允许NULL或不允许NULL。
还请参阅我的答案仍然困惑关于识别与非识别关系
现实世界还有另一种解释：
一本书属于一个所有者，一个所有者可以拥有多本书。 但是，这本书也可以在没有所有者的情况下存在，并且所有权可以从一个所有者变为另一个所有者。 书与业主之间的关系是一种非识别关系。
然而，一本书是由作者撰写的，作者可以写多本书。 但是，这本书需要由作者撰写 – 没有作者就不可能存在。 因此，书与作者的关系是一种识别关系。
识别关系指定在没有父对象的情况下子对象不能存在
非标识关系指定对象之间的常规关联，1：1或1：n基数。
通过设置父表基数，可以将非标识关系指定为可选，其中父代不是必需的
这里有一个很好的描述：
两个实体之间的关系可以被分类为“识别”或“非识别”。 当父实体的主键包含在子实体的主键中时，存在识别关系。 另一方面，当父实体的主键被包括在子实体中而不是作为子实体的主键的一部分时，存在非识别关系。 此外，非识别关系可以被进一步分类为“强制性”或“非强制性”。 当子表中的值不能为空时，存在强制的非标识关系。 另一方面，当子表中的值可以为空时，存在非必需的非标识关系。
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
非识别关系
一个非识别关系意味着一个孩子与父母有关系，但可以由其自己来识别。
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之间。
比尔的回答是正确的，但令人震惊的是在所有其他答案中没有人指出最重要的方面。
一遍又一遍地说，在没有父母的情况下，在认同和认同关系中，孩子是不能存在的。 （例如user287724 ）。 这是事实，但完全忽略了这一点。 为了达到这个目的，这个外键就足够了。 它不需要成为主键的一部分。
所以这是真正的原因：
一个识别关系的目的是外键不能改变 ，因为它是主键的一部分… 因此识别！
如何user287724第二个答案的书和作者的关系的例子得到576投票ups？ 正如它所说：
然而，一本书是由作者撰写的，作者本可以写多本书。 但是这本书需要由作者写作，没有作者就不可能存在。 因此，书与作者的关系是一种识别关系。
这是一个非常混乱的例子，绝对不是一个 identifying relationship 的有效例子 。
我终于明白了两者之间的区别：（（所以请不要把我和这个数量的投票混淆！
是的，如果没有至less一个作者，一本书是不可能写的，但是作者（这是外键）并不能在书本中识别这本书！
您可以从书籍行中删除作者（FK），并仍然可以通过其他字段（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
在这个例子中， printers_details表中的Product_ID被认为是FK引用的products.id表， 并且在printers_details表中也是PK ，这是一个识别关系，因为打印机表中的Product_ID（FK） 是IDENTIFYING里面的行表，我们不能从子表中删除product_id，因为我们不能再识别行，因为我们失去了它的主键
如果你想把它放在两行：
识别关系是当子表中的FK被认为是子表中的PK（或标识符）而仍然引用父表时的关系
另一个例子可能是当你有一个国家数据库的import和出口有3个表（import – 产品 – 国家）
import表是具有这些字段(the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) )的孩子。 （product_id，country_id）来标识导入的每一行“如果它们全部在同一年”，则这两列可以在子表（导入）中组合一个主键并且还引用父表。
请我很高兴我终于明白了identifying relationship和non identifying relationship的概念：（（所以，请不要告诉我，我错了所有这些投票ups为一个完全无效的例子
是的逻辑上是一本书不能没有一个作者，但一本书可以识别没有作者，实际上它不能与作者确定！
你可以100％删除作者从书行，仍然可以识别该书！ ，请不要告诉我我误解了这个概念:(
识别关系意味着子实体完全依赖于母实体的存在。 示例账户人员表和人员账户。人员账户表仅由账户和人员表的存在来标识。
非识别关系是指子表不能识别父表的存在，例如有表为accounttype，account.accounttype表不识别为存在的表。
如果您认为删除父项时应删除子项，则这是一种识别关系。
如果即使父母被删除也应该保留子项目，那么这是一个不确定的关系。
作为一个例子，我有一个培训数据库，包括学员，培训，文凭和培训课程：
- 学员与培训课程有明确的关系
- 培训与培训课程有明确的关系
- 但是学员与文凭没有明确的关系
如果删除相关的学员，培训或文凭，只能删除培训课程。
订单处理就是一个很好的例子。 来自客户的订单通常具有标识订单的订单号，每个订单（例如订单date和客户标识）以及一系列订单项发生的一些数据。 每个订单项都包含用于标识订单中的订单项，订购的产品，产品的数量，产品的价格以及订单项的金额的项目编号，可以通过将数量乘以价钱。
标识订单项的编号只能在单个订单的上下文中标识。 每个订单中的第一个行项目是项目编号“1”。 订单项的完整标识是项目编号以及它所属的订单编号。
订单和订单项之间的父子关系因此是一个识别关系。 ER模型中的一个紧密相关的概念是名为“subentity”，其中行项是订单子实体。 通常情况下，子实体与其从属的实体之间具有强制性的子女 – 父母身份关系。
在传统的数据库devise中，LineItems表的主键将是（OrderNumber，ItemNumber）。 今天的一些devise师会给一个项目一个单独的ItemID，作为主键，由DBMS自动增加。 在这种情况下，我推荐古典devise。
假设我们有这些表格：
user -------- id name comments ------------ comment_id user_id text
这两张表之间的关系将确定关系。 因为，评论只能属于其所有者，而不属于其他用户。 例如。 每个用户都有自己的评论，当用户被删除时，这个用户的评论也应该被删除。
正如下面的链接中所解释的那样，一个识别关系有点像ER概念模型中的父类的弱实体types关系。 用于数据build模的UML样式的CAD不使用ER符号或概念，关系的types是：识别，非识别和非特定的。
识别是父母/孩子的关系，孩子是一个弱的实体（即使在传统的ER模型中被称为识别关系），由于它自己的属性没有真正的主键，因此不能由其自身唯一地标识。 在物理模型上对子表的每一次访问都将依赖（包括语义上）在父母的主键上，该主键变成儿童主键（也是外键）的一部分或全部，通常导致组合键在孩子的一面。 子本身的最终现有密钥本身只是伪密钥或部分密钥，不足以识别该types的实体或实体集的任何实例，而没有父母的PK。
非标识关系是完全独立的实体集合的普通关系（部分或全部），它们的实例并不依赖于彼此的主键来唯一标识，尽pipe它们可能需要部分或全部关系的外键，而不是作为孩子的主要关键。 孩子有自己的主键。 父母的同性恋 两者都独立。 根据关系的基数，一个PK作为一个FK到另一个（N侧），如果是部分的话，可以是空的，如果总和，则不能为空。 但是在这样的关系中，FK永远也不会是孩子的PK，因为当一个确定的关系是这样的时候。
http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships
一个确定的关系是两个强大的实体之间。 一个非识别关系并不总是一个强大的实体和一个弱的实体之间的关系。 可能存在一个情况，即一个孩子本身有一个主键，但其实体的存在可能取决于其母体。
例如：销售者和卖书之间的关系可能存在于销售者可能拥有自己的主键但是其实体仅在销售书籍时被创build
参考基于比尔卡尔文
