IFSP INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SÃO PAULO CAMPUS SALTO CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 IFSP INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SÃO PAULO CAMPUS SALTO CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANDERSON CHAVES CARNIEL BJIN OLAP: UMA FERRAMENTA OLAP BASEADA NO ÍNDICE BITMAP DE JUNÇÃO Trabalho de conclusão de curso apresentado ao Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - Salto para obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas Salto, SP, Fevereiro de 2012.

2 ANDERSON CHAVES CARNIEL BJIN OLAP: UMA FERRAMENTA OLAP BASEADA NO ÍNDICE BITMAP DE JUNÇÃO Trabalho de conclusão de curso apresentado ao Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - Salto para obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas Orientador: Prof. Thiago Luís Lopes Siqueira São Paulo, SP, Fevereiro de 2012.

3 Dedico esta monografia aos meus queridos pais, que sempre me apoiaram em qualquer momento, por qualquer motivo e razão

4 AGRADECIMENTOS Aos meus gloriosos pais, que me apoiaram em todos os momentos acreditando em mim. À minha querida namorada Dany, pelo amor, carinho e afeto, sua compreensão e apoio ao longo desse trabalho foram fundamentais para sua conclusão. A todas as pessoas envolvidas neste trabalho, que de algum modo me ajudaram com maior ou menor intensidade. Obrigado pelas palavras acolhedoras e amizade. Ao dedicado Prof. Thiago Luís Lopes Siqueira, pela oportunidade de trabalharmos na iniciação cientifica que originou esta monografia, pela confiança, respeito e investimento neste aluno que agora ingressa no Mestrado. Aos professores Dr. Edson Murakami e Adriano Rivolli da Silva, pela motivação de sempre melhorar o trabalho, com suas aulas emocionantes e contagiantes que certamente contribuíram para esta monografia. Ao professor Dr. Claudio Haruo Yamamoto pela orientação da bolsa de iniciação científica em Ao fantástico casal de professores Dr. Ricardo Rodrigues Ciferri e Dra. Cristina Dutra de Aguiar Ciferri, que acreditaram em mim para o programa de Mestrado no DC/UFSCar. Ao IFSP pela bolsa de iniciação científica em 2010, semente deste trabalho, e pela bolsa de iniciação científica em À coordenadoria de tecnologia de informação do IFSP Campus Salto pelo suporte de equipamentos e rede que foram determinantes para a conclusão deste trabalho.

5 RESUMO Data Warehouse (DW) e OLAP (Online Analytical Processing) são segmentos importantes da inteligência de negócio (Business Inteligence) apoiando o processo de tomada de decisão estratégica. O DW é uma base de dados histórica, integrada e volumosa, enquanto OLAP viabiliza a análise e visualização multidimensional dos dados. Sobre o DW incidem consultas analíticas ad-hoc provenientes de ferramentas OLAP que culminam frequentemente em alto tempo de resposta, devido ao grande volume de dados, à realização de junções e agregações e à aplicação de filtros. Por isso, existe o desafio em relação ao desempenho no processamento de consultas OLAP para diminuir o tempo de resposta ao usuário e assim beneficiar a tomada de decisão. Mecanismos para melhorar o desempenho do processamento de consultas, como estruturas de indexação, são essenciais. Nesta monografia é proposta uma nova ferramenta OLAP, nomeada BJIn OLAP, baseada no índice bitmap de junção. Apesar do bom desempenho deste índice, no melhor do nosso conhecimento, não existe nenhuma ferramenta OLAP baseada intrinsecamente no índice bitmap de junção. A ferramenta BJIn OLAP realiza consultas analíticas de OLAP sobre DW e operações OLAP drill-down, roll-up, slice-and-dice e pivoting utilizando somente índices bitmap de junção, visando diminuir o tempo de resposta das consultas, e viabilizando mecanismos eficientes de visualização dos resultados. Além disso, a ferramenta BJIn OLAP implementa operações de construção, atualização e exclusão dos referidos índices. Testes de desempenho foram realizados comparando a ferramenta BJIn OLAP à junção estrela, à visões fragmentadas verticalmente, à visões materializadas e ao servidor OLAP Mondrian. Esses testes indicaram que a ferramenta BJIn OLAP diminuiu significativamente o tempo de resposta de consultas OLAP com reduções de tempo de até 98% em relação a tecnologias existentes, sobre bases de dados com diferentes volumes, contendo dados reais ou sintéticos e sob diferentes sistemas operacionais. Além disso, as vantagens da ferramenta BJIn OLAP se estenderam aos resultados de outros testes de desempenho que avaliaram o uso de memória, a apresentação dos resultados das consultas ao usuário, e a operação de atualização dos índices bitmap de junção. Palavras-chave: Data Warehouse, OLAP, Índice Bitmap de Junção, drill-down, roll-up, slice-and-dice, pivoting

6 ABSTRACT Data Warehouse (DW) and OLAP (Online Analytical Processing) are core issues of Business Intelligence to aid the process of strategic decision making. The DW is a large integrated historical database, while OLAP enables analysis and visualization of multidimensional data. OLAP tools perform ad-hoc analytical queries over DW. These queries often spend a high response time due to the data volume, joins among tables, data aggregation, filters and sorting. Therefore, there is a challenge concerning performance on OLAP query processing, aiming to decrease query response time to the user and thus benefit the decision-taking. Mechanisms to improve the performance of query processing, such as indexing structures are essential. In this completion of course work a new OLAP tool based on the bitmap join index is proposed and named BJIn OLAP. Although this index has a reasonable query processing performance, to the best of our knowledge, there is no OLAP tool based on it. The BJIn OLAP tool enables analytical queries and the OLAP operations of drill-down, roll up, slice-and-dice and pivoting on DW using strictly bitmap join indexes in order to decrease the response time of queries, and visualization methods to present query results. Moreover, the BJIn OLAP tool implements construction, updating and deleting operations for these indexes. A performance evaluation was conducted through performance tests, comparing the BJIn OLAP tool to the star join, vertically fragmented views, materialized views and the Mondrian OLAP server. These tests indicated that BJIn OLAP tool significantly decreased the response time of OLAP queries and produced performance gains of up to 98% on databases with different volumes, containing synthetic and real data or under different operating systems. Moreover, the benefits of the BJIn OLAP tool were also observed in other performance tests that evaluated the memory usage, the presentation of the query results the user, and the update operation of bitmap join indexes. Keywords: Data Warehouse, OLAP, Bitmap Join Index, drill-down, roll-up, sliceand-dice, pivoting

7 LISTA DE FIGURAS Figura 1. Representação de um hipercubo de dados Figura 2. Esquema estrela para uma aplicação de varejo, adaptada de [20] Figura 3. Esquema floco de neve normalizando a hierarquia de Supplier da Figura Figura 4. Consultas OLAP sobre o hipercubo de dados da Figura Figura 5. Operação drill-down e roll-up da hierarquia entre os atributos da dimensão Customer Figura 6. Operação slice-and-dice sobre a dimensão Customer selecionando o continente AMERICA e a dimensão Part selecionando CD, DVD e TV Figura 7. À esquerda, resultado da consulta, e à direita, uma operação pivoting Figura 8. Consultas SQL e MDX equivalentes Figura 9. Resultado das consultas SQL e MDX da Figura Figura 10. Esquema estrela e uma consulta usando a junção estrela Figura 11. Visão fragmentada verticalmente Figura 12. Resultado de uma consulta executada sobre a visão fragmentada verticalmente Figura 13. Visão materializada Figura 14. Resultado de uma consulta executada sobre a visão materializada Figura 15. Índices bitmap de junção sobre uma visão fragmentada verticalmente Figura 16. Índices bitmap de junção sobre uma visão materializada Figura 17. Consulta sobre índices bitmap de junção Figura 18. Três registros para serem incluídos no DW Figura 19. Diagrama de caso de uso da ferramenta BJIn OLAP Figura 20. Fluxos de dados para construção de índices bitmap de junção Figura 21. Tela de construção de índices bitmap de junção Figura 22. Exemplo de documento XML da definição interna dos índices bitmap de junção. 42 Figura 23. Fluxo de dados para consulta de índices bitmap de junção Figura 24. Escrita da consulta com recurso de realce e complemento automático Figura 25. Resultado da consulta e operações OLAP disponíveis Figura 26. Operação OLAP slice-and-dice Figura 27. Operação OLAP slice-and-dice completa Figura 28. Operação pivoting sobre a Figura Figura 29. Fluxo de operações para atualização de índices bitmap de junção Figura 30. Tela de atualização de índices bitmap de junção... 51

8 Figura 31. Fluxo de operações para exclusão de índices bitmap de junção Figura 32. Tela de exclusão de índices bitmap de junção Figura 33. Exemplo de arquivo de configuração da ferramenta BJIn OLAP Figura 34. Exemplo de arquivo log4j.properties para registro de logs Figura 35. Arquivo de log nativo gerado após uma operação de construção de índice Figura 36. Exemplo de registro do log4j para a operação de construção de índice Figura 37. Exemplo de documento user.xml para controle de usuários Figura 38. Modelos das consultas do SSB [20] Figura 39. Consultas do grupo Q3 adaptadas de [20] para operações drill-down e roll-up Figura 40. Consultas do grupo Q4 para operações drill-down e roll-up [20] Figura 41. Esquema estrela do DW webpide [41] Figura 42. Consultas sobre a base de dados webpide [41] Figura 43. Tempo decorrido por cada configuração para processar as consultas do SSB sobre a base de dados DW Figura 44. Quantidade de vetores de bits disponíveis para cada consulta do SSB sobre DW1 66 Figura 45. Espaço requerido para armazenamento de índices bitmap de junção e VFV Figura 46. Resultados das consultas sobre a base de dados webpide Figura 47. Tempo decorrido na execução das consultas do SSB na base de dados DW Figura 48. Tempo decorrido para processar as consultas do SSB sobre a base de dados DW10 usando visões materializadas Figura 49. Tempo adicionado pelas ferramentas OLAP em relação ao seu mecanismo de consulta Figura 50. Espaço requerido total considerando a base de dados DW Figura 51. Tempo decorrido para visualização final do usuário dos resultados das consultas do grupo Q Figura 52. Tempo total para carregar as páginas de resultados das operações OLAP drill-down e roll-up do grupo Q3 sobre a base de dados DW Figura 53. Uso de memória para a operação OLAP roll-up sobre a base de dados DW Figura 54. Uso de memória para a consulta Q3.4 processada sobre a base de dados DW Figura 55. Uso de memória para a consulta Q3.4 usando visão materializada sobre a base de dados DW Figura 56. Portabilidade e o processamento de consultas sobre a base de dados DW Figura 57. Portabilidade e o processamento de consultas para o DW Figura 58. Testes em relação a atualizações de índices bitmap de junção... 85

9 LISTA DE TABELAS Tabela 1. Compatibilidade da ferramenta BJIn OLAP Tabela 2. Fórmulas usadas pela ferramenta BJIn OLAP Tabela 3. Variáveis correspondentes das fórmulas da Tabela Tabela 4. Parâmetros e variáveis locais de Algoritmo Tabela 5. Descrição das propriedades de configuração da ferramenta BJIn OLAP Tabela 6. Permissões para controle de usuários Tabela 7. Características dos grupos de consultas da Figura Tabela 8. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1 utilizando o grupo Q3 do SSB Tabela 9. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1 utilizando o grupo Q4 do SSB Tabela 10. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10 usando o grupo Q3 do SSB Tabela 11. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10 usando o grupo Q4 do SSB Tabela 12. Linhas e colunas que compuseram as tabelas cruzadas Tabela 13. Quantidade de novos vetores de bits criados para cada atributo indexado Tabela 14. Comparação de tecnologias existentes e a ferramenta BJIn OLAP... 87

10 LISTA DE ABREVIATURAS Ajax Asynchronous JavaScript and XML API Application Programming Interface BJIn OLAP Bitmap Join Index OLAP Tool CSV Comma-Separated Values DW Data Warehouse HTML HyperText Markup Language JDBC Java Database Connection JE Junção Estrela JSON JavaScript Object Notation JSP Java Server Pages JVM Java Virtual Machine MDX MultiDimensional expressions OAT Openlink Ajax Toolkit OLAP Online Analytical Processing OLTP Online Transaction Processing SGBD Sistema Gerenciador de Banco de Dados SOLAP Spatial OLAP SQL Structured Query Language SSB Star Schema Benchmark UML Unified Modeling Language VFV Visão Fragmentada Verticalmente VM Visão Materializada XML extensible Markup Language

11 SUMÁRIO 1 INTRODUÇÃO Contexto e Motivação Contribuições Organização da Monografia FUNDAMENTAÇÃO TEÓRICA Data Warehouse OLAP Processamento de Consultas Junção Estrela Fragmentação Vertical dos Dados Visão Materializada Índice Bitmap de Junção Processamento de Atualizações UMA FERRAMENTA OLAP BASEADA NO ÍNDICE BITMAP DE JUNÇÃO O Projeto Construindo Índices Bitmap de Junção Consultando Índices Bitmap de Junção Slice-and-Dice Drill-down e Roll-up Pivoting Atualizando Índices Bitmap de Junção O Gatilho Fluxos de Dados Excluindo Índices Bitmap de Junção Outras Funcionalidades Parâmetros de Configuração Registro de Log Permissões e Privilégios TESTES DE DESEMPENHO EXPERIMENTAIS Configurações dos Testes

12 4.2 Comparando a Ferramenta BJIn OLAP com Visões Fragmentadas Verticalmente Operações Drill-down e Roll-up Consultando a Base de Dados Real webpide Investigação Sobre o Aumento do Volume de Dados e o Uso de Visões Materializadas As Consultas do SSB Operações Drill-down e Roll-up UMA AVALIAÇÃO EXPERIMENTAL ESTENDIDA Apresentando os Resultados das Consultas ao Usuário Uso de Memória Portabilidade e o Desempenho no Processamento de Consultas Atualizações de Índices Bitmap de Junção TRABALHOS CORRELATOS CONCLUSÕES E TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A APÊNDICE B APÊNDICE C APÊNDICE D ANEXO A

13 13 1 Introdução Nesta monografia é proposta uma nova ferramenta denominada BJIn OLAP (The Bitmap Join Index OLAP Tool). Ela objetiva diminuir o tempo de resposta a consultas analíticas OLAP (Online Analytical Processing) que incidem sobre data warehouses, utilizando intrinsecamente índices bitmap de junção. São enfocadas as operações drill-down, roll-up, pivoting e slice-and-dice. 1.1 Contexto e Motivação A inteligência de negócio (Business Intelligence) vem sendo cada vez mais adotada por instituições para compreender seus dados, visando melhorar o andamento de seus negócios e auxiliar a elaboração de estratégias para tomadas de decisão [1]. Para a correta organização desses dados, é necessário isolá-los das transações diárias gerenciadas por ferramentas OLTP (Online Transaction Processing) [1] [2], compondo assim uma base de dados histórica, integrada, consolidada, orientada ao assunto, não volátil e intrinsecamente volumosa. Essa base de dados é denominada data warehouse (DW) [2] [3] [4] [5]. Sobre o DW incidem consultas analíticas OLAP para auxiliar a tomada decisão, alicerçando a elaboração de estratégias de negócio [6] [7]. Para a tomada de decisão, a minimização do tempo de resposta das consultas OLAP é um fator importante, aliado aos recursos de visualização de dados. Deve-se ressaltar que tais consultas, executadas sobre um DW volumoso, iria realizar junções, filtros, agrupamentos e ordenações envolvendo tabelas com um grande volume de dados, ocasionando um alto tempo de resposta [7]. Os recursos de visualizações devem prover suporte a operações de manipulação de dados do DW, considerando as operações OLAP drill-down, roll-up, pivoting e slice-and-dice [2] [7]. Por exemplo, considere a consulta definida por qual a receita total dos países da América nos anos de 1999 a 2010? A operação slice-and-dice foi definida pelos predicados da consulta para filtrar os resultados nos países e nos anos especificados. Uma operação drill-down requereria mais detalhamento de informações em um ou mais atributos, por exemplo: qual a receita total das cidades do Brasil nos anos de 1999 a 2010?. Inversamente, a operação roll-up sumarizaria os dados em um ou mais atributos, por exemplo: qual a receita total de todos os continentes nos anos de 1999 a 2010?. Por fim, a operação pivoting viabiliza engendrar as perspectivas de análise de acordo com os atributos envolvidos Uma operação pivoting seria visualizar atributos em um eixo especifico e posteriormente, mudá-los de posição, por exemplo, atributos no eixo das colunas se deslocarem para o eixo das linhas em uma tabela cruzada.

14 14 As consultas analíticas sobre DW bem como operações OLAP culminam frequentemente em um alto tempo de resposta por exigirem grande esforço computacional. Na literatura, as principais técnicas conhecidas para beneficiar o desempenho do processamento das consultas em DW [8] são: Materialização de visões [9] [10] [11] [12] que preprocessa agrupamentos e elimina junções entre as tabelas; Fragmentação vertical e horizontal dos dados [13] que objetiva eliminar a junção entre as tabelas; e Estruturas de indexação [14] [15] [16]. Este trabalho enfoca a indexação como técnica para melhorar o tempo de resposta de consultas sobre DW. Em particular, o índice bitmap de junção [8] [16] [17] é empregado para esta finalidade. Sua principal vantagem, em relação a outras técnicas, é de manipular vetores de bits por meio de operações lógicas auxiliadas pelo hardware. Apesar do índice bitmap de junção ser um método de acesso promitente, inexistem na literatura ferramentas OLAP que acessem intrinsecamente esses índices para processar consultas sobre DW e para nele realizar operações OLAP. 1.2 Contribuições A proposta da ferramenta BJIn OLAP tem como contribuições principais: Viabilizar construir, atualizar e excluir índices bitmap de junção sobre DWs; Acessar intrinsecamente os índices bitmap de junção para processar consultas analíticas OLAP, bem como as operações OLAP drill-down, roll-up, slice-anddice e pivoting [2] [7] ; Oferecer recursos de visualização apropriados, apresentando os resultados em tabelas e gráficos; Por viabilizar as funcionalidades citadas, a ferramenta BJIn OLAP é inovadora; e Por prover um bom desempenho no processamento de consultas mesmo para atributos com alta cardinalidade. A ferramenta BJIn OLAP foi validada por meio de testes de desempenho experimentais usando DW criados a partir de dados sintéticos e um DW contendo dados reais. Os resultados obtidos foram comparados ao processamento de consultas no sistema gerenciador de banco de dados e ao servidor OLAP Mondrian [18] [19]. Os dados sintéticos foram gerados usando o Star Schema Benchmark (SSB) [20]. Nos testes foram executadas consultas em duas bases de dados com tamanhos distintos, que avaliaram e comprovaram a

15 15 escalabilidade da ferramenta para o aumento do volume de dados. A ferramenta BJIn OLAP proporcionou excelentes ganhos de desempenho de no mínimo 70% se comparado ao Mondrian para processar consultas. Além disso, as operações drill-down e roll-up foram analisadas e confirmou-se a viabilidade do uso de índices bitmap de junção para processá-las, com ganhos de desempenho de 83% a 93%. Outros testes como uso de memória, o impacto na visualização dos resultados e portabilidade também foram realizados. Estes testes inferiram que a ferramenta BJIn OLAP proveu um bom desempenho considerando outras métricas de avaliação. Adicionalmente, testes de atualizações de índices bitmap de junção foram realizados para averiguar o custo de construção e atualização, indicando que a atualização dos índices é melhor que a sua reconstrução. 1.3 Organização da Monografia O restante desta monografia está organizado em sete capítulos, quatro apêndices e um anexo: Capítulo 2: os fundamentos teóricos envolvidos na monografia são resumidos, os quais são indispensáveis para a compressão da ferramenta OLAP proposta; Capítulo 3: a ferramenta BJIn OLAP é introduzida, descrita e são especificadas suas funcionalidades; Capítulo 4: os testes de desempenhos experimentais executados sobre a ferramenta BJIn OLAP são especificados, incluindo as discussões dos resultados obtidos; Capítulo 5: testes de desempenho experimentais adicionais sobre a ferramenta BJIn OLAP são apresentados e os resultados obtidos discutidos; Capítulo 6: os trabalhos correlatos são discutidos em relação à ferramenta proposta; Capítulo 7: o trabalho é concluído, apresentando as principais contribuições e apontando trabalhos futuros; Apêndice A: são apresentados e especificados os casos de uso da ferramenta BJIn OLAP; Apêndice B: são especificados e documentados os diagramas de classe da ferramenta; Apêndice C: são apresentados os diagramas de sequência para as funcionalidades da ferramenta;

16 16 Apêndice D: são apresentados os comandos principais usados para coletar os resultados dos testes de desempenho; e, Anexo A: contém o manual da ferramenta BJIn OLAP, gentilmente elaborado pelo aluno de graduação da USP Lucas de Carvalho Scabora. A proposta da ferramenta BJIn OLAP, suas funcionalidades principais e ainda os resultados alcançados com testes de desempenhos para avaliar a viabilidade da ferramenta, foram descritos também em artigos publicados em eventos qualificados pelo Qualis/CAPES: [21] e [22]. Destaca-se a Menção Honrosa à ferramenta [21] e a seleção entre os quatro melhores artigos do evento [22]. Tal seleção viabilizou o convite para submissão de uma versão estendida do artigo ao periódico CLEIej, o qual também é qualificado pelo Qualis/CAPES.

17 17 2 Fundamentação Teórica Neste capítulo são resumidos os conceitos teóricos fundamentais para a compreensão deste trabalho. Na seção 2.1 é exposto sobre data warehouse, enquanto a seção 2.2 é descrito a tecnologia de consultas analíticas multidimensionais para suporte a decisão (OLAP). Na seção 2.3 são apresentadas algumas das principais técnicas utilizadas para processar consultas sobre data warehouse. Finalmente na seção 2.4 é discutido o processamento de atualizações em data warehouse. 2.1 Data Warehouse Instituições tem requerido cada vez mais compreensão de seus dados visando melhorar o andamento de seus negócios e para auxiliar a elaboração de estratégias de tomada de decisão. Porém, com o aumento do volume dos dados, em geral não integrados, e a necessidade de consultas em baixo tempo, determinaram a separação de operações do dia-adia das decisões estratégicas [1]. Um data warehouse (DW) [2] [3] [4] [5] é uma solução para a organização e manipulação dos dados para a tomada de decisão estratégica. DW é uma base de dados histórica, volumosa, orientada ao assunto e não volátil, constituído por um modelo multidimensional organizado conceitualmente em um hipercubo de dados [3] [4]. Uma representação conceitual do hipercubo de dados é mostrada na Figura 1. As faces do hipercubo de dados mostrado são Date, Supplier, Customer e Part. Cada célula do hipercubo de dados descreve quantitativamente o assunto analisado. O assunto analisado pode ser as vendas de um produto, e cada célula representa a média da venda. Por exemplo, em uma rede varejista necessita-se saber o andamento das vendas de seus produtos ao longo do tempo, então este hipercubo de dados mantém todas as informações necessárias. Figura 1. Representação de um hipercubo de dados

18 18 A representação lógica do hipercubo de dados pode ser baseada no modelo relacional, usando o esquema estrela (star schema) ou o esquema floco de neve (snowflake) [3] [4]. Tais esquemas são compostos por tabelas de dimensão e uma tabela de fatos [3] [4]. A tabela de fatos armazena as medidas que descrevem quantitativamente o negócio analisado. Cada célula do hipercubo de dados é representada por uma medida na tabela de fatos. Além disso, a tabela de fatos mantém chaves estrangeiras para as tabelas de dimensão. Cada tabela de dimensão é uma face do hipercubo fornecendo características do negócio, e seus atributos podem compor hierarquias. A representação lógica da Figura 1 é mostrada pelo esquema estrela da Figura 2. Este esquema estrela possui a tabela de fatos Lineorder e as dimensões Customer, Supplier, Date e Part, ilustrando acima das mesmas a quantidade esperada de tuplas, assim como os relacionamentos e cardinalidade existentes. Os atributos da tabela Customer formam uma hierarquia, por exemplo, c_region c_nation c_city c_address [10]. Onde os resultados agregados por cidade (c_city) são suficientes para obter os resultados agregados por nação (c_nation) e por continente (c_region), por exemplo. O esquema floco de neve normaliza as hierarquias existentes nas dimensões, aumentando o número de junções existentes entre as tabelas [3]. Na Figura 3 é mostrado um esquema floco de neve que normaliza a hierarquia s_region s_nation s_city s_address a partir da tabela de dimensão Supplier. Pode-se observar que o atributo s_adrress fica na própria dimensão mantendo a chave estrangeira para s_city, que mantém a chave estrangeira para s_nation, e esta para s_region normalizando totalmente a hierarquia. Tanto no esquema estrela quanto no floco de neve, a navegação pela hierarquia pode viabilizar perspectivas de análise diferentes sobre os dados do hipercubo. Estas navegações e consultas para análises multidimensionais do hipercubo de dados são viabilizadas por ferramentas de suporte a decisão (OLAP) [2] [7].

