我无法完全掌握这些差异。你能描述这两个概念并使用现实世界的例子吗?
15 回答
标识关系是子表中的行的存在依赖于父表中的行。这可能会令人困惑,因为如今为子表创建伪键是一种常见的做法,但不将外键作为子表的父部分的主键。形式上,“正确”的做法是让外键成为子主键的一部分。但逻辑关系是,没有父母,孩子就无法存在。
示例:A
Person
有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person
. 由于我们希望支持多个电话号码,我们创建了第二个表PhoneNumbers
,其主键包括person_id
引用该Person
表。我们可能会认为电话号码属于一个人,即使它们被建模为单独表格的属性。这是一个强有力的线索,表明这是一种识别关系(即使我们没有真正包含
person_id
在 的主键中PhoneNumbers
)。非标识关系是指父项的主键属性不能成为子项的主键属性。一个很好的例子是查找表,例如
Person.state
引用主键的外键States.state
。Person
是关于 的子表States
。但是其中的一行Person
不是由它的state
属性来标识的。即state
不是主键的一部分Person
。非标识关系可以是可选的或强制的,这意味着外键列分别允许 NULL 或不允许 NULL。
另请参阅我对仍然对识别与非识别关系感到困惑的回答
现实世界还有另一种解释:
一本书属于一个所有者,一个所有者可以拥有多本书。但是,这本书也可以在没有所有者的情况下存在,并且它的所有权可以从一个所有者变为另一个所有者。一本书和所有者之间的关系是一种非识别关系。
然而,一本书是由一个作者写的,而这个作者可能写了多本书。但是,这本书需要由作者撰写——没有作者,它就无法存在。因此,书与作者之间的关系是一种识别关系。
比尔的答案是正确的,但令人震惊的是,在所有其他答案中,没有人指出最重要的方面。
人们一遍又一遍地说过,在识别关系中,没有父母,孩子就无法存在。(例如user287724)。这是真的,但完全没有抓住重点。外键为非空就足以实现这一点。它不需要是主键的一部分。
所以这才是真正的原因:
识别关系的目的是外键永远不会改变,因为它是主键的一部分......因此识别!
标识关系指定子对象不能在没有父对象的情况下存在
非标识关系指定对象之间的常规关联,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
user287724的回答给出了以下书籍和作者关系的例子:
然而,一本书是由作者写的,而作者可能写了多本书。但是这本书需要作者写,没有作者就不可能存在。因此,书与作者之间的关系是一种识别关系。
这是一个非常令人困惑的示例,绝对不是identifying relationship
.
是的,book
没有至少一个就不能写author
,但是author
(它是外键)的不是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
中,printers_details
表中的 FK 被认为是引用products.id
表的 FK 并且也是表中的 PKprinters_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
and的概念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 之间。
如果你认为删除父项时也应该删除子项,那么它是一种标识关系。
如果即使删除了父项,也应该保留子项,则它是非标识关系。
例如,我有一个包含学员、培训、文凭和培训课程的培训数据库:
- 受训者与培训课程有确定的关系
- 培训与培训课程具有识别关系
- 但受训者与文凭有非识别性关系
如果删除相关学员、培训或文凭之一,则仅应删除培训课程。
标识关系意味着子实体完全依赖于父实体的存在。
示例帐户表人员表和人员帐户。人员帐户表仅通过帐户和人员表的存在来标识。
非标识关系是指子表不通过父表的存在来标识。
示例作为 accountType 和 account.accountType 表的表不标识存在 account 表。
就像下面链接中很好解释的那样,识别关系有点像 ER 概念模型中与其父级的弱实体类型关系。用于数据建模的 UML 样式 CAD 不使用 ER 符号或概念,关系的种类是:识别、非识别和非特定。
标识关系是父/子关系,其中子实体是一种弱实体(即使在传统的 ER 模型中,它也称为标识关系),其自身属性没有真正的主键,因此无法由其自身唯一标识. 在物理模型上,对子表的每次访问都将依赖于(包括语义上)父主键,该主键变成子主键的一部分或全部(也是外键),通常会产生复合键在孩子方面。子项本身的最终现有密钥只是伪密钥或部分密钥,不足以识别该类型实体或实体集的任何实例,没有父项的 PK。
非标识关系是完全独立实体集的普通关系(部分或全部),其实例不依赖于彼此的主键来唯一标识,尽管它们可能需要外键来实现部分或全部关系,但不是作为孩子的主键。孩子有自己的主键。父母同上。两者独立。根据关系的基数,一个的 PK 作为 FK 到另一个(N 侧),如果是部分的,可以为空,如果是全部,则不能为空。但是,在这样的关系中,FK 永远不会是孩子的 PK,就像识别关系一样。
http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships
从父级迁移到子级的属性是否有助于识别1子级?
- 如果是:标识依赖存在,关系是标识的,子实体是“弱的”。
- 如果不是:标识依赖不存在,关系是非标识的,子实体“强”。
请注意,识别依赖意味着存在依赖,但反之则不然。每个非 NULL FK 都意味着没有父级的子级不能存在,但仅此一项并不能确定关系。
有关这方面的更多信息(以及一些示例),请查看ERwin 方法指南的“识别关系”部分。
PS我意识到我参加聚会(非常)迟到了,但我觉得其他答案要么不完全准确(根据存在依赖而不是身份依赖来定义它),要么有点曲折。希望这个答案能提供更多的清晰度......
1孩子的 FK 是孩子的 PRIMARY KEY 或(非 NULL)UNIQUE 约束的一部分。
一个很好的例子来自订单处理。来自客户的订单通常具有标识订单的订单号、每个订单出现一次的一些数据(例如订单日期和客户 ID)以及一系列行项目。每个行项目包含一个项目编号,用于标识订单中的行项目、订购的产品、该产品的数量、产品的价格以及行项目的金额,可以通过将数量乘以价格。
标识行项目的编号仅在单个订单的上下文中标识它。每个订单中的第一个行项目是项目编号“1”。行项目的完整标识是项目编号及其所属的订单编号。
因此,订单和订单项之间的父子关系是一种识别关系。ER 建模中一个密切相关的概念称为“子实体”,其中行项目是订单的子实体。通常,子实体与其从属的实体具有强制性的子-父标识关系。
在经典数据库设计中,LineItems 表的主键是 (OrderNumber, ItemNumber)。今天的一些设计师会给一个项目一个单独的 ItemID,作为主键,并由 DBMS 自动递增。在这种情况下,我推荐古典设计。
在非标识关系中,您不能将相同的主键列(例如“ID”)两次具有相同的值。
但是,通过标识关系,您可以让“ID”列的相同值显示两次,只要它具有不同的“otherColumn_ID”外键值,因为主键是两列的组合。
请注意,FK 是否为“非空”并不重要!;-)
识别关系存在于两个强实体之间。非识别关系可能并不总是强实体和弱实体之间的关系。可能存在子实体具有主键但其实体的存在可能取决于其父实体的情况。
例如:卖方与书籍之间的关系可能存在,其中卖方可能有自己的主键,但仅在出售书籍时才创建其实体
基于比尔·卡尔文的参考
假设我们有这些表:
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将识别关系。因为,评论只能属于其所有者,不能属于其他用户。例如。每个用户都有自己的评论,当用户被删除时,该用户的评论也应该被删除。