UNIT II

DATABASE MANAGEMENT SYSTEM

RELATIONAL MODEL
What is a relational database?

A relational database is a collection of information that organizes data in predefined relationships

where data is stored in one or more tables (or "relations") of columns and rows, making it easy to
see and understand how different data structures relate to each other. Relationships are a logical
connection between different tables, established on the basis of interaction among these tables.
A relational database (RDB) is a way of structuring information in tables, rows, and columns. An RDB
has the ability to establish links—or relationships–between information by joining tables, which
makes it easy to understand and gain insights about the relationship between various data points.

Developed by E.F. Codd from IBM in the 1970s, the relational database model allows any table to be
related to another table using a common attribute. Instead of using hierarchical structures to
organize data, Codd proposed a shift to using a data model where data is stored, accessed, and
related in tables without reorganizing the tables that contain them.

Think of the relational database as a collection of spreadsheet files that help businesses organize,
manage, and relate data. In the relational database model, each “spreadsheet” is a table that stores
information, represented as columns (attributes) and rows (records or tuples).

Attributes (columns) specify a data type, and each record (or row) contains the value of that specific
data type. All tables in a relational database have an attribute known as the primary key, which is
a unique identifier of a row, and each row can be used to create a relationship between different
tables using a foreign key—a reference to a primary key of another existing table.
 The Customer table contains data about the customer:

 Customer ID (primary key)

 Customer name
 Billing address
 Shipping address

In the Customer table, the customer ID is a primary key that uniquely identifies who the customer
is in the relational database. No other customer would have the same Customer ID.

The Order table contains transactional information about an order:

 Order ID (primary key)

 Customer ID (foreign key)
 Order date
 Shipping date
 Order status

Here, the primary key to identify a specific order is the Order ID. You can connect a customer with
an order by using a foreign key to link the customer ID from the Customer table.
The two tables are now related based on the shared customer ID, which means you can query both
tables to create formal reports or use the data for other applications. For instance, a retail branch
manager could generate a report about all customers who made a purchase on a specific date or
figure out which customers had orders that had a delayed delivery date in the last month.

The above explanation is meant to be simple. But relational databases also excel at showing very
complex relationships between data, allowing you to reference data in more tables as long as the
data conforms to the predefined relational schema of your database.

As the data is organized as pre-defined relationships, you can query the data declaratively. A
declarative query is a way to define what you want to extract from the system without expressing
how the system should compute the result. This is at the heart of a relational system as opposed to
other systems.
Examples of relational databases
Now that you understand how relational databases work, you can begin to learn about the many
relational database management systems that use the relational database model. A relational
database management system (RDBMS) is a program used to create, update, and manage relational
databases. Some of the most well-known RDBMSs include MySQL, PostgreSQL, MariaDB, Microsoft
SQL Server, and Oracle Database.

Cloud-based relational databases like Cloud SQL, Cloud Spanner and AlloyDB have become
increasingly popular as they offer managed services for database maintenance, patching, capacity
management, provisioning and infrastructure support.

Relational Algebra in DBMS

Relational Algebra is a procedural query language that provides a set of operations to manipulate
and retrieve data stored in a relational database. It forms the theoretical foundation for SQL
(Structured Query Language) and is widely used in Database Management Systems (DBMS).
Here’s an overview of relational algebra in DBMS:

Key Concepts

 Relation: A table consisting of rows (tuples) and columns (attributes).

 Tuple: A row in a relation.
 Attribute: A column in a relation.
 Domain: The set of permissible values for a given attribute.

Types of Operations in Relational Algebra

1. Unary Operations: Operations performed on a single relation.

o Selection (σ): Selects rows that satisfy a given condition.
 Example: σ_{age > 30}(Employee) retrieves all employees older
than 30.
o Projection (π): Selects specific columns (attributes) from a relation.
 Example: π_{name, age}(Employee) retrieves the name and age of
employees.
o Rename (ρ): Changes the name of a relation or its attributes.
  Example: ρ_TempEmployee(Employee) renames the Employee
relation to TempEmployee.
2. Binary Operations: Operations performed on two relations.
o Union (∪): Combines two relations and eliminates duplicates.
 Example: A ∪ B retrieves tuples present in either A, B, or both.
o Set Difference (−): Retrieves tuples that are in one relation but not in the other.
 Example: A − B returns tuples that are in A but not in B.
o Intersection (∩): Retrieves tuples that are present in both relations.
 Example: A ∩ B returns tuples common to both A and B.
o Cartesian Product (×): Combines every tuple in one relation with every tuple in
another relation.
 Example: A × B combines tuples from A with every tuple from B.
o Join Operations: Combines related tuples from two relations based on a condition.
 Natural Join (⋈): Joins two relations on common attributes.
 Example: Employee ⋈ Department joins Employee and Department
based on matching department IDs.
 Theta Join (θ): Joins two relations using a condition (e.g., =, <, >).
 Example: A ⋈_{A.id = B.id} B joins relations A and B where
IDs match.
3. Division (÷): A special operation that finds tuples in one relation that are related to all tuples
in another relation.
o Example: A ÷ B returns tuples in A that are related to every tuple in B.

Importance in DBMS

 Foundation for SQL: Relational algebra operations correspond to SQL operations such as
SELECT, JOIN, UNION, and WHERE.
 Query Optimization: DBMSs often optimize SQL queries by converting them into relational
algebra expressions to determine the most efficient way to retrieve data.
 Data Manipulation: Relational algebra defines how data is manipulated (inserted, updated,
deleted) in a relational database.

 Find names and salaries of employees in the 'CSE' department:

o Query: π_{name, salary}(σ_{dept = 'CSE'}(Employee))
 Find employees with a salary greater than 30,000:
o Query: σ_{salary > 30000}(Employee)
 Find the common employees in two departments:
o Query: Employee_CSE ∩ Employee_ECE

