DIVISIÓN DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

Asignatura:
Taller de bases de datos.

Elaborado por:
Zamudio Franco Luis Jesús

Docente: Ing. Oscar Olivares López.

Grupo: 352M
Actividad:
Investigación (C4)
 GUÍA ESTRUCTURADA DE EVALUACIÓN
División: (1) Ingeniería de Sistemas Computacionales
Docente: (2) ING.OSCAR OLIVARES LOPEZ
Asignatura: (3) Tópicos Avanzados de Programación
Unidad: (4) 4
Alumno(s): (5) Zamudio Franco Luis Jesús 193107070 Grupo: (6) 352M
Competencia específica Controla la concurrencia de la base de datos para disminuir los problemas de desempeño y/o
evaluada: (7) consistencia

Evidencia: (8) INVESTIGACION

Indicaciones generales: (9)
 La investigación debe ser entregado en tiempo y forma, en las fecha y horas indicados por el profesor.
 La investigación deberá entregarse de forma individual.
 La investigación del reporte debe ser nítida y pulcra.
 No debe incluir faltas de ortografía
Criterios de evaluación: (10)

No. CRITERIO VALOR SI NO

1 La investigación contiene portada e índice 10%
2 La investigación contiene la introducción respectiva 10%
3 La investigación contiene objetivos 10%
4 La investigación contiene la justificación correspondiente. 10%
La investigación contiene manejo de imágenes menores a media cuartilla
5 10%
respectivo al texto tratado.
6 La investigación contiene ejemplos claros a cada tema tratado 10%
7 La investigación es clara, precisa al tema en SQLServer 30%
8 Maneja al final de la investigación min 3 referencias bibliográficas 5%
9 La investigación se encuentra sin faltas de ortografía. 5%
Total 100%

Puntuación 1ª oportunidad 2ª oportunidad

Alcanzada(11)
Contenido
Introducción...............................................................................................................4
Objetivos....................................................................................................................5
Justificación...............................................................................................................5
4.1 Conceptos............................................................................................................6
4.1.1 Concurrencia.................................................................................................6
4.1.2 Transacción...................................................................................................6
4.1.3 Control de transacción...................................................................................6
4.1.4 Granularidad..................................................................................................7
4.1.5 Bloqueos........................................................................................................7
4.2 Propiedades de las transacciones.......................................................................7
4.2.1 Atomicidad.....................................................................................................8
4.2.2 Consistencia..................................................................................................9
4.2.3 Aislamiento....................................................................................................9
4.2.4 Permanencia..................................................................................................9
4.2.5 Propiedad adicional al ACID........................................................................10
4.3 Grados de consistencia.....................................................................................10
4.3.1 Consistencia de grado dos..........................................................................11
4.3.2 Estabilidad del cursor..................................................................................12
4.4 Niveles de aislamiento.......................................................................................12
4.5 Commit y Rollback.............................................................................................14
4.5.1 Commit.........................................................................................................14
4.5.2 Rollback.......................................................................................................15
Conclusión...............................................................................................................16
Referencias..............................................................................................................16

Tabla de ilustraciones.

Ilustración 1, Los diferentes estados de transacciones..........................................11

Ilustración 2, Tabla de Niveles de aislamiento........................................................13
Introducción.
Cuando se diseñan las aplicaciones, se deben diseñar también las transac- ciones
que éstas contienen y que son las encargadas de trabajar sobre la base de datos.
Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un
programa de aplicación, que acceden o cambian el contenido de la base de datos.
Las transacciones representan eventos del mundo real, como dar de alta un nuevo
cliente, registrar una factura o dar de baja un artículo que ya no está a la venta.
Estas transacciones se deben realizar sobre la base de datos para que ésta siga
siendo un fiel reflejo de la realidad.

