Database Design

Entity-relationship Model
(ER model)

1
 Database design
• The database design process can be
divided into six steps.
1. Requirement Analysis
– What data should be stored?
– What applications must be built?
– What operations are most frequent and subjected
to performance requirements?

2
2. Conceptual database design
– High-level description of
 Data to be stored
 Constraints
– Often carried out using the ER model
3. Logical Database design
– Choose a DBMS to implement our database
design.
– Convert the conceptual database design into a
database schema for the chosen DBMS.
– Convert ER schema into a relational database schema.

3
4. Schema Refinement
– Analyze the collection of relations in our
relational database.
– Identify the potential problems.
– Refine the schema.
5. Physical database design
– Ensure that the design meets the performance
requirement.
– Build index, clustering some tables etc.
– Redesign parts of the database schema.

4
6. Application and security design
– Write application programs.
– Identify data that can be accessible by certain
types of users.
– Take steps to ensure that access rules are
enforced.

5
 Entity-Relationship Model
• Entity-Relationship (ER) model is a popular
conceptual data model.
• This model is used in the design of database
applications.
• The model describes data to be stored and
the constraints over the data.

6
 Entities and attributes
• E-R model views the real world as a
collection of entities and relationships
among entities.
• An entity is an object in the real world that
is distinguishable from other objects.
– Examples
• A classroom
• A teacher
• The address of the teacher

7
• An entity is described using a set of
attributes whose values are used to
distinguish one entity from another of the
same type.
name = Chan Tai Man

address = 25, Siu Road, Shatin

age = 55

phone = 1234-5667

8
• An entity set is a collection of entities of the
same type.

e1
(Chan Tai Man, 55, …)

e2
(Cheung Tin, 20, …)

e3
(Wong King, 33, …)

9
• All entities in a given entity set have the
same attributes ( the values may be
different).
employee = (name, address, age, phone)

employee 1 employee 2

name = Chan Tai Man name = Cheung Tin

address = 25, Siu Road, Shatin address = 25, Big Street, Shatin

age = 55 age = 20
phone = 1234-5667 phone = 2338-7779

10
• For each attribute associated with an entity
set, we must identify a domain of possible
values.
– Example
• The domain associated with the attribute name
might be the set of 20-character strings.
• The domain associated with the attribute age might
be an integer.

11
 Entity-Relationship diagram
(E-R diagram)
• The E-R model can be presented graphically
by an E-R diagram.

age
age address
address

phone
phone
name
name

Employee
Employee attribute

entity
12
 Key
• A superkey is any set of attributes which
can uniquely identify an entity.
• A key is a minimal set of attributes whose
values uniquely identify an entity in the set.
• A key is also called a candidate key.
• There could be more than one candidate
key.
• A primary key is a candidate key chosen to
serve as the key for the entity set.
13
 Key
• A superkey is any set of attributes which
can uniquely identify an entity. No proper subset of the
attributes can be a superkey
• A key is a minimal set of attributes whose
values uniquely identify an entity in the set.
• A key is also called a candidate key.
• There could be more than one candidate
key.
• A primary key is a candidate key chosen to
serve as the key for the entity set.
14
 • A key may contain more than one attribute.

lecturer = M.H.Wong location

location

date
date
course code = CSCI3170 course-code
course-code
C1 location = LSB L1 time
time
lecturer
lecturer
date = 9 Sep 2019

time = 10:30am Lecture

Lecture

• For example, {location,date,time} is a key.

• {lecturer, date, time} is also a key.
• {lecturer, location, date, time} is not a key,
but it is a superkey.
15
• The key should depend on the real life
possibility rather than on the current set of
the data.
• For example, in the previous database
which contains only two employees (p.10),
the age can distinguish each employee.
However, we may get a new employee with
the same age as an existing employee.

16
• Usually, we need to add an extra attribute as
a key.
The primary key is
underlined
employee 1

name = Chan Tai Man ID

