lOMoARcPSD|50868604

VTU exam Question Paper with Solution of BCS403 Data

Base Management Systems Sep-2024-Ms. Rencita Maria
Colaco
B Tech in COMPUTER SCIENCE (Presidency University India)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])
 lOMoARcPSD|50868604

DBMS-BCS403 SOLUTION JUNE/JULY 2024

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

MODULE 1

Q1a. Define database. Elaborate component modules of DBMS and their

interactions.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A database is a collection of logically coherent data with some inherent

meaning, representing aspects of the real world, organized in such a way that it
can be easily accessed, managed, and updated.

A DBMS consists of the following major components:

● Storage Manager: Manages the storage of data and meta-data.

A
● Query Processor: Converts user queries into low-level instructions for

IT
efficient access.
● Transaction Manager: Manages the execution of transactions while

C
ensuring ACID properties (Atomicity, Consistency, Isolation, and

EN
Durability).
● Concurrency Control Manager: Ensures transactions do not interfere
with each other.

-R
These modules interact to process user queries, ensure data consistency, manage
concurrent access, and store the data efficiently .

1. Interactive Query Interface

24
20
● Casual or occasional users interact with the database through an
n_

interactive query interface.

● Queries go through a query compiler that parses and validates them for
tio

correctness (syntax, file names, etc.), and converts them into an internal
form.
lu

● The query optimizer improves the query by rearranging operations,

So

eliminating redundancies, and choosing efficient search algorithms, using

statistics from the system catalog. This results in executable code that is
passed to the runtime processor.
S-

2. Application Programs
BM

● Application programmers write programs using languages like Java, C,

or C++ which interact with the database.
D

● A precompiler extracts DML (Data Manipulation Language)

commands from the program, which are compiled separately by the DML
compiler.
● The rest of the program is compiled by the host language compiler, and the
two parts (DML commands and the main program) are linked together to
form a canned transaction.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

● Canned transactions are executed repeatedly by users who supply

parameters (e.g., in a bank payment transaction, account number, payee,
and amount are parameters). This approach is becoming popular with
scripting languages like PHP and Python.

3. Runtime Database Processor

● The runtime database processor executes privileged commands,

A
executable query plans, and canned transactions with parameters.

IT
● It interacts with the system catalog and may update statistics related to the
database. It also works with the stored data manager, which handles I/O

C
operations between the disk and main memory.

EN
● Buffer management is handled either by the DBMS or the operating
system. The DBMS also includes concurrency control and
backup/recovery modules for transaction management.

-R
4. Client-Server Architecture
24
● Typically, the client program runs on a separate computer (client) that
20
accesses the database, which resides on a database server.
● In some cases, the client accesses a middle-tier application server, which
n_

in turn accesses the database server.

● The operating system schedules disk accesses and DBMS processing if
tio

the system is shared by many users. If dedicated, the DBMS may control
memory buffering of disk pages directly.
lu

5. DBMS Interaction with the OS

So

● The DBMS interacts with the operating system when it needs to perform
S-

disk accesses (for the database or catalog).

● The DBMS can also interface with compilers for host programming
BM

languages and with client programs through the system network

interface.
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So

Q1b. Describe the three-schema architecture. Why do we need mappings

S-

among schema levels?

BM

The three-schema architecture separates the user’s view from the physical
database and defines three levels:
D

1. Internal Level: Describes the physical storage structure.

2. Conceptual Level: Describes the structure of the database for a
community of users.
3. External Level: Defines different views for users.

Mappings among these schemas are essential to transform a request from an

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

external schema to the conceptual schema and then to the internal schema. This
ensures data independence at different levels​.

A
IT
C
EN
-R
24
20
n_

Q1c. Explain the difference between logical and physical data independence.
tio

● Logical data independence allows changing the conceptual schema

without affecting the external schemas or application programs.
lu

● Physical data independence allows changing the internal schema without

affecting the conceptual schema
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Q2a. Draw an ER diagram for a company database with employee,

department, project as strong entities, and dependent as a weak entity.

Here is a simplified explanation for the ER diagram:

● Entities: Employee, Department, Project (Strong), Dependent (Weak)

● Relationships: Employee works in a Department, Employee works on a

A
Project, Dependent is related to Employee

IT
● Constraints: Employee has one Department, and works on multiple
projects, Dependent weak entity relies on Employee.

