INSTITUTO TECNOLGICO SUPERIOR DE

TAMAZUNCHALE

CARRERA:
INGENIERA EN SISTEMAS COMPUTACIONALES

MATERIA:
TALLER DE BASE DE DATOS

UNIDAD V
TEMA:
INVESTIGACIN: UNIDAD 5 - TRANSACCIONES

ALUMNO:
CSAR MANUEL REYES

12ISC062

CATEDRTICO:
ING. BRAULIO BAUTISTA LPEZ

GRUPO:

M1

SEMESTRE:

FECHA DE ENTREGA:
PERIODO:

TURNO:

MATUTINO

28 DE NOVIEMBRE DEL 2014

AGOSTO

2014 ENERO

2015

CONTENIDO
INTRODUCCIN .................................................................................................................. 3
5.1 CONCEPTOS BSICOS ................................................................................................. 4
5.2 PROPIEDADES DE LA TRANSACCIN ..................................................................... 5
CONTROL DE TRANSACCIONES EN ORACLE .......................................................... 6
5.3 GRADOS DE CONSISTENCIA ..................................................................................... 7
5.4 NIVELES DE AISLAMIENTO ....................................................................................... 9
5.5 COMMIT Y ROLLBACK ............................................................................................. 11
TRANSACCIONES EN SQL SERVER .............................................................................. 13
RECOMENDACIONES. ..................................................................................................... 16
EJEMPLOS DONDE SE APLICAN. .................................................................................. 16
CONCLUSIONES ................................................................................................................ 18
BIBLIOGRAFA .................................................................................................................. 19

INTRODUCCIN
En esta unidad cinto estaremos viendo el tema de transiciones en la materia de base de
datos.
Dentro de esta investigacin podremos ver con claridad que es y en que consiste este tema,
de una forma generalizada se puede decir que una transicin es un conjunto de operaciones
que se ejecutan como nico bloque, o bien, es un conjunto de rdenes que se ejecutan
formando una unidad para de esta manera poder trabajar.
De igual manera se presentara unos ejemplos en cdigo para ser comprendido de mejor
manera.
El ejemplo ms claro sobre el tema es la transferencia de cuentas bancarias, porque se
realizan de manera distinta porque en una aumenta y en la otra cuenta disminuye.

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)
Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD), es un conjunto de
rdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o
atmica.
Un SGBD se dice 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 transaccin, 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 transaccin nunca se hubiese realizado. Una transaccin debe contar
con ACID (un acrnimo ingls) que quiere decir: Atomicidad, Consistencia, Aislamiento y
Durabilidad. Entonces para que un Sistema de Gestin de Bases de Datos sea considerado
Transaccional, debe cumplir con estos criterios (ACID).
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 transaccin.

BEGIN TRAN: Especifica que va a empezar una transaccin.

COMMIT TRAN: Le indica al motor que puede considerar la transaccin

completada con xito.

ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la

base al punto de integridad.

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

5.2 PROPIEDADES DE LA TRANSACCIN

Una unidad lgica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades
ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificada 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 aun, 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 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.

CONTROL DE TRANSACCIONES EN ORACLE

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
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 nombrePuntoRestauracin;
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:
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.

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 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 funcin de los efectos
secundarios de la simultaneidad que se permiten, como las lecturas de datos sucios o las
lecturas fantasmas
Los niveles de aislamiento de las transacciones controlan lo siguiente:

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 se inici la instruccin o la transaccin.
o Lee la modificacin de los datos no confirmada.

La seleccin de un nivel de aislamiento de transaccin no afecta a los bloqueos adquiridos

para proteger las modificaciones de datos. Siempre se obtiene un bloqueo exclusivo en los
datos modificados de una transaccin, bloqueo que se mantiene hasta que se completa la
transaccin, independientemente del nivel de aislamiento seleccionado para la misma. En el
caso de las operaciones de lectura, los niveles de aislamiento de transaccin definen
bsicamente el nivel de proteccin contra los efectos de las modificaciones que realizan
otras transacciones.

