Data Warehouse - Da Modelagem a Implantação

AUTOR:
CAMILO MUSSI

Introdução
O contexto em que se vive atualmente demanda das organizações uma
capacidade de analisar, planejar e reagir rápida para poder acompanhar ou superar as
exigências dos clientes e à ameaça da concorrência. Para que isto aconteça, é
necessário que a organização tenha disponível, quando necessário, as informações
que constituem a base para obtenção de vantagens competitivas e maior fidelidade dos
clientes.
A todo o momento uma grande quantidade de informações sobre os mais
variados aspectos dos negócios da empresa é gerada e armazenada, passando a fazer
parte da base de conhecimento. Entretanto, esses dados estão espalhados por vários
sistemas de difícil integração, sem qualidade e indisponíveis para os gerentes e altos
executivos que são os tomadores de decisões estratégicas das organizações. Para
suprir essa deficiência surgiu o Data Warehouse (DW), que se constitui de um conjunto
de arquiteturas e/ou sistemas de informação orientados a assunto que existem em
plataformas segregadas do ambiente transacional, manipulando grande volume de
dados, principalmente históricos, e dão origem a consultas (read-only) invariavelmente
não previsíveis, que tem por objetivo dar suporte a esses processos.
O objetivo desse tutorial é apresentar os principais conceitos e questões
envolvidas com este tecnologia, procurando enfatizar a importância de sua utilização
para garantir agilidade e segurança na tomada de decisão, definido o caminho a ser
desenvolvido desde a modelagem até a implantação de um DW.
Histórico
O universo dos sistemas de informação é historicamente imaturo, existe apenas
desde a década de 1960, a prova disto é a tendência desses sistemas de
concentrarem-se nos detalhes. O DW surge num contexto de evolução dos processos
de tomada de decisão das empresas, que pode ser mais bem observado segundo uma
perspectiva global.
O processamento dos Sistemas de Apoio à Decisão (SAD) está em evolução,
mas suas origens remontam aos primórdios dos computadores.
Em meados da década de 60, começou a proliferação dos arquivos mestres e
fitas magnéticas causando um tremendo problema: a redundância dos dados e a difícil
manutenção e desenvolvimento dos programas, além da complexidade do hardware.
Para solucionar esses problemas surgiu uma nova tecnologia de armazenamento
e acesso a dados por volta de 1970, o armazenamento em disco ou Dispositivo de
Armazenamento de Acesso Direto (DASD). Nesse novo dispositivo os dados eram
acessados de forma direta, ou seja, para acessar o registro “n + 1” não era preciso
passar pelos registros 1,2,...,n. O tempo de acesso passou a ser medido em
milissegundos, solucionando o problema de tempo das fitas magnéticas.
Com o DASD surgiu um software conhecido como Sistema Gerenciador de Banco
de Dados (SGBD), que gerencia o armazenamento, acesso e indexação dos dados no
DASD, além de outras funcionalidades. Com o SGBD e o DASD surgiu uma solução

1
tecnológica para os arquivos mestres, resolvendo os problemas de tempo de acesso,
redundância de dados e etc. Essas novas tecnologias abriram o caminho para o
processamento de transações online de alta performance e o surgimento de sistemas
bancários, de controle de reservas, controle de produção e outros.
Na década de 80 surgiram os computadores pessoais e as linguagens de quarta
geração, que transformaram os usuários em sujeitos ativos, já que agora eles
passaram a controlar os sistemas e os dados. Com essa nova tecnologia, surgiu a
possibilidade de se utilizar os dados para outros objetivos além do processamento on-
line de alta performance. Os Sistemas de Informações Gerenciais (SIG) passaram a
ser viáveis, surgindo então o paradigma de um único banco de dados para apoiar o
processamento transacional e o processamento analítico.
Após o advento das transações on-line de alta performance surgiram os
programas de extração, que usando alguns critérios de seleção transportavam os
dados para um novo arquivo ou banco de dados. Com isto conseguia-se uma melhora
na performance das análises coletivas dos mesmos, pois o processamento não estaria
concorrendo com as transações on-line e, além disso, a posse dos dados passou para
as mãos dos usuários. Por esses motivos, tornou-se comum o uso dos programas de
extração e, conseqüentemente, o advento de alguns problemas como a falta de
credibilidade dos dados, problemas de produtividade e a impossibilidade de transformar
os dados em informações. Esse novo ambiente desorganizado não atendia às
necessidades do futuro e por isso se fizeram necessárias algumas mudanças de
arquitetura, surgindo o ambiente projetado de DW.
No cerne de um ambiente projetado de DW está a percepção da existência de
dois tipos de dados [4]:
• Dados primitivos – utilizados pelos sistemas operacionais das empresas.
Podem ser atualizados e refere-se a um presente momento. Atendem as
atividades funcionais;
• Dados derivados – dados resumidos ou calculados para atender às
necessidades da empresa. Não podem ser atualizados e são históricos.
Atendem as atividades gerenciais.
Como pode ser visto, existe uma grande diferença entre os dados primitivos
(dados operacionais) e os dados derivados (dados gerenciais) e, portanto, eles não
devem coexistir num mesmo banco de dados.
Num ambiente projetado de uma empresa existem quatro níveis [4]:
1. Operacional – contém os dados primitivos e atendem ao processamento on-line
de alta performance;
2. Atômico ou DW – contém dados primitivos não atualizados e dados derivados;
3. Departamental – contém informações úteis aos diversos departamentos da
empresa. A fonte de todos esses dados é o DW. Há um banco de marketing, um
de contabilidade e assim por diante, às vezes denominado Datamart;
4. Individual – geralmente dados temporários e de pequenas proporções e são
utilizados para analises heurísticas.
A primeira vista, pode-se concluir que existe uma grande redundância de dados
neste ambiente mas essa afirmação não é verdadeira. No nível operacional existem
apenas registros com valores atuais, no de DW existem dados históricos e, no
Departamental, existem registros dos departamentos específicos da empresa.

