Why is it necessary to indicate identifying or non-identifying relationships in an ERD?

Question

In an ERD, a weak/non-identifying relationship is one that connects two strong entities, and is indicated with a dashed line. A strong/identifying relationship is one that connects a strong entity to a weak entity (a weak entity is one that contains the foreign key [FK] from its related entity as a component of its own primary key [PK]), and is indicated by a solid line.

My question is, So what? Why is it so important to distinguish between weak/non-identifying relationships versus strong/identifying relationships that ERD designers are supposed to make that distinction with dashed versus solid lines, respectively? Why does it matter so much?

For me, every element and convention in an ERD should add necessary information that either translates directly into the database design (that is, DDL SQL statements), or at least explains information that is important but not necessarily obvious (and example of this last case would be naming the relationships--they do not translate into SQL, but they are very useful for understanding the ERD). Here is a sample ERD for the sake of discussion (modified from another StackOverflow question):

I have considered this a lot, and to me, the only information that solid versus dashed lines add is already adequately conveyed in the following conventions:

• Whether or not an FK is part of an entity's PK (PK,FK1 or PK,FK2 in the sample ERD).
• Whether or not the FK is a required attribute (bold) or optional attribute (not bold).

As far as I can see, the solid versus dashed relationship line adds no additional useful information. Rather than adding information, this convention is non-intuitive and is very confusing. As just one example of the confusion they cause, there are many duplicate questions here on StackOverflow that ask which is which; here are just a few examples:

• How to identify a strong vs weak relationship on ERD?
• What's the difference between identifying and non-identifying relationships?
• Still Confused About Identifying vs. Non-Identifying Relationships
• Identifying vs Non-Identifying Relationships (Again!!!)

Can anyone explain to me what additional information that convention adds that is not contained in the fact that an FK might or might not be part of a PK? I am seriously considering just ignoring the convention completely (that is, I want to start drawing my ERDs with all solid lines), but I would really appreciate it if someone could point out something important that I'm overlooking.

Answer 1

A convention used in ER model diagrams is that referencing (foreign key) attributes are not shown at all unless they are part of a primary key. If referencing attributes are required they are supposed to be implied by the existence of a relationship line. Accordingly, there is no standard or generally agreed ER notation for foreign key attributes even when they are part of a primary key. The case where referencing attributes are needed in order to identify instances of an entity is often called out on ER diagrams by using a dotted relationship line. The motivation here is presumably that "primary" key attributes are deemed to be mandatory and significant so their dependence on other things is also significant.

If your diagram shows foreign key attributes in some other way then the distinction between identfiying/non-identifying relationships is unimportant in my view. Whatever notation you use, ultimately what matters is that your audience understands your diagram correctly.