1

Database Application
SAK 3408
CHAPTER 2
DATABASE DESIGN

Learning Objectives (W4)

2

Describe the database design phases.

Explain on how to construct E-R diagram.
Transform ERD into Relation.
Data normalization to decompose a relation
with anomalies into well-structured relations.

Data Normalization
3

Primarily a tool to validate and improve a

logical design so that it satisfies certain
constraints that avoid unnecessary

duplication of data

The process of decomposing relations with

anomalies to produce smaller, wellstructured relations

Well-Structured Relations
4

A relation that contains minimal data

redundancy and allows users to insert, delete,
and update rows without causing data
inconsistencies
Goal is to avoid anomalies
Insertion Anomaly adding new rows forces user
to include the details of that rows.
Deletion Anomaly deleting rows may cause a
loss of data that would be needed for other future
rows
Modification Anomaly changing data in a row
forces changes to other rows because of
duplication

Recap
5

Definition: A relation is a named, two-dimensional

table of data

Table is made up of rows (records), and columns (attribute or

field)

Not all tables qualify as relations

Requirements:

Every relation has a unique name.

Every attribute value is atomic (not multivalued, not
composite)
Every row is unique (cant have two rows with exactly the
same values for all their fields)
Attributes (columns) in tables have unique names
The order of the columns is irrelevant
The order of the rows is irrelevant

Figure 2.23 Employee table

6

C++

7/23/200x

Question Is this a relation? Answer Yes: unique rows and no

multivalued attributes

Question Whats the primary key? Answer Composite: Emp_ID,

Course_Title

Anomalies in this Table

7

Insertion cant enter a new employee without

having the employee take a class
Deletion if we remove employee 140, we lose
information about the existence of a Tax Acc
class
Modification giving a salary increase to
employee 100 forces us to update multiple
records
Why
do these anomalies exist?

Because weve combined two themes (entity

types) into one relation. This results in
duplication, and an unnecessary dependency
between the entities

Functional Dependencies and

Keys

Functional Dependency: The value of one

attribute (the determinant) determines the
value of another attribute
Candidate Key:
A

unique identifier. One of the candidate keys will

become the primary key
E.g.

perhaps there is both credit card number and SS#

in a tablein this case both are candidate keys

Each

non-key field is functionally dependent on

every candidate key

Figure 2.24
Steps in
normalization

First Normal Form

10

No multivalued attributes
Every attribute value is atomic
All relations are in 1st Normal
Form

What is atomic value?

11

This mean that in your table, for every row-by-column

position (cell), there exists only one value - not an
array or list of values:
OrderID

CustID

Date

Items

4/11/02

5 Pencils, 3 Erasers, 6 Rulers

23

6/11/02

1 Scissor

15

7/11/02

2 Pen, 2 Notebook

7/11/02

15 5" Magazine File

23

7/11/02

1 Stapler

8/11/02

5 Kingston USB Flash Drive 8GB

Example
12

DEPT_NO

MANAGER_NO

EMP_NO

EMP_NAME

D101

12345

20000
20001
20002

Carl Sagan
Magic Johnson
Larry Bird

D102

13456

30000
30001

Jimmy Carter
Paul Simon

and now, is this a relation?

13

Dept_N
o

Manager_N
o

Emp_N
o

Emp_Name

D101

12345

2000

Carl Sagan

D101

12345

2001

Magic Johnson

D101

12345

2002

Larry Bird

D102

13456

3000

Jimmy Carter

D102

13456

30001

Paul Simon

Second Normal Form

14

1NF plus every non-key attribute is fully

functionally dependent on the ENTIRE
primary key
Every

non-key attribute must be defined by

the entire key, not by only part of the key
No partial functional dependencies

Fig. 2.23 is NOT in 2nd Normal Form (see

fig 2.25)

Figure 2.25 Functional Dependencies in EMPLOYEE2

15

Dependency on entire primary key

EmpID

CourseTitl
e

Nam
e

DeptNam Salar DateComplete

e
y
d

Dependency
Dependencyon
ononly
onlypart
partofofthe
thekey
key
EmpID, CourseTitle DateCompleted
EmpID Name, DeptName, Salary

Therefore, NOT in 2nd Normal Form!!

Getting it into 2nd Normal Form

16

Figure 2.26 decomposed into two separate relations

EmpID

Nam
e
EmpID

DeptNam Salar
e
y

Both are full

functional
dependencie
s

CourseTitl DateComplete
e
d

Third Normal Form

17

2NF PLUS no

transitive
dependencies (one attribute functionally

determines a second, which functionally

determines a third)
Fig. 2.27, 2.28

Figure 2.27 -- Relation with transitive dependency

(a) SALES relation with simple data

18

(b) Relation with transitive dependency

CustID Name
CustID Salesperson
CustID Region
All this is OK
(2nd NF)
19

BUT

CustID Salesperson Regi

Transitive
dependency
(not 3rd NF)

Figure 2.28 Removing a transitive dependency

(a) Decomposing the SALES relation

20

Figure 2.28(b) Relations in 3NF

Salesperson Region

CustID Name
CustID
Salesperson
Now, there are no transitive
dependencies
Both relations are in 3rd NF
21

Other Normal Forms

22

Boyce-Codd NF

4th NF

No multivalued dependencies

5th NF

All determinants are candidate keysthere is no

determinant that is not a unique identifier

No lossless joins

Domain-key NF

The ultimate NFperfect elimination of all possible

anomalies