Normalization

Rigorous technique used to break down data represented in a user view into a set of 2- dimensional tables where “all attributes in the relation are defined by the key, the whole key and nothing but the key” Resulting relations will correspond to the tables to be used in a relational database Identification of primary key for a relation is critical

Sample Userview: Class List Section: DBS201ASubject Name: Intro to DB Instructor No: 213Instr Name:Belvedere Student No: Student Name: Joe Brown Student No: Student Name: Le Huang Section: DBS201BSubject Name: Intro to DB Instructor No: 222Instr Name: Langer Student No: Student Name: Ella Zeltserman Student No: Student Name: Maria Ramirez

Un-normalized Relation Identify all attributes presented in user view Choose a primary key (made up of 1 or more attributes) that best represents what user view describes Name the relation and list all attributes for the relation Indicate primary key by underlining 1 or more attributes Indicate if an attribute or group of related attributes can have more than one value for a given value of the primary key by enclosing within brace brackets { } – this is referred to as a ‘repeating group’

Class List Relation – Un-normalized Form CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName, {StudentNumber, StudentName} ]

1 st Normal Form Relation A relation is in 1 st normal form when the primary key determines a single value of each attribute for all attributes in the relation (i.e. the relation contains no repeating groups) 2 different approaches can be used to take a relation from un-normalized to 1NF (both produce same results at the end of the normalization process!)

Unnormalized ->1 st Normal Form Approach 1 Unnormalized relation: CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName, {StudentNumber, StudentName} ] Restate original unnormalized relation without repeating group: CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName ] Create new relation consisting of key of original relation and attributes within repeating group and add to key to ensure uniqueness: CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber, StudentName ]

Unnormalized ->1 st Normal Form Approach 2 Unnormalized Relation: CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName, {StudentNumber, StudentName} ] Add to key of unnormalized relation to insure primary key identifies 1 and only 1 value of each attribute in the relation: CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName, StudentNumber, StudentName ] Regardless of approach used you will now have 1 or more relations in which the primary key identifies 1 and only 1 value of each of the non- key attributes in the 1NF relation

2 nd Normal Form A 1NF relation is in 2NF when the entire primary key is needed to determine the value of each non-key attribute (i.e. relation has no partial dependencies – attributes whose values can be determined by knowing only part of the key)

1 st Normal Form -> 2 nd Normal Form 1NF Relations: CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName, SubjectName ] contains the partial dependency SubjectCode -> SubjectName and CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber, StudentName ] contains the partial dependency StudentNumber-> StudentName so are not in 2NF Create new relation(s) consisting of part of the primary key and all attributes whose values are determined by this part of the primary key: SUBJECT [SubjectCode, SubjectName ] and STUDENT [StudentNumber, StudentName ] Restate original relation(s) without partially dependent attributes: CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber ] and CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName ]

3 Rd Normal Form A 2NF relation is in 3NF when the primary key and nothing but the primary key can be used to determine the value of each non-key attribute (i.e. relation has no transitive dependencies – attributes whose values can be determined by knowing something other than the key)

2NF -> 3NF 2NF Relations: CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber ], CLASSLIST [ SubjectCode, SectionCode, InstructorNo, InstructorName ], SUBJECT [SubjectCode, SubjectName ] and STUDENT [StudentNumber, StudentName ] Create new relation(s) consisting of the attribute(s) which are determined by something other than the primary key (transitive dependencies) and make the primary key of these new relation(s) the attribute that actually determines the value of these attributes. In CLASSLIST the Instructor Name is determined by InstructorNo so create the new relation: INSTRUCTOR [InstructorNo, InstructorName ] Restate original relation(s) without transitively dependent attributes (Original relation will now contain a foreign key – a non-key attribute that relates to the primary key of the new relation) : CLASSLIST [ SubjectCode, SectionCode, InstructorNo ], CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber ], SUBJECT [SubjectCode, SubjectName ] and STUDENT [StudentNumber, StudentName ]

Resulting 3NF Relations for ClassList Userview Set of 3NF Relations for the Class List Userview: CLASSLIST [ SubjectCode, SectionCode, InstructorNo ] CLASSLISTSTUDENT [ SubjectCode, SectionCode, StudentNumber ] SUBJECT [SubjectCode, SubjectName ] STUDENT [StudentNumber, StudentName ] INSTRUCTOR [InstructorNo, InstructorName ] 1 unnormalized userview will always result in 1 or more relations in 1NF Each 1NF relation will result in 1 or more 2NF relations Each 2NF relation will result in 1 or more 3NF relations You can never lose (ie not include) an attribute – it must always be found in one of the relations at each step You can never lose a relation

Normalize Remaining User views Normalization process is then applied to each remaining user view (eg grade sheet, timetable request, …) A set of 3NF relations is produced for each user view Then 3NF relations from each user view are then integrated to form one complete set of relations for the application