Identifying relationships exist when the primary key of the parent entity is included in the primary key of the child entity. On the other hand, a non-identifying relationship exists when the primary key of the parent entity is included in the child entity but not as part of the child entity's primary key.
A non-identifying relationship is a relationship between two entities in which an instance of the child entity is not identified through its association with a parent entity, which means the child entity is not dependent on the parent entity for its identity and can exist without it.
An identifying relationship is a relationship between two entities in which an instance of a child entity is identified through its association with a parent entity, which means the child entity is dependent on the parent entity for its identity and cannot exist without it.
The double diamond box in ER diagram represents a relation between a weak entity and its owner strong entity, this relationship is called an identifying relationship.
An identifying relationship is when the existence of a row in a child table depends on a row in a parent table. This may be confusing because it's common practice these days to create a pseudokey for a child table, but not make the foreign key to the parent part of the child's primary key. Formally, the "right" way to do this is to make the foreign key part of the child's primary key. But the logical relationship is that the child cannot exist without the parent.
Example: A Person
has one or more phone numbers. If they had just one phone number, we could simply store it in a column of Person
. Since we want to support multiple phone numbers, we make a second table PhoneNumbers
, whose primary key includes the person_id
referencing the Person
table.
We may think of the phone number(s) as belonging to a person, even though they are modeled as attributes of a separate table. This is a strong clue that this is an identifying relationship (even if we don't literally include person_id
in the primary key of PhoneNumbers
).
A non-identifying relationship is when the primary key attributes of the parent must not become primary key attributes of the child. A good example of this is a lookup table, such as a foreign key on Person.state
referencing the primary key of States.state
. Person
is a child table with respect to States
. But a row in Person
is not identified by its state
attribute. I.e. state
is not part of the primary key of Person
.
A non-identifying relationship can be optional or mandatory, which means the foreign key column allows NULL or disallows NULL, respectively.
See also my answer to Still Confused About Identifying vs. Non-Identifying Relationships
There is another explanation from the real world:
A book belongs to an owner, and an owner can own multiple books. But, the book can exist also without the owner, and ownership of it can change from one owner to another. The relationship between a book and an owner is a non-identifying relationship.
A book, however, is written by an author, and the author could have written multiple books. But, the book needs to be written by an author - it cannot exist without an author. Therefore, the relationship between the book and the author is an identifying relationship.
Bill's answer is correct, but it is shocking to see that among all the other answers no one points out the most significant aspect.
It has been said over and over again, that in an identifying relationship the child can not exist without the parent. (e.g. user287724). This is true, but completely misses the point. It would be enough for the foreign key to be non-null to achieve this. It does not need to be part of the primary key.
So here is the real reason:
The purpose of an identifying relationship is that the foreign key can NEVER CHANGE, because it is part of the primary key... therefore identifying!!!
An Identifying relationship specifies that a child object cannot exist without the parent object
Non-identifying relationships specifies a regular association between objects, 1:1 or 1:n cardinality.
Non-identifying relationships can be specified as optional where a parent is not required or mandatory where a parent is required by setting the parent table cardinality...
Here's a good description:
Relationships between two entities may be classified as being either "identifying" or "non-identifying". Identifying relationships exist when the primary key of the parent entity is included in the primary key of the child entity. On the other hand, a non-identifying relationship exists when the primary key of the parent entity is included in the child entity but not as part of the child entity's primary key. In addition, non-identifying relationships may be further classified as being either "mandatory" or "non-mandatory". A mandatory non-identifying relationship exists when the value in the child table cannot be null. On the other hand, a non-mandatory non-identifying relationship exists when the value in the child table can be null.
http://www.sqlteam.com/article/database-design-and-modeling-fundamentals
Here's a simple example of an identifying relationship:
Parent
------
ID (PK)
Name
Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name
Here's a corresponding non-identifying relationship:
Parent
------
ID (PK)
Name
Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name
user287724's answer gives the following example of the book and author relationship:
A book however is written by an author, and the author could have written multiple books. But the book needs to be written by an author it cannot exist without an author. Therefore the relationship between the book and the author is an identifying relationship.
This is a very confusing example and is definitely not a valid example for an identifying relationship
.
Yes, a book
can not be written without at least one author
, but the author
(it's foreign key) of the book
is NOT IDENTIFYING the book
in the books
table!
You can remove the author
(FK) from the book
row and still can identify the book row by some other field (ISBN
, ID
, ...etc) , BUT NOT the author of the book!!
I think a valid example of an identifying relationship
would be the relationship between (products table) and a (specific product details table) 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
In this example the Product_ID
in the printers_details
table is considered a FK references the products.id
table and ALSO a PK in the printers_details
table , this is an identifying relationship because the Product_ID
(FK) in the printers table IS IDENTIFYING the row inside the child table, we can't remove the product_id
from the child table because we can't identify the row any more because we lost it's primary key
If you want to put it in 2 lines:
an identifying relationship is the relationship when the FK in the child table is considered a PK(or identifier) in the child table while still references the parent table
Another example may be when you have 3 tables (imports - products - countries) in an imports and exports for some country database
The import
table is the child that has these fields(the product_id
(FK), the country_id
(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) )
we may use the (
product_id, the
country_id`) to identify each row of the imports "if they all in the same year" here the both columns can compose together a primary key in the child table(imports) and also referencing there parent tables.
Please I'm happy I finally understand the concept of the identifying relationship
and non identifying relationship
, so please don't tell me I'm wrong with all of these vote ups for a completely invalid example
Yes logically a book can't be written without an author but a book can be identified without the author,In fact it can't be identified with the author!
You can 100% remove the author from the book row and still can identify the book!.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With