BI um sistema de apoio a decisões gerenciais

Prévia do material em texto

Business Intelligence: um sistema de apoio a decisões 
gerenciais 
André Amaral Muszinski, Silvia de Castro Bertagnolli 
Faculdade de Informática – Curso de Bacharelado em Sistemas de Informação – Centro 
Universitário Ritter dos Reis (Uniritter) – Porto Alegre – RS – Brasil 
andre.amaral@neogrid.com, silviacb@uniritter.edu.br
Resumo. Os ambientes de negócios cada vez mais complexos exigem dos 
gestores ações mais rápidas, inovadoras e ágeis. Um dos maiores problemas 
enfrentados pelas empresas é a dificuldade em realizar a análise dos negócios 
e a gestão de desempenho da corporação. Este artigo descreve o 
desenvolvimento de uma solução de Business Intelligence (centrada em um 
Data warehouse, utilizando Integração de Dados e Processamento Analítico 
Online), que permite, através de relatórios e gráficos, a visualização de dados 
financeiros e estratégicos da empresa, apoiando o processo de tomada de 
decisão. 
Abstract. The business environments increasingly complex, requires quicker, 
innovative and agile actions from the managers. One of the biggest problems 
faced by companies is the difficulty in performing business analysis and 
performance management of the corporation. This paper presents the 
development of a Business Intelligence solution (centered in a Data 
Warehouse, using the Data Integration and Online Analytical Processing), 
which allows, through reports and graphs, visualization of financial and 
strategic data of company, supporting the decision making process. 
1. Introdução 
Um dos maiores problemas enfrentados pelas empresas é a dificuldade em realizar a 
análise dos negócios e gestão de desempenho da corporação. Hoje, estas análises são 
realizadas utilizando-se planilhas eletrônicas e consultas SQL (Structured Query 
Language) complexas com vários joins que são executadas nos bancos de dados 
transacionais, gerando lentidão (e até mesmo paradas) nos sistemas. A consulta SQL 
gerada pela equipe de TI (Tecnologia da Informação), normalmente não atende a todas 
as necessidades do usuário final, fazendo com que todo o ciclo se repita (solicitar os 
dados, esperar, receber os dados, revisar a informação e analisar os resultados). A 
geração de uma simples planilha eletrônica, para ser utilizada como ferramenta no 
planejamento estratégico, pode levar semanas para ser desenvolvida. 
 Neste cenário, um sistema computadorizado de suporte aos gestores, como o 
Business Intelligence (BI), permite decisões melhores e mais rápidas. Uma solução de 
BI centrada em Data Warehouse (DW), separada do servidor de banco de dados 
transacional, proporciona um repositório central de dados, criando uma “fábrica de 
informações”, onde relatórios, gráficos e alertas de desempenho podem ser gerados 
diretamente pelo usuário final. Isto permite que os usuários possam acessar dados 
 
históricos da empresa, possibilitando decisões ágeis, análise dos negócios, análise de 
tendências, descoberta de informações e conhecimento. O DW é um ponto-chave nesta 
arquitetura, pois centraliza a informação, possibilitando uma “versão única da verdade”.
 O presente trabalho foi desenvolvido na NeoGrid Informática, empresa 
especializada em soluções de Business-to-Business (B2B). O projeto iniciou com a 
análise dos relatórios financeiros e de desempenho, gerados pelo Administrador de 
Banco de Dados (DBA), solicitados pela diretoria mensalmente. 
 O objetivo foi implementar uma solução de BI de modo a apoiar a tomada de 
decisão de gerentes de negócios (nível comercial), gerentes departamentais (nível tático) 
e diretores (nível estratégico) da NeoGrid, utilizando dados históricos e atuais, e 
visualizando-os através de relatórios, gráficos e indicadores-chave de desempenho (Key 
Performance Indicator - KPI) utilizando ferramentas de processamento analítico. 
 Para tanto, foi necessário (i) definir e implantar a arquitetura necessária para o 
desenvolvimento da solução; (ii) analisar os relatórios financeiros e de desempenho 
gerados pelo DBA mensalmente; (iii) definir os Data Marts e relatórios necessários; (iv) 
validar a implementação dos relatórios junto a gerentes de negócios, gerentes 
departamentais e diretores. 
 O texto deste artigo encontra-se organizado em 5 seções, onde: a seção 2 detalha 
os aspectos teóricos que fundamentam a solução proposta; a seção 3 descreve a solução 
implementada, bem como os diagramas e elementos que auxiliaram na modelagem; a 
seção 4 apresenta os resultados obtidos com a aplicação do trabalho em um estudo de 
caso real; e a seção 5 apresenta a conclusão do trabalho. 
2. Referencial Teórico 
Este capítulo apresenta os principais elementos teóricos que foram utilizados para 
elaborar a solução proposta. 
2.1 Business Intelligence 
Business Intelligence (BI) é um termo relativamente novo, mas certamente não é um 
conceito novo. Este termo foi criado pelo Grupo Gartner no início dos anos 1990 e 
inclui arquiteturas, ferramentas, bancos de dados, aplicações e metodologias. O conceito 
é simples: fazer uso de informações já disponíveis nas organizações para ajudar os 
responsáveis pelas tomadas de decisões a adotar as melhores opções e de forma mais 
rápida. 
 Os principais objetivos do BI são permitir o acesso interativo aos dados, 
proporcionar a manipulação destes dados e fornecer aos gestores a capacidade de 
realizar a análise adequada. Ao examinarem os dados, situações e desempenhos 
históricos e atuais, os tomadores de decisão conseguem uma melhor compreensão dos 
dados, que podem servir como base para decisões melhores e mais informadas. O 
processo de BI baseia-se na transformação de dados em informações (TURBAN et. al, 
2009). 
 O principal benefício do BI para uma organização é a capacidade de fornecer 
informações precisas quando necessário, incluindo uma visão em tempo real do 
desempenho corporativo. Estas informações são necessárias para todos os tipos de 
 
decisões, principalmente para o planejamento estratégico (TURBAN et. al, 2009). Seus 
principais benefícios compreendem: economia de tempo, versão única da verdade, 
melhores estratégias e planos, melhores decisões táticas, processos mais eficientes e 
economia de custos. As aplicações de BI visam diminuir a diferença entre o 
desempenho atual de uma organização e o desempenho desejado, expresso em sua 
missão, objetivos, metas e a estratégia para atingi-los. 
 Um sistema de BI possui quatro grandes componentes, conforme descreve Turban 
(2009): (i) data warehouse, banco ou repositório de dados especial preparado para dar 
suporte a aplicações de tomada de decisão; (ii) análise de negócios, corresponde a uma 
coleção de ferramentas para manipular e analisar os dados no DW, incluindo 
processamento analítico, multidimensionalidade, mineração de dados e técnicas de 
análise avançada; (iii) gestão de desempenho do negócio (Business Performance 
Management – BPM) para monitoria e comparação do desempenho da corporação às 
metas estabelecidas, com a aplicação de balanced scorecards; e (iv) interface com 
usuário. 
 As áreas mais comuns de aplicação do BI são relatórios gerais, análise de vendas e 
