Tabla de Hechos (Fact Table)

Definición

Una tabla de hechos (fact table) es la tabla central en un modelo dimensional que contiene las filas que registran eventos de negocio medibles. Cada fila representa una ocurrencia de un evento —una venta completada, un pedido procesado, una sesión de usuario iniciada, un pago recibido— junto con las medidas numéricas asociadas a ese evento: el monto facturado, las unidades vendidas, la duración de la sesión, el importe cobrado. La tabla de hechos se conecta al resto del modelo mediante llaves foráneas que apuntan a las tablas de dimensiones, las cuales proveen el contexto descriptivo para cada evento.

La característica estructural más importante de una tabla de hechos es su forma: alta y estrecha. Alta porque registra cada evento discreto —un warehouse de comercio electrónico mediano puede tener cientos de millones de filas en su tabla de hechos de pedidos—. Estrecha porque el número de columnas es reducido: típicamente entre 5 y 20 columnas, compuestas principalmente por las llaves foráneas a las dimensiones y por las medidas numéricas del evento. Esta geometría específica es la que permite a los motores analíticos de almacenamiento columnar —BigQuery, Snowflake, Redshift, Databricks— ejecutar escaneos de alta velocidad sobre miles de millones de filas.

El concepto de tabla de hechos fue formalizado por Ralph Kimball en la disciplina de business intelligence durante los años 90 y sigue siendo el patrón dominante para el diseño de esquemas analíticos en 2025. La razón de su longevidad es simple: la separación entre hechos (qué ocurrió y cuánto) y dimensiones (quién, qué, dónde, cuándo, por qué) mapea directamente sobre la forma en que los analistas formulan preguntas de negocio, y esa correspondencia hace que los modelos dimensionales sean más intuitivos de consultar que cualquier alternativa normalizada.

Cómo se implementa

El diseño de una tabla de hechos comienza siempre con la declaración del grano: la unidad mínima de medición que representará cada fila. Esta decisión precede a cualquier otra consideración de diseño. Por ejemplo, una tabla de hechos de ventas puede tener el grano "una línea de pedido de un pedido de ventas" —cada fila es un producto dentro de un pedido— o el grano "un pedido de ventas" —cada fila es un pedido completo con sus totales—. Ambos granos son válidos, pero requieren tablas separadas porque responden preguntas diferentes y tienen medidas diferentes.

Las medidas de la tabla de hechos se dividen en tres categorías según su comportamiento de agregación. Las medidas aditivas se pueden sumar por cualquier dimensión sin restricciones: el monto de ventas en pesos se puede sumar por día, por producto, por cliente o por cualquier combinación. Las medidas semi-aditivas se pueden sumar por algunas dimensiones pero no por tiempo: el saldo de inventario al cierre del día se puede sumar por SKU para obtener el inventario total, pero no tiene sentido sumar el saldo del lunes con el del martes para obtener el "inventario semanal". Las medidas no aditivas son ratios o porcentajes que no se pueden agregar directamente: el margen bruto porcentual no se puede promediar directamente, sino que debe calcularse dividiendo la suma del margen bruto entre la suma del ingreso bruto.

Ejemplo práctico

Considere una distribuidora mayorista con sede en Monterrey que vende productos de consumo a tiendas de conveniencia y supermercados en México y Colombia. El equipo de datos está diseñando el data warehouse para reportar métricas de ventas, margen y rendimiento por canal.

El equipo define el grano de la tabla de hechos principal como "una línea de pedido de un pedido de ventas confirmado". Cada fila registra la venta de un SKU específico a un cliente específico en una fecha específica a través de un canal específico. Las medidas incluyen: cantidad_cajas, precio_unitario_mxn, descuento_linea_mxn, costo_landed_mxn, y flete_prorateado_mxn.

Con esta estructura, el analista de operaciones puede responder preguntas como: ¿Cuál fue el margen bruto por línea de producto en el tercer trimestre en Bogotá? ¿Qué canales de distribución tienen el ticket promedio más alto? ¿Qué clientes generaron más de $500,000 MXN en compras en los últimos 90 días? Todas estas preguntas se resuelven uniendo la tabla de hechos con las dimensiones de producto, geografía, canal y tiempo respectivamente — sin necesidad de transformaciones adicionales ni tablas de reporte precalculadas.

Para las métricas de inventario — stock disponible al cierre de cada semana — el equipo crea una segunda tabla de hechos separada con grano "un SKU en un almacén en un día". Esta tabla es un snapshot periódico que registra el estado del inventario al cierre de cada jornada. Mantener dos tablas de hechos separadas con granos distintos, en lugar de mezclarlos en una sola tabla, preserva la claridad del modelo y evita errores de doble conteo al cruzar ventas con inventario.

Análisis en profundidad

Los tres tipos de tablas de hechos —transaccional, snapshot periódico y snapshot acumulado— sirven propósitos analíticos distintos y no son intercambiables. La tabla transaccional es la más común: registra cada evento en el momento en que ocurre con la granularidad más fina posible. El snapshot periódico registra el estado de una métrica en intervalos regulares, independientemente de si hubo actividad en ese intervalo —el hecho de que un almacén no haya realizado ventas en un martes no significa que su inventario sea cero, y el snapshot periódico captura ese estado de forma natural sin necesidad de lógica de imputación especial—. El snapshot acumulado registra el ciclo de vida completo de un proceso de negocio en una sola fila que se actualiza conforme el proceso avanza — por ejemplo, el pipeline de ventas donde una fila por oportunidad se actualiza con la fecha de cada etapa alcanzada (prospecto, calificado, propuesta enviada, contrato firmado, facturado).

