Name:- Prajwal Digambar Kute

Sub :- DBMS (PYQ 2022)

Roll no:- 60

PRN:-2110121245062
Q. 1 Solve Any Two of the following.
A) Why would you choose a database system instead of simple storing data in
file processing system? Compare file processing system and DBMS.

Choosing a database system over a simple file processing system is often a wise decision when
dealing with complex, structured data and when you require more advanced features and
capabilities. Here are some key reasons for choosing a database system.
Data Integrity: Database management systems (DBMS) provide mechanisms to ensure data
integrity. They enforce data constraints, such as unique keys and referential integrity, to maintain the
accuracy and consistency of the data.

Data Security: DBMS offers access control mechanisms to protect data from unauthorized access
and modifications. User roles and permissions can be defined to restrict who can perform specific
operations on the data.
Data Redundancy Reduction: In a file processing system, data redundancy is common, leading to
increased storage requirements and data inconsistency. DBMS minimizes data redundancy through
normalization, which can save storage space and reduce the likelihood of errors.
Data Retrieval and Query Capabilities: DBMS provides a structured way to query and retrieve data
using SQL (Structured Query Language). This allows for efficient data retrieval and analysis, making
it easier to answer complex questions about the data.
Concurrency Control: DBMS can manage concurrent access to data, allowing multiple users to work
with the data simultaneously while ensuring data consistency and preventing conflicts.
Data Scalability: Database systems are designed to handle large volumes of data and are scalable.
You can add more storage, increase processing power, and optimize performance as your data
needs grow.
Data Recovery and Backup: DBMS includes features for data backup and recovery, reducing the risk
of data loss in case of hardware failures or other issues.
Data Indexing: DBMS creates indexes to facilitate quick data retrieval. This improves query
performance, especially when dealing with large datasets.
Data Relationships: DBMS supports the establishment of relationships between data entities
through keys and foreign keys, allowing for structured and efficient data modeling.
ACID Properties: DBMS ensures transactions follow ACID properties (Atomicity, Consistency,
Isolation, Durability), which guarantees that data changes are reliable and maintain data integrity.

File Processing System:

File processing systems are suitable for simpler, smaller-scale applications where data
requirements are minimal and straightforward.
They lack built-in data integrity and security features, requiring you to implement these aspects
manually, which can be error-prone.
Data redundancy is common in file processing systems, which can lead to inefficiencies and
inconsistency.
Retrieving and querying data from files can be less efficient, and complex queries are challenging to
implement.

Handling concurrent access and maintaining data consistency can be difficult without a DBMS.

File processing systems may not be as scalable or adaptable to changing data requirements.
In summary, a database system is the preferred choice when you need to manage complex,
structured data with requirements for data integrity, security, and efficient data retrieval. File
processing systems may be sufficient for smaller, simpler applications, but they lack the advanced
features and capabilities that modern DBMSs offer.

●
B) Define an Entity and Attribute. Explain the different types of attributes that
occur in an ER diagram model, with an example.

In the context of Entity-Relationship (ER) diagrams, an entity and an attribute are fundamental
concepts used to model the structure of a database.
Entity:
An entity represents a real-world object, concept, or thing that can be uniquely identified and stored
in a database. In an ER diagram, entities are typically depicted as rectangles. They serve as the
building blocks of the database, and each entity corresponds to a table in a relational database.
Example: Let's consider a library database. In this case, "Book," "Author," "Borrower," and
"LibraryBranch" can be considered as entities. Each of these entities will have attributes associated
with them to describe their properties.
Attribute:
An attribute is a characteristic or property of an entity. It describes the data that can be stored for
each instance of the entity. Attributes are typically depicted as ovals connected to their respective
entity in an ER diagram. Each attribute represents a field or column in the corresponding database
table.
Types of Attributes in an ER Diagram:

Simple Attribute: A simple attribute contains atomic values that cannot be divided further. For
example, the "Title" attribute of the "Book" entity is a simple attribute.
Composite Attribute: A composite attribute can be divided into smaller, meaningful components with
independent meanings. For instance, the "Address" attribute of the "Author" entity can be divided into
"Street," "City," "State," and "ZIP Code."
Derived Attribute: A derived attribute's value can be calculated from other attributes. It is not stored
directly but can be computed when needed. For example, the "Age" attribute of the "Borrower" entity
can be derived from the "Date of Birth" attribute.
Multi-valued Attribute: A multi-valued attribute can hold multiple values for a single entity instance.
For example, the "Phone Numbers" attribute of the "Borrower" entity may have multiple phone
numbers associated with it.
Key Attribute: A key attribute uniquely identifies each entity instance within an entity set. It is crucial
for maintaining the uniqueness and integrity of the database. In the "Book" entity, an example of a
key attribute could be "ISBN" (International Standard Book Number).
Example of Attributes: Consider the "Book" entity in a library database. It could have the following
attributes:
ISBN (Key Attribute)
Title (Simple Attribute)
Author (Composite Attribute with sub-attributes: "First Name" and "Last Name")
Published Year (Simple Attribute)

Price (Simple Attribute)

Edition (Simple Attribute)
Keywords (Multi-valued Attribute)
In summary, entities and attributes are essential components of ER diagrams used to model the
structure of a database. Attributes provide detailed information about the entities and can have
various types, depending on their characteristics and the nature of the data they represent.

Q.2 Solve Any Two of the following.

 A) Define and differentiate the following relational algebra operators with
suitable example:
(i) Cartesian product (ii) Natural join

(i) Cartesian Product: The Cartesian product, denoted by the symbol "×" (not to be confused
with the "x" multiplication symbol), is a relational algebra operation that combines every row from
one relation with every row from another relation. It generates a new relation with a number of rows
equal to the product of the number of rows in the two input relations.
Example: Let's say we have two relations, A and B, with the following data:

Relation A:

Name

ID

1 Alice

2 Bob

Relation B:

Age City

25 Paris

Age City
30 London

The Cartesian product of A × B would be as follows:

ID Name Age City

1 Alice 25 Paris

1 Alice 30 London

2 Bob 25 Paris

2 Bob 30 London

As you can see, every row from Relation A is combined with every row from Relation B, resulting in a
new relation with all possible combinations.

(ii) Natural Join: A natural join is a relational algebra operation that combines two relations
based on a common attribute (column) that they share. It merges rows from both relations where
the values of the common attribute match. In a natural join, the duplicate columns (attributes) are
eliminated, and the result contains only one copy of the common attribute.
Example: Let's consider two relations, Employees and Departments, with the following data:
Employees:
 Name Department

Emp_ID

101 Alice HR

102 Bob Sales

103 Charlie IT

Departments:

Department Manager

HR John

Sales David

IT Sarah

A natural join between Employees and Departments on the "Department" attribute would produce the
following result:

Emp_ID Name Department Manager

101 Alice HR John

102 Bob Sales David

103 Charlie IT Sarah

In this example, the natural join combines the two relations based on the "Department" attribute, and
the resulting relation contains only one copy of the "Department" column. It also includes the
attributes from both original relations where the "Department" values match

Q. 3 Solve Any Two of the following.

B) Consider the following relational schema.

Weather (city, temperature, humidity, condition) Location (city, country) Write the

following queries in SQL:

(i) Find all the tuples having temperature greater than that of Paris.
(ii) Find the names of those cities with temperature and condition whose condition is neither
Sunny nor Cloudy but temperature must be greater than 70.
Find all the cities with temperature, condition and humidity, whose humidity is in the range
of 63 to 79.
You can write SQL queries to retrieve the desired information from the given relational schema as
follows:

(i) Find all the tuples having temperature greater than that of Paris.
SELECT *
FROM Weather
WHERE temperature > (SELECT temperature FROM Location WHERE city = 'Paris');

This query retrieves all the rows from the Weather table where the temperature is greater than the
temperature of Paris, which is obtained by using a subquery to select the temperature value from the
Location table for the city 'Paris'.