marketing, planejamento e previsão, consolidação financeira, relatórios de desempenho, 
orçamento e análise de rentabilidade (JACOBSON; MISNER, 2007). 
 Transformar dados históricos em conhecimento estratégico é um dos objetivos da 
tecnologia da informação nas organizações. O DW é uma ferramenta que surgiu com 
esse propósito, trazendo a idéia de centralização das informações, visualização 
multidimensional dos dados e descoberta de padrões de comportamento para dar aos 
administradores maior agilidade na tomada de decisões (BARBALHO, 2003). 
2.2 Data Warehouse 
Um data warehouse (DW) é um conjunto de dados produzido para oferecer suporte à 
tomada de decisões. Ele é um repositório de dados atuais e históricos de possível 
interesse aos gestores de toda a organização. Osdados, normalmente, são estruturados 
de modo a estarem disponíveis em um formato pronto para atividades de processamento 
analítico (processamento analítico online, mineração de dados, consultas, geração de 
relatórios, outras aplicações de suporte à decisão). Portanto, um DW é uma coleção de 
dados orientada por assunto, integrada, variável no tempo e não-volátil, que proporciona 
suporte ao processo de tomada de decisões da gerência (LARSON; AGARWAL, 2006). 
 Os DWs contêm uma grande variedade de dados que apresentam uma imagem 
coerente das condições da empresa em um determinado ponto no tempo. A idéia por trás 
do conceito foi criar uma infra-estrutura de banco de dados que estivesse sempre online 
e contivesse todas as informações dos sistemas de processamento de transações online 
(Online Transaction Processing - OLTP), incluindo dados históricos (DELANEY; 
AGARWAL, 2006). Porém, esta infra-estrutura seria reorganizada e estruturada de 
forma a oferecer rapidez e eficiência em consultas, análises e suporte à decisão. Em 
geral, o DW é armazenado em um banco de dados separado da base operacional. Esta 
separação evita a perda de desempenho no processo operacional da empresa 
(BARBALHO, 2003). 
 Os tomadores de decisão necessitam de informações concisas e confiáveis, sobre 
operações atuais, tendências e mudanças. As informações de interesse para a empresa 
 
são constantemente fragmentadas com o uso de diferentes sistemas operacionais e fontes 
externas, e assim os gestores tomam decisões com informações parciais, na melhor das 
hipóteses. O DW supera este obstáculo acessando, integrando e organizando os 
principais dados operacionais de uma forma consistente, confiável e prontamente 
disponível, onde for necessário (TURBAN et. al, 2009). 
 Um data warehouse une bancos de dados de toda uma empresa. Já um Data Mart 
(DM), normalmente é menor e se concentra em um assunto ou departamento específico. 
Um Data Mart é um subconjunto de um DW, que normalmente consiste em uma única 
área temática (ex.: marketing, vendas, operações). Em um DM pode existir mais de um 
fato e a utilização de dimensões comuns a eles (MACHADO, 2004). Os DMs são uma 
solução menos cara, capazes de serem substituídos por um DW ou de complementá-lo. 
Eles podem ser dependentes ou independentes de um DW. 
2.2.1 Arquiteturas de Data Warehouse 
A escolha da arquitetura e sua implementação são decisões gerenciais do projeto. Estes 
fatores estão relacionados à infra-estrutura disponível (banco de dados, ferramentas 
OLAP e ETL, processamento paralelo, particionamento de dados), ao ambiente de 
negócios (porte da empresa), escopo de abrangência desejado, assim como a capacidade 
da equipe interna de TI e dos recursos disponibilizados para investimento (MACHADO, 
2004). De acordo com Ballard et. al (2006), as principais arquiteturas utilizadas são: 
• arquitetura de Data Warehouse Empresarial (Enterprise Data Warehouse – 
EDW) – é considerada a que suporta toda ou maior parte dos requisitos ou 
necessidades. Ela possui grande grau de acesso e a utilização das informações é 
para todos os departamentos de uma empresa; 
• arquitetura de Data Mart Independente – é um DW projetado para uma unidade 
estratégica de negócios ou um departamento, mas cuja fonte não é um EDW. 
Eles são fáceis de construir, porém envolvem altos custos, redundância de 
dados e não permitem uma visão global da empresa; 
• arquitetura de Data Mart Dependente (Integrados) – é um subconjunto criado a 
partir do EDW. Ele tem a vantagem de usar um modelo de dados consistente e 
apresentar dados de qualidade. 
 Cada arquitetura de DW tem aplicações específicas para as quais sua eficiência é 
maior (ou menor), e assim oferece os benefícios máximos para a organização 
(BALLARD et. al, 2006). 
 A decisão de qual arquitetura implementar pode causar impactos quanto ao 
sucesso do projeto de um DW. Diversos fatores influenciam a escolha da arquitetura e 
implementação, entre elas o tempo para execução do projeto, a necessidade urgente de 
um DW, o retorno do investimento a ser realizado, a velocidade dos benefícios da 
utilização das informações, a limitação de recursos, a satisfação do usuário executivo, a 
compatibilidade com sistemas existentes e os recursos necessários à implementação de 
uma arquitetura (KIMBALL, 2002). 
 
2.2.2 Tipos de Implementação 
Vários tipos de implementação de arquiteturas de DW podem ser usados. Segundo 
Machado (2004), os tipos de implementação mais utilizadas em empresas são: top 
down, bottom up e uma combinação das duas. 
 A implementação top down é conhecida como padrão inicial do conceito de DW. 
Ela requer maior planejamento e trabalho de definições conceituais de tecnologias 
completos antes de iniciar o projeto de DW. Neste tipo de arquitetura constrói-se, em 
primeiro lugar, o EDW e depois se extrai os dados para os DMs (INMON, 2005). 
 A abordagem top down, proposta por Inmon (2005), apresenta como vantagens: (i) 
herança de arquitetura – todos os DMs originados de um DW utilizam a arquitetura e os 
dados do DW; (ii) visão de empreendimento – o DW concentra todos os negócios da 
empresa; (iii) controle e centralização de regras – garante a existência de um único 
conjunto de aplicações ETL (Extract, Transform and Load). Machado (2004) destaca as 
seguintes desvantagens: (i) implementação muito longa; (ii) alta taxa de risco – não 
existem garantias para o investimento neste tipo de ambiente; (iii) expectativas 
relacionadas ao ambiente – a demora do projeto e a falta de retorno podem induzir 
expectativas nos usuários. 
 Devido ao custo e tempo necessários em uma implementação top down, a 
