UNIVERSIDAD PRIVADA TELESUP

TRANSACCIONESElabora dos ejemplos de transacciones en un sistema de base de datos. Elabora un esquema de cada una de los ejemplos realizados. Envía ambos archivos a través de este medio.

Las transacciones son un concepto fundamental de todos los sistemas de bases de datos. El punto esencial de una transacción es su capacidad para empaquetar varios pasos en una sola operación “todo o nada”. Los estados intermedios entre los pasos no son visibles para otras transacciones concurrentes, y si ocurre alguna falla que impida que se complete la transacción, entonces ninguno de los pasos se ejecuta y no se afecta la base de datos en absoluto. Las transacciones son un concepto fundamental de todos los sistemas de bases de datos. El punto esencial de una transacción es su capacidad para empaquetar varios pasos en una sola operación “todo o nada”. Los estados intermedios entre los pasos no son visibles para otras transacciones concurrentes, y si ocurre alguna falla que impida que se complete la transacción, entonces ninguno de los pasos se ejecuta y no se afecta la base de datos en absoluto.

EJEMPLO 1Considere una base de datos bancaria que contiene balances de varias cuentas de clientes y balances totales de depósito de sucursales. Suponga que queremos registrar un pago de $100 de la cuenta de Alicia a la de Roberto. Simplificando la operación exageradamente, las órdenes SQL para hacerlo se verían así:UPDATE cuentas SET balance = balance - 100.00 WHERE nombre = 'Alicia';UPDATE sucursales SET balance = balance - 100.00 WHERE nombre = (SELECT sucursal FROM cuentas WHERE nombre = 'Alicia');UPDATE cuentas SET balance = balance + 100.00 WHERE nombre = 'Roberto';UPDATE sucursales SET balance = balance + 100.00 WHERE nombre = (SELECT sucursal FROM cuentas WHERE nombre = 'Roberto');Los detalles de estas órdenes no son importantes en este momento; lo que importa es que hay varias actualizaciones separadas involucradas para lograr esta operación más o menos sencilla. Los operadores bancarios van a querer estar seguros de que o todos estos pasos se ejecutan o no se ejecuta ninguno. Definitivamente no sería aceptable si una falla del sistema resulta en que Roberto recibe $100 que no fueron debitados de la cuenta de Alicia. Tampoco si a Alicia le debitaran y a Roberto no le abonaran. Se necesita una garantía de que si algo sale mal en el transcurso de la operación, ninguno de los pasos ejecutados hasta el momento tendrán efecto. Para el ejemplo anterior, agrupar las actualizaciones en una transacción proporciona esa garantía. De las transacciones se dice que son atómicas: desde el punto de vista de otras transacciones, la transacción ocurre completamente o no ocurre en absoluto.También es necesario garantizar que, después que se complete una transacción y que el sistema de bases de datos tenga completo conocimiento de ella, realmente el registro haya sido permanente y que este no se perderá, incluso si llega a suceder una falla poco tiempo después. Por ejemplo, si se estuviera registrando un retiro de Roberto, no sería aceptable que el débito de su cuenta desapareciera en una falla del sistema justo después de que él sale del banco. Una base de datos transaccional garantiza que todas las actualizaciones realizadas por una transacción se grabarán en un medio de almacenamiento permanente (en disco, por ejemplo) antes de que la transacción se reporte completamente.Otra propiedad importante de las bases de datos transaccionales se relaciona con la noción de las actualizaciones atómicas: cuando hay muchas transacciones concurrentes, ninguna de ellas debería conocer los cambios incompletos hechos por las demás. Por ejemplo, si alguna transacción está ocupada totalizando todos los balances de una sucursal, no serviría que incluyera el débito de la sucursal de Alicia pero no el crédito a la sucursal de Roberto, ni viceversa. Así que las transacciones deben ser todo o nada, no solamente en términos de su efecto permanente en la base de datos, sino también en términos de su visibilidad a medida que suceden. Las actualizaciones hechas hasta cierto momento por una

ADMINISTRACIÓN DE BASE DE DATOS

UNIVERSIDAD PRIVADA TELESUP

transacción abierta son invisibles para las demás transacciones hasta que la transacción se complete. A partir de su finalización, todas las actualizaciones se hacen visibles simultáneamente.Retomando el ejemplo de la base de datos bancaria, suponga que se debitan $100 de la cuenta de Alicia y se abonan a la cuenta de Roberto, pero que después resulta que se debió abonar a la cuenta de Walter. Esto se podría hacer usando un punto de recuperación:BEGIN;UPDATE cuentas SET balance = balance - 100.00 WHERE nombre = 'Alicia';SAVEPOINT mi_savepoint;UPDATE cuentas SET balance = balance + 100.00 WHERE nombre = 'Roberto';-- Uy ... no era la cuenta de Roberto sino la de WalterROLLBACK TO mi_savepoint;UPDATE cuentas SET balance = balance + 100.00 WHERE nombre = 'Walter';COMMIT;Este ejemplo, claro, está sobre simplificado, pero existe mucha posibilidad de control en un bloque de transacción por medio de los puntos de recuperación. Es más, ROLLBACK TO es la única manera de retomar el control de un bloque de transacción puesto en estado de aborto por el sistema debido a un error, devolverlo completamente y reiniciarlo.

EJEMPLO 2 Creamos dos tablas: “producto” y “producto externo”

Tabla producto Tabla producto_externoCREATE TABLE producto(codigo INT NOT NULL DEFAULT 0,nombre VARCHAR(100),cantidad INT DEFAULT NULL,PRIMARY KEY (codigo)) ENGINE=INNODB;

CREATE TABLE producto_externo(codigo INT NOT NULL DEFAULT 0,nombre VARCHAR(100),cantidad INT DEFAULT NULL,PRIMARY KEY (codigo)) ENGINE=INNODB; Aquí con datos ya agregados.

Se nos pide mediante una transacción insertar datos desde la tabla producto externo a la tabla producto. Código:

Bien para ello tenemos el siguiente resultado en la tabla producto.

ADMINISTRACIÓN DE BASE DE DATOS

UNIVERSIDAD PRIVADA TELESUP

Recordar si sucede algún error sencillamente escribimos ROLLBACK; y desacera lo que hicimos.Bien ahora si todo está bien debemos escribir COMMIT; para guardar los cambios en la base de datos, pero si queremos volver a deshacer los cambios con ROLLBACK, ya no se podrá. EJEMPLO 3Continuando el ejemplo anterior esta vez realizaremos uno de actualizar la tabla producto, le sumaremos a la columna cantidad. Usamos transacciones.

Obtenemos el siguiente resultado:

Tal como está en código se ha sumado, la columna cantidad de la tabla producto externo, a la tabla producto de la columna cantidad. Y por ello suma 150 + 300 = 450.Supongamos que nos equivocamos de fila, no era la 1, si no 2, de la tabla producto, para ello realizamos lo siguiente:START TRANSACTION;SELECT @A:=cantidad, @B:=nombre FROM producto_externo WHERE codigo=2;INSERT INTO producto (codigo, nombre, cantidad) VALUES (1, @B, @A);ROLLBACK;UPDATE producto SET cantidad=cantidad+@A WHERE codigo=2;COMMIT;

El resultado sería el siguiente:

En la fila 2 en cantidad tenía 100 y se le ha sumado 300 de la tabla producto externo.

ADMINISTRACIÓN DE BASE DE DATOS