2
 Com isso chega-se ao ambiente que será estudado a seguir.
Ambiente de DW
Existem, nas empresas, dois tipos de sistemas:
• Sistemas operacionais (On-line Transaction Processing - OLTP): sistemas
que dão suporte ao dia a dia do negócio da empresa, que mantém a
empresa em funcionamento e são chamados de sistemas de produção e
• Sistemas informacionais (On-line Analitycal Processing - OLAP): sistemas
que dão suporte aos processos decisórios da empresa, que irão dar
subsídios para as decisões estratégias da empresa e compreendem os SADs
e os SIGs.
Como os dados informacionais exigem uma quantidade significativa e variada de
recursos, devem estar num ambiente de banco de dados separado dos dados
operacionais.
Alguns motivos que levam a essa separação:
• O DW engloba dados de vários sistemas OLTP e
• As estruturas básicas de dados de um DW são diferentes do sistema OLTP.
A grande vantagem de separar esses dados é que, como eles satisfazem a
objetivos diferentes, eles poderão se concentrar no que fazem, oferecendo melhor
desempenho e funcionalidade.
Conceito de DW
Segundo W. H. Inmon [4], um DW é uma coleção de dados orientada por
assuntos, integrada, variante no tempo e não volátil, que tem por objetivo dar suporte
aos processos de tomada de decisão.
Os dados dos sistemas operacionais irão constituir a base de carga do DW.
Esses dados, após sofrerem um processo de transformação, irão ser associados a um
novo ponto no eixo do tempo e armazenados no DW. Contudo, um DW irá exigir mais
recursos do que os vistos anteriormente e, portanto, serão incluídas também
informações vindas de várias outras fontes internas (planilhas eletrônicas, documentos
textuais, etc.) bem como fontes externas (jornais, revistas etc.)
Características
1. Orientado por Assunto
Refere-se ao fato de que os dados estaão organizados de acordo com os
assuntos de interesse da empresa, como por exemplo: produto, cliente, loja. Em
contrapartida, os dados dos sistemas operacionais estão organizados de acordo com a
funcionalidade da empresa, como por exemplo, no caso de uma escola: aluno,
servidor, matrícula.
Esses assuntos serão armazenados em um conjunto de tabelas relacionadas. É
importante enfatizar que, não necessariamente, todas essas tabelas devem estar com
o mesmo nível de resumo ou no mesmo dispositivo de armazenamento.
2. Integrado
Refere-se ao fato de que todo dado, trazido dos sistemas operacionais para o
ambiente de DW é, anteriormente, consolidado, de forma que passe a ter um único
significado. Como exemplo, considere o atributo “sexo” que, em uma aplicação é

3
tratado como “m/f”, em outra como “1/0”, outra como “x/y” e outra como
“masculino/feminino”. Para ser transportado para o DW, o dado tem que ser codificado
de uma única forma.
3. Variante no Tempo
Refere-se ao fato de que as estruturas de dados no DW sempre contêm um
atributo de tempo, ou seja, a cada mudança ocorrida num dado, uma nova entrada é
criada e não atualizada, como acontece nos sistemas operacionais.
É importante salientar a complexidade do ambiente de DW, pois pode possuir
não somente resumos anuais e mensais como também diários e semanais. Sabe-se
que o número de dias e o início de uma semana diferem de um mês para o outro e de
um ano para o outro. Além disso, os metadados também devem acompanhar essa
variação no tempo, pois um determinado dado pode ter um significado numa época e
outro em uma época diferente.
4. Não Volátil
Refere-se ao fato de que, em um DW, os dados não sofrem atualizações. Eles
são carregados uma única vez e, a partir desse momento, só podem ser consultados.
Ao contrário do que acontece nos sistemas operacionais onde existem milhões de
transações de atualizações ocorrendo a todo instante. Por isso esses sistemas têm de
possuir um grande número de controles para que não ocorra nenhuma inconsistência
devido a uma transação interrompida indevidamente.
OLTP X OLAP
Existem grandes diferenças entre os dois ambientes que, a seguir, serão
definidas, mostrando o benefício que a implantação do DW pode trazer para o
ambiente operacional.
1. Integração dos dados
Os dados no ambiente operacional não estão integrados, cada sistema possui
uma definição própria. Para migrá-los para o DW deve existir uma integração prévia,
porque se os dados chegarem em um estado não integrado, não poderão ser utilizados
para obter uma visão corporativa. Com isso consolidam-se dados inconsistentes dos
sistemas mais antigos em conjuntos coerentes.
2. Atualização dos dados
Não há sobreposição entre os registros existentes no ambiente operacional e no
de DW. Caso ocorra uma mudança, um novo registro é inserido no DW, associando ao
mesmo um elemento de tempo. Com isso os dados históricos não precisam mais ser
guardado no ambiente operacional. A remoção de grandes volumes de dados traz
algumas facilidades para o ambiente de produção como: correção, reestruturação,
monitoração e indexação, deixando o ambiente mais maleável.
3. Ciclo de vida do desenvolvimento
O ciclo de vida do DW começa pelos dados. Caso esses dados estejam sob
controle, eles são integrados e testados para verificar distorções. Então, é feita a
codificação do programa. Os resultados dos programas são analisados e, finalmente,
os requisitos do sistema são compreendidos.
4. Organização dos dados (modelo de dados)
Enquanto no ambiente operacional, os dados são modelados segundo a técnica
denominada Modelagem Entidade/Relacionamento, que busca remover qualquer

