1. CONCEITO DE DATA WAREHOUSE
A definição de DW varia de autor para autor, indo desde a informação armazenada num banco de dados de suporte a decisão até o processo de modelagem, extração de dados operacionais e armazenamento num banco de dados DSS. No entanto, apesar dessa variação, existe um consenso com relação aos objetivos de se implementá-lo (isto é, prover aos usuários finais fácil acesso a dados íntegros e consistentes para tomadas de decisões nos negócios). O escopo dessa tomada de decisão pode ser tático, operacional, estratégico e mais amplo.
Sistemas de DW revitalizam os sistemas da empresa, pois:
. Permitem que sistemas mais antigos continuem em operação;
. Consolidam dados inconsistentes dos sistemas mais antigos em conjuntos coerentes;
. Extraem benefícios de novas informações oriundas das operações correntes;
. Provém ambiente para o planejamento e arquitetura de novos sistemas de cunho operacional.
Devemos considerar, no entanto, que um DW não contem apenas dados resumidos, podendo conter também dados primitivos. É desejável prover ao usuário a capacidade de aprofundar-se num determinado tópico, investigando níveis de agregação menores ou mesmo o data primitivo, permitindo também geração de novas agregações ou correlações com outras variáveis. Além dos mais, é extremamente difícil prever todos os possíveis dados resumidos que serão necessários. Limitar o conteúdo de um DW apenas a dados resumidos significa limitar os usuários apenas às consultas e análises que eles puderem antecipar frente a seus requisitos atuais, não deixando qualquer flexibilidade para novas necessidades.
O objetivo da tecnologia DW é de fornecer os subsídios necessários para a transformação de uma base de dados de uma organização, geralmente transacionais, on-line operacional e com um conjunto de dados relativamente recente (denominado banco de dados OL TP) para uma base de dados maior que não seja orientada ao ambiente operacional e que contenha o histórico de todos de interesse existentes na organização, denominado banco de dados OLAP e também conhecido como DW propriamente dito.
1.1. Características do Datawarehouse
Apresentamos a seguir as principais características da tecnologia DW que são: orientado por temas, integrado, variado no tempo e não volátil.
Orientado por temas: refere-se ao fato do DW armazenar informações sobre temas específicos importantes para o negocio da empresa. Exemplos típicos de temas são produtos, atividades, contas, clientes, etc. Em contrapartida, o ambiente operacional é organizado por aplicações funcionais. Por exemplo, em uma organização bancária, estas aplicações incluem empréstimos, investimentos e seguros.
A implementação de um tema pode corresponder a um conjunto de tabelas relacionadas. Por exemplo, considerando informações sobre vendas de funcionários, podem existir tabelas contento informações básicas dos funcionários (como código do funcionário, nome, endereço, sexo, data inicio, data fim, etc.), uma com dados do período 1948 a 1980, outra com dados para o período 1985-1990. Além destas, existem tabelas cumulativas intermediárias com as atividades dos funcionários entre 1980 e 1990, contendo registro resumo para as atividades de cada mês (contendo código do funcionário, mês, número de transações, média de vendas, total menor venda, total maior venda, total vendas canceladas, etc.), e, finalmente, encontram-se ainda tabelas detalhadas de atividades para os períodos 1987-1988 e 1989-1990 (incluindo código do funcionário, data atividade, numero da nota, numero pedido, quantia, cliente id, local, etc..).
Existem, portanto, para o mesmo tipo informação, diferentes níveis de detalhe e sumarização. Note-se que todas estas tabelas contêm um identificador comum, o código do funcionário, além de um elemento temporal como parte da chave de cada tabela. Nem sempre todas estas tabelas seriam mantidas em discos, sendo possível que, em alguns casos, as informações mais detalhadas das atividades dos vendedores fossem mantidas em fita magnética, ficando acessíveis apenas quando solicitadas.
Integrado: refere-se à consistência de nomes das unidades das variáveis, etc., no sentido de que os dados foram transformados até um estado uniforme. Por exemplo, considere-se sexo como um elemento de dado. Uma aplicação pode codificar sexo como M/F, outra como 1/0 e uma terceira como H/M. Conforme os dados são trazidos para o DW, eles são convertidos para um estado uniforme, ou seja, sexo e codificado apenas de uma forma. Da mesma maneira, se um elemento de dado é medido em centímetros em uma aplicação, em polegadas em outra, ele será convertido para uma representação única ao ser colocado no DW.
Variante no tempo: refere-se ao fato do dado em um DW referir-se a algum momento especifico, significando que ele não é atualizável, enquanto que o dado de produção é atualizado de acordo com mudanças de estado do objetivo em questão, refletindo, em geral, o estado do objeto no momento do acesso. Em um DW, a cada ocorrência de uma mudança, uma nova entrada é criada, para marcar esta mudança.
O tratamento de séries temporais apresenta características especificas, que adicionam complexidade ao ambiente do DW. Processamentos mensais ou anuais são simples, mas dias e messes oferecem dificuldades pelas variações encontradas nos números. Deve-se considerar que não apenas os dados têm umas características temporal, mas também os metadados, que incluem definições dos itens de dados, rotinas de validação, algoritmos de derivação, etc. Sem a manutenção do histórico dos metadados, as mudanças das regras de negócio que afetam os dados na DW são perdidas, invalidando dados históricos.
Não volátil: significa que o DW permite apenas a carga inicial dos dados e consultas a estes dados, o chamado ambiente ”load-and-access”. Após serem integrados e transformados, os dados são carregados em bloco para o DW, para que estejam disponíveis aos usuários para acesso. No ambiente operacional, ao contrario, os dados são, em geral, atualizados registro a registro, em múltiplas transações. Essa volatilidade requer um trabalho considerável para assegurar integridade e consistência através de atividades de rollback, recuperação de falhas, commits e bloqueios. Um DW não requer este grau de controle típico dos sistemas orientados a transações.
Nos últimos anos, o conceito de DW evoluiu rapidamente de um considerável conjunto de ideias relacionadas para uma arquitetura voltada para a extração de informação especializada e derivada a partir dos dados operacionais da empresa. O estudo de uma arquitetura descreve o ambiente de DW permitem compreender melhor a estrutura geral de armazenamento, integração, comunicação, processamento e apresentação dos dados que servirão para subsidiar o processo de tomada de decisão nas empresas.
1.2. Arquitetura Datawarehouse
1.2.1. Arquitetura Genérica
Uma arquitetura genérica proposta procura apenas sistematizar papéis no ambiente de DW, permitindo que as diferentes abordagens encontradas no mercado atualmente possam se enquadrar nesta descrição genérica. Estas estruturas estão divididas nas seguintes camadas:
· Camadas de Bancos de Dados Operacionais: corresponde aos dados das bases de dados operacionais da organização junto com dados provenientes de outras fontes externas que serão tratados para compor o DW.
· Camada de Acesso à Informação: é a camada com a qual os usuários finais interagem. Representa as ferramentas que o usuário utiliza no dia-a-dia, tal como Excel, SAS e outras. Também envolve o hardware e software utilizado para obtenção de relatórios, planilhas, gráficos e outros. A cada dia surgem sistemas mais sofisticados para manipulação, análise e apresentação dos dados, incluindo-se ferramentas de data-mining e visualização.
· Camada de Acesso aos Dados: esta camada é responsável pela ligação entre as ferramentas de acesso à informação e os dados operacionais. Esta camada comunica não só com diferentes SGBD’s e sistemas de arquivos de um mesmo ambiente como também, idealmente, com outras fontes sob diferentes protocolos de comunicação, no que se chama acesso universal de dados.
· Camada de Metadados (Dicionários de Dados): metadados são as informações sobre os dados mantidos pela empresa (descrições de registros em um programa COBOL, comandos CREATE do SQL, informação em um diagrama E-R e dados em um dicionário de dados são exemplos de metadados). Para poder manter a funcionalidade de um ambiente de DW é necessário ter disponível uma grande variedade de metadados. Dados sobre as visões dos usuários devem poder ter acesso aos dados de um DW sem que tenha que saber onde residem estes dados ou a forma como estão armazenados.
· Camada de Gerenciamento de Processo: a camada de gerenciamento de processo está envolvida com o controle das diversas tarefas a serem realizadas pelo responsável pelo gerenciamento dos processos que contribuem para manter o DW atualizado e consistente.
· Camada de Transporte ou Middleware: esta camada gerencia o transporte de informações pelo ambiente de redes. É usada para isolar aplicações, operacionais ou informacionais, do formato real dos dados nas duas extremidades. Também inclui a coleta de mensagens a transações e se encarrega de entregá-las em locais e tempos determinados.
· Camada do DW: o Datawarehouse propriamente dito corresponde aos dados usados para fins “informacionais”. Em alguns casos, DW é simplesmente uma visão lógica ou virtual dos dados, podendo de fato não envolver o armazenamento destes dados. Em um DW que exista fisicamente, cópias dos dados operacionais e externos são de fato armazenadas, de modo a prover fácil acesso e alta flexibilidade de manipulação.
· Camada de Gerenciamento de Replicação: Esta camada inclui todos os processos necessários para selecionar, editar, resumir, combinar e carregar o DW e as correspondentes informações de acesso a partir das bases operacionais e fontes externas. Normalmente isto envolve programação complexa, mas cada vez mais são disponibilizadas ferramentas para facilitar estes processos. Esta camada pode também envolver programas de análise da qualidade dos dados e filtros que identificam padrões nos dados operacionais.
1.2.2. Arquitetura de Dados
Em termos de ambiente físico de dados, o DW pode ser centralizado em um único local ou distribuído setorialmente. A primeira alternativa significa consolidar o banco de dados em um DW integrado. Esta abordagem procura maximizar o poder disponível.
Uma segunda abordagem, considerada uma arquitetura federativa, distribuindo a informação por função, com dados financeiros em um servidor, dados de marketing em outro local, e dados de manufatura em um terceiro lugar.
Em uma terceira abordagem, considera-se uma arquitetura de DW por camadas, armazenando dados altamente resumidos em um servidor, dados resumidos ao nível de detalhe intermediário em uma segundo servidor, e os dados mais detalhados (atômicos) em um terceiro servidor. O primeiro servidor atende a maior parte dos pedidos de dados, com um número menor pedidos passando para a camada 2 e de usuários com baixo volume de dados enquanto servidores nas outras camadas estão mais adequados para processar grandes volumes de dados, mas baixo número de usuários.
Esta terceira abordagem é bastante comum, sendo definida por diversos autores. É claro que, além das camadas do DW propriamente dito, tem-se a camada dos dados operacionais, de onde os dados atômicos são coletados. Estes dados atômicos, em geral, sofreram diversos processos de transformação para fins de integração, consistência e acuracidade e constituem o que chama de “operational data store (ods)”.
1.3. O Papel dos Metadados
Diferentes aplicações desenvolvidas em tempos diferentes no âmbito operacional da empresa, geralmente contém dados que são inconsistentes ou redundantes. A menos que sejam guiados pelos princípios de uma administração de dados efetiva, um DW não atingirá seu objetivo de integração dos dados. Os metadados constituem-se no principal recurso para a administração de dados e assumem maior importância ainda no ambiente de DW.
Metadados normalmente são definidos como “dados sobre os dados”. Talvez uma definição mais exata seja a de que metadado é uma abstração dos dados, ou ainda, dados de mais alto nível que descrevem dados de um nível inferior. Sem metadados, os dados não têm significado. São exemplos de metadados as descrições de registros em um programa de aplicação ou o esquema de um banco de dados descrito em seu catálogo ou ainda as informações contidas em um dicionário de dados.
Em um ambiente operacional, os metadados são especialmente valiosos para os desenvolvedores de aplicação e os administradores do banco de dados. Os bancos de dados operacionais são usualmente utilizados via aplicações que já contem as definições de dados embutidas. Seus usuários simplesmente interagem com as telas do sistema, sem precisar conhecer como os dados são mantidos pelo banco de dados.
O ambiente de suporte a decisão, por sua vez, é bastante distinto. Nele, analistas de dados e executivos procuram por fatos não usuais e correlações que serão reconhecidas quando encontradas. Aplicações rotineiras e pré-definidas não fazem sentido neste ambiente. Os usuários de um DW precisam examinar seus dados e para tal, conhecer sua estrutura e significado.
De um modo, existem três camadas de metadados em um Datawarehouse:
· Metadados operacionais (do nível das aplicações): definem a estrutura dos dados mantidos pelos bancos operacionais, usados palas aplicações de produção da empresa;
· Metadados centrais do DW: mantidos no catalogo do DW. Distinguem-se por serem orientados por assunto, definindo como os dados transformados devem ser interpretados. Incluem definições de agregados e campos calculados, assim como visões sobre cruzamentos de assuntos;
· Metadados do nível do usuário: mapeiam os metadados do DW para conceitos que sejam familiares e adequados aos usuários finais.
Como se vê, dados sobre desempenho e monitoramento também se qualificam como metadados. Os processos que monitoram o ambiente de uma DW (tais como extração, carga e uso) criam metadados que são usados para determinar como o sistema vem atuando em termos de desempenho. Da mesma forma, dados que identificam questões relativas a qualidade dos dados detectados durante os processos de extração e carga, devem também estar disponíveis para os usuários, para que estes possam julgar a acuracidade de suas análises.
1.4. Ciclo de vida do desenvolvimento em um DW
Pelo fato de que no Ciclo de desenvolvimento de sistemas clássicos, todos o requisitos são conhecidos, a sua implementação em um DW não pode ser efetivada, ou seja, o DW possui um ciclo próprio chamado de CLDS. Este ciclo caracteriza-se por começar pelos dados, procurando integrá-los e testá-los e após partir para a codificação dos programas de interface para os dados, sendo que somente nestas etapas os resultados são analisados pelos usuários e, finalmente, os requisitos dos sistemas são compreendidos.
2. FERRAMENTAS BACK END
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 projetistas 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;
* 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 têm 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 Datawarehouse;
5. Atualização (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, concebida há muito tempo, contendo muito lixo e inconsistências. 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 dos dados que estão 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 possam livrar os dados de problemas que, por algum motivo, passaram despercebidos nos sistemas de origem, tais como: códigos 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ão 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 ID’s, 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 pode 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 SGBD’s 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.
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 sistemas 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 todo-disco-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 sequê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 recente, 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 o momento são realizadas alterações na base de dados transacionais. 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 DM’s (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 DM’s, 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.