Una transacción puede estar compuesta por varias operaciones sobre la ba- se de
datos, como registrar una factura, que requiere insertar datos en varias tablas. Sin
embargo, desde el punto de vista del usuario, estas operaciones conforman una
sola tarea. Desde el punto de vista del SGBD, una transacción lleva a la base de
datos de un estado consistente a otro estado consistente. El SGBD garantiza la
consistencia de la base de datos incluso si se produce algún fallo, y también
garantiza que una vez se ha finalizado una transacción, los cambios realizados por
ésta quedan permanentemente en la base de da- tos, no se pueden perder ni
deshacer (a menos que se realice otra transacción que compense el efecto de la
primera). Si la transacción no se puede finalizar por cualquier motivo, el SGBD
garantiza que los cambios realizados por esta transacción son deshechos.

El objetivo del diseño de las transacciones es definir y documentar las

características de alto nivel de las mismas que requiere el sistema. Esta tarea se
debe llevar a cabo al principio del proceso de diseño para garantizar que el
esquema lógico es capaz de soportar todas las transacciones necesarias.
Objetivos.
Con este trabajo de investigación se busca.

 Investigar y analizar los temas correspondientes a la competencia 4.

 Comprender las sentencias o instrucciones Commit y Rollback tanto
teóricamente como prácticamente, así como su estructura.
 Entender los conceptos básicos de la concurrencia.

Justificación.
La presente investigación se enfocará a estudiar los conceptos básicos de lo que
es la concurrencia en un SGDB con la finalidad de que dominemos este tema
tanto teóricamente como prácticamente.

Así que, el presente trabajo cubre los temas que marca la cuarta competencia de
nuestra respectiva instrumentación didáctica de la materia que es taller de bases
de datos.

Es importante para nosotros el manejar este tema ya que en este momento a estar
ocupando un sistema gestor de base de datos se necesita conocer temas básicos
para hacer un correcto uso de este y por supuesto que el tema de concurrencia es
uno de estos. De este tema, lo que llevaremos a la práctica será el uso de las
sentencias Commit y Rollback asi que tenemos que poner atención en para que
sirven estas y las estructuras que se deben cumplir.
 4.- CONCURRENCIA.
4.1 Conceptos.
4.1.1 Concurrencia.
El término concurrencia se refiere al hecho de que los DBMS (Sistema de
Administración de Base de Datos) permiten que muchas transacciones accedan a
una misma base de datos a la vez.

Cuando existen varios usuarios intentando modificar los datos al mismo tiempo se
necesita establecer algún tipo de control para que las modifica- ciones de un
usuario no interfieran con las de los otros, a este sistema se le denomina control
de concurrencia.

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

4.1.2 Transacción.
Informalmente, una transacción es la ejecución de ciertas instrucciones que
accedan a una base de datos compartida. Cada transacción accede a información
compartida sin interferir con otras transacciones, y si una transacción termina
normalmente, todos sus efectos son permanentes, en caso contrario no tiene
afecto alguno.

Una transacción puede consistir en varias operaciones de acceso a la base de

datos. Está delimitada por constructoras como begin transaction y end-transaction.

4.1.3 Control de transacción.

Es el encargado de aplicar la integridad de base de datos garantizando que todos
los procesos SQL se ejecutan completamente o no se ejecutan. Los comandos del
control de transacción son BEGIN, COMMIT y ROLLBACK.

La importancia de incluir controles de transacción en la base de datos, radica en

que si van hacer afectadas varias tablas en una operación y falló el proceso en
una de ellas, no importa que ya hayan sido afectada varias tablas, la operación no
se efectúa en ninguna.
4.1.4 Granularidad.
La granularidad representa el nivel de detalle al que se desea almacenar la
información sobre según sea la problemática que se esté analizando. Para que
esto quede más claro veremos un ejemplo, los datos referentes a graduados,
pueden registrarse semestre a semestre, en cambio, los datos referentes a niveles
de posgrado pueden hacerse mensualmente. Mientras mayor sea el nivel de
detalle de los datos, se tendrán mayores posibilidades de análisis, ya que los
mismos podrán ser resumidos. Es decir, los datos que posean granularidad fina
(nivel de detalle) podrán ser resumidos hasta obtener una granularidad media o
gruesa. A mayor granularidad, menor concurrencia.

