SQL

1. Practice_sql_1 - MySQL - OneCompiler

2. Transaction Practice - MySQL - OneCompiler
3. Table related Queries - MySQL - OneCompiler

-- CREATE TABLE student(

-- id int PRIMARY KEY,
-- name varchar(30),
-- age int not NULL
-- );
-- INSERT INTO student(id,name,age)
-- VALUES
-- (1,"anuj",22),
-- (2,"shiva",22),
-- (3,"aman",22);

-- SELECT *FROM student;

-- Create Sales table

CREATE TABLE Sales (

sale_id INT PRIMARY KEY,
product_id INT,
quantity_sold INT,
sale_date DATE,
total_price DECIMAL(10, 2)
);

-- Insert sample data into Sales table

INSERT INTO Sales (sale_id, product_id, quantity_sold,

sale_date, total_price) VALUES
(1, 101, 5, '2024-01-01', 2500.00),
(2, 102, 3, '2024-01-02', 900.00),
(3, 103, 2, '2024-01-02', 60.00),
(4, 104, 4, '2024-01-03', 80.00),
(5, 105, 6, '2024-01-03', 90.00);
-- SELECT *FROM Sales;

SELECT avg(total_price) FROM Sales;

SELECT product_id,total_price FROM Sales
where total_price<=(SELECT avg(total_price) FROM Sales);

-- Random selection of item

SELECT product_id
FROM Sales
ORDER BY RAND()
LIMIT 2;

-- last item
SELECT quantity_sold FROM Sales
ORDER by sale_id desc
LIMIT 1;
SELECT quantity_sold FROM Sales
ORDER by sale_id desc
LIMIT 3;

-- sort by price
SELECT sale_id,total_price FROM Sales
ORDER by total_price desc;
-- order by data
SELECT sale_id,sale_date FROM Sales
ORDER by sale_date desc;

SELECT sale_id,quantity_sold FROM Sales

where quantity_sold>=5;
SELECT sale_id,sale_date FROM Sales
where not sale_date='2024-01-02';

SELECT *FROM Sales;

-- in
SELECT sale_id,product_id,total_price FROM Sales
where product_id IN(101,102);

SELECT sale_id,quantity_sold FROM Sales

where quantity_sold IN(5,2);
-- not IN
SELECT sale_id,quantity_sold FROM Sales
where quantity_sold not IN(5,2);
-- between
SELECT sale_id,total_price FROM Sales
where total_price between 50 and 500;

-- not between
SELECT sale_id, total_price
FROM Sales
WHERE total_price NOT BETWEEN 50 AND 500;
-- Like
SELECT sale_id,sale_date FROM Sales
WHERE sale_date Like '2024-01-%';

SELECT sale_id,sale_date FROM Sales

WHERE sale_date Like '%-01-%';

SELECT sale_id,sale_date FROM Sales

WHERE sale_date Like '%-03';

-- ANY: Compares a value to each value in a list or

-- subquery and returns true if any comparison is true.
SELECT product_id, quantity_sold, sale_date, total_price
FROM Sales
WHERE total_price > ANY (SELECT total_price FROM Sales
WHERE sale_date = '2024-01-02');
-- all
-- ANY: Returns TRUE if the condition is TRUE for at least
one value in the subquery result.
-- ALL: Returns TRUE if the condition is TRUE for all
values in the subquery result.
SELECT product_id, quantity_sold, sale_date, total_price
FROM Sales
WHERE total_price > ALL (SELECT total_price FROM Sales
WHERE sale_date = '2024-01-02');

-- group by
SELECT avg(total_price), count(sale_id),sale_date FROM
Sales
group by sale_date;

-- HAVING clause
SELECT product_id, SUM(total_price) AS total_sales
FROM Sales
GROUP BY product_id
HAVING SUM(total_price) > 100;

SELECT sale_date, SUM(total_price) AS

sum_of_total_sales_group_by_data
FROM Sales
GROUP BY sale_date
HAVING SUM(total_price) > 100;

Alter TABLE Sales add product_val int default 0;

-- SELECT * FROM Sales;
-- If the column exists, run this command:
ALTER TABLE Sales DROP COLUMN product_val;

