INSTITUTO TECNOLGICO SUPERIOR CARRANZA

DE JESS

CARRERA: Ing. en sistemas computacionales MATERIA: Taller de base de datos INVESTIGACIN: UNIDAD5: Transacciones. DOCENTE:

PRESENTA:

Jess Carranza, ver. A

Noviembre de 2012

[UNIDAD5]

29 de noviembre de 2012

NDICE
PAGINA. INTRODUCCIN. ................................................................................................... 3 5.1 Conceptos Bsicos. ........................................................................................... 4 5.2 Propiedades de las Transaciones. .................................................................... 6 5.3 Grados de Consistencia. ................................................................................... 9 5.4 Niveles de Aislamiento. ................................................................................... 11 5.5 Commint y RollBack. ....................................................................................... 14 Conclusin............................................................................................................. 20 REFERENCIAS BIBLIOGRFICAS ...................................................................... 21

ITSJC | 2

[UNIDAD5]

29 de noviembre de 2012

INTRODUCCIN.
La gran cantidad de avances e innovaciones tecnolgicas que se produjeron en los ltimos aos tuvieron como resultado un cambio en la forma de observar a los sistemas de informacin, en general a las aplicaciones computacionales. Existen avances tecnolgicos que se realizan de forma constante en dispositivos de almacenamiento, circuitos, programas y metodologas. Dichos avances van de la mano junto con la demanda de los usuarios y programas para la explotacin de dichos dispositivos mejorados. Un rea en la cual las soluciones estn ocupando tecnologa con nuevas arquitecturas, es en la de los Sistemas distribuidos de informacin. Estos sistemas se refieren al manejo de datos almacenados en muchos Sitios ligados a travs de una red de comunicaciones. Un caso particular de estos sistemas distribuidos es lo que se conoce como base de datos distribuidas. En los sistemas de base de datos distribuidas se persigue la integracin de sistemas de base de datos diversos, no necesariamente homogneos para dar a los usuarios una visin global de la informacin disponible. Este proceso de integracin no implica la centralizacin de la informacin, mas bien, con la ayuda de la tecnologa de redes de computadoras la informacin se mantiene distribuida y los sistemas de bases de datos distribuidos permiten el acceso a ella como si estuviera localizada en un solo lugar. La distribucin de la informacin permite tener accesos rpidos a la misma, tener copias de la informacin para accesos ms rpidos y para tener respaldo en caso de fallas. Un sistema de base de datos distribuida es el resultado de la integracin de una base de datos distribuida con un sistema para su manejo.

ITSJC | 3

[UNIDAD5]

29 de noviembre de 2012

5.1 Conceptos Bsicos.

Desde el punto de vista del usuario la interaccin con la base de datos se lleva a cabo mediante operaciones con significado en el modelo semntico (por ejemplo, una transferencia de fondos en un banco). Desde el punto de vista de la base de datos estas operaciones pueden estar formadas por varias operaciones elementales (por ejemplo, quitar fondos de una cuenta y aadrselos a otra). Se llama Transaccin a una coleccin de operaciones que forman una unidad lgica de trabajo en una BD realizada por una o ms sentencias SQL estrechamente relacionadas. Una transaccin es una unidad de la ejecucin de un programa que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias operaciones de acceso a la base de datos. Una Transaccin est delimitada por instrucciones de inicio transaccin y fin transaccin (la transaccin consiste en todas las operaciones que se ejecutan entre inicio transaccin y fin transaccin). El concepto de transaccin se desarroll para atender los casos en los que el estado resultante de la base de datos depende del xito completo en una serie de operaciones. Este concepto vio la luz debido a que varias operaciones sucesivas pueden modificar el resultado de operaciones anteriores. En esos casos, si alguna operacin produce un error, el estado resultante puede ser indeterminado. Para solucionar este problema, las transacciones agrupan una serie de operaciones de manera que es posible garantizar la integridad del resultado final. O todas las operaciones se ejecutan con xito y se confirman (se escriben en la base de datos), o toda la transaccin se considera no realizada. La accin de cancelar una transaccin se denomina deshacer la transaccin. Deshacer una transaccin permite anular los cambios y recuperar el estado de la base de datos previo a la transaccin.

ITSJC | 4

[UNIDAD5]

29 de noviembre de 2012

