K.S.

SCHOOL OF ENGINEERING AND MANAGEMENT, BANGALORE - 560109

DEPARTMENT OF COMPUTER SCIENCE AND BUSINESS SYSTEMS
SESSION: 2023-2024 (EVEN SEMESTER)
I SESSIONAL TEST SCHEME AND SOLUTION
SET B

USN
Degree : B.E Semester : III
Branch : CS & BS Course Code : BCS 403
Course Title : Database Management Systems Date : 30/05/2024
Duration : 90 Minutes Max Marks : 30

Note: Answer ONE full question from each part.

Q
SCHEME & SOLUTION Marks
No.

2M

1 (a) 5
 3M

➢ The typical DBMS components are represented in Figure. It is divided

into two parts. The top part of the figure refers to the various users of the
database environment and their interfaces. The lower part shows the
internals of the DBMS responsible for storage of data and processing of
transactions.
➢ The database and the DBMS catalogue are usually stored on disk. The
stored data manager module of the DBMS controls access to DBMS
information that is stored on disk.
➢ The top part of Figure shows interfaces for the DBA staff who defines the
database and manipulate its definition using the DDL and other privileged
commands , casual users who work with interactive interfaces to
formulate queries, application programmers who create programs
using some host programming languages, and parametric users who do
data entry work by supplying parameters to predefined transactions.
➢ The DDL compiler processes schema definitions, specified in the DDL,
and stores descriptions of the schemas (meta-data) in the DBMS
catalogue.

➢ Casual users interact with the interactive query interface. The queries are
parsed and validated for correctness of the query syntax, the names of
files and data elements by a query compiler. This internal query is
subjected to query optimization. The query optimizer is concerned with
the ordering of operations, elimination of redundancies, and use of correct
algorithms and indexes during execution.
➢ The query optimizer consults the system catalog for statistical and other
physical information about the stored data and generates executable code
that performs the necessary operations for the query and makes calls on
the runtime processor

Graphical User Interface (GUI): 1M

Types of Users: Casual users, business analysts, non-technical personnel.
Description: GUIs provide a visual interface with graphical elements such as
menus, buttons, and icons.
Features: Intuitive navigation, drag-and-drop functionality, visual representations
(e.g., charts, graphs), form-based data entry.
Example: A web-based administration console for managing database settings,
data entry forms in enterprise applications.
Command-Line Interface (CLI): 1M
(b) Types of Users: Database administrators (DBAs), power users, technical 5
personnel.
Description: CLI allows users to interact with the database by entering text-based
commands.
Features: Access to advanced functionalities, scripting capabilities, direct control
over database operations.
Example: Command-line tools such as SQL*Plus for Oracle, psql for
PostgreSQL, mysql for MySQL.
Forms-Based Interface: 1M
Types of Users: Data entry clerks, administrative staff, end users.
Description: Forms-based interfaces present users with structured forms for
 entering and updating data.
Features: Input validation, dropdown menus, checkboxes, radio buttons, and
wizards for complex tasks.
Example: Online forms for customer registration, order processing, and inventory
management.
Report Generators: 1M
Types of Users: Business analysts, decision-makers, executives.
Description: Report generators allow users to create and customize reports based
on database queries.
Features: Drag-and-drop report design, templates, formatting options, scheduling
and distribution capabilities.
Example: Business intelligence tools like Tableau, Power BI, and Crystal
Reports.
Web-Based Interface: 1M
Types of Users: Remote users, clients, customers, distributed teams.
Description: Web-based interfaces provide access to the DBMS via a web
browser over the internet or intranet.
Features: Cross-platform compatibility, accessibility from anywhere with internet
access, role-based access control.
Example: Web portals for online banking, e-commerce websites, project
management systems.

1M

➢ Data independence is a fundamental concept in database management

systems (DBMS) that refers to the ability to modify the database schema
(structure) without affecting the application programs that access the data. It
allows for changes in the database organization, storage structures, or
access methods without requiring changes to the application programs or
queries that use the data. Data independence enhances flexibility,
maintenance, and scalability in database systems.

There are two main types of data independence:

Logical Data Independence:

