A transaction is a "unit of work" that has the following ("ACID") properties.
a transaction is an indivisible unit of work; all of its actions either succeed or they all fail (logical units of work (LUW)). In the event of a failure of any operation, effects of all operations that make up the transaction should be undone, and data should be rolled back to its previous state.
after the transaction executes, it must leave the system in a correct state or abort (leaving the system in its initial state: COMMIT or ROLLBACK). For example, in the case of relational databases, a consistent transaction should preserve all the integrity constraints defined on the data.
a transaction's behavior is not affected by other transactions that execute concurrently. The effect of executing a set of transactions serially should be the same as that of running them concurrently. This requires two things:
during the course of a transaction, an intermediate (possibly inconsistent) state of the data should not be exposed to all other transactions
two concurrent transactions should not be able to operate on the same data. Database management systems usually implement this feature using locking.
a transaction's effects are permanent (persistent) after it commits (information is saved in a recoverable storage resource).