BBDD Curso 2021-2022

El modelo relacional
El objetivo principal del modelo relacional es proteger al usuario de la obligación de conocer las
estructuras de datos físicas con las que se representa la información de una base de datos.
Desvincular estas estructuras de datos, que son complejas por naturaleza, del diseño lógico
(Modelo Relacional), permite que la base de datos se pueda implementar en cualquier gestor
de bases de datos relacional (Oracle, MySQL, DB2, etc.)

Las características fundamentales del modelo relacional:

• La relación es el elemento fundamental del modelo. Los usuarios ven la base de datos
como una colección de relaciones. Estas relaciones se pueden operar /mediante el
Algebra Relacional.
• El modelo relacional es independiente de la forma en que se almacenan los datos y de
la forma de representarlos, por tanto, la base de datos se puede implementar en
cualquier SGBD y los datos se pueden gestionar utilizando cualquier aplicación gráfica.
Por ejemplo, se pueden manejar las tablas de una base de datos MySQL u Oracle con
Microsoft Access.
• Al estar fundamentado en una fuerte base matemática, se puede demostrar la eficacia
del modelo a la hora de operar conjuntos de datos

Las relaciones en el modelo relacional

Se define una relación como un conjunto de atributos, cada uno de los cuales pertenece a un
dominio, y que posee un nombre que identifica la relación. Se representa gráficamente por una
tabla con columnas (atributos) y filas (tuplas). El conjunto de tupias de una relación representa
el cuerpo de la relación y el conjunto de atributos y el nombre representan el esquema.

Ejemplo de definición de una relación:

Otros conceptos del modelo relacional

Definición de algunos conceptos necesarios para transformar el modelo conceptual (diagrama
entidad-relación) en el modelo lógico (modelo relacional).

Atributo: Características que describen a una entidad o relación.

Dominio: Conjunto de valores permitidos para un atributo. Por ejemplo, cadenas de caracteres,
números enteros, los valores Sí o No, etc.

Restricciones de semántica: Condiciones que deben cumplir los datos para su correcto
almacenamiento. Hay varios tipos:

Restricciones de clave: Es el conjunto de atributos que identifican de forma única a una entidad.

Restricciones de valor único (UNIQUE): Es una restricción que impide que un atributo tenga un
valor repetido. Todos los atributos clave cumplen esta restricción. No obstante, es posible que
BBDD Curso 2021-2022

algún atributo no sea clave y requiera una restricción de valor único. Por ejemplo, el número de
bastidor de un vehículo no es clave (lo es la matrícula) y sin embargo, no puede haber ningún
número de bastidor repetido.

Restricciones de integridad referencial: Se da cuando una tabla tiene una referencia a algún valor
de otra tabla. En este caso la restricción exige que exista el valor referenciado en la otra tabla.
Por ejemplo, no se puede poner una nota a un alumno que no exista.

Restricciones de dominio: Esta restricción exige que el valor que puede tomar un campo esté
dentro del dominio definido. Por ejemplo, si se establece que un campo DNI pertenece al
dominio de los números de 9 dígitos + 1 letra, no es posible insertar un DNI sin letra, puesto que
la restricción obliga a poner al menos 1 letra.

Restricciones de verificación (CHECK): Esta restricción permite comprobar si un valor de un

atributo es válido conforme a una expresión.

Restricción de valor NULO (NULL o NOT NULL): Un atributo puede ser obligatorio si no admite el
valor NULO o NULL, es decir, el valor falta de información o desconocimiento. Si admite como
valor el valor NULL, el atributo es opcional.

Disparadores o triggers: Son procedimientos que se ejecutan para hacer una tarea concreta en
el momento de insertar, modificar o eliminar información de una tabla.

Restricciones genéricas adicionales o aserciones (ASSERT). Permite validar cualquiera de los

atributos de una o varias tablas.

Clave: Una clave es un conjunto de atributos que identifican de forma única una ocurrencia de
entidad. En este caso, las claves pueden ser simples (atómicas) o compuestas. Además, hay
varios tipos de clave:

Superclave: Identifican a una entidad (pueden ser no mínimas). Por ejemplo, para un empleado,
las superclaves posibles son el DNI, o el DNI+Nombre, o el DNH+Nombre+Numero de la
Seguridad Social, etc

Clave Candidata: Es la mínima Superclave (en el caso anterior el DNI, o el Número de la seguridad
social).

Clave Primaria: Es la clave candidata elegida por el diseñador como clave definitiva (en el
ejemplo anterior se elegiría el DNI por ser la más representativa para un empleado).

