UNIT– III

SQL: QUERIES, CONSTRAINTS, TRIGGERS: form of basic SQL query, UNION, INTERSECT,
and EXCEPT, Nested Queries, aggregation operators, NULL values, complex integrity constraints in
SQL, triggers and active databases.

Schema Refinement: Problems caused by redundancy, decompositions, problems related to

decomposition, reasoning about functional dependencies, FIRST, SECOND, THIRD normal forms,
BCNF, lossless join decomposition, multi-valued dependencies, FOURTH normal form, FIFTH normal
form.

1.​ SQLCOMMANDS
Structured Query Language (SQL) is the database language used to create a database and
to perform operations on the existing database. SQL commands are instructions used to
communicate with the database to perform specific tasks and queries with data. These SQL
commands are categorized into five categories as:

i.​ DDL: Data Definition Language

ii.​ DML: Data Manipulation Language
iii.​ DQL: Data Query Language
iv.​ DCL: Data Control Language
v.​ TCL: Transaction Control Language.

●​ DDL (Data Definition Language): DDL or Data Definition Language consists

 of the SQL commands that can be used to define the database schema. It simply
deals with descriptions of the database schema and is used to create and modify the
structure of database objects in the database. The DQL commands are:

●​ CREATE: It is used to create the database or its objects (like table, index, function,
views, store procedure and triggers).
●​ DROP: It is used to delete objects from the database.
●​ ALTER: It is used to alter the structure of the database.
●​ TRUNCATE: It is used to remove all records values from a table, including all
spaces allocated for the records are removed.
ii.​ DQL (Data Query Language):. The purpose of DQL Command is to get data from some
schema relation based on the query passed to it.
The DQL commands are:
●​ SELECT–is used to retrieve data from the database.

iii.​ DML (Data Manipulation Language): The SQL commands that deals with the
manipulation of data present in the database belong to DML or Data Manipulation Language
and this includes most of the SQL statements. The DML commands are:

●​ INSERT–is used to insert data into a table.

●​ UPDATE– is used to update existing data within a table.
●​ DELETE–is used to delete records from a database table.
●​ SELECT–is used to retrieve data from the database.

iv.​ DCL (Data Control Language): DCL includes commands which mainly deal with the
rights, permissions and other controls of the database system. The DCL commands are:
●​ GRANT-gives user’s access privileges to database.
●​ REVOKE-withdraw user’s access privileges given by using the GRANT command.
v.​ TCL (transaction Control Language):TCL commands deals with the transaction within
the database. The TCL commands are:
●​ COMMIT–commits a Transaction.
●​ ROLLBACK–rollbacks transaction in case of any error occurs.
●​ SAVEPOINT–sets a save point with in a transaction.

SET OPERATIONS:
 UNION, INTERSECT, EXCEPT
There are mainly three set operations: UNION, INTERSECT, EXCEPT. You can refer to the
image below to understand the set operations in SQL.

●​ UNION: Combine two or more result sets into a single set, without duplicates.

●​ UNION ALL: Combine two or more result sets into a single set, including all duplicates.

●​ INTERSECT: Takes the data from both result sets which are in common

●​ EXCEPT: Takes the data from the first result set, but not in the second result set (i.e. no matching to
each other)

Rules on Set Operations:

1.​ The result sets of all queries must have the same number of columns.

2.​ In every result set the data type of each column must be compatible (well matched) to the data type of
its corresponding column in other result sets.

Table A

Table B
UNION Operator:

The Union operator will return all the unique rows from both the queries. Notice that the duplicates are removed
from the result set.

SELECT ID, Name, Gender, Department FROM Table A

UNION

SELECT ID, Name, Gender, Department FROM Table B

UNION ALL Operator:

The UNION ALL operator returns all the rows from both the queries, including the duplicates.

SELECT ID, Name, Gender, Department FROM Table A

UNION ALL

SELECT ID, Name, Gender, Department FROM Table B

INTERSECT Operator:
The INTERSECT operator retrieves the common unique rows from both the left and the right query. Notice the duplicates
are removed.

SELECT ID, Name, Gender, Department FROM Table A

INTERSECT

SELECT ID, Name, Gender, Department FROM Table B

EXCEPT Operator:

The EXCEPT operator will return unique rows from the left query that aren’t present in the right query’s results.

SELECT ID, Name, Gender, Department FROM Table A

EXCEPT

SELECT ID, Name, Gender, Department FROM Table B

If you want the rows that are present in Table B but not in Table A, reverse the queries.

SELECT ID, Name, Gender, Department FROM Table B

EXCEPT

SELECT ID, Name, Gender, Department FROM Table A

Note: UNION, INTERSECT or EXCEPT operations are possible if and only if first SELECT query and second SELECT
query produces same no of columns in same order, same column names and data type. Otherwise it gives an error.
AGGREGATE FUNCTIONS:
The SQL allows summarizing data through a set of functions called aggregate functions

The commonly used aggregate functions are

1.​ count()
2.​ Sum()
3.​ Avg()
4.​ Min()
5.​ Max()

Example Student Table

+-----+---------+------------+--------+--------+
| sid | sname | percentage | gender | branch |
+-----+---------+------------+--------+--------+
| 101 | hari | 99 | male | csm |
| 102 | deepu | 90 | female | ece
| 103 | pujith | 95 | male | csm |
| 104 | asritha | 78 | female csm |
| 105 | tarun | 88 | male | civil |
| 106 | mounika | 98 | female | EEE |
+-----+---------+------------+--------+--------+

1. count() : It returns number of rows which match specified criteria

Syntax: select count(columnname) from tablename;

