Pós-Graduação em Ciência da Computação
“UMA ANÁLISE COMPARATIVA DE FUNÇÕES
MDX NOS SERVIDORES ANALYSIS SERVICES E
MONDRIAN”
PorERIVAM ANSELMO DE ALBUQUERQUE
Dissertação de Mestrado Profissional
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
Universidade Federal de Pernambuco
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Erivam Anselmo de Albuquerque
“Uma análise comparativa de funções MDX nos
servidores Analysis Services e Mondrian"
ORIENTADOR(A): Prof. Dr. Robson do Nascimento Fidalgo
RECIFE, ABRIL/2013
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
Albuquerque, Erivam Anselmo de
Uma análise comparativa de funções MDX nos servidores Analysis Services e Mondrian/ Erivam Anselmo de Albuquerque. - Recife: O Autor, 2013.
xiii, 105 f. : il., fig.,gráf., quadro
Orientador: Robson do Nascimento Fidalgo.
Dissertação (mestrado profissional) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.
Inclui bibliografia, anexo e apêndice.
1. Banco de dados. 2. OLAP. I. Fidalgo, Robson do Nascimento (orientador). II. Título.
Dissertação de Mestrado Profissional apresentada por Erivam Anselmo de
Albuquerque à Pós-Graduação em Ciência da Computação do Centro de
Informática da Universidade Federal de Pernambuco, sob o título, “Uma Análise
Comparativa de Funções MDX nos servidores Analysis Services e Mondrian”,
orientada pelo Professor Robson do Nascimento Fidalgo e aprovada pela Banca Examinadora formada pelos professores:
_____________________________________________ Profª. Bernadette Farias Lóscio
Centro de Informática / UFPE
_____________________________________________
Profª. Maria da Conceição Moraes Batista
Universidade Federal Rural de Pernambuco
_____________________________________________
Prof. Robson do Nascimento Fidalgo Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 22 de abril de 2013.
___________________________________________________
Profª. EDNA NATIVIDADE DA SILVA BARROS
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Dedico esta dissertação a Deus e a minha família.
AGRADECIMENTOS
Meus agradecimentos, em primeiro lugar, são direcionados a Deus, pela vida, pela saúde, pela inspiração e por mais essa oportunidade que me proporcionou. A Ele toda a glória.
Agradeço especialmente a minha família, nas pessoas de Cláudia, minha amada esposa, que tanto me motivou. Também agradeço a Eva e a Ada, minhas adoráveis filhas, que alegram meu viver, por terem me dado o apoio necessário. A vocês, obrigado por me compreenderem em momentos importantes nos quais estive ausente, mesmo estando próximo, em razão dos esforços por concluir esse trabalho.
Aos meus pais, dedico homenagem e agradecimento. Em especial, à memória de meu pai, com quem gostaria muito de compartilhar este momento. Agradeço a minha mãe pela dedicação e orações.
Minha gratidão ao meu orientador, Prof. Robson do Nascimento Fidalgo, que, antes de tudo, sabe ser gente simples, independente dos títulos que já possui e dos que venha a possuir. Agradeço pela oportunidade de conviver e aprender com o excelente profissional, orientando-me, lutando comigo para conseguirmos nossos objetivos. Não poderia ter tido melhor orientador.
“Descobri que não há nada melhor para o homem do que ser feliz e praticar o bem enquanto vive.”
RESUMO
A MultiDimensional eXpression (MDX) é uma linguagem de consulta para processamento analítico de dados ou On-line Analytical Processing (OLAP). Apesar de esta linguagem ser usada pela maioria dos servidores OLAP, esta não é um padrão de direito. Portanto, tem-se pouca (ou nenhuma) garantia de que as funções MDX usadas por um servidor OLAP também possam ser usadas em outros servidores. Neste contexto, de forma a comparar as funções MDX de um servidor OLAP de código aberto e outro de código fechado, os servidores Mondrian e Analysis Services, por serem bem aceitos tanto pela academia quanto pela indústria, foram respectivamente escolhidos. Para realizar este estudo comparativo, o qual consiste em examinar se existe diferença entre as gramáticas da linguagem MDX usadas por estes servidores, será utilizada a seguinte estratégia: identificar quais funções são específicas de um servidor, quais funções são comuns aos servidores e, dentre as funções comuns (i.e., com o mesmo nome), se existe diferença de sintaxe entre elas. De forma a executar este estudo, será apresentado o cenário de testes aplicados, bem como a ferramenta TestMDX que foi desenvolvida para automatizar a execução dos testes. Por fim, será apresentada uma análise dos resultados obtidos.
ABSTRACT
The MultiDimensional eXpression (MDX) is a query language for Online Analytical Processing (OLAP). Although this language is used by most OLAP servers, this is not a facto standard. Therefore, there is little (or no) guarantee that the MDX functions used by an OLAP server can also be used on other servers. In this context, in order to compare the MDX functions of an OLAP server open source and other closed source, servers Mondrian and Analysis Services, to be well accepted by both the academia and by industry, were respectively chosen. To accomplish this comparative study, which is to examine whether there are differences between the MDX grammars used by these servers, we have identified which functions are specific to a server, which functions are common to the servers and, among the common functions (i.e., with the same name), if theirs syntaxes are the same. In order to perform this study will be presented to the test scenario, as well as the tool TestMDX that was developed to automate test execution. Finally, we will present an analysis of the results.
LISTA DE FIGURAS
Figura 2.1 - Esboço e exemplo de modelos estrela [7]. ... 16
Figura 2.2 - Principais conceitos de um Cubo de dados ... 18
Figura 2.3 - Principais operações OLAP ... 19
Figura 3.1 - Esquema estrela do Data Mart de teste ... 27
Figura 3.2 – Cubo Sales no Analysis Services e Mondrian ... 28
Figura 3.3 - Casos de uso da ferramenta TestMDX ... 29
Figura 3.4 - Arquitetura para usar a ferramenta TestMDX ... 30
Figura 3.5 - TestMDX: Diagrama de classes de visualização ... 31
Figura 3.6 - TestMDX: Diagrama de classes de controle ... 32
Figura 3.7 - TestMDX: Tela inicial da ferramenta ... 33
Figura 3.8 - TestMDX: Tela de cadastro de conexões ... 34
Figura 3.9 - TestMDX: Cadastro de caso de teste ... 35
Figura 3.10 - TestMDX: Executar teste automático ... 35
Figura 3.11 - TestMDX: Tela de resumo dos testes ... 36
Figura 3.12 – TestMDX: Layout do repositório de consultas ... 36
Figura 3.13 - TestMDX: Arquivo de saida de testes ... 37
Figura 3.14 - TestMDX: Diagrama de atividade de teste automático ... 37
Figura 4.1 - Esquema do quadro comparativo de funções ... 40
Figura A.1 - Arquivos da pasta lib dentro do arquivo mondrian.war ... 53
Figura A.2 - Arquivo FoodMartCreateData.sql para carga de dados da base FoodMart ... 53
Figura A.3 - Pasta de instalação com arquivos copiados ... 53
Figura B.1 - Iniciando a instalação do MySQL Connector/NET ... 55
Figura B.2 - Data Source com MySQL Data Provider ... 56
Figura B.3 - Parâmetros para conexão com a base foodmart do MySQL ... 56
Figura B.4 - Modificando valor do parâmetro "Sql Server Mode" ... 57
Figura B.5 - Testando a conexão com o MySQL... 57
Figura B.6 - Definindo credenciais de acesso para o Data Source ... 57
Figura B.7 - Finalizando a instalação ... 58
Figura B.8 - Data Source criado para foodmart... 58
Figura B.9 - Seleção de tabelas para Data Source View ... 58
Figura B.10 - Data Source View com tabelas de foodmart ... 59
Figura B.11 - Regra XMLA_Access (Tela 1) ... 59
Figura B.12 - Regra XMLA_Access (Tela 2) ... 59
Figura C.1 - Iniciando instalação do IIS ... 60
Figura C.2 - Configurações mínimas para o IIS ... 60
Figura C.3 - Iniciando o gerenciador do IIS ... 61
Figura C.5 - Copiando arquivos do mecanismo XMLA ... 62
Figura C.6 - Colando arquivos copiados na pasta olap do site padrão IIS ... 62
Figura C.7 - Pasta olap selecionada para conversão de aplicativo ... 63
Figura C.8 - Converter para Aplicativo ... 63
Figura C.9 - Concluindo conversão para aplicativo no IIS ... 64
Figura C.10 - Manipulador para dlls do site ... 64
Figura C.11 - Mapeamento de Script ... 65
Figura C.12 - Teste de acesso HTTP XMLA ... 65
Figura D.1 - Arquivos do Mondrian descompactados... 66
Figura D.2 - Pasta do Mondrian criada pelo arquivo mondrian.war no servidor Tomcat ... 67
Figura D.3 - Conector jdbc MySQL na pasta lib do Tomcat ... 67
Figura D.4 - Navegador acessando o Mondrian OLAP Server ... 71
Figura D.5 - Mondrian OLAP Server exibindo dados da base foodmart ... 71
LISTA DE GRÁFICOS Gráfico 4.1 - Funções comuns e específicas do Analysis Services e Mondrian ... 41
Gráfico 4.2 - Funções sobrecarregadas do Analysis Services e Mondrian ... 42
Gráfico 4.3 - Quantidade de sintaxes nos servidores Analysis Services e Mondrian. ... 43
LISTA DE QUADROS
Quadro 2.1 - Tipos de coleções de membros MDX ... 19
Quadro 2.2 - Sintaxe básica MDX ... 21
Quadro 2.3 - Exemplo de consulta básica MDX ... 21
Quadro 2.4- Categorias de Funções MDX ... 23
Quadro 4.1 – Sintaxes exclusivas do Mondrian ... 44
Quadro 4.2 - Sintaxes exclusivas do Analysis Services ... 45
Quadro D.1 - Arquivo datasource.xml do Mondrian configurado para conectar MySQL ... 68
LISTA DE SCRIPTS Código A.1 - Script para carga de dados na base foodmart do Mysql ... 54
LISTA DE ABREVIATURAS E SIGLAS
API - Application Programming Interface é um conjunto de rotinas, protocolos e
ferramentas para desenvolvimento de sistemas.
BI - Business Intelligence DW - Data Warehouse DM - Data Mart
HTTP - HyperText Transfer Protocol
Java – Uma linguagem de programação orientada a objetos.
JDBC - Java Database Connectivity é uma API do Java para execução de
comandos SQL em banco de dados.
MDX - Multidimensional Expressions é uma linguagem de consulta para
servidores OLAP proposta pela Microsoft em 1997
ODBC - Open Database Connectivity Open é um driver que permite às
aplicações acessarem os dados armazenados em SGBD.
OLAP - On-line Analytical Processing
SGBD - Sistema de Gerenciamento de Banco de Dados SOAP -Object Access Protocol
SQL - Structured Query Language é a linguagem padrão para manipulação de
dados em banco de dados relacionais.
XML - eXtensible Markup Language é uma linguagem onde os
desenvolvedores podem criar suas próprias marcações. Isso permite que se estabeleçam padrões, mecanismos de transmissão, interpretação e validação dos dados contidos no arquivo.
SUMÁRIO 1. INTRODUÇÃO ... 14 1.1 APRESENTAÇÃO ... 14 1.2 MOTIVAÇÃO ... 14 1.3 OBJETIVOS E CONTRIBUIÇÕES ... 15 1.4 ESTRUTURA DO TRABALHO ... 15 2. CONCEITOS BÁSICOS ... 16
2.1 BANCO DE DADOS PARA OLAP ... 16
2.2 LINGUAGEM MDX ... 19
2.3 CONSIDERAÇÕES FINAIS ... 23
3. ANÁLISE COMPARATIVA DE FUNÇÕES MDX ... 24
3.1 MATERIAIS ... 24
3.1.1 TECNOLOGIAS UTILIZADAS ... 24
3.2 MÉTODOS ... 26
3.2.1 PREPARANDO O DW E O CUBO DE TESTE ... 26
3.2.2 DESENVOLVIMENTO DA FERRAMENTA TestMDX ... 28
3.2.3 ESTRATÉGIA PARA SELEÇÃO E ELABORAÇÃO DAS CONSULTAS ... 38
3.3 CONSIDERAÇÕES FINAIS ... 39
4. RESULTADOS E DISCUSSÕES ... 40
4.1 DIFERENÇAS DE FUNÇÕES MDX DO ANALYSIS SERVICES E MONDRIAN ... 40
4.2 FUNÇÕES COM SINTAXES EXCLUSIVAS ... 44
4.3 DIVERGÊNCIAS ENCONTRADAS COM A AJUDA DE TESTMDX ... 45
5. CONCLUSÕES ... 47
5.1 CONSIDERAÇÕES FINAIS ... 47
5.2 TRABALHOS FUTUROS ... 48
REFERÊNCIAS ... 49
ANEXO A - SCRIPT PARA CARGA DE DADOS NA BASE FOODMART DO MYSQL ... 51
APÊNDICE A - CRIANDO A BASE DE DADOS FOODMART NO MYSQL ... 52
APÊNDICE B - CONECTANDO O ANALYSIS SERVICES COM O MYSQL ... 55
APÊNDICE C - CONFIGURAÇÃO DO IIS PARA ACESSO HTTP XMLA ... 60
APÊNDICE D - INSTALAÇÃO E CONFIGURAÇÃO DO MONDRIAN ... 66
APÊNDICE F - COMPARAÇÃO DA SINTAXE MDX ... 78 APÊNDICE G - CONSULTAS TESTADAS COM A FERRAMENTA TESTMDX ... 87 APÊNDICE H – FUNÇÕES SOBRECARREGADAS ... 105
1. INTRODUÇÃO
Neste Capítulo são apresentadas as motivações e os objetivos que levaram ao desenvolvimento desta dissertação. Além disso, também é descrita a estrutura na qual os demais Capítulos deste trabalho estão organizados.
1.1 APRESENTAÇÃO
OLAP (OnLine Analytical Processing) [1] é uma tecnologia para realizar consultas analíticas que permitem cruzar dados (e.g. vendas por ano, tipo de
produto e escolaridade do cliente) e visualizá-los com diferentes níveis de
detalhes (e.g. vendas por ano, semestre, mês e dia). OLAP por muito tempo não teve uma linguagem de consulta padrão. A primeira proposta [2] foi feita
em 1997, quando a Microsoft disponibilizou a linguagem MDX
(MultiDimensional eXpressions) [2] como a linguagem de consulta para a API (Application Programming Interface) ODBO (OLE DB for OLAP) [3]. Posteriormente, no ano de 2001, com o intuito de prover uma API independente de linguagem de Programação, a Microsoft e a Hyperion especificaram o padrão XML4A (XML for Analysis) [3], o qual é baseado em Serviços Web [4] e usa MDX como linguagem de consulta.
Embora MDX não seja um padrão “de direito”, dada a sua ampla aceitação por várias ferramentas OLAP (e.g., MicroStrategy, Oracle
Corporation, SAS, SAP, Teradata, JasperSoft, Cognos, Business Objects, Crystal Reports, Microsoft Excel e Microsoft Reporting Services), esta é
considerada um “padrão de fato”. Neste contexto, dada à importância de MDX e a falta de um padrão oficial da mesma, este trabalho irá comparar as funções MDX dos servidores Analysis Service e Mondrian. A seguir, é apresentada a motivação para realizar este trabalho.
1.2 MOTIVAÇÃO
As principais motivações para o desenvolvimento deste trabalho são: 1) a linguagem MDX é utilizada pela maioria dos servidores OLAP, porém esta não é um padrão de direito; 2) o Analysis Service e o Mondrian são servidores OLAP baseados em MDX [13] bem conceituados; 3) não há garantia de que todas as funções MDX do Analysis Service possam ser executadas no Mondrian e vice-versa; 4) não se tem conhecimento de um trabalho que tenha
feito uma análise comparativa de funções MDX desses servidores OLAP; Por fim, 5) as descobertas obtidas a partir deste trabalho serão úteis para orientar a escrita de consultas MDX que precisam ser executadas nos dois servidores OLAP em questão (e.g. em projetos de migração/integração de sistemas OLAP e/ou desenvolvimento de soluções OLAP que devem rodar tanto no Mondrian quanto no Analysis Services).
1.3 OBJETIVOS E CONTRIBUIÇÕES
O objetivo geral deste trabalho é realizar uma análise comparativa de funções MDX nos servidores OLAP Analysis Services e Mondrian. A partir do objetivo geral, podem-se descrever os seguintes objetivos específicos, os quais correspondem às contribuições deste trabalho: 1) especificação de uma estratégia para selecionar as funções MDX que devem ser testadas nos servidores OLAP analisados; 2) Identificação das funções que são exclusivas do Mondrian; 2) Identificação das funções que são exclusivas do Analysis Services; 3) Identificação das funções comuns ao Mondrian e ao Analysis Services; 4) Identificação das divergências na sintaxe das funções comuns aos servidores; e 5) especificação e desenvolvimento de uma ferramenta para simultaneamente testar consultas MDX nos dois servidores OLAP em questão.
1.4 ESTRUTURA DO TRABALHO
Visando atingir os objetivos desta dissertação, bem como apresentar alguns conceitos e tecnologias relacionadas, os demais Capítulos estão organizados da seguinte maneira: no Capítulo 2, é apresentada a fundamentação teórica para o entendimento deste trabalho, abordando os principais conceitos relacionados com base de dados para suporte à decisão (Data Warehouse), Processamento Analítico (ou simplesmente OLAP) e a linguagem MDX; no Capítulo 3, são apresentados os materiais e os métodos aplicados na construção deste trabalho; no Capítulo 4, é feita uma discussão sobre os resultados obtidos; e, por fim, no Capítulo 5, são apresentadas as conclusões, as limitações do estudo e propostas para trabalhos futuros.
2. CONCEITOS BÁSICOS
Neste Capítulo são apresentados os principais conceitos relacionados à OLAP, os quais são fundamentais para possibilitar um melhor entendimento dos próximos capítulos desta dissertação.
2.1 BANCO DE DADOS PARA OLAP
Um DW (Data Warehouse) [1], [5], [6] é um banco de dados para dar suporte à tomada de decisão que armazena uma visão histórica e sem heterogeneidade das principais fontes de dados de uma corporação. Devido ao elevado custo e complexidade de construir um DW, uma opção mais barata e simples é construir um DM (Data Mart) [1], [5], [6]. Diferentemente dos DW, que correspondem a uma visão global dos dados, os DM são específicos para um assunto da corporação (e.g., um setor ou departamento). A maioria dos DM/DW é construído usando um SGBD (Sistema de Gerenciamento de Banco de Dados) relacional e seu esquema de dados é normalmente modelado a partir de um esquema Estrela [1], [5], [6], o qual possui tabelas de dois tipos: 1) Dimensão - tabela desnormalizada projetada para armazenar as descrições textuais do negócio a ser analisado e 2) Fato - tabela normalizada projetada para armazenar o conjunto de chaves estrangeiras para as chaves primárias das dimensões e as medidas numéricas do negócio a ser analisado. A Figura 2.1 ilustra um esboço (A) e um exemplo (B) de um esquema estrela.
Várias ferramentas podem ser usadas para consultar os dados de um DW/DM. Uma dessas ferramentas é a OLAP (Online Analytical Processing) [1] [8]. OLAP é uma tecnologia utilizada para realizar consultas de suporte à decisão sobre bases de dados conhecidas como cubos de dados [1] [8], os quais correspondem a uma visão (materializada ou não) de um DW. Os principais conceitos sobre cubo de dados são ilustrados na Figura 2.2 e apresentados a seguir [9] [10]:
Dimensões – Correspondem aos eixos de análise do cubo de
dados. Por exemplo: DM_Cliente, DM_Localizacao e DM_Tempo;
Níveis – Equivalem aos atributos de uma dimensão. Por exemplo:
Unidade Federativa, Estado Civil e Mês;
Hierarquias – Representam diferentes visões ordenadas dos
níveis de uma dimensão. Ressalta-se que uma dimensão pode ter mais de uma hierarquia. Por exemplo, uma dimensão DM_Tempo pode ter uma hierarquia ano > semestre > mês e outra ano > mês > dia;
Medidas – correspondem a atributos mensuráveis. Por exemplo,
unidades vendidas, vendas em reais e lucro;
Membros – são os dados de um nível. Por exemplo, janeiro,
fevereiro, março e abril são membros de um nível mês;
Fatos ou células – correspondem aos valores de uma medida que
é obtido a partir da interseção de membros de diferentes dimensões. Por exemplo, mouse Microsoft em 2013, vendeu 200 unidades.
Figura 2.2 - Principais conceitos de um Cubo de dados
A partir de um cubo de dados, várias operações OLAP podem ser executadas [11]. A Figura 2.3 ilustra estas operações, as quais são introduzidas a seguir:
Roll-up: agregação dos dados para um nível menos detalhado.
Por exemplo, ir de um nível mês para um nível semestre;
Drill-down: agregação dos dados para um nível mais detalhado.
Esta operação é inversa ao Roll-up;
Slice: projeção sobre um ou mais níveis de uma dimensão do
cubo de dados. Por exemplo, vendas de produtos por marca, ano e tipo de fornecedor;
Dice: seleção sobre um ou mais membros de um nível do cubo de
dados. Por exemplo, vendas em PE, no ano de 2011 e de cliente solteiros;
Pivoting/Rotate - rotação dos eixos do cubo de dados. Por
exemplo, venda de produtos por ano e tipo de cliente ou venda de produtos por tipo de cliente e ano.
Figura 2.3 - Principais operações OLAP
2.2 LINGUAGEM MDX
MultiDimensional eXpression (MDX) [12] é uma linguagem de consulta a cubo de dados que tem uma sintaxe declarativa semelhante à linguagem SQL. Entretanto, apesar das semelhanças, MDX não é uma extensão de SQL, pois esta linguagem tem propósitos, funções e operadores distintos. A seguir, são apresentados os principais conceitos para manipular dados em MDX.
Um dado em MDX é conhecido como membro. Por exemplo, Masculino Recife e Janeiro. Os membros podem ser especificados pelo seu nome único (e.g., [Tempo].[Ano].[Mes].[Abril de 2013]), pelo nome qualificado (e.g., [Tempo]. [Ano].[2013].[Trimestre 2].[Abril de 2013]), pelo nome abreviado (e.g., [Tempo]. [Abril de 2013]), ou retornado por uma função MDX (e.g., PrevMember, Parent , FirstChild).
Existem dois tipos de coleções de membros: tuplas e conjuntos. No primeiro caso, todos os membros da coleção devem ser de dimensões diferentes. Por sua vez, no segundo caso, a coleção é formada por um conjunto de membros de uma mesma dimensão. Ressalta-se que uma tupla é delimitada por parênteses “( )” e um conjunto por chaves “{ }”. No Quadro 2.1 são apresentados exemplos destes tipos de coleções.
Tipo de
coleção Exemplo
Conjunto {[Tempo].[2010].[Trimestre1],[Tempo].[2011].[Trimestre1],[Tempo].[2012].[Trimestre1]} Tupla ([Tempo].[2013], [Loja].[Brasil], [Produto].[Bebida])
Conjunto de Tuplas
{([Tempo].[2013], [Loja].[Brasil].[AL], [Produto].[Bebida]), ([Tempo].[2013], [Loja].[Brasil].[PB], [Produto].[Bebida]), ([Tempo].[2013], [Loja].[Brasil].[PE], [Produto].[Bebida])}
Além de permitir manipular dados (membros), a MDX também permite manusear metatados (i.e., dimensões, hierarquias e níveis). Por exemplo, para referenciar a dimensão Tempo, pode-se fazer pelo nome da dimensão (e.g., [Tempo]), por um membro (e.g., [Tempo].[2013].Dimension), por uma hierarquia (e.g., [Tempo].[Periodo Fiscal].Dimension), ou por um nível (e.g., [Tempo].[Periodo Fiscal].[Ano].Dimension). Para referenciar a hierarquia Periodo Fiscal da dimensão Tempo pode-se fazer pelo nome da hierarquia (e.g., [Tempo].[Periodo Fiscal]), por um nível (e.g., [Tempo].[Periodo Fiscal].[Ano].Hierarchy), ou por um membro da hierarquia (e.g., [Time].[Periodo Fiscal].[2012].Hierarchy). Por fim, para referenciar um nível Mês da dimensão Tempo usando a hierarquia padrão, pode-se fazer [Tempo].[Mes], [Tempo].Levels(2) ou [Tempo].[Mes].[Abril].Level. Caso seja necessário referenciar o nível Mês da hierarquia Periodo Fiscal da dimensão Tempo, pode-se fazer [Tempo].[Periodo Fiscal].[Mes], [Tempo].[Periodo Fiscal].Levels(2). [Tempo].[Periodo Fiscal].[Mes].[Abril].Level. Ressalte-se que o uso de colchetes só é obrigatório quando o nome do identificador (dado ou metadado) contiver números, espaços em branco, palavras reservadas da linguagem MDX ou caracteres especiais.
A partir do entendimento dos principais identificadores de MDX, pode-se escrever uma consulta de acordo com a sintaxe apresentada no Quadro 2.2 [12].
Quadro 2.2 - Sintaxe básica MDX
SELECT [<especificação_do_eixo> [, <especificação_do_eixo>...]] FROM <nome_do_cubo>
[WHERE <especificação_de_Seleção>]
No Quadro 2.2 pode-se observar que apenas as cláusulas SELECT e FROM são obrigatórias. Além disso, onde aparece <especificação_do_eixo>, <nome_do_cubo> e <especificação_de_Seleção>, pode-se definir os eixos que serão usados na consulta, o nome do cubo a ser consultado e o eixo que irá restringir a consulta, respectivamente. Basicamente, uma consulta MDX tem três eixos: coluna (columns ou 0), linha (rows ou 1) e restritivo. Os dois primeiros são usados para projetar dados (operação de Slice) e o último para selecionar dados (operação de Dice). O Quadro 2.3 mostra um exemplo básico de uma consulta MDX, o qual tem no eixo coluna o membro [Medidas].[Unidades vendidas], no eixo linha o conjunto {[Tempo].[2011],
[Tempo].[2012]} e no eixo restritivo a tupla ([Loja].[Brasil].[PE],
[Produto].[Bebida]). Nota-se que os eixos de uma consulta MDX são formados a partir de membros, conjuntos e tuplas. Uma boa documentação de MDX pode
ser consultada em http://msdn.microsoft.com/pt-br/library/ms145506.aspx ou
http://mondrian.pentaho.com/documentation/mdx.php.
Quadro 2.3 - Exemplo de consulta básica MDX
SELECT
[Medidas].[Unidades vendidas] ON COLUMNS, {[Tempo].[2011], [Tempo].[2012]} ON ROWS FROM [Vendas]
WHERE ([Loja].[Brasil].[PE], [Produto].[Bebida])
A linguagem MDX tem várias categorias de funções, estas são apresetadas a seguir:
Funções de matriz - fornecem matrizes para serem usadas em UDFs (i.e., funções definidas pelo usuário);
Funções de dimensão - retornam uma referência a uma dimensão
a partir de uma hierarquia, nível ou membro;
Funções de hierarquia - retornam uma referência a uma
hierarquia a partir de um nível ou membro;
Funções de nível - retornam uma referência a um nível a partir de
um membro, dimensão, hierarquia ou expressão de cadeia de caracteres;
Funções lógicas - executam operações lógicas e comparações
em objetos e expressões;
Funções de membro - retornam uma referência a um membro a
partir de outros objetos ou de uma expressão de cadeia de caracteres;
Funções matemáticas - executam operações matemáticas e
estatísticas em objetos e expressões;
Funções de conjunto - retornam uma referência a um conjunto a
partir de outros objetos ou de uma expressão de cadeia de caracteres;
Funções de cadeia de caracteres - retornam valores da cadeia de
caracteres a partir de outros objetos ou do servidor;
Funções de tupla - retornam uma referência a uma tupla a partir
de um conjunto ou de uma expressão de cadeia de caracteres. No Quadro 2.4 são apresentados exemplos de cada uma das categorias de funções MDX. Na próxima seção são apresentadas as considerações finais deste capítulo.
Quadro 2.4- Categorias de Funções MDX
Categoria de função Exemplo
Funções de matriz SELECT MinhaUDF([Tempo].[Ano].Members) on 0 FROM [Vendas] Funções de dimensão SELECT [Tempo].[Ano].[1997].Dimension on 0 FROM [Vendas]
Funções de hierarquia
WITH MEMBER MEASURES.nomehierarquia AS [Tempo].[Ano].[1997].Hierarchy.Name
SELECT MEASURES.nomehierarquia ON 0, [Tempo].[Ano].Members ON 0 FROM [Vendas]
Funções de nível
WITH MEMBER MEASURES.nomenivel AS [Tempo].[Ano].Level.Name SELECT MEASURES.nomenivel ON 0,
[Tempo].[Ano].Members ON 0 FROM [Vendas]
Funções lógicas
WITH MEMBER MEASURES.[IsLeafDemo] AS
IsLeaf([Tempo].[Ano].[1997])
SELECT MEASURES.[IsLeafDemo] ON 0 FROM [Vendas]
Funções de membro
WITH MEMBER MEASURES.[CurrentMemberDemo] AS [Tempo].[Ano].CurrentMember.Name
SELECT MEASURES.[CurrentMemberDemo] ON 0, [Tempo].[Ano].Members ON 1 FROM [Vendas]
Funções matemáticas
WITH MEMBER [Measures].[soma] AS
SUM({[Tempo].[Ano].[1997],[Tempo].[Ano].[1997]})
SELECT [Measures].[soma] on 0 FROM [Vendas]
Funções de conjunto
SELECT [Measures].[Unidades] ON 0,
Crossjoin([Tempo].[Ano].Members,
[Produto].[Categoria].Members) ON 1 FROM [Vendas] Funções de cadeia de
caracteres
SELECT Generate([Tempo].[Ano].Members , {[Measures].[Unidades]}) ON 0 FROM [Vendas]
Funções de tupla
WITH SET demotupla AS '[Tempo].[Ano].Members * [Produto].[Categoria].Members'
MEMBER MEASURES.demoitemtupla AS
TupleToStr(demotupla.Item(1))
SELECT MEASURES.demoitemtupla ON 0 FROM [Sales]
2.3 CONSIDERAÇÕES FINAIS
OLAP é uma tecnologia utilizada para dar suporte à tomada de decisão. Os servidores OLAP que se destacam são o Analysis Services e o Mondrian. Ambos utilizam a linguagem MDX para consultas. Esta linguagem permite manipular dados (membros) que, por sua vez, são organizados em níveis, hierarquias e dimensões de um cubo. Além disso, MDX utiliza coleções de membros, e estes elementos também são utilizados como argumentos em funções MDX. No próximo Capítulo, são apresentados os materiais e métodos empregados no desenvolvimento deste trabalho.
3. ANÁLISE COMPARATIVA DE FUNÇÕES MDX
Neste Capítulo descrevem-se os materiais (tecnologias utilizadas) e métodos (procedimentos realizados) que foram empregados durante o desenvolvimento deste trabalho.
3.1 MATERIAIS
Nesta seção são apresentadas as tecnologias utilizadas na preparação do ambiente de teste e no desenvolvimento da ferramenta de testes.
3.1.1 TECNOLOGIAS UTILIZADAS
Para a realização deste trabalho, foram utilizadas as seguintes tecnologias:
Servidores OLAP: Mondrian e Analysis Services;
SGBD para armazenar e gerenciar o DW: MySQL Server;
Ferramenta para construção de cubos no Analysis Services:
Microsoft Visual Studio 2008;
Linguagem de programação: Java;
Ambiente de desenvolvimento: Eclipse;
APIs para acessar os servidores OLAP: XMLA e OLAP4J;
Driver XMLA para conexão aos servidores OLAP: XmlaOlap4jDriver
Driver JDBC para conexão ao DW: MySQL Connector/JDBC 5.1.10 e
MySQL Connector/Net 6.6.5;
Driver JDBC para acessar a base de dados da ferramenta de testes
no SGBD SQLite: SQLite-jdbc-3.7.2.
Servidores Web: Apache Tomcat e Microsoft Internet Information
Services;
Os servidores OLAP selecionados para realizar os testes foram o Mondrian e o Analysis Services, pois ambos usam a linguagem MDX e são os representantes mais populares de servidores OLAP, baseados em tecnologias de código aberto e fechado, respectivamente. O Mondrian é da Pentaho e pode
ser obtido no site http://sourceforge.net/projects/mondrian/. Por sua vez, o Analysis Services é da Microsoft e é distribuído com o SQL Server.
Dado que o Mondrian possui um conjunto de cubos para testes, o cubo
Sales (ver seção 3.2.1) foi escolhido para testar as funções MDX deste
servidor. A escolha deste cubo foi motivada pelo fato dele ilustrar um exemplo de vendas de um supermercado, o qual é bem conhecido e de fácil entendimento. Para garantir a uniformidade de fonte de dados, o cubo Sales foi replicado no Analysis Services. Para isto, utilizou-se o Visual Studio 2008 - a ferramenta da Microsoft para criação de cubos no Analysis Services. Por fim, sobre o DW de teste, como os cubos de teste do Mondrian são criados a partir do DW Foodmart com o SGBD MySQL Server (ver seção 3.2.1), estes (DW e SGBD) foram mantidos.
Os testes de funções MDX nos servidores Mondrian e Analysis Services foram realizados a partir do desenvolvimento da ferramenta TesteMDX (ver seção 3.2.2). Esta ferramenta foi construída em Java utilizando o ambiente de desenvolvimento integrado Eclipse, pois este é fácil de usar e tem uma grande comunidade de usuários. Além disso, também foi necessário utilizar: 1) as API XMLA e OLAP4J para submeter às consultas MDX e recuperar seus resultados; 2) o driver genérico XmlaOlap4jDriver para conectar ao Analysis Service e Mondrian; 3) os drivers MySQL Connector/JDBC 5.1.10 e MySQL Connector/Net 6.6.5 para, respectivamente, configurar o acesso do Mondrian e do Analysis Services ao DW no MySQL; 4) o driver SQLite-jdbc-3.7.2 para permitir o armazenamento dos resultados dos testes realizados pela ferramenta TestMDX em um banco de dados SQLite; Por fim, 5) o Apache Tomcat e Microsoft Internet Information Services como servidores Web para o Mondrian e o Analysis Services, respectivamente.
Sobre o equipamento utilizado para realizar os testes, este foi um notebook com processado Pentium® Dual-Core 2.30GHz, 3 GB de Memória RAM, HD de 320 GB e sistema operacional Windows 7 Professional (32 Bits).
3.2 MÉTODOS
Nesta seção são apresentados os procedimentos realizados para o desenvolvimento deste trabalho. Primeiramente, é apresentado como o DW e o Cubo de teste foram construídos. Depois, apresenta-se o desenvolvimento da ferramenta TestMDX. Na sequência, apresenta-se a estratégia para seleção e elaboração das consultas.
3.2.1 PREPARANDO O DW E O CUBO DE TESTE
Para assegurar a homogeneidade dos dados, utilizou-se um único DW, o FoodMart. Este DW foi escolhido, pois é livremente distribuído com a atual versão do Mondrian e foi distribuído com as antigas versões do Analysis Services (i.e., até o SQL Server 2000). O SGBD escolhido para gerenciar o DW foi o MySQL Server, pois este é de distribuição gratuita e o script SQL de criação do DW Foodmart é baseado no dialeto deste SGBD. Para instanciar o DW FoodMart foi utilizado o script SQL apresentado no ANEXO A e realizado o procedimento descrito no APÊNDICE A. O DW FoodMart tem 22 (vinte e duas) tabelas de dimensões e 2 (duas) tabelas de fatos. Para os testes realizados neste trabalho, foram utilizadas apenas 6 (seis) tabelas de dimensões (i.e., Customer, Store, Promotion, Product, Product_class e Time) e a tabela de fatos Sales_Fact_1997. A Figura 3.1 mostra o esquema estrela do Data Mart de teste.
Com base no Data Mart de teste, o Mondrian disponibiliza o cubo Sales. Dado que este cubo não existe na versão 2008 do Analysis Services, foi necessário reconstruí-lo/replicá-lo no Analysis Services. Ressalta-se que, para construir este cubo no Analysis Services, foi utilizado o MySQL Connector/Net para conectar o Visual Studio à base de dados foodmart do MySQL (ver APÊNDICE B). No Mondrian, esta conexão é feita usando o MySQL Connector/JDBC. Dessa forma, tanto o Mondrian quanto o Analysis Services utilizaram o mesmo esquema para o cubo Sales. Na Figura 3.2 mostra-se o esquema do cubo Sales no Analysis Sevice (em tons coloridos) e no Mondrian (em tons de cinza). Nesta figura o cubo Sales tem 4 medidas convencionais (e.g., Store Cost e Unit Sales), 3 medidas calculadas (e.g., Profit e Profit last
Period) tem 11 dimensões (e.g., Customers e Time), cada uma dessas
dimensões tem suas hierarquias (e.g., a dimensão Time tem as hierarquias
Time e Weekly), cada uma das hierarquias tem seus nívies (e.g., a hierarquia Time tem os níveis Year, Quarter e Month).
Figura 3.2 – Cubo Sales no Analysis Services e Mondrian
3.2.2 DESENVOLVIMENTO DA FERRAMENTA TestMDX
Embora o Analysis Services e o Mondrian disponham de ferramentas para executar consultas MDX, estas ferramentas não permitem, ao mesmo tempo, executar as consultas no Analysis Services e no Mondrian. Além disso, não permitem executar um script com várias consultas, tampouco obter e registrar, em um arquivo, informações sobre quais consultas foram executadas com sucesso (ou não) nos dois servidores. Dadas estas limitações, foi necessário desenvolver a ferramenta TestMDX para executar os testes de funções MDX nestes servidores. O desenvolvimento desta ferramenta justifica-se pela necessidade de verificar justifica-se de fato as sintaxes das funções testadas são executadas conforme a especificação. A ferramenta TestMDX é capaz de executar simultaneamente as consultas nos dois servidores OLAP e registrar o resultado dos testes para posterior análise. Na Figura 3.3 mostra-se os casos
de uso da ferramenta TestMDX. Nesta Figura tem-se o caso de teste “Cadastrar Conexões”, o qual permite ao usuário cadastrar conexões com servidores OLAP; o caso de uso “Cadastrar Casos de Testes” que permite ao usuário cadastrar os casos de testes a serem executados e por fim, o caso de uso “Executar Testes”, o qual, com base nas conexões e casos de testes previamente cadastrados, permite que os usuários executem vários testes simultaneamente nos dois servidores OLAP.
Figura 3.3 - Casos de uso da ferramenta TestMDX
Na Figura 3.4 apresenta-se a arquitetura de software para uso da ferramenta TestMDX. Nesta Figura observam-se três camadas: Dados (o DW), Serviço OLAP (ilustrada pelos servidores Mondrian e Analysis Service) e Cliente (a ferramenta TestMDX). Além disso, também é possível observar o uso das API OLAP4J e JDBC. Para acessar os servidores OLAP via OLAP4J utilizou-se o driver genérico XmlaOlap4jDriver, pois ainda não existe um driver OLAP4J nativo para o Analysis Service. Ressalta-se que os servidores OLAP poderiam ser acessados usando apenas a API XMLA. Contudo, dado que manipular elementos XML é mais complexo do que manipular objetos Java, optou-se pela API OLAP4J. Para acessar a base de dados, que armazena os resultados dos testes realizados com a ferramenta TestMDX, utilizou-se a API
SQLite-JDBC. Também foram utilizadas as APIs MySQL Connector/Net e MySQL Connector/JDBC para conectar, respectivamente, o Analysis Services e o Mondrian ao DW de testes.
Figura 3.4 - Arquitetura para usar a ferramenta TestMDX
Na implementação da ferramenta, as classes foram divididas em duas categorias. A primeira delas é composta por classes de interface gráfica do usuário. A segunda é composta por classes de controle da ferramenta. São estas classes que executam as atividades de processamento e controle dos testes. O diagrama de classes apresentado na Figura 3.5 mostra as classes gráficas da ferramenta TestMDX. Estas classes utilizam a interface IFachada para se comunicar com a camada que contém as classes de controle (ver Figura 3.6).
Figura 3.5 - TestMDX: Diagrama de classes de visualização
Na Figura 3.5, a classe “TPrincipal” cria e controla a primeira tela da
ferramenta TestMDX (ver Figura 3.7); esta contém os menus que dão acesso
às demais telas da ferramenta. Já a classe “TCadastrarConexoes” possui
métodos para manter dados que permitem à ferramenta conectar-se aos servidores OLAP. A classe “TCadastrarCasosTestes” mantém dados dos casos de testes, ou seja, as conexões que serão utilizadas para o teste, além dos nomes dos arquivos de entrada e de saída do teste. Por fim, a classe “TTesteAutomatico” pemite a seleção e execução automática de um caso de
teste. Estas classes, com exceção de “TPrincipal”, utilizam os métodos existentes na interface “IFachada” para realizar parte de suas operações.
Figura 3.6 - TestMDX: Diagrama de classes de controle
Na Figura 3.6, a classe “TestarConexaoOLAPMDX” usa dados
previamente cadastrados para conectar com os servidores e fazer teste de conexão, além de verificar a existência de cubos e metadados. Já a classe “ProcessarTesteAutomatico” é responsável por controlar o processamento de consultas automáticas. Esta classe faz a leitura do arquivo de consultas MDX e controla o fluxo de execução destas nos servidores OLAP. A classe “ExecutarConsulta” é instanciada para cada um dos servidores. Dessa forma,
cada instância da classe “ExecutarConsulta” representa uma consulta
executada em um servidor. A classe “TestarMDXOlapServidor” faz a conexão
com os servidores OLAP; através do protocolo XMLA, envia a consulta e lê seu resultado . Por fim, a classe “TExibirResultado” mostra na tela a síntese do processamento do teste automático.
A ferramenta TestMDX foi desenvolvida utilizando a linguagem de programação Java. Os pré-requisitos para o funcionamento adequado da ferramenta TestMDX são: (1) os servidores OLAP devidamente configurados para prover acesso XMLA; e (2) os servidores com a mesma base de dados configurada e o mesmo esquema de cubo OLAP para fins de testes. A tela inicial da ferramenta TestMDX é mostrada na Figura 3.7.
Figura 3.7 - TestMDX: Tela inicial da ferramenta
Nesta tela (Figura 3.7) existem três botões, o primeiro dá acesso ao cadastro de conexões com os servidores OLAP, o segundo ao cadastro de casos de testes e o terceiro dá acesso à execução de testes nos servidores. Através dos menus também é possível acessar estas opções da ferramenta.
Figura 3.8 - TestMDX: Tela de cadastro de conexões
Antes de realizar um teste automático com a ferramenta TestMDX, é preciso cadastrar conexões com os servidores OLAP. Na tela de cadastro de conexões (ver Figura 3.8), o usuário seleciona o tipo de conexão (e.g., Mondrian ou Analysis Services) e informa os dados necessários para que a ferramenta possa estabelecer uma conexão com os servidores OLAP. Depois disso, são cadastrados os casos de testes (ver Figura 3.9), informando as conexões que serão utilizadas, bem como o arquivo que contém as consultas a serem testadas e o arquivo que terá a saída dos testes. A estrutura desses arquivos é ilustrada nas Figuras 3.12 e 3.13, respectivamente. Feito isso, o usuário acessa a tela de execução de teste automático (ver Figura 3.10), seleciona um caso de teste e inicia a execução do teste automático. Por fim, a
Figura 3.9 - TestMDX: Cadastro de caso de teste
Na ferramenta TestMDX, um caso de testes (ver Figura 3.9) corresponde a um registro contendo: a) os dados das conexões que serão utilizadas para execução de consultas MDX; b) o nome do arquivo que contém todas as consultas MDX (i.e., repositório de consultas) que serão testadas nos servidores OLAP; e c) o nome do arquivo de saída no qual são registrados os resultados dos testes.
Figura 3.11 - TestMDX: Tela de resumo dos testes
Figura 3.12 – TestMDX: Layout do repositório de consultas
Um artefato de software importante para a execução de testes automáticos é o arquivo Excel, que funciona como repositório de consultas MDX. Este arquivo (ver Figura 3.12) é formado pelas colunas “A”, “B” e “C”, sendo obrigatório apenas o preenchimento das duas primeiras. A primeira linha (o cabeçalho) não é considerada no processamento dos testes e descreve o
significado de cada coluna. Outro artefato importante é o arquivo resultante da execução dos testes. Neste arquivo (ver Figura 3.13) são gravadas as mensagens retonadas pelos servidores durante o teste, além, do status do teste em cada um dos servidores.
Figura 3.13 - TestMDX: Arquivo de saida de testes
O diagrama de atividade apresentado na Figura 3.14 ilustra como os testes são realizados pela ferramenta TestMDX. Nesta Figura, tem-se a leitura do arquivo com as consultas MDX. Depois, enquanto não for final do arquivo, cada consulta será lida e executada nos servidores Analysis Services e Mondrian. Ao chegar no final do arquivo de testes, é exibida uma tela com resultados do teste, encerrando os testes.
3.2.3 ESTRATÉGIA PARA SELEÇÃO E ELABORAÇÃO DAS CONSULTAS
Após consultar as referências oficiais de MDX do Mondrian (http://mondrian.pentaho.com/documentation/mdx.php) e do Analysys Service (http://msdn.microsoft.com/en-us/library/ms145970.aspx), constatou-se que a quantidade de funções MDX do Mondrian (217) é diferente da quantidade de funções MDX do Analysis Services (145) - ver APÊNDICE E. Dada esta diferença, como não faz sentido testar todas as funções destes servidores, foi necessário definir uma estratégia para selecionar quais funções seriam comparadas, analisadas e executadas. Ou seja :
1- Selecionar as funções com o mesmo nome em ambos os servidores OLAP;
2- Verificar a sintaxe básica dessas funções (apenas foram considerados os parâmetros obrigatórios) a fim de excluir as funções com mesmo nome, mas sintaxes divergentes;
3- Identificar as funções sobrecarregadas (considerando apenas os parâmetros obrigatórios) a fim de elaborar uma consulta para cada forma de sintaxe destas funções;
4- Elaborar uma consulta para cada função com o mesmo nome e sintaxe;
5- Executar teste nos servidores OLAP, usando a ferramenta TestMDX, para verificar se as sintaxes das funções comuns, de fato, funcionam conforme especificado na documentação do Analysis Services e Mondrian.
3.3 CONSIDERAÇÕES FINAIS
Este capítulo apresentou as tecnologias utilizadas para compor o ambiente de teste. Também apresentou a preparação do DW e do cubo de testes. Além disso, foi apresentada a ferramenta TestMDX, desenvolvida para automatizar testes de consultas MDX nos servidores Analysis Services e Mondrian. Também foi apresentada uma estratégia para seleção e elaboração das consultas que foram testadas. Por fim, foram identificadas para cada um dos servidores as funções exclusivas, as sobrecarregadas e as com sintaxes divergentes.
4. RESULTADOS E DISCUSSÕES
Este Capítulo apresenta as diferenças identificadas nas funções MDX dos servidores Analysis Services e Mondrian. Também apresenta uma análise da quantidade de funções comuns, específicas, sobrecarregadas e de sintaxes do Analysis Services e Mondrian. Além disso, apresenta as funções com sintaxes exclusivas nestes servidores. Por fim, apresenta divergências encontradas com a ajuda da ferramenta TestMDX.
4.1 DIFERENÇAS DE FUNÇÕES MDX DO ANALYSIS SERVICES E MONDRIAN
A partir das 217 (duzentos e dezessete) funções MDX do Mondrian e 145 (cento e quarenta e cinco) funções MDX do Analysis Services foram identificadas as funções com o mesmo nome nos dois servidores (i.e., 104 funções). No APÊNDICE E tem-se um quadro destacando em amarelo as funções com o mesmo nome. Neste quadro, cada função destacada na coluna do Analysis Services tem um número que corresponde a sua posição na coluna do Mondrian e um contador das funções com o mesmo nome. A Figura 4.1 ilustra um trecho deste quadro. Observa-se nesta ilustração que a função AllMembers é comum aos dois servidores (está destacada em amarelo), aparece na terceira posição da coluna “Analysis Service” (sexta posição da coluna “Mondrian”) e corresponde a terceira função comum aos servidores OLAP.
Figura 4.1 - Esquema do quadro comparativo de funções
Comparando a quantidade de funções do Analysis Services com as do Mondrian, constatou-se que o Mondrian tem 72 (setenta e duas) funções a mais que o Analysis Services (i.e., 217-145). Além disso, constatou-se (ver Gráfico 4.1) que há mais funções específicas no Mondrian (217 – 104 = 113 ou
52,07%) do que no Analysis Services (145 – 104 = 41 ou 28,28%). Ademais, enquanto a maioria das funções do Analysis Services (104 ou 71,72% - ver o lado esquerdo do Gráfico 4.1) pode ser executada no Mondrian, a maioria das funções do Mondrian (113 ou 52,07% - ver o lado direito do Gráfico 4.1) não pode ser usada no Analysis Services. Ou seja, consultas MDX que executam no Analysis Services têm mais chances de serem executadas no Mondrian.
Gráfico 4.1 - Funções comuns e específicas do Analysis Services e Mondrian
Dentre as 104 (cento e quatro) funções MDX comuns, existem funções que são sobrecarregadas, ou seja, mais de uma função com o mesmo nome, porém com argumentos (i.e., parâmetros) diferentes. Dessa forma, quando uma função MDX é utilizada em uma consulta, o servidor determina a função a ser chamada a partir dos tipos de dados e do número de argumentos fornecidos. Por exemplo, a função MDX Ancestor, quanto à sintaxe, tem duas
formas de utilização. A primeira forma é “Ancestor(Member_Expression,
Level_Expression)”, cujo o segundo argumento é uma expressão de nível, e a segunda forma da sintaxe é “Ancestor(Member_Expression, Distance)”, sendo o segundo argumento uma distância representada por um valor numérico. A partir desta análise, constatou-se que o Mondrian tem mais funções sobrecarregadas (17 ou 16,35%) que o Analysis Services (15 ou 14,42%) - ver Gráfico 4.2. As funções sobrecarregadas do Analysis Service e Mondrian são destacadas em amarelo na no APÊNDICE H.
Gráfico 4.2 - Funções sobrecarregadas do Analysis Services e Mondrian
Dado que existem funções sobrecarregadas em ambos os servidores, foi necessário contar, a partir das 104 (cento e quatro) funções com o mesmo nome, quantas sintaxes diferentes existem para estas funções. Neste sentido, os totais foram: 128 (cento e vinte e oito) sintaxes para o Analysis Services e 132 (cento e trinta duas) para o Mondrian. Estes totais podem ser conferidos nas colunas dois e três do quadro apresentado no APÊNDICE F. É importante destacar que apenas a sintaxe básica das funções (i.e., parâmetros obrigatórios) foi considerada para realizar as referidas contagens. Uma vez que a quantidade de sintaxes básicas do Analysis Services (128) é diferente do Mondrian (132), também foi necessário identificar a quantidade de sintaxes exatamente iguais e aquelas que eram específicas de cada um dos servidores. Neste caso, os totais foram: 122 (cento e vinte e duas) sintaxes iguais, 6 (seis) sintaxes específicas do Analysis Services e 10 (dez) exclusivas do Mondrian. Estes totais podem ser consultados a partir das colunas seis, sete e oito do quadro apresentado no APÊNDICE F. O Gráfico 4.3 resume esta discussão.
Gráfico 4.3 - Quantidade de sintaxes nos servidores Analysis Services e Mondrian.
A proporção de sintaxes iguais (ver Gráfico 4.4) é um indicador importante para uma análise comparativa de funções MDX nestes servidores. Neste sentido, a partir da análise das 128 (cento e vinte e oito) sintaxes do Analysis Service, constatou-se que as 122 (cento e vinte e duas) sintaxes iguais perfazem 95,31%. Por sua vez, a partir das 132 (cento e trinta e duas) sintaxes do Mondrian, constatou-se que as 122 (cento e vinte e duas) sintaxes resultam em 92,42%. Além disso, a proporção de sintaxes exclusivas do Analysis Services é 4,69% (i.e., 6/128), enquanto que a do Mondrian é 7,58% (i.e., 10/132). Neste contexto, foram escritas 122 (cento e vinte e duas) consultas MDX, as quais foram testadas utilizando a ferramenta TestMDX e podem ser examinadas no APÊNDICE G. Na próxima seção, são apresentadas as divergências de sintaxe do Mondrian e do Analysis Services.
128 132 122 6 10 0 20 40 60 80 100 120 140 Quantidade de sintaxes no Analysis Services Quantidade de sintaxes no Mondrian Quantidade de sintaxes iguais Quantidade de sintaxes exclusivas do Analysis Services Quantidade de sintaxes exclusivas do Mondrian
Gráfico 4.4 - Sintaxes iguais e exclusivas no Analysis Services e Mondrian
4.2 FUNÇÕES COM SINTAXES EXCLUSIVAS
No Analysis Services as funções AllMembers, CurrentMember, DefaultMember, Dimension e Members só podem ser utilizadas com hierarquias e níveis. Contudo, no Mondrian estas funções também podem ser usadas em dimensões. Outras funções do Mondrian (e.g., ClosingPeriod, Extract, IsEmpty, Levels e NonEmptyCrossJoin) são exclusivas devido ao tipo de argumento utilizado na sintaxe (i.e., membro, cadeia de caracteres,
dimensão, expressão numérica ou conjunto – ver Quadro 4.1). Da mesma
forma, no Analysis Services, existem funções (ver Quadro 4.2) com sintaxes
exclusivas (e.g., CoalesceEmpty, Count, Descendants, Extract,
NonEmptyCrossjoin). Ressalta-se que as funções Extract e
NonEmptyCrossJoin possuem sintaxes exclusivas tanto no Analysis Services quando no Mondrian.
Quadro 4.1 – Sintaxes exclusivas do Mondrian Funções do Mondrian com sintaxe divergente
<Dimension>.AllMembers
ClosingPeriod(<Member>)
<Dimension>.CurrentMember <Dimension>.DefaultMember <Dimension>.Dimension
Extract(<Set>, <Dimension>[, <Dimension>...]) IsEmpty(<Numeric Expression>)
Levels(<String>)
<Dimension>.Members
Quadro 4.2 - Sintaxes exclusivas do Analysis Services Funções do Analysis Services com sintaxe divergente CoalesceEmpty(String_Expression1 [ ,String_Expression2,...n] )
Dimensions.Count
Hierarchy_Expression.Levels.Count
Descendants(Set_Expression [ , Level_Expression [ ,Desc_Flag ] ] )
Extract(Set_Expression, Hierarchy_Expression1 [,Hierarchy_Expression2, ...n] ) NonEmptyCrossjoin(Set_Expression1 [ ,Set_Expression2,...] [,Count ] )
4.3 DIVERGÊNCIAS ENCONTRADAS COM A AJUDA DE TESTMDX
Analisando os resultados dos testes executados com a ferramenta TestMDX, constatou-se que a função StrToSet não pode ser executada no Mondrian utilizando-se apenas a sintaxe básica (obrigatória). Testada a sintaxe básica no Mondrian, o servidor retornou a informação de que esta função deve ter pelo menos dois argumentos. Ou seja, de acordo com a documentação do Mondrian a sintaxe da função é “StrToSet(<String>[, <Dimension>...])”, entretanto o segundo argumento da função (i.e., <Dimension>), que deveria ser opcional, é obrigatório, de modo que a sintaxe básica mais apropriada para o Mondrian é “StrToSet(<String>,<Dimension>)”.
Da mesma forma, constatou-se que a função StrToTuple não pode ser excutada no Mondrian utilizado-se apenas a sintaxe básica. Testada a sintaxe básica no Mondrian, o servidor retornou a informação de que esta função deve ter pelo menos dois argumentos. Ou seja, na documentação do Mondrian, a sintaxe da função StrToTuple é “StrToTuple(<String>)”. Embora nesta sintaxe tem-se apenas um argumento (i.e., <String>), é necessário informar um segundo argumento (i.e., <Dimension>) que corresponde a uma dimensão do cubo. Dessa forma, no Mondrian, a sintaxe básica mais apropriada para esta função é “StrToTuple(<String>,<Dimension>)”.
Além das diferenças de sintaxes, o Analysis Services e o Mondrian também apresentam divergências quanto à forma de ordenar membros nos resultados de consultas usando as funções DrillDownLevelBottom e DrillDownLevelTop. Conforme análise dos resultados dos testes, constatou-se que apesar de utilizar o mesmo DW e cubo de dados, nestas funções os membros são recuperados em ordens distintas dependendo do servidor utilizado na consulta. Por exemplo, usando a função DrillDownLevelBottom no
Analysis Services, a ordem dos membros é descendente, porém no Mondrian não há uma ordem específica (i.e., ascendente ou descendente) dos membros. Já na função DrillDownLevelTop, o Analysis Services recupera membros em ordem ascendente, enquanto no Mondrian a ordem é descendente. Dessa forma, utilizando estas funções, os resultados das consultas são divergentes nestes servidores.
Outras divergências quanto aos resultados das consultas ocorrem nas funções IsAncestor, IsEmpty, IsGeneration, IsLeaf, IsSibling que retornam os
operadores lógicos “true” ou “false”. No Analysis Services, estas funções
apresentam estes operadores como “True” ou “False”, porém no Mondrian estes são apresentados como “true” e “false”. Embora a semântica destes operadores lógicos seja a mesma nos dois servidores, nota-se uma diferença no primeiro caractere de cada um destes operadores. Dessa forma, dependendo do servidor utilizado para a consulta, aplicações clientes obterão resultados que precisam ser padronizados antes de serem analisados. No próximo capítulo, são apresentadas as considerações finais e também propostas para trabalhos futuros.
5. CONCLUSÕES
O objetivo deste capítulo é apresentar as considerações finais sobre os principais conceitos e tópicos existentes neste trabalho, bem como os objetivos que foram transformados em contribuições e algumas indicações para trabalhos futuros.
5.1 CONSIDERAÇÕES FINAIS
A informação é um insumo relevante para o processo de tomada de decisão. Neste sentido, a utilização de DW, ferramentas OLAP e a linguagem MDX têm contribuído significativamente com este processo. Por isso, qualquer divergência nas funções MDX, em relação aos servidores OLAP, pode comprometer os resultados das consultas e, consequentemente, a qualidade da decisão.
Apesar da linguagem MDX ser usada pela maioria dos servidores OLAP, esta não é um padrão de direito. Dessa falta de padrão, surgem os problemas de divergências nas funções MDX, visto que não há obrigatoriedade dos servidores OLAP aderirem, por completo, a uma especificação de outro fabricante. Dessa forma, cada fornecedor OLAP pode estender a sintaxe MDX adicionando operadores e funções, inclusive com parâmetros adicionais, ou até mesmo pode tornar obrigatório o uso de parâmetros que são opcionais na sintaxe de outros servidores. Estas divergências nas funções MDX podem dificultar a elaboração de consultas em diferentes servidores OLAP. Então, torna-se muito importante identificar e tornar conhecidas estas diferenças. Por esse motivo, justifica-se a realização deste trabalho.
Nesta dissertação foi apresentada uma estratégia e a ferramenta TestMDX para realizar uma análise comparativa de funções MDX nos servidores Analysis Services e Mondrian. Contudo, este método, assim com a ferramenta, podem ser estendidos para uma análise comparativa em outros servidores OLAP à MDX.
5.2 TRABALHOS FUTUROS
Uma proposta para trabalhos futuros é a realização de um mapeamento das divergências de funções MDX abrangendo outros servidores OLAP. Outra proposta é uma implementação em Java para solucionar problemas (e.g., necessidade de reescrever consultas, migração de servidor OLAP) causados por divergência de funções MDX entre servidores OLAP, ou seja, tratar problemas de heterogeneidade da sintaxe MDX.
REFERÊNCIAS
[1] R. Kimball and M. Ross, The Data Warehouse Toolkit: The Complete
Guide to Dimensional Modeling., 2nd ed. John Wiley & Sons, 2002, p.
464.
[2] Carl Nolan. Intoduction to Multidimensional Expressions (MDX). Microsoft
Corporation, August 1999.
[3] XMLA - XML for Analysis Services. What is XML for Analysis Services
(XMLA)?. Disponível em <http://news.xmlforanalysis.com/what-is-xmla.html > Acessado em 15/05/2012.
[4] W3C. Web Services Activity. Disponível em
<http://www.w3.org/2002/ws/> Acessado em 16/05/2012.
[5] W. H. Inmon, Building the data WareHouse, 2nd ed. New York: John
Wiley & Sons, 1996, p. 401.
[6] R. Kimball and M. Ross, The Data WareHouse Toolkit, 1st ed. New York:
John Wiley & Sons, 1996, p. 464.
[7] R. N. Fidalgo, “Uma Infra-Estrutura para Integração de Modelos,
Esquemas e Serviços Multidimensionais e Geográficos.,” Biblioteca Digital de Teses e Dissertações da UFPE, 2005.
[8] S. LIN and D. BROWN, “An outlier-based data association method for
linking criminal incidents,” Decision Support Systems, vol. 41, no. 3, pp. 604-615, Mar. 2006.
[9] C. M. Tanure, “Uma Arquitetura de Software para Descoberta de Regras
de Associação Multidimensional , Multinível e de Outliers em Cubos OLAP: um Estudo de Caso com os Algoritmos APriori e FP-Growth,” Universidade Federal de Pernambuco, 2010.
[10] E. Thomsen, OLAP Solutions: Building Multidimensional Information
Systems. John Wiley & Sons, 1997.
[11] F. R. Paim, “Uma Metodologia para Análise de Requisitos em Sistemas
Data Warehouse.,” Universidade Federal de Pernambuco, 2003.
[12] Microsoft. MDX Function Reference. Disponível em <
http://msdn.microsoft.com/en-us/library/ms145970.aspx> Acessado em 16/03/2012.
[13] Sallam, Rita L.; Richardson, James; hagerty, John e Hostmann, Bill. Magic
Quadrant for Business Intelligence Platforms. Disponível em:
<http://www.gartner.com/id=1531017> Acesso em: 20/02/2013 de outubro de 2012.
ANEXO A - SCRIPT PARA CARGA DE DADOS NA BASE FOODMART DO MYSQL
Este anexo contém o script necessário para efetuar carga de dados do DW FoodMart.
java -cp
"mondrian.jar;log4j-1.2.8.jar;commons-logging-1.0.4.jar;eigenbase-xom.jar;eigenbase-resgen.jar;eigenbase-properties.jar;mysql-connector-java-5.1.10.jar" mondrian.test.loader.MondrianFoodMartLoader verbose tables data indexes
jdbcDrivers=com.mysql.jdbc.Driver inputFile=FoodMartCreateData.sql
APÊNDICE A - CRIANDO A BASE DE DADOS FOODMART NO MYSQL
Este apêndice apresenta o processo de criação da base de dados foodmart no banco de dados MySQL em computadores com sistema operacional Windows.
Pré-requisitos:
Java Development Kit (JDK)
Arquivo mondrian-3.2.1.13885.zip (disponível em
http://sourceforge.net/projects/mondrian/files/mondrian/mondrian -3.2.1.13885/)
Arquivo mysql-connector-java-5.1.10.jar (disponível em
http://dev.mysql.com/downloads/connector/j/ )
MySQL Instalado
Antes de executar os procedimentos para instalação da base foodmart deve-se criar uma base de dados de nome foodmart no MySQL e também criar o usuário foodmart com a senha foodmart. Utilizando-se de algum outro usuário e senha para conectar-se à base de dados será preciso modificar os campos user e password no script de criação e carga de dados. O usuário deve ter permissão de administrador para a base de dados foodmart.
Na pasta que foi descompactada existe uma subpasta pasta de nome lib. Dentro desta existe um auquivo de nome mondrian.war que também deve ser decompactado. Dentro deste arquivo existe uma pasta de nome lib (Figura A.1) e é nesta pasta que estão os arquivos que devem ser copiados para c:\install_foodmart. Os arquivos são:
mondrian.jar log4j-1.2.8.jar commons-logging-1.0.4.jar eigenbase-xom.jar eigenbase-resgen.jar eigenbase-properties.jar
Figura A.1 - Arquivos da pasta lib dentro do arquivo mondrian.war
Dentro da pasta C:\mondrian-3.2.1.13885\demo existe o arquivo FoodMartCreateData.sql e este também deve ser copiado para a pasta C:\install_foodmart.
Tendo baixado o connector Java para MySQL (i.e.,
mysql-connector-java-5.1.10.jar) deve-se copiar este arquivo para a pasta
c:\install_foodmart.Também copiar o arquivo
mondrian-3.2.1.13885\demo\FoodMartCreateData.sql (Figura A.2) para a pasta
C:\install_foodmart.
Figura A.2 - Arquivo FoodMartCreateData.sql para carga de dados da base FoodMart
Pode-se copiar e colocar o script (Código A.1) em um arquivo de nome INSTALL.BAT e gravar na pasta c:\install_foodmart. Assim após modificar o script caso seja necessário, basta executar no prompt o comando INSTALL.BAT. Este script deve ser digitado ou copiado em apenas uma linha, ou seja, não deve haver quebra de linha entre estes comandos, caso contrário haverá falha na execução.
Digite cd C:\install_foodmart no prompt de comando (para acessar a pasta com os arquivos) e em seguida execute o script (Código A.1) para iniciar a instalação da base foodmart no MySQL. É importante observar que pode ser necessário fazer alguma alteração no script, em caso de versões diferentes dos arquivos. Após a conclusão da criação da base de dados foodmart a pas c:\install_foodmart pode ser deletada. Aguarde o final da execução do script. Após a conclusão a posta c:\install_foodmart pode ser eliminada.
Código A.1 - Script para carga de dados na base foodmart do Mysql
java -cp
"mondrian.jar;log4j-1.2.8.jar;commons-logging-1.0.4.jar;eigenbase-xom.jar;eigenbase-resgen.jar;eigenbase-properties.jar;mysql-connector-java-5.1.10.jar" mondrian.test.loader.MondrianFoodMartLoader verbose tables data indexes
-jdbcDrivers=com.mysql.jdbc.Driver -inputFile=FoodMartCreateData.sql
