ERIVAM ANSELMO DE ALBUQUERQUE

Pós-Graduação em Ciência da Computação UMA ANÁLISE COMPARATIVA DE FUNÇÕES MDX NOS SERVIDORES ANALYSIS SERVICES E MONDRIAN Por ERIVAM ANSELMO DE ALBUQUERQUE Dissertação de Mestrado Profissional Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao RECIFE, ABRIL/203

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" 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. ORIENTADOR(A): Prof. Dr. Robson do Nascimento Fidalgo RECIFE, ABRIL/203

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-57 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, 203. xiii, 05 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, 203. Inclui bibliografia, anexo e apêndice.. Banco de dados. 2. OLAP. I. Fidalgo, Robson do Nascimento (orientador). II. Título. 025.04 CDD (23. ed.) MEI203 087

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

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

Descobri que não há nada melhor para o homem do que ser feliz e praticar o bem enquanto vive. (Eclesiastes 3:2) v

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. Palavras-Chave: Estudo Comparativo. Linguagem MDX. OLAP vi

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. Keywords: Comparative Study. MDX. OLAP vii

LISTA DE FIGURAS Figura 2. - Esboço e exemplo de modelos estrela [7].... 6 Figura 2.2 - Principais conceitos de um Cubo de dados... 8 Figura 2.3 - Principais operações OLAP... 9 Figura 3. - 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... 3 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.0 - TestMDX: Executar teste automático... 35 Figura 3. - TestMDX: Tela de resumo dos testes... 36 Figura 3.2 TestMDX: Layout do repositório de consultas... 36 Figura 3.3 - TestMDX: Arquivo de saida de testes... 37 Figura 3.4 - TestMDX: Diagrama de atividade de teste automático... 37 Figura 4. - Esquema do quadro comparativo de funções... 40 Figura A. - 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. - 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.0 - Data Source View com tabelas de foodmart... 59 Figura B. - Regra XMLA_Access (Tela )... 59 Figura B.2 - Regra XMLA_Access (Tela 2)... 59 Figura C. - 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... 6 Figura C.4 - Adicionando pool de aplicativos no IIS... 6 viii

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.0 - Manipulador para dlls do site... 64 Figura C. - Mapeamento de Script... 65 Figura C.2 - Teste de acesso HTTP XMLA... 65 Figura D. - 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... 7 Figura D.5 - Mondrian OLAP Server exibindo dados da base foodmart... 7 LISTA DE GRÁFICOS Gráfico 4. - Funções comuns e específicas do Analysis Services e Mondrian... 4 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 Gráfico 4.4 - Sintaxes iguais e exclusivas no Analysis Services e Mondrian... 44 ix

LISTA DE QUADROS Quadro 2. - Tipos de coleções de membros MDX... 9 Quadro 2.2 - Sintaxe básica MDX... 2 Quadro 2.3 - Exemplo de consulta básica MDX... 2 Quadro 2.4- Categorias de Funções MDX... 23 Quadro 4. Sintaxes exclusivas do Mondrian... 44 Quadro 4.2 - Sintaxes exclusivas do Analysis Services... 45 Quadro D. - Arquivo datasource.xml do Mondrian configurado para conectar MySQL... 68 LISTA DE SCRIPTS Código A. - Script para carga de dados na base foodmart do Mysql... 54 x

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 997 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. XMLA - XML for Analysis xi

SUMÁRIO. INTRODUÇÃO... 4. APRESENTAÇÃO... 4.2 MOTIVAÇÃO... 4.3 OBJETIVOS E CONTRIBUIÇÕES... 5.4 ESTRUTURA DO TRABALHO... 5 2. CONCEITOS BÁSICOS... 6 2. BANCO DE DADOS PARA OLAP... 6 2.2 LINGUAGEM MDX... 9 2.3 CONSIDERAÇÕES FINAIS... 23 3. ANÁLISE COMPARATIVA DE FUNÇÕES MDX... 24 3. MATERIAIS... 24 3.. TECNOLOGIAS UTILIZADAS... 24 3.2 MÉTODOS... 26 3.2. 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. 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. CONSIDERAÇÕES FINAIS... 47 5.2 TRABALHOS FUTUROS... 48 REFERÊNCIAS... 49 ANEXO A - SCRIPT PARA CARGA DE DADOS NA BASE FOODMART DO MYSQL... 5 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 E - COMPARAÇÃO DE FUNÇÕES MDX... 72 xii

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

