Presentation is loading. Please wait.

Presentation is loading. Please wait.

Functional Dependency & Normalization. Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition.

Similar presentations


Presentation on theme: "Functional Dependency & Normalization. Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition."— Presentation transcript:

1 Functional Dependency & Normalization

2 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Data Redundancy Major aim of relational database design is to group attributes into relations to minimize data redundancy and reduce file storage space required by base relations. Problems associated with data redundancy are illustrated by comparing the following Staff and Branch relations with the StaffBranch relation. 2

3 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Data Redundancy 3

4 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Data Redundancy StaffBranch relation has redundant data: details of a branch are repeated for every member of staff. In contrast, branch information appears only once for each branch in Branch relation and only branchNo is repeated in Staff relation, to represent where each member of staff works. 4

5 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Update Anomalies Relations that contain redundant information may potentially suffer from update anomalies. Types of update anomalies include: –Insertion, –Deletion, –Modification. 5

6 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Functional Dependency Main concept associated with normalization. Functional Dependency –Describes relationship between attributes in a relation. –If A and B are attributes of relation R, B is functionally dependent on A (denoted A B), if each value of A in R is associated with exactly one value of B in R.

7 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Functional Dependency Property of the meaning (or semantics) of the attributes in a relation. Diagrammatic representation: 7

8 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example Employee SSNNameJobTypeDeptName 557-78-6587Lance SmithAccountantSalary 214-45-2398Lance SmithEngineerProduct Note: Name is functionally dependent on SSN because an employee’s name can be uniquely determined from their SSN.

9 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example - Functional Dependency 9

10 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Functional Dependency Main characteristics of functional dependencies used in normalization: –have a 1:1 relationship between attribute(s) on left and right-hand side of a dependency; –hold for all time; –are nontrivial. 10

11 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition The Process of Normalization Formal technique for analyzing a relation based on its primary key and functional dependencies between its attributes. Often executed as a series of steps. Each step corresponds to a specific normal form, which has known properties. As normalization proceeds, relations become progressively more restricted (stronger) in format and also less vulnerable to update anomalies. 11

12 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Relationship Between Normal Forms 12

13 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 1 st Normal Form The Requirements The requirements to satisfy the 1 st NF: –Each table has a primary key: minimal set of attributes which can uniquely identify a record –The values in each column of a table are atomic (No multi-value attributes allowed). –There are no repeating groups: two columns do not store similar information in the same table.

14 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 1 st Normal Form Example Un-normalized Students table: Normalized Students table: Student#AdvIDAdvNameAdvRoomClass1Class2 123123AJames555102-8104-9 124123BSmith467209-0102-8 Student#AdvIDAdvNameAdvRoomClass# 123123AJames555102-8 123123AJames555104-9 124123BSmith467209-0 124123BSmith467102-8

15 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 2 nd Normal Form The Requirements The requirements to satisfy the 2 nd NF: –All requirements for 1 st NF must be met. –Redundant data across multiple rows of a table must be moved to a separate table. The resulting tables must be related to each other by use of foreign key.

16 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 2 nd Normal Form Example Students table Registration table Student#AdvIDAdvNameAdvRoom 123123AJames555 124123BSmith467 Student#Class# 123102-8 123104-9 124209-0 124102-8

17 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 3 rd Normal Form The Requirements The requirements to satisfy the 3 rd NF: –All requirements for 2 nd NF must be met. –Eliminate fields that do not depend on the primary key; That is, any field that is dependent not only on the primary key but also on another field must be moved to another table.

18 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 3 rd Normal Form Example Students table: Student table:Advisor table: Student#AdvIDAdvNameAdvRoom 123123AJames555 124123BSmith467 Student#AdvID 123123A 124123B AdvIDAdvNameAdvRoom 123AJames555 123BSmith467

19 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition 3 rd Normal Form Example Cont. Students table: Registration table:Advisor table: Student#Class# 123102-8 123104-9 124209-0 124102-8 AdvIDAdvNameAdvRoom 123AJames555 123BSmith467 Student#AdvID 123123A 124123B

20 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Conclusion We have seen how Database Normalization can decrease redundancy, increase efficiency and reduce anomalies by implementing three of seven different levels of normalization called Normal Forms. The first three NF’s are usually sufficient for most small to medium size applications.

21 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example 1 Un-normalized Table: Student#Advisor#AdvisorAdv-RoomClass1Class2Class3 102210Susan Jones412101-07143-01159-02 412312Anne Smith216101-07159-02214-01

