MODELO

RELACIONAL

- UT3 -
RA6: Diseña modelos relacionales normalizados
interpretando diagramas entidad/relación

Se han utilizado Se han identificado los

Se han identificado
herramientas gráficas campos que forman
las tablas del diseño
para representar el parte de las tablas del
lógico.
diseño lógico. diseño lógico.

Se han analizado las

relaciones entre las Se han identificado los
tablas del diseño campos clave
lógico.
 INTRODUCCIÓN
Una base de datos relacional es un conjunto de una o más relaciones estructuradas
en tuplas (que son las filas o registros) que se vinculan entre sí por un campo en
común (un elemento de la tupla). En la práctica lo entendemos mejor si pensamos
en una relación como una tabla con filas (registros) y columnas (campos).
Un SGBD relacional gestiona bases de datos construidas bajo estos principios.
Una vez que hemos diseñado nuestro modelo E-R, debemos transformarlo al modelo
relacional el cual es interpretable por los SGBD relacionales. Para ello haremos una serie
de consideraciones y se tendrán en cuenta algunos conceptos.
 Conceptos básicos
Grado de una tabla: Nº de campos que tiene. No tiene que ver con el grado del modelo
E/R que define el nº de entidades que intervienen en una relación.
Cardinalidad de una tabla: Nº de filas que tiene. No tiene que ver con el conceptos de
cardinalidad estudiado en el modelo E/R que definía el nº de instancias de una entidad que
participaba en una relación.
Dominio de un campo: Conjunto de valores homogéneos y atómicos que puede tomar el
campo caracterizados por un nombre. (Atómico: que no se puede subdividir). Este dominio
define el tipo de datos que toma un campo y puede ser definido por el administrador de la
BD. (Ver tabla de tipos de datos)
Clave o llave primaria (PK): Conjunto no vacío de atributos que identifican unívoca y
mínimamente una fila.
Clave o llave foránea (FK): Clave primaria de otra tabla con la que está relacionada y a
la que hace referencia . Pueden llamarse de distinta forma en las distintas tablas aunque se
recomienda que tengan el mismo nombre.
 Conceptos básicos
En la intersección de una fila con una columna sólo puede haber un único valor. Por este
motivo los atributos multievaluados no se representan como tal en la tabla sino que deben
buscarse otras alternativas. (las veremos más adelante).

No se permiten filas duplicadas.

En la definición del esquema de la tabla es indiferente tanto el orden de las filas como el
orden de las columnas.

Se pueden repetir los nombres de atributos en distintas tablas (cuidado con esto porque si
se incluyen FK de otras tablas con el mismo nombre puede haber conflictos).
 Conceptos básicos

En una tabla identificamos dos conceptos:

- Esquema: Contiene el nombre de la tabla y la definición de los campos.
- Extensión: Contiene los datos propiamente dichos.
 Conceptos básicos – Notación Crow's feet

Cero (0,1)

Uno (1,1)

Muchos (0,N)

(1,N)
Conceptos básicos – Notación Crow's feet

NOTACIONES MODELO ER /
RELACIONAL

https://rua.ua.es/dspace/bitstream/
10045/23898/6/T2B-3%20ERnotaci
%C3%B3n.pdf
 Transformación de entidades fuertes y sus atributos
Se crea una nueva tabla cuyo nombre coincidirá con el nombre de la entidad y los
atributos de la misma pasarán a ser los campos de la tabla según las siguientes
consideraciones:

El atributo “clave” de la entidad pasará a ser la clave primaria (PK) de la tabla.

Atributos obligatorios: Se transforman en una columna no admitiendo valores nulos
(not null – NN).
Atributos opcionales: Se transforman en una columna admitiendo valores nulos.
Atributos multivaluados: Se crea una nueva tabla formada con la clave primaria de la
entidad y el atributo multivaluado, siendo ambos clave primaria de la nueva tabla (hay
otras posibilidades).
 Transformación de entidades fuertes y sus atributos
