Scribd
Upload
6 views7 pages

DBMS Micro

DBMS Micro roject for Btech

Uploaded by

info.ganolife
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views7 pages

DBMS Micro

DBMS Micro roject for Btech

Uploaded by

info.ganolife
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Mini Project

Group Members :
Name Enrollment No.

Tanish Kamdar 24CP304

Pratham Chelaramani 24CP303

Guided by Prof. Kirti Sharma


Project Title : LaptopNest

Project Definition
This project is an exclusive e-commerce platform dedicated to selling a wide
range of laptops. The store offers a comprehensive inventory that includes
laptops across various categories, from gaming to work and personal use.
Each laptop listing provides detailed specifications, such as processor type,
RAM capacity, storage size, graphics card model, display features, and more,
ensuring that customers can make well-informed purchasing decisions.

Initial Table
First we will create a single table with all the necessary columns:

Processor VARCHAR Processor used in the laptop

Type of Graphics Card used in laptop

Page 1
Functional Dependencies (Before Normalization)

LaptopID → LaptopName, RAM, Storage, GraphicsCard, Display, Price, Category, StockQuantity


This means LaptopID determines all laptop-related information.

SupplierID → SupplierName, SupplierContact


SupplierID determines supplier details.

PurchaseID → UserID, Username, DatePurchased


PurchaseID determines purchase and user information.

UserID → Username
UserID determines the username (assuming each user has a unique ID).

Finding Key Attributes (Before Normalization)

Candidate Keys : LaptopID, PurchaseID, SupplierID

Primary Key : LaptopID

Foreign Keys : None (Since no other table for REFERENCE)

Issues in the FDs

Data Redundancy: Supplier and user information are repeated unnecessarily, which causes
inefficiency.

Partial Dependencies: Attributes like StockQuantity do not depend on the entire primary key.

Multi-Valued Attributes: The SupplierContact field violates 1NF.

Anomalies: Update, insert, and delete anomalies are likely due to mixed data types and
redundancy.

Lack of Separation: Combining purchase data with product data and supplier information
creates a need for separation into multiple tables.

Conclusion

As we can observe, just adding all the columns in a single table can cause unwanted
dependencies, data redundancy & anomalies. The solution for all this is Normalization.

Let’s Now Implement Normalization to our table and find the best possible set of relations
to solve our problem.

Page 2
Normalization
1st Normal Form : The table must have atomic (single-valued) attributes, and
there should be no repeating groups .

The SupplierContact column is multi-valued. To resolve this, we'll split the


multi-valued attribute into separate rows for each contact number, thus making
the table comply with 1NF.

2nd Normal Form : The table must be in 1NF, and all non-key attributes should
be fully functionally dependent on the primary key. Partial dependencies should
be removed .

Non-key columns like SupplierName, SupplierContact, and Category


are dependent on only part of the composite key (LaptopID or SupplierID),
leading to partial dependencies.

Functional Dependencies:

LaptopID → LaptopName, RAM, Storage, GraphicsCard, Display, Price, Category,


StockQuantity.
SupplierID → SupplierName, SupplierContact
PurchaseID → UserID, Username, DatePurchased

To fix this, we need to create new tables for Suppliers and Purchases.

Laptop Table :

Supplier Table:

Purchase Table:

Page 3
3rd Normal Form : The table must be in 2NF, and no transitive dependencies
should exist (i.e., non-key attributes should not depend on other non-key attributes).

Functional Dependencies: .

The Purchases table still has a transitive dependency:

UserID → Username, Username → PurchaseID

This introduces a transitive dependency because Username depends on UserID,


which in turn depends on PurchaseID

To resolve this, we split the Purchases table into two relations:

Users Table: Store the user information separately.


Purchases Table: Store only the purchase-related information.

Users Table :

Purchases Table :

BCNF : A table is in BCNF if It is already in 3NF and For every functional dependency
(FD), the determinant (left-hand side of the FD) is a superkey.

After checking all the tables we couldn’t find any table that violates BCNF.

4th Normal Form : A relation is in 4NF if It is in BCNF and It has no multi-valued


dependencies (MVDs) unless they are trivial, which means all non-trivial multi-valued
dependencies must be removed.

Functional Dependencies: .

SupplierID → SupplierName, SupplierContact

There is a potential issue here because SupplierContact is a multi-valued attribute.


A supplier can have multiple contact numbers, and these are independent of the
supplier name. This represents a multi-valued dependency:

SupplierID →→ SupplierContact (independently from SupplierName)

To resolve this, we need to split this table to remove the multi-valued dependency.
We create two separate tables:

Supplier Details: Store supplier-specific information (without contact numbers).


Supplier Contacts: Store supplier contact information.

Page 4
Supplier Details Table :

Supplier Details Table :

5th Normal Form : A relation is in Fifth Normal Form (5NF) if It is in 4NF and It
cannot be decomposed further into smaller relations without losing information
(i.e., no non-trivial join dependencies should exist). .

After checking all the tables we couldn’t find any table that violates 5th NF.

After Normalization :
Relational Diagram:

Conclusion : After performing normalization we get the best possible set of


relations, without any redundancy.

Now we can move toward the creation of the Entity-Relationship diagram.

Page 5
Entity Relationship Diagram:

Page 6

You might also like