Unit I Normalization

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 51

UNIT-I –DBMS-NORMALIZATION

Mr.V.Yuvaraj
Assistant Professor – Department of Computer Applications
Dr. N.G.P. ARTS AND SCIENCE COLLEGE
Dr. N.G.P.-KALAPATTI ROAD
COIMBATORE-641 048
Tamil Nadu, India
Mobile: +917502919891,
E-mail: [email protected]

Dr. NGPASC
COIMBATORE | INDIA
Objective

• Normalization presents a set of rules that


tables and databases must follow to be well
structured.
• Historically presented as a sequence of normal
forms

Dr. NGPASC
COIMBATORE | INDIA
Normalization
A large database defined as a single relation may
result in data duplication.
This repetition of data may result in:
• Making relations very large.
• It isn't easy to maintain and update data as it would
involve searching many records in relation.
• Wastage and poor utilization of disk space and
resources.
• The likelihood of errors and inconsistencies increases.

Dr. NGPASC
COIMBATORE | INDIA
What is Normalization?
• Normalization is the process of organizing the data in
the database.
• Normalization is used to minimize the redundancy
from a relation or set of relations. It is also used to
eliminate undesirable characteristics like Insertion,
Update, and Deletion Anomalies.
•Normalization divides the larger table into smaller and
links them using relationships.
•The normal form is used to reduce redundancy from
the database table.
Dr. NGPASC
COIMBATORE | INDIA
Data modification anomalies can be
categorized into three types:
Data modification anomalies can be categorized into
three types:
•Insertion Anomaly: Insertion Anomaly refers to when
one cannot insert a new tuple into a relationship due to
lack of data.
•Deletion Anomaly: The delete anomaly refers to the
situation where the deletion of data results in the
unintended loss of some other important data.
•Updatation Anomaly: The update anomaly is when an
update of a single data value requires multiple rows of
data to be updated.
Dr. NGPASC
COIMBATORE | INDIA
Types of Normal Forms:

Dr. NGPASC
COIMBATORE | INDIA
First Normal From

• A table is in the first normal form iff


– The domain of each attribute contains only
atomic values, and
– The value of each attribute contains only a single
value from that domain.

In layman's terms. it means every column of


your table should only contain single values
Dr. NGPASC
COIMBATORE | INDIA
Example

• For a library

Patron ID Borrowed books


C45 B33, B44, B55
C12 B56

Dr. NGPASC
COIMBATORE | INDIA
1-NF Solution

Patron ID Borrowed book


C45 B33
C45 B44
C45 B33
C12 B56

Dr. NGPASC
COIMBATORE | INDIA
Example

• For an airline

Flight Weekdays
UA59 Mo We Fr
UA73 Mo Tu We Th Fr

Dr. NGPASC
COIMBATORE | INDIA
1NF Solution

Flight Weekday
UA59 Mo
UA59 We
UA59 Fr
UA73 Mo
UA73 We
… …
Dr. NGPASC
COIMBATORE | INDIA
Example

• Book table
BookNo Title Author Year
B1 Moby Dick H. Melville 1851
B2 Lincoln G. Vidal 1984

Author attribute is:


 functionally dependent on the pair
{ BookNo, Title}
 fully functionally dependent on BookNo

Dr. NGPASC
COIMBATORE | INDIA
Why it matters
• table Borrowed Books

BookNo Patron Address Due

B1 J. Fisher 101 Main Street 3/2/15


B2 L. Perez 202 Market Street 2/28/15
Address attribute is
 functionally dependent on the pair
{ BookNo, Patron}
 fully functionally dependent on Patron
Dr. NGPASC
COIMBATORE | INDIA
Problems

• Cannot insert new patrons in the system until


they have borrowed books
– Insertion anomaly
• Must update all rows involving a given patron
if he or she moves.
– Update anomaly
• Will lose information about patrons that have
returned all the books they have borrowed
– Deletion anomaly
Dr. NGPASC
COIMBATORE | INDIA
Second Normal Form

• A table is in 2NF iff


– It is in 1NF and
– no non-prime attribute is dependent on any
proper subset of any candidate key of the table
• A non-prime attribute of a table is an attribute
that is not a part of any candidate key of the
table
• A candidate key is a minimal superkey
Dr. NGPASC
COIMBATORE | INDIA
Example

• Library allows patrons to request books that


are currently out

BookNo Patron PhoneNo


B3 J. Fisher 555-1234
B2 J. Fisher 555-1234
B2 M. Amer 555-4321

Dr. NGPASC
COIMBATORE | INDIA
Example

• Candidate key is {BookNo, Patron}


• We have
– Patron → PhoneNo
• Table is not 2NF
– Potential for
• Insertion anomalies
• Update anomalies
• Deletion anomalies

Dr. NGPASC
COIMBATORE | INDIA
2NF Solution

• Put telephone number in separate Patron


table

BookNo Patron Patron PhoneNo


