CHAPTER – IV

DEPENDENCIES AND NORMAL FORMS

What is Normalization?
Normalization is a database design technique that reduces data redundancy and eliminates
undesirable characteristics like Insertion, Update and Deletion Anomalies. A normalization rule
divides larger tables into smaller tables and links them using relationships. The purpose of
Normalisation in SQL is to eliminate redundant (repetitive) data and ensure data is stored
logically.
The inventor of the relational model Edgar Codd proposed the theory of normalization of data
with the introduction of the First Normal Form, and he continued to extend theory with Second
and Third Normal Form. Later he joined Raymond F. Boyce to develop the theory of Boyce-Codd
Normal Form.

Database Normal Forms

Here is a list of Normal Forms in SQL:

 1NF (First Normal Form)

 2NF (Second Normal Form)
 3NF (Third Normal Form)
 BCNF (Boyce-Codd Normal Form)
 4NF (Fourth Normal Form)
 5NF (Fifth Normal Form)
 6NF (Sixth Normal Form)

Database Normalization with Examples

Database Normalization Example can be easily understood with the help of a case study.
Assume, a video library maintains a database of movies rented out. Without any normalization in
database, all information is stored in one table as shown below. Let’s understand Normalization
database with normalization example with solution:

Names Address Movies data Salutation

First Street – Pirates of the Caribbean , Clash Ms.
Janet Jones
Plot no-4 of Titans
Forgetting Sarah Marshal , Daddy Mr.
Robert Phill 3rd street -34
‘s little Girl
Robert Phill 5th Avenue Clash of Titans Mr.

Here you see Movies Rented column has multiple values.

 : 1NF (First Normal Form) Rules:

As per the rule of first normal form, an attribute (column) of a table cannot hold multiple values.
It should hold only atomic values.

 Each table cell should contain a single value.

 Each record needs to be unique.

From the Above table, we make in 1 NF

Names Address Movies data Salutation
Janet Jones First Street –Plot no-4 Pirates of the Caribbean Ms
Janet Jones First Street –Plot no-4 Clash of Titans Ms.
Robert Phill 3rd street -34 Forgetting Sarah Marshal Mr.
Robert Phill 3rd street -34 Daddy ‘s little Girl Mr.
Robert Phill 5th Avenue Clash of Titans Mr.

What is a KEY in SQL?

A KEY in SQL is a value used to identify records in a table uniquely. An SQL KEY is a single column
or combination of multiple columns used to uniquely identify rows or tuples in the table. SQL Key
is used to identify duplicate information, and it also helps establish a relationship between
multiple tables in the database.
Note: Columns in a table that are NOT used to identify a record uniquely are called non-key
columns.

What is a Primary Key?

A primary is a single column value used to identify a database record uniquely.

It has following attributes

 A primary key cannot be NULL

 A primary key value must be unique
 The primary key values should rarely be changed
 The primary key must be given a value when a new record is inserted.

What is Composite Key?

A composite key is a primary key composed of multiple columns used to identify a record
uniquely

In our database, we have two people with the same name Robert Phil, but they live in different
places.
 Fig: Composite key in Database

Hence, we require both Full Name and Address to identify a record uniquely. That is a composite
key.

: 2NF (Second Normal Form) Rules

 Rule 1- It should be in 1NF

 Rule 2- Single Column Primary Key that does not functionally dependant on any subset
of candidate key relation

It is clear that we can’t move forward to make our simple database in 2 nd Normalization form
unless we partition the table above.

Membership Names Address Movies data

1 Janet Jones First Street –Plot Pirates of the Caribbean , Clash of Titans
2 Robert Phill 3rd street -34 Forgetting Sarah Marshal , Daddy ‘s little
3 Robert Phill 5th Avenue Clash of Titans

Membership Movies data

1 Pirates of the Caribbean
1 Clash of Titans
2 Forgetting Sarah Marshal
2 Daddy ‘s little Girl
3 Clash of Titans

We have divided our 1NF table into two tables viz. Table 1 and Table2. Table 1 contains
member information. Table 2 contains information on movies rented.

We have introduced a new column called Membership_id which is the primary key for table 1.
Records can be uniquely identified in Table 1 using membership id
 : Database – Foreign Key: From the above table, Membership_ID is the Foreign Key
Membership Movies data
1 Pirates of the Caribbean
1 Clash of Titans
2 Forgetting Sarah Marshal
2 Daddy ‘s little Girl
3 Clash of Titans

Foreign Key references the primary key of another Table! It helps connect your Tables

 A foreign key can have a different name from its primary key
 It ensures rows in one table have corresponding rows in another
 Unlike the Primary key, they do not have to be unique. Most often they aren’t
 Foreign keys can be null even though primary keys can not

