ACID Compliant

En ciencias de la computación , ACID (atomicidad, coherencia, aislamiento, durabilidad) es un

conjunto de propiedades que garantizan las operaciones de base de datos se procesan de forma
fiable. En el contexto de bases de datos , una operación lógica simple de los datos se llama una
transacción. Por ejemplo, una transferencia de fondos de la cuenta bancaria a otra, a pesar de que
pueden implicar cambios múltiples (por ejemplo, una cuenta de débito y crédito a otro), es una sola
transacción.

Jim Gray define estas propiedades de un sistema de transacciones confiables en la década de 1970 y
las tecnologías desarrolladas de forma automática a alcanzar. [1] En 1983, Andreas Reuter y
Haerder Theo acuñó el acrónimo ACID para describirlos. [2]

Contenido
1 Características
1.1 Atomicidad
1.2 Coherencia
1.3 Aislamiento
1.4 Durabilidad
2 Ejemplos
2.1 Atomicidad fracaso
2.2 Coherencia fracaso
2.3 Aislamiento de falla
2.4 Durabilidad fracaso
3 Aplicación
3.1 vs Bloqueo multiversioning
3.2 Las transacciones distribuidas
4 Véase también
5 Notas
6 Referencias

Características

Atomicidad
Atomicidad requiere que las modificaciones de base de datos debe seguir un todo o nada "regla".
Cada transacción se dice que es atómica. Si una parte de la transacción falla, toda la transacción
falla y el estado de base de datos no se modifica. Es fundamental que el sistema de gestión de base
de datos mantiene la naturaleza atómica de las transacciones, a pesar de cualquier aplicación, DBMS
( Database Management System ), sistema operativo o un error de hardware.

Una transacción atómica no puede ser subdividida y deben ser tratados en su totalidad o en
absoluto. Atomicidad significa que los usuarios no tienen que preocuparse por el efecto de las
transacciones incompletas.

Las transacciones pueden fallar por varios tipos de razones:

Error de hardware: Un disco duro falla, la prevención de algunos de los cambios de base de datos de
la transacción de que entre en vigor.
Error del sistema: El usuario pierde su conexión con la aplicación antes de proporcionar toda la
información necesaria.
Error de base de datos: Por ejemplo, la base de datos se queda sin espacio para almacenar datos
adicionales.
Error de la aplicación: La aplicación intenta enviar datos que viola una regla que impone la propia
base de datos, como el intento de insertar un valor duplicado en una columna.

Consistencia
La coherencia de propiedad garantiza que cualquier transacción de la base de datos realiza lo llevan
de un estado consistente a otro.

La propiedad de la coherencia no dice cómo el DBMS debe manejar una incoherencia que no sea
asegurar la base de datos está limpia al final de la transacción. Si, por alguna razón, una transacción
se ejecuta que viola las reglas de la base de datos de coherencia, toda la transacción podría ser
revertido al estado anterior a la transacción - o sería igualmente válido para el DBMS a adoptar
alguna medida de parche hasta obtener el base de datos en un estado coherente. Así, si el esquema
de base de datos , dice que un campo en particular es para la celebración de números enteros, el
DBMS puede decidir rechazar los intentos de poner los valores fraccionarios allí, o podría ronda los
valores suministrados a la unidad más próxima: las dos opciones mantener la coherencia.

La regla de coherencia se aplica sólo a las normas de integridad que se encuentran dentro de su
ámbito de aplicación. Así, si un DBMS permite campos de un registro para actuar como referencia a
otro registro, entonces la consistencia implica el DBMS debe hacer cumplir la integridad referencial :
por el momento cualquier transacción termina, todos y cada uno de referencia en la base de datos
debe ser válido. Si una transacción consistió en un intento de eliminar un registro al que hace
referencia a otro, cada uno de los siguientes mecanismos que mantener la coherencia:
anular la transacción, hacer retroceder al estado coherente, antes;
eliminar todos los registros que hacen referencia al registro eliminado (esto se conoce como
eliminación en cascada), o bien,
anular los campos pertinentes de todos los registros que el punto en el registro ha sido eliminado.

Estos son ejemplos de las limitaciones de propagación , y algunos sistemas de bases de datos
permiten que el diseñador de base de datos para especificar qué opción de elegir la hora de
establecer el esquema de una base de datos.

Los desarrolladores de aplicaciones son responsables de garantizar la coherencia a nivel de

aplicación, más allá de la ofrecida por el DBMS. Por lo tanto, si un usuario se retira fondos de una
cuenta y el nuevo saldo es menor que el umbral de la cuenta un saldo mínimo, por lo que el DBMS
se refiere, la base de datos está en un estado coherente a pesar de que esta regla (desconocido para
el DBMS) ha sido violados.

