Última actualización: 2026-11-11

Contenido de esta página

• ¿Qué es un data warehouse?
• ¿Para qué sirve un data warehouse?
• Inmon vs Kimball: dos maneras de construir el almacén
• ¿Cómo llegan los datos al almacén?
• Un ejemplo colombiano: la bodega de datos del SISPRO
• Una consulta analítica, en pequeño
• Lo que se desarrolla aparte: arquitectura, modelos, data marts, nube y lago
• La pregunta de fondo no es Inmon o Kimball

En enero de 2013, el Ministerio de Salud y Protección Social presentó el sistema con el que reúne la información del sector salud de Colombia [1]. Una de las diapositivas enumeraba seis premisas de trabajo. La quinta decía, sin rodeos: «La Fuente de los datos es la única que puede modificarlos» [1].

La frase parece un trámite. No lo es.

Quiere decir que el lugar donde el Ministerio consulta los datos no es el lugar donde esos datos nacen. Una afiliación, un pago de aportes o una atención médica se registran en otro sistema, que tiene su propio dueño. El sistema del Ministerio los recibe, los junta y los ofrece para consultar. Si un dato viene mal, el arreglo le toca a quien lo produjo [1].

Esa división del trabajo tiene nombre. El propio documento la llama «Bodega de Datos» [1]. En el resto del mundo se le dice data warehouse.

¿Qué es un data warehouse?

Un data warehouse, en español almacén de datos o bodega de datos, es una base de datos construida solo para analizar. Recibe copias de los datos que producen los sistemas del día a día de una organización. Los limpia, los pone de acuerdo entre sí y los guarda con su historia, para que cualquiera pueda preguntar por meses o años sin tocar los sistemas de origen.

La definición que, según el propio Bill Inmon, aceptó la industria es la suya. Él mismo cuenta que apareció en su libro Building the Data Warehouse [3]. En un texto de diciembre de 2025 la repite así. El almacén es «una colección de datos orientada a temas, integrada, no volátil y variante en el tiempo, para la toma de decisiones de la gerencia» [3]. Las citas en inglés de esta página son traducción propia.

Leídas en lenguaje llano, esas cuatro palabras dicen esto:

• Orientado a temas. Se organiza por los asuntos sobre los que se pregunta, como clientes, productos o ventas, y no por el programa que produjo cada dato.
• Integrado. Los datos de cada aplicación se rehacen con una forma y una estructura comunes a toda la organización [3]. Un cliente es el mismo cliente, venga del sistema que venga.
• No volátil. Lo que entra no se borra ni se reescribe con el uso diario: se va sumando.
• Variante en el tiempo. Guarda la historia. Inmon describe esos datos como detallados e históricos [3].

Una analogía: el kiosco y la hemeroteca

Piense en el periódico. El kiosco de la esquina vende la edición de hoy y mañana la cambia por la siguiente. Le sirve a quien quiere saber qué pasa ahora. Ese es el sistema operacional, el del día a día: el que atiende la venta, la cita o el pago del momento.

La hemeroteca hace otra cosa. Guarda todas las ediciones de muchos diarios, ordenadas por fecha, y no corrige la de ayer: si hubo un error, la corrección sale en una edición posterior. Allí se va a comparar, no a comprar. Ese es el almacén de datos.

Nadie le pediría al vendedor del kiosco la portada de un día de 2019. Y nadie iría a la hemeroteca por el periódico de esta mañana.

¿Para qué sirve un data warehouse?

Un almacén de datos sirve para hacer preguntas grandes sin estorbar a los sistemas que mueven la operación. El sistema que registra ventas debe responder rápido a cada cajero. La pregunta por el total de los últimos cinco años obliga a leer todas las filas de ese periodo. Si las dos cosas pasan en la misma base, la segunda frena a la primera.

