5.1.

Conceptos bsicos
Desde el punto de vista del usuario la interaccin con la base de datos se lleva a cabo mediante operaciones con significado en el modelo semntico (por
ejemplo, una transferencia de fondos en un banco).
Desde el punto de vista de la base de datos estas operaciones pueden estar formadas por varias operaciones elementales (por ejemplo, quitar fondos de
una cuenta y aadrselos a otra)
Se llama Transaccin a una coleccin de operaciones que forman una unidad lgica de trabajo en una BD realizada por una o ms sentencias SQL
estrechamente relacionadas.
Una transaccin es una unidad de la ejecucin de un programa que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias operaciones de
acceso a la base de datos. Una Transaccin est delimitada por instrucciones de inicio transaccin y fin transaccin (la transaccin consiste en todas las
operaciones que se ejecutan entre inicio transaccin y fin transaccin).
El concepto de transaccin se desarroll para atender los casos en los que el estado resultante de la base de datos depende del xito completo en una serie
de operaciones. Este concepto vio la luz debido a que varias operaciones sucesivas pueden modificar el resultado de operaciones anteriores. En esos casos,
si alguna operacin produce un error, el estado resultante puede ser indeterminado.
Para solucionar este problema, las transacciones agrupan una serie de operaciones de manera que es posible garantizar la integridad del resultado final. O
todas las operaciones se ejecutan con xito y se confirman (se escriben en la base de datos), o toda la transaccin se considera no realizada. La accin de
cancelar una transaccin se denomina deshacer la transaccin. Deshacer una transaccin permite anular los cambios y recuperar el estado de la base de
datos previo a la transaccin.
Por ejemplo, en una transaccin bancaria automatizada, si un banco transfiere dinero desde la cuenta A a la cuenta B, la retirada de fondos de A y el
depsito en B deben producirse con xito para procesar los fondos correctamente, de lo contrario la transaccin entera debe cancelarse.
Esquematizando el proceso de transacciones tenemos: O se ejecutan todas las operaciones que componen la transaccin, o no se realiza ninguna.

Propiedades de la Transaccin
Una
unidad
lgica
de
trabajo
debe
exhibir
cuatro
propiedades,
propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificacada como transaccin.

conocidas

como

Atomicity: Una Transaccin (Tx) se ejecuta completamente de otra manera se eliminan los cambios parciales realizados.

Begin Transaction - Programa - End Transaction

Responsable: El mtodo de recuperacin, de no completar todas las operaciones, devuelve la BD a su estado anterior a empezar esa Tx
rollback).

Coherencia: Asegura que los datos que observamos no cambian (por otros usuarios) hasta que acabemos la Transaccin.

Despus de terminar una Transaccin la Base de datos no viola ninguna de sus reglas: valores obligatorios, claves nicas,etc.

Responsable: los programadores mediante la definicin adecuada de la integridad referencial: check, triggers, primary
key,foreign key,

Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen.

Una Transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.
Ms aun, si varias transacciones, se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado
secuencialmente. Esto se conoce como seriabilidad debido a que su resultado es la capacidad de volver a cargar los datos iniciales y reproducir
una serie de transacciones para finalizar con los datos en el mismo estado en que estaban despus de realizar transacciones originales.d
Responsable: el mtodo de concurrencia: mecanismos, reglas, protocolos

Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas.

Responsable: el mtodo o gestor de recuperacin.

Control de transacciones en Oracle

Inicio de transaccin
Cuando no hay ya una transaccin en progreso, y se ejecuta una sentencia LDD o LMD(interactivamente o dentro de una aplicacin)
Cada sentencia LDD es tratada como una transaccin N
No existe sentencia de tipo BEGIN TRANSACTION

Fin de transaccin
COMMIT:Finaliza la transaccin actual y hace permanentes (confirma) los cambios realizados
ROLLBACK:Finaliza la transaccin actual y deshace los cambios realizados

Sentencia COMMIT
Una sentencia COMMIT marca el final de una transaccin correcta, implcita o definida por el usuario. COMMIT hace que todas las
modificaciones efectuadas sobre los datos desde el inicio de la transaccin sean parte permanente de la base de datos, y adems, libera los
recursos mantenidos por la conexin. Su sintaxis es la siguiente:
COMMIT COMMENT 'mensaje' | FORCE 'texto']
COMMENT sirve para comentar la transaccin en un mximo 255 caracteres. FORCE fuera de modo manual una transaccin dudosa y es de
uso exclusivo en sistemas distribuidos de base de datos.

Sentencia SAVEPOINT
1

Esta sentencia permite crear un punto de restauracin dentro de una transaccin, es decir, un punto al que podremos retroceder deshaciendo
todo lo hecho deshaciendo todo lo hecho desde l en adelante. Su sintaxis es la siguiente
SAVEPOINT nombrePuntoRestauracin;

Sentencia ROLLBACK
Seala el final sin xito de una transaccin, elimina todas las modificaciones de datos realizadas desde el inicio de la transaccin y tambin
libera los recursos que retiene la transaccin. Su sintaxis es la siguiente:
ROLLBACK [WORK] [TO SAVEPOINT nombrePuntoRestauracin | FORCE 'texto'];

Grados de consistencia
Consistencia es un trmino ms amplio que el de integridad. Podra definirse como la coherencia entre todos los datos de la base de datos.
Cuando se pierde la integridad tambin se pierde la consistencia. Pero la consistencia tambin puede perderse por razones de funcionamiento.
Una transaccin finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia).

Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

Si se anula los cambios que ha efectuado son deshechos.

La ejecucin de una transaccin debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de
integridad definidas).

Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

Si se anula los cambios que ha efectuado son deshechos.

Una transaccin que termina con xito se dice que est comprometida (commited), una transaccin que haya sido comprometida llevar a la
base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transaccin
slo puede estar en uno de los siguientes estados.

Activa (Active): el estado inicial; la transaccin permanece en este estado durante su ejecucin.

Parcialmente comprometida (Uncommited): Despus de ejecutarse la ltima transaccin.

Fallida (Failed): tras descubrir que no se puede continuar la ejecucin normal.

Abortada (Rolled Back): despus de haber retrocedido la transaccin y restablecido la base de datos a su estado anterior al comienzo de la
transaccin.

Comprometida (Commited): tras completarse con xito.

Aspectos relacionados al procesamiento de transacciones

Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones:

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.

Consistencia de la base de datos interna. Los algoritmos de control de datos semntico tienen que satisfacer siempre las restricciones de
integridad cuando una transaccin pretende hacer un commit.

Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de
una red para garantizar la atomicidad y durabilidad de las transacciones. As tambin, se requieren protocolos para la recuperacin local y
para efectuar los compromisos (commit) globales.

Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecucin de transacciones
concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.

Protocolos de control de rplicas. El control de rplicas se refiere a cmo garantizar la consistencia mutua de datos replicados. Por ejemplo
se puede seguir la estrategia read-one-write-all (ROWA).

Niveles de aislamiento
Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transaccin de las modificaciones de
recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la
simultaneidad que se permiten, como las lecturas desfasadas o ficticias.

Control de los niveles de aislamiento de transaccin:

Controla si se 11realizan bloqueos cuando se leen los datos y qu tipos de bloqueos se solicitan.

Duracin de los bloqueos de lectura.

Si una operacin de lectura que hace referencia a filas modificadas por otra transaccin:
o

Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

Recupera la versin confirmada de la fila que exista en el momento en el que empez la instruccin o la transaccin.

Lee la modificacin de los datos no confirmados.

El nivel de aislamiento para una sesin SQL establece el comportamiento de los bloqueos para las instrucciones SQL.
El estndar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en funcin de tres eventos que son permitidos o no dependiendo
del nivel de aislamiento. Estos eventos son:
Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podra usarse una versin anterior de un registro. Por lo
tanto, las lecturasno son consistentes al usar este nivel de aislamiento.

Lectura norepetible. Una transaccin vuelve a leer datos que previamente haba ledo y encuentra que han sido modificados o eliminados
por una transaccin cursada.

Lectura fantasma. Una transaccin vuelve a ejecutar una consulta, devolviendo un conjuto de registros que satisfacen una condicin de
bsqueda y encuentra que otros registro que satisfacen la condicin han sido insertadas por otra transaccin cursada.

Los niveles de aislamiento SQL son definidos basados en si ellos permiten a cada uno de los eventos definidos anteriormente. Es interesante
notar que el estndar SQL no impone un esquema de cierre especfico o confiere por mandato comportamientos particulares, pero ms bien
describe estos niveles de aislamiento en trminos de estos teniendo muchos mecanismos de cierre/coincidencia, que dependen del evento de
lectura.

Segn el estndar SQL 1992, SQL Server y MySQL permiten todos estos niveles, Oracle slo permite la lectura comprometida y secuenciable.
Los niveles se pueden establecer en ambos para cada transaccin. Sin embargo esto no es necesariamente cierto.
El estndar SQL trataba de establecer los niveles de aislamiento que permitiran a varios grados de consistencia para querys ejecutadas en
cada nivel de aislamiento. Las lecturas repetibles "REPEATABLE READ" es el nivel de aislamiento que garantiza que un query un resultado
consistente.
En la definicin SQL estndar, la lectura comprometida "READ COMMITTED" no regresa resultados consistentes, en la lectura no
comprometida "READ UNCOMMITTED" las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podra usarse una versin anterior
de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.
A mayor grado de aislamiento, mayor precisin, pero a costa de menor concurrencia.

COMMIT Y ROLLBACK
Ejemplo bsico en MySQL precio del dolar con respecto al peso 1995 al 2012.
?

CREATE TABLE IF NOT EXISTS dolar (

fecha DATE,

precio DECIMAL (8,4),

PRIMARY KEY (fecha)

) ENGINE = InnoDB DEFAULT CHARSET=latin1;

Considere la siguiente informacin

Fecha
2012/02/01
2012/02/02
2012/02/03
2012/02/07
2012/02/08
2012/02/09
2012/02/10

Lecturas consistentes
Por default, las tablas InnoDB ejecutan un lectura consistente (consistent read). Esto significa que cuando una sentencia SELECT es
ejecutada, MySQL regresa los valores presentes en la base de datos hasta la transaccin ms reciente que ha sido completada.

Si alguna transaccin est en progreso, los cambios hechos por alguna sentencia DELETE, INSERT o UPDATE no sern reflejados. Sin
embargo, existe una excepcin: las transacciones abiertas si pueden ver sus propios cambios. Para demostrar esto, necesitamos establecer dos
conexiones al servidor MySQL.
Observe el caso feliz de las transacciones. Sin violaciones de integridad referencial o otra clase de errores

Clie
?
1

SET AUTOCOMMIT = 0

INSERT INTO dolar VALUES('2012-02-01', 13.0077);

INSERT INTO dolar VALUES('2012-02-02', 12.8900);

INSERT INTO dolar VALUES('2012-02-03', 12.8038);

SELECT * FROM dolar WHERE fecha >= '2012/02/01';

COMMIT;

Por defecto, MySQL se ejecuta con el modo autocommit activado. Esto significa que en cuanto ejecute un comando que actualice (modifique)
una tabla, MySQL almacena la actualizacin en disco.
Si usa tablas transaccionales (como InnoDB o BDB), puede desactivar el modo autocommit con el siguiente comando: SET AUTOCOMMIT = 0;
Tras deshabilitar el modo autocommit poniendo la variable AUTOCOMMIT a cero, debe usar COMMIT para almacenar los cambios en disco
o ROLLBACK si quiere ignorar los cambios hechos desde el comienzo de la transaccin.

START TRANSACTION
El siguiente cdigo crea una tabla InnoDB de nombre resumen;
?
1

CREATE TABLE resumen (

year

mes

promedio DECIMAL(8,4),

PRIMARY KEY (year, mes)

INTEGER,
INTEGER,

)engine = innodb;

Clie
?
1

START TRANSACTION;

SELECT @prom:= AVG(precio) FROM dolar

WHERE YEAR(fecha) = 2011 AND MONTH(fecha) = 1;

INSERT INTO resumen VALUES (2011, 1, @prom);

SELECT * FROM resumen;

Clie

?
1

SELECT * FROM resumen;

COMMIT;

?
1

SELECT * FROM resumen;

Clie

Programacin de transacciones
Tipos de transacciones: implcitas (modo de autocompromiso) y explcitas (delimitadas).
El ejemplo clsico de transaccin es una transferencia bancaria, en la que quitamos saldo a una cuenta y lo aadimos en otra. Si no somo
capaces de abonar el dinero en la cuenta de destino, no debemos quitarlo de la cuenta de origen.
SQL Server funciona por defecto con Transacciones de confirmacin automtica , es decir, cada instruccin individual es una transaccin y se
confirma automticamente.

Transaccin implicita
?
1

SET IMPLICIT_TRANSACTIONS ON

2
3
4

DECLARE @importe DECIMAL(18,2),

@CuentaOrigen VARCHAR(12),

@CuentaDestino VARCHAR(12)

7
8
9

/* Asignamos el importe de la transferencia

10

* y las cuentas de origen y destino

11

*/

12
13
14
15
16

SET @importe = 50
SET @CuentaOrigen = '200700000002'
SET @CuentaDestino = '200700000001'

BEGIN TRY

17
18

/* Descontamos el importe de la cuenta origen */

19
20
21
22

UPDATE CUENTAS
SET SALDO = SALDO - @importe
WHERE NUMCUENTA = @CuentaOrigen

23
24
25

/* Registramos el movimiento */

26
27

INSERT INTO MOVIMIENTOS

28

(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR,

29

IMPORTE, FXMOVIMIENTO)

30
31
32
33
34

