Artigo

http://www.datawarehouse.inf.br/artigos.
asp
Alguns conceitos sobre DW

Por Fernando Vieira
O Data Warehouse (DW) é um conjunto de técnicas que aplicadas em conjunto

geram um sistema de dados que nos proporcionam informações para tomada de
decisões. Ele funciona tipicamente na arquitetura cliente/servidor. Todos os grandes
bancos de dados do mercado podem, em teoria, ser usados como gerenciadores do
DW. Contudo, é importante salientar duas características fundamentais para um SGBD
que vai comportar uma imensa quantidade de dados e que será acessado por uma
quantidade cada vez maior de usuários. São elas: Capacidade de compressão de dados
e otimização de performance de queries. Procure por essas qualidades quando for
escolher o seu SGBD. Os principais do mercado são: Oracle 8, Sybase IQ 12, DB2
(IBM), Informix e SQL Server 7.0.
O DW é um banco de dados físico que fica separado do sistema OLTP, feito numa
modelagem dimensional. Ele será alimentado pelos sistemas OLTP da empresa,
chamados de sistemas transacionais. Existe uma série de ferramentas que
automatizam esse processo, chamadas “ferramentas de extração, filtragem e carga
dos dados”. Como exemplo temos a Platinum, Prism e o Power Stage (Sybase).
Mas antes da implantação do DW necessariamente deverá ser aplicada uma
metodologia que levante os “objetos gerenciais”. A partir deste trabalho, parte-se para
a modelagem lógica/física, que deverá ser num esquema dimensional, de preferência o
star-schema.
Nesta etapa é importante a documentação através de ferramentas Case, como o
System Architect, o Erwin ou o Power Designer (módulo Warehouse Architect).
Para a visualização dos dados, existe uma classe específica de ferramentas,
comumente conhecidas como ferramentas OLAP. Há várias sub-classes como ROLAP
(Relational OLAP), DOLAP (Desktop OLAP), MOLAP ( Multidimensional OLAP) e HOLAP
(hybrid OLAP que vem a ser DOLAP OU ROLAP + MOLAP).
Uma breve descrição de cada uma:
• ROLAP – Neste caso a arquitetura se compõe de: SGBD + ferramenta ROLAP.

Aqui, a engine OLAP fica em um servidor dedicado, que armazena os vários
“cubos” de informação. O usuário acessa os vários cubos, e analisa as
informações com o processamento OLAP sendo realizado no servidor. Pode
trazer problemas de escalabilidade (o número crescente de usuários pode
derrubar o servidor) e de tráfego de rede. Por outro lado, permite análise de
grandes volumes de dados. Exemplos de ferramentas: DSS Agent
(Microestrategy), Power Dimension (Sybase).
• DOLAP – A arquitetura é composta de SGBD + ferramenta DOLAP. O
processamento OLAP acontece na máquina cliente, sem tráfego de rede nem
problemas de escalabilidade. Contudo, pode trazer problemas em alguns
relatórios, quando o volume de dados fica muito grande, apesar das boas
ferramentas tratarem os dados de maneira compactada. Exemplos: Business
Objects, Cognos, Brio e Oracle Discovery.
• MOLAP – Tem-se SGBD + servidor MOLAP. Neste caso, no SGBD ficam os dados
num formato simples, e no Servidor MOLAP, que é na verdade um banco de
dados multidimensional, ficam os dados consolidados. O usuário visualiza
diretamente o Servidor MOLAP, usando os módulos de consulta desta
ferramenta. Exemplos: Essbase (Hyperion), Metacube (Informix), Oracle
Express, e Plato (Microsoft). É uma arquitetura não muito “user friendly”, não
sendo muito aceita em seu formato puro.
http://www.datawarehouse.inf.br/artigos.asp
• HOLAP – Neste caso, junta-se uma ferramenta OLAP ao sistema MOLAP, sendo
que os usuários usam essa interface para fazer suas consultas. É um sistema
extremamente completo, contudo é o mais caros de todos, sendo que muitas
vezes a análise custo/benefício mostra a inviabilidade desta opção.
Apesar de outras ferramentas possibilitarem a visualização dos dados, como o Excel

ou o Access, as mesmas não apresentam nem performance adequada nem capacidade
de ver os dados multidimensionalmente, como Slice-and-Dice e Drill que são os
recursos mais importantes para analisar as informações.
Entenda as diferenças entre ferramentas OLAP para web

e não web
Por Ivã Cielo
Baseado no artigo escrito por Jonathan Wu a DM Review, em março de 2000
Diferenças entre aplicações Web e não Web

Durante os últimos anos temos acompanhado a evolução dos sistemas de Business
Intelligence (BI). Estas evoluções envolveram vários aspectos, entre eles, a facilidade
de uso, a alta capacidade de geração de SQL´s complexos, além de avançadas
ferramentas e recursos de administração. Com a alta disseminação da internet, os
usuários dos sistemas de BI, sentiram a necessidade de haver para web (thin client),
aquilo que eles já possuíam no seu desktop, nos sistemas client server (full client).
Citaremos as características de cada um desses sistemas mais abaixo, para podermos
entendê-los melhor.
Configuração e Arquitetura
Os aplicativos de BI, tem um impacto muito significativo nos sistemas de
informações das empresas. Entendendo como essas aplicações trabalham, e sua
arquitetura técnica, elas podem auxiliar os usuários a explorarem melhor a sua
ferramenta, e obterem melhores resultados.
Full Client, ou aplicações de BI não web
Uma aplicação full client, utiliza a arquitetura convencional de client-server. Nessa
configuração, o aplicativo de BI reside somente no cliente, isto é, no computador do
usuário final. Esse sistema também opera standalone e permite analisar e obter
resultados dos dados, sem estar necessariamente conectado na rede, pois o cubo de
dados está na máquina cliente. Isso exige um bom processador, bastante espaço em
disco, e muita memória RAM, para continuar rodando outras aplicações.
O sistema full client, faz uma interação com o servidor. Os dados são obtidos dele,
mas o sistema é quem faz os cálculos, sumarizações e também formatação dos dados
no relatório, sem precisar se reconectar ao servidor.
Características
Cliente Servidor
do sistema
1 – Sistema
Operacional
1 – Sistema
2 - Sistema
Operacional
Gerenciador de Banco
Software mínimo 2 – Aplicações de BI
de Dados Relacional
3 – Middleware para
(SGBDR)
conexão com o SGBD
conexão com o SGBD
Funções do 1 – A aplicação de BI 1 – O SGBDR analisa

sistema provê interface com as requisições feitas
os usuários pelos usuários
2 – A aplicação de BI 2 - O SGBDR recebe e
gera o SQL e processa as tarefas
submete ao servidor requisitadas
aquilo que o usuário 3 - O SGBDR e a
requisita
3 – A aplicação de BI,
tem habilidades para middleware, enviam o
formatar os resultado dos dados
resultados dos dados para o cliente
retornados do
servidor
Uma aplicação full client de BI, usa a arquitetura cliente/servidor. Nesta

configuração, o cliente faz uma parte e o servidor faz outra, completando em conjunto
a tarefa. O cliente contém a aplicação de BI e geram uma interface que habilitam os
usuários a interagirem, sozinhos com a aplicação. O servidor contém um gerenciador
de banco de dados relacional, dados e outros softwares pertinentes a ele. Vamos
descrever abaixo como são executados os passos, numa aplicação BI cliente/servidor:
1. O usuário ativa a aplicação de BI, onde é validado;

2. Usando a aplicação de BI, o usuário faz uma requisição:
A aplicação gera o SQL e envia ao servidor através de middleware, via rede. O
servidor recebe a requisição e repassa-a para o SGBD. Esse por sua vez,
analisa o SQL e o executa.
O resultado da pesquisa, é enviado de volta para o cliente, também através de

middleware e a conexão via rede.
A aplicação de BI recebe o resultado, e permite o usuário analisar, formatar e
sumarizar os dados para fazer a análise dos mesmos.
Thin client, ou aplicações de BI, baseadas na web
Uma aplicação thin client de BI utiliza a arquitetura client-server, mas requer

algumas configurações de hardware adicionais. Nessa configuração, o software reside
no servidor web e o cliente não é tão robusto como no full client. No quadro abaixo
vamos especificar melhor.
Características
Cliente Servidor
do sistema
1 – Sistema 1 – Sistema
Operacional Operacional
Software Mínimo 2 – Aplicação de BI 2 – SGBD
3 – Middleware para 3 – Middleware para
conexão com o SGBD conexão com o SGBD
Funções do 1 – A aplicação de BI 1 – O SGBD analisa a

sistema provê a interface com requisição do usuário
os usuários 2 – O SGBD processa
2 – Ela gera o SQL e a tarefa requisitada
envia a requisição 3 – O SGBD e o
para o servidor middleware envia o
3 – A aplicação de BI resultado dos dados
permite formatar os par ao cliente
dados que retornam

do servidor
Note que o software thin client, reside no web server, e o cliente junto com o
servidor é que completam a tarefa. O cliente contém somente um browser e habilita o
usuário a interagir com o web site do servidor, esse por sua vez, contém o software
para fazer a consulta e também a base de dados a ser consultada. Vamos dar um
exemplo de como se dá a interação entre o cliente e o servidor.
1. O usuário ativa o web browser;

2. O usuário acessa o site da aplicação de BI via web browser. Após estar
conectado, e com a senha validada, o web server disponibiliza a interface da
aplicação de BI;
3. O usuário faz a requisição e envia para o web server;
4. O servidor web recebe a requisição e por SQL, envia para o servidor de banco
de dados, através de middleware e conexão de rede;
5. O SGBD recebe a instrução, analisa o SQL e realiza a tarefa;
6. Feito isso, ele manda de volta somente o resultado dos dados para o cliente;
7. O software de BI residente no servidor, gera o resultado num relatório em
HTML;
8. O servidor web exibe o relatório para o cliente através do browser.
Benefícios para se usar full client e thin client
Vamos analisar agora as vantagens e desvantagens de cada uma dessas tecnologias.
Aplicação de BI Vantagens Desvantagens
1 – Os usuários dessa
tecnologia podem
analisar os
resultados, tanto
quando estiver
conectado na rede,
ou não. É ideal para 1 – Os custos de
usuários de hardware/software e
computadores upgrades nos
Full client
portáteis. softwares de BI, são
2 – Na maioria dos muito maiores do que
casos de utilização, a no thin client.
funcionalidade e a
robustez dessa
tecnologia tem um
desempenho muito
superior ao thin
client.
Thin client 1 – Os custos de 1 – Em certos casos, o

manutenção em full client tem maior
software/hardware e performance do que o
thin client.
os upgrades, são bem
2 – Os usuários não
inferiores que o full
conseguem utilizar a
client.
aplicação de BI para
2 – A utilização do
analisar os resultados
thin client é mais
sem estarem
simples que o full
conectados no web
client.
site.
Conclusão
Cada sistema tem a sua importância. Para algumas corporações, onde o número de
usuários dos sistemas de BI é pequeno, talvez seja mais interessante o sistema full
client, pois ele tem mais recursos, e possui uma flexibilidade maior. Mas se a empresa
possuir um grande número de usuários que precisam gerar consultas, remotamente
então o sistema de thin client se torna bem mais interessante, cabe aos gerentes de
informática analisarem e decidirem em qual perfil sua empresa se ajusta melhor.
Dimensão: Como ela funciona

Por Daniel Diniz
Dimensão: Sentido em que se manda a extensão para avalia-la.

Dimensionar: Calcular ou preestabelecer as dimensões ou proporções de algo.
Dimensional: Referente à dimensão.
A técnica antiga de se criar bancos de dados simples e compreensível foi
aperfeiçoada para o surgimento da modelagem dimensional. A capacidade de poder
observar um banco de dados no formato de um cubo, contendo duas, três, quatro ou
até mais dimensões, permite as pessoas que o utilizam, fatia-lo em qualquer uma de
suas dimensões.
Modelagem dimensional irá permitir ao usuário analisar seu negocio que qualquer
uma de suas dimensões, visões de negocio. Através desse tipo de modelagem será
possível para o usuário, ver um conjunto de dados de uma forma concreta e
compreensível, algo que era abstrato se torna real.
Algumas pessoas têm a facilidade para a perceber a visão do cubo outros possuem
alguma dificuldade, abaixo encontraremos algumas ilustrações a respeito dessa
modelagem para que fique mais claro como ela funciona.
Com as informações já modeladas um usuário irá fazer sua analise e pede algumas
informações, elas são trabalhadas das seguintes formas:
É feita a procura na coluna da tabela, as ocorrências do objeto pedido pelo usuário.
Depois de toda a varredura é apresentado ao usuário o seu pedido.
Ocorre também o seguinte:
Após a analise acima descrita, as informações obtidas serão cruzadas com as de
outras dimensões para uma consulta mais completa.
O quadro a seguir mostra como é feita a varredura de todas as informações nas
dimensões:
Ex.:
Ocorrências de produtos que são vendidos em caixa (será marcado em vermelho)
E poderá ver (em amarelo) os produtos que são vendidos em caixa..
Frutas Laranja Unidade

Caixa
Saco
Pêra Unidade
Caixa
Saco
Maçã Unidade
Caixa
Saco
Verduras Couve-Flor Unidade
Caixa
Saco
Alface Unidade
Caixa
Saco
Agrião Unidade
Caixa
Saco
Legumes Abóbora Unidade
Caixa
Saco
Chuchu Unidade
Caixa
Saco
Cenoura Unidade
Caixa
Saco
Busca se uma informação em que o período está compreendido no ano de 1999,

então só será capturada a informação referente ao pedido do usuário.
Pede a informação sobre um produto especifico, ex. Laranja. Da mesma forma serão
vasculhadas todas as informações sobre produtos e será capturada aquela que
somente indica o produto pedido.
E para finalizar essa consulta o usuário irá pedir a informação sobre seu cliente,
Supermercado Super Super, da mesma forma como nas anteriores será capturada
somente a informação pedida.
E através dessa condição do usuário, as informações são cruzadas entre si e

passadas para o usuário.
A modelagem dimensional proporciona um ganho de tempo na consulta, uma melhor

organização do sistema e principalmente a sua utilização se da de forma intuitiva para
o usuário.
Tabelas Dimensionais ou Faces de um Cubo

Por Daniel Diniz
As tabelas dimensionais são aquelas que irão guardar em sua maioria informações
textuais, as quais ajudam a definir um componente da dimensão do negocio.
Por exemplo, um componente (registro) da dimensão produto representa um
produto especifico com característica singular.
Tipo de
Chave Produto
Venda
01 Laranja Caixa
02 Laranja Saco
03 Maçã Unidade
04 Maçã Caixa
05 Maçã Saco
06 Morango Caixa
... ... ...
Cada registro representa um produto e todas as suas características.

OBS.: um registro não se repetirá as características podem sim se repetir, mas
estarão combinadas de forma que o registro como um todo não se repita. Não existe a
necessidades de criar formulas desenvolver regras para que isso ocorra, naturalmente
as definições irão se encaixar em suas devidas posições já que possui uma boa
modelagem.
Para prosseguirmos iremos diferenciar atributos e registros.
Atributos são os campos da tabela, colunas. São utilizados como fontes de
restrições, cabeçalho de linha. Seu conteúdo dentro da dimensão é de maior valor
sendo textual.
Chave Produto
01 Laranja
02 Laranja
03 Maçã
04 Maçã
05 Maçã
06 Morango
... ...
Cada coluna indica um atributo. Esse pode ser utilizado como restrição da seguinte
forma:
O usuário quer saber sobre um determinado produto (atributo) que é laranja.
Dessa forma na dimensão o atributo atua como restrição.
Registro em uma dimensão é a linha da tabela, ele é único não se repetirá, será
composto por um conjunto de atributos.
Ao trabalhar com a modelagem dimensional pode-se cair em uma armadilha,
Atributo de valor textual ou medição numérica?
O atributo textual irá indicar uma característica especifica, por exemplo, nome, tipo,
marca, peso, entre outros.
Pergunta – Peso é textual?

Será sim quando expressar uma característica singular de um produto.
Pergunta – Como saber?
Podemos analisar na maioria das ocasiões fazendo um questionamento. Se for uma
medição que varia continuamente ou se é padrão.
Caso varie será considerado um atributo para a tabela FATO, se não é para a
Dimensão.
Para a construção de uma tabela dimensional não existe regra definida, tamanho
limite, uma dica interessante é a seguinte:
Quando se construir uma Tabela Dimensional coloque nela o maior numero de
atributos possíveis, uma tabela com uma boa aparência possui cerca de 50 (cinqüenta)
colunas. Em alguns casos, sabemos que isso é muito difícil, mas teremos a consciência
de que iremos monta-la com o maior numero de informações possíveis, para que na
hora da analise não falte nenhum detalhe ou evite que no futuro estejamos presos
fazendo inserções e alterações.
O tamanho que essa tabela possuirá será irrelevante, pois ela não terá uma taxa de
crescimento, o que pode acontecer com essa tabela é uma mudança que será de forma
bem trabalhada (Slow Change Dimensions), e se dará em momentos de necessidade
onde dentro do projeto de Data Warehouse será sua manutenção, que já é planejada
desde o inicio.
Entenda as diferenças entre ferramentas OLAP para web

e não web
Por Ivã Cielo
Baseado no artigo escrito por Jonathan Wu a DM Review, em março de 2000
Diferenças entre aplicações Web e não Web

Durante os últimos anos temos acompanhado a evolução dos sistemas de Business
Intelligence (BI). Estas evoluções envolveram vários aspectos, entre eles, a facilidade
de uso, a alta capacidade de geração de SQL´s complexos, além de avançadas
ferramentas e recursos de administração. Com a alta disseminação da internet, os
usuários dos sistemas de BI, sentiram a necessidade de haver para web (thin client),
aquilo que eles já possuíam no seu desktop, nos sistemas client server (full client).
Citaremos as características de cada um desses sistemas mais abaixo, para podermos
entendê-los melhor.
Configuração e Arquitetura
Os aplicativos de BI, tem um impacto muito significativo nos sistemas de
informações das empresas. Entendendo como essas aplicações trabalham, e sua
arquitetura técnica, elas podem auxiliar os usuários a explorarem melhor a sua
ferramenta, e obterem melhores resultados.
Full Client, ou aplicações de BI não web
Uma aplicação full client, utiliza a arquitetura convencional de client-server. Nessa
configuração, o aplicativo de BI reside somente no cliente, isto é, no computador do
usuário final. Esse sistema também opera standalone e permite analisar e obter
resultados dos dados, sem estar necessariamente conectado na rede, pois o cubo de
dados está na máquina cliente. Isso exige um bom processador, bastante espaço em
disco, e muita memória RAM, para continuar rodando outras aplicações.
O sistema full client, faz uma interação com o servidor. Os dados são obtidos dele,
mas o sistema é quem faz os cálculos, sumarizações e também formatação dos dados
no relatório, sem precisar se reconectar ao servidor.
Características
Cliente Servidor
do sistema
1 – Sistema
Operacional
1 – Sistema
2 - Sistema
Operacional
Gerenciador de Banco
Software mínimo 2 – Aplicações de BI
de Dados Relacional
(SGBDR)
conexão com o SGBD
conexão com o SGBD
Funções do 1 – A aplicação de BI 1 – O SGBDR analisa

sistema provê interface com as requisições feitas
os usuários pelos usuários
2 – A aplicação de BI 2 - O SGBDR recebe e
gera o SQL e processa as tarefas
submete ao servidor requisitadas
aquilo que o usuário 3 - O SGBDR e a
requisita
3 – A aplicação de BI,
tem habilidades para middleware, enviam o
formatar os resultado dos dados
resultados dos dados para o cliente
retornados do
servidor
Uma aplicação full client de BI, usa a arquitetura cliente/servidor. Nesta

configuração, o cliente faz uma parte e o servidor faz outra, completando em conjunto
a tarefa. O cliente contém a aplicação de BI e geram uma interface que habilitam os
usuários a interagirem, sozinhos com a aplicação. O servidor contém um gerenciador
de banco de dados relacional, dados e outros softwares pertinentes a ele. Vamos
descrever abaixo como são executados os passos, numa aplicação BI cliente/servidor:
1. O usuário ativa a aplicação de BI, onde é validado;

2. Usando a aplicação de BI, o usuário faz uma requisição:
A aplicação gera o SQL e envia ao servidor através de middleware, via rede. O
servidor recebe a requisição e repassa-a para o SGBD. Esse por sua vez,
analisa o SQL e o executa.
O resultado da pesquisa, é enviado de volta para o cliente, também através de

middleware e a conexão via rede.
A aplicação de BI recebe o resultado, e permite o usuário analisar, formatar e
sumarizar os dados para fazer a análise dos mesmos.
Thin client, ou aplicações de BI, baseadas na web
Uma aplicação thin client de BI utiliza a arquitetura client-server, mas requer

algumas configurações de hardware adicionais. Nessa configuração, o software reside
no servidor web e o cliente não é tão robusto como no full client. No quadro abaixo
vamos especificar melhor.
Características
Cliente Servidor
do sistema
1 – Sistema 1 – Sistema
Operacional Operacional
Software Mínimo 2 – Aplicação de BI 2 – SGBD
3 – Middleware para 3 – Middleware para
conexão com o SGBD conexão com o SGBD
Funções do 1 – A aplicação de BI 1 – O SGBD analisa a

sistema provê a interface com requisição do usuário
os usuários 2 – O SGBD processa
2 – Ela gera o SQL e a tarefa requisitada
envia a requisição 3 – O SGBD e o
para o servidor middleware envia o
3 – A aplicação de BI resultado dos dados
permite formatar os par ao cliente
dados que retornam

do servidor
Note que o software thin client, reside no web server, e o cliente junto com o
servidor é que completam a tarefa. O cliente contém somente um browser e habilita o
usuário a interagir com o web site do servidor, esse por sua vez, contém o software
para fazer a consulta e também a base de dados a ser consultada. Vamos dar um
exemplo de como se dá a interação entre o cliente e o servidor.
1. O usuário ativa o web browser;

2. O usuário acessa o site da aplicação de BI via web browser. Após estar
conectado, e com a senha validada, o web server disponibiliza a interface da
aplicação de BI;
3. O usuário faz a requisição e envia para o web server;
4. O servidor web recebe a requisição e por SQL, envia para o servidor de banco
de dados, através de middleware e conexão de rede;
5. O SGBD recebe a instrução, analisa o SQL e realiza a tarefa;
6. Feito isso, ele manda de volta somente o resultado dos dados para o cliente;
7. O software de BI residente no servidor, gera o resultado num relatório em
HTML;
8. O servidor web exibe o relatório para o cliente através do browser.
Benefícios para se usar full client e thin client
Vamos analisar agora as vantagens e desvantagens de cada uma dessas tecnologias.
Aplicação de BI Vantagens Desvantagens
1 – Os usuários dessa
tecnologia podem
analisar os
resultados, tanto
quando estiver
conectado na rede,
ou não. É ideal para 1 – Os custos de
usuários de hardware/software e
computadores upgrades nos
Full client
portáteis. softwares de BI, são
2 – Na maioria dos muito maiores do que
casos de utilização, a no thin client.
funcionalidade e a
robustez dessa
tecnologia tem um
desempenho muito
superior ao thin
client.
Thin client 1 – Os custos de 1 – Em certos casos, o

manutenção em full client tem maior
software/hardware e performance do que o
thin client.
os upgrades, são bem
2 – Os usuários não
inferiores que o full
conseguem utilizar a
client.
aplicação de BI para
2 – A utilização do
analisar os resultados
thin client é mais
sem estarem
simples que o full
conectados no web
client.
site.
Conclusão
Cada sistema tem a sua importância. Para algumas corporações, onde o número de
usuários dos sistemas de BI é pequeno, talvez seja mais interessante o sistema full
client, pois ele tem mais recursos, e possui uma flexibilidade maior. Mas se a empresa
possuir um grande número de usuários que precisam gerar consultas, remotamente
então o sistema de thin client se torna bem mais interessante, cabe aos gerentes de
informática analisarem e decidirem em qual perfil sua empresa se ajusta melhor.
EIS - Executive Information System

Por Ivã Cielo
Os EIS(Executive Information Systems) - Sistemas de Informações Executivas - são

sistemas desenvolvidos para atender as necessidades dos executivos de uma empresa,
de obterem informações gerenciais de uma maneira simples e rápida. Ele é concebido
conforme o nível de conhecimento, entendimento e compreensão de informática dos
diretores.
Através do EIS o executivo obtém de forma simples e rápida as informações
gerenciais para ele tomar suas decisões sem depender exclusivamente do corpo
técnico, ou da área de informática. O intuito desse sistema é facilitar a vida deles.
Geralmente de interface gráfica, com simples operação, e basicamente com os
resultados de pesquisas mostrados através de gráficos e não em tabelas como a
maioria dos outros sistemas.
Devido a falta de tempo desses usuários especiais, o EIS deve ser modelado para ser
bastante user friendly e as informações serem acessadas, de preferência, com poucos
cliques. Outra característica importante é que elas devam ser trazidas bastante
resumidas e em alto nível de agregação pois, as decisões tomadas nesse nível
administrativo, não se atém em detalhes e sim no todo, como por exemplo. O diretor
de uma grande empresa não vai querer saber quantas canetas foram usadas na
empresa durante um ano, mas sim o valor total das despesas de material de
expediente.
O EIS pode ser construindo utilizando como base vários sistemas transacionais,
porém torna-se inviável devido ao grande volume de trabalho que isso proporciona,
pois extrair dados de diversas fontes, tratá-los, manter a integridade e manter o
histórico dos mesmos, torna o trabalho inviável. Porém se fizermos o EIS para
acessarmos um Data Warehouse a tarefa do fica muito mais fácil, pois facilita a busca
dos dados de um único sistema, onde as informações já se encontram de acordo com
as necessidades dos executivos e a tarefa de extração, transformação e carga, ficam
por conta dos técnicos do Data Warehouse e ele fica por conta somente da análise.
Características
As principais características destes sistemas são:
• Ter como propósito atender às necessidades de informações dos executivos de

alto nível. Como acompanhamento e controle de informações a nível estratégico
da empresa;
• Podem ser customizadas de acordo com estilo de cada executivo;
• Contêm recursos gráficos de alta qualidade para que as informações possam
ser apresentadas graficamente de várias formas;
• São fáceis de usar, para que o executivo possa operá-los com muito pouco
treinamento;
• Proporcionam acesso rápido e fácil a informações detalhadas, ou seja, as
informações são visualizadas em níveis que podem ser expandidos.
Vantagens Gerenciais
O EIS além de facilitar o trabalho, com um ambiente fácil e simples, ele também
pode permitir que o usuário altere o nível de detalhamento das informações com a
ajuda de uma ferramenta OLAP. Com o uso integrado desta ferramenta o executivo
poderá transformar as informações que se encontram em forma de tabelas para
gráficos ou vice-versa, como também poderá executar um Drill-Down ou um Drill-Up
para detalhar ou resumir o grau de granularidade da informação.
Vamos a um exemplo. Em um relatório estão contidas todas as informações das
vendas no ano de 1999 de todas as concessionárias do RS, porém o executivo quer
analisar estas informações, também, para cada cidade deste estado. O que ele deverá
fazer? Neste caso, havendo a integração com o OLAP, o usuário poderá executar um
Drill-Down no estado do Rio Grande do Sul, que automaticamente irão aparecer as
informações para cada cidade deste estado.
Por fim, o EIS permite que o usuário faça análise de tendências e comparações entre
diversas informações de forma prática e rápida, sem necessitar de um apoio da área
de informática para conseguir atingir o seu objetivo, isso o torna mais competitivo,
organizado e independente, que é tudo o que eles querem.
ETL - Extração, Transformação e Carga de Dados

Por Ivã Cielo
Esta etapa é uma das fases mais criticas de um Data Warehouse, pois envolve a fase
de movimentação dos dados. A mesma se dá basicamente em três passos, extração,
transformação e carga dos dados, esses são os mais trabalhosos, complexos e também
muito detalhados, embora tenhamos várias ferramentas (falaremos mais abaixo) que
nos auxiliam na execução desse trabalho.
O primeiro passo a ser tomado no processo de ETL é simplesmente a definição das
fontes de dados e fazer a extração deles. As origens deles podem ser várias e também
em diferentes formatos, onde poderemos encontrar desde os sistemas transacionais
das empresas até planilhas, flat files (arquivos textos) , dados que vem do grande
porte e também arquivos do tipo DBF, do antigo Clipper ou Dbase.
Definidas as fontes, partimos para o segundo passo que consiste em transformar e
limpar esses dados. Mas o que afinal de contas o que é isso?
Bem vamos descrever de uma forma bem simples. Quando obtemos os dados de
uma fonte, que na maioria das vezes é desconhecida nossa, e foi concebida ha muito
tempo atrás, os mesmos possuem muito lixo e há muita inconsistência. Por exemplo.
Quando um vendedor de linhas telefônicas for executar uma venda, ou inscrição, ele
está preocupado em vender, e não na qualidade dos dados que está inserindo na base,
então se por acaso o cliente não tiver o número do CPF a mão, ele cadastra um
número qualquer, desde que o sistema aceite, um dos mais utilizados é o 999999999-
99. Agora imagine um diretor de uma companhia telefônica consultar o seu Data
Warehouse (DW) para ver quais são os seus maiores clientes, e aparecer em primeiro
lugar o cliente que tem o CPF 999999999-99 ? Seria no mínimo estranho. Por isso,
nessa fase do DW, fazemos a limpeza desses dados, para haver compatibilidade entre
eles.
Além da limpeza, temos de fazer na maioria das vezes uma transformação, pois os
dados provêm de vários sistemas, e por isso, geralmente uma mesma informação tem
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 está guardado 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, então quando fazemos o
processo de ETL, transformamos esses dados e deixamos num formato uniforme
sugerido pelo próprio usuário. No DW, teremos somente M e F, fato esse que facilitará
a análise dos dados que serão recuperados pela ferramenta OLAP.
A seguir são apresentados alguns dos fatores que devem ser analisados antes de
começar a fase de extração dos dados:
• A extração de dados do ambiente operacional para o ambiente de data

warehouse demanda uma mudança na tecnologia. Os dados são transferidos de
bancos de dados hierárquicos, tal como o adabas, ou de bases do grande porte,
como o DB2, para uma nova tecnologia de SGBD para Data Warehouse, tal
como o IQ da Sybase, Red Brick da Informix, Essbase ou o DB2 para DW;
• A seleção de dados do ambiente operacional pode ser muito complexa, pois
muitas vezes é necessário selecionar vários campos de um sistema transacional
para compor um único campo no data warehouse;
• Outro fator que deve ser levado em conta é que dificilmente há o modelo de
dados dos sistemas antigos, e se existem não estão documentados;
• Os dados são reformatados. Por exemplo: um campo data do sistema
operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do
tipo ano e mês como AAAA/MM;
• Quando há vários arquivos de entrada, a escolha das chaves deve ser feita
antes que os arquivos sejam intercalados. Isso significa que se diferentes
estruturas de chaves são usados nos diferentes arquivos de entrada, então
deve-se optar por apenas uma dessas estruturas;
• Os arquivos devem ser gerados obedecendo a mesma ordem das colunas
estipuladas no ambiente de data warehouse;
• Podem haver vários resultados. Dados podem ser produzidos em diferentes
níveis de resumo pelo mesmo programa de criação do data warehouse;
• Valores default devem ser fornecidos. As vezes pode existir um campo no data
warehouse que não possui fonte de dados, então a solução é definir um valor
padrão para estes campos.
O data warehouse espelha as informações históricas necessárias, enquanto o

ambiente operacional focaliza as informações pontuais correntes.
A parte de carga dos dados também possui uma enorme complexidade, e os
seguintes fatores devem ser levados em conta:
• A parte de Integridade dos dados. No momento da carga é necessário checar os

campos que são chaves estrangeiras com suas respectivas tabelas para
certificar-se de que os dados existentes na tabela da chave estrangeira estão de
acordo com a tabela da chave primária;
• Se a tabela deve receber uma carga incremental ou a carga por cima dos
dados. A carga incremental normalmente é feita para tabelas fatos e a carga
por cima dos dados é feita em tabelas dimensões onde o analista terá que
deletar os dados existentes e incluí-los novamente. Mas em alguns casos
poderá acontecer que as tabelas de dimensões tem de manter o histórico,
então o mesmo deverá ser mantido;
• Apesar de existirem ferramentas de ETL como o DTS (Data Transformation
Service), Data Stage, ETI, Acta e Sagent, ainda tem-se a necessidade de criar
rotinas de carga para atender determinadas situações que poderão ocorrer.
As ferramentas de ETL mais utilizadas no mercado são o Data Stage da Ardent,

agora adquirido pela Informix, o ETI da IBM, Sagent da própria Sagent, Informática
Power Conect da Informatica e o DTS da Microsoft. Todos tem os seus diferenciais e
cada um poderá ser utilizado dependendo do caso de cada empresa. Algumas
ferramentas tem a curva de aprendizado mais suave, outras um pouco mais íngrime,
mas em certos casos mesmo sendo uma ferramenta de difícil aprendizado exigindo
maiores investimentos em pessoal, serão compensados com a performance e
flexibilidade da mesma. Há outras ferramentas que tem custo zero de aquisição pois,
vem embutida junto com um SGBD (Sistema Gerenciador de Banco de Dados), mas
em contrapartida são bastante limitadas no tocante a extração de dados e exigem uma
maior codificação dos processos de ETL, em relação as outras.
O que vale dizer é que uma ferramenta de ETL tem grande valia, principalmente se
os sistemas OLTP (transacionais) são muitos, pois elas são uma poderosa fonte de
geração de metadados, e que contribuirão muito para a produtividade da sua equipe,
porém deve-se tomar muito cuidado ao escolhe-la. Seja minucioso, teste o máximo de
ferramentas que puder e veja qual é a mais adequada ao seu caso, pois elas exigem
um alto investimento, tanto em capacitação, quanto na própria aquisição. Em alguns

casos é interessante o auxílio de profissionais externos para a escolha. O fato
verdadeiro é que os benefícios serão bastante vistosos e a produtividade aumentará
consideravelmente.
Kimball x Inmon
por Susan Gallas
adaptado por Ana Carolina Trevisan
Um grande número de profissionais de data warehouse questionaram as diferentes

abordagens ao data warehousing ensinadas por Bill Inmon e Ralph Kimball. Guerras
religiosas eclodiram entre os devotos seguidores de cada um. À medida em que a
indústria amadureceu, as duas filosofias foram se tornando muito mais próximas.
Entretanto, a linguagem utilizada para descrever sua metodologia conduz a questões
de compatibilidade.
Na verdade, suas abordagens são bastante compatíveis. É apenas uma questão de
como Kimball e Inmon nomeiam suas estruturas. Os dois experts concordam que o
sucesso de warehouses/marts depende efetivamente de reunir primeiramente as
necessidades do negócio. Estas necessidades orientam o design do mart que por sua
vez, orienta os dados necessários no warehouse. A teoria big bang de construção do
warehouse baseada nos sistemas operacionais tem provado consumir excessivamente
tempo e recursos com retorno limitado para os negócios.
Ambos os experts concordam que a validação negócio-usuário do design do data
mart assegura que as expectativas sejam administradas. Uma vez que isto tiver
ocorrido, o analista de dados pesquisa o(s) sistema(s) de origem mais apropriado(s) e
obtém o modelo (ou projeta o seu próprio se aquele não existir). Este modelo é o
ponto de partida para o projeto da área de armazenagem (staging area ou
warehouse). Kimball chama isso de quarto dos fundos (backroom) e Inmon chama isso
de warehouse. Este é o local onde as regras de integridade referenciais são aplicadas
(via DBMS ou validação do software) e onde transformação de diferentes valores é
realizada. Outras regras de negócios são aplicadas aos dados para se alcançar um
formato consistente e valores derivados.
Dependendo das necessidades da dimensão que se alteram lentamente, a entidade
será definida de maneira diferente.
• Tipo I: Apenas sobrescreva;

• Tipo II: Nós precisamos da versão e das datas;
• Tipo III: Adicione cópias antigas e novas de certos campos importantes.
Chaves substitutas também são geradas aqui. Isto é necessário para dimensões
correspondentes. Tanto Kimball quanto Inmon recomendam a extração de uma única
origem de uma só vez. Alguns consultores de warehouse podem ter interpretado a
abordagem de Kimball como sendo de extrair diversas vezes da mesma origem mas eu
não acho que esta foi sua intenção. Isto tudo é feito na área de staging.
Uma vez que os dados foram carregados para a área de staging, o próximo processo
é carregar os data marts. Todas as partes concordam que a estrutura de negócios mais
adequada é o star schema. Para o tratamento dos dados, estes precisam permanecer
na terceira forma normal de maneira que os relacionamentos ocultos sejam
descobertos. O star schema oculta aqueles devido à extensiva desnormalização. O star
schema lembra bem uma planilha do Excel juntamente com a utilização da tabela pivô.
Esta é a melhor estrutura de layers de apresentação.
Em relação ao ODS, a definição de Inmon é um quadro atual, volátil e integrado dos
negócios. Esta é uma estrutura útil para o marketing one-to-one e relacionamento com
o consumidor, além de outras áreas onde apenas as transações mais recentes são
importantes para o processo operacional do negócio. Kimball descreve o ODS como
uma estrutura para armazenar dados de transações detalhados incluindo a história,

que é uma reação a dados não detalhados no warehouse. Minha impressão é a de que
se o datawarehouse for
projetado inicialmente para conter apenas dados levemente sumarizados e
transações não detalhadas, isto foi devido aos recursos limitados do computador e do
fato de que a maioria dos usuários de negócios não precisam daquelas informações
detalhadas para sua análise.
Como o potencial, a velocidade e a capacidade de armazenamento dos
computadores aumentou, a história dos detalhes transacionais encontra-se no
warehouse onde os usuários podem acessar aquele nível de detalhes caso seja
necessário.
O que eu tenho feito é fundir as duas filosofias para chegar aos princípios do melhor
design para os projetos nos quais eu tenho trabalhado. Kimball é um expert quando o
assunto é compreender e documentar o desenho do star schema e trabalhar com os
usuários de negócios. Ele criou o conceito de dimensões de relatório que se alteram
lentamente - como é versus como era - e resolveu cada
problema técnico que já foi apresentado a ele além daqueles que ele descobriu por si
mesmo. Sua força reside na implementação, e eu o considero o expert do "quarto da
frente" (front room).
Inmon foi pioneiro no conceito do data warehouse e do suporte a
decisões. Eu acredito em sua especialização no design do warehouse, tratamento de
dados e ciclo de informações de loop fechado. Como "praticantes" (1) de warehouse,
nosso maior interesse não é entender as complexidades e diferenças sutis das duas
abordagens e sim, aplicar os aspectos de cada uma que se adaptem ao problema que
nós estamos tentando resolver. Inmon e Kimball forneceram-nos uma metodologia
estruturada para resolver os problemas de negócios e cabe a nós aplicar com bom
senso estes princípios.
Ferramentas de Back End

Por Eliane Martins de Sousa, pós-graduada em Sistemas de Informações Inteligentes pelo CRRM - Université Aix-
Marseille III, (Fr) e Analista de Sistemas da Caixa Econômica Federal
As ferramentas de back end são as responsáveis pelo processo de extração, limpeza,

carga e restauração dos dados utilizados num sistema de Data Warehouse (DW). Essa
etapa é também denominada de ETL - Extração, Limpeza, Transformação e Carga dos
Dados.
Embora tenhamos hoje em dia ferramentas que auxiliam na execução do trabalho,
ainda assim é um processo trabalhoso, complexo e também muito detalhado. As
ferramentas de extração de dados são caras, deve-se adquirir, se for o caso, após a
definição dos requisitos de extração e transformação.
Se a equipe de projetista do DW optar por desenvolver um software, o sistema de
gerenciamento deverá executar, pelo menos, 11 processos ou a maior parte deles,
para que seja possível extrair os dados de um banco de dados de produção e enviá-los
para o DW. O conjunto desses processos é chamado, por Ralph Kimball, de Sistema de
Extração de Dados de Produção - SEDP, os processos são:
• Extração primária;
• Identificação dos registros modificados;
• Generalização de chaves para dimensões em modificações;
• Transformação em imagens de registro de carga;
• Migração do sistema legado para o sistema DDW;
• Classificação e construção de agregados;
• Generalização de chaves para agregados;
• Carregamento;
• Processamento de exceções;
• Garantia de qualidade e,
• Publicação.
Apesar de existirem ferramentas de ETL como o Data Stage (Ardent/Informix), o

DTS (Microsoft) e o Sagent (da própria Sagent), às vezes é necessário criar rotinas de
carga para atender determinadas situações que poderão ocorrer. Todos tem os seus
diferenciais e cada um poderá ser utilizado dependendo do caso de cada empresa. O
mais importante é que uma ferramenta de ETL tem grande valia, principalmente se os
sistemas fontes (Legado, OLTP e/ou transacionais) que alimentarão o DW forem
muitos, uma vez que essas ferramentas são uma poderosa fonte de geração de
metadados e contribuirão muito para a produtividade da equipe.
Podemos citar cinco operações principais realizadas pelas ferramentas back end:
1. Extração dos dados de fontes internas e externas;

2. Limpeza dos dados extraídos;
3. Transformação;
4. Carga no DW e,
5. Atualizações (refresh).
1. EXTRAÇÃO DE DADOS
A extração de dados de fontes externas geralmente é feita através de gateways e

interfaces padrão do tipo ODBC (padrão para acesso a banco de dados do SQL Access
Group Consortium adotado pela Microsoft) ou outras, com diversos produtos já
existentes no mercado.
Para os dados de produção mantidos em um sistema de banco de dados relacional
orientado para transação, várias ferramentas e aplicações utilizando SQL extraem os
dados para um arquivo ou envia-os (um registro por vez) para um aplicativo de
solicitação. Entretanto, se os dados de produção estiverem armazenados em um
sistema proprietário, tal como o pacote de entrada de pedidos de cartões de crédito de
um fornecedor, o formato dos arquivos talvez não seja de conhecimento público,
impossibilitando, às vezes, a leitura direta dos dados, para contornar o problema é
necessário gerar um relatório ou criar um arquivo para descarregar os dados do
sistema de produção.
A catalogação dos sistemas de produção que alimentam o DW é recomendável para
identificação precisa da extração primária dos dados.
2. LIMPEZA DOS DADOS
De uma maneira geral, podemos dizer que o processo de limpeza e transformação

