Modelo Relacional I

El modelo de datos relacional es, desde hace tiempo, el más utilizado para modelar
sistemas reales que trabajan con información. Se impuso debido a las limitaciones que
implicaba el uso de modelos anteriores como el Codasyl (modelo en red) o el
jerárquico. Se basa en el uso de relaciones o tablas que agrupan conjuntos de datos en
forma de filas o tuplas. Además, incorpora restricciones que son formas de reflejar las
políticas de la empresa u organización que se está modelando.

Nos encontramos en la FASE 2: REGLAS DE TRANSFORMACIÓN del Modelo Entidad

Relación (MER) al Modelo Relacional (MR).

I. Conceptos del MR

1. Relación (atributos y dominio)

Cada relación es similar a una tabla, en filas y columnas. Cada fila representa una
colección de valores relacionados entre sí. Estos valores pueden ser entendidos como
hechos que representan una entidad o un vínculo entre entidades del mundo real.

El nombre de la tabla y el de las columnas permiten interpretar el significado de los

valores almacenados en cada fila de la tabla. Por ejemplo, un jugador de una base de
datos de una liga de baloncesto quedaría representado del siguiente modo:

jugador (id_jugador entero(4), dni entero(8), nombre character(20), apellido character

(20), equipo character (20), edad entero(3), fecha_alta fecha)

De modo que representamos la tabla o relación jugadores con siete campos o

características de un jugador. Además, se incluye el tipo de datos para cada atributo
especificando el tamaño o dominio de los mismos (en general, se incluirán más
aspectos de los campos como si son obligatorios u opcionales, etc.) Así, el campo

1
id_jugador es un campo que puede tomar valores de tipo numérico de hasta 4 dígitos,
el nombre es una cadena de caracteres de hasta 20 caracteres, etc.

Por lo tanto, todos los valores de una columna tienen el mismo tipo de datos. Es decir,
pertenecen a un dominio, siendo éste un conjunto finito de valores homogéneos y
atómicos, caracterizados por un nombre. Se dice homogéneos, puesto que son todos
del mismo tipo, y atómicos porque son indivisibles dentro del modelo. Todo dominio
tiene un nombre por el cual nos referimos a él y un tipo de datos. Generalmente, un
dominio lleva asociados un tipo de datos y/o un formato.

Recapitulando:

 La tabla es una relación.

 Una fila de la tabla es una tupla.
 Una cabecera de columna es un atributo.
 El grado de una relación es su número de atributos.
 Con dominio nos referimos al tipo de datos que describe los valores que
pueden ser almacenados en cada columna.
 El orden de las tuplas no tiene relevancia.
 El orden de los atributos no tiene importancia.
 El número de ocurrencias (filas) de una relación se llama cardinalidad.

Por ejemplo, en la tabla jugador de la base de datos liga tendremos tantas ocurrencias
como jugadores estén registrados.

Distinguimos entre esquema de relación o intensión que define la estructura de la

tabla, es decir, sus atributos con los dominios subyacentes, y un cuerpo o extensión,
que está formado por un conjunto de ocurrencias o tuplas que varían en el tiempo.

En nuestro ejemplo tendríamos:

Intensión de la relación jugador

jugadores (id_jugador: número de 4 dígitos, dni: número de ocho dígitos, nombre:

cadena de hasta 20 caracteres, apellido: cadena de hasta 20 caracteres, equipo:

2
cadena de hasta 20 caracteres, edad: números entre 18 y 100, fecha_alta: fecha con el
formato año-mes-dia)

Extensión de la relación jugador

id_jugador dni nombre apellido equipo edad

1 71650463 Juan Carlos Navarro Regal Barça 33
2 09435678 Pau Gasol LA Lakers 33
3 08435678 Carlos Cabezas CAI Zaragoza 27

II. Restricciones del modelo relacional

Cuando hacemos un modelo de datos de un SI (Sistema de Información), además de los
datos y sus relaciones reflejamos ciertas condiciones o políticas de negocio que
deseamos que cumplan.

Por ejemplo, en nuestra liga de baloncesto una restricción puede ser que cada equipo
tenga un código asociado o que cada jugador pertenezca necesariamente a un equipo.

Es lo que llamamos restricciones, que son condiciones que se imponen al modelo, ya

sea por las características del mismo o por los requerimientos del diseñador.

Hay dos grupos principales, las inherentes que imponen condiciones derivadas de la
propia definición del modelo (no dependen del diseñador) y de usuario o semánticas
que son impuestas por el diseñador de la BD en función de los requisitos del sistema a
modelar.

1. Restricciones inherentes

Se derivan de la misma estructura del modelo así que no tienen que ser definidas por
el diseñador. Son las siguientes:

a) Restricción de clave
No puede haber dos tuplas iguales. Es decir, no puede haber dos filas u
ocurrencias de una relación con el mismo valor en todos los campos.

