Enhanced Entity-

Relationship Model
Objectives

• Definition of terms
• Use of supertype/subtype relationships
• Aggregation
• Use of generalization and specialization techniques
• Specification of completeness and disjoint constraints
• Develop supertype/subtype hierarchies for realistic business situations
• Union Type or Category
• ER Model Project
• Develop entity clusters
• Explain universal data model
• Name categories of business rules
• Define operational constraints graphically and in English
 Enhanced Entity Relationship Diagram
• Enhanced ERD 🡪 The model that has resulted from extending the original ER model with
new modeling constructs.
• Entity type 🡪 a collection of entities that have the same attributes (properties or
characteristics)
• In some situations, an entity type can be divided into several subgroups or subtypes
• Supertype 🡪 entity type that can be divided into subtypes
• A supertype is a generic entity type that has a relationship with one or more subtypes
• Subtype 🡪 a subset of a supertype and shares common attributes
• Behave like other entity types
• The identifiers (primary keys) of supertype and subtypes are always identical

• All properties of EMPLOYEE entity type

apply automatically to the TEACHER
subtype but the reverse is not true
• Each subtype has only one supertype
• Root 🡪 entity type at the top of a
hierarchy
Basic Notation for Supertype/Subtype
Notation

a) EER

Notatio
n
 Basic Notation for Supertype/Subtype Notation
(Cont.)
b)
Microsoft
Visio
Notation

Different modeling tools may have different notation for the

same modeling constructs
Employee Supertype with three Subtypes

All employee subtypes

will have emp nbr, name,
address, and date-hired

Each employee subtype

will also have its own
attributes
 IS-A Relationship
• Relationship between each subtype and its supertype 🡪 IS-A or IS-AN relationship
• For example: "Shahbaz IS-A Student“, "Teacher IS-AN Employee“
• The relationship is read from subtype to supertype
• The identifier (or primary key) of supertype is included with each subtype
• For example: two types of teachers in a university 🡪 permanent teachers, visiting
teachers
• Permanent teachers: Teacher-ID, Name, Address, Mobile-No, Basic Salary, and Allowances
• Visiting teachers: Teacher-ID, Name, Address, Mobile-No, Hours, and Rate Per Hour
• Each type has one or more attributes that are different from the other type
• Each subtype contains only those attributes that are not common
• Cardinality from subtype to supertype 🡪 mandatory
• because an instance of a subtype is always an instance of the supertype
• Cardinality from supertype to subtype 🡪 optional zero or one
• Exclusive relationship 🡪 subtype and supertype are mutually exclusive, and each
instance of the supertype is required to be a member of exactly one subtype
• Each teacher must be a permanent teacher or visiting teacher
Supertype/Subtype Relationships in a Hospital

Both
outpatients
and resident
patients are
cared for by
a responsible
physician

Only resident patients are

assigned to a bed
 Inheritance Associated with Supertype/Subtype
• Inheritance is another important concept associated with subtypes and
supertypes
• Property by which all attributes (and relationships) of a supertype become
attributes of its subtypes
• This important property makes it unnecessary to include the attributes and
relationships of supertype with the subtypes
• These attributes need not be attached to the subtypes
 Aggregation
• Aggregation 🡪 an abstraction concept, which is used to build a higher-level
object from its components
• For example, a computer is built by using various related components
• The aggregation abstraction allows designer to
• either decompose objects by breaking them into more detailed components
• or to aggregate objects, grouping them together into higher-level objects
• The hardware and software are further decomposed into their subparts
 Generalization
• The process of identifying a general entity type from a set of specialized
entity types
• Bottom-up process in which two or more entities can be generalized to a
higher level entity if they have some attributes in common
• Common features of subclasses are identified and generalized into a single
super-class

Bottom Up
 Example of Generalization
a) Three entity types: CAR, TRUCK, and MOTORCYCLE

All these types of vehicles have common attributes

 Example of Generalization (Cont.)

b) Generalization to VEHICLE supertype

So we put
the shared
attributes in
a supertype

Note: no subtype for motorcycle, since it has no unique

attributes
 Specialization
• The process of identifying one or more subtypes and forming
supertype/subtypes relationships
• Specialization is the process of defining a set of subtypes or subclasses of the
supertype
• The subtypes are defined based on their characteristics
• Top-down process in which a higher-level entity type (supertype) is divided
into two more lower-level entity types (subtypes)
• Inheritance 🡪 subclasses inherit all the attributes and relationships of their
superclass

Top Down
Example of Specialization
a) Entity type PART

Only applies to
manufactured parts

Applies only to purchased

parts
 Example of Specialization (Cont.)
b) Specialization to MANUFACTURED PART and PURCHASED PART

Created 2
subtypes

Note: multivalued attribute was replaced by an

associative entity relationship to another entity
 Constraints in Supertype/ Completeness
Constraint

•Completeness Constraints: Whether an