implementação bottom up vem se tornando muito popular. O propósito é construir um 
DW incremental a partir do desenvolvimento de DMs independentes. Ela é bastante 
utilizada, pois possui um retorno de investimento muito rápido (KIMBALL, 2002). 
Kimball (2002) destaca as seguintes vantagens da abordagem bottom up: implementação 
rápida, retorno rápido e enfoque inicial nos principais negócios. Já Machado (2004) 
destaca as seguintes desvantagens: (i) perigo de DMs legados: um dos maiores perigos 
no DW é a criação de DMs independentes. A solução pode não considerar a arquitetura 
de forma global. Desse modo, os DMs independentes transformam-se em DM legados, 
que podem inviabilizar futuras integrações; (ii) dificuldade em obter a visão do 
empreendimento; (iii) coordenação de múltiplas equipes e iniciativas; e (iv) 
procedimentos de ETL mais complexos. 
 A implementação combinada tem o propósito de integrar a arquitetura top down 
com a bottom up. Nessa abordagem efetua-se a modelagem de dados do DW de visão 
macro, sendo o passo seguinte a implementação de partes desse modelo. Essas partes 
são escolhidas por processos ou atividades da área de interesse e constituem os DMs. 
Cada DM pode ser gerado a partir do macromodelo de dados do DW e integrado ao 
modelo físico do DW (MACHADO, 2004). 
2.2.3 Modelagem dimensional 
O projeto de DW se baseia no conceito de modelagem dimensional (ou 
multidimensional), que compreende um sistema baseado em recuperação que suporta 
acessos com alto volume de consultas. A representação dos dados é estruturada como 
um cubo, transmitindo a idéia de múltiplas dimensões. 
 A maior vantagem da multidimensionalidade é que ela permite que os dados 
sejam organizados de acordo com a preferência de cada usuário (ou área de negócio). 
 
Apresentações diferentes dos mesmos dados podem ser providenciadas de modo rápido 
e fácil (ITALIANO; ESTEVES, 2004a). 
 O modelo multidimensional é baseado em três tipos de estruturas (REIS; 
TEIXEIRA; ARAÚJO, 2009): 
• fatos – a tabela de fatos é a tabela central do modelo e contém os valores 
(numéricos) que se deseja analisar, geralmente, contendo um grande volume de 
dados. A tabela fato possui chaves externas, que se relacionam comsuas 
tabelas de dimensões, e campos numéricos que são os valores (medidas) que 
serão analisados; 
• dimensões – as tabelas de dimensões representam um aspecto do negócio que 
está sendo analisado. Sua chave primária serve para manter a integridade 
referencial na tabela fato à qual está relacionada. Uma dimensão oferece ao 
usuário um grande número de combinações e intersecções para analisar os 
dados, possibilitando diversas formas de visualizar os dados; 
• medidas – são atributos numéricos armazenados na tabela de fatos, que 
representam o desempenho de um indicador em relação às dimensões que 
participam desse fato. 
 A modelagem multidimensional é um processo que envolve algumas etapas cujo 
objetivo é levantar e representar as necessidades de análise e de informações dos 
usuários de determinado departamento ou área de negócios (REIS; TEIXEIRA; 
ARAÚJO, 2009). 
 Para Ballard et. al (2006), existem três tipos básicos de modelos 
multidimensionais: 
• esquema estrela – cada dimensão é formada por apenas uma tabela não 
padronizada. O fato de suas tabelas não estarem normalizadas, resultará em 
uma menor quantidade de tabelas no modelo do DM, mas como conseqüência 
poderá causar redundância dos dados, fato característico neste tipo de solução; 
• esquema multi-estrela – este esquema é baseado no esquema estrela, com uma 
tabela para cada dimensão, porém existem múltiplas tabelas de fatos, unidas 
através das dimensões; 
• esquema floco de neve – neste esquema as tabelas das dimensões estão 
padronizadas para eliminar a redundância dos dados. Diferente do esquema 
estrela, neste esquema os dados das dimensões estão distribuídos em múltiplas 
tabelas. 
 As estruturas das dimensões possuem níveis, onde cada nível de uma dimensão 
deve ter correspondência com uma coluna na tabela da dimensão. Os dados são 
classificados (ordenados) por grau de detalhe e são organizados em uma estrutura 
hierárquica (ITALIANO; ESTEVES, 2004b). 
2.2.4 Integração de dados e processos de ETL 
Um grande objetivo do DW é integrar dados de múltiplos sistemas. A integração de 
dados compreende três grandes processos que, quando implementados corretamente, 
 
permitem que eles sejam disponibilizados a um conjunto de ferramentas de Extração, 
Transformação e Carga (ETL), análise e ao ambiente de data warehousing (LANGIT, 
2008). Já os processos compreendem: (i) acesso aos dados (a capacidade de acessar e 
extrair dados de qualquer fonte), (ii) federação de dados (a integração das visualizações 
de negócios em diversos data stores) e (iii) captura de alterações (com base na 
identificação, captura e entrega das alterações feitas nas fontes de dados da empresa). 
 O ETL é extremamente importante na integração de dados e também no DW, pois 
seu objetivo é carregar dados integrados e limpos. Os dados usados nestes processos 
podem ser oriundos de qualquer fonte: uma aplicação de mainframe, uma aplicação 
ERP (Enterprise Resource Planning), uma ferramenta de CRM (Relationship 
Management), um arquivo texto, uma planilha do Excel ou até uma fila de mensagens 
(TURLEY; KASPRZAK; CAMERON, 2007). 
 O processo de ETL é um componente essencial de qualquer projeto centrado em 
dados. Langit (2008) classifica o processo em três etapas: (i) extração, com leitura de 
uma ou mais fontes de dados; (ii) transformação, onde dados anteriormente extraídos 
são convertidos na forma em que precisam estar, para que sejam colocados em um DW 
ou em um banco de dados; (iii) e carga dos dados no DW. 
 É comum que as organizações possuam sistemas transacionais desenvolvidos por 
diferentes equipes e, que no seu desenvolvimento, tenham adotado diferentes 
convenções na codificação de variáveis, nomes dos atributos das tabelas, diferentes 
tipos de dados ou formatos de datas. Ao extrair os dados dos diferentes sistemas, deve 
ser definido um formato único para o DW e realizar as transformações necessárias em 
cada caso (TURLEY; KASPRZAK; CAMERON, 2007). 
2.2.5 Processamento Analítico Online (OLAP) 
O OLAP (Online Analytical Processing) é um conjunto de ferramentas e técnicas que 
permite realizar a exploração dos dados de um DW, utilizando os recursos de 
modelagem, análise e visualização de grandes conjuntos de dados. O OLAP ajuda a 
analisar de forma mais eficiente a quantidade de dados crescente armazenados pelas 
organizações transformando-os em informação (JACOBSON; MISNER, 2007). 
 Relatórios e consultas fazem parte das atividades mais antigas de OLAP e BI. O 
