DBMS SHORT QUESTIONS 2M

1. What are the problems that occur without applying normalization

When database normalization, particularly Second Normal Form (2NF), is not applied, several
issues may arise, particularly in terms of data integrity, redundancy, and update anomalies. Here
are the main problems:

1. Data Redundancy: Without 2NF, data may be unnecessarily repeated across rows in a
table, leading to wasted storage and larger database size. Redundant data increases the
chance of inconsistency when updates are made.

2. Update Anomalies: Without normalization, changing a single value in a non-normalized

table can require multiple updates. For example, if the address for a particular supplier is
stored in multiple rows, updating the address would require changing it in each instance.

3. Insertion Anomalies: If all columns are not fully dependent on the primary key, you may
encounter situations where you can't insert data about a certain entity without including
unnecessary or irrelevant data. For instance, you might be unable to insert data about a
new product without assigning it to a particular customer, leading to incomplete data
entry.

4. Deletion Anomalies: When data is removed, other unintentionally related information

may also be deleted. For example, deleting a record of a student in a class could also
delete information about the class itself if stored in the same row.

5. Complexity in Querying and Maintenance: Without 2NF, the database structure

becomes more complex and harder to query efficiently. Complex, non-normalized tables
require more complex SQL queries, and database management becomes difficult over
time, leading to performance degradation.

6. Data Integrity Issues: In a non-normalized table, it’s more likely that inconsistent data
will occur, especially in cases where redundant information is present in multiple rows.
Normalization help maintain data integrity by ensuring that data dependencies are
logically sound.

Applying 2NF resolves these issues by eliminating partial dependencies, which ensures
that non-primary key attributes depend fully on the entire primary key.

2. Define functional dependency and list the types. 2m questions.

Functional Dependency is a relationship between two attributes in a database. It

indicates that the value of one attribute (or a group of attributes) uniquely determines the
value of another attribute. If attribute A determines attribute B, then B is said to
be functionally dependent on A, written as A→BA→B.
 Types of Functional Dependencies:

1. Trivial Functional Dependency: When an attribute or set of attributes is

functionally dependent on itself, e.g., A→AA→A or AB→AAB→A.
2. Non-Trivial Functional Dependency: When a dependency A→BA→B holds,
and B is not a subset of A, meaning B relies solely on A.
3. Full Functional Dependency: When an attribute is fully dependent on a
composite key, meaning it cannot be determined by any subset of the key.
4. Partial Dependency: When an attribute is dependent on part of a composite key
rather than the whole key (violates 2NF).
5. Transitive Dependency: When an attribute depends on another attribute
indirectly through a third attribute (violates 3NF).

3. Multivalued dependency(mvd)

Multivalued Dependency (MVD) is a type of dependency in a relational database where

one attribute in a table uniquely determines a set of values for another attribute,
independent of other attributes. In other words, if we have a multivalued
dependency A↠BA↠B, then for each value of attribute AA, there is a set of values
for attribute BB that are independent of the values of other attributes in the relation.

4. Define surrogate key.

A surrogate key is a unique identifier for each record in a database table, used as the primary
key. Unlike natural keys, a surrogate key has no intrinsic meaning or relationship to the data
itself; it’s purely used to uniquely identify rows. Surrogate keys are often auto-generated by the
database management system, such as an auto-incrementing integer or a globally unique
identifier (GUID)

5. properties of decomposition.
1. Lossless Join:

 decomposition is lossless if, after breaking down a table into multiple tables, we
can reconstruct the original table without losing any data.

 This ensures that no information is lost or misrepresented after decomposition.

 It is achieved when the common attributes among decomposed tables serve as a

primary or candidate key in at least one of the tables.

2.Dependency Preservation:

 Decomposition is dependency-preserving if all functional dependencies of the

original table can still be enforced in the decomposed tables.
  This property helps maintain the integrity of data and simplifies enforcement of
constraints without additional joins.

3. Redundancy Reduction:

i. Decomposition should aim to minimize data redundancy by eliminating partial,

transitive, and multivalued dependencies.

ii. This reduces the risk of update, insert, and delete anomalies, making data
management more efficient.

4.Simplicity

i. Decomposing large tables into smaller ones should make the database schema
simpler

to understand and work with, aiding both database design and querying.