-- Select all rows from the Sales table

-- SELECT * FROM Sales;
ALTER table Sales add new_col int;

delete new_col FROM Sales;

SELECT * FROM Sales;

Output:
+------------------+
| avg(total_price) |
+------------------+
| 726.000000 |
+------------------+
+------------+-------------+
| product_id | total_price |
+------------+-------------+
| 103 | 60.00 |
| 104 | 80.00 |
| 105 | 90.00 |
+------------+-------------+
+------------+
| product_id |
+------------+
| 104 |
| 103 |
+------------+
+---------------+
| quantity_sold |
+---------------+
| 6 |
+---------------+
+---------------+
| quantity_sold |
+---------------+
| 6 |
| 4 |
| 2 |
+---------------+
+---------+-------------+
| sale_id | total_price |
+---------+-------------+
| 1 | 2500.00 |
| 2 | 900.00 |
| 5 | 90.00 |
| 4 | 80.00 |
| 3 | 60.00 |
+---------+-------------+
+---------+------------+
| sale_id | sale_date |
+---------+------------+
| 4 | 2024-01-03 |
| 5 | 2024-01-03 |
| 2 | 2024-01-02 |
| 3 | 2024-01-02 |
| 1 | 2024-01-01 |
+---------+------------+
+---------+---------------+
| sale_id | quantity_sold |
+---------+---------------+
| 1 | 5 |
| 5 | 6 |
+---------+---------------+
+---------+------------+
| sale_id | sale_date |
+---------+------------+
| 1 | 2024-01-01 |
| 4 | 2024-01-03 |
| 5 | 2024-01-03 |
+---------+------------+
+---------+------------+---------------+------------+-------------+
| sale_id | product_id | quantity_sold | sale_date | total_price |
+---------+------------+---------------+------------+-------------+
| 1 | 101 | 5 | 2024-01-01 | 2500.00 |
| 2 | 102 | 3 | 2024-01-02 | 900.00 |
| 3 | 103 | 2 | 2024-01-02 | 60.00 |
| 4 | 104 | 4 | 2024-01-03 | 80.00 |
| 5 | 105 | 6 | 2024-01-03 | 90.00 |
+---------+------------+---------------+------------+-------------+
+---------+------------+-------------+
| sale_id | product_id | total_price |
+---------+------------+-------------+
| 1 | 101 | 2500.00 |
| 2 | 102 | 900.00 |
+---------+------------+-------------+
+---------+---------------+
| sale_id | quantity_sold |
+---------+---------------+
| 1 | 5 |
| 3 | 2 |
+---------+---------------+
+---------+---------------+
| sale_id | quantity_sold |
+---------+---------------+
| 2 | 3 |
| 4 | 4 |
| 5 | 6 |
+---------+---------------+
+---------+-------------+
| sale_id | total_price |
+---------+-------------+
| 3 | 60.00 |
| 4 | 80.00 |
| 5 | 90.00 |
+---------+-------------+
+---------+-------------+
| sale_id | total_price |
+---------+-------------+
| 1 | 2500.00 |
| 2 | 900.00 |
+---------+-------------+
+---------+------------+
| sale_id | sale_date |
+---------+------------+
| 1 | 2024-01-01 |
| 2 | 2024-01-02 |
| 3 | 2024-01-02 |
| 4 | 2024-01-03 |
| 5 | 2024-01-03 |
+---------+------------+
+---------+------------+
| sale_id | sale_date |
+---------+------------+
| 1 | 2024-01-01 |
| 2 | 2024-01-02 |
| 3 | 2024-01-02 |
| 4 | 2024-01-03 |
| 5 | 2024-01-03 |
+---------+------------+
+---------+------------+
| sale_id | sale_date |
+---------+------------+
| 4 | 2024-01-03 |
| 5 | 2024-01-03 |
+---------+------------+
+------------+---------------+------------+-------------+
| product_id | quantity_sold | sale_date | total_price |
+------------+---------------+------------+-------------+
| 101 | 5 | 2024-01-01 | 2500.00 |
| 102 | 3 | 2024-01-02 | 900.00 |
| 104 | 4 | 2024-01-03 | 80.00 |
| 105 | 6 | 2024-01-03 | 90.00 |
+------------+---------------+------------+-------------+
+------------+---------------+------------+-------------+
| product_id | quantity_sold | sale_date | total_price |
+------------+---------------+------------+-------------+
| 101 | 5 | 2024-01-01 | 2500.00 |
+------------+---------------+------------+-------------+
+------------------+----------------+------------+
| avg(total_price) | count(sale_id) | sale_date |
+------------------+----------------+------------+
| 2500.000000 | 1 | 2024-01-01 |
| 480.000000 | 2 | 2024-01-02 |
| 85.000000 | 2 | 2024-01-03 |
+------------------+----------------+------------+
+------------+-------------+
| product_id | total_sales |
+------------+-------------+
| 101 | 2500.00 |
| 102 | 900.00 |
+------------+-------------+
+------------+----------------------------------+
| sale_date | sum_of_total_sales_group_by_data |
+------------+----------------------------------+
| 2024-01-01 | 2500.00 |
| 2024-01-02 | 960.00 |
| 2024-01-03 | 170.00 |
+------------+----------------------------------+
 DCL Commands

