Chapters 4, 6

Entity
Relationship
Modeling

Database Systems: Design,

Implementation, and Management
CHAPTERS 4, 5

Entity Relationship (E-R) Modeling

Database
Systems

1
 Chapter Objectives
Chapters 4, 6
Entity
Relationship
Modeling

 Understand basic modeling concepts

 Understand the entity relationship model
 Learn how to develop an E-R diagram

Database
Systems

2
 The Entity Relationship (E-R) Model
Chapters 4, 6
Entity
Relationship
Modeling  E-R Model Components
 Three components: Entities, Attributes, and
Relationships.
 Entities
 In E-R model an entity refers to the entity set, not an entity
occurrence.
 A row in a table corresponds to an entity instance.
 An entity is represented by a rectangle containing the
entity’s name.
 Example:

STUDENT
Database
Systems

3
 The Entity Relationship (E-R) Model
Chapters 4, 6
Entity
Relationship
Modeling  Attributes
 Attributes are represented by ovals and are
connected to the entity with a line.
 Each oval contains the name of the attribute it
represents.
 Attributes have a domain -- the attribute’s set of
possible values.
 Attributes may share a domain.
 Primary keys are underlined.

Database
Systems

4
 E-R Diagram - Example
Chapters 4, 6
Entity
Relationship
Modeling
ID NAME MAJOR

STUDENT

E-R Diagram of STUDENT Entity with Attributes

ID Name Major
123456789 John McDonald Insy
123123423 Joe Baxter Insy
356342112 Jill Austin Fina
Relational Table for Student entity
Database A shorthand form used to describe table structure:
Systems
STUDENT (ID, NAME, MAJOR) 5
 Classes of Attributes
Chapters 4, 6
Entity
Relationship
Modeling  A simple attribute cannot be subdivided.
 Examples: Age, Sex, and Marital status
 A composite attribute can be further subdivided to
yield additional attributes.
 Examples:
 ADDRESS Street, City, State, Zip
 PHONE NUMBER  Area code, Exchange number
 Don’t confuse with composite key, where two
attributes together form a primary key.
 Example of composite key:
 CLASS(Course_ID, Section_Nbr, Class_Time, Prof_Num)
Database
Systems

6
 Classes of Attributes
Chapters 4, 6
Entity
Relationship
Modeling  A single-valued attribute can have only a single
value.
 Examples:
 A person can have only one social security number.
 A manufactured part can have only one serial number.
 A multivalued attribute can have many values.
 Multivalued attributes are shown by a double line
connecting to the entity
 Examples:
 A person may have several college degrees.
 A household may have several phones with different
Database numbers
Systems

7
 Multivalued Attribute Example
Chapters 4, 6
Entity
Relationship
Modeling

Mod_Code Car_Year

Car_ID Car_Color
CAR

Car Color can take multiple values for

color of body, trim, top, etc

Database
Systems

8
 Classes of Attributes
Chapters 4, 6
Entity
Relationship
Modeling  Multivalued Attribute in Relational DBMS
 The relational DBMS cannot implement multivalued
attributes.
 Possible courses of action for the designer
 Within the original entity, create several new attributes,
one for each of the original multivalued attribute’s
components. Example:
 CAR_COLOR 
CAR_TOPCOLOR, CAR_BODYCOLOR,
CAR_TRIMCOLOR
 Create a new entity composed of the original multivalued
attribute’s components.

Database
Systems

9
 Multivalued Attribute Representation
Chapters 4, 6
Entity
Relationship
Modeling
Mod_Code Car_Year TopColor TrimColor

Car_ID CAR BodyColor

Car color attribute is replaced by three single valued attributes

Mod_Code Car_Year Car_ID Section Color

1 M
Car_ID
Database CAR Has SEC_COLOR
Systems

10
Multivalued attribute replaced by a new entity
 Classes of Attributes
Chapters 4, 6
Entity
Relationship
Modeling  A derived attribute is not physically stored within
the database; its value is computed from other
attributes.
 It is indicated using a dotted line connecting the
attribute with the entity.
 Example: AGE can be derived from DOB and current date.
 Number of years of employment

