RESTRICCIONES DE INTEGRIDAD EN EL MODELO RELACIONAL

Miguel Bautista Len DNI: 44591303f 11 de Abril de 2008

ndice

1. Introduccin al modelo relacional..3 2. Conceptos previos..5 3. El problema de la integridad en las bases de datos8 4. Restricciones de los dominios. Unicidad y valor nulo......10 5. Restricciones en la clave. Integridad de entidades12 6. Integridad referencial y claves externas....147. Integridad referencial en SQL17

8. Operaciones de actualizacin y tratamiento de las violaciones a las restricciones18 9. Ejemplo...20 10. Asertos, disparadores y reglas de verificacin. ..........................................2311. Disparadores en SQL..26

12. Bases de datos activas. .......2713. Modelo ECA y propiedades de las reglas activas...28

14. Bibliografa..30

Introduccin al modelo relacional

El modelo de datos relacional fue introducido por Tedd Codd de IBM Research en 1970. Codd introduce el concepto de relacin como una estructura bsica del modelo, lo que supuso un importante paso en la investigacin de los SGBD (Sistemas Gestores de Bases de Datos), suministrando un slido fundamento terico para el desarrollo, dentro de este enfoque relacional, de nuevos productos. El trabajo publicado por Codd, presentaba un nuevo modelo de datos que persegua una serie de objetivos, que se pueden resumir en los siguientes:

-Independencia fsica: es decir, el modo en el que se almacenan los datos no influya en su manipulacin lgica y, por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico. -Independencia lgica: esto es, que el aadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos (vistas). -Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en que ste prefiera. -Uniformidad: las estructuras lgicas de los datos presentan un aspecto uniforme, lo que facilita la concepcin y manipulacin de la base de datos por parte de los usuarios. -Sencillez: las caractersticas anteriores, as como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender y de utilizar por parte del usuario final.

Un Sistema Gestor de Bases de Datos es una herramienta software que permite la creacin y manipulacin de bases de datos. Para ello, debe tener un Lenguaje de Definicin de Datos

(LDD) que, habitualmente, ser el estndar SQL. Iremos viendo algunos ejemplos de casos concretos en SQL.

Desde mediados de los aos 80, el modelo relacional es utilizado por prcticamente la totalidad de los SGBD comerciales: -Algunas de las principales empresas informticas del mundo, son en origen, empresas fabricantes de SGBDs relacionales: ORACLE, Sybase, INFORMIX, etc. -Existen grandes fabricantes de hardware y software que tienen su SGBD relacional: IBM: DB2, Microsoft: SQL Server, etc. -Existen SGBDs diseados para PCs y usuarios no expertos: Microsoft Access, etc.

El modelo relacional incluye tres aspectos muy importantes: -Estructuras: Las estructuras son objetos bien definidos (tales como tablas, vistas, ndices y otros) que almacenan o acceden a datos de una base de datos. Las estructuras y los datos de ellas pueden ser manipulados por operaciones. -Operaciones: Son acciones definidas claramente que permiten a los usuarios manipular los datos y estructuras de una base de datos. Las operaciones en una base de datos se deben adherir a un conjunto predefinido de reglas de integridad. -Reglas de integridad: Las reglas de integridad son las leyes que gobiernan cuales operaciones son permitidas sobre los datos y las estructuras de una base de datos. Las reglas de integridad protegen los datos y las estructuras de una base de datos.

Con respecto a la parte dinmica del modelo, se proponen un conjunto de operadores que se aplican a las relaciones. Todos ellos conforman el lgebra Relacional.

En lo que respecta a la estructura, el modelo relacional representa a una base de datos como una coleccin de relaciones, es decir, un conjunto de tablas formadas por filas y columnas. Cada fila representa un conjunto de datos relacionados entre s. Dichos valores pueden referirse a un conjunto de hechos que describen a una entidad o bien a un vnculo entre entidades. Por ejemplo, podemos tener una fila de una tabla que incorpore datos de los empleados para cada uno de los empleados de una empresa. Las columnas representan las propiedades de cada una de las filas de la tabla. Por ejemplo, en una tabla que contenga informacin de empleados podemos tener columnas como DNI y Nombre para describir distintas caractersticas o propiedades de los empleados. El nombre de la tabla y los nombres de las columnas ayudan a interpretar el significado de los valores que estn en cada una de las filas de la tabla. Por tanto, una base de

datos relacional sera un conjunto de tablas con nombres nicos, en los que las filas representan hechos y las columnas representan propiedades. Todos los datos de la base de datos se representan en forma de relaciones cuyo contenido vara en el tiempo.

En la terminologa formal del modelo relacional, una fila se denomina tupla, una cabecera de columnas es un atributo y la tabla se denomina relacin. El tipo de datos que describe los tipos de valores que pueden aparecer en cada columna se llama dominio. Vemos estos conceptos ms detalladamente.

Conceptos previos

-Un dominio D es un conjunto finito de valores homogneos y atmicos caracterizados por un nombre; decimos homogneos porque son todos del mismo tipo y atmicos porque son indivisibles. Todo dominio ha de tener un nombre por el cual nos podamos referir a l y un tipo de datos; as el tipo de datos del dominio "nacionalidades" es una tira de caracteres de longitud 10. El dominio "nacionalidades" tiene valores : Espaa, Francia,... Si descompusiramos Espaa en E,s,p,... perdera la semntica. Ejemplos de dominios seran: Colores: Es el conjunto de los colores D={rojo, verde, azul,} Nmeros de DNI: Es conjunto de nmeros del DNI vlidos, formados por ocho dgitos. Edad: Edades posibles de los empleados entre 18 y 80 aos.

-Un atributo es el papel que tiene un determinado dominio en una relacin. Es muy usual dar el mismo nombre al atributo y al dominio. En el caso de que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habr que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre.

Por ejemplo los atributos edad_fsica y edad_mental pueden estar definidos sobre el mismo dominio edad; o los atributos precio_compra y precio_venta pueden estar definidos sobre el mismo dominio de enteros de longitud 5.

Adems de los dominios y atributos simples que acabamos de definir, en los ltimos trabajos de algunos autores [Codd (1990), Date (1990)] se introduce el concepto de dominio compuesto.

-Un dominio compuesto se puede definir como una combinacin de dominios simples que tiene un nombre y a la que se pueden aplicar ciertas restricciones de integridad. Por ejemplo, un usuario puede necesitar manejar, adems de los tres dominios Da, Mes y Ao, un dominio compuesto denominado Fecha que sera la combinacin de los tres primeros, y al que podramos aplicar las adecuadas restricciones de integridad a fin de que no aparecieran valores no vlidos para la fecha; algo anlogo ocurre Con el nombre y los apellidos, que, segn las aplicaciones, puede ser conveniente tratarlos en conjunto o por separado. De la misma forma, es posible definir un atributo compuesto Fecha que tomara sus valores del dominio compuesto de igual nombre.

-Un esquema de relacin R se denotar por R(A1, A2, ..., An), y se compone de un nombre de relacin R y una lista de atributos A1, A2, ..., An. Cada atributo Ai es el nombre del papel desempeado por algn dominio D en el esquema de relacin R. Se dice que D es el dominio de Ai, y se denota por dom(Ai). Un esquema de relacin sirve para describir una relacin. El grado de una relacin es el nmero de atributos n de su esquema de relacin. Por ejemplo, esquema de relacin para una relacin de grado 3 que describe a los clientes de un banco: Clientes (nombreCli, dniCli, domicilio)

