BASIC CONCEPTS Database Management System

BASIC CONCEPTS Database Management System


BASIC CONCEPTS Database Management System : A Transaction is a unit of program execution that accesses and possibly updates various data items. A Transaction usually results from the execution of a user program written in a high-level Data Manipulation Language or Programming Language and is delimited by Statements of the form begin transaction and end transaction.

To ensure integrity of data, a transaction should have the following properties (called ACID properties):

  1. Atomicity: Transactions are atomic (all or nothing). Either all operations of the transaction are reflected property in the database, or none are.
  2. Consistency: A Transaction, while executing in isolation (that is, with no other transaction executing concurrently), transforms a consistent state of the database into another consistent State, without necessarily preserving consistency at all intermediate steps.
  3. Isolation : Transactions are isolated from one another, that is, even though many transactions may be running concurrently, but updates of a transaction are hidden from others until a transaction Commits. That is, for every pair of Transactions Ti and Tj, it appears to Ti that either Tj finished execution before the start of Ti or Tj stated after Ti finished. Thus, each transaction is unaware of other transactions executing concurrently in the System.
  4. Durability: Once a transaction commits, its updates survive, even if the system crashes before the updates are physically written into the database.

Access to the database is through the following two operations:

read (X) It transfers the data item X from the database to a local buffer belonging to the transaction that executed the read operation.

write (X) it transfers the data item X from the local buffer of the transaction that executed the write Operation to the database.

The write operation does not necessarily result in immediate update of the data on the disk; updates may be temporarily stored in RAM and transferred to the disk later.

Let Ti be a transaction that transfers R 50/- from account A to account B. Then Ti may be defined as follows:


Ti: read (A);

A:= A-50;


read (B);

B:= B+50;

Write (B).

Let us consider the ACID properties with respect to Ti.

Consistency: The consistency requirement here is that the sum of A and B should remain unchanged by execution of the transaction.

Atomicity: Suppose a failure occurs after write (A) and before write (B) is executed, value of A + B as reflected in the database would be deficit as compared to the value of A+B existing in the database just prior to the execution of Ti. Such a state is called inconsistent state, which is to be prevented anyhow. So, if a transaction fails during its execution, it is ROLLED BACK, so that the system goes back to the consistent that existed just before Ticommenced execution. Hence, it is as if Tinever started execution. This is ensured by the Atomicity requirement i.e. if the Atomicity property is provided, either all actions of a transaction are reflected in the database or none are. The basic idea behind ensuring Atomicity is as follows:- Databasekeeps track of old values of any data which is updated. This is part of the log maintained on the disk. If a transaction fails, old values of updated data are used to restore the database to an earlier consistent state. Handling of Atomicity is the responsibility of a system component called transaction-management-component.

Durability: Once the execution of a transaction completes successfully, and the user who initiated the transaction has been informed of the fund transfer, no subsequent system failure would undo the update i.e., the update would persist even in event of Subsequent System failures. Ensuring Durability is the responsibility of a system component called recovery-management-component. It is closely related to transaction-management-component.

Isolation: The database is temporarily inconsistent during the transaction processing, for example after write (A) has been completed but write (B) is yet to be executed; if another Transaction Treads A and B during this period and computes A+B, the resulting value not represent the real-world situation. Now, if Ti updates A and B based on the computed value of A+B, the database may be left in an inconsistent state at the end. This is because though Ti and Tj, when executed Stand-alone, will preserve consistency of the database, but when executed concurrently, the may interleave in a way that consistency of the database may not be preserved. A simple solution to this problem is to execute the transactions serially, but such a scheme would deny the performance benefits of concurrent processing. So, concurrent execution of transaction is very much permitted, but the isolation property of transaction ensures the concurrent execution of transactions results in a system state that is equivalent to a state that would have resulted if the transactions would have been executed serially. This is ensured by a system component called concurrency control component.