E-Commerce Platform

Abstract:
This project aims to develop a robust E-commerce platform utilizing Python for GUI
development with Tkinter and SQLite for database management. The platform will provide
users with a seamless shopping experience while offering administrators efficient tools for
managing products, orders, and customer information. The system will feature a user-friendly
interface built with Tkinter, enabling customers to browse products, add items to their cart, and
complete purchases with ease. SQLite will be employed as the backend database system to
store and manage various aspects of the platform, including product listings, user accounts,
order details, and transaction records. Key functionalities will include user authentication,
product management, shopping cart functionality, checkout process, order management, and
reporting. Security measures will be implemented to safeguard sensitive data, and the system
will be designed for scalability and performance. Through the integration of Python, SQLite,
and Tkinter, this project aims to deliver a comprehensive E-commerce solution that meets the
needs of both customers and administrators while showcasing the capabilities of these
technologies in building modern web applications.
Problem Identification:
Despite the widespread popularity of online shopping, many existing E-commerce platforms
face various challenges that hinder user satisfaction and hinder business efficiency. Some of
the common problems include:
1. Poor User Experience: Many E-commerce platforms have complex user interfaces,
making it difficult for users to navigate through product listings, manage their shopping
carts, and complete transactions smoothly.
2. Inefficient Database Management: Traditional E-commerce platforms often rely on
bulky and slow database systems, leading to sluggish performance, data
inconsistencies, and difficulties in managing large volumes of transactions and
customer data.
3. Security Concerns: Security breaches, data leaks, and unauthorized access to sensitive
information are significant concerns for both users and businesses. Weak authentication
mechanisms and inadequate data encryption can expose users' personal and financial
data to potential threats.
4. Limited Scalability: Some E-commerce platforms struggle to handle increasing traffic
and transaction volumes, resulting in system crashes, slow response times, and
downtime during peak periods such as sales events or holidays.
5. Lack of Customization: Many E-commerce platforms offer limited customization
options for users and administrators, making it challenging to tailor the platform to
specific business needs, branding requirements, or user preferences.
6. High Development Costs: Developing and maintaining a custom E-commerce platform
can be costly and time-consuming, especially for small businesses or startups with
limited resources. High development costs may deter businesses from investing in a
robust online storefront.
Addressing these challenges requires the development of a modern and efficient E-commerce
platform that prioritizes user experience, data security, scalability, customization, and
affordability. By leveraging Python, SQLite, and Tkinter, this project aims to tackle these
problems and deliver a comprehensive solution that meets the needs of both users and
businesses in the digital marketplace.
INTRODUCTION:
An eCommerce Management System is a comprehensive software solution designed to
streamline the operations and processes involved in running an online store. It serves as the
backbone for managing various aspects of eCommerce businesses, including inventory
management, order processing, customer relationship management, marketing, and analytics.
Here's a breakdown of the key components and functionalities typically found in an
eCommerce Management System:
1. Product Management: This feature allows store owners to add, edit, categorize, and
organize products effectively. It includes features such as product descriptions, images,
pricing, and inventory levels.
2. Order Processing: The system automates the order fulfillment process from the point
of purchase to delivery, including order confirmation, payment processing, shipping,
and tracking.
3. Provide personalized shopping experiences through features like customer accounts,
wish lists, targeted promotions, and seamless access to product listings for convenient
purchasing.
4. Scalability and Customization: They are designed to scale with the growth of the
business and offer customization options to tailor the platform according to specific
business requirements.
ER Diagram:

1. Wishlist:
• Description: The Wishlist entity represents a collection of items that a user
desires to acquire or keep track of within an e-commerce website. Users often
create wishlists to bookmark products they are interested in purchasing at a later
time or to share with others as gift suggestions.
• Attributes:
o wishlist_id: A unique identifier for each wishlist, serving as the primary
key for the Wishlist entity. It distinguishes one wishlist from another in
the database.

2. Users:
• Description: The Users entity represents individuals who have registered on the
e-commerce website to avail its services, such as purchasing products, creating
wishlists, or leaving reviews. Each user is identified uniquely within the system
and possesses various attributes that help manage their account and facilitate
communication.
• Attributes:
o Email: The email address associated with the user's account, serving as
a unique identifier for login purposes.
o User_Id: A unique identifier assigned to each user, functioning as the
primary key for the Users entity. It distinguishes one user from another
in the database.
o Password: The encrypted string used for user authentication and access
control.
o Phone: A multi-valued attribute representing the contact phone
number(s) associated with the user. Users may have more than one
phone number stored in their profile.
o Name: Name of the user.
o Address: A composite attribute comprising several sub-attributes that
collectively represent the user's physical location. It includes:
▪ H.no (House Number): The building or house number of the
user's address.
▪ Street: The street name where the user resides.
 ▪ City: The city or locality where the user's address is located.
