Post on 03-Jan-2016
description
BTM 382 Database Management
Chapter 6:Normalization of Database Tables
Chitu OkoliAssociate Professor in Business Technology Management
John Molson School of Business, Concordia University, Montréal
Problems with unnormalized tables
Needless redundancy, hence insert, update and delete anomalies (inconsistencies)
Data updates are less efficient because tables are larger
Indexing is more cumbersome No simple strategies for creating views (virtual tables)
Understanding dependencies to be able to properly normalize tables
Functional dependency
Functional dependency: A→B or (A,B)→(C,D) B is functionally dependent on A means that knowing A will therefore give
you the correct value of B E.g. Project.ID → Project.Name Also called determination: “A determines B”
Full functional dependency: (A,B)→C where A→�C and B→�C When all the attributes in a key are required for the determination (none is
optional) E.g. (Project.ID, Project.Manager) → Project.Name
Project.Manager is optional—this is not a full functional dependency E.g. (Project.Manager, Project.StartDate) → Project.Name
This is a full functional dependency, assuming a manager can launch no more than one project on a given date
Repeating group = multivalued attributeMultivalued dependency Repeating group = multivalued attribute
Attribute whose values contain multiple values (a list or array of values), instead of a single value
Illegal in the relational model; troublesome for normalization if you don’t catch it
Functional dependency: A→B Multivalued dependency: A→B1/B2/B3/…/Bn
Instead of determining just one value of B in a table, A determines multiple values at the same time
E.g. Project.ID → Project.EmployeeID Usually indicates a problem with normalization
Partial and transitive dependencies
Partial dependency: (A,B)→(C,D) and B→C (A,B) is a candidate key (e.g. primary key) C doesn’t need both A and B to determine it; it only needs B E.g. (Project.ID,Project.ManagerID) → Project.Name
and Project.ID → Project.Name
Transitive dependency: A→(B,C) and B→C A is a candidate key
Technically speaking, a transitive dependency requires that B and C not be part of any candidate key. However, if you expand the meaning to include even if they are part of the key, then you will avoid BCNF automatically
A determines C, but so does B, even though B is not a candidate key
E.g. Project.ID → (Project.Client,Project.Location)and Project.Client → Project.Location
The normal forms
Summary of attaining normal forms
1NF: Primary key identified and no multivalued attributes Legitimate primary key selected (unique identifying key) Only one value per table cell; no lists/arrays (multivalued attributes) in any table cell
If you split multivalued attributes off to separate tables, then you avoid 4NF violations
2NF: 1NF minus partial dependencies All candidate key dependencies are fully functional
(A,B)→C where A→=C and B→=C
3NF/BCNF: 2NF minus transitive dependencies Only a candidate key determines any attribute
If A→(B,C), then B →= C There is a technical distinction between 3NF and BCNF, but if you keep this rule, then you
take care of both 3NF and BCNF
4NF: BCNF minus multivalued dependencies Each row strictly describes just one entity
If you split multivalued attributes into separate tables to attain 1NF, then you also avoid 4NF violations
DKNF, 5NF, 6NF relatively rare and often not worth the trouble normalizing, even if applicable
Dependency diagram:Basic tool for normalization Depicts all dependencies found in a given table structure Gives bird’s-eye view of all relationships among table’s
attributes Makes it less likely that you will overlook an important
dependency
3NF vs BCNF
BCNF is only an issue because of poor selection of primary key for 1NF step
Regardless, dealing with all dependencies resolves table into BCNF
Fixing 4NF problem
The only reason a table might be in 3NF/BCNF but not in 4NF is because two originally multivalued attributes existed at 1NF stage
Two multivalued attributes should always be placed in separate tables If you do this in the
first step to resolve 1NF, you will never have problems with 4NF
Denormalization
Denormalization Although normalization is important, processing
speed and efficiency is also important in database design
Sources
Most of the slides are adapted from Database Systems: Design, Implementation and Management by Carlos Coronel and Steven Morris. 11th edition (2015) published by Cengage Learning. ISBN 13: 978-1-285-19614-5
Other sources are noted on the slides themselves