Assignment Normalization
Customer
Order
CustomerID
OrderID
CustomerName
CustomerID
Address
OrderDate
Phone
TotalAmount
OrderID
ShippingAddress
OrderDate
ShippingStatus
ProductID
ProductName
ProductPrice
Customer Table:
ID
Customer CustomerNa Addre Phon OrderI OrderDa ProductI ProductNa ProductPri
me
ss
e
D
te
D
me
ce
1
1
2
John Smith
123
Maple 5551001
St,
1234
City A
10/1/202
2001
4
Laptop
John Smith
123
Maple 5551001
St,
1234
City A
10/1/202
2002
4
Headphone
150
s
Jane Doe
456
Oak
5551002
Ave, 5678
City B
10/2/202
2003
4
Coffee
Maker
1200
80
1
John Smith
123
Maple 5551003
St,
1234
City A
10/3/202
2004
4
Blender
60
3
789
Pine 555Alice Brown
1004
Rd,
8765
City C
10/4/202
2001
4
Laptop
1200
2
456
Oak
5551005
Ave, 5678
City B
10/5/202
2004
4
Blender
60
Jane Doe
Order Table:
OrderID CustomerID OrderDate TotalAmount ShippingAddress
ShippingStatus
1001
1
10/1/2024 1350
123 Maple St, City A Shipped
1002
2
10/2/2024 80
456 Oak Ave, City B Pending
1003
1
10/3/2024 60
123 Maple St, City A Delivered
1004
3
10/4/2024 1200
789 Pine Rd, City C Shipped
1005
2
10/5/2024 60
456 Oak Ave, City B Shipped
First normal form (1NF):
For the first normal form, we must make sure each cell is atomic, each row is unique, and
there are no repeating groups. In the above Customer Table, columns such as CustomerID,
CustomerName, Address, and Phone describe a customer, while OrderID, OrderDate, ProductID,
ProductName, and ProductPrice relate to orders and products. This structure is severely flawed
especially for retail store, as a customer can have multiple orders with multiple products which
may create duplicate rows, thus creating data redundancy and violating atomicity by storing
multiple values in one field. Moreover, the OrderDate column exists in both Customer and Order
Tables, which creates repeating groups. To resolve this, we apply 1NF: We separate Customer
table into 2 tables: Customer and ProductOrder. The customer table will now include
CustomerID (primary key), CustomerName, Address, and Phone, and the ProductOrder table
will include OrderID, ProductID, ProductName, and ProductPrice with OrderID and ProductID
as composite key. This splitting isolates customers’ data and customers’ orders separately. The
Order table is already in 1NF with OrderID as the primary key and no repeating groups, so we
can leave it as it is.
Customer
ProductOrder
Order
CustomerID
OrderID
OrderID (PK)
(PK)
(PK/FK)
CustomerID (FK)
CustomerName
ProductID (PK)
OrderDate
Address
ProductName
TotalAmount
Phone
ProductPrice
ShippingAddress
ShippingStatus
Fig: 1NF (PK=Primary Key, FK = Foreign Key)
Customer Table:
CustomerID (PK) CustomerName Address
Phone
1
John Smith
123 Maple St, City A 555-1234
2
Jane Doe
456 Oak Ave, City B 555-5678
3
Alice Brown
789 Pine Rd, City C 555-8765
ProductOrder Table:
OrderID (PK/FK) ProductID (PK) ProductName ProductPrice
1001
2001
Laptop
1200
1001
2002
Headphones
150
1002
2003
Coffee Maker 80
Order Table:
OrderID
CustomerID
OrderDate TotalAmount ShippingAddress
(PK)
(FK)
1001
1
ShippingStatus
123 Maple St, City
10/1/2024 1350
Shipped
A
OrderID
CustomerID
OrderDate TotalAmount ShippingAddress
(PK)
(FK)
1002
2
ShippingStatus
456 Oak Ave, City
10/2/2024 80
Pending
B
123 Maple St, City
1003
1
10/3/2024 60
Delivered
A
Second Normal Form (2NF):
2NF requires all tables to be in 1NF, and all non-key columns must depend fully on the
primary key. Following this criterion, we can observe that the customer table from 1NF appears
to be in 2NF already, as CustomerName, Address, and Phone depend entirely on CustomerID
(primary key). However, the ProductOrder table has two columns, OrderID and ProductID,
which are composite keys, but ProductName and ProductPrice depend only on ProductID, not on
OrderID, which creates a partial dependency. To resolve this partial dependency, we split the
ProductOrder table into two tables: a Product Table with ProductID (primary key),
ProductName, and ProductPrice, where all columns depend on ProductID; and a ProductOrder
Table with OrderID and ProductID (composite key). Finally, the Order table also appears to be in
2NF, as OrderDate, TotalAmount, ShippingAddress, and ShippingStatus have full dependency on
OrderID (the primary key), whereas CustomerID is a foreign key.
Customer
Product
Order
ProductOrder
ProductID (PK)
OrderID (PK)
OrderID
ProductName
CustomerID (FK)
(PK/FK)
ProductPrice
OrderDate
ProductID
Address
TotalAmount
(PK/FK)
Phone
ShippingAddress
CustomerID
(PK)
CustomerName
ShippingStatus
Fig: 2NF
Customer Table:
CustomerID (PK) CustomerName Address
Phone
1
John Smith
123 Maple St, City A 555-1234
2
Jane Doe
456 Oak Ave, City B 555-5678
3
Alice Brown
789 Pine Rd, City C 555-8765
Product Table:
ProductID (PK) ProductName ProductPrice
2001
Laptop
1200
2002
Headphones
150
ProductID (PK) ProductName ProductPrice
2003
Coffee Maker 80
ProductOrder Table:
OrderID (PK/FK) ProductID (PK/FK)
1001
2001
1001
2002
1002
2003
Order Table:
OrderID
CustomerID
(PK)
(FK)
1001
1
OrderDate TotalAmount ShippingAddress
ShippingStatus
123 Maple St, City
10/1/2024 1350
Shipped
A
456 Oak Ave, City
1002
2
10/2/2024 80
Pending
B
OrderID
CustomerID
OrderDate TotalAmount ShippingAddress
(PK)
(FK)
1003
1
ShippingStatus
123 Maple St, City
10/3/2024 60
Delivered
A
Third Normal Form (3NF):
The rule of 3NF states that all tables must be in 2NF, the primary key must define all
other non-key columns, and the non-key columns must not depend on any column other than the
primary key column, also known as transitive dependency. The customer table appears to be in
3NF, as all non-key columns such as CustomerName, Address, and Phone depend solely on the
CustomerID (primary key) column. Similarly, for the product table, all the non-key columns,
such as ProductName and ProductPrice, have full dependency on ProductID (primary key). The
Order Table also appears to be in 3NF with OrderID as the primary key, and other non-key
column such as CustomerID (foreign key), OrderDate, TotalAmount, ShippingAddress, and
ShippingStatus fully dependent on it. However, if we consider the shipping address to be orderspecific only, meaning it should be dependent on the OrderID and not the CustomerID, otherwise
we would have a transitive dependency, since the Customer table also has an address column.
Lastly, the ProductOrder table has two columns, which are composite keys, and since the
ProductOrder table has no other columns, the possibility of transitive dependency can be ruled
out. Thus, all tables satisfy 3NF.
Customer
Product
Order
ProductOrder
CustomerID
ProductID (PK)
OrderID (PK)
OrderID
ProductName
CustomerID (FK)
(PK/FK)
ProductPrice
OrderDate
ProductID
Address
TotalAmount
(PK/FK)
Phone
ShippingAddress
(PK)
CustomerName
ShippingStatus
Fig: 3NF
Customer Table:
CustomerID (PK) CustomerName Address
Phone
1
John Smith
123 Maple St, City A 555-1234
2
Jane Doe
456 Oak Ave, City B 555-5678
3
Alice Brown
789 Pine Rd, City C 555-8765
Product Table:
ProductID (PK) ProductName ProductPrice
2001
Laptop
1200
2002
Headphones
150
ProductID (PK) ProductName ProductPrice
2003
Coffee Maker 80
ProductOrder Table:
OrderID (PK/FK) ProductID (PK/FK)
1001
2001
1001
2002
1002
2003
Order Table:
OrderID
CustomerID
(PK)
(FK)
OrderDate TotalAmount ShippingAddress
ShippingStatus
123 Maple St, City
1001
1
10/1/2024 1350
Shipped
A
456 Oak Ave, City
1002
2
10/2/2024 80
Pending
B
OrderID
CustomerID
OrderDate TotalAmount ShippingAddress
(PK)
(FK)
1003
1
ShippingStatus
123 Maple St, City
10/3/2024 60
Delivered
A
In conclusion, by following the above three normalization steps, we have transformed the
retail company’s legacy database into an optimal system tailored to its needs. Previously, the
database schemas for Customer and Order had issues with data redundancy, data integrity,
relationships, and partial and transitive dependencies. After going through normalization
processes, it has successfully resolved those issues. The two original tables are divided into four
tables: Customer, Order, Product, and ProductOrder, ensuring data integrity and eliminating data
duplication. This change enables the legacy system to run faster with more efficient queries runs
with less redundant data. Moreover, isolating customers’ information, their orders’ information
and product details enforces better security. Thus, the system has transformed into a modern
database system that boasts faster runtime and robust security.
0
