Lecture 3 ER Design
Lecture 3 ER Design
Lecture 3 ER Design
E-R Model to
Relational Tables
COMP3278A
Introduction to Database Management Systems
Dr. Ping Luo
Email : [email protected]
Department of Computer Science, The University of Hong Kong
E-R Design
Decision
Entity sets v.s. Attributes
How do you model an employee and his phone
number?
Treat phone number as an attribute of an employee.
Treat phone as a separate entity.
phone
phone
phone
A loan is an object in
this phrase.
Can we have joint loan?
(E.g., Do we need to express something like “A loan
can be associated with multiple customers”)
Entity sets v.s. Relationship sets
customer
borrower
customer address
first_name
name
last_name
Many to many
One to many / many to one
One to one
Relationship sets
A many‐to‐many relationship set is a table with
columns for the primary keys of the participating entity
sets, and any attributes of the relationship set.
sponsor_id
team_id sponsor_date
car_number ownership_date
name phone
customer employee
Specialization (method 2)
Form a table for each entity set with all local and
inherited attributes.
Person(name, street, city)
Customer(name, street, city, credit_rating) name
customer employee
Specialization
Observation: If the specialization is total, the
generalized entity set may not require a table!
Person(name, street, city)
Customer(name, street, city, credit_rating) name
ISA Disjoint
credit_rating salary
customer employee
Section 3.3
Foreign Key
Example 1
Example 1
To transform an ER model to
relational tables…
Step 1. Entity set -> table
Course (course code, name) Each entity set becomes a table.
Each attribute becomes a column.
Each entity is a tuple in the table.
Option 2
Customer (customerID, name)
Foreign key: none
Handling ISA relationship VIP (customerID, name, discount_rate)
Option 2 : Foreign key: {customerID} referencing Customer
Member (customerID, name, accumulated_points)
Form a table for each entity
Foreign key: {customerID} referencing Customer
set with all local and inherited
attributes
Example 3
Option 1
[Storage] Option 1 has less Customer (customerID, name)
storage redundancy. Foreign key: none
[Efficiency] Accessing data (e.g, VIP (customerID, discount_rate)
retrieving the name and Foreign key: {customerID} referencing Customer
discount_rate of a VIP) in option Member (customerID, accumulated_points)
1 requires accessing two tables Foreign key: {customerID} referencing Customer
(not as efficient as option 2,
which requires accessing one
table only)! Option 2
Customer (customerID, name)
Foreign key: none
VIP (customerID, name, discount_rate)
Foreign key: {customerID} referencing Customer
What are the advantage
Member (customerID, name, accumulated_points)
and disadvantage of these Foreign key: {customerID} referencing Customer
Example 3
Option 1
Customer (customerID, name)
Foreign key: none
Total VIP (customerID, discount_rate)
specialization Foreign key: {customerID} referencing Customer
Member (customerID, accumulated_points)
Foreign key: {customerID} referencing Customer
Option 2
Customer (customerID, name)
Foreign key: none
Option 3 VIP (customerID, name, discount_rate)
VIP (customerID, name, discount rate) Foreign key: {customerID} referencing Customer
Foreign key: none Member (customerID, name, accumulated_points)
Member (customerID, name, Foreign key: {customerID} referencing Customer
accumulated points)
Foreign key: none
Example 4
Handling Multivalue
attributes
Multivalue attribute
becomes a table.
Customer (customerID, name)
Foreign key: none
END
COMP3278A
Introduction to Database Management Systems
Dr. Ping Luo
Email : [email protected]
Department of Computer Science, The University of Hong Kong