Atributos compuestos: Se transforma en campos simples que componen el atributo
compuesto, desapareciendo este como tal de la tabla.
Atributos derivados: No formaran parte del modelo relacional resultante, quedando
eliminados en esta parte del diseño.
Observamos la entidad EMPLEADO que se
ha transformado en una tabla cuyos campos
son los atributos asociados.
- El atributo clave pasa a ser clave primaria
de la tabla.
- El atributo compuesto “Dirección”
desaparece como campo de la tabla y en su
lugar se incluyen los elementos que lo
componen como campos individuales.
- El atributo “Teléfono” que es
multivaluado, desaparece de la tabla y se
genera una tabla nueva que lo incluye como
un campo además de la PK de la entidad.
Ambos campos forman ahora la PK de la
nueva tabla generada.
 Transformación de entidades débiles y sus atributos
Se crea una nueva tabla cuyo nombre coincidirá con el nombre de la entidad débil y los
atributos de la misma pasarán a ser los campos de la tabla. Además se añadirá un campo
nuevo con la PK de la entidad fuerte de la que depende.

NOTA: Tener en cuenta que la

línea de conexión es continua.
Esto significa que se trata de
una relación identificativa, es
decir, la entidad con
cardinalidad N, sólo se
identifica si se acompaña de
la entidad con cardinalidad 1.
 Transformación de RELACIONES M:N

Teniendo en cuenta que en el modelo relacional sólo se pueden representar tablas, las
relaciones M:N del modelo E/R se convierten en una nueva tabla cuyos campos son las
PK de las entidades relacionadas. En caso de que la relación tuviera atributos propios,
éstos se añadirían como campos en la tabla. La PK de esta nueva tabla es la
concatenación de las PK de las entidades relacionadas, y además son FK.
Nota: En Workbech, sólo es necesario representar las dos entidades relacionadas y
emplear el conector correcto. El aplicativo genera de forma automática la tabla
resultante. Luego puedes editar el nombre o lo que se requiera.
 Transformación de RELACIONES 1:N

CASO 1:1 La entidad con cardinalidad (1,1) se

convierte en una tabla con sus
atributos y su PK (PK1)

La entidad con cardinalidad (1,N) se

convierte en una tabla con sus
atributos y su PK (PK2) y además se
le añade un campo con la PK de la
entidad (1,1). En este caso PK1. Esta
clave pasa a ser sólo clave foránea
(FK) de la entidad 2 (no forma parte
de la PK). En esta tabla se añadirían
los atributos de la relación.
El esquema representa la
transformación.
 Transformación de RELACIONES 1:N
CASO 1:1
EXCEPCIONES

Casos en los que

puede interesar
crear una nueva
tabla para la
relación
 Transformación de RELACIONES 1:N
CASO 1:1
EXCEPCIONES

1) Cuando el número de ocurrencias de la entidad que propaga la clave es muy pequeño y cabe la
posibilidad de que al propagar la clave quedan muchos valores repetidos o nulos.

2) Cuando se prevea que en el futuro se puede convertir en una relación N:M

3) Cuando la relación tenga atributos propios. En algunos casos se pueden migrar estos atributos junto
con la clave pero, en general, se crea una nueva tabla.
 Transformación de RELACIONES 1:N
Las entidades se transforman
CASO 0:1
en tablas con sus atributos
como campos y sus claves
primarias. La relación se
transforma también en otra
tabla cuyos campos son las PK
(que actuarían de FK) de
ambas entidades más los
atributos que tuviera la
relación.
La PK de esta tabla es la PK
de la entidad con cardinalidad
N.
 Transformación de RELACIONES 1:1
Se crea una tabla por cada entidad y sus
CASO (1,1) (1,1) campos son los atributos asociados
incluyendo sus PK correspondientes.
Además la PK de una de las tablas debe
pasar como PK de la otra. Da igual qué clave
pasa (puede pasar la PK1 a la tabla de la
entidad 2; o PK2 a la tabla de la entidad 1).
En ambos casos la clave migrada es sólo una
FK (no forma parte de la clave primaria de la
tabla).
 Transformación de RELACIONES 1:1
Se crea una tabla por cada entidad
CASO (1,1) (0,1) y sus campos son los atributos
asociados incluyendo sus PK
correspondientes.
Además la PK con cardinalidad
(1,1) migra como FK a la tabla con
cardinalidad (0,1) pero no forma
parte de la clave primaria.
Si la relación tuviera atributos se
añadirían a la tabla con
cardinalidad (0,1)
 Transformación de RELACIONES 1:1