22 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Table in First Normal Form –No Repeating Fields –Data in Smallest Parts Student#Advisor#AdvisorFNameAdvisorLName Adv- Room Class# 102210SusanJones412101-07 102210SusanJones412143-01 102210SusanJones412159-02 412312AnneSmith216101-07 412312AnneSmith216159-02 412312AnneSmith216214-01

23 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Second Normal Form –Redundant Data Eliminated Student#Advisor#AdvFirstNameAdvLastName Adv- Room 102210SusanJones412 412312AnneSmith216 Table: Students Student#Class# 1022101-07 1022143-01 1022159-02 4123201-01 4123211-02 4123214-01 Table: Registration

24 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Third Normal Form –Data Not Dependent On Key is Eliminated Student#Advisor#StudentFNameStudentLName 102210JaneMayo 412312MarkBaker Table: Students Student#Class# 1022101-07 1022143-01 1022159-02 4123201-01 4123211-02 4123214-01 Table: Registration Advisor#AdvFirstNameAdvLastName Adv- Room 10SusanJones412 12AnneSmith216 Table: Advisors

25 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Relationships for Example 1 Registrati on Student # Class# Students Student # Advisor# Advisors Advisor# AdvFirstNa me AdvLastNa me Adv-Room

26 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example 2 Un-normalized Table: EmpIDNameDept Code Dept NameProj 1Time Proj 1 Proj 2Time Proj 2 Proj 3Time Proj 3 EN1-26Sean BreenTWTechnical Writing30-T325%30-TC40%31-T330% EN1-33Amy GuyaTWTechnical Writing30-T350%30-TC35%31-T360% EN1-36Liz RoslynACAccounting35-TC90%

27 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Table in First Normal Form EmpIDProject Number Time on Project Last Name First Name Dept Code Dept Name EN1-2630-T325%BreenSeanTWTechnical Writing EN1-2630-TC40%BreenSeanTWTechnical Writing EN1-2631-T330%BreenSeanTWTechnical Writing EN1-3330-T350%GuyaAmyTWTechnical Writing EN1-3330-TC35%GuyaAmyTWTechnical Writing EN1-3331-T360%GuyaAmyTWTechnical Writing EN1-3635-TC90%RoslynLizACAccounting

28 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Second Normal Form EmpIDProject Number Time on Project EN1-2630-T325% EN1-2630-T340% EN1-2631-T330% EN1-3330-T350% EN1-3330-TC35% EN1-3331-T360% EN1-3635-TC90% EmpIDLast Name First Name Dept Code Dept Name EN1-26BreenSeanTWTechnical Writing EN1-33GuyaAmyTWTechnical Writing EN1-36RoslynLizACAccounting Table: Employees and ProjectsTable: Employees

29 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Third Normal Form Dept CodeDept Name TWTechnical Writing ACAccounting EmpIDLast Name First Name Dept Code EN1-26BreenSeanTW EN1-33GuyaAmyTW EN1-36RoslynLizAC EmpIDProject Number Time on Project EN1-2630-T325% EN1-2630-T340% EN1-2631-T330% EN1-3330-T350% EN1-3330-TC35% EN1-3331-T360% EN1-3635-TC90% Table: Employees_and_Projects Table: Departments Table: Employees

30 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Relationships for Example 2 Employees_and_Proj ects EmpID ProjectNumber TimeonProject Employee s EmpID FirstName LastName DeptCode Departmen ts DeptCod e DeptName

31 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example 3 EmpIDNameManagerDeptSectorSpouse/Children 285Carl Carlson SmithersEngineering6G 365LennySmithersMarketing8G 458Homer Simpson Mr. BurnsSafety7GMarge, Bart, Lisa, Maggie Un-normalized Table:

32 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Table in First Normal Form Fields contain smallest meaningful values EmpIDFNameLNameManagerDeptSectorSpouseChild1Child2Child3 285CarlCarlsonSmithersEng.6G 365LennySmithersMarketing8G 458HomerSimpsonMr. BurnsSafety7GMargeBartLisaMaggie

33 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Table in First Normal Form No more repeated fields EmpIDFNameLNameManagerDepartmentSectorDependent 285CarlCarlsonSmithersEngineering6G 365LennySmithersMarketing8G 458HomerSimpsonMr. BurnsSafety7GMarge 458HomerSimpsonMr. BurnsSafety7GBart 458HomerSimpsonMr. BurnsSafety7GLisa 458HomerSimpsonMr. BurnsSafety7GMaggie

