Cuando diseñás una tabla de hechos, lo primero que definís es el grano: qué representa cada fila. Una venta individual. Un evento de suscripción. Una interacción de usuario con un contenido. Esa definición parece un detalle técnico, pero es el contrato fundamental del modelo.
El grano determina qué preguntas podés responder con esa tabla. Y también determina qué métricas tienen sentido ahí.
Qué significa el grano
El grano responde una pregunta simple: ¿qué representa una fila de esta tabla?
En una tabla de hechos de ventas, el grano podría ser "una línea de una transacción de venta". Cada fila representa un producto vendido en una transacción específica, en una fecha específica, a un cliente específico.
En una tabla de hechos de suscripciones, el grano podría ser "el estado de una suscripción de una cuenta en una fecha". Cada fila representa qué suscripción tenía una cuenta en un momento dado, si estaba vigente, cuándo empezó, cuándo terminó.
El grano no es un detalle de implementación. Es la definición de qué estás midiendo. Si no tenés claro el grano, no tenés claro qué significa cada número en la tabla.
Métricas que respetan el grano
Una vez definido el grano, las métricas que agregues deben poder calcularse a ese nivel de detalle.
Si el grano es "una línea de venta", las métricas válidas son las que tienen sentido para esa línea: cantidad vendida, precio unitario, monto de la línea, descuento aplicado. Cada una de esas métricas se puede calcular para cada fila sin necesidad de agregar otras filas.
Si el grano es "un contenido creado por una cuenta en una fecha", las métricas válidas son las que tienen sentido para ese evento: duración del contenido, categoría, si fue el primer contenido de la cuenta. Métricas que se pueden determinar mirando solo esa fila.
Métricas que violan el grano
El problema aparece cuando agregás una métrica que requiere un nivel de agregación distinto al grano de la tabla.
Supongamos que tenés una tabla de hechos de contenidos creados, donde el grano es "un contenido creado por una cuenta en una fecha". Alguien propone agregar una métrica: "cantidad promedio de contenidos que crea la cuenta por mes".
Esa métrica viola el grano. Para calcular un promedio mensual, necesitás agregar todos los contenidos de la cuenta en el mes. Pero cada fila de tu tabla representa un contenido individual. Estás mezclando dos niveles de detalle en la misma tabla.
El número va a existir, vas a poder calcularlo y ponerlo en la columna. Pero va a ser el mismo número repetido en todas las filas del mismo mes para la misma cuenta. Y cuando alguien sume esa columna pensando que está sumando algo útil, va a obtener basura.
El grano como contrato
El grano funciona como un contrato entre quien diseña el modelo y quien lo consume.
Cuando un analista ve una tabla de hechos, asume que puede sumar las métricas y obtener totales válidos. Si el grano es "línea de venta", sumar el monto de todas las filas da el total de ventas. Si el grano es "evento de suscripción", contar las filas da la cantidad de eventos.
Cuando metés una métrica que viola el grano, rompés ese contrato. El analista suma una columna y obtiene un número que no significa nada. O peor: obtiene un número que parece significar algo pero está mal.
Dónde van las métricas agregadas
Si necesitás métricas que requieren un grano distinto, la solución es otra tabla.
Siguiendo el ejemplo anterior: si necesitás "cantidad promedio de contenidos por cuenta por mes", esa métrica pertenece a una tabla con grano "cuenta-mes". Esa tabla deriva de la tabla granular de contenidos, pero tiene su propio grano y sus propias métricas.
La tabla granular sigue existiendo. Sirve para análisis detallado, para debugging, para derivar otras tablas. La tabla agregada existe para responder preguntas que requieren ese nivel de consolidación.
Esto conecta con lo que vimos sobre derivación: la tabla agregada consume de la tabla granular, no calcula en paralelo desde las fuentes de origen. El linaje es claro, las definiciones son consistentes.
Tablas de hechos sin métricas numéricas
Un caso especial: a veces el grano del evento es el aporte analítico, sin necesidad de métricas numéricas tradicionales.
Una tabla de hechos de "asignaciones de cuenta a vendedor" podría tener como grano "una asignación de una cuenta a un vendedor en una fecha". Las columnas son las claves a las dimensiones: cuenta, vendedor, fecha de inicio, fecha de fin. No hay monto, no hay cantidad.
Kimball llama a esto "tabla de hechos sin hechos". El valor está en poder cruzar las dimensiones y responder preguntas como "qué cuentas tenía asignadas este vendedor en este período". El grano sigue siendo el contrato fundamental, aunque no haya métricas para sumar.
Validar el grano antes de agregar métricas
Antes de agregar una métrica a una tabla de hechos, la pregunta es: ¿esta métrica tiene sentido para cada fila individual?
Si la respuesta es sí, la métrica respeta el grano. Si la respuesta es "solo tiene sentido si agrupo por X", la métrica pertenece a otra tabla con ese grano.
Esto parece obvio cuando lo leés, pero en la práctica es fácil de violar. Alguien necesita un número, la tabla de hechos ya existe, agregar una columna parece más rápido que crear otra tabla. El número aparece, los reportes funcionan, y el problema queda latente hasta que alguien intenta usar esa columna de una forma que el diseñador no anticipó.
En resumen
El grano de una tabla de hechos define qué representa cada fila. Esa definición no es negociable: es el contrato que permite que las métricas tengan sentido.
Cualquier métrica que agregues debe poder calcularse a ese nivel de detalle. Si la métrica requiere agregar filas para tener sentido, pertenece a otra tabla con otro grano.
Mantener esta disciplina evita que el modelo se degrade con el tiempo. Cada tabla tiene un propósito claro, las métricas son coherentes con el grano, y quien consume el modelo puede confiar en que sumar una columna produce un resultado válido.