Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a...
-
Upload
spencer-kennedy -
Category
Documents
-
view
220 -
download
1
Transcript of Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a...
![Page 1: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/1.jpg)
1Chapter 7Database Principles
Data NormalizationData NormalizationPrimarily a tool to validate and improve a
logical design so that it satisfies certain constraints that avoid unnecessary duplication of data
The process of decomposing relations with anomalies to produce smaller, well-structured relations
Chapter 7Chapter 7Logical Database Design Logical Database Design
Relational Systems (Normalization) Relational Systems (Normalization)
![Page 2: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/2.jpg)
2Chapter 7Database Principles
Well-Structured RelationsWell-Structured Relations A relation that contains minimal data redundancy
and allows users to insert, delete, and update rows without causing data inconsistencies
Goal is to avoid anomalies– Insertion Anomaly – adding new rows forces user to
create duplicate data– Deletion Anomaly – deleting rows may cause a loss of
data that would be needed for other future rows– Modification Anomaly – changing data in a row forces
changes to other rows because of duplication
General rule of thumb: a table should not pertain to more than one entity type
![Page 3: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/3.jpg)
3Chapter 7Database Principles
Example – Figure 5.2bExample – Figure 5.2b
Question – Is this a relation? Answer – Yes: unique rows and no multivalued attributes
Question – What’s the primary key? Answer – Composite: Emp_ID, Course_Title
![Page 4: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/4.jpg)
4Chapter 7Database Principles
Anomalies in this TableAnomalies in this TableInsertion – can’t enter a new employee without
having the employee take a classDeletion – if we remove employee 140, we lose
information about the existence of a Tax Acc classModification – giving a salary increase to
employee 100 forces us to update multiple records
Why do these anomalies exist? Because we’ve combined two themes (entity types) into one relation. This results in duplication, and an unnecessary dependency between the entities
![Page 5: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/5.jpg)
5Chapter 7Database Principles
Functional Dependencies and KeysFunctional Dependencies and KeysFunctional Dependency: The value of one
attribute (the determinant) determines the value of another attribute
Candidate Key:– A unique identifier. One of the candidate keys
will become the primary key E.g. perhaps there is both credit card number and SS#
in a table…in this case both are candidate keys
– Each non-key field is functionally dependent on every candidate key
![Page 6: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/6.jpg)
6Chapter 7Database Principles
5.22 -Steps in normalization
![Page 7: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/7.jpg)
7Chapter 7Database Principles
First Normal FormFirst Normal Form
No multivalued attributesEvery attribute value is atomicFig. 5-2a is not in 1st Normal Form
(multivalued attributes) it is not a relationFig. 5-2b is in 1st Normal formAll relations are in 1st Normal Form
![Page 8: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/8.jpg)
8Chapter 7Database Principles
Second Normal FormSecond Normal Form1NF plus every non-key attribute is fully
functionally dependent on the ENTIRE primary key– Every non-key attribute must be defined by the
entire key, not by only part of the key– No partial functional dependencies
Fig. 5-2b is NOT in 2nd Normal Form (see fig 5-23b)
![Page 9: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/9.jpg)
9Chapter 7Database Principles
Fig 5.23(b) – Functional Fig 5.23(b) – Functional Dependencies in EMPLOYEE2Dependencies in EMPLOYEE2
EmpID CourseTitle DateCompletedSalaryDeptNameName
Dependency on entire primary key
Dependency on only part of the key
EmpID, CourseTitle DateCompleted
EmpID Name, DeptName, Salary
Therefore, NOT in 2nd Normal Form!!
![Page 10: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/10.jpg)
10Chapter 7Database Principles
Getting it into 2Getting it into 2ndnd Normal Form Normal Form See p193 – decomposed into two separate relations
EmpID SalaryDeptNameName
CourseTitle DateCompletedEmpID
Both are full functional dependencies
![Page 11: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/11.jpg)
11Chapter 7Database Principles
Third Normal FormThird Normal Form
2NF PLUS no transitive dependencies (one attribute functionally determines a second, which functionally determines a third)
Fig. 5-24, 5-25
![Page 12: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/12.jpg)
12Chapter 7Database Principles
Figure 5-24 -- Relation with transitive dependency
(a) SALES relation with simple data
![Page 13: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/13.jpg)
13Chapter 7Database Principles
Figure 5-24(b) Relation with transitive dependency
CustID NameCustID SalespersonCustID Region
All this is OK(2nd NF)
BUT
CustID Salesperson Region
Transitive dependency(not 3rd NF)
![Page 14: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/14.jpg)
14Chapter 7Database Principles
Figure 5.25 -- Removing a transitive dependency
(a) Decomposing the SALES relation
![Page 15: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/15.jpg)
15Chapter 7Database Principles
Figure 5.25(b) Relations in 3NF
Now, there are no transitive dependencies…Both relations are in 3rd NF
CustID Name
CustID Salesperson
Salesperson Region
![Page 16: Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.](https://reader036.fdocuments.us/reader036/viewer/2022062314/56649eb55503460f94bbe43d/html5/thumbnails/16.jpg)
16Chapter 7Database Principles
Other Normal Forms Other Normal Forms (from Appendix B)(from Appendix B)
Boyce-Codd NF– All determinants are candidate keys…there is no determinant
that is not a unique identifier 4th NF
– No multivalued dependencies 5th NF
– No “lossless joins” Domain-key NF
– The “ultimate” NF…perfect elimination of all possible anomalies