4
redundância dos dados para obter um melhor desempenho da transação, no ambiente
de DW os dados são modelados segundo a técnica da Modelagem Multidimensional,
que busca obter um maior desempenho nas consultas e atender às necessidades de
simplicidade do usuário.
5. Tempo de resposta
A noção de tempo de resposta nos dois ambientes é bem diferente. Enquanto no
OLTP, o tempo de resposta é um fator crítico, ou seja, está diretamente ligado aos
negócios, no ambiente de DW é mais atenuado, podendo ser medido em minutos,
horas ou dias. No entanto isso não quer dizer que ele não seja importante, o tempo de
resposta está diretamente ligado à produtividade, então quanto menor mais resultados
serão alcançados.
6. Uma máquina ou duas
Como o DW exige uma quantidade significativa e variada de recursos,
geralmente é implementado em uma máquina separada do sistema OLTP. A palavra
recurso, de um modo geral, é um motivo suficiente para requerer uma segunda
máquina, mas existem outros dois motivos importantes. Primeiro, o DW é um recurso
centralizado que integra dados de vários sistemas OLTP. Neste caso, por definição, a
máquina do DW é separada. Segundo, as estruturas básicas de dados do DW são
completamente diferentes daquelas do sistema OLTP. Como os dados devem ser
copiados e reestruturados para o DW, praticamente não há razão para mantê-los na
máquina do original OLTP. [6]
7. Metadados
São normalmente definidos como “dados sobre dados”. Talvez uma definição
mais exata seja a de que metadado é uma abstração dos dados, ou ainda, dados de
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 de banco de dados. Os bancos de
dados operacionais são usualmente utilizados via aplicação, que já contém 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
conhecidas quando encontradas. Aplicações rotineiras e predefinidas 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 geral existem três camadas de metadados em um DW:
• Operacionais (do nível das aplicações) – definem a estrutura dos dados
mantidos pelos bancos operacionais, usados pelas aplicações de produção da
empresa;
• Centrais do DW – mantidos no catálogo do DW. Distingue-se por serem
orientados por assunto, definindo como os dados transformados devem ser
interpretados. Incluem definições de agregados e campos calculados, assim
como as visões sobre cruzamentos de assuntos;

5
 • Nível do usuário – mapeiam os metadados do DW para conceitos que sejam
familiares e adequados aos usuários finais.
Projetando um DW
Os DW de sucesso não são como os sistemas operacionais que possuem fases
de desenvolvimento e manutenção bem distintas. Eles são entidades dinâmicas que
mudam de acordo com as necessidades de negócio da organização, caracterizando-se
assim por uma abordagem de desenvolvimento evolucionária. Além do seu dinamismo,
os custos de implementação e o impacto nos sistemas operacionais também justificam
essa abordagem.
Muitas empresas iniciam o processo por um departamento que tenha carência
de informação e cujo trabalho seja relevante para a organização, criando os chamados
datamarts , para depois ir acrescentando aos poucos. Outra opção é disponibilizar um
protótipo de DW, escolher alguns usuários e deixar que eles experimentem essas
pequenas amostras. Após a concordância do grupo, carregar os dados dos sistemas
operacionais e dados externos.
De qualquer forma, Inmon [4] salienta que é um erro pensar que técnicas de
projeto que servem para sistemas convencionais serão adequadas para a construção
de um DW. Os requisitos para um DW não são conhecidos até que ele esteja
parcialmente carregado ou já em uso.
Outra questão importante, discutida por Kimball [6], é a adequação do modelo
entidade-relacionamento ao tipo de transação OLTP. O principal objetivo da
modelagem, neste caso, é eliminar ao máximo, a redundância, de tal forma que uma
transação que promova mudanças no estado do banco de dados, atue o mais
pontualmente possível. Com isso, nas metodologias de projeto usuais, os dados são
fragmentados por diversas tabelas, o que traz uma considerável complexidade à
formulação de uma consulta por um usuário final. Por isso, esta abordagem não parece
ser a mais adequada para o projeto de um DW, onde estruturas mais simples, com
menor grau de normalização devem ser buscadas.
Não existe ainda no mercado uma metodologia de desenvolvimento de DW
consolidada, o que se vê são propostas de construção do modelo dimensional a partir
dos modelos corporativos ou departamentais de forma incremental. Segundo Inmon [4],
um DW é construído de forma heurística, confirmando a abordagem evolucionária
descrita anteriormente.
De qualquer forma, a metodologia a ser adotada é ainda bastante dependente
da abordagem escolhida, em termos de ambiente, distribuição, etc.. A seguir, serão
apresentadas etapas sugeridas para desenvolvimento de um projeto de DW.
Entrevistando os usuários finais
Deve-se começar pelas entrevistas com os usuários finais para saber quais
informações importantes são necessárias para serem consultadas e analisadas.
Segundo Kimball [6], as entrevistas com os usuários finais têm duas finalidades.
Primeiro, oferecem ao projetista uma visão concreta das necessidades e expectativas
da comunidade de usuários. As entrevistas criam uma conexão entre as equipes de
projetistas do DW e do negócio. Entender o negócio é a “moeda de ouro” da equipe de
projetistas. Essas entrevistas são essenciais ao sucesso do projeto.
A segunda finalidade das entrevistas permite aos projetistas aumentar o nível de
conscientização dos usuários finais quanto à implantação do DW, assim como adequar

6
suas expectativas. Entrevistar o usuário final é sem dúvida uma faca de dois gumes. A
equipe de projetistas deve estar preparada para dar continuidade ao projeto logo após
o término das entrevistas, porque o DW estará nas mentes dos usuários.
O processo de entrevista deve alternar entre grupos de usuários finais e
Administradores de Banco de Dados (DBAs) de sistemas legados. À medida que os
usuários finais levantam os tópicos importantes, surgem as questões sobre qual a
capacidade dos dados disponíveis de suportar tais tópicos.
As entrevistas ideais consistem em sessões de uma hora, em que dois ou três
projetistas da equipe reúnem-se com um gerente de área e alguns de seus
subordinados. As reuniões com muitos participantes de cada departamento são uma
perda de tempo. Uma hora de reunião será mais que suficiente para a equipe de DW
obter informações iniciais e geralmente é oportuno absorver as principais necessidades
do usuário antes de prosseguir com as entrevistas.
Em uma organização de grande porte, é aconselhável realizar uma ou duas
entrevistas com cada segmento, mesmo que alguns deles não sejam prioritários para o
DW. Será especialmente importante incluir tanto o segmento matriz como o filial nas
entrevistas principais, além das áreas igualmente importantes. Será melhor não
entrevistar todas as equipes de uma determinada área em seqüência, isto é, todas as
equipes de marketing, seguidas de todas as equipes de produção e de todas as de
vendas. À medida que as entrevistas progridem, os projetistas adquirem maior
entendimento do negócio e pode ser útil retornar a um tópico do início do processo, nas
últimas entrevistas. O conteúdo das entrevistas finais não deve acrescentar nada de
extraordinário às informações coletadas, comprovando dessa forma que todos os
aspectos importantes do negócio foram abordados. Caso surjam informações
totalmente novas nas etapas finais do processo de entrevistas, então devemos
suspeitar de que alguns dos tópicos não foram amplamente cobertos.
Deve-se ter cuidado na escolha do usuário que deve ser entrevistado. O mesmo
deve ser capaz de responder todas as perguntas sobre o negócio da empresa e
especialmente do seu departamento.
O segredo de uma boa entrevista é fazer o usuário descrever seu trabalho. Há
várias perguntas que resultam em respostas produtivas. A seguir estão algumas delas,
mas lembre-se: Seja flexível.
• Qual a missão do seu grupo/departamento/divisão?
• Qual mudança recente na condução do negócio é mais significativa?
• Como você mede o sucesso em seu grupo?
Perguntas sobre o nível de granularidade devem ser incluídas:
• Você consulta os dados diariamente?
• Você precisa distinguir terças de sábados?
• Instantâneos mensais são suficientes para o que você deseja fazer?
A combinação dos níveis de detalhe de cada uma das dimensões determina a
granularidade da tabela de fatos central.
Finalmente algumas perguntas sobre urgência :
• É necessário que os dados de ontem estejam disponíveis hoje? Observe que
essa pergunta é diferente daquela de granularidade. É possível que um

7
 grupo precise distinguir terças-feiras de sábados (granularidade), mas não
que os dados de ontem estejam disponíveis hoje (urgência).
• Quanto tempo após o fechamento do mês deve ser gerado o instantâneo
mensal?
As respostas a essas perguntas orientarão o projeto do sistema de extração de
dados.
No final da entrevista, será um bom momento para serem solicitados exemplos
de relatórios sobre os temas discutidos. Um processo de entrevista bem sucedido deve
resultar num acúmulo de relatórios administrativos.
Entrevistando os DBAs
Segundo Kimball [6], as entrevistas com os DBAs são de vital importância, pois
eles são os especialistas dos sistemas legados que podem ser usados como fonte de
dados do DW e, por isso, devem ser realizadas intercaladas com as dos usuários
finais. Essas entrevistas devem checar a consistência dos temas abordados nas
entrevistas com os usuários finais. Deve também ser solicitado, anteriormente, aos
DBAs, a descrição textual de cada tabela importante do banco, dos campos das
tabelas e a contagem de linhas de cada tabela para servir como suporte a construção
do DW. A seguir estão descritas algumas perguntas que devem ser feitas aos DBAs :
• Como os vários sistemas de produção relacionam-se entre si? Que sistema
alimenta outro sistema? Qual a origem dos dados?
• Onde os DW obtém os arquivos mestre para algumas das dimensões chave?
• Quais campos das tabelas importantes estão preenchidos? Quais estão
totalmente preenchidos? Quais possuem garantia de qualidade? Quais são
obrigatórios no momento da entrada de dados? Quais são validados no
momento da entrada de dados?
• O que os códigos significam? Onde é possível obter a descrição textual dos
códigos? Quem pode informar o significado dos códigos?
• Como são administradas as chaves das tabelas? Elas são reutilizadas?
• Sempre é gerada uma nova chave de produção quando acontece uma
modificação num determinado registro? Existe um documento descrevendo
exatamente essa modificação? Seremos notificados sobre essas modificações?
• É possível ler diretamente os arquivos de produção de dados? Quais sistemas
estão disponíveis para executar essa etapa de leitura? Os registros modificados
são identificados nos arquivos de dados de produção? É possível ler o histórico
de transações original?
• Há campos nessas tabelas sendo utilizados com mais de uma finalidade e
depende do contexto?
No final da entrevista, será um bom momento para ser solicitado exemplos de
relatórios fornecidos a comunidade de usuários.
Definindo o modelo de dados
Após levantamento das informações que os usuários desejam analisar no DW e
os sistemas legados onde se encontram essas informações, deve-se definir o “escopo
de integração”, que consiste em identificar as entidades que pertencem ao escopo do
modelo de dados.

