TEMA 4

DISEÑO DE BASES DE DATOS.

.

1.- INTRODUCCIÓN.

A partir del esquema conceptual (ME/R) y teniendo en cuenta los requisitos del
universo del discurso, se elabora un esquema lógico estándar(ELS),que se apoya en un
modelo lógico estándar(MLS),el cual será el mismo modelo de datos (Jerárquico, Codasyl o
Relacional )soportado por el SGBD que se vaya a utilizar pero sin las restricciones ligadas a
ningún producto comercial, en nuestro caso el MLS es el modelo relacional, pero como ya
hemos señalado la metodología se podría aplicar igualmente a los modelos Jerárquico y
Codasyl.
Este ELS se describirá utilizando el lenguaje estándar de datos correspondiente(:SQL,
NDL, etc.).En nuestro caso el SQL, por ser el lenguaje estándar de los SGBD relacionales.
Con el ELS y teniendo en cuenta el modelo lógico especifico(MLE) propio del
SGBD(INGRES,SYSBASE,DB2,ORACLE,INFORMIX,INTERBASE,etc.) se elabora el esquema lógico
especifico(ELE),que será descrito en el LDD(lenguaje de definición de datos)del producto
comercial que estemos utilizando, en los SGBD relacionales este lenguaje será el SQL propio
o especifico del SGBD.
En la fase de diseño lógico de bases de datos, además del MLS, MLE, y los lenguajes
SQL estándar y SQL propio del SGBD utilizado, disponemos de otras herramientas, como
son, los diagramas de dependencias funcionales, la teoría de la normalización, los grafos
relacionales, etc.
CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

2.- MODELO LÓGICO ESTÁNDAR: EL MODELO RELACIONAL.

De los diferentes modelos lógicos estándares que hemos señalado en la introducción,

nosotros nos centraremos única y exclusivamente en el modelo relacional y en el lenguaje
SQL standard como lenguaje de definición de datos para representar el modelo relacional en
el esquema lógico estándar, aunque este lenguaje será objeto de estudio con más
profundidad en posteriores temas.

2.1- INTRODUCCIÓN.

En este capitulo analizaremos el modelo relacional siguiendo, como con el modelo

E/R, la definición formal de modelo de datos. Empezaremos exponiendo la historia y
objetivos del modelo, para pasar a continuaci6n a presentar los aspectos estáticos del
mismo.
La introducci6n por Codd, muy a finales de los años sesenta, de la teoría de las
relaciones en el campo de las bases de datos supuso un importante paso en la invesfigaci6n
de los SGBD, suministrando un sólido fundamento teórico para el desarrollo, dentro de este
enfoque relacional, de nuevos productos.

El documento de Codd propone un modelo de datos basado en la teoría de las

relaciones, en donde los datos se estructuran lógicamente en forma de Raciones -tablas-,
siendo un objetivo fundamental del modelo: mantener la independencia de esta estructura
lógica respecto al modo de almacenamiento y a otras características de tipo físico. En pa -
labras de Codd (1970), "la vista relacional de los datos... parece ser superior al modelo en
grafos o en red... Proporciona un medio de describir datos con su estructura natural
únicamente, es decir, sin superponer ninguno estructura adicional con el propósito de su
representación en la máquina".

El trabajo publicado por Codd en ACM, Codd(1970), presentaba un nuevo modelo de

datos que perseguía una serie de objetivos, muchos de ellos comunes a otros modelos, que
se pueden resumir en los siguientes:
Independencia física: es decir, que el modo en el que se almacenan los datos no
influya en su manipulación lógica y, por tanto, los usuarios que acceden a esos datos no
tengan que modificar sus programas por cambios en el almacenamiento físico
Independencia lógica: esto es, que el añadir, eliminar o modificar objetos de la base
de datos no repercuta en los programas y/o usuarios que están accediendo a subconjuntos
parciales de los mismos (vistas).
Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en
que éste prefiera.
Uniformidad: las estructuras lógicas de los datos presentan un aspecto uniforme, 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 muy
sencillos, producen como resultado que el modelo de datos relacional sea fácil de
comprender y de utilizar por parte del usuario final.

ÁNGEL TARANCÓN MAJÁN PAG: 2

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Queremos insistir en la importancia que Codd concede al tema de la independencia

de la representación lógica de los datos respecto a su almacenamiento interno
(independencia de ordenación, independencia de indexación e independencia de los caminos
de acceso), tal como expresa Codd desde su primer artículo dedicado al modelo relacional,
en cuyos resúmenes se puede leer: "... se propone un modelo relacional de datos como una
base para proteger a los usuarios de sistemas de datos formateados de los cambios que
potencialmente pueden alterar la representación de los datos, causados por el crecimiento
del banco de datos y por los cambios en los caminos de acceso.
Para conseguir los objetivos citados, Codd introduce el concepto de relación—tabla—
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. Formalmente, una relación es un
conjunto de filas en la terminología relacional.

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—no hay que olvidar que una relación es un conjunto—, mientras que otros fueron
introducidos específicamente para el modelo relacional. Todos ellos conforman el álgebra
relacional definida formalmente en Codd (1972), donde además se compara el álgebra
relacional con el otro lenguaje propuesto por Codd en su trabajo de 1970.

La teoría de la normalización, cuyas tres primeras formas normales fueron

introducidas por Codd desde sus primeros trabajos, elimina dependencias entre atributos
que originan anomalías en la actualización de la base de datos y proporciona una estructura
más regular en la representación de relaciones, constituyendo el soporte para el diseño de
bases de datos relacionales.

Las indiscutibles ventajas del modelo relacional no le han librado de críticas, a veces
acerbas y, a veces también, justificadas, especialmente las 4 relativas a la poca eficiencia de
los primeros prototipos y productos comerciales y a su falta de semántica. Si se analiza la
evolución del modelo relacional se observa, que después de los primeros estu dios teóricos
que se extienden a partir de 1970, comienza el desarrollo de diversos prototipos, entre los
que destacan el Sistema R, que se llevó a cabo en los laboratorios de IBM en California y que
fue el origen de los productos relacionales de IBM (DB2, SQL/DS, etc.), e INGRES, que fue
creado en la Universidad de Berkeley, Stonebraker (1986), y convertido más tarde en un
sistema comercial. A pesar de que desde su introducción en 1970, el modelo relacional se
convirtió en uno de los principales temas de investigación en bases de datos, los primeros
sistemas relacionales tardaron unos diez años en aparecer en el mercado, llegándose a
calificar de juguetes, más aptos para la investigación o para el desarrollo de bases de datos
experimentales o de pequeño tamaño que para el soporte de verdaderos sistemas de
información. Probablemente, la teoría relacional nació cuando la tecnología existente en
aquellos momentos no podía todavía ofrecer la adecuada base para instrumentaciones que

ÁNGEL TARANCÓN MAJÁN PAG: 3

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

