Restricciones de Integridad

Sesión 04

Ms. Adrián G. Arce Holgado

 Definición
• Son reglas que siempre deben cumplirse de modo de apoyar la integridad de la base de
datos.

• E.d., que la BD cumpla fielmente con el mundo modelado.

• Proporcionan un medio de asegurar que las modificaciones hechas a la base de datos

no provoquen la pérdida de la consistencia de los datos.

• Una BD sera 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.
• 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 relacion 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 atomicos)
• 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 relacion puede tomar un valor nulo”.
• Restricciones de usuario (también
llamadas restricciones semánticas)
• Restricción de clave primaria (PRIMARY KEY)
• Permite declarar un atributo o conjunto de atributos como
la clave primaria de una relacion.

• Restricción de unicidad (Unique)

• Permite definir claves alternativas (los valores de uno o
varios atributos no pueden repetirse en diferentes tuplas de
una relacion)

• Restricción de obligatoriedad (NOT NULL)

• Permite declarar si uno o varios atributos de una relacion
deben tomar siempre un valor, es decir no pueden tomar
valores nulos.
• Restricción de clave ajena (FOREIGN KEY) - Integridad
referencial
• “Si una relacion R2 (relacion que rerefencia) tiene un descriptor
que es la clave primaria de la relacion R1 (relacion 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
foranea de la relacion R2.
• Los atributos que son clave ajena en una relacion no necesitan
tener los mismos nombres que los atributos de la clave primaria
con la cual ellos se corresponden.
• Viene impuesta por el mundo real y es el usuario quien la define
al describir el esquema relacional.
• Es de tipo implícito: se define en el esquema y el modelo la
reconoce sin necesidad de programar ni 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

• El atributo nombre_e de la relación LIBRO es clave foranea

que referencia a EDITORIAL.
• Debe concordar con la clave primaria de la relación
EDITORIAL o bien ser nulo.
• Los libros de nuestra BD 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

• La relación ESCRIBE posee dos claves foraneas: nombre, que

referencia a la relación AUTOR, y cod_libro, que referencia a
la relación LIBRO.
• Ninguna de las dos claves ajenas puede tomar valores nulos,
ya que forman parte de la clave primaria de la relación
ESCRIBE.
• El modelo relacional permite tambien definir las opciones de borrado y
modificacion en las claves ajenas.

• Indican las acciones que hay que llevar a cabo cuando se produce un borrado o
modificacion de una tupla en la relacion padre referenciada por una entidad hija.
• 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 foranea.

• Ej. 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
foranea.

• Ej. 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.

• Ej. El borrado de un departamento supone un borrado de todos

los empleados que trabajan en él.
• Empleado (nombre, departamento, salario, fecha)
• Departamento (numero_depto, nombre)
• 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 foraneas de la relación que referencia.

• 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 foranea de la relación que
referencia.
• Este valor debe ser definido al momento de crear la tabla
correspondiente.

• 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 relacion Departamento)
• Las opciones de borrado y modificacion pueden ser distintas
para determinada clave foranea de una relacion; por
ejemplo, es posible definir el borrado en cascada y la
modificacion 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 Modificacion en cascada
• M:N Modificacion con puesta a nulos
• M:D Modificacion con puesta a valor por defecto
• M:R Modificacion restringida
• Restricciones de verificación (CHECK)
• Puede suceder que sea necesario especificar una condicion
que deben cumplir los valores de determinados atributos de
una relacion de la BD.
• Para ellos se definen las restricciones de verificación.
• Llevan implicitas un rechazo en caso de que no se cumpla la
condicion especificada y que tambien se comprueban antes
una inserción, borrado o modificacion.

• Por ejemplo, para la relacion Empleado podria 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 a insertar un empleado con un sueldo superior o
inferior, la operación se rechazaria.
• 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.

• Si en una oficina 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.
 Ejemplo: Colección personal de discos
• Contexto:
– Se tiene una colección de varios discos
– Cada disco tiene un interprete
– Un interprete puede tener uno o más discos
– Cada disco tiene varias canciones.
– Una canción puede salir en uno o más discos
• Se desea:
– Obtener el nombre, año e interprete del disco que contiene la canción
“The Number of the Beast”.
– Listado con nombres de discos y sus respectivas canciones del
interprete “Dream Theater”
 Introducción
• Estos modelos surgen de la necesidad de mecanismos que
capten con mayor facilidad la semántica del mundo real,
mejorando la calidad de diseño de sistemas.

• Visualiza los datos en forma unificada, centrándose en las

estructuras lógicas y abstractas de datos como representación
del mundo real, con independencia de consideraciones de tipo
físico.
 Definición
• Generalmente todo modelo tiene una representación gráfica, para el
caso de datos el modelo más popular es el modelo entidad-relación o
digrama E/R.
• Se denomina así debido a que precisamente permite representar
relaciones entre entidades (objetivo del modelado de datos).
• El modelo debe estar compuesto por:
– Entidades
– Atributos
– Relaciones
– Llaves
 Entidades
Cualquier tipo de objeto o concepto sobre el que se recoge
información.
En nuestro ejemplo:
• Discos
• Intérpretes
• Canciones
 Atributos
Es una característica de interés o un hecho sobre una entidad o
sobre una relación.

En nuestro ejemplo:

• Discos: Nombre, Año, Sello, Comentario, Id_disco.

• Intérpretes: Nombre, país, id_interprete.
• Canciones: Nombre, duración, id_canción.
 Relaciones
• Una relación o vínculo entre dos o más entidades
describe alguna interacción entre las mismas.

• Las relaciones evitan redundancia de datos

guardados en las tablas.
 Relaciones – Uno a uno
Relaciona un único registro de la tabla principal con
uno sólo de la tabla relacionada. Este tipo de relación
produce el mismo resultado que si se unieran los
campos de ambas tablas en una sola tabla.
 Relaciones – Uno a varios
Es el tipo de relación más frecuente. Un único registro
de la tabla principal se puede relacionar con varios de
la tabla relacionada. Este tipo de relación es la que
utilizaremos la mayoría de las veces.
 Relaciones – Varios a varios
• Un registro de la tabla principal se relaciona con
varios de la tabla relacionada y, además, un registro
de la tabla relacionada se relaciona con varios de la
tabla principal.
 Relaciones – Varios a varios (solución)
• Este tipo de relaciones se puede transformar en dos
relaciones de tipo uno a varios, creando una tabla
intermedia de unión.
 Llave principal y secundaria
• PK (Primary Key), es una clave que identifica
univocamente a un registro de otro.

• FK (Foreign Key), es una clave que ayuda a relacionar

las tablas, usando la PK de la tabla a la cual se hace
referencia.
Ejemplo
 Metodología para diseño del MER
1. Identificar Entidades (Sustantivos)
2. Identificar Relaciones (Verbos)
3. Identificar atributos de entidades
4. Identificar llaves primarias
5. Establecer cardinalidades
 Caso 01
Se requiere construir un sistema de información en el
que se requiere tener la información sobre las viviendas
urbanas del país y las personas que las habitan. Cada
persona solo puede habitar una vivienda, pero puede ser
propietaria de más de una. (Como simplificador, las
ciudades pertenecen a regiones).
 01 - Identificar sustantivos  entidades

Se requiere construir un sistema de información en el que se

requiere tener la información sobre las viviendas urbanas del país
y las personas que las habitan. Cada persona solo puede habitar
una vivienda, pero puede ser propietaria de más de una. (Como
simplificador, las ciudades pertenecen a regiones).

personas viviendas ciudades regiones

 02 - Identificar verbos  relaciones

Se requiere construir un sistema de información en el que se

requiere tener la información sobre las viviendas urbanas del país
y las personas que las habitan. Cada persona solo puede habitar
una vivienda, pero puede ser propietaria de más de una. (Como
simplificador, las ciudades pertenecen a regiones).
02 - Identificar verbos  relaciones
 03 - Identificar atributos
• Personas : DNI y Nombre
• Viviendas : Dirección
• Ciudades : Nombre
• Regiones : Nombre
 04 – Identificar llaves primarias (FK)
• Personas: DNI Nota: las llaves primarias se
• Viviendas: Id_vivienda denotan por PK (Primary
• Ciudades: Id_ciudad Key), y usaremos la
siguiente forma de
• Regiones: Id_región representación:

PK: DNI
04 – Identificar llaves primarias (FK)
PK: id_vivienda
dirección

Habita

PK: DNI personas viviendas

Pertenece
PK: id_ciudad
nombre
Es propietaria
ciudades

nombre
PK: id_region

nombre regiones Estan

 05 – Establecer cardinalidades

Se requiere construir un sistema de información en el que

se requiere tener la información sobre las viviendas
urbanas del país y las personas que las habitan. Cada
persona solo puede habitar una vivienda, pero puede
ser propietaria de más de una. (Como simplificador, las
ciudades pertenecen a regiones).
 05 – Establecer cardinalidades

• Entonces…
• Una persona es propietaria de N viviendas, y una
vivienda es propiedad de 1 sola persona.
• En las viviendas pueden habitar N personas, y una
persona puede habitar en 1 sola vivienda.
• Una ciudad puede tener N viviendas, y una vivienda
pertenece a sólo 1 ciudad.
• Una región puede tener N ciudades, y una ciudad
pertenece a sólo 1 región.
05 – Establecer cardinalidades
 05 – Establecer cardinalidades
• Como parte de este paso, nace una llave llamada FK
(Foreign Key), llave foránea, que es el identificador que
relaciona de forma real las entidades (como otro
atributo de la entidad principal).
• Esta se toma desde la punta de la relación con 1 a la
que tiene N.
• Para ello se traspasa la PK de la entidad con
cardinalidad 1, como FK a la entidad con cardinalidad
N.
 05 – Establecer cardinalidades
PK: id_vivienda FK: DNI
dirección
FK: id_vivienda
1 FK: id_ciudad
Habita
N
N
PK: DNI personas viviendas

1 N Pertenece
PK: id_ciudad
1
nombre
Es propietaria
ciudades

PK: id_region nombre N

FK: id_region

nombre regiones Estan

1
 Solución
PK
:Id_vivien dirección
da FK
FK :Id_ciud
:Id_vivien ad
da FK: DNI
N 1
Habita

PK: DNI personas viviendas N

nombre pertenece

Es propietaria

PK 1 FK
1 N :Id_ciud
:Id_region
ad
ciudades

nombre
N
nombre

1
PK regiones estan
:Id_region
 Caso práctico
• Se necesita el diseño de una BD simple para un banco
que contenga la información de los clientes, las
cuentas, las sucursales y las transacciones producidas.
• Se debe tener en cuenta las siguientes restricciones:
 Un cliente puede tener muchas cuentas.
 Una cuenta puede pertenecer a muchos clientes, pero
solo uno de ellos es el titular.
 Una cuenta está asociada a una sucursal.
 Con respecto a las transacciones solo se requiere
almacenar el número de la transacción, la cuenta que la
origino, la fecha y el monto.