República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria

Universidad Politécnica Territorial del Estado Bolívar
Administración de Base de Datos
T10-INF-1

Manejo de transacciones

Profesora: Estudiantes:

Luzmeidy Bravo Alexander Serrano (26.851.230

Nelson Figuera (28.342.503)

Ciudad Bolívar, julio de 2021.

 Introducción

El concepto de transacción es algo amplio y está presente tanto en

sistemas centralizados como en sistemas distribuidos, el concepto de
“sistema distribuido” no debe ser confundido asumiendo que es cualquier
sistema que no sea el ordenador central, el uso correcto de
la transaccionalidad ayuda a garantizarla consistencia de la información y
minimiza los bloqueos de datos maximizando la concurrencia de los
procesos.
De esta manera da paso al siguiente tema que es la concurrencia, el
término concurrencia se refiere al hecho de que los DBMS (Sistemas de
Administración de Bases de Datos) permiten que muchas transacciones
accedan a una misma base de datos a la vez, en un sistema de éstos se
necesita algún tipo de mecanismo de control de concurrencia para
asegurar que las transacciones concurrentes no interfieran entre sí.
La confiabilidad es otro requerimiento indiscutible y probablemente el
más importante. Una base de datos no confiable es simplemente
inutilizable. Para la mayoría de las aplicaciones, en especial las
empleadas en sistemas de tiempo real, la confiabilidad es una propiedad
no negociable que deben tener todos los componentes.
Un sistema de manejo de bases de datos confiable es aquel que puede
continuar procesando las solicitudes de usuario aun cuando el sistema
sobre el que opera no es confiable. En otras palabras, aun cuando los
componentes de un sistema distribuido fallen, un DDMBS confiable debe
seguir ejecutando las solicitudes de usuario sin violar la consistencia de la
base de datos.

3
 Manejo de transacciones

Una 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.

Un SGBD es llamado transaccional, si es capaz de mantener la

integridad de los datos, haciendo que estas transacciones no puedan
finalizar en un estado intermedio. Cuando por alguna causa el sistema
debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas
hasta dejar la base de datos en su estado inicial (llamado punto de
integridad), como si la orden de la transacción nunca se hubiese
realizado.

Para esto, el lenguaje de consulta de datos SQL (Structured Query

Language), provee los mecanismos para especificar que un conjunto
de acciones deben constituir una transacción.

 BEGIN TRAN: especifica que va a empezar una transacción.

 COMMIT TRAN: le indica al motor que puede considerar la

transacción completada con éxito.

 ROLLBACK TRAN: indica que se ha alcanzado un fallo y que debe

restablecer la base al punto de integridad.

En un sistema ideal, las transacciones deberían garantizar todas las

propiedades ACID; en la práctica, a veces alguna de estas propiedades
se simplifica o debilita con vistas a obtener un mejor rendimiento.

Por ejemplo, en una transacción bancaria automatizada, si un banco

transfiere dinero desde la cuenta A a la cuenta B, la retirada de fondos de
A y el depósito en B deben producirse con éxito para procesar los fondos
correctamente, de lo contrario la transacción entera debe cancelarse.

Esquematizando el proceso de transacciones: O se ejecutan todas las

operaciones que componen la transacción, o no se realiza ninguna.
 En SQL
Éxito Fracaso
Begin transacction Begin transacction
Instrucción 1 Instrucción 1
Instrucción 2 Instrucción 2
... ...
Commit workEnd Rollback workEnd
transacction transacction

Propiedades de una transacción

Las transacciones sobre la base de datos deben ajustarse al
principio ACID (ATOMIC + CONSISTENT + ISOLATED +
DURABLE), lo que implica que una transacción debe ser:
ATÓMICA (ATOMIC): Todas las operaciones que componen la
transacción deben aplicarse sobre la base de datos o no aplicarse
ninguna. Una transacción es indivisible.

CONSISTENTE (CONSISTENT): Se mantiene la consistencia de

los datos antes y después de ejecutar la transacción.

AISLADA (ISOLATED): Cuando muchas transacciones se

pueden llevar a cabo simultáneamente por uno o varios usuarios, la
realización de una no debe afectar jamás a las otras y por tanto no
llevar a una situación de error.
 PERMANENTE (DURABLE): Una vez que la transacción ha sido
confirmada (COMMIT) y por tanto los cambios de la base de datos
guardados, éstos deben perdurar en el tiempo aun cuando el gestor
de base de datos o el propio equipo fallen.

Estructura de las transacciones

La estructura de una transacción usualmente viene dada según

el modelo de la transacción, estas pueden ser planas (simples) o
anidadas.

Transacciones planas: consisten en una secuencia de operaciones

primitivas encerradas entre las palabras clave BEGIN y END. Por
ejemplo: 

            BEGIN _TRANSACTION Reservación

              ....

             END.

Transacciones anidadas: consiste en tener transacciones que

dependen de otras, estas transacciones están incluidas dentro de otras de
un nivel superior y se las conoce como subtransacciones. La transacción
de nivel superior puede producir hijos (subtransacciones) que hagan más
fácil la programación del sistema y mejoras del desempeño.

En las transacciones anidadas las operaciones de una transacción

pueden ser así mismo otras transacciones. Por ejemplo:

BeginTransaction Reservación
BeginTransaction Vuelo
…
EndTransaction {Vuelo}
BeginTransaction Hotel
…
endTransaction {Hotel}
 BeginTransaction Car
…
endTransaction {Car}

EndTransaction {Reservación}
Una transacción anidada dentro de otra conserva las mismas
propiedades que las de su padre, esto implica, que puede contener así
mismo transacciones dentro de ella. Existen restricciones obvias en una
transacción anidada: debe empezar después que su padre y debe
terminar antes que él. El compromiso de una subtransaccion es
condicional al compromiso de su padre, si el padre de una o varias
subtransacciones  aborta, las subtransacciones hijas también serán
abortadas. Las transacciones anidadas brindan un nivel más alto de
concurrencia entre transacciones. Ya que una transacción consiste de
varias transacciones es posible tener mayor concurrencia dentro de una
sola transacción.

Así también, es posible recuperarse de fallas de forma independiente

de cada sub transacción. Esto limita el daño a una parte más pequeña de
la transacción, haciendo que el costo de la recuperación sea el menor.

También se deben considerar el orden de las lecturas y escrituras. Si

las acciones de lectura y escritura pueden ser mezcladas sin ninguna
restricción, entonces, a este tipo de transacciones se les conoce
como generales. Por el contrario, si se restringe o impone que un dato
debe ser leído antes de que pueda ser escrito entonces se tendrán
transacciones restringidas.

Si las transacciones son restringidas a que todas las acciones de

lectura se realicen antes de las acciones de escritura entonces se les
conoce como de dos pasos. Finalmente existe un modelo de acción para
transacciones restringidas en donde se aplica aún más la restricción de
que cada par < read, write > tiene que ser ejecutado de manera atómica.

Operaciones de una transacción

  Inicio de transacción: Operación que marca el momento en el
que una transacción comienza a ejecutarse.

 Leer o escribir: Operaciones de lectura/escritura de elementos de

la base de datos.

 Fin de la transacción: Se verifica si la transacción debe abortarse

por alguna razón.

 Confirmar (COMMIT): La operación termino con éxito.

 Abortar (ROLLBACK): La transacción termino sin éxito.

Estados de una Transacción

 Transacción activa: se encuentra en este estado justo después

de iniciar su ejecución.

 Transacción parcialmente comprometida: en este punto, se

efectúan diferentes operaciones de verificación para asegurar que la
transacción no interfiera con otras transacciones en ejecución.

 Transacción comprometida: ha concluido su ejecución con éxito.

 Transacción fallida: en este caso, es posible que la transacción

deba ser cancelada.

 Transacción abortada: indica que la transacción a abandonado el

sistema.

Representación de los estados de una transacción:

Control de concurrencia
 Qué es la planeación (schedule) de una transacción.

Es una secuencia de las acciones realizadas por una o más

transacciones. Cuando se estudia el control de concurrencia, las acciones
de escritura y de lectura tienen lugar en los buffers de la memoria
principal, no del disco. Es decir, un elemento de base de datos A, el cual
se llevó a algún buffer por alguna transacción T puede ser leído o escrito
en ese buffer no solo por la transacción T, sino también por otras
transacciones que tienen acceso al elemento de la base de datos.

Una secuencia (S) de n transacciones T1, T2, T3,…Tn es un

ordenamiento de operaciones de las transacciones. Las operaciones de
diferentes transacciones pueden ser intercaladas en la secuencia

S. sin embargo para cada transacción Ti en S deben aparecer en el

mismo orden en el cual ocurren en Ti. El orden de las operaciones en S
se considera que es un orden total, lo que significa que para dos
operaciones en la secuencia, una ocurre antes que otra. Es posible
-teóricamente-, manejar secuencias cuyas operaciones son órdenes
parciales.

Ejemplos de planeaciones seriales y no seriales que involucran a la

transacción T1 y T2. Planeación serial A: T1 seguido de T2:

a) Planeación serial B: T2 seguido de T1:

 b) Dos planeaciones no-seriales C y D con operaciones