. 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.. APRESENTAÇÃO OLAP (OnLine Analytical Processing) [] é 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 997, 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 200, 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..2 MOTIVAÇÃO As principais motivações para o desenvolvimento deste trabalho são: ) 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 [3] 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 4

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)..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: ) 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..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. 5

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. BANCO DE DADOS PARA OLAP Um DW (Data Warehouse) [], [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) [], [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 [], [5], [6], o qual possui tabelas de dois tipos: ) 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. ilustra um esboço (A) e um exemplo (B) de um esquema estrela. Figura 2. - Esboço e exemplo de modelos estrela [7]. 6

Várias ferramentas podem ser usadas para consultar os dados de um DW/DM. Uma dessas ferramentas é a OLAP (Online Analytical Processing) [] [8]. OLAP é uma tecnologia utilizada para realizar consultas de suporte à decisão sobre bases de dados conhecidas como cubos de dados [] [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] [0]: 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 203, vendeu 200 unidades. 7

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 []. 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 20 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. 8

Figura 2.3 - Principais operações OLAP 2.2 LINGUAGEM MDX MultiDimensional expression (MDX) [2] é 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 203]), pelo nome qualificado (e.g., [Tempo]. [Ano].[203].[Trimestre 2].[Abril de 203]), pelo nome abreviado (e.g., [Tempo]. [Abril de 203]), 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. são apresentados exemplos destes tipos de coleções. Quadro 2. - Tipos de coleções de membros MDX 9

Tipo de coleção Conjunto Tupla Conjunto de Tuplas Exemplo {[Tempo].[200].[Trimestre],[Tempo].[20].[Trimestre],[Tempo].[202].[Trimestre]} ([Tempo].[203], [Loja].[Brasil], [Produto].[Bebida]) {([Tempo].[203], [Loja].[Brasil].[AL], [Produto].[Bebida]), ([Tempo].[203], [Loja].[Brasil].[PB], [Produto].[Bebida]), ([Tempo].[203], [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].[203].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].[202].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, podese 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 [2]. 20

Quadro 2.2 - Sintaxe básica MDX [<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 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 ) 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].[20], [Tempo].[202]} 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/ms45506.aspx ou http://mondrian.pentaho.com/documentation/mdx.php. Quadro 2.3 - Exemplo de consulta básica MDX [Medidas].[Unidades vendidas] ON COLUMNS, {[Tempo].[20], [Tempo].[202]} 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: 2

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

