En bases de datos transaccionales, la redundancia es el enemigo. Normalizar significa eliminar duplicación: cada dato vive en un solo lugar, y las relaciones se resuelven con claves foráneas. Si el nombre de un cliente aparece en dos tablas, algo está mal.
En modelado analítico, la lógica es distinta. Desnormalizar es parte del diseño. Las dimensiones repiten atributos que en el transaccional estarían separados. Las tablas de hechos pueden contener métricas derivadas de otras tablas. Y eso está bien, siempre que se cumpla una condición: que haya una sola definición del concepto y que el linaje sea claro.
Desnormalización con propósito
El modelo dimensional de Kimball propone desnormalizar para facilitar el consumo. Una dimensión de producto incluye la categoría, la subcategoría, la marca, el proveedor, todo en la misma tabla. En un modelo normalizado, esos atributos estarían en tablas separadas con sus propias claves.
La razón es práctica: cuando un analista quiere filtrar ventas por categoría de producto, no debería tener que hacer tres joins para llegar al dato. La dimensión desnormalizada permite que la consulta sea directa.
Esto implica redundancia. Si dos productos tienen la misma categoría, el nombre de esa categoría aparece repetido en ambos registros. En el mundo transaccional, eso sería un problema de integridad. En el mundo analítico, es una decisión de diseño que prioriza la usabilidad sobre la normalización.
Cuándo la redundancia se vuelve problema
La redundancia deja de ser aceptable cuando el mismo concepto se define de forma distinta en dos lugares.
Imaginá que tenés una tabla de hechos de ventas y otra de hechos de devoluciones. Ambas necesitan calcular el "monto neto" de una transacción. Si cada tabla calcula ese monto con su propia lógica, sin derivar de una definición común, vas a tener dos números que deberían coincidir pero no coinciden.
Lo que falta ahí es una sola definición de qué significa "monto neto" y cómo se calcula. Que el monto aparezca en dos tablas no es el problema, que cada tabla lo calcule distinto sí.
Un equipo construye una tabla de hechos para un proceso de negocio. Meses después, otro equipo construye otra tabla para otro proceso. Ambos necesitan la misma métrica, pero cada uno la implementa a su manera. Cuando alguien intenta cruzar los datos, los números no cierran.
Linaje como control
El linaje es la trazabilidad de cómo se construyó un dato: de dónde viene, qué transformaciones sufrió, qué reglas de negocio se aplicaron.
Cuando hay linaje claro, la redundancia deja de ser un riesgo. Si una tabla de hechos deriva sus métricas de otra tabla que ya tiene las definiciones correctas, la redundancia es controlada. Sabés que el dato de la segunda tabla viene de la primera, con las mismas reglas.
Si una tabla de hechos de resumen consume datos de una tabla de hechos granular, y ambas usan las mismas reglas de cálculo, la redundancia es aceptable. El resumen es una derivación controlada del granular. Si alguien pregunta de dónde sale un número, la respuesta es clara.
Derivar en lugar de calcular en paralelo
La recomendación práctica es que las tablas derivadas consuman de las tablas base, no que calculen en paralelo desde las fuentes de origen.
Si tenés una tabla de hechos granular con ventas por transacción, y necesitás una tabla agregada con ventas por mes y región, la tabla agregada debería derivar de la granular. No debería ir a las fuentes de origen y recalcular todo desde cero.
Esto tiene dos ventajas. Primero, garantiza consistencia: si la definición de "venta" cambia, cambia en un solo lugar y se propaga a las derivadas. Segundo, simplifica el debugging: si un número no cierra, podés rastrear la cadena de derivación hasta encontrar dónde está el problema.
Cuando cada tabla calcula desde las fuentes de origen de forma independiente, perdés ambas cosas. Las definiciones se dispersan, y rastrear un error se vuelve un ejercicio de arqueología.
Redundancia controlada vs redundancia accidental
La diferencia entre un modelo que escala y uno que se degrada está en si la redundancia es intencional o accidental.
En un modelo con buen gobierno: las dimensiones están desnormalizadas para facilitar el consumo, las tablas derivadas consumen de las tablas base, las métricas tienen una sola definición, y el linaje es explícito. Si el mismo dato aparece en dos tablas, hay una razón documentada.
En un modelo sin gobierno: cada área tiene su propia versión de las métricas clave, las tablas duplican lógica existente sin derivar de una base común, y cuando los números no coinciden, nadie sabe cuál es el correcto.
Herramientas que ayudan
Las herramientas modernas de transformación, como dbt, facilitan este tipo de gobierno. El grafo de dependencias muestra qué tablas consumen de qué otras. La documentación vive junto al código. Los tests validan que las definiciones se cumplan.
Pero la herramienta no resuelve el problema por sí sola. Si el equipo construye tablas que calculan en paralelo sin derivar de una base común, el grafo va a mostrar eso: múltiples caminos que llegan al mismo concepto desde distintos orígenes.
El gobierno del modelo es una disciplina, no una funcionalidad. La herramienta puede facilitarlo, pero la decisión de mantener definiciones únicas y linaje claro es del equipo.
En resumen
La redundancia en un modelo analítico no es inherentemente mala. Desnormalizar es parte del diseño dimensional. Repetir datos para facilitar el consumo es una decisión válida.
Lo que sí es un problema es que el mismo concepto se defina de forma distinta en dos lugares. Cuando eso pasa, los números no cierran, nadie sabe cuál es la fuente de verdad, y el modelo pierde credibilidad.
La solución es linaje claro y definiciones únicas. Las tablas derivadas consumen de las tablas base. Las métricas se calculan una vez y se propagan. Si hay redundancia, es intencional y trazable.
Lo que importa es el linaje, no la ausencia de redundancia.