1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Basic Normal Forms These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

2. 2 © Ellis Cohen 2001-2008 Overview of Lecture Normal Forms 1st Normal Form 2nd Normal Form Conceptual 2NF Normalization PURE 3rd Normal Form MIXED 3rd Normal Form Factoring & MIXED 3rd Normal Form Normalization with Nested Determinants Normalization with Overlapping Determinants

3. 3 © Ellis Cohen 2001-2008 Normal Forms –1NF, 2NF, 3NF, BCNF, 4NF, 5NF(PJNF) –Property of a table From 2NF on –Each one defines a new kind of non-redundancy requirement –Each one requires the previous one To deal with a relation that fails to satisfy a particular normal form: –the relation is decomposed in a particular way

4. 4 © Ellis Cohen 2001-2008 1st Normal Form

5. 5 © Ellis Cohen 2001-2008 1NF: 1st Normal Form All fields in a relation must be atomic 1NF is not about Redundancy, but about ensuring that entity classes / relations are in a form that we can easily normalize (A form of normalization can actually be defined for relations with non-atomic field, but it is more complicated) 40694…{ Sam } 15129… 30276…{ Willlam, Norman } 81107…{ Josh, Jake } 60019 … empno … kids Emps

6. 6 © Ellis Cohen 2001-2008 Relational 1NF Normalization 40694… 15129… 30276… 81107… 60019 … empno ename Employees 40694Sam 30276Willlam 30276Norman 81107Josh 81107Jake empno childnam Children empno childnam Emps new empno ename Emps old empno ename *kids Normalize by 1) Remove multivalued attribute from relation 2) Create new relation with composite key: single-valued version of attribute + original relation's primary key What's the corresponding conceptual normalization?

7. 7 © Ellis Cohen 2001-2008 Conceptual 1NF Normalization Normalize By 1)Remove multivalued attribute from entity class 2)Add a weak entity class dependent upon the original class with the single-valued version of the attribute Employee empno ename Child childnam has Employee empno ename *kids Multivalued

8. 8 © Ellis Cohen 2001-2008 2nd Normal Form

9. 9 © Ellis Cohen 2001-2008 2NF: 2nd Normal Form No partial key dependencies: The determinants of a non-prime attribute CANNOT consist of only part of a candidate key Entries( invid, linenum, customer, prodid ) invid  customer prime attributesnon-prime attributes 3049217 JONES 6171 304931CHEN4059 304932CHEN6171 304933CHEN2184 304941SONI3792 invid linenum customer prodid Entries

10. 10 © Ellis Cohen 2001-2008 2NF Violation Diagram: Partial Key Violation prime attributesnon-prime attributes Candidate key linenum customer Determinant(s) invid

11. 11 © Ellis Cohen 2001-2008 Comparing NF Diagrams prime attributesnon-prime attributes Candidate key linenum customer Determinant(s) invid linenum prodid invid 2NF Violation In 2NF

12. 12 © Ellis Cohen 2001-2008 Relational 2NF Normalization 30492JONES 30493CHEN 30494SONI invid customer Invoices invid customer Entries new invid linenum prodid Entries old invid linenum customer prodid Normalize by 1) Create a new relation with the determinant and everything dependent upon it 2) Remove everything dependent upon the determinant from the original relation 3) Add foreign key constraint, possibly w cascading delete 3049217 6171 3049314059 3049326171 3049332184 3049413792 invid linenum prodid Entries invid  customer

13. 13 © Ellis Cohen 2001-2008 Corresponding Conceptual Model InvoiceEntry invid customer linenum prodid Invoices invid customer Entries invid linenum prodid

14. 14 © Ellis Cohen 2001-2008 Normalization Exercise Original Table: Dog( ssno, dogname, dogdob, oaddr, ophone ) –ssnosoc sec# of dog's owner –dognamename of dog –dogdobdate of birth of dog –oaddraddr of the owner –ophonephone # of the owner 1)What are the candidate keys? 2)What are the prime attributes? 3)What FD's are determined by a candidate key? 4)What FD's are not determined by a candidate key?

15. 15 © Ellis Cohen 2001-2008 Normalization Answer: FD's Candidate Keys ssno + dogname Prime Attributes ssno, dogname Candidate Key FD's ssno + dogname  dogdob Non Candidate Key FD's ssno  oaddr, ophone Normalize!