EMP_NUM EMP_DOB EMP_AGE

Database EMPLOYEE
Systems

11
 Relationships
Chapters 4, 6
Entity
Relationship
Modeling  Relationship
 A relationship is an association between entities.
 Relationships are described as verbs.
 Relationships are represented by diamond-shaped
symbols.
 Example:

Professor Teaches Class

Teaches
Professor Class

Database
Systems

12
 Types of Relationships
Chapters 4, 6
Entity
Relationship
Modeling  A relationship’s degree indicates the number of
entities that participate in the relationship.
 A unary relationship exists when an association is
maintained within a single entity. (Recursive
relationship)
 Example:

Employee

Manages
Manages
Database
Systems

13
 Types of Relationships
Chapters 4, 6
Entity
Relationship
Modeling
 A binary relationship exists when two entities are
associated. (Most common).
 Three entities participate in a ternary relationship.

Author Writes Book

Doctor Prescription Patient

Database
Systems Drug
14
 Connectivity
Chapters 4, 6
Entity
Relationship
Modeling  The term connectivity is used to describe the
relationship classification (e.g., one-to-one, one-to-
many, and many-to-many).
1 M
Professor Teaches Class

One-to-Many relationship

M N
Author Writes Book

Many-to-Many relationship

1 1
Person
Database
One-to-One relationship
Systems
Is marriedto
15
 Connectivity
Chapters 4, 6
Entity
Relationship
Modeling

Professor Class

One-to-Many relationship

Writes
Author Book

Many-to-Many relationship

Person
One-to-One relationship
16
Is marriedto
Database
Systems
 Cardinality
Chapters 4, 6
Entity
Relationship
Modeling  Cardinality expresses the specific number of entity
occurrences associated with one occurrence of the
related entity.
 This is determined by an organization’s business
policy.

1 M
Professor Teaches Class
(0,3) (1,1)

One-to-Many relationship

Teaches
Professor Class
(0,3) (1,1)
Database
Systems One-to-Many relationship
17
 Cardinality
Chapters 4, 6
Entity
Relationship
Modeling

M N
Student Enrolls in Class
(1,6) (5,35)
Many-to-Many relationship

Enrolls in
Student Class

Many-to-Many relationship
Database
Systems

18
 Chen’s Vs. Crow’s Foot Notations
Chapters 4, 6
Entity
Relationship
Modeling

Database
Systems

19
 Cardinality
Chapters 4, 6
Entity
Relationship
Modeling  Implications of Cardinality
 A professor listed in the professor table may appear in the
Class table as few as zero times or as many as 3 times.
Table name: CLASS
Cl_Code Course Sec Time Room ProfNum
10012 AC_211 1 MWF 8:00-8:50 a.m BUS311 105
10013 AC_211 2 MWF 9:00-9:50 a.m BUS200 105
10014 AC_211 3 TTh 2:30-3:45 p.m BUS252 342
10015 AC_212 1 MWF 10:00-10:50 a.m BUS311 301
10016 AC_212 2 Th 6:00-8:40 p.m BUS252 301
10017 CIS-220 1 MWF 9:00-9:50 a.m KLR209 228
10018 CIS-220 2 MWF 9:00-9:50 a.m KLR211 114
10019 CIS-220 3 MWF 10:00-10:50 a.m KLR209 228
10020 CIS-420 1 W 6:30-8:40 p.m KLR209 162
10021 QM-261 1 MWF 8:00-8:50 a.m KLR200 114
10022 QM-261 2 TTh 1:00-2:15 p.m KLR200 114
10023 QM-362 1 MWF 11:00-11:50 a.m KLR200 162
Database
Systems
10024 QM-362 2 TTh 2:30-3:45 p.m KLR200 162

20
 Cardinality