-Una relacin del esquema de relacin R(A1, A2, ..., An), denotada tambin por r(R), es un conjunto de n-tuplas r = { t1, t2, ..., tn }. Cada n-tupla t es una lista de n valores ordenados t= donde cada vi es un elemento de dom(Ai), o un valor nulo especial. El i-simo valor de la tupla t, que se corresponde con el atributo Ai, se referencia como t[Ai]. Una relacin tambin puede plantearse como una relacin matemtica de grado n sobre los dominios dom(A1), dom(A2) ... dom(An), que es un subconjunto del producto cartesiano de los dominios de R: r(R) (dom(A1) x dom(A2) x ... x dom(An)) El producto cartesiano especifica todas las combinaciones posibles de valores de los dominios, y el estado actual de la relacin refleja slo las tuplas vlidas en ese momento. Los atributos

reflejan los papeles o interpretaciones de cada dominio, y puede haber varios atributos de una relacin definidos sobre el mismo dominio. Caractersticas de las relaciones: -No existe orden entre las tuplas, aunque lgicamente se almacenen y se visualicen en un cierto orden, pero ese orden puede variar sin que suponga alterar la relacin. -No existe orden entre los atributos y, por tanto, puede cambiarse el orden sin que suponga un cambio a la relacin. Por comodidad suele suponerse un orden en los atributos y as se representarn los valores de las tuplas en ese orden. -Primera Forma Normal: Los valores son atmicos o indivisibles. Valores compuestos o multivaluados no son permitidos. Atributos Compuestos: Se representan slo sus componentes simples. Atributos Multivaluados: Se representa cada atributo multivaluado en una relacin separada. Dicha relacin almacenar todos los valores. Interpretacin de una Relacin: a) El esquema de una relacin es un aserto o afirmacin que indica los atributos del objeto (entidad o relacin) que representa la relacin. b) Cada tupla es un hecho o instancia de ese objeto, que puede representarse como un predicado. -TRANSACCIN: Conjunto de operaciones de una aplicacin de Bases de Datos que se efectan como una nica operacin lgica. Propiedades: Atomicidad: Una transaccin se considera como una nica operacin lgica, aunque est formada por varias operaciones ms simples. Debe controlarse que una transaccin no sea ejecutada a medias. Una transaccin, o se ejecuta completamente o no se ejecuta. Consistencia: Antes y despus de cada transaccin, la BD debe tener valores lgicos, aceptables o consistentes. Si se produce un fallo del sistema en medio de la transaccin, se deben anular las primeras operaciones de la transaccin ya efectuadas: Los valores de la BD deben ser consistentes. La consistencia de la BD debe asegurarse incluso aunque varias transacciones se efecten concurrentemente. Durabilidad: Tras una transaccin, los nuevos valores de la BD deben mantenerse a pesar de cualquier tipo de fallo del sistema.

- Un esquema de base de datos relacional S es un conjunto de esquemas de relaciones S = {R1, R2, ..., Rn} y un conjunto de restricciones de integridad RI. Un estado o instancia de una base de datos relacional BD de S es un conjunto de estados de relaciones BD = {r1, r2, ...,rm}, en el que cada ri es un estado de Ri y los estados de relaciones satisfacen las restricciones de integridad especificadas en RI. Los atributos que representan el mismo concepto del mundo real pueden tener o no el mismo nombre en relaciones distintas, y viceversa. Los esquemas de bases de datos se representan mediante tablas: lista de valores con un nombre, donde cada valor es una fila (registro), compuesto por 1 o ms columnas (campos). Fila o Tupla (row, tuple): Hecho que corresponde a una entidad o relacin en el mundo real. Sin repeticiones. Columna o Atributo (column, attribute): Valor relacionado con ese hecho, sobre un aspecto particular. Todos los valores de una columna son del mismo tipo o dominio. Los valores (y el dominio) deben ser atmicos o indivisibles (como informacin). Ejemplos: Nmeros naturales, reales, cadenas de caracteres... Formato: Forma de representar un dato. Ej: Tlfno: +34 999-99-99-99.

La definicin y los tipos de claves los veremos cuando abordemos los tipos de restricciones relativas a estos conceptos.

El problema de la integridad en las bases de datos

En el mundo real existen ciertas restricciones que deben cumplir los elementos en l existentes; por ejemplo, una persona slo puede tener un nmero de DNI y una nica direccin oficial. Cuando se disea una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es lo mismo, reflejar las restricciones existentes en el mundo real. Los componentes de una restriccin son los siguientes: -La operacin de actualizacin (insercin, borrado o eliminacin) cuya ejecucin ha de dar lugar a la comprobacin del cumplimiento de la restriccin. -La condicin que debe cumplirse, la cual es en general una proposicin lgica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso). -La accin que debe llevarse a cabo dependiendo del resultado de la condicin.

Toda instalacin debe garantizar la integridad de la informacin que almacena en todo instante de se historia. Se refiere a la exactitud o correccin de los datos en la base de datos. Esta integridad de los datos es ms importante en un sistema de base de datos que en un entorno de archivos privados porque los datos son compartidos. Por ello, los guardados en el sistema deben de estar protegidos contra los accesos no autorizados, de la destruccin o alteracin malintencionada y de la introduccin accidental de inconsistencias. El mal uso de la base de datos puede clasificarse como malintencionada (con premeditacin) o accidental. La prdida accidental de la consistencia de los datos puede ser resultado de: -Cadas durante el procesamiento de transacciones -Anomalas causadas por el acceso concurrente a la base de datos -Anomalas causadas por la distribucin de datos entre varias computadoras -Errores lgicos que violan la suposicin de que las transacciones conservan las ligaduras de consistencia de la base de datos. Es mas sencilla la proteccin contra la perdida accidental de la consistencia de los datos que la proteccin contra el acceso mal intencionado a la base de datos. Entre las formas de acceso malintencionado se encuentra: -La lectura no autorizada de los datos (robo de informacin) -La modificacin no autorizada de los datos -La destruccin no autorizada de los datos. Adems de proteger los datos contra posibles problemas sistemticos, deben incluirse tambin procedimientos de chequeo que aseguren que los valores de los datos se ajustan a ciertas reglas prescritas de antemano. Estas pruebas podrn hacerse verificando las relaciones que existen entre varios valores de datos. Por tanto, definimos integridad como la accin de conservar la seguridad en un sistema en el que se permite acceso a mltiples usuarios y compartir la base de datos. Tiene como funcin proteger el sistema contra operaciones que introduzcan inconsistencias en los datos. El control centralizado de la base de datos puede ayudar a evitar estos problemas (en la medida de lo posible) permitiendo que el administrador de datos defina las restricciones de integridad, que sern verificadas siempre que se realice una operacin de actualizacin. Las restricciones de integridad se especifican en el esquema de una base de datos, y proporcionan un medio de asegurar que los cambios que en ella se hacen por usuarios autorizados no resultan en una prdida de consistencia de los datos. As pues, las restricciones de integridad protegen la base de datos contra daos accidentales, ya que sin los controles apropiados sera posible que un usuario actualizara la base de datos de forma incorrecta, generando as datos malos e infectando a otros usuarios con esos datos.