3
 El orden de las tuplas no es importante, ni tampoco el orden de los atributos.
b) Restricción de dominio
Cada atributo solo puede tomar un único valor del dominio, no
admitiéndose por tanto los grupos repetitivos (valor atómico). Es decir, no
podemos tener, por ejemplo, dos valores para el campo edad en la tabla
jugador.
C) Es necesario el cumplimiento de la regla de integridad
de entidad
“Ningún atributo que forme parte de la clave primaria de una relación puede
tomar un valor desconocido o inexistente (nulo).”

2. Restricciones de usuario

Son restricciones impuestas por las características del sistema que se está modelando
y, por tanto, dependen del mismo. Se distinguen los siguientes tipos:

a) Superclave
Es un atributo o conjunto de atributos que identifican de modo único las tuplas
de una relación. Por ejemplo, dni, id_jugador, o combinaciones de nombre y
dni, etc.

b) Clave candidata
Es un conjunto mínimo de atributos que identifican unívoca y
mínimamente cada tupla en una relación (por tanto podrían llegar a
ser clave primaria). Una relación puede tener varias claves
candidatas. Para el caso de la relación jugadores, las claves posible s
serían los campos id_jugador y dni. Sin embargo, la unión de dni y
nombre no sería una clave ya que no necesitamos el nombre para
identificar a un jugador, de ahí el uso de “mínimo” en la definición.

c) Clave primaria
De entre las claves candidatas es la que el diseñador escoge para que
identifiquen a cada una de las ocurrencias o tuplas. No puede tomar valores
nulos. En nuestro ejemplo podríamos escoger id_jugador.

4
d) Clave alternativa
Claves candidatas que no han sido escogidas como clave primaria. En nuestro
ejemplo sería el dni.
e) Clave ajena
Conjunto de atributos de una relación cuyos valores han de coincidir con los
valores de la clave primaria de otra relación. La clave ajena y la clave primaria
deben de estar definidas necesariamente sobre los mismos dominios.
f) Regla de integridad referencial
“Si una relación R2 (relación que referencia) tiene un conjunto de atributos que
son clave primaria de la relación R1 (relación referenciada), todos los valores de
dichos atributos deben coincidir con otro grupo de valores de la clave primaria
de R1 o bien ser nulos. Además la clave ajena también puede formar parte de la
clave principal de R2”.
Por ejemplo, si tenemos las relaciones equipos (R1) y jugadores (R2) con la
siguiente estructura:

equipos (nombre_equipo, puntos, ciudad)

jugadores (id_jugador, dni, nombre, apellido, equipo, edad, fecha_alta, equipo)

El campo nombre_ equipo podría ser una clave principal de la tabla equipo ya
que identifica a cada equipo, es decir, no se repite. Así el campo equipo en la
tabla jugador referencia al nombre de un equipo, o sea que es un campo que
en la tabla equipo funciona como clave primaria. Podemos establecer
integridad referencial entre estas dos tablas imponiendo que todos los valores
del campo equipo en jugador deben estar en la tabla equipo o ser nulos. Dicho
de otro modo, no puede haber jugadores que jueguen en equipos inexistentes
en la base de datos.

Hay que tener en cuenta que la base de datos es dinámica y que, por tanto, los
valores se van modificando, eliminando a lo largo del tiempo de modo que si
creamos restricciones de integridad referencial debemos determinar las

5
 acciones que deben tomarse como consecuencia de operaciones de
modificación y borrado realizadas sobre filas de las tablas referenciadas.
Es decir, debemos decir qué ocurre cuando, por ejemplo, eliminamos o
modificamos filas en la tabla equipo.
¿Qué ocurriría entonces con las filas de jugadores pertenecientes al equipo
eliminado o modificado? Para ello se distinguen tres posibilidades:
g) Operación restringida
Sólo se puede borrar una fila de la tabla que tiene la clave primaria
referenciada en caso de que no existan filas con esa clave ajena en la tabla que
referencia.
En nuestro ejemplo, solo podremos borrar o modificar un equipo (en el
caso de modificar me refiero al nombre) si no hay jugadores
relacionados con el mismo.
h) Operación con transmisión en cascada
El borrado o la modificación de una fila de la tabla que contiene la clave
primaria implica el borrado o la modificación en cascada de las filas de la tabla
que referencia, cuya clave ajena coincide con el valor de la clave primaria de la
tabla que es referenciada.En nuestro ejemplo, el borrado o modificación de un
equipo implicaría la eliminación o modificación de los jugadores pertenecientes
al mismo.
i) Operaciones con puesta a nulos
El borrado o la modificación de una fila de la tabla que contiene la clave
primaria implica modificar a valor nulo los valores de la clave ajena de las filas
de la tabla que referencia, cuya clave ajena coincide con el valor de la clave
primaria de la tabla referenciada.En nuestro ejemplo, pondríamos a nulo los
valores coincidentes de equipo en la tabla jugador.

