Transacciones Sqp

Elabora 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.

Por ejemplo, considere 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 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.

En PostgreSQL, una transacción se indica encerrando las órdenes SQL de la transacción entre las órdenes BEGIN y COMMIT. Entonces la transacción bancaria del ejemplo de arriba se vería así:

BEGIN;

UPDATE cuentas SET balance = balance - 100.00 WHERE nombre = 'Alicia';

-- etc etc

COMMIT;

Si en medio de una transacción se decide que ya no se quiere registrar los cambios (tal vez el balance de Alicia se volvió negativo en algún momento, por ejemplo), se puede recurrir a la orden ROLLBACKen lugar de COMMIT y todas las actualizaciones hasta ese punto quedarían canceladas.

De hecho, PostgreSQL trata cada declaración de SQL como si se estuviera ejecutando dentro de una transacción. Si uno no especifica una orden BEGIN, entonces cada declaración individual tiene unBEGIN y, si es exitosa, un COMMIT alrededor de ella. Algunas veces, a un grupo de declaraciones encerradas entre BEGIN y COMMIT se les llama un bloque de transacción.

Nota

BEGIN y COMMIT automáticos.

Algunas bibliotecas cliente usan las órdenes BEGIN y COMMIT automáticamente, de tal forma que uno obtiene el efecto de bloques de transacción sin pedirlos. Revise la documentación de la interfaz que esté usando.

Es posible controlar las declaraciones en una transacción de una manera más granular por medio de puntos de recuperación (savepoints). Los puntos de recuperación permiten descartar selectivamente algunas partes de la transacción mientras las demás sí se ejecutan. Después de definir un punto de recuperación con SAVEPOINT, se puede volver a él si es necesario por medio deROLLBACK TO. Todos los cambios de la base de datos hechos por la transacción entre el punto de recuperación y el rollback se descartan, pero los cambios hechos antes del punto de recuperación se mantienen.

Después de volver a un punto de recuperación, este último sigue definido, o sea que se puede volver a él varias veces. Y al contrario, si uno está seguro de que no necesita volver a un punto de recuperación particular otra vez, entonces puede liberarlo para que el sistema ahorre algunos recursos. Tenga en cuenta que tanto liberar un punto de recuperación como volver a él liberará automáticamente todos los puntos de recuperación definidos después de él.

Todo esto sucede dentro del bloque de transacción, por lo tanto nada es visible para otras sesiones de la base de datos. Cuando se ejecuta el bloque de transacción, las acciones ejecutadas se hacen visibles como una unidad para otras sesiones, mientras que las acciones de rollback nunca se hacen visibles.

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

...