Tres lecciones enteras defendiendo que cada hecho debe estar almacenado exactamente una vez, y ahora una lección explicando cuándo conviene romper esa regla. Puede parecer una contradicción, y no lo es: es la diferencia entre saber una regla y saber usarla.

Al final de la lección anterior nos encontramos cuatro veces con la misma situación. duracion_min en eventos, calculada a partir de inicio y fin. plazas_ocupadas en inscripciones, calculada a partir de acompanantes. El importe de una multa, que no puede recalcularse si la ordenanza cambia. La tarifa_hora de una cesión de sala, que debe quedar congelada con el valor del día de la factura. Las cuatro son redundancias. Las cuatro violan la letra de la tercera forma normal. Y las cuatro son correctas.

Desnormalizar es introducir redundancia en un esquema a propósito, para conseguir algo concreto que el esquema normalizado no daba. Las tres palabras que importan son "a propósito", "concreto" y "no daba". Sin las tres, no es desnormalización: es no haber hecho el trabajo.

Esta lección cierra el módulo con la decisión inversa, tomada con el mismo rigor con que hemos tomado las anteriores. Qué se gana y qué se paga exactamente. Cuándo está justificado y cuándo no. Las técnicas una a una, con SQL sobre BiblioRed. Cómo se mantiene la coherencia de lo que se ha duplicado adrede. Y una guía de decisión con las preguntas que hay que responder antes de tocar nada —y las señales de que hay que dar marcha atrás.

1. Qué es desnormalizar y la regla de oro
2. Lo primero que hay que probar: los índices, no la desnormalización
3. La balanza: qué se gana y qué se paga
4. Cuándo está justificado: los tres casos
5. Técnica 1: la columna redundante o calculada
6. Técnica 2: columnas generadas frente a columnas mantenidas a mano
7. Técnica 3: duplicar un atributo para evitar un JOIN
8. Técnica 4: tablas de resumen preagregadas
9. Técnica 5: vistas materializadas
10. Técnica 6: tablas de historial planas
11. Técnica 7: el esquema en estrella de los almacenes de datos
12. Cómo se mantiene la coherencia de lo desnormalizado
13. El puente con NoSQL: el modelado documental es desnormalización elevada a método
14. Guía de decisión: las preguntas antes y las señales para deshacerlo

Definición. Desnormalizar es modificar deliberadamente un esquema normalizado para introducir redundancia —datos duplicados o derivados— con el objetivo de mejorar el rendimiento de lectura o de preservar un valor histórico, aceptando a cambio el coste de mantener esa redundancia coherente.

Fíjate en tres cosas de esa definición.

Se parte de un esquema normalizado. No se puede desnormalizar lo que nunca estuvo normalizado. Un esquema que nació con redundancia porque nadie analizó las dependencias no está desnormalizado: está mal diseñado. La diferencia no es semántica: en un esquema desnormalizado sabes exactamente qué dato está duplicado, por qué, y quién es responsable de mantenerlo; en un esquema mal diseñado, no.

El objetivo es concreto. "Por si acaso" y "para que vaya más rápido" no son objetivos. "El informe mensual de dirección tarda cuarenta segundos y tiene que tardar menos de dos" sí lo es. "El importe de la multa no debe cambiar si la ordenanza sube" también.

Se acepta un coste, y hay que nombrarlo. Toda desnormalización tiene una factura, y la factura la paga alguien: el que escribe, el que mantiene el disparador, o el usuario que un día ve dos cifras distintas para lo mismo.

Primero normaliza. Después desnormaliza a propósito, midiendo. Nunca al revés.

Es la regla que ordena toda la lección y merece la pena desglosarla:

"Primero normaliza" significa que el punto de partida es siempre el esquema en 3FN o FNBC. Es el que expresa correctamente el dominio, el que no admite contradicciones, y el que cualquier profesional entenderá. Es también, y esto se olvida, la única referencia contra la que se puede medir si la desnormalización ha servido de algo.

"A propósito" significa documentado. Cada columna redundante debe tener escrito al lado: qué duplica, por qué, quién la mantiene y qué pasa si se desincroniza. Sin eso, dentro de dos años alguien la verá, pensará que es un error, y la "arreglará" o —peor— la dejará pudrirse.

"Midiendo" significa con números antes y después. Si no puedes decir "esta consulta tardaba 4,2 segundos y ahora tarda 80 milisegundos", no sabes si la desnormalización ha servido. Y muy a menudo no sirve: el problema estaba en otra parte.

"Nunca al revés" es lo importante. Empezar con un esquema redundante "porque así será más rápido" y normalizarlo cuando dé problemas es el orden equivocado, porque la desnormalización prematura toma decisiones sobre un patrón de uso que todavía no conoces, y deshacerla después es infinitamente más caro que hacerla ahora: hay datos, hay código y hay informes que dependen de ella.

Antes de seguir, una advertencia que evita la mayor parte de las desnormalizaciones innecesarias que se ven en producción.

Cuando una consulta va lenta, la desnormalización no es lo primero que hay que probar. Es lo último.

El orden correcto de intervenciones, de menos invasiva a más, es este:

Los cuatro primeros no tocan los datos, no introducen la posibilidad de que la base de datos se contradiga, y se deshacen en un minuto. El quinto es permanente en la práctica.

Y la experiencia es contundente: la inmensa mayoría de las consultas lentas en un esquema normalizado se arreglan con un índice. Un JOIN de cinco tablas con las claves ajenas indexadas sobre unos cientos de miles de filas es una operación de milisegundos en PostgreSQL. Si tarda segundos, casi siempre falta un índice, la consulta pide columnas que no necesita, o el planificador está trabajando con estadísticas viejas.

