Database Management System

Question Bank-2
Compare DDL (Data Definition Language) and DML (Data Manipulation Language) in SQL.

 DDL (Data Definition Language): Includes commands like CREATE, ALTER, and DROP that define
1
or modify the structure of database objects (tables, schemas, etc.).
 DML (Data Manipulation Language): Includes commands like SELECT, INSERT, UPDATE, and
DELETE that allow users to manipulate and query data within the tables.
Explain the importance of Fifth Normal Form (5NF).

Fifth Normal Form (5NF) deals with join dependency and ensures that a relation is free from
redundancy due to multiple relationships between attributes. A table is in 5NF if it cannot be
decomposed into smaller tables without losing information.
Importance:
 Eliminates Redundancy: 5NF ensures that data is stored in a way that minimizes
2
redundancy, especially in complex relationships.
 Prevents Update Anomalies: By ensuring that each piece of information is stored in
only one place, it prevents issues like inconsistent updates across multiple places in the
database.
In practice, 5NF is often considered in systems where there are highly complex relationships
involving multiple attributes, though it is less commonly used in most everyday database
designs.
Explain the concept of a transaction in database management systems.

A transaction in a database management system (DBMS) is a sequence of one or more

operations (such as insert, update, delete) that are executed as a single unit. The transaction
must either be fully completed (commit) or fully rolled back (abort) to maintain the consistency
of the database.
Key properties of a transaction are:
3
 Atomicity: Ensures that all operations in the transaction are completed successfully or
none at all.
 Consistency: The database moves from one consistent state to another.
 Isolation: Ensures that transactions do not interfere with each other, even when
executed concurrently.
 Durability: Once a transaction is committed, its changes are permanent, even in the
case of system failures.
Identify the difference between a deadlock and a livelock.

 Deadlock: A situation in which two or more transactions are waiting for each other to
4 release resources, causing all of them to be stuck indefinitely without making progress.
 Livelock: A situation in which transactions continuously change states in response to
each other but never make any actual progress, often by repeatedly retrying an
operation.
How does a transaction move from the "Active" state to the "Committed" state?

A transaction moves from the "Active" state to the "Committed" state after successfully
5
completing all its operations, meeting all integrity constraints, and receiving a commit
command. Once committed, the transaction's changes are permanently applied to the database
and cannot be undone.
Identify the differences between functional dependency, transitive dependency, and multivalued
dependency with examples.
6
Multivalued Dependency
1. Functional Dependency (FD):
 o Definition: A functional dependency exists when one attribute (or set of
attributes) in a relation uniquely determines another attribute.
o Notation: A → B means that attribute A uniquely determines attribute B.
o Example:
 Student (StudentID, StudentName, Course)
 Here, StudentID → StudentName indicates that a StudentID uniquely
determines the StudentName.
2. Transitive Dependency:
o Definition: A transitive dependency occurs when one attribute depends on
another, which in turn depends on a third attribute. It happens if A → B and B
→ C, then A → C.
o Example:
 Employee (EmpID, EmpName, DeptID, DeptName)
 If EmpID → DeptID and DeptID → DeptName, then EmpID →
DeptName is a transitive dependency.
3. Multivalued Dependency (MVD):
o Definition: A multivalued dependency exists when one attribute determines a
set of values for another attribute, independent of other attributes.
o Notation: A ↠ B means that for each value of A, there is a set of possible values
for B.
o Example:
 Student (StudentID, Hobby, Language)
If a student has multiple hobbies and languages, then StudentID ↠
Hobby and StudentID ↠ Language indicate that StudentID determines
a set of hobbies and a set of languages independently.
Explain how Fourth Normal Form (4NF) handles multivalued dependencies and provide an
example.

Fourth Normal Form (4NF): A relation is in 4NF if it is in Boyce-Codd Normal Form (BCNF)
and has no multivalued dependencies.
 Handling MVDs in 4NF: In 4NF, multivalued dependencies are eliminated by
decomposing the relation. If an MVD exists between two sets of attributes, they should
be separated into different relations to eliminate redundancy.
Example:
7
 Student (StudentID, Hobby, Language)
