El esquema estrella: leer el mapa del almacén

En 1996, un consultor llamado Ralph Kimball publicó un libro que cambió la forma en que se organizan los datos para análisis. La idea central era tan visual que se podía dibujar en una servilleta: pon la tabla de hechos en el centro, rodéala de dimensiones, y conéctalas con líneas. El resultado parece una estrella. Ese patrón se llama esquema estrella (star schema), y si abres el diagrama ER del almacén de casi cualquier empresa mediana o grande del mundo, vas a ver exactamente eso.

Ya sabes distinguir hechos de dimensiones. Ahora vas a ver cómo se organizan en un patrón concreto que puedes leer como un mapa: el centro te dice qué se mide, las puntas te dicen por qué ángulos puedes mirar esos números. Ese mapa es tu guía para escribir cualquier query sin perderte, sin duplicar filas, y sin dejar datos fuera.

### La forma de estrella: por qué se llama así

Dibuja un círculo en el centro de un papel. Escribe dentro "fact_ventas". Ahora dibuja cuatro círculos alrededor y conéctalos con líneas al centro: dim_producto, dim_cliente, dim_fecha, dim_tienda. Lo que tienes se parece a una estrella: un núcleo y puntas irradiando. Esa es la estructura. No es una metáfora bonita: es un patrón de ingeniería con reglas concretas que afectan a cómo escribes tus queries.

La regla principal del esquema estrella: las dimensiones se conectan SOLO al hecho central, nunca entre sí. dim_producto no tiene una línea a dim_cliente. No hay una tabla intermedia entre la fecha y la tienda. Todo pasa por el centro. Esto significa que en tus queries, SIEMPRE empiezas por la tabla de hechos y haces JOINs directos a las dimensiones que necesites. Nunca JOIN de dimensión a dimensión pasando por el hecho.

### Leer el mapa: qué te dice el esquema antes de escribir una query

Antes de escribir una sola línea de SQL, mirar el esquema estrella te dice tres cosas. Primera: qué puedes medir (las columnas numéricas del hecho central). Segunda: por qué ángulos puedes mirar esos números (cada dimensión es un ángulo: por producto, por cliente, por fecha, por tienda). Tercera: qué combinaciones son posibles. Si no hay una dimensión de canal de marketing conectada al hecho, no puedes agrupar por canal — el dato no está ahí.

1. 01.Mira el hecho central: sus métricas te dicen QUÉ puedes calcular (ventas, cantidad, coste...)
2. 02.Mira las dimensiones alrededor: te dicen POR QUÉ puedes agrupar y filtrar (categoría, país, mes...)
3. 03.Si una dimensión no está conectada, no puedes cruzar por ahí — tendrías que pedirla al equipo de ingeniería
4. 04.El número de filas del hecho te anticipa si tu query será rápida o lenta
5. 05.Los atributos de cada dimensión te dicen el nivel de detalle disponible (si dim_fecha solo tiene mes, no puedes agrupar por día)

### El peligro de multiplicar filas: JOINs que engañan

El esquema estrella está diseñado para que cada JOIN sea seguro: una fila del hecho se une con exactamente una fila de la dimensión. Por eso funciona el patrón FROM hecho JOIN dimensión — nunca multiplicas filas. PERO esto solo se cumple si la dimensión tiene una sola fila por cada valor de la clave. Si por algún motivo la dimensión tiene duplicados (dos filas con el mismo id_producto), tu JOIN multiplica las ventas de ese producto por dos. Y tu SUM sale el doble de lo que debería.

Este es el error más peligroso del analista, porque es invisible. El número sale "bien" — no da error, no rompe nada. Simplemente es incorrecto, y solo lo descubres cuando alguien dice "esto no cuadra con lo que yo tengo" o cuando comparas contra otra fuente. La regla de oro: si tras un JOIN el número de filas aumenta, algo está multiplicando. Siempre comprueba el COUNT(*) antes y después del JOIN cuando un resultado te parezca demasiado alto.

1-- Comprobación rápida: ¿mi JOIN multiplica filas?
2-- ANTES del JOIN:
3SELECT COUNT(*) FROM fact_ventas;           -- 47.231.000
4
5-- DESPUÉS del JOIN:
6SELECT COUNT(*)
7FROM fact_ventas f
8JOIN dim_producto p ON f.id_producto = p.id_producto;
9-- Si da 47.231.000 → OK, no multiplica
10-- Si da 49.000.000 → PROBLEMA: hay duplicados en dim_producto
11
12-- Y si crece, ¿quién es el culpable? Se le pregunta a la dimensión:
13SELECT id_producto, COUNT(*) AS veces
14FROM dim_producto
15GROUP BY id_producto
16HAVING COUNT(*) > 1;
17-- Cada fila que salga es un id repetido, y el "veces" te dice
18-- por cuánto está multiplicando tus ventas.

¿Y qué haces cuando el COUNT te dice que sí multiplica? Tres cosas, en este orden. Primera: no lo arregles a escondidas. Un DISTINCT puesto encima tapa el síntoma y te deja sin saber qué fila era la buena. Segunda: mira qué filas están repetidas, porque a veces no es un error sino una dimensión con historial —el mismo producto con dos versiones—, y ese caso tiene solución propia, que es de lo que va la lección de dimensiones que cambian. Tercera: si de verdad es una carga mal hecha, es un asunto del equipo de ingeniería, y avisar cuanto antes es parte de tu trabajo. Mientras tanto, cualquier número que hayas mandado con ese JOIN dentro está inflado, y decirlo tú antes que otro es la diferencia entre un aviso y un problema.

### Un esquema, muchas preguntas

La belleza del esquema estrella es que un solo modelo responde cientos de preguntas diferentes. Con fact_ventas rodeada de dim_producto, dim_cliente, dim_fecha y dim_tienda, puedes responder: ventas por categoría, ventas por país, ventas por trimestre, top 10 clientes, productos con más descuento, tiendas que más crecen, comparativa interanual por región... todo con el mismo patrón: FROM hecho JOIN dimensiones WHERE filtros GROUP BY atributo.

Cada nueva dimensión que se añade al modelo es un nuevo ángulo para mirar los mismos números. Si mañana el equipo de ingeniería añade dim_campana_marketing conectada al hecho, de repente puedes responder "ventas por campaña" sin tocar nada más. Es como añadir una lente nueva a un microscopio: los datos son los mismos, pero ahora puedes verlos desde otra perspectiva.

### Esquema copo de nieve: la variante que a veces encuentras

Algunos almacenes no usan estrella pura. Usan una variante llamada esquema copo de nieve (snowflake schema), donde las dimensiones están a su vez normalizadas: dim_producto apunta a dim_categoria que apunta a dim_departamento. El hecho sigue en el centro, pero las dimensiones tienen "subdimensiones". Para ti como analista, esto significa más JOINs para llegar al atributo que necesitas — en vez de un JOIN directo a dim_producto.categoria, haces dos: dim_producto → dim_categoria.

En la práctica, la mayoría de almacenes modernos prefieren la estrella pura porque es más simple de consultar. Si te encuentras un copo de nieve, no pasa nada grave: el patrón es el mismo, solo que con un salto más. Pero si tienes la oportunidad de opinar sobre el diseño, la estrella es más amigable para el analista que el copo de nieve.

### Resumen: cómo leer cualquier almacén

1. 01.Busca la tabla de hechos: es la más grande, tiene números y claves. Todo irradia de ella.
2. 02.Identifica las dimensiones: son las tablas pequeñas con texto descriptivo, conectadas al hecho.
3. 03.Cada línea del diagrama es un JOIN que puedes hacer. Si no hay línea, no hay conexión directa.
4. 04.Tus queries SIEMPRE empiezan por FROM hecho JOIN dimensión(es) WHERE filtros GROUP BY atributo.
5. 05.Comprueba que los JOINs no multiplican filas (COUNT antes y después).
6. 06.Si te falta una dimensión, no intentes inventarla con subqueries: pídela al equipo de ingeniería.

Ya tienes el mapa visual: un centro con números, puntas con contexto, líneas que las conectan. En la siguiente lección vas a profundizar en algo que determina si tus números salen correctos o no: la granularidad. Porque no basta con saber qué tablas hay — necesitas saber qué representa CADA FILA de la tabla de hechos para no contar de más ni de menos.