Consistencia. Consistencia en sistemas de base de datos se refiere a la exigencia que cualesquiera transacciones de bases de datos Sólo debe cambiar datos afectados de formas permitidas. Los datos escritos en la base de datos deben ser válidos según todas las reglas definidas, incluyendo limitaciones, Cascades, factores desencadenantes y cualquier combinación de éstos. Podría definirse como la coherencia entre todos los datos de la base de datos. La ejecución de una transacción debe conducir a un estado de la base de datos consistente. Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos. La propiedad de consistencia en las bases de datos se basa en la premisa que afirma que una transacción debe llevar al sistema de un estado válido a otro que también lo sea. Cabe resaltar que la validez de las operaciones está determinada por su seguimiento o no de las reglas establecidas para garantizar la fiabilidad de la base de datos. Consistencia de datos Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias Niveles de Aislamiento. No todos los tipos de bases de datos soportan cada nivel de aislamiento. Algunos proveedores de base de datos utilizan diferentes nombres para los niveles de aislamiento. Las consultas se ejecutan con una unidad de trabajo en el origen de datos como una transacción con un nivel de aislamiento predeterminado o definido por el administrador. Los autores de informes no deben suponer que las consultas que ejecutan procedimientos almacenados confirman todos los datos escritos por el procedimiento. En algunos entornos, los cambios realizados por un procedimiento pueden quedar confirmados por las características de la base de datos. Si necesita ejecutar consultas específicas con distintos niveles de aislamiento, debe definir distintas conexiones de base de datos. Para los orígenes de datos OLAP, incluido SAP BW, la unidad de trabajo de transacciones es de sólo lectura. Suponga que una transacción en un programa actualiza los datos de una geodatabase de ArcSDE pero, antes de que se confirme la transacción, otro programa lee los mismos datos. La respuesta depende del nivel de aislamiento de la transacción. Si la transacción permite a otros programas leer los datos no confirmados, el segundo programa leerá los datos actualizados. Esto puede mejorar el rendimiento, porque el segundo programa no tiene que esperar a que finalice la transacción para leer los datos. También pueden establecerse dentro de una aplicación o antes de una transacción individual. Todas las lecturas de la transacción verán solo datos confirmados antes de que se inicie la transacción, y nunca verán cambios de la transacción simultánea confirmados durante la ejecución de la transacción. Su DBMS puede hacer referencia a estos niveles por otros nombres. Cada nivel funciona de manera similar en todos los DBMS, pero hay diferencias importantes. Para evitar errores en el diseño de aplicaciones y flujos de trabajo, asegúrese de entender cómo afectan los niveles de aislamiento al bloqueo y la simultaneidad en su DBMS. Recíprocamente, si se usan altos niveles de aislamiento la posibilidad de bloqueo aumenta, lo que también requiere análisis cuidadoso del código. Los niveles de aislamiento están definidos por ANSI/ISO SQL, y se listan a continuación.
Es el grado en que se aísla una transacción de las modificaciones de recursos o
datos realizadas por otras transacciones. Antes de entrar a los NIVELES DE AISLAMIENTO debemos comprender lo que son los EFECTOS DE LECTURA, estos son casos en donde la transacción A lee datos que pudieron haber sido modificados por la transacción B, existen 3 tipos diferentes. Las transacciones especifican un nivel de aislamiento que define la forma en que una transacción se aísla de las demás transacciones. Una transacción es la unidad lógica de trabajo en un motor relacional. En escenarios de este tipo, todas las acciones han de completarse o la transacción no llega a completarse. En el ámbito relacional, pasa algo parecido y se identifican una serie de requisitos que se han de cumplir para completar la transacción. Si algo lo impide, SQL Server abortará el comando y revertirá la transacción. Cada transacción, ya sea exitosa o no, deja la base de datos en un estado coherente en base a las restricciones definidas en el entorno, ya sean contraints de foreign keys, unicidad de constraints unique o cualquier restricción definida en la lógica transaccional de la base de datos. Cada transacción parece que ocurre aisladamente de otras transacciones con respecto a los cambios en la base de datos. El grado de aislamiento puede variar según el nivel aislamiento que se define en la transacción, y es en este aspecto donde centramos el alcance de este artículo. Cada transacción perdura a través de una interrupción del servicio. Las anomalías de base de datos son resultados generados que parecen incorrectos cuando se observan desde el ámbito de una sola transacción, pero que son correctos cuando se observan desde el ámbito de todas las transacciones. La transacción A lee todas las filas que satisfacen una cláusula WHERE de una consulta SQL. La transacción B inserta una fila adicional que satisface la cláusula WHERE. La transacción A vuelve a evaluar la condición WHERE y recoge la fila adicional. El aislamiento es una parte importante de la propiedad ACID que garantiza que las transacciones sean fiables. Esto permite que las transacciones que se ejecutan simultáneamente no interfieran con otras, garantizando la integridad de los datos, al no existir aislamiento en una transacción podría modificar los datos que otra transacción está leyendo, por lo que se crea una inconsistencia cuando se crean datos. Ahora que entendemos que es el aislamiento en términos generales, vamos a conocer cuáles son los niveles de aislamiento, estos determinan como las transacciones se comportan con otras transacciones, es como ser más o menos restrictivo. Referencias consultadas en formato APA. (Consistencia) Coherencia (sistemas de bases de datos). (s. f.). hmn.wiki. https://hmn.wiki/es/Consistency_(database_systems)
4.3 Grados de consistencia - 2016_08_TBD_8. (s. f.).