Transacciones de bases de datos

A transacción se compone de una unidad de trabajo realizado dentro de un sistema de gestión de base de datos (o sistema similar) contra una base de datos y tratados en forma coherente y fiable independiente de otras transacciones. Las transacciones en un entorno de base de datos tienen dos propósitos principales:

1. Para proporcionar confiables unidades de trabajo que permitan la recuperación correcta de fracasos y mantén una base de datos consistente incluso en los casos del sistema falla, cuando se detiene la ejecución (parcial o completamente) y muchas operaciones sobre una base de datos siguen siendo incompletas, con estatus incierto.
2. Proporcionar aislamiento entre programas que acceden a una base de datos simultáneamente. Si no se proporciona este aislamiento, resultado del programa son posiblemente errónea.

Una transacción de base de datos, por definición, debe ser atómico, constante, aislado y durable. Los practicantes de la base de datos a menudo se refieren a estas propiedades de las transacciones de la base de datos utilizando el acrónimo ÁCIDO.

Transacciones proporcionan una proposición "todo o nada", indicando que cada unidad de trabajo realizada en una base de datos debe completar en su totalidad o no tienen efecto alguno. Además, el sistema debe aislar cada transacción de otras transacciones, resultados deben ajustarse a las restricciones existentes en la base de datos y las transacciones que completan con éxito deben se escriben para almacenaje durable.

Propósito

Bases de datos y otros datos de tiendas que tratar la integridad de datos como primordial a menudo incluyen la capacidad de manejar las operaciones para mantener la integridad de los datos. Una sola transacción consiste en una o más unidades independientes de trabajo, cada lectura 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 este tratamiento deja el almacén de base de datos o datos en un estado coherente.

Ejemplos de sistemas de contabilidad de doble entrada a menudo ilustrar el concepto de transacciones. En la partida doble contabilidad cada débito requiere la grabación de un crédito asociado. Si uno escribe un cheque por $100 comprar víveres, un sistema de contabilidad de doble entrada transaccional debe registrar las siguientes dos entradas para cubrir la transacción:

1. $100 de débito a la cuenta de gastos de comestibles
2. $100 de crédito a la cuenta de cheques

Un sistema transaccional que pasar ambas entradas o ambas entradas fracasaría. Por el tratamiento de la grabación de múltiples entradas como una unidad transaccional atómica de trabajo el sistema mantiene la integridad de los datos registrados. En otras palabras, nadie termina con una situación en la que se registra un débito pero crédito asociado no está grabada, o viceversa.

Bases de datos transaccionales

A base de datos transaccional es un DBMS donde escribir las transacciones sobre la base de datos son capaces de rodar si no se completen correctamente (por ejemplo debido a la pérdida de potencia o conectividad).

Más modernos sistemas de gestión de base de datos relacional caen en la categoría de bases de datos que soportan las transacciones.

En un sistema de base de datos una transacción puede ser uno o más declaraciones de manipulación de datos y consultas, cada lectura o escritura de información en la base de datos. Usuarios de sistemas de base de datos considerar consistencia y integridad de datos como muy importante. Una simple transacción generalmente se emite para el sistema de base de datos en un lenguaje como el SQL envuelto en una transacción, utilizando un patrón similar al siguiente:

1. Iniciar la transacción
2. Ejecutar un conjunto de manipulaciones de datos y/o consultas
3. Si no hay errores se producen entonces la transacción y fin
4. Si los errores producen entonces deshacer la transacción y terminar

Si no hay errores ocurrieron durante la ejecución de la transacción el sistema compromete la transacción. Una operación de confirmación de transacción aplica todas las manipulaciones de datos en el ámbito de la transacción y persiste los resultados a la base de datos. Si se produce un error durante la transacción, o si el usuario especifica un rollback la operación, las manipulaciones de datos dentro de la transacción no persisten en la base de datos. En ningún caso puede una transacción parcial estar comprometida con la base de datos ya que eso dejaría la base de datos en un estado incoherente.

Internamente, multiusuario bases de datos de almacén y proceso de transacciones, a menudo utilizando una transacción ID o XID.

Hay varias formas diferentes para las transacciones a ser implementado que documentó por encima de la forma más sencilla. Transacciones anidadas, por ejemplo, son transacciones que contienen declaraciones dentro de los que se inician nuevas transacciones (i.e. subtransacciones). Transacciones de niveles múltiples son una variante de transacciones anidadas donde las subtransacciones llevará a cabo en los diferentes niveles de la arquitectura de un sistema de capas (por ejemplo, con una operación a nivel de motor de base de datos, una operación a nivel de sistema operativo) Otro tipo de transacción es la transacción de compensación.

En SQL

Las transacciones están disponibles en la mayoría las implementaciones de bases de datos SQL, aunque con diferentes niveles de robustez. (MySQL, por ejemplo, no soporta las transacciones en el MyISAM motor de almacenamiento, que era su motor de almacenamiento predeterminado antes de la versión 5.5.)

Una transacción se inicia típicamente mediante el comando BEGIN (aunque el estándar SQL especifica INICIAR TRANSACCIÓN). Cuando el sistema procesa un COMETER Declaración, la transacción termina con éxito. A ROLLBACK Declaración también puede terminar la transacción, deshacer cualquier trabajo realizado desde BEGIN TRANSACTION. If autocommit se deshabilitó el uso INICIAR TRANSACCIÓN, autocommit también se vuelve a activar al final de la transacción.

Uno puede definir el nivel de aislamiento para operaciones transaccionales individuales como bueno como en todo el mundo. A nivel READ COMMITTED, el resultado de cualquier trabajo realizado después de que una transacción ha comenzado, pero antes de que ha terminado, seguirá siendo invisible para los demás usuarios de la base de datos hasta que ha terminado. En el nivel más bajo (READ UNCOMMITTED), que en ocasiones puede utilizarse para asegurar alta concurrencia, dichos cambios serán visibles.

Transacciones distribuidas

Implementación de sistemas de base de datos transacciones distribuidas como las transacciones contra múltiples aplicaciones o hosts. Una transacción distribuida aplica las propiedades ácidas sobre múltiples sistemas o almacenes de datos y puede incluir sistemas como bases de datos, sistemas de archivos, sistemas de mensajería y otras aplicaciones. En una transacción distribuida un coordinación servicio asegura que todas las partes de la transacción se aplican a todos los sistemas relevantes. Como con la base de datos y otras transacciones, si falla alguna parte de la transacción, la transacción entera se deshace en todos los sistemas afectados.

Sistemas de ficheros transaccionales

El Namesys Reiser4 sistema de ficheros para Linux es compatible con las transacciones y como de Microsoft Windows Vista, Microsoft NTFS sistema de archivos soporta transacciones distribuidas a través de redes.

Véase también

• Control de concurrencia

Lectura adicional

• Philip A. Bernstein, Eric Newcomer (2009): Principios de procesamiento de transacciones, 2ª edición, Morgan Kaufmann (Elsevier), ISBN 978-1-55860-623-4
• Gerhard Weikum, Gottfried Vossen (2001), Sistemas de información transaccional: teoría, algoritmos y la práctica del control de concurrencia y recuperación, Morgan Kaufmann, ISBN 1-55860-508-8

Enlaces externos

• C2:TransactionProcessing

Otras Páginas

• Motorola A910
• Master (judicial)
• Sitio Finder
• Relleno (alimentos para animales)
• Afectan la logica
• Revision clinica
• Equipo llamando