(ii)Find the names of those cities with temperature and condition whose condition is neither Sunny
nor Cloudy but temperature must be greater than 70.

SELECT w.city, w.temperature, w.condition

FROM Weather w
WHERE w.temperature > 70 AND w.condition NOT IN ('Sunny', 'Cloudy');

This query selects the city, temperature, and condition from the Weather table for cities where the
temperature is greater than 70 and the condition is neither 'Sunny' nor 'Cloudy'.

(iii) Find all the cities with temperature, condition, and humidity, whose humidity is in the range
of 63 to 79.
SELECT w.city, w.temperature, w.condition, w.humidity
FROM Weather w
WHERE w.humidity >= 63 AND w.humidity <= 79;
C) What is view? What are its advantages? Explain views in SQL with suitable
example.

In SQL, a view is a virtual table that is created by a query and does not store data on its own. Instead,
it is a saved SQL statement that allows you to encapsulate complex SQL queries and present the
results as if they were a regular table. Views are particularly useful for simplifying data access and
providing a layer of abstraction over the underlying database tables.

Advantages of using views in SQL:

Data Security: Views can be used to restrict access to certain columns or rows of a table, allowing
you to define a security layer for sensitive data. Users can be granted access to views without
exposing the underlying table structure.
Simplified Querying: Views allow you to encapsulate complex or frequently used queries into a single,
easy-to-use object. This can simplify application code and make it easier to query the data.
Data Abstraction: Views provide a level of abstraction, allowing you to change the underlying
structure of the database without affecting the queries that reference the view. This is useful for
maintaining backward compatibility as the schema evolves.
Performance Optimization: Views can be used to precompute and store the results of expensive or
frequently used queries, which can improve query performance.
Joining Tables: Views can simplify the process of joining multiple tables into a single virtual table,
making it easier to work with related data.

Here's an example of how to create and use a view in SQL:

Let's say you have a database with two tables: Customers and Orders. You want to create a view
that shows the customer name along with their order count. Here's how you can create the view:

CREATE VIEW CustomerOrderView AS

SELECT c.CustomerID, c.CustomerName, COUNT(o.OrderID) AS OrderCount
FROM Customers c
LEFT JOIN Orders o ON c.CustomerID = o.CustomerID
GROUP BY c.CustomerID, c.CustomerName;

In this example:
We create a view called CustomerOrderView.
The view retrieves data from both the Customers and Orders tables, performing a left join to count
the number of orders for each customer.
The result of this query is saved as a view, and it can be queried like a regular table.
Once the view is created, you can query it as if it were a table to retrieve the customer names along
with their order counts:
SELECT * FROM CustomerOrderView;
Q.4 Solve Any Two of the following

A) What is Normalization? Explain the importance of normalization.What is the

criteria for good relation design?

A) Normalization is a database design technique used to organize data in a relational

database efficiently and reduce data redundancy. It involves breaking down a large table into smaller,
related tables to eliminate duplicate data and ensure data integrity. The main goals of normalization
are to minimize data redundancy, improve data consistency, and facilitate data maintenance and
retrieval. It helps prevent anomalies such as insertion, update, and deletion anomalies that can occur
when data is stored in a denormalized or unnormalized form.

The importance of normalization in database design can be summarized as follows:

Data Integrity: Normalization reduces the risk of data anomalies by ensuring that data is stored in a
structured and consistent manner. This helps maintain the accuracy and reliability of the data.
Redundancy Reduction: By eliminating duplicate data, normalization reduces storage space
requirements and minimizes the risk of data inconsistencies or discrepancies.
Simplified Data Maintenance: When data is well-organized, making updates or modifications to the
database is more straightforward and less error-prone. Changes need to be made in fewer places,
which simplifies data maintenance.
Improved Query Performance: Normalized databases can often be queried more efficiently, as
related data is stored in separate tables, making it easier to retrieve specific information without
unnecessary duplication.
Scalability: Normalized databases are more scalable, making it easier to add new data without the
need for extensive modifications to the database schema.
The criteria for good relational database design, often associated with normalization, are usually
described using a series of normal forms. The most common normal forms are:
First Normal Form (1NF): Each table must have a primary key, and the values in each column must
be atomic, i.e., indivisible. There should be no repeating groups, and each column should contain
only one type of data.
Second Normal Form (2NF): A table should be in 1NF, and all non-key attributes should be fully
functionally dependent on the entire primary key, which means no partial dependencies.
Third Normal Form (3NF): A table should be in 2NF, and it should not contain transitive
dependencies. Transitive dependencies occur when a non-key attribute depends on another nonkey
attribute that, in turn, depends on the primary key.
Boyce-Codd Normal Form (BCNF): A more stringent version of 3NF, BCNF ensures that, for every non
-trivial functional dependency, the determinant is a superkey.
Fourth Normal Form (4NF): A table should be in BCNF, and it should not have any multi-valued
dependencies.
Fifth Normal Form (5NF): Also known as Project-Join Normal Form (PJ/NF), it deals with cases
where a table has multi-valued dependencies and is typically used in complex scenarios.
The choice of which normal form to achieve depends on the specific requirements of the application
and the nature of the data. Good relational database design aims to achieve an appropriate level of
normalization while considering performance, data integrity, and ease of querying.
B) Explain BCNF with suitable example and distinguish between BCNF and 3NF
Is relation R(student_no, course_no,instr_no) with
F = { {student_no, course_no} → instr_no, instr_no→ course_no} in BCNF and
3NF? Justify your answer.

BCNF (Boyce-Codd Normal Form) and 3NF (Third Normal Form) are two different levels of
normalization in relational database design, each with specific rules to eliminate certain types of
data anomalies. Let's start by defining and explaining BCNF and 3NF and then determine whether
the given relation R with its functional dependencies is in BCNF and 3NF.
BCNF (Boyce-Codd Normal Form): A relation is in BCNF if, for every non-trivial functional dependency
X → Y, X is a superkey. In other words, a relation is in BCNF if it satisfies the following two
conditions:

For every non-trivial functional dependency X → Y, X is a superkey.

There are no partial dependencies, meaning that for any X → Y, X should be a superkey, and there
should be no proper subset of X that can functionally determine Y.
3NF (Third Normal Form): A relation is in 3NF if, for every non-trivial functional dependency X → Y, X
is a superkey or Y is a prime attribute (an attribute that is part of a candidate key). In other words, a
relation is in 3NF if it satisfies the following two conditions:

For every non-trivial functional dependency X → Y, X is a superkey or Y is a prime attribute.

There are no transitive dependencies, meaning that if X → Y and Y → Z, then there should not be a
direct functional dependency from X to Z.
Now, let's analyze the given relation R(student_no, course_no, instr_no) with the functional
dependencies:

F = { {student_no, course_no} → instr_no, instr_no → course_no }

First, we need to identify the candidate keys. In this case, the candidate key can be {student_no,
course_no} because it uniquely identifies each row in the relation.

Now, let's evaluate the relation for BCNF and 3NF:

BCNF:
The functional dependency {student_no, course_no} → instr_no is given. Since {student_no,
course_no} is a superkey (it's a candidate key), this condition is satisfied.
The functional dependency instr_no → course_no is given. Instr_no is not a superkey, so this
condition is not satisfied. To bring the relation to BCNF, we need to decompose it into two relations:
one with instr_no → course_no and another with student_no, course_no → instr_no.

3NF:
The functional dependency {student_no, course_no} → instr_no is given. {student_no, course_no} is a
superkey, and instr_no is not a prime attribute. This condition is not satisfied for 3NF.
The functional dependency instr_no → course_no is given. Instr_no is not a superkey. This condition
is not satisfied for 3NF.
In summary, the given relation R(student_no, course_no, instr_no) is not in BCNF or 3NF. To bring it
into BCNF and 3NF, we need to decompose the relation as mentioned earlier, creating two
relations: one for instr_no → course_no and another for student_no, course_no → instr_no,
ensuring that all functional dependencies adhere to the BCNF and 3NF rules.

Q. 5 Solve Any One of the following.

A) Explain ACID properties in detail

 ACID is an acronym that stands for Atomicity, Consistency, Isolation, and Durability. These
