Línea de tiempo, tres granos

El mismo dato diario, semanal y mensual. El punto de la clase es que el grano cambia la historia, y eso sólo se ve superponiendo.

La forma la decide el trabajo que hace el dato —magnitud, identidad, polaridad, cambio en el tiempo, distribución—, no el gusto. Regla del curso: un solo eje.

Contéstalas de memoria, sin abrir apuntes ni el notebook de la clase anterior (espaciado 1–3–7–21):

1. Sesión 17 · ¿Qué va en dim_fecha y por qué se construye una sola vez?
2. Sesión 15 · ¿Cuáles son las cuatro verificaciones del modelo de Austral?
3. Sesión 11 · ¿Cuál es el orden de ataque frente a un archivo nuevo, en sus cuatro pasos?

Par (2 min) → plenaria (3 min).

La respuesta a la pregunta colgada, dicha por ellos y escrita en la pizarra:

La prueba de suma cruzada. Si tres vistas del mismo hecho dan tres totales distintos, una está mal —y es la que te va a explotar en la reunión. El control no es opcional: es lo que separa un entregable de un borrador.

Preguntas que quedan planteadas hoy: al cierre.

Esto es exactamente lo que vas a tener que hacer solo en tres semanas. Antes de escribir una línea de SQL, contesta las cuatro:

1. Filtro desde 2018 → ¿sobre el hecho o sobre cada vista? (sobre el hecho, una sola vez: si se filtra en cada vista, tarde o temprano una se te queda sin filtro)
2. Fecha dd-mm-yyyy → ¿al agrupar o al exportar? (al exportar: si agrupas por texto, "01-02-2018" y "01-12-2018" se ordenan mal)
3. Tres granularidades → la estructura es idéntica; lo único que cambia es el DATE_TRUNC.
4. Cantidades: SUM. Precios: AVG. Y ojo: "promediar precios" no es una sola cosa, como se va a ver a las 21:40.

«El requisito tiene cuatro líneas y cuatro decisiones escondidas. En la prueba, el que responde las cuatro sin darse cuenta de que eran decisiones, saca 4. El que las declara, saca 7.»

Es otra noche: la base parte vacía. Antes de correr nada, el recall real —preguntarles a ellos, no mostrarlo—: «¿qué tablas dejamos ayer y cuál era el grano del hecho?» Recoger las cinco en voz alta y recién entonces reconstruirlas, en silencio, en dos segundos:

duckdb -init herramientas/cargar.sql

.read herramientas/modelo-alimentaria.sql
-- ven_limpia 15.355 · dim_producto 10 · dim_proveedor 4 · dim_fecha 1.461 · fact_ventas 15.355

-- 🔨 ACTIVIDAD · córrela: la base filtrada y las tres vistas
-- la base filtrada, UNA sola vez (regla de negocio: 2017 no se usa)
CREATE VIEW fact_2018 AS
SELECT * FROM fact_ventas WHERE EXTRACT(year FROM fecha_key) >= 2018;

-- 1) diaria
CREATE VIEW vista_diaria AS
SELECT fecha_key AS periodo,
       SUM(cantidad)                  AS cantidad,
       ROUND(AVG(precio_unitario), 1) AS precio_prom
FROM fact_2018 GROUP BY 1;

-- 2) semanal
CREATE VIEW vista_semanal AS
SELECT DATE_TRUNC('week', fecha_key) AS periodo,
       SUM(cantidad)                  AS cantidad,
       ROUND(AVG(precio_unitario), 1) AS precio_prom
FROM fact_2018 GROUP BY 1;

-- 3) mensual
CREATE VIEW vista_mensual AS
SELECT DATE_TRUNC('month', fecha_key) AS periodo,
       SUM(cantidad)                  AS cantidad,
       ROUND(AVG(precio_unitario), 1) AS precio_prom
FROM fact_2018 GROUP BY 1;

«Tres vistas, una sola idea. La granularidad no es una tabla distinta: es una decisión de agrupación. El que entiende eso escribe la cuarta en veinte segundos.»

Inspección visual, obligatoria antes de creerle a nada:

-- 🔨 ACTIVIDAD · córrela y mírala: ¿está el año completo?
SELECT * FROM vista_mensual ORDER BY periodo LIMIT 12;

Dos preguntas dirigidas sobre lo que aparece en pantalla: ¿está el año completo? ¿Y por qué las cantidades se mueven mucho y los precios casi nada? (Guardarse esa segunda observación: es la semilla de la sesión 21.)

-- 🔨 ACTIVIDAD · córrela tú: las tres vistas tienen que sumar lo mismo
SELECT (SELECT SUM(cantidad) FROM vista_diaria)  AS diaria,
       (SELECT SUM(cantidad) FROM vista_semanal) AS semanal,
       (SELECT SUM(cantidad) FROM vista_mensual) AS mensual;
-- 1.009.104 · 1.009.104 · 1.009.104

