Enhanced Entity-Relationship

(EER) Modeling

August 20, 2024

EER Modeling
◼ EER stands for Enhanced ER or Extended ER
◼ EER model created to design more accurate schemas
◼ Includes some object-oriented concepts, such as inheritance
◼ More complex requirements than traditional applications
◼ EER Model Concepts
◼ Includes all modeling concepts of basic ER
◼ Additional concepts:
◼ subclasses/superclasses
◼ specialization/generalization
◼ categories (UNION types)
◼ attribute and relationship inheritance
◼ These are fundamental to conceptual modeling
Subclasses and Superclasses (1)
◼ An entity type may have additional meaningful subgroupings
of its entities
◼ Example: EMPLOYEE may be further grouped into:
◼ SECRETARY, ENGINEER, TECHNICIAN, …
◼ Based on the EMPLOYEE’s Job
◼ MANAGER
◼ EMPLOYEEs who are managers
◼ SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
◼ Based on the EMPLOYEE’s method of pay

◼ EER diagrams extend ER diagrams to represent these

additional subgroupings, called subclasses or subtypes
Subclasses and Superclasses (2)

◼ EMPLOYEE is
the superclass
for each of these
subclasses

◼ These are also

called IS-A
relationships
◼ Each of these subgroupings is ◼ SECRETARY IS-A
◼ a subset of EMPLOYEE entities EMPLOYEE,
◼ TECHNICIAN IS-A
◼ called a subclass of EMPLOYEE EMPLOYEE, …
Subclasses and Superclasses (3)
◼ Subclass member is the same entity in a distinct specific role
◼ An entity cannot exist in the database merely by being a
member of a subclass; it must also be a member of the
superclass
◼ A member of the superclass can be optionally included as a
member of any number of its subclasses
◼ Examples:
◼ A salaried employee who is also an engineer belongs to the two
subclasses:
◼ ENGINEER and SALARIED_EMPLOYEE

◼ A salaried employee who is also an engineering manager belongs

to the three subclasses:
◼ MANAGER, ENGINEER, and SALARIED_EMPLOYEE

◼ It is not necessary that every entity in a superclass be a member

of some subclass
Representing Specialization in EER Diagrams

◼ Type inheritance
◼ Subclass entity inherits all attributes and relationships of
superclass
◼ Example:
◼ SECRETARY (as well as TECHNICIAN and ENGINEER) inherit the
attributes Name, SSN, …, from EMPLOYEE
◼ Every SECRETARY entity will have values for the inherited attributes
 Specialization (1)
◼ Process of defining a set of
subclasses of a superclass Job type
◼ Defined on the basis of some
distinguishing characteristic of the
entities in the superclass
◼ {SECRETARY, ENGINEER,
TECHNICIAN} is a specialization of
EMPLOYEE based upon job type.
◼ May have several specializations of
the same superclass
◼ Another specialization of
EMPLOYEE based on method of
pay is {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}.
Specialization (2)

◼ Attributes of a subclass are called specific or local attributes.

◼ The attribute TypingSpeed of SECRETARY

◼ Subclass can also participate in specific relationship types.

◼ A relationship BELONGS_TO of HOURLY_EMPLOYEE
Generalization (1)
◼ The reverse of the specialization process
◼ Several classes with common features are generalized
into a superclass;
◼ Original classes become its subclasses

◼ Example: CAR, TRUCK generalized into VEHICLE;

◼ Both CAR, TRUCK become subclasses of the
superclass VEHICLE.
◼ We can view {CAR, TRUCK} as a specialization of
VEHICLE
◼ Alternatively, we can view VEHICLE as a generalization
of CAR and TRUCK
Generalization (2)
 Generalization and Specialization
