Artigo Clube Delphi Edição 12 - Data Warehouse

Data Warehouse

Prepare-se para um armazém bem diferente !

A tendência a uma abordagem mais analítica dos dados armazenados em nossas aplicações tem colocado o Data Warehouse e os "Sistemas de Apoio a Decisão" em evidência nos últimos tempos, o que  é muito bom. Porém,  a pergunta que tem atormentado alguns desenvolvedores é: "Para quem...? "

O termo assusta boa parte dos programadores e usuários mas não é tão complicado assim. Os principais problemas são a falta de documentação sobre a tecnologia e as definições ou regras que ainda não estão muito claras.

Mas vamos passar sobre esses fatores menores e focar sobre nós, criadores de software: de que forma podemos ter um primeiro contato com a tecnologia e como ela pode afetar os projetos do dia a dia?

Sendo assim, outra pergunta surge: quem precisa de um DW?  Podemos até pensar: "fiz um programa para controlar uma vídeo-locadora, esses caras nunca vão precisar de um DW de verdade". Engano seu. Imagine uma grande vídeo-locadora com dezenas de lojas; não será preciso saber quais são as fitas mais locadas, quais clientes entregam as fitas nas primeiras 24 horas mesmo podendo ficar mais um dia, qual é a média de retorno de uma fita que custou R$ 70,00 para ser adquirida, entre outros?

Estas informações estatísticas não estão armazenadas diretamente dentro de sua base de dados e esse é o principal conceito que torna um DW uma base de informações, e não apenas uma base de dados. Todos os sistemas de apoio a decisão trabalham com informações organizadas desta forma.

Imaginar que seja possível ter esse tipo de resultado trabalhando em uma base de produção OLTP (Processamento de Transações On-Line) e tentar executar grandes pesquisas SQL sobre ela, pode fazer com que todos os usuários do sistema tenham "chiliques" enquanto tudo fica cada vez mais lento e lento. Provavelmente, poderíamos até extrair informações relevantes, mas imagine que um determinado processamento leve 6 horas. O que você vai fazer? Instruir para que este processamento seja rodado à noite? Quem vai ficar olhando se está tudo em ordem? Seu cliente ou diretor da empresa quer uma informação importantíssima e dela depende uma decisão comercial crítica; quem vai falar para ele que a informação só estará disponível no dia seguinte? Imagine a situação: quase no final do processamento alguém aperta o botão fechar do form!

Essa é uma das razões pela qual podemos dizer  "sim" a  um DataWarehouse. Pois bem,  e por onde começar?

Como o próprio nome diz, "Data Warehouse" é um "Armazém de dados" e para administrar esse armazém devemos conhecer como funcionam suas regras :

1- Um DW existe para fornecer dados Corporativos ou Organizacionais para Gerentes e/ou Diretores. Devem ter o poder de acessar estas informações rapidamente e de qualquer local ou forma que julgarem adequado.

2- Consistência de dados. O ponto mais forte de um DW é a confiabilidade. Se um dado não está correto ou não foi completamente carregado ele deve ser descartado e o analista responsável tem que ser avisado. Em um sistema OLTP, todos os controles de consistência visam garantir a integridade de pequenas transações, enquanto em um DW devemos nos preocupar com o  aspecto mais global, onde o que realmente importa é o sucesso da nova carga de dados.

3- O DW completo é composto por :

* Hardware Central, equipamento que dá sustentação ao DW. Deve ser dimensionado de acordo com a quantidade de dados esperada e o número de consultas diárias.

- Software de banco de dados relacional, o melhor possível.

- Os dados. Fornecidos por um sistema OLTP, que processa as transações diárias da empresa.

- Ferramentas de "Front-end", que devem prover formas de acessar os dados armazenados.

4- Slice and Dice. Os dados contidos no Data o negócio. Este aspecto também depende muito do tipo de negócio que estará sendo avaliado.

