UNIT 3

Created @January 16, 2025 3:54 PM

Class DBMS

transaction query
schema : acc
tables: accnt

std procedure: create acct

view: accnt detail

std procedure: transfer money

view: transaction history

BEGIN TRANSACTION;
UPDATE accounts.accountdetails
SET balance = balance - 5000
WHERE accountnumber = 'I89012';

UPDATE accounts.accountdetails
SET balance = balance + 5000
WHERE accountnumber = 'E45678';

INSERT INTO accounts.accounttransfer (txnno, fromaccount, toaccount, txndate, amo

VALUES
('a101', 'I89012', 'E45678', GETDATE(), 5000, 'Completed', 'Transfer successful')

COMMIT;
IF (SELECT balance FROM accounts.accountdetails WHERE accountnumber = 'I89012') <
BEGIN
PRINT 'Insufficient funds';
ROLLBACK;
RETURN;
END

Normalization in Database Management Systems

(DBMS)
Normalization is a database design technique that reduces data redundancy and eliminates data
anomalies by organizing fields and tables of a database. It involves breaking down larger tables into
smaller ones and linking them using relationships.

UNIT 3 1
 Why Normalize Database?
Eliminate redundant data

Ensure data dependencies make sense

Maintain data integrity

Reduce data anomalies

Types of Normal Forms

1. First Normal Form (1NF)
Rules for 1NF:

Each table cell should contain a single value

Each record needs to be unique

Each column should have a unique name

Example of table NOT in 1NF:

StudentID Name Courses

1 John Math, Physics, Chemistry

After converting to 1NF:

StudentID Name Course

1 John Math

1 John Physics

1 John Chemistry

-- Create a new table to hold atomic values

CREATE TABLE StudentSubjects (
StudentID INT,
Name NVARCHAR(50),
Subject NVARCHAR(50)
);

-- Split the multi-valued column into individual rows

INSERT INTO StudentSubjects (StudentID, Name, Subject)
SELECT

UNIT 3 2
 StudentID,
Name,
TRIM(value) AS Subject
FROM
OriginalTable
CROSS APPLY STRING_SPLIT(Subjects, ','); -- STRING_SPLIT splits comma-separated v

-- Check the result

SELECT * FROM StudentSubjects;

-- Create a new table without duplicates

SELECT DISTINCT StudentID, Name, Subject
INTO CleanedStudentSubjects
FROM StudentSubjects;

-- Replace the original table

UNIT 3 3
 DROP TABLE StudentSubjects;
EXEC sp_rename 'CleanedStudentSubjects', 'StudentSubjects';

-- Create a separate table for phone numbers

CREATE TABLE StudentPhones (
StudentID INT,
PhoneNumber NVARCHAR(15)
);

-- Insert individual phone numbers into the new table

INSERT INTO StudentPhones (StudentID, PhoneNumber)
SELECT
StudentID,
TRIM(value) AS PhoneNumber
FROM
OriginalTable
CROSS APPLY STRING_SPLIT(PhoneNumbers, ','); -- Split multi-valued column

-- Add FirstName and LastName columns

ALTER TABLE StudentSubjects
ADD FirstName NVARCHAR(50), LastName NVARCHAR(50);

-- Update these columns by splitting FullName

UPDATE StudentSubjects
SET
FirstName = LEFT(FullName, CHARINDEX(' ', FullName) - 1),
LastName = SUBSTRING(FullName, CHARINDEX(' ', FullName) + 1, LEN(FullName));

UNIT 3 4
 2. Second Normal Form (2NF)
Rules for 2NF:

Should be in 1NF

All non-key attributes should be fully functionally dependent on the primary key

Example of table NOT in 2NF:

Order_ID Product_ID Product_Name Quantity

1 P1 Laptop 2

2 P1 Laptop 3

After converting to 2NF:

Table 1: Orders

Order_ID Product_ID Quantity

1 P1 2

2 P1 3

Table 2: Products

Product_ID Product_Name

P1 Laptop

3. Third Normal Form (3NF)

Rules for 3NF:

Should be in 2NF

No transitive dependencies (non-prime attributes depending on other non-prime attributes)

Example of table NOT in 3NF:

Student_ID Department_ID Department_Name

1 D1 Computer Science

2 D1 Computer Science

After converting to 3NF:

UNIT 3 5
 Table 1: Students

Student_ID Department_ID

1 D1

2 D1

Table 2: Departments

Department_ID Department_Name

D1 Computer Science

4. Boyce-Codd Normal Form (BCNF)

BCNF (Boyce-Codd Normal Form) represents a more rigorous and stringent version of the Third Normal
Form. It addresses certain anomalies that might still exist in 3NF by enforcing a stricter rule: for any
functional dependency A → B in the relation, A must be a super key. This means that every determinant
(the left side of a functional dependency) must be a candidate key of the relation, ensuring an even
higher degree of data integrity.

Benefits of Normalization
Better database organization

More efficient data access

Easier maintenance

Reduced data redundancy

Better data consistency

When to Denormalize?
Sometimes, denormalization might be necessary for:

Improving query performance

Reducing join operations

Meeting specific business requirements

Note: The level of normalization needed depends on your specific use case and requirements. Not all
databases need to be normalized to 5NF.

transaction model and acid properties

Collections of operations that form a single logical unit of work are called transactions.

A transaction is a unit of program execution that accesses and possibly updates various data items.

Operations of Transaction
A user can make different types of requests to access and modify the contents of a database. So, we
have different types of operations relating to a transaction. They are discussed as follows:

i) Read(X)