Las tres iguales, y el número es el de ayer. Y los conteos de filas, que también se comparan:

-- 🔨 ACTIVIDAD · córrela tú: los períodos también tienen que cuadrar
SELECT (SELECT COUNT(*) FROM vista_diaria)  AS dias,
       (SELECT COUNT(*) FROM vista_semanal) AS semanas,
       (SELECT COUNT(*) FROM vista_mensual) AS meses;
-- 1.096 · 157 · 36

«1.096 días son exactamente tres años (2018, 2019 y 2020, con el 29 de febrero de 2020 adentro). 36 meses son exactamente tres años. Si te da 35, te falta un mes; y ese mes tiene ventas.»

La suma cruzada ya dijo que las tres vistas son el mismo dato. Ahora se mira si cuentan la misma historia. Para poder superponerlas hay un paso que no se salta: las tres se llevan a unidades por día. Un total mensual y un total diario no caben en el mismo eje —son escalas distintas— y meterlos igual sería el error que la clase 18 desarma. Con la misma unidad, la superposición es legítima.

# 👀 SE MIRA · el gráfico ya viene escrito: se corre y se mira
import matplotlib.pyplot as plt

GRIS, TINTA, ALERTA = "#b8b8b8", "#102a38", "#8c2b20"

# Las tres, en la MISMA unidad: unidades por día. Sin esto no se pueden superponer.
dia = bd.sql("SELECT periodo, cantidad AS por_dia FROM vista_diaria ORDER BY 1")
sem = bd.sql("""SELECT DATE_TRUNC('week', periodo) AS periodo,
                       SUM(cantidad) / COUNT(*) AS por_dia
                FROM vista_diaria GROUP BY 1 ORDER BY 1""")
mes = bd.sql("""SELECT DATE_TRUNC('month', periodo) AS periodo,
                       SUM(cantidad) / COUNT(*) AS por_dia
                FROM vista_diaria GROUP BY 1 ORDER BY 1""")

fig, eje = plt.subplots(figsize=(11, 5))
eje.plot(dia.periodo, dia.por_dia, color="#d8d8d8", linewidth=0.6,
         label=f"diaria · {len(dia)} puntos")
eje.plot(sem.periodo, sem.por_dia, color=GRIS, linewidth=1.3,
         label=f"semanal · {len(sem)} puntos")
eje.plot(mes.periodo, mes.por_dia, color=ALERTA, linewidth=2.4,
         label=f"mensual · {len(mes)} puntos")

for _, f in dia.nlargest(3, "por_dia").iterrows():
    eje.annotate(f"{f.periodo:%d-%m-%Y}\n{f.por_dia:,.0f}".replace(",", "."),
                 xy=(f.periodo, f.por_dia), xytext=(6, -4),
                 textcoords="offset points", fontsize=8, color=TINTA)

eje.set_title("Las tres vistas suman las mismas 1.009.104 unidades.\n"
              "El día tiene tres torres que el mes borra sin avisar",
              fontsize=13, color=TINTA, loc="left")
eje.set_ylabel("unidades por día", fontsize=9)
eje.legend(frameon=False, fontsize=9, loc="upper right")
for lado in ("top", "right"):
    eje.spines[lado].set_visible(False)
fig.tight_layout()
plt.show()

Qué se mira en el resultado:

1. Que las tres líneas viven en la misma banda. Tienen que: es el mismo dato. Si una se despega, la vista está mal construida y la suma cruzada lo habría dicho antes.
2. Las tres torres de la línea diaria. El 19-07-2018, el 12-06-2019 y el 17-10-2020. La línea semanal las convierte en un bulto y la mensual las hace desaparecer. Ninguna de las tres vistas miente: cada una responde una pregunta distinta.
3. Y por eso la pregunta que hay que dejar colgada: si el informe mensual es el que sube a la gerencia, ¿quién se enteró de esos tres días? Guárdenlos — el martes que viene son la clase entera.
4. El eje vertical dice «unidades por día», no «unidades». Ese rótulo es la razón por la que las tres pueden estar en el mismo gráfico. Sin él, el gráfico es una trampa.

«307.331 unidades de más. Son las 3.814 filas de 2017 que se colaron por una vista a la que se le olvidó el filtro. Y fíjense en lo peligroso: el número no se ve raro. Es plausible, es del mismo orden de magnitud, y un gráfico con él se ve perfecto. Sólo la suma cruzada lo delata.»

La regla del bloque, para el Parcial 2: las tres vistas se construyen sobre la misma base filtrada. Un filtro escrito tres veces es un filtro que algún día va a estar escrito de dos formas.

