Una transacción es una unidad de trabajo que mantiene la consistencia de los datos en una base de datos. Si una transacción tiene éxito, los cambios de datos se confirman de forma permanente, pero si falla, se revierten todos los cambios. Las propiedades clave de una transacción son la atomicidad, consistencia, aislamiento y durabilidad. Existen diferentes tipos de transacciones como explícitas, implícitas y de confirmación automática.

1. TRANSACCIONES

2. DEFINICIÓN
Es una unidad única de trabajo. Si una transacción
tiene éxito, todas las modificaciones de los datos
realizadas durante la transacción se confirman y se
convierten en una parte permanente de la base de
datos.
Si una transacción encuentra errores y debe cancelarse
o revertirse, se borran todas las modificaciones de los
datos.

3. PROPIEDADES
 Atomicidad: Las operaciones que componen una transacción deben
considerarse como una sola.
 Consistencia: Una operación nunca deberá dejar datos inconsistentes. Una
transacción es una unidad de integridad porque mantiene la coherencia de los
datos, transformando un estado coherente de datos en otro estado de datos
igualmente coherente.
 Aislamiento: Los datos "sucios" deben estar aislados, y evitar que los usuarios
utilicen información que aún no está confirmada o validada. El aislamiento
requiere que parezca que cada transacción sea la única que manipula el
almacén de datos, aunque se puedan estar ejecutando otras transacciones al
mismo tiempo. Una transacción nunca debe ver las fases intermedias de otra
transacción.
 Durabilidad: Una vez completada la transacción los datos actualizados ya serán
permanentes y confirmados. Si una transacción se realiza satisfactoriamente, el
sistema garantiza que sus actualizaciones se mantienen, aunque el equipo falle
inmediatamente después de la confirmación.

4. TIPOS DE TRANSACCIONES
 De Confirmación Automática: El Gestor de Datos inicia una transacción
automáticamente por cada operación que actualice datos. De este modo mantiene
siempre la consistencia de la base de datos, aunque puede generar bloqueos.
 Implícitas: Cuando el Gestor de Datos comienza una transacción automáticamente
cada vez que se produce una actualización de datos, pero el que dicha transacción
se confirme o se deshaga, lo debe indicar el programador.
 Explícitas: Son las que iniciamos nosotros "a mano" mediante instrucciones SQL,
los programadores son los que indican qué operaciones va a abarcar. Cada
transacción se inicia explícitamente con la instrucción BEGIN TRANSACTION y se
termina explícitamente con una instrucción COMMIT o ROLLBACK.
 Transacciones de Ámbito de Lote: Una transacción implícita o explícita de
Transact-SQL que se inicia en una sesión de MARS (conjuntos de resultados
activos múltiples), que solo es aplicable a MARS, se convierte en una transacción
de ámbito de lote. Si no se confirma o revierte una transacción de ámbito de lote
cuando se completa el lote, SQL Server la revierte automáticamente.

5. COMANDOS
 A. BEGIN TRANSACTION: Marca el punto de inicio de una transacción explícita.
Representa un punto en el que los datos a los que hace referencia una conexión
son lógica y físicamente coherentes. Si se producen errores, se pueden revertir
todas las modificaciones realizadas en los datos después de BEGIN
TRANSACTION para devolver los datos al estado conocido de coherencia.
 B. COMMIT: Marca el final de una transacción explícita o de confirmación
automática. Esta instrucción hace que los cambios en la transacción se
confirmen permanentemente en la base de datos. La instrucción COMMIT es
idéntica a COMMIT WORK, COMMIT TRAN y COMMIT TRANSACTION.
 C. ROLLBACK: Revierte una transacción al principio de la misma. No se
confirman cambios para la transacción en la base de datos. La instrucción
ROLLBACK es idéntica a ROLLBACK WORK, ROLLBACK TRAN y ROLLBACK
TRANSACTION.

6. EJEMPLO
Trabajaremos con la base de datos Northwind en nuestros ejemplos.
Vamos a realizar una transacción que modifica el precio de dos
productos de la base de datos.
USE NorthWind
DECLARE @Error int
--Declaramos una variable que utilizaremos para almacenar un
posible código de error
BEGIN TRAN
--Iniciamos la transacción
UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'

7. --Ejecutamos la primera sentencia
SET @Error=@@ERROR
--Si ocurre un error almacenamos su código en @Error
--y saltamos al trozo de código que deshara la transacción. Si, eso de
ahí es un
--GOTO, el demonio de los programadores, pero no pasa nada por
usarlo
--cuando es necesario
IF (@Error<>0) GOTO TratarError
--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
SET @Error=@@ERROR
--Y si hay un error hacemos como antes
IF (@Error<>0) GOTO TratarError
--Si llegamos hasta aquí es que los dos UPDATE se han completado
con
--éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN

8. TratarError:
--Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0 THEN
BEGIN
PRINT 'Ha ecorrido un error. Abortamos la transacción'
--Se lo comunicamos al usuario y deshacemos la transacción
--todo volverá a estar como si nada hubiera ocurrido
ROLLBACK TRAN
END

9. CONCLUSIONES
 Es difícil imaginar hoy en día la concentración de
información sin base de datos, las pequeñas o grandes
industrias tienen como base de su sistema informático la
construcción de base de datos con la que podemos tener
gran versatilidad con cualquier tipo de equipos.
 La seguridad en las bases de datos es muy importante
debido a que garantiza la integridad física y lógica de los
datos.