Experiment Title:
Case Study and Problem Statement Formula on
Objec ve:
To select a real-life scenario and define a clear, concise, and feasible problem statement based on it.
Apparatus/So ware Required:
Pen & Paper or Word Processor
Internet (op onal for research)
Theory:
A problem statement is the first step in designing any system or solu on. By analyzing a real-world
case study, students learn to iden fy key issues and define the problem clearly to guide
development.
Procedure:
1. Choose a domain (e.g., healthcare, agriculture, educa on).
2. Iden fy a relevant real-world issue.
3. Research exis ng solu ons.
4. Write a problem statement including:
o Background
o Current challenges
o Need for the solu on
5. Review and finalize the statement.
Sample Problem Statement:
Domain: Agriculture
Problem:
"Design an IoT-based irriga on system that uses soil moisture sensors to automate watering, aiming
to reduce water waste and improve crop yield."
Expected Outcome:
A well-defined problem statement based on a relevant real-world case study.
Result:
The student analyzed a case and successfully formulated a valid problem statement.
Experiment Title:
Conceptual Designing using ER Diagrams
Objec ve:
To understand and apply the principles of conceptual database design by crea ng ER diagrams that
include en es, a ributes, keys, rela onships, cardinali es, generaliza on, and specializa on.
Apparatus/So ware Required:
Pen and Paper / ER Diagram Tool (e.g., Draw.io, Lucidchart, Creately)
System with internet (op onal)
Theory:
En ty-Rela onship (ER) modeling is used in database design to visually represent data objects
(en es), their a ributes, and the rela onships between them. The ER diagram helps in
understanding the data structure before implemen ng the database. Key concepts include:
En es: Objects or concepts about which data is stored.
A ributes: Proper es or details of an en ty.
Keys: Uniquely iden fy each en ty (Primary Key).
Rela onships: Connec ons between en es.
Cardinality: Specifies the number of instances in a rela onship (1:1, 1:N, M:N).
Generaliza on: Combining similar en es into a generalized en ty.
Specializa on: Breaking down an en ty into sub-en es with dis nct features.
Procedure:
1. Choose a case study/domain (e.g., Library, Hospital, E-Commerce).
2. Iden fy all en es involved in the system.
3. List a ributes for each en ty and iden fy the primary key.
4. Iden fy rela onships among en es and define cardinali es.
5. Apply generaliza on and specializa on if applicable.
6. Draw the ER diagram using standard nota ons.
7. Submit the final document to the lab teacher.
Expected Outcome:
An ER diagram showing all relevant en es, a ributes, keys, rela onships, and advanced
concepts like generaliza on/specializa on.
Result:
The student successfully designed and submi ed a complete ER diagram based on the selected case
study, demonstra ng a clear understanding of conceptual database design.
Experiment Title:
Conver ng ER Model to Rela onal Model
Objec ve:
To convert an ER (En ty-Rela onship) model into a rela onal model by represen ng en es and
rela onships in tabular format, defining a ributes as columns, and iden fying primary and foreign
keys.
Apparatus/So ware Required:
Pen and Paper / Word Processor
ER Diagram (from previous experiment)
DBMS tool (op onal for prac cal implementa on)
Theory:
The Rela onal Model is a logical structure where data is organized into tables (rela ons). The
conversion process includes:
Crea ng a table for each en ty
Represen ng a ributes as columns
Assigning primary keys to uniquely iden fy each record
Conver ng rela onships into foreign keys or separate tables
Preserving cardinali es and constraints
Steps:
1. Each en ty becomes a table.
2. Each a ribute becomes a column.
3. Primary Key (PK) uniquely iden fies each row.
4. Rela onships become:
o Foreign keys for 1:N or N:1
o Separate tables for M:N with foreign keys from related en es
Procedure:
1. Take the ER diagram from the previous experiment.
2. For each en ty, create a table with a ributes and define the primary key.
3. Analyze rela onships:
o For 1:N or N:1: Add foreign key to the “many” side
o For M:N: Create a new rela on with foreign keys from both en es
4. Represent generaliza on/specializa on using single or mul ple table strategy
5. Document all rela onal tables clearly in tabular form
6. Submit the document to the lab teacher
Expected Outcome:
Rela onal schema with all tables, columns, keys, and rela onships accurately derived from the ER
diagram.
Result:
The student successfully converted the ER model into rela onal tables and documented the
structure, demonstra ng understanding of database design principles.
Experiment Title:
Normaliza on up to Third Normal Form (3NF)
Objec ve:
To eliminate data redundancy and anomalies in rela onal tables by applying normaliza on rules up
to the Third Normal Form (3NF).
Apparatus/So ware Required:
Pen and Paper / Word Processor
Tables generated from ER-to-Rela onal conversion
DBMS tool (op onal)
Theory:
Normaliza on is the process of organizing data in a database to reduce redundancy and improve
data integrity. It involves dividing large tables into smaller ones and defining rela onships among
them.
Normal Forms:
1NF (First Normal Form):
Remove repea ng groups; ensure atomic values.
2NF (Second Normal Form):
Must be in 1NF; remove par al dependencies (i.e., non-prime a ributes fully depend on the
whole primary key).
3NF (Third Normal Form):
Must be in 2NF; remove transi ve dependencies (i.e., non-prime a ributes should not
depend on other non-prime a ributes).
Procedure:
1. Start with unnormalized or original tables from ER-to-Rela onal model.
2. Apply 1NF: Ensure atomic values in all a ributes.
3. Apply 2NF:
o Iden fy par al dependencies
o Create new tables for dependent a ributes
4. Apply 3NF:
o Iden fy transi ve dependencies
o Decompose the tables accordingly
5. Clearly write the resul ng normalized tables a er each step.
6. Submit the document showing each stage of normaliza on.
Expected Outcome:
Normalized tables in 1NF, 2NF, and finally in 3NF with reduced redundancy and no
inser on/update/dele on anomalies.
Result:
The student successfully normalized the given rela onal schema up to 3NF and demonstrated a clear
understanding of func onal dependencies and table decomposi on.
Experiment Title:
Crea on of Tables Using SQL
Objec ve:
To understand SQL basics and perform table crea on, including the use of appropriate data types,
se ng primary and foreign keys, altering exis ng tables, and dropping tables using SQL commands.
Apparatus/So ware Required:
SQL Tool (MySQL, Oracle, PostgreSQL, or SQLite)
SQL Editor or Command Line Interface
Theory:
SQL (Structured Query Language) is used to manage and manipulate rela onal databases. This
experiment focuses on the DDL (Data Defini on Language) commands which include:
CREATE TABLE: Define new tables with specified columns and data types
PRIMARY KEY: Uniquely iden fies each record
FOREIGN KEY: Establishes rela onships between tables
ALTER TABLE: Modify the structure of an exis ng table
DROP TABLE: Delete a table from the database
Common SQL Data Types:
INT, VARCHAR(n), DATE, FLOAT, BOOLEAN, etc.
Procedure:
1. Open the SQL tool or DBMS interface.
2. Use the CREATE TABLE statement to define en es with columns and data types.
3. Set PRIMARY KEY for unique iden fica on.
4. Set FOREIGN KEY to define rela onships between tables.
5. Use ALTER TABLE to add, modify, or delete columns or constraints.
6. Use DROP TABLE to remove unwanted tables.
7. Verify results using DESC tablename; and SELECT queries.
Sample SQL Commands:
sql
CopyEdit
-- Create Customer table
CREATE TABLE Customer (
CustomerID INT PRIMARY KEY,
Name VARCHAR(100),
Email VARCHAR(100)
);
-- Create Orders table with Foreign Key
CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
OrderDate DATE,
CustomerID INT,
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);
-- Alter table to add a column
ALTER TABLE Customer ADD Phone VARCHAR(15);
-- Drop table
DROP TABLE Orders;
Expected Outcome:
Students will be able to write and execute SQL commands for table crea on, define keys, alter
structures, and delete tables effec vely.
Result:
The student successfully created, modified, and dropped tables using SQL commands and
demonstrated understanding of SQL data defini on opera ons.
Experiment Title:
Prac cing DML Commands – INSERT, SELECT, UPDATE, DELETE
Objec ve:
To learn and prac ce Data Manipula on Language (DML) commands in SQL to insert, retrieve,
update, and delete data from database tables.
Apparatus/So ware Required:
SQL Tool (MySQL, Oracle, PostgreSQL, SQLite, etc.)
SQL Editor or Command Line Interface
Previously created database tables
Theory:
DML (Data Manipula on Language) is used to manage data within tables in a rela onal database.
Key DML commands include:
INSERT – Adds new records to a table
SELECT – Retrieves data from a table
UPDATE – Modifies exis ng data
DELETE – Removes records from a table
These opera ons allow users to manage and interact with stored data effec vely.
Procedure:
1. Open your SQL interface and connect to the database.
2. Use the INSERT command to add data into the tables.
3. Use the SELECT command to view data.
4. Use the UPDATE command to modify specific values.
5. Use the DELETE command to remove specific records.
6. Use SELECT * FROM tablename; a er each opera on to verify changes.
Sample SQL Commands:
sql
CopyEdit
-- Insert data into Customer table
INSERT INTO Customer (CustomerID, Name, Email)
-- Select all customers
SELECT * FROM Customer;
-- Update customer name
UPDATE Customer
SET Name = 'Ravi Sharma'
WHERE CustomerID = 1;
-- Delete a customer
DELETE FROM Customer
WHERE CustomerID = 1;
Expected Outcome:
Students will be able to insert, retrieve, update, and delete records from database tables using
appropriate DML commands.
Result:
The student successfully performed DML opera ons and validated the changes using SELECT queries.
Experiment Title:
Prac cing Queries using ANY, ALL, IN, EXISTS, NOT EXISTS, UNION, INTERSECT, and Constraints
Objec ve:
To execute SQL queries using subquery operators and set opera ons, and apply constraints to
enforce data integrity.
Apparatus/So ware Required:
SQL Tool (MySQL/PostgreSQL/etc.)
Command-line or SQL Editor
Theory:
IN, ANY, ALL: Used in subqueries to filter results.
EXISTS / NOT EXISTS: Check for the presence or absence of rows in a subquery.
UNION / INTERSECT: Combine or find common rows between queries.
Constraints: Rules applied to columns (e.g., PRIMARY KEY, FOREIGN KEY, CHECK).
Procedure:
1. Use sample tables (e.g., Customer, Orders).
2. Write and run queries using IN, ANY, ALL, EXISTS, NOT EXISTS.
3. Apply UNION or simulate INTERSECT.
4. Add constraints using CREATE or ALTER TABLE.
5. Observe and verify outputs.
Sample Queries:
sql
CopyEdit
SELECT Name FROM Customer WHERE CustomerID IN (1, 2, 3);
SELECT Name FROM Customer c
WHERE EXISTS (SELECT * FROM Orders o WHERE o.CustomerID = c.CustomerID);
SELECT * FROM Product
WHERE Price > ALL (SELECT Price FROM Product WHERE CategoryID = 3);
ALTER TABLE Customer ADD CONSTRAINT chk_email CHECK (Email LIKE '%@%');
Expected Outcome:
Students will understand and use advanced SQL query constructs and constraints.
Result:
The student prac ced and successfully executed complex SQL queries and applied constraints.
Experiment Title:
Prac cing Subqueries (Nested, Correlated) and Joins (Inner, Outer, and Equi)
Objec ve:
To execute SQL queries using subqueries (nested and correlated) and various types of joins (inner,
outer, equi) to retrieve data from mul ple related tables.
Apparatus/So ware Required:
SQL Tool (MySQL, PostgreSQL, Oracle, etc.)
Sample rela onal tables (e.g., Customer, Orders, Product)
Theory:
Nested Subquery: A subquery executed once and its result is used by the outer query.
Correlated Subquery: A subquery that references columns from the outer query; executed
for each row.
Joins:
o Inner Join: Returns matching rows from both tables.
o Outer Join:
Le Outer Join: All rows from the le table and matched rows from the
right.
Right Outer Join: All rows from the right table and matched rows from the
le .
o Equi Join: A type of inner join using equality (=) in the condi on.
Procedure:
1. Use sample tables with rela onships (e.g., Orders with CustomerID).
2. Write and execute:
o Nested subqueries using IN, =, etc.
o Correlated subqueries using EXISTS, etc.
3. Perform INNER, LEFT OUTER, RIGHT OUTER, and EQUI joins.
4. Use SELECT to verify results.
Sample Queries:
sql
CopyEdit
-- Nested Subquery
SELECT Name FROM Customer
WHERE CustomerID IN (SELECT CustomerID FROM Orders WHERE TotalAmount > 500);
-- Correlated Subquery
SELECT Name FROM Customer c
WHERE EXISTS (SELECT * FROM Orders o WHERE o.CustomerID = c.CustomerID);
-- Inner Join
SELECT c.Name, o.OrderDate FROM Customer c
INNER JOIN Orders o ON c.CustomerID = o.CustomerID;
-- Le Outer Join
SELECT c.Name, o.OrderDate FROM Customer c
LEFT JOIN Orders o ON c.CustomerID = o.CustomerID;
-- Equi Join
SELECT * FROM Product p, Category c
WHERE p.CategoryID = c.CategoryID;
Expected Outcome:
Students will understand and apply subqueries and joins to retrieve meaningful data across mul ple
tables.
Result:
The student executed various types of subqueries and joins successfully on sample rela onal tables.
Experiment Title:
Prac ce Queries using COUNT, SUM, AVG, MAX, MIN, GROUP BY, HAVING, VIEWS Crea on and
Dropping
Objec ve:
To perform aggregate func ons and work with grouped data and views in SQL.
Tools Required:
SQL RDBMS (MySQL/PostgreSQL/etc.)
SQL tool or terminal
Theory:
Aggregate Func ons:
COUNT(), SUM(), AVG(), MAX(), MIN() operate on data columns.
GROUP BY: Groups rows with same values (e.g., by department).
HAVING: Filters groups (used a er GROUP BY).
VIEWS: Virtual tables created using CREATE VIEW and removed using DROP VIEW.
Procedure:
1. Create Table:
sql
CopyEdit
CREATE TABLE Employees (
EmpID INT PRIMARY KEY,
Name VARCHAR(50),
Department VARCHAR(50),
Salary INT
);
2. Insert Data:
sql
CopyEdit
INSERT INTO Employees VALUES (1, 'Amit', 'HR', 40000),
(2, 'Rita', 'IT', 60000),
(3, 'John', 'IT', 55000);
3. Aggregate Queries:
sql
CopyEdit
SELECT COUNT(*) FROM Employees;
SELECT SUM(Salary), AVG(Salary) FROM Employees;
SELECT MAX(Salary), MIN(Salary) FROM Employees;
4. Group and Filter:
sql
CopyEdit
SELECT Department, COUNT(*) FROM Employees GROUP BY Department;
SELECT Department, AVG(Salary) FROM Employees GROUP BY Department HAVING AVG(Salary) >
50000;
5. Views:
sql
CopyEdit
CREATE VIEW HighEarners AS
SELECT Name, Salary FROM Employees WHERE Salary > 50000;
SELECT * FROM HighEarners;
DROP VIEW HighEarners;
Expected Output:
Results for aggregate and grouped queries.
View created and dropped successfully.
Result:
Learned SQL aggregate func ons, grouping, filtering, and use of views.
Experiment Title:
Prac cing on Triggers – Crea on, Inser on, Dele on, and Upda ng using Trigger
Objec ve:
To understand and implement SQL triggers for automa ng ac ons during insert, update, and delete
opera ons.
Tools Required:
SQL-compa ble RDBMS (e.g., MySQL, PostgreSQL, Oracle)
SQL command-line or GUI (like MySQL Workbench)
Theory:
Trigger: A database object that is automa cally invoked when a specified event occurs.
Types of Triggers:
o BEFORE or AFTER INSERT
o BEFORE or AFTER UPDATE
o BEFORE or AFTER DELETE
Triggers are useful for enforcing business rules, maintaining logs, or preven ng invalid data changes.
Procedure:
1. Create Main Table:
sql
CopyEdit
CREATE TABLE Students (
ID INT PRIMARY KEY,
Name VARCHAR(50),
Marks INT
);
2. Create Log Table:
sql
CopyEdit
CREATE TABLE Audit_Log (
Ac onType VARCHAR(20),
Ac onTime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
3. Create Trigger for INSERT:
sql
CopyEdit
CREATE TRIGGER a er_insert_student
AFTER INSERT ON Students
FOR EACH ROW
INSERT INTO Audit_Log(Ac onType) VALUES ('INSERT');
4. Create Trigger for DELETE:
sql
CopyEdit
CREATE TRIGGER a er_delete_student
AFTER DELETE ON Students
FOR EACH ROW
INSERT INTO Audit_Log(Ac onType) VALUES ('DELETE');
5. Create Trigger for UPDATE:
sql
CopyEdit
CREATE TRIGGER a er_update_student
AFTER UPDATE ON Students
FOR EACH ROW
INSERT INTO Audit_Log(Ac onType) VALUES ('UPDATE');
6. Test Triggers:
o Insert data into Students
o Update a row
o Delete a row
o Check entries in Audit_Log
Expected Output:
Triggers should fire on respec ve ac ons and log entries should be created in Audit_Log.
Result:
Successfully implemented and tested INSERT, UPDATE, and DELETE triggers in SQL.