Clave foránea: Es un atributo de una entidad, que es clave en otra entidad. Por ejemplo, la nota
en un módulo de una asignatura corresponde a un DNI, que es clave de otra entidad. En este
caso el DNI es una clave foránea en la tabla notas.
BBDD Curso 2021-2022

Transformación de un diagrama E/R al modelo relacional

Vamos a partir de un ejemplo:

Nota:

Al pasar del esquema E/R al esquema Relacional deberemos añadir las claves foráneas
necesarias para establecer las interrelaciones entre las tablas. Dichas claves foráneas no
aparecen representadas en el esquema E/R.

1. Entidades

Cada entidad se transforma en una tabla. El identificador (o identificadores) de la entidad pasa

a ser la clave principal de la relación y aparece subrayada o con la indicación: PK (Primary Key).
Si hay clave alternativa esta se pone en «negrita».

Ejemplo: Todas las entidades del ejemplo anterior generan tabla. En concreto, la entidad AULA
genera la siguiente tabla:
BBDD Curso 2021-2022

2. Relaciones binarias (de grado 2)

Relaciones N:M: Es el caso más sencillo. Siempre generan tabla. Se crea una tabla que incorpora
como claves ajenas o foráneas FK (Foreign Key) cada una de las claves de las entidades que
participan en la relación. La clave principal de esta nueva tabla está compuesta por dichos
campos. Es importante resaltar que no se trata de 2 claves primarias, sino de una clave primaria
compuesta por 2 campos. Si hay atributos propios, pasan a la tabla de la relación. Se haría
exactamente igual si hubiera participaciones mínimas 0. Orden de los atributos en las claves
compuestas: Se deben poner a la izquierda todos los atributos que forman la clave. El orden de
los atributos que forman la clave vendrá determinado por las consultas que se vayan a realizar.
Las tuplas de la tabla suelen estar ordenadas siguiendo como índice la clave. Por tanto, conviene
poner primero aquellos atributos por los que se va a realizar la consulta.

Ejemplo: Realicemos el paso a tablas de la relación N:M entre MÓDULO (1,n) y ALUMNO (1,n).
Este tipo de relación siempre genera tabla y los atributos de la relación, pasan a la tabla que ésta
genera.

Relaciones 1:N: Por lo general no generan tabla.

Se dan 2 casos:

• Caso 1: Si la entidad del lado «1» presenta participación (0,1), entonces se crea una
nueva tabla para la relación que incorpora como claves ajenas las claves de ambas
entidades. La clave principal de la relación será sólo la clave de la entidad del lado «N».

Ejemplo: Realicemos el paso a tablas de la relación 1:N entre PROFESOR (1,n) y EMPRESA (0,1).
Como en el lado «1» encontramos participación mínima 0, se generará una nueva tabla.

• Caso 2: Para el resto de las situaciones, la entidad del lado «N» recibe como clave ajena

la clave de la entidad del lado «1». Los atributos propios de la relación pasan a la tabla
donde se ha incorporado la clave ajena.
BBDD Curso 2021-2022

Ejemplo: Realicemos el paso a tablas de la relación 1:N entre MÓDULO (1,1) y TEMA (1,n). Como
no hay participación mínima «0» en el lado 1, no genera tabla y la clave principal del lado «1»
pasa como foránea al lado «n».

Relaciones 1:1: Por lo general no generan tabla.

Se dan 3 casos:

• Caso 1: Si las dos entidades participan con participación (0,1), entonces se crea una
nueva tabla para la relación.

Ejemplo: No se presenta ninguna situación así en el esquema estudiado. Una situación donde
puede darse este caso es en HOMBRE (0,1) se casa con MUJER (0,1). Es similar al caso 1 del
apartado anterior en relaciones 1:N, aunque en este caso debemos establecer una restricción
de valor único para FK2.

• Caso 2: Si alguna entidad, pero no las dos, participa con participación mínima 0 (0,1),
entonces se pone la clave ajena en dicha entidad, para evitar en lo posible, los valores
nulos.
• Caso 3: Si tenemos una relación 1:1 y ninguna tiene participación mínima 0, elegimos la
clave principal de una de ellas y la introducimos como clave clave ajena en la otra tabla.
Se elegirá una u otra forma en función de cómo se quiera organizar la información para
facilitar las consultas. Los atributos propios de la relación pasan a la tabla donde se
introduce la clave ajena.
BBDD Curso 2021-2022

Otros ejemplos:
BBDD Curso 2021-2022

3. Relaciones de dependencia (Siempre de grado 2 y cardinalidad 1:N)