instance of a supertype must also be a member
of at least one subtype
• Total Specialization Rule: Yes (double line)
• Partial Specialization Rule: No (single line)
Examples of Completeness Constraints
a) Total Specialization Rule

A patient must be either

an outpatient or a
resident patient
Examples of Completeness Constraints (Cont.)
b) Partial Specialization Rule

A vehicle
could be a
car, a
truck, or
neither
Inclusion of Constraints on Generalization and
Specialization
• Subclasses are disjoint 🡪 if an entity can be a member of only one subclass
• Subclasses are non-disjoint 🡪 if an entity can be a member of more than one
subclasses (i.e. subclasses are overlapping)

A member of a library can

A PERSON in a university can be EMPLOYEE,
be Regular Member, Life
ALUMNUS, and STUDENT at the same time
Member, or Season
Member.
Examples of Disjoint Constraints
a) Disjoint Rule

A patient can either be outpatient

or resident, but not both
Examples of Disjoint Constraints (Cont.)

b) Overlap rule

A part may be both

purchased and
manufactured
Constraints in Supertype/ Subtype
Discriminators
• Subtype Discriminator: An attribute of the supertype whose
values determine the target subtype(s)
• Disjoint – a simple attribute with alternative values to indicate
the possible subtypes
• Overlapping – a composite attribute whose subparts pertain to
different subtypes. Each subpart contains a boolean value to
indicate whether or not the instance belongs to the associated
subtype
Introducing a Subtype Discriminator (Disjoint Rule)

A simple attribute with

different possible values
indicating the subtype
Subtype Discriminator (Overlap Rule)
A composite
attribute with
sub-attributes
indicating “yes”
or “no” to
determine
whether it is of
each subtype
Example of Supertype/Subtype Hierarchy
 Union Type or Category
• Union Type or Category 🡪 A collection of entities of distinct entity types
• Triangle symbol is used to show the union type or category
• For example, the OWNER of a COMPANY can be a PERSON with a BANK
ACCOUNT
 Project 1
Step 1
•In a university/college, a student
called a class representative (CR)
represents other students of his
class. The STUDENT entity type may
have attributes like Roll-No, and
Name, Phone.
Step 2
•A student in a university/college
takes one or more courses according
to his/her choice. But in order to be
a student, he/she must take at least
one course. The COURSE entity type
may have attributes like CourseID,
CourseName, CourseFee, etc.
 Project 1
Step 3
•A course is always taught by some teachers. A teacher cannot exist without a
corresponding course. A course may be taught by at least one or more
teachers. On the other hand, a teacher may teach at least one or more
courses.

Step 4
•Each department has a chairman, while a chairman chairs only one
department.
 Project 1
Step 5
•In a university, a teacher belongs to one and only one department. However,
a department may have at least one or many teachers. The teacher can be
visiting, part-time, or full-time.
 Project 1
COMPLETE EE-R MODEL OF UNIVERSITY SYSTEM
Entity Clusters

• EER diagrams are difficult to read when there are too many entities
and relationships
• Solution: Group entities and relationships into entity clusters
• Entity cluster: Set of one or more entity types and associated
relationships grouped into a single abstract entity type
Possible Entity
Clusters for Pine
Valley Furniture in
Microsoft Visio

Related groups
of entities could
become clusters
EER Diagram of PVF Entity Clusters

More readable,
isn’t it?
Manufacturing Entity Cluster

Detail for a single cluster

Packaged data
models provide
generic models
that can be
customized for a
particular
organization’s
business rules
 Business Rules

• Statements that define or constrain some aspect of the

business
• Classification of business rules:
• Derivation–rule derived from other knowledge, often in the form of a
formula using attribute values
• Structural assertion–rule expressing static structure. Includes attributes,
relationships, and definitions
• Action assertion–rule expressing constraints/control of organizational
actions
EER Diagram
to Describe
Business
Rules
Types of Action Assertions

• Result
• Condition–IF/THEN rule
• Integrity constraint–must always be true
• Authorization–privilege statement
• Form
• Enabler–leads to creation of new object
• Timer–allows or disallows an action
• Executive–executes one or more actions
• Rigor
• Controlling–something must or must not happen
• Influencing–guideline for which a notification must occur
Stating an Action Assertion

• Anchor Object–an object on which actions are limited

• Action–creation, deletion, update, or read
• Corresponding Objects–an object influencing the ability to perform an
action on another business rule

Action assertions identify corresponding objects that

constrain the ability to perform actions on anchor objects
Data Model Segment for Class Scheduling
 Business Rule 1: For a faculty member to be assigned to teach a section
of a course, the faculty member must be qualified to teach the course for
which that section is scheduled

Corresponding object

In this case, the

action assertion
is a Restriction Action assertion

Anchor object

Corresponding object
 Business Rule 2: For a faculty member to be assigned to teach a section of
a course, the faculty member must not be assigned to teach a total of more
than three course sections

In this case, the

action assertion Corresponding
is an object

Upper LIMit
Action assertion
Anchor object