Database Normalization

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. 1. First Normal Form (1NF) 2. Second Normal Form (2NF) 3. Third Normal Form (3NF) First normal form (1NF) sets the very basic rules for an organized database: y Define the data items required, because they become the columns in a table. Place related data items in a table. y Ensure that there are no repeating groups of data. y Ensure that there is a primary key.

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.

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 100 100 100 NAME Sachin Sachin Sachin AGE 36 36 36 ADDRESS Lower West Side Lower West Side Lower West Side ORDERS Cannon XL-200 Battery XL-200 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 NAME VARCHAR (20) AGE INT ADDRESS CHAR (25), PRIMARY KEY (ID) );
ID NAME

NOT NULL, NOT NULL, NOT NULL,

This table would have following record: AGE ADDRESS

100 ORDERS table:

Sachin

36

Lower West Side

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 10 11 12 CUSTOMER_ID 100 100 100 ORDERS Cannon XL-200 Battery XL-200 Tripod Large

Third Rule of 1NF:

The final rule of the first normal form . create a primary key for each table which we have already created.

Database - Second Normal Form (2NF)

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 CUST_NAME VARCHAR (20) PRIMARY KEY (CUST_ID) ); CREATE TABLE ORDERS( ORDER_ID INT ORDER_DETAIL VARCHAR (20) PRIMARY KEY (ORDER_ID) );

NOT NULL, NOT NULL,

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

NOT NULL, NOT NULL,

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) );

Database - Third Normal Form (3NF)

A table is in third normal form when the following conditions are met: y It is in second normal form. y 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 CUST_NAME VARCHAR (20) DOB DATE, STREET VARCHAR(200), CITY VARCHAR(100), STATE VARCHAR(100), ZIP VARCHAR9(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );

NOT NULL, NOT NULL,

The dependency between 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 VARCHAR9(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 CUST_NAME VARCHAR (20) DOB DATE, ZIP VARCHAR9(12), EMAIL_ID VARCHAR(256), PRIMARY KEY (CUST_ID) );

NOT NULL, NOT NULL,

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.