2M
C) 5
➢ Logical data independence refers to the ability to change the conceptual
schema (logical schema) of the database without affecting the external
schema or application programs.Changes to the logical schema involve
modifications to the way data is organized, modeled, or represented at the
conceptual level, such as adding, modifying, or dropping tables, columns,
or relationships.
➢ Application programs accessing the data through the external schema are
shielded from these changes, as they interact with the data through a
conceptual view of the database.Logical data independence allows for
modifications to the database design, such as normalization,
denormalization, or restructuring, without impacting the applications that
use the data.

Physical Data Independence: 2M

➢ Physical data independence refers to the ability to change the physical

 storage structures or access methods of the database without affecting the
logical or conceptual schema, as well as the external schema or application
programs.Changes to the physical schema involve modifications to how
data is stored, indexed, or accessed on the underlying storage devices, such
as adding, modifying, or reorganizing files, indexes, or data storage
formats.
➢ Application programs accessing the data through the external schema are
insulated from these changes, as they interact with the data through a
logical view of the database.Physical data independence allows for
optimizations in database performance, storage utilization, or data
distribution, such as partitioning, indexing, or implementing storage
compression, without impacting the applications that use the data.

Example: 1M

➢ Consider a database system that stores information about employees,

including their ID, name, department, and salary. Application programs
access this data through an external schema that defines views or tables for
specific functionalities, such as payroll processing or employee
management.
➢ Logical Data Independence: Suppose the database administrator decides to
split the "Employees" table into separate "BasicInfo" and "SalaryInfo"
tables to improve data organization. This change to the logical schema does
not affect the application programs, as they continue to access employee
data through the same external schema, which abstracts the underlying
database structure changes.
➢ Physical Data Independence: Suppose the database administrator decides to
migrate the database from a single server to a distributed environment for
better scalability. This change to the physical schema involves
redistributing data across multiple servers and implementing data
replication or partitioning techniques. Application programs remain
unaffected by this change, as they interact with the data through the same
logical view provided by the external schema.

1M
i) Database:
➢ A database is a structured collection of data organized and stored
electronically in a computer system. It typically consists of tables
(relations) that store data in rows and columns, along with relationships
between tables. Databases are designed to efficiently manage, retrieve,
and manipulate data to meet the needs of users and applications.

2(a) ii) Metadata: 1M 5

➢ Metadata refers to data that describes other data. It provides information
about the characteristics, structure, and context of data stored in a
database. Metadata includes details such as data types, column names,
table names, relationships between tables, data definitions, and
constraints. It helps users and applications understand and manage the
data within the database.
iii) Data Dictionary: 1M
➢ A data dictionary is a centralized repository that stores metadata and data
 definitions for a database system. It contains detailed descriptions of data
elements, including their names, data types, lengths, formats, and
meanings. The data dictionary serves as a reference for database
administrators, developers, and users to understand the structure and
content of the database.
iv) Domain, Key, Integrity Constraint: 2M
➢ Domain: A domain defines the set of allowable values for a specific
attribute or column in a database table. It specifies the data type, range,
format, and constraints that apply to the attribute's values. For example, a
domain for the "Age" attribute may specify that valid ages must be
integers between 0 and 150.
➢ Key Constraint: A key constraint defines a set of attributes (columns) in a
table that uniquely identify each row (record) in the table. A primary key
is a type of key constraint that uniquely identifies each row and ensures
data integrity by preventing duplicate or null values. For example, an
"EmployeeID" column may serve as the primary key in an "Employees"
table.
➢ Integrity Constraint: An integrity constraint is a rule or condition that
enforces the accuracy, consistency, and validity of data stored in a
database. It ensures that data meets specified criteria and maintains data
integrity. Examples of integrity constraints include entity integrity
constraints (e.g., primary key constraints), referential integrity constraints
(e.g., foreign key constraints), and domain constraints (e.g., check
constraints).

(b) 5

➢ This Company ER diagram illustrates key information about Company,

including entities such as employee, department, project and dependent.
It allows to understand the relationships between entities.
Entities and their Attributes are
Employee Entity : Attributes of Employee Entity are Name, Id, Address,
 Gender, Dob and Doj.