Microsoft lo explica en su guía de arquitectura. Las bases que registran las transacciones del negocio están optimizadas para anotar registros uno por uno. Guardan información valiosa, pero «no están diseñadas para el análisis», y sacar datos de ellas es lento y difícil [6]. Por eso recomienda un sistema aparte cuando se necesitan consultas analíticas complejas sin perjudicar a los sistemas transaccionales [6].

A esos dos mundos se les dan dos siglas en inglés. OLTP es el procesamiento de transacciones en línea, el del día a día, que se explica en la guía de bases de datos transaccionales. OLAP es el procesamiento analítico en línea, y su lugar entre los demás sistemas está en los tipos de bases de datos.

La separación tiene un precio, y conviene decirlo. Según la misma guía, los almacenes analíticos suelen actualizarse con intervalos mucho más lentos que los sistemas de origen [6]. Sirven para decisiones estratégicas, más que para reaccionar al minuto [6]. Si lo que necesita es saber qué pasa en este segundo, el almacén no es la herramienta.

Margy Ross, entonces presidenta del Kimball Group, lo plantea en términos de empresa en una columna de 2004. Nadie intentaría manejar un negocio sin procesos y sistemas para la operación, escribe, y del mismo modo hacen falta procesos y sistemas analíticos que aprovechen esa base [4]. El almacén de datos es la pieza que alimenta la inteligencia de negocios, los informes y tableros con los que se decide.

Inmon vs Kimball: dos maneras de construir el almacén

Inmon y Kimball no discuten si hace falta un almacén de datos, sino por dónde empezar a construirlo. Inmon propone primero un almacén central para toda la organización y, desde él, almacenes pequeños por área. Kimball propone empezar por los procesos del negocio, cada uno modelado para consultar fácil, y unirlos con descripciones comunes.

Dos términos ayudan a leer la tabla. Un data mart es un almacén más pequeño, hecho para un área o un grupo de usuarios [3]. Y la tercera forma normal es una manera de repartir los datos en tablas para no repetir nada, explicada en la guía de normalización de bases de datos.

	Enfoque Inmon (fábrica de información corporativa)	Enfoque Kimball (arquitectura de bus)
Qué se construye primero	Un almacén central, en formato relacional normalizado, con datos detallados e históricos de toda la organización [3]	Un modelo por proceso de negocio, como los pedidos, cargado una sola vez para toda la empresa y no repetido por departamento [4]
Cómo llegan los datos a cada área	Los data marts se alimentan únicamente del almacén central [3]	Los procesos se conectan con dimensiones conformadas: descripciones con el mismo nombre, los mismos valores y el mismo significado en todo el almacén [4]
Ventaja, según su defensor	Una «única versión de la verdad»: un lugar con la última palabra sobre qué dato es correcto [3]	El detalle de cada transacción queda disponible, así que se puede resumir de cualquier manera sin suponer de antemano las preguntas [4]
Riesgo, según el otro lado	Ross: la normalización por sí sola no resuelve las claves y etiquetas comunes que exige integrar, y, en el enfoque híbrido, guardar el detalle dos veces añade costos y demoras significativos [4]	Inmon: en su primera etapa, el modelo de Kimball no contiene una única versión de la verdad para toda la empresa y se vuelve problemático en organizaciones grandes, con muchos datos que integrar [3]
Lo que el propio defensor admite	Inmon: requiere mucho más tiempo y recursos, sobre todo porque su alcance es toda la organización [3]	Ross: no se opone del todo a un almacén normalizado previo, si hay una necesidad real, presupuesto para duplicar la carga y el almacenamiento, y claridad sobre el doble paso [4]

Fuente: textos de cada autor o de su grupo [3][4][5]. Cada columna resume a un defensor y a su crítico; ninguno de los dos es neutral.