Los índices, el plan de ejecución, EXPLAIN ANALYZE y cómo se lee, y la optimización de consultas en general son el contenido de la lección 06-03. Es literalmente la lección siguiente a este módulo, y el orden no es casual: primero se aprende a hacer que el esquema normalizado vaya rápido, y solo entonces se plantea cambiarlo.

Regla operativa: no desnormalices ninguna consulta sin haber ejecutado antes su EXPLAIN ANALYZE y haber comprobado que no hay ningún índice que la arregle. Si no sabes leer un plan de ejecución todavía, no estás en condiciones de decidir una desnormalización.

Toda desnormalización es un intercambio. Estos son los dos platos de la balanza, y conviene tenerlos escritos para poder comparar en cada caso concreto.

La nota sobre la contención merece detenerse, porque es el coste que menos se anticipa. Si añades total_prestamos a la tabla socios y lo actualizas en cada préstamo, cada operación de mostrador tiene que bloquear la fila del socio. Con un socio prestando de uno en uno no pasa nada. Pero si mañana añades total_prestamos a sucursales, todas las operaciones de la sucursal Norte compiten por la misma fila, y en hora punta el mostrador se serializa. Los mecanismos de bloqueo y los niveles de aislamiento son la lección 06-02; por ahora quédate con que un contador global es una desnormalización con un coste de concurrencia que puede ser mucho peor que el JOIN que evitaba.

De todos los motivos que se alegan para desnormalizar, solo tres resisten el examen.

La desnormalización cambia coste de escritura por velocidad de lectura. Solo compensa si se lee muchísimo más de lo que se escribe.

En BiblioRed, la ficha pública de un material —título, autor, disponibilidad por sucursal— se consulta desde el catálogo web unas 40.000 veces al día. Los datos que muestra cambian, como mucho, cuando entra un ejemplar nuevo: dos o tres veces por semana. La relación es de decenas de miles de lecturas por escritura, y ahí una copia bien mantenida se paga sola.

En el lado contrario, la tabla prestamos se escribe constantemente durante el horario del mostrador y se lee sobre todo por socio. Desnormalizarla para acelerar un informe que se ejecuta una vez al mes es un mal negocio.

El criterio numérico: si la relación lecturas/escrituras no llega a 10:1, casi nunca compensa. Por encima de 100:1, empieza a ser interesante. Y ese ratio hay que medirlo, no estimarlo.

Este es el caso donde la desnormalización gana por goleada y ninguna otra técnica se le acerca.

Dirección quiere un cuadro de mando con los préstamos por sucursal y mes de los últimos ocho años. Sobre el esquema normalizado, eso es un GROUP BY sobre 84.000 filas de prestamos con tres JOIN. Hoy tarda unos segundos. Cuando BiblioRed lleve veinte años y tenga millones de préstamos, tardará minutos, y el cuadro de mando se abrirá una vez cada mañana... para cada uno de los quince responsables.

La clave está en que los datos de meses cerrados no cambian nunca. Recalcular en cada consulta el total de marzo de 2019 es tirar trabajo. Precalcularlo una vez y guardarlo es la decisión evidente. Es la técnica 4 de la sección 8.

Y este es el caso más importante de los tres, porque no es una cuestión de rendimiento sino de corrección. Aquí la desnormalización no es un compromiso: es la única respuesta correcta.

Considera la multa 900 de BiblioRed: emitida el 12 de marzo de 2026 al socio 14 por un retraso de 35 días, importe 3,50 €, tarifa vigente 0,10 €/día. En abril, el ayuntamiento sube la tarifa a 0,15 €/día.

¿Cuánto debe Marta Alsina por aquella multa? 3,50 €. Se le comunicó por escrito, consta en el recibo, y no puede cambiar. Si multas no guardara el importe y lo calculara con un JOIN a la tabla de tarifas, en abril esa multa pasaría a valer 5,25 € retroactivamente. Eso no es un problema de diseño: es un error de facturación.

El mismo razonamiento vale para:

• El nombre del socio en el momento del pago. Si un recibo dice "Recibido de Marta Alsina" y ella cambia de apellido, el recibo emitido no cambia. El nombre en el recibo es un dato histórico, no una referencia viva a socios.
• El precio de adquisición de un ejemplar. Se pagó lo que se pagó.
• La dirección de envío de un pedido, en un comercio electrónico. El pedido se envió allí, aunque el cliente se haya mudado.

Este es exactamente el patrón que en la lección 03-03 llamamos duplicación histórica congelada al hablar del modelado documental, y clasificamos como "categoría B": un campo duplicado que es correcto por semántica, no una copia que haya que propagar. La disciplina que exige es distinta de la de una copia viva: no se actualiza nunca, y precisamente por eso no tiene riesgo de inconsistencia.

La prueba para distinguirlo: pregúntate "si el valor original cambia mañana, ¿este debe cambiar también?". Si la respuesta es no, no es una desnormalización de rendimiento: es un dato distinto que casualmente coincidió con el original en el momento de crearlo, y guardarlo es lo correcto.

La más común y la más fácil de hacer mal. Consiste en guardar en una tabla un valor que se puede obtener contando o sumando filas de otra.

El caso: la ficha del socio en la aplicación de mostrador muestra cuántos préstamos tiene en total y cuántos están abiertos. Normalizado:

Con un índice sobre prestamos(socio_id) esto es instantáneo para un socio. Aquí no hay nada que desnormalizar, y es importante decirlo: la tentación de añadir el contador aparece antes de haber comprobado si hace falta.

