05 · Lectura de fondo

La metodología de Kimball

Quién formalizó el esquema en estrella, y cómo ordena el trabajo completo de construir un data warehouse.

Ralph Kimball es quien formalizó el diseño en esquema de estrella. Su metodología, conocida como Business Dimensional Lifecycle (ciclo de vida dimensional del negocio), explica paso a paso cómo elegir el grano, las dimensiones y los hechos de un data warehouse — el mismo concepto de "grano" que viste en la ficha de fct_ventas.

El PDF de abajo es un resumen académico en español de esa metodología completa, publicado en los Cuadernos de la Facultad de la UCASAL.

PDF: Rivadera, G. R. (2010). La metodología de Kimball para el diseño de almacenes de datos (Data warehouses). Cuadernos de la Facultad, N.° 5, UCASAL.

¿Dónde vive un data warehouse, en la práctica?

Hasta aquí todo esto pudo sonar bastante abstracto: hechos, dimensiones, un ciclo de vida con nombre en inglés. Y llega un punto en el que aparece una pregunta muy concreta que casi ningún curso responde: "vale, ¿pero todo esto dónde se guarda? ¿Tengo que instalar algo? ¿A dónde subo los datos, exactamente?"

Es una de las dudas más comunes al empezar en datos, y genera una incertidumbre real — la sensación de que a todos los demás ya les quedó claro y a uno se le pasó la clase donde lo explicaron. No es así: es simplemente un tema que rara vez se enseña de forma directa, porque la mayoría del material se concentra en el modelado (estrella, copo de nieve) y deja la infraestructura para "después". Aquí va esa parte que falta.

La versión corta
hoy, en la gran mayoría de las empresas, el data warehouse no es una máquina en un cuarto del edificio — es una cuenta en un servicio en la nube, como quien contrata almacenamiento en Google Drive pero para tablas en vez de archivos.
Los nombres que vas a encontrar
Google BigQuery, Snowflake, Amazon Redshift y Microsoft Fabric / Azure Synapse son los más usados. Ninguno se "instala": se contrata, y las tablas viven dentro de un proyecto de esa cuenta.

Para hacerlo concreto: en BigQuery, por ejemplo, un proyecto llamado tienda-analytics podría tener un dataset ventas_dw, y dentro de ese dataset viven, como tablas normales, fct_ventas, dim_producto y dim_cliente — las mismas tablas de las que habla toda esta página, solo que alojadas en un servidor de Google en vez de en la computadora de alguien.

En la nube (BigQuery, Snowflake...)Local / on-premise
¿Quién mantiene el hardware?El proveedor (Google, Amazon...)El propio equipo de la empresa
Costo inicialBajo — se paga por lo que se usaAlto — hay que comprar servidores
Cómo se escalaCon un clic, casi al instanteComprando e instalando más hardware
Qué tan común es hoyEs la opción por defecto en la mayoría de empresas nuevasTodavía existe en empresas grandes con reglas estrictas de dónde deben estar sus datos

Ahora, cómo llegan los datos hasta ahí. Nadie escribe cada fila a mano: un conjunto de procesos automáticos, llamados ETL o ELT (extraer, transformar, cargar — el orden cambia según el caso), se encarga de mover la información desde donde nace hasta el data warehouse, todos los días, sin intervención manual:

  1. Extraer Un proceso se conecta a las fuentes originales — la base del sistema de ventas, la app, un archivo que exporta otro equipo — y lee los datos nuevos.
  2. Cargar Esos datos, todavía en bruto, se copian dentro del data warehouse. Herramientas como Fivetran o Airbyte suelen encargarse de este paso.
  3. Transformar Ya dentro del data warehouse, otro proceso ordena esos datos en bruto y arma las tablas de hechos y dimensiones — el trabajo de modelado del que habla el resto de esta página. Una herramienta muy usada para esta etapa es dbt.
  4. Consultar Con las tablas ya armadas, herramientas de reportes como Looker, Power BI o Tableau se conectan al data warehouse y arman los dashboards que finalmente ve alguien del negocio.
Ninguna de estas herramientas hay que dominarlas para aprender a modelar datos. El grano, las tablas de hechos y las dimensiones son el mismo concepto ya sea que la tabla viva en un archivo .sqlite en tu computadora o en una cuenta de BigQuery de una empresa real. De hecho, es totalmente normal — y una buena forma de empezar — practicar el modelado en una base de datos gratuita y local, como SQLite o PostgreSQL, antes de tocar una cuenta en la nube. La parte de infraestructura casi siempre se aprende después, en el trabajo, con el equipo de al lado como guía — no es algo que se espere que alguien traiga resuelto desde el primer día.