Saturday 27 July 2013

Normalization in sql server

  Database normalization is the process of efficiently organizing data in a database. There are two reasons
of the normalization process:

1) Eliminating redundant data,for example, storing the same data in more than one tables.
2) Ensuring data dependencies make sense.

Both of these are worthy goals as they reduce the amount of space a database consumes and
ensure that data is logically stored. Normalization consists of a series of guidelines that
help guide you in creating a good database structure. Normalization guidelines are divided
into normal forms; think of form as the format or the way a database structure is laid out.
The aim of normal forms is to organize the database structure so that it complies with the
rules of first normal form, then second normal form, and finally third normal form.
It's your choice to take it further and go to fourth normal form, fifth normal form, and so on,
but generally speaking, third normal form is enough.

A) First Normal Form (1NF)
B) Second Normal Form (2NF)
C) Third Normal Form (3NF)

A) First Normal Form ::

First normal form (1NF) sets the very basic rules for an organized database:
1) Define the data items required, because they become the columns in a table.Place related data
items in a table.
2) Ensure that there are no repeating groups of data.
3) Ensure that there is a primary key.

a)First Rule of 1NF:

You must define the data items. This means looking at the data to be stored, organizing the data into columns,
defining what type of data each column contains, and finally putting related columns into their own table.
For example, you put all the columns relating to locations of meetings in the Location table, those relating
to members in the MemberDetails table, and so on.

b)Second Rule of 1NF:

The next step is ensuring that there are no repeating groups of data.

Consider we have following table:

CREATE TABLE CUSTOMERS( ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25), ORDERS VARCHAR(155) );

So if we populate this table for a single customer having multiple orders then it would be something as follows:

ID NAME AGE ADDRESS ORDERS 100 Sachin 36 Lower West Side Cannon XL-200 100 Sachin 36 Lower West Side
Battery XL-200 100 Sachin 36 Lower West Side Tripod Large But as per 1NF,

we need to ensure that there are no repeating groups of data. So let us break above table into to parts
and join them using a key as follows:

CUSTOMERS table:

CREATE TABLE CUSTOMERS( ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25),
PRIMARY KEY (ID) );

This table would have following record:

ID NAME AGE ADDRESS 100 Sachin 36

Lower West Side ORDERS table:

CREATE TABLE ORDERS( ID INT NOT NULL, CUSTOMER_ID INT NOT NULL, ORDERS VARCHAR(155),
PRIMARY KEY (ID) );

This table would have following records:

ID CUSTOMER_ID ORDERS 10 100 Cannon XL-200 11 100 Battery XL-200 12 100

Third Rule of 1NF:
The final rule of the first normal form .
create a primary key for each table which we have already created. Second Normal Form Second normal
form states that it should meet all the rules for 1NF and there must be no partial dependences of any
of the columns on the primary key:Consider a customer-order relation and you want to store customer ID,
customer name, order ID and order
detail,and date of purchage:

CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, ORDER_ID INT NOT NULL,
ORDER_DETAIL VARCHAR (20) NOT NULL, SALE_DATE DATETIME, PRIMARY KEY (CUST_ID, ORDER_ID) );

This table is in first normal form, in that it obeys all the rules of first normal form. In this table,
the primary key consists of CUST_ID and ORDER_ID. Combined they are unique assuming same
customer would hardly order same thing. However, the table is not in second normal form because
there are partial dependencies
of primary keys and columns. CUST_NAME is dependent on CUST_ID,
and there's no real link between a customer's name and what he purchaged.
Order detail and purchage date are also dependent on ORDER_ID, but they are not dependent on
CUST_ID,
because there's no link between a CUST_ID and an ORDER_DETAIL or their SALE_DATE. To make
this table comply
with second normal form, you need to separate the columns into three tables. First,

create a table to store the customer details as follows:

CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, PRIMARY KEY (CUST_ID) );

Next, create a table to store details of each order:

CREATE TABLE ORDERS( ORDER_ID INT NOT NULL, ORDER_DETAIL VARCHAR (20) NOT NULL, PRIMARY KEY (ORDER_ID) );

Finally, create a third table storing just CUST_ID and ORDER_ID to keep track of all the orders for a
customer:

CREATE TABLE CUSTMERORDERS( CUST_ID INT NOT NULL, ORDER_ID INT NOT NULL, SALE_DATE DATETIME, PRIMARY KEY
(CUST_ID, ORDER_ID) );

Third Normal Form A table is in third normal form when the following conditions are met:

It is in second normal form.
All nonprimary fields are dependent on the primary key. The dependency of nonprimary fields is
between the data.

For example in the below table, street name, city, and state are unbreakably bound to the zip code.

CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, DOB DATE, STREET VARCHAR(200),
CITY VARCHAR(100), STATE VARCHAR(100), ZIP VARCHAR(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );

The dependency between zip code and address is called a transitive dependency.
To comply with third normal form, all you need to do is move the Street, City, and State fields into
their own table, which you can call the Zip Code table:

CREATE TABLE ADDRESS( ZIP VARCHAR(12), STREET VARCHAR(200), CITY VARCHAR(100), STATE VARCHAR(100), PRIMARY KEY (ZIP) );

Next, alter the CUSTOMERS table as follows:

CREATE TABLE CUSTOMERS( CUST_ID INT NOT NULL, CUST_NAME VARCHAR (20) NOT NULL, DOB DATE, ZIP VARCHAR(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );

The advantages of removing transitive dependencies are mainly twofold. First,
the amount of data duplication is reduced and therefore your database becomes smaller.
The second advantage is data integrity. When duplicated data changes, there's a big risk of updating
only some of the data, especially if it's spread out in a number of different places in the database.

For example, If address and zip code data were stored in three or four different tables, then any
changes in zip codes would need to ripple out to every record in those three or four tables.


I hope You got something useful in this article. I would like to have feedback from my blog readers.
Your valuable feedback, question, or comments about this article are always welcome.


No comments:

Post a Comment

if you have any doubt any suggestions do comment