respondiesen eficientemente a las necesidades de los usuarios, es decir, se podría

considerar la teoría relacional como un niño prematuro cuya cuna no estaba preparada en el
momento de su nacimiento.

A pesar de ello, el modelo de datos relacional ha tenido un auge espectacular desde

finales de los años setenta y, sobre todo, en los ochenta, una vez que empezaron a vencerse
las dificultades que presentaba su instrumentación y gracias al desarrollo tecnológico que ha
permitido una mayor eficiencia de los productos relacionales. A lo largo de estas dos
décadas se han publicado miles de artículos y libros que han ido aclarando y am pliando el
modelo originariamente propuesto por Codd, y también han ido apareciendo productos
comerciales que corren en las más diversas plataformas con rendimientos muy aceptables,
incluso, en muchos casos, comparables a los de los sistemas soportados en modelos
convencionales, aun que en este terreno sigue habiendo autores que ponen en duda la
posibilidad de que los productos relacionales puedan llegar, en cuanto a eficiencia, a la
altura de los basados en otros modelos; ver, por ejemplo, el reciente informe Butler et al.
(1990).

La discusión sobre el mejor modelo de datos, y la inclusión de características

relacionales en productos no relacionales en su origen (sistemas renacimos, en palabras de
Codd) hizo surgir un debate en torno a sí la aplicación del marchamo relacional estaba o no
justificada en muchos casos; Codd(1985) publica sus famosas 12 reglas, analizando algunos
de los productos comerciales en el marco de las mismas, llegando a la conclusión de la
escasa relacionabilidad de la mayoría de los productos que se ofrecían en el mercado.

En 1990 apareció una nueva obra de Codd, en la que presenta la segunda versión del
modelo relacional (RM/V2), ampliando y profundizando en ciertos conceptos como los de
dominio, restricciones de integridad, catálogo, vistas, etc., proponiendo un mejor
tratamiento de los valores nulos (a los que pasa a denominar marcas—"marks"—) y de sus
operaciones asociadas, y estudiando otros temas, como los relativos a la administración,
autorización, distribución y protección de datos. Todo ello organizado en las trescientas
treinta y tres características—agrupadas en dieciocho clases—que, según él, habría de tener
un sistema para ser considerado como relacional, versión 2, Coda (1990).

ÁNGEL TARANCÓN MAJÁN PAG: 4

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

2.2. ESTRUCTURA DEL MODELO RELACIONAL

Como hemos señalado anteriormente, la relación es el elemento básico del modelo

relacional, y se puede representar como una tabla (ver Figura ). En ella podemos distinguir
un conjunto de columnas, denominadas atributos, que representan propiedades de la misma
y que están caracterizadas por un nombre, y un conjunto de filas llamadas tuplas, que son
las ocurrencias de la relación. El número de filas de una relación se denomina cardinalidad,
mientras que el número de columnas es el grado. Existen también dominios de donde los
atributos toman sus valores.

Atributo1 Atributo2 .................. Atributo n

xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx
xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx
xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx
xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx
xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx
xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx

Representación de una relación en forma de tabla

Insistimos en que una relación se puede representar en forma de tabla, aunque tiene
una serie de elementos característicos que la distinguen de la tabla:

 No puede haber filas duplicadas, es decir, todas las tuplas tienen que ser
distintas.
 E1 orden de las filas es irrelevante.
 La tabla es plana, es decir, en el cruce de una fila y una columna sólo puede
haber un valor (no se admiten atributos multivaluados, grupos repetitivos).

Se trata de restricciones inherentes al modelo que más adelante analizaremos. Una