entrelazadas:

27

Control de concurrencia en el DBMS

Manejo de transacciones en SQL

SET AUTOCOMMIT = {0 | 1}

Si el modo de autocommit está en apagadado SET AUTOCOMMIT = 0,

entonces se asume que la misma transacción continua hasta que se
realice un COMMIT o un ROLLBACK. Donde un commit actualizará Por
default el modo de autocommit está encendido, de manera que cada
operación es considerada una transacción y todo cambio se va reflejando
automáticamente en la base de datos.
 Niveles de aislamiento en SQL

SQL estándar define 4 niveles de aislamiento en términos de 3

fenómenos que deben ser prevenidos entre transacción concurrentes.
Estos son:

 dirty read: Una transacción lee datos escritos por una transacción
concurrente que no ha hecho "commit"
 nonrepeatable read: Una transacción re-lee datos que leyó
previamente y encuentra que han sido modificados por otra
transacción (que hizo commit en el inter).
 phantom read: Una transacción re-ejecuta un query regresando un
conjunto de tuplas que satisfacen una condición de búsqueda y
encuentra que el resultado ha cambiado debido a otra transacción
que hizo "commit" recientemente.

SQL Transaction Isolation Levels

Dirty Nonrepeatable Phantom

Isolation Level
Read Read Read
Read
Possible Possible Possible
uncommitted
Not
Read committed Possible Possible
possible
Repeatable Not
Not possible Possible
read possible
Not
Serializable Not possible Not possible
possible

