Aggregation vs Ternary relationship - When to use?

Question

I am reading a book about database systems and in the chapter covering database design using ER, the author aims to explain when to use aggregation versus ternary relationship. In short, each Project entity is sponsored by one or more Department entities and each Department can sponsor zero, one or more Projects. Each Sponsorship relationship has a Monitors relationship, which connects Employees with Sponsorship.

This can be expressed in 2 ER diagrams:

Now, we want to express an additional constraint that each Sponsorship relationship is monitored by at most one Employee.The author states that this cannot be done with ternary relationship. I can't wrap my head around why. To express this in diagrams, I would just point an arrow from Sponsors2 to Emplyees in ternary relation. Does this not satisfy the additional constraint?

Answer 1

The issue is that we attempt to mix a key constraint ("each Sponsorship relationship is monitored by at most one Employee) with a participation constraint ("each project must be sponsored by at least one department," indicated by the bold line).

In a ternary relationship, we would be trying to impose a total participation of the Project entity set, while also trying to impose a one-to-many relationship between Employees and (Project,Department) tuples. The ER diagram is not equipped to handle this in a ternary relationship -- how would it know whether the one-to-many relationship was between Employees and Projects, Employees and Departments, or Employees and (Project,Department) tuples?

Note that, for any entity in an n-ary relationship, you are allowed to force a unique (one-to-one or many-to-one) key constraint between said entity and all other entities in the relationship (indicated by an arrow), or force a participation constraint (indicated by a bolded line). One-to-one or many-to-one relationships in a ternary (or higher-degree) relationship between one entity and the rest of the entities in the relationship are unambiguous -- these are akin to adding a UNIQUE constraint in a table -- but one-to-many or many-to-many relationships are not and must be modeled with an aggregate relationship.