relación siempre tiene un nombre, y en ella es posible distinguir una cabecera (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, extensión, que está formado por un conjunto de tuplas
que varían en el tiempo.

Esta representación de la relación como una tabla ha sido el origen de que los
productos relacionales y los usuarios utilicen habitualmente el nombre de tabla (en principio
ajeno a la teoría relacional) para denominar las relaciones y, como consecuencia de ello, se
llame filas a las tuplas y columnas a los atributos. Sin embargo, debemos advertir que la
terminología es irrelevante y que un producto no es más o menos relacional por utilizar una
u otra terminología.

ÁNGEL TARANCÓN MAJÁN PAG: 5

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

DOMINIOS
COD_EQUIPOS NOMBRES NACIONALIDADES

ESPAÑOLA
9999 XXXXXXXXXX ITALIANA
FRANCESA
4 ALEMANA
15
............

EQUIPOS C
OOO1 NUMANCIA ESPAÑOLA
T A
U R
OOO2 NAPOLES ITALIANA
P = D =5
O128 R.MADRID ESPAÑOLA L I
6512 LYON FRANCESA
A N
S A
OO57 COLONIA ALEMANA
L
I
D
ATRIBUTOS A
D
=

GRADO = 3

Representación de la relación equipos

2.3 DOMINIOS Y ATRIBUTOS.

Un dominio D es un conjunto finito de valores homogéneos y atómicos,V1 V2.....Vn

caracterizados por un nombre; decimos homogéneos por que son todos del mismo tipo, y
atómicos porque son indivisibles en lo que al modelo se refiere(esta exigencia de atomicidad
es sólo es válida para los dominios simples),es decir, si se descompusieran perderían la
semántica a ellos asociada. Por ejemplo, el dominio equipos toma los valores: NUMANCIA,
R.MADRID, NAPOLES, etc., que son todos del mismo tipo (longitud de 15 caracteres) y que
no son divisibles sin perder su semántica, así si descompusiéramos el valor NUMANCIA en
las letras N, U, M, etc., o en grupos de tres caracteres NUM, ANC, etc., se perdería la
semántica, ya que estas letras consideradas aisladamente han dejado de tener el significado
que tenia NUMANCIA como valor de equipo.
Todo dominio ha de tener un nombre por el cual nos podamos referir a él, y un tipo
de datos; así el tipo de datos del dominio de nacionalidades es una tira de caracteres de
longitud diez. También se le puede asociar una unidad de medida, como metros, kilos, etc.,
y ciertas restricciones.
Los dominios pueden definirse por intensión o por extensión. Por ejemplo, el
dominio de las edades de los empleados se define por intensión como entero de longitud
dos comprendido entre 18 y 65, mientras que la definición del dominio de nacionalidades
por intensión sería muy pobre semánticamente, ya que permitiría toda combinación de 10
letras, aun cuando no constituyesen una nacionalidad válida, por ello, seria preferible definir
este dominio por extensión con los nombres de las distintas nacionalidades que
admitiésemos en nuestra base de datos.

ÁNGEL TARANCÓN MAJÁN PAG: 6

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Ejemplo..-

Por intensión.-
CODIGO numérico 4 caracteres
EDAD Entero 2 caracteres
Extensivo.- consiste en describir los distintos valores que puede tomar el dominio.
ESTADO CIVIL S,C,V,D.
NACIONALIDAD ESPAÑOLA, FRANCESA, AMERICANA,...

Un atributo A es el papel que tiene un determinado dominio D en una relación; se

dice que D es el dominio de A y se denota como dom(A). Asi, el atributo nacionalidad de la
tabla EQUIPOS, definido sobre el dominio de nacionalidades nos indica que dicho dominio
tiene el papel de nacionalidad de COD_EQUIPOS en la referida tabla.
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, Al, A2,...,AN, estructurados en
relaciones; cada atributo toma sus valores de un único dominio (dominio subyacente) y
varios atributos pueden tener el mismo dominio subyacente.

Es muy usual dar el mismo nombre al atributo y al dominio subyacente. En el caso de

que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá
que darles nombres distintos ya que una tabla no puede tener dos atributos con el mismo
nombre.
Además de los dominios y atributos simples que acabamos de definir en los últimos
trabajos de algunos autores [Codd (1990), Date (1990)] se introduce el concepto de dominio
compuesto que, puede resultar interesante, desde un punto de vista práctico para el diseño
de datos; y cuya ausencia en el modelo relacional básico no encontrábamos justificada.
Un dominio compuesto se puede definir como una combinación de dominios simples
que tiene un nombre y a la que se pueden aplicar restricciones de integridad. Por ejemplo,
un usuario puede necesitar, además de los tres dominios Día, Mes y Año, un dominio
compuesto denominado Fecha que sería la combinación de los tres primeros, podríamos
aplicar las adecuadas restricciones de integridad a fin de que no aparecieran valores no
válidos para la fecha; algo análogo ocurre con el nombre y los apellidos, que, según las
aplicaciones, puede ser conveniente tratarlos en conjunto o por separado.
De la misma forma, es posible definir un atributo compuesto que tomaría sus valores
del dominio compuesto de igual nombre
Tanto los atributos compuestos como los dominios compuesto pueden ser tratados,
si así lo precisa el usuario, como piezas únicas de información, es decir, como valores
atómicos.

ÁNGEL TARANCÓN MAJÁN PAG: 7

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

2.4. RELACIÓN

Matemáticamente, una relación definida sobre los n dominios Dl, D2, ....,DN no
necesariamente distintos, es un subconjunto del producto cartesiano de estos dominios,
donde cada elemento de la relación, tupla, es una serie de n valores ordenados.

En esta definición matemática de relación, que es la que aparece en los primeros

trabajos de Codd, no se alude a los atributos, es decir, al papel que tienen los dominios en
la relación y, además, en ella el orden de los valores dentro de una tupla es significativo. A
fin de evitar estos inconvenientes, se puede dar otra definición de relación más adecuada al
punto de vista de las bases de datos, para lo cual es preciso distinguir, al igual que hacíamos
con las entidades donde diferenciábamos entre tipo y ocurrencia, dos conceptos en la
noción de relación (a los que ya nos hemos referido)que servirán para definir a estas de dos
formas distintas .

Intensión o Esquema de relación, denotado R (Al: Dl, A2:D2, ..., An: Dn) es un conjunto de n
pares atributo-dominio subyacente (Aj: Di) donde n es el grado del esquema de relación. La
intensión es la parte definitoria y estática de la relación, que se corresponde con la cabecera
cuando la relación se percibe como una tabla (el conjunto A de atributos sobre los que se
define la relación se suele denominar contexto de la misma).

Extensión u ocurrencia (instancia) de relación (llamada a veces simplemente relación),

denotada por r(R) es un conjunto de m tuplas { tl, t2, ..., tm } donde cada tupla es un
conjunto de n pares atributo-valor (Ai: Vij) ,donde Vij es el valor j del dominio Di asociado al
atributo Ai; el número de tuplas m es la cardinalidad. La relación r(R) es, por tanto, el
conjunto de tuplas que, en un instante determinado, satisfacen el correspondiente esquema
de relación R; así como el esquema de relación es - relativamente— invariante, su extensión
varía en el transcurso del tiempo.

Cuando la relación se percibe como una tabla, el cuerpo de la tabla sería la

extensión. En la siguiente figura se representa la intensión y la extensión de la relación
EQUIPOS; obsérvese que en la extensión se ha incluido también, tal como se hace
habitualmente, la cabecera con los nombres de los atributos, en lugar de la representación
que correspondería estrictamente a la definición que acabamos de dar.

ÁNGEL TARANCÓN MAJÁN PAG: 8

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

EXTENSIÓN DE LA RELACIÓN :EQUIPOS

EQUIPOS (COD_E:COD_EQUIPOS, DESCRIPCÓN:EQUIPOS,

NACIONALIDAD:NACIONALIDADES)

EXTENSIÓN DE LA RELACIÓN :EQUIPOS

COD_E DESCRIPCION NACIONALIDAD

OOO1 NUMANCIA ESPAÑOLA

OOO2 NAPOLES ITALIANA

O128 R.MADRID ESPAÑOLA

6512 LYON FRANCESA

OO57 COLONIA ALEMANA

Intensión y extensión de una relación

En adelante las relaciones las definiremos por intensión especificando solamente los
nombres de los dominios que pertenecen a la relación.

2.5. Claves

Una clave candidata de una relación es un conjunto no vacío de atributos que

identifican unívoca y mínimamente cada tupla. 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 repetidas y, por tanto, el conjunto de todos los atributos identificará unívocamente a
las tuplas; si no se cumpliera la condición de minimalidad 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 las tuplas de la relación.
Claves alternativas: son aquellas claves candidatas que no han sido escogidas como
clave primaria.
Se denomina clave ajena de una relación R2 a un conjunto de atributos cuyos
valores han de coincidir con los valores de la clave primaria de una relación R1 (R1 y R2 no
son necesariamente distintas, recuérdese el concepto de interrelación reflexiva). Cabe
destacar que la clave ajena y la correspondiente clave primaria han de estar definidas sobre
los mismos dominios.

ÁNGEL TARANCÓN MAJÁN PAG: 9

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

MODELO E/R.

DNI_J NOMBRE FECHA_N COD_E DESCRIPCIÓN

1:N NACIONALIDAD

(8,n) (1,1)
JUGADORES PERTENECEN EQUIPOS

MODELO RELACIONAL:

JUGADORES (DNI_J, NOMBRE, FECHA_N,.........., COD_E)

CLAVE PRIMARIA CLAVE AJENA (relaciona JUGADORES
con sus EQUIPOS)

EQUIPOS(COD_E, DESCRIPCIÓN, NACIONALIDAD ,.......,)

CLAVE PRIMARIA

MODELO E/R.
COD_P FECHA FUNCIÓN DNI_A NOMBRE

PARTIDOS ARBITRAJES ARBITROS

(0,n) (4,4)

4:N

MODELO RELACIONAL.

PARTIDOS ( COD_P, FECHA,..........,)

CLAVE PRIMARIA

ARBITRAJES( COD_P, DNI_A, FUNCION)

CLAVE PRIMARIA CLAVE PRIMARIA
Y AJENA DE PARTIDOS Y AJENA DE ARBITROS

ARBITROS(DNI_A, NOMBRE,..........,)
CLAVE PRIMARIA

ÁNGEL TARANCÓN MAJÁN PAG: 10

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

2.6 RESTRICCIONES

En el modelo relacional, al igual que en otros modelos, existen restricciones, es decir,

estructuras u ocurrencias no permitidas, siendo preciso distinguir entre restricciones
inherentes y restricciones de usuario. Los datos almacenados en la base han de adaptarse a
las estructuras impuestas por el modelo (por ejemplo, no tener tuplas duplicadas) y han de
cumplir las restricciones de usuario para constituir una ocurrencia válida del esquema.

2.6.1. Restricciones inherentes

En el modelo relacional cabe mencionar como restricciones inherentes, además de las
derivadas de la definición matemática de relación, la integridad de entidad.

De la definición matemática de relación se deduce inmediatamente una serie de

características propias de una relación que se han de cumplir obligatoriamente, por lo que
se trata de restricciones inherentes y que, como ya hemos señalado, diferencian una relación
de una tabla:

 No hay dos tuplas iguales.

 El orden de las tuplas no es significativo.
 El orden de los atributos (columnas) no es significativo. Cada atributo sólo puede
tomar un único valor del dominio, no admitiéndose por tanto los grupos
repetitivos.

La regla de integridad de entidad establece que "Ningún atributo que forme parte de
la clave primaria de una relación puede tomar un valor nulo"; esto es, un valor desconocido o
inexistente. Esta restricción debería aplicarse también a las claves alternativas, pero el
modelo no lo exige.

2.6.2. Restricciones de usuario

Podemos considerar la restricción de usuario, dentro del contexto relacional, como
un predicado(condición)definido sobre un conjunto de atributos, de tuplas o de dominios,
que debe ser verificado por los correspondientes objetos para que éstos constituyan una
ocurrencia válida del esquema.

Dentro de las restricciones de usuario destaca la restricción de integridad referencial

que se expresa de la siguiente manera: "Si una relación R2(relación que referencia) tiene un
descriptor que es la clave primaria de la relación R1 (relación referenciada), todo valor de
dicho descriptor debe, concordar con un valor de la clave primaria de R1, o ser nulo". El des-
criptor es, por tanto, una clave ajena de la relación R2 ,R1 y R2 son relaciones no
necesariamente distintas. Además, cabe destacar que la clave ajena puede ser también parte
de la clave primaria de R2.

ÁNGEL TARANCÓN MAJÁN PAG: 11

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

La integridad referencial es una restricción de comportamiento ya que viene impuesta

por el mundo real y es el usuario quien la define al describir el esquema relacional; es
también de tipo implícito, ya que se define en el esquema y el modelo la reconoce (no así
algunos productos) sin necesidad de que se programe ni de que se tenga que escribir
ningún procedimiento para obligar a que se cumpla.

En la Figura 1a) se muestra un ejemplo de clave ajena: el atributo nombre_e de la

