Temas Semana 7 Unidad 3

Contenido de la Unidad 3
Contenido
3.4. Restricciones ............................................................................................................... 1
Restricciones Inherentes del Modelo Relacional. ............................................................. 1
Restricciones Semánticas o de Usuario. .......................................................................... 3
3.5. Integridad de dominio ................................................................................................... 5
Semana 7 Unidad 3 - del 04 de marzo al 10 de marzo
3.4. Restricciones
Restricciones Inherentes del Modelo Relacional.
• No existen tuplas repetidas (obligatoriedad de clave primaria). La relación se ha

definido como un conjunto de tuplas, y en matemáticas los conjuntos por definición
no incluyen elementos repetidos. Hay que decir, sin embargo, que muchos de los SGBD
relacionales sí admiten duplicidad de tuplas.
• El orden de las tuplas y el de los atributos no es relevante.
• Cada atributo de cada tupla solo puede tomar un único valor sobre el dominio sobre el
que está definido.
• Ningún atributo que forme parte de la clave primaria de una relación puede tomar un
valor nulo (regla de integridad de entidad)
Estas restricciones son las que marcan la diferencia entre una tabla y una relación, ya que una
tabla presenta las filas y las columnas en un orden, del cual carecen las relaciones. Por otro
lado, una tabla podría contener filas repetidas. De todos modos, es muy común utilizar el
término tabla para referirse a una relación.
Las 12 reglas de Codd
Preocupado por los productos que decían ser sistemas gestores de bases de datos
relacionales (RDBMS) sin serlo, Codd publica las 12 reglas que debe cumplir todo DBMS para
ser considerado relacional. Estas reglas en la práctica las cumplen pocos sistemas
relacionales. Las reglas son:
1
1. Información. Toda la información de la base de datos debe estar representada
explícitamente en el esquema lógico. Es decir, todos los datos están en las tablas.
2. Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre

de la columna o atributo que contiene el dato
3. Tratamiento sistemático de los valores nulos. El DBMS debe permitir el tratamiento

adecuado de estos valores.
4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser

accesibles usando un esquema relacional.
5. Sublenguaje de datos completo. Al menos debe de existir un lenguaje que permita el

manejo completo de la base de datos. Este lenguaje, por lo tanto, debe permitir realizar
cualquier operación.
6. Actualización de vistas. El DBMS debe encargarse de que las vistas muestren la última
información.
7. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de

modificación debe actuar sobre conjuntos de filas, nunca deben actuar registro a
registro.
8. Independencia física. Los datos deben de ser accesibles desde la lógica de la base de
datos aún cuando se modifique el almacenamiento.
9. Independencia lógica. Los programas no deben verse afectados por cambios en las
tablas.
10. Independencia de integridad. Las reglas de integridad deben almacenarse en la base

de datos (en el diccionario de datos), no en los programas de aplicación.
2
11. Independencia de la distribución. El sublenguaje de datos debe permitir que sus
instrucciones funcionen igualmente en una base de datos distribuida que en una que
no lo es.
12. No subversión. Si el DBMS posee un lenguaje que permite el recorrido registro a

registro, éste no puede utilizarse para incumplir las reglas relacionales.
Restricciones Semánticas o de Usuario.
1. Restricción de Clave Primaria (PRIMARY KEY), permite declarar un atributo o conjunto

de atributos como la clave primaria de una relación.
2. Restricción de Unicidad (UNIQUE), permite que una clave alternativa o secundaria

pueda tomar valores únicos para las tuplas de una relación (como si de una clave
primaria se tratara). Se entiende que la clave primaria siempre tiene esta restricción.
3. Restricción de Obligatoriedad (NOT NULL), permite declarar si uno o varios atributos

de una relación debe tomar siempre un valor.
4. Restricción de Integridad Referencial o de Clave Foránea (FOREIGN KEY), se utiliza para

que mediante claves foráneas podamos enlazar relaciones de una base de datos. La
integridad referencial nos indica que si una relación tiene una clave foránea que
referencia a otra relación, cada valor de la clave foránea o ajena tiene que ser igual a un
valor de la clave principal de la relación a la que referencia, o bien, ser completamente
nulo. Los atributos que son clave foránea en una relación no necesitan tener los
mismos nombres que los atributos de la clave primaria con la cual ellos se
corresponden. El diseñador de la base de datos deberá poder especificar qué
operaciones han de rechazarse y cuáles han de aceptarse, y en este caso, qué
operaciones de compensación hay que realizar para mantener la integridad de la base
de datos. Para ello el diseñador debe plantearse tres preguntas por cada clave foránea:
1. ¿Puede aceptar nulos esa clave foránea? Por ejemplo, (tomando como referencia las
relaciones PROVEEDORES, ARTICULOS) ¿tiene sentido la existencia de un articulo
cuyo proveedor se desconoce? Evidentemente, no. En algunos casos esta respuesta
podría ser distinta, por ejemplo, en una base de datos con las relaciones EMPLEADOS
3
y DEPARTAMENTOS, podría existir un empleado no asignado de momento a un
departamento.
2. ¿Qué deberá suceder si se intenta eliminar una tupla referenciada por una clave
foránea? Por ejemplo, si se intenta eliminar un proveedor del cual existe algún artículo.
En general, para estos casos existen por lo menos tres posibilidades:
• Restringir: La operación de eliminación se restringe sólo al caso en el que no existe