Quadro 2.4- Categorias de Funções MDX Categoria de função Funções de matriz Funções de dimensão Funções de hierarquia Funções de nível Funções lógicas Funções de membro Funções matemáticas Funções de conjunto Funções de cadeia de caracteres Funções de tupla Exemplo MinhaUDF([Tempo].[Ano].Members) on 0 FROM [Vendas] [Tempo].[Ano].[997].Dimension on 0 FROM [Vendas] WITH MEMBER MEASURES.nomehierarquia AS [Tempo].[Ano].[997].Hierarchy.Name MEASURES.nomehierarquia ON 0, [Tempo].[Ano].Members ON 0 FROM [Vendas] WITH MEMBER MEASURES.nomenivel AS [Tempo].[Ano].Level.Name MEASURES.nomenivel ON 0, [Tempo].[Ano].Members ON 0 FROM [Vendas] WITH MEMBER MEASURES.[IsLeafDemo] AS IsLeaf([Tempo].[Ano].[997]) MEASURES.[IsLeafDemo] ON 0 FROM [Vendas] WITH MEMBER MEASURES.[CurrentMemberDemo] AS [Tempo].[Ano].CurrentMember.Name MEASURES.[CurrentMemberDemo] ON 0, [Tempo].[Ano].Members ON FROM [Vendas] WITH MEMBER [Measures].[soma] AS SUM({[Tempo].[Ano].[997],[Tempo].[Ano].[997]}) [Measures].[soma] on 0 FROM [Vendas] [Measures].[Unidades] ON 0, Crossjoin([Tempo].[Ano].Members, [Produto].[Categoria].Members) ON FROM [Vendas] Generate([Tempo].[Ano].Members, {[Measures].[Unidades]}) ON 0 FROM [Vendas] WITH SET demotupla AS '[Tempo].[Ano].Members * [Produto].[Categoria].Members' MEMBER MEASURES.demoitemtupla AS TupleToStr(demotupla.Item()) MEASURES.demoitemtupla ON 0 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. 23

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

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.) 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.), 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: ) 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..0 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). 25

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. 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_997. A Figura 3. 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 26

Period) tem 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. - Esquema estrela do Data Mart de teste 27

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 justificase pela necessidade de verificar 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 28

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 29

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

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 3

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

A ferramenta TestMDX foi desenvolvida utilizando a linguagem de programação Java. Os pré-requisitos para o funcionamento adequado da ferramenta TestMDX são: () 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. 33

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.2 e 3.3, respectivamente. Feito isso, o usuário acessa a tela de execução de teste automático (ver Figura 3.0), seleciona um caso de teste e inicia a execução do teste automático. Por fim, a tela de saída do teste é exibida para o usuário (ver Figura 3.). 34

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.0 - TestMDX: Executar teste automático 35

Figura 3. - TestMDX: Tela de resumo dos testes Figura 3.2 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.2) é 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 36

significado de cada coluna. Outro artefato importante é o arquivo resultante da execução dos testes. Neste arquivo (ver Figura 3.3) são gravadas as mensagens retonadas pelos servidores durante o teste, além, do status do teste em cada um dos servidores. Figura 3.3 - TestMDX: Arquivo de saida de testes Figura 3.4 - TestMDX: Diagrama de atividade de teste automático 37

