Uma discussão sempre presente no cenário de Data Warehouse é o debate “É melhor um Data Warehouse corporativo ou um Data Mart setorial?”. Os Data Marts têm ganho popularidade, pois tendem a ser implementados em muito menos tempo e a custos bem menores que um Data Warehouse corporativo.
Infelizmente, ao construirmos nosso segundo Data Mart identificamos que alguns dados já são usados pelo primeiro. No terceiro, percebemos que utilizamos muitos dados que se repetiam nos anteriores. Em conseqüência disso, chegamos à triste conclusão que a proliferação de Data Marts sem integração leva a redundâncias e muitas vezes à inconsistência de dados.
Construir um Data Warehouse corporativo tem vantagens e desvantagens. As vantagens seriam a visão única e consolidada dos dados, que eliminam redundâncias e disponibilizam uma única interface entre o usuário e as informações da qual ele precisa. As desvantagens ficam por conta do custo e tempo para sua implementação.
Mas, por que não ficarmos com a solução ideal de desenhar um Data Warehouse corporativo e obter suas vantagens, implementando-o por Data Marts, integrados, e construir passo a passo um cenário corporativo?
De maneira geral, tende-se a confundir o termo Data Mart com Data Warehouse pequeno, como se a diferença fundamental entre os dois fosse, exclusivamente, o tamanho da base de dados. Um Data Mart não é um Data Warehouse pequeno.
As diferenças estão basicamente nos seus objetivos e missões. Um Data Mart está focado em uma determinada função de negócio e geralmente obtém seus dados das aplicações específicas desse negócio.
Por outro lado, um Data Warehouse suporta uma visão “cross-function”, cruzando e integrando informações de diversas funções. Suas fontes de dados também são múltiplas: as diversas e numerosas aplicações que apóiam as funções realizadas pelo Data Warehouse.
A discussão começa a perder sentido quando começamos a falar de uma empresa “customer-centric”, na qual o cliente se torna o foco do negócio. Um Data Warehouse compatível com uma visão empresarial “customer-centric” é por natureza integrado, pois o relacionamento de um cliente com a empresa cruza diversas funções de negócio, como marketing, vendas, produção, financeiro e outras.
Manter essas informações fragmentadas pelas diversas funções ou pelos diversos departamentos da empresa jamais nos permitirá ter uma visão completa do cliente.
É muito simples entender isso: cada função de negócio é suportada por aplicativos específicos (ou módulos específicos de um ERP), que armazenam e processam as transações efetuadas. As referidas transações podem ser de “order processing”, faturas, movimentação do estoque e assim por diante. O cliente aparece direta ou indiretamente em todas essas transações, mas o foco delas é na própria operação efetuada e não no relacionamento com o cliente em si.
Se quisermos um Data Warehouse que suporte uma visão “customer-centric”, devemos ter visão integrada do relacionamento desse cliente com a empresa. Isto significa aglutinar todas as informações pertinentes ao cliente (e seus familiares, dentro do conceito de “householding”) e suas transações em um único local.
Mas construir um Data Warehouse corporativo é um grande desafio.
As dificuldades começam pela pouca integração e compatibilidade dos dados espalhados pelas diversas aplicações. Outro problema sério é a qualidade dos dados encontrados, principalmente daqueles referentes às análises geodemográficas (como nomes, idades e endereços), que por serem de pouca importância aos sistemas transacionais, nunca foram exaustivamente criticados e validados. Uma pesquisa recentemente efetuada nos EUA mostrou que de 30% a 50% dos dados armazenados nos sistemas corporativos estavam incorretos ou inconsistentes.
Vamos analisar um pouco esses problemas. A questão da integração é emblemática das dificuldades encontradas no caminho de um Data Warehouse. Um Data Warehouse “customer-centric” deve integrar as informações sobre clientes espalhadas por toda a empresa e seus diferentes sistemas. Nesse momento aparecem os primeiros problemas de códigos de clientes diferentes e dificuldade de relacionar uma determinada transação a um cliente (não havia essa preocupação nos sistemas transacionais). Depois, a limpeza dos dados encontrados. Quando se fala em nomes e endereços, encontra-se de tudo.
As inconsistências e incorreções são muito grandes: nomes incompletos ou grafados erroneamente (tanto nas pessoas físicas como Mário Júnior, Mário J e Mário Jr, quanto nas jurídicas, como PAT, PA&T, PAT Ltda., etc.), abreviaturas não padronizadas (Ave., Av., aven., etc.), erros (nomes nos lugares dos endereços ou o endereço é número 100 ou 1000?), ausência de dados (falta número do apartamento) e assim por diante.
Portanto, ao aglutinarmos os dados de um único cliente, precisamos limpá-los e identificar qual das diversas versões será a correta e mais atualizada. Não é muito simples de fazer.
Um outro desafio é a atualização do Data Warehouse. Como as fontes de dados são os sistemas transacionais, as atualizações são constantes. Os clientes estão fazendo transações a cada instante com a empresa. Novos clientes e aplicações aparecem. Como atualizar o Data Warehouse? Atualizar todos os seus registros pode ser uma tarefa árdua. Por outro lado, atualizações parciais precisam ser bem definidas, a fim de evitar que se tornem indevidas ou incompletas.
De maneira geral, atualizar apenas o que foi modificado é a solução mais adequada em termos de custo e desempenho. Mas, por ser uma operação mais complexa que um simples “reload” de base de dados, seu planejamento e sua operacionalização precisam ser muito bem pensados. Basta imaginar uma atualização diária de 5000 clientes em base de 10 milhões de clientes. Evitar procedimentos demorados e ineficientes é importantíssimo para termos o Data Warehouse sempre atualizado e disponível.
Por outro lado, atualizar um Data Mart é muito mais fácil. Vamos imaginar um Data Mart de vendas, no qual apenas as vendas do dia (lojas e produtos) são incorporadas à base de dados. Como não existem informações que relacionam essas vendas aos clientes, não há necessidade de modificação de registros detalhados. Diferente de um Data Warehouse “customer-centric”, no qual precisamos atualizar a movimentação efetuada pelo cliente.
Uma boa e simples maneira de se identificar o potencial de problemas com a proliferação de Data Marts é fazer uma planilha onde colocamos nas linhas horizontais os Data Marts existentes ou a serem implementados, e nas colunas verticais as dimensões de cada um (informações). Onde um Data Mart usar uma determinada dimensão, marca-se um X na interseção.
Ao preenchermos essa planilha, vamos descobrir que muitos dos Data Marts usam as mesmas dimensões. Se a maioria das células for marcada com X significa que a maioria dos Data Marts usa as mesmas dimensões. Por que então mantê-los separados?
Cezar Taurion é consultor da Pricewaterhouse Coopers
[email protected]
