我还不能完全理解这些差异。你能描述这两个概念并使用真实世界的例子吗?
当前回答
标识关系是指子表中的行是否存在取决于父表中的某一行。这可能会让人困惑,因为现在通常的做法是为子表创建一个伪密钥,但不将外键作为子表主键的父部分。从形式上讲,这样做的“正确”方法是让外键成为孩子的主键的一部分。但逻辑关系是,没有父母,孩子就不可能存在。示例:一个人有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person列中。因为我们希望支持多个电话号码,所以我们创建了第二个表PhoneNumbers,其主键包括引用person表的person_id。我们可能会认为电话号码属于一个人,尽管它们被建模为单独表格的属性。这是一个很好的线索,表明这是一种识别关系(即使我们没有在PhoneNumbers的主键中包含person_id)。非标识关系是指父级的主键属性不能成为子级的主键。一个很好的例子是查找表,例如Person.state上的外键引用States.state的主键。Person是与States相关的子表。但是Person中的一行不通过其state属性标识。即状态不是Person主键的一部分。非标识关系可以是可选的或强制性的,这意味着外键列分别允许NULL或不允许NULL。
另请参阅我对“仍然困惑于确定与不确定关系”的回答
其他回答
比尔的回答是正确的,但令人震惊的是,在所有其他答案中,没有人指出最重要的方面。
人们一再强调,在一种确定的关系中,没有父母,孩子是不可能存在的。(例如用户287724)。这是真的,但完全没有抓住重点。外键为非空就足够了。它不需要是主键的一部分。
因此,真正的原因是:
识别关系的目的是,外键永远不会更改,因为它是主键的一部分。。。因此识别!!!
假设我们有这些桌子:
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将确定关系。因为,评论只能属于其所有者,而不能属于其他用户。例如每个用户都有自己的评论,当用户被删除时,该用户的评论也应被删除。
这里有一个很好的描述:
两个实体之间的关系可分为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时,存在识别关系。另一方面,当父实体的主键包含在子实体中但不作为子实体主键的一部分时,存在非标识关系。此外,不可识别的关系可进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时,存在强制的非标识关系。另一方面,当子表中的值可以为空时,存在非强制的非标识关系。
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
识别关系意味着子实体完全依赖于父实体的存在。
示例帐户表人员表和人员帐户。人员帐户表仅通过帐户和人员表的存在来标识。
非标识关系意味着父表的存在不标识子表。
示例accountType和account.accountType表未标识为存在科目表。
现实世界还有另一种解释:
一本书属于所有者,所有者可以拥有多本书。但是,这本书也可以在没有所有者的情况下存在,它的所有权可以从一个所有者变为另一个所有者。书籍和所有者之间的关系是一种不可识别的关系。
然而,一本书是由一位作者写的,而且作者可能已经写了多本书。但是,这本书需要作者来写——没有作者,它就不可能存在。因此,这本书与作者之间的关系是一种认同关系。
推荐文章
- 将值从同一表中的一列复制到另一列
- 什么是数据库池?
- 关于数据库,每个开发人员应该知道些什么?
- "where 1=1"语句
- 是使用各有一个模式的多个数据库更好,还是使用一个数据库有多个模式更好?
- 如何从Oracle的表中获取列名?
- 如何检查表上持有哪些锁
- 在MongoDB中查找重复的记录
- 对于PostgreSQL表来说,多大才算太大?
- 模式、表和数据库之间的区别是什么?
- 我看到VARCHAR(255)如此频繁地使用(而不是其他长度),有什么好的原因吗?
- 使用pgadmin连接到heroku数据库
- Delete_all vs destroy_all
- 我如何移动一个redis数据库从一个服务器到另一个?
- 如何首次配置postgresql ?