Data Warehouse (DW) – O Centralizador de dados

Para início, é importante frisar que, até o presente momento, não se consegue pensar em um projeto de BI tradicional sem a presença de um Data Warehouse, na verdade, “até funciona”, mas, com erros de conceitos que acarretará em perda de performance, ausência de escalabilidade e o maior dos problemas, a ineficácia no alcance do objetivo do projeto.

Os artefatos do BI (Dashboards, Insights, KPI…) são o resultado de um processo que envolve, em resumo, coleta, mineração e exibição dos dados para análise, e o ponto inicial deste processo são as fontes de dados que podem ser diversas. Os bancos de dados relacionais são exemplos de fontes de origem desses dados.

Para entendermos a importância do Data Warehouse (DW) em um projeto de BI, vamos analisar algumas características:

  • Um banco de dados relacional é estruturado a partir de uma modelagem bidimensional onde os dados são consolidados em linhas e colunas, organizados e normalizados, para garantir as regras de integridade (chave, domínio, referencial, etc.) bem como as propriedades ACID, além de eliminar redundâncias.
  • Um projeto de BI precisa de respostas rápidas e não se preocupa muito com informações repetidas, pois o objetivo final é entregar a resposta certa da forma mais rápida. Para isso acontecer, precisamos que todos os dados estejam agrupados, afim de fornecer uma visão mais ampla do negócio. Neste caso, faz-se necessário a utilização da modelagem multidimensional, que é a arquitetura requerida pelo banco DW, mas isso é assunto para outro post.

Temos então o armazém de dados, local para onde são enviados os dados colhidos nas diversas fontes. Estas informações serão organizadas, agrupadas e contadas para que possam ser utilizadas. Após essa definição tosca do que seria um DW, vamos ver o que diz um dos mais renomados autores do tema.

Segundo William H. Inmon, Data Warehouse é uma coleç

ão de dados orientada por assuntos, integrada, variante no tempo, que tem por objetivo dar suporte aos processos de tomada de decisão.

Orientado ao assunto Agrupados por assunto dos negócios
Integrado Dados de diversas fontes
Não volátil Sempre inserido, nunca excluído
Variante no tempo Posições temporais das atividades

O processo de montagem de um DW se dá em:

  • Extrair os dados de alguma(s) fonte(s).
  • Transformar estes dados (agrupar e contar).
  • Fazer a carga destes para dentro do banco DW.

A este processo damos o nome de ETL, acrônimo de Extract Transform Load, em português, Extração, Transformação e Carga. Este assunto, por sua vez, também merece uma leitura exclusiva, e em breve falaremos sobre ele.

O objetivo do Data Warehouse é armazenar todas as informações que possam ser contadas e agrupadas através do tempo. Quanto maior for a empresa, mais dados serão armazenados. Um projeto de BI pode ser inviabilizado por causa do tempo em que se levará para montar o DW. Para resolver este problema surgiram os Data Marts.

Podemos definir um Data Mart (DM) como um sub-conjunto do Data Warehouse, onde cada Data Mart agrupa um determinado assunto ou setor da empresa, por exemplo, podemos ter o DM do financeiro, um DM de vendas, um DM de produtos e todos eles juntos formam um DW. Confuso? Vamos tentar de outra forma.

Podemos montar o Data Warehouse a partir de duas abordagens:

  • Top-down: é quando a empresa cria um DW e depois parte para a segmentação, ou seja, divide o DW em áreas menores gerando assim pequenos bancos orientados por assuntos aos departamentos.
  • Botton-up: é quando a situação é inversa. A empresa, por estratégia, prefere primeiro criar um banco de dados para uma área apenas. Com isso os custos são bem inferiores do que os de um projeto de DW completo. A partir da visualização dos primeiros resultados passa-se a implementar outra área, e assim sucessivamente até resultar em um Data Warehouse.

Agora que esclarecemos as diferenças entre DW e DM, vamos imaginar isso tudo acontecendo.

Supondo que a fonte de dados é um banco de dados relacional, para ter informações reais, devemos ler estes dados do banco de produção. Então, conectamos nossa ferramenta de ETL no banco relacional de produção e executamos alguns relacionamentos, agrupamentos, somas, entre outros processos que podem durar horas.

Se você tiver um faro fino para problemas, vai perceber que fazer todo esse processo conectado no banco de dados de produção não é uma ideia muito legal. Para resolver este problema, existe mais uma etapa neste processo.  Geralmente separado do servidor de produção, um processo que chamamos de Staging. É um banco de dados que não segue as regras de integridade ou propriedades ACID, seu objetivo é receber todas as informações que foram copiadas do banco de dados relacional e executar todo o trabalho, ou seja, a ferramenta de ETL copia todos os dados que quer trabalhar para dentro da Staging, e a partir daí, a ferramenta faz todo o processamento neste servidor, desta forma, o banco de dados de produção não sofre uma sobrecarga. Depois de todos esses processos executados, a ferramenta copia os dados prontos para dentro do Data Warehouse ou do Data Mart.

Para que tudo isso funcione de forma bem organizada, a Staging deve possuir algumas características como, não exigir nenhuma regra de integridade, isso aumenta a performance do processamento.

 


Fonte: Database Data Warehousing Guide

Referências

CONSTRUÇÃO DE DATA WAREHOUSE (DW) E DATA MART (DM)

Disponível em <https://imasters.com.br/artigo/11178/gerencia-de-ti/construcao-de-data-warehouse-dw-e-data-mart-dm?trace=1519021197 HYPERLINK > Acesso em: 09 mai. 2017

DATABASE DATA WAREHOUSING GUIDE

Disponível em <https://docs.oracle.com/database/121/DWHSG/concept.htm#DWHSG8073 > Acesso em: 09 mai. 2017

 

Leave Comment

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *