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

最新推荐文章于 2021-10-13 14:46:47 发布

p15097962069

最新推荐文章于 2021-10-13 14:46:47 发布

阅读量1.2k

点赞数 3

文章标签： database database-design data-modeling identifying-relationship

原文链接：https://es.sofbug.com/question/3CTR

版权

我无法完全掌握差异。您能否同时描述两个概念并使用真实示例？

#1楼

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

例如：在卖方可能拥有自己的主键，但仅在出售书籍时才创建实体的情况下，卖方与某本书之间的关系可能存在于卖方正在出售书的情况下

参考依据Bill Karwin

#2楼

非身份关系

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

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

#3楼

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

一本书属于一个所有者，一个所有者可以拥有多本书。但是，这本书也可以在没有所有者的情况下存在，并且其所有权可以从一个所有者更改为另一个所有者。书籍与所有者之间的关系是一种非身份关系。

但是，一本书是由一位作者撰写的，并且该作者可能写了多本书。但是，这本书需要由作者撰写-没有作者就不可能存在。因此，书与作者之间的关系是一种识别关系。

#4楼

假设我们有这些表：

user
--------
id
name


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

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

#5楼

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

如果即使删除了父项也应保留子项，那么这是一个不确定的关系。

例如，我有一个培训数据库，其中包含受训者，培训，文凭和培训课程：

学员与培训课程有明确的关系
培训与培训课程有明确的关系
但是受训者与文凭之间的身份不明

如果删除了相关的受训者，培训或文凭之一，则仅应删除培训课程。

#6楼

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

标识的关系是父/子关系，其中子是一种弱实体（即使在传统的ER模型中，它也称为标识关系），由于其自身的属性没有真正的主键，因此无法通过其自身唯一地标识。在物理模型上，对子表的每次访问都将（在语义上包括）父级主键，这将成为子级主键（也就是外键）的一部分或全部，通常会产生复合键在孩子方面。子级本身的最终现有密钥仅是伪密钥或部分密钥，不足以标识该类型的实体或实体集的任何实例，而没有父级的PK。

非标识关系是完全独立的实体集的普通关系（部分或全部），其实例不依赖于彼此的主键进行唯一标识，尽管它们可能需要部分或全部关系的外键，但不是作为孩子的主键。孩子有自己的主键。父同上。两者独立。根据关系的基数，一个的PK作为FK传递至另一（N端），如果是部分，则可以为null，如果为总计，则不能为null。但是，在这样的关系中，FK永远也不会是孩子的PK，就像确定性的关系一样。

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

#7楼

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

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

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

是的，一book不能在没有至少一个写author ，但author对的（它的外键） book是不是确定 book的books表！

您可以从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

在这个例子中Product_ID在printers_details表被认为是FK引用products.id表以及在一个PK printers_details表，这是一个识别关系，因为Product_ID在打印机表（FK） 是标识子内的行表，我们无法从子表中删除product_id ，因为我们不再标识该行，因为我们丢失了它的主键

如果要将其分为两行：

标识关系是当子表中的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％从书本行中删除作者，但仍然可以识别书本！ 。

#8楼

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

一遍又一遍地说，在与父母的关系中，没有父母就不能存在孩子。（例如user287724 ）。的确如此，但是完全错了。外键为非null足以实现此目的。它不必是主键的一部分。

所以这是真正的原因：

识别关系的目的是外键永远都不能改变 ，因为它是主键的一部分，因此可以识别！！！

#9楼

从父级迁移到子级的属性是否有助于标识¹个子级？

如果是：标识依赖性存在，则关系为标识，子实体为“弱”。
如果不存在 ：则不存在标识依赖关系，则关系为非标识关系，子实体为“强”。

请注意，标识依赖性意味着存在依赖性，但并非相反。每个非NULL FK都意味着没有父母就不能存在孩子，但是仅靠这一点并不能确定关系。

有关此内容（和一些示例）的更多信息，请查看《 ERwin方法指南》的“识别关系”部分。

PS：我意识到我（在极端情况下）迟到了派对，但是我觉得其他答案不是完全准确（从存在依赖而不是标识依赖来定义），或者有些曲折。希望这个答案可以提供更多的清晰度...

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

#10楼

识别关系意味着子实体完全取决于父实体的存在。示例帐户表人员表和人员帐户。人员帐户表仅通过帐户和人员表的存在来标识。

非标识关系表示子表未通过父表的存在进行标识，例如存在表为accounttype和account.accounttype表未通过account表的存在进行标识。

#11楼

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

非识别关系指定对象之间的规则关联，即1：1或1：n基数。

通过设置父表基数，可以在不需要父级的情况下将非标识关系指定为可选，在不需要父级的情况下可以将其指定为强制性...

#12楼

这是一个很好的描述：

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

#13楼

标识关系是子表中的行的存在取决于父表中的行的时间。这可能会造成混淆，因为如今常见的做法是为子表创建伪密钥，但不将外键作为子主键的父部分。正式地，执行此操作的“正确”方法是使外键成为孩子主键的一部分。但是逻辑上的关系是，没有父母就不能存在孩子。
示例：一个Person有一个或多个电话号码。如果他们只有一个电话号码，我们可以简单地将其存储在Person列中。由于我们要支持多个电话号码，因此我们创建了第二个表PhoneNumbers ，其主键包括引用Person表的person_id 。
即使电话号码被建模为单独表格的属性，我们也可能认为电话号码属于一个人。这有一个很明显的线索，那就是这是一种识别关系（即使我们没有在PhoneNumbers的主键中实际包含person_id ）。
当父级的主键属性不能成为子级的主键属性时，这是一种非身份关系 。的一个很好的例子是一个查找表，如一个外键Person.state引用的主键States.state 。 Person是一个子表相对于States 。但是Person的行不能通过其state属性来标识。即state不是Person的主键的一部分。
非标识关系可以是可选的或强制的 ，这意味着外键列分别允许NULL或不允许NULL。