Recuperación en Base de Datos

Vista previa del material en texto

1. RECUPERACIÓN
1.1 CONCEPTO
El objetivo del concepto de recuperación es el de proteger la base de datos contra fallas lógicas y físicas que destruyan los datos en todo o en parte independientemente de la naturaleza de las fallas estas pueden afectar los aspectos de almacenamiento de la base de datos como son: 
	
	fallas que provocan la pérdida de memoria volátil 
	
	fallas que provocan la pérdida del contenido de memoria secundaria.
En un sistema de base de datos recuperación significa, restaurar la base de datos, a un estado que se sabe que es correcto, después de una falla que provoca que se considere que el estado actual es incorrecto. 
El principio de recuperación esta fundamentado en la redundancia. 
Podemos tener la seguridad de que la base de datos es recuperable, si aseguramos que cualquier parte de la información que contiene, puede ser reconstruida, a partir de otra información que se encuentra almacenada redundantemente en algún lugar del sistema. 
Aunque los procesos de recuperación se ha desarrollado en el contexto de base de datos relacionales, no es una condición indispensable que las base de datos sean relacionales.
1.2 TRANSACCIONES
Una transacción es una unidad de la ejecución de un programa accede y posiblemente actualiza varios elementos de datos. Una transacción es normalmente el resultado de 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 ó Pascal) y esta delimitado por declaraciones ( o llamadas a función) de la forma inicio transacción y fin transacción. 
La transacción consiste en todas las operaciones que se ejecutan entre el inicio y el final de la transacción. 
Las características de una transacción son:
Atomicidad , o todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas. 
Consistencia , a 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 , ya que una transacción no muestra los cambios que produce hasta que finaliza 
Persistencia , ya que una vez finaliza la transacción con éxito, sus efectos perduran en la BD. 
Seriabilidad , en el sentido de que el efecto de ejecutar transacciones concurrentemente debe ser el mismo que se produciría al ejecutarlas por separado en un orden secuencial según van entrando en el sistema. 
Este tipo de técnicas considera que las transacciones tienen 3 fases: 
Lectura: Las transacciones realizan operaciones sobre copias privadas de los objetos 
( accesibles solo por la transacción) 
Validación: En la que se comprueba si el conjunto de objetos modificados por una transacción se solapa con el conjunto de objetos modificados por alguna otra que haya hecho la validación durante la fase de lectura de dicha transacción. 
Grabación: En el caso de no detectar interferencias se graban las modificaciones, convirtiendo las versiones privadas de los objetos en versiones actuales.
1.3 FALLAS DE TRANSACCIÓN
En un extremo del espectro habrá un nodo que jamás falla, a veces llamado un nodo perfecto. En el otro extremo aparece un nodo que fallas de una manera del todo desconocida. Un nodo como esta pudiera comunicar basura a través de la red, o bien en razón de su falla, pudiera enviar acciones inapropiadas, pero con formato valido por la red. Nodos como estos se conocen como nodos desquiciados. 
Otro tipo de falla corresponde a nodos que se convierten en malévolos, lo cual significa que el nodo tiene el propósito expreso de llevar a cabo una actividad no autorizada, o de causar daños de forma intencional. Es incluso posible considerar fallas donde los nodos conspiran unos con otros para hacer caer el sistema distribuido. A veces se conoce como fallas bizantinas 
Entre los extremos de los nodos perfectos y los nodos desquiciados están los nodos “sensatos”. Un nodo sensato es un nodo que puede fallar, pero solo en una forma definida y conocida. El ejemplo más sencillo de un nodo sensato es uno que , ó es perfecto , ó deja de responder por completo. 
1.4 FALLAS DEL SISTEMA
	
	Este tipo de fallas se conocen como caídas suaves 
	
	Afectan a todas las transacciones en progreso, pero no dañan físicamente la base de datos. 
	
	Un problema inherente a las fallas de sistema, es la perdida de toda la información que se encuentra en memoria principal, en los buffers de la base de datos. 
	
	Por lo anterior puede desconocerse el estado real en que se encuentra cada una de las transacciones en progreso. Dichas transacciones no se complementaran, tiene que deshacerse al restablecer el sistema. 
	
	También se hace necesario rehacer, al tiempo de restablece el sistema. Aquellas transacciones que ya se habían completado exitosamente en el momento en que ocurrió la caída. 
1.5 FALLAS EN EL MEDIO 
	
	Ocurren por ejemplo, cuando se dañan las cabezas del disco, o falla el manejador del disco 
	
	Causan daños ala base de datos o a alguna porción de ella. 
	
	Afectan a aquellas transacciones que están usando la porción dañada.
	
	También se denominan caídas duras. 
	
	Este tipo de fallas se restaura, después de reparada la falla de hardware, copiando el respaldo mas actual de la base de datos y rehaciendo las transacciones ocurridas a partir de la construcción del respaldo. 
2. INTEGRIDAD
2.1 DEFINICIÓN
Integridad: conservar la seguridad en un sistema que se permite a múltiples usuarios el acceso al sistema y compartir la base de datos. 
Integridad: tiene como función proteger la base de datos contra operaciones que introduzcan inconsistencias en los datos. Se habla de integridad en el sentido de corrección, validez o precisión de los datos. 
2.2 REGLAS DE INTEGRIDAD
Los conceptos básicos de integridad en el modelo relacional son el de llave primaria, llave foránea, valores nulos y un par de reglas de integridad. 
Una llave primaria es uno o un conjunto de atributos que permiten identificar a las n-adas de manera única en cualquier momento. 
Una llave foránea de una relación es un atributo que hace referencia a una llave primaria de otra relación; esto da pie a que una relación puede tener varias llaves foráneas. 
Un valor nulo es un valor que esta fuera de la definición de cualquier dominio el cual permite dejar el valor del atributo “ latente”, su uso es frecuente en las siguientes situaciones: 
i) cuando se crea una n-ada y no se conocen todos los valores de cada uno de los atributos 
ii) cuando se agrega un atributo a una relación 
iii) Para no tomarse en cuanta al hacer cálculos numéricos. 
Las dos reglas de integridad tiene que ver precisamente con los conceptos antes mencionados y son:
Integridad de relaciones. 
Ningún atributo que forme parte de una llave primaria puede aceptar valores nulos. 
Integridad referencial
Al tener una relación 9#9 con llave primaria 10#10 de dominio 11#11 y otra relación 1#1 con atributo 10#10 que no es llave primaria de 1#1, entonces cualquier valor en el atributo 10#10 en 1#1 debe ser: 
i) nulo, o 
ii) Un valor que este en el atributo 10#10 de la llave primaria de una n-ada en la relación 9#9
2.3 REGLAS DE INTEGRIDAD DE DOMINIO
Un dominio de valores posibles puede estar asociado con cada atributo. Los limites de dominio son la forma mas elemental de restricciones de integridad. Son fáciles de probar por el sistema siempre que se introduce un nuevo dato en la base de datos. 
Tipos de dominios 
Es posible que varios atributos tengan el mismo dominio. Podemos ver que una definición adecuada de restricciones de dominio no solo nos permite probar consultas para asegurar que la comparación que se hace tiene sentido. 
El principio que hay detrás de los dominios de atributo es similar al que hay detrás de la asignación de tipos a variables en los lenguajes de programación. Los lenguajes de programación fuertemente tipiados permiten que el compilador el programa con mayor detalle. 
2.4 REGLAS DE INTEGRIDAD DE RELACIÓN 
La segunda regla de integridadse aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deber ser completamente nulos. 
La regla de integridad referencial se marca en términos de estados de base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal. 
Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas: 
	
	Reglas de los nulos: ¿tiene sentido que la clave ajena acepte nulos? 
	
	Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena? 
