Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Normalization

•Download as PPTX, PDF•
•

The document discusses database normalization. It defines normalization as a process that makes data structures efficient by eliminating redundancy and inconsistencies. The key goals of normalization are to control redundancy, ensure data consistency, and allow complex queries. The document outlines the various normal forms including 1NF, 2NF, 3NF, BCNF and examples of how to normalize tables to each form by removing functional dependencies on non-key attributes.

1 of 47

1

Normalization Ahmed Farag Information Systems Dept. Faculty of Computers and Information Menoufia University, Egypt.

2

Normalization

3

Normaliz ation • The biggest problem needed to be solved in database is data redundancy. • Why data redundancy is the problem? Because it causes: • Insert Anomaly • Update Anomaly • Delete Anomaly Teacher Subject Teacher Degree Tel Sok San Database Master's 012666777 Van Sokhen Database Bachelor's 017678678 Sok San E-Commerce Master's 012666777

4

Normaliz ation • Normalization is a process by which data structures in a relational database are as efficient as possible, including the elimination of redundancy, the minimization of the use of null values and the prevention of the loss of information. • Aims of Normalization: • Normalization ensures that the database is structured in the best possible way. • To achieve control over data redundancy. There should be no unnecessary duplication of data in different tables. • To ensure data consistency. Where duplication is necessary the data is the same. • To allow data in different tables can be used in complex queries.

5

Stages of Normalization • First Normal Form (1NF) • Second Normal Form (2NF) • Third Normal Form (3NF) • Boyce-Codd Normal Form (BCNF) • Fourth Normal Form (4NF) • Fifth Normal Form (5NF)

6

Candidate Key • A Candidate Key is an attribute (possibly composite) that can be used to uniquely identify each tuple in a relation. • A relation may have more than one candidate key • If so, one candidate key is nominated as the primary key

7

First Normal Form

8

First Normal Form • The official qualifications for 1NF are: • Each attribute name must be unique. • Each attribute value must be single. • Each row must be unique. • There is no repeating groups. • Additional: • Choose a primary key. • Reminder: • A primary key is unique, not null, unchanged. • A primary key can be either an attribute or combined attributes.

9

First Normal Form Ex:1 • Non-Normalized Table: (Student Table)

10

First Normal Form • To convert data for unnormalized form to 1NF, simply convert any repeated attributes into part of the candidate key • STUDENT(Number, Name, Classes) • STUDENT(Number, Name, Classes)

11

First Normal Form

12

First Normal Form Ex:2 • Example of a table not in 1NF : Group Topic Student Score Group A Group B Intro MongoDB Intro MySQL Sok San 18 marks Sao Ry 17 marks Chan Tina 19 marks Tith Sophea 16 marks It violates the 1NF because: • Attribute values are not single. • Repeating groups exists.

13

First Normal Form Ex:2 • After eliminating: Now it is in 1NF. However, it might still violate 2NF and so on. Group Topic Family Name Given Name Score A Intro MongoDB Sok San 18 A Intro MongoDB Sao Ry 17 B Intro MySQL Chan Tina 19 B Intro MySQL Tith Sophea 16

14

Over to you...

15

Second Normal Form

16

Second Normal Form • A table is in the second normal form if : 1. It's in the first normal form 2. No column that is not part of the primary key is dependent only a portion of the primary key

17

Second Normal Form • The official qualifications for 2NF are: • A table is already in 1NF. • All nonkey attributes are fully dependent on the primary key. • All partial dependencies are removed to place in another table.

18

Second Normal Form • The concept of functional dependency in central to normalization and, in particular, strongly related to 2NF.

19

Functional Dependency • If ‘X’ is a set of attributes within a relation, then we say ‘A’ (an attribute or set of attributes), is functionally dependent on X, if and only if, for every combination of X, there is only one corresponding value of A • We write this as : X -> A

20

Functional Dependency • We say an attribute, B, has a functional dependency on another attribute, A, if for any two records, which have the same value for A, then the values for B in these two records must be the same. We illustrate this as: • A -> B (read as: A determines B or B depends on A)

