El modelo ACID

El modelo ACID es fundamental para garantizar la integridad y consistencia de los datos en las bases de datos. Profundicemos en cada una de sus propiedades:

Atomicidad (Atomicity)

• Todo o nada: Una transacción se ejecuta como una unidad indivisible. Si una parte de la transacción falla, toda la transacción se deshace, dejando la base de datos en el mismo estado que antes de que comenzara.
• Ejemplo: En una transferencia bancaria, si el dinero se debita de una cuenta pero no se acredita en la otra debido a un error, la transacción se deshace y ambas cuentas permanecen sin cambios.

Consistencia (Consistency)

• Integridad de los datos: Una transacción transforma la base de datos de un estado válido a otro estado válido. Esto significa que se cumplen todas las reglas de integridad definidas para la base de datos.
• Ejemplo: En una base de datos de un banco, una transacción que transfiere dinero debe asegurarse de que el saldo total de todas las cuentas permanezca igual.

Aislamiento (Isolation)

• Transacciones independientes: Cada transacción se ejecuta como si fuera la única que está accediendo a la base de datos. Esto evita que los resultados de una transacción se vean afectados por otras transacciones concurrentes.
• Ejemplo: Si dos usuarios están intentando comprar el mismo artículo al mismo tiempo, las transacciones de ambos usuarios deben ser aisladas para evitar que se venda el artículo a ambos.

Durabilidad (Durability)

• Cambios permanentes: Una vez que una transacción se ha completado con éxito, los cambios que ha realizado se hacen permanentes, incluso en caso de fallas del sistema.
• Ejemplo: Si se produce un corte de energía después de que una transacción se haya confirmado, los cambios realizados por la transacción deben persistir cuando el sistema se recupere.

Niveles de Aislamiento

El nivel de aislamiento define qué tan aisladas están las transacciones entre sí. Los niveles de aislamiento más comunes son:

• Read Uncommitted: Una transacción puede leer datos no confirmados por otras transacciones, lo que puede llevar a problemas de lectura sucia.
• Read Committed: Una transacción solo puede leer datos que han sido confirmados por otras transacciones, evitando problemas de lectura sucia.
• Repeatable Read: Una transacción recibe siempre los mismos datos para las mismas filas, a menos que esas filas sean modificadas por la propia transacción.
• Serializable: El más alto nivel de aislamiento, garantiza que las transacciones se ejecuten como si se ejecutaran secuencialmente, evitando todos los problemas de concurrencia.

Implementación de Transacciones

Las transacciones se implementan a nivel de sistema de gestión de bases de datos (SGBD) utilizando un protocolo de dos fases:

1. Fase de preparación: El SGBD verifica si se pueden realizar los cambios solicitados por la transacción. Si todo está bien, se marca la transacción como lista para confirmar.
2. Fase de confirmación: Si todas las transacciones en la fase de preparación son exitosas, se confirman los cambios y se actualizan los registros de la base de datos. Si alguna transacción falla, se deshacen todos los cambios.

Ejemplos.

Ejemplos de Transacciones ACID

1. SQL Server

SQL

BEGIN TRANSACTION;
UPDATE Cuentas SET Saldo = Saldo - 100 WHERE IdCuenta = 1;
UPDATE Cuentas SET Saldo = Saldo + 100 WHERE IdCuenta = 2;
COMMIT TRANSACTION;

• Explicación: Esta transacción transfiere 100 unidades monetarias de la cuenta 1 a la cuenta 2. Si alguna de las actualizaciones falla, toda la transacción se deshace gracias a ROLLBACK TRANSACTION.

2. Oracle

SQL

BEGIN;
UPDATE cuentas SET saldo = saldo - 100 WHERE id_cuenta = 1;
UPDATE cuentas SET saldo = saldo + 100 WHERE id_cuenta = 2;
COMMIT;

• Explicación: Similar al ejemplo de SQL Server, esta transacción realiza una transferencia entre dos cuentas. Oracle utiliza BEGIN y COMMIT para delimitar las transacciones.

3. PostgreSQL

SQL

BEGIN;
UPDATE cuentas SET saldo = saldo - 100 WHERE id_cuenta = 1;
UPDATE cuentas SET saldo = saldo + 100 WHERE id_cuenta = 2;
COMMIT;

• Explicación: La sintaxis de PostgreSQL es muy similar a la de Oracle para las transacciones.

Otro Ejemplo (más complejo): Reserva de Vuelo y Hotel

SQL

BEGIN TRANSACTION;
    -- Reservar vuelo
    INSERT INTO ReservasVuelos (ClienteId, VueloId) VALUES (1, 123);
    -- Reservar hotel
    INSERT INTO ReservasHoteles (ClienteId, HotelId) VALUES (1, 456);
COMMIT TRANSACTION;

• Explicación: Esta transacción reserva un vuelo y un hotel para un cliente. Si alguna de las reservas falla (por ejemplo, no hay disponibilidad), toda la transacción se deshace, evitando que el cliente tenga una reserva de vuelo sin hotel o viceversa.

Consideraciones Adicionales

• Niveles de aislamiento: Cada SGBD ofrece diferentes niveles de aislamiento (Read Uncommitted, Read Committed, Repeatable Read, Serializable) que afectan cómo se ven los datos no confirmados por otras transacciones.
• Aislamiento a nivel de fila: Algunos SGBD permiten un aislamiento a nivel de fila, lo que significa que solo las filas afectadas por una transacción están bloqueadas para otras transacciones.
• Transacciones distribuidas: En sistemas distribuidos, las transacciones pueden involucrar múltiples bases de datos. Los protocolos de dos fases (2PC) o tres fases (3PC) se utilizan para coordinar las transacciones en este escenario.