Concepts of Database Management Seventh Edition Chapter 5 Database Design 1: Normalization

Objectives Discuss functional dependence and primary keys Define first normal form, second normal form, and fourth normal form Describe the problems associated with tables (relations) that are not in first normal form, second normal form, or third normal form, along with the mechanism for converting to all three Understand how normalization is used in the database design process 2

Introduction Normalization process –Identifying potential problems, called update anomalies, in the design of a relational database –Methods for correcting these problems Normal form: table has desirable properties –First normal form (1NF) –Second normal form (2NF) –Third normal form (3NF) 3

Introduction (continued) Normalization –Table in first normal form better than table not in first normal form –Table in second normal form better than table in first normal form, and so on –Goal: new collection of tables that is free of update anomalies 4

Functional Dependence 5 B A A certain field say Column Bis functionally dependent on another field say Column A if Column B’s value depend on the value of Column A. And also that Column A’s value is associated only with a exactly one value of Column B. And so if Column B depends on Column A then it also means that Column A functionally determines Column B.

Functional Dependence (continued) FIGURE 5-2: Rep table with additional column, PayClass 6 Let’s assume that in Premiere Products all Sales Rep in any given Pay class earn the Commission Rate. So, which means And his/her Commission Rate a Sale’s Rep Pay Classhis/her Commission Ratedetermines therefore dependson his/her Pay Class PayClassRate

Functional Dependence (continued) 7 Let’s make it a local example here. Suppose we have a Courses table below: That is, Course Code determines his/her Course Description And Course Description depends on Course Code Course CodeCourse Description IS230Database Design CA100Computer Literacy BU101Intro to Business Course CodeCourse Description

Functional Dependence (continued) 8 Given a Salary table for Faculties of a community college which one field determines which field and which field depends which field? PositionAnnual Salary Instructor16,000 Assistant Professor19,000 Associate Professor24,000 Professor29,000 Professor Emeritus35,000

Let us examine Rep table on Premier Database FIGURE 5-4: Rep table with second rep named Kaiser added FIGURE 5-3: Rep table 9

Question? Is Street functionally depend on Firstname or Lastname? 10

Question? Is CustomerName Functionally Dependent on RepNum? FIGURE 5-3: Rep table 11

Question? So, on which columns does QuotedPrice is functionally dependent? 12 Is QuotedPrice Functionally Dependent on PartNum? Is QuotedPrice Functionally Dependent on OrderNum?

Non-Graded Exercise 13 Identify which field(s) is functionally dependent on which field(s) And then which field(s) functionally determines which field(s). Stud ID StudeLastStudFirstHighSchool Num HighSchool Name AdvisorNu m Advisor Name 1CruzJohn101CCA990Smith 2MooreAnna102SDA991Song 3FriendFe101CCA991Song 4ZapMario103MNHS990Smith 5BassGerard103MNHS992George

Primary Key and Functional Depedence 14 Remember the primary key concept that we learn on Chapter 4? Primary key uniquely identifies a record or row. The key in determining if column is functionally dependent to another column is to ask the question, is a certain column functionally dependent to the Primary Key.

Primary Key and Functional Depedence 15 What is the Primary Key of Part table? Is Warehouse functionally dependent on Class? Is the Combination of Partnum and Descriptin is the Primary Key?

Primary Key and Functional Depedence 16 Is CustomerNum the Primary Key for Customer table? Does CustomerNum determines the values of the other fields?

Question? Is OrderNum the Primary Key of OrderLine table? FIGURE 5-3: Rep table 17 What is the Primary Key of OrderLine Table?

Nothing but the Key 18 The key thought in normalization is the primary key. To Quote E.F. Codd the father of relational database systems. –“[Every] non-key [attribute] must provide a fact about the key, the whole key, and nothing but the key.” Take this into mind as we go on three basic normal forms in Database Design.

Three Normal Forms Mnemonics In order to easily remember the three normal forms just remember the word RePeaT ignoring the vowels (which are in small letters) which are: 19 R – 1 ST Normal Form - No Repeating groups or multi-valued fields T – 3 rd Normal Form - No Transitional Dependence P – 2 nd Normal Form - No Partial Dependence

First Normal Form There should be no repeating group or multi- valued columns in order for a Table to be in first normal form. –Repeating group: multiple entries for a single record –Unnormalized relation: contains a repeating group 20