OLAP possibilita que o usuário produza facilmente seus próprios relatórios e analise 
tendências e desempenho diariamente (TURBAN et. al, 2009). Os sistemas OLAP 
oferecem uma alternativa aos sistemas transacionais, produzindo uma visão dos dados 
orientados à análise, além de uma navegação rápida e flexível (LARSON; AGARWAL, 
2006). Um sistema OLAP apresenta as seguintes características: (i) esquema otimizado 
para que as consultas realizadas pelos usuários sejam retornadas rapidamente; (ii) 
geração de relatórios complexos de uma forma simples; (iii) utilização interativa com os 
usuários, ou seja, as consultas não necessitam estar pré-definidas; e (iv) permite a 
redundância de dados para otimização de consultas. 
 Kimball (2002) classifica os sistemas OLAP em três tipos: (i) OLAP 
multidimensional (MOLAP) – é implementado através de um DW multidimensional. Os 
dados são organizados em uma estrutura de cubos; (ii) OLAP relacional (ROLAP) – é 
implementado sobre um banco de dados relacional; e (iii) OLAP híbrido (HOLAP) – 
combina atributos de MOLAP e ROLAP. 
 
 Ballard et. al (2006) destaca as principais operações utilizadas nas ferramentas 
OLAP: (i) drill down e roll up - são operações que movimentam a visão dos dados 
(cubo) ao longo das hierarquias de uma dimensão. O drill down ocorre quando o usuário 
desagrupa os dados, aumentando o nível de detalhe da informação. O roll up (ou drill 
up) é o contrário. Ele ocorre quando o usuário agrupa os dados, diminuindo o nível de 
detalhamento da informação; (ii) slice e dice - o slice é quando um membro em 
particular de uma dimensão é selecionado, formando uma espécie de “fatia” (slice) do 
cubo original. O dice seleciona vários membros de várias dimensões formando um sub-
cubo. Tanto o slice quanto o dice são formas particulares de filtro; e (iii) pivot - é o 
ângulo pelo qual os dados são visualizados. Permite a troca de linhas por colunas em 
uma tabela ou modificação da posição das dimensões em um gráfico. 
 A aplicação dessas operações (visões) sobre um modelo multidimensional cria 
uma visão no formato cubo, conhecida como Decision Cube (BARBALHO, 2003). 
3. Solução Implementada 
O objetivo deste trabalho foi desenvolver uma solução de BI, que apóie a tomada de 
decisão de diretores e gerentes da empresa NeoGrid, através da visualização de 
relatórios e KPIs, manipulando fatos, medidas e dimensões. O foco é o desenvolvimento 
de um DW, composto por cubos OLAP e o acesso a relatórios via Web. 
 Segundo Turban et. al (2009), os fatores essenciais para que um projeto deste 
porte seja bem-sucedido são: (i) definir claramente os objetivos, (ii) reunir apoio ao 
projeto junto à gerência, (iii) estabelecer cronogramas e orçamentos; e (iv) administrar 
as expectativas. 
 O desenvolvimento desta solução utiliza como metodologia os passos (fases) 
propostos por Barbieri (2001) para a implementação de um sistema de BI: (i) 
planejamento, (ii) levantamento das necessidades, (iii) modelagem dimensional, (iv) 
projeto físico dos bancos de dados, (v) projeto de ETL, (vi) desenvolvimento de 
aplicações, (vii) teste e homologação, (viii) treinamento e (ix) implantação. As próximas 
seções irão apresentar cada um destes passos, de forma detalhada. 
3.1 Planejamento 
Na etapa de planejamento o escopo do projeto deve ser definido, sempre mantendo o 
foco no negócio. Deve-se atentar para as áreas mais críticase que possuem necessidades 
mais abrangentes de informações gerenciais (BARBIERI, 2001). 
 Nesta etapa, também deve ser definida a arquitetura e o tipo de implementação 
que deverão ser utilizados para a construção do DW. Neste momento foi definida uma 
arquitetura do tipo “Data Warehouse Empresarial”, sendo implementada utilizando 
técnicas combinadas (“top down” e “bottom up”). Com relação ao mecanismo de 
processamento de consultas, utilizou-se um servidor de banco de dados 
multidimensional (MOLAP), devido ao seu melhor desempenho e a um conjunto rico e 
complexo de funções de análise (CARVALHO, 2003). 
 Assim, definiu-se o foco deste projeto, que são os dados de desempenho 
financeiro e estratégico da aplicação Mercador (www.mercador.com), solução de EDI 
(Electronic Data Interchange) que é o produto de maior faturamento da NeoGrid. 
 
 Depois de definido o escopo do projeto, foi realizada uma análise prévia com o 
intuito de identificar as principais métricas e dimensões. Posteriormente, foi realizada 
uma análise da visão macro, para verificar como os projetos futuros serão integrados ao 
projeto inicial. A modelagem foi desenvolvida de modo a garantir que ela possa ser 
aproveitada em outros DMs da empresa. 
 Outro fator importante para o sucesso da implantação do BI é a definição da 
arquitetura tecnológica. A arquitetura deve ser definida durante o planejamento, pois 
características de desempenho e disponibilidade irão definir níveis de serviço e graus de 
compromissos variados (BARBIERI, 2001). Os componentes básicos desta definição 
compreendem: (i) sistema gerenciador de banco de dados, (ii) ferramentas de 
desenvolvimento de sistemas OLAP, (iii) ferramentas para processos ETL (com 
mecanismos para transferência de dados entre ambientes heterogêneos) e (iv) um 
visualizador de relatórios (de preferência que as informações possam ser visualizadas 
através da Web) (BARBIERI, 2001). 
 A arquitetura escolhida para este projeto foi a da plataforma Microsoft, que além 
de possuir todos os requisitos de desempenho e escalabilidade, é a arquitetura de BI 
mais utilizada (The OLAP Report, 2009). Além disso, a NeoGrid já trabalha há mais de 
10 anos com a plataforma SQL Server, além de ser uma empresa parceira (Microsoft 
Partner Gold) da Microsoft. 
 Ao concluir o planejamento foi realizado o levantamento das necessidades do DW 
relacionado aos setores financeiro e estratégico, conforme descreve a próxima seção. 
3.2 Levantamento de necessidades 
A etapa de levantamento de necessidades é uma das mais importantes, pois nesta fase é 
possível identificar e priorizar as necessidades de informação que a organização 
necessita. É importante o envolvimento de analistas de sistemas, usuários, equipe de 
tecnologia da informação e DBAs durante esta fase (BARBIERI, 2001). 
 Diferente do desenvolvimento de sistemas tradicionais, o ciclo de 
desenvolvimento de um DW inicia pela análise dos dados. Esta primeira análise da base 
de dados transacional, permite que o analista obtenha um melhor entendimento das 
necessidades e limitações do projeto, pois o DW é um grande repositório de dados 
originados destes sistemas (KIMBALL, 2002). 
 Barbieri (2001) destaca dois modelos que devem ser utilizados durante o 
