Modelando segundo o Data Vault 2.0

Uma abordagem robusta para data warehousing que abraça a mudança em vez de temê-la

O problema que ninguém escapa

Todo data warehouse começa limpo e organizado. E todo data warehouse, mais cedo ou mais tarde, encontra a realidade: uma nova fonte de dados aparece, um sistema de origem muda uma coluna, uma regra de negócio se altera, e a estrutura elegante que você projetou começa a rachar.

As modelagens clássicas sofrem com isso. Um modelo dimensional puro, do tipo estrela, é maravilhoso para consumo e análise, mas frágil quando a integração de muitas fontes voláteis entra em cena. Cada mudança na origem tende a exigir retrabalho, e o rastro de onde cada dado veio se perde no caminho.

É exatamente essa dor que a metodologia Data Vault se propõe a resolver. Criada por Dan Linstedt e hoje consolidada na sua segunda geração, o Data Vault 2.0, ela oferece uma forma de modelar a camada de integração de um data warehouse que não teme a mudança. Pelo contrário: ela é desenhada para absorver mudança como parte natural da vida.

Neste artigo, vou mostrar como o Data Vault pensa, seus três componentes essenciais, o que mudou na versão 2.0 e, principalmente, onde ele se encaixa numa arquitetura moderna de dados. Vamos usar um domínio simples e familiar como fio condutor: clientes e pedidos.

O que é, de fato, o Data Vault

O Data Vault é uma metodologia de modelagem voltada à camada de integração de um data warehouse. A palavra “integração” é a chave aqui, e voltarei a ela.

Sua premissa central é separar três coisas que as modelagens tradicionais misturam: as chaves de negócio (o que identifica uma entidade), os relacionamentos entre entidades, e os atributos descritivos que mudam ao longo do tempo. Ao manter essas três coisas em estruturas distintas, o modelo ganha uma propriedade rara: você pode acrescentar uma fonte nova, ou lidar com uma origem que mudou, sem mexer no que já existe.

Isso se apoia em quatro princípios que valem enunciar antes dos detalhes.

Flexibilidade. Novas fontes e novos atributos entram por adição, não por alteração. Você estende o modelo em vez de reformá-lo.

Escalabilidade. A estrutura suporta grandes volumes e, por ser altamente paralelizável na carga, cresce bem com a organização.

Resiliência à mudança. Fontes que mudam não quebram o warehouse. O impacto de uma alteração fica contido em estruturas específicas, sem efeito dominó.

Rastreabilidade. Cada registro carrega a marca de onde veio e de quando chegou. Para governança, auditoria e conformidade, isso é ouro.

Os três componentes: Hub, Link e Satélite

Aqui está o coração da metodologia. O Data Vault modela tudo com apenas três tipos de tabela. Vou definir cada um com cuidado, porque é justamente aqui que as explicações costumam se embaralhar.

Hub: a identidade do negócio

Um Hub armazena as chaves de negócio (business keys) de uma entidade, e nada mais além do mínimo necessário. Se a entidade é o cliente, o Hub de Cliente guarda o identificador que o negócio usa para reconhecer um cliente, o CPF, um código, um e-mail, seja qual for a chave real do domínio.

O Hub não guarda nome, endereço nem telefone. Ele guarda apenas quem existe. Sua função é ser o ponto único e estável de integração: não importa de quantos sistemas diferentes o cliente “12345” apareça, ele terá um único registro no Hub. A unicidade aqui é da chave de negócio, e é isso que evita duplicações espalhadas pelo warehouse.

Um Hub típico contém: a business key, uma chave substituta, o carimbo de quando foi carregado pela primeira vez (load date) e a identificação da fonte (record source).

Link: os relacionamentos

Um Link representa uma associação entre dois ou mais Hubs. Se um cliente faz um pedido, é o Link que registra essa conexão, guardando as chaves do Hub de Cliente e do Hub de Pedido lado a lado.

Um detalhe importante e não óbvio: no Data Vault, todo relacionamento vira um Link, e os Links são sempre modelados como muitos-para-muitos. Isso não é desperdício, é estratégia. Se amanhã a regra de negócio mudar e um pedido puder ter vários clientes, ou vice-versa, o modelo já está preparado, sem migração dolorosa. O Link absorve a mudança de cardinalidade de graça.

Satélite: os atributos e a história

Um Satélite guarda os atributos descritivos e, crucialmente, o histórico deles ao longo do tempo. É onde vivem o nome do cliente, seu endereço, seu telefone, e cada versão que esses dados já tiveram.