First Normal Form (continued) Orders (OrderNum, OrderDate, (PartNum, NumOrdered) ) FIGURE 5-5: Sample unnormalized table 21 Repeating Group or Multi- valued Columns

First Normal Form (continued) Orders (OrderNum, OrderDate, PartNum, NumOrdered) FIGURE 5-6: Result of normalization (conversion to first normal form) 22 Converted to First Normal Form No more Multi-valued fields

Second Normal Form (continued) Table (relation) in second normal form (2NF) –Table is in first normal form –No nonkey column (not a primary key) column should be partially dependent of a composite primary key. Partial dependencies: only on a portion of the primary key 23

Second Normal Form 24 Description is partially dependent on PartNum but not on both OrderNum and PartNum which are the composite Primary Key. Primary Key : OrderNum and PartNum OrderDate is partially dependent on OrderNum but not on both OrderNum and PartNum which is the composite Primary Key.

Converting to Second Normal Form 25 OrderNum OrderDate X Because the Primary Key is OrderNum and Partnum

Converting to Second Normal Form 26 X Remove partially dependent field OrderDate And make a new table out of it let’s say in this case Orders table

Converting to Second Normal Form 27 PartNum Description X Because the Primary Key is OrderNum and Partnum

Converting to Second Normal Form 28 X Remove partially dependent field Description And make a new table out of it let’s say in this case Part table

Converting to Second Normal Form 29 XX The Original table becomes a new table which is Normalized. And let’s say we name it OderLine table.

Second Normal Form (continued) FIGURE 5-9: Conversion to second normal form 30

Third Normal Form (continued) Table (relation) in third normal form (3NF) –It is in second normal form –There should no non-primary key that is transitional dependent to a primary key. 31

Third Normal Form (continued) FIGURE 5-10: Sample Customer table 32

Third Normal Form Customer (CustomerNum, CustomerName, Balance, CreditLimit, RepNum, LastName, FirstName) Functional dependencies: –CustomerNum → CustomerName, Balance, CreditLimit, RepNum, LastName, FirstName –RepNum → LastName, FirstName 33

Third Normal Form (continued) Correction procedure –Remove each column that is transitionally dependent. –Create a new table, transferring the removed columns to the newly created table. –Make a primary key of the new table –And use the primary key as the foreign key from the table where the columns were removed earlier. 34

Third Normal Form (continued) 35 FIGURE 5-12: Conversion to third normal form

Third Normal Form (continued) FIGURE 5-12: Conversion to third normal form (continued) 36

Incorrect Decompositions Decomposition must be done using method described for 3NF Incorrect decompositions can lead to tables with the same problems as original table 37

Incorrect Decompositions (continued) FIGURE 5-13: Incorrect decomposition of the Customer table 38

Incorrect Decompositions (continued) FIGURE 5-13: Incorrect decomposition of the Customer table (continued) 39

Incorrect Decompositions (continued) FIGURE 5-14: Second incorrect decomposition of the Customer table 40

Incorrect Decompositions (continued) FIGURE 5-14: Second incorrect decomposition of the Customer table (continued) 41

Guess which normal form it violates? 42 EmployeeIDLastnameFirstnameGenderComputer Skills 1JamesGeorgeMEncoding, MS Office, Photoshop 2MilesMayFEncoding, Programming, Database Design 3GatesAlanMProgramming, MS Office How should we normalized the above table? Let’s say we want to store Employee’s different computer skills on a table.

Guess which normal form it violates? 43 CustomerIDLastnameFirstnameContactNumber 1ChristopherRey , AllenGeorge GreenRhea , , How should we normalized the above table? Let’s say we want to store Customer’s contact numbers.

Guess which normal form it violates? 44 StudentIDCourseCo de LastnameFirstnameCourseDe scription Section 1001IS230MillsKarenDatabase Design CA100CourtneyFrancisComputer Literacy EN110SmithPhillipAdvanced Reading EN110CourtneyFrancisAdvanced Reading CA100MorrisonJohnComputer Literacy 2 How should we normalized the above table? Let’s say we want to store Students who takes courses on a particular section.