o A student can have multiple hobbies and multiple languages. If the hobbies and
languages are independent of each other, a multivalued dependency StudentID
↠ Hobby and StudentID ↠ Language may exist.
 To convert the relation to 4NF:
o Decompose into two relations:
 StudentHobby (StudentID, Hobby)
 StudentLanguage (StudentID, Language)
This decomposition eliminates the multivalued dependencies and ensures the relation is in 4NF.
Explain the key differences between 3NF and BCNF and discuss scenarios where BCNF is
preferred over 3NF.

Third Normal Form (3NF):

 Definition: A relation is in Third Normal Form (3NF) if it is in Second Normal Form
(2NF) and no non-prime attribute is transitively dependent on the primary key.
 Non-prime Attribute: An attribute that is not part of a candidate key.
 Transitive Dependency: A situation where attribute A depends on attribute B, and
8 attribute B depends on attribute C, so attribute A transitively depends on attribute C.
 Rule: A relation is in 3NF if, for every functional dependency A→BA \to BA→B, at
least one of the following holds:
1. AAA is a superkey (a candidate key or a superset of a candidate key).
2. BBB is a prime attribute (part of a candidate key).
Boyce-Codd Normal Form (BCNF):
 Definition: A relation is in Boyce-Codd Normal Form (BCNF) if it is in Third Normal
Form (3NF) and for every functional dependency A→BA \to BA→B, A is a superkey.
 Superkey: A set of attributes that uniquely identifies a tuple in a relation.
  Key Rule: In BCNF, every functional dependency must have a superkey on the left side.
This eliminates any possibility of non-prime attributes (attributes that are not part of a
candidate key) being involved in functional dependencies.
Key Differences Between 3NF and BCNF
Aspect 3NF BCNF
A relation is in BCNF if it is in 3NF
A relation is in 3NF if it is in 2NF
and for every functional dependency
Normal Form and no transitive dependency exists
A→BA \to BA→B, AAA must be a
for non-prime attributes.
superkey.
Allows non-prime attributes to Does not allow non-prime attributes to
Handling of
depend on another non-prime depend on another non-prime
Functional
attribute as long as the dependency attribute, even if the dependency is not
Dependencies
is not transitive. transitive.
3NF is less strict; it allows certain
BCNF is stricter than 3NF,
non-prime attributes to be
Strictness disallowing all non-superkey
transitively dependent on the
dependencies.
primary key.
3NF allows relations where a non- BCNF eliminates all violations of
Occurrence of
prime attribute is transitively functional dependencies that don’t
Violations
dependent on a key. involve superkeys.
Example of a Violation of 3NF but in BCNF:
Consider the following relation:
 Student (StudentID, CourseID, Instructor)
Functional Dependencies:
1. StudentID→CourseIDStudentID \to CourseIDStudentID→CourseID (Each student
takes only one course).
2. CourseID→InstructorCourseID \to InstructorCourseID→Instructor (Each course has a
specific instructor).
Here, the relation is in 3NF but not in BCNF because:
 CourseID→InstructorCourseID \to InstructorCourseID→Instructor is a functional
dependency, but CourseIDCourseIDCourseID is not a superkey (since
StudentIDStudentIDStudentID is the primary key), violating BCNF.
To convert this to BCNF, we decompose it into two relations:
 StudentCourse (StudentID, CourseID)
 CourseInstructor (CourseID, Instructor)
