Ch.4.

Entity Relationship Modeling

Chapter 4

Entity Relationship Modeling

Copyright © 2019, 2016, 2013 Pearson Education, Inc. All Rights Reserved

2.1
 Ch.4. Entity Relationship Modeling

Section. 1

Basic Concepts of ER Modeling

2.2
 Ch.4. Entity Relationship Modeling

Why to Use Modeling Language

• Summarizing ideas about information systems design in a standard format

• Clear, effective communications between stakeholder groups
• Updating documents on the design when the design changes
• Therefore, using modeling languages to ensure;

❑ Consistency: visual elements, including shapes, size,

and colors, should have consistent meanings in a diagram
❑ Clarity: visual elements should deliver clear meanings
❑ Simplicity: the entire presentation should be as simple as
possible, without redundancy

2.3
 Ch.4. Entity Relationship Modeling

Database Structure

Does the diagram below provide enough ideas about a database structure?

Database
AdventureWorks

Table Table
Sales.SalesOrderHeader Sales.SalesOrderDetail

Table
Sales.SalesOrderHeaderSalesReason

2.4
 Ch.4. Entity Relationship Modeling

Entity Relationship Model

• A design language or blueprint for a database design

• More generalized, logical, and abstract than a physical

database design

• Providing conceptual understanding on database structure

• Easier to modify and update than a physical database design
• Using entities, attributes, and relationships

2.5
 Ch.4. Entity Relationship Modeling

Clarification on Terminologies

• The following sets of terms concerning E-R modeling are equivalent:

(Table = Relation = File, Column = Attribute = Field, Row = Tuple = Record)
• Although not all tables are relational (i.e., some tables do not have
relations), the terms relation and table (and entity) are often
interchangeably used.

2.6
Ch.4. Entity Relationship Modeling

Section. 2

Entities

2.7
 Ch.4. Entity Relationship Modeling

Terms related to Entity

• Entity
▪ Something that can be uniquely identified and the organization wishes to
maintain in data, such as person, place, or concept
▪ Can be either tangible (e.g., employee, students) or intangible (e.g., job
position, academic course)
▪ The title of an entity is generally for entity type (hence,
interchangeably used with entity type in the context of ER diagrams)

2.8
 Ch.4. Entity Relationship Modeling

Terms related to Entity (cont’d)

• Entity type: collection of entity (or entities) with attributes and hence, often
corresponding to a table (e.g., CUSTOMER)
• Entity instance: a specific example of an entity with some attributes,
corresponding to a row in a table (e.g., CID3)

Entity Type CUSTOMER

(also called, Entity)
customer_id name
CID1 A
CID2 B
CID3 C Entity Instance
CID4 D
CID5 E

2.9
 Ch.4. Entity Relationship Modeling

Entity Type and Entity Instances

FIGURE 2-3 Entity type EMPLOYEE with two instances

Entity type: EMPLOYEE

Attributes Attribute Type Example Instance_1 Example Instance_2

Employee Number CHAR (10) 64217836 53410197

Name CHAR (25) Michelle Brady David Johnson

Address CHAR (30) 100 Pacific Avenue 450 Redwood Drive

City CHAR (20) San Francisco Redwood City

State CHAR (2) CA CA

Zip Code CHAR (9) 98173 97142

Date Hired DATE 03-21-1992 08-16-1994

Birth Date DATE 06-19-1968 09-04-1975

2.10
 Ch.4. Entity Relationship Modeling

Guidelines for Naming Entity Types

• Singular noun without spaces to associate