Relaciones de dependencia en existencia: Se comportan como una 1:N normal. La clave

principal del lado 1 pasa al lado «N» como foránea (hacia donde apunta la flecha)

Ejemplo: No encontramos ningún ejemplo, reseñado como tal, en el supuesto anterior. Ahora
bien, se comportan en el paso a tablas como cualquier otra relación 1:N. Sólo se tendría en
cuenta, el hecho de ser débil en existencia para en el momento de creación de la BD, imponer
que al borrar una ocurrencia en el lado «1», se borren las asociadas en el lado «n».

Relaciones de dependencia en identificación: Por lo general no generan tablas, porque suelen

ser 1:1 o 1:N. Como en toda relación 1:N, la clave de la entidad fuerte debe introducirse en la
tabla de la entidad débil como foránea y, además en este caso, formar parte de la clave de ésta.
En las entidades débiles, la clave de la entidad fuerte debe ir la primera y, a continuación, los
discriminadores de la débil.

Ejemplo: Realicemos el paso a tablas de la relación débil en identificación entre CURSO Y GRUPO.

4. Relaciones de grado mayor que 2

Relaciones n-arias (solo veremos hasta grado 3): Siempre generan tabla. Las claves principales
de las entidades que participan en la relación pasan a la nueva tabla como claves foráneas. Y
solo las de los lados «n» forman la principal. Si hay atributos propios de la relación, estos se
incluyen en esa tabla.

Ejemplo: No encontramos ningún ejemplo de relación de más de grado 2 en el supuesto anterior.

5. Relaciones reflexivas

Relaciones Reflexivas o Recursivas: Generan tabla o no en función de la cardinalidad. Si es 1:1,

no genera tabla. En la entidad se introduce dos veces la clave, una como clave principal y otra
como clave ajena. Se suele introducir una modificación en el nombre por diferenciarlas. Si es
1:N, se puede generar tabla o no. Si hubiese participación 0 en el lado 1, obligatoriamente se
generaría tabla. Si es N:N, la relación genera tabla.

Ejemplo: Realicemos el paso a tablas de la relación reflexiva de ALUMNO. Como no tiene

participación mínima «0» en el lado 1, no genera tabla. La clave principal de ALUMNOS, volverá
a aparecer en ALUMNOS como clave foránea, igual que en cualquier relación 1:N. Ahora bien,
como no puede haber dos campos con el mismo nombre en la misma tabla, deberemos cambiar
un poco el nombre de la clave principal, para que haga referencia al papel que ocupa como clave
foránea.
BBDD Curso 2021-2022

6. Jerarquías

Eliminación de las relaciones jerárquicas: Las relaciones jerárquicas son un caso especial.

Se pueden dar algunas guías que sirvan de referencia, pero en la mayoría de los casos, va a
depender del problema concreto. Estas guías son:

Se creará una tabla para la entidad supertipo. A no ser que tenga tan pocos atributos que dejarla
sea una complicación.

Si la entidad subtipo no tiene atributos y no está relacionada con ninguna otra entidad,
desaparece.

Si la entidad subtipo tiene algún atributo, se crea una tabla. Si no tiene clave propia, hereda la
de la entidad supertipo.

Si la relación es exclusiva, el atributo que genera la jerarquía se incorpora en la tabla de la

entidad supertipo.

Si se ha creado una tabla por cada una de las entidades subtipo, no es necesario incorporar dicho
atributo a la entidad supertipo.

Ejemplo: No encontramos ningún ejemplo de relación de jerarquía 2 en el supuesto anterior.

BBDD Curso 2021-2022

NORMALIZACIÓN
El diseño de una BD relacional se puede realizar aplicando al mundo real, en una primera fase,
un modelo como el modelo E/R, a fin de obtener un esquema conceptual; en una segunda fase,
se transforma dicho esquema al modelo relacional mediante las correspondientes reglas de
transformación. También es posible, aunque quizás menos recomendable, obtener el esquema
relacional sin realizar ese paso intermedio que es el esquema conceptual. En ambos casos, es
conveniente (obligatorio en el modelo relacional directo) aplicar un conjunto de reglas,
conocidas como Teoría de normalización, que nos permiten asegurar que un esquema relacional
cumple unas ciertas propiedades, evitando:

La redundancia de los datos: repetición de datos en un sistema.

Anomalías de actualización: inconsistencias de los datos como resultado de datos redundantes

y actualizaciones parciales.

Anomalías de borrado: pérdidas no intencionadas de datos debido a que se han borrado otros
datos.

Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la

