Restricciones de Integridad en El Modelo Relacional
49
RESTRICCIONES DE INTEGRIDAD EN EL MODELO RELACIONAL
-
Upload
miguel-bautista -
Category
Documents
-
view
3.998 -
download
2
Transcript of Restricciones de Integridad en El Modelo Relacional
RESTRICCIONES DE
INTEGRIDAD EN EL MODELO
RELACIONAL
Miguel Bautista León
DNI: 44591303f
11 de Abril de 2008
Índice
1. Introducción al modelo relacional………………………………………..……………3
2. Conceptos previos……………………………………………………………………..5
3. El problema de la integridad en las bases de datos……………………………………8
4. Restricciones de los dominios. Unicidad y valor nulo……………………………......10
5. Restricciones en la clave. Integridad de entidades……………………………………12
6. Integridad referencial y claves externas……………………………………...……….14
7. Integridad referencial en SQL…………………………………………………………17
8. Operaciones de actualización y tratamiento de las violaciones a las restricciones……18
9. Ejemplo………………………………………………………………………………...20
10. Asertos, disparadores y reglas de verificación………. .........................................…….23
11. Disparadores en SQL…………………………………………………………………..26
12. Bases de datos activas. …………………………...…...…….…………………………27
13. Modelo ECA y propiedades de las reglas activas……………………………………...28
14. Bibliografía……………………………………………………………………………..30
Introducción al modelo relacional
El modelo de datos relacional fue introducido por Tedd Codd de IBM Research en 1970.
Codd introduce el concepto de relación como una estructura básica del modelo, lo que supuso
un importante paso en la investigación de los SGBD (Sistemas Gestores de Bases de Datos),
suministrando un sólido fundamento teórico para el desarrollo, dentro de este enfoque
relacional, de nuevos productos. El trabajo publicado por Codd, presentaba un nuevo modelo de
datos que perseguía una serie de objetivos, que se pueden resumir en los siguientes:
-Independencia física: es decir, el modo en el que se almacenan los datos no influya en su
manipulación lógica y, por tanto, los usuarios que acceden a esos datos no tienen que modificar
sus programas por cambios en el almacenamiento físico.
-Independencia lógica: esto es, que el añadir, eliminar o modificar objetos de la base de datos
no repercuta en los programas y/o usuarios que están 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 lógicas de los datos presentan un aspecto uniforme, lo que
facilita la concepción y manipulación de la base de datos por parte de los usuarios.
-Sencillez: las características anteriores, así como unos lenguajes de usuario muy sencillos,
producen como resultado que el modelo de datos relacional sea fácil de comprender y de utilizar
por parte del usuario final.
Un Sistema Gestor de Bases de Datos es una herramienta software que permite la creación y
manipulación de bases de datos. Para ello, debe tener un Lenguaje de Definición de Datos
(LDD) que, habitualmente, será el estándar SQL. Iremos viendo algunos ejemplos de casos
concretos en SQL.
Desde mediados de los años 80, el modelo relacional es utilizado por prácticamente la totalidad
de los SGBD comerciales:
-Algunas de las principales empresas informáticas 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 diseñados para PC’s 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 dinámica 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
colección 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 vínculo 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 información de empleados podemos
tener columnas como DNI y Nombre para describir distintas características 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 están en cada una de las filas de la tabla. Por tanto, una base de
datos relacional sería 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 varía en el tiempo.
En la terminología formal del modelo relacional, una fila se denomina tupla, una cabecera de
columnas es un atributo y la tabla se denomina relación. El tipo de datos que describe los tipos
de valores que pueden aparecer en cada columna se llama dominio. Vemos estos conceptos más
detalladamente.
Conceptos previos
-Un dominio D es un conjunto finito de valores homogéneos y atómicos caracterizados por un
nombre; decimos homogéneos porque son todos del mismo tipo y atómicos 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 : España, Francia,... Si descompusiéramos España en
E,s,p,... perdería la semántica.
Ejemplos de dominios serían:
Colores: Es el conjunto de los colores D={rojo, verde, azul,}
Números de DNI: Es conjunto de números del DNI válidos, formados por ocho dígitos.
Edad: Edades posibles de los empleados entre 18 y 80 años.
-Un atributo es el papel que tiene un determinado dominio en una relación.
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_física 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.
Además 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 combinación 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, además de los tres dominios Día, Mes y Año, un dominio
compuesto denominado Fecha que sería la combinación de los tres primeros, y al que
podríamos aplicar las adecuadas restricciones de integridad a fin de que no aparecieran valores
no válidos para la fecha; algo análogo ocurre Con el nombre y los apellidos, que, según las
aplicaciones, puede ser conveniente tratarlos en conjunto o por separado.
De la misma forma, es posible definir un atributo compuesto Fecha que tomaría sus valores del
dominio compuesto de igual nombre.
-Un esquema de relación R se denotará por R(A1, A2, ..., An), y se compone de un nombre de
relación R y una lista de atributos A1, A2, ..., An. Cada atributo Ai es el nombre del papel
desempeñado por algún dominio D en el esquema de relación R. Se dice que D es el dominio de
Ai, y se denota por dom(Ai). Un esquema de relación sirve para describir una relación. El grado
de una relación es el número de atributos n de su esquema de relación. Por ejemplo, esquema de
relación para una relación de grado 3 que describe a los clientes de un banco:
Clientes (nombreCli, dniCli, domicilio)
-Una relación del esquema de relación R(A1, A2, ..., An), denotada también 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=<v1,v2, ..., vn> 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 relación también puede plantearse como una relación matemática 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 relación refleja sólo las tuplas válidas en ese momento. Los atributos
reflejan los papeles o interpretaciones de cada dominio, y puede haber varios atributos de una
relación definidos sobre el mismo dominio.
Características de las relaciones:
-No existe orden entre las tuplas, aunque lógicamente se almacenen y se visualicen en
un cierto orden, pero ese orden puede variar sin que suponga alterar la relación.
-No existe orden entre los atributos y, por tanto, puede cambiarse el orden sin que
suponga un cambio a la relación. Por comodidad suele suponerse un orden en los
atributos y así se representarán los valores de las tuplas en ese orden.
-Primera Forma Normal: Los valores son atómicos o indivisibles.
Valores compuestos o multivaluados no son permitidos.
– Atributos Compuestos: Se representan sólo sus componentes simples.
– Atributos Multivaluados: Se representa cada atributo multivaluado en una
relación separada. Dicha relación almacenará todos los valores.
Interpretación de una Relación:
a) El esquema de una relación es un aserto o afirmación que indica los atributos del
objeto (entidad o relación) que representa la relación.
b) Cada tupla es un hecho o instancia de ese objeto, que puede representarse como un
predicado.
-TRANSACCIÓN: Conjunto de operaciones de una aplicación de Bases de Datos que se
efectúan como una única operación lógica. Propiedades:
– Atomicidad: Una transacción se considera como una única operación lógica, aunque
esté formada por varias operaciones más simples.
• Debe controlarse que una transacción no sea ejecutada “a medias”.
• Una transacción, o se ejecuta completamente o no se ejecuta.
– Consistencia: Antes y después de cada transacción, la BD debe tener valores lógicos,
aceptables o consistentes.
• Si se produce un fallo del sistema en medio de la transacción, se deben anular
las primeras operaciones de la transacción ya efectuadas: Los valores de la BD
deben ser consistentes.
• La consistencia de la BD debe asegurarse incluso aunque varias transacciones
se efectúen concurrentemente.
– Durabilidad: Tras una transacción, 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 más columnas (campos).
• Fila o Tupla (row, tuple): Hecho que corresponde a una entidad o relación 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 atómicos o indivisibles (como
información). Ejemplos: Números naturales, reales, cadenas de caracteres...
– Formato: Forma de representar un dato. Ej: Tlfno: +34 999-99-99-99.
La definición 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 sólo puede tener un número de DNI y una única dirección oficial.
Cuando se diseña 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 restricción son los siguientes:
-La operación de actualización (inserción, borrado o eliminación) cuya ejecución ha de
dar lugar a la comprobación del cumplimiento de la restricción.
-La condición que debe cumplirse, la cual es en general una proposición lógica, definida
sobre uno o varios elementos del esquema, que puede tomar uno de los valores de
verdad (cierto o falso).
-La acción que debe llevarse a cabo dependiendo del resultado de la condición.
Toda instalación debe garantizar la integridad de la información que almacena en todo instante
de se historia. Se refiere a la exactitud o corrección de los datos en la base de datos. Esta
integridad de los datos es más 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 destrucción o alteración
malintencionada y de la introducción accidental de inconsistencias. El mal uso de la base de
datos puede clasificarse como malintencionada (con premeditación) o accidental.
La pérdida accidental de la consistencia de los datos puede ser resultado de:
-Caídas durante el procesamiento de transacciones
-Anomalías causadas por el acceso concurrente a la base de datos
-Anomalías causadas por la distribución de datos entre varias computadoras
-Errores lógicos que violan la suposición de que las transacciones conservan las
ligaduras de consistencia de la base de datos.
Es mas sencilla la protección contra la perdida accidental de la consistencia de los datos que la
protección 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 información)
-La modificación no autorizada de los datos
-La destrucción no autorizada de los datos.
Además de proteger los datos contra posibles problemas sistemáticos, deben incluirse también
procedimientos de chequeo que aseguren que los valores de los datos se ajustan a ciertas reglas
prescritas de antemano. Estas pruebas podrán hacerse verificando las relaciones que existen
entre varios valores de datos.
Por tanto, definimos integridad como la acción de conservar la seguridad en un sistema en el
que se permite acceso a múltiples usuarios y compartir la base de datos. Tiene como función
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 serán verificadas siempre que se realice una operación de actualización. 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
pérdida de consistencia de los datos. Así pues, las restricciones de integridad protegen la base de
datos contra daños accidentales, ya que sin los controles apropiados sería 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 mayoría de los productos de bases de datos de hoy día son mas bien
débiles 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 definición cobra gran importancia en un diseño de base da datos relacional.
Distinguimos entre restricciones inherentes y semánticas:
-Restricciones inherentes. Además de las derivadas del concepto de "relación" 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 sólo puede tomar un único valor del dominio, no
admitiéndose por tanto los grupos repetitivos; destaca la regla de integridad de entidad.
-Restricciones de semánticas. También 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
semántica del mundo real. Aquí tenemos la restricción de integridad referencial, clave
primaria, unicidad, existencia (valor no nulo), verificación, aserción y disparadores.
Otra clasificación, distingue entre las restricciones de estado, que definen las restricciones que
debe satisfacer un estado válido de la base de datos; y las llamadas restricciones de transición,
definidas para tratar con cambios de estado de la base de datos ("el sueldo de un empleado sólo
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
diseño de bases de datos por normalización (no lo veremos).
He intentado agrupar los conceptos en función de su relevancia y según la relación que
presentan, e introduciendo ejemplos de manera que la exposición sea lo más clara posible.
Restricciones de dominio. Unicidad y valor Nulo
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 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 programación de sistemas. Puesto que los sistemas de base
de datos son diseñados para soportar usuarios que nos son expertos en computadores a menudo
los beneficios de los lenguajes fuertemente tipados pasan más que las desventajas. No obstante
existen muchos sistemas que permiten solamente un número pequeño de tipos de dominios. Los
sistemas más nuevos particularmente los sistemas de base de datos orientados a objetos, ofrecen
un conjunto rico de tipos de dominio que puede ser ampliado fácilmente.
Al definir cada atributo sobre un dominio se impone una restricción 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 atómico de su dominio.
Los límites de dominios son la forma más 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.
Una definición adecuada de las restricciones de los dominios no sólo permite verificar los
valores introducidos en la base de datos, sino también 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 cláusula 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 programación.
La cláusula 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 comprobación-valor-sueldo check(value ≥ 6.00)
Los tipos de datos asociados a los dominios suelen incluir los tipos numéricos estándar para
enteros y reales, así como caracteres y cadenas de longitud fija y variable, fecha, hora, marca de
tiempo y dinero. También pueden especificarse intervalos o conjuntos explícitos de valores
permitidos. Adicionalmente, se puede definir el valor nulo como una marca utilizada para
representar información desconocida. La necesidad de valores nulos es evidente por diversas
razones:
-Existencia de tuplas con ciertos atributos desconocidos en ese momento.
-Necesidad de añadir un nuevo atributo a una tabla ya existente; atributo que en el
momento de introducirse no tendrá ningún valor para las tuplas de la relación.
-Posibilidad de atributos inaplicables a ciertas tuplas, como la editorial para un artículo.
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 restricción que se puede
aplicar a cualquier dominio es la restricción de existencia.
Esta restricción evita la aparición de valores nulos en las columnas:
Dado un conjunto de atributos K de R (K≠∅) se dice que R satisface una restricción 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 restricción.
El SQL estándar permite que la declaración del dominio de un atributo incluya la especificación
not null. Esto prohibe la inserción de un valor nulo para este atributo. Cualquier modificación de
la base de datos que causara que se insertase un valor nulo en un dominio not null genera un
diagnóstico de error.
Restricciones de unicidad
Otro tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de
unicidad. Esta restricción evita la aparición de valores duplicados en las columnas.
Por ejemplo: Sólo se admite una sucursal en cada ciudad.
En SQL, se puede utilizar restricciones unique para garantizar que no se escriben valores
duplicados en columnas específicas que no forman parte de una clave principal.
Restricciones en la clave. Integridad de entidades
Sabemos que no puede haber dos tuplas que tengan la misma combinación de valores para todos
sus atributos. Por tanto, vemos que existen subconjuntos de atributos de un esquema de relación
R con la propiedad de que no debe haber dos tuplas en un estado de relación r de R con la
misma combinación de valores para estos atributos. Este conjunto de atributos se denomina
superclave, y especifica una restricción de unicidad:
Se tiene que cumplir que en una relación 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 relación tiene por lo menos una superclave: el conjunto de todos sus atributos. Sin
embargo, una superclave puede tener atributos redundantes, así que un concepto más útil es el
de clave:
Una clave K de un esquema de relación R es una superclave de R con la propiedad
adicional de que la eliminación 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 mínima.
Normalmente, un esquema de relación tendrá más de una clave, denominadas claves
candidatas. Designamos a una de las claves candidatas como clave primaria de la relación
subrayando los atributos que la forman, denominados atributos primos. La clave de una
relación 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 varía con el tiempo; debe seguir siendo
válida aunque insertemos tuplas nuevas en la relación. Todas la relaciones que forman el
esquema de una base de datos relacional tienen que tener definida una clave primaria.
Sea R una relación, se dice que R satisface la restricción de clave primaria si:
R satisface la restricción de unicidad sobre su clave primaria,
R satisface la restricción de valor no nulo sobre su clave primaria,
en caso contrario R viola esta restricción.
Esta es una de las restricciones más 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 creación de índices y ordenar la tabla en función de dicha clave primaria con
vistas a la optimización 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 restricción de integridad de entidades establece que ningún 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 podrán permitir nulos.
La justificación de la regla de integridad de las entidades es la siguiente:
-Las relaciones base corresponden a entidades del mundo real
-Por definición, 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 también.
-Las Claves primarias realizan esta función de identificación ú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 contradicción de términos: no existe.
-Podemos emplear argumentos análogos 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.
-Restricción PRIMARY KEY en SQL:
Cuando especifica una restricción PRIMARY KEY en una tabla, se exige la unicidad de los
datos mediante la creación de un índice único para las columnas de clave principal. Este índice
también permite un acceso rápido 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 restricción PRIMARY KEY para más de una columna, puede haber valores
duplicados dentro de la misma columna, pero cada combinación de valores de todas las
columnas de la definición de la restricción PRIMARY KEY debe ser única. Ejemplo:
Cuando trabaja con combinaciones, las restricciones PRIMARY KEY relacionan una tabla con
otra. Este concepto de relación nos lleva al siguiente apartado.
Integridad referencial y claves externas
La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de datos
relacionales para asegurarse que los registros de tablas relacionadas son válidos y que no se
borren o cambien datos relacionados de forma accidental produciendo errores de integridad.
Es una restricción de comportamiento, ya que viene impuesta por el mundo real y es el usuario
quien la define al describir el esquema relacional; es también de tipo implícito, 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 ningún procedimiento para obligar a que se cumpla.
Se especifica entre dos relaciones, y asegura que un valor que aparece en una relación para un
conjunto de atributos determinado aparezca también en otra relación para un cierto conjunto de
atributos; 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
relación 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 relación R2; se dice que los atributos CE hacen referencia o se
refieren a la relación 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 bién es nulo. Si no es nulo, diremos que la tupla t1
hace referencia a la tupla t2. R1 será la relación referenciante, y R2 la relación
referenciada.
Básicamente, 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 relación. Una clave externa también puede hacer referencia a su propia relación
(caso de supervisor y empleado). Otra fuente de restricciones de integridad son los conjuntos de
entidades débiles: entidades dependientes de otras, que especifican determinados atributos
complementarios a estas. El esquema de la relación de cada conjunto de entidades débiles
incluye una clave externa, lo que lleva a una restricción de integridad referencial.
La integridad referencial hace que el SGBD se asegure de que no haya en las claves externas
valores que no estén 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:
-Relación Uno a Uno: Cuando un registro de una tabla sólo 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 relación 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.
-Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar
relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla
principal puede tener más 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 más fácil de recordar).
Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los
habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará
empadronado) en una única población. En este caso la tabla principal será la de poblaciones y la
tabla secundaria será la de habitantes. Una población puede tener varios habitantes pero un
habitante pertenece a una sola población. Esta relación 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 población que contiene el código de la población en la que
está empadronado el habitante, esta columna es clave externa de la tabla habitantes, y en la
tabla poblaciones tenemos una columna código de población clave principal de la tabla.
-Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más
de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar
relacionadas directamente, se tiene que añadir 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 artículos que se
venden en la empresa, un cliente podrá realizar un pedido con varios artículos, y un artículo
podrá ser vendido a más de un cliente.
No se puede definir entre clientes y artículos, hace falta otra tabla (por ejemplo una tabla de
pedidos) relacionada con clientes y con artículos. La tabla pedidos estará relacionada con cliente
por una relación uno a muchos y también estará relacionada con artículos por un relación uno a
muchos.
Asociada a la integridad referencial están 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 actualización en uno de sus extremos puede propagarse por toda la
cadena, de ahí la denominación 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 violación de
restricciones de integridad referencial:
-Actualizar registros en cascada: Esta opción le indica al sistema gestor de la base de datos
que cuando se cambie un valor del campo clave de la tabla principal, automáticamente 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 código (la clave principal), automáticamente se actualizan todos los habitantes
(en la tabla secundaria) que tienen el valor ‘1’ en el campo población (en la clave externa)
dejando ‘10’ en vez de ‘1’.Si no se tiene definida esta opción, no se puede cambiar los valores
de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor ‘1’ del
código 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 opción le indica al sistema gestor de la base de datos que
cuando se elimina un registro de la tabla principal automáticamente se borran también los
registros relacionados en la tabla secundaria. Por ejemplo: Si borramos la población Onteniente
en la tabla de poblaciones, automáticamente todos los habitantes de Onteniente se borrarán de la
tabla de habitantes.
Si una actualización de borrado en cascada crea una violación de la restricción que no puede
resolverse mediante una nueva operación en cascada, el sistema aborta la transacción. En
consecuencia, se deshacen todas las modificaciones generadas por la transacción 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 transacción. Las restricciones de
integridad se comprueban sólo al final de la transacción, no en los pasos intermedios.
Las claves externas pueden especificarse como parte de la instrucción create table de SQL
usando la cláusula foreign key, que además puede especificar las acciones a tomar para
restaurar la integridad referencial. SQL también soporta una versión de la cláusula references,
donde se puede especificar explícitamente una lista de atributos de la relación referenciada.
La cláusula on delete cascade asociada con la declaración de la clave externa, provoca que el
borrado se realice en cascada. La cláusula on update cascade, de forma similar realiza una
actualización en cascada, si se modifica la clave primaria.
Vemos la sintaxis de las cláusulas 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 instrucción create table de SQL: la cláusula primary key de la instrucción create table
incluye una lista de los atributos que comprende la clave primaria; y la cláusula foreign key de
la instrucción create table incluye una lista de los atributos que comprende la clave externa y el
nombre de la relación a la que hace referencia mediante la clave externa. Ejemplo:
create table cliente
(nombre-cliente char(20),
calle-cliente char(30),
ciudad-cliente char(30),
primary key (nombre-cliente))
create table sucursal
(nombre-sucursal char(15),
ciudad-sucursal char(30),
activo integer,
primary key (nombre-sucursal))
create table cuenta
(número-cuenta char(10),
nombre-sucursal char(15),
saldo integer,
primary key (número-cuenta),
. . .
foreign key (nombre-sucursal) references sucursal
on delete cascade
on update cascade
. . . )
create table impositor
(nombre-cliente char(20),
número-cuenta char(10),
primary key (nombre-cliente, número-cuenta),
foreign key (nombre-cliente) references cliente,
foreign key (número-cuenta) references cuenta)
Operaciones de actualización y tratamiento de las violaciones
de restricción
Las operaciones del modelo relacional pueden clasificarse en recuperaciones y actualizaciones.
Vamos a ver las operaciones de actualización básicas, que son tres: Insertar (insertar una o más
tuplas nuevas en una relación), Eliminar (elimina tuplas en una relación) 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 relación, 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 transacción en la cuenta 6 de 700 € realizada el 7-11-2003,
escribiríamos lo siguiente: Insertar < "6", “2”, "7-11-2003", 700> en transacciones.
Al insertar, puede violarse una restricción de dominio si se proporciona un valor de atributo que
no pertenece al dominio correspondiente. También puede violarse una restricción de clave si la
clave de la nueva tupla ya existe en la relación. 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 relación
referenciada.
Cuando una inserción viola una o más restricciones, la opción predeterminada es rechazar la
inserción.
-Eliminar: La operación Eliminar sólo 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 información a eliminar, se expresa una condición en términos
de los atributos de la relación correspondiente.
Por ejemplo, para eliminar todas las transacciones de la cuenta número 1 escribiríamos:
Eliminar en transacciones las tuplas con numeroCta=”1”
Podemos optar por distintas soluciones ante una violación de esta tipo. La opción seleccionada
en cada caso debe poder especificarse también en el esquema de la base de datos.
Vemos las opciones que implementa un SGBD:
a) Operación restringida: esto es, el borrado de tuplas de la relación que contiene la
clave primaria referenciada; sólo se permite si no existen tuplas con dicha clave en
la relación que contiene la clave externa. Esto nos llevaría, por ejemplo, a que para
poder borrar una editorial de nuestra base de datos no tendría que haber ningún libro
que estuviese publicado por dicha editorial, en caso contrario el sistema impediría el
borrado.
b) Operación con transmisión en cascada: esto es, el borrado de tuplas de la relación
que contiene la clave primaria referenciada lleva consigo el borrado en cascada de
las tuplas de la relación que contienen la clave externa. Ya vimos en qué consistían
las operaciones en cascada.
c) Operación con puesta a nulos: el borrado de tuplas de la relación que contiene la
clave primaria referenciada lleva consigo poner a nulos los valores de las claves
externas de la relación que referencia. Esta opción, obviamente, sólo es posible
cuando el atributo que es clave externa admite el valor nulo.
d) Operación con puesta a valor por defecto: el borrado de tuplas de la relación que
contiene la clave primaria referenciada lleva consigo poner el valor por defecto a la
clave externa de la relación que referencia.
e) Operación que desencadena un procedimiento de usuario: en este caso, el
borrado de tuplas de la tabla referenciada pone en marcha un procedimiento
definido por el usuario.
-Actualizar: La operación Actualizar modifica los valores de uno o más atributos de una o más
tuplas de una relación. Es necesario especificar una condición sobre los atributos de la relación
para seleccionar la tupla o tuplas a modificar.
Por ejemplo, para cambiar el domicilio del cliente con dniCli 1 a C/Real nº 14, escribiríamos:
Actualizar domicilio de clientes con dniCli = "1".
La actualización 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 relación referenciada (o es nulo).
Ejemplo
Se desea almacenar información 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 pública o privada.
Tendremos, por tanto, las entidades ALUMNO, PROVINCIA, FACULTAD y
UNIVERSIDAD; más ALUMNO_FACULTAD derivada de la relación 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 numéricos enteros de 8 cifras.
-El atributo ALUMNO.edad solo puede tomar valores numéricos enteros de 2 cifras, mayores
que 15.
-El atributo UNIVERSIDAD.tipo solo puede tomar uno de dos valores posibles: 1 (pública) o 2
(privada).
-El atributo FACULTAD.num_cursos solo puede tomar un valor numérico entero en el
intervalo [4,6].
-El atributo ALUMNO_FACULTAD.curso_inicio solo puede tomar valores numéricos 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. Además, 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. Además, no puede ser nulo por la restricción de integridad de clave.
-El atributo ALUMNO_FACULTAD.dni siempre debe tener un valor que se encuentre en
ALUMNO.dni. Además, no puede ser nulo por la restricción de integridad de clave.
-La agregación de los atributos ALUMNO_FACULTAD.cod_univ y
ALUMNO_FACULTAD.cod_fac siempre debe tener un valor que se encuentre en la
agregación de los atributos FACULTAD.cod_univ y FACULTAD.cod_fac. No vale cada
atributo por separado.
PROBLEMAS CON LAS RESTRICCIONES DURANTE LAS OPERACIONES
1.Inserción: Inserción 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 agregación de todos los atributos que forman la clave
primaria toma un valor único e inédito 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. Opción alternativa:
Antes de dar por válida la inserción 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.Modificación: Modificación del valor de algún 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 agregación
de todos los atributos que forman la clave primaria no tome un valor único e inédito 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 automáticamente 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í habría (al menos temporalmente) un problema de
consistencia de la información almacenada en la base de datos, ya que existirán 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 verían
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 operación 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 verificación
A las restricciones vistas hasta ahora, se les ha prestado una atención 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 semánticas que expresan conocimiento específico de la
aplicación y que están más allá de los esquemas predefinidos y rígidos; 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 organización para llevar a cabo sus funciones
primarias. Ejemplos de estas restricciones pueden ser:
a) La suma de todos los importes de los préstamos de cada sucursal debe ser menor que la suma
de todos los saldos de las cuentas de esa sucursal.
b) Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínimo de
200.000 Euros.
Vamos a ver los mecanismos que se utilizan para definir estas reglas:
- RESTRICCIÓN DE VERIFICACIÓN: Es un predicado que expresa una condición que se
desea que la base de datos satisfaga siempre. Comprueba, en toda operación de actualización, si
el predicado es cierto o falso y, en el segundo caso, rechaza la operación. Son las cláusulas
check de la mayoría de lenguajes. La expresión lógica mediante la cual se formula la condición
está definida sobre uno a varios atributos de un mismo elemento. Este tipo de restricción 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 análogas a las restricciones de verificación, aunque se diferencian de ellas en
que pueden estar referidas a más 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 válido, sólo se
permiten las modificaciones posteriores de la base de datos que no hagan que se viole el aserto.
Esta comprobación puede introducir una sobrecarga importante si se han realizado asertos
complejos. Por tanto, los asertos deben utilizarse con precaución.
En SQL los asertos adoptan la forma:
create assertion <nombre-aserto> check <predicado>
Dado que SQL no proporciona ningún mecanismo “para todo X, P(X)” (donde P es un
predicado), no queda más remedio que implementarlo utilizando su equivalente “no existe
X tal que no P(X)”.
Vemos cómo se escribirían las dos restricciones mencionadas al principio del apartado:
a) La suma de todos los importes de los préstamos de cada sucursal debe ser menor que la suma
de todos los saldos de las cuentas de esa sucursal:
create assertion restricción-suma check
(not exists (select * from sucursal
where (select sum(importe) from préstamo
where préstamo.nombre-sucursal = sucursal.nombre-sucursal) >=
(select sum (importe) from cuenta
where préstamo.nombre-sucursal = sucursal.nombre-sucursal)))
b) Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínimo de
200.000 Euros:
create assertion restricción-saldo check
(not exists (select * from préstamo
where not exists (select *
from prestatario, impositor, cuenta
where préstamo.número-préstamo=prestatario.número-préstamo
and prestatario.nombre-prestatario = impositor.nombre-cliente
and impositor.número-cuenta = cuenta.número-cuenta
and cuenta.saldo >= 200000)))
-DISPARADORES O TRIGGERS: Un disparador es una orden que el sistema ejecuta de
manera automática como efecto secundario de la modificación de la base de datos. 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 actualización. Son útiles para
alertar a los usuarios o para realizar de manera automática 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 condición correspondiente.
Para diseñar 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 básica de un trigger es la típica de un modelo ECA:
• Llamada de activación: es la sentencia que permite "disparar" el código a ejecutar.
• Restricción: es la condición necesaria para realizar el código.
• Acción 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 según 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 condición, su ejecución es única.
Si no se especificara la condición, ya que es opcional, se considera el resultado como verdadero
y la acción se dispara siempre que se ejecute la operación.
Los disparadores relacionales tienen dos niveles de granularidad: a nivel de fila y a nivel de
sentencia. En el primer caso, la activación tiene lugar para cada tupla involucrada en la
operación y se dice que el sistema tiene un comportamiento orientado a tuplas. En el segundo
caso, la activación tiene lugar sólo una vez para cada sentencia SQL, refiriéndose a todas las
tuplas invocadas por la sentencia, con un comportamiento orientado a conjuntos. Además los
disparadores tienen funcionalidad inmediata o diferida. La evaluación de los disparadores
inmediatos normalmente sucede inmediatamente después del evento que lo activa (opción
después), aunque también puede precederlo (opción antes) o ser evaluados en lugar de la
ejecución del evento (opción en lugar de). La evaluación diferida de los disparadores tiene lugar
al finalizar la transacción en donde se han activado.
Un disparador puede activar otro disparador. Esto ocurre cuando la acción de un disparador es
también 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 resolución, 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 también 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 típico 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
réplicas 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 operación lo dispara: insert,
update o delete (no hay disparadores en los select porque estos no modifican los datos).
Además debe indicar, cuando se va a ejecutar, antes (before) o después (after) de la operación.
También se puede especificar un predicado de condición necesario para la activación del
trigger, mediante la cláusula when. Para las actualizaciones, el disparador puede especificar
aquellas columnas cuya actualización cause la ejecución del disparador.
El código que se ejecuta en el disparador puede necesitar los valores de los atributos antes y
después de ser modificados. Para ello se utilizan las cláusulas referencing new row as y
referencing old row as. Los valores nuevos son accesibles en disparadores de inserción o
actualización, y los valores antiguos en disparadores de actualización o borrado.
Estos disparadores pueden servir como restricciones extras que pueden evitar actualizaciones no
válidas. Por ejemplo, si no se desea permitir descubiertos, se puede crear un disparador before
que retroceda la transacción si el nuevo saldo es negativo.
En lugar de realizar una acción por cada fila afectada, se puede realizar una acción única para la
instrucción SQL completa que causó la inserción, borrado o actualización. Para hacerlo se usa la
cláusula for each statement en lugar de for each row. Las cláusulas referencing old table as o
referencing new table as se pueden usar entonces para hacer referencia a tablas temporales
(denominadas tablas de transición) conteniendo todas las filas afectadas. Las tablas de transición
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 <nombre trigger> CREATE TRIGGER contar
<BEFORE|AFTER> AFTER INSERT ON Estudiantes
<INSERT|DELETE|UPDATE> WHEN (new.edad < 18)
ON <nombre relacion> FOR EACH ROW
FOR EACH <ROW|STATEMENT> BEGIN
EXECUTE PROCEDURE <nombre proc.>> cont := cont + 1;
(<function args>); END
Bases de datos activas
La idea viene motivada por el concepto que definimos como Restricciones de transición.
El poder especificar reglas con una serie de acciones que se ejecutan automáticamente cuando
se producen ciertos eventos, es una de las mejoras de los sistemas de gestión de bases de datos
que se consideran de gran importancia desde hace algún tiempo.
En los sistemas de gestión de bases de datos tradicionales (pasivas), la evolución de la base de
datos se programa en el código de las aplicaciones, mientras que en los sistemas de gestión de
bases de datos activas esta evolución es autónoma 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 aplicación. 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 gestión de bases de datos (SGBD) que
contiene un subsistema que permite la definición y la gestión de reglas de producción.
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 reacción se elimina
de los programas de aplicación y se codifica en forma de dichas reglas de producción, más
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. Además, también se hace posible el
integrar distintos subsistemas (control de accesos, gestión de vistas, etc.) y se extiende el ámbito
de aplicación de la tecnología de bases de datos a otro tipo de aplicaciones.
El problema principal en el diseño 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 evento–condición–acción (modelo ECA): cada regla reacciona ante
un determinado evento, evalúa una condición y, si ésta es cierta, ejecuta una acción. La
ejecución de las reglas tiene lugar bajo el control de un subsistema autónomo, 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
actualización que se aplican explícitamente sobre la base de datos. También pueden ser eventos
temporales (por ejemplo, que sea una determinada hora del día) u otro tipo de eventos externos
(definidos por el usuario).
-La condición que determina si la acción de la regla se debe ejecutar. Una vez ocurre el evento
disparador, se puede evaluar una condición (es opcional). Si no se especifica condición, la
acción se ejecutará cuando suceda el evento. Si se especifica condición, la acción se ejecutará
sólo si la condición se evalúa a verdadero.
-La acción a realizar puede ser una transacción sobre la base de datos o un programa externo
que se ejecutará automáticamente.
Casi todos los sistemas relacionales incorporan reglas activas simples denominadas
disparadores (triggers), que están basados en el modelo ECA:
-Los eventos son sentencias SQL de manejo de datos (INSERT, DELETE, UPDATE).
-La condición (que es opcional) es un predicado booleano expresado en SQL.
-La acción es una secuencia de sentencias SQL, que pueden estar inmersas en un lenguaje de
programación 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
condición es verdadera, entonces se ejecuta la acción. Se dice que el disparador es activado por
el evento, es considerado durante la verificación de su condición y es ejecutado si la condición
es cierta. Sin embargo, hay diferencias importantes en el modo en que cada sistema define la
activación, consideración y ejecución de disparadores.
PROPIEDADES DE LAS REGLAS ACTIVAS:
1. Terminación: Un conjunto de reglas garantiza la terminación cuando, para cada transacción
que puede activar la ejecución de reglas, esta ejecución produce un estado final en un número
finito de pasos. Esta es la única regla esencial de las tres.
2. Confluencia: Un conjunto de reglas garantiza la confluencia cuando, para cada transacción
que puede activar la ejecución de reglas, la ejecución termina produciendo un estado final único
que no depende del orden de ejecución de las reglas.
3. Comportamiento observable idéntico: Un conjunto de reglas garantiza un comportamiento
observable idéntico cuando, para cada transacción que puede activar la ejecución de reglas, esta
ejecución es concluyente y todas las acciones visibles llevas a cabo por la regla son idénticas y
producidas en el mismo orden.
El proceso del análisis de reglas permite la verificación de si las propiedades deseadas se
cumplen en un conjunto de reglas. Una herramienta esencial para verificar la terminación es el
grafo de activación, 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 acción de R1 contiene una
sentencia del lenguaje de manejo de datos que es también uno de los eventos de R2. Una
condición necesaria pero no suficiente para la no terminación es la presencia de ciclos en el
grafo de activación.
Los sistemas que tienen muchas reglas activas suelen ser cíclicos. Sin embargo, sólo unos pocos
ciclos son los que provocan situaciones críticas.
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 continuación.
Algoritmo Iterativo
mientras existan reglas activadas:
seleccionar una regla activada R
comprobar la condición de R
si la condición es cierta, ejecutar la acción de R
fin mientras
Algoritmo Recursivo
mientras existan reglas activadas:
seleccionar una regla activada R
comprobar la condición de R
si la condición es cierta:
ejecutar la acción de R
ejecutar este algoritmo para las reglas activadas por la acción de R
fin si
fin mientras
Bibliografía
ELMASRI, R.; NAVATHE, S. B.
Fundamentos de sistemas de bases de datos.
Tercera Edición
PEARSON EDUCACIÓN, S. A., Madrid, 2002
C. J. DATE
Introducción a los sistemas de bases de datos.
Séptima Edición
PEARSON EDUCACIÓN, S. A., 2001
CLAUDIO CASARES
Modelo de datos. Modelo Relacional.
http://www.programacion.net/bbdd/autor/28/
EMMANUEL MARTÍNEZ HERNÁNDEZ
Instituto tecnológico CD Madero/Bases de datos II/Unidad II. Integridad
http://www.geocities.com/tazzplayer_k/unidad_ii_integridad.htm
JAVIER ACOSTA; LUIS BOLAÑOS; LEOMAR BLÁSCO
Mecanismos de seguridad e integridad.
http://alfa.facyt.uc.edu.ve/computacion/pensum/cs0347/download/exposiciones2006-2007/
Seguridad%20e%20integridad.pdf
JUAN IGNACIO RODRIGUEZ DE LEÓN
Restricciones a la base de datos: Integridad y seguridad
http://s3.amazonaws.com/UNED/apuntes/Tema6.pdf
RAÚL DAVID SALOMON GARCÍA
Bases de datos II. UNIDAD II. Integridad
www.geocities.com/la_cakzula/ Integridad .pdf
MERCHE MARQUÉS
Diseño de sistemas de bases de datos
http://www3.uji.es/~mmarques/e16/teoria/cap1.pdf
Miguel Bautista León
DNI: 44591303f
11 de Abril de 2008