3 Otras restricciones

Existen otro tipo de restricciones que se pueden expresar mediante el uso de SQL o
lenguajes propios del sistema gestor:

6
a) Restricciones de verificación
Son los llamados checks que permiten imponer condiciones a elementos
o atributos de una relación. Por ejemplo, podemos imponer que el
campo edad en la relación jugador esté comprendido entre 18 y 100
años.
b) Restricción de aserción
Son parecidas a las anteriores, la única diferencia es que ahora las
condiciones pueden ser sobre atributos de más de una tabla. Por
ejemplo, podemos imponer que cada equipo tenga o esté relacionado
con al menos 5 jugadores.
c) Disparadores o triggers
Permiten determinar una acción determinada ante cierta condición. Son
objetos programados por el usuario para tal fin. En nuestro ejemplo
podríamos hacer que cuando un jugador se da de alta en un equipo (en
la tabla equipo) el atributo numero_jugadores en la tabla equipo se
incremente en una unidad de la fila correspondiente a ese equipo.

7
 Test
1. La regla de integridad de entidad consiste en:
a. Un atributo que forma parte de la clave primaria puede tomar un valor
desconocido, pero en ningún caso nulo.
b. Un atributo que forma parte de la clave primaria puede tomar un valor
desconocido o nulo.
c. Si una relación R2 (relación que referencia) tiene un conjunto de atributos
que son clave primaria de la relación R1 (relación referenciada), todos los
valores de dichos atributos deben coincidir con otro grupo de valores de la
clave primaria de R1 o bien ser nulos.
d. Un atributo que forma parte de la clave primaria no puede tomar un valor
desconocido inexistente (nulo).
2. Una clave ajena de una relación hace referencia:
a. A la clave primaria de una relación.
b. A un conjunto de atributos de una relación que han de coincidir con los
valores de la clave primaria de otra relación.
c. A un conjunto de atributos de una relación que han de coincidir con los
valores de la clave primaria de otra relación, que nunca pueden ser nulos.
d. A un conjunto de atributos de una relación que no han de coincidir con los
valores de la clave primaria de otra relación.
3. Cuál de estos nombres no es correcto para denominar las ocurrencias de
entidades almacenadas en una tabla:
a. Fila.
b. Tupla.
c. Columna.
d. Registro.
4. ¿Cuál no es una posibilidad cuando se elimina o modifican filas en la tabla
que contiene una clave primaria que es referenciada desde una clave externa
en otra tabla?
a. Operación con transmisión en cascada.

8
 b. Operación con puesta a nulos.
c. Operación con eliminación de claves foráneas o ajenas.
d. Operación restringida.
5. El Modelo de Datos Relacional…
a. Es el más utilizado después del modelo en red.
b. Ha surgido para complementarse con el modelo jerárquico.
c. Se basa en el uso de relaciones o tablas que agrupan conjuntos de datos en
forma de filas o tuplas.
d. Aunque es el más utilizado no permite incorporar restricciones de ningún
tipo en el modelo.
6. Señala la opción incorrecta
a. Una fila de la tabla es una tupla.
b. Una cabecera de columna es un atributo.
c. El orden de los atributos sí tiene importancia.
El número de ocurrencias (filas) de una relación se llama cardinalidad.
7. Señala la afirmación incorrecta respecto a la intensión
a. Define la estructura de la tabla.
b. Define los atributos de la tabla con los dominios subyacentes.
c. Es considerada el esquema de la relación.
d. Define el conjunto de ocurrencias o tuplas que varían en el tiempo.
8. Indica la afirmación correcta en cuanto a la restricción de clave
a. Siempre pueden existir dos filas con el mismo valor en todos los campos.
b. Pueden existir dos tuplas con el mismo valor en todos los campos, excepto
en uno, el que sea.
c. Pueden existir dos filas iguales siempre y cuando el orden de los atributos
no sea el mismo.
d. No puede haber dos tuplas iguales.
9. Si existe una tabla alumno(dni, nombre, domicilio)
a. dni y nombre serían la clave alternativa.
b. dni y nombre es una clave candidata de la relación.
c. dni y nombre sería la clave primaria.
d. dni y nombre es una superclave.

9
 10. Señala la afirmación incorrecta sobre la aplicación de restricciones mediante
el lenguaje SQL
a. Con las restricciones de verificación se pueden establecer condiciones
b. La restricción de aserción permiten establecer condiciones sobre atributos de
más de una tabla
c. Los triggers permiten realizar una acción determinada si se cumple una
condición
d. Las restricciones de verificación son también consideradas de aserción

Respuestas:

1 d/2 b/3 c/4 d/5 c/6 c/7 d/8 d/9 d/10 d

10