NORMALIZATION

universe.bits.pilani.ac.in
  • No tags were found...

NORMALIZATION

NORMALIZATIONLecture 10,11,12© Prentice Hall, 20021


Well-Structured Relations A relation that contains minimal data redundancyand allows users to insert, delete, and update rowswithout causing data inconsistencies Goal is to avoid anomalies– Insertion Anomaly – adding new rows forces user tocreate duplicate data– Deletion Anomaly – deleting rows may cause a loss ofdata that would be needed for other future rows– Modification Anomaly – changing data in a row forceschanges to other rows because of duplicationGeneral rule of thumb: a table should not pertain tomore than one entity type


Anomalies in this Table Insertion – can’t enter a new employee withouthaving the employee take a class Deletion – if we remove employee 140, we loseinformation about the existence of a Tax Acc class Modification – giving a salary increase toemployee 100 forces us to update multiple recordsWhy do these anomalies exist?Because we’ve combined two themes (entity types)into one relation. This results in duplication, and anunnecessary dependency between the entities


Steps innormalization


First Normal Form No multivalued attributes Every attribute value is atomic All relations are in 1 st Normal Form


Second Normal Form 1NF plus every non-key attribute is fullyfunctionally dependent on the ENTIREprimary key– Every non-key attribute must be defined by theentire key, not by a part of the key– No partial functional dependencies


Functional Dependencies inEMPLOYEE2Dependency on entire primary keyEmpID CourseTitle Name DeptName Salary DateCompletedDependency on only part of the keyEmpID, CourseTitle DateCompletedEmpID Name, DeptName, SalaryTherefore, NOT in 2 nd Normal Form!!


Getting it into 2 nd Normal FormEmpIDNameDeptNameSalaryBoth are fullfunctionaldependenciesEmpIDCourseTitleDateCompleted


Third Normal Form 2NF PLUS no transitive dependencies(one attribute functionally determines asecond, which functionally determines athird)


Relation with transitive dependency(a) SALES relation with simple data


Relation with transitive dependencyCustID NameCustID SalespersonCustID RegionAll this is OK(2 nd NF)BUTCustID Salesperson RegionTransitive dependency(not 3 rd NF)


Removing a transitive dependency(a) Decomposing the SALES relation


Relations in 3NFSalesperson RegionCustID NameCustID SalespersonNow, there are no transitive dependencies…Both relations are in 3 rd NFFurther on Normalization…..Follow Class Notes

More magazines by this user
Similar magazines