▪ State: The state or province where the user resides.
▪ Pincode: The postal code or ZIP code associated with the user's
area.
▪ Landmark: A notable point of reference near the user's address,
aiding in locating their residence.

3. Payments:
 • Description: The Payments entity records the transactions made by users to
purchase products or services on the e-commerce website. It tracks the details
of each payment, including the payment method used and the date of the
transaction.
• Attributes:
o Payment_id: A unique identifier assigned to each payment transaction,
serving as the primary key for the Payments entity. It distinguishes one
payment from another in the database.
o Date: The date on which the payment transaction occurred, providing a
chronological record of when the transaction took place.
o Method: The method used for the payment transaction, indicating how
the user chose to make the payment (e.g., credit card, debit card, PayPal,
bank transfer, etc.).

4. Orders:

• Description: The Orders entity represents the purchases made by users on the e-
commerce website. It contains information about each order placed, including
the total amount, status, and date of the order.
• Attributes:
o Total Amount: The total cost of the order, including the prices of all
items purchased, any applicable taxes, and shipping charges.
o Order_id: A unique identifier assigned to each order, serving as the
primary key for the Orders entity. It distinguishes one order from another
in the database.
o Status: The current status of the order, indicating whether it is pending,
processed, shipped, delivered, or canceled.
o Date: The date and time when the order was placed, providing a
timestamp for when the transaction occurred.
5. Order_Items:

• Description: The Order_items entity represents the individual items included in

each order made by users on the e-commerce website. It provides a detailed
breakdown of the products purchased, including the quantity of each item.
• Attributes:
o Order_items_id: A unique identifier assigned to each order item, serving
as the primary key for the Order_items entity. It distinguishes one order
item from another in the database.
o Quantity: The number of units of the particular item included in the
order. It indicates how many of the item were purchased in that specific
order.

6. Products:

• Description: The Products entity represents the various items available for
purchase on the e-commerce website. It includes details such as the product's
price, description, and name.
• Attributes:
 o Product_id: A unique identifier assigned to each product, serving as the
primary key for the Products entity. It distinguishes one product from
another in the database.
o Price: The cost of the product, indicating the amount users need to pay
to purchase it.
o Description: A brief description or overview of the product, providing
users with information about its features, specifications, and uses.
o Name: The name or title of the product, serving as a concise identifier
for users to recognize and refer to the item.

7. Reviews:

• Description: The Reviews entity captures user feedback and evaluations of

products purchased on the e-commerce website. It includes details such as the
comment provided by the user, the review's unique identifier, and the rating
given to the product.
• Attributes:
o Comment: The textual feedback or commentary provided by the user
regarding their experience with the product. It may include opinions,
suggestions, or criticisms.
o Review_id: A unique identifier assigned to each review, serving as the
primary key for the Reviews entity. It distinguishes one review from
another in the database.
o Rating: The numerical score or rating given by the user to indicate their
satisfaction level with the product. It typically ranges from 1 to 5, with
1 being the lowest and 5 being the highest rating.
8. Categories:

• Description: The Categories entity organizes products into distinct groups or

classifications based on shared characteristics or attributes. It serves as a
hierarchical structure that helps users navigate and discover products more
efficiently.
• Attributes:
o Category_id: A unique identifier assigned to each category, serving as
the primary key for the Categories entity. It distinguishes one category
from another in the database.
o Name: The name or title of the category, representing its content or
theme. It provides a descriptive label for users to understand the type of
products grouped within the category.

9. Discount:

• Description: The Discount entity represents promotional offers or price

reductions applicable to products on the e-commerce website. It tracks various
discounts available to users during their shopping experience.
• Attributes:
o Discount_id: A unique identifier assigned to each discount, serving as
the primary key for the Discount entity. It distinguishes one discount
from another in the database.
o Offer: Describes the specific discount or promotional offer provided to
users, such as percentage off, buy-one-get-one, or fixed amount
reduction.
Complete ER Diagram:

Relationships:
1. Users has Wishlist:
• One-to-Many relationship from Users to Wishlist (One user can have multiple
wishlists)
• Total Participation of Wishlist (Every Wishlist must be associated with a user)
• Partial Participation of Users(A user may or maynot have a wishlist)
2. Products added to Wishlist:
• Many-to-Many relationship between Products and Wishlist (A product can be
added to multiple wishlists, and a wishlist can contain multiple products)
• Partial Participation of Products(Every product may not be present in a wishlist)
• Partial Participation of Wishlist (A wishlist can be empty)
3. Payments belongs to Orders:
• One-to-One relationship from Payments to Orders (One payment can be
associated with one order, and an order can have only one payment)
• Total Participation of Payments( Every Payment must belong to an order)
• Partial Participation of Orders(An order may or maynot have associated
payments)
4. Users place Orders:
• One-to-Many relationship from Users to Orders (One user can place multiple
orders)
• Total Participation of Orders(Every order must be associated with an user)
• Partial Participation of Users(A user may or maynot place an order)
5. Orders contain Order_items:
• One-to-Many relationship from Orders to Order_items (One order can contain
multiple order items)
• Total Participation of Orders(Every order must contain atleast one order_item)
• Total Participation of Order_Items(Each order_item must be associated with a
order)
6. Users write Reviews:
• One-to-Many relationship from Users to Reviews (One user can write multiple
reviews)
• Total Participation of Reviews(If a review exists then it is associated by a user)
• Partial Participation of Users(A user may or maynot write a review)
7. Products have Reviews:
• One-to-Many relationship from Products to Reviews (One product can have
multiple reviews)
• Total Participation of Reviews(A review must be associated with a product)
• Partial Participation of Products( A product may or may not have a review)
8. Order_items contain Products:
• One-to-One relationship from Order_items to Products (Each order item
corresponds to one product)
• Total Participation of Order_Items(Every order_items must be associated with
a product)
• Partial Participation of Products(Not every product needs to be associated with
order_items)
9. Products belong to Categories:
• Many-to-One relationship from Products to Categories (Multiple products can
belong to the same category)
• Total Participation of Products(Every product must belong to a category)
• Total Participation of Categories(Every category must contain atleast one
product, if not then the category won’t exist on the store)
10. Discount on Categories:
• One-to-Many relationship from Discount to Categories (One discount can apply
to multiple categories, but a category can have only one discount)
• Total Participation of Discount(Every discount must be associated with a
category)
• Partial Participation of Categories(A category may or maynot have a discount
associated with it)
Conversion of ER diagram to Relational Model

1. Entity: Users
Since “Users” entity is a strong entity, we create the relational table with all the normal
attributes and we include the components of the composite attribute.

Table: Users
Also, since Phone is a multivalued attribute, we create a separate table for phone with
attributes phone and primary key(user_id) of the users entity.
User_Id Phone
1 7742198188
2 7854589545
3 5484589545
4 9458745845
5 9654215425
6 9823456153
7 9751482536
8 9564875123
9 8452146256
10 7214589456
Table: Phone
2. Entity: Reviews
Since “Reviews” entity is a strong entity, we include all the normal attributes in the
relational table.
Also, it has a relation of many to one with users, so we include the primary key of users
entity in reviews table but with the attribute name as the name of relation i.e writes.
Reviews entity is also related with products entity with many to one relation, so we
include the primary key of products entity in the reviews table but with the attribute
name as the name of the relation i.e has.
Review_Id Comment Rating Writes Has
 R1 This product is amazing, 5 3 P1
exceeded my expectations!
R2 Poor quality, broke within a 2 2 P1
week.
R3 Works great, highly 4 3 P4
recommended.
R4 Not as advertised, disappointed. 2 4 P5
R5 Absolutely love it, best purchase 5 3 P6
ever!
R6 Average product, does the job. 3 2 P7
R7 Great value for the price, very 4 5 P8
satisfied.
R8 Average quality, expected better. 3 7 P1
R9 Terrible experience, would not 1 8 P4
buy again.
R10 Exactly what I needed, perfect! 5 10 P5
Table: Reviews

3. Entity: Wishlist
Wishlist is a week entity so we include the primary key of users as a foreign key in
wishlist table. Now, since it is one to many relation between users and wishlist therefore
we include the primary key of users with the attribute name as the name of relation i.e
has
Wishlist_Id Has
W1 2
W2 3
W3 2
W4 4
W5 5
W6 6
W7 9
W8 9
W9 3
W10 5
Table: Wishlist
Also, wishlist and products are related to each other via many to many relation, so a
separate table for the relation will be created with primary keys of both the entities
Wishlist_Id Product_Id
W1 P1
W1 P2
W1 P5
W1 P6
W2 P4
W2 P5
W4 P3
W4 P8
 W5 P6
W5 P9
W6 P7
W6 P4
W7 P8
W7 P10
W8 P4
W9 P5
W10 P2
Table: AddedTo
4. Entity: Orders
Since it is a strong entity, we include all the attributes of orders entity in the orders table.
Also it has a relation of many to one with users, so we include the primary key of users
table in the orders table but with the attribute name as the name of the relation i.e. place

Order_Id Status Place Total_Amount Date

O1 Shipped 2 64260 2024-04-10
O2 Pending 2 2998 2024-04-12
O3 Processing 3 250 2024-04-11
O4 Out For 4 110240 2024-04-20
Delivery
O5 Delivered 4 7495 2024-04-28
O6 Cancelled 4 35998 2024-05-01
O7 Returned 5 143970 2024-05-04
O8 Shipped 8 2998 2024-05-08
O9 Shipped 10 1368 2024-05-18
O10 Delivered 2 2400 2024-05-24
Table: Orders
5. Entity: Payments
Payments is also a strong entity, therefore we include all the attributes of this entity in
its relational table.
It has a one to one relation with orders entity, and also it is the total participant in the
relation, so we include the primary key of the orders entity in the payments table.
Payment_Id Order_Id Method Date
PAY1 O1 Credit Card 2024-04-13
PAY2 O2 Debit Card 2024-04-10
PAY3 O3 Cash 2024-04-07
PAY4 O4 Credit Card 2024-04-03
PAY5 O5 Debit Card 2024-04-01
PAY6 O6 Cash 2024-03-13
PAY7 O7 Cash 2024-03-12
PAY8 O8 Credit Card 2024-03-10
PAY9 O9 Credit Card 2024-03-09
PAY10 O10 Credit Card 2024-03-02
 Table: Payments
6. Entity: Products
Since, it is a strong entity we include all the attributes in the products table.
Also it has a many to one relation with categories entity, so we include the primary key
of the categories table in the products table but with the name of the attribute as the
name of the relation i.e belongs_to
Product_Id Name Description Price Belongs_To
P1 Vivo T2X 5G Fastest Selling 5G Phone 17999 C2
P2 HP 15s Intel Thin and Light Laptop 56260 C3
i3
P3 Lenovo Four sided narrow bezel and a 47990 C3
Ideapad Slim screen-to-body ratio of upto 88%
5
P4 Woxen Shirt Men, Regular Fit 2000 C1
XL
P5 Wrangler T- Men, Solid, Polo Neck 1499 C1
Shirt
P6 Bharat Austin Fabric, Manual Recliner 28000 C5
Lifestyle
Recliner
P7 Life’s English, Paperback, Das Gaur Gopal 250 C9
Amazing
Secrets Book
P8 Samsung S24 Supercharged with AI features and 110240 C2
Ultra powerful hardware
P9 Attitude is English, Paperback, Keller Jeff 225 C9
Everything
Book
P10 AutoLift Capacity upto 2000kg 1499 C10
2Ton Scissor
Jack
Table: Products
7. Entity: Categories
Categories is also a strong entity, so we include all the attributes of this entity in the
relational table.
Since, it has a many to one relation with with entity discount, we include the primary
key of discount in the relational table of categories but with the attribute name as the
name of the relation i.e has

Category_Id Name Has

C1 Fashion D4
C2 Mobiles D2
C3 Electronics D1
C4 Grocery D3
 C5 Home and D7
Furniture
C6 Health Care D6
C7 Sports and D5
Fitness
C9 Books D10
C10 Auto D9
Accessories
Table: Categories
8. Entity: Order_Items
It is a week entity, so we include the primary key of the products table as a foreign key
in the order_items table.
Also, since it has a one-to-one relation with the products entity, and it is a total
participant, so we include the primary key of product entity as a foreign key in the
order_items table.
It also has a many to one relation with the orders table, so we include the primary key
of the orders table in the order_items table but with the attribute name as the name of
the relation, i.e contains
Order_Item_Id Contains Product_Id Quantity
OI1 O1 P2 1
OI2 O1 P4 4
OI3 O2 P5 2
OI4 O3 P7 1
OI5 O4 P8 1
OI6 O5 P10 5
OI7 O6 P1 2
OI9 O7 P3 3
OI10 O8 P5 2
Table: Order_Items
9. Entity: Discount
Since it is a strong entity, we include all the attributes of discount entity in its relational
table.
Discount_Id Offer
D1 33
D2 20
D3 5
D4 50
D5 10
D6 80
D7 90
D9 44
D10 55
Table: Discount
SQL Queries

SQL Constraints:
1. Primary Key:
CREATE TABLE Users (
User_Id INT PRIMARY KEY,
Username VARCHAR(50),
Email VARCHAR(100),
Date_of_Birth DATE,
);
By declaring User_Id as the primary key, you ensure that each user in the Users table can be
uniquely identified by their User_Id. This helps maintain data integrity and enables efficient
data retrieval and manipulation operations.

2. Unique:
CREATE TABLE Users (
User_Id INT PRIMARY KEY,
Username VARCHAR(50) UNIQUE,
Email VARCHAR(100),
Date_of_Birth DATE,
);

