Universidad Tecnológica de Izúcar de Matamoros Programa Educativo:

1. Universidad Tecnológica de Izúcar de Matamoros Programa Educativo: Tecnologías de la Información MATERIA: Base de datos para aplicaciones MAESTRO: GONZALO ROSAS CABRERA ACTIVIDAD: Operatividad de transacciones. INTEGRANTES: Omar Osorio osorio 11292036 Marco Antonio torres carranco11292077 VIERNES, 07 de febrero de 2014

2. Índice • Planes (historias) de transacciones • Puntos que debe cumplir un plan completo • Soporte de transacciones en SQL • Sentencia explicita en SQL • Características atribuidas a cada transacción • Nivel de aislamiento más bajo que serializable • Ejemplo1 • Ejemplo2 • Conclusión Omar • Conclusión Marco • Referencias • Transacción • Los sistemas de procesamientos de transacciones son sistemas • Estados de transacciones y operaciones adicionales • Función de cada una de las operaciones • Diagrama que muestra el paso de una transacción por sus estados de ejecución • El diario del sistema • Tipos de entradas denominadas registros del diario • Función de cada uno de los tipos de entradas • Punto de confirmación de una transición • En que cosiste cada una de las propiedades ACID • Planes de transacción

3. Transacción Unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Esta se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación como SQL, C++ o Java Las transacciones están limitadas Por funciones de la forma begintransaction(inicio de transacción ) y endtransaction(Fin transacción ). La transacción consisten en todas las operaciones que se ejecuta entre begintransactionyendtransaction.

4. Los sistemas de procesamientos de transacciones son sistemas Son sistemas con grandes bases de datos y cientos de usuarios concurrentes que están ejecutando transacciones de bases de datos un ejemplo de dichos sistemas son como el procesamiento de las tarjetas de crédito, cajas de supermercados entre otros.

5. Estados de transacciones y operaciones adicionales Una transacción es una unidad atómica de trabajo que se realiza por completo o no se efectúa en lo absoluto. Para fines de recuperación el sistema necesita mantenerse al tanto en cuanto la transacción (inicia, termina, confirma o aborta). Siguiendo las siguientes operaciones todas relacionas al recorrido de la transacción • BEGIN_TRANSACTION • READ o WRITE • END_TRANSACTION • COMMIT_TRASACTION • ROLLBACK o ABORT

6. Función de cada una de las operaciones • BEGIN_TRANSACTION (inicio_de_transacción): marca el principio de la ejecución de transacción. • READ (leer) o WRITE (escribir): éstas especifican las operaciones de lectura o escritura de elementos de base de datos que se ejecutan. • END_TRANSACTION (fin_de_transacción): especifica que las operaciones READ o WRITE han terminado. • COMMIT_TRASACTION (confirmar_transacción): confirma la transacción si es que ya termino con éxito. • ROLLBACK (restaurar) o ABORT (abortar): indica que la transacción termino sin éxito o que cualquier cambio en la base de datos se debe deshacer.

7. Diagrama que muestra el paso de una transacción por sus estados de ejecución

8. El diario del sistema Para recuperar los fallos de las transacciones, el sistema mantiene un diario que sigue la pista de todas las operaciones de transacciones que afectan a los valores de la base de datos. Esta información se puede ocupar para realizar la recuperación en caso de fallas.

9. Tipos de entradas denominadas registros del diario En entradas, T se refiere a un indicador de transacción único que el sistema genera automáticamente. • [start_transaction, T] • [write_item, T, X, valor_anterior, nuevo_valor] • [read_item, T, X] • [commit, T] • [abort, T]

10. Función de cadauno de los tipos de entradas • [start_transaction, T]: Indica que se ha iniciado la ejecución de la transacción T. • [write_item, T, X, valor_anterior, nuevo_valor]: Indica que la transacción T ha cambiado el valor del elemento de base de datos X del valor_anterior al nuevo_valor. • [read_item, T, X]: Registra que la transacción T leyó el valor del elemento X de la base de datos. • [commit, T]: Indica que la transacción T termino con éxito y establece que su efecto se puede confirmar (registrar permanentemente) en la base de datos. • [abort, T]: Indica que se abortó la transacción T.