Donde sí aparece el problema es en el listado de los 12.000 socios de la sucursal Norte con su número de préstamos, que la aplicación pagina de 50 en 50. Ahí el agregado se calcula sobre toda la tabla en cada página.

La desnormalización:

La consulta pasa a ser un SELECT directo sobre socios, sin JOIN ni agregación.

Lo que hay que documentar y no olvidar:

Esa última fila es la más importante y la que más se olvida: toda columna desnormalizada necesita un procedimiento documentado para recalcularla desde cero. Es la red de seguridad, y algún día se usará.

La consulta de auditoría:

Si esa consulta devuelve filas, el mecanismo de mantenimiento tiene un agujero. Programarla como comprobación nocturna cuesta cinco minutos y ahorra meses de desconcierto.

No toda columna derivada tiene el mismo riesgo. Hay una diferencia enorme entre las que mantiene el SGBD y las que mantiene tu código, y elegir bien es la decisión más rentable de esta lección.

Ya las conocemos del módulo 4 y las examinamos en 05-03:

La palabra ALWAYS es la garantía: PostgreSQL recalcula el valor en cada INSERT y cada UPDATE, y rechaza cualquier intento de escribirlo a mano:

Es una desnormalización sin riesgo de inconsistencia. Viola la 3FN en la letra, y no en el espíritu, porque el peligro que la 3FN previene está eliminado por otro mecanismo.

Su limitación es importante: una columna generada solo puede depender de columnas de su propia fila y usar funciones deterministas. No puede contar filas de otra tabla, ni consultar sucursales, ni usar now(). Por eso total_prestamos en socios no puede ser una columna generada: depende de otra tabla.

Cuando la columna generada no llega, el mantenimiento pasa a ser responsabilidad de alguien, y ahí empiezan los problemas de la sección 12.

Y el detalle que ya señalamos en 05-03 y que conviene fijar: un importe histórico no puede ser una columna generada, aunque lo parezca. importe = tarifa × dias es una fórmula, sí, pero si tarifa cambia, una columna generada recalcularía el importe de las multas antiguas. Tiene que ser una columna normal, calculada una vez al emitir la multa y nunca más. La diferencia entre duracion_min —derivada de inicio y fin, que son de la propia fila y no cambian— y un importe derivado de un dato externo mutable es exactamente esta.

La técnica más simple: copiar una columna de la tabla A a la tabla B para no tener que unirlas.

El caso: la lista de préstamos activos en el mostrador muestra el título del material. Normalizado hacen falta tres JOIN, porque libros es una vista sobre materiales + materiales_libro desde la jerarquía de 04-03:

La desnormalización:

La consulta se queda en un SELECT sobre prestamos con un solo JOIN a ejemplares para el filtro de sucursal.

Y ahora la parte honesta: en este caso concreto, casi seguro que no vale la pena. Con índices en las claves ajenas, tres JOIN sobre unas decenas de miles de filas son milisegundos. Se ha introducido una copia viva —si alguien corrige un título mal catalogado, hay que propagarlo a todos los préstamos— a cambio de un beneficio que probablemente no se nota. Es el ejemplo perfecto de desnormalización que parece razonable y no lo es.

¿Cuándo sí valdría la pena? Cuando el atributo duplicado cumple al menos una de estas dos condiciones:

• Es inmutable. El ISBN de una edición no cambia nunca. Copiarlo es gratis: no hay nada que propagar. Es la "categoría A" de 03-03.
• Debe congelarse. El título del material en el momento del préstamo, para un recibo o un histórico. Es la categoría B: se copia una vez y nunca se toca.

Si el atributo es vivo —puede cambiar y la copia debe seguirlo— la duplicación exige propagación, y entonces hay que preguntarse si el JOIN que se evita compensa el mecanismo que se añade. La mayor parte de las veces, no.

Aquí es donde la desnormalización deja de ser un compromiso discutible y pasa a ser la solución obvia.

El caso: el cuadro de mando de dirección con los préstamos por sucursal y mes desde 2018.

La carga, que es una única consulta agregada:

El cuadro de mando pasa de agregar 84.000 filas (y creciendo) a leer una tabla de unos 400 registros —8 años × 12 meses × 4 sucursales—. La diferencia de rendimiento no es de un 20 %: es de tres órdenes de magnitud, y no se puede conseguir de ninguna otra forma.

Tres detalles de diseño que hacen que esta técnica funcione bien:

La columna cerrado. Distingue los meses terminados —que no cambiarán nunca— del mes en curso, que sí. Los cerrados se calculan una vez y se olvidan; solo el mes actual necesita refresco. Es lo que hace que el coste de mantenimiento sea casi cero.

La columna actualizado_en. Cualquiera que mire la tabla sabe de cuándo son los datos. Sin ella, nadie puede juzgar si una cifra es fiable.

El ON CONFLICT ... DO UPDATE. Permite ejecutar la carga las veces que haga falta sin duplicar nada. Un proceso que se puede repetir sin efectos secundarios es infinitamente más fácil de operar que uno que hay que ejecutar exactamente una vez.

Y la regla que no se negocia: la tabla de resumen es derivada, nunca fuente de verdad. Si resumen_prestamos_mes y prestamos discrepan, prestamos tiene razón y el resumen se regenera. El día que alguien empiece a corregir cifras directamente en el resumen, la desnormalización se ha convertido en un segundo sistema de datos incoherente con el primero.

Una vista materializada es una tabla de resumen que el SGBD gestiona por ti: se define con una consulta, PostgreSQL guarda el resultado en disco, y se refresca cuando se lo pides.

