1. University of Manitoba Asper School of Business 3500 DBMS Bob Travica
Chapter 3
Data Normalization
Based on G. Post, DBMS: Designing & Building Business Applications
Updated 2010

2. Practically boils down to defining tables so that
Normalization
The process of putting data into the format of relational databases (or, organizing data for relational databases)
Practically boils down to defining tables so that
a) problems (anomalies) with insertion, deletion and modification of data are avoided
b) data quality is preserved (completeness, integrity)
c) redundancy is reduced

3. Relational Database Terminology
Relational database: A collection of tables (relations). Tables store atomic data.
Table: A collection of columns (attributes, properties, fields)
describing an entity (class).
Table is also a collection of rows (records) each with the same number of columns.
Each row stores data on objects (entity instances).
EmployeeID TaxpayerID LastName FirstName HomePhone Address
Cartom Abdul (603) South Street
Venetiaan Roland (804) Paramaribo Ln
Johnson John (703) Main Street
Stenheim Susan (410) W. Maple
Attributes/
Properties
Rows/Objects
Entity (Class): Employee
Table: Employee

4. Relational Database Terminology – Primary Key
Every table has a primary key (key) – an attribute that uniquely
identifies each row (e.g., EmployeeID on previous slide)
Primary key can span more than one column combined (combined, composite, concatenated) key.
OrderItem
OrderID ItemID Quantity
Other attributes are called non-key columns.
Primary key can be generated automatically by DBMS – surrogate key.
Note: Watch for data types (e.g., number vs. text) and naming rules (arbitrary but consistent).

5. Relational Database Shorthand Notation
Primary key is underlined
Non-key columns
Table name
Customer(CustomerID, LastName, FirstName, Address, City, State, ZipPostalCode, TelephoneNumber) *
Note: Telephone number can be used as a “backup key.”

6. Order Management Application
Non-Normalized Class Diagram
Customer
Order
Salesperson
Item
OrderItem 1 *
Normalized Tables Diagram,
Schema
Customer
Order
Salesperson
Item 1 *
OrderItem
Association class
(ItemOrdered,
OrderDetail, etc.)

7. Shorthand Notation for Normalized Tables Diagram – Foreign Key
Customer(CustomerID, Name, Address, City, Phone)
Salesperson(EmployeeID, Name, DateHired)
Order(OrderID, OrderDate, CustomerID, EmployeeID)
OrderItem(OrderID, ItemID, Quantity)
Item(ItemID, Description, ListPrice)
Foreign Key = Attribute that is a key in another table (e.g., CustomerID in Order).
Logic & naming of OrderItem: Replacing the Order-Item many-to-many
relationship with two 1:M relationships.
OrderItem has a combined key—OrderID+ItemID.

8. NORMALIZATION

9. “Dynamic Data” (Transaction Data) — Operations Entities
Video Store Transaction Management System (VTMS): Classes, Columns & Business Rules
“Dynamic Data” (Transaction Data)
— Operations Entities
(change more often)
“Static (Master) Data”—
Market &Inventory Entities
(don’t change often)
Customer table
Key: CustomerID
Attributes:
Name
Address
Phone
Video table
Key: VideoID
Attributes :
Title
RentalFee
Rating…
RentalTransaction table
Key: TransactionID
Attributes :
CustomerID
Date
VideoRented table
Key: TransactionID + VideoID
Attributes:
Copy#
Business Rules: A customer can have many transactions… Each transaction can include
many videos… A transaction can include only one copy of a particular video...