Example 1 : Count the number of students.

mysql>select count(sname) from student; ​

+-----------------+
| count(sname) |
+-----------------+
| 6 |
+-----------------+

Example 2 : Count the number of branch.

mysql>select count(branch) from student;

+---------------+
| count(branch) |
+---------------+
| 6 |
+---------------+
Example 3 : Count the number of distinct branch.

Mysql> select count(distinct branch) from student;

+------------------------+
| count(distinct branch) |
+------------------------+
| 4 |
+------------------------+

Example 4 : Count the number of students with *.

Mysql> select count(*) from student;

+----------+
| count(*) |
+----------+
| 6 |
+----------+

2 .Sum () : The sum function returns the total sum of a numeric column that you choose

Syntax: select sum(columnname) from tablename;

Example : Find the sum of total percentage of all students.

Mysql> select sum(percentage) from student;

+-----------------+
| sum(percentage) |
+-----------------+
| 548 |
+-----------------+
3.average () : The average function returns the average value of a numeric column that you choose

Syntax: select avg(columnname) from tablename;

Example : Find the average percentage of all students.

Mysql> select avg(percentage) from student;

+-----------------+
| avg(percentage) |
+-----------------+
| 91.3333 |
+-----------------+

4.min() function: The min function returns the smallest value of the selected column in a table.

Syntax: select min(columnname) from tablename;

Example : Find the minimun percentage from all students.

Mysql> select min(percentage) from student;

+-----------------+
| min(percentage) |
+-----------------+
| 78 |
+-----------------+

5.max() function: The max function returns the largest value of the selected column in a table.

Example : Find the maximum percentage from all students.

Mysql> select max (percentage) from student;

+-----------------+
| max(percentage) |
+-----------------+
| 99 |
+-----------------+
NESTEDQUERIES
Nested queries are those queries which have an outer query and inner subquery. So, basically,
the sub query is a query which is nested within another query. They allow us to execute a query
within another query, making it easier to handle complex data operations. Nested queries are
commonly used for filtering data, performing calculations, or joining datasets indirectly.

Key Characteristics:

1.​ The inner query runs before the outer query.

2.​ The result of the inner query can be used by the outer query for comparison or as input data.
3.​ Nested queries are particularly useful for breaking down complex problems into smaller, manageable parts, making it easier
to retrieve specific results from large datasets.

Syntax of Nested Queries

The basic syntax of a nested query involves placing one query inside of another query. Inner query or subquery is
executed first and returns a set of values that are then used by the outer query. The syntax for a nested query is as follows:
SELECT column1, column2...
FROM table1
WHERE column1 OPERATOR (SELECT column1
FROM table2
WHERE condition);

Operators Used in Independent Nested Queries

IN Operator
This operator checks if a column value in the outer query's result is present in the inner query's result. The final
result will have rows that satisfy the IN condition.
NOT IN Operator
This operator checks if a column value in the outer query's result is not present in the inner query's result. The
final result will have rows that satisfy the NOT IN condition.
ALL Operator
This operator compares a value of the outer query's result with all the values of the inner query's result and
returns the row if it matches all the values.
ANY Operator
This operator compares a value of the outer query's result with all the inner query's result values and returns the
row if there is a match with any value.

EXISTS Operator
This operator checks whether a subquery returns any row. If it returns at least one row. EXISTS operator returns
true, and the outer query continues to execute. If the subquery returns no row, the EXISTS operator returns
false, and the outer query stops execution.
NOT EXISTS Operator
This operator checks whether a subquery returns no rows. If the subquery returns no row, the NOT EXISTS
operator returns true, and the outer query continues to execute. If the subquery returns at least one row, the
NOT EXISTS operator returns false, and the outer query stops execution.
NULL Values

A field with a NULL value is a field with no value.

If a field in a table is optional, it is possible to insert a new record or update a record without adding a value to this field. Then, the
field will be saved with a NULL value.

It is not possible to test for NULL values with comparison operators, such as =, <, or <>.

We will have to use the IS NULL and IS NOT NULL operators instead.

IS NULL Syntax

SELECT column_names​
FROM table_name​
WHERE column_name IS NULL;

IS NOT NULL Syntax

SELECT column_names​
FROM table_name​
WHERE column_name IS NOT NULL;

Example

Let us create a table with the name CUSTOMERS in the SQL database using the CREATE statement as shown in
the query below −
​
CREATE TABLE CUSTOMERS (
ID INT NOT NULL,
NAME VARCHAR (20) NOT NULL,
AGE INT NOT NULL,
ADDRESS CHAR (25),
SALARY INT,
PRIMARY KEY (ID)
);

Let us insert some values into the above created table using the following query −INSERT INTO
CUSTOMERS VALUES
(1, 'Ramesh', 32, 'Ahmedabad', 2000),
(2, 'Khilan', 25, 'Delhi', 1500),
(3, 'Kaushik', 23, 'Kota', 2000),
(4, 'Chaitali', 25, 'Mumbai', 6500),
(5, 'Hardik', 27, 'Bhopal', 8500),
(6, 'Komal', 22, 'Hyderabad', NULL),
(7, 'Muffy', 24, 'Indore', NULL);

The table is successfully created in the database.

ID NAME AGE ADDRESS SALARY

1 Ramesh 32 Ahmedabad 2000

2 Khilan 25 Delhi 1500

3 Kaushik 23 Kota 2000

4 Chaitali 25 Mumbai 6500

5 Hardik 27 Bhopal 8500

6 Komal 22 Hyderabad NULL

7 Muffy 24 Indore NULL