UNIT 3 6
 A read operation is used to read the value of X from the database and store it in a buffer in the main
memory for further actions such as displaying that value.

Such an operation is performed when a user wishes just to see any content of the database and not
make any changes to it.

For example, when a user wants to check his/her account's balance, a read operation would be
performed on user's account balance from the database.

ii) Write(X)
A write operation is used to write the value to the database from the buffer in the main memory. For
a write operation to be performed, first a read operation is performed to bring its value in buffer, and
then some changes are made to it, e.g. some set of arithmetic operations are performed on it
according to the user's request, then to store the modified value back in the database, a write
operation is performed.

For example, when a user requests to withdraw some money from his account, his account balance
is fetched from the database using a read operation, then the amount to be deducted from the
account is subtracted from this value, and then the obtained value is stored back in the database
using a write operation.

iii) Commit
This operation in transactions is used to maintain integrity in the database. Due to some failure of
power, hardware, or software, etc., a transaction might get interrupted before all its operations are
completed. This may cause ambiguity in the database, i.e. it might get inconsistent before and after
the transaction.

To ensure that further operations of any other transaction are performed only after work of the
current transaction is done, a commit operation is performed to the changes made by a transaction
permanently to the database.

iv) Rollback
This operation is performed to bring the database to the last saved state when any transaction is
interrupted in between due to any power, hardware, or software failure.

In simple words, it can be said that a rollback operation does undo the operations of transactions
that were performed before its interruption to achieve a safe state of the database and avoid any
kind of ambiguity or inconsistency.

Properties of Transaction
Transactions follow 4 properties, namely, Atomicity, Consistency, Isolation, and Durability.

i) Atomicity
This property ensures that either all operations of a transaction are executed or it is aborted. In any
case, a transaction can never be completed partially.

Each transaction is treated as a single unit (like an atom). Atomicity is achieved through commit and
rollback operations, i.e. changes are made to the database only if all operations related to a
transaction are completed, and if it gets interrupted, any changes made are rolled back using
rollback operation to bring the database to its last saved state.

ii) Consistency

UNIT 3 7
 This property of a transaction keeps the database consistent before and after a transaction is
completed.

Execution of any transaction must ensure that after its execution, the database is either in its prior
stable state or a new stable state.

In other words, the result of a transaction should be the transformation of a database from one
consistent state to another consistent state.

Consistency, here means, that the changes made in the database are a result of logical operations
only which the user desired to perform and there is not any ambiguity.

iii) Isolation
This property states that two transactions must not interfere with each other, i.e. if some data is
used by a transaction for its execution, then any other transaction can not concurrently access that
data until the first transaction has completed.