Membership
Foreign Key Movies data
1 Pirates of the Caribbean
1 Clash of Titans
2 Forgetting Sarah Marshal
2 Daddy ‘s little Girl
3 Clash of Titans

 Foreign key references primary key

 Foreign key can only have values present in primary key
 It could have a name other than that of primary key
Primary

MemberShip Names Address Salutation

First Street –Plot
1 Janet Jones Ms
no-4
rd
2 Robert Phill 3 street -34 Mr.
3 Robert Phill 5th Avenue Mr.

Why do you need a foreign key?

Suppose, a novice inserts a record in Table below such as

Insert a record in Table below where Member ID =101
Membership Movies data
101 Pirates of the Caribbean , Clash of Titans
But Membership ID 101 is not present in table above
Membership Names Address Salutation
1 Janet Jones First Street –Plot no-4 Ms.
2 Robert Phill 3rd street -34 Mr
3 Robert Phill 5th Avenue Mr

But Database will throw an ERROR this helps in referential integrity

 You will only be able to insert values into your foreign key that exist in the unique key
in the parent table. This helps in referential integrity.
 The above problem can be overcome by declaring membership id from above Table 2 as
foreign key of membership id from Table1
 Now, if somebody tries to insert a value in the membership id field that does not exist
in the parent table, an error will be shown!

What are transitive functional dependencies?

A transitive functional dependency is when changing a non-key column, might cause any of the
other non-key columns to change

Consider the table 1. Changing the non-key column Full Name may change Salutation.

: 3NF (Third Normal Form) Rules

 Rule 1- Be in 2NF
 Rule 2- Has no transitive functional dependencies

To move our 2NF table into 3NF, we again need to again divide our table.

Below is a 3NF example in SQL database:

 We have again divided our tables and created a new table which stores salutation
 There are no transitive functional dependencies, and hence our table is in 3NF

In Table 3 Salutation ID is primary key, and in Table 1 Salutation ID is foreign to primary key in
Table 3
Boyce Codd normal form (BCNF)

It is an advance version of 3NF that’s why it is also referred as 3.5NF. BCNF is stricter than 3NF. A
table complies with BCNF if it is in 3NF and for every functional dependency X->Y, X should be the
super key of the table.

Example: Suppose there is a company wherein employees work in more than one department.
They store the data like this:

emp_id emp_nationality emp_dept dept_type dept_no_of_emp

1001 Austrian Production and planning D001 200
1001 Austrian stores D001 250
1002 American design and technical support D134 100
1002 American Purchasing department D134 600

unctional dependencies in the table above:

emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}

Candidate key: {emp_id, emp_dept}

The table is not in BCNF as neither emp_id nor emp_dept alone are keys.
To make the table comply with BCNF we can break the table in three tables like this:

emp_nationality table:
emp_id emp_nationality
1001 Austrian
1002 American

emp_dept table:

emp_dept dept_type dept_no_of_emp

Production and planning D001 200
stores D001 250
design and technical support D134 100
Purchasing department D134 600
emp_dept_mapping table:

emp_id emp_dept
1001 Production and planning
1001 stores
1002 design and technical support
1002 Purchasing department

Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}

Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}

This is now in BCNF as in both the functional dependencies left side part is a key.

A good database design has many benefits and is a goal to achieve for every DBA −
Easy Retrieval of Information
If the design is developed properly, then it would be easier to retrieve information. Correct
design means the tables, constraints, and relationships created are flawless.
Easier Modification
Changes that you make to the value of a given field will not adversely affect the values of other
fields within the table.
Easy to Maintain
The database structure should be easy to maintain. The design is perfect if changes in one field is
not affecting changes in another field.
Information
With a good design, you can enhance the quality and consistency of information.
Well-designed Database
If the database is well defined, then the flaws and issues of a poorly designed database will not
need to be addressed.
A badly designed database has the following problems:

 Related data is scattered over various tables. A change must be updated at many places.
It's possible that the information is only half present; it's there in one table, but missing in
another one.
 Data is inconsistent or ambiguous (poly interpretable).
 The database is unnecessary complex, hacked with lots of tricks. The database
designer done unnecessary complex things, where it could have been done so much
easier.
 The database has 'hidden' information, for example by the sequence of rows in a table.
 The database is slow, inflexible, hard to extend and cannot handle all real life situations.

What is Functional Dependency?

Functional Dependency (FD) is a constraint that determines the relation of one attribute to
another attribute in a Database Management System (DBMS). Functional Dependency helps to
maintain the quality of data in the database. It plays a vital role to find the difference between
good and bad database design.

A functional dependency is denoted by an arrow “→”. The functional dependency of X on Y is

represented by X → Y. Let’s understand Functional Dependency in DBMS with example.

Key Terms :

Key Terms Description

Axioms is a set of inference rules used to infer all the functional dependencies on a
Axiom
relational database.
It is a rule that suggests if you have a table that appears to contain two entities which are
Decomposition
determined by the same primary key then you should consider breaking them up into two
Dependent It is displayed on the right side of the functional dependency diagram.

Determinant It is displayed on the left side of the functional dependency Diagram.

It suggests that if two tables are separate, and the PK is the same, you should consider
Union
putting them together

Rules of Functional Dependencies

Below are the three most important rules for Functional Dependency in Database:

 Reflexive rule –. If X is a set of attributes and Y is_subset_of X, then X holds a value of Y.

 Augmentation rule: When x -> y holds, and c is attribute set, then ac -> bc also holds. That
is adding attributes which do not change the basic dependencies.
 Transitivity rule: This rule is very much similar to the transitive rule in algebra if x -> y
holds and y -> z holds, then x -> z also holds. X -> y is called as functionally that
determines y.
 Types of Functional Dependencies in DBMS
There are mainly four types of Functional Dependency in DBMS. Following are the types of
Functional Dependencies in DBMS:

 Multivalued Dependency
 Trivial Functional Dependency
 Non-Trivial Functional Dependency
 Transitive Dependency

Multivalued Dependency in DBMS

Multivalued dependency occurs in the situation where there are multiple independent
multivalued attributes in a single table. A multivalued dependency is a complete constraint
between two sets of attributes in a relation. It requires that certain tuples be present in a
relation. Consider the following Multivalued Dependency Example to understand.

Example:
Car_model Maf_year Color
H001 2017 Metallic
H001 2017 Green
H005 2018 Metallic
H005 2018 Blue
H010 2015 Metallic
H033 2012 Gray

In this example, maf_year and color are independent of each other but dependent on
car_model. In this example, these two columns are said to be multivalue dependent on
car_model.
This dependence can be represented like this:
car_model -> maf_year
car_model-> colour
Trivial Functional Dependency in DBMS
The Trivial dependency is a set of attributes which are called a trivial if the set of attributes are
included in that attribute.

So, X -> Y is a trivial functional dependency if Y is a subset of X. Let’s understand with a Trivial
Functional Dependency Example.

For example:
Emp_id Emp_name
AS555 Harry
AS811 George
AS999 Kevin
 Consider this table of with two columns Emp_id and Emp_name.

{Emp_id, Emp_name} -> Emp_id is a trivial functional dependency as Emp_id is a subset of

{Emp_id,Emp_name}.

Non Trivial Functional Dependency in DBMS

Functional dependency which also known as a nontrivial dependency occurs when A->B
holds true where B is not a subset of A. In a relationship, if attribute B is not a subset of
attribute A, then it is considered as a non-trivial dependency.

Company CEO Age

Microsoft Satya Nadella 51
Google Sundar Pichai 46
Apple Tim Cook 57

Example:

(Company} -> {CEO} (if we know the Company, we knows the CEO name)

But CEO is not a subset of Company, and hence it’s non-trivial functional dependency.

Transitive Dependency in DBMS

A Transitive Dependency is a type of functional dependency which happens when t is indirectly
formed by two functional dependencies. Let’s understand with the following Transitive
Dependency Example.

Example:

Company CEO Age

Microsoft Satya Nadella 51
Google Sundar Pichai 46
Alibaba Jack Ma 54

{Company} -> {CEO} (if we know the compay, we know its CEO’s name)

{CEO } -> {Age} If we know the CEO, we know the Age

Therefore according to the rule of rule of transitive dependency:

{ Company} -> {Age} should hold, that makes sense because if we know the company name, we
can know his age.
4.15 Armstrong’s Axioms in Functional Dependency
The term Armstrong axioms refer to the sound and complete set of inference rules or axioms,
introduced by William W. Armstrong, that is used to test the logical implication of functional
dependencies. If F is a set of functional dependencies then the closure of F, denoted as ,
is the set of all functional dependencies logically implied by F. Armstrong’s Axioms are a set of
rules, that when applied repeatedly, generates a closure of functional dependencies.

Axioms –

Secondary Rules : These rules can be derived from the above axioms.
 UNIT-V
TRANSACTIONS

Transactions:

 The transaction is a set of logically related operation. It contains a group of tasks.

 A transaction is an action or series of actions. It is performed by a single user to perform