• El promedio de promedios (2.349,85) casi no falla aquí, porque los meses tienen un número parecido de ventas. Difiere del simple en una centésima. "Y por eso es traicionero: funciona hasta el día en que un mes tiene la mitad de los datos, y ahí falla sin avisar."
• El promedio ponderado por cantidad (1.817,93) es 532 pesos más bajo. No es un error: es otra pregunta. El simple responde "¿cuánto cuesta un producto típico?"; el ponderado responde "¿a qué precio promedio se vendió cada unidad que salió de la bodega?". Para planificar compras, la segunda.

Y el detalle que hay que mostrar porque va a aparecer en el parcial:

-- 👀 SE MIRA · los precios nulos que AVG ignora en silencio
SELECT COUNT(*) AS precios_nulos FROM fact_2018 WHERE precio_unitario IS NULL;
-- 10

«AVG ignora los nulos en silencio: esas 10 filas no están en el denominador y nadie te avisó. Son 10 de 11.541, así que no mueve la aguja —pero tú tienes que saberlo antes de que te lo pregunten, no después.»

-- 🔨 ACTIVIDAD · córrela tú y después abre el archivo que sale
COPY (
  SELECT strftime(periodo, '%d-%m-%Y') AS periodo, cantidad, precio_prom
  FROM vista_diaria
  ORDER BY periodo
) TO 'salidas/vista_diaria_ddmmyyyy.csv' (HEADER, DELIMITER ',');

Se abre el CSV resultante en un editor de texto y se mira la primera línea: 01-01-2018,852,2210.6.

«La plataforma ya puede comer. Y este archivo es un entregable de la etapa 1 del parcial.»

El detalle que cuesta puntos: el ORDER BY periodo se hace sobre la fecha, no sobre el texto. Se demuestra en dos segundos —si se ordena el texto, 01-02-2018 va antes que 01-01-2019 y el archivo sale desordenado. La fecha se formatea al final, nunca antes de ordenar.

El experto de esta sesión — Control de Gestión:

«DATE_TRUNC('week', ...) en DuckDB parte las semanas el lunes. Es una decisión que tomó la herramienta por ti, y tú la vas a firmar. Entonces: ¿la semana del reporte parte el lunes o el domingo? ¿Y el mes cierra el 30 o el último día hábil?»

Se muestra, medido, lo que cambia:

«El total no se mueve un gramo. Pero cada comparación semanal sí, y con el criterio domingo aparece en tu reporte "desde 2018" un período etiquetado 2017. Imagínate explicando eso en un comité.

La respuesta no está en la documentación de DuckDB: está en Control de Gestión, porque tiene que calzar con el resto de los informes de la empresa. Y si no puedes preguntar, se declara: "semanas ISO, de lunes a domingo".»

1. Vista trimestral —la cuarta granularidad, para probar que el patrón se repite: DATE_TRUNC('quarter', ...). Debe dar 12 trimestres y sumar 1.009.104.
2. Demanda diaria promedio por producto (JOIN con dim_producto): la Harina de trigo lidera con 152,0 unidades/día y el Cacao cierra con 44,3. Es el germen del requisito 3.2 del parcial.
3. Bonus: ¿qué día de la semana se vende más? (JOIN con dim_fecha.dia_sem). El fin de semana vende casi la mitad que un martes: 94.206 unidades el domingo contra 169.764 el martes. ¿Eso es demanda o es que la bodega no despacha domingo? —otra pregunta para el experto.

# 🔨 ACTIVIDAD — escribe TÚ estas consultas. Acá no viene la respuesta.
# Descomenta la llamada a bd.sql() de cada una cuando la tengas escrita.

vista_trimestral = """
-- 1) La cuarta granularidad: DATE_TRUNC('quarter', ...) sobre fact_2018.
--    Tiene que dar 12 trimestres y sumar 1.009.104.
"""
# bd.sql(vista_trimestral)

demanda_por_producto = """
-- 2) Demanda diaria promedio por producto: JOIN de fact_2018 con dim_producto.
--    La Harina de trigo tiene que salir primera, con 152,0 unidades por día.
"""
# bd.sql(demanda_por_producto)

dia_de_semana = """
-- 3) BONUS: ¿qué día de la semana se vende más? JOIN con dim_fecha.dia_sem.
--    El domingo tiene que dar casi la mitad que el martes.
"""
# bd.sql(dia_de_semana)

Síntesis, construida con ellos:

1. «¿Cómo pruebas que tus vistas están bien?» → suma cruzada y conteo de períodos.
2. «¿Dónde va el filtro?» → en la base, una sola vez.
3. «¿Cuándo se formatea la fecha?» → al final, después de ordenar.
4. «¿Cuál promedio?» → el que responda tu pregunta, declarado.

Anki S7–S9: el tramo de modelamiento completo entra al mazo hoy.

Preguntas que quedan planteadas (se escriben en la pizarra y no se responden):

→ Las tres vistas cuadran en SQL. Si mañana el equipo trabaja en Python, ¿te va a dar el mismo número?

→ Y si no da lo mismo, ¿qué revisas primero: la herramienta, o la decisión que declaraste?