Por ejemplo, en una transaccin bancaria automatizada, si un banco transfiere dinero desde la cuenta A a la cuenta B, la retirada de fondos de A y el depsito en B deben producirse con xito para procesar los fondos correctamente, de lo contrario la transaccin entera debe cancelarse. Esquematizando el proceso de transacciones tenemos: O se ejecutan todas las operaciones que componen la transaccin, o no se realiza ninguna.

En SQL

xito

Fracaso

Begin transacction Begin transacction

Instruccin Instruccin ... 1 2 Instruccin Instruccin ... 1 2

Commit work End transacction

Rollback work End transacction

ITSJC | 5

[UNIDAD5]

29 de noviembre de 2012

5.2 Propiedades de las Transaciones.

Una unidad lgica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades ACID (atomicidad,

coherencia, aislamiento

durabilidad), para ser calificacada como transaccin.

Atomicity: Una Transaccin (Tx) se ejecuta completamente de otra manera se

eliminan los cambios parciales realizados. Begin Transaction - Programa - End Transaction

Responsable: El mtodo de recuperacin, de no completar todas las operaciones,

devuelve la BD a su estado anterior a empezar esa Tx (Rollback).

Coherencia: Asegura que los datos que observamos no cambian (por otros usuarios)
hasta que acabemos la Transaccin. Despus de terminar una Transaccin la Base de datos no viola ninguna de sus reglas: valores obligatorios, claves nicas, etc.

Responsable: los programadores mediante la definicin adecuada de la integridad referencial: check, triggers, primary key, foreign key, Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se
confirmen. Una Transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.

Ms an, si varias transacciones, se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado secuencialmente. Esto se conoce como seriabilidad debido a que su resultado es la capacidad de volver a ITSJC | 6

[UNIDAD5]

29 de noviembre de 2012

cargar los datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban despus de realizar transacciones originales. Responsable: el mtodo de concurrencia: mecanismos, reglas, protocolos. Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas. Responsable: el mtodo o gestor de recuperacin. Inicio de transaccin Cuando no hay ya una transaccin en progreso, y se ejecuta una sentencia LDD o LMD (interactivamente o dentro de una aplicacin) Cada sentencia LDD es tratada como una transaccin N No existe sentencia de tipo BEGIN TRANSACTION Fin de transaccin

COMMIT: Finaliza la transaccin actual y hace permanentes (confirma) los cambios realizados ROLLBACK: Finaliza la transaccin actual y deshace los cambios realizados

Sentencia COMMIT

ITSJC | 7

[UNIDAD5]

29 de noviembre de 2012

Una sentencia COMMIT marca el final de una transaccin correcta, implcita o definida por el usuario. COMMIT hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transaccin sean parte permanente de la base de datos, y adems, libera los recursos mantenidos por la conexin. Su sintaxis es la siguiente:

COMMIT COMMENT 'mensaje' | FORCE 'texto']

COMMENT sirve para comentar la transaccin en un mximo 255 caracteres. FORCE fuera de modo manual una transaccin dudosa y es de uso exclusivo en sistemas distribuidos de base de datos.

Sentencia SAVEPOINT Esta sentencia permite crear un punto de restauracin dentro de una transaccin, es decir, un punto al que podremos retroceder deshaciendo todo lo hecho deshaciendo todo lo hecho desde l en adelante. Su sintaxis es la siguiente

SAVEPOINT nombre Punto Restauracin;

Sentencia ROLLBACK

Seala el final sin xito de una transaccin, elimina todas las modificaciones de datos realizadas desde el inicio de la transaccin y tambin libera los recursos que retiene la transaccin. Su sintaxis es la siguiente:

ITSJC | 8

[UNIDAD5]

29 de noviembre de 2012

ROLLBACK [WORK] [TO SAVEPOINT nombrePuntoRestauracin | FORCE

'texto'];

5.3 Grados de Consistencia.

Consistencia es un trmino ms amplio que el de integridad. Podra definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad tambin se pierde la consistencia. Pero la consistencia tambin puede perderse por razones de funcionamiento. Una transaccin 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 ejecucin de una transaccin 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 transaccin que termina con xito se dice que est comprometida (commited), una transaccin 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. En cualquier momento una transaccin slo puede estar en uno de los siguientes estados.

ITSJC | 9

[UNIDAD5]

29 de noviembre de 2012

