Question

我无法完全掌握差异。你能描述这两个概念并使用现实世界的例子吗？

Answer 1

标识关系是指子表中存在的行取决于父表中的行。这可能会让人感到困惑，因为现在通常会为子表创建伪代码，但不将外键设置为子主键的父部分。在形式上，这样做的“正确”方法是使外键成为孩子主键的一部分。但逻辑关系是没有父母就不能存在孩子。

示例：Person有一个或多个电话号码。如果他们只有一个电话号码，我们只需将其存储在Person列中即可。由于我们希望支持多个电话号码，因此我们制作了第二个表PhoneNumbers，其主键包含引用person_id表的Person。

我们可能会将电话号码视为属于某个人，即使它们被建模为单独表格的属性。这是一个强有力的线索，即这是一种识别关系（即使我们在person_id的主键中不包含PhoneNumbers）。
非标识关系是指父的主键属性不能成为子项的主键属性的时间。一个很好的例子是查找表，例如Person.state上引用States.state主键的外键。 Person是与States相关的子表。但Person属性中未标识state中的一行。即state不属于Person的主键。

非标识关系可以是可选或强制，这意味着外键列分别允许NULL或不允许NULL。

另请参阅我对Still Confused About Identifying vs. Non-Identifying Relationships

的回答

Answer 2

现实世界还有另一种解释：

一本书属于所有者，所有者可以拥有多本书。但是，这本书也可以在没有所有者的情况下存在，并且它的所有权可以从一个所有者变为另一个。书与所有者之间的关系是一种非识别关系。

然而，一本书是由作者撰写的，作者本可以写多本书。但是，这本书需要由作者撰写 - 没有作者就不可能存在。因此，书与作者之间的关系是一种认同关系。

Answer 3

标识关系指定子对象不能存在没有父对象

非标识关系指定常规关联对象之间，1：1或1：n基数。

如果父项不是，则可以将非标识关系指定为可选需要或必须通过设置父母的父母父表基数......

Answer 4

Bill's answer是正确的，但看到令人震惊的是，在所有其他答案中，没有人指出最重要的方面。

有人一遍又一遍地说，在没有父母的情况下，孩子不能存在和识别关系。（例如user287724）。这是事实，但完全忽略了这一点。只要外键足够非null 就可以实现这一点。它不需要是主键的一部分。

所以这是真正的原因：

识别关系的目的是外键永远不会改变，因为它是主键的一部分... therefore识别!!!

Answer 5

这是一个很好的描述：

两个实体之间的关系可以被分类为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时，存在标识关系。另一方面，当父实体的主键包含在子实体中但不作为子实体的主键的一部分时，存在非标识关系。此外，非识别关系可以进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时，存在强制的非标识关系。另一方面，当子表中的值可以为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

Answer 6

user287724's answer给出了本书和作者关系的以下示例：

然而，一本书是由作者撰写的，作者可以写出多本书。但这本书需要由作者撰写，如果没有作者，就不能存在。因此，书与作者之间的关系是一种识别关系。

这是一个非常令人困惑的示例，对于identifying relationship来说肯定不是有效示例。

是的，如果没有至少一个book，则author无法写入，但author的{{1}}（它的外键）是< strong> NOT IDENTIFYING 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被视为FK引用printers_details表，{strong>是}中的 PK table，这是一个识别关系，因为打印机表格中的products.id（FK）正在识别子表格中的行，我们无法移除printers_details来自子表，因为我们无法识别该行，因为我们丢失了它的主键

如果你想把它分成两行：

识别关系是FK中的关系子表被认为是子表中的PK（或标识符）仍引用父表

另一个例子可能是某个国家/地区数据库的导入和导出中有3个表（导入 - 产品 - 国家/地区）