◼ Data Modeling with Specialization and Generalization
◼ A superclass or subclass represents a collection
(or set or grouping) of entities
◼ It also represents a particular type of entity
◼ Shown in rectangles in EER diagrams
(as are entity types)
◼ We can call all entity types (and their corresponding
collections) classes, whether they are entity types,
superclasses, or subclasses
Generalization and Specialization
Constraints on Specialization and
Generalization (1)
◼ Predicate-defined (or condition-defined) specialization
◼ If all subclasses in a specialization have membership
condition on same attribute of the superclass
◼ Display it by writing the predicate condition next to the
line attaching the subclass to its superclass
◼ JobType is the defining attribute of the specialization
{SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE
◼ User-defined specialization
◼ If no condition determines membership
◼ Membership in the subclass is specified individually by
the database users by applying an operation to add an
entity to the subclass
Displaying an attribute-defined
specialization in EER diagrams
Constraints on Specialization and
Generalization (2)

◼ Two basic constraints can be applied to a

specialization/generalization:
◼ Disjointness Constraint
◼ Completeness (or totalness) Constraint

◼ Disjointness and completeness constraints are

independent
Constraints on Specialization and
Generalization (3)
◼ Disjointness Constraint:
◼ Specifies that the subclasses of the specialization
must be disjoint:
◼ An entity can be a member of at most one of the
subclasses of the specialization
◼ Specified by d in EER diagram
◼ If not disjoint, specialization is overlapping:
◼ That is the same entity may be a member of more
than one subclass of the specialization
◼ Specified by o in EER diagram
Constraints on Specialization and
Generalization (4)
◼ Completeness Constraint:
◼ Total specifies that every entity in the superclass
must be a member of some subclass in the
specialization/generalization
◼ Shown in EER diagrams by a double line
◼ Partial allows an entity not to belong to any of the
subclasses
◼ Shown in EER diagrams by a single line
◼ Can also be shown with (min, max) pair
Constraints on Specialization and
Generalization (5)
◼ Four types of specialization /generalization:
◼ Disjoint, total
◼ Disjoint, partial
◼ Overlapping, total
◼ Overlapping, partial

◼ Note: Generalization usually is total because the

superclass is derived from the subclasses.
Example of disjoint partial Specialization
Example of overlapping total Specialization
Specialization/Generalization Hierarchies
and Lattices (1)
◼ A subclass may itself have further subclasses
specified on it
◼ Forms a hierarchy or a lattice

▪ Specialization hierarchy (single inheritance)

▪ Every subclass participates as a subclass in
only one class/subclass relationship
▪ Results in a tree structure or strict hierarchy

▪ Specialization lattice (multiple inheritance)

▪ Subclass can be a subclass in more than one
class/subclass relationship
Shared Subclass “Engineering_Manager”

◼ In a lattice or hierarchy, a subclass inherits attributes not

only of its direct superclass, but also of all its predecessor
superclasses
◼ A subclass with more than one superclass is called a
shared subclass (multiple inheritance)
 Specialization/Generalization Hierarchies
and Lattices (3)
◼ Depending on how they were derived, one can have:
◼ Specialization hierarchies or lattices, or

◼ Generalization hierarchies or lattices

◼ In specialization, start with an entity type and define

subclasses of the entity type by successive specialization
◼ Called a top down conceptual refinement process

◼ In generalization, start with many entity types and

generalize those that have common properties
◼ Called a bottom up conceptual synthesis process

◼ In practice, a combination of both processes is usually

employed
Specialization / Generalization Lattice
Example (UNIVERSITY)
Modeling of UNION Types Using
Categories (1)
◼ Union type or a category
◼ Need to model a single superclass/subclass
relationship with more than one superclass
◼ Subclass represents a collection of objects that is
a subset of the UNION of distinct entity types
◼ Such a subclass is a category or UNION TYPE
◼ Attribute inheritance works more selectively
◼ Category can be total or partial
◼ Some modeling methodologies do not have union
types
Categories (UNION TYPES) (2)
◼ Example: In a database for vehicle registration, a
vehicle owner can be a PERSON, a BANK (holding
a lien on a vehicle) or a COMPANY.
◼ A category (UNION type) called OWNER is created
to represent a subset of the union of the three
superclasses COMPANY, BANK, and PERSON
◼ A category member must exist in at least one of its
superclasses
◼ Difference from shared subclass, which is a:
◼ Subset of the intersection of its superclasses
◼ Shared subclass member must exist in all of its
superclasses
Two categories (UNION types):
OWNER, REGISTERED_VEHICLE
 Design Choices for
Specialization/Generalization
▪ Many specializations and subclasses can be defined to make
the conceptual model accurate
▪ If a subclass has few specific attributes and no specific
relationships - Can be merged into the superclass
▪ If all the subclasses of a specialization/ generalization have few
specific attributes and no specific relationships
▪ Can be merged into the superclass
▪ Replace with one or more type attributes that specify the
subclass or subclasses that each entity belongs to
▪ Union types and categories should generally be avoided
▪ Choice of disjoint/overlapping and total/partial constraints on
specialization/generalization - Driven by rules in the miniworld
being modeled