A transaction must have the properties of atomicity, consistency, isolation and durability. In addition, when more than one transaction is being executed concurrently, we must have serializability.
When two or more transactions are running concurrently, the steps of the transactions would normally be interleaved. The interleaved execution of transactions is decided by the database system software called the scheduler which receives a stream of user requests that arise from the active transactions. A particular sequencing (usually interleaved) of the actions of a set of transactions is called a schedule. A serial schedule is a schedule in which all the operations of one transaction are completed before another transaction can begin (that is, there is no interleaving). Later in the section we will show several different schedules of the same two transactions.
It is the responsibility of the scheduler to maintain consistency while allowing maximum concurrency. The scheduler therefore must make sure that only correct schedules are allowed. We would like to have a mechanism or a set of conditions that define a correct schedule. That is unfortunately not possible since it is always very complex to define a consistent database. The assertions defining a consistent database (called integrity constraints or consistency constraints) could well be as complex as the database itself and checking these assertions, assuming one could explicitly enumerate them, after each transaction would not be practical. The simplest approach to this problem is based on the notion of each transaction being correct by itself and a schedule of concurrent executions being able to preserve their correctness.
A serial schedule is always correct since we assume transactions do not depend on each other. We further assume that each transaction when run in isolation transforms a consistent database into a new consistent state and therefore a set of transactions executed one after another (i.e. serially) must also be correct. A database may however not be consistent during the execution of a transaction but it is assumed the database is consistent at the end of the transaction. Although using only serial schedules to ensure consistency is a possibility, it is often not a realistic approach since a transaction may at times be waiting for some input/output from secondary storage or from the user while the CPU remains idle, wasting a valuable resource. Another transaction could have been running while the first transaction is waiting and this would obviously improve the system efficiency. We therefore need to investigate schedules that are not serial. However, since all serial schedules are correct, interleaved schedules that are equivalent to them must also be considered correct. There are in fact n! different serial schedules for a set of any n transactions. Note that not all serial schedules of the same set of transactions result in the same consistent state of the database. For example, a seat reservation system may result in different allocations of seats for different serial schedules although each schedule will ensure that no seat is sold twice and no request is denied if there is a free seat available on the flight. However one serial schedule could result in 200 passengers on the plane while another in 202 as shown below.
Let us consider an airline reservation system. Let there be 12 seats available on flight QN32. Three requests arrive; transaction T1 for 3 seats, transaction T2 for 5 seats and transaction for T3 7 seats. If the transactions are executed in the order { T1 , T2 , T3 } then we allocate 8 seats but cannot meet the third request since there are only 4 seats left after allocating seats for the first two transactions. If the transactions are executed in the order { T2  , T3 ,  T1 }, we allocate all the 12 remaining seats but the request of transaction T1  cannot be met. If the transactions are instead executed in the order { T3 , T1 , T2 } then we allocate 10 seats but are unable to meet the request of Transaction T2 for 5 seats. In all there are 3!, that is 6, different serial schedules possible. The remaining three are { T1 , T3 , T2 }, { T2  , T1 , T3 }, and { T3 , T2 , T1 }. They lead to 10, 8 and 12 seats being sold respectively. All the above serial schedules must be considered correct although any one of the three possible results may be obtained as a result of running these transactions.
We have seen that some sets of transactions when executed concurrently may lead to problems, for example, lost update anomaly. Of course, any sets of transactions can be executed concurrently without leading to any difficulties if the read and write sets of these transactions do not intersect. We want to discuss sets of transactions that do interfere with each other. To discuss correct execution of such transactions, we need to define the concept of serializability.
Let T be a set of n transactions T1, T2………. Tn. If the n transactions are executed serially (call this execution S), we assume they terminate properly and leave the database in a consistent state. A concurrent execution of the n transactions in T (call this execution C) is called serializable if the execution is computationally equivalent to a serial execution. There may be more than one such serial execution. That is, the concurrent execution C always produces exactly the same effect on the database as some serial execution S does where S is some serial execution of T, not necessarily the order
T1, T2………. Tn. Thus if a transaction T1 writes a data item A in the interleaved schedule C before another transaction T1 reads or writes the same data item, the schedule C must be equivalent to a serial schedule in which Ti appears before Tj. Therefore in the interleaved transaction Ti appears logically before Tj it does; same as in the equivalent serial schedule. The concept of serializability defined here is sometimes called final state serializability; other forms of serializability exist. The final state serializability has sometimes been criticized for being too strict while at other times it has been criticized for being not strict enough! Some of these criticisms are valid though and it is therefore necessary to provide another definition of serializability called view serializability. Two schedules are called view serializable if the order of any two conflicting operations in the two schedules is the same. If a schedule of transactions is not serializable, we may be able to overcome the concurrency problems by modifying the schedule so that it serializable. The modifications are made by the database scheduler.
We now consider a number of examples of possible schedules of two transactions running concurrently. Consider a situation where a couple has three accounts (A, B, C) with a bank. The husband and the wife maintain separate personal savings accounts while they also maintain a loan account on their house. A is the husband's account, B is the wife's account and C is the housing loan. Each month a payment of $500 is made to the account C. To make the payment on this occasion, the couple walks to two adjoining automatic teller machines and the husband transfers $200 from account A to C (Transaction 1) while the wife on the other machine transfers $300 from account B to C (Transaction 2). Several different schedules for these two transactions are possible. We present the following four schedules for consideration
A serial schedule without interleaving


    Transaction 1

     Time

    Transaction 2

    Read A
    A:=A-200
    Write A
    Read C
    C:=C+200
    Write C
-
-
-
-
-
-

         1
         2
         3
         4
         5
         6
         7
         8
         9
       10
       11
       12

-
-
-
-
-
-
     Read B
     B:=B-300
     Write B
     Read C
     C:=C+300
     Write C

An interleaved serializable schedule


     Transaction 1

         Time

     Transaction 2

     Read A
     A:=A-200
     Write A
-
-
-
     Read C
     C:=C+200
     Write C
-
-
-

            1
            2
            3
            4
            5
            6
            7
            8
            9
           10
           11
           12

-
-
-
     Read B
     B:=B-300
     Write B
-
-
-
     Read C
     C:=C+300
     Write C

An interleaved non-serializable schedule

       Transaction 1

      Time

        Transaction 2

     Read A
     A:=A-200
     Write A
     Read C
-
-
-
-
-
-
     C:=C+200
      Write C

          1
          2
          3
          4
          5
          6
          7
          8
          9
         10
         11
         12

-
-
-
-
    Read B
    B:=B-300
    Write B
    Read C
    C:=C+300
     Write C
-
-

Another interleaved serializable schedule

       Transaction 1

         Time

     Transaction 2

-
-
     Read A
     A:=A-200
     Write A
     Read C
     C:=C+200
     Write C
-
-
-
-

               1          
               2
               3
               4
               5
               6
               7             
               8
               9
              10
              11
              12

     Read B
     B:=B-300
     Write B
-
-
-
-
-
-
    Read C
    C:=C+300
     Write C

 

It is therefore clear that many interleaved schedules would result in a consistent state while many others will not. All correct schedules are serializable since they all must be equivalent to either serial schedule (T1, T2) or (T2, T1).