normal forms in relational databases 1

Normal Forms in Relational Databases1

1 Bolstad, P. pp 283-291

Problem

• Massive tables with information about multiple entities become unwieldy making data update and maintenance difficult.

• They suffer from performance issues, consistency, and redundancy

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!

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

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

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.

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

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.

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

Example