Happy Holidays to all.

From Solstice onward, may you have one Epiphany after another.

Peace, Joy and Prosperity in 2005,
From Clarise, Joseph, and all at Team InterASC and TeleInterActive press.

This is the last of the series on the 3 Rules of Normalization for Newbies. If you have forgotten the first 2 rules, review the 2 previous blogs because inherent to the 3NF Rule is compliance with the first two.

The 3NF Rule states: "No non-UID can depend upon another non-UID attribute." This basically means an entity is in the Third Normal Form if it is in 2NF and every one of its attributes is NOT dependent on any other describing attribute.

Let us consider the following example:

Training_Score is dependent on Training_Date. To make this in 3NF, move Training_Score and Training_Date to the entity Training.

So, this concludes our series on the 3 First Normalization Rules. The complete picture of our simple example is:

In yesterday's blog, I discussed 1NF. Today, as promised, is the blog about 2NF.

The 2NF Rule states: "An attribute must depend upon its entity's entire UID". This basically means that every one of the attributes is functionally dependent on the whole key. Also, implicit to this rule is the fact that the entitiy is in its 1NF. So, if you have forgotten what 1NF is all about, review yesterday's blog.

Consider the following example:

The attribute Warehouse_Location is not functionally dependent on Emp_ID. To make this Entity Relationship Diagram in 2NF, move the attribute Warehouse_Location to the entity Warehouse. To be compliant with the 1NF, Warehouse_Location is put in its basic form as Warehouse_Address1, Warehouse_City, Warehouse_State, Warehouse_ZIPCode.

This will result in:

Tomorrow's blog is the last installment of this series on the First 3 Rules of Normalization.

The First Normal Form States: "All attributes are not repeated or must be single-valued"

In identifying whether a table is in its 1NF, consider this 3-points checklist:
1. Does a Primary Key exist?
2. Have you ensured that each attribute is in its basic form? Being in its basic form means that it is not derived
3. Have you ensured that the attribute is not repeated and considered single-valued?

Let us examine the following simple example :

1. Existence of a Primary Key: EMPLOYEE is uniquely identified by its attribute Employee_ID.

2. Verification that the attribute is in its basic form: The attribute Emp_Age is derived. Emp_Age is broken to its basic form, e.g. Emp_DateOfBirth.

3. Verification that the attribute is not repeating: In the example, Emp_Dependent, Emp_DependentNM, Emp_DependentDOB can be classified as repeating occurrences of EmployeeDependent. To make it in 1NF, move these to its own Entity.

The final result of the example will be:

Next blog will be on the 2NF.

The work of Dr. Codd as published in A Relational Model of Data for Large Shared Data Bank by E.F. Codd provides the detailed and comprehensive explanation of Relational Model and Normalization.

I just want my blog to be short and sweet each day. So, over the next 3 days, I shall blog on a normalization rule. I learn by example so I shall discuss the rules through examples.

Normalization helps eliminate the problems of redundancy in database design. It reinforces referential integrity in the database and provides a way to index. A highly normalized design may need a large number of joins. Hence, there is a need to carefully review the degree of normalization in a database design. One must consider the database’s intended use.

The First 3 Rules of Normalization are:

1. First Normal Form (1NF): All attributes are not repeated or must be single-valued
2. Second Normal Form (2NF): An attribute must depend upon its entities entire UID
3. Third Normal Form (3NF): No non-UID attribute can be dependent upon another non-UID attribute

Part 1 of my blog will be about 1NF.