operations for accessing the contents of the database.

OR

A transaction is an action or series of actions that are being performed by a single user or
application program, which reads or updates the contents of the database.

A transaction can be defined as a logical unit of work on the database. This may be an entire
program, a piece of a program, or a single command (like the SQL commands such as INSERT or
UPDATE), and it may engage in any number of operations on the database. In the database
context, the execution of an application program can be thought of as one or more transactions
with non-database processing taking place in between.

Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's account. This
small transaction contains several low-level tasks:

X – ACCOUNT Y-ACCOUNT

 Open_Account(X) Open_Account(y)
 Old_Balance = X.balance Old _Balance = Y.Balance
 New_Balance = Old_Balance - 800 New_Balance = Old_Balance + 800
 X.balance = New_Balance Y.balance = New_Balance
 Close_Account(X) Close_Account(Y)

Operations of Transaction:

 Read(X): Read operation is used to read the value of X from the database and stores it
in a buffer in main memory.
 Write(X): Write operation is used to write the value back to the database from the
buffer.
 Let's take an example to debit transaction from an account which consists of following
operations:
 1. R(X);
 2. X = X - 500;
 3. W(X);
 Let's assume the value of X before starting of the transaction is 4000.
 The first operation reads X's value from database and stores it in a buffer.
 The second operation will decrease the value of X by 500. So buffer will contain 3500.
 The third operation will write the buffer's value to the database. So X's final value will be
3500.
But it may be possible that because of the failure of hardware, software or power, etc. that
transaction may fail before finished all the operations in the set.

For example: If in the above transaction, the debit transaction fails after executing operation 2
then X's value will remain 4000 in the database which is not acceptable by the bank.

To solve this problem, we have two important operations:

To solve this problem, we have two important operations:

Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.

Transaction property
The transaction has the four properties. These are used to maintain consistency in a database,
before and after the transaction.

Property of Transaction

1. Atomicity
2. Consistency
3. Isolation
4. Durability
Atomicity
 It states that all operations of the transaction take place at once if not, the transaction is
aborted.
 There is no midway, i.e., the transaction cannot occur partially. Each transaction is
treated as one unit and either run to completion or is not executed at all.

Atomicity involves the following two operations:

Abort: If a transaction aborts then all the changes made are not visible.
Commit: If a transaction commits then all the changes made are visible.

Example: Let's assume that following transaction T consisting of T1 and T2. A consists of Rs 600
and B consists of Rs 300. Transfer Rs 100 from account A to account B.

T1 T2

Read(A) Read(B)
A:=A-100 Y:=Y+100
Write(A) Write(B)

After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.

If the transaction T fails after the completion of transaction T1 but before completion of transaction T2,
then the amount will be deducted from A but not added to B. This shows the inconsistent database state.
In order to ensure correctness of database state, the transaction must be executed in entirety.
Consistency
 The integrity constraints are maintained so that the database is consistent before and
after the transaction.
 The execution of a transaction will leave a database in either its prior stable state or a
new stable state.
 The consistent property of database states that every transaction sees a consistent
database instance.
 The transaction is used to transform the database from one consistent state to another
consistent state.
For example: The total amount must be maintained before or after the transaction.
1. Total before T occurs = 600+300=900
2. Total after T occurs= 500+400=900
Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.
 Isolation
 It shows that the data which is used at the time of execution of a transaction cannot be
used by the second transaction until the first one is completed.
 In isolation, if the transaction T1 is being executed and using the data item X, then that
data item can't be accessed by any other transaction T2 until the transaction T1 ends.
 The concurrency control subsystem of the DBMS enforced the isolation property.
Durability
 The durability property is used to indicate the performance of the database's consistent
state. It states that the transaction made the permanent changes.
 They cannot be lost by the erroneous operation of a faulty transaction or by the system
failure. When a transaction is completed, then the database reaches a state known as the
consistent state. That consistent state cannot be lost, even in the event of a system's
failure.
 The recovery subsystem of the DBMS has the responsibility of Durability property.

States of Transaction:
In a database, the transaction can be in one of the following states -

Active state
 The active state is the first state of every transaction. In this state, the transaction is being
executed.
 For example: Insertion or deletion or updating a record is done here. But all the records
are still not saved to the database.

Partially committed
 In the partially committed state, a transaction executes its final operation, but the data is
still not saved to the database.
 In the total mark calculation example, a final display of the total marks step is executed in
this state.
Committed

A transaction is said to be in a committed state if it executes all its operations successfully. In this
state, all the effects are now permanently saved on the database system.

Failed state
 If any of the checks made by the database recovery system fails, then the transaction is said
