Quando se fala em Data Warehouse (DW) e Business Intelligence (BI), imediatamente associamos às ferramentas de consulta gráfica. Estas ferramentas são extremamente importantes, pois seus recursos amigáveis de point & click e facilidades tipo drill down facilitam sobremaneira o trabalho de análise de informações. Mas existe um outro lado menos glamouroso do BI que a própria mídia especializada também tende a esquecer: a carga e a limpeza dos dados nos DW. Sem dados consistentes e confiáveis, qualquer gráfico ou relatório gerado poderá levar a decisões erradas. Assim, esse aspecto pouco comentado de BI merece uma atenção toda especial.
Algumas dúvidas começam a aparecer à medida que nos aprofundamos na questão. Primeiro, os dados dos sistemas transacionais, sejam eles legados ou ERPs, serão extraídos de forma sumariada? Ou será que essa sumarização não eliminaria informações que poderiam ser úteis em futuras análises? Qual será a periodicidade dessa extração? Como os dados serão obtidos? Uma simples cópia de tabelas de um ERP nem sempre significa informações válidas, pois, de maneira geral, essas tabelas fazem sentido apenas para o próprio ERP.
E quanto ao processo de atualização do DW, como reconhecer que informações foram alteradas nos sistemas transacionais desde o último ciclo de atualização? Outra dúvida: como garantir que os dados terão a qualidade e consistência adequadas? E mais uma pergunta cruel: como obter dados históricos? Um DW trabalha muitas vezes com dados históricos, e a maioria dos sistemas transacionais não armazena dados por muito tempo, pois são orientados a fazer transações.
Um DW precisa ser carregado a partir de dados dos sistemas transacionais, e muitas vezes esse processo precisa passar por um intenso trabalho de conversão e transformação. Como os dados a serem armazenados serão usados para análises de decisões de negócio, precisam ter qualidade e consistência. E como garantir essa qualidade? De maneira geral, existem três oportunidades de intervenção: na própria aplicação; no processo de transformação e carga do DW; e depois de o DW ter sido carregado com os dados.
A teoria nos diz que se os dados estão limpos na aplicação, não precisam ser tratados para serem carregados no DW. Mas, mesmo em um ERP (e principalmente nos sistemas legados, mais antigos) nem sempre essa teoria reflete a realidade. Dados referentes a endereços, nomes e variáveis pouco importantes às transações tendem a não ser validados em seu processo de criação.
O momento da transformação e carga dos dados é uma boa oportunidade de sincronizar as diversas visões e interpretações dos dados da empresa. Mesmo que tenhamos um ERP, certamente existirão dados fora desse pacote, em outras aplicações (ou em outro ERP), que precisam ser carregados no DW.
Onde estarão os problemas? Podem estar em diversos lugares diferentes, como nas chaves de acesso, nas estruturas de dados, nos inter-relacionamentos entre os dados e nas convenções de codificação. Assim, todo e qualquer dado que venha de um ERP, ou de outra aplicação, deve passar por uma camada de software encarregada de transformá-lo e adequá-lo tanto em qualidade quanto em consistência.
Podemos pensar também em limpeza dos dados após sua carga no DW. Um exemplo dessa necessidade é quando precisamos armazenar dados históricos com projeções de muitos anos. Se quisermos armazenar dados com esta longevidade provavelmente enfrentaremos situações como moedas diferentes e codificações que mudaram com o tempo (uma nova codificação contábil, por exemplo).
E como garantir integridade referencial em um DW? Em um ambiente transacional, as relações ocorrem no mesmo período de tempo. Mas em um DW, a dimensão tempo provoca situações anômalas que devem ser consideradas. Por exemplo, uma relação entre dois dados pode existir em um determinado momento e não existir em outro. Mas esses dois momentos estão armazenados no DW.
E uma vez que já pensamos nos desafios da qualidade dos dados, devemos agora pensar em como buscar esses dados. Existem basicamente três momentos de carga de dados: (a) uma eventual carga a partir de dados históricos; (b) a carga inicial, baseada nos dados dos sistemas transacionais; e (c) a atualização rotineira do DW a partir de dados atualizados pelos sistemas transacionais. Cada uma das três modalidades oferece desafios diferentes e devem ser analisadas cuidadosamente.
A carga de dados históricos é simples do ponto de vista tecnológico. É efetuada uma única vez e geralmente obtida de arquivos seqüênciais. A dificuldade é com relação ao seu conteúdo, pois provavelmente muitas informações estão armazenadas com códigos obsoletos. E, infelizmente, algumas empresas podem não ter um controle rígido sobre seus arquivos históricos e, assim, não podem garantir que o próprio meio de armazenamento esteja 100% correto.
A carga inicial exige que as bases de dados dos sistemas transacionais sejam acessadas e carregadas no DW. Estas bases de dados podem ser acessadas diretamente ou lidas e convertidas para arquivos flat e, posteriormente, carregados no DW. Esta segunda alternativa geralmente é considerada quando as bases de dados exigem acessos especiais, como as bases de dados SAP, que só podem ser acessados via APIs próprias.
A atualização rotineira do DW é o desafio mais complicado. Vamos imaginar uma situação hipotética: um determinado DW foi carregado na segunda-feira. Durante toda a semana, os sistemas transacionais receberam atualizações, inserções e deleções de dados. E chega a outra segunda-feira. Como atualizar o DW? Carregar todo ele novamente poderá ser inviável devido ao volume de dados envolvidos. Assim, devemos atualizá-lo apenas com as informações que foram modificadas na semana. Mas como fazê-lo? Vamos discutir algumas técnicas que podem ser adotadas, isoladamente ou em conjunto. A título de exemplo, vamos imaginar que nosso sistema transacional está baseado em um ERP qualquer.
Uma técnica poderia ser substituir completamente os dados oriundos de determinadas tabelas do ERP. Entretanto, essa substituição só tem validade se a tabela for pouco modificada (deve ser bastante estável). O porém é que não teríamos registros do histórico das mudanças, pois estaríamos refletindo apenas a última situação delas.
Outra técnica seria criar arquivos que registrassem as alterações sofridas pelas bases de dados do sistema transacional. Infelizmente, na prática, significa alterar a aplicação transacional (nos sistemas mais antigos, sem documentação atualizada, seria um imenso risco) para gerar tais arquivos e, no caso dos ERPs, nem sempre essa facilidade existe.
Uma terceira alternativa é interceptar as alterações no nível do software de banco e dados (dbms call level). Nem sempre isso é possível, pois existem restrições do próprio banco de dados, levando a uma maior demanda de I/O, que pode afetar a performance do sistema transacional, e não há garantia que a transação efetivamente foi realizada, pois, após o update, algum evento pode ter impedido a transação de ser finalizada corretamente.
Podemos pensar também em usar as log tapes (as que são usadas para backup/recovery) para identificar as modificações ocorridas. Entretanto, temos problemas em conhecer seus layouts e nem sempre conseguimos identificar os dados que nos interessam. Além disso, será óbvio que teremos que debater calorosamente a questão com o pessoal da produção, que não gosta de ver seus arquivos de backup sendo processados pelas aplicações, fora de seu controle.
Como vemos pelos exemplos anteriores, definir procedimentos que mantenham o DW atualizado não é uma tarefa trivial. Cada organização deve pensar nas suas modalidades específicas e pode até mesmo adotar algumas das técnicas citadas. Ou, mais provavelmente, criar outras.
De qualquer maneira, o sucesso do DW está na capacidade de manter-se atualizado, com dados consistentes e de qualidade. Para isso, é necessário muito esforço e planejamento.
Cezar Taurion é consultor da Pricewaterhouse Coopers [email protected]
