The value of one attribute in a table is determined entirely by the value of another attribute.
For example, the birthday of a Customer can be determined by the primary key of the Customer, in which record the birthday belongs. Here an Customer’s birthday depends on the Customer’s primary key.
Customer birthday (depends on) -> Customer ID
The notation X -> Y means if and only if each X value is associated with at most one Y value.
We can find the birthday of a Customer, thru the ID of the Customer. Using the ID, for a one to one relationship (that is one Customer has ONLY one birthday), we can find the only birthday of a Customer. Where as using the birthday, we might find ID’s of several Customers, since same birthday might belong to multiple persons.
Understanding First Three Normal Forms
First normal form sample:
1. Create atomic values, i.e. which can’t be broken down more.
Address: Location + City + State + Country
Should be formed with separate fields:
Address table: Address ID, Location, City, State, and Country.
2. Remove repetitive column groups.
Customer table: Customer ID, Customer Name, Address ID, Address ID
Should be formed as:
Customer table: Customer ID, Customer Name
Customer Address table: Customer ID, Address ID
Second normal form sample:
Remove partial dependency.
Order Item table: Order ID, Inventory Item ID, Inventory Item Sell Price, Inventory Item Sell Quantity
Should be formed as:
Order Item table: Order ID, Inventory Item ID, Inventory Item Sell Quantity
Inventory Item table: Inventory Item ID, Inventory Item Sell Price
Third normal form sample:
Move the non-keys to a separate table, which don’t depend on keys (or depends on non-key).
Sales Order table: Sales Order No, Date, Customer No, Customer Name
Should be formed as:
Customer table: Customer No, Customer Name
Sales Order table: Sales Order No, Date, Customer No
Technorati Tags: database,application,design
What is Normalization?
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 links them using relationships.
In this tutorial, you will learn-
The inventor of the relational model Edgar Codd proposed the theory of normalization with the introduction of First Normal 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 Data Normalization in SQL is still being developed further. For example, there are discussions even on 6th Normal Form. However, in most practical applications, normalization achieves its best in 3rd Normal Form. The evolution of Normalization theories is illustrated below-
Database Normalization Examples -
Assume a video library maintains a database of movies rented out. Without any normalization, all information is stored in one table as shown below.
Here you see Movies Rented column has multiple values.
Database Normal Forms
Now let's move into 1st Normal Forms
1NF (First Normal Form) Rules
- Each table cell should contain a single value.
- Each record needs to be unique.
The above table in 1NF-
Before we proceed let's understand a few things --
What is a KEY?
A KEY is a value used to identify a record in a table uniquely. A KEY could be a single column or combination of multiple columns
Note: Columns in a table that are NOT used to identify a record uniquely are called non-key columns.
What is a Primary Key?
A primary is a single column value used to identify a database record uniquely.
It has following attributes
What is 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 in different places.
Hence, we require both Full Name and Address to identify a record uniquely. That is a composite key.
Let's move into second normal form 2NF
2NF (Second Normal Form) 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.
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
Database - Foreign Key
In Table 2, Membership_ID is the Foreign Key
| Foreign Key references the primary key of another Table! It helps connect your Tables |
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.
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 are 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.
Let's move into 3NF
3NF (Third Normal Form) Rules
- Rule 1- Be in 2NF
- Rule 2- Has no transitive functional dependencies
To move our 2NF table into 3NF, we again need to again divide our table.
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 at 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 into next levels of normalizing data are normally needed in complex databases. However, we will be discussing next levels of normalizations in brief in the following.
Boyce-Codd Normal Form (BCNF)
Even when a database is in 3rd Normal Form, still there would be anomalies resulted if it has more than one Candidate Key.
Sometimes is BCNF is also referred as 3.5 Normal Form.
4NF (Fourth Normal Form) Rules
If no database table instance contains two or more, independent and multivalued data describing the relevant entity, then it is in 4th Normal Form.
5NF (Fifth Normal Form) Rules
A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed into any number of smaller tables without loss of data.
6NF (Sixth Normal Form) Proposed
6th Normal Form is not standardized, yet however, it is being discussed by database experts for some time. Hopefully, we would have a clear & standardized definition for 6th Normal Form in the near future...
That's all to Normalization!!!
- 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 and have better security models.
- Functional dependencies are a very important component of the normalize data process
- Most database systems are normalized database up to the third normal forms.
- A primary uniquely identifies are record in a Table and cannot be null
- A foreign key helps connect table and references a primary key