September 24, R McFadyen1 The objective of normalization is sometimes stated “to create relations where every dependency is on the primary key, the whole primary key, and nothing but the primary key” Database designers are always looking for (OLTP) databases that are as simple as possible - ones that are easiest to keep consistent, ones where the semantics are clear. Normalization

September 24, R McFadyen2 Certain relation schemas have update anomalies - they may be difficult to understand and maintain Normalization theory recognizes this and gives us some principles to guide our designs Normal Forms: 1NF, 2NF, 3NF, BCNF, 4NF, … are each an improvement on the previous ones in the list Normalization

September 24, R McFadyen3 Normalization is a process (involves decomposition) that generates tables of higher normal forms. Denormalization moves from higher to lower forms and is done for performance reasons. Normalization

September 24, R McFadyen4 Suppose we have EmployeeProject Anomalies EmployeeProject holds information about employees and the projects they work on emp_num: employee’s social insurance number proj_num: a project number ep_hours: the hours the employee has worked on the project emp_name: the employee’s name proj_loc: the location of the project PK is {emp_num, proj_num} emp_numproj_numep_hoursemp_nameproj_loc

September 24, R McFadyen5 An instance of the table: emp_numproj_numep_hoursemp_name EmployeeProject proj_loc Anomalies 11236JonesEdmt 11362JonesWpg JonesBrandon 17235SmithEdmt 17362SmithWpg SmithWpg

September 24, R McFadyen6 EmployeeProject Anomalies we will have redundant information in the database … if more than one employee works on the same project, then the project location is repeated if some employee works on more than one project, then the employee’s name is repeated emp_numproj_numep_hoursemp_nameproj_loc

September 24, R McFadyen7 Redundant data leads to additional space requirements update anomalies Anomalies

September 24, R McFadyen8 Suppose EmployeeProject is the only relation where the Project Location is recorded insert anomalies adding a new project is complicated, unless there is also an employee for that project deletion anomalies if we delete all employees for some project, then what should happen to the project information? modification anomalies if we update the location of a project, then we must change it in all rows referring to that project Anomalies

September 24, R McFadyen9 If we design a database with a relation such as EmployeeProject then we will have complex update rules to enforce. difficult to code correctly will not be as efficient as possible Such designs mix concepts. E.g EmployeeProject mixes the Employee and Project concepts Such designs are (generally) not good for OLTP Anomalies

September 24, R McFadyen10 Suppose we have a relation R comprising attributes X,Y, … We say a functional dependency exists between the attributes X and Y, if, whenever a tuple exists with the value x for X, it will always have the same value for y for Y. emp_numemp_name emp_gender emp_phone XY Employee Given a specific employee number, there is only one value for name, one value for gender, and only one value for phone Emp_number is a determinant for emp_name, emp_gender, emp_phone Functional dependencies emp_numemp_genderemp_nameemp_phone

September 24, R McFadyen11 a series of normal forms are known that have, successively, better update characteristics we’ll consider 1NF, 2NF, 3NF, and BCNF a technique used to improve a relation is decomposition, where one relation is replaced by two or more relations. When we do so, we want to eliminate update anomalies without losing any information. Our target is BCNF Normal Forms

September 24, R McFadyen12 The Dependency Diagram  illustrates a single-attribute PK (simple PK)  all employee attributes are dependent on the PK Employee emp_numemp_genderemp_nameemp_phone

September 24, R McFadyen13 Partial Dependency PROJ_CODEEMP_NUMPROJ_NAMEHRS_WORKED  Multi-attribute PK (composite PK)  HRS_WORKED is dependent on the PK  But PROJ_CODE, which is only a part of the PK, determines PROJ_NAME (equivalently, PROJ_NAME is dependent on PROJ_CODE) Partial dependency

