Thursday, December 27, 2012

Database Normalization

What is Normalization ? Why should we use it?

Normalization is a database design technique which organizes tables in a manner that reduces redundancy and dependency of data.
It divides larger tables to smaller tables and link them using relationships.
The inventor of the relational model Edgar Codd proposed the theory of normalization with the introduction of FirstNormal Form and he continued to extend theory with Second and Third Normal Form. Later he joined with Raymond F. Boyce  to develop the theory of Boyce-Codd Normal Form

Theory of Normalization is still being developed further. For example there are discussions even on 6th Normal Form. But in most practical applications normalization achieves its best in 3rd Normal FormThe evolution of Normalization theories is illustrated below-

alt

Let’s learn Normalization with practical example -

Assume a video library maintains a database of movies rented out. Without any normalization all information is stored in one table as shown below.

alt
Table 1


Here you see Movies  Rented column has multiple values.
Now let’s move in to 1st Normal Form

1NF Rules


  • Each table cell should contain single value.
  • Each record needs to be unique.

The above table in 1NF-
alt
Table 1 : In 1NF Form


Before we proceed lets understand a few things --

What is a KEY ?


A KEY  is a value used to uniquely identify a record in a table. A KEY could be a single column or combination of multiple columns

Note: Columns in a table that are NOT used to uniquely identify a record are called non-key columns.

What is a primary Key?


alt


A primary is a single column values used to uniquely identify a database record.
It has following attributes
  • A primary key cannot be NULL
  • A primary key value must be unique
  • The primary key values can not be changed
  • The primary key must be given a value when a new record is inserted.

What is a composite Key?

A composite key is a primary key composed of multiple columns used to identify a record uniquely

In our database , we have two people with the same name Robert Phil but they live at different places.
alt
Hence we require both Full Name and Address to uniquely identify a record. This is a composite key.
Let’s move into 2NF

2NF Rules

  • Rule 1- Be in 1NF
  • Rule 2- Single Column Primary Key


It is clear that we can’t move forward to make our simple database in 2nd Normalization form unless we partition the table above.
alt
Table 1



alt
Table 2



We have divided our 1NF table into two tables viz. Table 1 and Table2. Table 1 contains member information. Table 2 contains information on movies rented.
We have introduced a new column called Membership_id which is the primary key for table 1. Records can be uniquely identified in Table 1 using membership id


Introducing Foreign Key!


In Table 2, Membership_ID is the foreign Key
alt


altForeign Key references primary key of another Table!It helps connect your Tables

  • A foreign key can have a different name from its primary key
  • It ensures rows in one table have corresponding rows in another
  • Unlike Primary key they do not have to be unique. Most often they aren’t
  • Foreign keys can be null even though primary keys can not


alt

Why do you need a foreign key ?


Suppose an idiot inserts a record in Table B such as
You will only be able to insert values into your foreign key that exist in the unique key in the parent table. This helps in referential integrity. 
alt

The above problem can be overcome by declaring membership id  from Table2  as foreign key of membership id  from Table1 
Now , if somebody tries to insert a value in the membership id  field that does not exist in the parent table , an error will be shown!

What is a transitive functional dependencies?

A transitive functional dependency is when changing a non-key column , might cause any of the other non-key columns to change
Consider the table 1. Changing the non-key column Full Name , may change Salutation.
alt
Let’s move ito 3NF

3NF Rules

  • Rule 1- Be in 2NF
  • Rule 2- Has no transitive functional dependencies
To move our 2NF table into 3NF we again need to need divide our table.

alt
TABLE 1



alt
Table 2



alt
Table 3


We have again divided our tables and created a new table which stores Salutations. 
There are no transitive functional dependencies and hence our table is in 3NF
In Table 3 Salutation ID is primary key and in Table 1 Salutation ID is foreign to primary key in Table 3

Now our little example is in a level that cannot further be decomposed to attain higher forms of normalization. In fact it is already in higher normalization forms. Separate efforts for moving in to next levels of normalization are normally needed in complex databases.



Summary

  • Database designing is critical to the successful implementation of a database management system that meets the data requirements of an enterprise system.
  • Normalization helps produce database systems that are cost effective, cost effective and have better security models.
  • Functional dependencies are a very important component of the normalization process
  • Most database systems are normalized up to the third normal form.
  • A primary uniquely identifies are record in a Table and cannot be null
  • A foreign key helps connect table and references a primary key



More information click on:


No comments:

Post a Comment