Tarea 8

miércoles, 28 de enero de 2009

Querys de Consultas y Reportes de la Aplicacion

Consulta para Validar Usuario
'SELECT CONTRASENA, USUARIO FROM usuarios WHERE USUARIO=\''.$USUARIO.'\''

Consulta para Insertar un Nuevo Ciudadano
"INSERT INTO ciudadanos (FOLIO,RFC,CURP,TELEFONO,EXTENSION,APELLIDOPATERNO,APELLIDOMATERNO,NOMBRE,CALLE,NUMERO,ENTRE,COLONIA,CP,ESTADO,CIUDAD,CORREO,ID) VALUES ('$FOLIO','$RFC','$CURP','$TELEFONO','$EXTENSION','$APELLIDOPATERNO','$APELLIDOMATERNO','$NOMBRE','$CALLE','$NUMERO','$ENTRE','$COLONIA','$CP','$ESTADO','$CIUDAD','$CORREO','$ID');"

Consulta para Insertar un Nuevo Reporte
"INSERT INTO reportes (FOLIO,ID,NOMBRE,TURNADO,ASUNTO,FECHA) VALUES ('$FOLIO','$ID','$NOMBRE','$TURNADO','$ASUNTO','$FECHA');"

Consulta para Actualizar la Contraseña de Usuario
"UPDATE usuarios SET USUARIO='{$_POST['USUARIO']}', CONTRASENA='{$_POST['CONTRASENA2']}' WHERE USUARIO = '$_POST[USUARIO]'"

Reporte de Ciudadano que su CURP ya este Registrado
"SELECT * FROM ciudadanos WHERE CURP = $_POST[CURP]"

Consulta para Autoincrementar el Folio de los Reportes
"SELECT MAX(FOLIO) as maximo FROM $tabla"

Reporte de Ciudadano que su Folio de Elector este Registrado
"SELECT * FROM ciudadanos WHERE FOLIO = $_POST[FOLIO]"

Reporte de Reportes por Folio de Reporte
"SELECT * FROM reportes WHERE FOLIO = $_POST[FOLIO]"

Consulta para Insertar un Nuevo Usuario
"INSERT INTO usuarios (USUARIO,CONTRASENA,NOMBRE,AREA) VALUES ('$USUARIO','$CONTRASENA','$NOMBRE','$AREA');"

Reporte de Ciudadano que su RFC este Registrado
"SELECT * FROM ciudadanos WHERE RFC = $_POST[RFC]"

Reporte de Ciudadano que su Telefono este Registrado
"SELECT * FROM ciudadanos WHERE TELEFONO = $_POST[TELEFONO]"

Tarea 5

Creación de Tabla USUARIOS y 50 Registros en MySQL 5.0