La tabla de hechos sin medidas — la "factless fact table" — es un patrón frecuentemente malentendido pero valioso. Registra la ocurrencia de un evento sin ninguna medida numérica asociada. Por ejemplo, una tabla que registra qué estudiantes asistieron a qué clases en qué fechas tiene un grano definido (una asistencia) pero ninguna medida numérica más allá del hecho de la ocurrencia. Su utilidad radica en responder preguntas de presencia y ausencia: ¿Qué productos estaban disponibles para la venta en cada tienda en cada día de la semana de Buen Fin, aunque no se hayan vendido? La tabla factless se une a las dimensiones de producto, tienda y tiempo para identificar los espacios del cruce que no aparecen en la tabla transaccional.

El manejo de las llaves foráneas en la tabla de hechos merece atención especial. El modelado dimensional de Kimball especifica el uso de llaves sustitutas (surrogate keys) —enteros autogenerados— en lugar de llaves naturales de los sistemas fuente. La razón es pragmática: las llaves naturales de los sistemas transaccionales cambian, se reutilizan, varían entre sistemas fuente, y complican el seguimiento de cambios históricos en las dimensiones (Slowly Changing Dimensions). Las llaves sustitutas son estables, compactas y permiten que la tabla de hechos permanezca inmutable incluso cuando los atributos de una dimensión cambian — un cliente que cambia de segmento de mercado en el sistema CRM no requiere modificar la tabla de hechos histórica; solo requiere un nuevo registro en la dimensión de cliente con la nueva categorización.

El problema del grano mixto es el error de diseño más costoso en la construcción de tablas de hechos. Ocurre cuando se mezclan filas de diferentes granularidades en la misma tabla: por ejemplo, combinar en la misma tabla filas a nivel de línea de pedido con filas a nivel de resumen de pedido. El resultado es que las agregaciones producen doble conteo en algunas columnas, los analistas obtienen resultados inconsistentes dependiendo de cómo filtran la tabla, y la confianza en el modelo se erosiona. La corrección habitual requiere dividir la tabla en dos tablas separadas con granos distintos y reconstruir todos los reportes afectados — un trabajo costoso que se puede evitar completamente con una declaración explícita del grano antes de comenzar la implementación.

La relación entre la tabla de hechos y el star schema es central para entender el rendimiento analítico. En un star schema bien diseñado, las queries analíticas siguen el mismo patrón: FROM fact_table JOIN dim_X ON fact_table.x_id = dim_X.id WHERE filtros_de_dim GROUP BY atributos_de_dim. Los motores de warehouses columnar modernos han optimizado sus planes de ejecución específicamente para este patrón, usando técnicas como predicado pushdown (aplicar filtros de dimensión antes del JOIN), pruning de particiones sobre columnas de tiempo, y materialización de agregaciones frecuentes. La tabla de hechos bien diseñada es la que permite que esas optimizaciones sean efectivas — una tabla con granos mixtos, columnas sin particionar o llaves naturales inconsistentes neutraliza esas ventajas.

Errores frecuentes

• ✗

  No declarar el grano antes de diseñar la tabla. Comenzar a poblar una tabla de hechos sin haber definido explícitamente el grano produce tablas con filas de granularidades mezcladas. Una vez que la tabla existe y tiene dependencias en reportes y dashboards, corregir el grano requiere una reingeniería completa del modelo. El grano debe estar documentado en el contrato de datos del modelo y revisado por todos los consumidores antes de que la tabla entre en producción.

• ✗

  Almacenar atributos descriptivos en la tabla de hechos. Incluir en la tabla de hechos columnas como nombre_cliente, categoria_producto o region_geografica viola el principio de separación entre hechos y dimensiones. Esos atributos pertenecen a las tablas de dimensión. Almacenarlos en la tabla de hechos duplica datos, complica las actualizaciones cuando los atributos cambian, e impide el seguimiento de cambios históricos mediante Slowly Changing Dimensions.

• ✗

  Usar llaves naturales de sistemas fuente como llaves foráneas. Las llaves naturales — IDs de CRM, códigos de ERP, SKUs de catálogo — cambian, se reutilizan y difieren entre sistemas fuente. Una tabla de hechos que usa llaves naturales directamente no puede manejar correctamente los cambios históricos en las dimensiones (SCD Tipo 2), produce errores de JOIN cuando los sistemas fuente cambian sus identificadores, y dificulta la integración de datos de múltiples sistemas en una misma tabla de dimensión conformed.

Cómo lo rastrea Fairview

Fairview construye su capa de datos operativos sobre un modelo dimensional donde las tablas de hechos centrales —transacciones, eventos de facturación, interacciones de producto— se conectan a dimensiones conformadas de cliente, canal, producto y tiempo. Cuando una empresa conecta sus fuentes de datos a Fairview, la plataforma mapea automáticamente los eventos de cada fuente hacia el grano correcto de la tabla de hechos correspondiente, aplicando llaves sustitutas para garantizar que los cambios históricos en clientes o productos queden trazados correctamente sin alterar el historial de transacciones. El data mart de cada área funcional —ventas, finanzas, operaciones— expone solo las tablas de hechos y dimensiones relevantes para esa área, lo que reduce la complejidad de consulta para los analistas de negocio sin acceso a SQL avanzado.

Las métricas del Operating Dashboard de Fairview —MRR, margen bruto, costo por adquisición, eficiencia operativa— se calculan en tiempo real sobre las tablas de hechos actualizadas por los conectores de Stripe, Shopify, QuickBooks y demás fuentes integradas. Cada métrica tiene una definición de grano explícita documentada en el catálogo de datos de la plataforma, lo que garantiza que los números que ve el COO en el dashboard corresponden exactamente a la misma definición que usa el equipo de finanzas en sus modelos de planificación.

Preguntas frecuentes