8/10/2019 Database Chapter02-03
1/22
CHAPTER 2
DATABASE DESIGN
1
Database Application
SAK 3408
8/10/2019 Database Chapter02-03
2/22
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 relationwith anomalies into well-structured relations.
8/10/2019 Database Chapter02-03
3/22
Data Normalization3
Primarily a tool to validate and improve a
logical design so that it satisfies certain
constraints that avo id unnecessary
dupl icat ion o f data
The process of decomposing relations with
anomalies to produce smaller, well-
st ructuredrelations
8/10/2019 Database Chapter02-03
4/22
Well-Structured Relations4
A relation that contains minimal dataredundancy and allows users to insert, delete,and update rows without causing data
inconsistencies Goal is to avoid anomalies
Insertion Anomalyadding new rows forces userto include the details of that rows.
Deletion Anomalydeleting rows may cause aloss of data that would be needed for other futurerows
Modification Anomalychanging data in a row
forces changes to other rows because ofduplication
8/10/2019 Database Chapter02-03
5/22
Recap5
Definition: A relation is a named, two-dimensionaltable of data
Table is made up of rows (records), and columns (attribute orfield)
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 thesame 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
8/10/2019 Database Chapter02-03
6/22
Figure 2.23 Employee table
6
QuestionIs this a relation? AnswerYes: unique rows and nomultivalued attributes
QuestionWhats the primary key?AnswerComposite: Emp_ID,Course_Title
C++ 7/23/200x
8/10/2019 Database Chapter02-03
7/22
Anomalies in this Table7
Insertioncant enter a new employee without
having the employee take a class
Deletionif we remove employee 140, we lose
information about the existence of a Tax Accclass
Modificationgiving a salary increase to
employee 100 forces us to update multiple
recordsWhy 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
8/10/2019 Database Chapter02-03
8/22
Functional Dependencies and
Keys8
Functional Dependency: The value of oneattribute (the determinant) determines thevalue 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 onevery candidate key
8/10/2019 Database Chapter02-03
9/22
9
Figure 2.24
Steps innormalization
8/10/2019 Database Chapter02-03
10/22
First Normal Form
10
No multivalued attributes
Every attribute value is atomic
A ll relat ionsare in 1stNormalForm
8/10/2019 Database Chapter02-03
11/22
What is atomic value?11
OrderID CustID Date Items
1 4 4/11/02 5 Pencils, 3 Erasers, 6 Rulers
2 23 6/11/02 1 Scissor
3 15 7/11/02 2 Pen, 2 Notebook
4 2 7/11/02 15 5" Magazine File
5 23 7/11/02 1 Stapler
6 2 8/11/02 5 Kingston USB Flash Drive 8GB
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:
8/10/2019 Database Chapter02-03
12/22
12
Example
DEPT_NO MANAGER_NO EMP_NO EMP_NAME
D101 12345 20000
2000120002
Carl Sagan
Magic JohnsonLarry Bird
D102 13456 3000030001
Jimmy CarterPaul Simon
8/10/2019 Database Chapter02-03
13/22
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
and now, is this a relation?
8/10/2019 Database Chapter02-03
14/22
Second Normal Form
14 1NF plusevery 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 2ndNormal Form (see
fig 2.25)
8/10/2019 Database Chapter02-03
15/22
Figure 2.25Functional Dependencies in EMPLOYEE2
15
Dependency on onlypartof the key
EmpID CourseTitl
e
DateComplete
d
Salar
y
DeptNam
e
Nam
e
EmpID, CourseTitle DateCompletedEmpID Name, DeptName, Salary
Therefore, NOT in 2ndNormal Form!!
Dependency on entire primary key
Dependency on onlypartof the key
8/10/2019 Database Chapter02-03
16/22
Getting it into 2ndNormal Form
16
EmpID Salary
DeptName
Name
CourseTitl
e
DateComplete
d
EmpID
Both are full
functionaldependencie
s
Figure 2.26 decomposed into two separate relations
8/10/2019 Database Chapter02-03
17/22
Third Normal Form
17
2NF PLUS no trans i t ive
dependencies(one attribute functionally
determines a second, which functionallydetermines a third)
Fig. 2.27, 2.28
8/10/2019 Database Chapter02-03
18/22
18
Figure 2.27 -- Relation with transitive dependency
(a) SALES relation with simple data
8/10/2019 Database Chapter02-03
19/22
19
(b) Relation with transitive dependency
CustID Name
CustID SalespersonCustID Region
All this is OK
(2ndNF)
BUT
CustID Salesperson Regi
Transitive
dependency
(not 3rdNF)
8/10/2019 Database Chapter02-03
20/22
20
Figure 2.28 Removing a transitive dependency
(a) Decomposing the SALES relation
8/10/2019 Database Chapter02-03
21/22
21
Figure 2.28(b) Relations in 3NF
Now, there are no transitive dependencies
Both relations are in 3rdNF
CustIDName
CustIDSalesperson
SalespersonRegion
8/10/2019 Database Chapter02-03
22/22
Other Normal Forms22
Boyce-Codd NF
All determinants are candidate keysthere is nodeterminant that is not a unique identifier
4thNF No multivalued dependencies
5thNF No lossless joins
Domain-key NF The ultimate NFperfect elimination of all possible
anomalies