21

Functional Dependency EX • employee name -> email address employee name project email address Sok San POS MartSys soksan@yahoo.com Sao Ry Univ Mgt Sys sao@yahoo.com Sok San Web Redesign soksan@yahoo.com Chan Sokna POS MartSys chan@gmail.com Sao Ry DB Design sao@yahoo.com

22

Functional Dependency EX • If EmpNum is the PK then the FDs: EmpNum -> EmpEmail, EmpFname, EmpLname • must exist. EmpNum EmpEmail EmpFname EmpLname 123 jdoe@abc.com John Doe 456 psmith@abc.com Peter Smith 555 alee1@abc.com Alan Lee 633 pdoe@abc.com Peter Doe 787 alee2@abc.com Alan Lee

23

3 different ways you might see FDs depicted EmpNum -> EmpEmail, EmpFname, EmpLname

24

Determinant • Functional Dependency EmpNum -> EmpEmail • Attribute on the left hand side is known as the determinant EmpNum is a determinant of EmpEmail

25

Example 1: Table in 1NF

26

Functional Dependency • It is clear that : RefNo -> Name, Address, Status or, most correctly, AccNo, RefNo -> Name, Address, Status

27

Table in 1NF

28

Example 2: Table in 1NF • FD: CourseID -> Course Name CourseID SemesterID Num Student Course Name IT101 201301 25 Database IT101 201302 25 Database IT102 201301 30 Web Prog IT102 201302 35 Web Prog IT103 201401 20 Networking • The Course Name depends on only CourseID, a part of the primary key not the whole primary {CourseID, SemesterID}.It’s called partial dependency. Solution: • Remove CourseID and Course Name together to create a new table.

29

CourseID SemesterID Num Student Course Name IT101 201301 25 Database IT101 201302 25 Database IT102 201301 30 Web Prog IT102 201302 35 Web Prog IT103 201401 20 Networking CourseID Course Name IT101 Database IT101 Database IT102 Web Prog IT102 Web Prog IT103 Networking C ourseID SemesterID Num Student IT101 201301 25 IT101 201302 25 IT102 201301 30 IT102 201302 35 IT103 201401 20 Done? Oh no, it is still not in 1NF yet. Remove the repeating groups too. CourseID Course Name IT101 Database IT102 Web Prog IT103 Networking

30

Over to you... Functional Dependency: Supplier#, Part# -> Quantity Supplier# -> City

31

Normalization

32

Third Normal Form

33

Third Normal Form • A table is in the third normal form if: 1. It is the second normal form 2. There are no non-key columns dependent on other non- key columns that could not act as the primary key.

34

Third Normal Form • The official qualifications for 3NF are: • A table is already in 2NF. • Nonprimary key attributes do not depend on other nonprimary key attributes • (i.e. no transitive dependencies) • All transitive dependencies are removed to place in another table.

35

Third Normal Form Ex:1 Functional Dependency: BranchName -> Address, ManagerNo AccNO -> Balance, Type, BranchName, Address, ManagerNo

36

Branch Name Address Manager No Rathmines 15 Upr Rathmimes Road 1234 Dame St. 1 Dame Street 1101

37

Third Normal Form Ex:2 • Example of a Table not in 3NF: • The Teacher Tel is a nonkey attribute, and the Teacher Name is also a nonkey atttribute. But Teacher Tel depends on Teacher Name. It is called transitive dependency. StudyID Course Name Teacher Name Teacher Tel 1 Database Sok Piseth 012 123 456 2 Database Sao Kanha 0977 322 111 3 Web Prog Chan Veasna 012 412 333 4 Web Prog Chan Veasna 012 412 333 5 Networking Pou Sambath 077 545 221 Primary Key Solution: Remove Teacher Name and Teacher Tel together to create a new table.

38

