Oracle Normals

8/13/2019 Oracle Normals

1/25

NormalizationNormalization

Normalizationis a process of analyzing arelation to ensure it is well formed

More specifically, if a relation is normalized,

rows can be added, removed, or updatedwithout creating exceptions


2/25

NormalizationNormalization

The process of decomposing relations withanomalies to produce smaller well-structuredrelations.

nomalies! "rrors or inconsistencies that mayresult when user attempts to update a table

that contains redundant data.#ell-structured relations contains minimal

redundancy and allows users to insert, modify,and delete the rows in a table without errors orinconsistencies.


3/25

AnomaliesAnomalies

$elations that are not normalized will experienceissues %nown as anomalies

& 'nsertion anomaly

(ifficulties inserting data into a relation

& Modification anomaly

(ifficulties modifying data into a relation

& (eletion anomaly

(ifficulties deleting data from a relation


4/25

Stages of Normal FormsStages of Normal Forms

)irst Normal )orm *+N)

econd Normal )orm *N)

Third Normal )orm */N)

0oyce-1odd Normal )orm *01N)

)ourth Normal )orm *2N)

)ifth Normal )orm *3N)

(omain45ey Normal )orm *(54N)


5/25

)irst Normal )orm)irst Normal )orm

relation is in first normal form when it containsno multi-valued attributes.

The value at the intersection of each row andcolumn must be atomic.


6/25

T06" #'T7 $"8"T'N9 9$:;8T06" #'T7 $"8"T'N9 9$:;8

03/03/1998

29/10/1999

15/05/1999

DB2

CICS

SSAD

90,00

0

MISRobert1789

03/03/2000

12/01/1998

14/06/1999

C++

D2000

Java Bas!s

80,00

0

MISMar"1456

09/07/1998#a$ato%52,00

0

A!!o&%t%

'

Ja(es1245

06/12/1999

12/05/1998

SSAD

MS)*!e

48,00

0

MaretA%-re.1233

DateCo(e

te-

Co&rsea(

e

Saar

"

Deta(

e

a(e(ID

EMPLOYEE


7/25

T06" 'N )'$T N:$M6 ):$MT06" 'N )'$T N:$M6 ):$M

12/01/1998D200080,000MISMar"1456

03/03/2000C++80,000MISMar"1456

06/12/1999SSAD48,000Maret%'A%-re.1233

14/06/1999Java Bas!s80,000MISMar"1456

09/07/1998#a$ato%52,000A!!o&%t%'Ja(es1245

12/05/1998MS)*!e48,000Maret%'A%-re.1233

DateCo(e

te-

Co&rsea(

e

Saar"Deta(ea(e(ID

EMPLOYEE


8/25

8ro+?3.??

(atabase(esigne

r

@ohn 9News

+?+

/.B>B2.3?"lecC"ngineer

@une "rbough

+?/"vergreen

+3

HoursChg_hour

Job_Class

Emp_Name

Emp_num

Proj_Name

Proj_Num


9/25

8roB2.3?"lecC"

ngineer

@une "

rbough

+?/"verg

reen

+3

HoursChg_hour

Job_Class

Emp_Name

Emp_num

Proj_Name

Proj_Num

Data

Orga

nizati

on:

FirstNo

rmal

Form


10/25

Example for 1NFExample for 1NF


11/25

)unctional (ependencies nd 5eys)unctional (ependencies nd 5eys

Normalization is based on the analysis offunctional dependencies.

)unctional dependency constraint betweentwo attributes or two sets of attributes.

"mpC'(, 1ourseCName(ateC1ompleted

The date a course is completed is determined bythe identity of the employee and the name ofthe course.


12/25

econd Normal )ormecond Normal )orm

relation that is in first normal form and hasevery non-%ey attribute functionally dependenton the primary %ey.


13/25


relation that is in first normal form is in secondnormal form if and only if

. The primary %ey consists of only one attribute.

/. No non-%ey attribute exists in the relation.

2. "very no-%ey attribute is functionallydependent on the primary %ey.

To convert relation into second normal form, we

decompose the relation into new relationships.


14/25


EMPLOYEE is decomposed into two relations

80,000MISMar"1456

52,000A!!o&%t%'Ja(es1245

48,000Maret%'A%-re.1233

Saar"Deta(ea(e(ID

14/06/1999Java Bas!s1456

03/03/2000C++1456

12/01/1998D20001456

12/05/1998MS)*!e1233

06/12/1999SSAD1233

DateCo(ete-Co&rsea(e(ID

EMPLOYE2

EMPLOYE1


15/25


16/25

After applying 2NFAfter applying 2NF


17/25

Third Normal )ormThird Normal )orm

Transitive dependency

)unctional dependency between two nor morenon-%ey attributes.

relation is in third normal form */N), if it is insecond normal form and no transitivedependencies exist.


18/25

Third Normal )ormThird Normal )orm

RegionSalespersonNameCustID

Relation with transitive dependency

SALES

Cust_ID is the primary key !ll o" the remainin# attri$utes are

"unctionally dependent on this attri$ute

%owever& re#ion is "unctionally dependent on sales

person and salesperson is "unctionally dependent on Cust_ID


19/25

SalespersonNameCustID

RegionSalesperson

Afterapplying

ThirNormal

Form!Remo"al

ofTransiti"e

Depenen#y


20/25

Example for 3NFExample for 3NF


21/25

Solution to Previous ExampleSolution to Previous Example


22/25


23/25


24/25

0oyce41odd normal form0oyce41odd normal form

0oyce 4 1odd normal form ny remaininganomalies that result from functionaldependencies have been removed


25/25

Oracle Normals

Documents

Transcript of Oracle Normals