Se consulta como cualquier tabla:

Es el punto crítico, y la diferencia entre las dos formas es grande:

Para el catálogo web de BiblioRed, cada 10 minutos es más que suficiente: que la web diga "2 disponibles" cuando hace tres minutos que quedó 1 es aceptable, porque el socio va a comprobarlo en el mostrador de todos modos.

Regla práctica: empieza siempre por una vista materializada. Si el refresco completo tarda demasiado —y con años de historial acabará tardando— migra a una tabla de resumen con refresco incremental. Es el orden que minimiza el trabajo.

(Nota: SQLite no tiene vistas materializadas. El equivalente es una tabla normal poblada por la aplicación. Es una de las diferencias que hay que tener presentes al elegir entre PostgreSQL y SQLite, como vimos en 01-02.)

Una variante de la tabla de resumen que no agrega, sino que aplana: guarda una fila por hecho, pero con todas las columnas que hacen falta ya resueltas, sin JOIN.

Cada fila lleva doce columnas que en el esquema normalizado exigirían cinco JOIN. Cualquier informe —préstamos por autor y año, por tipo de material y sucursal, por franja de edad del socio— se resuelve con un GROUP BY sobre una sola tabla.

Lo importante de esta técnica es la frase "en el momento del préstamo". Los valores se copian cuando el préstamo se cierra y no se actualizan nunca más. Si Marta Alsina se traslada a la sucursal Sur en 2027, los préstamos que hizo en 2026 siguen diciendo "Norte", que es la verdad histórica. Un informe sobre la actividad de la sucursal Norte en 2026 debe contarlos.

Aquí está la diferencia clave con las técnicas anteriores: esto no es una copia que haya que mantener sincronizada. Es un registro de lo que era cierto entonces. No hay riesgo de inconsistencia porque no hay nada que propagar, y por eso esta es una de las desnormalizaciones más seguras que existen.

Todas las técnicas anteriores son desnormalizaciones puntuales sobre un esquema normalizado. El esquema en estrella es otra cosa: es un modelo de datos completo diseñado desde el principio para desnormalizar, de forma sistemática y por norma.

Retomamos aquí la distinción OLTP frente a OLAP de la lección 01-02:

El esquema en estrella organiza los datos en dos tipos de tabla:

• Tabla de hechos (fact table): una fila por acontecimiento medible, con las métricas numéricas que se van a agregar y claves ajenas a las dimensiones. Es enorme —millones o miles de millones de filas— y muy estrecha.
• Tablas de dimensión: el contexto por el que se quiere filtrar y agrupar. Son pequeñas, anchas y deliberadamente desnormalizadas: una dimensión no se descompone aunque tenga dependencias transitivas.

Se llama "en estrella" porque el diagrama tiene la tabla de hechos en el centro y las dimensiones alrededor:

Y las consultas analíticas se vuelven triviales de escribir y rapidísimas de ejecutar:

Un solo nivel de JOIN, sin cadenas. En el esquema normalizado, llegar de un préstamo a la nacionalidad del autor exige recorrer prestamos → ejemplares → materiales → autores.

Cuatro razones, y las cuatro son sólidas:

1. No hay escrituras concurrentes. El almacén se carga por lotes desde el sistema operativo. El principal coste de la desnormalización —mantener la coherencia ante escrituras— sencillamente no existe.
2. La fuente de verdad está en otro sitio. Si el almacén se corrompe, se vuelve a cargar desde el OLTP. La redundancia no puede producir una pérdida irrecuperable.
3. Los datos son históricos e inmutables. Un préstamo de 2019 no cambia. Y cuando el contexto cambia —un material se recataloga— lo correcto es conservar el valor antiguo para los hechos antiguos, que es justo lo que la desnormalización da.
4. El patrón de consulta es conocido y estable. Se sabe de antemano por qué se va a agrupar, y el modelo se diseña para eso.

En resumen: en OLAP se dan a la vez todas las condiciones que justifican desnormalizar, y ninguna de las que lo desaconsejan. Por eso allí es la norma y no la excepción.

(Existe una variante llamada copo de nieve que sí normaliza las dimensiones —sacando autor de dim_material a su propia tabla, por ejemplo—. Ahorra espacio y complica las consultas. El criterio mayoritario en la industria es estrella salvo que las dimensiones sean gigantescas. El diseño de almacenes de datos es una disciplina propia; aquí solo interesa reconocerlo como desnormalización sistemática y entender por qué está justificada.)

Toda desnormalización que no sea histórica congelada crea una obligación: mantener la copia sincronizada con la fuente. Hay tres formas de cumplirla y hay que elegir conscientemente.

El código que escribe el préstamo actualiza también el contador:

A favor: la lógica está donde el equipo la ve, es fácil de depurar y de probar.

En contra, y es un problema serio: basta que un solo camino de escritura se olvide para que la copia empiece a divergir. Y los caminos de escritura son más de los que parece: la aplicación web, la aplicación de mostrador, el proceso de importación nocturno, el script de corrección que alguien ejecutó a mano un martes por la tarde. Cada uno tiene que acordarse.

Un disparador es una función que el SGBD ejecuta automáticamente cuando ocurre un evento sobre una tabla. La ventaja decisiva: da igual quién escriba y desde dónde.

Lectura del código, línea a línea, porque es la primera vez que aparece un disparador en el curso:

• RETURNS TRIGGER marca la función como apta para ser invocada por un disparador.
• TG_OP es una variable especial que contiene la operación: 'INSERT', 'UPDATE' o 'DELETE'.
• NEW es la fila nueva (existe en INSERT y UPDATE); OLD es la anterior (existe en UPDATE y DELETE).
• AFTER ... FOR EACH ROW significa que se ejecuta una vez por fila afectada, después de aplicar el cambio. Si un UPDATE toca 500 filas, el disparador se ejecuta 500 veces.
• Todo ocurre dentro de la misma transacción que la operación original: si el UPDATE del contador falla, el INSERT del préstamo se deshace también. Esa atomicidad es precisamente lo que hace fiable esta opción, y es materia de la lección 06-01.

A favor: imposible de saltarse. Coherencia garantizada por el SGBD.

En contra: es lógica de negocio escondida en la base de datos, invisible para quien lee el código de la aplicación; complica la depuración; y cuesta en cada escritura. Un UPDATE masivo de 100.000 filas ejecuta el disparador 100.000 veces.

Un trabajo programado recalcula la copia periódicamente:

A favor: coste cero en las escrituras, código sencillo, y —esto es valioso— corrige por sí solo cualquier divergencia, venga de donde venga.

En contra: los datos están desfasados entre ejecuciones. Hay que decidir si eso es aceptable, y decirlo en la interfaz ("datos a fecha de ayer").

La combinación que mejor funciona en la práctica: elige una de las tres para el mantenimiento y añade siempre la de lote como auditoría. Aunque uses un disparador, programa la consulta de comprobación nocturna. Si algún día devuelve filas, sabrás que hay un agujero antes de que lo descubra un usuario.

Si al leer la sección 7 has pensado "esto se parece mucho a lo de embeber documentos", has visto exactamente lo que hay que ver.

El modelado documental de la lección 03-03 —embeber en lugar de referenciar, duplicar campos a propósito, diseñar el agregado alrededor de la consulta que lo va a leer— es desnormalización. No es una técnica parecida: es la misma decisión, tomada por los mismos motivos, con las mismas consecuencias.

Compáralo punto por punto:

La diferencia no está en la técnica sino en el punto de partida por defecto. En un sistema relacional, lo normal es normalizar y desnormalizar en casos concretos y justificados. En un sistema documental, lo normal es agregar —desnormalizar— y normalizar (referenciar) en casos concretos y justificados. El eje es el mismo; lo que cambia es dónde está el punto neutro.

Y la disciplina que exige es idéntica. En 03-03 establecimos que cada campo duplicado debe estar clasificado —inmutable, histórico congelado, o vivo con propagación— y que si no se escribe, en seis meses nadie sabrá si hay que actualizarlo. Es exactamente la documentación que la sección 5 de esta lección exige para cada columna redundante. La regla es la misma en los dos mundos: duplica lo que se muestra, nunca lo que se usa para decidir; y escribe siempre quién es la fuente de verdad.

Esto explica también algo que en el módulo 3 podía sonar contradictorio. Cuando dijimos que MongoDB "no necesita JOIN" no estábamos diciendo que hubiera desaparecido el problema que el JOIN resuelve: estábamos diciendo que se paga por adelantado, en la escritura, en forma de duplicación mantenida. Es el mismo intercambio de la sección 3 de esta lección, con los mismos platos en la balanza.

Respóndelas por escrito. Si alguna no tiene respuesta, no desnormalices todavía.

1. ¿He medido el problema? ¿Cuánto tarda ahora la consulta, con datos de producción y volumen real? Si no tienes el número, no tienes un problema: tienes una sospecha.

2. ¿He probado con un índice? EXPLAIN ANALYZE de la consulta, revisión de los índices existentes, ANALYZE de las tablas. Esto es la lección 06-03 y es obligatorio antes de seguir.

3. ¿Cuál es el objetivo concreto? "Este informe debe abrirse en menos de dos segundos" es un objetivo. "Ir más rápido" no lo es, porque no se puede saber si se ha cumplido.

4. ¿Cuál es la relación lecturas/escrituras? Medida, no estimada. Por debajo de 10:1, la desnormalización rara vez compensa.

5. ¿La copia es inmutable, histórica congelada o viva? Es la pregunta que más ahorra. Las dos primeras son casi gratis. Solo la tercera exige un mecanismo de propagación, y solo entonces hay que responder las dos siguientes.

6. ¿Quién mantiene la copia y qué pasa si falla? Aplicación, disparador o lote (sección 12). Y el escenario del fallo: ¿un número mal en una pantalla, o un importe mal en una factura? La gravedad decide el mecanismo.

7. ¿Cómo se detecta y se repara la divergencia? La consulta de auditoría y el procedimiento de recálculo, escritos y programados. Si no los tienes, la desnormalización no está terminada.

Una desnormalización no es para siempre. Estas seis señales indican que hay que revisarla, y probablemente revertirla:

1. Las consultas de auditoría devuelven filas con regularidad. El mecanismo de mantenimiento tiene un agujero que no se ha cerrado. Cada divergencia detectada es un dato que alguien vio mal antes de que la auditoría lo pillara.

2. Nadie recuerda por qué está esa columna. Si la documentación no existe o nadie la encuentra, la desnormalización ya no es deliberada: es deuda.

3. La copia se ha convertido en fuente de verdad. El síntoma es que alguien corrige un valor en la copia en lugar de en el original. A partir de ahí hay dos sistemas de datos que se contradicen y no hay forma de decidir cuál manda.

4. Las escrituras se han vuelto el cuello de botella. El sistema optimizó las lecturas y ahora el mostrador espera. Mide otra vez: puede que el equilibrio haya cambiado.

