2. Una de los objetivos de usar una base de datos era el de
garantizar la atomicidad de un conjunto de operaciones. La
atomicidad es la garantía que nos da el sistema de que, ante la
ejecución de una serie de operaciones, englobadas en lo que
llamamos una transacción, o bien se ejecutan todas las
operaciones, o bien no se efectúa ninguna.
En otras palabras, el conjunto de operaciones se ejecuta en su
totalidad o no se ejecuta en absoluto, no dejando ningún efecto
sobre el sistema.
Una vez empezada una
transacción, por tanto,
esta puede acabar con
una confirmación que la
hace definitiva

3. La atomicidad nos facilita mantener la consistencia de los
datos. Decimos que una base de datos es consistente si se
garantiza que siempre se verifican unas determinadas
condiciones, definidas por nosotros, y que expresaremos en
forma de reglas. Las condiciones deben cumplirse
obligatoriamente antes y después de la transacción (pero
pueden incumpliese transitoriamente dentro de la misma).
Por ejemplo, consideremos una transacción de fondos desde
la cuenta A a la cuenta B. Definimos una regla de consistencia
que establezca que la suma de los saldos de A y B debe ser
constante. Esta regla debe cumplirse antes y después de la
transacción, aunque si es posible que durante la transacción
se produzcan inconsistencias.

4. Otra característica destacable de una transacción es su
durabilidad. Esta garantiza que, en el instante en el que se
finaliza la transacción, esta perdura. Incluso en el caso de fallo
en el sistema, este deberá ser capaz de recuperarse y
recordar todas la transacciones que hayan sido completadas.
Finalmente, un sistema de transacciones debe garantizar el
aislamiento. El aislamiento es la garantía de que los cambios
hechos dentro de cualquier transacción son invisibles al resto
los usuarios, mientras esta no haya concluido. Así se
garantiza que el resto de usuarios no observen los cambios
intermedios.

5. El gestor de transacciones es la parte del gestor de base de
datos que se asegura de mantener la atomicidad, durabilidad
y aislamiento de las transacciones. Si no hay ningún error, al
acabar la transacción esta se da por definitiva.
Si se produce un error durante la transacción, el sistema debe
restaurar la base de datos al estado en que estaba justo antes
de que empezara la transacción. Este proceso se denomina
recuperación de fallos.