Database Systems:

Design, Implementation, and

Management
Tenth Edition

Chapter 5
Advanced Data Modeling
 The Extended Entity Relationship
Model
• Extended entity relationship model (EERM),
sometimes referred to as the enhanced entity
relationship model, is the result of adding more
semantic constructs to the original ER model.
• As you might expect, a diagram that uses the
EERM is called an EER diagram (EERD).

Database Systems, 10th Edition 2

 Entity Supertypes and Subtypes
• Because most employees possess a wide range of
skills and special qualifications, data modelers must
find a variety of ways to group employees based on
their characteristics.
• It avoids unnecessary nulls in attributes when some
employees have characteristics that are not shared
by other employees.
• It enables a particular employee type to participate
in relationships that are unique to that employee
type.

Database Systems, 10th Edition 3

 Entity Supertypes and Subtypes

Database Systems, 10th Edition 4

 Entity Supertypes and Subtypes
• The PILOT entity stores only attributes that are
unique to pilots and that the EMPLOYEE entity
stores attributes that are common to all employees.
• Based on that hierarchy, you can conclude that
PILOT is a subtype of EMPLOYEE and that
EMPLOYEE is the supertype of PILOT.
• In modeling terms, an entity supertype is a generic
entity type that is related to one or more entity
subtypes. The entity supertype contains common
characteristics, and the entity subtypes each
contain their own unique characteristics.
Database Systems, 10th Edition 5
 Entity Supertypes and Subtypes
Two criteria help the designer determine when to use
subtypes and supertypes:

• There must be different, identifiable kinds or types

of the entity in the user’s environment.

• The different kinds or types of instances should

each have one or more attributes that are unique to
that kind or type of instance.

Database Systems, 10th Edition 6

 Specialization Hierarchy
• Entity supertypes and subtypes are organized in a
specialization hierarchy, which depicts the
arrangement of higher-level entity supertypes
(parent entities) and lower- level entity subtypes
(child entities).
A specialization hierarchy provides the means to:
• Support attribute inheritance.
• Define a special supertype attribute known as the
subtype discriminator.
• Define disjoint or overlapping constraints and
complete or partial constraints.
Database Systems, 10th Edition 7
 Specialization Hierarchy

Database Systems, 10th Edition 8

 Inheritance
• The property of inheritance enables an entity
subtype to inherit the attributes and relationships of
the supertype.
• A supertype contains attributes that are common to
all of its subtypes. In contrast, subtypes contain
only the attributes that are unique to the subtype.
• One important inheritance characteristic is that all
entity subtypes inherit their primary key attribute
from their supertype.
• Entity subtypes inherit all relationships in which the
supertype entity participates.
Database Systems, 10th Edition 9
 Inheritance

Database Systems, 10th Edition 10

 Subtype Discriminator
• A subtype discriminator is the attribute in the
supertype entity that determines to which subtype
the supertype occurrence is related.
• It is common practice to show the subtype
discriminator and its value for subtype in the ERD.
• In previous example Supertype Employee is related
to a PILOT subtype if the EMP_TYPE has a value
of “P.” If the EMP_TYPE value is “M,” the supertype
is related to a MECHANIC subtype. If the
EMP_TYPE value is “A,” the supertype is related to
the ACCOUNTANT subtype.
Database Systems, 10th Edition 11
 Disjoint and Overlapping Constraints
• Disjoint subtypes, also known as nonoverlapping
subtypes, are subtypes that contain a unique
subset of the supertype entity set; in other words,
each entity instance of the supertype can appear in
only one of the subtypes.
• Overlapping subtypes are subtypes that contain
nonunique subsets of the supertype entity set; that
is, each entity instance of the supertype may
appear in more than one subtype.

Database Systems, 10th Edition 12

 Disjoint and Overlapping Constraints

Database Systems, 10th Edition 13

 Disjoint and Overlapping Constraints
• The implementation of disjoint subtypes is based
on the value of the subtype discriminator attribute
in the supertype. However, implementing
overlapping subtypes requires the use of one
discriminator attribute for each subtype.

Database Systems, 10th Edition 14

 Completeness Constraint
• The completeness constraint specifies whether
each entity supertype occurrence must also be a
member of at least one subtype. The completeness
constraint can be partial or total.
• Partial completeness means that not every
supertype occurrence is a member of a subtype;
some supertype occurrences may not be members
of any subtype. Represented by single line.
• Total completeness means that every supertype
occurrence must be a member of at least one
subtype. Represented by double lines.
Database Systems, 10th Edition 15
 Specialization and Generalization
• Specialization is the top-down process of identifying
lower-level, more specific entity subtypes from a
higher-level entity supertype. In the aviation
example, you used specialization to identify
multiple entity subtypes from the original employee
supertype.
• Generalization is the bottom-up process of
identifying a higher-level, more generic entity
supertype from lower-level entity subtypes.
Generalization is based on grouping the common
characteristics and relationships of the subtypes.

Database Systems, 10th Edition 16

 Entity Clustering
• An entity cluster is a “virtual” entity type used to
represent multiple entities and relationships in the
ERD.
• An entity cluster is formed by combining multiple
interrelated entities into a single, abstract entity
object.
• An entity cluster is considered “virtual” or “abstract”
in the sense that it is not actually an entity in the
final ERD. Instead, it is a temporary entity used to
represent multiple entities and relationships, with
the purpose of simplifying the ERD and thus
enhancing its readability.
Database Systems, 10th Edition 17
 Entity Integrity:
Selecting Primary Keys
• Primary key is the most important characteristic
of an entity
– Single attribute or some combination of attributes
• Primary keys and foreign keys work together to
implement relationships
• Properly selecting primary key has direct bearing
on efficiency and effectiveness

