PDF de programación - BASES DE DATOSDISTRIBUIDAS MIS 515 - MANEJO DE TRANSACCIONES

<<>>
Imágen de pdf BASES DE DATOSDISTRIBUIDAS MIS 515 - MANEJO DE TRANSACCIONES

BASES DE DATOSDISTRIBUIDAS MIS 515 - MANEJO DE TRANSACCIONESgráfica de visualizaciones

Actualizado el 21 de Marzo del 2018 (Publicado el 20 de Febrero del 2018)
314 visualizaciones desde el 20 de Febrero del 2018
386,4 KB
18 paginas
BASES DE DATOSDISTRIBUIDAS MIS 515
1

1
BASES DE DATOS
DISTRIBUIDAS
TEMA 4
PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ
2

4. MANEJO DE TRANSACCIONES
4.1 Conceptos de Transacciones
4.2 Control de concurrencia
4.3 Serialización de transacciones
4.4 Algoritmos de control de concurrencia
BASES DE DATOSDISTRIBUIDAS MIS 515
2

3
Conceptos de Transacciones
Hasta este momento, las primitivas básicas de acceso que se han
considerado son las consultas (queries). Sin embargo, no se ha discutido
qué pasa cuando, por ejemplo, dos consultas tratan de actualizar el
mismo elemento de datos, o si ocurre una falla del sistema durante la
ejecución de una consulta.
Dada la naturaleza de una consulta de lectura o actualización, a veces no
se puede simplemente reactivar la ejecución de una consulta, puesto que
algunos datos pueden haber sido modificados antes de la falla. El no
tomar en cuenta esos factores puede conducir a que la información en la
base de datos contenga datos incorrectos.
El concepto fundamental aquí es la noción de "ejecución consistente" o
"procesamiento confiable" asociada con el concepto de una consulta. El
concepto de una transacción es usado dentro del dominio de la base de
datos como una unidad básica de cómputo consistente y confiable.
4
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 (Ver Figura
5.1)
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
BASES DE DATOSDISTRIBUIDAS MIS 515
3
datos y por otro lado tener una transparencia adecuada en el manejo de
las fallas que se pueden presentar en una base de datos.

Figura 5.1. Un modelo de transacción.

5

Ejemplo 5.2. Considere una agencia de reservaciones para líneas aéreas con las
siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )
CUST( CNAME, ADDR, BAL )
FC( FNO, DATE, CNAME, SPECIAL )
Una versión simplificada de una reservación típica puede ser implementada mediante
la siguiente transacción:
Begin_transaction Reservación
begin
input( flight_no, date, customer_name );
EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1
WHERE FNO = flight_no
AND DATE = date
EXEC SQL INSERT
INTO FC( FNAME, DATE, CNAME, SPECIAL )
VALUES (flight_no, date, customer_name, null
)
output("reservación terminada");
end.
BASES DE DATOSDISTRIBUIDAS MIS 515
4

6

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.
7
Ejemplo 5.3. Considerando de nuevo el Ejemplo 5.2, veamos el caso cuando
no esisten asientos disponibles para hacer la reservación.
Begin_transaction Reservación
begin
input( flight_no, date, customer_name );
EXEC SQL SELECT STSOLD, CAP
INTO temp1, temp2
FROM FLIGHT
WHERE FNO = flight_no AND DATE = date
if temp1 = temp2 then
output( "no hay asientos libres" )
Abort
else
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD +
1
WHERE FNO = flight_no
AND DATE = date
EXEC SQL INSERT

INTO FC( FNAME, DATE,
CNAME, SPECIAL )
VALUES (flight_no, date,
customer_name, null )
Commit
output("reservación terminada");
endif
end.
BASES DE DATOSDISTRIBUIDAS MIS 515
5

8

Caracterización de transacciones
Observe que en el ejemplo anterior las transacciones leen y
escriben datos. Estas acciones se utilizan como base para
caracterizar a las transacciones. Los elementos de datos
que lee una transacción se dice que constituyen el conjunto
de lectura (RS). Similarmente, los elementos de datos que
una transacción escribe se les denominan el conjunto de
escritura (WS). Note que los conjuntos de lectura y escritura
no tienen que ser necesariamente disjuntos. La unión de
ambos conjuntos se le conoce como el conjunto base de la
transacción F = (FR ∪ DWS)
Ejemplo 5.4. Los conjuntos de lectura y escritura de la transacción
del Ejemplo 5.3 son:
RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }
WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE,
FC.NAME, FC.SPECIAL }
9

Propiedades de las transacciones
La discusión en la sección previa clarifica el concepto de transacción. Sin
embargo, aun 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:
BASES DE DATOSDISTRIBUIDAS MIS 515
6
1. 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.
2. 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.
3. 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).
4. 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 como recuperar la base de datos a un estado consistente en
donde todas las acciones que han hecho un commit queden
reflejadas.
En resumen, 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).

10

Tipos de Transacciones
Las transacciones pueden pertenecer a varias clases. Aun cuando los
problemas fundamentales son los mismos para las diferentes clases, los
BASES DE DATOSDISTRIBUIDAS MIS 515
7
algoritmos y técnicas que se usan para tratarlas pueden ser
considerablemente diferentes. Las transacciones pueden ser agrupadas
a lo largo de las siguientes dimensiones:
1. Aéreas de aplicación. En primer lugar, las transacciones se
pueden ejecutar en aplicaciones no distribuidas. Las transacciones
que operan en datos distribuidos se les conoce como
transacciones distribuidas. Por otro lado, dado que los resultados
de una transacción que realiza un commit son durables, la única
forma de deshacer los efectos de una transacción con commit es
mediante otra transacción. A este tipo de transacciones se les
conoce como transacciones compensatorias. Finalmente, en

ambientes heterogéneos se presentan transacciones heterogéneas
sobre los datos.
2. Tiempo de duración. Tomando en cuenta el tiempo que
transcurre desde que se inicia una transacción hasta que se realiza
un commit o se aborta, las transacciones pueden ser de tipo batch
o en línea. Estas se pueden diferencias también como
transacciones de corta y larga vida. Las transacciones en línea se
caracterizan por tiempos de respuesta muy cortos y por accesar un
porción relativamente pequeña de la base de datos. Por otro lado,
las transacciones de tipo batch toman tiempos relativamente largos
y accesan grandes porciones de la base de datos.
3. Estructura. Considerando la estructura que puede tener una
transacción se examinan dos aspectos: si una transacción puede
contener a su vez subtransacciones o el orden de las acciones de
lectura y escritura dentro de una transacción.

11

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.
BASES DE DATOSDISTRIBUIDAS MIS 515
8
En las transacciones anidadas las operaciones de una transacción
pueden ser así mismo transacciones.
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
  • Links de descarga
http://lwp-l.com/pdf8911

Comentarios de: BASES DE DATOSDISTRIBUIDAS MIS 515 - MANEJO DE TRANSACCIONES (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad