In the context of the ACID principles for database
transactions "Consistency" denotes the
characteristic of a transaction to transform a consistent state
of the database into another consistent state. Consistency is the one
characteristic of a transaction which can normally not be enforced by
a transaction manager. The code of the transaction itself must ensure
this consistency, e.g. by testing if enough money is on a checking
account before paying out money or by ensuring that if a supplier of
goods is removed from the database, also all goods it supplied are
removed. Please note that it is not required that the database has a
consistent state during the whole execution time of the transaction,
only at the end.
From the consistency of one transaction one can deduce that a
schedule of several concurrent transactions will
preserve the consistency of the whole database, too, as long as the
schedule is serializable. The proof is easy, since a serializable
schedule means that an equivalent serial schedule exists. In
that serial schedule all transactions are executed one after another
and therefore transform the database through a series of (consistent)
states to the final consistent state.
Ensuring the consistency of the whole database by demanding that
each transaction maintains it can be seen as the
implicit way to ensure database consistency. The
consistency constraints of the database are
encoded implicitly within the transactions, e.g. by comparing the
account balance vs. the credit line in the first example above. This
has the disadvantage that one single transaction which ends in an
inconsistent state (e.g. due to a programming error) can
invalidate the whole database. In another approach therefore the
consistency criteria are stored explicitly within
the database as rules and consistency
constraints. Using these the DBMS can then check on its own if the
final state of a transaction is consistent. If not, the transaction
will be aborted. This achieves more protection against
inconsistencies but implementation - of the
database but also of the error responses of transactions - becomes
more difficult.