COMP 1630

Relational Database Design and SQL

Week 3
Chapter 4

Entity Relationship
(ER) Modeling
Learning Objectives
After completing this chapter, you will be able to:
■ Identify the main characteristics of entity relationship components
■ Describe how relationships between entities are defined, refined, and
incorporated into the database design process
■ See how ERD components affect database design and implementation
■ Understand that real-world database design often requires the
reconciliation of conflicting goals
The Entity Relationship Model
(ERM)
Forms the basis of an
Database’s main
entity relationship
components
diagram (ERD)
• Conceptual database as • Entities
viewed by end user • Attributes
• Relationships
Entities

Object of interest to the end user

• Refers to the entity set and not to a single entity occurrence

ERM corresponds to a table—not to a row—in the

relational environment
• ERM refers to a table row as an entity instance or entity
Inoccurrence
Chen, Crow’s Foot, and UML notations, an
entity is represented by a rectangle that contains
the entity’s name
• The entity name, a noun, is usually written in all capital letters
■ Characteristics of entities
– Required attribute: must have a value and cannot be left empty
– Optional attribute: does not require a value and can be left empty
– Domain: set of possible values for a given attribute
– Identifier: one or more attributes that uniquely identify each entity instance
– Composite identifier: primary key composed of more than one attribute
– Composite attribute: attribute that can be subdivided to yield additional attributes
– Simple attribute: attribute that cannot be subdivided
– Single-valued attribute: attribute that has only a single value
– Multivalued attributes: attributes that have many values

Attributes (1 of 7)
Attributes (2 of 7)
Attributes (3 of 7)
Attributes (4 of 7)
■ Requirements of multivalued attributes
– Create several new attributes, one for each component of the
original multivalued attribute
– Develop a new entity composed of the original multivalued
attribute’s components
■ Derived attribute: attribute whose value is calculated from other
attributes
– Derived using an algorithm
Attributes (5 of 7)
Attributes (6 of 7)
Attributes (7 of 7)
Table 4.2 Advantages and Disadvantages of Storing Derived Attributes
Derived Attribute: Stored Derived Attribute: Not Stored

Advantage Saves CPU processing cycles Saves storage space

Saves data access time Computation always yields current value
Data value is readily available
Can be used to keep track of
historical data

Disadvantage Requires constant maintenance Uses CPU processing cycles

to ensure derived value is Increases data access time
current, especially if any values Adds coding complexity to queries
used in the calculation change
Relationships,
Connectivity, and
Cardinality
■ Association between entities that always operate in both
directions
– Participants: entities that participate in a
relationship
■ Connectivity: describes the relationship classification
– Include 1:1, 1:M, and M:N
■ Cardinality: expresses the minimum and maximum
number of entity occurrences associated with one
occurrence of related entity
– In the ERD, cardinality is indicated by placing the
appropriate numbers beside the entities, using the
format (x, y)
 Existence
dependence

Existence • Entity exists in the database only when it is

associated with another related entity

Dependen occurrence

ce Existence
independence
• Entity exists apart from all of its related
entities
• Referred to as a strong entity or regular
entity
Relationship Strength
■ Weak (non-identifying) relationship
– Primary key of the related entity does not contain a primary key
component of the parent entity
■ Strong (identifying) relationships
– Primary key of the related entity contains a primary key component of the
parent entity
Weak Entities (1 of 3)
■ Conditions of a weak entity
– Existence-dependent
– Has a primary key that is partially or totally derived from
parent entity in the relationship
■ Database designer determines whether an entity is weak
– Based on business rules
Weak Entities (2 of 3)
Weak Entities (3 of 3)
Relationship Participation
■ Optional participation
– One entity occurrence does not require a corresponding entity
occurrence in a particular relationship

■ Mandatory participation
– One entity occurrence requires a corresponding entity occurrence
in a particular relationship
Relationship Degree

Indicates the number of entities or

participants associated with a relationship
■ Unary relationship: association is
maintained within a single entity
■ Binary relationship: two entities are
associated
■ Ternary relationship: three entities are
associated
■ Recursive relationship: relationship exists
within a single entity type
 Recursive Relationships

■ Relationship can exist between occurrences of the same entity set