Las transacciones se deben ejecutar en un nivel de aislamiento de lectura repetible, al

menos, para evitar las prdidas de actualizaciones que pueden producirse cuando dos
transacciones recuperan la misma fila, y a continuacin la actualizan segn los valores
recuperados originalmente. Si las dos transacciones actualizan las filas con una nica
instruccin UPDATE y no basan la actualizacin en los valores recuperados previamente,
la prdida de las actualizaciones no puede producirse en el nivel de aislamiento
predeterminado de lectura confirmada.
Para establecer el nivel de aislamiento para una transaccin, puede utilizar el mtodo de
setTransactionIsolation de la clase SQLServerConnection. Este mtodo acepta un valor int
como argumento, que se basa en una de las constantes de conexin, segn se muestra a
continuacin:
Un nivel de aislamiento menor significa que los usuarios tienen un mayor acceso a los
datos simultneamente, con lo que aumentan los efectos de la simultaneidad que pueden
experimentar, como las lecturas de datos sucios o la prdida de actualizaciones. Por el
contrario, un nivel de aislamiento mayor reduce los tipos de efectos de simultaneidad, pero
requiere ms recursos del sistema y aumenta las posibilidades de que una transaccin
bloquee a otra. El nivel de aislamiento apropiado depende del equilibrio entre los requisitos
de integridad de los datos de la aplicacin y la sobrecarga de cada nivel de aislamiento. El
nivel de aislamiento superior, que es serializable, garantiza que una transaccin recuperar
exactamente los mismos datos cada vez que repita una operacin de lectura, aunque para
ello aplicar un nivel de bloqueo que puede afectar a los dems usuarios en los sistemas
multiusuario. El nivel de aislamiento menor, de lectura sin confirmar, puede recuperar
datos que otras transacciones han modificado pero no confirmado. En este nivel se pueden
producir todos los efectos secundarios de simultaneidad, pero no hay bloqueos ni versiones
de lectura, por lo que la sobrecarga se reduce.
con.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
Para utilizar el nuevo nivel de aislamiento de instantnea de SQL Server 2005, puede
utilizar una de las constantes SQLServerConnection, segn se muestra a continuacin:
con.setTransactionIsolation(SQLServerConnection.TRANSACTION_SNAPSHOT);

o podemos utilizar:
con.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED + 4094);

5.5 COMMIT Y ROLLBACK

MySQL se ejecuta con el modo autocommit activado. Esto significa que encuanto 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.
COMMIT:
Hasta que no se realiza un COMMIT, slo el usuario que est realizando las modificaciones
podr ver el efecto que estn surtiendo sobre las tablas afectadas, el resto de los usuarios
vern la informacin antigua ( la existente en el segmento de Rollback ).
Las filas afectadas por las operaciones de un usuario ( INSERT, UPDATE, DELETE ) son
bloqueadas. Otros usuarios no pueden acceder a dichas filas hasta que no finalice la
transaccin.
El COMMIT afecta slo a la transaccin del usuario que ejecuta el COMMIT ( no afecta a
transacciones de otros usuarios ).
ROLLBACK:
Una sentencia ROLLBAC (al igual que un COMMIT) puede ser usado en un subprograma
PL / SQL. Esto ofrece una gran ventaja cuando se usan estructuras lgicas del tipo if-then-

else, puesto que permiten modificar y borrar informacin de forma condicional en base a
condiciones en tiempo de ejecucin.
Ejemplos:
START TRANSACTION:
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHEREtype=1;
COMMIT
Con START TRANSACTION, autocommit permanece deshabilitado hasta el final de la
transaccincon COMMIT o ROLLBACK. El modo autocommit vuelve a su estado previo.

TRANSACCIONES EN SQL SERVER