Database Systems, 10th Edition 18

 Natural Keys and Primary Keys
• Natural key is a real-world identifier used to uniquely
identify real-world objects
– Familiar to end users and forms part of their day-to-day
business vocabulary
• Generally, data modeler uses natural identifier as
primary key of entity being modeled
• May instead use composite primary key or surrogate
key
– Surrogate key - a PK created to simplify the
identification of entity instances
• Has no meaning, exists only to distinguish one entity from
another (e.g., Autonumber)

Database Systems, 10th Edition 19

 Primary Key Guidelines
• Attribute that uniquely identifies entity instances
in an entity set
– Could also be combination of attributes
• Main function is to uniquely identify an entity
instance or row within a table
• Guarantee entity integrity, not to “describe”
the entity
• Primary keys and foreign keys implement
relationships among entities
– Behind the scenes, hidden from user

Database Systems, 10th Edition 20

Database Systems, 10th Edition 21
 When to Use Composite Primary Keys
• Composite primary keys useful in two cases:
– As identifiers of composite entities
• In which each primary key combination is allowed
once in M:N relationship
– As identifiers of weak entities
• In which weak entity has a strong identifying
relationship with the parent entity
• Automatically provides benefit of ensuring that
there cannot be duplicate values

Database Systems, 10th Edition 22

 Composite PK of ENROLL
ensures a student can not
Database Systems, 10th Edition register for the same class twice 23
 When to Use Composite Primary Keys
• When used as identifiers of weak entities
normally used to represent:
– Real-world object that is existent-dependent on
another real-world object (employee-dependent)
– Real-world object that is represented in data
model as two separate entities in strong
identifying relationship (invoice-line)
• Dependent entity exists only when it is related to
parent entity
– EMPLOYEE and DEPENDENT – latter uses a
composite PK containing employee id
– LINE exists only as part of INVOICE

Database Systems, 10th Edition 24

 When To Use Surrogate Primary Keys
• Especially helpful when there is:
– No natural key
– Selected candidate key has embedded semantic
contents
– Selected candidate key is too long or
cumbersome

Database Systems, 10th Edition 25

 When To Use Surrogate Primary Keys
• If you use surrogate key:
– Ensure that candidate key of entity in question
performs properly
– Use “unique index” and “not null” constraints

Database Systems, 10th Edition 26

 When To Use Surrogate Primary Keys

• A catering hall has a number of rooms it rents for small parties

– What should be the PK? DATE,TIME_START,ROOM
– What if, in addition to the room, additional equipment were to be used
from the RESOUCE table
– Composite key for linking table would be DATE,TIME_START,ROOM,
RSC_ID
• Quite lengthy
• If that became FK in another entity, it would be quite complex to maintain
– Instead use numeric, single attribute surrogate key
27
Database Systems, 10th Edition
 Design Cases:
Learning Flexible Database Design
• Data modeling and design requires skills
acquired through experience
• Experience acquired through practice
• Four special design cases that highlight:
– Importance of flexible design
– Proper identification of primary keys
– Placement of foreign keys

Database Systems, 10th Edition 28

 Design Case 1: Implementing 1:1
Relationships
• Foreign keys work with primary keys to properly
implement relationships in relational model
• Put primary key of the “one” side on the “many”
side as foreign key
– Primary key: parent entity
– Foreign key: dependent entity

Database Systems, 10th Edition 29

 Design Case 1: Implementing 1:1
Relationships
• In 1:1 relationship, there are two options:
– Place a foreign key in both entities (not
recommended)
– Place a foreign key in one of the entities
• Primary key of one of the two entities appears as
foreign key of other

Database Systems, 10th Edition 30

Database Systems, 10th Edition 31
 Design Case 2: Maintaining History of
Time-Variant Data
• Normally, existing attribute values are replaced
with new value without regard to previous value
• Time-variant data:
– Values change over time
– Must keep a history of data changes
• Keeping history of time-variant data equivalent
to having a multivalued attribute in your entity
• Must create new entity in 1:M relationships with
original entity
• New entity contains new value, date of change

Database Systems, 10th Edition 32

Database Systems, 10th Edition 33
Database Systems, 10th Edition 34
 Design Case 3: Fan Traps
• Design trap occurs when relationship is
improperly or incompletely identified
– Represented in a way not consistent with the
real world
• Most common design trap is known as fan trap
• Fan trap occurs when one entity is in two 1:M
relationships to other entities
– Produces an association among other entities
not expressed in the model

Database Systems, 10th Edition 35

Database Systems, 10th Edition 36
Database Systems, 10th Edition 37
 Design Case 4:
Redundant Relationships
• Redundancy is seldom a good thing in database
environment
• Occurs when there are multiple relationship paths
between related entities
• Main concern is that redundant relationships
remain consistent across model
• Some designs use redundant relationships to
simplify the design
• In the following example, the relationship between
DIVISION and PLAYER is not needed as all
information can be obtained through TEAM
Database Systems, 10th Edition 38
Database Systems, 10th Edition 39
 40
Database Systems, 10th Edition
 Portion of Tiny College ERD

Database Systems, 10th Edition 41

 Tiny College - New Requirement
• Tiny College wants to keep track of the history of all
administrative appointments (date of appointment and
date of termination).
• The Tiny College chancellor may want to know how
many deans worked in the College of Business between
January 1, 1960 and January 1, 2010 or who the dean
of the College of Education was in 1990. Given that
information, create the complete ERD containing all
primary keys, foreign keys, and main attributes.

Database Systems, 10th Edition 42

 Tiny College ERD

Database Systems, 10th Edition 43