DBD Unidad 2 parte 8 Restricciones de Integridad

Restricciones de Integridad.
Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las
restricciones de integridad que los datos almacenados en dicha estructura deben
cumplir para garantizar que son correctos.
Las restricciones son reglas que siempre deben cumplirse de modo de apoyar la
integridad de la base de datos (es decir, que la base de datos cumpla fielmente con el
mundo modelado).
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. Por tanto, las restricciones de integridad
protegen a la base de datos contra los daños accidentales.
Una BD será consistente si satisface las reglas de integridad definidas para ella.
Restricciones de dominios.
Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto
de valores permitidos para cada atributo.
Hay además dos reglas de integridad muy importantes que son restricciones que se
deben cumplir en todas las bases de datos relacionales y en todos sus estados o
instancias (las reglas se deben cumplir todo el tiempo).
Es preciso distinguir entre restricciones inherentes y restricciones de usuario.
Restricciones inherentes
Además de las derivadas de la definición de "relación":

Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.

No hay dos atributos que se llamen igual.
Tenemos que:

En una relación no hay dos tuplas iguales (obligatoriedad de clave primaria).

El orden de las tuplas no es significativo. (de arriba hacia abajo)

El orden de los atributos (columnas) no es significativo. (izq. a der.)

Cada atributo sólo puede tomar un único valor del dominio, no admitiéndose por
tanto los grupos repetitivos. (son atómicos)
Regla de integridad de entidad
Se aplica a las claves primarias de las relaciones:
“Ningún atributo que forme parte de la clave primaria de una relación puede tomar un
valor nulo”.
Por definición, una clave primaria es un identificador irreducible que se utiliza para
identificar de modo único las tuplas. Que sea irreducible significa que ningún
subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se
permite que parte de la clave primaria sea nula, se está diciendo que no todos sus
atributos son necesarios para distinguir las tuplas, con lo que se contradice la
irreducibilidad.
Restricciones de usuario (también llamadas restricciones semánticas)
Se pueden definir como un predicado sobre un conjunto de atributos, de tuplas o de
dominios, que debe ser verificado para que constituya una ocurrencia valida del
esquema.
Restricción de clave primaria (PRIMARY KEY)
Permite declarar un atributo o conjunto de atributos como la clave primaria de una
relación (identifica unívocamente cada tupla de la relación).
Restricción de unicidad (Unique)
Permite definir claves alternativas (los valores de uno o varios atributos no pueden
repetirse en diferentes tuplas de una relación)
Restricción de obligatoriedad (NOT NULL)
Permite declarar si uno o varios atributos de una relación deben tomar siempre un
valor, es decir no pueden tomar valores nulos.
Restricción de clave ajena (FOREIGN KEY) - Integridad referencial
“Si una relación R2 (relación que rerefencia) tiene un descriptor que es la clave
primaria de la relación R1 (relación referenciada) todo valor de dicho descriptor debe
concordar con un valor de la clave primaria de R1 o ser nulo”. El descriptor es una
clave foránea de la relación R2.
Los atributos que son clave ajena en una relación no necesitan tener los mismos
nombres que los atributos de la clave primaria con la cual ellos se corresponden.
La integridad referencial 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.
EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS) PK: NOMBRE_E
LIBRO (CODIGO, TITULO, IDIOMA, ..., NOMBRE_E) PK: CODIGO FK: NOMBRE_E
referencia a Editorial
En este ejemplo el atributo nombre_e de la relación LIBRO es clave foránea que
referencia a EDITORIAL, de modo que debe concordar con la clave primaria de la
relación EDITORIAL o bien ser nulo, porque los libros de nuestra base de datos
deberán pertenecer a una editorial existente, o si se desconoce la editorial, no se
tendrá ningún valor para este atributo.
AUTOR (NOMBRE, NACIONALIDAD, INSTITUCION, ..) PK: NOMBRE
LIBRO (CODIGO, TITULO, IDIOMA, EDITORIAL, ...) PK: CODIGO
ESCRIBE (NOMBRE, COD LIBRO) PK: NOMBRE+CODIGO FK: NOMBRE referencia
a Autor, CODIGO referencia a Libro
En este ejemplo la relación ESCRIBE posee dos claves foráneas: nombre, que
referencia a la relación AUTOR, y cod_libro, que referencia a la relación LIBRO; en
este caso ninguna de las dos claves ajenas puede tomar valores nulos, ya que forman
parte de la clave primaria de la relación ESCRIBE.
La regla de integridad referencial se enmarca en términos de estados de la base de
datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión
es ¿qué hacer si estando en un estado legal, llega una petición para realizar una
operación que conduce a un estado ilegal?
Además de la integridad referencial que nos permite enlazar relaciones entre si dando
lugar a la estructura de la BD, el modelo relacional permite también definir las
opciones de borrado y modificación en las claves ajenas. Estas opciones indican las
acciones que hay que llevar a cabo cuando se produce un borrado o modificación de
una tupla en la relación padre referenciada por una entidad hija. Las posibilidades para
una operación de actualización (borrado o modificación) son:

Operación restringida (RESTRICT): Borrar o modificar 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 foránea.
o
Para 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.

Operación con transmisión en cascada (CASCADE): El borrado o modificación
de tuplas de la relación que contiene la clave primaria referenciada lleva consigo el
borrado o modificación en cascada de las tuplas de la relación que contienen la
clave foránea.
o
Al modificar el nombre de una editorial en la relación EDITORIAL, se
tendría que modificar también dicho nombre en todos los libros de nuestra
base de datos publicados por dicha editorial.
o
Ej. Empleado (nombre, departamento, salario, fecha)
Departamento (numero_depto, nombre)
El borrado de un departamento supone un borrado de todos los empleados que
trabajan en él.

Operación con puesta a nulos (SET NULL): El borrado o modificación de tuplas
de la relación que contiene la clave primaria referenciada lleva consigo poner a
nulos los valores de las claves foráneas de la relación que referencia.
o
Cuando se borra una editorial, los libros que ha publicado dicha editorial y
que se encuentran en LIBRO se les coloque el atributo nombre_e a nulos.
Esta opción, obviamente, sólo es posible cuando el atributo que es clave
ajena admite el valor nulo.

Operación con puesta a valor por defecto (SET DEFAULT): El borrado o la
modificación de tuplas de la relación que contiene la clave primaria referenciada
lleva consigo poner el valor por defecto a la clave foránea de la relación que
referencia. Este valor debe ser definido al momento de crear la tabla
correspondiente.
o
En el ejemplo anterior, cuando se borra un determinado departamento, es
posible asignar a sus empleados a un departamento ficticio (que debe
encontrarse evidentemente en la relación Departamento)
Las opciones de borrado y modificación pueden ser distintas para determinada clave
foránea de una relación; por ejemplo, es posible definir el borrado en cascada y la
modificación restringida.
Nota: cuando las restricciones de integridad referencial afectan a varias tablas, hay
que tener en cuenta que la combinación de opciones puede generar graves problemas
de integridad.
Las opciones para la integridad referencial son:
B:C
Borrado en cascada
B:N
Borrado con puesta a nulos
B:D
Borrado con puesta a valor por defecto
B:R
Borrado restringido
M:C
Modificación en cascada
M:N
Modificación con puesta a nulos
M:D
Modificación con puesta a valor por defecto
M:R
Modificación restringida
Restricciones de verificación (CHECK)
En algunos casos puede suceder que sea necesario especificar una condición que
deben cumplir los valores de determinados atributos de una relación de la BD aparte
de las restricciones ya vistas de clave primaria, unicidad, obligatoriedad y clave ajena.
Para ellos se definen las restricciones de verificación que llevan implícitas un rechazo
en caso de que no se cumpla la condición especificada y que también se comprueban
antes una inserción, borrado o modificación. Por ejemplo, para la relación Empleado
podría definirse una restricción sobre el atributo salario que establezca que “el rango
del salario de un empleado puede oscilar entre los $150.000 y los $300.000. Así, si se
va insertar un empleado con un sueldo superior o inferior, la operación se rechazaría.
Reglas de negocio
Además de las reglas de integridad anteriores, los usuarios o los administradores de la
base de datos pueden imponer ciertas restricciones específicas sobre los datos,
denominadas reglas de negocio.
Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta
veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al
respecto y debe hacerla respetar. En este caso, no debería permitir un nuevo
empleado en una oficina que ya tiene los veinte permitidos.
Hoy en día aún existen SGBD relacionales que no permiten definir este tipo de
restricciones ni las hacen respetar.