alguna tupla con clave foránea que la referencie, rechazándose en caso contrario.
En nuestro ejemplo, un proveedor podrá ser borrado, si y sólo si, por ahora, no
suministra artículos.
• Propagar en cascada: La operación de borrado se propaga en cascada eliminando

también todas las tuplas cuya clave foránea la referencien. En nuestro ejemplo, se
eliminaría el proveedor y todas las tuplas de artículos suministrados por él.
• Anular: Se asignan nulos en la clave foránea de todas las tuplas que la referencien
y se elimina la tupla referenciada. En nuestro ejemplo, no tiene mucho sentido,
pero consistiría en asignar nulos al NIF-PROV de todas las tuplas de articulos
pertenecientes al proveedor que queremos borrar, y posteriormente borrar al
proveedor.
3. ¿Qué deberá suceder si hay un intento de modificar la clave primaria de una tupla
referenciada por una clave foránea? Por ejemplo, si se intenta modificar la clave de un
proveedor del cual existe algún artículo. Se actúa con las mismas tres posibilidades
que en el caso anterior:
• Restringir
• Propagar en cascada.
• Anular
4. Restricción de Valor por Defecto (DEFAULT), permite que cuando se inserte una tupla
o registro en una tabla, para aquellos atributos para los cuales no se indique un valor
exacto se les asigne un valor por defecto.
5. Restricción de Verificación o Chequeo (CHECK), en algunos casos puede ocurrir que

sea necesario especificar una condición que deben cumplir los valores de
4
determinados atributos de una relación de la BD, aparte de las restricciones vistas
anteriormente.
6. Aserciones (ASSERTION): Esta restricción generaliza a la anterior, lo forman las

aserciones en las que la condición se establece sobre elementos de distintas
relaciones (por ello debe tener un nombre que la identifique).
7. Disparadores (TRIGGERS), a veces puede interesar espeficar una acción distinta del
rechazo cuando no se cumple una determinada restricción semántica. En este caso,
se recurre al uso de disparadores o triggers que nos permiten además de indicar una
condición, especificar la acción que queremos que se lleve a cabo si la condición se
hace verdadera. Los disparadores pueden interpretarse como reglas del tipo evento-
condición-acción (ECA) que pueden interpretarse como reglas que especifican que
cuando se produce un evento, si se cumple una condición, entonces se realiza una
determinada acción.
3.5. Integridad de dominio
La regla de integridad de dominio está relacionada, como su nombre indica, con la noción de
dominio. Esta regla establece dos condiciones.
La primera condición consiste en que un valor no nulo de un atributo 𝐴𝑖 debe pertenecer al

dominio del atributo 𝐴𝑖 ; es decir, debe pertenecer a dominio (𝐴𝑖 ).
Esta condición implica que todos los valores no nulos que contiene la base de datos para un
determinado atributo deben ser del dominio declarado para dicho atributo.
Ejemplo
• Si en la relación EMPLEADOS (DNI, nombre, apellido, edademp) hemos declarado que

dominio (DNI) es el dominio predefinido de los enteros, entonces no podremos insertar,
por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero.
Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el usuario.
Observemos que los dominios definidos por el usuario resultan muy útiles, porque nos
5
permiten determinar de forma más específica cuáles serán los valores admitidos por los
atributos.
Ejemplo
• Supongamos ahora que en la relación EMPLEADOS(DNI, nombre, apellido, edademp)

hemos declarado que dominio(edademp) es el dominio definido por el usuario edad.
Supongamos también que el dominio edad se ha definido como el conjunto de los
enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un
empleado con un valor de 90 para edademp.
La segunda condición de la regla de integridad de dominio es más compleja, especialmente

en el caso de dominios definidos por el usuario; los SGBD actuales no la soportan para estos
últimos dominios. Por estos motivos sólo la presentaremos superficialmente.
Esta segunda condición sirve para establecer que los operadores que pueden aplicarse sobre
los valores dependen de los dominios de estos valores; es decir, un operador determinado sólo
se puede aplicar sobre valores que tengan dominios que le sean adecuados.
Ejemplo
• Analizaremos esta segunda condición de la regla de integridad de dominio con un

ejemplo concreto. Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) se
ha declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no
se permitirá consultar todos aquellos empleados cuyo DNI sea igual a ‘Elena’ (DNI =
‘Elena’). El motivo es que no tiene sentido que el operador de comparación = se aplique
entre un DNI que tiene por dominio los enteros, y el valor ‘Elena’, que es una serie de
caracteres.
De este modo, el hecho de que los operadores que se pueden aplicar sobre los valores
dependan del dominio de estos valores permite detectar errores que se podrían cometer
cuando se consulta o se actualiza la base de datos. Los dominios definidos por el usuario son
muy útiles, porque nos permitirán determinar de forma más específica cuáles serán los
operadores que se podrán aplicar sobre los valores.
Ejemplo
• Veamos otro ejemplo con dominios definidos por el usuario. Supongamos que en la
conocida relación EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que
6
dominio(DNI) es el dominio definido por el usuario númerosDNI y que
dominio(edademp) es el dominio definido por el usuario edad. Supongamos que
númerosDNI corresponde a los enteros positivos y que edad corresponde a los enteros
que están entre 16 y 65. En este caso, será incorrecto, por ejemplo, consultar los
empleados que tienen el valor de DNI igual al valor de edademp. El motivo es que,
aunque tanto los valores de DNI como los de edademp sean enteros, sus dominios son
diferentes; por ello, según el significado que el usuario les da, no tiene sentido
compararlos.
Sin embargo, los actuales SGBD relacionales no dan apoyo a la segunda condición de la regla
de integridad de dominio para dominios definidos por el usuario. Si se quisiera hacer, sería
necesario que el diseñador tuviese alguna forma de especificar, para cada operador que se
desease utilizar, para qué combinaciones de dominios definidos por el usuario tiene sentido
que se aplique. El lenguaje estándar SQL no incluye actualmente esta posibilidad.
7
Referencias bibliográficas
Elizabeth Pulido Romero, Óscar Escobar Domínguez y José Ángel Núñez Pérez. Base de
datos. Ciudad de México: Grupo Editorial Patria, 2019. eLibro.
Marqués, Mercedes. 2024. Bases de datos. Castelló de la Plana: D - Universitat Jaume I.

Servei de Comunicació i Publicacions, 2009. eLibro
Alcalde (2 de octubre de 2017). Diseño de Bases de Datos ( II ) - Restricciones. El baúl del

programador. Recuperado el 20 de febrero de 2024 de
https://elbauldelprogramador.com/diseno-de-bases-de-datos-ii/

Temas Semana 7 Unidad 3

Cargado por

Copyright:

Formatos disponibles

Temas Semana 7 Unidad 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Temas Semana 7 Unidad 3

Cargado por

Copyright:

Formatos disponibles

Contenido de la Unidad 3

Restricciones Inherentes del Modelo Relacional.

• No existen tuplas repetidas (obligatoriedad de clave primaria). La relación se ha

• El orden de las tuplas y el de los atributos no es relevante.

Las 12 reglas de Codd

2. Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre

3. Tratamiento sistemático de los valores nulos. El DBMS debe permitir el tratamiento

4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser

5. Sublenguaje de datos completo. Al menos debe de existir un lenguaje que permita el

7. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de

10. Independencia de integridad. Las reglas de integridad deben almacenarse en la base

12. No subversión. Si el DBMS posee un lenguaje que permite el recorrido registro a

Restricciones Semánticas o de Usuario.

1. Restricción de Clave Primaria (PRIMARY KEY), permite declarar un atributo o conjunto

2. Restricción de Unicidad (UNIQUE), permite que una clave alternativa o secundaria

3. Restricción de Obligatoriedad (NOT NULL), permite declarar si uno o varios atributos

4. Restricción de Integridad Referencial o de Clave Foránea (FOREIGN KEY), se utiliza para

• Restringir: La operación de eliminación se restringe sólo al caso en el que no existe

• Propagar en cascada: La operación de borrado se propaga en cascada eliminando

5. Restricción de Verificación o Chequeo (CHECK), en algunos casos puede ocurrir que

6. Aserciones (ASSERTION): Esta restricción generaliza a la anterior, lo forman las

3.5. Integridad de dominio

La primera condición consiste en que un valor no nulo de un atributo 𝐴𝑖 debe pertenecer al

• Si en la relación EMPLEADOS (DNI, nombre, apellido, edademp) hemos declarado que

• Supongamos ahora que en la relación EMPLEADOS(DNI, nombre, apellido, edademp)

La segunda condición de la regla de integridad de dominio es más compleja, especialmente

• Analizaremos esta segunda condición de la regla de integridad de dominio con un

Marqués, Mercedes. 2024. Bases de datos. Castelló de la Plana: D - Universitat Jaume I.

Alcalde (2 de octubre de 2017). Diseño de Bases de Datos ( II ) - Restricciones. El baúl del

También podría gustarte