Transacción de base de datos

Una transacción de base de datos simboliza una unidad de trabajo, realizada dentro de un sistema de gestión de base de datos (o un sistema similar) contra una base de datos, que se trata de forma coherente y fiable independientemente de otras transacciones. Una transacción generalmente representa cualquier cambio en una base de datos. Las transacciones en un entorno de base de datos tienen dos propósitos principales:

1. Proporcionar unidades de trabajo fiables que permitan la recuperación correcta de los fallos y mantener una base de datos consistente incluso en casos de fracaso del sistema. Por ejemplo: cuando la ejecución se detiene prematura e inesperadamente (completa o parcialmente) en cuyo caso muchas operaciones en una base de datos permanecen incompletas, con estatus poco claro.
2. Proporcionar aislamiento entre programas que accedan a una base de datos simultáneamente. Si no se proporciona este aislamiento, los resultados de los programas son posiblemente erróneos.

En un sistema de administración de base de datos, una transacción es una sola unidad de lógica o trabajo, a veces compuesta de múltiples operaciones. Cualquier cálculo lógico realizado en un modo consistente en una base de datos se conoce como transacción. Un ejemplo es una transferencia de una cuenta bancaria a otra: la transacción completa requiere restar el monto a transferir de una cuenta y agregar ese mismo monto a la otra.

Una transacción de base de datos, por definición, debe ser atómica (debe estar completa en su totalidad o no tener ningún efecto), consistente (debe ajustarse a las restricciones existentes en la base de datos), aislada (no debe afectar otras transacciones) y duradero (debe escribirse en un almacenamiento persistente). Los profesionales de bases de datos a menudo se refieren a estas propiedades de las transacciones de bases de datos utilizando el acrónimo ACID.

Propósito

Las bases de datos y otros almacenes de datos que tratan la integridad de los datos como algo primordial a menudo incluyen la capacidad de manejar transacciones para mantener la integridad de los datos. Una sola transacción consta de una o más unidades de trabajo independientes, cada una de las cuales lee y/o escribe información en una base de datos u otro almacén de datos. Cuando esto sucede, a menudo es importante asegurarse de que todo ese procesamiento deje la base de datos o el almacén de datos en un estado coherente.

Los ejemplos de los sistemas de contabilidad de partida doble a menudo ilustran el concepto de transacciones. En la contabilidad por partida doble, cada débito requiere el registro de un crédito asociado. Si uno escribe un cheque por $ 100 para comprar comestibles, un sistema de contabilidad transaccional de doble entrada debe registrar las siguientes dos entradas para cubrir la transacción única:

1. Debit $100 a la cuenta de gastos de los negocios
2. Crédito $100 a Cuenta de Verificación

Un sistema transaccional haría que ambas entradas pasaran o ambas fallarían. Al tratar el registro de entradas múltiples como una unidad de trabajo transaccional atómica, el sistema mantiene la integridad de los datos registrados. En otras palabras, nadie termina en una situación en la que se registra un débito pero no se registra un crédito asociado, o viceversa.

Bases de datos transaccionales

Una base de datos transaccional es un DBMS que proporciona las propiedades ACID para un conjunto entre paréntesis de operaciones de base de datos (begin-commit). Todas las operaciones de escritura dentro de una transacción tienen un efecto de todo o nada, es decir, la transacción se realiza correctamente y todas las escrituras tienen efecto o, de lo contrario, la base de datos pasa a un estado que no incluye ninguna de las escrituras de la transacción.. Las transacciones también aseguran que el efecto de las transacciones concurrentes satisfaga ciertas garantías, conocidas como nivel de aislamiento. El nivel de aislamiento más alto es la serialización, que garantiza que el efecto de las transacciones simultáneas sea equivalente a su ejecución en serie (es decir, secuencial).

La mayoría de los sistemas modernos de administración de bases de datos relacionales admiten transacciones. Las bases de datos NoSQL priorizan la escalabilidad junto con las transacciones de soporte para garantizar la consistencia de los datos en caso de actualizaciones y accesos simultáneos.

En un sistema de base de datos, una transacción puede consistir en una o más declaraciones y consultas de manipulación de datos, cada una de las cuales lee o escribe información en la base de datos. Los usuarios de los sistemas de bases de datos consideran que la coherencia y la integridad de los datos son muy importantes. Por lo general, se emite una transacción simple al sistema de base de datos en un lenguaje como SQL envuelto en una transacción, utilizando un patrón similar al siguiente:

1. Comience la transacción.
2. Ejecute un conjunto de manipulaciones y/o consultas de datos.
3. Si no se produce ningún error, entonces comete la transacción.
4. Si se produce un error, entonces vuelva a rodar la transacción.

Una operación de confirmación de transacción conserva todos los resultados de la manipulación de datos dentro del alcance de la transacción en la base de datos. Una operación de reversión de transacciones no conserva los resultados parciales de las manipulaciones de datos dentro del alcance de la transacción en la base de datos. En ningún caso se puede comprometer una transacción parcial con la base de datos, ya que eso dejaría la base de datos en un estado inconsistente.

Internamente, las bases de datos multiusuario almacenan y procesan transacciones, a menudo mediante el uso de un ID de transacción o XID.

Existen varias formas diferentes de implementar las transacciones además de la forma simple documentada anteriormente. Las transacciones anidadas, por ejemplo, son transacciones que contienen declaraciones dentro de ellas que inician nuevas transacciones (es decir, subtransacciones). Las transacciones multinivel son una variante de las transacciones anidadas en las que las subtransacciones tienen lugar en diferentes niveles de una arquitectura de sistema en capas (por ejemplo, con una operación en el nivel del motor de base de datos, una operación en el nivel operativo). -Nivel del sistema). Otro tipo de transacción es la transacción de compensación.

En SQL

Las transacciones están disponibles en la mayoría de las implementaciones de bases de datos SQL, aunque con diferentes niveles de solidez. Por ejemplo, MySQL comenzó a admitir transacciones desde la versión anterior 3.23, pero el motor de almacenamiento InnoDB no estaba predeterminado antes de la versión 5.5. El motor de almacenamiento anterior disponible, MyISAM, no admite transacciones.

Por lo general, una transacción se inicia con el comando BEGIN (aunque el estándar SQL especifica START TRANSACTION). Cuando el sistema procesa una instrucción COMMIT, la transacción finaliza con una finalización exitosa. Una instrucción ROLLBACK también puede finalizar la transacción, deshaciendo cualquier trabajo realizado desde BEGIN. Si la confirmación automática se deshabilitó con el inicio de una transacción, la confirmación automática también se volverá a habilitar al final de la transacción.

Uno puede establecer el nivel de aislamiento para operaciones transaccionales individuales así como globalmente. En el nivel más alto (READ COMMITTED), el resultado de cualquier operación realizada después de que se haya iniciado una transacción permanecerá invisible para otros usuarios de la base de datos hasta que finalice la transacción. En el nivel más bajo (READ UNCOMMITTED), que puede usarse ocasionalmente para garantizar una alta concurrencia, dichos cambios serán visibles de inmediato.

Bases de datos de objetos

Las bases de datos relacionales se componen tradicionalmente de tablas con campos y registros de tamaño fijo. Las bases de datos de objetos comprenden blobs de tamaño variable, posiblemente serializables o que incorporan un tipo MIME. Las similitudes fundamentales entre las bases de datos relacionales y de objetos son el inicio y la confirmación o reversión.

Después de iniciar una transacción, los registros de la base de datos o los objetos se bloquean, ya sea de solo lectura o de lectura y escritura. Entonces pueden ocurrir lecturas y escrituras. Una vez que la transacción está completamente definida, los cambios se confirman o revierten atómicamente, de modo que al final de la transacción no haya inconsistencias.

Transacciones distribuidas

Los sistemas de bases de datos implementan transacciones distribuidas como transacciones que acceden a datos a través de múltiples nodos. Una transacción distribuida aplica las propiedades ACID en varios nodos y puede incluir sistemas como bases de datos, administradores de almacenamiento, sistemas de archivos, sistemas de mensajería y otros administradores de datos. En una transacción distribuida, normalmente hay una entidad que coordina todo el proceso para garantizar que todas las partes de la transacción se apliquen a todos los sistemas relevantes.

Sistemas de archivos transaccionales

El sistema de archivos Namesys Reiser4 para Linux admite transacciones y, a partir de Microsoft Windows Vista, el sistema de archivos NTFS de Microsoft admite transacciones distribuidas entre redes. Se están realizando investigaciones sobre sistemas de archivos más coherentes con los datos, como el sistema de archivos transaccional Warp (WTF).