El proceso de cuatro pasos de Kimball

Descripción

Esta lección enseña el método completo —proceso de negocio, grano, dimensiones, hechos— sobre un ejemplo pequeño y ajeno a Kiosko: una cafetería. La razón de no usar Kiosko todavía es deliberada: quieres ver el patrón completo, de principio a fin, en un caso tan simple que ninguna decisión sea dudosa, antes de aplicarlo sobre datos reales con sus propias complicaciones. Las lecciones 4 y 5 retoman exactamente este mismo proceso, paso por paso, sobre fact_orders.

Conexión con el módulo. Esta es la lección más conceptual del módulo, y la más importante: si el proceso de cuatro pasos no queda claro aquí, con un ejemplo sin complicaciones, aplicarlo sobre Kiosko en las lecciones siguientes va a sentirse arbitrario en vez de metódico.

Una analogía: la receta antes que los ingredientes

Un cocinero que abre un restaurante nuevo no compra ingredientes al azar y después decide qué platillo cocinar con lo que tiene. Empieza al revés: decide qué platillo va a servir (el proceso de negocio), después decide la porción exacta que representa un plato —¿es una porción individual, una porción familiar, un aperitivo?— (el grano), y solo entonces sabe qué ingredientes necesita comprar y en qué cantidad (los hechos), y qué acompañamientos o variantes ofrecer (las dimensiones: tipo de pan, tamaño, con o sin queso).

Si invirtiera el orden —comprando ingredientes antes de decidir la porción—, terminaría con una cocina llena de cosas que "podrían servir para algo", sin ningún plato bien definido. El proceso de Kimball aplica exactamente esa misma disciplina al diseño de un modelo dimensional: la secuencia importa, y saltarse un paso —o hacerlos en el orden equivocado— produce el mismo caos que comprar ingredientes sin receta.

Ejemplo trabajado: los cuatro pasos, aplicados a una cafetería

Antes de tocar a Kiosko, aplica el proceso completo sobre un negocio distinto y mucho más simple: una cafetería con tres empleados (baristas) que preparan bebidas para clientes que pagan en el momento.

Paso 1 — Select the business process. El proceso de negocio no es "la cafetería" en general —eso es demasiado amplio para modelar en una sola tabla—; es un evento medible y específico. Para esta cafetería, el proceso elegido es la venta de una bebida: cada vez que un barista cobra una bebida a un cliente, ocurre el evento que este modelo va a registrar.

Paso 2 — Declare the grain. La pregunta es: ¿qué representa exactamente una fila? Para la venta de una bebida, la respuesta más fina y honesta es: una fila representa una bebida vendida, en un instante específico, preparada por un barista específico. No es "un cliente" (un cliente puede pedir tres bebidas en una sola visita) ni "un día de ventas" (eso ya sería un agregado, no el grano original).

Paso 3 — Identify the dimensions. Con el grano ya fijo ("una bebida vendida, en un instante, por un barista"), las dimensiones son el contexto que responde quién, qué, cuándo y dónde: dim_drink (qué bebida — espresso, latte, capuchino), dim_barista (quién la preparó), dim_date (cuándo).

Paso 4 — Identify the facts. Las medidas numéricas que tiene sentido sumar a través de muchas filas: price (el precio cobrado) y, si la cafetería lo registrase, prep_time_seconds (el tiempo de preparación, sumable para calcular carga de trabajo total de un barista en un turno).

# coffee_shop_four_steps.py
BUSINESS_PROCESS = "Venta de una bebida"

GRAIN = "Una fila representa una bebida vendida, en un instante especifico, preparada por un barista especifico"

DIMENSIONS = ["dim_drink", "dim_barista", "dim_date"]

FACTS = ["price", "prep_time_seconds"]

print("=== Los cuatro pasos de Kimball, aplicados a una cafeteria ===\n")
print(f"Paso 1 (business process): {BUSINESS_PROCESS}")
print(f"Paso 2 (grain):            {GRAIN}")
print(f"Paso 3 (dimensions):       {DIMENSIONS}")
print(f"Paso 4 (facts):            {FACTS}")

# Una fila de ejemplo, ya con el grano correcto
sale = {
    "drink_id": "D01",
    "barista_id": "B02",
    "sale_ts": "2026-08-03T08:15:00",
    "price": 3.50,
    "prep_time_seconds": 90,
}
print(f"\nUna fila real con este grano: {sale}")

Qué esperar. Al correr python3 coffee_shop_four_steps.py, la salida es exactamente esta:

=== Los cuatro pasos de Kimball, aplicados a una cafeteria ===

Paso 1 (business process): Venta de una bebida
Paso 2 (grain):            Una fila representa una bebida vendida, en un instante especifico, preparada por un barista especifico
Paso 3 (dimensions):       ['dim_drink', 'dim_barista', 'dim_date']
Paso 4 (facts):            ['price', 'prep_time_seconds']

Una fila real con este grano: {'drink_id': 'D01', 'barista_id': 'B02', 'sale_ts': '2026-08-03T08:15:00', 'price': 3.5, 'prep_time_seconds': 90}

