Módulo 1: From Flat Tables To Dimensional Models

Presentación del módulo: de tablas planas a modelos dimensionales

Siguiente →

Por qué existe este módulo

data-engineering-foundations-guide terminó con un pipeline real: fact_orders, dim_store y dim_product, construidos en tres capas —bronze, silver, gold— y verificados dos veces para confirmar que correrlo de nuevo no duplicaba ni una sola fila. Ese pipeline funciona. La gerente de Kiosko recibió su reporte de ventas por tienda y por producto, con revenue calculado correctamente. Si tu única meta fuera "tener algo consultable", la historia ya terminó ahí.

Pero foundations fue honesta sobre lo que dejó sin resolver, y lo dijo con esas palabras casi exactas: le dio a Kiosko un hecho y dos dimensiones planas, lo mínimo para tener algo consultable, no una metodología de modelado. dim_store y dim_product usan llave natural, sin llave sustituta, porque "son catálogos fijos que no cambian durante toda la guía". No existe dim_date. No existe una segunda tabla de hechos para el clickstream de la app (events, con sus page_view/add_to_cart/purchase), aunque ese dato ya está ahí, esperando. Y sobre todo: en ningún lugar de foundations existe una frase que diga, con precisión, qué representa exactamente una fila de fact_orders. Se dijo de forma informal, en una analogía ("una línea de orden"), pero nunca se declaró como una decisión de diseño verificada con una consulta.

Esta guía existe para cerrar esa deuda, empezando exactamente por ese último punto. Antes de construir un star schema completo (módulo 2), antes de decidir entre normalizar o aplanar (módulo 3), antes de historizar una dimensión que cambia (módulo 4) — antes de cualquier otra cosa — hay una pregunta que el método de modelado dimensional más usado en la industria insiste en responder primero, y que este módulo 1 responde con Kiosko: ¿qué representa, exactamente, una fila? Esa pregunta tiene nombre técnico: se llama declarar el grano, y es el primer instinto que separa a alguien que diseña un warehouse con criterio de alguien que solo junta tablas hasta que las consultas "funcionan".

Conexión con el módulo. Este módulo no construye ninguna tabla nueva —fact_orders, dim_store y dim_product siguen siendo, columna por columna, las que declaró foundations—. Lo que este módulo construye es el vocabulario y el proceso que vas a reutilizar en cada uno de los siete módulos que siguen: el proceso de cuatro pasos de Ralph Kimball (proceso de negocio → grano → dimensiones → hechos), aplicado por primera vez, de punta a punta, sobre el fact_orders que ya tienes.

Una analogía: la libreta de anotaciones y la contabilidad formal

Piensa en un puesto de mercado pequeño, de esos que llevan las cuentas en una libreta. El dueño anota cada venta como le sale: a veces "vendí 3 aguas", a veces "cliente compró agua y una barra, $2.35 en total", a veces solo el total del día sin detalle. La libreta sirve —al final del mes, sumando páginas, el dueño sabe más o menos cuánto ganó—, pero si un contador le preguntara "¿cuántas unidades de agua vendiste el martes 4 de agosto, exactamente?", el dueño tendría que releer cada línea de la libreta, adivinando qué representa cada anotación, porque nunca decidió de antemano una unidad fija de registro.

La contabilidad formal no tiene ese problema, porque empieza al revés: antes de anotar la primera venta, decide qué es un asiento contable —una transacción específica, con fecha, monto y cuenta, siempre con la misma forma— y de ahí en adelante, cada fila del libro mayor es exactamente eso, sin excepción. Cualquier pregunta futura ("¿cuánto vendimos en agua el martes?") se responde sumando asientos, con confianza, porque la unidad de registro nunca fue ambigua.

fact_orders, tal como lo dejó foundations, ya funciona más como la libreta que como la contabilidad formal: sabes que cada fila es "más o menos una venta", pero nadie escribió, en ningún lugar, la frase exacta que dice qué es una fila y verificó con una consulta que el dato real cumple esa frase. Este módulo convierte esa intuición informal en una declaración formal, verificada — el primer paso de cualquier modelo dimensional serio.