C
EN
The diagram would look similar to the one in the textbook showing employees,
departments, and dependents​.

-R
24
20
n_
tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Q2b. Define the following terms with examples using ER notations: Entity,
attribute, composite attribute, multivalued attribute, participation role.

● Entity: Represents a real-world object, e.g., Employee.

● Attribute: Property of an entity, e.g., Employee’s name.
● Composite Attribute: Attribute with components, e.g., Name (First

A
Name, Last Name).

IT
● Multivalued Attribute: Attribute that can hold multiple values, e.g.,
Phone Numbers.

C
● Participation Role: Refers to an entity’s role in a relationship, e.g.,

EN
Employee works in Department

-R
MODULE 2
24
Q3a. Discuss update operations and constraint violations with examples.
20
Update operations include Insert, Delete, and Update. These can violate
n_

constraints such as:

tio

1. Relational Model Operations

● The operations of the relational model are categorized into retrievals and
lu

updates.
So

● Retrieval operations are typically expressed using relational algebra or

relational calculus (introduced in later chapters). Relational algebra forms
a new relation by applying algebraic operators on existing relations, which
S-

helps in querying the database.

BM

● Update operations modify the database state, including the Insert,

Delete, and Update (Modify) operations.
D

2. Insert Operation

● Insert adds new tuples (records) to a relation. However, integrity

constraints must be maintained:
○ Domain constraints ensure that each value belongs to the proper
domain (data type or value range).
○ Key constraints prevent duplicate primary key values.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

○ Entity integrity ensures that primary key attributes cannot be

NULL.
○ Referential integrity ensures that foreign keys reference valid
tuples in other relations.
● Examples:
○ Inserting a tuple with a NULL primary key violates entity integrity
and is rejected.

A
○ Inserting a tuple with an existing primary key value violates key
constraints and is rejected.

IT
○ Inserting a tuple with an invalid foreign key violates referential

C
integrity.
○ A valid insert operation satisfies all constraints.

EN
3. Delete Operation

-R
● Delete removes tuples from a relation, and it can only violate referential
integrity.
24
○ Referential integrity violation occurs if other tuples reference the
tuple being deleted. For example, deleting an EMPLOYEE tuple
20
could cause issues if other relations like WORKS_ON or
DEPENDENT reference it.
n_

● Options for Handling Violations:

○ Restrict: Reject the deletion.
tio

○ Cascade: Delete the referencing tuples as well (e.g., deleting related

WORKS_ON tuples).
lu

○ Set Null or Set Default: Modify the referencing attributes, either by

So

setting them to NULL or to a default value.

4. Update Operation
S-

● Update modifies attribute values in existing tuples. It can violate several

BM

constraints:
○ Domain constraints if the new value is not of the correct type.
○ Key constraints if updating the primary key duplicates an existing
D

value.
○ Referential integrity if modifying a foreign key references a
non-existing tuple.
● Examples:
○ Updating an employee’s salary or department number is acceptable
as long as it doesn't violate any integrity constraints.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

○ Updating a primary key or foreign key might require checking for

consistency with other tuples or relations.

5. Handling Constraint Violations

● The DBMS can reject operations that violate integrity constraints by

default or provide corrective options such as asking for valid inputs.
● Similar handling options for Update as with Delete, like restrict, cascade,

A
or set null.

IT
C
EN
Q3b. Relational algebra operators for select and project operations.

● Select (σ): Retrieves rows that satisfy a condition, e.g., σ(Salary >

-R
30000)(Employee).
● Project (π): Retrieves specific columns, e.g., π(Name, Salary)(Employee)​.

24
Q3c. Characteristics of relations that make them different from ordinary
data.
20
1. Tabular Structure (Relations are Tables)
n_

● A relation is represented as a table of rows and columns. Each row

tio

represents a tuple (or record), and each column represents an attribute (or
field).
lu

● Tuples in a relation are ordered conceptually but not physically, meaning

the order of rows does not affect the relation.
So

2. Attributes and Domains

S-

● Each column (attribute) in a relation is associated with a domain, which

BM

defines the permissible values the attribute can take. For example, a
domain for a "Date of Birth" column might only accept valid date values.
● Attributes must maintain atomicity, meaning every value in a relation
D

must be atomic or indivisible (not a set or list of values).

3. Uniqueness of Tuples

● In a relational model, each tuple must be unique. No two rows can have
identical values for all attributes. This is enforced by the primary key, a
unique identifier for each tuple.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

