Restricciones De Bases De Datos

Tema 6. Restricciones a la Base de Datos:

Integridad y seguridad

Juan Ignacio Rodr´ıguez de Le´on

Resumen

Las restricciones desde el punto de vista de integridad de bases

de datos. se presentan dependencias funcionales, integridad referencial

y otros mecanismos para mantenimiento de integridad, tales

como disparadores y afirmaciones. El objetivo es la protecci ´on de la

base de datos de accidentes. Restricciones de los dominios. Integridad

referencial. Asertos (asserts). Disparadores (triggers). Seguridad

y autorizaci´on. Autorizaci´on en SQL. Cifrado y autenticaci ´on

´Indice

1. Restricciones de los dominios 3

2. Integridad referencial 4

2.1. Integridad referencial en el modelo E-R . . . . . . . . . . . . 4

2.2. Modificaci´on de la base de datos . . . . . . . . . . . . . . . . 4

2.3. Integridad referencial en SQL . . . . . . . . . . . . . . . . . . 5

3. Asertos 6

4. Disparadores (triggers) 7

4.1. Necesidad de los disparadores . . . . . . . . . . . . . . . . . 7

4.2. Disparadores en SQL . . . . . . . . . . . . . . . . . . . . . . . 7

4.3. Cuando no deben usarse disparadores . . . . . . . . . . . . . 8

5. Seguridad y autorizaci´on 8

5.1. Violaciones de la seguridad . . . . . . . . . . . . . . . . . . . 8

5.2. Autorizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3. Autorizaciones y vistas . . . . . . . . . . . . . . . . . . . . . . 9

5.4. Concesi´on de privilegios . . . . . . . . . . . . . . . . . . . . . 10

5.5. El concepto de papel (rol) . . . . . . . . . . . . . . . . . . . . . 10

5.6. Trazas de auditor´ıa . . . . . . . . . . . . . . . . . . . . . . . . 10

1

´INDICE 2

6. Autorizaci´on en SQL 11

6.1. privilegios en SQL . . . . . . . . . . . . . . . . . . . . . . . . 11

6.1.1. Papeles o roles . . . . . . . . . . . . . . . . . . . . . . 12

6.1.2. El privilegio de conceder privilegios . . . . . . . . . . 12

6.1.3. Otras caracter´ısticas . . . . . . . . . . . . . . . . . . . 12

7. Cifrado y autenticaci´on 13

7.1. T´ecnicas de cifrado . . . . . . . . . . . . . . . . . . . . . . . . 13

7.2. Autenticaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 RESTRICCIONES DE LOS DOMINIOS 3

En este tema se tratar´an las restricciones a la base de datos. Las restricciones

son limitaciones que deseamos imponer en nuestra sistema, de forma

que sea imposible almacenar datos incorrectos.

Algunas de las restricciones ya se han visto, por ejemplo, la limitaci ´on de

los valores posibles de los atributos a un subconjunto, lo que denomin´abamos

dominio del atributo.

1. Restricciones de los dominios

Las restricciones de los dominios son la formam´as simple de restricci ´on

de integridad. El sistema las verifica f´acilmente siempre que se introduce

en la base de datos un nuevo elemento de datos.

La cl´ausula create domain se puede usar para definir nuevos dominios.

Por ejemplo, las instrucciones:

create domain Euros numeric(12,2)

create domain D´olares numeric(12,2)

Un intento de asignar un valor de tipo D´olares a una variable de tipo

Euros resultar´ıa en un error sint´actico, aunque ambos tengan el mismo tipo

num´erico.

SQL tambi´en proporciona las cl´ausulas drop domain y alter domain para

borrar o modificar dominios que se hayan declarado anteriormente.

La cl´ausula check de SQL permite restringir aunm´as los dominios; permite

al dise ˜nador del esquema especificar un predicado que debe satisfacer

cualquier valor para poder pertenecer al dominio. V´ease, como ejemplo:

create domain sueldo-por-hora numeric(5,2)

constraint comprobaci´on-valor-sueldo

check (value  4.00)

El dominio sueldo-por-hora tiene una restricci ´on que asegura que el

sueldo por hora sea mayor que 4,00.

Tambi´en puede utilizarse para restringir un dominio para que no contenga

valores nulos, o se puede limitar para que contenga s ´olo un conjunto

especificado de valores usando la cl´ausula in.

las condiciones check permiten subconsultas que se refieren a otras relaciones.

Por ejemplo, esta restricci ´on se podr´ıa especificar sobre la relaci ´on

pr´estamo:

check (nombre-sucursal in

(select nombre-sucursal from sucursal))

2 INTEGRIDAD REFERENCIAL 4

La condici´on check verifica que nombre-sucursal en cada tupla en la

relaci ´on pr´estamo es realmente el nombre de una sucursal de la relaci ´on

cuenta. As´ı, la condici´on no s ´olo se debe comprobar cuando se inserte o

modifique pr´estamo, sino tambi´en cuando cambie la relaci ´on sucursal (en

este caso, cuando se borre o modifique la relaci ´on cuenta).

La restricci ´on anterior es realmente un ejemplo de una clase de restricci

´on muy habitual denominadas restricci ´on de integridad referencial. En el

Apartado 2 se estudian estas restricciones y como especificarlas en SQL.

Las condiciones check complejas pueden ser ´ utiles cuando se desee

asegurar la integridad de los datos, pero se deben usar con cuidado, dado

que pueden ser costosas de comprobar.

2. Integridad referencial

A menudo se desea asegurar que un valor que aparece en una relaci ´on

para un conjunto de atributos determinado aparezca tambi´en en otra relaci ´on

para un cierto conjunto de atributos. Esta condici´on se denomina integridad

referencial.

El caso m´as normal es cuando queremos garantizar que el valor almacenado

en una clave externa est´a tambi´en como clave primaria en la

relaci ´on referenciada. En caso contrario, se dice que la tupla de la relaci ´on

referenciante est´a colgante.

Las tuplas colgantes pueden ser aceptables o no, dependiendo del modelo

de datos. En el caso de que no sean aceptables, hay que imponer una

integridad referencial o dependencia de subconjunto.

2.1. Integridad referencial en el modelo E-R

Si se obtiene el esquema de la base de datos relacional creando tablas a

partir de los diagramas E-R, cada relaci ´on que proceda de un conjunto de

relaciones tendr´a restricciones de integridad referencial.

Otra fuente de restricciones de integridad referencial son los conjuntos

de entidades d´ebiles; el esquema de la relaci ´on de cada conjunto de entidades

...