CHAPTER 4

DATABASE DESIGN
CREATING A BLUEPRINT WITH AN ERD
• UNARY
• BINARY
• TERNARY
 BLUEPRINT?
If you have ever watched a house being built, or if you
have ever had an addition put onto an existing house,
you know that the standard method of communication is
a big piece of paper called a blueprint. Blueprinting is
the standard method used to copy large architectural
and construction drawings.
 Terms
Entity
A data entity is anything real or abstract about which we want
to store data. Entity types fall into five classes: roles, events,
locations, tangible things or concepts. E.g. employee,
payment, campus, book. Specific examples of an entity are
called instances. E.g. the employee John Jones, Mary
Smith's payment, etc.

Relationship
A data relationship is a natural association that exists
between one or more entities. E.g. Employees process
payments. Cardinality defines the number of occurrences of
one entity for a single occurrence of the related entity. E.g. an
employee may process many payments but might not
process any payments depending on the nature of her job.
Entity Relationship Diagram (ERD)
 The Types
• Chen
– Emphasis on modelling
• Crow's Foot
– UML
• Both of these focus more on design and
implementation
• In reality you can implement your DB from
either one.
Attributes Examples
Crow’s Foot Notation

Database Systems, 9th Edition

 How to read the notation?

• ''Professor teaches 0 to 3 classes'' is the relationship

• To get the participation you read backwards: ''Class is
optional to professor''
• ''A class is taught by 1 professor'' is the relationship
• Participation: ''Professor is mandatory to class''
 Crow’s Foot Diagram (optional)

• Some COURSEs are offered only once a year and

do not generate a CLASS each semester.
 Crow’s Foot Diagram (mandatory)

• This condition is created by the constraint that is

imposed by the semantics of the statement “Each
COURSE generates one or more CLASSes”.
• In ER terms, each COURSE in the “generates”
relationships must have at least one class. Therefore,
a class must be created as the COURSE is created in
order to comply with the semantics of the problem.
Entity Relationship Diagram (ERD)
• Database design tool.
• Uses symbol to indicate entity sets,
relationships and relationship types.
• Why need ERD?
– Easily read
– Easily organized
– Easily expanded
ERD Symbols & Designs
ERD Symbols

Entity Examples:
Connectivity

1 M
Relationship CUSTOMER generates INVOICE
(1,1) (1,N)

Composite Entity Cardinality

1 1
EMPLOYEE generates PILOT
Optionality (0,1) (1,1)

Weak Entity
1 M M 1
EMPLOYEE EDUCATION DEGREE
(0,N) (1,1) (1,1) (1,N)
 An ERD Methodology
1. Identify Entities
 Identify the roles, events, locations, tangible things or concepts about which the end-users want
to store data.
2. Find Relationships
 Find the natural associations between pairs of entities using a relationship matrix.
3. Draw Rough ERD
 Put entities in rectangles and relationships on line segments connecting the entities.
4. Fill in Cardinality
 Determine the number of occurrences of one entity for a single occurrence of the related entity.
5. Define Primary Keys
 Identify the data attribute(s) that uniquely identify one and only one occurrence of each entity.
6. Draw Key-Based ERD
 Eliminate Many-to-Many relationships and include primary and foreign keys in each entity.
7. Identify Attributes
 Name the information details (fields) which are essential to the system under development.
8. Map Attributes
 For each attribute, match it with exactly one entity that it describes.
9. Draw fully attributed ERD
 Adjust the ERD from step 6 to account for entities or relationships discovered in step 8.
10. Check Results
 Does the final Entity Relationship Diagram accurately depict the system data?
 SIMPLE EXAMPLE
• A company has several departments. Each
department has a supervisor and at least one
employee. Employees must be assigned to at
least one, but possibly more departments. At
least one employee is assigned to a project, but
an employee may be on vacation and not
assigned to any projects. The important data
fields are the names of the departments,
projects, supervisors and employees, as well as
the supervisor and employee number and a
unique project number.
 1. Identify Entities

• The entities in this system are

DEPARTMENT, EMPLOYEE,
SUPERVISOR and PROJECT. One is
tempted to make Company an entity, but
it is a false entity because it has only one
instance in this problem. True entities
must have more than one instance.
 2. Find Relationships
• We construct the following Entity
Relationship Matrix:
Department Employee Supervisor Project

Department is assigned run by

Employee belongs to works on

Supervisor runs

