0% found this document useful (0 votes)
3 views

11 Normalization Example

Uploaded by

Jhanzab Khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

11 Normalization Example

Uploaded by

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

Normalization Examples

DEPENDENCIES: DEFINITIONS
Multivalued Attributes (or repeating groups): non-
key attributes or groups of non-key attributes the
values of which are not uniquely identified by
(directly or indirectly) (not functionally dependent
on) the value of the Primary Key (or its part).

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
DEPENDENCIES: DEFINITIONS
Partial Dependency – when an non-key
attribute is determined by a part, but not the
whole, of a COMPOSITE primary key.
Partial
CUSTOMER Dependency

Cust_ID Name Order_ID


101 AT&T 1234
101 AT&T 156
125 Cisco 1250
DEPENDENCIES: DEFINITIONS
Transitive Dependency – when a non-key attribute determines
another non-key attribute.

Transitive
Dependency

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
NORMAL FORMS: REVIEW
Unnormalized – There are multivalued attributes or repeating
groups
1 NF – No multivalued attributes or repeating groups.
2 NF – 1 NF plus no partial dependencies
3 NF – 2 NF plus no transitive dependencies
EXAMPLE 1: DETERMINE NF
All attributes are directly
ISBN  Title or indirectly determined
ISBN  Publisher by the primary key;
therefore, the relation is
Publisher  Address at least in 1 NF

BOOK

ISBN Title Publisher Address


EXAMPLE 1: DETERMINE NF
ISBN  Title The relation is at least in 1NF.
There is no COMPOSITE
ISBN  Publisher primary key, therefore there
Publisher  Address can’t be partial dependencies.
Therefore, the relation is at
least in 2NF
BOOK

ISBN Title Publisher Address


EXAMPLE 1: DETERMINE NF
Publisher is a non-key
attribute, and it determines
ISBN  Title
Address, another non-key
ISBN  Publisher attribute. Therefore, there
is a transitive dependency,
Publisher  Address which means that the
relation is NOT in 3 NF.
BOOK

ISBN Title Publisher Address


EXAMPLE 1: DETERMINE NF
We know that the relation is at
ISBN  Title least in 2NF, and it is not in 3
ISBN  Publisher NF. Therefore, we conclude
that the relation is in 2NF.
Publisher  Address

BOOK

ISBN Title Publisher Address


EXAMPLE 1: DETERMINE NF
ISBN  Title In your solution you will write the
ISBN  Publisher following justification:
Publisher  Address 1) No M/V attributes, therefore at
least 1NF
2) No partial dependencies,
therefore at least 2NF
3) There is a transitive dependency
(Publisher  Address),
therefore, not 3NF
Conclusion: The relation is in 2NF

BOOK

ISBN Title Publisher Address


EXAMPLE 2: DETERMINE NF
Product_ID  Description
All attributes are directly or
indirectly determined by the
primary key; therefore, the relation
is at least in 1 NF
ORDER

Order_No Product_ID Description


EXAMPLE 2: DETERMINE NF
Product_ID  Description
The relation is at least in 1NF.
There is a COMPOSITE Primary Key (PK)
(Order_No, Product_ID), therefore there can be
partial dependencies. Product_ID, which is a part
of PK, determines Description; hence, there is a
partial dependency. Therefore, the relation is not
2NF. No sense to check for transitive
dependencies!

ORDER

Order_No Product_ID Description


EXAMPLE 2: DETERMINE NF
Product_ID  Description

We know that the relation is at least


in 1NF, and it is not in 2 NF.
Therefore, we conclude that the
relation is in 1 NF.

ORDER

Order_No Product_ID Description


EXAMPLE 2: DETERMINE NF
Product_ID  Description
In your solution you will write the
following justification:
1) No M/V attributes, therefore at least
1NF
2) There is a partial dependency
(Product_ID  Description), therefore
not in 2NF
Conclusion: The relation is in 1NF
ORDER

Order_No Product_ID Description


EXAMPLE 3: DETERMINE NF
Part_ID  Description Comp_ID and No are not
Part_ID  Price determined by the primary
Part_ID, Comp_ID  No key; therefore, the relation
is NOT in 1 NF. No sense
in looking at partial or
transitive dependencies.

PART

Part_ID Descr Price Comp_ID No


EXAMPLE 3: DETERMINE NF
Part_ID  Description In your solution you will write
Part_ID  Price the following justification:
1) There are M/V attributes;
Part_ID, Comp_ID  No therefore, not 1NF
Conclusion: The relation is not
normalized.

PART

Part_ID Descr Price Comp_ID No


BRINGING A RELATION TO 1NF

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 1NF
Option 1: Make a determinant of the repeating group (or the
multivalued attribute) a part of the primary key.

Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 1NF
Option 2: Remove the entire repeating group from
the relation. Create another relation which would
contain all the attributes of the repeating group,
plus the primary key from the first relation. In this
new relation, the primary key from the original
relation and the determinant of the repeating group
will comprise a primary key.
STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 1NF
STUDENT

Stud_ID Name
101 Lennon
125 Jonson

STUDENT_COURSE

Stud_ID Course Units


101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
BRINGING A RELATION TO 2NF

Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 2NF
Goal: Remove Partial Dependencies
Partial
Composite Dependencies
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 2NF
Remove attributes that are dependent from the part but
not the whole of the primary key from the original
relation. For each partial dependency, create a new
relation, with the corresponding part of the primary key
from the original as the primary key.

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 2NF
CUSTOMER
STUDENT_COURSE
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00 Stud_ID Course_ID
125 Johnson MSI 331 3.00
101 MSI 250
101 MSI 415
125 MSI 331

STUDENT COURSE

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
BRINGING A RELATION TO 3NF

Goal: Get rid of transitive dependencies.

Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
BRINGING A RELATION TO 3NF
Remove the attributes, which are dependent on a
non-key attribute, from the original relation. For
each transitive dependency, create a new relation
with the non-key attribute which is a determinant in
the transitive dependency as a primary key, and the
dependent non-key attribute as a dependent.

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
BRINGING A RELATION TO 3NF
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID


111 Mary Jones 1
122 Sarah Smith 2

DEPARTMENT

Dept_ID Dept_Name
1 Acct
2 Mktg
ASSIGNMENT 3 P1
Perform the normalization on the given table and clearly
answer the mentioned questions.
Put the given table in 1NF Tables
Put the given table in 2NF
Put the given table in 3NF Tables

You might also like