Unidad 1 / Escenario 2

Lectura fundamental

Evaluación y uso de
funcionalidades ACID

Contenido
1 Fundamentos de las bases de datos
2 ¿Qué es persistencia?
3 Conceptos fundamentales de modelos de bases de datos
4 ¿Qué es Transacción?
5 Propiedades ACID
6 Estado de las transacciones
7 Modelo de programación de una transacción
8 Bloqueos de una transacción y Fallo de transacciones
9 Datos inseguros
10 Recuperación
11 Commit
12 Rollback
Palabras claves: base de datos, acid, commit, rollback, persistencia.
1. Fundamentos de las bases de datos
Los motores de bases de datos son manejados por los sistemas de gestión de bases de datos, los
cuales trabajan de manera concurrente, es decir que se pueden realizar consultas y las demás ope-
raciones DML (Lenguaje de manipulación de datos), de manera concurrente. Un ejemplo que se pue-
de citar, es el proceso que se realiza sobre la tabla de saldos de la aplicación de cuentas de ahorros
de un banco, donde muchos de los clientes están accediendo a dicha tabla de manera simultánea.

2. ¿Qué se entiende por persistencia de datos?

Es el procedimiento que permite realizar almacenamiento de datos, comúnmente denominado
persistencia de la información de un sistema transaccional. Para llevar a cabo estas operacio-
nes, se debe entender en qué consiste un sistema de almacenamiento NAS (Network Attached
Storage) que sirve archivos a través de una red de área local (LAN). Igualmente es necesario
saber de qué elementos está compuesta una NAS. Una NAS, está compuesta a nivel de hardwa-
re por un procesador, conjunto de discos duros y de un módulo de conexión a la red.

3. Conceptos fundamentales de modelos de bases de datos

En conclusión, una transacción es una operación que genera o modifica los datos de ítem que
se encuentra guardado en un sistema de información.

4. ¿Qué es Transacción?
Un sistema transaccional consiste en el desarrollo de las operaciones que realizan una aplica-
ción que requiere almacenar, recolectar, consultar o modificar los datos generados por una ope-
ración de transacción realizada por una aplicación de este tipo en una empresa u organización.
En conclusión, una transacción es una operación que genera o modifica los datos de ítem que
se encuentra guardado en un sistema de información.

5. Propiedades ACID
Los mecanismos de gestión de transacciones proporcionados por un motor de base de datos
como Oracle, implementan lo que comúnmente se conoce como prueba ACID (atomicidad, con-
sistencia, aislamiento y durabilidad - atomicity, consistency, isolation and durability).

POLITÉCNICO GRANCOLOMBIANO 2
5.1 Atomicidad

El principio de atomicidad establece que todas las partes de una transacción deben completarse
o ninguna de ellas se realiza. Por ejemplo, si cada vez que cambia el salario de un empleado tam-
bién se debe cambiar el grado del empleado, esto es, la transacción es atómica las dos actualiza-
ciones se realizan. La base de datos debe garantizar que ambas operaciones se hacen o ninguna
se hace. Si solo una operación tiene éxito, se tendrá un empleado con un sueldo incompatible
con su grado. Esto es lo que se conoce como corrupción de datos. Si algo sale mal antes de que
la transacción esté completa, la base de datos debe garantizar que todas las partes que pasaron
se inviertan; esto debe ocurrir automáticamente. La reversión de una transacción incompleta
puede ser manual (como cuando emite el comando ROLLBACK), pero debe ser automática.

5.2 Consistencia

El principio de consistencia indica que los resultados de una consulta deben ser coherentes con
el estado de la base de datos en el momento en que comenzó la consulta. Imagínese una con-
sulta que saca el promedio del valor de una columna de una entidad (tabla). Si la tabla es muy
grande, tardará muchos minutos en recorrer toda tabla.

Si otros usuarios están actualizando la columna mientras la consulta está en progreso, pode-
mos hacer las siguientes preguntas:

• ¿Debería la consulta incluir los valores nuevos o antiguos?

• ¿Debería incluir filas que se insertaron o eliminaron después de iniciada la consulta?

El principio de consistencia requiere que la base de datos asegure que los valores cambiados no
sean vistos por la consulta; que le dará un promedio de la columna como lo fue cuando la con-
sulta comenzó, no importa cuánto tiempo toma la consulta o qué otra actividad está ocurriendo
en las tablas en cuestión.

5.3 Aislamiento

El principio de aislamiento establece que una transacción incompleta (es decir, no comprome-
tida) debe ser invisible para el resto del mundo. Mientras la transacción está en progreso, sólo
la sesión que está ejecutando la transacción puede ver los cambios; Todas las demás sesiones
deben ver los datos no modificados, no los nuevos valores, es decir:

POLITÉCNICO GRANCOLOMBIANO 3
 • La transacción completa podría no tener éxito y por lo tanto, ningún otro usuario debe ver
los cambios que podrían ser revertidos.

• Durante el progreso de una transacción, los datos son incoherentes (en términos comer-
ciales): hay un corto tiempo cuando el empleado ha tenido su salario cambiado, pero no
su grado.

• El aislamiento de transacciones requiere que la base de datos oculte las transacciones

en progreso de otros usuarios: verán la versión pre-actualizada de los datos hasta que se
complete la transacción, cuando verán todos los cambios como un conjunto coherente.

5.3.1 Niveles de aislamiento

En una sesión SQL, el nivel de aislamiento establece los bloqueos que deben ejecutarse
en las instrucciones SQL. Estos son:

• Lectura no comprometida. Asegura que no sean leídos los datos corruptos.

• Lectura comprometida. Solo se permiten lecturas de datos comprometidos.

• Lectura repetible. Lecturas repetidas de las mismas filas, dan los mismos datos.

• Secuenciable. Las transacciones se aíslan al 100%.

Comportamiento concurrente de las transacciones

• Lectura sucia. Lectura de datos no comprometidos.

• Lectura no repetible. Con las lecturas repetidas se obtienen resultados no deseados.

• Lectura Fantasma: Es cuando se hace lectura de una fila que no existía cuando empe-
zó la transacción.

Tabla 1. Niveles de aislamiento.

1.COMPORTAMIENTOS PERMITIDOS
2. Nivel de aislamiento 3. Lectura sucia 4. Lectura no repetible 5. Lectura fantasma
6. Lectura no comprometida 7. SI 8. SI 9. SI
10. Lectura comprometida 11. NO 12. SI 13. SI
14. Lectura repetible 15. NO 16. NO 17. NO
18. Secuenciable 19. NO 20. NO 21. NO
Fuente: Rojas, Alexis. (2017)

POLITÉCNICO GRANCOLOMBIANO 4
5.4 Durabilidad

El principio de durabilidad establece que una vez que una transacción se completa, debe ser
imposible para la base de datos perderla. Durante el tiempo que la transacción está en progreso,
el principio de aislamiento requiere que nadie (aparte de la sesión) pueda ver los cambios que
ha hecho hasta ahora. En el instante en que la transacción se completa, se debe poder ver por
cualquier usuario que tenga permisos y la base de datos debe garantizar que el cambio nunca
se pierda.

Una base de datos relacional no puede perder datos. Los datos pueden perderse a través de
errores de usuario cuando usa instrucciones DML inapropiadas, o cuando elimina caer o trunca
tablas.

6. Estado de las transacciones

Una transacción cuando termina bien, se denomina transacción comprometida., de lo contrario
es una transacción revocada. Una transacción comprometida, no se puede reversar. La única
forma de reversar los cambios, es ejecutando otra transacción denominada transacción com-
pensadora.

Ejemplo: Si abonas $20.000 a una cuenta de ahorros y se equivocó de cuenta, la única

manera de revesarla, es enviado una transacción de reverso por -$20.000 a la cuenta equi-
vocada y luego sí hacer la transacción de abono a la cuenta correcta. Las transacciones
compensadoras no las gestiona la base de datos. Lo tiene que hacer el responsable de las
operaciones en la aplicación [2].

¿Qué se entiende por fin de una transacción?

• Activa: Durante su ejecución.

• Parcialmente comprometida: Después de ejecutarse la última instrucción.

• Fallida: Cuando la transacción no puede continuar su ejecución normal.

• Abortada: Transacción retrocedida y base de datos restaurada al estado anterior an-

tes de comenzar la operación.

• Comprometida o en ejecución. Transacción exitosa.

POLITÉCNICO GRANCOLOMBIANO 5
Figura 1. Diagrama de estados de una transacción
Fuente: Politecnico Grancolombiano, (2017)

7. Modelo de programación de una transacción