● Primary keys ensure the integrity of the data and allow the database to
reference individual records precisely.

4. No Duplicates

● Relations do not allow duplicate tuples. Each tuple must be distinct, as a

relation is a set of tuples and sets do not contain duplicate elements.

A
5. Unordered Tuples and Attributes

IT
● Tuples (rows) in a relation are not ordered. Unlike arrays or lists in

C
programming, the order of tuples is irrelevant, and the DBMS does not

EN
enforce a particular order.
● Attributes (columns) are also unordered, meaning the left-to-right order of
columns does not affect the definition or behavior of the relation.

-R
6. Integrity Constraints
24
● Relations are subject to various integrity constraints that ensure the
20
correctness and consistency of the data:
○ Domain constraints: Values in each column must come from the
attribute's domain.
n_

○ Key constraints: The primary key must be unique for every tuple.
○ Referential integrity: A foreign key in one relation must reference
tio

a valid tuple in another relation.

○ Entity integrity: The primary key must not be NULL.
lu
So

7. Relational Operations

● Relations support specific operations defined by relational algebra,

S-

including:
○ Selection: Retrieving rows based on conditions.
BM

○ Projection: Retrieving specific columns.

○ Join: Combining two relations based on a related attribute.
D

○ Union, Intersection, and Difference: Set-based operations to

combine or compare relations.

8. Data Independence

● Relations are abstract representations of data, which provides data

independence. Changes to the physical storage of data do not affect the

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

logical structure of relations, meaning users interact with data at a higher

level of abstraction.

9. Set-Based Theory

● Relations are fundamentally based on set theory and predicate logic.

They are considered sets of tuples where set operations like union,
intersection, and difference can be performed. This makes relations

A
different from ordered data structures in programming.

IT
10. Null Values

C
EN
● Relations can accommodate NULL values, which represent unknown,
missing, or inapplicable information. However, certain constraints, like
primary keys, may disallow NULL values.

-R
11. Normalization
24
● Relations can be normalized to reduce redundancy and improve data
20
integrity. Normalization organizes data into smaller, related relations to
eliminate anomalies during insertion, deletion, or update operations.
●
n_
tio

a. Perform the following:

lu

(i) Student U Instructor

(ii) Student ⋂ Instructor
So

(iii) Student - Instructor (iv) Instructor - Student on the following tables:

S-

● Student: Fname, Lname

● Instructor: Fname, Lname
BM

i)
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_

ii)
tio
lu
So
S-

iii)
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

iv)

A
IT
C
EN
b. Consider the following relational database schema and write the queries

-R
in relational algebra expressions:
EMP(Eno, Ename, Salary, Address, Phone, DNo)
DEPT(DNo, Dname, Dloc, MgrEno)
DEPENDENT(Eno, DepName, Relation, Dage) 24
20
1. List all the employees who reside in ‘Belagavi’.
2. List all the employees who earn between 30000 and 40000.
n_

3. List all the employees who work for the ‘Sales’ department.
4. List the employees who have at least one dependent.
tio

5. List the department names along with the names of the managers.
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

MODULE 3

Module 3:

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Q5a. Informal design guidelines for relation schema design.

● Making sure that the semantics of the attributes is clear in the

schema
● Reducing the redundant information in tuples
● Reducing the NULL values in tuples
● Disallowing the possibility of generating spurious tuples

A
14.1.1 Clear Semantics

IT
● Definition: Relation attributes should have clear real-world meanings.

C
● Importance: A well-designed relation schema is easier to explain and

EN
interpret.
● Example: The EMPLOYEE schema clearly represents employee data,

-R
with attributes like name and department number, indicating an implicit
relationship with the DEPARTMENT schema.

24
● Guideline: Design schemas to ensure each relation corresponds to a single
entity or relationship to avoid semantic ambiguity.
20
14.1.2 Redundant Information and Update Anomalies
n_

● Redundancy: Grouping attributes can lead to repeated information across

tuples, wasting space.
tio

● Anomalies:
○ Insertion Anomalies: Difficulty adding new data (e.g., a new
lu

employee) without needing to fill in all department details.

○ Deletion Anomalies: Removing a record can unintentionally lose
So

essential data (e.g., deleting the last employee removes department

info).
S-

○ Modification Anomalies: Changes require updates in multiple

places, risking inconsistencies.
BM

● Guideline: Structure schemas to prevent these anomalies.