Desafortunadamente, la mayora de los productos de bases de datos de hoy da son mas bien dbiles con respecto al manejo de las restricciones de integridad. Es por ello que la solidez de nuestro sistema viene en gran parte determinado por el cumplimiento de estas restricciones, cuya definicin cobra gran importancia en un diseo de base da datos relacional. Distinguimos entre restricciones inherentes y semnticas: -Restricciones inherentes. Adems de las derivadas del concepto de "relacin" como eran que: no hay dos tuplas iguales, el orden de las tuplas no es significativo, el orden de los atributos (columnas) no es significativo, cada atributo slo puede tomar un nico valor del dominio, no admitindose por tanto los grupos repetitivos; destaca la regla de integridad de entidad. -Restricciones de semnticas. Tambin llamadas restricciones de usuario, son facilidades que el modelo ofrece a los usuarios con el fin de que estos puedan reflejar en el esquema, la semntica del mundo real. Aqu tenemos la restriccin de integridad referencial, clave primaria, unicidad, existencia (valor no nulo), verificacin, asercin y disparadores.

Otra clasificacin, distingue entre las restricciones de estado, que definen las restricciones que debe satisfacer un estado vlido de la base de datos; y las llamadas restricciones de transicin, definidas para tratar con cambios de estado de la base de datos ("el sueldo de un empleado slo puede incrementarse"). Esto nos lleva al concepto de bases de datos activa. Estas restricciones se especifican con reglas de actividad y disparadores. Otros tipos de restricciones, llamadas dependencias de los datos (que incluyen las dependencias funcionales y las dependencias multivaluadas) se utilizan principalmente para el diseo de bases de datos por normalizacin (no lo veremos).

He intentado agrupar los conceptos en funcin de su relevancia y segn la relacin que presentan, e introduciendo ejemplos de manera que la exposicin sea lo ms clara posible.

Restricciones de dominio. Unicidad y valor NuloEl principio que hay detrs de los dominios de atributo es similar al que hay detrs de la asignacin de tipos a variables en los lenguajes de programacin. Los lenguajes de programacin fuertemente tipados permiten que el compilador compruebe el programa con mayor detalle. Sin embargo, los lenguajes fuertemente tipados impiden " cortes inteligentes" que a menudo son requeridos en la programacin de sistemas. Puesto que los sistemas de base de datos son diseados para soportar usuarios que nos son expertos en computadores a menudo los beneficios de los lenguajes fuertemente tipados pasan ms que las desventajas. No obstante

existen muchos sistemas que permiten solamente un nmero pequeo de tipos de dominios. Los sistemas ms nuevos particularmente los sistemas de base de datos orientados a objetos, ofrecen un conjunto rico de tipos de dominio que puede ser ampliado fcilmente.

Al definir cada atributo sobre un dominio se impone una restriccin sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios: Las restricciones de dominio especifican que el valor de cada atributo debe ser un valor atmico de su dominio. Los lmites de dominios son la forma ms elemental de restricciones de integridad. Son fciles de probar por el sistema siempre que se introduce un nuevo dato en la base de datos. Una definicin adecuada de las restricciones de los dominios no slo permite verificar los valores introducidos en la base de datos, sino tambin examinar las consultas para asegurarse de que tengan sentido las comparaciones que hagan. Por ejemplo, normalmente no se considerar que la consulta Hallar todos los clientes que tengan el nombre de una sucursal tenga sentido. Por tanto, nombre-cliente y nombre-sucursal deben tener dominios diferentes.

La clusula check de SQL:1999 permite restringir los dominios de maneras poderosas que no permiten la mayor parte de los sistemas de tipos de los lenguajes de programacin. La clusula check permite especificar un predicado que debe satisfacer cualquier valor asignado a una variable cuyo tipo sea el dominio. Por ejemplo: create domain sueldo-por-hora numeric(4,2) **num_cifras=4 ; num_decimales=2** constraint comprobacin-valor-sueldo check(value 6.00)

Los tipos de datos asociados a los dominios suelen incluir los tipos numricos estndar para enteros y reales, as como caracteres y cadenas de longitud fija y variable, fecha, hora, marca de tiempo y dinero. Tambin pueden especificarse intervalos o conjuntos explcitos de valores permitidos. Adicionalmente, se puede definir el valor nulo como una marca utilizada para representar informacin desconocida. La necesidad de valores nulos es evidente por diversas razones: -Existencia de tuplas con ciertos atributos desconocidos en ese momento.

-Necesidad de aadir un nuevo atributo a una tabla ya existente; atributo que en el momento de introducirse no tendr ningn valor para las tuplas de la relacin. -Posibilidad de atributos inaplicables a ciertas tuplas, como la editorial para un artculo.

Vemos un par de restricciones que se pueden definir para cualquier dominio y que nos dan pie al siguiente apartado:

Restricciones de existencia Dentro de las restricciones de los dominios, un tipo especial de restriccin que se puede aplicar a cualquier dominio es la restriccin de existencia. Esta restriccin evita la aparicin de valores nulos en las columnas: Dado un conjunto de atributos K de R (K se dice que R satisface una restriccin de ) valor no nulo sobre K si se cumple la siguiente propiedad: t ( t R Ai K y t(Ai) tiene valor nulo) en caso contrario R viola esta restriccin. El SQL estndar permite que la declaracin del dominio de un atributo incluya la especificacin not null. Esto prohibe la insercin de un valor nulo para este atributo. Cualquier modificacin de la base de datos que causara que se insertase un valor nulo en un dominio not null genera un diagnstico de error.

Restricciones de unicidad Otro tipo especial de restriccin que se puede aplicar a cualquier dominio es la restriccin de unicidad. Esta restriccin evita la aparicin de valores duplicados en las columnas. Por ejemplo: Slo se admite una sucursal en cada ciudad. En SQL, se puede utilizar restricciones unique para garantizar que no se escriben valores duplicados en columnas especficas que no forman parte de una clave principal.

Restricciones en la clave. Integridad de entidadesSabemos que no puede haber dos tuplas que tengan la misma combinacin de valores para todos sus atributos. Por tanto, vemos que existen subconjuntos de atributos de un esquema de relacin R con la propiedad de que no debe haber dos tuplas en un estado de relacin r de R con

la misma combinacin de valores para estos atributos. Este conjunto de atributos se denomina superclave, y especifica una restriccin de unicidad: Se tiene que cumplir que en una relacin R, si t1 y t2 son dos tuplas distintas de R, y K es el conjunto de atributos que forman la superclave, t1[K] t2[K]. Toda relacin tiene por lo menos una superclave: el conjunto de todos sus atributos. Sin embargo, una superclave puede tener atributos redundantes, as que un concepto ms til es el de clave: Una clave K de un esquema de relacin R es una superclave de R con la propiedad adicional de que la eliminacin de cualquier atributo A de K deja un conjunto de atributos K que no es superclave de R. Decimos que una clave es una superclave mnima. Normalmente, un esquema de relacin tendr ms de una clave, denominadas claves candidatas. Designamos a una de las claves candidatas como clave primaria de la relacin subrayando los atributos que la forman, denominados atributos primos. La clave de una relacin se determina a partir del significado de los atributos (escogeremos, en la medida de lo posible, la que menos tenga), y es una propiedad que no vara con el tiempo; debe seguir siendo vlida aunque insertemos tuplas nuevas en la relacin. Todas la relaciones que forman el esquema de una base de datos relacional tienen que tener definida una clave primaria. Sea R una relacin, se dice que R satisface la restriccin de clave primaria si: R satisface la restriccin de unicidad sobre su clave primaria, R satisface la restriccin de valor no nulo sobre su clave primaria, en caso contrario R viola esta restriccin. Esta es una de las restricciones ms importantes en una base de datos relacional, ya que con ello alcanzamos varios objetivos: -El modelo asegura que cada una de las tuplas ser distinta del resto al exigir una clave primaria. -Permite la creacin de ndices y ordenar la tabla en funcin de dicha clave primaria con vistas a la optimizacin de las consultas. -Facilita el modelado de relaciones entre tablas mediante el mecanismo da clave externa, que ser un atributo en otra tabla cuyo contenido referencia a alguna tupla de sta (integridad referencial). La restriccin de integridad de entidades establece que ningn valor de clave primaria puede ser nulo, entendiendo por entidad un objeto del mundo real distinguible de otros objetos.

