Você está na página 1de 97

UNIVERSIDADE DO PLANALTO CATARINENSE

DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS


CURSO DE SISTEMAS DE INFORMAÇÃO
(BACHARELADO)

MARCELO FEIJÓ VARGAS

CONSTRUCAO DE DATA WAREHOUSE PARA


PEQUENAS E MÉDIAS EMPRESAS USANDO SOFTWARE LIVRE

LAGES (SC)
2008
MARCELO FEIJÓ VARGAS

CONSTRUCAO DE DATA WAREHOUSE PARA


PEQUENAS E MÉDIAS EMPRESAS USANDO SOFTWARE LIVRE

Relatório do Trabalho de Conclusão de


Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
créditos de disciplina com nome
equivalente no curso de Sistemas de
Informação – Bacharelado.

Orientação: Prof. Angelo Augusto Frozza,


M.Sc.

LAGES (SC)
2008
MARCELO FEIJÓ VARGAS

CONSTRUCAO DE DATA WAREHOUSE PARA


PEQUENAS E MÉDIAS EMPRESAS USANDO SOFTWARE LIVRE

ESTE RELATÓRIO, DO TRABALHO


DE CONCLUSÃO DE CURSO, FOI
JULGADO ADEQUADO PARA
OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO, DO 8º.
SEMESTRE, OBRIGATÓRIA PARA
OBTENÇÃO DO TÍTULO DE:

BACHAREL EM SISTEMAS DE
INFORMAÇÃO

Lages (SC), 01 de dezembro de 2008

Prof. Angelo Augusto Frozza, M.Sc.


Orientador

BANCA EXAMINADORA:

Prof. Edson Roberto Souza Paes, M.Sc. Prof. Juliana Aparecida Piccoli Branco,
UNIPLAC M.Sc.
UNIPLAC

Prof. Wilson Castello Branco Neto, Dr. Prof. Angelo Augusto Frozza, M.Sc.
Professor de TCC Coordenador de Curso
LISTA DE ILUSTRAÇÕES

FIGURA 1 - Representação do modelo dimensional ...................................................19


FIGURA 2 - Representação do modelo estrela ............................................................20
FIGURA 3 - Representação do modelo floco de neves ...............................................20
FIGURA 4 - Drill-Down ..............................................................................................26
FIGURA 5 - Drill Up ...................................................................................................26
FIGURA 6 - Slice and Dice ..........................................................................................27
FIGURA 7 - Diagrama de uma solução de BI .............................................................29
FIGURA 8 - Arquitetura do Pentaho BI ......................................................................31
FIGURA 9 - Pentaho BI Plataform .............................................................................33
FIGURA 10 - Login Pentaho .......................................................................................34
FIGURA 11 - Solutions ................................................................................................34
FIGURA 12 - Visualização ..........................................................................................35
FIGURA 13 - Diagrama do banco de dados do estudo de caso. ..................................38
FIGURA 14 - Arquitetura sistema transacional ...........................................................39
FIGURA 15 - Esquema lógico do banco de dados para o Data Warehouse................42
FIGURA 16 - Processo de ETL ....................................................................................45
FIGURA 17 - Kettle .....................................................................................................45
FIGURA 18 - Carga da dimensão Sortimento .............................................................46
FIGURA 19 - Dimensão Transportador .......................................................................47
FIGURA 20 - Dimensão Clientes .................................................................................48
FIGURA 21 - Dimensão Tempo ..................................................................................49
FIGURA 22 - Fatos Saída ............................................................................................50
FIGURA 23 - Conexão com o cubo de dados no Schema Workbench ........................53
FIGURA 24 - Visualização do cubo criado..................................................................56
FIGURA 25 - OLAP Navigator....................................................................................62
FIGURA 26 - MDX ......................................................................................................62
FIGURA 27 - Config OLAP Table ..............................................................................63
FIGURA 28 - Show Parent Members...........................................................................63
FIGURA 29 - Hide Spans .............................................................................................64
FIGURA 30 - Show Properties .....................................................................................64
FIGURA 31 - Suppress Empty Rows/Columns ...........................................................65
FIGURA 32 - Swap Axes .............................................................................................65
FIGURA 33 - Drill Member .........................................................................................66
FIGURA 34 - Drill Positio ...........................................................................................66
FIGURA 35 - Drill Replace..........................................................................................67
FIGURA 36 - Drill Through .........................................................................................67
FIGURA 37 - Show Chart ............................................................................................67
FIGURA 38 - Chart Config ..........................................................................................68
FIGURA 39 - Configure Print Settings ........................................................................68
FIGURA 40 - Print This Page Via PDF .......................................................................69
FIGURA 41 - Start Excel .............................................................................................69
FIGURA 42 - Nome do cubo, descrição e conexão de dados ......................................78
FIGURA 43 - Esquema relacional de dados ................................................................79
FIGURA 44 - Criação das medidas ..............................................................................80
FIGURA 45 - Criação das dimensões ..........................................................................81
FIGURA 46 - Conexão com o repositório ...................................................................83
FIGURA 47 - Editor SQL ............................................................................................84
FIGURA 48 - Nova Tranformação ...............................................................................84
FIGURA 49 - Entrada de dados ...................................................................................85
FIGURA 50 - Selecionando valores .............................................................................86
FIGURA 51 - Insert / Update .......................................................................................87
QUADRO 1 - Exemplo de consulta MDX .................................................................36
QUADRO 2 - Dimensão Tempo ................................................................................42
QUADRO 3 - Dimensão Clientes ..............................................................................43
QUADRO 4 - Dimensão Sortimento..........................................................................43
QUADRO 5 - Dimensão Transportador .....................................................................44
QUADRO 6 - Tabela de Fatos ...................................................................................44
QUADRO 7 - Exemplo de arquivo XACTION .........................................................60
LISTA DE ABREVIATURAS E SIGLAS

API - Application Programming Interface


BI - Business Intelligence
CRM - Customer Relationship Management
DW - Data Warehouse
ER - Entidade Relacionamento
ETC - Extração, Transformação e Carga
FTP - File Transfer Protocol
IBM - International Business Machines
JDBC - Java Database Connectivity
JNDI - Java Naming and Directory Interface
JRE - Java Runtime Environment
J2EE Java2 - Platform Enterprise Edition
JVM - Java Virtual Machine
KETTLE - Kettle, Extraction, Transport, Transformation and Loading
Environment
MDX - Multi-Dimensional Expressions
ODBC - Open Data Base Connectivity
PCI - Pre-Configured Installation
PPL - Pentaho Public License
SAD - Sistemas de Apoio à Decisão
SGBD - Sistema Gerenciador de Banco de Dados
SOAP - Simple Object Access Protocol
OLAP - On-line Analytical Processing
OLTP - On-line Transaction Processing
TCC - Trabalho de Conclusão de Curso
TI - Tecnologia da Informação
XML - Extensible Markup Language
XMLA - XML For Analysis
RESUMO

O BI, também conhecido por Inteligência de Negócios ou Inteligência Empresarial, é o


conjunto de tecnologias orientadas a disponibilizar informação e conhecimento em
uma empresa e inclui ferramentas como Customer Relationship Management (CRM),
Data Mining, Data Warehouse, entre outras. Data Warehouse (DW) é uma ferramenta
cuja concepção e administração são voltados à bancos de dados para apoio à tomada
de decisão. Seu objetivo consiste em organizar os dados corporativos da melhor
maneira, para dar subsídio de informações para gerentes e diretores, em um banco de
dados paralelo aos sistemas transacionais da empresa. Os DW têm aplicação limitada
em empresas de médio e pequeno porte, principalmente devido ao alto custo das
aplicações comerciais. Por outro lado, com o surgimento de ferramentas que podem
ser obtidas gratuitamente (ou a custos reduzidos), as médias e pequenas empresas
começam a se beneficiar da utilização dessa tecnologia. Neste trabalho busca-se
demonstrar a viabilidade de desenvolvimento de um DW a partir de ferramentas
distribuídas como software livre. Para tanto, utiliza-se o Pentaho como pacote de
software livre para desenvolvimento de DW e demonstra-se o uso do mesmo através
de um estudo de caso. Ao final, espera-se contribuir para que as empresas adotem uma
postura de trabalho mais voltada à gestão da informação e à criação de estratégias
competitivas.

Palavras-chave: Data Warehouse; Business Intelligence; software livre; estratégias


competitivas.
ABSTRACT

The BI, also known as Business Intelligence, is a set of technologies used to provide
information and knowledge on a company including tools like Customer Relationship
Management (CRM), Data Mining, Data Warehouse, among others. Data Warehouse
(DW) is a tool whose design and administration are focused on databases that support
decision making. Its goal is to organize corporate data as so to give subsidies of
information for managers and executives in a database parallel to the transactional
systems of a company. The DW has limited applications in companies of medium and
small size, mainly due to the high cost of commercial applications. However, with the
emergence of tools that can be obtained for free (or low-cost), the medium and small
businesses start to benefit from the use of this technology. The present study attempts
to demonstrate the feasibility of developing a DW from tools distributed as free
software. In order to achieve this, the Pentaho is used as a free software package for
DW development and it is studied by means of a case study. With this work, it is
expected to help companies to adopt a posture more focused on information
management and on the creation of competitive strategies.

Keywords: Data Warehouse; Business Intelligence; free software; competitive


strategies.
SUMÁRIO

1 INTRODUÇÃO ........................................................................................................11
1.1 Apresentação ...........................................................................................................11
1.2 Descrição do problema ............................................................................................13
1.3 Justificativa ..............................................................................................................13
1.4 Objetivo geral ..........................................................................................................15
1.5 Objetivos específicos ...............................................................................................15
1.6 Metodologia .............................................................................................................15
2 DATA WAREHOUSE .............................................................................................17
2.1 Conceitos e características de Data Warehouse ......................................................17
2.2 Modelagem dimensional .........................................................................................18
2.3 Etapas para a criação de um DW .............................................................................21
2.4 Extração, transformação e carga..............................................................................23
2.5 On-line Analytical Processing - OLAP ...................................................................25
2.6 Operações básicas em Data Warehouse ..................................................................25
2.7 Conclusão ................................................................................................................27
3 PLATAFORMA PENTAHO DE BUSINESS INTELLIGENCE ........................29
3.1 Processos e definições .............................................................................................29
3.2 Licenças e formas de obtenção do Pentaho ............................................................30
3.3 Arquitetura ...............................................................................................................31
3.4 Instalação .................................................................................................................33
3.5 Multi-Dimensional Expressions - MDX..................................................................35
3.6 Conclusão ................................................................................................................36
4 CRIAÇÃO DE UM DATA WAREHOUSE COM PENTAHO ...........................37
4.1 Sistema transacional ................................................................................................37
4.2 Arquitetura proposta ................................................................................................39
4.3 Modelagem dimensional .........................................................................................39
4.4 Modelo Estrela .........................................................................................................42
4.5 Processo de ETL ......................................................................................................44
4.6 Configuracao do servidor de aplicação ...................................................................51
4.7 Configuração do Cubo .............................................................................................52
4.8 Visualização do Data Warehouse ...........................................................................61
4.9 Conclusão ................................................................................................................69
5 CONSIDERAÇÕES FINAIS ...................................................................................71
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................73
BIBLIOGRAFIA COMPLEMENTAR .....................................................................75
APÊNDICES ................................................................................................................76
11

1 INTRODUÇÃO

1.1 Apresentação

Quanto mais conhecimento a humanidade adquire, mais complexos se


tornam os sistemas, as empresas e a sociedade. Os administradores de empresas
passam a maior parte de seu tempo identificando e analisando informações que os
levam às decisões necessárias para o gerenciamento de seus empreendimentos e
negócios. Vários fatores contribuem para mudanças no modo de se tomar decisões
estratégicas nos negócios e nas empresas (DATAMIND TECHNOLOGY CENTER,
1998).
Pensando nisso, introduziu-se no mercado o conceito de Data Warehouse
(DW), com sua concepção e administração voltados a bancos de dados para apoio à
tomada de decisão. Esse conceito consiste em organizar os dados corporativos da
melhor maneira, para dar subsídio de informações para a tomada de decisão por parte
dos gerentes e diretores das empresas. Tudo isso em um banco de dados paralelo aos
sistemas transacionais da empresa.
O Data Warehouse (DW) é uma ferramenta no contexto do Business
Intelligence (BI). O BI, também conhecido por Inteligência de Negócios ou
Inteligência Empresarial, é o conjunto de tecnologias orientadas a disponibilizar
informação e conhecimento em uma empresa e inclui ferramentas como Customer
Relationship Management (CRM), Data Mining, Data Warehouse, entre outras
(MACHADO, 2004).
As ferramentas de Business Intelligence (BI) são bastante difundidas entre
empresas de grande porte, porém, têm aplicação limitada entre as empresas de médio e
12

pequeno porte, principalmente devido ao alto custo das mesmas. Por outro lado, com o
surgimento de ferramentas que podem ser obtidas gratuitamente (ou a custos
reduzidos), as médias e pequenas empresas começam a se beneficiar da utilização
dessa tecnologia.
Conhecer mais sobre essas tecnologias permite aos administradores descobrir
novas maneiras de criar diferenciais para uma empresa em uma economia globalizada,
deixando-os mais seguros para definirem metas e adotarem diferentes estratégias em
uma organização. Assim, eles conseguem visualizar, antes de seus concorrentes, novos
mercados e oportunidades, além de atuar de maneiras diferentes conforme o perfil de
seus consumidores.
Este Trabalho de Conclusão de Curso (TCC) contribui no sentido de analisar
algumas ferramentas computacionais que podem auxiliar nos processos de tomada de
decisões, por intermédio de Data Warehouses.
O presente trabalho está dividido em cinco capítulos. Este primeiro capítulo
faz a apresentação do tema do trabalho, seguida da definição do problema e da
justificativa desta pesquisa. Os objetivos gerais e específicos também são relacionados,
finalizando com a descrição da metodologia a ser seguida para o desenvolvimento da
pesquisa e para alcançar os objetivos. O segundo capítulo descreve conceitos de DW,
além de dar ênfase à apresentação da ferramenta Pentaho, bem como sua
configuração. No terceiro capítulo é apresentada a descrição de um estudo de caso,
para o qual são abordadas as fontes de informação OLTP (On-line Transaction
Processing), o modelo dimensional OLAP (On-line Analytical Processing) e o
processo de Extração, Transformação e Carga (ETC) dos dados. O quarto capítulo
apresenta a implementação do estudo de caso e disponibiliza a análise de dados para
validação do usuário final. Por fim, no quinto capítulo são registradas as considerações
finais e após, as referências bibliográficas que nortearam o desenvolvimento deste
TCC.
13

1.2 Descrição do problema

As ferramentas de BI são amplamente utilizadas em empresas de grande


porte para o desenvolvimento de aplicações para a tomada de decisão e inteligência
competitiva.
Pequenas e médias empresas também podem se beneficiar de aplicações para
a tomada de decisão. Porém, o alto custo desse tipo de aplicação não favorece a sua
disseminação em empresas desse porte.

1.3 Justificativa

Para competir no mercado e superar a concorrência, médias e pequenas