It ensures that the integrity of the database is maintained and we don't get any ambiguous values.
Thus, any two transactions are isolated from each other.

This property is enforced by the concurrency control subsystem of DBMS.

iv) Durability
This property ensures that the changes made to the database after a transaction is completely
executed, are durable.

It indicates that permanent changes are made by the successful execution of a transaction.

In the event of any system failures or crashes, the consistent state achieved after the completion of
a transaction remains intact. The recovery subsystem of DBMS is responsible for enforcing this
property.

ACID in a Nutshell
Property Ensures Example

If money is deducted but not added, the entire transaction rolls

Atomicity All-or-nothing execution
back.

Consistency Database remains valid Constraints like "no negative balance" are preserved.

No interference in
Isolation Concurrent transactions appear to run serially.
execution

Durability Changes are permanent After committing a transfer, the data persists through failures.

transaction states
During the complete process of a transaction, there are a lot of states which are described below:

Active State:
When the transaction is going well without any error, then this is called an active state. If all the
operations are good, then it goes to a partially committed state, and if it fails, then it enters into a failed
state.

Partially Committed State:

UNIT 3 8
 All the changes in the database after the read and write operation needs to be reflected in permanent
memory or database. So, a partially committed state system enters into a committed state for the
permanent changes, and if there is any error, then it enters into a failed state.

Failed State:
If there is any error in hardware or software which makes the system fail, then it enters into the failed
state. In the failed state, all the changes are discarded, and the system gets its previous state which was
consistent.

Advertisement

Aborted State:
If there is any failure during the execution, then the system goes from failed to an aborted state. From an
aborted state, the transaction will start its execution from a fresh start or from a newly active state.

Committed State:
If the execution of a transaction is successful, the changes are made into the main memory and stored
in the database permanently, which is called the committed state.

Terminated State:
If the transaction is in the aborted state(failure) or committed state(success), then the execution stops,
and it is called the terminated state.

serializability
A serializability schedule in DBMS ensures that concurrent transactions produce the same final result as
if they were executed one after the other. It also helps to maintain the data consistency and integrity

Key Concepts in Transaction Serializability:

1. Schedule: A schedule is a sequence of operations (read, write, etc.) from multiple transactions. It
represents the order in which these operations are executed by the database.

2. Serial Schedule: A serial schedule is one where the operations of one transaction are executed
completely before the operations of another transaction begin. There is no interleaving of
operations.

UNIT 3 9
 Example of a Serial Schedule:

T1: Read(A), Write(A)

T2: Read(B), Write(B)

In this schedule, T1 runs first, and after it is finished, T2 begins. There are no overlapping
operations.

3. Non-Serial Schedule: A non-serial schedule involves the interleaving of operations from multiple
transactions. In these schedules, transactions are executed concurrently, and their operations may
overlap.

Example of a Non-Serial Schedule:

T1: Read(A)

T2: Write(B)

T1: Write(A)

T2: Read(B)

Types of Transaction Serializability:

1. Conflict Serializability:

A schedule is conflict serializable if it can be transformed into a serial schedule by swapping

non-conflicting operations.

Two operations are considered conflicting if they:

Belong to different transactions.

Access the same data item.

At least one of them is a write operation.

This type of serializability can be determined by drawing a precedence graph of the transactions
in the schedule and checking if the graph is acyclic. If the graph is acyclic, then the schedule is
conflict serializable. If it contains a cycle, then the schedule is not conflict serializable.

Example
Consider a schedule with three transactions, T1, T2, and T3, and the following set of operations:

T1: R(P), W(Q)

T2: R(Q), W(R)
T3: R(R), W(P)

The operations that are performed in the transactions are R(Read) and W(Write) operations on
the data items ‘P’ and ‘Q’.

In a precedence graph, the edges represent the ordering constraints between transactions in the
concurrent execution of a database system. If we encounter any conflicts between transactions,
then we will draw an edge. The conflict serializability of the schedule can be determined by
constructing a precedence graph as follows:

