TRANSACCIONES

El término transacción hace referencia a un conjunto de operaciones que

forman una única unidad lógica de trabajo. Por ejemplo, la transferencia de
dinero de una cuenta a otra es una transacción que consta de dos
actualizaciones, una para cada cuenta.
Un sistema de base de datos debe asegurar que la ejecución de las
transacciones se realice adecuadamente a pesar de la existencia de fallos:
O se ejecuta la transacción completamente o no se ejecuta en lo absoluto.
demás debe gestionar la ejecución concurrente de las transacciones evitando
introducir inconsistencias.

Propiedades de las transacciones (propiedades ACID)

Atomicidad (Atomicity)
Significa que el sistema permite operaciones Atómicas. Una operación atómica
es aquella que si está formada por operaciones más pequeñas (acciones) se
consideran como un paquete indivisible.
Resulta importante que,
• bien se ejecuten completamente todas las acciones de una transacción,
• o bien, en el caso de fallo, se deshagan los efectos parciales de la
transacción.
En otras palabras, o todas las operaciones se realizan adecuadamente en
la base de datos o ninguna de ellas.

Propiedades de las transacciones (propiedades ACID)

Consistencia (Consistency)
(Integridad) Esta propiedad asegura que si la base de datos es consistente
inicialmente, la ejecución de la transacción deja a la base de datos en un
estado consistente.
Esta propiedad asegura que sólo se empieza aquello que se puede acabar.
Sostiene que cualquier transacción llevará a la base de datos desde un estado
válido a otro también válido.

Propiedades de las transacciones (propiedades ACID)

Aislamiento (Isolation)
Propiedad que asegura que una operación no puede afectar a otras. Asegura
que en la ejecución concurrente de transacciones, están aisladas entre sí, de
tal manera que cada una tiene la impresión de que ninguna otra transacción se
ejecuta concurrentemente con ella. De este modo, cada transacción ignora al
resto de las transacciones que se ejecutan concurrentemente en el sistema.
Para evitar problemas en la ejecución de transacciones concurrentes, es
ejecutarlas secuencialmente, es decir, una tras otra.
Propiedades de las transacciones (propiedades ACID)
Durabilidad (Durability)
Propiedad que asegura que una vez realizada la operación, ésta persistirá y no
se podrá deshacer aunque falle el sistema.

Estados de una transacción

• Activa, el estado inicial: la transacción permanece en este estado durante
su ejecución.
• Parcialmente comprometida, después de ejecutarse la última instrucción
• Fallida, tras descubrir que no puede continuar la ejecución normal.
• Abortada, después de haber retrocedido la transacción y restablecido la
base de datos a su estado anterior al comienzo de la transacción.
• Comprometida, tras completarse con éxito.

Transacciones en SQL
Un lenguaje de manipulación de datos debe incluir una construcción específica
que indica el conjunto de acciones que constituyen una transacción.
Una transacción se inicia por la ejecución de un sistema transaccional
delimitado por las instrucciones de la forma inicio transacción y fin
transacción; consiste en todas las operaciones que se ejecutan entre el
intermedio.
Las transacciones se terminan con una de las instrucciones SQL siguientes:
Commit (work) comprometiendo la transacción actual y comienza una nueva
Rollback (work) provoca que la transacción actual aborte.

Bitácora de transacciones
Una bitácora es, en la actualidad, un cuaderno o publicación que permite llevar un registro escrito de
diversas acciones. Su organización es cronológica, lo que facilita la revisión de los contenidos anotados.
Es importante que cada vez que un usuario ingrese o modifique datos se grabe un campo de auditoría en
un registro identificándolo, debe de asegurarse de que los registros de la auditoría no puedan ser
modificados ni borrados. Las pistas de auditoría están diseñadas para permitir el rastreo de cualquier
registro de entrada o proceso llevado a cabo en un sistema. Los detalles de cada transacción se registran
en un archivo de transacciones. El estudio de transacciones puede proporcionar información de cómo se
modificó el archivo.