to be in the failed state.
 In the example of total mark calculation, if the database is not able to fire a query to fetch
the marks, then the transaction will fail to execute.

Aborted
 If any of the checks fail and the transaction has reached a failed state then the database
recovery system will make sure that the database is in its previous consistent state. If not
then it will abort or roll back the transaction to bring the database into a consistent state.
 If the transaction fails in the middle of the transaction then before executing the transaction,
all the executed transactions are rolled back to its consistent state.
 After aborting the transaction, the database recovery module will select one of the two
operations:

 Re-start the transaction

 Kill the transaction

Schedule

A series of operation from one transaction to another transaction is known as schedule. It is used
to preserve the order of the operation in each of the individual transaction.

1. Serial Schedule

The serial schedule is a type of schedule where one transaction is executed completely before
starting another transaction. In the serial schedule, when the first transaction completes its
cycle, then the next transaction is executed.
For example: Suppose there are two transactions T1 and T2 which have some operations. If it
has no interleaving of operations, then there are the following two possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations of T2.
2. Execute all the operations of T1 which was followed by all the operations of T2.

 In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2.
 In the given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.

2. Non-serial Schedule
 If interleaving of operations is allowed, then there will be non-serial schedule.
 It contains many possible orders in which the system can execute the individual
operations of the transactions.
 In the given figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It
has interleaving of operations.

3. Serializable schedule

 The serializability of schedules is used to find non-serial schedules that allow the
transaction to execute concurrently without interfering with one another.
 It identifies which schedules are correct when executions of the transaction have
interleaving of their operations.
 A non-serial schedule will be serializable if its result is equal to the result of its
transactions executed serially.
 Here :
Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.

Testing of Serializability

Serialization Graph is used to test the Serializability of a schedule.

Assume a schedule S. For S, we construct a graph known as precedence graph. This graph
has a pair G = (V, E), where V consists a set of vertices, and E consists a set of edges. The
set of vertices is used to contain all the transactions participating in the schedule. The set
of edges is used to contain all edges Ti ->Tj for which one of the three conditions holds:

1. Create a node Ti → Tj if Ti executes write (Q) before Tj executes read (Q).

2. Create a node Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
3. Create a node Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

Precedence of Graph S :
  If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti are
executed before the first instruction of Tj is executed.
 If a precedence graph for schedule S contains a cycle, then S is non-serializable. If the
precedence graph has no cycle, then S is known as serializable.

Read(A): In T1, no subsequent writes to A, so no new edges

Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges

Precedence graph for schedule S1:

The precedence graph for schedule S1 contains a cycle that's why Schedule S1 is non-serializable.
 .
Explanation:
Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why ScheduleS2 is serializable.
Conflict Serializable Schedule
 A schedule is called conflict serializability if after swapping of non-conflicting operations, it
can transform into a serial schedule.
 The schedule will be a conflict serializable if it is conflict equivalent to a serial schedule.

Conflicting Operations

The two operations become conflicting if all conditions satisfy:

1. Both belong to separate transactions.
2. They have the same data item.
3. They contain at least one write operation.
Example:
Swapping is possible only if S1 and S2 are logically equal.

Here, S1 = S2. That means it is non-conflict.

Here, S1 ≠ S2. That means it is conflict.

Conflict Equivalent

In the conflict equivalent, one can be transformed to another by swapping non-conflicting

operations. In the given example, S2 is conflict equivalent to S1 (S1 can be converted to S2 by
swapping non-conflicting operations).

Two schedules are said to be conflict equivalent if and only if:

1. They contain the same set of the transaction.

2. If each pair of conflict operations are ordered in the same way.

Schedule S2 is a serial schedule because, in this, all operations of T1 are performed before
starting any operation of T2. Schedule S1 can be transformed into a serial schedule by swapping
non-conflicting operations of S1.

After swapping of non-conflict operations, the schedule S1 becomes:

T1 T2

Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B)
View Serializability
o A schedule will view serializable if it is view equivalent to a serial schedule.
o If a schedule is conflict serializable, then it will be view serializable.
o The view serializable which does not conflict serializable contains blind writes.

View Equivalent

Two schedules S1 and S2 are said to be view equivalent if they satisfy the following conditions:

1. Initial Read

An initial read of both schedules must be the same. Suppose two schedule S1 and S2. In schedule
S1, if a transaction T1 is reading the data item A, then in S2, transaction T1 should also read A.

Above two schedules are view equivalent because Initial read operation in S1 is done by T1 and
in S2 it is also done by T1.

2. Updated Read

In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti should read A which is
updated by Tj