En el caso de las claves primarias compuestas, la regla de integridad de entidades dice que cada valor individual de la clave primaria debe ser no nulo en su totalidad. Esta regla se aplica solo a las claves primarias, en las claves alternativas se podrn permitir nulos. La justificacin de la regla de integridad de las entidades es la siguiente: -Las relaciones base corresponden a entidades del mundo real -Por definicin, las entidades en el mundo real son distinguibles; es decir, se les puede identificar de alguna manera. -Los representantes de entidades dentro de la base de datos deben ser distinguibles tambin. -Las Claves primarias realizan esta funcin de identificacin nica en el modelo relacional. -Si tiene valor nulo y este significa "la propiedad no es aplicable", esa tupla no tiene sentido. -Si significa "el valor se desconoce", surge todo tipo de problemas. -Una entidad sin identidad es una contradiccin de trminos: no existe. -Podemos emplear argumentos anlogos a los anteriores para demostrar la necesidad de prohibir valores de la clave-primaria parcialmente nulos.

Las restricciones de clave y de integridad de entidades se especifican sobre relaciones individuales.

-Restriccin PRIMARY KEY en SQL: Cuando especifica una restriccin PRIMARY KEY en una tabla, se exige la unicidad de los datos mediante la creacin de un ndice nico para las columnas de clave principal. Este ndice tambin permite un acceso rpido a los datos cuando se utiliza la clave principal en las consultas. De esta forma, las claves principales que se eligen deben seguir las reglas para crear ndices nicos. Si se define una restriccin PRIMARY KEY para ms de una columna, puede haber valores duplicados dentro de la misma columna, pero cada combinacin de valores de todas las columnas de la definicin de la restriccin PRIMARY KEY debe ser nica. Ejemplo:

Cuando trabaja con combinaciones, las restricciones PRIMARY KEY relacionan una tabla con otra. Este concepto de relacin nos lleva al siguiente apartado.

Integridad referencial y claves externas

La integridad referencial es un sistema de reglas que utilizan la mayora de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son vlidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Es una restriccin de comportamiento, ya que viene impuesta por el mundo real y es el usuario quien la define al describir el esquema relacional; es tambin de tipo implcito, ya que se define en el esquema y el modelo la reconoce (o as algunos productos) sin necesidad de que se programe ni de que se tenga que escribir ningn procedimiento para obligar a que se cumpla. Se especifica entre dos relaciones, y asegura que un valor que aparece en una relacin para un conjunto de atributos determinado aparezca tambin en otra relacin para un cierto conjunto de atributos; es decir, que si B hace referencia a A, entonces A debe existir. Definimos el concepto de clave externa. Un conjunto de atributos CE del esquema de la relacin R1 es una clave externa de R1 si satisface estas condiciones: - Los atributos de CE tienen el mismo dominio que los atributos de la clave primaria CP de otro esquema de relacin R2; se dice que los atributos CE hacen referencia o se refieren a la relacin R2. -Un valor de CE en una tupla t1 del estado actual de R1 es el valor de CP en alguna tupla t2 del estado actual de R2, o bin es nulo. Si no es nulo, diremos que la tupla t1 hace referencia a la tupla t2. R1 ser la relacin referenciante, y R2 la relacin referenciada.

Bsicamente, mantener la integridad referencial significa que todos los valores de claves externas almacenados en la tabla deben corresponder a un registro correlacionado en la tabla que tiene esta clave externa como clave primaria. En una base de datos con muchas relaciones, suele haber muchas restricciones de integridad referencial, ya que surgen de las relaciones representadas entre las entidades representadas por los esquemas de relacin. Una clave externa tambin puede hacer referencia a su propia relacin (caso de supervisor y empleado). Otra fuente de restricciones de integridad son los conjuntos de entidades dbiles: entidades dependientes de otras, que especifican determinados atributos complementarios a estas. El esquema de la relacin de cada conjunto de entidades dbiles incluye una clave externa, lo que lleva a una restriccin de integridad referencial. La integridad referencial hace que el SGBD se asegure de que no haya en las claves externas valores que no estn en la tabla principal; por ello, se activa en cuanto creamos una clave

externa y a partir de ese momento se comprueba cada vez que se modifiquen datos que puedan alterarla. La verdadera eficacia de una base relacional es su capacidad de combinar claves primarias y externas para establecer relaciones entre las tablas de datos. Vemos los tipos de relaciones:

-Relacin Uno a Uno: Cuando un registro de una tabla slo puede estar relacionado con un nico registro de la otra tabla y viceversa. Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qu profesor es jefe de qu departamento, tenemos una relacin uno a uno entre las dos tablas ya que un departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento. -Relacin Uno a Varios: Cuando un registro de una tabla (tabla secundaria) slo puede estar relacionado con un nico registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener ms de un registro relacionado en la tabla secundaria, en este caso se suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla secundaria como tabla 'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un padre (regla ms fcil de recordar). Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una poblacin puede tener ms de un habitante, pero un habitante pertenecer (estar empadronado) en una nica poblacin. En este caso la tabla principal ser la de poblaciones y la tabla secundaria ser la de habitantes. Una poblacin puede tener varios habitantes pero un habitante pertenece a una sola poblacin. Esta relacin se representa incluyendo en la tabla 'hijo' una columna que se corresponde con la clave principal de la tabla 'padre'. Por tanto, en la tabla habitantes tenemos una columna poblacin que contiene el cdigo de la poblacin en la que est empadronado el habitante, esta columna es clave externa de la tabla habitantes, y en la tabla poblaciones tenemos una columna cdigo de poblacin clave principal de la tabla. -Relacin Varios a Varios: Cuando un registro de una tabla puede estar relacionado con ms de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar relacionadas directamente, se tiene que aadir una tabla entre las dos que incluya los pares de valores relacionados entre s. Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artculos que se venden en la empresa, un cliente podr realizar un pedido con varios artculos, y un artculo podr ser vendido a ms de un cliente. No se puede definir entre clientes y artculos, hace falta otra tabla (por ejemplo una tabla de pedidos) relacionada con clientes y con artculos. La tabla pedidos estar relacionada con cliente

por una relacin uno a muchos y tambin estar relacionada con artculos por un relacin uno a muchos.

Asociada a la integridad referencial estn los conceptos de actualizar los registros en cascada y eliminar registros en cascada. Si hay una cadena de dependencias de claves externas entre varias relaciones, un borrado o una actualizacin en uno de sus extremos puede propagarse por toda la cadena, de ah la denominacin de actualizaciones o borrados en cascada. El actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la clave externa y que le indican al sistema gestor qu hacer en los casos de violacin de restricciones de integridad referencial: -Actualizar registros en cascada: Esta opcin le indica al sistema gestor de la base de datos que cuando se cambie un valor del campo clave de la tabla principal, automticamente cambiar el valor de la clave externa de los registros relacionados en la tabla secundaria. Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10 en el campo cdigo (la clave principal), automticamente se actualizan todos los habitantes (en la tabla secundaria) que tienen el valor 1 en el campo poblacin (en la clave externa) dejando 10 en vez de 1.Si no se tiene definida esta opcin, no se puede cambiar los valores de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor 1 del cdigo de la tabla de poblaciones, no se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han podido modificar por infracciones de clave. -Eliminar registros en cascada: Esta opcin le indica al sistema gestor de la base de datos que cuando se elimina un registro de la tabla principal automticamente se borran tambin los registros relacionados en la tabla secundaria. Por ejemplo: Si borramos la poblacin Onteniente en la tabla de poblaciones, automticamente todos los habitantes de Onteniente se borrarn de la tabla de habitantes. Si una actualizacin de borrado en cascada crea una violacin de la restriccin que no puede resolverse mediante una nueva operacin en cascada, el sistema aborta la transaccin. En consecuencia, se deshacen todas las modificaciones generadas por la transaccin y por sus acciones en cascada. Las transacciones pueden consistir en varios pasos, y las restricciones de integridad se pueden violar temporalmente dentro de una transaccin. Las restricciones de integridad se comprueban slo al final de la transaccin, no en los pasos intermedios.