relación LIBRO es clave ajena que referencia a EDITRIAL, de modo que debe concordar con la
clave primaria de la relación EDITORIAL o bien ser nulo, porque los libros de nuestra base de
dates deberán pertenecer a una editorial existente, o si se desconoce la editorial no se
tendrá ningún valor para este atributo. En la Figura 1b), la relación ESCRIBE posee dos claves
ajenas: nombre, que referencia a la relación AUTOR, y código, que referencia a la relación
LIBRO; en este caso ninguna de las dos claves ajenas puede tomar valores nulos, ya que
forman parte de la clave primaria de la relación ESCRIBE.

EDITORIAL ( NOMBRE_E, DIRRECCIÓN, CIUDAD, PAIS)

LIBRO (CÓDIGO, TITULO, IDIOMA,......., NOMBRE_E)

clave ajena
fig. 1a

AUTOR ( NOMBRE, NACIONALIDAD, INSTITUCIÓN.....)

LIBRO (CÓDIGO,TITULO , IDIOMA, EDITOTIAL....)

ESCRIBE(NOMBRE, COD-LIBRO)
clave ajena clave ajena

fig.1b

ÁNGEL TARANCÓN MAJÁN PAG: 12

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Hay que observar que todo atributo de una clave primaria compuesta de una relación
R1,sino está definido sobre un dominio compuesto, debe ser clave ajena de R2,
reverenciando a una relación R2, cuya clave primaria sea simple.

Además de definir las claves ajenas, hay que determinar las consecuencias que
pueden tener ciertas operaciones (BORRADO)realizadas sobre tuplas de la relación
referenciada; pudiéndose distinguir, en principio, las siguientes opciones:
Operación restringida (RESTRICT): esto es, el borrado o la modificación de 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 con tiene la clave ajena. Esto nos llevaría, por
ejemplo, a que para poder 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): esto es, el borrado o la
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 contiene
la clave ajena. En nuestro ejemplo, equivaldría a decir que 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.
Operación con puesta a nulos (SET NULL): esto es, el borrado o la modificación de
tuplas de la relación que contiene la clave primaria referenciada lleva consigo poner a nulos
los valores de las claves ajenas de la relación que referencia. Esto nos llevaría a que cuando
se borra una editorial, a los libros que ha publicado dicha editorial y que se encuentran en la
relación LIBROS 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): esto es, 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 ajena de la relación que referencia; valor por
defecto que habría sido definido al crear la tabla correspondiente.

ÁNGEL TARANCÓN MAJÁN PAG: 13

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

3. CONVERSIÓN DEL ESQUEMA CONCEPTUAL AL LÓGICO ESTÁNDAR.

El paso de un esquema en el ME/R al relacional está basado en los tres principios

siguientes:
 Todo tipo de entidad se convierte en una relación.
 Todo tipo de interrelación N:M se transforma en una relación (tabla).
 Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave
(casi siempre y lo más aconsejable) o se transforma en una nueva relación.

3.1 REGLAS PARA EL ME/R BÁSICO.

3.1.1 Transformación de dominios

En el modelo relacional estándar un dominio es un objeto más, propio de la

estructura del modelo que, como tal, tendrá su definición concreta en el lenguaje de
definición de datos que se elija. Como ejemplo podemos crear el dominio de los estados
civiles, que es el conjunto de valores de tipo carácter, de longitud 1,y que puede tomar los
valores S,C,V,D.

MER:

E_CIVIL

MR:

DOMINIO E_CIVIL CHAR(1) IN (‘S’,’C’,’V’,’D’)

ESQUEMA RELACIONAL:Definido a través del SQL estándar

CREATE DOMAIN E_CIVIL AS CHAR(1)