ID

age
age
address = 25, Siu Road, Shatin address
address
ID = A234980 phone
phone
name
name
age = 55

phone = 1234-5667 Employee

Employee

17
 Relationships
• A relationship is an association among two
or more entities.
Example:
E1 = {John, Ada, David, Peter}
E2 = {CSC1234, CEG4567, ERG6677, CSC3399}

Lectuer course
teach

John CSC1234

Ada CEG4567

David ERG6677

Peter CSC3399
18
• Relationship: teach
(John,CEG4567), (David, CSC1234),(David,CSC3399)
• As with entities, we may wish to collect a
set of similar relationships into a
relationship set.
• A relationship set can be thought of a set of
n-tuples:
{(e1 , , en ) | e1  E1 ,  en  En }
• The teach relation can be represented by the
set:
{(John,CEG4567), (David, CSC1234),(David,CSC3399)}

19
• A relationship set can also be represented
by an E-R diagram.

hkid
hkid Phone_no
Phone_no

name address
address
name Course_id
Course_id title
title

attribute Lecturer
Lecturer Teach
Teach course
course

entity relationship

20
• A relationship can also have descriptive
attributes.
• Descriptive attributes are used to record
information about the relationship, rather
than about any one of the participating
entities. Attribute of the relationship
Since
Since
(date)
(date)
ID
ID Phone_no
Phone_no

Name
Name Address
Address did
did dname
dname

Employees
Employees Work_in
Work_in Departments
Departments
21
• A relationship must be uniquely identified
by the participating entities, without
reference to the descriptive attributes.
• In the previous example, each relationship
must be uniquely identified by the
combination of the employee hkid and the
department did.
• Thus, for each employee-department pair,
we cannot have more than one associated
“since” value.
22
• Suppose now each department has offices in several
locations and we want to record the locations at which
each employee works.
• This relationship is ternary (degree=3).
Since
Since
(date)
(date)
ID
ID Phone_no
Phone_no

Name
Name Address
Address did
did dname
dname

Employees
Employees Work_in
Work_in Departments
Departments

address
address Locations
Locations capacity
capacity
23
• Recursive Relationship
– Entity sets of a relationship need not be distinct.
– Sometimes a relationship might involve two
entities in the same entity set.
ID
ID Phone_no
Phone_no

Name
Name Address
Address

Employees
Employees

supervisor subordinate

Reports_to
Reports_to
24
• Since employees report to other employees
– Every relationship in Reports_To is of the form
(emp1,emp2), where both emp1 and emp2 are
entities in employees.
– However, they play different roles.
• emp1 reports to emp2, which is reflected in the role
indicators supervisor and subordinate in the
previous diagram.

25
 Key constraints
(mapping constraints)
• The mapping of the relationship can be
classified into the following cases:

1-to-1 1-to Many Many-to-1 Many-to-Many

26
• One-to-many
– One-to-many constraint from A to B: an entity in B can
be associated with at most one entity in A.
– Each child can appear in at most one mother-child
relationship.

Woman Child
Mother-of

Lisa Susan

Rose Mike

Cathy Cindy

Tina Eddie

27
• Child has a key constraint in the mother-of
relationship set.
• This restriction can be indicated by an
arrow in the E-R diagram.
Note: the arrow is always
pointing from an entity to a
relationship.
hkid
hkid age
age

name address
address
name hkid
hkid name
name

Mother
Mother Mother-of
Mother-of Child
Child

Intuitively, the arrow states that given a child entity, we can uniquely determine
the mother-of relationship. 28
• Many-to-one
– Similar to one-to-many

ID
ID Phone_no
Phone_no

Name
Name Address
Address did
did dname
dname

Employees
Employees Work_in
Work_in Departments
Departments

Each employee belongs to one department and a department may have

many employees.
29
• One-to-one
– If the relationship between A and B satisfies the one-to-
one mapping constraint from A to B, then an entity in A
is related to at most one entity in B, and an entity in B
is related to at most one entity in A.