levantamento de necessidades: (i) o modelo Fonte das Informações, que representa quais 
informações e análises são esperadas pelos usuários do sistema; e o (ii) modelo Fonte 
dos Dados, que representa as fontes de informações e o destino delas no modelo 
dimensional. O objetivo destes modelos não é o de definir e modelar fatos, dimensões e 
tabelas auxiliares, porque o foco está nos requisitos levantados. 
 A documentação gerada durante esta fase é baseada na solução proposta por 
Scheeren (2009), que utiliza a UML (Unified Modeling Language) para auxiliar a 
modelagem de DWs. 
 Após algumas entrevistas com os usuários, foi detectada a necessidade de análise 
do faturamento e do tráfego de documentos da aplicação Mercador, que permitisse aos 
gestores uma visão estratégica. Conforme proposto por Scheeren (2009), o modelo 
 
Fonte das Informações, que descreve as necessidades levantadas pelos usuários, é 
representado por um diagrama de caso de uso, que apresenta graficamente a 
especificação do projeto. 
 Após a definição do escopo (faturamento e tráfego de documentos), foram 
identificados os requisitos do projeto, relacionando os tipos de análises necessárias 
pelos usuários (gestores). O Apêndice A ilustra os diagramas de casos de uso, 
relacionados, respectivamente, ao escopo de faturamento e de tráfego de documentos. 
 Além das entrevistas com os usuários, outra fonte que auxiliou o levantamento de 
dados foram os relatórios gerenciais. Alguns scripts SQL, que são executados 
mensalmente pelo DBA, também foram analisados. Os resultados destas consultas são 
inseridos em planilhas eletrônicas e enviados aos gestores. Desse modo, estas consultas 
permitiram uma análise prévia, que possibilitou identificar o foco inicial do projeto. 
 Independente do fato que está sendo criado, ele sempre possui no mínimo quatro 
elementos (MACHADO, 2004): (i) onde aconteceu o fato; (ii) quando aconteceu o fato; 
(iii) quem executou o fato; e (iv) o que é o objeto do fato. Com base nestes elementos, 
Machado (2004) propõe a utilização de quatro pontos cardeais para facilitar a descoberta 
de informações (modelo Fonte dos Dados) levantadas pelo modelo anterior. Estes 
pontos cardeais são definidos pelas seguintes perguntas: “Onde?”, “Quando?”, “Quem?” 
e “O quê?”. 
 Para o modelo Fonte dos dados, que representa a fonte das informações, Scheeren 
(2009) também propõe a especificação através da utilização de casos de uso. Neste 
modelo, sistemas de origem e destino são representados por atores. Para definir o que 
representa cada ator, Scheeren (2009) criou os seguintes estereótipos: <<st>> para 
sistema transacional; <<ad>> para arquivo de dados e <<md>> para modelo 
dimensional. Para os pontos cardeais propostos por Machado (2004), Scheeren (2009) 
definiu os seguintes estereótipos para os casos de uso: <<onde?>>, <<quando?>>, 
<<quem?>> e <<o quê?>>. No Apêndice B encontram-se os modelos Fonte dos Dados 
das necessidades levantadas nos modelos anteriores (Apêndice A). 
 Inicialmente, os usuários propuseram uma solução de data warehouse ativo 
(tempo real), porém este tipo de solução pode gerar diferentes resultados dependendo do 
momento em que o relatório será gerado. Por este motivo, ficou definido que as cargas 
devem ser geradas diariamente. 
 Outro requisito necessário é que a solução deve estar operando no modelo 24x7, 
com um acordo de nível de serviço (Service Level Agreement - SLA) de 99,5% de 
disponibilidade. Todo o hardware e software do servidor é monitorado, pois caso ocorra 
alguma falha ou instabilidade no sistema o responsável pelo suporte será acionado. 
 Após a finalização do levantamento das necessidades, foi iniciada a modelagem 
dimensional do DW, conforme apresentada na próxima seção. 
3.3 Modelagem Dimensional 
A etapa de modelagem dimensional é considerada uma das mais importantes e é um dos 
fatores críticos de sucesso em um projeto de DW. Ela possibilita que o usuário obtenha 
as informações em uma forma muito próxima do seu entendimento, com várias 
perspectivas possíveis. A normalização e a não redundância são dispensadas na 
 
modelagem dimensional, com o intuito de se obter estruturas mais ágeis. Tabelas que 
poderão conter milhares de registros, com muitos gigabytes, ou até mesmo alguns 
terabytes de dados, são manipuladas (BARBIERI, 2001). 
 A modelagem dimensional produz um modelo conceitual dimensional, formado 
por tabelas Fato e tabelas Dimensão. Para auxiliar a modelagem, Scheeren (2009) 
sugere a utilização de diagramas de classes. 
 Segundo Italiano e Esteves (2004b), a etapa de modelagem dimensional é 
composta por alguns passos, cujo objetivoé representar as necessidades de análise e de 
informações do usuário: 
• definir fatos e métricas – neste passo é definido o que deve ser avaliado no 
DW. Definida a área de negócios que está sendo modelada, deve ser respondida 
a seguinte questão: “O que estamos avaliando?”. A resposta desta pergunta é a 
lista de fatos. Com isso, foi possível identificar dois fatos: Faturamento e 
Tráfego de Documentos. Depois de encontrar os fatos, foram identificadas as 
métricas para cada fato; 
• definir as dimensões de negócios – após a identificação dos fatos e métricas 
que serão armazenados no DW, são definidas as dimensões relacionadas às 
métricas, que serão utilizadas para a avaliação dos fatos. A questão deste passo 
é: “Como as métricas serão analisadas?”; 
• definir a granularidade das informações em cada dimensão – após a definição 
das dimensões de negócio, deve ser definido o nível de detalhe (granularidade) 
mais baixo que será avaliado. O seguinte questionamento deve ser realizado ao 
usuário: “Qual o nível de detalhe desejado?”. Para o fato Faturamento a 
granularidade é mensal, para o fato Tráfego é diária; 
• definir a hierarquia de agrupamento das informações – é necessário definir as 
possibilidades de agrupamento (sumarização) das informações desejadas pelo 
usuário, especificando estes agrupamentos em cada uma das dimensões de 
negócio. Este passo deve responder a seguinte questão: “Como se espera 
agrupar ou sumarizar as informações?”. A dimensão tempo do fato Tráfego 
possui a seguinte hierarquia: Ano � Semestre � Trimestre � Mês � Dia. 
Para o fato Faturamento, a dimensão tempo possui a hierarquia a seguir: Ano 
� Semestre � Trimestre � Mês. 
 Após a identificação de todos os elementos necessários para a modelagem, através 
de entrevistas e análise dos modelos Fonte das Informações, Fonte dos Dados e 
Entidade-Relacionamento, foram definidos os modelos esquematizados pela Figura 1. 
 
 
 