11. Punto de confirmación de una transición • Una transacción T llega a un punto de confirmación cuando todas sus operaciones que tienen acceso a la base de datos se han ejecutado con éxito y el efecto de todas estas operaciones ha registrado en el diario.Es donde se dice que la transacción esta confirmada y se supone que su efecto se registró permanentemente en la base de datos. Propiedades deseables en las transacciones Para asegurar la integridad de los datos se necesita que el sistema de base de datos cumpla con las siguientes propiedades: • Atomicidad • Conservación de la consistencia • Aislamiento • Durabilidad o permanencia Estas se conocen como propiedades ACID.

12. En que cosiste cada una de las propiedades ACID • Atomicidad: Una transacción es una unidad atómica de procesamiento; o se realiza por completo o no se realiza en lo absoluto. • Conservación de la consistencia: Una transacción conserva la consistencia si su ejecución completa lleva la base de datos de un estado consistente a otro. • Aislamiento: Una transacción debería parecer que se está ejecutando de forma aislada de las demás transacciones. • Durabilidad o permanencia: los cambios aplicados a la base de datos por una transacción confirmada deben perdurar en la base de datos. Estos cambios no beben perderse por un fallo posterior.

13. Planes de transacción • Planes recuperables garantiza que, una vez confirmada la operación, nunca tendrá que anularse. • Planes sin cascada añaden una condición para asegurar que ninguna transacción abortada requerirá que otras transacciones se aborten en cascada. • Planes escritos proporcionan una condición a un más fuerte que permite un esquema de recuperación simple, el cual consiste en escribir los antiguos valores de los elementos que hayan sido modificados por una transacción abortada.

14. Planes (historias) de transacciones Planes de transacciones Secuencia de ejecución de las operaciones de varias operaciones con una posible intercalación. Para el objetivo de recuperación y control de concurrencia, estamos principalmente interesados en las operaciones de las transacciones read_item (leer­_elemento) y write_item (escribir_elemento), asi como las operaciones commit (confirmar) y abort (abortar).

15. Puntos que debe cumplir un plan completo Se dice que un plan P de n transacciones es un plan completo si se cumplen las siguientes condiciones: • Las operaciones de P son exactamente las operaciones de, incluidas una operación de confirmar (commit) o de abortar (abort) como última operación de cada transacción en el plan • Para cualquier plan de operaciones de la misma transacción su orden de aparición en P es el mismo que en su orden de aparición en . • Para dos operaciones cualesquiera en conflito, una de ellas debe ocurrir antes que la otra en el plan.

16. Soporte de transacciones en SQL Definición de transacción en SQL: es una unidad lógica de trabajo y garantiza que es atómica. Una única sentencia en SQL se considera siempre que es atómica, tanto si completa su ejecución sin errores como si falla y deja la base de datos sin modificar.

17. Sentencia explicita en SQL Con SQL no hay una sentencia explicita begin_transaction. El inicio de una transacción se realiza implícitamente cuando se encuentran determinadas sentencias de SQL. Sin embargo, toda translación ha de tener una sentencia explicita al final, que puede ser commit (confirmar) o ROLLBACK (deshacer o restaurar).

18. Características atribuidas a cada transacción Atoda transacción se le atribuyen ciertas características que se especifican con la sentencia SET TRANSACTION de SQL2. Estas características son: • El modo de acceso. • El tamaño del área de diagnóstico. • El nivel de aislamiento.

19. Características atribuidas a cada transacción • El modo de acceso puede especificarse como READ ONLY (solo lectura) o READ WRITE (leer y escribir). El valor por defecto es READ WRITE , a menos que se especifique el nivel de aislamiento de lectura no confirmada (READ UNCOMMITTED) • La opción de tamaño del área de diagnóstico, DIAGNOSTIC SIZE n, especifica un valor entero n, que indica el número de condiciones que puede tomar simultáneamente en el área de diagnóstico. • La opción de nivel aislamiento se especifica utilizando la sentencia ISOLATION LEVEL<aislamiento>, donde el valor para <aislamiento> puede ser READ UNCOMMITTED (lectura no confirmada), REPEATABLE READ (lectura repetible), o SERIALIZABLE (serializable).

20. Nivel de aislamiento más bajo que serializable Entonces pueden ocurrir una o más de las siguientes tres violaciones: Lectura sucia, lectura no repetible y fantasma. Se muestrara una tabla que resume violaciones posibles basadas en los niveles de aislamiento definidos en SQL