Activa (Active): el estado inicial; la transaccin permanece en este estado durante su ejecucin. Parcialmente comprometida (Uncommited): Despus de ejecutarse la ltima transaccin. Fallida (Failed): tras descubrir que no se puede continuar la ejecucin normal. Abortada (Rolled Back): despus de haber retrocedido la transaccin y restablecido la base de datos a su estado anterior al comienzo de la transaccin. Comprometida (Commited): tras completarse con xito.

Aspectos relacionados al procesamiento de transacciones Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones:

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. Consistencia de la base de datos interna. Los algoritmos de control de datos semntico tienen que satisfacer siempre las restricciones de integridad cuando una transaccin pretende hacer un commit. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. As tambin, se requieren protocolos para la recuperacin local y para efectuar los compromisos (commit) globales. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecucin de transacciones concurrentes bajo el

ITSJC | 10

[UNIDAD5]

29 de noviembre de 2012

criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de rplicas. El control de rplicas se refiere a cmo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

5.4 Niveles de Aislamiento.

Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transaccin de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o ficticias. Control de los niveles de aislamiento de transaccin: Controla si se realizan bloqueos cuando se leen los datos y qu tipos de bloqueos se solicitan. Duracin de los bloqueos de lectura. Si una operacin de lectura que hace referencia a filas modificadas por otra transaccin: Se bloquea hasta que se libera el bloqueo exclusivo de la fila. Recupera la versin confirmada de la fila que exista en el momento en el que empez la instruccin o la transaccin. Lee la modificacin de los datos no confirmados. El nivel de aislamiento para una sesin SQL establece el comportamiento de los bloqueos para las instrucciones SQL. El estndar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en funcin de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:

ITSJC | 11

[UNIDAD5]

29 de noviembre de 2012

Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podra usarse una versin anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.

Lectura no repetible. Una transaccin vuelve a leer datos que previamente haba ledo y encuentra que han sido modificados o eliminados por una transaccin cursada. Lectura fantasma. Una transaccin vuelve a ejecutar una consulta, devolviendo un conjunto de registros que satisfacen una condicin de bsqueda y encuentra que otros registro que satisfacen la condicin han sido insertadas por otra transaccin cursada. Los niveles de aislamiento SQL son definidos basados en si ellos permiten a cada uno de los eventos definidos anteriormente. Es interesante notar que el estndar SQL no impone un esquema de cierre especfico o confiere por mandato comportamientos particulares, pero ms bien describe estos niveles de aislamiento en trminos de estos teniendo muchos mecanismos de

cierre/coincidencia, que dependen del evento de lectura.

Niveles de aislamiento: Comportamiento permitido

Lectura Nivel de aislamiento Sucia No repetible Fantasma

Lectura no comprometida

Lectura comprometida

No

S ITSJC | 12

[UNIDAD5]

29 de noviembre de 2012

Niveles de aislamiento: Comportamiento permitido

Lectura Nivel de aislamiento Sucia No repetible Fantasma

Lectura repetible

No

No

Secuenciable

No

No

No

Segn el estndar SQL 1992, SQL Server y MySQL permiten todos estos niveles, Oracle slo permite la lectura comprometida y Secuenciable. Los niveles se pueden establecer en ambos para cada transaccin. Sin embargo esto no es necesariamente cierto. El estndar SQL trataba de establecer los niveles de aislamiento que permitiran a varios grados de consistencia para querys ejecutadas en cada nivel de aislamiento. Las lecturas repetibles "REPEATABLE READ" es el nivel de aislamiento que garantiza que un query un resultado consistente. En la definicin SQL estndar, la lectura comprometida "READ COMMITTED" no regresa resultados consistentes, en la lectura no comprometida "READ UNCOMMITTED" las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podra usarse una versin anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento. A mayor grado de aislamiento, mayor precisin, pero a costa de menor concurrencia.

ITSJC | 13

[UNIDAD5]

29 de noviembre de 2012

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

5.5 Commint y RollBack.

Ejemplo bsico en MySQL precio del dolar con respecto al peso 1995 al 2012.

1 2 3 4 5

CREATE TABLE IF NOT EXISTS dolar ( fecha DATE, precio DECIMAL (8,4), PRIMARY KEY (fecha) ) ENGINE = InnoDB DEFAULT CHARSET=latin1;

Considere la siguiente informacin

Fecha

Precio