16. 16 © Ellis Cohen 2001-2008 Normalization Answer: Design What's the corresponding conceptual model? Dogs ssno dogname dogdob Owners ssno oaddr ophone

17. 17 © Ellis Cohen 2001-2008 Normalized Conceptual Model Dogs ssno dogname dogdob Owners ssno oaddr ophone OwnerDog ssno oaddr ophone dogname dogdob

18. 18 © Ellis Cohen 2001-2008 Conceptual 2NF Normalization

19. 19 © Ellis Cohen 2001-2008 Conceptual 2NF Normalization Partial key violations can be seen and fixed during Conceptual Modeling. Given the following entity class and FD, how should the entity class be decomposed? Entry invid linenum customer prodid invid  customer

20. 20 © Ellis Cohen 2001-2008 Conceptual 2NF Normalization Entry invid linenum customer prodid InvoiceEntry invid customer linenum prodid Normalize By 1)Move determinant and everything dependent on it to a new entity class. 2)The original class becomes a weak entity class, with the remaining parts of the key as the discriminator invid  customer invid + linenum  prodid invid  customer What's the corresponding relational normalization ?

21. 21 © Ellis Cohen 2001-2008 Relational 2NF Normalization Invoices invid customer Entries new invid linenum prodid Entries old invid linenum customer prodid Normalize by 1) Create a new relation with the determinant and everything dependent upon it 2) Remove everything dependent upon the determinant from the original relation 3) Add foreign key constraint, possibly w cascading delete invid  customer

22. 22 © Ellis Cohen 2001-2008 Another Normalization Exercise Original Entity Class Assign( empno, ename, pno, pname, taskid, tname, startdate, hrsPerWeek ) Minimal Non-Candidate Key FD's empno + pno  startdate empno  ename pno  pname taskid  tname Start by doing 2NF conceptual normalization based on this FD In many cases, the entire normalization can be done using the conceptual model

23. 23 © Ellis Cohen 2001-2008 Initial Normalization Step ProjAssignAssign owned by empno ename pno pname startdate taskid tname hrsPerWeek Now normalize Assign based on taskid  tname This is also 2NF, because taskid is a discriminator, and only part of the primary key empno + pno  startdate empno + pno + taskid  hrsPerWeek

24. 24 © Ellis Cohen 2001-2008 Normalization by Task ProjAssignAssign empno ename pno pname startdate hrPerWeek Now normalize based on empno  ename Task taskid tname empno + pno  startdate empno + pno + taskid  hrsPerWeek taskid  tname

25. 25 © Ellis Cohen 2001-2008 Normalization by Employee ProjAssign pno pname startdate Employee empno ename empno + pno + taskid  hrsPerWeek taskid  tname Assign hrPerWeek Task taskid tname Now normalize based on pno  pname

26. 26 © Ellis Cohen 2001-2008 Complete Normalization ProjAssign startdate Employee empno ename Project pno pname empno + pno + taskid  hrsPerWeek taskid  tname Assign hrPerWeek Task taskid tname

27. 27 © Ellis Cohen 2001-2008 PURE 3rd Normal Form

28. 28 © Ellis Cohen 2001-2008 2NF & 3NF Normalizations The decomposition rules are –Create a new relation/class with the determinant and everything dependent upon it –Relational: Remove everything dependent upon the determinant from the original relation –Conceptual: Remove the determinant and everything dependent upon it from the original class Each normal form variant results in a different design pattern –Relational fingerprints vary wrt resulting primary and foreign keys –Conceptual models vary wrt primary keys, discriminators, and kinds of relationships

29. 29 © Ellis Cohen 2001-2008 3NF: 3rd Normal Form A table is in 3NF if every non-prime attribute is minimally determined by a candidate key If not, we have –2NF Violation a non-prime attribute is determined by only part of a candidate key –3NF-ONLY Violations the determinant of a non-prime attribute includes some other non-prime attribute

30. 30 © Ellis Cohen 2001-2008 2NF/Pure 3NF Violations prime attributesnon-prime attributes C A BX 2NF Partial Key Violation 3NF Transitivity Violation X BA Candidate Key Pure

