FACULDADES SANTO AGOSTINHHO DE MONTES CLAROS

CENTRO CIENCIAS EXATAS E TECNOLOGICAS

CURSO DE SISTEMAS DE INFORMAÇÃO

(BACHARELADO)

SISTEMA DE BUSINESS INTELLIGENCE

TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO ÀS FACULDADES

SANTO AGOSTINHO DE MONTES CLAROS, PARA OBTENÇÃO DOS
CRÉDITOS NA DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE
SISTEMAS DE INFORMAÇÃO – BACHARELADO.

MARCOS RODRIGO

JEREMIAS SOARES

PABLO HERIQUE

MONTES CLAROS, MARÇO/2011.

AGRADECIMENTOS
 LISTA DE FIGURAS

Figura 1 - Componentes de um ambiente de BI..................................................7

Figura 2 - Composição básica de uma tabela de fatos........................................9

Figura 3 - Níveis de granularidade.....................................................................11

Figura 4 - Exemplo de um esquema em estrela................................................15

Fiigura 5 - Exemplo do conceito de cubo...........................................................17

Figura 6 - Representação de um Data Mart de vendas.....................................18

 LISTA DE ABREVIATURAS E SIGLAS

BI – Business Intelligence (Inteligência de Negócios)

SAD - Sistemas de apoio à decisão é uma classe de Sistemas de Informação

ou Sistemas baseados em Conhecimento.

ERP – Enterprise Resource Planning (Sistema de Gestão Integrada)

OLAP – On-line Analytical Processing (Processo analítico on-line) é a

capacidade para manipular e analisar um grande volume de dados sob
múltiplas perspectivas.

OLTP – On-line Transaction Processing (Processo transacional on-line) São

sistemas que se encarregam de registrar todas as transações contidas em uma
determinada operação organizacional.

SIG – Sistema de Informação Gerencial

ETL – Extraction / Transformation /Load (Extração/Transformação/Carga).

DW – Data Warehouse significa armazém de dados, ou depósito de dados.

DM – Data Marts significa armazém de dados é subconjunto de dados de um

data warehouse.

BD – Banco da Dados, são conjuntos de registros dispostos em estrutura

regular que possibilita a reorganização dos mesmos e produção de
informação. Um banco de dados normalmente agrupa registros utilizáveis para
um mesmo fim.

KPI – Key perfomance indicator, significa indicador chave de desempenho.

DASHBOARD – é um painel de indicadores.

PENTAHO – Suíte de aplicativos para BI.

LISTA DE TABELAS
LISTA DE ANEXOS

SUMÁRIO
1. RESUMO

2. ABSTRACT

3. INTRODUÇÃO

Num cenário onde a informação é o bem mais valioso e competitivo para

uma organização, os softwares de Business Intelligence se tornam uma das
maneiras mais eficazes de transformar dados de diversas fontes em
informações que auxiliem o apoio a tomada de decisões gerenciais. E é dentro
deste cenário hipercompetitivo que precisamos de muito mais de uma simples
informação.
Cada vez mais é necessário ter em mãos informações qualificadas que
realmente gerem valor. As informações disponibilizadas pelos aplicativos de
Business Intelligence são de extrema importância para auxiliar e formatar
ações, que vão desde o desenvolvimento de promoções dirigidas aos
diferentes perfis de clientes, até adequações dos procedimentos adotados por
áreas como as de atendimento e engenharia.
Estudos mundiais da IDC mostram que 56% das organizações possuem
de 2 a 9 sistemas de fontes de dados, e 20% possuem de 10 a 24. Esta
volumosa movimentação de dados atrelada ao encurtamento dos ciclos de
tomada de decisão traz consigo alguns desafios, e o primeiro deles dizem
respeito à complexidade em disponibilizar informações precisas e relevantes,
no tempo certo para as pessoas certas (COMPUTERWORD,2009).
A escolha de uma ferramenta de Business Intelligence veio com a
necessidade de cruzar e analisar informações de vendas, rotas de vendas,
clientes e vendedores para realizar uma gestão empresarial eficiente. A
Pentaho foi a ferramenta escolhida por ter sua versão community edition e por
possuir bastantes recursos.
O software Pentaho é uma plataforma para criação de soluções de
Business Intelligence (BI), que inclui recursos de geração de relatórios,
integração e armazém de dados (datawarehousing), análise de informações
(OLAP), painéis (dashhoards) para controle gerencial e mineração de dados
(Data Mining).
Para João Lucio (2009), as organizações têm usado os dados de suas
bases operacionais para atender as suas necessidades de informações desde
tempos passados. Nesta situação, além da dificuldade de encontrá-los,
diversas vezes, dados inconsistentes são utilizados como base para tomada de
decisões importantes.
É aí que a Tecnologia de Informação assume um papel de grande
importância ao permitir de forma rápida e simples a manipulação das
informações necessárias ao gerenciamento integrado dos negócios. O
interesse pelo Business Intelligence (BI) vem crescendo na medida em que seu
emprego possibilita às corporações realizar uma série de análises e projeções,
de forma a agilizar os processos relacionados às tomadas de decisão.