Restringir: no se permite borrar la tupla referenciada. 
Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas la referencia mediante la clave ajena. 
Anular: se borra la tupla referenciada y las tuplas que la reverenciaba ponen a nulo la clave ajena (solo si acepta nulos). 
	
	Reglas de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena? 
Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada. 
Propagar: se modifica el valor de la clave primaria de la tupla referenciaba y se propaga la modificación a las tuplas que la referencia mediante clave ajena. 
Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena ( solo si acepta nulos).
2.5 MECANISMOS DE VISTAS PARA IMPLANTACIÓN DE INTEGRIDAD
Vistas 
Cualquier relación que no es parte del modelo conceptual, pero se hace visible al usuario como una <<relación virtual>>, se llama vista. Es posible tener un gran número de vistas sobre cualquier conjunto de relaciones reales dado. 
Puesto que las relaciones reales en el modelo conceptual puedes modificarse, generalmente no es posible almacenar una relación correspondiente a una vista. En cambio, una vista debe volverse a calcular para cada consulta que se refiere a ella. 
Definición de vista 
Una vista se define usando la sentencia create view. Para definir una vista debemos darle un nombre y presentar la consulta que calcula la vista. La forma de la sentencia create view es: 
Create view v as < expresión de consulta > 
Donde <expresión de consulta>es cualquier expresión legal de consulta en álgebra relacional. El nombre de la vista se representa por v.
Actualización por medio de vistas 
Aunque las vistas son una herramienta útil para las consultas, presentan problemas importantes si las actualizaciones, inserciones o eliminaciones se expresan usando vistas. La dificultad es que una modificación de la base de datos expresada en términos de vistas debe traducirse en una modificación de las relaciones reales en el modelo conceptual de la base de datos.
3. CONCURRENCIA
 
 3.1 DEFINICIÓN
 
 El término concurrencia se refiere al hecho de los SMBDs, normalmente permiten que muchas transacciones tengan acceso a los mismos datos, al mismo tiempo . 
 En dichos sistemas se requieren mecanismos de control de la concurrencia para asegurar que las transacciones no se interfieran entre si. 
 En sistemas multiusuario, es necesario un mecanismo para controlar la concurrencia. Se pueden producir inconsistencias importantes derivadas del acceso concurrente, como por ejemplo, el problema de la operación perdida. 
 En un sistema de biblioteca, existe un campo que almacena el número de copias disponibles para préstamo. Este campo debe incrementarse en uno cada vez que se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un ejemplar. 
 Si existen varias bibliotecarias, una de ellas inicia la transacción t1, leyendo la variable número ejemplares (n), cuyo contenido se guarda en la variable n1. Tiempo después, otra bibliotecaria podría leer la misma variable incrementándola en una unidad, transacción t2. Después, la transacción t1 añade una unidad a esa variable y la actualiza, el resultado es erróneo, ya que la variable N debería haber aumentado en 2 unidades, y solo ha aumentado en una. La transacción t2 se ha perdido. 
 
3.2 PROBLEMAS QUE SE PRESENTAN (ACTUALIZACIÓN , PÉRDIDA, ETC )
Los tres problemas de principales de la concurrencia son: 
 Actualización perdida 
 
 Dependencia no comandada 
 
 Análisis inconsistente 
 
Actualización perdida : Este problema puede presentarse si dos transacciones concurrentes actualizan una misma tupla. Y la segunda que se realiza al final, no toma en cuenta el efecto de la primera. 
Dependencia no comandada : Ocurre si se permite que una transacción lea o modifique una tupla que ha sido modificada por otra transacción, sin que se haya comandado el registro en firme de esta modificación. Una modificación si ocurriera una operación de cancelación podrían generarse inconsistencias. 
Análisis inconsistente: Ocurre cuando una transacción hace un análisis contable o estadístico, sobre una tabla que esta siendo actualizada por otra transacción. 
 
Problemas de la concurrencia 
 En los sistemas de tiempo compartido (aquellos con varios usuarios, procesos, tareas, trabajos que reparten el uso de CPU entre estos) se presentan muchos problemas debido a que los procesos compiten por los recursos del sistema. Los programas concurrentes a diferencia de los programas secuenciales tienen una serie de problemas muy particulares derivados de las características de la concurrencia: 
Violación de la exclusión mutua: En ocasiones ciertas acciones que se realizan en un programa concurrente no proporcionan los resultados deseados. Esto se debe a que existe una parte del programa donde se realizan dichas acciones que constituye una región critica, es decir, es una parte del programa en la que se debe garantizar que si un proceso accede a la misma, ningún otro podrá acceder. Se necesita pues garantizar la exclusión mutua. 
 
Bloqueo mutuo o deadlock: Un proceso se encuentra en estado de deadlock si esta esperando por un suceso que no ocurrirá nunca. Se puede producir en la comunicación de procesos y mas frecuentemente en la gestión de recursos. Existen cuatro condiciones necesarias para que se pueda producir deadlock: 
 
 Los procesos necesitan acceso exclusivo a los recursos
 
 Los procesos necesitan mantener ciertos recursos exclusivos mientras esperan por otros.
 
 Los recursos no se pueden obtener de los procesos que están a la espera.
 
 Existe una cadena circular de procesos en la cual cada proceso posee uno o mas de los recursos que necesita el siguiente proceso en la cadena. 
 
 
Retraso indefinido o starvation: Un proceso se encuentra en starvation si es retrasado indefinidamente esperando un suceso que no puede ocurrir. Esta situación se puede producir si la gestión de recursos emplea un algoritmo en el que no se tenga en cuenta el tiempo de espera del proceso. 
 
Injusticia o unfairness: Se pueden dar situaciones en las que exista cierta injusticia en relación a la evolución de un proceso. Se deben evitar situaciones de tal forma que se garantice que un proceso evoluciona y satisface sus necesidades sucesivas en algún momento. 
 
Espera ocupada: En ocasiones cuando un proceso se encuentra a la espera por un suceso, una forma de comprobar si el suceso se ha producido es verificando continuamente si el mismo se ha realizado ya. Esta solución de espera es muy poco efectiva, porque desperdicia tiempo de procesamiento, y se debe evitar. La solución ideal es suspender el proceso y continuar cuando se haya cumplido la condiciónde espera. 
 
Condiciones de Carrera o Competencia: La condición de carrera (race condition) ocurre cuando dos o mas procesos accesan un recurso compartido sin control, de manera que el resultado combinado de este acceso depende del orden de llegada. 
 
Postergación o Aplazamiento Indefinido (a): Consiste en el hecho de que uno o varios procesos nunca reciban el suficiente tiempo de ejecución para terminar a su tarea. Por ejemplo, que un proceso ocupa un recurso y lo marque como ocupado y que termine sin marcarlo como desocupado. Si algún otro proceso pide ese recurso, lo vera ocupado y esperara indefinidamente a que se desocupe. 
 
Condición de Espera Circular: Esto ocurre cuando dos o mas procesos forman una cadena de espera que los involucra a todos. 
 
Condición de No apropiación: Esta condición no resulta precisamente de la concurrencia, pero juega un papel muy importante en este ambiente. Esta condición especifica que si un proceso tiene asignado un recurso, dicho recurso no puede arrebatársele por ningún motivo, y estará disponible hasta que el proceso lo suelte por su voluntad. 
 
 
3.3 SERIABILIDAD
Teoría de la Seriabilidad 
 Una calendarización (schedule), también llamado una historia, se define sobre un conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecución de las operaciones de las transacciones. La calendarización puede ser especificada como un orden parcial sobre T. 
Ejemplo 1. Considere las siguientes tres transacciones: 
T1: Read( x ) 
 T2: Write( x ) 
 T3: Read( x ) 
 
Write( x ) 
 Write( y ) 
 Read( y ) 
 
Commit 
 Read( z ) 
 Read( z ) 
 
 
 Commit 
 Commit 
 
 Una calendarización de las acciones de las tres transacciones anteriores puede ser: 
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } 
¨ Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo dato de la base de datos x se dice que están en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-write. 
 Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a transacciones diferentes. En el último caso, se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica que su orden de ejecución es importante. El orden de dos operaciones de lectura es insignificante. 
 Una calendarización completa define el orden de ejecución de todas las operaciones en su dominio. Formalmente, una calendarización completa STc definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { S T, <T } en donde 
S T = U i S i , para todos los i = 1, 2, ..., n 
<T Ê i <i , para todos los i = 1, 2, ..., n 
Para cualesquiera dos operaciones en conflicto Oij y Okl Î S T, ó Oij <T Okl ó Okl <T Oij 
 La primera condición establece simplemente que el dominio de la calendarización es la unión de los dominios de las transacciones individuales. La segunda condición define la relación de ordenamiento como un súper conjunto de la relación de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transacción. La condición final define el orden de ejecución entre dos operaciones en conflicto. 