Figura 1: Modelos Dimensionais Faturamento e Tráfego. 
 Conforme ilustrado na Figura 1, todos os fatos foram modelados utilizando o 
esquema estrela, proposto por Kimball (2002). Além de ser o esquema de modelagem 
mais conhecido e utilizado em bases de dados de suporte à decisão (MACHADO, 
2004), ele possui excelente desempenho nas consultas, pois reduz o número de joins. 
Outra vantagem do esquema estrela é a facilidade com que o usuário não técnico 
consegue visualizar as análises do negócio (MACHADO, 2004). 
 Optou-se pela criação de um DM para cada aplicação da organização NeoGrid. 
Por esse motivo, estes dois fatos serão armazenados em apenas um DM. 
 Um importante atributo da tabela Dimensão é a sua chave primária. Por questões 
de desempenho, não serão utilizadas chaves compostas ou concatenadas. Para cada 
tabela Dimensão foi definido que sua chave primária será um número inteiro atribuído 
seqüencialmente. Kimball (2002) sugere que sejam utilizadas chaves genéricas 
(artificiais), também chamadas de surrogate keys. Um dos principais motivos para a 
criação de chaves genéricas é que o DW, por manter as informações históricas, não pode 
ficar vulnerável a problemas de duplicação de chaves durante novas cargas de dados. 
Outra importante razão para o uso de chaves genéricas, é que em caso de alterações de 
atributos nos sistemas transacionais, as chaves genéricas serão a base para se manter o 
histórico destas alterações no DW. 
 A tabela Fato será composta por métricas e chaves para cada uma das dimensões. 
A chave primária da tabela Fato será composta por atributos que correspondem a chaves 
estrangeiras, satisfazendo as restrições impostas pela integridade de entidade 
(obrigatoriedade e unicidade da chave primária) e pela integridade referencial. 
 A finalização da modelagem dimensional é a condição necessária para iniciar o 
projeto físico do banco de dados, conforme apresenta a próxima seção. 
3.4 Projeto Físico dos Bancos de Dados 
Nesta etapa são definidas as estruturas lógicas do modelo dimensional, ou seja, são 
definidas as tabelas fato e de dimensões, os seus relacionamentos, os índices, os 
atributos e as regras de tabelas (BARBIERI, 2001). 
 
 Para a modelagem dimensional foi utilizada a ferramenta ERwin Data Modeler. 
Após a modelagem, a ferramenta permitiu a geração automática de um script SQL com 
a criação de todos os objetos do banco de dados (tabelas, índices, constraints) do DM. 
 A partir da modelagem realizada percebeu-se a necessidade de definir dois fatos, 
um para cada escopo mapeado, e para cada fato, foram definidas dimensões relacionadas 
com ele. O Apêndice C esquematiza, respectivamente, os modelos Entidade-
Relacionamento (ER) dos dois fatos propostos (Faturamento e Tráfego). 
 A solução será implantada no data center de Joinville, onde será integrado ao 
SharePoint Server, permitindo acesso Web (interno e externo) aos relatórios. 
 O SQL Server cria automaticamente índices cluster para todas as chaves 
primárias (Primary Keys – PKs) das tabelas. Os índices não-cluster foram criados para 
as tabelas de dimensões que possuem campos de data e CNPJ. Durante a fase de 
homologação, foram gerados testes de carga, que permitiram avaliar o desempenho das 
consultas, percebendo-se a necessidade da criação de novos índices. 
3.5 Projeto de ETL 
Componente essencial de qualquer projeto centrado em dados, as tecnologias de 
extração, transformação e carga (ETL) são consideradas o “coração” da parte técnica do 
processo de data warehousing (TURBAN et. al, 2009). Durante esta etapa são definidos 
os processos necessários para transformar o modelo Fonte em um modelo Dimensional 
(BARBIERI, 2001). Esta etapa é um grande desafio para os gestores de TI, pois os 
processos de ETL costumam consumir cerca de 70% do tempo de um projeto 
(TURBAN et. al, 2009). 
 Conforme apresentado no Trabalho de Conclusão de Curso I, durante este 
projeto foi utilizada a ferramenta Integration Services, que faz parte do pacote SQL 
Server. O Integration Services é a ferramenta de ETL da solução de BI da Microsoft. Ela 
permite desenvolver graficamente todo o fluxo do processo (Figura 2). Além de facilitar 
o desenvolvimento, permite uma melhor compreensão do processo, tornando menos 
complexas as futuras manutenções. 
 
Figura 2: Processo ETL do Fato Tráfego. 
 Todos os dados foram importados dos servidores de bancos de dados de 
produção (3 servidores SQL Server 2008). Não foi necessária a importação de arquivos 
ou de qualquer outro tipo de estrutura de armazenamento. 
 O primeiro passo foi desenvolver os processos de ETL das dimensões e, 
posteriormente, os processos dos fatos. A tabela de fatos referencia as tabelas de 
dimensões através de chaves estrangeiras e por este motivo deve sempre ser a última 
tabela a ser atualizada durante o processo de ETL (integridade referencial). 
 
 No desenvolvimento dos pacotes ETL, foram utilizados componentes para 
conexões a bancos de dados (OLE DB), execução de scripts SQL e captura de alterações 
nas fontes de dados. 
 Na dimensão LOCALIZACAO_REMETENTE, os dados de CNPJ e razão social 
são monitorados na base transacional. Caso algum destes valores seja alterado, o 
processo realiza a atualização destes no DW. A Figura 3 apresenta a execução do ETL 
da dimensão LOCALIZACAO_REMETENTE. Foram analisados 105.404 registros, 
atualizados 647 membros e incluídos 10.529 novos registros na dimensão. 
 
Figura 3: Subprocesso responsável pela dimensão LOCALIZACAO_REMETENTE. 
 Esta etapa do projeto gerou dois pacotes de software, com dois grandes 
processos ETL , um para cada fato. Nenhuma informação foi sumarizada neste processo. 
A tabela do fato Tráfego, por exemplo, possui um registro para cada registro na tabela 
fonte. 
 Finalizado o desenvolvimento dos processos de extração, transformação e carga 
das dimensões e fatos, foram criadas duas rotinas (uma para cada fato) responsáveis pelaexecução dos processos ETL e processamento dos cubos (nesta ordem). Todos os 
processos de ETL são executados no servidor onde está armazenado o DW. Finalizado o 
projeto de ETL do DW, iniciou-se o desenvolvimento dos cubos, como apresenta a 
próxima seção. 
3.6 Desenvolvimento de Aplicações 
Após adquirir dados e informações de diversas fontes e organizá-los em um data 
warehouse, iniciou-se o desenvolvimento da solução de análise de negócios. 
 A análise de negócios é um conjunto de ferramentas e técnicas que permitem 
