Manejo de Transacciones

Transacciones: Concepto. Estructura. Operaciones y Estados de Transacciones.

Propiedades deseables en las transacciones (ACID).
Concepto: Una transacción es una colección de acciones que hacen
transformaciones consistentes de los estados de un sistema preservando la
consistencia del sistema. Una base de datos está en un estado consistente si
obedece todas las restricciones de integridad definidas sobre ella. Los cambios de
estado ocurren debido a actualizaciones, inserciones, y supresiones de
información. Por supuesto, se quiere asegurar que la base de datos nunca entra
en un estado de inconsistencia. Sin embargo, durante la ejecución de una
transacción, la base de datos puede estar temporalmente en un estado
inconsistente. El punto importante aquí es asegurar que la base de datos regresa
a un estado consistente al fin de la ejecución de una transacción. Lo que se
persigue con el manejo de transacciones es por un lado tener una transparencia
adecuada de las acciones concurrentes a una base de datos y por otro lado tener
una transparencia adecuada en el manejo de las fallas que se pueden presentar
en una base de datos.
Condiciones de terminación de una transacción: Una transacción siempre termina,
aun en la presencia de fallas. Si una transacción termina de manera exitosa se
dice que la transacción hace un commit (se usará el término en inglés cuando no
exista un término en español que refleje con brevedad el sentido del término en
inglés). Si la transacción se detiene sin terminar su tarea, se dice que la
transacción aborta. Cuando la transacción es abortada, su ejecución es detenida y
todas sus acciones ejecutadas hasta el momento son deshechas (undone)
regresando a la base de datos al estado antes de su ejecución. A esta operación
también se le conoce como rollback.

Estructura:

 La estructura de una transacción usualmente viene dada según el modelo de la

transacción, estas pueden ser planas (simples) o anidadas.
Transacciones planas: Consisten en una secuencia de operaciones primitivas
encerradas entre las palabras clave BEGIN y END. Por ejemplo: 
            BEGIN _TRANSACTION Reservación
              ….
             END.
Transacciones Anidadas: Consiste en tener transacciones que dependen de otras,
estas transacciones están incluidas dentro de otras de un nivel superior y se las
conoce como subtransacciones. La transacción de nivel superior puede producir
hijos (subtransacciones) que hagan más fácil la programación del sistema y
mejoras del desempeño.
En las transacciones anidadas las operaciones de una transacción pueden ser así
mismo otras transacciones. Por ejemplo:

 Una transacción anidada dentro de otra conserva las mismas propiedades que las
de su padre, esto implica, que puede contener así mismo transacciones dentro de
ella. Existen restricciones obvias en una transacción anidada: debe empezar
después que su padre y debe terminar antes que él. El compromiso de una
subtransaccion es condicional al compromiso de su padre, si el padre de una o
varias subtransacciones aborta, las subtransacciones hijas también serán
abortadas. Las transacciones anidadas brindan un nivel más alto de concurrencia
entre transacciones. Ya que una transacción consiste de varias transacciones es
posible tener mayor concurrencia dentro de una sola transacción.
Así también, es posible recuperarse de fallas de forma independiente de cada sub
transacción. Esto limita el daño a una parte más pequeña de la transacción,
haciendo que el costo de la recuperación sea el menor.
 También se deben considerar el orden de las lecturas y escrituras. Si las acciones
de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a
este tipo de transacciones se les conoce como Generales .Por el contrario, si se
restringe o impone que un dato debe ser leído antes de que pueda ser escrito
entonces se tendrán transacciones Restringidas. Si las transacciones son
restringidas a que todas las acciones de lectura se realicen antes de las acciones
de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un
modelo de acción para transacciones restringidas en donde se aplica aún más la
restricción de que cada par < read, write > tiene que ser ejecutado de manera
atómica.
Operaciones de una transacción
 Inicio de Transacción: Operación que marca el momento en el que una
transacción comienza a ejecutarse.
 Leer o Escribir: Operaciones de lectura/escritura de elementos de la base
de datos.
 Fin de la Transacción: Se verifica si la transacción debe abortarse por
alguna razón.
 Confirmar (COMMIT): La operación termino con éxito.
 Abortar (ROLLBACK): La transacción termino sin éxito.
Estados de una Transacción
 Transacción Activa: se encuentra en este estado justo después de iniciar su
ejecución.
 Transacción Parcialmente Confirmada: en este punto, se efectúan
diferentes operaciones de verificación para asegurar que la transacción no
interfiera con otras transacciones en ejecución.
 Transacción Confirmada: Ha concluido su ejecución con éxito.
 Transacción Fallida: En este caso, es posible que la transacción deba ser
cancelada.
 Transacción Terminada: indica que la transacción a abandonado el sistema.
Propiedades
La discusión en la sección previa clarifica el concepto de transacción. Sin
embargo, aún no se ha dado ninguna justificación para afirmar que las
transacciones son unidades de procesamiento consistentes y confiables. Las
propiedades de una transacción son las siguientes:
 Atomicidad. Se refiere al hecho de que una transacción se trata como una
unidad de operación. Por lo tanto, o todas las acciones de la transacción se
realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que, si
una transacción se interrumpe por una falla, sus resultados parciales deben
ser deshechos. La actividad referente a preservar la atomicidad de
transacciones en presencia de abortos debido a errores de entrada,
sobrecarga del sistema o interbloqueos se le llama recuperación de
transacciones. La actividad de asegurar la atomicidad en presencia de
caídas del sistema se le llama recuperación de caídas.
 Consistencia. La consistencia de una transacción es simplemente su