Now, both relations are in BCNF, as every functional dependency involves a superkey.
Scenarios Where BCNF is Preferred Over 3NF
BCNF is generally preferred over 3NF in situations where:
1. Elimination of Redundancy: BCNF removes anomalies that 3NF might leave behind,
specifically the possibility of having redundant data due to non-superkey dependencies.
o Example: In a relation like Student (StudentID, CourseID, Instructor) where
a course determines the instructor, BCNF helps eliminate redundancy by
splitting the relation into two.
2. Stronger Consistency Guarantees: BCNF ensures that every determinant is a superkey,
which provides a stronger guarantee of data integrity by preventing any dependency
between non-prime attributes.
o Example: When an attribute is non-prime and involved in a functional
dependency, BCNF will prevent inconsistencies, whereas 3NF would still allow
this dependency.
3. Data Integrity: If you have frequent updates to the data (insert, delete, update
operations), BCNF can help avoid issues related to redundancy and update anomalies.
Example: In scenarios where courses are frequently added, BCNF ensures that each course's
instructor is stored in a separate relation, preventing repetition of instructor information for each
student.
Explain the concept of normalization and its benefits in database design.
9
Normalization is the process of organizing the data in a relational database to minimize
redundancy and dependency. The goal is to ensure that the database is structured in such a way
 that it eliminates undesirable characteristics like data anomalies (insertion, update, and deletion
anomalies), improves data integrity, and simplifies querying.
The process involves dividing a large table into smaller, more manageable tables and defining
relationships between them. The tables are designed based on rules, called normal forms (NF),
which ensure that data is structured efficiently.
Benefits of Normalization:
1. Minimization of Data Redundancy: Reduces repeated data, saving storage space and
improving efficiency.
2. Avoiding Data Anomalies: Eliminates insertion, deletion, and update anomalies that
could lead to inconsistent data.
3. Data Integrity: Ensures consistency in the data by establishing clear relationships
between tables.
4. Improved Query Performance: Efficient tables with minimal redundancy may result in
better performance when querying.
Example:
Consider a table storing information about students and the courses they are enrolled in:
diff
Copy
Student_Course
--------------------------------------
Student_ID | Student_Name | Course
--------------------------------------
1 | Alice | Math
1 | Alice | Science
2 | Bob | Math
3 | Charlie | Science
By normalizing the above table (e.g., into separate Student and Course tables), redundancy is
reduced and integrity is maintained.

Explain the differences between 2NF, 3NF, and BCNF with suitable examples.

1. Second Normal Form (2NF): A table is in 2NF if it is in 1NF (no repeating groups or arrays),
and every non-prime attribute is fully dependent on the entire primary key (i.e., no partial
dependency).
Partial Dependency occurs when a non-prime attribute is dependent on only part of a composite
primary key.
Example of 2NF: Consider a table with a composite primary key (Student_ID, Course_ID):
diff
Copy
Student_Course
------------------------------
Student_ID | Course_ID | Instructor
------------------------------
1 | Math | Dr. Smith
10 1 | Science | Dr. Johnson
2 | Math | Dr. Smith
Here, Instructor is partially dependent on Course_ID (not the full primary key (Student_ID,
Course_ID)), so it violates 2NF. To bring it into 2NF, the table is divided into two tables:
 Student_Course (Student_ID, Course_ID)
 Course_Instructor (Course_ID, Instructor)

2. Third Normal Form (3NF): A table is in 3NF if it is in 2NF and every non-prime attribute
is transitively dependent only on the primary key. This means there should be no transitive
dependency, i.e., a non-prime attribute shouldn't depend on another non-prime attribute.
Transitive Dependency occurs when a non-prime attribute depends on another non-prime
attribute.
Example of 3NF: Consider the following table, where Student_ID is the primary key:
pgsql
Copy
Student_Info
 -----------------------------------
Student_ID | Name | Department | Dept_Head
-----------------------------------
1 | Alice | CS | Dr. Lee
2 | Bob | IT | Dr. Smith
3 | Charlie| CS | Dr. Lee
Here, Dept_Head is transitively dependent on Department, since Dept_Head depends on
Department, which in turn depends on Student_ID.
To bring it into 3NF, we create two tables:
 Student_Info (Student_ID, Name, Department)
 Department_Info (Department, Dept_Head)

3. Boyce-Codd Normal Form (BCNF): A table is in BCNF if it is in 3NF and for every non-
trivial functional dependency, the determinant is a superkey. In simpler terms, BCNF requires
that for every functional dependency, the attribute on the left side of the dependency must be a
candidate key.
Example of BCNF: Consider the following table, where Student_ID and Course_ID together
form the primary key:
markdown
Copy
Student_Course_Info
---------------------------------
Student_ID | Course_ID | Instructor
---------------------------------
1 | Math | Dr. Smith
1 | Science | Dr. Johnson
2 | Math | Dr. Smith
Here, Instructor is dependent on Course_ID, not on the whole primary key (Student_ID,
Course_ID). This violates BCNF because Course_ID is not a superkey, even though it determines
Instructor.
To bring this table into BCNF, we would split the table into two:
 Student_Course (Student_ID, Course_ID)
 Course_Instructor (Course_ID, Instructor)