6.Define closure set of FD

For an attribute set XX with a set of functional dependencies FF, the closure of XX, written as X+X+, is
the set of all attributes that are functionally determined by XX using the functional dependencies in FF.

How to Calculate the Closure of an Attribute Set:

To determine the closure of an attribute set XX with respect to FF:

1. Start with X+=XX+=X (initially the closure set includes XX itself).

2. Apply each functional dependency in FF to add new attributes to X+X+

If Y→ZY→Z is in FF and Y⊆X+Y⊆X+, then add ZZ to X+X+

3. Repeat step 2 until no new attributes can be added to X+X+

The closure helps determine key attributes, candidate keys, and can be used to verify dependency

preservation in decomposition.

7. Define commit and savepoint with example.

Commit and Savepoint are two important concepts in database transaction management, allowing
control over how and when data modifications are permanently saved.

1. Commit

A commit is a command used to save all the changes made in a transaction permanently to the
database. Once a transaction is committed, the changes are irreversible and become visible to other
users or sessions.

Example of Commit:
Consider a banking application where money is transferred from Account A to Account B. The transfer
transaction consists of two operations:

1. Deducting the amount from Account A.

2. Adding the amount to Account B.

If both operations complete successfully, the transaction is committed to make the changes permanent.

BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A';

UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B';

COMMIT;

In this example, once COMMIT is executed, the deduction from Account A and the addition to Account B
become permanent in the database.

2. Savepoint

A savepoint is a marker within a transaction that allows you to partially roll back the transaction to that
specific point. Unlike a commit, a savepoint does not make changes permanent but allows for greater
control in managing complex transactions by creating checkpoints.

Ex

BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A';

SAVEPOINT deduct_from_A; -- Set a savepoint after deducting from A

UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B';

-- Suppose an error occurs here, so we want to roll back to the savepoint

ROLLBACK TO deduct_from_A;

-- Changes to Account B are undone, but deduction from Account A remains

COMMIT;

In this example, if something goes wrong after SAVEPOINT deduct_from_A, we can roll back to that
savepoint. The changes before the savepoint (deducting from Account A) will remain, while changes
after it (adding to Account B) are undone.
8.list the problem that can occur due to concurrent execution.
1. Concurrent execution of transactions in a database can lead to several problems if not properly
managed. Here are the main issues:

1. Lost Update:

 Occurs when two or more transactions read the same data and then update it
based on the original value.

 If both transactions write their changes, the last write will overwrite the first,
resulting in a "lost" update.

2. Dirty Read (Uncommitted Dependency):

 Happens when a transaction reads data that has been modified by another
uncommitted transaction.

 If the uncommitted transaction rolls back, the data read by the first transaction
becomes invalid or inconsistent.

3. Non-Repeatable Read (Inconsistent Retrieval):

 Arises when a transaction reads the same data multiple times, but another
transaction modifies it in between reads.

 This causes the initial transaction to retrieve different values in successive reads,
leading to inconsistency.

4. Phantom Read:

 Occurs when a transaction reads a set of rows based on a condition, but another
transaction inserts, updates, or deletes rows that affect the original result set.

 This can cause new rows (phantoms) to appear or disappear in subsequent

reads, leading to unexpected results.

5. Serialization Anomaly:

 Refers to a situation where the results of concurrent transactions differ from

what would have occurred if they were executed sequentially in some order.

 Non-serializable execution can lead to inconsistencies and conflicts, which can

be especially problematic in financial and critical systems.

Concurrency control mechanisms, like locking, isolation levels, and timestamps, are used to manage
these problems, ensuring data integrity and consistency in concurrent transactions.
9.Define the grant and revoke command.
The grant command is used by users to provide privileges to database objects and to provide permission
to other users.

A privilege gives permission to access a named object. For example, permission to access a database
table. Users who obtain privileges can gain a connection to the database. It grants users permission to
access objects of a database and administers access rights to users.

Here is how you grant privileges in SQL:

grant privilege_name on object_name

to {user_name | public | role_name}

 object_name: Name of database object

 privilege_name: Permission has to be granted

 user_name: User that obtains access

 public: Used to provide access to all users

 The revoke command functions as the opposite of the grant command.