EMPLOYEE DEPARTMENT
MANAGES

30
 ID
ID Phone_no
Phone_no

Name
Name Address
Address did
did dname
dname

Employees
Employees manages
manages Departments
Departments

An employee can associate with at

most one department via the relationship
“manages”.
A department can associate with at most
one employee via the relationship
“manages”

31
• Many-to-many
– An entity in A is associated with any number of
entities in B, and an entity in B is associated
with any number of entities in A.
– In fact, it means that there is no restriction in
the mapping
CUSTOMER BORROWER LOAN

32
 ID
ID street
street

name
name city
city loan-number
loan-number amount
amount

Customer
Customer Borrower
Borrower Loan
Loan

• A customer can associate with several loans (possibly 0)

via Borrower
• A loan can associate with several customers (possibly 0)
via Borrower

33
 Keys for a relationship set
• The concept of keys is also used to identify a
relationship, as in entities.
• There are different cases:
– Many-to-many
For a relationship among E1, …, Ek, with no mapping
constraint, the primary key is normally the union of
the primary keys for E1, …, Ek.

– e.g. {ID,loan_number} is the key for borrower. (p.33)

34
– 1-to-many or many-to-1
• An entity set E has a key constraint in a relationship
set R, such that each entity in an instance of E
appears in at most one relationship in the instance of
R.
• Hence an entity in E can uniquely identify a
relationship in R. Thus, the key of E can be used as
the key in R.
e.g. child-mother (p.28): is a many-to-one
relationship, where entity Child has a key constraint.
– Child can be the primary key in the relationship set.

35
– One-to-one
• For a one-to-one relationship between two entity
sets E and F, key(E) and key(F) are both keys for the
relationship set.
• e.g. “manages” relation (p.31): both {ID} and {did}
are the keys of the relation.

36
 Participation constraints
• The key constraint on Manages (p.30) tells
us that a department has at most one
manager.
• A natural question to ask is whether every
department has a manager.
• Suppose every department is required to
have a manager. Such a constraint is an
example of participation constraint.

37
• In short, a participation constraint imposes
some requirements on the number of times
an entity participates in a relationship.
• We can classify participation in
relationships as follows:
– total - each entity in the entity set must
participate in at least one relationship.
– partial - an entity in the entity set may not
participate in a relationship.

38
• E.g. Every employee must work for some
department. The participation of EMPLOYEE in
WORKS-FOR is total participation

EMPLOYEE WORK-FOR DEPARTMENT

39
 ID
ID Phone_no
Phone_no

name
name address
address dept-number
dept-number dept-name
dept-name

Employee
Employee WORK-FOR
WORK-FOR Department
Department

If the participation of an entity set in a relationship set is total,

the two are connected by a thick link; independently, the
presence of an arrow indicates a key constraint.

In this case, the thick line means every employee has to participate
in the work-for relationship.
i.e., every employee has to work for some departments (at least one department).
40
 Weak Entities
• Strong entity
– An entity which has a super key.
– Each entity can be distinguished from other
entities in the same set.
• Weak entity
– Without super key.
– May not be able to distinguish themselves from
others without associations with entities in
other entity sets.
41
• Example
– Suppose employees can purchase insurance policies to
cover their dependents.
– The attributes of the dependents entity set are pname
and age.
– The attribute pname does not identify a dependent
uniquely.
– Dependents is a weak entity set.
– A dependent entity can only be identified by
considering some of its attributes in conjunction with
the primary key of employee (identifying owner).
– The set of attributes that uniquely identify a weak entity
for a given owner entity is called a partial key.

42
 cost
cost
Broken line indicates that pname
ID
ID Phone_no
Phone_no is a partial key for dependents.

name
name address
address pname
pname age
age

Employee
Employee Policy
Policy Dependents
Dependents

To underscore the fact

