DBMS - Transacción - Tutorialspoint

Anuncios

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

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

Cuenta de A

Open_Account(A)Old_Balance = A.balanceNew_Balance = Old_Balance - 500A.balance = New_BalanceClose_Account(A)

Cuenta de B

Open_Account(B)Old_Balance = B.balanceNew_Balance = Old_Balance + 500B.balance = New_BalanceClose_Account(B)

Propiedades deACID

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 mantener Atomicidad, Consistencia, Aislamiento y Durabilidad -conocidas comúnmente como propiedades ACID- con el fin de asegurar la precisión, la completitud y la integridad de los datos.

Atomicidad – Esta propiedad establece que una transacción debe ser tratada como una unidad atómica, es decir, o se ejecutan todas sus operaciones o ninguna. No debe haber ningún estado en una base de datos en el que una transacción quede parcialmente completada. Los estados deben ser definidos antes de la ejecución de la transacción o después de la ejecución/aborto/fracaso de la transacción.
Consistencia – La base de datos debe permanecer en un estado consistente después de cualquier transacción. Ninguna transacción debe tener ningún efecto adverso en 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, debe seguir siendo consistente también después de la ejecución de la transacción.
Durabilidad – La base de datos debe ser lo suficientemente duradera como para mantener todas sus últimas actualizaciones incluso si el sistema falla o se reinicia. Si una transacción actualiza un trozo de datos en una base de datos y se compromete, entonces la base de datos mantendrá los datos modificados. Si una transacción se compromete pero el sistema falla antes de que los datos puedan escribirse en el disco, entonces esos datos se actualizarán una vez que el sistema vuelva a entrar en acción.
Aislamiento – En un sistema de base de datos en el que se ejecuta más de una transacción simultáneamente y en paralelo, la propiedad de aislamiento establece que todas las transacciones se llevarán a cabo y se ejecutarán como si fuera la única transacción en el sistema. Ninguna transacción afectará a la existencia de cualquier otra transacción.

Serializabilidad

Cuando múltiples transacciones están siendo ejecutadas por el sistema operativo en un entorno de multiprogramación, hay posibilidades de que las instrucciones de una transacción se intercalen con alguna otra transacción.

Programación – Una secuencia de ejecución cronológica de una transacción se llama programación. Un cronograma puede tener muchas transacciones en él, cada una de las cuales comprende un número de instrucciones/tareas.
Cronograma serial – Es un cronograma en el que las transacciones están alineadas de tal manera que una transacción se ejecuta primero. Cuando la primera transacción completa su ciclo, entonces se ejecuta la siguiente transacción. Las transacciones se ordenan una tras otra. Este tipo de cronograma se denomina cronograma en serie, ya que las transacciones se ejecutan de manera serial.

En un entorno de transacciones múltiples, los cronogramas 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 causa ningún daño si dos transacciones son mutuamente independientes y trabajan en diferentes segmentos de datos; pero en caso de que estas dos transacciones estén trabajando en los mismos datos, entonces los resultados pueden variar. Este resultado siempre variable puede llevar a 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.

Programas de equivalencia

Un programa 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 equivalentes. Pueden dar el mismo resultado para algún valor y resultados diferentes para otro conjunto de valores. Es por eso que esta equivalencia no se considera generalmente significativa.

Equivalencia de vista

Dos horarios serían equivalentes de vista si las transacciones en ambos horarios 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 sobre el valor de los datos en S1, entonces también realiza la escritura final sobre el valor de los datos en S2.

Equivalencia de conflicto

Dos programaciones serían conflictivas si tienen las siguientes propiedades –

Ambas pertenecen a transacciones separadas.
Ambas acceden al mismo dato.
Al menos una de ellas es una operación de «escritura».

Dos horarios que tienen múltiples transacciones con operaciones conflictivas se dice que son equivalentes al conflicto si y sólo si –

Ambos horarios contienen el mismo conjunto de Transacciones.
El orden de los pares de operaciones conflictivas se mantiene en ambos horarios.

Nota – Los horarios equivalentes a la vista son serializables a la vista y los horarios equivalentes al conflicto son serializables al conflicto. Todas las programaciones serializables en conflicto son también serializables en vista.

Estados de las transacciones

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

Estados de la transacción

Activa – En este estado, la transacción se está ejecutando. Este es el estado inicial de cada transacción.
Parcialmente comprometida – Cuando una transacción ejecuta su operación final, se dice que está en un estado parcialmente comprometido.
Fallida – 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 seguir adelante.

Abortado – Si alguna de las comprobaciones falla y la transacción ha alcanzado un estado fallido, entonces el gestor de recuperación retrocede todas sus operaciones de escritura en la base de datos para devolver la base de datos a su estado original en el que se encontraba 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 abortar una transacción –

Reiniciar la transacción
Matar la transacción
Comprometida – Si una transacción ejecuta todas sus operaciones con éxito, se dice que está comprometida. Todos sus efectos se establecen ahora de forma permanente en el sistema de base de datos.