2012/02/01 13.0077

2012/02/02 12.8900

ITSJC | 14

[UNIDAD5]

29 de noviembre de 2012

Fecha

Precio

2012/02/03 12.8038

2012/02/07 12.7120

2012/02/08 12.6472

2012/02/09 12.6833

2012/02/10 12.7200

Lecturas consistentes Por default, las tablas InnoDB ejecutan un lectura consistente (consistente read). Esto significa que cuando una sentencia SELECT es ejecutada, MySQL regresa los valores presentes en la base de datos hasta la transaccin ms reciente que ha sido completada. Si alguna transaccin est en progreso, los cambios hechos por alguna sentencia INSERT o UPDATE no sern reflejados. Sin embargo, existe una excepcin: las transacciones abiertas si pueden ver sus propios cambios. Para demostrar esto, necesitamos establecer dos conexiones al servidor MySQL. Observe el caso feliz de las transacciones. Sin violaciones de integridad referencial o otra clase de errores

Cliente 1

Cliente 2

ITSJC | 15

[UNIDAD5]

29 de noviembre de 2012

SET AUTOCOMMIT = 0 SET AUTOCOMMIT = 0 INSERT INTO VALUES('2012-02-01',

13.0077);

dolar 12.7120);

INSERT INTO VALUES('2012-02-07', INSERT INTO VALUES('2012-02-08', INSERT INTO VALUES('2012-02-09', INSERT INTO VALUES('2012-02-10',

dolar

dolar

INSERT INTO VALUES('2012-02-02',

12.8900);

dolar 12.6472);

dolar

INSERT INTO VALUES('2012-02-03',

12.8038); fecha >= '2012/02/01';

dolar 12.6833);

dolar

SELECT * FROM dolar WHERE 12.7200);

SELECT * FROM dolar WHERE

fecha >= '2012/02/01';

COMMIT;

SELECT * FROM dolar WHERE fecha

>= '2012/02/01';

ITSJC | 16

[UNIDAD5]

29 de noviembre de 2012

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 actualizacin en disco. Si usa tablas transaccionales (como InnoDB o BDB), puede desactivar el modo autocommit con el siguiente comando: SET AUTOCOMMIT = 0; Tras deshabilitar el modo autocommit poniendo la variable AUTOCOMMIT a cero, debe usar COMMIT para almacenar los cambios en disco o ROLLBACK si quiere ignorar los cambios hechos desde el comienzo de la transaccin.

START TRANSACTION

El siguiente cdigo crea una tabla InnoDB de nombre resumen;

1 2 3

CREATE TABLE resumen ( year INTEGER, mes INTEGER,

ITSJC | 17

[UNIDAD5]

29 de noviembre de 2012

4 5 6

promedio DECIMAL(8,4), PRIMARY KEY (year, mes) )engine = innodb;

Cliente 1

Cliente 2

START TRANSACTION; SELECT @prom:= AVG(precio) FROM

dolar

WHERE
=

YEAR(fecha) 2011 AND INTO VALUES FROM

MONTH(fecha) = 1; INSERT
resumen (2011, 1, @prom);

SELECT
resumen;

SELECT @prom:= AVG(precio) FROM dolar WHERE YEAR(fecha)

= 2011

AND

ITSJC | 18

[UNIDAD5]

29 de noviembre de 2012

MONTH(fecha) = 2; INSERT INTO resumen VALUES (2011, 2,

@prom);

SELECT * FROM resumen;

SELECT
resumen;

FROM

COMMIT; SELECT * FROM resumen;

SELECT
resumen;

FROM

ITSJC | 19

[UNIDAD5]

29 de noviembre de 2012

Conclusin.
Una transaccin es una coleccin 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 informacin. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecucin de una transaccin, 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 ejecucin de una transaccin.

ITSJC | 20

[UNIDAD5]

29 de noviembre de 2012

REFERENCIAS BIBLIOGRFICAS
http://www.itescam.edu.mx/principal/sylabus/763820.php?nombreCarrera=Ingenier %EDa+en+Sistemas+Computacionales http://es.scribd.com/doc/72783799/Unidad-1-Taller-de-Base-de-Datos http://tallerbdd.es.tl/Unidad-1.htm http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r82687.DOCX http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?clave_a sig=AEF-1031&carrera=ISIC-2010-224&id_d=136

ITSJC | 21