Ejemplo 2. Considere las tres transacciones del ejemplo 1, una posible calendarización completa está dada por la siguiente gráfica dirigida acíclica (DAG). 
 Una calendarización se define como un prefijo de una calendarización completa. Un prefijo de un orden parcial se define como sigue. Dado un orden parcial P = { S , < }, P’ = { S ’, <’ }, es un prefijo de P si 
S ’ Ì S i 
" ei Î S ’, e1 <’ e2, si y solamente si, e1 < e2, y 
" ei Î S ’, si $ ej Î S y ej < ei, entonces, ej Î S ’ 
 Las primeras dos condiciones definen a P’ como una restricción de P en el dominio S ’, en donde las relaciones de ordenamiento en P se mantienen por P’. La última condición indica que para cualquier elemento de S ’, todos sus predecesores en S deben ser incluidos también en S ’. 
Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del Ejemplo 2. 
 Si en una calendarización S, las operaciones de varias transacciones no están entrelazadas, esto es, si las operaciones de una transacción ocurren de manera consecutiva, entonces se dice que la calendarización es serial. Si cada transacción es consistente (obedece las reglas de integridad), entonces la base de datos se garantiza ser consistente al final de la calendarización serial. La historia asociada a este tipo de calendarización se le conoce como serial. 
Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1. 
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } 
 Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia resultante sobre la base de datos es equivalente a alguna historia serial. Basada en la relación de precedencia introducida por el orden parcial, es posible discutir la equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base de datos. 
 Dos calendarizaciones, S1 y S2, definidas sobre e l mismo conjunto de transacciones T, se dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i ¹ k), cada vez que Oij <1 Okl, entonces, Oij <2 Okl. A esta relación se le conoce como equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones en término del orden de ejecución relativo de las operaciones en conflicto en ellas. 
 Una calendarización S se dice que es serializable, si y solamente si, es equivalente por conflictos a una calendarización serial. 
Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto: 
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } 
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } 
 
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H2 es serializable: 
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } 
H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 } 
 
 La función primaria de un controlador de concurrencia es generar una calendarización serializable para la ejecución de todas las transacciones. El problema es, entonces, desarrollar algoritmos que garanticen que únicamente se generan calendarizaciones serializables. 
 
Seriabilidad en SMBD distribuidos 
 En bases de datos distribuidas es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la calendarización de la ejecución de transacciones en un nodo conocido como calendarización local y la calendarización global de las transacciones en el sistema. Para que las transacciones globales sean serializables se deben satisfacer las siguientes condiciones: 
 cada historia local debe ser serializable, y 
 
 dos operaciones en conflicto deben estar en el mismo orden relativo en todas las historias locales donde las operaciones aparecen juntas. 
 La segunda condición simplemente asegura que el orden de serialización sea el mismo en todos los nodos en donde las transacciones en conflicto se ejecutan juntas. 
 
Ejemplo 6. Considere las siguientes tres transacciones: 
T1: Read( x ) 
 T2: Read( x ) 
 
x ¬ x + 5 
 x ¬ x * 5 
 
Write( x ) 
 Write( x ) 
 
Commit 
 Commit 
 
 Las siguientes historias locales son individualmenteserializables (de hecho son seriales), pero las dos transacciones no son globalmente serializables. 
LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 } 
LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 } 
3.4 MECANISMOS DE SEGUROS
 Los mecanismos de seguridad en el control de concurrencia primero se introducen la notación de transacción. Una petición en-línea a la base de datos se considera como una transacción; generalmente involucrada llamadas a rutinas del DBMS para operaciones de Entrada / Salida y alguna cantidad limitada de operaciones. 
 El procesamiento de la transacción empieza tan pronto como se propone la petición del usuario. Termina cuando se contesta la petición y en ese momento el sistema libera todos los recursos utilizados para la transacción. 
 Algunos DBMS tiene mecanismos de seguridad para prevenir actualizaciones concurrentes sin control. Cuando se involucra simultáneamente varias transacciones para acceder los mismos datos, se forja a cada transacción a comprobar la existencia de un seguro asociado con los datos . 
 La figura muestra un mecanismo de seguridad que acomoda en serie dos operaciones de actualización concurrente. Una transacción puede acceder los datos sólo si el seguro asociado con los datos está abierto. Una vez que el programa tiene acceso a los datos, pone el seguro para así bloquear el acceso a los datos a las demás transacciones . 
 El seguro se restablece (rest) mediante la transacción cuando completa su operación de actualización. Aquellas transacciones a las que se negó el acceso a los datos estarán esperando en una fila asociada con el seguro hasta que éste sea restablecido. Cuando esto sucede, sólo la siguiente transacción bloqueara en fila de espera tendrá acceso a los datos compartidos.
 El término granularidad se refiere al tamaño de las unidades aseguradas de datos compartidos . En la programación con lenguajes de alto nivel, el sistema operativo proporciona un seguro para cada archivo. Así , la granularidad del seguro en este caso es todo un archivo. 
 Cuando un archivo se abre, se le asegura para excluir del acceso a otros programas , hasta que el archivo quede cerrado . 
 En un sistema de manejo de base de datos, la granularidad del seguro , que se especifica en el esquema, puede ser un riesgo, un campo o incluso ciertos valores en un campo. 
 Una granularidad pequeña resultará en un mejor uso de los datos y previene interferencias. Sin embargo el manejo de una gran cantidad de seguros se vuelve complejo mientras el nivel de la granularidad se hace más fino. 
 Normalmente un módulo especial llamado el manejador de la seguridad (lock manager) es responsable por el manejo de la misma. 
 No existen estándares en la industria para la implementación de los mecanismos de seguridad en un DBMS. Idealmente, un DBMS debería de prevenir automáticamente la interferencia de la simultaneidad sin necesidad de involucrar al programador, pero tal software sería difícil de implantar y costos de ejecutar. 
 Diversos sistemas proporcionan distintos recursos de seguridad para evitar la concurrencia de la transacciones. 
 En el sistema relacional System R, los mecanismos de seguridad son totalmente transparentes; no se requiere de ninguna operación de seguridad explícita por parte del usuario. 
 
Figura : Mecanismos de seguridad para actualizaciones simultaneas
 
3.4.1 TIPOS DE SEGUROS (ALGORITMOS DE CONTROL DE CONCURRENCIA)
 El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados) y aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos). 
 Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. 
 Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. 
 El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos híbridos. 
 
Algoritmos basados en candados 
 En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl), también llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles. 
 
 rl 
 wl 
 
rl 
 si 
 no 
 
wl 
 no 
 no 
 
 En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos.
 El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. 
 El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato. 
 
Candados de dos fases (2PL) 
 En los candados de dos fases una transacción le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transacción, la transacción solicitante debe esperar. Cuando una transacción libera un candado, ya no puede solicitar más candados. 
 Así una transacción que utiliza candados de dos fases se comporta como en la Figura 1. En la primera fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos uno por uno. 
 La importancia de los candados de dos fases es que se ha demostrado de manera teórica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables. Puede suceder que si una transacción aborta después de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten también provocando lo que se conoce como abortos en cascada. 
 Para evitar lo anterior, los despachadores para candados de dos fases implementan lo que se conoce como los candados estrictos de dos fases en los cuales se liberan todos los candados juntos cuando la transacción termina (con commit o aborta). El comportamiento anterior se muestra en la Figura 2. 
 
Figura 1. Gráfica del uso de los candados de dos fases. 
 
 
Figura 2 Comportamiento de los candados de dos fases estrictos. 
 
Candados de dos fases centralizadosEn sistemas distribuidos puede que la administración de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. 
 En la Figura 3 se presenta la estructura de la comunicación de un administrador centralizado de candados de dos fases. 
 La comunicación se presenta entre el administrador de transacciones del nodo en donde se origina la transacción (llamado el coordinador TM), el administrador de candados en el nodo central y los procesadores de datos (DP) de todos los nodos participantes. Los nodos participantes son todos aquellos en donde la operación se va a llevar a cabo. 
 
 
Figura 3. Comunicación en un administrador centralizado de candados de dos fases estrictos. 
 La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que se forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el sistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas en el nodo central. 
 
