OLTP vs. Data Warehouse: por qué tu base transaccional no es suficiente para BI

debate opinión entretenimiento

Fecha de Publicación: 13/03/2026

opinion

Un gerente de TI con un sistema OLTP robusto y 10 años de datos históricos te dice que un Data Warehouse es "redundancia costosa". Aquí está la respuesta técnica que necesitas tener lista.

El argumento del Gerente de TI

Es un escenario clásico. ElectroHogar S.A.S. opera con un sistema transaccional que registra cada venta en 10 ciudades del país: cantidad, precio, cliente, tienda. El Gerente de TI tiene razón en un punto: los datos sí están ahí. Todos. Con timestamps precisos. Normalizados hasta la 3FN.

"Nuestro sistema OLTP captura absolutamente todos los datos de la empresa (históricos y actuales) y es capaz de generar cualquier reporte solicitado mediante consultas directas. Un Data Warehouse es redundancia costosa y un gasto innecesario."
— Gerente de TI, ElectroHogar S.A.S.

El problema no es la disponibilidad de los datos. Es para qué fue diseñado el sistema que los almacena.

El choque de propósitos: OLTP vs. OLAP

Un sistema OLTP (Online Transaction Processing) está optimizado para operaciones de escritura rápidas, atómicas y concurrentes. Un Data Warehouse está optimizado para lecturas analíticas sobre grandes volúmenes históricos. Son objetivos de diseño fundamentalmente opuestos.

criterio	OLTP (sistema transaccional)	Data Warehouse
propósito	Registrar operaciones del negocio en tiempo real	Analizar patrones históricos para toma de decisiones
usuarios	Personal operativo: cajeros, vendedores, logística	Gerencia, analistas BI, equipo comercial y mercadeo
datos	Detallados y actuales — filas individuales de transacciones	Históricos y agregados — optimizados para sumarizaciones
modelo	Normalizado (3FN) — minimiza redundancia de escritura	Desnormalizado (estrella/copo de nieve) — minimiza JOINs de lectura
consultas	Simples, pocas filas, alta frecuencia (ms)	Complejas, millones de filas, baja frecuencia (segundos)
concurrencia	Miles de escrituras simultáneas sin bloqueo	Lecturas analíticas con locks tolerables
impacto de reportes	Alto — un GROUP BY sobre ventas históricas puede bloquear operaciones	Ninguno — sistema separado, cero impacto operacional
integraciones	Fuente única (sistema transaccional)	Múltiples fuentes integradas vía ETL
herramientas BI	Compatibilidad limitada, modelos de datos complejos	Conexión nativa con Power BI, Tableau, Looker

El problema concreto de ElectroHogar

Los datos de ElectroHogar viven en archivos CSV separados: tiendas, productos, clientes, tiempo y ventas. No hay un modelo unificado. Para responder "¿cuál fue el margen por subcategoría en Barranquilla durante el Q3 2024?" en el OLTP se necesita:

-- Consulta analítica sobre OLTP normalizado SELECT p.Subcategoria, t.Ciudad, SUM(v.TotalVenta) AS ingresos, SUM(v.MargenTotal) AS margen FROM ventas v JOIN productos p ON v.IdProducto = p.IdProducto JOIN tiendas t ON v.IdTienda = t.IdCiudad JOIN tiempo ti ON v.IdTiempo = ti.IdTiempo WHERE t.Ciudad = 'Barranquilla' AND ti.Trimestre = 3 AND ti.Anio = 2024 GROUP BY p.Subcategoria, t.Ciudad; -- Resultado: full table scan sobre ventas históricas. -- Con 3 años de operación → potencialmente millones de filas. -- Ejecutado en horario pico → bloqueo de operaciones en caja.

En el Data Warehouse con esquema estrella, la misma consulta opera sobre tablas precalculadas y optimizadas para aggregation. Power BI ni siquiera necesita escribir ese SQL: lo hace internamente en milisegundos con columnar storage.

El modelo propuesto: esquema estrella

Para ElectroHogar se propone una Fact_Ventas central con cuatro dimensiones. La granularidad es por transacción individual, lo que permite desde el detalle hasta cualquier nivel de agregación.

esquema estrella — dw electrohogar

Dim_Tiempo

IdTiempo PK
Fecha · Dia · Mes
Trimestre · Anio
DiaSemana · EsFinSemana

Dim_Producto

IdProducto PK
ProductoNombre · Marca
Categoria · Subcategoria
Precio

FACT_VENTAS

IdVenta PK
FK: Tiempo · Producto
FK: Cliente · Tienda
─────────
Cantidad
TotalVenta
CostoUnitario
MargenTotal

Dim_Cliente

IdCliente PK
Nombre · Segmento
Ciudad · Sexo · Edad

Dim_Tienda

IdCiudad PK
Ciudad · Departamento
Region

El argumento que le falta al Gerente de TI

El sistema OLTP no está en discusión. Seguirá siendo la fuente de verdad operacional. El DW no lo reemplaza: lo complementa. El proceso ETL extrae los CSV transaccionales, los transforma (limpieza, estandarización, enriquecimiento) y los carga al modelo dimensional. Son dos sistemas con responsabilidades distintas.

veredicto técnico

Ejecutar consultas analíticas complejas sobre el OLTP en producción es un antipatrón de arquitectura. Degrada el rendimiento transaccional, no escala con el crecimiento del histórico y hace que Power BI trabaje contra un modelo normalizado para el cual no fue diseñado. El Data Warehouse no es redundancia: es especialización de responsabilidades.

Discussion (0)

Fecha de Publicación: 16/04/2024

Explorando las Novedades de PHP 8.2: Mejoras y Optimizaciones

Fecha de Publicación: 16/04/2024

Explorando las Bases de Datos Relacionales: Fundamentos y Aplicaciones

Fecha de Publicación: 16/04/2024

Descubriendo las Bases de Datos No Relacionales: Un Mundo Más Allá de las Tablas

Fecha de Publicación: 16/04/2024

Base de Datos Relacional vs. Base de Datos No Relacional: Comprendiendo las Diferencias y las Elecciones Correctas

Fecha de Publicación: 18/04/2024

Guía rápida para iniciar un proyecto con NestJS

Fecha de Publicación: 17/04/2024

Configuracion de apache2

Fecha de Publicación: 29/04/2024

Un hito histórico: Microsoft abre el código de MS-DOS

Fecha de Publicación: 01/03/2025

Mi portafolio

Fecha de Publicación: 13/03/2026