Módulo 24: Normalización

Objetivos del módulo

Reconocer las anomalías de inserción, modificación y borrado y relacionarlas con las dependencias funcionales
Entender el objetivo de la normalización y las dos propiedades que debe tener una buena descomposición: sin pérdida de información y con preservación de dependencias
Comprobar si una descomposición es sin pérdida con el test de dos relaciones y con la matriz de Chase
Dominar las formas normales 1FN, 2FN, 3FN y FNBC, y conocer la 4FN, la 5FN, la 6FN y la FNDC
Aplicar paso a paso los algoritmos de síntesis a 3FN (Bernstein) y de descomposición a FNBC
Decidir cuándo conviene desnormalizar y qué riesgos implica
Relacionar un buen diseño E/R con un esquema normalizado y usar la normalización como herramienta de validación

1. Las anomalías de un mal diseño

1.1 Una tabla “plana” de ventas

Imagina que la empresa del esquema EMPRESA no tuviera una base de datos bien diseñada, sino una única hoja de cálculo exportada a una tabla con una fila por cada producto vendido:

VENTAS_PLANO (pedido_id, fecha_pedido, cliente_id, nombre_cliente, ciudad, producto_id, nombre_producto, cantidad, precio_unitario)

pedido_id	fecha_pedido	cliente_id	nombre_cliente	ciudad	producto_id	nombre_producto	cantidad	precio_unitario
5001	15/01/2025	1001	Talleres Martín S.L.	Valencia	2	Portátil Gaming 16	1	1499,00
5001	15/01/2025	1001	Talleres Martín S.L.	Valencia	6	Ratón inalámbrico	2	19,90
5001	15/01/2025	1001	Talleres Martín S.L.	Valencia	9	Monitor 24 FHD	2	139,00
5002	28/01/2025	1002	Construcciones Levante S.A.	Alicante	4	Torre Oficina i5	10	649,00
5002	28/01/2025	1002	Construcciones Levante S.A.	Alicante	9	Monitor 24 FHD	10	139,00
5002	28/01/2025	1002	Construcciones Levante S.A.	Alicante	8	Pack teclado y ratón	10	34,50
5006	22/03/2025	1001	Talleres Martín S.L.	Valencia	19	Disco SSD 1TB	4	89,90
5006	22/03/2025	1001	Talleres Martín S.L.	Valencia	6	Ratón inalámbrico	4	19,90

(Los datos son los reales de los pedidos 5001, 5002 y 5006 de empresa_datos.sql.)

Sus dependencias funcionales, obtenidas de las reglas de negocio:

F = { pedido_id              → fecha_pedido, cliente_id
      cliente_id             → nombre_cliente, ciudad
      producto_id            → nombre_producto
      pedido_id, producto_id → cantidad, precio_unitario }

La única clave candidata es {pedido_id, producto_id} (son los dos únicos atributos que no aparecen a la derecha y su cierre es todo). Suponemos que un producto aparece como mucho una vez en cada pedido.

1.2 Redundancia

El nombre “Talleres Martín S.L.” aparece cinco veces, la fecha de cada pedido se repite en todas sus líneas y “Ratón inalámbrico”, dos veces. La redundancia, por sí sola, desperdicia espacio; pero lo grave son sus consecuencias.

1.3 Anomalía de inserción

📘 Concepto: Hay una anomalía de inserción (insertion anomaly) cuando no se puede registrar un hecho sin registrar a la vez otro hecho distinto que quizá todavía no existe.

No se puede dar de alta un cliente nuevo (como el 1013 o el 1014 de EMPRESA, que no tienen pedidos) hasta que haga un pedido: pedido_id y producto_id forman la clave y no pueden ser nulos (integridad de entidad).
No se puede dar de alta un producto que aún no se ha vendido (como el 14).
Al insertar una línea de un pedido existente hay que repetir los datos del pedido y del cliente, con riesgo de escribirlos mal.

1.4 Anomalía de modificación

📘 Concepto: Hay una anomalía de modificación (update anomaly) cuando un mismo hecho está almacenado en varias filas y, al modificarlo, hay que cambiarlas todas; si se cambia solo una parte, la base de datos queda inconsistente.

Si Talleres Martín se traslada a Paterna, hay que actualizar cinco filas. Si un UPDATE olvida alguna, la tabla dirá a la vez que el cliente 1001 está en Valencia y en Paterna. Lo mismo ocurre si se corrige el nombre de un producto.

1.5 Anomalía de borrado

📘 Concepto: Hay una anomalía de borrado (deletion anomaly) cuando, al eliminar un hecho, se pierden involuntariamente otros hechos independientes.

Si se anula el pedido 5002 (el único de Construcciones Levante en la tabla), al borrar sus tres filas desaparece toda la información del cliente 1002. Y si se borra la línea del producto 4, se pierde también que existe la “Torre Oficina i5”.

1.6 Origen común de las anomalías

Anomalía	Causa	DF responsable
No se pueden insertar clientes sin pedidos	Los datos del cliente dependen de una parte de la clave	`pedido_id → cliente_id` (parcial) y `cliente_id → nombre_cliente` (transitiva)
No se pueden insertar productos sin ventas	Los datos del producto dependen de una parte de la clave	`producto_id → nombre_producto` (parcial)
Cambiar la ciudad exige varias actualizaciones	La ciudad depende de un atributo no clave	`cliente_id → ciudad`
Borrar un pedido borra el cliente	Dos hechos independientes en la misma fila	Ídem

⚠️ Importante: Todas las anomalías tienen la misma raíz: hay DF cuyo determinante no es superclave de la tabla. La normalización consiste en descomponer la tabla para que eso no ocurra (o, en 3FN, que solo ocurra en un caso controlado).

2. El objetivo de la normalización

📘 Concepto: La normalización es un proceso formal que, a partir de un esquema de relación y sus dependencias, lo sustituye por un conjunto de esquemas más pequeños (una descomposición) que cumplen una determinada forma normal, es decir, un conjunto de condiciones que garantizan la ausencia de ciertos tipos de redundancia y anomalías.

Una buena descomposición debe cumplir tres requisitos:

Cada relación resultante está en la forma normal deseada (normalmente 3FN o FNBC).
Sin pérdida de información (lossless join): la tabla original se puede reconstruir exactamente reuniendo las nuevas tablas. Es obligatorio.
Con preservación de dependencias (dependency preservation): todas las DF originales se pueden comprobar dentro de alguna de las nuevas tablas, sin necesidad de reunirlas. Es muy deseable.

Breve historia: E. F. Codd definió la 1FN, 2FN y 3FN entre 1970 y 1972; Boyce y Codd, la FNBC en 1974; Ronald Fagin, la 4FN (1977), la 5FN (1979) y la forma normal de dominio-clave (1981); Date, Darwen y Lorentzos, la 6FN (2002), pensando en bases de datos temporales.

Las formas normales están anidadas: cada una exige más que la anterior.

flowchart TB
    subgraph NF1["1FN: valores atómicos"]
        subgraph NF2["2FN: sin dependencias parciales"]
            subgraph NF3["3FN: sin dependencias transitivas"]
                subgraph NFBC["FNBC: todo determinante es superclave"]
                    subgraph NF4["4FN: sin DMV no triviales"]
                        subgraph NF5["5FN: sin DC no implicadas por las claves"]
                            n6["6FN"]
                            dk["FNDC (DKNF)"]
                        end
                    end
                end
            end
        end
    end

💡 Consejo: En la práctica profesional, el objetivo habitual es la 3FN o la FNBC. La 4FN y la 5FN resuelven situaciones menos frecuentes, normalmente fruto de un mal tratamiento de relaciones N:M o ternarias.

3. Descomposición de relaciones

3.1 Definición

📘 Concepto: Una descomposición de R(U) es un conjunto de esquemas {R₁(U₁), …, Rₙ(Uₙ)} tales que U₁ ∪ … ∪ Uₙ = U (no se pierde ningún atributo). Cada extensión rᵢ se obtiene proyectando: rᵢ = πUᵢ.

3.2 Descomposición sin pérdida de información

📘 Concepto: Una descomposición es sin pérdida (lossless, non-additive join) si, para toda extensión válida r de R:

r = πU₁ ⋈ πU₂ ⋈ … ⋈ πUₙ

Siempre se cumple r ⊆ πU₁ ⋈ … ⋈ πUₙ: la reunión nunca “olvida” tuplas. Lo que puede ocurrir es que aparezcan tuplas de más, llamadas tuplas espurias (spurious tuples). Por eso se habla de “pérdida de información” aunque haya más filas: perdemos la capacidad de saber cuáles son las verdaderas.

💻 Ejemplo: Descomponemos mal VENTAS_PLANO en:

V1 (pedido_id, fecha_pedido, cliente_id)

V2 (cliente_id, nombre_cliente, ciudad, producto_id, nombre_producto, cantidad, precio_unitario)

Para el cliente 1001, V1 tiene los pedidos 5001 y 5006, y V2 tiene cinco filas de productos (tres del 5001 y dos del 5006). Al reunir por cliente_id, cada pedido se combina con los cinco productos:

pedido_id	cliente_id	producto_id	cantidad	¿Real?
5001	1001	2	1	Sí
5001	1001	6	2	Sí
5001	1001	9	2	Sí
5001	1001	19	4	No (espuria)
5001	1001	6	4	No (espuria)
5006	1001	2	1	No (espuria)
…	…	…	…	…

Ya no sabemos qué se compró en cada pedido. La descomposición correcta une por pedido_id: V1 (pedido_id, fecha_pedido, cliente_id) y V2’ (pedido_id, producto_id, …).

3.3 Test de dos relaciones (teorema de Heath)

📘 Concepto: Una descomposición de R en dos relaciones R₁ y R₂ es sin pérdida si y solo si se cumple alguna de estas DF (pertenecen a F⁺):

(R₁ ∩ R₂) → (R₁ − R₂) o bien (R₁ ∩ R₂) → (R₂ − R₁)

Es decir, los atributos comunes son superclave de al menos una de las dos relaciones.

La intuición es clara: si los atributos comunes identifican a las filas de una de las dos tablas, cada fila de la otra “encaja” con una sola fila, y no se generan combinaciones falsas.