4. JUSTIFICATIVA

Tornar o processo de tomada de decisões mais rápido e prático, a fim de

produzir uma gestão mais dinâmica e eficiente.

5. TEMA

Utilização de BI na tomada de decisão gerencial para redução de custos

em uma empresa de Lubrificantes utilizando a ferramenta Pentaho.

6. PROBLEMA

É possível gerar informações do processo de vendas de uma empresa

de Lubrificantes visando a tomada de decisão gerencial e redução de custos
utilizando Business Intelligence?

7. OBJETIVO

O objetivo deste trabalho é criar uma solução de inteligência de negócios

para uma empresa do ramo de lubrificantes visando otimizar o fluxo de
informações para melhorar a tomada de decisão e oferecer dados estratégicos
para análise com um mínimo de atraso em relação a uma transação ou evento
dentro da empresa.
8. ESPECÍFICOS

• Apresentação da ferramenta de business intelligence Pentaho.

• Projeto de desenvolvimento de business intelligence para empresa de

Lotemoc Lubrificantes.

• Desenvolvimento de recursos analíticos, dashboards, cubos, para

realização de analises gerenciais inteligentes através do sistema de
business intelligence Pentaho.

9. CONTEXTUALIZAÇÃO DA EMPRESA

jeremias

10. REFERENCIAL TEÓRICO

10.1. BANCO DE DADOS

10.2. ENGENHARIA DE SOFTWARE

10.3. SISTEMAS DE INFORMAÇÃO

Para Laudon (2002), um sistema de informação (S.I.) pode ser definido

como um conjunto de componentes inter-relacionados trabalhando juntos para
coletar, recuperar, processar, armazenar e distribuir informação com a
finalidade de facilitar o planejamento, o controle, a coordenação, a análise e o
processo decisório em empresas e outras organizações.

10.4. SISTEMAS DE BUSINESS INTELIGENCE (SISTEMAS DE

APOIO A DECISÃO - SAD)

De acordo com Heinrichs e Lim (2003), para competir no mercado global

de hoje, as empresas precisam deter mais conhecimento do que antigamente
e, ainda, para obter sucesso, elas precisam saber mais sobre seus clientes,
mercados, tecnologias e processos, e precisam ter essas informações antes
que seus concorrentes.
 Segundo Barbieri (2001), BI representa a habilidade de se estruturar,
acessar e explorar informações, normalmente guardadas em DW/DM (Data
Warehouse / Data Mart), com o objetivo de desenvolver percepções,
entendimentos, conhecimentos, os quais podem produzir um melhor processo
de tomada de decisão.

Shim et al. (2002) dizem que os SAD são soluções computacionais

desenvolvidas para apoiar a tomada de decisões complexas durante a
resolução de problemas. Ferramentas clássicas de SAD compreendem
componentes para gerenciamento de sofisticados bancos de dados, poderosas
funções de modelagem e poderosos, embora simples, projetos de interface
com o usuário, que permitem trabalhar interativamente com questões,
relatórios e funções gráficas.

Complementam Grigori et al. (2004) que com dados limpos e agregados

