Tema 34. Bases de Datos Relacionales y Entidad-Relación – Oposición

Publicado2 de enero de 2026

Actualizado10 de enero de 2026

Poroposicion

📚 Análisis del Tema: Bases de Datos Relacionales y Normalización

El tema proporciona una visión completa de las bases de datos relacionales, desde su contexto histórico hasta los elementos del modelo, el diseño conceptual con el Modelo E-R, y la posterior refinación de las tablas mediante la Normalización.

Puntos Importantes del Tema

Modelo Relacional: Se basa en la teoría de conjuntos, utilizando el concepto de relación (tablas) y un álgebra para operar con ellas. E. F. Codd fue su padre intelectual.
Elementos del Modelo Relacional:
- Tabla/Fichero/Relación: Estructura bidimensional con filas y columnas.
- Fila/Tupla/Registro/Entidad: Representa una entidad del mundo real.
- Columna/Campo/Atributo: Representa las características de la entidad.
- Dominio: Conjunto de valores que puede tomar una columna.
Estructura de la Base de Datos: Se divide en el esquema (definición de la estructura, metadatos) y la instancia (los datos en un momento dado).
Manipulación de la Información: Se realiza mediante lenguajes relacionales como el Álgebra Relacional (describe cómo hacer la consulta) y el Cálculo Relacional (indica lo que se desea devolver). El lenguaje más común es SQL.
Sistemas de Gestión de Bases de Datos Relacionales (SGBDR/RDBMS): Software dedicado a tratar con estas bases de datos (ej. MySQL, Oracle, SQL Server).
Normalización: Proceso para garantizar que las tablas estén construidas de acuerdo con especificaciones para que las operaciones relacionales no generen anomalías. [cite_start]Se necesita estar al menos en la Tercera Forma Normal (3FN) para que las operaciones funcionen sin anomalías.

🏗️ Aclaración del Modelo Entidad-Relación y su Utilidad

El Modelo Entidad-Relación (E-R) es la fase de diseño conceptual esencial para crear una base de datos bien estructurada y normalizada.

¿Para qué se necesita el Modelo E-R?

El Modelo E-R permite representar la realidad de la empresa o sistema en forma de objetos básicos (entidades) y sus asociaciones (relaciones). Este diagrama (Diagrama E-R) es un paso intermedio que nos da una «fotografía» de la información antes de traducirla a tablas relacionales.

Su utilidad principal es garantizar un diseño lógico y sin redundancias desde el inicio:

Identificación de Entidades y Atributos: Se define qué objetos son importantes (Entidad = Tabla) y qué información se debe guardar de ellos (Atributo = Campo).
Definición de Claves: Se eligen las Claves Candidatas y la Clave Principal, que identifican unívocamente a cada registro.
Definición de Relaciones y Claves Foráneas: Se definen las asociaciones entre entidades, clasificándolas por Cardinalidad (Uno a Uno, Uno a Muchos, Muchos a Muchos) [cite_start]y Modalidad (Obligatoria u Optativa). [cite_start]Esto determina dónde colocar las Claves Foráneas (claves primarias de otra tabla) para vincular los datos.

📊 Clasificación por Cardinalidad

1. Relación Uno a Uno (1:1)

Ocurre cuando una entidad de tipo A se relaciona únicamente con una entidad de tipo B, y viceversa.

Ejemplo: Un Ciudadano y su DNI. (Un ciudadano solo tiene un DNI y ese DNI pertenece a un solo ciudadano).
En la base de datos: Normalmente se resuelve poniendo la clave primaria de una de las tablas como clave foránea en la otra, o incluso fusionando ambas en una sola tabla si la relación es muy fuerte.

2. Relación Uno a Muchos (1:N)

Es la más común. Una entidad en A puede relacionarse con varias entidades en B, pero una entidad en B solo puede relacionarse con una entidad en A.

Ejemplo: Un Departamento y sus Empleados. (Un departamento tiene muchos empleados, pero cada empleado pertenece a un único departamento).
En la base de datos: Se resuelve siempre llevando la clave primaria del lado «1» a la tabla del lado «N» como clave foránea. En nuestro ejemplo, el ID_Departamento se guarda en la tabla de EMPLEADOS.