Las claves externas pueden especificarse como parte de la instruccin create table de SQL usando la clusula foreign key, que adems puede especificar las acciones a tomar para

restaurar la integridad referencial. SQL tambin soporta una versin de la clusula references, donde se puede especificar explcitamente una lista de atributos de la relacin referenciada. La clusula on delete cascade asociada con la declaracin de la clave externa, provoca que el borrado se realice en cascada. La clusula on update cascade, de forma similar realiza una actualizacin en cascada, si se modifica la clave primaria. Vemos la sintaxis de las clusulas hasta ahora vistas en un breve ejemplo de uso de SQL en el siguiente apartado.

Integridad referencial en SQL

Como ya sabemos, las claves primarias y las claves externas se pueden especificar como parte de la instruccin create table de SQL: la clusula primary key de la instruccin create table incluye una lista de los atributos que comprende la clave primaria; y la clusula foreign key de la instruccin create table incluye una lista de los atributos que comprende la clave externa y el nombre de la relacin a la que hace referencia mediante la clave externa. Ejemplo:

create table cliente (nombre-cliente char(20), calle-cliente ciudad-cliente char(30), char(30),

primary key (nombre-cliente)) create table sucursal (nombre-sucursal char(15), ciudad-sucursal activo integer, primary key (nombre-sucursal)) create table cuenta (nmero-cuenta char(10), nombre-sucursal char(15), saldo integer, char(30),

primary key (nmero-cuenta), ... foreign key (nombre-sucursal) references sucursal

on delete cascade on update cascade ...) create table impositor (nombre-cliente char(20), nmero-cuenta char(10), primary key (nombre-cliente, nmero-cuenta), foreign key (nombre-cliente) references cliente, foreign key (nmero-cuenta) references cuenta)

Operaciones de actualizacin y tratamiento de las violaciones de restriccin

Las operaciones del modelo relacional pueden clasificarse en recuperaciones y actualizaciones. Vamos a ver las operaciones de actualizacin bsicas, que son tres: Insertar (insertar una o ms tuplas nuevas en una relacin), Eliminar (elimina tuplas en una relacin) y Actualizar (modifica los valores de algunos atributos de tuplas existentes). Cuando se realizan estas operaciones, no se deben violar las restricciones de integridad. Vemos los tipos de operaciones:

-Insertar: Para insertar datos en una relacin, bien especificamos la lista de valores de la tupla que se va a insertar o escribimos una consulta cuyo resultado sea el conjunto de tuplas que se va a insertar. Ejemplo: Para insertar una nueva transaccin en la cuenta 6 de 700 realizada el 7-11-2003, escribiramos lo siguiente: Insertar < "6", 2, "7-11-2003", 700> en transacciones. Al insertar, puede violarse una restriccin de dominio si se proporciona un valor de atributo que no pertenece al dominio correspondiente. Tambin puede violarse una restriccin de clave si la clave de la nueva tupla ya existe en la relacin. La integridad de entidades puede violarse si la clave primaria de la nueva tupla es nula. Y la integridad referencial puede violarse si el valor de cualquier clave externa de la nueva tupla hace referencia a una tupla que no existe en la relacin referenciada. Cuando una insercin viola una o ms restricciones, la opcin predeterminada es rechazar la insercin.

-Eliminar: La operacin Eliminar slo puede violar restricciones de integridad referencial, cuando las claves externas de otras tuplas de la base de datos hacen referencia a la tupla que se va a eliminar. Para especificar la informacin a eliminar, se expresa una condicin en trminos de los atributos de la relacin correspondiente. Por ejemplo, para eliminar todas las transacciones de la cuenta nmero 1 escribiramos: Eliminar en transacciones las tuplas con numeroCta=1 Podemos optar por distintas soluciones ante una violacin de esta tipo. La opcin seleccionada en cada caso debe poder especificarse tambin en el esquema de la base de datos.

Vemos las opciones que implementa un SGBD:

a) Operacin restringida: esto es, el borrado de tuplas de la relacin que contiene laclave primaria referenciada; slo se permite si no existen tuplas con dicha clave en la relacin que contiene la clave externa. Esto nos llevara, por ejemplo, a que para poder borrar una editorial de nuestra base de datos no tendra que haber ningn libro que estuviese publicado por dicha editorial, en caso contrario el sistema impedira el borrado.

b) Operacin con transmisin en cascada: esto es, el borrado de tuplas de la relacinque contiene la clave primaria referenciada lleva consigo el borrado en cascada de las tuplas de la relacin que contienen la clave externa. Ya vimos en qu consistan las operaciones en cascada.

c) Operacin con puesta a nulos: el borrado de tuplas de la relacin que contiene laclave primaria referenciada lleva consigo poner a nulos los valores de las claves externas de la relacin que referencia. Esta opcin, obviamente, slo es posible cuando el atributo que es clave externa admite el valor nulo.

d) Operacin con puesta a valor por defecto: el borrado de tuplas de la relacin quecontiene la clave primaria referenciada lleva consigo poner el valor por defecto a la clave externa de la relacin que referencia.

e) Operacin que desencadena un procedimiento de usuario: en este caso, elborrado de tuplas de la tabla referenciada pone en marcha un procedimiento definido por el usuario.

-Actualizar: La operacin Actualizar modifica los valores de uno o ms atributos de una o ms tuplas de una relacin. Es necesario especificar una condicin sobre los atributos de la relacin para seleccionar la tupla o tuplas a modificar. Por ejemplo, para cambiar el domicilio del cliente con dniCli 1 a C/Real n 14, escribiramos: Actualizar domicilio de clientes con dniCli = "1". La actualizacin de un atributo que no es clave primaria ni clave externa no suele dar problemas (excepto de dominio). Modificar un valor de la clave primaria es similar a eliminar una tupla e insertar otra en su lugar, por lo que pueden darse los problemas vistos para inserciones y eliminaciones. Aplicaremos, por tanto, alguno de los mecanismos que hemos visto. Si se modifica un atributo de una clave externa, hay que comprobar que el nuevo valor existe en la relacin referenciada (o es nulo).

Ejemplo

Se desea almacenar informacin sobre alumnos universitarios: a) Para cada alumno hay que almacenar la provincia donde reside. b) Cada alumno puede estar matriculado en varias facultades pertenecientes a distintas universidades. c) Hay que almacenar el curso de inicio de estudios de un alumno en cada facultad en las que est matriculado. d) Las facultades se numeran correlativamente para cada universidad. e) Las facultades pueden pertenecer a distintas universidades. f) Una universidad puede ser pblica o privada.

