E-COMMERCE MANAGEMENT SYSTEM

By

Avyakt Garg 2020B1A71902P

Tanushi Garg 2020B1A70648P

DBMS PROJECT
SEMESTER II 2022-23
 ER DIAGRAM

EXPLANATION:
● The above given ER diagram has 7 entities denoted by rectangles and all entities have
corresponding attributes drawn in ellipses. The primary key of each entity has been
underlined.
● There are 7 relations represented by diamonds having their cardinality ratios mentioned
over the connecting line segments.
● Total and partial participation can be distinguished based on double and single lines
between relationship set and entity set respectively.
● Dashed Ellipses depict derived attributes.
● Double ovals are used to represent multivalued attributes (note - they were resolved
later in 1NF normalization)
● Double rectangles represent weak entities that don’t have unique identification i.e. don’t
have a primary key and depend upon other entities.
 CONVERSION OF ER TO RELATIONAL MODEL

STEP1
We converted all entities and relations as tables and then looked for redundancies

1. CUSTOMER

Cust_id Name Emaill Phone No. Shipping_Add

2. PRODUCTS

Effective_price Price Prod_id Name Description Order_units Stock_units Discount Category

3. ORDERS

Order_id Date Price Status Shipping_Ad

4. SHIPPING

Expected Date Del_Ph_No Zipcode Address Status Tracking_No

5. REVIEWS

Rating Feedback Date Title

6. PAYMENT

Payment_id Amount Type Date

 7. COUPON

Code Discount

8. CART

Cust_id Quantity Prod_id

9. PLACES

Cust_id Order_id

10. HAS

Prod_id Order_id

11. SHIPMENT

Tracking_No Order_id

12. GETS

Prod_id Rating Feedback Date

13. TAKES

Payment_id Order_id

14. APPLIES

Code Order_id
 STEP 2
We checked for redundancies and thus removed the unnecessary tables. For example, the table
for relation ‘takes’ was removed and instead order_id was added as a Foreign Key into the
Payment table. We have underlined the Primary Keys and have mentioned Foreign Keys using
(F.K.)

1. CUSTOMER

Cust_id Name Emaill Phone No. Shipping_Add

2. PRODUCTS

Effective_price Price Prod_id Name Description Order_units Stock_units Discount Category

3. ORDERS

Order_id Date Price Status Shipping_ Cust_id (F.K.) Code (F.K)

Ad

4. SHIPPING

Expected Del_Ph_ Zipcode Address Status Tracking_N Order_id

Date No o (F.K,)

5. REVIEWS

Rating Feedback Date Title Prod_id (F.K.)

6. PAYMENT

Payment_id Amount Type Date Order_id (F.K.)

7. COUPON

Code Discount
 8. CART

Cust_id (F.K.) Quantity Prod_id (F.K.)

9. HAS

Prod_id (F.K) Order_id (F.K.)

 NORMALISING THE RELATIONS

1NF

First normal form prohibits the use of multivalued and/or composite attributes we check each
table for the same

1. CUSTOMER
It has Shipping address as a multivalued as well as a composite attribute. To
tackle this we first divided the column shipping address into S.no, House, City,
State, and Pincode

But these columns were still multivalued and to sort this issue we decided to add
new tuple for every value and so our new primary key became cust_id,add_s.no

Cust_id Name Emaill Phone No. Add_S.no Add_House Add_City Add_State Add_pincode

2. PRODUCTS
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

3. ORDERS
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

4. SHIPPING
This also had the column Address though this was not multivalued it was
composite and so we broke it down just like in customers.

Expected Del_Ph_No Zipcode Status Tracking_ Order_id Ship_State Ship_City Ship_House

Date No (F.K,)

5. REVIEWS
 They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

6. PAYMENT
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

7. COUPON
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

8. CART
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.

9. HAS
They have no multi-valued and/or composite attributes thereby satisfying the
condition for 1NF.
 2NF

Relation must follow the condition for 1NF and all Non-Prime attributes should be fully functional
dependent on the Primary Key and not part of the key

1. CUSTOMER
Cust_id Name Emaill Phone No. Add_S.no Add_House Add_City Add_State Add_pincode

