Normal Forms in Relational Databases 1 1 Bolstad, P. pp

Problem Massive tables with information about multiple entities become unwieldy making data update and maintenance difficult. They suffer from performance issues, consistency, and redundancy

Problem Redundancy: 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!

Solution: Normalization Data structured in sequentially higher orders of normal form to: –improve consistency –Reduce redundancy –Increase stability

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

1 st 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

2 nd NF In 1 st NF form and every non-key attribute is functionally dependent on the primary key. Note in 1 st 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.

First to Second NF Parcel – ID -> Alderman Parcel – ID -> Tship-ID Parcel – ID -> Tship_Name Parcel – ID -> Thall_add Own-ID -> Own_name Own-ID -> Own_add Link of two

Still a problem with 2 nd NF The 2 nd NF still has problems though it’s much better than 1 st. 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.

Solution: 3 rd 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

Example