5- A qualidade dos dados fornecidos pelo sistema OLTP é fundamental para que o DW possa apresentar dados úteis para todos. Por exemplo, se durante a locação de uma fita o campo "Gênero" não foi preenchido corretamente pois era opcional, não será possível ao DW analisar essa informação e apresentar estatísticas baseadas nela, simplesmente porque a informação não estava presente na tabela original (OLTP). Portanto, muito cuidado com os campos ditos "opcionais" - eles podem levar o seu Data Warehouse a falência.

E como os dados chegam até o nosso armazém ???

A coisa mais simples do mundo depois de um repeat..until!. O DW é montado lendo-se as informações da base de dados principal, organizando-as e gravando na base do DW. Essa é a parte fácil, agora vamos ver os detalhes da coisa toda.

Duas observações rápidas :

1 - De quanto em quanto tempo devemos fazer a carga de dados do sistema de origem (OLTP) para a base de dados do DW? Normalmente utilizamos a dimensão tempo para definir o processo. Se a menor unidade da dimensão tempo for "dia" então o DW "deverá" ser carregado a cada dia.

2 - A base de dados do DW deve ser realmente uma base separada da base principal OLTP? Sim, pois o "Stress" gerado na base original pelas consultas SQL para apurar informações gerenciais é muito grande e vai afetar a performance da aplicação OLTP que está fornecendo os dados. Prover um equipamento para este fim é a melhor política.

É importante observar que não podemos encará-lo como um projeto OLTP. Emitir uma NF, baixar estoque e registrar contas a receber não existem mais, agora o negócio é outro. Temos que recuperar essas informações em nível estratégico, e não pense que é daquele jeito manjado "uma listagem de NFs emitidas", pois esse tempo já passou. Apresentar esse tipo de relatório a um CEO afinado com as inovações tecnológicas do mercado é a morte!

Minha consideração pessoal é que a tarefa mais importante de toda essa tecnologia é desenhar adequadamente o Data Warehouse e processar os dados afim de armazená-los dentro da base.

Essencialmente, o desenho de um Data Warehouse é um trabalho de modelagem de dados e está profundamente ligado às necessidades de informação da empresa.  Não quer dizer que é para Delphi, VB, C++ ou JAVA, pois está totalmente desvinculado da linguagem que será utilizada para acessar ou processar os dados, nem me perguntem qual ferramenta eu utilizo :-)

Imagine que o diretor da sua empresa pergunte: "Qual o nosso produto campeão de vendas no mês de Janeiro/2000?". Através dessa pergunta podemos determinar que existem duas dimensões de pesquisa para o dado: primeiro a linha do tempo, pois a pergunta indica um período Janeiro/2000, e a outra a dimensão produto, pois indica o produto a ser pesquisado. O cruzamento dessas duas linhas nos trazem parâmetros para recuperar a informação necessária. Notem que um diretor jamais irá perguntar qual o terceiro produto da Nota Fiscal número 04287 emitida em 01/08/2000. Esta informação está em um nível de detalhamento que não interessa a um diretor, suas questões são bem diferentes.

Nem todas as necessidades são tão simples. E se a pergunta fosse : "Qual o nosso desempenho de vendas nos mercados que atuamos no último ano ???" Podemos então determinar três dimensões para medição: Dimensão Tempo (o período a ser analisado é o último ano), Dimensão Produto (desejamos o desempenho de vendas) e a Dimensão Mercados (desejamos saber quais os mercados com melhor desempenho). Este tipo de abordagem chama-se Data Warehouse multidimensional, e a melhor forma de visualizar como as informações são armazenadas é observar o modelo "cubista":

Isso não lembra alguma coisa como um Decision Cube?

Não é uma forma tão complexa de analisar dados. Uma estrutura deste tipo lembra muito uma matriz multidimensional e é o caminho mais fácil para que os usuários compreendam como as informações estão à disposição. É a maneira perfeita para mostrar como a abstração dos dados pode ser vencida com algumas técnicas novas. Alguns de vocês assistiram MATRIX ?