Se crea una tabla por cada entidad
CASO (0,1) (0,1) y sus campos son los atributos
asociados incluyendo sus PK
correspondientes.
Además se crea una nueva tabla
correspondiente a la relación cuyos
campos son las PK de las
entidades asociadas. La clave
primaria de esta tabla es la
concatenación de las PK de cada
entidad (que a su vez son FK). Si
la relación tuviera atributos se
incluirían en la tabla.
 Transformación de relaciones REFLEXIVAS
La transformación de las relaciones reflexivas se realiza de la misma forma que el resto de
relaciones teniendo en cuenta sus cardinalidades. Lo que ocurre es que en lugar de tener dos
entidades relacionadas, sólo tenemos una y por tanto sólo habrá una tabla en lo que respecta a la
entidad. Eso significa que las FK harán referencia a la PK de la propia tabla.

Para una mejor comprensión ten en cuenta el siguiente esquema:

Ejemplo trasformación relación reflexiva 1:N, caso (1,1)
Si tenemos en cuenta la teoría explicada
respecto a estos casos, tenemos que a la
entidad con cardinalidad (1,N) se le añade
como FK la PK con cardinalidad (1,1). Al
ser una relación reflexiva, la entidad
EMPLEADO tiene las dos cardinalidades,
por tanto, se añade un campo que llamamos
ID_jefe, que hace referencia al ID de la
misma tabla (puede contener valores nulos)
Ejemplo de transformación reflexiva 1:1, caso (0,1)(1,1)

Igual que en el caso

anterior, la tabla tiene
ambas cardinalidades y
por tanto se añade un
nuevo campo llamado
Id_alquiler_anterior, que
es FK de la propia tabla y
que hace referencia al ID
de la tabla. Puede contener
valores nulos.
Ejemplo transformación relación reflexiva M:N
Se crea una nueva tabla con la PK de la
entidad y nuevamente se añade otro
campo que también forma parte de la PK
de la tabla
 Transformación relación ternaria N:M:P
ESTUDIANTE (est, ...)

ASIGNATURA (asig, ...)

SEMESTRE (sem, ...)

EVALUACIÓN-SEMESTRAL (est, asig, sem, nota)

donde {est} referencia ESTUDIANTE,

{asig} referencia ASIGNATURA
y {sem} referencia SEMESTRE

La PK de la tabla EVALUACIÓN-SEMESTRAL es la combinación de las tres FK

 Transformación relación ternaria 1:1:1
Esta interrelación registra información de
defensas de proyectos de fin de carrera.
Intervienen en ella el estudiante que presenta el
proyecto, el proyecto presentado y el tribunal
evaluador.
La transformación del ejemplo anterior se
muestra a continuación:

Cuando la conectividad de la interrelación

es 1:1:1, la relación que se obtiene de su
transformación tiene como clave
TRIBUNAL (trib, ...) primaria los atributos que forman la
ESTUDIANTE (est, ...)
PROYECTO-FIN-CARRERA (pro, ...) clave primaria de dos entidades
cualesquiera de las tres
interrelacionadas.
 Transformación relación ternaria 1:1:1

DEFENSA (trib, est, pro, fecha-defensa)

donde {trib} referencia TRIBUNAL,
{est} referencia ESTUDIANTE
y {pro} referencia PROYECTO-FIN-CARRERA

En este caso se ha elegido como PK trib, est, pero podían haberse elegido las combinaciones (trib,
pro) o (est, pro)
 Transformación relación ternaria 1:1:N
Se crea una nueva tabla para la relación que
tiene como PK los atributos que forman la PK
de la entidad del lado N y los atributos que
forman la PK de cualquiera de las dos entidades
que están conectadas con 1.

HORA-SEMANAL (código-hora, ...)

AULA (código-aula, ...)
ASIGNATURA (asig, ...)
La nueva tabla tiene todas las PK de las CLASE (código-hora, código-aula, asig, duración)
Entidades relacionadas, pero la PK propia de la
tabla sólo es la combinación de la entidad con
{código-hora} referencia HORA-SEMANAL,
cardinalidad N y cualquiera de las otras dos {código-aula} referencia AULA
(En este caso código_aula) y {asig} referencia ASIGNATURA
Transformación relación ternaria 1:1:N