19 19 Figura 2. Esquema estrela para uma aplicação de varejo, adaptada de [20] Figura 3. Esquema floco de neve normalizando a hierarquia de Supplier da Figura OLAP Ferramentas Online Analytical Processing (OLAP) tem sido desenvolvidas para o processamento, análise, interpretação e visualização dos dados multidimensionais armazenados em DW [2] [7]. Sendo assim, OLAP e DW tornaram-se aspectos fundamentais de inteligência de negócio (Business Intelligence) [1] [2] e a sua combinação está sendo adotada pelas instituições para auxiliar na tomada de decisão estratégica, tática e operacional de seus processos. Por outro lado, sistemas transacionais ou OLTP (Online Transaction Processing), objetivam registrar operações transacionais de uma organização. Sistemas OLTP visam manipular os dados envolvidos em tempo real, inserindo, alterando, excluindo e consultando

20 20 registros para uma operação determinada em um bom desempenho [8]. No entanto, ferramentas OLAP são designadas somente para a emissão de consultas sobre dados históricos do DW, com um bom desempenho, para o apoio estratégico organizacional. São apresentadas na Figura 4 consultas que poderiam ser realizadas por ferramentas OLAP, sobre o hipercubo de dados da Figura 1, visando tomada de decisão. Figura 4. Consultas OLAP sobre o hipercubo de dados da Figura 1 Ferramentas OLAP em geral, oferecem meios de manipulação multidimensionais dos dados com as operações: (i) drill-down, (ii) roll-up, (iii) slice-and-dice e (iv) pivoting. Essas operações realizam filtros e junções sobre a grande quantidade de dados da tabela de fatos e as dimensões do DW, culminando em um alto tempo de resposta [2] [7]. Para as operações drill-down e roll-up a definição de hierarquias é fundamental. A operação drill-down progride para níveis de granularidade mais baixos na hierarquia, sendo visualizado um maior detalhamento sobre os dados agregados. Na operação roll-up, inversamente, regride para níveis maiores na hierarquia, visualizando um menor detalhamento sobre os dados agregados. Na Figura 5 são apresentadas as operações drill-down e roll-up disponíveis na hierarquia da dimensão Customer, c_region c_nation c_city c_address. Uma operação drill-down seria primeiramente consultar dados a respeito de uma nação (c_nation), e em seguida consultar dados a respeito de uma cidade (c_city) da nação. Inversamente, em uma operação roll-up, primeiramente seriam consultados os dados por cidade (c_city), e em seguida, por nação (c_nation), por exemplo.

21 21 Figura 5. Operação drill-down e roll-up da hierarquia entre os atributos da dimensão Customer A operação slice-and-dice define filtros derivados da junção do grande volume de dados da tabela de fatos e das dimensões, realizando consultas com resultados mais refinados. Esta operação define pontos de filtros sobre os dados agregados das dimensões do hipercubo de dados, resultando em um hipercubo menor para obter a análise desejada. A Figura 6 demonstra uma operação slice-and-dice sobre o hipercubo da Figura 1 denotado pela seleção do continente AMERICA de Customer e dos itens CD, DVD e TV de Part. Com os resultados, uma análise aprofundada poderá ser feita sobre o hipercubo resultante, podendo sofrer outras operações OLAP. Figura 6. Operação slice-and-dice sobre a dimensão Customer selecionando o continente AMERICA e a dimensão Part selecionando CD, DVD e TV A operação pivoting (pivoteamento) permite o usuário alterar os eixos de visualização dos resultados de uma consulta, alterando a perspectiva de análise. Para o resultado da consulta na qual se deseja saber a soma do lucro dos anos de 2009 e 2010 agrupados pelo país do cliente, a operação pivoting é mostrada na Figura 7. No lado esquerdo da Figura 7 é mostrada a tabela de resultado original da consulta, com o eixo das colunas para o ano de consumo (d_year) e no eixo das linhas para o país do cliente (c_nation). Enquanto isso, no lado direito da Figura 7 é visualizado o resultado do pivoting, com o eixo das colunas para o país do cliente (c_nation) e no eixo das linhas para o ano de consumo (d_year). O recurso de

22 22 visualização mostrado na Figura 7 é chamado de tabela cruzada (cross table) e permite uma visualização tabular em eixos dos resultados gerados por uma consulta. Figura 7. À esquerda, resultado da consulta, e à direita, uma operação pivoting Existem diversas ferramentas OLAP atualmente. A principal delas de código aberto (open source) é o Mondrian do grupo Pentaho [18] [19]. Mondrian é um servidor OLAP escrita na linguagem de programação Java que permite a exploração de dados de negócios através de tabelas cruzadas geradas pelo JPivot [23] visualizadas em páginas JSP (Java Server Pages). Para habilitar as operações OLAP, o Mondrian exige a definição do cubo de dados por meio de um documento XML (extensible Markup Language). O cubo de dados do Mondrian descreve o esquema DW, como por exemplo, tabelas de fatos e dimensões, hierarquias e medidas. O software Mondrian Schema Workbench [24] facilita a especificação do cubo de dados para a definição do documento XML acessando o esquema do DW. A linguagem de consulta utilizada pelo Mondrian é a MDX (MultiDimensional expressions) [19] [25], sendo traduzida posteriormente para a linguagem SQL (Structured Query Language). Após o usuário escrever a consulta MDX e executá-la no Mondrian, as operações OLAP drill-down, roll-up, slice-and-dice e pivoting são habilitadas. Tais operações permitem cruzar informações de resultados em tabelas processadas por consultas analíticas complexas executadas nos sistemas gerenciadores de banco de dados (SGBD). A linguagem MDX prevê uma sintaxe especializada para consulta e manipulação de dados multidimensionais do hipercubo OLAP [25]. Embora seja possível converter facilmente uma consulta MDX para SQL, expressões MDX muito simples poderiam requerer uma sintaxe SQL muito complexa [18]. Portanto, a MDX tem como objetivo facilitar a elaboração de consultas multidimensionais oferecendo a perspectiva direta de manipulação das dimensões do hipercubo de dados. Na Figura 8 é mostrada duas consultas, uma MDX e outra SQL, equivalentes. Ambas as consultas selecionam a soma da receita dos países consumidores e fornecedores do continente asiático, a partir dos anos 1992 até 1997, sobre o esquema estrela da Figura 2 [20]. Observa-se que a consulta SQL, exige a escrita das junções envolvidas, agrupamentos e

23 23 ordenação, enquanto na MDX não é necessário. Na Figura 9a é mostrado o resultado tabular unidimensional da consulta executada no SGBD PostgreSQL. Enquanto na Figura 9b é mostrado o resultado dessa consulta executada no Mondrian. A linguagem MDX possui três cláusulas: SELECT, FROM e WHERE [25]. A cláusula SELECT especifica quais atributos irão compor os eixos das colunas e das linhas na tabela cruzada. Na cláusula FROM é especificado em qual hipercubo de dados a consulta será emitida, e finalmente, na cláusula WHERE é definida a operação slice-and-dice. Além disso, a linguagem MDX exige a manipulação direta das hierarquias dos atributos das dimensões. A seleção de valor é dado por [DIMENSÃO].[NÍVEL].[VALOR]. Sendo DIMENSÃO a tabela de dimensão, NÍVEL o atributo e VALOR o valor do atributo. Então para a consulta MDX da Figura 8, o nível [Customer].[Continente].[ASIA] seleciona o continente asiático da dimensão Customer. Ou ainda, de forma equivalente, pode-se especificar a marcação [Customer].[ASIA], pois o continente (c_region) é o primeiro nível da hierarquia c_region c_nation c_city c_address. A seleção de todos os países consumidores asiáticos na MDX é dado pelo uso da função MDX Children sobre [Customer].[ASIA]. Esta por sua vez, seleciona todos os valores do nível subsequente da hierarquia selecionada. No exemplo, são selecionados todos os países (c_nation) do continente (c_region) ASIA. De maneira análoga, são selecionados os países fornecedores asiáticos e os anos entre 1992 e Percebe-se que são aplicados filtros sobre as dimensões especificadas na cláusula SELECT, porém a diferença é que eles são visualizados na tabela de resultado, ao contrário dos filtros realizados na cláusula WHERE. A seleção da medida é dada pela dimensão padrão da MDX, [Measures], e especificado com configurações na ferramenta OLAP, a função de agregação sobre a medida selecionada, que no exemplo deve ser o sum. No exemplo é definido que no eixo das colunas (ON COLUMNS) serão mostrados os anos, e no eixo das linhas (ON ROWS) a medida e os países consumidores e fornecedores (Figura 9b). Outra particularidade da MDX é a restrição de que a dimensão definida no ON COLUMNS não pode reaparecer no ON ROWS nem na cláusula WHERE, bem como o inverso. Por fim, é usada a função MDX Crossjoin que cruza as dimensões para a sua visualização no eixo selecionado.

24 24 Figura 8. Consultas SQL e MDX equivalentes (a) Tabela unidimensional (b) Tabela cruzada gerada pelo Mondrian (cross table) Figura 9. Resultado das consultas SQL e MDX da Figura Processamento de Consultas Nesta seção serão apresentadas as formas mais comuns para processar consultas sobre DW. Na seção é abordada a junção estrela, que realiza a junção do grande volume de dados da tabela de fatos com as dimensões, executando filtros, agrupamento e ordenação, como mostra a consulta SQL da Figura 8. A junção estrela, como será discutida no Capítulo 4, se torna o método mais severo para processar consultas analíticas OLAP, resultando em tempos de respostas inadmissíveis.

25 25 Nas seções 2.3.2, e são apresentadas as principais formas conhecidas para melhorar o tempo de resposta de consultas submetidas a um DW: fragmentação vertical dos dados, visão materializada e índice bitmap de junção Junção Estrela A junção estrela [2] [5] [8] é o método mais custoso de processar consultas sobre um DW, por realizar a junção de todas as tabelas envolvidas do esquema estrela para então executar filtros, agrupamentos e classificações. Por exemplo, considerando a seleção da soma da receita dos países consumidores e fornecedores do continente asiático, a partir dos anos 1992 até 1997, sobre o esquema estrela da Figura 2 [20], esta consulta será como a apresentada anteriormente na Figura 8a. Na Figura 10a são mostrados quais atributos serão selecionados no esquema estrela e as junções existentes, enquanto na Figura 10b é mostrada a consulta SQL com realce na operação mais custosa, a junção. A junção é realizada sobre as tabelas de dimensão Customer, Supplier e Date com a tabela de fatos Lineorder envolvendo um grande volume de dados. Além disso, são processados os filtros sobre os atributos c_region, s_region e d_year, agrupamentos, e classificações. No final, esse processamento culmina em um tempo de resposta altíssimo para o usuário final, sendo inapropriado para consultas OLAP. Adicionalmente, o método de consulta junção estrela para um esquema floco de neve realiza junções extras para as tabelas normalizadas. Para responder a mesma consulta da Figura 10b, novas junções são necessárias. A junção sobre a hierarquia de atributos da tabela de dimensão Customer, c_region > c_nation > c_city > c_address, deverá ser processada, bem como para a hierarquia s_region > s_nation > s_city > s_address da tabela de dimensão Supplier. Como mostrado na Figura 3, para selecionar o atributo c_region da dimensão Customer, junções sobre Customer, Customer_Ciy, Customer_Nation e Customer_Region são necessárias. De maneira análoga para a dimensão Supplier. Portanto, isso culmina em um tempo de resposta ainda maior do que a junção estrela para um esquema estrela.

26 26 (a) Esquema estrela (Figura 2) com realce para junções e atributos selecionados da consulta (b) Consulta SQL sobre o esquema estrela (Figura 2) com realce para as junções Figura 10. Esquema estrela e uma consulta usando a junção estrela Fragmentação Vertical dos Dados A fragmentação vertical dos dados mantém o conjunto mínimo de atributos do esquema estrela que são necessários para responder um conjunto de consultas [13]. Ou seja, a fragmentação vertical dos dados visa a eliminação do custo das junções no processamento das consultas. Por exemplo, para a consulta apresentada na Figura 10b, o conjunto de atributos necessário para a execução da consulta é c_region, s_region, c_nation, s_nation, d_year e lo_revenue, e sua tabela é visualizada na Figura 11a. Assim, é gerada uma visão fragmentada verticalmente obtida pela execução de junções existente, que para o exemplo é Π c_region, s_region, c_nation, s_nation, d_year, lo_revenue (Customer Lineorder Supplier Date). A execução da consulta SQL para formar esta visão fragmentada verticalmente para o esquema estrela da Figura 2 é apresentada na Figura 11b. Portanto, essa visão pode armazenar os dados para melhorar o desempenho do processamento de consultas, pois, elimina as junções envolvidas e somente realiza os filtros e agrupamentos para responder as consultas.

27 27 (a) A visão fragmentada verticalmente (b) SQL para compor a visão Figura 11. Visão fragmentada verticalmente Para responder a mesma consulta da Figura 10b, a visão fragmentada verticalmente apresentada na Figura 11a foi construída. Para executar a consulta sobre a visão fragmentada verticalmente as junções não serão necessárias, então somente os filtros c_region = ASIA AND s_region = ASIA AND d_year >= 1992 AND d_year <= 1997 e os agrupamentos da seleção serão executados. A consulta sobre a visão fragmentada verticalmente é mostrada na Figura 12. A Figura 12a mostra as tuplas selecionadas pela consulta da Figura 12b. Posteriormente os dados serão agregados e a função de agregação sum será executada sobre o atributo lo_revenue. (a) Tuplas selecionadas da visão (b) SQL da consulta sobre a visão Figura 12. Resultado de uma consulta executada sobre a visão fragmentada verticalmente Visão Materializada Uma visão materializada armazena informações do DW preprocessados que podem ser usadas para responder consultas frequentemente exigidas [9] [10] [11] [12]. Uma visão

28 28 materializada é construída pela criação de uma tabela que preprocessa junções da tabela de fatos com as tabelas de dimensão, e suas medidas são agregadas. Assim uma visão materializada armazena os dados agregados preprocessados, elimina o processamento de junções e agrupamentos, e reduz drasticamente o número de linhas beneficiando os filtros [9]. Por exemplo, para a consulta apresentada na Figura 10b, o conjunto de atributos necessário para a execução da consulta é c_region, s_region, c_nation, s_nation, d_year e lo_revenue, e a função de agregação da medida lo_revenue é o sum. A visão materializada correspondente é visualizada na Figura 13a. Assim, para compor a visão materializada, é necessário executar as junções existentes entre os atributos, agrupá-los e aplicar a função de agregação, sendo c_nation, s_nation, d_year, G SUM(lo_revenue) (Π c_region, s_region, c_nation, s_nation, d_year, lo_revenue (Customer Lineorder Supplier Date) ). A execução da consulta SQL para formar esta visão materializada para o esquema estrela da Figura 2 é apresentada na Figura 13b. Portanto, essa visão materializada pode armazenar os dados para melhorar o desempenho do processamento de consultas, pois elimina as junções envolvidas e agrupamentos, e somente os filtros são necessários. Além disso, os filtros são beneficiados pela redução de linhas envolvidas. (a) A visão materializada (b) SQL para compor a visão materializada Figura 13. Visão materializada Para responder a consulta da Figura 10b, a visão materializada na Figura 13a foi construída. Para executar a consulta sobre a visão materializada as junções e agrupamentos não serão necessárias, então somente os filtros c_region = ASIA AND s_region = ASIA AND d_year >= 1992 AND d_year <= 1997 serão executados. A consulta sobre a visão materializada é mostrada na Figura 14. A Figura 14a mostra a tupla selecionada pela consulta da Figura 14b. Portanto, somente os filtros foram realizados na visão materializada, selecionando diretamente seus valores para a classificação.

29 29 (a) Tupla selecionada da visão materializada (b) SQL da consulta sobre a visão materializada Figura 14. Resultado de uma consulta executada sobre a visão materializada Índice Bitmap de Junção Estruturas de indexação são alternativas para melhorar o desempenho de consultas em DW [8] [10] [15]. Existem o índice bitmap e o índice bitmap de junção, sua estenção, comumente usados para o processamento de consultas em DW. O índice bitmap constrói um vetor de bits (bit-vector) para cada valor distinto do atributo indexado [14] [15]. A cardinalidade do atributo é o número de valores distintos dele e determina a quantidade de vetores de bits existentes. Todos os vetores de bits tem a mesma quantidade de bits que o número de linhas contidas na tabela indexada. Cada vetor de bits é composto pelos valores 0 e 1. Se para a i-ésima tupla da tabela ocorrer o valor associado ao vetor de bits, então o i-ésimo bit do vetor de bits irá ter o valor 1. Caso contrário, o bit será 0. A principal vantagem de utilizar o índice bitmap para processar consultas é de realizar operações bit-a-bit que são eficientemente processadas pelo hardware. Adicionalmente, um índice bitmap de junção [8] [16] [17] pode ser criado sobre atributos das tabelas de dimensão para evitar a operação de junção das tabelas de dimensão com a tabela de fatos. Portanto, o índice bitmap de junção estende o índice bitmap. Deste modo, a i-ésima entrada de um vetor de bits possui o bit com valor 1 se o valor correspondente ocorre na i-ésima tupla da tabela de fatos. Caso contrário, o bit será 0. Este índice dispensa o uso de junções entre as tabelas envolvidas, economizando a tarefa custosa de junção dos dados tanto em um esquema estrela quanto floco de neve. Para responder a mesma consulta da Figura 10b, índices bitmap de junção podem ser construídos sobre os atributos envolvidos na consulta. Portanto, os índices bitmap de junção são construídos sobre Π c_region, s_region, c_nation, s_nation, d_year, lo_revenue (Customer Lineorder Supplier Date), mostrado na Figura 11a. A Figura 15 mostra a visão fragmentada

30 30 verticalmente e seus respectivos índices bitmap de junção. Usando este índice, as junções são evitadas e as operações de recuperação dos dados são executadas mais rapidamente. Índices bitmap de junção podem ser construídos também sobre visões materializadas [17], como mostra a Figura 16. Dessa forma, o processamento de consultas será mais eficiente que a sobre visão fragmentada verticalmente, uma vez que os dados estão agregados e existe uma redução no volume de dados indexado. Logo, o uso de índices bitmap de junção sobre uma visão materializada reduz a quantidade de vetores de bits criados para cada atributo, por aplicar funções de agregação nas medidas (como por exemplo, lo_revenue). (a) a visão fragmentada verticalmente (b) índices bitmap de junção correspondente Figura 15. Índices bitmap de junção sobre uma visão fragmentada verticalmente (a) a visão materializada (b) índices bitmap de junção correspondente Figura 16. Índices bitmap de junção sobre uma visão materializada Para realizar consultas sobre o índice, as operações OR são realizadas primeiramente para depois serem executadas as operações AND, e então buscar os resultados. Por exemplo, seja o índice da Figura 15b, criado sobre uma visão fragmentada verticalmente, para processar uma consulta com as restrições c_region = ASIA AND (d_year = 1992 OR d_year = 1998), primeiramente são realizadas as operações OR com os vetores de bits 1992 e 1998 do atributo d_year. Depois, a operação AND é executada com o vetor de bits ASIA do atributo

31 31 c_region e então são selecionadas as tuplas do resultado. Esse processo é mostrado na Figura 17. Figura 17. Consulta sobre índices bitmap de junção Uma das desvantagens do índice bitmap são atributos com alta cardinalidade [14], pois aumenta drasticamente o número de vetores de bits e o espaço de armazenamento dos índices causando perda de desempenho nas consultas. As técnicas de binning, compressão e codificação visam minimizar essas perdas [8] [14]. O FastBit é uma implementação eficiente de índice bitmap desenvolvido por Lawrence Berkeley Nation Laboratory e consiste num software livre [26] [27]. Este software não dispõe de mecanismos para criação automática de índices bitmap de junção, além de exigir a digitação de extensos e complexos comandos aos terminais de comando do sistema operacional e do SGBD. A visualização dos resultados de consultas é por meio de uma representação tabular em um arquivo-texto, impondo limitações ao seu uso para tomada de decisão. 2.4 Processamento de Atualizações Em geral, atualizações em DW em um ciclo regular de tempo, por exemplo, diária, semanal ou mensalmente, e a maioria consiste somente em operações de inclusão de registros (append-only) [7] [9] [28] [29]. Além disso, a inserção de registros em DW ocorre em lotes [3]. A atualização de valores de registros é incomum e desencorajado em DW [3]. Portanto, quando atualizações ocorrem em um DW que utiliza técnicas para melhorar o desempenho de

32 32 consultas, como a fragmentação vertical de dados, visão materializada ou índices bitmap de junção, estas também devem ser atualizadas com os novos registros adicionados [28] [29]. Suponha que três linhas foram inseridas no DW descrito na Figura 2, como mostrado na Figura 18. Considere que lo_suppkey=800 referencia um fornecedor localizado no Brasil, lo_custkey=287 referencia um consumidor localizado no Japão e lo_orderdate=550 ocorreu em Tupla 1 (t1) lo_orderkey lo_linenumber lo_partkey lo_custkey lo_orderdate lo_suppkey lo_revenue lo_shipmode AIR Tupla 2 (t2) c_custkey c_name c_phone c_mktsegment c_address c_city c_nation c_region CUBA AUTOMOBILE CUBA01 HAVANA CUBA AMERICA Tupla 3 (t3) lo_orderkey lo_linenumber lo_partkey lo_custkey lo_orderdate lo_suppkey lo_revenue lo_shipmode AIR Figura 18. Três registros para serem incluídos no DW A tupla t1 é inserida primeiramente na tabela de fatos Lineorder. Considerando a visão fragmentada verticalmente da Figura 11a, uma nova tupla será adicionada, como {'ASIA', 'AMERICA', 'JAPAN', 'BRAZIL', 1993, 8190}. Para atualizar os índices bitmap de junção correspondente à visão fragmentada verticalmente, mostrada na Figura 15b, o vetor de bits para c_region='asia' terá um bit 1 adicionado, e os outros modificados similarmente. Para a visão materializada da Figura 13a, a segunda linha deverá ser modificada atualizando o valor de sum(lo_revenue) para ( ). Logo, para modificar o índice bitmap de junção correspondente a visão materializada mostrado na Figura 16b, o vetor de bits do atributo sum(lo_revenue) para o valor deverá ser substituído de um bit 1 para 0. Além disso, um vetor de bits para o valor deverá ser criado e ter um bit 1 para a segunda linha, e o restante das linhas 0. Claramente a inserção do registro t1 no DW deve ter manutenções severas para manter visões fragmentadas verticalmente, visões materializadas ou índices bitmap de junção, que são necessárias para melhorar o desempenho de processamento de consultas. Posteriormente, a tupla t2 é inserida na tabela de dimensão Customer e não afeta a visão fragmentada verticalmente, visões materializadas ou índices bitmap de junção, por ser associada exclusivamente à tabela de dimensão. Finalmente, a tupla t3 é inserida na tabela de fatos Lineorder. Como resultado, a visão fragmentada verticalmente da Figura 11a terá uma nova linha adicionada, como {'AMERICA', 'AMERICA', 'CUBA', 'BRAZIL', 1993, 7910}.

33 33 Para os índices bitmap de junção mostrados na Figura 15b, será necessário: adicionar um bit 1 no vetor de bits de c_region='america' e adicionar um bit 0 no vetor de bits de c_region='asia'; adicionar um bit 1 no vetor de bits de s_region='america' e adicionar um bit 0 no vetor de bits de s_region='asia'; criar um novo vetor de bits para c_nation='cuba', com um bit 1 na última linha e bits zeros nas linhas restantes; adicionar um bit 1 no vetor de bits de s_nation='brazil' e adicionar bit 0 nos outros vetores de bits desse atributo, e; adicionar um bit 1 no vetor de bits para d_year=1993 e adicionar bit 0 nos outros vetores de bits desse atributo. Para a visão materializada mostrada na Figura 13a, uma nova linha composta por {'AMERICA', 'AMERICA', 'CUBA', 'BRAZIL', 1993, 7910} será adicionada. Se o atributo sum(lo_revenue) foi indexado, um novo vetor de bits para o valor 7910 deverá ser construído com um bit 1 na última linha e 0 nas restantes. Finalmente, o índice bitmap de junção de c_nation da Figura 16b, terá um novo vetor de bits para o valor 'CUBA', enquanto os outros vetores de bits serão modificados similarmente ao dos índices bitmap de junção para a visão fragmentada verticalmente, como discutido. Claramente, a inserção de t1 e t3 no DW demanda mais alterações a serem realizadas para a manutenção de visões fragmentadas verticalmente, visões materializadas e índices bitmap de junção para melhorar o processamento de consultas. Particularmente, o índice bitmap de junção pode requerer a criação de mais vetores de bits, como demonstrado.

34 34 3 Uma Ferramenta OLAP Baseada no Índice Bitmap de Junção Neste capítulo é apresentada a ferramenta The Bitmap Join Index OLAP Tool (BJIn OLAP Tool), que consiste na principal contribuição desta monografia. Por razão de simplicidade, ela será tratada como BJIn OLAP no restante desse capítulo, o qual possui a estrutura que segue. Na seção 3.1 o projeto da ferramenta BJIn OLAP é explicado com a apresentação de seus casos de uso e funcionalidades gerais. Nas seções 3.2, 3.3, 3.4 e 3.5 são descritos os fluxos de dados para as seguintes operações sobre os índices bitmap de junção: construção, consulta, atualização e exclusão. Por fim, na seção 3.6 são descritos os recursos adicionais da ferramenta BJIn OLAP. 3.1 O Projeto A ferramenta BJIn OLAP foi especificada e modelada utilizando diagramas de casos de uso, diagramas de classe e diagramas de sequência da UML (Unified Modeling Language) [30] [31] [32] [33]. Protótipos foram desenvolvidos incrementalmente, sendo testados e avaliados para atender a cada caso de uso. As principais funcionalidades da ferramenta, descritas nas seções 3.2 a 3.5, são retratadas pelo diagrama de casos de uso na Figura 19. Os atores são os programas Mondrian Schema Workbench e FastBit, o SGBD, e o Usuário. Os casos de uso são: (i) Manter Índices Bitmap de Junção; (ii) Consultar Índices Bitmap de Junção; e, (iii) Processar Operações OLAP. O Usuário interage com o Mondrian Schema Workbench para especificar o esquema do DW e uma lista de atributos a serem indexados. A validação desses dados ocorre na interação entre o Mondrian Schema Workbench e o SGBD. Se a lista for válida, ela é repassada pelo Mondrian Schema Workbench ao Usuário.