Above two schedules are not view equal because, in S1, T3 is reading A updated by T2 and in S2,
T3 is reading A updated by T1.

3. Final Write

A final write must be the same between both the schedules. In schedule S1, if a transaction T1
updates A at last then in S2, final writes operations should also be done by T1.
Above two schedules is view equal because Final write operation in S1 is done by T3 and in S2, the final
write operation is also done by T3.

Example:

Schedule S

With 3 transactions, the total number of possible schedule

= 3! = 6

 S1 = <T1 T2 T3>
 S2 = <T1 T3 T2>
 S3 = <T2 T3 T1>
 S4 = <T2 T1 T3>
 S5 = <T3 T1 T2>
 S6 = <T3 T2 T1>

Taking first schedule S1:

Schedule S1
Step 1: final Updation on data items
In both schedules S and S1, there is no read except the initial read that's why we don't need to
check that condition.
Step 2: Initial Read
The initial read operation in S is done by T1 and in S1, it is also done by T1.
Step 3: Final Write
The final write operation in S is done by T3 and in S1, it is also done by T3. So, S and S1 are view
Equivalent.
The first schedule S1 satisfies all three conditions, so we don't need to check another schedule.
Hence, view equivalent serial schedule is:
T1 → T2 → T3

Recoverability of Schedule
Sometimes a transaction may not execute completely due to a software issue, system crash or
hardware failure. In that case, the failed transaction has to be rollback. But some other
transaction may also have used value produced by the failed transaction. So we also have to
rollback those transactions.

The above table 1 shows a schedule which has two transactions. T1 reads and writes the value of
A and that value is read and written by T2. T2 commits but later on, T1 fails. Due to the failure,
we have to rollback T1. T2 should also be rollback because it reads the value written by T1, but
T2 can't be rollback because it already committed. So this type of schedule is known as
irrecoverable schedule.

Irrecoverable schedule: The schedule will be irrecoverable if Tj reads the updated value of Ti and
Tj committed before Ti commit.
The above table 2 shows a schedule with two transactions. Transaction T1 reads and writes A,
and that value is read and written by transaction T2. But later on, T1 fails. Due to this, we have to
rollback T1. T2 should be rollback because T2 has read the value written by T1. As it has not
committed before T1 commits so we can rollback transaction T2 as well. So it is recoverable with
cascade rollback.

Recoverable with cascading rollback: The schedule will be recoverable with cascading rollback
if Tj reads the updated value of Ti. Commit of Tj is delayed till commit of Ti.

The above Table 3 shows a schedule with two transactions. Transaction T1 reads and write A and
commits, and that value is read and written by T2. So this is a cascade less recoverable schedule.

Transaction Isolation Levels in DBMS:

As we know that, in order to maintain consistency in a database, it follows ACID properties.
Among these four properties (Atomicity, Consistency, Isolation and Durability) Isolation
determines how transaction integrity is visible to other users and systems. It means that a
transaction should take place in a system in such a way that it is the only transaction that is
accessing the resources in a database system.

Isolation levels define the degree to which a transaction must be isolated from the data
modifications made by any other transaction in the database system. A transaction isolation
level is defined by the following phenomena –
 Dirty Read – A Dirty read is the situation when a transaction reads a data that has not
yet been committed. For example, let’s say transaction 1 updates a row and leaves it
uncommitted, meanwhile, Transaction 2 reads the updated row. If transaction 1 rolls back
the change, transaction 2 will have read data that is considered never to have existed.
 Non Repeatable read – Non Repeatable read occurs when a transaction reads same
row twice, and get a different value each time. For example, suppose transaction T1 reads
data. Due to concurrency, another transaction T2 updates the same data and commit, Now
if transaction T1 rereads the same data, it will retrieve a different value.
 Phantom Read – Phantom Read occurs when two same queries are executed, but the
rows retrieved by the two, are different. For example, suppose transaction T1 retrieves a
set of rows that satisfy some search criteria. Now, Transaction T2 generates some new rows
that match the search criteria for transaction T1. If transaction T1 re-executes the
statement that reads the rows, it gets a different set of rows this time.
Based on these phenomena, The SQL standard defines four isolation levels:
1. Read Uncommitted – Read Uncommitted is the lowest isolation level. In this level, one
transaction may read not yet committed changes made by other transaction, thereby
allowing dirty reads. In this level, transactions are not isolated from each other.
2. Read Committed – This isolation level guarantees that any data read is committed at
the moment it is read. Thus it does not allow dirty read. The transaction holds a read or
write lock on the current row, and thus prevent other transactions from reading, updating
or deleting it.
3. Repeatable Read – This is the most restrictive isolation level. The transaction holds read
locks on all rows it references and writes locks on all rows it inserts, updates, or deletes.
Since other transaction cannot read, update or delete these rows, consequently it avoids non-
repeatable read.
4. Serializable – This is the highest isolation level. A serializable execution is guaranteed to
be serializable. Serializable execution is defined to be an execution of operations in which
concurrently executing transactions appears to be serially executing.