4.1.5 Bloqueos.
Un bloqueo (también conocido como seguro o candado) podemos definirlo como
una variable asociada a cada elemento de datos, ya que describe el estado de
dicho elemento respecto a las posibles operaciones que se pueden llevar a cabo
con ellos en cada momento.

Las transacciones pueden llevar a cabo bloqueos, por ejemplo sobre los registros
que vayan a utilizar, impidiendo a otros usuarios la lectura o escritura de los
elementos bloqueados para evitar inconsistencias en el acceso concurrente.

4.2 Propiedades de las transacciones.

Una transacción (abreviada Tx) es un conjunto de acciones llevadas a cabo por un
usuario o un programa de aplicación, que accede o cambian el contenido de la
base de datos.

Las transacciones representan eventos del mundo real. Las características que se
deben recoger de cada transacción son las siguientes:

Datos que utiliza la transacción.

Características funcionales de la transacción.

Salida de la transacción.
Importancia para los usuarios.
Frecuencia de utilización.

Hay tres tipos de transacciones:

 1. Transacciones de recuperación. En estas se accede a los datos para
visualizarlos en la pantalla a modo de informe.
2. Transacciones de actualización. En estas se insertan, borran o actualizan
los datos de la base de datos.
3. Transacciones mixtas. En estas se mezclan operaciones de recuperación
de datos y de actualización.

Las transacciones deben cumplir cuatro propiedades ACID:

1. Atomicidad (Atomicity).

2. Consistencia (Consistency).

3. Aislamiento (Isolation).

4. Permanencia (Durability).

4.2.1 Atomicidad.
Las transacciones son consideradas atómicas. Esto quiere decir que todas las
instrucciones contenidas en una transacción son consideradas en conjunto como
una unidad indivisible, por lo que se dice que una transacción debe ejecutarse por
completo o no ejecutarse, “todo o nada”, a este requisito se le llama “atomicidad”.

Si la transacción ocurriera a medias, la base de datos quedaría inconsistente, por

lo tanto es muy importante que las transacciones hechas a la base de datos
conserven su atomicidad.

Cuando una transacción llega al estado cometido, es porque se ejecutaron

exitosamente todas sus operaciones, por lo tanto la transacción mantuvo su
atomicidad. Pero ¿qué sucede cuando un error impide a la transacción ejecutar
todas sus instrucciones?, ¿cómo se conserva en este caso la atomicidad?. Bien,
recordando que si no se puede “todo”, entonces “nada”, la transacción que entra
en estado fallado tendrá que retroceder en las instrucciones ejecutadas y regresar
a las condiciones iniciales (antes de ejecutarse). Una vez que se realiza el
retroceso, la transacción entra en estado abortado y aunque la transacción no
cumplió su cometido, conservó su atomicidad.

4.2.2 Consistencia.
La propiedad consistencia también es conocida como coherencia. La coherencia
asegura que cualquier transacción llevará a la base de datos de un estado válido a
otro estado válido.

Cada transacción debe ser un conjunto de instrucciones que conserve la

consistencia de la base de datos, lo cual significa que las transacciones
comienzan en un estado consistente de la base de datos y terminan dejándola en
otro estado también consistente.

Cabe mencionar que una transacción no está obligada a conservar la consistencia

de la base de datos durante su ejecución, únicamente al terminar. Es decir, que no
importa que al ejecutar cada instrucción de la transacción se genere un estado
inconsistente temporal, siempre y cuando al terminar de ejecutar todas las
instrucciones de esa transacción, la base de datos mantenga su consistencia.

También se debe conservar la consistencia de la base de datos cuando se