Teacher Name Teacher Tel Sok Piseth 012 123 456 Sao Kanha 0977 322 111 Chan Veasna 012 412 333 Chan Veasna 012 412 333 Pou Sambath 077 545 221 Done? Oh no, it is still not in 1NF yet. Remove Repeating row. Teacher Name Teacher Tel Sok Piseth 012 123 456 Sao Kanha 0977 322 111 Chan Veasna 012 412 333 Pou Sambath 077 545 221 ID Teacher Name Teacher Tel T1 Sok Piseth 012 123 456 T2 Sao Kanha 0977 322 111 T3 Chan Veasna 012 412 333 T4 Pou Sambath 077 545 221 Note about primary key: -In theory, you can choose Teacher Name to be a primary key. -But in practice, you should add Teacher ID as the primary key. StudyID C ourse N ame T.ID 1 Database T1 2 Database T2 3 Web Prog T3 4 Web Prog T3 5 Networking T4

39

Boyce-Codd Normal Form

40

Boyce- Codd Normal Form • All attributes in a relation should be dependent upon the key, the whole key and nothing but the key

41

Boyce- Codd Normal Form • The official qualifications for BCNF are: • A table is already in 3NF. • All determinants must be superkeys. • All determinants that are not superkeys are removed to place in another table.

42

Boyce-Codd Normal Form EX:1

43

Redundancy in 3NF • The combination of ROOM, TIME is unique to each tuple, no room is used twice at the same time (thus it is in 3NF). • But, we know there is a redundancy in that ROOM depends LECTURER, therefore, we split the table...

44

Normalization

45

Boyce-Codd Normal Form EX:2 • Example of a table not in BCNF: • Key: {Student, Course} • Functional Dependency: {Student, Course} -> Teacher Teacher -> Course Student Course Teacher Sok DB John Sao DB William Chan E-Commerce Todd Sok E-Commerce Todd Chan DB William Problem: Teacher is not a superkey but determines Course.

46

Student Course Sok DB Sao DB Chan E-Commerce Sok E-Commerce Chan DB Course Teacher DB John DB W illiam E-Commerce Todd Course DB E-Commerce Solution: Decouple a table contains Teacher and Course from from original table (Student, Course). Finally, connect the new and old table to third table contains Course.

47

Boyce-Codd Normal Form • Difference between BCNF and 3NF: • Most relations in 3NF are also in BCNF, the only time this may not be true is when there is more than one candidate key for a relation and at least one of is composite.

More Related Content