10. Normalized Schema for STMS In Short Hand Notation
Customer(CustomerID, LastName, FirstName, Address, City, …)
Transaction data stored in 2
tables due to the business rule
that a rental transaction can
include just 1 copy of a video.
RentalTransaction(TransID, RentDate, CustomerID)
VideoRented(TransID, VideoID, Copy#)
Video(VideoID, Title, RentalFee)

11. Why Normalize – Avoiding data anomalies
How to get to those four tables from the business rule?
Are not these two tables enough?
Customer
Video
* rents *
Partial schema for this class diagram:
Customer(CustomerID, LastName, FirstName, … VideoID, Date)
Video(VideoID, Title, RentalFee)
Not good because:
Transaction data would have to be part of table Customer (or Video), which causes
repetition of Customer data for each transaction—redundancy.
Deletion of transaction data causes deletion of customer data—
deletion anomaly.
New customers cannot be added because VideoID as part of the key
in Video cannot be empty —insertion anomaly.

12. Normalization Customer Video * rents * RentalTransaction 1 * has
Rule of Thumb: Each many-to-many relationship must be replaced by
2 one-to-many relationships (see Customer-Order-Item above).
Customer
Video
* rents *
RentalTransaction 1 *
has
includes 1.
How to track
different copies
of same video?
Still M:M
Customer
Video
RentalTransaction 1 *
has
contains
VideoRented
1 includes*
is rented 2.
Table VideoRented tracks each copy of a particular video. Multiplicity on the video side is forced down to 1, which enforces the business rule that only 1 copy of a video can be rented out in a transaction (slides 9 & 10).

13. Normalization – Step by Step
RentalForm(TransID, RentDate, (CustomerID, Name, Address, City, State, …),
(VideoID, Copy#, Title, RentalFee))
Interview users, understand output needed. Put data into a large table (RentalForm).
Pick out attributes.
Find repeating groups.
Look for potential keys.
Identify computed values.

14. Problems with Repeating Groups (Sections)
RentalForm(TransID, RentDate, (CustomerID, Phone, Name, Address, City, State, …),
(VideoID, Copy#, Title, Rent))
Repeating Groups
TransID RentDate CustomerID LastName Phone Address VideoID Copy# Title Rent
1 4/18/02 3 Washington Easy Street : A Space Odyssey $1.50
1 4/18/02 3 Washington Easy Street 6 3 Clockwork Orange $1.50
2 4/30/02 7 Lasater S. Ray Drive 8 1 Hopscotch $1.50
2 4/30/02 7 Lasater S. Ray Drive 2 1 Apocalypse Now $2.00
2 4/30/02 7 Lasater S. Ray Drive 6 1 Clockwork Orange $1.50
Problems:
Insertion Anomaly: Inserting a Customer creates blank space in video and transactions columns. With VideoID as part of key, customer and video data must be inserted at the same time.
Deletion Anomaly: Delete transaction data => delete customer and video data.
Useless redundancy & wasted storage.
If there are repeating sections, the table is not in the first normal form (1NF).

15. First Normal Form (1NF)
1NF: A table is in 1NF if it does not have repeating sections.
Normalization Procedure:
Remove repeating sections by splitting the initial table into new tables.
Link new tables on the key from the initial table.
RentalTransaction(TransID, RentDate)
Video(TransID, VideoID, Copy#, Title, RentalFee)
Customer(TransID, CustomerID, Phone, Name, Address, City, State, ZipCod)
New
Reminder of
initial table

16. Problems with First Normal Form
Apply only to tables with concatenated keys:
TransID VideoID Copy# Title RentalFee
: A Space Odyssey $1.50
1 6 3 Clockwork Orange $1.50
2 8 1 Hopscotch $1.50
2 2 1 Apocalypse Now $2.00
2 6 1 Clockwork Orange $1.50
Video
There are problems concerning the relationship between the key and non-keys.
Concept of Functional Dependence:
An attribute depends on another attribute if changing the later causes a change of the former.
The key column must be sufficient for determining values of the non-key columns.

17. Problems with First Normal Form (cont.)
Copy# depends on full key (TransID + VideoID) --
Full Functional Dependency on the key.
Combined determine
Video(TransID, VideoID, Copy#, Title, RentalFee)
Sufficient to determine
VideoID is sufficient for predicting titles and rental fees.
There is Partial Functional Dependency between the combined key and Title and RentalFee.
If any non-key column depends just on a part of the key (there is partial functional dependence), the table is not in 2NF.

18. Second Normal Form (2NF)
2NF: A table is in 2NF if it is (a) is 1NF and (b) non-key columns depend on the entire key.
Normalization Procedure:
Move TransID and Copy# into a new table VideoRented.
Preserve a link between Video and VideoRented by importing VideoID in table VideoRented.
Video(TransID, VideoID, Copy#, Title, RentalFee)
move
export
VideoRented(TransID, VideoID, Copy#)
New
Video(VideoID, Title, RentalFee)
Resulting Video table

19. Finalize 2NF…
Table Customer must also be brought into 2NF by moving TransID
into table RentalTransaction (already there) and exporting CustomerID.
Customer(TransID, CustomerID, Phone, Name, Address, City, State,…)
RentalTransaction(TransID, RentDate, CustomerID)
move
export
Completed
Resulting Customer table
Customer(CustomerID, LastName, FirstName, Address, City, …)

20. Third Normal Form (3NF)
Problems with 3NF: If any non-key depends on some other non-key there is transitive dependency and the table is not in 3NF.
3 NF: Table is in 3NF if it is (a) in 2NF, and (b) each non-key attribute depends on the key only.
Our design is already in 3NF!
Customer(CustomerID, LastName, FirstName, Address, City, …)
VideoRented(TransID, VideoID, Copy#)
Video(VideoID, Title, RentalFee)
RentalTransaction(TransID, RentDate, CustomerID)

21. 3NF Example
Table in 2NF: Sales(CustomerID, CustomerName, Salesperson, Region)
Violation of 3NF: Region (non-key) is dependent on Salesperson.
Solution – split table into 12 tables: :
Sales(CustomerID, CustomerName, Salesperson)
Salesperson(Salesperson, Region)
Forms beyond the 3rd are very rare and reaching 3NF is sufficient for practical purposes.

22. Schema for VSTMS Allowing Multiple Copies per
Transaction
Customer(CustomerID, LastName, FirstName, Address, City, …)
Video(VideoID, Title, RentalFee)
RentalTransaction(TransID, CustomerID, VideoID, RentDate) 1 * * 1
Note:
Video key can be made unique: VideoID = 85.1 (decimal place designates a copy),
or 85c1 (text type), or use a bar code for each video and copy (ItemID).

23. Normalization Summary (Must know!)
1) If a table has repeating sections, there is huge redundancy and different classes are mixed together. Split the table, so that classes are clearly differentiated. Result: 1NF.
1NF: A table is in 1NF if it does not have repeating sections.
2) If a table has a combined key, non-key columns may depend on just a part of the primary key, and so there is partial functional dependency. Split the table so that in new tables non-keys depend on the entire key. Result: 2NF.
2NF: A table is in 2NF if it is in 1NF and non-key columns
depend on the entire key.
3) If a non-key depends on another non-key, there is transitive dependency. Split the table so that in new tables each non-key depends on the key and nothing but the key. Result: 3NF.
3NF: A table is in 3NF if it is in 2NF and all non-keys depend
on the key only.