integridad referencial

INTEGRIDAD REFERENCIAL
Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones
modi caciones 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 base de datos contiene unos datos que, en cada momento, deben reflejar la realidad o, más
concretamente, la situación de una porción del mundo real. En el caso de las bases de datos
dato relacionales,
esto significa que las tuplas o filas que contienen las relaciones deben tener valores que reflejen la realidad
correctamente.
Ejemplo:
En la relación de esquema EMPLEADOS(DNI, nombre, apellido, sueldo), una tupla que tiene un valor de –1.000
para el sueldo probablemente no tiene sentido, porque los sueldos no pueden ser negativos. Como es
evidente, para que los datos sean íntegros, es preciso que cumplan varias condiciones.
El hecho de que los sueldos no puedan ser negativos es una condición
condición que se debería cumplir en la relación
EMPLEADOS.
En general, las condiciones que garantizan la integridad de los datos pueden ser de dos tipos:
1) Las restricciones de integridad de usuario son condiciones específicas de una base de datos concreta;
con
es
decir, son las que se deben cumplir en una base de datos particular con unos usuarios concretos, pero que
no son necesariamente relevantes en otra base de datos.
Restricción de integridad de usuario en EMPLEADOS
Éste sería el caso de la condiciónn anterior, según la cual los sueldos no podían ser negativos.
Observe que esta condición era necesaria en la base de datos concreta de este ejemplo porque aparecía el atributo
sueldo, al que se quería dar un significado; sin embargo, podría no ser necesaria
ria en otra base de datos diferente
donde, por ejemplo, no hubiese sueldos.
sueldos
2) Las reglas de integridad de modelo,
modelo en cambio, son condiciones más generales, propias de un modelo de
datos, y se deben cumplir en toda base de datos que siga dicho modelo.
Ejemplo
emplo de regla de integridad del modelo de datos relacional
En el caso del modelo de datos relacional, habrá una regla de integridad para garantizar que los valores de una
clave primaria de una relación no se repitan en tuplas diferentes de la relación. Toda
da base de datos relacional debe
cumplir esta regla que, por lo tanto, es una regla de integridad del modelo.
Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de una base de
datos; una vez definidas, deben velar por
p su cumplimiento.
Lass reglas de integridad del modelo, en cambio, no se deben definir para cada base de datos concreta,
porque se consideran preestablecidas para todas las base de datos de un modelo. Un SGBD de un modelo
determinado debe velar por el cumplimiento
mplimiento de las reglas de integridad preestablecidas por su modelo.
A continuación estudiaremos con detalle las reglas de integridad del modelo relacional, reglas que todo
SGBD relacional debe obligar a cumplir.
1. REGLA DE INTEGRIDAD
AD DE UNICIDAD DE LA CLAVE PRIMARIA
La regla de integridad de unicidad está relacionada con la definición de clave primaria. Concretamente,
establece que toda clave primaria que se elija para una relación no debe tener valores repetidos.
Ejemplo
Tenemos la siguiente relación:
SALON
ID_SALON
101
102
103
103
ID_EDIFICIO
13
13
14
15
DIMENSIÓN
10
14
20
13
En esta relación, dado que la clave primaria está formada por ID-SALON y ID-EDIFICIO,
EDIFICIO, no hay ningún salón que
repita tanto id-edificio como número de otro salón. Sin embargo, sí se repiten valores de id-edificio (por ejemplo,
13);); y también se repiten valores de id-salón (103). A pesar de ello, el edificio y el número no se repiten nunca al
mismo tiempo.
Un SGBD relacional deberá garantizar el cumplimiento de esta regla de integridad en todas las inserciones,
así como en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la
relación.
CÓDIGO CREACIÓN DE CLAVE PRIMARIA (PRIMARY KEY) EN MYSQL
Create table salon(
Id_salon integer not null,
Id_edificio
edificio integer not null,
Dimension integer not null,
PRIMARY KEY(ID_SALON,ID_EDIFICIO
EDIFICIO));
2. REGLA DE INTEGRIDAD DE ENTIDAD DE LA CLAVE PRIMARIA
La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una
relación no puedan tener valores nulos.
Ejemplo
Tenemos la siguiente relación:
SALON
ID-SALON
101
102
103
103
ID-EDIFICIO
13
13
14
15
DIMENSIÓN
10
14
20
13
En esta relación, puesto que la clave primaria está formada por ID-EDIFICIO y ID-SALÓN, no hay ningún salón
que tenga un valor nulo para id-edificio, ni tampoco para id-salón.
Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas
individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas
no se pudieran distinguir.
Un SGBD relacional tendrá que garantizar el cumplimiento de esta regla de integridad en todas las
inserciones y, también, en todas las modificaciones que afecten a atributos que pertenecen a la clave
primaria de la relación.
Establecer valores no nulos (NOT NULL) en MYSQL
Cuando se crean las tablas, los campos que se requieren que sean NO NULOS deben tener
la sentencia NOT NULL después de especificar el tipo de dato:
Create table salon(
Id_salon integer NOT NULL,
Id_edificio integer NOT NULL,
Dimension integer NOT NULL,
Primary key(id_salon,id_edificio));
3. REGLA DE INTEGRIDAD
AD REFERENCIAL
La regla de integridad referencial está relacionada con el concepto de clave foránea. Concretamente,
determina que todos los
os valores que toma una clave foránea deben ser valores nulos o valores que existen
en la clave primaria que referencia.
Ejemplo
Si tenemos las siguientes relaciones:
SALON
ID-SALON
101
102
103
103
ID-EDIFICIO
13
13
14
15
ESTUDIANTES
DIMENSIÓN
10
14
20
13
CODIGO
12376876
32345412
22312376
34345645
NOMBRE
JUAN
FEDERICO
ANTONIO
FERNANDO
APELLIDO
ROJAS
PEREZ
DIAZ
LALINDE
SALON_IDSALON
SALON
101
101
102
103
SALON_IDEDIFICIO
13
13
13
15
Donde SALON-ID-EDIFICIO y SALON-ID-SALON
SALON
de la relación ESTUDIANTES forman una clave foránea que referencia la
relación SALÓN.. Debe ocurrir que los valores no nulos de SALON-ID-EDIFICIO y SALON-ID-SALON
SALON
de la relación
ESTUDIANTES estén en la relación SALÓN como valores de ID-SALON y ID-EDIFICIO.
EDIFICIO. Por ejemplo, el empleado
<22312376, ANTONIO DIAZ, 102,13>> tiene el valor 13 para ID-EDIFICIO y el valor 102 para ID--SALÓN, de modo que en la
relación SALÓN hay un salón con valor 13 para ID-EDIFICIO y con valor 102 para ID-SALÓN.
La necesidad
sidad de la regla de integridad relacional
r
proviene del hecho de que las claves foráneas tienen por
objetivo establecer una conexión con la clave primaria que referencian. Si un valor de una clave foránea no
estuviese presente en la clave primaria correspondiente, representaría una referencia
refere
o una conexión
incorrecta.
Código de creación de clave foránea (FOREIGN KEY) en MYSQL
Create table salon(
Id_salon integer not null,
Id_edificio
edificio integer not null,
Dimension integer not null,
Primary key(id_salon,id_edificio
,id_edificio));
Create table estudiantes(
Codigo integer not null,
Nombre varchar(20) not null,
Apellido
o varchar(20) not null,
Salon_idsalon integer not null,
Salon_idedificio
ificio integer not null,
null
Primary key(codigo),
FOREIGN KEY (SALON_IDSALON,SALON_ID
ALON_IDEDIFICIO) REFERENCES SALON(ID_SALON,ID_EDIFICIO));
SALON(ID_SALON,ID_ED
Un SGBD relacional tendrá que hacer cumplir esta regla de integridad. Deberá efectuar comprobaciones
cuando se produzcan las siguientes operaciones:
a) Inserciones en una relación que tenga una clave foránea.
f
b) Modificaciones
caciones que afecten a atributos que pertenecen a la clave foránea de una relación.
c) Borrados en relaciones referenciadas por otras relaciones.
d) Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relación referenciada
por otra relación.
Ejemplo
Retomamos el ejemplo anterior, donde salón-id-edificio y salón-id-salón de la relación ESTUDIANTES forman
una clave foránea que referencia la relación SALON.
SALON
ID-SALON
101
102
103
103
ID-EDIFICIO
13
13
14
15
ESTUDIANTES
DIMENSIÓN
10
14
20
13
CODIGO
12376876
32345412
22312376
34345645
NOMBRE
JUAN
FEDERICO
ANTONIO
FERNANDO
APELLIDO
ROJAS
PEREZ
DIAZ
LALINDE
SALON-IDSALON
SALON
101
101
102
103
SALON- ID-EDIFICIO
13
13
13
15
Las siguientes operaciones provocarían el incumplimiento
incump
de la regla de integridad referencial:
• Inserción de <12764411, JOSE, RIOS, 105,15>
105,15 en ESTUDIANTES.
Incumple la regla de integridad referencial porque
p
el salón 105, edificio 15 no existe en la relación SALON.
SALON
• Modificación de <34345645,
34345645, FERNANDO,
FERNANDO LALINDE, 103,15,> de ESTUDIANTES por <34345645,
34345645, FERNANDO,
FERNANDO LALINDE, 101,16>.
Incumple la regla de integridad referencial porque
p
el salón 101, edificio 16 no existe en la relación SALON.
SALON
• Borrado de <101,13,10> de SALÓN.
Incumple la regla de integridad referencial porque
p
está referenciado en la tabla estudiantes.
• Modificación de <101,13,10> de SALÓN por <107, 13, 10>.
Incumple la regla de integridad referencial porque está modificando id-salón
id
que es un atributo
ibuto que pertenece a la clave
primaria de SALON que a su vez está referenciada por la relación ESTUDIANTES en la tupla 1 y 2.
Un SGBD relacional debe procurar que se cumplan las reglas de integridad del modelo. Una forma habitual de
mantener estas reglas
as consiste en rechazar toda operación de actualización que deje la base de datos en un
estado en el que alguna regla no se cumpla. En algunos casos, sin embargo, el SGBD tiene la posibilidad de
aceptar la operación y efectuar acciones adicionales compensatorias,
compensa
de modo que el estado que se obtenga
satisfaga las reglas de integridad, a pesar de haber ejecutado la operación.
Esta última política se puede aplicar en las siguientes operaciones de actualización que violarían la regla de
integridad:
a) Borrado de una tupla que tiene una clave primaria referenciada.
b) Modificación de los valores de los atributos de la clave primaria de una tupla que tiene una clave primaria
referenciada.
En los casos anteriores, algunas de las políticas que se podrán aplicar serán las siguientes: restricción,
actualización en cascada y anulación. A continuación explicamos el significado de las tres posibilidades
mencionadas.
Restricción
La política de restricción consiste en no aceptar la operación de actualización.
Más concretamente, la restricción en caso de BORRADO, consiste en NO permitir borrar una tupla si tiene
una clave primaria referenciada por alguna clave foránea.
De forma similar, la restricción en caso de MODIFICACION consiste en NO permitir modificar ningún atributo
de la clave primaria de una tupla si tiene una clave primaria referenciada por alguna clave foránea.
Ejemplo:
Supongamos que tenemos las siguientes relaciones, donde departamento se relaciona con empleados de uno
a muchos. La clave primaria de departamento (cod_dep) se referencia como clave foránea en Empleados
(dept_cod_dep).
DEPARTAMENTO
NOMBRE
COD_DEP
Ventas
10
sistemas
20
Comercial
30
UBICACION
Bogotá
Cali
Pereira
EMPLEADOS
COD_EMP
1232
2124
5467
NOMBRE
María
Nubia
Wilson
APELLIDO
Rodas
Pérez
Quiroz
DEPT_COD_DEP∗
10
10
20
a) Si aplicamos la restricción en caso de borrado y, por ejemplo, queremos borrar al departamento de
VENTAS, no podremos hacerlo porque tiene empleados asociados que lo referencian.
Implementar RESTRICCION en caso de BORRADO en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES DEPARTAMENTO(COD_DEP) ON DELETE RESTRICT);
∗
DEPT_COD_DEP clave foránea referenciada de la tabla departamento
b) Si aplicamos la restricción en caso de modificación y queremos modificar el número del departamento 20,
no será posible hacerlo porque también tiene empleados asociados que lo referencian.
Implementar RESTRICCION en caso de MODIFICACION en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES DEPARTAMENTO(COD_DEP) ON UPDATE RESTRICT);
Actualización en cascada
La política de actualización en cascada consiste en permitir la operación de actualización de la tupla, y en
efectuar operaciones compensatorias que propaguen en cascada la actualización a las tuplas que la
referenciaban; se actúa de este modo para mantener la integridad referencial.
Más concretamente, la actualización en cascada en caso de borrado consiste en permitir el borrado de una
tupla t que tiene una clave primaria referenciada, y borrar también todas las tuplas que referencian t.
De forma similar, la actualización en cascada en caso de modificación consiste en permitir la modificación
de atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y modificar del
mismo modo todas las tuplas que referencian t.
Ejemplo:
Supongamos que tenemos las siguientes relaciones, donde departamento se relaciona con empleados de uno
a muchos. La clave primaria de departamento (cod_dep) se referencia como clave foránea en Empleados
(dept_cod_dep).
DEPARTAMENTO
NOMBRE
COD_DEP
Ventas
10
sistemas
20
Comercial
30
UBICACION
Bogotá
Cali
Pereira
EMPLEADOS
COD_EMP
1232
2124
5467
NOMBRE
María
Nubia
Wilson
APELLIDO
Rodas
Pérez
Quiroz
DEPT_COD_DEP
10
10
20
a) Si aplicamos la actualización en cascada en caso de borrado y, por ejemplo, queremos borrar el
departamento de Ventas, se borrarán también los empleados María Rodas y Nubia Pérez que están
asociados al departamento de ventas. Y nos quedará:
DEPARTAMENTO
NOMBRE
COD_DEP
sistemas
20
Comercial
30
UBICACION
Cali
Pereira
EMPLEADOS
COD_EMP NOMBRE
Wilson
5467
APELLIDO
Quiroz
DEPT_COD_DEP
20
Implementar ACTUALIZACIÓN EN CASACADA en caso de BORRADO en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES DEPARTAMENTO(COD_DEP) ON DELETE CASCADE);
b) Si aplicamos la actualización en cascada en caso de modificación, y queremos modificar el código del
departamento 20 por 21, también se cambiará el 20 por 21 en el empleado 5467 Wilson Quiroz 20. Y nos
quedará:
DEPARTAMENTO
NOMBRE
COD_DEP
sistemas
21
Comercial
30
UBICACION
Cali
Pereira
EMPLEADOS
COD_EMP NOMBRE
Wilson
5467
APELLIDO
Quiroz
DEPT_COD_DEP
21
Implementar ACTUALIZACIÓN EN CASACADA en caso de MODIFICIACION en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES DEPARTAMENTO(COD_DEP) ON UPDATE CASCADE);
ANULACION
Ésta política consiste en permitir la operación de actualización de la tupla y en efectuar operaciones
compensatorias que pongan valores nulos a los atributos de la clave foránea de las tuplas que la
referencian; esta acción se lleva a cabo para mantener la integridad referencial.
Puesto que generalmente los SGBD relacionales permiten establecer que un determinado atributo de una
relación no admite valores nulos, sólo se puede aplicar la política de anulación si los atributos de la clave
foránea sí los admiten.
Más concretamente, la anulación en caso de borrado consiste en permitir el borrado de una tupla t que tiene
una clave referenciada y, además, modificar todas las tuplas que referencian t, de modo que los atributos de
la clave foránea correspondiente tomen valores nulos.
De forma similar, la anulación en caso de modificación consiste en permitir la modificación de atributos de la
clave primaria de una tupla t que tiene una clave referenciada y, además, modificar todas las tuplas que
referencian t, de modo que los atributos de la clave foránea correspondiente tomen valores nulos.
EJEMPLO:
DEPARTAMENTO
NOMBRE
COD_DEP
Ventas
10
sistemas
20
Comercial
30
UBICACION
Bogotá
Cali
Pereira
EMPLEADOS
COD_EMP
1232
2124
5467
NOMBRE
María
Nubia
Wilson
APELLIDO
Rodas
Pérez
Quiroz
DEPT_COD_DEP
10
10
20
a) Si aplicamos la anulación en caso de borrado y, por ejemplo, queremos borrar al departamento de
ventas, se modificarán todos los empleados asociados y pasarán a tener un valor nulo en DEPT_COD_DEP.
Quedará así:
DEPARTAMENTO
NOMBRE
COD_DEP
sistemas
20
Comercial
30
UBICACION
Cali
Pereira
EMPLEADOS
COD_EMP
1232
2124
5467
NOMBRE
María
Nubia
Wilson
APELLIDO
Rodas
Pérez
Quiroz
DEPT_COD_DEP
NULL
NULL
20
Implementar ANULACION en caso de BORRADO en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES DEPARTAMENTO(COD_DEP) ON DELETE SET NULL);
b) Si aplicamos la anulación en caso de modificación, y ahora queremos cambiar el número del
departamento 20 por 22, se modificarán todos los empleados asociados
asociados y pasarán a tener un valor
nulo en DEPT_COD_DEP. Quedará así:
DEPARTAMENTO
NOMBRE
COD_DEP
sistemas
22
Comercial
30
UBICACION
Cali
Pereira
EMPLEADOS
COD_EMP
1232
2124
5467
NOMBRE
María
Nubia
Wilson
APELLIDO
Rodas
Pérez
Quiroz
DEPT_COD_DEP
NULL
NULL
NULL
Implementar ANULACION en caso de MODIFICACION en MYSQL
Create table departamento(
Cod_dep integer not null,
Nombre varchar(20) not null,
Ubicacion varchar(20) not null,
Primary key(cod_dep));
Create table empleados(
Cod_emp integer not null,
null
Nombre varchar(25) not null,
Apellido varchar(25) not null,
Dept_cod_dep
cod_dep integer not null,
Primary key(cod_emp),
FOREIGN KEY(DEPT_COD_DEP) REFERENCES
EFERENCES DEPARTAMENTO(COD_DEP)
DEPARTAMEN
ON UPDATE SET NULL);
Selección de la política de mantenimiento de la integridad referencial
Hemos visto que en caso de borrado o modificación de una clave primaria referenciada por alguna clave foránea hay
varias políticas de mantenimiento de la regla de integridad referencial.
El diseñador puede elegir para cada clave foránea qué política se aplicará en caso de borrado de la clave primaria
referenciada, y cuál en caso de modificación de ésta. El diseñador deberá tener en cuenta el significado de cada clave
foránea
oránea concreta para poder elegir adecuadamente.
adecuadamente
BIBLIOGRAFÍA
Abraham Silberschatz, Henry F. Korth,
th, S. Sudarshan. FUNDAMENTOS DE BASES DE DATOS, Cuarta edición, Copyright ©
MMI, por McGraw-Hill Inc. ISBN: 0-07-228363
228363-7