Scribd
Upload
160 views29 pages

(M4S2 POWERPOINT) Normalization

The document provides an overview of relational database design and normalization. It defines key terms related to relational databases and normalization. The objectives are to define normalization terms, describe anomalies in data, and explain the process of normalization to eliminate anomalies and produce well-structured relations. It provides examples to demonstrate the concepts of functional dependencies, candidate keys, and applying first, second and third normal form to decompose relations and eliminate anomalies.

Uploaded by

Alexander T. Barsaga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
160 views29 pages

(M4S2 POWERPOINT) Normalization

The document provides an overview of relational database design and normalization. It defines key terms related to relational databases and normalization. The objectives are to define normalization terms, describe anomalies in data, and explain the process of normalization to eliminate anomalies and produce well-structured relations. It provides examples to demonstrate the concepts of functional dependencies, candidate keys, and applying first, second and third normal form to decompose relations and eliminate anomalies.

Uploaded by

Alexander T. Barsaga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

INFORMATION MANAGEMENT

MODULE 4: Relational Database Design and The


Relational Model
MODULE 4 SUBTOPIC 1

NORMALIZATION
MODULE 4

OBJECTIVES

■At the end of the chapter, the learner should be able to:
• Define terms
• List five properties of relations
• State two properties of candidate keys
• Define first, second, and third normal form
• Transform E-R and EER diagrams to relations
• Create tables with entity and relational integrity constraints
• Use normalization to convert anomalous tables to well-structured
relations
• Primarily a tool to validate and improve a logical design so
that it satisfies certain constraints that avoid unnecessary
duplication of data
• The process of decomposing relations with anomalies to
produce smaller, well-structured relations
• A relation that contains minimal data redundancy and allows users
to insert, delete, and update rows without causing data
inconsistencies
• Goal is to avoid anomalies

Figure 4-1
Example–Figure 4-2b

Question–Is this a relation? Answer–Yes: Unique rows and no multivalued


attributes

Question–What’s the primary key? Answer–Composite: EmpID, CourseTitle


• Types of Anomalies:

• Insertion Anomaly–adding new rows


forces user to create duplicate data
• Deletion Anomaly–deleting rows may
cause a loss of data that would be
needed for other future rows
• Modification Anomaly–changing data in a
row forces changes to other rows
because of duplication

General rule of thumb: A


table should not pertain to
more than one entity type.

Why do these anomalies exist?


Because there are two themes (entity types) in this one relation. This results in data
duplication and an unnecessary dependency between the entities.
Figure 4.22 Steps in normalization

3rd normal form is generally


considered sufficient
• For example, consider the relation EMP COURSE (EmpID, CourseTitle,
DateCompleted) shown in Figure 4-7. We represent the functional dependency
in this relation as follows:

• The comma between EmpID and CourseTitle stands for the logical AND
operator, because DateCompleted is functionally dependent on EmpID and
CourseTitle in combination.
• The functional dependency in this statement implies that the date when a
course is completed is determined by the identity of the employee and the title
of the course.
Typical examples of functional dependencies are the following:
1. SSN → Name, Address, Birthdate A person’s name, address, and birth date
are functionally dependent on that person’s Social Security number (in other
words, there can be only one Name, one Address, and one Birthdate for each
SSN).
2. VIN → Make, Model, Color The make, model, and the original color of a
vehicle are functionally dependent on the vehicle identification number (as above,
there can be only one value of Make, Model, and Color associated with each
VIN).
3. ISBN → Title, FirstAuthorName, Publisher The title of a book, the name of
the first author, and the publisher are functionally dependent on the book’s
international standard book number (ISBN).
• The attribute on the left side of the arrow in a functional dependencyis called a
determinant.
• SSN, VIN, and ISBN are determinants in the preceding three examples. In the
EMP COURSE relation (Figure 4-7), the combination of EmpID and
CourseTitle is a determinant.
• Candidate key is an attribute, or combination of
attributes, that uniquely identifies a row in a relation. A
candidate key must satisfy the following properties
,which are a subset of the six properties of a relation
previously listed:
• 1. Unique identification For every row, the value of the key must
uniquely identify that row. This property implies that each nonkey
attribute is functionally dependent on that key.
• 2. Nonredundancy No attribute in the key can be deleted without
destroying the property of unique identification.
STEPS IN NORMALIZATION
• No multivalued attributes
• Every attribute value is atomic
• Fig. 4-25 is not in 1st Normal Form (multivalued
attributes) ➔ it is not a relation.
• Fig. 4-26 is in 1st Normal form.
• All relations are in 1st Normal Form.
Table with multivalued attributes, not in 1st normal form

Note: This is NOT a relation.


Table with multivalued attributes, not in 1st normal form

Note: This is NOT a relation.


• Insertion –if new product is ordered for order 1007 of existing customer,
customer data must be re-entered, causing duplication
• Deletion –if we delete the Dining Table from Order 1006, we lose
information concerning this item’s finish and price
• Update –changing the price of product ID 4 requires update in multiple
records

Why do these anomalies exist?


Because there are multiple themes
(entity types) in one relation. This
results in duplication and an
unnecessary dependency between
the entities.
four determinants in INVOICE
1NF PLUS every 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
Figure 4-27 Functional dependency diagram for INVOICE

OrderID ➔ OrderDate, CustomerID, CustomerName, CustomerAddress


CustomerID ➔ CustomerName, CustomerAddress
ProductID ➔ ProductDescription, ProductFinish, ProductStandardPrice
OrderID, ProductID ➔ OrderQuantity

Therefore, NOT in 2nd Normal Form


Figure 4-28 Removing partial dependencies

Getting it into Second Normal


Form

Partial dependencies are removed, but there are still


transitive dependencies
• 2NF PLUS no transitive dependencies (functional dependencies on non-
primary-key attributes)
• Note: This is called transitive, because the primary key is a determinant for
another attribute, which in turn is a determinant for a third
• Solution: Non-key determinant with transitive dependencies go into a new
table; non-key determinant becomes primary key in the new table and stays as
foreign key in the old table
Figure 4-29 Removing partial dependencies

Getting it into Third Normal


Form

Transitive dependencies are removed.


In this lesson, you should have learned the following:
• Five properties of relations
• Two properties of candidate keys
• First, second, and third normal form
• Transform E-R and EER diagrams to relations
• Create tables with entity and relational integrity constraints
• Use normalization to convert anomalous tables to well-structured
relations
ASK ANY QUESTION RELATED TO OUR
TOPIC FOR TODAY.
• Taylor, A. G. (2019). SQL for dummies (9th ed.). Hoboken, NJ: For
Dummies.
• Harrington, J. (2016). Relational Database Design and Implementation
(4th Edition). Morgan Kaufmann
• Juric, N., Vrbsky, S., Nestorov, S. (2016). Database Systems: Introduction
to Databases and Data Warehouses. Prospect Press
• Kroenke, D. M., & Auer, D. J. (2016). Database Concepts. Pearson.
• Sullivan, D. (2015). NoSQL for Mere Mortals (1st ed.). Boston: Addison-
Wesley.
• Hoffer, J., Ramesh, V., Topi, H. (2013). Modern Database Management 11th
Edition, Prentice Hall.

You might also like