识别关系和非识别关系的区别

在本文中，我们将讨论实体的概述以及识别和非识别关系，最后将重点讨论两者之间的差异。让我们一一讨论。

概述：

没有自己的关键属性的实体类型被称为弱实体类型。与此不同的是，存在具有其关键属性的常规实体类型，也称为强实体类型。
属于弱实体类型的实体在与具有自己关键属性的其他实体相关时被识别，也称为强实体类型或识别或所有者实体类型。
强实体类型的一个或多个关键属性与任意数量的弱实体类型属性相关联以识别它。

识别关系：
将弱实体类型与所有者实体类型相关联的关系称为标识关系。弱实体类型总是完全参与(存在依赖)关系，因为弱实体类型在没有所有者身份的情况下无法识别。这并不意味着每个存在依赖(总参与)都会导致弱实体类型。

识别关系

图表说明 –

这里的家庭成员(实体)是一个弱实体。它没有任何主键。给定所有者 id(即主键 Cust_id)和弱实体的一个或多个属性(即家庭成员的姓名)，我们可以唯一标识弱实体关系中的元组。
Name 不是弱实体中的主键，而是弱实体中的一个键属性。在 ER 图中，弱实体部分键用虚线下划线表示。
所有者实体应该始终是一个强实体，所有者和弱实体之间的关系始终是一对多的，弱实体完全参与
ER图中的双菱形框代表弱实体与其所有者强实体之间的关系，这种关系称为识别关系。因为存在一对多的关系并且多方完全参与。所以这里需要两种关系，一种用于弱实体，一种用于弱实体和弱关系属性。
一个弱实体类型可能有多个识别实体类型和一个度数高于两个的识别关系类型。
标识实体类型有时也称为父实体类型或主导实体类型。弱实体类型有时也称为子实体类型。

示例-1：
让我们专注于电影、导演和电影_导演的关系。

需求分析：
一个导演可以导演很多(M)部电影，而一部电影可以由很多(N)个导演导演。因此，这是 M:N 关系，因此需要该关系来存储此信息。一个关系用于存储电影信息，一个关系用于存储导演信息，一个关系(movies_directors)，其中movie_id作为电影关系的外键，director_id作为导演关系的外键，因此，它们有助于参考电影表和导演表，以提供用户指定的查询结果。电影和电影导演之间的关系是太多(一部电影可以由多个导演执导)，导演和电影导演之间的关系也太多(因为一个导演可以导演多部电影)。因此，movies 和movie_directors 之间的关系是识别关系，因为child(即movie_directors)中的每个元组都取决于存在于movies 关系中的条目。以同样的方式，导演和电影导演也与识别关系有关。如果我们从 movie Relation 中删除任何条目，那么也需要删除 movie_directors 中的相应条目。

二元关系的符号

非识别关系：
在非标识关系中，父表的主要属性/属性(即主键的属性)在子表中不用作主要属性/属性，但可以作为子表的主要属性/属性(即非主要) .这里国家(父)表和城市(子表)之间的虚线代表国家和城市之间的非识别关系。可以在没有父实体的情况下唯一标识子实体。

国家/地区表

城市表

示例1 ：

如果您有作者关系和书籍关系。在某些情况下，我们可能需要存储有关一本书的数据，但我们不知道作者是谁。这本书的身份/存在不依赖于作者的信息。
在上述非识别关系的例子中，国家实体Code属性作为主键，用于唯一识别国家关系。这里国家(即父表)的主键(即代码)存在于城市(即子)表中，但不作为主键或主键的一部分。
两个关系城市(孩子)和国家(父母)与非识别关系相关联。关系城市以 ID 作为主键。但在国家实体中，Code 属性被用作唯一标识国家关系的主键。这里父国家的主键(即代码)存在于城市(即子)关系中，但不是作为主键或主要属性)。

非识别关系的部分：
非识别关系进一步分为以下两部分。

强制性非身份关系
可选的非识别关系

让我们讨论一下。

强制性非身份关系 –
当存在于子关系中的父关系属性不能包含 NULL 值时，就存在“强制”非标识关系。
可选的非标识关系——当父关系(主要属性或主键)的属性包含空值时，两个关系之间存在“可选”非标识关系。

识别关系和非识别关系的区别：

S.No.	Identifying relationship	Non-identifying relationship
1.	In identifying relationship, the primary key of parent(Identifying entity type) is added in child relations with some attribute/attributes of the child for uniquely identifying each tuple in child relation i.e. a tuple in the child table depends on the row in the parent table.	In a non-identifying relationship, the prime attribute/data tributes (i.e. attribute of primary key) of a parent is not used as prime attribute/attributes in the child table, but it can be attributed (i.e. non-prime) of the child table.
2.	For example – The above example was taken in identifying relationships. In that example, every tuple in family member relation(which includes attributes like name, age of family member) can not be uniquely determined by relation Family_member. So the customer primary key is combined with one or more attributes(i.e. name) to uniquely identify a tuple in relation to a Family member. So the relationship between Customer (i.e. Parent table) and Family_member(child table) is identifying( i.e. a row in Family_member table/relation depends upon row in Customer table). Here the combination of C_Id(i.e. from the parent table and name in Family member(child) table) together helps to identify each tuple in Family_member.	For example – In the above example taken in the non-identifying relationship. The country entity, Code attribute is used as the primary key for uniquely identifying country relations. Here the primary key(i.e. Code) of the country which is the parent table is present in the city(i.e. child) table but not as a part of the primary key or primary key. Each tuple in relation to the city can be uniquely identified without referring to country relation. The relationship between city and country is defined as ‘different cities can belong to the same country’ So this is many to one non-identifying relationship because a relation city can be uniquely identified with ID(i.e. its primary key).

S.No.

Identifying relationship

Non-identifying relationship

In identifying relationship, the primary key of parent(Identifying entity type) is added in child relations with some attribute/attributes of the child for uniquely identifying each tuple in child relation i.e. a tuple in the child table depends on the row in the parent table.

In a non-identifying relationship, the prime attribute/data tributes (i.e. attribute of primary key) of a parent is not used as prime attribute/attributes in the child table, but it can be attributed (i.e. non-prime) of the child table.

For example –
The above example was taken in identifying relationships.

In that example, every tuple in family member relation(which includes attributes like name, age of family member) can not be uniquely determined by relation Family_member.
So the customer primary key is combined with one or more attributes(i.e. name) to uniquely identify a tuple in relation to a Family member.
So the relationship between Customer (i.e. Parent table) and Family_member(child table) is identifying( i.e. a row in Family_member table/relation depends upon row in Customer table).
Here the combination of C_Id(i.e. from the parent table and name in Family member(child) table) together helps to identify each tuple in Family_member.

For example –
In the above example taken in the non-identifying relationship.

The country entity, Code attribute is used as the primary key for uniquely identifying country relations.
Here the primary key(i.e. Code) of the country which is the parent table is present in the city(i.e. child) table but not as a part of the primary key or primary key.
Each tuple in relation to the city can be uniquely identified without referring to country relation.
The relationship between city and country is defined as ‘different cities can belong to the same country’ So this is many to one non-identifying relationship because a relation city can be uniquely identified with ID(i.e. its primary key).