ausencia de otros datos.

En la práctica, si la BD se ha diseñado haciendo uso de modelos semánticos como el modelo E/R

no suele ser necesaria la normalización. Por otro lado, si nos proporcionan una base de datos
creada sin realizar un diseño previo, es muy probable que necesitemos normalizar.

En la teoría de bases de datos relacionales, las formas normales (FN) proporcionan los criterios
para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas.
Cuanto más alta sea la forma normal aplicable a una tabla, menos vulnerable será a
inconsistencias y anomalías. Edgar F. Codd originalmente definió las tres primeras formas
normales (1FN, 2FN, y 3FN) en 1970. Estas formas normales se han resumido como requiriendo
que todos los atributos sean atómicos, dependan de la clave completa y en forma directa (no
transitiva). La forma normal de Boyce-Codd (FNBC) fue introducida en 1974 por los dos autores
que aparecen en su denominación. Las cuarta y quinta formas normales (4FN y 5FN) se ocupan
específicamente de la representación de las relaciones muchos a muchos y uno a muchos entre
los atributos y fueron introducidas por Fagin en 1977 y 1979 respectivamente.Cada forma
normal incluye a las anteriores.
BBDD Curso 2021-2022

Antes de dar los conceptos de formas normales veamos unas definiciones previas:

Dependencia funcional: A → B, representa que B es funcionalmente dependiente de A. Para un

valor de A siempre aparece un valor de B. Ejemplo: Si A es el D.N.I., y B el Nombre, está claro
que para un número de D.N.I, siempre aparece el mismo nombre de titular.

Dependencia funcional completa: A → B, si B depende de A en su totalidad. Ejemplo: Tiene

sentido plantearse este tipo de dependencia cuando A está compuesto por más de un atributo.
Por ejemplo, supongamos que A corresponde al atributo compuesto: D.N.I._Empleado +
Cod._Dpto. y B es Nombre_Dpto. En este caso B depende del Cod_Dpto., pero no del
D.N.I._Empleado. Por tanto no habría dependencia funcional completa.

Dependencia transitiva: A→B→C. Si A→B y B→C, Entonces decimos que C depende de forma
transitiva de A. Ejemplo: Sea A el D.N.I. de un alumno, B la localidad en la que vive y C la
provincia. Es un caso de dependencia transitiva A→ B → C.

Determinante funcional: todo atributo, o conjunto de ellos, de los que depende algún otro
atributo. Ejemplo: El D.N.I. es un determinante funcional pues atributos como nombre,
dirección, localidad, etc, dependen de él.

Dependencia multivaluada: A→→B. Son un tipo de dependencias en las que un determinante

funcional no implica un único valor, sino un conjunto de ellos. Un valor de A siempre implica
varios valores de B. Ejemplo: CursoBachillerato →→ Modalidad. Para primer curso siempre va a
aparecer en el campo Modalidad uno de los siguientes valores: Ciencias, Humanidades/Ciencias
Sociales o Artes. Igual para segundo curso.

Primera Forma Normal: 1FN

Una Relación está en 1FN si y sólo si cada atributo es atómico.

Ejemplo: Supongamos que tenemos la siguiente tabla con datos de alumnado de un centro de
enseñanza secundaria.

Como se puede observar, esta tabla no está en 1FN puesto que el campo Teléfonos contiene
varios datos dentro de una misma celda y por tanto no es un campo cuyos valores sean atómicos.
La solución sería la siguiente:
BBDD Curso 2021-2022

Segunda Forma Normal: 2FN

Una Relación está en 2FN si y sólo si está en 1FN y todos los atributos que no forman parte de
la Clave Principal tienen dependencia funcional completa de ella.

Ejemplo: Seguimos con el ejemplo anterior. Trabajaremos con la siguiente tabla:

Vamos a examinar las dependencias funcionales. El gráfico que las representa es el siguiente:

Siempre que aparece un DNI aparecerá el Nombre correspondiente y la LocalidadAlumno

correspondiente. Por tanto, DNI → Nombre y DNI → LocalidadAlumno. Por otro lado, siempre
que aparece un Curso aparecerá el Tutor correspondiente. Por tanto, Curso → Tutor. Los
atributos Nombre y LocalidadAlumno no dependen funcionalmente de Curso, y el atributo Tutor
no depende funcionalmente de DNI.

El único atributo que sí depende de forma completa de la clave compuesta DNI y Curso es
FechaMatrícula: (DNI,Curso) → FechaMatrícula.
BBDD Curso 2021-2022