8
 Depois de definir o escopo, para construir um modelo de dados para o DW, o
ponto de partida é o modelo corporativo. Contudo, um considerável número de
alterações é feito no modelo corporativo para ser aplicado ao DW, como :
• Remover dados meramente operacionais.
• As estruturas de chaves do modelo corporativo de dados são aumentadas
para conter um elemento de tempo.
• Os relacionamentos de dados dos modelos operacionais são transformados
em “artefatos” no DW.
• Realização de análise de estabilidade (consiste em agrupar atributos de
dados de acordo com sua propensão a alterações).
No final dessas transformações, se esboçará um modelo de dados que servirá
como guia para a construção do DW iterativamente. A seguir, estão algumas das
muitas razões da importância do desenvolvimento iterativo [4]:
• O usuário final não terá condições de expressar suas necessidades com
clareza até que a primeira iteração seja feita;
• A gerência não se comprometerá por completo até que verdadeiros
resultados tangíveis e claros sejam apresentados;
• Há necessidade de, rapidamente, obter resultados visíveis.
Como todo o esforço de desenvolvimento é guiado pelo modelo de dados
unificado, ele irá produzir um todo coeso e firmemente orquestrado.
Contudo há algumas limitações quanto ao uso do modelo de dados como
alicerce do DW. O modelo de dados parece tornar todas as entidades iguais e, na
realidade, no mundo do DW, as entidades não são pares idênticos, elas demandam
seu próprio tratamento especial.
Analisando o DW sob uma perspectiva tridimensional, observa-se que algumas
entidades serão escassamente povoadas, ao passo que outras serão altamente
povoadas.
A vantagem da criação do modelo dimensional consiste em agilizar os dados
para o processamento do SAD. Por meio da pré-junção dos dados e da geração de
redundância seletiva, o projetista simplifica e agiliza os dados para acesso e análise,
que é necessário para o DW.
Em resumo, o modelo de dados relacional e o dimensional se enquadram como
alicerces do projeto do DW. O modelo dimensional se aplica como um alicerce do
projeto das entidades de grande porte que existirão. O modelo de dados relacional se
aplica como alicerce do projeto para as entidades de pequeno porte.
Existem dois tipos de esquema para o modelo dimensional: o star join (estrela) e
o snowflake (flocos de neve).
No modelo star join, as instâncias são armazenadas em uma tabela contendo o
identificador de instância, valores das dimensões descritivas para cada instância, e
valores dos fatos ou medidas, para aquela instância (tabela de fatos). Além disso, pelo
menos uma tabela é usada, para cada dimensão, para armazenar dados sobre a
dimensão (tabela de dimensão). Este esquema é chamado de star join por apresentar
uma tabela de fatos dominante no centro do esquema e as tabelas de dimensões nas
extremidades. A tabela de fatos é ligada às demais tabelas por múltiplas junções,

9
enquanto as tabelas de dimensões se ligam apenas à tabela central por uma única
junção. A tabela de fatos é onde as medidas numéricas do fato representado são
armazenadas. Cada uma destas medidas é tomada segundo uma interseção de todas
as dimensões.
O outro tipo, o modelo snowflake, consiste de uma extensão do star join, onde
cada uma das pontas da estrela passa a ser o centro de outras estrelas. Porque cada
tabela de dimensão seria normalizada, quebrando-se a tabela original ao longo de
hierarquias existentes em seus atributos.
Kimball [6] aconselha os projetistas a resistirem à tentação de transformar
esquemas estrela em floco de neve, devido ao impacto da complexidade deste tipo de
estrutura sobre o usuário final, enquanto que o ganho em termos de espaço de
armazenamento seria pouco relevante.
Questões que devem ser observadas na modelagem
Segundo Kimball [6], algumas características devem ser observadas, durante a
modelagem do DW, para que as consultas não produzam resultados incorretos, pois as
mesmas servirão de base para a tomada de decisão das empresas, ou se tornem muito
lentas e impossíveis de serem executadas. São elas:
• Atributos semi-aditivos e não aditivos
Uma operação não aditiva, como o cálculo da margem bruta, pode ser
computada em qualquer plano da tabela de fatos, lembrando-se de calcular o quociente
das somas, não a soma dos quocientes. Em outras palavras, o resultado deve ser a
divisão das somas e não o inverso. Uma operação semi-aditiva não pode ser
adicionada ao longo de todas as dimensões da tabela de fatos, deve-se limitar com
isso a operação às dimensões válidas.
• Dimensões descaracterizadas
Números de controle de documentos, como números de pedidos, números de
fatura e números de conhecimento de embarque, normalmente são representados
como dimensões descaracterizadas (isto é, chaves de dimensão sem uma tabela
correspondente) em tabelas de fatos em que o grão da tabela é o documento
propriamente dito ou uma linha de item do documento.
• Dimensões derivadas que suportam agregados
Ë extremamente importante construir tabelas de fatos derivadas (resumidas) em
vários níveis superiores de detalhe para melhorar o desempenho das consultas, que de
outra forma apresentariam um grande número de registros.
Existem muitas formas de agregados no DW, sendo as mais comuns:
a. Cumulativa simples: as transações diárias são transportadas do ambiente
operacional e resumidas em forma de registros no DW. O resumo pode ser feito
por qualquer área de interesse, segundo a qual o DW esteja organizado.
b. Resumo rotativo: os dados passam do ambiente operacional para o DW
como mencionado anteriormente. A diferença está na forma como é agregado.
Por exemplo, nesta estrutura, nos primeiros sete dias da semana a atividade é
resumida em sete posições diárias. No oitavo dia, as sete posições diárias são
acumuladas e colocadas na primeira posição semanal. No final do mês, as
posições semanais são acumuladas e colocadas na primeira posição mensal. No
final do ano, as posições mensais são acumuladas, e a primeira posição anual é