In this the candidate key is composed of two attributes Cust_id and Add_S.No and
so we need to check if it violates 2NF.

It has the following functional dependencies

Cust_id -> Name

Cust_id -> Email
Cust_id -> Phone No.

Cust_id, Add_S.No -> Name, Email, Phone No., Add_House, Add_City, Add_state,
Add_pincode

Add_pincode ->Add_State, Add_City

Add_City -> Add_State

Now, we can see that the Cust_id can singularly determine Name, Email and Phone No.,
independent of Add_Sno which is also a part of the candidate key and therefore, the
relation must be decomposed.

A. Customer
Cust_ID Name Number Email

B. Customer_Locations
Cust_ID Add.Sno Add_House Add_State Add_City Add_pincode

2. PRODUCTS
Effective_price Price Prod_id Name Description Order_units Stock_units Discount Category

Following are the functional dependencies in the the relation:

Prod_id -> Effective_price
Prod_id ->Price
Prod_id ->Name
Prod_id ->Description
Prod_id ->Order_units
 Prod_id ->Stock_units
Prod_id ->Discount
Prod_id ->Category

Doesn’t violate the 2NF

3. ORDERS
Order_id Date Price Status Shipping_ Cust_id (F.K.) Code (F.K)
Ad

Following are the functional dependencies in the the relation:

Order_id -> Date
Order_id -> Price
Order_id -> Status
Order_id -> Shipping_Ad
Order_id -> Cust_id
Order_id -> Code

Doesn’t Violate 2NF.

4. SHIPPING
Expected Del_Ph_No Zipcode Status Tracking_ Order_id Ship_State Ship_City Ship_House
Date No (F.K,)

Following are the functional dependencies in the the relation:

Tracking_No -> Expected Date
Tracking_No -> Status
Tracking_No -> Del_Ph_No
Tracking_No -> Zipcode
Tracking_No -> Order_id
Tracking_No -> Ship_State
Tracking_No -> Ship_City
Tracking_No -> Ship_House

Zipcode -> Ship_State, Ship_City

Ship_State -> Ship_City

Doesn’t Violate 2NF.

5. REVIEWS
Rating Feedback Date Title Prod_id (F.K.)

Following are the functional dependencies in the the relation:

Title, Prod_id -> Rating, Feedback, Date

Doesn’t Violate 2NF.

6. PAYMENT
Payment_id Amount Type Date Order_id (F.K.)

Following are the functional dependencies in the the relation:

Payment_id -> Amount, Type, Date, Order_id

Doesn’t Violate 2NF.

7. COUPON
Code Discount

Following are the functional dependencies in the the relation:

Code -> Discount

Doesn’t Violate 2NF

8. CART
Cust_id (F.K.) Quantity Prod_id (F.K.)

Following are the functional dependencies in the the relation:

Cust_id, Prod_id -> Cust_id, Prod_id, Quantity

Doesn’t Violate 2NF

11. HAS
Prod_id (F.K) Order_id (F.K.)

Following are the functional dependencies in the the relation:

Prod_id, Order_id -> Prod_id, Order_id

Doesn’t Violate 2NF

 3NF
3NF eliminates Transitive Functional Dependencies for Non-Prime attributes. A 3NF relation
always satisfies 2NF.

1. CUSTOMER

Upon applying 2NF normalization, the above relation was decomposed into the following
2 relations :

C. Customer
Cust_ID Name Number Email

D. Customer_Locations
Cust_ID Add.Sno Add_House Add_State Add_City Add_pincode

In the relation Customer_Locations, we observe the following functional dependencies:

Add_pincode ->Add_State, Add_City
Add_City -> Add_State

Non-prime attribute Add_pincode can determine other non-prime attributes like

Add_State and Add_city. Also, we can obtain Add_state from Add_City, both
being non-prime attributes. This violates the conditions for 3NF and the relation
Customer_Locations must be decomposed as below:

E. Customer_Location
Cust_id Add_Sno Add_House Add_pincode

F. Customer_city
Add_pincode Add_city

G. Customer_state
Add_city Add_state

2. PRODUCTS
Effective_price Price Prod_id Name Description Order_units Stock_units Discount Category