En caso de las aplicaciones integradas que corren en redes, es casi imprescindible el establecimiento de
autorizaciones individuales para cada consulta de datos y para cada tipo de modificación, pues de otro
modo, se haría difícil evitar que cualquier persona consulte o modifique datos sin autorización de la
gerencia. Para esto:
• Debería existir una tabla que indique, para cada potencial usuario: su contraseña; a que aplicaciones
puede acceder; qué actividades de consulta o modificación de datos está autorizado a realizar.
• El sistema de control interno debería prever: quién tendrá la responsabilidad de manejar dicha tabla; quién
puede autorizar modificaciones a ella; qué constancias escritas deben dejarse de cada
modificación.
CONCURRENCIA
El termino concurrencia se refiere al hecho de que los DBMS o
Sistemas de administración de base de datos permiten que muchas
transacciones puedan acceder a la misma base de datos a la vez.
Permitir varias transacciones que actualizan concurrentemente los datos
provoca complicaciones en la consistencia de los mismos, sin embargo existen
dos buenas razones para permitir la concurrencia.
Productividad y utilización de recursos mejoradas.
Tiempo de espera reducido.
Una de las propiedades fundamentales de las transacciones es el aislamiento.
Cuando se ejecutan varias transacciones concurrentes en la base de datos,
puede que deje de conservase la propiedad de aislamiento.
El control de transacciones concurrentes en una base de datos brinda un
eficiente desempeño del sistema de Bases de Datos.

Problemas
Existen formas en las que una transacción, aunque sea correcta por
sí misma, puede producir una respuesta incorrecta si alguna otra transacción
interfiere con ella en alguna forma.
Consideremos que la transacción que interfiere también puede ser correcta; lo
que produce el resultado incorrecto general, es el intercalado son control entre
las dos transacciones correctas.
Los problemas son:
Actualización perdida
Dependencia no confirmada (Lectura Sucia)
Análisis inconsistente
Lectura no repetible o difusa
Lectura fantasma

Actualización Perdida
Ocurre cuando dos transacciones que intentan modificar un elemento de
datos, ambas leen el valor antiguo del elemento, una de ellas (T1) actualiza el
dato, pero esa actualización se pierde dado que la otra transacción (T2) sobre
escribe ese valor sin siquiera leerlo.

Dependencia no confirmada (Lectura Sucia)

Ocurre cuando una transacción T1 lee o actualiza un elemento de datos que
ha sido actualizado por otra transacción T2 que aún no ha sido confirmada.
Por lo tanto, existe la posibilidad de que se deshaga T2 y T1 haya visto un
valor que ya no existe. T1 opera sobre una suposición falsa.
Análisis inconsistente
Se produce cuando una transacción T1, producto de haber leído un dato
actualizado por otra transacción T2 ya confirmada, incurre en un análisis
inconsistente.

Lectura no repetible o difusa

Se produce cuando una transacción T vuelve a leer un elemento de datos que
ya había leído previamente pero que, luego fue modificado por otra
transacción. Así, la transacción T estará leyendo dos valores distintos para el
mismo elemento de datos.

Lectura fantasma
Se produce cuando una transacción T vuelve a ejecutar una consulta que
extrae una cantidad de tuplas de una relación, que ya había ejecutado
anteriormente, pero que ahora devuelve una tupla adicional (fantasma), que
fuera insertada por otra transacción.

Control
El control de Concurrencia: Es la coordinación de procesos concurrentes
que operan sobre datos compartidos y que podrían interferir entre ellos.
Operación. Para el control de concurrencia solo interesan:
• readi(X),ri(X): la transacción i lee el ítem X de la base.
• writei(X),wi(X): la transacción i escribe el ítem X de la base.
• commiti,ci: la transacción i confirma que todas sus modificaciones deben
ser permanentes en la base.
• aborti,ai: la transacción i indica que ninguna de sus modificaciones deben
ser permanentes en la base.
• Rollback. Es la acción de recuperar el estado anterior de la base frente a un
abort de una transacción.

El Manejador de Transacciones (Scheduler o Transaction Manager)

• Se encarga de la administración de las transacciones en la Base de Datos.
• Para eso recibe las instrucciones que los programas pretenden ejecutar y
se toma la libertad de reordenarlas, sin cambiar nunca el orden relativo de los Read y Write.
• Puede llegar a agregar instrucciones (nunca R/W) por su cuenta.
• Puede llegar a demorar la ejecución de las instrucciones.
• Hace lo que necesite para implementar ACID hasta donde pueda.