21. Ejemplo 1 EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL SET TRANSACTION READ WRITE // leer y escribir DIAGNOSTICS SIZE 5 // tamaño del área de diagnóstico ISOLATION LEVEL SERIALIZABLE // nivel aislamiento EXEC SQL INSERT INTO EMPLEADO (NOMBRE, LNOMBRE, NSS, DNO, SALARIO) // se realizaunainsersion en la tabla VALUES (‘robert’,’smith’, ‘9898979’, 2, 35000); EXEC SQL UPDATE EMPLEADO SET SALARIO = SALARIO * 1,1 WHERE DNO = 2; EXEC SQL COMMIT // confirmacion GOTO THE_END; UNDO: EXEC SQL ROLLBACK; //restaurar THE_END:…; //fianliza

22. Ejemplo 2 Controla el comportamiento del bloqueo y de las versiones de fila de las instrucciones Transact-SQL emitidas por una conexión a SQL Server. SET TRANSACTION ISOLATION LEVEL      { READ UNCOMMITTED //indica que no puede leer no confirmada  | READ COMMITTED     // indica que si se pudo leer  | REPEATABLE READ   // indica que la lectura se repite   | SNAPSHOT   //Especifica los datos leídos por cualquier instrucción de transacción   | SERIALIZABLE     } [ ;] // no permite violaciones que cuse lectura sucias

23. Conclusión Omar En estas diapositivas se muestra la definición de una transacción de una base de datos y las operaciones que intervienen en el procedimiento, además de que también es importante recalcar que es importante que las transacciones cumplan con las propiedades ACID. También se explicó diferentes tipos de fallos que se pueden presentar al momento de realizar la ejecución de las transacciones y se presentan los estados por los que dichas transacciones tiene que pasar durante su ejecución, posteriormente da una breve explicación de los métodos que se utilizan para los planes de recuperación información retomando los diferentes tipos de planes existentes. Se mostró cómo es que trabaja el diario de un sistema de base de datos el cual se almacena automáticamente y permite al usuario poder tener o extraer la información anterior de todas las transacciones, y para que toda loa información fuera comprendida una manera clara se realizó una tabla en donde se muestra las posibles violaciones basadas en los niveles de aislamiento definidos en SQL en la cual se pudo observar que si se indica una violación y que si no se indica una violación dicha tabla estaba basada en las tres violaciones principales como lectura sucia, lectura no repetible y fantasmas las cuales eran evaluadas de acuerdo a los niveles de aislamiento como lectura no confirmada, lectura confirmada, lectura repetible y serializable, y para comprender mejor toda la información y quedara clara de acuerdo a la forma de aplicar directamente se explicaron unos ejercicios realizados en SQL.

24. Conclusión Marco • En estas diapositivas las cuales contienen los principales conceptos detallados y en las cuales se explica los fundamentos y sintaxis que conforman la operación de transacciones. • Como tema principal en las diapositivas son las transacciones las cuales son definidas en estas diapositivas como una unidad de la ejecución de programas que acceden y actualizan varios datos dentro de un sistema por tal motivo es de gran utilidad entender el concepto como tal de transacciones para poder implementar las actualizaciones de las bases de datos y de esa manera poder realizar lo que las ejecuciones continuas y que las fallas de varios tipos que puedan ocurrir no dañen nuestra base de datos. • Por tal motivo es necesario que las transacciones cumplan con las propiedades como: atomicidad, consistencias, aislamiento y durabilidad estos conceptos son conocido como propiedades de ACID el nombres des de las iniciales de cada una de las propiedades. • Pero siempre ay que tener en mente que la ejecución recurrente de transacciones mejora la productividad y actualiza el sistema reduciendo el tiempo de espera de las transacciones. • Además de que cuando varias transacciones se ejecutan continuamente en la base de datos, puede que se deje de conservar la consistencia de los datos, por eso es muy necesario tener en cuenta que se deben de controlar la interacción entre las transacciones concurrentes. • Así también tenemos que tomar en cuenta cómo es que se mueve una transacción desde donde inicia hasta donde termina verificando cual es la secuencia que toma una transacción.

25. Referencias • Navathe, R. A. (2004). Fundamentos de Sistemas de Bases de Datos . Madrid (España): ADDISON WESLEY. • SUDARSHAN, S. K. (2006). FUNDAMENTOS DE BASE DE DATOS (quita edici{on).Aravaca (MAdrid): Mc Graw Hill.