with its attributes (e.g., Price (entity type) –
ListingPrice & DiscountedPrice (attributes)
• Concise (or abbreviation)
• Specific to organization or business function
• Following naming rules of organization
• Names consistent for all ER diagrams

2.11
 Ch.4. Entity Relationship Modeling

Strong vs. Weak Entities

• Strong Entity
▪ Exists independently from other types of entities
▪ Having its own unique identifier
▪ E.g., adventureworks.sales.SalesOrderHeader
▪ Most common type of entity
▪ Using a dotted line to present the relationship (identifying relationship)

• Weak Entity
▪ Depends on a strong entity and cannot exist on its own
▪ No unique identifier (only a partial identifier)
▪ E.g., adventureworks.sales.SalesOrderHeaderSalesReason
▪ Using a solid line to present the relationship (non-identifying relationship)

2.12
 Ch.4. Entity Relationship Modeling

Strong vs. Weak Entities_ Example

Weak Entity
Strong Entity
No unique identifier
VIN alone can be
for individual vehicles
a unique identifier

2.13
 Ch.4. Entity Relationship Modeling

Supertypes and Subtypes

• Supertype: a generic entity type that has a relationship with one or more subtypes
(e.g., adventureworks.HumanResources.Employee)
• Subtype: a subgrouping of the entities in an entity type that has attributes distinct
from those in other subgroupings (e.g, adventureworks.sales.SalesPerson)

Supertype Entity

Subtype Entities

2.14
Ch.4. Entity Relationship Modeling

Section. 3

Attributes

2.15
 Ch.4. Entity Relationship Modeling

Attributes
• Properties or characteristics of an entity or relationship type
(corresponds to columns in a table)
• Classifications of attributes:
• Identifier (e.g., VIN, EmployeeID)
• Required vs. Optional (e.g., LastName vs. CustomerHobby)
• Simple (atomic) vs. Composite (e.g., FirstName vs. MailingAddress)
• Single-Valued vs. Multivalued (e.g., MaritalStatus vs. CustomerInterests)
• Stored vs. Derived (DateOfBirth vs. Age)
CUSTOMER
Attributes customer_id name
CID1 A
CID2 B
CID3 C
CID4 D
CID5 E

2.16
 Ch.4. Entity Relationship Modeling

Classification of Attributes_ Example

Identifier, required, simple, Optional, simple, single-valued, and

single-valued, and stored attributes derived attributes

Employee First Last DateOf Mailing Employee

Age
ID Name Name Birth Address Skill
A0001 John Harrison 01-01-2000 123 St, City1, TX 21 SQL
A0002 Tom Mitchell 03-12-1997 345 St, City2, TX 24 SQL, Python
A0003 Cindy Underwood 11-14-1988 456 St, City3, TX 35

Required, composite, single- Optional, multi-valued,

valued, and stored attributes and stored attributes

• Is there any unnecessary or redundant attribute? If so, why is it redundant?

• Which attributes requires further data processing to be used for data analysis and why?

2.17
 Ch.4. Entity Relationship Modeling

Why Entity and Attribute Important for Data Analysts

• When preparing data for analysis, data analysts should;

▪ Understand the nature of attributes to find errors (e.g., max. and min. values)

▪ Define or develop an unique identifier for each row (e.g., customer ID vs. order ID)

▪ Divide multivalued attributes into single valued attributes (e.g., year from date)

▪ Create attributes from available attributes (e.g., profit = revenue – cost)

▪ Operationalize measures, using attributes (e.g., benefit → financial profit)

2.18
 Ch.4. Entity Relationship Modeling

Functional Dependency

• A functional dependency occurs when the value of one (set of) attribute(s)
determines the value of a second (set of) attribute(s):
▪ StudentID - StudentName
▪ StudentID - (DormName, DormRoom, DormFee)

• The attribute on the left of the functional dependency is called the determinant
• Functional dependencies could rely on equations:

▪ Quantity * UnitPrice = TotalPrice

▪ ListPrice – PriceDiscount = PromoPrice

ListPrice and DiscountedPrice

determine PromoPrice

2.19
 Ch.4. Entity Relationship Modeling

Functional Dependency_ Example

Determines

EmployeeID FirstName LastName

A0001 John Harrison

A0002 John Mitchell
A0003 Cindy Underwood

DOES NOT determine

• EmployeeID uniquely determines FirstName (i.e., determinant)

while FirstName does not do so for EmployeeID (i.e., FirstName
has a functional dependency on EmployeeID)

2.20
 Ch.4. Entity Relationship Modeling

Composite Determinants

• A determinant of a functional dependency that consists of more

than one attribute

▪ (StudentID, CourseNumber) (Grade)

▪ (ItemNumber, Date) (DailySales)

2.21
 Ch.4. Entity Relationship Modeling

Why Functional Dependency Matters?

• When updating an attribute, other attributes, which have functional

dependency with the attribute, may be impacted (e.g., change in revenue or cost
affects profit)
• To enhance database efficiency, reducing redundant attributes, an attribute
can be removed if it is reproducible by using other attributes (e.g., removing
profit when revenue and cost are available)
• When conducting data normalization for multiple data tables, it is important
to understand their functional dependencies between tables

2.22
 Ch.4. Entity Relationship Modeling

Data Normalization and Functional Dependency_ Example

CUSTOMER ORDER ORDER

Order Order Customer Customer Customer Order Order Customer
ID Date ID Name Address ID Date ID
OD1 20220929 C1
OD1 20220929 C1 Nick address_1
OD2 20220929 C2
OD2 20220929 C2 Tom address_2 OD3 20220929 C3
OD4 20220929 C4
OD3 20220929 C3 Harry address_3 OD5 20220930 C1
OD4 20220929 C4 Andrea address_4 OD6 20220930 C2
OD7 20220930 C3
OD5 20220930 C1 Nick address_1
OD8 20220930 C4
OD6 20220930 C2 Tom address_2
CUSTOMER
OD7 20220930 C3 Harry address_3 Customer Customer Customer
OD8 20220930 C4 Andrea address_4 ID Name Address
C1 Nick address_1
C2 Tom address_2
C3 Harry address_3
C4 Andrea address_4
Due to the functional dependency of Customer Name
and Customer Address on Customer ID, “CUSTOMER
ORDER” can be divided into “ORDER” and
“CUSTOMER”, reducing data redundancy

2.23
Ch.4. Entity Relationship Modeling

Section. 4

Keys

2.24
 Ch.4. Entity Relationship Modeling

Keys
• Key: one or combination of more than one attribute to identify rows in a relation
• Composite key: the key that consists of two or more attributes
• Candidate key: the key that can determine other attributes in a relation
• Primary key: a candidate key selected as the primary means of identifying rows
in a relation;

▪ There is only one primary key per relation

▪ The primary key may be a composite key
▪ The ideal primary key is short, numeric (or combination
of number and alphabet), and never changes

2.25
 Ch.4. Entity Relationship Modeling

Candidate Key vs. Primary Key_ Example

• What are candidate keys in PURCHASING.VENDOR?
• Given PURCHASING.PRODUCTVENDOR, which of the candidate keys is ideal
for primary key and why?

PURCHASING.VENDOR
BusinessEntityID AccountNumber Name CreditRating PreferredVendorStatus
1492 AUSTRALI0001 Australia Bike Retailer 1 1
1494 ALLENSON0001 Allenson Cycles 2 1
1496 ADVANCED0001 Advanced Bicycles 1 1
1498 TRIKES0001 Trikes, Inc. 2 1

PURCHASING.PRODUCTVENDOR
ProductID BusinessEntityID AverageLeadTime StandardPrice LastReceiptCost
1 1492 17 47.87 50.26
2 1494 19 39.92 41.92
4 1496 17 54.31 57.03
317 1498 19 28.17 29.58

2.26
 Ch.4. Entity Relationship Modeling

Foreign Key

• The primary key of one relation that is placed in another relation to form a link
between the relations (used for combining multiple tables)
• Either a single key or a composite key

▪ DEPARTMENT (DepartmentCode, BudgetCode, ManagerID)

▪ EMPLOYEE (EmployeeID, EmployeeLastName, EmployeeFirstName,
DepartmentCode)
Primary Key
Foreign Key

▪ DepartmentCode (foreign key) can be used to find BudgetCode and ManagerID in

DEPARTMENT table (c.f., EmployeeID is the primary key)

2.27
 Ch.4. Entity Relationship Modeling

Surrogate Key
• An artificial attribute added to a relation to serve as primary key
▪ Supplied (or generated) by DBMS (Database Management Systems)
▪ Short, numeric, and never changes—an ideal primary key
▪ Has artificial values that are meaningless to users
▪ Normally hidden in forms and reports because it is hard to understand
▪ E.g., product bar code, Amazon ASIN code, etc.

• Providing a concise primary key for an entity

Need four attributes
▪ RENTAL_PROPERTY WITHOUT surrogate key:
RENTAL_PROPERTY (Street, City, State, ZipCode, Rental_Rate)

▪ RENTAL_PROPERTY WITH surrogate key:

RENTAL_PROPERTY (PropertyID, Street, City, State, ZipCode, Rental_Rate)

Need only one attribute

2.28
 Ch.4. Entity Relationship Modeling

Integrity Constraints (1 of 3)
• Set of constraints or rules that limit acceptable values and actions for attributes
• Used to maintain accuracy and integrity of data in the database
• Domain Constraints
▪ A set of possible values that may be assigned to an attribute
▪ Values in a column of a relation must meet the column (i.e., attribute) definitions
▪ Usually consists of domain name, meaning, data type, size, and allowable range

Domain Constraints for Entity type STUDENT STUDENT

STUDENT ID Semester Age
Attribute Domain Name Domain 1000 1st 34
ID Student ID Int(4) 1001 2nd 23 NOT allowable
Semester Semester of student Char(5) 1002 3rd 29
Age Demographic age Int(4) 1003 4th Thirty
1004 5th 22

2.29
 Ch.4. Entity Relationship Modeling

Integrity Constraints (2 of 3)

• Entity Integrity
Entity integrity is concerned with a primary key;
▪ Every relation has a primary key (otherwise, weak entity)
▪ Data values for the primary key are all valid
▪ Every primary key attribute is NOT null

ID Semester Age
1000 1st 34
1001 2nd 23
ID (primary key) 1002 3rd 29
should not be Null
NULL 4th 30
1004 5th 22

2.30
 Ch.4. Entity Relationship Modeling

Integrity Constraints (3 of 3)
• Referential Integrity Constraints
▪ The statement that limits the values of the foreign key to those already existing
as primary key values in the corresponding relation
▪ E.g., CustomerID must have the same constrains in the both relations to identify
customers from one to another relation (e.g., only four numbers or combination
of two letters and four numbers)

Foreign Key Primary Key

OrderID CustomerID CustomerID FirstName LastName

OD1000 CID1000 1000 Michael Jordan
OD1001 CID1001 1001 Scottie Pippen
OD1002 CID1002 1002 Stephen Curry
OD1003 CID1003 1004 Tim Duncan
OD1004 CID1004 1005 Tony Parker

DO NOT match to the primary key

2.31
 Ch.4. Entity Relationship Modeling

Section. 5

Types of Relations in ER Modeling

2.32
 Ch.4. Entity Relationship Modeling

Relationships

• Entities can be associated with one another in relationships

• All relations have minimum and maximum cardinality constraints
• According to the number of entities involved in a relation, relations
have different degrees of relations, such as unary, binary, or ternary

2.33
 Ch.4. Entity Relationship Modeling

Relationships: Cardinality

• Literally means “the number of elements in a set”

• Cardinality Constraints: the number of instances of one entity that can
or must be associated with each instance of another entity
▪ Minimum cardinality – the minimum number of entity instances
that MUST participate in a relationship
▪ Maximum cardinality–the maximum number of entity instances
that CAN participate in a relationship

2.34
 Ch.4. Entity Relationship Modeling

Relationships: Minimum Cardinality

• Minimums are generally stated as either zero or one:

▪ IF ZERO [ ] THEN participation in the relationship by the entity is optional,

and no entity instance may participate in the relationship
▪ IF ONE [ ] THEN participation in the relationship by the entity is
mandatory, and at least one entity instance must participate in the
relationship

Employee can be assigned to NO project,

while project must have at least ONE employee

2.35
 Ch.4. Entity Relationship Modeling

Relationships: Maximum Cardinality

• Maximums are generally stated as one or many:

▪ IF ONE [ ] THEN ONLY ONE entity instance participates in relationship

▪ IF MANY [ ] THEN MORE THAN ONE entity instances participate in
the relationship
Many

One

Customer can submit more than one orders,

while an order can be made by no more than one customer

2.36
 Ch.4. Entity Relationship Modeling

Relationship Cardinality Notations and Examples

Read the relations 1 and 2!

2.37
 Ch.4. Entity Relationship Modeling

Table to Relation

ORDER CUSTOMER
Order Order Customer Customer Customer Customer
ID Date ID ID Name Address
OD2 20220929 C2 C1 Nick address_1
OD3 20220929 C3 C2 Tom address_2
OD4 20220929 C4 C3 Harry address_3
OD5 20220930 C1 C4 Andrea address_4
OD6 20220930 C2
OD7 20220930 C3
OD8 20220930 C4

Made by
ORDER CUSTOMER
Makes

2.38
 Ch.4. Entity Relationship Modeling

Relationships
• One-to-One: each entity in the relationship will have exactly one related entity
• One-to-Many: an entity on one side of the relationship can have many related
entities, but an entity on the other side will have a maximum of one related entity
• Many-to-Many: entities on both sides of the relationship can have many related
entities on the other side

Many-to-Many

One professor must be qualified for one or more than one course,
while one course must be associated with one or more than one professor

2.39
 Ch.4. Entity Relationship Modeling

Degree of Relationship

• Unary (degree one): entities of the same entity type related to each other
• Binary (degree two): entities of one type related to entities of another
(most common)
• Ternary (degree three): entities of three different types involved in the
same relationship

Degrees of Relationships (Figure 2-2)

2.40
 Ch.4. Entity Relationship Modeling

Degree of Relationship_ Examples

• Unary (degree one)

c.f., Shipping Mode and Unit

Price are not an entity but
attributes involved in the
relationship, “Supplies”
• Binary (degree two) • Ternary (degree three)

2.41
 Ch.4. Entity Relationship Modeling

References

• The major contents of this note are reproduced from the textbook of BCIS 5420;
Topi et al. Modern Database Management. 13 th edition. Pearson's, 2019

• Unless having a specific reference source, the photos and icons used in this
material are from the following sources providing copyright free images:
imagesource.com, iconfinder.com, and pexels.com

• The diagrams used are from the textbook publisher’s materials

2.42