Summary of Differences:
Normal
Key Condition Example
Form
Eliminates partial dependency (non-prime Instructor dependent only on
2NF
attributes depend on the entire composite key). Course_ID needs splitting.
Eliminates transitive dependency (non-prime Dept_Head dependent on Department
3NF
attributes depend on other non-prime attributes). requires splitting.
Ensures that for every functional dependency, the Instructor dependent on Course_ID but
BCNF
determinant is a superkey. Course_ID isn't a superkey.
In conclusion:
 2NF addresses partial dependency.
 3NF eliminates transitive dependency.
 BCNF strengthens the 3NF by eliminating situations where a non-superkey attribute
determines another attribute.
Explain the significance of Fifth Normal Form (5NF) and provide a real-world case where PJNF
is essential for database design.

Fifth Normal Form (5NF):

Fifth Normal Form (5NF), also known as Projection-Join Normal Form (PJNF), is the highest
11 level of normalization in relational database design. It deals with eliminating redundancy
caused by join dependency, ensuring that a relation is free of any join dependency.
A relation is in 5NF (or PJNF) if it is in 4NF (i.e., no multi-valued dependencies) and every join
dependency is a consequence of the candidate keys.
Join Dependency occurs when a relation can be decomposed into smaller relations, and these
smaller relations, when joined, will recreate the original relation without any loss of information.
This is primarily focused on eliminating unnecessary redundancy caused by complex
relationships between the attributes.
Key Characteristics of 5NF:
 A relation in 5NF cannot be decomposed into smaller relations without losing data or
introducing redundancy.
 It requires that every join dependency in the relation be a consequence of the candidate
keys.
 It eliminates redundancy that may arise in cases where multiple multi-valued facts are
involved.
The Significance of 5NF:
The primary significance of 5NF is that it ensures data integrity and eliminates redundancy
when the relationship between the data items is complex. It ensures that each piece of information
is stored only once, reducing the possibility of inconsistent data or anomalies. 5NF primarily
applies to situations where there are complex many-to-many relationships between attributes
in a table.
When 5NF is Required:
While 5NF is rarely needed for most database designs, it becomes essential in certain complex
relationships. It is particularly useful in cases where:
 Data is highly interdependent.
 There are multiple many-to-many relationships.
 The data contains multi-valued facts that need to be recorded across several entities.
By applying 5NF, we ensure that no additional redundancy is introduced when the data is split
into multiple relations.
Real-World Example:
Case: Supplier, Product, and Project Relationship:
Consider a scenario in which a company has multiple suppliers, each supplying various products
to different projects. The relationship between these three entities can lead to redundancy if the
data is stored in a single table. To fully understand the need for 5NF or PJNF, let's look at how
data can be represented in a non-normalized manner.
Example Table (Non-Normalized):
Supplier_Product_Project
-------------------------------------------------
Supplier_ID | Product_ID | Project_ID | Price
-------------------------------------------------
1 | 101 | 5001 | 50
1 | 101 | 5002 | 50
1 | 102 | 5001 | 75
2 | 101 | 5001 | 55
2 | 103 | 5002 | 60
 A supplier can supply multiple products.
 A product can be associated with multiple projects.
 Multiple suppliers may supply the same product to different projects.
In this case, there is redundancy because a supplier supplying the same product to different
projects will cause repeated data for the supplier, product, and project combination. This table
can lead to data anomalies, such as insertion, deletion, or update anomalies.
Decomposing into 5NF (PJNF):
To achieve 5NF, we decompose this relation into smaller, logically related tables based on join
dependency and candidate keys:
1. Supplier_Product (supplier-product relationship):
2. Supplier_ID | Product_ID
3. ------------------------
4. 1 | 101
5. 1 | 102
6. 2 | 101
7. Product_Project (product-project relationship):
8. Product_ID | Project_ID
9. ------------------------
10. 101 | 5001
11. 101 | 5002
12. 102 | 5001
 13. 103 | 5002
