Relational Calculus

• There is an alternate way of formulating queries known

as Relational Calculus.
• Relational calculus is a non-procedural query language.
• In the non-procedural query language, the user is
concerned with the details of how to obtain the end
results.
• The relational calculus tells what to do but never
explains how to do.
• It is based on Predicate calculus, a name derived from
branch of symbolic language.
• There are two types of quantifiers:
• Universal Quantifiers: The universal quantifier
denoted by ∀ is read as for all which means that in a
given set of tuples exactly all tuples satisfy a given
Existential Quantifiers: The existential quantifier
denoted by ∃ is read as for all which means that in a
given set of tuples there is at least one occurrences
whose value satisfy a given condition.
• Tuple Relational Calculus (TRC)
• It is a non-procedural query language which is based on
finding a number of tuple variables also known as range
variable for which predicate holds true.
• It describes the desired information without giving a
specific procedure for obtaining that information.
• A Query in the tuple relational calculus is expressed as
following notation
{T | P (T)} or {T | Condition (T)}
• T is the resulting tuples
• P(T) is the condition used to fetch T.
• { T.name | Author(T) AND T.article = 'database' }
• Output: This query selects the tuples from the AUTHOR relation. It
returns a tuple with 'name' from Author who has written an article
on 'database’.
• TRC (tuple relation calculus) can be quantified. In TRC, we can use
Existential (∃) and Universal Quantifiers (∀).
• { R| ∃T ∈ Authors(T.article='database' AND R.name=T.name)}
• 2. Domain Relational Calculus (DRC)
• The second form of relation is known as Domain relational calculus.
• In domain relational calculus, filtering variable uses the domain of
attributes. Domain relational calculus uses the same operators as
tuple calculus.
• It uses logical connectives ∧ (and), ∨ (or) and ┓ (not). It uses
Existential (∃) and Universal Quantifiers (∀) to bind the variable.
• {< article, page, subject > | ∈ javatpoint ∧ subject = 'database'}
Transaction
• 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.
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
1.Open_Account(X)
2.Old_Balance = X.balance
3.New_Balance = Old_Balance - 800
4.X.balance = New_Balance
5.Close_Account(X)
Y's Account
1.Open_Account(Y)
2.Old_Balance = Y.balance
3.New_Balance = Old_Balance + 800
4.Y.balance = New_Balance
5.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.
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:
• 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
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:
1. Re-start the transaction
2. 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.
• 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 T2 which was followed by
all the operations of T1.
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.
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).
• 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.
• For example:
• 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
 Precedence graph for schedule S1:

The precedence graph for schedule S1 contains a cycle

that's why Schedule S1 is non-serializable.
• 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
Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no

cycle that's why ScheduleS2 is serializable.