empresas precisam saber mais sobre seus clientes, mercado e tecnologias. Torna-se
necessário ter informações confiáveis e no momento certo (HEINRICHS e LIM,
2003). Um gerente, para tomar decisões, baseia-se em uma série de relatórios com
informações da empresa. Ter informações em mãos é, portanto, um elemento
importante para quem quer tomar decisões rápidas e que podem trazer vantagens na
hora da competição.
Algumas aplicações dão suporte às empresas no processo de tomada de
decisão, pode-se destacar os Sistemas de Apoio à Decisão (SAD) e os sistemas de
Business Intelligence (BI). Esses sistemas contam com algumas ferramentas para a sua
construção, entre elas, estão os Data Warehouse (DW).
Segundo Inmon (1997), “Data Warehouse (DW) é um conjunto de dados
baseados em assuntos, integrados, não-voláteis e variáveis em relação ao tempo, para
apoio às decisões gerenciais”. Kimball (1997), por sua vez, amplia esse conceito,
incluindo um conjunto de ferramentas e técnicas de projeto que, quando aplicadas às
necessidades específicas dos usuários, permite o planejamento e a construção do DW.
Segundo Torres (1995), no mundo atual dificilmente se pode competir na
grande maioria dos negócios sem o uso da Tecnologia da Informação (TI). Em outras
palavras, existe um relacionamento muito grande entre a TI e o comportamento
estratégico de uma organização. Nesse sentido, a TI não é apenas um elemento
14

operacional ou integrante de produtos e serviços, pois tem seu valor estratégico em


uma de suas funções mais tradicionais, que é o fornecimento de informações para a
gestão. Dessa forma, um bom conjunto de informações de natureza estratégica pode
tornar a empresa mais competitiva na medida em que melhora a tomada de decisão.
O uso estratégico da informação tem se tornado uma necessidade cada vez
mais clara para as empresas. Quando a informação é bem utilizada, ela pode agregar
valor ao negócio, além de gerar outros benefícios para a empresa, como reduzir custos
ou identificar novos nichos de mercado.
Empresas de maior porte geralmente têm seus sistemas de informação
construídos sob as plataformas de grandes fabricantes de hardware e software, como
IBM, Oracle e Microsoft, os quais apresentam módulos próprios para BI.
Entre as empresas de pequeno e médio porte, esse tipo de sistema tem
aplicação limitada devido ao alto custo das ferramentas proprietárias. Essas empresas,
pressionadas por custos, geralmente buscam soluções tecnológicas insuficientes, pois
não têm poder para investir nos recursos necessários para uma estratégia voltada à
inteligência de negócios. Projetos de Business Intelligence utilizam softwares para
análise de padrões e gestão da informação, além de outros recursos, muitas vezes fora
do seu alcance.
No entanto, nos últimos anos vem ocorrendo uma interessante mudança para
as empresas, que não envolve grandes investimentos em infra-estrutura tecnológica.
Esta mudança está associada à existência de excelentes softwares livres e confiáveis,
que podem ser utilizados de maneira muito profissional, como bancos de dados, suítes
de escritório, bem como, programas para a implantação de BI.
Portanto, a importância do BI no planejamento estratégico começa a ser
sentida a partir do momento em que a pequena e média empresa adotam uma postura
de trabalho mais voltada à gestão da informação. Somente com informação íntegra e
confiável é possível criar estratégias que atendam melhor seus clientes e colocar a
empresa em um patamar de competitividade mais lucrativo.Com as ferramentas
distribuídas sob a filosofia do software livre, as pequenas e médias empresas passam a
se beneficiar da utilização dessa tecnologia, reduzindo seu custo de implantação.
15

1.4 Objetivo geral

O objetivo geral desse trabalho é demonstrar a viabilidade de


desenvolvimento de um Data Warehouse a partir de um conjunto de ferramentas
distribuídas como software livre.

1.5 Objetivos específicos

Os objetivos específicos desse trabalho são:


a) Definir um pacote de software livre para desenvolvimento de Data
Warehouse;
b) Demonstrar o uso deste pacote de software através de um estudo de caso.

1.6 Metodologia

O presente Trabalho de Conclusão de Curso foi dividido em três etapas.


Inicialmente, tem-se uma visão geral do trabalho, na qual descreveu-se a apresentação
do tema, bem como os objetivos, a justificativa, o cronograma, a metodologia e as
referências bibliográficas.
Ainda na primeira etapa, foi realizado um levantamento bibliográfico em que
foram abordados os conceitos de Data Warehouse e projetos de software livre para
construção de DW, com ênfase para a ferramenta Pentaho, bem como a apresentação e
configuração da mesma.
Na segunda etapa foi apresentada a descrição de um estudo de caso e foram
abordadas as fontes de informação OLTP (On-line Transaction Processing), o modelo
dimensional do DW e o processo de Extração, Transformação e Carga dos dados
referentes a este estudo de caso.
A terceira etapa consistiu no processo de implementar o DW e a interface
OLAP, disponibilizando os recursos para análise de dados.
Ao final, espera-se contribuir para que os usuários finais adotem uma postura
de trabalho mais voltada à gestão da informação, com a informação íntegra e
16

confiável, criando estratégias e, ainda, colocando a empresa em um patamar de


competitividade lucrativo.
17

2 DATA WAREHOUSE

Neste capítulo é apresentada uma descrição geral do que é um Data


Warehouse (DW), juntamente com alguns conceitos relacionados. Entre os conceitos,
destacam-se a modelagem dimensional, aplicada na fase de projeto de um DW, o
processo de ETC (Extração, Transformação e Carga) e o OLAP (On-Line Analytical
Processing), que permite visualizar e analisar grandes quantidades de dados. As etapas
para a criação de um Data Warehouse também são discutidas, com alguns exemplos
ilustrativos.

2.1 Conceitos e características de Data Warehouse

Inicialmente, são analisadas algumas definições de Data Warehouse


elaboradas por especialistas da área. Segundo Inmon (1997), idealizador do conceito,
Data Warehouse “é uma coleção de dados integrados, orientados por assunto,
variáveis com o tempo e não voláteis, usados para dar suporte ao processo gerencial de
tomada de decisão”.
A partir da definição de DW feita por Inmon (1997) e vista anteriormente, é
possível encontrar as principais características de Data Warehouse, que são:
 Integrado - A integração dos dados ocorre quando os dados são passados
do ambiente transacional, através de diversas fontes de dados, para o
ambiente de DW. Todo dado trazido dos sistemas transacionais para o
ambiente de DW é, anteriormente, consolidado, de forma que passe a ter
um único significado;
 Orientado por assuntos - os dados do Data Warehouse são organizados
de modo a facilitar a análise dos dados, para isso o DW contém
18

informações orientadas a assuntos importantes para o negócio da empresa


(análise de vendas) e não por aplicação, como em bancos de dados
transacionais (aplicação de vendas);
 Variante no Tempo - os dados não são atualizáveis, ou seja, são relativos
a um determinado instante de tempo, o que proporciona o
armazenamento histórico dos dados;
 Não volátil – significa dizer que o Data Warehouse permite apenas a
carga inicial dos dados e consultas a estes dados, ou seja, após serem
integrados, transformados e incluídos, os dados não podem ser alterados.

2.2 Modelagem dimensional

Nos bancos de dados relacionais, usados nos sistemas transacionais


tradicionais, a redundância dos dados é evitada, sendo aceita somente em
determinados casos em que é realmente necessária. Esta redundância é eliminada
através de processos de normalização. A normalização das tabelas traz benefícios nos
casos em que muitas transações são efetuadas, pois estas se tornam mais simples e
rápidas. No caso de Data Warehouses, ocorre o contrário, as transações operam sobre
um grande volume de dados e não são simples, nem freqüentes, não sendo conveniente
a normalização das tabelas, pois no ambiente de Data Warehouse ocorrem poucas
transações concorrentes e cada transação acessa um grande número de registros
(PERNAS, 2003).
Conforme Pernas (2003), outro ponto que distingue o banco de dados
relacional do Data Warehouse está relacionado à modelagem dos dados. Enquanto que
em um banco de dados relacional geralmente utiliza-se a modelagem Entidade–
Relacionamento (ER), em um DW utiliza-se de uma modelagem lógica denominada de
modelagem dimensional, também chamada de modelagem multidimensional. Assim,
modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional
dos dados.
Segundo Kimball (1997), a modelagem dimensional “é uma técnica de
projeto lógico que busca apresentar os dados em uma estrutura padrão e intuitiva que
19

permite um acesso de alta performance”. Essa é uma técnica antiga usada para criar
bancos de dados simples e compreensíveis.
Um modelo dimensional é composto, basicamente, pela tabela de fatos e
pelas tabelas de dimensões (Figura 1). A tabela de fatos traz o resultado da consulta,
ou seja, os valores de medição representando transações ou eventos referentes aos
negócios da organização e que podem ser passíveis de análise. Uma dimensão pode
agregar sob nomes distintos, um conjunto de itens com características e posições
próprias, tais como meses e trimestres em relação a um período anual (FROZZA,
2006).

FIGURA 1 - Representação do modelo dimensional


(FONTE: SHIGUNOV, 2007)

Existem várias técnicas para fazer a modelagem dimensional, sendo as


principais: o modelo estrela (Star Schema), que se assemelha a uma estrela, e o modelo
floco de neves (Snow Flake).
Dominante no projeto de DW (KIMBALL, 1997), a modelagem dimensional
no modelo estrela possui as seguintes características:
 Distingue bem as dimensões dos fatos medidos;
 Simplifica a visualização dimensional;
 É eficiente para a realização de consultas;
 Acomoda mudanças mais facilmente.
20

A Figura 2 ilustra um esquema dimensional na forma de estrela para um DW


de vendas, com as dimensões tempo, região, produto, vendedor, cliente e as medidas
da tabela de fatos (valor das vendas, média das vendas).

FIGURA 2 - Representação do modelo estrela

No modelo floco de neves as tabelas de dimensão são normalizadas, evitam


redundância e requerem mais junções para as consultas (Figura 3).

FIGURA 3 - Representação do modelo floco de neves


21

De acordo com Barbieri (2001, p. 74), “a modelagem de dados é


seguramente um dos fatores críticos de sucesso num projeto de Data Warehouse, e
pode representar a fronteira entre o sucesso e o seu fracasso”.
Como o modelo relacional trabalha com normalização, suas tabelas possuem
menos registros e não têm redundâncias, apresentando assim uma melhor performance
nas tarefas do dia-a-dia, como inclusões, alterações e exclusões de registros. Mas ele
só é adequado para consultas simples de poucos registros. Para análises mais
complexas, com um universo de registros maior, o modelo dimensional oferece uma
melhor alternativa, economizando em junções com várias tabelas e armazenando
dados que facilitam a análise das informações (HOKAMA et al., 2004, p. 32).
Para se elaborar um esquema dimensional deve-se levar em conta a
granularidade desejada para a análise. Granularidade se define como o nível com que
os dados estão sumarizados. O grão é o maior nível de detalhamento. O nível
adequado de granularidade deve ser definido de tal forma que atenda às necessidades
do usuário, tendo como limitação os recursos disponíveis (SHIGUNOV, 2007). A
granularidade afeta diversas características em um DW, como o número de diferentes
cruzamentos de dados que podem ser realizados, a infra-estrutura e o espaço em disco
necessário.
Uma dimensão de um cubo é uma coleção de hierarquias de membros,
organizados de maneira conveniente para análise. Um membro é um ponto em uma
hierarquia de uma dimensão, determinado por um conjunto particular de valores de
atributo. Um nível da hierarquia é uma coleção de membros que possuem a mesma
distância da raiz da hierarquia. Cada hierarquia de dimensão está associada a um
atributo da tabela de fatos (MACDONALD e RUBIK, 2007).

2.3 Etapas para a criação de um DW

Kimball (1997), propõe nove etapas para a criação de um banco de dados


dimensional:
a) selecionar o processo de negócio a ser modelado - sendo um processo
executado na organização. Portanto, é importante não se referir a um
22

departamento ou função de negócio da organização, já que se trata do


processo do negócio. Um exemplo é um modelo dimensional único para
tratar de dados de pedidos, em vez de criar um modelo dimensional para
o departamento de vendas e um para o de marketing, em que ambos
desejam acessar dados de pedidos;
b) declarar o grão (nível de detalhes) do processo de negócio - declarar o
grão significa especificar exatamente o que uma linha da tabela de fatos
representa;
c) escolher as dimensões que se aplicam a cada linha da tabela de fatos -
quando não há dúvidas a respeito do grão, geralmente as dimensões
podem ser identificadas facilmente;
d) identificar os fatos numéricos que preenchem cada linha da tabela de
fatos - o interesse é analisar as medidas de desempenho do processo de
negócio. Todos os fatos candidatos em um projeto devem ser verdadeiros
para o grão definido na etapa da declaração do grão e fatos típicos são
valores numéricos aditivos, como quantidade vendida ou valor de custo;
e) armazenar os dados pré-calculados na tabela de fatos - para evitar
possíveis inconsistências para o usuário final, todos os dados calculados
são armazenados fisicamente na tabela de fatos;
f) fazer a carga das tabelas de dimensão - neste ponto, a tabela de fatos está
completa e o papel das tabelas de dimensão é fornecer entradas para a
tabela de fatos diretamente de atributos dimensionais;
g) preparar dimensões para suportar evoluções (mudanças) – verifica-se a
possibilidade de determinados valores de atributos das tabelas de
dimensões, os quais dificilmente sofrem alterações, necessitarem de
atualizações;
h) definir a amplitude de tempo do histórico do banco de dados - ou seja, a
duração do banco de dados. Esta escolha está relacionada com o período
de tempo da tabela de fatos no Data Warehouse, de acordo com o
processo de negócio da empresa;
i) definir o espaço de tempo com que os dados devem ser extraídos e
23

carregados no DW – define o intervalo de tempo do processo de extração


de dados dos sistemas transacionais e sua conseqüente carga no DW.

2.4 Extração, transformação e carga

A etapa de ETC (Extração, Transformação e Carga) é uma das fases mais


críticas de um Data Warehouse, pois divide-se em três fases (BORTOLINI, 2008):
a) a fase de extração dos dados dos sistemas transacionais ou de outras fontes
(planilhas, arquivos e textos);
b) a fase de filtragem, que consiste basicamente em garantir a integridade dos
dados;
c) a fase de carga dos dados no Data Warehouse.

Quando os dados são copiados de sistemas transacionais para o ambiente de


Data Warehouse parece que nada além de simples extrações de dados de um local para
outro está ocorrendo. Em virtude desta enganosa simplicidade, muitas vezes as
empresas acabam perdendo tempo e dinheiro por ter que refazer toda esta parte de
extração. A etapa de ETC tem influência em quase todas as nove etapas de criação de
um DW definidas na seção anterior.
A extração de dados do ambiente operacional para o ambiente de Data
Warehouse demanda uma mudança na tecnologia, pois, muitas vezes, os dados são
transferidos de um banco de dados hierárquico, para uma nova tecnologia de SGBD
(Sistema Gerenciador de Banco de Dados) para DW (BORTOLINI, 2008).
Os bancos de dados transacionais armazenam as informações das transações
diárias da empresa. São utilizados por todos os funcionários para registrar e executar
operações pré-definidas, por isso seus dados podem sofrer constantes mudanças. Por
não ocorrer redundância nos dados e as informações históricas não ficarem
armazenadas por muito tempo, este tipo de banco de dados não exige grande
capacidade de armazenamento (BORTOLINI, 2008).
Um DW, por sua vez, armazena dados analíticos, destinados às necessidades
da gerência no processo de tomada de decisões. Isto pode envolver consultas
24

complexas que necessitam acessar um grande número de registros. Um DW armazena