10
carregada. Existem vantagens e desvantagens nesta abordagem com relação a
anterior:
ƒ Os dados podem ser processados para encontrar o ponto mais alto,
mais baixo, a média, e assim por diante.
ƒ A primeira e a última ocorrência de dados podem ser dispostas em
um bloco.
ƒ Dados de determinados tipos, inseridos nos limites de diversos
parâmetros, podem ser mensurados.
ƒ Dados válidos em relação a um determinado momento podem ser
dispostos em um bloco.
ƒ Os dados mais antigos e os mais recentes podem ser dispostos em
um bloco.
c. Dimensões grandes: não se devem desmembrar as dimensões, mesmo que
elas sejam extensas, pois poderá causar um desempenho limitado. A melhor
abordagem para rastrear modificações nessas tabelas é subdividi-las em
minidimensões compostas por pequenos conjuntos de atributos estruturados
para conter um número limitado de valores.
d. Dimensões de modificação lenta: o DW deve representar de forma
concreta o histórico passado, por isso não se pode considerar que as entidades
não se modificam ao longo do tempo. Entretanto, a solução não será incluir tudo
na tabela de fatos ou tornar cada dimensão dependente no tempo. Em vez
disso, deve-se explorar o fato de que a maioria das dimensões é constante ao
longo do tempo e que se pode preservar uma estrutura dimensional
independente, incluindo relativamente poucas adições para capturar o aspecto
temporal das modificações. Essas dimensões praticamente constantes são
chamadas de dimensões de modificação lenta. Existem três opções de
modificação destas dimensões, cada uma delas resultando em um diferente
nível de rastreamento de modificações ao longo do tempo:
ƒ Substituir os valores antigos dos registros da dimensão e, portanto,
perder a capacidade de rastrear o histórico passado.
ƒ Adicionar um registro à dimensão, contendo os novos valores do
atributo no momento da mudança, para segmentar o histórico entre a
descrição antiga e a nova descrição com muita precisão.
ƒ Criar novos campos “atuais” no registro original da dimensão para
incluir os novos valores do atributo, mantendo também seus valores
originais, permitindo dessa forma descrever o histórico anterior e o
posterior à mudança tanto em relação aos valores originais do atributo
quanto aos valores atuais.
e. Tabela de fatos sem fatos: alguns processos que são representados no DW
produzem tabelas de fatos semelhantes às tabelas que foram construídas, mas
que não contém fatos mensuráveis. São chamadas de tabelas de fatos sem
fatos. As duas principais variações dessas tabelas são tabelas de rastreamento
de eventos e tabelas de cobertura. Os eventos são geralmente modelados por
uma tabela de fatos contendo algumas chaves, cada qual representando uma
dimensão do evento, freqüentemente não estão associadas a fatos numéricos
óbvios. As tabelas de cobertura são, freqüentemente, tabelas de eventos que

11
 não ocorreram e, de modo geral, não contém fatos assim como as tabelas de
rastreamento de eventos. [6]
Decisões no projeto de um DW
Uma vez que o modelo de dados tenha sido definido, o próximo passo é definir
algumas características do projeto físico, para que se possam satisfazer alguns
critérios como:
• Capacidade de gerenciar grande quantidade de dados.
• Capacidade de permitir que os dados sejam acessados de modo flexível.
• Capacidade de, periodicamente, carregar grande quantidades de dados.
• Capacidade de acessar dados de um registro por vez, ...
Granularidade
O mais importante aspecto do projeto de DW é a questão da granularidade, pois
afeta profundamente o volume de dados que residem no DW e, ao mesmo tempo, afeta
o tipo de consulta que pode ser atendida.
O volume de dados e o espaço bruto não são as únicas questões relevantes,
existe também a força de processamento que precisa ser empregada para acessar
esses dados.
Há, portanto, um bom motivo para a compactação de dados, porque se
economiza, sobre o total de DASD utilizado, o número de índices necessários e os
recursos de processador para o tratamento de dados.
No entanto, à medida que o nível de granularidade se eleva, há uma
correspondente diminuição da possibilidade de utilização dos dados para atender a
consulta.
Para solucionar essa questão, ou seja, possuir armazenamento e acesso aos
dados de forma eficiente e, ao mesmo tempo, poder analisar os dados em maior
detalhe, deve-se utilizar níveis duais de granularidade na parte detalhada do DW.
Ao criar dois níveis de granularidade no nível detalhado, o arquiteto do SAD
possibilita que, na maior parte do tempo, o processamento dirija-se aos dados
levemente resumidos que são compactados e de fácil acesso, além de disponibilizar o
nível de dados históricos quando um maior nível de detalhe for requerido.
Em decorrência dos custos, da eficiência, da facilidade de acesso e da
possibilidade de atender a qualquer consulta que possa ser respondida, para a maior
parte das empresas, o nível dual de dados consiste na melhor opção arquitetônica para
o nível detalhado do DW.
Particionamento
O objetivo do particionamento dos dados de detalhe corrente consiste em
repartir os dados em unidades físicas menores, para proporcionar ao pessoal de
operação e ao projetista mais flexibilidade no gerenciamento dos dados do que é
proporcionado pelas unidades físicas maiores.
Quando os dados residem em unidades físicas maiores, entre outras coisas,
eles não podem ser: Reestruturados facilmente; Indexados livremente; Pesquisados
seqüencialmente, se necessário; Reorganizados, Recuperados ou Monitorados
facilmente