La tabla deja ver un acuerdo que suele perderse en la pelea. Ross reconoce que ambos enfoques planean desde la mirada de toda la empresa [4]. Y los dos rechazan los almacenes sueltos que cada área arma por su cuenta, sin coordinarse: producen variaciones parecidas pero distintas, con nombres y reglas inconsistentes [4]. El grupo Kimball documenta, además, una arquitectura híbrida que usa un almacén normalizado ya existente como fuente de datos limpios [5].

Inmon concede algo más. Para organizaciones pequeñas, con pocos datos, el modelo simple de Kimball en su primera etapa «puede ser perfectamente adecuado» [3]. La diferencia pesa cuando hay muchas fuentes que integrar.

¿Cómo llegan los datos al almacén?

Los datos llegan al almacén por un ciclo de carga que se repite: se sacan de las fuentes, se transforman y se cargan. A ese ciclo se le dice ETL, sigla en inglés de extraer, transformar y cargar. La transformación aplica las reglas del negocio y suele usar tablas de paso que retienen los datos mientras se procesan [7].

1. Extraer. Se copian los datos de los sistemas de origen: ventas, nómina, inventario, citas.
2. Transformar. Se filtran, se ordenan, se agregan, se cruzan entre tablas, se limpian, se quitan duplicados y se validan [7].
3. Cargar. Se guardan en el almacén, ya con la forma acordada.

Existe una variante llamada ELT: extraer, cargar y luego transformar. Ahí la transformación ocurre dentro del propio almacén de destino, con su capacidad de cómputo [7]. Microsoft sugiere elegirla cuando el destino es un almacén moderno o un lakehouse (un híbrido de almacén y lago de datos) con cómputo que crece según la demanda [7].

El grupo Kimball llama a esta parte la trastienda. Separa el ambiente de carga, que no ve el usuario, del área de presentación, donde se consultan los datos [5]. En la trastienda identifica 34 subsistemas, agrupados en cuatro grandes operaciones: extraer, limpiar y armonizar, entregar al área de presentación y administrar el proceso [5].

Cómo se arma, se programa y se vigila cada uno de esos caminos es oficio de la ingeniería de datos.

Un ejemplo colombiano: la bodega de datos del SISPRO

El SISPRO, Sistema Integral de Información de la Protección Social, es la herramienta del Ministerio de Salud para obtener, procesar y consolidar la información que apoya las decisiones del sector [2]. Su página oficial lo dice así: «Su diseño se basa en una Bodega de Datos en la cual se concentra la información necesaria para la construcción de indicadores y reportes» [2].

Los datos vienen de fuentes internas y externas al Ministerio [2]. La página nombra varios componentes [2]. Tres de ellos son la PILA, la planilla integrada con la que se liquidan los aportes; los RIPS, el registro individual de los servicios de salud prestados, y el RUAF, el registro único de afiliados [1].

La presentación de 2013 llama a esa bodega Sistema de Gestión de Datos, o SGD, y la define como un sistema que integra información de diferentes fuentes [1]. También reparte responsabilidades. Las fuentes responden por la calidad, la cobertura y la oportunidad de sus datos [1]. El equipo del SGD administra y mantiene la bodega [1]. Y los usuarios la consultan para su trabajo diario y proponen nuevas fuentes [1].

La tabla pone frente a frente los cuatro rasgos de Inmon y lo que escribió el Ministerio en ese documento. La correspondencia es mía; las frases son del Ministerio.

Rasgo	Lo que dice la presentación del Ministerio (2013)
Integrado	La bodega «integra información proveniente de diferentes Fuentes» [1]
Variante en el tiempo	Ofrece «la posibilidad del manejo histórico de la información» [1]
No volátil	Una de sus premisas: solo la fuente puede modificar los datos [1]
Orientado a temas	La consulta se organiza en cubos, vistas ya armadas por asunto: afiliaciones, vacunaciones, defunciones o prestadores de servicios de salud, entre otros [1]

Hay un detalle que conecta con la discusión de la sección anterior. Entre las ventajas de la bodega, el documento anota «ofrecer a los diferentes usuarios una única versión de la información» [1]. Es, casi palabra por palabra, la promesa que Inmon pone en el centro de su enfoque [3].