14.1.3 NULL Values in Tuples

D

● Problem: Excessive NULL values can complicate understanding and

operations.
● Guideline: Minimize attributes with frequent NULL values and consider
separate relations for those attributes to maintain clarity.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

14.1.4 Generation of Spurious Tuples

● Concern: Poorly designed relations can lead to unexpected tuples in

results when joining or querying.
● Example: Combining multiple entities or relationships can create tuples
that do not accurately represent the intended relationships.
● Guideline: Ensure design avoids configurations that could lead to spurious
data.

A
IT
C
[Link] 1NF, 2NF, and 3NF with examples.

EN
● 1NF (First Normal Form): Ensures atomicity of values.
● 2NF (Second Normal Form): Ensures no partial dependency, every

-R
non-key attribute must depend on the whole primary key.
● 3NF (Third Normal Form): Ensures no transitive dependency, i.e.,
non-key attributes do not depend on other non-key attributes​.
24
20
n_
tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio

Q5c. SQL Commands for INSERT, UPDATE, and DELETE.

lu

● INSERT: INSERT INTO Employee VALUES ('John', 'Doe', 30000);

So

● UPDATE: UPDATE Employee SET Salary = 35000 WHERE Name =

'John Doe';
S-

● DELETE: DELETE FROM Employee WHERE Name = 'John Doe';​.

BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio

6a). Discuss insertion, deletion, and modification anomalies. Why are they
considered bad? Illustrate with examples.
lu

In relational databases, anomalies occur when data is stored redundantly in a

So

poorly designed schema, typically in a non-normalized table. These anomalies

can be classified into three main types: insertion, deletion, and modification
S-

anomalies. They are considered bad because they compromise the integrity of the
data and may result in inconsistencies or the loss of important information.
BM

1. Insertion Anomaly:

An insertion anomaly occurs when it is impossible to insert data into the table
D

without also inserting unrelated or redundant information. This happens in a

non-normalized schema where certain columns depend on each other and require
values even when the actual information is not available.

Example: Consider a table that stores employee and department information:

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

EmpI EmpNam DeptI DeptNam

D e D e
101 John 10 HR

If you want to add a new department (say "Finance") without assigning any
employee to it, you cannot insert it into this table unless you also provide some

A
employee information. This dependency creates an insertion anomaly, as you
can't insert department data without inserting employee data.

IT
C
EN
2. Deletion Anomaly:

A deletion anomaly occurs when deleting data about one entity inadvertently

-R
causes loss of data about another entity. This is common in non-normalized
tables where data is stored redundantly.

Example: Using the same table from above: 24

20
EmpI EmpNam DeptI DeptNam
n_

D e D e
101 John 10 HR
tio

102 Susan 20 Finance

lu
So

If you delete the row for employee Susan, you also lose information about the
Finance department (DeptID 20), even though that department may still exist.
S-
BM

3. Modification Anomaly:

A modification anomaly occurs when data is stored redundantly and needs to be

D

updated in multiple places. If you update it in one place and forget to update it
elsewhere, the database will have inconsistent data.

Example: If the department name HR changes to Human Resources, you would

need to update all rows where DeptID is 10. If you forget to update some rows,
the database will have inconsistent data, where DeptID 10 refers to both HR and

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Human Resources.

EmpI EmpNam DeptI DeptName

D e D
101 John 10 HR
103 Mary 10 Human

A
Resources

IT
C
Why are these anomalies considered bad?

EN
● Data Redundancy: Storing the same information multiple times leads to
redundancy, which wastes storage space and makes the system harder to

-R
manage.
● Data Inconsistency: If the same information is stored in multiple places,
24
there’s a risk that it will become inconsistent over time due to modification
anomalies.
20
● Difficulty in Data Management: Anomalies make it harder to insert,
update, or delete records without affecting unrelated data. This increases
n_

the complexity of the database and the risk of errors.

● Loss of Information: Deletion anomalies can lead to the unintended loss of
tio

important data, compromising the integrity of the database.

lu

Normalization as a Solution:
So

Normalization, particularly to 3NF (Third Normal Form) or higher, is used to

eliminate these anomalies. By organizing the data into separate, well-defined
S-

tables with appropriate keys and relationships, insertion, deletion, and

modification anomalies can be avoided, ensuring consistency and integrity of the
BM

data.
D

6b)Illustrate the following with suitable examples:

● (i) Datatypes in SQL

● (ii) Substring Pattern Matching in SQL

(i) SQL provides various data types to define the type of data that can be stored

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

in a column of a table. Here are some common SQL datatypes:

INT: Stores integer values (e.g., 100, -45).

CREATE TABLE Employees (

ID INT,

A
Name VARCHAR(50),

IT
Age INT

C
);

EN
●

-R
VARCHAR(size): Stores variable-length string data (e.g., John, Database).

CREATE TABLE Students ( 24

20
StudentID INT,

Name VARCHAR(100)
n_

);
tio

●
lu

FLOAT: Stores floating-point numbers (e.g., 10.5, -2.75).

So

CREATE TABLE Products (

S-

ProductID INT,
BM

Price FLOAT

);
D

DATE: Stores date values in the format YYYY-MM-DD (e.g., 2023-09-20).

CREATE TABLE Orders (

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

OrderID INT,

OrderDate DATE

);

A
BOOLEAN: Stores true/false values.

IT
CREATE TABLE Flags (

C
FlagID INT,

EN
IsActive BOOLEAN

-R
);

(ii)
24
20
SQL provides the LIKE operator for pattern matching using wildcards, and it is
n_

commonly used to search for substrings in string data. The two main wildcards
used with LIKE are:
tio

● %: Represents zero or more characters.

lu

● _: Represents a single character.

So

Examples:

Find names that start with 'A':

S-
BM

SELECT Name

FROM Students
D

WHERE Name LIKE 'A%';

● This query retrieves all names that begin with the letter 'A'.

Find names that end with 'son':

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

SELECT Name

FROM Employees

WHERE Name LIKE '%son';

A
Find names where the second letter is 'a':

IT
SELECT Name

C
FROM Employees

EN
WHERE Name LIKE '_a%';

-R
●

Find names that contain 'dat':

24
20
SELECT Name

FROM Employees
n_

● WHERE Name LIKE '%dat%';

tio
lu

MODULE 4
So

Q7a. Consider the following relations:

S-

● Student(Snum, Sname, Branch, level, age)

BM

● Class(Cname, meet_at, room, fid)

● Enrolled(Snum, Cname)
● Faculty(fid, fname, deptid)
D

Write the following queries in SQL. No duplicates should be printed in any of the
answers.

(i) Find the names of all Juniors (level = JR) who are enrolled in a class

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

taught by I. Teach.

SELECT DISTINCT [Link]

FROM Student S, Enrolled E, Class C, Faculty F
WHERE [Link] = [Link]
AND [Link] = [Link]
AND [Link] = [Link]

A
AND [Link] = 'JR'

IT
AND [Link] = 'I. Teach';

C
EN
This query joins the Student, Enrolled, Class, and Faculty tables to find the
students who are at the junior level and enrolled in a class taught by a specific
faculty member.

-R
24
(ii) Find the names of all classes that either meet in room R128 or have five
20
or more students enrolled.
n_

SELECT DISTINCT [Link]

FROM Class C
tio

WHERE [Link] = 'R128'

UNION
lu

SELECT [Link]
So

FROM Class C, Enrolled E

WHERE [Link] = [Link]
GROUP BY [Link]
S-

HAVING COUNT([Link]) >= 5;

BM

This query uses a UNION to combine the results of two conditions: classes
meeting in room R128 or classes with five or more students enrolled.
D

(iii) For all levels except JR, print the level and the average age of students
for that level.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

SELECT [Link], AVG([Link]) AS Avg_Age

FROM Student S
WHERE [Link] <> 'JR'
GROUP BY [Link];

This query calculates the average age of students for each level except for

A
juniors.

IT
C
EN
(iv) For each faculty member that has taught classes only in room R128,
print the faculty member’s name and the total number of classes he or she
has taught.

-R
SELECT [Link], COUNT([Link]) AS Total_Classes
FROM Faculty F, Class C 24
20
WHERE [Link] = [Link]
AND [Link] = 'R128'
n_

GROUP BY [Link]
HAVING COUNT(DISTINCT [Link]) = 1;
tio

This query finds faculty members who have only taught classes in room R128
lu

and returns their name and the total number of classes they have taught.
So
S-

(v) Find the names of students not enrolled in any class.

BM

SELECT [Link]
FROM Student S
D

WHERE [Link] NOT IN (SELECT [Link] FROM Enrolled E);

