DBMS - Transacción

Una transacción se puede definir como un grupo de tareas. Una sola tarea es la unidad mínima de procesamiento que no se puede dividir más.

Tomemos un ejemplo de una transacción simple. Suponga que un empleado del banco transfiere 500 rupias de la cuenta de A a la cuenta de B. Esta transacción muy simple y pequeña implica varias tareas de bajo nivel.

A’s Account

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Propiedades ACID

Una transacción es una unidad muy pequeña de un programa y puede contener varias tareas de bajo nivel. Una transacción en un sistema de base de datos debe mantenerAtomicidad Ccoherencia Isolación, y Ddurabilidad, comúnmente conocida como propiedades ACID, para garantizar la precisión, la integridad y la integridad de los datos.

  • Atomicity- Esta propiedad establece que una transacción debe tratarse como una unidad atómica, es decir, se ejecutan todas sus operaciones o ninguna. No debe haber ningún estado en una base de datos donde una transacción se deja parcialmente completada. Los estados deben definirse antes de la ejecución de la transacción o después de la ejecución / aborto / falla de la transacción.

  • Consistency- La base de datos debe permanecer en un estado consistente después de cualquier transacción. Ninguna transacción debería tener un efecto adverso sobre los datos que residen en la base de datos. Si la base de datos estaba en un estado consistente antes de la ejecución de una transacción, también debe permanecer consistente después de la ejecución de la transacción.

  • Durability- La base de datos debe ser lo suficientemente duradera como para contener todas sus últimas actualizaciones, incluso si el sistema falla o se reinicia. Si una transacción actualiza una parte de los datos en una base de datos y se confirma, entonces la base de datos contendrá los datos modificados. Si una transacción se confirma pero el sistema falla antes de que los datos se puedan escribir en el disco, entonces esos datos se actualizarán una vez que el sistema vuelva a la acción.

  • Isolation- En un sistema de base de datos donde se está ejecutando más de una transacción simultáneamente y en paralelo, la propiedad de aislamiento establece que todas las transacciones se realizarán y ejecutarán como si fuera la única transacción en el sistema. Ninguna transacción afectará la existencia de cualquier otra transacción.

Serializabilidad

Cuando el sistema operativo ejecuta múltiples transacciones en un entorno de multiprogramación, existen posibilidades de que las instrucciones de una transacción se intercalen con alguna otra transacción.

  • Schedule- Una secuencia de ejecución cronológica de una transacción se denomina programación. Una programación puede tener muchas transacciones, cada una de las cuales consta de una serie de instrucciones / tareas.

  • Serial Schedule- Es un cronograma en el que las transacciones se alinean de tal manera que una transacción se ejecuta primero. Cuando la primera transacción completa su ciclo, se ejecuta la siguiente. Las transacciones se ordenan una tras otra. Este tipo de programación se denomina programación en serie, ya que las transacciones se ejecutan en serie.

En un entorno de transacciones múltiples, los programas en serie se consideran un punto de referencia. La secuencia de ejecución de una instrucción en una transacción no se puede cambiar, pero dos transacciones pueden tener sus instrucciones ejecutadas de forma aleatoria. Esta ejecución no daña si dos transacciones son mutuamente independientes y funcionan en diferentes segmentos de datos; pero en caso de que estas dos transacciones estén trabajando con los mismos datos, los resultados pueden variar. Este resultado siempre variable puede llevar la base de datos a un estado inconsistente.

Para resolver este problema, permitimos la ejecución paralela de un programa de transacciones, si sus transacciones son serializables o tienen alguna relación de equivalencia entre ellas.

Horarios de equivalencia

Un esquema de equivalencia puede ser de los siguientes tipos:

Equivalencia de resultados

Si dos programas producen el mismo resultado después de la ejecución, se dice que son resultados equivalentes. Pueden producir el mismo resultado para algún valor y resultados diferentes para otro conjunto de valores. Es por eso que esta equivalencia generalmente no se considera significativa.

Ver equivalencia

Dos programas se verían en equivalencia si las transacciones en ambos programas realizan acciones similares de manera similar.

Por ejemplo

  • Si T lee los datos iniciales en S1, entonces también lee los datos iniciales en S2.

  • Si T lee el valor escrito por J en S1, entonces también lee el valor escrito por J en S2.

  • Si T realiza la escritura final en el valor de datos en S1, entonces también realiza la escritura final en el valor de datos en S2.

Equivalencia de conflicto

Dos programas estarían en conflicto si tuvieran las siguientes propiedades:

  • Ambos pertenecen a transacciones independientes.
  • Ambos acceden al mismo elemento de datos.
  • Al menos uno de ellos es la operación de "escritura".

Se dice que dos programas que tienen múltiples transacciones con operaciones en conflicto son equivalentes en conflicto si y solo si:

  • Ambos programas contienen el mismo conjunto de transacciones.
  • El orden de los pares de operaciones en conflicto se mantiene en ambos programas.

Note- Ver programas equivalentes se pueden ver en serie y los programas equivalentes en conflicto se pueden serializar en conflicto. Todas las programaciones serializables en conflicto también se pueden ver en serialización.

Estados de transacciones

Una transacción en una base de datos puede estar en uno de los siguientes estados:

  • Active- En este estado, la transacción se está ejecutando. Este es el estado inicial de cada transacción.

  • Partially Committed - Cuando una transacción ejecuta su operación final, se dice que está en un estado parcialmente comprometido.

  • Failed- Se dice que una transacción está en un estado fallido si falla alguna de las comprobaciones realizadas por el sistema de recuperación de la base de datos. Una transacción fallida ya no puede continuar.

  • Aborted- Si alguna de las comprobaciones falla y la transacción ha alcanzado un estado fallido, el administrador de recuperación revierte todas sus operaciones de escritura en la base de datos para que la base de datos vuelva a su estado original donde estaba antes de la ejecución de la transacción. Las transacciones en este estado se denominan abortadas. El módulo de recuperación de la base de datos puede seleccionar una de las dos operaciones después de que se anula una transacción:

    • Reiniciar la transacción
    • Mata la transacción

  • Committed- Si una transacción ejecuta todas sus operaciones con éxito, se dice que está comprometida. Todos sus efectos ahora se establecen permanentemente en el sistema de base de datos.