Now, let us retrieve the records present in the table that are not null using the IS NOT NULL
operator −

SELECT ID, NAME, AGE, ADDRESS, SALARY

FROM CUSTOMERS
WHERE SALARY IS NOT NULL;

The above query would produce the following result −

ID NAME AGE ADDRESS SALARY

1 Ramesh 32 Ahmedabad 2000

2 Khilan 25 Delhi 1500

3 Kaushik 23 Kota 2000

4 Chaitali 25 Mumbai 6500

5 Hardik 27 Bhopal 8500

You can also retrieve the NULL records present in the table using IS NULL operator in the SELECT
query as shown below −
SELECT ID, NAME, AGE, ADDRESS, SALARY
FROM CUSTOMERS WHERE SALARY IS NULL;

The above query would produce the following result −

ID NAME AGE ADDRESS SALARY

6 Komal 22 Hyderabad NULL

7 Muffy 24 Indore NULL

Complex Integrity Constraints

In SQL, integrity constraints are rules that ensure data integrity in a database. They can be classified into two
categories: simple and complex.

Simple integrity constraints include primary keys, unique constraints, and foreign keys. These constraints
ensure that data in a table is unique and consistent, and they prevent certain operations that would violate these
rules.

On the other hand, complex integrity constraints are more advanced rules that cannot be expressed using simple
constraints. They are typically used to enforce business rules, such as limiting the range of values that can be
entered into a column or ensuring that certain combinations of values are present in a table.

There are several ways to implement complex integrity constraints in SQL, including:

1. Check Constraints: Check constraints are used to restrict the range of values that can be entered into a
column. For example, a check constraint can be used to ensure that a date column only contains dates in a
certain range.

CREATE TABLE Employee (​

ID INT PRIMARY KEY,​
Name VARCHAR(50),​
Age INT,​
Salary DECIMAL(10,2),​
CONSTRAINT CHK_Age CHECK (Age >= 18 AND Age <= 65),​
CONSTRAINT CHK_Salary CHECK (Salary >= 0)​
);​

In this example, we are creating a table called "Employee" with columns for ID, Name, Age, and Salary. We
have added two check constraints, one to ensure that the age is between 18 and 65, and another to ensure that
the salary is greater than or equal to 0.

2. Assertions: Assertions are used to specify complex rules that cannot be expressed using simple constraints.
They are typically used to enforce business rules, such as ensuring that a customer's age is greater than a certain
value.
CREATE TABLE Customer (​
ID INT PRIMARY KEY,​
Name VARCHAR(50),​
Age INT,​
Gender VARCHAR(10),​
CONSTRAINT CHK_Age CHECK (Age >= 18),​
CONSTRAINT CHK_Gender CHECK (Gender IN ('M', 'F')),​
CONSTRAINT CHK_Female_Age CHECK (Gender <> 'F' OR Age >= 21)​
);​

In this example, we are creating a table called "Customer" with columns for ID, Name, Age, and Gender. We
have added three constraints: one to ensure that the age is greater than or equal to 18, another to ensure that the
gender is either "M" or "F", and a third to ensure that if the gender is "F", the age is greater than or equal to 21.

3. Triggers: Triggers are special procedures that are executed automatically in response to certain events, such
as an insert or update operation on a table. Triggers can be used to implement complex business rules that
cannot be expressed using simple constraints.

TRIGGERS
A database trigger is a stored program which is automatically fired or executed when some events occur. A trigger can be
invoked either BEFORE or AFTER the data is changed by INSERT, UPDATE or DELETE statement.

Syntax:
CREATE TRIGGER [TriggerName]
[BEFORE | AFTER]
{INSERT | UPDATE | DELETE}
on [TableName]
[FOR EACH ROW]

[TriggerBody]

Types of triggers
BEFORE INSERT TRIGGER

The following is the syntax to create a BEFORE INSERT trigger in MySQL:

CREATE TRIGGER trigger_name
BEFORE INSERT
ON table_name FOR EACH ROW
Trigger_body;

Let us understand how to create a BEFORE INSERT trigger using the CREATE TRIGGER statement in
MySQL with an example.
Suppose we have created a table named employee as follows:
CREATE TABLE employee
(Name varchar (45) NOT NULL,
occupation varchar(35) NOT NULL,
Working_date date,
Working_hours varchar (10)
);
Next, we will insert some records into the employee table and then execute the SELECT statement to see the table data as
follows:
 mysql>DELIMITER //
mysql>Create Trigger before_insert_occupation
BEFORE INSERT ON employee FOR EACH ROW
BEGIN
IF NEW.occupation='Scientist' THEN SET NEW.occupation='Doctor';
END IF;
END //

mysql> INSERT INTO employee VALUES