5. El motivo original ha desaparecido. El informe que justificaba la tabla de resumen ya no lo usa nadie. La versión nueva de PostgreSQL ejecuta aquel JOIN cien veces más rápido. Se añadió un índice que resuelve el caso. Revisa las desnormalizaciones al menos una vez al año: algunas caducan.

6. La lógica de mantenimiento se ha vuelto más compleja que el JOIN que evitaba. Si el disparador tiene cuarenta líneas y tres casos especiales para ahorrar un JOIN de dos tablas, el intercambio ha dejado de tener sentido.

Con la misma disciplina que se hizo, y en orden inverso al de 05-03: se cambian primero las lecturas para que usen el esquema normalizado, se comprueba que dan los mismos resultados, se retira el mecanismo de mantenimiento, y solo al final se elimina la columna o la tabla. Guardando una copia antes, siempre.

Desnormalizar sin haber medido. Es el error número uno y la causa de la mayor parte de la redundancia innecesaria que hay en producción. "Esto va a ir lento cuando crezca" es una predicción, no una medición, y las predicciones sobre rendimiento fallan constantemente: el cuello de botella casi nunca está donde se esperaba.

Desnormalizar antes de probar un índice. Es la sección 2 entera. Un CREATE INDEX es reversible, gratuito en riesgo, e instantáneo; una desnormalización es permanente en la práctica. Empieza por 06-03.

Empezar desnormalizado "por si acaso". Rompe la regla de oro. No sabes todavía qué consultas van a dominar, ni con qué volumen, ni con qué patrón de escritura. Y deshacerlo después es mucho más caro que hacerlo ahora.

No documentar la fuente de verdad. Cada dato duplicado tiene que tener escrito cuál de las dos copias manda. Sin eso, el día que discrepen —y discreparán— nadie sabrá cuál corregir, y alguien elegirá mal.

Tratar la copia como fuente de verdad. El síntoma es un UPDATE directo sobre la tabla de resumen para "cuadrar" una cifra. Ese UPDATE no arregla nada: crea una divergencia permanente que el siguiente refresco borrará, o peor, no borrará.

Poner un disparador que refresque una vista materializada entera en cada escritura. Anula por completo el beneficio y convierte cada INSERT en un recálculo global. Las vistas materializadas se refrescan de forma programada.

Olvidar el procedimiento de recálculo. Toda desnormalización necesita un UPDATE/INSERT documentado que la reconstruya desde cero. Algún día habrá que ejecutarlo, con prisa, y no será el momento de escribirlo.

Confundir "dato congelado" con "dato desnormalizado". No son lo mismo y confundirlos lleva a dos errores opuestos: propagar un valor que debía quedarse quieto (y falsear un histórico), o dejar sin propagar una copia viva (y mostrar datos obsoletos). La pregunta que los separa está en la sección 4: si el original cambia mañana, ¿este debe cambiar también?

No revisar nunca. Las desnormalizaciones caducan. Una revisión anual de todas las que hay en el esquema, con sus mediciones repetidas, suele encontrar al menos una que ya no hace falta.

Para cada uno de estos cuatro casos de BiblioRed, decide si desnormalizarías o no. Justifica con las preguntas de la sección 14 e indica, si desnormalizas, qué técnica usarías y qué mecanismo de mantenimiento.

a) La página de detalle de un evento muestra el nombre de la sala y su aforo. Se consulta unas 300 veces al día. La consulta normalizada tarda 4 milisegundos.

b) El informe anual de dirección cruza los 84.000 préstamos con socios, materiales, autores y sucursales, agrupando por autor y año. Tarda 38 segundos y lo abren 15 personas cada mañana durante enero.

c) El recibo que se imprime al cobrar una multa muestra el nombre del socio, el importe y el motivo.

d) El catálogo web muestra, para cada material, cuántos ejemplares hay disponibles en cada sucursal. Se consulta 40.000 veces al día y los datos cambian con cada préstamo y cada devolución.

BiblioRed añadió hace seis meses la columna socios.total_prestamos, mantenida por la aplicación de mostrador (opción A de la sección 12). Hoy, la responsable de la sucursal Norte dice que la ficha de un socio muestra 12 préstamos y su historial solo tiene 9.

Se pide:

• a) Escribir la consulta de auditoría que encuentra todos los socios con el contador descuadrado, mostrando la diferencia.
• b) Escribir el UPDATE que repara el contador de todos ellos.
• c) Proponer tres causas plausibles de la divergencia, teniendo en cuenta que el mantenimiento está en la aplicación.
• d) Proponer el cambio de mecanismo que evitaría que vuelva a ocurrir, y decir qué se gana y qué se paga.

Dirección de BiblioRed pide un cuadro de mando de la actividad de eventos con estas cifras, por sucursal y mes: número de eventos celebrados, número total de inscripciones confirmadas, plazas ofertadas, ocupación media en porcentaje, y valoración media de los informes de evento.

Se pide:

• a) Escribir el CREATE TABLE de la tabla de resumen, con clave primaria y las columnas de control que recomienda la sección 8.
• b) Escribir el INSERT ... SELECT que la carga a partir de eventos, salas, inscripciones e informes_evento, contemplando solo los meses cerrados.
• c) Decidir el mecanismo de refresco y justificarlo.
• d) Escribir la consulta de auditoría que comprueba que una fila del resumen cuadra con los datos operativos.

Solución 1

a) No desnormalizar. La pregunta 1 ya lo resuelve: 4 milisegundos no es un problema. Con 300 consultas diarias, el tiempo total de CPU dedicado a ese JOIN es de poco más de un segundo al día. Introducir una copia de sala_nombre y sala_aforo en eventos significaría además duplicar un dato vivo —el aforo cambia si la sala se reforma, y de hecho es el ejemplo de anomalía de actualización que usamos en 04-01—, así que exigiría un mecanismo de propagación completo. Coste alto, beneficio nulo.

