1. Normalization – Additional Notes

2. Normalization Abstract Example For the following un-normalized relation: RELN1[A, B, {C, D}, E, F, G] where E can be determined by knowing only A, and the G can be determined by knowing only F 1NF: RELN1[A, B, E, F, G] RELN2[A, B, C, D] 2NF: RELN1[A, B, F, G] RELN3[A, E] RELN2[A, B, C, D] 3NF: RELN1[A, B, F] RELN4[F, G] RELN3[A, E] RELN2[A, B, C, D]

3. Sample User View: Class List Section: DBS201A: Intro to DB Design; Belvedere, 213 Student#Student Name 111Joe Brown 212Li Huang Section: DBS201B: Intro to DB Design; Langer, 222 Student#Student Name 323Ella Sundin 555Maria Ramirez Section: IPC144A: Intro to Programming; Belvedere, 213 Section: IPC144B: Intro to Programming; Belvedere, 213 Student#Student Name 111Joe Brown 444Li Huang

4. Modified Class List User View Subj Code Sect Code Subj NameInstr NameInstr No Stud No Stud Name DBS201AIntro to DB Design Belvedere213111Joe Brown DBS201AIntro …Belvedere213212Li Huang DBS201BIntro …Langer222323Ella Sundin DBS201BIntro …Langer222555Maria Ramirez IPC144AIntro to Programming Belvedere213 IPC144BIntro to …Belvedere213111Joe Brown IPC144BIntro to …Belvedere213444Li Huang

5. Modified Class List User View – Un-normalized Form CLASSLIST [ SubjectCode, SectionCode, InstrNo, InstrName, SubjectName, StudentNumber, StudentName ] Note : With the composite primary key chosen there are no repeating groups! Since there are no repeating groups this relation is already in 1NF

6. 2 nd Normal Form 1NF Relation: CLASSLIST [ SubjectCode, SectionCode, StudentNumber, InstrNo, InstrName, SubjectName, StudentName ] contains the partial dependencies: StudentNumber-> StudentName; SubjectCode  SubjectName 2NF Relations: CLASSLIST [ SubjectCode, SectionCode, StudentNumber, InstrNo, InstrName] SUBJECT [ SubjectCode, SubjectName] STUDENT [StudentNumber, StudentName ]

7. 3rd Normal Form 2NF Relations: CLASSLIST [ SubjectCode, SectionCode, StudentNumber, InstrNo, InstrName] contains transitive dependency InstrNo  InstrName SUBJECT [ SubjectCode, SubjectName] STUDENT [StudentNumber, StudentName ] 3NF Relations: CLASSLIST [ SubjectCode, SectionCode, StudentNumber, InstrNo] INSTRUCTOR [InstrNo, InstrName] SUBJECT [ SubjectCode, SubjectName] STUDENT [StudentNumber, StudentName ]

8. Different User View Representations Note that different representations of a user view produce different intermediate results (UNF, 1NF, 2NF relations) However different representations of a user view produce the same set of 3NF relations Choose the method of representation of a user view that seems best for you!

9. Nested Repeating Groups Example Representation of a user view in UNF may result in nested repeating groups. The process of resolving a repeating group must be performed starting with the outermost repeating group first to produce a temporary new relation containing a repeating group. The process of resolving a repeating group must then also be performed on this temporary relation

10. Nested Repeating Groups User View SUBJECT: DBS201; Intro to DB Section: A; Belvedere, 213 Student#Student Name 111Joe Brown 212Li Huang Section: B; Langer, 222 Student#Student Name 323Ella Sundin 555Maria Ramirez SUBJECT: IPC144; Intro to Programming Section:A; Belvedere, 213 Section: B; Belvedere, 213 Student#Student Name 111Joe Brown 444Li Huang

11. Nested Repeating Groups User View – UNF CLASSLIST [ SubjectCode, SubjectName, {SectionCode, InstrNo, InstrName, {StudentNumber, StudentName} } ] Note : Section information repeats for a subject, and student information repeats within a section

12. Nested Repeating Groups – 1NF From UNF: CLASSLIST [ SubjectCode, SubjectName, {SectionCode, InstrNo, InstrName, {StudentNumber, StudentName} } ] We get 1NF: CLASSLIST [ SubjectCode, SubjectName] CLASSLIST [ SubjectCode, SectionCode, InstrNo, InstrName, {StudentNumber, StudentName} ] – temporary; not yet in 1NF SECTION [ SubjectCode, SectionCode, InstrNo, InstrName] ENROLMENT [ SubjectCode, SectionCode, StudentNumber, StudentName]