A la hora de establecer la Clave Primaria de una tabla debemos escoger un atributo o conjunto
de ellos de los que dependan funcionalmente el resto de los atributos. Además, debe ser una
dependencia funcional completa. Si escogemos DNI como clave primaria, tenemos un atributo
(Tutor) que no depende funcionalmente de él. Si escogemos Curso como clave primaria,
tenemos otros atributos que no dependen de él.

Si escogemos la combinación (DNI, Curso) como clave primaria, entonces sí tenemos todo el
resto de los atributos con dependencia funcional respecto a esta clave. Pero es una dependencia
parcial, no total (salvo FechaMatrícula, donde sí existe dependencia completa). Por tanto, esta
tabla no está en 2FN. La solución sería la siguiente:

Tercera Forma Normal: 3FN

Una Relación está en 3FN si y sólo si está en 2FN y no existen dependencias transitivas. Todas
las dependencias funcionales deben ser respecto a la clave principal.

Ejemplo: Seguimos con el ejemplo anterior. Trabajaremos con la siguiente tabla:

BBDD Curso 2021-2022

Las dependencias funcionales existentes son las siguientes. Como podemos observar existe una
dependencia funcional transitiva: DNI → Localidad → Provincia

Para que la tabla esté en 3FN, no pueden existir dependencias funcionales transitivas. Para
solucionar el problema deberemos crear una nueva tabla. El resultado es:
BBDD Curso 2021-2022

Forma Normal de Boyce-Codd: FNBC

Una Relación está en FNBC si está en 3FN y no existe solapamiento de claves candidatas.
Solamente hemos de tener en cuenta esta forma normal cuando tenemos varias claves
candidatas compuestas y existe solapamiento entre ellas. Pocas veces se da este caso.

Ejemplo: Tenemos una tabla con información de proveedores, códigos de piezas y cantidades
de esa pieza que proporcionan los proveedores. Cada proveedor tiene un nombre único. Los
datos son:

El atributo CantidadPiezas tiene dependencia funcional de dos claves candidatas compuestas,

que son:

(NombreProveedor, CodigoPieza)

(CIFProveedor, CódigoPieza)

Existe también una dependencia funcional en doble sentido (que no nos afecta):
NombreProveedor <-> CIFProveedor.

Para esta tabla existe un solapamiento de 2 claves candidatas compuestas. Para evitar el
solapamiento de claves candidatas dividimos la tabla. La solución es:
BBDD Curso 2021-2022

Cuarta Forma Normal: 4FN

Una Relación está en 4FN si y sólo si está en 3FN (o FNBC) y las únicas dependencias
multivaluadas son aquellas que dependen de las claves candidatas.

Ejemplo: Tenemos una tabla con la información de nuestros alumnos y alumnas y las asignaturas
que cursan, así como los deportes que practican.

Para normalizar esta tabla, debemos darnos cuenta de que la oferta de asignaturas está
compuesta por un conjunto de valores limitado. Igual sucede con los deportes. Por tanto, existen
dos dependencias multivaluadas:

• Estudiante →→ Asignatura
• Estudiante →→ Deporte

Por otro lado, no existe ninguna dependencia entre la asignatura cursada y el deporte
practicado. Para normalizar a 4FN creamos 2 tablas:
BBDD Curso 2021-2022

Diagrama E/R equivalente

Quinta Forma Normal: 5FN

La quinta forma normal (5FN), es una generalización de la anterior. También conocida como
forma normal de proyección-unión (PJ/NF). Una tabla se dice que está en 5NF si y sólo si está en
4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas. Ejemplo:
Tenemos una tabla con varios proveedores que nos proporcionan piezas para distintos
proyectos. Asumimos que un Proveedor suministra ciertas Piezas en particular, un Proyecto usa
ciertas Piezas, y un Proyecto es suplido por ciertos Proveedores, entonces tenemos las
siguientes dependencias multivaluadas:

• Proveedor →→ Pieza
• Pieza →→ Proyecto
• Proyecto →→ Proveedor

Se puede observar cómo se produce un ciclo:

• Proveedor →→ Pieza →→ Proyecto →→ Proveedor (nuevamente)

BBDD Curso 2021-2022

Descomponemos la tabla en 3 tabla nuevas: Proveedor-Pieza, Pieza-Proyecto, Proyecto-

Proveedor.
BBDD Curso 2021-2022

El producto natural de estas 3 tablas nos da la tabla original. Proveedor-Pieza |x| Pieza-
Proyecto |x| Proyecto-Proveedor = Suministros

Diagrama E/R equivalente