Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Manejo de transacciones

Unidad 4 BDD
by

Lucero Zamora

on 24 June 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Manejo de transacciones

Transacciones Control de concurrencia Manejo de transacciones Unidad 4 Qué es??? El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Ing. Lucero Zamora Merino Hasta el momento, las primitivas básicas de acceso que se han considerado son las consultas o queries. Pero 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 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. 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 Ejemplo 1:
Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.

UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"


Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre:

Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
end. Ejemplo 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. 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. 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. Tarea: sintaxis de commit y rollback Propiedades Atomicidad Consistencia Aislamiento Durabilidad Se refiere al hecho de que una transacción se trata como una unidad de operación. 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. La consistencia de una transacción es simplemente su correctitud. 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. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). 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. 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. Tipos Áreas de aplicación Tiempo de duración Estructura Las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. 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. 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 diferenciar 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. Las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones El orden de las acciones de lectura y escritura dentro de una transacción. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: Aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados o bloqueos). Aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos).
Full transcript