El esquema estrella: diseñando tu primera estructura analítica

Ya sabes qué son hechos y dimensiones. Ahora vamos a juntarlos en un patrón formal: el esquema estrella (star schema). Se llama así porque cuando lo dibujas en un diagrama ER, parece una estrella: la tabla de hechos en el centro y las dimensiones irradiando como puntas. Es el patrón más usado en Data Warehousing desde que Kimball lo popularizó en los 90, y sigue siendo el estándar en 2024.

La belleza del esquema estrella es su simplicidad para el usuario final. Un analista de negocio que sepa SQL básico puede escribir queries efectivas porque la estructura refleja cómo piensa sobre los datos: "dame las ventas (hecho) por categoría de producto (dimensión) y mes (dimensión) para clientes VIP (dimensión)". Cada pregunta de negocio se traduce directamente a un SELECT + JOINs contra la estrella.

### Reglas del esquema estrella

1. 01.UNA tabla de hechos en el centro — representa el proceso de negocio que mides
2. 02.Dimensiones alrededor — cada una conectada a la fact table por UNA foreign key
3. 03.Las dimensiones NO se conectan entre sí — solo a la fact table (esto es clave)
4. 04.La fact table contiene SOLO claves ajenas y métricas numéricas — ni un atributo descriptivo
5. 05.Las dimensiones son desnormalizadas (no hay tablas puente entre dimensiones)
6. 06.Cada dimensión tiene una surrogate key como PK
7. 07.Un esquema estrella = un proceso de negocio. Si tienes ventas Y envíos, son dos estrellas

### Ejemplo completo: estrella de ventas de un e-commerce

Vamos a diseñar paso a paso la estrella para el proceso "una línea de venta". El negocio quiere responder preguntas como: ventas por categoría, por mes, por región, por canal de adquisición, evolución de nuevos vs recurrentes, ticket medio por día de la semana, etc.

1-- ═══════════════════════════════════════════════════════
2-- ESQUEMA ESTRELLA: Ventas de e-commerce
3-- ═══════════════════════════════════════════════════════
4
5-- ─── DIMENSIONES ──────────────────────────────────────
6
7CREATE TABLE dim_date (
8    date_key        INTEGER PRIMARY KEY,
9    full_date       DATE NOT NULL UNIQUE,
10    day_name        VARCHAR(10),
11    month_name      VARCHAR(10),
12    month_number    SMALLINT,
13    quarter         SMALLINT,
14    year            SMALLINT,
15    is_weekend      BOOLEAN,
16    is_holiday      BOOLEAN
17);
18
19CREATE TABLE dim_customer (
20    customer_key    BIGINT PRIMARY KEY,
21    customer_id     VARCHAR(20),
22    full_name       VARCHAR(200),
23    email           VARCHAR(200),
24    country         VARCHAR(50),
25    city            VARCHAR(100),
26    segment         VARCHAR(30),
27    acquisition_channel VARCHAR(30),
28    first_order_date DATE
29);
30
31CREATE TABLE dim_product (
32    product_key     BIGINT PRIMARY KEY,
33    product_id      VARCHAR(20),
34    product_name    VARCHAR(200),
35    category        VARCHAR(50),
36    subcategory     VARCHAR(50),
37    brand           VARCHAR(100),
38    unit_cost       DECIMAL(10,2),
39    is_active       BOOLEAN
40);
41
42CREATE TABLE dim_store (
43    store_key       BIGINT PRIMARY KEY,
44    store_id        VARCHAR(10),
45    store_name      VARCHAR(100),
46    city            VARCHAR(100),
47    region          VARCHAR(50),
48    country         VARCHAR(50),
49    store_type      VARCHAR(20),   -- 'online', 'physical'
50    open_date       DATE
51);
52
53-- ─── TABLA DE HECHOS ──────────────────────────────────
54
55CREATE TABLE fact_sales (
56    -- Surrogate key del hecho (opcional pero útil)
57    sales_key       BIGINT PRIMARY KEY,
58    -- Foreign keys a dimensiones
59    date_key        INTEGER NOT NULL REFERENCES dim_date(date_key),
60    customer_key    INTEGER NOT NULL REFERENCES dim_customer(customer_key),
61    product_key     INTEGER NOT NULL REFERENCES dim_product(product_key),
62    store_key       INTEGER NOT NULL REFERENCES dim_store(store_key),
63    -- Dimensión degenerada (no tiene su propia tabla)
64    order_number    VARCHAR(20),
65    -- Métricas
66    quantity        SMALLINT NOT NULL,
67    unit_price      DECIMAL(10,2) NOT NULL,
68    discount_pct    DECIMAL(5,2) DEFAULT 0,
69    net_amount      DECIMAL(12,2) NOT NULL,  -- quantity * unit_price * (1-discount)
70    tax_amount      DECIMAL(10,2),
71    shipping_cost   DECIMAL(10,2)
72);

### Esquema snowflake: cuando normalizas las dimensiones

Una variante es el esquema copo de nieve (snowflake): en vez de tener todos los atributos en una dimensión plana, normalizas la dimensión. Por ejemplo, en vez de dim_product con category como VARCHAR, creas una tabla separada dim_category y dim_product apunta a ella con un FK. Visualmente, la estrella se convierte en un copo de nieve con ramificaciones.

¿Cuándo usar snowflake? Casi nunca. La normalización ahorra un poco de espacio, pero el espacio en un warehouse es barato. Lo que NO es barato es el rendimiento: cada JOIN adicional es tiempo de ejecución y complejidad para el analista. El consenso de la industria: usa star schema por defecto. Solo normaliza una dimensión si es MUY grande (millones de filas) y la normalización reduce significativamente su tamaño.

### Conformed dimensions: reutilizar entre estrellas

Una empresa no tiene una sola estrella — tiene varias. Ventas, envíos, devoluciones, visitas web, campañas de marketing. ¿Qué pasa si cada estrella tiene su propia dim_customer con definiciones diferentes de "segmento"? Caos. Los números no cuadran entre departamentos.

La solución de Kimball: conformed dimensions. Son dimensiones compartidas entre múltiples fact tables, con la MISMA definición y los MISMOS valores. dim_date es la conformed dimension más obvia — todas las estrellas usan la misma. dim_customer debería ser la misma en ventas, soporte y marketing. Esto es lo que permite hacer queries "cross-process": "clientes que compraron en Q4 Y abrieron un ticket de soporte".

### Errores comunes al diseñar estrellas

• ▹Meter atributos descriptivos en la fact table — si no es sumable/promediable, es dimensión
• ▹Crear dimensiones con pocas filas que deberían ser junk dimensions (flags, estados)
• ▹No incluir dim_date — usar funciones de fecha directamente sobre un timestamp en la fact
• ▹Conectar dimensiones entre sí — viola el principio de la estrella y complica queries
• ▹Mezclar granularidades en la misma fact table (ventas diarias Y mensuales juntas)
• ▹Usar natural keys como FK en la fact table — siempre surrogate keys