Aplicado al ejemplo:

Descomposición	R₁ ∩ R₂	¿Es superclave de alguna?	Resultado
V1, V2	cliente_id	cliente_id⁺ = {cliente_id, nombre_cliente, ciudad}: no contiene pedido_id ni producto_id	Con pérdida
V1, V2’	pedido_id	pedido_id⁺ ⊇ {fecha_pedido, cliente_id} = V1 − V2’	Sin pérdida

💡 Consejo: Una consecuencia práctica: si descompones R usando una DF X → Y en R₁(X ∪ Y) y R₂(U − Y), la descomposición siempre es sin pérdida, porque R₁ ∩ R₂ = X y X → Y = R₁ − R₂. Todos los algoritmos de normalización descomponen así.

3.4 Test de la matriz (algoritmo de Chase)

Para descomposiciones en más de dos relaciones se usa la matriz o tableau (chase test):

1. Construir una matriz con una fila por cada Rᵢ y una columna por cada atributo Aⱼ de U.
2. Celda (i, j) = aⱼ  si Aⱼ ∈ Rᵢ   (símbolo "distinguido")
                 bᵢⱼ si Aⱼ ∉ Rᵢ   (símbolo "no distinguido")
3. Repetir hasta que no haya cambios:
     para cada DF X → Y de F:
         para cada par de filas que coinciden en todas las columnas de X:
             igualar sus valores en las columnas de Y:
               si uno de ellos es un aⱼ, ambos pasan a aⱼ;
               si no, ambos toman uno de los bᵢⱼ (por ejemplo el de menor fila).
             (el cambio se propaga a todas las apariciones del símbolo sustituido en esa columna)
4. La descomposición es SIN PÉRDIDA si y solo si alguna fila queda entera con símbolos a.

💻 Ejemplo: R(A, B, C, D, E) con F = { A → C, B → D, CD → E }. ¿Es sin pérdida la descomposición {R₁(A, C), R₂(B, D), R₃(A, B, E)}?

Matriz inicial:

	A	B	C	D	E
R₁ (AC)	a₁	b₁₂	a₃	b₁₄	b₁₅
R₂ (BD)	b₂₁	a₂	b₂₃	a₄	b₂₅
R₃ (ABE)	a₁	a₂	b₃₃	b₃₄	a₅

A → C: las filas 1 y 3 coinciden en A (a₁). En C tienen a₃ y b₃₃: la fila 3 pasa a a₃.
B → D: las filas 2 y 3 coinciden en B (a₂). En D tienen a₄ y b₃₄: la fila 3 pasa a a₄.
CD → E: ninguna pareja coincide a la vez en C y D. Sin más cambios.

	A	B	C	D	E
R₁ (AC)	a₁	b₁₂	a₃	b₁₄	b₁₅
R₂ (BD)	b₂₁	a₂	b₂₃	a₄	b₂₅
R₃ (ABE)	a₁	a₂	a₃	a₄	a₅

La fila 3 es entera de símbolos a: la descomposición es sin pérdida.

En cambio, con {R₁(A, C), R₂(B, D), R₃(C, D, E)} la fila 3 empieza como (b₃₁, b₃₂, a₃, a₄, a₅); ninguna pareja de filas coincide en A, en B ni en (C, D), así que no cambia nada y ninguna fila queda completa: con pérdida. Tiene sentido: no hay ningún atributo que “enlace” A con B.

💡 Consejo: Interpretación de la matriz: cada fila representa una tupla de la reunión; los símbolos a son los valores de una tupla t “objetivo”. Si las DF obligan a que alguna fila coincida con t en todo, t estaba realmente en la relación original y no es espuria.

3.5 Preservación de dependencias

📘 Concepto: La proyección de F sobre Rᵢ, F[Rᵢ], es el conjunto de DF de F⁺ cuyos atributos están todos en Rᵢ. Una descomposición preserva las dependencias si (F[R₁] ∪ … ∪ F[Rₙ])⁺ = F⁺: toda DF original puede deducirse de DF que se comprueban dentro de una sola tabla.

¿Por qué importa? Una DF que no se preserva solo puede comprobarse reuniendo tablas en cada inserción o modificación. Un SGBD comprueba de forma eficiente las claves (PRIMARY KEY, UNIQUE) dentro de una tabla; una restricción que abarca varias tablas exige mecanismos más costosos y propensos a errores (en Oracle, normalmente disparadores, que se estudian en el Curso de Oracle PL/SQL).

Para comprobar si una DF X → Y se preserva no hace falta calcular F⁺. Basta este algoritmo:

resultado ← X
repetir
    para cada Rᵢ de la descomposición:
        t ← ((resultado ∩ Rᵢ)⁺ calculado con F) ∩ Rᵢ
        resultado ← resultado ∪ t
hasta que resultado no cambie
X → Y se preserva  si y solo si  Y ⊆ resultado

💻 Ejemplo: R(A, B, C, D) con F = { A → B, B → C, C → D, D → A } y la descomposición {AB, BC, CD}. A primera vista, D → A “se ha perdido” porque D y A no están juntos en ninguna tabla. Comprobémoslo:

Iteración	Rᵢ	(resultado ∩ Rᵢ)⁺ ∩ Rᵢ	resultado
0			D
1	AB	∅	D
1	BC	∅	D
1	CD	D⁺ = ABCD → ∩ CD = CD	CD
2	AB	∅	CD
2	BC	C⁺ ∩ BC = BC	BCD
3	AB	B⁺ ∩ AB = AB	ABCD

A ∈ resultado: D → A se preserva. La razón es que las proyecciones contienen también B → A, C → B y D → C (todas en F⁺ por el ciclo), y D → C → B → A.

3.6 Relación entre las dos propiedades

Objetivo	¿Siempre alcanzable?
3FN + sin pérdida + preservación	Sí (algoritmo de síntesis, sección 11.1)
FNBC + sin pérdida	Sí (algoritmo de descomposición, sección 11.2)
FNBC + sin pérdida + preservación	No siempre (ejemplo en la sección 7)
4FN + sin pérdida	Sí

4. Primera forma normal (1FN)

4.1 Definición

📘 Concepto: Una relación está en primera forma normal (1FN) si todos sus atributos toman valores atómicos (indivisibles desde el punto de vista del SGBD) y monovaluados: en cada celda hay un solo valor del dominio, no una lista, un conjunto ni una tabla anidada. Por definición, toda relación del modelo relacional está en 1FN; la 1FN es lo que distingue una relación de una tabla cualquiera.

Violaciones típicas de la 1FN:

Atributos multivaluados: una celda telefonos = '600111111, 961222333'.
Grupos repetitivos (repeating groups): columnas asignatura1, nota1, asignatura2, nota2, asignatura3, nota3.
Atributos compuestos que se quieren consultar por partes guardados como un único texto (direccion = 'C/ Mayor 5, 46001, Valencia' cuando se necesita filtrar por código postal).

⚠️ Importante: La atomicidad es relativa al uso. Una fecha es atómica aunque tenga día, mes y año, porque el SGBD sabe extraerlos. Un nombre completo en una sola columna es atómico si nunca se necesita ordenar por apellido; si se necesita, conviene separarlo. La pregunta clave es: ¿necesitará la aplicación acceder a una parte del valor por separado?

4.2 Cómo pasar a 1FN

Partimos de esta tabla de una academia (no está en 1FN):

dni	nombre	telefonos	curso1	nota1	curso2	nota2
11111111A	Ana Ruiz	600111111, 961222333	SQL1	8,5	PY1	7
22222222B	Luis Pérez	600222222	SQL1	6

Hay tres alternativas:

Alternativa	Resultado	Valoración
A. Nueva tabla por cada grupo (recomendada)	ALUMNOS(dni, nombre), TELEFONOS(dni, telefono), NOTAS(dni, curso, nota)	Correcta: sin límite de teléfonos ni cursos, sin nulos, y ya normalizada
B. Aplanar repitiendo filas	Una fila por cada combinación teléfono × curso	Está en 1FN, pero con mucha redundancia (y mezcla dos multivaluados independientes: viola la 4FN)
C. Columnas fijas	telefono1, telefono2	Límite artificial, nulos y consultas complicadas (`WHERE telefono1 = x OR telefono2 = x`)

Con la alternativa A:

ALUMNOS (dni, nombre)

TELEFONOS_ALUMNO (*dni*, telefono) con dni → ALUMNOS(dni)

NOTAS (*dni*, cod_curso, nota) con dni → ALUMNOS(dni)

Es exactamente lo que harías con un atributo multivaluado en la transformación E/R → relacional (módulo 17).

💡 Consejo: Oracle permite tipos colección (VARRAY, tablas anidadas) y columnas JSON, que rompen deliberadamente la 1FN (modelo objeto-relacional). Tienen usos legítimos, pero en este curso los evitaremos: complican las consultas, las restricciones y la normalización.

5. Segunda forma normal (2FN)

5.1 Definición

📘 Concepto: Una relación está en segunda forma normal (2FN) si está en 1FN y todo atributo no primo depende de forma plena de cada clave candidata. Dicho de otro modo: no existe ninguna DF X → A con A no primo y X subconjunto propio de una clave candidata.

Recuerda: un atributo es primo si forma parte de alguna clave candidata. La 2FN no dice nada de los atributos primos.

⚠️ Importante: Si todas las claves candidatas tienen un único atributo, la relación está automáticamente en 2FN: no existen subconjuntos propios no vacíos de la clave. El problema de la 2FN solo aparece con claves compuestas.

5.2 Ejemplo: VENTAS_PLANO no está en 2FN

Clave: {pedido_id, producto_id}. Atributos no primos: todos los demás. Dependencias parciales:

pedido_id → fecha_pedido, cliente_id (y, transitivamente, nombre_cliente, ciudad).
producto_id → nombre_producto.

Solo cantidad y precio_unitario dependen plenamente de la clave.

5.3 Cómo pasar a 2FN

Para cada dependencia parcial X → Y (X parte de la clave), se crea una relación con X y todos los atributos que dependen de X (incluidos los que dependen de él transitivamente), y se eliminan esos atributos de la relación original:

PEDIDOS_2 (pedido_id, fecha_pedido, cliente_id, nombre_cliente, ciudad)

PRODUCTOS_2 (producto_id, nombre_producto)

LINEAS_2 (*pedido_id*, *producto_id*, cantidad, precio_unitario)

Cada descomposición se hace con una DF (X → Y), así que es sin pérdida (sección 3.3). Ya se puede insertar un producto sin ventas. Pero en PEDIDOS_2 sigue habiendo un problema: el nombre y la ciudad del cliente se repiten en todos sus pedidos.

6. Tercera forma normal (3FN)

6.1 Definición de Codd

📘 Concepto: Una relación está en tercera forma normal (3FN) si está en 2FN y ningún atributo no primo depende transitivamente de una clave candidata.

6.2 Definición de Zaniolo (equivalente y más práctica)

📘 Concepto: Una relación R está en 3FN si, para toda DF no trivial X → A de F⁺ con A un único atributo, se cumple al menos una de estas condiciones:

X es superclave de R, o

A es un atributo primo.

Esta definición (Carlo Zaniolo, 1982) tiene dos ventajas: no necesita comprobar antes la 2FN (la implica) y se aplica DF a DF. Para comprobarla basta revisar las DF de un recubrimiento mínimo (o de F con lados derechos simples), siempre que se hayan proyectado correctamente sobre R.

Equivalencia con la de Codd: una DF X → A con A no primo y X no superclave es, o bien parcial (si X es parte de una clave), o bien transitiva (si X no es parte de ninguna clave: clave → X → A). Prohibir ambas cosas es exactamente pedir 2FN y ausencia de transitivas.

💡 Consejo: Una regla mnemotécnica clásica en inglés: cada atributo no clave debe depender “of the key, the whole key, and nothing but the key” (de la clave, de toda la clave y de nada más que la clave). “La clave” es la 1FN (existe una clave), “toda la clave” es la 2FN y “nada más que la clave” es la 3FN.

6.3 Ejemplo: PEDIDOS_2 no está en 3FN

En PEDIDOS_2, cliente_id → nombre_cliente, ciudad, con cliente_id no superclave y nombre_cliente, ciudad no primos. Es la dependencia transitiva pedido_id → cliente_id → nombre_cliente.

6.4 Cómo pasar a 3FN

Para cada DF transitiva Y → Z (Y no superclave, Z no primo) se crea una relación (Y, Z) y se elimina Z de la original, dejando Y como clave ajena:

CLIENTES (cliente_id, nombre_cliente, ciudad)

PEDIDOS (pedido_id, fecha_pedido, cliente_id)

cliente_id → CLIENTES(cliente_id)

PRODUCTOS (producto_id, nombre_producto)

LINEAS_PEDIDO (*pedido_id*, *producto_id*, cantidad, precio_unitario)

pedido_id → PEDIDOS(pedido_id)
producto_id → PRODUCTOS(producto_id)

¡Es exactamente la estructura del esquema EMPRESA! (que además usa num_linea como parte de la clave de lineas_pedido, para permitir que un producto aparezca en dos líneas de un mismo pedido).

flowchart LR
    LINEAS_PEDIDO["LINEAS_PEDIDO"] -->|pedido_id| PEDIDOS["PEDIDOS"]
    LINEAS_PEDIDO -->|producto_id| PRODUCTOS["PRODUCTOS"]
    PEDIDOS -->|cliente_id| CLIENTES["CLIENTES"]

Comprobación de las anomalías:

Anomalía original	¿Resuelta?
Insertar un cliente sin pedidos	Sí: es una fila de CLIENTES
Insertar un producto sin ventas	Sí: es una fila de PRODUCTOS
Cambiar la ciudad de un cliente	Sí: se cambia una sola fila
Borrar el único pedido de un cliente	Sí: el cliente sigue en CLIENTES

⚠️ Importante: ¿Y precio_unitario? No depende de producto_id, porque el precio de venta se congela en cada línea y el de catálogo puede cambiar. Por eso se queda en LINEAS_PEDIDO, y PRODUCTOS tiene su propio precio (el actual). Confundir “precio de catálogo” con “precio de venta” es un error de diseño muy común.

7. Forma normal de Boyce-Codd (FNBC)

7.1 Definición

📘 Concepto: Una relación R está en forma normal de Boyce-Codd (FNBC, Boyce-Codd normal form, BCNF) si, para toda DF no trivial X → Y de F⁺, X es superclave de R. En palabras: todo determinante es superclave.

Es la 3FN de Zaniolo sin la excepción “o A es primo”. Por tanto, FNBC ⟹ 3FN, pero no al revés. La diferencia solo puede aparecer cuando una DF tiene como implicado un atributo primo, lo que exige que haya varias claves candidatas compuestas que se solapan (comparten algún atributo).

💡 Consejo: Si una relación está en 3FN y no tiene claves candidatas compuestas solapadas (por ejemplo, si tiene una sola clave candidata), está también en FNBC. Por eso en la mayoría de los diseños 3FN y FNBC coinciden.

7.2 El ejemplo clásico: 3FN pero no FNBC

En un centro de idiomas:

Cada profesor imparte un único idioma.
Un idioma lo imparten varios profesores.
Cada alumno, para cada idioma que estudia, tiene un único profesor.

CLASES (alumno, idioma, profesor) con F = { alumno, idioma → profesor; profesor → idioma }.

alumno	idioma	profesor
Ana	Inglés	Smith
Ana	Francés	Dupont
Luis	Inglés	Smith
Eva	Inglés	Brown
Eva	Francés	Dupont

Claves candidatas: alumno nunca está a la derecha; (alumno, idioma)⁺ = todo y (alumno, profesor)⁺ = (alumno, profesor, idioma) = todo. Claves: {alumno, idioma} y {alumno, profesor}. Todos los atributos son primos.

3FN: sí. En profesor → idioma, profesor no es superclave, pero idioma es primo.
FNBC: no. profesor → idioma y profesor no es superclave.

Anomalías que quedan: “Smith imparte Inglés” está repetido por cada alumno de Smith; no se puede registrar que un profesor nuevo imparte Alemán hasta que tenga un alumno; si Luis se da de baja y era el único alumno de un profesor, se pierde qué idioma imparte ese profesor.

7.3 Pasar a FNBC y perder una dependencia

Descomponemos por la DF que viola la FNBC, profesor → idioma:

PROFESORES (profesor, idioma)

ALUMNO_PROFESOR (alumno, *profesor*)

Sin pérdida: la intersección es profesor y profesor → idioma. ✔
Ambas en FNBC. ✔
¿Preserva alumno, idioma → profesor? En PROFESORES solo vale profesor → idioma; en ALUMNO_PROFESOR no hay DF no triviales. Con el algoritmo: resultado = {alumno, idioma} → con PROFESORES, (idioma)⁺ ∩ {profesor, idioma} = {idioma}; con ALUMNO_PROFESOR, (alumno)⁺ ∩ … = {alumno}. No se llega a profesor. No se preserva. ✘

Consecuencia práctica: nada impide insertar en ALUMNO_PROFESOR las filas (Ana, Smith) y (Ana, Brown), aunque ambos profesores enseñan Inglés y la regla dice que Ana tiene un único profesor de Inglés. Para detectarlo habría que reunir las dos tablas.

⚠️ Importante: Este es el dilema FNBC frente a 3FN: o se acepta un poco de redundancia controlada (3FN, todas las DF comprobables con claves) o se elimina la redundancia a costa de una restricción que requiere un mecanismo adicional (disparador, ver Curso de Oracle PL/SQL). No hay una respuesta universal: depende de qué es más frecuente, las actualizaciones que provocan anomalías o la violación de la regla.

Una tercera vía, muy útil en la práctica, es mantener ambas tablas y la tabla original con una clave ajena compuesta hacia PROFESORES. Lo verás en el ejercicio 4 con los horarios de un instituto.

8. Cuarta forma normal (4FN)

8.1 Definición

📘 Concepto: Una relación R está en cuarta forma normal (4FN) si, para toda dependencia multivaluada no trivial X ↠ Y que se cumple en R, X es superclave de R.

Recuerda (módulo 19) que X ↠ Y es trivial si Y ⊆ X o X ∪ Y = U, y que toda DF es una DMV. Por eso 4FN ⟹ FNBC.

8.2 Ejemplo

En el módulo 19 viste OFERTA_DOCENTE(asignatura, profesor, libro), donde profesores y libros de una asignatura son independientes: asignatura ↠ profesor | libro.

asignatura	profesor	libro
Bases de Datos	Marta Gil	Elmasri
Bases de Datos	Marta Gil	Silberschatz
Bases de Datos	Juan Sanz	Elmasri
Bases de Datos	Juan Sanz	Silberschatz
Programación	Juan Sanz	Deitel

Clave: los tres atributos. No hay DF no triviales: está en FNBC.
asignatura ↠ profesor es no trivial y asignatura no es superclave: no está en 4FN.

Descomposición (teorema de Fagin: R se descompone sin pérdida en R₁(X ∪ Y) y R₂(X ∪ Z) si y solo si X ↠ Y):

ASIGNATURA_PROFESOR (asignatura, profesor)

ASIGNATURA_LIBRO (asignatura, libro)

Ahora añadir un libro a Bases de Datos es una fila, no una por profesor.

💡 Consejo: Las violaciones de la 4FN casi siempre proceden de haber juntado en una tabla dos atributos multivaluados independientes de la misma entidad, o dos relaciones N:M independientes. Si en el E/R los modelaste como dos relaciones binarias distintas, la transformación ya te habrá dado tablas en 4FN.

9. Quinta forma normal (5FN o FNPC)

9.1 Definición

📘 Concepto: Una relación R está en quinta forma normal (5FN), también llamada forma normal de proyección-combinación (FNPC, project-join normal form, PJ/NF), si toda dependencia de combinación no trivial *(R₁, …, Rₙ) que se cumple en R está implicada por las claves candidatas de R.

Una DC es trivial si alguna Rᵢ es todo R. “Implicada por las claves” significa, intuitivamente, que cada Rᵢ contiene una clave de R (descomponer así es inofensivo).

9.2 Ejemplo: agentes, empresas y productos

Una agencia comercial tiene esta regla de negocio, llamada restricción cíclica:

Si un agente representa a una empresa, y el agente vende un tipo de producto, y la empresa fabrica ese tipo de producto, entonces el agente vende ese producto de esa empresa.

agente	empresa	producto
Ana	Electrix	tostadora
Ana	Hogarsa	aspiradora
Luis	Electrix	aspiradora
Ana	Electrix	aspiradora

La cuarta fila está obligada por la regla: Ana representa a Electrix (fila 1), Ana vende aspiradoras (fila 2) y Electrix fabrica aspiradoras (fila 3).

No hay DF no triviales (clave: los tres atributos) ni DMV no triviales (por ejemplo, agente ↠ empresa exigiría la fila (Ana, Hogarsa, tostadora), que no existe). Está en 4FN.
Pero se cumple la DC *({agente, empresa}, {empresa, producto}, {agente, producto}).

Comprobemos que ninguna descomposición en dos proyecciones funciona y que la de tres sí:

Reunión	Tupla espuria que aparece
AE ⋈ EP	(Luis, Electrix, tostadora)
AE ⋈ AP	(Ana, Hogarsa, tostadora)
AP ⋈ EP	(Luis, Hogarsa, aspiradora)
AE ⋈ EP ⋈ AP	Ninguna: se recupera exactamente la tabla original

(AE = π[agente, empresa], EP = π[empresa, producto], AP = π[agente, producto].) Por ejemplo, AE ⋈ EP genera (Luis, Electrix, tostadora), pero al reunir con AP desaparece, porque Luis no vende tostadoras.

Como ninguna de las tres proyecciones contiene una clave de VENTAS (la clave es la terna completa), la DC no está implicada por las claves: no está en 5FN. Solución:

AGENTE_EMPRESA (agente, empresa)

EMPRESA_PRODUCTO (empresa, producto)

AGENTE_PRODUCTO (agente, producto)

Ventaja: si Luis empieza a vender tostadoras, basta insertar (Luis, tostadora) en AGENTE_PRODUCTO; la reunión deducirá automáticamente (Luis, Electrix, tostadora). En la tabla original habría que acordarse de insertar todas las filas que la regla obliga.

⚠️ Importante: La 5FN solo se aplica si la restricción cíclica es una regla de negocio real. Si un agente puede vender aspiradoras de Hogarsa pero no las de Electrix aunque represente a ambas, no hay DC y la tabla de tres columnas (una relación ternaria del E/R) es la correcta. Recuerda los criterios de relaciones ternarias del módulo 13.

10. Sexta forma normal y forma normal de dominio-clave

10.1 Sexta forma normal (6FN)

📘 Concepto: Una relación está en 6FN si no admite ninguna dependencia de combinación no trivial: es irreducible, cada tabla tiene la clave y, como mucho, un atributo más.

Fue propuesta por Date, Darwen y Lorentzos para bases de datos temporales: si cada atributo de un empleado (salario, puesto, departamento) cambia en momentos distintos y hay que guardar su historia, separar cada atributo en su propia tabla con su intervalo de validez evita repetir datos que no han cambiado. Se usa en algunos almacenes de datos (por ejemplo, la técnica anchor modeling), pero no en diseños operacionales habituales.

10.2 Forma normal de dominio-clave (FNDC, DKNF)

📘 Concepto: Una relación está en forma normal de dominio-clave (FNDC, domain-key normal form, DKNF) si toda restricción de la relación es consecuencia lógica de sus restricciones de dominio y de sus restricciones de clave.

Fagin demostró (1981) que una relación en FNDC no tiene anomalías de inserción ni de borrado. Es un ideal teórico: no existe un algoritmo general para alcanzarla, y muchas restricciones reales (por ejemplo, “el salario de un empleado no puede superar el de su jefe”) no se pueden expresar solo con dominios y claves.

11. Algoritmos de normalización

11.1 Síntesis a 3FN (algoritmo de Bernstein)

El algoritmo de síntesis construye el esquema “desde abajo”: agrupa las DF en relaciones. Garantiza 3FN, sin pérdida y con preservación de dependencias.

Entrada:  R(U), F
Salida:   descomposición en 3FN, sin pérdida y con preservación

1. Calcular un recubrimiento mínimo Fm de F (módulo 19).
2. Agrupar las DF de Fm con el mismo lado izquierdo: X → A₁, ..., X → Aₖ.
   Por cada grupo, crear una relación Rᵢ(X, A₁, ..., Aₖ) con clave X.
3. Si ninguna Rᵢ contiene una clave candidata de R,
   añadir una relación cuyo esquema sea una clave candidata de R.
4. Eliminar las relaciones cuyo esquema esté contenido en el de otra.
   (Opcional: fusionar relaciones con claves equivalentes, X ↔ Y.)

El paso 2 asegura la preservación: cada DF de Fm está dentro de una relación.
El paso 3 asegura que es sin pérdida: la relación con la clave “enlaza” todas las demás.
La 3FN se demuestra a partir de que Fm es mínimo.

💻 Ejemplo: R(A, B, C, D, E, G, H) con F = { A → BC, C → D, BD → E, E → C, G → H }.

Paso 1. Recubrimiento mínimo. Descomponiendo: A → B, A → C, C → D, BD → E, E → C, G → H. En BD → E, ¿es B extraño? D⁺ = D. ¿Es D extraño? B⁺ = B. No hay extraños. ¿Redundantes? Ninguna (por ejemplo, A⁺ sin A → C es AB, sin C). Fm = { A → B, A → C, C → D, BD → E, E → C, G → H }.

Paso 2. Agrupar por lado izquierdo:

Grupo	Relación
A → B, A → C	R₁(A, B, C)
C → D	R₂(C, D)
BD → E	R₃(B, D, E)
E → C	R₄(E, C)
G → H	R₅(G, H)

Paso 3. Claves de R: A y G nunca están a la derecha; (AG)⁺ = ABCDEGH = U. Clave única: AG. Ninguna Rᵢ contiene AG: se añade R₆(A, G).

Paso 4. Ningún esquema está contenido en otro.

Resultado: R₁(A, B, C), R₂(C, D), R₃(B, D, E), R₄(E, C), R₅(G, H), R₆(A, G).

Observa R₃(B, D, E): en ella se cumple también E → D (porque E → C → D en F⁺). Sus claves son BD y BE. E → D tiene determinante no superclave, pero D es primo: R₃ está en 3FN pero no en FNBC. La síntesis garantiza 3FN, no FNBC.

11.2 Descomposición a FNBC

El algoritmo de descomposición trabaja “desde arriba”: parte la relación mientras haya una DF que viole la FNBC. Garantiza FNBC y sin pérdida, pero no la preservación de dependencias.

Entrada:  R(U), F
Salida:   descomposición en FNBC sin pérdida

resultado ← { R }
mientras haya una Rᵢ en resultado que no esté en FNBC:
    elegir una DF no trivial X → Y que se cumpla en Rᵢ con X no superclave de Rᵢ
    (conviene tomar Y = (X⁺ ∩ Rᵢ) − X, todo lo que X determina dentro de Rᵢ)
    sustituir Rᵢ por:
        Rᵢ₁ = X ∪ Y
        Rᵢ₂ = Rᵢ − Y
fin mientras

Cada paso descompone por una DF X → Y, luego es sin pérdida (sección 3.3).

⚠️ Importante: Para saber si una sub-relación Rᵢ está en FNBC no basta con mirar las DF de F que caen dentro de Rᵢ: hay que considerar las de F⁺ proyectadas (DF implícitas). Un test seguro: para cada subconjunto X de Rᵢ, calcula X⁺ (con F) ∩ Rᵢ; si contiene algo más que X pero no todo Rᵢ, X viola la FNBC en Rᵢ. Con pocos atributos es rápido.

💻 Ejemplo: R(A, B, C, D, E, G) con F = { AB → C, C → A, BC → D, D → EG }.

Claves: B nunca está a la derecha; E y G solo a la derecha. (AB)⁺ = U, (BC)⁺ = U, (BD)⁺ = BDEG. Claves: AB y BC. DF que violan la FNBC: C → A y D → EG.

Iteración 1. Elegimos D → EG (D⁺ = DEG):

R₁(D, E, G), clave D. En FNBC.
R₂(A, B, C, D).

Iteración 2. En R₂, C → A: C⁺ ∩ R₂ = {A, C}, no es todo R₂. Viola la FNBC.

R₂₁(A, C), clave C. En FNBC.
R₂₂(B, C, D). DF proyectadas: BC → D. ¿Alguna más? B⁺ ∩ BCD = B; C⁺ ∩ BCD = C; D⁺ ∩ BCD = D; (BD)⁺ ∩ BCD = BD; (CD)⁺ ∩ BCD = CD. Solo BC → D, con BC clave: en FNBC.

Resultado: R₁(D, E, G), R₂₁(C, A), R₂₂(B, C, D).

¿Preserva las dependencias? D → EG está en R₁, C → A en R₂₁, BC → D en R₂₂. Pero AB → C se ha perdido: A y B no están juntos en ninguna tabla. (Con el algoritmo: resultado = AB; R₁ no aporta; R₂₁: A⁺ ∩ AC = A; R₂₂: B⁺ ∩ BCD = B. No se llega a C.)

💡 Consejo: El resultado del algoritmo depende del orden en que elijas las DF que violan la FNBC. Si una elección pierde dependencias, prueba otro orden: a veces existe una descomposición FNBC que sí las preserva. Una buena estrategia es empezar por las DF “más bajas” en la cadena (las que no tienen nada que dependa de su implicado), o hacer primero la síntesis 3FN y descomponer después solo las tablas que no estén en FNBC.

12. Tabla resumen de formas normales

Forma normal	Condición	Elimina	Cómo se alcanza
1FN	Valores atómicos y monovaluados	Grupos repetitivos, multivaluados	Nueva tabla por grupo repetitivo
2FN	1FN y ningún no primo depende de parte de una clave	Dependencias parciales	Separar X → Y con X parte de la clave
3FN	Toda DF no trivial X → A: X superclave o A primo	Dependencias transitivas	Separar Y → Z con Y no superclave; síntesis de Bernstein
FNBC	Toda DF no trivial X → Y: X superclave	Determinantes que no son superclave	Algoritmo de descomposición (puede perder DF)
4FN	Toda DMV no trivial X ↠ Y: X superclave	Multivaluados independientes en la misma tabla	Separar (X, Y) y (X, Z)
5FN (FNPC)	Toda DC está implicada por las claves	Restricciones cíclicas	Descomponer en las proyecciones de la DC
6FN	Ninguna DC no trivial	Cualquier descomposición posible	Una tabla por atributo no clave (bases temporales)
FNDC	Toda restricción se deduce de dominios y claves	Todas las anomalías de inserción y borrado	Sin algoritmo general

Propiedad	3FN (síntesis)	FNBC (descomposición)
Sin pérdida	Siempre	Siempre
Preserva DF	Siempre	No siempre
Redundancia por DF	Posible (DF con implicado primo)	Ninguna
Resultado único	No (depende del recubrimiento)	No (depende del orden)

13. Método práctico de normalización

Cuando te den una tabla y te pidan normalizarla, sigue estos pasos:

flowchart TB
    p1["1. Identificar atributos y pasar a 1FN"] --> p2["2. Obtener F de los requisitos"]
    p2 --> p3["3. Calcular el recubrimiento mínimo"]
    p3 --> p4["4. Calcular TODAS las claves candidatas"]
    p4 --> p5{"5. ¿En qué forma normal está?"}
    p5 -->|"No 2FN / no 3FN"| p6["6a. Síntesis 3FN o eliminar parciales y transitivas"]
    p5 -->|"3FN, no FNBC"| p7["6b. Valorar FNBC frente a preservación"]
    p5 -->|"FNBC"| p8["7. Revisar DMV y DC (4FN, 5FN)"]
    p6 --> p7
    p7 --> p8
    p8 --> p9["8. Comprobar sin pérdida y preservación; escribir el esquema con PK, FK y UK"]

💡 Consejo: En un examen, justifica cada paso: qué DF viola qué forma normal y por qué (determinante no superclave, implicado no primo…). La respuesta “está en 2FN” sin justificar vale poco.

14. Desnormalización

14.1 Qué es y por qué se hace

📘 Concepto: La desnormalización es la introducción deliberada y controlada de redundancia en un esquema normalizado, normalmente para mejorar el rendimiento de las consultas a costa de complicar las actualizaciones.

Un esquema muy normalizado obliga a reunir muchas tablas para responder ciertas consultas, y las reuniones (joins) cuestan. Motivos habituales para desnormalizar:

Consultas muy frecuentes que reúnen siempre las mismas tablas (por ejemplo, el listado de pedidos con el nombre del cliente).
Agregados costosos que se consultan mucho y cambian poco (total de un pedido, número de empleados por departamento).
Almacenes de datos (data warehouses) y sistemas analíticos (OLAP): los datos se cargan por lotes y casi nunca se modifican, así que las anomalías de actualización no preocupan. El esquema en estrella (star schema) usa tablas de dimensiones deliberadamente desnormalizadas (por ejemplo, una dimensión PRODUCTO que incluye el nombre de la categoría y de la categoría padre).
Historia y documentos legales: una factura debe conservar la dirección del cliente en el momento de emitirla. Copiarla en la factura no es desnormalizar: es otro dato (la dirección facturada), que depende de num_factura y no de cliente_id.

14.2 Técnicas

Técnica	Ejemplo en EMPRESA	Cómo mantener la coherencia
Duplicar una columna	Copiar `nombre` del cliente en `pedidos`	Disparador (PL/SQL) o proceso por lotes
Columna derivada o agregada	`total` en `pedidos`, calculado de sus líneas	Disparador, o columna virtual si se calcula de la misma fila
Tabla resumen	VENTAS_MENSUALES (mes, producto_id, unidades, importe)	Proceso de carga periódico
Vista materializada	La misma tabla resumen gestionada por Oracle	Refresco automático (módulo 26)
Fusionar tablas 1:1	Unir dos tablas que siempre se consultan juntas	Sin riesgo si la relación es realmente 1:1 total

💡 Consejo: Antes de desnormalizar a mano, considera las alternativas que no rompen el diseño lógico: índices adecuados, vistas (que simplifican las consultas sin duplicar datos) y vistas materializadas (que duplican datos, pero los mantiene el SGBD). Las verás en el módulo 26.

14.3 Riesgos

Reaparecen las anomalías de modificación: si el nombre del cliente está en dos sitios, alguna vez estará distinto.
Las escrituras son más lentas y complejas (hay que actualizar las copias).
El código de mantenimiento (disparadores, procesos) es una fuente de errores.
El esquema es más difícil de entender y evolucionar.

⚠️ Importante: La regla de oro es: primero normaliza, después desnormaliza solo donde una medición demuestre que hace falta, documentando cada redundancia y el mecanismo que la mantiene coherente. Desnormalizar “por si acaso” es un error de diseño, no una optimización.

15. Diseño E/R y normalización

La normalización y el modelo E/R son dos caminos complementarios hacia el mismo objetivo:

Enfoque	Dirección	Punto de partida	Riesgo
E/R + transformación	Descendente (top-down)	Requisitos → entidades y relaciones	Olvidar una entidad o modelar mal una relación
Normalización	Ascendente (bottom-up)	Atributos sueltos + DF	Difícil con muchos atributos; las DF hay que descubrirlas igualmente

📘 Concepto: Si el diagrama E/R es correcto (cada entidad tiene solo sus atributos, cada atributo multivaluado se ha tratado, cada relación tiene la cardinalidad correcta) y se transforma con las reglas del módulo 17, las tablas resultantes suelen estar ya en 3FN o FNBC. La normalización se usa entonces como herramienta de validación: si una tabla no está en 3FN, hay un error en el modelo conceptual.

Correspondencia entre violaciones y errores de modelado:

Síntoma en la tabla	Error en el E/R
No está en 1FN	Atributo multivaluado o compuesto sin tratar
Dependencia parcial	Atributos de una entidad colocados en una relación N:M (por ejemplo, `nombre_alumno` en MATRICULA)
Dependencia transitiva	Entidad oculta: un grupo de atributos que describe otra cosa (CLIENTE dentro de PEDIDO, PROFESOR dentro de CURSO)
No FNBC	Relación con varias claves solapadas; a menudo, una relación ternaria que debería tener una restricción o ser binaria
No 4FN	Dos relaciones N:M independientes fusionadas en una ternaria
No 5FN	Ternaria que en realidad es la combinación de tres binarias con una regla cíclica

💡 Consejo: El flujo profesional es: E/R → transformación → comprobación de la forma normal de cada tabla con sus DF → ajustes. Es exactamente el proceso que seguirás en los casos completos del módulo 21.

16. Ejercicios

Los ejercicios 1 a 14 están resueltos. Los ejercicios 15 a 24 son propuestos.

Ejercicio 1: Factura

Una pequeña empresa guarda sus facturas así (una fila por línea de factura):

FACTURAS_PLANO (num_factura, fecha, nif_cliente, nombre_cliente, direccion_cliente, cod_articulo, descripcion, precio_actual, cantidad, precio_venta, importe, total_factura)

Reglas: cada factura es de un cliente y tiene una fecha; de cada cliente se conoce nombre y dirección; cada artículo tiene descripción y precio actual de catálogo; en cada factura un artículo aparece en una sola línea, con su cantidad y el precio al que se vendió; importe = cantidad × precio_venta y total_factura es la suma de los importes. Normaliza hasta FNBC.

Ver solución

Atributos derivados. importe y total_factura se calculan a partir de otros. Introducen las DF cantidad, precio_venta → importe y num_factura → total_factura, pero lo correcto en el diseño lógico es eliminarlos (se calculan en las consultas o con una vista) y, si hiciera falta por rendimiento, reintroducirlos después como desnormalización controlada.

DF (sin derivados):

num_factura               → fecha, nif_cliente
nif_cliente               → nombre_cliente, direccion_cliente
cod_articulo              → descripcion, precio_actual
num_factura, cod_articulo → cantidad, precio_venta

Clave: num_factura y cod_articulo nunca aparecen a la derecha; su cierre es U. Clave única: {num_factura, cod_articulo}.

Forma normal: 1FN (valores atómicos). No 2FN: num_factura → fecha, nif_cliente y cod_articulo → descripcion, precio_actual son parciales.

2FN: FACTURAS_2(num_factura, fecha, nif_cliente, nombre_cliente, direccion_cliente), ARTICULOS(cod_articulo, descripcion, precio_actual), LINEAS(num_factura, cod_articulo, cantidad, precio_venta).

3FN: en FACTURAS_2, nif_cliente → nombre_cliente, direccion_cliente es transitiva. Se separa CLIENTES.

Esquema final (todas con una sola clave y todos los determinantes son clave: FNBC):

CLIENTES (nif_cliente, nombre_cliente, direccion_cliente)

ARTICULOS (cod_articulo, descripcion, precio_actual)

FACTURAS (num_factura, fecha, nif_cliente)

nif_cliente → CLIENTES(nif_cliente)

LINEAS_FACTURA (*num_factura*, *cod_articulo*, cantidad, precio_venta)

num_factura → FACTURAS(num_factura), cod_articulo → ARTICULOS(cod_articulo)

Matiz legal: una factura emitida no puede cambiar si el cliente se muda. Si se exige conservar la dirección de facturación, se añade direccion_facturada a FACTURAS: depende de num_factura (es un dato histórico de la factura), no de nif_cliente, así que no viola la 3FN.

Ejercicio 2: Matrícula en un ciclo formativo

EXPEDIENTE (nia, nombre_alumno, cod_ciclo, nombre_ciclo, cod_modulo, nombre_modulo, horas, curso_academico, nota, cod_profesor, nombre_profesor)

Reglas: cada alumno está matriculado en un ciclo; cada módulo pertenece a un ciclo y tiene unas horas; un alumno puede cursar un módulo en varios cursos académicos (si repite) y en cada uno obtiene una nota; cada módulo, en cada curso académico, lo imparte un único profesor. Calcula las claves y normaliza a 3FN.

Ver solución

nia                                   → nombre_alumno, cod_ciclo
cod_ciclo                             → nombre_ciclo
cod_modulo                            → nombre_modulo, horas, cod_ciclo
nia, cod_modulo, curso_academico      → nota
cod_modulo, curso_academico           → cod_profesor
cod_profesor                          → nombre_profesor

Clave: nia, cod_modulo y curso_academico no aparecen a la derecha y su cierre es U. Clave única: {nia, cod_modulo, curso_academico}.

Violaciones: parciales nia → ..., cod_modulo → ..., cod_modulo, curso_academico → cod_profesor; transitivas cod_ciclo → nombre_ciclo y cod_profesor → nombre_profesor. Está solo en 1FN.

Síntesis 3FN (el recubrimiento mínimo coincide con F descompuesto):

ALUMNOS (nia, nombre_alumno, cod_ciclo)

CICLOS (cod_ciclo, nombre_ciclo)

MODULOS (cod_modulo, nombre_modulo, horas, cod_ciclo)

IMPARTICIONES (*cod_modulo*, curso_academico, cod_profesor)

PROFESORES (cod_profesor, nombre_profesor)

MATRICULAS (*nia*, *cod_modulo*, curso_academico, nota)

Claves ajenas: ALUMNOS.cod_ciclo y MODULOS.cod_ciclo → CICLOS; IMPARTICIONES.cod_modulo → MODULOS; IMPARTICIONES.cod_profesor → PROFESORES; MATRICULAS.nia → ALUMNOS; MATRICULAS.(cod_modulo, curso_academico) → IMPARTICIONES (un alumno solo se matricula de un módulo que se imparte ese curso).

Todas las tablas tienen una sola clave y todos los determinantes son clave: también están en FNBC. Sin pérdida (la tabla MATRICULAS contiene la clave original) y con preservación.

Restricción entre tablas: “un alumno solo puede cursar módulos de su ciclo” no es una DF de ninguna tabla. Se puede imponer con un truco declarativo: añadir cod_ciclo a MATRICULAS con dos FK compuestas, (nia, cod_ciclo) → ALUMNOS(nia, cod_ciclo) y (cod_modulo, cod_ciclo) → MODULOS(cod_modulo, cod_ciclo), declarando UNIQUE esos pares en las tablas referenciadas. Ojo: un detalle fino es que, al hacer la BCNF “a ciegas” por otro orden, es fácil perder la DF nia → cod_ciclo; la síntesis la conserva.

Ejercicio 3: Préstamos de una biblioteca

Una biblioteca municipal gestionaba los préstamos con esta hoja de cálculo:

num_socio	nombre_socio	telefono	cod_ejemplar	isbn	titulo	autores	editorial	fecha_prestamo	fecha_devolucion
17	Ana Ruiz	600111111	E-0001	978-84-1	Fundamentos de BD	Elmasri, Navathe	Pearson	01/09/2026	15/09/2026
23	Luis Pérez	600222222	E-0002	978-84-1	Fundamentos de BD	Elmasri, Navathe	Pearson	03/09/2026
17	Ana Ruiz	600111111	E-0107	978-84-9	SQL para torpes	Taylor	Anaya	03/09/2026
23	Luis Pérez	600222222	E-0001	978-84-1	Fundamentos de BD	Elmasri, Navathe	Pearson	20/09/2026

Reglas: cada ejemplar es una copia física de un libro (isbn); un ejemplar no se presta dos veces el mismo día; la fecha de devolución es nula mientras no se devuelve. Normaliza.

Ver solución

1FN: autores es multivaluado. Se saca a AUTORIAS(isbn, autor). Si el orden de los autores importa (en las citas, sí), se añade orden: AUTORIAS(isbn, orden, autor). En un diseño más completo, AUTOR sería una entidad con su propio código.

DF del resto:

num_socio                    → nombre_socio, telefono
cod_ejemplar                 → isbn
isbn                         → titulo, editorial
cod_ejemplar, fecha_prestamo → num_socio, fecha_devolucion

Clave: {cod_ejemplar, fecha_prestamo} (no aparecen a la derecha y su cierre es U).

2FN: cod_ejemplar → isbn, titulo, editorial es parcial. 3FN: num_socio → nombre_socio, telefono e isbn → titulo, editorial son transitivas.

Esquema final (FNBC):

SOCIOS (num_socio, nombre_socio, telefono)

LIBROS (isbn, titulo, editorial)

AUTORIAS (*isbn*, orden, autor)

EJEMPLARES (cod_ejemplar, isbn)

PRESTAMOS (*cod_ejemplar*, fecha_prestamo, num_socio, fecha_devolucion)

Observa que el diseño coincide con el que daría el E/R: LIBRO, EJEMPLAR (con su relación 1:N), SOCIO y la relación “presta” entre SOCIO y EJEMPLAR con atributos de fecha. La normalización ha “descubierto” las entidades ocultas.

Ejercicio 4: Horarios de un instituto (3FN frente a FNBC)

Con la tabla HORARIOS(grupo, dia, hora, aula, profesor, asignatura) del ejercicio 9 del módulo 19 (claves: {grupo, dia, hora}, {aula, dia, hora}, {profesor, dia, hora}; DF adicional grupo, asignatura → profesor), determina su forma normal, descomponla en FNBC y valora el resultado.

Ver solución

Forma normal. El único atributo no primo es asignatura, y solo depende de superclaves. La DF grupo, asignatura → profesor tiene un determinante que no es superclave, pero profesor es primo. Por tanto: 3FN sí, FNBC no.

Redundancia: si 1º DAW tiene 5 horas semanales de Bases de Datos con Rosa, “Rosa imparte BD a 1º DAW” se repite 5 veces.

Descomposición FNBC por grupo, asignatura → profesor:

DOCENCIA (grupo, asignatura, profesor)

SESIONES (grupo, dia, hora, aula, asignatura) con UK: (aula, dia, hora)

Sin pérdida (la intersección {grupo, asignatura} es clave de DOCENCIA). En SESIONES las DF proyectadas son grupo, dia, hora → aula, asignatura y aula, dia, hora → grupo, asignatura, ambos determinantes clave: FNBC.

Pérdida: profesor, dia, hora → grupo (un profesor no puede estar en dos grupos a la vez) ya no se puede comprobar en una sola tabla, porque profesor y la franja ya no están juntos. ¡Y es una regla esencial!

Solución práctica (redundancia controlada): mantener la tabla en 3FN, añadiendo DOCENCIA y una FK compuesta:

DOCENCIA (grupo, asignatura, profesor) con UK (grupo, asignatura, profesor)

HORARIOS (grupo, dia, hora, aula, profesor, asignatura) con UK (aula, dia, hora), UK (profesor, dia, hora) y FK (grupo, asignatura, profesor) → DOCENCIA(grupo, asignatura, profesor)

Así, las tres claves de HORARIOS se comprueban con PK/UK y la FK garantiza que el profesor anotado en cada sesión es el que imparte esa asignatura a ese grupo: la redundancia existe, pero el SGBD impide que se vuelva inconsistente. HORARIOS sigue en 3FN (no en FNBC) y no hace falta ningún disparador.

Ejercicio 5: Pasar a 1FN

Convierte a 1FN esta tabla de una autoescuela, explicando las alternativas:

dni	nombre	telefonos	permiso1	fecha1	permiso2	fecha2
11111111A	Ana Ruiz	600111111, 961222333	B	10/05/2020	A2	03/03/2024
22222222B	Luis Pérez	600222222	B	21/06/2025

Ver solución

Hay un atributo multivaluado (telefonos) y un grupo repetitivo (permiso, fecha).

ALUMNOS (dni, nombre)

dni	nombre
11111111A	Ana Ruiz
22222222B	Luis Pérez

TELEFONOS (*dni*, telefono)

dni	telefono
11111111A	600111111
11111111A	961222333
22222222B	600222222

PERMISOS (*dni*, tipo_permiso, fecha_obtencion)

dni	tipo_permiso	fecha_obtencion
11111111A	B	10/05/2020
11111111A	A2	03/03/2024
22222222B	B	21/06/2025

DF: dni → nombre en ALUMNOS; dni, tipo_permiso → fecha_obtencion en PERMISOS. Las tres tablas están en FNBC.

Si en vez de esto aplanáramos en una sola tabla (dni, nombre, telefono, tipo_permiso, fecha), Ana necesitaría 2 × 2 = 4 filas, nombre dependería parcialmente de la clave {dni, telefono, tipo_permiso} y se cumpliría dni ↠ telefono | tipo_permiso, fecha: 1FN, pero ni 2FN ni 4FN.

Ejercicio 6: ¿Sin pérdida?

Sea R(A, B, C, D, E, G) con F = { A → B, C → DE, AC → G }. Comprueba con la matriz de Chase si son sin pérdida: a) {AB, CDE, ACG}; b) {ABC, CDE, CG}.

Ver solución

a) {AB, CDE, ACG}

	A	B	C	D	E	G
AB	a₁	a₂	b₁₃	b₁₄	b₁₅	b₁₆
CDE	b₂₁	b₂₂	a₃	a₄	a₅	b₂₆
ACG	a₁	b₃₂	a₃	b₃₄	b₃₅	a₆

A → B: filas 1 y 3 coinciden en A. La fila 3 pasa a a₂ en B.
C → DE: filas 2 y 3 coinciden en C. La fila 3 pasa a a₄ en D y a₅ en E.
Fila 3: (a₁, a₂, a₃, a₄, a₅, a₆). Sin pérdida.

Además preserva las dependencias: cada DF de F está dentro de una de las tres relaciones.

b) {ABC, CDE, CG}

	A	B	C	D	E	G
ABC	a₁	a₂	a₃	b₁₄	b₁₅	b₁₆
CDE	b₂₁	b₂₂	a₃	a₄	a₅	b₂₆
CG	b₃₁	b₃₂	a₃	b₃₄	b₃₅	a₆

