Scribd
Upload
58 views

Database Chapter02-03

This document discusses database design and normalization. It describes the goals of normalization as avoiding data anomalies like insertion, deletion, and modification anomalies. The document explains the concepts of functional dependencies, candidate keys, and various normal forms including 1st, 2nd, and 3rd normal form. It provides examples of relations and how to decompose relations to remove anomalies and attain higher normal forms through elimination of transitive dependencies.

Uploaded by

rockers91
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
58 views

Database Chapter02-03

This document discusses database design and normalization. It describes the goals of normalization as avoiding data anomalies like insertion, deletion, and modification anomalies. The document explains the concepts of functional dependencies, candidate keys, and various normal forms including 1st, 2nd, and 3rd normal form. It provides examples of relations and how to decompose relations to remove anomalies and attain higher normal forms through elimination of transitive dependencies.

Uploaded by

rockers91
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

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

You might also like