Database Chapter02-03

8/10/2019 Database Chapter02-03

1/22

CHAPTER 2

DATABASE DESIGN

1

Database Application

SAK 3408


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.


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


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


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


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


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/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


9/22

9

Figure 2.24

Steps innormalization


10/22

First Normal Form

10

No multivalued attributes

Every attribute value is atomic

A ll relat ionsare in 1stNormalForm


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:


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


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?


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)


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


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


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


18/22

18

Figure 2.27 -- Relation with transitive dependency

(a) SALES relation with simple data


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)


20/22

20

Figure 2.28 Removing a transitive dependency

(a) Decomposing the SALES relation


21/22

21

Figure 2.28(b) Relations in 3NF

Now, there are no transitive dependencies

Both relations are in 3rdNF

CustIDName

CustIDSalesperson

SalespersonRegion


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

Database Chapter02-03

Documents

Transcript of Database Chapter02-03