Candados de dos fases distribuidos 
 En los candados de dos fases distribuidos se presentan despachadores en cada nodo del sistema. Cada despachador maneja las solicitudes de candados para los datos en ese nodo. 
 Una transacción puede leer cualquiera de las copias replicada del elemento x, obteniendo un candado de lectura en cualquiera de las copias de x. 
 La escritura sobre x requiere que se obtengan candados para todas las copias de x. La comunicación entre los nodos que cooperan para ejecutar una transacción de acuerdo al protocolo de candados distribuidos de dos fases . 
 Los mensajes de solicitud de candados se envían a todos los administradores de candados que participan en el sistema. Las operaciones son pasadas a los procesadores de datos por los administradores de candados. 
 Los procesadores de datos envía su mensaje de "fin de operación" al administrador de transacciones coordinador. 
 Hay tres tipos distintos de seguros que pueden especificarse como seguros de control de acceso: literal , nombre del seguro o un procedimiento de la base de datos. 
 Las llaves encierran los tipos de operaciones o declaraciones DML ( por ejemplo : INSERT, DELETE) cuya ejecución en los datos asegurados requiere de una clave que coincida con a del control de acceso. 
Literal: Es el tipo de seguro más usado. Una literal es lo mismo que una contraseña. Previamente se dieron ejemplos del uso de contraseñas como seguro de control de acceso. 
Nombre del seguro: Especifica el nombre de un elemento en el cual se debe colocar el valor de un seguro . El elemento se guarda en una unidad de almacenamiento permanente y un programa de utilería designa su valor. Así, se puede cambiar el valor del seguro sin cambiar ni recopilar el esquema o subesquemas. 
Procedimiento de base de datos: Un procedimiento de la base de datos se puede usar para comprobar la validez de una clave y ver si coincide con el seguro. 
 A pesar de todo los medios para autorizar el acceso a objetivos asegurados en la sección, algún usuario no autorizado puede tratar de romper la seguridad ensayando distintas combinaciones de contraseña. Una manera de prever esto es registrar las identidades de los usuarios que trataron de acceder la base pero que fallaron debido a la falta de una autorización apropiada. Cuando un usuario ha hecho un cierto número de intentos dentro de un periodo de tiempo, se debe informar al personal de seguridad para que investigue la situación. 
 
 3.4.2 PROTOCOLOS
 Protocolos de bloqueo (locking protocols). 
 Estos son todos de dos fases: 
 2PL centralizad
 
 2PL con copia primaria 
 
 2PL distribuido 
 
 bloque mayoritario. 
 
 
 2PL centralizado 
 Se caracteriza por: 
 Hay un único planificador, o gestor de bloqueos (lock manager), para la totalidad del SGBD Distribuido que pueden garantizar (grant) y liberar (release) bloqueos. 
 
 2PL centralizado. 
o Funcionamiento: 
El coordinador de transacciones local divide la transacción en subtransacciones, usando el catálogo global del sistema. Si la transacción implica actualizar un dato que está replicado, el coordinador solicita un bloqueo de escritura de todas las copias antes de actualizar cada copia y liberar los bloqueos. El coordinador puede elegir cualquiera de las copias de un dato replicado para lectura. 
El gestor de transacciones local, implicado en la transacción global, solicita y libera los bloqueos que mantiene el gestor centralizado de bloqueos usando las reglas usuales para el bloqueo en dos fases. 
El gestor centralizado de bloqueos comprueba que las peticiones de bloqueo sobre un dato sean compatibles, de manera que el gestor de bloqueos envía un mensaje de vuelta al nodo que originó la petición reconociendo que el bloqueo ha sido concedido. En caso contrario, coloca la petición en una cola hasta que el bloqueo pueda ser realizado. 
 
2PL con copia primaria. 
 Se caracteriza por: 
 Cada gestor de bloqueos local es responsable de un conjunto de datos, de manera que se elige una copia como copia primaria; el resto de copia se llaman copias esclavas. La elección del nodo primario es flexible, y el nodo elegido no contiene necesariamente la copia primaria de ese dato. 
 
 2PL distribuido
 Se caracteriza por: 
 Se distribuye un gestor de bloqueo en cada nodo. Cada uno es responsable de la gestión de bloqueos de los datos que contiene en ese nodo. El 2PL distribuido implementa una protocolo de control de replicas Read-One-Write-All. 
 Cualquier copia de un dato replicado puede ser usada para operaciones de lectura, pero todas las copias deben ser bloqueadas para escritura antes que se puedan modificar. 
 
Bloqueo mayoritario. 
 Se caracteriza por: 
 Se mantiene un gestor de bloqueos en cada nodo para gestionar los bloqueos de ese nodo. Cuando se ejecuta una transacción que trabaja con un dato que esta replicado, debe enviar una petición de bloqueo a más de la mitad de los nodos donde esta el dato. 
 
 Protocolos de marcas de tiempo (time stamp protocols) 
 Su objetivo es ordenar las transacciones globalmente de manera que transacciones con una marca de tiempo menor, obtengan la prioridad en el caso de conflicto. El problema es que los relojes de nodos diferentes podrían no estar sincronizados. 
 
 Recuperación de bases de datos distribuidas 
 Fallos en un ambiente distribuido. 
 Tipos de fallos en un SGDB distribuido: 
 La pérdida de mensajes 
 
 El fallo de un enlace de comunicación 
 
 El fallo de un nodo 
 
 Particiones en la red 
 
 El primer punto es responsabilidad del sistema de comunicación, pero el resto de puntos deben ser resueltos por el SGBD distribuido. No obstante es importante el valor de timeout que se establezca (permite decidir si un nodo está caído, si está congestionado, o si es el canal el que tiene problemas). 
 Como afectan los fallos a la recuperación. 
 El SGBDD debe asegurar que las subtransacciones (forman la transacción global) sean realizadas todas o ninguna. 
Los pasos a seguir son: 
Abortar cualquier transacción afectada por el fallo 
Marcar el nodo como fallido para evitar accesos de otros nodos. 
Chequear periódicamente si el nodo se ha recuperado, o esperar a que el nodo fallido avise. 
Al reiniciar, el nodo fallido inicia un proceso de recuperación para abortar transacciones ejecutadas durante fallo. 
Después debe generar una copia consistente de la base de datos. 
 
 Protocolos distribuidos de recuperación. 
 El SGBDD tiene que asegurar la atomicidad en las transacciones globales. 
 Estos protocolosdeben impedir que el fallo en un nodo afecte al resto de nodos en funcionamiento (protocolos no bloqueantes). 
 Tipos de protocolos de ejecución de transacciones: 
Protocolo de ejecución en dos fases. Puede producir interbloqueo. 
 Protocolo de ejecución en tres fases. 
 Estos usan un coordinador (el que inicia la transacción) y tienen unos participantes (nodos implicados) 
 Protocolo de ejecución en dos fases. 
 Funcionamiento: 
 Se distinguen dos fases: votación y decisión. 
 En la primera el coordinador pregunta si están preparados para realizar (commit) la transacción. Si un participante vota abortar, o no responde dentro del timeout, entonces se aborta la transacción. Si todos votan para realizarla (commit), entonces el coordinador da instrucciones para realizar la transacción. 
 El periodo de timeout permite evitar el bloqueo de los nodos ante el fallo de uno de los participantes. Si un nodo falla en el proceso, todos siguen un protocolo de terminación, el nodo fallido sigue un protocolo de recuperación. 
Protocolo de terminación: 
 Este protocolo fija los pasos a seguir cuando un coordinador o participante falla al recibir un mensaje esperado dentro de un periodo de tiempo. 
 Este protocolo establece como deben actuar el coordinador y los participantes cuando no se recibe una respuesta durante el timeout. 
 Enviar PREPARE 
 
 Enviar DECISION 
 
 GLOBAL 
 
 RECONOCIMIENTO 
 
 recibido 
 
 INICIO 
 
 ESPERA 
 
 DECIDIDO 
 
 COMPLETADO 
 
 a) Coordinador b) Participante 
 
 Enviar 
 
 COMMIT 
 
 Enviar 
 
 ABORTAR 
 
 recibido PREPARE 
 
 INICIO 
 
 PREPARADO 
 
 ABORTADO EJECUTADO 
 
Protocolo de recuperación: 
 Este protocolo fija los pasos a seguir cuando el nodo fallido se recupera. 
 El protocolo al aplicar dependerá de quien falló: 
 El coordinador 
 
 Un participante 
 
 Si fue el coordinador quien falló los participantes pueden llevar a cabo un proceso de elección de un nuevo coordinador (protocolo de elección). 