Um Satélite sempre se liga a um Hub (ou a um Link) por chave estrangeira. Quando um atributo muda, o Data Vault não sobrescreve: ele insere uma nova linha com o novo valor e um novo carimbo de tempo, preservando o valor antigo. O resultado é um histórico completo e auditável de como cada entidade evoluiu. Se o cliente mudou de endereço três vezes, os três endereços estão lá, datados.

É comum separar os atributos de uma mesma entidade em múltiplos Satélites, por exemplo, um para dados que mudam raramente e outro para dados voláteis, ou um Satélite por fonte de origem. Isso mantém a carga eficiente e isola o impacto das mudanças.

Juntando tudo

No nosso exemplo de clientes e pedidos, o modelo fica assim: um Hub de Cliente e um Hub de Pedido guardam as identidades; um Link conecta os dois, registrando quem pediu o quê; e Satélites pendurados em cada Hub guardam os detalhes e todo o histórico. Simples de enunciar, poderoso na prática.

O que o Data Vault 2.0 trouxe de novo

A versão original resolvia o problema de modelagem, mas tinha um gargalo prático na carga. O Data Vault 2.0 endereçou isso e ampliou o escopo para além da modelagem. Três mudanças merecem destaque.

Hash keys no lugar de sequências. Na primeira versão, as chaves substitutas eram sequenciais, o que criava dependências na ordem de carga: você precisava carregar o Hub antes do Link para saber qual número usar. O DV 2.0 substitui isso por chaves hash, calculadas diretamente a partir da business key (tipicamente com um algoritmo como MD5 ou SHA). Como o hash é determinístico, Hubs, Links e Satélites podem ser carregados em paralelo e de forma independente, sem esperar uns pelos outros. Num mundo de processamento distribuído, isso é uma virada de jogo.

Foco em agilidade e automação. O DV 2.0 não é só um padrão de tabelas; é um método que abraça práticas ágeis, ciclos curtos de entrega e forte automação. Como a estrutura é repetitiva e previsível (tudo é Hub, Link ou Satélite), a geração de código de carga se presta bem à automação, e o warehouse cresce em incrementos entregáveis em vez de grandes releases arriscados.

Padrões de carga bem definidos. A carga é sempre por inserção, nunca por atualização ou exclusão. Isso torna o processo idempotente, auditável e trivialmente paralelizável, além de preservar o histórico por construção.

Mãos à obra: um Data Vault em SQLite

Teoria é bonita, mas nada substitui ver a coisa rodar. Vamos construir um Data Vault 2.0 mínimo e funcional usando apenas SQLite e Python, sem instalar nada. O domínio é o nosso já conhecido cliente e pedido, e o objetivo é provar, na prática, três promessas da metodologia: o Hub não duplica, o Satélite historiza, e a informação de negócio se reconstrói por junções.

Começamos pela estrutura. Três tabelas, uma de cada tipo (mais um segundo Hub para o pedido):

-- HUB: guarda apenas a chave de negócio (business key)
CREATE TABLE hub_cliente (
    hk_cliente     TEXT PRIMARY KEY,   -- hash da business key
    cpf            TEXT NOT NULL,      -- business key
    load_date      TEXT NOT NULL,
    record_source  TEXT NOT NULL
);

-- LINK: relacionamento entre hubs (sempre modelado como M:N)
CREATE TABLE link_cliente_pedido (
    hk_link        TEXT PRIMARY KEY,   -- hash das duas business keys
    hk_cliente     TEXT NOT NULL,
    hk_pedido      TEXT NOT NULL,
    load_date      TEXT NOT NULL,
    record_source  TEXT NOT NULL,
    FOREIGN KEY (hk_cliente) REFERENCES hub_cliente (hk_cliente),
    FOREIGN KEY (hk_pedido)  REFERENCES hub_pedido  (hk_pedido)
);
-- SATÉLITE: atributos descritivos + histórico (carga sempre por inserção)
CREATE TABLE sat_cliente (
    hk_cliente     TEXT NOT NULL,
    load_date      TEXT NOT NULL,
    nome           TEXT,
    cidade         TEXT,
    hash_diff      TEXT NOT NULL,      -- hash dos atributos, detecta mudança
    record_source  TEXT NOT NULL,
    PRIMARY KEY (hk_cliente, load_date),
    FOREIGN KEY (hk_cliente) REFERENCES hub_cliente (hk_cliente)
);