sobre um determinado processo, armazenados em um Data Warehouse, é
possível realizar análises utilizando-se tecnologias de BI e extrair conhecimento
sobre as circunstâncias que levaram a determinado resultado no passado,
tenha o resultado sido bom ou ruim. Assim, é possível utilizar essas
informações para explicar por que tais circunstâncias ocorreram e para predizer
potenciais problemas nos processos em andamento. A Figura 1 mostra os
principais componentes deste ambiente.
 Figura 1 Componentes de um ambiente de BI
Fonte: Adaptação do autor segundo (BARBIERE, 2001)

10.5. DATA WAREHOUSE

Conforme Fortulan & Filho (2005), ao longo do tempo, os bancos de

dados foram desenvolvidos para fins de processamentos de dados
operacionais e analíticos, havendo maior ênfase no primeiro caso, ainda que
ambos tivessem usuários com diferentes necessidades. Uma vez
compreendida essa diferença, foram criados bancos de dados separados para
fins analíticos, chamados de Data Warehouse (DW).

Segundo Inmon (1997), Data Warehouse é 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. O objetivo de um
Data Warehouse é fornecer uma “imagem única da realidade do negócio”. De
uma forma geral, sistemas de Data Warehouse compreendem um conjunto de:

a) programas que extraem dados do ambiente operacional da empresa;

b) um banco de dados que os mantém;

 c) sistemas que fornecem estes dados aos seus usuários.

Para Boghi e Shitsuka (2002), DW é um conjunto de tecnologias com o

objetivo de converter uma grande quantidade de dados em informações
utilizáveis. E para as organizações, o DW acaba transformando as fontes de
dados operacionais em um ambiente que permite o uso estratégico dos dados.

De acordo com Monteiro (2007), o DW é um repositório de dados

provenientes dos dados operacionais, onde se cria um ambiente homogêneo e
padronizado, com finalidade de propiciar análises de negócio concentradas em
um só local.

10.5.1. METADADOS

10.5.2. MODELAGEM DIMENSIONAL

De acordo com Hokama (2004), o modelo dimensional surgiu para

atender sistemas de processamento analítico, com consultas para
planejamento tático e estratégico da empresa. Atualmente a utilização desses
sistemas pelo nível operacional das empresas vem crescendo, auxiliando o
ocesso de tomada de decisões diárias. Normalmente, ele atende um pequeno
número de usuários que realizam consultas planejadas.

Segundo Barbalho (2003), essa estrutura é composta basicamente pelas

tabelas de fatos e tabelas de dimensões. A tabela de fatos traz o resultado da
consulta, ou seja, valores de medição. As restrições, objeções e
questionamentos ficam nas tabelas de dimensões, que trazem informações
textuais sobre o valor medido na tabela de fatos.

10.5.2.1. TABELAS DE FATOS

De acordo com Hokama et al. (2004), a tabela de fatos é sempre

esparsa, ou seja, possui um número relativamente pequeno de todas as
combinações possíveis de valores de chaves. No contexto desse projeto,
poderia ser dado como exemplo o fato de que um produto pode ser vendido
por todos os representantes, comprado por todos os clientes, podendo ser
faturado em qualquer data. Por isso pode-se concluir que é algo extremamente
esparso, pois uma porcentagem muito pequena de todas as combinações
possíveis de representantes, clientes, produtos e datas de faturamento
aparecerá na base.

Segundo Bispo (1998), uma tabela de fato contém vários fatos,

correspondentes a cada uma de suas linhas, sendo que cada fato pode
armazenar uma ou mais medidas numéricas, que constituirão os valores da
análise dimensional. Esse tipo de tabela normalmente armazena muito mais
linhas que as tabelas de dimensões, e devem receber atenção, pois podem ter
um volume muito grande.

Figura 2 Composição básica de uma tabela de fatos

Fonte: Barbieri, 2001

Para Kimball (2002), a tabela de Fatos é a principal tabela que compõe

um modelo dimensional, armazenam medições (linha em uma tabela de fatos)
numéricas ou métricas de desempenho que está relacionada a um assunto ou
processo de negócio. Todo registro de uma tabela de fato está ligado a um
conjunto de dimensões que indicam a granularidade dos fatos que estão
armazenados e definem qual o alvo destas medidas. Quanto menor a
granularidade de um fato, maior será o nível de detalhe armazenado.