T1 -> T2
T2 -> T3
T3 -> T1

UNIT 3 10
 The graph has a cycle (T1 -> T2 -> T3 -> T1), indicating that the schedule is not conflict
serializable.

2. View Serializability:

A schedule is view serializable if the final outcome (the view) is the same as a serial
execution, without necessarily being able to transform it into a serial schedule by swapping
operations.

The concept of view equivalence ensures that each transaction sees the same data as it
would in a serial execution.

View serializability can be determined by constructing a view serializable schedule graph (VSG)
of the transactions in the schedule. The VSG contains nodes representing the transactions and
edges representing conflicts and views between the transactions. If the VSG is acyclic, then the
schedule is view serializable.

Example
Consider a schedule with three transactions, T1, T2, and T3, and the following set of operations:

T1: R(P), W(Q)

T2: R(Q), W(R)
T3: R(R), W(P)

The operations that are performed in the transactions are R(Read) and W(Write) operations on
the data items ‘P’ and ‘Q’. In a VSG, the edges represent the ordering constraints between
transactions in the concurrent execution of a database system. It ensures that the transactions
are view serializable.

We must first identify the view equivalent schedules for the given concurrent execution to obtain
the edges in this graph. Two schedules are view equivalent if they produce the same set of
database states for any initial database state. The view serializability of the schedule can be
determined by constructing a VSG as follows:

T1 -> T2
T2 -> T3
T3 -> T1

UNIT 3 11
 The VSG has a cycle (T1 -> T2 -> T3 -> T1), indicating that the schedule is not view serializable.

Functional Dependency
The functional dependency is a relationship that exists between two attributes. It typically exists
between the primary key and non-key attribute within a table.

1. X → Y

The left side of FD is known as a determinant, the right side of the production is known as a dependent.

For example:

Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address.

Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table because if we
know the Emp_Id, we can tell that employee name associated with it.

Functional dependency can be written as:

1. Emp_Id → Emp_Name

We can say that Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency

1. Trivial functional dependency

A → B has trivial functional dependency if B is a subset of A.

The following dependencies are also trivial like: A → A, B → B

Example:

Consider a table with two columns Employee_Id and Employee_Name.

{Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency as

UNIT 3 12
 Employee_Id is a subset of {Employee_Id, Employee_Name}.
Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial dependencies too.

2. Non-trivial functional dependency

A → B has a non-trivial functional dependency if B is not a subset of A.

When A intersection B is NULL, then A → B is called as complete non-trivial.

Example:

1. ID → Name,

2. Name → DOB

3. Transitive Dependency:
A transitive dependency exists when an attribute depends on another attribute through a third
attribute.

Example: If we have the functional dependencies:

AccountID→BranchCode\text{AccountID} \to \text{BranchCode}

BranchCode→BranchLocation\text{BranchCode} \to \text{BranchLocation}

Then, AccountID→BranchLocation\text{AccountID} \to \text{BranchLocation} by transitivity.

In this case, knowing the AccountID will also tell us the BranchLocation indirectly through the
BranchCode.

3. Multivalued Dependency:
A multivalued dependency exists when an attribute in a relation is dependent on another, but not in
a simple functional way. It occurs when one attribute determines a set of values for another
attribute.

Example: If an account has multiple contact numbers, the AccountID would determine multiple
contact numbers, but the relationship between AccountID and ContactNumbers is not a simple one-
to-one functional dependency.

Armstrong’s Axioms in Functional Dependency in

DBMS
Reflexivity: If A is a set of attributes and B is a part of A, then the function A -> B is valid.

Augmentation: If the A -> B dependency is valid, adding multiple elements to either side of the
dependency will not affect the dependency.

Transitivity: If the functions X → Y and Y → Z are both valid, then X → Z is also valid according to
the transitivity rule.

Union rule If X → Y and X → Z, then X → YZ is true.

Decomposition rule Its reverse of Rule 4. If X → YZ, then X → Y, and X → Z are true

Pseudotransitivity rule If X → Y and ZY → A are true, then XZ → A is also true.

UNIT 3 13