Transacciones
Upcoming SlideShare
Loading in...5
×
 

Transacciones

on

  • 1,216 views

 

Statistics

Views

Total Views
1,216
Views on SlideShare
1,212
Embed Views
4

Actions

Likes
2
Downloads
60
Comments
0

1 Embed 4

https://www.facebook.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Transacciones Transacciones Presentation Transcript

    • INSTITUTO TECNOLÓGICO DE CIUDAD MADERO Transacciones Unidad 5 Dase de Datos
    • EQUIPO 4 Integrantes: Gema Patricia Galicia Santos Daniel Antonio Cruz Manuel Cruz Díaz
    • 5.1 CONCEPTOS BÁSICOS Transacción La transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
    • TRANSACCIÓN Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicación, que acceden o cambian el contenido de la base de datos.
    • Transacción Ejemplo Las transacciones representan eventos del mundo real, como:
    • Las características que se debe recoger de cada transacción son las siguientes: 1. Datos que utiliza la transacción. 2. Características funcionales de la transacción. 3. Salida de la transacción. 4. Importancia para los usuarios. 5. Frecuencia de utilización.
    • Hay tres tipos de transacciones: 1. En las transacciones de recuperación se accede a los datos para visualizarlos en la pantalla a modo de informe. 2. En las transacciones de actualización se insertan, borran o actualizan datos de la base de datos. 3. En las transacciones mixtas se mezclan operaciones de recuperación de datos y de actualización.
    • 5.2 PROPIEDADES DE LAS TRANSACCIONES Las transacciones deben cumplir cuatro propiedades ACID: 1. 2. 3. 4. Atomicidad (Atomicity) Consistencia (Consistency) Aislamiento (Isolation) Permanencia (Durability):
    • Propiedades de las Transacciones 1. Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias. 2. Consistencia (Consistency): es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.
    • Propiedades de las Transacciones 3. Aislamiento (Isolation): es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información nunca generará ningún tipo de error. 4. Permanencia (Durability): es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema. Nota: Si la transacción no se puede finalizar por cualquier motivo, el SGBD garantiza que los cambios realizados por esta transacción son deshechos
    • ESTADOS DE UNA TRANSACCIÓN • En cualquier momento una transacción sólo puede estar en uno de los siguientes estados. 1. Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución. 2. Parcialmente comprometida (Uncommited): Después de ejecutarse la ultima transacción. 3. Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal. 4. Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción. 5. Comprometida (Commited): tras completarse con éxito.
    • Diagrama de estados de una transacción:
    • 5.3 GRADOS DE CONSISTENCIA Consistencia es un término más amplio que el de integridad. Podría definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia. Pero la consistencia también puede perderse por razones de funcionamiento.
    • 5.3 GRADOS DE CONSISTENCIA • Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse. Por consistente se debe entender, internamente consistente. • Consistencia de datos: Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes.
    • 5.3 GRADOS DE CONSISTENCIA En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen: • Todos los valores de la llave primaria son únicos. • La base de datos mantiene integridad referencial lo que significa que los registros solo referencian información que existe. • Ciertos predicados se mantienen. Por ejemplo, la suma de los gastos es menor o igual al presupuesto. • A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una práctica de programación. La atomicidad, el aislamiento y la durabilidad están aseguradas estén o no programadas para preservar la consistencia. Es responsabilidad del desarrollador de la aplicación asegurar que su programa preserva la consistencia.
    • 5.3 GRADOS DE CONSISTENCIA Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia). • Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos. • Si se anula los cambios que ha efectuado son deshechos. La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de integridad definidas). • Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos. • Si se anula los cambios que ha efectuado son deshechos.
    • Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema
    • 5.4 Niveles de Aislamiento
    • ¿Qué es Aislamiento? • En bases de datos, el aislamiento es una propiedad que define cómo y cuándo los cambios producidos por una operación se hacen visibles para las demás operaciones concurrentes. Aislamiento es una de las 4 propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) aplicables a una base de datos transaccional.
    • Niveles de Aislamiento • De las cuatro propiedades ACID de un Sistema de gestión de bases de datos relacionales (SGBDR) la de aislamiento es la que más frecuentemente se relaja. Para obtener el mayor nivel de aislamiento, un SGBDR generalmente hace un bloqueo de los datos o implementa un Control de concurrencia mediante versiones múltiples (MVCC), lo que puede resultar en una pérdida de concurrencia. Por ello se necesita añadir lógica adicional al programa que accede a los datos para su funcionamiento correcto
    • SERIALIZABLE • Este es el nivel de aislamiento más alto. Especifica que todas las transacciones ocurran de modo aislado, o dicho de otro modo, como si todas las transacciones se ejecutaran de modo serie (una tras otra). La sensación de ejecución simultánea de dos o más transacciones que perciben los usuarios sería una ilusión producida por el SGBD.
    • LECTURAS COMPROMETIDAS (READ COMMITTED) • En este nivel de aislamiento, un SGBDR que implemente el control de concurrencia basado en bloqueos mantiene los bloqueos de escritura -de los datos seleccionados hasta el final de la transacción, mientras que los bloqueos de lectura se cancelan tan pronto como acaba la operación de SELECT (por lo que el efecto de las lecturas no repetibles puede ocurrir, como se explica más abajo). Al igual ocurría en el nivel anterior, no se gestionan los bloqueos de rango.
    • LECTURAS NO COMPROMETIDAS (READ UNCOMMITTED) • Este es el menor nivel de aislamiento. En él se permiten las lecturas sucias(ver más abajo), por lo que una transacción pude ver cambios no cometidos aún por otra transacción.
    • Nivel de aislamiento por defecto • El nivel de aislamiento por defecto de distintos SGBDR varía ampliamente. La mayoría de bases de datos que gestionan transacciones permiten al usuario establecer cualquier nivel de aislamiento. Algunos SGBDR requieren sintaxis especial cuando se realiza una operación SELECT que efectúa bloqueos (e.g.SELECT ... FOR UPDATE para bloquear para escritura aquéllas filas accedidas)
    • 5.5 Commit y Rollback
    • ¿Qué es commit? • En el contexto de la Ciencia de la computación y la gestión de datos, commit(acción de comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no permanentes". Un uso popular es al final de una transacción de base de datos.
    • Una sentencia COMMIT • En SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitió BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los savepoints (puntos de recuperación) existentes que puedan estar en uso.
    • Nota: • En términos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transacción, es un rollback.
    • ¿Qué es rollback? • En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. • Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.
    • • En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.
    • Ejemplo: Transacciones
    • 5.5 COMMIT Y ROLLBACK • COMMIT Esta instrucción de SQL se utiliza para confirmar como permanentes las modificaciones realizadas en una transacción. • Begin tran Insert into Mvtos Values (‘0150’, ‘Dep’, 1500, ’08-10-2008’) Insert into Mvtos Values (‘7120’, ‘Ret’, 1500, ’08-10-2008’) Update Cuentas Set Saldo = Saldo + 1 where Numero = ‘0150’ Update Cuentas Set Saldo = Saldo – 1 Where Numero = ‘7120’ • Commit tran Con la instrucción commit tran se pone una marca para saber hasta que punto se hizo la transacción.
    • • Por defecto, MySQL se ejecuta con el modo autocommit activado. Esto significa que en cuanto ejecute un comando que actualice (modifique) una tabla, MySQL almacena la actualización en disco. • Desactiva el comando autocommit SET AUTOCOMMIT=0; • Tras deshabilitar el modo autocommit debe usar COMMIT para almacenar los cambios en disco o ROLLBACK si quiere ignorar los cambios hechos desde el comienzo de la transacción. Si quiere deshabilitar el modo autocommit para una serie única de comandos, puede usar el comando START TRANSACTION: • START TRANSACTION; • SELECT @A:=SUM(salary) • FROM table1 • WHERE type=1; • UPDATE table2 SET summary=@A WHERE type=1; • COMMIT; • Con START TRANSACTION, autocommit permanece deshabilitado hasta el final de la transacción con COMMIT o ROLLBACK. El modo autocommit vuelve a su estado previo.
    • • • • • • • Veremos un ejemplo completo, donde utilizaremos START TRANSACTION (no es necesario AUTOCOMMIT en 0) CREATE TABLE `departamentos` ( `CODIGO` INTEGER(11) NOT NULL DEFAULT ’0′, `NOMBRE` VARCHAR(100), `PRESUPUESTO` INTEGER(11) DEFAULT NULL, PRIMARY KEY (`CODIGO`) )ENGINE=InnoDB Ahora, insertaremos registros de la tabla departamentos_externos a departamentos mediante una transacción: START TRANSACTION; SELECT @A := presupuesto FROM departamentos_externos WHERE código =11; INSERT INTO departamentos( código, nombre, presupuesto ) VALUES ( 11, ‘Department test’, @A ); COMMIT; // para aceptar la transaccion ó ROLLBACK;//si quieres cancelar la transaccion En el ejemplo anterior se guardo el presupuesto del departamento externo 11 en la variable @A y luego fue asignado al presupuesto en la tabla departamentos. Al realizar una transacción SQL hay que tener en cuenta que apenas se realice un INSERT, UPDATE o DELETE se genera un bloqueo sobre la tabla y que otros clientes no pueden acceder para escribir esta tabla. Otros clientes podrán realizar SELECTs sobre la tabla, pero no podrán ver los datos del primer cliente hasta que los mismos sean confirmados.
    • ROLLBACK • Esta función del SQL se utiliza para deshacer todas las modificaciones realizadas desde la última confirmación. • Ejemplo Begin tran <Comandos SQL> <Comandos SQL> Save tran Puntoseg <Comandos SQL> <Comandos SQL> If @@ERROR <> 0 Rollback tran Puntoseg (cancela todo desde aquí hasta el punto de guardado) Else Commit tran
    • • Veamos un ejemplo. • Disponemos de la tabla EMPLE, que está formada por los campos que se muestran en la imagen.
    • • A continuación comenzamos una • transacción con START TRANSACTION. Modificamos el salario de todos los empleados de la tabla EMPLE, con la siguiente sentencia SQL. update emple set salario=1000;
    • • Y comprobamos a continuación que la tabla vuelve a su estado original.  Si queremos validar los cambios en la base de datos, completaremos la transacción con el uso de la sentencia COMMIT. Si ejecutamos ROLLBACK justo después de hacer el COMMIT, los cambios realizados sobre la base de datos permanecerán, debido a que anteriormente se validó la transacción, así que una ves utilizada la sentencia COMMIT ya no puedes usar ROLLBACK.
    • • Observamos a continuación que se ha modificado el salario de todos los empleados  Deshacemos el trabajo ya que nos hemos equivocado. Para ello utilizamos la sentencia ROLLBACK.
    • Comandos Utilizados
    • Comandos Utilizados
    • Comandos Utilizados
    • Comandos Utilizados
    • Comandos Utilizados
    • Comandos Utilizados
    • Comandos Utilizados
    • Bibliografía: • • • • • • http://es.wikipedia.org/wiki/ACID http://es.wikipedia.org/wiki/Transacci%C3%B3n_(base_de_datos) http://www.fdi.ucm.es/profesor/fernan/dbd/apuntestema07.pdf http://www.paginasprodigy.com.mx/evaristopacheco/taller/Grados Consistencia.html http://es.wikipedia.org/wiki/Rollback http://www.slideshare.net/nicola51980/postgresql-leccin-8manipulando-datos-y-transacciones