14. Supplier_Project (supplier-project relationship):
15. Supplier_ID | Project_ID
16. ------------------------
17. 1 | 5001
18. 1 | 5002
19. 2 | 5001
20. 2 | 5002
21. Price (supplier-product-project-price relationship):
22. Supplier_ID | Product_ID | Project_ID | Price
23. -----------------------------------------------
24. 1 | 101 | 5001 | 50
25. 1 | 101 | 5002 | 50
26. 1 | 102 | 5001 | 75
27. 2 | 101 | 5001 | 55
28. 2 | 103 | 5002 | 60
Now, we can join these smaller tables to retrieve the original information, but redundancy is
removed, and there is no loss of data. Each piece of information is stored only once, and it is
referenced by keys (e.g., Supplier_ID, Product_ID, and Project_ID). This ensures data integrity
and removes any potential anomalies that could arise during insert, update, or delete operations.

Explain the importance of deadlock detection and prevention in transaction management.

Deadlock in transaction management occurs when two or more transactions are unable to proceed
because each is waiting for the other to release resources. This creates a situation where no
transaction can make progress, potentially leading to system inefficiency and reduced
performance. Deadlock detection and prevention are essential to ensure that the database
management system (DBMS) operates smoothly.
Deadlock Detection:
 Definition: Deadlock detection involves identifying situations where transactions are
stuck in a circular wait, meaning that no progress can be made.
 Importance:
1. Prevents System Freezing: Detecting deadlocks ensures that the system does
not become stuck, which could freeze operations and impact user experience.
2. Allows for Recovery: Once deadlocks are detected, the system can resolve the
issue by aborting one or more of the transactions involved, freeing up the
12
resources.
3. Enhances Resource Allocation: Deadlock detection allows for the efficient use
of resources by resolving conflicts when detected.
Deadlock Prevention:
 Definition: Deadlock prevention involves taking steps to ensure that deadlocks do not
occur in the first place by controlling how resources are allocated.
 Importance:
1. Improves Transaction Flow: By preventing deadlocks, transactions can
proceed without unnecessary delays, ensuring smooth operations.
2. Optimizes Performance: Preventing deadlocks reduces the need for complex
recovery mechanisms and allows better management of system resources.
3. Avoids Wasted Resources: Prevention avoids the waste of resources that could
occur when transactions are in a deadlock state.
Both deadlock detection and prevention are crucial for maintaining system efficiency, reducing
downtime, and ensuring the integrity of transaction management in a database system.
Identify and describe the ACID properties of a transaction with examples.

The ACID properties (Atomicity, Consistency, Isolation, and Durability) ensure reliable and
correct execution of transactions in a database management system (DBMS). Each property
13 addresses specific aspects of transaction reliability.
1. Atomicity:
o Definition: Atomicity ensures that a transaction is treated as a single unit of
work. Either all operations in the transaction are completed successfully, or none
of them are applied (i.e., a transaction is "all or nothing").
 o Example: Consider a banking transfer where $100 is moved from Account A to
Account B. If the system fails midway, the entire transaction is rolled back, and
no money is transferred, maintaining atomicity.
2. Consistency:
o Definition: Consistency ensures that a transaction transforms the database from
one valid state to another. After a transaction, the database must satisfy all
predefined rules, constraints, and relationships (e.g., no violation of foreign keys
or data integrity).
o Example: In the same banking system, a transaction should not leave Account
A with a negative balance. If the transaction would result in such an
inconsistency, the transaction will not be completed.
3. Isolation:
o Definition: Isolation ensures that transactions are executed independently of one
another, even if they are executed concurrently. The intermediate states of
transactions are not visible to other transactions until they are fully completed.
o Example: If two users are trying to update the same bank account at the same
time, the isolation property ensures that one transaction is completed before the
other begins, preventing inconsistencies like double withdrawals.
4. Durability:
o Definition: Durability ensures that once a transaction has been committed, it is
permanent, even in the case of system failures (e.g., power loss or crash). The
changes made by the transaction are saved and cannot be lost.
o Example: If a user deposits $500 into their bank account and the system crashes
immediately afterward, once the system is restored, the transaction will be
reflected in the account balance.

Summary:
 Atomicity ensures that all parts of a transaction are completed, or none are applied.
 Consistency ensures the database moves from one valid state to another.
 Isolation ensures that transactions are independent of each other.
 Durability guarantees that committed transactions are permanent, even after a system
