Generalization & Aggregation

Plain entities and relationships can't capture every structure. The extended ER model adds two tools. Generalization pulls the features many entity types share up into one general superclass; its subclasses inherit those features and add their own, joined by an ISA ('is a') link. Aggregation treats an entire relationship — together with the entities it connects — as a single higher-level entity, so another relationship can attach to it.

Generalization vs specialization — same picture, two directions

1. 1Generalization is *bottom-up*: you notice Student and Employee both have name and address, so you gather those shared features into a superclass Person.
2. 2Specialization is *top-down*: you start with Person and split it into more specific sub-types Student and Employee.
3. 3Either way the result is the same ISA hierarchy, and inheritance means each subclass automatically has all of the superclass's attributes without restating them.

Turning an ISA hierarchy into tables

One common mapping keeps the superclass as its own table and gives each subclass a table whose primary key is *also* a foreign key back to the superclass — so the subclass row and its parent row share the same identifier.

CREATE TABLE Person (
  person_id INT PRIMARY KEY,
  name      VARCHAR(60)
);
CREATE TABLE Student (
  person_id INT PRIMARY KEY REFERENCES Person(person_id), -- key AND foreign key
  gpa       DECIMAL(3,2)
);
CREATE TABLE Employee (
  person_id INT PRIMARY KEY REFERENCES Person(person_id),
  salary    INT
);

Aggregation — a relationship as an entity

Suppose Employee works-on Project (a relationship). Now you want to record that a Manager monitors that whole working-on arrangement — not just an employee, and not just a project, but the *pairing*. Aggregation lets you box the works-on relationship into a single abstract entity that the monitors relationship can point at.