INTEGRANTES:

LABASTIDA SALINAS HUGO ALBERTO

LÓPEZ MORENO MARIO DAVID
RAMÍREZ MIRANDA JANETH
SANCHEZ GUZMAN DIEGO
ZÁRATE GONZÁLEZ GUILLERMO

MATERIA:
BASES DE DATOS DISTRIBUIDAS

DOCENTE:
RIVERO MARBÁN JORGE ARTURO

ACTIVIDAD:
UNIDAD 4

Horario
Lunes Miércoles Viernes
11:00 - 13:00 11:00 - 13:00 12:00 - 13:00
2 Índice

 Introducción
 Objetivo general
 Unidad 4 Manejo de transacciones
 4.1 Transacciones
 4.2 Control de concurrencia
 4.3 Confiabilidad
 Conclusiones
 Glosario Técnico
 Bibliografía
 Introducción
3  En el presente trabajo se hablará sobre el manejo de transacciones en una base de
datos distribuida; El concepto de transacción es algo mucho más amplio y está presente
tanto en sistemas centralizados como en sistemas distribuidos, tampoco debemos
confundir el concepto de “sistema distribuido” asumiendo que es cualquier sistema que
no sea el ordenador central, el uso correcto de la transaccionalidad ayuda a garantizar
la 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 empotradas, 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.
 Esperando desarrollar el tema lo más claro posible se anexará un glosario técnico, al
igual que se espera cubrir el objetivo principal, así como los específicos.
4 Objetivo general

 Describir la importancia de las transacciones dentro de las bases de datos

distribuidas, incorporando información de los diferentes tipos de
transacciones, características y funcionalidad de las mismas, así mismo se
resaltara la definición detallada de las concurrencias y el control
adecuado que se debe de llevar dentro de las bases de datos, esto con la
finalidad de que no existan problemas posteriores de concurrencia, por
último se mencionara la confiabilidad que se tiene en las transacciones
para llegar a un determinado punto en donde se tenga la facilidad de
operar con estas transacciones y llevarlas adecuadamente dentro de la
practica en tiempo real.
 Unidad 4
Manejo de transacciones
4.1 Transacciones

 OBJETIVO ESPECIFICO
 Realizar una breve explicación de las transacciones manejadas en las
bases de datos y resaltar cuales son más oportunas o primordiales en el
momento de la ejecución de una base de datos distribuida.
 4.1 Transacciones

 “Una transacción es una secuencia de una o más operaciones agrupadas como

una unidad” El inicio y el final de la transacción definen los puntos de
consistencia de la base de datos distribuida. Si una acción de la transacción no
se puede ejecutar, entonces ninguna acción dentro de la secuencia que
conforma la transacción tendrá efecto. Las operaciones dentro de una
transacción se almacenan temporalmente, no a nivel de disco. Es hasta que
termina la transacción que se tienen efecto de manera permanente o no.
 • En algunas situaciones, el cliente necesitan que una secuencia de operaciones
a la base de datos distribuida se ejecuten de manera atómica:
 • libres de interferencia por operaciones de otros clientes.
 • Todas las operaciones se deben completar con éxito o no tener ningún efecto
si el servidor falla.
4.1 Transacciones
4.1 Transacciones
4.1 Transacciones

Propiedades ACID

• Atomicidad (Atomicity)
• Consistencia (Consistency)
• Aislamiento (Isolation)
• Durabilidad (Durability)
4.1 Transacciones
Transacciones: Condiciones de terminación
Una transacción siempre termina, aun cuando exista un fallo. Si una transacción
termina de manera exitosa se dice que la transacción ha sido consumada:
commit . El resultado de una transacción consumada es almacenado en la base
de datos de manera permanente y no se puede deshacer.
Si la transacción se detiene sin terminar su tarea, se dice que la transacción
aborta. Cuando la transacción es abortada, su ejecución se detiene y todas las
acciones ejecutadas hasta el momento se deshacen (undone), regresando la
base de datos al estado antes de su ejecución. A esta operación también se le
conoce como rollback.