Repare em dois campos que carregam a essência do DV 2.0. O hk_cliente é uma hash key, calculada a partir do CPF. O hash_diff, no satélite, é o hash de todos os atributos descritivos juntos: é ele que nos dirá, sem comparar campo a campo, se algo mudou.

As duas funções de hashing são o coração de tudo:

import hashlib

def hash_key(*parts):
    """Hash determinístico de uma ou mais business keys."""
    raw = "||".join(str(p).strip().upper() for p in parts)
    return hashlib.md5(raw.encode()).hexdigest()
def hash_diff(*attrs):
    """Hash dos atributos - muda quando qualquer atributo muda."""
    raw = "||".join("" if a is None else str(a).strip() for a in attrs)
    return hashlib.md5(raw.encode()).hexdigest()

Como o hash é determinístico, o mesmo CPF sempre gera a mesma hk_cliente, em qualquer tabela, sem consultar sequência nenhuma. É isso que permite carregar Hub, Link e Satélite em paralelo.

Agora a regra de ouro da carga, ilustrada pelo satélite. Ele só insere uma nova versão se os atributos mudaram:

def carregar_sat_cliente(cpf, nome, cidade, source, load_date):
    hk = hash_key(cpf)
    hd = hash_diff(nome, cidade)
    # pega o hash_diff da versão mais recente deste cliente
    cur.execute("""
        SELECT hash_diff FROM sat_cliente
        WHERE hk_cliente = ? ORDER BY load_date DESC LIMIT 1""", (hk,))
    row = cur.fetchone()
    # insere só se é novo (row is None) ou se algo mudou (hash_diff diferente)
    if row is None or row[0] != hd:
        cur.execute("INSERT INTO sat_cliente VALUES (?,?,?,?,?,?)",
                    (hk, load_date, nome, cidade, hd, source))

Nunca há UPDATE, nunca há DELETE. Só inserção. É essa disciplina que constrói o histórico de graça.

Vamos simular três dias de carga. No dia 1, a cliente Ana aparece em Recife e faz o pedido PED-001. No dia 2, ela faz um segundo pedido, sem mudar de cidade. No dia 3, ela se muda para Olinda:

# Dia 1 — Ana aparece em Recife e faz um pedido
carregar_hub_cliente("11111111111", SRC, "2024-01-10")
carregar_hub_pedido("PED-001", SRC, "2024-01-10")
carregar_link("11111111111", "PED-001", SRC, "2024-01-10")
carregar_sat_cliente("11111111111", "Ana Souza", "Recife", SRC, "2024-01-10")

# Dia 2 - novo pedido, mesma cidade. Hub e Sat NÃO duplicam.
carregar_hub_cliente("11111111111", SRC, "2024-02-15")   # já existe, ignora
carregar_hub_pedido("PED-002", SRC, "2024-02-15")
carregar_link("11111111111", "PED-002", SRC, "2024-02-15")
carregar_sat_cliente("11111111111", "Ana Souza", "Recife", SRC, "2024-02-15")  # sem mudança
# Dia 3 - Ana muda de cidade. O satélite historiza.
carregar_sat_cliente("11111111111", "Ana Souza", "Olinda", SRC, "2024-06-20")

E o que o banco nos mostra ao final? Exatamente o comportamento prometido:

=== HUB CLIENTE (1 registro, apesar de 2 cargas) ===
('11111111111', '2024-01-10')

=== SAT CLIENTE (2 versões: Recife -> Olinda) ===
('2024-01-10', 'Ana Souza', 'Recife')
('2024-06-20', 'Ana Souza', 'Olinda')

O Hub tem uma única linha, mesmo tendo recebido a Ana em duas cargas distintas: a hash key barrou a duplicação. O satélite tem duas versões: a carga do dia 2 não gerou linha nova (o hash_diff era idêntico), mas a mudança de cidade no dia 3 gerou. O endereço antigo continua lá, datado. Isso é a historização acontecendo por construção.

Falta a parte que interessa ao negócio: reconstruir a informação. Para saber o estado atual da cliente, pegamos a versão mais recente do satélite:

SELECT h.cpf, s.nome, s.cidade
FROM hub_cliente h
JOIN sat_cliente s ON s.hk_cliente = h.hk_cliente
WHERE s.load_date = (
    SELECT MAX(s2.load_date) FROM sat_cliente s2
    WHERE s2.hk_cliente = h.hk_cliente);