Tendremos, por tanto, las entidades ALUMNO, PROVINCIA, FACULTAD y UNIVERSIDAD; ms ALUMNO_FACULTAD derivada de la relacin varios a varios que existe entre las anteriores.

RESTRICCIONES EN EL EJEMPLO

Restricciones de dominio (suponiendo unos dominios cualesquiera): -El atributo ALUMNO.dni solo puede tomar valores numricos enteros de 8 cifras. -El atributo ALUMNO.edad solo puede tomar valores numricos enteros de 2 cifras, mayores que 15. -El atributo UNIVERSIDAD.tipo solo puede tomar uno de dos valores posibles: 1 (pblica) o 2 (privada). -El atributo FACULTAD.num_cursos solo puede tomar un valor numrico entero en el intervalo [4,6]. -El atributo ALUMNO_FACULTAD.curso_inicio solo puede tomar valores numricos no menores que 1998.

Integridad de clave: -El atributo ALUMNO.dni no puede tomar valor nulo. -El atributo PROVINCIA.cod_prov no puede tomar valor nulo. -El atributo PROVINCIA.nombre no puede tomar valor nulo. Adems, no puede tomar valores repetidos. -El atributo UNIVERSIDAD.cod_univ no puede tomar valor nulo. -El atributo FACULTAD.cod_univ no puede tomar valor nulo. -El atributo FACULTAD.cod_fac no puede tomar valor nulo. -El atributo ALUMNO_FACULTAD.dni no puede tomar valor nulo. -El atributo ALUMNO_FACULTAD.cod_univ no puede tomar valor nulo. -El atributo ALUMNO_FACULTAD.cod_fac no puede tomar valor nulo.

Integridad referencial: -El atributo ALUMNO.cod_prov siempre debe tener un valor que se encuentre en PROVINCIA.cod_prov, o bien ser nulo (p.e. si se desconoce la provincia donde vive un alumno). -El atributo FACULTAD.cod_univ siempre debe tener un valor que se encuentre en UNIVERSIDAD.cod_univ. Adems, no puede ser nulo por la restriccin de integridad de clave. -El atributo ALUMNO_FACULTAD.dni siempre debe tener un valor que se encuentre en ALUMNO.dni. Adems, no puede ser nulo por la restriccin de integridad de clave. -La agregacin de los atributos ALUMNO_FACULTAD.cod_univ y ALUMNO_FACULTAD.cod_fac siempre debe tener un valor que se encuentre en la agregacin de los atributos FACULTAD.cod_univ y FACULTAD.cod_fac. No vale cada atributo por separado.

PROBLEMAS CON LAS RESTRICCIONES DURANTE LAS OPERACIONES

1.Insercin: Insercin de una nueva tupla en una tabla. -Solo se puede insertar una tupla si todos los atributos de la clave primaria tienen valor no nulo. Ejemplo: No se puede insertar un alumno con dni nulo. -Solo se puede insertar una tupla si la agregacin de todos los atributos que forman la clave primaria toma un valor nico e indito hasta el momento en la tabla. Ejemplo: No se puede insertar una nueva provincia si ya existe su cod_prov en la tabla. -Solo se puede insertar una tupla si todos los atributos que son claves externas de otras tablas toman valores ya presentes en dichas tablas o bien nulos. Ejemplo: No se puede insertar una nueva facultad si no existe previamente la universidad a la que pertenece. Opcin alternativa: Antes de dar por vlida la insercin de la nueva facultad, se obliga al usuario a introducir los datos correctos de la nueva universidad. -Solo se puede insertar una tupla si los valores de los atributos satisfacen todas las restricciones adicionales que pudieran concernirles. Ejemplo: No se puede insertar una nueva universidad cuyo atributo tipo tome el valor 7.

2.Modificacin: Modificacin del valor de algn atributo de una o varias tuplas de una tabla. -Si el atributo a modificar es primo, su valor no puede modificarse a nulo. Ejemplo: No puede cambiarse el valor del atributo cod_univ a nulo. -Si el atributo a modificar es primo, su valor no puede modificarse a otro tal que la agregacin de todos los atributos que forman la clave primaria no tome un valor nico e indito en la tabla. Ejemplo: No puede modificarse el dni de un alumno a un nuevo valor que ya existiera en la tabla. -Solo se puede modificar el valor de un atributo si el nuevo valor satisface todas las restricciones adicionales que pudieran afectarle. Ejemplo: No puede modificarse la edad de un alumno si la nueva edad es menor o igual que 15. -Si el atributo a modificar es parte de una clave externa en otra tabla, entonces hay que modificar automticamente el viejo valor que tomaba en dicha tabla por el nuevo valor. Ejemplo: Si se modifica el valor previo V1 del atributo cod_prov de la tabla PROVINCIA a un

nuevo valor V2, entonces el atributo cod_prov de todas las tuplas de la tabla ALUMNO cuyo valor fuera V1 ha de modificarse al nuevo valor V2.

3. Borrado: Borrado de una o varias tuplas de una tabla. Al borrar una tupla hay que tener en cuenta que se deben verificar las restricciones de integridad referencial. Ejemplo: Supongamos que se borra una tupla de la tabla PROVINCIA cuyo valor de cod_prov es V. Si en la tabla ALUMNO no hay ninguna tupla cuyo valor del atributo cod_prov sea V, entonces no hay problema. Pero si no es as habra (al menos temporalmente) un problema de consistencia de la informacin almacenada en la base de datos, ya que existirn alumnos residentes en una provincia que no existe. Dos posibles soluciones para mantener la consistencia: a) Borrar todas las tuplas de ALUMNO afectadas. A su vez esto puede suponer una serie de borrados sucesivos en otras tablas, debido igualmente a problemas de integridad y consistencia, como en ALUMNO_FACULTAD. b) No permitir el borrado de la tupla de PROVINCIA si en ALUMNO hay tuplas que se veran afectadas. El procedimiento a seguir es primero borrar en la tabla ALUMNO todas aquellas tuplas cuyo atributo cod_prov tome valor V, y luego realizar la misma operacin de borrado en la tabla PROVINCIA. Otros ejemplos: borrado en la tabla ALUMNO (afecta a la tabla ALUMNO_FACULTAD), en la tabla UNIVERSIDAD (afecta a la tabla FACULTAD) y en la tabla FACULTAD (afecta a la tabla ALUMNO_FACULTAD).

Asertos, disparadores y reglas de verificacinA las restricciones vistas hasta ahora, se les ha prestado una atencin especial porque se pueden verificar con facilidad y se aplican a una gran variedad de aplicaciones de bases de datos. Sin embargo, hay muchas restricciones semnticas que expresan conocimiento especfico de la aplicacin y que estn ms all de los esquemas predefinidos y rgidos; por lo que no se pueden expresar utilizando nicamente estas formas especiales. Estas reglas son las denominadas reglas de negocio, ya que expresan las estrategias de una organizacin para llevar a cabo sus funciones primarias. Ejemplos de estas restricciones pueden ser: a) La suma de todos los importes de los prstamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal.

b) Cada prstamo tiene al menos un cliente que tiene una cuenta con un saldo mnimo de 200.000 Euros.

Vamos a ver los mecanismos que se utilizan para definir estas reglas:

- RESTRICCIN DE VERIFICACIN: Es un predicado que expresa una condicin que se desea que la base de datos satisfaga siempre. Comprueba, en toda operacin de actualizacin, si el predicado es cierto o falso y, en el segundo caso, rechaza la operacin. Son las clusulas check de la mayora de lenguajes. La expresin lgica mediante la cual se formula la condicin est definida sobre uno a varios atributos de un mismo elemento. Este tipo de restriccin se declara al tiempo que se define el elemento del esquema al cual afecta. Se les puede dar un nombre, pero al no tener existencia por s mismas sino dentro del elemento al que afectan, el nombre no es obligatorio.

