Enhanced entity-relationship diagrams, or EERDs, are specialized ER Diagrams that can be extremely useful for modeling your database. EERDs use several concepts that are closely related to object-oriented design and programming.
3 minute read
Want to make an ERD of your own? Try Lucidchart. It's quick, easy, and completely free.
What is an Enhanced ER Diagram?
Enhanced entity-relationship models, also known as extended entity-relationship models, are advanced database diagrams very similar to regular ER diagrams. Enhanced ERDs are high-level models that represent the requirements and complexities of complex databases.
In addition to the same concepts that ordinary ER diagrams encompass, EERDs include:
-
Subtypes and supertypes (sometimes known as subclasses and superclasses)
-
Specialization and generalization
-
Category or union type
-
Attribute and relationship inheritance
Want to make an ERD of your own? Try Lucidchart. It's quick, easy, and completely free.
Make an ERDEnhanced ERD Definitions and Examples
The definitions of concepts listed below are unique to enhanced entity-relationship diagrams and can help to understand how the modeling concepts of EERDs differ from those of ERDs. If you need to brush up on the basic concepts of ERDs, check out our ER diagram tutorial, including this guide to the basic ER diagram symbols. As soon as you fully understand ERD structure, you’re ready to learn how to create enhanced ER diagrams.
Supertypes and Subtypes
-
Supertype - an entity type that relates to one or more subtypes.
-
Subtype - a subgroup of entities with unique attributes.
-
Inheritance - the concept that subtype entities inherit the values of all supertype attributes.
Note: subtype instances are also classified as supertype instances.
Generalization & Specialization
-
Generalization - the process of defining a general entity type from a collection of specialized entity types.
-
Specialization - the opposite of generalization, since it defines subtypes of the supertype and determines the relationship between the two.
Constraints
-
Disjointness constraints - You will need to 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 superclass 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.
Subtype Discriminators
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.
Creating an Effective EERD
A well-designed EERD will help you build storage systems that are long-lasting and useful. Consider the following when evaluating your entity relationship diagram to be sure that you’re modeling a system design that will meet the requirements of your business:
-
Stability:
Will the diagram support changing business needs? -
Breadth:
Can all of the data that we need to store be organized in the model? -
Flexibility:
Can data in this model be re-organized to support new information requirements? -
Efficiency:
Is this model the simplest solution possible? Is the data modeled with the appropriate symbols? -
Accessibility:
Can both creators and end users easily understand your EERD? -
Conformity:
Will the model integrate easily with your existing database structure?