Chapters 4, 6
Entity
Relationship
Modeling  Professor Table
Table name: Professor
ProfNum LName FName Init Dept Office Extn
103 Donelly Ronald O HIST AC220 6783
104 Yukon Preston D ENG AC402E 5561
105 Hefington Arnelle B ACCT BUS229 8665
110 Thieu Van S CHEM PYR200 3412
114 Graztevki Gerald B CIS KLR302 4436
155 Ritula Annelise MATH PYR245 4440
160 Smith Robert T ENG MLL108 2248
162 Rob Peter CIS KLR203 2359
209 Smith Melanie K CIS KLR225 3421
228 Coronel Cartos M CIS KLR203 2359
297 Jones Hermine CHEM PYR356 1145
301 Osaki Ismael K ACCT BUS244 4683
335 Okomoto Ronald F ENG MLL108 3997
342 Smith Robert A ACCT BUS345 5514
387 Smithson James D ACCT BUS229 8665
Database
Systems

21
 Existence Dependence
Chapters 4, 6
Entity
Relationship
Modeling  If an entity’s existence depends on the existence of
one or more other entities, it is said to be existence-
dependent.
 Example:
 CLASS is existence dependent on COURSE - Course code
appears as a foreign key in the Class table
 The implication of existence dependence is that a
Course instance must be created in the Course table
before the corresponding Class instances may be
added to the Class table.

Database
Systems

22
 Relationship Participation
Chapters 4, 6
Entity
Relationship
Modeling  The participation is optional if one entity
occurrence does not require a corresponding entity
occurrence in a particular relationship.
 An optional entity is shown by a small circle on the
side of the optional entity.
 Example: Class is optional to Professor
Professor is mandatory to Class, so every
Class must have a Professor assigned to it.

1 M
Professor Teaches Class
(0,3) (1,1)
Database
Systems

23
 Relationship Participation
Chapters 4, 6
Entity
Relationship  The participation is optional if one entity
Modeling
occurrence does not require a corresponding entity
occurrence in a particular relationship.
 An optional entity is shown by a small circle on the
side of the optional entity.
 Example: Class is optional to Professor
Professor is mandatory to Class, so every
Class must have a Professor assigned to it.
1 M
Professor Teaches Class
(0,3) (1,1)

Database Teaches
Systems Professor Class
24
 Relationship Participation
Chapters 4, 6
Entity
Relationship
Modeling
 Relationship participation depends on the business
rule of the organization.

1 M
Course Creates Class
(0,N) (1,1)

Class is optional to Course, Course is mandatory to Class

1 Creates M
Course Class

Database
Class is optional to Course, Course is mandatory to Class
Systems

25
 Relationship Participation
Chapters 4, 6
Entity
Relationship
Modeling

1 M
Course Creates Class
(1,N) (1,1)

Class is mandatory to Course and Course is mandatory to Class

Creates
Course Class
(1,N) (1,1)

Database Class is mandatory to Course and Course is mandatory to Class

Systems

26
 Weak Entity
Chapters 4, 6
Entity
Relationship
Modeling  A weak entity is one that
 is existence-dependent on another entity and
 has a primary key that is partially or totally derived
from its strong counterpart.
 A weak entity is indicated by a double rectangle.

E_ID Dep_Num
E_ID E_Name
Dep_Name
1 M
Employee Supports Dependent
(0,N) (1,1)

Database
Systems

27
 Weak Entity
Chapters 4, 6
Entity
Relationship
Modeling  Weak entity illustration

Employee Table Dependent Table

E_ID E_Name E_ID Dep_Num Dep_Name
1001 John 1001 1 Jack
1002 Joe 1001 2 Jeb
1003 Jill 1001 3 Jacob
1003 1 Joy
1003 2 Jimmy

Is Class a weak entity in the relationship between Class and Course?

Database
Systems

28
 Relationship Strength
Chapters 4, 6
Entity
Relationship 
Modeling Strong (Identifying)
Relationship
 A strong relationship
exists when the PK of the
related entity contains a
PK component of the
parent entity.
 The child entity is a weak
entity.
 Crow’s Foot model uses a
solid line to connect the
two entities.

Database
Systems

29
 Relationship Strength
Chapters 4, 6
Entity
Relationship 
Modeling Weak (Non-Identifying) Relationship
 A weak relationship exists when the PK of the related entity
does not contain a PK component of the parent entity.
 Crow’s Foot model uses a dashed line to connect the two
entities.

Database
Systems

30
 Recursive Entities