12
 Há vários critérios por meio dos quais é possível dividir dados, como: Data; Área
de negócio; Área geográfica; Unidade organizacional ou por todos os critérios
anteriores.
Ciclicidade dos dados
A ciclicidade de dados refere-se ao tempo necessário para que uma alteração
realizada no ambiente operacional seja refletida no DW. Algumas razões devem ser
observadas, como:
• Quanto mais rigidamente o ambiente operacional for emparelhado com o
DW, mais dispendiosa e complexa será a tecnologia.
• Os dados devem ser estabilizados antes de migrarem para o DW.
Eliminação dos dados
Há diversas maneiras pelas quais os dados são eliminados ou os detalhes dos
dados são transformados, como [4]:
• Acrescentados a um arquivo de resumo rotativo onde os detalhes são
perdidos.
• Transferidos de um meio de armazenamento para outro de alta performance,
como do DASD para um meio de armazenamento em massa.
• Efetivamente eliminados do sistema.
• Transferidos de um nível de arquitetura para outro, como do nível
operacional para o nível de data warehouse.
Instantâneos
A interação básica de negócios, que faz com que o DW se torne povoado por
dados, pode ser chamada de interação “EVENTO -> INSTANTÂNEO”. Em uma
interação “EVENTO -> INSTANTÂNEO”, algum evento de negócio dispara um
instantâneo de dados (normalmente no ambiente operacional), que por sua vez é
movido para o ambiente de DW.
Existem dois tipos de evento de negócio que podem disparar um instantâneo:
• Evento gerado pela atividade: um exemplo pode ser a concretização de uma
venda, a entrada de um item no estoque, a realização de uma chamada
telefônica ou a entrada de uma carga.
• Evento gerado pelo tempo: Um exemplo pode ser o final do dia, o final da
semana, ou o final de mês.
Erros na implantação de um DW
O Data Warehousing Institute [10] aponta os dez erros mais comuns na
implantação de um DW:
1. Começar o projeto com o tipo errado de patrocínio.
2. Gerar expectativas que não podem ser satisfeitas, frustrando os executivos
quando da utilização do DW.
3. Dizer: “Isto vai ajudar os gerentes a tomar decisões melhores” e outras
informações politicamente ingênuas.
4. Carregar o DW com informações só “porque estavam disponíveis” .

13
 5. Falhar no objetivo de acrescentar valor ao dada por meio de mecanismos de