ejecutan
transacciones de forma concurrente.

4.2.3 Aislamiento.
Una transacción debe estar aislada del resto de las transacciones. Esto quiere
decir que aunque existan muchas transacciones ejecutándose al mismo tiempo,
cualquier
modificación de datos que realice una transacción, está oculta para el resto de las
transacciones, hasta que dicha transacción termine su ejecución.

Esta propiedad sirve para que una transacción no pueda operar datos que otra
transacción está ocupando. Si no existiera aislamiento, se produciría un estado
inconsistente en la base de datos.

4.2.4 Permanencia.
Es la propiedad que asegura que, una vez realizada la operación, ésta persistirá y
no se podrá deshacer, aunque falle el sistema.

Significa que en el mismo momento en que una operación ha terminado

satisfactoriamente y el sistema informa de ello, sus efectos quedan ya registrados
permanentemente. Si el sistema falla no debe permitir que se pierdan las
operaciones realizadas por Tx ya confirmadas.

La propiedad permanencia también es conocida como durabilidad. Una vez que

una transacción se completa correctamente, sus efectos no se pueden modificar
sin ejecutar una transacción de compensación. Los cambios realizados por una
transacción correcta sobreviven a posteriores anomalías del sistema. Esto es,
deberían mantenerse incluso aunque se produjera un fallo de hardware o
software.

4.2.5 Propiedad adicional al ACID.

Serializabilidad: Además de las propiedades ACID, los estándares de SQL
estipulan que las transacciones deben ser serializables. Serializabilidad significa
que los efectos de un conjunto de transacciones simultáneas deben dar el mismo
resultado que si se ejecutaran en serie las transacciones individuales y que si
cada una de las transacciones tuviera un uso exclusivo del sistema

4.3 Grados de consistencia.

Consistencia es un término más amplio que el de integridad. Podría definirse como
la coherencia entre todos los datos de la base de datos. Cuando se pierde la
integridad también se pierde la consistencia. Pero la consistencia también puede
perderse por razones de funcionamiento.

Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base

de datos se encuentra en un estado consistente antes de ejecutar la transacción,
una vez que ésta termine la consistencia de la base de datos deberá conservarse.
Por consistente se debe entender, internamente consistente.

Una transacción 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 ejecución de una transacción 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 transacción que termina con éxito se dice que está comprometida. Para ver
esto mas a detalle veremos los estados que existen en las transacciones ya que
en cualquier momento una transacción sólo puede estar en uno de los siguientes
estados.

Activa. El estado inicial, la transacción permanece en este estado durante su

ejecución.

Parcialmente comprometida. Después de ejecutarse la ultima transacción.

Fallida. Tras descubrir que no se puede continuar la ejecución normal.

Abortada: Después de haber retrocedido la transacción y restablecido la base de

datos a su estado anterior al comienzo de la transacción.

Ilustración 1, Los diferentes estados de transacciones

4.3.1 Consistencia de grado dos.

Sabemos ahora que si todas las transacciones mantienen la consistencia de la
base de datos al ejecutarse solas, entonces el proceso de serialización podrá
garantizar que se mantenga la consistencia cuando las transacciones se ejecuten
concurrentemente. Pero para algunas aplicaciones, los protocolos pueden
provocar que se permita muy poca concurrencia, es en éstos casos cuando se
recurre a un nivel más débil de consistencia, que aunque implicarán una carga
adicional en los programadores para garantizar una base de datos correcta,
permitirán mayor concurrencia.

Uno de éstos “niveles débiles de consistencia” es conocido como “consistencia de

grado dos” y pretende evitar los abortos en cascada, sin necesariamente
garantizar la serialización. Utiliza los mismos modos de bloqueo que se usan en el
bloqueo de dos fases pero a diferencia del bloqueo de dos fases, los bloqueos
compartidos pueden liberarse en cualquier momento y los exclusivos no pueden
liberarse hasta que la transacción termine o aborte.