correctitud. En otras palabras, una transacción es un programa correcto que
lleva la base de datos de un estado consistente a otro con la misma
 característica. Debido a esto, las transacciones no violan las restricciones
de integridad de una base de datos.
 Aislamiento. Una transacción en ejecución no puede revelar sus resultados
a otras transacciones concurrentes antes de su commit. Más aún, si varias
transacciones se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado de manera secuencial
(seriabilidad).
 Durabilidad. Es la propiedad de las transacciones que asegura que una vez
que una transacción hace su commit, sus resultados son permanentes y no
pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran
que los resultados de una transacción sobrevivirán a fallas del sistema.
Esta propiedad motiva el aspecto de recuperación de bases de datos, el
cual trata sobre cómo recuperar la base de datos a un estado consistente
en donde todas las acciones que han hecho un commit queden reflejadas.
Las transacciones proporcionan una ejecución atómica y confiable en presencia
de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y
un manejo correcto de réplicas (en el caso de que se soporten).
Problemas de concurrencia: ejecución sin conflictos. Planificación de
transacciones
La concurrencia es un fenómeno que se presenta en varios contextos. Uno de
ellos es la multiprogramación ya que el tiempo del procesador es compartido
dinámicamente por varios procesos. Otro caso son las aplicaciones estructuradas,
donde la programación estructurada se implementa como un conjunto de procesos
concurrentes. Y por último se tiene que la misma estructuración recién
mencionada es utilizada en el diseño de los sistemas operativos, los cuales se
implementan como un conjunto de procesos.
El termino concurrencia se refiere al hecho de que los DBMS (SISTEMAS DE
ADMINISTRACION DE BD) permiten que muchas transacciones puedan accesar
a una misma base de datos a la vez. En un sistema de estos se necesitan algún
tipo de mecanismos de control de concurrencia para asegurar que las
transacciones concurrentes no interfieran entre sí.
En sistemas multiusuario, es necesario un mecanismo para controlar la
concurrencia. Se pueden producir inconsistencias importantes derivadas del
acceso concurrente, como, por ejemplo, el problema de la operación perdida.
En un sistema de biblioteca, existe un campo que almacena el número de copias
disponibles para préstamo. Este campo debe incrementarse en uno cada vez que
se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un
ejemplar.
Si existen varias bibliotecarias, una de ellas inicia la transacción t1, leyendo la
variable numero ejemplares (n), cuyo contenido se guarda en la variable n1.
Tiempo después, otra bibliotecaria podría leer la misma variable incrementándola
en una unidad, transacción t2. Después, la transacción t1 añade una unidad a esa
variable y la actualiza, el resultado es erróneo, ya que la variable N debería haber
aumentado en 2 unidades, y solo ha aumentado en una. La transacción t2 se ha
perdido.
Consiste en controlar la interacción entre los usuarios concurrentes para no
afectar la inconsistencia de los datos. Cuando se trabajaba con manejadores de
archivos y se estaba actualizando un determinado registro, ningún otro usuario
podía actualizar el mismo archivo; aunque el registro a trabajar fuera otro. Con
esta característica, ya más de un usuario puede accesar a un mismo registro y
actualizarlo.
El objetivo fundamental del control de concurrencia de base de datos es garantizar
que la ejecución concurrente de transacciones no resulta en una pérdida de
consistencia de la base de datos. La concurrencia se da cuando dos transacciones
están interconectadas, lo que es común en un entorno multiusuario. Así pues, en
un entorno de multiprogramación es posible ejecutar varias transacciones de
manera concurrente.
Ejecución sin conflictos:
Planificación de transacciones: Una planificación p de n transacciones T1,..,Tn es
un ordenamiento de las operaciones de las transacciones respetando el orden
interno de cada transacción.
Las planificaciones se clasifican:
 Planificación serializada si para cada transacción T que participa en la
 planificación, las operaciones de T se ejecutan consecutivamente.
 Planificación no serializada
 Planificación serializable si es equivalente a alguna planificación
 serializada del mismo conjunto de transacciones.
 Planificación no serializable si no son equivalentes a ninguna
 planificación serializada
Clasificación de planificaciones:
 Recuperables: una vez que una T ha confirmado nunca será
 necesario deshacerla.
 No recuperables: no satisfacen la condición anterior ( no se deben
 permitir).
Una planificación P es recuperable si ninguna transacción T de P se confirma
antes de que se hayan confirmado todas las transacciones T’ que han escrito un
elemento que T lee.
Concurrencia: Conflicto, correctitud, seriabilidad, inconsistencia, Algoritmos para el
control de concurrencia: Algoritmos Optimistas, Algoritmos de Bloqueo (El
problema del interbloqueo)

Concurrencia:
La concurrencia de bases de datos es la capacidad de una base de datos para
permitir que varios usuarios afecten a varias transacciones. Esta es una de las
principales propiedades que separa una base de datos de otras formas de
almacenamiento de datos, como las hojas de cálculo.
La capacidad de ofrecer simultaneidad es exclusiva de las bases de datos. Las
hojas de cálculo u otros medios de almacenamiento de archivos planos a menudo
se comparan con las bases de datos, pero difieren en este aspecto importante.
Las hojas de cálculo no pueden ofrecer a varios usuarios la capacidad de ver y
trabajar con los diferentes datos en el mismo archivo, porque una vez que el
primer usuario abre el archivo, está bloqueado para otros usuarios. Otros usuarios
pueden leer el archivo, pero no pueden editar los datos.
Conflicto:
Garrido, F. Ficheros y bases de datos (2019) Disponible en línea:
[Link]
Valle, J. Concurrencia en las bases de datos (2015) Disponible en línea:
[Link]
base-datos