TECNOLOGICO NACIONAL DE MEXICO

CAMPUS TUXTEPEC

ASIGNATURA:
Taller de Base de Datos
CARRERA:
Ingeniera en Sistemas Computacionales
SEMESTRE: 5to.

GRUPO: A

CATEDRATICO:
M.S.C Mara Luisa Acosta Sanjun
TRABAJO:
Transacciones
UNIDAD:
V
PRESENTA:
Castellanos Rodrguez Oscar
No. de control:
12350180

29 de Noviembre del 2014, San Juan Bautista Tuxtepec, Oaxaca

ndice General.
Introduccin3
5.1 Conceptos Bsicos.4
5.2 Propiedades de las transacciones5
5.3 Grados de Consistencia.6
5.4 Niveles de aislamiento8
5.5 Commit & Rollback11
Conclusin.14
Bibliografa.15

ndice de Figuras
Figura 1: Diagrama de transaccin de estados.7
Figura 2: Niveles de aislamiento.11
Figura 3: Ejemplo utilizando Begin & Commit..13
Figura 4: Ejemplo utilizando Begin, Commit & Roll
Back.13

INTRODUCCION.
Qu es una Transaccin?
El trmino transaccin hace referencia a un conjunto de operaciones que forman
una nica unidad lgica de trabajo. Por ejemplo, la transferencia de dinero de una
cuenta a otra es una transaccin que consta de dos actualizaciones, una para cada
cuenta.

Resulta importante que, o bien se ejecuten completamente todas las acciones de

una transaccin, o bien, en caso de fallo, se deshagan los efectos parciales de la
transaccin. Esta propiedad se denomina atomicidad. Adems, una vez ejecutada
con xito una transaccin, sus efectos deben persistir en la base de datos: un fallo
en el sistema no debe tener como consecuencia que la base de datos se olvide de
una transaccin que haya completado con xito. Esta propiedad se denomina
durabilidad.

En los sistemas de bases de datos en los que se ejecutan de manera concurrente

varias transacciones, si no se controlan las actualizaciones de los datos compartidos
existe la posibilidad de que las transacciones vean estados intermedios
inconsistentes creados por las actualizaciones de otras transacciones. Esta
situacin puede dar lugar a actualizaciones errneas de los datos almacenados en
la base de datos. Por tanto, los sistemas de bases de datos deben proporcionar los
mecanismos para aislar las transacciones de otras transacciones que se ejecuten
de manera concurrente. Esta propiedad se denomina aislamiento. (Abraham
Silberschatz)

5.1 Conceptos Bsicos.

Se llama transaccin a una coleccin de operaciones que forman una nica unidad
lgica de trabajo. Un sistema de base de datos debe asegurar que la ejecucin de
las transacciones se realice adecuadamente a pesar de la existencia de fallos: o se
ejecuta la transaccin completa o no se ejecuta en absoluto. Adems debe gestionar
la ejecucin concurrente de las transacciones evitando introducir inconsistencias.
Otra definicin de Transaccin es una coleccin de operaciones que forman una
unidad lgica de trabajo en una BD realizada por una o ms sentencias SQL
estrechamente relacionadas.
Al ligual que una transaccin es una unidad de la ejecucin de un programa que
accede y posiblemente actualiza varios elementos de datos. Una transaccin se
inicia por la ejecucin de un programa de usuario escrito en un lenguaje de
manipulacin de datos de alto nivel o en un lenguaje de programacin (por ejemplo
SQL, COBOL, C, C++ o Java), y est delimitado por instrucciones (o llamadas a
funcin) de la forma inicio transaccin y fin transaccin. La transaccin consiste
en todas las operaciones que se ejecutan entre inicio transaccin y el fin
transaccin. (Abraham Silberschatz).

Una transaccin es una unidad lgica de trabajo de la base de datos. Puede tratarse
de un programa completo, de una parte del programa o de un nico comando (por
ejemplo, el comando SQL INSERT o UPDATE) y puede implicar un nmero
arbitrario de operaciones con la base de datos.(Connolly & Begg)

Una transaccin es una unidad de trabajo lgica que comprende por lo regular
varias operaciones de base de datos. En la cual el usuario debe ser capaz de
informar al sistema cuando haya operaciones distintas que forman parte de la
misma transaccin.(C.J. Date)

5.2 PROPIEDADES DE LAS TRANSACCIONES.

Para asegurar la integridad de los datos se necesita que el sistema de base de datos
mantenga las siguientes propiedades de las transacciones.
Estas propiedades a menudo reciben el nombre de propiedades ACID; el acrnimo
se obtiene de la primera letra de cada una de las cuatro propiedades en ingls
(Atomicity, Consistency, Isolation y Durability, respectivamente). (Abraham
Silberschatz).

