Still Confused About Identifying vs. Non-Identifying Relationships

Question

So, I\'ve been reading up on identifying vs. non-identifying relationships in my database design, and a number of the answers on SO seem contradicting to me. Here are the t

Answer 1

part of the issue here is the confusion of terminology. identifying relationships are useful for avoiding long join paths.

The best definition i have seen is "an identifying relationship includes the PK as of the parent in the the child PK. In other words the PK of the child includes the FK to the parent as well as the "actual" PK of the child.

Answer 2

identifying relationship gives out one to many optional relationship when we have to define parent to child relationship.in addition it gives one to only one relationship from child to parent flow.since parent entity primary key will be the part of primary key of child entity, child entity instance will identify the parent entity instance.it is represented by solid line in er diagram.

where as non identifying relationship will many to many relationship.For the existence of child entity instance there should have parent entity instance but each entity instance in child entity may be related to many entity instance of parent entity.this is the reason why primary key of parent entity well be the foreign key of child entity, but child entity will not take parent entity primary key as its primary key.it will have its own primary key. many to many relation doesn't exist in real world er diagram. so it need to be resolved

Answer 3

Yes, go with first one, but i don't think second one contradicts the first one. It's just formulated a little bit confusing..

UPDATE:

Just checked - second question's answer is wrong in some assumptions,.. book-author is not necessarily 1:n relation, as it could be m:n. In relational databases that creates intersection table for this m:n relation, and you get identifying relations between intersection table and those other 2 tables..

Answer 4

"as I don't want to learn something wrong".

Welll, if you really mean that, then you can stop worrying about ER lingo and terminology. It is imprecise, confused, confusing, not at all generally agreed-upon, and for the most part irrelevant.

ER is a bunch of rectangles and straight lines drawn on a piece of paper. ER is deliberately intended to be a means for informal modeling. As such, it is a valuable first step in database design, but it is also just that : a first step.

Never shall an ER diagram get anywhere near the preciseness, accuracy and completeness of a database design formally written out in D.

Answer 5

Identifying / non-identifying relationships are concepts in ER modelling - a relationship being an identifying one if it is represented by a foreign key that is part of the referencing table's primary key. This is usually of very little importance in relational modelling terms because primary keys in the relational model and in SQL databases do not have any special significance or function as they do in an ER model.

For example, suppose your table enforces two candidate keys, A and B. Suppose A is also a foreign key in that table. The relationship thus represented is deemed to be "identifying" if A is designated to be the "primary" key, but it is non-identifying if B is the primary key. Yet the form, function and meaning of the table is identical in each case! This is why in my opinion I don't think the identifying / non-identifying concept is really very important.

Answer 6

An identifying relationship is indeed an ERD concept as this is the domain of conceptual modelling, modelling our understanding of the 'universe of discourse'. It is a parent-child relationship whereby we model the fact that identity of each child object is (at least in part) established/determined by the identity of the parent object. It is therefore mandatory, and immutable.

A real world example is with the perennial challenge of identifying people. A person's unique identity can be (in part) defined by their relationship with their birth mother and father. When known, these are immutable facts. Therefore the relationship between birth parent and child is an identifying relationship in that it contributes (immutably) to defining the identity of the child.

It is these qualities and the use of relational dbms constructs that result in the PK of the child being a composite key that includes, via FK, the PK of the parent. As a PK, the identity of the child is mandatory and immutable (it can't change) A 'change' in a PK is in fact instantiating a new object. Therefore the PK must not be able to be changed. The immutability of a PK should also be constrained. DB constraints can be used to implement that quality of PKs.