Dos límites, para no decir más de lo que dicen las fuentes. La presentación es de 2013, y no verifiqué cómo está montada la bodega hoy por dentro. La página vigente del Ministerio confirma el diseño basado en una bodega de datos, pero no publica su arquitectura [2]. Quién define la calidad de cada dato y quién responde por ella es tema del gobierno de datos.

Una consulta analítica, en pequeño

Una consulta analítica no busca una venta: suma muchas a la vez. El ejemplo usa una tabla de hechos mínima, la que guarda cada evento medible con su fecha y su valor. Está escrito en SQL, el lenguaje para pedirle datos a una base relacional, y corre en SQLite 3.53.1 [10].

-- Tabla de hechos mínima: una fila por venta, con su fecha y su valor
CREATE TABLE hechos_ventas (
  fecha    TEXT,     -- día de la venta, en formato AAAA-MM-DD
  producto TEXT,     -- qué se vendió
  unidades INTEGER,  -- cuántas unidades
  valor    INTEGER   -- valor total en pesos
);

INSERT INTO hechos_ventas VALUES
  ('2024-03-14', 'cuaderno', 3, 15000),
  ('2024-07-02', 'lapicero', 10, 12000),
  ('2024-11-20', 'cuaderno', 5, 25000),
  ('2025-02-08', 'cuaderno', 4, 22000),
  ('2025-06-30', 'lapicero', 12, 15600),
  ('2025-12-05', 'cuaderno', 6, 33000),
  ('2026-01-19', 'lapicero', 8, 11200),
  ('2026-04-27', 'cuaderno', 7, 42000);

-- La pregunta analítica: ¿cuánto se vendió cada año, por producto?
SELECT strftime('%Y', fecha) AS anio,
       producto,
       SUM(unidades)          AS unidades,
       SUM(valor)             AS valor_pesos
FROM hechos_ventas
GROUP BY anio, producto
ORDER BY anio, producto;

La función strftime saca el año de cada fecha [10]. El resultado:

anio	producto	unidades	valor_pesos
2024	cuaderno	8	40000
2024	lapicero	10	12000
2025	cuaderno	10	55000
2025	lapicero	12	15600
2026	cuaderno	7	42000
2026	lapicero	8	11200

Son datos inventados para el ejemplo. Con ocho filas, la consulta es instantánea en cualquier parte. Con cinco años de una cadena de tiendas, esa misma suma puede leer millones de registros, y por eso conviene hacerla en el almacén y no en la caja registradora.

Lo que se desarrolla aparte: arquitectura, modelos, data marts, nube y lago

Esta guía presenta el concepto. Cinco temas vecinos tendrán desarrollo propio. La arquitectura del almacén por capas explica qué pasa en cada piso, de la llegada del dato a su consulta. El esquema estrella y el copo de nieve son las dos formas clásicas de organizar las tablas de hechos y sus descripciones. Ahí entra también cómo se registran los cambios en esas descripciones. El data mart se ocupa del almacén pequeño por área. Los almacenes de datos en la nube cubren los servicios gestionados. Y la comparación entre data lake y data warehouse aclara cuándo conviene cada uno.

Sobre la nube basta un dato aquí. Los grandes proveedores ya documentan sus servicios con ese nombre. Google describe BigQuery como un almacén de datos sin servidores, totalmente administrado [8]. Amazon presenta Redshift como un servicio de almacén de datos en la nube a escala de petabytes [9]. Cuándo el volumen obliga a repartir el trabajo entre muchas máquinas se explica en la guía de big data.

La pregunta de fondo no es Inmon o Kimball

Tomo partido, y aviso que es opinión. Para una entidad pública colombiana, o para una empresa mediana con muchos sistemas que no se hablan, el problema más caro casi nunca es el modelo de las tablas. Es ponerse de acuerdo en qué es un afiliado, un cliente o una venta.