Ejemplo trabajado: el mapa de los cuatro pasos, antes de aplicarlos

Antes de escribir el primer archivo de este módulo, vale la pena ver el destino completo — los cuatro pasos que vas a recorrer, y en qué lección de este módulo aparece cada uno.

# kimball_steps_preview.py
STEPS = [
    (1, "Select the business process", "Que evento de negocio de Kiosko vas a modelar primero"),
    (2, "Declare the grain", "Que representa, exactamente, una fila de fact_orders"),
    (3, "Identify the dimensions", "Con que contexto se puede filtrar o agrupar ese grano"),
    (4, "Identify the facts", "Que columnas numericas del grano tiene sentido sumar"),
]

print("=== El proceso de cuatro pasos de Kimball, aplicado a Kiosko en este modulo ===\n")
for number, name, question in STEPS:
    print(f"Paso {number}: {name}")
    print(f"         {question}\n")

print("Este modulo 1 completa los cuatro pasos sobre fact_orders, el hecho que ya existe.")
print("Los modulos 2 a 8 profundizan cada pieza que este primer paso deja, a proposito, superficial.")

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

=== El proceso de cuatro pasos de Kimball, aplicado a Kiosko en este modulo ===

Paso 1: Select the business process
         Que evento de negocio de Kiosko vas a modelar primero

Paso 2: Declare the grain
         Que representa, exactamente, una fila de fact_orders

Paso 3: Identify the dimensions
         Con que contexto se puede filtrar o agrupar ese grano

Paso 4: Identify the facts
         Que columnas numericas del grano tiene sentido sumar

Este modulo 1 completa los cuatro pasos sobre fact_orders, el hecho que ya existe.
Los modulos 2 a 8 profundizan cada pieza que este primer paso deja, a proposito, superficial.

Ningún número de Kiosko todavía —esta lección es, deliberadamente, el mapa antes del territorio, igual que hizo el módulo 8 de foundations con su propio mapa de bronze/silver/gold—. Pero fíjate en el orden exacto de los cuatro pasos: grano antes que dimensiones, dimensiones antes que hechos. Ese orden no es arbitrario, y la lección 3 de este módulo explica, con evidencia, por qué invertirlo produce modelos rotos.

Diagrama: dónde estabas, dónde vas a estar

flowchart LR
    subgraph Foundations["foundations (guia anterior)"]
        A["fact_orders, dim_store, dim_product\nun hecho, dos dimensiones planas\nsin grano declarado formalmente"]
    end

    subgraph M1["Este modulo (1 de 8)"]
        B["Paso 1: Select the business process\n(leccion 4)"]
        C["Paso 2: Declare the grain\n(leccion 5, EJECUTADO)"]
        D["Paso 3-4: Dimensions + Facts\n(leccion 6, definicion precisa)"]
        E["Grano declarado y verificado\n(leccion 8, proyecto)"]
    end

    subgraph Resto["Modulos 2-8 (el resto de la guia)"]
        F["Star schema completo,\nSCD, snowflake vs OBT,\naccumulating snapshot..."]
    end

    A --> B --> C --> D --> E --> F

El mapa de este módulo

Leccion   Que construye
────────  ──────────────────────────────────────────────────────────────
L1        (esta) El mapa: por que la guia empieza declarando el grano
L2        Que dejo plano foundations, exactamente, y por que fue correcto entonces
L3        El proceso de cuatro pasos de Kimball, explicado con un ejemplo aparte
L4        Paso 1: seleccionando el proceso de negocio de Kiosko (ordenes de venta)
L5        Paso 2: declarando el grano de fact_orders -- EJECUTADO con DuckDB
L6        Pasos 3-4: hechos vs dimensiones, con la definicion precisa de Kimball
L7        Que cambia -- en la practica -- cuando el grano deja de ser implicito
L8        Proyecto: la declaracion de grano formal de Kiosko, verificada