informações históricas de muitos anos e por isso deve ter uma grande capacidade de
processamento e armazenamento dos dados, os quais se encontram em dois formatos:
detalhados e resumidos (BORTOLINI, 2008).
A seleção de dados do ambiente operacional pode ser muito complexa, pois,
em geral, é necessário selecionar vários campos de um sistema transacional para
compor um único campo no Data Warehouse (por exemplo, o percentual de
lucratividade, que é dado pelo valor do custo sobre o valor da venda), ou integrar
campos de vários sistemas transacionais em um campo com representação única no
DW (por exemplo, um campo representando o sexo de uma pessoa). Ainda, os dados
podem ser reformatados, por exemplo: um campo data do sistema transacional, do tipo
DD/MM/AAAA, pode ser exportado para o outro sistema com o tipo ano e mês como
AAAA/MM/DD (BORTOLINI, 2008).
Podem existir várias fontes de dados diferentes para compor uma
informação, que pode ser oriunda de uma planilha Excel, por exemplo, enquanto uma
outra informação que serve para compor um mesmo fato vem de um arquivo texto.
Quando há vários arquivos de entrada, a escolha das chaves deve ser feita
antes que os arquivos sejam intercalados. Isso significa que, se diferentes estruturas de
chaves são usadas nos diferentes arquivos de entrada, então se deve optar por apenas
uma dessas estruturas (BORTOLINI, 2008). Os arquivos devem ser gerados
obedecendo a mesma ordem das colunas estipuladas no ambiente de Data Warehouse.
Pode haver vários resultados e dados podem ser produzidos em diferentes níveis de
resumo pelo mesmo programa de criação do Data Warehouse.
Valores padrões devem ser fornecidos. Às vezes pode existir um campo no
Data Warehouse que não possui fonte de dados. Então, a solução é definir um valor
padrão para estes campos.
Após a definição de como devem ficar os dados no Data Warehouse, há a
necessidade de filtragem dos dados para colocá-los no padrão definido. Por exemplo,
em um sistema transacional, o campo de sexo é preenchido como F ou M, e em um
outro sistema este mesmo dado é preenchido com 0 ou 1. É justamente nesta hora que
25

entra a parte de filtragem, que é transformar os dados para um padrão definido, que no
exemplo pode ser F ou M.

2.5 On-line Analytical Processing - OLAP

On-Line Analytical Processing (OLAP) significa analisar uma grande


quantidade de dados para dar suporte ao processo decisório através de consultas ou
análises feitas por analistas, gerentes e executivos. OLAP está associado à interface de
consulta de dados no DW. O termo on-line implica que, até mesmo com a grande
quantidade de dados envolvida, tipicamente muitos milhões de registros, ocupando
muitos gigabytes, o sistema deve responder às consultas (queries) rápidas o suficiente
para permitir uma exploração interativa dos dados (MACDONALD e RUBIK, 2007).
OLAP emprega uma técnica chamada Multidimensional Analysis, ou Análise
Multidimensional. Enquanto um banco de dados relacional armazena todos os dados
na forma de linhas e colunas, um conjunto de dados multidimensional consiste em
eixos e células (MACDONALD e RUBIK, 2007).
As ferramentas OLAP permitem aos usuários analisar os dados em
dimensões múltiplas, como produto, tempo e vendedor. Cada dimensão pode conter
hierarquias, por exemplo, a dimensão tempo pode conter as hierarquias ano, mês e dia.
Os dados nestas dimensões são agregados, ou seja, são resumidos, mas pode-se
navegar livremente de uma hierarquia para outra, até se chegar à máxima
granularidade dos dados.

2.6 Operações básicas em Data Warehouse

Em um sistema de Data Warehouse, as principais operações disponíveis nas


interfaces OLAP são:

 Drill Down
A operação Drill Down é utilizada para solicitar uma visão mais
detalhada de um conjunto de dados. Conforme Machado (2004), quando
26

o usuário aumenta o nível de granularidade, diminui o nível de


detalhamento da informação, como mostra a Figura 4.

 Drill Up
Conforme Machado (2004), com a capacidade de Drill up o usuário pode
navegar do nível de maior detalhe até o mais alto nível de maior
sumarização de dados.

FIGURA 4 - Drill-Down
(FONTE: CARUSO, 2007)

FIGURA 5 - Drill Up
(FONTE: CARUSO, 2007)

 Slice and Dice


A tradução livre é corte e picadinho. Possibilita selecionar apenas uma
27

parte do cubo para análise dos dados.


São operações para realizar a navegação dos dados na visualização de um
cubo. Slice and Dice significa, em uma forma simplista, a redução do
escopo dos dados em análise, além de mudar a ordem das dimensões,
mudando desta forma a orientação segundo a qual os dados são
visualizados (MACHADO, 2004).

FIGURA 6 - Slice and Dice


(FONTE: CARUSO, 2007)

2.7 Conclusão

Para a elaboração de um Data Warehouse é de extrema importância ter


conhecimento de sua estrutura e seus recursos. Com este capítulo, pode-se ter noção
dos conceitos, características, e etapas para o desenvolvimento de um sistema de BI –
Business Intelligence, no caso específico, um Data Warehouse.
Observa-se a necessidade de seguir algumas regras para desenvolver um
DW, as quais são: planejamento, obtenção da fonte de dados, modelagem dimensional,
extração, transformação e carga dos dados e, por fim, as operações básicas em
interfaces OLAP Drill Down, Drill Up e Slice and Dice, importantes para que o
usuário saiba utilizar os recursos de navegação e detalhamento, sumarização das
granularidades e enfim, a disponibilização dos dados para análise e posterior validação
do usuário final.
28

No caso deste trabalho, este capítulo representa a fase de estudos sobre os


conceitos e processos de desenvolvimento de um DW, as quais são de extrema
importância para a continuidade do mesmo.
29

3 PLATAFORMA PENTAHO DE BUSINESS INTELLIGENCE

Neste capítulo é apresentada uma descrição geral da plataforma Pentaho,


juntamente com algumas definições e processos. Logo após, é abordado como pode ser
obtida e sua licença de uso. Ainda, descreve-se a arquitetura do Pentaho, sua
instalação, como funciona o Mecanismo de Solução e os demais componentes que
formam a arquitetura. Após entender como é estruturada uma solução no Pentaho, é
abordada a linguagem MDX (Multi-Dimensional Expressions), utilizada nas consultas
de objetos multi-dimensionais ao esquema lógico do Data Warehouse.

3.1 Processos e definições

A plataforma Pentaho é um conjunto de software open source para criação


de soluções de BI (Business Intelligence). Ela possui ferramentas para atender ao
processo de criação de soluções de BI de ponta-a-ponta, integrada à uma gama de
opções para banco de dados e outras ferramentas, conforme ilustra a Figura 7
(TEMATEC, 2008)

FIGURA 7 - Diagrama de uma solução de BI


(FONTE: TEMATEC, 2008)
30

Quando uma organização precisa tomar uma decisão é indispensável ter


dados corretos e disponíveis para consulta. Para conseguir isso, ela deve tratar e
consolidar as informações armazenadas nos sistemas e fontes de dados que apóiam seu
negócio em um repositório centralizado, criando “uma única versão da verdade”,
limpa e confiável (processo ETC). Depois, pessoas que entendem do negócio da
empresa devem ter acesso a esse repositório e, usando ferramentas de visualização e
exploração de dados, interpretá-los para finalmente tomar uma decisão (TEMATEC,
2008).
O conjunto destes componentes de softwares, dados, operações e processos
usados para atender uma necessidade específica, para tomar uma decisão, é chamado
de solução.
A Pentaho Inc. integrou e promoveu o desenvolvimento de várias
ferramentas open source que fornecem os recursos necessários para criação de
soluções de BI. Esse conjunto é conhecido por Pentaho Open BI Suite e inclui
ferramentas para consolidar dados de fontes diversas, criar interfaces visuais para
exploração desses dados e montar soluções para necessidades específicas (TEMATEC,
2008).

3.2 Licenças e formas de obtenção do Pentaho

A plataforma Pentaho BI é distribuída como código aberto, através da


Licença Pública da Pentaho (PPL - Pentaho Public License). A PPL é uma licença
para software livre de código aberto, similar à Licença Pública do Mozilla (versão 1.1)
(PENTAHO, 2007).
A plataforma Pentaho BI pode ser baixada gratuitamente, através do
endereço http://www.sourceforge.net/projects/pentaho. Existem várias versões
disponíveis. Através do endereço http://www.pentaho.org pode-se ter acesso a um
wizard que ajuda a determinar a versão correta para cada caso.
Para iniciantes, é recomendável fazer o download de uma versão de
demonstração (por exemplo, a pentaho_demo_hsqldb-1.6.0.GA.863). Estas versões
31

incluem uma aplicação pré-configurada em um servidor Jboss, juntamente com alguns


exemplos e dados em um servidor Sun Microsystems JRE.

3.3 Arquitetura

O projeto Pentaho BI é constituído de um conjunto completo de ferramentas


de BI e bibliotecas que fornecem funcionalidades de BI aos desenvolvedores. É uma
solução com suporte a relatórios, análises, data mining e workflow, através de uma
série de componentes que podem ser distribuídos juntos ou separados (PENTAHO,
2007).
O servidor roda de acordo com o padrão de servidores Java, tais como
Apache TomCat e JBoss. Ele utiliza um método de desenvolvimento, distribuição e
suporte que torna possível o modelo de negócios open source (PENTAHO, 2007).
A Figura 8 apresenta a arquitetura do Pentaho, a qual é composta por
componentes de integração de dados, infra-estrutura e apresentação dos dados e a
origem destes dados.

FIGURA 8 - Arquitetura do Pentaho BI


(FONTE: PENTAHO, 2007)

O Pentaho BI abrange, principalmente, as seguintes áreas de aplicação


(PENTAHO, 2007):
32

 Relatórios (Reporting): Fornece desde simples relatórios em uma página


web, até relatórios de alta qualidade, tais como relatórios de indicações
financeiras e relatórios ricos em conteúdos, como tabelas, gráficos, entre
outros;
 Análises (Analysis): Permite consultas, exploração interativa com
operações slice-and-dice, drill-down e pivoting. Inclui front-end gráfico
para exploração dos cubos OLAP;
 Painéis (Dashboards): Reúne relatórios, análises e outras exposições em
um único local para simplificar o acesso, podendo ser customizado por
usuário ou assunto;
 Data mining: Descobre relacionamentos ocultos nos dados, que podem
ser utilizados para otimizar os processos de negócio e prever resultados
futuros. Permite que os resultados sejam exibidos em um formato de fácil
entendimento ao usuário;
 Workflow: Liga diretamente as medidas de desempenho de negócio aos
processos, promovendo um ciclo contínuo de melhorias.

Todos os componentes da plataforma são de código aberto. Neste trabalho


são analisados os seguintes componentes: Pentaho Cube Designer, Pentaho
Workbench, Pentaho Design Studio, OLAP Mondrian, Front-End JPivot Analysis,
Pentaho Data Integration (Kettle) Back-End e o servidor de aplicação JBoss.
O projeto Pentaho BI oferece uma solução que pode ser utilizada por
desenvolvedores Java, os quais podem utilizar os componentes do projeto para montar
rapidamente soluções BI sob medida. O Pentaho pode ser utilizado por empresas
desenvolvedoras de software para adicionarem as funcionalidades de BI em seus
produtos. O projeto pretende, ainda, permitir que usuários finais tenham acesso a
soluções de BI com a qualidade dos softwares comerciais tradicionais, porém com um
custo bem mais acessível.
33

3.4 Instalação

A instalação pré-configurada (PCI-1.6.0.GA.863), usada neste trabalho, é


uma instalação completa de servidor, projetada para avaliar as características da
plataforma de BI Pentaho. A suíte disponibiliza um servidor de aplicação pré-
configurado, bases de dados de aplicação pré-povoadas, dados de amostra e exemplos
plenamente funcionais. Há uma versão do PCI que inclui o Java Runtime Environment
(JRE) também.
O desempenho desta instalação depende de muitos fatores, mas ela deve
executar sem problemas em quase todas as plataformas e configurações.
O processo de instalação é bastante simples:
 Cria-se uma nova pasta no disco rígido, selecionando-se um nome e
localização, preferencialmente na raiz do disco;
 Assegura-se que o diretório contenha espaço suficiente;
 Utiliza-se uma ferramenta de descompactação para extrair na nova pasta
os arquivos copiados;
 Para executar o PCI usa-se o arquivo start-pentaho.bat e aguarda-se a
inicialização. Deve aparecer na tela a mensagem “[STDOUT] [pt_47]
Pentaho BI Platform server is ready” (Figura 9);

FIGURA 9 - Inicialização do Pentaho BI Plataform

 Abre-se o browser e informa-se o endereço http://localhost:8080;


 Seleciona-se o usuário Joe e senha Admin (Figura 10);
34

FIGURA 10 - Login Pentaho

 Escolhe-se no menu Navigate a opção Solutions (Figura 11);

FIGURA 11 - Menu Solutions

 Deve-se escolher Analysis Examples, no qual há um exemplo disponível


para visualização (Figura 12).
35

FIGURA 12 - Visualização do exemplo disponível

3.5 Multi-Dimensional Expressions - MDX

A linguagem MDX (Multi-Dimensional Expressions – expressões


multidimensionais) é uma linguagem para descrever consultas multidimensionais em
bancos de dados e foi, originalmente, criada pela Microsoft para utilização com o
produto SQL Server OLAP Services, por volta de 1998, como parte da especificação
OLE DB/OLAP API (MICROSOFT, 2008).
Com o intuito de tornar a linguagem MDX um padrão, ela foi recentemente
introduzida como parte da API do XMLA1 (XML for Analysis), que é um padrão para
acesso a servidores OLAP via SOAP (Simple Object Access Protocol). Este padrão
permite que aplicações não Java também possam ter acesso ao servidor OLAP
(ANALYSIS, 2007).
A linguagem MDX proporciona facilidades para consultas multidimensionais
às fontes de dados usando a estrutura de consulta do Pentaho. Sua adoção entre
desenvolvedores de aplicação e provedores de ferramentas OLAP têm sido crescente e
se tornou um padrão para expressões de consultas multidimensionais.

1
XMLA é um padrão que permite que aplicações cliente se comuniquem com bases de dados dimensionais ou
OLAP. A transmissão das mensagens é feita utilizando padrões da Internet, como HTTP e SOAP.
36

O Quadro 1 apresenta um exemplo de consulta MDX. Esta consulta retorna


uma visão do cubo multidimensional Sales, com as medidas Unit Sales (unidades
vendidas) e Store Sales (unidades em estoque) nas colunas, relativas ao segundo
trimestre de 1997, descriminadas por produto nas diferentes linhas da visão
(MACDONALD e RUBIK, 2007).

QUADRO 1 - Exemplo de consulta MDX


1 SELECT {[Measures].[Unit Sales], [Measures].[Store Sales]}
2 ON COLUMNS,
3 {[Product].members} ON ROWS
4 FROM [Sales]
5 WHERE [Time].[1997].[Q2]
(FONTE: MACDONALD e RUBIK, 2007)

3.6 Conclusão

Para alcançar o objetivo proposto neste trabalho se fez necessário conhecer o


funcionamento da plataforma Pentaho. Sendo assim, é de grande importância conhecer
os processos, definições, arquitetura e funcionalidades da plataforma.
Neste sentido, identificou-se em listas de discussão que essa é a principal
plataforma aberta para uso com BI, representando a solução ideal para o
desenvolvimento deste trabalho, uma vez que outras plataformas ou ferramentas
semelhantes estão em um estágio de desenvolvimento inferior ao Pentaho.
Conhecer a arquitetura do Pentaho auxilia a conhecer quais sistemas estão
integrados à mesma, a qual é constituído de um conjunto completo de ferramentas de
Business Intelligence (BI) e bibliotecas que fornecem funcionalidades de BI aos
desenvolvedores e como devem ser usados para criar soluções. Há ainda de forma
detalhada, como obter o software disponível e a licença, e um passo a passo para
facilitar a instalação.
Nos próximos capítulos, esses componentes são melhor compreendidos
através do uso de um estudo de caso.
37

