Back to: SQL Server Tutorial For Beginners and Professionals
Database Normalization in SQL Server with Examples
In this article, I am going to discuss Database Normalization in SQL Server with Examples. Understanding Database Normalization is a must for a database developer. So, here in this article, we will discuss if we are not following Database Normalization, then what problems we face and then we will discuss how to overcome such problems using Database Normalization. I am going to discuss everything with examples so that it will be easier for you to understand the concepts. As part of this article, we are going to discuss the following pointers.
- Understanding the First, Second, and Third normal forms.
- What are the different Database Design Problems developers face?
- Understanding Duplicate and Redundancy and how both are different.
- Understanding the Atomic and repeating group problem.
- What are partial dependency and Transitional dependency Design Issues?
- How to Design many to many relationships?
Here we are going to discuss what are the different design problems database developers face and how we can solve them using the first, second, and third normal forms in SQL Server with Examples.
The database is a centralized place to store the data and it should not accept duplicate, bad, and redundant data to store in it. So, that the end-user can trust the data i.e. the Data Integrity should be there. In order to achieve this, the first and most important thing is how you design your database? What kind of database design principles you are following?
Before going to understand the first, second, and third normal forms, let us first understand what are the basic design mistakes database developers normally does. Once you understand the design mistakes, then you can easily understand the first, second, and third normal forms.
Design Mistake 1: No Proper Primary and Unique Key
The first database design mistake the developers are doing is they don’t put the proper primary key and unique keys or candidate keys. In order to understand this, please have a look at the following customer table.
CREATE TABLE Customer( CustomerId INT IDENTITY (1, 1), Name VARCHAR(200), Code VARCHAR(200), PhoneNumber VARCHAR(200), SSN VARCHAR(200), Product VARCHAR(200) )
The customer Code and SSN (Social Security Number) value should be unique for a customer. It should now accept any duplicate values. But here, as you can see, we have not applied any key (primary or unique) on these two columns, so it accepts duplicate values it as shown in the following image.
Now, let us solve the above problem by adding a unique key on Code and SSN column. But before that, we need to truncate the table. So, please execute the following SQL Script.
TRUNCATE TABLE Customer; ALTER TABLE Customer ADD CONSTRAINT UK_Customer_Code UNIQUE (Code); ALTER TABLE Customer ADD CONSTRAINT UK_Customer_SSN UNIQUE (SSN);
Now, with the above design changes, it will not accept duplicate values in Code and SSN column and when you try to insert duplicate data, it will give you the following error by saying that you are violating the uniqueness of customer code.
Design Mistake 2: Multiple values into a single column
The second design mistake people do is, they are adding multiple values into a single column. For example, let say a customer buys multiple products, then what people are doing is, they are adding all products in a single column separated them either by comma or pipe symbol as shown below.
As you can see in the Product column we are adding three values. We need to understand that, it’s a column, not a whole. It should have an atomic value. The problem is that you can put duplicate data. In other to solve the above problem, what people are doing is, they are adding three columns to the table as shown below.
And then insert each product into the respective table as shown below.
This is not a good design approach. The problem here is redundant data. In our example, Product1, Product2, and Product3 are redundant columns. In the first record, there are three products and in the second record, there are 2 products but the Product3 column also exists and it takes Null value which is nothing but redundant value. Because of our bad database design, we came into redundant problems. This problem also technically termed repeating group problems.
Design Mistake 3: Repeating Group problems
Repeating group problems means we are creating columns that are exactly the same (Product1, Product2, and Product3). Why these three columns are existing, now one knows. Again, tomorrow, if you want to add the fourth product, then again you need to add one more column into the table.
In order to solve the above repeating group problem what we need to do is we need to create another table called Product i.e. to resolve this problem we need to split the table. So, what we are going to do is, are going to create two tables, one table is going to hold Customer data and the other table is going to hold product information.
Creating the Product table:
Here we are creating the Product table with some more columns. Why I am adding additional columns that I will discuss later. Please execute the below SQL Script to create the Product table. Please note, here we created a ProductId as primary key and ModelId as a unique key.
CREATE TABLE Product( [ProductId] [int] PRIMARY KEY, [ModelId] [int] UNIQUE, [ProductName] [nvarchar](50) NULL, [ProductCost] [money] NULL, [ModelName] [nvarchar](50) NULL, [ManufacturerName] [nvarchar](50) NULL );
Modifying the Customer table:
From the Customer table, we are going to remove the Product1, Product2, and Product3 columns. Then we will add ProductId and ModelId as foreign key columns which will reference the ProductId and ModelId column of the Product table. To keep things simple, first, we will delete the Customer table and then we will create the customer table with new columns. To do so, please execute the following SQL Script.
DROP TABLE Customer; CREATE TABLE [Customer]( [CustomerId] [int] PRIMARY KEY, [Name] [varchar](200) NULL, [Code] [varchar](200) NULL, [PhoneNumber] [varchar](200) NULL, [SSN] [varchar](200) NULL, [ProductId] INT FOREIGN KEY REFERENCES Product(ProductId), [ModelId] INT FOREIGN KEY REFERENCES Product(ModelId) )
With the above change now, you can insert data into the Product table and then you can insert data into the Customer table as shown below.
Product Table:
Customer Table:
Now you can insert the ProductId and ModelId values into the ProductId and ModelId column of the Customer table as shown below.
That’s fine. There is no redundancy data or column. But this design is not what we are expecting. One customer can buy multiple products. But putting the ProductId and ModelId column here means one customer can buy only one product. That is one to one relationship.
So, this design will not fit here. Here, we need to introduce an intermediate table that has reference to both Product (ProductId and ModelId) and Customer (CustomerId) table. That means we need to create a table that has many to many relationships between Customer and Product table i.e. one customer can buy multiple products and multiple products can be bought by multiple customers.
First, delete the ProductId and ModelId column from the Customer table. Once you delete those two columns, your Customer table should look as below.
Creating ProductCustomerMapping table:
Please execute the below script to create the ProductCustomerMapping table. This table maintains many to many relationships between the Customer and Product table. It has a reference to the CustomerId column of the Customer table as well as a reference to the ProductId and ModelId column of the Product table.
CREATE TABLE [ProductCustomerMapping]( [ProductCustomerId] INT PRIMARY KEY, [CustomerId] INT FOREIGN KEY REFERENCES Customer(CustomerId), [ModelId] INT FOREIGN KEY REFERENCES Product(ModelId), [ProductId] INT FOREIGN KEY REFERENCES Product(ProductId) );
Now, you can insert the data into the ProductCustomerMapping table as expected. For better understanding please have a look at the following image.
First Normal Form in Database Normalization in SQL Server with Examples:
- Design Problem 1: Duplicate Data due to no proper primary key and unique keys.
- Design Problem 2: One column containing multi-value data. It should atomic value. Atomic value means it should not be divided further.
- Design Problem 3: Repeating Groups or redundant columns.
When the above design problems are solved or you can say the above rules are satisfied, that means your database is in First Normal Form.
Design Problem 4: Non-Key columns are fully dependent on the primary key
The fourth design problem that lots of developers do is, they make non-key columns (columns without primary key) in the tables which are not dependent on the primary key column. In order to understand this better, please modify the Product table as shown below. Here, we are adding Country and City columns to the table.
Now modify the data of the Product table as shown below.
If you look at the Product table, the Product Name and Product cost columns are related to the ProductId which is the primary key. The model name field is dependent on the ModelId column. And Model has nothing to do with the Product. Along the same line, the non-key column Country and Area has a relation with the ProductId column.
This is a bad design because when we say a table, a table is a logical unit. If you are putting fields that are not related to the unit then you have problems. Tomorrow if you have to add or remove fields then it becomes very difficult to change the structure. So, we should move the non-key columns which are not related to the unit to separate tables. We need to do lots of changes. Let do one by one.
Step1: Creating Model table:
Please execute the below SQL Query which will create the Model table. The Model table will contain only the model-related information.
CREATE TABLE [Model]( [ModelId] [int] PRIMARY KEY, [ModelName] [nvarchar](50) NULL, [ManufacturerName] [nvarchar](50) NULL, [Country] [nvarchar](50) NULL, [City] [nvarchar](50) NULL );
Once you create the Model table, and then please fill the table with the following data.
Step2: Modifying the Product table.
From the Product table, delete all the columns except the ProductId, ProductName, and ProductCost column. Once you delete the columns, the Product table structure should looks as shown below.
Now the Product table will contain only the Product related information. The data in the Product table is shown below.
Note: We need to design the database in such a way that, all the non-key columns should fully dependent on the primary key column. If you are not following this rule means one table having the data of many entities.
Step3: Modifying the ProductCustomerMapping table.
To make the thing simple, just delete and create the ProductCustomerMapping table. The only change is that the ModelId column now references the ModelId column of the Model table.
DROP TABLE ProductCustomerMapping; CREATE TABLE [ProductCustomerMapping]( [ProductCustomerId] INT PRIMARY KEY, [CustomerId] INT FOREIGN KEY REFERENCES Customer(CustomerId), [ModelId] INT FOREIGN KEY REFERENCES Model(ModelId), [ProductId] INT FOREIGN KEY REFERENCES Product(ProductId) );
Once you modified the ProductCustomerMapping table then please fill the table with the following data.
Now, with the above database design, all the non-key columns are fully dependent on the primary key column.
Second Normal Form in Database Normalization in SQL Server with Examples:
Must satisfy the first normal form:
- Design Problem 1: Duplicate Data due to no proper primary key and unique keys.
- Design Problem 2: One column containing multi-value data. It should atomic value. Atomic value means it should not be divided further.
- Design Problem 3: Repeating Groups or redundant columns.
As well as the Design Problem 4: Non-Key columns are fully dependent on Primary key
When the above four design problems are solved or you can say when the database design satisfied the above four rules, it means your database is in Second Normal Form.
Design Problem 5: Transitive Dependencies
If you look at the Model table, then the City column value depends on the Country column value, not on the ModelId column. Putting both the values in the Model column is a bad design. So, what we need to do here is, we need to move these transitive dependencies to other tables.
Step1: Creating the Country table
Please execute the below SQL Script to create the Country table with two columns. Here, we marked the CountryId as the primary key.
CREATE TABLE [Country]( [CountryId] [int] Primary Key, [CountryName] [nvarchar](50) );
Fill the country with the following data.
Step2: Creating the City table
Please execute the below SQL Script to create the City table with three columns. Here, we marked CityId as the primary key and CountryId as the foreign key reference to the CountryId column of the Country table.
CREATE TABLE [City]( [CityId] [int] Primary Key, [CityName] [nvarchar](50), [CountryId] INT FOREIGN KEY REFERENCES Country(CountryId) );
Fill the City table with the following data.
Step3: Modifying the Model table structure
From the Model table, we need to delete the Country and City columns. Then we need to add CountryId column which will be a foreign key referencing the CountryId column of the Country table. In order to do so, please execute the below script.
ALTER TABLE Model DROP COLUMN Country; ALTER TABLE Model DROP COLUMN City; ALTER TABLE Model ADD CountryId INT; ALTER TABLE Model ADD FOREIGN KEY (CountryId) REFERENCES Country(CountryId);
With the above changes now, modify the data in the Model table as shown below.
Third Normal Form in Database Normalization in SQL Server with Examples:
The Third Normal Form says that there should not be any transitive data and it should follow the first and second normal forms. So, Normalization is all about splitting your table into multiple tables or units. In order to remember, the first, second, and third normal form, please have a look at the following diagram which shows a summary of what we discussed in this article.
In the next article, I am going to discuss Database De-normalization in detail. Here, in this article, I try to explain Database Normalization in SQL Server with one real-time example. I hope you enjoy this Database Normalization in SQL Server article. If you have any questions or queries about this Database Normalization in SQL Server with Examples article, then please feel free to ask me in the comment section.
Nothing (No other tutorial) is better then this tutorial.
this is really outstanding….
Its very good explanation about the topic. Very well explained.
5TH,6th,boyce code examples?
The Model table should add CityID rather than CountryID in the The last example , anyone agree with me?
I think you have not covered the cursor topic…
Hi
Very soon we are going to cover cursor as well as missing and new features of SQL Server.
cool thanks
best article .