This query retrieves the names of students who are not enrolled in any class by
using a NOT IN subquery.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Q7b. What do you understand by correlated and nested queries in SQL?

Explain with a suitable example.

● Correlated Query: A correlated query is a subquery that refers to a

column from the outer query. It is executed repeatedly, once for each row
selected by the outer query.

Example:

A
IT
SELECT Sname, age

C
FROM Student S

EN
WHERE age > (SELECT AVG(age) FROM Student WHERE Branch =
[Link]);

-R
Here, the inner query refers to the outer query's Branch, and for each student, the
average age of students in that branch is calculated.
24
20
● Nested Query: A nested query is a query within another query, where the
inner query is executed once and its result is passed to the outer query.
n_

Example:
tio

SELECT Sname, age

lu

FROM Student
WHERE age > (SELECT AVG(age) FROM Student);
So
S-

Here, the inner query calculates the average age once, and the result is used to
compare against the age of each student.
BM

Q7c. Discuss the ACID properties of a database transaction.

D

The ACID properties ensure that database transactions are processed reliably.
They are:

1. Atomicity: Ensures that all operations within a transaction are completed.

If any part of the transaction fails, the entire transaction is rolled back, and
the database remains unchanged.
Example: If a bank transfer transaction debits one account but fails to

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

credit another, the entire transaction is reversed.

2. Consistency: Ensures that a transaction brings the database from one valid
state to another. The database must meet all the rules and constraints after
the transaction.
Example: If a transaction violates any constraints, such as a foreign key
constraint, the database should be rolled back.
3. Isolation: Ensures that transactions are executed in isolation from one

A
another. Intermediate results of a transaction are not visible to other
transactions until the transaction is committed.

IT
Example: If two users try to update the same account balance

C
simultaneously, isolation ensures that both transactions are handled in a
serializable manner.

EN
4. Durability: Ensures that once a transaction is committed, it remains so,
even in the event of a system crash. The results of the transaction are

-R
permanently stored in the database.
Example: Once a bank transfer transaction is committed, it is reflected in
the database even if the system crashes immediately afterward.
24
20
n_

Q8a. What are the views in SQL? Explain with examples.

tio

Views in SQL are virtual tables based on the result of an SQL query. They do not
store data themselves but provide a way to look at and manipulate the result of a
lu

query as if it were a table.

So

Example:
S-

CREATE VIEW HighSalaryEmployees AS

SELECT EmpID, EmpName, Salary
BM

FROM Employees
WHERE Salary > 50000;
D

In this example, a view called HighSalaryEmployees is created based on the

result of a query that selects employees with a salary greater than 50,000. Once
the view is created, you can query it as if it were a table:

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

SELECT * FROM HighSalaryEmployees;

Benefits of Views:

1. Simplicity: They simplify complex queries by encapsulating them in a

view.
2. Security: You can restrict access to certain data by allowing users to query

A
a view instead of the base table.

IT
3. Data Abstraction: Views provide an abstraction layer over the database
schema.

C
EN
Q8b. In SQL, write the usage of GROUP BY and HAVING clauses with

-R
suitable examples.

24
● GROUP BY: The GROUP BY clause is used to group rows that have the
same values in specified columns. It is often used with aggregate functions
20
(COUNT, SUM, AVG, etc.).
● HAVING: The HAVING clause is used to filter the groups based on certain
conditions, similar to WHERE but for groups.
n_

Example:
tio
lu

SELECT DeptID, COUNT(EmpID) AS EmployeeCount

So

FROM Employees
S-

GROUP BY DeptID
BM

HAVING COUNT(EmpID) > 5;

D

● GROUP BY DeptID groups the rows by department.

● HAVING COUNT(EmpID) > 5 filters the groups to only those
departments with more than 5 employees.

In this query, we count the number of employees in each department and return

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

only the departments with more than 5 employees.

Q8c. Discuss the types of problems that may encounter with transactions
that run concurrently.

When transactions run concurrently, several problems can arise, affecting the

A
consistency and isolation of the database. These problems include:

IT
1. Lost Update: Occurs when two transactions simultaneously update the

C
same data. The update of one transaction may overwrite the other, leading

EN
to lost data.
Example:
○ Transaction A reads a value of 100 from the database.

-R
○ Transaction B also reads the value 100, increments it to 110, and
writes it back.
24
○ Transaction A increments its original value (100) to 105 and writes
it back, thus "losing" the update made by Transaction B.
20
2. Dirty Read: Occurs when a transaction reads data that has been written by
another transaction but not yet committed. If the second transaction is
n_