*PostgreSQL ofrece Read Committed (default) y Serializable

*La mayoría de los dbms ofrecen los 4 niveles

Descripción de los niveles de aislamiento en Innodb (MySQL)

READ UNCOMMITTED
 Tambíen llamado "dirty read": los selects que norequieren bloqueos
son realizados de manera que no es posible ver una versión más reciente
del registro, entonces no hay lecturas consistentes bajo este nivel. El
opuesto es el READ COMMITTED.

READ COMMITTED

Parecido al nivel de aislamiento en Oracle. Todos los queries del tipo

SELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODE
únicamente bloquean los índices de los registros, no los huecos (gaps)
anteriores a ellos y así permite insertar libremente nuevos registros
después de los registros bloqueados.

UPDATE y DELETE que usan un índice único con una única condición
de búsqueda, solo bloquean el índice del registro encontrado, no los
huecos entre ellos. Pero en selecciones de "rangos" para UPDATE y
DELETE en Innodb se debe aplicar un bloqueo de "next-key o gap" y
bloquear las inserciones de otros usuarios en los huecos cubiertos en ese
rango.

REPEATABLE READ

El nivel por default en InnoDB. SELECT ... FOR UPDATE, SELECT ...
LOCK IN SHARE MODE, UPDATE, and DELETE, los cuales usan índices
únicos con una única condición de búsqueda, sólo bloquean el índice del
registro encontrado, no los huecos anteriores a él. De otra manera estas
operaciones emplean bloqueos "next-key", bloqueando el rango de
índices obtenido a partir del bloqueo "next-key" o "gap" y bloquea nuevas
inserciones por parte de otros usuarios.

En lecturas consistentes hay una diferencia muy importante con el nivel

"read commited": en este nivel todas las lecturas consistentes dentro de la
misma transacción leen la misma copia de información establecida por la
primer lectura. Esta convención significa que si se realizan varios selects
simples dentro de la misma transacción estos selects son consistentes
entre sí.

SERIALIZABLE

Este nivel es como el anterior, pero todos los selects simples son
implícitamente convertidos a SELECT ... LOCK IN SHARE MODE.

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ

UNCOMMITTED | READ COMMITTED | REPEATABLE READ |
SERIALIZABLE}

Principales tipos de JOINS en SQL

Los JOINs en SQL sirven para combinar filas de dos o más

tablas basándose en un campo común entre ellas, devolviendo por tanto
datos de diferentes tablas. Un JOIN se produce cuando dos o más tablas
se juntan en una sentencia SQL.

Existen más tipos de joins en SQL que los que aquí se explican,

como CROSS JOIN, O SELF JOIN, pero no todos ellos están soportados
por todos los sistemas de bases de datos. Los más importantes son los
siguientes:

INNER JOIN: Devuelve todas las filas cuando hay al menos una

coincidencia en ambas tablas.

LEFT JOIN: Devuelve todas las filas de la tabla de la izquierda, y las

filas coincidentes de la tabla de la derecha.

RIGHT JOIN: Devuelve todas las filas de la tabla de la derecha, y las

filas coincidentes de la tabla de la izquierda.

OUTER JOIN: Devuelve todas las filas de las dos tablas, la izquierda y

la derecha. También se llama FULL OUTER JOIN.

INNER JOIN
 INNER JOIN selecciona todas las filas de las dos columnas siempre y
cuando haya una coincidencia entre las columnas en ambas tablas. Es el
tipo de JOIN más común.

Representación gráfica:

Ejemplo mediante las tablas Clientes y Pedidos:

La siguiente sentencia SQL devolverá todos los clientes con

pedidos:

Si hay filas en Clientes que no tienen coincidencias en Pedidos, los

Clientes no se mostrarán. La sentencia anterior mostrará el siguiente
resultado:

Sofie Mariona aparece dos veces ya que ha realizado dos pedidos. No

aparece Marco Lambert, pues no ha realizado ningún pedido.
LEFT JOIN
LEFT JOIN mantiene todas las filas de la tabla izquierda (la tabla1). Las
filas de la tabla derecha se mostrarán si hay una coincidencia con las de
la izquierda. Si existen valores en la tabla izquierda pero no en la tabla
derecha, ésta mostrará null.

Representación gráfica:

Tomando de nuevo las tablas de productos y pedidos, ahora queremos

mostrar todos los clientes, y cualquier pedido que pudieran haber
encargado:

La sentencia anterior devolverá lo siguiente:

 Ahora vemos que se muestran todas las filas de la tabla Clientes, que
es la tabla de la izquierda, tantas veces como haya coincidencias con el
lado derecho. Marco Lambert no ha realizado ningún pedido, por lo que
se muestra null.

RIGHT JOIN
Es igual que LEFT JOIN pero al revés. Ahora se mantienen todas las
filas de la tabla derecha (tabla2). Las filas de la tabla izquierda se
mostrarán si hay una coincidencia con las de la derecha. Si existen
valores en la tabla derecha pero no en la tabla izquierda, ésta se
mostrará null.

Representación gráfica:

De nuevo tomamos el ejemplo de Clientes y Pedidos, y vamos a

hacer el mismo ejemplo anterior, pero cambiado LEFT por RIGHT:

Ahora van a aparecer todos los pedidos, y los nombres de los

clientes que han realizado un pedido. Nótese que también se ha
cambiado el orden, y se han ordenado los datos por PedidoID.

OUTER JOIN
OUTER JOIN o FULL OUTER JOIN devuelve todas las filas de la tabla
izquierda (tabla1) y de la tabla derecha (tabla2). Combina el resultado de
los joins LEFT y RIGHT. Aparecerá null en cada una de las tablas
alternativamente cuando no haya una coincidencia.

Representación gráfica:

Vamos a obtener todas las filas de las tablas Clientes y Pedidos:

La sentencia devolverá todos los Clientes y todos los Pedidos, si un

cliente no tiene pedidos mostrará null en PedidoID, y si un pedido no
tuviera un cliente mostraría null en NombreCliente (en este ejemplo no
sería lógico que un Pedido no tuviera un cliente).

La sintaxis de OUTER JOIN o FULL OUTER JOIN no existen en

MySQL, pero se puede conseguir el mismo resultado de diferentes
formas, esta es una:

Disparadores
Los disparadores (o triggers) son bloques de código PL/SQL asociados
a una tabla y que se ejecutan automáticamente como reacción a
una operación DML específica (INSERT, UPDATE o DELETE) sobre
dicha tabla.

En resumen, los disparadores son eventos a nivel de tabla que se

ejecutan automáticamente cuando se realizan ciertas operaciones sobre
la tabla.

Los triggers pueden definirse para las operaciones INSERT, DELETE o

Update, y pueden dispararse antes o después de la operación.
Finalmente, el nivel de los disparadores puede ser la fila o registro o la
orden.

Tipos de disparadores
 Orden de ejecución de los triggers

Una misma tabla puede tener varios triggers asociados. En tal caso es
necesario conocer el orden en el que se van a ejecutar.

