Unidad 7 Flashcards
Seguridad de Datos
Hablamos de Seguridad de Datos en una base de datos relacional al referirnos al respeto establecido por el Gestor de Bases de Datos en cuanto a las características del modelo relacional:
● Integridad de Dominio
● Integridad Referencial
Modelo de Transacciones
Desde el punto de vista de la base de datos una transacción es un conjunto de operaciones elementales que deben ser procesadas como una unidad de trabajo.
Las transacciones se deben procesar de manera confiable de modo que no haya pérdida de datos debido a
fallas en el sistema o a que varios usuarios estén accediendo en forma concurrente.
Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción
Propiedades (ACAD)
● Atomicidad (Atomicity)
● Consistencia (Consistency)
● Aislamiento (Isolated)
● Durabilidad (Durability)
Atomicidad (Atomicity)
Significa que una transacción no se puede subdividir. Su realización es completa. Se debe considerar una única operación lógica, aunque esté formada por varias operaciones más simples que deben ejecutarse en forma completa o no ejecutarse.
Consistencia (Consistency)
Conservación de coherencia. Esto significa que si antes de la
ejecución de una transacción la base de datos está en estado consistente, una vez ejecutada la
transacción ésta debe volver al mismo estado de consistencia
Aislamiento (Isolated)
Concurrencia no problemática. Debe asegurarse incluso aunque varias transacciones se efectúen concurrentemente.
Durabilidad (Durability)
Permanencia de los cambios. Significa que tras la ejecución de una
transacción, los nuevos valores de la base de datos deben mantenerse a pesar de cualquier tipo de
fallo del sistema.
Estados de las Transacciones. Estados de la base de datos
● Activa (estado inicial): la transacción permanece en este estado durante su ejecución. Durante la misma el estado de la base de datos es inconsistente.
● Parcialmente Comprometida: la transacción pasa a este estado cuando acaba de realizar la última instrucción (antes del COMMIT)
● Fallida: la transacción pasa a este estado tras descubrir que no puede continuar la ejecución normal
● Abortada: la transacción pasa a este estado después de haber restablecido la base de datos a su estado anterior (ROLLBACK)
● Comprometida: la transacción pasa a este estado tras completarse con éxito. Se dice también que está confirmada (COMMIT)
En la medida en que se están ejecutando transacciones la base de datos está en estado inconsistente.
Una transacción comprometida que haya hecho modificaciones transforma a la base de datos llevándola a un nuevo estado de consistencia que permanece incluso de que luego haya fallos en el sistema.
Para asegurar el estado de consistencia de una base de datos toda transacción abortada no debe tener efecto sobre el estado de la base de datos. Cualquier cambio que haya realizado la transacción abortada
debe deshacerse.
Ejecución de las Transacciones
El archivo de bitácora o log de transacciones es el que lleva la información de cómo se están ejecutando las transacciones en la base de datos.
Lleva registro de cada una de las operaciones de la transacción que se están ejecutando y a qué objetos de la base de datos afectan.
La estructura del log de transacciones es dependiente del Gestor de Base de Datos pero sus entradas tienen al menos:
● Marca de Inicio de Transacción
● Marcas de escritura, modificaciones o eliminaciones realizadas por la Transacción con valores
anteriores y valores posteriores para un objeto
● Marca de Fin de Transacción
Recuperación de base de Datos
El SGBD puede recuperar la base de datos luego de un fallo de una o varias transacciones deshaciendo o rehaciendo las operaciones individualmente, transacción por transacción, a partir del log de transacciones.
Si el sistema falla, el SGBD podrá recuperar el estado consistente de la base de datos examinando el log de transacciones y utilizando diversas técnicas de recuperación.
Puesto que el log de transacciones contiene un registro de cada operación que cambia el valor de algún objeto de la base de datos, se podrá deshacer el efecto de las operaciones de una transacción retrocediendo por el log de transacciones y restaurando todos los objetos cambiados por dichas operaciones a sus valores anteriores.
Concurrencia
La ejecución de varias transacciones en forma concurrente permite:
● Mejorar la productividad
● Mejorar la utilización de recursos
● En un ambiente de alto caudal de transacciones, reducir el tiempo de espera para los usuarios
Pero puede destruir la consistencia de la base de datos.
Problemas de la Concurrencia
● Actualización perdida: Es cuando la actualización de un usuario sobrescribe la de otro
● Lectura Sucia: Es cuando se leen datos que otra transacción ha modificado sin que la misma se haya confirmado (se haya ejecutado el COMMIT)
● Lectura fantasma: Es cuando, por ejemplo, una transacción lee datos con ciertas condiciones de registro, otra transacción inserta datos que la consulta no recuperó. Por último la consulta original se
vuelve a ejecutar y se encuentra con registros que inicialmente no existían.
● Lectura no repetible: Es cuando una transacción lee el mismo valor más de una vez. Entre una lectura y la siguiente, otra transacción los modifica
Bloqueos
Utilizar la propuesta de Bloqueos implica que el SGBD evita que un usuario acceda a un objeto de la base de datos que se está utilizando. Entonces, solo la transacción para la cual fue bloqueado el objeto tendrá
acceso y otras transacciones deberán esperar hasta que el objeto sea desbloqueado.
Los bloqueos pueden ser:
● Compartidos: Es necesario obtener un bloqueo compartido antes de ejecutar una consulta
● Exclusivos: Es necesario obtener un bloqueo exclusivo antes de ejecutar una operación de
escritura.
Protocolo de Compromiso en 2 Fases
Para asegurarse de que no se presenten problemas de actualizaciones perdidas el Componente de Control
de Concurrencias del SGBD utiliza el protocolo de compromiso en 2 fases:
1. Antes de leer o escribir en un objeto de datos, la transacción debe adquirir un bloqueo para el elemento
2. Espera si hay un bloqueo problemático para el objeto de datos
3. Después de realizar el bloqueo, la transacción no adquiere ningún nuevo bloqueo.
Al inicio de la transacción no existe ningún objeto bloqueado e
inicia la etapa de bloqueos donde la transacción adquiere los bloqueos de todos los objetos de datos
requeridos para la misma. Se realiza la transacción y al finalizar se liberan todos los bloqueos
simultáneamente.
Esto puede generar que otras transacciones permanezcan en espera durante un tiempo considerable hasta
que la transacción que realizó los bloqueos los libere.
Niveles de Aislamiento
El diseñador de las transacciones deberá planificar las transacciones según las mismas requieran protegerse de los problemas de la concurrencia y equilibrar el trabajo especificando el nivel de aislamiento. Una planificación representa el orden cronológico en que se ejecutarán las instrucciones de las transacciones en
el sistema.
Comportamiento Serializable o Secuenciable: Si todos los bloqueos se conservan hasta el final de la
transacción se evitan los problemas de control de concurrencia descritos anteriormente
Lectura repetible: Este nivel de aislamiento impide que dos lecturas consecutivas den diferentes resultados.
Utiliza bloqueos exclusivos que se liberan al finalizar la transacción pero no evita la lectura fantasma
Lectura comprometida: Se utilizan bloqueos compartidos que impiden solo la lectura de actualizaciones
incorrectas.
Lectura no comprometida: No utiliza bloqueos. Debe ser utilizado para el acceso a datos de sólo lectura.
Fallos. Clasificación
● Problemas de caídas del Sistema
● Problemas lógicos en las transacciones
● Problemas de terminación anormal
Problemas de caídas del Sistema
Debido a que ante una caída en el sistema la base de datos no puede depender de los datos almacenados en memoria RAM y son utilizados los mecanismos de log de transacciones.
Además métodos de administración de la continuidad para prevenirlos. Entre estos métodos podemos mencionar: respaldos en momentos en que la base de datos no está operativa o mientras está en
línea (generación de backups mientras la base de datos está operativa), utilización de RAID de discos, UPS, etc. La utilización de estos mecanismos dependerá de la confiabilidad de los datos que se quiera establecer
Los problemas lógicos de las transacciones
son detectados durante la ejecución de las mismas y dan lugar a
abortar la transacción con un mensaje específico para el usuario.
● Problemas de integridad de dominio: tipos de datos incorrectos, valores nulos cuando el atributo no los acepta, validaciones específicas de rangos valores, etc.
● Problemas de integridad referencial: intentar hacer referencia a una clave foránea inexistente
● Problemas de fallas de programación: división por cero
Estos problemas dan lugar a un ROLLBACK
