El documento explica las características de las transacciones en un sistema de gestión de bases de datos. Una transacción es un conjunto de órdenes que se ejecutan de forma atómica, confirmándose todas las modificaciones si tiene éxito o revirtiéndose si falla. Las transacciones deben cumplir las propiedades de atomicidad, coherencia, aislamiento y durabilidad.

1. BASE DE
DATOS IIIng. Marco Aurelio Porro Chulli
Ingeniería de Sistemas y
Telemática
INTEGRANTES:
 Sandrita Rafael Estela..
 Rosaliny Rivera Salazar.
TRANSACCIONES

2. TRANSACCIONES
Una transacción en un Sistema de Gestión de Bases de
Datos es un conjunto de órdenes que se ejecutan
formando una unidad de trabajo, es decir, en forma
indivisible o atómica. 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. Atomicidad (Atomicity)
Una transacción es una unidad de trabajo en la que se produce
una serie de operaciones entre las instrucciones BEGIN
TRANSACTION y END TRANSACTION de una aplicación. Una
transacción se ejecuta exactamente una vez y tiene carácter
"atómico" (de subdivisión), es decir, el trabajo se realiza en su
totalidad o no se realiza en ningún caso.
Las operaciones asociadas a una transacción comparten
normalmente un objetivo común y son interdependientes. Si el
sistema ejecutase únicamente una parte de las operaciones,
podría poner en peligro el objetivo final de la transacción. La
atomicidad elimina la posibilidad de procesar un subconjunto de
operaciones.

4. Consistencia (Consistency)
Es la propiedad que asegura que sólo se empieza aquello
que se puede acabar. Por lo tanto, se ejecutan aquellas
operaciones que no van a romper la reglas y directrices de
integridad de la base de datos. 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.

5. Aislamiento (Isolation)
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.
Las transacciones alcanzan el nivel máximo de
aislamiento cuando se pueden serializar. En este nivel,
los resultados obtenidos de un conjunto de
transacciones concurrentes son idénticos a los
obtenidos mediante la ejecución en serie de las
transacciones.

6. Permanencia (Durability_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. El
registro especializado permite que el
procedimiento de reinicio del sistema complete
las operaciones no finalizadas, garantizando la
permanencia de la transacción.
La permanencia se suele implementar forzando a
los periféricos encargados de almacenar los
cambios a confirmar la completa y definitiva
transmisión de los datos al medio (generalmente,
el disco).

7.  Configuració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.
 Transacciones 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.
Se inicia implícitamente una nueva transacción
cuando se ha completado la anterior, pero cada
transacción se completa explícitamente con una
instrucción COMMIT o ROLLBACK.
 Transacciones 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.

8.  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.
 Puntos de recuperacion (SavePoint).
Los puntos de recuperación (SavePoints) permiten
manejar las transacciones por pasos, pudiendo hacer
rollbacks hasta un punto marcado por el savepoint y no por
toda la transacción.
 Transacciones anidadas.
Podemos anidar varias transacciones. Cuando anidamos
varias transacciones la instrucción COMMIT afectará a la
última transacción abierta, pero ROLLBACK afectará a
todas las transacciones abiertas.

9.  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.
Cada transacción dura hasta que se completa sin errores y se emite COMMIT
TRANSACTION para hacer que las modificaciones sean una parte permanente
de la base de datos, o hasta que se produzcan errores y se borren todas las
modificaciones con la instrucción ROLLBACK TRANSACTION.
SINTAXIS
--Applies to SQL Server and Azure SQL Database BEGIN { TRAN |
TRANSACTION } [ { transaction_name | @tran_name_variable } [ WITH MARK [
'description' ] ] ] [ ; ]

10.  ROLLBACK TRANSACTION
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.
Una transacción no se puede revertir después de ejecutar una
instrucción COMMIT TRANSACTION, excepto cuando COMMIT
TRANSACTION está asociada a una transacción anidada
incluida en la transacción que se revierte. En esta instancia, la
transacción anidada se revierte, incluso si ha emitido una
instrucción COMMIT TRANSACTION para ella.
SINTAXIS
ROLLBACK { TRAN | TRANSACTION }
[ transaction_name | @tran_name_variable
| savepoint_name | @savepoint_variable ]
[ ; ]

11.  COMMIT TRANSACTION
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.
Si la transacción que se ha confirmado era una transacción Transact-SQL
distribuida, COMMIT TRANSACTION hace que MS DTC utilice el protocolo de
confirmación en dos fases para confirmar los servidores involucrados en la
transacción.
Si una transacción local afecta a dos o más bases de datos de la misma instancia
del Motor de base de datos, la instancia utiliza una confirmación interna en dos
fases para confirmar todas las bases de datos involucradas en la transacción.
SINTAXIS
Database COMMIT [ { TRAN | TRANSACTION } [ transaction_name |
@tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ] [ ; ]

12. USE AdventureWorks2012;
GO
IF OBJECT_ID(N'TestTran',N'U') IS NOT NULL
DROP TABLE TestTran;
GO
CREATE TABLE TestTran (Cola int PRIMARY
KEY, Colb char(3));
GO
-- This statement sets @@TRANCOUNT to 1.
BEGIN TRANSACTION OuterTran;
GO
PRINT N'Transaction count after BEGIN OuterTran
= '
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO
INSERT INTO TestTran VALUES (1, 'aaa');
GO
-- This statement sets @@TRANCOUNT to 2.
BEGIN TRANSACTION Inner1;
GO
PRINT N'Transaction count after BEGIN Inner1 = '
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO
INSERT INTO TestTran VALUES (2, 'bbb');
GO
-- This statement sets @@TRANCOUNT to 3.
BEGIN TRANSACTION Inner2;
GO
PRINT N'Transaction count after BEGIN Inner2 = '
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO
INSERT INTO TestTran VALUES (3, 'ccc');
GO
-- This statement decrements @@TRANCOUNT to 2.
-- Nothing is committed.
COMMIT TRANSACTION Inner2;
GO
PRINT N'Transaction count after COMMIT Inner2 = '
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO
-- This statement decrements @@TRANCOUNT to 1.
-- Nothing is committed.
COMMIT TRANSACTION Inner1;
GO
PRINT N'Transaction count after COMMIT Inner1 = '
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO
-- This statement decrements @@TRANCOUNT to 0
and
-- commits outer transaction OuterTran.
COMMIT TRANSACTION OuterTran;
GO
PRINT N'Transaction count after COMMIT OuterTran =
'
+ CAST(@@TRANCOUNT AS nvarchar(10));
GO

13.  De lo aprendido se puede concluir que, si en una transacción
una operación falla, en todo el bloque de instrucciones que
comprende las demás también fallarán.
 Concluimos también que toda transacción debe ajustarse a las
reglas de atomicidad, coherencia, aislamiento y durabilidad.
 Este tipo de transacciones no requieren de nuestra
intervención puesto que el sistema se encarga de todo.
 Sin embargo, si hay que realizar varias operaciones y
queremos que sean tratadas como una unidad tenemos que
crear esas transacciones de manera explícita.

14.  Aprender el uso de transacciones es importante
para poder asegurar integridad de una operación.
 Las transacciones deben durar lo mínimo posible
para evitar bloqueos que terminen en problemas
de performance.