Aggregation

Definition

Aggregation is an EER modeling concept that allows an entire relationship (together with the entity sets it connects) to be treated as a higher-level entity, so that this combined "relationship-as-entity" can itself participate in further relationships with other entity sets. It solves the problem of a relationship needing to relate to yet another entity set, which the basic ER model cannot express directly (a relationship diamond normally cannot connect to another relationship diamond).

Worked Example

Consider the relationship Enrolls_In connecting Student and Course. Now suppose the college wants to record which Faculty member approved/monitored each specific enrollment (perhaps for scholarship audits) — this requires relating a Faculty entity to the combination of (a specific Student enrolled in a specific Course), not to Student or Course individually. Aggregation lets the designer draw a boundary box around the Student–Enrolls_In–Course relationship, treat that whole boundary as one aggregate "black box" entity, and connect a new relationship (e.g., Monitored_By) from that aggregate to Faculty.

Edge Cases

• Aggregation is conceptually and notationally entirely different from generalization/specialization (6.17/6.18): generalization/specialization is about ISA hierarchies among similar entity sets sharing attributes; aggregation is about elevating a dissimilar relationship into an entity-like unit so it can connect further. Confusing the two is a very common exam mistake — remember: generalization/specialization = "is-a," aggregation = "relationship treated as a thing."
• Without aggregation, a common but semantically incorrect workaround is to try connecting Faculty directly to BOTH Student and Course separately with a ternary relationship — but that would suggest Faculty relates to any Student and any Course independently, not specifically to a particular enrollment pairing, losing the intended meaning.
• Aggregation is drawn in an EER diagram literally as a dashed rectangle/boundary enclosing the original entity sets and relationship diamond, with the new relationship line originating from that boundary.
• In ER-to-relational mapping, an aggregation is typically implemented by having the resulting MonitoredBy-type relationship reference the primary key of the junction table that already represents EnrollsIn (i.e., the Enrollment table's own composite/surrogate key), effectively treating that table's rows as first-class referenceable entities.

Key Takeaways / Interview Q&A

Q: In one sentence, what problem does aggregation solve? A: It lets a relationship (plus its connected entities) be treated as a single higher-level entity so that a third entity set can relate specifically to instances of that relationship, not to the individual entities separately.

Q: How is aggregation different from a plain ternary relationship achieving a similar-looking result? A: A ternary relationship directly connects three entity sets as equal participants in one single association; aggregation specifically preserves and reuses an EXISTING binary relationship as a unit, then adds a separate new relationship on top of that unit to a third entity set — appropriate when the binary relationship (like Enrolls_In) has independent meaning of its own. Q: Is aggregation the same as generalization? A: No — they are unrelated EER constructs solving different problems: aggregation elevates a relationship to an entity-like unit; generalization/specialization builds superclass/subclass (ISA) hierarchies from shared attributes.