Project uses
 3. Draw Rough ERD
• We connect the entities whenever a
relationship is shown in the entity
Relationship Matrix.
 4. Fill in Cardinality
From the description of the problem we see that:
• Each department has exactly one supervisor.
• A supervisor is in charge of one and only one department.
• Each department is assigned at least one employee.
• Each employee works for at least one department.
• Each project has at least one employee working on it.
• An employee is assigned to 0 or more projects.
 5. Define Primary Keys

• We have 4 entities: DEPARTMENT,

EMPLOYEE, SUPERVISOR and
PROJECT
• The primary keys are:
• Department Name (DEPARTMENT),
Employee Number (EMPLOYEE),
Supervisor Number (SUPERVISOR), and
Project Number (PROJECT).
 6. Draw Key-Based ERD
There are two many-to-many relationships in the rough ERD above,
between Department and Employee and between Employee and
Project.

Thus we need the associative entities Department-Employee and

Employee-Project.

The primary key for Department-Employee is the concatenated key

Department Name and Employee Number.

The primary key for Employee-Project is the concatenated key

Employee Number and Project Number.

Definition concatenate : To connect or link in a series or chain

 7. Identify Attributes
• The only attributes indicated are the names
of the departments, projects, supervisors and
employees, as well as the supervisor and
employee NUMBER and a unique project
number.
 8. Map Attributes
Attribute Entity
Department Name Department
Employee Number Employee

Employee Name Employee

Supervisor Number Supervisor

Supervisor Name Supervisor

Project Name Project

Project Number Project

9. Draw Fully Attributed ERD
 Steps to Complete an ERD
1) Identify the Business Rules (BR)
2) Make a list of the Entities.
3) List ALL the simple relationships between Entities and define
the connectivity, cardinalities, weak and optional relationships.
4) Merge the simple ERDs into one ERD, placing the most
occurring ENTITY in the middle if possible.

ERDs are difficult. They are as much of as an art as they are the
result of step-by-step process. It takes practice.

In the next sections, we will take an example and go through the

steps.
 ERD Example #1
• Consider a database that is to represent a large
business. In this typical business, there is a
Division that operates several Departments. The
Division is run by one Employee and each
Department is managed by one Employee. Of
course the Department employs many Employees
who work on projects that are assigned to them.
Everyone needs to be busy, so it is not uncommon
for an Employee to be assigned many Projects and a
Project may have many Employees assigned to it.
There is a special case of Employees that are not
assigned to any Department; they roam around
looking for work from the various Departments.
 STEP 1) Identify the Business Rules
From the paragraph above we can get
the following Business Rules (BR):

a) A department employs many

employees, but each employee is
employed by one department.

b) Some employees, known as "rovers,"

are not assigned to any department.
c) A division operates many
departments, but each department is
operated by one division
 STEP 1) Identify the Business Rules
From the paragraph above we can get the following
Business Rules (BR):

d) An employee may be assigned to many projects and a

project may have many
employees assigned to it.

e) A project must have at least one employee assigned to it.

f) One of the employees manages each department.

g) One of the employees runs each division.

STEP 2) Make a list of the Entities
From the paragraph above we can get the following Business Rules (BR):

a) A DEPARTMENT employs many EMPLOYEEs, but each employee is employed

by one department.

b) Some employees, known as "rovers," are not assigned to any department.

c) A DIVISION operates many departments, but each department is operated by one

division

d) An employee may be assigned to many projects and a project may have many
employees assigned to it.

e) A PROJECT must have at least one employee assigned to it.

f) One of the employees manages each department.

g) One of the employees runs each division.

STEP 2) Make a list of the Entities
• From the case study there are the following
Entities:

• EMPLOYEE
• DIVISION
• DEPARTMENT
• PROJECT
 3. List ALL simple ERDs

• Here comes the hard part. For each of the

relationships below we have to determine all the
details of connectivity, cardinalities, weak
relationships and optional participation between
entities. Let's take them one at a time.
3. List ALL simple ERDs
[DIVISION] <operates> [DEPARTMENT]

[EMPLOYEE] <runs> [DIVISION]

[EMPLOYEE] <manages> [DEPARTMENT]

[EMPLOYEE] <assigned> [PROJECT]

[DEPARTMENT] <employs> [EMPLOYEE]

 3. List ALL simple ERDs
The first simple ERD:
____________________________________

DIVISION operates DEPARTMENT

