杨思为 | 我们一家

identifying relationship与non identifying relationship的不同之处

在使用CASE工具进行数据库建模，在创建表与表的关系时应该弄清楚“Identifying relationship”与“non-identifying relationship”的含义，以及“Identifying relationship”与“non-identifying relationship”的不同之处，下边是我对这两种关系的理解。

让我们从这样一个例子开始，例如图书管理系统中设计了以下两个数据表，分别是作者表（Authors）和图书清单表（Booklist），这两个表的结构如下：

其中图书表的“Auth_id”作为外键码约束条件引用作者表的主键码，说得通俗点就是说作者表（Authors）是父表，图书表（Booklist）是子表。要想知道图书表中《WordPress技巧》的作者是谁，需要通过字段“Auth_id”在作者表中查询，也就是说Auth_id是图书表的外键码。

即父记录在子记录创建之前创建，子记录在父记录删除之前删除。

例如要在图书表添加《CSS实战》这本图书，首先要在作者表先添加作者“yangjf”；而如果要在作者表中删除作者“yangjf”这本书，首先要删除图书表中《CSS实战》这本书，从而保证数据的引用完整性，也就避免出现无父记录的“孤儿”记录。

说了那么多，那么以上两个表究竟是“Identifying relationship”关系，还是“non-identifying relationship”关系呢？答案取决于这个图书管理系统的业务规则。

1、当图书管理系统的业务规则规定：作者必须有图书，没有图书的作者不能录入系统中。

那么作者表（Authors）与图书表（Booklist）的关联关系为“Identifying relationship”。

也就是说“identifying relationship”表示如果父表有记录，那么子表中必须有记录。即作者表（Authors）中的每一位作者在图书表（Booklist）中至少存在一本书（当然可以有多本书，因为一个作者完全有可能有多本书）。

同理，“identifying relationship”关联关系还表示如果父表没有记录，则子表也不能有记录。例如如果作者表中没有作者“yangjf”的信息，那么图书表中就不能有图书《CSS实战》。

2、当图书管理系统的业务规则规定：作者可以没有图书。

那么作者表（Authors）与图书表（Booklist）的关联关系为“non-identifying relationship”。

也就是说“non-identifying relationship”表示父表的数据可以独立于子表的数据存在； 

 例如上图的作者表中的作者“jimmy”可以在图书表中没有记录，也就是说可以允许作者没有书籍。那么以上两个表的关系就为“non-identifying relationship”

以上是我对“Identifying relationship”与“non-identifying relationship”关联关系的理解，有什么不对请您指出，非常感谢。

以下则是我在上网搜集的一些关于这两者关系的资料（其中有的理解和我的不一样），也放在这里，希望对您有所帮助：）

判别一个关系是Non-Identifying还是Identifying只要区分子实体的主键，看是否需要父实体的外键来共同作为主键，需要则为Identifying，如果子实体自己的主键就可唯一标识则它为Non-Identifying！

以下是具体的定义：

ER模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。

如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。非强制的非标识关系，用带菱形的虚线表示。

—————————–

 以下这篇关于“Identifying and non-identifying relationships”区别的资料我觉得非常不错，其实我感觉和我上边举的例子基本是一样的：）

Identifying and non-identifying relationships

An identifying relationship means that the child table cannot be uniquely identified without the parent. For example, you have this situation in the intersection table used to resolve a many-to-many relationship where the intersecting table’s Primary Key is a composite of the left and right (parents) table’s Primary Keys.

Example…
Account (AccountID, AccountNum, AccountTypeID)
PersonAccount (AccountID, PersonID, Balance)
Person(PersonID, Name)

The Account to PersonAccount relationship and the Person to PersonAccount relationship are identifying because the child row (PersonAccount) cannot exist without having been defined in the parent (Account or Person). In other words: there is no personaccount when there is no Person or when there is no Account.

A non-identifying relationship is one where the child can be identified independently of the parent ( Account – AccountType)

Example…
Account( AccountID, AccountNum, AccountTypeID )
AccountType( AccountTypeID, Code, Name, Description )

The relationship between Account and AccountType is non-identifying because each AccountType can be identified without having to exist in the parent table.

You can define the relationship type (identifying/non identifying) in the DeZign for Databases in the relationship dialog. Double click on the relationship line in the diagram window to display the relationship dialog.

作者：思为爸爸 分类：数据库 标签：CASE工具, identifying relationship, non identifying relationship, 数据库 时间：2008年10月28日

当前位置：首页>开发研究>数据库>

上一篇：WordPress创建简单讨论区——自定义分类模板

下一篇：Case studio是什么？Case studio介绍

姓名 (必填)

邮件（我们一家会保密的） (必填)

站点

订阅该评论