Tipos de Transacciones
Transacciones planas: Estas transacciones tienen un punto de partida simple
(Begin_transaction) y un punto simple de terminación (End_transaction)
Las transacciones anidadas: las operaciones de una transacción anidada
pueden incluir otras transacciones
4.2 Control de concurrencia

 OBJETIVO ESPECIFICO
 Definir las concurrencias dentro de una base de datos, así mismo detallar
el control de concurrencias que se utilizan o manejan dentro de las bases
de datos distribuidas, con la finalidad de obtener más conocimientos para
la realización de prácticas en tiempo real.
4.2 Control de concurrencia

 DEFINICIÓN DE CONCURRENCIA
 En el campo informático, el termino concurrencia se refiere a la
capacidad de los Sistemas de Administración de Base de Datos, de
permitir que múltiples procesos sean ejecutados al mismo tiempo, y que
también puedan interactuar entre sí.
 El control de concurrencia trata con los problemas de aislamiento y
consistencia del procesamiento de transacciones. El control de
concurrencia distribuido de una DDBMS asegura que la consistencia de la
base de datos se mantiene en un ambiente distribuido multiusuario.
4.2 Control de concurrencia

 PROBLEMAS DE CONCURRENCIA
 Si no se hace un adecuado control de concurrencia, se pueden presentar
dos anomalías. En primer lugar, se pueden perder actualizaciones
provocando que los efectos de algunas transacciones no se reflejen en la
base de datos. En segundo término, pueden presentarse recuperaciones
de información inconsistentes.
 Los tres problemas son:
 El problema de la Actualización Perdida
 El problema de la Dependencia No Confirmada
 El problema del Análisis Inconsistente
4.2 Control de concurrencia

 TÉCNICAS DE BLOQUEO EN DOS FASES PARA CONTROLAR LA

CONCURRENCIA
 Algunas de las principales técnicas que se utilizan para controlar la
ejecución concurrente de transacciones están basadas en el concepto
de bloqueo de elementos de datos.
 Un bloqueo es una variable asociada a un elemento de datos que
describe el estado de ese elemento respecto a las posibles operaciones
que se le puedan aplicar.
 Generalmente, hay un bloqueo por cada elemento de datos de la base
de datos. Los bloqueos se utilizan como un medio para sincronizar el
acceso de las transacciones concurrentes a los elementos de la base de
datos.
4.2 Control de concurrencia

 La sintaxis para bloquear tablas es la

 siguiente:
 LOCK TABLES nombre_tabla1 READ | WRITE, nombre_tabla2 READ | WRITE
…
 Cuando se crea un bloqueo para acceder a una tabla, dentro de la zona
de bloqueo no
 podremos acceder a otras tablas hasta que no se finalice el bloqueo:
 LOCK TABLES t1 READ;
 SELECT * FROM t1;
 SELECT * FROM t2;
4.2 Control de concurrencia

 ALGUNOS CASOS DE CONCURRENCIA, PUEDEN SER:

 La multiprogramación, ya que el tiempo del procesador es compartido
dinámicamente por varios procesos.
 Las aplicaciones estructuradas, donde la programación estructurada se
implementa como un conjunto de procesos concurrentes.
 También se tiene que la misma estructura recién mencionada es utilizada
en el diseño de los sistemas operativos, los cuales se implementan como un
conjunto de procesos.
4.2 Control de concurrencia

 Tomaremos como ejemplo las transacciones de las cuentas de un banco,

supongamos que tenemos un programa llamado Depositar, el cual
deposita dinero en una cuenta.
4.2 Control de concurrencia
 Supongamos que la cuenta 7 tiene un saldo de $1000 y que el cliente 1
deposita $100 en la cuenta 7 en el mismo instante en el que el cliente 2
deposita $100000 en la cuenta 7. Cada uno de los clientes llama al
procedimiento Depositar de tal manera que se crea una transacción para
realizar su actualización. La ejecución concurrente de éstos depósitos
produce una secuencia de lecturas y escrituras en la base de datos, tales
como
 Leer1 (Cuentas [7]) devuelve el valor de $1000
 Leer2 (Cuentas [7]) devuelve el valor de $1000
 Escribir2 (Cuentas [7], $101000)
 Commit2
 Escribir1 (Cuentas [7], $1100)
 Commit1