B3 J. Fisher J. Fisher 555-1234
B2 J. Fisher M. Amer 555-4321
B2 M. Amer

Dr. NGPASC
COIMBATORE | INDIA
Third Normal Form

• A table is in 3NF iff


– it is in 2NF and
– all its attributes are determined only by its
candidate keys and not by any non-prime
attributes

Dr. NGPASC
COIMBATORE | INDIA
Example

• Table BorrowedBooks
BookNo Patron Address Due
B1 J. Fisher 101 Main Street 3/2/15
B2 L. Perez 202 Market Street 2/28/15

 Candidate key is BookNo


 Patron → Address

Dr. NGPASC
COIMBATORE | INDIA
3NF Solution

• Put address in separate Patron table

BookNo Patron Due


B1 J. Fisher 3/2/15
B2 L. Perez 2/28/15

Patron Address
J. Fisher 101 Main Street
L. Perez 202 Market Street
Dr. NGPASC
COIMBATORE | INDIA
Another example

• Tournament winners
Tournament Year Winner DOB
Indiana Invitational 1998 Al Fredrickson 21 July 1975

Cleveland Open 1999 Bob Albertson 28 Sept. 1968


Des Moines Masters 1999 Al Fredrickson 21 July 1975

• Candidate key is {Tournament, Year}


• Winner →DOB
Dr. NGPASC
COIMBATORE | INDIA
Boyce-Codd Normal Form

• Stricter form of 3NF


• A table T is in BCNF iff
– for every one of its non-trivial dependencies
X → Y, X is a super key for T

• Most tables that are in 3NF also are in BCNF

Dr. NGPASC
COIMBATORE | INDIA
Example
Manager Project Branch
Alice Alpha Austin
Alice Delta Austin
Carol Alpha Houston
Dean Delta Houston

• We can assume
– Manager → Branch
– {Project, Branch} → Manager
Dr. NGPASC
COIMBATORE | INDIA
Example
Manager Project Branch
Alice Alpha Austin
Bob Delta Houston
Carol Alpha Houston
Alice Delta Austin

• Not in BCNF because Manager → Branch and


Manager is not a superkey
• Will decomposition work?
Dr. NGPASC
COIMBATORE | INDIA
A decomposition (I)

Manager Project Manager Branch


Alice Alpha Alice Austin
Bob Delta Bob Houston
Carol Alpha Carol Houston
Alice Delta

• Two-table solution does not preserve the


dependency {Project, Branch} → Manager
Dr. NGPASC
COIMBATORE | INDIA
A decomposition (II)

Manager Project Manager Branch


Alice Alpha Alice Austin
Bob Delta Bob Houston
Carol Alpha Carol Houston
Alice Delta Dean Houston
Dean Delta
• Cannot have two or more managers managing
the same project at the same branch
Dr. NGPASC
COIMBATORE | INDIA
Multivalued dependencies

• Assume the column headings in a table are


divided into three disjoint groupings X, Y, and
Z
• For a particular row, we can refer to the data
beneath each group of headings as x, y, and z
respectively

Dr. NGPASC
COIMBATORE | INDIA
Fourth Normal Form

• A table is in 4NF iff


– For every one of its non-trivial multivalued
dependencies X => Y, X is either:
• A candidate key or
• A superset of a candidate key

Dr. NGPASC
COIMBATORE | INDIA
Example from Wikipedia

Restaurant Pizza DeliveryArea


Pizza Milano Thin crust SW Houston
Pizza Milano Thick crust SW Houston
Pizza Firenze Thin crust NW Houston
Pizza Firenze Thick crust NW Houston
Pizza Milano Thin crust NW Houston
Pizza Milano Thick crust NW Houston

Dr. NGPASC
COIMBATORE | INDIA
Discussion

• The table has no non-key attributes


– Key is { Restaurant, Pizza, DeliveryArea}
• Two non-trivial multivalued dependencies
– Restaurant => Pizza
– Restaurant => DeliveryArea
since each restaurant delivers the same pizzas
to all its delivery areas

Dr. NGPASC
COIMBATORE | INDIA
4NF Solution
Restaurant DeliveryArea
Pizza Milano SW Houston
Pizza Firenze NW Houston
Pizza Milano NW Houston
• Two separate tables
Restaurant Pizza
Pizza Milano Thin crust
Pizza Milano Thick crust
Pizza Firenze Thin crust
Pizza Firenze Thick crust
Dr. NGPASC
COIMBATORE | INDIA
Fifth normal form

• A table T is said to be 5NF iff


– Every non-trivial join dependency in it is implied
by its candidate keys

• A join dependency *{A, B, … Z} on T is implied


by the candidate key(s) of T if and only if each
of A, B, …, Z is a superkey for T

Dr. NGPASC
COIMBATORE | INDIA
An example

Store Brand Product


Circuit City Apple Tablets
Circuit City Apple Phones
Circuit City Toshiba Laptops
CompUSA Apple Laptops