Atomicidad. Todas las operaciones de la transaccin se realizan adecuadamente

en la base de datos o ninguna de ellas. (Abraham Silberschatz).

Consistencia. Las transacciones conservan la consistencia de la base de datos.

Es decir, una transaccin transforma un estado consistente de la base de datos en
otro igual, sin necesidad de conservar la consistencia en todos los puntos
intermedios. (C.J. Date)
Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el
sistema garantiza que para cada par de transacciones Ti y Tj, se cumple que para
los efectos de Ti, o bien Tj ha terminado su ejecucin antes de que comience Ti , o
bien que Tj ha comenzado su ejecucin despus de que Ti termine. De este modo,
cada transaccin ignora al resto de las transacciones que se ejecuten
concurrentemente en el sistema. (Abraham Silberschatz).

Durabilidad. Tras la finalizacin con xito de una transaccin, los cambios

realizados en la base de datos permanecen, incluso si hay fallos en el sistema.
(Abraham

Silberschatz).

5.3 GRADOS DE CONSISTENCIA

Consistencia es un trmino ms amplio que el de integridad, la cual 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.( Raghu & Gehrke)
Una transaccin finalizada 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.
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. .( Raghu & Gehrke)
Activa, el estado inicial; la transaccin permanece en este estado durante su
ejecucin. (Abraham Silberschatz).

Parcialmente comprometida, despus de ejecutarse la ltima instruccin.

(Abraham

Silberschatz).

Fallida, tras descubrir que no puede continuar la ejecucin normal.

(Abraham

Silberschatz).

Abortada, despus de haber retrocedido la transaccin y restablecido la

base de datos a su estado anterior al comienzo de la transaccin. (Abraham
Silberschatz).
Comprometida, tras completarse con xito. (Abraham Silberschatz).

Fig.1 Diagrama de transicin de estados

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. .( Raghu &
Gehrke)
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 criterio de correctitud. La consistencia entre transacciones se
garantiza mediante el aislamiento de las mismas. .( Raghu & Gehrke)
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). .( Raghu & Gehrke).

5.4 NIVELES DE AISLAMIENTO

Utilizamos el trmino nivel de aislamiento para referirnos a lo que podra ser
descrito vagamente como el grado de interferencia que una transaccin dada es
capaz de tolerar por parte de las transacciones concurrentes. Entonces, si
queremos garantizar la seriabilidad, no podemos aceptar ninguna cantidad de
interferencia!; en otras palabras, el nivel de aislamiento debe ser el mximo posible.
Sin embargo, como indiqu al final de la seccin anterior, los sistemas reales
comnmente permiten que las transacciones operen a niveles de aislamiento que
son menores a este mximo, por una diversidad de razones pragmticas. (C.J.
Date)

Como lo sugiere el prrafo anterior, el nivel de aislamiento es visto generalmente

como una propiedad de las transacciones. De hecho, no hay razn por la cual una
transaccin no deba operar simultneamente a niveles diferentes de aislamiento en
distintas partes de la base de datos, al menos en principio. Sin embargo, por
simplicidad, continuaremos pensando en el nivel de aislamiento como una
propiedad de toda la transaccin. (C.J. Date)

Podemos definir al menos, cinco niveles de aislamiento, pero el SQL estndar

definen solamente cuatro, mientras que el DB2 slo soporta dos actualmente. En

trminos generales, entre mayor sea el nivel de aislamiento, menor ser la

interferencia (y menor la concurrencia); y entre ms bajo sea el nivel de aislamiento,
mayor ser la interferencia (y mayor la concurrencia). Como ejemplo
consideraremos los dos niveles soportados por DB2, que son llamados estabilidad
de cursor y lectura repetible, respectivamente. La lectura repetible (RR) es el nivel
mximo. Si todas las transacciones operan a este nivel, todos los planes son).
Por el contrario, bajo la estabilidad de cursor (CS), si una transaccin TI. (C.J. Date)
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:
o Se bloquea hasta que se libera el bloqueo exclusivo de la fila.
o Recupera la versin confirmada de la fila que exista en el momento en el
que empez la instruccin o la transaccin.
o Lee la modificacin de los datos no confirmados. (Post, Gerald V)

Los niveles

posibles

son

READ

UNCOMMITTED,

READ

COMMITTED,

REPEATABLE READ o SERIALIZABLE.*

El nivel predeterminado es SERIALIZABLE, ya que si se especifica alguno de los

otros tres, la implementacin tiene la libertad de asignar algn nivel superior (en
donde "superior" est definido en trminos del ordenamiento SERIALIZABLE >
REPEATABLE READ > READ COMMITTED > READ UNCOMMITTED). (C.J. Date)