By adding a unique constraint to the Username column, you ensure that each username in the
Users table must be unique. This constraint helps maintain data integrity by preventing
duplicate usernames from being entered into the table. It also allows for efficient querying of
usernames, as the database management system (DBMS) automatically creates a unique index
on the column to enforce uniqueness.

3. Not Null:
CREATE TABLE Users (
User_Id INT PRIMARY KEY,
Username VARCHAR(50) UNIQUE,
Email VARCHAR(100) NOT NULL,
Date_of_Birth DATE,
);

By adding the NOT NULL constraint to the Email column, you ensure that each user in the
Users table must have a valid email address associated with their account. This constraint helps
maintain data integrity by preventing the insertion of incomplete or invalid data into the table.
Additionally, it enables efficient querying and retrieval of user data, as NULL values do not
need to be handled specially in database queries.
 4. Foreign Key:
CREATE TABLE Categories (
Category_Id SERIAL PRIMARY KEY,
Name VARCHAR(50) NOT NULL,
Has INT,
FOREIGN KEY (Has) REFERENCES Discount(Discount_Id)
);
By adding this foreign key constraint, you establish a relationship between the Categories table
and the Discount table. Specifically, it ensures referential integrity by enforcing that every
value in the Has column of the Categories table must correspond to a valid Discount_Id value
in the Discount table. This constraint helps maintain data consistency and prevents orphaned
records in the database.

5. Default:
CREATE TABLE Orders (
Order_Id PRIMARY KEY,
Status VARCHAR(20) DEFAULT 'Pending',
Place INT NOT NULL,
Total_Amount DECIMAL(10, 2),
Date DATE,
FOREIGN KEY (Place) REFERENCES Users(User_Id)
);
By adding a default constraint to the Status column, you ensure that every order in the Orders
table will have a status value, even if one is not explicitly provided during insertion. This helps
maintain data consistency and prevents NULL values from being inserted into the column.
Additionally, it simplifies data entry by providing a default value that can be overridden if
necessary.

6. Check:
CREATE TABLE Discount (
Discount_Id PRIMARY KEY,
Offer INT CHECK (Offer >= 0 AND Offer <= 100)
);
By adding a check constraint to the Offer column, you enforce data integrity by ensuring that
only valid discount offer values are allowed in the Discount table. This prevents the insertion
of invalid or out-of-range values, such as negative numbers or values exceeding 100, into the
column. Check constraints help maintain the consistency and correctness of data within the
database.
Set Operations:
1. Union:
This operation combines the results of two queries and removes any duplicate rows. It
is suitable for combining similar data from different tables.
For example, if we want to combine the products from two different categories, say
"Fashion" and "Electronics":
SELECT *
FROM Products
WHERE Belongs_To = 1

UNION

SELECT *
FROM Products
WHERE Belongs_To = 3;

Output→
Product_Id Name Description Price Belongs_To
P4 Woxen Shirt Men, Regular Fit 2000 C1
XL
P5 Wrangler T- Men, Solid, Polo Neck 1499 C1
Shirt
P2 HP 15s Intel i3 Thin and Light Laptop 56260 C3
P3 Lenovo Four sided narrow bezel and a screen- 47990 C3
Ideapad... to-bo...

2. Union All:
Similar to UNION, but it does not eliminate duplicate rows. It combines all rows from
two queries.

For example, Combine all products from the "Mobiles" category and products with a
discount of more than 50%.

SELECT *
FROM Products
WHERE Belongs_To = 2

UNION ALL

SELECT p.*
FROM Products p
INNER JOIN Categories c ON p.Belongs_To = c.Category_Id
INNER JOIN Discount d ON c.Has = d.Discount_Id
WHERE d.Offer > 50;

Output→
Product_Id Name Description Price Belongs_To
P1 Vivo T2X 5G Fastest Selling 5G Phone 17999 C2
P2 HP 15s Intel i3 Thin and Light Laptop 56260 C3
P8 Samsung S24 Ultra Supercharged with AI features 110240 C2
and powerful...
P9 Attitude is English, Paperback, Keller Jeff 225 C9
Everything Book
P10 AutoLift 2Ton Capacity upto 2000kg 1499 C10
Scissor Jack
P4 Woxen Shirt XL Men, Regular Fit 2000 C1
P5 Wrangler T-Shirt Men, Solid, Polo Neck 1499 C1

3. Intersect:
This operation returns only the rows that appear in both queries. It is useful for finding
common data between two tables.

For example, Find products that belong to both the "Fashion" category and have a
discount.
SELECT p.*
FROM Products p
INNER JOIN Categories c ON p.Belongs_To = c.Category_Id
WHERE c.Category_Id = 1