Aislamiento
El aislamiento se refiere a la exigencia de que otras operaciones no pueden acceder a los datos que
ha sido modificado durante una transacción que aún no ha terminado. La cuestión de aislamiento se
produce en el caso de las operaciones simultáneas (varias transacciones que ocurren al mismo
tiempo). Cada transacción debe seguir siendo conscientes de otras transacciones al mismo tiempo de
ejecución, excepto que puede ser una transacción que esperar para la realización de otra operación
que ha modificado los datos que requiere la operación de espera. Si el sistema de aislamiento no
existe, entonces los datos podrían ponerse en un estado incoherente. Esto podría ocurrir, si una
transacción está en el proceso de modificación de datos, pero no ha terminado todavía, y luego una
segunda transacción lee y modifica los datos que no comprometidos de la primera operación. Si la
operación falla el primer y el segundo éxito, que la violación de aislamiento transaccional hará que la
inconsistencia de datos. Debido a la realización y interbloqueos preocupaciones con múltiples
operaciones en competencia, muchas bases de datos modernos permiten lecturas sucias , que es
una manera de evitar algunas de las restricciones del sistema de aislamiento. Una lectura no
significa que una transacción puede leer, pero no modificar, los datos no comprometidos de otra
transacción.

Durabilidad
La durabilidad es la capacidad del DBMS para recuperar las actualizaciones de transacción cometidos
contra cualquier tipo de fallo del sistema (hardware o software). Durabilidad es DBMS de la garantía
de que una vez que el usuario ha sido notificado de la transacción es un éxito la operación no se
perderán, la transacción cambios en los datos sobrevivirá fallo del sistema, y que todas las
restricciones de integridad se han cumplido, por lo que el DBMS no será necesario efectuar la
operación inversa. Muchos DBMS aplicar la durabilidad de las transacciones por escrito en un registro
de transacciones que puede ser reprocesado para recrear el derecho del estado del sistema antes de
que el fracaso más tarde. Una transacción se considera cometido sólo después de su inscripción en el
registro.

Durabilidad no implica un estado permanente de la base de datos. Una de las operaciones que
pueden modificar los datos modificados por una transacción antes sin violar el principio de
durabilidad.

Ejemplos
Los siguientes ejemplos sirven para explicar con más detalle las propiedades ACID. En estos
ejemplos, la base de datos tiene dos campos, A y B, en dos registros. Una restricción de integridad
requiere que el valor en A y el valor de B deben sumar 100.

Error de Atomicidad
La operación de resta 10 A y añade 10 a B. Si tiene éxito, sería válida, porque los datos continúa
para satisfacer la restricción. Sin embargo, suponer que después de retirar 10 de la A, la transacción
no puede modificar B. Si la base de datos mantiene el nuevo valor de A, la atomicidad y la restricción
de que ambas sean violados. Atomicidad requiere que ambas partes de esta transacción completa o
no.

Error de coherencia
La consistencia es un término muy general que exige los datos cumple con todas las reglas de
validación que la aplicación general de espera - sino para satisfacer la propiedad de la coherencia de
un sistema de base de datos sólo tiene que hacer cumplir esas normas que están dentro de su
ámbito de aplicación. En el ejemplo anterior, una regla es un requisito que A + B = 100, la mayoría
de los sistemas de base de datos no permitan este tipo de regla que se especifica, y así no tendría la
responsabilidad de hacerla cumplir - pero sería capaz de garantizar los valores fueron números
enteros. Ejemplo de reglas que pueden ser impuestos por el sistema de base de datos que la clave
principal de valores de un registro único identificar ese registro, que los valores almacenados en los
campos son del tipo correcto (el esquema puede requerir que tanto A como B son números enteros,
por ejemplo) y en el rango de derecho, y que las claves foráneas son válidos.

Las reglas de validación que no puede ser ejercida por el sistema de base de datos es
responsabilidad de los programas de aplicación utilizando la base de datos.

Error de aislamiento
Para demostrar el aislamiento, se supone ejecutar dos operaciones al mismo tiempo, cada uno
intentando modificar los mismos datos. Uno de los dos tiene que esperar hasta que el otro lleva a
cabo con el fin de mantener el aislamiento.

Consideremos dos transacciones. T 1 transferencias 10 de la A a T B. 2 transferencias de 10 de B a

A. En conjunto, hay cuatro acciones:
restar 10 de la A
añadir de 10 a B.
restar 10 de B
añadir de 10 a A.

Si estas operaciones se realizan con el fin, el aislamiento se mantiene, aunque T 2 debe esperar.
Considere lo que sucede, si T 1 no a mitad de camino. La base de datos elimina T 1 'efectos s, y T 2
sólo ve datos válidos.