CHECK (VALUE IN (‘S’,’C’,’V’,’D’))

Aun que pocos productos comerciales tratan los dominios, nosotros lo especificamos
porque el diseño lógico estándar si lo contempla y se trata de un aspecto importante en la
definición de relación en el modelo relacional. Muchos productos comerciales al dominio lo
tratan como restricciones de los atributos en las relaciones o tablas, pero este es un aspecto
del diseño lógico especifico que en cada momento lo resolveremos como proceda en el
correspondiente SGBD.

ÁNGEL TARANCÓN MAJÁN PAG: 14

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

3.1.2 Transformación de entidades. Según lo que hemos indicado anteriormente,

"cada tipo de entidad se convierte en una relación". Esto es, el modelo lógico estándar
posee el objeto RELACION o TABLA mediante el cual representamos las entidades. La tabla
se llamará igual que el tipo de entidad de donde proviene. Para su definición disponemos en
el SQL de la sentencia CREATE TABLE( aunque lo habitual es definirlos dentro de la tabla
como restricciones de los atributos, opción permitida en la sentencia CREATE TABLE). Por
ejemplo, la entidad EQUIPOS se transforma en una RELACIÓN(tabla) identificada con ese
mismo nombre(ver Figura). En este caso la transformación es directa y no hay pérdida de
semántica.
3.1.2 Transformación de atributos de entidades. Cada atributo de una entidad se
transforma en una columna de la relación a la que ha dado lugar la entidad. Pero teniendo
en cuenta que tenemos atributos identificadores principales, identificadores alternativos y el
resto de atributos que no son identificadores—atributos no principales—desglosamos esta
regla en tres subreglas:
Atributos identificadores principales . El (o los) atributo(s) identificador(es)
principal(es) (AIP en adelante) de cada tipo de entidad pasan a ser la clave primaria de la
relación. Por ejemplo, en la Figura anterior tenemos la relación EQUIPOS, fruto de la
transformación de la entidad del mismo nombre, con su AIP correspondiente como clave
primaria. El lenguaje lógico estándar (LLS) recoge directamente este concepto por medio de
la cláusula PRIMARY KEY(CLAVE PRIMARIA) en la descripción de la tabla, luego la
transformación es directa y no hay pérdida de semántica.
Atributos identificadores alternativos. Respecto a los atributos identificadores
alternativos el MLS recoge por medio de la cláusula UNIQUE estos objetos, ya que son
soportados directamente por el modelo relacional. Al ser la transformación directa no hay
perdida de semántica.
Atributos no identificadores. Los atributos no principales pasan a ser columnas de la
tabla, las cuales tienen permitido tomar valores nulos, a no ser que se indique los contrario.

MER:
COD_CL (AIP) NIF (AIC) PAIS

CLIENTES

MR:

CLIENTES (COD_CL:CODIGOS,NIF:NIF,PAIS:PAISES’)

ESQUEMA RELACIONAL:Definido a través del SQL

estándar
CREATE TABLE CLIENTES
( COD_CL CODIGOS
NIF NIF
ÁNGEL TARANCÓN MAJÁN PAG: 15
PAIS PAISES
PRIMARY KEY (COD_CL)
UNIQUE (NIF))
CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

3.1.3 Transformación de interrelaciones.

Dependiendo del tipo de correspondencia variará la manera la manera de realizar la
transformación al modelo relacional, por eso desglosamos esta regla en tres subreglas:

3.1.3.1 Interrelaciones N:M un tipo de interrelación N:M se transforma en una

relación que tendrá como clave primaria la concatenación de los atributos identificadores
principales de los tipos de entidades que asocia. Además cada uno de los atributos que
forman parte de la clave primaria de esta relación son claves ajenas de cada una de las
tablas donde este atributo es clave primaria, lo que se especifica en el ELS a través de la
cláusula FOREIGN KEY dentro de la sentencia de creación de la tabla. Habrá que estudiar
además, que ocurre en el caso del borrado o modificación de la clave primaria referenciada,
teniendo en cuenta que en el ELS las opciones permitidas son RESTRICT(en caso de no
especificar la opción),SET NULL;SET DEFAULT;CASCADE

MER:

DNI NOMBRE COD_V DIRECCION

PERSONAS PROPIETARIO VIVIENDAS

MR:
PERSONAS (DNI,
DNI,NOMBRE)

PROPIETARIO(DNI,COD_V)

VIVIENDAS(COD_V,DIRECCIÓN)
ESQUEMA RELACIONAL:Definido a través del SQL estándar
CREATE TABLE PERSONAS (.........)
CREATE TABLE VIVIENDAS(.........)
CREATE TABLE PROPIETARIO
( DNI DNI,COD_V CODIGOS,
PRIMARY KEY (DNI,COD_V),
FOREIGN KEY (DNI) REFERENCES PERSONAS
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN FEY(COD_V) REFERENCES VIVIENDAS
ON UPDATE CASCADE)

otra transformación que debemos recoger en esta transformación son las

cardinalidades mínimas y máximas de cada una de las entidades que intervienen lo que se
hace mediante aserciones o restricciones CREATE ASSERTION CHECK(cuya descripción no
veremos hasta que Vds. No alcancen conocimientos de SQL).

ÁNGEL TARANCÓN MAJÁN PAG: 16

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

3.1.3.2 Interelaciones 1:N. Existen dos soluciones para la transformación de las

interrelaciones 1:N:
A.-) Propagar el atributo identificador principal del tipo de entidad que tiene la
cardinalidad máxima 1 a la que tiene N, es decir en el sentido de la fecha.

MER:

DNI NOMBRE COD_V DIRECCION

1;N
(O,n) (1,1)

PERSONAS HABITA VIVIENDAS

MR:
PERSONAS (DNI,
DNI,NOMBRE,COD_V)
No nula

VIVIENDAS(COD_V,DIRECCIÓN)

ESQUEMA RELACIONAL:Definido a través del SQL estándar

CREATE TABLE VIVIENDAS(.........)
CREATE TABLE PERSONAS
( DNI DNI,NOMBRE NOMBRES,COD_V CODIGOS,
PRIMARY KEY (DNI),
FOREIGN KEY (COD_V) REFERENCES VIVIENDAS
ON DELETE CASCADE
ON UPDATE CASCADE,
CHECK( COD_V IS NOT NULL) )

Cuando se utiliza el mecanismo de propagación de clave es conveniente analizar las

cardinalidades mínimas de la entidad que propaga la clave para evitar la perdida de
semántica en la transformación, como la clave ajena permite nulos este problema lo
resolvemos con la cláusula IS NOT NULL.
B.-) Transformarla en una relación, como si se tratase de una interrelación
N:M. Esta posibilidad se debe usar cuando se prevea que en el futuro la interrelación
se puede convertir en N:M

