Is a unary/recursive relationship strong/identifying or weak/non-identifying?

Question

First, some definitions to make sure that the terminology I'm using is clear:

1. Strong and weak entities and strong/identifying and weak/non-identifying relationships: 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 (that is, an entity that contains the primary key [PK] of its related entity as a component of its own component primary key), and is indicated by a solid line.

   For example, consider this diagram (borrowed from another post):

The relationship between Course (strong entity) and Class (weak entity) is a strong relationship (solid line) because Class contains Course's PK (*CID) as part of its own PK (*CID,*Date). In contrast, the relationship between Room (strong entity) and Class (even though it is a weak entity) is weak because Room's PK (*RID) is not part of Class's PK.

2. Unary/recursive relationship: Most relationships are binary, in that they connect two separate entities. For example, the relationships between Course and Class, and between Room and Class, are binary relationships. Rarely, you have a unary (also called recursive) relationship when an entity has a relationship with itself. In the diagram, the only unary relationship is the one with the Employee entity. It should be labelled "manages", because it represents the fact that one Employee might manage 0 to many Employees; and every Employee is managed by 1 and only 1 Employee. The PK of Employee is *EmpID, and the foreign key (FK) that links the relationship is Manager.

So, here's my question: Is a unary relationship strong/identifying or weak/non-identifying? The PK of the one side (Employee, *EmpID) is not only part of, but is the full constituent of the PK on the many side (again, Employee, *EmpID). So, that would indicate that it should be a strong relationship, with a solid line, contrary to what is depicted in the sample diagram. Could anyone please clarify this for me?

Answer 1

I'm not totally sure where your definition of "strong" vs. "weak" originates from (this may be a language problem), but as far as I can see it can be thought of as this: Do the two related entities continue to exist if the other one ceases to exist or if they lose their relationship. In your example, a Class cannot exist when the Course is scrapped. This can be expressed through one table's PK containing the others, but that is not necessarily the case. Class could have (for totally different reasons) its own id as PK and use the CID only as FK. That would not change the factual relationship of those two entities.

On the other hand, if you have something like Cars and Drivers, they will have a weak link. A deleted (dead) driver will not suddenly cause their car to vanish. Likewise a car getting stolen will not usually cause an immediate heart attack of its driver. This is a "weak" link. The two things can continue to exist even if the other one is gone.

In your case with Employees, the two people will continue to exist even if they lose their relationship or if the other entity is gone. Hence it is a weak link. Also, to stick with your definition based on what is the PK, Manager is a FK into Employee and usually is different from and no part of its PK, since it is rare to find anyone being their own manager in a corporate hierarchy.

Answer 2

Weak/Strong Relationships: A strong relationship just means that the dependent entity cannot exist apart from the relationship. Take Class, Course and Room, for example. Imagine the following conversation:

"I think I'll teach a class this September."
"Good. What course will you teach?"
"I haven't decided yet."

Well, until this instructor decides on a course, there really cannot be a class. Since a course must be specified before the class is created, the relationship is a strong one. Also, when considering which class to take, a class in "Bead Rendering" and a class in "Cybercrafting" are two completely different things even though they may both meet in the same room at the same time (just on different days). The identity of each class is inexorably bound to a course. So this relationship is also identifying.

"I think I'll reach Discretionary Logic this September."
"Good. What room will it be in?"
"I haven't decided yet."

The class can still exist even though is has not been assigned a room. Yes, a room will have to be assigned before the semester starts, but at the moment we can still create the class, put "TBD" in the catalog and allow students to enroll. The class can exist without a room (for a while, anyway) so the relationship is weak. Also, two classes in "Discretionary Logic" are functionally equivalent, even though they are taught in different rooms. The relationship with the room has nothing to do with the type of class. The relationship is non-identifying.

So if students had signed up to take Bead Rendering in room 17 were notified that the room had changed to 12, they would not think, "This is a completely different class!" No, the class is the same, only the location is different. However, if they were told the class was now "Second-hand Carnival Staffing" then they would be right. This is now a completely different class. This is the difference between identifying and non-identifying relationships.

Unary/Recursive Relationships: It's important to realize that all relationships consist of at least two entities. In this way a database relationship is similar to a human relationship -- it takes two to Tango. The "unary" just means that both sides of the relationship are filled by the same logical entity.

It is easy to see that a "meets in" relationship between a Class entity and a Room entity cannot be satisfied between, say, two Class entities or two Room entities. However, a "is managed by" relationship requires an Employee entity on both sides. It should also be obvious that an employee does not require this relationship in order to exist. Maybe the employee is a new hire and has not yet been assigned a manager. Maybe the employee is the Lead Dog in this particular organization and no other employee is worthy to fit that bill.

Or if Pete, who was managed by Carol, is now managed by Sarah, the nature of Pete has not changed. Just go ask him.

So this unary relationship is weak/non-identifying. It is also recursive in that Pete may be managed by Carol who is managed by Sam who is ... well, you get the idea.

Unary relationships tend to also be recursive, though this is more an effect of the design rather than a requirement of the relationship. For example, the relationship "is married to" would be unary, but not recursive. If implemented in a way that recursion was possible, care would have to be taken to prevent it -- or there could be some awkward moments among the workforce.

Notice I have not mentioned "primary key" or "foreign key" anywhere. These are implementation details, not characteristics of the types of relationship. One can fully understand the concepts of relationships without using or even considering those terms.

---

Having said all that, it should be pointed out that Identifying and Non-Identifying, if not completely subjective terms, are sensitive to context. For example, it is perfectly reasonable for a college to schedule more than one class of the same course during the same semester. So there could be an "Algebra 2" class in room 3 and a different "Algebra 2" class in room 7 and yet another in room 12. This considerably strengthens the relationship between Class and Room. Now the statement "I am taking Algebra 2" is insufficient information to identify which of the three classes you are enrolled.

Add to this the fact that a fourth "Algebra 2" class could also be held in the same room as one of the others, just at a different time or day.

So an initial design using a weak relationship might work just fine in some contexts (small school that held only one class of any course during a semester) but would have to be made into a strong relationship in a different context (larger school that offered or may offer multiple classes of the same course in the same semester). So this is not intrinsic to the types of entities. It cannot be determined ahead of time just by looking at an ER diagram.

Answer 3

Based on my rethinking of the question especially from @TommCatt's responses, it seems that my confusion might stem from my defective definition of a strong/identifying relationship: "A strong/identifying relationship is one that connects a strong entity to a weak entity (that is, an entity that contains the primary key [PK] of its related entity as a component of its own primary key), and is indicated by a solid line."

The defective part of the definition is "an entity that contains the primary key [PK] of its related entity as a component of its own component". More accurately, I should have said, "an entity that contains the foreign key [FK] from its related entity as a component of its own primary key [PK]".

From that perspective, then it is clear why a unary relationship is not strong: the FK from the unary relationship is not part of the PK; thus, the relationship is weak, and is represented with a dashed line.