Determine the connectivity:

Business rule (c) states: A division operates many departments, but each
department is operated by one division. So we get

[DIVISION] (1) ………<operates>…………..(M)[DEPARTMENT]

 3. List ALL simple ERDs
The first simple ERD:
____________________________________

Determine the cardinality:

Procedure for determining the cardinality:

A DIVISION will operate a minimum of ____1____ DEPARTMENT

A DIVISION will operate a maximum of ____N____ DEPARTMENTs

Then reverse the order:

A DEPARTMENT is operated by a minimum of ___1_____ DIVISIONs

A DEPARTMENT is operated by a maximum of ____1____ DIVISIONs

Putting this information together you get:

M
1
DIVISION operates DEPARTMENT

(1,N) (1,1)
 3. List ALL simple ERDs
The Second simple ERD:
____________________________________
(g) One of the employees runs each division.

EMPLOYEE runs DIVISION

EMPLOYEE DIVISION
Step1 1  Fixed 1
Step 2 1 1  Fixed
Step 3 This is the 1 1
connectivity
3. List ALL simple ERDs
The Second simple ERD:
____________________________________
Determine the cardinality:

A DIVISION will be run by a minimum of ____1____ EMPLOYEEs

A DIVISION will be run by a maximum of ____1____ EMPLOYEEs

Then reverse the order:

An EMPLOYEE runs a minimum of ___0_____ DIVISIONs

An EMPLOYEE runs a maximum of ____1____ DIVISIONs

1
1
EMPLOYEE runs DIVISION

(0,1) (1,1)
Note the circle on the DIVISION Entity?
That’s because not all employees run a division.
 3. List ALL simple ERDs
The Third simple ERD:
____________________________________

EMPLOYEE mamages DEPARTMENT

Determine the connectivity:

Business rule (f) states: ONE of the employees manages a department.
EMPLOYEE DEPARTMENT
Step1 1  Fixed 1
Step 2 1 1  Fixed
Step 3 This is the 1 1
connectivity
3. List ALL simple ERDs
The Third simple ERD:
____________________________________

Determine the cardinality:

A DEPARTMENT is managed by a minimum of ____1____ EMPLOYEEs

A DEPARTMENT is managed by a maximum of ____1____ EMPLOYEEs

Then reverse the order: (you might have to change the verb)

An EMPLOYEE manages a minimum of ___0_____ DEPARTMENTs

An EMPLOYEE manages maximum of ____1____ DEPARTMENTs
1
1
DEPARTMENT mamages EMPLOYEE

(1,1) (0,1)

Note the circle on the DEPARTMENT Entity? That’s

because not all employees manage a department!
 3. List ALL simple ERDs
The Fourth simple ERD:
____________________________________

EMPLOYEE Is assigned to PROJECT

Determine the connectivity:

Business rule (d) states: An employee may be assigned to MANY projects and a
project may have MANY employees assigned to it. Therefore it is M:N. This
means that 'is assigned to' becomes a bridge entity:.

EMPLOYEE PROJECT
Step1 1  Fixed M
Step 2 M 1  Fixed
Step 3 This is the M N
connectivity
 3. List ALL simple ERDs
The Fourth simple ERD:
____________________________________
Determine the cardinality:

A PROJECT is assigned a minimum of ____1____ EMPLOYEEs See BR (e)

A PROJECT is assigned a maximum of ____N____ EMPLOYEEs

Then reverse the order:

An EMPLOYEE is assigned to a minimum of ___0_____ PROJECTs

An EMPLOYEE is assigned to a maximum of ____N____ PROJECT s

Note BR 'e' states: A project must have at least one employee assigned to it.
This means that we can't have a PROJECT without any employees.
Ending ERD #4
1 M M 1

EMPLOYEE isEntity
assigned
nameto PROJECT

(0,N) (1,1) (1,1) (1,N)

 3. List ALL simple ERDs
The Fourth simple ERD:
____________________________________

1 M M 1

EMPLOYEE isEntity
assigned
nameto PROJECT

(0,N) (1,1) (1,1) (1,N)

Why the optional circle on the Bridge Entity? Recall that not
all employees are assigned to a Project. Some employees are
assigned to manage a Department or run a Division.
Therefore this is shown by the circle meaning that not all
employees are assigned to a Project. The fact that the circle
is on the bridge entity and not on the EMPLOYEE entity is just
a matter of format and not meaning. In general, if you have a
bridge entity with any optional conditions then the circle goes
on the bridge entity.
 3. List ALL simple ERDs
