CE 301T
CHAPTER 4
Enhanced Entity-Relationship (ER) Mod
Dr. Najma Ismat
nismat@[Link]
Computer Engineering Departme
Chapter Outline
• EER stands for Enhanced ER or Extended ER
• EER Model Concepts
• Includes all modeling concepts of basic ER
• Additional concepts:
• subclasses/superclasses
• specialization/generalization
• categories (UNION types)
• attribute and relationship inheritance
• Constraints on Specialization/Generalization
• The additional EER concepts are used to model applications more
completely and more accurately
• EER includes some object-oriented concepts, such as inheritance
• Knowledge Representation and Ontology Concepts
Slide 1- 2
Overview of Database Design Process
Enhanced ER Model (EER Model)
• EER is a high-level data model that incorporates the extensions to the
original ER model.
• EER diagrams extend ER diagrams to represent these additional concepts:
• Sub Class and Super
• Specialization and Generalization
• Union or Category
• Aggregation
Slide 3- 3
Overview of Database Design Process
Subclasses and Superclasses
• 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 (the role they play)
• SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
• Based on the EMPLOYEE’s method of pay
• The set or collection of entities in each of the groupings mentioned above is a
subset of the entities that belong to the EMPLOYEE entity set, meaning that
every entity that is a member of one of these subgroupings is also an employee.
• Each of these subgroupings is called subclass or subtype
• EER diagrams extend ER diagrams to represent these additional subclasses or
subtypes
Slide 3- 4
Overview of Database Design Process
Subclasses and Superclasses
• The relationship between a superclass superclass
and any one of its subclasses a
superclass/subclass or supertype/subtype Employee
or simply a class/subclass relationship.
• Each of these subgroupings is a subset of
EMPLOYEE entities d
• Each is called a subclass of EMPLOYEE
• EMPLOYEE is the superclass for each of
these subclasses secretary engineer Manager
• These are called superclass/subclass
relationships:
• EMPLOYEE/SECRETARY
• EMPLOYEE/TECHNICIAN Subclasses
• EMPLOYEE/MANAGER
Slide 3- 5
Overview of Database
Design Process
Database Design Process Overview
Slide 3- 6
Subclasses and Superclasses
• These are also called IS-A relationships
• SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….
• Note: An entity that is member of a subclass represents the
same real-world entity as some member of the superclass:
• The 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
Slide 3- 7
Methodologies for Conceptual
Subclasses and Superclasses
Design
• 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
Slide 3- 8
Methodologies for Conceptual
Attribute Inheritance in Superclass /
Design Subclass Relationships
• An important concept associated with subclasses (subtypes) is
that of type inheritance.
• An entity in the subclass represents the same real-world entity
from the superclass, so it inherits the same attributes as well as
values of its attributes as a member of the superclass.
• The entity also inherits all the relationships in which the
superclass participates.
• All relationships of the entity as a member of the 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
Slide 3- 9
Methodologies for Conceptual
Specialization
Design
• Specialization is the process of defining a set of subclasses of a superclass
• The set of subclasses is based upon some distinguishing characteristics of the
entities in the superclass
• Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE
based upon job type.
• Example: MANAGER is a specialization of EMPLOYEE based on the role the
employee plays
• May have several specializations of the same superclass
• Example: Another specialization of EMPLOYEE based on the method of pay is
{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
• Superclass/subclass relationships and specialization can be diagrammatically
represented in EER diagrams
• Attributes of a subclass are called specific or local attributes.
• For example, the attribute TypingSpeed of SECRETARY
• The subclass can also participate in specific relationship types.
• For example, a relationship BELONGS_TO of HOURLY_EMPLOYEE
Slide 3- 10
Methodologies for Conceptual
Specialization
Design
• There are two main reasons for including class/subclass relationships and
specializations.
1. Certain attributes may apply to some but not all entities of the superclass entity
type.
2. The second reason for using subclasses is that some relationship types may be
participated in only by entities that are members of the subclass. For example, if
only HOURLY_EMPLOYEES
Slide 3- 11
[Link]
Methodologi
Specialization
es for
Conceptual
Design
Slide 3- 12
Methodologies for Conceptual
Generalization
Design
• Generalization is 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
Slide 3- 13
Methodologies for Conceptual
Generalization
Design
Slide 3- 14
Generalization and Specialization
• Diagrammatic notations are sometimes used to distinguish
between generalization and specialization
• Arrow pointing to the generalized superclass represents a
generalization
• Arrows pointing to the specialized subclasses represent a
specialization
• In general, a superclass or subclass represents a collection of
entities of the same type and hence also describes an entity
type; that is why superclasses and subclasses are all shown in
rectangles in EER diagrams, like entity types.
Methodologies for Conceptual
Types of Specialization
Design
1. Predicate-defined ( or condition-defined) : based on
some predicate. E.g., based on value of an attribute,
say, Job-type, or Age.
2. Attribute-defined: shows the name of the attribute
next to the line drawn from the superclass toward the
subclasses
3. User-defined: membership is defined by the user on an
entity by entity basis.
• Membership is specified individually for each entity by the
user, not by any condition that may be evaluated
automatically.
Methodologies forSpecialization
Constraints on Conceptualand
Design Generalization
• If we can determine exactly those entities that will become
members of each subclass by a condition, the subclasses are
called predicate-defined (or condition-defined) subclasses
• Condition is a constraint that determines subclass members
• Display a predicate-defined subclass by writing the predicate
condition next to the line attaching the subclass to its superclass
Slide 3- 17
Constraints on Specialization and
Generalization
• Two basic constraints can apply to a specialization/generalization:
1. 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 the 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 the EER diagram
• Example:
• For a university DBMS, the tables of students and faculty. A disjoint
constraint is used to make sure that records in both tables must have
different primary keys and a student cannot exist in a faculty table and vice
versa.
Slide 3- 18
Constraints on Specialization and
Generalization
2. Completeness (Exhaustiveness) Constraint:
• Makes sure that every conceivable value for an attribute is
represented in a table.
1. Total Completeness
• 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
• Example:
• Assume that the entity attributes for the customer DBMS are
• names, and preferred contact methods (email, postal mail,
cell phone, and home phone).
• Every potential value for the "preferred method of contact"
property (e.g., email, phone, and letter) would have to be
represented in the database in order to satisfy the "total
completeness" criteria.
Slide 3- 19
Constraints on Specialization and
Generalization
2. Partial
• Allows an entity not to belong to any of the subclasses
• Shown in EER diagrams by a single line
• Partial constraint permits certain potential values for an
attribute to be absent from a table while still guaranteeing that
any value that is there is legitimate.
• Example:
• Assume, for instance, that a table contains details about
workers, such as their department and job title. The "job title"
property could be subject to a partial completeness constraint
that permits some job titles to be absent from the table while
still ensuring that any job titles that are present be legitimate
Slide 3- 20
Constraints on Specialization and
Generalization
• Hence, we have 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.
Slide 3- 21
Example of disjoint partial Specialization
Example COMPANY Database
Slide 3- 22
Example of overlapping total Specialization
Example COMPANY Database
Slide 3- 23
Specialization/Generalization Hierarchies,
Lattices & Shared Subclasses
• A subclass may itself have further subclasses specified on it
• forms a hierarchy or a lattice
• Hierarchy has a constraint that every subclass has only one
superclass (called single inheritance); this is basically a tree
structure
• In a lattice, a subclass can be a subclass of more than one
superclass (called multiple inheritance)
Slide 3- 24
Specialization/Generalization Hierarchies,
Example COMPANY Database
Lattices & Shared Subclasses
ENGINEER is a subclass of EMPLOYEE and is also a superclass of
ENGINEERING_MANAGER; this represents the real-world constraint that every
engineering manager is required to be an engineer.
Slide 3- 25
Specialization/Generalization Hierarchies,
Lattices & Shared Subclasses
• In a lattice or hierarchy, a subclass inherits attributes not only of
its direct superclass but also of all its predecessor superclasses
all the way to the root of the hierarchy or lattice if necessary.
• For example, an entity in GRADUATE_STUDENT inherits all the
attributes of that entity as a STUDENT and as a PERSON.
• An entity may exist in several leaf nodes of the hierarchy, where
a leaf node is a class that has no subclasses of its own.
• For example, a member of GRADUATE_STUDENT may also be a
member of RESEARCH_ASSISTANT.
• A subclass with more than one superclass is called a shared
subclass (multiple inheritances) refer Figure 4.6 on slide 25
• Can have:
• specialization hierarchies or lattices, or
• generalization hierarchies or lattices,
• depending on how they were derived Slide 3- 26
Specialization/Generalization Hierarchies,
Example COMPANY Database
Lattices & Shared Subclasses
Slide 3- 27
Categories (UNION TYPES)
• A collection of entities from different entity types.
• In this case, a subclass will represent a collection of entities that is
a subset of the UNION of entities from distinct entity types; we call
such a subclass a union type or a category.
• All the superclass/subclass relationships we have seen thus far have a
single superclass
• A shared subclass is a subclass in:
• more than one distinct superclass/subclass relationships
• each relationship has a single superclass
• shared subclass leads to multiple inheritance
• In some cases, we need to model a single superclass/subclass
relationship with more than one superclass
• Superclasses can represent different entity types
• Such a subclass is called a category or UNION TYPE
Slide 3- 28
Categories (UNION TYPES)
• 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 (typically just 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
Slide 3- 29
Categories (UNION TYPES)
Slide 3- 30