4.2 Control de concurrencia

 El resultado de esta ejecución es que la Cuenta [7] contiene $1100. A

pesar que el depósito del cliente 2 concluyó satisfactoriamente, la
interferencia con la ejecución de Depósito del cliente 1 causó que el
depósito del cliente 2 se pierda. Este fenómeno de actualización perdida
ocurre cuando dos transacciones, mientras intentan modificar un dato,
ambas leen el valor antiguo del elemento antes que ninguna haya
modificado su valor.
4.3 Confiabilidad

 OBJETIVO ESPECIFICO
 Demostrar los puntos básicos y esenciales dentro de la confiabilidad de las
bases de datos distribuidas, así mismo detallar los protocolos y resaltar los
puntos de verificación.
4.3 Confiabilidad

 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 empotradas, 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
continua procesando las solicitudes de usuario aún 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.
4.3 Confiabilidad

 Conceptos básicos de confiabilidad.

 La confiabilidad engloba varias actividades y una de ellas es el
planteamiento de modelos de confiabilidad, esto es fundamentalmente la
probabilidad de supervivencia del sistema.
 Se expresa como una función de las confiabilidades de los componentes o
subsistemas, que generalmente, estos modelos se encuentran
dependiendo del tiempo.
 Protocolos REDO/UNDO.
4.3 Confiabilidad

 El registro de la base de datos contiene información que es utilizada por el

proceso de recuperación para restablecer la base de datos a un estado
consistente. Esta información puede incluir entre otras cosas:
 El identificador de la transacción.
 El tipo de operación realizada.
 Los datos accesados por la transacción para realizar la acción.
 El valor anterior del dato (imagen anterior).
 El valor nuevo del dato (imagen nueva).
4.3 Confiabilidad

 Considere el escenario mostrado en la Figura de abajo. El DBMS inicia la

ejecución en el tiempo 0 y en el tiempo t se presenta una falla del sistema.
Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha sido
concluida (ha realizado su commit) pero T2 no pudo ser concluida.
 La propiedad de durabilidad requiere que los efectos de T1 sean reflejados
en la base de datos estable. De forma similar, la propiedad de atomicidad
requiere que la base de datos estable no contenga alguno de los efectos
de T2.
4.3 Confiabilidad

 Operación REDO.
 Por otra parte, es posible que el administrador del buffer haya realizado la
escritura en la base de datos estable de algunas de las páginas de la base
de datos volátil correspondientes a la transacción T2.
 Así, la información de recuperación debe incluir datos suficientes para
permitir deshacer ciertas actualizaciones en el nuevo estado de la base de
datos y regresarla al estado anterior. A esta operación se le conoce como
UNDO y se muestra en la Figura de abajo. La operación UNDO restablece
un dato a su imagen anterior utilizando la información del registro de la
base de datos.
4.3 Confiabilidad

 Operación UNDO.
 De forma similar a la base de datos volátil, el registro de la base de datos
se mantiene en memoria principal (llamada los buffers de registro) y se
escribe al almacenamiento estable (llamado registro estable). Las páginas
de registro se pueden escribir en el registro estable de dos formas: síncrona
o asíncrona. En forma síncrona, también llamada un registro forzado, la
adición de cada dato en el registro requiere que la página del registro
correspondiente se mueva al almacenamiento estable. De manera
asíncrona, las páginas del registro se mueven en forma periódica o
cuando los buffers se llenan.
4.3 Confiabilidad

 Puntos de verificación (checkpoints).

 Cuando ocurre una falla en el sistema es necesario consultar la bitácora
para determinar cuáles son las transacciones que necesitan volver a
hacerse y cuando no necesitan hacerse. Estos puntos de verificación nos
ayudan para reducir el gasto de tiempo consultando la bitácora. El punto
de verificación es un registro que se genera en la bitácora para concluir
en todo lo que se encuentra antes de ese punto está correcto y
verificado.
4.3 Confiabilidad

 Protocolo 2PC de confiabilidad distribuida.

 El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol

especial. Este es llamado el coordinador; todos los demás agentes que deben
hacer commit a la vez son llamados participantes.
 El coordinador es responsable de tomar la decisión de llevar a cabo un commit