Following are the functional dependencies in the the relation:

Prod_id -> Effective_price
Prod_id ->Price
 Prod_id ->Name
Prod_id ->Description
Prod_id ->Order_units
Prod_id ->Stock_units
Prod_id ->Discount
Prod_id ->Category

Doesn’t violate the 3NF

3. ORDERS
Order_id Date Price Status Shipping_ Cust_id (F.K.) Code (F.K)
Ad

Following are the functional dependencies in the the relation:

Order_id -> Date
Order_id -> Price
Order_id -> Status
Order_id -> Shipping_Ad
Order_id -> Cust_id
Order_id -> Code

Doesn’t Violate 3NF.

4. SHIPPING
Expected Del_Ph_No Zipcode Status Tracking_ Order_id Ship_State Ship_City Ship_House
Date No (F.K,)

The following functional dependencies can be observed in the relation:

Zipcode -> Ship_State, Ship_City
Ship_State -> Ship_City

Just as observed in Customer relation, Non-prime attribute Zipcode can determine other
non-prime attributes like Ship_State and Ship_city. Also, we can obtain Ship_state from
Ship_City, both being non-prime attributes. This violates the conditions for 3NF and the
relation Shippping must be decomposed in similar manner:

H. Ship_city
Zipcode Ship_city

I. Ship_state
Ship_city Ship_state
 J. Ship_Location
Expected_ Del_Ph_No Zipcode Status Tracking_ Ship_House Order_
Date No id

We see a redundancy in data since relations Customer_city and Customer_state can be

used in place of Ship_city and Ship_state respectively. Therefore, these 2 relations are
eliminated.

5. REVIEWS
Rating Feedback Date Title Prod_id (F.K.)

Following are the functional dependencies in the the relation:

Title, Prod_id -> Rating, Feedback, Date

Doesn’t Violate 3NF.

6. PAYMENT
Payment_id Amount Type Date Order_id (F.K.)

Following are the functional dependencies in the the relation:

Payment_id -> Amount, Type, Date, Order_id

Doesn’t Violate 3NF.

7. COUPON
Code Discount

Following are the functional dependencies in the the relation:

Code -> Discount

Doesn’t Violate 3NF

8. CART
Cust_id (F.K.) Quantity Prod_id (F.K.)

Following are the functional dependencies in the the relation:

Cust_id, Prod_id -> Cust_id, Prod_id, Quantity

Doesn’t Violate 3NF.

11. HAS
Prod_id (F.K) Order_id (F.K.)

Following are the functional dependencies in the the relation:

Prod_id, Order_id -> Prod_id, Order_id

Doesn’t Violate 3NF.

FINAL TABLES WITH CONSTRAINTS AND KEYS

Customers
c_id :Stores the customer id, can't be null and is the primary key
C_name: Stores the Customer's name, can't be null
c_email : Stores the Email of the customer, can’t be null
c_phoneno : Stores the Phone Number of the customer, Can't be null

Constraints are applied so that valid emails i.e one having @ and a domain name are
allowed, only 10 digit phone numbers can be stored

Also duplicate entries for email or phone number is prevented

Customer_Location
C_id: Stores the customer id, can't be null also acts as foreign key to table customer
C_address_sno: Stores the S.No. of the address of that user default value is set as 1
C_address_house: Stores the line 1 of address eg C390, SFS Flats
C_address_pincode: Stores the pincode of the address

In this the C_id along with C_Adress_sno acts as primary key

Constraints are added to ensure that only valid 6 digit pin codes are entered

No Null Values are allowed to be stored

Customer_city
C_city: Stores the name of the city
C_pincode: Stores the pincode of the city, acts as the primary key also refers to the table
Customer_location

No null values are allowed to be stored

Customer_state
c_state : Stores the name of the State
C_city: Stores the name of the city which acts as the primary key and also refers to the
table custome_city

No null values are allowed to be stored, also while inserting we have tried to use
INSERT IGNORE INTO to prevent redundant entries

Products
P_id Stores the id of the product, acts as the primary key
p_description : Stores the description of the product
P_category: Stores the category of the product
P_price: Stores the price of the product
p_effective_price : Is a derived attribute and stores the effective price i.e. price after
discount
P_discount: Store the percentage discount on the product
P_units_on_order: Stores the amount of products on order
P_units_in_stock: Stores the number of products in stockI)