desnormalização, categorização e navegação assistida.
6. Escolher um gerente que seja voltado para a tecnologia e não para o usuário.
7. Focalizar em dados tradicionais internos orientados a registro e ignorar o valor
potencial de dados textuais, imagem, som, vídeo e dados externos.
8. Fornecer dados com definições confusas e sobrepostas.
9. Acreditar nas promessas de desempenho, capacidade e escalabilidade dos
vendedores de produtos.
10. Usar o DW como justificativa para modelagem de dados e uso de ferramentas
case.
Povoando um data warehouse
A extração, limpeza, transformação e migração de dados dos sistemas
existentes na empresa para o DW constituem tarefas críticas para o seu funcionamento
efetivo e eficiente.
Diversas técnicas e abordagens têm sido propostas, algumas bastante
genéricas e outras especialmente voltadas para a manutenção da integridade dos
dados num ambiente caracterizado pela derivação e replicação de informações.
O grande desafio por trás da alimentação de dados das fontes para o DW não é
técnico, mas gerencial. Muitos dos processos envolvidos – como mapeamento,
integração e avaliação da qualidade – ocorrem de fato durante a fase de análise e
projeto. Especialistas afirmam que identificar fontes, definir regras de transformação,
detectar e resolver questões de qualidade e integração consome cerca de 80% do
tempo de projeto. Embora algumas ferramentas possam ajudar a detectar problemas
na qualidade dos dados e gerar programas de extração, a maioria das informações
necessárias para desenvolver regras de mapeamento e transformação existe apenas
na cabeça dos analistas e usuários. Fatores que certamente influem na estimativa de
tempo para estas tarefas são o número de fontes e a qualidade dos metadados sobre
as fontes. As regras de negócio associadas a cada fonte – tais como validação de
domínios, regras de derivação e dependências entre elementos de dados – são outras
fonte de preocupações. Se estas regras tiverem de ser extraídas do código fonte das
aplicações, o tempo para mapeamento e integração pode dobrar.
Os processos associados à migração de dados das fontes para o DW incluem
extração de dados, limpeza, transformação e carga do DW.
Extração
As várias alternativas para extração permitem balancear desempenho, restrições
de tempo e de armazenamento. Por exemplo, se a fonte for um banco de dados on-
line, pode-se submeter uma consulta diretamente ao banco para criar os arquivos de
extração. O desempenho das aplicações ligadas às fontes pode cair consideravelmente
se transações on-line e as consultas para extração competirem entre si. Uma solução
alternativa é criar uma cópia corrente dos dados das fontes a partir da qual então se
fará a extração. Como desvantagem desta solução, pode-se citar o espaço adicional de
disco necessário para armazenar a cópia.
Outra alternativa é examinar o ciclo de processamento de algumas transações
off-line que atuem nas fontes. Os programas que criam os arquivos de extração para a
carga do DW podem ser incorporados a um ponto apropriado do esquema de
processamento.
14
Transformação e filtros
Os processos de transformação invocam as regras que convertem valores de
dados das fontes para valores do ambiente global e integrado do DW. Algumas
ferramentas permitem ao usuário controlar a maioria das atividades de exportação e
transformação por meio de parâmetros e “scripts”, constituindo uma filtragem
avançada. Outras ferramentas atuam como shells onde programas específicos de
extração e filtragem são inseridos.
Incorporando modificações
Sempre que modificações relevantes são feitas nas fontes de informações, estes
novos dados são extraídos e traduzidos para o modelo de dados do DW, onde são
integrados com os já existentes.
A detecção e extração das modificações dependem das facilidades disponíveis
pela fonte. Se esta fonte dor sofisticada, como um SGBD relacional que possui triggers,
este processo é relativamente fácil. No entanto, em muitos casos a fonte não dispõe de
recursos avançados para detecção e captura das modificações (sistemas herdados,
por exemplo). Neste casos existem basicamente três alternativas para detectar e extrair
modificações:
1. A aplicação que utiliza a fonte de informação é alterada de modo a enviar
notificações de alteração para o DW. Esta alternativa requer que o código
existente seja modificado. No entanto, na maioria dos casos essa opção é
impraticável devido à complexidade do código e grande tempo necessário
para sua alteração.
2. O arquivo de log do sistema é analisado de modo a obter as modificações
relevantes. O problema com esta alternativa é que, normalmente, são
necessários privilégios de DBA para acessar o log e muitos administradores
relutam em prover este acesso pois coloca em risco a segurança do sistema.
3. As modificações são determinadas por meio da comparação do dump
corrente da fonte com um anterior. O problema com esta alternativa é que ela
não é muito escalonável, ou seja, à medida que os dados das fontes
aumentam é necessário um número muito maior de comparações. Deste
modo, torna-se absolutamente necessário implementar este algoritmo do
modo mais eficiente possível.
OLAP
OLAP sempre envolve consultas interativas aos dados, seguindo um caminho de
análise por meio de múltiplos passos, como por exemplo, aprofundar-se
sucessivamente por níveis mais baixos de detalhe de um quesito de informação
específico. Envolve capacidades analíticas, incluindo a derivação de taxas, variâncias e
outras, envolvendo medidas ou dados numéricos por meio de muitas dimensões,
devendo suportar modelo de previsões, análises estatísticas e de tendências.
Dois tipos de processos são bastante comuns em aplicações OLAP:
• Slice and Dice: corresponde à técnica de mudar a ordem das dimensões
mudando assim a orientação segundo a qual os dados são visualizados.
Embora os dados permaneçam os mesmos, a mudança de orientação
permite ao usuário investigar diferentes inter-relacionamentos entre eles.
• Drill Down: consiste em permitir ao usuário “descer” pelas hierarquias das
dimensões: é comum o usuário iniciar pelo nível resumido (tal como vendas

15
 nacionais, por marca) e então seletivamente obter níveis de detalhe
adicionais para seguir e explicar uma observação feita no nível resumido.
Conclusão
As organizações atuais, tanto nacionais como multinacionais, estão sempre
procurando vantagens competitivas. Sabe-se que a informação é a chave para se
ganhar tal vantagem. O problema é entender como as montanhas de dados que estão
nos sistemas operacionais irão ajudar para tal.
Nesse cenário, surge o DW como uma alternativa de transformar tais dados em
informações que irão ajudar a identificar as oportunidades para obtenção dessas
vantagens.
Bibliografia
[1] Corey, M., Abbey, M., Abramson, I., Taub, B. Oracle 8i - Data Warehouse. Campus,
2001.
[2] Gonçalves, M. Extração de Dados para Data Warehouse. Axcel Books, 2003.
[3] Inmon, W.H.. Terdeman, R. H., Imjoff, C. Data Warehousing: como transformar
informações em oportunidades de negócio. Berkeley, 2001.
[4] Inmon, W.H. Como Construir o Data Warehouse. Campus, 1997.
[5] Inmon, W.H., Welch, J. D., Glassey, K. L. Gerenciando Data Warehouse. Makron
Books, 1999.
[6] Kimball, R. Data Warehouse Toolkit. Makron Books, 1998.
[7] Kimball, R., Merz, R. Data Webhouse: construindo o data warehouse para a Web.
Campus, 2000.
[8] Pinheiro, Carlos A. R. WEB Warehousing, Extração e Gerenciamento de Dados na
Internet. Axcel Books, 2003.
[9] Thomsen, E. OLAP: Construindo sistemas de informações multidimensionais.
Campus, 2002.
[10] Singh, H. S. Data Warehouse: conceitos, tecnologias, implantação e
gerenciamento. Makron Books, 2001.

16