Data Control Language (DCL) commands in SQL are used to control access to data
within the database. These commands help in enforcing security by defining access
rights and permissions. The main DCL commands are GRANT and REVOKE.

DCL Commands

1. GRANT: Gives a user access privileges to the database.

2. REVOKE: Removes access privileges from a user.

GRANT Command

The GRANT command is used to provide privileges to users.

Syntax

GRANT privilege [, privilege]...

ON object
TO user [, user]...
[WITH GRANT OPTION];

● privilege: The specific privilege or list of privileges to be granted.

● object: The database object (e.g., table, view) on which the privileges are
being granted.
● user: The user or list of users to whom the privileges are being granted.
● WITH GRANT OPTION: Allows the user to grant the specified privileges to
other users.

Example

Granting SELECT and INSERT privileges on the Sales table to user username:

GRANT SELECT, INSERT

ON Sales
TO username;

Granting all privileges on the Sales table to user username with the ability to grant
the same privileges to other users:

GRANT ALL PRIVILEGES

ON Sales
TO username
WITH GRANT OPTION;

REVOKE Command

The REVOKE command is used to remove privileges from users.

Syntax
REVOKE privilege [, privilege]...
ON object
FROM user [, user]...;

● privilege: The specific privilege or list of privileges to be revoked.

● object: The database object (e.g., table, view) from which the privileges are
being revoked.
● user: The user or list of users from whom the privileges are being revoked.
Example

Revoking SELECT and INSERT privileges on the Sales table from user username:

REVOKE SELECT, INSERT

ON Sales
FROM username;

Revoking all privileges on the Sales table from user username:

REVOKE ALL PRIVILEGES

ON Sales
FROM username;

Example Usage

Assume you have a Sales table and a user john_doe. You can grant and revoke
privileges as follows:

1. Granting SELECT Privilege:

GRANT SELECT
ON Sales
TO john_doe;

2. Granting INSERT Privilege:

GRANT INSERT
ON Sales
TO john_doe;

3. Granting All Privileges:

GRANT ALL PRIVILEGES

ON Sales
TO john_doe;

4. Revoking SELECT Privilege:

REVOKE SELECT
ON Sales
FROM john_doe;

5. Revoking All Privileges:

REVOKE ALL PRIVILEGES

ON Sales
FROM john_doe;

Summary

● GRANT: Used to give users access privileges to the database.

● REVOKE: Used to remove access privileges from users.
● DCL commands help manage security and access control in SQL databases.

Indexing
Indexing is a powerful technique in SQL databases used to improve the speed of
data retrieval operations. An index is a separate data structure that allows the
database to find records more quickly than it could by scanning an entire table.
Here’s a detailed look at indexing in SQL:

Types of Indexes

1. Primary Index: Automatically created when a primary key is defined. It

ensures that the primary key columns are unique and ordered.
2. Unique Index: Ensures that all values in the indexed column(s) are unique.
Similar to the primary index but can be created on columns other than the
primary key.
 3. Clustered Index: Alters the physical storage order of the data to match the