4 CRIAÇÃO DE UM DATA WAREHOUSE COM PENTAHO

No presente capítulo demonstra-se, através de um estudo de caso, como


funciona o processo de desenvolvimento de um Data Warehouse (DW) a partir da
plataforma Pentaho. O processo de criação do DW inicia pela análise de um sistema
OLTP – On-line Transaction Processing de uma empresa de transportes de madeira
fictícia. É feita a identificação dos dados atualmente utilizados para tomada de decisão
na empresa e, a partir desta análise, é realizada a modelagem dimensional do DW.
Logo após, é programado o processo de extração, transformação para posterior carga
no DW. Ao final, com a modelagem dimensional criada e o banco de dados do DW
devidamente preenchido, é feita a configuração do cubo para possibilitar a análise dos
dados na plataforma Pentaho.

4.1 Sistema transacional

Neste trabalho busca-se o desenvolvimento de uma solução de DW. Esta


seção tem por finalidade descrever genericamente o funcionamento do controle de
produção de uma empresa de reflorestamento, baseado no estudo do software de
gestão da empresa. Posteriormente, com base nas características aqui levantadas, é
feita a proposta de uma aplicação de Data Warehouse para atender às necessidades
deste setor.
A estrutura da empresa de reflorestamento é formada por operadores,
gerência comercial e pessoal de apoio. A gerência comercial é responsável pelo
controle dos operadores e acompanhamento dos transportes dos produtos. O pessoal de
apoio é responsável pelo trabalho burocrático do setor, como atendimento a clientes,
38

cadastramento de produtos, condições de pagamento, interação com as transportadoras


e operadores.
O cliente faz o pedido para o pessoal de apoio. O pedido contém uma
determinada data de entrega, a condição de pagamento, a transportadora que faz a
entrega e os itens do pedido, que são os produtos comprados pelo cliente.
O sistema OLTP, que faz o controle de cargas é de grande importância para a
empresa, mas apresenta carência de informações estratégicas e não responde a
questões que têm origem no cruzamento de dados, como: quais os melhores clientes
por período do ano, total das saídas de cargas por cliente no mês, valor total de vendas
no dia, mês ou ano e quantidade transportada.
No levantamento das informações, fica claro a necessidade de uma aplicação
que apresente as informações estratégicas aos dirigentes da empresa, diretamente da
origem dos dados, para que possam visualizá-las e utilizá-las na tomada de decisão.
Os dados do sistema OLTP estão disponíveis no SGBD (Sistema
Gerenciador de Banco de Dados) FireBird, versão 2.0. Para facilitar a análise, os
dados de interesse deste estudo de caso estão representados no diagrama apresentado
na Figura 13, o qual serve de base a modelagem do Data Warehouse.

FIGURA 13 - Diagrama do banco de dados do estudo de caso.


39

O sistema OLTP contém uma tabela saída que faz o controle de saídas,
relacionando veículos, produtos por cliente e município.
A título de informação técnica, o hardware e software utilizados para
desenvolver o estudo do banco de dados OLTP são:
 Hardware:
 PC (Notebook) com processador Turion X2, de 1,66 GHz, e 1 GB de
memória RAM, HD 120GB.
 Software:
 Sistema operacional: Microsoft Windows XP Service Pack 2;
 Banco de dados: FireBird 2.0.

4.2 Arquitetura proposta

A arquitetura proposta para esse estudo de caso é apresentada na Figura 14.


Ela ilustra o sistema transacional ligado em um servidor OLAP, com o acesso local
(localhost). O servidor OLAP é utilizado para construir e visualizar o Data
Warehouse. Esta arquitetura é ideal para a demonstração deste estudo de caso, porque
utiliza o sistema, bem como o servidor de banco de dados já existente, e requer um
investimento mínimo em hardware e software.

FIGURA 14 - Arquitetura sistema transacional

4.3 Modelagem dimensional

Nesta seção é apresentada a fase de projeto para a construção do Data


Warehouse, segundo as nove etapas propostas por Kimball (2002):
40

a) Primeira etapa - seleção do processo do negócio a ser modelado:


Após reunião com os gerentes e funcionários da empresa, entre os
processos de negócio existentes, escolheu-se a área de produção como
prioritária, por esta ser uma atividade executada na empresa de
fundamental importância para os negócios e principal fonte geradora de
receitas. Assim sendo, o Data Warehouse proposto compreende um cubo
OLAP com dados sobre as operações de transporte realizadas;

b) Segunda etapa – declaração do grão do processo de negócio:


Escolheu-se que a granularidade, ou nível de detalhes, forneça
informações de saídas por cliente, por período (dia, mês, trimestre,
semestre e ano), por produto e por transportador.

c) Terceira etapa – escolha das dimensões:


Com base na definição da granularidade, as dimensões definidas foram:
cliente, tempo, transportador e sortimento. Nesta etapa, também são
definidos os atributos das dimensões, os quais correspondem à descrição
dos fatos e estabelecem os níveis de detalhe que a informação pode ser
apresentada, ou seja, refletem as operações drill-down e drill-up. Os
atributos das dimensões são mostrados na seção 4.4;

d) Quarta etapa – identificação dos Fatos:


Com a finalidade de analisar as medidas de desempenho das saídas de
cargas, escolheu-se como fatos: a quantidade de produtos transportados
(em toneladas) e o valor das vendas realizadas. O Quadro 2 apresenta a
origem dos fatos para o cubo proposto.

QUADRO 2 - Identificação dos fatos


FATOS: OPERAÇÕES DE TRANSPORTE
Medida Descrição Origem
Quantidade transportada em Peso Bruto (tabela Saída) – Tara
Quantidade
toneladas. (tabela Saída)
Preço (tabela sortimento) *
Valor Venda Valor das vendas realizadas.
Quantidade

e) Quinta etapa – armazenar os dados na tabela de Fatos:


41

Esta etapa, descrita na seção 4.5, é suportada pelo processo de Extração,


Transformação e Carga (ETC), que extrai os dados da base transacional,
passa pelo processo transformação e carrega para a base dimensional.

f) Sexta etapa – preenchendo as tabelas de dimensão:


Esta etapa também está descrita na seção 4.5, que trata sobre o processo
de ETC;

g) Sétima etapa – preparar dimensões para suportar mudanças:


Até o presente momento, a única necessidade de alteração prevista para
as tabelas de dimensões é a inclusão de novos valores provenientes das
tabelas de cadastro do sistema transacional. Cabe ressaltar que não há
exclusão de registros em um banco de dados de um Data Warehouse;

h) Oitava etapa – escolha da duração do banco de dados:


Nesta etapa definiu-se que o período de duração do banco de dados do
Data Warehouse é de dez anos. A definição deste tempo leva em
consideração o período médio para corte de árvores da espécie Pinus,
principal produto transportado pela empresa deste estudo de caso. Desta
forma, as análises de tendência no transporte de madeira podem
apresentar com detalhes o crescimento da demanda pelos serviços da
empresa. Após dez anos, os dados no banco de dados do DW podem ser
retirados da base de dados e armazenados em dispositivos de
armazenamento secundário, possibilitando sua recuperação caso seja
necessário;

i) Nona etapa – definir espaço de tempo de extração e carga de dados:


O espaço de tempo em que os dados devem ser extraídos do banco de
dados do sistema transacional e carregados no Data Warehouse é mensal.
O processo de extração e a programação do mesmo são detalhados na
próxima seção.
42

4.4 Modelo Estrela

Com base na seção anterior, aqui é apresentado o Modelo Estrela do banco


de dados para o DW proposto (Figura 15), composto por uma tabela de Fatos (Quadro
8) e cinco tabelas de Dimensões (Quadros 3 a 7), caracterizadas a seguir:

FIGURA 15 - Esquema lógico do banco de dados para o Data Warehouse

Recomenda-se que o banco de dados de um Data Warehouse seja separado


do banco de dados do sistema transacional e, de preferência, que esteja em um servidor
próprio. Assim sendo, optou-se por implementar o banco de dados do DW em um
servidor (hardware) diferente do servidor em que está o banco transacional,
gerenciado pelo SGBD PostgreSQL.
A dimensão Tempo armazena a hierarquia de períodos relacionada às datas
de saída correspondentes aos Fatos. Esta dimensão é composta pelos atributos
apresentados no Quadro 3.

QUADRO 3 - Dimensão Tempo


DIMENSÃO TEMPO
Atributo Descrição Tipo de dado
Seq_id_tempo ID da data Bigint
Ano Número do ano integer
Trimestre Número do trimestre no ano integer
Mês_nome Número do mês nome text
Dia_nome Número do dia Text
43

Os usuários do DW podem fazer suas análises considerando os dados em


intervalos de dias, meses, trimestres ou anos. Por exemplo, o valor realizado de
transportes para o mês de Setembro de 2008.
A origem dos dados da dimensão DIM_TEMPO não é proveniente do banco
de dados OLTP. Os dados são gerados a partir do processo de ETL descrito na
próxima etapa de desenvolvimento.
A dimensão DIM_CLIENTES tem por finalidade armazenar dados relativos
aos clientes. No Quadro 4 são listados os atributos que caracterizam esta dimensão.
A partir dessa dimensão, podem ser feitas análises levando em consideração
cada cliente individual da empresa, bem como análises considerando agrupamentos de
clientes por hierarquia: estado, município, bairro e situação. Por exemplo, qual o valor
de transporte por cliente; qual o valor de vendas no ano de 2007, por município.

QUADRO 4 - Dimensão Clientes


DIMENSÃO: DIM_CLIENTES
Atributos Descrição Tipo de dado Origem
Idcliente ID do cliente Integer Campo sequencial
Situação Ativo ou não ativo Character (2) OLTP(tabela clientes, campo ativo)
Estado Estado onde o cliente mora Character (30) OLTP(tabela uf, campo uf)
Município Município onde o cliente mora Character (30) OLTP(tabela municipio, campo municipio )
Bairro Estado onde o cliente mora Character (30) OLTP(tabela clientes, campo bairro)
Nome Nome do cliente Character (50) OLTP(tabela clientes, campo idcliente)

A dimensão DIM_SORTIMENTO armazena as informações sobre os


produtos que são transportados pela empresa e disponibilizados aos seus clientes. O
Quadro 5 apresenta uma explicação sobre os atributos que compõem esta tabela de
dimensão: nome do produto e sua situação.
Como exemplo de análises que podem ser obtidas no DW, tem-se: qual a
quantidade e o valor de cada produto transportado, para qual cidade foi transportador e
o ano de transporte.

QUADRO 5 - Dimensão Sortimento


DIMENSÃO DIM_ SORTIMENTO
Atributos Descrição Tipo de dado Origem
Idsortimento Código do sortimento Integer Campo Sequencial
Situação Ativo ou não ativo Character (2) OLTP (tabela sortimento, campo ativo)
Nome Nome do sortimento Character (50) OLTP (tabela sortimento, campo nome)
44

A dimensão DIM_TRANSPORTADOR armazena as informações sobre os


transportadores disponíveis, os quais correspondem às empresas que prestam este
serviço. Uma explicação sobre os atributos que compõem esta tabela de dimensão
encontra-se no Quadro 6.

QUADRO 6 - Dimensão Transportador


DIMENSÃO DIM_TRANSPORTADOR
Atributos Descrição Tipo de dado Origem
idtransportador ID do transportador Integer Campo Sequencial
Situação Ativo ou não ativo Character(2) OLTP (tabela transportador, campo ativo)
Nome Nome do transportador Character (50) OLTP (tabela transportador, campo nome)

A tabela de Fatos SAÍDA contém as informações sobre as saídas de produtos


da empresa e é composta pelas chaves estrangeiras das tabelas de dimensão e pelos
valores que correspondem aos Fatos (Medidas). O Quadro 7 apresenta uma explicação
sobre os atributos que compõem esta tabela de Fatos.

QUADRO 7 - Tabela de Fatos


FATO SAÍDA
Atributo Descrição Tipo de dado Origem
ID do cliente que fez o
idclientes Integer OLTP (tabela clientes, campo idcliente)
pedido
ID da data de saída dos DWTCC (dimensão tempo, campo
seq_id_tempo Integer
veículos seq_id_tempo)
DWTCC (dimensão transportador,
idtransportador ID do transportador Integer
campo idtransportador)
OLTP (tabela clientes, campo
idoperadores ID dos operadores Integer
idoperador)
OLTP (tabela clientes, campo
idsortimento ID do sortimento Integer
idsortimento)
Medida que identifica a
Quantidade Numeric (17,2) OLTP (tabela saida, peso bruto - tara )
quantidade transportada
Medida que calcula o valor
OLTP (tabela sortimento, campo preco)
Valor Venda total do sortimento Numeric (17,2)
* Quantidade
transportado

4.5 Processo de ETL

Os detalhes do povoamento do Data Warehouse através do processo de ETL


– Extraction, Transformation and Load (Extração, Transformação e Carga) são
explicados nesta seção. Para tanto, foi utilizado no projeto a ferramenta de código
aberto chamada Kettle, que é distribuída pela Pentaho Inc. e auxilia a integração de
45

dados e a construção do DW, como ilustra a figura 16. Um tutorial passo-a-passo de


uso do Kettle é apresentado no apêndice B.

FIGURA 16 - Arquitetura do processo de ETL

A seguir, são exemplificados os passos necessários para passar os dados


contidos no banco de dados OLTP para o banco de dados do DW, através do processo
de ETL.

FIGURA 17 - Kettle

A figura 17 mostra a interface da ferramenta Kettle, responsável pelo


processo de ETL. A base do processo de ETL no Kettle é a criação de
Transformações, ou seja, para cada tabela do DW, é criado um processo de
transformação que lê os dados da fonte original (OLTP), faz um pré-processamento e
46

grava na tabela do DW. A criação de transformações é feita por meio de componentes


pré-configurados (steps) fornecidos pelo Kettle, em um modo drag-and-drop (arrastar
e soltar).
Em algumas situações, o processo de ETL precisa apenas copiar os dados de
uma tabela no banco transacional para o banco do DW. Este é o caso, por exemplo, da
dimensão DIM_SORTIMENTO (Figura 18). Para estes casos, o ETL é realizado da
seguinte forma:
a) Table Input: carregam-se os valores armazenados na tabela
SORTIMENTO do banco OLTP (idsortimento, nome e ativo);
b) Definir Metadatas: definem-se os tipos de valores dos campos
selecionados;
c) Definir situation: faz o mapeamento da situação (S ou N, no banco
OLTP) para Ativo ou Não-Ativo;
d) Select values: selecionam-se apenas os atributos necessários para serem
carregados na dimensão;
e) Insert/Update: escreve-se na dimensão DIM_SORTIMENTO os dados
resultantes da transformação, sendo eles idsortimento, nome e situação.

FIGURA 18 - Carga da dimensão Sortimento

A dimensão DIM_TRANSPORTADOR (Figura 19) é criada pela integração


de dados das tabelas Transportadores e Municípios, do banco de dados OLTP:
a) Table Input: carregam-se os valores armazenados na tabela
TRANSPORTADOR do banco OLTP (idtransportador, nome, bairro e
idmunicipio);
b) Database lookup: busca-se o campo com o nome do Município;
47

c) Select values: selecionam-se apenas os atributos necessários para serem


carregados na dimensão;
d) Insert/Update: escreve-se na dimensão DIM_TRANSPORTADOR os
dados resultantes da transformação, sendo eles idtransportador, nome,
bairro e municipio.

FIGURA 19 - Dimensão Transportador

A dimensão Clientes (Figura 20) é criada a partir da integração dos dados de