4.3.2 Estabilidad del cursor.

Otro nivel débil de consistencia es llamado “Estabilidad del cursor”, que es una
forma de consistencia de grado dos, pero fue creada para programas escritos con
propósito general, lenguajes orientados a registros como Pascal, o C que
normalmente trabajan sobre los registros de una relación, entonces la estabilidad
del cursor en vez de bloquear toda la relación, bloquea el registro que la iteración
está procesando en ese momento y todos los registros modificados permanecen
bloqueados en modo exclusivo hasta que la transacción termine.

4.4 Niveles de aislamiento.

El nivel de aislamiento es el grado que se aísla una transacción de las
modificaciones de recursos o datos realizadas por otras transacciones.

Se puede ajustar el nivel de aislamiento entre las transacciones y determinar para

una transacción el grado de aceptación de datos inconsistentes. A mayor grado de
aislamiento, mayor precisión, pero a costa de menor concurrencia.

El nivel de aislamiento para una sesión SQL establece el comportamiento de los

bloqueos para las instrucciones SQL.

Antes de entrar a los niveles de aislamiento, debemos comprender lo que son los
efectos de lectura, estos son casos en donde la transacción A lee datos que
pudieron haber sido modificados por la transacción B, existen 3 tipos diferentes.

 Lecturas sucias: Ocurre cuando se le permite a una transacción la lectura

de una fila que ha sido modificada por otra transacción concurrente pero
todavía no ha sido cometida.

 Lecturas no repetibles: Una lectura no repetible ocurre cuando en el curso

de una transacción una fila se lee dos veces y los valores no coinciden.

 Lecturas fantasmas: Ocurre cuando, durante una transacción, se ejecutan

dos consultas idénticas, y los resultados de la segunda son distintos de los
de la primera.

 Lectura no confirmada: Este es el nivel de aislamiento más bajo.

Los niveles de aislamiento son los siguientes:

Lectura no confirmada:
En esta es posible que ocurran lecturas sucias, la lecturas no repetibles y lecturas
fantasma.

Lectura confirmada:
En esta es posible que ocurran lecturas no repetibles y lecturas fantasma, pero
evita que ocurran lecturas sucias.

Lectura repetible:
En esta pueden ocurrir lecturas fantasmas, pero evita que ocurran lecturas sucias
y
lecturas no repetibles.

Serializable:
Este es el nivel de aislamiento más alto, evita por completo las lecturas sucias, las
lecturas no repetibles y las lecturas fantasmas.

Ilustración 2, Tabla de Niveles de aislamiento

4.5 Commit y Rollback.
4.5.1 Commit.
En el contexto de la ciencia de la computación y la gestión de datos, commit
(acción de comprometer) se refiere a la idea de consignar un conjunto de cambios
"tentativos, o no permanentes". Un uso popular es al final de una transacción de
base de datos.

Si la transacción que se ha confirmado era una transacción Transact-SQL

distribuida, COMMIT TRANSACTION hace que MS DTC utilice el protocolo de
confirmación en dos fases para confirmar los servidores involucrados en la
transacción. Si una transacción local afecta a dos o más bases de datos de la
misma instancia del Database Engine (Motor de base de datos), la instancia utiliza
una confirmación interna en dos fases para confirmar todas las bases de datos
involucradas en la transacción. Cuando se utiliza en transacciones anidadas, las
confirmaciones de las transacciones anidadas no liberan recursos ni hacen
permanentes sus modificaciones. Las modificaciones sobre los datos sólo quedan
permanentes y se liberan los recursos cuando se confirma la transacción más
externa.

En SQL finaliza una transacción de base de datos de un sistema gestor de base

de datos relacional (RDBMS) y pone visible todos los cambios a otros usuarios. El
formato general es emitir una sentencia BEGIN WORK, una o más sentencias
SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia
ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que
se emitió BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los
savepoints (puntos de recuperación) existentes que puedan estar en uso.

