Modelagem de cofre de dados - Data vault modeling

A modelagem de cofre de dados é um método de modelagem de banco de dados projetado para fornecer armazenamento histórico de longo prazo de dados provenientes de vários sistemas operacionais. É também um método de olhar para dados históricos que lida com questões como auditoria, rastreamento de dados, velocidade de carregamento e resiliência a mudanças, além de enfatizar a necessidade de rastrear a origem de todos os dados no banco de dados. Isso significa que cada linha em um cofre de dados deve ser acompanhada por atributos de fonte de registro e data de carregamento, permitindo que um auditor rastreie os valores de volta à fonte. Foi desenvolvido por Daniel (Dan) Linstedt em 2000.

A modelagem de cofre de dados não faz distinção entre dados bons e ruins ("ruim" significa não conformidade com as regras de negócios). Isso é resumido na declaração de que um cofre de dados armazena "uma única versão dos fatos" (também expressa por Dan Linstedt como "todos os dados, o tempo todo") em oposição à prática em outros métodos de armazenamento de dados " uma única versão da verdade "onde os dados que não estão em conformidade com as definições são removidos ou" limpos ".

O método de modelagem é projetado para ser resiliente a mudanças no ambiente de negócios de onde vêm os dados armazenados, separando explicitamente as informações estruturais dos atributos descritivos. O cofre de dados foi projetado para permitir o carregamento paralelo tanto quanto possível, para que implementações muito grandes possam ser dimensionadas sem a necessidade de um grande redesenho.

História e filosofia

Na modelagem de data warehouse, existem duas opções concorrentes bem conhecidas para modelar a camada onde os dados são armazenados. Ou você modela de acordo com Ralph Kimball , com dimensões conformadas e um barramento de dados corporativo, ou você modela de acordo com Bill Inmon com o banco de dados normalizado . Ambas as técnicas apresentam problemas ao lidar com mudanças nos sistemas que alimentam o data warehouse. Para dimensões conformadas, você também deve limpar os dados (para conformá-los) e isso é indesejável em vários casos, pois isso inevitavelmente perderá informações. O cofre de dados é projetado para evitar ou minimizar o impacto desses problemas, movendo-os para áreas do data warehouse que estão fora da área de armazenamento histórico (a limpeza é feita nos data marts) e separando os itens estruturais (chaves de negócios e o associações entre as chaves de negócios) a partir dos atributos descritivos.

Dan Linstedt, o criador do método, descreve o banco de dados resultante da seguinte maneira:

"O Data Vault Model é um rastreamento orientado a detalhes, histórico e um conjunto unicamente vinculado de tabelas normalizadas que suportam uma ou mais áreas funcionais de negócios. É uma abordagem híbrida que engloba o melhor da raça entre a 3ª forma normal (3NF) e o esquema em estrela . O design é flexível, escalonável, consistente e adaptável às necessidades da empresa "

A filosofia do cofre de dados é que todos os dados são dados relevantes, mesmo que não estejam de acordo com as definições e regras de negócios estabelecidas. Se os dados não estiverem em conformidade com essas definições e regras, isso é um problema para a empresa, não para o data warehouse. A determinação de que os dados estão "errados" é uma interpretação dos dados que se origina de um ponto de vista específico que pode não ser válido para todos ou em todos os momentos. Portanto, o cofre de dados deve capturar todos os dados e apenas ao relatar ou extrair dados do cofre de dados os dados estão sendo interpretados.

Outro problema para o qual o cofre de dados é uma resposta é que cada vez mais há uma necessidade de total auditabilidade e rastreabilidade de todos os dados no data warehouse. Devido aos requisitos da Sarbanes-Oxley nos EUA e medidas semelhantes na Europa, este é um tópico relevante para muitas implementações de inteligência de negócios, portanto, o foco de qualquer implementação de cofre de dados é a rastreabilidade completa e auditabilidade de todas as informações.