31. 31 © Ellis Cohen 2001-2008 Pure 3NF Violation Example prime attributes non-prime attributes deptno dname empno ename address deptno dname Emps

32. 32 © Ellis Cohen 2001-2008 Relational Pure 3NF Normalization Normalize by 1) Create a new relation with the determinant and everything dependent upon it 2) Remove everything dependent upon the determinant from the original relation 3) Add foreign key constraint, possibly w cascading delete empno ename address deptno dname Emps old deptno  dname Emps new empno ename address deptno Depts deptno dname

33. 33 © Ellis Cohen 2001-2008 Corresponding Conceptual Model EmployeeDept empno ename address deptno dname Emps empno ename address deptno Depts deptno dname

34. 34 © Ellis Cohen 2001-2008 Another Pure 3NF Example Video( vidid, title, year, custid, studio ) title + year  studio 61809Mouth1988S611Universal 30512Zanzibar1931S611Paramount 49177Follow Me2001S611Universal 21534Mouth1988P309Universal 30857Zanzibar1993F247Disney vidid title year custid studio Videos prime attributesnon-prime attributes

35. 35 © Ellis Cohen 2001-2008 Corresponding Conceptual Model Films title year studio Videos vidid title year custid VideoFilm vidid custid title year studio

36. 36 © Ellis Cohen 2001-2008 Conceptual Pure 3NF Normalization Video vidid title year custid studio Normalize by 1)Move determinant and everything dependent on it to a new entity class. 2)The original entity class becomes the child entity class in a 1:M relationship with the new class VideoFilm vidid custid title year studio Child entity classParent entity class vidid  custid title + year  studio vidid  title, year Note how FD's become unique or key constraints What about Video's lifetime?

37. 37 © Ellis Cohen 2001-2008 Deciding Lifetime Dependency VideoFilm is a copy of a vidid custid title year studio FilmVideo title year studio vidid custid is a copy of a Should we treat Video as a strong entity class, or as a dependent entity class (i.e. with a lifetime dependency constraint) Normalization doesn't tell us what to do here. This is an independent design issue.

38. 38 © Ellis Cohen 2001-2008 MIXED 3rd Normal Form

39. 39 © Ellis Cohen 2001-2008 2NF/3NF Violation Diagrams prime attributesnon-prime attributes C A BX 2NF Partial Key Violation 3NF Transitivity Violation X X BCA Pure Mixed BA

40. 40 © Ellis Cohen 2001-2008 MIXED 3NF Violation Example prime attributes non-prime attributes divnamdeptno dname empno MIXED Emps divnam empno ename deptno dname divnam + deptno  dname

41. 41 © Ellis Cohen 2001-2008 3NF: 3rd Normal Form (MIXED) Mixed Transitivity Violation: The determinants are a mixture of prime and non-prime attributes Emp( divnam, empno, ename, deptno, dname ) divnam + deptno  dname Widgets7499ALLEN30SALES Widgets7654MARTIN30SALES Widgets6922FUDGE10ACCOUNTING Novatone7698BLAKE30RESEARCH Novatone7499SHAKUR10ACCOUNTING Novatone7844TURNER50SUPPORT divnam empno ename deptno dname Emps prime attributesnon-prime attributes

42. 42 © Ellis Cohen 2001-2008 Relational Mixed 3NF Normalization Depts divnam deptno dname Emps new divnam empno ename deptno Emps old divnam empno ename deptno dname Normalize by 1) Create a new relation with the determinant and everything dependent upon it 2) Remove everything dependent upon the determinant from the original relation 3) Add foreign key constraint, possibly w cascading delete divnam + deptno  dname What's the corresponding conceptual model?

43. 43 © Ellis Cohen 2001-2008 Potential Weak Entity Class Model DeptEmployee divnam deptno dname empno ename Depts Emps Does this conceptual model correspond? divnam deptno dname divnam empno ename deptno

44. 44 © Ellis Cohen 2001-2008 Weak Entity Class Model Dependency DeptEmployee divnam deptno dname empno ename This model implies that an employee is identified relative to to a Dept Emps divnam empno ename deptno But the result of normalization identifies an employee relative to a Division