várias tabelas do banco OLTP:
a) Table Input: carregam-se os valores armazenados nas tabelas CLIENTE,
MUNICIPIO e UF do banco OLTP (cliente.idcliente, cliente.nome,
cliente.bairro, cliente.ativo, município.nome, uf.uf);
b) Define Metadatas: definem-se os tipos de dados dos campos
selecionados;
c) Value mapper: define-se o mapeamento do campo situação (S -> Ativo;
N -> Não Ativo);
d) Select values: selecionam-se e renomeiam-se apenas os atributos
necessários para serem carregados na dimensão;
e) Insert/Update: escreve-se na dimensão DIM_CLIENTES os dados
resultantes da transformação, sendo eles idcliente, nome, bairro,
município, UF e situação.
48

FIGURA 20 - Dimensão Clientes

A dimensão DIM_TEMPO (Figura 21) apresenta um pouco mais de


complexidade, quando comparada com as anteriores. Os dados dessa dimensão não
vêm do banco OLTP, pois são gerados pelo processo de ETL e, posteriormente, são
relacionados na criação da tabela de Fatos:
a) Generate Rows: geram-se conjuntos de valores para days (dias), months
(meses) e years (anos), com limites para cada campo de 31 dias para
days, 12 meses para months e 20 anos para years;
b) Add Sequence: definem-se números seqüenciais (IDs) para os registros
criados nos três conjuntos de valores do item a (dias, meses e anos).
Neste passo, o valor inicial e o valor de incremento de cada seqüência são
definidos;
c) Join Rows: faz-se a união (produto cartesiano) dos conjuntos de valores
gerados (dias, meses e anos);
d) BuildDateInfo: executa-se um script em JavaScript para criação e
validação das datas, utilizando as variáveis criadas nos passos anteriores;
e) Sort rows: selecionam-se os campos para a ordenação das datas, com base
nos campos dia, mês e ano;
f) Filter rows: filtram-se os campos, descartando as datas inválidas com
base na condição dt = null. Se a data é válida, segue o campo para o step
Add Sequence, se não for válida segue para o step InvalidDateIgnore;
g) Add sequence: atribui-se um id para cada data criada, com valor inicial e
incremento pré-definidos;
49

h) Value mapper: faz-se o mapeamento dos meses (em números) para os


respectivos nomes (string);
i) Calculate: fornece um conjunto de funções pré-definidas, que são
executadas sobre o campo dt (data), para calcular: dia do ano na data
(sequencial, por exemplo, 1 a 365); semana do ano na data (sequencial,
por exemplo, 1 a 52); dia da semana da data (sequencial, 1 a 7);
j) Value mapper: faz-se o mapeamento do dia da semana (1 a 7) para o
respectivo nome (string);
k) Select values: selecionam-se os campos necessários para armazenar na
dimensão tempo;
l) Combination lookup/Update: escreve-se na dimensão DIM_TEMPO os
dados resultantes da transformação.

FIGURA 21 - Dimensão Tempo

Para a tabela de Fatos SAÍDA (Figura 22) deste estudo de caso, a


transformação é feita pela integração de dados do banco OLTP (tabelas Saida,
Sortimento e Veiculo) com a dimensão TEMPO, além dos cálculos das medidas
Quantidade e Valor Venda:
a) Table Input: carregam-se os valores armazenados na tabela SAÍDA do
50

banco OLTP;
b) Database lookup: busca-se o preço do produto na tabela Sortimento;
c) Database lookup: busca-se o transportador do produto na tabela Veiculo;
d) Rename Values: renomeiam-se os valores conforme definido para a tabela
Fatos;
e) Calculate: faz-se o cálculo da quantidade de produtos transportados e o
valor total das vendas;
f) Buscar datas: busca-se o campo data_data na dimensão TEMPO;
g) Compara campos data: comparam-se os campos data_data (dimensão
TEMPO) e data (OLTP), para associar cada linha com o respectivo
registro na dimensão TEMPO;
h) Add sequence: adiciona-se uma sequência (id) para cada linha da tabela
Fatos;
i) Select values: selecionam-se apenas os atributos necessários para serem
carregados na tabela de Fatos;
j) Combination lookup/update: escreve-se na tabela Fato SAIDA os dados
resultantes da transformação.

FIGURA 22 - Fatos Saída


51

4.6 Configuracao do servidor de aplicação

A Plataforma Pentaho depende do JNDI (Java Naming and Directory


Interface) para nomear as fontes de dados, as quais devem ser definidas no JBoss. O
JBoss usa um arquivo XML para identificar cada fonte de dados (conexão JNDI), o
qual tem como nome fonte–ds.xml (Quadro 8), sendo fonte o nome da fonte de dados e
–ds.xml o sufixo padrão (por exemplo, postgresql-ds.xml).
Para que a interface da plataforma execute corretamente, configura-se a
conexão JNDI da seguinte forma: adiciona-se um arquivo *-ds.xml para a fonte de
dados na respectiva pasta do JBoss (.../server/default/deploy), conforme pode ser visto
no Quadro 8. Na linha 3 informa-se o nome da conexão; na linha 4 informa-se a URL;
na linha 5 informa-se o driver para conexão; na linha 6 informa-se o usuário do banco
de dados; e, na linha 7 informa-se a senha desse usuário

QUADRO 8 - Arquivo postgre-ds.xml


1 <datasources>
2 <local-tx-datasource>
3 <jndi-name>dw_tcc</jndi-name>
4 <connection-
url>jdbc:postgresql://localhost:5432/dwtcc</connection-url>
5 <driver-class>org.postgresql.Driver</driver-class>
6 <user-name>postgres</user-name>
7 <password>postgres</password>
8 </local-tx-datasource>
9 </datasources>

Para a pasta pentaho.war (...\jboss\server\default\deploy\pentaho.war\WEB-


INF), devem ser incluídas referências para a fonte de dados nos arquivos web.xml e
jboss-web.xml.
O Quadro 9 apresenta um fragmento do código que deve ser incluido no
arquivo web.xml. Na linha 3 informa-se a descrição; na linha 4 informa-se a referencia
a conexão; na linha 5 informa-se a classe Java responsável pela conexão; na linha 6
informa-se o autor.

QUADRO 9 - Fragmento de código do arquivo web.xml


1 ...
2 <resource-ref>
52

3 <description>dw_tcc</description>
4 <res-ref-name>jdbc/dw_tcc</res-ref-name>
5 <res-type>javax.sql.DataSource</res-type>
6 <res-auth>Container</res-auth>
7 </resource-ref>
8 ...

No Quadro 10 é apresentado um fragmento de código para configuração do


arquivo jboss-web.xml. Na linha 3 é informado a referencia a conexão; na linha 4
informa-se a classe Java responsável pela conexão; e, na linha 5 informa-se o nome da
conexão.

QUADRO 10 - Fragmento de código do arquivo jboss-web.xml


1 ….
2 <resource-ref>
3 <res-ref-name>jdbc/dw_tcc</res-ref-name>
4 <res-type>javax.sql.DataSource</res-type>
5 <jndi-name>java:/dw_tcc</jndi-name>
6 </resource-ref>
7 ...

Por fim, para a pasta lib (...\pentaho-demo\jboss\server\default\lib), deve ser


incluído o driver de conexão para a fonte de dados, neste caso foi o conector
postgresql-8.3-603.jdbc2.jar.

4.7 Configuração do Cubo

O próximo passo é gerar o cubo com os dados que devem aparecer no


módulo Pentaho Analysis. O Pentaho Analysis é a interface final do usuário,
desenvolvida sobre o engine Mondrian OLAP, que é um servidor OLAP, ou seja, o
software responsável por prover os recursos de gerenciamento de dados em um DW.
O Mondrian é configurado através esquemas, que são arquivos XML criados
em uma estrutura específica utilizada pelo engine. Neste trabalho, descreve-se a
configuração dos cubos com a utilização da ferramenta Schema Workbench. Um
tutorial descrevendo outra ferramenta (Cube Designer) é apresentado no Apêndice A.
53

Apesar desta última ferramenta ser bastante utilizada na comunidade Pentaho, a


mesma encontra-se descontinuada.
O Schema Workbench é uma interface de design que permite a criação e o
teste de esquemas de cubos OLAP (arquivos XML) do Mondrian. Esses modelos
XML utilizam as tabelas de Fatos e Dimensões encontradas no banco de dados do
Data Warehouse criado.
O Schema Workbench fornece as seguintes funcionalidades:
 Editor de esquema integrado, apresentando a fonte dos dados no rodapé,
para validação;
 Teste das consultas MDX nos esquemas e nas bases de dados;
 Visualização da estrutura da base de dados.

FIGURA 23 - Conexão com o cubo de dados no Schema Workbench

As propriedades de conexão com o cubo de dados são configuradas através


do menu Tools > Preferences (Figura 23). Devem ser informados:
 O nome da classe de conexão do driver do banco de dados;
 A URL da conexão com o banco de dados;
 O usuário e a senha;

Ao criar um novo esquema ou abrir um já existente, o Schema Workbench


verifica se as tabelas e colunas definidas no cubo existem realmente na base de dados.
Para criar ou editar elementos nos esquemas, o Workbench valida as
modificações nas tabelas e colunas do cubo de dados. O procedimento para
54

configuração das estruturas da engine Mondrian são detalhadas através do passo-a-


passo seguinte:
a) Clica-se em File>New>Schema para criar um novo esquema;
b) Com o botão direito do mouse clica-se em Schema>Add cube para
adicionar um novo cubo (Figura 24);

FIGURA 24 - New Cube

c) Seleciona-se Table e, se for caso, seleciona-se a tabela Fatos;


d) Clica-se com o botão direito do mouse no novo cubo criado e seleciona-se
Add Measure, para criar uma nova medida;
e) Na nova medida criada, escolhe-se um agregador, por exemplo, soma, e
seleciona-se a coluna e o tipo de dado (Figura 25);

FIGURA 25 - New Measure

f) Para criar uma nova dimensão, clica-se com o botão direito e seleciona-se
Add Dimension;
g) Seleciona-se a chave estrangeira adequada para a dimensão e atribui-se
um nome (Figura 26);
55

FIGURA 26 - New Dimension

h) Para expandir uma hierarquia nesta dimensão, seleciona-se Add


Hierarchy;
i) No nome da hierarquia, seleciona-se Primary Key para chave primária e
atribui-se um nome a tabela (Figura 27);

FIGURA 27 - New Hierarchy

j) Clica-se com o botão direito em Hierarchy e adiciona-se o nível;


k) Seleciona-se o nome do nível, a tabela e as colunas (Figura 28).
56

FIGURA 28 - New Level

Ao final, repetir os mesmos procedimentos para atribuir mais dimensões e


medidas. A Figura 29 mostra o cubo finalizado, com a opção de visualizar o XML do
cubo em View>View XML.

FIGURA 29 - Visualização do cubo criado

Após criar o arquivo XML que representa a estrutura do cubo, o próximo


passo é criar o arquivo XACTION (Action Sequence ou seqüência de ação). Esta etapa
57

é ralizada com o Pentaho Design Studio, que é um ambiente gráfico para a construção
e teste de documentos Action Sequence.
O Design Studio é baseado no Eclipse, que é uma IDE open source para
desenvolvimento de projetos. O Eclipse fornece uma série de vantagens, incluindo a
capacidade de integrar diferentes ferramentas comuns, embora mantendo a reutilização
de componentes existentes, bem como uma enorme economia no tempo de
desenvolvimento.
O arquivo XACTION é um documento XML, que contém a estrutura de
como o Analysis deve mostrar os dados, indica qual arquivo XML do Mondrian (cubo)
é utilizado e quais ferramentas são disponibilizadas.
As instruções abaixo devem ser seguidas para criar um arquivo XACTION:

a) No Pentaho Design Studio, cria-se um novo projeto em file/new/project.


Na tela que aparece, seleciona-se a opção java/java project e clica-se em
Next. Na tela seguinte, coloca-se um nome para o projeto. Em Contents,
seleciona-se a segunda opção e informa-se o diretório em que o arquivo
deve ser salvo (por exemplo, samples/analysis) e clica-se em Next. Na
nova tela, pressiona-se o botão Finish (Figura 30);

b) Depois do projeto ter sido criado, clica-se com o botão direito em cima
do projeto. Seleciona-se BI Plataform/New Action Sequence. Em File
Name, coloca-se o nome do cubo (o mesmo nome usado para criar o
arquivo .mondrian.xml) como nome_cubo.xaction e em template,
seleciona-se a opção Create an Analysis View e clica-se em Finish
(Figura 31);

c) No menu Define Process, em Analysis View; no campo Data Model,


seleciona-se o arquivo .mondrian.xml (no caso samples/analysis/nome_
cubo.mondrian xml) e em Data Source informa-se o nome da conexão
com o banco de dados (por exemplo, meu_bd). No menu General, no
campo Author, atribui-se o nome do autor, e no campo Title, um nome
para o DW. No menu Test, salva-se o arquivo .xaction. Em Pentaho
58

Server URL, informa-se a url para o Pentaho (http://localhost:


8080/pentaho) e clica-se em Test Server. Para informar a Generated
URL, deve-se clicar no botão Generate URL. Depois de aparecer uma url
do como: <http://localhost:8080/pentaho/ViewAction?&solution=sam
ples&path=analysis& action=nome_ cubo.xaction> (Figura 32).

FIGURA 30 - Analysis View


59

FIGURA 31 - New Action Sequence

FIGURA 32 - Define Process


60

O Quadro 11 apresenta um exemplo de XACTION gerado pelo Design


Studio para o estudo de caso apresentado neste trabalho.

QUADRO 11 - Exemplo de arquivo XACTION


1 <?xml version="1.0" encoding="UTF-8"?>
2 <action-sequence>
3 <name>analysis_default.xaction</name>
4 <title>TCC Analysis View</title>
5 <version>1</version>
6 <logging-level>ERROR</logging-level>
7 <documentation>
8 <author>Marcelo Vargas</author>
9 <result-type>AnalysisView</result-type>
10 <icon>analysis_default.png</icon>
11 </documentation>
12
13 <inputs>
14 <mode type="string">
15 <default-value/>
16 <sources>
17 <request>mode</request>
18 </sources>
19 </mode>
20 </inputs>
21
22 <outputs>
23 <model type="string"/>
24 <connection type="string"/>
25 <mdx type="string"/>
26 <options type="list"/>
27 <title type="string"/>
28 <url type="string">
29 <destinations>
30 <response>redirect</response>
31 </destinations>
32 </url>
33 </outputs>
34
35 <resources/>
36
37 <actions>
38 <action-definition>
39 <component-name>PivotViewComponent</component-name>
40 <action-type>Analysis View</action-type>
41 <action-inputs>
42 <mode type="string"/>
43 </action-inputs>
44 <action-outputs>
45 <model type="string"/>
46 <connection type="string"/>
47 <mdx type="string"/>
48 <options type="list"/>
49 <title type="string"/>
50 <url type="string"/>
61

51 </action-outputs>
52 <component-definition>
53 <title>Analysis View</title>
54 <viewer>Pivot</viewer>
55 <options>
56 <personal/>
57 <cube-nav/>
58 <mdx-edit/>
59 <sort-conf/>
60 <spacer/>
61 <level-style/>
62 <hide-spans/>
63 <properties/>
64 <non-empty/>
65 <swap-axes/>
66 <spacer/>
67 <drill-member/>
68 <drill-position/>
69 <drill-replace/>
70 <drill-thru/>
71 <spacer/>
72 <chart/>
73 <chart-conf/>
74 <spacer/>
75 <print-conf/>
76 <print-pdf/>
77 <spacer/>
78 <excel/>
79 </options>
80 <query><![CDATA[default]]></query>
81 <model><![CDATA[pentaho-demo\pentaho-
82 solutions\samples\analysis\tcc.mondrian.xml]]></model>
83 <jndi><![CDATA[dw_tcc]]></jndi>
84 </component-definition>
85 <action-name>Pivot View</action-name>
86 <logging-level>DEBUG</logging-level>
87 </action-definition>
88
89 </actions>
90 </action-sequence>

