Operadores GeoMDQL

Dos operadores propostos no Cap´ıtulo 5, foram implementamos na arquitetura Golapware os seguintes: i) Topol´ogicos, descritos na Se¸c˜ao 5.3.1.1; ii) Cardinais, descritos na Se¸c˜ao 5.3.1.2; iii) M´etricos da Se¸c˜ao 5.3.1.3; e iv) Dos operadores que geram novas geometrias, apresentados na Se¸c˜ao 5.3.1.4, implementamos na camada de aplica¸c˜ao, o operador Clipping. Entretanto, por limita¸c˜ao de tempo, este operador ainda n˜ao foi totalmente integrado `a sintaxe da linguagem GeoMDQL.

Quanto aos operadores multidimensionais, listados na Se¸c˜ao 5.3.2, est˜ao dispon´ıveis na sin- taxe GeoMDQL todos os operadores originalmente definidos para a linguagem MDX [254]. Alguns desses operadores foram re-implementados para serem utilizados em consultas do tipo GEO (i.e. operadores DrillDownLevel, DrillUpLevel, Members, Children e Siblings) e GEOMD de Integra¸c˜ao (i.e. operadores Members, Children e Siblings).

Dos operadores geogr´aficos e multidimensionais propostos na Se¸c˜ao 5.3.3, est˜ao dispon´ıveis na sintaxe GeoMDQL os operadores LowDistance, TopDistance, RankArea, RankPerimeter, RankLength, MaxArea, MinArea, MaxPerimeter, MinPerimeter, MaxLength, MinLength, Av- gArea, AvgPerimeter, AvgLength, MedianArea, MedianPerimeter, MedianLength, ModeArea, ModePerimeter e ModeLength. O Operador Drillout tamb´em foi implementado, por´em, sem a op¸c˜ao de uni˜ao de geometrias. Al´em disso, o operador NGeoGrouping foi implementado para objetos geogr´aficos do tipo Ponto, utilizando o algoritmo de K-Means [7]. Por´em, ele n˜ao est´a totalmente integrado `a interface da linguagem GeoDMQL. Percebemos que este operador pode ser estendido, no sentido de permitir, por exemplo, a cria¸c˜ao de grupos a partir de um ponto fixo, determinando a quantidade de elementos de cada grupo ou ainda, analisando outras propriedades relacionadas ao objeto para gerar os agrupamentos. Finalmente, foi tamb´em foi implementado o operador NNNeighbors, para objetos geogr´aficos do tipo Ponto, por´em, n˜ao foi totalmente integrado com a interface da linguagem GeoMDQL por limita¸c˜oes de tempo.

Alguns resultados de consultas na sintaxe GeoMDQL, envolvendo estes operadores s˜ao dados na Se¸c˜ao 6.4.

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA

Esta se¸c˜ao discorre sobre os detalhes relacionados com a implementa¸c˜ao da arquitetura Golap- ware (apresentada no Cap´ıtulo 5), na qual est´a inserida a linguagem GeoMDQL. A seguir, s˜ao apresentados aspectos de implementa¸c˜ao de cada uma das camadas da nossa arquitetura.

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 97

6.3.1 Camada I - Data Warehouse Geogr´afico

O Data Warehouse Geogr´afico da camada (I) foi implementado de acordo com as especifica¸c˜oes apresentadas no Cap´ıtulo 4 e em [283, 81]. Todos os esquemas de DWG discutidos na Se¸c˜ao 6.4, s˜ao baseados no modelo formal de DWG detalhado no Cap´ıtulo 4, que estende o arcabou¸co GeoDWFrame [115] com a inclus˜ao de medidas espaciais.

Para a modelagem, valida¸c˜ao e gera¸c˜ao dos scripts SQL para a cria¸c˜ao dos esquemas dos DWG implementados em nossa pesquisa, foi utilizada a ferramenta CASE GeoDWCASE [119]. Todas as modelagens dos exemplos pr´aticos listados na Se¸c˜ao 6.4, foram realizadas com GeoD- WCASE. Os principais pontos de GeoDWCASE s˜ao a utiliza¸c˜ao de estere´otipos que facilitam a modelagem, a valida¸c˜ao do esquema realizada com OCL [203], e a gera¸c˜ao autom´atica dos esquemas. Atualmente, os esquemas podem ser gerados para Oracle, PostgreSQL e MySQL, obedecendo `as restri¸c˜oes das extens˜oes espaciais de cada um destes SGBD. Maiores detalhes sobre a ferramenta GeoDWCASE, a especifica¸c˜ao, a valida¸c˜ao e a gera¸c˜ao dos scripts SQL de um DWG, podem ser analisados em [283, 81, 119].

Atualmente, ´e utilizado o SGBD PostgreSQL [228] com sua extens˜ao para tratamento ge- ogr´afico, o PostGis [154] por ser um SGBD aberto e extens´ıvel. Mas qualquer outro SGBD com extens˜ao espacial pode ser adotado. Al´em disso, a extra¸c˜ao e carga do DWG ainda ´e realizada de forma manual, utilizando scripts baseados na linguagem PL/pgSQL do PostgreSQL [228].

6.3.2 Metadados

A camada de metadados desempenha uma importante fun¸c˜ao na integra¸c˜ao entre os proces- samentos geogr´afico e multidimensional. Na base de metadados, est˜ao registradas informa¸c˜oes importantes sobre os dados geogr´aficos e multidimensionais, tais como tipos de dados e endere¸co do armazenamento. Outra funcionalidade importante ´e o armazenamento das defini¸c˜oes sobre os cubos de dados.

A especifica¸c˜ao dos cubos de dados geogr´aficos e multidimensionais segue as defini¸c˜oes do nosso modelo GeoMDCube [81], apresentado no Cap´ıtulo 4. Atualmente, a implementa¸c˜ao da fonte de metadados ´e baseada na tecnologia XML [294], dessa forma, os cubos de dados geogr´aficos e multidimensionais s˜ao definidos e armazenados em arquivos XML. A principal justificativa para o uso desta tecnologia ´e o fato de que estamos estendendo o servidor OLAP Mondrian [224], e este j´a utiliza XML para a manipula¸c˜ao de metadados. Al´em de servirem para definir a estrutura do cubo de dados, as informa¸c˜oes contidas no arquivo XML em quest˜ao s˜ao usadas para gerar os scripts SQL que s˜ao utilizados para acessar as tabelas do DWG para recuperar os dados geogr´aficos e multidimensionais e gerar as devidas agrega¸c˜oes de dados definidas para cada cubo de dados. A Figura 6.1 exibe, em um digrama gerado pela ferramenta XML Spy [8], o elemento Cube do esquema XML utilizado pelo servidor OLAP Mondrian,

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 98

com as extens˜oes realizadas para se adequar `a arquitetura Golapware. Este esquema guia a especifica¸c˜ao dos cubos e realiza a valida¸c˜ao dos mesmos.

Figura 6.1 Esquema XML utilizado para validar os cubos geogr´aficos e multidimensionais

Como podemos verificar na Figura 6.1, para o elemento Cube, foram adicionados dois atrib- utos, chamados isGeoCube e geoCube, os quais s˜ao utilizados, respectivamente, para informar se um cubo ´e geogr´afico e qual seu nome. De forma semelhante, para o elemento Dimension,

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 99

foram adicionados os elementos isGeoDimension e geoDimension, para indicar se a dimens˜ao do cubo ´e geogr´afica e qual ´e o nome da dimens˜ao. Para o elemento Hierarchy, adicionamos os elementos isGeoHierarchy (que indica se a hierarquia ´e geogr´afica ou n˜ao) e geoHierarchy (que representa o nome da hierarquia geogr´afica). Por sua vez, o elemento Level tamb´em foi estendido com os atributos isGeoLevel, geoLevel, geometryColumn e geoJoinColumn, os quais s˜ao utilizados para, respectivamente: (i) indicar se um n´ıvel ´e ou n˜ao geogr´afico, (ii) informar o nome da tabela dimens˜ao do DWG que cont´em os dados geogr´aficos deste n´ıvel, (iii) indicar qual coluna da tabela dimens˜ao ´e respons´avel por armazenar as geometrias dos membros geogr´aficos e (iv) representar a chave prim´aria da tabela dimens˜ao utilizada para definir o n´ıvel. Por fim, o elemento Measure foi alterado para conter um atributo chamado isGeoMeasure, que indica se ele ´e ou n˜ao geogr´afico. Com as especifica¸c˜oes implementadas neste esquema XML, ´e poss´ıvel definir um esquema com um ou mais cubos de dados, e para cada cubo s˜ao definidas uma ou mais dimens˜oes. Cada dimens˜ao possui suas hierarquias, cada hierarquia possui n´ıveis, e assim por diante, conforme define o modelo GeMDQCube [81] (ver Cap´ıtulo 4).

Baseado no esquema XML apresentado na Figura 6.1, foi definido um conjunto de classes JAVA [190], que s˜ao respons´aveis pela manipula¸c˜ao das instˆancias deste esquema. Este m´odulo possui grande intera¸c˜ao com o mecanismo de processamento geogr´afico e multidimensional, definido na camada (II) da arquitetura, que ser´a detalhada na Se¸c˜ao 6.3.3. Na Figura 6.2, ´e dado um exemplo de instˆancia XML, que especifica um cubo de dados a partir do DWG do estudo de caso DWG RECIFE, apresentado na Se¸c˜ao 6.4.3.

6.3.3 Camada II - Processamento Multidimensional e Geogr´afico

Na segunda camada (II) da nossa arquitetura est´a o mecanismo de processamento geogr´afico e multidimensional, respons´avel por processar as consultas expressas de acordo com a sintaxe GeoMDQL. A implementa¸c˜ao desta camada foi realizada atrav´es da extens˜ao do servidor OLAP Mondrian [224] para prover suporte ao processamento de dados geogr´aficos.

A escolha do servidor Mondrian para a cria¸c˜ao do nosso servidor SOLAP se deve ao fato do mesmo ser uma ferramenta de c´odigo aberto, independente de plataforma e compat´ıvel com a linguagem MDX, que serviu de base para a cria¸c˜ao da linguagem GeoMDQL. Como o Mondrian foi projetado para ser de c´odigo aberto, extens´ıvel e independente de plataforma, a sua extens˜ao pˆode ser realizada com maior facilidade. Al´em disso, a arquitetura deste servidor conta com um m´odulo que permite a adi¸c˜ao de fun¸c˜oes definidas pelo usu´ario (i.e. UDF - User Defined Functions). Dessa forma, foi poss´ıvel implementar fun¸c˜oes externas e utilizar as mesmas nas consultas GeoMDQL. No que se refere ao processamento espacial, est˜ao utilizados os recursos do PostGis [241], que ´e a extens˜ao espacial do PostgreSQL [228]. A principal justificativa para esta escolha, se deve a estas ferramentas serem de dom´ınio p´ublico, e caso haja necessidade de implementar alguma outra funcionalidade para processamento espacial, isso pode ser realizado

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 100

Figura 6.2 Exemplo de instˆancia XML definindo um Cubo de Dados

alterando diretamente o PostgreSQL e o PostGIS, uma vez que ambos s˜ao abertos e extens´ıveis. No processador de consultas, um parser escrito em Java, implementa a gram´atica da lin- guagem GeoMDQL, apresentada no Cap´ıtulo 5. O parser realiza a an´alise l´exica, traduzindo o arquivo fonte que cont´em a gram´atica da linguagem em lexemas e tokens, o que permite que os tokens sejam reconhecidos. Este parser tamb´em faz a an´alise sint´atica, que ´e respons´avel por verificar quando uma senten¸ca faz parte da gram´atica da linguagem. Ap´os realizar o pars- ing, o processador realiza a valida¸c˜ao sint´atica dos operadores da linguagem, confrontando, por exemplo, tipo e quantidade dos parˆametros reais com os parˆametros formais. Em seguida, o processador da consulta identifica qual ´e o tipo da requisi¸c˜ao (i.e. GEO, MD, ou GEOMD de integra¸c˜ao ou mapeamento), os quais foram detalhados no Cap´ıtulo 5.

Ap´os realizar o parsing e a classifica¸c˜ao de uma requisi¸c˜ao GeoMDQL, o mecanismo de processamento faz uso do gerenciador de metadados para recuperar as informa¸c˜oes necess´arias e finalizar o processamento e a execu¸c˜ao da consulta. Com essas informa¸c˜oes, s˜ao geradas in- stru¸c˜oes utilizadas pelo m´odulo de processador de consultas para recuperar os dados geogr´aficos e/ou multidimensionais solicitados na requisi¸c˜ao. O acesso aos metadados ´e realizado atrav´es de um m´odulo, tamb´em implementado em Java, que segue as defini¸c˜oes do esquema XML da Se¸c˜ao 6.3.2 e oferece um conjunto de classes para manipular as instˆancias XML que armazenam

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 101

