Database Systems

(Enhanced) Entity-Relationship
Model
CMPS 244
 Previous Lecture

• Entity Related Components

• Entity Sets
• Entity Attributes
• Entity Constraints

• Relationship Related Components

• Relationship Sets
• Relationship Attributes
• Relationship Constraints
 Example ER Diagram
firstname lastname
name year
credithours
hobby id name CID

m n
numofcourses STUDENT ENROLLED COURSE

grade
n

TEACHES
office
m

id
PROFESSOR name
 What we haven’t covered

• N-ary relationships

• Weak Entity Sets

• Specialization and Generalization

• Categorization
 N-ary Relationships

• Relationships can involve more than two entity types

• For example, consider the following relationship

• Professors teaching students a course for which they
receive a grade
• Involves three entity sets
• PROFESSOR
• STUDENT
• COURSE
 Example Ternary Relationship
firstname lastname
name year
credithours
hobby id name CID

numofcourses STUDENT TEACHES COURSE

grade

office

id
PROFESSOR name
 Constraints for N-ary
Relationships
• Participation Constraints
• Indicate whether entities must participate in the
relationship or not (similar to binary relationships)
• For our example ternary relationship, we have that
• Each student must be taught
• Each course must be taught
• Some professors do not teach
 Participation Constraints for a
Ternary Relationship
firstname lastname
name year
credithours
hobby id name CID

numofcourses STUDENT TEACHES COURSE

grade

office

id
PROFESSOR name
 Constraints for N-ary
Relationships (2)
• Cardinality Constraints
• Consider n-1 entity sets
• For our example ternary relationship, we have that
• Each student-course pair can be related to at most one staff
member
• Each professor-course pair can be related to many students
• Each professor-student pair can be related to many courses
 Cardinality Constraints for a
Ternary Relationship
firstname lastname
name year
credithours
hobby id name CID

m n
numofcourses STUDENT TEACHES COURSE

grade

1 office

id
PROFESSOR name
 What we haven’t covered

• N-ary relationships

• Weak Entity Sets

• Specialization and Generalization

• Categorization
 Weak Entity Sets

• Weak entities depend on other entities

• They cannot exist unless the entities they depend on exist
• They cannot be identified on their own

• Weak entity sets are connected to their identifying entity

sets via identifying relationships
• Weak entity sets are represented in an ER diagram as
double-lined rectangles
• Identifying relationships are represented in an ER
diagrams as double-lined diamonds
Example of a Weak Entity Set
office

id
PROFESSOR name

RELATED

relationship
name

RELATIVE
 Constraints for Weak Entity
Sets
• Weak entity sets always totally participate in the identifying
relationship
• Weak entities have partial keys that are used to identify entities
that belong to the same identifying entities
• E.g., name could be a partial key for relatives of professors since
it can identify the relatives of a given professor

• The key of a weak entity is the combination of its partial key

and the key of its identifying entity
• The key of a relative is professor id + name of relative

• Partial keys are represented in an ER diagram as underlined

attributes with the lines dotted
Cardinalities for Weak Entity
Sets (2)
office

id
PROFESSOR name

RELATED

relationship m
name

RELATIVE
 What we haven’t covered

• N-ary relationships

• Weak Entity Sets

• Specialization and Generalization

• Categorization
 Specialization and
Generalization
• Specialization is the process of defining a set of
subclasses for an entity set
• Each subclass has its own attributes, participates in its own
relationships

• Generalization is the process of defining a superclass for

a group of entity sets
• The superclass has its own attributes, participates in its own
relationships

• Subclasses inherit attributes from their superclasses

• Either attribute-based or user-defined
 Example of a User-defined
Specialization
firstname lastname

hobby id name

STUDENT

gpa
thesis
numofcourses

UNDERGRAD POSTGRAD
 Example of an Attribute-based
Generalization
firstname lastname

id name
type

PERSON

hobby office
numofcourses
Type=“staff ”

Type=“student”

STUDENT STAFF
 Specialization and
Generalization Constraints
• Participation Constraints
• Total participation if every entity in the superclass set
must be a member of at least one subclass
• Partial participation if some entities in the superclass
set do not have to belong to any subclass
• Total participation is denoted by double-lined edge
from the superclass to the specialization circle
 Example of a User-defined
Specialization
firstname lastname

hobby id name Each student must be

either an undergrad or
a postgrad
STUDENT

gpa
thesis
numofcourses

UNDERGRAD POSTGRAD
 Example of an Attribute-based
Generalization
firstname lastname
Some people are
neither students nor
staff id name
type

PERSON

hobby office
numofcourses
Type=“staff ”

Type=“student”