4.8 Visualização do Data Warehouse

O Pentaho Analysis apresenta as funcionalidades gerais para visualização do


cubo configurado. Nas ferramentas disponíveis, destaca-se a opção que exporta os
dados extraídos para Excel e a opção OLAP Navigator, que oferece filtros altamente
customizáveis para relacionar informações do cubo.
Outras funcionalidades relevantes são as operações de Drill Up e Drill
Down, que consistem, respectivamente, em agregação de métricas e detalhamento das
62

métricas. Esta opção é indicada pelo sinal de + e - ao lado das colunas.

Os principais recursos da barra de ferramentas são:

a) OLAP Navigator: Define o layout geral da query, como as colunas e


linhas a serem exibidas e os campos para os filtros. Pode-se, através desse
ícone, modificar as estruturas das pesquisas OLAP, visualizando e
adicionando ou removendo dimensões ao cubo propriamente dito (Figura
33);

FIGURA 33 - OLAP Navigator

b) MDX: o Analysis utiliza a MDX Query Language para definir queries


multidimensionais (Figura 34);

FIGURA 34 - MDX
63

c) Config OLAP Table: permite configurar a tabela gerada pelo cubo.


Oferece recursos como manter a hierarquia ascendente ou descendente,
importantes para uma melhor visualização das pesquisas (Figura 35).

FIGURA 35 - Config OLAP Table

d) Show Parent Members: mostra os parent members para as linhas ou


colunas, ou seja, preenche os espaços vazios na tabela com os membros
pais para cada nível nas suas respectivas linhas (Figura 36);

FIGURA 36 - Show Parent Members

e) Hide Spans: retira cabeçalhos repetidos em resultados comuns. Esta


opção realiza uma tarefa parecida com a ferramenta anterior, porém com
relação às colunas (Figura 37);
64

FIGURA 37 - Hide Spans

f) Show Properties: através da ativação dessa opção tornam-se visíveis as


propriedades das dimensões expandidas (Figura 38);

FIGURA 38 - Show Properties

g) Suppress Empty Rows / Columns: mais uma função importante na boa


visualização da tabela. Espaços em branco (coluna Measures na Figura
30) são ocultados (Figura 31) por esta ferramenta para uma melhor
visualização (Figura 39);
65

FIGURA 39 - Suppress Empty Rows/Columns

h) Swap Axes: realiza a inversão entre linhas/colunas e colunas/linhas; É


equivalente à operação de Dice – rotação para visualizar o cubo sobre
outra perspectiva (Figura 40);

FIGURA 40 - Swap Axes

i) Drill buttons: pode-se escolher entre os itens j, k, l e m para refinar uma


operação de Drill down ou Drill up;
j) Drill Member: Em Drill Member, quando expande-se uma dimensão,
todas as instâncias do membro são expandidas (Figura 41);
66

FIGURA 41 - Drill Member

k) Drill Position: seguindo o Drill Member, apenas o membro selecionado é


expandido, mesmo que existam outras instâncias do mesmo membro
(Figura 42);

FIGURA 42 - Drill Position

l) Drill Replace: essa opção permite agregar linhas ou colunas durante o


Drill down (Figura 43);
67

FIGURA 43 - Drill Replace

m) Drill Through: adiciona uma seta indicativa nos Fatos apresentados para
possível visualização mais específica do usuário (Figura 44);

FIGURA 44 - Drill Through

n) Show Chart: permite a construção de gráficos para análise dos dados em


outra visão (Figura 45);

FIGURA 45 - Show Chart


68

o) Chart Config: como alguns gráficos ficam desconfigurados pelo grande


número de colunas, ou pelo tamanho dos nomes das mesmas, essa
ferramenta permite configurar fatores que possam tornar o gráfico mais
apresentável (Figura 46);

FIGURA 46 - Chart Config

p) Configure Print Settings: permite a configuração de opções de impressão


(Figura 47);

FIGURA 47 - Configure Print Settings

q) Print This Page Via PDF: gera um documento em formato PDF com a
tabela em questão (Figura 48);
69

FIGURA 48 - Print This Page Via PDF

r) Start Excel: gera um documento de planilha eletrônica, no formato XLS


(MS Excel), com a tabela em questão (Figura 49).

FIGURA 49 - Start Excel

4.9 Conclusão

O Pentaho é um pacote completo para criar aplicações de Business


Inteligence. O JPivot e o Mondrian são as principais ferramentas constantes no pacote
do Pentaho e alvo do trabalho aqui apresentado. O Mondrian é responsável por
implementar um servidor OLAP, enquanto o JPivot é usado para implementar a
interface final do usuário.
Este capítulo foi muito importante para demonstrar o uso da plataforma
Pentaho, através do estudo de caso pode-se mostrar todo o potencial de
desenvolvimento com soluções de Business Intelligence em software livre.
Com o conhecimento obtido no desenvolvimento do trabalho e descritos nos
capítulos anteriores viu-se a importância desta ferramenta por ser completa para
desenvolvimento de Business Intelligence.
Devida a falta de documentação, algumas dificuldades foram encontradas
durante o desenvolvimento do trabalho, mas muitas delas resolvidas através da
70

comunidade Pentaho-br, e com esta interação na lista possibilitou ainda contribuir


com outros desenvolvedores com as mesmas dificuldades.
71

5 CONSIDERAÇÕES FINAIS

As contribuições deste trabalho acadêmico consistem no estudo de uma


tecnologia existente para o auxílio às pequenas empresas que têm limitações no
desenvolvimento de aplicações para a tomada de decisão, devido ao seu alto custo.
Com a suíte de ferramentas Pentaho, o desenvolvedor pode criar aplicações completas
para Business Intelligence.
As contribuições de cunho social, baseiam-se no fato de que este estudo
serve como base para a disseminação de tecnologias de software livre e Data
Warehouse em pequenas empresas no Brasil e para o domínio da mesma, além da
redução no seu custo.
Diante deste cenário, foi descrito um estudo de caso de desenvolvimento de
um Data Warehouse em uma empresa de reflorestamento, de forma a coletar,
consolidar e analisar informações referentes às práticas institucionais que possam
futuramente servir de base para uma melhor compreensão e um melhor planejamento
da empresa.
Os objetivos específicos propostos para o trabalho foram alcançados. Foi
apresentada a plataforma Pentaho BI, com a descrição de sua arquitetura e dos
principais softwares que compõe esta suíte. Além disso, foi elaborado um estudo de
caso que demonstra, passo-a-passo, o uso do Pentaho para criação de um Data
Warehouse simples.
Como alternativas de trabalhos futuros, sugere-se aplicar os conhecimentos
aqui apresentados em um caso de empresa real, com o objetivo de validar as
informações que podem ser obtidas com o uso de um Data Warehouse. Além disso,
este estudo de caso pode avançar no estudo das ferramentas disponíveis no Pentaho,
procurando melhorar a interface com o usuário final e apresentar novos recursos que
72

não foram utilizados neste trabalho. Neste estudo de caso real, podem-se encontrar
situações não previstas aqui, como a necessidade de mais de um cubo no DW,
retratando processos de negócios diferentes, além de prováveis problemas de
modelagem de bancos de dados transacionais.
Para estudos mais avançados, a plataforma Pentaho BI também disponibiliza
ferramentas para a realização de processos de mineração dos dados (Data Mining). O
estudo destas ferramentas abre outras frentes para descoberta do conhecimento em
bancos de dados corporativos.
73

REFERÊNCIAS BIBLIOGRÁFICAS

BORTOLINI, A. L. de. Um projeto de data warehouse. Disponível em:


<http://materdei.ceicom.com.br/arquivos/Um%20Projeto%20de%20Data%20Werehou
se.pdf>. Acessado em: 10 out. 2008.

DATAMIND TECHONOLOGY CENTER. Data mining for competitive advantage.


1998. Disponível em: <http://www.datamindcorp/paper_advantage.html>. Acessado
em: 16 jan. 2007.

FROZZA, A. A. Data warehouse: modelagem dimensional. Notas de Aula da


disciplina Data Warehouse. Lages: UNIPLAC, 2008.

HEINRICHS, J. H.; LIM, J. Integrated web-based data mining tolls with business
models for knowledge management. Decision Support Systems, v. 35, n. 1, p. 103-
112, 2003.

HOKAMA, D. D. B. et al. A modelagem de dados no ambiente Data Warehouse.


2004. 121 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de
Informação) – Faculdade de Computação e Informática, Universidade Presbiteriana
Mackenzie. Disponível em: <http://meusite.mackenzie.com.br/rogerio/tgi
/2004ModelagemDW.pdf>. Acessado em: 20 mai. 2008.

INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Campus, 1997.


387 p.

KIMBALL, R. Data Warehouse Toolkit. São Paulo: Makron Books, 1997. 388 p.

MACDONALD, G. C.; RUBIK, J. R. Pesquisa e seleção de ferramentas livres e


baseadas em padrões de sistemas abertos para a elaboração de interfaces OLAP
sobre a web. 2007. 114 p. Trabalho de Conclusão de Curso (Bacharelado em Sistemas
de Informação) - Departamento de Informática e Estatística, Universidade Federal de
Santa Catarina, Florianópolis, 2007.

MACHADO, F. N. R. Tecnologia e projeto de Data Warehouse: uma visão


multidimensional. São Paulo: Érica, 2004. 318 p.

MICROSOFT. Microsoft Corporation. Disponível em: <http://www.microsoft.com>.


Acessado em: 01 mai. 2008.

PERNAS, A. M. da R. Modelagem de um Data Webhouse voltado a produção e


comercialização de sementes. 2003. 70 f. Trabalho de Conclusão de Curso
(Bacharelado em Ciência da Computação) – Instituto de Física e Matemática,
74

Universidade Federal de Pelotas, Pelotas. Disponível em: <http://www.ufpel.edu.br/


prg/sisbi/bibct/acervo/info/2003/mono_ana_pernas.pdf>. Acessado em: 20 mai. 2008.

SHIGUNOV, F. Uma Aplicação OLAP sobre a Web para Análise dos Dados do
Vestibular da UFSC e Diretrizes para a sua Integração com GIS. 2007. 88 f.
Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) -
Departamento de Informática e Estatística, Universidade Federal de Santa Catarina -
UFSC, Florianópolis.

TEMATEC. Por dentro da Pentaho Open BI Suite: Conceitos, Arquitetura e


Componentes. Disponível em: <http://br.groups.yahoo.com/group/pentahobr/>.
Acessado em: 05 set. 2008.

TORRES, N. A. Competitividade empresarial com a tecnologia de informação.


São Paulo: Makron Books, 1995. 230 p.
75

BIBLIOGRAFIA COMPLEMENTAR

BALLARD, C.; HERREMAN, D. Data Modeling Techniques for Data


Warehousing. IBM, International Technical Support Organization, February, 1998.

BARBIERI, C. Business Intelligence: modelagem e tecnologia. Rio de Janeiro: Axcel


Books, 2001.
BISPO, C. A. F. Uma Análise da Nova Geração de Sistemas de Apoio à Decisão.
1998. 174 f. Dissertação (Mestrado em Engenharia de Produção) - Departamento de
Engenharia da Produção, Universidade de São Paulo - USP, São Paulo.
BOUMAN, Roland. Pentaho Data Integration: Kettle turns data into business.
Disponível em: <http://rpbouman.blogspot.com/2006/06/pentaho-data-integration-
kettle-turns.html>. Acessado em: 08 out. 2008
FELBER, E. J. W. Proposta de uma ferramenta OLAP em um Data Mart
comercial: Uma aplicação prática na industria calçadista. 1997. 156 f. Trabalho de
Conclusão de Curso (Bacharelado em Ciência da Computação) – Instituto de Ciências
Exatas e Tecnológicas, Centro Universitário Feevale, Novo Hamburgo, 1997.
MARTINS, Mario Pereira. CARVALHO, Juliano Varela. WIVES, Leandro Krug.
Analysis: uma proposta de ferramenta OLAP-Web para a análise de informações
ambientais do Vale do Rio dos Sinos. UFRGS, 2005. Disponível em:
<http://ccet.ucs.br/erbd2007/artigos/26041.pdf>. Acessado em: 10 out.2008.
PENTAHO. Pentaho Open Source Business Intelligence. Disponível em:
<http://www.pentaho.com>. Acessado em: 12 out. 2007.
76

APÊNDICES

APÊNDICE A – PENTAHO CUBE DESIGN ..........................................................77


APÊNDICE B – PENTAHO DATA INTEGRATION ............................................82
APÊNDICE C - ARTIGO ...........................................................................................88
77

APÊNDICE A – PENTAHO CUBE DESIGN

A fim de utilizar um modelo personalizado de dados no servidor Pentaho, é


necessário que se crie um arquivo Mondrian Cube Schema que contém a definição de
cubos OLAP. O arquivo descreve dimensões, hierarquias, níveis, fatos e o
mapeamento para um modelo de dados relacionais.
No entanto, criar esse arquivo manualmente pode ser uma tarefa que
consome tempo. Assim, é altamente recomendado usar o software Pentaho Cube
Designer para criar esses arquivos. O problema é que a versão atual (Pentaho Cube
Designer 0.7.2.0) tem as suas limitações, não suporta todas as características do
Mondrian Schema e pode não funcionar com modelos de dados muito complexos. Ele
não suporta agregação, dimensões partilhadas, inline tables, calculated members e
cubos de múltiplos arquivos dentro do mesmo esquema.
Apesar disso, o Pentaho Cube Designer é ainda um produto útil ao certo que
pode ser usado como um bom ponto de partida para a criação de modelos no servidor
Pentaho. Ao esconder a lógica dos modelos de dados multidimensionais sob uma
interface gráfica simples, o Cube Designer pode ser utilizado como uma ferramenta
básica para criar mapeamentos e, em seguida, os recursos avançados podem ser
facilmente adicionados manualmente, editando o arquivo de mapeamento Schema
XML ou usando o software Schema Workbench.
Antes de iniciar com as instruções, para usar o Pentaho Cube Designer são
necessários os seguintes componentes:
 JRE 1.5;
 Firebird / Postgres / MySQL/ Oracle/ Hibernate ou qualquer base de
dados concordante com o JDBC;
 Servidor Pentaho (PCI);
 Windows / Linux (RedHat/Suse) / Mac OSX (PPC/Carbon)
78

Esse aplicativo suporta qualquer base de dados concordante com o JDBC. Os


drivers JDBC para os bancos de dados Oracle, MySQL, Microsoft SQL Server e
Hibernate são incluídos na distribuição do software. Caso seja necessário acessar outra
base de dados concordante com JDBC, os drivers necessários precisam ser copiados
para a pasta CubeDesigner/lib/jdbc. Neste caso foi utilizado Firebird.
Abaixo algumas instruções passo a passo sobre como criar um simples Cubo
Mondrian usando Pentaho Cube Designer.

A.1 Informações básicas do Cubo

O primeiro passo é fornecer informações básicas que é o nome do cubo e sua


descrição. O nome deve ser simples e descritivo, uma vez que é utilizado nas
definições e arquivos de configuração ao longo de todas as aplicações Pentaho BI.
Na parte de baixo da tela, define-se a ligação à uma base de dados da fonte
de dados. Existe um assistente que torna realmente fácil de configurar uma conexão e
testá-la. Outra maneira que pode ser configurada a conexão com o banco é através do
conteúdo do arquivo jdbc.properties, dentro da pasta resources\system\simple-jndi. Na
sequência do tutorial é criado um cubo, chamamos a conexão de DW e usado como
fonte de dados Firebird.

FIGURA 50 - Nome do cubo, descrição e conexão de dados


79

A.2 Mapeamento de tabelas

Na tela Map Tables é definido o modelo de dados e um cubo que é criado. Os


quadros podem ser selecionados com um duplo clique no canto inferior esquerdo do
painel ao lado da janela. As ligações entre as tabelas podem ser facilmente criadas
arrastando e soltando os principais domínios e os domínios-alvo podem ser
selecionadas, clicando em uma caixa de seleção ao lado do campo desejado. Aqui
também pode ser adicionado cláusulas WHERE, agrupamentos e ordenação dos
registros.
Na tela abaixo, é selecionada as tabelas e cria-se o esquema necessário,
inclusive o esquema estrela ou snow flake. Após a criação do esquema, as colunas são
selecionadas para as métricas e dimensões e clique em Next.

FIGURA 51 - Esquema relacional de dados

B.1 Seleção da tabela de fato e criação de medidas

Após selecionar e configurar a fonte, o próximo passo é apontar tabela de


fatos e selecionar os campos. Neste exemplo, é utilizado os seguintes campos
numéricos: VALOR PEDIDO e FRETE.
Pode ser alterado o tipo de agregação aqui (tipos disponíveis são: SUM,
AVG, COUNT, MIN, MAX), o formato dos valores numéricos e os nomes das
colunas.
80

FIGURA 52 - Criação das medidas

B.2 Criando dimensões

O próximo passo é criar dimensões no cubo. Para criar uma dimensão, é


selecionado o campo de source fields, que é o mais elevado na hierarquia e clica-se no
botão Add New Dimension e logo após o nome da dimensão é digitado. Utiliza-se as
teclas de seta para criar níveis.
Por exemplo, para criar uma dimensão Clientes, após selecionar o
ID_CLIENTE, com o botão Add New Dimension renomeia-se, e ao fim, finaliza-se.
Em seguida, selecionando os campos NOME e BAIRRO em conformidade, clica-se na
seta para a direita, para cada uma delas e assim, criando os próximos níveis na
hierarquia (Figura 53).

C.1 Salvar o arquivo schema

O botão View XML é utilizado para vizualizar o arquivo de configuração do


conteúdo, em seguida, com o botão Publish para publicar a especificação do cubo
Mondrian no site do Pentaho (PCI). Especifica-se os parâmetros para a publicação e
depois, finaliza-se. O arquivo XML gerado pode ser salvo em algum local desejado
pelo usuário. Em Finish seleciona-se o diretório em que será salvo e, após
81

especificado, salvar em Save. Os arquivos criados são Mondrian Cube Schema,


Pentaho XACTION e Pentaho properties.

FIGURA 53 - Criação das dimensões


82

APÊNDICE B – PENTAHO DATA INTEGRATION

O Pentaho Data Integration – PDI (antigamente conhecido como Kettle) é


uma suíte de ferramentas gratuitas dedicada a Business Inteligence (BI), capaz de
realizar operações de extração, transformação, transporte e carga de dados (ETL –
Extraction, Transformation and Loading), que são as quatro operações típicas
realizadas para se criar um Data Warehouse.
O Pentaho Data Integration trabalha com ferramentas distintas para realizar
cada etapa do processo e a interação entre as mesmas é fluente e intuitiva. A
ferramenta Spoon apresenta uma interface gráfica para criação de transformações de
dados e a ferramenta Pan é responsável pela execução dessas transformações. Para
criar jobs (rotinas que são periodicamente executadas) é utilizada a ferramenta Chef e
sua execução se faz pela ferramenta Kitchen. Estas operações são salvas em formato
XML, mantendo assim um formato de fácil entendimento. Mais detalhes sobre as
ferramentas que fazem parte do Pentaho Data Integration (BOUMAN):
 Spoon: é uma ferramenta para o usuário final modelar o fluxo de entrada
de dados através da transformação.
 Pan: executa os comandos de transformações modelados com o Spoon;
 Chef: é uma ferramenta gráfica orientada para o usuário final modelar
Jobs;
 Jobs trabalha constituído de entradas como transformações, FTP etc., que
estão colocados em um fluxo de controle;
 Kitchen: é uma ferramenta usada para executar trabalhos criados com o
Chef.
O PDI foi desenvolvido em Java e, por isso, requer que a Máquina Virtual
Java esteja instalada no computador para ser utilizado. Por este motivo, o PDI é
independente de plataforma, ou seja, qualquer sistema operacional que possua uma
JVM (Java Virtual Machine) é compatível com o PDI.
83

A.1 Conexão com o repositório

A primeira parte do tutorial de ETL explica como criar uma simples


transformação utilizando a aplicação Spoon. A transformação, neste exemplo, lê
registros de uma tabela em um banco de dados Firebird e, em seguida, seleciona
valores para depois, carregá-los no banco de dados do Data Warehouse.
Assumindo que a aplicação está instalada corretamente, a primeira coisa a
fazer depois é executá-la para configurar um repositório. Uma vez que a janela
Selecionar um repositório é exibido, é necessário criar ou escolher um repositório. Um
repositório é um local onde todos os objetos são armazenados. Neste exemplo, é um
banco de dados Firebird.
Para criar novos repositórios clica-se em New. Uma opção muito útil na tela
é um botão chamado Test, que permite aos usuários testar novas conexões, há outro
botão chamado Explorer, que permite que os usuários naveguem no schema do banco
de dados e de explorar a base de dados. Depois de clicar no Create or Upgrade um
novo repositório é criado. Por padrão, um usuário com direitos de Administrador é
criado, nome de login é admin e a senha também é admin. É altamente recomendável
alterar a senha depois do primeiro login.

FIGURA 54 - Conexão com o repositório

O PDI possui suporte nativo a diversos bancos de dados, utilizando vários


drivers diferentes (JDBC, ODBC etc.), o que viabiliza a conexão e junção de diversas
bases de dados de maneira simples e intuitiva.
84

Uma outra funcionalidade simples, porém eficiente e necessária, fornecida


pelo PDI é a possibilidade de executar comandos SQL diretamente da aplicação. Uma
vez criada uma conexão a um banco de dados qualquer, o Kettle fornece uma janela
que o usuário pode digitar comandos SQL e executá-los de maneira simples e rápida.

FIGURA 55 - Editor SQL

A.2 Criando uma transformação

O PDI possui diversos passos de transformação. Uma breve definição vai é


citada sobre alguns deles.
O setor administrativo de uma empresa pode armazenar os dados de seus
clientes em um banco de dados Firebird. É interessante importarmos os dados desse
banco para o Data Warehouse ao final do dia. Então, é necessário criar uma nova
transformação no PDI.
A criação de uma simples transformação no PDI pode retificar esta falta de
comunicação e fornecer melhorias para os sistemas de informação desta empresa,
como mostra a Figura 48 a seguir.

FIGURA 56 - Nova Tranformação


85

B.1 Entrada de dados

Feito isso, precisa-se criar uma entrada (input) para a transformação. Neste
exemplo, a entrada é a tabela CLIENTES utilizada para armazenar os dados dos
clientes.
No lado esquerdo da tela, em Core Objects> Input> Table Input arrastando o
step Table input para o espaço vazio, ao lado direito. Feito isso, pode editar o step,
dando dois cliques sobre ele. Escolha a conexão com o banco fonte que importa os
dados através do botão Get SQL select statement.
Neste exemplo, a tabela de clientes conta com os campos IDCLIENTE,
NOME e BAIRRO.
A qualquer momento é possível clicar no botão Preview para verificar se os
dados obtidos da tabela estão de acordo com o esperado. Isto ajuda a encontrar erros
de configuração e corrigi-los rapidamente, evitando que os mesmos causem um efeito
dominó na transformação criada.

FIGURA 57 - Entrada de dados


86

B.2 Selecionando valores

Agora, arrasta-se o step Select Values, localizado na aba Core Objects>


Tranform> Select values para informar ao PDI o nome de cada campo. Deve
selecionar a aba Fields e preencher os campos de acordo com o modelo indicado.
Editando o step do componente, pode-se informar quais os campos são exportados
para o banco de dados.

FIGURA 58 - Selecionando valores

É importante também dar um nome significativo ao Step, como Selecionando


Valores. Desta forma o diagrama gerado pelo PDI fica mais legível e intuitivo.

B.2 Inserção de dados

Considerando que o banco de dados no qual se insere os dados dos clientes já


possui uma tabela para isto, o primeiro passo é configurar uma conexão a este banco
de dados para a transformação, conforme foi descrito anteriormente em Conexão com
o Banco de Dados.
Para a inserção dos dados, é utilizado o step Insert/Update, localizado na aba
Core Objects> Output> Insert/Update e é preenchido os seguintes campos:
87

IDCLIENTE, NOME e BAIRRO. A aba Update Fields, não está marcado atualização
para IDCLIENTE, para que não haja a duplicação de ids.

FIGURA 59 - Insert / Update

Ao final, executa-se a transformação no botão Run, abre outra janela para


escolher se sua execução é local, remotamente ou através de clusteres. Escolha a
opção e clique no botão Launch. Finalizando, aparece uma tela com o log de execução
da transformação.
88

APÊNDICE C - ARTIGO

Construção de Data Warehouse para pequenas e médias


empresas usando software livre
Marcelo Feijó Vargas1, Angelo Augusto Frozza2
1
Departamento de Ciências Exatas e Tecnológicas
Universidade do Planalto Catarinense (UNIPLAC)
Av. Castelo Branco, 170 – 88.509-900 – Lages – SC – Brazil
{marcelofv, frozza}@uniplac.net

Abstract. Data Warehouse (DW) is a tool in the context of Business Intelligence


(BI). The BI is the set of technologies geared to provide information and knowledge
on a firm and includes tools like Customer Relationship Management (CRM), Data
Mining, Data Warehouse, among others. In this study attempts to demonstrate the
feasibility of developing a DW from tools distributed as free software, choose a free
software package for development of DW; demonstrate the use of the software
package through a case study. In conclusion, it is expected to help companies adopt
a posture of work more focused on information management and the creation of
competitive strategies.

Resumo. Data Warehouse (DW) é uma ferramenta no contexto do Business


Intelligence (BI). O BI é o conjunto de tecnologias orientadas a disponibilizar
informação e conhecimento em uma empresa e inclui ferramentas como Customer
Relationship Management (CRM), Data Mining, Data Warehouse, entre outras.
Neste trabalho busca-se demonstrar a viabilidade de desenvolvimento de um DW a
partir de ferramentas distribuídas como software livre; escolher um pacote de
software livre para desenvolvimento de DW; demonstrar o uso pacote do software
através de um estudo de caso. Concluindo, espera-se contribuir para que as
empresas adotem uma postura de trabalho mais voltada à gestão da informação e à
criação de estratégias competitivas.

1 Apresentação
O Data Warehouse (DW) é uma ferramenta no contexto do Business Intelligence (BI). O BI,
também conhecido por Inteligência de Negócios ou Inteligência Empresarial, é o conjunto de
tecnologias orientadas a disponibilizar informação e conhecimento em uma empresa e inclui
ferramentas como Customer Relationship Management (CRM), Data Mining, Data
Warehouse, entre outras.
As ferramentas de Business Intelligence (BI) são bastante difundidas entre empresas
de grande porte, porém, têm aplicação limitada em empresas de médio e pequeno porte,
principalmente devido ao alto custo das mesmas. Por outro lado, com o surgimento de
89

ferramentas que podem ser obtidas gratuitamente (ou a custos reduzidos), as médias e
pequenas empresas começam a se beneficiar dessa tecnologia para a tomada de decisão.
Neste trabalho busca-se: a) demonstrar a viabilidade de desenvolvimento de um DW a
partir de ferramentas distribuídas como software livre; b) escolher um pacote de software
livre para desenvolvimento de DW; c) demonstrar o uso pacote do software através de um
estudo de caso.
A estrutura deste artigo apresenta, inicialmente, uma visão geral do trabalho. Na etapa
seguinte, apresentou-se a ferramenta Pentaho, sua descrição e arquitetura. Na terceira etapa
foi descrito um estudo de caso e foram abordadas as fontes de informação OLTP (On-line
Transaction Processing) e o processo de Extração, Transformação e Carga (ETC) dos dados
referentes a este estudo de caso. A última etapa consistiu no processo de implementar o DW e
a interface OLAP, disponibilizando os recursos para análise de dados.

2 Plataforma Pentaho de Business Inteligence


A plataforma Pentaho é um conjunto de software open source para criação de soluções de BI
(Business Intelligence). Ela possui ferramentas para atender ao processo de criação de
soluções de BI de ponta-a-ponta, integrada à uma gama de opções para banco de dados e
outras ferramentas, conforme ilustra a Figura 1 [TEMATEC 2008].

Figura 1 - Diagrama de uma solução de BI


(FONTE: TEMATEC, 2008)

Quando uma organização precisa tomar uma decisão é indispensável ter dados
corretos e disponíveis para consulta. Para conseguir isso, ela deve tratar e consolidar as
informações armazenadas nos sistemas e fontes de dados que apóiam seu negócio em um
repositório centralizado, criando “uma única versão da verdade”, limpa e confiável (processo
ETL). Depois, pessoas que entendem do negócio da empresa devem ter acesso a esse
repositório e, usando ferramentas de visualização e exploração de dados, interpretá-los para
finalmente tomar uma decisão [TEMATEC, 2008].
O conjunto destes componentes de softwares, dados, operações e processos usados
para atender uma necessidade específica, para tomar uma decisão, são chamados de solução.
A Pentaho Inc. integrou e promoveu o desenvolvimento de várias ferramentas open
source que fornecem os recursos necessários para criação de soluções de BI. Esse conjunto é
conhecido por Pentaho Open BI Suite e inclui ferramentas para consolidar dados de fontes
diversas, criar interfaces visuais para exploração desses dados e montar soluções para
necessidades específicas [TEMATEC, 2008].
90

a) Arquitetura
O projeto Pentaho BI é constituído de um conjunto completo de ferramentas de BI e
bibliotecas que fornecem funcionalidades de BI aos desenvolvedores. É uma solução com
suporte a relatórios, análises, data mining e workflow, através de uma série de componentes
que podem ser distribuídos juntos ou separados [PENTAHO, 2007].
O servidor roda de acordo com o padrão de servidores Java, tais como Apache
TomCat e JBoss. Ele utiliza um método de desenvolvimento, distribuição e suporte que torna
possível o modelo de negócios open source [PENTAHO, 2007].
A Figura 2 apresenta a arquitetura do Pentaho, a qual é composta por componentes de
integração de dados, infra-estrutura e apresentação dos dados e a origem destes dados.

Figura 2 - Arquitetura do Pentaho BI


(FONTE: PENTAHO, 2007)

O Pentaho BI abrange, principalmente, as seguintes áreas de aplicação [PENTAHO,


2007]:

 Relatórios (Reporting): Fornece desde simples relatórios em uma página web,


até relatórios de alta qualidade, tais como relatórios de indicações financeiras e
relatórios ricos em conteúdos, como tabelas, gráficos, entre outros;
 Análises (Analysis): Permite consultas, exploração interativa com operações
slice-and-dice, drill-down e pivoting. Inclui front-end gráfico para exploração
dos cubos OLAP;
 Painéis (Dashboards): Reúne relatórios, análises e outras exposições em um
