Cuando hay que aprobar presupuesto para un proyecto de data warehouse, la objeción más común es: "¿para qué necesitamos eso si las métricas se pueden sacar del transaccional?". Y muchas veces tienen razón. Si lo único que necesitás es un reporte mensual de ventas, probablemente puedas sacarlo con una query sobre la base de producción.
El problema aparece cuando esa query empieza a competir con las operaciones del negocio, cuando el analista necesita entender la lógica de la aplicación para hacer una pregunta simple, o cuando tres áreas calculan la misma métrica de tres formas distintas y nadie sabe cuál es la correcta.
Ahí es donde la distinción entre OLTP y OLAP deja de ser una cuestión técnica y se convierte en una decisión de negocio.
Dos mundos con objetivos distintos
OLTP significa Online Transaction Processing. Es el mundo de las bases de datos que le dan soporte al negocio: registrar una venta, crear un usuario, actualizar un inventario. Cada operación es una transacción que tiene que ser rápida, consistente y confiable.
En OLTP, el diseño está optimizado para escribir mucho, muy rápido, con mucho volumen. Por eso se normaliza: se evita la redundancia, se separan las entidades, se garantiza la integridad. Una tabla de clientes, otra de pedidos, otra de productos, cada una con su clave primaria y sus relaciones.
OLAP significa Online Analytical Processing. Es el mundo de las bases de datos que responden preguntas de negocio: cuánto vendimos el mes pasado, qué clientes están en riesgo de irse, qué productos tienen mejor margen. Cada consulta puede tocar millones de registros y cruzar múltiples dimensiones.
En OLAP, el diseño está optimizado para leer y agregar. Por eso se desnormaliza: se repiten datos, se precomputan métricas, se organizan las tablas para que las consultas sean intuitivas. Dimensiones que describen (quién, qué, cuándo) y hechos que miden (cuánto, cuántos).
El problema de usar OLTP para análisis
Cuando alguien intenta hacer análisis directamente sobre el modelo transaccional, pasan varias cosas.
Primero, las queries se vuelven complicadas. Para responder "cuántos contenidos creó cada tipo de suscripción el mes pasado" hay que hacer joins entre cinco tablas, filtrar por fechas, agrupar por atributos que están dispersos. El SQL termina siendo un laberinto.
Segundo, el rendimiento se degrada. Las bases transaccionales están optimizadas para operaciones puntuales, no para escanear millones de registros. Pegarle con queries pesadas a una base OLTP puede afectar las operaciones del negocio.
Tercero, y esto es lo más importante: el modelo no está pensado para responder esas preguntas. Las tablas reflejan cómo opera el sistema, no cómo piensa el negocio. Un analista que mira el modelo transaccional tiene que entender la lógica de la aplicación para poder hacer una pregunta simple.
El modelo dimensional como puente
El modelado dimensional, formalizado por Kimball en los 90, propone una forma de organizar datos que sigue siendo la más efectiva para análisis. La idea es simple: separar lo que describe (dimensiones) de lo que mide (hechos).
Una dimensión es una tabla que contiene atributos descriptivos: el cliente con su nombre, su segmento, su fecha de alta. El producto con su categoría, su marca, su precio. El tiempo con su día, su mes, su trimestre.
Un hecho es una tabla que contiene métricas asociadas a un evento: una venta con su monto, su cantidad, su descuento. Una creación de contenido con su duración, su tipo, su fecha.
El modelo resultante tiene forma de estrella: una tabla de hechos en el centro, rodeada de dimensiones. Cada fila del hecho tiene claves que apuntan a las dimensiones relevantes.
Este diseño tiene una ventaja que no es obvia: cualquier persona de negocio puede mirar el modelo y entender qué se está midiendo. No hace falta conocer la lógica de la aplicación. Las preguntas se traducen directamente a queries: "ventas por región y mes" es un join entre el hecho de ventas, la dimensión de geografía y la dimensión de tiempo.
Por qué esto importa más allá de la técnica
La separación entre OLTP y OLAP no es un capricho de arquitectura: tiene consecuencias concretas en cómo el equipo trabaja con datos.
Si no hay un modelo analítico explícito, cada persona que necesita un número lo calcula a su manera. El área comercial tiene su Excel con su definición de "cliente activo". Finanzas tiene otra. Marketing tiene una tercera. Cuando los números no coinciden, nadie sabe cuál es el correcto.
Si hay un modelo dimensional bien diseñado, las definiciones están en un solo lugar. "Cliente activo" significa lo mismo para todos porque está modelado una vez. Los reportes son consistentes porque parten de la misma base.
Esto no se resuelve con una herramienta de BI ni con un data lake. Se resuelve con un modelo de datos pensado para responder preguntas de negocio.
Qué viene en esta colección
Este artículo abre una colección sobre modelado analítico en la práctica. Los temas que siguen profundizan en las decisiones de diseño que aparecen cuando pasás de la teoría a la implementación:
- Por qué el modelo debe definirse antes que los pipelines, no después
- Cómo mantener historia en dimensiones sin que el proceso de carga se vuelva inmanejable
- Cómo manejar redundancia sin perder consistencia
- Cómo definir el grano de una tabla de hechos y qué pasa cuando lo violás
- Cómo tratar métricas que no se pueden sumar en todas las dimensiones
- Cómo reutilizar dimensiones entre distintos procesos de negocio
Cada artículo es independiente, pero comparten un hilo: las decisiones de modelado no son técnicas aisladas. Son decisiones de diseño que determinan si el equipo puede confiar en los datos o no.
En resumen
OLTP y OLAP no son dos formas de hacer lo mismo con distinta velocidad. Son dos mundos con propósitos distintos.
OLTP registra transacciones. OLAP responde preguntas de negocio.
Confundir esto lleva a modelos que no sirven para ninguna de las dos cosas: bases transaccionales sobrecargadas con queries analíticas, o warehouses que replican la estructura del sistema origen sin agregar valor.
El modelado dimensional es el puente entre ambos mundos. Y entenderlo bien es lo que separa a un equipo que tiene datos de un equipo que puede usarlos.