Isso quer dizer o seguinte, quando vamos armazenar os dados de faturamento de uma loja em um sistema OLTP temos sempre o nível mais detalhado possível, como registros contendo o número da loja, o produto com valores e quantidades, o PDV que efetivou a venda, dados do cliente e assim por diante. Esse tipo de informação, ou melhor, toda essa quantidade de informação tem que ser "tabulada", filtrada, limpa, organizada, checada e consolidada para que seja útil dentro do DW. Tentar ver essas informações sem um devido tratamento é como ver um quebra-cabeças não montado. Simplesmente não conseguiremos visualizar todo o potencial de informação lá contido porque não veremos as informações como deveríamos.

Abaixo um exemplo típico de um registro em um Data Warehouse. A tabela central em nosso modelo "VENDA" é conhecida como tabela de "Fatos":

Junto da tabela de fatos nós temos as tabelas de dimensão, que orbitam a tabela de fatos e trazem informações adicionais, como dados sobre um produto, sobre a loja ou sobre a medição de tempo.

O planejamento do DW e as definições sobre os dados lá armazenados afetam sobremaneira o nível de retorno que podemos ter, mas também podem deixar o acesso às informações muito difícil e demorado. Observe que quando processamos nossa base OLTP e gravamos os dados para o DW, se não nos importarmos com o dado PDV da loja, será impossível determinar qual dos PDV's da loja vende mais. Essa informação será perdida durante o processo e esse é um dos grandes riscos do DW.  Fazer um projeto visando atender as necessidades reais da organização, evitando o armazenamento de dados desnecessários e ao mesmo tempo gravando as informações realmente relevantes é o grande objetivo de quem pretende dar início a um projeto desse tipo.

As tabelas dentro de um DW são modeladas de acordo com o exemplo anterior, na maioria das vezes assumindo uma estrutura radial, com grandes tabelas no centro (as tabelas de fatos) e outras menores (as tabelas de dimensão), orbitando as tabelas de fatos e provendo as dimensões em que os dados podem ser analisados em conjunto com informações adicionais sobre cada uma das dimensões.

No modelo acima definimos que serão armazenados os totais de venda de um determinado produto, em uma determinada loja em um dia de vendas. Assim é correto dizer que o "grão" de nossa tabela é "Produto / Loja / Dia", pois é  a menor porção de dados possível a ser recuperada, em todas as medições.

Olhando por este aspecto temos a impressão de que toda a informação relevante está localizada na tabela de fatos e que as tabelas de dimensão não oferecem qualquer tipo de dado relevante ou que possa alterar a análise das informações nas tabelas de fatos. Bem, essa visão está equivocada, embora seja comum para as pessoas que estão começando a projetar bases de dados para DW.

Uma abordagem um pouco mais profunda revela que as tabelas de dimensão são as grandes responsáveis por nos fornecer os mecanismos restritivos necessários para análises cirúrgicas em nossos dados. O usuário inicia uma consulta típica a um DW sobre as tabelas de dimensão, onde diversas pequenas pesquisas serão realizadas e atributos serão definidos para que sejam aplicados à pesquisa final. Estas operações são geralmente muito rápidas e definem as regras que serão aplicadas sobre a tabela de fatos gerando um "conjunto de resposta". Podemos dizer que as tabelas de dimensões desempenham um papel de "guias de pesquisa" fazendo um ajuste fino sobre o resultado esperado. Quanto maiores os recursos para que os usuários possam definir quais serão essas guias, menores serão os conjuntos de resposta e menor será o trafego de rede e menor o tempo consumido pelo processamento.

Imagine que temos um cliente que pratica comércio de produtos no varejo, como uma grande loja de departamentos, onde existem diversas lojas a serem controladas e muitos produtos. Facilmente esse cliente poderá alcançar milhares de registros ou talvez milhões. Em situações desse tipo, a perfeita seleção de parâmetros de pesquisa pode significar o sucesso ou não de um projeto de DW.

Definitivamente, se houver a necessidade de economia de tempo em um projeto de Data Warehouse (já sabendo que todos os projetos são para ontem), não economize na fase de projeto, pois este será um momento precioso durante todo o processo de desenvolvimento do DW e, com certeza, não poderemos voltar no tempo para recuperá-lo.