September 24, R McFadyen14 Transitive Dependency STU_NUMSTU_LNAMEDEPT_CODEDEPT_NAME All student attributes are dependent on the PK But DEPT_CODE determines DEPT_NAME (or DEPT_NAME is dependent on DEPT_CODE, a non-key attribute Transitive dependency

September 24, R McFadyen15 BCNF all determinants are candidate keys INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Example, consider: Partial dependency Transitive dependency

September 24, R McFadyen16 BCNF - all determinants are candidate keys INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Determinants: prod_code prod_title inv_num cus_num inv_num, prod_code line_units Three determinants, but only one is a candidate key. Therefore, not in BCNF

September 24, R McFadyen17 BCNF - all determinants are candidate keys INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Three determinants: prod_code inv_num {prod_code, line_units} but only one is a candidate key. Therefore, not in BCNF A table with these attributes will have a lot of redundancy.

September 24, R McFadyen18 Decomposition We can decompose the single table into three tables where there will be no unnecessary redundancy no loss of information - we can join the three to have what we had before no loss of dependencies INV_NUM LINE_NUM PROD_CODE PROD_TITLE LINE_UNITS INV_NUMCUS_NUMPROD_CODE

September 24, R McFadyen19 Decomposition Each of these tables is in BCNF INV_NUM LINE_NUM PROD_CODE PROD_TITLE LINE_UNITS INV_NUMCUS_NUM PROD_CODE

September 24, R McFadyen20 INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Consider: This table is not in 2NF because it has a partial dependency: CUS_NUM is dependent on INV_NUM Partial dependency

September 24, R McFadyen21 First Normal Form (1NF) Each row/column intersection contains one and only one value, rather than a set of values All attributes are dependent on the primary key

September 24, R McFadyen22 EMP_NUMEMP_LNAMEEMP_FNAMEEMP_DOB This table is in 1NF. Question to answer later: is it in 2NF? 3NF? BCNF? First Normal Form (1NF) Consider

September 24, R McFadyen23 First Normal Form (1NF) INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS This table is in 1NF. Question to answer later: is it in 2NF? 3NF? BCNF? Consider

September 24, R McFadyen24 The Second Normal Form (2NF)  Meets 1NF requirements  Does not contain partial dependencies  But may contain transitive dependencies

September 24, R McFadyen25 Decomposition A table can be decomposed into two or more tables. Ideally, this involves: no loss of information all information previously available can be obtained by joining the new tables - a lossless decomposition no loss of dependencies a dependency-preserving decomposition

September 24, R McFadyen26 INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Consider: This table is not in 2NF because it has a partial dependency: CUS_NUM is dependent on INV_NUM Partial dependency

September 24, R McFadyen27 INV_NUM LINE_NUM PROD_CODEPROD_TITLECUS_NUM LINE_UNITS Consider: We need to decompose the table - move the partial dependency to a new table. I.e. Invoice information belongs elsewhere. Partial dependency

September 24, R McFadyen28 Decomposition create a new table don’t lose any information (can still derive) INV_NUM LINE_NUM PROD_CODEPROD_TITLE LINE_UNITS INV_NUMCUS_NUM No partial dependencies present!

September 24, R McFadyen29 The Third Normal Form (3NF)  Meets 2NF requirements  Does not contain transitive dependencies

September 24, R McFadyen30 Consider: Because of the transitive dependency, this table is not in 3NF Transitive dependency INV_NUM LINE_NUM PROD_CODEPROD_TITLE LINE_UNITS We need to decompose the table - move the transitive dependency to a new table. I.e. Product information belongs elsewhere.

September 24, R McFadyen31 INV_NUM LINE_NUM PROD_CODE LINE_UNITS Decomposition create a new table don’t lose any information (can still derive) There is no transitive dependency here! PROD_CODEPROD_TITLE

September 24, R McFadyen32 The Boyce-Codd Normal Form (BCNF)  Meets 3NF requirements  Every determinant in the table is a candidate key  Focus is on determinants

September 24, R McFadyen33 Example consider the following functional dependencies and table structure city, streetnamepostalcode postalcodecity citystreetnamepostalcode Note that this table does have redundant data, and from a theoretical perspective, would have anomalies associated with it. Address

September 24, R McFadyen34 Example city, streetnamepostalcode postalcodecity citystreetnamepostalcode Let us consider the more formal/complete definitions in the text, and then ask: What are the non-key attributes? What is the primary key? What is the normal form of Address? Address

September 24, R McFadyen35 From the text: A relation R is in 2NF if every nonprime attribute of A is not partially dependent on any key R. nonprime: an attribute is nonprime if it is not a member of a candidate key. prime: an attribute is prime if it is a member of a candidate key. citystreetnamepostalcode Address In our example, there are no nonprime attributes Hence the table is in 2NF

September 24, R McFadyen36 From the text: A relation R is in 3NF if, whenever a functional dependency x --> A holds in R, either a) X is a superkey of R, or b) A is a prime attribute of R. One of the things that this says is: if a nonprime attribute A is dependent on some attribute, that determinant must include the key. citystreetnamepostalcode Address In our example, there are no nonprime attributes Hence the table is in 3NF

September 24, R McFadyen37 Is every determinant a candidate key? NO citystreetnamepostalcode Address Hence the table is not BCNF What decomposition would preserve dependencies and have BCNF tables? Is this a practical example?