3.

Modelo relacional
3.1 Introducción
En el capítulo anterior se mencionaron 3 tipos de modelado: conceptual,
lógico y físico.

El modelo e-r se considera un modelo conceptual ya que permite a un

nivel alto el ver con claridad la información utilizada en algun problema o
negocio.

En este capítulo nos concentraremos en desarrollar un buen modelo

"lógico" que se conoce como "esquema de la base de datos" ( database
schema) a partir del cual se podrá realizar el modelado físico en el DBMS,
es importante mencionar que es un paso necesario, no se puede partir de
un modelo conceptual para realizar un físico.

3.2 Por qué "modelo relacional" ?

Puede resultar confuso el concepto de modelo entidad-relación vs modelo
relacional, quizás porque ambos comparten casi las mismas palabras.
Como se mencionó en la sección anterior, el objetivo del modelo
relacional es crear un "esquema" (schema), lo cual como se mencionará
posteriormente consiste de un conjunto de "tablas" que representan
"relaciones", relaciones entre los datos.

Estas tablas, pueden ser construídas de diversas maneras:

 Creando un conjunto de tablas iniciales y aplicar operaciones de

normalización hasta conseguir el esquema más óptimo. Las técnicas
de nomalización se explican más adelante en este capítulo.
 Convertir el diagrama e-r a tablas y posteriormente aplicar también
operaciones de normalización hasta conseguir el esquema óptimo.
La primer técnica fue de las primeras en existir y, como es de suponerse,
la segunda al ser más reciente es mucho más conveniente en varios
aspectos:

 El partir de un diagrama visual es muy útil para apreciar los

detalles, de ahí que se llame modelo conceptual.
 El crear las tablas iniciales es mucho más simple a través de las
reglas de conversión.
 Se podría pensar que es lo mismo porque finalmente hay que
"normalizar" las tablas de todas formas, pero la ventaja de partir
del modelo e-r es que la "normalización" es mínima por lo general.
 Lo anterior tiene otra ventaja, aún cuando se normalice de manera
deficiente, se garantiza un esquema aceptable, en la primer técnica
no es así.

3.3 Conceptos básicos

3.3.1 Tablas

El modelo relacional proporciona un manera simple de representar los

datos: una tabla bidimensional llamada relación.

título año duración tipo

Star Wars 1977 124 color
Mighty
1991 104 color
Ducks
Wayne's
1992 95 color
World

Relación Películas

La relación Películas tiene la intención de manejar la información de las

instancias en la entidad Películas, cada renglón corresponde a una
entidad película y cada columna corresponde a uno de los atributos de la
entidad. Sin embargo las relaciones pueden representar más que
entidades, como se explicará más adelante.

3.3.2 Atributos
Los atributos son las columnas de un relación y describen características
particulares de ella.

3.3.3 Esquemas

Es el nombre que se le da a una relación y el conjunto de atributos en

ella.

Películas (título, año, duración, tipo)

En un modelo relación, un diseño consiste de uno o más esquemas, a

este conjunto se le conoce como "esquema relacional de base de datos"
(relational database schema) o simplemente "esquema de base de datos"
(database schema)

3.3.4 Tuplas

Cada uno de los renglones en una relación conteniendo valores para cada
uno de los atributos.

(Star Wars, 1977, 124, color)

3.3.5 Dominios

Se debe considerar que cada atributo (columna) debe ser atómico, es

decir, que no sea divisible, no se puede pensar en un atributo como un
"registro" o "estructura" de datos.

3.3.6 Representaciones equivalentes de una relación

Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden

en que aparecen las tuplas es irrelevante.

Así mismo el orden de los atributos tampoco es relevante

año título tipo duración

Mighty
1991 color 104
Ducks
Wayne's
1992 color 95
World
1977 Star Wars color 124
 Otra representación de la relación Películas

3.4 Conversión del modelo e-r a un esquema de

base de datos (Conversión a tablas)
3.4.1 Introducción

El modelo es una representación visual que gráficamente nos da una

perspectiva de como se encuentran los datos involucrados en un proyecto
u organización.

Pero el modelo no nos presenta propiamente una instancia de los datos,