A → B: ninguna pareja coincide en A.
C → DE: las tres filas coinciden en C (a₃): en D todas pasan a a₄ y en E a a₅.
AC → G: ninguna pareja coincide en A y C a la vez.

Resultado: fila 1 = (a₁, a₂, a₃, a₄, a₅, b₁₆), fila 3 = (b₃₁, b₃₂, a₃, a₄, a₅, a₆). Ninguna completa: con pérdida. El problema: G depende de AC, pero la relación CG no lleva A, así que no sabemos qué G corresponde a cada A.

Ejercicio 7: Preservación de dependencias

Para la descomposición {R₁(D, E, G), R₂(A, C), R₃(B, C, D)} de R(A, B, C, D, E, G) con F = { AB → C, C → A, BC → D, D → EG }, comprueba DF a DF si se preservan.

Ver solución

DF	Algoritmo	¿Se preserva?
D → EG	Está dentro de R₁	Sí
C → A	Está dentro de R₂	Sí
BC → D	Está dentro de R₃	Sí
AB → C	resultado = AB; R₁: ∅; R₂: (A)⁺ ∩ AC = A; R₃: (B)⁺ ∩ BCD = B. Sin cambios	No

La descomposición no preserva las dependencias: para garantizar que un par (A, B) determina un único C habría que reunir R₂ y R₃. Es el resultado del algoritmo FNBC de la sección 11.2. Si es importante conservar AB → C, la alternativa es la síntesis 3FN, que da {ABC, BCD, DEG}: la relación ABC (claves AB y BC) conserva AB → C, pero no está en FNBC por C → A (A es primo, así que sí está en 3FN).

Ejercicio 8: Forma normal más alta

Indica la forma normal más alta (1FN, 2FN, 3FN o FNBC) de cada relación, justificándolo:

a) R(A, B, C, D), F = { A → B, C → D } b) R(A, B, C, D), F = { AB → C, C → D } c) R(A, B, C), F = { AB → C, C → B } d) R(A, B, C, D), F = { A → BCD, BC → A } e) R(A, B, C, D, E), F = { AB → CDE, C → D, D → B } f) R(A, B, C, D, E), F = { A → BC, C → D, D → E }

Ver solución

Rel.	Claves	Análisis	Forma normal
a	AC	A → B y C → D son parciales (B, D no primos)	1FN
b	AB	Sin parciales; C → D: C no superclave, D no primo (transitiva)	2FN
c	AB, AC	C → B: C no superclave pero B primo	3FN
d	A, BC	Todos los determinantes (A, BC) son claves	FNBC
e	AB, AC, AD	C → D y D → B: determinantes no superclave, implicados primos	3FN
f	A	Clave simple: 2FN. C → D, D → E: transitivas	2FN

En e), las claves se obtienen así: A nunca está a la derecha; (AB)⁺ = U; (AC)⁺ = ACD → ABCD → ABCDE = U (C → D, D → B, AB → CDE); (AD)⁺ = ABD → ABCDE = U; (AE)⁺ = AE.

Ejercicio 9: Descomposición a FNBC

Descompón en FNBC R(A, B, C, D, E) con F = { AB → CDE, C → D, D → B } (la relación e del ejercicio anterior). ¿Se preservan las dependencias?

Ver solución

Claves: AB, AC, AD. Violan la FNBC: C → D (C⁺ = CDB) y D → B.

Iteración 1. Por C → DB (todo lo que C determina): R₁(C, D, B), R₂(A, C, E).

R₁(B, C, D): DF proyectadas C → D, D → B, C → B. Clave C. D → B viola la FNBC (D⁺ ∩ BCD = BD).
R₂(A, C, E): (AC)⁺ ⊇ E; ¿A → ? A⁺ = A; C⁺ ∩ ACE = C. Clave AC. FNBC.

Iteración 2. R₁ por D → B: R₁₁(D, B), R₁₂(C, D).

Resultado: R₁₁(D, B), R₁₂(C, D), R₂(A, C, E).

¿Se preservan? C → D (R₁₂), D → B (R₁₁). AB → CDE: resultado = AB; R₁₁: B⁺ ∩ BD = B; R₁₂: ∅; R₂: A⁺ ∩ ACE = A. No se preserva AB → C (ni AB → E). Con la 3FN de partida (la relación ya estaba en 3FN) se mantenía todo.

Ejercicio 10: Síntesis a 3FN de los vuelos

Aplica el algoritmo de síntesis a la relación VUELOS del ejercicio 12 del módulo 19, cuyo recubrimiento mínimo era: { num_vuelo → origen, destino, hora_salida; num_vuelo, fecha → avion, piloto; avion → modelo; modelo → capacidad; piloto → nombre_piloto }.

Ver solución

Paso 2 (un esquema por determinante):

Determinante	Relación
num_vuelo	VUELOS (num_vuelo, origen, destino, hora_salida)
num_vuelo, fecha	OPERACIONES (num_vuelo, fecha, avion, piloto)
avion	AVIONES (avion, modelo)
modelo	MODELOS (modelo, capacidad)
piloto	PILOTOS (piloto, nombre_piloto)

Paso 3: la clave de la relación original, {num_vuelo, fecha}, está en OPERACIONES. No hay que añadir nada.

Paso 4: ningún esquema contenido en otro.

Claves ajenas: OPERACIONES.num_vuelo → VUELOS, OPERACIONES.avion → AVIONES, OPERACIONES.piloto → PILOTOS, AVIONES.modelo → MODELOS. Todas las relaciones tienen clave única y sus determinantes son clave: FNBC.

Mejora semántica que no detecta la normalización: probablemente un piloto no puede pilotar dos vuelos que se solapan en el tiempo. Eso no es una DF (depende de horas e intervalos) y requiere otro mecanismo.

Ejercicio 11: Citas en un hospital

CITAS (num_historia, nombre_paciente, fecha_nac, cod_medico, nombre_medico, cod_especialidad, nombre_especialidad, fecha, hora, consulta, motivo)

Reglas: cada médico tiene una especialidad; un médico atiende a un solo paciente en cada fecha y hora; un paciente no puede tener dos citas a la misma fecha y hora; cada médico pasa consulta en un único despacho cada día. Normaliza a FNBC.

Ver solución

num_historia            → nombre_paciente, fecha_nac
cod_medico              → nombre_medico, cod_especialidad
cod_especialidad        → nombre_especialidad
cod_medico, fecha, hora → num_historia, motivo
num_historia, fecha, hora → cod_medico
cod_medico, fecha       → consulta

Claves: fecha y hora nunca están a la derecha; LR = {num_historia, cod_medico, cod_especialidad}. (cod_medico, fecha, hora)⁺ = U y (num_historia, fecha, hora)⁺ = U (pasa por cod_medico). Dos claves: {cod_medico, fecha, hora} y {num_historia, fecha, hora}.

Forma normal: hay parciales (cod_medico → nombre_medico, num_historia → nombre_paciente, cod_medico, fecha → consulta) y transitivas (cod_especialidad → nombre_especialidad). Solo 1FN.

Resultado (síntesis y FNBC coinciden):

PACIENTES (num_historia, nombre_paciente, fecha_nac)

ESPECIALIDADES (cod_especialidad, nombre_especialidad)

MEDICOS (cod_medico, nombre_medico, cod_especialidad)

TURNOS (*cod_medico*, fecha, consulta)

CITAS (*cod_medico*, fecha, hora, num_historia, motivo) con UK: (num_historia, fecha, hora)

CITAS tiene dos claves candidatas: una se declara como PK y la otra como UNIQUE, y así el SGBD garantiza las dos reglas (“un médico, un paciente por hora” y “un paciente, una cita por hora”). FK: CITAS.(cod_medico, fecha) → TURNOS (un médico solo tiene citas los días que pasa consulta), CITAS.num_historia → PACIENTES, MEDICOS.cod_especialidad → ESPECIALIDADES. Todas en FNBC y se preservan todas las DF.

Ejercicio 12: Cuarta forma normal

Una plataforma de vídeo guarda CONTENIDOS(titulo, actor, idioma_audio): los actores del reparto y los idiomas en que está disponible el audio, que son independientes. ¿En qué forma normal está? Normaliza a 4FN. ¿Qué cambiaría si el idioma dependiera del actor (por ejemplo, actores de doblaje)?

Ver solución

No hay DF no triviales; la clave son los tres atributos: FNBC. Pero titulo ↠ actor | idioma_audio es no trivial y titulo no es superclave: no está en 4FN. Una película con 10 actores y 6 idiomas necesita 60 filas; añadir un idioma exige 10 inserciones.

Descomposición 4FN:

REPARTO (titulo, actor)

AUDIOS (titulo, idioma_audio)

(10 + 6 = 16 filas.)

Si el idioma dependiera del actor (cada actor de doblaje solo aparece en la versión de su idioma), actor e idioma no serían independientes, no habría DMV y la tabla ternaria sería correcta (incluso podría existir la DF titulo, actor → idioma_audio, que cambiaría la clave a {titulo, actor}).

Ejercicio 13: Quinta forma normal

En una red de centros de formación se cumple: “si un profesor está habilitado para una asignatura, y trabaja en un centro, y ese centro oferta la asignatura, entonces el profesor la imparte en ese centro”. Con estos datos de IMPARTE(profesor, asignatura, centro), comprueba la dependencia de combinación y normaliza:

profesor	asignatura	centro
Rosa	BD	Sur
Rosa	Prog	Norte
Iván	BD	Norte
Rosa	BD	Norte

Ver solución

Proyecciones:

PA (profesor, asignatura) = { Rosa-BD, Rosa-Prog, Iván-BD }
AC (asignatura, centro) = { BD-Sur, Prog-Norte, BD-Norte }
PC (profesor, centro) = { Rosa-Sur, Rosa-Norte, Iván-Norte }

Reuniones de dos:

Reunión	Tupla espuria
PA ⋈ AC	(Iván, BD, Sur): Iván no trabaja en Sur
PA ⋈ PC	(Rosa, Prog, Sur): Sur no oferta Prog
PC ⋈ AC	(Iván, Prog, Norte): Iván no está habilitado en Prog

La reunión de las tres elimina las tres tuplas espurias (cada una falla en la proyección que no se usó) y devuelve las cuatro filas originales: se cumple *(PA, AC, PC). No hay DF ni DMV no triviales (por ejemplo, profesor ↠ asignatura exigiría (Rosa, Prog, Sur)). Está en 4FN pero no en 5FN.

Descomposición 5FN: HABILITACIONES(profesor, asignatura), OFERTA(asignatura, centro), DESTINOS(profesor, centro). La tabla IMPARTE se obtiene con una vista que reúne las tres.

Ejercicio 14: ¿Desnormalizar?

En EMPRESA, el panel de dirección muestra continuamente el importe total de cada pedido y el número de empleados de cada departamento. Se propone añadir importe_total a pedidos y num_empleados a departamentos. Valora la propuesta y sus alternativas.

Ver solución

Ambas columnas son derivadas: importe_total se calcula sumando cantidad × precio_unitario × (1 − descuento/100) de las líneas, y num_empleados contando empleados. Añadirlas introduce la DF implícita “el valor almacenado debe coincidir con el cálculo”, que ninguna clave puede garantizar.

Riesgos: cada INSERT, UPDATE o DELETE en lineas_pedido o empleados debe actualizar la columna; si un programa lo olvida, el panel mostrará datos falsos. Mantenerlo automáticamente exige disparadores (PL/SQL).

Alternativas, de menos a más intrusiva:

No desnormalizar: con 24 pedidos y 23 empleados, el cálculo es instantáneo. Solo con millones de filas tendría sentido optimizar.
Vista que calcule los totales (módulo 26): misma comodidad para el panel, sin redundancia.
Índices en lineas_pedido(pedido_id) (ya cubierto por la PK) y empleados(dept_id).
Vista materializada con refresco periódico: el SGBD mantiene la copia y el panel acepta datos de hace unos minutos.
Columnas desnormalizadas + disparadores: solo si las anteriores no bastan y está medido.

Conclusión: en este caso no se justifica la desnormalización; una vista es la opción correcta.

Ejercicio 15: Propuesto. Alquiler de vehículos

ALQUILERES (matricula, marca, modelo, categoria, precio_dia_categoria, dni_cliente, nombre_cliente, fecha_inicio, fecha_fin, oficina_recogida, ciudad_oficina). Define las reglas que consideres razonables, escribe F, calcula las claves y normaliza a FNBC.

Ejercicio 16: Propuesto. Liga deportiva

PARTIDOS (jornada, equipo_local, equipo_visitante, estadio, ciudad_estadio, arbitro, nombre_arbitro, goles_local, goles_visitante). Cada equipo juega en casa en su estadio; en cada jornada un equipo juega un único partido. Encuentra todas las claves candidatas (hay más de una) y normaliza.

Ejercicio 17: Propuesto. Reservas de hotel

RESERVAS (num_reserva, dni_cliente, nombre_cliente, num_habitacion, tipo_habitacion, precio_noche, fecha_entrada, fecha_salida, regimen, precio_regimen). El precio por noche depende del tipo de habitación y de la temporada. Decide qué atributos necesitas añadir para que el precio quede bien determinado y normaliza.

Ejercicio 18: Propuesto. Agencia de viajes

Diseña desde una tabla plana VIAJES (cod_viaje, destino, pais, fecha_salida, guia, telefono_guia, dni_viajero, nombre_viajero, hotel, categoria_hotel, ciudad_hotel) el esquema en 3FN, sabiendo que un viaje visita varios hoteles y cada salida (viaje y fecha) tiene un único guía.

Ejercicio 19: Propuesto. Letras (1)

Sea R(A, B, C, D, E, G) con F = { A → B, B → C, C → A, D → E, AD → G }. Calcula las claves, la forma normal más alta, una descomposición FNBC y comprueba si preserva las dependencias.

Ejercicio 20: Propuesto. Letras (2)

Aplica el algoritmo de síntesis a R(A, B, C, D, E, G, H) con F = { AB → C, C → B, BD → EG, E → H, H → E }. Indica si alguna de las relaciones obtenidas no está en FNBC.

Ejercicio 21: Propuesto. Demostraciones

Demuestra que: a) toda relación con exactamente dos atributos está en FNBC; b) si una relación está en 3FN y todas sus claves candidatas son simples, está en FNBC; c) la descomposición de R por una DF X → Y en (X ∪ Y) y (U − Y) es siempre sin pérdida.

Ejercicio 22: Propuesto. 4FN

Una consultora guarda CONSULTORES(empleado, habilidad, idioma, cliente), donde habilidades e idiomas son características del empleado y cliente son los clientes para los que trabaja. Identifica las DMV y normaliza a 4FN.

Ejercicio 23: Propuesto. Matriz de Chase

Sea R(A, B, C, D, E) con F = { A → C, B → C, C → D, DE → C, CE → A }. Comprueba si la descomposición {AD, AB, BE, CDE, AE} es sin pérdida.

PUBLICACIONES (id_publicacion, autor, email_autor, fecha, texto, etiquetas, id_usuario_like, fecha_like). Una publicación tiene varias etiquetas y puede recibir muchos “me gusta” (como mucho uno por usuario). Pasa a 1FN y normaliza hasta 4FN.

Resumen

Concepto	Idea clave
Anomalías	Inserción, modificación y borrado; causadas por DF cuyo determinante no es superclave
Normalización	Descomponer en relaciones que cumplan una forma normal
Sin pérdida	r = ⋈ de las proyecciones; test de dos relaciones: R₁ ∩ R₂ superclave de una de ellas; matriz de Chase para n
Preservación	Toda DF comprobable dentro de una tabla; algoritmo con (resultado ∩ Rᵢ)⁺ ∩ Rᵢ
1FN	Valores atómicos y monovaluados
2FN	Sin dependencias parciales de no primos respecto de una clave
3FN (Zaniolo)	X → A: X superclave o A primo
FNBC	Todo determinante es superclave; puede perder DF
4FN	Toda DMV no trivial tiene determinante superclave
5FN (FNPC)	Toda DC está implicada por las claves; restricciones cíclicas
6FN, FNDC	Irreducibilidad (bases temporales); restricciones de dominio y clave
Síntesis (Bernstein)	Recubrimiento mínimo → una tabla por determinante → añadir clave → 3FN, sin pérdida, preserva
Descomposición FNBC	Partir por X → Y mientras X no sea superclave; sin pérdida, no siempre preserva
Desnormalización	Redundancia deliberada por rendimiento; primero normalizar, después medir
E/R y normalización	Un buen E/R da tablas en 3FN/FNBC; la normalización valida el diseño

Navegación
← Módulo anterior: Dependencias funcionales	Siguiente módulo: Casos prácticos de diseño lógico →

Módulo 24: Normalización

Objetivos del módulo

1. Las anomalías de un mal diseño

1.1 Una tabla “plana” de ventas

1.2 Redundancia

1.3 Anomalía de inserción

1.4 Anomalía de modificación

1.5 Anomalía de borrado

1.6 Origen común de las anomalías

2. El objetivo de la normalización

3. Descomposición de relaciones

3.1 Definición

3.2 Descomposición sin pérdida de información

3.3 Test de dos relaciones (teorema de Heath)

3.4 Test de la matriz (algoritmo de Chase)

3.5 Preservación de dependencias

3.6 Relación entre las dos propiedades

4. Primera forma normal (1FN)

4.1 Definición

4.2 Cómo pasar a 1FN

5. Segunda forma normal (2FN)

5.1 Definición

5.2 Ejemplo: VENTAS_PLANO no está en 2FN

5.3 Cómo pasar a 2FN

6. Tercera forma normal (3FN)

6.1 Definición de Codd

6.2 Definición de Zaniolo (equivalente y más práctica)

6.3 Ejemplo: PEDIDOS_2 no está en 3FN

6.4 Cómo pasar a 3FN

7. Forma normal de Boyce-Codd (FNBC)

7.1 Definición

7.2 El ejemplo clásico: 3FN pero no FNBC

7.3 Pasar a FNBC y perder una dependencia

8. Cuarta forma normal (4FN)

8.1 Definición

8.2 Ejemplo

9. Quinta forma normal (5FN o FNPC)

9.1 Definición

9.2 Ejemplo: agentes, empresas y productos

10. Sexta forma normal y forma normal de dominio-clave

10.1 Sexta forma normal (6FN)

10.2 Forma normal de dominio-clave (FNDC, DKNF)

11. Algoritmos de normalización

11.1 Síntesis a 3FN (algoritmo de Bernstein)

11.2 Descomposición a FNBC

12. Tabla resumen de formas normales

13. Método práctico de normalización

14. Desnormalización

14.1 Qué es y por qué se hace

14.2 Técnicas

14.3 Riesgos

15. Diseño E/R y normalización

16. Ejercicios

Ejercicio 1: Factura

Ejercicio 2: Matrícula en un ciclo formativo

Ejercicio 3: Préstamos de una biblioteca

Ejercicio 4: Horarios de un instituto (3FN frente a FNBC)

Ejercicio 5: Pasar a 1FN

Ejercicio 6: ¿Sin pérdida?

Ejercicio 7: Preservación de dependencias

Ejercicio 8: Forma normal más alta

Ejercicio 9: Descomposición a FNBC

Ejercicio 10: Síntesis a 3FN de los vuelos

Ejercicio 11: Citas en un hospital

Ejercicio 12: Cuarta forma normal

Ejercicio 13: Quinta forma normal

Ejercicio 14: ¿Desnormalizar?

Ejercicio 15: Propuesto. Alquiler de vehículos

Ejercicio 16: Propuesto. Liga deportiva

Ejercicio 17: Propuesto. Reservas de hotel

Ejercicio 18: Propuesto. Agencia de viajes

Ejercicio 19: Propuesto. Letras (1)

Ejercicio 20: Propuesto. Letras (2)

Ejercicio 21: Propuesto. Demostraciones

Ejercicio 22: Propuesto. 4FN

Ejercicio 23: Propuesto. Matriz de Chase

Ejercicio 24: Propuesto. Red social

Resumen