Id is Primary Key for Employee Entity.
Department Entity : Attributes of Department Entity are D_no, Name and
Location.
D_no is Primary Key for Department Entity.
Project Entity : Attributes of Project Entity are P_No, Name and Location.
P_No is Primary Key for Project Entity.
Dependent Entity : Attributes of Dependent Entity are D_no, Gender and
relationship.
Relationships are :
Employee’s works in Departments –
Many employee works in one Department but one employee can not work in
many departments.
Manager controls a Department –
employee works under the manager of the Department and the manager records
the date of joining of employee in the department.
Department has many Projects –
One department has many projects but one project can not come under many
departments.
Employee works on project –
One employee works on several projects and the number of hours worked by
the employee on a single project is recorded.
Employee has dependents –
Each Employee has dependents. Each dependent is dependent of only one
employee.

Entity Integrity Constraint (Primary Key Constraint):Ensures that each row

in a table is uniquely identifiable. It typically involves defining a primary key for
a table, which must be unique and not null.

Referential Integrity Constraint (Foreign Key Constraint):Maintains the

consistency between related tables. It ensures that values in a foreign key column
match values in the primary key column of another table or are null.

c) Domain Integrity Constraint:Enforces data validity by defining permissible

values within a column. It can involve data type constraints (e.g., integer, string)
or check constraints (e.g., ensuring a date is within a specific range).

Entity-Relationship (ER) Constraints:Define relationships between entities in

an entity-relationship diagram (ERD). For example, cardinality constraints (such
as one-to-one, one-to-many, many-to-many) specify how entities relate

Generalization

➢ Generalization is a process of generalizing an entity which contains

generalized attributes or properties of generalized entities. The entity that
3(a) is created will contain the common features. Generalization is a Bottom 5
up process.

We can have three sub entities as Car, Truck, Motorcycle and these three entities
can be generalized into one general super class as Vehicle.
 Aggregation

➢ Aggregation represents relationship between a whole object and its

component. Using aggregation we can express relationship among
relationships. Aggregation shows ‘has-a’ or ‘is-part-of’ relationship
between entities where one represents the ‘whole’ and other ‘part’.

Consider a ternary relationship Works_On between Employee, Branch and

Manager. Now the best way to model this situation is to use aggregation, So, the
relationship-set, Works_On is a higher level entity-set. Such an entity-set is
treated in the same manner as any other entity-set. We can create a binary
relationship, Manager, between Works_On and Manager to represent who
manages what tasks.

2M
➢ Outer join operations in relational algebra are used to combine tuples
from two relations even if there is no matching tuple in one of the
relations. There are three types of outer joins: left outer join, right outer
join, and full outer join.
Students (sid, name):
| sid | name |
(b) |-----|--------| 5

| 101 | Alice |
| 102 | Bob |
| 103 | Charlie|
Grades (sid, grade):
| sid | grade |
|-----|-------|
| 101 | A |
| 103 | B |
| 104 | C |
Left Outer Join: 1M

➢ A left outer join returns all tuples from the left relation (Students) and
matching tuples from the right relation (Grades). If there is no matching
tuple in the right relation, NULL values are used.

Students ⋈ᴸ Grades
Applying left outer join to the given example:
| sid | name | grade |
|-----|---------|-------|
| 101 | Alice | A |
| 102 | Bob | NULL |
| 103 | Charlie | B |
Right Outer Join: 1M
➢ A right outer join returns all tuples from the right relation (Grades) and
matching tuples from the left relation (Students). If there is no matching
tuple in the left relation, NULL values are used.

Students ⋈ᴿ Grades
Applying right outer join to the given example:
| sid | name | grade |
|-----|---------|-------|
| 101 | Alice | A |
| 103 | Charlie | B |
| 104 | NULL |C |
Full Outer Join: 1M
➢ A full outer join returns all tuples from both relations. If there is no
matching tuple in one of the relations, NULL values are used for the
attributes from that relation.

Students ⋈ᶠ Grades
Applying full outer join to the given example:
| sid | name | grade |
 |-----|---------|-------|
| 101 | Alice | A |
| 102 | Bob | NULL |
| 103 | Charlie | B |
| 104 | NULL |C |
These examples illustrate how left, right, and full outer joins combine tuples from
two relations, considering matching tuples and handling cases where there is no
match.

