Ferramentas de Back End Por Eliane Martins de Sousa, pós-graduada em Sistemas de Informações Inteligentes pelo CRRM - Université Aix-Marseille III, (Fr) e Analista de Sistemas da Caixa Econômica Federal As ferramentas de back end são as responsáveis pelo processo de extração, limpeza, carga e restauração dos dados utilizados num sistema de Data Warehouse (DW). Essa etapa é também denominada de ETL - Extração, Limpeza, Transformação e Carga dos Dados. Embora tenhamos hoje em dia ferramentas que auxiliam na execução do trabalho, ainda assim é um processo trabalhoso, complexo e também muito detalhado. As ferramentas de extração de dados são caras, deve-se adquirir, se for o caso, após a definição dos requisitos de extração e transformação. Se a equipe de projetista do DW optar por desenvolver um software, o sistema de gerenciamento deverá executar, pelo menos, 11 processos ou a maior parte deles, para que seja possível extrair os dados de um banco de dados de produção e enviá-los para o DW. O conjunto desses processos é chamado, por Ralph Kimball, de Sistema de Extração de Dados de Produção - SEDP, os processos são: Extração primária; Identificação dos registros modificados; Generalização de chaves para dimensões em modificações; Transformação em imagens de registro de carga; Migração do sistema legado para o sistema DDW; Classificação e construção de agregados; Generalização de chaves para agregados; Carregamento; Processamento de exceções; Garantia de qualidade e, Publicação. Apesar de existirem ferramentas de ETL como o Data Stage (Ardent/Informix), o DTS (Microsoft) e o Sagent (da própria Sagent), às vezes é necessário criar rotinas de carga para atender determinadas situações que poderão ocorrer. Todos tem os seus diferenciais e cada um poderá ser utilizado dependendo do caso de cada empresa. O mais importante é que uma ferramenta de ETL tem grande valia, principalmente se os sistemas fontes (Legado, OLTP e/ou transacionais) que alimentarão o DW forem muitos, uma vez que essas ferramentas são uma poderosa fonte de geração de metadados e contribuirão muito para a produtividade da equipe. Podemos citar cinco operações principais realizadas pelas ferramentas back end: 1. Extração dos dados de fontes internas e externas; 2. Limpeza dos dados extraídos; 3. Transformação; 4. Carga no DW e, 5. Atualizações (refresh). 1. EXTRAÇÃO DE DADOS A extração de dados de fontes externas geralmente é feita através de gateways e interfaces padrão do tipo ODBC (padrão para acesso a banco de dados do SQL Access Group Consortium adotado pela Microsoft) ou outras, com diversos produtos já existentes no mercado. Para os dados de produção mantidos em um sistema de banco de dados relacional orientado para transação, várias ferramentas e aplicações utilizando SQL
extraem os dados para um arquivo ou envia-os (um registro por vez) para um aplicativo de solicitação. Entretanto, se os dados de produção estiverem armazenados em um sistema proprietário, tal como o pacote de entrada de pedidos de cartões de crédito de um fornecedor, o formato dos arquivos talvez não seja de conhecimento público, impossibilitando, às vezes, a leitura direta dos dados, para contornar o problema é necessário gerar um relatório ou criar um arquivo para descarregar os dados do sistema de produção. A catalogação dos sistemas de produção que alimentam o DW é recomendável para identificação precisa da extração primária dos dados. 2. LIMPEZA DOS DADOS De uma maneira geral, podemos dizer que o processo de limpeza e transformação dos dados que serão carregados num sistema de DW serve para corrigir algumas imperfeições contidas na base de dados transacional, a fim de fornecer ao usuário do sistema analítico dados concisos e com uma qualidade que permita uma tomada de decisão baseada em valores mais próximos dos reais. Idealmente, poderíamos imaginar que os dados deveriam apenas ser convertidos para padronização de medidas, porém sabe-se que podem existir valores incorretos numa base de dados transacional, os quais não podem ser propagados, principalmente no momento em que serão analisados estes dados, muitas vezes comparativamente. Além disso a limpeza é necessária porque os dados normalmente advém de uma fonte muitas vezes desconhecida nossa, concebida há muito tempo, contendo muito lixo e inconsistência. Por exemplo: se a empresa for de cartão de crédito, o vendedor está mais preocupado em vender o produto (cartão) do que na qualidade de dados que está inserindo. Se o cliente não tiver o número do RG na hora da venda, o vendedor cadastrará um número qualquer para agilizar a venda. Se for feita uma consulta posterior, levando-se em conta o número do RG dos clientes, no mínimo informações estranhas aparecerão (algo como RG número 99999999-99). Por isso, nessa fase do DW, faz-se a limpeza desses dados, para haver compatibilidade entre eles. O processo de limpeza não estará completo sem que se possa livrar os dados de problemas que, por algum motivo, passaram despercebidos nos sistemas de origem, tais como: código inválidos e preenchimento de vários campos com valores incompatíveis entre si. A própria modelagem do sistema OLTP pode conter "pontos fracos" que permitam, por assim dizer, a existência de dados inconsistentes, os quais podem e devem ser filtrados antes da carga no DW, podemos encontrar bases de dados com os seguintes problemas: Diferenças de unidades: podemos ter campos de idade dos clientes em anos ou em meses, sendo necessário converter todas as medidas para qualquer uma das duas (ou todas em anos, ou todas em meses); Diferenças de precisão: alguns valores de preços de produtos podem estar representados com duas casas decimais em uma tabela e com quatro casas decimais em outra tabela, cabendo ao administrador do DW definir qual a precisão desejada; Diferenças de códigos ou expressões: em campos que são codificados nos sistemas transacionais a fim de reduzir o espaço de armazenamento, agilizar e padronizar a entrada de dados, devemos ter atenção para que não sejam utilizados atributos para cidade como "RJ" para Rio de Janeiro e noutra base de dados fonte com o mesmo conteúdo "RJ" representando Roberto Justus. Se o sistema transacional fonte dos dados for o mesmo, muito dificilmente esta duplicidade poderia ocorrer; Diferenças de granularidade: é o caso de um campo que totalize as horas despendidas para realizar uma determinada tarefa, como reuniões realizadas num mês que pode ser confundido com outro campo que totalize
as horas gastas com reuniões numa semana, não sendo possível utilizar estes campos para realizar comparações ou totalizações sem as devidas conversões; Diferenças de abstração: no caso do campo de telefone ser armazenado com o DDD separado dos números normais em uma fonte enquanto que noutra fonte estarem estes números combinados num só campo. Normalmente as ações de correção das anomalias encontradas não se dá automaticamente com uma rotina específica, até porque isto poderia ter sido feito já na própria base transacional. O que se encontra em sistemas deste tipo são rotinas que listam estes dados para que uma pessoa responsável procure solucionar as pendências caso a caso, corrigindo inclusive a base original. O desenvolvimento de rotinas de limpeza e integração de dados a serem carregados em um DW requer uma série de cuidados e pode tornar-se bastante trabalhosa para técnicos especializados. Na maioria das vezes é preferível utilizar ferramentas que foram desenvolvidas para este fim. Neste ponto também pode ser interessante que a equipe de desenvolvimento do sistema transacional que serviu de fonte para o DW indique os pontos principais de possível ocorrência de distorções, agilizando o processo. Uma ferramenta interessante a ser desenvolvida é aquela que percorre as tuplas de uma tabela da base transacional e realiza a totalização de ocorrências de cada tipo de informação, como o atributo de sexo, por exemplo, onde poderiam ser encontradas. As ferramentas de data auditing servem para localizar e apresentar registros gravados onde os relacionamentos estejam deteriorados, ou seja, numa relação de muitos para um, por exemplo, podem existir diversas tuplas de uma tabela relacionadas a uma tupla que foi excluída em outra tabela, sendo que estas informações estariam "perdidas" na base de dados pela quebra da relação de paternidade. Caso existam tuplas de determinadas tabelas que representem uma mesma informação mas que estejam definidas com diferentes IDs, pode-se ter uma mesma cidade com duas siglas diferentes, por exemplo, Brasília com as siglas "BR" e "BSB". Isto levaria o sistema de extração a concluir que são cidades diferentes, porém o que ocorreu foi um cadastro duplicado e o ideal seria excluir uma das duas e migrar os relacionamentos da excluída para a que permaneceria no sistema. Outro tipo de redundância pode ser encontrado no caso de cadastros de clientes no sistema de aplicações e outro cadastro de devedores no sistema de empréstimos. A integração destas duas tabelas deve ser feita a fim de conferir uma maior consistência ao sistema de DW. 3. TRANSFORMAÇÃO DOS DADOS O processo de transformação de dados no DW ocorre, dentre outras situações, devido ao desenvolvimento de sistemas que não levaram em consideração o compartilhamento de processos e dados quando do surgimento dos sistemas legados. Uma vez que a origem dos dados podem ser de sistemas diferentes, às vezes é necessário padronizar os diferentes formatos. Por exemplo: em alguns sistemas a informação sobre o sexo do cliente pode estar armazenada no seguinte formato : "M" para Masculino e "F" para Feminino. Porém, em algum outro sistema pode estar armazenado como "H" para Masculino e "M" para Feminino e assim sucessivamente. Quando levamos esses dados para o DW, deve-se ter uma padronização deles, ou seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em formatos diferentes. Portanto, fazemos o processo de ETL, transformamos esses dados e deixamos num formato uniforme normalmente sugerido pelo próprio usuário. Outra situação de transformação de dados, bem comum, enfrentada pelo analista
responsável pela Aquisição de Dados do DW ao examinar um determinado campo de uma tabela, onde somente são permitidos os valores 1 ou 2, vir uma ocorrência com um valor 0 (zero) para o atributo. O módulo de transformação deverá mostrar que o padrão é o valor 1, neste caso, deverá ser substituído de maneira que as regras definidas no escopo do sistema sejam cumpridas; deve-se transformar estes dados a fim de que os mesmos obedeçam a um padrão que permitirá futuras comparações sem que haja a necessidade de executar operações de conversão durante a realização das consultas, o que possivelmente tornaria o processo de pesquisa extremamente lento e trabalhoso em alguns casos. 4. CARGA DOS DADOS O processo de carga do Data Warehouse é uma operação efetuada por processo de carga/inserção específicos de cada DBMS ou por processos independentes de carga rápida (Fastload) - é a tecnologia que consegue tempos de carga significativamente mais rápidos através do pré-processamento dos dados e de dispensa das operações de verificação de integridade dos dados e de registro das operações efetuadas. Esta tecnologia substitui uma função especifica de carga do DBMS. A carga dos dados será feita a partir de um sistema de banco de dados temporário, no qual os dados devem já ter passado por um processo de limpeza e integração (transformação). As tabelas que serão atualizadas no sistema de DW devem ser montadas utilizando-se agregações, sumarizações e ordenações dos dados. Caso estejamos trabalhando num ambiente distribuído e as tabelas construídas nos passos anteriores estejam em outro servidor que não seja o do DW devemos então fazer a migração destas tabelas para este último. Uma vez feita a migração das tabelas passamos então para a carga propriamente dita. Alguém poderia imaginar que, a fim de reduzir o tempo total do processo, seria interessante já realizar a carga durante a migração das tabelas entre os servidores. Esta operação não é recomendável uma vez que qualquer problema ocorrido durante a migração teria influências diretas no DW como um todo e tornaria a correção das falhas muito mais trabalhosa para o administrador do sistema. Após os dados serem carregados fisicamente no servidor, passamos então para a carga propriamente dita. Quando utilizamos ferramentas de bulk load oferecidos pelos SGBDs relacionais, a recuperação dos dados em caso de falha é perfeitamente possível a qualquer momento. Esta característica confere ao sistema a segurança necessária, uma vez que problemas podem ocorrer e a consistência do DW deve ser mantida. A velocidade de carga influencia de forma drástica na performance do sistema. Muitas vezes são excluídos os índices de ordenação das tabelas a fim de reduzir a quantidade de controles a serem monitorados pelo BD (Banco de Dados), reconstruindo-as posteriormente após a conclusão da carga. 4.1 Carregamento de Dados segundo Kimball Ralph Kimball sugere, em seu livro Data Warehouse toolkit (1998) que a equipe de projetistas do DW construa um sistema de extração de dados de produção, normalmente, leva-se de 3 a 5 meses para construção, que deve ser configurado de forma a minimizar o tempo de manutenção durante o carregamento. Um meio para fazer isso é espelhar o DW, conforme mostra a figura 1.
Embora o espelhamento esteja associado ao processamento de transações, no DW ela fornece um alto nível de segurança em casos de falha de uma unidade de disco. Adicionalmente, em muitos sistemas operacionais, a configuração espelhada executa praticamente todas as operações de disco cerca de 2 vezes mais rápido do que as configurações não espelhadas, isto acontece porque o sistema pode optar pelo espelho capaz de fornecer os dados primeiros durante a realização de uma consulta (geralmente as consultas são realizadas durante o dia). Essa capacidade está no nível inferior (na estrutura) do sistema operacional e dos sistema de arquivos e não faz parte do DBMS (Sistema Gerenciador de Banco de Dados) ou da lógica da aplicação. À noite, durante a carga de dados, o espelhamento é deliberadamente interrompido. Se a máquina do DBMS for um multiprocessador (tanto SMP - Multiprocessador Simétrico, quanto MMP - Processador Massivamente Paralelo), uma fração dos processadores poderá dar continuidade às consultas em um dos espelhos cujos dados permanecem inalterados, enquanto os outros processadores iniciam a carga dos dados que serão modificados. Isso permite que a máquina fique disponível para consulta praticamente 24 horas, além de possibilitar que um ciclo de carregamento extenso e complexo de dados e índices seja completado. Ao final da fase de carregamento, há uma verificação da qualidade dos dados do espelho que foi modificado. Se a qualidade dos dados for assegurada, o primeiro espelho será mantido off line para que seja realizada uma transferência de dados do tipo todo-disco-para-todo-disco. Mesmo em um sistema de grande porte, esse processo pode ser executado em menos de uma hora. Após a conclusão da transferência, o espelhamento é restabelecido e o sistema retorna para on line. Se não for possível garantir a qualidade dos dados, toda a transferência tododisco-para-todo-disco poderá ser feita no sentido inverso, restaurando dessa forma a configuração exata do dia anterior. Para o carregamento de tabelas muito grandes é necessário criar um índice de tabela de fatos segmentável. Como a maioria dos carregamentos noturnos (semanais ou mensais) anexa dados ao final de uma seqüência de tempo, será extremamente útil se pudermos dar um drop no índice mestre da tabela de fatos apenas para o período de tempo mais recentes, em vez de fazê-lo para a tabela toda. Isso permite que a carga dos períodos de tempo mais recentes seja executada com maior rapidez do que se o índice permanecer no local, e permite que a parte do índice em que foi dado um drop seja reconstruída rapidamente quando o carregamento estiver concluído. Vários dos sistemas gerenciadores de
banco de dados possuem índices segmentáveis. 5. ATUALIZAÇÃO DOS DADOS (REFRESH) A todo momento são realizadas alterações na base de dados transacional. Estas modificações, inclusões de novas tuplas, cadastros de novos dados, devem ser atualizados para o DW (Data Warehouse) a fim de que este esteja condizente com a atualidade das fontes de origem. Existem sistemas que são programados para detectar automaticamente a ocorrência de mudanças significativas nas fontes, tornando o processo de atualização ou refresh mais transparente para o usuário e também para o administrador do DW. Em muitos casos não existe esta característica nos sistemas transacionais. Podemos, então, adotar três alternativas na tentativa de detecção e extração destas modificações: a) Alterar a aplicação que gerencia a fonte de informação a fim de enviar notificações destas alterações para o DW. Isto somente é possível quando se tem o código-fonte dos sistemas e ainda quando se dispõe de tempo para realizar estas mudanças neste código; b) Analisar o arquivo de log do sistema procurando por modificações significativas. Isto existe no sistema Data Propagator da IBM. O problema desta solução reside no fato de que os administradores normalmente não aceitam fornecer permissões de acesso ao sistema uma vez que isto coloca em risco a segurança do mesmo; c) As modificações são detectadas através da comparação do dump corrente da fonte com um dump emitido anteriormente. À medida que os dados das fontes aumentam, o número de comparações deve aumentar, o que acaba por inviabilizar o processo. Em ambientes onde existem DMs (Data Marts) departamentais ou funcionais além do DW, tem-se a necessidade de definir uma política de entrega de novos dados a todos os bancos. Muitos projetos contemplam a utilização de um servidor de replicação na arquitetura de distribuição dos dados. Um Servidor de Replicação consiste numa aplicação sofisticada que seleciona e particiona dados para distribuição a cada um dos DMs, aplicando restrições de segurança, transmitindo uma cópia dos dados para os locais adequados e criando um log de todas as transmissões. A cada etapa final do processo de carga de produção diária a comunidade de usuários deve ser informada sobre a consistência da carga, a totalização da carga do dia anterior e as áreas a serem usadas ou evitadas. Isso deve tornar-se uma fonte de referência de rotina para os usuários. CONCLUSÃO A etapa de ETL é uma das mais críticas de um projeto de DW, pois uma informação carregada erroneamente trará conseqüências imprevisíveis nas fases posteriores. O objetivo desta fase é fazer a integração de informações de fontes múltiplas e complexas. A utilização de Ferramentas Back End adquiridas ou desenvolvidas, de acordo com a opção da empresa, agiliza os processos e minimizam os eventuais prejuízos advindos das experiências do tipo "tentativa e erro", além de reduzir o tempo de realização desta etapa do DW, que, geralmente, costuma ser subestimado pelos projetistas, variando entre 7 a 9 meses e, em alguns casos, até 1 ano. A complexidade de tarefas necessárias para se desenvolver um sistema de extração de dados e mantê-lo funcionando exige novas funções na área de
informática, tais como: Analista de extração - responsável pelas especificações funcionais e análise de requisito; Programador de extração - programa a extração dos dados de produção, identifica os registros modificados, atribui novas chaves e prepara imagens de registros de carga para a migração para o DW; Mediador de extração - avalia o extrato diário, define quais modificações de atributos de dimensão devem ser rastreadas com chaves de dimensão de modificação lenta e negocia com o pessoal da produção os prazos necessários para transmissão dos dados e para a modificação de alterações de dados e de formatos; Gerente da tabela de dimensão mestra - mantém as dimensões mestras corporativas, tais como: produto, cliente, campanhas, equipe de vendas e demais dimensões centrais ou administrativas semelhantes, cria e atribui chaves, incluindo a manipulação de chaves de dimensão de modificação lenta e chaves de agregados; Programador de garantia de qualidade de tabelas de dimensão - responsável pelo preenchimento de atributos textuais em tabelas de dimensão e pela correção dos erros e de pequenas variações; Gerente de monitoramento de agregados - monitora as estatísticas do navegador de agregados e constrói novos agregados e as divulga aos usuários do DW a fim de tornar as consultas anteriormente longas, cada vez mais rápidas; Gerente de garantia de qualidade de carga de dados - avalia o carregamento diário do DW, define se é adequado liberar nova carga de dados para os usuários e informar aos usuários sobre o status do data warehouse; Gerente de backup e recuperação do DW - responsável pelo cópia dos arquivos e pela recuperação da transação de cada dia contendo milhões de registros; Gerente de metadados do DW - fornece espaço e suporte a todos os tipos de metadados associados à carga de dados da produção, do navegador de agregados e das ferramentas de consulta (Front End) e geração de relatórios. Isto inclui tabelas de comparação para localizar registros modificados nos sistemas de produção, assim como o status da chave atual para permitir a formulação de novas chaves de dimensão.