1. Get data properly tabled!
University of Manitoba Asper School of Business 3500 DBMS Bob Travica
Chapter 3
Data Normalization
Get data properly tabled!
Based on G. Post, DBMS: Designing & Building Business Applications
Updated 2017

2. Normalization
The process of putting data into the format of relational databases or organizing data into
correctly designed tables.
Tables should be designed so that
a) problems (anomalies) with insertion, deletion and modification of data are avoided
b) redundancy is reduced
c) data quality is preserved (accuracy, completeness, consistency)

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 represents an object (an instance of a class).
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. A non-key depends on key.
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”, “secondary key”.
But the question today is, which tel. number (landline, cell; which cell number?)
* Shorthand notation is good for analysis but not for official diagrams. Do not use it in your assignments and exams.

6. Class Diagram to Schema
Class becomes table
Primary keys may expand (OrderItem)
Foreign keys created (complement PKs to support associations)
Multiplicity designed via PK-FK links (FK = “many” side)
Class Diagram
(Non-Normalized)
Customer
Order
Salesperson
Item 1 *
OrderItem
places
serves
contains
Customer
Order
Salesperson
Item
OrderItem 1 *
Schema –
Normalized Tables Diagram

7. Shorthand Notation for Schema:
Foreign Key Creation
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 (FK) = Attribute that is a (primary) key in another table (e.g., CustomerID in Order); encircled.
Logic & naming of OrderItem: Replacing the Order-Item M:N relationship with two 1:M relationships. Also common name: OrderDetail.
The OrderItem key is a combination of FKs (OrderID+ItemID).

8. NORMALIZATION
GET IN TABLE!

9. Video Store * Transaction Processing System (VSTPS): Classes
Transaction Data (“Dynamic” )
— Operations Entities
(change more often)
Master Data (“Static”)—
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#
* Video refers to blu ray disks, video games, etc.

10. Business Rules and Class Diagram for VSTPS
Business Rules for multiplicity:
A customer can have many rental transactions, each being for a specific customer.
A transaction can include many video titles, and a title is in many transactions.
A transaction can include only one copy of a video title (quantity is 1).
Customer
VideoTitle
RentalTransaction 1 *
has
includes
VideoCopy
Rented