Protocolo de recuperación. Fallo en el coordinador: 
 Estado INICIAL: La recuperación en este caso consiste en iniciar el procedimiento de ejecución (commit). 
 Estado de ESPERA: El coordinador no ha recibido todas las respuestas (ninguna de abortar). La recuperación consiste en reiniciar el procedimiento de ejecución (commit). 
 Estado DECIDIDO: El coordinador ha dado instrucciones para abortar o ejecutar globalmente la transacción. Al reiniciar, si el coordinador ha recibido todos los reconocimientos, completa la transacción con éxito, en caso contrario, tiene que iniciar el protocolo de terminación. 
Protocolo de recuperación. Fallo en un participante: 
Estado INICIAL: El participante no ha votado todavía sobre la transacción,de manera que cuando se recupera puede abortar 
Estado PREPARADO: El participante ha enviado su voto al coordinador. En este caso, la recuperación se hace mediante el protocolo de terminación discutido anteriormente. 
Fallo en los estados ABORTADO/EJECUTADO: El participante ha completado la transacción. Por consiguiente, al reiniciar, ninguna otraacción será necesaria. 
 
 Este protocolo debe intentar que todos los participantes realicen las mismas acciones (estado consistente). 
 Protocolo de elección: 
 El protocolo es ejecutado cuando los participantes detectan que el coordinador ha fallado. Una asunción que hace este protocolo es que los nodos tienen preestablecido un orden. 
 Funcionamiento: Cada nodo envía su numero de orden al resto de nodos mayores que el. Si este recibe un mensaje de un nodo menor que el deja de enviar mensajes. 
 Cuando el nodo fallido se recupera se vuelve a realizar la elección. 
 
Protocolo de ejecución en tres fases. 
 Características: 
 Es no bloqueante para nodos que fallan, excepto si fallan todos. Los fallos en la comunicación pueden hacer que diferentes nodos alcancen diferentes decisiones. 
El protocolo requiere: 
 
 Imposibilidad de que ocurran particiones en la red. 
 
 Al menos un nodo NO debe fallar. 
 
 Como mucho K nodos pueden fallar simultáneamente (el sistema seclasifica como K-elástico). 
 
 
 Protocolo de ejecución en tres fases. 
Funcionamiento: 
b) Participante 
 Enviar Preparado Enviar ABORTAR 
 
 Recibido 
 
 PREPARE 
 
 INICIO 
 
 PREPARADO 
 
 ABORTADO PRE-COMMIT 
 
 COMMITED 
 
a) Coordinador 
 DECIDIDO 
 
 (COMMITED) 
 
 COMPLETADO 
 
 Recibido 
 
 Preparado 
 
 Recibido 
 
 ABORTAR 
 
 Enviado 
 
 PREPARE 
 
 INICIO 
 
 ESPERANDO 
 
 DECIDIDO 
 
 (ABORTAR) 
 
 PRE-COMMIT
 
 
 El protocolo "commit" de dos fases permite que una transacción distribuida sea ejecutada de manera confiable y se llama de dos fases porque logra su objetivo en dos etapas. 
Primera Fase 
 Durante la primera etapa se consigue que todos los participantes reciban las operaciones que conforman la transacción, las escriban en lo que se llama "almacenamiento estable" y que le hagan conocer a un coordinador central que ya están listos para ejecutar la transacción. 
Segunda fase 
 La segunda etapa consiste de indicar a todos los participantes que ejecuten las operaciones de la transacción. 
Almacenamiento Estable 
 El almacenamiento estable consiste de algún medio físico en donde se pueda escribir datos de manera confiable, de tal suerte que si ocurre cualquier accidente se tenga la capacidad de recuperar todos los datos y suministrarlos a los procesos pertinentes. Por ejemplo, podemos decir que un medio de almacenamiento estable sería la combinación de escribir los datos en un disco duro primario y al mismo tiempo en uno o más discos secundarios (espejo) reduciendo al máximo la posibilidad de perder los datos. 
Código del protocolo commit de dos fases 
 Coordinador: Escribe la primitiva "PREPARE" en la bitácora 
Envía la primitiva PREPARE a cada participante e inicializa CONTADOR 
 Participantes: Esperan por la primitiva "PREPARE" 
Si el participante está listo para operar entonces 
ejecuta 
Escribe operaciones de la transacción a la bitácora local
Escribe la primitiva "LISTO" en la bitácora local
Envía la primitiva "LISTO" al coordinador 
si no, hace esto: 
Escribe la primitiva "ABORTAR" en la bitácora local
Envía la primitiva "ABORTAR" al coordinador. 
fin. 
Coordinador: Espera la primitiva LISTO o ABORTAR de todos los participantes 
o bien, espera que se venza el valor del CONTADOR. 
Si CONTADOR = 0 o alguna respuesta es la primitiva ABORTAR entonces 
Escribe la primitiva "ABORTAR GLOBAL" en la bitácora
Envía la primitiva ABORTAR a todos los participantes. 
Si no, si se reciben todos los mensajes de LISTO hace esto: 
Escribe la primitiva "COMMIT GLOBAL" en la bitácora local
Envía la primitiva "COMMIT GLOBAL" a todos los participantes. 
Participantes: Esperan por la primitva ABORTAR o COMMIT GLOBAL 
Escriben el mensaje recibido en la bitácora local (ABORTAR o COMMIT)
Envían la primitiva "CONFIRMADO" al coordinador
Ejecutan el mensaje recibido (ABORTAR o COMMIT) 
Coordinador: Espera por la primitiva CONFIRMADO de todos los participantes 
Escribe la primitiva COMPLETO en la bitácora local. 
 3.4.3 DEADLOCK
 El bloqueo (deadlock) ocurre cuando se desarrolla una espera circular entre dos transacciones y cada una solicita una operación de actualización sobre el mismo archivo. 
 Suponga que las dos siguientes actualizaciones se deben ejecutar: 
 Transacción 1: Cambiar la cantidad de una orden de compra en la cual el cliente H. Haley compró una pieza el 16 de diciembre. La cantidad nueva es 4. La petición será procesada al acceder primero el archivo CUSTOMER y después el archivo TRANS . 
 Transacción 2: Actualizar la dirección del cliente que compró una pieza con número de inventario (INV-NO) 1408 el 4 de diciembre. La dirección nueva es40 Bank Street. 
 Para cumplir con la petición primero se debe acceder el archivo TRANS y después el archivo CUSTOMER. 
 Ambas transacciones reclaman los mismos archivos TRANS Y CUSTOMER. Para empezar, cada transacción reclama un archivo. Después, cada transacción hace seguir otro comando READY solicitando el otro archivo que necesita. 
 Sin embargo, cada transacción queda bloqueado para uso exclusivo. Ambas transacciones esperarán infinitamente, ya que ninguna puede terminar su transacción y liberar el archivo solicitado por otra. 
 El programador o el sistema puede evitar los bloqueos. En el ejemplo anterior esto se puede hacer si una transacción demanda los dos archivos que requiere para completar su transacción al mismo tiempo: 
 Transaction 1: access the TRANS file and then the CUSTOMER file. 
 Transaction 2: access the CUSTOMER file and then the TRANS file 
 
 Ejemplo de bloqueo
 En las dos primeras proposiciones READY , cada transacción llama a un archivo y establece un seguro sobre el archivo solicitado. Se desarrolla una situación de establecimiento cuando la transacción 1 se bloquea por su petición de tener derecho exclusivo sobre el archivo CUSTOMER , y a su vez , la proposición 2 se bloquea por su petición de entrar en el uso exclusivo del archivo TRANS. Como resultado, ambas transacciones esperarán infinitamente. 
 Si un conjunto de procesos esta en estado de espera por recursos y nunca cambia de estado porque los recursos por los que espera están siendo utilizados por otros procesos en estado de espera tenemos un Deadlock. Los recursos son la memoria, dispositivos de E/S, semáforos, archivos, etc. 
La forma en que un proceso hace uso de un recurso es: 
 Solicitud: si el recurso esta disponible se le otorga, si no el proceso pasa a estado de espera. 
 
 Uso: El proceso utiliza el recurso 
 
 Liberación: el proceso debe liberar el recurso. 
 
 
Condiciones necesarias para que se produzca deadlock 
 Si se presentan simultáneamente las cuatro siguientes condiciones el sistema esta en deadlock. 
Exclusión mutua: Por lo menos un proceso que tenga otorgado un recurso en forma exclusiva. 
Uso y Espera: Debe existir al menos un proceso que este haciendo uso de un recurso y que este esperando por otros recursos asignados a otros procesos. 
No interrupción: Los recursos no pueden ser retirados al proceso. Si un proceso hace uso de un recurso no le podrá ser retirado hasta que voluntariamente el proceso lo libere. 
Espera Circular: Debe existir un conjunto de procesos {P1.....Pn} tal que P1 espera por un recurso utilizado por P2,......,Pn espera por un recurso utilizado por P1. 
 
Resourse Allocation Graph (Grafo de utilización de recursos) 
Conjunto de Vértices: U =P U R 
P={P1,P2,....,Pn} 
R={R1,R2,...,Rn} 
 Conjunto de Aristas: 
 Una arista de un proceso Pi a un Recurso Rj significa que el proceso i esta haciendo una solicitud por el recurso Rj. 
 Una arista del recurso Rj al proceso Pi, significa que el recurso esta asignado al proceso. 
 Si un RAG no tiene ciclos el sistema no esta en DEADLOCK, si los tiene no se puede afirmar nada. 
 
3.4.3.1 TÉCNICAS PARA PREVENIRLO
Prevención de Deadlocks 
 La estrategia consiste en anular alguna de las cuatro condiciones necesarias para que se produzca un Deadlock. 
No puede ser anulada porque existen recursos que deben ser usados en modalidad exclusiva. 
La alternativa sería hacer que todos los procesos solicitaran todos los recursos que habrán de utilizar antes de utilizarlos al momento de su ejecución lo cual sería muy ineficiente. 
Para anular esta condición cuando un proceso solicita un recurso y este es negado el proceso deberá liberar sus recursos y solicitarlos nuevamente con los recursos adicionales. El problema es que hay recursos que no pueden ser interrumpidos. 
Espera Circular: esta estrategia consiste en que el sistema operativo numere en forma exclusiva los recursos y obligue a los procesos a solicitar recursos en forma ascendente. El problema de esto es que quita posibilidades a la aplicación. 
 
Evasión de Deadlocks 
 
 Si se tiene cuidado al en la forma de asignar los recursos se pueden evitar situaciones de Deadlock. Supongamos un ambiente en el que todos los procesos declaren a priori la cantidad máxima de recursos que habá de usar. 
 
 Estado Seguro: un estado es seguro si se pueden asignar recursos a cada proceso (hasta su máximo) en algún orden sin que se genere Deadlock. El estado es seguro si existe un ordenamiento de un conjunto de procesos {P1...Pn} tal que para cada Pi los recursos que Pi podrá utilizar pueden ser otorgados por los recursos disponibles mas los recursos utilizados por los procesos Pj,j<i. Si los recursos solicitados por Pi no pueden ser otorgados, Pi espera a que todos los procesos Pj hayan terminado. 
 
 
 Algoritmo del banquero de Dijkstra 
 
 Asigna peticiones de recursos siempre que las mismas den como resultado estados seguros. Solicitudes que den como resultado estados inseguros serán negadas hasta que puedan ser satisfechas. Este algoritmos evita situaciones de Deadlock asignando los recursos en forma correcta. 
 
 Las debilidades del algoritmo son: que requiere que la cantidad de recursos del sistema sea constante, requiere una cantidad de procesos constante y requiere que los procesos garanticen que los recursos van a ser devueltos en un intervalo finito de tiempo. 
 
Algoritmos de Detección de Deadlock 
 
Cuando hay una única ocurrencia de cada recurso. (variante del grafo de "wait for graph"). Consiste en reducir el grafo, retirando las aristas que van de recursos a procesos y de procesos a recursos, colocando nuevas aristas que reflejan la situación de espera entre procesos. Si el grafo reducido tiene ciclos el sistema esta en Deadlock. Orden de operaciones = n^2 , n = cantidad de aristas. 
Cuando hay múltiples ocurrencias de cada recurso 
Procedure detecta_deadlock 
var Disponible:array[1..n] of integer //# de recursos 
Usados:array[1..n] of integer 
Solicitados:array[1..n] of integer 
Finalizado:array[1..n] of boolean 
Begin 
Work:=Disponibles; 
For i:=1..n do if(usados[i]≠0) then finish[i]:=false 
Else finish[i]:=true; 
While(encontrar_indice_i = true) do { 
Work:=work + usados[i]; 
Finish[i]:=true; } 
If ((finish[i] = false) para algun i), 1≤i≤n then à El sistema esta en Deadlock. 
End 
Function encontrar_indice_i : Boolean 
Begin 
If (existe i tal que (Finish[i]=false && solicitados[i] ≤ work) 
Then -> true 
Else -> false 
End 
 
3.4.3.2 TÉCNICAS PARA DESHACERLO (RECUPERACIÓN)
 En una base de datos puede existir errores debido a varios motivos, tales como la actualización incompleta de datos redundantes, validación inadecuada de los datos de entrada, mal funcionamiento físico o errores de lógica en la programación . Desgraciadamente los errores no siempre se pueden evitar, así que los DBMS proporcionan mecanismos para recuperar los datos correctos después de que ocurren los errores. 
 La restauración de una base de datos a su estado normal es un problema real e importante que no se puede pasar por alto. 
 Generalmente, quien opera la base (DBA) , es responsable de implementar procedimientos de detección de errores . Utilerías de detección son proporcionadas como parte de DBMS o se puede desarrollar particularmente. Sin importar el procedimiento utilizado, éstos se corren a intervalos regulares para mantener la integridad. Una vez detectados, es esencial que el manejador los corrija inmediatamente. 
 Para que el manejador obtenga la información necesaria para efectuar la recuperación de la base, se debe hacer regularmentecopias de respaldo (back-up copies). Por lo común se usan cintas magnéticas para guardar las copias, debido a que son compactas y de bajo costo. 
 La última copia de respaldo anterior a un error, se usa para restaurar los datos afectados hasta ese día. A veces ocurre que se requiere varias copias de respaldo de distintas áreas afectadas para restaurar completamente la base de datos. 
 Operación de registro 
 La mayoría de los DBMS proporcionan un elemento de rastreo para registrar lo sucedido en cada transacción actualizada por la base de datos . 
 El registro, es un prerrequisito para la recuperación de la base de datos; restaura un archivo a su estado anterior cuando ocurre alguna falla en una transacción. El manejador del registro (log manager), es una componente de la DBMS que efectúa el registro escribiendo cualquiera de los dos tipos de registro siguiente en un archivo de búsqueda: 
1) Ante-imagen: Se refiere a los bloques antiguos de datos originales en la base que se guardaron antes de la actualización de una transacción. Si ocurre un error, esta copia se puede usar para cancelar el efecto de la transacción. 
2) Post-imagen: Es el nombre que recibe un bloque procesado por una transacción listo para ser reescrito en la base. 
Métodos de recuperación 
 Se usan dos métodos de recuperación de base de datos: recuperación en avance o recuperación en retroceso (roll-forward o roll-back). El método a utilizar depende del tipo y la extensión de los errores. 
1) Recuperación en avance 
 Con este método se consigue la restauración mediante la copia de respaldo de la base para recuperar la porción principal de los datos. Después se reaplican los registros post-imagen del registro a la copia de respaldo para incorporar las actualizaciones efectuadas desde que se hizo la copia de respaldo. Los registros post-imagen del registro log, más que las transacciones, se reaplican ala copia de respaldo, ya que estas imágenes son datos procesados, listos para rescribirse en la base. 
2) Recuperación en retroceso 
 Esta recuperación puede nulificar el efecto de una sola transacción que hizo cambios en la base pero abortó antes del término. ( Recuerde que para mantener la integridad de los datos, una transacción debe ejecutarse en su totalidad o no ejecutarse). La recuperación en retroceso se consigue llamando al registro ante-imagen del archivo log y reinstalándolo en la base para nulificar el efecto de transacción errónea. 
3.5 ETIQUETAS DE TIEMPO (ESTAMPADO DE TIEMPO) 
Algoritmos basados en estampas de tiempo
 A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts( Ti ) cuando ésta inicia. 
 Una estampa de tiempo es un identificado r simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la monoticidad, esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado. 
 
 