Transaction definition in SQL:

A transaction is a unit of work that is performed against a database. Transactions are units or
sequences of work accomplished in a logical order, whether in a manual fashion by a user or
automatically by some sort of a database program. A transaction is the propagation of one or
more changes to the database.

How to implement Transactions using SQL?

Following commands are used to control transactions. It is important to note that these
statements cannot be used while creating tables and are only used with the DML Commands
such as – INSERT, UPDATE and DELETE.

1. BEGIN TRANSACTION: It indicates the start point of an explicit or local transaction.

Syntax: BEGIN TRANSACTION transaction_name ;
2. SET TRANSACTION: Places a name on a transaction.
Syntax: SET TRANSACTION [READ WRITE | READ ONLY];
3. COMMIT: If everything is in order with all statements within a single transaction, all changes
are recorded together in the database is called committed. The COMMIT command saves all
the transactions to the database since the last COMMIT or ROLLBACK command.
Syntax: COMMIT;
Example 1 :
Following is an example which would delete those records from the table which have age = 20
and then COMMIT the changes in the database.
Queries:
DELETE FROM Student WHERE AGE = 20;
COMMIT;
Output:
Thus, two rows from the table would be deleted and the SELECT statement would look like,

4. ROLLBACK: If any error occurs with any of the SQL grouped statements, all changes need to
be aborted. The process of reversing changes is called rollback. This command can only be
used to undo transactions since the last COMMIT or ROLLBACK command was issued.
Syntax: ROLLBACK;
Example:
From the above example 1
Delete those records from the table which have age =20 and then ROLLBACK changes in the
database.
Queries:
DELETE FROM student WHERE AGE =20;
ROLLBACK;
OUTPUT:

5. SAVEPOINT: creates points within the groups of transactions in which to ROLLBACK.

A SAVEPOINT is a point in a transaction in which you can roll the transaction back to a certain
point without rolling back the entire transaction.

Syntax for Savepoint command:

SAVEPOINT SAVEPOINT_NAME;
This command is used only in the creation of SAVEPOINT among all the transactions.
In general ROLLBACK is used to undo a group of transactions.
Syntax for rolling back to Savepoint command:

ROLLBACK TO SAVEPOINT_NAME;
you can ROLLBACK to any SAVEPOINT at any time to return the appropriate data to its original
state.
Example:
From the above example Sample table1,
Delete those records from the table which have age = 20 and then ROLLBACK the changes in
the database by keeping Savepoints.
Queries:
SAVEPOINT SP1; //Savepoint created.
DELETE FROM Student WHERE AGE = 20; //deleted
SAVEPOINT SP2; //Savepoint created.
Here SP1 is first SAVEPOINT created before deletion.
In this example one deletion have taken place.
After deletion again SAVEPOINT SP2 is created.

Deletion have been taken place, let us assume that you have changed your mind and decided
to ROLLBACK to the SAVEPOINT that you identified as SP1 which is before deletion.
deletion is undone by this statement ,

ROLLBACK TO SP1;
//Rollback completed.
6. RELEASE SAVEPOINT:- This command is used to remove a SAVEPOINT that you have
created.
Syntax: RELEASE SAVEPOINT SAVEPOINT_NAME
Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command to undo
transactions performed since the last SAVEPOINT.
It is used to initiate a database transaction and used to specify characteristics of the
transaction that follows.
Serializability by Locks-Locking: Lock-Based Protocol

In this type of protocol, any transaction cannot read or write data until it acquires an appropriate
lock on it. There are two types of lock:
1. Shared lock:
o It is also known as a Read-only lock. In a shared lock, the data item can only read by the
transaction.
o It can be shared between the transactions because when the transaction holds a lock,
then it can't update the data on the data item.
2. Exclusive lock:
o In the exclusive lock, the data item can be both reads as well as written by the
transaction.
o This lock is exclusive, and in this lock, multiple transactions do not modify the same data
simultaneously.

There are four types of lock protocols available:

1. Simplistic lock protocol

It is the simplest way of locking the data while transaction. Simplistic lock-based protocols allow
all the transactions to get the lock on the data before insert or delete or update on it. It will
unlock the data item after completing the transaction.