-- Resultado: ('11111111111', 'Ana Souza', 'Olinda')

E para responder “quais pedidos a Ana fez?”, atravessamos Hub → Link → Hub:

SELECT hc.cpf, hp.num_pedido
FROM hub_cliente hc
JOIN link_cliente_pedido l ON l.hk_cliente = hc.hk_cliente
JOIN hub_pedido hp ON hp.hk_pedido = l.hk_pedido;
-- Resultado: PED-001 e PED-002

Aqui, ao vivo, você sente a promessa e o preço do Data Vault na mesma consulta. A promessa: nenhum dado se perdeu, todo o histórico está rastreável, e novas fontes entrariam por simples adição de tabelas. O preço: até uma pergunta trivial exige junções entre três tabelas. Multiplique isso por dezenas de entidades e você entende por que as consultas analíticas são empurradas para uma camada de consumo, que é justamente o próximo assunto.

O script completo, com todas as rotinas de carga e pronto para rodar com um único python3, acompanha este artigo. É totalmente autocontido: usa apenas a biblioteca padrão do Python, sem instalar nada.

Onde o Data Vault se encaixa (e onde não)

Aqui está a nuance mais importante do artigo, e a que costuma faltar nas explicações: o Data Vault não é a camada com que o usuário final conversa.

Pense numa arquitetura em três camadas. Na base, uma área de aterrissagem recebe os dados brutos das fontes (a raw, ou staging). No meio, o Data Vault faz a integração: reúne todas as fontes, preserva o histórico completo e mantém a rastreabilidade. No topo, camadas de consumo, tipicamente marts dimensionais (o velho e bom esquema estrela), servem os dados já modelados para análise e BI.

Ou seja, Data Vault e modelagem dimensional não competem; eles cooperam. O Data Vault é excelente para integrar e historiar, mas suas consultas, cheias de junções entre Hubs, Links e Satélites, são complexas demais para o analista final. Por isso, agregações e sumarizações são deliberadamente adiadas para as camadas posteriores, onde um star schema entrega performance e simplicidade de consulta. O Data Vault guarda a verdade histórica; o data mart apresenta essa verdade de forma consumível.

Essa divisão de trabalho é o que dá a ele suas propriedades quase autodocumentáveis: como a estrutura do Data Vault espelha as chaves e relacionamentos reais do negócio, o modelo conta a própria história de onde os dados vêm e como se conectam.

Quando vale a pena, e quando não vale

Sendo honesto, o Data Vault não é para todo mundo, e adotá-lo por moda é um erro caro.

Ele brilha em ambientes complexos: muitas fontes de dados heterogêneas, requisitos de auditoria e governança rigorosos, fontes que mudam com frequência, e a necessidade de um histórico completo e rastreável. Setores regulados, como saúde, finanças e governo, são o habitat natural dele.

Por outro lado, ele cobra um preço. O número de tabelas explode (cada entidade vira vários objetos), a carga exige orquestração cuidadosa, e as consultas sobre o modelo cru são notoriamente trabalhosas. Para um data warehouse pequeno, com poucas fontes estáveis e sem exigência forte de histórico, o Data Vault é canhão para matar mosquito. Nesses casos, um bom modelo dimensional direto resolve com muito menos cerimônia.

A pergunta certa não é “Data Vault é bom?”, e sim “a complexidade e a volatilidade das minhas fontes justificam a camada de integração que ele oferece?”.

Fechando o cofre

O Data Vault é uma resposta madura a um problema real: como construir um data warehouse que não desmorone a cada mudança de negócio. Ao separar identidade (Hubs), relacionamentos (Links) e atributos históricos (Satélites), ele ganha uma flexibilidade que as modelagens tradicionais não alcançam, e a versão 2.0, com suas hash keys e sua vocação ágil, o tornou pronto para a escala e o paralelismo dos ambientes de dados modernos.

Mas o ponto que vale levar deste texto é o do encaixe: o Data Vault é a camada de integração e história, não a de consumo. Ele convive com a modelagem dimensional, cada um fazendo o que faz de melhor. Entender essa divisão é o que separa quem usa o Data Vault com propósito de quem apenas empilha tabelas em nome de uma sigla da moda.

Se a sua organização enfrenta muitas fontes, muita mudança e exigências sérias de governança, o Data Vault merece um lugar na mesa de decisão. Se não, vale saber que ele existe, e por que às vezes o mais simples é o mais sábio.

Até a próxima.