– Naturally, such a condition is found within a unary relationship
■ Common in manufacturing industries
■ One common pitfall when working with unary relationships is to
confuse participation with referential integrity
– Similar because they are both implemented through constraints
on the same set of attributes
Associative (Composite) Entities
■ Used to represent an M:N relationship between two or more
entities
■ Has a 1:M relationship with the parent entities
– Composed of the primary key attributes of each parent entity
■ May also contain additional attributes that play no role in
connective process
Developing an ER Diagram (1 of
11)
■ Activities involved in building and ERD
– Create a detailed narrative of the organization’s description of
operations
– Identify business rules based on the descriptions
– Identify main entities and relationships from the business rules
– Develop the initial ERD
– Identify the attributes and primary keys that adequately describe
entities
– Revise and review ERD
Developing an ER Diagram (2 of
11)
Developing an ER Diagram (3 of
11)
Developing an ER Diagram (4 of
11)
Developing an ER Diagram (5 of
11)
Developing an ER Diagram (6 of
11)
Developing an ER Diagram (7 of
11)
Developing an ER Diagram (8 of
11)
Developing an ER Diagram (9 of
11)
Developing an ER Diagram (10 of
11)
Developing an ER Diagram (11 of
11)
Table 4.4
Entity
Components of the ERM
Relationship Connectivity Entity

SCHOOL operates 1:M DEPARTMENT

DEPARTMENT has 1:M STUDENT

DEPARTMENT employs 1:M PROFESSOR

DEPARTMENT offers 1:M COURSE

COURSE generates 1:M CLASS

SEMESTER includes 1:M CLASS
PROFESSOR is dean of 1:1 SCHOOL

PROFESSOR chairs 1:1 DEPARTMENT

PROFESSOR teaches 1:M CLASS

PROFESSOR advises 1:M STUDENT

STUDENT enrolls in M:N CLASS

BUILDING contains 1:M ROOM
ROOM is used for 1:M CLASS
Note: ENROLL is the composite entity that implements the
M:N relationship “STUDENT enrolls in CLASS.”
Database Design Challenges:
Conflicting Goals
■ Database designers must often make design compromises that
are triggered by conflicting goals
– Database design must conform to design standards
– High processing speed may limit the number and complexity
of logically desirable relationships
– Maximum information generation may lead to loss of clean
design structures and high transaction speed
Summary
■ The ERM uses ERDs to represent the conceptual database as viewed by
the end user
■ Connectivity describes the relationship classification (1:1, 1:M, or M:N)
■ In the ERM, an M:N relationship is valid at the conceptual level
■ ERDs may be based on many different ERMs
■ Unified Modeling Language (UML) class diagrams are used to represent
the static data structures in a data model
■ Database designers, no matter how well they can produce designs that
conform to all applicable modeling conventions, are often forced to make
design compromises
Chapter 5

Advanced Data
Modeling
Learning Objectives
After completing this chapter, you will be able to:
■ Describe the main extended entity relationship (EER) model
constructs and how they are represented in ERDs and EERDs
■ Use entity clusters to represent multiple entities and relationships in
an entity relationship diagram (ERD)
■ Describe the characteristics of good primary keys and how to select
them
■ Apply flexible solutions for special data-modeling cases
The Extended Entity Relationship
Model (EERM)
■ Enhanced entity relationship model
– Result of adding more semantic constructs to the original entity relationship
(ER) model
– EER diagrams (EERDs) use the EER model
Entity Supertypes and Subtypes

Entity supertype
• Generic entity type related to one or more entity subtypes
• Contains common characteristics
Entity subtype
• Contains unique characteristics of each entity subtype

Criteria to determine usage

• There must be different, identifiable kinds of the entity in the user’s
environment
• The different kinds of instances should each have one or more
attributes that are unique to that kind of instance
Entity supertypes and subtypes are organized in a specialization
hierarchy
• Depicts arrangement of higher-level entity supertypes and lower-level entity subtypes
• Relationships are described in terms of “is-a” relationships
• Subtype exists within the context of a supertype
• Every subtype has one supertype to which it is directly related
• Supertype can have many subtypes

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

Specialization Hierarchy (1 of 2)
Specialization Hierarchy (2 of 2)
Inheritance

Enables an entity subtype to inherit attributes

and relationships of the supertype
■ All entity subtypes inherit their primary key
attribute from their supertype
■ At the implementation level, supertype and
its subtype(s) maintain a 1:1 relationship
■ Entity subtypes inherit all relationships in
which supertype entity participates
■ Lower-level subtypes inherit all attributes
and relationships from its upper-level
supertypes
Subtype Discriminator
■ Attribute in the supertype entity that determines to which
entity subtype the supertype occurrence is related
– Default comparison condition is the equality comparison
– In some situations, the subtype discriminator is not
necessarily based on an equality comparison
Disjoint and Overlapping
Constraints
■ Disjoint subtypes: contain a unique subset of the supertype entity set
– Known as nonoverlapping subtypes
– Implementation is based on the value of the subtype discriminator attribute in the
supertype
■ Overlapping subtypes: contain nonunique subsets of the supertype entity set
– Implementation requires the use of one discriminator attribute for each subtype

