Get best of the week

O desenvolvimento do DATA VAULT e a transição para o BUSINESS DATA VAULT

Em um artigo anterior, falei sobre os conceitos básicos do DATA VAULT, descrevi os elementos básicos do DATA VAULT e seu objetivo. Isso não pode ser considerado esgotado o tópico do DATA VAULT, é necessário falar sobre os próximos estágios da evolução do DATA VAULT.

E neste artigo, vou me concentrar no desenvolvimento do DATA VAULT e na transição para o BUSINESS DATA VAULT ou simplesmente para o BUSINESS VAULT.

Razões para o aparecimento do BUSINESS DATA VAULT


Deve-se notar que o DATA VAULT com certos pontos fortes não apresenta desvantagens. Uma dessas desvantagens é a dificuldade em escrever consultas analíticas. As solicitações têm um número significativo de JOINs, o código é longo e complicado. Além disso, os dados do DATA VAULT não estão sujeitos a nenhuma conversão; portanto, do ponto de vista comercial, o DATA VAULT em sua forma pura não possui valor incondicional.

Para eliminar essas deficiências, a metodologia DATA VAULT foi expandida por elementos como:

  • Tabelas PIT (point in time);
  • Tabelas BRIDGE;
  • DERIVAÇÕES PREDEFINIDAS.

Vamos dar uma olhada no objetivo desses elementos.

Mesas de pit


Como regra, um objeto de negócios (HUB) pode incluir dados com taxas de atualização diferentes, por exemplo, se estivermos falando de dados que caracterizam uma pessoa, podemos dizer que as informações sobre um número de telefone, endereço ou email têm uma taxa de atualização mais alta do que digamos, nome, detalhes do passaporte, estado civil ou sexo.

Portanto, ao determinar os satélites, deve-se ter em mente a frequência de suas atualizações. Por que isso é importante?

Se você armazenar atributos com diferentes taxas de atualização em uma tabela, precisará adicionar uma linha à tabela sempre que atualizar o atributo alterado com mais frequência. Como conseqüência, um aumento no espaço em disco, um aumento no tempo de execução da consulta.

Agora que dividimos os satélites de acordo com a frequência de atualização e podemos fazer upload de dados para eles de forma independente, deve ser possível obter dados relevantes. Melhor sem usar JOINs desnecessários.

Explicarei, por exemplo, que é necessário obter informações atualizadas (até a data da última atualização) dos satélites com diferentes frequências de atualização. Para fazer isso, você precisa não apenas criar um JOIN, mas também criar várias subconsultas (para cada satélite que contenha informações) com uma escolha da data máxima de atualização MAX (Data de atualização). A cada novo JOIN, esse código aumenta e rapidamente se torna difícil de entender.

A tabela PIT foi projetada para simplificar essas consultas; as tabelas PIT são preenchidas ao mesmo tempo em que novos dados são gravados no DATA VAULT. Tabela PIT:

imagem

Assim, temos informações sobre a relevância dos dados em todos os satélites a cada momento no tempo. Usando JOINs para a tabela PIT, podemos excluir completamente consultas aninhadas, naturalmente com a condição de que a PIT seja preenchida todos os dias e sem intervalos. Mesmo se houver lacunas no PIT, os dados reais podem ser obtidos apenas usando uma sub-solicitação ao próprio PIT. Uma subconsulta funcionará mais rápido que as subconsultas para cada satélite.

PONTE


As tabelas BRIDGE também são usadas para simplificar consultas analíticas. No entanto, a diferença do PIT é um meio de simplificar e acelerar solicitações entre diferentes hubs, links e seus satélites.

A tabela contém todas as chaves necessárias para todos os satélites que são freqüentemente usados ​​em consultas. Além disso, se necessário, as chaves comerciais com hash podem ser complementadas com chaves em formato de texto, se os nomes das chaves forem necessários para análise.

O fato é que, sem usar o BRIDGE, no processo de obtenção de dados localizados em satélites pertencentes a diferentes hubs, será necessário produzir JOINs não apenas dos próprios satélites, mas também vincular hubs de conexão.

A presença ou ausência do BRIDGE é determinada pela configuração de armazenamento, pela necessidade de otimizar a velocidade de execução da consulta. É difícil criar um exemplo universal de BRIGE.

DERIVAÇÕES PREDEFINIDAS


Outro tipo de objeto que nos aproxima do BUSINESS DATA VAULT são as tabelas que contêm indicadores pré-calculados. Essas tabelas são realmente importantes para os negócios, pois contêm informações agregadas de acordo com as regras especificadas e facilitam o acesso.

Arquitetonicamente, DERIVAÇÕES PREDEFINIDAS nada mais são do que apenas outro satélite de um determinado hub. Como um satélite comum, contém uma chave comercial e a data em que o registro foi formado no satélite. Nisso, porém, as semelhanças terminam. A composição adicional dos atributos de um satélite "especializado" é determinada pelos usuários de negócios com base nos indicadores pré-calculados mais populares.

Por exemplo, um hub que contém informações sobre um funcionário pode incluir um satélite com indicadores como:

  • Salário mínimo;
  • Salário máximo;
  • Salário médio;
  • Total acumulado de salários acumulados, etc.

É lógico incluir DERIVAÇÕES PREDEFINIDAS na tabela PIT do mesmo hub; é possível obter facilmente fatias de dados de funcionários em uma data específica.

RESULTADOS


Como mostra a prática, o uso do DATA VAULT por usuários corporativos é um pouco difícil por vários motivos:

  • O código de solicitação é complexo e complicado;
  • A abundância de JOINs afeta o desempenho da consulta;
  • Escrever consultas analíticas requer um conhecimento excelente da estrutura do repositório.

Para simplificar o acesso a dados, o DATA VAULT se estende com objetos adicionais:

  • Tabelas PIT (point in time);
  • Tabelas BRIDGE;
  • DERIVAÇÕES PREDEFINIDAS.

No próximo artigo, pretendo contar, na minha opinião, a coisa mais interessante para quem trabalha com BI. Apresentarei maneiras de criar tabelas - fatos e tabelas - medições baseadas no DATA VAULT.

Os materiais do artigo são baseados:

  • Na publicação de Kent Graziano, que além de uma descrição detalhada contém diagramas do modelo;
  • Livro: “Criando um data warehouse escalável com o DATA VAULT 2.0”;
  • Artigo Fundamentos do Data Vault .

More articles:


All Articles