Data Warehouse

Prévia do material em texto

Data Warehouse 
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 pelaligaçã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 gerenciamentodeverá 
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 quesã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, tornandoo 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.