Data Vault 2.0 y alternativas al esquema estrella

El esquema estrella de Kimball ha sido el rey indiscutible del modelado dimensional durante 30 años. Y sigue siendo la opción correcta para la gran mayoría de los casos. Pero como ingeniero de datos, necesitas saber que existen ALTERNATIVAS. No para que las domines todas — sino para que cuando alguien en una entrevista o en un proyecto mencione "Data Vault" o "One Big Table", no te quedes en blanco. Esta lección es contexto y criterio, no dominio profundo.

La pregunta fundamental es: ¿cuándo Kimball NO es suficiente? Respuesta corta: cuando tienes muchas fuentes de datos que cambian frecuentemente, cuando necesitas auditoría total, o cuando el esquema no es estable (el negocio cambia de opinión sobre qué analizar cada trimestre). En esos escenarios, las alternativas brillan.

### Data Vault 2.0: la bóveda de datos

Data Vault fue creado por Dan Linstedt en los años 2000 como respuesta a un problema real: las empresas con decenas de sistemas fuente (ERP + CRM + legacy + APIs + archivos) encontraban que el esquema estrella era FRÁGIL. Cada vez que añadías una fuente nueva o el negocio reorganizaba un departamento, tenías que rediseñar tus dimensiones. Data Vault resuelve esto separando estructura de contexto de una forma radical.

¿Y por qué «2.0»? El método original es de 2000. La versión 2.0, publicada en 2013, es la que se usa hoy: añade la arquitectura y las prácticas de carga para volúmenes grandes, y sobre todo cambia las claves. Antes eran números de secuencia (como SERIAL); ahora son hashes de la clave de negocio. Y ese cambio no es cosmético: con una secuencia, para insertar en el link hay que haber cargado antes los hubs y preguntarles su número. Con un hash, la clave se calcula desde el propio patient_id, así que los hubs, links y satélites se pueden cargar los seis a la vez, en paralelo y en cualquier orden. Con 25 sistemas fuente, eso es la diferencia entre una carga de horas y una de minutos.

La analogía: si el esquema estrella es un cuadro pintado (bonito pero rígido — si quieres cambiar algo, repintas), Data Vault es un álbum de fotos con LEGO. Cada pieza encaja con las demás independientemente, y puedes añadir piezas nuevas sin destruir las existentes. Es más complejo de construir, pero más flexible ante cambios.

### Los 3 componentes de Data Vault

• ▹Hubs: representan entidades de negocio (cliente, producto, pedido). Solo contienen la business key + metadata. Una tabla por entidad.
• ▹Links: representan RELACIONES entre entidades (cliente-compra-producto). Son tablas de asociación que conectan hubs.
• ▹Satellites: contienen los ATRIBUTOS descriptivos y su historial. Cada cambio es una nueva fila. Es donde vive toda la información "útil".

1-- Data Vault 2.0: ejemplo simplificado
2
3-- HUB: solo la business key del cliente (mínimo absoluto)
4CREATE TABLE hub_customer (
5    hub_customer_hash   CHAR(64) PRIMARY KEY,  -- SHA-256 de business key
6    customer_bk         VARCHAR(50) NOT NULL,   -- business key original
7    load_date           TIMESTAMP,
8    record_source       VARCHAR(50)             -- de dónde vino
9);
10
11-- HUB: solo la business key del producto
12CREATE TABLE hub_product (
13    hub_product_hash    CHAR(32) PRIMARY KEY,
14    product_bk          VARCHAR(50) NOT NULL,
15    load_date           TIMESTAMP,
16    record_source       VARCHAR(50)
17);
18
19-- LINK: relación "cliente compró producto"
20CREATE TABLE link_purchase (
21    link_purchase_hash  CHAR(32) PRIMARY KEY,
22    hub_customer_hash   CHAR(32) REFERENCES hub_customer,
23    hub_product_hash    CHAR(32) REFERENCES hub_product,
24    purchase_bk         VARCHAR(50),           -- order_number
25    load_date           TIMESTAMP,
26    record_source       VARCHAR(50)
27);
28
29-- SATELLITE: atributos del cliente (CON historial completo)
30CREATE TABLE sat_customer_details (
31    hub_customer_hash   CHAR(32) REFERENCES hub_customer,
32    load_date           TIMESTAMP,
33    -- Atributos (cambian con el tiempo)
34    name                VARCHAR(200),
35    city                VARCHAR(100),
36    segment             VARCHAR(30),
37    email               VARCHAR(200),
38    -- Metadata
39    hash_diff           CHAR(32),      -- hash de los atributos (detectar cambios)
40    record_source       VARCHAR(50),
41    PRIMARY KEY (hub_customer_hash, load_date)
42);

### Cuándo considerar Data Vault