un ejemplo que muestre con claridad algunas datos de muestra y como
se relacionan en realidad. Por eso es conveniente crear un "esquema", el
cual consiste de tablas las cuales en sus renglones (tuplas) contienen
instancias de los datos.

3.4.2 Conversión a tablas desde un modelo con relaciones (1-

1,1-m,m-m)

Las tablas siguientes muestran las reglas que se deben seguir para poder
crear dicho esquema.

modelo e-r conversión a tablas

 una tabla por cada conjunto de entidades

o nombre de tabla = nombre de conjunto de entidades
 una tabla por cada conjunto de relaciones m-m
o nombre de tabla = nombre de conjunto de relaciones
 definición de columnas para cada tabla
o conjuntos fuertes de entidades
 columnas = nombre de atributos
o conjuntos débiles de entidades
 columnas = llave_primaria (dominante) U
atributos(subordinado)
o conjunto de relaciones R (m-m) entre A, B
 columnas (R) = llave_primaria (A) U
 llave_primaria (B) U atributos(R)
o conjunto de relaciones R (1-1) entre A y B
 columnas (A) = atribs(A) U llave primaria(B) U
atributos(R)
o conjunto de relaciones R (1-m) entre A y B
 columnas (B) = atribs(B) U llave primaria(A) U
atributos(R)

El diagrama anterior se convertiría al siguiente esquema:

Debil

atribs_Debi LLP_ atribs_rel_

 l A 0
A

LLP_A atribs_A
B1

LLP_B1 atribs_B1
B2

LLP_B atribs_ LLP_ attribs_rel

2 B2 A _2
B3

LLP_B atribs_B LLP_ atribs_rel_

3 3 A 3
A_B1

LLP_A LLP_B1 atribs_rel_1

donde:

LLP_X es la llave primaria de la entidad X (un subconjunto de

atribs_X)

Ejemplo:
Para el ejemplo de la figura tendríamos el esquema:

escuela

id url nombre
departamento

clave url nombre id_escuela

curso

clave seccion nombre clave_depto

profesor

id nombre extension
estudiante

id nombre carrera
profesor_curso

id_prof clave_curso seccion_curso

estudiante_curso

id_estud clave_curso seccion_curso

3.4.3 Conversión a tablas desde un modelo con generalización

modelo e-r
de generalización a tablas
dos posibilidades:

1.
o crear una tabla para el conjunto de entidades A de
mayor nivel
 columnas (A) = atributos(A)

o para cada conjunto de entidades B de menor nivel, crear

una tabla tal que:
  columns (B) = atributos (B) U llave_primaria (A)

2.

o si A es un conjunto de entidades de mayor nivel para

cada conjunto de entidades B de menor nivel, crear una
tabla tal que:
columnas (B) = atributos (B) U atributos (A)

La generalización se convertiría al siguiente esquema:

1)

LLP_A atribs_A
 B1

atribs_B1 LLP_A
B2

atribs_B2 LLP_A
B3

atribs_B3 LLP_A
donde:

LLP_X es la llave primaria de la entidad X (un subconjunto de

atribs_X)

2)

B1

atribs_B1 LLP_A atribs_A

B2

atribs_B2 LLP_A atribs_A

B3

atribs_B3 LLP_A atribs_A

donde:

LLP_X es la llave primaria de la entidad X (un subconjunto de

atribs_X)

Es importante mencionar que a pesar de que existen 2 métodos para

convertir una generalización a tablas, no hay una regla exacta de cual
usar en determinado caso. A continuación se mencionan algunos
consejos útiles para la determinación de cual método emplear:

1. Si la entidad de nivel superior está relacionada con otra(s)

entidades puede sugerirse emplear el método (1) ya que de esa
manera la tabla (A) será la única involucrada en la relación, de otra
 forma se tendrían tres tablas (B1,B2 y B3) formando parte de la
relación
2. Es importante tomar en cuenta la pertenencia de instancias, si se
considera que hablamos de una generalización disjunta, donde no
se puede pertenecer a varias entidades de nivel inferior, quizás sea
recomendable el método (1), en otro caso se podría pensar en el
método (2).
3. También es importante analizar ambos casos con respecto a las
"consultas" que se deseen realizar ya que esto también determina
en muchos casos el método a emplear.

3.4.4 Descubrimiento de llaves en las relaciones

Las llaves resultantes en las relaciones de un esquema se pueden inferir

de la siguiente manera:

1) Cada tabla que provenga de una entidad contiene por si misma una
llave

2) Para las tablas resultado de una relación se toman las llaves primarias
de ambas entidades y éstas conforman la nueva llave primaria, excepto
en un caso como el que sigue:
Podemos observar que existe una relación m-m entre "actor" y
"serie", demostrando que un actor puede actuar en muchas
series y que muchas series tendrán a los mismos actores.

La tabla que se crearía sería:

actor_serie

id_actor id_serie id_personaje

Abel hermano
Joaquín Pardavé Génesis
bueno
Evita Muñoz Qué bonita
Dulce abuelita
(Chachita) familia
Caín hermano
Joaquín Pardavé Génesis
malo
Evita Muñoz Hermelinda Bruja
(Chachita) linda Hermelinda
si se considera "id_actor, id_serie" como la llave primaria
caemos en un problema porque esa combinación no identifica de
 manera única a la tupla, como es el caso de "Joaquín Pardavé,
Génesis" ya que en la primer tupla tenemos que determina a
"Abel hermano bueno" y en la tercera a "Caín hermano malo".

La relación es correcta ya que un actor puede representar a

varios personajes en la misma obra, pero entonces la llave
"id_actor, id_serie" no es la correcta y en este caso lo más
recomendable sería emplear los tres atributos de la relación
"id_actor, id_serie, id_personaje"

RESTRICCIONES DE LAS BASES DE DATOS

Las restricciones de los datos se imponen para asegurarnos que los datos cumplen con una serie de
condiciones predefinidas para cada tabla. Estas restricciones ayudan a conseguir la integridad de
referencia: todas las referencias dentro de una BD son válidas y todas las restricciones se han
cumplido.

Las restricciones se van a definir acompañadas por un nombre, lo que permitirá activarlas o
desactivarlas según sea el caso; o también mezcladas en la definiciones de las columnas de la tabla.
A continuación vamos a describir cada una de las restricciones mencionadas.

NOT NULL

Establece la obligatoriedad de que esta columna tenga un valor no nulo. Se debe especificar junto a
la columna a la que afecta. Los valores nulos no ocupan espacio, y son distintos a 0 y al espacio en
blanco. Hay que tener cuidado con los valores nulos en las operaciones, ya que 1 * NULL es igual
a NULL.

UNIQUE

Evita valores repetidos en una columna, admitiendo valores nulos. Oracle crea un índice
automáticamente cuando se habilita esta restricción y lo borra al deshabilitarse.

DEFAULT

Establece un valor por defecto para esa columna, si no se le asigna ninguno.

CHECK
 Comprueba que se cumpla una condición determinada al rellenar esa columna. Esta condición sólo
debe estar construida con columnas de esta misma tabla.

PRIMARY KEY

Establece el conjunto de columnas que forman la clave primaria de esa tabla. Se comporta como
única y obligatoria sin necesidad de explicitarlo. Sólo puede existir una clave primaria por tabla.
Puede ser referenciada como clave ajena por otras tablas. Crea un índice automáticamente cuando
se habilita o se crea esta restricción. En Oracle, los índices son construidos sobre árboles B +.

FOREIGN KEY

Establece que el contenido de esta columna será uno de los valores contenidos en una columna de
otra tabla maestra. Esta columna marcada como clave ajena puede ser NULL. No hay límite en el
número de claves ajenas. La clave ajena puede ser otra columna de la misma tabla. Se puede forzar
que cuando una fila de la tabla maestra sea borrada, todas las filas de la tabla detalle cuya clave
ajena coincida con la clave borrada se borren también. Esto se consigue añadiendo la coletilla ON
DELETE CASCADE en la definición de la clave ajena.

1. 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 relaciónales. Las reglas son:

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

2. 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 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 actua con las mismas
tres posibilidades que en el caso anterior:
 Restringir
 Propagar en cascada.
 Anular