Basic operations:
1. Selection (σ) Selects a subset of rows from relation.
2. Projection (π) Selects a subset of columns from relation.
3. Cross-product (×) Allows us to combine two relations.
4. Set-difference ( ) Tuples in relation. 1, but not in relationn. 2.
5. Union (U) Tuples in reln. 1 and in reln. 2.
6. Rename( ρ) Use new name for the Tables
or fields. Additional operations:
7. Intersection (∩), Join( ), Division(÷): Not essential, but (very!)
 useful. Since each operation returns a relation, operations can be
composed! (Algebra is
―closed‖.)

Projection

 Deletes attributes that are not in projection list.

 Schema of result contains exactly the fields in the projection list, with the
same names that they had in the (only) input relation. ( Unary Operation)
 Projection operator has to eliminate duplicates! (as it returns a relation which is a set)
o Note: real systems typically don‘t do duplicate elimination unless the
user explicitly asks for it. (Duplicate values may be representing
different real world entity or relationship).
Example: Consider the BOOK table:

Acc-No Title Author

100 ―DBMS‖ ―Silbershatz‖
200 ―DBMS‖ ―Ramanuj‖
300 ―COMPILER‖ ―Silbershatz‖
400 ―COMPILER‖ ―Ullman‖
500 ―OS‖ ―Sudarshan‖
600 ―DBMS‖ ―Silbershatz‖

Title

πTitle(BOOK) = ―DBMS‖
―COMPILER‖
―OS‖

Selection

 Selects rows that satisfy selection condition.

 No duplicates in result
 Schema of result identical to schema of (only) input relation.
 Result relation can be the input for another relational algebra
operation! (Operator composition.)
Example: For the example
given above: σAcc-
no>300(BOOK) =

Acc Title Author

- No
400 ―COMPILER ―Ullman‖
‖
500 ―OS‖ ―Sudarshan‖
σTitle=‖DBMS‖(BOOK)=

Acc Title Author

- No
100 ―DBMS‖ ―Silbershatz‖
200 ―DBMS‖ ―Ramanuj‖
600 ―DBMS‖ ―Silbershatz‖

πAcc-no (σTitle=‖DBMS‖ (BOOK))=

Acc-
No
100
200
600

Union, Intersection, Set-Difference

 All of these operations take two input relations, which must be union-compatible:
o Same number of fields.
o Corresponding‘ fields have the same type.
 What is the schema of
result? Consider:
Borrower Depositor
Cust- Loan-no Cust-name Acc-no
name Suleman A-100
Ram L-13 Radheshyam A-300
Shyam L-30 Ram A-401
Suleman L-42

List of customers who are either borrower or depositor at bank= πCust-name

(Borrower) U πCust-name (Depositor)=

Cust-name
Ram
Shyam
Suleman Customers who are both borrowers and depositors =
Radeshyam πCust-name (Borrower) ∩ πCust-name (Depositor)=
Cust-
name
Ram
Suleman
 Customers who are borrowers but not depositors = πCust-name (Borrower)
πCust-
name (Depositor)=

Cust-name

Shyam