34 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Second/Third Normal Form Remove Repeated Data From Table Step 1 EmpIDFNameLNameManagerDepartmentSector 285CarlCarlsonSmithersEngineering6G 365LennySmithersMarketing8G 458HomerSimpsonMr. BurnsSafety7G EmpIDDependent 458Marge 458Bart 458Lisa 458Maggie

35 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Second Normal Form EmpIDFNameLNameManagerIDDeptSector 285CarlCarlson2Engineering6G 365Lenny2Marketing8G 458HomerSimpson1Safety7G EmpIDDependent 458Marge 458Bart 458Lisa 458Maggie ManagerIDManager 1Mr. Burns 2Smithers Removed Repeated Data From Table Step 2

36 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in Third Normal Form DeptCodeDepartmentSectorManagerID ENEngineering6G2 MKMarketing8G2 SFSafety7G1 EmpIDFNameLNameDeptCode 285CarlCarlsonEN 365LennyMK 458HomerSimpsonSF EmpIDDependent 458Marge 458Bart 458Lisa 458Maggie ManagerIDManager 1Mr. Burns 2Smithers Employees Table Dependents Table Department Table Manager Table

37 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Relationships for Example 3

38 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example 4 Rep IDRepresentativeClient 1Time 1Client 2Time 2Client 3Time 3 TS-89Gilroy GladstoneUS Corp.14 hrsTaggarts26 hrsKilroy Inc.9 hrs RK-56Mary MayhemItaliana67 hrsLinkers2 hrs Rep IDRep First NameRep Last Name Client ID* ClientTime With Client TS-89GilroyGladstone978US Corp14 hrs TS-89GilroyGladstone665Taggarts26 hrs TS-89GilroyGladstone782Kilroy Inc.9 hrs RK-56MaryMayhem221Italiana67 hrs RK-56MaryMayhem982Linkers2 hrs Table in 1 st Normal Form Table Violating 1 st Normal Form

39 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in 2 nd and 3 rd Normal Form Rep ID*Client ID*Time With Client TS-8997814 hrs TS-8966526 hrs TS-897829 hrs RK-5622167 hrs RK-569822 hrs RK-566654 hrs Rep ID*First NameLast Name TS-89GilroyGladstone RK-56MaryMayhem Client ID* Client Name 978US Corp 665Taggarts 782Kilroy Inc. 221Italiana 982Linkers This example comes from a tutorial from http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=95 and http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=104 Please check them out, as they are very well done.

40 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Example 5 SupplierIDStatusCityPartIDQuantity S120LondonP1300 S120LondonP2200 S210ParisP1300 S210ParisP2400 S310ParisP2200 S420LondonP2200 S420LondonP4300 Although this table is in 1NF it contains redundant data. For example, information about the supplier's location and the location's status have to be repeated for every part supplied. Redundancy causes what are called update anomalies. Update anomalies are problems that arise when information is inserted, deleted, or updated. For example, the following anomalies could occur in this table: INSERT. The fact that a certain supplier (s5) is located in a particular city (Athens) cannot be added until they supplied a part. DELETE. If a row is deleted, then not only is the information about quantity and part lost but also information about the supplier. UPDATE. If supplier s1 moved from London to New York, then two rows would have to be updated with this new information. Table in 1 st Normal Form

41 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in 2NF SupplierIDStatusCity S120London S210Paris S310Paris S420London S530Athens SupplierIDPartIDQuantity S1P1300 S1P2200 S2P1300 S2P2400 S3P2200 S4P4300 S4P5400 Tables in 2NF but not in 3NF still contain modification anomalies. In the example of Suppliers, they are: INSERT. The fact that a particular city has a certain status (Rome has a status of 50) cannot be inserted until there is a supplier in the city. DELETE. Deleting any row in SUPPLIER destroys the status information about the city as well as the association between supplier and city. Suppliers Parts

42 Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Tables in 3NF Advantages of Third Normal Form The advantage of having relational tables in 3NF is that it eliminates redundant data which in turn saves space and reduces manipulation anomalies. For example, the improvements to our sample database are: INSERT. Facts about the status of a city, Rome has a status of 50, can be added even though there is not supplier in that city. Likewise, facts about new suppliers can be added even though they have not yet supplied parts. DELETE. Information about parts supplied can be deleted without destroying information about a supplier or a city. UPDATE. Changing the location of a supplier or the status of a city requires modifying only one row.


Download ppt "Functional Dependency & Normalization. Copyright © 2004 Ramez Elmasri and Shamkant Navathe Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition."

Similar presentations


Ads by Google