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.