BTM 382 Database Management Chapter 6: Normalization of Database Tables Chitu Okoli Associate Professor in Business Technology Management John Molson School of Business, Concordia University, Montréal 1

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) 2

Understand dependencies for normalization: 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 3

Understand dependencies for normalization: Repeating group = multivalued attribute Multivalued 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 4

Understand dependencies for 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 5

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 2NF: 1NF minus partial dependencies –All 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 –Only a problem if you missed multivalued attributes in 1NF DKNF, 5NF, 6NF –relatively rare and often not worth the trouble normalizing 6

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 7

8

9

3NF vs BCNF BCNF is only an issue because of poor selection of primary key for 1NF step Removing dependencies resolves table into BCNF 10

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, as the solution shows 11

Denormalization Although normalization is important, processing speed and efficiency is also important in database design 12

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: Database Systems: Design, Implementation and Management Other sources are noted on the slides themselves 13