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
Desenvolvimento de Sistemas
Salto, SP, Fevereiro de 2012.
em
Análise
e
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
Desenvolvimento de Sistemas
Orientador:
Prof. Thiago Luís Lopes Siqueira
São Paulo, SP, Fevereiro de 2012.
Análise
e
Dedico esta monografia aos meus queridos pais, que sempre me
apoiaram em qualquer momento, por qualquer motivo e razão
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 2011.
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 2011.
À 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.
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
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
LISTA DE FIGURAS
Figura 1. Representação de um hipercubo de dados ................................................................ 17
Figura 2. Esquema estrela para uma aplicação de varejo, adaptada de [20] ............................ 19
Figura 3. Esquema floco de neve normalizando a hierarquia de Supplier da Figura 2 ............ 19
Figura 4. Consultas OLAP sobre o hipercubo de dados da Figura 1 ....................................... 20
Figura 5. Operação drill-down e roll-up da hierarquia entre os atributos da dimensão
Customer................................................................................................................................... 21
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 .................................................... 21
Figura 7. À esquerda, resultado da consulta, e à direita, uma operação pivoting ..................... 22
Figura 8. Consultas SQL e MDX equivalentes ........................................................................ 24
Figura 9. Resultado das consultas SQL e MDX da Figura 8 .................................................... 24
Figura 10. Esquema estrela e uma consulta usando a junção estrela ....................................... 26
Figura 11. Visão fragmentada verticalmente ............................................................................ 27
Figura 12. Resultado de uma consulta executada sobre a visão fragmentada verticalmente ... 27
Figura 13. Visão materializada ................................................................................................. 28
Figura 14. Resultado de uma consulta executada sobre a visão materializada ........................ 29
Figura 15. Índices bitmap de junção sobre uma visão fragmentada verticalmente .................. 30
Figura 16. Índices bitmap de junção sobre uma visão materializada ....................................... 30
Figura 17. Consulta sobre índices bitmap de junção ................................................................ 31
Figura 18. Três registros para serem incluídos no DW ............................................................ 32
Figura 19. Diagrama de caso de uso da ferramenta BJIn OLAP .............................................. 35
Figura 20. Fluxos de dados para construção de índices bitmap de junção ............................... 38
Figura 21. Tela de construção de índices bitmap de junção ..................................................... 39
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 .................................... 43
Figura 24. Escrita da consulta com recurso de realce e complemento automático .................. 44
Figura 25. Resultado da consulta e operações OLAP disponíveis ........................................... 44
Figura 26. Operação OLAP slice-and-dice .............................................................................. 45
Figura 27. Operação OLAP slice-and-dice completa ............................................................... 46
Figura 28. Operação pivoting sobre a Figura 27 ...................................................................... 47
Figura 29. Fluxo de operações para atualização de índices bitmap de junção ......................... 51
Figura 30. Tela de atualização de índices bitmap de junção .................................................... 51
Figura 31. Fluxo de operações para exclusão de índices bitmap de junção ............................. 52
Figura 32. Tela de exclusão de índices bitmap de junção ........................................................ 53
Figura 33. Exemplo de arquivo de configuração da ferramenta BJIn OLAP........................... 54
Figura 34. Exemplo de arquivo log4j.properties para registro de logs..................................... 55
Figura 35. Arquivo de log nativo gerado após uma operação de construção de índice ........... 56
Figura 36. Exemplo de registro do log4j para a operação de construção de índice ................. 57
Figura 37. Exemplo de documento user.xml para controle de usuários ................................... 59
Figura 38. Modelos das consultas do SSB [20] ........................................................................ 61
Figura 39. Consultas do grupo Q3 adaptadas de [20] para operações drill-down e roll-up ..... 62
Figura 40. Consultas do grupo Q4 para operações drill-down e roll-up [20] .......................... 62
Figura 41. Esquema estrela do DW webpide [41] .................................................................... 63
Figura 42. Consultas sobre a base de dados webpide [41] ....................................................... 63
Figura 43. Tempo decorrido por cada configuração para processar as consultas do SSB sobre
a base de dados DW1................................................................................................................ 65
Figura 44. Quantidade de vetores de bits disponíveis para cada consulta do SSB sobre DW166
Figura 45. Espaço requerido para armazenamento de índices bitmap de junção e VFV ......... 67
Figura 46. Resultados das consultas sobre a base de dados webpide ....................................... 69
Figura 47. Tempo decorrido na execução das consultas do SSB na base de dados DW10 ..... 71
Figura 48. Tempo decorrido para processar as consultas do SSB sobre a base de dados DW10
usando visões materializadas .................................................................................................... 72
Figura 49. Tempo adicionado pelas ferramentas OLAP em relação ao seu mecanismo de
consulta ..................................................................................................................................... 73
Figura 50. Espaço requerido total considerando a base de dados DW10 ................................. 74
Figura 51. Tempo decorrido para visualização final do usuário dos resultados das consultas do
grupo Q3 ................................................................................................................................... 77
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 DW10 ................................................................ 79
Figura 53. Uso de memória para a operação OLAP roll-up sobre a base de dados DW1 ....... 80
Figura 54. Uso de memória para a consulta Q3.4 processada sobre a base de dados DW10... 81
Figura 55. Uso de memória para a consulta Q3.4 usando visão materializada sobre a base de
dados DW10 ............................................................................................................................. 82
Figura 56. Portabilidade e o processamento de consultas sobre a base de dados DW1 ........... 83
Figura 57. Portabilidade e o processamento de consultas para o DW10 .................................. 84
Figura 58. Testes em relação a atualizações de índices bitmap de junção ............................... 85
LISTA DE TABELAS
Tabela 1. Compatibilidade da ferramenta BJIn OLAP............................................................. 36
Tabela 2. Fórmulas usadas pela ferramenta BJIn OLAP.......................................................... 40
Tabela 3. Variáveis correspondentes das fórmulas da Tabela 2 ............................................... 40
Tabela 4. Parâmetros e variáveis locais de Algoritmo 1 .......................................................... 49
Tabela 5. Descrição das propriedades de configuração da ferramenta BJIn OLAP................. 54
Tabela 6. Permissões para controle de usuários ....................................................................... 58
Tabela 7. Características dos grupos de consultas da Figura 36 .............................................. 61
Tabela 8. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1
utilizando o grupo Q3 do SSB .................................................................................................. 68
Tabela 9. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW1
utilizando o grupo Q4 do SSB .................................................................................................. 68
Tabela 10. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10
usando o grupo Q3 do SSB ...................................................................................................... 75
Tabela 11. Operações OLAP drill-down e roll-up executadas sobre a base de dados DW10
usando o grupo Q4 do SSB ...................................................................................................... 75
Tabela 12. Linhas e colunas que compuseram as tabelas cruzadas .......................................... 76
Tabela 13. Quantidade de novos vetores de bits criados para cada atributo indexado............. 84
Tabela 14. Comparação de tecnologias existentes e a ferramenta BJIn OLAP ....................... 87
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
SUMÁRIO
1
INTRODUÇÃO ----------------------------------------------------------------------------------- 13
1.1
Contexto e Motivação ------------------------------------------------------------------------------------------------ 13
1.2
Contribuições ---------------------------------------------------------------------------------------------------------- 14
1.3
Organização da Monografia ---------------------------------------------------------------------------------------- 15
2
FUNDAMENTAÇÃO TEÓRICA ------------------------------------------------------------- 17
2.1
Data Warehouse ------------------------------------------------------------------------------------------------------- 17
2.2
OLAP -------------------------------------------------------------------------------------------------------------------- 19
2.3
Processamento de Consultas ---------------------------------------------------------------------------------------- 24
2.3.1
Junção Estrela --------------------------------------------------------------------------------------------25
2.3.2
Fragmentação Vertical dos Dados --------------------------------------------------------------------26
2.3.3
Visão Materializada -------------------------------------------------------------------------------------27
2.3.4
Índice Bitmap de Junção --------------------------------------------------------------------------------29
2.4
Processamento de Atualizações------------------------------------------------------------------------------------- 31
3
UMA FERRAMENTA OLAP BASEADA NO ÍNDICE BITMAP DE JUNÇÃO -- 34
3.1
O Projeto---------------------------------------------------------------------------------------------------------------- 34
3.2
Construindo Índices Bitmap de Junção -------------------------------------------------------------------------- 36
3.3
Consultando Índices Bitmap de Junção -------------------------------------------------------------------------- 42
3.3.1
Slice-and-Dice --------------------------------------------------------------------------------------------45
3.4
3.3.2
Drill-down e Roll-up ------------------------------------------------------------------------------------46
3.3.3
Pivoting ----------------------------------------------------------------------------------------------------46
Atualizando Índices Bitmap de Junção --------------------------------------------------------------------------- 47
3.4.1
O Gatilho --------------------------------------------------------------------------------------------------48
3.4.2
Fluxos de Dados------------------------------------------------------------------------------------------50
3.5
Excluindo Índices Bitmap de Junção ------------------------------------------------------------------------------ 52
3.6
Outras Funcionalidades ---------------------------------------------------------------------------------------------- 53
3.6.1
Parâmetros de Configuração ---------------------------------------------------------------------------53
3.6.2
Registro de Log ------------------------------------------------------------------------------------------54
3.6.3
Permissões e Privilégios --------------------------------------------------------------------------------57
4
TESTES DE DESEMPENHO EXPERIMENTAIS --------------------------------------- 60
4.1
Configurações dos Testes -------------------------------------------------------------------------------------------- 60
4.2
Comparando a Ferramenta BJIn OLAP com Visões Fragmentadas Verticalmente -------------------- 64
4.3
Operações Drill-down e Roll-up ------------------------------------------------------------------------------------ 67
4.4
Consultando a Base de Dados Real webpide --------------------------------------------------------------------- 69
4.5
Investigação Sobre o Aumento do Volume de Dados e o Uso de Visões Materializadas ---------------- 69
4.5.1
As Consultas do SSB ------------------------------------------------------------------------------------70
4.5.2
Operações Drill-down e Roll-up ----------------------------------------------------------------------74
5
UMA AVALIAÇÃO EXPERIMENTAL ESTENDIDA ----------------------------------- 76
5.1
Apresentando os Resultados das Consultas ao Usuário ------------------------------------------------------- 76
5.2
Uso de Memória ------------------------------------------------------------------------------------------------------- 79
5.3
Portabilidade e o Desempenho no Processamento de Consultas --------------------------------------------- 82
5.4
Atualizações de Índices Bitmap de Junção ----------------------------------------------------------------------- 84
6
TRABALHOS CORRELATOS --------------------------------------------------------------- 86
7
CONCLUSÕES E TRABALHOS FUTUROS -------------------------------------------- 88
8
REFERÊNCIAS ---------------------------------------------------------------------------------- 90
APÊNDICE A ------------------------------------------------------------------------------------------- 94
APÊNDICE B ----------------------------------------------------------------------------------------- 106
APÊNDICE C ----------------------------------------------------------------------------------------- 122
APÊNDICE D ----------------------------------------------------------------------------------------- 131
ANEXO A ---------------------------------------------------------------------------------------------- 132
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
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
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

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
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
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
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 2
2.2
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
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
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
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
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 1998.
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
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 8
2.3
Processamento de Consultas
Nesta seção serão apresentadas as formas mais comuns para processar consultas sobre
DW. Na seção 2.3.1 é 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
Nas seções 2.3.2, 2.3.3 e 2.3.4 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.
2.3.1 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
(a) Esquema estrela (Figura 2) com realce para
(b) Consulta SQL sobre o esquema estrela
junções e atributos selecionados da consulta
(Figura 2) com realce para as junções
Figura 10. Esquema estrela e uma consulta usando a junção estrela
2.3.2 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 é Π
s_region, c_nation, s_nation, d_year, lo_revenue
(Customer
Lineorder
Supplier
c_region,
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
(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
2.3.3 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
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, GSUM(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
(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
2.3.4 Í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 Π
Supplier
c_region, s_region, c_nation, s_nation, d_year, lo_revenue
(Customer
Lineorder
Date), mostrado na Figura 11a. A Figura 15 mostra a visão fragmentada
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
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
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 1993.
Tupla 1 (t1)
lo_orderkey
lo_linenumber
lo_partkey
lo_custkey
lo_orderdate
lo_suppkey
lo_revenue
78171831
15
5
23087
550
287
8190
…
lo_shipmode
AIR
Tupla 2 (t2)
c_custkey
c_name
c_phone
c_mktsegment
c_address
c_city
c_nation
c_region
30001
CUBA001
+5378671374
AUTOMOBILE
CUBA01
HAVANA
CUBA
AMERICA
Tupla 3 (t3)
lo_orderkey
lo_linenumber
lo_partkey
lo_custkey
lo_orderdate
lo_suppkey
lo_revenue
78171832
16
3
30001
550
287
7910
…
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 586326 (578136+8190). 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 578136 deverá ser substituído de um bit 1 para 0. Além
disso, um vetor de bits para o valor 586326 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
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
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
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
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
Sistema Operacional
SGBD
Navegador
3.2
Nome do Software
Versão Mínima
Windows
XP
Linux
-
PostgreSQL
8.3
MySQL
5.4
IBM DB2®
9.7
Opera
9.2
Chrome
10
Firefox
2.0
Internet Explorer
8
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
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 (CommaSeparated 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 3.6.2.
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
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 (F1), e quantos arquivos serão criados (F2). Em seguida, é calculado o
número de diretórios em que os arquivos do FastBit serão armazenados (F3). 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 (F4).
40
Tabela 2. Fórmulas usadas pela ferramenta BJIn OLAP
Fórmula
Objetivo
F1 N = T / (RAM / FASTBIT_DIVISOR)
Definir o número de linhas máximo de
cada arquivo CSV
F2 L = Tn / N
Definir a quantidade total de arquivos
CSV
F3 P = (L * S) / (RAM / FASTBIT_DIVISOR)
Definir a quantidade de diretórios
F4 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
FASTBIT_DIVISOR
Tamanho em MB da memória primária do servidor
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
Tn
Número de tuplas da tabela temporária
P
Quantidade total de diretórios
S
Tamanho em MB do maior arquivo CSV criado
C
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 coli, 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
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
<FastBitColumns timestamp="1324159659666" 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="1325508594611"
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
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 <= 1997”. 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é
1997. 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
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
Realce
automático
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
3.3.1 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
Figura 27. Operação OLAP slice-and-dice completa
3.3.2 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.
3.3.3 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
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 27
3.4
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
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 3.4.1 o gatilho é discutido e apresentado o gatilho utilizado pela ferramenta
BJIn OLAP. Por fim, na seção 3.4.2 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.
3.4.1 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
{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 = 23087 e SELECT
c_region FROM Customer WHERE c_custkey = 23087 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 cm. 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.
Tabela 4. Parâmetros e variáveis locais de Algoritmo 1
Parâmetro
ou variável local
F
T
ti
aj
D
dk
M
Tabela
Record
value
C
NEW
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 ti
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
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, aj, ti, dk, valor, C, NEW
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
registro  NULL
para cada ti em T
para cada aj em ti
para cada dk em D
se aj  dk então
C  tabela.getColumns()  dk.getColumns()
para cada cm em C
valor  executar(SELECT cm FROM dk WHERE dk.pk = ti.aj)
registro.add(valor)
fim-para
fim-se
fim-para
se aj  M então registro.add(NEW.aj)
fim-para
se registro ≠ NULL então
executar(INSERT INTO tabela VALUES registro.getValues())
registro  NULL
fim-se
fim-para
3.4.2 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
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
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
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 3.6.1 descreve os parâmetros de
configuração essenciais para que a ferramenta BJIn OLAP seja executada. Na seção 3.6.2 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.
3.6.1 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
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)
Os detalhes da conexão JDBC com o SGBD. Sendo o SGBD, porta de
url
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
3.6.2 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
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
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 11656 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 13542 ms
Figura 35. Arquivo de log nativo gerado após uma operação de construção de índice
57
….
2011-12-18 13: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\1324221493778.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"
2011-12-18 13:18:14,446
INFO [http-bio-8080-exec-11]
(CreateIndex.java:283) - creating index "my_index"
2011-12-18 13:18:17,076 DEBUG [main] (BitmapJoinIndex.java:518) - Index:
my_index. COMMAND EXISTS TABLE: select count(*) from pg_class where
relname ilike 'tempTable';
2011-12-18 13:18:17,089
INFO [main] (BitmapJoinIndex.java:598) - Index:
my_index. Temporary table name to update is "tempTable1"
2011-12-18 13: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
3.6.3 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
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
canUploadXml
canCreateIndex
canUpdateIndex
canDeleteIndex
superUser
Descrição
True para permitir o carregamento de documentos XML descrevendo o
cubo de dados, e false para revogar.
True para permitir a criação de índices bitmap de junção e false para
revogar.
True para dar permissão de atualização de índices bitmap de junção nos
índices listados na tag indices e false para revogar.
True para dar permissão de remoção de índices bitmap de junção nos
índices listados na tag indices e false para revogar.
True para declarar como um superusuário e false para revogar.
59
Figura 37. Exemplo de documento user.xml para controle de usuários
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
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];
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;
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;
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?
Q1
Q2
Q3
Q4
1
3
3
4
3
2
3
3
Não
Sim
Sim
Sim
Não
Sim
Sim
Sim
Atributos para
serem indexados
4
5
7
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 3.345.588 na base de dados DW1, e a cardinalidade
5.841.774 na base de dados DW10.
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.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.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.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
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 830.000 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
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 2.6.35.6-45.fc14.x86_64, e foi instalado os seguintes softwares:
FastBit 1.2.3, PostgreSQL 9.0.4, JDK 1.6.0.4, Apache Tomcat 7.0.12; e
Duas plataformas distintas foram utilizadas devido ao custo das operações envolvidas.
Ambas as plataformas P1 tiveram OAT 2.8, Mondrian Schema Workbench 3.2.0 e o servidor
OLAP Mondrian 3.2.1.13885 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
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
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 1.386 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 5.571 MB, e os índices bitmap de junção ocuparam uma soma de
6.060 MB de espaço de armazenamento. Comparado às visões, os índices requereram 8,8%
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
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
Grupo
Q3
Consulta
Q3.1
Q3.2
Q3.3
Q3.4
Soma Q3
Redução (%)
Drill-down (segundos)
Mondrian
BJIn OLAP
14,4118
5,1134
38,6804
3,3528
0,2420
0,4360
2,4238
0,3872
55,758
9,2894
83,34%
Roll-up (segundos)
Mondrian
BJIn OLAP
3,4350
3,0586
40,9222
1,2140
4,1530
2,6374
14,6500
3,7018
63,1602
10,6118
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
Grupo
Q4
Consulta
Q4.1
Q4.2
Q4.3
Soma Q4
Redução (%)
Drill-down (segundos)
Mondrian
BJIn OLAP
17,8840
4,9434
6,4412
3,1622
14,7292
3,1420
39,0544
11,2476
71,20%
Roll-up (segundos)
Mondrian
BJIn OLAP
3,9330
1,6458
8,6654
5,4604
23,7316
5,6588
36,3300
12,7650
64,86%
69
4.4
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
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 4.5.1 os
testes de desempenho consideram todas as consultas do SSB. Já na seção 4.5.2 enfoca-se o
desempenho no processamento das operações drill-down e roll-up.
4.5.1 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
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
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
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 8.673 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 56.683
MB e as visões fragmentadas verticalmente requereram 55.801 MB. Para as visões
materializadas mantidas pelo SGBD, o espaço requerido foi de 3.931 MB e para os índices
construídos sobre as visões materializadas foram necessários 3.905 MB. As visões
fragmentadas verticalmente levaram 4.345 segundos para sua construção, enquanto as visões
materializadas levaram 65.141 segundos para serem construídas. Os índices bitmap de junção
demoraram 10.997 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
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 DW10
4.5.2 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
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
4.5.1. 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
Grupo
Q3
Drill-down (segundos)
Consulta Mondrian+VM BJIn OLAP
Q3.1
19,9432
4,6154
Q3.2
6,5180
0,7516
Q3.3
14,9670
0,2694
Q3.4
1,8420
0,2996
43,2702
5,9360
Soma
86,28%
Redução
Roll-up (segundos)
Mondrian+VM BJIn OLAP
5,7080
3,5462
2,0688
0,5218
2,1906
0,9744
33,2721
1,9338
43,2386
6,9762
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
Grupo
Q4
Drill-down (segundos)
Consulta Mondrian+VM BJIn OLAP
Q4.1
108,2348
7,9038
Q4.2
57,6974
5,4272
Q4.3
58,7136
3,5386
224,6458
16,8696
Soma
92,49%
Redução
Roll-up (segundos)
Mondrian+VM BJIn OLAP
46,0644
5,7180
67,8728
5,4370
109,9106
4,0550
223,8478
15,2100
93,20%
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 10.10 com Kernel 2.6.3527.x86_64 e com os seguintes softwares: FastBit 1.2.4, PostgreSQL 9.0, JDK
1.6.0_24 e Apache Tomcat 7.0.14.
5.1
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 3.6.15 e o
utilitário FireBug 1.7.3.
Tabela 12. Linhas e colunas que compuseram as tabelas cruzadas
Consulta
Q3.1
Q3.2
Q3.3
Q3.4
Colunas
c_nation, s_nation, d_year, sum(lo_revenue)
c_city, s_city, d_year, sum(lo_revenue)
c_city, s_city, d_year, sum(lo_revenue)
c_city, s_city, d_year, sum(lo_revenue)
Número de Linhas
DW1
DW10
150
150
596
600
24
24
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
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
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
(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 DW10
5.2
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

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
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
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 DW10
5.3
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
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
Figura 57. Portabilidade e o processamento de consultas para o DW10
5.4
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, 600.000 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
d_year
s_nation
p_category
lo_revenue
lo_supplycost
s_region
c_region
p_mfgr
Novos vetores de bits
2
3
5
0
0
0
0
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
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
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 5.841.774. 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
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
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



















Mondrian FastBit




BJIn OLAP
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
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
Como trabalhos futuros pretende-se registrar formalmente a ferramenta BJIn OLAP
como Software Livre, e o seu portal na internet (http://gbd.dc.ufscar.br/bjinolap) 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
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. 3270-3275.
[2] WREMBEL, R.; KONCILIA, C. Data Warehouses and OLAP: Concepts,
Architectures and Solutions. IRM Press, 2006. 332 p.
[3] KIMBALL, R.; ROSS, M. The Data Warehouse Toolkit: O guia completo para
modelagem dimensional. 2. ed. Rio de Janeiro: Campus, 2002. 494 p.
[4] INMON, H. Building the Data Warehouse. 4. ed. Wiley, 2002. 476 p.
[5] CIFERRI, C. D. A. Distribuição dos dados em ambientes de data warehousing. 2002.
263 f. Tese (Doutorado em Ciência da Computação) - Centro de Informática,
Universidade Federal de Pernambuco, Recife, PE, Brasil, 2002.
[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. 287-297.
[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.
65-74, ACM, 1997.
[8] SIQUEIRA, T. L. L. SB-index: Um Índice Espacial baseado em Bitmap para Data
Warehouse Geográfico. 2009. 118f. Dissertação (Mestrado em Ciência da Computação) Departamento de Computação, Universidade Federal de São Carlos, São Carlos, SP,
Brasil, 2009.
[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 97-104.
[10]
HARINARAYAN, V.; RAJARAMAN, A.; ULLMAN, J. D. Implementing data cubes
efficiently. Special Interest Group on Management of Data (SIGMOD Record), v. 25, p.
205-216, ACM, 1996.
[11]
DELLATRECHE, L.; WOAMENO Y. Dimension table driven approach to referential
partition relational data warehouses. ACM FOURTEENTH INTERNATIONAL
91
WORKSHOP ON DATA WAREHOUSING AND OLAP (DOLAP), 12., 2009, New
York: ACM, Anais… 2009, p 9-16.
[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. 479-494, SBC, 2011.
[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. 11-23.
[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, 2006. p. 157-178.
[15]
CHAN, C. Y. Bitmap Index. In: LIU, L; OZSU, M. T. Encyclopedia of Database
Systems. Springer, 2009, p. 244-248.
[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, 1995.
[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. 105-116.
[18]
MONDRIAN pentaho analysis. Disponível em: http://mondrian.pentaho.com/. Acesso
em: Fev. 2012.
[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. 237-252, Springer Berlin /
Heidelberg, 2009.
[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... 2011, p. 911-926.
[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... 2011, p. 13-18.
[23]
JPIVOT. Disponível em: http://jpivot.sourceforge.net/. Acesso em: Fev. 2012.
92
[24]
PENTAHO
MONDRIAN
documentation.
Disponível
em:
http://mondrian.pentaho.com/documentation/workbench.php. Acesso em: Fev. 2012.
[25]
WHITEHORN, M.; ZARE, R.; PASUMANSKY, M. Fast Track to MDX. Springer,
2005. 310 p.
[26]
WU, K. FastBit: an efficient indexing technology for accelerating data-intensive
science. Journal of Physics: Conference Series. v. 16, p. 556-560, 2005.
[27]
FASTBIT an efficient compressed bitmap index technology. Disponível em:
http://sdm.lbl.gov/fastbit/. Acesso em: Fev. 2012.
[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. 312.
[29]
CANAHUATE, G. Update Conscious Bitmap Indexes. In: CANAHUATE, G.
Enhanced Bitmap Indexes for Large Scale Data Management. 2009. p. 141-163.
Dissertação (Mestrado em Ciência da Computação) - The Ohio State University, EUA,
2009.
[30]
GUEDES, G.T.A. UML: Uma abordagem prática. ed. 1. Novatec, 2004. 320 p.
[31]
DEITEL, H. M.; DEITEL, P. J. Java: Como Programar. ed. 6. Prentice Hall, 2005.
1152 p.
[32]
PRESSMAN, R. S. Engenharia de Software. ed. 6. Bookman, 2006. 752 p.
[33]
METSKER, S. J. Padrões de projeto em Java. Bookman, 2004. 407 p.
[34]
KURNIAWAN, B. Java para a web com Servlets, JSP e EJB. ed. 1. Ciência
Moderna, 2002. 832 p.
[35]
OAT Open-link Ajax Toolkit Framework. Disponível em: http://oat.openlinksw.com/.
Acesso em: Fev. 2012.
[36]
CODEMIRROR 2. Disponível em: http://codemirror.net/. Acesso em: Fev. 2012.
[37]
JQUERY the write less, do more. Disponível em: http://jquery.com/. Acesso em: Fev.
2012.
[38]
ZAKAS, N. C.; McPEAK, J.; FAWCETT, J. Professional Ajax (Programmer to
Programmer). 2 ed. Wrox, 2009. 624 p.
[39]
CROCKFOD, D. JavaScript: The Good Parts. Yahoo Press, 2008. 176 p.
[40]
GUPTA, S. Pro Apache log4j. ed. 2. APress, 2007. 224 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
In: XVI JORNADAS DE JÓVENES INVESTIGADORES.16., 2008, Chile, Anais...
2008, p. 1016-1025.
[42]
LANE, P. Oracle® Database Data Warehousing Guide 11g Release 1 (11.1). 2010.
Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28313.pdf.
[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. 1299-1316.
[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. 165-205, Springer, 2011.
[45]
MANIATIS, S. The Case for Mobile OLAP. In: INTERNATIONAL PERVASIVE
INFORMATION MANAGEMENT PIM ’04 (EDBT WORKSHOPS), 2004, Grécia,
Anais... 2004, p. 405-414.
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
Descrição
Usuário
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.
Mondrian Schema Workbench
Software que constrói documento XML para o ator Usuário com a especificação validada do cubo de
dados de um data warehouse.
SGBD
Sistema Gerenciador de Banco de Dados responsável por manter data warehouses.
FastBit
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
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
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
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
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
UC001 – Manter Índices Bitmap de Junção
MSG08 - Índice excluído com sucesso.
MSG09 - O índice não possui atualizações disponíveis.
Detalhamento dos campos.
Legenda
O - Preenchimento obrigatório | A - Preenchimento automático pelo sistema | E - Valor do atributo pode ser editado
Campo
O
Documento XML
x
Nome do Índice
A
E
Tipo
x
x
Texto
Usuário do SGBD
x
x
Texto
Senha do SGBD
x
x
Texto
x
Booleano
x
Booleano
x
Booleano
XML
Criar Índice sobre uma Visão Materializada
Criação Índice com suporte a Atualizações
Atributo do XML
x
Tamanho
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
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.
b.
A ferramenta deverá apresentar os seguintes dados referentes ao índice:
1.
Estrutura em Árvore dos Atributos do Índice;
2.
Nome do Índice;
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
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
Nome do Índice
x
x
Texto
Estrutura em Árvore dos Atributos do Índice
x
x
Árvore
Consulta
x
Tabela Cruzada
x
Gráficos
E
x
Tipo
Texto
x
Tabela
x
Gráfico
Tamanho
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
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.
ii.
Nome do Atributo;
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.
ii.
Nome do Atributo;
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
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
Nome do Atributo
x
x
Texto
Descendente
x
x
Texto
Ancestral
x
x
Texto
Valor
x
x
Texto
Tamanho
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
108
2. Diagrama de Classe 1 – Manter Índices Bitmap de Junção
109
3. Diagrama de Classe 2 – Consultar Índices Bitmap de Junção e Processar
Operações OLAP
110
4. Diagrama de Classe – br.bjinolap.controller
111
5. Diagrama de Classe – br.bjinolap.model.bean
112
6. Diagrama de Classe – br.bjinolap.bitmapjoinindex
113
7. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.column
114
8. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.executor
115
9. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.map
116
10. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.query
117
11. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.util
118
12. Diagrama de Classe – br.bjinolap.model.bitmapjoinindex.validate
119
13. Diagrama de Classe – br.bjinolap.model.command
120
14. Diagrama de Classe – br.bjinolap.model.connection
15. Diagrama de Classe – br.bjinolap.model.user
121
16. Diagrama de Classe – br.bjinolap.model.xml
17. Diagrama de Classe – br.bjinolap.thread
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
124
2. Diagrama de sequência da construção de índices bitmap de junção
125
3. Diagrama de sequência da atualização de índices bitmap de junção
126
4. 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
128
6. 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
130
8. Diagrama de sequência para processamento da operação OLAP roll-up
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 1.7.3 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 600.000 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
postgres -f /opt/teste_update/file.sql) 2>> $1
E a chamada do programa foi:

./update.sh arquivo.txt
-U
132
ANEXO A
Manual de utilização da ferramenta BJIn OLAP
Manual de utilização do
BJIn OLAP
Sumário
1.
Instalando o Tomcat 7 ....................................................................................................... 1
2.
Instalando o BJIn OLAP no Tomcat 7 ............................................................................. 3
3.
Configurando o BJIn OLAP ............................................................................................... 5
3.1.
Configurando o arquivo config.properties ............................................................... 5
3.2.
Configurando o arquivo log4j.properties ................................................................. 6
4.
Criando um arquivo XML e carregando no BJIn OLAP ................................................ 8
5.
Criando um índice com o BJIn OLAP............................................................................ 18
6.
Executando uma Consulta (Query) ............................................................................... 20
7.
Operações OLAP.............................................................................................................. 26
7.1.
Alterando a granularidade da consulta ................................................................. 26
7.2.
Filtrando a consulta .................................................................................................. 28
7.3.
Mudando colunas para linhas e vice-versa .......................................................... 29
7.4.
Filtrando as colunas em páginas ........................................................................... 30
Demais opções ................................................................................................................. 32
8.
8.1.
Autocompletar ........................................................................................................... 32
8.2.
Controle de usuários ................................................................................................ 32
9.
Atualizando o índice ......................................................................................................... 35
10.
Deletando o índice ....................................................................................................... 36
11.
Considerações Finais .................................................................................................. 37
1. Instalando o Tomcat 7
1. Primeiro, baixe o arquivo "apache-tomcat-7.0.6.tar.gz" do link:

http://tomcat.apache.org/download-70.cgi
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:

http://127.0.0.1:8080/
Se tudo estiver certo, a seguinte imagem aparecerá:
1
Observação: Esse tutorial de instalação do tomcat foi retirado do site:
http://diegobenna.blogspot.com/2011/01/install-tomcat-7-in-ubuntu-1010.html
2
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
Agora selecione o programa, conforme a figura:
Se tudo estiver correto, o programa iniciará:
4
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
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
TRACE
Fornece mensagens mais detalhadas que o nível DEBUG.
DEBUG
Fornece mensagens detalhadas sobre o uso do programa.
INFO
Fornece mensagens menos detalhadas, que apenas informam sobre o
andamento das operações.
WARN
Fornece mensagens apenas para situações potencialmente nocivas.
ERROR
Fornece mensagens dos erros que não impedem que o programa
continue executando.
FATAL
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
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
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
Clique com o botão direito do mouse sobre o 'Schema' e adicione um cubo,
atribuindo um nome a ele.
10
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
Configure essa dimensão com a Foreign Key (FK) da tabela de fatos
correspondente à dimensão criada.
12
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
No caso, como a dimensão é o ano, será usado a tabela DATE do spadawan.
Agora, adiciona-se um Level a hierarquia.
14
Observação: Não se esqueça de adicionar o tipo de dado de cada Level (number,
integer, ...).
Agora volte na hierarquia e coloque a Primary Key (PK) da tabela referente à
dimensão.
15
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
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
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
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
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
21
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
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
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 7.2.
24
25
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
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
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
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
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
31
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
canCreateIndex
True para permitir a criação de índices bitmap de junção
e false para negar.
canUpdateIndex
True para dar permissão de atualização de índices bitmap de
junção nos índices listados na tag indices e false para negar.
canDeleteIndex
True para dar permissão de remoção de índices bitmap de
junção nos índices listados na tag indices e false para negar.
superUser
True para declarar como um superusuário e false para negar.
Caso o usuário seja um superusuário, ele já possui todas as
permissões citadas anteriormente.
Assim, o arquivo que especifica essas permissões é chamado de user.xml.
Como exemplo, podemos ter:
<Users>
<User name="user" passwd="pass" canUploadXml="true"
canCreateIndex="true" superUser="false" canDeleteIndex="false"
canUpdateIndex="true">
<User name="admin" passwd="admin" superUser="true">
</Users>
Feito isso, ao iniciar o programa, ele pedirá login:
33
Dependendo do usuário, ele poderá fazer o que for especificado pelo arquivo.
Por exemplo, o usuário user poderá criar e atualizar índices, mas não poderá remover
nenhum desses índices.
Toda vez que algum usuário criar um índice, o arquivo XML será alterado. Por
exemplo, se criarmos o índice do manual com o usuário user, teremos:
<Users>
<User name="user" passwd="pass" canUploadXml="true"
canCreateIndex="true" superUser="false" canDeleteIndex="false"
canUpdateIndex="true">
<IndexName>spadawan</IndexName>
</User>
<User name="admin" passwd="admin" superUser="true">
</Users>
34
9. Atualizando o índice
Na parte “Update Index” é possível atualizar os índices criados. Para isso, é
necessário que o índice permita update (seção 5). Feito isso, haverá uma trigger no
banco de dados que registrará (em uma tabela auxiliar) todas as inserções feitas na
tabela de fatos.
Para que seja possível atualizar o índice basta inserir uma ou mais tuplas na
tabela de fatos de seu data warehouse (que já possua um índice no BJIn OLAP).
Assim, ao verificar atualizações sobre o índice que sofreu update, temos o seguinte:
Basta clicar no botão “Update Index” para atualizar o índice com os novos
dados inseridos.
35
10.
Deletando o índice
Para remover um índice, vá em “Drop Index”, selecione o índice desejado e
clique em “Delete”.
Caso o índice permita update, será solicitado o nome de usuário e senha do
banco de dados. Isso acontece para excluir tanto a tabela temporária quanto a trigger
que foram criadas junto com o índice (como falado anteriormente).
36
11.
Considerações Finais
Para esse manual, usou-se a distribuição Ubuntu 11.04 do Sistema
Operacional Linux, com as seguintes versões de software:
o PostgreSQL Plus Standard 9.1;
o Fastbit 1.2.4;
o Schema Workbench 3.3.0.14703.
A ferramenta BJIn OLAP foi desenvolvida por Anderson Chaves Carniel com a
orientação do professor Thiago Luís Lopes Siqueira e com suporte do Instituto Federal
de Educação, Ciência e Tecnologia de São Paulo – Campus Salto.
Este manual foi escrito por Lucas de Carvalho Scabora com afiliação
institucional do Instituto de Ciências Matemáticas e de Computação da Universidade
de São Paulo e a orientação da Professora Doutora Cristina Dutra de Aguiar Ciferri. A
revisão do manual foi feita por Anderson Chaves Carniel.
37