STUDENT STAFF
 Specialization and
Generalization Constraints (2)
• Overlap Constraints
• Disjoint if all subclasses are disjoint (i.e., an entity can
belong to at most one subclass)
• Denoted by “d” in the specialization circle
• Overlapping if the subclasses are overlapping (i.e., an
entity can belong to more than one subclass
• Denoted by “o” in the specialization circle
 Example of a User-defined
Specialization
firstname lastname

hobby id name Each student must be

either an undergrad or
a postgrad but can’t be
STUDENT
both

gpa
thesis
numofcourses

UNDERGRAD POSTGRAD
 Example of an Attribute-based
Generalization
firstname lastname
Some people are
neither students nor
staff and a person can id name
type
be both a student and
a staff, e.g., RA or TA
PERSON

hobby office
numofcourses
Type=“staff ”

Type=“student”

STUDENT STAFF
 What we haven’t covered

• N-ary relationships

• Weak Entity Sets

• Specialization and Generalization

• Categorization
 Categorization

• In categorization, we have n superclasses and one

subclass

• The subclass contains entities from either of its n

superclasses

• The subclass is said to be a subset of the union of its

n superclasses

• Attribute inheritance depends on the superclass the

entity belongs to
Example of a Categorization

account_no
An owner is either a
balance
person or a company but a
person or a company don’t
have to be an owner
OWNER

name
id name
address

job
PERSON COMPANY
Categorization Constraints

• Participation Constraints
• Total participation if the subclass is the union of all the
entities in the superclasses (i.e., every entity in each
superclass is a member of the subclass as well)
• A categorization with total participation is equivalent
to a specialization (generalization) with total
participation
• Partial participation if some entities in the superclasses
do not belong to the subclass
• Total participation is denoted by double-lined edge
from the subclass to the categorization circle
 Example of a Total
Categorization
account_no Every person is an owner
balance
and every company is an
owner
ACCOUNT
Equivalent to a total
specialization

name
id name
address

job
PERSON COMPANY
 What we haven’t covered

• N-ary relationships

• Weak Entity Sets

• Specialization and Generalization

• Categorization
 Design Tips for ER Modeling

• Avoid redundancy

• Limit the use of weak entity sets

• Don’t use an entity set when an attribute will do

32
 Avoiding Redundancy

• Redundancy occurs when we say the same thing in

two different ways

• Redundancy wastes space and (more importantly)

encourages inconsistency
• The two instances of the same fact may become
inconsistent if we change one and forget to change the
other related version

33
 Example 1
name name addr

m 1
PRODUCT SELLS PRODUCER

Good!
- Every producer’s address is stored once

34
 Example 1
name name addr

m 1
PRODUCT SELLS PRODUCER

producer

Bad!
- Storing information about producers twice

35
 Example 3

name producer

address

PRODUCT

Bad!
- Repeats the address of a producer for each product it produces and
we can’t store information about producers who do not produce
anything at some point

36
 Entity Sets Versus Attributes

• An entity set should satisfy at least one of the

following conditions
• It is more than the name of something
• It has at least one non-key attribute
• It is the ”many” in a one to many or many to many
relationship

37
 Example 4
name name addr

m 1
PRODUCT SELLS PRODUCER

Good!
- PRODUCER deserves to be an entity set because it has non-key
attribute address
- PRODUCT deserves to be an entity set because it is the “many” of
the one to many relationship

38
 Example 5

name producer

PRODUCT

Good!
- No need to use producer as an entity set since we only record
names of producers

39
 Example 6
name name

m 1
PRODUCT SELLS PRODUCER

Bad!
- we store only the names of producers (i.e., no non-key attributes)
and it’s not the “many” of the 1 to many relationship so it doesn’t
need to be an entity set

40
 Design Tips for ER Modeling (2)
• Don’t overuse weak entity sets
• Beginning database designers often doubt that anything could be
a key by itself
• They make all entity sets weak, supported by all other entity sets
to which they are linked
• In reality, we usually create IDs for entity sets

• When to use weak entity sets?

• The usual reason is that there is no global authority capable of
creating unique IDs

41
 Design Tips for ER Modeling (3)
• When to use specialization/generalization?
• If a subclass has few specific attributes and no specific
relationships it should be merged into the superclass
• If all the subclasses have few specific attributes and no specific
relationships, they should be merged into the superclass and add
one or more type attributes that specify the subclass or subclasses
that each entity belongs to

• When to use categorization?

• Categories should generally be avoided unless the superclasses
represent completely different types of entities and do not share
many attributes but participate in many similar relationships

42
 Further Readings

• Chapter 4 of the main textbook