TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

TEMA 5
El modelo relacional
1. INTRODUCCIÓN
En un documento propuesto por Codd, presenta un modelo de datos basado en la teoría de las relaciones,
en donde los datos se estructuran lógicamente en forma de relaciones (tablas), siendo un objetivo funda-
mental del modelo mantener la independencia de la estructura lógica respecto al modo de almacenamien-
to y a otras características de tipo físico. Dicho modelo de datos perseguía una serie de objetivos, muchos
de ellos comunes a otros modelos, los cuales se pueden resumir en los siguientes:
 Independencia física. El modo en que se almacenan los datos no debe influir en su manipula-
ción lógica, y por tanto, los usuarios que accedan a esos datos no han de modificar sus pro-
gramas por cambios en el almacenamiento físico.
 Independencia lógica. Añadir, eliminar o modificar cualquier elemento de la base de datos no
debe repercutir en los programas y/o usuarios que están accediendo a subconjuntos parciales
de los mismos.
 Flexibilidad. En el sentido de poder ofrecer a cada usuario los datos de la forma más adecuada
a la correspondiente aplicación.
 Uniformidad. Las estructuras lógicas de los datos presentan un aspecto uniforme (tablas), lo
que facilita la concepción y manipulación de la base de datos por parte de los usuarios.
 Sencillez. Las características anteriores, así como unos lenguajes de usuario más o menos sen-
cillos, producen como resultado que el modelo de datos relacional sea fácil de comprender y
de utilizar por parte del usuario final.

Para conseguir los objetivos citados, Codd introduce el concepto de relación como estructura básica
del modelo. Todos los datos de una base de datos se representan en forma de relaciones, cuyo contenido
varía en el tiempo. Una relación en terminología relacional es un conjunto de filas con unas determinadas
características (tuplas).
Con respecto a la parte dinámica del modelo, se propone un conjunto de operadores que se aplican a
las relaciones. Algunos de estos operadores son clásicos de la teoría de conjuntos (una relación se define
matemáticamente como un conjunto), mientras que otros fueron introducidos específicamente para el
modelo relacional. Todos ellos conforman el álgebra relacional.

2. ESTRUCTURA DEL MODELO RELACIONAL

La relación es el elemento básico del modelo relacional, y se puede representar como una tabla.

NOMBRE
Atributo 1 Atributo 2 … Atributo n
XXX XXX … XXX tupla 1
XXX XXX … XXX tupla 2
… … … …
XXX XXX … XXX tupla m

El conjunto de columnas, denominadas atributos, representan propiedades de la tabla, las cuales

están caracterizadas por su nombre. Al conjunto de filas, llamadas tuplas, contendrán los valores que toma
cada uno de los atributos para cada elemento de la relación.

35
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

DOMINIO
NOMBRES NACIONALIDADES INSTITUCIONES
XXXXXXXXXXXXX Española U.P.M.
… Francesa Politécnico de Milán
Italiana Relational Institute
…

AUTOR
NOMBRE NACIONALIDAD INSTITUCIÓN Atributos
Date, C. J. Norteamericana Relational Institute
Codd, E. F. Norteamericana Relational Institute TUPLAS Cardinalidad 4
Ceri, S. Italiana Politécnico de Milán
Saltor, F. Española U.P.M.

Grado 3

El grado es el número de atributos. La Cardinalidad es el número de tuplas. Una relación, aunque se

representa en forma de tabla, tiene una serie de elementos característicos que la distinguen de la tabla,
como por ejemplo, no se admiten filas duplicadas, las filas y las columnas no están ordenadas, y es plana,
es decir, que en el cruce de una fila y una columna sólo puede haber un valor. Se trata de restricciones in-
herentes al modelo.

Esquema comparativo de la terminología de relación, tabla y ficheros

RELACIÓN TABLA FICHERO
Tupla Fila Registro
Atributo Columna Campo
Grado Nº de columnas Nº de campos
Cardinalidad Nº de filas Nº de registros