El ejemplo clsico de transaccin es una transferencia bancaria, en la que quitamos saldo a
una cuenta y lo aadimos en otra. Si no somos capaces de abonar el dinero en la cuenta de
destino, no debemos quitarlo de la cuenta de origen.
SQL Server funciona por defecto con Transacciones de confirmacin automtica, es decir,
cada instruccin individual es una transaccin y se confirma automticamente.
Sobre el ejemplo anterior de la transferencia bancaria, un script debera realizar algo
parecido al siguiente:
DECLARE @importe DECIMAL(18,2),
@CuentaOrigen VARCHAR(12),
@CuentaDestino VARCHAR(12)
/* Asignamos el importe de la transferencia
* y las cuentas de origen y destino
*/
SET @importe = 50
SET @CuentaOrigen = '200700000001'
SET @CuentaDestino = '200700000002'

/* Descontamos el importe de la cuenta origen */

UPDATE CUENTAS
SET SALDO = SALDO - @importe

WHERE NUMCUENTA = @CuentaOrigen

/* Registramos el movimiento */
INSERT INTO MOVIMIENTOS
(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR, IMPORTE,
FXMOVIMIENTO)
SELECT
IDCUENTA, SALDO + @importe, SALDO, @importe, getdate()
FROM CUENTAS
WHERE NUMCUENTA = @CuentaOrigen

/* Incrementamos el importe de la cuenta destino */

UPDATE CUENTAS
SET SALDO = SALDO + @importe
WHERE NUMCUENTA = @CuentaDestino

/* Registramos el movimiento */
INSERT INTO MOVIMIENTOS
(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR, IMPORTE,
FXMOVIMIENTO)
SELECT

IDCUENTA, SALDO - @importe, SALDO, @importe, getdate()

FROM CUENTAS
WHERE NUMCUENTA = @CuentaDestino

Esta forma de actuar seria errnea, ya que cada instruccin se ejecutara y confirmara de
forma independiente, por lo que un error dejara los datos errneos en la base de datos ( y
ese es el peor error que nos podemos encontrar! )
Transacciones implcitas y explicitas
Para agrupar varias sentencias Transact SQL en una nica transaccin, disponemos de los
siguientes mtodos:

Transacciones explcitas: Cada transaccin se inicia explcitamente con la

instruccin BEGIN TRANSACTION y se termina explcitamente con una
instruccin COMMIT o ROLLBACK.

Transacciones implcitas: Se inicia automtivamente una nueva transaccin

cuando se ejecuta una instruccin que realiza modificaciones en los datos, pero cada
transaccin se completa explcitamente con una instruccin COMMIT o
ROLLBACK.

Para activar-desactivar el modo de transacciones implcitas debemos ejecutar la siguiente

instruccin.
--Activamos el modo de transacciones implicitas
SET IMPLICIT_TRANSACTIONS ON
--Desactivamos el modo de transacciones implicitas
SET IMPLICIT_TRANSACTIONS OFF

RECOMENDACIONES.
Hemos visto ya muchas explicaciones acerca de lo que son las transacciones y concepto
aplicado en base de datos, sin duda, es sinnimo de ser confiable al trabajar en nuestra base
de datos.
Pueden ser utilizadas con ms frecuencia en bancos, la idea es que usar alguna sentencia sin
afectar nada sino hasta que nosotros lo indiquemos con la sentencia COMMIT.
El concepto de transaccin va enfocado a que al ejecutar dicha sentencia no suceda nada, y
que los cambios sean realizados hasta que escribamos la sentencia que mencionamos.
En cuanto a los manejadores de base de datos tenemos MY SQL, SQL SERVER y
ORACLE entre otros, si deseamos trabajar sin complicaciones de licencias y todo ello, esta
la gran opcin de usar MY SQL que es libre y muy fcil de usar para todo aquel que desea
manejar informacin. En cuanto a SQL SERVER es un entorno muy particular de
Microsoft, una de las complicaciones que podemos tener quiz sea el entorno de trabajo ya
que hace se realizan otros pasin pero la lgica de las consultas son las mismas y por otro
lado seria la compatibilidad.
Actualmente ORACLE es uno de los gestores de base de datos con mucho renombre que
posee una gran seguridad y una amplia gama de informacin y soporte de parte de sus
desarrolladores ya que es de paga.
En todos estas opciones que puedo presentar se puede aplicar lo de transacciones, solo es
cuestin de saber en cul de ellos nos podemos acoplar y trabajar libremente, la esencia de
las consultas y las sintaxis que son usadas pueden aplicar en cualquiera de estas.