35 35 Figura 19. Diagrama de caso de uso da ferramenta BJIn OLAP A ferramenta BJIn OLAP foi implementada como um servidor OLAP de código fonte aberto (open source) sob a linguagem de programação Java [31] [32] [34] No lado do servidor, a ferramenta opera o SGBD e o FastBit para construir índices bitmap de junção, processar consultas sobre estes índices e atualizar os índices. Então, o caso de uso Manter Índices Bitmap de Junção se refere às operações de criar, atualizar e excluir índices bitmap de junção. Neste caso de uso, para as operações de construção e de atualização dos índices, ocorre a interação com o SGBD e com o FastBit. Apenas após a construção dos índices é que se permite a submissão de consultas sobre os mesmos pelo ator Usuário. Enquanto, o caso de uso Consultar Índices Bitmap de Junção se refere à operação de consultas sobre os índices bitmap de junção, existindo interação com o FastBit. Onde o ator Usuário, interage por meio de páginas JSP [34] para submeter consultas e analisar os dados multidimensionais por meio de tabelas cruzadas (cross tables) [25] e gráficos gerados pelo framework Open Ajax Toolkit Framework [35]. Por simplicidade, tal framework será tratado neste trabalho apenas por OAT. As consultas não requerem interação direta com o SGBD porque, uma vez que os índices são construídos, as consultas incidem apenas sobre eles. Deste modo, há interação somente com o FastBit. Quando o usuário redige as consultas, a ferramenta BJIn OLAP oferece mecanismos de realce (highlight) e de complemento automático (autocomplete) por meio da biblioteca

36 36 CodeMirror 2 [36]. Além disso, recursos da biblioteca JQuery [37] são utilizados para auxiliar a construção e atualização de índices bem como a escrita de consultas. Por exemplo, por meio de visualização em árvore da estrutura do cubo de dados indexado. Para a exibição dos resultados das consultas, foram empregadas requisições assíncronas e JSON (JavaScript Object Notation) [38] [39]. Além disso, a ferramenta BJIn OLAP oferece suporte ao registro de logs em diferentes níveis e diferentes categorias, utilizando a API log4j [40]. As operações OLAP representadas pelo caso de uso Processar Operações OLAP, exigem que uma consulta tenha sido previamente executada. Os resultados prévios podem ser reusados, ou pode ser formulada uma nova consulta e processada acessando os índices bitmap de junção. As operações das quais a ferramenta BJIn OLAP provê suporte, acessando exclusivamente índices bitmap de junção, são: drill-down, roll-up, slice-and-dice e pivoting. Atualmente, a ferramenta BJIn OLAP é compatível com os softwares mostrados na Tabela 1, e suas respectivas versões mínimas. Além disso, a ferramenta BJIn OLAP provê suporte aos esquemas estrela e floco de neve. Tabela 1. Compatibilidade da ferramenta BJIn OLAP Categoria Nome do Software Versão Mínima Windows XP Sistema Operacional Linux - PostgreSQL 8.3 SGBD MySQL 5.4 IBM DB2 9.7 Opera 9.2 Chrome 10 Navegador Firefox 2.0 Internet Explorer Construindo Índices Bitmap de Junção A Figura 20 exibe os fluxos de dados existentes na operação de construção dos índices bitmap de junção, conforme o caso de uso Manter Índices Bitmap de Junção da Figura 19. A ferramenta BJIn OLAP usa o termo índice para se referir a um conjunto de índices bitmap de junção que foram definidos sobre diversos atributos, tais como c_region, s_region, c_nation, s_nation, d_year e lo_revenue, por exemplo. Esta nomenclatura será adotada neste capítulo. Primeiramente, o usuário executa o Mondrian Schema Workbench para especificar quais atributos serão indexados, bem como quais são as tabelas de dimensão, a tabela de fatos, as medidas, e os atributos que compõem as hierarquias (fluxo 1). O Mondrian Schema

37 37 Workbench acessa o SGBD e confere o esquema do DW, garantindo que o documento XML seja válido (fluxo 2). Caso seja válido, este documento é disponibilizado para o usuário (fluxo 3). Em seguida, o usuário usa a ferramenta BJIn OLAP para realizar o carregamento do documento XML gerado (fluxo 4). Após, o usuário deverá fornecer o nome do índice, seu nome de usuário e sua senha para acesso ao SGBD. O usuário deve ainda indicar se deseja construir o índice sobre uma visão materializada, e se o referido índice será atualizável ou não. A operação de atualização será discutida na seção 3.4. Assim que essas informações são fornecidas, o documento XML é interpretado. São executados comandos SQL e comandos de exportação de dados sobre o SGBD, o qual computa as junções e cria uma tabela temporária (fluxo 5). Esta tabela temporária é composta pela junção entre as tabelas de dimensão e a tabela de fato, desde que existam atributos dessas tabelas citados no documento XML. Se o índice for construído sobre uma visão materializada, esta será similar ao da Figura 16a. Caso contrário, será similar ao da Figura 15a. Após a criação da tabela temporária, o SGBD a exporta para um conjunto de arquivos CSV (Comma- Separated Values) que são armazenados no mesmo diretório onde o índice será criado (fluxo 6). A seguir, a ferramenta BJIn OLAP executa comandos ardea e ibis do FastBit (fluxo 7), os quais transformam o conjunto de arquivos CSV no formato interno do FastBit (fluxo 8), e constroem os índices bitmap de junção (fluxo 9). Finalmente, a ferramenta BJIn OLAP escreve um arquivo de log e um documento XML no diretório do índice (fluxo 10). O documento XML descreve internamente os índices bitmap de junção construídos. Já arquivo de log mantém a descrição completa da operação de construção do índice para o usuário, indicando a etapa da construção em que se encontra. Tal log é mantido independentemente do log descrito na seção

38 38 Figura 20. Fluxos de dados para construção de índices bitmap de junção Por exemplo, sejam os fluxos de dados da Figura 20 e seja um documento XML definido pelo usuário no Mondrian Schema Workbench, (fluxos 1 a 3), relativo ao DW mostrado na Figura 2, e que especifica os atributos c_region, s_region, c_nation, s_nation, d_year e lo_revenue para serem indexados. O reuso do Mondrian Schema Workbench viabiliza a interoperabilidade entre o Mondrian OLAP Server e a ferramenta BJIn OLAP, de forma que ambos utilizem o documento XML. Enquanto o Mondrian OLAP Server lê o documento XML para descrever o cubo de dados do DW, a ferramenta BJIn OLAP constrói índices bitmap de junção sobre os atributos especificados no documento XML. O documento XML é carregado na ferramenta BJIn OLAP (fluxo 4). Neste momento a ferramenta BJIn OLAP valida se o referido XML contém todas as chaves primárias e estrangeiras, tipos de dados dos atributos bem como nomes dos elementos. Posteriormente, o usuário deve fornecer as informações mostradas pela Figura 21 (fluxo 4). Estas são, o documento XML, usuário e senha do sistema gerenciador de banco de dados. Ao selecionar a opção de criar índice sobre a visão materializada, a ferramenta BJIn OLAP mostrará uma árvore de seleção dos atributos a serem indexados. Na Figura 21, todos os atributos disponíveis foram selecionados. Claramente, os atributos a serem indexados envolvem quatro diferentes tabelas para junção, Customer, Supplier, Date e Lineorder. Portanto, para construir o referido índice, a tabela temporária é similar àquela mostrada na Figura 16a (fluxo 5). Depois que os dados da tabela temporária são exportados para arquivos

39 39 CSV, os índices bitmap de junção são construídos sobre os atributos da tabela temporária (fluxos 7 a 9). Figura 21. Tela de construção de índices bitmap de junção A ferramenta BJIn OLAP contorna uma deficiência do FastBit para manipular arquivos CSV na construção de o índices bitmap de junção (fluxos 8 e 9). Para transformar o arquivo CSV no formato binário interno (fluxo 8), o FastBit carrega o arquivo CSV inteiramente em memória primária. Neste sentido, a ferramenta BJIn OLAP realiza cálculos para evitar que o carregamento do arquivo exceda a memória primária disponível (i.e., previne o estouro de memória ). A Tabela 2 mostra o conjunto de fórmulas matemáticas utilizadas para realizar os cálculos citados. Cada variável utilizada pelas fórmulas da Tabela 2 são descritas na Tabela 3. Primeiramente, é calculado o número máximo de linhas que cada arquivo CSV deverá ter (F 1 ), e quantos arquivos serão criados (F 2 ). Em seguida, é calculado o número de diretórios em que os arquivos do FastBit serão armazenados (F 3 ). Os índices são construídos sobre os arquivos de cada um desses diretórios. Depois de definido o número de diretórios que deverão ser criados, a última etapa é calcular o número de arquivos CSV que irão compor cada diretório (F 4 ).

40 40 Tabela 2. Fórmulas usadas pela ferramenta BJIn OLAP Fórmula Objetivo F 1 N = T / (RAM / FASTBIT_DIVISOR) Definir o número de linhas máximo de cada arquivo CSV F 2 L = T n / N Definir a quantidade total de arquivos CSV F 3 P = (L * S) / (RAM / FASTBIT_DIVISOR) Definir a quantidade de diretórios F 4 C = L / P Definir o número de arquivos CSV para cada diretório Tabela 3. Variáveis correspondentes das fórmulas da Tabela 2 Variável Descrição N Número máximo de linhas de cada arquivo CSV T Tamanho em MB da tabela temporária RAM Tamanho em MB da memória primária do servidor FASTBIT_DIVISOR Valor 2,2 usado como margem de segurança, que assegura o uso de menos da metade da memória L Quantidade total de arquivos CSV T n P S C Número de tuplas da tabela temporária Quantidade total de diretórios Tamanho em MB do maior arquivo CSV criado Número de arquivos CSV para cada diretório As últimas operações relativas à construção de índices bitmap de junção se referem à gravação de log e à geração de um documento XML (fluxo 10). Esse documento consiste em uma descrição interna dos índices que nomeia as colunas internamente para serem usadas nas consultas, definindo um mapeamento para as colunas armazenadas fisicamente. Internamente, cada coluna indexada é nomeada como col i, com 0 i < n, onde n é o número de colunas indexadas. Este recurso possibilita manipular as colunas dos índices sem afetar o nome real delas, o que facilita a escrita de consultas e evita ambiguidades. Por exemplo, se o usuário especificar duas hierarquias para uma dimensão Customer da Figura 2, como c_region c_nation e c_nation c_address, somente um índice bitmap é criado sobre o atributo c_nation e duas colunas lógicas são definidas no documento XML que contém a

41 41 definição interna dos índices. Isso pode ocorrer quando existe mais de uma hierarquia em uma dimensão que utilize os mesmos atributos, como exemplificado. A Figura 22 mostra o documento XML de definição interna dos índices para os atributos c_region, s_region, c_nation, s_nation, d_year e lo_revenue, conforme o exemplo. Na tag FastBitColumns o atributo timestamp indica quando o índice foi criado, enquanto o atributo aggtable indica se o índice foi criado sobre uma visão materializada. Cada atributo indexado, é dividido em duas tags, FastBitColumnLevel e FastBitColumnMeasure. Os atributos indexados e contidos em FastBitColumnLevel, sob a tag ColumnLevel, são os níveis pertencentes as tabelas de dimensão. Por sua vez, a tag ColumnLevel contém os atributos assim descritos: (i) dimension é o nome da dimensão; (ii) hierarchy é o nome da hierarquia de dimension; (iii) level é o nível de granularidade de hierarchy; (iv) datatype é o tipo de dado de level segundo o FastBit; (v) name é o nome real do atributo indexado; e (vi) alias é o nome atribuído pelo usuário ao level, o qual é o usado na escrita de consultas. As hierarquias são retratadas pelo documento XML. O nível ancestral de cada level é mostrado no atributo rollup. Já o nível descendente de cada level é listado no atributo drilldown. Por exemplo, o nível ancestral do level Nation (atributo c_nation) da dimensão Customer é o level Region (atributo c_region), representando a dimensão Customer. Assim se retrata a hierarquia c_region c_nation. As medidas da tabela de fatos são representadas pela tag FastBitColumnMeasure. Cada tag ColumnsMeasure contém os atributos assim descritos: (i) measure é o nome da medida; (ii) datatype é o tipo de dado de measure segundo o FastBit; (iii) name é o nome real do atributo indexado; (iv) alias é o nome atribuído pelo usuário à medida measure, o qual é o usado na escrita de consultas. A tag UpdateStarSchema se refere ao suporte a atualizações, o qual será discutido na seção 3.4.

42 42 <FastBitColumns timestamp=" " aggtable="true"> <FastBitColumnLevel> <ColumnLevel dimension="date" hierarchy="year" level="year" datatype="int" name="col1" alias="d_year"/> <ColumnLevel dimension="supplier" hierarchy="supplier" level="region" datatype="key" drilldown="s_nation" name="col2" alias="s_region"/> <ColumnLevel dimension="supplier" hierarchy="supplier" level="nation" datatype="key" rollup="s_region" name="col3" alias="s_nation"/> <ColumnLevel dimension="customer" hierarchy="customer" level="region" datatype="key" drilldown="c_nation" name="col4" alias="c_region"/> <ColumnLevel dimension="customer" hierarchy="customer" level="nation" datatype="key" rollup="c_region" name="col5" alias="c_nation"/> </FastBitColumnLevel> <FastBitColumnMeasure> <ColumnMeasure measure="revenue" datatype="double" name="col0" alias="lo_revenue"/> </FastBitColumnMeasure> <UpdateStarSchema schema="public" table="temptable2" trigger="bjinolap_updateindex1" lastupdatetimestamp=" " availablerowlastpartition="0"/> </FastBitColumns> Figura 22. Exemplo de documento XML da definição interna dos índices bitmap de junção 3.3 Consultando Índices Bitmap de Junção Sabe-se que, ao término da operação de construção, um documento XML contendo a descrição interna do índice é gerado, além de um arquivo de log, conforme a Figura 20 (fluxo 10). A partir de então, esse índice fica disponível para ser consultado. Na Figura 23 é exibido os fluxos de dados existentes na operação de consulta sobre os índices bitmap de junção, conforme o caso de uso Consultar Índices Bitmap de Junção da Figura 19. Primeiramente, o usuário escolhe o índice que será usado para o processamento das consultas, e redige uma consulta usando uma linguagem semelhante a SQL (fluxo 1). Essa linguagem de consulta é definida pelo FastBit e não requer junções e nem cláusulas de agrupamento. O agrupamento é realizado sobre as colunas listadas na cláusula SELECT. Já os filtros são especificados na cláusula WHERE. A cláusula FROM é omitida, pois o usuário selecionou previamente o índice que será consultado. Em seguida, a ferramenta BJIn OLAP compõe o comando ibis contendo a consulta e o índice escolhido, submetendo-o ao FastBit (fluxo 2). A ferramenta BJIn OLAP redige a

43 43 consulta submetida de acordo com o documento XML de definição interna do índice. Então, o FastBit acessa o diretório do índice, processando a consulta (fluxo 3) e escrevendo seu resultado em um conjunto de arquivos CSV (fluxo 4). Depois, a ferramenta BJIn OLAP processa a leitura do conjunto de arquivos CSV (fluxo 5). No final da leitura, é enviado um JSON para o navegador, como resposta da requisição assíncrona (Ajax) do usuário. Com esse mecanismo, a ferramenta BJIn OLAP (servidor) envia apenas o conteúdo necessário para ser processado pelo navegador (cliente). Deste modo, a ferramenta BJIn OLAP, utilizando o OAT, constrói tabelas cruzadas (cross tables) e gráficos para exibir os resultados ao usuário em páginas JSP (fluxo 6). Figura 23. Fluxo de dados para consulta de índices bitmap de junção Por exemplo, seja o índice conforme descreve o documento XML da Figura 22, sendo indexados os atributos c_region, s_region, c_nation, s_nation, d_year e lo_revenue para o esquema estrela da Figura 2. Então, o usuário seleciona o índice e submete a consulta com os filtros SELECT c_nation, s_nation, d_year, sum(lo_revenue) WHERE c_region = ASIA AND s_region = ASIA AND d_year >= 1992 AND d_year <= Na Figura 24 é mostrada a interface da ferramenta BJIn OLAP para a escrita dessa consulta, com os recursos de realce (highlight) e de complemento automático (autocomplete). A cláusula WHERE da consulta redigida consiste na operação OLAP slice-and-dice. Ela restringe consumidores e fornecedores por suas nações no continente asiático, compreendendo os anos de 1992 até Depois que a consulta é submetida e executada (fluxos 2 a 5), os resultados são mostrados para o usuário (fluxo 6). O resultado dessa consulta é exibido na Figura 25. Além disso, as operações OLAP se tornam disponíveis para serem realizadas sobre os resultados apresentados, como destacado na Figura 25. A operação OLAP roll-up é disponibilizada na

44 44 escolha dos atributos na caixa de combinação (combo-box). A operação pivoting é viabilizada arrastando e soltando (drag and drop) as colunas, para trocar os eixos. Complemento automático Realce Figura 24. Escrita da consulta com recurso de realce e complemento automático Roll-up Pivoting Figura 25. Resultado da consulta e operações OLAP disponíveis Nas seções subsequentes são mostradas todas as operações OLAP que a ferramenta BJIn OLAP disponibiliza, tomando como exemplo o resultado da consulta mostrado na Figura 25. Essas operações são modeladas pelo caso de uso Processar Operações OLAP da Figura 19.

45 Slice-and-Dice Como visto na Figura 25, as operações OLAP são viabilizadas no resultado de uma consulta. A operação OLAP slice-and-dice foi efetuada a partir das restrições definidas na cláusula WHERE, processadas pelo servidor. Por outro lado, esta operação pode ser empregada no lado do cliente, realizando filtros de análises sobre o resultado já existente, portanto sem acessar o servidor. Para tornar mais restritos os resultados da consulta mostrados na Figura 25, é possível realizar filtros sobre as colunas já presentes na tabela cruzada. Na Figura 26 é indicado como foi iniciada uma operação slice-and-dice sobre a coluna s_nation, selecionando apenas o valor CHINA. Isto é semelhante a adicionar o filtro s_nation= CHINA. Além disso, podem-se ordenar os resultados em ordem crescente (ascending) ou decrescente (descending). Para completar a operação slice-and-dice, foi ainda realizada uma filtragem de maneira semelhante, mas que determina c_nation = JAPAN. O resultado completo da operação sliceand-dice é exibido na Figura 27. Deve-se enfatizar que o servidor não é acessado na operação slice-and-dice auxiliada pelos componentes da interface. Já nos filtros especificados na cláusula WHERE, o servidor é acessado. Slice-and-dice s_nation= CHINA Figura 26. Operação OLAP slice-and-dice

46 46 Figura 27. Operação OLAP slice-and-dice completa Drill-down e Roll-up As operações OLAP roll-up e drill-down são habilitadas quando existirem atributos que fazem parte de alguma hierarquia na cláusula SELECT da consulta que foi processada. Na Figura 25, a operação OLAP roll-up foi viabilizada porque a cláusula SELECT listou os atributos s_nation e c_nation. Logo, viabiliza-se a opção de aumentar a sumarização dos dados, escolhendo um nível de granularidade maior na hierarquia. Para efetuar essa operação, seleciona-se o nível de origem e o nível de destino. Por exemplo, uma operação roll-up é selecionar o nível de origem c_nation e nível de destino c_region, a partir dos resultados exibidos na tabela cruzada da Figura 25. Essa operação é realizada selecionando os níveis desejados nas caixas de combinação. Se existisse um nível acima de c_region este também estaria disponível para realizar a operação roll-up. Desta forma, não seria necessário se referir sempre a níveis subjacentes para efetuar tal operação. De maneira análoga, a ferramenta BJIn OLAP viabiliza a operação drill-down, detalhando os dados em um nível de granularidade mais baixo. Para uma operação roll-up ou drill-down ser executada, o servidor é acessado e uma nova consulta é gerada e processada. Neste processamento, o desempenho é beneficiado pelo cache do FastBit que mantém resultados da consulta anterior Pivoting Para realizar uma operação pivoting, basta o usuário arrastar uma coluna da tabela cruzada e soltar sobre o seu eixo oposto. Deste modo, pode-se transformar uma coluna em

47 47 uma linha e vice-versa. Essa operação modifica a visualização atual dos dados, sendo processada no lado do cliente e sem o envio de requisição ao servidor. Na Figura 28 é mostrada uma operação pivoting sobre a Figura 27. A coluna d_year do eixo das colunas foi arrastada para o eixo das linhas, modificando a estrutura da tabela cruzada. Nesta operação OLAP, os gráficos também são atualizados no lado do cliente, retratando a nova tabela cruzada. Figura 28. Operação pivoting sobre a Figura Atualizando Índices Bitmap de Junção Na ferramenta BJIn OLAP, índices bitmap de junção são atualizáveis se o usuário habilitar esse recurso antes da construção do índice. Com essa opção habilitada, a ferramenta BJIn OLAP automaticamente cria dois componentes essenciais para realizar a atualização dos índices bitmap de junção. Um dos componentes é uma tabela temporária com os mesmos atributos dos índices. O outro componente é um gatilho (trigger) implementado no SGBD, que verifica se novas tuplas foram adicionadas à tabela de fatos do DW. Além disso, o documento XML de descrição dos índices contém informações pertinentes para a atualização dos índices. Essas informações são mantidas na tag UpdateStarSchema no corpo da tag FastBitColumns, conforme mostra a Figura 22. Nesta tag existem os atributos assim descritos: (i) trigger é o nome do gatilho criado sobre a tabela de fatos; (ii) table é o nome da tabela de atualizações;(iii) schema é o esquema do banco de dados em que o gatilho e a tabela de atualizações estão; (iv) availablerowlastpartition indica

48 48 a quantidade de tuplas disponíveis no último diretório criado para armazenar os índices e (v) lastupdatetimestamp indica quando ocorreu a última atualização. Então, essa tag armazena as informações necessárias para manter a tabela de atualizações e gatilho. Na seção o gatilho é discutido e apresentado o gatilho utilizado pela ferramenta BJIn OLAP. Por fim, na seção são explicados os fluxos de dados da operação de atualização de índices bitmap de junção, a partir da tabela de atualizações composta por registros que foram adicionados pelo gatilho O Gatilho O gatilho detecta inserções na tabela de fatos e então insere os novos registros na tabela de atualizações, tal como as tuplas t1 e t3 exemplificadas na Figura 18. Inserem-se novas tuplas na tabela de atualizações somente depois que os registros são inseridos na tabela de fato (AFTER INSERT). Então, são mapeados os valores de cada atributo das dimensões que foram indexadas, usando as chaves estrangeiras referenciadas pela tupla inserida. Então, as tuplas com os valores mapeados são inseridas na tabela de atualizações. Por sua vez, a tabela temporária conterá um conjunto de registros para serem adicionados aos índices bitmap de junção. O gatilho tem uma sequência de tarefas para serem processadas, que independe do esquema do DW. Essas tarefas são detalhadas no Algoritmo 1, e seus parâmetros e variáveis locais são descritos na Tabela 4. Inicialmente, o registro que será inserido na tabela de atualizações está vazio (linha 1). Uma estrutura de repetição assegura o processamento das tarefas seguintes para toda tupla inserida na tabela de fatos (linhas 2 a 19). Para cada atributo da linha inserida, os valores são mapeados para compor o registro a ser inserido na tabela (linhas 3 a 14). Atributos que tem chaves estrangeiras referenciando tabelas de dimensão (linhas 4 a 12) são distinguidos dos atributos que são medidas (linha 13). Finalmente, o registro com os valores mapeados é inserido na tabela de atualizações (linhas 15 a 18). A verificação de cada tabela de dimensão (linha 4) tem como objetivo mapear os valores dos atributos que referenciam as tabelas de dimensão por meio de chaves estrangeiras (como lo_custkey na Figura 2). Assim, os valores são trocados por valores dos atributos indexados (tais como c_region e c_nation da Figura 2). Para compor o conjunto de atributos C, é testado se o atributo corrente pertence a alguma tabela de dimensão (linha 5). Em caso positivo, o conjunto C é o resultado da intersecção dos atributos pertencentes à tabela de dimensão e à tabela de atualizações (linha 6). Por exemplo, se a tabela de dimensão é Customer (Figura 2) e a tabela tem os atributos da Figura 15a, então é atribuído a C o resultado de {c_region, s_region, c_nation, s_nation, d_year, d_year, lo_revenue}