2. Pre-claiming Lock Protocol

o Pre-claiming Lock Protocols evaluate the transaction to list all the data items on which
they need locks.
o Before initiating an execution of the transaction, it requests DBMS for all the lock on all
those data items.
o If all the locks are granted then this protocol allows the transaction to begin. When the
transaction is completed then it releases all the lock.
o If all the locks are not granted then this protocol allows the transaction to rolls back and
waits until all the locks are granted.
Two-phase locking (2PL)
o The two-phase locking protocol divides the execution phase of the transaction into three
parts.
o In the first part, when the execution of the transaction starts, it seeks permission for the
lock it requires.
o In the second part, the transaction acquires all the locks. The third phase is started as
soon as the transaction releases its first lock.
o In the third phase, the transaction cannot demand any new locks. It only releases the
acquired locks.

Two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may be acquired by the
transaction, but none can be released.

Shrinking phase: In the shrinking phase, existing lock held by the transaction may be released,
but no new locks can be acquired.

In the below example, if lock conversion is allowed then the following phase can happen:
1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.
2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.
Example :

The following way shows how unlocking and locking work with 2-PL.
Transaction T1:
o Growing phase: from step 1-3
o Shrinking phase: from step 5-7
o Lock point: at 3
Transaction T2:
o Growing phase: from step 2-6
o Shrinking phase: from step 8-9
o Lock point: at 6
Strict Two-phase locking (Strict-2PL)
o The first phase of Strict-2PL is similar to 2PL. In the first phase, after acquiring all the
locks, the transaction continues to execute normally.
o The only difference between 2PL and strict 2PL is that Strict-2PL does not release a lock
after using it.
o Strict-2PL waits until the whole transaction to commit, and then it releases all the locks at
a time.
o Strict-2PL protocol does not have shrinking phase of lock release.
Timestamp Ordering Protocol
 The Timestamp Ordering Protocol is used to order the transactions based on their
Timestamps. The order of transaction is nothing but the ascending order of the
transaction creation.
 The priority of the older transaction is higher that's why it executes first. To determine
the timestamp of the transaction, this protocol uses system time or logical counter.
 The lock-based protocol is used to manage the order between conflicting pairs among
transactions at the execution time. But Timestamp based protocols start working as soon
as a transaction is created.
 Let's assume there are two transactions T1 and T2. Suppose the transaction T1 has
entered the system at 007 times and transaction T2 has entered the system at 009 times.
T1 has the higher priority, so it executes first as it is entered the system first.
 The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write'
operation on a data.

Basic Timestamp ordering protocol works as follows:

1. Check the following condition whenever a transaction Ti issues a Read (X) operation:
o If W_TS(X) >TS(Ti) then the operation is rejected.
o If W_TS(X) <= TS(Ti) then the operation is executed.
o Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues a Write(X) operation:

o If TS(Ti) < R_TS(X) then the operation is rejected.
o If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back otherwise the
operation is executed.

Where,
TS(TI) denotes the timestamp of the transaction Ti.
R_TS(X) denotes the Read time-stamp of data-item X.
W_TS(X) denotes the Write time-stamp of data-item X.

Advantages and Disadvantages of TO protocol:

o TO protocol ensures serializability since the precedence graph is as follows:
 o TS protocol ensures freedom from deadlock that means no transaction ever
waits.
o But the schedule may not be recoverable and may not even be cascade- free.

4.15 Validation Based Protocol

Validation phase is also known as optimistic concurrency control technique.

In the validation based protocol, the transaction is executed in the following
three phases:

1. Read phase: In this phase, the transaction T is read and executed. It is

used to read the value of various data items and stores them in
temporary local variables. It can perform all the write operations on
temporary variables without an update to the actual database.
2. Validation phase: In this phase, the temporary variable value will be
validated against the actual data to see if it violates the serializability.
3. Write phase: If the validation of the transaction is validated, then the
temporary results are written to the database or system otherwise the
transaction is rolled back.

Here each phase has the following different timestamps:

Start(Ti): It contains the time when Ti started its execution.

Validation (Ti): It contains the time when Ti finishes its read phase and starts its
validation phase.

Finish(Ti): It contains the time when Ti finishes its write phase.

 This protocol is used to determine the time stamp for the transaction
for serialization using the time stamp of the validation phase, as it is
the actual phase which determines if the transaction will commit or
rollback.
 Hence TS(T) = validation(T).
 The serializability is determined during the validation process. It can't
 be decided in advance.
 While executing the transaction, it ensures a greater degree of
concurrency and also less number of conflicts.
 Thus it contains transactions which have less number of rollbacks.