10.5.2.2. TABELAS DE DIMENSÕES

Segundo Kimball, (1998), as tabelas de dimensão são aquelas que

armazenam as descrições textuais do negócio, onde cada uma dessas
descrições textuais ajuda a definir um componente da respectiva dimensão.
Exemplo disso seria que cada registro da dimensão cliente refere-se a um
cliente específico

Para Kimball (2002), as tabelas de dimensão sempre acompanham uma

tabela de fatos, ela possui os descritores textuais de um processo, as tabelas
de dimensão são formadas diversos atributos, que servem de base para definir
regras de agrupamento e filtros para consultas em uma tabela de fato. Os
atributos nas tabelas de dimensão possuem um papel essencial do DW, por
serem a origem de todas as restrições e rótulos de relatórios, os atributos são
fundamentais para que o DW seja utilizado e compreendido.

10.5.2.3. GRANULARIDADE E HIERARQUIA

Para INMON (1997), a granularidade é o mais importante aspecto do

projeto de um DW. Isso se deve à seguinte relação:

• O baixo nível de granularidade aumenta o volume de dados

armazenados no DW;
• O alto nível de granularidade origina pesquisas limitadas de
informação, com poucos detalhes.

Segundo GRAY (1998), granularidade se refere ao nível de detalhe

(especificação) dos dados ou de resumo contido nas unidades de dados
existentes em um DW. Quanto mais detalhado os dados forem, mais baixo é o
nível de granularidade.

De acordo com Inmon (1996), a granularidade refere-se ao nível de

detalhe ou sumariação contida nas unidades de um DW. Quanto maior o
detalhamento, menor a granularidade, quanto menor o detalhamento, maior a
granularidade. O exemplo na figura 1.8 mostra isso. Caso seja visualizado o
total de vendas dentro do mês, haverá um baixo nível de detalhes, mas uma
granularidade alta (Figura 3[a]). Se esses valores forem divididos em dias, o
nível de detalhe aumentará, porém a granularidade não (Figura 3[b]).
 Figura 3 Níveis de granularidade
Fonte: Inmon (1996)

10.5.2.4. TIPO DE MODELAGENS

Segundo Harrison (1998), os cinco modelos de projeto de Data

Warehouse são:

• Esquema em estrela;

• Esquema em estrela parcial;

• Esquema de fact table (tabela de fatos) particionada;

• Esquema de tabela dimensional particionada;

• Esquema snowflake.

Abaixo iremos fazer uma breve análise sobre o Esquema em estrela e

SnowFlake.

10.5.2.4.1. ESQUEMA EM ESTRELA

Poe et al. (1998) explica que o esquema estrela é uma estrutura simples,
com poucas tabelas e relacionamentos bem definidos e assemelha-se ao
modelo de negócio, o que facilita a leitura e entendimento, não só pelos
analistas, como por usuários finais não familiarizados com estruturas de banco
de dados. Permite a criação de um banco de dados que facilita a execução de
consultas complexas, podendo ser realizadas de modo eficiente e intuitivo pelo
usuário.

De acordo com Harrison (1998), o uso de uma tabela única por

dimensão e de uma tabela de fatos simples por categoria assegura que as
definições dos metadados possam ser usadas novamente, independentemente
do nível de sumário ou fatos.

A figura 4 faz uma ilustração do modelo.

Figura 4 Exemplo de um esquema em estrela

Fonte: adaptada de HOKAMA et al (2004)
 Para Roldán (2010, p. 367) um esquema em estrela consiste em uma
tabela central conhecida como a tabela de fatos, rodeado por tabelas de
dimensão. Embora o fato tenha indicadores do seu negócio, como vendas em
dólares, as dimensões têm informação descritiva para os atributos do seu
negócio, como tempo, clientes e produtos.

10.5.1.4.2. ESQUEMA SNOWFLAKE (FLOCO DE NEVE)

Segundo Machado (2000), o esquema snowflake (floco de neve) é uma

variação do star schema, no qual todas as tabelas de dimensão são
normalizadas na terceira forma normal, ou seja, são retirados das tabelas os
campos que são funcionalmente dependentes de outros campos que não são
chaves.