49 49 {c_custkey, c_name, c_phone, c_mktsegment, c_address, c_city, c_nation, c_region}, portanto C = {c_nation, c_region}. Então, para cada elemento de C, o valor do atributo é consultado na tabela de dimensão e adicionado no registro (linhas 7 a 10). Por exemplo, a tupla t1 da Figura 18 foi inserida na tabela de fatos. Então, os valores 'JAPAN' e 'ASIA' serão adicionados ao registro, uma vez que SELECT c_nation FROM Customer WHERE c_custkey = e SELECT c_region FROM Customer WHERE c_custkey = serão executados. Depois de executar esses passos para todas as tabelas de dimensão, o registro conterá {'ASIA', 'AMERICA', 'JAPAN', 'BRAZIL', 1993}. Os valores dos atributos que são medidas na tabela de fato são adicionados ao registro (linha 13). No exemplo, o valor para lo_revenue é adicionado ao registro, resultando em {'ASIA', 'AMERICA', 'JAPAN', 'BRAZIL', 1993, 8190}. Finalmente, a inserção é realizada na tabela de atualizações, usando os valores mapeados do registro (linhas 15 a 18). Por exemplo, INSERT INTO tabela VALUES ( ASIA, AMERICA, JAPAN, BRAZIL, 1993, 8190). Uma importante observação é que o Algoritmo 1 provê suporte apenas a esquemas estrela. Para prover suporte a esquemas floco de neve, a ferramenta BJIn OLAP modifica a linha 8 do Algoritmo 1 para efetuar a junção das tabelas normalizadas, e então buscar o atributo c m. Essas tabelas estarão no conjunto de tabelas de dimensão D. Embora o gatilho adicione novas linhas na tabela de atualizações, existem outras tarefas que o usuário e a ferramenta BJIn OLAP precisam realizar para manter os índices bitmap de junção atualizados. Parâmetro ou variável local F T t i a j D d k M Tabela Record value C NEW Tabela 4. Parâmetros e variáveis locais de Algoritmo 1 Descrição Tabela de fatos do DW Conjunto de linhas para serem inseridas na tabela de fatos F Uma linha de T Um atributo de t i O conjunto de tabelas de dimensão Uma tabela de dimensão de D O conjunto de medidas de F A tabela de atualizações Um registro do tipo tabela Um valor extraído de um atributo Um conjunto de atributos A linha que está sendo inserida em F

50 50 Algoritmo 1 GatilhoAtualizarIndicesBitmapJuncao ( F, T, D, M, tabela) Saída: Uma tabela de atualizações contendo registros para serem adicionados aos índices bitmap de junção. Declarações: registro, a j, t i, d k, valor, C, NEW 01 registro NULL 02 para cada t i em T 03 para cada a j em t i 04 para cada d k em D 05 se a j d k então 06 C tabela.getcolumns() d k.getcolumns() 07 para cada c m em C 08 valor executar(select c m FROM d k WHERE d k.pk = t i.a j ) 09 registro.add(valor) 10 fim-para 11 fim-se 12 fim-para 13 se a j M então registro.add(new.a j ) 14 fim-para 15 se registro NULL então 16 executar(insert INTO tabela VALUES registro.getvalues()) 17 registro NULL 18 fim-se 19 fim-para Fluxos de Dados A Figura 29 mostra o fluxo de dados da operação de atualização de índices bitmap de junção, conforme o caso de uso Manter Índices Bitmap de Junção da Figura 19. Primeiramente, o usuário fornece o nome do índice a ser atualizado (fluxo 1). Só podem ser atualizados os índices cujas tabelas de atualização contiverem registros. Então, são submetidos comandos SQL e de exportação de dados ao SGBD (fluxo 2). O SGBD por sua vez, exporta a tabela de atualização para um conjunto de arquivos CSV que são armazenados no diretório do índice (fluxo 3). Em seguida, a ferramenta BJIn OLAP executa os comandos de ardea e ibis do FastBit (fluxo 4). Eles transformam os dados presentes no conjunto de arquivos CSV em seu para o formato binário do FastBit (fluxo 5) e atualizam os índices bitmap de junção (fluxo 6). Além disso, os registros da tabela de atualização são removidos, mantendo somente a estrutura desta. Por fim, a ferramenta BJIn OLAP atualiza o log com a descrição completa da operação de atualização, e a modifica o documento XML, especificando quando ocorreu a última atualização do índice. Também é registrada a quantidade de tuplas que ainda podem ser adicionadas ao diretório (fluxo 7).

51 51 Figura 29. Fluxo de operações para atualização de índices bitmap de junção Por exemplo, o usuário requer a atualização do índice construído na Figura 21. A Figura 30 exibe os dados requeridos ao usuário para a atualização do índice (fluxo 1). Um índice poderá ser atualizado somente se dados existirem na tabela de atualizações. Opcionalmente, o usuário pode fazer essa checagem antes de executar a operação de atualização. Caso existirem dados a serem atualizados no índice, a ferramenta processará a atualização (fluxo 2 ao 6) e desabilitará o índice para consultas. Ao término da atualização, o log contendo todas as etapas do índice e o documento XML de definição do índice é atualizado (fluxo 7). Por fim, o índice ficará disponível para o processamento de consultas. Figura 30. Tela de atualização de índices bitmap de junção

52 52 Sobre o processo de atualizações de índices bitmap de junção na ferramenta BJIn OLAP, existem as observações que seguem. A atualização consiste incluir novos registros aos índices e na criação de novos vetores de bits se necessário, similarmente a inserção das tuplas t1 e t3 da Figura 18. Inserções na tabela de fatos negadas pelo SGBD por violar restrições referenciais (chaves estrangeiras) não são consideradas pela ferramenta BJIn OLAP para atualizar índices bitmap de junção. A substituição de valores, similar ao comando UPDATE da linguagem SQL, não é suportada. Se os índices bitmap de junção que foram criados sobre uma visão materializada necessitarem a substituição de valores, primeiramente a visão materializada e depois os índices bitmap de junção são reconstruídos. 3.5 Excluindo Índices Bitmap de Junção A Figura 31 exibe o fluxo de dados referente à operação de exclusão de índices bitmap de junção, conforme o caso de uso Manter Índices Bitmap de Junção da Figura 19. Primeiramente, o usuário seleciona o índice a ser excluído (fluxo 1). Depois, é verificado se o índice selecionado tem suporte a atualizações. Apenas se o suporte a atualizações existir, o acesso ao SGBD é necessário, e são submetidos comandos SQL para exclusão da tabela e do gatilho de atualização (fluxo 2). Por fim, o diretório do índice é completamente excluído (fluxo 3). Figura 31. Fluxo de operações para exclusão de índices bitmap de junção Por exemplo, para excluir um índice que teve a opção de atualização ativada, o usuário deverá informar o acesso ao SGBD (fluxo 1), como mostrado na Figura 32. Então, a ferramenta BJIn OLAP questiona o usuário para confirmar a operação de exclusão. Em caso de resposta positiva, o índice e seu documento XML de definição são excluídos permanentemente (fluxos 2 e 3).

53 53 Figura 32. Tela de exclusão de índices bitmap de junção 3.6 Outras Funcionalidades Nesta seção são detalhadas outras funcionalidades relevantes que foram implementados na ferramenta BJIn OLAP. A seção descreve os parâmetros de configuração essenciais para que a ferramenta BJIn OLAP seja executada. Na seção o registro de log de todas as operações geridas pela ferramenta BJIn OLAP é apresentado. Por fim, na seção 3.6.3, o controle de usuários é especificado Parâmetros de Configuração Para executar a ferramenta BJIn OLAP é indispensável redigir previamente, no servidor, o conteúdo do arquivo de propriedades config.properties. Ele contém os parâmetros de configuração da ferramenta BJIn OLAP. Para redigir o seu conteúdo, são utilizados uma chave e um valor, seguindo o padrão da linguagem de programação Java, conforme a Tabela 5. Na Figura 33 é exemplificado o conteúdo de um arquivo config.properties para conexão com o SGBD PostgreSQL, o qual mantém o banco de dados denominado ssb. São incluídos também os caminhos absolutos dos aplicativos ardea e ibis, e o valor default para especificar o diretório onde serão armazenados os índices bitmap de junção. A notação utilizada na Figura 33 se refere ao sistema operacional Linux. Ou seja, os índices serão armazenados em /bjin.

54 54 Tabela 5. Descrição das propriedades de configuração da ferramenta BJIn OLAP Chave Valor ibispath O caminho absoluto onde o aplicativo ibis do FastBit está instalado ardeapath O caminho absoluto da instalação do aplicativo ardea do FastBit (idem) url Os detalhes da conexão JDBC com o SGBD. Sendo o SGBD, porta de acesso e o nome da base de dados a ser acessada. driver O driver a ser utilizado na conexão JDBC O diretório onde será criado o diretório denominado bjin que bjinolappath armazenará os índices bitmap de junção. O usuário que executa o servidor web (e.g Apache Tomcat) deve ter permissões de escrita e leitura sobre tal diretório. driver=org.postgresql.driver url=jdbc:postgresql://localhost:5432/ssb ardeapath=/opt/fastbit-ibis1.2.4/examples/ardea ibispath=/opt/fastbit-ibis1.2.4/examples/ibis bjinolappath=default Figura 33. Exemplo de arquivo de configuração da ferramenta BJIn OLAP Registro de Log A ferramenta BJIn OLAP oferece suporte ao registro de logs em diferentes níveis e diferentes categorias, utilizando a API log4j. A gravação de log favorece a procura por anormalidades ocorridas durante a execução do programa, além de beneficiar a identificação e a depuração de erros. Para a especificação da gravação do log, deve-se redigir um arquivo de configuração log4j.properties localizado no servidor. Ao contrário dos logs mostrados na Figura 20 (fluxo 10) e na Figura 29 (fluxo 7), o registro de log discutido nesta seção registra todas as tarefas que a ferramenta BJIn OLAP processa ao executar as requisições do usuário. Os níveis de log funcionam como segue. No nível DEBUG, são registrados todos os comandos executados pela ferramenta BJIn OLAP, tais como os comandos SQL e os comandos do sistema operacional. No nível INFO, todas as operações realizadas são registradas, isto é, construção, consulta, atualização e exclusão de índices bitmap de junção. No nível WARN, são gravados os tratamentos de exceções. Finalmente, nos níveis ERROR e FATAL são registrados todos os erros ocorridos na execução da ferramenta BJIn OLAP. Por exemplo, ao construir índices bitmap de junção, comandos SQL são emitidos ao SGBD para construir uma tabela temporária. O nível DEBUG registraria esses comandos. Já o nível o

55 55 INFO registraria que a operação de construção se encontra na etapa de criação da tabela temporária. Se fosse lançada uma exceção na operação, ela seria reportada pelo nível ERROR. Além disso, o nível WARN registraria o ROLLBACK realizado no banco de dados. Além dos níveis, os registros de log podem ser realizados em categorias, isto é, bjinolap.build, bjinolap.query e bjinolap. A categoria bjinolap determina o registro de todas as operações descritas nas seções 3.2 a 3.5. Para gravar o log referente à operação de consulta (seção 3.3), configura-se o log4j para a categoria bjinolap.query. De maneira análoga, pode-se gravar o log das operações de construção (seção 3.2) e atualização (seção 3.4) dos índices bitmap de junção, utilizando a categoria bjinolap.build. A operação de exclusão é registrada pela categoria bjinolap, porque não depende do FastBit. Na Figura 34 é mostrado um exemplo de configuração de log. As linhas com o caractere inicial # são comentários. O nível de log para cada categoria foi o DEBUG (linhas 2 a 4). As saídas (appenders) de dados do log mostradas pela categoria bjinolap são stdout e file. Já a categoria bjinolap.build tem como saída somente file, e para a categoria bjinolap.query a saída é stdout. A saída stdout (linhas 6 a 7) consiste no dispositivo de saída padrão da linguagem de programação Java (console). Já para file (linhas 9 a 13) foi determinado o armazenamento do log em arquivo e com cópia de segurança (backup, linha 13) assim que o arquivo especificado (linha 10) ultrapassar o tamanho máximo de 100 KB (linha 11). 01 #categorias e níveis de log 02 log4j.logger.bjinolap=debug, stdout, file 03 log4j.logger.bjinolap.build=debug, file 04 log4j.logger.bjinolap.query=debug, stdout 05 #especificação da saída padrão (console) 06 log4j.appender.stdout=org.apache.log4j.consoleappender 07 log4j.appender.stdout.layout=org.apache.log4j.patternlayout 08 #especificação do log para arquivo 09 log4j.appender.file=org.apache.log4j.rollingfileappender 10 log4j.appender.file.file=/bjin/bjinolap.log 11 log4j.appender.file.maxfilesize=100kb 12 # um arquivo de backup 13 log4j.appender.file.maxbackupindex=1 14 #especificação de herança entre as categorias 15 log4j.additivity.bjinolap.query=false 16 log4j.additivity.bjinolap.build=false Figura 34. Exemplo de arquivo log4j.properties para registro de logs

56 56 Como mencionado, o registro de log utilizando o log4j, fornece uma visão detalhada do processamento da ferramenta BJIn OLAP às requisições do usuário. Ele difere do log mantido quando um índice é construído ou atualizado. Por exemplo, o log nativo gerado pela ferramenta BJIn OLAP após uma operação de construção do índice conforme a Figura 20 é mostrado na Figura 35. Pode-se observar que ele é sucinto, somente informando a etapa e seu tempo total de processamento para a construção do índice. Já na Figura 36 é mostrado o log gerado pelo log4j para a mesma operação de construção, utilizando o arquivo log4j.properties mostrado na Figura 34. Por simplicidade, a Figura 36 mostra apenas até a parte da construção da tabela temporária. Observa-se que este log mantém mais detalhes para todas as etapas realizadas pela ferramenta, tais como comandos gerados e ações que estão sendo executadas internamente. Por exemplo, sabe-se que a tabela de atualizações do índice que está sendo construído será denominada temptable1. Processing the star-join and creating a temporary table. Processed the star-join and created a temporary table in ms Processing the CSV file dump. Processed the CSV file dump in 89 ms Processing the data partition creation. Processed the data partition creation in 1514 ms Processing CREATE INDEX. Processed CREATE INDEX in 283 ms Success in ms Figura 35. Arquivo de log nativo gerado após uma operação de construção de índice

57 :18:14,445 DEBUG [http-bio-8080-exec-11] (CreateIndex.java:256) - For windows: java -classpath ".;D:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpweb apps\bjin-web\web-inf\lib\*" br.bjinolap.application.builderbitmapjoinindex "D:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebap ps\bjin-web\xml\temporarycubes\ xml" "D:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebap ps\bjin-web\config.properties" "my_index" "0" "postgres" "postgres" "D:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebap ps\bjin-web\xml\ssb-q30.xml" "D:\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebap ps\bjin-web\log4j.properties" "CREATE" "1" :18:14,446 INFO [http-bio-8080-exec-11] (CreateIndex.java:283) - creating index "my_index" :18:17,076 DEBUG [main] (BitmapJoinIndex.java:518) - Index: my_index. COMMAND EXISTS TABLE: select count(*) from pg_class where relname ilike 'temptable'; :18:17,089 INFO [main] (BitmapJoinIndex.java:598) - Index: my_index. Temporary table name to update is "temptable1" :18:17,090 DEBUG [main] (BitmapJoinIndex.java:610) - Index: my_index. CREATE TEMPORARY TABLE: CREATE TABLE public.temptable1 as ( SELECT public.lineorder.lo_revenue as col0, public.date.d_year as col1, public.supplier.s_region as col2, public.supplier.s_nation as col3, public.customer.c_region as col4, public.customer.c_nation as col5 FROM public.lineorder, public.date, public.supplier, public.customer WHERE public.lineorder.lo_orderdate = public.date.d_datekey AND public.lineorder.lo_suppkey = public.supplier.s_suppkey AND public.lineorder.lo_custkey = public.customer.c_custkey LIMIT 0);. Figura 36. Exemplo de registro do log4j para a operação de construção de índice Permissões e Privilégios Outra funcionalidade disponível é a de controle de acesso e de privilégios de usuários. Todos os usuários e as suas permissões devem ser definidos num documento XML denominado user.xml. Este arquivo fica no diretório da ferramenta BJIn OLAP definido pela propriedade bjinolappath do arquivo de configuração config.properties (Tabela 5). Se não for criado um arquivo user.xml no diretório específico, não existirá controle de acesso e privilégios de usuários no uso dos índices mantidos pela ferramenta BJIn OLAP.

58 58 Cada usuário possui um login, uma senha e um conjunto de permissões. Na Tabela 6 são descritas todas as permissões que um usuário pode possuir. Um superusuário pode executar todas as funcionalidades da ferramenta BJIn OLAP bem como consultar todos os índices existentes no diretório. As permissões omitidas possuem valor false. Em adição, para permitir a consulta sobre um índice, ele deve ser citado na tag IndexName. Na Figura 37 é mostrado um exemplo de configuração do documento user.xml, sendo definido o usuário anderson e um superusuário. Caso a ferramenta esteja configurada para realizar o controle de usuários, o usuário deverá se autenticar na ferramenta BJIn OLAP para efetuar qualquer operação, tal como construir um índice. Ao tentar executar uma operação, o controle de usuário averigua se o usuário corrente possui permissões para efetuá-la, de acordo com o documento user.xml. Quando um novo índice é construído (seção 3.2), o documento user.xml é atualizado, adicionando o nome do novo índice ao seu respectivo usuário na tag IndexName. A exclusão de um índice (seção 3.5) elimina-o da tag IndexName. O processamento de consultas sobre um índice somente é permitida se este índice estiver listado na tag IndexName. Na atualização de índices, o documento user.xml não é modificado. Na Figura 37, vê-se que o usuário anderson tem permissão para criação de índices bitmap de junção, bem como construiu os índices ssb_1 e ssb_2. Tal usuário também detém permissão de consulta sobre estes índices. Se ele excluir o índice ssb_1, a tag correspondente será removida. Tabela 6. Permissões para controle de usuários Permissão Descrição True para permitir o carregamento de documentos XML descrevendo o canuploadxml cubo de dados, e false para revogar. True para permitir a criação de índices bitmap de junção e false para cancreateindex revogar. True para dar permissão de atualização de índices bitmap de junção nos canupdateindex índices listados na tag indices e false para revogar. True para dar permissão de remoção de índices bitmap de junção nos candeleteindex índices listados na tag indices e false para revogar. superuser True para declarar como um superusuário e false para revogar.

59 Figura 37. Exemplo de documento user.xml para controle de usuários 59

60 60 4 Testes de Desempenho Experimentais Neste capítulo é apresentada a validação da ferramenta BJIn OLAP por meio de testes de desempenho experimentais. Os resultados revelaram o notável desempenho da ferramenta BJIn OLAP para processar consultas em DW, considerando as operações OLAP slice-anddice, drill-down e roll-up. Os testes foram realizados comparando a ferramenta BJIn OLAP com as tecnologias existentes do SGBD e com o Mondrian. Como a operação OLAP pivoting é realizada no lado do cliente, esta não foi incluída nos testes. Este capítulo está organizado como segue. A seção 4.1 detalha as configurações utilizadas nos testes de desempenho. Na seção 4.2, avalia-se o desempenho do processamento da operação slice-and-dice, comparando a ferramenta BJIn OLAP com o servidor OLAP Mondrian, e com visões fragmentadas verticalmente mantidas pelo SGBD. Também são feitas considerações sobre o armazenamento e a cardinalidade de atributos. As operações drill-down e roll-up são enfocadas na seção 4.3. Na seção 4.4, a ferramenta BJIn OLAP é comparada com o Mondrian usando um DW contendo dados reais. Na seção 4.5 são descritos os resultados obtidos nos testes de desempenho usando um DW mais volumoso, considerando visões materializadas e índices bitmap de junção construídos sobre essas visões. 4.1 Configurações dos Testes Na construção das bases de dados foi utilizado o Star Schema Benchmark (SSB) [20] para criar dois esquemas estrela idênticos ao da Figura 2. A base de dados denominada DW1 foi carregada usando o fator de escala 1 do SSB, produzindo 6 milhões de tuplas na tabela de fatos. A base de dados DW10 foi carregada com o fator de escala 10 e, portanto, foi 10 vezes mais volumosa que DW1. Ambas as bases de dados continham hierarquias de atributos. Por exemplo, s_region s_nation s_city s_address e p_mfgr p_category p_brand1, as quais permitem testes de desempenho para as operações drill-down e roll-up. As consultas do SSB foram utilizadas nos testes. Elas estão organizadas em quatro grupos de consulta com complexidade crescente: Q1, Q2, Q3 e Q4. Cada grupo de consulta determina um número especifico de junções e filtros, bem como agrupamentos e ordenações. A Figura 38 mostra o modelo de cada grupo de consultas. Na Tabela 7 são descritas as operações que cada grupo processa para executar suas consultas. Todas as consultas têm filtros na cláusula WHERE, habilitando a operação OLAP slice-and-dice.

61 61 Q1 SELECT SUM(lo_extendedprice*lo_discount) AS revenue FROM Lineorder, Date WHERE lo_orderdate = d_datekey AND d_year = [YEAR] AND lo_discount BETWEEN [DISCOUNT] - 1 AND [DISCOUNT] + 1 AND lo_quantity < [QUANTITY]; Q3 SELECT c_nation, s_nation, d_year, SUM(lo_revenue) AS revenue FROM Customer, Lineorder, Supplier, Date WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND c_region = 'ASIA' AND s_region = 'ASIA' AND d_year >= 1992 AND d_year <= 1997 GROUP BY c_nation, s_nation, d_year ORDER BY d_year asc, revenue DESC; Q2 SELECT SUM(lo_revenue), d_year, p_brand1 FROM Lineorder, Date, Part, Supplier WHERE lo_orderdate = d_datekey AND lo_partkey = p_partkey AND lo_suppkey = s_suppkey AND p_category = 'MFGR#12' AND s_region = 'AMERICA' GROUP BY d_year, p_brand1 ORDER BY d_year, p_brand1; Q4 SELECT d_year, c_nation, SUM(lo_revenue - lo_supplycost) AS profit FROM Date, Customer, Supplier, Part, Lineorder WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_partkey = p_partkey AND lo_orderdate = d_datekey AND c_region = 'AMERICA' AND s_region = 'AMERICA' AND (p_mfgr = 'MFGR#1' OR p_mfgr = 'MFGR#2') GROUP BY d_year, c_nation ORDER BY d_year, c_nation; Figura 38. Modelos das consultas do SSB [20] Tabela 7. Características dos grupos de consultas da Figura 36 Grupo Junções Filtros GROUP BY? ORDER BY? Atributos para serem indexados Q1 1 3 Não Não 4 Q2 3 2 Sim Sim 5 Q3 3 3 Sim Sim 7 Q4 4 3 Sim Sim 7 As operações drill-down e roll-up estão presentes nas consultas Q3.1, Q3.2, Q3.3 e Q3.4 do grupo Q3, e nas consultas Q4.1, Q4.2, Q4.3 do grupo Q4 do SSB. Executá-las progressivamente determina a operação drill-down, enquanto a execução inversa consiste na operação roll-up. As consultas do grupo Q3 para realizar operações roll-up e drill-down são mostradas na Figura 39, enquanto na Figura 40 são mostradas as consultas do grupo Q4. Em ambas as figuras, os atributos usados para roll-up e drill-down são destacados em negrito. Outras bases de dados foram criadas como visões fragmentadas verticalmente e visões materializadas, conforme a seção 2.3. Em relação à cardinalidade dos atributos, todas as consultas envolvem ao menos um atributo com cardinalidade alta. Por exemplo, o atributo lo_revenue tem uma cardinalidade de na base de dados DW1, e a cardinalidade na base de dados DW10.

62 62 Q3.1 SELECT c_nation, s_nation, d_year, sum(lo_revenue) AS revenue FROM customer, lineorder, supplier, date WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND c_region = 'EUROPE' AND s_region = 'EUROPE' AND d_year >= 1992 AND d_year <= 1997 GROUP BY c_nation, s_nation, d_year ORDER BY d_year ASC, revenue DESC; Q3.3 SELECT c_city, s_city, d_year, sum(lo_revenue) AS revenue FROM customer, lineorder, supplier, date WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND (c_city = 'UNITED KI1' OR c_city = ' UNITED KI5') AND (s_city = ' UNITED KI1' OR s_city = ' UNITED KI5') AND d_year >= 1992 and d_year <= 1997 GROUP BY c_city, s_city, d_year ORDER BY d_year ASC, revenue DESC; Q3.2 SELECT c_city, s_city, d_year, sum(lo_revenue) AS revenue FROM customer, lineorder, supplier, date WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND c_nation = 'UNITED KINGDOM' AND s_nation = ' UNITED KINGDOM ' AND d_year >= 1992 AND d_year <= 1997 GROUP BY c_city, s_city, d_year ORDER BY d_year ASC, revenue DESC; Q3.4 SELECT c_city, s_city, d_year, sum(lo_revenue) AS revenue FROM customer, lineorder, supplier, date WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND (c_city = ' UNITED KI1' OR c_city = ' UNITED KI5') AND (s_city = ' UNITED KI1' OR s_city = ' UNITED KI5') AND d_yearmonth = 'Dec1997' GROUP BY c_city, s_city, d_year ORDER BY d_year asc, revenue DESC; Figura 39. Consultas do grupo Q3 adaptadas de [20] para operações drill-down e roll-up Q4.1 SELECT d_year, c_nation, sum(lo_revenue lo_supplycost) AS profit FROM customer, lineorder, supplier, date, part WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND lo_partkey = p_partkey AND c_region = 'AMERICA' AND s_region = 'AMERICA' AND (p_mfgr = 'MFGR#1' OR p_mfgr = 'MFGR#2') GROUP BY d_year, c_nation ORDER BY d_year ASC, c_nation ASC; Q4.2 SELECT d_year, s_nation, p_category, sum(lo_revenue lo_supplycost) AS profit FROM customer, lineorder, supplier, date, part WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND lo_partkey = p_partkey AND c_region = 'AMERICA' AND s_region = 'AMERICA' AND (d_year = 1997 OR d_year = 1998) AND (p_mfgr = 'MFGR#1' OR p_mfgr = 'MFGR#2') GROUP BY d_year, s_nation, p_category ORDER BY d_year ASC, s_nation ASC; Q4.3 SELECT d_year, s_nation, p_category, sum(lo_revenue lo_supplycost) AS profit FROM customer, lineorder, supplier, date, part WHERE lo_custkey = c_custkey AND lo_suppkey = s_suppkey AND lo_orderdate = d_datekey AND lo_partkey = p_partkey AND c_nation = 'UNITED STATES' AND s_nation = 'UNITED STATES' AND (d_year = 1997 OR d_year = 1998) AND p_category = 'MFGR#14' GROUP BY d_year, s_nation, p_category ORDER BY d_year ASC, s_nation ASC; Figura 40. Consultas do grupo Q4 para operações drill-down e roll-up [20]

63 63 Além de utilizar as bases de dados e consultas do SSB, foram realizados testes sobre um DW contendo dados reais. Essa base de dados, denominada webpide, é um esquema estrela para armazenar dados educacionais do governo brasileiro [41]. A base de dados webpide tem 8 tabelas de dimensão e fatos, e seu esquema estrela é mostrado na Figura 41. Foram avaliadas duas consultas sobre o DW webpide, mostradas na Figura 42. Esse teste foi realizado visando comprovar que a ferramenta BJIn OLAP está preparada para ser executada em aplicações reais, bem como para DW menos volumosos. Figura 41. Esquema estrela do DW webpide [41] Web-PIDE Q1 SELECT a.ano_aplicacao, avg(proficiencia), c.cor, s.sexo, pc.agua_encanada FROM dependencia_administrativa AS ad, ano_aplicacao AS a, fatos as f, disciplina AS d, sexo AS s, cor AS c, perfil_socioeconomico AS pc, localizacao AS l WHERE ad.depadm_pk = f.dep_adm AND a.ano_aplicacao = f.ano_aplicacao AND d.disciplina_pk = f.disciplina AND f.sexo = s.sexo AND c.cor_pk = f.cor AND f.perfil_socioec = pc.perfil_socioeconomico AND f.localizacao = l.localizacao_pk AND (a.ano_aplicacao = 2001 OR a.ano_aplicacao = 2003) AND l.regiao = 'Sudeste' AND ad.classe = 'Estadual' AND d.disciplina = 'Matemática' AND serie = 4 GROUP BY a.ano_aplicacao, l.regiao, s.sexo, c.cor, pc.agua_encanada ORDER BY a.ano_aplicacao ASC, c.cor ASC Web-PIDE Q2 SELECT classe, a.ano_aplicacao, avg(proficiencia) FROM dependencia_administrativa AS ad, ano_aplicacao AS a, fatos AS f, disciplina AS d WHERE ad.depadm_pk = f.dep_adm AND a.ano_aplicacao = f.ano_aplicacao AND d.disciplina_pk = f.disciplina AND (classe = 'Particular' OR classe = 'Federal' OR classe = 'Estadual') AND (a.ano_aplicacao = 1997 OR a.ano_aplicacao = 2001 OR a.ano_aplicacao = 2003) AND d.disciplina = 'Matemática' AND serie = 3 GROUP BY classe, a.ano_aplicacao ORDER BY a.ano_aplicacao ASC Figura 42. Consultas sobre a base de dados webpide [41]

64 64 A plataforma de software e hardware usada foi assim descrita: Plataforma P1: um computador com um processador AMD Athlon II X2 B22 com frequência de 2800/2000 Mhz, disco rígido SATA de 320 GB com 7200 RPM, e 2 GB de memória principal. O sistema operacional foi Fedora 14 com a versão do Kernel fc14.x86_64, e foi instalado os seguintes softwares: FastBit 1.2.3, PostgreSQL 9.0.4, JDK , Apache Tomcat ; e Duas plataformas distintas foram utilizadas devido ao custo das operações envolvidas. Ambas as plataformas P1 tiveram OAT 2.8, Mondrian Schema Workbench e o servidor OLAP Mondrian instalados. Todos os índices bitmap de junção foram construídos com o algoritmo de compressão WAH [14], com codificação e sem binning. Esses recursos são padrões implementados pelo FastBit para aperfeiçoar os índices bitmap construídos sobre atributos com alta cardinalidade. 4.2 Comparando a Ferramenta BJIn OLAP com Visões Fragmentadas Verticalmente Esse experimento foi conduzido na plataforma P1 e pelas seguintes configurações: JE usou a técnica da junção estrela para o processamento no SGBD sobre a base de dados DW1; VFV usou visões fragmentadas verticalmente (construídas para cada consulta) para o processamento no SGBD sobre a base de dados DW1; BJIn OLAP eliminou junções acessando índices bitmap de junção que foram previamente construídos sobre a base de dados DW1; e Mondrian acessou a base de dados DW1 usando MDX. A configuração VFV demandou a construção de uma visão fragmentada verticalmente para cada consulta do SSB, tal como aquela mostrada na Figura 12a que serve para fornecer a resposta da consulta da Figura 12b. Os testes foram realizados localmente para inibir a latência da rede. Todas as consultas do SSB foram executadas e o cache foi limpo depois da execução de cada consulta. Cada consulta foi executada cinco vezes, e posteriormente foi calculada a média do tempo de execução. Os resultados são exibidos na Figura 43. Claramente, o desempenho da ferramenta BJIn OLAP superou as outras configurações, o que indica que os índices bitmap de junção é uma boa opção para processar consultas em DWs. Por outro lado, a configuração Mondrian foi a que apresentou piores resultados no desempenho do processamento das consultas. Na verdade, o servidor OLAP Mondrian acessa o esquema estrela mantido pelo SGBD para executar consultas, mapeando consultas MDX para SQL. Então, como Mondrian acessou a base de dados DW1 e realizou a

65 65 junção estrela tal como a configuração JE, os seus resultados são similares. Além disso, o aumento de tempo que diferenciou as configurações Mondrian e JE, é dado pelo tempo que o Mondrian despende para apresentar os resultados das consultas para o usuário, como as tabelas cruzadas. Ambas as configurações JE e Mondrian apresentaram tempos de respostas das consultas proibitivos. Embora a configuração VFV tenha apresentado uma redução de tempo em relação à JE, a ferramenta BJIn OLAP foi mais eficiente que a VFV de 6,8% (Q4.2) a 48,5% (Q3.4). A redução de tempo é a porcentagem que determina o quanto mais eficiente uma configuração foi sobre a outra configuração. Além disso, a ferramenta BJIn OLAP considera também o tempo de construção das páginas JSP com a tabela cruzada contendo os resultados. Já a configuração VFV não realiza tais tarefas. Ainda na Figura 43, o tempo mínimo e o tempo máximo de redução sobre as técnicas que o Mondrian utiliza são destacados. Todas as consultas executadas possuíam restrições na cláusula WHERE. Assim os resultados indicaram que índices bitmap de junção melhoraram o desempenho para processar a operação slice-anddice. Figura 43. Tempo decorrido por cada configuração para processar as consultas do SSB sobre a base de dados DW1 A cardinalidade dos atributos é uma questão muito importante para ser considerada no uso de índices bitmap, porque determina a quantidade de vetores de bits a serem criados para

66 66 cada atributo. A Figura 44 mostra a soma das cardinalidades de todos os atributos indexados. Somente os índices do grupo Q1 possuem menos que 3 milhões de vetores de bits. Verificouse que ao menos 99% dos vetores de bits foram acessados por cada consulta. Isso demonstra que a ferramenta BJIn OLAP processa eficientemente consultas sobre atributos com alta cardinalidade, mesmo acessando um número alto de vetores de bits, utilizando o FastBit. Figura 44. Quantidade de vetores de bits disponíveis para cada consulta do SSB sobre DW1 A construção dos índices bitmap de junção demorou segundos, enquanto construir as visões fragmentadas verticalmente usando o SGBD tomou 310 segundos. O requisito de espaço de armazenamento para as visões fragmentadas verticalmente e índices bitmap de junção são mostrados na Figura 45. Quanto mais vetores de bits foram criados (Figura 44), mais espaço de armazenamento foi necessário (Figura 45). Como resultado, visões fragmentadas verticalmente e índices bitmap de junção construídos para o grupo Q1 requereram menos espaço que para os demais grupos. Além disso, para o grupo Q1, os índices ocuparam menos espaço de armazenamento que as visões. Por outro lado, considerando os grupos Q2, Q3 e Q4, os índices requereram mais espaço que as visões. O espaço de armazenamento requerido variou de acordo com a consulta, como mostrado na Figura 45. Ressalta-se que existem atributos indexados de tipos de dados distintos e com diferentes tamanhos em bytes. Por fim, o DW1 ocupou ao todo 884 MB, as visões fragmentadas verticalmente ocuparam uma soma de MB, e os índices bitmap de junção ocuparam uma soma de MB de espaço de armazenamento. Comparado às visões, os índices requereram 8,8%

67 67 mais espaço em disco. Apesar do custo de armazenamento dos índices, existiu um ganho razoável de desempenho para processar as consultas. Figura 45. Espaço requerido para armazenamento de índices bitmap de junção e VFV 4.3 Operações Drill-down e Roll-up Neste teste de desempenho foram avaliadas as operações drill-down e roll-up usando a plataforma P1 para processar as consultas do grupo Q3 e Q4 (Figuras Figura 39 e Figura 40) considerando as seguintes configurações: BJIn OLAP eliminou as junções acessando intrinsecamente índices bitmap de junção construídos sobre o DW1; e Mondrian para acessar DW1 usando MDX; Para o grupo Q3 foram indexados os atributos d_year, d_yearmonth, s_region, s_nation, s_city, c_region, c_nation, c_city e lo_revenue. Já para o grupo Q4 foram indexados os atributos d_year, c_nation, c_region, s_region, p_mfgr, p_category, s_city, p_brand1, s_nation, lo_revenue e lo_supplycost. O teste foi executado localmente para inibir a latência de rede. Foram executadas as consultas de cada grupo consecutivamente, sem a limpeza do cache entre cada consulta. Essa estratégia utiliza o cache para reaproveitar resultados de consultas anteriores e assim processar as consultas mais rapidamente. Ao contrário da seção anterior, que foram executadas consultas não consecutivamente. A operação drill-down sobre o grupo Q3 teve como ordem de execução as consultas Q3.1, Q3.2, Q3.3 e Q3.4, e a operação roll-up utilizou a ordem inversa. A operação drill-down sobre o grupo Q4 teve como ordem as consultas Q4.1, Q4.2 e Q4.3, e a ordem inversa para a operação roll-up. Ambas as operações foram executadas cinco vezes, coletando-se o tempo decorrido de cada consulta específica, e

68 68 posteriormente calculado a média em segundos. Além disso, foi calculado o tempo total de cada operação OLAP e a redução de tempo que a ferramenta BJIn OLAP impôs sobre o Mondrian. Os resultados são mostrados nas Tabelas 8 e 9. Eles revelaram que o cache auxiliou no processamento da sequência de consultas em ambos os grupos, para as operações drill-down e roll-up. Deve-se ressaltar que os resultados demonstraram que a ferramenta BJIn OLAP se sobressaiu em comparação à configuração do Mondrian para executar a primeira consulta de ambas as operações drill-down e roll-up. Além disso, o Mondrian consumiu maior tempo para processar a primeira consulta do que a soma de todas as consultas realizadas pela ferramenta BJIn OLAP. Por exemplo, para processar a operação drill-down do grupo Q3 (executando Q3.1, Q3.2, Q3.3 e Q3.4 nessa ordem), a ferramenta BJIn OLAP gastou a soma de 9,2894 segundos. Já o Mondrian consumiu 14,4118 segundos apenas para processar a primeira consulta da operação (Q3.1). Esse experimento mostrou que a ferramenta BJIn OLAP reduziu drasticamente o tempo de resposta das consultas para processar as operações drill-down e roll-up. A ferramenta BJIn OLAP forneceu uma redução de tempo de ao menos 64,86% sobre o Mondrian. Portanto, isso demonstra a viabilidade do uso de índices bitmap de junção em ferramentas OLAP para o processamento eficiente de operações drill-down e roll-up. Tabela 8. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1 utilizando o grupo Q3 do SSB Drill-down (segundos) Roll-up (segundos) Grupo Consulta Mondrian BJIn OLAP Mondrian BJIn OLAP Q3.1 14,4118 5,1134 3,4350 3,0586 Q3.2 38,6804 3, ,9222 1,2140 Q3 Q3.3 0,2420 0,4360 4,1530 2,6374 Q3.4 2,4238 0, ,6500 3,7018 Soma Q3 55,758 9, , ,6118 Redução (%) 83,34% 83,20% Tabela 9. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1 utilizando o grupo Q4 do SSB Drill-down (segundos) Roll-up (segundos) Grupo Consulta Mondrian BJIn OLAP Mondrian BJIn OLAP Q4.1 17,8840 4,9434 3,9330 1,6458 Q4.2 6,4412 3,1622 8,6654 5,4604 Q4 Q4.3 14,7292 3, ,7316 5,6588 Soma Q4 39, , , ,7650 Redução (%) 71,20% 64,86%

69 Consultando a Base de Dados Real webpide Este teste de desempenho teve como objetivo avaliar a ferramenta BJIn OLAP considerando as consultas da base de dados real webpide (Figura 42), usando a plataforma P1 usando as seguintes configurações: BJIn OLAP eliminou as junções acessando intrinsecamente índices bitmap de junção construídos sobre a base de dados webpide; e Mondrian para acessar a base de dados webpide usando MDX; Os testes foram realizados localmente para inibir a latência de rede. Todas as consultas da Figura 42 foram emitidas e o cache foi limpado depois da execução de cada consulta. Cada consulta foi executada cinco vezes, e posteriormente calculou-se o tempo médio em segundos. Os resultados são mostrados na Figura 46. Claramente foi evidenciado o benefício de utilizar a ferramenta BJIn OLAP para processar consultas sobre uma base de dados real contendo um volume menor de dados. As reduções de tempo sobre o Mondrian são de 73,05% para a consulta Q1 e 79,21% para Q2. A consulta Q1 mostrou ser ligeiramente mais custosa que a Q2 em ambas as configurações da ferramenta BJIn OLAP (aproximadamente 0,4 segundos) e Mondrian (aproximadamente 0,2 segundos). Esses resultados comprovam que a ferramenta BJIn OLAP tem a viabilidade de processar consultas eficientemente em aplicações reais, oferecendo ao usuário final um tempo de resposta às consultas mais baixo que o Mondrian. Figura 46. Resultados das consultas sobre a base de dados webpide 4.5 Investigação Sobre o Aumento do Volume de Dados e o Uso de Visões Materializadas Nesta seção é avaliado o desempenho do processamento das as consultas do SSB executadas sobre uma base de dados mais volumosa: DW10. São utilizadas as técnicas de

70 70 junção estrela, visões fragmentadas verticalmente, índices bitmap de junção, visões materializadas, e índices bitmap de junção construídos sobre essas visões. Na seção os testes de desempenho consideram todas as consultas do SSB. Já na seção enfoca-se o desempenho no processamento das operações drill-down e roll-up As Consultas do SSB Este teste de desempenho objetivou avaliar a escalabilidade da ferramenta BJIn OLAP em relação ao aumento do volume de dados. Ao longo dessa seção, foram executados diversos testes de desempenho utilizando a plataforma P1. Primeiramente, as seguintes configurações foram consideradas: JE usou o SGBD para processar a junção estrela na base de dados DW10; VFV usou o SGBD para eliminar junções acessando visões fragmentadas verticalmente específicas que foram previamente construídas sobre a base de dados DW10; BJIn OLAP eliminou junções acessando índices bitmap de junção que foram previamente construídos sobre a base de dados; e Mondrian para acessar a base de dados usando MDX. Os testes foram executados localmente para inibir a latência de rede. Cada consulta foi executada cinco vezes, e posteriormente calculou-se o tempo médio de execução em segundos. Limpou-se o cache entre cada execução. Os resultados são mostrados na Figura 47, e a eficiência de execução de consultas sobre dados mais volumosos utilizando a ferramenta BJIn OLAP foi expressiva. Claramente, a configuração do Mondrian foi menos eficiente que as demais. Além disso, a configuração JE obteve resultados tão proibitivos quanto o Mondrian. Novamente, isso se deve ao fato do Mondrian usar o SGBD para processar a junção estela. Em contrapartida, as visões fragmentadas verticalmente melhoraram o desempenho das consultas. Porém, o uso de índices bitmap de junção conferiu melhor desempenho. A ferramenta BJIn OLAP apresentou reduções de tempo variando de 24% (Q3.1) a 66% (Q1.1) se comparado as visões fragmentadas verticalmente. A redução de tempo proporcionada pela ferramenta BJIn OLAP se tornou mais evidente se comparada ao Mondrian, variando de 49% (Q3.2) a 85% (Q2.1). Isto confirma a escalabilidade da ferramenta BJIn OLAP para processar consultas em DW volumosos.

71 71 Figura 47. Tempo decorrido na execução das consultas do SSB na base de dados DW10 Posteriormente, foi realizado o teste de desempenho para investigar o uso de visões materializadas e de índices bitmap de junção sobre estas visões. Além disso, este teste avaliou os mecanismos de busca usados por ambas as ferramentas OLAP. Enquanto o mecanismo de consulta usado pelo Mondrian é o SGBD, o mecanismo de consulta da ferramenta BJIn OLAP é o FastBit. As seguintes configurações foram consideradas utilizando a plataforma P1: SGBD+VM usou visões materializadas construídas para processar cada consulta do SSB (similares à visão da Figura 13a); Mondrian+VM eliminou junções acessando as referidas visões materializadas, usando MDX e o recurso de AggregateTable; FastBit+VM para acessar os índices bitmap de junção construídos sobre as referidas visões materializadas; e BJIn OLAP+VM eliminou junções acessando índices bitmap de junção que foram previamente construídos sobre as referidas visões materializadas da base de dados (similarmente a Figura 16b); Os testes foram executados localmente para inibir a latência de rede. Cada consulta foi executada cinco vezes, e calculou-se o tempo médio de execução em segundos. Limpou-se o cache entre cada execução de consulta. Apesar da base de dados DW10 ter um grande volume

72 72 de dados, as visões materializadas reduziram drasticamente a quantidade de linhas a serem consultadas. Os resultados do teste realizado são mostrados na Figura 48. A ferramenta BJIn OLAP apresentou melhores resultados que o Mondrian em todas as consultas. Considerando os mecanismos de busca, o FastBit foi similar ao SGBD na maioria das consultas, com exceção do grupo Q1. Isso ocorreu devido ao menor volume de dados, isto é, as visões materializadas continham menos que 100 linhas para cada consulta do grupo. A redução de tempo imposta pela ferramenta BJIn OLAP em relação ao Mondrian variou de 94,32% (Q1.1) a 98,84% (Q4.2). Este teste mostrou que a ferramenta BJIn OLAP pode ser utilizada para construir índices bitmap de junção sobre visões materializadas, e assim prover um bom desempenho no processamento de consultas. Figura 48. Tempo decorrido para processar as consultas do SSB sobre a base de dados DW10 usando visões materializadas Outro importante resultado é a diferença de tempo entre os mecanismos de consulta e as ferramentas OLAP, comparadas na Figura 49, considerando o teste relatado pela Figura 48. O SGBD executa rapidamente as consultas, porém o Mondrian adiciona uma grande fração de tempo ao acessar o DW para validações no cubo de dados, transformar a consulta MDX para SQL e processar os resultados. O Mondrian adicionou de 5 a 59 segundos ao tempo total do SGBD, enquanto a ferramenta BJIn OLAP adicionou menos que 1 segundo ao tempo total do FastBit. Conclui-se

73 73 que a ferramenta BJIn OLAP não introduz um atraso significante ao tempo de processamento de consultas gasto pelo FastBit. Figura 49. Tempo adicionado pelas ferramentas OLAP em relação ao seu mecanismo de consulta Em relação aos requisitos de armazenamento, a base de dados DW10 ocupou MB. A Figura 50 mostra o espaço total requerido dos índices bitmap de junção, visões fragmentadas verticalmente (VFV), índices bitmap de junção sobre visões materializadas e das visões materializadas (VM). Os índices bitmap de junção ocuparam uma soma de MB e as visões fragmentadas verticalmente requereram MB. Para as visões materializadas mantidas pelo SGBD, o espaço requerido foi de MB e para os índices construídos sobre as visões materializadas foram necessários MB. As visões fragmentadas verticalmente levaram segundos para sua construção, enquanto as visões materializadas levaram segundos para serem construídas. Os índices bitmap de junção demoraram segundos para serem construídos, enquanto os índices construídos sobre as visões materializadas necessitaram de 994 segundos. As visões fragmentadas verticalmente ocuparam um espaço total similar ao espaço de armazenamento requerido pelos índices bitmap de junção. Em contrapartida, os índices construídos sobre visões materializadas requereram ligeiramente menos espaço de armazenamento que as visões materializadas mantidas pelo SGBD. Na realidade, índices são pequenos devido ao pequeno número de tuplas, reduzido por conta da agregação dos dados

74 74 nas visões. Portanto, os índices bitmap de junção construídos sobre visões materializadas beneficiaram tanto o armazenamento, quanto o processamento de consultas pela ferramenta BJIn OLAP. Figura 50. Espaço requerido total considerando a base de dados DW Operações Drill-down e Roll-up Como constatado na seção 4.5.1, o processamento de consultas usando visões materializadas é mais eficiente que usando visões fragmentadas verticalmente, para a base de dados DW10. Com isso, nesta seção é realizado o teste de desempenho que visa avaliar as operações OLAP drill-down e roll-up, usando a plataforma P1, para processar as consultas do grupo Q3 e Q4 (Figuras Figura 39 e Figura 40) usando visões materializadas. Consideraramse as seguintes configurações: Mondrian + VM acessou visões materializadas construídas sobre a base de dados usando MDX e o recurso de AggregateTable; e BJIn OLAP acessou intrinsecamente índices bitmap de junção construídos sobre as referidas visões materializadas. Para o grupo Q3 foram criadas visões materializadas considerando os atributos d_year, d_yearmonth, s_region, s_nation, s_city, c_region, c_nation, c_city e lo_revenue. Já para o grupo Q4 foram considerados os atributos d_year, c_nation, c_region, s_region, p_mfgr, p_category, s_city, p_brand1, s_nation, lo_revenue e lo_supplycost. Os índices bitmap de junção foram construídos sobre essas visões. O teste foi executado localmente para inibir a latência de rede. Foram executadas as consultas de cada grupo consecutivamente, sem a limpeza do cache entre cada consulta. Essa

75 75 estratégia utiliza o cache para reaproveitar resultados de consultas anteriores e assim processar as consultas mais rapidamente. Ambas as operações foram executadas cinco vezes, coletando-se o tempo decorrido de cada consulta específica, e posteriormente calculado a média em segundos. Além disso, foi calculado o tempo total de cada operação OLAP e a redução de tempo que a ferramenta BJIn OLAP impôs sobre o Mondrian. Os resultados são mostrados nas Tabelas Tabela 10 e Tabela 11. O cache auxiliou o processamento das consultas. Novamente, a ferramenta BJIn OLAP exigiu menos tempo para processar a primeira consulta do que a operação OLAP completa realizada pelo Mondrian. Porém, desta vez foram acessadas visões materializadas indexadas. Essa diferença é grande para o grupo Q4, devido às validações que o Mondrian faz no esquema do DW e à complexidade das consultas. Essas validações checaram se a visão materializada compõe exatamente os dados que estão sendo requisitados na consulta MDX, como discutido na seção A ferramenta BJIn OLAP claramente mostrou um desempenho melhor que a configuração do Mondrian, com a redução de tempo variando de 83,36% (operação roll-up em Q3) a 93,20% (operação roll-up em Q4). Este experimento mostrou que a ferramenta BJIn OLAP executa eficientemente as operações drill-down e roll-up acessando índices bitmap de junção construídos sobre visões materializadas. Além disso, seu desempenho é superior ao desempenho do Mondrian acessando visões materializadas para processar tais operações. Tabela 10. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10 usando o grupo Q3 do SSB Drill-down (segundos) Roll-up (segundos) Grupo Consulta Mondrian+VM BJIn OLAP Mondrian+VM BJIn OLAP Q3.1 19,9432 4,6154 5,7080 3,5462 Q3.2 6,5180 0,7516 2,0688 0,5218 Q3 Q3.3 14,9670 0,2694 2,1906 0,9744 Q3.4 1,8420 0, ,2721 1,9338 Soma 43,2702 5, ,2386 6,9762 Redução 86,28% 83,86% Tabela 11. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10 usando o grupo Q4 do SSB Drill-down (segundos) Roll-up (segundos) Grupo Consulta Mondrian+VM BJIn OLAP Mondrian+VM BJIn OLAP Q ,2348 7, ,0644 5,7180 Q4.2 57,6974 5, ,8728 5,4370 Q4 Q4.3 58,7136 3, ,9106 4,0550 Soma 224, , , ,2100 Redução 92,49% 93,20%

76 76 5 Uma Avaliação Experimental Estendida Neste capítulo é apresentada uma avaliação estendida da ferramenta BJIn OLAP. Na seção 5.1, é discutido o desempenho para apresentar os componentes de visualização de resultados das consulta no lado do cliente. A seção 5.2 compara o uso de memória principal no processamento de consultas. A seção 5.3 avalia o desempenho de consultas com enfoque à portabilidade entre os sistemas operacionais Linux e Windows. A seção 5.4 aborda a operação de atualização índices bitmap de junção. Foram consideradas as mesmas bases de dados DW1 e DW10 descritas na seção 4.1. A plataforma de software e hardware usada foi assim descrita: Plataforma P2: um computador com o processador Intel Core i5 com frequência de 2,66 Ghz, 640 GB de disco rígido SATA com 7200 RPM, e 4 GB de memória principal. O sistema operacional foi Ubuntu com Kernel x86_64 e com os seguintes softwares: FastBit 1.2.4, PostgreSQL 9.0, JDK 1.6.0_24 e Apache Tomcat Apresentando os Resultados das Consultas ao Usuário Esse teste de desempenho avaliou o tempo que cada ferramenta OLAP demandou para apresentar os resultados para o usuário. Ao contrário dos outros testes realizados, este experimento foi realizado no lado cliente. Foi medido o tempo total que o Mondrian e a ferramenta BJIn OLAP gastaram para carregar e exibir a página JSP, a partir do primeiro byte recebido pelo navegador. Esta avaliação foi realizada considerando as consultas do grupo Q3 (Figura 39) por ser o grupo que contém mais consultas e por possibilitar operações OLAP drill-down e roll-up. A Tabela 12 mostra a quantidade de colunas e de linhas dos resultados de cada consulta do grupo Q3, Essas linhas e colunas compuseram a tabela cruzada apresentada para o usuário, considerando as bases de dados DW1 e DW10. Para medir o tempo total do carregamento da página foi utilizado o navegador Mozilla Firefox e o utilitário FireBug Tabela 12. Linhas e colunas que compuseram as tabelas cruzadas Número de Linhas Consulta Colunas DW1 DW10 Q3.1 c_nation, s_nation, d_year, sum(lo_revenue) Q3.2 c_city, s_city, d_year, sum(lo_revenue) Q3.3 c_city, s_city, d_year, sum(lo_revenue) Q3.4 c_city, s_city, d_year, sum(lo_revenue) 3 4 No primeiro teste, cada consulta do grupo Q3 foi executada cinco vezes, coletando-se o tempo total de carregamento dos resultados na página, e calculando-se a média em

77 77 segundos. Limpou-se o cache entre cada execução. As seguintes configurações foram consideradas: Mondrian+JE acessou a base de dados DW1 usando MDX; e BJIn OLAP eliminou junções acessando índices bitmap de junção; Os resultados mostrados na Figura 51a revelaram que a ferramenta BJIn OLAP foi três vezes mais eficiente que o Mondrian para apresentar os resultados no lado do cliente, considerando Q3.1 e Q3.2. Além disso, a ferramenta BJIn OLAP gastou o menor tempo para mostrar os resultados mais extensos (consulta Q3.2). Posteriormente, foi reexecutado o experimento sobre a base de dados DW10 com as seguintes configurações: Mondrian+VM acessou visões materializadas específicas que foram criadas para processar cada consulta; e BJIn OLAP+VM eliminou junções acessando índices bitmap de junção construídos sobre as visões materializadas mencionadas; Os resultados são mostrados na Figura 51b. Eles revelaram que a visualização dos resultados das consultas considerando um DW mais volumoso não prejudicou a o desempenho do Mondrian e da ferramenta BJIn OLAP, se comparados com os resultados da Figura 51a. A ferramenta BJIn OLAP apresentou os resultados das consultas em menor tempo que o Mondrian em todas as consultas. Esse resultado se deve ao fato que os resultados processados pela ferramenta BJIn OLAP são enviados através de JSON para o navegador, como resposta de uma requisição assíncrona. Assim, processa eficientemente os resultados de consultas executadas sobre índices mais volumosos e sobre índices menos volumosos. (a) Testes executados sobre a base de dados DW1 (b) Testes executados sobre a base de dados DW10 Figura 51. Tempo decorrido para visualização final do usuário dos resultados das consultas do grupo Q3

78 78 Testes de desempenho similares foram executados para operações drill-down e rollup. Foram consideradas as consultas do grupo Q3 sobre o DW10, coletando-se o tempo total de cada consulta e calculando a média em segundos das cinco execuções. Não se limpou o cache entre a execução de cada consulta, visando reaproveitar resultados prévios. As seguintes configurações foram utilizadas: Mondrian+VM eliminou junções acessando uma visão materializada especifica que foi construída para processar todas as consultas do grupo Q3; e BJIn OLAP+VM eliminou junções acessando índices bitmap de junções construídos sobre a visão materializada anteriormente citada; Os resultados para a operação drill-down são mostrado na Figura 52a. A ferramenta BJIn OLAP teve melhor desempenho que o Mondrian em todas as consultas. Além disso, a ferramenta BJIn OLAP proveu um eficiente reuso do cache e do JSON para mostrar os resultados na página. Com isso, a ferramenta BJIn OLAP proveu um baixo tempo total de apresentação dos resultados para as consultas executadas consecutivamente a partir da consulta Q3.1. Os resultados para a operação roll-up são mostrados na Figura 52b. Assim como anteriormente, a ferramenta BJIn OLAP se sobressaiu ao Mondrian em todas as consultas. Diferentemente da operação drill-down, a operação roll-up não indicou decréscimo de tempos de resposta quando suas consultas foram executadas consecutivamente. Isto se observou tanto na ferramenta BJIn OLAP como no Mondrian. Houve um acréscimo da consulta Q3.3 para a Q3.2 em ambas as configurações. Esse fato pode ser explicado pela execução das consultas que aumentou de 24 linhas (Q3.3) para 600 linhas (Q3.2), conforme mostrado na Tabela 12, causando um atraso. A exibição dos resultados das consultas não ultrapassaram 0,009 segundos na ferramenta BJIn OLAP. Novamente, houve a exibição dos resultados da operação roll-up, fazendo uso de cache e JSON, proporcionou um bom desempenho.

79 79 (a) Testes executados para operação OLAP drill-down (b) Testes executados para operação OLAP roll-up Figura 52. Tempo total para carregar as páginas de resultados das operações OLAP drill-down e roll-up do grupo Q3 sobre a base de dados DW Uso de Memória Nesta seção é apresentado o teste que mede e compara a quantidade de memória primária utilizada por cada ferramenta OLAP e seus respectivos mecanismos de consulta. O mecanismo de consulta usado pela ferramenta BJIn OLAP é o FastBit, enquanto o do servidor OLAP Mondrian é o SGBD. Todos os testes desta seção foram executados na plataforma P2, devido complexidade das operações envolvidas. O Mondrian e a ferramenta BJIn OLAP consomem memória da máquina virtual do Java (JVM) que foi medida usando o NetBeans Profiler. Esse software é amplamente pelos desenvolvedores por ser integrado com o ambiente de desenvolvimento NetBeans, e por ter uso livre. Além disso, o SGBD e o FastBit utilizam memória principal gerenciada pelo sistema operacional, que foi medida utilizando a biblioteca ps_mem.py. Essa biblioteca retrata mais fielmente o uso de memória que o comando do sistema operacional top do Linux. Primeiramente, foi executada a operação OLAP roll-up usando o grupo de consultas Q3 (Figura 39) sobre a base de dados DW1 e considerando as seguintes configurações: SGBD processou uma junção estrela para executar todas as consultas do grupo Q3 consecutivamente; Mondrian foi o servidor OLAP Mondrian acessando a junção estrela anteriormente citada;

80 80 FastBit eliminou as junções acessando intrinsecamente índices bitmap de junção que foram construídos sobre todos os atributos contidos no grupo Q3; e BJIn OLAP eliminou junções acessando os índices bitmap de junção mencionados anteriormente. A Figura 53 mostra os resultados. A ferramenta BJIn OLAP consumiu menor espaço de memória que o Mondrian na maioria do tempo. O FastBit consumiu mais memória que o SGBD durante as quatro consultas que compuseram a operação OLAP roll-up. Todavia, o FastBit exigiu um tempo muito menor que o SGBD para processar a consulta. Esse resultado revelou que a ferramenta BJIn OLAP possui um uso de memória conveniente durante a operação OLAP roll-up. Figura 53. Uso de memória para a operação OLAP roll-up sobre a base de dados DW1 Posteriormente, foi executada a consulta Q3.4 (Figura 39) sobre a base de dados DW10 e as seguintes configurações: SGBD processou a junção estrela para executar a consulta Q3.4; Mondrian foi o servidor OLAP Mondrian acessando a junção estrela anteriormente citada; FastBit eliminou as junções acessando intrinsecamente índices bitmap de junção; e BJIn OLAP eliminou junções acessando os índices bitmap de junção mencionados anteriormente.

81 81 Os resultados são mostrados na Figura 54. Nota-se que a consulta Q3.4 executada exige um alto tempo de processamento devido ao volume de dados envolvido. A ferramenta BJIn OLAP consumiu ligeiramente menos memória (aproximadamente 4 MB) que o Mondrian, além de executar a consulta mais rapidamente. O FastBit consumiu mais memória que o SGBD e teve um pico de consumo de aproximadamente 330 MB no final de seu processamento. Todavia, isso garantiu um processamento mais rápido da consulta. Após 25 segundos de execução, o consumo do SGBD foi maior que o Mondrian, mantendo-se constante até o final do processamento. Portanto, a ferramenta BJIn OLAP ofereceu um uso de memória razoável para processar a consulta Q3.4 na base de dados mais volumosa. Figura 54. Uso de memória para a consulta Q3.4 processada sobre a base de dados DW10 Para reduzir o tempo de resposta e de consumo de memória da consulta Q3.4, ela foi executada sobre a base de dados DW10 usando visões materializadas, ao invés da junção estrela. Para a configuração SGBD foi construída a visão materializada contendo os atributos da consulta Q3.4. Tal visão materializada também foi acessada pela configuração Mondrian. Na configuração FastBit, foram construídos índices bitmap de junção sobre a visão materializada, os quais também foram acessados pela configuração BJIn OLAP. Os resultados são mostrados na Figura 55. Apesar da ferramenta BJIn OLAP ter consumido mais memória que o Mondrian durante os 6 segundos iniciais, ela proporcionou um tempo mais curto de resposta. Além disso, o Mondrian drasticamente aumentou o consumo de memória após os 6 segundos de execução. O FastBit teve somente um pico de consumo de memória (aproximadamente 38 MB) que durou cerca de 1 segundo. Novamente,

82 82 a ferramenta BJIn OLAP teve um uso de memória mais adequado, considerando a consulta mais custosa. Considerando o uso de memória para junção estrela (Figura 54), os resultados para visão materializada foram razoavelmente melhores, uma vez que menos memória foi consumida em um tempo de processamento menor. Logo, a junção estrela se tornou inadmissível tanto pelo alto tempo de resposta quanto pelo inadequado consumo de memória. Figura 55. Uso de memória para a consulta Q3.4 usando visão materializada sobre a base de dados DW Portabilidade e o Desempenho no Processamento de Consultas Nessa seção são discutidos os testes de desempenho entre o Mondrian e a ferramenta BJIn OLAP em dois diferentes sistemas operacionais, objetivando avaliar a portabilidade. Na plataforma P2 foi instalado o Microsoft Windows 7 SP1 Professional 64 bits em adição ao Linux Ubuntu. Primeiramente foi realizado o teste de desempenho acessando a base de dados DW1 considerando as configurações: Mondrian+JE processou a junção estrela para executar o grupo de consultas Q3 usando MDX; e BJIn OLAP eliminou junções acessando intrinsecamente índices bitmap de junção; As consultas do grupo Q3 foram executadas cinco vezes cada uma, coletando-se o tempo total de cada consulta e o calculando-se a média do tempo de execução em segundos. As configurações descritas foram usadas em ambos os sistemas operacionais (nomeados Win e Linux). Limpou-se o de cache entre a execução de cada consulta. Os resultados são exibidos

83 83 na Figura 56, e mostram o desempenho eficiente da ferramenta BJIn OLAP em ambos os sistemas operacionais. Comparando o Mondrian a si mesmo, é notável o melhor desempenho no sistema operacional Linux. Em contrapartida, a ferramenta BJIn OLAP obteve resultados similares na maioria das consultas em ambos os sistemas operacionais, com exceção de Q3.1. Figura 56. Portabilidade e o processamento de consultas sobre a base de dados DW1 Posteriormente, um teste de desempenho similar foi executado sobre a base de dados DW10 considerando as seguintes configurações em ambos os sistemas operacionais (nomeados Win e Linux): Mondrian+VM acessou visões materializadas específicas para cada consulta do grupo Q3 usando MDX e AggregateTables; e BJIn OLAP eliminou junções acessando intrinsecamente índices bitmap de junção construídos sobre as visões materializadas. Portanto, no novo teste foi avaliado o desempenho da portabilidade utilizando visões materializadas. Os resultados são mostrados na Figura 57. Novamente, a ferramenta BJIn OLAP obteve um desempenho melhor que o Mondrian em ambos os sistemas operacionais. A consulta Q3.4 demonstrou ser a mais custosa em ambos os sistemas operacionais. Tanto o Mondrian quanto a ferramenta BJIn OLAP demonstraram melhores resultados no sistema operacional Linux, usando visões materializadas e índices construídos sobre essas visões.

84 84 Figura 57. Portabilidade e o processamento de consultas para o DW Atualizações de Índices Bitmap de Junção Nesta seção é apresentado o teste de desempenho para a operação de atualização sobre os índices bitmap de junção mantidos pela ferramenta BJIn OLAP. A base de dados DW1 foi utilizada. Considerou-se a consulta que demandou mais armazenamento (Figura 45) e maior tempo de resposta (Figura 43), isto é, a consulta Q4.2. A carga de trabalho utilizada foi composta de 10% do volume original do índice. Então, novos registros foram inseridos na tabela de fatos Lineorder. Na inserção, novos valores foram também adicionados nas tabelas de dimensão do DW. Como resultado, a operação de atualização não somente adicionou novos bits aos vetores de bits existentes, mas também criou novos vetores de bits e aumentou as cardinalidades dos atributos, conforme mostrado na Tabela 13. Cada novo vetor de bit criado teve no mínimo 6 milhões de bits com valor 0, considerando-se os bits que se referiam às entradas existentes no índice antigo. Tabela 13. Quantidade de novos vetores de bits criados para cada atributo indexado Atributos Novos vetores de bits d_year 2 s_nation 3 p_category 5 lo_revenue 0 lo_supplycost 0 s_region 0 c_region 0 p_mfgr 2 O primeiro teste averiguou o desempenho da inserção das novas tuplas na base de dados DW1. A inserção de novos registros foi executada em 184,03 segundos considerando

85 85 que a base de dados DW1 continha o gatilho para atualizar índices bitmap de junção, mantido pela ferramenta BJIn OLAP. Por outro lado, a mesma inserção foi executada em 126,89 segundos sem o gatilho. Portanto, a execução do gatilho introduziu um custo de 31,05% em relação à inserção sem o gatilho. Esse custo adicional deve ser considerado ao usar a ferramenta BJIn OLAP para a operação de atualizações de índices. O segundo teste averiguou o tempo de processamento das tarefas para atualizar índices bitmap de junção na ferramenta BJIn OLAP: exportação da tabela temporária para formato CSV usando o SGBD, e execução dos comandos ardea e ibis do FastBit para adicionar novos valores e criar novos vetores de bits. Todo o processo demorou 15,45 segundos. A Figura 58a relevou que a extração da tabela temporária consumiu 45,12% do tempo gasto para atualizar os índices bitmap de junção. Portanto, as tarefas realizadas pelo FastBit demonstram ser mais custosas que as realizadas pelo SGBD quando índices bitmap de junção são atualizados pela ferramenta BJIn OLAP. Finalmente, o último teste comparou as operações de criação dos índices bitmap de junção e a atualização dos respectivos índices usando a ferramenta BJIn OLAP, e as tarefas citadas desempenhadas pelo SGBD e pelo FastBit. Os resultados são mostrados na Figura 58b. A execução do FastBit demandou uma parcela maior de tempo para construir os índices, como evidenciado pelo processamento da atualização. Além disso, a operação de construção demandou 120 segundos, enquanto a operação de atualização levou 15 segundos. Portanto, nota-se ser mais vantajoso atualizar índices que efetuar a reconstrução dos mesmos, uma vez que os resultados mostram que o processo de atualização representaram somente 12,84% do tempo total da construção dos índices correspondentes. (a) tarefas desempenhadas pelo SGBD e FastBit (b) comparação entre operações de construção e atualização de índices Figura 58. Testes em relação a atualizações de índices bitmap de junção

86 86 6 Trabalhos Correlatos Neste capítulo são comparadas tecnologias existentes à ferramenta BJIn OLAP, como mostra a Tabela 14. O Oracle BI [42] provê suporte às operações de construção e atualização de índices bitmap de junção. Porém, o uso desse índice é somente recomendado para atributos com baixa cardinalidade [42]. Por outro lado, a ferramenta BJIn OLAP, provê suporte a indexação de atributos com altas cardinalidades. Por exemplo, o atributo lo_revenue da base de dados DW10 que possuía cardinalidade de Além disso, o Oracle BI não é um software livre com código fonte aberto, não provê uma aplicação web cliente e, portanto, não foi considerado nos testes de desempenho. O servidor OLAP Mondrian provê suporte a visões materializadas. Isto confere um melhor desempenho no processamento de consultas. Porém, não são utilizados índices bitmap de junção. Além disso, o usuário deve conhecer MDX e escrever consultas sob esta para a execução de consultas. Por outro lado, a ferramenta BJIn OLAP utiliza índices bitmap de junção e provê suporte uma linguagem de consulta que é sintaticamente baseada na SQL. Com isso, a ferramenta BJIn OLAP não requer conhecimento adicional de outra linguagem de consulta, como a MDX. Adicionalmente, o Mondrian não oferece qualquer mecanismo para atualização de visões materializadas mantidas pelo SGBD. Já a ferramenta BJIn OLAP pode realizar atualizações dos índices bitmap de junção, quando requisitado pelo usuário. Tendo em vista o desempenho de apresentação das páginas pela ferramenta BJIn OLAP e pelo Mondrian, são feitas as seguintes considerações. O Mondrian manipula as requisições do cliente de maneira síncrona, enquanto a ferramenta BJIn OLAP essas requisições são assíncronas (Ajax) [38]. Como resultado, o Mondrian envia os resultados de tabelas e gráficos preprocessados contendo código HTML, que são manipulados e exibidos pelo navegador. Por outro lado, a ferramenta BJIn OLAP envia um JSON de resposta à requisição Ajax, contendo os resultados das consultas para serem processadas no lado do cliente via Javascript [38] [39]. Com isso, a ferramenta BJIn OLAP minimiza processamento no lado do servidor, e permite a manipulação de operações no lado do cliente. Todas as operações OLAP realizadas pelo Mondrian são processadas pelo servidor. Isso é realizado pelo componente de visualização que o Mondrian utiliza, o JPivot. O JPivot é responsável por receber as requisições do usuário, e emitir uma consulta MDX ao Mondrian para processar os novos resultados. Por sua vez, a ferramenta BJIn OLAP pode realizar operações slice-and-dice e pivoting no lado cliente, usando o OAT. O uso da linguagem Javascript proporcionou a ferramenta BJIn OLAP, uma maior interação ao usuário para

87 87 realizar diversas operações, como a filtragem e a manipulação de eixos das colunas (Figuras Figura 26 e Figura 28). Além disso, para a escrita das consultas, a ferramenta BJIn OLAP provê recursos de realce e de complemento automático para auxiliar a definições de consultas. O Mondrian não dispõe de recurso semelhante. Logo, as implementações usando a linguagem Javascript na ferramenta BJIn OLAP proporcionaram a esta mais recursos de interação que o Mondrian no lado cliente. Tabela 14. Comparação de tecnologias existentes e a ferramenta BJIn OLAP Característica Oracle BI Mondrian FastBit BJIn OLAP Provê suporte ao índice bitmap de junção Provê suporte a operações OLAP Previne a digitação de complexos comandos do SO Previne a digitação de complexos comandos do SGBD Provê recursos de visualização É software de código aberto É uma aplicação web Implementa a operação de atualização Usa Ajax e JSON Em adição, a ferramenta BJIn OLAP estende eficientemente o FastBit para ser aplicado sobre DW e a suporte das operações OLAP drill-down, roll-up, slice-and-dice e pivoting. O FastBit provê suporte as operações de construção, atualização e exclusão de índices bitmap de junção, porém obriga o usuário a digitar extensos e complexos comandos ao terminal do sistema operacional e do SGBD. A ferramenta BJIn OLAP retira esses empecilhos oferecendo ao usuário uma interface para essas operações. Além disso, a ferramenta BJIn OLAP estende o FastBit para ser executado no lado do servidor, enquanto no lado do cliente os resultados das consultas são visualizados para o usuário em forma de tabelas cruzadas e gráficos em páginas JSP. Os testes de desempenho, discutidos nos capítulos 4 e 5, tiveram como objetivos validar o desempenho da ferramenta BJIn OLAP. Foi investigada a viabilidade do desenvolvimento de uma ferramenta OLAP baseada em índices bitmap de junção para processar operações OLAP drill-down, roll-up, slice-and-dice e pivoting, comparando com o Mondrian. Diferentemente do trabalho [43], estes testes não tiveram o objetivo de comparar implementações de índices de junção. Também não foram considerados algoritmos específicos para selecionar os índices bitmap de junção, conforme [17].

88 88 7 Conclusões e Trabalhos Futuros Nesta monografia foi proposta a ferramenta BJIn OLAP para eficientemente realizar o processamento de consultas OLAP e das operações OLAP drill-down, roll-up, slice-and-dice e pivoting sobre DW, utilizando intrinsecamente o índice bitmap de junção. A ferramenta BJIn OLAP é um software livre e foi validada através de testes de desempenho experimentais para avaliar e comprovar a viabilidade de adotar índices bitmap de junção em ferramentas OLAP. Os testes de desempenho experimentais foram realizados considerando os índices bitmap de junção contra as principais técnicas de processamento de consultas e o Mondrian, usando bases de dados de diferentes volumes para as consultas do SSB. Segundo os testes realizados, com a ferramenta BJIn OLAP, foi possível realizar consultas de diferentes complexidades e com atributos com alta cardinalidade mais rapidamente que o Mondrian, com ganho de cerca de 68 a 98% no tempo de resposta. Além disso, foram realizados testes de desempenho experimentais para as operações OLAP roll-up e drill-down em diferentes volumes de dados. Os resultados mostraram que a ferramenta BJIn OLAP reduziu drasticamente o tempo de resposta das operações OLAP drilldown e roll-up acessando somente índices bitmap de junção com reduções de 64% a 93%. Adicionalmente, a ferramenta BJIn OLAP propiciou um processamento eficiente de consultas em diferentes sistemas operacionais, contribuindo com a portabilidade. Testes de desempenho, para averiguar o tempo em que os resultados das consultas são exibidos ao usuário, demonstraram que a ferramenta BJIn OLAP provê recursos eficientes de visualização dos resultados. Além disso, segundo os testes realizados, observou-se que a ferramenta BJIn OLAP proveu um uso de memória mais adequado que as propostas existentes. Embora esta ferramenta utilize mais memória para processar as consultas, esse uso é feito por um período curto, ao contrário do Mondrian que utiliza menos memória, mas por um período mais longo. Isso se deve ao fato de a ferramenta BJIn OLAP prover um tempo de resposta mais curto que o Mondrian para processar as consultas OLAP. Outro diferencial da ferramenta é o seu suporte para atualização de índices bitmap de junção. Apesar do custo adicional devido a execução do gatilho de atualizações, nos testes realizados há indícios de que é mais viável realizar atualizações no índice do que reconstruílos a cada adição de tuplas.

89 89 Como trabalhos futuros pretende-se registrar formalmente a ferramenta BJIn OLAP como Software Livre, e o seu portal na internet ( deverá conter todas as documentações do trabalho realizado. Será realizada a execução de testes de desempenho para avaliar a escalabilidade da ferramenta, utilizando volumes de dados crescentes. Por exemplo, com a geração de dados segundo valores crescentes do fator de escala do SSB, e.g. 1, 2, 3,..., 100. Além disso, serão realizadas comparações com outras ferramentas OLAP, envolvendo as funcionalidades e o desempenho do processamento de consultas. A investigação para a operação OLAP drill-across e a adaptação da ferramenta para operações OLAP espaciais (SOLAP) são trabalhos em desenvolvimento [44]. Além disso, a usabilidade da ferramenta BJIn OLAP para dispositivos móveis será investigada e definida para processar consultas e operações OLAP, visando a portabilidade para Mobile OLAP [45].

90 90 8 Referências [1] XU, L., et al. Research on business intelligence in enterprise computing environment. In: IEEE INTERNATIONAL CONFERENCE, SYSTEMS, MAN AND CYBERNETICS, 2007, Montreal, Anais 2007, p [2] WREMBEL, R.; KONCILIA, C. Data Warehouses and OLAP: Concepts, Architectures and Solutions. IRM Press, p. [3] KIMBALL, R.; ROSS, M. The Data Warehouse Toolkit: O guia completo para modelagem dimensional. 2. ed. Rio de Janeiro: Campus, p. [4] INMON, H. Building the Data Warehouse. 4. ed. Wiley, p. [5] CIFERRI, C. D. A. Distribuição dos dados em ambientes de data warehousing f. Tese (Doutorado em Ciência da Computação) - Centro de Informática, Universidade Federal de Pernambuco, Recife, PE, Brasil, [6] GOLFARELLI, M. Open source BI platforms: a functional and architectural comparison. In: INTERNATIONAL CONFERENCE ON DATA WAREHOUSING AND KNOWLEDGE DISCOVERY (DaWaK), 11., 2009, Linz, Austria: Springer, Anais 2009, p [7] CHAUDHURI, S.; DAYAL, U. An overview of data warehousing and OLAP technology. Special Interest Group on Management of Data (SIGMOD Record), v. 26, p , ACM, [8] SIQUEIRA, T. L. L. SB-index: Um Índice Espacial baseado em Bitmap para Data Warehouse Geográfico f. Dissertação (Mestrado em Ciência da Computação) - Departamento de Computação, Universidade Federal de São Carlos, São Carlos, SP, Brasil, [9] BAIKOUSI, E.; VASSILIADIS P. View usability and safety for the answering of top-k queries via materialized views. ACM FOURTEENTH INTERNATIONAL WORKSHOP ON DATA WAREHOUSING AND OLAP (DOLAP), 12., 2009, New York: ACM, Anais 2009, p [10] HARINARAYAN, V.; RAJARAMAN, A.; ULLMAN, J. D. Implementing data cubes efficiently. Special Interest Group on Management of Data (SIGMOD Record), v. 25, p , ACM, [11] DELLATRECHE, L.; WOAMENO Y. Dimension table driven approach to referential partition relational data warehouses. ACM FOURTEENTH INTERNATIONAL

91 91 WORKSHOP ON DATA WAREHOUSING AND OLAP (DOLAP), 12., 2009, New York: ACM, Anais 2009, p [12] FIRMINO, A. S. et al. A Novel Method for Selecting and Materializing Views based on OLAP Signatures and GRASP. Journal of Information and Data Management. v. 2, n. 3, p , SBC, [13] GOLFARELLI, M.; MAIO, D.; RIZZI, S. Applying vertical fragmentation techniques in logical design of multidimensional databases. In: INTERNATIONAL CONFERENCE ON DATA WAREHOUSING AND KNOWLEDGE DISCOVERY (DaWaK), 2., 2000 London: Springer, Anais 2000, p [14] STOCKINGER K.; WU, K. Bitmap indices for data warehouses. In: WREMBEL, R.; KONCILIA, C. Data Warehouses and OLAP: Concepts, Architectures and Solutions. Data Warehouses and OLAP. IRM Press, p [15] CHAN, C. Y. Bitmap Index. In: LIU, L; OZSU, M. T. Encyclopedia of Database Systems. Springer, 2009, p [16] O NEIL P.; GRAEFE, G. Multi-table joins through bitmapped join indices. Special Interest Group on Management of Data (SIGMOD Record), v. 24, p. 8-11, ACM, [17] DELLATRECHE, L.; BOUKHALFA, K. Yet Another Algorithms for Selecting Bitmap Join Indexes. In: INTERNATIONAL CONFERENCE ON DATA WAREHOUSING AND KNOWLEDGE DISCOVERY (DaWaK), 12., 2010, Bilbao: Springer, Anais 2010, p [18] MONDRIAN pentaho analysis. Disponível em: Acesso em: Fev [19] CASTERS, M.; BOUMAN, J.; DOGEN. Pentaho Kettle Solutions. 1 ed. Wiley, 2010, 721 p. [20] O NEIL, P., et al. The Star Schema Benchmark and Augmented Fact Table Indexing. Lecture Notes in Computer Science, v. 5895/2009, p , Springer Berlin / Heidelberg, [21] CARNIEL, A. C.; SIQUEIRA, T. L. L. An OLAP Tool based on the Bitmap Join Index. In: CONFERENCIA LATINOAMERICANA DE INFORMÁTICA. 35., 2011, Quito, Anais , p [22] CARNIEL, A. C.; SIQUEIRA, T. L. L. The Bitmap Join Index OLAP Tool. In: SIMPÓSIO BRASILEIRO DE BANCO DE DADOS SESSÃO DEMOS. 17., 2011, Florianópolis, SC, Brasil, Anais , p [23] JPIVOT. Disponível em: Acesso em: Fev

92 92 [24] PENTAHO MONDRIAN documentation. Disponível em: Acesso em: Fev [25] WHITEHORN, M.; ZARE, R.; PASUMANSKY, M. Fast Track to MDX. Springer, p. [26] WU, K. FastBit: an efficient indexing technology for accelerating data-intensive science. Journal of Physics: Conference Series. v. 16, p , [27] FASTBIT an efficient compressed bitmap index technology. Disponível em: Acesso em: Fev [28] CIFERRI, C. D. A.; FONSECA, F. F. Materialized Views in Data Warehousing Environments. In: XXI INTERNATIONAL CONFERENCE OF THE CHILEAN - COMPUTER SCIENCE SOCIETY. 11., 2001, Punta Arenas, Chile, Anais 2001, p [29] CANAHUATE, G. Update Conscious Bitmap Indexes. In: CANAHUATE, G. Enhanced Bitmap Indexes for Large Scale Data Management p Dissertação (Mestrado em Ciência da Computação) - The Ohio State University, EUA, [30] GUEDES, G.T.A. UML: Uma abordagem prática. ed. 1. Novatec, p. [31] DEITEL, H. M.; DEITEL, P. J. Java: Como Programar. ed. 6. Prentice Hall, p. [32] PRESSMAN, R. S. Engenharia de Software. ed. 6. Bookman, p. [33] METSKER, S. J. Padrões de projeto em Java. Bookman, p. [34] KURNIAWAN, B. Java para a web com Servlets, JSP e EJB. ed. 1. Ciência Moderna, p. [35] OAT Open-link Ajax Toolkit Framework. Disponível em: Acesso em: Fev [36] CODEMIRROR 2. Disponível em: Acesso em: Fev [37] JQUERY the write less, do more. Disponível em: Acesso em: Fev [38] ZAKAS, N. C.; McPEAK, J.; FAWCETT, J. Professional Ajax (Programmer to Programmer). 2 ed. Wrox, p. [39] CROCKFOD, D. JavaScript: The Good Parts. Yahoo Press, p. [40] GUPTA, S. Pro Apache log4j. ed. 2. APress, p. [41] SIQUEIRA, T. L. L.; CIFERRI, R. R.; SANTOS, M. T. P. Projeto, construção e manutenção de data warehouses para auxiliar o planejamento de políticas de educação.

93 93 In: XVI JORNADAS DE JÓVENES INVESTIGADORES.16., 2008, Chile, Anais , p [42] LANE, P. Oracle Database Data Warehousing Guide 11g Release 1 (11.1) Disponível em: [43] DATTA, A.; VANDERMEER, D.; RAMAMRITHAM, K. Parallel Star Join + DataIndexes: efficient query processing in data warehouses and OLAP. In: KNOWLEDGE AND DATA ENGINNERING, IEEE TRANSACTIONS. 14., 2002, IEEE Computer Society, Anais 2002, p [44] SIQUEIRA, T. L. L. et al. The SB-index and the HSB-Index: efficient indices for spatial data warehouses. Geoinformatica, v.16, n. 1, p , Springer, [45] MANIATIS, S. The Case for Mobile OLAP. In: INTERNATIONAL PERVASIVE INFORMATION MANAGEMENT PIM 04 (EDBT WORKSHOPS), 2004, Grécia, Anais , p

94 94 APÊNDICE A Diagrama de Casos de Uso BJIn OLAP Objetivo deste Documento Este documento tem como finalidade especificar os limites e as funcionalidades de BJIn OLAP Tool. Diagrama de Casos de Uso Atores Ator Usuário Mondrian Schema Workbench SGBD FastBit Descrição O ator deseja construir, atualizar, excluir e consultar índices, visualizando seus resultados em gráficos e tabelas. Além disso, o ator deseja realizar operações OLAP provenientes de consultas que foram processadas. Software que constrói documento XML para o ator Usuário com a especificação validada do cubo de dados de um data warehouse. Sistema Gerenciador de Banco de Dados responsável por manter data warehouses. Software que manipula índices bitmap, sendo o responsável por construir e consultar os índices bitmap. Especificação de Casos de Uso RQ (Requisito) - Um requisito é uma condição ou uma capacidade com o qual o sistema deve estar de acordo expressando as necessidades do cliente. RN (Regras de Negócio) - Correspondem às regras que regulam o negócio que devem ser seguidas e garantidas pelo sistema para cada requisito funcional identificado e/ou para o módulo.

95 95 UC001 Manter Índices Bitmap de Junção Sumário Este caso de uso tem como objetivo a construção, atualização e exclusão de índices bitmap de junção. Bem como o carregamento do documento XML, previamente especificado utilizando o ator Mondrian Schema Workbench, na ferramenta BJIn OLAP. Pré-Condição Existindo um controle de usuários na ferramenta, o usuário deve estar autenticado. Configuração do software FastBit na ferramenta. Roteiro Fluxo Básico Depois de autenticado na ferramenta BJIn OLAP: 1. A ferramenta apresenta as opções de Upload XML [FA01], Create Index [FA02], Update Index [FA03] e Drop Index [FA04]. 2. O caso de uso é encerrado. Fluxos Alternativos FA01 Upload XML 1. A ferramenta apresenta a tela de carregamento de documento XML de especificação do cubo de dados a ser indexado [RN01]; 2. O ator Usuário seleciona o documento XML e aciona a opção de Upload XML [FE01] [FE02] [FE03] [RN02]; 3. A ferramenta mostra a mensagem [MSG04] e deverá ir ao fluxo [FA01] FA02 Create Index: 1. A ferramenta apresenta a tela de construção de índices bitmap de junção [RN03]; 2. O ator Usuário preenche as informações, define se os índices serão criados sobre uma visão materializada, caso positivo deve ir ao fluxo [FA04], bem como aciona a opção Build Index [FE01] [FE03] [FE04] [FE05] [FE06] [RN05]; 3. A ferramenta deve ir ao fluxo [FA06]. FA03 Update Index: 1. A ferramenta apresenta a tela de atualizações de índices bitmap de junção [RN06]; 2. O ator Usuário preenche as informações e aciona a opção Update Index [FE01] [FE03] [FE05] [FE06] [RN07]; 3. A ferramenta deve ir ao fluxo [FA06]. FA04 Drop Index: 1. A ferramenta apresenta a lista de índices bitmap de junção a serem excluídos [RN08]; 2. O ator Usuário seleciona o índice a ser excluído [FA07]; 3. O ator Usuário aciona a opção Drop Index [FE01] [FE03] [FE05] [RN10]; 4. O sistema deverá apresentar uma mensagem informativa [MSG08] e deve retornar para o fluxo [FA04]. FA05 Visualizar estrutura do cubo de dados selecionado: 1. A ferramenta mostra a estrutura do cubo de dados que o usuário selecionou, permitindo a seleção dos atributos que formarão a visão materializada a ser indexada [RN04]; 2. O ator Usuário seleciona os atributos que formarão a visão materializada; 3. A ferramenta deve retornar ao fluxo básico. FA06 Construindo índices:

96 96 UC001 Manter Índices Bitmap de Junção 1. A ferramenta mostra a tela de que está construindo os índices bitmap de junção. FA07 Índice a ser excluído: 1. A ferramenta verifica se o índice a ser excluído tem como opção habilitada, as atualizações (update); 2. Em caso positivo, a ferramenta mostra as informações a serem preenchidas [RN09]; 3. O ator Usuário preenche as informações; 4. A ferramenta deve retornar ao fluxo 3 de [FA04]. Fluxos de Exceção FE01 Campo Obrigatório Não Preenchido: 1. Caso algum campo obrigatório não tenha sido informado, a ferramenta deverá apresentar uma mensagem informativa [MSG01]; 2. As informações são mantidas na tela atual. FE02 Documento XML inválido: 1. Caso o documento XML enviado não for válido para a construção de índices bitmap de junção, a ferramenta deverá apresentar uma mensagem informativa [MSG02]; 2. As informações são mantidas na tela atual. FE03 Permissão negada: 1. Caso o ator Usuário autenticado não tiver permissão para a operação solicitada, a ferramenta deverá apresentar uma mensagem informativa [MSG03]; 2. As informações são mantidas na tela atual. FE04 Nome do índice inválido: 1. Caso o nome do índice não começar com letras ou underline e tiver somente caracteres alfanuméricos, a ferramenta deverá apresentar uma mensagem informativa [MSG05]; 2. As informações são mantidas na tela atual. FE05 Conexão com o banco de dados falhou: 1. Caso o usuário e senha do banco de dados falharem na conexão com o ator SGBD, o sistema deverá apresentar uma mensagem informativa [MSG06]. 2. As informações são mantidas na tela atual. FE06 Caminho do FastBit inválido: 1. Caso a configuração do FastBit da ferramenta BJIn OLAP não existir ou o caminho do software ardea e íbis não forem os corretos, o sistema deverá apresentar uma mensagem informativa [MSG07]. 2. As informações são mantidas na tela atual. Pós-Condição Ator Usuário com um índice construído pronto a ser consultado. Regra de Negócio RN01 Carregar novo documento XML:

97 97 UC001 Manter Índices Bitmap de Junção 1. A ferramenta deverá apresentar um link para envio do arquivo XML: a. Documento XML; RN02 O Documento XML: 1. A ferramenta deverá validar se o arquivo selecionado é um documento XML válido. Caso contrário, deverá emitir uma mensagem de alerta [MSG02]. 2. Se existir um controle de usuários, a ferramenta deverá validar se o usuário autenticado possui permissão para construir índices. Caso contrário, deverá emitir uma mensagem de alerta [MSG03]; RN03 Novo Índice: 1. A ferramenta deverá apresentar um link para criação de um novo índice bitmap de junção: a. Dados do índice: i. A ferramenta deverá apresentar os seguintes campos: 1. Documento XML; 2. Nome do Índice; 3. Usuário do SGBD; 4. Senha do SGBD; 5. Criar Índice sobre uma Visão Materializada; 6. Criar Índice com suporte a Atualizações; RN04 Selecionar atributos para Visão Materializada: 1. Caso a opção de criar o índice sobre uma visão materializada estiver marcada, a ferramenta deverá apresentar os atributos envolvidos no documento XML selecionado: a. Árvore da estrutura do cubo de dados do documento XML: i. A ferramenta deverá apresentar todos os atributos do XML com a opção de sua seleção: 1. Atributo do XML; RN05 Criar Índice: 1. Se existir um controle de usuários, a ferramenta deverá validar se o usuário autenticado possui permissão para construir índices. Caso contrário, deverá emitir uma mensagem de alerta [MSG03]; 2. A ferramenta deverá validar se o nome do índice foi informado corretamente. Caso contrário, deverá emitir uma mensagem de alerta [MSG05]; 3. A ferramenta deverá validar se os dados informados do SGBD estão corretos para o estabelecimento da conexão com o SGBD. Caso contrário, deverá emitir uma mensagem de alerta [MSG06]; 4. A ferramenta deverá validar se os dados configurados do FastBit estão corretos. Caso contrário, deverá emitir uma mensagem de alerta [MSG07]; 5. A ferramenta deverá acessar o ator SGBD, carregar os dados a serem indexados e enviá-los ao ator FastBit para construir o índice referido. RN06 Atualização de Índice: 1. A ferramenta deverá apresentar um link para atualização de um índice bitmap de junção existente: b. Dados do índice: i. A ferramenta deverá apresentar os seguintes campos: 1. Nome do Índice: existente em ordem alfabética; 2. Usuário do SGBD;

98 98 UC001 Manter Índices Bitmap de Junção 3. Senha do SGBD; RN07 Atualizar Índice: 1. Se existir um controle de usuários, a ferramenta deverá validar se o usuário autenticado possui permissão para atualizar o índice selecionado. Caso contrário, deverá emitir uma mensagem de alerta [MSG03]; 2. A ferramenta deverá validar se o nome do índice foi informado. Caso contrário, deverá emitir uma mensagem de alerta [MSG01]; 3. A ferramenta deverá validar se os dados informados do SGBD estão corretos. Caso contrário, deverá emitir uma mensagem de alerta [MSG06]; 4. A ferramenta deverá validar se os dados configurados do FastBit estão corretos. Caso contrário, deverá emitir uma mensagem de alerta [MSG07]; 5. A ferramenta deverá validar se o índice selecionado possui atualizações disponíveis. Caso contrário, deverá emitir uma mensagem de alerta [MSG09]; 6. A ferramenta deverá acessar o ator SGBD e enviar os novos dados a serem indexados para o ator FastBit atualizar o índice referido. RN08 Exclusão de Índices: 1. A ferramenta deverá apresentar uma listagem em ordem alfabética: a. Dados do índice: i. Nome do Índice; RN09 Dados SGBD: 1. A ferramenta deverá apresentar: c. Dados do SGBD: i. A ferramenta deverá apresentar os seguintes campos: 1. Usuário do SGBD; 2. Senha do SGBD; RN10 Excluir Índice: 1. Se existir um controle de usuários, a ferramenta deverá validar se o usuário autenticado possui permissão para excluir o índice selecionado. Caso contrário, deverá emitir uma mensagem de alerta [MSG03]; 2. A ferramenta deverá validar se o nome do índice foi informado. Caso contrário, deverá emitir uma mensagem de alerta [MSG01]; 3. Caso os dados do SGBD forem requisitados, a ferramenta deverá validar se os dados informados estão corretos. Caso contrário, deverá emitir uma mensagem de alerta [MSG06]; 4. A ferramenta deverá excluir o índice, e caso existir dados do SGBD, excluir o gatilho criado. Mensagens MSG01 O campo (nome do campos) não foi preenchido. MSG02 - Documento XML inválido. MSG03 - O usuário (usuário) não tem permissão para efetuar (operação). MSG04 - Documento XML enviado com sucesso. MSG05 - Nome do índice é inválido. Por favor, informe um nome válido. MSG06 - Conexão com o banco de dados falhou. Usuário e/ou senha incorreto. MSG07 - Dados de configuração do FastBit inválidos.

99 99 MSG08 - Índice excluído com sucesso. MSG09 - O índice não possui atualizações disponíveis. UC001 Manter Índices Bitmap de Junção Detalhamento dos campos. Legenda O - Preenchimento obrigatório A - Preenchimento automático pelo sistema E - Valor do atributo pode ser editado Campo O A E Tipo Tamanho Documento XML x XML Nome do Índice x x Texto Usuário do SGBD x x Texto Senha do SGBD x x Texto Criar Índice sobre uma Visão Materializada x Booleano Criação Índice com suporte a Atualizações x Booleano Atributo do XML x x Booleano

100 100 UC002 Consultar Índices Bitmap de Junção Sumário Este caso de uso tem como objetivo a consulta de índices bitmap de junção, oferecendo recursos que facilite a definição da consulta. Bem como a visualização de seus resultados de forma agradável em tabelas de gráficos ao ator Usuário. Pré-Condição Existindo um controle de usuários na ferramenta, o usuário deve estar autenticado. Configuração do software FastBit na ferramenta. Um índice deve estar construído. Roteiro Fluxo Básico Depois de autenticado na ferramenta BJIn OLAP, e acessar a parte de Query Index: 1. A ferramenta apresenta a opção de selecionar um índice disponível para consulta [FA01]; 2. O caso de uso é encerrado. Fluxos Alternativos FA01 Selecionar Índice para Consulta: 1. A ferramenta apresenta uma tela de listagem dos índices disponíveis para consulta [RN01]; 2. O ator Usuário seleciona o índice a ser consultado e aciona a opção de Proceed [FE01] [RN02]; 3. A ferramenta deverá direcionar para a tela de consulta do índice selecionado [FA02]. FA02 Consultar Índice: 1. A ferramenta apresenta a tela de consulta do índice [RN03]; 2. O ator Usuário escreve a consulta [FA03] e aciona a opção Submit Query [FE02] [RN05]; 3. A ferramenta deve ir ao fluxo [FA04] permanecendo na mesma tela. FA03 Recurso para Auxiliar a Escrita de Consultas: 1. A ferramenta apresenta recursos de realce e de autocompletar para palavras reservadas e atributos disponíveis no índice [RN04]. FA04 Resultados da Consulta: 1. A ferramenta apresenta o resultado da consulta em tabela cruzada e em gráficos [RN06]; 2. O ator Usuário visualiza o resultado da consulta e poderá definir outra consulta [FA02]. Fluxos de Exceção FE01 Índice Não Selecionado: 3. Caso nenhum índice não tenha sido selecionado, a ferramenta deverá apresentar uma mensagem informativa [MSG01]; 4. As informações são mantidas na tela atual. FE02 Consulta Inválida: 1. Caso a consulta informada não tenha sido informada ou conter erros, a ferramenta deverá apresentar uma mensagem informativa [MSG02]; 2. Caso a configuração do FastBit da ferramenta BJIn OLAP não existir ou o caminho do software ardea e íbis não forem os corretos, o sistema deverá apresentar uma mensagem informativa [MSG03]. 3. As informações são mantidas na tela atual.

101 101 UC002 Consultar Índices Bitmap de Junção Pós-Condição Ator Usuário com resultados de consultas processada pelo FastBit acessando intrinsecamente índices bitmap de junção. Regra de Negócio RN01 Listar Índices para Consulta: 1. A ferramenta deverá apresentar uma listagem dos índices que o usuário autenticado tem acesso, em ordem alfabética: a. Dados do índice: ii. Nome do Índice; RN02 Validar Índice Selecionado: 1. A ferramenta deverá validar se o índice selecionado existe e se o mesmo está pronto para consulta. Caso o índice não existir, deverá emitir uma mensagem de alerta [MSG04], caso o índice não estiver pronto para consulta, deverá emitir uma mensagem de alerta [MSG05]. RN03 Consulta de Índice: 1. A ferramenta deverá apresentar uma tela de consulta do índice selecionado: a. Dados do índice: i. A ferramenta deverá apresentar os seguintes dados referentes ao índice: 1. Estrutura em Árvore dos Atributos do Índice; 2. Nome do Índice; b. Consulta ii. A ferramenta deverá apresentar o seguinte campo: 1. Consulta; RN04 Recurso para Auxiliar Escrita de Consulta: 1. A ferramenta deverá realçar as palavras chaves e atributos do índice com cores predominantes no momento em que o ator Usuário estiver digitando a consulta no campo, além de oferecer recurso de autocompletar para a palavra que está sendo digitada. RN05 Consultar Índice: 1. A ferramenta deverá validar a consulta escrita. Caso a consulta esteja com erro de sintaxe, deverá emitir uma mensagem de alerta [MSG02]; 2. A ferramenta deverá validar se os dados configurados do FastBit estão corretos. Caso contrário, deverá emitir uma mensagem de alerta [MSG03]; 3. A ferramenta deverá acessar o ator FastBit para processar a consulta emitida. RN06 Resultados da Consulta: 1. A ferramenta deverá apresentar os resultados da consulta emitida pelo ator Usuário. Caso não existir resultado, a ferramenta deverá emitir a mensagem [MSG06]; a. Dados do Resultado: i. A ferramenta deverá apresentar os seguintes resultados da consulta: 1. Tabela Cruzada; 2. Gráficos;

102 102 UC002 Consultar Índices Bitmap de Junção Mensagens MSG01 - Nenhum índice foi selecionado para ser consultado. MSG02 - Consulta inválida. (erro). MSG03 - Dados de configuração do FastBit inválidos. MSG04 - O índice selecionado não existe. MSG05 - O índice ainda está sendo construído ou atualizado. (passo construção/atualização). MSG06 - Essa consulta não contém resultados. Detalhamento dos campos. Legenda O - Preenchimento obrigatório A - Preenchimento automático pelo sistema E - Valor do atributo pode ser editado Campo O A E Tipo Tamanho Nome do Índice x x Texto Estrutura em Árvore dos Atributos do Índice x x Árvore Consulta x x Texto Tabela Cruzada x x Tabela Gráficos x Gráfico

103 103 UC003 Processar Operações OLAP Sumário Este caso de uso tem como objetivo processar as operações OLAP: slice-and-dice, pivoting, drill-down e roll-up. As operações drill-down e roll-up reusam o caso de uso de Consultar Índices Bitmap de Junção, definindo automaticamente a consulta que responda a operação OLAP definida. Pré-Condição Existindo um controle de usuários na ferramenta, o usuário deve estar autenticado. Configuração do software FastBit na ferramenta. Um índice deve estar construído. Uma consulta sobre o índice deve ter sido processada. Roteiro Fluxo Básico Depois de autenticado na ferramenta BJIn OLAP, acessar a parte de Query Index, e processar uma consulta: 1. A ferramenta apresenta as opções de drill-down [FA01], roll-up [FA02], slice-and-dice [FA03] e pivoting [FA04]; 2. O caso de uso é encerrado. Fluxos Alternativos FA01 Operação OLAP drill-down: 1. A ferramenta apresenta uma listagem dos atributos que possuem a operação drill-down disponível [RN01]; 2. O ator Usuário seleciona qual o atributo de origem do drill-down e o destino e aciona a opção de Submit Drill-Down [FE01] [RN02]; 3. A ferramenta deverá ir ao [UC002 - FA04]. FA02 Operação OLAP roll-up: 1. A ferramenta apresenta uma listagem dos atributos que possuem a operação roll-up disponível [RN03]; 2. O ator Usuário seleciona qual o atributo de origem do roll-up e o destino e aciona a opção de Submit Roll-Up [FE01] [RN04]; 3. A ferramenta deverá ir ao [UC002 - FA04]. FA03 Operação OLAP slice-and-dice: 1. A ferramenta apresenta opções de filtragem sobre as colunas visualizadas na tabela cruzada do resultado da consulta [RN05]; 2. O ator Usuário define o filtro sobre a coluna selecionada [FE02] [RN06]; 3. A ferramenta deve mostrar a nova tabela cruzada, resultante do filtro, na mesma tela. FA04 Operação OLAP pivoting: 1. A ferramenta oferece recursos para a troca de eixos na tabela cruzada de resultado [RN07]; 2. O ator Usuário troca eixo de colunas selecionadas na tabela cruzada [FE02] [RN08]; 3. A ferramenta deve mostrar a nova tabela cruzada, resultante do pivoteamento, na mesma tela. Fluxos de Exceção FE01 Atributo não Existente ou não Pertencente a Hierarquia: 1. Caso o atributo de origem ou destino não existir, ou não pertencer à mesma hierarquia da dimensão correspondente, a ferramenta deverá apresentar uma mensagem informativa [MSG01]; 2. As informações são mantidas na tela atual.

104 104 UC003 Processar Operações OLAP FE02 Coluna na Tabela Cruzada Não Existe: 1. Caso a coluna da tabela cruzada selecionada não existir, a ferramenta deverá apresentar uma mensagem informativa [MSG02]; 2. As informações são mantidas na tela atual. Pós-Condição Ator Usuário com resultados das operações OLAP realizadas sobre a consulta. Regra de Negócio RN01 Listar Atributos para Operação OLAP Drill-Down: 1. A ferramenta deverá apresentar uma listagem dos atributos do índice que tiver, ao menos, um descendente em sua hierarquia e para cada atributo listado: a. A ferramenta deverá listar todos os descendentes de sua hierarquia: i. Atributos que contém descendente, em ordem alfabética: 1. Nome do Atributo; ii. Descendentes de cada atributo listado: 1. Descendente; RN02 Realizar Operação OLAP Drill-Down: 1. A ferramenta deverá validar se os atributos selecionados existem e se pertencem a mesma hierarquia, caso contrário, deverá emitir uma mensagem de alerta [MSG01]. 2. A ferramenta deverá gerar uma nova consulta derivada da operação OLAP drill-down sobre o atributo de origem selecionado para o atributo descendente destino selecionado. RN03 Listar Atributos para Operação OLAP Roll-up: 1. A ferramenta deverá apresentar uma listagem dos atributos do índice que tiver, ao menos, um ancestral em sua hierarquia e para cada atributo listado: a. A ferramenta deverá listar todos os ancestrais de sua hierarquia: i. Atributos que contém ancestral, em ordem alfabética: 1. Nome do Atributo; ii. Ancestrais de cada atributo listado: 1. Ancestral; RN04 Realizar Operação OLAP Roll-up: 1. A ferramenta deverá validar se os atributos selecionados existem e se pertencem a mesma hierarquia, caso contrário, deverá emitir uma mensagem de alerta [MSG01]. 2. A ferramenta deverá gerar uma nova consulta derivada da operação OLAP roll-up sobre o atributo de origem selecionado para o atributo ancestral destino selecionado. RN05 Listar Valores de Filtragem para Operação OLAP slice-and-dice: 1. A ferramenta deverá apresentar uma listagem dos valores da coluna selecionada da tabela cruzada: a. Valores da Coluna: i. A ferramenta deverá apresentar a listagem em ordem alfabética dos valores da coluna: 1. Valor;

105 105 UC003 Processar Operações OLAP RN06 Realizar Operação OLAP slice-and-dice: 1. A ferramenta deverá validar se o atributo selecionado existe e se o valor selecionado pertence a coluna, caso contrário, deverá emitir uma mensagem de alerta [MSG01]. 2. A ferramenta deverá gerar uma nova tabela cruzada realizando o filtro, sobre coluna selecionada, dos valores selecionados: a. O filtro ocorre na seleção dos valores da coluna que foram listados. RN07 Viabilização da Operação OLAP pivoting: 1. A ferramenta deverá viabilizar a troca de eixos da tabela cruzada; a. Trocar atributos que estão no eixo das colunas para o eixo das linhas; b. Trocar atributos que estão no eixo das linhas para o eixo das colunas. RN08 Realizar Operação OLAP pivoting: 1. A ferramenta deverá validar se o atributo selecionado existe ou se a operação de pivoting é inválida devido a tentativa da troca de eixo pelo mesmo eixo, caso contrário, a ferramenta deverá impedir a operação de pivoting. 2. A ferramenta deverá gerar uma nova tabela cruzada com a troca de eixos realizados na tabela cruzada. Mensagens MSG01 - Atributos selecionados não existem ou não pertence à mesma hierarquia. MSG02 - Coluna da tabela cruzada não existe. Detalhamento dos campos. Legenda O - Preenchimento obrigatório A - Preenchimento automático pelo sistema E - Valor do atributo pode ser editado Campo O A E Tipo Tamanho Nome do Atributo x x Texto Descendente x x Texto Ancestral x x Texto Valor x x Texto

106 106 APÊNDICE B Diagramas de Classe Este apêndice objetiva documentar e especificar as classes da ferramenta BJIn OLAP e seus principais relacionamentos. Os diagramas de classe que compõe este apêndice são: Diagrama de Pacotes: que mostram todos os pacotes existentes na ferramenta BJIn OLAP; Diagrama de Classe 1 Manter Índices Bitmap de Junção: mostra as principais classes envolvidas para a construção, alteração e exclusão de índices bitmap de junção; e Diagrama de Classe 2 Consultar Índices Bitmap de Junção e Processar Operações OLAP: mostra as principais classes envolvidas para consulta e processamento de operações OLAP sobre os índices bitmap de junção. Em adição, para cada pacote da ferramenta é mostrado um diagrama de classe detalhando as classes que compõe tal pacote. Portanto, os pacotes que terão diagrama de classe detalhado são: Diagrama de Classe br.bjinolap.controller Diagrama de Classe br.bjinolap.model.bean Diagrama de Classe br.bjinolap.bitmapjoinindex Diagrama de Classe br.bjinolap.model.bitmapjoinindex.column Diagrama de Classe br.bjinolap.model.bitmapjoinindex.executor Diagrama de Classe br.bjinolap.model.bitmapjoinindex.map Diagrama de Classe br.bjinolap.model.bitmapjoinindex.query Diagrama de Classe br.bjinolap.model.bitmapjoinindex.util Diagrama de Classe br.bjinolap.model.bitmapjoinindex.validate Diagrama de Classe br.bjinolap.model.command Diagrama de Classe br.bjinolap.model.connection Diagrama de Classe br.bjinolap.model.user Diagrama de Classe br.bjinolap.model.xml Diagrama de Classe br.bjinolap.thread

107 1. Diagrama de Pacotes 107

108 2. Diagrama de Classe 1 Manter Índices Bitmap de Junção 108

109 Diagrama de Classe 2 Consultar Índices Bitmap de Junção e Processar Operações OLAP

110 4. Diagrama de Classe br.bjinolap.controller 110

111 5. Diagrama de Classe br.bjinolap.model.bean 111

112 6. Diagrama de Classe br.bjinolap.bitmapjoinindex 112

113 7. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.column 113

114 8. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.executor 114

115 9. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.map 115

116 10. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.query 116

117 11. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.util 117

118 12. Diagrama de Classe br.bjinolap.model.bitmapjoinindex.validate 118

119 13. Diagrama de Classe br.bjinolap.model.command 119

120 Diagrama de Classe br.bjinolap.model.connection 15. Diagrama de Classe br.bjinolap.model.user

121 Diagrama de Classe br.bjinolap.model.xml 17. Diagrama de Classe br.bjinolap.thread

122 122 APÊNDICE C Diagramas de Sequência Este apêndice objetiva documentar e especificar as funcionalidades principais e prioritárias da ferramenta BJIn OLAP por meio de diagramas de sequência. Estes diagramas visam demonstrar a interação entre as principais classes para cada funcionalidade da ferramenta BJIn OLAP. Os diagramas de sequência que compõe este apêndice são: Diagrama de sequência geral para controle de requisições; Diagrama de sequência da construção de índices bitmap de junção; Diagrama de sequência da atualização de índices bitmap de junção; Diagrama de sequência para registro de logs das operações de construção e atualização de índices bitmap de junção; Diagrama de sequência da exclusão de índices bitmap de junção; Diagrama de sequência do processamento de consultas sobre índices bitmap de junção; Diagrama de sequência para processamento da operação OLAP drill-down; e, Diagrama de sequência para processamento da operação OLAP roll-up.

123 1. Diagrama de sequência geral para controle de requisições 123

124 2. Diagrama de sequência da construção de índices bitmap de junção 124

125 3. Diagrama de sequência da atualização de índices bitmap de junção 125

126 Diagrama de sequência para registro de logs das operações de construção e atualização de índices bitmap de junção

127 5. Diagrama de sequência da exclusão de índices bitmap de junção 127

128 Diagrama de sequência do processamento de consultas sobre índices bitmap de junção

129 7. Diagrama de sequência para processamento da operação OLAP drill-down 129

130 8. Diagrama de sequência para processamento da operação OLAP roll-up 130

131 131 APÊNDICE D Este apêndice objetiva apresentar os comandos utilizados para coletar os resultados dos testes de desempenho. Para capturar o tempo total de cada consulta executada no PostgreSQL, foi utilizado o comando no terminal: \timing Para capturar o tempo do Mondrian e da ferramenta BJIn OLAP, foi utilizado o utilitário FireBug no navegador Mozilla FireFox. Em relação a coleta do espaço de armazenamento de tabelas no SGBD, foi utilizado o comando a seguir para cada tabela (tab): select relname, pg_size_pretty(pg_relation_size('tab')) from pg_class where relname = 'tab' Para coletar o espaço de armazenamento dos índices no sistema operacional Linux, foi utilizado o comando a seguir, no terminal da linha de comando para o diretório /bjin, que armazenou todos os índices: du /bjin --max-depth=1 h Na coleta da quantidade de memória utilizada pelo FastBit e PostgreSQL foi utilizado o seguinte código na linguagem shell script: #!/bin/bash while true; do date && /opt/ps_mem.py grep $1 done Portanto a chamada desse script é dada como segue. Onde processo é o nome do software que será coletado o consumo total de memória (por exemplo, ibis do FastBit) e arquivo é onde serão gravadas os segundos e o seu respectivo consumo de memória../memoria.sh processo >> arquivo.txt Para coletar o tempo da inserção das novas tuplas, no teste de atualizações, foi feito o seguinte código na linguagem shell script. Este programa executa os comandos SQL do arquivo file.sql e coleta o tempo total gravando-o em um arquivo. time(/opt/postgresql/9.0/bin/psql -d ssb1update2 -U postgres -f /opt/teste_update/file.sql) 2>> $1 E a chamada do programa foi:./update.sh arquivo.txt

132 132 ANEXO A Manual de utilização da ferramenta BJIn OLAP

133 Manual de utilização do BJIn OLAP

134 Sumário 1. Instalando o Tomcat Instalando o BJIn OLAP no Tomcat Configurando o BJIn OLAP Configurando o arquivo config.properties Configurando o arquivo log4j.properties Criando um arquivo XML e carregando no BJIn OLAP Criando um índice com o BJIn OLAP Executando uma Consulta (Query) Operações OLAP Alterando a granularidade da consulta Filtrando a consulta Mudando colunas para linhas e vice-versa Filtrando as colunas em páginas Demais opções Autocompletar Controle de usuários Atualizando o índice Deletando o índice Considerações Finais... 37

135 1. Instalando o Tomcat 7 1. Primeiro, baixe o arquivo "apache-tomcat tar.gz" do link: 2. Mova o programa para um diretório onde deseja instalar. No caso, usou-se o diretório /usr/share/. Para isso, o comando usado foi (considerando que o terminal estava no diretório que contém a pasta do tomcat): sudo mv apache-tomcat-7.0.8/ /usr/share/tomcat7 3. Para configurar os usuários do tomcat, é necessário modificar o arquivo tomcat-users.xml, no caminho: sudo gedit /usr/share/tomcat7/conf/tomcat-users.xml Neste caso, sugere-se o seguinte trecho (configurando usuario e senha como desejar): <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="manager"/> <role rolename="admin-gui"/> <role rolename="admin-script"/> <role rolename="admin"/> <user username="usuario" password="senha" roles="manager-gui,admingui,manager,admin,manager-script,admin-script"/> </tomcat-users> 4. Agora execute o tomcat: sudo /usr/share/tomcat7/bin/startup.sh 5. Com o tomcat ativado, abra um navegador e digite o endereço: Se tudo estiver certo, a seguinte imagem aparecerá: 1

136 Observação: Esse tutorial de instalação do tomcat foi retirado do site: 2

137 2. Instalando o BJIn OLAP no Tomcat 7 Para instalar o BJIn OLAP no tomcat, copie o arquivo BJInolap.war dentro da pasta BJIn OLAP Tool para o diretório: /usr/share/tomcat7/webapps/ Agora inicie o tomcat e clique em Manager App, conforme mostrado na figura: 3

138 Agora selecione o programa, conforme a figura: Se tudo estiver correto, o programa iniciará: 4

139 3. Configurando o BJIn OLAP 3.1. Configurando o arquivo config.properties Para conectar o BJIn OLAP ao Banco de Dados (no caso, PostgreSQL) é necessário definir o diretório do FastBit (ardea e ibis) e a localização de armazenamento dos índices. Para isso, configure o arquivo config.properties do diretório: /usr/share/tomcat7/webapps/bjinolap/web-inf Ele deve ser configurado da seguinte maneira: driver=driver DE CONEXÃO JDBC url=url DE CONEXÃO COM JDBC ardeapath=caminho DO ARDEA DO FASTBIT ibispath=caminho DO IBIS DO FASTBIT bjinolappath= CAMINHO ONDE SERÃO ARMAZENADOS OS ÍNDICES No caso, se configurou os atributos como: driver=org.postgresql.driver url=jdbc:postgresql://localhost:5432/spadawan ardeapath=/home/lucas/downloads/fastbit-ibis1.2.4/examples/ardea ibispath=/home/lucas/downloads/fastbit-ibis1.2.4/examples/ibis bjinolappath=default Observações: org.postgresql.driver é o nome do driver que conectará com o banco de dados, que no caso é o PostgreSQL; spadawan é o nome do banco de dados usado (exemplo); /home/lucas/downloads/fastbit-ibis1.2.4/ é o caminho onde o FastBit foi instalado. É recomendado a versão 1.2.4, ou mais atual, do FastBit para que o BJIn OLAP funcione corretamente. default é a configuração padrão, que salva os índices no diretório: o /bjin/[nome do índice criado] 5

140 3.2. Configurando o arquivo log4j.properties Esse arquivo, presente no mesmo diretório que o arquivo config.properties define a configuração de logs de BJIn OLAP. Ele possui a seguinte estrutura: #log4j.rootlogger=debug, stdout, file log4j.logger.bjinolap=debug, stdout, file log4j.logger.bjinolap.build=debug, file log4j.logger.bjinolap.query=debug, stdout #Disable an inheritance system for additivity log4j.additivity.bjinolap.query=false / true log4j.additivity.bjinolap.build=false / true log4j.appender.stdout=org.apache.log4j.consoleappender log4j.appender.stdout.layout=org.apache.log4j.patternlayout # Pattern to output the caller's file name and line number. log4j.appender.stdout.layout.conversionpattern=%d %5p [%t] (%F:%L) - %m%n log4j.appender.file=org.apache.log4j.rollingfileappender log4j.appender.file.file=/bjin/bjinolap.log log4j.appender.file.maxfilesize=100kb # Keep one backup file log4j.appender.file.maxbackupindex=1 log4j.appender.file.layout=org.apache.log4j.patternlayout log4j.appender.file.layout.conversionpattern=%d %5p [%t] (%F:%L) - %m%n No trecho em azul está especificado como será o log. Primeiramente é preciso especificar o nível de detalhamento, explicado na tabela a seguir: 6

141 TRACE DEBUG INFO WARN ERROR FATAL Fornece mensagens mais detalhadas que o nível DEBUG. Fornece mensagens detalhadas sobre o uso do programa. Fornece mensagens menos detalhadas, que apenas informam sobre o andamento das operações. Fornece mensagens apenas para situações potencialmente nocivas. Fornece mensagens dos erros que não impedem que o programa continue executando. Fornece mensagens apenas dos erros que fazer o programa abortar. Os níveis superiores abrangem os níveis inferiores, logo, se assumirmos o nível DEBUG, temos os níveis DEBUG, INFO, WARN, ERROR e FATAL. Após isso, temos os appenders (stdout e file), que direcionam a saída do log para um arquivo (file) e/ou para a saída padrão(stdout). O caminho onde estará o arquivo do log foi especificado em verde. Basta alterar esse caminho para armazenar o log em outro local. Em vermelho temos as configurações que habilitam ou desabilitam a hierarquia das categorias do log (true ou false). Em azul temos que o nível do detalhes log é definido nas categorias bjinolap.build, bjinolap.query e bjinolap. A categoria bjinolap abrange as categorias bjinolap.build e bjinolap.query, sendo assim, o nível de detalhamento e os appenders que forem definidos na categoria bjinolap afetará as outras categorias. Para exemplificar, se a categoria bjinolap tiver o nível de detalhamento TRACE, as categorias bjinolap.build e bjinolap.query também terão esse nível, independente do nível que for especificado para cada um deles. O mesmo acontece com os appenders. Assim, desabilitando a hierarquia (colocando false), o nível de detalhamento (e appenders) definido para a categoria bjinolap não interferirá nas outras categorias. 7

142 4. Criando um arquivo XML e carregando no BJIn OLAP Para gerar o índice, é necessário um arquivo XML de especificação do cubo de dados do data warehouse contendo os atributos a serem indexados. Para isso, aconselha-se utilizar o programa Mondrian Schema Workbench. Para criar o arquivo, será feito um exemplo passo a passo. Observação: Esse manual apenas exemplifica a criação de um XML para a base de dados usada, que no caso chama-se spadawan. Primeiramente, será necessário conectar-se com o banco de dados. Para isso, baixe o JDBC de seu banco de dados (no caso, PostgreSQL) e o coloque na pasta Drivers do Schema Workbench. Posteriormente, pode executar o programa. No caso do Ubuntu executa-se o seguinte comando no terminal (estando dentro da pasta do Schema Workbench): sh workbench.sh 8

143 Agora, montaremos um cubo de dados para o data warehouse spadawan. O primeiro passo é conectar-se com o banco de dados. Para isso, vá em: Options -> Connection... e configure a conexão. No exemplo: Após conectar-se com a Base de Dados, podemos iniciar a construção do cubo de dados. Vá em: File -> New -> Schema 9

144 Clique com o botão direito do mouse sobre o 'Schema' e adicione um cubo, atribuindo um nome a ele. 10

145 Agora adicione uma tabela de fatos a esse cubo, também clicando com o botão invertido sobre ele. Com um cubo de dados criado, é possível adicionar suas dimensões. O manual explicará como adicionar a dimensão Date, pois o restante é análogo. Clique com o botão invertido sobre o cubo e adicione uma nova dimensão. 11

146 Configure essa dimensão com a Foreign Key (FK) da tabela de fatos correspondente à dimensão criada. 12

147 Clicando com o botão invertido sobre a dimensão, crie uma hierarquia. No exemplo, usaremos apenas ano. Adicione a tabela correspondente a essa hierarquia. 13

148 No caso, como a dimensão é o ano, será usado a tabela DATE do spadawan. Agora, adiciona-se um Level a hierarquia. 14

149 Observação: Não se esqueça de adicionar o tipo de dado de cada Level (number, integer,...). dimensão. Agora volte na hierarquia e coloque a Primary Key (PK) da tabela referente à 15

150 Siga esses mesmos passos e crie mais duas dimensões. A próxima figura mostra como ficou o schema. Lembrando que pelo menos uma das dimensões deve conter um Level sendo um atributo da tabela DATE. Agora precisamos adicionar uma Medida (Measure) ao cubo. Clique com o botão invertido sobre o cubo e adicione uma medida. 16

151 Pronto, o cubo de dados exemplo está pronto. Salve o documento XML e você terá o arquivo para usar no BJIn OLAP. Assim que terminar de gerar o arquivo XML, apenas carregue-o no programa: 17

152 5. Criando um índice com o BJIn OLAP Após carregar um arquivo XML, vamos criar o índice. Na parte de Create Index, selecione o arquivo xml carregado, dê um nome para o índice e forneça o nome do usuário e senha do banco de dados, para que o programa possa acessar o data warehouse: Neste caso, é possível criar o índice sobre uma visão materializada. Para isso, selecione a opção conforme a imagem abaixo: 18

153 Além disso, é possível habilitar o índice para update, marcando a opção Enable Update. Se o índice permitir update, será criada uma tabela temporária e uma trigger na base de dados para armazenar as alterações na tabela de fatos. Após isso, crie o índice: 19

154 6. Executando uma Consulta (Query) Para realizar uma consulta, na parte de Query, selecione o índice em que as consultas serão feitas: Caso o índice ainda esteja em construção, o BJIn OLAP exibirá mensagens informando qual o status da criação do índice, como mostrado nas figuras: 20

155 21

156 Após terminada a criação do índice, será solicitado os apelidos (aliases) das colunas, para realizar as consultas (apenas na primeira vez). Feito isso, é possível executar consultas sobre o índice. A próxima imagem exemplifica uma consulta: 22

157 Para auxiliar na escrita da consulta existe no lado esquerdo do campo da consulta, a hierarquia completa do cubo de dados gerada pelo Schema Workbench: Assim, foi feita a consulta exemplo sobre a base de dados Spadawan. A resposta da consulta aparece abaixo: 23

158 Também é possível visualizar o resultado em forma de gráficos, apenas clicando nos botões Show chart (exibe o gráfico geral da tabela), Show column totals chart (exibe um gráfico com apenas o eixo das colunas da tabela) ou Show row totals chart (exibe um gráfico com apenas o eixo das linhas da tabela) que estão abaixo do resultado da consulta. Esses gráficos são baseados na tabela resultado, ou seja, se for aplicado filtros na tabela resultado, o gráfico também será alterado. Os filtros são explicados na seção

159 25

160 7. Operações OLAP 7.1. Alterando a granularidade da consulta É possível mudar a granularidade da consulta fazendo operações Roll-up e Drill-down. Para isso, basta selecionar os atributos e clicar nos botões Submit Roll-up ou Submit Drill-down, dependendo do caso. As imagens a seguir ilustram como é feito: Neste caso, fazemos um Roll-up do atributo c_nation (Países) para c_region (Continentes). A próxima imagem gera o resultado. 26

161 Como se pode perceber, as linhas da tabela, que eram países, foram agrupadas em continentes. Um exemplo contrário é fazer um Drill-down de c_region para c_nation (clicando no botão Submit Drill-down ). No caso, ele mostra os países (c_nation), mas ainda os agrupa em Continentes (c_region). O restante é análogo, selecione os atributos que se deseja fazer Roll-up ou Drill-down e clique no botão Submit Roll-up ou Submit Drill-down. 27

162 7.2. Filtrando a consulta Também é possível filtrar os resultados da coluna, simplesmente clicando sobre a coluna desejada. A figura mostra como isso é feito no exemplo: 28

163 7.3. Mudando colunas para linhas e vice-versa É possível mudar os eixos das colunas e linhas simplesmente clicando e arrastando, como mostram as figuras: 29

164 7.4. Filtrando as colunas em páginas Similar à seção anterior, é possível filtrar os resultados por página. Por exemplo, podemos ver o resultado de cada ano arrastando a coluna d_year conforme a figura: 30

165 31

166 8. Demais opções 8.1. Autocompletar A ferramenta fornece a opção de autocompletar uma palavra simplesmente usando o comando CTRL + ESPAÇO. A figura a seguir mostra um exemplo: 8.2. Controle de usuários A ferramenta BJIn OLAP também inclui um controle de permissões para diferentes usuários. Normalmente, no caminho default (explicado na seção 3) é possível colocar um arquivo XML (user.xml) para especificar as permissões de cada usuário. Caso uma permissão não for declarada, assume-se que o usuário não tem essa permissão (false). Essas permissões são: Permissão canuploadxml Descrição True para permitir o carregamento de arquivos XML descrevendo o cubo de dados, e false para negar. 32