2.1.Dominio y Atributo
Un dominio es un conjunto finito de valores homogéneos y atómicos (V1, V2,… Vn) caracterizado por un
nombre. Se dice que son valores homogéneos porque son todos del mismo tipo, y atómicos porque son
indivisibles en lo que al modelo se refiere, es decir, si se descompusiesen, perderían la semántica a ellos
asociada.
Todo dominio ha de tener un nombre, por el cual nos podemos referir a él, y un tipo de datos. Los
dominios pueden definirse por intensión o por extensión, por ejemplo, el dominio de las edades de las per-
sonas activas de puede definir por intensión como un número entero de longitud 2 comprendido entre 18 y
65, mientras que la definición del dominio de nacionalidades por intensión sería muy pobre semánticamen-
te, ya que permitiría toda combinación de 10 letras aún cuando no constituyesen un nombre válido de na-
cionalidad. Por ello, sería preferible definir este dominio por extensión, con los nombres de las distintas
nacionalidades que admitiera la base de datos.
El dominio contiene todos los posibles valores que puede tomar un atributo, y es estático, es decir,
estos valores no varían en el transcurso del tiempo, ya que si variasen se consideraría un dominio distinto.
El universo del discurso de una base de datos relacional, representado por “U”, está compuesto por
un conjunto finito y no vacío de atributos a1, a2,… an, estructurados en relación. Cada atributo toma sus
valores de un único dominio, y varios atributos pueden tener el mismo dominio. Es muy usual dar el mismo
nombre al atributo y al dominio. En el caso de que sean varios los atributos de una misma tabla, definidos
sobre el mismo dominio, habrá que darles nombres diferentes, ya que una tabla no puede tener dos atribu-
tos con el mismo nombre.
Un dominio compuesto se puede definir como una combinación de dominios simples, a la que se
pueden aplicar ciertas restricciones de integridad, por ejemplo, un usuario puede necesitar manejar, ade-
más de los 3 dominios “día”, “mes” y “año”, un dominio compuesto por dichos 3 dominios, denominado
36
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

“fecha”, al que se le podrían aplicar las adecuadas restricciones de integridad con el fin de que no aparecie-
ran valores no válidos para la fecha.
Al igual que es posible definir dominios compuestos, existen también atributos compuestos. De esta
forma, el atributo “fecha” tomaría sus valores del dominio compuesto de igual nombre.
Tanto los atributos compuestos como los dominios compuestos pueden ser tratados, si así lo precisa
el usuario, como piezas únicas de información, es decir, como valores atómicos.

2.2.Definición formal de relación

Para dar una definición de relación lo más adecuada desde el punto de vista de las bases de datos, es preci-
so tener en cuenta los siguientes elementos:
 Nombre. Las relaciones se identifican por un nombre, si bien ciertas relaciones (por ejemplo,
resultados intermedios) pueden no tener nombre.
 Cabecera de relación. Conjuntos de n pares atributo-dominio. Se corresponde con la primera
fila cuando la relación se percibe como una tabla.
 Cuerpo de la relación. Conjunto de m tuplas, donde cada tupla es un conjunto de n pares atri-
buto-valor. Así como la cabecera de la relación es invariante, su cuerpo varía en el transcurso
del tiempo.
 Esquema de relación. Está constituido por el nombre y la cabecera. El esquema de relación re-
presenta la parte definitoria y estática.
 Estado de relación. Al que se denomina simplemente “relación”, está constituido por el es-
quema y el cuerpo de relación.

2.3.Clases de relación
En una primera división, se diferencias relaciones nominadas y sin nombre:
 Relaciones nominadas. A su vez suelen ser persistentes o temporales.
o Persistentes. Son aquellas cuya definición (esquema de relación) permanece en la base
de datos, borrándose solamente mediante una acción explícita del usuario. Pueden ser
de 3 tipos:
 Relaciones base. Existen por sí mismas, no en función de otras relaciones, y se
crean especificando explícitamente su esquema de relación. Sus ocurrencias de
relación, al igual que su definición, también se encuentran almacenadas.
 Vistas. Son relaciones derivadas que se definen dando un nombre a una expresión
de consulta. Se podría decir que son relaciones virtuales en el sentido de que no
tienen datos almacenados, sino que lo único que se almacena es su definición en
términos de otras relaciones con nombre.
 Instantáneas. Son relaciones derivadas, al igual que las anteriores, es decir, se de-
finen en términos de otras relaciones nominadas, pero tienen datos propios alma-
cenados, los cuales son el resultado de ejecutar la consulta especificada. También
se las conoce como Vistas Materializadas. Las instantáneas no se actualizan cuan-
do cambian los datos de las relaciones sobre las que están definidas, pero “se re-
frescan” cada cierto tiempo de acuerdo con lo indicado por el usuario en el mo-
mento de su creación.
o Temporales. Una relación temporal desaparece de la base de datos sin necesidad de una
acción de borrado específica del usuario. Por ejemplo, al finalizar una sesión o una
transacción.
 Relaciones sin nombre. Son los resultados de consultas que no se materializan, sino que se en-
tregan al usuario que ha realizado la consulta. Pueden ser tanto resultados intermedios como
finales. En consecuencia, las relaciones no nominadas son siempre temporales.

37
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

2.4.Claves
Una clave candidata de una relación es un conjunto de atributos que identifican unívoca y mínimamente
cada tupla de la relación. Por la propia definición de relación, siempre hay al menos una clave candidata, ya
que al ser una relación un conjunto, no existen dos tuplas iguales, y por tanto, el conjunto de todos los atri-
butos siempre tiene que identificar unívocamente a cada tupla. Si no se cumpliera la condición de minima-
lidad, se eliminarían aquellos atributos que lo impidiesen.
Una relación puede tener más de una clave candidata, entre las cuales se debe distinguir:
 Clave primaria. Es aquella clave candidata que el usuario escogerá por consideraciones ajenas
al modelo relacional para identificar la tupla de la relación. Cuando sólo existe una clave can-
didata, ésta será la clave primaria.
 Claves alternativas. Son aquellas claves candidatas que no han sido escogidas como clave pri-
maria.
 Clave ajena. Se denomina clave ajena de una relación R2 a un conjunto no vacío de atributos
cuyos valores han de coincidir con los valores de la clave primaria de una relación.

EMPLEADO
DNI NU_SS COD_EMPL NOMBRE APELLIDOS DIRECCIÓN TELÉFONO
Clave Clave Clave
Candidata Candidata Candidata

Clave
Primaria

Grafo relacional:
AUTOR (DNI, Nacionalidad, Institución…)
LIBRO (Código, Título, Idioma, Editorial…) CLAVES AJENAS
ESCRIBE (DNI, Código…)

3. RESTRICCIONES
En el modelo relacional, al igual que en otros modelos, existen restricciones, es decir, estructuras u ocu-
rrencias no permitidas, pudiéndose diferenciar entre restricciones inherentes y restricciones semánticas.
Los datos almacenados en la base han de adaptarse a las estructuras impuestas por el modelo, y han
de cumplir las restricciones de usuario a fin de consistir una ocurrencia válida del esquema.

3.1.Restricciones Inherentes
Los modelos de datos tienen restricciones que impone el mismo modelo, el cual no admite ciertas estructu-
ras. Son las restricciones inherentes que no son definidas por los usuarios, sino obligadas por el propio mo-
delo.
De la definición matemática de relación, se deduce una serie de características propias de una rela-
ción que se han de cumplir obligatoriamente por lo que se trata de restricciones inherentes, y son las si-
guientes:
 No hay dos tuplas iguales, de donde se deduce la obligatoriedad de la clave primaria.
 El orden de las tuplas no es significativo.
 El orden de los atributos no es significativo.
 Cada atributo sólo puede tomar un único valor del dominio sobre el que está definido, no ad-
mitiéndose, por tanto, los grupos repetitivos. Se dice que una tabla que cumple esta condición
está normalizada o, también, que está en primera forma normal.

Toda relación ha de estar normalizada; en caso contrario, no es realmente una relación.

38
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

AUTOR
NOMBRE NACIONALIDAD INSTITUCIÓN IDIOMAS
Date, C. J. Norteamericana Relational Institute Inglés, Español
Codd, E. J. Norteamericana Relational Institute Inglés
Ceri, F. Italiana Politécnico de Milán Italiano, Inglés

No consistiría exactamente una relación al no restar normalizada, ya que el atributo “idiomas” toma
más de un valor del correspondiente dominio.

Date, C. J. Norteamericana Relational Institute Español

Ceri. F Italiana Politécnico de Milán Inglés

Existe otra restricción inherente, que es la Regla de Integridad de Entidad, la cual impone que ningún
atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo.

3.2.Restricciones semánticas
Son facilidades que el modelo ofrece a los usuarios a fin de que éstos puedan reflejar en el esquema lo más
fielmente posible la semántica del mundo real. Pero estas restricciones semánticas del modelo relacional,
al igual que ocurre con cualquier otro modelo, no son muchas veces suficientes para captar toda la semán-
tica del universo del discurso que se está tratando de modelar. Por ello, algunos productos añaden ciertas
facilidades que permiten programarlas.
 Clave primaria. Permite declarar un atributo o un conjunto de atributos como clave primaria
de una relación, por lo que sus valores no se podrán repetir ni se admitirán los nulos. La obliga-
toriedad de la clave primaria es una restricción inherente del modelo relacional; sin embargo,
la declaración de un atributo como clave primaria de una relación es una restricción semántica,
que responde a la necesidad del usuario de imponer que los valores del conjunto de atributos
que constituyen la clave primaria no se repitan en la relación, ni tampoco tomen valores nulos.
 Unicidad. Mediante la cual se indica que los valores de un conjunto de atributos no pueden
repetirse en una relación. Esta restricción permite la definición de claves alternativas.
 Obligatoriedad. De uno o más atributos, con lo que se indica que el conjunto de atributos no
admite valores nulos.
 Integridad referencial. Si una relación R2 (relación que referencia) tiene un descriptor que es
una clave primaria de la relación R1 (relación referenciada), todo valor de dicho descriptor de-
be concordar con un valor de la clave primaria referenciada de R1, o bien ser nulo. El descrip-
tor es, por tanto, una clave ajena de la relación R2.

EDITORIAL NOMBRE_ED … LIBRO ISBN … NOMBRE_ED

Rama … 1234 … Rama
Amaya … 2345 … Rama
McGraw Hill … 3456 … McGraw Hill
4567 … Nulo

La integridad referencial es una importante restricción semántica que viene impuesta por el mundo
real, siendo el usuario quien la define al describir el esquema relacional. El modelo la reconoce sin necesi-
dad de que se programe ni de que se tenga que escribir ningún procedimiento para obligar su cumplimien-
to.
Además de definir las claves ajenas, hay que determinar las consecuencias que pueden tener ciertas
operaciones, como borrado y modificación, realizadas sobre tuplas de la relación referenciada, pudiéndose
distinguir las siguientes opciones:

39
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

 Operación restringida. El borrado de tuplas de la relación que contiene la clave referenciada (o

la modificación de dicha clave) sólo se permite si no existen tuplas con este valor en la relación
que contiene la clave ajena, es decir, para borrar una editorial de la base de datos, no debería
haber ningún libro que estuviese publicado por dicha editorial; en caso contrario, el sistema
impediría el borrado. Es la opción válida por defecto, es decir, si no se indica ninguna opción, el
sistema tomará ésta.
 Operación con transmisión en cascada. Lleva consigo el borrado (o modificación) en cascada
de la relación que contiene la clave ajena. Por ejemplo, si se modificase el nombre de una edi-
torial en la relación “Editorial”, se modificaría automáticamente dicho nombre en todos los li-
bros de la base de datos publicados por dicha editorial.
 Operación con puesta a nulos. Lleva consigo poner a nulos los valores de las claves ajenas de
la relación que referencia. Por ejemplo, si se borra una editorial, a los libros que ha publicado
dicha editorial, y que estuviesen en “Libros”, se les pondría automáticamente a nulo el atributo
Nombre_Ed, siempre y cuando el atributo que es clave ajena admita nulos.
 Operación con puesta a valor por defecto. El borrado de tuplas de la relación que contiene la
clave referenciada lleva consigo poner por defecto a la clave ajena de la relación que referen-
cia valor por defecto, que habría sido definido al crear la tabla correspondiente.

La opción seleccionada, en caso de borrado, es independiente de la de modificación, es decir, las

opciones de borrado y de modificación pueden ser distintas.
Cuando las restricciones de integridad referencial afectan a varias tablas, hay que tener en cuenta
que la combinación de opciones que se definan puede provocar graves problemas de integridad.
Existen otras restricciones en el modelo relacional llamadas “de rechazo”, en las que el usuario for-
mula una condición mediante un predicado definido sobre un conjunto de atributos, el cual debe ser verifi-
cado por los correspondientes objetos en toda operación de actualización para que el nuevo estado consti-
tuya una ocurrencia válida del esquema. En caso de que la operación intente violar la condición, se impide
que la operación se lleve a cabo, es decir, se produce un rechazo de la operación.
En el modelo relacional se distinguen dos restricciones de rechazo según la condición afecte a un
único elemento de la base de datos o más de uno: verificación y aserción.
 Verificación. Se define sobre un único elemento.
 Aserción. Puede afectar a varios elementos.

Existen otras restricciones en las que el usuario puede especificar la respuesta a una determinada
condición. Se les llama “disparadores”. Son procedimentales, es decir, el usuario escribirá el procedimiento
que ha de aplicarse en caso de que se cumpla la condición.

4. MODELO RELACIONAL Y ARQUITECTURA ANSI

En el nivel conceptual de la arquitectura ANSI se encuentran, además de las restricciones, las relaciones
base, ya que tienen una representación directa en el almacenamiento interno.
En el nivel externo de la arquitectura ANSI están las vistas, tablas virtuales de las que sólo se almace-
na su definición y no tienen, por tanto, representación directa en el almacenamiento.
Por lo que respecta al esquema interno, el modelo relacional no especifica absolutamente nada al
tratarse de un modelo lógico.

5. VALORES NULOS EN EL MODELO RELACIONAL

Un valor nulo se define como una señal utilizada para representar información desconocida, inaplicable,
inexistente, no válida, no proporcionada, indefinida, etc.
La necesidad de los valores nulos, o marcas, en las bases de datos se justifica por lo siguiente:
 Crear tuplas con ciertos atributos desconocidos en ese momento.
 Añadir un nuevo atributo a una relación existente, que en el momento de añadirse no tendría
ningún valor para las tuplas de la relación.
40
TEMA 5: EL MODELO RELACIONAL Gestión de Bases de Datos

 Atributos inaplicables a ciertas tuplas.

6. 12 REGLAS DE CODD PARA LOS

SISTEMAS RELACIONALES
1. Representación de la información. Toda información en una base de datos relacional debe re-
presentarse explícitamente a nivel lógico y de manera única por medio de valores en las tablas.
Es el principio básico del modelo relacional.
2. Acceso garantizado. Todo dato debe ser accesible mediante una combinación de un nombre
de tabla, un valor de su clave y el nombre de una columna. Es una forma de insistir en la obli-
gatoriedad de la clave primaria.
3. Tratamiento sistemático de valores nulos. Los valores nulos han de ser tratados sistemática-
mente por el sistema, el cual ha de ofrecer las facilidades necesarias para su tratamiento.
4. Catálogo activo en línea basado en el modelo relacional. La representación de la descripción
de la base de datos debe ser igual a la de los otros datos, y su acceso debe poder realizarse por
medio del mismo lenguaje relacional que se utiliza para los demás datos.
5. Sublenguaje de datos completo. Debe existir un lenguaje que permita un completo manejo de
la base de datos.
6. Actualización de vistas. Toda vista teóricamente actualizable deberá poder ser actualizada en
la práctica por el sistema.
7. Inserciones, modificaciones y eliminaciones de alto nivel. Todas las operaciones de manipula-
ción de datos deben operar sobre conjuntos de filas.
8. Independencia física de los datos. El acceso lógico a los datos debe mantenerse incluso cuan-
do cambien los métodos de acceso o la forma de almacenamiento.
9. Independencia lógica de los datos. Los programas de aplicación no deben verse afectados por
cambios realizados en las tablas que estén permitidos teóricamente, y que preservan la infor-
mación.
10. Independencia de la integridad. Las reglas de integridad de una base de datos deben ser defi-
nibles por medio del sublenguaje de datos relacional, y habrán de almacenarse en el catálogo
de la base de datos.
11. Independencia de la distribución. Debe existir un sublenguaje de datos que pueda soportar
bases de datos distribuidas.
12. Regla de la no subversión. Si un SGBD soporta un lenguaje de bajo nivel que permite el acceso
fila a fila, éste no puede utilizarse para saltarse las reglas de integridad expresadas por medio
del lenguaje de más alto nivel.

41