10.5.1.4.3 . ESQUEMA DE CONSTELAÇÃO

10.5.2.5. EXTRAÇÃO TRANSFORMAÇÃO E CARGA DE DADOS

– ETL

Roldán (2010, p. 11) explica que o carregamento de um data warehouse

ou um datamart envolve muitos passos, e há muitas variantes dependendo da
área de negócios ou regras de negócio. No entanto, em cada caso, o processo
envolve as seguintes etapas:

Extrair informações de um ou mais banco de dados, arquivos de texto e

outras fontes. O processo de extração pode incluir a tarefa de validação
e descarte de dados que não correspondem as padrões esperados ou
regras.

Transformar os dados obtidos para atender as necessidades de

negócio. A transformação implica tarefas como a conversão de tipos de
dados, fazendo alguns cálculos, filtragem de dados irrelevantes, e
resumindo.

Carregar os dados transformados em uma base de dados de destino.

Dependendo da requisitos, a carga pode substituir as informações
 existentes, ou pode adicionar novas informações a cada vez que é
executado.

10.5.2.6. DATA MATS

Singh (2001, p. 14), define o data mart como um subconjunto lógico e

físico da área de apresentação do data warehouse. Logo, um data warehouse
é composto por um conjunto de data marts integrados. Originalmente, os data
marts eram definidos como subconjuntos altamente agregados de dados,
normalmente escolhidos para responderem a uma questão de negócio
específica, espécie de módulos. Essa definição não funcionou porque levou a
data marts isolados, que não eram flexíveis e não podiam ser combinados
entre si.

Para Roldán (2010, p. 367), data marts são esquemas que abordam as
necessidades de um departamento específico ou que foram construídos para
um determinado grupo de utilizadores. A autora também adverte que às vezes,
o termo data mart é confundido com data warehouse. No entanto, data marts e
data warehouses não são a mesma coisa. Ela ainda explica que a principal
diferença entre data marts e data warehouses é que data warehouses
atendem as necessidades de toda a organização, enquanto um data marts
atende às necessidades de um departamento específico.

A Figura 6 representa um data mart de vendas com seis dimensões.

 Figura 6 – Representação de um Data Mart de vendas
Fonte: Roldán (2010, p. 368)

Para Nimer (1998), os data marts são subconjuntos de dados, dentro de

um data warehouse, projetados para dar suporte a negócios de unidades
organizacionais específicas.

10.5.2.7. DATA STAGING AREA

Kimball, Ross (2002, p. 10), define que “A data staging area abrange
tudo entre os sistemas operacionais de origem e a área de apresentação dos
dados”.

10.5.2.8. FONTES DE DADOS

10.5.2.9. TRANSFORMAÇÕES DE DADOS

10.5.2.10. DESTINO DOS DADOS

10.5.3. OLAP E OLTP

Segundo Thomsen (2002, p. 8), o termo OLAP (Online Analytical

Processing) surgiu como antítese que complementa o termo OLTP (Online
Transaction Processing), tradicionalmente encontrado na teoria de bancos de
dados. OLAP é uma abordagem para a geração de respostas rápidas e
analiticamente flexíveis a consultas gerenciais.

Bispo e Cazarini (1998) apresentam o OLAP como uma ferramenta

capaz de efetuar análises de dados com visão multidimensional do negócio,
comparando-os por diversos ângulos. Aplicações que utilizam este tipo de
ferramenta devem ter como características:

• Permitir visão multidimensional dos dados;

• Realizar cálculos complexos;

• Criar agregações e consolidações;

• Fazer previsões e análise de tendência;

• Construir cenários a partir de suposições; e

• Fazer cálculos e manipular dados através de diferentes dimensões.

Os termos OLTP (On-Line Transaction Processing - Processamento de

Transações On-Line) e OLAP (On-Line Analytical Processing - Processamento
Analítico On-Line) descrevem o modo de processamento nos sistemas de
bancos de dados.

Os bancos de dados operacionais que tratam as operações diárias de

uma empresa, baseados em OLTP, atingem proporções de centenas de
megabytes e até mesmo gigabytes. Consistência e capacidade de recuperação
de dados são críticas, e a maximização do poder de processar transações é
requerida para minimizar os problemas que podem ser causados pela
concorrência de processos.