CREATE TABLE IF NOT EXISTS `usuarios` (
`USUARIO` varchar(10) NOT NULL,
`CONTRASENA` varchar(10) NOT NULL,
`NOMBRE` varchar(50) NOT NULL,
`AREA` varchar(40) NOT NULL,
PRIMARY KEY (`USUARIO`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

--
-- Volcar la base de datos para la tabla `usuarios`
--

INSERT INTO `usuarios` (`USUARIO`, `CONTRASENA`, `NOMBRE`, `AREA`) VALUES
('PACO', 'ADMIN', 'PAILLES RUBIÑOS FRANCISCO NICOLAS', 'PARQUES Y JARDINES'),
('TRIX', 'DANIEL', 'HUERTA GOMEZ DANIEL', 'LIMPIA PUBLICA'),
('FERNANDO', 'LAGUNA', 'FERNANDO FRAGOSO', 'PARQUES Y JARDINES'),
('ALDO', 'TLACO', 'ALDO PEREZ', 'PARQUES Y JARDINES'),
('DANIEL', 'COYOL', 'DANIEL HUERTA GOMEZ', 'PARQUES Y JARDINES'),
('RICARDO', 'JARDIN', 'RICARDO MONTALVO', 'PARQUES Y JARDINES'),
('BETZHY', 'SOLIS', 'BETHY SOLIS', 'LIMPIA PUBLICA'),
('RAUL ', 'GOMEZ', 'RAUL GOMEZ ', 'FINANZAS'),
('ALEJANDRO', 'GONZALEZ', 'ALEJANDRO GONZALEZ', 'FINANZAS'),
('GRISEL', 'MAMA', 'GRISEL CHAVES', 'LIMPIA PUBLICA'),
('MARTHA', 'MILLO', 'MARTHA RODRIGUEZ', 'FINANZAS'),
('CRISTIANO', 'RONALDO', 'CRISTIANO RONNY', 'LIMPIA PUBLICA'),
('OMAR', 'RORO', 'OMAR RODRIGUEZ', 'LIMPIA PUBLICA'),
('RAFA', 'RAMOS', 'RAFA RAMOS', 'CULTURA'),
('FELIX', 'MACEDA', 'FELIX MACEDA', 'TRANSITO DEL EDO'),
('MARCARIAN', 'AMERICA', 'MARCARIAN CONTRERAS', 'TRANSITO DEL EDO'),
('ROSA', 'RUSA', 'ROSA MANSURES', 'FINANZAS'),
('LILI', 'ALI', 'LILI SUAREZ', 'PARQUES Y JARDINES'),
('PACHI', 'CHURRO', 'PACHI LOPEZ', 'TRANSITO DEL EDO'),
('ESTHER', 'SOSA', 'ESTHER SOSA', 'FINANZAS'),
('CARMEN ', 'VALLE', 'CARMEN DEL VALLE', 'RECURSOS HUMANOS'),
('EDER ', 'ARRIOLA', 'EDER ARRIOLA', 'RECURSOS HUMANOS'),
('GUIDMYE', 'EMID', 'GUIDMYE EMID', 'RECURSOS HUMANOS'),
('PATO ', 'MEME', 'PATO ALFARO', 'RECURSOS HUMANOS'),
('SUSANA', 'SUSI', 'SUSANA LOPEZ', 'FINANZAS'),
('ALBERTO', 'BETO', 'ALBERTO VAZQUEZ', 'TRANSITO DEL EDO'),
('ANA', 'ANYTA', 'ANA DELIA', 'PARQUES Y JARDINES'),
('ANITA', 'CONTROL', 'ANITA PEREZ', 'PARQUES Y JARDINES'),
('JUCHI', 'JUCHITAN', 'JUCHI ELMO', 'RECURSOS HUMANOS'),
('ZAZYL', 'ZAZY', 'ZAZYL HA', 'PARQUES Y JARDINES'),
('PEPA', ' PEPITA', 'PEPA PEREZ', 'FINANZAS'),
('JUAN', 'MARTIN', 'JUAN POTRO', 'TRANSITO DEL EDO'),
('ROGER', 'FEDE', 'ROGER FEDERER', 'CULTURA'),
('DIANA', 'DIDI', 'DIANA ASUARA', 'RECURSOS HUMANOS'),
('EMILI', 'EMI', 'EMILI COSTE', 'FINANZAS'),
('FERNANDA', 'FER', 'FERNANDA R', 'RECURSOS HUMANOS'),
('SUAREZ', 'SIRO', 'SUAREZ MARTINEZ', 'FINANZAS'),
('KISIFUR', 'OSOS', 'KISIFUR OSO', 'RECURSOS HUMANOS'),
('LEONARDO', 'TORTUGA', 'LEONARDO PORTO', 'TRANSITO DEL EDO'),
('DONATELO', 'TORTU', 'DONATELO CHIAPAS', 'PARQUES Y JARDINES'),
('MIGUEL', 'MIKE', 'MIGUEL VASQUE', 'CULTURA'),
('RAFITA', 'VALD', 'RAFITA VALDE', 'TRANSITO DEL EDO'),
('AMANDA', 'EMA', 'AMANDA LULU', 'FINANZAS'),
('GABY', 'GOGO', 'GABY MASTHER', 'FINANZAS'),
('MARTIN', 'KEVIN', 'MARTIN KEVINNN', 'CULTURA'),
('BRAD', 'PITT', 'BRAD PITINO', 'TRANSITO DEL EDO'),
('ANGY', 'XSL', 'ANGY JOLIE', 'PARQUES Y JARDINES'),
('ROBERT', 'RIANA', 'ROBERT NIRO', 'TRANSITO DEL EDO'),
('KAKA', 'KAI', 'KAKA MILAN', 'CULTURA');

Tarea 4

Diagrama E/R

Creación de Tabla en MySQL 5.0

CREATE TABLE IF NOT EXISTS `ciudadanos` (

`FOLIO` varchar(20) NOT NULL,

`RFC` varchar(20) NOT NULL,

`CURP` varchar(20) NOT NULL,

`TELEFONO` varchar(10) NOT NULL,

`EXTENSION` varchar(5) NOT NULL,

`APELLIDOPATERNO` char(25) NOT NULL,

`APELLIDOMATERNO` varchar(25) NOT NULL,

`NOMBRE` varchar(25) NOT NULL,

`CALLE` varchar(40) NOT NULL,

`NUMERO` varchar(5) NOT NULL,

`ENTRE` varchar(60) NOT NULL,

`COLONIA` varchar(40) NOT NULL,

`CP` varchar(5) NOT NULL,

`ESTADO` varchar(25) NOT NULL,

`CIUDAD` varchar(25) NOT NULL,

`CORREO` varchar(40) NOT NULL,

`ID` varchar(15) NOT NULL,

PRIMARY KEY (`FOLIO`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `reportes` (

`FOLIO` varchar(15) NOT NULL,

`ID` varchar(15) NOT NULL,

`NOMBRE` varchar(60) NOT NULL,

`TURNADO` varchar(50) NOT NULL,

`ASUNTO` varchar(4000) NOT NULL,

`FECHA` varchar(20) NOT NULL,

PRIMARY KEY (`FOLIO`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `usuarios` (

`USUARIO` varchar(10) NOT NULL,

`CONTRASENA` varchar(10) NOT NULL,

`NOMBRE` varchar(50) NOT NULL,

`AREA` varchar(40) NOT NULL,

PRIMARY KEY (`USUARIO`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Reportes

Diccionario de Datos

Lectura 13 - Recuperación

miércoles, 21 de enero de 2009

INTRODUCCIÓN

En el siguiente resumen se presenta los diferentes tipos de fallo que pueden producirse en una computadora ya que estos se producen por varios motivos como: fallos de disco, cortes de corriente, errores en el software, incluso sabotaje. En cada uno de estos casos puede perderse información, es por esto que cada sistema de base de datos debe tener un esquema de recuperación de datos el cual debe constar de una alta disponibilidad para minorizar el tiempo en el que no se puede usar la información. Es por esto que se exponen cada uno de estos problemas con más detalle.

1.1. CLASIFICACIÓN DE LOS FALLOS

En un sistema puede producirse varios tipos de fallos, cada uno de los cuales requiere un tratamiento diferente. El tipo de fallo más fácil de tratar es el que no te conduce a una perdida de información en el sistema. Los fallos más difíciles de tratar son aquellos que provocan una perdida de información. Es por eso que abordaremos solo los siguientes tipos de fallos:

• Fallo en la transacción. Hay dos tipos de errores que pueden hacer que una transacción falle:

- Error lógico. La transacción no puede continuar con su ejecución normal a causa de alguna condición interna, como una entrada incorrecta, datos no encontrados, desbordamiento o exceso del límite de recursos.
- Error del sistema. El sistema se encuentra en un estado no deseado, como consecuencia del cual una transacción no puede continuar con su ejecución normal. Sin embargo, se puede volver a ejecutarse mas tarde.

• Caída del sistema. Un mal funcionamiento del hardware o un error en el software de la base de datos o del sistema operativo causa la perdida del contenido de la memoria volátil y aborta el procesamiento de una transacción. El contenido de la memoria no volátil permanece intacto y no se corrompo. La suposición de que los errores de hardware o software fuercen una parada del sistema, pero no corrompan el contenido de la memoria no volátil, se conoce como supuesto de fallo-parada.
• Fallo de disco. Un bloque del disco pierde su contenido como resultado de bien una colisión de la cabeza lectora, bien un fallo durante una operación de transferencia de datos. las copias de datos que se encuentran en otros discos o en archivos de seguridad en medios de almacenamiento secundarios, como cintas, se utilizan para recuperarse del fallo.

Para determinar como el sistema debe recuperarse de los fallos, es necesario identificar los modos de fallo de los dispositivos de almacenamiento. Entonces se pueden proponer algoritmos para garantizar la consistencia de la base de datos y la atomicidad de las transacciones a pesar de los fallos, a los cuales se le conocen como algoritmos de recuperación, constan de dos partes:

1. Acciones llevadas a cabo durante al procesamiento normal de transacciones para asegurar que existe información suficiente para permitir la recuperación frente a fallos.
2. Acciones llevadas a cabo después de ocurrir un fallo para restablecer el contenido de la base de datos, la atomicidad de la transacción y la durabilidad.

Para una mayor comprensión de cómo se pueden garantizar las propiedades de atomicidad y durabilidad de una transacción, se pueden comprender mejor estros medios de almacenamiento y sus métodos de acceso.

1.2. ESTRUCTURA DE ALMACENAMIENTO

1.2.1. Tipos de almacenamiento

• Almacenamiento volátil. La información que reside en almacenamiento volátil no suele sobrevivir a las caídas del sistema.
• Almacenamiento no volátil. La información que reside en almacenamiento no volátil sobrevive a las caídas del sistema.

En el estado actual de la tecnología, el almacenamiento no volátil es más lento en varios órdenes de magnitud que el almacenamiento volátil. Esta diferencia de velocidad es consecuencia de que los dispositivos de disco y de cinta sean electromecánicos, mientras que el almacenamiento volátil se basa por completo en circuitos integrados, como el almacenamiento volátil.

• Almacenamiento estable. La información nunca se pierde. A pesar de que el almacenamiento estable es teóricamente imposible de conseguir, puede obtenerse una buena aproximación usando técnicas que hagan que la perdida de información sea una posibilidad muy remota.

Ciertos sistemas están provistos de una fuente de alimentación de seguridad. Por lo que determinada memoria principal puede sobrevivir a las caídas del sistema y a cortes de corriente. Otras formas alternativas de medios de almacenamiento no volátil, como los medios ópticos, ofrecen un grado de confianza incluso más alto que el de los discos.

1.2.2. Implementación del almacenamiento estable

Para implementar almacenamiento estable se debe replicar la información necesaria en varios medios de almacenamiento no volátil (normalmente discos) con modos de fallo independientes, y actualizar esa información de manera controlada para asegurar que un fallo durante una transferencia de datos no dañara la información necesaria.
Una transferencia de bloques entre la memoria y el disco puede acabar de diferentes formas:

• Éxito. La información transferida llega a su destino con seguridad.
• Fallo parcial. Ocurre un fallo en medio de la transferencia y el bloque de destino contiene información incorrecta.
• Fallo total. El fallo ocurre suficientemente pronto durante la transferencia para que el bloque destino permanezca intacto.

Es necesario que, si se produce un fallo durante una transferencia de datos, el sistema lo detecte e invoque a un procedimiento de recuperación para restaurar el bloque a un estado estable. Para hacer esto, el sistema debe mantener dos bloques físicos por cada bloque lógico de la base de datos; en el caso de los discos con imagen, ambos bloques están en el mismo lugar; en el caso de copia de seguridad remota, uno de los bloques es local mientras que el otro esta en un lugar remoto. Una operación de salida se ejecuta de la siguiente manera:

1. Se escribe la información en el primer bloque físico.
2. cuando la primera escritura se completa con éxito, se escribe la misma información en el segundo bloque físico.
3. la salida está complementada sólo después de que la segunda escritura finalice con éxito.

1.2.3. Acceso a los datos

El sistema de base de datos reside permanentemente en almacenamiento no volátil y se divide en unidades de almacenamiento de longitud fija denominadas bloques. Los bloques son las unidades de datos que se transfieren desde y hacia el disco y pueden contener varios elementos de datos.

Las transacciones llevan información del disco hacia la memoria principal y luego devuelven la información al disco. Las operaciones de entrada y salida se realizan en unidades de bloque. Los bloques que residen en el disco como bloques físicos, y a los que residen temporalmente en la memoria principal como bloques de memoria intermedia. El área de memoria en donde los bloques residen temporalmente se denomina memoria intermedia de disco.

La transferencia de un bloque entre disco y memoria principal se comienza a través de las dos operaciones siguientes:

1. Entrada (A) transfiere el bloque físico A a la memoria principal.
2. Salida (B) transfiere el bloque de memoria intermedia B al disco y reemplaza allí al correspondiente bloque físico.

1.3. RECUPERACION Y ATOMICIDAD

Para conseguir el objetivo de la atomicidad se debe efectuar primero la operación de salida de la información que describe las modificaciones en el almacenamiento estable sin modificar todavía la base de datos. Este procedimiento permitirá realizar la salida de todas las modificaciones realizadas por una transacción comprometida aunque se produzcan fallos. Las transacciones se ejecutan secuencialmente, esto es, solamente una transacción esta activa en cada momento.

1.4. RECUPERACION BASADA EN EL REGISTRO HISTORICO

La estructura mas ampliamente utilizada para guardar las modificaciones de una base de datos es el registro histórico. El registro histórico es una secuencia de registros que mantiene un registro de todas las actividades de actualización de la base de datos. Existen varios tipos de registros del registro histórico. Un registro de actualización del registro histórico describe una única escritura en la base de datos y tiene los siguientes cambios:

• El identificador de la transacción es un identificador único de la transacción que realiza la operación escribir.
• El identificador del elemento de datos es un identificador único del elemento de datos que se escribe.
• El valor anterior es el valor que tenía el elemento de datos antes de la escritura.
• El valor nuevo es el valor que tendrá el elemento de datos después de la escritura.

Existen otros registros del registro histórico especiales para registrar sucesos significativos durante el procesamiento de una transacción tales como el comienzo de una transacción y el éxito o aborto de la misma.

1.4.1 Modificación diferida de la base de datos

La técnica de la modificación diferida garantiza la atomicidad de las transacciones mediante el almacenamiento de todas las modificaciones de la base de datos en el registro histórico, pero retardando la ejecución de todas las operaciones escribir de una transacción hasta que la transacción se compromete parcialmente. Cuando una transacción se compromete parcialmente, la información del registro histórico asociada a esa transacción se utiliza para la ejecución de las escrituras diferidas. Si el sistema cae antes de que la transacción complete su ejecución o si la transacción aborta, la información del registro histórico simplemente se ignora.

1.4.2. Modificación inmediata de la base de datos

La técnica de modificación inmediata permite realizar la salida de las modificaciones de la base de datos a la propia base de datos mientras que la transacción esta todavía en estado activo. Las modificaciones de datos escritas por transacciones activas se denominan modificaciones no comprometidas. En caso de una caída o de un fallo en la transacción, el sistema debe utilizar el campo para el valor anterior de los registros del registro histórico para restaurar los elementos de datos modificados a los valores que tuvieran antes de comenzar la transacción.
Mediante la utilización del registro histórico, el sistema puede manejar cualquier fallo que no genere una perdida de información en el almacenamiento no volátil. El esquema de recuperación usa dos procedimientos de recuperación:

• Deshacer. Restaura el valor de todos los elementos de datos actualizados por la transacción a los valores anteriores.
• Rehacer. Fija el valor de todos los elementos de datos actualizados por la transacción a los nuevos valores.

Las operaciones deshacer y rehacer deben ser idempotentes para garantizar un comportamiento correcto incluso en el caso de que el fallo se produzca durante el proceso de recuperación.
Después de haberse producido un fallo, el esquema de recuperación consulta el registro histórico para determinar las transacciones que deben rehacerse y las que deben deshacerse.

1.4.3. Puntos de revisión

Cuando ocurre un fallo en el sistema, en principio es necesario recorrer completamente el registro histórico para hallar la información. En este enfoque hay dos inconvenientes principales:

1. El proceso de búsqueda consume tiempo.
2. La mayoría de las transacciones que deben rehacerse de acuerdo con el algoritmo ya tienen escritas sus actualizaciones en la base de datos. aunque el hecho de volver a ejecutar estas transacciones no produzca resultados erróneos, si repercutirá en un aumento del tiempo de ejecución del proceso de recuperación.

Para reducir este tipo de sobrecarga se introducen los puntos de revisión. Durante la ejecución, el sistema actualiza el registro histórico utilizando la técnica de modificación diferida de la base de datos ó la técnica de modificación inmediata de la base de datos. Además el sistema realiza periódicamente puntos de revisión, en los cuales tiene lugar la siguiente secuencia de acciones:

1. escritura en almacenamiento estable de todos los registros del registro histórico que residan en ese momento en memoria principal.
2. escritura en disco de todos los bloques de memoria intermedia que se hayan modificado.
3. escritura en almacenamiento estable de un registro del registro histórico .

Mientras se lleva cabo un punto de revisión no se permite que ninguna transacción realice acciones de actualización, tales como escribir en un bloque de memoria intermedia o escribir un registro del registro histórico.

La presencia de un registro en el registro histórico permite que el sistema pueda hacer más eficiente su procedimiento de recuperación.

1.5. PAGINACION EN LA SOMBRA

La paginación en la sombra es una técnica de recuperación alternativa a las basadas en registro histórico. Bajo ciertas circunstancias la paginación en la sombra puede requerir menos acceso al disco que los métodos basados en registro histórico. No obstante, existen algunos inconvenientes en el enfoque de la paginación en la sombra.

Igual que antes, la base de datos se divide en un número determinado de bloques de longitud fija a los que se denominara paginas. Tras la paginación en la sombra se mantienen dos tablas de páginas durante la vida de una transacción: la tabla de páginas actual y las tablas de páginas sombra.

Intuitivamente, el enfoque de la paginación en la sombra para recuperación se basa en almacenar la tabla de páginas sombra en almacenamiento no volátil, de modo que puede recuperarse el estado de la base de datos antes de la ejecución de una transacción en caso de producirse una caída del sistema o de que se abortase la transacción. La tabla actual de páginas se escribe en almacenamiento no volátil cuando la transacción se compromete. Entonces, la tabla actual de páginas se convierte en la nueva tabla de páginas de sombra y se concede el permiso para la ejecución de la siguiente transacción.

La paginación en la sombra presenta varias ventajas frente a as técnicas basadas en registro histórico. Se elimina la sobrecarga de escritura del registro histórico y la recuperación es notablemente más rápida. Sin embargo la técnica de paginación en la sombra también tiene ciertos inconvenientes:

• Sobrecarga en el compromiso.
• Fragmentación de datos.
• Recogida de basura.

Además de los inconvenientes anteriores, la paginación en la sombra presenta más dificultades que las técnicas basadas en registro histórico para adaptarla a sistemas que permitan la ejecución concurrente de varias transacciones. Por todas estas razones no esta muy extendido el uso de la paginación en la sombra.

1.6. TRANSACCIONES CONCURRENTES Y RECUPERACIÓN

Ahora se vera como modificar y extender el esquema de recuperación basado en registro histórico para permitir la ejecución concurrente de varias transacciones. El sistema sigue teniendo una única memoria intermedia de disco y un único registro histórico independiente del número de transacciones concurrentes. Todas las transacciones comparten los bloques de la memoria intermedia. Se permiten actualizaciones inmediatas y que un bloque de la memoria intermedia tenga elementos de datos que hayan sido modificados por una o más transacciones.

1.6.1. Interacción con el control de concurrencia

El esquema recuperación depende en gran medida del esquema de control de concurrencia que se use. Para retroceder los efectos de una transacción fallida deben deshacerse las modificaciones realizadas por esa transacción.

Es necesario, por tanto, que si una transacción modifica el valor de un elemento de datos, ninguna otra transacción pueda modificar el mismo elemento de datos hasta que se haya comprometido o se haya retrocedido. Este registro puede satisfacerse fácilmente utilizado bloqueo estricto de fases, esto es, bloqueo de dos fases manteniendo bloqueos exclusivos hasta el final de la transacción.

1.6.2. Retroceso de transacciones

Se utiliza el registro histórico para retroceder una transacción fallida. El registro histórico se explora hacia atrás; para cada registro del registro histórico, se restablece el valor del elemento de datos son su valor anterior. La exploración del registro histórico termina cuando se encuentra el registro. Es importante empezar por el final, ya que una transacción puede haber actualizado más de una vez el valor de un elemento datos. Una vez que haya actualizado un elemento de datos, ninguna otra transacción podría haber actualizado el mismo elemento de datos debido a los registros del control de concurrencia. Así pues la restricción del valor anterior de un elemento de datos no borrara los efectos de otra transacción.

1.6.3. Puntos de revisión

Los puntos de revisión son usados para reducir el número de registros del registro histórico que deben ser examinados cuando el sistema se recupera de una caída. Se asume que no existe la concurrencia, durante la recuperación es necesario considerar solamente las siguientes transacciones:

• Las transacciones que comenzaron después del último punto de revisión.
• La única transacción, si la había, que estaba activa en el momento de grabarse el ultimo punto de revisión.

Cuando las transacciones pueden ejecutarse concurrentemente, la situación se torna mas complicada ya que varias transacciones pueden estar activas en el momento en que se produce el último punto de revisión.

En un sistema de procesamiento de transacciones concurrente es necesario que el registro del registro histórico correspondiente a un punto de revisión sea de la forma , donde L, es una lista con las transacciones activas en el momento del punto de revisión.

El requisito de que las transacciones no puedan realizar modificaciones sobre los bloques de la memoria intermedia ni sobre el registro histórico durante un punto de revisión puede resultar molesto, ya que el procesamiento de transacciones tendrá que parar durante la ejecución de un punto de revisión. Un punto de revisión durante el cual se permite que las transacciones realicen modificaciones incluso mientras los bloques de memoria intermedia se están guardando en disco, se denomina punto de revisión difuso.

1.6.4. Recuperación al reiniciar

El sistema construye dos listas cuando se recupera de una caída: la lista- deshacer, que consta de las transacciones que han de deshacer, y la lista-rehacer, que esta formada por las transacciones que deben rehacerse.

Estas dos listas se construyen durante la recuperación de la siguiente manera. Al principio ambas están vacías. Luego se recorre el registro histórico hacia atrás examinando cada registró hasta que se encuentra el primer registro .

Una vez que se han examinado los registros apropiados del registro histórico, se atiende al contenido de la lista L en el registro punto de revisión.

Cuando se termina la lista-rehacer y la lista-deshacer, el proceso de recuperación procede de la siguiente manera:

1. Se recorre de nuevo el registro histórico hacia atrás comenzando en el ultimo registro y se realiza una operación deshacer por cada registro del registro histórico que pertenezca una transacción de la lista-deshacer.
2. Se localiza el ultimo registro del registro histórico.
3. Se recorre el registro hacia delante desde el ultimo registro se realiza una operación rehacer por cada registro del registro histórico que permanezca a una transacción de la lista-rehacer.

Es importante procesar el registro histórico hacia atrás en el paso para garantizar que el estado resultante de la base de datos sea correcto.

1.7. GESTIÓN DE LA MEMORIA INTERMEDIA

1.7.1. Registro histórico con memoria intermedia

El coste de realizar la escritura en almacenamiento estable de un bloque es suficientemente elevado para que sea deseable escribir de una sola vez varios registros del registro histórico. Para hacer esto se escriben los registros del registro histórico en una memoria intermedia almacenada en la memoria principal en la que permanecen durante un tiempo hasta que se guardan en almacenamiento estable. Se pueden acumular varios registros del registro histórico en la memoria intermedia del registro histórico y escribirse en almacenamiento estable con una sola operación. El orden de los registros del registro histórico en el almacenamiento estable debe ser exactamente el mismo orden en el que fueron escritos en la memoria intermedia del registro histórico.

Debido a la utilización de la memoria intermedia en el registro histórico, antes de ser escrito en almacenamiento estable, un registro del registro histórico puede permanecer únicamente en memoria principal (almacenamiento volátil) durante un espacio de tiempo considerable.

1.7.2. Base de datos con memoria intermedia

La base de datos se almacena en almacenamiento no volátil (disco) y cuando es necesario, se traen a memoria principal los bloques de datos que hagan falta. Como la memoria principal suele ser mucho más pequeña que la base de datos completa, puede ser necesaria la sobreescritura de un bloque B1 en memoria principal cuando es necesario traer a memoria otro bloque B2. Si B1 ha sido modificado, B1 se debe escribir ante de traer B2. Esta jerarquía de almacenamiento se corresponde con el concepto usual de memoria virtual.

1.7.3. El papel de sistema operativo en la gestión de la memoria intermedia

La memoria intermedia de la base de datos puede gestionarse usando uno de estos dos enfoques:

1. El sistema de base de datos reserva parte de la memoria principal para utilizarla como memoria intermedia y es el, en vez del sistema operativo, el que se encarga de gestionarlo.
2. El sistema de base de datos implementa su memoria intermedia dentro de la memoria virtual del sistema operativo.

Ambos enfoques tienen algunos inconvenientes, debe elegirse cualquiera de los dos excepto si el sistema operativo esta diseñado para soportar los requisitos del registro histórico de base de datos.

1.8. FALLO CON PERDIDA DE ALMACENAMIENTO NO VOLATIL

A pesar de que es raro encontrarse con un fallo en el que se pierde información de almacenamiento no volátil, es necesario prepararse para afrontar este tipo de fallos.
La idea básica es volcar periódicamente (una vez al día) el contenido entero de la base de datos en almacenamiento estable.

Más precisamente, ninguna transacción puede estar activa durante el procedimiento de volcado y tendrá lugar una secuencia de acciones similar a la utilizada en los puntos de revisión:

1. Escribir en almacenamiento estable todos los registros del registro histórico que residan en ese momento en memoria principal.
2. Escribir en disco todos los bloques de la memoria intermedia.
3. Copiar el contenido de la base de datos en almacenamiento estable.
4. Escribir el registro del registro histórico en almacenamiento estable.

Para la recuperación por pérdida de almacenamiento no volátil se restituye la base de datos en el disco utilizando el último volcado realizado. Entonces se consulta el registro histórico y se rehacen todas las transacciones que se hubieran comprometido desde que se efectuó el último volcado.

1.9. TÉCNICAS AVANZADAS DE RECUPERACIÓN

Se han propuesto varias técnicas de recuperación alternativas que pueden aplicarse incluso con bloqueos de liberaron rápida.

1.9.1. Registro de deshacer lógico

Si se usa una operación deshacer física, es decir, si durante el retroceso se escriben los valores anteriores de los nodos internos del árbol B+ (antes de ejecutar la operación inserción), podrían perderse algunas de las modificaciones realizadas por inserciones o barrados ejecutados posteriormente por otras transacciones.

La operación inserción no debe deshacer así, sino con una operación deshacer lógica, esto es, mediante la ejecución de una operación borrado en este caso.

Las operaciones de inserción y borrado son ejemplos de un tipo de operaciones que requieren operaciones deshacer lógicas, ya que liberan rápidamente los bloqueos. Estas operaciones se denominan operaciones lógicas.

1.9.2. Retroceso de transacciones

El retroceso de transacciones durante el modo de operación normal (esto es, no durante la fase de recuperación). Se recorre el registro histórico hacia atrás y se usan los registros del registro histórico pertenecientes a la transacción para devolver a os elementos de datos sus valores anteriores. Estos registros del registro histórico se denominan a veces registros de compensación del registro histórico. Estos registros no necesitan información para deshacer puesto que nunca es necesario realizar esta operación.

1.9.3. Punto de revisión

Los puntos de revisión suspenden temporalmente las modificaciones sobre la base de datos y se llevan a cabo las siguientes acciones:

1. Se escriben en almacenamiento estable todos los registros del registro histórico que se encuentran en ese momento en la memoria principal.
2. Se escriben en disco todos los bloques de la memoria intermedia que se hayan modificado.
3. Se escribe en almacenamiento estable el registro , donde L es una lista de todas las transacciones activas.

1.9.4. Recuperación al reiniciar

Las acciones de recuperación se realizan en dos fases cuando se vuelve a iniciar el sistema de base de datos después del fallo:

1. En la fase rehacer se vuelven a realizar modificaciones de todas las transacciones mediante la exploración hacia delante del registro histórico a partir del ultimo punto de revisión.
2. en la fase deshacer se retroceden todas las transacciones de la lista-deshacer. Se realiza el retroceso recorriendo el registro histórico hacia atrás empezando por el final.

1.9.5. Revisión difusa

La revisión difusa requiere que, mientras se efectúa el punto de revisión, se suspendan temporalmente todas las modificaciones de la base de datos. Si el número de painas de la memoria intermedia es grande, un punto de revisión puede llevar mucho tiempo, lo que puede resultar en una interrupción inaceptable en el procedimiento de transacciones. Para evitar estas interrupciones es posible modificar la técnica para permitir modificaciones después de haber escrito en el registro histórico el registro revisión, pero antes de escribir en disco los bloques de la memoria intermedia que han sufrido modificaciones. El punto de revisión así generado recibe el nombre de punto de revisión difuso.

1.9.6. Aries

El método de recuperación Aries representa a los métodos actuales de recuperación. La técnica de recuperación avanzada que se ha descrito se ha modelado después de Aries, pero se ha simplificado significativamente para ilustrar los conceptos clave y hacerlo mas fácil de comprender. En cambio Aries utiliza varias técnicas para reducir la sobrecarga de los puntos de revisión. En particular Aries es capaz de evitar rehacer muchas operaciones registradas que ya se han realizado y de reducir la cantidad de información registrada. El precio pagado es una mayor complejidad, pero beneficios merecen la pena.

Las diferencias principales entre Aries y el algoritmo de recuperación avanzada expuesto son que Aries:

1. Usa un número de secuencia del registro histórico para identificar a los registros del registro histórico.
2. Soporta operaciones rehacer fisiológicamente, que son físicas en el sentido en que la pagina afectada esta físicamente identificada, pero que pueden ser lógicas en la pagina.
3. Usar una tabla de paginas desfasadas para minimizar las operaciones rehacer innecesarias durante la recuperación.
4. Usa un esquema de revisión difusa que solo registra información sobre las páginas desfasadas e información asociada y no requiere siquiera la escritura de las páginas desfasadas a disco.

1.9.6.1 Estructura de datos

Cada registro de Aries tiene un número de secuencia del registro histórico (NSR) que lo identifica unívocamente. El NSR consiste en un número de archivo y un desplazamiento dentro del archivo.

1.9.6.2. Algoritmo de recuperación

Aries recupera de una caída del sistema en tres fases:

• Paso de análisis. Este paso determina las transacciones que hay que deshacer, las paginas que están desfasadas en el momento de la caída y el NSR en el que debería comenzar el paso rehacer.
• Paso rehacer. Este paso comienza en una posición determinada durante el análisis y realiza una operación rehacer, repitiendo la historia, para llevar a la base de datos al estado anterior a la caída.
• Paso deshacer. Este paso retrocede todas las transacciones incompletas en el momento de la caída.

1.9.6.3. Otras características

Entre otras de las características que proporciona Aries se encuentran:
• Independencia de recuperación. Algunas paginas se pueden recuperar independientemente de otras, de forma que se pueden usar incluso cuando se estén recuperando otras.
• Puntos de almacenamiento. Las transacciones pueden registrar puntos de almacenamiento y se pueden retroceder parcialmente hasta un punto de almacenamiento.
• Bloqueo de grano fino. El algoritmo de recuperación de Aries se puede usar con algoritmos de control de concurrencia de índices que permiten el bloqueo en el nivel de tuplas de los índices, en lugar del bloqueo en el nivel de las páginas, lo que aumenta significativamente la concurrencia.
• Optimizaciones de recuperación. La TablaPaginasDesfasadas se puede usar para preextraer páginas durante la operación rehacer, en lugar de extraer una pagina solo cuando el sistema encuentra un registro del registro histórico a aplicar a la página.

1.10. SISTEMAS REMOTOS DE COPIAS DE SEGURIDAD

Los sistemas tradicionales de procesamiento de transacciones son sistemas centralizados o sistemas cliente-servidor. Estos sistemas deben proporcionar una disponibilidad elevada, es decir, el tiempo en que el sistema no es utilizable debe ser extremadamente pequeño.

Varios aspectos que deben adoptarse al diseñar sistemas remotos para copias de seguridad son los siguientes:

• Detección de fallos. Al igual que en los protocolos para el manejo de fallos en sistemas distribuidos, es importante que el sistema remoto de copia de seguridad detecte que el sitio principal ha fallado.
• Transferencia del control. Cuando el sitio principal falla, el sitio copia de seguridad asume el procesamiento y se transforma en el nuevo sitio principal.
• Tiempo de recuperación. Si el registro histórico del sitio remoto copia de seguridad se hace grande, la recuperación puede tardar mucho.
• Tiempo de compromiso. Para asegurar que las actualizaciones de una transacción comprometida sean duraderas no se debe declarar comprometida una transacción hasta que sus registros del registro histórico hayan alcanzado el sitio copia de seguridad.

CONCLUSIÓN

Podemos concluir que cada uno de lo elementos en la recuperación de información de la base de datos son de gran utilidad, teniendo también claro que los sistemas de recuperación tienen fallos lo cuales se describieron anteriormente; así también se mencionaron cuales son los mas utilizados, al mismo tiempo sus ventaja y desventajas.

BIBLIOGRAFIA

Fundamentos de Bases de Datos. Cuarta Edición
Silberschatz; Korth; Sudarshan.
McGraw Hill. 2002

Lectura 12 - Concurrencia

INTRODUCCIÓN.

En este presente resumen se ve a conocer lo que es concurrencia. Cuando se ejecutan varias transacciones en la base de datos, se puede considerar dejar la propiedad de aislamiento. En varias ocasiones es llevar el control de todas las transacciones a través de esquemas de control de concurrencia.
Todos estos esquemas se describen a continuación, aquí se basan en la propiedad de secuencialidad.

PROTOCOLOS BÁSICOS EN EL BLOQUEO

Una forma de asegurar la secuencialidas es exigir que el acceso a los elementos de datos se haga en exclusión mutua; es decir, mientras una transacción accede a un elemento de datos, ninguna otra transacción puede modificar dicho elemento.

BLOQUEOS.

Existen muchos modos mediante los cuales se puede bloquear un elemento de datos.
1. Compartido. Si una transacción T obtiene un bloqueo en modo compartido (denotado por C) sobre le elemento Q, entonces T puede leer Q pero no escribir.
2. Exclusivo. Si una transacción T obtiene un bloqueo en modo exclusivo (denotado por X) sobre el elemento Q, entonces T puede tanto leer como escribir Q.
Es necesario que toda transacción solicite un bloqueo del modo apropiado sobre el elemento de datos Q dependiendo de los tipos de operaciones que se vayan a realizar sobre Q. La petición se hace al gestor se control de concurrencia. La transacción puede realizar la operación solo después de que el gestor de control de concurrencia conceda el bloqueo a la transacción.
.
Una transacción solicita un bloqueo compartido sobre el elemento de datos Q a través de la instrucción bloquear-C (Q). De forma similar se solicita un bloqueo exclusivo a través de la instrucción bloquear-X (Q). Se puede desbloquear un elemento de datos Q por medio de la instrucción desbloquear (Q).

Leer(B);
B:=B-50
Transacción T1
Escribir(B);
Desbloquear (B);
Bloquear-X(A);
Leer(A);
A:= A+50;
Escribir(A);
Desbloquear

Bloquear-C(A);
Leer(A);
Transacción T2
Desbloquear(A);
Bloquear-C(B);
Leer(B);
Desbloquear(B);
Visualizar (A+B).
Transacción T2

Se exige en toda transacción del sistema siga un conjunto de reglas llamado protocolo de bloqueo, que indica el momento en que una transacción puede bloquear y desbloquear cada uno de los elementos de datos. Los protocolos de bloqueo restringen el número de planificaciones posibles. El conjunto de tales planificaciones es un subconjunto propio de todas las planeaciones secuenciales posibles.

Bloquear-X(B);
Leer(B);
Transacción T3
B:=B-50;
Escribir(B);
Bloquear-X(A);
Leer(A);
A:=A-50;
Desbloquear(B);
Desbloquear(A).

Se dice que una planificación S es lega bajo un protocolo de bloqueo dado si S es una planificación posible para un subconjunto de transacciones que sigan las reglas de protocolo de bloqueos. Se dice que un protocolo asegura la secuencialidad en cuanto a conflictos si y solo si todas las planificaciones legales son secuenciables en cuanto a conflictos; en otras palabras, para todas las planificaciones legales la relación àasocia es a cíclica.

Bloquear-C(A);
Transacción T4
Leer(A);
Bloquear-C(B);
Leer(B);
Visualizar(A+B);
Desbloquear (A);
Desbloquear (B).

CONCESIÓN DE BLOQUEOS.

Cuando una transacción solicita un bloqueo de un modo particular sobre un elemento de datos y ninguna otra transacción posee un bloqueo sobre el mismo elemento de datos en un modo conflictivo, se puede conceder el bloqueo.
Se puede evitar la inanición de las transacciones al conceder los bloqueos de la siguiente manera: cuando una transacción T 1 solicita un bloqueo sobre un elemento de datos Q en un modo particular M, el gestor de control de concurrencia concede el bloqueo siempre que

1. No exista un transacción que posea un bloqueo sobre Q en un modo que este en conflicto con M.
2. No exista otra transacción que este esperando un bloqueo sobre Q y que lo haya solicitado antes que T.

De este modo, una partición de bloqueo nunca se quedara bloqueada por otra petición de bloqueo solicitada mas tarde.

PROTOCOLOS DE BLOQUEO EN DOS FASES.

Un protocolo que asegura la secuencialidad es el protocolo de bloqueos de dos fases. Este protocolo exige que cada transacción realice las peticiones de bloqueo y desbloqueo de dos fases:

1. Fase de crecimiento. Una transacción puede obtener bloqueos pero no puede liberarlos.
2. Fase de decrecimiento. Una transacción puede liberar bloqueos pero no puede obtener ninguno nuevo.

Inicialmente una transacción esta en la fase de crecimiento. La transacción adquiere los bloqueos que necesite. Una ves que la transacción libera un bloqueo, entra en la fase de decrecimiento y no puede realizar mas peticione de bloqueo.
Se pude mostrar que el protocolo de bloqueo de dos fases asegura la secuencialidad en cuanto a conflictos. Considérese cualquier transacción. Le punto de la planificación en el cual la transacción obtiene su bloqueo final (el final de la fase de crecimiento) se denomina punto de bloqueo de la transacción El protocolo de bloqueo de dos fases no asegura la ausencia de interbloqueos.
Los retrocesos en cascada se pueden evitar por medio de una modificación del protocolo de bloqueo de dos fases que se denomina protocolo de bloqueo estricto de dos fases. Este protocolo exige que, además de que el bloqueo sea de dos fases, una transacción debe poseer todos los bloqueos en modo exclusivo que tome hasta que dicha transacción se complete., este requisito asegura que todo dato que describe una transacción no comprometida esta bloqueado en modo exclusivo hasta que la transacción se complete.
Otra variante del bloqueo de dos fases es el protocolo riguroso de dos fases, el cual exige que se posean todos los bloqueos hasta que se comprometa la transacción .
´
IMPLEMENTACIÓN DE BLOQUEOS.

Un gestor de bloqueos se puede implementar como un proceso que recibe mensajes de transacciones y envía mensajes como respuesta. El proceso gestor de bloqueos responde a los mensajes de solicitud de bloqueo con mensajes de concesión de bloqueo, o con mensajes que solicitan un retroceso de la transacción. Los mensajes de desbloqueo tan solo requieren un reconocimiento como respuesta, pero pueden dar lugar a un menaje de concesión para otra transacción que este esperando.
El gestor de bloqueos utiliza la siguiente estructura de datos: para cada elemento de datos que esta actualmente bloqueado, mantiene una lista enlazada de registros, uno para cada solicitud en el orden en que llegaron las solicitudes. Utiliza una tabla de asociación, indexada por el nombre del elemento de datos, para encontrar la lista enlazada para cada miembro e datos; esta tabla se denomina tabla de bloqueos. Cada registro en la lista enlazada da cada elemento de datos anota que transacción hizo la solicitud, y en que modo de bloqueo se solicito. El registro también anota si la solicitud ya se ha concedido.

PROTOCOLOS BASADOS EN GRAFOS.

Si se desean desarrollar protocolos que no sean de dos fases, es necesario tener información adicional acerca de la forma en que cada transacción accede a la base de datos. Existen varios modelos que pueden obtener la información adicional, que difieren en la cantidad de información que proporcionan. El modelo mas simple exige que se tenga un conocimiento previo acerca del orden en el cual se accede a los elementos de la base de datos. Dada esta información es posible construir protocolos de bloqueo que no sean de dos fases pero que no obstante aseguren la secuencialidad.
En el protocolo de árbol solo se permite la instrucción de bloqueo bloquear-X. Cada transacción Ti puede bloquear un elemento de datos al menos una vez y debe seguir las siguientes reglas:

1. El primer bloqueo de T, puede ser sobre cualquier elemento de datos.
2. Posteriormente, T puede bloquear un elemento de datos Q solo si T esta bloqueando actualmente al padre de Q.
3. Los elementos de datos bloqueados se pueden desbloquear en cualquier momento.
4. T no puede desbloquear de nuevo un elemento de datos que ya haya bloqueado y desbloqueado anteriormente.

PROTOCOLOS BASADOS EN MARCAS TEMPORALES.

En los protocolos de bloqueo que se han descrito antes se determina el orden entre dos transacciones conflictivas en tiempo de ejecución a través del primer bloqueo que soliciten ambas que traiga consigo modos incompatibles. Otro método para determinar el orden de secuencialidad es seleccionar previamente un orden entre las transacciones. El método mas común para hacer esto es utilizar un esquema de ordenación por marcas temporales.

MARCAS TEMPORALES.

Existen dos métodos simples para implementar ese esquema:
1. Usar el valor del reloj del sistema como marca temporal; es decir, la marca temporal de una transacción es igual al valor del reloj en el momento en que la transacción entra en el sistema.
2. Usar un contador lógico que se incrementa cada vez que se asigna una nueva marca temporal; es decir, la marca temporal de una transacción es igual al valor del contador en el momento en el cual la transacción entra en el sistema.
Las marcas temporales de las transacciones determinan el orden da secuencia.
· Marca_temporal-E(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con éxito escribir(Q).
· Marca_temporal-L(Q) denota la mayor marca temporal de todas las transacciones que ejecutan con éxito leer(Q).
Estas marcas temporales se actualizan cada vez que se ejecuta una nueva operación leer (Q) o escribir (Q).

PROTOCOLOS DE ORDENACIÓN POR MARCAS TEMPORALES.

Asegura que todas las operaciones leer y escribir conflictivas se ejecutan en el orden de las marcas temporales. Este protocolo opera como sigue:
1. Supóngase que la transacción T ejecuta leer(Q).
a. Si MT(T)<>

REGLA DE ESCRITURA DE THOMAS.

La modificación al protocolo de ordenación por marcas temporales, denominada regla de escritura de Thomas, es la siguiente. Supóngase que la transacción T ejecuta escribir Q.
1. Si MT(T) <>

PROTOCOLOS BASADOS EN VALIDACIÓN.

Se asume que una transacción T se ejecuta en dos o tres fases diferentes durante su tiempo de vida dependiendo de si es una transacción de solo lectura o una de actualización. Las fases son, en orden.
1. Fase de lectura. Durante esta fase tiene lugar la ejecución de la transacción T. Se leen los valores de varios elementos de datos y se almacenan en variables locales de T. Todas las operaciones escribir se realizan sobre las variables locales temporales sin actualizar la base de datos actual.
2. Fase de validación. La transacción T realiza una prueba de validación para determinar si puede copiar a la base da datos las variables locales temporales que tienen los resultados de las operaciones escribir sin causar una violación de secuencialidad.
3. Fase de escritura. Si la transacción T tiene éxito en la validación (paso 2) entonces las actualizaciones reales se aplican a la base de datos. En otro caso T se retrocede.
Cada transacción debe pasar por las tres fases y en el orden que se muestra. Sin embargo, se pueden entrelazar las tres fases de la ejecución concurrente de las transacciones.
Para realizar la prueba de validación se necesita conocer le momento en que tienen lugar las distintas fases de las transacciones T. Se asociaran por tanto tres marcas temporales distintas a las transacción T.

1. Inicio (T). momento en el cual T comienza si ejecución.
2. Validación (T), momento en el cual T termina su fase de lectura y comienza su fase de validación.
3. Fin (T), momento en el cual T termina su fase de escritura.

GRANULARIDAD MÚLTIPLE.

En los esquemas de control de concurrencia que se han descrito antes se ha tomado cada elemento de datos individual como la unidad sobre la cual se producía la sincronización.
Si una transacción T necesita acceder solo a unos cuantos datos, ya que en ese caso se perdería la concurrencia.
Lo que se necesita en un mecanismo que permita al sistema definir múltiples niveles de granularidad. Se puede hacer uno permitiendo que los elementos de datos sean de vario tamaños y definiendo una jerarquía de granularidades de los datos, en el cual las granularidades pequeñas están anidadas en otras mas grandes. Una jerarquía tal se puede representar gráficamente como un árbol.
Este protocolo permite la concurrencia y reduce la sobrecarga de bloqueos. Es particularmente útil en las aplicaciones con una mezcla de

· Transacciones cortas que solo acceden a algunos elementos de datos.
· Transacciones largas que producen informes a partir de un archivo completo o un conjunto de archivos.

ESQUEMAS DE MULTIPLEXIÓN.

En los esquema de control de concurrencia multiversión, cada operación escribir (Q ) crea una nueva versión de (Q). Cuando se realiza una operación leer (Q) el gestor de control de concurrencia elige una de las versiones de Q que se va a leer.

ORDENACIÓN POR MARCAS TEMPORALES.

La técnica mas frecuente utilizada en los sistemas multivesión es la de las marcas temporales . A cada transacción T del sistema se le asocia una única marca temporal estática que se denota MT(T).
A cada elemento de datos Q se le asocia una secuencia de versiones . Cada versión Q contiene tres campos:

· Contenido
· Marca_temporal-E(Q1)
· Marca_temporal-L(Q1)

BLOQUEO DE DOS FASES MULTIVERSION.

Intenta conocer las ventajas del control de concurrencia con la ventaja con las ventajas del bloqueo de dos fases. Este protocolo distingue entre transacciones de solo lectura y transacciones de actualización.
Las transacciones de actualización realizar un bloqueo de dos fases riguroso; es decir, mantienen todos los bloqueos hasta el final de la transacción. Así se pueden secuenciar según su orden de terminación. Cada elemento de datos tiene una única marca temporal. La marca temporal no es en este caso una marca temporal basada en un reloj real, sino que es un contador, que se denomina contador_mt, que se incrementa durante el procesamiento del compromiso.
El bloqueo de dos fases multiversión o variaciones de este se usan en algunos sistemas de base de datos comerciales.

TRATAMIENTO DE INTERBLOQUEOS.

Un sistema esta en estado de interbloqueo si existe un conjunto de transacciones tal que toda transacción de un conjunto esta esperando a otra transacción del conjunto.
El único remedio a esta situación no deseada es que el sistema invoque alguna acción drástica, como retroceder algunas de las transacciones involucradas en el interbloqueo. El retroceso de una transacción puede ser parcial: esto es, se puede retroceder una transacción hasta el punto donde obtuvo un bloqueo coya liberación resuelve el interbloqueo.
Existen dos métodos principales para tratar el problema de los interbloqueos. Se puede utilizar un protocolo de prevención de interbloqueos para asegurar que le sistema llegue a un estado de interbloqueo. De forma alternativa se puede permitir que el sistema llegue a un estado de interbloqueo, y tratar de recuperarse después a través de un esquema de detección y recuperación de interbloqueos.

PREVENCIÓN DE INTERBLOQUEOS.

Existen dos enfoques a la prevención de interbloqueos . Un enfoque asegura que no puede haber esperas cíclicas ordenando las peticiones de bloqueo o exigiendo que todos los bloqueos se adquieran juntos. El otro enfoque es mas cercano a la recuperación de interbloqueos y realiza retrocesos de las transacciones en lugar de esperar un bloqueo, siempre que el bloqueo puede llevar potencialmente a un interbloqueo.
Es esquema mas simple para la primera aproximación exige que cada transacción bloquee todos los elementos de datos antes de comenzar su ejecución. Este protocolo tiene dos inconvenientes principales:

1) A menudo es difícil predecir, antes que comience la transacción, cuales son los elementos de datos que es necesario bloquear.
2) La utilización de los elementos de datos puede ser muy baja, ya que muchos de los elementos de datos pueden estar bloqueados pero sin usar durante mucho tiempo.

ESQUEMAS BASADOS EN LÍMITE DE TIEMPO.

Otro enfoque simple del tratamiento de interbloqueos se basa en bloqueos con limite de tiempo. En este enfoque una transacción que haya solicitado un bloqueo espera por lo menos durante un intervalo de tiempo especificado. Si no se concede el bloqueo en ese tiempo, se dice que la transacción esta fuera de tiempo y ella misma se retrocede y vuelve a empezar.

DETECCIÓN Y RECUPERACIÓN DE INTERBLOQUEOS.

Si el sistema no utiliza algún protocolo que asegure la ausencia de interbloqueos, entonces se debe usar un esquema de detección y recuperación. Periódicamente se invoca a un algoritmo que examina el estado del sistema para determinar si hay interbloqueo. Si lo hay entonces el sistema debe intentar recuperarse del interbloqueo.

OPERACIONES PARA INSERTAR Y BORRAR.

Algunas transacciones necesitan no sólo acceder a los elementos de datos existentes; sino también poder crear nuevos elementos de datos. Otras necesitan tener la posibilidad de borrar elementos de datos.Para examinar la forma en que tales transacciones afectan al control de concurrencia se introducen las operaciones adicionales siguientes:

· Borrar (Q): borra de la base de datos el elemento de datos Q.
· Insertar (Q): inserta en la base de datos el nuevo elemento de datos Q y le asigna un valor inicial.

BORRADO.

Para comprender la manera en que puede afectar la presencia de las instrucciones borrar al control de concurrencia, se debe decidir en que casos una instrucción borrar está en conflicto con otro instrucción.
Se puede concluir lo siguiente:
En el protocolo de dos fases se necesita un bloqueo exclusivo en un elemento de datos antes de que se borre dicho elemento.
En el protocolo de ordenación por marcas temporales se debe hacer un prueba similar que la que se hacía con escribir.

INSERCIÓN

No se pueden realizar operaciones leer o escribir sobre un elemento de datos hasta que éste ultimo exista.
Puesto que insertar (Q) asigna un valor al elemento de datos Q, se trata de insertar de forma similar a escribir desde el punto de vista del control de concurrencia:En el protocolo de bloqueo de dos fases, si T­i realiza una operación insertar (Q) se da a Ti un bloqueo exclusivo sobre el elemento de datos Q recientemente creado.EL

FENÓMENO FANTASMA.

Considérese una transacción T29 que ejecuta la siguiente pregunta SQL a la base de datos bancaria:Select sum (saldo)From cuentaWhere nombre-sucursal = ‘Pamplona’La transacción T29 necesita acceder a todas las tuplas de la relación cuenta que pertenezcan a la sucursal pamplona.
Sea T30 una transacción que ejecuta la siguiente inserción SQL:
Insert into cuentValues (‘Pamplona’, C-201, 900)
Con lo anterior se espera que haya un conflicto potencial debido a las razones siguientes:Si T29 utiliza la tupla que ha insertado recientemente T30 al calcular sum(saldo), entonces T29 lee el valor que ha escrito T30. Así en una planificación secuencial equivalente a S, T30 debe ir antes de T29.
Si T29 no utiliza la tupla que ha insertado recientemente T30 al calcular sum(saldo), entonces en una planificación secuencial equivalente a S, T29 debe ir antes de T30.T29 y T30 no acceden a ninguna tupla común y sin embargo están en conflicto. En efecto, T29 y T30 están en conflicto en una tupla fantasma. Si se realiza el control de concurrencia con granularidad de tupla no se detecta dicho conflicto. Este problema recibe el nombre de fenómeno fantasma.
Una solución es la técnica de bloqueo de índice. Toda transacción que inserte una tupla en una relación debe insertar información en cada una de los índices que se mantengan en la relación.El protocolo de bloqueo de índice toma las ventajas de la disponibilidad de índices en una relación convirtiendo las apariciones del fenómeno fantasma en conflictos en los bloqueos sobre los nodos hoja índice. El protocolo opera de la siguiente manera.

· Toda relación debe tener al menos un índice.
· Una transacción T puede acceder a las tuplas de una relación únicamente después de haberlas encontrado primero a través de uno o mas índices de la relación.
· Una transacción T que realiza una búsqueda debe bloquear en modo compartido todos los nodos hoja índice a los que accede.
· Una transacción T no puede insertar, borrar o actualizar una tupla t en una relación r sin utilizar todos los índices de r.
· Hay que cumplir con las reglas del protocolo de bloqueo de dos fases.

Existen variantes de la técnica de bloqueo de índice para eliminar el fenómeno fantasma con otros protocolos de control de concurrencia.

NIVELES DÉBILES DE CONSISTENCIA.

La secuencialidad es un concepto útil porque permite a los programadores ignorar problemas relacionados con la concurrencia cuando codifican las transacciones.
Sin embargo, puede que los protocolos necesarios para asegurar la secuencialidad permitan muy poca concurrencia para algunas aplicaciones. En estos casos se utilizan los niveles más débiles de consistencia. El uso de niveles más débiles de consistencia añade una nueva carga a los programadores para asegurar la corrección de las bases de datos.

CONSISTENCIA DE GRADO DOS.

El objetivo de la consistencia de grado dos es evitar abortar en cascada sin asegurar necesariamente la secuencialidad. El protocolo de bloqueo para la consistencia de grado dos utiliza los mismos dos modos de bloqueo que se utilizan para el bloqueo de dos fases: compartido (C) y exclusivo (X). Las transacciones deben mantener el modo de bloqueo adecuado cuando tengan acceso a un elemento de datos.

ESTABILIDAD DEL CURSOR

La estabilidad del cursor es una forma de consistencia de grado dos diseñada para programas escritos en lenguajes de propósito general, los cuales iteran sobre las tuplas de una relación utilizando cursores. La estabilidad del cursor asegura que:

· La tupla que está procesando la iteración esté bloqueada en modo compartido.
· Todas las tuplas modificadas estén bloqueadas en modo exclusivo hasta que se comprometa la transacción.

NIVELES DÉBILES DE CONSISTENCIA EN SQL.

La norma SQL también permite que una transacción especifique si puede ser ejecutada de tal forma que se convierta en no secuenciable con respecto a otras transacciones.
Los nivekes de consistencia especificados por SQL-92 son los siguientes:

· Secuenciable es el predeterminado.
· Lectura repetible solo permite leer registros comprometidos, y además requiera que, entre dos lecturas de un registro realizadas por una transacción, no se permita que ninguna otra transacción actualice el registro.
· Compromiso de lectura solo permite leer registros comprometidos, pero ni siquiera requiere lecturas repetitivas.
· Sin compromiso de lectura permite incluso leer registros no comprometidos.

CONCURRENCIA EN ESTRUCTURAS DE ÍNDICE.

Los índices, se pueden convertir en un punto de mucho bloqueo, lo que prode un baja grado de concurrencia. Es aceptable que una transacción busque en un índice dos veces y se encuentre que la lectura del índice ha cambiado entre ambas búsquedas, mientras que las duplas devuelvan el conjunto correcto de tuplas. De este modo se acepta tener un acceso no secuenciable a un índice mientras siga siendo correcto dicho índice.Las técnicas que se presentan para el control de concurrencia en los arboles B+ se basan en el bloqueo, pero no se complementan ni el bloqueo de dos fases ni el protocolo de árbol.
Técnicas:
1. Se denomina protocolo de cangrejo.
a. Cuando se busca un valor clave, el protocolo de cangrejo bloquea primero el nodo raíz en modo compartido. Cuando se recorre el nodo hacia abajo, adquiere un bloqueo compartido sobre el siguiente nodo hijo. Después de adquirir el bloqueo de nodo hijo, libera el bloqueo sobre el nodo padre. Repite el proceso hasta que alcanza un nodo hoja.
b. Cuando se inserta o se borra un valor clave, el protocolo de cangrejo realiza estas acciones:

i. Sigue el mismo protocolo que para la búsqueda hasta que alcanza el nodo hoja deseado.

ii. Bloquea el nodo hoja en modo exclusivo e inserta o borra el valor clave
iii. Si se necesita dividir un nodo o combinarlo con sus hermanos, o redistribuir los valores claves entre hermanos, el protocolo del cangrejo bloquea al padre del nodo en modo exclusivo.
Si el padre requiere división, combinación o redistribución de valores clave, el protocolo mantienen el bloqueo sobre el padre, y la división, la combinación o la redistribución se siguen propagando de la misma manera.El avance de los bloqueos mientras que el protocolo baja del árbol o sube de nuevo actúa de forma similar al cangrejo.Una vez que una operación particular libere un bloqueo sobre un nodo, otras operaciones pueden acceder a ese nodo. Existe una posibilidad de interbloqueos entre las operaciones de búsqueda que bajan por el árbol, y las divisiones, combinaciones y redistribuciones que se propagan hacia arriba del árbol. El sistema puede manejar con facilidad tales interbloqueos reiniciando la operación de búsqueda desde la raíz, después de liberar los bloqueos mantenidos por la operación.

2. Consigue mas concurrencia, impidiendo que se mantenga un bloqueo sobre un nodo mientras que está adquiriendo el bloqueo sobre otro nodo, utilizando una versión modificada de los árboles B+ llamados árboles enlazados; requieren que todo el nodo mantenga un puntero a su hermano derecho.
a. Búsqueda. Se debe bloquear en nodo compartido cada nodo del árbol B+ antes que acceda a él.
b. Inserción y borrado. El sistema sigue las reglas de la búsqueda para localizar el nodo sobre el cual se va a realizar la inserción o el borrado.
c. División. Si se divide un nodo se crea uno nuevo y se convierte en el hermano derecho del nodo original.
d. Fusión. Si el nodo tiene muy pocos valores de clave de búsqueda después de un borrado, se debe bloquear en modo exclusivo el nodo con el que se debe fusionar.Una inserción o un borrado pueden bloquear un nodo, desbloquearlo y posteriormente volverlo a bloquear. Una búsqueda que se ejecute con operaciones de división o de combinación puede observar que la clave de búsqueda deseada se ha trasladado al nodo hermano derecho debido a la división o a la combinación.En la mayoría de las bases de datos las inserciones son mas frecuentes que los borrados, por lo que es probable que los nodos que tienen muy pocos valores claves de búsqueda ganen valores adicionales de forma relativamente rápida.En lugar de bloquear nodos hoja índice en dos fases algunos esquemas de control de concurrencia de índices utilizan bloqueo de valores claves individuales, permitiendo que se inserten o se borren otros valores claves de la misma hoja. Por lo tanto, el bloqueo de valores clave proporciona una concurrencia mejorada. Utilizar el bloqueo de valores clave podría permitir que se produjera el fenómeno fantasma; para prevenirlo se utiliza la técnica de bloqueo.
3. Esta técnica, cada búsqueda por índice debe bloquear no solo las claves encontradas dentro del rango, sino también el siguiente valor clave, esto es, el valor clave que es justo mayor que el ultimo valor clave que está dentro del rango de la búsqueda por índice de otra transacción, las dos transacciones entraran en conflicto en el valor clave que sigue al valor clave insertado. De forma similar, los borradores también deben bloquear el siguiente valor clave al valor que se ha borrado para asegurar que se detecten los conflictos con las subsiguientes búsquedas de otras consultas.

BIBLIOGRAFÍA:

Capitulo 16 Silverschatz.

Lectura 11 - Transacciones

INTRODUCCIÓN

En el presente resumen hablaremos de un tema de suma importancia como lo es la Gestión de Transacciones, la cual es una unidad de ejecución de un programa que accede y actualiza varios elementos de datos. También se explica la importancia que tiene el hecho de que las transacciones cuenten con las propiedades ACID.
Incluso hablaremos de los estados de las transacciones donde se presenta un diagrama, en fin, estos y mas temas son tratados en el presente documento.

GESTIÓN DE TRANSACCIONES.

Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Esta se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo SQL, COBOL, C, C++ o Java) y está delimitado por instrucciones de la forma inicio de transacción y fin transacción. La transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y el fin transacción.
Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones, llamadas en conjunto ACID:

Atomicidad. O todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas.
Consistencia. La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute concurrentemente) conserva la consistencia de la base de datos.
Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, cada transacción ignora al resto de las transacciones que se ejecuten en el sistema.
Durabilidad. Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.
El acceso a la base de datos se lleva a cabo mediante las dos operaciones siguientes:
Leer (x), que transfiere el dato X de la base de datos a una memoria intermedia local perteneciente a la transacción que ejecuta la operación leer.
Escribir (x), que transfiere el dato X desde la memoria intermedia local de la transacción que ejecuta la operación escribir a la base de datos.
En un sistema de base de datos real, la operación escribir no tiene por que producir necesariamente una actualización de los datos en disco; la operación escribir puede almacenarse temporalmente en memoria y llevarse a disco más tarde.

ESTADOS DE UNA TRANSACCIÓN.

En ausencia de fallos, todas las transacciones se completan con éxito. Sin embargo, una transacción puede que no siempre termine su ejecución. Una transacción de este tipo se denomina abortada. Si se pretende asegurar la propiedad de atomicidad, una transacción abortada no debe tener efecto sobre el estado de la base de datos. Así, cualquier cambio que haya hecho la transacción abortada sobre la base de datos debe deshacerse. Una vez que se han deshecho los cambios efectuados por la transacción abortada, se dice que la transacción ha retrocedido.
Parte de la responsabilidad del esquema de recuperaciones es gestionar las transacciones abortadas.
Una transacción que termina con éxito se dice que está comprometida. Una transacción comprometida que haya hecho modificaciones transforma la base de datos llevándola a un nuevo estado consistente, que permanece incluso si hay un fallo en el sistema.
Cuando una transacción se ha comprometido no se pueden deshacer sus efectos abortándola. La única forma de deshacer los cambios de una transacción comprometida es ejecutando una transacción compensadora.
Es necesario precisar qué se entiende por terminación con éxito de una transacción. Se establece por tanto un modelo simple abstracto de transacción. Una transacción debe estar en uno de los estados siguientes:
*Activa, el estado inicial; la transacción permanece en este estado durante su ejecución.
*Parcialmente comprometida, después de ejecutarse la última instrucción.
*Fallida, tras descubrir que no puede continuar la ejecución normal.
*Abortada, después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.
*Comprometida, tras completarse con éxito.

Una transacción comienza en el estado activa, cuando acaba su última instrucción pasa al estado de parcialmente comprometida. En este punto la transacción ha terminado su ejecución, pero es posible que aún tenga que ser abortada, puesto que los datos actuales pueden estar todavía en la memoria principal y puede producirse un fallo en el hardware antes de que se complete con éxito.
El sistema de base de datos escribe en disco la información suficiente para que, incluso al producirse un fallo, puedan reproducirse los cambios hechos por la transacción al reiniciar el sistema tras el fallo. Cuando se termina de escribir esta información la transacción pasa al estado comprometida.
Una transacción llega al estado fallida después de que el sistema determine que dicha transacción no puede continuar su ejecución normal. Una transacción de este tipo se debe retroceder. Después pasa al estado abortado. En este punto, el sistema tiene dos opciones:
*Reiniciar la transacción, pero sólo si la transacción se ha abortado a causa de algún error hardware o software que no lo haya provocado la lógica interna de la transacción. Una transacción reiniciada se considera una nueva transacción.
*Cancelar la transacción, Normalmente se hace esto si hay algún error interno lógico que sólo se puede corregir escribiendo de nuevo el programa de aplicación, o debido a una entrada incorrecta o debido a que no se han encontrado los datos deseados en la base de datos.
Cuando una escritura externa observable tiene lugar, no puede borrarse puesto que puede haber sido vista fuera del sistema de base de datos. Muchos sistemas permiten que tales escrituras tengan lugar sólo después de que la transacción llegue al estado comprometida. Una manera de implementar dicho esquema es hacer que el sistema de base de datos almacene temporalmente cualquier valor asociado con estas escrituras externas en memoria no volátil, y realice las escrituras actuales sólo si la transacción llega al estado comprometida. Si el sistema falla después de que la transacción llegue al estado comprometida, pero antes de que finalicen las escrituras externas, el sistema de base de datos puede llevar a cabo dichas escrituras externas (usando los datos de la memoria no volátil) cuando el sistema se reinicie.

IMPLEMENTACIÓN DE LA ATOMICIDAD Y LA DURABILIDAD

El componente de gestión de recuperaciones de un sistema de base de datos implementa el soporte para la atomicidad y la durabilidad. En primer lugar consideramos un esquema simple pero extremadamente ineficiente denominado copia en la sombra. Este esquema asume que la base de datos es simplemente un archivo en disco. En disco se mantiene un puntero llamado puntero_bd que apunta a la copia actual de la base de datos. Una transacción que quiera actualizar una base de datos crea primero una copia completa de dicha base de datos. Todos los cambios de hacen en la nueva copia de la base de datos dejando la copia original, la copia en la sombra, inalterada. Si en cualquier punto hay que abortar la transacción, la copia nueva simplemente se borra. La copia antigua de la base de datos no se ve afectada.
Si la transacción se completa, se compromete como sigue. En primer lugar se consulta al sistema operativo para asegurarse de que todas las páginas de la nueva copia de la base de datos se han escrito en disco, después de terminar esta orden se actualiza el puntero para que apunte a la nueva copia de la base de datos.
Si la transacción falla en algún momento antes de actualizar puntero_bd, el contenido de la base de datos anterior no se ve afectado. Se puede abortar la transacción simplemente borrando la nueva copia de la base de datos. Una vez que se ha comprometido la transacción, puntero_bd apunta a todas las modificaciones que ésta ha realizado en la base de datos. De este modo, o todas las modificaciones de la transacción se ven reflejadas o ninguna de ellas, independientemente del fallo de la transacción.
La implementación depende realmente de que escribir puntero_bd sea una operación atómica; es decir, o se escriben todos sus bytes o ninguno de ellos. Si se escribieran algunos de los bytes del puntero y otros no, el puntero no tendría sentido y al reiniciarse el sistema no se podrían encontrar ni la versión anterior ni la nueva de la base de datos. Afortunadamente los sistemas de disco proporcionan actualizaciones atómicas de bloques enteros, o al menos de un sector del disco.
De este modo, la implementación de la copia en la sombra del componente de gestión de recuperaciones asegura las propiedades de atomicidad y durabilidad de las transacciones.

EJECUCIONES CONCURRENTES

Los sistemas de procesamiento de transacciones permiten normalmente la ejecución de varias transacciones concurrentemente. Permitir esto provoca complicaciones en la consistencia de los mismos. Asegurar la consistencia a pesar de la ejecución concurrente de las transacciones requiere un trabajo extra; es mucho más sencillo exigir que las transacciones se ejecuten secuencialmente, es decir, una a una, comenzando cada una sólo después de que la anterior se haya completado. Sin embargo, existen dos buenas razones para permitir la concurrencia.
Productividad y utilización de recursos mejoradas. Una transacción consiste en varios pasos, Algunos implican operaciones de E/S; otros implican operaciones de UCP, La UCP y los discos pueden trabajar en paralelo en una computadora. Por tanto, las operaciones de E/S se pueden realizar en paralelo con el procesamiento de la UCP. Se pueden ejecutar varias transacciones en paralelo.
Todo esto incrementa la productividad del sistema, es decir, en el número de transacciones que puede ejecutar en un tiempo dado. Análogamente, la utilización del procesador y del disco aumenta también; en otras palabras, el procesador y el disco está menos tiempo desocupado o sin hacer ningún trabajo útil.
Tiempo de espera reducido. Debe haber una mezcla de transacciones que se ejecutan en el sistema, algunas cortas y otras largas. Si las transacciones se ejecutan secuencialmente, la transacción corta debe esperar a que la transacción larga anterior se complete, lo cual puede llevar a un retardo impredecible en la ejecución de la transacción. Si las transacciones operan en partes diferentes de la base de datos es mejor hacer que se ejecuten concurrentemente, compartiendo los ciclos de la UCP y los accesos a disco entre ambas. La ejecución concurrente reduce los retardos impredecibles en la ejecución de las transacciones. Además se reduce también el tiempo medio de respuesta: El tiempo medio desde que una transacción comienza hasta que se completa.
La razón para usar la ejecución concurrente en una base de datos es esencialmente la misma que para usar multiprogramación en un sistema operativo.
El sistema de base de datos debe controlar la interacción entre las transacciones concurrentes para evitar que se destruya la consistencia de la base de datos. Esto se lleva a cabo a través de una serie de mecanismos denominados esquemas de control de concurrencia.

SECUENCIALIDAD

El sistema de base de datos debe controlar la ejecución concurrente de las transacciones para asegurar que el estado de las transacciones para asegurar que el estado de la base sigue siendo consistente. Antes de examinar cómo debe realizar esta tarea, el sistema de base de datos hay que entender primero las planificaciones que aseguran la consistencia y las que no.
Puesto que ls transacciones son programas, es difícil calcular cuáles son las operaciones exactas que realiza una transacción y cómo interaccionan las operaciones de varias transacciones. Por este motivo no se van a interpretar los tipos de operaciones que puede realizar una transacción sobre un elemento de datos. En lugar de esto se consideran sólo dos operaciones: leer y escribir. Se asume así que entre una instrucción leer y otra escribir sobre un elemento de datos, una transacción puede realizar una secuencia arbitraria de operaciones con la copia que reside en la memoria intermedia local de dicha transacción. Existen dos tipos de secuencialidad, en cuanto a conflictos y en cuanto a vistas.

RECUPERABILIDAD

Si la transacción Ti falla, por la razón que sea, es necesario deshacer el efecto de dicha transacción para asegurar la propiedad de atomicidad de la misma. En un sistema que permita la concurrencia es necesario asegurar también que toda transacción Ti que dependa de Ti se aborta también. Para alcanzar esta garantía, es necesario poner restricciones al tipo de planificaciones permitidas en el sistema.
Existen diferentes tipos de planificaciones, como lo son las recuperables, que son las que para todo par de transacciones lee elementos de datos que ha escrito previamente Ti, la operación comprometer Ti aparece antes que la de T; planificaciones sin cascada, incluso si una planificación es recuperable, hay que retroceder varias transacciones para recuperar correctamente el estado previo a un fallo en una transacción T1. (Es un fenómeno en el cual un fallo en una única transacción provoca una serie de retrocesos de la transacción provoca una serie de retrocesos de la transacción.

IMPLEMENTACIÓN DEL AISLAMIENTO

Existen varios esquemas de control de concurrencia que se pueden utilizar para asegurar que, incluso si se ejecutan concurrentemente muchas transacciones, sólo se generen planificaciones aceptables sin tener en cuenta la forma en que el sistema operativo comparte en el tiempo los recursos (tales como el tiempo de UCP) entre las transacciones.
El objetivo de los esquemas de control de concurrencia es proporcionar un elevado grado de concurrencia, al mismo tiempo que asegurar que todas las planificaciones que se generan son secuenciales en cuanto a conflictos o en un cuanto a vistas y son sin cascada.

DEFINICIÓN DE TRANSACCIONES EN SQL

Un lenguaje de manipulación de datos debe incluir una constructora para especificar el conjunto de acciones que constituyen una transacción.
En la norma SQL se especifica el comienzo de una transacción explícitamente. Las transacciones se terminan con una de las instrucciones SQL siguientes:
Commit work compromete la transacción actual y comienza una nueva.
Rollback work provoca que la transacción actual aborte.
La palabra clave work es opcional en ambas instrucciones. Si el programa termina sin ninguna de estas órdenes, los cambios o bien se comprometen o bien se retroceden; en la norma no se especifica cuál de las dos acciones tiene lugar, y depende de la implementación.
La norma específica también que el sistema debe garantizar tanto la secuencialidad como la ausencia de retroceso en cascada. La definición de secuencialidad que usa la norma es que la planificación debe tener el mismo efecto que tendría una planificación secuencial. De este modo son aceptables tanto la secuencialidad en cuanto a conflictos como la secuencialidad en cuanto a vistas. La norma SQL-92 permite también que una transacción especifique que puede ejecutarse de forma que se convierta en no secuenciable con respecto a otras transacciones.

COMPROBACIÓN DE LA SECUENCIALIDAD

Cuando se diseñan esquemas de control de concurrencia hay que demostrar que las planificaciones que genera el esquema son secuenciales. Para hacer esto se debe entender primero la forma de determinar si, dada una planificación concreta P es secuencial.
El orden de secuencialidad se puede obtener a través de la ordenación topológica, la cual determina un orden lineal, que consiste en el orden parcial del grafo de precedencia. En general se pueden obtener muchos órdenes lineales posibles a través de la ordenación topológica.
Para poder probar la secuencialidad en cuanto a conflictos hay que construir el grafo de precedencia e invocar a un algoritmo de detección de ciclos. Los algoritmos de detección de ciclos, tales como los que se basan en la búsqueda primero en profundidad, requieren del orden de n operaciones, De este modo se tiene un esquema práctico para determinar la secuencialidad en cuanto a conflictos.
La comprobación de la secuencialidad en cuanto a vistas es más complicada. De hecho, se ha demostrado que el problema de determinar la secuencialidad en cuanto a vistas es NP-completo. Por tanto, seguramente no exista ningún algoritmo eficiente para comprobar la secuencialidad en cuanto a vistas.

CONCLUSIÓN

Por último podemos decir que realmente es importante conocer la forma en que podemos asegurar la integridad de los datos, también conocer los diferentes estados en que puede encontrarse una transacción, y la transición que estas llevan para pasar de un estado a otro, como el componente de gestión implementa el soporte para la atomicidad y la durabilidad y la comprobación de secuencialidad, etc.

BIBLIOGRAFÍA

Fuente: Silverschatz Capitulo 15.

Lectura 10 - Integridad Y Seguridad

INTRODUCCIÓN

En el presente resumen se muestra como las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a las bases de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos, Esto es, que las restricciones de integridad protegen a la base de datos contra los daños accidentales.

También se muestra que además de la protección contra la introducción accidental de inconsistencia, puede ser necesario proteger los datos almacenados en la base de datos frente a accesos no autorizados y destrucción o alteración malintencionada.


INTEGRIDAD Y SEGURIDAD

Restricciones de los dominios.

Anteriormente hemos visto que hay que asociar a cada atributo un dominio de valores posible. Las restricciones de los dominios son la forma más simple de restricción de integridad, ya que el sistema las verifica fácilmente siempre que se introduce en la base de datos un nuevo elemento de datos.

La definición adecuada de las restricciones de los dominios aparte de permitir la verificación de los datos introducidos a la base de datos, permite también examinar las consultas para asegurarse de que tengan sentido las comparaciones que hagan. El principio subyacente a los dominios de los tributos es parecido al de los tipos de las variables en los lenguajes de programación.

En la cláusula CHECK de SQL, por ejemplo, se permite al diseñador del esquema especificar un predicado que debe satisfacer cualquier valor asignado a una variable cuyo tipo sea el dominio.

Por ejemplo, para asegurar que un dominio de sueldo por horas solo permita valores mayores que u n valor especificado debe usarse el siguiente código:

Create domain sueldo-por-hora numeric (5,2)
Constraint comprobación-valor-sueldo
Check (value ≥ 4,00)

Las condiciones CHECK complejas pueden ser útiles cuando se desea asegurar la integridad de los datos, pero se deben usar con cuidado, dada que pueden ser costosas de comprobar.

Integridad referencial

Se conoce así al aseguramiento de que un valor que aparece en una relación para un conjunto de atributos determinado aparezca también en otra relación para un cierto conjunto de atributos.

Las restricciones de integridad referencial aparecen con frecuencia. Si se obtiene el esquema de la base de datos relacional creando tablas a partir de los diagramas entidad relación, cada relación que proceda de un conjunto de relaciones tendrá restricciones de integridad referencial (Llaves externas).
En SQL, las claves primarias pueden especificarse como parte de la instrucción create table, usando la cláusula foreign key. De manera predeterminada, una clave externa referencia los atributos que forman la clave primaria de la tabla referenciada. Por ejemplo:

Create table cliente
(nombre-cliente char(20),
Calle-cliente char(30),
Ciudad-cliente char(30),
Primary key (nombre-cliente))

Otra fuente de restricciones de integridad referencial son los conjuntos de entidades débiles. La modificación de la base de datos puede ocasionar violaciones de la integridad referencial también.

Cabe mencionar que la cláusula antes mencionada Foreign key puede especificar si una acción de borrado o de actualización de la relación a la que hace referencia viola la restricción, en lugar de rechazar la acción, hay que adoptar medidas para modificar la tupla de la relación que hace la referencia con objeto de restaurar la restricción.

Asertos

Un aserto es un predicado que expresa una condición que se desea que la base de datos satisfaga siempre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos que se pueden verificar con facilidad y se aplican a una gran variedad de aflicciones de bases de datos.

En SQL los asertos adoptan la siguiente forma:

Create assertion check
Cuando se crea un aserto el sistema comprueba su validez. Si el aserto es valido, solo se permiten las modificaciones posteriores de la base de datos que no hagan que se viole el aserto. Asertos complejos deben usarse con cautela ya que pueden introducir una sobrecarga importante, lo que lleva a soslayar el soporte para los asertos generales.

Disparadores

Un disparador es una orden que el sistema ejecuta de manera automática como efecto secundario de la modificación de la base de datos. Para llevarlo a cabo deben seguirse los siguientes pasos:

1.- Especificar las condiciones en las que se va a ejecutar el disparador (mediante un evento y una condición).
2.- Especificar las acciones que realizara cuando se ejecute el disparador.

Las bases de datos almacenan a estos disparadores como datos normales, por lo que son persistentes y accesibles para todas las operaciones de la base de datos. Al almacenar un disparador es el SMBD el responsable de ejecutarlo cada vez que ocurra el evento especificado y se satisfaga la condición correspondiente.

Los disparadores son mecanismos útiles para alertar a los usuarios o para realizar de manera automática ciertas tareas cuando se cumplen determinadas condiciones.

En SQL se usan ampliamente los disparadores, por ejemplo, supóngase que el valor del campo de numero telefónico de una tupla insertada esta vacío, que indica la ausencia de un numero de teléfono. Se puede definir un disparador que reemplace el valor por el valor Null. Se usa la instrucción Set para realizar estas modificaciones.

Create trigger poner-nulo before update on r
Referencing new row as nfila
For each row
When nfila.numero-teléfono=’’
Set nfila.numero-teléfono=null

Muchos sistemas de base de datos proporcionan implementaciones no estándar de disparadores, o implementan solo algunas de las características de los disparadores. . Por ejemplo, muchos de los sistemas de bases de datos no incrementan la cláusula befote, y usan la palabra clave on en lugar de alter. Puede que no implementen la cláusula referencing. En su lugar, pueden especificar tablas de transición usando las palabras claves insert o deleted.

Seguridad y autorización.

Los datos guardados en la base de datos deben estar protegidos contra los accesos no autorizados, de la destrucción o alteración malintencionadas además de la introducción accidental de inconsistencias que evitan las restricciones de integridad.

Violaciones de la seguridad.

Algunas formas de acceso mal intencionado son:

 Lectura no autorizada de los datos (Robo de información).
 Modificación no autorizada de los datos.
 Destrucción no autorizada de los datos.

Para proteger de forma adecuada una base de datos hay que adoptar medidas de seguridad en varios niveles:

Sistema de base de datos. Algunos usuarios están autorizados para el acceso a una parte limitada de información, por lo tanto es responsabilidad del sistema de base de datos asegurarse de que no se violen estas restricciones de autorización.
Sistema operativo. La debilidad de la seguridad del sistema operativo puede servir como medio para el acceso no autorizado a la base de datos.
Red. La seguridad en el nivel del software de la red es tan importante como la seguridad física, tanto en Internet como en las redes privadas de la empresa.
Físico. Los sitios que contienen los sistemas informáticos deben estar protegidos físicamente contra la entrada de intrusos.
Humano. Los usuarios deben ser autorizados cuidadosamente para reducir la posibilidad de que alguno de ellos dé acceso a intrusos a cambio de sobornos u otros favores.
Autorizaciones.

Los usuarios pueden tener varios tipos de autorización para diferentes partes de la base de datos, por ejemplo:

De lectura: Permite la lectura de datos pero no su modificación.
De inserción: Permite la inserción de datos nuevos, pero no la modificación de los ya existentes.
De actualización: Permite la modificación de los datos pero no su borrado.
De borrado: Permite el borrado de los datos.

Además de estas formas de autorización para el acceso a los datos, los usuarios pueden recibir autorización para modificar el esquema de la base de datos:

De índices: Permite la creación y borrado de índices.
De recursos: Permite la creación de nuevas relaciones.
De alteración: Permite el añadido o el borrado de atributos de las relaciones.
De eliminación: Permite el borrado de relaciones.

Es importante destacar que para permitir al administrador de la base de datos que regule el uso de los recursos del sistema es necesario tratar la creación de índices como un privilegio.

La forma superior de autoridad es la concedida al administrador de la base de datos, pues es el precisamente el que puede autorizar usuarios nuevos, reestructurar la base de datos, etc. Esta forma de autoridad es análoga a la proporcionada al superusuario u operador del sistema operativo.

Autorizaciones y vistas.

Como ya hemos visto, las vistas son un medio de proporcionar a un usuario un modelo personalizado de la base de datos. Estas pueden ocultar los datos que no necesitan ver los usuarios. La capacidad de las vistas para ocultar datos mejora la seguridad. Se puede utilizar una combinación de seguridad en el nivel relacional y en el nivel de las vistas para limitar el acceso de un usuario precisamente a los datos que necesita.

Por ejemplo considérese que un empleado que necesita saber los nombres de todos los clientes que tienen un prestamo en cada sucursal. Este empleado no esta autorizado para ver la información concerniente a los prestamo concretos que tiene cada cliente. Por lo tanto se le debe negar el acceso directo a la relacioon, prestamo. Pero si tendra acceso a la informcion necesaria, esto es a la vista cliente-prestamo que consiste solo en los nombres de los clientes y las sucursales en los que tienen un prestamo. Esta vista se define de la siguiente manera en SQL:

Create view cliente-prestamo as
(select nombre-sucursal, nombre-cliente
from prestatario, prestamo
where prestatario.numero-prestamo
= prestamo.numero-prestamo)

Concesión de privilegios.

El usuario al que se le ha concedido alguna forma de autorización, puede ser autorizado a transmitir esa autorización a otros usuarios, pero hay que tener cuidado con el modo en que se puede transmitir esa autoridad para asegurar que esta puede ser retirada en el futuro.

El lenguaje SQL tiene los privilegios delete, insert, select y update. Además incluye órdenes para conceder y retirar privilegios. La instrucción grant se utiliza para conferir autorizaciones. La forma básica de muestra a continuación:
Grant on to

La lista de privilegios permite la concesión de varios privilegios con una sola orden.

Por ejemplo en la siguiente instrucción grant se concede a los usuarios U1, U2 y U3 la autorización update sobre el atributo importe de la relación préstamo:

Grant update (importe) on préstamo to U1,U2,U3

Papeles

En la base de datos se crean papeles, estos facilitan la asignación de un conjunto de privilegios a un usuario de acuerdo al papel que el usuario desempeña en la organización.

En SQL se pueden crar de la siguiente forma:

Create role cajero

Se pueden conceder privilegios a los papeles al igual que a los usuarios, como se muestra:
Grant select on cuenta
to cajero

Los papeles se pueden asignar a los usuarios, así como a otros papeles, como muestran estas instrucciones.

Grant cajero to Juan
Create role gestor
Grant cajero to gestor
Grant gestor to maria

Los privilegios de un usuario o papel consisten en:

 Todos los privilegios concedidos directamente al usuario o papel.
 Todos los privilegios concedidos a papeles que se hayan concedido al usuario o papel.

Un usuario o papel al que se le concede un privilegio no está autorizado de manera predeterminada a concedérselo a otros usuarios o papeles. Si se desea conceder un privilegio a un usuario y permitirle que lo transmita a otros usuarios hay que añadir la cláusula with grant option a la orden grant correspondiente. Por ejemplo, si se desea conceder a U1 el privilegio select sobre sucursal y que pueda transmitirlo a otros, hay que escribir:

grant select on sucursal to U1 with grant option

Para retirar una autorización se utiliza la instrucción revoke. Adopta una forma casi idéntica a la de grant:

revoke on
from [restrict cascade]

Cifrado y autenticación

Puede que las diferentes provisiones para la autorización que haga un sistema de bases de datos no proporcionen suficiente protección para los datos extremadamente delicados. En tales casos se pueden cifrar los datos. Los datos cifrados no se pueden leer a menos que el lector sepa la manera de descifrarlos (descodificarlos).
El cifrado también forma la base de los buenos esquemas para la autenticación de usuarios en una base de datos.

Técnicas de cifrado

Puede que las técnicas de cifrado sencillas no proporcionen la seguridad adecuada, dado que puede ser sencillo para un usuario no autorizado romper el código. Como ejemplo de una técnica de cifrado débil considérese la sustitución de cada carácter por el siguiente en el alfabeto. Así, Navacerrada se transforma en: Ñbwbdfssbeb.

Una buena técnica de cifrado tiene las propiedades siguientes:

 Es relativamente sencillo para los usuarios autorizados cifrar y descifrar los datos.
 El esquema de cifrado no depende de lo poco conocido que sea el algoritmo, sino más bien de un parámetro del algoritmo denominado clave de cifrado.
 Es extremadamente difícil para un intruso determinar la clave de cifrado.

Un enfoque, la norma de cifrado de datos (DES) realiza una sustitución de caracteres y una reordenación de los mismos en función de una clave de cifrado. Para que este esquema funcione los usuarios autorizados deben proveerse de la clave de cifrado mediante un mecanismo seguro.

El cifrado de clave pública es un esquema alternativo que evita parte de los problemas que se afrontan con DES. Se basa en dos claves; una clave pública y una clave privada.

Autenticación

La autenticación se refiere a la tarea de verificar la identidad de una persona o software que se conecte a una base de datos. La forma más simple consiste en una contraseña secreta que se debe presentar cuando se abra una conexión a la base de datos.

La autenticación basada en palabras clave se usa ampliamente por los sistemas operativos y bases de datos. Sin embargo, el uso de contraseñas tiene algunos inconvenientes, especialmente en una red.

Un esquema más seguro es el sistema de desafíorespuesta. El sistema de bases de datos envía una cadena de desafío al usuario. El usuario cifra la cadena de desafío usando una contraseña secreta como clave de cifrado y devuelve el resultado. El sistema de bases de datos puede verificar la autenticidad del usuario descifrando la cadena con la mima contraseña secreta, y comparando el resultado con la cadena de desafío original. Este esquema asegura que las contraseñas no circulen por la red.

Otra aplicación interesante de la criptografía está en las firmas digitales para verificar la autenticidad de los datos; las firmas digitales desempeñan el papel electrónico
de las firmas físicas en los documentos. La clave privada se usa para firmar los datos y los datos firmados se pueden hacer públicos. Cualquiera podría verificarlos con la clave pública, pero nadie podría haber generado los datos codificados sin tener la clave privada. Por tanto, se puede comprobar que los datos fueron creados realmente por la persona que afirma haberlos creado.

Además, las firmas digitales también sirven para asegurar el rechazo. Es decir, en el caso de que una persona que creó los datos afirmase más tarde que no lo hizo (el equivalente electrónico de afirmar que no se ha firmado un talón) se puede probar que esa persona ha creado los datos (a menos que haya cedido su clave privada a otros).

Conclusión

A forma de conclusión se puede decir que la información del autor es clara y concisa en cuanto a mostrarnos la importancia de la seguridad e integridad en los datos almacenados en las bases de datos, al mismo tiempo que nos muestra la forma de aplicar esta información a través de ejemplos.

Bibliografía

Fundamentos de Bases de Datos. Cuarta Edición
Silberschatz; Korth; Sudarshan.
McGraw Hill. 2002
Páginas 141-159.