Para realizar una transacción en un sistema de base de datos y asegurarse de que funciona sin problemas, existen pocas reglas que una transacción de base de datos debe seguir. Estas reglas son los estándares en todos los sistemas de bases de datos relacionales (RDBMS) y se llaman reglas de ACID .
ACID significa Atomicidad, Consistencia, Aislamiento y Durabilidad . Así que vamos a ver qué dicen todas estas Reglas.
Consulte aquí los detalles de las propiedades ACID de Transacciones en un RDBMS .
-> A: La atomicidad establece que cada transacción debe ser de naturaleza atómica. Una transacción en una base de datos relacional puede contener una única declaración de SQL o múltiples sentencias de SQL. Así, por Atomic Transaction significa “todo o nada”. O bien todas las sentencias / pasos SQL se ejecutan con éxito en una transacción, o fallan como una sola unidad y ninguno de ellos debe tratarse como ejecutado y el sistema debe retornar a su estado original.
Por ejemplo : si la cuenta A y la cuenta B tienen un saldo de $ 2000, debe transferir $ 1000 de la cuenta A a la cuenta B, esto implicará 2 pasos. Primer retiro de la cuenta A y segundo depósito en la cuenta B. Por lo tanto, ambos pasos deben tratarse como unidad individual o atómica y en la cuenta final: A debe tener $ 1000 y la cuenta B debe tener un saldo de $ 3000. Si en el caso después del Primer paso, el sistema falla o se produce un error, el primer paso también debe retrotraerse y se deben retirar $ 1000 de la cuenta: A debe volver a depositarse en él, manteniendo $ 2000 en ambas cuentas. Por lo tanto, no debería haber un estado intermedio en el que la cuenta A tenga $ 1000 y la cuenta B aún tenga un saldo de $ 2000.
-> C: la coherencia establece que cualquier Transacción ocurrida en una base de datos lo llevará de un estado consistente a otro estado consistente . Los datos finalmente registrados en la base de datos deben ser válidos de acuerdo con las Reglas, Restricciones, Cascadas, Desencadenantes, etc. definidos. Si en caso de cualquier falla en estas reglas los cambios realizados por cualquier transacción se deben retrotraer, esto pondrá al sistema en un estado consistente anterior.
Por ejemplo: si el proceso de depósito de dinero tiene un disparador creado encima. Y en el momento de la transferencia de dinero, cualquiera de los desencadenadores falla o cualquier nodo de base de datos, el sistema debe revertir automáticamente la transacción completa y volver al sistema a su estado anterior consistente antes de que se inicie la transacción. O si todo se ejecuta con éxito, entonces el sistema se compromete a un nuevo estado consistente.
-> I: aislamiento significa que las transacciones que realizan las mismas funciones deben ejecutarse en aislamiento y no en paralelo para proporcionar más concurrencia a los datos y evitar lecturas y escrituras sucias. Es necesario utilizar niveles adecuados de Aislamiento de transacciones y bloqueo para evitar esto.
Por ejemplo: si dos personas acceden a una cuenta conjunta con un saldo de $ 5000 de 2 terminales para retirar dinero. Digamos al mismo tiempo que John & Marry solicitan retirar $ 4000 de dos cajeros automáticos diferentes. Si ambas transacciones no se ejecutan en aislamiento y se ejecutan en paralelo, tanto John como Marry podrán retirar $ 4000 cada uno, es decir, $ 8000 en total de su cuenta. Para asegurarse de que esto no ocurra, no se debe permitir que las transacciones se ejecuten en paralelo, configurando Aislamiento de transacciones y / o métodos de bloqueo en los objetos de la base de datos.
-> D: Durabilidad , una transacción debe ser duradera almacenando los datos de forma permanente y poniéndolos a disposición en caso de falla de energía, recuperación de fallas del sistema, bloqueo, cualquier error, etc. En general, los datos no deben perderse en ningún de los happenings y uno debería ser capaz de recuperar datos de restauración, registro y otros métodos.
~ SQL con Manoj