único local para simplificar o acesso, podendo ser customizado por usuário ou
assunto;
 Data mining: Descobre relacionamentos ocultos nos dados, que podem ser
utilizados para otimizar os processos de negócio e prever resultados futuros.
Permite que os resultados sejam exibidos em um formato de fácil entendimento
ao usuário;
91

 Workflow: Liga diretamente as medidas de desempenho de negócio aos


processos, promovendo um ciclo contínuo de melhorias.

Todos os componentes da plataforma são de código aberto. Neste trabalho são


analisados os seguintes componentes: Pentaho Cube Designer, Pentaho Workbench, Pentaho
Design Studio, OLAP Mondrian, Front-End JPivot Analysis, Pentaho Data Integration
(Kettle) Back-End e o servidor de aplicação JBoss.
O projeto Pentaho BI oferece uma solução que pode ser utilizada por desenvolvedores
Java, os quais podem utilizar os componentes do projeto para montar rapidamente soluções
BI sob medida. O Pentaho pode ser utilizado por empresas desenvolvedoras de software para
adicionarem as funcionalidades de BI em seus produtos. O projeto pretende, ainda, permitir
que usuários finais tenham acesso a soluções de BI com a qualidade dos softwares comerciais
tradicionais, porém com um custo bem mais acessível.

3 Estudo de Caso
Demonstra-se, através de um estudo de caso, como funciona o processo de desenvolvimento
de um Data Warehouse (DW) a partir da plataforma Pentaho. O processo de criação do DW
inicia pela análise de um sistema OLTP – On-line Transaction Processing de uma empresa de
reflorestamento fictícia. É feita a identificação dos dados atualmente utilizados para tomada
de decisão na empresa e, a partir desta análise, é realizada a modelagem dimensional do DW.
Logo após, é programado o processo de extração, transformação para posterior carga no DW.
Ao final, com a modelagem dimensional criada e o banco de dados do DW devidamente
preenchido, é feita a configuração do cubo para possibilitar a análise dos dados na plataforma
Pentaho.

a) Empresa
Neste trabalho busca-se o desenvolvimento de uma solução de DW. Esta seção tem por
finalidade descrever genericamente o funcionamento do controle de produção de uma
empresa de reflorestamento, baseado no estudo do software de gestão da empresa.
Posteriormente, com base nas características aqui levantadas, é feita a proposta de uma
aplicação de Data Warehouse para atender às necessidades deste setor.
A estrutura da empresa de reflorestamento é formada por operadores, gerência
comercial e pessoal de apoio. A gerência comercial é responsável pelo controle dos
operadores e acompanhamento dos transportes dos produtos. O pessoal de apoio é
responsável pelo trabalho burocrático do setor, como atendimento a clientes, cadastramento
de produtos, condições de pagamento, interação com as transportadoras e operadores.
O cliente faz o pedido para o pessoal de apoio. O pedido contém uma determinada
data de entrega, a condição de pagamento, a transportadora que faz a entrega e os itens do
pedido, que são os produtos comprados pelo cliente.
O sistema OLTP, que faz o controle de cargas é de grande importância para a empresa,
mas apresenta carência de informações estratégicas e não responde a questões que têm origem
no cruzamento de dados, como: quais os melhores clientes por período do ano, total das
saídas de cargas por cliente no mês, valor total de vendas no dia, mês ou ano e quantidade
transportada.
92

No levantamento das informações, fica claro a necessidade de uma aplicação que


apresente as informações estratégicas aos dirigentes da empresa, diretamente da origem dos
dados, para que possam visualizá-las e utilizá-las na tomada de decisão.
Os dados do sistema OLTP estão disponíveis no SGBD (Sistema Gerenciador de
Banco de Dados) FireBird, versão 2.0.

b) Processo ETL
Os detalhes do povoamento do Data Warehouse são explicados neste tópico através da
dimensão TEMPO. Foi utilizado no projeto a ferramenta de código aberto chamada Kettle,
que é distribuída pela Pentaho Inc. e auxilia a integração de dados e a construção do DW.
A dimensão TEMPO apresenta um pouco mais de complexidade, comparada com as
anteriores. Os dados dessa dimensão não vêm do banco OLTP, pois são gerados pelo processo
de ETC e posteriormente são relacionados na tabela de Fatos:
a) Add Sequence: definem-se e selecionam-se números seqüenciais (conjunto de valores
com um valor inicial e um valor de incremento definidos) para dias, meses e anos;
b) Join Rows: faz-se a união dos números com o produto cartesiano;
c) BuildDateInfo: executa-se com linguagem Java Script com cálculos para a validação
das datas;
d) Sort rows: selecionam-se os campos para a organização com base nos campos
especificados (dias, meses e anos);
e) Filter rows: filtram-se os campos, descartando as datas inválidas com base em
condições. Se a data é valida segue o campo para o step Add Sequence, se não for
válida segue para o step InvalidDateIgnore;
f) Add sequence: atribui-se um id para cada data criada, com valor inicial e final pré-
definidos;
g) Value mapper: define-se o mapeamento para os valores string, neste caso o nome do
mês;
h) Calculate: fornece um conjunto de funções pré-definidas que podem ser executadas
sobre os valores contidos nos campos, com base nisso, faz-se o cálculo para mostrar o
nome do mês;
i) Value mapper: define-se o mapeamento para mostrar o nome dia da semana;
j) Select values: selecionam-se os valores necessários para armazenar na dimensão
tempo;
k) Combination lookup/Update: escreve-se na dimensão DIM_TEMPO os dados
resultantes da transformação.
93

Figura 3 - Dimensão Tempo

c) Pentaho Workbench
O próximo passo é avaliar os softwares responsáveis pela criação do Pentaho Analysis. A
avaliação pode assumir muitas formas, mas esse esquema vai ajudar a orientar o processo de
avaliação Pentaho, fornecendo um recurso para a organização de usar e identificar os
componentes utilizados na plataforma Pentaho.
Pentaho Analysis é desenvolvido sobre o engine Mondrian OLAP. Os esquemas são
modelos de arquivos XML que são criados em uma estrutura específica utilizada pelo engine
Mondrian. A configuração dos cubos são descritos com a utilização do schema Workbench.
O Schema Workbench é uma interface de design que permite a criação e o teste de
esquemas de cubos OLAP do Mondrian. Esses modelos XML utilizam tabelas de fatos e
dimensões encontradas no ambiente de Data Warehouse criados.
O Schema Workbench fornece as seguintes funcionalidades:
 Editor de esquema integrado, apresentando a fonte dos dados no rodapé, para
validação;
 Teste das consultas MDX nos esquemas e nas bases de dados;
 Visualização da estrutura da base de dados.

As propriedades de conexão com o cubo de dados são configuradas através do menu


Tools > Preferences:
94

Figura 4 - Conexão Workbench

Ao criar um novo esquema ou abrir um já existente, o Workbench irá verificar se as


tabelas e colunas definidas no cubo existem realmente na base de dados.
Para criar ou editar elementos dos esquemas, o Workbench irá validar as modificações
pelas tabelas e colunas do cubo de dados. O procedimento para configuração das estruturas da
engine Mondrian são detalhadas através do passo a passo seguinte:
a) Clica-se em File>New>Schema para criar um novo esquema.
b) Com o botão direito do mouse clica-se em Schema>Add cube para adicionar um
novo cubo.
c) Seleciona-se table, e se for caso, seleciona-se a tabela fato.
d) Clica-se com o botão direito do mouse no novo cubo criado e seleciona-se Add
Measure, para criar uma nova medida.
e) Na nova medida criada, escolhe-se um agregador, como a soma, seleciona-se a
coluna e o tipo de dado.
f) Para criar uma nova dimensão, clica-se com o botão direito e seleciona-se Add
Dimension.
g) Seleciona-se a chave estrangeira adequada para a dimensão, e atribui-se um nome.
h) Para expandir uma hierarquia nesta dimensão, seleciona-se Add Hierarchy.
i) Nome da hierarquia, seleciona-se Primary Key para chave primária e atribui-se um
nome a tabela.
j) Clica-se com o botão direito em Hierarchy e adiciona-se o nível.
k) Seleciona-se nome do nível, a tabela e as colunas.
Ao final, repetir os mesmos procedimentos para atribuir mais dimensões e medidas,
assim como as medidas.

d) Pentaho Design Studio


Próxima fase com o Pentaho Design Studio que é aplicativo que oferece um ambiente gráfico
para a construção e teste de documentos Action Sequence e relatórios.
É baseado na aplicação Eclipse, que é um software open source para desenvolvimento
de projetos robusto. Potencialmente, Eclipse dá-nos uma série de vantagens, incluindo; um
existente bem conhecido e bem definido, a capacidade de integrar diferentes ferramentas
comuns, embora mantendo a reutilização de componentes existentes, bem como uma enorme
95

economia no tempo de desenvolvimento. Para este trabalho utilizaremos o Design Studio, no


desenvolvimento do arquivo XACTION.
O arquivo XACTION é um arquivo em XML que contém a estrutura de como o
Analysis mostrará os dados, qual XML do Mondrian será utilizado e quais ferramentas serão
disponibilizadas.
Segue-se as instruções abaixo para criar a sequência de ação:
a) No Pentaho Design Studio,cria-se um novo projeto em file/new/project; na tela que
aparece, seleciona-se a opção java/java project e clica-se em next;, na tela seguinte,
coloca-se um nome para o projeto, em Contents, seleciona-se a segunda opção e informa-
se o diretório onde o arquivo será salvo(samples/ analysis) e clica-se em Next; na nova
tela, pressiona-se o botão Finish.
b) Depois do projeto ter sido criado, clica-se com o botão direito em cima do projeto,
seleciona-se BI Plataform/New Action Sequence; em File Name coloca-se o nome do cubo
(o mesmo nome usado para criar o arquivo .mondrian.xml) como nome_cubo.xaction e em
template, seleciona-se a opção 'Create an Analysis View' e clica-se em Finish;
c) No menu Define Process, em Analysis View; no campo Data Model, seleciona-se o
arquivo .mondrian.xml ( no caso: samples/analysis/nome_cubo.mondrian xml) e em Data
Source informa-se o nome da conexão ao banco de dados (ex: meu_bd); no menu General,
no campo Author, atribui-se o nome e no campo Title, um nome para o DW. No menu
Test, salva-se o .xaction; em Pentaho Server URL, informa-se a url: http://localhost:
8080/pentaho e clica-se em Test Server; para informar a Generated URL, deve-se clicar
no botão Generate URL. Depois de aparecer uma url do como:
<http://localhost:8080/pentaho/ViewAction? &solution= samples&path= analysis&
action=nome_ cubo.xaction>.

e) Pentaho Analysis
O Pentaho Analysis apresenta as funcionalidades gerais, nas ferramentas disponíveis, destaca-
se a opção que exporta os dados extraídos para Excel, e a opção OLAP Navigator, que
oferece opções de filtro altamente customizáveis para relacionar informações do cubo.
Outras funcionalidades relevantes são a de Drill Up e Drill Down que consistem,
respectivamente, em agregação de métricas e detalhamento das métricas. Esta opção é
indicada pelo sinal de + e - ao lado das colunas.
Principais recursos da barra de ferramentas:
 OLAP Navigator: Define o layout geral da query, como as colunas, linhas a ser
exibidos e campos para os filtros. Pode através desse ícone modificar as estruturas
das pesquisas OLAP visualizando e adicionando ou removendo dimensões ao cubo
propriamente dito.
 MDX: o Analysis utiliza a MDX query language para definir queries
multidimensionais.
 Config OLAP Table: com o “Config OLAP Table”, podemos configurar a tabela
gerada pelo cubo, podem oferecer recursos importantes na melhor visualização das
pesquisas.
 Show Parent Members: mostra os "parent members" para as linhas ou colunas.
Preenche os espaços vazios na tabela com os “membros pais” para cada nível nas
suas respectivas linhas.
96

 Hide Spans: retira cabeçalhos repetidos em resultados comuns. Ela realiza uma
tarefa parecida com a ferramenta anterior, porém com relação às colunas
 Show Properties: através da ativação dessa opção tornamos visíveis as
propriedades das dimensões expandidas.
 Suppress Empty Rows / Columns: mais uma função importante na boa visualização
da tabela, espaços em branco são ocultados por esta ferramenta para uma melhor
visualização.
 Swap Axes: realiza a inversão entre linhas/colunas e colunas/linhas.
 Drill Member: podemos escolher entre os itens 9, 10, 11 e 12 para refinar um
“Drill down”. Em “Drill Member”, quando expandimos uma dimensão todas as
instâncias do membro serão expandidas.
 Drill Position: Seguindo o “Drill Member”, apenas o exemplo do membro clicado
será expandido, mesmo que existam outras instâncias do mesmo membro.
 Drill Replace: essa opção no permite como que agregar linhas ou colunas durante
o “Drill down”.
 Drill Through: adiciona uma seta indicativa na fatos apresentados para possível
visualização mais específica do usuário.
 Show Chart: permite a construção de gráficos para análise dos dados em outra
visão.
 Chart Config: como alguns gráficos ficam desconfigurados pelo número grande de
colunas, ou pelo tamanho dos nomes das mesmas, essa ferramenta permite
configurar fatores que possam tornar o gráfico apresentável.
 Configure Print Settings: permite a configuração de fatores de impressão.
 Print This Page Via PDF: gera um documento em formato PDF com a tabela em
questão.
 Start Excel: gera um documento em “xls” com a tabela em questão.

4 Considerações Finais
Com o advento da globalização, as empresas contemporâneas dos mais diversos setores de
atuação têm investido na captação e na aplicação da informação como diferencial estratégico
e competitivo na condução de seus negócios. Data Warehouse é um exemplo de tecnologia da
área da computação muito utilizado neste processo.
As tecnologias que permitem a análise e a visualização de dados e informações são
extremamente importantes para o processo de tomada de decisão. Não basta oferecer grandes
quantidades de dados ou informações, mesmo gratuitamente, sem que haja ferramentas de
apoio que auxiliem o usuário a analisá-las, cruzá-las, sumarizá-las e visualizá-las de uma
forma conveniente, a fim de identificar alguma informação realmente útil e relevante. É
somente realizando esse processo que as pessoas podem prever o resultado de diferentes
situações, visualizando cenários e tomando decisões de forma mais confiável.
As maiores contribuições de cunho acadêmico deste trabalho consistem no estudo e no
aperfeiçoamento de uma tecnologia existente para o auxílio a pequenas empresas que tem
limitações ao desenvolvimento de aplicações para a tomada de decisão, devido ao seu alto
custo Com a suíte de ferramentas Pentaho, desenvolvedor pode desenvolver aplicações
97

completas para a inteligência dos negócios. As contribuições de cunho social baseiam-se no


fato de que este estudo serve como base para a disseminação da tecnologia em pequenas
empresas no Brasil e para o domínio da mesma, além do barateamento no seu uso e custo.
As alternativas de trabalhos futuros estão focadas na realização das fases subseqüentes
previstas no cronograma do projeto. A ferramenta Mondrian deverá ser aplicada no
cruzamento de dimensões para avaliações mais aprofundadas e a realização mais efetiva de
um processo de mineração dos dados disponíveis no Data Warehouse.

Referências Bibliográficas
PENTAHO. Pentaho Open Source Business Intelligence. Disponível em:
<http://www.pentaho.com>. Acessado em: 12 out. 2007.
TEMATEC. Por dentro da Pentaho Open BI Suite: Conceitos, Arquitetura e
Componentes. Disponível em: <http://br.groups.yahoo.com/group/pentahobr/>. Acessado
em: 05 set. 2008.

Você também pode gostar