TABLE 5.1: Discriminator Attributes with Overlapping Subtypes

Discriminator Discriminator Comment

Attributes: Professor Attributes:
Administrator
Y N The Employee is a member of the Professor
subtype.
N Y The Employee is a member of the Administrator
subtype.
Y Y The Employee is both a Professor and an
Administrator.
Completeness Constraint

TABLE 5.2 Specifies whether each

supertype occurrence must
SPECIALIZATION HIERARCHY CONSTRAINT
also be a member of at least
SCENARIOS
one subtype
Type Disjoint Constraint Overlapping Constraint ■ Partial completeness: not
every supertype
Partia Supertype has optional Supertype has optional occurrence is a member of
l subtypes. subtypes. a subtype
Subtype discriminator can be Subtype discriminators can
null. be null. ■ Total completeness: every
Subtype sets are unique. Subtype sets are not unique. supertype occurrence
must be a member of at
Total Every supertype occurrence is Every supertype occurrence least one subtypes
a member of only one subtype. is a member of at
Subtype discriminator cannot least one subtype.
be null. Subtype discriminators
Subtype sets are unique. cannot be null.
Subtype sets are not unique.
 Specialization

• Top-down process
• Identifies lower-level, more specific
entity subtypes from a higher-level
Specializatio entity supertype
n and • Based on grouping unique
characteristics and relationships of
Generalizati the subtypes
Generalization
on • Bottom-up process
• Identifies a higher-level, more
generic entity supertype from lower-
level entity subtypes
• Based on grouping common
characteristics and relationships of
the subtypes
Entity Clustering

“Virtual” entity type used to represent

multiple entities and relationships in ERD
■ Formed by combining multiple
interrelated entities into a single,
abstract entity object
■ General rule: avoid the display of
attributes to eliminate complications
that result when the inheritance rules
change
Entity Integrity: Selecting Primary
Keys
■ Primary keys: single attribute or a combination of attributes
– Uniquely identifies each entity instance
– Guarantees entity integrity
– Works with foreign keys to implement relationships

Natural Keys and Primary Keys

■ Natural key or natural identifier:
– real-world identifier used to uniquely identify real-world objects
– Familiar to end users and forms part of their day-to-day business
vocabulary
– Used as the primary key of the entity being modeled
Primary Key Guidelines
■ Desirable primary key characteristics
– Non intelligent
– No change over time
– Preferably single-attribute
– Preferably numeric
– Security-compliant
When to Use Composite Primary
Keys
■ Identifiers of composite entities
– Each primary key combination is allowed once in M:N relationship
■ Identifiers of weak entities
– Strong identifying relationship with the parent entity
– Represents a real-world object that is existence-dependent on another
real-world object
– Represented in the data model as two separate entities in a strong
identifying relationship
■
When to Use Surrogate Primary Keys
(1 of 2)
Primary key used to simplify Useful when there is no natural key
Helpful if selected candidate key has
the identification of entity embedded semantic contents or is
instances too long

Require ensuring that the

Use “unique index” and “not null”
candidate key of entity in constraints
question performs properly
 Table 5.4: Data Used to Keep Track of
Events
DATE TIME_START TIME_END ROOM EVENT_NAME PARTY_OF

6/17/2018 11:00 a.m. 2:00 p.m. Allure Burton 60

Wedding
6/17/2018 11:00 a.m. 2:00 p.m. Bonanza Adams Office 12
6/17/2018 3:00 p.m. 5:30 p.m. Allure Smith Family 15
6/17/2018 3:30 p.m. 5:30 p.m. Bonanza Adams Office 12
6/18/2018 1:00 p.m. 3:00 p.m. Bonanza Boy Scouts 33
6/18/2018 11:00 a.m. 2:00 p.m. Allure March of 25
Dimes
6/18/2018 11:00 a.m. 12:30 p.m. Bonanza Smith Family 12

When to Use Surrogate Primary Keys

(2 of 2)
 Summary
The extended entity relationship (EER) model adds semantics to the ER model via entity supertypes, subtypes, and
clusters
■ A specialization hierarchy depicts the arrangement and relationships between entity supertypes and entity
subtypes
■ An entity cluster is a “virtual” entity type used to represent multiple entities and relationships in the ERD
■ Natural keys are identifiers that exist in the real world
■ Composite keys are useful to represent M:N relationships and weak (strong identifying) entities
■ Surrogate primary keys are useful when there is no natural key that makes a suitable primary key, when the
primary key is a composite primary key with multiple data types, or when the primary key is too long to be usable
■ Time-variant data refers to data whose values change over time and require that you keep a history of data
changes
■ A fan trap occurs when you have one entity in two 1:M relationships to other entities, and there is an association
among the other entities not expressed in the model