Fíjate en algo que vas a ver repetirse, idéntico en estructura, cuando apliques el mismo proceso a Kiosko en las lecciones 4 y 5: cada dimensión (dim_drink, dim_barista, dim_date) responde una pregunta de contexto distinta sobre la misma fila, y cada hecho (price, prep_time_seconds) es algo que tiene sentido sumar a través de muchas ventas. Ninguna columna aparece dos veces en ambas listas — una columna es dimensión o es hecho, nunca las dos cosas.

Diagrama: el orden que no se puede invertir

flowchart TD
    A["Paso 1: Select the business process\n(que evento vas a medir)"] --> B["Paso 2: Declare the grain\n(que representa una fila)"]
    B --> C["Paso 3: Identify the dimensions\n(el contexto de esa fila)"]
    C --> D["Paso 4: Identify the facts\n(las medidas numericas de esa fila)"]

    B -.no se puede saltar.-> E["Si declaras dimensiones o hechos\nsin grano fijo, cada columna nueva\nreabre la pregunta 'una fila de que?'"]

Profundización: por qué invertir el orden rompe el modelo

Imagina que alguien, apurado, empieza por el paso 3 —"identify the dimensions"— sin haber declarado el grano de la cafetería primero. Esa persona podría razonablemente proponer dim_drink y dim_barista como dimensiones... pero también podría proponer dim_customer_visit (una dimensión por visita completa de un cliente, que puede incluir varias bebidas). Sin el grano ya fijo, ninguna de las dos propuestas es objetivamente correcta o incorrecta — dependen, completamente, de si el grano final va a ser "una bebida" o "una visita completa". Cada dimensión que se agregue sin el grano fijo obliga a volver a preguntar "¿una fila de qué, exactamente?", y ese vaivén es, con precisión, lo que produce un modelo indeciso: mitad una cosa, mitad otra, sin que nadie pueda responder con seguridad qué representa una fila.

Esa es la razón concreta —no solo una convención arbitraria— de que el proceso ponga "declare the grain" en el paso 2, inmediatamente después de elegir el proceso de negocio, y antes de tocar una sola dimensión o un solo hecho. El grano es la restricción que hace que todas las decisiones que siguen tengan una sola respuesta correcta, no varias igualmente razonables.

Hay una segunda razón, más práctica todavía: las medidas del paso 4 solo tienen sentido una vez que sabes a qué nivel se calculan. price como medida de "una bebida vendida" es directo: el precio de esa bebida específica. Pero si el grano fuera "una visita completa" (varias bebidas), price tendría que ser una suma ya calculada de antemano —perdiendo el detalle de cuánto costó cada bebida individual—. El grano no solo organiza el modelo: determina literalmente qué significa cada medida.

Errores comunes

Elegir un proceso de negocio demasiado amplio. Qué pasa: alguien, al hacer el paso 1, elige algo como "la cafetería" o "las operaciones del negocio" en vez de un evento medible y específico como "la venta de una bebida". Por qué pasa: pensar en términos de "el negocio completo" se siente más ambicioso e importante que pensar en un solo tipo de evento. Cómo detectarlo: si tu "proceso de negocio" no se puede describir como un verbo con un momento específico en que ocurre (vender, pedir, enviar, iniciar sesión), es demasiado amplio para modelarse en una sola tabla de hechos. Cómo corregirlo: un negocio real tiene varios procesos —ventas, compras a proveedores, turnos de empleados—, y cada uno se modela con su propia tabla de hechos, cada una con su propio grano. "La cafetería" no es un proceso; "la venta de una bebida" sí lo es.

Declarar el grano usando una columna, no una frase. Qué pasa: alguien, al hacer el paso 2, escribe algo como grain = "drink_id" — el nombre de una columna, no una oración completa que describa qué representa la fila. Por qué pasa: pensar en términos de "la llave" de la tabla se siente más técnico y directo que escribir una frase en prosa. Cómo detectarlo: si tu declaración de grano cabe en el nombre de una sola columna, probablemente estás describiendo una llave, no el grano completo — el grano necesita describir la unidad de negocio completa ("una bebida vendida, en un instante, por un barista"), no solo un identificador. Cómo corregirlo: el ejemplo trabajado de esta lección declara el grano como una oración completa en GRAIN, no como el nombre de una columna — imita esa forma, siempre.

Mezclar dimensiones y hechos en la misma lista, "porque las dos describen la venta". Qué pasa: alguien, al terminar los pasos 3 y 4, incluye price tanto en DIMENSIONS como en FACTS, razonando que el precio también "describe" la venta. Por qué pasa: es fácil olvidar la prueba de comportamiento —¿tiene sentido sumarlo?— y confundir "describe algo de la fila" con "es una dimensión". Cómo detectarlo: si sumar la columna a través de muchas filas produce un número con sentido de negocio ("revenue total de la cafetería"), es un hecho, no una dimensión — sin excepción, sin importar qué tan descriptiva se sienta. Cómo corregirlo: aplica la prueba de las dos preguntas que ya viste en foundations (¿se puede sumar con sentido? ¿describo algo estable que uso para agrupar?) a cada columna, una por una, antes de decidir en qué lista va.

