Enhanced Entity Relationship

Enhanced Entity-Relationship Modeling

Enhanced Entity-Relationship (EER) modeling is an extension of ER modeling to include object-oriented concepts such as:

  • superclasses and subclasses
  • specialization and generalization
  • aggregation and composition

These modeling constructs may allow more precise modeling of systems that are object-oriented in nature such as:

  • CAD/CAM systems (Computer-Aided Design/Manufacturing)
  • GIS (Geographical Information Systems)

Super classes and Subclasses

The object-oriented ideas of inheritance and superclasses and subclasses are taught during programming in an OO language such as Java.

A superclass is a general class that is extended by one or more subclasses.

A subclass is a more specific class that extends a superclass by inheriting its methods and attributes and then adding its own methods and attributes.

Inheritance is the process of a subclass inheriting all the methods and attributes of a superclass.

When to use EER Modeling?

It is important to emphasize that many database projects do not need the object-oriented modeling features of EER modeling.

Remember the goal of conceptual modeling is to produce a model that is simple and easy to understand.

Do not introduce complicated subclass/superclass relationships if they are not needed.

Only use the EER modeling constructs if they offer a significant advantage over regular ER modeling.

EER modeling is especially useful when the domain being modeled is object-oriented in nature and the use of inheritance reduces the complexity of the design.

There are two common cases where EER modeling is useful instead of basic ER modeling:

  • 1) When using attribute inheritance can reduce the use of nulls in a single entity relation (that contains multiple subclasses).
  • 2) Subclasses can be used to explicitly model and name subsets of entity types that participate in their own relationships.

When to use EER Modeling? Using Attribute Inheritance

Note that the title attribute indicates what job the employee does at the company. Consider if each job title had its own unique information that we would want to record such as:

  • EE, PR – programming language used (lang), DB used (db)
  • SA, ME – MBA? (MBA), bonus

We could represent all these attributes in a single relation:

Note the wasted space as attributes that do not apply to a particular subclass are NULL.

Generalization and Specialization

Subclasses and superclasses are created by using either generalization or specialization.

Specialization is the process of creating more specialized subclasses of an existing superclass.

  • Top-down process: Start with a general class and then subdivide it into more specialized classes. The specialized classes may contain their own attributes. Attributes common to all subclasses remain in the superclass.

Generalization is the process of creating a more general superclass from existing subclasses. Bottom-up process: Start with specialized classes and try to determine a general class that contains the attributes common to all of them.

Constraints on Generalization and Specialization

There are two types of constraints associated with generalization and specialization:

  • Participation constraint – determines if every member in a superclass must participate as a member of one of its subclasses.
  • It may be optional for a superclass member to be a member of one of its subclasses, or it may be mandatory that a superclass member be a member of one of its subclasses.
  • Disjoint constraint – determines if a member of a superclass can be a member of one or more than one of its subclasses.
  • If a superclass object may be a member of only one of its subclasses this is denoted by OR (subclasses are disjoint).
  • Otherwise, AND is used to indicate that it may be in more than one of its subclasses.

General Predicate Constraints

Predicate-defined constraints specify when an object participates in a subclass using a certain rule.

  • For example, a subclass called RichEmployees can be defined with a membership predicate such as salary >100000.

Attribute-defined subclasses are a particular type of predicate-defined constraint where the value of an attribute(s) determines if an object is a member of a subclass.

  • For example, the title field could be used as a defining attribute for the Developer and Manager subclasses.
  1. Emp is in Developer if title = ‘EE’ or ‘PR’
  2. Emp is in Manager if title = ‘ME’ or ‘SA’

Relationship Constraints vs. Inheritance Constraints

There is a parallel between relationship constraints on associations/relationships and inheritance constraints on superclasses and subclasses.

  • Minimum # of occurrences – called participation constraint in both cases
  • Maximum # of occurrences – called cardinality constraint for relationships and disjoint constraint for subclasses

Multiple Inheritance

If each class only has one superclass, then the class diagram is said to be a specialization or type hierarchy.

If a class may have more than one superclass, then the class diagram is said to be a specialization or type lattice.

Although multiple inheritance is powerful, it should be avoided if possible.


Aggregation represents a ‘HAS-A’ or ‘IS-PART-OF’ relationship between entity types. One entity type is the whole, the other is the part.


Composition is a stronger form of aggregation where the part cannot exist without its containing whole entity type and the part can only be part of one entity type.


The Enhanced Entity-Relationship model (EER) model allows for object-oriented design features to be captured.

Generalization and specialization are two complementary processes for constructing superclasses and subclasses.

Participation and disjoint constraints apply to subclasses.

  • Participation of a superclass may be mandatory or optional

in a subclass.

  • A superclass may only be a member of one subclass (disjoint constraint indicated by OR) or multiple (indicated by AND).

Aggregation and composition are used to model HAS-A or

PART-OF relationships.

The features of EER modeling are rarely needed in most database design projects.

+ posts