5. 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.
6. 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 determinados atributos de una relación de la BD, aparte de las restricciones
vistas anteriormente.
7. 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).
8. 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.
Restricciones de
integridad
Ago 05, 2023

En el contexto de las bases de datos, las "restricciones de integridad" se

refieren a reglas específicas que se implementan para garantizar la
precisión y coherencia de los datos dentro de una base de datos
relacional . Estas reglas gobiernan los datos a medida que se insertan,
actualizan y eliminan, evitando así la corrupción de datos no deseada y
aplicando la estructura lógica deseada. La definición de restricciones de
integridad se puede detallar más en varios aspectos:
Integridad del dominio: Esto asegura que todas las entradas en una
columna dada sean consistentes y se encuentren dentro de un dominio
definido. Por ejemplo, si se espera que una columna tenga números
positivos, la restricción de dominio evitará que se inserten números
negativos o valores no numéricos.
Integridad de la entidad: Esto se refiere a la unicidad de las filas dentro
de una tabla, normalmente aplicada mediante el uso de claves primarias.
La clave principal identifica de forma única un registro en una tabla, y la
integridad de la entidad garantiza que no existan claves duplicadas,
manteniendo así la distinción de cada registro.
Integridad referencial: esta restricción garantiza que las relaciones entre
las tablas permanezcan consistentes. Cuando una tabla tiene una clave
externa que es una referencia a la clave principal de otra tabla, la
integridad referencial garantiza que se mantenga esta conexión. Si se
elimina o altera un registro al que hace referencia una clave externa, la
base de datos tomará acciones definidas, como actualizar la clave de
referencia o denegar el cambio.
Integridad definida por el usuario: estas restricciones son específicas de
la lógica comercial o las reglas que pertenecen al caso de uso particular
de la base de datos. Por ejemplo, una restricción definida por el usuario
puede requerir que el salario de un empleado no supere una cierta
cantidad o que la edad de un cliente sea mayor de 18 años. Estas reglas
se pueden adaptar a los requisitos específicos de una aplicación
determinada.
Verificar restricciones: estas restricciones permiten definir reglas más
específicas para los datos dentro de una columna o conjunto de
columnas. Por ejemplo, una restricción de verificación puede requerir que
un valor de porcentaje esté entre 0 y 100 o que una entrada de fecha de
nacimiento sea anterior a la fecha actual.
Restricciones nulas: esto determina si se puede permitir un valor nulo
para un atributo en particular. Si se aplica una restricción nula a una
columna, garantiza que cada fila de esa columna debe contener un valor.
Integridad temporal: esto garantiza la precisión y coherencia de los datos
de fecha y hora dentro de la base de datos, a menudo asegurando que
los valores de fecha y hora sigan secuencias lógicas y se adhieran a
formatos definidos.
Las restricciones de integridad juegan un papel crucial en el
mantenimiento de la confiabilidad y solidez de un sistema de base de
datos. Por lo general, se definen durante la fase de diseño de la base de
datos y el sistema de administración de la base de datos (DBMS) los
aplica.
Sin las restricciones de integridad adecuadas, una base de datos podría
sufrir inconsistencias, ambigüedades y errores que podrían afectar
significativamente su usabilidad y confiabilidad. Estas restricciones, por lo
tanto, forman una parte esencial de la arquitectura de la base de datos,
asegurando que los datos se adhieran a las reglas y estándares de
calidad esperados.

INTEGRIDAD DE LA BASE DE DATOS

Integridad de entidad
 La integridad de entidad define una fila como entidad única para una tabla
determinada. La integridad de entidad exige la integridad de las columnas de los
identificadores o la clave principal de una tabla, mediante índices y restricciones
UNIQUE, o restricciones PRIMARY KEY.

Ejemplos:

 Tenemos la siguiente relación:

DESPACHOS
Edificio número superficie
Marina 120 10
Marina 122 15
Marina 230 20
Diagonal 120 10
En esta relación, puesto que la clave primaria está formada por edificio y número,
no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para
número.

 Una empresa dedicada a la venta de bebidas, podríamos identificar las bebidas de un modo