It is used to remove the privileges on user accounts for access to a
database object. It revokes permission granted to a user on a database
object and also revokes the access rights assigned to users.

revoke privilege_name on object_name

from { user_name| public|role _name}

Here, the revoke command removes every privilege initially granted to the user.

Both the grant and revoke commands in a data control language help assign and deny

permission to users on a database object.

10. Define Triggers.

Trigger is a statement that a system executes automatically when there is any modification to the
database. In a trigger, we first specify when the trigger is to be executed and then the action to be
performed when the trigger executes. Triggers are used to specify certain integrity constraints and
referential constraints that cannot be specified using the constraint mechanism of SQL.
Example –
Suppose, we are adding a tuple to the ‘Donors’ table that is some person has donated blood. So, we
can design a trigger that will automatically add the value of donated blood to the ‘Blood_record’ table.
Types of Triggers
We can define 6 types of triggers for each table:
1. AFTER INSERT activated after data is inserted into the table.
2. AFTER UPDATE: activated after data in the table is modified.
3. AFTER DELETE: activated after data is deleted/removed from the table.
4. BEFORE INSERT: activated before data is inserted into the table.
5. BEFORE UPDATE: activated before data in the table is modified.
6. BEFORE DELETE: activated before data is deleted/removed from the table.

11. Transaction rollback

A transaction rollback is a database operation used to revert a database to its previous state by canceling a
transaction that has encountered an error or is deemed undesirable to complete. When a rollback is performed, any
changes made by the transaction are undone, ensuring data integrity and consistency.
Here’s a quick breakdown of how it works:
1. Start Transaction: When a transaction begins, the database keeps a log of changes.
2. Perform Operations: Changes are made to the data (e.g., updates, deletions, insertions).
3. Error/Abort Condition: If an error occurs, or if the transaction needs to be canceled (manually or
automatically), a rollback can be triggered.
4. Rollback: The database uses the log to undo all changes made during the transaction, returning to the state
before it began.
When Rollbacks Are Useful
 Error Handling: Prevents partial updates if an error occurs mid-transaction.
 Data Integrity: Ensures the database remains consistent, even if part of the transaction fails.
 Application Logic: Allows programs to cancel transactions that don’t meet specific conditions.
Rollbacks are essential in scenarios where data consistency is crucial, like financial transactions or multi-step
processes in databases.

12.Concurrency control
Concurrency control is a database management technique used to ensure that multiple transactions can occur
simultaneously without leading to data inconsistencies or integrity issues. It’s essential in environments where
multiple users or processes access and modify a database at the same time, as it helps maintain data accuracy,
prevents conflicts, and ensures reliable transaction processing.
Why Concurrency Control is Important
Without concurrency control, two or more transactions happening concurrently could interfere with each other in
various ways, such as:
 Dirty reads: One transaction reads data written by another uncommitted transaction.
 Lost updates: Two transactions update the same data simultaneously, with one update overwriting the
other.
  Inconsistent retrievals: Data is read in the middle of a transaction, leading to incomplete or inconsistent
data.
Methods of Concurrency Control
1. Locking: Locking prevents other transactions from accessing data while it’s being modified. Examples
include:
o Exclusive Lock: Only one transaction can modify the data at a time.

o Shared Lock: Multiple transactions can read, but not modify, the data simultaneously.

2. Timestamp Ordering: Transactions are ordered based on timestamps to decide the sequence of execution,
ensuring older transactions have priority.
3. Optimistic Concurrency Control: Assumes conflicts are rare and only checks for conflicts when
transactions are about to commit.
Example of Concurrency Control
Suppose two bank tellers are working with the same account balance.
1. Initial Balance: The account has $500.
2. Transaction 1: Teller A initiates a deposit of $200.
3. Transaction 2: Teller B initiates a withdrawal of $100 at the same time.
Without concurrency control:
 If both transactions read the initial balance at $500 simultaneously, Teller A would calculate $500 + $200 =
$700, while Teller B would calculate $500 - $100 = $400.
 Depending on which transaction completes last, the final balance could incorrectly be recorded as $400 or
$700 instead of the correct $600.
With concurrency control (like locking):
 Teller A’s transaction locks the account while adding $200, setting the balance to $700.
 Teller B’s transaction then subtracts $100 from the updated $700, resulting in a final balance of $600.

********