that Dependents is a weak
entity and Policy is its
The arrow from Dependents to Policy indicates that each Dependents
identifying relationship, we
entity appears in at most one Policy relationship. The arrow is thick
draw both with dark lines.
because of the total participation constraint.

43
 Non-binary relationship set
• Suppose n ≥ 2, for E1, E2, ..., En,
SUPPLIER
SUPPLY PROJECT sname pname
sname pname

Supplier
Supplier Supply
Supply Project
Project

part-ID
part-ID

Part
Part

PART

44
• A relationship set is a subset of

• n = the degree of the relationship set

• In general, a non-binary relationship set
cannot be replaced by a number of binary
relationship sets.
• Consider supplier s, project j, and part p,
– Existence of (s,p), (j,p) and (s,j), where s in
SUPPLIER, p in PART, j in PROJECT, does
not imply existence of (s,j,p) necessarily.
– This is known as the connection trap

45
 s1 j1
SUPPLIER s2 j2

s1 SUPPLY
PROJECT
s2
j1 p1 s1
j2 p2 s2
p1
p2

PART p1 j1
p2 j2

46
 Class Hierarchies
• Sometimes it is natural to classify the
entities in an entity set into subclasses.
name
name
ID
ID address
address

Employees
Employees

Hour_worked
Hour_worked Contract_ID
Contract_ID
Hour_wages
Hour_wages ISA
ISA

Hourly-Emps
Hourly-Emps Contract_Emps
Contract_Emps
47
• Attributes are inherited by the entity set in
the subclass.
– E.g. the attributes defined for an
Hourly_Emps entity are the attributes for
Employees plus that of Houly_Emps.
• A class hierarchy can be viewed in one of
the two ways.
1. A class is specialized into subclasses.
2. The subclasses are generalized by a
superclass.

48
• We can specify two kinds of constraints
with respect to ISA hierarchies,
– Overlap constraints
• Determine whether two subclasses are allowed to
contain the same entity.
E.g. Can an employee be an Hourly_Emps as well
as a Contract_emps entity?
– Covering constraints
• Determine whether the entities in the subclasses
collectively include all entities in the superclass.
E.g. Does every Employee entity also have to be an
Hourly_Emps or a Contract_emps.

49
• Reasons for using hierarchy:
– Add descriptive attributes that make sense only
for the entities in a subclass.
• E.g. Hourly_wages does not make sense for a
Contract_Emps entity.
– Identify the set of entities that participate in
some relationship.
• E.g. we might wish to define the manages
relationship so that the participating entity sets are
Senior_Emps and Departments to ensure that only
senior employees can be managers.

50
 Aggregation
• Sometimes, we have to model a relationship
between a collection of entities and relationships.
• Aggregation allows us to indicate that a
relationship set (identified through a dashed box)
participates in another relationship set.
• Example
– Suppose we have an entity set called projects.
– Each projects entity is sponsored by one or more departments.
– A department that sponsors a project might assign employees to
monitor the sponsorship.
– Intuitively, monitors should be a relationship set that associates a
Sponsors relationship (rather than a projects or departments entity)
with an Employees entity.
51
 name
name
ID
ID address
address

Employees
Employees

Monitors
Monitors until
until

started-on
started-on dname
dname
pid
pid pbudget
pbudget did
did budget
budget

Projects
Projects Sponsors
Sponsors Departments
Departments

52
 Conceptual Design with
the E-R model
• Developing an ER diagram presents several
choices, including the following:
– Should a concept be modeled as an entity or an
attribute?
– Should a concept be modeled as an entity or a
relationship?
– What are the relationship sets and their
participating entity sets? Should we use binary
or ternary relationships?
– Should we use aggregation?

53
• Entity versus Attribute
– Should address be an attribute of Employees or
an entity (connected to Employees by a
relationship)?
1.If we have several addresses per employee,
address must be an entity (attributes cannot
be set-valued)
2.If the structure (city, street, etc) is important,
e.g. want to retrieve employees in a given
city, address must be modeled as an entity
(attribute values are atomic)

