ESCUELA POLITCNICA NACIONAL

FACULTAD DE INGENIERA DE SISTEMAS INFORMTICOS

BASES DE DATOS DITRIBUIDAS GR1
NOMBRE: ALEXIS GUERRERO
FRANCISCO IZURIETA
DAVID MORALES
FECHA: 27/0/2017
TEMA: RESUMEN DEDEL CAPITULO 10 DEL LIBRO DE TRABAJO

10 INTRODUCCIN A LA GESTIN DE TRANSACCIONES

Las transacciones en bases de datos son unidades bsicas de computo confiable y
consistente. Esto implica que las transacciones sean ejecutadas como consultas cuando sus
estrategias de ejecucin son determinadas y son traducidas operaciones de base de datos
primitivas.
Dentro de lo que engloba a las transacciones es importante hablar de consistencia de ejecucin
y computacin confiable.
Consistencia que la base de datos no adquiera valores extraos por actualizaciones que se
produzcan en ella (consistencia mutua).
Confiabilidad sistema que se pueda recuperar de fallos ocurridos, es decir un sistema flexible.
La administracin de las transacciones tiene que ver con la consistencia de una base de datos
a pesar de que haya fallos.
10.1 Definicin de transaccin
No existe una sola definicin, pero la ms acertada sera: conjunto de operaciones de lectura y
escritura sobre una base datos, en donde deben ejecutarse todas o ninguna de ellas. Una
transaccin difiere de una consulta en el aspecto que esta genera una nueva versin de la base
de datos, mientras que la consulta no.
A nivel de DMBS cuando se realiza una transaccin se inicia con un begin y se finaliza con un
end, pero muchas veces esto se omite ya que no se tiene transacciones complejas.

10.1.1 Condiciones de finalizacin de las transacciones

Sin importar que una transaccin no tenga condiciones de terminado puede finalizar sin
importar los fallos de consistencia que se puedan dar. Las condiciones de finalizacin de una
transaccin son:
Commit se realiz correctamente la transaccin
Rollback no se realiz la transaccin y se mantienen intactos los datos originales.

Aunque en muchas transacciones no se especfica el commit y rollback, especificar estas

condiciones hacen que no se comentan errores de consistencia y se tenga una base de datos
ms confiable.
Ejemplo:
Se realiza una compra y se tiene un determinado stock, si el nmero de productos es menor al
stock se ejecuta la transaccin (commit), pero por el contrario si el nmero de productos
pedidos es mayor al stock existente no se realiza la transaccin y no se modifica nada
(rollback).

10.1.2 Caracterizacin de las transacciones

El conjunto de tems que la transaccin est a destinada a leer se llaman conjunto de lectura, y
los que la transaccin est destinada a escribir se llaman conjunto de escritura.
Los dos conjuntos mencionados anteriormente unidos se conocen como conjunto base y es el
grupo de tems o atributos que de alguna manera estn involucrados en una transaccin.
Las operaciones de lectura y escritura son meramente abstractas, ya que su verdadero
procedimiento se da a nivel de software y hardware.
10.1.3 Formalizacin del concepto de transaccin
Una transaccin Ti tiene operaciones asociadas Oij sobre una entidad x.
Ejemplo:
Leer (x)
x=x+1
escribir (x)
commit

Esto se puede representar mediante un diagrama de orden, similar al siguiente:

L(x) e(x) c

10.2 Propiedades de las transacciones

