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

我还没能完全理解它们的区别。你能描述一下这两个概念并用现实世界的例子吗？

488426 次浏览
小开

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

非标识关系指定常规关联对象之间，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 PKName

下面是一个对应的非标识关系：

Parent------ID (PK)Name
Child-----ID (PK)ParentID (FK to Parent.ID) -- notice no PKName
小开
最佳答案

  • 识别关系是指子表中一行的存在依赖于父表中的一行。这可能会让人困惑，因为现在为子表创建伪键是很常见的做法，但是没有使外键成为子主键的父部分。从形式上讲，这样做的“正确”方法是使外键成为子主键的一部分。但逻辑关系是子不能没有父项而存在。

    示例：Person有一个或多个电话号码。如果他们只有一个电话号码，我们可以简单地将其存储在Person的一列中。由于我们想要支持多个电话号码，我们制作了第二个表PhoneNumbers，其主键包括引用Person表的person_id。

    我们可能会认为电话号码属于某个人，即使它们被建模为单独表的属性。这是一个强有力的线索，表明这是一个识别关系（即使我们没有在PhoneNumbers的主键中包含person_id）。

  • A非识别关系是当父节点绝不能的主键属性成为子节点的主键属性时。一个很好的例子是查找表，例如Person.state上的外键引用States.state的主键。Person是States的子表。但是Person中的一行不是由其state属性标识的。即state不是Person主键的一部分。

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

另见我对仍然对识别和非识别关系感到困惑的回答

小开

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

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

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

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

小开

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

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

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

小开

标识关系意味着子实体完全依赖于父实体的存在。

示例帐户表人员表和人员帐户。人员帐户表仅通过帐户和人员表的存在来标识。

非标识关系意味着子表不通过父表的存在来标识。

示例一个表，如账户类型和account.account类型表不与账户表的存在标识。

小开

标识关系是两个强实体之间的关系。非标识关系不一定总是强实体和弱实体之间的关系。可能存在这样的情况，子实体本身有主键，但其实体的存在可能取决于其父实体。

例如卖家和一本书之间的关系当一本书被卖家出售时卖家可能有自己的主键但它的实体只有在一本书被出售时才被创建

参考资料：Bill Karwin

小开

非识别关系

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

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

帐户和个人之间的关系是不可识别的。

识别关系

识别关系意味着父母需要给孩子身份。孩子的存在完全是因为父母。

这意味着外键也是主键。

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

ITEM_LANG与项目的关系是辨识，ITEM_LANG与语言的关系也是辨识。

小开

假设我们有这些表：

user--------idname

comments------------comment_iduser_idtext

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

小开

如果您认为应该在删除父项时删除子项，则它是一种标识关系。

如果子项应该保留，即使父项被删除，那么它是一个非标识关系。

例如，我有一个包含学员、培训、文凭和培训课程的培训数据库：

  • 受训人员与培训课程有明确的关系
  • 培训与培训课程有明确的关系
  • 但是受训者与文凭有一种非认同的关系

如果删除了相关的受训人员、培训或文凭之一，则只应删除培训课程。

小开

就像下面的链接中解释的那样，识别关系有点像ER概念模型中与其父实体的弱实体类型关系。用于数据建模的UML风格CAD不使用ER符号或概念，关系的类型是：识别、非识别和非特定。

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

非标识关系是完全独立实体集的普通关系（部分或全部），其实例不依赖于彼此的主键来唯一标识，尽管它们可能需要外键来进行部分或全部关系，但不作为子实体集的主键。子实体有自己的主键。父实体。两者独立。根据关系的基数，一个实体集的PK作为FK到另一个（N边），如果部分，可以为空，如果全部，必须不为空。但是，在这样的关系中，FK永远不会也是孩子的PK，就像识别关系一样。

小开

user287724的回答给出了本书和作者关系的以下示例：

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

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

是的，如果没有至少一个author，就不能写入book，但是book的author（它的外键）是不确定，books表中的book！

您可以从book行中删除author（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）正在识别是子表中的行，我们不能从子表中删除product_id，因为我们无法再识别该行，因为我们丢失了它的主键

如果你想把它放在两行：

标识关系是当FK在子表被认为是子表中的PK（或标识符），而仍然引用父表

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

import表是具有这些字段的子级（product_id（FK），country_id（FK），进口数量，价格，进口单位，运输方式（空运，海运））我们可以使用（product_id, thecountry_id'）来标识导入的每一行“如果它们都在同一年”，这里的两列可以在子表（导入）中组合一个主键并引用那里的父表。

请，我很高兴我终于理解了identifying relationship和non identifying relationship的概念，所以请不要告诉我我对完全无效示例的所有投票都错了

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

你可以100%从书行中删除作者，仍然可以识别这本书！

小开

比尔的回答是正确的。但在所有其他答案中，没有人指出最重要的方面。

人们一遍又一遍地说，在标识关系中，没有父节点，子节点就不能存在。（例如user287724）。这是真的，但完全没有抓住重点。外键为非空就足以实现这一点。它不需要成为主键的一部分。

这就是真正的原因：

标识关系的目的是外键永远不会改变，因为它是主键的一部分…因此标识！！！

小开

属性从父级迁移到子级是否有助于识别1子级？

  • 如果是的：标识依赖存在，则关系是标识的，子实体是“弱”的。
  • 如果没有：标识依赖不存在，则关系是非标识的，并且子实体“强”。

请注意，识别依赖意味着存在依赖，但不是相反。每个非NULL FK都意味着孩子不能没有父母而存在，但仅此并不能使关系识别。

有关这方面的更多信息（以及一些示例），请查看ERwin方法指南的“识别关系”部分。

附注：我意识到我参加派对已经（非常）迟到了，但我觉得其他答案要么不完全准确（用存在依赖而不是认同依赖来定义它），要么有点曲折。希望这个答案能提供更多的清晰度…

1子进程的FK是子进程主键或（非空）唯一约束的一部分。

小开

Daniel Dinnyes的回答的补充：

在非标识关系中，您不能具有相同值的相同主键列（例如“ID”）两次。

但是，对于标识关系您可以在“ID”列中显示两次相同的值，只要它具有不同的“otherColumn_ID”外键值，因为主键是两列的组合。

请注意，FK是否为“非空”并不重要！；-）


提交答案