general, a un modo más individual: Todas las bebidas en un sólo grupo. Todas las bebidas de la
misma marca en un grupo. Agrupar las bebidas en función de si son alcohólicas o no. Cada
bebida de modo individual. Un hecho sobre una determinada bebida, como puede ser el sabor
de un refresco.

Integridad de dominio
La integridad de dominio viene dada por la validez de las entradas para una
columna determinada. Puede exigir la integridad de dominio para restringir el tipo
mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el
intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones
CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.

Ejemplos:

 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.
 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.

Integridad referencial
La integridad referencial protege las relaciones definidas entre las tablas cuando se
crean o se eliminan filas. En SQL Server la integridad referencial se basa en las
relaciones entre claves externas y claves principales o entre claves externas y claves
exclusivas, mediante restricciones FOREIGN KEY y CHECK. La integridad
referencial garantiza que los valores de clave sean coherentes en las distintas
tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores
inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se
cambien en consecuencia en toda la base de datos.
Cuando se exige la integridad referencial, SQL Server impide a los usuarios:
 Agregar o cambiar filas en una tabla relacionada si no hay ninguna fila
asociada en la tabla principal.
 Cambiar valores en una tabla principal que crea filas huérfanas en una tabla
relacionada.
 Eliminar filas de una tabla principal cuando hay filas relacionadas
coincidentes.
Ejemplos:

 En las tablas Sales.SalesOrderDetail y Production.Product de la base de

datos AdventureWorks2008R2, la integridad referencial se basa en la relación
entre la clave externa (ProductID) de la tabla Sales.SalesOrderDetail y la
clave principal (ProductID) de la tabla Production.Product. Esta relación
garantiza que un pedido de ventas no pueda nunca hacer referencia a un producto
que no existe en la tabla Production.Product.

 Supongamos una base de datos con las entidades Persona y Factura. Toda factura
corresponde a una persona y solamente una. Implica que en todo momento dichos
 datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal
resueltas.
Supongamos que una persona se identifica por su atributo DNI (Documento Nacional
de Identidad). También tendrá otros atributos como el nombre y la dirección. La
entidad Factura debe tener un atributo DNI_cliente que identifique a quién pertenece
la factura.
Por sentido común es evidente que todo valor de DNI_cliente debe corresponder con
algún valor existente del atributo DNI de la entidad Persona. Esta es la idea intuitiva
de la integridad referencial.

Integridad definida por el usuario

La integridad definida por el usuario permite definir reglas de empresa específicas
que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de
integridad admiten la integridad definida por el usuario. Esto incluye todas las
restricciones de nivel de columna y nivel de tabla en CREATE TABLE,
procedimientos almacenados y desencadenadores.

Ejemplos:
 Supongamos que en la conocida relación EMPLEADOS (DNI, nombre, apellido,
edademp) se ha declarado que 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.

3.5 INTEGRIDAD DE DOMINIO

- mayo 20, 2019

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 Ai debe pertenecer al dominio del atributo Ai; es
decir, debe pertenecer a dominio(Ai).

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, ecordad que los conceptos
entonces no podremos insertar, por ejemplo, ningún
de dominio
empleado que tenga por DNI el valor “Luis”, que no es un predefinido y dominio
entero. definido por el usuario se han
explicado
Recordemos que los dominios pueden ser de dos tipos:
en el subapartado 2.2 de esta
predefinidos o definidos por el usuario. Observad que los unidad
dominios definidos por el usuario resultan muy útiles,
didáctica.
porque nos 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
Lectura recomendada
como el conjunto de los enteros que están entre 16 y 65.
Para estudiar con más detalle
En este caso, por ejemplo, no será posible insertar un
la segunda condición
empleado con un valor de 90 para edademp.
de la regla de integridad
La segunda condición de la regla de integridad de dominio de dominio, podéis consultar
es más compleja, especialmente en el caso de dominios la siguiente obra:
definidos por el usuario; los SGBD actuales no la soportan C.J. Date (2001). Introducción
para estos últimos dominios. Por estos motivos sólo la a los sistemas de bases de
datos (7ª ed., cap. 19).
presentaremos superficialmente. Prentice Hall.

Esta segunda condición sirve para establecer que los

operadores que pueden aplicarse sobre los valores dependen de
los dominios de estosvalores; 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
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.