That’s almost all of them! Can you do the last one?
a) A DEPARTMENT employs many EMPLOYEEs, but each
employee is employed by one department.
b) b) Some employees, known as "rovers," are not assigned
to any department.
Determine the cardinality:

A DEPARTMENT is assigned a minimum of ____1____ EMPLOYEEs See BR (a)

A DEPARTMENT is assigned a maximum of ____N____ EMPLOYEEs

Then reverse the order:

An EMPLOYEE is assigned to a minimum of ___0_____ DEPARTMENTs

An EMPLOYEE is assigned to a maximum of ____1____ DEPARTMENTs
N
1
DEPARTMENT employs EMPLOYEE

(1,N) (0,1)
Step 4) Merge the simple ERDs into one
ERD
• Suppose you completed all the simple ERDs. Now
it's time to create the full-blown ERD.

• All you do is look for the Entity that occurs the

most in the simple ERDs and place that in the
center of the drawing. In our case it is
EMPLOYEE—it occurs three times.

• Then just connect the other entities around the

center one.
You should end up with something like
this:
 ERD Exercise #2
Temporary Employment Corporation (TEC) places temporary workers in companies
during peak periods. TEC's manager gives you the following description of the business:
TEC has a file of candidates who are willing to work.

If the candidate has worked before, that candidate has a specific job history. (Naturally, no job
history exists if the candidate has never worked.)

Each candidate has several qualifications.

TEC also has a list of companies that request temporaries.

Each time a company requests a temporary employee, TEC makes an entry in the openings
folder. This folder contains an opening number, company name, required qualifications, starting
date, anticipated ending date, and hourly pay.
Each opening requires only one specific or main qualification.

When a candidate matches the qualification, he/she is given the job, and an entry is made in the
placement record folder. This folder contains an opening number, candidate number, total hours
worked, and so on. In addition, an entry is made in the job history for the candidate.
 ERD Exercise #2
TEC uses special codes to describe a candidate's qualifications for an opening.
The list of codes includes:

Code Description

SEC-45 Secretarial work, at least 45 words per minute

SEC-60 Secretarial work, at least 45 words per minute
CLERK General clerking work
PRG-VB Programmer, VisualBasic
PRG-C++ Programmer, C++
DBA-OR Database Administrator, ORACLE
DBA-DB2 Database Administrator, DB2
SYS-1 Systems Analyst, level 1
SYS-2 Systems Analyst, level 2
NW-NOV Network administrator, Novell experience
 ERD Exercise #2
Given this information, do the following:

1) List the entities the TEC wants to track

2) Make a list of all the simple ERDs (also called
binary relationships)
3) Determine all the cardinalities, connectivities,
optionalities, and weak entities.
4) Construct the complete ERD.
 ERD Exercise #2
1) List the entities the TEC wants to track

COMPANY
OPENING
QUALIFICATION
CANDIDATE
JOB_HISTORY
PLACEMENT
 ERD Exercise #2
• The complete ERD shows all the details.
• (Steps 2 and 3 were skipped–because it was
like the example we went through in the
beginning of this lecture)
1
ERD Exercise #2
COMPANY

(0,N)

lists 1 1
QUALIFICATION
(1,1) (0,N)
M M (1,N)
OPENING matches (1,1) M
1 (1,1) CAN_QUAL
(0,N)
M
(1,1)
(1,1) (1,N)
M M 1 1
PLACEMENT CANDIDATE
(1,1) (0,N) 1
1 (1,1) (0,N)

has