properties are fundamental concepts in database management systems and are designed to ensure
the reliability and integrity of transactions in a database.

Atomicity:
Atomicity ensures that a transaction is treated as a single, indivisible unit of work. Either all the
operations within a transaction are completed successfully, or none of them are. In other words, a
transaction is atomic, meaning it's all or nothing.
If any part of a transaction fails, the entire transaction is rolled back to its initial state, ensuring that
the database remains consistent.

Consistency:
Consistency guarantees that a database starts in a consistent state and ends in a consistent state
after a transaction. The database must satisfy a set of integrity constraints defined by the database
schema.
In other words, a transaction cannot bring the database from a consistent state to an inconsistent
state. The consistency constraint ensures that the data remains valid throughout the transaction.

Isolation:
Isolation ensures that concurrent execution of multiple transactions does not lead to interference or
inconsistency. Each transaction should be isolated from others until it's completed.
Isolation levels, such as Read Uncommitted, Read Committed, Repeatable Read, and Serializable,
define the degree to which one transaction can "see" the uncommitted changes made by other
transactions. Higher isolation levels provide a greater level of data consistency but may impact
performance due to locking and blocking.

Durability:
Durability guarantees that once a transaction is committed, its changes are permanent and will
survive any system failures, such as power outages or crashes. This means that the data changes
are written to non-volatile storage, typically disk, and can be recovered even in the event of a
catastrophic failure.
The durability property ensures that the data remains intact and can be retrieved even if the system
crashes immediately after a transaction is acknowledged as successful.
ACID properties are essential for ensuring data reliability and integrity in database systems,
particularly in scenarios where data consistency and correctness are critical, such as financial
systems, e-commerce applications, and many enterprise-level databases. However, implementing
strong ACID guarantees can sometimes come at the cost of reduced performance, as locking and
logging mechanisms may introduce overhead. In cases where high performance is more critical than
strict consistency, NoSQL databases that relax some ACID properties may be preferred.

B) What are ordered indices? Explain with suitable example. Distinguish between
dense index and sparse index.

Ordered indices are data structures used in databases to improve the efficiency of
searching for specific records in a table. These indices are typically associated with a specific
column or set of columns in a database table. They help in speeding up query performance by
allowing the database management system (DBMS) to locate and access records more quickly.

There are two main types of ordered indices: dense index and sparse index.

Dense Index:
In a dense index, there is an index entry for every record in the table, and the index entries are sorted
based on the values of the indexed column(s).
Each index entry contains a pointer (typically a file offset or a primary key) to the corresponding
record in the table.
Dense indices are generally used in situations where the indexed column has a relatively low
cardinality (few distinct values) or when there is a need to support range queries efficiently.

Since every record has a corresponding index entry, dense indices can quickly locate any record.
Example: Consider a table of students with a dense index on the "StudentID" column. The dense
index will contain an entry for every student, and each entry will point to the location of the student's
record in the table.

Sparse Index:
In a sparse index, the index entries are not created for every record in the table. Instead, the index
contains entries for only some of the records.

The index entries are usually sorted based on the values of the indexed column(s).
To find a specific record, you may need to follow a chain of index entries to get to the desired record.
Sparse indices are typically used when the indexed column has high cardinality (many distinct values)
and to save storage space, as they don't create entries for all records.
Example: Consider a large library catalog with a sparse index on the "Book Title" column.
Instead of having an entry for every book, the index might have entries for specific book titles (e.g., A,
B, C, etc.). To find a book, you would start at the appropriate entry and follow a chain of entries until
you find the one you're looking for.
In summary, ordered indices are used to improve the efficiency of searching for records in a
database. Dense indices have an entry for every record, while sparse indices have entries for only
some records, making them suitable for high-cardinality columns or scenarios where storage space
is a concern. The choice between dense and sparse indexing depends on the specific requirements
of the database and the types of queries that need to be optimized.
Top of Form