11. Schema for VSTPS
You can create a schema almost entirely based on your knowledge of data analysis and multiplicity; Table 3 may be a bit tricky. 1
Tbl 1
Customer(CustomerID, LastName, FirstName, Address, City, …) *
Tbl 2
RentalTransaction(TransID, RentDate, CustomerID) 1
Transaction
data *
Tbl 3
VideoRented(TransID, VideoID, Copy#) * 1
Tbl 4
Video(VideoID, Title, RentalFee)

12. Normalization Process
To arrive at a class diagram and then schema, start with the system requirements task (talk with users, understand output that exists and that is needed in the future).
Which classes does this electronic form indicate? What are the possible class associations, attributes, keys?
Classes indicated (min.):
CUSTOMER
TRANSACTION
VIDEO
These classes translate into
3 tables. Put together,
it is a big chunk of data
shown below in a mock-up
(incorrect) table.
RentalForm(TransID, RentDate, ((CustomerID, Name, Address, City, State, …), (VideoID, Copy#, Title, RentalFee))

13. Why Normalize – Avoiding Data Anomalies
How to get to proper tables using normalization logic? Why not use that one table
RentalForm?
RentalForm(TransID, RentDate, ((CustomerID, Name, Address, City, State, …), (VideoID, Copy#, Title, RentalFee))
Poor design because:
Master data (Customer, Video) repeat for each transaction - high redundancy.
Deletion of transaction data causes deletion of master data and reverse – deletion anomaly: Cannot delete target data but more (or less) than wanted.
A new customer can’t be added without adding a new video and reverse – insertion anomaly: Data can’t be added without corrupting (faking) other data.
To change customer name, all records must be rewritten –
update anomaly: Data can’t be updated just in a single master record.
Conclusion: From the normalization perspective, data must be properly designed in order to avoid CRUD* anomalies and reduce redundancy.
* Data Reading (retrieval) is not included in anomalies but it is apparent that the single class design above
causes major retrieval problems.

14. Normalization Process
A process of creating tables that are free from data anomalies.
Practically, create master and transactional tables, and connect them via PK-FK associations.
Each M:N relationship must be replaced by two 1:M relationships.
A split & relate process.
RentalForm
(Customer, Video, RentalTransaction)
At the level of class
diagramming, 3 classes
at least can be created.
Assume this is bypassed
we work with just 1 table.
Split in 3 tables
A rental transaction
contains M videos,
each video
rented M times.
Relating data preserved
via keys (e.g., CustomerID
exported from RentalForm
to Customer, same for Video).
RentalTransaction
Customer
Video 1 *
M, N = “Many”

15. Normalization Process (cont.)
- To track each copy of a video (video title), RentalTransaction is
further split.
- New table VideoRented stays connected by exporting
RentalTranscationID into VideoRented.
- Changes in multiplicity (encircled 1s). 1
RentalTransaction *
VideoRented (copy#) * 1
A rental transaction
contains a particular
copy of each video rented. * 1
Customer
Video

16. Three Normal Forms There are three normal forms we study:
First normal form (1NF)
Second normal form (2NF)
Third normal form (3NF)
The goal of the normalization process is to arrive at 3NF that suffers no data anomaly. Tables in 3NF are normalized (except for some very rare cases).
When no data anomaly is present, all non-key attributes depend only on the key attribute. Technically, there is a full functional dependence of the values of the non-key columns on the values of the key column.

17. Functional Dependence Between the Key and Other Columns
The key column must be sufficient for determining values of the non-key columns.
An attribute depends on another attribute if the change of its value is caused by a change of that other attribute’s value.
From this perspective, the goal of the normalization process is to establish the full Functional Dependence between the key and non-key columns, driving out all other dependencies (Partial Functional Dependence, and Transitive Dependence).
determines
Key
Non-key columns
Full Functional Dependence
(Key determines non-key values)
Non-key columns
Key
Partial Functional Dependence
(Part of key determines some non-key values)
Key
Non-key columns
Transitive Dependence (Non-key attribute
determines another non-key)

18. 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.
Similar to recognizing classes and transforming them into tables.
Ask after removing repeating sections: Can values of non-key attributes be predicted form the key values?
RentalTransaction(TransID, RentDate) + CustomerID (FK)
Video(VideoID, Copy#, Title, RentalFee)
Customer(CustomerID, Phone, Name, Address, City, State)
New tables
Reminder of
table RentalForm ?*
*CopyID causes Title and Rental to repeat for each copy.
New tables
Video(VideoID, Title, RentalFee)
Reminder of
table Video
VideoRented(VideoID, Copy#) + TransID (FK)

19. Anomalies with Repeating Sections
RentalForm(TransID, RentDate, ((CustomerID, Phone, Name, Address, City, State, …),
(VideoID, Copy#, Title, Rent))
Repeating sections
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
Repeating groups cause
high redundancy
update anomaly (must run through all records)
insertion anomaly causes wrong data (fake CustomerID if new video added)
- deletion anomaly (can’t delete simply what is needed)
If there are repeating sections, the table is not in the first normal form (1NF).

20. 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.
The 2NF test applies only to tables with the key that has two or more attributes – combined (concatenated) key.
Suppose that table Video is like below.
Combined determine
Video(TransID, VideoID, Copy#, Title, RentalFee)
Sufficient to determine
VideoID suffices for predicting title and rental fees, TransID may refer to many titles. Therefore, there is Partial Functional Dependence between the combined key and Title and RentalFee.
Just Copy# can be predicted from both TransID and VideoID.

21. Second Normal Form (2NF), cont’d
If any non-key column depends just on a part of the key there is partial functional dependence and the table is not in 2NF.
Solution: Split tables and get results as on slide 17.
Video(VideoID, Title, RentalFee)
VideoRented(TransID, VideoID, Copy#)
*Neither TransID nor VideoID on their own can predict Copy# of a rented video title.
**It is true that TransID suffices for predicting values of all other attributes, but it is not really needed for predicting Title
and RentalFee because these are predictable from VideoID.

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

23. 3NF Violation Examples
Tables in 2NF but there is transitive dependence:
RentalTransaction(TransID, RentDate, CustomerID, CustomerStanding)
Solution: put CustomerStanding in tbl Customer
Sale(SaleID, CustomerID, SalespersonID, SalespersonRank…)
Solution: split
Sale(SaleID, CustomerID, SalespersonID)
Salesperson(SalespersonID, SalespersonRank)
Forms beyond the 3rd are very rare and therefore reaching 3NF is sufficient for most of practical purposes.
When we say “create schema”, we mean “create tables that are in 3NF”.

24. Summary of Normal Forms (Must know by heart!)
1) If a table has repeating sections, there is huge redundancy, different classes are mixed together, and all anomalies occur. 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 combined 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-key columns
depend on the key only.