failure.
These ACID properties are essential for maintaining the integrity, reliability, and correctness of
transactions in a database system.
Identify different transaction states and explain the transitions between them with a state
diagram.?

A transaction in a database management system (DBMS) undergoes various states during its
execution. These states represent different stages in the lifecycle of a transaction. Understanding
the states and transitions is crucial for managing transactions effectively, ensuring they are
executed correctly, and handling failures.
Transaction States:
There are several key states that a transaction can be in:
1. New:
o Definition: The transaction is created but has not yet started executing.
o Transition: The transaction moves from the New state to the Active state once
it begins executing.
14
2. Active:
o Definition: The transaction is actively executing and making changes to the
database.
o Transition: The transaction may either commit (successfully complete) or abort
(fail and roll back) from this state.
3. Partially Committed:
o Definition: The transaction has executed all its operations and reached the point
where it is about to be committed, but it has not yet been permanently saved to
the database.
o Transition: This state occurs if the transaction finishes execution and is waiting
to be committed (i.e., all the operations are successful up to that point).
4. Committed:
o Definition: The transaction has successfully completed and all changes have
 been permanently saved to the database.
o Transition: Once committed, the transaction state becomes final, and no further
action can be taken. The transaction is considered successfully executed.
5. Aborted:
o Definition: The transaction has failed during execution or explicitly requested to
be rolled back. All changes made by the transaction are undone, and the
transaction is terminated.
o Transition: If a transaction is in the Active state and encounters an error or a
deadlock, it may transition to Aborted. Alternatively, if the transaction is
explicitly rolled back, it enters the Aborted state.
6. Terminated:
o Definition: The transaction has been successfully committed or aborted, and no
further actions will be taken. This state signifies that the transaction has
completed its life cycle.
o Transition: Once the transaction is either Committed or Aborted, it enters the
Terminated state, which represents the end of the transaction's lifecycle.
State Transitions:
The transitions between these states are governed by the actions of the system and the transaction
itself.
1. New → Active: The transaction starts executing.
2. Active → Partially Committed: The transaction successfully finishes execution and is
ready to be committed.
3. Partially Committed → Committed: The transaction is permanently saved to the
database.
4. Active → Aborted: The transaction encounters an error, failure, or deadlock, and is
rolled back.
5. Aborted → Terminated: After a transaction is aborted, it ends, and no further action is
possible.
6. Committed → Terminated: After the transaction is committed, it is considered finished,
and no further changes will occur.

State Diagram:
Here is a state diagram representing the lifecycle of a transaction:
pgsql
Copy
+------------+ start +------------+ commit +------------+
| New |---------------->| Active |------------------->| Partially |
| | | | | Committed |
+------------+ +------------+ +------------+
| |
| |
| |
abort | | commit
v v
+------------+ +------------+
| Aborted |<---------| Committed |
+------------+ +------------+
| |
| |
v v
+------------+ +------------+
| Terminated |<-------->| Terminated |
+------------+ +------------+
 New → Active: This transition occurs when a transaction is initiated and begins its
execution.
 Active → Partially Committed: This transition takes place after all the operations of a
transaction have been executed successfully and the system is ready to commit the
changes.
 Active → Aborted: If a transaction encounters an issue, such as a deadlock or an error,
it is aborted and all changes are undone.
  Partially Committed → Committed: After successful execution, the transaction
reaches this state when it is saved permanently to the database.
 Active → Aborted: If an error occurs during execution or the transaction is explicitly
rolled back, it transitions to the Aborted state.
 Aborted → Terminated: Once a transaction has been aborted, it is considered
terminated.
 Committed → Terminated: Once the transaction is successfully committed, it is
considered complete and enters the Terminated state.
Importance of Transaction States:
1. Managing Errors: By having different states, a DBMS can effectively handle failures
and recover by rolling back transactions from any state before Commit.
2. Concurrency Control: The states allow the system to manage concurrent transactions,
ensuring that transactions can execute without conflicting with one another.
3. Consistency: Each state ensures that the database maintains its integrity by only
committing changes after confirming that the transaction has successfully completed.