Los disparadores se activan al ejecutarse la sentencia SQL.

 Si existe, se ejecuta el disparador de tipo BEFORE (disparador

previo) con nivel de orden.
 Para cada fila a la que afecte la orden:
 Se ejecuta si existe, el disparador de tipo BEFORE con nivel de
fila.
 Se ejecuta la propia orden.
 Se ejecuta si existe, el disparador de tipo AFTER (disparador
posterior) con nivel de fila.
 Se ejecuta, si existe, el disparador de tipo AFTER con nivel de
orden.
Restricciones de los triggers.

El cuerpo de un disparador es un bloque PL/SQL. Cualquier orden que

sea legal en un bloque PL/SQL , es legal en el cuerpo de un disparador,
con las siguientes restricciones:

 Un disparador no puede emitir ninguna orden de control de

transacciones (COMMIT, ROLLBACK o SAVEPOINT). El
disparador se activa como parte de la ejecución de la orden que
provocó el disparo, y forma parte de la misma transacción que
dicha orden. Cuando la orden que provoca la orden es confirmada
o cancelada, se confirma o se cancela también el trabajo realizado
por el disparador.
 Por las mismas razones, ningún procedure o función llamado por el
disparador puede emitir órdenes de control de transacciones.
 El disparador no puede declarar variables de tipo LONG.

Utilización de ld y :new en los disparadores con nivel de fila.

Un disparador con nivel de fila se ejecuta una vez por cada fila
procesada por la orden que provoca el disparo. Dentro del disparador,
puede accederse a la fila que está siendo actualmente
procesada utilizando, para ello, dos pseudo-registros,  ld y :new.

En principio tanto ld como :new son del tipotabla_disparo%ROWTYPE;

Ejemplo:
 Conclusión
Las transacciones son de vital importancia en los gestores de bases de
datos, pues estas mismas brindan un potencial respecto al manejo de la
información en la base de datos, pero al ser tan potentes y de gran
utilidad, también involucran ciertas vulnerabilidades, las cuales algunas le
atañen al sistema gestor de base de datos y el servidor que implemente.
Otras a los desarrolladores de base de datos o programadores ya que los
resultados para que se produzca un buen funcionamiento en un sistema
desarrollado, se obtendrán en la medida en que sepan implementar las
diferentes propiedades o utilidades que ofrecen los gestores mediante el
lenguaje universal de acceso a datos.
El estudio de las transacciones concurrentes en una aplicación que se
implemente en una estructura cliente servidor, es de vital importancia,
dado que mantener la coherencia y durabilidad de los datos que son
consumidos desde un SGBD no es una tarea trivial. La elección de una
técnica de manejo de concurrencia que permita la serialización de las
transacciones y la coherencia de las operaciones realizadas sobre dichos
datos, debe realizarse de acuerdo a la naturaleza del problema que se
esté tratando de resolver
Los JOINS son una herramienta muy útil que funcionan para
consultarlos datos que necesitamos obtener de una base de datos sobre
todo cuando ocupamos obtener información que cumpla con los criterios
solicitados por nosotros los usuarios. Además de permitir combinar varios
registros de tablas y localizar los valores de columnas relacionadas en las
mismas.
Los disparadores son una clase especial de procedimiento almacenado
que se ejecuta automáticamente cuando se produce un evento en el
servidor de bases de datos. Estos solo se pueden aplicar a una tabla
específica, es decir, un trigger no sirve para dos o más tablas.
 Bibliografía
Laiho, A. Silpiö, M. (2014). SQL Transactions. Dbtechnet.org. Cimo.
Obtenido el 28 Junio de 2021, desde:
https://www.dbtechnet.org/download/SQL-
Transactions_handbook_SP.pdf

Transactions. (2016). Docs.oracle.com. obtenido 29 agosto 2016,

de
(2016). Transactions. Docs.oracle.com. Obtenido el 29 Junio de 2021,
desde:
http://docs.oracle.com/database/121/CNCPT/transact.htm#CNCPT016

Lázaro, D. (2021). Principales tipos de JOINS en SQL. Diego.com.es.

Obtenido el 29 Junio de 2021, desde: https://diego.com.es/principales-
tipos-de-joins-en-sql

Domínguez, J. (2015). MySQL Triggers, Funciones y Procedimientos.

researchgate.net. UPT Aragua. Obtenido el 29 Junio de 2021, desde:
https://www.researchgate.net/profile/Jorge-Dominguez-
Chavez/publication/274634086_Triggers_funciones_y_procedimientos/l
inks/5523e0ad0cf24f160943af03/Triggers-funciones-y-
procedimientos.pdf.