Product_ID表是包含这些字段的子项（product_id（FK），import（FK），导入量，价格，导入的单位，运输方式（空运，海运））product_id product_id country_id country_id`）来识别进口的每一行＆＃34;如果它们都在同一年＃34;这两个列可以组合子表中的主键（导入）并引用父表。

我很高兴我终于理解了we may use the (和, the的概念，所以请不要告诉我，所有这些投票都错了对于完全无效的示例

是的，从逻辑上讲，一本书不能在没有作者的情况下书写，但书籍可以在没有作者的情况下书写，实际上它不能与作者一起识别！

您可以100％从图书行中删除作者，但仍然可以识别图书！。

Answer 7

非识别关系

非识别关系意味着孩子与父母有关，但可以由自己识别。

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之间。

Answer 8

识别关系意味着子实体完全依赖于父实体的存在。示例帐户表人员表和personaccount。人员帐户表仅由帐户和人员表的存在标识。

非标识关系意味着子表未由父表的存在标识例如，表格为帐户类型，而account.accounttype表格未标识帐户表格。

Answer 9

如果您认为在删除父项时应删除子项，那么它就是一种识别关系。

如果即使父母被删除也应该保留子项目，那么这是一个非识别关系。

举个例子，我有一个培训数据库，包括学员，培训，文凭和培训课程：

学员与培训课程有明确的关系
培训与培训课程有明确的关系
但受训人员与文凭之间存在不确定关系

如果删除了相关的培训生，培训或文凭，则只能删除培训课程。

Answer 10

是否将属性从父级迁移到子级帮助识别¹ 孩子？

如果是：存在识别依赖关系，则关系正在识别，而子实体是“弱”＆＃34;。
如果不：识别依赖性不存在，则该关系是非识别关系，而子实体＆＃34;强＆＃34;。

请注意，识别依赖意味着存在依赖性，而不是相反。每个非NULL FK意味着一个孩子在没有父母的情况下不能存在，但仅凭这一点并不能确定关系。

有关此内容的更多信息（以及一些示例），请查看＆＃34;识别关系＆＃34; ERwin Methods Guide。

的部分

P.S。我意识到我（非常）迟到了，但我觉得其他答案要么不完全准确（用存在依赖而不是识别依赖来定义），要么有些蜿蜒。希望这个答案更清晰......

¹孩子的FK是孩子的PRIMARY KEY或（非NULL）UNIQUE约束的一部分。

Answer 11

一个很好的例子来自订单处理。来自客户的订单通常具有标识订单的订单号，每个订单发生一次的一些数据，例如订单日期和客户ID，以及一系列订单项。每个订单项都包含一个项目编号，用于标识订单中的订单项，订购的产品，产品的数量，产品的价格以及订单项的金额，可以通过将数量乘以价。

标识订单项的数字仅在单个订单的上下文中标识它。每个订单中的第一个订单项是商品编号“1”。订单项的完整标识是商品编号以及作为其一部分的订单编号。

订单和订单项之间的父子关系因此是一种识别关系。 ER建模中一个密切相关的概念是名称“subentity”，其中订单项是订单的子实体。通常，子实体与其从属的实体具有强制的子父级身份关系。

在经典数据库设计中，LineItems表的主键是（OrderNumber，ItemNumber）。今天的一些设计师会给项目一个单独的ItemID作为主键，并由DBMS自动增加。在这种情况下，我推荐经典设计。

Answer 12

如下面的链接中所述，在ER概念模型中，识别关系有点像弱父实体类型关系。用于数据建模的UML样式CAD不使用ER符号或概念，关系的类型是：识别，非识别和非特定。

识别那些是父/子的关系，其中孩子是弱实体（即使在传统的ER模型中称为识别关系），其自身的属性没有真正的主键，因此不能唯一地识别由它自己。在物理模型上对子表的每次访问都将依赖于（包括语义上）父父的主键，该主键变成子主键的一部分或全部（也是外键）），通常导致儿童方面的复合键。子项本身的最终现有密钥只是伪密钥或部分密钥，不足以识别该类型的实体或实体集的任何实例，而没有父代的PK。

非识别关系是完全独立的实体集的普通关系（部分或全部），其实例不依赖于彼此＆＃39;要唯一标识的主键，尽管它们可能需要外键用于部分或全部关系，但不能作为子键的主键。孩子有自己的主键。父母同意。都是独立的。根据关系的基数，一个的PK作为FK到另一个（N侧），如果是部分，则可以为null，如果是total，则必须不为空。但是，在这样的关系中，FK永远不会成为孩子的PK，就像识别关系一样。

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

Answer 13

对Daniel Dinnyes' answer的补充：

在非身份识别关系中，两次相同的主键列（即“ ID”）不能具有相同的值。

但是，对于具有身份标识关系的人，只要其具有不同的“ otherColumn_ID”外键值，您就可以使“ ID”列的相同值两次出现，因为键是两列的组合。

请注意，FK是否为“非空”都没有关系！ ;-）

Answer 14

识别关系在两个强实体之间。非识别关系可能并不总是强实体和弱实体之间的关系。可能存在子项本身具有主键但其实体的存在可能依赖于其父实体的情况。

例如：卖方可能拥有自己的主键，但只有在出售图书时才创建实体，卖方和卖方出售图书的书籍之间可能存在关系

基于Bill Karwin的参考

Answer 15

假设我们有这些表格：

user
--------
id
name


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

这两个表之间的关系将确定关系。因为，评论只能属于其所有者，而不属于其他用户。例如。每个用户都有自己的评论，当用户被删除时，也应该删除该用户的评论。

识别和非识别关系之间有什么区别？

15 个答案: