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 idéias 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
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 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.
Nenhum comentário:
Postar um comentário