SELECT
IDCUENTA, SALDO + @importe, SALDO, @importe, getdate()
FROM CUENTAS
WHERE NUMCUENTA = @CuentaOrigen

35
36
37
38
39
40

/* Incrementamos el importe de la cuenta destino */

UPDATE CUENTAS
SET SALDO = SALDO + @importe
WHERE NUMCUENTA = @CuentaDestino

41
42

/* Registramos el movimiento */

43
44
45
46

INSERT INTO MOVIMIENTOS

(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR,
IMPORTE, FXMOVIMIENTO)

47
48
49
50

SELECT
IDCUENTA, SALDO - @importe, SALDO, @importe, getdate()

51

FROM CUENTAS

52

WHERE NUMCUENTA = @CuentaDestino

53
54

/* Confirmamos la transaccion*/

55
56

COMMIT TRANSACTION -- O solo COMMIT

57

END TRY

58

BEGIN CATCH

59
60

/* Hay un error, deshacemos los cambios*/

61
62
63

ROLLBACK TRANSACTION -- O solo ROLLBACK

PRINT 'Se ha producido un error!'

64
65
66

END CATCH

Transacciones explcitas
Cada transaccin se inicia explcitamente con la instruccin BEGIN TRANSACTION y se termina explcitamente con una instruccin COMMIT o
ROLLBACK.

?
1

DECLARE @importe DECIMAL(18,2),

2
3

@CuentaOrigen VARCHAR(12),

4
5

@CuentaDestino VARCHAR(12)

6
7
8
9

/* Asignamos el importe de la transferencia

10
11

* y las cuentas de origen y destino

12
13

*/

14
15

SET @importe = 50

16
17

SET @CuentaOrigen = '200700000002'

18
19

SET @CuentaDestino = '200700000001'

20
21
22
23

BEGIN TRANSACTION -- O solo BEGIN TRAN

24
25
26

BEGIN TRY

27

/* Descontamos el importe de la cuenta origen */

28
29

UPDATE CUENTAS

30
31

SET SALDO = SALDO - @importe

32
33

WHERE NUMCUENTA = @CuentaOrigen

34
35
36

/* Registramos el movimiento */

37
38

INSERT INTO MOVIMIENTOS

39
40
41

(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR,

IMPORTE, FXMOVIMIENTO)

42
SELECT

43
44
45
46
47

IDCUENTA, SALDO + @importe, SALDO, @importe, getdate()

FROM CUENTAS
WHERE NUMCUENTA = @CuentaOrigen

48
49

/* Incrementamos el importe de la cuenta destino */

50
51

UPDATE CUENTAS

52

SET SALDO = SALDO + @importe

53

WHERE NUMCUENTA = @CuentaDestino

54
55
56

/* Registramos el movimiento */

57
58
59
60

INSERT INTO MOVIMIENTOS

(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR,
IMPORTE, FXMOVIMIENTO)

61
SELECT

62
63
64

IDCUENTA, SALDO - @importe, SALDO, @importe, getdate()

FROM CUENTAS
WHERE NUMCUENTA = @CuentaDestino

65
66
67
68

/* Confirmamos la transaccion*/

69
70

COMMIT TRANSACTION -- O solo COMMIT

71
72
73

END TRY

74
75
76
77
78

BEGIN CATCH
/* Hay un error, deshacemos los cambios*/
ROLLBACK TRANSACTION -- O solo ROLLBACK
PRINT 'Se ha producido un error!'
END CATCH

79

Ejemplo (SQL Server)

:

Considere las siguientes tablas en sintaxis SQL SERVER 2000

Incremento de un 1% de las comisiones 15% y 16% de la tabla de comisiones roysched. Si no existen estos porcentajes entonces no se
ejecutar la instruccin de actualizacin. En este ejemplo se deben incrementar ambos; si uno de ellos no existe, se debe dejar sin modificar.
BEGIN TRAN actualiza_comisiones -- Inicio de la transaccin.

?
1

USE pubs

2
3
4
5
6

IF EXISTS (SELECT titles.title, roysched.royalty

FROM titles, roysched
WHERE titles.title_id=roysched.title_id
AND roysched.royalty=16)
UPDATE roysched SET royalty=17 WHERE royalty=16

ELSE

ROLLBACK TRAN actualiza_comisiones

IF EXISTS (SELECT titles.title, roysched.royalty

10

FROM titles, roysched

11

WHERE titles.title_id=roysched.title_id

12

AND roysched.royalty=15)

13

BEGIN

14

UPDATE roysched SET royalty=16 WHERE royalty=15

15
16
17
18

COMMIT TRAN actualiza_comisiones

END
ELSE
ROLLBACK TRAN actualiza_comisiones