('Markus','Scientist',’2020-10-08', 14);

mysql>INSERT INTO employee VALUES

('Alexander','Actor','2020-10-012',13);

In this

output, we can see that on inserting the occupation column values as 'Scientist', the table will automatically fill
the 'Doctor' value by invoking a trigger.

AFTER INSERT TRIGGER

Let us understand how to create an AFTER INSERT trigger using the CREATE TRIGGER statement in MySQL with an
example.

mysql> CREATE TABLE student_info (

stud_id int NOT NULL,
stud_code varchar(15) DEFAULT NULL,
stud_name varchar(35) DEFAULT NULL,
subject varchar(25) DEFAULT NULL,
marks int DEFAULT NULL,
phone varchar(15) DEFAULT NULL,
PRIMARY KEY (stud_id)
 ) ;

MySQL> insert into student_info values(1,101,'mark','english',68,34569357);

MySQL> insert into student_info values(2,102,'joseph','physics',70,98674536);

MySQL> insert into student_info values(3,103,'john','maths',70,97896958);

MySQL> insert into student_info values(4,104,'barack','maths',90,8786868);

MySQL> insert into student_info values(5,105,'rinky','maths',85,678465);

MySQL> insert into student_info values(6,106,'adam','science',92,4747848);

MySQL> insert into student_info values(7,107,'andrew','science',83,56742456);

MySQL> insert into student_info values(8,108,'brayan','science',85,76767654);

MySQL> select * from student_info;

MySQL> CREATE TABLE student_detail (

-> stud_id int NOT NULL,
-> stud_code varchar(15) ,
-> stud_name varchar (35) ,
-> subject varchar(25) ,
-> marks int,
-> phone varchar (15) ,
-> Lastinserted Time,
-> PRIMARY KEY (stud_id)
-> );

Mysql> DELIMITER //

MySQL> Create Trigger after_insert_details

-> AFTER INSERT ON student_info FOR EACH ROW
-> BEGIN
-> INSERT INTO student_detail VALUES (new.stud_id, new.stud_code,
-> new.stud_name, new.subject, new.marks, new.phone, CURTIME());
 -> END //

MySQL> INSERT INTO student_info VALUES

-> (10, 110, 'Alexandar', 'Biology', 67, '2347346438');
-> //

MySQL> SELECT * FROM student_detail;

-> //

BEFORE UPDATE Trigger

Let us understand how to create a BEFORE UPDATE trigger using the CREATE TRIGGER statement in MySQL with an
example.
Suppose we have created a table named sales_info as follows:
CREATE TABLE sales_info (
id INT AUTO_INCREMENT,
product VARCHAR(100) NOT NULL,
quantity INT NOT NULL DEFAULT 0,
fiscalYear SMALLINT NOT NULL,
CHECK(fiscalYear BETWEEN 2000 and 2050),
CHECK (quantity >=0),
UNIQUE(product, fiscalYear),
PRIMARY KEY(id)
);

Next, we will insert some records into the sales_info table as follows:
INSERT INTO sales_info(product, quantity, fiscalYear)
VALUES
('2003 Maruti Suzuki',110, 2020),
('2015 Avenger', 120,2020),
('2018 Honda Shine', 150,2020),
('2014 Apache', 150,2020);
Then, execute the SELECT statement to see the table data as follows:
Next, we will use a CREATE TRIGGER statement to create a BEFORE UPDATE trigger. This trigger is invoked
automatically before an update event occurs in the table.
​DELIMITER $$
​
​CREATE TRIGGER before_update_salesInfo
​BEFORE UPDATE
​ON sales_info FOR EACH ROW
​BEGIN
​ DECLARE error_msg VARCHAR(255);
​ SET error_msg = ('The new quantity cannot be greater than 2 times the current quantity');
​ IF new.quantity > old.quantity * 2 THEN
​ SIGNAL SQLSTATE '45000'
​ SET MESSAGE_TEXT = error_msg;
​ END IF;
​END $$

First, we can use the following statements that update the quantity of the row whose id = 2:

mysql> UPDATE sales_info SET quantity = 125 WHERE id = 2;

This statement works well because it does not violate the rule. Next, we will execute the below statements that
update the quantity of the row as 600 whose id = 2
mysql> UPDATE sales_info SET quantity = 600 WHERE id = 2;
It will give the error as follows because it violates the rule.
 AFTER UPDATE Trigger

create table sales

(id integer,
product varchar(20),
quantity int,
fiscal_year int,
fiscal_month int ,
check(fiscal_month >=1 and fiscal_month<=12),
check(fiscal_year between 2000 and 2050),
primary key (id));

insert into sales values(1,'Honda',140,2020,1);

insert into sales values(2,'Suzuki',120,2020,1);
insert into sales values(3,'KIA',150,2020,1);

mysql> select * from sales;

+----+---------+----------+-------------+--------------+
| id | product | quantity | fiscal_year | fiscal_month |
+----+---------+----------+-------------+--------------+
| 1 | Honda | 140 | 2020 | 1|
| 2 | Suzuki | 120 | 2020 | 1|
| 3 | KIA | 150 | 2020 | 1|
+----+---------+----------+-------------+--------------+
create table saleschanges (
-> id int Auto_increment,
salesid int,
beforequantity int,
afterquantity int,
changedAt timestamp,
primary key(id));

mysql> create trigger after_sales_updates after update on sales for each row
begin
if old.quantity <> new.quantity then
insert into saleschanges(salesid,beforequantity,afterquantity)
values(old.id,old.quantity,new.quantity);
end if;
end//
Query OK, 0 rows affected (0.01 sec)
mysql> update sales set quantity=350 where id=1;
-> //
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from salechanges;

-> //
+----+---------+----------------+---------------+---------------------+
| id | salesid | beforequantity | afterquantity | changedAt |
+----+---------+----------------+---------------+---------------------+
| 1| 1| 140 | 350 | 2023-08-17 16:52:50 |
+----+---------+----------------+---------------+---------------------+
1 row in set (0.00 sec)
BEFORE DELETE Trigger
Let us understand how to create a BEFORE DELETE trigger using the CREATE TRIGGER statement in
MySQL with an example.
Suppose we have created a table named salaries to store the salary information of an employee as follows:
CREATE TABLE salaries (
emp_num INT PRIMARY KEY,
valid_from DATE NOT NULL,
amount int NOT NULL DEFAULT 0
);

Next, we will insert some records into this table using the below statement:

INSERT INTO salaries (emp_num, valid_from, amount) VALUES

(102, '2020-01-10', 45000),

(103, '2020-01-10', 65000),

(105, '2020-01-10', 55000),

(107, '2020-01-10', 70000),

(109, '2020-01-10', 40000);

Third, we will create another table named salary_archives that keeps the information of deleted salary.

CREATE TABLE salary_archives (

id INT PRIMARY KEY AUTO_INCREMENT,
emp_num INT,
valid_from DATE NOT NULL,
amount FLOAT NOT NULL DEFAULT 0,
deleted_time TIMESTAMP DEFAULT NOW()
);

We will then create a BEFORE DELETE trigger that inserts a new record into the salary_archives table before a
row is deleted from the salaries table.

DELIMITER $$
CREATE TRIGGER before_delete_salaries
BEFORE DELETE
ON salaries FOR EACH ROW
BEGIN
INSERT INTO salary_archives (emp_num, valid_from, amount)
VALUES (OLD. emp_num, OLD.valid_from, OLD.amount);
END$$

Let us test the above created BEFORE DELETE trigger and how we can call them. So first, we will remove a
row from the salaries table:
mysql> DELETE FROM salaries WHERE emp_num = 105;
After executing a statement, we can see that the trigger was invoked successfully and inserted a new record into the
salary_archives table.
Third, we will remove all rows from the salaries table:
mysql> DELETE FROM salaries;
Finally, we will query data from the salary_archives table again. The trigger was called four times because the DELETE
statement removed four records from the salaries table. See the below output:

AFTER DELETE Trigger

Let us understand how to create an AFTER DELETE trigger using the CREATE TRIGGER statement in MySQL with
an example.
Suppose we have created a table named salaries to store the salary information of an employee as follows:
CREATE TABLE salaries (
emp_num INT PRIMARY KEY,
valid_from DATE NOT NULL,
amount FLOAT NOT NULL DEFAULT 0
);
Next, we will insert some records into this table using the below statement:
INSERT INTO salaries (emp_num, valid_from, amount)
VALUES
(102, '2020-01-10', 45000),
(103, '2020-01-10', 65000),
(105, '2020-01-10', 55000),
(107, '2020-01-10', 70000),
 (109, '2020-01-10', 40000);
Execute the SELECT query to see the table data.

Third, we will create another table named total_salary_budget that keeps the salary information from the salaries
table.

CREATE TABLE total_salary_budget( total_budget int );

Fourth, we will use the SUM() function that returns the total salary from the salaries table and keep this
information in the total_salary_budget table:

mysql> INSERT INTO total_salary_budget (total_budget)

SELECT SUM (amount) FROM salaries;
Execute the SELECT statement to verify the table:

We will then create an AFTER DELETE trigger that updates the total salary into the total_salary_budget table after
a row is deleted from the salaries table.

DELIMITER $$

CREATE TRIGGER after_delete_salaries

AFTER DELETE
ON salaries FOR EACH ROW
BEGIN
UPDATE total_salary_budget SET total_budget = total_budget - old.amount;
END$$
First, we will delete a salary from the salaries table using the following statements to invoke the above-created trigger:
mysql> DELETE FROM salaries WHERE emp_num = 105;

mysql> SELECT * FROM total_salary_budget;

Third, we will remove all data from the salaries table:

mysql> DELETE FROM salaries;

Active Databases
An active database is a database that uses triggers and other event-driven functionalities. The
term "active" signifies that the DBMS reacts automatically to changes in data and predefined
events. Triggers are a primary mechanism that makes a database "active."

Key Features of Active Databases

Event-Condition-Action (ECA) Rule: This is the foundational concept of active databases.
When a specific event occurs, the database checks a particular condition, and if that condition
 is met, an action is executed.

Reactive Behavior: The database can react to changes without external applications or users
having to intervene, thanks to the ECA rules.

Flexibility: Active databases provide more flexibility in data management and ensure better data
integrity and security.

Why are Active Databases Important?

●​ Integrity Maintenance: Active databases can enforce more complex business rules that can't
be enforced using standard integrity constraints.
●​ Automation: They can automate certain tasks, reducing manual interventions.
●​ Alerts: They can notify users or applications when specific conditions are met.

The Problem of redundancy

Redundancy in DBMS is having several copies of the same data in the database, for example, storing the
complete details of the department such as department_id, department_name, and department_head repeatedly
in every student record. Redundancy may cause inconsistency in data when they are not properly updated. It
may also cause an increase in storage space and cost.
Redundancy in DBMS is the problem that arises when the database is not normalized. It is the concept of
storing multiple copies of the same data in different parts of the database.

Let's understand the concept of redundancy in DBMS with a simple student table.

student_nam student_ag dept_i dept_nam

student_id dept_head
e e d e
Computer
1 Ajay 18 100 Ramakrishn
Science
a
Computer Ramakrishn
2 Vijay 18 100
Science a

In this student table, we have repeated the same department details, dept_id, dept_name, and dept_head
in every student record. This causes redundancy in the student table.

How does Data Redundancy Occur?

Data redundancy in DBMS may occur due to any of the below reasons.

1.​ The database is not normalized through DBMS normalization.

2.​ The same data is stored in multiple places by multiple systems causing redundancy in data.
3.​ Mistake during database design causes the same data to be stored multiple times.

Problems caused by redundancy in Database

Redundancy in DMBS can cause several problems while performing operations on data such
as insert, delete, and update. Let's use the below student table to understand insertion, updation,
and deletion anomalies.

dept_i dept_nam
student_id student_name student_age dept_head
d e
Computer
1 Deepak 18 05
Science
jegadeesan
Computer
2 Rahul 18 05
Science
jegadeesan

Ramakrishn
3 Asritha 18 03 Mechanical
a

1.​ Insertion Anomaly

An insertion anomaly occurs when specific details cannot be inserted into the database without
the other details.

Example: Without knowing the department details, we cannot insert the student details in the
above table. The student details (student_id, student_name, and student_age) depend on the
department details (dept_id, dept_name, and dept_head).

2.​ Deletion Anomaly

Deletion anomaly occurs when deleting specific details loses some unrelated information from the
database.

Example: If we delete the student with student_id 3 from the above student table, we also lose the
department details with dept_id 03. Deleting student details result in losing unrelated department details.

1.​ Updation Anomaly

Updation anomaly occurs when there is data inconsistency resulting from a partial data update.

Example: We wanted to update the dept_head to Ramakrishna for dept_id 03; we need to update it in all
places. If the update didn't occur in all the places (partial update), it may result in data inconsistency.
 2.​ Wastage of Memory: Disk space is wasted due to storing same copy multiple times.

3.​ Storage cost increases: When multiple copies of same data is stored, need more disk space and
storage cost increases.

How to Avoid Redundancy in DBMS?

Redundancy in DBMS can be avoided by following the below approaches.
1.​ Redundancy in DBMS can be avoided by normalizing the data through database normalization.
2.​ Redundancy can be avoided using Master Data. Master data is a single source of data accessed by
several applications and systems.
3.​ Proper database architecture design can avoid data redundancy.

Decompositions, Problems Related To Decomposition

The term decomposition refers to the process in which we break down a table in a database into various
elements or parts. Thus, decomposition replaces a given relation with a collection of various smaller
relations. Thus, in a database, we can make any table break down into multiple tables when we want to
collect a particular set of data.
In simpler words, the process of decomposition refers to dividing a relation X into {X1, X2 …Xn}.
Decomposition is dependency preserving as well as lossless. Decomposition in DBMS removes
redundancy, anomalies and inconsistencies from a database by dividing the table into multiple tables.

Types of Decomposition
a.​ Lossless Decomposition
b.​ Lossy Decomposition

Lossless Decomposition

Decomposition is lossless if it is feasible to reconstruct relation R from decomposed tables using Joins. This is the
preferred choice. The information will not lose from the relation when decomposed. The join would result in the
same original relation.

Let us see an example −

<EmpInfo>
Emp_I Emp_Name Emp_Ag Emp_Locatio Dept_I Dept_Name
D e n D
Emp1 Jacob 29 Alabama Dpt1 Operations
Emp2 Henry 32 Alabama Dpt2 HR
Emp3 Tom 22 Texas Dpt3 Finance
Decompose the above table into two tables:
<EmpDetails>
Emp_ID Emp_Name Emp_Age Emp_Location
Emp1 Jacob 29 Alabama
Emp2 Henry 32 Alabama
Emp3 Tom 22 Texas

<DeptDetails>
Dept_ID Emp_ID Dept_Name
Dpt1 Emp1 Operations
Dpt2 Emp2 HR
Dpt3 Emp3 Finance

Now, Natural Join is applied on the above two tables −

The result will be −

Emp_I Emp_Name Emp_Ag Emp_Locatio Dept_I Dept_Name
D e n D
Emp1 Jacob 29 Alabama Dpt1 Operations
Emp2 Henry 32 Alabama Dpt2 HR
Emp3 Tom 22 Texas Dpt3 Finance

Therefore, the above relation had lossless decomposition i.e. no loss of information

Lossy Decomposition

As the name suggests, when a relation is decomposed into two or more relational schemas, the loss of
information is unavoidable when the original relation is retrieved.

Let us see an example −

<EmpInfo>
Emp_I Emp_Nam Emp_Ag Emp_Locatio Dept_ID Dept_Nam
D e e n e
Emp1 Jacob 29 Alabama Dpt1 Operations

Emp2 Henry 32 Alabama Dpt2 HR

Emp3 Tom 22 Texas Dpt3 Finance

Decompose the above table into two tables −

<EmpDetails>
Emp_ID Emp_Name Emp_Age Emp_Location

Emp1 Jacob 29 Alabama

Emp2 Henry 32 Alabama

Emp3 Tom 22 Texas

<DeptDetails>
Dept_ID Dept_Name

Dpt1 Operations

Dpt2 HR

Dpt3 Finance

Now, you won’t be able to join the above tables, since Emp_ID isn’t part of the DeptDetails relation.
Therefore, the above relation has lossy decomposition.

Problems of decomposition in DBMS?

There are many problems regarding the decomposition in DBMS mentioned below:

1. Loss of Information:

During the decomposition process, it is possible to lose some information present in the original table.
This occurs when critical relationships or dependencies between attributes are not preserved properly in
the decomposed relations. As a result, queries might not return the expected results or might become
more complex.

2. Anomalies:

Decomposition can introduce anomalies like update, insertion, and deletion anomalies. These occur when
data inconsistencies arise due to poor decomposition choices. For example, if a table is decomposed into
two smaller tables, updating information that involves both of these tables may lead to inconsistencies.
3. Join Complexity:

When a table is decomposed into multiple smaller relations, it often requires performing joins to retrieve
the original data. If the decomposition is not done efficiently, these joins can become complex and slow
down query performance significantly.

4. Redundancy:

While the goal of decomposition is to eliminate redundancy, it is possible to introduce new redundancy if
the decomposition is not carefully planned. Redundancy can lead to wasted storage space and can cause
update anomalies.

5. Increased Storage Space:

In some cases, decomposition can lead to an increase in storage space. For example, if the same data
needs to be stored in multiple decomposed tables to maintain referential integrity, it can result in
duplication of data.

6. Dependency Preservation:

Decomposition should ideally preserve all the functional dependencies from the original relation.
However, it is not always possible to preserve all dependencies, and some may be lost during the
decomposition process. This can lead to integrity issues

Functional dependency

Refer class notes

NORMALIZATION
●​ Normalization is the process of minimizing the redundancy from a relation or set of
relations.
●​ It is used to eliminate the Insertion, Update and Deletion Anomalies.
●​ Normalization divides the larger table into the smaller table and links the musing
relationship.
●​ Normalization is done with the help of different normal form.

The inventor of the relational model Edgar Codd proposed the theory of normalization with
the introduction of the First Normal Form, and he continued to extend theory with Second and
Third Normal Form. Later he joined Raymond F. Boyce to develop the theory of Boyce-Codd
Normal Form. In software industry, they are using only up to third normal form and sometimes
 Boyce-Codd Normal Form.

1.​ 1NF (FIRSTNORMALFORM)

1NF (First Normal Form) is the basic level of database normalization. It ensures that a table is well-structured
and avoids issues like data duplication or inconsistency.

A relation (table) is said to be in first normal form if and only if:

●​ Each table cell contains only atomic values (single value).i,e it does not contain any composite or
multi-valued attribute.
●​ All Values in a Column Should Be of the Same Type
●​ Every Column Must Have a Unique Name
●​ Each record needs to be uniquely identified by the primary key.

1NF Example:

HTNO FIRSTNAM LASTNAME MOBILE

E
9999988888
501 Jhansi Rani
7777799999
8888888881
502 Ajay Kumar
7897897897
503 Priya Verma 9898989898

The above table is not in 1NF because 501 and 502 is having two values in mobile column. If we
add a new column as alternative mobile number to the above table, then for 503 alternative
mobile number is NULL. Moreover, if a student has ‘n’ mobile numbers, then adding ‘n’ extra
column is meaningless. It is better to add extra rows. If we add extra row for each 501 and 502
then the table looks like
 HTNO FIRSTNAM LASTNAME MOBILE
E
501 Jhansi Rani 99999888
88
501 Jhansi Rani 77777999
99
502 Ajay Kumar 88888888
81
502 Ajay Kumar 78978978
97
503 Priya Verma 98989898
98

But the above table violates primary key constraint. Therefore instead of adding either columns
or rows, the best solution is to split the table into two tables as shown below. If we do as shown
below, if a student having ‘n’ number of mobile numbers also can be added.

HTN FIR LA
O ST ST
NA NA
ME ME
501 Jhansi Rani
502 Ajay Kumar
503 Priya Verma
HTN MOBIL
O E
501 99999888
88
501 77777999
99
502 88888888
81
502 78978978
97
503 98989898
98
​

2.​ 2NF (SECONDNORMALFORM)

Second Normal Form (2NF) is based on the concept of fully functional dependency. It is a way to
organize a database table so that it reduces redundancy and ensures data consistency.
 A relation is said to be in 2-NF if and only if

●​ It should be in 1-NF(First Normal Form)

●​ There should not be any partial functional dependencies

2NF Example:

Consider the table below.

​ There are many courses having the same course fee. Here,

​ COURSE_FEE cannot alone decide the value of COURSE_NO or STUD_NO.

​ COURSE_FEE together with STUD_NO cannot decide the value of COURSE_NO.

​ COURSE_FEE together with COURSE_NO cannot decide the value of STUD_NO.

​ The candidate key for this table is {STUD_NO, COURSE_NO} because the combination of these two columns
uniquely identifies each row in the table.

​ COURSE_FEE is a non-prime attribute because it is not part of the candidate key {STUD_NO, COURSE_NO}.

​ But, COURSE_NO -> COURSE_FEE, i.e., COURSE_FEE is dependent on COURSE_NO, which is a proper
subset of the candidate key.

​ Therefore, Non-prime attribute COURSE_FEE is dependent on a proper subset of the candidate key, which is a
partial dependency and so this relation is not in 2NF.

​ To convert the above relation to 2NF, we need to split the table into two tables such as :

Table 1: STUD_NO, COURSE_NO

Table 2: COURSE_NO, COURSE_FEE.
Now, each table is in 2NF:

The Course Table ensures that COURSE_FEE depends only on COURSE_NO.

The Student-Course Table ensures there are no partial dependencies because it only relates students to courses.

3.​ 3NF (THIRDNORMALFORM)

A relation (table) is in third normal form if and only if it satisfies the following conditions:

●​ It is in second normal form

●​ There is no transitive functional dependency

Transitive functional dependency means, we have the following relationships in

the table: A is functionally dependent on B (A→B), and B is functionally

dependent on C (B→C). In this case, C is transitively dependent on A via B (A→B

and B→C mean A→B→C implies A→C).

3NFExample:

Consider the following book details table example:

BOOK_DETAILS
BookID GenreID GenreTyp Price
e
1 1 Gardening 250.00
2 2 Sports 149.00
3 1 Gardening 100.00
4 3 Travel 160.00
5 2 Sports 320.00

The above table is not in3NFbecausethereexist transitive dependency. In the table able,
 BookID determines GenreID​ {BookID→GenreID}
GenreID determines GenreType.​ {GenreID→GenreType}

∴ BookID determines GenreType via GenreID.​ {BookID→GenreType}

It implies that transitive functional dependency is existing and the structure does not
satisfy third normal form. To bring this table into third normal form, we split the table into
two as follows:

BOOK_DETAILS GENRE_DETAILS

BookID GenreID Price

GenreI GenreTyp
1 1 250.00 D e
2 2 149.00 1 Gardening
3 1 100.00 2 Sports
4 3 160.00 3 Travel
5 2 320.00

BOYCE CODD NORMAL FORM (BCNF)

A relation (table) is said to be in the BCNF if and only if it satisfy the following conditions:

●​ It should be in the Third Normal Form.

●​ For any functional dependency A→B, A should be a superkey.
In simple words, it means, that for a dependency A → B, A cannot be a non-prime
attribute, if B is a prime attribute.

Example: Below we have a Patient table of a hospital. A patient can go to hospital

many times to take treatment. On a single day many patients can take treatment.
PatientI Name EmailID AdmittedDat Drug Quntit
D e y
101 Ram [email protected] 30/10/1998 A-10 10
102 Jhon [email protected] 30/10/1998 X-90 10
101 Ram [email protected] 10/06/2001 X-90 20
103 Sowmy [email protected] 05/03/2002 Y-30 15
a
102 Jhon [email protected] 05/03/2002 A-10 15

In the above table,{PateintID,AdmittedDate}acts as Primary key.But if we know the

EmailID value, we can find PatientID value.
 That is EmailID → PatientID.

In the above dependency, EmailId is non-prime attribute and PatientID is a prime

attribute. Therefore the above table is not in BCNF. In order to bring the table into BCNF,
we split it into two tables as shown below.

PatientI Name AdmittedDat Dru Quntit

D e g y
101 Ram 30/10/1998 A-1 10
0
102 Jhon 30/10/1998 X-9 10
0
101 Ram 10/06/2001 X-9 20
0
103 Sowm 05/03/2002 Y-3 15
ya 0
102 Jhon 05/03/2002 A-1 15
0

PatientI EmailID
D
101 [email protected]
102 [email protected]
103 [email protected]

In other words we can also define BCNF as there should not be any overlapping between candidate
keys. If you consider the original table (before splitting), we can get two candidate keys {PateintID,
AdmittedDate} and{EmailID, AdmittedDate}.

As there exist over lapping in the candidate keys,the table is not in BCNF. To bring it into BCNF,
we split into two tables as shown above.

4-NF (FOURTHNORMALFORM)
A relation is said to be in 4-NFif and only if it satisfies the following conditions
 ●​ It should be in the Third Normal Form.
●​ The table should not have any Multi-valued Dependency.

What is Multi-valued Dependency?

A table is said to have multi-valued dependency, if the following three conditions are true.

i.​ A table should have at-least 3 columns for it to have a multi-valued dependency.
ii.​ For any dependency A →B,if there exists multiple value of B for a single value of A,

then the table may have multi-valued dependency. It is represented as A →→ B.

iii.​ In a relation R(A,B,C),if there is a multi-valued dependency between A and B, then B

and C should be independent of each other.

If all these three conditions are true for any relation (table), then it contains multi-valued
dependency. The multi-valued dependency can be explained with an example. Let the Relation R
containing three columns A, B, C

As shown in the above figure, if 501 opted fors ubjects like Java and C# and hobbies
of 501 are Cricket and Dancing. Similarly, If 502 opted for subjects like Python and
Android and hobbies of 501 are Chess and Singing, then it can be written into a table with
three columns as follows:
HTN Subjec Hobby
O t
501 Java Cricke
t
501 Java Danci
ng
501 C# Cricke
t
501 C# Danci
ng
502 Pytho Chess
n
502 Pytho Singin
n g
502 Andro Chess
id
502 Andro Singin
id g

As there exist multivalued dependency,the above table is decomposed into two tables such
 that

HTN Subjec
O t
501 Java
501 C#
502 Pytho
n
502 Andro
id
HTN Hobby
O
501 Cricke
t
501 Danci
ng
502 Chess
502 Singin
g

Now these tables(relations) satisfy the fourth normal form.

4.​ 5NF
A relation is said to be in 5-NFif and only if it satisfies the followingconditions

●​ It should be in the Fourth Normal Form.

●​ The table should not have any join Dependency and joining should be lossless.

5NFisalso knownasProject-join normalform (PJ/NF).

A table is decomposed into multiple small tables to eliminate redundancy, and when
we re-join the decomposed tables, there should not be any loss in the original data or
shold not create any new data. In simple words, joining two or more decomposed table
should not lose records nor create new records.

Example:Consider a table which contains are cord of Subject, Professor and Semester in three
columns. The primary key is the combination of all three columns. No column itself is not a
candidate key or a super key.
 Inthetable,DBMS is taught by Ravindar and UmaRani in semester4,DS by Sindhusha and Venu
in sem 3. In this case, the combination of all these fields required to identify valid data.

So to make the table into 5NF,we can decompose it into three relations,

Subje Profess Semester

ct or
C Srilatha 2
DBM Ravindar 4
S
DS Sindhush 3
a
DBM UmaRan 4
S i
CN Srikanth 5
DS Venu 3
WT Srinivas 5

The above table is decomposed into three tables as follows to bring it into 5-NF.

Subje Professo
ct r
C Srilatha
DBMS Ravindar
DS Sindhusha
DBMS UmaRani
CN Srikanth
DS Venu
WT Srinivas
Semest Professor
er
2 Srilatha
3 Ravindar
5 Sindhusha
3 UmaRani
5 Srikanth
2 Venu
5 Srinivas
Semes Subject
ter
2 C
4 DBMS
3 DS
5 CN
5 WT