Skip to main content

Aggregation

Aggregation is an abstract relationship used when we need to represent a relationship between a relationship and an entity.

  • In simple words: when a relationship itself needs to participate in another relationship, we use aggregation.
  • It is sometimes called a “has-a” or “part-of” relationship.
  • Graphically, in ER diagrams, an aggregation is represented by a rectangle (entity) connected to a diamond (relationship) enclosed in another rectangle.

Why Aggregation is Needed?​

Normally, ER diagrams allow:

  • Entity ↔ Entity relationships.

But what if we need:

  • Entity ↔ Relationship relationships?

For example, a relationship (say “Works_On”) itself needs to connect with another entity (say Project_Manager). In such cases, normal ER model is insufficient, so aggregation comes into play.

Example of Aggregation​

  • Entities:
    • Employee (Emp_ID, name)
    • Project (Proj_ID, Title)
    • Department (Dept_ID, Dept_Name)
  • Relationship:
    • Works_On (Employee ↔ Project)

Now, suppose we want to represent: A department controls the “Works_On” relationship between employee and project.

This means:

  • A department doesn’t directly control a project or an employee individually.
  • Instead, it controls the association of an employee working on a project.

Here’s where aggregation is needed:

  • We treat the relationship Works_On as an abstract entity, and then relate it with Department using another relationship (say, Controls).

ER Representation (textual)

 Employee -------- Works_On -------- Project
                        |
                        |
                  [Aggregation]
                        |
                  Controls (by)
                        |
                   Department
  • Works_On (relationship) is aggregated and treated like an entity.
  • Then Controls relates Department to this aggregated relationship.

Key Characteristics of Aggregation​

  1. Represents higher-level abstraction (relationship of relationship).
  2. Avoids redundancy – instead of connecting department separately to employee and project, we connect it to their association.
  3. Expresses real-world semantics more naturally.