45. 45 © Ellis Cohen 2001-2008 Relational Mapping DeptEmployee divnam deptno dname empno ename deptno is also part of the primary key Can we remove deptno as part of the primary key? Depts Emps divnam deptno dname divnam empno ename deptno

46. 46 © Ellis Cohen 2001-2008 Shrinking Primary Key via Constraints If we can ensure that divnam + empno is a candidate key then deptno does not need to be part of Emps' primary key. So, we can use the ER model below so long as we add the conceptual state constraint: Within any given division, employee numbers are unique. This means that an Employee is uniquely identified by divnam + empno, so deptno is not needed in the primary key Depts divnam deptno dname Emps divnam empno ename deptno DeptEmployee divnam deptno dname empno ename

47. 47 © Ellis Cohen 2001-2008 Conceptual Mixed 3NF Normalization Employee divnam empno ename deptno dname Normalize by 1)Move determinant and everything dependent on it to a new entity class. 2)The original class becomes a weak entity class, with the remaining parts of the key as the discriminator divnam + empno  ename divnam + deptno  dname divnam + empno  deptno Note how FD's become unique or key constraints DeptEmployee divnam deptno dname empno ename + A dept with employees can't be deleted

48. 48 © Ellis Cohen 2001-2008 Factoring & MIXED 3rd Normal Form

49. 49 © Ellis Cohen 2001-2008 Potential 1:M Model Depts divnam deptno dname Emps divnam empno ename deptno DeptEmployee divnam deptno dname divnam empno ename Does this conceptual model correspond?

50. 50 © Ellis Cohen 2001-2008 Actual Relational Mapping DeptEmployee divnam deptno dname divnam empno ename Depts divnam deptno dname Emps divnam empno ename ddivnam deptno Nothing ensures that an employee is in the same division as the employee's department! Can we fix this by adding a state constraint?

51. 51 © Ellis Cohen 2001-2008 Constrained Relational Mapping + Conceptual State Constraint: an employee is in the same division as the employee's department DeptEmployee divnam deptno dname divnam empno ename Depts divnam deptno dname Emps divnam empno ename deptno

52. 52 © Ellis Cohen 2001-2008 Adding a Division Class DeptEmployee divnam deptno dname divnam empno ename Division divnam Because divnam shows up in both Employee & Dept, it suggests that it should be represented by its own Division Class Are there any problems with this model?

53. 53 © Ellis Cohen 2001-2008 Induced Entity Attributes DeptEmployee divnam deptno dname divnam empno ename Division divnam The divnam attributes in Employee and Dept are both now illegal entity attributes.

54. 54 © Ellis Cohen 2001-2008 Using Weak Entity Classes works for empno ename deptno dname Division divnam DeptEmployee + Conceptual State Constraint: an employee is in the same division as the employee's department This constraint can be depicted directly on the ER diagram!

55. 55 © Ellis Cohen 2001-2008 Using Factored Relationships (by Division) Factored Relationship: An employee of a given division works for a department in the same division works for empno ename deptno dname Division divnam DeptEmployee Crow Magnum

56. 56 © Ellis Cohen 2001-2008 Containment Model in UML Employee * DK empno ename Division PK divnam Not quite standard due to DK & because UML doesn't allow attributes in containment diagrams Dept * DK deptno dname * 0..1 Everything contained in the outer box holds for a single division at a time UML

57. 57 © Ellis Cohen 2001-2008 Crow Magnum Containment Division Everything inside the outer box holds for a single division at a time An employee of a given division works for a department in the same division divnam works for empno ename deptno dname DeptEmployee has* An employee is identified wrt a division A division has many (*) employees Underlining indicates an identifying relationship with Division Crow Magnum

58. 58 © Ellis Cohen 2001-2008 Normalization with Nested Determinants

59. 59 © Ellis Cohen 2001-2008 Conceptual Normalization Normalization can be used initially at the conceptual level to improve designs. However, when there are multiple related composite functional dependencies, relational normalization may still be required (though can sometimes be avoided by doing conceptual normalizations in the right order)

60. 60 © Ellis Cohen 2001-2008 Nested Determinants Video( vidid, acqdate, empno, ename, renttime, custid, cphone ) Candidate Keys: vidid Minimal Non Key FD's empno  ename custid  cphone custid + renttime  empno start with these Do Conceptual Normalization custid custid + renttime Nested Determinants

