No post Data Vault – Como Usar  falei um pouco sobre a motivação, conceitos e arquitetura envolvida em um projeto de DW baseado em Data Vault. Um dos meus leitores colocou algumas perguntas muito interessantes, tão interessantes que eu decidi respondê-las em um post exclusivo. Além de ser um meio mais cômodo que um formulário de comentários, é uma forma de agradecer pela participação e mostrar o quanto eu apreciei. ;-) (Sim, eu sou fã dos meus leitores.)

Perguntas, Perguntas, Perguntas

Eis as perguntas colocadas no comentário:

1) Nos satélites, você cita um campo “Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);”. Neste ponto eu fiquei em dúvida. O ETL para estes satélites poderão realizar operação de update ou não? Ou este campo seria apenas para os casos de atributos que já tiveram uma “vigência fechada” nos OLTP (estou fazendo analogia ao SCD tipo II)?

2) Eu e um colega discutimos se o DV seriam bancos de dados para cada sistema transacional ou todo o DV corporativo estaria em um único banco de dados. Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto? No meu caso, estou falando de SAS e, consequentemente, datasets são tabelas e diretórios são bancos de dados. Então, na falta de um banco relacional como DV, eu inicialmente colocaria todo o DV num “diretório dvault”.

3) Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Vou responder uma por seção. Vamos lá.

LEDTS vs. SCD2

O ETL para estes satélites poderão realizar operação de update ou não?

Não apenas podem, como devem. Satélites guardam histórico e possuem exatamente o mesmo comportamento de uma dimensão de variação lenta do tipo 2. Ele acertou na mosca!

Hubs e links são tabelas que guardam os conceitos de negócio da organização, e as relações entre esses conceitos. Se algum dia um determinado hub ou relacionamento entre hubs existiu, o Data Vault captura e arquiva essa informação. Satélites, por outro lado, dão o contexto desses elementos.

O Cofre: Coleção ou Caverna?

A segunda pergunta é mais complexa:

Você sugere o DV deveria estar em bancos diferentes? Ou tudo junto?

Bom, por um simples questão de integração, deveria estar tudo junto.

Buraco Negro

Até que ponto pode crescer um satélite?

Um BD relacional daria conta de manter um satélite gigantesco (algo como muitos atributos/colunas muitas transações/registros por dia)?

Bom, o propósito central de um DV é acumular “todo os dados, para todo o sempre”. Logo, precisamos que a estrutura na qual os dados estão armazenados dê conta disso. Se um relacional não consegue, então precisamos recorrer a algo mais elástico. Inmon chamava essa camada de Near Line Storage, que é um armazenamento de alto volume, mas em uma mídia mais econômica. Em troca pelo preço menor por byte e durabilidade maior, a velocidade de acesso seria menor. No caso original, NLS seriam fitas magnéticas.

Conclusão

A conclusão, desta vez, é minha: do comentário e das perguntas eu posso ver que estou deixando algumas lacunas no assunto de Data Vault. Vou levar essa visão em consideração nos próximos posts sobre o assunto.

Até lá! ;-)

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