El SISPRO lo entendió así. Sus seis premisas hablan de estándares, de integración, de registros administrativos y de quién puede modificar cada dato [1]. Ninguna nombra un producto ni un proveedor.

Ross cierra su comparación con un criterio que comparto. El éxito de un almacén, escribe, se mide por la aceptación que le da el negocio y por los beneficios que obtiene de él [4]. Un almacén impecable que nadie consulta es una hemeroteca cerrada con llave.

Preguntas frecuentes

¿Cómo se dice data warehouse en español? Almacén de datos es la traducción más usada. En el sector público colombiano también circula bodega de datos: así la llama el Ministerio de Salud al describir el SISPRO [2]. En esta guía, data warehouse, almacén de datos y bodega de datos se usan como sinónimos.

¿Un data warehouse es lo mismo que una base de datos? Es un tipo de base de datos con un propósito particular: analizar. Toda bodega de datos es una base de datos, pero la base que registra las ventas de una tienda no es una bodega. La diferencia está en el uso y en el diseño, no en el programa que la guarda.

¿Cada cuánto se actualiza un almacén de datos? Depende de lo que pida el negocio: puede ser cada hora, cada noche o cada mes. Microsoft anota que estos sistemas suelen refrescarse con intervalos mucho más lentos que los transaccionales [6]. En la presentación de 2013 del SISPRO, varias fuentes figuraban con reporte mensual [1].

¿Qué ejemplos de data warehouse hay en Colombia? Un caso documentado con fuente oficial es la bodega de datos del SISPRO, del Ministerio de Salud, que concentra la información para indicadores y reportes del sector [2]. El Ministerio publica qué contiene y para qué sirve, aunque no su arquitectura interna [2].

¿Hace falta un data warehouse para usar Power BI o Excel? No. Una herramienta de tableros puede leer directamente una hoja de cálculo o una base de datos. El almacén empieza a hacer falta en tres casos. Cuando hay varias fuentes que no cuadran entre sí, cuando se necesita la historia completa o cuando las consultas frenan los sistemas del día a día.

Referencias