Las lecciones 2 y 3 son puramente conceptuales — te dan el vocabulario y el proceso antes de aplicarlo. Las lecciones 4, 5 y 6 aplican los cuatro pasos de Kimball, uno por uno, sobre el fact_orders real de Kiosko — la lección 5 es la única de este módulo que ejecuta una consulta nueva sobre datos reales, y es, con toda propiedad, el resultado central del módulo. La lección 7 da un paso atrás y pregunta qué cambia en la práctica cuando el grano deja de ser una intuición y se vuelve una declaración verificada. Y la lección 8 cierra con el mini-proyecto: la declaración de grano formal de Kiosko, lista para que los siete módulos que siguen la den por sentada.

Profundización: por qué esta guía no empieza construyendo el star schema

Es tentador, al abrir una guía que promete "modelado dimensional real", querer ver un diagrama con varias tablas conectadas desde la primera lección. Esta guía resiste esa tentación a propósito, y vale la pena explicar por qué.

Un star schema completo —con dim_date, con dimensiones conformadas, con llaves sustitutas— es una consecuencia de decisiones anteriores, no un punto de partida. Si construyes las tablas antes de declarar qué representa cada fila de tu hecho, terminas con un modelo que "se ve bien" en un diagrama pero que nadie puede usar con confianza para responder una pregunta de negocio específica, porque nadie sabe, con precisión, qué significa sumar una columna de ese hecho. El Kimball Group —el origen del proceso de cuatro pasos que este módulo enseña— lo pone así: la respuesta a "cuál es el grano" determina todo lo que sigue, y se decide colaborativamente, considerando tanto las necesidades del negocio como la realidad de los datos de origen disponibles.

Por eso este módulo, con toda intención, no toca dim_date ni construye una sola tabla nueva. Toma el fact_orders que ya existe, y le hace la pregunta que foundations nunca le hizo con precisión: ¿qué representa exactamente una fila, y cómo lo sabes con certeza, no por intuición? Responder esa pregunta bien es lo que hace que el módulo 2 —donde sí vas a construir el star schema completo— tenga un cimiento sólido debajo.

Errores comunes

Asumir que, como foundations "ya modeló" a Kiosko, este módulo es repetición. Qué pasa: alguien que completó foundations ve fact_orders, dim_store y dim_product otra vez en este módulo y asume que no hay nada nuevo que aprender, porque el esquema es idéntico. Por qué pasa: el esquema, columna por columna, efectivamente no cambia en este módulo — el cambio está en el proceso que se aplica sobre ese esquema, no en el esquema en sí. Cómo detectarlo: si terminas este módulo sin poder recitar, de memoria, la frase exacta que declara el grano de fact_orders —no "una venta", sino la frase precisa de la lección 5—, te saltaste lo que este módulo realmente enseña. Cómo corregirlo: presta atención a la lección 5, no a las columnas —el valor de este módulo está en el proceso de declarar y verificar, no en tablas que ya conoces.

Saltar directo al módulo 2, porque "el star schema es lo interesante". Qué pasa: alguien impaciente por ver dimensiones conformadas y dim_date intenta empezar por el módulo 2, tratando este módulo 1 como un trámite. Por qué pasa: un star schema completo se siente más "avanzado" y visualmente más completo que una sola frase declarando un grano. Cómo detectarlo: si al construir un star schema en el módulo 2 no puedes explicar, sin dudar, por qué elegiste esa combinación específica de dimensiones para acompañar a fact_orders, es porque te faltó el paso 2 y 3 de Kimball que este módulo enseña primero. Cómo corregirlo: el orden de los ocho módulos de esta guía no es cronológico por casualidad — cada uno depende de una decisión que el anterior ya verificó. Este módulo 1 es la base sobre la que se apoyan los siete que siguen.

Confundir "declarar el grano" con "escribir un comentario en el código". Qué pasa: alguien escribe # grain: one row per order line como comentario en su script de Python y considera el trabajo terminado, sin verificar con ninguna consulta que el dato real cumple esa afirmación. Por qué pasa: un comentario se siente como suficiente documentación, y escribir una consulta de verificación parece un paso extra innecesario. Cómo detectarlo: si tu "declaración de grano" nunca se comparó contra un COUNT(*) real sobre el dato real, es una suposición con forma de comentario, no una declaración verificada. Cómo corregirlo: la lección 5 de este módulo va a mostrarte, con una consulta ejecutada de verdad, por qué la verificación importa — y por qué "yo creo que el grano es X" y "confirmé que el grano es X" son dos afirmaciones completamente distintas.