3. Relación Muchos a Muchos (N:M)

Ocurre cuando una entidad en A puede relacionarse con muchas entidades en B, y una entidad en B también puede relacionarse con muchas de tipo A.

Ejemplo: Estudiantes y Asignaturas. (Un estudiante se matricula en muchas asignaturas y una asignatura tiene muchos estudiantes).
En la base de datos: NUNCA se puede representar directamente con una clave foránea en las tablas originales. Se requiere crear una Tabla Intermedia (tabla de vinculación) que contenga las claves primarias de ambas tablas como su propia clave compuesta.

💡 Concepto de Modalidad (Participación)

Aunque me has preguntado por la cardinalidad, en los exámenes suelen ir de la mano de la modalidad. La cardinalidad indica el «máximo» de relaciones, y la modalidad indica el «mínimo»:

Modalidad 0 (Opcional): La entidad no tiene por qué estar relacionada obligatoriamente (ej. un Cliente que aún no ha realizado ningún Pedido).
Modalidad 1 (Obligatoria): La entidad debe estar relacionada al menos con una (ej. un Pedido debe tener obligatoriamente un Cliente).

Si el diseño E-R es correcto, la base resultante será muy cercana a la forma normal, minimizando los problemas (redundancia, ambigüedades, anomalías de modificación) que la Normalización busca corregir.

🎯 Normalización hasta Boyce-Codd: Explicación Exhaustiva

La Normalización es un conjunto de reglas que se aplican a las tablas para evitar anomalías (pérdida de información o inconsistencias) al insertar, modificar o eliminar datos. Cada Forma Normal (FN) es un nivel de restricción que se construye sobre la anterior.

Aquí te detallo las primeras formas normales (1FN, 2FN, 3FN) y la Forma Normal de Boyce-Codd (BCFN), y cómo memorizarlas.

Primera Forma Normal (1FN)

Requisito	Clave de Memorización
Una tabla está en 1FN si impide que un atributo tome más de un valor.	Atomicidad (valores indivisibles).

Regla: Los valores de cada columna deben ser atómicos (indivisibles). Además, no debe haber filas duplicadas.

Ejemplo y Solución: Una tabla con un campo Departamento que contiene "Dirección, Gestión" para un solo empleado no está en 1FN, ya que el valor es compuesto (multivaluado).

Solución: Se descompone la fila en dos, de modo que cada departamento ocupa su propia fila:
- DNI: 12345345G, Nombre: Andrea, Departamento: Dirección.
- DNI: 12345345G, Nombre: Andrea, Departamento: Gestión.

Resultado: La tabla es ahora una verdadera relación donde cada intersección de fila y columna contiene un valor único.

Segunda Forma Normal (2FN)

Requisito	Clave de Memorización
Una tabla está en 2FN si está en 1FN y cada atributo que no sea clave, depende de forma funcional completa respecto de cualquiera de las claves.	Dependencia de TODA la Clave Principal.

Regla: Solo aplica si la clave principal es compuesta (formada por varios atributos). Ningún atributo no clave debe depender solo de una parte de la clave principal (esto es una dependencia funcional parcial).

Conceptos de Dependencia:

[Dependencia Funcional (X→Y): Para cada valor de X, solo hay un valor posible para Y.
Dependencia Funcional Completa (X⇒Y): Y depende de X y no se puede conseguir la misma dependencia con un subconjunto más pequeño de X.

Ejemplo y Solución: En una tabla con clave principal compuesta (DNI, Cod_Curso):

Nota depende de (DNI, Cod_Curso) (dependencia completa).
[Nombre y Apellido1 dependen solo de DNI (dependencia parcial).
Solución: Se separa la dependencia parcial en una nueva tabla:
- Tabla ALUMNOS (2FN): DNI (Clave), Nombre, Apellido1.
- Tabla ASISTENCIA (2FN): DNI, Cod_Curso (Clave Compuesta), Nota.

Resultado: Se elimina la redundancia de Nombre y Apellido al repetirse el DNI en la tabla original, resolviendo las anomalías de modificación (por ejemplo, si se actualiza el nombre del alumno, solo se hace una vez en la tabla ALUMNOS).

Tercera Forma Normal (3FN)

Requisito	Clave de Memorización
Una tabla está en 3FN si está en 2FN y ningún atributo que no sea clave depende transitivamente de las claves de la tabla.	No hay dependencias transitivas.

Regla: Un atributo no clave no debe depender funcionalmente de otro atributo no clave. [cite_start]Esto se llama dependencia funcional transitiva.

Concepto de Dependencia Transitiva (X→→Z): Si X→Y y Y→Z, pero no ocurre Y→X, entonces Z depende transitivamente de X.

Ejemplo y Solución: En una tabla ALUMNOS con clave principal DNI:

Provincia depende de Cod_Provincia.
Cod_Provincia es un atributo no clave.
Por lo tanto, DNI → Cod_Provincia (no clave) → Provincia (no clave) → Dependencia Transitiva.
Solución: Se separa la dependencia transitiva en una nueva tabla:
- Tabla ALUMNOS (3FN): DNI (Clave), Nombre, Apellido1, Cod_Provincia (Clave Foránea).
- Tabla PROVINCIA (3FN): Cod_Provincia (Clave), Provincia.

Resultado: Se elimina la redundancia de los nombres de provincia (ej. «Palencia» se repite menos veces), resolviendo la anomalía de modificación (si cambia el nombre de la provincia, solo se modifica una vez en la tabla PROVINCIA).

Forma Normal de Boyce-Codd (BCFN o FNBC)

Requisito	Clave de Memorización
Una tabla está en BCFN si está en 3FN y todo determinante es una clave candidata.	Todo Determinante es una Clave Candidata.

Regla: Es una forma más estricta de la 3FN y se aplica cuando la tabla tiene múltiples claves candidatas que se solapan. Un determinante es el conjunto de atributos del que depende funcionalmente otro atributo (la parte izquierda de la flecha en X→Y).

Ejemplo y Solución: En la tabla TUTORÍAS con clave principal (DNI, Asignatura):

Existe la dependencia funcional: (DNI, Asignatura) → Tutor. (La clave determina al tutor).
Existe otra dependencia: Tutor → Asignatura. (Cada tutor enseña una única asignatura) .

Aquí, Tutor es un determinante, pero no es una clave candidata (varios DNI pueden tener el mismo tutor). Por lo tanto, no está en BCFN.

Solución: Se descompone la tabla para aislar la dependencia.

Tabla TUTORÍAS (BCFN): DNI, Tutor (Clave Compuesta: DNI, Tutor).
Tabla ASIGNATURASTUTOR (BCFN): Tutor, Asignatura (Clave: Tutor).

Resultado: Se elimina la redundancia de la asignatura, que se repetía para cada alumno del mismo tutor, evitando la anomalía donde una mala selección de clave genera datos repetidos

🔑 Ejemplo Clarificador de Boyce-Codd (BCFN)

Consideremos una tabla que registra la relación entre Alumnos, el Tutor asignado, y el Departamento al que pertenece ese tutor.

Alumno	Tutor	Departamento
Ana	Eva	Matemáticas
Juan	Eva	Matemáticas
Sara	Pedro	Lengua
Miguel	Pedro	Lengua

1. Claves y Dependencias

Asumimos las siguientes reglas de negocio y, por lo tanto, las siguientes dependencias funcionales:

Regla A: Un Alumno tiene asignado un único Tutor.
- Alumno→Tutor
Regla B: Cada Tutor trabaja para un único Departamento.
- Tutor→Departamento

A. Identificación de Claves Candidatas

Para identificar unívocamente una fila, solo se necesita saber quién es el Alumno. Si sabes que es «Ana», sabes que su Tutor es «Eva» y su Departamento es «Matemáticas».

Clave Candidata (CC): {Alumno}

B. Identificación de Determinantes

Los Determinantes son los conjuntos de atributos que están en el lado izquierdo de cualquier dependencia funcional.

Dependencia: Alumno→Tutor
- Determinante 1: {Alumno}
Dependencia: Tutor→Departamento
- Determinante 2: {Tutor}

2. Evaluación de Formas Normales

¿Está en 3FN?

Sí, la tabla está en 3FN, porque:

Está en 2FN (la clave es simple, {Alumno}, por lo que no hay dependencias parciales).
No hay dependencia transitiva: Tutor y Departamento no son clave, y la dependencia Tutor→Departamento no involucra a la clave Alumno a través de otro atributo no clave.

¿Está en BCFN?

Aquí es donde falla. La regla de BCFN dice que todo determinante debe ser una clave candidata.

Determinante 1 (Alumno): Es una Clave Candidata. → ¡Cumple!
Determinante 2 (Tutor): NO es una Clave Candidata (varios alumnos, Ana y Juan, pueden tener el mismo tutor). → ¡VIOLA BCFN!

3. El Problema (Anomalía)

El hecho de que el Determinante {Tutor} no sea una clave candidata genera una anomalía de redundancia y actualización.

Redundancia: Repetimos el hecho de que «Eva está en el departamento de Matemáticas» una vez por cada alumno que tiene Eva.
Anomalía de Actualización: Si el tutor Eva cambia del departamento de Matemáticas a Física, tendríamos que actualizar dos filas (Ana y Juan). Si olvidamos actualizar la fila de Juan, la base de datos queda inconsistente.

4. La Solución (Descomposición)

Para alcanzar BCFN, la tabla debe descomponerse para aislar la dependencia problemática (Tutor→Departamento).

Tabla 1: ASIGNACIÓN (Mantiene la relación Alumno-Tutor)
- PK: Alumno
- FK: Tutor | Alumno | Tutor | | :—: | :—: | | Ana | Eva | | Juan | Eva | | Sara | Pedro | | Miguel | Pedro |
Tabla 2: TUTORES_DEP (Aísla la dependencia problemática)
- PK: Tutor (que ahora es una clave candidata y el único determinante) | Tutor | Departamento | | :—: | :—: | | Eva | Matemáticas | | Pedro | Lengua |

Conclusión: En la tabla original, Tutor→Departamento era una dependencia entre atributos, donde Tutor era el determinante, pero no era la clave de la tabla. BCFN fuerza a que esta dependencia se separe en su propia tabla, donde el determinante (Tutor) se convierte en la Clave Principal.

4️⃣ Cuarta y 5️⃣ Quinta Forma Normal: Uso y Utilidad en la Realidad

En la práctica, existe un consenso en la industria que la meta principal y el estándar de calidad para la mayoría de las aplicaciones transaccionales (OLTP) es la Tercera Forma Normal (3FN), o como máximo, la Forma Normal de Boyce-Codd (BCFN).

1. Cuarta Forma Normal (4FN)

La 4FN se enfoca en eliminar las Dependencias Multivaluadas (DMV) no triviales.

Aspecto	Evaluación
Dificultad de Implementación:	Media. Una vez que se detecta la DMV, la descomposición es sencilla. La dificultad principal es detectar la DMV en el diseño inicial, ya que es una restricción lógica más compleja que las dependencias funcionales.
Utilidad Práctica:	Muy útil. Aunque la DMV es menos común que la dependencia transitiva (3FN), cuando ocurre, genera una redundancia masiva y muy costosa. Si tu diseño E-R incluye entidades con múltiples atributos multivaluados independientes (como en el ejemplo de `Nº Curso`, `Profesor`, `Material` ), aplicar 4FN es crucial para evitar que la información se repita exponencialmente.
Uso en la Realidad:	Frecuente en sistemas complejos donde una entidad tiene varias propiedades que pueden tener múltiples valores de forma independiente. Si pasas por la Normalización de Boyce-Codd, y la base de datos sigue teniendo redundancia sin una dependencia funcional clara, debes revisar la 4FN.

2. Quinta Forma Normal (5FN)

La 5FN se enfoca en resolver las Dependencias de Reunión (Join Dependencies), que surgen de restricciones de negocio muy específicas.

Aspecto	Evaluación
Dificultad de Implementación:	Alta. Es la forma más compleja y polémica. Implica descomponer la tabla en tres o más componentes (por ejemplo, tres pares de atributos: (A, B), (B, C), (A, C)) y asegurar que, al reunirlas, se obtiene la tabla original sin perder información.
Utilidad Práctica:	Raramente útil. El tema indica que es raro encontrarse con este tipo de problemas cuando la normalización llega a 4FN.Solo es necesaria cuando existe una restricción de negocio tripartita (como la del ejemplo de `Proveedor`, `Material`, `Proyecto`) que dicta cómo deben relacionarse los tres elementos, forzando la redundancia.
Uso en la Realidad:	Muy raro. Se considera un ejercicio principalmente académico. Los diseñadores profesionales se detienen en 3FN o BCFN, y solo revisan la 5FN si el modelo es excepcionalmente complejo y hay una sospecha muy clara de que la información se está repitiendo debido a una dependencia de reunión no detectada.

🟢 Conclusión para Oposiciones

Nivel de Importancia	Formas Normales	Justificación
Alto (Esencial)	1FN, 2FN, 3FN	Son el estándar industrial. Entender la eliminación de atomicidad, dependencias parciales y dependencias transitivas es obligatorio.
Medio (Avanzado)	BCFN	Es la verdadera prueba de un diseño limpio. Debes entender cómo se diferencia de 3FN al analizar todos los determinantes y no solo los atributos no clave.
Bajo (Teórico)	4FN, 5FN	Son el límite teórico. Debes conocer sus nombres, definiciones (DMV y dependencia de reunión) y saber que son raramente implementadas en la práctica.

Para tu estudio, concéntrate en dominar la detección de anomalías hasta BCFN, y ten claro que la 4FN y 5FN son extensiones para casos extremos de redundancia.

❌ No, una tabla no puede alcanzar la Cuarta Forma Normal (4FN) si no cumple primero con la Forma Normal de Boyce-Codd (BCFN).

La jerarquía de las Formas Normales es estrictamente acumulativa y creciente en cuanto a restricciones.

La Jerarquía Estricta

Para que una tabla esté en 4FN, debe cumplir las siguientes condiciones:

Estar en 1FN.
Estar en 2FN.
Estar en 3FN.
Estar en BCFN.
Estar en 4FN (es decir, no tener dependencias multivaluadas no triviales).

El diagrama de normalización lo muestra claramente: el camino para llegar a 4FN siempre pasa por BCNF (a menudo se coloca BCNF entre 3FN y 4FN en el flujo de normalización).

¿Por qué BCFN es un requisito para 4FN?

La razón es simple: BCNF es una forma normal más estricta y rigurosa que 3FN.

3FN solo prohíbe las dependencias funcionales transitivas (dependencia de un atributo no clave sobre otro atributo no clave).
BCNF prohíbe TODAS las dependencias funcionales donde el determinante (la parte que determina el valor) no sea una clave candidata.

Si una tabla está en 3FN pero no en BCNF, significa que aún contiene anomalías de actualización y redundancia causadas por dependencias funcionales mal definidas.

Si una tabla aún tiene problemas de dependencia funcional (fallando BCFN), no tiene sentido verificar dependencias multivaluadas (4FN), que son un problema estructural más avanzado.

Al igual que no puedes verificar la 3FN sin cumplir la 2FN, no puedes verificar la 4FN sin cumplir la BCNF. El objetivo es corregir primero las anomalías más básicas (1FN, 2FN, 3FN) y luego las más complejas (BCNF, 4FN, 5FN).

Resumen de Normalización (1FN a 5FN)

Forma Normal	¿Qué elimina o corrige?	Clave para el examen
1FN	Grupos repetitivos y valores no atómicos.	Atomicidad: Cada celda, un solo dato.
2FN	Dependencias funcionales parciales.	Clave Completa: Todo depende de toda la clave.
3FN	Dependencias transitivas.	Directo: No hay puentes entre atributos no clave.
BCFN	Determinantes que no son claves candidatas.	Determinante = Clave Candidata.
4FN	Dependencias multivaluadas (DMV).	Independencia: Aísla hechos independientes.
5FN	Dependencias de reunión (Join).	Recomposición: No se puede dividir más.