Scribd
Upload
2K views

Oracle Normalization Simplified

The document discusses normalization of data models. It defines three normal forms: 1NF requires attributes to be single-valued, 2NF requires attributes to depend on the entire primary key, and 3NF requires attributes to be dependent only on the primary key and not on other non-key attributes. The document provides examples of normalizing entities by identifying attributes that violate these rules and moving them to appropriate entities to achieve normalization.

Uploaded by

bookworm_shashi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
2K views

Oracle Normalization Simplified

The document discusses normalization of data models. It defines three normal forms: 1NF requires attributes to be single-valued, 2NF requires attributes to depend on the entire primary key, and 3NF requires attributes to be dependent only on the primary key and not on other non-key attributes. The document provides examples of normalizing entities by identifying attributes that violate these rules and moving them to appropriate entities to achieve normalization.

Uploaded by

bookworm_shashi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 14

Normalization

Normalize the Data Model


Normalization is a relational database concept, but its principles
apply to Conceptual Data Modelling.
 First Normal Form (1NF)
 All Attributes must be single-valued
 Second Normal Form (2NF)
 An attribute must be dependent upon its
entity’s entire unique identifier
 Third Normal Form (3NF)
 All non key attributes are mutually
independent and are fully dependent on
primary key
A normalized entity-relationship data model automatically translates into a
normalized relational database design!
First Normal Form
Single-valued attributes
First Normal Form Rule: All attributes must be singled-valued.
Validate that each attribute has a single value
for each occurrence of the entity. No
attribute should have repeating values.
CLIENT
#* identifier
* date contacted
Does the entity CLIENT comply with 1NF?

The attribute date contacted has multiple values, therefore the


entity CLIENT is not in 1NF.
First Normal Form (cont)

 If an attribute has multiple values, create an


additional entity and relate it to the original
entity with a M:1 relationship.

CONTACT for CLIENT


#* date contacted
#* identifier
o location
o result the
subject
of
Second Normal Form
Dependency on entire UID
Second Normal Form Rule: An attribute must be dependent upon
its entity’s entire unique identifier.
 Validate that each attribute is dependent on
its entity’s entire unique identifier. Each
specific instance of the UID must determine
a single instance of each attribute.
 Validate that an attribute is not dependent
upon only part of its entity’s UID.

COURSE Validate placement of the COURSE entity’s


#* code attributes
* name
* duration
* fee In this example, each instance of a course code determines
a specific value for name, duration, and fee. The
attributes are properly placed.
Second Normal Form (cont)

 Validate the placement of the attributes for the


ACCOUNT and BANK entities

ACCOUNT managed BANK


#* number by
#* number
* balance
* name
* date opened
* bank location the
manager
of

Are there any attributes which can be determined from a portion of


its entity’s UID?
Second Normal Form (cont)

 Validate the placement of the attributes for the


ACCOUNT and BANK entities

ACCOUNT managed BANK


#* number by
#* number
* balance
* name
* date opened
the * bank location
manager
of

Each instance of a BANK and account number determine specific


values of balance and date opened for each account. The attribute
bank location is misplaced. It is dependent on BANK but not on
account number and so should be an attribute of BANK.
Third Normal Form
No non-UID interdependencies
Third Normal Form Rule: No non-UID attribute can be dependent
upon another non-UID attribute.
 Validate that each non-UID attribute is not
dependent upon another non-UID attribute
 Move any non-UID attribute that is
dependent upon another non-UID attribute
ORDER
#* id Are any of the non-UID attributes for this
* date of order entity dependent upon another non-UID
* customer id
* customer name
attribute?
* state
Third Normal Form (cont)

ORDER The attributes customer name and state are


#* id
* date of order dependent on the customer id. Create another
* customer id entity called CUSTOMER with a UID of customer
* customer name id and place the attributes accordingly.
* state

ORDER CUSTOMER
#* id for #* id
* date of order * name
the * state
submitter
of
Exercise N-1
For the following E-R Model, evaluate each entity against the rules
of normalization, identify the misplaced attribute, and explain
what rule of normalization each misplaced attribute violates.
Optionally, re-draw the E-R diagram in third normal form.

ENROLLMENT for COURSE


grade code #* course number
teacher number course name
grade description completed teacher number
course name with department code
department name
for teacher name

assigned

STUDENT
#* student id
last name
first name
Exercise N-1 Solution-1NF

 Any repeating values?


COURSE
ENROLLMENT for #* course number
grade code course name
teacher number teacher number
grade description department code
completed department name
course name with teacher name
for

assigned There is no violation of


First Normal form, so
STUDENT the entities stay the same.
#* student id
last name
first name
Exercise N-1 Solution-2NF
 Any partial UID dependencies?

ENROLLMENT for COURSE


grade code #* course number
teacher number course name
grade description completed teacher number
course name with department code
department name
for teacher name

assigned
Yes! Teacher Number
STUDENT and Course Name, in the
#* student id
ENROLLMENT entity,
last name do not depend on both
first name the Course Number and
Student Id.
Exercise N-1 Solution-3NF

• Any transitive UID dependencies?

ENROLLMENT for COURSE


grade code #* course number
grade description course name
completed teacher number
with department code
department name
for teacher name

assigned
Yes! Grade Description is dependent
STUDENT on Grade Code, Department Name is
#* student id dependent on Department Number,
last name and Teacher name is dependent on
first name Teacher Number.
Exercise N-1
Solution-Normalized Model
ENROLLMENT COURSE taught by TEACHER
for # * course number # * number
course name name
the
completed with teacher
of
offered by

DEPARTMENT
the offerer of
the receiver
# * number
of name

GRADE
assigned to # * code
description The ENROLLMENT entity
for
assigned
has no attributes of its own.
It is still considered an
STUDENT entity, since it participates
# * student id in 2 or more relationships.
last name
first name

You might also like