as informa¸c˜oes sobre os cubos geogr´aficos e multidimensionais.

Como a implementa¸c˜ao do servidor Mondrian utiliza a tecnologia ROLAP (Relational OLAP), as consultas GeoMDQL s˜ao transformadas em requisi¸c˜oes SQL que, atrav´es de uma conex˜ao JDBC [189], s˜ao utilizadas para recuperar os dados armazenados em tabelas relacionais no DWG. Dessa forma, ao analisarmos as implementa¸c˜oes deste servidor, percebemos que sua extens˜ao poderia ser realizada, em linhas gerais, de duas formas: i) alterando sua estrutura principal, respons´avel por gerar as instru¸c˜oes SQL para adicionar as restri¸c˜oes relacionadas aos operadores geogr´aficos ou ii) utilizar o recurso de UDF - User Defined Functions, que permite que novas fun¸c˜oes sejam desenvolvidas e incorporadas ao servidor, sem alterar o c´odigo fonte original.

A primeira op¸c˜ao resultaria em um enorme esfor¸co de implementa¸c˜ao, al´em de modificar consideravelmente, o c´odigo fonte original, o que poderia implicar, principalmente, na reescrita de c´odigo para adequar a solu¸c˜ao a uma nova vers˜ao do servidor Mondrian. Estas modifica¸c˜oes tamb´em implicariam em altera¸c˜oes no sistema de agrega¸c˜ao e cache do Mondrian [224]. Dessa forma, optamos por seguir a segunda op¸c˜ao, realizando o m´ınimo de altera¸c˜oes poss´ıveis no c´odigo fonte do servidor, mantendo o novo c´odigo em pacotes separados e utilizando o recurso de UDF do Mondrian como base para a extens˜ao.

Assim, o reposit´orio de metadados e o m´odulo de gerˆencia de metadados, s˜ao os elementos principais do nosso Servidor SOLAP e s˜ao utilizados a todo instante durante o processamento das consultas. O exemplo dado a seguir, demonstra como o processador de consultas utiliza os metadados para montar as instru¸c˜oes SQL para recuperar os dados do DWG:

A instru¸c˜ao [Localizacao].[Municipio].[Recife] faz referˆencia ao membro geogr´afico Recife, do n´ıvel Municipio, pertencente `a dimens˜ao Localizacao. Estas informa¸c˜oes est˜ao todas armazenadas no documento XML que define o cubo de dados, conforme pode ser observado na especifica¸c˜ao do cubo apresentado na Figura 6.2. Dessa forma, para recuperar este membro geogr´afico e sua respectiva geometria, o processador de consultas gera uma instru¸c˜ao SQL semelhante `a apresentada na seq¨uˆencia:

SELECT temp.nomeMunicipio, pgd municipio.geo municipio FROM pgd municipio, (SELECT DISTINCT cgd localizacao.nm municipio AS nomeMunicipio ,

cgd localizacao.id municipio AS numeroMunicipio FROM cgd localizacao) AS temp

WHERE temp.numeroMunicipio = pgd municipio.id municipio AND temp.nomeMunicipio LIKE ’Recife’

´

E assim que instru¸c˜oes GeoMDQL s˜ao mapeadas para SQL, que nosso mecanismo de processamento geogr´afico e multidimensional (da camada (II) da arquitetura Golapware) responde `as consultas do tipo GEOMD de Mapeamento e `as consultas do tipo GEO. Para as consultas do tipo MD, foi mantido o processamento original do Mondrian, uma vez que

6.3 IMPLEMENTAC¸ ˜AO DA ARQUITETURA 102

este tipo de consulta ´e especificada e processada da mesma forma que uma consulta MDX. Por sua vez, as requisi¸c˜oes do tipo GEOMD de Integra¸c˜ao s˜ao processadas utilizando os operadores GeoMDQL implementados, os quais foram listados na Se¸c˜ao 6.2.2. Atualmente, os mapeamentos s˜ao realizados somente para o dialeto SQL espacial do SGBD PostgreSQL [228]. A implementa¸c˜ao dos componentes para otimiza¸c˜ao, gerenciamento de cache e gerencia- mento de agrega¸c˜ao n˜ao foi realizada, mas sua especifica¸c˜ao visa prover um mecanismo de cache e reescrita de consultas para melhorar o desempenho dos processamentos.