1. Ministerio de Salud y Protección Social. SISPRO. Sistema Integral de Información de la Protección Social (presentación, enero de 2013) — seis premisas, entre ellas «La Fuente de los datos es la única que puede modificarlos»; el Sistema de Gestión de Datos (SGD) o Bodega de Datos de SISPRO «integra información proveniente de diferentes Fuentes», con un único repositorio y «la posibilidad del manejo histórico de la información»; ventaja de «ofrecer a los diferentes usuarios una única versión de la información»; roles de fuentes (calidad, cobertura y oportunidad), usuarios y equipo del SGD; fuentes PILA, RIPS y RUAF con sus nombres completos; cubos por componente (afiliaciones, vacunaciones, defunciones, prestadores, entre otros); fuentes con reporte mensual. Ministerio de Salud: presentación SISPRO, enero de 2013 — Consultada: 2026-11-11.
2. Ministerio de Salud y Protección Social. Sistema Integral de Información de la Protección Social (SISPRO) — herramienta para obtener, procesar y consolidar la información para la toma de decisiones del sector; «Su diseño se basa en una Bodega de Datos en la cual se concentra la información necesaria para la construcción de indicadores y reportes»; datos de fuentes internas y externas al Ministerio; componentes RUAF, RIPS, PILA, SIHO, SGD y SISMED, entre otros. Ministerio de Salud: Sistema Integral de Información SISPRO — Consultada: 2026-11-11.
3. Inmon, William. A Tale of Two Architectures – Kimball vs Inmon, en su publicación Data Architecture/Data Management Monographs (23 de diciembre de 2025) — la definición «a subject oriented, integrated, non volatile, time variant collection of data for management’s decision making» apareció en Building the Data Warehouse; la fábrica de información corporativa: datos de las aplicaciones rehechos en forma corporativa, almacén relacional normalizado con datos granulares e históricos, data marts alimentados solo por el almacén, «single version of the truth»; requiere mucho más tiempo y recursos; el modelo dimensional simple de Kimball (primera etapa) es más rápido de construir, no exige una única versión de la verdad, «may be perfectly adequate» para organizaciones pequeñas y se vuelve problemático en las grandes. Texto del autor sobre su propia posición. William Inmon: A Tale of Two Architectures — Consultada: 2026-11-11.
4. Ross, Margy (Kimball Group). Differences of Opinion (3 de marzo de 2004) — los negocios necesitan sistemas analíticos que complementen a los operativos; ambos enfoques planean desde la perspectiva de toda la empresa y rechazan los almacenes independientes; modelos dimensionales por proceso de negocio, cargados una vez; dimensiones conformadas; datos atómicos en estructuras dimensionales para resumir «any which way»; la normalización sola no resuelve la integración; costos de guardar el detalle dos veces; enfoque híbrido; el éxito se mide por la aceptación del negocio. Texto del grupo sobre su propia posición. Kimball Group: Differences of Opinion — Consultada: 2026-11-11.
5. Kimball Group. Kimball Technical DW/BI System Architecture — separación entre el ambiente de carga (ETL) de la trastienda y el área de presentación; 34 subsistemas de ETL agrupados en cuatro operaciones (extraer, limpiar y armonizar, entregar, administrar); la fábrica de información corporativa como alternativa con almacén en tercera forma normal; arquitectura híbrida. Kimball Group: Technical DW/BI System Architecture — Consultada: 2026-11-11.
6. Microsoft. Online analytical processing, Azure Architecture Center (fecha del artículo: 11 de abril de 2025) — las bases transaccionales están optimizadas para registros individuales y «not designed for analysis»; usar un sistema analítico para consultas complejas sin afectar los sistemas transaccionales; los almacenes analíticos suelen refrescarse a intervalos mucho más lentos y sirven a decisiones estratégicas más que a respuestas inmediatas. Microsoft Learn: Online analytical processing — Consultada: 2026-11-11.
7. Microsoft. Extract, transform, and load (ETL), Azure Architecture Center (fecha del artículo: 15 de septiembre de 2025) — definición de ETL y uso de tablas de paso; operaciones de transformación (filtrar, ordenar, agregar, unir, limpiar, deduplicar, validar); ELT transforma en el almacén de destino; elegir ELT cuando el destino es un almacén moderno o un lakehouse con cómputo elástico. Microsoft Learn: Extract, transform, and load (ETL) — Consultada: 2026-11-11.
8. Google Cloud. BigQuery overview (actualizada el 10 de noviembre de 2026) — BigQuery como almacén de datos sin servidores y totalmente administrado. Google Cloud: BigQuery overview — Consultada: 2026-11-11.
9. Amazon Web Services. What is Amazon Redshift?, Amazon Redshift Management Guide — servicio de almacén de datos en la nube, totalmente administrado y a escala de petabytes. AWS: What is Amazon Redshift? — Consultada: 2026-11-11.
10. SQLite. Date and Time Functions y Release History — función strftime y su sustitución %Y para el año; versión 3.53.1 publicada el 5 de mayo de 2026. SQLite: Date and Time Functions · SQLite: Release History — Consultada: 2026-11-11.

Cómo investigamos esta página

• Pregunta que responde: Qué es un almacén de datos, por qué se separa de los sistemas del día a día, cómo difieren Inmon y Kimball y cómo se ve en el SISPRO.
• Fuentes: identificadas 30 → incluidas 10
• Criterios de inclusión: textos de los propios autores, documentación oficial de fabricantes y documentos del Ministerio de Salud; sin citas de segunda mano, blogs ni enciclopedias.
• Fecha de corte de los datos: 2026-11-11