Restricciones de integridad En este tema se trata uno de los aspectos más importantes para añadir consistencia a los diseños de bases de datos: son las restricciones de integridad que ayudan a mantener la consistencia semántica de los datos. Además de las restricciones de integridad definidas por las claves y las restricciones de cardinalidad estudiadas en el tema Modelo entidad-relación, se tratan las restricciones de los dominios, la integridad referencial, las dependencias funcionales y las dependencias multivaloradas. Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos.
Protegen a la base de datos contra los daños accidentales. Tipos de restricciones de integridad:
Declaración de claves. Cardinalidad Cardinali dad de la relación de varios a varios, de uno a varios, de uno a uno. Restricciones de los dominios Integridad referencial Asertos Disparadores Dependencias funcionales Dependencias Dependencia s multivaloradas multivalorad as Restricciones de los dominios
Las restricciones de los dominios son la forma más simple de restricción de integridad. Se específica para cada atributo un dominio de valores posibles. 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 d e una sucursal sucursa l tenga sentido. Por tanto, nombre-cliente y nombresucursal 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: Número de cifras Número de decimales create domain sueldo-por-hora numeric(4,2) constraint comprobación-valor-sueldo check(value 6.00)
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. 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. CREATE TABLE Sucursales (nombre-sucursal VARCHAR(20), ciudad-sucursal VARCHAR(20) NOT NULL, - Restricción de existencia PRIMARY KEY(nombre-sucursal) UNIQUE (ciudad-sucursal)) - Restricción de unicidad Integridad referencial
La integridad referencial permite asegurar 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. Integridad referencial en el modelo E-R
Las restricciones de integridad referencial aparecen con frecuencia. Si se obtiene el esquema de la base de datos relacional creando tablas a partir de los diagramas E-R, cada relación que proceda de un conjunto de relaciones tendrá restricciones de integridad referencial. Sea un conjunto N-ario de relaciones R, que relaciona los conjuntos de entidades E 1, E 2, ..., E n. K i denota la clave primaria de E i. Los atributos del esquema de la relación del conjunto de relaciones R incluyen K 1 K 2 ... K n . Cada K i del esquema de R es una clave externa que lleva a una restricción de integridad referencial. Otra fuente de restricciones de integridad referencial son los conjuntos de entidades débiles. Un conjunto de entidades débiles debe incluir la clave primaria del conjunto de entidades del que éste depende. Por tanto, el esquema de la relación de cada conjunto de entidades débiles incluye una clave externa que lleva a una restricción de integridad referencial. Asertos
Un aserto es un predicado que expresa una condición que se desea que la base de datos satisfaga siempre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos. Sin embargo, hay muchas restricciones que no se pueden expresar utilizando únicamente estas formas especiales. Ejemplos de estas restricciones pueden ser
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. Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínim o de 200.000 Pta. En SQL-92 los asertos adoptan la forma create assertion
check Las dos restricciones mencionadas pueden escribirse tal y como se muestra a continuación. 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 ), que puede escribirse en SQL. 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 ))) 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))) 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 im portante si se han realizado asertos complejos. Disparadores
Un disparador es una orden que el sistema ejecuta de manera automática como efecto secundario de la modificación de la base de datos. Los disparadores son mecanismos útiles para alertar a los usuarios o para realizar de manera automática ciertas tareas cuando se cumplen determinadas condiciones. Por ejemplo, en lugar de permitir saldos de cuenta negativos, el banco trata los descubiertos dejando a cero el saldo de las cuentas y creando un préstamo por el importe del descubierto. Este préstamo recibe un número de préstamo idéntico al número de cuenta que ha tenido el descubierto. En este ejemplo la condición para ejecutar el disparador es una actualización de la relación cuenta que dé lugar a un valor negativo de saldo. Supóngase que Santos retiró cierta cantidad de dinero de una cuenta que dio lugar a que el saldo de la cuenta fuera negativo. t denota la tupla de la cuenta con un valor negativo de saldo. Las acciones que hay que emprender son las siguientes: Insertar una nueva tupla s a la relación préstamo con s[nombre-sucursal] = t[nombre-sucursal]
s[número-préstamo] = t[número-cuenta] s[importe] = - t[saldo] Obsérvese que, dado que t[saldo] es negativo, hay que cambiar el signo de t[saldo] para obtener el importe del préstamo un número positivo). Insertar una nueva tupla u a la relación prestatario con u[nombre-cliente] = Santos u[número-préstamo] = t[número-cuenta] Hacer que t[saldo] sea 0. Dependencias
funcionales
Una dependencia funcional (DF) es una propiedad semántica de un esquema de relación que presentan las tuplas válidas de la relación que determina para cada valor de un conjunto de atributos el valor de otro conjunto de atributos. La validez se interpreta desde el significado que el diseñador asocia a la relación. Por tanto, una DF no se puede inferir de una relación, sino que se debe definir explícitamente sobre los atributos de la relación conociendo perfectamente su semántica. Una DF define los estados consistentes de una relación en función de las dependencias entre los valores de los atributos. Ejemplo 1. En la siguiente relación se combinan los datos de los empleados, como su código de identificación y nombre, y de los centros a los que están adscritos, como la dirección y el teléfono.
En este ejemplo se muestra gráficamente que el valor del conjunto de campos DirecciónC y TeléfonoC depende del valor del campo Centro. En concreto, a un centro en particular le corresponden unívocamente una dirección y un teléfono. Es decir, cada vez que aparezca una fila con el valor Informática para Centro, siempre le corresponderá los mismos valores para los campos DirecciónC y TeléfonoC. Se dice entonces que tanto DirecciónC como TeléfonoC son dependientes funcionalmente de Centro. Por cada fila con un mismo valor de Centro se repiten los valores DirecciónC y TeléfonoC, lo que implica una redundancia de valores no deseable que se estudiará en el tema Normalización. Dependencias
multivaloradas
Las dependencias multivaloradas son restricciones de integridad que expresan relaciones entre los atributos de un esquema que no pueden ser expresables con las dependencias funcionales. Ejemplo 8.
En la siguiente relación se representan los empleados, sus domicilios y teléfonos, asumiendo que pueden tener más de una vivienda y teléfono, y que no se dispone información acerca del tipo de teléfono, fijo o móvil, por lo que no se puede relacionar con un domicilio. Estos atributos son independientes entre sí. Para mantener la relación consistente es necesario expresar todas las combinaciones de los atributos.
Empleados Nombre
Dirección
Teléfono
Ana Almansa Ana Almansa Ana Almansa Ana Almansa Ana Almansa Ana Almansa
c/ Argentales c/ Argentales c/ Argentales c/ Amaniel c/ Amaniel c/ Amaniel
1 2 3 1 2 3
Mientras que las dependencias funcionales impiden que aparezcan ciertas tuplas en las relaciones, las dependencias multivaloradas obligan a ello. Las dependencias multivaloradas aparecen cuando en un esquema de relación hay varias relaciones 1:N independientes entre sí.
Bibliografía [ACPT00] P. Atzeni, S. Ceri, S. Paraboschi y R. Torlone, Database Systems. Concepts, Languages and Architectures, McGraw-Hill, 2000. [EN00] R. Elmasri y S.B. Navathe, "Fundamentals of Data Base Systems", AddisonWesley, 2000. [SKS98] A. Silberstachatz, Korth y Sudarshan, "Database System Concepts", McGrawHill, 2001 Apartados 3.1-3.4 [Ull98] J.D. Ullman, "Principles of Database and Knowledge Base Systems", Vol. I y II,