b) Sí desnormalizar: tabla de resumen o vista materializada. Es el caso 2 de la sección 4 en estado puro. 38 segundos × 15 personas = casi diez minutos diarios de espera acumulada, sobre datos que no cambian: los préstamos de años cerrados son inmutables. Además, la pregunta 2 no va a salvarlo: ningún índice acelera significativamente un GROUP BY que recorre las 84.000 filas de todos modos.

La técnica adecuada es una tabla de resumen con granularidad autor-año y una columna cerrado, refrescada una vez al mes por proceso por lotes. Los años pasados se calculan una vez en la vida. El coste de mantenimiento tiende a cero y la consulta pasa de 38 segundos a unos pocos milisegundos.

c) Sí, pero no es una desnormalización opcional: es corrección. Es el caso 3 de la sección 4. El recibo emitido el 12 de marzo dice lo que dice y no puede cambiar: ni si el socio se cambia el nombre, ni si la ordenanza sube la tarifa, ni si la multa se recalifica. Los tres valores deben copiarse en la tabla pagos (o en una tabla recibos) en el momento de emitir el recibo, y no volver a tocarse nunca.

No hace falta mecanismo de mantenimiento —precisamente porque no se propaga nada— y no hay riesgo de inconsistencia. Es la desnormalización más segura y la única de las cuatro que sería un error no hacer.

d) Sí desnormalizar: vista materializada. Es el caso 1 de la sección 4. La relación lecturas/escrituras es abrumadora: 40.000 consultas diarias frente a unos pocos cientos de préstamos y devoluciones. Y la consulta normalizada es un COUNT agrupado sobre ejemplares para cada material, que en la página del catálogo se ejecuta muchas veces.

La técnica es la mv_disponibilidad_material de la sección 9, con refresco programado cada 5 o 10 minutos. La clave está en aceptar el desfase: que el catálogo web diga "2 disponibles" cuando quedan 1 es tolerable, porque el socio comprobará la disponibilidad real al pedirlo. Lo que no sería tolerable es usar esa vista para decidir si se concede un préstamo: para eso hay que consultar ejemplares, que es la fuente de verdad. Es la aplicación exacta de la regla de 03-03: duplica lo que se muestra, nunca lo que se usa para decidir.

Solución 2

a) Consulta de auditoría:

El LEFT JOIN es imprescindible: con un JOIN interno, los socios sin ningún préstamo desaparecerían del resultado, y son precisamente los que pueden tener un contador positivo erróneo.

b) Reparación:

El COALESCE cubre a los socios sin préstamos, cuyo COUNT sobre el LEFT JOIN da 0 pero cuyo subconjunto podría no aparecer. Y la comprobación dentro de la transacción, antes del COMMIT, es la práctica correcta: si el número no es cero, se hace ROLLBACK.

c) Tres causas plausibles, todas características del mantenimiento en la aplicación:

1. Un camino de escritura que no actualiza el contador. El proceso nocturno de importación de préstamos de la biblioteca vecina, o el script de corrección que alguien ejecutó a mano, insertaron en prestamos sin tocar socios. Es la causa más frecuente.
2. Un DELETE no contemplado. Cuando Iván Pereda pidió que se borrara su historial, se borraron las filas de prestamos pero el código solo restaba el contador en el caso de la devolución, no en el del borrado.
3. Una transacción parcialmente confirmada. Si el INSERT y el UPDATE no estaban dentro de la misma transacción, un fallo entre los dos deja el préstamo insertado y el contador sin incrementar. Es un error sutil y produce divergencias de una unidad, muy difíciles de rastrear después.

d) Cambio de mecanismo: pasar a disparador (opción B), y añadir la auditoría por lotes.

El disparador de la sección 12 se ejecuta venga la escritura de donde venga: la aplicación web, el mostrador, el proceso de importación o el psql de un martes por la tarde. Elimina de raíz las causas 1 y 2. Y como se ejecuta dentro de la misma transacción que la operación original, elimina también la 3.

Lo que se gana: coherencia garantizada por el SGBD, no por la disciplina de todos los equipos que escriben.

Lo que se paga: un coste añadido en cada escritura sobre prestamos —notable si alguna vez se hace un UPDATE masivo—; lógica de negocio que vive en la base de datos y no se ve leyendo el código de la aplicación; y una función plpgsql más que probar y mantener.

Y en cualquier caso, la consulta del apartado a) se programa como comprobación nocturna igualmente. Incluso con disparador: si el disparador se desactiva alguna vez para una carga masiva y alguien se olvida de reactivarlo, la auditoría lo detectará esa misma noche.

Solución 3

a) La tabla de resumen:

Las columnas cerrado y actualizado_en son las de control que pedía el enunciado. Los CHECK no son adorno: una tabla derivada con un porcentaje de ocupación del 340 % delata un error en la consulta de carga, y es mejor que lo detecte el INSERT que un directivo en una reunión.

b) La carga:

Tres decisiones que merecen comentario:

• La subconsulta LATERAL para las inscripciones evita el error clásico de multiplicar filas al unir dos tablas de detalle (inscripciones e informes) contra la misma tabla de eventos. Sin ella, un evento con 20 inscripciones y un informe produciría 20 filas y la valoración media se contaría 20 veces. Es exactamente el problema de "inventar filas al reunir" de 05-03, en su versión de agregación.
• e.estado = 'celebrado' excluye los cancelados y los programados, que no deben contar como actividad.
• plazas_ocupadas en lugar de contar inscripciones: la columna generada de inscripciones ya incluye los acompañantes, que es lo que ocupa aforo de verdad.