EJEMPLOS DONDE SE APLICAN.

Las transacciones sirven para asegurar la consistencia de la informacin, asegurando que un
conjunto de sentencias se ejecuten correctamente, o no se ejecuten.
Un ejemplo

Supongamos que un sitio web bancario tiene 2 usuarios, ambos trabajando sobre la misma
cuenta.
El usuario 1 pide incrementar su saldo en 10, mientras que el usuario 2 pide disminuirlo (a
travs de un formulario, por ejemplo)
El programador del sistema no puede decidir el orden en el que se ejecutarn las consultas,
as que bien podra suceder lo siguiente:

bal1 := ... SELECT balance FROM cuentas WHERE cuenta=X -- usuario 1

bal2 := ... SELECT balance FROM cuentas WHERE cuenta=X -- usuario 2

En este punto, existen dos copias de la aplicacin que contienen una variable $balance cada
una. Supongamos que ambas necesitan actualizar el valor en la base de datos:

UPDATE cuentas SET balance=(bal1+10) WHERE cuenta=X -- usuario 1

UPDATE cuentas SET balance=(bal2-10) WHERE cuenta=X -- usuario 2

El resultado es que ambas copias del programa ejecutaron sus consultas con la informacin
de balance que tenan, por lo que el resultado final es como si la consulta del usuario 1 no
se hubiera ejecutado nunca, ya que el usuario 2 actualiza el registro con informacin vieja.
Al final, en vez de quedar con el mismo saldo, la cuenta termina perdiendo 10.

CONCLUSIONES
Despus de toda esta informacin obtenida podemos hacer un nfasis un tanto clara de lo
que es las transacciones, que podemos denominar ya como un conjunto do ordenes que se
ejecuten para de esta manera formar una unidad de trabajo.
En otras palabras tambin podemos definir a la transaccin como un conjunto de acciones
que se llevan a cabo por algn usuario o algn programa de aplicacin que pueden acceder
al contenido de la base de datos.
Con esto se puede realizar cualquier tipo de operaciones en una base de datos, basndonos
en consultas simples o de un grado que presente complejidad.
Podemos tener beneficios en lograr acciones sobre la base de datos en la que deseamos
aplicar, logrando operaciones como el ingreso, borrado, actualizacin y visualizar.

BIBLIOGRAFA
http://es.slideshare.net/Thekavenet/transacciones-en-mysql
http://www.devjoker.com/contenidos/articulos/292/Transacciones-en-Transact-SQL.aspx
http://www.desarrolloweb.com/articulos/control-transacciones-oracle.html
http://lopez-garcia-victor.blogspot.mx/2012/10/unidad-v-transacciones.html
http://msdn.microsoft.com/es-es/library/aa833147%28v=vs.90%29.aspx
http://dsc.itpn.mx/recursositics/4semestre/tallerdebasededatos/Unidad%20V.pdf
http://es.wikipedia.org/wiki/Transacci%C3%B3n_%28base_de_datos%29
http://www.microsoft.com/en-us/server-cloud/products/sql-server/
http://mauricio-iso20000.blogspot.mx/p/unidad-4-manejo-de-transacciones.html
http://es.slideshare.net/dantoniocruz/transacciones-27511077
http://www.devjoker.com/contenidos/articulos/292/Transacciones-en-Transact-SQL.aspx
http://mundobyte.wordpress.com/2008/01/10/transacciones-en-mysql/