• ▹Muchas fuentes de datos (10+) que se integran en un warehouse central
• ▹Las fuentes cambian frecuentemente (nuevos campos, reorganizaciones)
• ▹Necesitas auditoría total: saber de DÓNDE vino cada dato y CUÁNDO llegó
• ▹El equipo es grande y necesita trabajar en paralelo sin pisarse
• ▹Normativa estricta (banca, sanidad) que requiere trazabilidad completa

### Cuándo NO usar Data Vault

• ▹Equipos pequeños (1-3 personas) — la complejidad no compensa
• ▹Pocas fuentes de datos (2-3 sistemas)
• ▹Necesitas resultados rápidos — Data Vault tarda más en dar valor inicial
• ▹El negocio quiere consultar directamente — Data Vault NO es user-friendly para BI
• ▹Tu warehouse es un data mart departamental (no enterprise)

Lo que cuesta Data Vault, medido. Misma pregunta de negocio, mismos 2 millones de hechos: la estrella la responde con 2 JOINs en 41 ms y ocupa 3 MB en Parquet; Data Vault necesita 5 JOINs, tarda 447 ms (10× más lento) y ocupa 119 MB (38× más espacio). El espacio se dispara porque las claves hash de 32 caracteres son aleatorias y no se comprimen — a diferencia de un INTEGER con 200.000 valores distintos, que el diccionario columnar reduce a casi nada. Consejo práctico: si implementas Data Vault, guarda la clave hash en binario (16 bytes), no como texto hexadecimal.

Y por eso nadie consulta un Data Vault directamente: encima se construyen marts en estrella (la "capa de presentación"), que son las tablas que ven los analistas y los dashboards. Data Vault es la bóveda — donde se guarda todo con trazabilidad. La estrella es el escaparate — donde se consulta rápido. En proyectos grandes coexisten las dos, una debajo de la otra.

### One Big Table (OBT): el anti-patrón que a veces funciona

El enfoque opuesto a la normalización: meter TODA la información en UNA sola tabla enorme. Sin JOINs. Sin dimensiones separadas. Una tabla de 50-100 columnas con todo lo que necesitas. Suena horrible desde un punto de vista académico, pero con los motores columnares modernos (BigQuery, Snowflake, DuckDB), funciona sorprendentemente bien para ciertos casos.

1-- ONE BIG TABLE: todo desnormalizado en una sola tabla
2CREATE TABLE obt_sales (
3    -- De lo que sería fact_sales:
4    order_date          DATE,
5    quantity            INTEGER,
6    revenue             DECIMAL(12,2),
7    -- De lo que sería dim_customer:
8    customer_name       VARCHAR(200),
9    customer_country    VARCHAR(50),
10    customer_segment    VARCHAR(30),
11    -- De lo que sería dim_product:
12    product_name        VARCHAR(200),
13    product_category    VARCHAR(50),
14    product_brand       VARCHAR(100),
15    -- De lo que sería dim_date:
16    month_name          VARCHAR(10),
17    quarter             SMALLINT,
18    year                SMALLINT,
19    is_weekend          BOOLEAN,
20    -- 30 columnas más...
21    store_city          VARCHAR(100),
22    store_region        VARCHAR(50),
23    promo_name          VARCHAR(100),
24    promo_discount_pct  DECIMAL(5,2)
25);
26
27-- Ventaja: queries triviales sin JOINs
28SELECT product_category, SUM(revenue)
29FROM obt_sales
30WHERE customer_segment = 'VIP' AND year = 2024
31GROUP BY product_category;
32
33-- Sin estrella, sin JOINs, sin surrogate keys. Simple.

OBT funciona bien cuando: tienes un caso de uso específico (un dashboard), no necesitas mantener historial (no SCD), y quieres que analistas sin SQL avanzado puedan consultarla directamente. NO funciona cuando: necesitas múltiples procesos de negocio, necesitas SCD, o la tabla crecería a cientos de columnas sin sentido.

### El panorama moderno: herramientas que influyen en el modelado

En 2024, herramientas como dbt han cambiado la conversación. Con dbt puedes definir modelos de datos como archivos SQL versionados en Git, con tests automáticos y documentación generada. Esto hace que mantener un esquema estrella sea MUCHO más fácil que hace 10 años. También permite adoptar enfoques híbridos: staging → intermediate (donde haces la lógica pesada) → marts (estrella final para cada departamento).

• ▹dbt: transforma SQL en un framework con tests, docs y linaje. Hace viable el ELT con SQL puro.
• ▹Medallion architecture (Databricks): Bronze → Silver → Gold es esencialmente raw → clean → analytics.
• ▹Activity schema: un enfoque minimalista donde todos los eventos se guardan en una sola tabla (entity, activity, timestamp, attributes_json).
• ▹Metrics layer (dbt metrics, Looker, MetricFlow): define métricas UNA vez y reutilízalas en cualquier query.

### Resumen: cuándo usar qué