Figura 1. Comunicación en candados de dos fases distribuidos. 
 
 Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos. 
 Por lo tanto, es preferible que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio identificador. Así, la estampa de tiempo es un par de la forma 
<contador local, identificador de nodo> 
 Note que el identificador de nodo se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes. 
El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción. Más aún, a cada elemento de datos x se le asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de lectura, rts(x) ; sus valores indican la estampa de tiempo más grande para cualquier lectura y escritura de x, respectivamente. 
El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla: 
Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser un transacción más vieja y Tk se dice ser una transacción más joven. 
 
Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma: 
for Ri(x) do begin 
if ts(Ti) < wts( x ) then 
reject Ri(x) 
else 
accept Ri(x) 
rts(x) ¬ ts(Ti) 
end 
 for Wi(x) do begin 
if ts(Ti) < rts(x) and 
ts(Ti) < wts(x) then 
reject Wi(x) 
else 
accept Wi(x) 
wts(x) ¬ ts(Ti) 
end 
 
 
 La acción de rechazar una operación, significa que la transacción que la envió necesita reiniciarse para obtener la estampa de tiempo más reciente del dato e intentar hacer nuevamente la operación sobre el dato. 
 
Ordenamiento conservador por estampas de tiempo 
 El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. 
 El ordenamiento conservador de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no será reiniciada. 
 La forma de asegurar lo anterior es sabiendo que ninguna otra operación con una estampa de tiempo menor puede llegar al despachador. Un problema que se puede presentar al retrasar las operaciones es que esto puede inducir la creación de interbloqueos (deadlocks). 
Ordenamiento por estampas de tiempo múltiples 
 Para prevenir la formación de interbloqueos se puede seguir la estrategia siguiente. Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate: 
1. Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una sola versión encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa de tiempo más grande que tiene un valor menor a ts(Ti). 
Una operación de escritura Wi(x) se traduce en una sola version, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que, 
ts(Ti) < ts(xr) < ts(Tj) 
Control de concurrencia optimista 
 Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato. 
 Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (V), lectura (R), cómputo (C) y escritura (W) . Los algoritmos optimistas, por otra parte, retrasan la fase devalidación justo antes de la fase de escritura ). De esta manera, una operación sometida a un despachador optimista nunca es retrasada. 
 Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace sus cambios en copias locales de los datos. 
 La fase de validación consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar. 
 
 
. Fases de la ejecución de una transacción pesimista, optimista. 
 Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no con los datos. 
 Más aún, las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación. 
 
 
 
	
	http://geocities.yahoo.com/ps/info?.refer=dbannerhttp://geocities.yahoo.com/ps/info?.refer=dbanner
	¡Error!Referencia de hipervínculo no válida.
	
	http://geocities.yahoo.com/ps/info?.refer=dbannerGeoCities Premium Services
	
4. SEGURIDAD
		
	4.1 CONCEPTO		
	El objetivo es proteger la Base de Datos contra accesos no autorizados. Se llama también privacidad. 
Incluye aspectos de:		
		Aspectos legales, sociales y éticos 	
		Políticas de la empresa, niveles de información publica y privada 	
		Controles de tipo físico, acceso a las instalaciones 	
		Identificación de usuarios: voz, retina del ojo, etc. 	
		Controles de sistema operativo 	
	En relación al SGBD, debe mantener información de los usuarios, su tipo y los accesos y operaciones permitidas a éstos. 
Tipos de usuarios: 
· DBA, están permitidas todas las operaciones, conceder privilegios y establecer usuarios 		
		Usuario con derecho a crear, borrar y modificar objetos y que además puede conceder privilegios a otros usuarios sobre los objetos que ha creado. 	
		Usuario con derecho a consultar, o actualizar, y sin derecho a crear o borrar objetos. 	
	Privilegios sobre los objetos, añadir nuevos campos, indexar, alterar la estructura de los objetos, etc. 
Los SGBD tienen opciones que permiten manejar la seguridad, tal como GRANT, REVOKE, etc. También tienen un archivo de auditoria en donde se registran las operaciones que realizan los usuarios. 
MEDIDAS DE SEGURIDAD 		
		Físicas: Controlar el acceso al equipo. Tarjetas de acceso, etc	
		Personal: Acceso sólo del personal autorizado. Evitar sobornos, etc.	
		SO: Seguridad a nivel de SO	
		SGBD: Uso herramientas de seguridad que proporcione el SGBD. Perfiles de usuario, vistas, restricciones de uso de vistas, etc.	
	Un SMBD cuenta con un subsistema de seguridad y autorización que se encarga de garantizar la seguridad de porciones de la BD contra el acceso no autorizado:		
		Identificar y autorizar a los usuarios: uso de códigos de acceso y palabras claves, exámenes, impresiones digitales, reconocimiento de voz, barrido de la retina, etc.	
		Autorización: usar derechos de acceso dados por el terminal, por la operación que puede realizar o por la hora del día.	
		Uso de técnicas de cifrado: para proteger datos en Base de Datos distribuidas o con acceso por red o internet.	
		Diferentes tipos de cuentas: en especial del ABD con permisos para: creación de cuentas, concesión y revocación de privilegios y asignación de los niveles de seguridad.	
		Manejo de la tabla de usuarios con código y contraseña, control de las operaciones efectuadas en cada sesión de trabajo por cada usuario y anotadas en la bitácora, lo cual facilita la auditoria de la Base de Datos.	
	
4.2 IDENTIFICACIÓN Y AUTENTIFICACIÓN
En un SGBD existen diversos elementos que ayudan a controlar el acceso a los datos. En primer lugar el sistema debe identificar y autentificar a los usuarios utilizando alguno de las siguientes formas: 		
		Código y contraseña 	
		Identificación por hardware 	
		Características bioantropométricas 	
		Conocimiento, aptitudes y hábitos del usuario 	
		Información predefinida (Aficiones, cultura, etc) 	
	Además, el administrador deberá especificar los privilegios que un usuario tiene sobre los objetos: 		
		Usar una B.D. 	
		Consultar ciertos datos 	
		Actualizar datos 	
		Crear o actualizar objetos 	
		Ejecutar procedimientos almacenados 	
		Referenciar objetos 	
		Indexar objetos 	
		Crear identificadores 	
	Mecanismos de autentificación 
La autentificación, que consiste en identificar a los usuarios que entran al sistema, se puede basar en posesión (llave o tarjeta), conocimiento (clave) o en un atributo del usuario (huella digital). 
Claves 
El mecanismo de autentificación más ampliamente usado se basa en el uso de claves o passwords; es fácil de entender y fácil de implementar. En UNIX, existe un archivo /etc/passwd donde se guarda los nombres de usuarios y sus claves, cifradas mediante una función one-way F. El programa login pide nombre y clave, computa F(clave), y busca el par (nombre, F(clave)) en el archivo. 
Con claves de 7 caracteres tomados al azar de entre los 95 caracteres ASCII que se pueden digitar con cualquier teclado, entonces las 957 posibles claves deberían desincentivar cualquier intento por adivinarla. Sin embargo, una proporción demasiado grande de las claves escogidas por los usuarios son fáciles de adivinar, pues la idea es que sean también fáciles de recordar. La clave también se puede descubrir mirando (o filmando) cuando el usuario la digita, o si el usuario hace login remoto, interviniendo la red y observando todos los paquetes que pasan por ella. Por último, además de que las claves se pueden descubrir, éstas también se pueden "compartir", violando las reglas de seguridad. 
En definitiva, el sistema no tiene ninguna garantía de que quien hizo login es realmente el usuario que se supone que es. 
Identificación física 
Un enfoque diferente es usar un elemento físico difícil de copiar, típicamente una tarjeta con una banda magnética. Para mayor seguridad este enfoque se suele combinar con una clave (como es el caso de los cajeros automáticos). Otra posibilidad es medir características físicas particulares del sujeto: huella digital, patrón de vasos sanguíneos de la retina, longitud de los dedos. Incluso la firma sirve. 
Algunas medidas básicas: 		
		Demorar la respuesta ante claves erróneas; aumentar la demora cada vez. Alertar si hay demasiados intentos. 	
		Registrar todas las entradas. Cada vez que un usuario entra, chequear cuándo y desde dónde entró la vez anterior. 	
		Hacer chequeos periódicos de claves fáciles de adivinar, procesos que llevan demasiado tiempo corriendo, permisos erróneos, actividades extrañas (por ejemplo cuando usuario está de vacaciones). 	
	