ÁNGEL TARANCÓN MAJÁN PAG: 17

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Una interrelación de tipo 1:1 es un caso particular de una N:M o, más

restrictivamente, de una 1:N, por lo que no hay regla fija para la transformación de este tipo
de interrelación en el modelo relacional estándar, pudiéndose aplicar la regla 4.1 (con lo que
crearíamos una relación) o aplicar la regla 4.2. (esto es, propagar la clave correspondiente).
En este último caso hay que observar que la propagación de la clave puede efectuarse en
ambas direcciones.

Los criterios para aplicar una u otra regla y para propagar la clave se basan en las
cardinalidades mínimas, en recoger la mayor cantidad de semántica posible, evitar los
valores nulos e incluso en motivos de eficiencia. A continuación exponemos algunos
ejemplos:
A.- Si las entidades que se asocian poseen cardinalidades (0,1), entonces la
interrelación 1:1 se transformará en una relación, además de las dos relaciones que
representan cada una de las entidades. Por ejemplo, en la siguiente figura ,tenemos la aso -
ciación MATRIMONIO entre las entidades HOMBRE y MUJER que se transforma en una
relación, evitando así los valores nulos que aparecerían en caso de propagar la clave de la
entidad MUJER a la tabla HOMBRE o viceversa, ya que como reflejan las cardinalidades no
todos los hombres ni todas las mujeres se encuentran casados.

MER
DNI N OMBRE
DNI N OMBRE
1:1
(0,1,) (0,1)
HOMBRES MATR IM ONIO MUJERES

MR
HOMBRES( DNI, NOMBRE)

MUJERES (DNI,NOMBRE)

MATRIMONIO(DNI,DNI_M )

ESQUEMA RELACIONAL:Definido a través del SQL

estándar.
CREATE TABLE HOMBRES(.......)
CREATE TABLE MUJERES(........)
CREATE TABLE MATRIMONIO(DNIDNIS,DNI_MDNIS
PRIMARY KEY (DNI,DNI_M),
FOREIGN KEY (DNI) REFERENCES HOMBRES ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (DNI_M) REFERENCES HOMBRES ON DELETE CASCADE
ON UPDATE CASCADE)

b) Si una de las entidades que participa en la interrelación posee cardinalidades (0,1),

mientras que en la otra son (1,1), conviene propagar la clave de la entidad con
cardinalidades (1,1) a la tabla resultante de la entidad de cardinalidades (0,1). En la Figura
tenemos una interrelación que recoge el empleado que es responsable de un departamento,
suponiendo que un empleado puede ser responsable como máximo de un departamento y
que cada departamento tiene que tener un responsable (pero sólo uno), en cuyo caso
propagamos la clave de EMPLEADO a la tabla de DEPARTAMENTO, evitando así valores nulos

ÁNGEL TARANCÓN MAJÁN PAG: 18

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

y captando más semántica (recogemos la cardinalidad mínima 1, que en caso de realizar la

propagación en sentido contrario no podríamos captar directamente).

MER
COD _D D ESCR IPCION

1:1
DNI N OMBRE

(1,1,) (0,1)
EMPLEADOS R ESPONSABLE DEPARTAMEN TOS

MR
EMPLEADO( DNI, NOMBRE)

DEPARTAMENTO(COD_D,DESCRIPCION,DNI )
NO NULA

ESQUEMA RELACIONAL:Definido a través del SQL

estándar.
CREATE TABLE EMPLEADOS(.......)
CREATE TABLE DEPARTAMENTOS(COD_D CODIGOS,
DESCRIPCIO DESCRIPCIONES,DNI DNIS,
PRIMARY KEY (COD-D),
FOREIGN KEY (DNI) REFERENCES EMPLEADOS ,
CHECK (DNI IS NOT NULL)
)

C.-En el caso de que ambas entidades presenten cardinalidades (1,1), se puede

propagar la clave de cualquiera de ellas a la tabla resultante de la otra, teniendo en cuenta
en este caso los accesos más frecuentes y prioritarios a los datos de las tablas. Se puede
plantear (también por motivos de eficiencia) la propagación de las dos claves, lo que
introduce redundancias que deben ser controladas por medio de restricciones.

3.1.4 Transformación de atributos de interrelaciones. Si la interrelación se transforma en una

relación, todos sus atributos pasan a ser columnas de la relación y si alguno de ellos fuera
AIP este formaría parte de la clave primaria de la relación.

En caso de que la interrelación se transforme mediante propagación de clave, sus

atributos migran junto a la clave de la relación que corresponda, aunque ya hemos
advertido que suele ser mejor crear una nueva relación para representar la interrelación que
tiene atributos, a veces por cuestiones de eficacia y cuando las cardinalidades máximas de la
interrelación N:M son conocidas, coinciden con las mínimas y no altas conviene emplear el
procedimiento de propagación de clave, tantas veces como se desprenda de la cardinalidad
máxima de la entidad que va a propagar la clave, en lugar de convertir la interrelación en
otra relación o tabla.

ÁNGEL TARANCÓN MAJÁN PAG: 19

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

MER
COD_P FECHA COD_E NOMBRE
2:N
(1,n) (2,2)
PARTIDOS DISPUTAN EQUIPOS

MR
EQUIPOS(COD_E,NOMBRE)

PARTIDOS(COD_P,FECHA,EQUIPO1,EQUIPO2)
CLAVE AJENA CLAVE AJENA
NO NULA NO NULA

ESQUEMA RELACIONAL

CREATE TABLE EQUIPOS (................)

CREATE TABLE PARTIDOS( COD_P CODS,FECHA FECHAS,EQIPO1 CODIGOS,
EQUIPO2 CODIGOS,
PRIMARY KEY (COD_P),FOREIGN KEY EQUIPO1 REFERENCES EQUIPOS,
FOREIGN KEY EQUIPO2 REFERENCES EQUIPOS,
CHECK(EQUIPO1 NOT NULL AND EQUIPO2 NOT NULL AND (EQUIPO1<>EQUIPO2))

Y si la interrelación tiene atributos, como en el ejemplo siguiente donde las funciones

a realizar son: arbitro principal,4ºárbitro y arbitro asistente(recuérdese que en un partido de
fútbol intervienen dos árbitros asistentes además del arbitro principal y el
4ºárbitro)podríamos proceder de la siguiente forma.

MER
COD_P FECHA FUNCION DNI NOMBRE
4:N
(1,n) (4,4)
PARTIDOS ARBITRAJES ARBITROS

MR
ARBITROS(DNI,NOMBRE)

PARTIDOS(COD_P,FECHA,DNI1,FUNCION1,DNI2,FUNCION2,DNI3,FUNCION3,DNI4,FUNCION4)
CLAVE AJENA
CLAVE AJENA
NO NULA CLAVE AJENA CLAVE AJENA
NO NULA
NO NULA NO NULA
ESQUEMA RELACIONAL
CREATE TABLE ARBITROS (................)
CREATE TABLE PARTIDOS( COD_P CODS,FECHA FECHAS,DNI1 DNIS,FUNCION1
FUNCIONES,DNI2 DNIS,FUNCION2 FUNCIONES,DNI3 DNIS,FUNCION3 FUNCIONES,
DNI4 DNIS,FUNCION4FUNCIONES, PRIMARY KEY (COD_P),FOREIGN KEY DNI1
REFERENCES ARBITROS,.........,FOREIGN KEY DNI4 REFERENCES ARBITROS,
CHECK(DNI1 NOT NULL AND DNI2 NOT NULL AND DNI3 NOT NULL AND DNI4 NOT
NULL AND (FUNCION3=FUNCION4) AND)AND (FUNCION1<>FUNCION2) AND
(FUNCION1<>FUNCION3) AND (FUNCION2<>FUNCIO3) AND DNI1<>DNI2 AND DNI1
<>DNI3 AND DNI1<>DNI4 AND DNI2<>DNI3 AND DNI2<>DNI4 AND DNI3<>DNI4) )