Data Vault 2.0 é a nova especificação. É um padrão aberto . A nova especificação consiste em três pilares: metodologia (SEI / CMMI, Six Sigma, SDLC, etc.), a arquitetura e o modelo. Dentro da metodologia, é definida a implementação das melhores práticas. O Data Vault 2.0 se concentra na inclusão de novos componentes, como Big Data, NoSQL - e também se concentra no desempenho do modelo existente. A especificação antiga (documentada aqui em sua maior parte) é altamente focada na modelagem de vault de dados. Ele está documentado no livro: Building a Scalable Data Warehouse com Data Vault 2.0.

É necessário evoluir a especificação para incluir os novos componentes, juntamente com as melhores práticas para manter os sistemas EDW e BI atualizados com as necessidades e desejos dos negócios atuais.

História

A modelagem de cofre de dados foi originalmente concebida por Dan Linstedt na década de 1990 e foi lançada em 2000 como um método de modelagem de domínio público. Em uma série de cinco artigos no The Data Administration Newsletter, as regras básicas do método Data Vault são expandidas e explicadas. Eles contêm uma visão geral, uma visão geral dos componentes, uma discussão sobre datas de término e junções, tabelas de links e um artigo sobre práticas de carregamento.

Um nome alternativo (e raramente usado) para o método é "Common Foundational Integration Modeling Architecture".

O Data Vault 2.0 entrou em cena em 2013 e traz para a mesa Big Data, NoSQL, integração contínua não estruturada e semiestruturada, juntamente com as melhores práticas de metodologia, arquitetura e implementação.

Interpretações alternativas

De acordo com Dan Linstedt, o Modelo de Dados é inspirado (ou padronizado) por uma visão simplista de neurônios, dendritos e sinapses - onde os neurônios estão associados a Hubs e Satélites Hub, Links são dendritos (vetores de informação) e outros Links são sinapses (vetores na direção oposta). Usando um conjunto de algoritmos de mineração de dados, os links podem ser pontuados com classificações de confiança e força. Eles podem ser criados e descartados instantaneamente de acordo com o aprendizado sobre relacionamentos que atualmente não existem. O modelo pode ser transformado, adaptado e ajustado automaticamente conforme é usado e alimentado com novas estruturas.

Outra visão é que um modelo de cofre de dados fornece uma ontologia da Empresa no sentido de que descreve os termos do domínio da empresa (Hubs) e as relações entre eles (Links), adicionando atributos descritivos (Satélites) quando necessário.

Outra maneira de pensar em um modelo de cofre de dados é como um modelo gráfico. O modelo de cofre de dados realmente fornece um modelo "baseado em gráfico" com hubs e relacionamentos em um mundo de banco de dados relacional. Dessa maneira, o desenvolvedor pode usar SQL para obter relacionamentos baseados em gráficos com respostas abaixo de um segundo.

Noções básicas

Modelo de cofre de dados simples com dois hubs (azul), um link (verde) e quatro satélites (amarelo)

O cofre de dados tenta resolver o problema de lidar com mudanças no ambiente separando as chaves de negócios (que não mudam com tanta frequência, porque identificam exclusivamente uma entidade de negócios) e as associações entre essas chaves de negócios, dos atributos descritivos dessas chaves .

As chaves de negócios e suas associações são atributos estruturais, formando o esqueleto do modelo de dados. O método de cofre de dados tem como um de seus principais axiomas que as chaves de negócios reais só mudam quando o negócio muda e são, portanto, os elementos mais estáveis ​​a partir dos quais derivar a estrutura de um banco de dados histórico. Se você usar essas chaves como a espinha dorsal de um data warehouse, poderá organizar o restante dos dados em torno delas. Isso significa que a escolha das chaves corretas para os hubs é de fundamental importância para a estabilidade do seu modelo. As chaves são armazenadas em tabelas com algumas restrições na estrutura. Essas tabelas-chave são chamadas de hubs.

Hubs

Os hubs contêm uma lista de chaves comerciais exclusivas com baixa propensão a mudanças. Os hubs também contêm uma chave substituta para cada item do hub e metadados que descrevem a origem da chave comercial. Os atributos descritivos para as informações no hub (como a descrição da chave, possivelmente em vários idiomas) são armazenados em estruturas chamadas de tabelas Satellite, que serão discutidas a seguir.

O hub contém pelo menos os seguintes campos:

• uma chave substituta, usada para conectar as outras estruturas a esta tabela.
• uma chave de negócios, o driver para este hub. A chave comercial pode consistir em vários campos.
• a fonte de registro, que pode ser usada para ver qual sistema carregou cada chave comercial primeiro.
• opcionalmente, você também pode ter campos de metadados com informações sobre atualizações manuais (usuário / hora) e a data de extração.

Um hub não pode conter várias chaves de negócios, exceto quando dois sistemas fornecem a mesma chave de negócios, mas com colisões que têm significados diferentes.

Os hubs normalmente devem ter pelo menos um satélite.

Exemplo de hub

Este é um exemplo de uma mesa central contendo carros, chamada "Carro" (H_CAR). A chave de direção é o número de identificação do veículo .

Links

Associações ou transações entre chaves de negócios (relacionadas, por exemplo, aos hubs para cliente e produto entre si por meio da transação de compra) são modeladas usando tabelas de links. Essas tabelas são basicamente tabelas de junção de muitos para muitos, com alguns metadados.

Os links podem ser vinculados a outros links, para lidar com mudanças na granularidade (por exemplo, adicionar uma nova chave a uma tabela de banco de dados mudaria o grão da tabela de banco de dados). Por exemplo, se você tiver uma associação entre cliente e endereço, poderá adicionar uma referência a um link entre os hubs para produto e empresa de transporte. Pode ser um link denominado "Entrega". Fazer referência a um link em outro link é considerado uma prática ruim, porque introduz dependências entre os links que tornam o carregamento paralelo mais difícil. Como um link para outro link é o mesmo que um novo link com os hubs do outro link, nesses casos, criar os links sem fazer referência a outros links é a solução preferida (consulte a seção sobre práticas de carregamento para obter mais informações).

Às vezes, os links vinculam os hubs a informações que, por si só, não são suficientes para construir um hub. Isso ocorre quando uma das chaves comerciais associadas ao link não é uma chave comercial real. Como exemplo, pegue um formulário de pedido com "número de pedido" como chave e linhas de pedido que são digitadas com um número semi-aleatório para torná-los únicos. Digamos, "número único". A última chave não é uma chave de negócios real, portanto, não é um hub. No entanto, precisamos usá-lo para garantir a granularidade correta para o link. Nesse caso, não usamos um hub com chave substituta, mas adicionamos a própria chave comercial "número exclusivo" ao link. Isso só é feito quando não há possibilidade de usar a chave de negócio para outro link ou como chave de atributos em um satélite. Esta construção foi chamada de 'link com pernas de pau' por Dan Linstedt em seu (agora extinto) fórum.

Os links contêm as chaves substitutas para os hubs vinculados, sua própria chave substituta para o link e metadados que descrevem a origem da associação. Os atributos descritivos das informações sobre a associação (como horário, preço ou valor) são armazenados em estruturas denominadas tabelas satélites, discutidas a seguir.

Exemplo de link

Este é um exemplo de uma tabela de ligação entre dois hubs para carros (H_CAR) e pessoas (H_PERSON). O link é denominado "Driver" (L_DRIVER).

Satélites

Os hubs e links formam a estrutura do modelo, mas não têm atributos temporais e não contêm atributos descritivos. Eles são armazenados em tabelas separadas chamadas satélites . Eles consistem em metadados vinculando-os ao hub ou link pai, metadados que descrevem a origem da associação e dos atributos, bem como uma linha do tempo com datas de início e término para o atributo. Onde os hubs e links fornecem a estrutura do modelo, os satélites fornecem a "carne" do modelo, o contexto para os processos de negócios que são capturados nos hubs e links. Esses atributos são armazenados tanto no que diz respeito aos detalhes do assunto quanto à linha do tempo e podem variar de bastante complexos (todos os campos descrevendo o perfil completo de um cliente) até bastante simples (um satélite em um link com apenas um indicador válido e uma linha do tempo).

Normalmente, os atributos são agrupados em satélites por sistema de origem. No entanto, atributos descritivos como tamanho, custo, velocidade, quantidade ou cor podem mudar em taxas diferentes, então você também pode dividir esses atributos em satélites diferentes com base em sua taxa de mudança.