Guess which normal form it violates? 45 Semester Code Semester Year SemsterS eason StudentIDLastnameFirstname Spring1001MillsKaren Spring1002CourtneyFrancis Fall1003SmithPhillip Fall1004MorrisonJohn Fall1005DylanSarah How should we normalized the above table? Let’s say we want a table that stores those who enroll in a certain semester.

Guess which normal form it violates? 46 CourseCodeSectionFacultyIDLastnameFirstname IS CastroEdper CA MangononGeorge EN RiveraMonica SS HaglelgamJohn MS Verg-inYenti How should we normalized the above table? Let’s say we want a table that stores the courses that Faculty taught.

Guess which normal form it violates? 47 DivisionIDDivisionNameFacultyIDLastnameFirstname 1Business1010Felix, Jr.Joseph 2Education1008HallersMaggie 3HCOP4025DacanayPaul 4Math and Science2641BizaSnyther How should we normalized the above table? Let’s say we want a table that stores who is the division chair of a certain division.

Graded Case Study – Alexamara 48 Problem 1 : Normalize the table below OwnerNumLastNameFirstNameBoatNameWeightMarina AD57AdneyBruce and JeanAdBruce X1,000 lbsEast Zinger1,500 lbsEast AN75AndersonBillYellow Beast2,000 lbsWest BL72BlakeMaryKumodo1,200 lbsEast Kryptonite1,000 lbsWest EL25ElendSandy and BillShark Fin1,300 lbsEast Two Cute900 lbsEast Ride North1,400 lbsWest

Graded Case Study - Alexamara 49 Problem 2 : Normalize the table below SlipIDMarinaNumSlipNumLengthRentalFeeBoatNameBoatTypeOwnerNumOwnerLastNameOwnerFirstName 11A140$3,800.00Anderson IISprite 4000AN75AndersonBill 21A240$3,800.00Our ToyRay 4025EL25ElendSand and Bill 31A340$3,600.00EscapeSprite 4000KE22KellyAllysa 41B130$2,400.00GypsyDolphin 28JU92JuarezMaria 51B230$2,600.00Anderson IIISprite 3000AN75AndersonBill 62125$1,800.00BravoDolphin 25AD57AdneyBruce and Jean 72225$1,800.00ChinookDolphin 22FE82FeenstraDaniel 82325$2,000.00ListyDolphin 25SM72SmeltzBeck and Dave 92430$2,500.00MermaidDolphin 28BL72BlakeMary $4,200.00Axxon IIDolphin 40NO27NortonPeter $4,200.00KarvelRay 4025TR72TrentAshton

Graded Case Study – Henry Books 50 Problem 1 : Normalize the table below PublisherCodePublisherNameCityBookTitleYearPublished AHArkham HouseSauk City WIDream House1999 Partial Recall2011 APArcade PublishingNew YorkGames Played1982 BABasic BooksBoulder CODance Fundamentals1980 Booking the Flight1993 BPBerkley PublishingBostonBastketball glory2001 VBVintage BooksNew YorkArchive Reload1998 Rusty Road2002 WNW.W. NortonNew YorkWar and Breeze2006 WPWestview PressBoulder COGeneral Goodwill1978

Graded Case Study – Henry Books 51 Problem 2 : Normalize the table below BookCodeTitleAuthorCodeAuthorFirstnameAuthorLastname 0180A Deepness in the Sky1001GeorgeGraham 0189Magic Terror1002EarlJohnson 0200The Stranger1001GeorgeGraham 0378Venice1003VitaliPablo 079XSecond Wind1004StrongMary 0808The Edge1002EarlJohnson

Summary Column (attribute) B is functionally dependent on another column A (or collection of columns) when each value for A in the database is associated with exactly one value of B Column(s) A is the primary key if all other columns are functionally dependent on A and no sub- collection of columns in A also have this property 52

Summary (continued) Table (relation) in first normal form (1NF) does not contain repeating groups Nonkey column (or nonkey attribute) is not a part of the primary key Table (relation) is in the second normal form (2NF) when it is in 1NF and no nonkey column is dependent on only a portion of the primary key Determinant is a column that functionally determines another column 53

Summary (continued) Table (relation) is in third normal form (3NF) when it is in 2NF and its only determinants are candidate keys Collection of tables (relations) that is not in third normal form has inherent problems called update anomalies 54