Para ilustrar una transacción de transferencia financiera entre dos cuentas en lenguaje plsql de
Oracle, veamos el siguiente diagrama:
CREATE OR REPLACE PROCEDURE transacciontx IS
COMENZAR v_valor_tx NUMBER(10,2);
v_cta_origen NUMBER(10);
v_cta_destin NUMBER(10);
BEGIN
TRANSACCION TX v_valor_tx := 1000000.00;
v_cta_origen := 2458000198;
SELECT C1 v_cta_destin := 6075010452;
SELECT C2
UPDATE C1 select c1 from ahorros where cta_cte = v_cta_origen;
UPDATE C2 select c1 from ahorros where cta_cte = v_cta_destin;
INSERT M1
INSERT M2 -- Las cuentas existen
update ahorros set saldo = saldo - v_valor_tx
where cta_cte = v_cta_origen; -- Restamos
update ahorros set saldo = saldo + v_valor_tx
where cuenta = v_cta_destin; -- Sumamos
NO SI insert into mvto values (v_cta_origen, v_valor_tx*(-1), sysdate)
TX CORRECTA ?
insert into mvto values (v_cta_destin, v_valor_tx, sysdate)
commit;
exception
when others then
ROLLBACK COMMIT dbms_output.put_line('error en la transaccion:'||sqlerrm);
dbms_output.put_line('se deshacen las operaciones);
rollback;
END transacciontx;
/
TERMINAR

Figura 2. Diagrama de un grupo de transacciones

Fuente: Elaboración propia, (2017)

POLITÉCNICO GRANCOLOMBIANO 6
Como se puede observar, primero se consultan las cuentas, luego se actualizan las cuentas y
después se ingresa el movimiento a la tabla de movimientos. Si todo sale bien, se hace COMMIT
(punto de compromiso --> el commit) para registrar las operaciones en la base de datos, de lo
contrario se levantan todas las operaciones con ROLLBACK.

8. Bloqueos de una transacción

Un bloqueo es una operación al tipo de acceso que se permite a un elemento del objeto como por
ejemplo filas, columnas, relaciones, etc., para asegurar la secuencialidad de una operación; esto
con el fin de que ninguna otra transacción opere sobre el elemento en cuestión. El SGBD (Siste-
ma de Gestión de la Base de Datos) impone los bloqueos necesarios en cada momento. El gestor
de acceso a los datos implementa las restricciones de acceso.

8.1 Tipos de bloqueos:

• read-locks: Sólo se permite para lectura

• write-locks: Se permite para lectura y escritura

El SGBD opera con el gestor de bloqueos y almacena los bloqueos en una tabla de bloqueos,
donde carga los elementos que intervienen en el bloqueo y son; (<elemento E>, <tipo de bloqueo
B>, <transacción T>), lo cual indica que la transacción T tiene un tipo de bloqueo B sobre el ele-
mento E.

8.2 Niveles de bloqueos:

Se refiere a los elementos que son bloqueados para hacer una operación. Estos niveles de bloqueo
son:
• Por clave: Bloquea un registro con base en la llave del registro.
• Por fila: Bloque una tupla.
• Por Página: Depende del motor de base de datos. Por lo general bloquean páginas de
8KB
• Por Extent: Bloqueo por extensiones grupos de 8 páginas de datos e índices.
• Por tabla. Bloquea una tabla completa.
• Por base de datos: Se inhabilita la base de datos completa.

POLITÉCNICO GRANCOLOMBIANO 7
8.3 Modos de bloqueos:
Existen muchos modos de bloqueos sobre un elemento de datos, pero en este apartado solo se
revisan los modos más usados:

• Modo Compartido: Si una transacción Ti, obtiene un bloqueo en modo compartido que
llamaremos C, con otra transacción Tj, sobre un elemento Q, entonces Ti puede leer a Q,
pero no puede escribir sobre Q [2] Página 383.

• Modo Exclusivo: Si una transacción Ti, obtiene un bloqueo en modo exclusivo que llama-
remos X, con otra transacción Tj, sobre un elemento Q, entonces Ti puede leer y escribir
sobre Q [2] Página 383.

8.4 Planificación de concurrencia:

Existen algoritmos que planifican el orden en que deben entrar las operaciones de las transac-
ciones sobre un elemento, para que se guarde el orden y las operaciones no fracasen, dado que
están siendo concurrentes, es decir, están tratando de acceder al mismo recurso a la vez.

• Ejemplo:

Solicitar Bloquear X(R);

Leer (R);

R := R - 100;

Escribir (R);
Desbloquear (R);

Bloquear X(P);

Leer (P);

P := P - 80;

Escribir (P);

Desbloquear (P);

Aquí vemos la secuencia que se lleva a cabo, para proteger un elemento de una transacción,
para que otra transacción no la dañe.

POLITÉCNICO GRANCOLOMBIANO 8
Veamos cómo sería la operación de dos transacciones sobre los elementos A y B.

Figura 3. Secuencia de bloqueos de dos transacciones sobre los elementos A y B

Fuente: Cebrián Marín, Diego (2014). Página 385

8.5 Fallo de transacciones

Una transacción puede fallar por varios motivos que pueden ser generados por el usuario o por
el sistema operacional o por el hardware o por el software.

Causas de falla:
A. Fallo de la transacción: Puede ser por interrupción por el usuario, fallo aritmético, privile-
gios de acceso, etc.,
B. Deadlock: muerte de una transacción,
C. Algoritmos de secuencialidad: Porque el algoritmo ordena la caída de la transacción por
algún evento que ha detectado que le impide completar la TX,
D. Error software o hardware.

Cuando las fallas son por errores en software o hardware, la recuperación debe hacerse con
base en las copias de seguridad.

POLITÉCNICO GRANCOLOMBIANO 9
9. Datos inseguros
Se habla de datos inseguros, cuando se está haciendo una operación y aparece un evento que
hace que la transacción o parte de la misma falle.

Ejemplo: Si se está llevando a cabo una transferencia y falla la inserción de movimiento que tie-
ne que ver con los datos de la cuenta destino en la tabla de movimiento, por cualquier razón (se
llenó la tabla, se bloqueó el disco, etc.), se debe hacer un rollback en cascada para que los datos
no queden inseguros.

10. Recuperación
La recuperación de los datos se puede resolver de diferentes maneras. Es indispensable que
exista dentro de la compañía una norma de respaldo de la información. Algunas de las formas
de salvaguardar la información son:

• Backup completo

• Backup incremental

• Información espejada (Discos Raid-1 o Raid 1+0).

La recuperación se puede llevar a cabo de diferentes maneras:

• Restaurando la información de un Backup.

• Haciendo un reproceso de la información a partir del punto donde se presentó la falla.

(Es una metodología costosa en tiempo, dinero y good will).

• Devolviendo las transacciones con rollback, cuando la transacción no ha tenido commit.

• Enviando una transacción de reverso, cuando el commit ya había sido ejecutado.

• Recuperación basada en logs de la base de datos.

11. Commit
Cuando una transacción que termina con éxito se dice que está comprometida (commited).

COMMIT: La sentencia commit finaliza la transacción actual y hace que los cambios realizados
dentro de la base de datos se vuelvan permanentes.

Una sentencia COMMIT en SQL TERMINA una transacción de base de datos dentro de un sistema
gestor de base de datos relacional (RDBMS) y hace visibles todos los cambios a los usuarios.

POLITÉCNICO GRANCOLOMBIANO 10
12. Rollback
ROLLBACK: La sentencia rollback, termina la transacción actual y deshace los cambios realiza-
dos, cuando los datos tratados no son los esperados, para que queden permanentes dentro de
la base de datos.

En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última
sentencia commit ejecutada, sean descartados por el sistema de gestión de base de datos rela-
cional (RDBMS).

POLITÉCNICO GRANCOLOMBIANO 11
Referencias
[1] Cebrián Marín, Diego (2014). Sistemas de almacenamiento: administración de bases de datos.
Editorial, IC Editorial, Fecha July 2014. Página 7 a 60. Recuperado de: http://site.ebrary.com.
loginbiblio.poligran.edu.co:2048/lib/bibliopoligransp/reader.action?docID=11126445&ppg=11

[2] Sudarshan, S. Fundamento de base de datos. Professor of Computer Science, Indian Institute
of Technology, Bombay. Database systems. Recuperado de: https://scholar.google.es/cita-
tions?user=KtP9-zYAAAAJ&hl=es&oi=sra

[3] Artículo: Un modelo de persistencia para el diseño de la base de datos basado en un modelo de
objetos formal. Recuperado de: http://web.a.ebscohost.com.loginbiblio.poligran.edu.co:2048/
ehost/pdfviewer/pdfviewer?vid=10&sid=ee84cd14-e0ec-4ccd-8a94-63b0c780fc97%40session-
mgr4009&hid=4109

[4] Artículo: Directrices para la construcción de artefactos de persistencia en el proceso de desarro-

llo de software. Recuperado de: http://web.a.ebscohost.com.loginbiblio.poligran.edu.co:2048/
ehost/pdfviewer/pdfviewer?vid=7&sid=ee84cd14-e0ec-4ccd-8a94-63b0c780fc97%40sessionm-
gr4009&hid=4109

[5] Jiménez Capel, María Yolanda (2014). Bases de datos relacionales y modelado de datos. Edito-
rial IC Editorial. Fecha. July 2014.

POLITÉCNICO GRANCOLOMBIANO 12
 INFORMACIÓN TÉCNICA

Módulo: Persistencia y Datos Transaccionales

Unidad 1: Sistemas de información transaccionales con

características ACID
Escenario 2: Evaluación y uso de funcionalidades ACID

Autor: Alexis Rojas Cordero

Asesor Pedagógico: Heidy Moncada

Diseñador Gráfico: Santiago Rodriguez
Asistente: Ana Milena Raga

Este material pertenece al Politécnico Grancolombiano.

Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO 13