INTERSECT

SELECT p.*
FROM Products p
INNER JOIN Categories c ON p.Belongs_To = c.Category_Id
INNER JOIN Discount d ON c.Has = d.Discount_Id;

Output→
Product_Id Name Description Price Belongs_To
P4 Woxen Shirt XL Men, Regular Fit 2000 C1
P5 Wrangler T-Shirt Men, Solid, Polo Neck 1499 C1

4. Minus:
This operation returns the rows that appear in the first query but not in the second query.
It is useful for finding the difference between two tables.
 For example, Find products from the "Electronics" category that do not have any
reviews.
SELECT *
FROM Products
WHERE Belongs_To = 3

MINUS

SELECT p.*
FROM Products p
INNER JOIN Reviews r ON p.Product_Id = r.Has;

Output→
Product_Id Name Description Price Belongs_To
P2 HP 15s Intel i3 Thin and Light Laptop 56260 C3
P3 Lenovo Four sided narrow bezel and a screen- 47990 C3
Ideapad... to-bo...
Joins
1. Inner Join:
SELECT Users.*, Phone.Phone
FROM Users
INNER JOIN Phone ON Users.User_Id = Phone.User_Id;

This query retrieves all columns from the Users table and the Phone column from the Phone
table, where there is a matching User_Id in both tables. It effectively combines the information
from both tables based on the User_Id column.
Output→
User_Id Name Email Phone
1 Admin admin@ecommerce.com 7742198188
2 Pragya pragya@gmail.com 7854589545
3 Rahul Sharma Rahul.sharma@gmail.com 5484589545
4 Soniya Singh soniyasingh@gmail.com 9458745845
5 Mohit Verma mohit@gmail.com 9654215425
6 Priya Sharma priyasharma@gmail.com 9823456153
7 Rohit Sharma rohit@gmail.com 9751482536
8 Anushka Gupta Anushka.g@gmail.com 9564875123
9 Dev Kumar Dev.kumar@gmail.com 8452146256
10 Pooja Sharma pooja@gmail.com 7214589456

2. Left Join:
SELECT Wishlist.Wishlist_Id, AddedTo.Product_Id
FROM Wishlist
LEFT JOIN AddedTo ON Wishlist.Wishlist_Id = AddedTo.Wishlist_Id;

This query retrieves the Wishlist_Id and Product_Id columns, where each row from the Wishlist
table is matched with the corresponding row from the AddedTo table based on the Wishlist_Id
column. If there is no match in the AddedTo table for a particular Wishlist_Id, the Product_Id
will be NULL for that row in the result set.
Output→
Wishlist_Id Product_Id
W1 P1
W1 P2
W1 P5
W1 P6
W2 P4
W2 P5
W3 NULL
W4 P3
 W4 P8
W5 P6
W5 P9
W6 P7
W6 P4
W7 P8
W7 P10
W8 P4
W9 P5
W10 P2

3. Full Join:
SELECT Orders.*, Payments.Payment_Id, Payments.Method
FROM Orders
FULL OUTER JOIN Payments ON Orders.Order_Id = Payments.Order_Id;

This query retrieves all columns from the Orders table and adds two additional columns
(Payment_Id and Method) from the Payments table. Each row from the Orders table is matched
with the corresponding row from the Payments table based on the Order_Id column. If there is
no match in either table for a particular Order_Id, the Payment_Id and Method columns will
be NULL for that row in the result set.
Output→
Order_Id Status Place Total_Amount Date Payment_Id Method
O1 Shipped 2 64260 2024-04- PAY1 Credit
10 Card
O2 Pending 2 2998 2024-04- PAY2 Debit
12 Card
O3 Processing 3 250 2024-04- PAY3 Cash
11
O4 Out For 4 110240 2024-04- PAY4 Credit
Delivery 20 Card
O5 Delivered 4 7495 2024-04- PAY5 Debit
28 Card
O6 Cancelled 4 35998 2024-05- PAY6 Cash
01
O7 Returned 5 143970 2024-05- PAY7 Cash
04
O8 Shipped 8 2998 2024-05- PAY8 Credit
08 Card
O9 Shipped 10 NULL 2024-05- PAY9 Credit
18 Card
O10 Delivered 2 NULL 2024-05- PAY10 Credit
24 Card

4. Right Join:
SELECT Products.*, Categories.Name AS Category
FROM Products
RIGHT JOIN Categories ON Products.Belongs_To = Categories.Category_Id;