-ASERTOS: Son anlogas a las restricciones de verificacin, aunque se diferencian de ellas en que pueden estar referidas a ms de un elemento del esquema (varias tablas), ya que tienen existencia por s mismas; por tal motivo, es obligatorio ponerles un nombre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos. Cuando se crea un aserto el sistema comprueba su validez. Si el aserto es vlido, slo se permiten las modificaciones posteriores de la base de datos que no hagan que se viole el aserto. Esta comprobacin puede introducir una sobrecarga importante si se han realizado asertos complejos. Por tanto, los asertos deben utilizarse con precaucin. En SQL los asertos adoptan la forma: create assertion check Dado que SQL no proporciona ningn mecanismo para todo X, P(X) (donde P es un predicado), no queda ms remedio que implementarlo utilizando su equivalente no existe X tal que no P(X). Vemos cmo se escribiran las dos restricciones mencionadas al principio del apartado: a) La suma de todos los importes de los prstamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal: create assertion restriccin-suma check (not exists (select * from sucursal where (select sum(importe) from prstamo where prstamo.nombre-sucursal = sucursal.nombre-sucursal) >=

(select sum (importe) from cuenta where prstamo.nombre-sucursal = sucursal.nombre-sucursal))) b) Cada prstamo tiene al menos un cliente que tiene una cuenta con un saldo mnimo de 200.000 Euros: create assertion restriccin-saldo check (not exists (select * from prstamo where not exists (select * from prestatario, impositor, cuenta where prstamo.nmero-prstamo=prestatario.nmero-prstamo and prestatario.nombre-prestatario = impositor.nombre-cliente and impositor.nmero-cuenta = cuenta.nmero-cuenta and cuenta.saldo >= 200000)))

-DISPARADORES O TRIGGERS: Un disparador es una orden que el sistema ejecuta de manera automtica como efecto secundario de la modificacin de la base de datos. Son instrumentos de las bases de datos activas que permiten definir reglas distintas de las restricciones; en realidad, las restricciones, no son otra cosa que un tipo especial de reglas de las bases de datos activas en las que el evento que las activa es una actualizacin. Son tiles para alertar a los usuarios o para realizar de manera automtica ciertas tareas cuando se cumplen determinadas condiciones. Una vez almacenado en la base de datos, el sistema de base de datos asume la responsabilidad de ejecutarlo cada vez que ocurra el evento especificado y se satisfaga la condicin correspondiente. Para disear un mecanismo disparador hay que cumplir dos requisitos: -Especificar las condiciones en las que se va a ejecutar el disparador. -Especificar las acciones que se van a realizar cuando se ejecute el disparador. Estos disparadores se ajustan al modelo ECA, que veremos en el siguiente apartado. La estructura bsica de un trigger es la tpica de un modelo ECA: Llamada de activacin: es la sentencia que permite "disparar" el cdigo a ejecutar. Restriccin: es la condicin necesaria para realizar el cdigo. Accin a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se han cumplido las condiciones iniciales. Existen dos tipos de triggers, que se clasifican segn la cantidad de ejecuciones a realizar: Row Triggers: se disparan una vez por cada fila afectada.

Statement Triggers: son aquellos que sin importar la cantidad de veces que se cumpla con la condicin, su ejecucin es nica. Si no se especificara la condicin, ya que es opcional, se considera el resultado como verdadero y la accin se dispara siempre que se ejecute la operacin. Los disparadores relacionales tienen dos niveles de granularidad: a nivel de fila y a nivel de sentencia. En el primer caso, la activacin tiene lugar para cada tupla involucrada en la operacin y se dice que el sistema tiene un comportamiento orientado a tuplas. En el segundo caso, la activacin tiene lugar slo una vez para cada sentencia SQL, refirindose a todas las tuplas invocadas por la sentencia, con un comportamiento orientado a conjuntos. Adems los disparadores tienen funcionalidad inmediata o diferida. La evaluacin de los disparadores inmediatos normalmente sucede inmediatamente despus del evento que lo activa (opcin despus), aunque tambin puede precederlo (opcin antes) o ser evaluados en lugar de la ejecucin del evento (opcin en lugar de). La evaluacin diferida de los disparadores tiene lugar al finalizar la transaccin en donde se han activado. Un disparador puede activar otro disparador. Esto ocurre cuando la accin de un disparador es tambin el evento de otro disparador. En este caso, se dice que los disparadores se activan en cascada. Vemos unas peculiaridades respecto al uso de los disparadores: No se deben usar disparadores para resolver problemas que ya tienen otro mecanismo de resolucin, es decir, no se deben usar disparadores para limitar el rango de valores de un atributo (para eso se usan los dominios), o para preservar la integridad referencial, por ejemplo. A veces se utilizan tambin para proporcionar datos consolidados o resumidos, obtenidos a partir de los datos reales. Si el sistema gestor lo permite, es mejor utilizar vistas materializadas. Otro uso tpico que se puede evitar es el uso de disparadores para realizar copias de los datos, usando los disparadores para marcar los registros que se hayan modificado, creado o borrado desde la ltima copia. La mayor parte de los sistemas gestores modernos permiten realizar estas rplicas bajo el control del gestor.

Disparadores en SQL

Los sistemas de bases de datos SQL usan ampliamente los disparadores, aunque antes de SQL:1999 no fueron parte de la norma. Por desgracia, cada sistema de bases de datos implement su propia sintaxis para los disparadores, conduciendo a incompatibilidades (la

sintaxis SQL:1999 para los disparadores es similar a la sintaxis de los sistemas de bases de datos DB2 de IBM y de Oracle). El disparador debe especificar sobre que tabla se va a activar, y que operacin lo dispara: insert, update o delete (no hay disparadores en los select porque estos no modifican los datos). Adems debe indicar, cuando se va a ejecutar, antes (before) o despus (after) de la operacin. Tambin se puede especificar un predicado de condicin necesario para la activacin del trigger, mediante la clusula when. Para las actualizaciones, el disparador puede especificar aquellas columnas cuya actualizacin cause la ejecucin del disparador. El cdigo que se ejecuta en el disparador puede necesitar los valores de los atributos antes y despus de ser modificados. Para ello se utilizan las clusulas referencing new row as y referencing old row as. Los valores nuevos son accesibles en disparadores de insercin o actualizacin, y los valores antiguos en disparadores de actualizacin o borrado. Estos disparadores pueden servir como restricciones extras que pueden evitar actualizaciones no vlidas. Por ejemplo, si no se desea permitir descubiertos, se puede crear un disparador before que retroceda la transaccin si el nuevo saldo es negativo. En lugar de realizar una accin por cada fila afectada, se puede realizar una accin nica para la instruccin SQL completa que caus la insercin, borrado o actualizacin. Para hacerlo se usa la clusula for each statement en lugar de for each row. Las clusulas referencing old table as o referencing new table as se pueden usar entonces para hacer referencia a tablas temporales (denominadas tablas de transicin) conteniendo todas las filas afectadas. Las tablas de transicin no se pueden usar con los disparadores before, pero s con los after, independientemente de si son disparadores de instrucciones (statement) o de filas (row). Vemos la sintaxis y un ejemplo:

CREATE TRIGGER ON FOR EACH EXECUTE PROCEDURE > ();

CREATE TRIGGER contar AFTER INSERT ON Estudiantes WHEN (new.edad < 18) FOR EACH ROW BEGIN cont := cont + 1; END

