Alguns Conceitos - FTP da PUC

Alguns Conceitos
Data Warehouse
Deter um enorme volume de dados na sua empresa não quer dizer nada. Você
precisa transformar dados brutos em informação.
OLAP
Analisar uma mesma informação de diferentes formas pode ajudar na tomada
exata de uma decisão. Ferramentas OLAP nos auxiliam nessa função.
Data Mining
Data Mining (ou mineração de dados) é o processo de extrair informação
válida, previamente desconhecida e de máxima abrangência a partir de
grandes bases de dados, usando-as para efetuar decisões cruciais.
Data Mart
Agregar a informacao por setores, além de melhorar a performace torna o
acesso mais simples para o usuario final. Os Data Marts nos auxiliam nisso.
Business Intelligence
Business Intelligence é um conjunto de conceitos e metodologias que,
fazendo uso de acontecimentos (fatos) e sistemas baseados nos mesmos,
apóia atomada de decisões em negócios.
Metadados
Sabemos que no Data Warehouse documentar tudo é vital para a
sobrevivência do projeto, pois o DW pode ser um projeto gigantesco e se
não houver uma documentação eficiente ninguém conseguirá entender nada.
Ferramentas de Back End
Por Eliane Martins de Sousa, pós-graduada em Sistemas de Informações Inteligentes pelo CRRM - Université AixMarseille 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.
2.
3.
4.
5.
Extração dos dados de fontes internas e externas;
Limpeza dos dados extraídos;
Transformação;
Carga no DW e,
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 todo-discopara-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.