Todas as tabelas contêm metadados, descrevendo minimamente pelo menos o sistema de origem e a data em que essa entrada se tornou válida, dando uma visão histórica completa dos dados conforme eles entram no data warehouse.

Exemplo de satélite

Este é um exemplo de satélite no link dos motoristas entre os hubs para carros e pessoas, denominado "Seguro do motorista" (S_DRIVER_INSURANCE). Este satélite contém atributos que são específicos para o seguro da relação entre o carro e a pessoa que o dirige, por exemplo, um indicador se este é o motorista principal, o nome da seguradora para este carro e a pessoa (também pode ser um hub) e um resumo do número de acidentes envolvendo esta combinação de veículo e motorista. Também está incluída uma referência a uma tabela de consulta ou referência chamada R_RISK_CATEGORY que contém os códigos para a categoria de risco na qual esta relação se enquadra.

(*) pelo menos um atributo é obrigatório. (**) o número de sequência torna-se obrigatório se for necessário para impor exclusividade para vários satélites válidos no mesmo hub ou link.

Tabelas de referência

As tabelas de referência são uma parte normal de um modelo de cofre de dados saudável. Eles existem para evitar o armazenamento redundante de dados de referência simples que são muito referenciados. Mais formalmente, Dan Linstedt define os dados de referência da seguinte forma:

Qualquer informação considerada necessária para resolver as descrições dos códigos ou para traduzir as chaves para (sic) de maneira consistente. Muitos desses campos são de natureza "descritiva" e descrevem um estado específico das outras informações mais importantes. Assim, os dados de referência residem em tabelas separadas das tabelas brutas do Data Vault .

As tabelas de referência são referenciadas a partir de satélites, mas nunca vinculadas a chaves externas físicas. Não existe uma estrutura prescrita para tabelas de referência: use o que funciona melhor em seu caso específico, variando de tabelas de pesquisa simples a pequenos cofres de dados ou até estrelas. Eles podem ser históricos ou não ter histórico, mas é recomendável que você se atenha às chaves naturais e não crie chaves substitutas nesse caso. Normalmente, os cofres de dados têm muitas tabelas de referência, assim como qualquer outro Data Warehouse.

Exemplo de referência

Este é um exemplo de uma tabela de referência com categorias de risco para motoristas de veículos. Ele pode ser referenciado a partir de qualquer satélite no cofre de dados. Por enquanto, fazemos referência a ele no satélite S_DRIVER_INSURANCE. A tabela de referência é R_RISK_CATEGORY.

(*) pelo menos um atributo é obrigatório.

Práticas de carregamento

O ETL para atualizar um modelo de cofre de dados é bastante simples (consulte Data Vault Série 5 - Práticas de carregamento ). Primeiro, você deve carregar todos os hubs, criando IDs substitutos para quaisquer novas chaves de negócios. Feito isso, agora você pode resolver todas as chaves de negócios para IDs substitutos se consultar o hub. A segunda etapa é resolver os links entre os hubs e criar IDs substitutos para quaisquer novas associações. Ao mesmo tempo, você também pode criar todos os satélites que estão conectados aos hubs, já que pode resolver a chave para um ID substituto. Depois de criar todos os novos links com suas chaves substitutas, você pode adicionar os satélites a todos os links.

Como os hubs não são unidos entre si, exceto por meio de links, você pode carregar todos os hubs em paralelo. Uma vez que os links não são anexados diretamente uns aos outros, você também pode carregar todos os links em paralelo. Como os satélites podem ser conectados apenas a hubs e links, você também pode carregá-los em paralelo.

O ETL é bastante simples e permite fácil automação ou modelagem. Os problemas ocorrem apenas com links relacionados a outros links, porque resolver as chaves de negócios no link apenas leva a outro link que também deve ser resolvido. Devido à equivalência desta situação com uma ligação a múltiplos hubs, esta dificuldade pode ser evitada remodelando tais casos e esta é de facto a prática recomendada.

Os dados nunca são excluídos do cofre de dados, a menos que você tenha um erro técnico ao carregar os dados.

Cofre de dados e modelagem dimensional

