Execution of a transaction in isolation (that is, with no other transaction executing concurrently) preserves the consistency of the database.
Which means data in the database has to be consistent not only before the transaction but also after the transaction.
Let Ti be a transaction that transfers $50 from account A to account B. This transaction
can be defined as:
A := A − 50;
B := B + 50;
Lets assume that, just before the execution of transaction Ti, the values of accounts A and B are $1000 and $2000, respectively.
The consistency requirement here is that the sum of A and B be unchanged by the execution of the transaction.
Here in above example $50 are being transferred from A to B. So before transaction sum of A+B = $1000 + $2000 = $3000.
After all the instructions of the transaction executed:
A value will be $950 (according to instruction set A:=A-50 and write (A).)
B value will be $2050 (according to instruction set B:=B+50 and write (B).)
Hence now sum A+B = $950 + $2050 = $3000 (same as before the transaction.)
Without the consistency requirement, money could be created or destroyed by the transaction! It can be verified easily that, if the database is consistent before an execution of the transaction, the database remains consistent after the execution of the transaction.
Ensuring consistency for an individual transaction is the responsibility of
the application programmer who codes the transaction. This task may be facilitated
by automatic testing of integrity constraints.