reunir, armazenar, analisar e fornecer acesso aos dados, com o objetivo de ajudar os 
usuários a tomarem melhores decisões comerciais e estratégicas (TURBAN et. al, 
2009). Para realizar a análise de negócios foram desenvolvidos os seguintes recursos: (i) 
geração de cubos OLAP para permitir consultas analíticas com visões 
multidimensionais; (ii) relatórios na Web pré-formatados com as consultas mais 
utilizadas; e (iii) consultas e análise ad hoc. 
 O primeiro passo nesta etapa foi iniciar o desenvolvimento dos dois cubos 
(sendo que, cada fato gerou um cubo). Através do Analysis Services (ferramenta para 
desenvolvimento OLAP da Microsoft), foram definidas as tabelas fato e suas dimensões 
(Figura 4). A linguagem utilizada foi a MDX (Multidimensional Expressions), 
linguagem criada pela Microsoft e que hoje é utilizada na maioria das ferramentas 
OLAP. Esta linguagem é uma extensão do SQL, que permite acesso às múltiplas 
dimensões. 
 
 
 
Figura 4: Cubo Tráfego no Analysis Services. 
 Com a estrutura básica do cubo projetada, foram definidas as métricas e as 
agregações necessárias. Para cada dimensão, foram definidos os atributos que serão 
visualizados pelos usuários, e também, criadas as suas hierarquias. 
 A tabela da dimensão TEMPO não precisou ser preenchida manualmente. O 
Analysis Services possui um wizard para a criação de dimensões do tipo TEMPO. Após 
definir as datas inicial e final necessárias, foi gerado um script para a carga desta tabela. 
A hierarquia da dimensão TEMPO é apresentada na Figura 5. 
 
Figura 5: Hierarquia da dimensão TEMPO. 
 Durante o desenvolvimento dos cubos, também foram definidos e ajustados os 
labels dos fatos, métricas, atributos e dimensões, além da ordem de visualização das 
informações. Assim, estes objetos são visualizados pelo usuário final com nomes mais 
significativos do ponto de vista do usuário (Figura 6). 
 
Figura 6: Atributos do usuário, hierarquia e tabela da dimensão REGIÃO_REMETENTE. 
 Inicialmente, os dados do fato Tráfego (agora cubo Tráfego) seriam agrupados 
por dia (uma única entrada com o total e tamanho total dos documentos trafegados por 
parceiros comerciais durante o dia). Porém, durante o desenvolvimento, os usuários 
perceberam que poderiam utilizar as consultas para gerar extratos analíticos do tráfego 
dos clientes. Este processo geralmente gera uma carga excessiva no banco de dados 
transacional, além de ser realizado apenas pelo DBA através de scripts SQL. 
 
 Após finalizar os cubos, foi projetada a visualização dos dados. Ela torna as 
aplicações de suporte à decisão mais atraentes e compreensíveis aos usuários, 
permitindo uma melhor interpretação dos dados. As ferramentas visuais podem ajudar a 
identificar relações, como por exemplo, tendências. 
 A visualização de análise de negócio através da Web facilita o seu uso, pois não 
é necessária a instalação de nenhum software adicional (sem falar nas atualizações de 
versões). Assim, foi criada uma série de relatórios (utilizando a ferramenta Microsoft 
Reporting Services), integrados à Intranet da corporação (Microsoft SharePoint), que 
permitem aos usuários de nível de conhecimento (administradores de nível médio - 
decisões táticas) a obtenção de relatórios e realizar análises destes. Um primeiro 
exemplo foi a criação de um relatório que permitiu a análise do volume de documentos 
trafegados (Figura 7), e um dashboard (Figura 8) que possibilitou um melhor 
acompanhamento do faturamento da empresa. 
 
Figura 7: Relatório através da Web. 
 
Figura 8: Dashboard do faturamento através da Web. 
 Embora a interface Web seja fácil de utilizar, ela possui algumas limitações. 
Todos os relatórios são pré-formatos, permitindo uma manipulação limitada das 
 
dimensões. Apesar de o projeto priorizar o uso da Web, para o caso de análises mais 
sofisticadas, são necessárias algumas ferramentas específicas, que incorporam, 
inclusive, métodos e práticas diferentes (BARBIERI, 2001). Para isso, percebe-se a 
necessidade de utilizar alguma ferramenta que conecte a base multidimensional e 
permita análises de negócios mais avançadas. 
 As planilhas são as principais ferramentas do usuário final para a programação 
de aplicações de suporte à decisão (TURBAN et. al, 2009). Neste contexto, o Microsoft 
Excel tem sido amplamente adotado como uma ferramenta eficiente e fácil de usar para 
a manipulação de dados. Ele evoluiu para além de uma simples ferramenta para cálculo 
de dados, ao ponto de agora ser usado como uma ferramenta sofisticada e flexível para 
coleta, análise e sintetização de dados de múltiplas fontes. 
 Por estes motivos, o Excel é uma ferramenta que se integra às principais 
soluções de BI do mercado. Sua principal função é como ferramenta de visualização de 
dados com acesso a cubos. Empresas como Microsoft, SAP, MicroStrategy e até mesmo 
a Oracle, disponibilizam plugins para que o Excel conecte aos seus cubos. 
 Como é uma ferramenta amplamente utilizada na NeoGrid, o Excel será a 
ferramenta que será conectada aos cubos e permitir que os diretores da empresa 
(administradores de nível superior - decisões estratégicas), possam realizar análises mais 
avançadas (Figura 9). 
 
Figura 9: Acesso aos cubos através do Excel. 
 Durante o desenvolvimento da aplicação, surgiu a oportunidade de realizar um 
teste em “produção”, e verificar a eficiência da solução. O faturamento, referente à 
aplicação Mercador, do mês de outubro havia diminuído comparado com o mês de 
setembro. Depois de realizada a carga dos dados de produção, foi possível analisar os 
relatórios e estabelecer alguns relacionamentos. Ao contrário do que se pensava, o 
aumento no volume de documentos trafegados não aumenta proporcionalmente o 
faturamento (o que deixou diretores e gerentes preocupados). 
 Com os relatórios gerados (Figura 10), foi possível analisar o faturamento dos 
“Top 400” clientes ao longo dos últimos 6 meses. Analisando o faturamento dos meses 
anteriores, foi identificado um erro operacional nas tabelas de preço e de cobrança. 
 
Como a descoberta da informação foi rápida, após algumas correções, foi possível gerar 
as faturas novamente, sem gerar perdas para a NeoGrid. Até o presente momento, não 
existiam maneiras de comparar (ou relacionar) o faturamento ou tráfego de documentos 
ao longo do tempo. O último relatório deste tipo havia levado mais de dois meses para 
ser finalizado. 
 
Figura 10: Relatório de utilização do portal Mercador. 
3.7 Teste e Homologação 
Finalizado o desenvolvimento, a aplicação foi instalada no ambiente alpha (ambiente 
para produtos em fase de testes, sem acesso aos usuários finais) e entregue à equipe de 
testes para realizar o processo de verificação. 
 Durante os testes de processamento dos cubos, foram detectadas algumas 