Chapters 4, 6
Entity
Relationship
Modeling  A recursive entity is one in which a relationship can
exist between occurrences of the same entity set.
 A recursive entity is found within a unary
relationship.
 Examples: 1 1
Employee

Is marriedto

Emp_Num Emp_Lname Emp_Fname Spouse

345 Ramirez James 347
346 Jones Anne 349
347 Ramirez Louise 345
348 Delaney Robert
Database
Systems 349 Shapiro Anton 346
31
 Recursive Entities
Chapters 4, 6
Entity
Relationship
Modeling  1:M Recursive relationship

1 M
Employee

Manages

Emp_Code Emp_Lname Emp_Manager

1001 Craighead 1005
1002 Frazier 1005
1003 Grzner 1005
1004 Mahapatra 1005
1005 Sircar

Database
Systems

32
 Recursive Entities
Chapters 4, 6
Entity
Relationship
Modeling  M:N Recursive relationship
M N
Course

COURSE Table Requires

Crs_Code Description Credit
INSY 3302 Bus. Programming 3
INSY 3305 Sys Analysis 3
INSY 4302 Database 3
INSY 4308 Sys Design 3

PREREQ Table
Crs_Code Prereq
INSY 3305 INSY 3302
INSY 4302 INSY 3302
Database
INSY 4308 INSY 3305
Systems INSY 4308 INSY 4302
33
 Composite Entities
Chapters 4, 6
Entity
Relationship
Modeling  A composite entity is often created in the process
of replacing a M:N relationship by a pair of 1:M
relationships.
 The composite entity serves as a bridge between
the related entities.
 Its primary key is composed of the primary keys of
the entities it connects.
 It may contain additional attributes besides the
primary key.
 Example:
Database
Systems

34
 Composite Entities
Chapters 4, 6
Entity
Relationship
Modeling  Example:
M N
Student Enrolls in Class
(1,6) (5,35)
Many-to-Many relationship

C_Id Desc
S_Id Name

1 M M 1
Student Enrolls in Class
(1,6) (1,1) (1,1) (5,35)

S_Id C_Id Grade

Database A pair of 1:M relationships with a Composite entity

Systems

35
 Composite Entities
Chapters 4, 6
Entity
Relationship
Modeling  Example:
M Enrolls in N
Student Class
(1,6) (5,35)
Many-to-Many relationship

C_Id Desc
S_Id Name

Student Enrolls in Class

(1,6) (1,1) (1,1) (5,35)

S_Id C_Id Grade

Database A pair of 1:M relationships with a Composite entity

Systems

36
 Entity Supertypes and Subtypes
Chapters 4, 6
Entity
Relationship 
Modeling Supertype-Subtype relationship (aka ISA relationship, or
Generalization-Specialization hierarchy) was added to the
ER model to create the Enhanced ER model.
 A subtype entity inherits the attributes and relationships of
the supertype entity and has attributes and relationships
unique to itself.
 A subtype entity is created when:
 it has some unique attributes that do not apply to the supertype
entity
 it participates in relationships that do not apply to the
supertype entity
 Supertype-subtype relationship is modeled as a 1:1
relationship in the EER model
Database
Systems

37
 Supertype Subtype Example
Chapters 4, 6
Entity
Relationship
Modeling

Database
Systems

38
 Entity Supertypes and Subtypes
Chapters 4, 6
Entity
Relationship
Modeling  Subtype entities could be disjoint (nonoverlapping)
or overlapping.
 If subtypes are disjoint, then each entity instance of
the supertype can appear in only one of the
subtypes
 Overlapping subtypes may share entity instances

Database
Systems

39
 Entity Supertypes and Subtypes
Chapters 4, 6
Entity
Relationship
Modeling  Completeness constraint specifies whether each
entity supertype instance is required to be a
member of at least one of the subtype
 Total Completeness means that every supertype
occurrence must be a member of at least one
subtype.
 Partial Completeness means that some of the
supertype instances may not be members of any
subtype.

Database
Systems

40
 Supertype Subtype Example
Chapters 4, 6
Entity
Relationship
Modeling

Database
Systems

41