Las restricciones sobre atributos normales deben ser las mínimas posibles(se cuenta con la
buena fe e instrucción del grabador de datos)aunque en este caso con fines didácticos se ha
optado por especificar las restricciones sobre el atributo función.

ÁNGEL TARANCÓN MAJÁN PAG: 20

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Si en el momento de diseñar la base de datos tenemos dudas (razonables o no) de

que en un futuro el dominio sobre el que se define el atributo de la interrelación es
susceptible de ampliarse con nuevos valores o modificarse estos lo más eficiente es
convertir el atributo en una entidad y la interrelación de grado 3 (4,5..etc) convertirla en una
tabla en el modelo relacional, como hubiese sido lo más apropiado en nuestro ejemplo con
el atributo función de la interrelación arbitrajes.

3.1.5. Transformación de restricciones. En cuanto a las restricciones de usuario, existen

ciertas cláusulas en el LLS que pueden recogerlas. Por ejemplo, podemos restringir a un
rango determinado los valores de un dominio a través de la cláusula RANGE BETWEEN, o
determinar por enumeración los valores que puede tomar una columna en una tabla con la
cláusula IN, como podemos observar en la regla de definición de los dominios.
Otra posibilidad es utilizar la cláusula CHECK dentro de la descripción de la tabla
para expresar una condición que debe cumplir un conjunto de atributos. Por ejemplo, para
que la fecha de inicio de un préstamo sea siempre menor que la de finalización, en la
creación de la tabla PESTAMOS en el esquema relacional escribiríamos las siguientes
sentencias SQL:

CREATE TABLE PRÉSTAMO

