Enhanced Entity Relationship Diagram

Enhanced entity relationship diagram

An enhanced entity-relationship diagram, or EERD, is a specialized model that deviates from traditional ERDs. It uses several concepts that are closely related to object-oriented design and programming.

For streamlined EERD creation, Lucidchart is the perfect choice. Drag and drop symbols, add connectors, and publish your work with the click of a button.

Try it now
Sign up free

What is an Enhanced ERD?

An enhanced entity-relationship model, also known as an extended entity-relationship model, is a type of database diagram that's similar to regular ERDs. Enhanced ERDs are high-level conceptual models that accurately represent the requirements of complex databases.

Enhanced ERDs include the same concepts that ordinary ER diagrams encompass. In addition, EERDs include:

  • Subtypes and supertypes (sometimes known as subclasses and superclasses)
  • Specialization or generalization
  • Category or union type
  • Attribute and relationship inheritance

Enhanced ERD Definitions and Examples

The modeling concepts of EERDs differ somewhat from those of ERDs. See the list below for definitions of concepts that are unique to enhanced entity-relationship diagrams. Before you dive in, be sure to review our ER diagram tutorial, including this comprehensive look at ER diagram symbols. When you fully understand ERD structure, you're ready to acquaint yourself with enhanced entity-relationship diagrams.


  • Supertype - an entity type that has a relationship with one or more subtypes.
  • Subtype - a subgroup of entities with unique attributes.
  • Inheritance - the idea that subtype entities inherit the values of all supertype attributes. Remember than a subtype instance is also classified as a supertype instance.


  • Generalization - the process of defining a general entity type from a collection of specialized entity types.
  • Specialization - the inverse of generalization, since it defines subtypes of the supertype and forms relationships between supertype and subtupe.
  • Inheritance - the idea that subtype entities inherit the values of all supertype attributes. Remember than a subtype instance is also classified as a supertype instance.


  • Disjointness constraints - decide whether a supertype instance may simultaneously be a member of two or more subtypes. The disjoint rule forces subclasses to have disjoint sets of entities. The overlap rule forces a subclass (also known as a supertype instance) to have overlapping sets of entities.
  • Completeness constraints - decide whether a supertype instance must also be a member of at least one subtype. The total specialization rule demands that every entity in the supclass belong to some subclass. Just as with a regular ERD, total specialization is symbolized with a double line connection between entities. The partial specialization rule allows an entity to not belong to any of the subclasses. It is represented with a single line connection.


A subtype discriminator is an attribute of the supertype that indicates an entity's subtype The attribute's values are what determine the target subtype.

  • Disjoint subtypes - simple attributes that must have alternative values to indicate any possible subtypes.
  • Overlapping subtypes - composite attributes whose subparts pertain to various subtypes. Each subpart has a Boolean value that indicates whether or not the instance belongs to the associated subtype.

How to Create an Effective EERD

Just like entity-relationship diagrams, a well-designed EERD will help you build storage systems that are long-lasting and useful. When evaluating the effectiveness of an entity relationship diagram, be sure that you’re modeling a system design that will meet important business requirements. Possible considerations are:

  • Stability - will the diagram support business needs that change over time?
  • Breadth - can this diagram accommodate all of the data we need to store?
  • Flexibility - can data in this model be re-allocated to support additional information requirements?
  • Efficiency - does this model represent the simplest solution? Is data modeled with the appropriate symbols?
  • Accessibility - can both creators and end users of the ERD easily understand it?
  • Conformity - will the design integrate seamlessly with any existing database structure?

To make your own enhanced entity relationship diagram, try Lucidchart. Diagrams built with our app are customizable, collaborative, and interactive. With online access from any device or location, what more could you need?

Try it now
Sign up free