Universidad Nacional Experimental Rafael Maria Baralt (UNERMB)

Sede San Francisco – PNF en Informática

Unidad Curricular Adm dé base de Datos
Trayecto 4-1

Trabajo 1

Realizado por:
Darwin Sulbaran
C.I: V-19485795

Marzo del 2021

DEFINICIÓN DE UNA TRANSACCIÓN
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.
ESTRUCTURA DE TRANSACCIONES
Las transacciones planas consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end. Por ejemplo,
Begin_transaction Reservación
...
end.
En las transacciones anidadas las operaciones de una transacción pueden ser así
mismo transacciones. Por ejemplo,
Begin_transaction Reservación
...
Begin_transactionVuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
...
end.
...
end.
Una transacción anidada dentro de otra transacción conserva las mismas
propiedades que la de sus padres, 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. Más
aún, el commit de una subtransacción es condicional al commit de su padre, en
otras palabras, si el padre de una o varias transacciones aborta, las
subtransacciones hijas también serán abortadas.
Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre
transacciones. Ya que una transacción consiste de varios transacciones, es
posible tener más concurrencia dentro de una sola transacción. Así también, es
posible recuperarse de fallas de manera independiente de cada subtransacción.
Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo
de la recuperación sea menor.
En el segundo punto de vista se considera 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. En
contraste, si se restringe o impone que un dato deber 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.
Ejemplo 6. Los siguientes son algunos ejemplos de los modelos de transacción
mencionados antes.
General: T1: { R(x), R(y), W(y), R(z), W(x), W(z), W(w), C}
Dos pasos: T2: { R(x), R(y), R(z), W(x), W(y), W(z), W(w), C}
Restringida: T3: { R(x), R(y), W(y), R(z), W(x), W(z), R(w), W(w), C}
Restringida y de dos pasos:
T4: { R(x), R(y), R(z), R(w), W(y), W(x), W(z), W(w), C}
Acción: T5: { [R(x), W(x)], [R(y), W(y)], [R(z), W(z)], [R(w), W(w)], C}
note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica
¨
OPERACIONES DE UNA TRANSACCIÓN
Para hacer posible el control de la concurrencia de las transacciones, así como la
recuperación del sistema tras fallos o caídas del mismo, es necesario almacenar
cuándo se inicia, termina, se confirma o se aborta cada transacción, y además qué
modificaciones de qué elementos de BD realiza cada una.
• 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, que se
realizan como parte de una transacción.
• FIN DE TRANSACCIÓN
Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si
la transacción debe abortarse por alguna razón (si viola el control de concurrencia,
por ejemplo), o bien si los cambios realizados por la transacción (hasta ahora en
buffers de memoria volátil) pueden aplicarse permanentemente a la base de datos
en disco (es decir, si puede realizarse una operación de CONFIRMAR (COMMIT)).
• CONFIRMAR
La transacción terminó con éxito, todos los cambios que ha realizado se pueden
confirmar sin peligro en la BD y ya no serán cancelados.
• ABORTAR
La transacción terminó sin éxito y toda actualización que ha realizado se debe
cancelar.
Algunas técnicas de recuperación necesitan operaciones adicionales como las
siguientes:
• DESHACER
Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción
completa.
• REHACER
Especifica que algunas de las operaciones realizadas por una transacción deben
repetirse, para asegurar que todas las operaciones realizadas por una transacción
que ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es decir, los
cambios hayan quedado grabados físicamente en disco).
ESTADOS DE UNA TRANSACCIÓN
El siguiente es el diagrama de transición de estados para la ejecución de
transacciones:

Una transacción entra en el estado ACTIVA justo después de iniciar su ejecución

y, en este estado, puede realizar operaciones LEER y ESCRIBIR.
Cuando la transacción finaliza, pasa al estado PARCIALMENTE CONFIRMADA.
En este punto, el
Subsistema de Control de Concurrencia puede efectuar verificaciones para
asegurar que la transacción no interfiera con otras transacciones en ejecución.
Además, el Subsistema de Recuperación puede anotar qué operaciones (qué
cambios) ha realizado que la transacción en un fichero del sistema (bitácora3), con
el objetivo de garantizar que los cambios realizados por la transacción terminada
queden permanentes, a pesar de fallos del sistema.
Una vez realizadas con éxito ambas verificaciones, la transacción ha llegado a su
punto de confirmación4 y pasa al estado CONFIRMADA (ha concluido su
ejecución con éxito).
Si una de las verificaciones falla o la transacción se aborta mientras está en
estado ACTIVA, pasa al estado FALLIDA. En este caso, es posible que la
transacción deba ser cancelada (anulada, revertida, abortada) para anular los
efectos de sus operaciones ESCRIBIR sobre la BD.
El estado TERMINADA indica que la transacción ha abandonado el sistema.
Las transacciones fallidas (abortadas) pueden ser reiniciadas posteriormente, ya
sea de forma automática por parte del sistema, o bien sea el usuario el que las
reintroduzca como si fueran nuevas transacciones.
Propiedades
Las transacciones deben cumplir cuatro propiedades, denominadas ACID:
Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha
realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
Consistencia (Consistency): es la propiedad que asegura que sólo se empieza
aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que
no van a romper la reglas y directrices de integridad de la base de datos.
Aislamiento (Isolation): es la propiedad que asegura que una operación no puede
afectar a otras. Esto asegura que la realización de dos transacciones sobre la
misma información nunca generará ningún tipo de error.
Durabilidad (Durability): es la propiedad que asegura que una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
La atomicidad frente a fallos se suele implementar con mecanismos de journaling,
y la protección frente a accesos concurrentes mediante bloqueos en las
estructuras afectadas. La serialibilidad viene garantizada por la atomicidad. La
permanencia se suele implementar forzando a los periféricos encargados de
almacenar los cambios a confirmar la completa y definitiva transmisión de los
datos al medio (generalmente, el disco).
La forma algorítmica que suelen tener las transacciones es la siguiente:

En cualquier momento, el programa podría decidir que es necesario hacer fallar la

transacción, con lo que el sistema deberá revertir todos los cambios hechos por
las operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a
aplicar_cambios y ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos y,
más recientemente, se han visto incorporadas a cómo gestiona un sistema
operativo la interacción con un sistema de archivos (como varias características de
las bases de datos, debido a que son muy similares arquitectónicamente).
Sistema de Información Transaccional
 Un sistema transaccional debe controlar las transacciones para mantener la
seguridad y consistencia de los datos involucrados. Por ejemplo, un cliente
transfiere dinero de una cuenta a otra cuenta dentro de un mismo banco; la
cantidad de dinero que se descuenta de la cuenta emisora debe ser igual a la que
se suma en la cuenta receptora. De no ser así, la acción (transacción) no se
realiza.
Un sistema transaccional debe ser capaz de enmendar cualquier error
ocurrido durante una transacción, pudiendo deshacer las operaciones realizadas,
manteniendo los datos tal cual estaban antes del error.También debe ser capaz de
controlar y administrar múltiples transacciones, determinando prioridades entre
éstas. Por ejemplo, un cliente está haciendo la reserva de un asiento en un vuelo,
dicho asiento debe ser bloqueado temporalmente hasta que se concrete la
transacción, porque otro cliente podría estar queriendo reservar el mismo asiento
en el mismo momento.
Diferencias entre algoritmos optimistas y algoritmos de bloqueo
Algoritmo optimista Algoritmo de bloqueo
El control de concurrencia  Estudiar cada solicitud al ocurrir
optimista (en ésta.
inglés Optimisticconcurrency
 Ver si su otorgamiento conduce
control o OCC) es un método
de control de concurrencia que se a un estado seguro:
aplica a sistemas transaccionales, o En caso positivo, se
tales como sistemas de gestión de otorga la solicitud.
bases de datos relacionales y memoria o En caso negativo, se la
transaccional de software. El OCC pospone.
asume que múltiples transacciones se
 Para ver si un estado es seguro:
pueden completar frecuentemente sin
interferir entre sí. Mientras se ejecutan, o Verifica si tiene los
las transacciones utilizan recursos de recursos suficientes para
datos sin adquirir bloqueos en esos satisfacer a otro cliente:
recursos. Antes de hacer el commit,  En caso
cada transacción verifica que ninguna afirmativo, se
otra transacción ha modificado los supone que los
datos que ha leído. Si la comprobación
préstamos se
revela modificaciones en conflicto, la
transacción que iba a hacer commit pagarán.
hace un rollback y se puede reiniciar.  Se verifica al
El control de concurrencia optimista siguiente cliente
fue propuesto por primera vez por H. cercano al límite y
T. Kung. así sucesivamente.
El OCC se utiliza generalmente en o Si en cierto momento se
entornos con baja contención de datos.
vuelven a pagar todos los
Cuando los conflictos son poco
frecuentes, las transacciones se créditos, el estado es
pueden completar sin el coste de la seguro y la solicitud
gestión de bloqueos y sin tener original debe ser
transacciones esperando a que se aprobada.
borren los bloqueos de otras
transacciones, dando lugar a un mayor
rendimiento que otros métodos de
control de concurrencia. Sin embargo,
si la contención de recursos de datos
es frecuente, el coste de reiniciar las
transacciones repetidamente perjudica
el rendimiento de manera significativa;
comúnmente se piensa que otros
métodos de control de
concurrencia tienen un mejor
rendimiento en estas condiciones. Sin
embargo, los métodos basados en
bloqueos ("pesimistas") también
pueden ofrecer un rendimiento pobre
porque los bloqueos pueden limitar
drásticamente la concurrencia efectiva
incluso cuando se evitan los deadlocks

Explique de qué se encarga la concurrencia en las bases de datos

El control de transacciones concurrentes en una base de datos brinda un eficiente
desempeño del Sistema de Base de Datos, puesto que permite controlar la
ejecución de transacciones que operan en paralelo, accesando a información
compartida y, por lo tanto, interfiriendo potencialmente unas con otras.
El hecho de reservar un asiento en un avión mediante un sistema basado en
aplicaciones web, cuando decenas de personas en el mundo pueden reservarlo
también, nos da una idea de lo importante y crucial que es el control de
concurrencia en un sistema de base de datos a mediana o gran escala.
Otro ejemplo en el que podemos observar la incidencia del control de concurrencia
en el siguiente: en una Base de Datos bancaria podría ocurrir que se paguen dos
cheques en forma simultánea sobre una cuenta que no tiene saldo suficiente para
cubrirlos en su totalidad, esto es posible evitarlo si se tiene un control de
concurrencia.