Mediante la interpolación de las operaciones, el orden real de las acciones podría ser: A - 10 B - 10,
B + 10 A + 10. Una vez más en cuenta lo que sucede, si T 1, no. T 1, aún resta 10 de A. Ahora, T 2
añade 10 a un restaurarlo a su valor inicial. Ahora T 1 no. ¿Cuál debería ser el valor de A? T 2 ya lo
ha cambiado. Además, una nunca cambió T T B. 2 resta 10 de la misma. Si T 2 se puedan
cumplimentar, de valor de B será mínimo de 10 también, y de un valor no cambiará, dejando una
base de datos no válidos. Esto se conoce como escritura error de escritura, ya que dos intentos de
operaciones para escribir en el campo de los mismos datos.

Error de durabilidad
Suponga que una transacción de transferencia de 10 desde la A a la B. Se elimina 10 de A. A
continuación, agrega de 10 a B. En este punto, un "éxito" mensaje se envía al usuario. Sin embargo,
los cambios se siguen en cola en el búfer de disco en espera de ser cometidos en el disco. Un corte
de corriente y los cambios se pierden. El usuario asume que los cambios se han hecho, pero se
pierden.

Para satisfacer la restricción de la durabilidad, el sistema de base de datos debe garantizar el

mensaje de éxito se retrasa hasta que la transacción haya finalizado. Puede ser suficiente para
asegurar que un registro de transacciones ha sido totalmente escrito en el disco, en el caso de un
accidente y reiniciar, la pérdida de las transacciones se vuelva a ejecutar, con lo que la base de
datos actualizada al día.
Aplicación

Procesamiento de una transacción a menudo se requiere una secuencia de operaciones que está
sujeta al fracaso por varias razones. Por ejemplo, el sistema puede no queda espacio en las unidades
de su disco, o puede haber utilizado su tiempo asignado de la CPU.

Hay dos familias de técnicas populares: escribir por delante de registro y paginación de la sombra .
En ambos casos, los bloqueos deben ser adquiridos en toda la información que se actualiza, y en
función del nivel de aislamiento, posiblemente en todos los datos que se lee así. En escribir por
delante de registro, la atomicidad es garantizada por la copia del original (sin cambios) de datos en
un registro antes de cambiar la base de datos. Eso permite que la base de datos para volver a un
estado coherente en el caso de un accidente.

En la sombra, las actualizaciones se aplican a una copia parcial de la base de datos, y la copia nueva
se activa cuando se confirma la transacción.

vs Bloqueo multiversioning

La mayoría de las bases de datos dependen de bloqueo para proporcionar capacidades de ACID.
Bloqueo significa que la transacción marcas los datos que tiene acceso para que el DBMS no sabe
para que otras transacciones de modificarlo hasta que la primera transacción tiene éxito o fracasa.
La cerradura siempre debe ser adquirido antes de proceso de datos, incluidos los datos que se leen
pero no modificarse. Las operaciones no triviales suelen requerir un gran número de bloqueos, lo que
resulta en gastos considerables, así como el bloqueo de otras transacciones. Por ejemplo, si el
usuario A ejecuta una transacción que tiene que leer una fila de datos que el usuario B quiere
modificar, el usuario B debe esperar hasta que el usuario A la transacción se complete. Dos bloqueo
de fase se aplica con frecuencia para garantizar el aislamiento completo. [ cita requerida ]

Una alternativa al bloqueo es control de concurrencia multiversión , en los que la base de datos
proporciona a cada transacción de la lectura, sin modificar la versión previa de datos que está siendo
modificada por otra transacción activa. Esto permite a los lectores para operar sin necesidad de
adquirir las cerraduras. Es decir, las transacciones de escritura no bloquean las operaciones de
lectura y los lectores no bloquean escritores. Volviendo al ejemplo, cuando el usuario A las
solicitudes de transacción de datos que el usuario B está modificando la base de datos proporciona
una con la versión de que los datos que existían cuando el usuario B comenzó su operación. El
usuario A obtiene una visión consistente de la base de datos incluso si otros usuarios están
cambiando los datos. Una puesta en práctica relaja la propiedad de aislamiento, es decir, el
aislamiento de instantánea .

Las transacciones distribuidas

La garantía de las propiedades ACID en una transacción distribuida a través de una base de datos
distribuida que no solo nodo es responsable de todos los datos que afectan a una transacción
presenta complicaciones adicionales. Las conexiones de red puede fallar, o un nodo con éxito podría
completar su parte de la transacción y, a continuación se requiere para revertir sus cambios, debido
a un error en otro nodo. Las dos fases del protocolo (que no debe confundirse con la fase de bloqueo
de dos), establece la atomicidad de las transacciones distribuidas para asegurar que cada
participante en la transacción de acuerdo sobre si la transacción debe ser comprometida o no. [ cita
requerida ] En pocas palabras, en los primeros fase, un nodo (el coordinador) interroga a los otros
nodos (los participantes) y sólo cuando todos responden que están preparados hace el coordinador,
en la segunda fase, la formalización de la transacción.