O diagrama de atividade apresentado na Figura 3.4 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/ms45970.aspx), constatou-se que a quantidade de funções MDX do Mondrian (27) é diferente da quantidade de funções MDX do Analysis Services (45) - 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 : - 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. 38

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

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. DIFERENÇAS DE FUNÇÕES MDX DO ANALYSIS SERVICES E MONDRIAN A partir das 27 (duzentos e dezessete) funções MDX do Mondrian e 45 (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., 04 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. 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. - 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., 27-45). Além disso, constatou-se (ver Gráfico 4.) que há mais funções específicas no Mondrian (27 04 = 3 ou 40

52,07%) do que no Analysis Services (45 04 = 4 ou 28,28%). Ademais, enquanto a maioria das funções do Analysis Services (04 ou 7,72% - ver o lado esquerdo do Gráfico 4.) pode ser executada no Mondrian, a maioria das funções do Mondrian (3 ou 52,07% - ver o lado direito do Gráfico 4.) 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. - Funções comuns e específicas do Analysis Services e Mondrian Dentre as 04 (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 (7 ou 6,35%) que o Analysis Services (5 ou 4,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. 4

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 04 (cento e quatro) funções com o mesmo nome, quantas sintaxes diferentes existem para estas funções. Neste sentido, os totais foram: 28 (cento e vinte e oito) sintaxes para o Analysis Services e 32 (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 (28) é diferente do Mondrian (32), 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: 22 (cento e vinte e duas) sintaxes iguais, 6 (seis) sintaxes específicas do Analysis Services e 0 (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. 42

40 20 00 80 60 40 28 32 22 20 0 Quantidade de sintaxes no Analysis Services Quantidade de sintaxes no Mondrian Quantidade de sintaxes iguais 6 0 Quantidade de Quantidade de sintaxes exclusivas sintaxes exclusivas do Analysis do Mondrian Services 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 28 (cento e vinte e oito) sintaxes do Analysis Service, constatou-se que as 22 (cento e vinte e duas) sintaxes iguais perfazem 95,3%. Por sua vez, a partir das 32 (cento e trinta e duas) sintaxes do Mondrian, constatou-se que as 22 (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/28), enquanto que a do Mondrian é 7,58% (i.e., 0/32). Neste contexto, foram escritas 22 (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. 43

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.). 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. 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 NonEmptyCrossJoin(<Set>, <Set>) 44

Quadro 4.2 - Sintaxes exclusivas do Analysis Services Funções do Analysis Services com sintaxe divergente CoalesceEmpty(String_Expression [,String_Expression2,...n] ) Dimensions.Count Hierarchy_Expression.Levels.Count Descendants(Set_Expression [, Level_Expression [,Desc_Flag ] ] ) Extract(Set_Expression, Hierarchy_Expression [,Hierarchy_Expression2,...n] ) NonEmptyCrossjoin(Set_Expression [,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 45

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

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

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

REFERÊNCIAS [] 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 999. [3] XMLA - XML for Analysis Services. What is XML for Analysis Services (XMLA)?. Disponível em <http://news.xmlforanalysis.com/what-isxmla.html > Acessado em 5/05/202. [4] W3C. Web Services Activity. Disponível em <http://www.w3.org/2002/ws/> Acessado em 6/05/202. [5] W. H. Inmon, Building the data WareHouse, 2nd ed. New York: John Wiley & Sons, 996, p. 40. [6] R. Kimball and M. Ross, The Data WareHouse Toolkit, st ed. New York: John Wiley & Sons, 996, 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. 4, no. 3, pp. 604-65, 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, 200. [0] E. Thomsen, OLAP Solutions: Building Multidimensional Information Systems. John Wiley & Sons, 997. [] F. R. Paim, Uma Metodologia para Análise de Requisitos em Sistemas Data Warehouse., Universidade Federal de Pernambuco, 2003. [2] Microsoft. MDX Function Reference. Disponível em < http://msdn.microsoft.com/en-us/library/ms45970.aspx> Acessado em 6/03/202. 49

[3] Sallam, Rita L.; Richardson, James; hagerty, John e Hostmann, Bill. Magic Quadrant for Business Intelligence Platforms. Disponível em: <http://www.gartner.com/id=5307> Acesso em: 20/02/203 de outubro de 202. 50

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-.2.8.jar;commons-logging-.0.4.jar;eigenbasexom.jar;eigenbase-resgen.jar;eigenbase-properties.jar;mysql-connector-java-5..0.jar" mondrian.test.loader.mondrianfoodmartloader -verbose -tables -data -indexes - jdbcdrivers=com.mysql.jdbc.driver -inputfile=foodmartcreatedata.sql - outputjdbcurl="jdbc:mysql://localhost/foodmart?user=foodmart&password=foodmart" 5

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 operacional Windows. Pré-requisitos: em computadores com sistema Java Development Kit (JDK) Arquivo mondrian-3.2..3885.zip (disponível em http://sourceforge.net/projects/mondrian/files/mondrian/mondrian -3.2..3885/) Arquivo mysql-connector-java-5..0.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.) e é nesta pasta que estão os arquivos que devem ser copiados para c:\install_foodmart. Os arquivos são: mondrian.jar log4j-.2.8.jar commons-logging-.0.4.jar eigenbase-xom.jar eigenbase-resgen.jar eigenbase-properties.jar 52

Figura A. - Arquivos da pasta lib dentro do arquivo mondrian.war Dentro da pasta C:\mondrian-3.2..3885\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-connectorjava-5..0.jar) deve-se copiar este arquivo para a pasta c:\install_foodmart.também copiar o arquivo mondrian- 3.2..3885\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 Figura A.3 - Pasta de instalação com arquivos copiados 53

Pode-se copiar e colocar o script (Código A.) 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.) 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. - Script para carga de dados na base foodmart do Mysql java -cp "mondrian.jar;log4j-.2.8.jar;commons-logging-.0.4.jar;eigenbasexom.jar;eigenbase-resgen.jar;eigenbase-properties.jar;mysql-connector-java-5..0.jar" mondrian.test.loader.mondrianfoodmartloader -verbose -tables -data -indexes - jdbcdrivers=com.mysql.jdbc.driver -inputfile=foodmartcreatedata.sql - outputjdbcurl="jdbc:mysql://localhost/foodmart?user=foodmart&password=foodmart" 54

APÊNDICE B - CONECTANDO O ANALYSIS SERVICES COM O MYSQL. Instalando o MySQL Connector/NET. A instalação deve ser feita em um computador que já tenha o Visual Studio funcionando. O objetivo desta instalação é possibilitar a conexão do Analysis Services Services e do Visual Studio ao banco de dados MySQL. Dessa forma é possível criar cubos OLAP utilizando fonte de dados (i.e., DataSource) do MySQL. Para instalar é necessário baixar o MySQL Connector/NET disponível no site http://dev.mysql.com/downloads/connector/net/. É importante fechar a ferramenta Visual Studio antes de instalar o conector. Execute o arquivo baixado para iniciar a instalação e Escolha o tipo de instalação completa (Figura B.). Figura B. - Iniciando a instalação do MySQL Connector/NET 55

2. Configurando a conexão do MySQL no Visual Studio Crie um novo projeto no Visual Studio e clique com o botão direito do mouse sobre Data Sources e selecione New Data Sources. Para o provider escolha MySQL Data Provider. Clique no botão OK e informe os dados usuários e senha e o nome da base de dados foodmart do MySQL. Este usuário deve ter permissão de acesso à base foodmart. Na tela Connection Manager clique em All e mude a propriiedade SQL Server Mode para true. As figuras a seguir mostram etapas para a configuração. Figura B.2 - Data Source com MySQL Data Provider 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" Figura B.5 - Testando a conexão com o MySQL Figura B.6 - Definindo credenciais de acesso para o Data Source 57

Figura B.7 - Finalizando a instalação Após estes procedimentos a base estará acessível e os dados disponíveis para criação de cubos (Figura B.8). O processo de criação do cubo segue o procedimento normal utilizado com outras fontes de dados. Figura B.8 - Data Source criado para foodmart Figura B.9 - Seleção de tabelas para Data Source View 58

Figura B.0 - Data Source View com tabelas de foodmart É preciso criar uma regra de acesso e selecionar os usuários ou grupo de usuários que podem fazer consultas no cubo através de XMLA. Neste projeto do cubo Sales foi criada uma regra denominada XMLA_Access e foi liberado o acesso para todos os usuários. Figura B. - Regra XMLA_Access (Tela ) Figura B.2 - Regra XMLA_Access (Tela 2) 59

APÊNDICE C - CONFIGURAÇÃO DO IIS PARA ACESSO HTTP XMLA Aplicações clientes não podem usar as bibliotecas de cliente do Analysis Services Services (e.g., um aplicativo Java executado em um servidor Linux). Neste caso usase-se o SOAP e o XML/A em uma conexão HTTP direta a uma instância do Analysis Services Services. A seguir é a presentado o processo de configuração do acesso XMLA para o Analysis Services. A maneira mais fácil de instalar o IIS é através da opção Painel de Controle\Programas\Ativar desativar recursos do Windows (Figura C.). Para fins deste trabalho, foi utilizado o IIS na versão 7. Este servidor foi configurado para responder solicitações na porta 80. Figura C. - Iniciando instalação do IIS Os recursos mínimos que devem ser instalados estão localizados na pasta do Internet Information Services, são eles: Ferramentas de Gestão, web. Extensibilidade NET, ASP.NET, extensões ISAPI, Autenticação básica e Windows Autenticação (ver Figura C.2). Figura C.2 - Configurações mínimas para o IIS 60

Encerrada a instalação do IIS, deve-se criar um pool de aplicativos para a aplicação. Para isso é preciso acessar a tela de configuração do IIS (ver Figura C.2). Isso pode ser feito de duas formas: a primeira é executando o comando inetmgr.exe (através do Prompt de Comando do Windows) e a segunda é clicar com o botão direito do mouse sobre o ícone meu computador e selecionar a opção gerenciar, em seguida selecionar serviços e aplicativos e o gerenciador de serviços de informações da internet (ver Figura C.3). Depois disso basta posionar o mouse sobre Pools de Aplicativos e Adicionar pool de aplicativos, e fornecer um nome, por exemplo, olap (ver Figura C.4). Figura C.3 - Iniciando o gerenciador do IIS Figura C.4 - Adicionando pool de aplicativos no IIS 6

É preciso copiar alguns arquivos que serão a base do website que fornece o acesso HTTP XMLA. Estes arquivos estão localizados na pasta onde foi instalado o servidor SQL (e.g. C:\Program Files\Microsoft SQL Server\MSAS0.MSSQLSERVER\OLAP\bin\isapi) na subpasta \OLAP\bin\isapi (Figura C.5). Basta copiar todos os arquivos desta pasta e colar em uma nova pasta sob o diretório raiz do site padrão. Figura C.5 - Copiando arquivos do mecanismo XMLA Para encontrar a pasta de destino para estes arquivos copiados devese clicar sobre o nome do site no gerenciador de configuração e pressionando Explorar. Criar uma nova pasta chamada olap e colar os arquivos copiados. São estes arquivos que fornecem o mecanismo do XMLA (ver Figura C.6). Figura C.6 - Colando arquivos copiados na pasta olap do site padrão IIS Também deve-se ter certeza de que o usuário que executa o serviço IIS tem permissão para ler os arquivos na pasta. Verifique as permissões indo até a seção segurança das propriedades na pasta pai (a raiz da web). Se as permissões não estiverem corretas o servidor emite uma mensagem de erro informando que os arquivos não podem ser encontrados ou não há permissão de acesso para os arquivos. 62

Expanda o site da Web padrão, pressionar atualizar e localize a pasta olap (Figura C.7). Posicione o mouse sobre a pasta olap e com botão direito do mouse e pressione a opção Converter para Aplicativo (Figura C.8). Após a conversão será exibida uma tela conforme mostra a Figura C.9. Figura C.7 - Pasta olap selecionada para conversão de aplicativo Figura C.8 - Converter para Aplicativo 63

Figura C.9 - Concluindo conversão para aplicativo no IIS Também é preciso adicionar um manipulador para para todas as DLLs (*.dll) do site. Selecione a pasta olap e do IIS pressionar Configurações Mapeamentos (Figura C.0). No lado direito da tela, encontra-se um link Adicionar mapa de script. Basta clique no link e em seguida preencher os campos conforme mostra a Figura C.. Feito isso deve-se verificar se o acesso HTTP XMLA já está funcionando.para isso basta digitar a url http://localhost/olap/msmdpump.dll em um navegador web (Figura C.2). Figura C.0 - Manipulador para dlls do site 64

Figura C. - Mapeamento de Script Figura C.2 - Teste de acesso HTTP XMLA 65

APÊNDICE D - INSTALAÇÃO E CONFIGURAÇÃO DO MONDRIAN Para instalar o Mondrian é preciso atender aos seguintes prérequisitos: Java Development Kit (JDK) Apache Tomcat (com driver JDBC no diretório tomcat\lib) Arquivo mondrian-3.2..3885.zip (disponível em http://sourceforge.net/projects/mondrian/files/mondrian/mondrian -3.2..3885/ ) Ter baixado o arquivo mysql-connector-java-5..0.jar (disponível em http://dev.mysql.com/downloads/connector/j/ ) O promeiro passo é descompactar o arquivo do Mondrian baixado: mondrian-3.2..3885.zip. Por exemplo, se descompactado na raiz do diver C:\, a pasta do Mondrian será C:\mondrian-3.2..3885 e o conteúdo da pasta semelhante a mostrado na Figura D.. Figura D. - Arquivos do Mondrian descompactados Em seguida copiar o arquivo C:\mondrian- 3.2..3885\lib\mondrian.war, para a pasta tomcat\webapps. Uma vez que este arquivo é copiado e o tomcat está sendo executado, automaticamente o tomcat irá criar uma pasta e descompactar o arquivo mondrian.war dentro da pasta 66

tomcat\webapps, conforme mostra a Figura D.2. Também deve ser copiado para o servidor tomcat o arquivo mysql-connector-java-5..0.jar (jdbc do MySQL) para a pasta tomcat\lib (ver Figura D.3). Figura D.2 - Pasta do Mondrian criada pelo arquivo mondrian.war no servidor Tomcat Figura D.3 - Conector jdbc MySQL na pasta lib do Tomcat A especificação XMLA permite a um provedor de XMLA ter múltiplas fontes de dados, mas alguns clientes, especialmente os com base em ADOMD.NET, só pode se conectar à primeira fonte de dados declarada. Portanto, recomenda-se que utilize apenas uma fonte de dados de origem, contendo vários catálogos, se necessário. Considera-se nesta etapa de configuração que a fonte de dados JDBC já está instalada. Editar o arquivo datasource.xml que fica dentro da pasta tomcat\webapps\mondrian\web-inf. Neste exemplo (ver Quadro D.) foi utilizado o usuário root com a senha mysql. 67

Quadro D. - Arquivo datasource.xml do Mondrian configurado para conectar MySQL <?xml version=".0"?> <DataSources> <DataSource> <DataSourceName>Provider=Mondrian;DataSource=MondrianFoodMart;</ DataSourceName> <DataSourceDescription>Mondrian FoodMart Data Warehouse</DataSourceDescription> <URL>http://localhost:8080/mondrian/xmla</URL> <ProviderName>Mondrian</ProviderName> <ProviderType>MDP</ProviderType> <AuthenticationMode>Unauthenticated</AuthenticationMode> <Catalogs> <Catalog name="foodmart"> <DataSourceInfo> Provider=mondrian; Jdbc=jdbc:mysql://localhost/foodmart; JdbcUser=root; JdbcPassword=mysql; JdbcDrivers=com.mysql.jdbc.Driver </DataSourceInfo> <Definition> </Definition> /WEB-INF/queries/FoodMart.xml </Catalog> </Catalogs> </DataSource></DataSources> A seguir são descritos alguns dos tags do arquivo datasource.xml, necessários para configurar a conexão do Mondrian com as fontes de dados: DataSourceName: refere-se ao nome da fonte de dados para o Mondrian, este nome é utlizado na url de conexão com o servidor. URL: a URL que será usado para se conectar à fonte de dados OLAP via definição do Datasource. DataSourceInfo: contém os detalhes relacionados com o prestador do serviço XMLA, como provedor, JDBC DataSource, usuário, senha, tipo de driver. Catalog name: refere-se ao arquivo que contém definições relacionadas com as dimensões, hierarquias e cubos que serão utilizadas. Este é um arquivo tipo xml deve estar dentro da pasta WEB-INF/queries/ do Mondrian. Por exemplo, o arquivo FoodMart.xml, utilizado nesta dissertação. 68

Outros arquivos do Mondriam que estão na pasta tomcat\webapps\mondrian\web-inf\queries, também precisam ser modificados são eles: fourhier.jsp, mondrian.jsp, colors.jsp e arrows.jsp. Os detalhes das modificações destes e outros arquivos podem ser observados a seguir. Localize as seguintes linhas: <jp:mondrianquery jdbcdriver="sun.jdbc.odbc.jdbcodbcdriver" jdbcurl="jdbc:odbc:mondrianfoodmart" INF/queries/FoodMart.xml"> id="query0" cataloguri="/web- Modifique para <jp:mondrianquery id="query0" jdbcdriver="com.mysql.jdbc.driver" jdbcurl="jdbc:mysql://localhost/foodmart?user=foodmart&password=foodma rt" cataloguri="/web-inf/queries/foodmart.xml"> Edite o arquivo testrole.jsp na tomcat\webapps\mondrian\webinf\queries, e localize as linhas <jp:mondrianquery jdbcdriver="sun.jdbc.odbc.jdbcodbcdriver" jdbcurl="jdbc:odbc:mondrianfoodmart" INF/queries/FoodMart.xml" role="california manager"> id="query0" cataloguri="/web- Modifique para <jp:mondrianquery id="query0" jdbcdriver="com.mysql.jdbc.driver" jdbcurl="jdbc:mysql://localhost/foodmart?user=foodmart&password=foodma rt" cataloguri="/web-inf/queries/foodmart.xml" role="california manager"> Edite o a arquivo tomcat\webapps\mondrian\web-inf\datasources.xml. No tag <datasourceinfo> o datasource padrão deve ser a base de dados foodmart <DataSourceInfo>Provider=mondrian;Jdbc=jdbc:mysql://localhost/f oodmart;jdbcuser=foodmart;jdbcpassword=foodmart;jdbcdrivers=com.mysql. jdbc.driver;</datasourceinfo> Edite o arquivo tomcat\webapps\mondrian\web-inf\mondrian.properties. Localize e connectionstring property o padrão para a base de dados foodmart deve ser com segue: 69

mondrian.test.connectstring=provider=mondrian;jdbc=jdbc:mysql://localh ost/foodmart;jdbcuser=foodmart;jdbcpassword=foodmart;jdbcdrivers=com.m ysql.jdbc.driver;catalog=/web-inf/queries/foodmart.xml; Edite o arquivo tomcat\webapps\mondrian\web-inf\web.xml. Modifique todas as ocorrências da string @mondrian.webapp.connectstring@, substituindo pelo detalhes para conexão com a base de dados foodmart. Isto será necessário para o parâmetro de contexto ConnectString e as secções de servlet MDXQueryServlet do arquivo, por exemplo: <context-param> <param-name>connectstring</param-name> <paramvalue>provider=mondrian;jdbc=jdbc:mysql://localhost/foodmart;jdbcuser= foodmart;jdbcpassword=foodmart;catalog=/web- INF/queries/FoodMart.xml;JdbcDrivers=com.mysql.jdbc.Driver;</paramvalue> </context-param> <servlet> <servlet-name>mdxqueryservlet</servlet-name> <servletclass>mondrian.web.servlet.mdxqueryservlet</servlet-class> <init-param> <param-name>connectstring</param-name> <paramvalue>provider=mondrian;jdbc=jdbc:mysql://localhost/foodmart;jdbcuser= foodmart;jdbcpassword=foodmart;jdbcdrivers=com.mysql.jdbc.driver;catal og=/web-inf/queries/foodmart.xml;</param-value> </init-param> </servlet> Testando o acesso ao Mondrian OLAP Server Após todas as modificações serem efetuadas nestes arquivos já é possível acessar o Mondrian através de um navegador (ver Figura D.4 e Figura D.5) e testar o funcionamento do Mondrian com a base de dados foodmart do MySQL. 70

Figura D.4 - Navegador acessando o Mondrian OLAP Server Figura D.5 - Mondrian OLAP Server exibindo dados da base foodmart 7