index. There can only be one clustered index per table because the data rows
themselves can only be sorted in one order.
4. Non-Clustered Index: Does not alter the physical storage order of the data.
Instead, it creates a separate object within the table that points back to the
original data rows. A table can have multiple non-clustered indexes.
5. Composite Index: An index on multiple columns of a table. Useful for queries
that filter by multiple columns.
6. Full-Text Index: Used for full-text searches. Particularly useful for searching
large blocks of text.

Creating Indexes

Indexes are created using the CREATE INDEX statement. Here’s the syntax for
creating different types of indexes:

Basic Syntax
CREATE INDEX index_name
ON table_name (column1, column2, ...);

Examples

1. Creating a Non-Clustered Index:

CREATE INDEX idx_sales_product_id

ON Sales (product_id);

2. Creating a Unique Index:

CREATE UNIQUE INDEX idx_unique_product_name

ON Products (product_name);

3. Creating a Composite Index:

CREATE INDEX idx_composite_sales

ON Sales (product_id, sale_date);

4. Creating a Full-Text Index:

CREATE FULLTEXT INDEX idx_fulltext_product_desc

ON Products (product_description);

Managing Indexes

1. Dropping an Index:

DROP INDEX index_name ON table_name;

Example:

DROP INDEX idx_sales_product_id ON Sales;

2. Viewing Indexes:

You can view indexes on a table using:

● MySQL:

SHOW INDEX FROM table_name;

Index Maintenance

1. Rebuilding an Index: Periodically, you may need to

rebuild an index to optimize its performance.

ALTER INDEX index_name REBUILD;

2. Reorganizing an Index: Less intensive than a rebuild, it

defragments the index.

ALTER INDEX index_name REORGANIZE;

No, you generally do not need to run the ALTER INDEX

index_name REBUILD command immediately after adding a new
record. The database management system (DBMS) automatically
updates the indexes when records are inserted, updated, or
deleted to ensure that the indexes remain current and
accurate.
Maintenance: Regular database maintenance tasks often include
index rebuilding to ensure optimal performance.
Performance Issues: If you notice that queries using the index
are performing poorly, rebuilding the index might help improve
performance.

Pros and Cons of Indexing

Pros

1. Faster Query Performance: Indexes greatly speed up search queries, JOIN

operations, and aggregate functions.
2. Efficient Data Retrieval: Makes retrieving data faster, especially in large
databases.

Cons

1. Disk Space: Indexes consume additional disk space.

2. Maintenance Overhead: Indexes need to be maintained and can slow down
INSERT, UPDATE, and DELETE operations because the index must also be
updated.
3. Complexity: Managing many indexes can add complexity to the database
design and maintenance.

When to Use Indexes

1. Primary Keys and Unique Constraints: Always index primary keys and
columns with unique constraints.
2. Foreign Keys: Index foreign keys to speed up JOIN operations.
3. Frequently Queried Columns: Index columns that are frequently used in
WHERE clauses, ORDER BY, and GROUP BY operations.
4. Large Tables: Indexing is especially beneficial for large tables where full table
scans would be inefficient.

Example Use Case

Suppose you have a Sales table and you frequently run queries filtering by
product_id and sorting by sale_date. You can create a composite index to
optimize these queries:
CREATE INDEX idx_sales_product_date
ON Sales (product_id, sale_date);

This index will make the following query faster:

SELECT sale_id, product_id, sale_date, total_price

FROM Sales
WHERE product_id = 101
ORDER BY sale_date;

Conclusion

Indexing is a fundamental aspect of database optimization. Properly designed

indexes can significantly enhance query performance and overall database
efficiency. However, they should be used judiciously to balance the benefits against
the potential drawbacks of increased storage requirements and maintenance
overhead.

Short Code
Table and Index Creation
CREATE TABLE Sales (
sale_id INT PRIMARY KEY AUTO_INCREMENT,
product_id INT,
quantity_sold INT,
sale_date DATE,
total_price DECIMAL(10, 2)
);