Los aspectos de consistencia y fiabilidad de las transacciones se deben a cuatro propiedades:
(1) atomicidad, (2) consistencia, (3) aislamiento, y (4) durabilidad. Juntas, estas son
comnmente referidas como las propiedades ACID de las transacciones. No son totalmente
independientes entre s; por lo general hay dependencias entre ellas.
10.2.1 Atomicidad
La atomicidad se refiere al hecho de que una transaccin se trata como una unidad de
operacin. Por lo tanto, se completan todas las acciones de la transaccin o ninguna de ellas.
Esto tambin se conoce como la "propiedad del todo o nada". La atomicidad requiere que, si la
ejecucin de una transaccin es interrumpida por cualquier tipo de falla, el DBMS ser
responsable de determinar qu hacer con la transaccin al recuperarse del fallo. Existen, por
supuesto, dos posibles lneas de accin: se puede finalizar completando las acciones restantes,
o se puede terminar anulando todas las acciones que ya se han ejecutado.
En general se puede hablar de dos tipos de fallos. Una transaccin en s puede fallar debido a
errores de datos de entrada, bloqueos u otros factores. En estos casos, o bien la transaccin se
anula, o el DBMS puede abortarla mientras se manejan los interbloqueos. El mantenimiento de
la atomicidad de la transaccin en presencia de este tipo de falla comnmente se denomina
recuperacin de la transaccin. El segundo tipo de fallo es causado por fallos del sistema,
como fallos de los medios, fallos del procesador, roturas de los enlaces de comunicacin,
cortes de energa, etc. Asegurar la atomicidad de la transaccin en presencia de fallos del
sistema se llama recuperacin de fallos.
10.2.2 Consistencia
La consistencia de una transaccin es simplemente que sea correcta. En otras palabras, una
transaccin es un programa correcto que asigna un estado de base de datos consistente a otro.
Hay una interesante clasificacin de consistencia que agrupa las bases de datos en cuatro
niveles de consistencia [Gray et al., 1976]. En la siguiente definicin los datos sucios se refieren
a valores de datos que han sido actualizados por una transaccin antes de su commit.
"Grado 3: La transaccin T tiene grado 3 de consistencia si:
1. T no sobrescribe datos sucios de otras transacciones.
2. T no realiza ninguna escritura hasta el final de la transaccin (EOT).
3. T no lee datos sucios de otras transacciones.
4. Otras transacciones no ensucian los datos ledos por T antes de que T se
complete.
Grado 2: La transaccin T tiene grado 2 de consistencia si:
1. T no sobrescribe datos sucios de otras transacciones.
2. T no realiza ninguna escritura antes de EOT.
3. T no lee datos sucios de otras transacciones.
Grado 1: La transaccin T tiene grado 1 de consistencia si:
1. T no sobrescribe datos sucios de otras transacciones.
2. T no realiza ninguna escritura antes de EOT.
Grado 0: La transaccin T tiene grado 0 de consistencia si:
1. T no sobrescribe datos sucios de otras transacciones. "
El punto en la definicin de mltiples niveles de consistencia es proporcionar a los
programadores de aplicaciones la flexibilidad para definir las transacciones que operan en
diferentes niveles.
10.2.3 Aislamiento
El aislamiento es la propiedad de las transacciones que requiere que cada transaccin vea una
base de datos consistente en todo momento. En otras palabras, una transaccin en ejecucin
no puede revelar sus resultados a otras transacciones simultneas antes de su commit. Si dos
transacciones simultneas acceden a un elemento de datos que est siendo actualizado por
una de ellas, no es posible garantizar que la segunda lea el valor correcto.
Ejemplo 10.8. Considere las siguientes dos transacciones simultneas (T1 y T2), las cuales
acceden al elemento de datos x. Suponga que el valor de x antes de comenzar a ejecutar es
50.

Lo siguiente es una posible secuencia de ejecucin de las acciones de estas transacciones:

Si T1 y T2 se ejecutan uno tras otro (independientemente del orden), la segunda transaccin
leer 51 como el valor de x y x tendr 52 como su valor al final de la ejecucin de estas dos
transacciones. Sin embargo, dado que las transacciones se ejecutan simultneamente, tambin
es posible la secuencia de ejecucin siguiente:

En este caso, la transaccin T2 lee 50 como el valor de x. Esto es incorrecto ya que T2 lee x
mientras que su valor se est cambiando de 50 a 51. Adems, el valor de x es 51 al final de la
ejecucin de T1 y T2, ya que la escritura de T2 sobrescribir la escritura de T1.
Asegurar el aislamiento al no permitir que los resultados incompletos sean vistos por otras
transacciones, como muestra el ejemplo anterior, resuelve el problema de las actualizaciones
perdidas. Este tipo de aislamiento se ha denominado estabilidad del cursor. Una segunda razn
para el aislamiento es la interrupcin en cascada. Si una transaccin permite a otros ver sus
resultados incompletos antes de comprometerse y luego decide abortar, cualquier transaccin
que haya ledo sus valores incompletos tendr que abortar tambin.
Es posible tratar los niveles de consistencia desde la perspectiva de la propiedad de
aislamiento. El grado 0 proporciona muy poco aislamiento aparte de prevenir las
actualizaciones perdidas. Grado 2 de consistencia evita abortos en cascada. El Grado 3
proporciona un aislamiento completo que obliga a una de las transacciones en conflicto a
esperar hasta que el otro termine.
ANSI, como parte de la especificacin estndar SQL2, ha definido un conjunto de niveles de
aislamiento [ANSI, 1992]. Se especifican tres fenmenos:
Lectura Sucia: Considere el caso en el que la transaccin T1 modifica un valor de
elemento de datos, que luego se lee por otra transaccin T2 antes de que T1 realice
una confirmacin o anulacin. En caso de interrupcin de T1, T2 ha ledo un valor que
nunca existe en la base de datos.
 Lectura no repetible o difusa: La transaccin T1 lee el valor de un dato. Otra