Se crea una nueva tabla para la relación

que tiene como PK todos los atributos
que forman las claves primarias de las
dos entidades de los lados de la
interrelación con cardinalidad M y N.
Al igual que en los casos anteriores,
debe también incluirse en la nueva tabla
la PK de cardinalidad 1, aunque no
forme parte de la clave primaria de esta
nueva tabla.
 Generalización y Especialización (Relaciones ISA)
Existen varias soluciones para realizar el paso a tablas de una especialización. La solución que
se elija en cada caso dependerá del tipo de especialización que estemos resolviendo: total,
parcial, inclusiva o exclusiva.

Las 3 soluciones posibles que podemos aplicar son las siguientes:

Crear una tabla para cada una de las entidades, tanto para la superclase como las subclases.
En este caso las subclases tendrían que guardar la clave de la primaria de la superclase.

Crear una tabla sólo para las subclases. En este caso los atributos de la superclase habría que
guardarlos en cada una de las subclases.

Crear una única tabla para la superclase. En este caso todos los atributos de las subclases se
guardarían en la superclase.
 RESTRICCIONES SEMÁNTICAS
RESTRICCIÓN DE CLAVE PRINCIPAL (PRIMARY KEY : PK)
Esta restricción (además de marcar los datos identificativos de una tabla) prohíbe que las columnas
que forman la clave primaria puedan contener valores repetidos en distintas filas o que queden
vacías (nulos) en alguna fila. Es decir, el contenido de las claves primarias es único y distinto de
nulo.

RESTRICCIÓN UNIQUE
Impide que los valores de los campos marcados como UNIQUE, puedan repetirse en
distintas filas. Es decir, en esa columna los valores deben ser distintos para cada fila.
Además se permite un solo valor NULL. No es necesario marcar como UNIQUE un
campo que sea PK ya que inherentemente, una PK es UNIQUE.
Si tenemos una columna donde ya hemos insertado valores duplicados y queremos
modificarlo añadiendo la restricción UNIQUE, el SGBD indicará un error y no aplicará tal
modificación.
 RESTRICCIONES SEMÁNTICAS
OBLIGATORIEDAD: NOT NULL

Esta restricción prohíbe que el campo macado quede vacío sin ningún valor.

INTEGRIDAD REFERENCIAL: FOREING KEY (FK)

Las claves externas o secundarias es el mecanismo del modelo relacional para poder
asociar datos de diferentes tablas.
Implica que las columnas marcadas como FK no puedan contener valores que no se
puedan relacionar con el campo asociado de la tabla que relacionan; aunque si pueden
contener valores nulos (a no ser que el campo referenciado sea PK).
 RESTRICCIONES SEMÁNTICAS
POLÍTICAS DE ACTUALIZACIÓN Y ELIMINACIÓN

La restricción de integridad referencial causa problemas en las operaciones de borrado y

modificación de registros, ya que si se ejecutan esas operaciones sobre la tabla principal
quedarán filas en la tabla secundaria con el campo FK haciendo referencia a un valor que
ya no existe, y eso la propia restricción no lo permite.
Para solventar esta situación se utilizan políticas especiales al crear la restricción ene l
campo FK.
 RESTRICCIONES SEMÁNTICAS
POLÍTICAS DE ACTUALIZACIÓN Y ELIMINACIÓN

Prohibir la operación (NO ACTION). Esto no permitiría hacer en las claves principales
ninguna operación si hay claves secundarias relacionadas con ellas. Suele ser la opción por
defecto. Es muy rígida.

Transmitir la operación en cascada (CASCADE). Es decir si se modifica o borra un

registro, también se modificarán o borrarán los registros relacionados con él.

Colocar nulos (SET NULL). Si modificamos o borramos un registro, los registros

relacionados se marcarán como nulo.
 RESTRICCIONES SEMÁNTICAS
POLÍTICAS DE ACTUALIZACIÓN Y ELIMINACIÓN