o abort finalmente. Cada participante corresponde a una subtransacción la
cual ha realizado alguna acción de escritura en su base de datos local.
 Se puede asumir que cada participante está en un sitio diferente. Aun si un
participante y el coordinador se encuentran en el mismo sitio, se sigue el
protocolo como si estuvieran en distintos sitios.
 La idea básica del 2PC es determinar una decisión única para todos los
participantes con respecto a hacer commit o abort en todas las
subtransacciones locales.
4.3 Confiabilidad

 EJEMPLO:
 Ejemplo de una falla del sistema.
 A pesar que T1 haya sido terminada, puede suceder que el buffer
correspondiente a la página de la base de datos modificada no haya sido
escrito a la base de datos estable. Así, para este caso la recuperación
tiene que volver a realizar los cambios hechos por T1. A esta operación se
le conoce como REDO y se presenta en la Figura de abajo.
 La operación de REDO utiliza la información del registro de la base de
datos y realiza de nuevo las acciones que pudieron haber sido realizadas
antes de la falla. La operación REDO genera una nueva imagen.
31 Conclusión

 Finalmente podemos deducir que se cumplió con los objetivos

acordados al principio de esta investigación, ya que observamos
los tipos y las propiedades de las transacciones, así como sus
estados, al igual que se logró definir la importancia del control de
concurrencia, sus principales problemas y como se han
solucionado ya que como se observó es un gran problema a la
hora de hacer duda se desarrolló la importancia de la
confiabilidad ya que sin ella no existe una transacción exitosa,
también se describieron los protocolos redo y undo, así como las
operaciones de cada uno. Por último, se observó que el manejo de
transacciones es tan importante para la mejora del sector laboral
ya que mejoran los acuerdos entre el cliente y el trabajador.
 Glosario Técnico
 Atomicidad: Propiedad que asegura que una operación se ha realizado o
no, y por lo tanto ante un fallo del sistema no puede quedar a medias.

 Anomalías: Cambio o desviación respecto de lo que es normal, regular,

natural o previsible dentro de la base de datos.

 Buffer: Espacio de memoria, en el que se almacenan datos de manera

temporal.

 Volátil: Que cambia o varía con facilidad y de forma poco previsible.

 Asíncrona: Comunicación que se establece de manera diferida en el

tiempo
33 Bibliografía

 Prof. Alejandro Reyes Ortiz. (2016). TRANSACCIONES EN BASES DE

DATOS DISTRIBUIDAS. 03/11/2019, de azc Sitio web:
http://aisii.azc.uam.mx/areyes/archivos/Licenciatura/BDD/Transa
cciones.pdf
 Daniel Antonio Cruz. (Oct 23, 2013). Transacciones. Nov 3, 2019, de
INSTITUTO TECNOLÓGICO DE CIUDAD MADERO Sitio web:
file:///C:/Users/trans/Desktop/Concurrencia%20%201/transacciones-
131023205403-phpapp01.pdf
 liras loca. (Apr 9, 2014). BD. control de concurrencia. Nov 3, 2019, de S/N
Sitio web: https://www.slideshare.net/fulaura18/bd-control-de-
concurrencia
 Bibliografía

 Jose Guadalupe Couoh Dzul. (Feb 2, 2015). control de concurrencia. Nov

3, 2019, de instituto tecnologico de conkal Sitio web:
https://www.slideshare.net/joseguadalupecouohdzul/invetigacion-base-
de-datos-dis-para-subir?qid=7f06dc82-4311-4a55-8684-
2e7ab5b54bdd&v=&b=&from_search=4
 S/A. (2012). Confidencialidad. 3 de noviembre 2019, de Blogspot.com Sitio
web:
http://basesdatosdistribuidas.blogspot.com/2012/11/confiabilidad.html?m=
1
 Mauricio. (2010). Unidad 4 Manejo de transacciones. 3 de Noviembre 2019,
de Blog spot.com Sitio web: http://mauricio-
iso20000.blogspot.com/p/unidad-4-manejo-de-transacciones.html?m=1
35

GRACIAS!