4.3 MATRIZ DE AUTORIZACIÓN
Autorizaciones 
Para facilitar la administración los SGBD suele incorporar el concepto de perfil, rol o grupo de usuarios que agrupa a una serie de privilegios por lo k el usuario que se asigna a un grupo hereda todos los privilegios del grupo. 
El mecanismo de control de acceso se encarga de denegar o conceder el acceso a los usuarios. En un SGBD puede existir diferentes tipos de autorización: 
Una primera distinción puede hacerse entre: 		
		Autorización explicita. Normalmente usada en los sistemas tradicionales. Consiste en almacenar que sujetos pueden accesar a ciertos objetos con determinados privilegios para lo que suele utilizarse una matriz de control de accesos. 	
		Autorización implícita. Consiste en que una autorización definida sobre un objeto puede deducirse a partir de otras (por ejemplo si se puede acceder a una clase en un SGBD se puede también acceder a todas las instancias de esa clase). 	
	Los usuarios pueden tener varios tiposde autorización para diferentes partes de la base de datos. 
Entre ellas están las siguientes: 		
		La autorización de lectura permite la lectura de los datos, pero no su modificación 	
		La autorización de inserción permite la inserción de datos nuevos, pero no la modificación de los existentes. 	
		La autorización de actualización permite la modificación de los datos, pero no su borrado. 	
		La autorización de borrado permite el borrado de los datos.	
	Los usuarios pueden recibir todos los tipos de autorización ninguno de ellos, o una combinación determinada de los mismos. 
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: 		
		La autorización de índices permite la creación y borrado de índices. 	
		La autorización de recursos permite la creación de las relaciones nuevas 	
		La autorización de alteración permite el añadido o el borrado de atributos de las relaciones. 	
		La autorización de eliminación permite el borrado de relaciones. 	
	Las autorizaciones de eliminación y de borrado se diferencian en que la autorización de borrado solo permite el borrado de tuplas. Si un usuario borra todas las tuplas de unas relación, la relación sigue existiendo, pero esta vacía. Si se elimina una relación, deja de existir. 
La capacidad de crear nuevas relaciones queda regulada mediante la autorización de recursos. El usuario con la autorización de recursos que crea una relación nueva recibe automáticamente todos los privilegios sobre el sistema. 
La autorización de índices puede parecer innecesaria, dado que la creación o borrado de un índice no afecta a los datos de las relaciones. Más bien, los índices son una estructura para las mejoras de rendimiento. Sin embargo, los índices también ocupan espacio y se exige que las modificaciones de las bases de datos actualicen los índices , los que llevaran a cabo actualizaciones estarían tentados de borrar los índices , los que llevan a cabo actualizaciones estarían tentados de borrar los índices, mientras que los que formulara consultas estarían tentados de crear numeroso índices. 
Para permitir si el 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 concebida al administrador de la base de datos. El administrador de la base de datos puede autorizar usuarios nuevos, reestructurar la base de datos, etc. 
Esta forma de autorización es análoga a la proporcionada al súper usuario u operador del sistema operativo. 
4.4 DEFINICIÓN DE UN ESQUEMA DE SEGURIDAD
El problema de la seguridad consiste en lograr que los recursos de un sistema sean, bajo toda circunstancia, utilizados para los fines previstos. Para eso se utilizan mecanismos de protección.
Un aspecto importante de la seguridad es el de impedir la pérdida de información, la cual puede producirse por diversas causas: fenómenos naturales, guerras, errores de hardware o de software, o errores humanos. La solución es una sola: mantener la información respaldada, de preferencia en un lugar lejano. 
Otro aspecto importante de la seguridad, es el que tiene que ver con el uso no autorizado de los recursos: 		
		Lectura de datos.	
		Modificación de datos.	
		Destrucción de datos.	
		Uso de recursos: ciclos de CPU, impresora, almacenamiento.	
	Otras amenazas y ataques posibles:		
		Virus. Un virus es parecido a un gusano, en cuanto se reproduce, pero la diferencia es que no es un programa por sí sólo, si no que es un trozo de código que se adosa a un programa legítimo, contaminándolo. Cuando un programa contaminado se ejecuta, ejecutará también el código del virus, lo que permitirá nuevas reproducciones, además de alguna acción (desde un simple mensaje inocuo hasta la destrucción de todos los archivos).	
		Caballo de troya. Un caballo de troya es un programa aparentemente útil que contiene un trozo de código que hace algo no deseado.	
		Puerta trasera. Una puerta trasera es un punto de entrada secreto, dejado por los implementadores del sistema para saltarse los procedimientos normales de seguridad. La puerta trasera puede haberse dejado con fines maliciosos o como parte del diseño; en cualquier caso, son un riesgo.	
		Caza claves. Dejar corriendo en un terminal un programa que pida "login:" y luego "password:", para engañar a los usuarios de modo que estos revelen su clave.	
		Solicitar recursos como páginas de memoria o bloques de disco, y ver qué información contienen; muchos sistemas no los borran cuando se liberan, de modo que se puede encontrar información "interesante".	
		Sobornar o torturar al administrador para que suelte la clave.	
	Principios básicos para la seguridad		
		Suponer que el diseño del sistema es público. 	
		El defecto debe ser: sin acceso. 	
		Chequear permanentemente. 	
		Los mecanismos de protección deben ser simples, uniformes y construidos en las capas más básicas del sistema. 	
		Los mecanismos deben ser aceptados sicológicamente por los usuarios. 	
	
4.5 MECANISMOS DE VISTAS PARA LA IMPLANTACIÓN DE SEGURIDAD (VIEW/FORMS)
Vistas 
El concepto de vistas es el medio de proporcionar a un usuario un modelo personalizado de la base de datos. Una vista puede ocultar los datos que un usuario no necesita ver. La capacidad de las vistas puede ocultar datos sirve para simplificar el uso del sistema y para mejorar la seguridad. 
El uso del sistema se simplifica porque se permite al usuario restringir su atención a los datos de interés. 
Aunque pueden que se nieguen el acceso directo a una relación, puede que se le permita el acceso a parte de esa relación mediante una vista. Por lo tanto, 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 se necesita. 
En el ejemplo bancario, considérese un empleado que necesita saber los nombres de todos los clientes que tienen un préstamo en cada sucursal. Este empleado no esta autorizado a ver la información concerniente a los prestamos concretos que pueda tener cada cliente. Por lo tanto, se le debe negar el acceso directo ala relación préstamo. 
Pero si va a tener acceso a la información necesaria, se le debe conceder acceso ala vista cliente-préstamo, que consiste solo en los nombres de los clientes y las sucursales en los que tiene un préstamo. Esta vista se puede definir en SQL de la siguiente manera: 
Create view cliente-préstamo as 
(select nombre-sucursal, nombre-cliente 
from prestatario, préstamo 
where prestatario.número-préstamo = préstamo.número-préstamo) 
Supóngase que el empleado formula la siguiente consulta SQL: 
select * 
from préstamo-cliente 
El empleado esta autorizado a ver el resultado de esta consulta. Sin embargo, cuando el procesador de consultas traduce la consulta en una consulta sobre las relaciones reales de la base de datos, se obtiene una consulta sobre prestatario y préstamo. Por lo tanto, se debe comprobar la autorización de la consulta del empleado antes de que comience el procesamiento de la misma. 
La creación de vistas no necesita autorización de recursos. El usuario que crea una vista no recibe necesariamente todos los privilegios sobre la misma. 
Ese usuario solo recibe los privilegios sobre la misma. Ese usuario solo recibe los privilegios que no proporcionan autorizaciones adicionales respecto de las que ya posee. 
Por ejemplo, un usuario no puede recibir la autorización de actualización sobre una vista sin tener la autorización de actualización sobre las relaciones utilizadas para definir la vista. Si un usuario crea una vista sobre la que no se puede conceder ninguna autorización de lectura sobre las relaciones prestatario y préstamo. 
4.6 BASE DE DATOS ESTADÍSTICAS
En este tipo de base de datos se debe evitar que a a partir de consultas que afectan a los datos globales se puedan inferir valores de datos individuales o inferir que un dato elemental no tiene determinado valor. 
Las