Usar el valor por defecto (DEFAULT). Se coloca un valor por defecto en las claves
externas relacionadas cuando se borre o modifique la clave principal relacionada. Este
valor por defecto se indica al crear la tabla (opción default).

No todas las bases de datos admiten todas estas posibles políticas a aplicar en operaciones de
actualizar o eliminar. Además, podemos indicar una política al actualizar y otra al eliminar.
Es decir podremos, por ejemplo, indicar nulos ante cambios en las claves principales y actuar en
cascada ante eliminaciones en las claves.
 RESTRICCIONES SEMÁNTICAS
REGLA DE VALIDACIÓN (CHECK)

Es una restricción que impone una condición lógica que deberá de cumplir una o más
columnas cuando se la añadan o modifiquen los datos. Por ejemplo, podríamos restringir
la columna llamada sueldo para que siempre acepte valores mayores de 1000; no se
permitiría entonces indicar sueldos menores de 1000 en dicha columna.
A veces las reglas implican a varias columnas, como por ejemplo que la fecha de
inicio sea mayor que la fecha final.
 RESTRICCIONES SEMÁNTICAS
DISPARADORES (TRIGGERS)

Son restricciones más complejas, presentes en sistemas avanzados de bases de datos. Se

trata de código almacenado en la base de datos, cuyas instrucciones se ejecutan
automáticamente cuando ocurre un determinado evento (añadir una fila, modificar filas,
iniciar sesión por parte del usuario,...).
Las instrucciones pueden realizar cualquier operación permitida. Por ejemplo, podemos
hacer que ningún usuario pueda añadir datos de 12 de la noche a 5 de la mañana, o que no
podamos añadir una cuenta bancaria si sus dígitos de control no cumplen la compleja regla
que se les aplica.
Los triggers permiten realizar restricciones muy potentes, pero son las restricciones más
complejas de definir ya que implican conocimientos de programación.
 NORMALIZACIÓN
PROCESO DE SIMPLIFICACIÓN Y OPTIMIZACIÓN DE LOS DATOS SIN PERDER
INFORMACIÓN
Los objetivos que se persiguen con la normalización son:
-Emplear el menor espacio posible
-Eliminar la redundancia a la mínima posible (redundancia = repetición de datos)
-Eliminar errores lógicos
-Mantener los datos ordenados

1FN 2FN 3FN FNBC 4FN 5FN

 NORMALIZACIÓN: 1FN
•Todos los atributos son «atómicos». No puede haber más de un valor en un campo.
•La tabla contiene una PK única.
•La PK no contiene atributos nulos.
•No debe existir variación en el número de columnas. Si algunas filas tienen 8
columnas y otras 3, pues no estamos en 1FN.
•Debe Existir una independencia del orden tanto de las filas como de las columnas, es
decir, si los datos cambian de orden no deben cambiar sus significados. Por ejemplo, si en
la columna 1 tenemos el primer apellido y en la columna 2 tenemos el segundo, pues no
estamos en 1FN. Igualmente si en la tercera fila tenemos el tercer mejor expediente y en la
quinta fila el quinto, no estamos en 1FN.
NORMALIZACIÓN: 1FN
 NORMALIZACIÓN: 1FN

Tabla 1: Valores no atómico

Tabla 2: Distinto número de campos en los registros de la misma tabla.
Tabla 3: Grupos de valores repetidos.

La tabla inicial ya estaría en 1FN

 NORMALIZACIÓN: 2FN
Una tabla está en 2FN si está en 1FN y además cumple que los atributos no clave
depende de TODA la clave principal.

En esta tabla la PK es (ID_EMPLEADO,

COD_PROF)
¿El campo PROFESIÓN depende de la PK?
¿Qué modificaciones harías para resolverlo?
NORMALIZACIÓN: 2FN
 NORMALIZACIÓN: 3FN
Una tabla está en 3FN si está en 1FN, también está en 2FN y además cumple que no
existen dependencias transitivas entre los campos que no son PK de la tabla.

Los campos NOMBRE, APELLIDO Y COD_CARGO dependen de la PK

ID_EMPLEADO, pero el campo CARGO depende del campo COD_CARGO.
Por tanto hay una dependencia transitiva.