CREATE INDEX idx_product_id ON Sales (product_id);

Insert New Record

INSERT INTO Sales (product_id, quantity_sold, sale_date,

total_price)
VALUES (106, 10, '2024-01-04', 300.00);
Index Maintenance (Periodic Task)
-- Periodically run this command to rebuild the index if
needed
ALTER INDEX idx_product_id REBUILD;

By understanding when and why to rebuild indexes, you can maintain optimal
performance for your SQL databases. Regular maintenance ensures that your
indexes remain efficient and queries execute quickly.

Transaction
Understanding transactions in advance is crucial for managing data integrity and consistency
in a database system. Here’s a comprehensive guide to transactions, including their
properties, commands, and practical considerations:

Transactions Overview

A transaction is a sequence of one or more SQL operations that are executed as a single
unit of work. Transactions are used to ensure data integrity and consistency, particularly in
multi-user environments where multiple operations might be occurring simultaneously.

ACID Properties

Transactions are characterized by the ACID properties, which stand for:

1. Atomicity:
○ Definition: Ensures that all operations within a transaction are completed
successfully. If any operation fails, the entire transaction is rolled back, and
the database remains unchanged.
○ Example: In a bank transfer, both the debit from one account and the credit to
another must either both succeed or both fail.
 2. Consistency:
○ Definition: Ensures that a transaction brings the database from one valid
state to another, maintaining all predefined rules and constraints.
○ Example: If a transaction violates a constraint (like exceeding a credit limit),
the transaction is rolled back.
3. Isolation:
○ Definition: Ensures that transactions are executed in isolation from one
another. Intermediate states of a transaction are not visible to other
transactions.
○ Example: Two transactions occurring simultaneously should not interfere with
each other’s operations.
4. Durability:
○ Definition: Ensures that once a transaction is committed, its changes are
permanent, even in the event of a system failure.
○ Example: After a bank transfer is committed, the changes to account
balances remain even if the system crashes immediately afterward.

Transaction Control Commands

1. START TRANSACTION / BEGIN:

○ Purpose: Begins a new transaction.

Syntax:
START TRANSACTION;
-- or
BEGIN;

○
2. COMMIT:
○ Purpose: Saves all changes made during the transaction to the database and
ends the transaction.

Syntax:
sql
Copy code
COMMIT;

○
3. ROLLBACK:
○ Purpose: Reverts all changes made during the transaction and ends the
transaction.

Syntax:
sql
Copy code
ROLLBACK;

○
Transaction Isolation Levels

Different isolation levels control the visibility of data changes made by one transaction to
other concurrent transactions. They balance between performance and data consistency:

1. READ UNCOMMITTED:
○ Allows: Reading uncommitted changes made by other transactions.
○ Prevents: Nothing; prone to dirty reads.
○ Use Case: Rarely used, except in specific cases where performance is critical
and dirty reads are acceptable.
2. READ COMMITTED:
○ Allows: Reading only committed changes made by other transactions.
○ Prevents: Dirty reads.
○ Use Case: Commonly used in many applications to balance performance and
consistency.
3. REPEATABLE READ:
○ Allows: Reading the same set of rows multiple times and seeing the same
data each time.
○ Prevents: Dirty reads, non-repeatable reads.
○ Use Case: Ensures repeatable reads in transactions, useful in banking
systems.
4. SERIALIZABLE:
○ Allows: Each transaction to execute in a fully isolated manner.
○ Prevents: Dirty reads, non-repeatable reads, phantom reads.
○ Use Case: Highest level of isolation, used when absolute consistency is
required.

Practical Example

Here’s an example of a transaction in a sales database:

-- Start a new transaction

START TRANSACTION;

-- Perform some operations

UPDATE Accounts SET balance = balance - 100 WHERE account_id = 1; --
Debit
UPDATE Accounts SET balance = balance + 100 WHERE account_id = 2; --
Credit

-- Commit the transaction if all operations are successful

COMMIT;

-- Rollback the transaction if there’s an error (example for

understanding)
-- ROLLBACK;
Considerations

1. Nested Transactions: Some database systems support nested transactions, where