(1,1)
1 M
creates HISTORY
(0,1)
ERD Exercise #2 (Discussion)
Each COMPANY may list one or more
OPENINGs. Because we will maintain
COMPANY data even if a company has not (yet!)
hired any of TEC's candidates, OPENING is an
optional entity in this relationship. OPENING is
existence-dependent on COMPANY, because there
cannot be an opening unless it is listed by a
company. Because we have decided to use the
COMPANY primary key as a component of the
OPENING's primary key, we have satisfied the
conditions that will allow us to classify OPENING
as a weak entity.
ERD Exercise #2 (Discussion)
Each job CANDIDATE may have many job HISTORY
entries. But keep in mind that a candidate may just have
competed job training and, therefore, may not have had
job experience (i.e., no job history) yet. In short,
HISTORY is optional to CANDIDATE. On the other
hand, a job candidate may have had many jobs
(remember, TEC is a temp employer!) and, therefore,
would have many entries in HISTORY. Finally,
HISTORY is clearly existence-dependent on
CANDIDATE; it is not possible to make an entry in
HISTORY without having a CANDIDATE to generate
that history. We will use the CANDIDATE primary key
as one of the components of the HISTORY's primary
key, thus allowing us to classify HISTORY as a weak
entity.
ERD Exercise #2 (Discussion)
Each CANDIDATE may have earned one or more
QUALIFICATIONs. Although a qualification may be
listed by a company, there may not be a matching
candidate because it is possible that none of the candidates
have this qualification. For instance, it is possible that none
of the available candidates is a Pascal programmer.
Therefore, CANDIDATE is optional to
QUALIFICATION. However, many candidates may have
a given qualification. For example, many candidates may
be C++ programmers. And each qualification may be
matched to many job candidates, so the relationship
between CANDIDATE and QUALIFICATION is M:N.
This relationship must be decomposed into two 1:M
relationships with the help of a composite entity we will
name CAN_QUAL.
ERD Exercise #2 (Discussion)
Each job OPENING requires one QUALIFICATION, and any given
qualification may fit many openings, thus producing a 1:M
relationship between QUALIFICATION and OPENING. For
example, a job opening for a C++ programmer requires an applicant
to have the C++ programming qualification, but there may be many
job openings for C++ programmers! However, a qualification does
not require an opening. (After all, if there is no listing with a C++
requirement, a candidate who has the C++ qualification does not
match the listing!) Therefore, OPENING is optional to
QUALIFICATION. Because there cannot be a listed opening unless
it also lists the required qualification for that opening, the OPENING
is existence-dependent on QUALIFICATION. We will use the
QUALIFICATION primary key as a component of the OPENING's
(composite) primary key. Because OPENING is existence-dependent
on QUALIFICATION and because it borrows the
QUALIFICATION's primary key as component of its own primary
key, OPENING is properly classified as a weak entity to
QUALIFICATION.
ERD Exercise #2 (Discussion)
A listed job opening may be filled by one or more candidates. Also,
keep in mind that, during some period of time, a candidate may fill
many openings. (TEC supplies temporaries, remember?) Therefore, the
relationship between OPENING and CANDIDATE is M:N. We will
decompose this M:N relationship into two 1:M relationships, using the
composite entity named PLACEMENT as the bridge between
CANDIDATE and OPENING. Because there is not necessarily an
opening for each candidate, OPENING is optional to CANDIDATE.
Similarly, since an OPENING may be listed even when there is no
available candidate, CANDIDATE is optional to OPENING. Note the
migration of the optional symbols in the E-R diagram. (You may
wonder why we show OPENING as a weak entity in the E-R diagram.
Actually, OPENING was declared a weak entity in our earlier
discussion concerning the OPENING's relationship to COMPANY!)
Also, remind the students that, although an opening may not have an
available candidate, and a candidate may not fit an opening, the actual
placement of a candidate clearly demonstrates that there was a match
between a candidate and a listed opening!
ERD Exercise #2 (Discussion)

There exists an entry in HISTORY for every

PLACEMENT entry, but not all HISTORY
entries will have a matching placement entry.
In other words, all PLACEMENT entries will
have a matching HISTORY entry, but
PLACEMENT is optional to HISTORY
because a position may have been filled by the
candidate rather than through the TEC
services!
 ERD Exercise #3
The Jonesburgh County Basketball Conference (JCBC) is an amateur
basketball association. Each city in the county has one team that
represents it. Each team has a maximum of twelve players and a
minimum of nine players. Each team also has up to three coaches
(offensive, defensive, and PT coaches.) Each team plays two games
(home and visitor) against each of the other teams during the season.
Note the following relationships:

The main components are TEAM and GAME.

Each team plays each other team at least twice.

To play a game, two teams are necessary: the home team and the visitor
team.

Each team plays once as the home team and once as the visitor team.
 ERD Exercise #3
Hint: Here are the Entities:
CITY
TEAM
COACH
PLAYER
GAME

Given these conditions, do the following:

1) List the business rules

2) List the Entities
3) List the simple relationships between all entities (like in the lecture),
and determine the cardinalities, connectivities, optional entities and
weak entities.
4) Make the complete ERD.