( Cod_Socio Códigos_Socio,
Cod_Ejemplar Cods,
Fecha_I Fechas,
Fecha_F Fechas,
PRIMARY KEY (Cod_Socio, Cod_Ejemplar, Fecha_1),
FOREIGN KEY (Cod_Socio) REFERENCES Socio
ON UPDATE CASCADE,
FOREIGN KEY (Cod_Ejemplar) REFERENCES Ejemplar
ON UPDATE CASCADE,
CHECK ( Fecha_I < Fecha_F ).

ÁNGEL TARANCÓN MAJÁN PAG: 21

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

4. REGLAS CONCERNIENTES A LAS EXTENSIONES DEL MODELO E/R

4.1 Transformación de dependencias en identificación y en existencia. Las dependencias en
existencia y en identificación no son recogidas directamente en el MLS. En el ejemplo de la
siguiente Figura vemos que la manera de transformar una interrelación de este tipo es
utilizar el mecanismo de propagación de clave, creando una clave ajena no nula, en la
relación de la entidad dependiente, con la característica de obligar a un borrado en cascada.

Además, en el caso de dependencia en identificación la clave primaria de la relación

de la entidad débil debe estar formada por la concatenación de las claves de las dos
entidades participantes en la interrelación.

MR
LIBRO (cod_libro, )

EJEMPLAR (cod_libro, cod_ejemplar,)

Esquema relacional

CREATE TABLE LIBROS( Cod_Libro Isbns, ............,

PRIMARY KEY (Cod_Libro) ) ~

CREATE TABLE EJEMPLAR( Cod_Libro Isbns, Cod_Ejemplar Cods,.........,

PRIMARY KEY (Cod_Libro, Cod_Ejemplar) —
FOREIGN KEY (Cod_Libro) REFERENCES Libro
ON DELETE CASCADE
)

4.2. transformación de interrelaciones exclusivas. Para soportar interrelaciones exclusivas

debemos definir las restricciones pertinentes en cada caso. Por ejemplo, en la Figura se
muestra que existe una exclusividad entre la edición de un libro por parte de una editorial o
de una universidad. Las interrelaciones edita1 y edita2 las resolvemos mediante el meca-
nismo de propagación de clave, llevando cod_universidad y cod_editorial a la relación LIBRO.

Para obligar a que se cumpla la exclusividad habría que introducir las

correspondientes restricciones en una cláusula CHECK, tal como se indica a continuación:

ÁNGEL TARANCÓN MAJÁN PAG: 22

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

C O D _ U N IV E R S ID A D

M ER 1 :N ( 0 ,1 )
C O D _ L IB R O U N IVERSID A D
T IT U L O

( 0 ,n )
LIBRO C O D -E D IT O R IA L

( 1 ,n )
M R ED ITO RIA L
( 0 ,1 )
1 :N

E S Q U E M A R E L A C IO N A L D E L A T A B L A L IB R O
C R E A T E T A B L E L ib r o ( C o d _ L ib r o I s b n s , t i t u l o t i t u l o s
C o d _ E d i t o r ia l C o d s _ E ,
C o d _ U n iv e r s id a d C o d s _ U ,
P R I M A R Y K E Y ( C o d _ L ib r o )
F O R E I G N K E Y ( C o d _ E d i t o r ia l) R E F E R E N C E S E d i t o r ia l
O N U PD A TE CA SCA D E
F O R E IG N K E Y ( C o d _ U n iv e r s i d a d ) R E F E R E N C E S U n i v e r s id a d
O N U PD A T E CA SCA D E
C H E C K ( ( C o d _ E d i t o r ia l I S N U L L A N D C o d _ U n iv e r s id a d I S N O T N U L L )
OR
( C o d _ U n i v e r s i d a d I S N U L L A N D C o d _ E d i t o r ia l I S N O T N U L L ) ) )

4.3 Transformación de tipos y subtipos.

En lo que respecta a los tipos y subtipos, no son objetos que se puedan representar
explícitamente en el modelo relacional estándar. Ante una entidad y sus subtipos caben
varias soluciones de transformación en el modelo relacional, con la consiguiente pérdida de
semántica dependiendo de la estrategia elegida. Destacamos tres principalmente:

COD_P NOMBRE

POLICIAS

(1,1) PLU_PELIG
TIPO_P
TÏTULO_ACA
(O,n)

ADMINIS ES_UN AGENTES

TRATIVOS (0,1) (O,1)

MR

SOLUCION A
POLICIAS( COD_P, NOMBRE,.....,TIPO_P,TITULO_ACA,PLUS_PELIG
SOLUCION B

POLICIAS (COD_P,NOMBRE,......)

ADMINISTRATIVOS( COD_P, TITULO_ACA)

AGENTES(COD_P,PLUS_PELIG)
SOLUCION C
ADMINISTRATIVOS( COD_P, NOMBRE,.....,TITULO_ACA,)
AGENTES( COD_P, NOMBRE,.....,PLUS_PELIG)

ÁNGEL TARANCÓN MAJÁN PAG: 23

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Opción a: Englobar todos los atributos de la entidad y sus subtipos en una sola relación. En
general, adoptaremos esta solución cuandolos subtipos se diferencien en muy pocos
atributos y las interrelaciones que los asocian con el resto de las entidades del esquema
sean las mismas para todos los subtipos. Por ejemplo, la diferencia que existe entre un
AGENTE y un ADMINISTRATIVO podemos considerarla como mínima desde el punto de vista
de ser POLICIA.
Por este motivo, la solución adecuada en este caso sería la creación de una sola tabla
que contenga todos los atributos del supertipos y los de los subtipos, añadiendo un atributo
adicional que indique el tipo de policia que es (el atributo discriminante de la jerarquia)
También habrá que especificar Jas restricciones semánticas correspondientes, por
ejemplo:
CHECK ( (Tipo_p = 'ADMINISTRATIVO'
AND plus_pelig IS NULL
AND titulo_Aca IS NOT NULL)
OR
(Tipo_p = ' AGENTE '
AND plus_pelig IS NOT NULL
AND Titulo_aca IS NULL) )

Hay que observar que el atributo discriminante de la jerarquía podrá admitir valores
nulos en el caso de que la jerarquía sea parcial y que deberá declararse como NOT NULL si la
jerarquía es total.
Por otra parte, el atributo discriminante constituirá un grupo repetitivo si los
subtipos se solapan, debiendo, por tanto, separar este atributo en una relación aparte y
crear una relación que asocie este atributo con la relación resultante del supertipo.

Opción b: Crear una relación para el supertipo y tantas relaciones como subtipos haya, con
sus atributos correspondientes. Esta es la solución adecuada cuando existen muchos
atributos distintos entre los subtipos y se quieren mantener de todas maneras los atributos
comunes a todos ellos en una relación. Al igual que en el caso anterior, habrá que crear las
restricciones y/o aserciones oportunas.

Opción c: Considerar relaciones distintas para cada subtipo, que contengan además los
atributos comunes. Se elegiría esta opción cuando se dieran las mismas condiciones que en
el caso anterior muchos atributos distintos—y los accesos realizados sobre los datos de los
distintos subtipos siempre afectan a atributos comunes.
Podemos, por tanto, elegir entre tres estrategias distintas para la
transformación de un tipo y sus subtipos al modelo relacional. Sin embargo,
desde un punto de vista exclusivamente semántico la opción b es la mejor.
Por otra parte, desde el punto de vista de la eficiencia tenemos que tener en
cuenta que:

ÁNGEL TARANCÓN MAJÁN PAG: 24

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

Opción a: E1 acceso a una fila que refleje toda la información de una determinada
entidad es mucho más rápido (no hace falta combinar varias relaciones).
Opción b: La menos eficiente, aunque, como ya hemos señalado, es la mejor desde
un punto de vista exclusivamente semántico.
Opción c: Con esta solución aumentamos la eficiencia ante determinadas consultas
(por ejemplo, las que afecten a todos los atributos de un subtipo) pero la disminuimos ante
otras (como las que conciernen a los atributos comunes de los distintos subtipos) e introdu-
cimos redundancias. Esta solución es en la que se pierde más semántica.

Elegiremos una estrategia u otra dependiendo de que sea la semántica o la

eficiencia la que prime para el usuario en un momento determinado. Por lo que se refiere a
la totalidad/parcialidad de la jerarquía y al solapamiento/disyunción de los subtipos, pueden
ser soportados por medio de restricciones en el propio esquema y por procedimientos que
recojan la semántica asociada a la dinámica de estos casos.
Por último, cabe destacar que en próximas versiones del lenguaje SQL (como la
denominada (SQL3) se están definiendo más elementos a fin de soportar directamente la
herencia por medio de las denominadas subtablas, véase ANSI (1991).

4.4 Transformación de la dimensión temporal. En el caso de que en el esquema E/R aparezca

el tiempo como una entidad más, la transformación en el esquema relacional estándar no
constituye mayor problema, ya que se tratará como otra entidad cualquiera, y por lo tanto se
creará una relación más .
Sin embargo, cuando la dimensión temporal la hemos recogido en el esquema E/R a
través de atributos de interrelación de tipo FECHA, la transformación en el MLS consiste en
pasarlos a columnas de la relación que corresponda. Sobre este punto debemos tener
cuidado a la hora de elegir la clave primaria de la relación resultante, dependiendo de los
supuestos semánticos del entorno.

4.5 Transformación de Atributos Derivados. No existe para los atributos derivados una
representación directa y concreta en el MLE, sino que se pueden tratar como atributos
normales, que pasarán a ser columnas de la relación que corresponda .En este caso es
preciso construir un procedimiento que calcule el valor del atributo derivado cada vez que se
inserten o borren las ocurrencias de los atributos que intervienen en el cálculo de éste y
añadir la restricciones correspondientes. Otra solución es no almacenar las columnas que
provengan de atributos derivados, creando procedimientos disparadores (triggers)que
calculen los valores de éstas cada vez que se recuperan, lo que en ocasiones puede resultar
más eficiente, pero puede plantear problemas de integridad y de semántica.

5. GRAFO RELACIONAL
Una forma de representar gráficamente el esquema relacional de una manera sencilla
y completa es el denominado grafo relacional, diagrama esquemático [Smith (1985)] o grafo
de combinación [Schkolnick y Sorensen (1980)].
Es un grafo compuesto de un conjunto de nodos multiparticionados, donde cada nodo
representa un esquema de relación, es decir, una tabla de la BD. Para cada tabla, como

ÁNGEL TARANCÓN MAJÁN PAG: 25

CICLO FORMATIVO : DAW MODULO PROFESIONAL: BASES DE DATOS

mínimo, ha de aparecer su nombre y sus atributos, indicando su clave primaria (subrayando

los atributos que la componen con trazo continuo) y sus claves ajenas (subrayando los
correspondientes atributos por trazo discontinuo

ÁNGEL TARANCÓN MAJÁN PAG: 26