Bases de datos activas

La idea viene motivada por el concepto que definimos como Restricciones de transicin. El poder especificar reglas con una serie de acciones que se ejecutan automticamente cuando se producen ciertos eventos, es una de las mejoras de los sistemas de gestin de bases de datos que se consideran de gran importancia desde hace algn tiempo. En los sistemas de gestin de bases de datos tradicionales (pasivas), la evolucin de la base de datos se programa en el cdigo de las aplicaciones, mientras que en los sistemas de gestin de bases de datos activas esta evolucin es autnoma y se define en el esquema de la base de datos. De este modo, al encontrarse las reglas definidas como parte del esquema de la base de datos, se comparten por todos los usuarios, en lugar de estar replicadas en todos los programas de aplicacin. Por tanto, cualquier cambio sobre el comportamiento reactivo se puede llevar a cabo cambiando solamente las reglas activas, sin necesidad de modificar las aplicaciones.

Un sistema de bases de datos activas es un sistema de gestin de bases de datos (SGBD) que contiene un subsistema que permite la definicin y la gestin de reglas de produccin. Mediante los sistemas de bases de datos activas se consigue un nuevo nivel de independencia de datos: la independencia de conocimiento. El conocimiento que provoca una reaccin se elimina de los programas de aplicacin y se codifica en forma de dichas reglas de produccin, ms conocidas como reglas activas. Mediante estas reglas se puede hacer respetar reglas de integridad, generar datos derivados, controlar la seguridad o implementar reglas de negocio. Adems, tambin se hace posible el integrar distintos subsistemas (control de accesos, gestin de vistas, etc.) y se extiende el mbito de aplicacin de la tecnologa de bases de datos a otro tipo de aplicaciones.

El problema principal en el diseo de las bases de datos activas est en entender el comportamiento de conjuntos complejos de reglas.

Modelo ECA y propiedades de las reglas activas

Las reglas siguen el modelo eventocondicinaccin (modelo ECA): cada regla reacciona ante un determinado evento, evala una condicin y, si sta es cierta, ejecuta una accin. La ejecucin de las reglas tiene lugar bajo el control de un subsistema autnomo, denominado motor de reglas, que se encarga de detectar los eventos que van sucediendo yde planificar las reglas para que se ejecuten.

En el modelo ECA una regla tiene tres componentes: -El evento (o eventos) que dispara la regla. Estos eventos pueden ser operaciones de consulta o actualizacin que se aplican explcitamente sobre la base de datos. Tambin pueden ser eventos temporales (por ejemplo, que sea una determinada hora del da) u otro tipo de eventos externos (definidos por el usuario). -La condicin que determina si la accin de la regla se debe ejecutar. Una vez ocurre el evento disparador, se puede evaluar una condicin (es opcional). Si no se especifica condicin, la accin se ejecutar cuando suceda el evento. Si se especifica condicin, la accin se ejecutar slo si la condicin se evala a verdadero. -La accin a realizar puede ser una transaccin sobre la base de datos o un programa externo que se ejecutar automticamente.

Casi todos los sistemas relacionales incorporan reglas activas simples denominadas disparadores (triggers), que estn basados en el modelo ECA: -Los eventos son sentencias SQL de manejo de datos (INSERT, DELETE, UPDATE). -La condicin (que es opcional) es un predicado booleano expresado en SQL. -La accin es una secuencia de sentencias SQL, que pueden estar inmersas en un lenguaje de programacin integrado en el producto que se est utilizando (por ejemplo, PL/SQL en Oracle).

El modelo ECA se comporta de un modo simple e intuitivo: cuando ocurre el evento, si la condicin es verdadera, entonces se ejecuta la accin. Se dice que el disparador es activado por el evento, es considerado durante la verificacin de su condicin y es ejecutado si la condicin es cierta. Sin embargo, hay diferencias importantes en el modo en que cada sistema define la activacin, consideracin y ejecucin de disparadores.

PROPIEDADES DE LAS REGLAS ACTIVAS: 1. Terminacin: Un conjunto de reglas garantiza la terminacin cuando, para cada transaccin que puede activar la ejecucin de reglas, esta ejecucin produce un estado final en un nmero finito de pasos. Esta es la nica regla esencial de las tres. 2. Confluencia: Un conjunto de reglas garantiza la confluencia cuando, para cada transaccin que puede activar la ejecucin de reglas, la ejecucin termina produciendo un estado final nico que no depende del orden de ejecucin de las reglas. 3. Comportamiento observable idntico: Un conjunto de reglas garantiza un comportamiento observable idntico cuando, para cada transaccin que puede activar la ejecucin de reglas, esta ejecucin es concluyente y todas las acciones visibles llevas a cabo por la regla son idnticas y producidas en el mismo orden. El proceso del anlisis de reglas permite la verificacin de si las propiedades deseadas se cumplen en un conjunto de reglas. Una herramienta esencial para verificar la terminacin es el grafo de activacin, que representa interacciones entre reglas. El grafo se crea incluyendo un nodo para cada regla y un arco de la regla R1 a la regla R2 cuando la accin de R1 contiene una sentencia del lenguaje de manejo de datos que es tambin uno de los eventos de R2. Una condicin necesaria pero no suficiente para la no terminacin es la presencia de ciclos en el grafo de activacin. Los sistemas que tienen muchas reglas activas suelen ser cclicos. Sin embargo, slo unos pocos ciclos son los que provocan situaciones crticas. Hay dos algoritmos alternativos para el procesamiento de las reglas activadas por una sentencia: al algoritmo iterativo y al algoritmo recursivo. Ambos se detallan a continuacin. Algoritmo Iterativo mientras existan reglas activadas: seleccionar una regla activada R comprobar la condicin de R si la condicin es cierta, ejecutar la accin de R fin mientras Algoritmo Recursivo mientras existan reglas activadas: seleccionar una regla activada R comprobar la condicin de R si la condicin es cierta: ejecutar la accin de R

ejecutar este algoritmo para las reglas activadas por la accin de R fin si fin mientras

BibliografaELMASRI, R.; NAVATHE, S. B. Fundamentos de sistemas de bases de datos. Tercera Edicin PEARSON EDUCACIN, S. A., Madrid, 2002

C. J. DATE Introduccin a los sistemas de bases de datos. Sptima Edicin PEARSON EDUCACIN, S. A., 2001

CLAUDIO CASARES Modelo de datos. Modelo Relacional. http://www.programacion.net/bbdd/autor/28/

EMMANUEL MARTNEZ HERNNDEZ Instituto tecnolgico CD Madero/Bases de datos II/Unidad II. Integridad http://www.geocities.com/tazzplayer_k/unidad_ii_integridad.htm

JAVIER ACOSTA; LUIS BOLAOS; LEOMAR BLSCO Mecanismos de seguridad e integridad. http://alfa.facyt.uc.edu.ve/computacion/pensum/cs0347/download/exposiciones20062007/Seguridad%20e%20integridad.pdf

JUAN IGNACIO RODRIGUEZ DE LEN Restricciones a la base de datos: Integridad y seguridad http://s3.amazonaws.com/UNED/apuntes/Tema6.pdf

RAL DAVID SALOMON GARCA

Bases de datos II. UNIDAD II. Integridad www.geocities.com/la_cakzula/Integridad.pdf

MERCHE MARQUS Diseo de sistemas de bases de datos http://www3.uji.es/~mmarques/e16/teoria/cap1.pdf

Miguel Bautista Len DNI: 44591303f 11 de Abril de 2008