No null values are allowed

Constraints are added to ensure that the units on stock and units on order never go into
negative also discount is only allowed to store values between 0 to 100

Coupons
c_coupon_code Stores the coupon code also acts as the primary key
c_discount Stores the discount percentages

No Null Values are Allowed

Constraints are added to ensure that the discount is always between 0 to 100 percent
Orders
O_id Stores the order id and acts as the primary key
O_date Stores the date of placing the order
O_status Stores the status of the order
o_coupon_code Stores the applied coupon code, its default value is set to ‘ZERO’ which
points to 0% discount, references to table Coupons
o_house Stores the shipping address line 1
o_pincode Stores the pincode and refers to the table customer_city

Appropriate constraints are added and no null values are added

Payment
p_id Stores a unique payment id and acts as primary key o_id VARCHAR(5) NOT NULL,
p_amount Stores the amount transferred/received
p_type To store the mode of payment
P_date To store the date of payment
O_id acts as a foreign key to refer to the table orders

Constraints like cascade delete is added so that if the order is deleted its payment is also
deleted
Note: for cancellation a negative payment is generated and the status is set to canceled

No Null Values are allowed

Shipping
s_tracking_id Stores the tracking id and allows user to track package, acts as primary
key s_date Stores expected date of shipping
s_phoneno Stores the phone number of the delivery executive
s_status Tells the status of the delivery
o_id Refers to the order it is delivering

Constraints like checking phone number and cascade delete are added ere

No Null Values are allowed

Reviews
p_id Stores the identity of the product being reviewed,refers to the table products
r_title Stores the title of the review
r_rating Stores the rating of the product
r_feedback Stores the review of the product
r_date Stores the date of review

Constraints are added to ensure that the rating is in between 1-5,

Also cascade delete constraint is added in order to delete the review if the product is
deleted

Has
p_id Stores the product id in the order, refers to table product
o_id stores the order id, refers to table orders
p_qty stores the quantity of product in the order

The order id along with product id acts as the primary key

Foreign key constraints are also added

Also cascade delete constraint is added so that if order is deleted the entry is deleted
from here also.

Cart
c_id gives the id of the user of the cart, refers to the table customers
p_id Stores the id of the product added into the cart, refers to the table products
p_qty Stores quantity of the product added into the cart

Foreign key constraints are added

Customer id along with product id is used as primary key

Constraints like cascade delete is added to ensure that the entries from cart is removed
if a user is deleted
 SQL QUERIES AND THEIR OUTPUTS

#QUERY 1 CREATING NEW USER

OUTPUT:

#QUERY 2 BROWSING PRODUCTS IN SPECIFIC CATEGORY

OUTPUT:
#QUERY 3 RECOMMENDING SIMILAR PRODUCTS

OUTPUT:

#QUERY 4 SHIPPING STATUS VIA TRACKING NUMBER

OUTPUT:

#QUERY 5 CHANGE SHIPPING ADDRESS

OUTPUT:
#QUERY 6 PRODUCT INFORMATION

OUTPUT:

#QUERY 7 PRODUCTS ON SALE

OUTPUT:
#QUERY 8 ADD PRODUCT TO CART

OUTPUT:

#QUERY 9 PLACING ORDER USING COUPON CODE

OUTPUT:
#QUERY 10 CANCELLING AN ORDER

OUTPUT:

#QUERY 11 - WRITING A REVIEW

OUTPUT:
#QUERY XX - VIEWING A REVIEW

OUTPUT:

#QUERY 12 - SUGGESTING PRODUCTS FREQUENTLY PURCHASED TOGETHER

OUTPUT:

#QUERY 13 ORDER HISTORY

OUTPUT:
#QUERY 14 PROCESSING A REFUND

OUTPUT:

#QUERY 15 UPDATING PAYMENT INFORMATION

#QUERY 16 TRENDING PRODUCTS

OUTPUT:

#QUERY 17 CHANGE DESIRED PRODUCT QUANTITY IN CART

OUTPUT: