EER Diagram

Definition

An EER (Enhanced Entity-Relationship) Diagram is the extended visual notation that includes all the basic ER model constructs (entities, attributes, relationships, cardinality, participation) PLUS the additional advanced modeling constructs introduced for handling more complex real-world requirements: generalization, specialization, and aggregation — together with their associated constraints (disjoint/overlapping, total/partial).

Worked Example

A full EER diagram for the college database would show: Student, Course, Department, Faculty as basic rectangles with their attributes; Enrolls_In, Offers, Belongs_To as relationship diamonds with cardinality/participation lines; a Person superclass specialized (top-down, or equivalently generalized bottom-up) into Student and Employee subclasses via an ISA triangle, marked partial+overlapping; Employee further specialized into Teaching_Staff/Non_Teaching_Staff; and an aggregation boundary box around Student–Enrolls_In–Course, connected via Monitored_By to Faculty. All of this combined — basic ER plus these EER extensions — constitutes the EER diagram.

Edge Cases

• A plain ER diagram (using only entities, attributes, and relationships) is technically a subset of what an EER diagram can express — every ER diagram is trivially also a valid (if simple) EER diagram, but not every EER diagram can be redrawn as a plain ER diagram without losing information, specifically when ISA hierarchies or aggregation are essential to the model's meaning.
• The presence of even one ISA triangle (generalization/specialization) or one aggregation boundary is what technically elevates a diagram from "ER diagram" to "EER diagram" in strict terminology — though in casual usage, people often say "ER diagram" loosely to mean either.
• An EER diagram, like a plain ER diagram, is a conceptual/logical design tool — it precedes and informs the ER-to-relational mapping step (6.21), but is not itself a physical database schema.
• A common mistake is treating "EER diagram" as an entirely separate technique from "ER diagram" rather than as a strict superset/extension — every EER construct not involving generalization/specialization/aggregation is drawn identically to plain ER notation.

Key Takeaways / Interview Q&A

Q: What three additional constructs does an EER diagram add beyond a basic ER diagram? A: Generalization, specialization, and aggregation (along with their disjoint/overlapping and total/partial constraints) — everything else (entities, attributes, relationships, cardinality, participation) is shared with plain ER diagrams.

Q: Is every ER diagram also technically an EER diagram? A: Yes — a plain ER diagram with no ISA hierarchies or aggregation is simply an EER diagram that happens not to use the extended constructs; the reverse is not always true.

Q: What comes immediately after building an EER diagram in the database design process? A: The EER diagram is converted into a relational schema (tables, keys, constraints) via ER-to-relational mapping (topic 6.21), including special rules for mapping ISA hierarchies and aggregated relationships.