A camada modelada do cofre de dados é normalmente usada para armazenar dados. Não é otimizado para desempenho de consulta, nem é fácil de consultar por meio de ferramentas de consulta conhecidas, como Cognos , OBIEE, SAP Business Objects , Pentaho et al. Como essas ferramentas de computação do usuário final esperam ou preferem que seus dados estejam contidos em um modelo dimensional, geralmente é necessária uma conversão.

Para este propósito, os hubs e satélites relacionados nesses hubs podem ser considerados como dimensões e os links e satélites relacionados nesses links podem ser vistos como tabelas de fatos em um modelo dimensional. Isso permite que você crie rapidamente um protótipo de um modelo dimensional de um modelo de cofre de dados usando vistas.

Observe que, embora seja relativamente simples mover dados de um modelo de cofre de dados para um modelo dimensional (limpo), o inverso não é tão fácil, dada a natureza desnormalizada das tabelas de fatos do modelo dimensional, fundamentalmente diferente da terceira forma normal do cofre de dados.

Metodologia de cofre de dados

A metodologia de armazenamento de dados é baseada nas melhores práticas SEI / CMMI Nível 5. Inclui vários componentes do CMMI Nível 5 e os combina com as melhores práticas de Six Sigma , TQM e SDLC. Particularmente, é focado na metodologia ágil de Scott Ambler para construção e implantação. Os projetos de armazenamento de dados têm um ciclo de versão curto e controlado por escopo e devem consistir em uma versão de produção a cada 2 a 3 semanas.

As equipes que usam a metodologia de cofre de dados devem se adaptar prontamente aos projetos repetíveis, consistentes e mensuráveis ​​que são esperados no CMMI Nível 5. Os dados que fluem através do sistema de cofre de dados EDW começarão a seguir o ciclo de vida do TQM (gerenciamento de qualidade total) que há muito tempo está ausente dos projetos de BI (inteligência de negócios).

Ferramentas

2150 Datavault Builder

Wherescape

Vaultspeed

Referências

Citações

Fontes

Literatura

• Patrick Cuba: o guru do armazenamento de dados. Um guia pragmático sobre a construção de um cofre de dados. Selbstverlag, ohne Ort 2020, ISBN 979-86-9130808-6.
• John Giles: O elefante na geladeira. Etapas guiadas para o sucesso do armazenamento de dados por meio da construção de modelos centrados nos negócios. Technics, Basking Ridge 2019, ISBN 978-1-63462-489-3.
• Kent Graziano: Melhor modelagem de dados. Uma introdução ao Agile Data Engineering usando o Data Vault 2.0. Data Warrior, Houston 2015.
• Hans Hultgren: Modelando o Agile Data Warehouse com Data Vault. Brighton Hamilton, Denver ua 2012, ISBN 978-0-615-72308-2.
• Dirk Lerner: Data Vault para agile Data-Warehouse-Architekturen. In: Stephan Trahasch, Michael Zimmer (Hrsg.): Agile Business Intelligence. Theorie und Praxis. dpunkt.verlag, Heidelberg 2016, ISBN 978-3-86490-312-0, S. 83–98.
• Daniel Linstedt: Supercarregue seu data warehouse. Regras de modelagem de dados inestimáveis ​​para implementar seu cofre de dados. Linstedt, Saint Albans, Vermont 2011, ISBN 978-1-4637-7868-2.
• Daniel Linstedt, Michael Olschimke: Construindo um data warehouse escalável com Data Vault 2.0. Morgan Kaufmann, Waltham, Massachusetts 2016, ISBN 978-0-12-802510-9.
• Dani Schnider, Claus Jordan ua: Projetos de data warehouse. Business Intelligence in der Praxis. Hanser, Munique 2016, ISBN 978-3-446-45075-2, S. 35-37, 161-173.

links externos

• A casa dos usuários da comunidade Data Vault
• O caminho para a certificação
• A página inicial de Dan Linstedt, o inventor da modelagem de Data Vault
• Um site dedicado ao Data Vault, mantido por Dan Linstedt
• Vídeos do Youtube sobre abordagem e metodologia de modelagem de armazenamento de dados
• Site de compartilhamento de slides de Dan Linstedt
• Site de certificação do Data Vault
• Site de dados ágeis
• Local de Entrega Agile Disciplinada (DAD)