En términos de transacciones, lo opuesto de commit para descartar los cambios

"en
tentativa" de una transacción, es un rollback lo cual veremos a continuacion.

Ejemplo.

Begin tran
Insert into Mvtos Values (‘0150’, ‘Dep’, 1500, ’08-10-2008’)
Insert into Mvtos Values (‘7120’, ‘Ret’, 1500, ’08-10-2008’)
Update Cuentas Set Saldo = Saldo + 1 where Numero = ‘0150’
Update Cuentas Set Saldo = Saldo – 1 Where Numero = ‘7120’
Commit tran.

Con la instruccion commit tran se pone una marca para saber hasta que punto se
hizo la transaccion.
4.5.2 Rollback.
En tecnologías de base de datos, un rollback es una operación que devuelve a la
base de datos a algún estado previo. Los Rollbacks son importantes para la
integridad de la base de datos, a causa de que significan que la base de datos
puede ser restaurada a una copia limpia incluso después de que se han realizado
operaciones erróneas.

Son cruciales para la recuperación de crashes de un servidor de base de datos;

realizando rollback (devuelto) cualquier transacción que estuviera activa en el
tiempo del crash, la base de datos es restaurada a un estado consistente.

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 gestión 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.

Una instrucción rollback transaction que especifica un savepoint_name no

libera ningún bloqueo.

En una transacción se permiten nombres de puntos de almacenamiento

duplicados, pero una instrucción rollback transaction que utilice este nombre sólo
revierte las transacciones realizadas hasta la instrucción save transaction más
reciente que también utilice este nombre.

Ejemplo.

Ejemplo
Begin tran
<Comandos SQL>
<Comandos SQL>
Save tran Puntoseg
<Comandos SQL>
<Comandos SQL>
If @@ERROR <> 0
Rollback tran Puntoseg (cancela todo desde aquí hasta el punto de guardado)
Else
Commit tran
Conclusión.
Gracias al trabajo realizado y a la investigación de campo realizada podemos decir
que las bases de datos deben cumplir una serie de aspectos para que exista
coherencia entre sus datos, a esto se le llama consistencias. Para que exista
consistencia también se deben cumplir con las propiedades de las transacciones
las cual mencionamos en la investigación.

Otra cosa que se debe tomar en cuenta en la concurrencia son los niveles de
aislamiento de la base de datos y los grados de consistencia con los que debe
cumplir.

Una cosa que facilita mucho el empleo de una base de datos son las instrucciones
commit y rollback que nos permiten ir atrás o adelante de una serie de
transacciones, para poder emplear estas mismas comprendimos desde que punto
parte cada una de estas, sus funciones que tienen, sus características
respectivamente y la estructura que llevan para hacer uso de estas en lo que viene
siendo el ejercicio de esta misma competencia.

Referencias.
Tejada Betancourt, L. (Ed.) y Martínez Silverio, D. A. Manual de bases de datos.
Universidad Abierta para Adultos (UAPA), 2019. p.
https://elibro.net/es/ereader/bibliotesci/175897?page=129

Marqués, M. (2009). Bases de datos. D - Universitat Jaume I. Servei de

Comunicació i Publicacions. https://elibro.net/es/lc/bibliotesci/titulos/51645

SILBERSCHATZ, A., KORTH, H.F., SUDARSHAN, S. "Fundamentos de bases de

datos", 3ª edición, McGraw-Hill, 1998.

Nieto Bernal, W. y Nieto Bernal, W. (2017). Diseño de base de datos. Universidad

del Norte. https://elibro.net/es/lc/bibliotesci/titulos/70030

Galicia, G., Antonio, D., y Cruz, M.. (2013). Transacciones. Noviembre 8, 2017, de
SlideShare Sitio web: https://es.slideshare.net/dantoniocruz/transacciones-
27511077.