1M
i) For all customers who have a loan from the bank, find their names, loan
numbers, and loan amount.
SELECT c.customer_name, l.loan_number, l.amount
FROM customer c
INNER JOIN borrower b ON c.customer_name = b.customer_name
INNER JOIN loan l ON b.loan_number = l.loan_number;
1M
ii) Find the customer names, loan numbers, and loan amounts, for all loans at the
Perry ridge branch.
SELECT c.customer_name, l.loan_number, l.amount
FROM customer c
INNER JOIN borrower b ON c.customer_name = b.customer_name
C) INNER JOIN loan l ON b.loan_number = l.loan_number
WHERE l.branch_name = 'Perry ridge';
1M
iii) Find the names of all branches that have assets greater than those of at least
one branch located in Brooklyn.
SELECT DISTINCT b1.branch_name
FROM branch b1
WHERE b1.assets > ANY (SELECT b2.assets FROM branch b2 WHERE
b2.branch_city = 'Brooklyn');
1M
iv) Find the average account balance of those branches where the account balance
is greater than Rs. 1200.
SELECT branch_name, AVG(balance) AS avg_balance
FROM account
 GROUP BY branch_name
HAVING AVG(balance) > 1200;
1M
v) Find the maximum across all branches of the total balance at each branch.
SELECT branch_name, SUM(balance) AS total_balance
FROM account
GROUP BY branch_name
ORDER BY total_balance DESC
LIMIT 1;

➢ Database users can be classified into several categories based on their

roles and interactions with the database. Here are some common
classifications along with explanations of their interfaces to the database
management system (DBMS):

Administrative Users: 2M

➢ These users are responsible for managing the overall database system,
including installation, configuration, security, and performance tuning.
Interface: Administrative users typically interact with the DBMS through
specialized tools or command-line interfaces designed for system
administration tasks. These interfaces provide features for managing users,
configuring database settings, monitoring performance, and performing
backup and recovery operations.
Database Designers:

➢ Database designers are responsible for designing the database schema,

including defining tables, relationships, constraints, and indexes.
Interface: Database designers often use graphical user interfaces (GUIs) or
4(a) data modeling tools to design and visualize the database schema. These 5
tools allow designers to create and modify database objects using drag-
and-drop interfaces, generate SQL scripts, and perform schema validation.
Database Administrators (DBAs): 3M

➢ DBAs are responsible for managing and maintaining the database

system, including security, backup and recovery, performance monitoring,
and optimization.
Interface: DBAs typically use specialized DBMS interfaces or command-line
tools that provide administrative features for managing users, roles, permissions,
backups, and other system-level tasks. These interfaces may also include
monitoring dashboards, diagnostic tools, and performance tuning utilities.
Application Developers:

➢ Application developers create software applications that interact with the

database to store, retrieve, and manipulate data.
Interface: Developers interact with the DBMS through application
programming interfaces (APIs) or database libraries provided by the
DBMS vendor. These interfaces allow developers to execute SQL queries,
transactions, and stored procedures from their application code.
 Alternatively, developers may use object-relational mapping (ORM)
frameworks to interact with the database using high-level object-oriented
abstractions.
End Users:

➢ End users are the consumers of the data stored in the database. They may
include business analysts, report writers, and other non-technical users
who need access to the database for querying and reporting purposes.
Interface: End users typically interact with the database through front-end
applications or reporting tools that provide user-friendly interfaces for executing
predefined queries, generating reports, and visualizing data. These interfaces
abstract the complexity of SQL queries and database structures, allowing end
users to access and analyze data without requiring deep technical knowledge.
➢ Each category of database users has specific roles and responsibilities,
and their interfaces to the DBMS are tailored to support their respective
tasks and requirements.

Book: (book_id, title, author)

Copy: (copy_id, book_id)
Borrower: (borrower_id, name)
Loan: (loan_id, copy_id, borrower_id, due_date)
Now, let's discuss each concept:

(i) Weak Entity Type:

➢ A weak entity type is an entity that cannot be uniquely identified by its

attributes alone; it depends on another entity (known as the identifying or
owner entity) for its existence.
Example: In our library database, "Copy" is a weak entity type because a copy
cannot exist without its corresponding book. The copy's existence depends on the
book it belongs to.
(ii) Participation Constraint: 1M

➢ A participation constraint specifies whether the existence of an entity in a