Normalization

  • 1. Normalization Ahmed Farag Information Systems Dept. Faculty of Computers and Information Menoufia University, Egypt.
  • 3. Normaliz ation • The biggest problem needed to be solved in database is data redundancy. • Why data redundancy is the problem? Because it causes: • Insert Anomaly • Update Anomaly • Delete Anomaly Teacher Subject Teacher Degree Tel Sok San Database Master's 012666777 Van Sokhen Database Bachelor's 017678678 Sok San E-Commerce Master's 012666777
  • 4. Normaliz ation • Normalization is a process by which data structures in a relational database are as efficient as possible, including the elimination of redundancy, the minimization of the use of null values and the prevention of the loss of information. • Aims of Normalization: • Normalization ensures that the database is structured in the best possible way. • To achieve control over data redundancy. There should be no unnecessary duplication of data in different tables. • To ensure data consistency. Where duplication is necessary the data is the same. • To allow data in different tables can be used in complex queries.
  • 5. Stages of Normalization • First Normal Form (1NF) • Second Normal Form (2NF) • Third Normal Form (3NF) • Boyce-Codd Normal Form (BCNF) • Fourth Normal Form (4NF) • Fifth Normal Form (5NF)
  • 6. Candidate Key • A Candidate Key is an attribute (possibly composite) that can be used to uniquely identify each tuple in a relation. • A relation may have more than one candidate key • If so, one candidate key is nominated as the primary key
  • 8. First Normal Form • The official qualifications for 1NF are: • Each attribute name must be unique. • Each attribute value must be single. • Each row must be unique. • There is no repeating groups. • Additional: • Choose a primary key. • Reminder: • A primary key is unique, not null, unchanged. • A primary key can be either an attribute or combined attributes.
  • 9. First Normal Form Ex:1 • Non-Normalized Table: (Student Table)
  • 10. First Normal Form • To convert data for unnormalized form to 1NF, simply convert any repeated attributes into part of the candidate key • STUDENT(Number, Name, Classes) • STUDENT(Number, Name, Classes)
  • 12. First Normal Form Ex:2 • Example of a table not in 1NF : Group Topic Student Score Group A Group B Intro MongoDB Intro MySQL Sok San 18 marks Sao Ry 17 marks Chan Tina 19 marks Tith Sophea 16 marks It violates the 1NF because: • Attribute values are not single. • Repeating groups exists.
  • 13. First Normal Form Ex:2 • After eliminating: Now it is in 1NF. However, it might still violate 2NF and so on. Group Topic Family Name Given Name Score A Intro MongoDB Sok San 18 A Intro MongoDB Sao Ry 17 B Intro MySQL Chan Tina 19 B Intro MySQL Tith Sophea 16
  • 16. Second Normal Form • A table is in the second normal form if : 1. It's in the first normal form 2. No column that is not part of the primary key is dependent only a portion of the primary key
  • 17. Second Normal Form • The official qualifications for 2NF are: • A table is already in 1NF. • All nonkey attributes are fully dependent on the primary key. • All partial dependencies are removed to place in another table.
  • 18. Second Normal Form • The concept of functional dependency in central to normalization and, in particular, strongly related to 2NF.
  • 19. Functional Dependency • If ‘X’ is a set of attributes within a relation, then we say ‘A’ (an attribute or set of attributes), is functionally dependent on X, if and only if, for every combination of X, there is only one corresponding value of A • We write this as : X -> A
  • 20. Functional Dependency • We say an attribute, B, has a functional dependency on another attribute, A, if for any two records, which have the same value for A, then the values for B in these two records must be the same. We illustrate this as: • A -> B (read as: A determines B or B depends on A)
  • 21. Functional Dependency EX • employee name -> email address employee name project email address Sok San POS MartSys soksan@yahoo.com Sao Ry Univ Mgt Sys sao@yahoo.com Sok San Web Redesign soksan@yahoo.com Chan Sokna POS MartSys chan@gmail.com Sao Ry DB Design sao@yahoo.com
  • 22. Functional Dependency EX • If EmpNum is the PK then the FDs: EmpNum -> EmpEmail, EmpFname, EmpLname • must exist. EmpNum EmpEmail EmpFname EmpLname 123 jdoe@abc.com John Doe 456 psmith@abc.com Peter Smith 555 alee1@abc.com Alan Lee 633 pdoe@abc.com Peter Doe 787 alee2@abc.com Alan Lee
  • 23. 3 different ways you might see FDs depicted EmpNum -> EmpEmail, EmpFname, EmpLname
  • 24. Determinant • Functional Dependency EmpNum -> EmpEmail • Attribute on the left hand side is known as the determinant EmpNum is a determinant of EmpEmail
  • 26. Functional Dependency • It is clear that : RefNo -> Name, Address, Status or, most correctly, AccNo, RefNo -> Name, Address, Status
  • 28. Example 2: Table in 1NF • FD: CourseID -> Course Name CourseID SemesterID Num Student Course Name IT101 201301 25 Database IT101 201302 25 Database IT102 201301 30 Web Prog IT102 201302 35 Web Prog IT103 201401 20 Networking • The Course Name depends on only CourseID, a part of the primary key not the whole primary {CourseID, SemesterID}.It’s called partial dependency. Solution: • Remove CourseID and Course Name together to create a new table.
  • 29. CourseID SemesterID Num Student Course Name IT101 201301 25 Database IT101 201302 25 Database IT102 201301 30 Web Prog IT102 201302 35 Web Prog IT103 201401 20 Networking CourseID Course Name IT101 Database IT101 Database IT102 Web Prog IT102 Web Prog IT103 Networking C ourseID SemesterID Num Student IT101 201301 25 IT101 201302 25 IT102 201301 30 IT102 201302 35 IT103 201401 20 Done? Oh no, it is still not in 1NF yet. Remove the repeating groups too. CourseID Course Name IT101 Database IT102 Web Prog IT103 Networking
  • 30. Over to you... Functional Dependency: Supplier#, Part# -> Quantity Supplier# -> City
  • 33. Third Normal Form • A table is in the third normal form if: 1. It is the second normal form 2. There are no non-key columns dependent on other non- key columns that could not act as the primary key.
  • 34. Third Normal Form • The official qualifications for 3NF are: • A table is already in 2NF. • Nonprimary key attributes do not depend on other nonprimary key attributes • (i.e. no transitive dependencies) • All transitive dependencies are removed to place in another table.
  • 35. Third Normal Form Ex:1 Functional Dependency: BranchName -> Address, ManagerNo AccNO -> Balance, Type, BranchName, Address, ManagerNo
  • 36. Branch Name Address Manager No Rathmines 15 Upr Rathmimes Road 1234 Dame St. 1 Dame Street 1101
  • 37. Third Normal Form Ex:2 • Example of a Table not in 3NF: • The Teacher Tel is a nonkey attribute, and the Teacher Name is also a nonkey atttribute. But Teacher Tel depends on Teacher Name. It is called transitive dependency. StudyID Course Name Teacher Name Teacher Tel 1 Database Sok Piseth 012 123 456 2 Database Sao Kanha 0977 322 111 3 Web Prog Chan Veasna 012 412 333 4 Web Prog Chan Veasna 012 412 333 5 Networking Pou Sambath 077 545 221 Primary Key Solution: Remove Teacher Name and Teacher Tel together to create a new table.
  • 38. Teacher Name Teacher Tel Sok Piseth 012 123 456 Sao Kanha 0977 322 111 Chan Veasna 012 412 333 Chan Veasna 012 412 333 Pou Sambath 077 545 221 Done? Oh no, it is still not in 1NF yet. Remove Repeating row. Teacher Name Teacher Tel Sok Piseth 012 123 456 Sao Kanha 0977 322 111 Chan Veasna 012 412 333 Pou Sambath 077 545 221 ID Teacher Name Teacher Tel T1 Sok Piseth 012 123 456 T2 Sao Kanha 0977 322 111 T3 Chan Veasna 012 412 333 T4 Pou Sambath 077 545 221 Note about primary key: -In theory, you can choose Teacher Name to be a primary key. -But in practice, you should add Teacher ID as the primary key. StudyID C ourse N ame T.ID 1 Database T1 2 Database T2 3 Web Prog T3 4 Web Prog T3 5 Networking T4
  • 40. Boyce- Codd Normal Form • All attributes in a relation should be dependent upon the key, the whole key and nothing but the key
  • 41. Boyce- Codd Normal Form • The official qualifications for BCNF are: • A table is already in 3NF. • All determinants must be superkeys. • All determinants that are not superkeys are removed to place in another table.
  • 43. Redundancy in 3NF • The combination of ROOM, TIME is unique to each tuple, no room is used twice at the same time (thus it is in 3NF). • But, we know there is a redundancy in that ROOM depends LECTURER, therefore, we split the table...
  • 45. Boyce-Codd Normal Form EX:2 • Example of a table not in BCNF: • Key: {Student, Course} • Functional Dependency: {Student, Course} -> Teacher Teacher -> Course Student Course Teacher Sok DB John Sao DB William Chan E-Commerce Todd Sok E-Commerce Todd Chan DB William Problem: Teacher is not a superkey but determines Course.
  • 46. Student Course Sok DB Sao DB Chan E-Commerce Sok E-Commerce Chan DB Course Teacher DB John DB W illiam E-Commerce Todd Course DB E-Commerce Solution: Decouple a table contains Teacher and Course from from original table (Student, Course). Finally, connect the new and old table to third table contains Course.
  • 47. Boyce-Codd Normal Form • Difference between BCNF and 3NF: • Most relations in 3NF are also in BCNF, the only time this may not be true is when there is more than one candidate key for a relation and at least one of is composite.