Need for Normalization Figure 4.1 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Figure 4.1 Observations PRO_NUM intended to be primary key Table entries invite data inconsistencies Table displays data anomalies Update Modifying JOB_CLASS Insertion New employee must be assigned project Deletion If employee deleted, other vital data lost Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Dependency Diagram (1NF) Figure 4.4 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Data Organization: 1NF (“Flattening” the table) Primary Key is PROJ_NUM, EMP_NUM Figure 4.3 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

1NF Summarized All key attributes defined (non-null) No repeating groups in table All attributes dependent on primary key Consequently all rows unique All this is part of “being relational” Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

2NF Conversion Results PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) ASSIGN (PROJ_NUM, EMP_NUM, HOURS) Figure 4.5 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

2NF Summarized In 1NF Includes no partial dependencies No attribute dependent on a portion of primary key 1NF with singleton primary key always 2NF Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Transitive Dependencies A  C is a transitive dependency if there is a B such that A  B and B  C where A is not functionally dependent on B and A is not functionally dependent on C Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

3NF In 2NF Contains no transitive dependencies outside the primary key To convert to 3NF, project out the dependency: JOB (JOB_CLASS, CHG_HOUR) PROJECT (PROJ_NUM, PROJ_NAME) ASSIGN (PROJ_NUM, EMP_NUM, HOURS) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS) Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Boyce-Codd Normal Form (BCNF) Codd originally did not consider the case where 1. There are 2 or more candidate keys 2. The keys are composite 3. They overlap To be in BCNF, every determinant must be a candidate key Notes: Determinant is attribute on the left of a FD 3NF table with only one candidate key is always in BCNF Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Solutions for problems 1 & 3 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

3NF Table Not in BCNF Figure 4.7 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Decomposition of Table Structure to Meet BCNF Figure 4.8 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel

Decomposition into BCNF Figure 4.9 Database Systems: Design, Implementation, & Management, 5th Edition, Rob & Coronel