(b) relationship is mandatory (total participation) or optional (partial 5
participation).
Example: In our library database, the participation constraint between "Book"
and "Copy" is total because a book must have at least one copy. However, the
participation constraint between "Borrower" and "Loan" is partial because not all
borrowers may have loans.

(iii) Cardinality Ratio: 1M

➢ Cardinality ratio specifies the number of instances of one entity that can
be associated with a single instance of another entity in a relationship.
Example: In our library database, the cardinality ratio between "Book" and
"Copy" is one-to-many because one book can have multiple copies, but each
copy belongs to only one book.
(iv) Recursive Relationship:
1M
➢ A recursive relationship occurs when an entity is related to itself through
a relationship set.
 Example: In our library database, we can have a recursive relationship between
"Borrower" and "Borrower" to represent borrowers who recommend books to
other borrowers. For example, we could have a relationship "Recommends" with
attributes like "recommendation_id", "borrower_id",
"recommended_to_borrower_id", and "recommendation_date".
(v) Specialization: 1M

➢ Specialization is the process of defining subtypes based on attributes or

roles.
Example: In our library database, we could have a specialization of "Borrower"
into "Student" and "Faculty" based on their attributes or roles. For example,
"Student" may have attributes like "student_id" and "major", while "Faculty"
may have attributes like "faculty_id" and "department".
(i) Retrieve the name, address, salary of employees who work for the Research
department.

π_Name, Address, Salary (σ_Dname='Research'(EMP ⨝ Dno=Dept.DNum

(σ_Dname='Research'(DEPT))))
1M
(ii) Find the names of employees who work on all projects controlled by
department number 4.

π_Name ((EMP ⨝ ESSN=WORKS_ON.ESSN WORKS_ON) ÷ π_Pnumber

(σ_Dnum=4(PROJECT)))
1M
(iii) Retrieve the SSN of all employees who are either in department number 4 or
directly supervise an employee who works in department number 4.
(c) 5
π_SSN (σ_Dno=4(EMP)) ∪ π_SuperSSN (σ_Dno=4(EMP))
1M
(iv) Retrieve the names of employees who have no dependents.

π_Name (EMP - (EMP ⨝ SSN=ESSN DEPENDENT)) 1M

(v) Retrieve each department number, the number of employees in the
department, and their average salary.
π_Dno, COUNT(SSN), AVG(Salary) (EMP GROUP BY Dno)
These queries represent the desired operations using relational algebra operations.

(i) Retrieve the name, address, salary of employees who work for the
Research department. 1M

(c) SELECT EMP.Name, EMP.Address, EMP.Salary 5

FROM EMP
INNER JOIN DEPT ON EMP.Dno = DEPT.Dnum
WHERE DEPT.Dname = 'Research';
 (ii) Find the names of employees who work on all projects controlled by
department number 4. 1M

SELECT DISTINCT EMP.Name

FROM EMP
WHERE NOT EXISTS (
SELECT *
FROM PROJECT
WHERE PROJECT.Dnum = 4
AND PROJECT.Pnumber NOT IN (
SELECT WORKS_ON.Pno
FROM WORKS_ON
WHERE WORKS_ON.ESSN = EMP.SSN
)
);

(iii) Retrieve the SSN of all employees who are either in department number 4 or
directly supervise an employee who works in department number 4. 1M

SELECT DISTINCT EMP.SSN

FROM EMP
WHERE EMP.Dno = 4
OR EMP.SSN IN (
SELECT DISTINCT EMP1.SuperSSN
FROM EMP AS EMP1
INNER JOIN EMP AS EMP2 ON EMP1.SSN = EMP2.SuperSSN
WHERE EMP2.Dno = 4
);

(iv) Retrieve the names of employees who have no dependents.

1MSELECT EMP.Name

FROM EMP
WHERE EMP.SSN NOT IN (
SELECT ESSN
FROM DEPENDENT
);(v) Retrieve each department number, the number of employees in the
department, and their average salary.
1M
SELECT DEPT.Dnum, COUNT(EMP.SSN) AS NumEmployees,
AVG(EMP.Salary) AS AvgSalary
FROM DEPT
INNER JOIN EMP ON DEPT.Dnum = EMP.Dno
GROUP BY DEPT.Dnum;

Course In charge HOD IQAC- Coordinator Principal