61. 61 © Ellis Cohen 2001-2008 Split out Customer & Employee Video Employee vidid acqdate renttime empno ename Customer custid cphone empno  ename custid  cphone Simple 3NF Transitivity Violations No further conceptual normalization is possible Draw the Relational Schema

62. 62 © Ellis Cohen 2001-2008 Split out Customer & Employee Video Employee vidid acqdate renttime empno ename Customer custid cphone custid + renttime  empno is a 3NF violation only in the Relational Model. Resolve it using Relational Normalization vidid acqdate custid renttime empno Videos Employees empno ename Customers custid cphone

63. 63 © Ellis Cohen 2001-2008 Relational Splicing vidid acqdate custid renttime empno Videos Employees empno ename Customers custid cphone Rentals custid renttime empno custid + rentime  empno Pure 3NF Violation Normalization tells us how to decompose, but not how to connect (w FK constraints). In this case, we had to splice Rentals in between Customers & Employees

64. 64 © Ellis Cohen 2001-2008 Alternate Decomposition Video( vidid, acqdate, empno, ename, renttime, custid, cphone ) Candidate Keys: vidid Minimal Non Key FD's empno  ename custid  cphone custid + renttime  empno start with this Do Conceptual Normalization custid custid + renttime Nested Determinants

65. 65 © Ellis Cohen 2001-2008 Split out Rental Video vidid acqdate Rental custid renttime empno cphone ename Now decompose using empno  ename custid  cphone

66. 66 © Ellis Cohen 2001-2008 Complete Conceptual Normalization Video vidid acqdate Rental custid renttime empno cphone ename Video Employee vidid acqdate empno ename Customer custid cphone Rental renttime Splitting Rental out first allows a complete Conceptual Normalization via 2NF via Pure 3NF Method: Decompose first using FD's with largest # of determinant fields e.g. custid + renttime  empno Now decompose using empno  ename custid  cphone

67. 67 © Ellis Cohen 2001-2008 Normalization with Overlapping Determinants

68. 68 © Ellis Cohen 2001-2008 Overlapping Determinants Assign ( empno, pno, task, startdate, payrate ) Candidate Keys: empno + pno + task Minimal Non Key FDs: empno + pno  startdate empno + task  payrate Do Conceptual Normalization starting with either FD empno + pno empno + task Overlapping Determinants

69. 69 © Ellis Cohen 2001-2008 Incomplete Conceptual Normalization AssignProjAssign task payrate empno pno startdate empno + pno  startdate AssignTaskAssign pno startdate empno task payrate empno + task  payrate Starting with either FD resolves a 2NF violation. Either result is in Conceptual Normal Form, but does not result in a complete normalization Pick either one, map to a Relational Schema, and complete the relational normalization

70. 70 © Ellis Cohen 2001-2008 Complete Relational Normalization empno pno task Assigns ProjAssigns empno pno startdate empno task payrate TaskAssigns Reverse Engineer the corresponding Conceptual Diagram Hint: Look at Conceptual Normalization of Mixed 3NF Violations

71. 71 © Ellis Cohen 2001-2008 Factored Relational Model empno pno task Assigns ProjAssigns empno pno startdate empno task payrate TaskAssigns Factor out empno What's left is an M:N relationship between ProjAssigns & TaskAssigns

72. 72 © Ellis Cohen 2001-2008 Factored Normalization Answer pno startdate task payrate TaskAssignProjAssign Employee Everything inside the outer box holds for a single employee at a time For any given employee, there is a many-many relationship between their projects and their tasks empno has* corresponds to

73. 73 © Ellis Cohen 2001-2008 Using Factored Relationships pno startdate task payrate Employee empno TaskAssignProjAssign (by Employee) corresponds to For any given employee, there is a many-many relationship between their projects and their tasks

74. 74 © Ellis Cohen 2001-2008 Normalization Methodology 1.Based on your knowledge, expertise, wisdom & prescience, design the best conceptual model you can 2.Do conceptual normalization. If an entity class has two FDs with nested determinants, resolve the FD with the larger determinant first If determinants overlap, conceptual normalization will not completely normalize a design 3.Map to a relational schema 4.Do relational normalization