Datawarehouse x Datamart

Você sabe a diferença entre Datawarehouse e Datamart?

Uma duvida muito comum é a diferença entre um banco de dados relacional e um Datawarehouse. Pois bem, a diferença é apenas conceitual e de modelagem. Em ambiente OLTP, as tabelas são criadas com normalização, visando a não duplicidade dos dados e a redução do espaço em armazenamento, enquanto que em um Datawarehouse, não nos preocupamos com duplicidade e espaço em disco, mas sim com a performance das querys. Ambos são criados com os mesmos comandos físicos, geralmente o CREATE DATABASE.

Outra dúvida na mesma linha é a diferença entre um Datawarehouse e um Datamart. Nesse caso, não há diferença na modelagem, ficando apenas a questão conceitual. Um Datamart é parte de um Datawarehouse, ou um Datawarehouse é composto por Datamarts. Parece confuso, mas é bem simples.

A implementação de um projeto de BI requer investimento, tanto em hardware quanto em pessoal. Muitas das vezes, a empresa não pode ou não quer investir tanto dinheiro no projeto e fazer uma modelagem Top Down, ou seja, de cima para baixo. Nesse modelo, mapeamos todos os dados da empresa como um todo e construímos o Datawarehouse. Há a modelagem Down Top, que ao contrário da modelagem anterior, aplica o sistema de construção por partes, ou seja, primeiro mapeamos os setores, para compor no fim todo o Datawarehouse. Esse mapeamento parcial, por exemplo de um setor de Marketing, é chamado de Datamart. O setor de Marketing poderá analisar normalmente o seu Datamart, que para o setor é o seu Datawarehouse. Entendidos os conceitos? Vamos ao caso de estudo:

A empresa XYZ vende passagens aéreas e precisa implementar a análise de dados voltada para negócios em na empresa para descobrir os locais mais rentáveis e a sua sazonalidade, com a finalidade de fazer uma campanha de marketing para seus clientes. A empresa conta com os seguintes setores:

• Contabilidade: Registra todo o movimento contábil da empresa.
• Comercial: Venda de passagens aos clientes.
• Marketing: Comerciais, banners, acesso ao website e campanhas em geral.
• Logística: Registro de despesas internas e contratos com fornecedores.
• RH: Funcionários e contratos de terceirizados.
• Fiscal: Contabiliza tributos e taxas.

Caso o projeto fosse implementado da maneira Top Down, teríamos um Datawarehouse completo, com todos os setores. O projeto porém, demandaria mais tempo e obviamente, mais custo. Essa é a desvantagem desse padrão, além de ser mais arriscado trabalhar com um montante maior de dados.

Modelo TOP DOWN de Datawarehouse

Caso o orçamento ou tempo disponível para a realização do projeto não fosse o suficiente, poderíamos optar pela estratégia oposta, começarmos a modelagem de baixo, por setores, que pode ser feita em períodos diferentes, ou seja, poderíamos dar um start no projeto de modelagem apenas para o setor de marketing, e com mais budget, modelarmos os demais setores mais à frente.

Como o projeto demanda relatórios de locais mais rentáveis e sazonalidade, precisamos somente verificar as passagens vendidas, reservadas, canceladas e etc. Não é necessário analisar por exemplo, os dados de RH, ou os dados do setor fiscal. É aí que entra o Datamart. O Datamart é uma parte do Datawarehouse. Com a visão do setor de Marketing, teremos um Datawarehouse, mas ele não representa todos os dados da empresa, sendo assim por uma visão geral, ele é um Datamart.

Vale ressaltar que essa técnica não é aplicada somente por orçamentos restritos ou tempo. Há empresas que aplicam a técnica com o propósito de distribuir as suas bases em locais físicos diferentes, facilitando e otimizando o acesso. Abaixo, temos um modelo de Datamart.

A modelagem de um Datawarehouse um um Datamart não tem uma fórmula mágica, ou uma receita de bolo. O segredo para se fazer uma modelagem correta é levantar os requisitos de uma forma detalhada para saber realmente o que o cliente deseja e resgatar as informações que geram esses relatórios de forma consistente. Quanto mais genérica for a pedida ou dúvida do gestor, mas dados teremos no Datawarehouse.

Suponhamos que a implantação tenha o seguinte objetivo: Maximizar os lucros e diminuir as despesas. Temos várias formas de chegar a esses objetivos:

Um Datamart de RH nos traria os funcionários com maior e menor salário, horas trabalhadas, voos nacionais ou internacionais e certamente calcularíamos o custo benefício de cada um, ou regionalmente, ou setorialmente e assim poderíamos implantar uma política interna com redução de cargo ou jornada de trabalho.

Um Datamart comercial nos mostraria os voos mais procurados e em que época, nos permitindo assim cancelar voos com pouca procura, que geram despesas com combustível, salário, lanche da tripulação e passageiros.

Um Datamart de Logística nos permitiria ver os fornecedores mais caros e a quantidade utilizada do produto, assim como a sua prioridade. Poderíamos por exemplo, trocar a marca do refrigerante servido à bordo, por uma marca mais barata. Substituir sanduíches por biscoitos. Parece pouco, mas qualquer medida tomada em grande escala, toma proporções imensas, representando uma porcentagem significativa no faturamento da empresa.

É completamente possível utilizar as duas abordagens. Um Datamart também pode ser criado a partir dos sistemas transacionais, o que não recomendo por questões de performance, mas o mesmo também pode derivar seus dados a partir de um Datawarehouse central, ou seja, temos uma estrutura central construída, que disponibiliza os dados para os Datamarts.