QB M3

For the relation schema below, give an expression in SQL for each of the queries that
follows:
employee (ID, person_name, street, city)
works (ID, company_name, salary)
company ( company_name, city)
manages (ID, manager_id)
i) Find the employees whose name starts with ‘C’.
ii) Find the name of managers of each company.
iii) Find the ID, name, and city of residence of employees who works for “First
Bank Corporation” and earn more than Rs50000.
iv) Find the name of companies whose employees earn a higher salary, on
average, then the average salary at “First Bank Corporation”.

i) Find the employees whose name starts with ‘C’:

SELECT * FROM employee WHERE person_name LIKE 'C%';
ii) Find the name of managers of each company:
SELECT e.person_name AS manager_name, c.company_name FROM manages m
JOIN employee e ON m.manager_id = e.ID JOIN company c ON m.ID = c.ID;
iii) Find the ID, name, and city of residence of employees who work for “First
Bank Corporation” and earn more than Rs50000:
SELECT e.ID, e.person_name, e.city FROM employee e JOIN works w ON e.ID =
w.ID JOIN company c ON w.company_name = c.company_name WHERE
w.company_name = 'First Bank Corporation' AND w.salary > 50000;
iv) Find the name of companies whose employees earn a higher salary, on
average, than the average salary at “First Bank Corporation”:
SELECT w.company_name FROM works w GROUP BY w.company_name
HAVING AVG(w.salary) > ( SELECT AVG(salary) FROM works WHERE
company_name = 'First Bank Corporation' );

Differentiate correlated and non-correlated nested queries with suitable examples.

Non-correlated Nested Queries:
● In a non-correlated nested query, the inner query can be executed
independently of the outer query. It doesn't rely on any values from the outer
query.
● Non-correlated subqueries are typically evaluated only once and their result is
used by the outer query.
● These subqueries are usually more efficient and can be evaluated just once for
the entire query execution.
SELECT name FROM employees WHERE salary > (SELECT AVG(salary) FROM
employees);

Correlated Nested Queries:

● In a correlated nested query, the inner query depends on the outer query. The
inner query is executed repeatedly, once for each row processed by the outer
query.
● Correlated subqueries are typically evaluated for each row of the outer query,
making them less efficient compared to non-correlated subqueries.
 ● These subqueries are useful when you need to reference values from the outer
query within the subquery.
SELECT name FROM employees e WHERE salary > (SELECT AVG(salary) FROM
employees WHERE department_id = e.department_id);

Consider the following relations for a database that keeps track of business trips of
salespersons in a sales office:SALESPERSON(Ssn, Name, StartYear, DeptNo)

TRIP(Ssn, FromCity, ToCity, DepartureDate, ReturnDate, TripId) EXPENSE(TripId,

AccountNo, Amount).

a) A trip can be charged to one or more accounts. Specify the foreign keys for this
schema, stating any assumptions you make.

b) Write relational algebra expressions to get the details of salespersons who have
traveled between Mumbai and Delhi and the travel expense is greater than Rs. 50000.

c) Write relational algebra expressions to get the details of the salesperson who had
incurred the greatest travel expenses among all travels made.

a) Foreign keys for the schema:

For the TRIP relation, the foreign key is Ssn, which references the Ssn attribute in the
SALESPERSON relation. This indicates that each trip is associated with a salesperson.
For the EXPENSE relation, the foreign key is TripId, which references the TripId
attribute in the TRIP relation. This indicates that each expense is associated with a trip.

b) Relational algebra expressions to get the details of salespersons who have traveled
between Mumbai and Delhi and the travel expense is greater than Rs. 50000:

π_Ssn, Name, FromCity, ToCity, DepartureDate, ReturnDate, Amount

((σ_FromCity='Mumbai' ∧ ToCity='Delhi' ∧ Amount > 50000 (TRIP ⨝
EXPENSE)) ⨝ SALESPERSON)
c) Relational algebra expressions to get the details of the salesperson who had
incurred the greatest travel expenses among all travels made:

π_Name, SUM(Amount) (TRIP ⨝ EXPENSE ⨝ SALESPERSON) ÷ {Ssn}

Consider the following schema:

 Suppliers (sid , sname, address)
Parts (pid, pname, color)
Catalog (sid, pid, cost)
The primary key fields are underlined and bold. Write relational algebra expressions
for the following queries:
a) Find the name of parts supplied by the supplier with sid=105.
b) Find the names of suppliers supplying some green parts for less than Rs 1000.
c) Find the IDs of suppliers who supply some red or green parts.
d) Find the names of suppliers who supply some red part.

Suppliers (sid, sname, address)

Parts (pid, pname, color)
Catalog (sid, pid, cost)
a) Find the name of parts supplied by the supplier with sid=105:
π_pname((σ_sid=105(Catalog)) ⨝ Parts)

b) Find the names of suppliers supplying some green parts for less than Rs 1000:
π_sname((σ_color='green' ∧ cost < 1000 (Catalog)) ⨝ Suppliers)

c) Find the IDs of suppliers who supply some red or green parts:
π_sid((σ_color='red' ∨ color='green' (Parts)) ⨝ Catalog)

d) Find the names of suppliers who supply some red part:

π_sname((σ_color='red' (Parts)) ⨝ Catalog ⨝ Suppliers)

Consider the query SELECT NAME, AGE FROM STUDENT WHERE GENDER
=‘Male’ on the table STUDENT (ROLLNO, NAME, AGE, GENDER, ADDRESS). Give
a relational algebra expression corresponding to the query. Is the result produced by the
query and your expression always the same? Why?

π_NAME, AGE(σ_GENDER='Male'(STUDENT))

σ_GENDER='Male'(STUDENT): Selects rows from the STUDENT table where the

GENDER attribute is 'Male'.
π_NAME, AGE: Projects the NAME and AGE attributes from the selected rows.

Static hashing and dynamic hashing

Static Hashing:
● In static hashing, the size of the hash table is fixed and does not change over
time.
● The hash function determines the bucket (or slot) to which each record is
mapped based on a predetermined number of buckets.
● If the number of records increases beyond the capacity of the hash table, it can
lead to an increase in collisions, which can degrade performance.
● Rehashing is required if the number of records exceeds the initial capacity of
the hash table. Rehashing involves creating a new, larger hash table,
 recalculating the hash values for all records, and redistributing the records into
the new hash table.
● Static hashing is simple to implement and suitable for scenarios where the size
of the dataset is relatively stable and known in advance.
Dynamic Hashing:
● In dynamic hashing, the size of the hash table can change dynamically based
on the number of records in the dataset.
● Dynamic hashing typically uses techniques like extendible hashing or linear
hashing.
● Extendible hashing uses a directory structure to dynamically adjust the number
of buckets based on the number of records.
● Linear hashing dynamically adjusts the number of buckets by splitting or
merging buckets as needed.
● Dynamic hashing adapts more flexibly to changes in the dataset size and can
reduce the likelihood of collisions, leading to better performance in dynamic
environments with unpredictable data growth.
● However, dynamic hashing can be more complex to implement compared to
static hashing due to the need for dynamic adjustments to the hash table
structure.

Compare DDL and DML with the help of an example.

DDL (Data Definition Language):

● DDL commands are used to define, modify, and manage the structure of the
database schema.
● They include commands such as CREATE, ALTER, DROP, and TRUNCATE.
● DDL commands do not directly manipulate the data in the tables; instead, they
define the structure of the database objects.
● DDL commands typically require higher privileges, such as database
administrator (DBA) or schema owner, to execute.

CREATE TABLE Employees ( EmployeeID INT PRIMARY KEY, FirstName

VARCHAR(50), LastName VARCHAR(50), DepartmentID INT, Salary DECIMAL(10,
2) );

DML (Data Manipulation Language):

● DML commands are used to manipulate and query data stored in the database
tables.
● They include commands such as SELECT, INSERT, UPDATE, DELETE.
● DML commands directly interact with the data stored in the tables, allowing
users to retrieve, insert, update, and delete records.
● DML commands can be executed by users with appropriate privileges,
typically including regular database users.
INSERT INTO Employees (EmployeeID, FirstName, LastName, DepartmentID, Salary)
VALUES (1, 'John', 'Doe', 101, 50000.00);