one transaction is started within another. These need to be managed carefully to
avoid complex rollback scenarios.
2. Savepoints: These are intermediate points within a transaction to which you can roll
back without rolling back the entire transaction. This is useful for complex
transactions.

Syntax:
SAVEPOINT savepoint_name;
-- Rollback to the savepoint
ROLLBACK TO SAVEPOINT savepoint_name;

○
3. Error Handling: Proper error handling ensures that transactions are rolled back in
case of errors. Use try-catch constructs or error-handling mechanisms provided by
your database system.
4. Performance: High isolation levels (like SERIALIZABLE) can impact performance
due to locking mechanisms. Choose the appropriate isolation level based on the
application's consistency requirements and performance needs.

Summary

● Transactions ensure data integrity and consistency through ACID properties.

● Commands: Use START TRANSACTION, COMMIT, and ROLLBACK to manage
transactions.
● Isolation Levels: Control the visibility of changes in concurrent transactions.
● Use Cases: Transactions are crucial in banking, e-commerce, and any application
requiring reliable data operations.

By understanding and correctly implementing transactions, you can ensure your database
operations are reliable, consistent, and maintain data integrity.
 Normalization
Normalization is the process of organizing the fields and tables of a relational
database to minimize redundancy and dependency. It involves decomposing a large
table into smaller tables and defining relationships among them to increase the
clarity and efficiency of the data. The goal of normalization is to eliminate redundant
data and ensure data dependencies make sense, thereby improving data integrity.

Normal Forms

Normalization is carried out in stages, referred to as normal forms (NFs). Each

normal form addresses a specific type of redundancy or anomaly.

1. First Normal Form (1NF)

2. Second Normal Form (2NF)
3. Third Normal Form (3NF)
4. Boyce-Codd Normal Form (BCNF)
5. Fourth Normal Form (4NF)
6. Fifth Normal Form (5NF)
7. Sixth Normal Form (6NF)

First Normal Form (1NF)

A relation is in 1NF if:

● All attributes contain only atomic (indivisible) values.

● There are no repeating groups or arrays.

Example:

javascript
Copy code
StudentID | Name | Courses
----------|---------|---------------
1 | Alice | Math, Physics
2 | Bob | Math, Chemistry

Normalized to 1NF:

StudentID | Name | Course

----------|-------|---------
1 | Alice | Math
1 | Alice | Physics
2 | Bob | Math
2 | Bob | Chemistry

Second Normal Form (2NF)

A relation is in 2NF if:

● It is in 1NF.
● All non-key attributes are fully functionally dependent on the entire primary
key (i.e., there are no partial dependencies).

Example:

mathematica
Copy code
OrderID | ProductID | ProductName | Quantity
--------|-----------|-------------|---------
1 | 101 | Apple | 5
1 | 102 | Banana | 3
2 | 101 | Apple | 2
2 | 103 | Orange | 4
Normalized to 2NF:

mathematica
Copy code
Order(OrderID, ProductID, Quantity)
Product(ProductID, ProductName)

Order:
OrderID | ProductID | Quantity
--------|-----------|---------
1 | 101 | 5
1 | 102 | 3
2 | 101 | 2
2 | 103 | 4

Product:
ProductID | ProductName
----------|-------------
101 | Apple
102 | Banana
103 | Orange

Third Normal Form (3NF)

A relation is in 3NF if:

● It is in 2NF.
● All non-key attributes are non-transitively dependent on the primary key (i.e.,
no transitive dependencies).

Example:

javascript
Copy code
StudentID | Name | DeptID | DeptName | DeptHead
----------|---------|--------|----------|---------
1 | Alice | 10 | Math | Dr. Smith
2 | Bob | 20 | Physics | Dr. Johnson
3 | Charlie | 10 | Math | Dr. Smith
Normalized to 3NF:

scss
Copy code
Student(StudentID, Name, DeptID)
Department(DeptID, DeptName, DeptHead)

Student:
StudentID | Name | DeptID
----------|---------|--------
1 | Alice | 10
2 | Bob | 20
3 | Charlie | 10

Department:
DeptID | DeptName | DeptHead
-------|----------|-----------
10 | Math | Dr. Smith
20 | Physics | Dr. Johnson

