1. Database Lecture Notes Normalization 3 – Denormalization
Dr. Meg Murray

2. The Normalization Question How Many Tables?
Should we store these two tables as they are, or should we combine them into one table in our new database?

3. Let’s Do Another Example
What Form?

4. 1NF Eliminate repeating groups in individual tables.
Create a separate table for each set of related data.
Identify each set of related data with a primary key.

5. 2NF
Create separate tables for sets of values that apply to multiple records.
Relate these tables with a foreign key.

6. 3NF
Eliminate fields that do not depend on the key.

7. BCNF
Are all determinant keys also candidate keys?

8. The Question: Normalize or Denormalize

9. Type of Database Updateable database or read-only database?
If updateable database, we normally want tables in 3NF or BCNF
If read-only database, we may not use normalized tables
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

10. Normalization: Advantages and Disadvantages
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

11. Choosing Not to Normalize
Normalization is used to control anomalies from functional dependencies
There are times when normalization is not desirable
The classic example is ZIP codes:
ZIP codes almost never change
Any anomalies are likely to be caught by normal business practices
Not having to use two tables speeds up application processing
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

12. Normalize ZipCode
Is this table in 3NF?

13. Normalize ZipCode Functional Dependencies: Would you normalize this?
CustomerID->(Name, Street, City, State, ZipPostalCode)
Zip->(City, State)
Would you normalize this?

14. Normalize ZipCode Is this practical?
CUSTOMER(CustomerNumber, CustomerName, CustomerAddress, Zip, ContactName)
ZIP_CODE(Zip, City, State)
Is this practical?
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hallvvvvv

15. Designing Read-Only Databases

16. Read-Only Databases
Read-only databases are non-operational databases using data extracted from operational databases
They are used for querying, reporting and data mining applications
They are never updated (in the operational database sense – they may have new data imported form time-to-time)
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

17. Denormalization
For read-only databases, normalization is seldom an advantage
Application processing speed is more important
Denormalization is the joining of data in normalized tables prior to storing the data
The data is then stored in non-normalized tables
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

18. Denormalization
Normalizing relations (or breaking them apart into many component relations) may significantly increase the complexity of the data structure
The question is one of balance
Trading complexity for modification problems
There are situations where denormalized relations are preferred
Google uses denormalized tables
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

19. Normalized Tables KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

20. Denormalizing the Data
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

21. Customized Tables
Read-only databases are often designed with many copies of the same data, but with each copy customized for a specific application
Consider the PRODUCT table:
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall

22. Customized Tables
PRODUCT_PURCHASING (SKU, SKU_Description, VendorNumber, VendorName, VendorContact_1, VendorContact_2, VendorStreet, VendorCity, VendorState, VendorZip)
PRODUCT_USAGE (SKU, SKU_Description, QuantitySoldPastYear, QuantitySoldPastQuarter, QuantitySoldPastMonth)
PRODUCT_WEB (SKU, DetailPicture, ThumbnailPicture, MarketingShortDescription, MarketingLongDescription, PartColor)
PRODUCT_INVENTORY (SKU, PartNumber, SKU_Description, UnitsCode, BinNumber, ProductionKeyCode)
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition)
© 2008 Pearson Prentice Hall