this query retrieves all columns from the Products table and adds one additional column
(Category) from the Categories table. Each row from the Categories table is matched with the
corresponding row from the Products table based on the Belongs_To column. If there is no
match in the Products table for a particular Category_Id, the columns from the Products table
will be NULL for that row in the result set.
Output→
Product_Id Name Description Price Belongs_To Category
P1 Vivo T2X 5G Fastest Selling 5G 17999 C2 Mobiles
Phone
P2 HP 15s Intel Thin and Light Laptop 56260 C3 Electronics
i3
P3 Lenovo Four sided narrow 47990 C3 Electronics
Ideapad Slim bezel and a screen-to-
5 body ratio of upto 88%
P4 Woxen Shirt Men, Regular Fit 2000 C1 Fashion
XL
P5 Wrangler T- Men, Solid, Polo Neck 1499 C1 Fashion
Shirt
P6 Bharat Austin Fabric, Manual 28000 C5 Home and
Lifestyle Recliner Furniture
Recliner
P7 Life’s English, Paperback, 250 C9 Books
Amazing Das Gaur Gopal
Secrets Book
P8 Samsung S24 Supercharged with AI 110240 C2 Mobiles
Ultra features and powerful
hardware
P9 Attitude is English, Paperback, 225 C9 Books
Everything Keller Jeff
Book
P10 AutoLift 2Ton Capacity upto 2000kg 1499 C10 Auto
Scissor Jack Accessories
NULL NULL NULL NULL C4 Grocery
NULL NULL NULL NULL C6 Health Care
NULL NULL NULL NULL C7 Sports and
Fitness

5. Natural Join
SELECT *
FROM Orders
NATURAL JOIN Payments;
This performs a Natural Join between the Orders and Payments tables. Since the Natural Join
automatically matches columns with the same name, it joins the tables on columns that have
the same name and the same data type in both tables.
So, the output of this query will be a result set containing all columns from both the Orders and
Payments tables, with only the rows where there are matching values in columns with the same
name.
Output→
Order_Id Status Place Total_Amount Date Payment_Id Method
O1 Shipped 2 64260 2024-04- PAY1 Credit
10 Card
O2 Pending 2 2998 2024-04- PAY2 Debit Card
12
O3 Processing 3 250 2024-04- PAY3 Cash
11
O4 Out For 4 110240 2024-04- PAY4 Credit
Delivery 20 Card
O5 Delivered 4 7495 2024-04- PAY5 Debit Card
28
O6 Cancelled 4 35998 2024-05- PAY6 Cash
01
O7 Returned 5 143970 2024-05- PAY7 Cash
04
O8 Shipped 8 2998 2024-05- PAY8 Credit
08 Card
O9 Shipped 10 NULL 2024-05- PAY9 Credit
18 Card
O10 Delivered 2 NULL 2024-05- PAY10 Credit
24 Card

6. Conditional Join
SELECT Wishlist.*, AddedTo.Product_Id
FROM Wishlist
JOIN AddedTo ON Wishlist.Wishlist_Id = AddedTo.Wishlist_Id
WHERE AddedTo.Product_Id = 5;

This query retrieves all columns from the Wishlist table and adds the Product_Id column from
the AddedTo table. It only includes rows where there is a matching Wishlist_Id in both tables
and where the Product_Id in the AddedTo table is equal to 5.
Output→
Wishlist_Id Has Product_Id
W1 2 P5
W2 3 P5
W9 3 P5
Normalization:
Since all the tables in the above database does not violate any of the rules of 1NF, 2NF, 3NF,
BCNF or 4NF, thus we produce the following modifications in some of the tables in order to
apply normalization over them:

1. Table: Wishlist
We can introduce a multivalued dependency by adding a new attribute to the Wishlist
table called Product_Details, where multiple products can be stored as a comma-
separated list.

Wishlist_Id User_Id Product_Details

W1 2 P1, P2, P5, P6
W2 3 P4, P5
W3 2 P3
W4 4 P3, P8
W5 5 P6, P9
W6 6 P7, P4
W7 9 P8, P10
W8 9 P4
W9 3 P5
W10 5 P2

Product_Details violates the 1NF because it contains multiple values separated by commas.
Each cell in a relational table should contain a single value, and multi-valued attributes should
be avoided. Also, the product details column is dependent only on wishlist_id and not on the
user_id hence, partial dependency exists and thus it violates 2NF rules.
Now, to resolve this we'll split the multivalued attribute Product_Details into a separate table
with a composite primary key.
Wishlist_Id User_Id
W1 2
W2 3
W3 2
W4 4
W5 5
W6 6
W7 9
W8 9
W9 3
W10 5
Table: Wishlist
Wishlist_Id Product_Id
W1 P1
W1 P2
 W1 P5
