lecture 04 normalization
DESCRIPTION
TRANSCRIPT
![Page 1: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/1.jpg)
4
Lecture 4
Normalization of Database Tables
![Page 2: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/2.jpg)
4
2
In this Lecture, you will learn:
• What normalization is and what role it plays in database design
• About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF
• How normal forms can be transformed from lower normal forms to higher normal forms
• That normalization and E-R modeling are used concurrently to produce a good database design
• That some situations require denormalization to generate information efficiently
![Page 3: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/3.jpg)
4
3
Database Tables and Normalization
• Table is basic building block in database design• Normalization is process for assigning attributes to
entities– Reduces data redundancies– Helps eliminate data anomalies– Produces controlled redundancies to link tables
• Normalization stages– 1NF - First normal form– 2NF - Second normal form– 3NF - Third normal form– 4NF - Fourth normal form
![Page 4: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/4.jpg)
4
4
Need for Normalization
Figure 4.1
![Page 5: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/5.jpg)
4
5
Figure 4.1 Observations
• PRO_NUM intended to be primary key• Table entries invite data inconsistencies• Table displays data anomalies
– Update• Modifying JOB_CLASS
– Insertion• New employee must be assigned project
– Deletion• If employee deleted, other vital data lost
![Page 6: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/6.jpg)
4
6
Conversion to 1NF
• Repeating groups must be eliminated– Proper primary key developed
• Uniquely identifies attribute values (rows)• Combination of PROJ_NUM and EMP_NUM
– Dependencies can be identified• Desirable dependencies based on primary key• Less desirable dependencies
– Partial » based on part of composite primary key
– Transitive
» one nonprime attribute depends on another nonprime attribute
![Page 7: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/7.jpg)
4
7
Dependency Diagram (1NF)
Figure 4.4
![Page 8: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/8.jpg)
4
8
Data Organization: 1NF
Figure 4.3
![Page 9: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/9.jpg)
4
9
1NF Summarized
• All key attributes defined• No repeating groups in table• All attributes dependent on
primary key
![Page 10: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/10.jpg)
4
10
Conversion to 2NF
• Start with 1NF format:• Write each key component on separate line• Write original key on last line• Each component is new table• Write dependent attributes after each key
PROJECT (PROJ_NUM, PROJ_NAME)EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
![Page 11: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/11.jpg)
4
11
2NF Conversion Results
Figure 4.5
![Page 12: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/12.jpg)
4
12
2NF Summarized
• In 1NF• Includes no partial dependencies
– No attribute dependent on a portion of primary key
• Still possible to exhibit transitive dependency– Attributes may be functionally dependent on
nonkey attributes
![Page 13: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/13.jpg)
4
13
Conversion to 3NF
• Create separate table(s) to eliminate transitive functional dependencies
PROJECT (PROJ_NUM, PROJ_NAME)ASSIGN (PROJ_NUM, EMP_NUM, HOURS)EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)JOB (JOB_CLASS, CHG_HOUR)
![Page 14: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/14.jpg)
4
14
3NF Summarized
• In 2NF• Contains no transitive dependencies
![Page 15: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/15.jpg)
4
15
Additional DB Enhancements
Figure 4.6
![Page 16: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/16.jpg)
4
16
Boyce-Codd Normal Form (BCNF)
• Every determinant in the table is a candidate key– Determinant is attribute whose value determines
other values in row
– 3NF table with one candidate key is already in BCNF
![Page 17: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/17.jpg)
4
17
3NF Table Not in BCNF
Figure 4.7
![Page 18: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/18.jpg)
4
18
Decomposition of Table Structure to Meet BCNF
Figure 4.8
![Page 19: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/19.jpg)
4
19
Decomposition into BCNF
Figure 4.9
![Page 20: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/20.jpg)
4
20
Normalization and Database Design
• Normalization should be part of the design process
• E-R Diagram provides macro view• Normalization provides micro view of entities
– Focuses on characteristics of specific entities
– May yield additional entities
• Difficult to separate normalization from E-R diagramming
• Business rules must be determined
![Page 21: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/21.jpg)
4
21
Initial ERD for Contracting Company
Figure 4.10
![Page 22: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/22.jpg)
4
22
Modified ERD for Contracting Company
Figure 4.11
![Page 23: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/23.jpg)
4
23
Final ERD for Contracting Company
Figure 4.12
![Page 24: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/24.jpg)
4
24
Higher-Level Normal Forms
• Fourth Normal Form (4NF)– Table is in 3NF
– Has no multiple sets of multivalued dependencies
![Page 25: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/25.jpg)
4
25
Conversion to 4NF
Figure 4.14Multivalued Dependencies
Figure 4.15Set of Tables in 4NF
![Page 26: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/26.jpg)
4
26
Denormalization
• Normalization is one of many database design goals
• Normalized table requirements
– Additional processing
– Loss of system speed
• Normalization purity is difficult to sustain due to conflict in:– Design efficiency
– Information requirements
– Processing
![Page 27: Lecture 04 normalization](https://reader034.vdocuments.net/reader034/viewer/2022051109/547b6797b4af9fea158b4e69/html5/thumbnails/27.jpg)
4
27
Unnormalized Table Defects
• Data updates less efficient• Indexing more cumbersome• No simple strategies for creating views