What's the difference between identifying and non-identifying relationships?

Question

I haven't been able to fully grasp the differences. Can you describe both concepts and use real world examples?

Good question, wheel is not be reinvented: [Peter Chen. The Entity Relationship Model, Toward a Unified View of Data, **1976**](http://extras.springer.com/2002/978-3-642-63970-8/DVD3/rom/pdf/Chen_hist.pdf) § 2.3.2: "*If relationships are used for identifying the entities, we shall call it a weak entity relation. If relationships are not used for identifying the entities, we shall call it a regular entity relation*". The OP question boils down to: [What are weak/regular entity relations?](https://vivadifferences.com/difference-between-strong-entity-and-weak-entity-with-examples/). — mins, Apr 25 '20 at 12:52

score 1104 · Accepted Answer · edited May 23 '17 at 12:26

1104

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

edited May 23 '17 at 12:26

Community

1
1

answered Apr 18 '09 at 05:59

Bill Karwin

462,430
80
609
762

10

+1: Bill, "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" - any links as to why this is? Google is failing me. – hobodave Mar 10 '10 at 21:41
1

@hobodave: It's the "convention over configuration" argument. Some schools of thought are that every table should define its primary key for a single-column pseudokey named `id` that auto-generates its values. Application frameworks like Rails have popularized this as a default. They treat natural keys and multi-column keys as divergent from their conventions, needed when using "legacy" databases. Many other frameworks have followed this lead. – Bill Karwin Mar 10 '10 at 23:06
21

It seems like "properly" constructing identifying relationships would lead to obnoxiously huge primary keys. e.g. Building has Floor has Room has Bed. The PK for Bed would be (bed_id, floor_id, room_id, building_id). It seem's strange that I've never seen this in practice, nor heard it suggested as a way to do anything. That's a lot of redundant data in the PK. – hobodave Mar 10 '10 at 23:34
27

@hobodave: I have seen multi-column primary keys that are even larger. But I take your point. Consider that multi-column primary keys convey more information; you can query the `Beds` table for all beds in a specific building without doing *any* joins. – Bill Karwin Mar 11 '10 at 01:00
@Bill Karwin If I have `user` table and there are fields `user_id` and `updated_by` and I would like `update_by` to reference the `user_id`, then relation must be non-identifying I think. Could you tell me am I correct in that part? – Eugene Jul 29 '11 at 13:53
2

@Eugene, yes I would expect that to be a non-identifying relationship. `user_id` should be the primary key by itself, and `updated_by` is not part of a multi-column primary key. – Bill Karwin Jul 29 '11 at 14:18
What if a child depends on two parents?, I suppose it will be needed a composed primary key of 3 { id, parentId1, parentId2 }. – Daniel Conde Marin Sep 28 '13 at 07:40
@leoMestizo, yes, any weak entity would have an identifying relationship with its parent entity table. The phone number example would be a good case. – Bill Karwin Oct 28 '13 at 16:40
@BillKarwin can an identifying relatonship have Mandatory/Optional?? – WantIt Mar 11 '14 at 22:19
@IvanMatala, by definition a foreign key in an identifying relationship is part of the child table's primary key. Primary keys cannot be null, so the answer is no, an identifying relationship cannot be optional. – Bill Karwin Mar 12 '14 at 02:13
I have read DBMS's book Elmasri navathe (and some chapters from korth also) sincerely but I didn't read this terms "identifying relationship"!! Is there any other any other terminology used for this? – Grijesh Chauhan Apr 20 '14 at 19:39
1

The example given of an identifying relationship is bad. Phone numbers change ownership over time. I would also have liked to see what the point is- why does the distinction matter? – Max Heiber Nov 04 '14 at 02:49
1

@mheiber, yes, phone numbers change ownership, but they have one owner at any given point in time. So you can change the foreign key to another user. – Bill Karwin Nov 11 '14 at 15:13
@BillKarwin Thanks. But how is that an identifying relationship, then? The identities of phone numbers and people don't seem to be interdependent. – Max Heiber Nov 12 '14 at 17:05
1

@mheiber, identifying relationship just means that the foreign key in the phone numbers table is also part of that table's primary key, and therefore must be NOT NULL. The phone number can be reassigned to another user, but it must always reference one user or another. – Bill Karwin Nov 12 '14 at 17:20
I know it's an old thread, but for the non-identifying, can the child exist without their State in your example i.e: NULL? The State is deleted, but the Person still exists? – Atieh Nov 19 '14 at 15:43
@Atieh, yes, a non-identifying relationship allows the Person to exist without referencing any State. – Bill Karwin Nov 19 '14 at 16:18
2

@BillKarwin the example of `Person` and `PhoneNumber` is not quite good. If you attach `Person.id` into the primary key of `PhoneNumber` then you will lose data integrity, as you can create a row in `PhoneNumber` that has a phone id for 2 people, e.g., the pair `(123, 45)` and `(123, 46)` will not violate any constraint and thats not what you want. – Sebastian Apr 06 '15 at 00:55
@Sebastian, that's not a data integrity problem, because the primary key is still unique. Think of it this way: if the `PhoneNumber` primary key were `(person_id, sequence)` and `sequence` starts numbering at **1** for each person, then you'd have many persons with the same value for `sequence`. The `sequence` column alone is not required to be unique, because the combination of the two columns is unique. – Bill Karwin Apr 06 '15 at 04:28
@BillKarwin I didn't meant data integrity for the engine. Your data model will allow you to do things you don't want to. – Sebastian Apr 06 '15 at 04:34
2

In other words, your model allows you to have a phone number attached to more than 1 person – Sebastian Apr 06 '15 at 04:37
@Sebastian, you're assuming that a given id value refers to the same phone instance, which is not necessarily true. The *combination* of columns in the primary key identifies the phone. In your model, you break 2nd normal form by relying on *part* of the key. – Bill Karwin Apr 06 '15 at 07:19
2

@BillKarwin I'm not assuming. I'm using what the model could model. Your `PhoneNumber` table will have `PK(Person.id, PhoneNumber.id)`. That makes a combination of 2 values to indentify a row. Again, you could have `(45, 123)` and `(46, 123)`. Those values represents 2 rows as they are differents primary keys. They also references 2 different rows in the `Person` table. Now, you need to ensure that fields corresponding the telephone number for those rows be different. – Sebastian Apr 06 '15 at 12:59
6

I will never use this to model that. The best answer is from "aqsa rao" below that states the following: "An identifying relationship means that the child table cannot be uniquely identified without the parent." Because your definition is adding unecessary semantic that could confuse people. It's not the dependency between entities the reason you create an identifying or non-indentifying relationship. – Sebastian Apr 06 '15 at 13:03
@Sebastian, well, I can only suggest you study what [Second Normal Form](http://en.wikipedia.org/wiki/Second_normal_form) means to this case. – Bill Karwin Apr 06 '15 at 15:52
"An identifying relationship is when the existence of a row in a child table depends on a row in a parent table." This only means that the child row existentially depends on the parent row, it does not imply an identifying relationship. An identifying relationship is a special case of existential dependence. For example, we could say that a Worker has to be associated with one and only one Project (existential dependence) but this not imply that the Worker will have the Project.ID as part of it's primary key. – vladimirm Jan 27 '16 at 12:55
What about *Unique Value?* – Ubi hatt Nov 05 '19 at 11:12

score 920 · Answer 2 · edited May 10 '17 at 16:04

920

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.

edited May 10 '17 at 16:04

Dennis

6,954
8
53
97

answered Mar 06 '10 at 12:54

4

A decent explanation but I believe it's also instructive to extend the example a little bit. A book has a number of pages. It cannot exist without pages and therefore we might conclude that the relationship between a book and the number of pages it has is also an identifying relationship. But will the number of pages attribute be part of any identification scheme (key) for the book? Probably not. The term "identifying relationship" is normally reserved for relationships involving *identifying* attributes - *prime* attributes in relational terms. – nvogel May 11 '13 at 08:20
14

What happens if the book was written by more than 1 author? It's not identifying relationship any more as M:N type, why? – NGix Nov 26 '13 at 21:49
2

These real examples are useless. When you realize how you create tables in ER and how data integrity will hold, you then throw away these examples. If you create a strong relationship between two entities, you are forcing to create a primary key in the entity table combined with PK from the other entity. If your model allows you that the same book can have multiple authors, then it's ok to be strong. But if your model only allows you 1 author 1 book, you can't have that constraint using strong relationship because `PK(Book.id, Book.person_id)`. – Sebastian Apr 06 '15 at 01:05
3

but the real usage is "can book exist without the author ?". The answer is yes in reality, because people will look for the book directly. Therefore in practice, for this case, they should be always be "non-identifying relationship". – windmaomao Jan 17 '16 at 16:45
4

what is going on guys !!, This is not a valid example for `the Identifying relationship` !!! yes a book can't be written without an author but , the author field in the books table is **NOT IDENTIFYING** the book row !!! – Accountant م Jun 01 '16 at 20:14
2

To make it technical now, the author_id should propagate as both FK and PK in "books". Assuming a book has no copies, owner_id must also propagate as FK, but not as PK. The reason why you never actually see the first identifying relationship in real world database design is we prefer to identify books by ISBN and look at them as independent. A book may be also written by more then one author, and may have multiple copies. – Cristi S. Aug 07 '16 at 01:05
1

helped me understand better than the Accepted answer! – Mostafiz Rahman Dec 19 '16 at 09:55
1

Your example is valid **if and only if** the author has written only that book and the book table does not have any other field to identify it properly (like its ISBN). So **this answer is not valid in a real world application**. How can I prove this? Try to find _Hamlet_ in Amazon using its author field. Why does the _Romeo and Juliet_ tragedy appear? Maybe did Shakespeare write it too? – cpinamtz Dec 28 '17 at 11:27

Daniel Dinnyes · Answer 3 · 2020-08-07T10:12:20.583

44

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!!!

edited Aug 07 '20 at 10:12

answered Jul 04 '17 at 12:39

Daniel Dinnyes

4,371
2
29
41

3

+1 for "It would be enough enough for the foreign key to be non-null, to achieve this." It *should* be enough, but unfortunately it's not when it comes to something like Entity Framework, which doesn't work right unless you use an identifying relationship, but then the "Id" field of an entity loses it's uniqueness as a result of being just a part of a composite key. – Triynko Aug 09 '17 at 19:17

score 25 · Answer 4 · answered Apr 18 '09 at 05:45

25

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...

answered Apr 18 '09 at 05:45

Christian C. Salvadó

723,813
173
899
828

6

This sounds more like a description of total participation in a relationship, than of an identifying relationship. – Thomas Padron-McCarthy Apr 18 '09 at 06:03
I disagree with the above definitions. You may have an object that depends on its parent and you want that object to be constrained to be linked only with 1 parent row. A `House` has `Wall`s. You remove house and you don't have walls. But a wall belongs only to a house. So doing strong-relationship won't work: `PK(Wall.id, House.id)` will allow you to insert into the model the same wall to another house. – Sebastian Apr 06 '15 at 01:08
The reason to have the `House_Wall` table is to identifying a Wall inside a House. It's the identifying relationship. The House_Wall table is like `PK(House.id, wall_number), FK(Wall.id)`. The wall_number is a sequence in a house and not unique without House.id. If you want to model like `PK(Wall.id, House.id)` and Wall.id must be unique, then it's enough to have House.id in the Wall table as FK. It's just trying to model different things. – QuestionDriven Oct 06 '20 at 08:12

score 16 · Answer 5 · answered Apr 18 '09 at 05:51

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

Your answer conflicts with that given by Bill Karwin, in the difference between whether the Foreign Key "is not" or "must not" be part of the Primary Key in the Child row. — Nicole, Aug 01 '09 at 15:47
@Andy White But could the primary key of the parent in an identifying relationship be non-mandatory, i.e., null, when it is part of a three-column composite primary key? — Frederik Krautwald, Apr 29 '15 at 21:21

score 13 · Answer 6 · edited Feb 11 '19 at 02:59

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, thecountry_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!.

You're right, if you only have tables books and authors. There is no identifying relationship there. But if you use a third table to represent the many-to-many relationship, the primary key of that third table consists of two foreign keys, referencing the books table and the authors table. That table has an identifying relationship to both books and authors. See my example in http://stackoverflow.com/questions/2814469/still-confused-about-identifying-vs-non-identifying-relationships/2814663#2814663 — Bill Karwin, Jun 01 '16 at 22:50

score 10 · Answer 7 · answered May 22 '14 at 14:31

10

Non-identifying relationship

A non-identifying relationship means that a child is related to parent but it can be identified by its own.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

The relationship between ACCOUNT and PERSON is non-identifying.

Identifying relationship

An identifying relationship means that the parent is needed to give identity to child. The child solely exists because of parent.

This means that foreign key is a primary key too.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

The relationship between ITEM_LANG and ITEM is identifying. And between ITEM_LANG and LANGUAGE too.

answered May 22 '14 at 14:31

Skarllot

685
6
16

3

How is PERSON and ACCOUNT non - identifying? How can ACCOUNT exist without PERSON? – MrRobot9 Sep 05 '18 at 15:59
why there is no answer for the previous comment? @MrRobot9 – AAEM Feb 10 '19 at 21:51
1

"How is PERSON and ACCOUNT non - identifying?" Because it's modeled as such. An account can be identified without knowing person_id. Why is it modeled as such? Because an account can have a different person as its owner in its lifetime. On the other hand, an ITEM_LANG cannot have a different ITEM in its lifetime. Although you can have different combinations, thier identities are different unlike the account-person relationship. – QuestionDriven Oct 06 '20 at 07:34

Daishi · Answer 8 · 2015-04-24T07:28:47.983

If you consider that the child item should be deleted when the parent is deleted, then it is an identifying relationship.

If the child item should be kept even though the parent is deleted, then it is a non-identifying relatioǹship.

As an example, I have a training database with trainees, trainings, diplomas and training sessions :

trainees have an identifying relationship with training sessions
trainings have an identifying relationship with training sessions
but trainees have a non-identifying relationship with diplomas

Only training sessions should be deleted if one of the related trainee, training or diploma is deleted.

Daniel Pinheiro · Answer 9 · 2016-02-10T05:20:14.473

Like well explained in the link below, an identifying relation is somewhat like a weak entity type relation to its parent in the ER conceptual model. UML style CADs for data modeling do not use ER symbols or concepts, and the kind of relations are: identifying, non-identifying and non-specific.

Identifying ones are relations parent/child where the child is kind of a weak entity (even at the traditional ER model its called identifying relationship), which does not have a real primary key by its own attributes and therefore cannot be identified uniquely by its own. Every access to the child table, on the physical model, will be dependent (inclusive semantically) on the parent's primary key, which turns into part or total of the child's primary key (also being a foreign key), generally resulting in a composite key on the child side. The eventual existing keys of the child itself are only pseudo or partial-keys, not sufficient to identify any instance of that type of Entity or Entity Set, without the parent's PK.

Non-identifying relationship are the ordinary relations (partial or total), of completely independent entity sets, whose instances do not depend on each others' primary keys to be uniquely identified, although they might need foreign keys for partial or total relationships, but not as the primary key of the child. The child has its own primary key. The parent idem. Both independently. Depending on the cardinality of the relationship, the PK of one goes as a FK to the other (N side), and if partial, can be null, if total, must be not null. But, at a relationship like this, the FK will never be also the PK of the child, as when an identifying relationship is the case.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

score 3 · Answer 10 · answered Jan 21 '18 at 07:25

Do attributes migrated from parent to child help identify¹ the child?

If yes: the identification-dependence exists, the relationship is identifying and the child entity is "weak".
If not: the identification-dependence doesn't exists, the relationship is non-identifying and the child entity "strong".

Note that identification-dependence implies existence-dependence, but not the other way around. Every non-NULL FK means a child cannot exist without parent, but that alone doesn't make the relationship identifying.

For more on this (and some examples), take a look at the "Identifying Relationships" section of the ERwin Methods Guide.

P.S. I realize I'm (extremely) late to the party, but I feel other answers are either not entirely accurate (defining it in terms of existence-dependence instead of identification-dependence), or somewhat meandering. Hopefully this answer provides more clarity...

¹ The child's FK is a part of child's PRIMARY KEY or (non-NULL) UNIQUE constraint.

score 3 · Answer 11 · answered Apr 01 '11 at 18:47

The identifing relaionship means the child entity is totally depend on the existance of the parent entity. Example account table person table and personaccount.The person account table is identified by the existance of account and person table only.

The non identifing relationship means the child table does not identified by the existance of the parent table example there is table as accounttype and account.accounttype table is not identified with the existance of account table.

score 2 · Answer 12 · answered Apr 19 '09 at 12:07

A good example comes from order processing. An order from a customer typically has an Order Number that identifies the order, some data that occurs once per order such as the order date and the Customer ID, and a series of line items. Each line item contains an item number that identifies a line item within an order, a product ordered, the quantity of that product, the price of the product, and the amount for the line item, which could be computed by multiplying the quantity by the price.

The number that identifies a line item only identifies it in the context of a single order. The first line item in every order is item number "1". The complete identity of a line item is the item number together with the order number of which it is a part.

The parent child relationship between orders and line items is therefore an identifying relationship. A closely related concept in ER modeling goes by the name "subentity", where line item is a subentity of order. Typically, a subentity has a mandatory child-parent identitying relationship to the entity that it's subordinate to.

In classical database design, the primary key of the LineItems table would be (OrderNumber, ItemNumber). Some of today's designers would give an item a separate ItemID, that serves as a primary key, and is autoincremented by the DBMS. I recommend classical design in this case.

score 1 · Answer 13 · answered Sep 09 '20 at 21:22

A complement to Daniel Dinnyes' answer:

On a non-identifying relationship, you can't have the same Primary Key column (let's say, "ID") twice with the same value.

However, with an identifyinig relationship, you can have the same value show up twice for the "ID" column, as long as it has a different "otherColumn_ID" Foreign Key value, because the primary key is the combination of both columns.

Note that it doesn't matter if the FK is "non-null" or not! ;-)

score 0 · Answer 14 · edited May 12 '16 at 23:24

0

An identifying relationship is between two strong entities. A non-identifying relationship may not always be a relationship between a strong entity and a weak entity. There may exist a situation where a child itself has a primary key but existence of its entity may depend on its parent entity.

For example : a relationship between a seller and a book where a book is being sold by a seller may exist where seller may have its own primary key but its entity is created only when a book is being sold

Reference based on Bill Karwin

edited May 12 '16 at 23:24

xAditya3393

129
3
12

answered Sep 29 '13 at 12:00

sp1rs

776
8
21

6

It might help to define what you mean by a "strong" and "weak" entity here. – nullability Dec 30 '13 at 20:33

score 0 · Answer 15 · answered Aug 06 '14 at 12:47

Let's say we have those tables:

user
--------
id
name


comments
------------
comment_id
user_id
text

relationship between those two tables will identifiying relationship. Because, comments only can be belong to its owner, not other users. for example. Each user has own comment, and when user is deleted, this user's comments also should be deleted.

What's the difference between identifying and non-identifying relationships?

15 Answers15

Linked

Related