我还不能完全理解这些差异。你能描述这两个概念并使用真实世界的例子吗?


当前回答

标识关系是指子表中的行是否存在取决于父表中的某一行。这可能会让人困惑,因为现在通常的做法是为子表创建一个伪密钥,但不将外键作为子表主键的父部分。从形式上讲,这样做的“正确”方法是让外键成为孩子的主键的一部分。但逻辑关系是,没有父母,孩子就不可能存在。示例:一个人有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person列中。因为我们希望支持多个电话号码,所以我们创建了第二个表PhoneNumbers,其主键包括引用person表的person_id。我们可能会认为电话号码属于一个人,尽管它们被建模为单独表格的属性。这是一个很好的线索,表明这是一种识别关系(即使我们没有在PhoneNumbers的主键中包含person_id)。非标识关系是指父级的主键属性不能成为子级的主键。一个很好的例子是查找表,例如Person.state上的外键引用States.state的主键。Person是与States相关的子表。但是Person中的一行不通过其state属性标识。即状态不是Person主键的一部分。非标识关系可以是可选的或强制性的,这意味着外键列分别允许NULL或不允许NULL。


另请参阅我对“仍然困惑于确定与不确定关系”的回答

其他回答

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

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

然而,一本书是由一位作者写的,而且作者可能已经写了多本书。但是,这本书需要作者来写——没有作者,它就不可能存在。因此,这本书与作者之间的关系是一种认同关系。

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

人们一再强调,在一种确定的关系中,没有父母,孩子是不可能存在的。(例如用户287724)。这是真的,但完全没有抓住重点。外键为非空就足够了。它不需要是主键的一部分。

因此,真正的原因是:

识别关系的目的是,外键永远不会更改,因为它是主键的一部分。。。因此识别!!!

非识别关系

非识别关系意味着孩子与父母有亲属关系,但可以单独识别。

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之间的关系。

订单处理就是一个很好的例子。来自客户的订单通常有一个用于标识订单的订单号、每个订单出现一次的一些数据(如订单日期和客户ID)以及一系列行项目。每个行项目包含一个项目编号,用于标识订单中的行项目、订购的产品、该产品的数量、产品的价格以及行项目的金额,可以通过将数量乘以价格来计算。

标识行项目的编号仅在单个订单的上下文中标识行项目。每个订单中的第一行项目是项目编号“1”。行项目的完整标识是项目编号及其所属的订单编号。

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

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

标识关系是指子表中的行是否存在取决于父表中的某一行。这可能会让人困惑,因为现在通常的做法是为子表创建一个伪密钥,但不将外键作为子表主键的父部分。从形式上讲,这样做的“正确”方法是让外键成为孩子的主键的一部分。但逻辑关系是,没有父母,孩子就不可能存在。示例:一个人有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person列中。因为我们希望支持多个电话号码,所以我们创建了第二个表PhoneNumbers,其主键包括引用person表的person_id。我们可能会认为电话号码属于一个人,尽管它们被建模为单独表格的属性。这是一个很好的线索,表明这是一种识别关系(即使我们没有在PhoneNumbers的主键中包含person_id)。非标识关系是指父级的主键属性不能成为子级的主键。一个很好的例子是查找表,例如Person.state上的外键引用States.state的主键。Person是与States相关的子表。但是Person中的一行不通过其state属性标识。即状态不是Person主键的一部分。非标识关系可以是可选的或强制性的,这意味着外键列分别允许NULL或不允许NULL。


另请参阅我对“仍然困惑于确定与不确定关系”的回答