Ejercicios

Ejercicio 1 — Aplica los cuatro pasos a un gimnasio. Un gimnasio registra cada vez que un socio hace check-in con su tarjeta al entrar. Aplica los cuatro pasos de Kimball a este proceso: (1) nombra el proceso de negocio, (2) declara el grano en una frase completa, (3) propón al menos dos dimensiones, (4) propón al menos un hecho (medida numérica).

Ver solución

Una respuesta razonable:

1. Business process: el check-in de un socio en el gimnasio.
2. Grain: una fila representa un check-in de un socio específico, en un instante específico, en una sede específica.
3. Dimensions: dim_member (quién), dim_gym_location (en qué sede), dim_date (cuándo).
4. Facts: visit_duration_minutes (si el gimnasio registra cuánto tiempo permaneció el socio, es una medida sumable a través de muchos check-ins — por ejemplo, para calcular el tiempo total de uso de una sede en un mes). Un check-in sin duración registrada podría, incluso, no tener ningún hecho numérico más allá de un contador implícito de "1 visita" — un caso legítimo llamado factless fact table, que vas a mencionar de pasada en la lección 6.

Ejercicio 2 — Encuentra el error en un grano mal declarado. Alguien propone este grano para el gimnasio: "una fila representa las visitas de un socio durante el mes". Explica en 2-3 frases por qué esta declaración, tal como está escrita, es más agregada que el grano más fino disponible, y por qué eso podría ser un problema.

Ver solución

"Las visitas de un socio durante el mes" es un agregado —una fila resumiría muchos check-ins en un solo número (por ejemplo, "12 visitas en agosto")—, no el evento individual más fino que el sistema de origen registra (cada check-in específico, con su propio instante). Declarar el grano de esa forma pierde información irrecuperable: no podrías responder "¿a qué hora del día visita más este socio?" ni "¿cuántas visitas tuvo la sede X el martes pasado?" sin volver a los datos crudos — exactamente el mismo problema que ya viste en foundations cuando la capa gold (agregada) no podía responder preguntas que solo silver (grano fino) sí podía. Un grano agregado puede ser una decisión válida para una tabla distinta y más resumida, pero nunca debería ser el grano de la tabla de hechos principal si el sistema de origen registra algo más fino.

Ejercicio 3 — Explica el orden con tus propias palabras. Sin repetir literalmente la sección de profundización, explica en 2-3 frases por qué "identify the dimensions" (paso 3) no se puede hacer bien sin haber completado antes "declare the grain" (paso 2).

Ver solución

Las dimensiones responden preguntas de contexto sobre una fila específica ("¿de qué bebida se trata?", "¿qué barista la preparó?"), pero esas preguntas solo tienen sentido si ya sabes qué es exactamente "una fila". Si el grano todavía no está decidido, cualquier dimensión que propongas está, en realidad, adivinando entre varias definiciones posibles del grano al mismo tiempo, y es fácil terminar con una dimensión que tiene sentido para un grano ("una bebida") pero no para otro ("una visita completa con varias bebidas"). Fijar el grano primero elimina esa ambigüedad: una vez decidido, solo hay una respuesta correcta a "¿qué contexto necesita esta fila?".

Resumen y siguiente paso

En esta lección aprendiste el proceso completo de cuatro pasos de Ralph Kimball —proceso de negocio, grano, dimensiones, hechos— aplicado, de principio a fin, sobre un ejemplo sencillo y ajeno a Kiosko: la venta de una bebida en una cafetería. Viste por qué el orden de los pasos no es una convención arbitraria: cada paso depende, de forma concreta, de que el anterior ya esté resuelto — invertir el orden produce ambigüedad, no solo desorden.

Antes de avanzar deberías poder: nombrar los cuatro pasos en orden, sin ayuda; declarar el grano de un proceso de negocio nuevo como una frase completa, no como el nombre de una columna; y explicar, con un ejemplo propio, por qué declarar dimensiones antes que el grano produce ambigüedad.

Con el proceso completo ya claro sobre un ejemplo sencillo, la lección 4 aplica el paso 1 —seleccionar el proceso de negocio— directamente sobre Kiosko: vas a ver que, incluso con solo dos fuentes de datos disponibles (orders y events), la elección del proceso correcto no es tan obvia como parece a primera vista.

Recursos

• Kimball Group — "Four-Step Dimensional Design Process" — la fuente que define, en el orden exacto usado en esta lección, los cuatro pasos aplicados aquí a la cafetería. kimballgroup.com/.../four-4-step-design-process. En inglés.
• "The Data Warehouse Toolkit", 3ra edición (Kimball & Ross, Wiley) — el capítulo de introducción desarrolla el mismo proceso de cuatro pasos con ejemplos de retail, la base conceptual de este libro completo. wiley.com/en-jp/The+Data+Warehouse+Toolkit. En inglés.
• Microsoft Learn — "Understand star schema and the importance for Power BI" — una confirmación práctica y neutral en herramienta de por qué declarar grano, dimensiones y hechos con precisión importa para cualquier consumidor analítico. learn.microsoft.com/en-us/power-bi/guidance/star-schema. En inglés.