Operaciones en Conflicto
Dos operaciones (r o w) están en conflicto si cumplen a la vez las siguientes
condiciones:
• Pertenecen a distintas transacciones.
• Acceden al mismo ítem.
• Al menos una es un write.
Historia
Dado un conjunto de transacciones se le llama historia o schedule a una
ordenación de todas las operaciones que intervienen en las transacciones
siempre que estas aparezcan en el mismo orden que en la transacción.
EJ:
• T1: r1(x),w1 (x),c1;
• T2: r2 (x),r2 (y),w2 (x),c2.
• H1: r1(x),w1 (x),c1, r2(x),r2 (y),w2 (x),c2 (Historia Serial)
• H2: r2(x), r1(x),w1(x), r2(y), c1,w2 (x), c2 (Historia Entrelazada)
Historia Completa. Es aquella que tiene todas las operaciones de las
transacciones involucradas y las operaciones en conflicto aparecen en el
mismo orden.

Historias Seriales y Serializables

Si las transacciones se ejecutaran siempre en forma serial, entonces no habría
concurrencia pero los datos siempre serían correctos.
Si las historias son entrelazadas, podría suceder que queden datos erróneos
que no se puedan corregir o que si una transacción aborta otra también tenga
que abortar.
EJ:
• T1: r1(x),w1 (x),a1;
• T2: r2 (x),r2 (y),w2 (x),c2 (o a2).
• H1: r1(x),w1(x), r2(x), r2(y), w2 (x), c2 ,a1 (Historia no recuperable)
• H2: r1(x),w1(x), r2(x), r2(y), w2 (x), a1,a2 (Historia con abortos en cascada)

Se necesitan historias entrelazadas pero con comportamiento de seriales.

Historia Serializable. Es aquella que es equivalente a una historia serial
con las mismas transacciones.
Uso de la Seriabilidad: El manejador debería garantizar la construcción de
historias serializables, y que sean recuperables y que no tengan abortos en
cascada.
Las formas básica de hacer esto, es demorar las operaciones en conflicto con
otras anteriores hasta que estas terminen.
Hay dos formas básicas de hacer esto:
• Locking (Bloqueos)
• Timestamps

Historia Recuperable. Una historia es Recuperable si ninguna transacción confirma hasta que confirmaron
todas las transacciones desde las cuales se leyeron ítems. (Los commit’s están en el mismo orden que el
flujo de datos). Si T1 guarda algo y T2 lo lee, primero T1 debe confirmar y después T2
Ejemplo.
• T1: w1(x), w1(z), r1(y), w1(y),c1
• T2: r2(y), w2(y), w2(z), c2
• H1: r2(y), w2(y), w1(x), w2(z), w1(z), r1(y), w1(y), c2, c1
Una historia Evita Abortos en Cascada es, donde ninguna transacción lee de
transacciones no confirmadas. (Los commit’s tienen que estar antes de los
read’s siguientes, se lee de transacciones ya confirmadas)
Ejemplo.
• T1: w1(x), w1(z), r1(y), w1(y),c1
• T2: r2(y), w2(y), w2(z), c2
• H2: r2(y),w1(x),w2(y), w2(z), w1(z), c2, r1(y), w1(y), c1
Una historia es Estricta si ninguna transacción lee o escribe hasta que todas
las transacciones que escribieron ese ítem fueron confirmadas. (Los commit’s
tienen que estar antes de los read’s write’s siguientes).
Ejemplo.
• T1: w1(x), w1(z), r1(y), w1(y),c1
• T2: r2(y), w2(y), w2(z), c2
• H3: r2(y), w1(x), w2(y), w2(z), c2, w1(z), r1(y), w1(y), c1

Se consideran dos operaciones nuevas en una transacción

• Ti: locki(X) ( o li(X)) y unlocki(X) (o ui(X)).
Cuando se ejecuta li(X), el DBMS hace que cualquier lj(X) (de otra transacción
Tj) no termine hasta que Ti ejecute ui(X).
El comportamiento es similar a los semáforos utilizados en los sistemas
operativos.
Ej:
• T1: l1(x), r1(x), w1(x), u1(x), l1(y), r1(y), w1(y), u1(x)
• T2: l2(x),r2(x), w2(x), u2(x)
• H1: l1(x), r1(x), w1(x), u1(x), l2(x),r2(x), w2(x), u2(x) l1(y),r1(y), w1(y), u1(x)
• H2: l1(x),r1(x), l2(x), w1(x), u1(x), r2(x), w2(x), u2(x) l1(y),r1(y), w1(y), u1(x)

Lock Binario.
Un ítem o está bloqueado o desbloqueado.
• Ventaja: Fácil de implementar.
• Desventaja: Niega incluso la lectura a otras transacciones, cuando esto no
sería necesario.

Read/Write Lock.
Hay tres operaciones a considerar:
• read_locki(X) (o rli(X)),
• write_locki(X) (o wli(X)),
• unlocki(X) (o ui(X)).
Ventaja: Se permite que varias operaciones hagan un rl (pero no un wl)
simultáneamente sobre el mismo ítem.
Desventaja: Un poco más complicado de implementar.
Deadlock
El uso de bloqueos puede conducir a una situación no deseada. El
interbloqueo es un estado en el cual ninguna transacción puede continuar su
ejecución normal.
En otras palabras, es cuando dos o más transacciones esperan unas por otras,
es decir, dos o más transacciones esperan unas por otras.

Chequeo: construir grafo de espera Tiene un arco de Ti a Tj si Ti está tratando

de lockear un ítem que Tj tiene lockeado. Si tiene ciclos, entonces hay
deadlock

Paquete en base de datos

Un paquete es una estructura que agrupa objetos de PL/SQL
compilados(procedimientos, funciones, variables, tipos ...) en la base de datos.
Esto nos permite agrupar la funcionalidad de los procesos en programas.
Los paquetes están formados por dos partes: la especificación y el cuerpo,
las cuales se crean por separado.
La especificación es la interfaz con las aplicaciones. En ella se declaran los
tipos, variables, constantes, excepciones, cursores y subprogramas
disponibles para su uso posterior desde fuera del paquete.
En la especificación del paquete sólo se declaran los objetos (procedures,
funciones, variables ...), no se implementa el código.
Los objetos declarados en la especificación del paquete son accesibles desde
fuera del paquete por otro script de PL/SQL o programa. Haciendo una
analogía con el mundo de C, la especificación es como el archivo de cabecera
de un programa en C.

Disparadores
Un trigger( o desencadenador) es una clase especial de procedimiento
almacenado que se ejecuta automáticamente cuando se produce un evento en
el servidor de bases de datos.
SQL proporciona los siguientes tipos de triggers:
• Trigger DML, se ejecutan cuando un usuario intenta modificar datos
mediante un evento de lenguaje de manipulación de datos (DML). Los
eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla
o vista.
• Trigger DDL, se ejecutan en respuesta a una variedad de eventos de
lenguaje de definición de datos (DDL). Estos eventos corresponden
principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL,
y a determinados procedimientos almacenados del sistema que ejecutan
operaciones de tipo DDL.
FALLOS
1. Fallo en la transacción
Error Lógico. La transacción no puede continuar con su ejecución normal a causa de alguna condición
interna, como una entrada incorrecta, datos no encontrados, desbordamiento o exceso del límite de
recursos.
Error del Sistema. El sistema se encuentra en un estado no deseado, por ejemplo, de interbloqueo y
como consecuencia una transacción no puede continuar con su ejecución normal. La transacción, sin
embargo, se puede volver a ejecutar más tarde.

2. Caída del sistema. Un mal funcionamiento del hardware o un error en el software de la base de
datos o del sistema operativo causa la pérdida del contenido de la memoria volátil (RAM) y aborta
el procesamiento de una transacción. El contenido de la memoria no volátil permanece intacto y
no se corrompe.

3. Fallo de Disco. Un bloque del disco pierde su contenido como resultado de bien una colisión de la
cabeza lectora, bien un fallo durante una operación de transferencia de datos. Las copias de los
datos que se encuentran en otros discos o en archivos de seguridad en medios de
almacenamiento secundarios, como cintas, se utilizan para recuperarse del fallo. Para recuperar el
sistema de los fallos y garantizar la consistencia de la base de datos y la atomicidad de las
transacciones, se proponen algoritmos de recuperación, los cuales constan de dos partes:
• Acciones llevadas a cabo durante el procesamiento normal de transacciones para asegurar que existe
información suficiente para permitir la recuperación frente a fallos.
• Acciones llevadas a cabo después de ocurrir un fallo para establecer el contenido de la base de datos a
un estado que asegure la consistencia de la base de datos, la atomicidad de la transacción y la
durabilidad.