c) Mecanismo de refresco: proceso por lotes, mensual, el día 1 de cada mes.

La justificación está en la naturaleza del dato. Los meses cerrados no cambian nunca: un evento celebrado en marzo con sus inscripciones y su informe es un hecho consumado. Refrescar más a menudo sería trabajo inútil. Y como el cuadro de mando es una herramienta de dirección que se mira mensualmente, un dato "a cierre del mes pasado" es exactamente lo que se necesita.

El ON CONFLICT ... DO UPDATE permite además reejecutar la carga sin riesgo si un informe de evento se rellena con retraso.

Un disparador aquí sería un error grave: recalcular agregados mensuales en cada inscripción es un coste permanente para un beneficio que se consume una vez al mes.

d) Consulta de auditoría para una fila concreta (marzo de 2026, sucursal Norte):

Si cuadra es f, la tabla de resumen está desviada y hay que reejecutar la carga de ese mes. Programar esta comprobación para el mes anterior, ejecutada semanalmente, es suficiente: los datos de meses cerrados no deberían moverse, y si se mueven es que alguien está corrigiendo datos históricos, que es algo que conviene saber.

Este módulo empezó con una promesa del módulo 4: someter el esquema de BiblioRed a un examen formal que hasta entonces habíamos evitado. Ya está hecho, y conviene mirar el recorrido entero.

En 05-01 construimos el instrumental. Las tres anomalías —de inserción, de actualización y de borrado— dejaron de ser una nota al pie para convertirse en tres fallos que provocamos con SQL sobre la hoja de préstamos. Aprendimos a escribir su causa como dependencia funcional X → Y, a distinguir las totales de las parciales y las transitivas, a deducir con los axiomas de Armstrong, y a calcular el cierre X⁺ para encontrar claves candidatas con un algoritmo en lugar de con intuición.

En 05-02 recorrimos el catálogo. Primera forma normal y la atomicidad que depende del uso; segunda y las dependencias parciales; tercera y las transitivas; Boyce-Codd con su definición de una línea y su letra pequeña sobre la conservación de dependencias; cuarta y las multivaluadas independientes; quinta y la honestidad de decir que casi nunca aparece. Y el criterio que ordena todo: hasta 3FN/FNBC siempre, más allá solo si el caso lo pide.

En 05-03 hicimos el trabajo. De una hoja de cálculo de trece columnas a nueve tablas en FNBC, paso a paso, con los datos delante y el SQL de migración. Aprendimos que INSERT ... SELECT DISTINCT es la forma canónica de migrar, que un error de clave duplicada es el esquema nuevo haciendo su trabajo, que la condición de Heath es lo que separa una descomposición correcta de una que inventa filas, y que en producción se normaliza por fases y no de golpe. Y encontramos un fallo real en el esquema del módulo 4: multas violaba la 3FN por prestamo_id → socio_id, lo que permitía cobrarle a un socio la multa de otro.

Y en esta lección hemos cerrado el círculo con la decisión inversa. Desnormalizar no es lo contrario de normalizar: es lo que se hace después de normalizar, sobre un esquema que ya es correcto, para conseguir algo concreto que ese esquema no daba. Hemos visto las siete técnicas —columna redundante, columna generada, atributo duplicado, tabla de resumen, vista materializada, historial plano, esquema en estrella—, las tres formas de mantener la coherencia con sus garantías y sus costes, y las siete preguntas que hay que responder por escrito antes de tocar nada. Hemos visto también que el caso más fuerte para desnormalizar no es el rendimiento sino la corrección: el importe de una multa, el nombre en un recibo y la tarifa de una factura son datos históricos congelados, y guardarlos no es una concesión, es la única respuesta correcta. Y hemos reconocido que el modelado documental de 03-03 es esta misma disciplina llevada al centro del método, con las mismas categorías y las mismas obligaciones.

La regla de oro resume el módulo entero: primero normaliza, después desnormaliza a propósito, midiendo, y nunca al revés. Un esquema normalizado del que se ha retrocedido en dos puntos concretos, documentados, medidos y auditados, es un buen esquema. Un esquema redundante que nunca pasó por la normalización no es un esquema desnormalizado: es un esquema sin diseñar.

Con esto se cierra el módulo 5, Normalización. El esquema de BiblioRed ha pasado el examen, con un fallo detectado y corregido y cuatro desnormalizaciones ahora justificadas y escritas. Sabemos que la estructura es correcta y que los datos no pueden contradecirse. Lo que todavía no sabemos es qué ocurre cuando dos personas del mostrador registran un préstamo del mismo ejemplar en el mismo instante, ni qué pasa si el servidor se apaga a mitad de una operación, ni cuánto tarda de verdad una consulta cuando la tabla tiene diez millones de filas, ni quién puede leer los teléfonos de los socios. En el módulo 6, Transacciones, Rendimiento y Seguridad, dejamos de mirar el esquema y empezamos a mirar el sistema en funcionamiento: las transacciones y las propiedades ACID que garantizan que una operación ocurre entera o no ocurre (06-01); la concurrencia y los niveles de aislamiento que deciden qué ve cada usuario mientras otro escribe (06-02); los índices y los planes de ejecución, que son —recuérdalo— lo primero que hay que probar antes de desnormalizar (06-03); y la seguridad, los permisos y las copias de seguridad, que es lo que separa una base de datos de un accidente esperando a ocurrir (06-04).