Lectura sucia. Supongamos que la transaccin TI realiza una actualizacin

sobre alguna fila, luego la transaccin T2 recupera esa fila y la transaccin
TI termina con una instruc cin deshacer. Entonces, la transaccin T2 ha

visto una fila que ya no existe, y que en cierto sentido nunca existi (debido
a que la transaccin TI efectivamente nunca fue ejecutada). (C.J. Date)

Lectura no repetible. Supongamos que la transaccin TI recupera una fila,

luego la tran saccin T2 actualiza esa fila y despus la transaccin TI
recupera nuevamente la "misma" fila. La transaccin TI ha recuperado la
"misma" fila dos veces, pero ve dos valores diferen tes en ella. (C.J. Date)

Fantasmas. Supongamos que la transaccin TI recupera el conjunto de

todas las filas que satisfacen alguna condicin (por ejemplo, todas las filas
de proveedores que satisfacen la condicin de que la ciudad es Pars).
Supongamos que la transaccin 72 inserta entonces una nueva fila que
satisface la misma condicin. Si la transaccin TI repite ahora su peti cin de
recuperacin, ver una fila que antes no exista, un "fantasma".(C.J. Date)
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. (Post, Gerald V)

Fig 2. Niveles de aislamiento

10

Segn el estndar SQL, SQL Server y MySQL permiten todos estos niveles. Los
niveles se pueden establecer en ambos para cada transaccin. Sin embargo esto
no es necesariamente cierto. (Post, Gerald V)
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. .( Raghu & Gehrke)

5.5 COMMIT & ROLLBACK

En la norma SQL se especifica el comienzo de una transaccin explcitamente. Las
transacciones se terminan con una de las instrucciones SQL siguientes:
La primera sentencia para llevar a cabo una transaccin es el Commit, el cual
compromete la transaccin actual y comienza una nueva.
Si todas las operaciones de una transaccin se completan con xito hay que marcar
el fin de una transaccin para que la base de datos vuelva a estar en un estado
consistente con la sentencia ya mencionada.
Como ya se mencion anteriormente, una sentencia COMMIT en SQL finaliza una
transaccin 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 ms sentencias SQL, y
entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se

11

puede emitir, la cual deshace todo el trabajo realizado desde que se emiti BEGIN
WORK. (Abraham Silberschatz).

La sentencia Rollback Provoca que la transaccin actual aborte, si alguna de las

operaciones de una transaccin falla hay que deshacer la transaccin en su
totalidad para volver al estado inicial en el que estaba la base de datos antes de
empezar. Esto se consigue con la sentencia ROLLBACK TRAN. (Abraham
Silberschatz).
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 gestin 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. .(C.J. Date)

Y con esta sentencia podemos ejecutar 2 operaciones:

Reiniciar la transaccin
pero slo si la transaccin se ha abortado a causa de algn error hardware o
software que no lo haya provocado la lgica interna de la transaccin. Una
transaccin

reiniciada

se

considera

una

nueva

transaccin.

(Abraham

Silberschatz).

Cancelar la transaccin.
Normalmente se hace esto si hay algn error interno lgico que slo se puede
corregir escribiendo de nuevo el programa de aplicacin, o debido a una entrada
incorrecta o debido a que no se han encontrado los datos deseados en la base de
datos (Abraham Silberschatz).

Ejemplos:

12

Fig.3 Ejemplo utilizando Begin & Commit

Fig.3 Ejemplo utilizando Begin , Commit & Rollback.

13

CONCLUSIN
Transacciones, es un concepto un poco fcil de entender ya que tiene mltiples
conceptos, pero es esta caso como nos enfocamos solo a las bases de datos y
como vimos las transacciones no son mas que procesos en los cuales podemos
insertar, eliminas y hacer un monton de operaciones en las bases de datos y en
sus tablas sin importar que contengan llaves forneas o primarias.
Y tambin sus propiedades las cuales son de gran importancia, ya que in ellas el
concepto de transaccin no seria muy entendible ni sus operaciones que se
realian con ellas.

14

BIBLIOGRAFIA.
Post, Gerald V. (2006). Sistemas de administracin para bases de datos.
1era. Edicin. Mxico
Raghu Ramakrishnan, Johanes Gehrke. (2007) Sistemas de gestin de
bases de datos. 3er. edicin. Mc. Graw-Hill
Silberschatz, Korth & Sudarshan. (2002). Fundamentos de Base de Datos.
Mc Graw Hil. Cuarta Edicin. Espaa.
Connolly M, Thomas, Begg E. Caroly. (2005) Sistemas de bases de datos.
Pretence Hall. Madrid, Espaa.
C J, Date (2000) Introduccin a los sistemas de base de datos. Pretence Hall.
Septima edicin. Mexico

15