54
• Should duration of an employee working in a
department be an attribute or an entity?

from
from to
to
name
name dname
dname
ID
ID address
address DID
DID budget
budget

Employees
Employees WORK-FOR
WORK-FOR Departments
Departments

• This ER model does not allow an employee to

work in a department for two or more periods.
– Because a relationship is uniquely identified by the
participating entities.
55
• The problem can be addressed by
introducing an entity set called Duration.

name
name dname
dname
ID
ID address
address DID
DID budget
budget

Employees
Employees WORK-FOR
WORK-FOR Departments
Departments

from
from Duration
Duration to
to

56
• Entity versus Relationship
– Suppose each department manger is given a
discretionary budget (dbudget).

since
since dbudget
dbudget
name
name dname
dname
ID
ID address
address DID
DID budget
budget

Employees
Employees Manages
Manages Departments
Departments

– This approach is natural if we assume that a

manager receives a separate discretionary
budget for each department.
57
• What if the discretionary budget is a sum
that covers all departments managed by that
employee?
– In this case, each manages relationship that
involves a given employee will have the same
value in the dbudget field, leading to redundant
storage of the same information.
– It is also misleading; it suggests that the budget
is associated with the relationship, when it is
actually associated with the manger.

58
 name
name
ID
ID address
address

Employees
Employees

Since
Since
dname
dname
ISA
ISA DID budget
DID budget

dbudget
dbudget Managers
Managers Manages
Manages Departments
Departments

• We can address the problem by introducing a new

entity set called managers by the ISA hierarchy.
59
• Binary versus Ternary Relationships
– The following ER diagram models the situation that an
employee can own several policies, each policy can be
owned by several employees, and each dependent can
be covered by several policies.

name
name
ID
ID address
address pname
pname age
age

Employees
Employees Covers
Covers Dependents
Dependents

policyID
policyID
policy
policy
cost
cost

60
• Suppose we have the following additional
requirements:
– A policy cannot be owned jointly by two or
more employees. (Impose a key constraint on
Policies with respect to Covers, but it
introduces a side effect that each policy can
cover only one dependent).
– Every policy must be owned by some
employee. (Impose a total participation
constraint on Policies, it is acceptable if each
policy covers at least one dependent).
– Dependents is a weak entity set, and each
dependent entity is uniquely identified by
taking pname in conjunction with the policyid
of a policy entity.
61
• Here is a solution

name
name
ID
ID address
address pname
pname age
age

Employees
Employees Dependents
Dependents
Purchaser
Purchaser Beneficiary
Beneficiary

policyID
policyID
policies
policies
cost
cost

62
• Aggregation versus Ternary Relationships

name
name
ID
ID address
address

Employees
Employees

Monitors
Monitors until
until

started-on
started-on dname
dname
pid
pid pbudget
pbudget did
did budget
budget

Projects
Projects Sponsors
Sponsors Departments
Departments

63
• According to the previous ER diagram:
– A project can be sponsored by any number of
departments,
– A department can sponsor one or more projects,
– Each sponsorship is monitored by one or more
employees.

64
• If we don’t need to record the until attribute of
Monitors, we might use a ternary relationship.
name
name
ID
ID address
address

Employees
Employees
started-on
started-on dname
dname
pid
pid pbudget
pbudget did
did budget
budget

Projects
Projects Sponsors
Sponsors Departments
Departments

• However, this design cannot express the constraint

that each sponsorship can be monitored by at most
one employee.
65
• If aggregation is used, it is easy for us to draw an
arrow from the aggregated relationship sponsors
to the relationship monitors.
name
name
ID
ID address
address

Employees
Employees

Monitors
Monitors

started-on
started-on dname
dname
pid
pid pbudget
pbudget did
did budget
budget

Projects
Projects Sponsors
Sponsors Departments
Departments

66