No caso do processamento analítico, baseado em OLAP, sistemas de

suporte a decisão, ajudam os analistas a identificar tendências, estabelecer
comparações e a prever resultados futuros, deve-se dar maior importância aos
dados históricos, totalizados e consolidados em detrimento dos dados
detalhados ou individualizados. As funções e manipulações em OLAP não
podem ser executadas de imediato nos sistemas OLTP.

Essas diferenças funcionais traduzem em diferenças na concepção de

seus modelos. Comumente, os sistemas OLTP utilizam o modelo entidade-
relacionamento. Os sistemas OLAP são raramente atualizados e são utilizados,
principalmente, para consultas, o modelo mais difundido é o estrela, explicado
no tópico 10.5.2.4.1.

10.5.3.1. CUBOS

Segundo Hokama (2004, p. 49), cubo de dados é uma estrutura

multidimensional que expressa à forma na qual os tipos de informações se
relacionam entre si. É formado pela tabela de fatos e pelas tabelas de
dimensão que a circundam e representam possíveis formas de visualizar e
consultar os dados. O cubo armazena todas as informações relacionadas a um
determinado assunto, de maneira a permitir que sejam montadas várias
combinações entre elas, resultando na extração de várias visões sobre o
mesmo tema.

Figura 5 Exemplo do conceito de cubo

10.5.3.2. FERRAMENTAS
 10.6. SISTEMA DE BUSINESS INTELLIGENCE PENTAHO

10.7. METODOLOGIA

PLANEJAMENTO

1. Definir os requisitos funcionais.

Determinar junto à equipe do projeto que informação deve ser
disponibilizada pela aplicação de BI, quando é necessário estar
disponível e em que formato.

2. Definir os grupos de utilizadores.

A equipe do projeto deve definir quem são os utilizadores da solução de
BI. Existem geralmente três grupos de utilizadores: utilizadores gerais de
relatórios; os produtores e analistas que avaliam os dados; e finalmente
os gestores que decidem os objetivos.

3. Identificar os Indicadores de Desempenho (KPI) requeridos.

São necessários valores operativos para a gestão dos processos de
uma companhia. A equipe do projeto deve defini-los em conjunto com o
departamento especialista.

4. Instalação e configuração do Pentaho BI Server.

5. Criar um protótipo simples da solução.
Criação de um protótipo simples da solução. Desta forma, pode ser feita
uma revisão para assegurar que os requisitos essenciais serão incluídos
desde o início.

Colaboradores dos departamentos especializados devem sempre ser

incluídos paralelamente, uma vez que são esses indivíduos que, no
futuro, irão trabalhar com as aplicações.

Testes feitos pelos colaboradores para determinar se o projeto segue o

escopo.

6. Garantir a integração e qualidade dos dados.

 Identificar os sistemas operacionais nos quais a informação requerida
está disponível e como o dado deve ser acessados.

Desenvolvimento

Desenvolvimento de cubos e relatórios dinâmicos utilizando as ferramentas de

ETL disponíveis no Pentaho.

Conclusão/Encerramento

Disponibilização do Pentaho para o grupo de utilizadores.

REFERÊNCAIS

Manzini Jr. R., O Segredo da Produtividade está no uso da informação.

Computerword, 20 a 30 Abr., p. 10-11, 1997.

COMPUTERWORD. In: Futuro e tendências do BI. Disponível em:

<http://computerworld.uol.com.br/company-zone/IDC/futuro-e-tendencias-de-bi
e-ba/>. Acesso em 08 Abr. 2011.

BARBIERI, Carlos. Business Intelligence: modelagem e tecnologia. Rio de

Janeiro: Axcel Books, 2001.

INMON, Willian H. Building the Data Warehouse. New York: John Wiley &
Sons. 1996. 401 p.

INMON, Willian H. Como construir um Data Warehouse. Tradução da Segunda

Edição. Rio de Janeiro-RJ: Campus, 1997. 388 p.

BOGHI, C.; SHITSUKA R.. Sistemas de Informação: Um Infoque Dinâmico.