• Note that Circuit City sells Apple tablets and phones


but only Toshiba laptops
Dr. NGPASC
COIMBATORE | INDIA
A very bad decomposition

Store Product Brand Product


Circuit City Tablets Apple Tablets
Circuit City Phones Apple Phones
Circuit City Laptops Apple Laptops
CompUSA Laptops Toshiba Laptops

• Let see what happens when we do a natural join

Dr. NGPASC
COIMBATORE | INDIA
The result of the join

Store Brand Product


Circuit City Apple Tablets
Circuit City Apple Phones
Circuit City Apple Laptops
Circuit City Toshiba Laptops
CompUSA Apple Laptops
CompUSA Toshiba Laptops

• Introduces
Dr. NGPASC
COIMBATORE | INDIA
two spurious tuples
A different table

Store Brand Product


Circuit City Apple Tablets
Circuit City Apple Phones
Circuit City Apple Laptops
Circuit City Toshiba Laptops
CompUSA Apple Laptops

• Assume now that any store carrying a given brand and


selling
Dr. NGPASC
a product that is made by that brand will
always carry that product
COIMBATORE | INDIA
The same decomposition

Store Product Brand Product


Circuit City Tablets Apple Tablets
Circuit City Phones Apple Phones
Circuit City Laptops Apple Laptops
CompUSA Laptops Toshiba Laptops

• Let see what happens when we do a natural join

Dr. NGPASC
COIMBATORE | INDIA
The result of the join

Store Brand Product


Circuit City Apple Tablets
Circuit City Apple Phones
Circuit City Apple Laptops
Circuit City Toshiba Laptops
CompUSA Apple Laptops
CompUSA Toshiba Laptops

• Still one spurious tuple


Dr. NGPASC
COIMBATORE | INDIA
The right decomposition
Store Product Brand Product
Circuit City Tablets Apple Tablets
Circuit City Phones Apple Phones
Circuit City Laptops Apple Laptops
CompUSA Laptops Toshiba Laptops

Store Brand
Circuit City Apple
Circuit City Toshiba
CompUSA
Dr. NGPASC
COIMBATORE | INDIA
Apple
Conclusion

• The first "big" table was 5NF


• The second table was decomposable

Dr. NGPASC
COIMBATORE | INDIA
Normalisation Example

• We have a table • Columns


representing orders – Order
in an online store – Product
• Each row represents – Quantity
an item on a – UnitPrice
particular order – Customer
• Primary key is – Address
{Order, Product}
Dr. NGPASC
COIMBATORE | INDIA
Functional Dependencies

• Each order is for a single customer:


– Order  Customer
• Each customer has a single address
– Customer  Address
• Each product has a single price
– Product  UnitPrice
• As Order  Customer and Customer  Address
– Order  Address
Dr. NGPASC
COIMBATORE | INDIA
2NF Solution (I)

• First decomposition
– First table
Order Product Quantity UnitPrice

– Second table
Order Customer Address

Dr. NGPASC
COIMBATORE | INDIA
2NF Solution (II)

• Second decomposition
– First table
Order Product Quantity
– Second table

Order Customer Address


– Third table

Product UnitPrice
Dr. NGPASC
COIMBATORE | INDIA
3NF

• In second table
Order Customer Address
– Customer  Address
• Split second table into

Order Customer

Dr. NGPASC
Customer Address
COIMBATORE | INDIA
Normalisation to 2NF

• Second normal form means • To remove the first FD we


no partial dependencies on project over
candidate keys {Order, Customer, Address}
– {Order}  {Customer, (R1)
Address} and
– {Product}  {UnitPrice} {Order, Product, Quantity, UnitPrice}
(R2)

Dr. NGPASC
COIMBATORE | INDIA
Normalisation to 2NF

• R1 is now in 2NF, but there • To remove this we project over


is still a partial FD in R2 {Product, UnitPrice} (R3)
and
{Product}  {UnitPrice}
{Order, Product, Quantity} (R4)

Dr. NGPASC
COIMBATORE | INDIA
Normalisation to 3NF

• R has now been split into 3 • To remove


relations - R1, R3, and R4 {Order}  {Customer} 
– R3 and R4 are in 3NF {Address}
– R1 has a transitive FD on • we project R1 over
its key – {Order, Customer}
– {Customer, Address}

Dr. NGPASC
COIMBATORE | INDIA
Normalisation

• 1NF:
– {Order, Product, Customer, Address, Quantity, UnitPrice}
• 2NF:
– {Order, Customer, Address}, {Product, UnitPrice}, and
{Order, Product, Quantity}
• 3NF:
– {Product, UnitPrice}, {Order, Product, Quantity},
{Order, Customer}, and {Customer, Address}

Dr. NGPASC
COIMBATORE | INDIA
Dr. NGPASC
COIMBATORE | INDIA 51

You might also like