dos dados que serão carregados num sistema de DW serve para corrigir algumas
imperfeições contidas na base de dados transacional, a fim de fornecer ao usuário do
sistema analítico dados concisos e com uma qualidade que permita uma tomada de
decisão baseada em valores mais próximos dos reais.
Idealmente, poderíamos imaginar que os dados deveriam apenas ser convertidos
para padronização de medidas, porém sabe-se que podem existir valores incorretos
numa base de dados transacional, os quais não podem ser propagados, principalmente
no momento em que serão analisados estes dados, muitas vezes comparativamente.
Além disso a limpeza é necessária porque os dados normalmente advém de uma
fonte muitas vezes desconhecida nossa, concebida há muito tempo, contendo muito
lixo e inconsistência. Por exemplo: se a empresa for de cartão de crédito, o vendedor
está mais preocupado em vender o produto (cartão) do que na qualidade de dados que
está inserindo. Se o cliente não tiver o número do RG na hora da venda, o vendedor
cadastrará um número qualquer para agilizar a venda. Se for feita uma consulta
posterior, levando-se em conta o número do RG dos clientes, no mínimo informações
estranhas aparecerão (algo como RG número 99999999-99).
Por isso, nessa fase do DW, faz-se a limpeza desses dados, para haver
compatibilidade entre eles. O processo de limpeza não estará completo sem que se
possa livrar os dados de problemas que, por algum motivo, passaram despercebidos
nos sistemas de origem, tais como: código inválidos e preenchimento de vários
campos com valores incompatíveis entre si. A própria modelagem do sistema OLTP
pode conter "pontos fracos" que permitam, por assim dizer, a existência de dados
inconsistentes, os quais podem e devem ser filtrados antes da carga no DW, podemos
encontrar bases de dados com os seguintes problemas:
• Diferenças de unidades: podemos ter campos de idade dos clientes em anos ou

em meses, sendo necessário converter todas as medidas para qualquer uma
das duas (ou todas em anos, ou todas em meses);
• Diferenças de precisão: alguns valores de preços de produtos podem estar
representados com duas casas decimais em uma tabela e com quatro casas
decimais em outra tabela, cabendo ao administrador do DW definir qual a
precisão desejada;
• Diferenças de códigos ou expressões: em campos que são codificados nos
sistemas transacionais a fim de reduzir o espaço de armazenamento, agilizar e
padronizar a entrada de dados, devemos ter atenção para que não sejam
utilizados atributos para cidade como "RJ" para Rio de Janeiro e noutra base de
dados fonte com o mesmo conteúdo "RJ" representando Roberto Justus. Se o
sistema transacional fonte dos dados for o mesmo, muito dificilmente esta
duplicidade poderia ocorrer;
• Diferenças de granularidade: é o caso de um campo que totalize as horas
despendidas para realizar uma determinada tarefa, como reuniões realizadas
num mês que pode ser confundido com outro campo que totalize as horas
gastas com reuniões numa semana, não sendo possível utilizar estes campos
para realizar comparações ou totalizações sem as devidas conversões;
• Diferenças de abstração: no caso do campo de telefone ser armazenado com o
DDD separado dos números normais em uma fonte enquanto que noutra fonte
estarem estes números combinados num só campo.
Normalmente as ações de correção das anomalias encontradas não se dá

automaticamente com uma rotina específica, até porque isto poderia ter sido feito já
na própria base transacional. O que se encontra em sistemas deste tipo são rotinas
que listam estes dados para que uma pessoa responsável procure solucionar as
pendências caso a caso, corrigindo inclusive a base original.
O desenvolvimento de rotinas de limpeza e integração de dados a serem carregados
em um DW requer uma série de cuidados e pode tornar-se bastante trabalhosa para
técnicos especializados. Na maioria das vezes é preferível utilizar ferramentas que
foram desenvolvidas para este fim. Neste ponto também pode ser interessante que a
equipe de desenvolvimento do sistema transacional que serviu de fonte para o DW
indique os pontos principais de possível ocorrência de distorções, agilizando o
processo.
Uma ferramenta interessante a ser desenvolvida é aquela que percorre as tuplas de
uma tabela da base transacional e realiza a totalização de ocorrências de cada tipo de
informação, como o atributo de sexo, por exemplo, onde poderiam ser encontradas.
As ferramentas de data auditing servem para localizar e apresentar registros
gravados onde os relacionamentos estejam deteriorados, ou seja, numa relação de
muitos para um, por exemplo, podem existir diversas tuplas de uma tabela
relacionadas a uma tupla que foi excluída em outra tabela, sendo que estas
informações estariam "perdidas" na base de dados pela quebra da relação de
paternidade.
Caso existam tuplas de determinadas tabelas que representem uma mesma
informação mas que estejam definidas com diferentes IDs, pode-se ter uma mesma
cidade com duas siglas diferentes, por exemplo, Brasília com as siglas "BR" e "BSB".
Isto levaria o sistema de extração a concluir que são cidades diferentes, porém o que
ocorreu foi um cadastro duplicado e o ideal seria excluir uma das duas e migrar os
relacionamentos da excluída para a que permaneceria no sistema.
Outro tipo de redundância pode ser encontrado no caso de cadastros de clientes no
sistema de aplicações e outro cadastro de devedores no sistema de empréstimos. A
integração destas duas tabelas deve ser feita a fim de conferir uma maior consistência
ao sistema de DW.
3. TRANSFORMAÇÃO DOS DADOS
O processo de transformação de dados no DW ocorre, dentre outras situações,

devido ao desenvolvimento de sistemas que não levaram em consideração o
compartilhamento de processos e dados quando do surgimento dos sistemas legados.
Uma vez que a origem dos dados podem ser de sistemas diferentes, às vezes é
necessário padronizar os diferentes formatos. Por exemplo: em alguns sistemas a
informação sobre o sexo do cliente pode estar armazenada no seguinte formato : "M"
para Masculino e "F" para Feminino. Porém, em algum outro sistema pode estar
armazenado como "H" para Masculino e "M" para Feminino e assim sucessivamente.
Quando levamos esses dados para o DW, deve-se ter uma padronização deles, ou
seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em
formatos diferentes. Portanto, fazemos o processo de ETL, transformamos esses dados
e deixamos num formato uniforme normalmente sugerido pelo próprio usuário.
Outra situação de transformação de dados, bem comum, enfrentada pelo analista
responsável pela Aquisição de Dados do DW ao examinar um determinado campo de
uma tabela, onde somente são permitidos os valores 1 ou 2, vir uma ocorrência com
um valor 0 (zero) para o atributo. O módulo de transformação deverá mostrar que o
padrão é o valor 1, neste caso, deverá ser substituído de maneira que as regras
definidas no escopo do sistema sejam cumpridas; deve-se transformar estes dados a
fim de que os mesmos obedeçam a um padrão que permitirá futuras comparações sem
que haja a necessidade de executar operações de conversão durante a realização das
consultas, o que possivelmente tornaria o processo de pesquisa extremamente lento e
trabalhoso em alguns casos.
4. CARGA DOS DADOS
O processo de carga do Data Warehouse é uma operação efetuada por processo de

carga/inserção específicos de cada DBMS ou por processos independentes de carga
rápida (Fastload) - é a tecnologia que consegue tempos de carga significativamente
mais rápidos através do pré-processamento dos dados e de dispensa das operações de
verificação de integridade dos dados e de registro das operações efetuadas. Esta
tecnologia substitui uma função especifica de carga do DBMS.
A carga dos dados será feita a partir de um sistema de banco de dados temporário,
no qual os dados devem já ter passado por um processo de limpeza e integração
(transformação). As tabelas que serão atualizadas no sistema de DW devem ser
montadas utilizando-se agregações, sumarizações e ordenações dos dados.
Caso estejamos trabalhando num ambiente distribuído e as tabelas construídas nos
passos anteriores estejam em outro servidor que não seja o do DW devemos então
fazer a migração destas tabelas para este último. Uma vez feita a migração das
tabelas passamos então para a carga propriamente dita.
Alguém poderia imaginar que, a fim de reduzir o tempo total do processo, seria
interessante já realizar a carga durante a migração das tabelas entre os servidores.
Esta operação não é recomendável uma vez que qualquer problema ocorrido durante a
migração teria influências diretas no DW como um todo e tornaria a correção das
falhas muito mais trabalhosa para o administrador do sistema.
Após os dados serem carregados fisicamente no servidor, passamos então para a
carga propriamente dita. Quando utilizamos ferramentas de bulk load oferecidos pelos
SGBDs relacionais, a recuperação dos dados em caso de falha é perfeitamente possível
a qualquer momento. Esta característica confere ao sistema a segurança necessária,
uma vez que problemas podem ocorrer e a consistência do DW deve ser mantida.
A velocidade de carga influencia de forma drástica na performance do sistema. Muitas
vezes são excluídos os índices de ordenação das tabelas a fim de reduzir a quantidade
de controles a serem monitorados pelo BD (Banco de Dados), reconstruindo-as
posteriormente após a conclusão da carga.
4.1 Carregamento de Dados segundo Kimball

Ralph Kimball sugere, em seu livro Data Warehouse toolkit (1998) que a equipe de
projetistas do DW construa um sistema de extração de dados de produção,
normalmente, leva-se de 3 a 5 meses para construção, que deve ser configurado de
forma a minimizar o tempo de manutenção durante o carregamento. Um meio para
fazer isso é espelhar o DW, conforme mostra a figura 1.
Embora o espelhamento esteja associado ao processamento de transações, no DW

ela fornece um alto nível de segurança em casos de falha de uma unidade de disco.
Adicionalmente, em muitos sistemas operacionais, a configuração espelhada executa
praticamente todas as operações de disco cerca de 2 vezes mais rápido do que as
configurações não espelhadas, isto acontece porque o sistema pode optar pelo espelho
capaz de fornecer os dados primeiros durante a realização de uma consulta
(geralmente as consultas são realizadas durante o dia). Essa capacidade está no nível
inferior (na estrutura) do sistema operacional e dos sistema de arquivos e não faz
parte do DBMS (Sistema Gerenciador de Banco de Dados) ou da lógica da aplicação.
À noite, durante a carga de dados, o espelhamento é deliberadamente interrompido.
Se a máquina do DBMS for um multiprocessador (tanto SMP - Multiprocessador
Simétrico, quanto MMP - Processador Massivamente Paralelo), uma fração dos
processadores poderá dar continuidade às consultas em um dos espelhos cujos dados
permanecem inalterados, enquanto os outros processadores iniciam a carga dos dados
que serão modificados. Isso permite que a máquina fique disponível para consulta
praticamente 24 horas, além de possibilitar que um ciclo de carregamento extenso e
complexo de dados e índices seja completado.
Ao final da fase de carregamento, há uma verificação da qualidade dos dados do
espelho que foi modificado. Se a qualidade dos dados for assegurada, o primeiro
espelho será mantido off line para que seja realizada uma transferência de dados do
tipo todo-disco-para-todo-disco. Mesmo em um sistema de grande porte, esse
processo pode ser executado em menos de uma hora. Após a conclusão da
transferência, o espelhamento é restabelecido e o sistema retorna para on line.
Se não for possível garantir a qualidade dos dados, toda a transferência 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 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.

Artigo

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Artigo

Enviado por

Direitos autorais:

Formatos disponíveis

http://www.datawarehouse.inf.br/artigos.

Alguns conceitos sobre DW

O Data Warehouse (DW) é um conjunto de técnicas que aplicadas em conjunto

• ROLAP – Neste caso a arquitetura se compõe de: SGBD + ferramenta ROLAP.

Apesar de outras ferramentas possibilitarem a visualização dos dados, como o Excel

Entenda as diferenças entre ferramentas OLAP para web

Diferenças entre aplicações Web e não Web

Funções do 1 – A aplicação de BI 1 – O SGBDR analisa

Uma aplicação full client de BI, usa a arquitetura cliente/servidor. Nesta

1. O usuário ativa a aplicação de BI, onde é validado;

O resultado da pesquisa, é enviado de volta para o cliente, também através de

Thin client, ou aplicações de BI, baseadas na web

Uma aplicação thin client de BI utiliza a arquitetura client-server, mas requer

Funções do 1 – A aplicação de BI 1 – O SGBD analisa a

dados que retornam

1. O usuário ativa o web browser;

Benefícios para se usar full client e thin client

Vamos analisar agora as vantagens e desvantagens de cada uma dessas tecnologias.

Aplicação de BI Vantagens Desvantagens

Thin client 1 – Os custos de 1 – Em certos casos, o

Dimensão: Como ela funciona

Dimensão: Sentido em que se manda a extensão para avalia-la.

Frutas Laranja Unidade

Busca se uma informação em que o período está compreendido no ano de 1999,

E através dessa condição do usuário, as informações são cruzadas entre si e

A modelagem dimensional proporciona um ganho de tempo na consulta, uma melhor

Tabelas Dimensionais ou Faces de um Cubo

Cada registro representa um produto e todas as suas características.

Pergunta – Peso é textual?

Entenda as diferenças entre ferramentas OLAP para web

Diferenças entre aplicações Web e não Web

Funções do 1 – A aplicação de BI 1 – O SGBDR analisa

Uma aplicação full client de BI, usa a arquitetura cliente/servidor. Nesta

1. O usuário ativa a aplicação de BI, onde é validado;

O resultado da pesquisa, é enviado de volta para o cliente, também através de

Thin client, ou aplicações de BI, baseadas na web

Uma aplicação thin client de BI utiliza a arquitetura client-server, mas requer

Funções do 1 – A aplicação de BI 1 – O SGBD analisa a

dados que retornam

1. O usuário ativa o web browser;

Benefícios para se usar full client e thin client

Vamos analisar agora as vantagens e desvantagens de cada uma dessas tecnologias.

Aplicação de BI Vantagens Desvantagens

Thin client 1 – Os custos de 1 – Em certos casos, o

EIS - Executive Information System

Os EIS(Executive Information Systems) - Sistemas de Informações Executivas - são

As principais características destes sistemas são:

• Ter como propósito atender às necessidades de informações dos executivos de

ETL - Extração, Transformação e Carga de Dados

• A extração de dados do ambiente operacional para o ambiente de data

O data warehouse espelha as informações históricas necessárias, enquanto o

• A parte de Integridade dos dados. No momento da carga é necessário checar os

As ferramentas de ETL mais utilizadas no mercado são o Data Stage da Ardent,

um alto investimento, tanto em capacitação, quanto na própria aquisição. Em alguns

Um grande número de profissionais de data warehouse questionaram as diferentes

• Tipo I: Apenas sobrescreva;

uma estrutura para armazenar dados de transações detalhados incluindo a história,

Ferramentas de Back End

As ferramentas de back end são as responsáveis pelo processo de extração, limpeza,

Apesar de existirem ferramentas de ETL como o Data Stage (Ardent/Informix), o

1. Extração dos dados de fontes internas e externas;

A extração de dados de fontes externas geralmente é feita através de gateways e

2. LIMPEZA DOS DADOS

De uma maneira geral, podemos dizer que o processo de limpeza e transformação