Boyce-Codd Normal Form (BCNF)

A relation is in BCNF if:

● It is in 3NF.
● Every determinant is a candidate key.

Example:

diff
Copy code
TeacherID | TeacherName | CourseID | CourseName
----------|-------------|----------|-----------
1 | Mr. Smith | 101 | Math
2 | Ms. Johnson | 102 | Physics
1 | Mr. Smith | 103 | Chemistry

Normalized to BCNF:

Teacher(TeacherID, TeacherName)
Course(CourseID, CourseName)
TeacherCourse(TeacherID, CourseID)

Teacher:
TeacherID | TeacherName
----------|-------------
1 | Mr. Smith
2 | Ms. Johnson

Course:
CourseID | CourseName
---------|------------
101 | Math
102 | Physics
103 | Chemistry

TeacherCourse:
TeacherID | CourseID
----------|----------
1 | 101
2 | 102
1 | 103

Fourth Normal Form (4NF)

A relation is in 4NF if:

● It is in BCNF.
● It has no multi-valued dependencies.

Example:

javascript
Copy code
StudentID | Course | Hobby
----------|----------|--------
1 | Math | Reading
1 | Math | Swimming
2 | Physics | Reading
2 | Chemistry| Swimming
Normalized to 4NF:

scss
Copy code
StudentCourse(StudentID, Course)
StudentHobby(StudentID, Hobby)

StudentCourse:
StudentID | Course
----------|-------
1 | Math
2 | Physics
2 | Chemistry

StudentHobby:
StudentID | Hobby
----------|-------
1 | Reading
1 | Swimming
2 | Reading
2 | Swimming

Fifth Normal Form (5NF)

A relation is in 5NF if:

● It is in 4NF.
● It has no join dependencies.

Example:

css
Copy code
Project | Task | Resource
----------|------------|---------
A | Design | Alice
A | Design | Bob
A | Testing | Alice
B | Design | Charlie
B | Testing | Bob

Normalized to 5NF:

less
Copy code
ProjectTask(Project, Task)
TaskResource(Task, Resource)
ProjectResource(Project, Resource)

ProjectTask:
Project | Task
----------|-----
A | Design
A | Testing
B | Design
B | Testing

TaskResource:
Task | Resource
----------|---------
Design | Alice
Design | Bob
Testing | Alice
Testing | Bob

ProjectResource:
Project | Resource
----------|---------
A | Alice
A | Bob
B | Charlie
B | Bob

Benefits of Normalization

1. Eliminates Redundancy: By dividing large tables into smaller ones,

redundancy is minimized.
 2. Avoids Anomalies: Insert, update, and delete anomalies are avoided.
3. Improves Data Integrity: Dependencies and constraints ensure the
consistency and accuracy of data.
4. Enhanced Performance: Smaller tables with fewer columns improve query
performance.

Drawbacks of Normalization

1. Complex Queries: Joining multiple tables can lead to complex queries.

2. Performance Overhead: Frequent joins can impact performance in large
databases.
3. Over-Normalization: Excessive normalization can lead to a large number of
tables, making the database difficult to manage.

Example with SQL

Step 1: Create Initial Table

sql
Copy code
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
Name VARCHAR(100),
DeptID INT,
DeptName VARCHAR(100),
DeptHead VARCHAR(100)
);

Step 2: Decompose into 2NF

sql
Copy code
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
Name VARCHAR(100),
DeptID INT
);

CREATE TABLE Department (

DeptID INT PRIMARY KEY,
DeptName VARCHAR(100),
 DeptHead VARCHAR(100)
);

Step 3: Decompose into 3NF

sql
Copy code
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
Name VARCHAR(100),
DeptID INT
);

CREATE TABLE Department (

DeptID INT PRIMARY KEY,
DeptName VARCHAR(100)
);

CREATE TABLE DepartmentHead (

DeptID INT PRIMARY KEY,
DeptHead VARCHAR(100)
);

By applying normalization principles, the database design ensures data integrity,

reduces redundancy, and prevents anomalies, leading to a robust and efficient
database system.