Cartesian-Product or Cross-Product (S1 × R1)

 Each row of S1 is paired with each row of R1.
 Result schema has one field per field of S1 and R1, with field names `inherited‘ if possible.
 Consider the borrower and loan tables as follows:

Borrower: Loan:
Cust-name Loan-no Loan-no Amount
Ram L-13 L-13 1000
Shyam L-30 L-30 20000
Suleman L-42 L-42 40000

Cross product of Borrower and Loan, Borrower × Loan =

Borrower.Cu Borrower.Loa Loan.Loa Loan.Amount

st- name n- no n- no
Ram L-13 L-13 1000
Ram L-13 L-30 20000
Ram L-13 L-42 40000
Shyam L-30 L-13 1000
Shyam L-30 L-30 20000
Shyam L-30 L-42 40000
Suleman L-42 L-13 1000
Suleman L-42 L-30 20000
Suleman L-42 L-42 40000

The rename operation can be used to rename the fields to avoid confusion when two field
names are same in two participating tables:

For example the statement, ρLoan-borrower(Cust-name,Loan-No-1, Loan-No-2,Amount) (

Borrower × Loan) results into- A new Table named Loan-borrower is created where it has
four fields which are renamed as Cust-name, Loan-No-1, Loan-No-2 and Amount and the
rows contains the same data as the cross product of Borrower and Loan.

Loan-borrower:
Cust Loan-No- Loan Amount
- 1 - No-
nam 2
e
Ram L-13 L-13 1000
Ram L-13 L-30 20000
Ram L-13 L-42 40000
Shyam L-30 L-13 1000
Shyam L-30 L-30 20000
Shyam L-30 L-42 40000
Suleman L-42 L-13 1000
Suleman L-42 L-30 20000
Suleman L-42 L-42 40000
Rename Operation

The rename operator ρ is one of the unary operators in relational algebra and is used to rename
relations in a DBMS. In other words, some relations or attributes may have complex names and can be
changed to make writing queries easier.

This relational operator is a base for SQL (Structured Query Language) and is used to rename relations.

Syntax

A rename query looks like the following:

ρnew_relation_name(new_attribute_name_list)(R)ρnew_relation_name(new_attribute_name_list)(R)

The new_relation_namenew_relation_name contains the name we want to replace with the original
relation RR and the new_attribute_name_listnew_attribute_name_list contains the changed attribute
names of RR.

Why is it needed?

The following are some reasons to use the rename operator:

 It helps us have user-friendly names so that it is easy to understand.

 We can easily write queries without using complex names.
 We may want to save the result of a RA expression in the form of a relation.
 It removes the confusion of attributes having the same names.
 It works really well to distinguish relations/tables that are joined with themselves.

Types

Three following types of renaming can be done:

 Renaming a relation
 Renaming an attribute
 Renaming both

Let's look at the differences between them using examples:

Rename a relation

Suppose we have a relation named Students Students and we want to change it

to FinalYrStudentsFinalYrStudents, the rename operation works as follows:

ρFinalYrStudents(Students)ρFinalYrStudents(Students)
Rename an attribute

Suppose we have a relation named Students and we want to change its

attributes StudentIDStudentID, StudentNameStudentName to SIDSID and SNameSName, the
rename operation works as follows:

ρ(SID,SName)(Students)ρ(SID,SName)(Students)

The attributes will be ordered as same as the tables and must be renamed in the same order. If only
selective attributes are to be changed, rewrite the original attribute names of those that are supposed
to be unchanged.

Rename both

Next, we'll change both the relation name and attributes of the StudentsStudents class:

ρFinalYrStudents(SID,SName)(Students)ρFinalYrStudents(SID,SName)(Students)
What is Relational Algebra?

Relational Algebra is a system used to model data stored in relational databases. It’s largely
used as the theoretical basis for which query languages like SQL are built around.

Core Concepts

A Relation can be thought of as a class in traditional OOP programming. This is generally

represented as a table. Each column of the table corresponds to an attribute of that class.
Each row of the table represents a single instance of the relation, or, in OOP terms, an object
of that class.

Example PERSON relation with attributes Name, Age, and FavoriteFood

Additionally, a row can be represented as a tuple, which is simply a comma delimited list of all
attributes in the row enclosed in parenthesis. As an example, for John in the relation Person above,
he can be represented as a tuple of (John, 15, Pizza).

Set Operations

Relational Algebra uses set operations from set theory, but with added constraints.

Union: A union of two relations (R1 U R2) can only be performed if the two relations are union
compatible. This essentially means that both relations have the exact same attributes. A union
combines the rows of the two relations and outputs a new relation that has both input relations’ rows
in it. Suppose, taking the example table above, we want to union with this new table below:
The end result would look like this:

Difference: The difference between two relations (R1- R2) is, as the name implies, all rows from the
first relation that are not present in the second relation. This operation also relies on the two tables
being union compatible. Why is this the case? If you think about it, a difference operation is essentially
a reverse union. Difference ‘takes away’ rows from a table.
If we have another table, Person3, who are all under 30, we can take the difference of the Person
relation to Person3(under 30), to result in a single row table with Stacy.

Cartesian ( or sometimes, Cross) Product: This operation does not need the two tables being
operated on to be union compatible. However, without some sort of condition associated with taking
the cross product of two tables, we are likely unable to glean any data of value. Taking the cross
product of two relations essentially taking every combination of the two tables’ tuples.

Take for example an unrelated table that corresponds color to strength.

If we take the cross product of this table with Person, we end up with a new table of 5 columns, with
each row getting a distinct combination of the tuples from both rows. As you can probably tell from
just that, there would be no use of this data.
Alright we took the cross product, but why?

So you’re probably confused why this operation exists. We will see in the next section, about Joins,
that once we take a cross product with a condition, we can start to gather meaningful data from this.

Join Operation

When we have two relations that have a single column (let’s just call this column C) in common, we
can perform what is known as a natural join. Essentially two tables are naturally joined by taking
the cross product of the two tables, then eliminating all combinations in which the column C from
table 1 and column C from table 2 are not equal.

So let’s take a look at a table of food, and the corresponding best way to obtain them.
If perform natural join on this table and Person, we will end up with a result of the Person table, along
with the corresponding location at which their favorite food is obtained from.

The bowtie is the natural join symbolLECTURE-11: Additional Operations

Additional Operations

Natural Join ( )

 Forms Cartesian product of its two arguments, performs selection forcing

equality on those attributes that appear in both relations
 For example consider Borrower and Loan relations, the natural join between
them
will automatically perform the selection on the table
returned by Borrower × Loan which force equality on the attribute that
appear in both Borrower and Loan i.e. Loan-no and also will have only
one of the column named Loan-No.
 That means = σBorrower.Loan-no = Loan.Loan-no (Borrower ×
Loan).
 The table returned from this will be as follows:

Eliminate rows that does not satisfy the selection criteria ―σBorrower.Loan-no = Loan.Loan-no”
from Borrower

× Loan =
Borrower.Cu Borrower.Loa Loan.Loa Loan.Amount
st- name n- no n- no
Ram L-13 L-13 1000
Ram L-13 L-30 20000
Ram L-13 L-42 40000
Shyam L-30 L-13 1000
Shyam L-30 L-30 20000
Shyam L-30 L-42 40000
Suleman L-42 L-13 1000
Suleman L-42 L-30 20000
Suleman L-42 L-42 40000

And will remove one of the column named Loan-no.

 i.e. =
Cust-name Loan-no Amount
Ram L-13 1000
Shyam L-30 20000
Suleman L-42 40000

Division Operation:

 denoted by ÷ is used for queries that include the phrase ―for all‖.
 For example ―Find customers who has an account in all branches in
 branch city Agra‖. This query can be solved by following statement.
ΠCustomer-name. branch-name ( ) ÷ Πbranch-name (σBranch-
city=”Agra”(Branch)
 The division operations can be specified by using only basic operations as follows:
Let r(R) and s(S) be given relations for schema R
and S with r ÷ s = ΠR-S(r) - ΠR-S ((ΠR-S (r) ×
s) - ΠR-S,S (r))
Tuple Relational Calculus

Relational algebra is an example of procedural language while tuple

relational calculus is a nonprocedural query language.
A query is specified as:
{t | P(t)}, i.e it is the set of all tuples t such that predicate P is true for t.

The formula P(t) is formed using atoms which uses the relations, tuples of
relations and fields of tuples and following symbols

Set operations

Set operations in DBMS allow combining the results of two or more queries in relational
databases. These operations are derived from set theory and include UNION, INTERSECT,
and MINUS (also called EXCEPT in some systems). Here's a breakdown:

1. UNION: Combines the result sets of two queries and returns all unique rows from
both queries.
o Example: SELECT column1 FROM table1 UNION SELECT column1 FROM
table2;
o This returns unique rows from both table1 and table2.
2. UNION ALL: Similar to UNION, but it does not eliminate duplicate rows.
o Example: SELECT column1 FROM table1 UNION ALL SELECT column1
FROM table2;
o This includes all duplicates from both table1 and table2.
3. INTERSECT: Returns only the rows that are common to both queries.
o Example: SELECT column1 FROM table1 INTERSECT SELECT column1
FROM table2;
o Only the rows present in both table1 and table2 are returned.
4. MINUS (EXCEPT): Returns the rows from the first query that are not present in
the second query.
o Example: SELECT column1 FROM table1 MINUS SELECT column1 FROM
table2;
o This returns rows in table1 that are not in table2.

These set operations help in performing operations such as combining results, finding
common records, or identifying differences between datasets.
Here are examples of set operations in SQL using a relational database system. Let's
assume we have two tables: TableA and TableB.

TableA:

ID Name

1 John

2 Alice

3 Bob

TableB:

ID Name

2 Alice

3 Charlie

4 David

1. UNION Example

The UNION operator combines the result sets of two queries, returning distinct values.

SELECT Name FROM TableA

UNION
SELECT Name FROM TableB;

Result:

Name

John

Alice
Name

Bob

Charlie

David

Explanation: The result contains distinct names from both tables.

2. UNION ALL Example

The UNION ALL operator combines the result sets of two queries, returning all values,
including duplicates.

SELECT Name FROM TableA

UNION ALL
SELECT Name FROM TableB;

Result:

Name

John

Alice

Bob

Alice

Charlie

David

Explanation: This result includes all names from both tables, including the duplicate
"Alice."

3. INTERSECT Example

The INTERSECT operator returns only the rows that are common to both queries.
SELECT Name FROM TableA
INTERSECT
SELECT Name FROM TableB;

Result:

Name

Alice

Explanation: Only "Alice" is common to both tables, so it’s the only row returned.

4. MINUS (EXCEPT) Example

The MINUS (or EXCEPT) operator returns the rows from the first query that are not in
the second query.

SELECT Name FROM TableA

MINUS
SELECT Name FROM TableB;

Result:

Name

John

Bob

Explanation: "John" and "Bob" exist in TableA but not in TableB, so they are returned.

SQL AGGREGATE FUNCTIONS

SQL Aggregate functions are functions where the values of multiple rows are grouped
as input on certain criteria to form a single value result of more significant meaning.
It is used to summarize data, by combining multiple values to form a single result.
SQL Aggregate functions are mostly used with the GROUP BY clause of the SELECT
statement.
Various Aggregate Functions
1. Count()
2. Sum()
3. Avg()
4. Min()
5. Max()
Aggregate Functions in SQL
Below is the list of SQL aggregate functions, with examples
Count():
 Count(*): Returns the total number of records .i.e 6.
 Count(salary): Return the number of Non-Null values over the column salary. i.e 5.
 Count(Distinct Salary): Return the number of distinct Non-Null values over the
column salary .i.e 5.
Sum():
 sum(salary): Sum all Non-Null values of Column salary i.e., 3120.
 sum(Distinct salary): Sum of all distinct Non-Null values i.e., 3120..
Avg():
 Avg(salary) = Sum(salary) / count(salary) = 3120 / 5 = 624
 Avg(Distinct salary) = sum(Distinct salary) / Count(Distinct Salary) = 3120 / 5 =
624
Min():
 Min(salary): Minimum value in the salary column except NULL i.e., 403.
Max():
 Max(salary): Maximum value in the salary i.e., 802.

SQL Database

Id Name Salary

1 A 802

2 B 403

3 C 604
Id Name Salary

4 D 705

5 E 606

6 F NULL

 Count the number of employees

SELECT COUNT(*) AS TotalEmployees FROM Employee;

 Calculate the total salary

SELECT SUM(Salary) AS TotalSalary FROM Employee;

 Find the average salary

SELECT AVG(Salary) AS AverageSalary FROM Employee;

 Get the highest salary

SELECT MAX(Salary) AS HighestSalary FROM Employee;

 Determine the lowest salary

SELECT MIN(Salary) AS LowestSalary FROM Employee;

Output

TotalEmployees

TotalSalary

3120
 AverageSalary

624

HighestSalary

802

LowestSalary

403

Key Takeaways :
 Aggregate functions in SQL operate on a group of values and return a single result.
 They are often used with the GROUP BY clause to summarize the grouped data.
 Aggregate function operates on non-NULL values only (except COUNT).
 Commonly used aggregate functions are – MIN(), MAX(), COUNT(), AVG(),
and SUM().

NULL values in SQL





In SQL there may be some records in a table that do not have values or data for every
field and those fields are termed as a NULL value.

NULL values could be possible because at the time of data entry information is not
available. So SQL supports a special value known as NULL which is used to represent the
values of attributes that may be unknown or not apply to a tuple. SQL places a NULL
value in the field in the absence of a user-defined value. For example, the
Apartment_number attribute of an address applies only to addresses that are in
apartment buildings and not to other types of residences.
So, NULL values are those values in which there is no data value in the particular field
in the table.

Importance of NULL Value

 It is important to understand that a NULL value differs from a zero value.
 A NULL value is used to represent a missing value, but it usually has one of three
different interpretations:
o The value unknown (value exists but is not known)
o Value not available (exists but is purposely withheld)
o Attribute not applicable (undefined for this tuple)
 It is often not possible to determine which of the meanings is intended. Hence, SQL
does not distinguish between the different meanings of NULL.

Principles of NULL values

 Setting a NULL value is appropriate when the actual value is unknown, or when a
value is not meaningful.
 A NULL value is not equivalent to a value of ZERO if the data type is a number and is
not equivalent to spaces if the data type is a character.
 A NULL value can be inserted into columns of any data type.
 A NULL value will evaluate NULL in any expression.
 Suppose if any column has a NULL value, then UNIQUE, FOREIGN key, and CHECK
constraints will ignore by SQL.
In general, each NULL value is considered to be different from every other NULL in the
database.

How To Test for NULL Values?

SQL allows queries that check whether an attribute value is NULL. Rather than using =
or to compare an attribute value to NULL, SQL uses IS and IS NOT. This is because SQL
considers each NULL value as being distinct from every other NULL value, so equality
comparison is not appropriate.
Now, consider the following Employee Table.

Query:
CREATE TABLE Employee (

Fname VARCHAR(50),

Lname VARCHAR(50),

SSN VARCHAR(11),

Phoneno VARCHAR(15),

Salary FLOAT

);

INSERT INTO Employee (Fname, Lname, SSN, Phoneno, Salary)

VALUES
 ('Shubham', 'Thakur', '123-45-6789', '9876543210', 50000.00),

('Aman', 'Chopra', '234-56-7890', NULL, 45000.00),

('Aditya', 'Arpan', NULL, '8765432109', 55000.00),

('Naveen', 'Patnaik', '345-67-8901', NULL, NULL),

('Nishant', 'Jain', '456-78-9012', '7654321098', 60000.00);

Output:

The IS NULL Operator

Suppose we find the Fname and Lname of the Employee having no Super_ssn then the
query will be:

Query:
SELECT Fname, Lname FROM Employee WHERE SSN IS NULL;

Output:

The IS NOT NULL Operator

Now if we find the Count of number of Employees having SSNs.

Query:
SELECT COUNT(*) AS Count FROM Employee WHERE SSN IS NOT NULL;

Output:
Updating NULL Values in a Table
We can update the NULL values present in a table using the UPDATE statement in SQL.
To do so, we can use the IS NULL operator in the WHERE clause to select the rows with
NULL values and then we can set the new value using the SET keyword.
Let’s suppose that we want to update SSN in the row where it is NULL.

Query:
UPDATE Employee

SET SSN = '789-01-2345'

WHERE Fname = 'Aditya' AND Lname = 'Arpan';

select* from Employee;

Output:

NESTED QUERY
In SQL, a nested query, also called a subquery, is a query embedded inside another
query. It allows you to use the result of one query as input for another. The subquery
can be placed in various clauses such as SELECT, FROM, WHERE, and HAVING.

Types of Subqueries:

1. Single-row subquery: Returns only one row from the subquery.

2. Multiple-row subquery: Returns multiple rows.
3. Correlated subquery: Refers to columns in the outer query, meaning it runs
once for each row processed by the outer query.

Basic Structure:

A subquery is enclosed in parentheses and can be placed in different SQL clauses.

Here’s a breakdown:

SELECT column_name
FROM table_name
WHERE column_name = (SELECT column_name FROM another_table WHERE condition);

Example 1: Simple Nested Query (Single-row subquery)

Find employees who earn more than the average salary.

SELECT first_name, salary

FROM Employees
WHERE salary > (SELECT AVG(salary) FROM Employees);

In this example, the subquery (SELECT AVG(salary) FROM Employees) calculates the
average salary, and the outer query selects employees with a salary greater than the
average.

Example 2: Nested Query with Multiple Rows

Find departments where there are employees with salaries greater than 50,000.

SELECT department_id
FROM Departments
WHERE department_id IN (SELECT department_id FROM Employees WHERE salary >
50000);
 Here, the subquery returns a list of department_ids from the Employees table where
salary exceeds 50,000, and the outer query retrieves all matching departments.

Example 3: Correlated Subquery

Find employees who earn more than the average salary in their department.

SELECT first_name, salary, department_id

FROM Employees e
WHERE salary > (SELECT AVG(salary) FROM Employees WHERE department_id =
e.department_id);

In this example, the subquery is correlated because it refers to the department_id of

the outer query, calculating the average salary per department for comparison.

“Nested queries are powerful tools in SQL that allow you to write more dynamic and
complex queries by using the results of one query as inputs to another. They are essential
when working with multiple tables or filtering based on aggregate results.”

Views





Views in SQL are a kind of virtual table. A view also has rows and columns like tables,
but a view doesn’t store data on the disk like a table. View defines a customized query
that retrieves data from one or more tables, and represents the data as if it was coming
from a single source.
We can create a view by selecting fields from one or more tables present in the
database. A View can either have all the rows of a table or specific rows based on
certain conditions.
In this article, we will learn about creating, updating, and deleting views in SQL.
Demo SQL Database
We will be using these two SQL tables for examples.
StudentDetails

StudentMarks
You can create these tables on your system by writing the following SQL query:
-- Create StudentDetails table

CREATE TABLE StudentDetails (

S_ID INT PRIMARY KEY,
NAME VARCHAR(255),
ADDRESS VARCHAR(255)
);

INSERT INTO StudentDetails (S_ID, NAME, ADDRESS)

VALUES
(1, 'Harsh', 'Kolkata'),
(2, 'Ashish', 'Durgapur'),
(3, 'Pratik', 'Delhi'),
(4, 'Dhanraj', 'Bihar'),
(5, 'Ram', 'Rajasthan');

-- Create StudentMarks table

CREATE TABLE StudentMarks (

ID INT PRIMARY KEY,
NAME VARCHAR(255),
Marks INT,
Age INT
);

INSERT INTO StudentMarks (ID, NAME, Marks, Age)

VALUES
(1, 'Harsh', 90, 19),
(2, 'Suresh', 50, 20),
(3, 'Pratik', 80, 19),
(4, 'Dhanraj', 95, 21),
(5, 'Ram', 85, 18);

CREATE VIEWS
We can create a view using CREATE VIEW statement. A View can be created from a
single table or multiple tables.

CREATE VIEW view_name AS

SELECT column1, column2.....
FROM table_name
WHERE condition;
Parameters:
 view_name: Name for the View
 table_name: Name of the table
 condition: Condition to select rows

Statement Examples

Example 1: Creating View from a single table

In this example, we will create a View named DetailsView from the table StudentDetails.

CREATE VIEW DetailsView AS

SELECT NAME, ADDRESS
FROM StudentDetails
WHERE S_ID < 5;
To see the data in the View, we can query the view in the same manner as we query a
table.
SELECT * FROM DetailsView;
Output:

Example 2: Create View From Table

In this example, we will create a view named StudentNames from the table Student
Details.

CREATE VIEW StudentNames AS

SELECT S_ID, NAME
FROM StudentDetails
ORDER BY NAME;

If we now query the view as,

SELECT * FROM StudentNames;

Output:

Example 3: Creating View from multiple tables

In this example we will create a View named MarksView from two tables StudentDetails
and StudentMarks.

To create a View from multiple tables we can simply include multiple tables in the
SELECT statement.

CREATE VIEW MarksView AS

SELECT StudentDetails.NAME, StudentDetails.ADDRESS, StudentMarks.MARKS
FROM StudentDetails, StudentMarks
WHERE StudentDetails.NAME = StudentMarks.NAME;

To display data of View MarksView:

SELECT * FROM MarksView;

Output:
Uses of a View
A good database should contain views for the given reasons:
1. Restricting data access – Views provide an additional level of table security by
restricting access to a predetermined set of rows and columns of a table.
2. Hiding data complexity – A view can hide the complexity that exists in multiple
joined tables.
3. Simplify commands for the user – Views allow the user to select information
from multiple tables without requiring the users to actually know how to perform a
join.
4. Store complex queries – Views can be used to store complex queries.
5. Rename Columns – Views can also be used to rename the columns without
affecting the base tables provided the number of columns in view must match the
number of columns specified in a select statement. Thus, renaming helps to hide the
names of the columns of the base tables.
6. Multiple view facility – Different views can be created on the same table for
different users.

Embedded SQL

Embedded SQL is a powerful method that allows the integration of high−level

programming languages with database management systems (DBMS). It acts as a bridge
between applications and databases which helps in data manipulation and
communication. Various database management systems offer embedded SQL, giving
developers the freedom to select the one that best serves their requirements.

Popular DBMS that support Embedded SQL are Altibase, IBM Db2, Microsoft SQL Server,
Mimer SQL, Oracle Database, PostgreSQL, and SAP Sybase.

Need of Embedded SQL

The goal to make database interactions simpler for application developers and end users
determines the demand for embedded SQL. Users often enter values or submit requests
while interacting with an application, which requires accessing and changing data
contained in a database. Developers may conduct these database tasks without
burdening the user with SQL complexities by integrating SQL queries directly into the
application code.

Structure of Embedded SQL

Connection to the Database

The first step in using embedded SQL is establishing a connection to the database. This
is done using the CONNECT keyword, preceded by EXEC SQL to indicate that it is a SQL
statement

Example
EXEC SQL CONNECT HR_USER;
Declaration Section

The declaration section is used to declare variables that will be used in SQL queries and
to capture the results of those queries. The host language and its variable will get and
capture the result. Types of variables used in the host language are:

Host Variable: Host variables are variables of the host language that are used to supply
data and store the results of SQL queries. The BEGIN DECLARE and END DECLARE
sections are defined within EXEC SQL and should be used to declare the variables within
the SQL code and;

Example
EXEC SQL BEGIN DECLARE SECTION;
int id;
int roll_no;
char name[10];
char address[30];
EXEC SQL END DECLARE SECTION;

Indicator variables: Indicator variables are also host variables but they are used to
capture NULL values which are returned by queries or to set NULL values in INSERT or
UPDATE statements. Indicator variables are always of the 2−byte short type. With
SELECT statement, indicators capture any NULL values returned for a column and with
INSERT OR UPDATE statement, the common value is set to be NULL regardless of the
value present for a host variable.

Example
EXEC SQL SELECT NAME INTO :NAME :IND_NAME FROM STUDENT WHERE ID = :ID;
INSERT INTO STUDENT (ID, SNAME) VALUES (:ID, :NAME :IND_NAME);
UPDATE STUDENT SET ADDRESS = :ADDRESS :IND_ADDRESS;
Execution Section

The execution section contains all the SQL queries and statements that are prefixed by
EXEC SQL. This is where you can write your SQL queries and perform database
operations.

Example
EXEC SQL SELECT * FROM STUDENT WHERE STUDENT_ID = :STD_ID;
Error Handling

Error handling is essential in embedded SQL. In embedded SQL, error handling is based
on the host language. In C programs, error handling is typically done using labels and
the WHENEVER statement. The WHENEVER statement is used to define the action to be
taken when a certain condition occurs. The condition can be SQLWARNING, SQLERROR,
or NOT FOUND. The action can be CONTINUE, DO <function>, GOTO , or STOP.

Example
EXEC SQL WHENEVER SQLWARNING DO display_warning();
EXEC SQL WHENEVER SQLERROR STOP;
EXEC SQL WHENEVER NOT FOUND GOTO lbl_no_records;

Advantages of Embedded SQL

1. Ease of Database Usage

Accessing databases is made simple with embedded SQL, which eliminates the need for
lengthy coding or other programs. It offers a simple method for getting data by feeding
it into the database, doing away with the need for complex and complicated
programming.

2. Security and authorization

With embedded SQL, developers may specify and implement appropriate authorization
procedures for database access. This helps prevent unauthorized access to sensitive data
and ensures that only users with the proper authorization can execute certain tasks.

3. Integration of Frontend and Backend

By permitting a direct connection between the user interface and the database,
embedded SQL makes it easier to integrate the front end and back end of an application.
This improves the overall user experience by enabling real−time data retrieval and
changes.

4. Error prevention

Developers can prevent logical mistakes from happening when processing database
transactions by integrating SQL queries into the application code. The integration of SQL
with the host language guarantees security and improves the application's dependability.

Disadvantages of Embedded SQL

1. Knowledge of the Host Language Required

Developers must have a solid understanding of the host language in which the SQL is
contained to use embedded SQL effectively. This can require more programming
language knowledge or training.

2. Complex Development Model

By using embedded SQL, the development process becomes even more difficult. It may
be difficult for developers to handle the integration of SQL statements within host
language code, especially for larger systems.

3. Limited SQL Flexibility

SQL statements must be declared at design time for embedded SQL, which means that
only predefined queries may be used in application code. The application's ability to react
to shifting requirements may be hampered by the absence of dynamic SQL flexibility.
 4. Dynamic SQL

Dynamic SQL involves the creation and execution of SQL statements at runtime. Dynamic
SQL allows developers to generate SQL statements dynamically based on runtime
conditions or user input. By combining changeable data, conditions, and dynamic
database or column names, developers may quickly construct SQL queries using dynamic
SQL. Because of its adaptability, dynamic SQL is a good choice when the SQL statements
need to change in response to evolving needs or user inputs. Dynamic SQL queries are
built at execution time so the system chooses how to access the database and conduct
the SQL queries. Performance could be affected as a result of this lack of preparation
because the system must create an execution plan on the spot. Dynamic SQL, however,
provides outstanding adaptability and versatility.

Steps to use Dynamic SQL

Step 1: Declare two variables

DECLARE
@var1 NVARCHAR(MAX),
@var2 NVARCHAR(MAX);

Step 2: Set the value of the first variable as table_name

SET @var1 = N'table_name';

Step 3: Select statement is added to table_name to create dynamic SQL

SET @var2= N'SELECT * FROM ' + @var1;

Step 4: Use the second variable to run the sp_executesql

EXEC sp_executesql @var2;

Example

This example will show how the data of a table named 'student' is selected using a
dynamic process.

Input Table

Student

Id Name City
1 Monu Gonda
2 Aman Lucknow
3 Naman Dehradun
Example
DECLARE
@var1 NVARCHAR(100),@var2 NVARCHAR(120);
SET @var1 = N'student';
SET @var2 = N'SELECT * FROM' + @var1;
EXEC sp_executesql @var2;
Output

Student

Id Name City
1 Monu Gonda
2 Aman Lucknow
3 Naman Dehradun
Advantages of Dynamic SQL

1. Flexibility: Dynamic SQL provides unparalleled flexibility as it allows developers

to build SQL statements dynamically based on runtime conditions or user input.
This flexibility enables developers to create dynamic queries, adapt to changing
requirements, and handle complex scenarios.
2. Conditional Queries: Dynamic SQL is particularly useful when dealing with
conditional queries. By building SQL statements dynamically, developers can
incorporate conditions into the queries, such as dynamic WHERE clauses or varying
column selections based on runtime conditions.
3. Table and Column Name Flexibility: Dynamic SQL allows developers to work
with dynamic table and column names. This flexibility is beneficial when dealing
with scenarios where the table or column names are not known or need to be
determined at runtime.
4. Database Administration: Dynamic SQL can be useful for database
administrators (DBAs) when performing tasks such as data migration, schema
changes, or automated maintenance operations. Dynamic SQL allows DBAs to
generate and execute SQL statements on the fly, adapting to the specific
requirements of the task at hand.

Integrity Constraints

Integrity constraints are the set of predefined rules that are used to maintain the quality
of information. Integrity constraints ensure that the data insertion, data updating, data
deleting and other processes have to be performed in such a way that the data integrity
is not affected. They act as guidelines ensuring that data in the database remain accurate
and consistent. So, integrity constraints are used to protect databases.

The various types of integrity constraints are

Types of Integrity Constraints:

 Domain Constraints
 Not-Null Constraints
 Entity integrity Constraints
 Key Constraints
 Primary Key Constrains
 Referential integrity constraints

1. Domain Constraints

These are defined as the definition of valid set of values for an attribute. The data type
of domain include string, char, time, integer, date, currency etc. The value of the attribute
must be available in comparable domains.
Example:

Student_Id Name Semester Age

21CSE100 Ramesh 5th 20

21CSE101 Kamlesh 5th 21

21CSE102 Aakash 5th 22

21CSE103 Mukesh 5th 20

 2. Not-Null Constraints
It specifies that within a tuple, attributes overs which not-null constraint is specified must
not contain any null value.
Example:
Let, the not-null constraint be specified on the “Semester” attribute in the relation/table
given below, then the data entry of 4th tuple will violate this integrity constraint, because
the “Semester” attribute in this tuple contains null value. To make this database instance
a legal instance, its entry must not be allowed by database management system.

Student_id Name Semester Age

21CSE100 Ramesh 5th 20

21CSE101 Kamlesh 5th 21

21CSE102 Akash 5th 22

21CSE103 Mukesh 20

3. Entity Integrity Constraints

Entity integrity constraints state that primary key can never contain null value because
primary key is used to determine individual rows in a relation uniquely, if primary key
contains null value then we cannot identify those rows. A table can contain null value in
it except primary key field.
Example:
It is not allowed because it is containing primary key as NULL value.

Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Aakash 5th 22

Mukesh 5th 20
 4. Key Constraints
Keys are the entity set that are used to identify an entity within its entity set uniquely.
An entity set can contain multiple keys, bit out of them one key will be primary key. A
primary key is always unique, it does not contain any null value in table.

Example:

Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Aakash 5th 22

21CSE102 Mukesh 5th 20

It is now acceptable because all rows must be unique.

5. Primary Key Constraints

It states that the primary key attributes are required to be unique and not null. That is,
primary key attributes of a relation must not have null values and primary key attributes
of two tuples must never be same. This constraint is specified on database schema to the
primary key attributes to ensure that no two tuples are same.
Example
Here, in the below example the Student_id is the primary key attribute. The data entry
of 4th tuple violates the primary key constraint that is specifies on the database schema
and therefore this instance of database is not a legal instance.

Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Akash 5th 22

21CSE103 Mukesh 5th 20

 6. Referential integrity constraints

It can be specified between two tables. In case of referential integrity constraints, if

a Foreign key in Table 1 refers to Primary key of Table 2 then every value of the Foreign
key in Table 1 must be null or available in Table 2.

Example:
Here, in below example Block_No 22 entry is not allowed because it is not present in 2nd
table.

Student_id Name Semester Block_No

22CSE101 Ramesh 5th 20

21CSE105 Kamlesh 6th 21

22CSE102 Aakash 5th 20

23CSE106 Mukesh 2nd 22

Block_No Block Location

20 Chandigarh

21 Punjab

25 Delhi

Integrity constraints act as the backbone of reliable and robust database. They ensure
that the data stored is reliable, worthy, consistent and accurate within the database. By
implement integrity constraints we can improve the quality of the data stored in database.
So, as the database continues to grow it will not become inconsistent and inaccurate.

Procedures

Local Procedures vs. Stored Procedures are both types of procedures used in SQL,
but they differ in terms of scope, storage, and how they are used within the database
environment. Below is a detailed comparison of both types:
1. Local Procedures

Definition:
A local procedure is a procedure that is defined and used within the scope of a single
session, batch, or block of code (like a script or a PL/SQL block). These procedures are
not stored permanently in the database; they exist only while the code is being executed.

Key Points:

 Scope: Local procedures are defined within a block of code such as an anonymous
PL/SQL block, a function, or another procedure. They are not accessible outside
of this scope.
 Temporary Nature: They exist only during the execution of the script or block
where they are defined. Once the block finishes executing, the local procedure is
discarded.
 Use Cases: Local procedures are useful for modularizing code within a specific
task, reducing redundancy in scripts, and enhancing readability without the need
to persist the procedure in the database.
 Performance: Since they are compiled at runtime, local procedures may have
slightly lower performance compared to stored procedures which are precompiled.

Example of a Local Procedure:

sql
Copy code
DECLARE
-- Define a local procedure within an anonymous PL/SQL block
PROCEDURE PrintMessage IS
BEGIN
DBMS_OUTPUT.PUT_LINE('This is a local procedure!');
END;
BEGIN
-- Call the local procedure
PrintMessage;
END;

In this example, the PrintMessage procedure is defined and used within the scope of the
anonymous block.

2. Stored Procedures

Definition:
A stored procedure is a named set of SQL statements and procedural logic stored
permanently in the database. It is precompiled, reusable, and can be invoked multiple
times from any session or application connected to the database.

Key Points:

 Scope: Stored procedures are stored and managed by the database and can be
called from anywhere within the database environment by users with appropriate
permissions.
 Persistence: They are permanently stored in the database, meaning they persist
beyond the session and can be reused across multiple applications and sessions.
 Precompiled: Stored procedures are precompiled and stored in an optimized
form in the database, resulting in faster execution compared to scripts or local
procedures.
 Security and Maintenance: Stored procedures can be secured with access
permissions and provide a centralized point of maintenance for commonly used
code, reducing duplication.
 Performance: Due to their precompiled nature and optimized execution plan,
stored procedures often provide better performance.

Example of a Stored Procedure:

sql
Copy code
CREATE PROCEDURE GetCustomerDetails(IN custID INT)
BEGIN
SELECT * FROM Customers WHERE CustomerID = custID;
END;

This stored procedure can be called from any session using:

sql
Copy code
CALL GetCustomerDetails(101);
Key Differences Between Local and Stored Procedures:

1. Scope and Accessibility:

o Local Procedures: Limited to the block or session where they are defined;
not accessible outside of that context.
o Stored Procedures: Accessible globally within the database; can be called
from any session or application.
2. Persistence:
o Local Procedures: Temporary; exist only during the execution of the
defining block or session.
 oStored Procedures: Permanent; stored in the database and persist until
explicitly dropped.
3. Compilation:
o Local Procedures: Compiled at runtime when the block is executed.
o Stored Procedures: Precompiled and stored in the database, resulting in
faster execution.
4. Use Cases:
o Local Procedures: Suitable for specific, one-time operations within a block
of code where persistence is not needed.
o Stored Procedures: Ideal for reusable, frequently executed tasks, often
involving complex business logic.
5. Maintenance and Security:
o Local Procedures: Maintenance is confined to the code block; security is
inherently limited to the session.
o Stored Procedures: Centralized maintenance; security can be managed
via database roles and permissions.

Summary:

 Local Procedures are best for temporary, localized tasks within a single script or
block, providing modularity without storing code permanently.
 Stored Procedures offer a robust, reusable, and secure way to encapsulate
business logic within the database, optimizing performance and maintainability.

A trigger is a stored procedure in a database that automatically invokes whenever a

special event in the database occurs. For example, a trigger can be invoked when a row
is inserted into a specified table or when specific table columns are updated. In simple
words, a trigger is a collection of SQL statements with particular names that are stored
in system memory. It belongs to a specific class of stored procedures that are
automatically invoked in response to database server events. Every trigger has a table
attached to it.
Because a trigger cannot be called directly, unlike a stored procedure, it is referred to
as a special procedure. A trigger is automatically called whenever a data modification
event against a table takes place, which is the main distinction between a trigger and a
procedure. On the other hand, a stored procedure must be called directly.

The following are the key differences between triggers and stored procedures:

1. Triggers cannot be manually invoked or executed.

2. There is no chance that triggers will receive parameters.
3. A transaction cannot be committed or rolled back inside a trigger.
A trigger is a special type of stored procedure that automatically executes (or "fires") in
response to certain events on a table or view in a database. Common events that can
fire a trigger include INSERT, UPDATE, and DELETE operations.

Key Points:

 Automatic Execution: Triggers run automatically when the specified event

occurs, without explicit invocation by the user.

 Types of Triggers:
o BEFORE Trigger: Executes before the event occurs (e.g., before inserting
a row).
o AFTER Trigger: Executes after the event has occurred (e.g., after
updating a row).