transaccin T2 entonces modifica o elimina ese dato y hace commit. Si T1 intenta volver
a leer el valor del dato, o bien lee un valor diferente o no puede encontrar el dato en
absoluto; As dos lecturas dentro de la misma transaccin T1 devuelven resultados
diferentes.
Lectura Fantasma: Ocurre cuando T1 hace una bsqueda con un predicado y T2
inserta nuevas tuplas que satisfacen el predicado.
Basndose en estos fenmenos, los niveles de aislamiento se definen como sigue.
Read uncommitted: Para transacciones que operan a este nivel, los tres fenmenos son
posibles.
Read committed: Las lecturas difusas y fantasma son posibles, pero las lecturas sucias no lo
son.
Repeatable read: Slo lecturas fantasmas son posibles.
Anomaly serializable: Ninguno de los fenmenos es posible.
10.2.4 Durabilidad
Durabilidad se refiere a la propiedad de las transacciones que garantiza que una vez que una
transaccin se compleata, sus resultados son permanentes y no se pueden borrar de la base
de datos. Por lo tanto, el DBMS garantiza que los resultados de una transaccin sobrevivirn
fallas subsiguientes del sistema. La propiedad de durabilidad plantea el problema de la
recuperacin de la base de datos, es decir, cmo recuperar la base de datos a un estado
consistente en el que se reflejan todas las acciones hechas commit.
 10.3 Tipos de transacciones
Las transacciones han sido clasificadas de acuerdo a varios criterios. Uno de los criterios es la
duracin de la transaccin. De acuerdo con esto las transacciones pueden ser clasificadas
como en lnea o por lotes. Las cuales son llamadas de vida-corta o vida-larga respectivamente.
Las transacciones en lnea tienen como principal caracterstica tener tiempos de respuesta
cortos y porque acceden a una pequea porcin de la base de datos. Por otro lado, las
transacciones por lotes, toman largos tiempos de ejecucin y acceden a una gran porcin de la
base de datos.
Otro tipo de clasificacin que se ha propuesto es con respecto a la organizacin de las
acciones de escritura y lectura. El tipo de transacciones que permiten tanto lectura y escritura
sin un orden especfico, son llamadas transacciones generales. Si las transacciones son
restringidas y todas las acciones de lectura deben ser ejecutadas antes de las acciones de
escritura, entonces la transaccin es llamada two-step. De forma similar si un elemento de los
datos debe ser ledo antes de que pueda ser actualizado, se denominan restricted(o lectura
antes de escritura). Si la transaccin es two-step y restricted a la vez, se denomina como una
transaccin restricted two-step. Finalmente tenemos el modelo de accin de transacciones, el
cual consiste del tipo restringido, donde cada par (lectura, escritura) es ejecutado
automticamente.
Tambin se pueden clasificar las transacciones de acuerdo a su estructura. Se pueden
distinguir cuatro amplias categoras en incremento de complejidad: transacciones tipo flat,
transacciones anidadas cerradas, transacciones anidadas abiertas, modelos workflow que en
algunos casos son combinaciones de varias formas anidadas. Esta clasificacin es
probablemente la ms comn.
10.3.1 Transacciones de tipo flat
Las transacciones flat tienen un nico punto de inicio y un nico punto de finalizacin. La
mayora del trabajo de gestin de transacciones se centran en transacciones flat.
10.3.2 Transacciones Anidadas
Un modelo alternativo de transacciones es permitir a una transaccin incluir otra transaccin
con sus propios puntos de inicio y retroalimentacin. Este tipo de transacciones que son
incrustadas dentro de otras son llamadas subtransacciones.
Se diferencian entre anidamiento cerrado y abierto por sus caractersticas de terminacin. Las
transacciones anidadas cerradas se comprometen en un modelo ascendente a travs de la
raz. Por lo tanto, una subtransaccin anidada comienza luego de que su padre haya
empezado y termina antes de este. Una transaccin anidada abierta permite que sus
resultados sean observados por fuera de la transaccin.
Las ventajas de las transacciones anidadas son: primero, proveen un nivel de concurrencia
ms alto entre transacciones. Como una transaccin consiste de un nmero de otras
transacciones, una mayor concurrencia es posible dentro de una sola transaccin.
Un segundo argumento a favor de las transacciones anidadas est relacionada a la
recuperacin. Es posible recuperarse independientemente de los fallos de cada
subtransaccin. Esto limita el dao a una pequea parte de la transaccin.
Finalmente, es posible crear nuevas transacciones de las ya existentes.
10.3.3 Workflows
Una definicin aceptada es que workflows es una coleccin de tareas organizadas para llevar a
cabo algn proceso de negocio.
Se pueden identificar tres tipos de workflows:
1. Workflows orientados al ser humano los cuales involucran a los humanos en la realizacin de
las tareas.
2. Workfllows orientados al sistema son los que consisten de computacin y tareas
especializadas que pueden ser ejecutadas por un computador.
3. Workflows transaccionales su alcance est entre orientado al ser humano y orientado al
sistema y toma caractersticas de ambos.
Un workflow es modelado con semntica de anidamiento abierto.