“anomalias” nos dados de produção, como, por exemplo, empresas cadastradas mais de 
uma vez (foram encontradas empresas com até 10 cadastros). O processamento dos 
cubos gerava erro, pois a razão social da empresa é um dos atributos das dimensões de 
LOCALIZACAO e ORGANIZACAO. O erro era causado pela duplicação de membros 
do atributo. A solução foi desenvolver mais um passo no processo ETL para limpar 
estas informações, onde foi adicionado o CNPJ da empresa à razão social. 
 Terminado o processo de verificação (e após algumascorreções de problemas 
detectados nos testes), o sistema foi implantado no ambiente de homologação (processo 
de validação). Este foi o último passo antes da implantação do sistema no ambiente de 
produção. A equipe de homologação realizou simulações de volume e de processamento 
para avaliar o impacto da solução na produção. Foi validado também, o pacote de 
instalação da solução. 
3.8 Treinamento 
Após a entrega do projeto à equipe de homologação, foi realizado um workshop sobre a 
solução. Participaram deste encontro o diretor da solução de EDI, o gerente da equipe de 
implantação EDI e alguns colaboradores da equipe de atendimento ao cliente. O 
principal objetivo foi apresentar a solução para estimular os usuários finais a 
participarem do processo de validação (homologação). 
 
 A participação dos usuários neste processo, além de garantir uma melhor 
qualidade na entrega do projeto, possibilitou alguns ajustes (ex.: ajuste de layout de 
alguns relatórios, campos de texto livre que foram alterados para combos, etc.) antes de 
entrar em produção. 
3.9 Implantação 
Com o produto homologado, foi iniciada a etapa de implantação do sistema no ambiente 
de produção. 
 Foi selecionado, para hospedar a solução, o servidor SQL Server responsável 
pelos sistemas internos da NeoGrid (que está hospedado em um data center diferente do 
sistema transacional). Este servidor possui um sistema operacional Windows 2003 
Enterprise 64 bits em conjunto com SQL Server 2008 Enterprise 64 bits. 
 Este servidor está em cluster failover (1 nó ativo + 1 nó passivo). O cluster SQL 
Server já possuía rotinas de manutenção e backups (em fita), não sendo necessário a 
criação de novas rotinas (jobs). 
 Com os serviços necessários instalados, foram criados monitores para verificar 
espaço em disco, utilização de hardware (CPU, disco, memória), número de transações 
por segundo, número de usuários conectados, além de verificar se os serviços estão 
ativos. Com isso, pode-se gerar relatórios para calcular a disponibilidade do sistema, 
além de realizar planejamento de capacidade. 
 Após a disponibilização da infra-estrutura necessária, todos os pacotes ETL, 
cubos e relatórios foram publicados. Os processos ETL terão acesso aos bancos de 
dados de produção (base transacional) através de um VPN (Virtual Private Network) 
estabelecida entre os dois data centers (20Mb/s). 
4. Conclusões 
Alguns fatores foram importantes para o sucesso deste projeto, como: (i) a obtenção de 
um patrocinador executivo, que facilitou o envolvimento de equipes e a liberação de 
recursos; (ii) a lembrança constante de que o objetivo é aumentar a produtividade do 
usuário; (iii) a participação dos usuários um fator crítico para o sucesso do projeto; (iv) 
o envolvimento tanto de profissionais de TI, quanto analistas de negócios no projeto; e 
(v) a atenção que deve ser dedicada às etapas de levantamento de necessidades e 
modelagem dimensional. 
 A solução continuará evoluindo com novos dashboards e incluíndo outros 
produtos da NeoGrid, como a Nota Fiscal Eletrônica (NF-e). 
 
Referências 
Ballard, C., Farrell, D., Gupta, A., Mazuela, C. e Vohnic, S. (2006), Dimensional 
Modeling: In a Business Intelligence Environment, IBM, 645 p. 
Barbalho, P. (2003), “Descubra o Data Warehouse: produtividade e rapidez”, SQL 
Magazine, Rio de Janeiro, n. 03, p. 34-38. 
Barbieri, C. (2001), Business Intelligence: Modelagem e Tecnologia, Axcel Books, 
424p. 
Carvalho, B. (2003), “Arquitetura de ferramentas OLAP”, SQL Magazine, Rio de 
Janeiro. 09, p. 12-16. 
Delaney, K. e Agarwal, S. (2006), Practical Business Intelligence with SQL Server 
2005, Addison-Wesley Professional, 432 p. 
Inmon, W. H. (2005), Building the Data Warehouse, Wiley, 576 p. 
Italiano, I. C. e Esteves, L. A. (2004a), “Modelagem de Data Warehouses e Data Marts 
– Parte 1”, SQL Magazine, Rio de Janeiro, n. 13, p. 42-45. 
Italiano, I. C. e Esteves, L. A. (2004b), “Modelagem de Data Warehouses e Data Marts 
– Parte 2”, SQL Magazine, Rio de Janeiro, n. 14, p. 37-43. 
Jacobson, R. e Misner, S. (2007), Microsoft SQL Server Server 2005: Analysis 
Services, Microsoft Press, 340 p. 
Kimball, R. (2002), The Data Warehouse Toolkit, Wiley, 464 p. 
Langit, L. (2008), Foundations of SQL Server 2005: Business Intelligence, Apress, 396 
p. 
Larson, B. e Agarwal, S. (2006), Delivering Business Intelligence with Microsoft SQL 
Server 2005, McGraw-Hill, 792 p. 
Machado, F. N. (2004), Tecnologia e Projeto de Data Warehouse, Érica, 318 p. 
Reis, E., Teixeira, F. e Araújo, M. A. (2009), “Implementando uma solução de Business 
Intelligence com o Microsoft SQL Server 2005 – Parte 1”, SQL Magazine, Rio de 
Janeiro, n. 59, p. 52-66. 
Scheeren, J. (2009), “Modelagem Visual de Data Warehouses e Data Marts”, Trabalho 
de Conclusão de Curso (Graduação em Sistemas de Informação), Centro 
Universitário Ritter dos Reis, Porto Alegre. 
The OLAP Report (2009), “OLAP market share analysis”, 
http://www.olapreport.com/market.htm, Junho. 
Turban, E., Sharda, R., Aronson, J. e King, D. (2009), Business Intelligence: um 
enfoque gerencial para a inteligência do negócio, Artmed, 254 p. 
Turley, P., Kasprzak, J. e Cameron, S. (2007), Microsoft SQL Server Server 2005: 
Integration Services, Microsoft Press, 453 p. 
 
Apêndices 
Apêndice A – Modelos Fonte das Informações Faturamento e Tráfego 
 
 
 
 
 
Apêndice B – Modelos Fonte dos Dados Faturamento e Tráfego 
 
 
 
 
 
 
 
Apêndice C - Modelos ER dos Fatos Faturamento e Tráfego