1 Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms.
Normal Forms in Relational Databases 1
-
Upload
hermione-hodge -
Category
Documents
-
view
38 -
download
0
description
Transcript of Normal Forms in Relational Databases 1
![Page 1: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/1.jpg)
Normal Forms in Relational Databases1
1 Bolstad, P. pp 283-291
![Page 2: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/2.jpg)
Problem
• Massive tables with information about multiple entities become unwieldy making data update and maintenance difficult.
• They suffer from performance issues, consistency, and redundancy
![Page 3: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/3.jpg)
ProblemRedundancy: Alderman Johnson in twice
Access: linear search to find parcels owned
by Yamane
Independence: If Devlin, Yamane and Prestovic sell
the parcel they jointly own Devlin is
purged from the database!
![Page 4: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/4.jpg)
Solution: Normalization
• Data structured in sequentially higher orders of normal form to:– improve consistency– Reduce redundancy – Increase stability
![Page 5: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/5.jpg)
Definitions
• Supper key: one or more attributes that may be used to uniquely id one and only one record
• Candidate key is a subset of the supper key which may also be a superkey.
• Primary key chosen from candidate keys that has a one to one correspondence to each record
• Functional dependency– For a given point in time each value of the dependent
attribute is determined by a value of another attribute.• Own_name -> Own-add• Tshp_name -> Thall-add• Transitive
![Page 6: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/6.jpg)
1st NF
• A table is in first normal form when there are no repeat columns– Most basic and still suffers from excessive
storage, redundancy, inefficient searches and potential loss of data upon updating
![Page 7: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/7.jpg)
2nd NF
• In 1st NF form and every non-key attribute is functionally dependent on the primary key.
• Note in 1st NF parcel-ID, Alderman and Tship-ID are duplicated when there are multiple owners of a parcel. Upon update of say Alderman, each redundant record needs to be updated.
![Page 8: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/8.jpg)
First to Second NF
Parcel – ID -> AldermanParcel – ID -> Tship-IDParcel – ID -> Tship_NameParcel – ID -> Thall_add
Own-ID -> Own_nameOwn-ID -> Own_add
Link of two
![Page 9: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/9.jpg)
Still a problem with 2nd NF
• The 2nd NF still has problems though it’s much better than 1st.
• The problem is transitive dependency. In our table Land Record 1, Parcel-ID specifies Tship-ID and Tship-ID specifies Tship_nam and Thall_add, so:– Parcel-ID -> Tship-ID, Alderman
– And
– Tship-ID -> Tship-nam, Thall-add– If we delete a parcel we remove the parcel from
tables Land Records 1 and Land Records 3 and loose relationship between Tship-ID, Tship_name and Thall_add.
![Page 10: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/10.jpg)
Solution: 3rd NF
• A table is in third normal fom if and only if for every functional dependency A-> B, A is a superkey or B is a member of a candidate key.
• Must ID all transitive functional dependencies and remove then by creating new tables
![Page 11: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/11.jpg)
Example
![Page 12: Normal Forms in Relational Databases 1](https://reader035.fdocuments.net/reader035/viewer/2022062221/56813665550346895d9df34f/html5/thumbnails/12.jpg)