rolled back, the first transaction has read invalid data.

Example:
tio

○ Transaction A updates a row, but before committing, Transaction B

reads that updated data.
lu

○ If Transaction A rolls back, the data read by Transaction B is

invalid.
So

3. Non-Repeatable Read: Happens when a transaction reads the same data

multiple times and gets different values due to modifications by other
S-

concurrent transactions.
Example:
BM

○ Transaction A reads a row.

○ Transaction B updates that row and commits.
○ Transaction A reads the same row again and finds different data.
D

4. Phantom Read: Occurs when a transaction reads a set of rows that satisfy a
certain condition, but when it repeats the query, new rows satisfying the
condition appear due to insertions by other transactions.
Example:
○ Transaction A reads all rows where Salary > 50000.
○ Transaction B inserts a new row with Salary = 60000.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

○ When Transaction A re-executes the query, it gets different results

due to the newly inserted row.

MODULE 5

A
a. What is the two-phase locking protocol? How does it guarantee

IT
serializability?

C
The two-phase locking (2PL) protocol is a concurrency control method used to

EN
ensure serializability of database transactions. A transaction is said to follow the
two-phase locking protocol if all locking operations (acquiring locks) precede the
first unlock operation (releasing locks). This divides the transaction into two

-R
phases:

24
● Growing Phase: The transaction acquires all required locks and cannot
release any lock.
20
● Shrinking Phase: The transaction releases the locks and cannot acquire
any more.
n_

By enforcing that no new locks can be acquired after the release of any lock, 2PL
guarantees that the transactions will be executed in a serializable manner, i.e., the
tio

result of concurrently running transactions will be the same as if they were

executed sequentially
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

A
IT
C
EN
-R
24
20
n_
tio
lu
So
S-
BM
D

b. Describe the wait-die and wound-wait protocols for deadlock prevention.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

Wait-Die Protocol: In this protocol, if an older transaction requests a lock held by

A
a younger transaction, the older transaction waits. If a younger transaction

IT
requests a lock held by an older transaction, the younger transaction is aborted

C
("dies") and restarted later with the same timestamp.
Wound-Wait Protocol: In this scheme, if an older transaction requests a lock held

EN
by a younger transaction, the younger transaction is aborted ("wounded") and
restarted later. However, if a younger transaction requests a lock held by an older

-R
transaction, the younger transaction waits​

c. List and explain the four major categories of NoSQL systems.

The four major categories of NoSQL systems are:

24
20
1. Document-based NoSQL Systems: Store data as documents in formats
n_

like JSON or BSON, accessible via document IDs.

2. Key-Value Stores: Simple data models that store data as key-value pairs
tio

for fast access.

3. Column-Based (Wide Column) NoSQL Systems: Partition data into
lu

columns or families of columns, optimized for queries across a few

columns.
So

4. Graph-Based NoSQL Systems: Represent data in graphs, where nodes

are entities, and edges represent relationships between entities. These
S-

systems are optimal for relationship-heavy queries.

BM

Document-Based NoSQL:

{
D

"_id": 1,

"name": "John",

"age": 30,

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

"email": "john@[Link]"

Key-Value Store:

A
{

IT
"John": {"age": 30, "email": "john@[Link]"}

C
}

EN
-R
Column-Based Store:

| Row Key | Name | Age | Email 24

|
20
|---------|-------|-----|--------------------|

|1 | John | 30 | john@[Link] |
n_
tio

Graph-Based (Neo4j):
lu

(John)-[:FRIEND_OF]->(Jane)
So
S-
BM

a. What is Multiple Granularity Locking? How is it implemented using

intention locks? Explain.
D

Multiple granularity locking allows a database system to lock data items at

different levels of granularity (e.g., entire databases, files, pages, or records)
efficiently. The system uses intention locks to indicate at higher levels of the
hierarchy the intention to lock data at finer levels.

● Intention Shared (IS): Indicates that a shared lock is requested on a

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

lower-level data item.

● Intention Exclusive (IX): Indicates that an exclusive lock is requested on
a lower-level data item.
● Shared-Intention Exclusive (SIX): Indicates that a shared lock is held on
a higher-level item, with the intention of locking lower-level items
exclusively​

A
IT
C
EN
-R
24
20
n_
tio
lu
So

The compatibility table of the three intention locks, and the actual shared and
S-

exclusive locks, is shown in Figure 21.8. In addition to the three types of

BM

intention locks, an appropriate locking protocol must be used. The multiple

granularity locking (MGL) protocol consists of the following rules:

1. The lock compatibility (based on Figure 21.8) must be adhered to.

D

2. The root of the tree must be locked first, in any mode.

3. A node N can be locked by a transaction T in S or IS mode only if the parent

node N is already locked by transaction T in either IS or IX mode.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

4. A node N can be locked by a transaction T in X, IX, or SIX mode only if the

parent of node N is already locked by transaction T in either IX or SIX mode.

5. A transaction T can lock a node only if it has not unlocked any node (to
enforce the 2PL protocol).

6. A transaction T can unlock a node, N, only if none of the children of node N

are currently locked by T

A
IT
b. Discuss the following MongoDB CRUD operations with their formats:
Insert: Adds new documents into a collection using the command:

C
EN
[Link](document)

-R
Delete: Removes documents from a collection using the command:

[Link](query) 24
20
n_

Read: Retrieves documents from a collection using the command:

tio

[Link](query)
lu
So

Each operation corresponds to creating, reading, updating, or deleting data in the

MongoDB database​.
update, delete).
S-

Documents can be created and inserted into their collections using the insert
BM

operation, whose format is:

db..insert() The parameters of the insert operation can include either a single
document or an array of documents.
D

The delete operation is called remove, and the format is:

db..remove()
The documents to be removed from the collection are specified by a Boolean
condition on some of the fields in the collection documents. There is also an
update operation, which has a condition to select certain documents, and a $set
clause to specify the update.

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

It is also possible to use the update operation to replace an existing document

with another one but keep the same ObjectId. For read queries, the main
command is called find, and the format is: db..find() General Boolean conditions
can be specified as , and the documents in the collection that return true are
selected for the query result. For a full discussion of the MongoDb CRUD
operations, see the MongoDB online documentation in the chapter references.

A
c. Briefly discuss about Neo4j data model.

IT
The Neo4j data model is based on a graph structure where:

C
● Nodes: Represent entities such as people, places, or objects, and can have

EN
properties.
● Relationships: Represent connections between nodes and are directed.
They can also have properties.

-R
● Properties: Key-value pairs associated with nodes or relationships.
● Labels: Group nodes into sets for querying. Nodes can have zero or
multiple labels. 24
20
The graph-based model is flexible and well-suited for complex queries involving
relationships, as seen in social networks, fraud detection, and recommendation
n_

systems
tio

1. Labels and Properties

● Labels categorize nodes. For example, in Figure 24.4(a), the nodes are
lu

labeled as EMPLOYEE, DEPARTMENT, PROJECT, and

So

LOCATION.
● Properties are attributes stored in curly brackets {...}. Nodes can have
S-

multiple labels, such as PERSON:EMPLOYEE:MANAGER. This is

similar to an entity and its subclasses in entity-relationship models (ER
BM

and EER).

2. Relationships and Relationship Types

D

● Relationships define connections between nodes. For example, Figure

24.4(b) shows relationships like WorksFor, Manager, LocatedIn, and
WorksOn.
● WorksOn has properties, such as Hours, which specify more details about
the relationship.
● Relationships can be traversed in either direction, even if they are shown

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])

 lOMoARcPSD|50868604

with arrows (→) indicating a specific direction.

3. Paths

● A path is a sequence of nodes and relationships that form part of a query.

It helps to navigate the graph and retrieve data matching a specific pattern.
● The concept is similar to path expressions in object databases (OQL) or
XML query languages (XPath, XQuery).

A
IT
4. Optional Schema

C
● Neo4j can function without a predefined schema. However, version 2.0

EN
introduced schema-related functions like indexes and constraints. For
instance, a key constraint can ensure that a certain property (e.g., EmpId)
is unique within a label (e.g., EMPLOYEE).

-R
5. Indexing and Node Identifiers

● When a node is created, Neo4j assigns it a unique system-defined24

20
identifier.
● Users can create indexes based on node properties for efficient retrieval.
For example, EmpId could be used to index EMPLOYEE nodes, and Dno
n_

for DEPARTMENT nodes.

tio
lu
So
S-
BM
D

Downloaded by Nikhil Kannale (nikhilkannale7@[Link])