Essa é uma questão que ainda me tira o sono: se a sua empresa tem poucos departamentos e eles têm processos estáveis, se seu modelo dimensional tem poucas estrelas e está bem feito, se o seu ETL não dá pau, então porque adotar Data Vault?

Bom, para começo de conversa, se você está na condição acima, parabéns! Empresa com poucos departamentos nem é tão raro, mas processos estáveis, claros e bem conhecidos, sistemas de origem e dados bem comportados, ETL maduro… Nossa, isso é o sonho de qualquer gerente de BI!

Logo, porque alguma empresa iria querer Data Vault?

  1. Porque os processos – que são a base da Modelagem Dimensional – nem sempre são claros.
  2. Esses mesmos processos podem ser maduros, mas raramente são estáveis. Na melhor das hipóteses mudam para se adaptar a mudanças de legislação. Na pior, mudam para garantir a sobrevivência da empresa.
  3. Nem sempre os processos são claramente entendidos. Quando o entendimento muda, o Modelo Dimensional precisa mudar.
  4. Sistemas de origem e dados bem comportados são coisa rara. O mais comum é o contrário: dados errados pululando por sistemas selvagens.
  5. Finalmente, ETL é um processo que demanda muita inteligência. Com tratamento de erros, demanda ainda mais. Quando algo muda na origem, o ETL precisa mudar, o que normalmente introduz novos bugs e novas necessidades de tratamentos de erros.

Isso já seria o suficiente para justificar a adoção de um Data Vault, mas não é esse o motivo que me levou a escrever esse post – acredite se quiser!

Semana passada estive com dois grandes amigos, que trabalham em um departamento da TI com projetos de BI. Eles me contaram que, em termos de modelagem de dados, eles têm uma visão muito mais pragmática que a da Modelagem Dimensional. Na visão corrente em um dos projetos, eles dizem que:

O Negócio X é o relacionamento de D1, D2, … e Dn.

E esse é o motivo que me levou a escrever hoje: mesmo havendo um processo de negócio que amarra os dados de uma forma que faz sentido para o negócio, no fundo tratam-se de dados que se inter-relacionam. Ou seja, um negócio ou assunto é registrado/caracterizado pelo relacionamento entre seus dados.

Não significa que eles descartam a Modelagem Dimensional. Pelo contrário, eles têm um Modelo Dimensional para o cliente explorar os dados, mas primeiro esses dados aterrisam numa camada intermediária, cujo desenho é muito parecido com um Data Vault.

E isso bate 100% com um dos paradigmas do Data Vault: como os dados serão consultados pelo cliente é uma questão para depois, normalmente melhor resolvida com um Modelo Dimensional. Primeiro é preciso guardá-los, e a seus relacionamentos. Esse é justamente o propósito do Data Vault: arquivar dados não-criticados, para preservá-los.

Assunto resolvido: um Data Vault é necessário porque os dados de uma organização se relacionam entre si, de maneiras que podem mudar ao longo do tempo. Para preservar os dados E a capacidade de analisá-los, precisamos de um Data Vault.

É isso!

7 comentários sobre “Porque Data Vault

  1. Na sua opinião, continua sendo “necessário” mesmo quando a origem é um (ou dois) sistemas transacionais (ERP) onde esses relacionamento já estão todos (bem) definidos? Nesse caso não seria apenas “duplicar dados”. Quando penso em Data Vault e na realidade da maioria dos projetos que estive envolvido, onde a(s) origem(s) era(m) sempre um ERP, continuo não encontrando motivação suficiente para criar mais uma “camada de dados”.

    1. Gleison, tenho o mesmo sentimento que você: se a fonte é uma só, estável, bem-comportada e conhecida, para quê a camada extra? Não consigo achar justificativa para um DV nessa situação. Apesar de, intuitivamente, eu perceber o valor de um DV em qualquer caso, eu ainda não encontrei um argumento tão matador para justificá-lo quanto os que existem para Modelo Dimensional. Mesmo sem uma boa justificativa, se fosse minha tarefa decidir pela adoção ou não de um DV no cenário que você mostrou, eu adotaria. Não consigo encontrar argumentos fortes para convencer outrem, mas eu estou convencido.

  2. Comecei a estudar DV hoje e estou com um dúvida fundamental em relação da posição do DV dentro da arquitetura de um sistema de Business Intelligence:

    OLTP —> Data Vault —> Dimensional Model —> OLAP

    Isso está correto? Eu terei um ETL do OLTP para o DV e outro ETL para os Data Marts? Ou o meu Data Warehouse será modelado utilizando a técnica DV e dali mesmo o servidor OLAP consultará os dados?

    1. Petrônio, você entendeu corretamente: adicionar um DV à arquitetura traz um novo ETL, desta vez do DV para um data mart dimensional. O DV não se presta a consultas. Confesso que eu briguei muito com isso – como poderia uma arquitetura dessas ser melhor que uma só carga diretamente ao DW dimensional?? Se você pensar um pouco, entende: um DV guarda _tudo_, ao passo que um modelo dimensional guarda só o que o cliente quer, e tratado – o dado original se perde. Ter um DV te permite recriar seu modelo dimensional completamente, incluindo o histórico! O preço dessa vantagem é justamente o ETL extra. Mas essa não é a única vantagem: devido à estrutua do DV ser muito simples e repetitiva, o desenho do ETL do DV para o Dimensional é mais ou menos repetitiva. Associado isso ao fato do ETL OLTP -> DV ser muito simples, no final das contas você acaba com uma característica interessante: o processo de ETL OLTP -> DV -> Dimensional é muito mais regular e repetitivo do que um processo de ETL OLTP -> Dimensional (com ou sem stage.) Para qualquer gestor de projeto, repetitividade vale ouro. Conclusão, as vantagens do DV compensam a necessidade de um ETL extra.

      1. Foi sim. Eu gosto de aprender desenhando diagramas e eu fiz esse para encaixar no meu esquema de BI….

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s