W1 P6
W2 P4
W2 P5
W4 P3
W4 P8
W5 P6
W5 P9
W6 P7
W6 P4
W7 P8
W7 P10
W8 P4
W9 P5
W10 P2
Table: Wishlist_Products

2. Table: Categories:
Let's introduce a transitive dependency by adding an attribute called Discount_Offer
directly to the Categories table.
Category_Id Name Has Discount_Offer
C1 Fashion 4 50
C2 Mobiles 2 20
C3 Electronics 1 33
C4 Grocery 3 5
C5 Home and Furniture 7 90
C6 Health Care 6 80
C7 Sports and Fitness 5 10
C9 Books 10 55
C10 Auto Accessories 9 44

To determine if the table violates 3NF, we need to identify any transitive dependencies. A
transitive dependency occurs when a non-prime attribute (an attribute not part of any candidate
key) depends on another non-prime attribute.
In this table, Discount_Offer appears to depend on Has, which is a non-prime attribute.
• Category_Id (Primary Key)
• Name
• Has (Non-prime attribute)
• Discount_Offer (Non-prime attribute)
Here, Discount_Offer seems to be functionally dependent on Has. This means the
Discount_Offer attribute is indirectly dependent on the Category_Id (the primary key),
violating 3NF.
To resolve this violation, we can split the table into two:
Category_Id Name Has
C1 Fashion D4
C2 Mobiles D2
C3 Electronics D1
C4 Grocery D3
C5 Home and Furniture D7
C6 Health Care D6
C7 Sports and Fitness D5
9 Books D10
10 Auto Accessories D9
Table: Categories

Discount_Id Offer
D1 33
D2 20
D3 5
D4 50
D5 10
D6 80
D7 90
D9 44
D10 55
Table: Discount
Result

Figure 1 Login Screen

This is the login window where users can access the application by entering their account
credentials. Users are required to input their username and password to log in and gain access
to the application.

Figure 2 Register Window

To access and utilize the application seamlessly, users must first register on the platform. They
are required to complete all necessary details to successfully register.
 Figure 3 Home Screen

Upon successful login, users can access and utilize the application from this home screen,
which offers various buttons for different tasks. In this window users can choose from several
options including:
1. View Product Categories
2. Search Products
3. Explore Wishlist
4. View past orders
5. Insert Products (Visible only to admin)
6. Insert Categories (Visible only to admin)
7. Delete Product (Visible only to admin)
8. Cart
 Figure 4 Categories

This is the categories window, where users can explore products specific to various categories
such as groceries, electronics, mobiles, and more.

Figure 5 Category: Fashion Product

This is the product display window for the selected category from the category window. Here,
users can explore various products related to the selected category.
 Figure 6 Product Details

This is the product details window, displaying the name, price, and description of the selected
product. Users can add the product to their cart by clicking the "Buy" button, and also have the
option to add the product to their wishlist.

Figure 7 Search Window

This is the search window where users can explore products related to a particular keyword by
entering their search query.
 Figure 8 Searching for a specific keyword

This is an example snapshot showing search results for the keyword "a". In the results, the user
found the following two products.

Figure 9 Wishlist

This is the wishlist window where users can view the list of products they have added to their
wishlist.
 Figure 10 Cart

This is the shopping cart, where users can view the products, they have added to their cart
directly from the product description page. The cart displays the list of products along with the
quantity the user has added for each item, as well as the total price of all items in the cart.

Figure 11 Order Summary

This is the order summary window, which presents the user's information such as name,
address, and email. Additionally, it displays the items currently in the cart and ready to be
placed for order.
 Figure 12 Payment Method

After placing the order, this payment method screen is displayed to the user, offering a selection
of various payment methods available such as UPI, cash on delivery, net banking, or
credit/debit card.

Figure 13 Payment Confirmation

This confirmation dialogue box appears, indicating that the product has been placed
successfully.
Conclusion

In conclusion, the development of our E-commerce Management System, utilizing SQLite as

the underlying database, marks a significant milestone in harnessing the power of database
management for streamlined online commerce. Through meticulous design and optimization,
we've transformed complex ER diagrams into efficient relational tables, facilitating seamless
data organization and retrieval.

The execution of various queries on these relational tables has not only validated the efficacy
of our database schema but also demonstrated its versatility in supporting diverse
functionalities essential for e-commerce operations. From inventory management to customer
relationship tracking, SQLite has proven to be a reliable foundation, enabling swift query
execution and ensuring smooth system performance.

As we reflect on this project, it becomes evident that the integration of SQLite into our E-
commerce Management System has not only enhanced operational efficiency but also paved
the way for future scalability and innovation. By leveraging the capabilities of database
management systems, we've laid a robust groundwork for sustainable growth and continuous
optimization in the dynamic landscape of online commerce.