São Paulo-SP: Érica, 2002. 288p.
GRAY, P.; WATSON, H. J. Decision support in the Data Warehouse. New
Jersey: Prentice Hall PTR, 1998.

THOMSEN, Erik. OLAP: construindo sistemas de informações

multidimensionais. 2. Ed. Rio de Janeiro: Campus, 2002.

KIMBALL, Ross. "The Data Warehouse Toolkit: The Complete Guide to

Dimensional Modeling (Second Edition)", Wiley, 2002. ISBN 0471200247.

KIMBALL, Ralph, REEVES, Laura, ROSS, Margy, THORNTHWAITE, Warren.

The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing,
Developing andIDeploying Data Warehouses. New York: John Wiley & Sons,
Inc., 1998. 771 p.

MONTEIRO, André Vinicius Gouvea. Uma aplicação de Data Warehouse para

apoiar negócios. Trabalho científico. 2007. Universidade do Estado do Rio de
Janeiro.

FORTULAN, Marcos Roberto; FILHO, Eduardo Vila Gonçalves. Uma proposta

de aplicação de Business Intelligence no chão-de-fábrica. São Carlos, SP:
2005. (Disponível em: www.scielo.br/pdf/gp/v12n1/a06v12n1.pdf. Acesso em:
Abril de 2011).

HOKAMA, Daniele Del Bianco et al. A modelagem de dados no ambiente Data

Warehouse. São Paulo: 2004. 121 p. Projeto de Diplomação (Bacharelado em
Sistemas de Informação) - Faculdade de Computação e Informática,
Universidade Presbiteriana Mackenzie.

HEINRICHS, J. H.; LIM, J. S. Integrating web-based data mining tolls with

business models for knowledge management. Decision Support Systems, v. 35,
n. 1, p. 103-112, 2003.

BISPO, C. A. F.; CAZARINI, E. W. A nova geração de sistemas de apoio à

decisão. In: ENEGEP, 18, 1998, Niterói, Rio de Janeiro, Brasil. Anais... Niterói:
ABEPRO, 1998.
SHIM, J. P.; WARKENTIN, M.; COURTNEY, J.; POWER, D. J.; SHARDA, R.;
CARLSSON, C. Past, present, and future of decision support technology.
Decision Support System, v. 33, n. 2, p. 111-126, 2002.

GRIGORI, D., CASATI, F.; CASTELLANOS, M.; DAYAL, U.; SAYAL, M.;
SHAN, M. C. Business Process Intelligence. Computers in Industry, v. 53, n. 3,
p. 324-343, 2004.

BARBALHO, Patrícia. Descubra o Data Warehouse: produtividade e rapidez.

Revista SQL Magazine. Rio de Janeiro nº 3, ano 1, p. 34 – 38, 2003

BISPO, Carlos Alberto Ferreira. Uma análise da nova geração de sistemas de

apoio à decisão. São Carlos: 1998. 160 p. Dissertação de Mestrado - Escola de
Engenharia de São Carlos, Universidade de São Paulo. Disponível em:
http://www.teses.usp.br/teses/disponiveis/18/18140/tde-04042004-
152849/publico/dissertacao_carlos.pdf. Acesso em: 12 Abr. 2011.

HARRISON, Thomas H. Intranet Data Warehouse. Tradução: Daniel Vieira.

São Paulo: Berkeley Brasil, 1998. 359 p.

POE, Vidette, KLAUER, Patricia, BROBST, Stephen. Building a Data

Warehouse for Decision Support. New Jersey. Prentice-Hall, Inc, 1998. 285 p.

MACHADO, Felipe N. R. Projeto de Data Warehouse: uma visão

multidimensional. São Paulo: Érica, 2000. 251 p.

LAUDON, 2002, LAUDON, LAUDON, 2002, Gerenciamento de Sistemas de

Informação, LTC, 3º edição, Rio de Janeiro, Brasil.

NIMER, F. (1998). Analisando o retorno sobre o investimento de data

warehouse. Developers’ Magazine, n. 18, p. 16-17, fev.

ROLDÁN, Maria Carina, 2010, Pentaho 3.2 Data Integration Beginner’s Guide.
Packt Publishing, 493 p.