Ejercicios

Ejercicio 1 — Recuerda la deuda de foundations, sin mirar atrás. Sin releer el capstone de foundations, escribe de memoria una lista de al menos tres cosas que fact_orders/dim_store/dim_product no tienen todavía (por ejemplo: ¿tienen llave sustituta? ¿hay una tabla de calendario? ¿qué pasa si el precio de un producto cambia?). Después, compara tu lista con la sección "Por qué existe este módulo" de esta lección.

Ver solución

Una lista razonable, tomada directamente de esta lección: (1) dim_store y dim_product usan llave natural, no llave sustituta — no hay forma de historizar un cambio sin romper referencias existentes; (2) no existe dim_date, así que cualquier análisis por día, semana o mes tendría que derivarse de order_ts directamente, sin una dimensión de calendario reutilizable; (3) no hay una segunda tabla de hechos para el clickstream (events), aunque ese dato ya existe; (4) en ningún lugar se declaró, con precisión y verificado con una consulta, qué representa exactamente una fila de fact_orders — se dijo de forma informal, en una analogía. Si tu lista tiene al menos tres de estos cuatro puntos, tienes clara la deuda que esta guía empieza a cerrar.

Ejercicio 2 — Ordena los cuatro pasos de memoria. Sin mirar el ejemplo trabajado de esta lección, escribe los cuatro pasos del proceso de Kimball en el orden correcto, usando solo sus nombres en inglés (Select the business process, Declare the grain, Identify the dimensions, Identify the facts).

Ver solución
  1. Select the business process
  2. Declare the grain
  3. Identify the dimensions
  4. Identify the facts

Si invertiste el orden de los pasos 2 y 3 —pensando que las dimensiones se deciden antes que el grano—, presta especial atención a la lección 3 de este módulo: es, precisamente, el error que más se repite al aprender este proceso por primera vez, y la lección explica con un ejemplo concreto por qué ese orden específico importa.

Ejercicio 3 — Explica la analogía con tus propias palabras. Usando la analogía de la libreta de anotaciones y la contabilidad formal de esta lección, explica en 2-3 frases por qué fact_orders de foundations se parece más a la libreta que a la contabilidad formal, aunque técnicamente ya sea una tabla estructurada en CSV.

Ver solución

fact_orders de foundations ya tiene una estructura fija —columnas, tipos, un esquema consistente en cada fila—, así que no es literalmente una libreta desordenada. Pero se parece a ella en lo que importa: nadie declaró, antes de construirla, una frase precisa de qué representa una fila, ni verificó esa frase contra el dato real con una consulta — la unidad de registro se entendió por intuición ("una venta"), no por una decisión de diseño explícita y comprobada. La contabilidad formal —y el modelado dimensional real— exige declarar esa unidad antes, no inferirla después mirando el dato.

Resumen y siguiente paso

Este módulo cierra la primera deuda explícita que foundations dejó: declarar, formalmente y con verificación, qué representa exactamente una fila de fact_orders. No vas a construir ninguna tabla nueva — vas a aplicarle a la tabla que ya existe el proceso de cuatro pasos de Ralph Kimball (proceso de negocio → grano → dimensiones → hechos), empezando por el paso que la mayoría de los equipos se salta y que más caro les cuesta después: declarar el grano antes de escribir una sola línea de SQL de más.

Antes de avanzar deberías poder: nombrar los cuatro pasos del proceso de Kimball en orden; explicar, con tus propias palabras, por qué el grano se declara antes que las dimensiones; y decir de memoria qué tabla de Kiosko es el sujeto de todo este módulo.

La lección 2 empieza por donde se quedó foundations: nombra, con precisión y sin exagerar, qué dejó plano a propósito y por qué esa fue la decisión correcta para el alcance de esa guía — el punto de partida honesto antes de empezar a construir encima.

Recursos

Siguiente →Qué dejó plano foundations, y por qué