CONSTRUCAO DE DATA WAREHOUSE PARA PEQUENAS E MÉDIAS EMPRESAS USANDO SOFTWARE LIVRE

Transcrição

1 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

2 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

3 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. UNIPLAC Prof. Juliana Aparecida Piccoli Branco, M.Sc. UNIPLAC Prof. Wilson Castello Branco Neto, Dr. Professor de TCC Prof. Angelo Augusto Frozza, M.Sc. Coordenador de Curso

4 LISTA DE ILUSTRAÇÕES FIGURA 1 - Representação do modelo dimensional FIGURA 2 - Representação do modelo estrela FIGURA 3 - Representação do modelo floco de neves FIGURA 4 - Drill-Down FIGURA 5 - Drill Up FIGURA 6 - Slice and Dice FIGURA 7 - Diagrama de uma solução de BI FIGURA 8 - Arquitetura do Pentaho BI FIGURA 9 - Pentaho BI Plataform FIGURA 10 - Login Pentaho FIGURA 11 - Solutions FIGURA 12 - Visualização FIGURA 13 - Diagrama do banco de dados do estudo de caso FIGURA 14 - Arquitetura sistema transacional FIGURA 15 - Esquema lógico do banco de dados para o Data Warehouse FIGURA 16 - Processo de ETL FIGURA 17 - Kettle FIGURA 18 - Carga da dimensão Sortimento FIGURA 19 - Dimensão Transportador FIGURA 20 - Dimensão Clientes FIGURA 21 - Dimensão Tempo FIGURA 22 - Fatos Saída FIGURA 23 - Conexão com o cubo de dados no Schema Workbench FIGURA 24 - Visualização do cubo criado FIGURA 25 - OLAP Navigator FIGURA 26 - MDX FIGURA 27 - Config OLAP Table FIGURA 28 - Show Parent Members FIGURA 29 - Hide Spans FIGURA 30 - Show Properties FIGURA 31 - Suppress Empty Rows/Columns FIGURA 32 - Swap Axes FIGURA 33 - Drill Member FIGURA 34 - Drill Positio FIGURA 35 - Drill Replace FIGURA 36 - Drill Through... 67

5 FIGURA 37 - Show Chart FIGURA 38 - Chart Config FIGURA 39 - Configure Print Settings FIGURA 40 - Print This Page Via PDF FIGURA 41 - Start Excel FIGURA 42 - Nome do cubo, descrição e conexão de dados FIGURA 43 - Esquema relacional de dados FIGURA 44 - Criação das medidas FIGURA 45 - Criação das dimensões FIGURA 46 - Conexão com o repositório FIGURA 47 - Editor SQL FIGURA 48 - Nova Tranformação FIGURA 49 - Entrada de dados FIGURA 50 - Selecionando valores FIGURA 51 - Insert / Update QUADRO 1 - Exemplo de consulta MDX QUADRO 2 - Dimensão Tempo QUADRO 3 - Dimensão Clientes QUADRO 4 - Dimensão Sortimento QUADRO 5 - Dimensão Transportador QUADRO 6 - Tabela de Fatos QUADRO 7 - Exemplo de arquivo XACTION... 60

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

7 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.

8 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.

9 SUMÁRIO 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia DATA WAREHOUSE Conceitos e características de Data Warehouse Modelagem dimensional Etapas para a criação de um DW Extração, transformação e carga On-line Analytical Processing - OLAP Operações básicas em Data Warehouse Conclusão PLATAFORMA PENTAHO DE BUSINESS INTELLIGENCE Processos e definições Licenças e formas de obtenção do Pentaho Arquitetura Instalação Multi-Dimensional Expressions - MDX Conclusão CRIAÇÃO DE UM DATA WAREHOUSE COM PENTAHO Sistema transacional Arquitetura proposta Modelagem dimensional Modelo Estrela Processo de ETL Configuracao do servidor de aplicação Configuração do Cubo Visualização do Data Warehouse Conclusão CONSIDERAÇÕES FINAIS... 71

10 REFERÊNCIAS BIBLIOGRÁFICAS BIBLIOGRAFIA COMPLEMENTAR APÊNDICES... 76

11 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 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 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 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 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 16 confiável, criando estratégias e, ainda, colocando a empresa em um patamar de competitividade lucrativo.

17 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Existem várias versões disponíveis. Através do endereço 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 ga.863). Estas versões

31 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 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 Instalação A instalação pré-configurada (PCI 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 Seleciona-se o usuário Joe e senha Admin (Figura 10);

34 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 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 XMLA 1 (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 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 SELECT {[Measures].[Unit Sales], [Measures].[Store Sales]} ON COLUMNS, {[Product].members} ON ROWS FROM [Sales] 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 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 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 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 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 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 Valor Venda Quantidade transportada em toneladas. Valor das vendas realizadas. Peso Bruto (tabela Saída) Tara (tabela Saída) Preço (tabela sortimento) * Quantidade e) Quinta etapa armazenar os dados na tabela de Fatos:

41 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 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 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 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 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 idclientes ID do cliente que fez o pedido Integer OLTP (tabela clientes, campo idcliente) seq_id_tempo ID da data de saída dos DWTCC (dimensão tempo, campo Integer veículos seq_id_tempo) idtransportador ID do transportador Integer DWTCC (dimensão transportador, campo idtransportador) idoperadores ID dos operadores Integer OLTP (tabela clientes, campo idoperador) idsortimento ID do sortimento Integer OLTP (tabela clientes, campo idsortimento) Quantidade Medida que identifica a quantidade transportada Numeric (17,2) OLTP (tabela saida, peso bruto - tara ) Valor Venda Medida que calcula o valor OLTP (tabela sortimento, campo preco) 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 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 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 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 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 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 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 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 <datasources> <local-tx-datasource> <jndi-name>dw_tcc</jndi-name> <connectionurl>jdbc:postgresql://localhost:5432/dwtcc</connection-url> <driver-class>org.postgresql.driver</driver-class> <user-name>postgres</user-name> <password>postgres</password> </local-tx-datasource> </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. 1 2 QUADRO 9 - Fragmento de código do arquivo web.xml... <resource-ref>

52 <description>dw_tcc</description> <res-ref-name>jdbc/dw_tcc</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> </resource-ref>... 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. <resource-ref> <res-ref-name>jdbc/dw_tcc</res-ref-name> <res-type>javax.sql.datasource</res-type> <jndi-name>java:/dw_tcc</jndi-name> </resource-ref>... 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 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 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 54 configuração das estruturas da engine Mondrian são detalhadas através do passo-apasso 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 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 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 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 58 Server URL, informa-se a url para o Pentaho ( 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: < ples&path=analysis& action=nome_ cubo.xaction> (Figura 32). FIGURA 30 - Analysis View

59 59 FIGURA 31 - New Action Sequence FIGURA 32 - Define Process

60 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 <?xml version="1.0" encoding="utf-8"?> <action-sequence> <name>analysis_default.xaction</name> <title>tcc Analysis View</title> <version>1</version> <logging-level>error</logging-level> <documentation> <author>marcelo Vargas</author> <result-type>analysisview</result-type> <icon>analysis_default.png</icon> </documentation> <inputs> <mode type="string"> <default-value/> <sources> <request>mode</request> </sources> </mode> </inputs> <outputs> <model type="string"/> <connection type="string"/> <mdx type="string"/> <options type="list"/> <title type="string"/> <url type="string"> <destinations> <response>redirect</response> </destinations> </url> </outputs> <resources/> <actions> <action-definition> <component-name>pivotviewcomponent</component-name> <action-type>analysis View</action-type> <action-inputs> <mode type="string"/> </action-inputs> <action-outputs> <model type="string"/> <connection type="string"/> <mdx type="string"/> <options type="list"/> <title type="string"/> <url type="string"/>

61 </action-outputs> <component-definition> <title>analysis View</title> <viewer>pivot</viewer> <options> <personal/> <cube-nav/> <mdx-edit/> <sort-conf/> <spacer/> <level-style/> <hide-spans/> <properties/> <non-empty/> <swap-axes/> <spacer/> <drill-member/> <drill-position/> <drill-replace/> <drill-thru/> <spacer/> <chart/> <chart-conf/> <spacer/> <print-conf/> <print-pdf/> <spacer/> <excel/> </options> <query><![cdata[default]]></query> <model><![cdata[pentaho-demo\pentahosolutions\samples\analysis\tcc.mondrian.xml]]></model> <jndi><![cdata[dw_tcc]]></jndi> </component-definition> <action-name>pivot View</action-name> <logging-level>debug</logging-level> </action-definition> </actions> </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 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 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 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 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 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 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 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 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 70 comunidade Pentaho-br, e com esta interação na lista possibilitou ainda contribuir com outros desenvolvedores com as mesmas dificuldades.

71 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 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 73 REFERÊNCIAS BIBLIOGRÁFICAS BORTOLINI, A. L. de. Um projeto de data warehouse. Disponível em: < se.pdf>. Acessado em: 10 out DATAMIND TECHONOLOGY CENTER. Data mining for competitive advantage Disponível em: < Acessado em: 16 jan FROZZA, A. A. Data warehouse: modelagem dimensional. Notas de Aula da disciplina Data Warehouse. Lages: UNIPLAC, 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 , HOKAMA, D. D. B. et al. A modelagem de dados no ambiente Data Warehouse 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: < /2004ModelagemDW.pdf>. Acessado em: 20 mai INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Campus, p. KIMBALL, R. Data Warehouse Toolkit. São Paulo: Makron Books, 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 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, MACHADO, F. N. R. Tecnologia e projeto de Data Warehouse: uma visão multidimensional. São Paulo: Érica, p. MICROSOFT. Microsoft Corporation. Disponível em: < Acessado em: 01 mai PERNAS, A. M. da R. Modelagem de um Data Webhouse voltado a produção e comercialização de sementes f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) Instituto de Física e Matemática,

74 74 Universidade Federal de Pelotas, Pelotas. Disponível em: < prg/sisbi/bibct/acervo/info/2003/mono_ana_pernas.pdf>. Acessado em: 20 mai 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 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: < Acessado em: 05 set TORRES, N. A. Competitividade empresarial com a tecnologia de informação. São Paulo: Makron Books, p.

75 75 BIBLIOGRAFIA COMPLEMENTAR BALLARD, C.; HERREMAN, D. Data Modeling Techniques for Data Warehousing. IBM, International Technical Support Organization, February, BARBIERI, C. Business Intelligence: modelagem e tecnologia. Rio de Janeiro: Axcel Books, BISPO, C. A. F. Uma Análise da Nova Geração de Sistemas de Apoio à Decisão 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: < Acessado em: 08 out FELBER, E. J. W. Proposta de uma ferramenta OLAP em um Data Mart comercial: Uma aplicação prática na industria calçadista 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, 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, Disponível em: < Acessado em: 10 out PENTAHO. Pentaho Open Source Business Intelligence. Disponível em: < Acessado em: 12 out

76 76 APÊNDICES APÊNDICE A PENTAHO CUBE DESIGN APÊNDICE B PENTAHO DATA INTEGRATION APÊNDICE C - ARTIGO... 88

77 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 ) 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 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 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 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 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 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 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 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. A.2 Criando uma transformação FIGURA 55 - Editor SQL 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