GeoMDQL - Centro de Ciências Exatas e Tecnologia

Transcrição

Universidade Federal de Pernambuco
Centro de Ciências Exatas e da Natureza
Departamento de Informática
Pós-graduação em Ciência da Computação
GEOMDQL: UMA LINGUAGEM DE
CONSULTA GEOGRÁFICA E
MULTIDIMENSIONAL
Joel da Silva
TESE DE DOUTORADO
Recife
Sexta-feira, 12 de Setembro de 2008
Universidade Federal de Pernambuco
Centro de Ciências Exatas e da Natureza
Departamento de Informática
Joel da Silva
GEOMDQL: UMA LINGUAGEM DE CONSULTA GEOGRÁFICA E
MULTIDIMENSIONAL
Trabalho apresentado ao Programa de Pós-graduação em
Ciência da Computação do Departamento de Informática
da Universidade Federal de Pernambuco como requisito
parcial para obtenção do grau de Doutor em Ciência da
Computação.
Orientadora: Prof. Dr . Valéria Cesário Times
Co-orientadora: Prof. Dr . Ana Carolina Salgado
Recife
Sexta-feira, 12 de Setembro de 2008
SILVA, Joel da
GEOMDQL: Uma Linguagem de Consulta
geográfica e Multidimensional / Joel da Silva. Recife : O Autor, 2008.
xviii, 175 folhas : il., fig., tab.
Tese (doutorado) - Universidade
Federal
Pernambuco. CIn. Ci^
encia da Computaç~
ao, 2008.
de
Inclui bibliografia, glossário e ap^
endice.
1. Banco de Dados. 2. Linguagem de Consulta.
3. Processamento multidimensional e espacial.
4. Data warehouse geográfico. I. Tı́tulo.
025.04
CDD(22.ed.)
MEI2008-105
Dedico esta Tese para minha Famı́lia, base do meu ser,
especialmente para meus pais Claudio e Maristella.
Agradecimentos
Primeiramente, agradeço a Deus por tudo que me foi concedido.
Agradeço especialmente as professoras Valéria Times e Ana Carolina Salgado pela confiança, pelo
apoio e pela orientação.
Aos professores Robson Fidalgo e Anjolina Oliveira pelo auxílio e pelas discussões que colaboraram
para o enriquecimento do meu trabalho.
Aos colegas e amigos do Grupo GOLAPA, Vivianne Medeiros, Clenúbio Souza, José Tiago, Fabio
Rocha, Rafael Leão da Fonseca, pelo auxílio e pelas produtivas discussões. E também, aos colegas do
MapDengue Petrus, Webster, Rafael Jacinto, Eduardo e José Antônio.
A toda minha família, que sempre me apoiou e me deu forças, em especial aos meus pais Claudio e
Maristella, as minhas irmãs Miriam e Gabrielly e aos meus tios Hermes e Neusa. Também, agradeço a
minha namorada Jessika Castro, pelo carinho e compreensão.
Aos meus irmãos Cleber Zanchettin, Tarcisio Pinto Câmara e Ricardo Afonso pela amizade, companheirismo e pelo convívio saudável.
Aos amigos, Ricardo Ramos, André, Cristiano, Pedro, Maury, Vaninha e Ruben pela amizade e
confiança.
Ao Conselho Nacional de Desenvolvimento Científico e Tecnológico pela bolsa de doutorado
fornecida e ao Centro de Informática pela infraestrutura disponibilizada.
Enfim, agradeço a todos que, direta ou indiretamente, contribuíram para esta conquista.
A todos o meu Muito Obrigado!!
iv
"Deus nos fez perfeitos e não escolhe os capacitados, capacita os
escolhidos. Fazer ou não fazer algo só depende de nossa vontade e
perseverança."
— ALBERT EINSTEIN (Deus não Escolhe os Capacitados )
Resumo
Existem várias propostas na literatura visando a integração das funcionalidades e características pertinentes aos processamentos de dados analíticos (OLAP) e geográficos (SIG). O principal objetivo é
prover um ambiente único, com capacidades de processamento geográfico e multidimensional, para
dar suporte ao processo de tomada de decisões estratégicas. Este tipo de ambiente vem sendo referido
atualmente como SOLAP.
Entretanto, pelo fato destas duas tecnologias terem sido concebidas com propósitos distintos, a integração entre estes dois ambientes não é uma tarefa fácil, e mesmo com tantas pesquisas sendo desenvolvidas, temos alguns pontos em aberto que merecem ser explorados. A definição de modelos de
dados para Data Warehouse Geográficos é um dos items desta integração. Outro ponto inserido neste
contexto é a definição de funções de agregação para medidas geográficas. Estas funções são utilizadas
no momento da especificação dos cubos de dados multidimensionais e geográficos. Conseqüentemente,
também necessitamos de novos modelos de cubos de dados que possibilitem a associação de geometrias
aos fatos e aos membros dos níveis.
Uma das partes mais importantes desse processo de integração é a consulta aos dados. Porém, a
maioria das abordagens que almejam esta integração de processamento, não dispõe de uma linguagem de
consulta que possibilite a utilização simultânea, tanto de operadores multidimensionais como espaciais.
É neste contexto que se insere esta tese, na qual apresentamos: i) um modelo formal para definição de
DWG; ii) um conjunto de funções de agregação para medidas geográficas; iii) um modelo formal para
cubos de dados chamado GeoMDCube; e iv) uma linguagem de consulta geográfica-multidimensional
denominada GeoMDQL (Geographic Multidimensional Query Language). GeoMDQL estende e integra,
em uma única sintaxe, os principais operadores multidimensionais e espaciais presentes na maioria das
ferramentas e em ambientes disponíveis atualmente para processamento multidimensional e geográfico.
GeoMDQL é baseada em padrões bem estabelecidos como ( MDX Multidimensional Expressions) e
OGC Simple Features for SQL.
As idéias propostas foram aplicadas na prática, por meio da implementação de uma arquitetura
SOLAP chamada Golapware e o desenvolvimento de estudo de caso baseado em dados de aplicações
reais. Dessa forma, foi possível demonstrar a utilização dos modelos, das funções e da linguagem de
consulta e operadores SOLAP discutidos nesta tese.
Palavras-chave: GeoMDQL, Data Warehouse Geográfico, GeoMDCube, SOLAP.
vi
Abstract
There have been a number of proposals in the literature aimed at integrating functionality and characteristics related to analytical (OLAP - Online Analytical Processing) and geographic (GIS- Geographic Information Systems) data processing. The main goal is to provide a unique environment with geographicmultidimensional processing capabilities in order to provide a means of supporting strategic decisionmaking processes. This kind of environment has been named SOLAP (Spatial OLAP).
However, due to the fact that these two technologies were conceived with different purposes in
mind, the interaction of the two environments is not an easy task and even with so much research being
developed, there remain unresolved issues that deserves exploration. The definition of data models for
Geographic Data Warehouses (GDW) is one of the items of this integration. Another issue refers to
aggregation functions for geographic measures. These functions are currently used in the definition of
geographic and multidimensional data cubes. Consequently, we also need new models of data cubes that
allow the association of geometries to the facts and the members of the levels.
Data querying is one of the most important issues in this process. However, most approaches do
not have a query language that allows both multidimensional and spatial operators to be used simultaneously. The present thesis addresses this context, presenting: i) a formal model for GDW specification;
ii) a set of aggregation functions for geographic measures; iii) a formal model for data cubes named
GeoMDCube; and iv) a geographic-multidimensional query language named GeoMDQL (Geographic
Multidimensional Query Language). Using a single syntax, GeoMDQL extends and integrates the main
multidimensional and spatial operators found in most multidimensional and geographic processing tools
and environments. GeoMDQL is based on well-known standards such as the MDX (Multidimensional
Expressions) and OGC Simple Features for SQL.
The proposed ideas were applied in practice through the implementation of a SOLAP architecture
named Golapware and the development of a case study based on data from real applications. It was
possible to demonstrate the utilization of the models, functions, query language and SOLAP operators
discussed in this thesis.
Keywords:
GeoMDQL, Geographical and Multidimensional Query Language, Geographical Data
Warehouse, GeoMDCube, SOLAP.
vii
Sumário
1
Introdução
1
1.1
Contextualização
1
1.2
Motivação
2
1.3
Objetivos
4
1.3.1
Objetivo Geral
4
1.3.2
Objetivos Específicos
4
1.4
2
5
Operadores e Linguagens
8
2.1
Introdução
8
2.2
Linguagens de Consulta
8
2.2.1
Linguagens de Consulta Geográficas
8
2.2.2
Linguagens de Consulta Analítica-Multidimensional
2.3
2.4
3
Estrutura da Tese
11
Operadores
13
2.3.1
Operadores para Dados Geográficos
13
2.3.2
Operadores para Dados Multidimensionais
14
Considerações
16
Processamento Multidimensional e Geográfico
18
3.1
Introdução
18
3.2
JMap Spatial OLAP
18
3.3
MapWarehouse
21
3.4
GeWOlap
23
3.5
SOVAT
26
3.6
PQL
28
3.7
Piet
30
3.8
GOLAPA
31
3.9
Outras Propostas
34
3.10 Considerações
37
viii
SUMÁRIO
4
5
ix
Modelos de Dados e Funções de Agregação de Medidas
41
4.1
Introdução
41
4.2
Um Modelo de Dados Formal para Data Warehouse Geográfico
41
4.3
Funções de Agregação de Medidas Espaciais
48
4.3.1
Distributiva Escalar
49
4.3.2
Distributiva Espacial
50
4.3.3
Algébrica Escalar
52
4.3.4
Algébrica Espacial
53
4.3.5
Holística Escalar
53
4.3.6
Holística Espacial
54
4.4
O Modelo de Dados Formal GeoMDCube
56
4.5
Considerações
61
A Linguagem de Consulta GeoMDQL
62
5.1
Introdução
62
5.2
A Linguagem GeoMDQL
62
5.2.1
62
5.3
5.4
Sintaxe da Linguagem GeoMDQL
Operadores da Linguagem GeoMDQL
68
5.3.1
Operadores Geográficos
70
5.3.1.1
Operadores Topológicos
71
5.3.1.2
Operadores Cardinais
72
5.3.1.3
Operadores Métricos
72
5.3.1.4
Operadores que Geram Novas Geometrias
73
5.3.2
Operadores Multidimensionais
75
5.3.3
Operadores Geográficos e Multidimensionais (SOLAP)
76
Arquitetura do Processador da Linguagem GeoMDQL
81
5.4.1
Camada I - Data Warehouse Geográfico
81
5.4.2
Camada II - Processamento Multidimensional e Geográfico
82
5.4.2.1
Servidor SOLAP
83
Camada III - Interface com o Usuário
84
5.4.3.1
Gerenciador de Consultas
85
5.4.3.2
Gerenciador de Catálogos
86
5.4.3.3
Gerenciador de Resultados
86
5.4.3
5.4.4
Metadados
88
5.5
Tipos de Consultas GeoMDQL
88
5.6
Considerações
90
SUMÁRIO
6
Aspectos de Implementação
93
6.1
Introdução
93
6.2
Implementação dos Operadores e Funções
93
6.2.1
Funções de Agregação de Medidas
93
6.2.2
Operadores GeoMDQL
94
6.3
6.4
6.5
7
x
Implementação da Arquitetura
94
6.3.1
Camada I - Data Warehouse Geográfico
95
6.3.2
Metadados
95
6.3.3
Camada II - Processamento Multidimensional e Geográfico
97
6.3.4
Camada III - Interface
100
Aplicação Prática da Abordagem
102
6.4.1
DWG DATASUS
103
6.4.2
DWG LAMEPE
109
6.4.3
DWG RECIFE
112
6.4.4
DWG RPA1
115
Considerações
117
Conclusões e Trabalhos Futuros
119
7.1
Considerações Finais
119
7.2
Principais Contribuições
121
7.3
Trabalhos Futuros
122
A SINTAXE DA LINGUAGEM GEOMDQL
A.1 Sintaxe GeoMDQL Especificada em EBNF
B EXEMPLOS DE FUNÇÕES DE AGREGAÇÃO PARA MEDIDAS ESPACIAIS
146
146
153
B.1 Funções do Tipo Distributiva Espacial com Retorno Escalar
153
B.2 Funções do Tipo Distributiva Espacial com Retorno Espacial
154
B.3 Funções do Tipo Algébrica Espacial com Retorno Escalar
156
B.4 Funções do Tipo Algébrica Espacial com Retorno Espacial
157
B.5 Funções do Tipo Holística Espacial com Retorno Escalar
158
B.6 Funções do Tipo Holística Espacial com Retorno Espacial
159
C EXEMPLOS DE CONSULTA GEOMDQL
C.1 Exemplos de Consulta na linguagem GeoMDQL
160
160
C.1.1
Consultas MD
160
C.1.2
Consultas GeoMD de Mapeamento
163
C.1.3
Consultas GeoMD de Integração
164
Lista de Figuras
1.1
Organização da Tese
6
3.1
Estrutura de um Ambiente SOLAP (Adaptado de [248])
3.2
Interface Gráfica do JMap Spatial OLAP
20
3.3
Metamodelo Espacial e Multidimensional do MapWarehouse [251]
22
3.4
Esquema Estrela Estendido do MapWarehouse (Adaptado de [251])
23
3.5
Exemplo de Consulta na abordagem MapWarehouse
24
3.6
Interface Gráfica do MapWarehouse
25
3.7
Modelagem de um DWG para Análise da Mortalidade utilizando Dimensões e Medidas
19
Espaciais
25
3.8
Arquitetura GeWOlap
26
3.9
Arquitetura de Software da proposta SOVAT (Adaptado de [253] )
27
3.10 Interface Gráfica SOVAT
28
3.11 Instâncias dos Atributos Funcionais vendas_carro e vendas_brinquedos [111]
29
3.12 Exemplo de Consulta Piet
31
3.13 Exibição de Mapas no Piet
32
3.14 Arquitetura Golapa [113]
33
3.15 Exemplo de Consulta de Integração
35
4.1
Esquema de DWG para Acompanhamento de Precipitações e Alagamentos
43
4.2
Exemplo de um Esquema de DWG
45
4.3
Exemplos Adicionais para as Definições Formais
47
4.4
Classificação das Funções de Agregação
49
4.5
Exemplos de Funções de Agregação com Resultado Escalar
51
4.6
Exemplos de Funções de Agregação com Resultado Espacial
52
4.7
Exemplo de Funções Holísticas com Resultado Escalar
54
4.8
Exemplo Funções Holísticas com Retorno Espacial
55
4.9
Exemplo de Esquema de Dimensão
57
4.10 Exemplos de Nível Convencional
58
4.11 Exemplos de Níveis Geográficos
58
4.12 Exemplo de Fato Convencional
60
xi
LISTA DE FIGURAS
4.13 Um Exemplo de Fato Geográfico
xii
61
5.1
Principais Elementos da Gramática da Linguagem GeoMDQL
63
5.2
Exemplo de Consulta GeoMDQL
63
5.3
Elemento formula_specification da Gramática da Linguagem GeoMDQL
64
5.4
Exemplo de Definição de Fórmulas em GeoMDQL
64
5.5
Elemento axis_specification_list da Gramática da Linguagem GeoMDQL
65
5.6
Exemplo de Utilização de Funções em GeoMDQL
65
5.7
Elemento geomdql_expression da Gramática da Linguagem GeoMDQL
66
5.8
Elemento member_geometry da Gramática da Linguagem GeoMDQL
67
5.9
Exemplo de Consulta GeoMDQL Envolvendo o Elemento Geometry
67
5.10 A Arquitetura Golapware
82
5.11 Comparação entre GeoMDQL e GISOLAP-QL [104]
91
5.12 Comparação entre GeoMDQL e SQL Espacial do MapWarehouse [251]
92
6.1
Esquema XML utilizado para validar os cubos geográficos e multidimensionais
96
6.2
Exemplo de instância XML definindo um Cubo de Dados
98
6.3
Interface Gráfica da Arquitetura Golapware
101
6.4
DWG para Saúde Pública
103
6.5
Consulta GeoMDQL de Mapeamento Utilizando o Operador Filter
105
6.6
Ranking de Área, de População e de Distância
106
6.7
Drillout no Estado de Pernambuco
108
6.8
DrillDown no Resultado Exibido na (Figura 6.7)
109
6.9
DWG para Meteorologia
110
6.10 Exemplo de Consulta de Mapeamento com Ranking
111
6.11 Exemplo de Consulta de Integração com DrilldownMember, MaxArea e MinArea
113
6.12 DWG Dengue
114
6.13 Exemplo de Consulta Geográfica Baseada no Operador Geogrouping de GeoMDQL
115
6.14 Exemplo de Consulta Geográfica Baseada no Operador NNNeighbors de GeoMDQL
116
6.15 DWG registro de lotes urbanos
117
6.16 Exemplo de Consulta Geográfica Baseada no operador Clipping
118
C.1 Exemplo de Consulta MD com TopCount e Membros Calculados
161
C.2 Exemplo de Consulta MD com Análise de Pareto
162
C.3 Exemplo de Consulta GeoMD de Mapeamento com Análise de Pareto
164
C.4 Exemplo de Consulta GeoMDQL de Mapeamento
165
C.5 Ranking de Área e de População
166
C.6 Drillout Filter e Intersects
168
LISTA DE FIGURAS
C.7 Exemplo de Consulta com o operador MaxArea
xiii
169
C.8 Exemplo de consulta de integração com os operadores Intersect, Disjoint e AtNorthEastOf170
C.9 Exemplo de Consulta de integração utilizando o operador GeoIntersects
171
Lista de Tabelas
3.1
Comparação entre Propostas para Processamento Multidimensional e Geográfico
40
4.1
Funções Distributivas com Resultado Escalar
50
4.2
Funções Distributivas com Resultado Espacial
50
4.3
Funções Algébricas com Resultado Escalar
53
4.4
Funções Algébricas com Resultado Espacial
53
4.5
Funções Holísticas com Resultado Escalar
54
4.6
Funções Holísticas com Resultado Espacial
55
5.1
Operadores GeoMDQL sobrecarregados da linguagem MDX
75
B.1 Funções Distributivas com resultado Escalar (Combinação da função Count com operadores topológicos )
153
B.2 Funções Distributivas com resultado Escalar (Combinação da função Count com operadores cardinais )
154
B.3 Funções Distributivas com resultado Escalar (Combinação das funções Max e Min com
Operadores Topológicos)
154
B.4 Funções Distributivas com resultado Escalar (Combinação das funções Max e Min com
Operadores Cardinais)
155
B.5 Funções Distributivas com resultado Escalar (Combinação das funções Max, Min e Sum
com operadores do tipo unário escalar)
155
B.6 Funções Distributivas com resultado Escalar (Combinação da funções Max e Min com
o operador de distância)
156
B.7 Funções Distributivas com resultado Espacial ( Combinação do operador Sum com operadores topológicos)
156
B.8 Funções Distributivas com resultado Espacial ( Combinação do operador Sum com operadores cardinais)
156
B.9 Funções Algébricas com resultado Escalar (Combinação das funções Avg e Stdv com
operadores do tipo unário escalar)
157
B.10 Funções Algébricas com resultado Escalar (Combinação das funções Min_N e Max_N
com operadores do tipo unário escalar)
157
xiv
LISTA DE TABELAS
xv
B.11 Funções Algébricas com resultado Escalar (Combinação das funções Min_N e Max_N
com o operador de distância)
157
B.12 Funções Algébricas com resultado Espacial (Combinação das funções Min_N e Max_N
com operadores cardinais)
158
B.13 Funções Holísticas com resultado Escalar (Combinação da função rank com operadores
espaciais do tipo unário escalar)
B.14 Funções Holísticas com resultado Espacial
159
159
Glossário
Termo
Descrição
API
Application Program Interface
BD
Banco de Dados
CASE
Computer-aided Software Engineering
CWM
Common Warehouse Metamodel
DW
Data Warehouse
DDL
Data Definition Language
DWG
DW Geográfico
EBNF
Extended Backus - Naur Form
ETL
Extract Transform Load
GeoDWFrame Geographical DW Framework
GML
Geography Markup Language
GDW
Geographic Data Warehouse
GeoMDQL
Geographic and Multidimensional Query Language
GIS
Geographic Information Systems
GMLA
GML for Analysis
GOLAPA
Geographical Online Analytical Processing Architecture
GOLAPE
GOLAP Engine
GOLAPI
GOLAP Interface
GPL
Graphical Presentation Language
HTTP
Hypertext Transfer Protocol
ISO
International Organization for Standarization
JDBC
Java Database Connectivity
JPF
Java Plugin Framework
JSP
Java Server Pages
MDX
Multidimensional Expressions
OCL
Object Constraint Language
ODBC
Open Data Base Connectivity
OGC
Open Geospatial Consortium
OLAP
On-Line Analytical Processing
xvi
GLOSSÁRIO
Termo
Descrição
OMG
Object Management Group
PQL
Pictorial Query Language
ROLAP
Relational OLAP
SGBD
Sistemas de Gerenciamento de Banco de Dados
SGBDE
Sistemas de Gerenciamento de Banco de Dados Espaciais
SIG
Sistema de Informações Geográficas
SOLAP
Spatial OLAP
SVG
Scalable Vector Graphics
SQL
Structured Query Language
SSD
Sistemas de Suporte à Decisão
UDF
User Defined Functions
UML
Unified Modeling Language
WFS
Web Feature Service
XMI
XML Metadata Interchange
XML
eXtensible Markup Language
XMLA
XML for Analysis
xvii
CAPÍTULO 1
INTRODUÇÃO
1.1
CONTEXTUALIZAÇÃO
Os Sistemas de Suporte à Decisão (SSD) [37, 233, 234, 235, 236] possibilitam o gerenciamento
e a análise de grandes bases de dados de forma eficiente e consistente, permitindo a extração
de informações que auxiliam os usuários a compreender o comportamento do negócio de uma
organização. Essas informações possibilitam que os diretores executivos da organização tomem
decisões estratégicas no intuito de melhor conduzir seu negócio em meio às freqüentes oscilações
do mercado. A partir dessas análises, podem ser feitas mudanças em estratégias de marketing
e inserção de novos produtos ou serviços no mercado. Finalmente, o principal objetivo dos
Sistemas de Suporte à Decisão é fornecer informações relevantes para o gerenciamento dos
negócios de uma organização.
Uma das tecnologias amplamente utilizadas no contexto de Sistemas de Suporte à Decisão
é o Data Warehouse (DW) [281, 163, 155, 36, 38]. DW pode ser definido como uma base
de dados integrados, orientados por assunto, não volátil e variante no tempo. Normalmente,
os dados armazenados em um DW servem de base para o uso da tecnologia OLAP (On-Line
Analytical Processing) [282, 37, 36, 221]. OLAP são uma categoria de software especı́fica para
realizar processamento analı́tico nos dados de um DW, de forma que este processamento deve:
(1) ocorrer com alto desempenho, consistência e interatividade e (2) auxiliar a tomada de
decisão em uma organização por meio da interpretação desses dados em uma variedade de visões
multidimensionais. Estas visões multidimensionais são providas pela estrutura dimensional do
DW e podem ser compreendidas como eixos e pontos de um espaço multidimensional, onde cada
eixo pode ser encarado como uma dimensão ou perspectiva (e.g. tempo, área geográfica, sexo)
e os pontos como um valor medido e correspondente à intersecção desses eixos. Associado ao
termo OLAP, estão os conceitos de cubos de dados, dimensões, hierarquias, nı́veis, membros,
fatos e medidas [113, 77, 202, 37, 282].
Técnicas de Mineração de Dados [5, 144] também são empregadas em SSD para revelar
padrões e relacionamentos ocultos existentes entre os dados de um DW e também para tentar
predizer determinados fatos por meio da utilização de dados históricos.
Sistemas de Informações Geográficas (SIG) [41, 43, 88, 32, 117] são também utilizados no
suporte à decisão. SIG consistem de ferramentas para visualização, manutenção e recuperação
de informações geo-referenciadas (i.e. dados que descrevem eventos ou objetos localizados sobre
1
2
1.2 MOTIVAÇÃO
a superfı́cie terrestre, e são definidos pelo OGC (Open Geospatial Consortium) [51, 53] como
Feições Geográficas). SIG são aplicações computacionais capazes de manipular e analisar informações baseadas em sua localização no espaço. No contexto de Suporte à Decisão, os SIG
são aplicados em diversos ramos como planejamento urbano e rural, controle ambiental, gerenciamento de serviços de utilidade pública, e administração de recursos naturais. A utilização
das funcionalidades dos SIG no contexto SSD, deram origem a uma nova categoria de sistemas,
chamado de Sistemas Espaciais de Suporte à Decisão (SESD) [162].
A criação de ambientes computacionais de auxı́lio à tomada de decisões, utilizando as tecnologias recém listadas, juntamente com processos de administração eficientes, deu origem ao
termo BI (Business Intelligence - Inteligência de Negócios) [285, 68, 236]. O que torna um
processo eficiente é o fato de que as decisões são tomadas a partir de informações geradas pela
análise de dados, internos e/ou externos à organização, e não simplesmente por intuição ou pela
percepção do que acontece.
Para a construção de ambientes de BI, as empresas podem optar entre uma série de ferramentas comerciais e de domı́nio público disponı́veis atualmente, que englobam, principalmente, Sistemas de Gerenciamento de Banco de Dados (SGBD) com extensões para manipulação de dados geográficos (e.g.
[75, 57, 55, 275, 196, 154, 228]) e servidores OLAP
([74, 68, 150, 58, 56, 61, 279, 295, 263, 224]). Uma análise comparativa detalhada destas
ferramentas, pode ser encontrada em [77, 83].
Recentemente, foi introduzido o termo SOLAP (Spatial On-Line Analytical Processing)
[248] que abrange a junção de todos os conceitos e tecnologias listadas anteriormente e também
envolve a definição da base de dados multidimensionais e geográficos, denominados Data Warehouse Geográfico (DWG) [296, 21, 120, 283]. Entretanto, até o presente momento, as abordagens
para a integração entre as tecnologias SIG, DW e OLAP não são consenso na literatura de banco
de dados, e diversos pontos se encontram em aberto. Isto serve de motivação para o desenvolvimento da presente pesquisa, na qual abordaremos algumas das lacunas presentes na definição e
implementação de ambientes SOLAP.
1.2
MOTIVAÇÃO
Atualmente, inúmeros trabalhos vêm sendo realizados na área de integração entre processamento
analı́tico-multidimensional e geográfico. Dentre os mais recentes, podemos citar [287, 175, 177,
251, 18, 19, 252, 247, 248, 231, 111, 112, 232, 229, 104]. Entretanto, devido aos dois ambientes
serem originalmente concebidos para propósitos distintos, esta integração não é trivial. O
objetivo principal destas pesquisas é fornecer um ambiente com funcionalidades integradas para
manipulação, consulta e análise tanto de dados convencionais quanto de dados geográficos. Esse
novo tipo de ambiente, também chamado de SOLAP [248], beneficia o processo de tomada de
decisões estratégicas por aumentar o universo de análises que podem ser realizadas a respeito do
1.2 MOTIVAÇÃO
3
negócio de uma organização. Porém, até o momento, esta integração não tem sido totalmente
alcançada ou faz uso de tecnologias proprietárias, o que muitas vezes, encarece e dificulta a
evolução e reutilização das soluções existentes.
Acreditamos que um ambiente SOLAP ideal deve ser aberto, extensı́vel e independente de
plataforma e deve congregar: 1) ferramentas para extração, transformação e leitura dos dados
convencionais e geográficos presentes em diferentes fontes; 2) um Data Warehouse Geográfico
(DWG) para base de dados analı́ticos e geográficos integrados; 3) metamodelos para o DWG e
para o conjunto de metadados de integração; 4) um mecanismo para processamento analı́ticomultidimensional e geográfico; 5) uma linguagem de consulta com sintaxe integrada para a
utilização simultânea tanto de operadores analı́ticos quanto de operadores espaciais e 6) uma
aplicação cliente com uma interface amigável para a elaboração, submissão, manipulação e
visualização dos resultados. Porém, nenhuma das abordagens de integração propostas até o
momento contempla todos estes items.
A fim de fornecer um ambiente SOLAP satisfatório, que seja aberto e extensı́vel, em nossas
pesquisas temos estudado formas de prover ao usuário, uma abstração da complexidade normalmente agregada às atividades que têm como objetivo definir esquemas de DWG, cubos de
dados geográficos e especificar consultas sobre dados analı́ticos e geográficos para a tomada de
decisão [283, 81, 113, 115, 79, 82, 116, 83, 82].
Um aspecto importante é o desenvolvimento de uma linguagem de consulta geográficamultidimensional, que permita a utilização simultânea, tanto de operadores analı́ticos como de
operadores espaciais. Isso possibilitaria a recuperação de informações relevantes ao processo
de tomada de decisão, abstraindo ao máximo, a complexidade existente em uma tarefa dessa
natureza. Assim, o foco principal desta tese é a definição e implementação de uma linguagem
analı́tica-multidimensional e geográfica. A nossa principal motivação é o fato de ainda não
existir na literatura de banco de dados, uma linguagem com uma sintaxe única para integrar
operadores multidimensionais e espaciais.
Inúmeras propostas encontradas na literatura abordam o desenvolvimento de linguagens de
consulta espacial (e.g. [45, 46, 97, 107, 172, 193]). Entretanto, a maior parte delas apresentase como uma extensão da SQL (Structured Query Language) padrão [157]. Dessa forma, o
processamento analı́tico-multidimensional não é considerado de forma satisfatória. Embora a
SQL padrão permita a realização de algumas análises de cunho analı́tico-multidimensional, ela
não apresenta a eficiência e as vantagens oferecidas por linguagens de consulta voltadas para
processamentos dessa natureza, como é o caso da MDX (Multidimensional Expressions) [201, 67]
e outras propostas encontradas na literatura [27, 135, 217].
Mesmo a MDX possuindo alguma semelhança com a sintaxe da SQL padrão, esta não é uma
extensão de SQL, caracterizando-se como uma outra linguagem, com caracterı́sticas vantajosas
no que se refere à consulta de dados em bases de dados multidimensionais. Outros estudos
encontrados na literatura também mencionam as dificuldades existentes em realizar operações
1.3 OBJETIVOS
4
analı́ticas com SQL [27, 243, 135]. Por sua vez, linguagens de consulta como MDX, voltadas
especialmente para processamento multidimensional, não se preocupam com a questão espacial,
a qual é de extrema relevância para o processo de tomada de decisões estratégicas em um
contexto geográfico-multidimensional.
Neste contexto se insere a linguagem GeoMDQL (Geographic and Multidimensional Query
Language [84, 81], que estende MDX com funcionalidades para análise de dados espaciais e até
o momento, é uma das poucas linguagens de consulta com sintaxe integrada e otimizada para
ambientes SOLAP.
Todos os aspectos relacionados com a linguagem GeoMDQL, incluindo sua gramática, sintaxe, arquitetura, implementação e aplicações, serão apresentadas no restante deste documento.
1.3
OBJETIVOS
Para guiar o desenvolvimento desta tese, alguns objetivos foram definidos, os quais serão detalhados nesta seção.
1.3.1
Objetivo Geral
O foco central deste trabalho é a definição e implementação de uma linguagem que contemple as caracterı́sticas presentes nas principais linguagens de consulta analı́tico- multidimensional e geográficas encontradas na literatura atualmente, agregando, de forma transparente ao
usuário, o poder de processamento pertinente a estes dois tipos de recuperação e análise de
dados (analı́tico-multidimensional e geográfico). Especificar e implementar uma linguagem com
tal funcionalidade é objetivo principal das pesquisas apresentadas neste documento. Porém, é
importante observar que as linguagens de consulta espaço-temporais não são consideradas nesta
tese.
1.3.2
Objetivos Especı́ficos
Para alcançar o objetivo geral deste trabalho, algumas metas são almejadas:
Estudo detalhado dos diversos tipos de operadores analı́ticos e espaciais presentes nas
principais propostas existentes na literatura, verificando como eles podem ser reutilizados
em nossa pesquisa;
Definição do modelo de Data Warehouse Geográfico e de Cubo de Dados Multidimensionais e Geográficos utilizados em nossa abordagem;
Especificação da gramática e dos operadores de GeoMDQL;
1.4 ESTRUTURA DA TESE
5
Definição da arquitetura e tecnologias para a implementação da nova linguagem de consulta, disponibilizando uma aplicação para processamento analı́tico-multidimensional e
geográfico.
O trabalho apresentado nesta tese está relacionado com as seguintes publicações:
[78] Joel da Silva, Valéria Times, Ana C. Salgado, Ajolina Oliveira, et al. A Set of Aggregation Functions for Spatial Measures, Proceedings of the Eleventh ACM International
Workshop on Data Warehousing and OLAP, Napa Valley, CA, USA, 2008.
[283] Valéria Times, Robson Fidalgo, Rafael Fonseca, Joel da Silva, Anjolina de Oliveira A
Metamodel for the Specification of Geographical DataWarehouses, Annals of
Information Systems - http://www.springer.com/series/7573,issn 1934-3221, 2008.
[81] Joel da Silva, Rafael Fonseca, Anjolina de Oliveira, Robson Fidalgo, Ana C. Salgado,
Valéria Times, Modelling and Querying Geographical Data Warehouses, Information System Journal - http://ees.elsevier.com/is/, issn 0306-4379, Submitted on Feb19-2008, Under Review.
[84] Joel da Silva, Valéria Times, Ana Carolina Salgado et al., Querying Geographical
DataWarehouses with GeoMDQL, Brazilian Symposium on Databases (SBBD 2007),
pages 223-237, João Pessoa, PB, Brasil, 2007.
[120] Rafael Fonseca, Robson Fidalgo, Joel da Silva, Valéria Times, Um Metamodelo
para a Especificação de Data Warehouses Geográficos, Brazilian Symposium on
Databases (SBBD 2007), pages 193-207, João Pessoa, PB, Brasil, 2007.
[83] Joel da Silva, Valéria Times, Ana Carolina Salgado et al., An Open Source and Web
Based Framework for Geographic and Multidimensional Processing , The 21st
Annual ACM Symposium on Applied Computing, Track on Advances in Spatial and
Image-based Information Systems (ACM SAC ASIIS’06), pages 63-67, Dijon, France,
2006.
[80] Joel da Silva, Valéria Times, Ana Carolina Salgado et al., Propondo uma Linguagem
de Consulta Geográfica Multidimensional, VI Brazilian Symposium on GeoInformatics, pages 479-489, Campos do Jordão, SP, Brasil, 2004.
1.4
ESTRUTURA DA TESE
Esta tese está organizada em 7 capı́tulos, conforme mostra o fluxograma da Figura 1.1.
6
Figura 1.1 Organização da Tese
Capı́tulo 2 - Operadores e Linguagens:
Este capı́tulo apresenta a revisão bibliográfica referente às principais propostas de linguagens de consulta e operadores para ambientes de processamento geográfico e para
ambientes de processamento analı́tico-multidimensional.
Capı́tulo 3 - Processamento Multidimensional e Geográfico:
Neste capı́tulo, são apresentadas as principais arquiteturas para processamento multidimensional e geográfico disponı́veis na literatura de banco de dados. São descritas as
principais caracterı́sticas de cada abordagem e ao final, um estudo comparativo é realizado.
Capı́tulo 4 - Modelos de Dados e Funções de Agregação de Medidas:
7
Este capı́tulo contém as definições formais dos nossos modelos de DWG e de cubo de
dados, juntamente com as funções para agregação de medidas geográficas, definidas em
nossa abordagem.
Capı́tulo 5 - A Linguagem de Consulta GeoMDQL:
Este capı́tulo apresenta a linguagem GeoMDQL, proposta nesta tese, juntamente com a
descrição de seus operadores, e de sua gramática e sintaxe.
Capı́tulo 6 - Aspectos de Implementação:
Os aspectos de implementação da nossa abordagem são apresentados e discutidos neste
capı́tulo. Também são demonstrados alguns dos resultados obtidos com a aplicação
prática das implementações em estudos de caso.
Capı́tulo 7 - Conclusões e Trabalhos Futuros:
Este capı́tulo traz um resumo do que foi apresentado neste documento, bem como algumas considerações finais sobre nossa pesquisa, nossas principais contribuições e algumas
indicações de trabalhos futuros.
Por fim, anexos a este documento, temos os Apêndices A, B e C, nos quais são apresentados,
respectivamente, a especificação completa da gramática GeoMDQL, exemplos de funções de
agregação e exemplos de consultas GeoMDQL com seus respectivos resultados.
CAPÍTULO 2
OPERADORES E LINGUAGENS
2.1
INTRODUÇÃO
As linguagens de consulta e seus operadores são pontos indispensáveis quando abordamos a
definição, o armazenamento, a recuperação e a análise de dados. Dessa forma, este capı́tulo tem
como objetivo apresentar um levantamento bibliográfico sobre as principais linguagens de consulta e operadores pertencentes aos ambientes de processamento geográfico e multidimensional.
Este levantamento será de extrema importância para a especificação e implementação da nossa
linguagem de consulta geográfica e multidimensional GeoMDQL [84], que será apresentada com
maiores detalhes no Capı́tulo 5.
Este capı́tulo está estruturado da seguinte forma: Na Seção 2.2, são apresentados alguns
trabalhos relacionados com linguagens de consulta para dados geográficos e multidimensionais.
Um levantamento sobre operadores geográficos e multidimensionais é apresentado na Seção 2.3,
e por fim, na Seção 2.4 são tecidas algumas considerações sobre o conteúdo apresentado no
presente capı́tulo.
2.2
LINGUAGENS DE CONSULTA
Nesta seção, serão listadas as principais propostas de linguagens de consulta disponı́veis na
literatura de banco de dados. Abordaremos aqui, exclusivamente, trabalhos relacionados com
linguagens de consulta para dados geográficos e para dados multidimensionais.
2.2.1
Linguagens de Consulta Geográficas
Um dos mais importantes trabalhos desenvolvidos no contexto das linguagens de consulta espacial é o apresentado em [97]. Neste trabalho, o autor propõe uma linguagem de consulta espacial,
denominada Spatial SQL, a qual foi inspirada na SQL padrão [86, 157]. Esta linguagem é composta de duas partes: i) uma linguagem de consulta e ii) uma linguagem de apresentação. A
parte da linguagem responsável pela recuperação dos dados é uma extensão da SQL, preservando as cláusulas SELECT-FROM-WHERE. Por sua vez, a parte da linguagem responsável
pela apresentação gráfica dos dados, denominada GPL (Graphical Presentation Language) [96],
permite que o usuário defina as caracterı́sticas do ambiente de visualização dos dados espaciais.
A proposta Spatial SQL baseia-se em outro trabalho do mesmo autor [99], no qual são descritas
8
2.2 LINGUAGENS DE CONSULTA
9
as caracterı́sticas desejáveis de uma linguagem de consulta espacial, levando em consideração
aspectos da interface com o usuário. No que se refere aos aspectos de implementação da Spatial
SQL, o autor ainda salienta que a linguagem proposta implementa somente um subconjunto da
álgebra espacial [138, 137] e parte das definições formais dos relacionamentos topológicos [95].
Vários conceitos e definições relacionadas com a proposta Spatial SQL passaram a ser levadas
em consideração no desenvolvimento de novas linguagens de consulta espacial e sistemas para
processamento geográfico (e.g. [193, 172]).
Neste mesmo contexto, o Consórcio Open GIS [53] apresentou a especificação Simple Features Specification For SQL [45], com o intuito de definir um padrão baseado em SQL (Structured
Query Language) [157, 86] que permitisse o armazenamento, a consulta e a alteração de coleções
de feições geográficas simples via API ODBC [69]. Uma feição geográfica simples foi definida
pela Open GIS Abstract Specification [53] para possuir tanto atributos espaciais como não espaciais. De acordo com esta especificação, as coleções de feições geo-espaciais são armazenadas
em um banco de dados relacional, no qual as tabelas contêm colunas para representar os valores
geométricos das feições. Os atributos espaciais das feições são armazenados em colunas de tipos
de dados geométricos definidos para SQL. Por sua vez, os atributos não espaciais das feições são
armazenados em colunas baseadas em tipos padrões da SQL92 [157, 86]. Na Simple Features
Specification For SQL, são descritos dois tipos de ambientes para implementação de tabelas de
feições. No primeiro ambiente, denominado SQL92, uma coluna com valores geométricos é implementada utilizando o conceito de chave estrangeira em uma tabela de geometrias. Um valor
geométrico é armazenado utilizando uma ou mais linhas de uma tabela de geometrias. Nesta
abordagem, as tabelas de geometrias são implementadas utilizando tipos numéricos da SQL
padrão, ou ainda com os tipos binários da SQL. Este ambiente não define uma função SQL para
acesso, manutenção e indexação de geometrias porque essas operações não podem ser implementadas em sistemas de banco de dados utilizando os tipos de dados da SQL padrão. O segundo
ambiente, referenciado na especificação como SQL92 com Tipos Geométricos, é uma extensão
do ambiente SQL92, pois adiciona um novo conjunto de tipos geométricos. Nesta segunda abordagem, a coluna em uma tabela, a qual armazena valores geométricos, é implementada como
uma coluna definida por Tipos Geométricos para SQL. Baseada no OGC Geometry Model [53].
Esta especificação é tida hoje como padrão para definição, manipulação e armazenamento
de feições espaciais. A maioria das outras propostas mais relevantes da área de processamento
geográfico leva em consideração esta especificação (e.g. [123, 172, 193, 46]). As ferramentas comerciais e de domı́nio público para processamento geográfico disponı́veis na atualidade também
levam em consideração esta proposta (e.g. [241, 75]). Uma das possı́veis razões para isso é que
a Simple Features Specification for SQL leva em consideração o trabalho de Egenhofer [94], o
qual define formalmente os relacionamentos espaciais entre feições espaciais.
Outra proposta analisada, no contexto de linguagens de consulta a dados espaciais, é a
linguagem GeoSQL apresentada em [107]. Nesta, os autores definem a GeoSQL, como uma
10
linguagem de consulta que mantém o mesmo estilo do SQL padrão. GeoSQL é a linguagem de
consulta espacial de um protótipo de GIS orientado a objetos, denominado YH-GIS, o qual é
responsável por interpretar as consultas expressas em GeoSQL e por devolver o resultado da
requisição. Vale salientar que a proposta, apesar de ter sido publicada depois do lançamento
do padrão Simple Features Specification [45] do OGC, não o leva em consideração.
A Filter Encoding Specification [46] é outra especificação do OGC e define uma codificação
XML (eXtensible Markup Language) para representar expressões de filtro, baseadas em CQL
(Common Query Language) [48, 50]. Uma expressão de filtro XML pode ser transformada em
uma cláusula WHERE de uma instrução SELECT da SQL para recuperar dados armazenados
em bancos de dados relacionais. Da mesma forma, uma expressão de filtro pode ser transformada em uma expressão Xpath [288] ou Xpointer [289] para recuperar dados armazenados
em documentos XML. Esta especificação segue as diretrizes apresentadas na Simple Features
Specification for SQL [45]. Esta especificação é voltada para utilização de Serviços Web [293]
para processamento geográfico ou de Web Feature Services (WFS) [49]. Nesta especificação,
são descritos alguns operadores que podem ser utilizados em expressões de filtro. Estes operadores podem ser: i) Operadores Espaciais (e.g.
BBox, Contains, Crosses, Disjoint, Equals,
Intersects, Overlaps, Touches e Within), ii) Operadores Lógicos (e.g. And, Or e Not ) e iii)
Operadores de Comparação (e.g. =, <, >, >=, <=, <>).
SQL/SDA [172] é outra proposta que estende a SQL padrão para consulta e análise de dados
espaciais, baseando-se na especificação Simple Feature Specification for SQL. A linguagem proposta segue a sintaxe de consulta da SQL, preservando as cláusulas SELECT-FROM-WHERE.
Além disso, ela possibilita a definição de subconsultas na cláusula FROM, facilitando a expressão de consultas complexas para a análise de dados espaciais. O projeto de SQL/SDA
também engloba uma interface gráfica escrita em Java que auxilia na elaboração das consultas
por utilizar ı́cones que representam as operações mais utilizadas. No protótipo que implementa
a linguagem SQL/SDA, as feições geográficas são armazenadas e gerenciadas pelo Oracle Spatial [75]. Dessa forma, a otimização e execução das consultas fica a cargo do módulo espacial
implementado neste SGBD. Isto torna a abordagem dependente do componente proprietário
Oracle Spatial.
Outro trabalho importante, que objetiva uma padronização para linguagens de consulta
para sistemas de processamento geográfico é a ISO SQL/MM [123, 269]. Trata-se de um esforço
do comitê ISO para definir uma extensão da SQL padrão para tratamento multimı́dia, e a
parte 3 desta especificação trata especificamente, das funcionalidades voltadas ao processamento
geográfico. A SQL/MM foi originalmente derivada do padrão OGC Simple Features Specification
for SQL [45], o qual define um modelo abstrato para representação de feições geográficas e de seus
relacionamentos bem como apresenta diretrizes para definição, manipulação e gerenciamento
desses dados geográficos. Detalhes adicionais sobre este trabalho podem ser encontrados em
[123, 269]. Adicionalmente, em [216] pode ser encontrado um estudo sobre o impacto da nova
11
geração da SQL.
O trabalho apresentado por Morris et al. [193] leva em consideração a especificação Simple Features Specification for SQL do OGC e propõe uma nova linguagem visual para consulta
a banco de dados geográficos. Esta proposta utiliza uma metodologia de filtro de fluxo para
expressar os diferentes tipos de consultas disponı́veis em um SIG. A técnica utilizada é a transformação das consultas expressas em diagramas de fluxo para uma linguagem que estende a
SQL padrão com operações espaciais. Apoiada por uma interface gráfica bem elaborada, esta
abordagem provê aos usuários, uma maior facilidade para expressar consultas. A justificativa
dos autores para propor uma nova linguagem de consulta visual está baseada nos trabalhos de
Max Egenhofer [92, 98], os quais salientam que as extensões espaciais da SQL padrão, por serem
textuais, possuem sintaxe complexa e deixam a elaboração das consultas sujeita a erros.
Atualmente, a maioria das ferramentas comerciais e de domı́nio público, que provêem o
suporte para o processamento geográfico, leva em consideração as especificações ISO [123] e
OGC [45]. Outros trabalhos foram desenvolvidos neste contexto de consulta a dados espaciais,
entre eles podemos citar [138, 137, 93, 100, 95, 147, 286, 10, 174, 110, 98, 20, 22, 30, 40, 39, 54,
108, 23, 255, 31, 39].
2.2.2
Linguagens de Consulta Analı́tica-Multidimensional
No passado, as funções analı́ticas eram realizadas fora dos SGBD, por ferramentas OLAP que
utilizavam API não padronizadas, gerando um gargalo nas aplicações devido à transferência de
grandes quantidades de dados entre o servidor de banco de dados e o servidor OLAP e também
dificultava a vida dos programadores de aplicações analı́ticas devido à falta de padronização
e devido à SQL padrão não ser a linguagem mais apropriada para a realização de consultas
analı́ticas. Uma possı́vel solução para este problema seria processar as funções OLAP no servidor
de banco de dados utilizando funções SQL padronizadas [208]. Para isso, o comitê ANSI [121]
publicou em 2000 um melhoramento para a SQL 1999, estendendo a mesma com a definição
de uma lista de funções OLAP. Este trabalho teve a cooperação de grandes fornecedores de
soluções OLAP como IBM/Infomix, Oracle e Microsoft.
Em [27], é proposto o Multidimensional Calculus (MD-CAL). Nesse estudo, os autores comparam sua abordagem com diversas outras de mesmo propósito e existentes na literatura. Eles
também compartilham a idéia apresentada em [67, 243], de que a SQL padrão não é a linguagem
de consulta mais indicada para análise de dados multidimensionais. MD-CAL é baseada na realização de cálculos feitos em uma tabela de fato e oferece um suporte de alto nı́vel para a
análise de dados multidimensionais. De acordo com a sintaxe da linguagem, funções escalares
e agregadas podem ser embutidas nas expressões de cálculos de forma declarativa. Em outro
trabalho dos mesmos autores, apresentado em [25], é feita uma comparação de duas linguagens
de consulta baseadas em paradigmas diferentes e voltadas para o modelo de dados MD [29].
12
A primeira é algébrica e provê uma maneira eficiente de manipular dados multidimensionais
de uma forma procedural. Entretanto, verificou-se que esta linguagem não é adequada para
usuários finais e foi proposta então, uma linguagem de alto nı́vel que permite aos usuários, especificarem suas consultas de forma natural e intuitiva, sem que haja perda de expressividade da
linguagem. Mais tarde, uma comparação entre três linguagens de consulta para o modelo MD
foi realizada. Esta comparação inclui a linguagem MD-A, que é uma linguagem algébrica e provê
um meio eficiente de manipular tabelas de fatos de forma procedural. A segunda linguagem é
MD-C, uma linguagem declarativa baseada em cálculos de primeira ordem para realização de
consultas às tabelas de fatos. Finalmente, é apresentada a linguagem gráfica MD-G, a qual se
destina a usuários finais, uma vez que provê uma forma simples de especificar as consultas.
Outra importante proposta no contexto de linguagens de consulta multidimensional é apresentada em [217]. Neste trabalho, a abordagem SQLM é descrita, a qual é composta por um
modelo de dados, uma álgebra formal e uma linguagem de consulta multidimensional. Uma
das grandes vantagens desta abordagem é a capacidade de manipular hierarquias complexas
e irregulares. A linguagem proposta é semelhante a SQL mas com algumas facilidades incorporadas para o tratamento de dados multidimensionais. Os conceitos listados no artigo são
aplicados a um estudo de caso real, no ramo de comércio eletrônico. O Modelo de dados
SQLM é definido em termos de um cubo multidimensional, consistindo do nome do cubo, de
dimensões e da tabela de fatos com medidas numéricas. Cada dimensão é composta por hierarquias contendo nı́veis e seus respectivos valores. A linguagem de consulta proposta, SQLM ,
é uma extensão da SQL padrão com suporte para consultas OLAP. Uma consulta é construı́da
utilizando as cláusulas SELECT-FROM-WHERE-GROUP BY-HAVING da SQL padrão com
algumas modificações para permitir o uso de conceitos OLAP. Outro ponto interessante com
relação à proposta SQLM é o fato da integração com XML. A integração é baseada no uso de
expressões XPath [288] nas consultas SQLM . Mais detalhes sobre esta abordagem de integração
podem ser obtidos em [218].
Uma linguagem que pode ser considerada padrão de fato para realizar consultas em Bancos
de Dados Multidimensionais é a MDX (Multidimensional Expressions) [265, 201]. Com a sintaxe
da MDX, é possı́vel realizar consultas em um cubo de dados multidimensionais de forma a
fornecer visões configuráveis dos dados em diferentes ângulos e nı́veis de agregação, por meio da
utilização de operadores analı́ticos. Embora a sintaxe MDX seja, em muitas formas, semelhante
à sintaxe da SQL (Structured Query Language) [157] esta não é uma extensão da SQL. Algumas
das funcionalidades providas pela MDX podem ser fornecidas pela SQL, mas muitas vezes, isto
não ocorre de forma eficiente e intuitiva [67]. Como na SQL, a MDX provê uma sintaxe DDL
(Data Definition Language) para gerenciar estruturas de dados. Com a sintaxe MDX, torna-se
muito fácil a aplicação dos operadores OLAP tradicionais, gerando visões configuráveis do cubo
de dados multidimensional. Embora a palavra cubo sugira a existência de três dimensões, um
cubo de dados multidimensionais pode conter dezenas de dimensões. Até a data da escrita deste
2.3 OPERADORES
13
documento, em sua versão mais recente, a linguagem MDX permite a especificação de até 128
eixos em uma consulta. A especificação dos eixos pode ser feita da seguinte forma. AXIS(0) (que
pode ser substituı́do por COLUMNS), AXIS(1) (que pode ser substituı́do por ROWS), AXIS(2)
(que pode ser substituı́do por PAGES), AXIS(3)(que pode ser substituı́do por CHAPTERS),
AXIS(4) (que pode ser substituı́do por SECTIONS) e AXIS(5), ... , AXIS(127). Entretanto, é
bastante incomum a utilização de mais do que três eixos em uma consulta MDX.
MDX provê extensibilidade na forma de funções definidas pelo usuário que podem ser desenvolvidas em diversas linguagens de programação. O usuário cria e registra suas próprias
funções que operam em dados multidimensionais e também aceitam argumentos e valores de
retorno na sintaxe de MDX.
Outro estudo voltado para a análise de dados multidimensionais é apresentado em [135].
Neste trabalho, o operador Data Cube, o qual possibilita agrupamentos, sub-totais e cruzamento
de tabulações para análise de dados, é definido. Com Data Cube também é possı́vel a utilização
de operadores analı́ticos como drill-down e roll-up. Como nas abordagens apresentadas em
[67, 27, 243], os projetistas do Data Cube também comentam sobre as dificuldades encontradas
em analisar dados multidimensionais utilizando o padrão SQL [86, 157]. Segundo os autores,
Data Cube seria uma opção para sanar as deficiências de análise multidimensional apresentadas
pela SQL padrão.
De todas as propostas citadas nesta seção, as mais difundidas são a ISO SQL OLAP [121]
e a MDX [265, 201]. Estas duas propostas estão presentes em diversas ferramentas disponı́veis
na atualidade (e.g. [208, 150, 70, 224]). Entretanto, a linguagem padrão de fato para consulta a
bases multidimensionais é a linguagem MDX [244], dando indı́cios de uma possı́vel padronização
num futuro próximo. Outros trabalhos, relacionados com manipulação e análise de dados multidimensionais são descritos em [126, 128, 181, 182, 141, 6, 280, 284, 220, 230, 4].
2.3
OPERADORES
As linguagens abordadas na seção anterior, disponibilizam aos usuários, inúmeros operadores
para a formulação das requisições para recuperação e análise de dados, geográficos e multidimensionais. Alguns destes operadores são discutidos nas próximas seções.
2.3.1
Operadores para Dados Geográficos
De acordo com Rigaux et al. [246], podemos classificar os operadores sobre dados espaciais em
sete grupos, de acordo com a assinatura do operador, ou seja, a quantidade de argumentos e o
tipo de retorno. Estes grupos são: i) Unário com Resultado Booleano; ii) Unário com Resultado
Escalar; iii) Unário com Resultado Espacial; iv) N-ário com Resultado Espacial; v) Binário com
Resultado Espacial e vi)Binário com Resultado Booleano; vii)Binário com Resultado Escalar.
2.3 OPERADORES
14
Esta classificação de operadores é discutida nesta seção porque ela foi utilizada na definição das
funções de agregação de medidas espaciais e dos operadores da linguagem GeoMDQL (Capı́tulos
4 e 5), por ser a mais completa dentre as que foram estudadas.
Os operadores da classe Unário com Resultado Booleano testam propriedades de um objeto
espacial, como por exemplo, testam se o objeto é convexo, se está conectado, se é válido, se é
um anel, entre outros.
Por sua vez, os operadores da classe Unário com Resultado Escalar, são aqueles que, quando
aplicados a um objeto geográfico retornam um valor correspondente a uma medição. Como exemplos de operadores desta categoria, temos os que são usados para calcular a área, o perı́metro,
o comprimento, a quantidade de geometrias, a quantidade de pontos e a quantidade de anéis
internos. Já os operadores do tipo Unário com Resultado Espacial são aqueles que mapeiam
geometrias em geometrias. Como exemplos podemos citar Buffer [180], ConvexHull [45], BBox
[45], (Clipping) ou Recorte [44] e Centroid [45].
No grupo N-ário com Resultado Espacial, estão aqueles operadores que mapeiam n-tuplas de
geometrias em geometrias. Como esta classificação considera a assinatura da operação, alguns
dos operadores presentes na categoria anterior (i.e. Operador Unário com Resultado Espacial )
podem se encaixar nesta categoria, como é o caso do ConvexHull ou Clipping de vários objetos
geográficos. Outro exemplo é a construção de diagramas de Voronoi [87].
Como exemplo de operadores da classe Binário com Resultado Espacial encontram-se aqueles que mapeiam pares de geometrias em geometrias, como as operações de união, intersecção e
diferença. Quanto aos operadores Binário com Resultado Booleano, podemos citar os operadores topológicos e operadores cardinais. Baseado no modelo das nove intersecções [94], o OGC
[51, 45] definiu algumas operações topológicas entre feições geográficas. Estas operações incluem
Toca, Cruza, Sobrepõe, Contém, Disjunto, Intersecta e Igualdade. Os operadores cardinais (i.e.
Ao Norte De, Ao Sul De, Ao Leste De, Ao Oeste De, Ao Nordeste De, Ao Noroeste De, Ao
Sudeste De e Ao Sudoeste De ) [132, 133, 260, 232, 133, 42, 89] também fazem parte desta
categoria.
Por fim, como exemplo da classe Binário com Resultado Escalar, temos os operadores que
mapeiam pares de geometrias em valores escalares. Como é o caso do operador de distância,
que retorna a distância entre dois objetos geográficos.
2.3.2
Operadores para Dados Multidimensionais
Existem na literatura inúmeras propostas de operações sobre dados multidimensionais [298,
240, 135, 168, 230, 297]. Em OLAP, temos algumas operações tradicionais como é o caso das
operações de agregação e desagregação (e.g. Roll-UP, Drill-Down e Group-By, seleção e projeção
(e.g. Rotate ou Pivot, Slice e Dice) e operações para navegação na estrutura do cubo de dados,
como é o caso dos operadores All, Members, Ancestor e Children, presentes na linguagem MDX
2.3 OPERADORES
15
[297]. Todas estas operações são realizadas sobre o cubo de dados multidimensionais.
O Operador Group-By foi inicialmente criado para utilização em bancos de dados relacionais,
entretanto em seguida, ele passou a ser utilizado em aplicações OLAP. Este operador foi originalmente apresentado por Gray et al. [134, 135], sendo subseqüentemente redefinido por Lehner
[168], Hurtado, Mendelzon e Vaisman [146] e também por Nguyen, Tjoa e Wagner [200] para
utilização em consultas analı́ticas juntamente com os novos modelos de dados multidimensionais
propostos por eles. Outro importante operador encontrado na literatura é o Data Cube. Este
operador foi proposto em [135], sendo posteriormente redefinido por Gyssens e Lakshamanan
[141] e Nguyen, Tjoa e Wagner [200], também para ser utilizado em consultas analı́ticas juntamente com os novos modelos de dados multidimensionais propostos pelos autores. Data Cube é
uma generalização n-dimensional de funções de agregação simples, como por exemplo o Group
By.
O operador Roll-Up ou Drill-Up decrementa o detalhe de uma medida, agregando esta
medida ao longo de uma determinada hierarquia. Problemas na aplicação desse operador podem
surgir quando o mesmo é aplicado sobre hierarquias não regulares. Este operador foi proposto
inicialmente em [134, 135]. Em seguida, foi redefinido por Cabibbo e Torlone [27], Lehner [168],
Nguyen, Tjoa e Wagner [200] e em Pedersen, Jensen e Dyreson [222] para utilização em conjunto
com os novos modelos de dados propostos.
Por outro lado, o operador Drill-Down realiza o inverso do Roll-UP, ou seja, ele aumenta
os detalhes de uma medida ao longo de uma hierarquia. Só é possı́vel aplicar uma operação de
Drill-Down se conhecemos as leis de desagregação dos dados. O Drill-Down foi originalmente
proposto por Gray et al. [134], sendo posteriormente redefinido por Lehner [168], Cabibbo e
Torlone [27], Nguyen, Tjoa e Wagner [200] e por Pedersen, Jensen e Dyreson [222].
A aplicação do operador Rotate ou Pivot [240] modifica a orientação das dimensões de um
cubo multidimensional. Em outras palavras, se imaginarmos uma tabela multidimensional, a
aplicação deste operador fará com que as informações que estavam sendo mostradas nas colunas
passem a ser visualizadas nas linhas e vice-versa.
Os operadores Slice e Dice nos permitem selecionar partes especı́ficas de um determinado
cubo de dados multidimensionais. Em [141], os autores definem esses operadores como sendo um
caso especial de seleção relacional para bancos de dados multidimensionais. O operador Slice
reduz as dimensões ou a cardinalidade de um cubo multidimensional por meio da eliminação
de uma ou mais dimensões. Por sua vez, o operador Dice restringe os valores de uma dimensão
mas não diminui a cardinalidade do cubo [240].
Exemplos de operações para navegação na estrutura do cubo multidimensional são os operadores presentes na linguagem MDX [297]. Entre eles, temos o All, que retorna o nı́vel mais alto
de uma hierarquia especı́fica; Members que retorna o conjunto de membros de uma dimensão,
nı́vel ou hierarquia; Ancestor que retorna o ancestral de um membro em um nı́vel especificado;
e Children que retorna o conjunto de filhos de um membro especı́fico.
2.4 CONSIDERAÇÕES
16
Outra categoria de operações muito utilizadas em OLAP podem ser classificadas como
operações distributivas (e.g. Contagem, Mı́nimo, Máximo e Somatório), algébricas (e.g. Média,
Desvio Padrão, Máximo N e Mı́nimo N ) e holı́sticas (e.g. Mediana, Maior Freqüência e Rank )
[134], que também estão presentes na linguagem MDX.
Para análises OLAP, também podemos encontrar operações de conjunto, para manipulação
de membros de um cubo de dados multidimensionais, como é o caso do Crossjoin, Intersect
e Union. Estes operadores realizam, respectivamente, o produto cartesiano, a intersecção e a
união de conjuntos. Além de operações para análises estatı́sticas, como os operadores BottomPercent e TopPercent que implementam a análise de Pareto [261], todos estes operadores são
implementados na linguagem MDX. Uma lista completa dos operadores OLAP implementados
por MDX pode ser encontrada em [297, 201, 67].
2.4
CONSIDERAÇÕES
Como podemos notar neste capı́tulo, apesar de vários trabalhos propostos abordarem o desenvolvimento de linguagens de consulta espacial, a maior parte delas apresenta-se como uma
extensão da SQL padrão. Dessa forma, o processamento analı́tico-multidimensional não é considerado de forma satisfatória. Embora a SQL padrão permita a realização de algumas análises
de cunho analı́tico-multidimensional, ela não apresenta a eficiência e as vantagens oferecidas
por linguagens de consulta voltadas para processamentos dessa natureza, como é o caso da
MDX e de outras propostas encontradas na literatura. Por sua vez, linguagens de consulta
como a MDX e as demais linguagens citadas neste capı́tulo, as quais estão voltadas especialmente para processamento multidimensional, não se preocupam com a questão espacial, a qual
é de extrema relevância para o processo de tomada de decisões estratégicas em um contexto
geográfico-multidimensional.
Tanto no universo geográfico quanto no multidimensional, diversas abordagens foram propostas até o momento para consulta a bases de dados multidimensionais e geográficos. Contudo,
podemos perceber que alguns resultados relativos a uma padronização têm sido obtidos. Isso
se deve ao lançamento de especificações como a ISO SQL Espacial [123] e a SQL do OGC [45]
que estão sendo levadas em consideração pela maioria dos trabalhos mais recentes bem como
pelas ferramentas de análise espacial presentes na atualidade (e.g. [241, 75, 55, 196]). Indı́cios
de padronização são visı́veis no contexto analı́tico-multidimensional com o lançamento das especificações da MDX [201, 67] e ISO SQL OLAP [121], as quais são levadas em consideração
pela maioria das ferramentas com caracterı́sticas de análise multidimensional disponı́veis na atualidade (e.g. [70, 74, 56, 224]), conforme apresentado em [244]. Vale salientar que entre essas
ferramentas analı́ticas, a MDX tem sido considerada como o padrão de fato para consultas a
bases multidimensionais.
No que se refere aos operadores multidimensionais e geográficos disponı́veis na literatura,
17
e implementados pelas linguagens citadas neste capı́tulo, podemos notar que trabalhos como o
de Max Egenhofer [94, 99, 95] foram muito importantes para a aquisição de uma padronização
dos operadores geográficos. Como prova disso, temos a especificação do OGC [45] que é um
dos padrões seguidos atualmente para implementação de aplicações geográficas, que leva em
consideração os conceitos definidos por ele. Da mesma forma, a ISO SQL MM [123] utiliza
conceitos de ambos os trabalhos [94, 45], o que tem mostrado que algumas operações sobre
dados espaciais estão de certa forma, bem definidas formalmente, testadas e existe um consenso
entre os autores sobre esses conceitos e formalizações.
Quanto aos operadores analı́ticos, também notamos que existe uma grande quantidade de
propostas relacionadas. Entretanto, os operadores mais difundidos entre as linguagens de consulta e ferramentas para processamento analı́tico são os operadores de agregação e desagregação
(i.e. Drill Down e Roll UP ) e de seleção (i.e. Slice e Dice), os quais são bastante utilizados em
análises sobre dados multidimensionais [240].
Finalmente, podemos concluir que ainda não temos conhecimento de uma linguagem de
consulta que ofereça funcionalidades para processamento tanto geográfico quanto multidimensional. Nenhuma linguagem estudada apresenta uma sintaxe que integre operadores analı́ticos
e geográficos o que se caracteriza como um problema em aberto e serve de motivação para
nossas pesquisas. Um levantamento bibliográfico mais detalhado sobre linguagens de consulta
e operadores pode ser encontrado em [77].
No próximo capı́tulo, apresentaremos as principais propostas disponı́veis na literatura de
banco de dados, que têm como objetivo a integração entre os processamento geográfico e multidimensional. Muitas destas propostas utilizam linguagens e operadores listados neste capı́tulo
para análise de dados.
CAPÍTULO 3
PROCESSAMENTO MULTIDIMENSIONAL E
GEOGRÁFICO
3.1
INTRODUÇÃO
Neste capı́tulo, são descritas as principais propostas disponı́veis na literatura de banco de dados,
que têm como objetivo a integração dos processamentos analı́tico multidimensional e geográfico.
Serão analisados com maiores detalhes as propostas mais recentes, e aquelas cujas idéias tenham
sido validadas por meio da construção de protótipos de sistemas ou aquelas que estão diretamente relacionadas com uma dada linguagem de consulta. Entre os trabalhos apresentados, está
a arquitetura GOLAPA, pois o presente trabalho de pesquisa está inserido no mesmo contexto
desta arquitetura.
Para isso, estruturamos o presente capı́tulo da seguinte forma: A Seção 3.2, apresenta
alguns detalhes da abordagem JMap [247, 248, 14]. Na Seção 3.3 é detalhada a proposta
MapWarehouse [251]. A Seção 3.4 apresenta alguns aspectos relacionados com a abordagem
GeWOlap [18, 19]. A proposta SOVAT [252] é apresentada na Seção 3.5. Na Seção 3.6 é
apresentada a proposta PQL [231]. Detalhes da abordagem Piet [104] são apresentados na
Seção 3.7. A arquitetura GOLAPA [113], é apresentada na Seção 3.8. Outras propostas para
processamento multidimensional e geográfico são apresentadas na Seção 3.9. Por fim, na Seção
3.10 é realizada uma comparação entre as principais propostas apresentadas neste capı́tulo.
3.2
JMAP SPATIAL OLAP
Com as inúmeras iniciativas para prover uma total integração entre processamento multidimensional e geográfico, tornou-se comum o uso do termo SOLAP (Spatial OLAP ). Em [247, 248, 14],
os autores definem as ferramentas para OLAP espacial, bem como apresentam conceitos relacionados a elas. Além disso, são descritas caracterı́sticas essenciais e desejáveis dessa nova categoria de ferramentas para processamento analı́tico e espacial. A Figura 3.1, mostra a estrutura
de um ambiente de OLAP espacial segundo a visão destes autores [247, 248, 14]. Um ambiente
SOLAP geralmente é composto por: i) Ferramentas para extração, integração, limpeza e carga
dos dados oriundos de fontes convencionais e de bancos de dados geográficos; ii) Data Warehouse Geográfico; iii) Mecanismos para processamento analı́tico-multidimensional e geográfico e
iv) Aplicações com interface gráfica, sincronizando mapas, tabelas e gráficos para a visualização
18
3.2 JMAP SPATIAL OLAP
19
e análise dos dados.
Figura 3.1 Estrutura de um Ambiente SOLAP (Adaptado de [248])
Um sistema SOLAP pode conter três tipos de dimensões espaciais [248, 13]: i) dimensões não
geométricas, que são aquelas implementadas pelas ferramentas OLAP tradicionais, nas quais
apenas dados descritivos são representados (e.g. nomes dos estados, das cidades e dos lugares);
ii) dimensões geométricas, que são aquelas que, para cada membro de um nı́vel existe uma geometria associada (e.g. polı́gono representando o limite do estado), podendo estes membros ser
visualizados em mapas e podem ser consultados e manipulados com a utilização de operadores
espaciais; e iii) dimensões mistas, nas quais apenas alguns nı́veis possuem geometrias associadas
aos seus membros (e.g. o nı́vel paı́s ). No que se refere a medidas espaciais, o trabalho distingue dois tipos de medidas: i) conjunto de geometrias, que necessitam de operações espaciais
como união ou intersecção para serem computadas; e ii) valor resultante da aplicação de alguma
operação topológica ou métrica [248].
As idéias apresentadas em [247, 248] resultaram na implementação da ferramenta comercial
para OLAP espacial chamada JMap Spatial OLAP [277]. A Interface gráfica da ferramenta
JMap é apresentada na Figura 3.2. Um dos estudos de caso realizados com JMap foi na área
de saúde, com dados sobre doenças e informações sobre qualidade do ar, entre outros. Dessa
3.2 JMAP SPATIAL OLAP
20
forma, com JMap, os usuários podem realizar consultas para encontrar, por exemplo, a relação
existente entre a ocorrência de doenças respiratórias e a qualidade do ar em determinadas
regiões.
Figura 3.2 Interface Gráfica do JMap Spatial OLAP
Com relação à implementação, os seguintes aspectos são apresentados para o sistema JMap:
i) Para construção da base de dados, foram utilizadas as soluções proprietárias Microsoft SQL
Server [70] para registro dos dados convencionais e Intergraph GeoMedia 4 [156] para armazenamento dos dados espaciais; ii) Para o desenvolvimento do servidor SOLAP, foi utilizado o Microsoft Analysis Services 2000 em conjunto com o Intergraph GeoMedia 4 ; iii) Na aplicação
cliente, componentes comerciais da ProClarity [238] foram utilizados em conjunto com o Intergraph GeoMedia 4 para visualização dos gráficos, tabelas e mapas; iv) Finalmente, a linguagem
de programação utilizada para a elaboração da interface gráfica foi o Visual Basic.
No JMap, as medidas espaciais são implementadas através de ponteiros, que fazem a ligação
dos dados armazenados em uma estrutura de DW (i.e. baseada no esquema flocos de neve
ou estrela [163]) com feições geográficas armazenadas em algum formato de dado espacial que
3.3 MAPWAREHOUSE
21
não pertence ao sistema gerenciador de banco de dados, ou seja, não possuem um DWG com
base integrada de dados e utilizam a mesma técnica para armazenamento de dados geográficos
apresentada em [268, 267].
Quanto aos tipos de operações disponı́veis no JMap, são priorizadas as operações de
agregação e desagregação (i.e. roll-up e drill-down). Inclusive, são propostas duas variações
para os operadores roll-up e drill-down (i.e. operadores Close e Open respectivamente). Estes
operadores são utilizados para agregar ou desagregar somente determinados membros em uma
dimensão, o que é equivalente aos operadores DrillDownMember e DrillUpMember implementados na linguagem MDX [67, 297]. Entretanto, os autores não informam se a ferramenta é capaz
de realizar análises integrando operadores espaciais (e.g. operadores topológicos, métricos ou
direcionais) e operadores analı́ticos (e.g. rank). Isto indica que a abordagem realiza apenas
mapeamentos, ou seja, a partir das ligações existentes entre os dados convencionais e suas geometrias, os mapas são construı́dos e manipulados através de cliques efetuados pelos usuários na
interface gráfica.
3.3
MAPWAREHOUSE
Outro trabalho que propõe integração entre processamento multidimensional e geográfico é o
MapWarehouse [251]. Neste trabalho, é apresentado um modelo lógico para Data Warehouse
Geográfico, o qual é implementado sobre um SGBD objeto-relacional. O modelo proposto é
baseado em uma extensão do modelo estrela tradicional [163] contendo: i) conceitos e estruturas
do modelo objeto-relacional e ii) componentes espaciais. A abordagem possibilita a utilização
de medidas espaciais como objeto de análise, e operações OLAP como drill-down e roll-up
são implementadas através das funções de agregação disponı́veis no SGBD Oracle Spatial (e.g.
união de geometrias).
A Figura 3.3 mostra o metamodelo espacial e multidimensional da proposta MapWarehouse.
Como pode ser analisado nesta figura, o modelo consiste da extensão do modelo tradicional
de DW, acrescentando os conceitos de Cubo Espacial, Medida Espacial, Dimensão Espacial,
Hierarquia Espacial, Nı́vel Espacial e Atributo Espacial.
Em [251], um Data Warehouse Geográfico é conceitualmente visualizado como um cubo geográfico composto de medidas geográficas e não geográficas, com dimensões, hierarquias e nı́veis
geográficos e não geográficos. Assim, os autores não deixam claro a diferença entre modelagem
multidimensional voltada para representar o cubo de dados e a modelagem dimensional voltada
para a representação do DW. Existe uma diferença entre a modelagem do Data Warehouse
Geográfico e dos cubos geográficos. A modelagem do DWG é dimensional e os conceitos de
múltiplas dimensões, hierarquias e nı́veis não fazem parte deste contexto. Uma vez criado o
DWG (base de dados), passa a ser possı́vel a criação de cubos de dados geográficos, para fornecer
diferentes visões dos dados armazenados, inclusive envolvendo inúmeras dimensões, hierarquias
3.3 MAPWAREHOUSE
22
Figura 3.3 Metamodelo Espacial e Multidimensional do MapWarehouse [251]
e nı́veis, provendo uma visão configurável dos dados sob diferentes perspectivas. Dessa forma,
a maneira com que os dados foram organizados no DWG pode auxiliar na criação destes cubos
de dados para posterior análise dos dados. Maiores detalhes sobre modelagem dimensional e
multidimensional podem ser obtidos em [120].
Um estudo de caso para a área de produção agrı́cola é apresentado para demonstrar as idéias
na prática. Neste estudo, áreas de plantio são armazenadas em um DWG e posteriormente
analisadas via consultas SQL. A Figura 3.4 mostra o esquema da base de dados da abordagem
MapWarehouse. A implementação deste estudo de caso fez uso do Oracle Spatial [75], no qual
os objetos geográficos foram armazenados utilizando o tipo de dados SDO Geometry do Oracle
Espacial, tornando a solução dependente de uma ferramenta comercial.
As consultas aos dados são realizadas através da extensão espacial da SQL disponı́vel no
SGBD Oracle. Dessa forma, a elaboração de consultas mais complexas necessariamente deverão
ser realizadas por profissionais da área de banco de dados, que conhecem o esquema do DWG
em detalhes e também as funções disponı́veis e a sintaxe da extensão espacial da linguagem.
Por exemplo, uma consulta do tipo: Exiba as áreas geográficas de plantação de milho e feijão
e quantidades de milho e feijão por área geográfica, dentro de uma janela retangular, para cada
meso-região e para cada micro-região do estado da Paraı́ba, durante maio de 2003, na atual
3.4 GEWOLAP
23
Figura 3.4 Esquema Estrela Estendido do MapWarehouse (Adaptado de [251])
sintaxe de consulta do MapWarehouse seria expressa da forma apresentada na Figura 3.5. Como
podemos perceber, existe uma complexidade agregada à atividade de elaborar consultas deste
tipo, e esta complexidade pode aumentar consideravelmente com a inserção de um número maior
de operadores (espaciais ou analı́ticos) em uma única consulta. Isto poderia ser minimizado com
a utilização de uma interface gráfica apropriada ao contexto geográfico e multidimensional ou
com uma linguagem de consulta otimizada para este propósito. A Figura 3.6 mostra um exemplo
de como os resultados são visualizados após a execução das consultas, entretanto, não fica claro
como é realizada a interação entre a aplicação e a interface gráfica no MapWarehouse. Além
disso, o fato das funções utilizadas pela aplicação serem do componente espacial do Oracle, pode
aumentar o custo de aplicar a abordagem com a utilização de um SGBD diferente.
3.4
GEWOLAP
A proposta GeWOlap [18, 19] tem como objetivo prover processamento geográfico e multidimensional na Web. Esta proposta é baseada em trabalhos anteriores dos mesmos autores, que
englobam a especificação de um modelo de dados multidimensional e geográfico e uma álgebra
que redefine operadores OLAP tradicionais (e.g. Roll-up, Drill-Down, Slice e Dice) [240] para
serem utilizados no ambiente de Data Warehouse Geográfico [17, 18].
3.4 GEWOLAP
24
Figura 3.5 Exemplo de Consulta na abordagem MapWarehouse
Muitas das idéias apresentadas em [19] são muito similares às descritas no artigo [83], no
qual uma arquitetura em camadas é apresentada, contendo os mesmos componentes na primeira
e segunda camadas (i.e. Data Warehouse Geográfico e o mecanismo de processamento multidimensional e geográfico, respectivamente). Além disso, as abordagens assemelham-se em alguns
aspectos de implementação, como por exemplo a extensão do Servidor OLAP Mondrian [224]
com funcionalidades para manipulação de dados geográficos e a utilização do JPivot [239] como
componente de interface gráfica e visualização dos resultados.
Neste trabalho, são discutidas as maneiras mais comuns de incluir dados geográficos em
um Data Warehouse tradicional, para torná-lo um DWG. A primeira forma é a utilização de
dimensões espaciais no modelo multidimensional e a segunda consiste na utilização de medidas
espaciais. Na primeira abordagem, os dados geométricos não são armazenados nas dimensões
juntamente com os dados descritivos. Na Figura 3.7-(A), é apresentado um exemplo de modelagem considerando o uso de dimensões espaciais para análise das taxas de mortalidade. Na
segunda abordagem, é utilizado o conceito de medida espacial, no qual a geometria é armazenada
na tabela de fatos do DWG ou consiste de um ponteiro para um dado geográfico. Nesta segunda
opção existe o problema relacionado com a definição de funções de agregação e desagregação
para serem aplicadas sobre estas medidas. A Figura 3.7-(B) mostra a modelagem de um DWG
25
3.4 GEWOLAP
Figura 3.6 Interface Gráfica do MapWarehouse
Figura 3.7 Modelagem de um DWG para Análise da Mortalidade utilizando Dimensões e
Medidas Espaciais
para a análise das taxas de mortalidade, no qual o objeto geográfico que representa a geometria
dos departamentos ou setores é o objeto de análise na tabela de fatos.
A Figura 3.8-(A) mostra a arquitetura de software GeWOlap. Como pode ser analisado, na
camada de dados, o DWG é criado utilizando o SGBD proprietário Oracle, e conseqüentemente,
utiliza sua extensão espacial Oracle Spatial para manipulação dos dados geográficos. Na camada
26
3.5 SOVAT
Figura 3.8 Arquitetura GeWOlap
de aplicação, encontra-se o servidor OLAP Mondrian, e na camada de interface é utilizado o
JPivot juntamente com o MapXtreme, o qual é utilizado para exibição dos dados geográficos
resultantes da consulta.
Na Figura 3.8-(B), pode ser visualizado o resultado de uma consulta processada pelo sistema
GeWOlap construı́do pelos autores. Neste estudo de caso, um DWG é utilizado para análise
da mortalidade, no qual os departamentos são utilizados como medidas espaciais. O resultado
exibido na tabela multidimensional utilizando o JPivot mostra que as medidas espaciais referemse a ponteiros para objetos geográficos e para valores agregados. Em um trabalho dos mesmos
autores, apresentado em [17], é feita a referência para um protótipo desktop, chamado GéOlap,
que usa apenas medidas numéricas. Os dados geográficos são representados implementando o
conceito de dimensões geográficas. Entretanto, detalhes de implementação não são informados.
3.5
SOVAT
SOVAT (Spatial OLAP visualization and analysis tool) [252, 253] é outro trabalho interessante
na área de processamento analı́tico e espacial, possibilitando a visualização dos resultados de
uma consulta em mapas e gráficos. A arquitetura proposta pode ser visualizada na Figura 3.9.
Como podemos observar nesta figura, a arquitetura contém as camadas de dados, de aplicação
e de interface gráfica com o usuário.Na camada de dados, podemos perceber que um DWG não
é usado como base de dados integrados. Os dados multidimensionais e geográficos são mantidos
em bases distintas. Na camada de aplicação, módulos de software foram desenvolvidos utilizando
3.5 SOVAT
27
a plataforma .NET [71] para permitir a integração e exploração dos dados multidimensionais e
geográficos armazenados na camada de dados. São permitidas análises especı́ficas do ambiente
OLAP e também mineração de dados, as quais são providas pelos componentes OLAP e de
Mineração de dados do Microsoft SQL Server [70].
Figura 3.9 Arquitetura de Software da proposta SOVAT (Adaptado de [253] )
No que se refere ao processamento geográfico, não foi possı́vel identificar quais operações
espaciais podem ser utilizadas. Somente comentam que é possı́vel realizar consultas envolvendo
o operador espacial Buffer e utilizar a técnica de análise de redes para encontrar a melhor
rota em um mapa especı́fico. Porém, com relação aos operadores topológicos e posicionais (e.g.
intersects, touches, crosses e within ) nada é comentado. No trabalho discutido em [252, 253]
também é apresentado o operador Drill-Out, que possibilita recuperar as feições geográficas
que são vizinhas de uma determinada feição geográfica, o que possivelmente é implementado
verificando a intersecção entre objetos geográficos. Também são omitidos detalhes sobre como é
mantida e manipulada a ligação entre os dados multidimensionais do DW e os objetos geográficos
da base de dados. A Figura 3.10 mostra como os resultados das consultas realizadas no ambiente
SOVAT são exibidas pela interface gráfica.
Para demonstrar as idéias na prática, foi desenvolvido um estudo de caso com dados de
um departamento de saúde e com dados estatı́sticos sobre doenças, população, número de
internações e dados sócio-econômicos. Dois princı́pios guiaram o desenvolvimento da interface
gráfica do ambiente SOVAT : a facilidade de uso e a completa integração entre SIG e OLAP.
28
3.6 PQL
Figura 3.10 Interface Gráfica SOVAT
Com o estudo de caso desenvolvido, testes de usabilidade da ferramenta foram realizados com
membros da comunidade de saúde, o que contribuiu para a realização de melhoramentos na
interface ao final de cada bateria de testes.
3.6
PQL
Outro projeto interessante que pode ser encontrado na literatura de Banco de Dados é o da linguagem PQL (Pictorial Query Language) [231, 111, 112, 232, 229]. Nessa pesquisa, Pourabbas
et al. apresentam um modelo de dados geográficos orientado a objetos, que é estendido para
dar suporte ao uso de links para cubos de dados multidimensionais. Entretanto, não é apresentada uma linguagem de consulta que permita a total integração entre operadores espaciais
e multidimensionais, sendo discutida uma linguagem baseada em SQL e muito semelhante às
abordadas no Capı́tulo 2.
Conforme detalhado em [232], PQL possibilita que a partir do resultado de uma consulta
espacial, possa se chegar aos dados multidimensionais relacionados, devido às ligações existentes
entre estes dados. Além disso, conforme mostrado em [111], a base de dados geográfica é mantida
separada da base multidimensional, não considerando a existência de um DW geográfico, sendo
isto uma das desvantagens da proposta PQL.
3.6 PQL
29
Figura 3.11 Instâncias dos Atributos Funcionais vendas carro e vendas brinquedos [111]
Em [112], é comentada a importância da existência de uma integração entre os ambientes
geográfico e multidimensional, para aumentar a eficácia e qualidade das consultas para suporte
à decisão. O elemento chave para possibilitar a integração destes ambientes é a dimensão
geográfica, a qual está sempre presente, implicitamente ou explicitamente, em um banco de
dados multidimensionais [112].
Esta proposta utiliza atributos especı́ficos, chamados de atributos funcionais, na estrutura
do banco de dados geográfico orientado a objetos. Estes atributos funcionais têm como objetivo descrever todos os fenômenos representados pelo cubo de dados multidimensional e cada
atributo é formado por um par contendo o nome do cubo e o nome da variável do cubo. O
primeiro campo corresponde ao fenômeno considerado (e.g. vendas de carro por modelo, mês
e municı́pio) e representa os fatos do cubo. O segundo campo é composto por todos os nomes
das variáveis, exceto a geográfica, pois esta implicitamente tem o mesmo nome da instância
geográfica (e.g. Municı́pio - ver Figura 3.11). Dessa forma, esta abordagem associa dados que
estão armazenados em bases separadas, e a partir desta ligação, se torna possı́vel a realização
de consultas multidimensionais e geográficas. Neste trabalho, não fica claro se o protótipo implementa todas as funcionalidades apresentadas e também não informam sobre as tecnologias
utilizadas no desenvolvimento do projeto.
3.7 PIET
30
A Figura 3.11, adaptada de [111], mostra as associações existentes entre os dados geográficos
e multidimensionais que podem ser realizadas através dos atributos funcionais e que se assemelham a referências entre objetos.
3.7
PIET
Piet [104] é outro trabalho disponı́vel na literatura de banco de dados, que tem como objetivo a
integração entre SIG e OLAP. Nesse trabalho, que é baseado no modelo publicado em [130], uma
dimensão geográfica é composta de um conjunto de grafos, cada um descrevendo um conjunto de
geometrias de uma camada temática. Estas geometrias estão relacionadas a membros de nı́veis
de um cubo multidimensional. O modelo é implementado por um arquivo XML, chamado de
Piet-Schema, que contém os mapeamentos entre os objetos geográficos e o cubo de dados.
Uma linguagem de consulta chamada GISOLAP-QL é também proposta. Esta linguagem
de consulta é composta por duas partes, separadas pelo caracter pipe (|). A primeira parte
consiste em uma consulta cuja sintaxe é muito semelhante à SQL espacial, mantendo as cláusulas
SELECT, FROM e WHERE, entretanto, com o caractere ponto e vı́rgula (;) ao final de cada
cláusula. A segunda parte é uma consulta formada de acordo com a sintaxe MDX [297] (i.e.
Consulta Espacial | Consulta MDX).
O processamento ocorre da seguinte forma: A primeira parte da consulta (i.e. parte espacial)
é executada com o auxı́lio do documento XML que contém os mapeamentos entre o cubo OLAP
e as geometrias e indica em qual tabela do banco de dados está armazenada cada informação. O
retorno desta consulta é utilizado para reescrever a parte MDX da consulta, a qual é processada
novamente, para recuperar o resultado final.
Para exemplificar o funcionamento da proposta Piet, é dada a seguinte consulta: Listar o total de unidades vendidas e seu custo, por produto, forma de divulgação da promoção (promotion
media - e.g. rádio, tv, jornal) e lojas que estão localizadas em provı́ncias cortadas por algum
rio. Na Figura 3.12-(A), esta consulta é especificada na sintaxe da linguagem GISOLAP-QL. A
Figura 3.12-(B) mostra como fica a consulta reescrita em MDX após o processamento parcial,
que retorna somente as provı́ncias cortadas por algum rio e na Figura 3.12-(C), é mostrado o
resultado final da consulta.
Como pode ser observado na Figura 3.12, a proposta Piet não possui uma interface gráfica
única, que permita a visualização integrada dos dados multidimensionais e geográficos. Piet
possui duas interfaces: i) a primeira (ver Figura 3.12-(C)), que utiliza o cliente JPivot [239]
para exibir o resultado das consultas em tabelas multidimensionais a partir da execução de
consultas especificadas na linguagem GISOLAP-QL ; ii) a segunda interface, utilizada para
realizar consultas espaciais, faz uso da aplicação Jump [161] para conectar ao SGBD e exibir os
resultados, conforme mostra a Figura 3.13. A base de dados da proposta Piet é implementada
com o SGBD PostgreSQL [228] com sua extensão espacial PostGIS[241]. Como servidor OLAP,
31
3.7 PIET
Figura 3.12 Exemplo de Consulta Piet
para a definição dos cubos multidimensionais e execução das consultas MDX, é utilizado o
Mondrian [224].
Para otimização de consultas, a abordagem Piet apresenta uma técnica que particiona as camadas de geometrias em sub-geometrias [104], identificando e armazenando pontos em comum
entre as camadas. Estas informações são utilizadas posteriormente para resolver as consultas. Testes de desempenho são apresentados em [104], mostrando que a técnica possui melhor
desempenho do que técnicas tradicionais como variações da R-Tree [140].
32
3.8 GOLAPA
Figura 3.13 Exibição de Mapas no Piet
3.8
GOLAPA
A arquitetura GOLAPA (Geographical On-Line Analytical Processing Architecture)[113, 115,
79, 82, 116, 83, 120] é outra proposta que visa a integração entre processamento multidimensional e geográfico. É no contexto desta arquitetura que está inserida a linguagem de consulta
proposta nesta tese. A arquitetura GOLAPA prevê modelos para Data Warehouse Geográfico
[115, 120], metadados de integração [116], serviços de integração de processamento geográfico e
multidimensional [79, 82, 83] e uma ferramenta para modelagem de esquemas de DWG [119],
os quais estão fortemente relacionados com a provisão de um ambiente único para processamento geográfico e multidimensional. GOLAPA é uma arquitetura de software que visa ser:
i) baseada em tecnologias abertas e extensı́veis e ii) otimizada para suporte à decisão em um
contexto multidimensional e geográfico. O primeiro objetivo trata da integração sobre o aspecto
tecnológico, isto é, que sua implementação seja baseada em tecnologias como Java e XML. Já o
segundo discorre sobre a estratégia, que é potencialmente, a melhor solução para a integração
dos processamentos analı́tico e geográfico.
Para alcançar o primeiro objetivo, optou-se por Java e XML como tecnologias para im-
3.8 GOLAPA
33
plementação de GOLAPA. Esta escolha deve-se ao fato destas linguagens serem hoje amplamente difundidas e permitirem seus usos com outras tecnologias (e.g. CORBA e Web Services).
Quanto ao segundo objetivo, optou-se por aplicar uma arquitetura baseada na utilização de um
Data Warehouse Geográfico, devido a esta abordagem ser a mais apropriada para aplicações
que requerem alto desempenho de consulta e que não exigem que seus dados estejam permanentemente sendo atualizados - caracterı́sticas desejáveis para uma arquitetura de suporte à
decisão.
As cinco camadas da arquitetura GOLAPA são distribuı́das conforme apresentado na Figura
3.14 [113]. GOLAPA dispõe de três camadas essenciais para o suporte multidimensional e geográfico: Camadas (I), (II) e (III), que respectivamente tratam dos dados, serviços e interface
gráfica de um sistema com capacidades de processamento tanto analı́tico quanto geográfico.
Além disso, duas camadas de suporte: Camadas (A) e (B) que respectivamente tratam dos
dados operativos e da construção/manutenção do DWG. Por GOLAPA ser uma arquitetura
em camadas, esta segue a especificação que uma camada qualquer (e.g. II) provê serviço para
a camada imediatamente superior (i.e. III), bem como faz uso dos serviços da camada imediatamente inferior (i.e. I). Maiores detalhes sobre cada um dos componentes desta arquitetura
estão disponı́veis em [113] e [77].
Uma vez que a arquitetura GOLAPA está voltada para a utilização de um Data Warehouse
Geográfico (DWG), uma importante etapa foi a definição do esquema do DWG que é previsto
na camada (I) de GOLAPA. O arcabouço GeoDWFrame [115, 113] tem o objetivo de definir
um conjunto de conceitos e princı́pios de projeto para a construção do esquema de um DWG.
Salienta-se que GeoDWFrame é uma especificação em alto nı́vel que define um conjunto de
orientações que visam guiar a definição do esquema dimensional e geográfico de um DWG. Dessa
forma, este arcabouço se abstrai do uso de padrões como CWM [227] e OGC [45], não especifica
um metamodelo (o que dificulta o seu uso por ferramentas CASE) e não oferece mecanismos
que possibilitem a verificação de consistência do esquema do DWG. Por isso, o metamodelo
GeoDWM [120] foi especificado utilizando restrições OCL (Object Constraint Language) [203]
e diagrama de classes da UML (Unified Modeling Language) [205], levando em consideração o
pacote Relacional de CWM [227] e SFS for SQL [45] do OGC, para facilitar a sua utilização
e extensão por outros trabalhos. Para fazer uso do metamodelo GeoDWM, foi implementada
uma ferramenta CASE chamada GeoDWCASE [119], que auxilia os usuários na construção de
esquemas de DWG.
O primeiro protótipo da arquitetura GOLAPA foi implementado com o GMLA Web Service
(GMLA WS) [82, 76, 79]. Este protótipo implementa o componente GOLAPE da arquitetura
GOLAPA, utilizando o modelo ISAG [79] e provê a integração de serviços analı́ticos e geográficos
na Web. A implementação do protótipo leva em consideração o metamodelo GAM (Geographical
Analytical Metamodel) [116] e o Esquema GeoMD (Geographical Multidimensional), que foram
definidos para o componente Metadata (ver Figura 3.14) da arquitetura GOLAPA.
34
3.8 GOLAPA
Figura 3.14 Arquitetura Golapa [113]
Posteriormente, uma evolução do protótipo foi implementada [83], utilizando o servidor
OLAP Mondrian [224], a aplicação cliente JPivot [239] e a tecnologia SVG [291] para exibição
dos mapas. Também foram desenvolvidos novos algoritmos para processamento das consultas
e foi feita uma avaliação do desempenho dessa execução [185]. Da mesma forma que em [82],
as consultas de integração são divididas em duas partes: i) a primeira contendo as restrições
espaciais, especificadas de acordo com a sintaxe SQL espacial do Postgis e ii) a segunda contendo uma consulta multidimensional em MDX. Estas requisições são processadas utilizando os
algoritmos definidos em [185], os quais foram implementados em Java, estendendo o servidor
OLAP Mondrian.
A arquitetura GOLAPA está em constante evolução, e algumas das atividades atuais são a
extensão do modelo de DWG para dar suporte a medidas espaciais, a evolução do mecanismo
de processamento geográfico e multidimensional, além da especificação de uma linguagem de
consulta para DWG. Maiores detalhes sobre estas atividades de pesquisa serão apresentados
nos próximos capı́tulos desta tese.
3.9 OUTRAS PROPOSTAS
35
Figura 3.15 Exemplo de Consulta de Integração
3.9
OUTRAS PROPOSTAS
Além das propostas listadas anteriormente, podemos encontrar na literatura de banco de dados,
outros trabalhos que visando a integração entre processamento multidimensional e geográfico.
O Map Cube [256] baseia-se no operador Cube [135] e assim como o ele, efetua todas as possı́veis
combinações de agregações por cada dado de cada dimensão do DW. A principal diferença entre
os operadores Cube e Map Cube é o formato de saı́da de seus dados, pois o Cube apenas os
representa em tabelas, enquanto que o Map Cube, em tabelas e mapas.
GeoMiner [143] é um projeto para mineração de dados geográficos que consiste em três
módulos básicos: i) módulo construtor de cubos de dados, ii) módulo para processamento
OLAP e iii) módulo de mineração de dados. Destes, apenas os módulos i) e ii) caracterizam-se
como pesquisas relacionadas a este trabalho.
GOAL (Geographical Information On-Line Analysis) [164] é um projeto que objetiva integrar DW/OLAP com SIG. Para alcançar este fim, Kouba et al. [164] implementaram uma
36
arquitetura de software cujo componente responsável por coordenar esta tarefa chama-se Módulo
de Integração (MI). A proposta GOAL sugere a integração de SIG com DW/OLAP via uma taxonomia entre classes/objetos de SIG e uma dimensão geográfica do DW/OLAP. Para isso, três
tipos de correspondências dinâmicas (classe, instância e ação) são propostos. Além disso, faz-se
uso de metadados para permitir a realização de todo o processo de criação das correspondências
dinâmicas.
SIGOLAP [109] objetiva integrar SIG e OLAP via uma arquitetura em três camadas, a qual
é baseada em mediadores e faz uso de um metamodelo de integração, utilizando metadados para
auxiliar no processo de integração.
Em [213, 214], é apresentada uma abordagem para prover operações do tipo OLAP em
sistemas de data warehouses espaciais. Em [213], é proposta uma estrutura de dados chamada
aR-Tree, a qual combina técnicas de indexação espacial e materialização para promover um
suporte para consultas de agregação espacial.
Por sua vez, em [242], a consulta ao cubo de dados é estendida introduzindo predicados
espaciais e funções que expressam explicitamente os relacionamentos espaciais entre dados e
uma tabela de fatos e de dimensões. Essa abordagem utiliza um mecanismo de ı́ndice espacial
para derivar a hierarquia espacial por pré-agregação e materialização.
Em [223], é investigada a utilização de pré-agregação em data warehouses espaciais, com o
intuito de permitir que consultas de agregação espacial sejam realizadas com um menor tempo
de resposta possı́vel. Ainda no contexto de agregação espacial, conforme [237], a agregação
espacial é um importante aspecto na geração de cubos de dados espaciais para permitir o uso
de operações especı́ficas de OLAP, como por exemplo drill-down/roll-up. Então, uma nova
metodologia é apresentada, a qual visa melhorar o desempenho em atividades de agregação
espacial.
Em [267], é proposto um modelo de data warehouse geográfico que consiste de medidas e
dimensões espaciais e não espaciais. Um método para construção de cubos de dados espaciais é
também apresentado, o qual é chamado de materialização seletiva baseada em objetos.
Em [176], é apresentada uma extensão dos modelos OLAP levando em consideração a necessidade de manipular dimensões, hierarquias e medidas geográficas, bem como possibilitar a
aplicação de operações topológicas sobre os dados armazenados de acordo com o modelo proposto. Entretanto, detalhes importantes sobre a implementação e utilização prática das idéias
propostas não são dados. Posteriormente, motivados pela falta de metodologias apropriadas
para o desenvolvimento de DWG, os autores propõem em [178], uma abordagem para análise
de requisitos para DWG. O principal objetivo desse trabalho é acompanhar o desenvolvimento
de esquemas para DWG.
Em [287], requisitos para ambientes SOLAP são definidos. Nesse trabalho, uma ferramenta
já existente para processamento espacial, denominada CommonGIS [287], é integrada com
um DW. A aplicação CommonGIS foi desenvolvida para ler dados geográficos de arquivos
37
ou de serviços implementados de acordo com a tecnologia WFS [49]. A idéia central é que
essa ferramenta também passe a ler dados oriundos de um DW. Para implementar as idéias
propostas, são sugeridas duas abordagens. A primeira utiliza um componente para acesso
aos dados geográficos, outro para acesso ao DW e um componente que representa a aplicação
cliente com a interface. Nessa abordagem, as camadas ou temas geográficos são associados aos
nı́veis do DW através de um arquivo de metadados. Para a segunda abordagem, é sugerida
a construção de um serviço único para processamento multidimensional e geográfico (i.e. um
servidor SOLAP). Para intercâmbio dos dados entre o servidor SOLAP e a aplicação cliente é
utilizado GMLA [114], que foi desenvolvido originalmente para a arquitetura GOLAPA.
Em [175, 177], os autores também compartilham a idéia de que um DW, acrescido de
funcionalidades para manipular dados espaciais agrega muitas vantagens ao processo decisório
dentro do contexto de Inteligência de Negócios e Suporte à Decisão. Isso é alcançado através da
extensão das hierarquias de um ambiente multidimensional para representar dados geográficos.
Então, são definidas diferentes formas de hierarquias espaciais, juntamente com a representação
conceitual das mesmas. Vários cenários de aplicação de um DWG, incluindo comparações entre
a utilização de medidas espaciais e dimensões espaciais, são também descritos.
Na pesquisa apresentada em [262], os autores descrevem um arquitetura que possibilita a
disponibilização de dados multidimensionais e geográficos na Web. A aplicação desenvolvida
permite a execução de consultas MDX [297], as quais são processadas pelo servidor OLAP Microsoft Analisys Services, por intermédio do XML for Analysis (XMLA). Um dos componentes
da arquitetura processa o resultado da consulta XMLA para recuperar os dados geográficos
associados e exibir o mapa correspondente. A abordagem não utiliza um Data Warehouse Geográfico, ou seja, os dados multidimensionais e geográficos são mantidos em bases separadas.
Pelo que foi apresentado, não fica claro se a abordagem permite a utilização de operadores
geográficos (e.g. topológicos, direcionais), realizando somente consultas de mapeamento (i.e. a
partir de dados multidimensionais são gerados mapas a partir das associações exitentes entre
os dados). Por sua vez, em [136] é apresentada uma arquitetura semelhante, com a vantagem
de utilizar tecnologias abertas.
Finalmente, em [85], é apresentado o modelo MuSD (Multigranular Spatial Data Warehouse). Trata-se de um novo modelo para criação de esquemas de DWG. Como os demais
apresentados anteriormente, este modelo também estende os conceitos de dimensão, hierarquia,
nı́veis e medidas para permitir o armazenamento e a manipulação de objetos geográficos. Este
trabalho concentra-se mais na definição formal dos conceitos, relacionados ao esquema de DWG
e aos operadores definidos sobre essa estrutura, mas nenhuma informação sobre a implementação
das idéias propostas é apresentada.
3.10
38
CONSIDERAÇÕES
Este capı́tulo discorreu sobre as principais propostas para integração entre processamento multidimensional e geográfico, disponı́veis na literatura de banco de dados. Podemos perceber que
um novo termo, denominado SOLAP [248] é utilizado para fazer referência aos ambientes que
visam integrar funcionalidades SIG e OLAP. Após estudar cada um dos trabalhos discutidos
neste capı́tulo, podemos concluir que nenhuma das abordagem estudadas provê uma total integração entre processamento multidimensional e geográfico. Os principais pontos analisados em
cada abordagem são listados na Tabela 3.1.
Como um dos trabalhos pioneiros na área de integração entre SIG e OLAP, o protótipo
apresentado em [247] e [248] foi transformado em uma ferramenta desktop comercial chamada
JMap. O diferencial do JMap em relação às outras abordagens está na interface gráfica bem
elaborada para consulta e análise dos dados. Entretanto, a abordagem não utiliza um DWG
como base de dados integrados, utiliza tecnologias proprietárias, não é multi-plataforma e não
conta com uma linguagem de consulta com operadores SIG e OLAP integrados.
A proposta MapWarehouse [251], desenvolvida para Web, possui uma base de dados integrada, implementada de acordo com o modelo de DWG definido pelos autores, e manipula
medidas espaciais. A abordagem disponibiliza os operadores espaciais, definidos pelo OGC [45],
e implementados no dialeto SQL espacial do SGBD Oracle [73]. Dessa forma, as consultas
precisam ser especificadas em SQL e podem se tornar complexas dependendo da quantidade
de tabelas e operações envolvidas. A interface gráfica do MapWarehouse apresenta poucas
funcionalidades, é utilizada basicamente para exibição dos resultados das consultas. Grande
parte do processamento é realizado pelo Oracle Espacial [194], que oferece grande quantidade
de operações para definição, manipulação e recuperação de dados espaciais. Entretanto, isso
torna a solução dependente de uma tecnologia proprietária.
Outro trabalho analisado neste capı́tulo, que visa integração de processamento multidimensional e geográfico na Web é o GeWOlap [18]. Esta abordagem é muito semelhante à apresentada
em [83], entretanto, os componentes responsáveis pelo armazenamento de dados e pelo processamento geográfico são proprietários. Essa proposta também não dispõe de uma linguagem de
consulta geográfica e multidimensional. Como grande parte do processamento é realizado pelo
servidor OLAP (i.e. Mondrian) e pela aplicação cliente OLAP (i.e. JPivot), as funcionalidades
de processamento multidimensional são predominantes.
SOVAT [252], outra abordagem analisada, não utiliza um DWG, não considera medidas
espaciais e as operações espaciais são minimizadas. Entretanto, um ponto forte da abordagem
é a interface gráfica, que permite a visualização dos dados em mapas e gráficos, de forma
semelhante ao JMap [248]. SOVAT também fornece funcionalidades para navegação no cubo
de dados, realização de operações multidimensionais e de mineração de dados, disponibilizadas
pelo servidor OLAP da Microsoft [70]. O trabalho é dependente de plataforma e baseado em
39
tecnologias proprietárias e também não disponibiliza uma linguagem de consulta que integre
operadores multidimensionais e geográficos.
Apesar de em [232], ser citada a existência de uma linguagem de consulta geográfica envolvendo operadores OLAP, nenhum protótipo é apresentado, e a linguagem discutida se resume
a uma extensão espacial da SQL. A abordagem baseia-se em um modelo de dados orientado
a objetos, que permite a ligação entre dados geográficos e estatı́sticos, armazenados em bases
separadas, ou seja, não é utilizado um DWG.
Da mesma forma que GeWOlap [18], MapWarehouse [251] e a proposta apresentada em [83],
Piet [104] é outro trabalho que se propõe a integrar SIG e OLAP na Web. A linguagem proposta
não apresenta uma sintaxe integrada para especificação das consultas envolvendo operadores
espaciais e multidimensionais e também não é usado um DWG. Na abordagem Web, discutida
nesse trabalho, as funcionalidades OLAP para processamento e visualização dos dados são
predominantes, pois as consultas são reescritas para a sintaxe MDX, processadas pelo servidor
OLAP Mondrian e os resultados são visualizados pela aplicação OLAP cliente JPivot. Seu
ponto forte é a otimização de consultas. A segunda interface disponibilizada pela proposta Piet
[104], está baseada na utilização de uma extensão espacial da SQL do PostGis e no software
Jump, na qual as funcionalidades de processamento geográfico são predominantes e as consultas
são todas processadas pelo PostGis.
A proposta GOLAPA [113, 115, 79, 82, 116, 83, 120], da mesma forma que as abordagens
GeWOlap [18], MapWarehouse [251] e Piet [104], também propõe integração de processamento
multidimensional e geográfico na Web. Apesar de contar com um modelo para DWG, ferramenta CASE para definição de esquemas de DWG, GOLAPA não provê suporte para medidas
espaciais e também não possui uma linguagem de consulta que integre as operações geográficas
e multidimensionais. GOLAPA baseia-se em padrões abertos e extensı́veis como o servidor
OLAP Mondrian, a aplicação OLAP cliente JPivot e o SGBD PostgreSQL [228] com a extensão
espacial PostGis.
40
Proposta
Tecnologias
Abertas
Independência Data
e de Plataforma
Extensı́veis
Ware- Linguagem de
Ge- Consulta
ográfico
NÃO
SIM
NÃO
MapWarehouse NÃO
SIM
SIM
NÃO
GeWOlap
NÃO
SIM
SIM
NÃO
SOVAT
NÃO
NÃO
NÃO
NÃO
PQL
-
-
NÃO
NÃO
Piet
SIM
SIM
NÃO
SIM
GOLAPA
SIM
SIM
SIM
NÃO
JMap
NÃO
house
Tabela 3.1: Comparação entre Propostas para Processamento
Multidimensional e Geográfico
Para finalizar este capı́tulo, a Tabela 3.1 exibe uma comparação entre as principais propostas
mencionadas neste capı́tulo, levando em consideração os seguintes critérios: i) Uso de tecnologias
abertas e extensı́veis, o que possibilita um baixo custo na implantação e facilita a evolução do
trabalho; ii) Independência de plataforma para que a implantação do sistema proposto ocorra
sem que haja restrições quanto ao sistema operacional disponı́vel; iii) Uso de DWG, como base
integrada de dados geográficos e multidimensionais; e iv) Uso de uma linguagem de consulta
com sintaxe única para utilização de operadores geográficos e multidimensionais.
Como pode ser analisado na Tabela 3.1, nenhuma das propostas contempla todos os items
listados, os quais consideramos de extrema importância para a proposição de ambientes SOLAP.
Como esta tese está inserida no contexto da arquitetura GOLAPA, nos próximos capı́tulos iremos apresentar os melhoramentos obtidos para esta arquitetura, para torná-la uma arquitetura
SOLAP totalmente integrada. Esta evolução da arquitetura GOLAPA contempla a extensão
do modelo atual de DWG para prover suporte a medidas espaciais, proposição de um conjunto
de funções de agregação para medidas espaciais, um modelo de cubo de dados e uma linguagem
de consulta multidimensional e geográfica que integra em uma única sintaxe operadores multidimensionais e geográficos.
CAPÍTULO 4
MODELOS DE DADOS E FUNÇÕES DE AGREGAÇÃO
DE MEDIDAS
4.1
INTRODUÇÃO
Neste capı́tulo, apresentaremos o nosso modelo formal de DWG, um conjunto de funções de
agregação de medidas espaciais e o nosso modelo de cubo de dados multidimensionais e geográficos, chamado GeoMDCube. Como esta tese está inserida no contexto da arquitetura
GOLAPA [113, 115, 79, 82, 116, 83, 120] discutida no Capı́tulo 3, e estamos estendendo o
arcabouço GeoDWFrame [115] para prover suporte ao uso de medidas espaciais, optamos por
formalizar matematicamente nosso modelo de DWG, para garantir uma modelagem consistente
e livre de ambigüidades. Outra contribuição que será apresentada neste capı́tulo é o conjunto de
funções de agregação de medidas espaciais, o qual foi definido pelo fato de ainda não existir um
consenso na literatura de banco de dados sobre este tipo de função. Na seqüência, detalharemos
nosso modelo formal de cubo de dados, para deixar claro a relação entre os componentes do
cubo de dados e os componentes do DWG, bem como demonstrar a aplicação das funções de
agregação de medidas listadas anteriormente.
O restante deste capı́tulo está estruturado da seguinte forma: Na Seção 4.2 apresentamos
nosso modelo formal de DWG. Na seqüência, a Seção 4.3 introduz um conjunto de funções de
agregação para medidas espaciais. Por sua vez, a Seção 4.4 apresenta o modelo GeoMDCube.
Finalmente, na Seção 4.5, são tecidas algumas considerações sobre os assuntos discutidos neste
capı́tulo.
4.2
UM MODELO DE DADOS FORMAL PARA DATA WAREHOUSE GEOGRÁFICO
Nesta seção, abordaremos as definições formais do nosso modelo de Data Warehouse Geográfico,
que estão detalhadas em [283]. Apesar de haver na literatura de banco de dados, vários trabalhos
formais relacionados com Data Warehouse, pouca atenção tem sido dada para a formalização
de Data Warehouse Geográfico (DWG). O modelo formal apresentado a seguir, estende as
definições do arcabouço GeoDWFrame [115] para considerar a utilização de medidas espaciais.
Nos trabalhos discutidos em [179, 85] e [248] uma medida espacial é representada pela
geometria de um objeto geográfico ou pelo resultado da aplicação de uma operação espacial
sobre um objeto geográfico. Da mesma forma que uma medida convencional [163], uma medida
41
4.2 UM MODELO DE DADOS FORMAL PARA DATA WAREHOUSE GEOGRÁFICO
42
espacial ou geográfica representa a medição de um determinado fenômeno. Dessa forma, fica a
cargo do projetista e usuários do DWG definir quais serão as medidas armazenadas na base de
dados, ou seja, a definição das medidas do DWG vai depender das necessidades de análise dos
usuários.
As medidas espaciais são computadas através da aplicação de operações espaciais como
união e intersecção de geometrias. Por sua vez, em [267] e [13], uma medida espacial é definida
como sendo um conjunto de ponteiros para objetos geográficos, armazenados em outra estrutura
de dados. Assim, os dados geográficos não estão armazenados na tabela de fatos do DWG e
considerando o volume de dados usualmente encontrado em uma tabela de fatos, essa técnica
pode tornar o processamento custoso. Alguns exemplos de medidas espaciais que podem ser
armazenadas em uma tabela fato de um Data Warehouse Geográfico são: i) área plantada
(representada por um polı́gono), ii) local de um acidente, foco de dengue ou plataforma de
coleta de dados (representada por um ponto) e iii) trecho recuperado de rodovia (representado
por uma linha).
Em nossa abordagem, uma medida espacial é qualquer objeto geográfico (e.g. objeto do tipo
ponto, linha ou polı́gono) armazenado na tabela de fatos do DWG. O nosso modelo de DWG
é baseado em dois conjuntos de tabelas: (i) tabelas dimensões e tabelas fatos nas quais, cada
coluna é associada a um determinado tipo de dados. Nós assumimos que existem dois conjuntos
finitos de tipos de dados: i) os tipos básicos (TB ), tal como inteiro, real e string ; e ii) os tipos
geográficos (TG ), cujos elementos são pontos, linhas, polı́gonos, conjuntos de pontos, conjuntos
de linhas e conjuntos de polı́gonos. Os tipos básicos podem ser divididos em descrição comum
e descrição geográfica. O tipo descrição geográfica pode somente ser utilizado para descrever
propriedades de um objeto geográfico (i.e. um objeto com uma geometria associada), como
por exemplo, o nome de um estado, nome de uma rodovia, entre outros. Por sua vez, o tipo
descrição comum é utilizado para representar qualquer outra propriedade de um DWG.
Assim, quando uma coluna é associada a um determinado tipo de dados, por exemplo
consideremos o tipo inteiro ∈ TB , podemos dizer que a coluna é do tipo inteiro ou que a coluna
é do tipo TB . Adicionalmente, dependendo do tipo escolhido, obviamente, podemos dizer que
a coluna de uma tabela do DWG é do tipo descrição comum ou descrição geográfica.
Seguindo as linhas gerais previamente definidas em [115, 113], e estendendo GeoDWFrame
com medidas espaciais, a seguir, apresentamos as definições formais do nosso modelo de DWG.
Para exemplificar as definições formais, serão utilizadas instâncias do esquema de DWG apresentado na Figura 4.1. Trata-se de uma DWG para acompanhamento de precipitações pluviométricas e áreas de alagamentos. Ou seja, a tabela de fatos desta aplicação possui duas medidas, sendo uma convencional (i.e. para armazenar os valores das precipitações pluviométricas)
e outra geográfica (i.e. para armazenar as geometrias das áreas alagadas). Neste exemplo, nós
consideramos que os dados sobre precipitações pluviométricas são coletados por plataformas de
coleta de dados que estão localizadas em determinadas cidades e dentro de bacias hidrográficas.
43
Figura 4.1 Esquema de DWG para Acompanhamento de Precipitações e Alagamentos
Conforme pode ser observado na legenda da Figura 4.1, os nomes das tabelas do esquema possuem um prefixo que está relacionado com as definições originais do arcabouço GeoDWFrame
[115, 113].
Definição 1 (Descrição geográfica micro e macro). Quando o objeto geográfico apresenta
baixa granularidade (e.g. objeto representado por um ponto) ele raramente é compartilhado
na definição de um esquema de DWG. Então, nós dizemos que a descrição geográfica é micro.
Por outro lado, se a granularidade é maior (e.g. objetos representados por polı́gonos), o tipo
será descrição geográfica macro. Como exemplos de descrição geográfica micro, podemos citar
a localização de um acidente de carro, o endereço de um cliente, a localização de um hospital ou
ainda, a localização de uma plataforma de coleta de dados (PCD) como está sendo representado
pela tabela pgd localizacaoPCD do esquema de DWG da Figura 4.1. Por outro lado, limites
de um bairro, cidade ou estado (e.g. tabela pgd estado da Figura 4.1 ), áreas de preservação
ambiental, entre outras, são consideradas instâncias do tipo descrição geográfica macro.
Definição 2 (Tabela Dimensão). Uma tabela dimensão é uma relação n-ária sobre K × S1 ×
. . . × Sr × A1 × . . . × Am × G1 × . . . × Gp , onde:
44
(i) n = 1 + r + m + p;
(ii) K é o conjunto de atributos representando a chave primária da tabela dimensão;
(iii) cada Si , 0 ≤ i ≤ r é um conjunto de chaves estrangeiras para outras tabelas dimensão;
(iv) cada coluna Aj (chamada de nome de atributo ou simplesmente atributo), 0 ≤ j ≤ m, é
um conjunto de valores de atributos do tipo TB ;
(v) e cada coluna Gk (chamada de geometria), 0 ≤ k ≤ p, é um conjunto de valores de atributos
geométricos (ou simplesmente valores de geometrias) do tipo TG .
Em nosso modelo de DWG, uma tabela dimensão pode ser Geográfica, Convencional, ou
Hı́brida, conforme é indicado nas definições seguintes.
Definição 3 (Dimensão Geográfica). Uma tabela dimensão geográfica pode ser classificada
como primitiva ou composta, como segue na definição abaixo:
Primitiva: Uma tabela dimensão primitiva possui o esquema K × . . . × G1 × . . . × Gp , onde:
(i) p ≥ 1, i.e. existe pelo menos uma coluna com geometrias;
(ii) e não existe nenhuma chave estrangeira ou atributo.
Composta: Uma tabela dimensão composta possui o esquema K ×S1 ×. . .×Sr ×A1 ×. . .×Am ,
onde:
(i) r ≥ 1, i.e. existe no mı́nimo uma coluna de chaves estrangeiras. Adicionalmente, cada chave
estrangeira está associada a uma tabela dimensão primitiva;
(ii) m ≥ 1, i.e. existe pelo menos um atributo;
(iii) e não existe nenhuma geometria na tabela.
Na Figura 4.2, mostramos um exemplo de instância do esquema de DWG para acompanhamento de dados meteorológicos, o qual foi mostrado na Figura 4.1. Além disso, conforme mostrado nesta figura, as tabelas pgd estado, pgd municipio, pgd localizacao bacia e
pgd localizacao pcd são primitivas, pois todas possuem uma coluna do tipo geometria (e.g.
polı́gono e ponto). Vale salientar que, sem as tabelas primitivas, uma tabela dimensão contendo dados geográficos teria que armazenar as geometrias juntamente com as descrições destes
objetos geográficos, ficando evidente a redundância e o aumento do custo no armazenamento.
Como exemplo de dimensão geográfica composta, temos a tabela cgd localizacao também
mostrada na Figura 4.2. Esta tabela é composta porque não contém uma coluna do tipo
geométrico, porém, ela possui duas chaves estrangeiras, nomeadas id estado e id municipio,
que fazem referência para duas tabelas primitivas (i.e. pgd estado e pgd municipio, respectivamente). Neste exemplo, temos a representação dos objetos geográficos mantidos no DWG com
suas geometrias normalizadas.
Definição 4 (Tabela Dimensão Convencional). Uma tabela dimensão convencional é
formada pelo esquema K × S1 × . . . × Sr × A1 × . . . × Am , onde:
(i) r ≥ 0. i.e. existe zero ou mais colunas de chaves estrangeiras. Também, não existe nenhuma
45
Figura 4.2 Exemplo de um Esquema de DWG
chave estrangeira para tabelas primitivas;
(ii) m ≥ 1 (existe pelo menos um atributo) e todos os atributos são do tipo descrição comum;
(iii) e não existe nenhuma coluna com geometrias.
Um exemplo de dimensão convencional é a tabela d tempo, a qual contém apenas dados
convencionais, conforme mostra a Figura 4.2. No que se refere às tabelas dimensões hı́bridas,
que podem ser micro, macro e conjunta, estas são exemplificadas como segue.
A tabela
mhd bacia hidrograf ica, mostrada na Figura 4.2 é um exemplo de dimensão hı́brida micro.
Esta tabela possui uma chave estrangeira (id bacia) que faz referência para a tabela primitiva
geográfica pgd localizacao bacia. Em uma tabela dimensão hı́brida micro é possı́vel armazenar
dados convencionais e geográficos, porém, os dados geográficos representam objetos geográficos
de menor granularidade (e.g. endereços de clientes, endereços de estações de coleta de dados e
endereços de hospitais) Devido à baixa granularidade dos dados geográficos armazenados nestas tabelas, raramente outras dimensões compartilham tais dados. Por sua vez, uma dimensão
46
hı́brida macro diferencia-se da micro por armazenar dados de maior granularidade, que normalmente são compartilhados com outras dimensões (e.g. limites de paı́ses, estados, cidades ou
bairros).
Também, na Figura 4.2, um exemplo de tabela dimensão hı́brida conjunta é representada
pela tabela jhd P CD, que possui duas chaves estrangeiras: i) id local pcd, que relaciona esta
tabela com a tabela primitiva geográfica pgd localizacao pcd e ii) id localizacao, que provê o
relacionamento com a tabela dimensão geográfica composta cgd localizacao. Uma boa razão
para a utilização das especializações das tabelas hı́bridas é o incremento proporcionado na
expressividade semântica do modelo de dados. Entretanto, consideramos que tal especialização
não seja necessária para determinadas aplicações, sendo suficiente o uso de dimensões geográficas
hı́bridas genéricas.
Definição 5 (Tabela Dimensão Hı́brida). Uma tabela dimensão hı́brida é formada pelo
esquema K × S1 × . . . × Sr × A1 × . . . × Am , onde:
(i) r ≥ 1, i.e. existe no mı́nimo uma coluna de chaves estrangeiras. Também, as chaves
estrangeiras são ligações para tabelas dimensões do tipo geográfica primitiva e/ou geográfica
composta;
(ii) m ≥ 1 de tal forma que exista pelo menos um atributo do tipo descrição comum e um
atributo do tipo descrição geográfica;
(iii) e não existe nenhuma coluna com geometrias.
Adicionalmente, uma tabela dimensão hı́brida pode ser micro, macro ou conjunto, conforme
segue a definição:
micro: os atributos do tipo descrição geográfica são do tipo micro, ou seja, representam objetos
de menor granularidade;
macro: os atributos do tipo descrição geográfica são do tipo macro, ou seja, representam objetos
de maior granularidade;
conjunta: os atributos podem ser tanto micro quanto macro.
Definição 6 (Tabela Fato). Uma tabela fato é uma relação n-ária sobre K × A1 × . . . × Am ×
M1 × . . . Mr × M G1 × . . . × M Gq , onde:
(i) K é o conjunto de atributos representando a chave primária da tabela, formado por S1 ×
S2 × . . . × Sp , onde cada Si , 1 ≤ i ≤ p é uma chave estrangeira para uma tabela dimensão;
(ii) n = p + m + r + q;
(iii) cada atributo Aj , 0 ≤ j ≤ m, é um conjunto de valores de atributos do tipo TB ;
(iv) cada coluna Mk , 0 ≤ k ≤ r é um conjunto de medidas do tipo TB ;
(v) e cada coluna M Gl , 0 ≤ l ≤ p, é um conjunto de medidas do tipo TG .
Como exemplo de tabela fato, temos na Figura 4.2, a tabela f acompanha precipitacao, a
qual possui quatro chaves estrangeiras (i.e. id tempo, id localizacao, id pcd e id bacia) e duas
47
Figura 4.3 Exemplos Adicionais para as Definições Formais
medidas: i) precipitacao - medida convencional que representa as medições das precipitações
pluviométricas colhidas pelas plataformas de coleta de dados e ii) area alagamento - medida
geográfica que armazena as geometrias de áreas alagadas pelo excesso de precipitações pluviométricas. Dessa forma, no momento da definição dos cubos de dados, as funções de agregação
convencionais, normalmente presentes em ambientes de DW tradicional, são aplicadas normalmente sobre a medida precipitacao. Entretanto, como diferencial, temos funções de agregação
espacial sendo aplicadas sobre a medida area alagamento. Uma lista das funções de agregação
propostas nesta tese é apresentada na seção seguinte.
Obviamente, dependendo de uma decisão de projeto, um DWG pode ser modelado de outras
formas, com esquemas diferentes do apresentado na Figura 4.1. Por exemplo, podemos definir
esquemas contendo tabelas de fato sem nenhuma medida e também com dimensões degeneradas
[163].
No mesmo contexto da aplicação na qual está inserido o DWG discutido nesta seção e apresentado na Figura 4.2, definimos outras tabelas de fatos para representar as diferentes possibilidades de modelagem e análise dos dados. A tabela de fatos f acompanha precipitacao2,
exibida na Figura 4.3-(A) é uma alternativa de modelagem para a tabela de fatos
f acompanha precipitacao, previamente exibida na Figura 4.2. A principal diferença é que,
4.3 FUNÇÕES DE AGREGAÇÃO DE MEDIDAS ESPACIAIS
48
na tabela f acompanha precipitacao, a localização geográfica das plataformas de coleta de dados (pcd localizacao) é armazenada em uma coluna do tipo geometria (e.g. Ponto) da tabela
de fatos e não mais em uma tabela dimensão primitiva como no exemplo da Figura 4.2.
No mesmo contexto, a Figura 4.3-(C) mostra um exemplo de tabela de fatos sem medidas
numéricas ou convencionais (i.e. f registra pcd2 ). Neste exemplo, o objetivo da tabela de fatos
é registrar a data de instalação das plataformas de coletas de dados localizadas dentro das
bacias hidrográficas de uma certa região. Assim, como nenhuma medida geográfica foi definida
para esta tabela de fatos, a análise pode ser realizada aplicando uma função para contagem
das chaves estrangeiras. Outra possibilidade de modelagem de uma tabela de fatos consiste na
criação de dimensões degeneradas [163], que é representada pela coluna numero registro da
tabela f registra pcd (Figura 4.3-(B)). Com isso, um esquema de DWG é formalmente definido
conforme segue.
Definição 7 (Esquema de Data Warehouse Geográfico). Um esquema de DWG é uma
tupla GDW = (DT, F T ), onde DT é um conjunto finito e não vazio, de tabelas dimensões e
F T é um conjunto finito e não vazio de tabelas fato.
Finalmente, o conjunto de tabelas mostradas na Figura 4.1 pode ser visto como um exemplo
de esquema de DWG formalmente definido conforme as definições anteriores.
Antes de prosseguirmos com as formalizações do cubo de dados e das funções de agregação,
faz-se necessário listar as funções de agregação de medidas espaciais propostas em nossa abordagem. Detalharemos estas funções na seção seguinte.
4.3
FUNÇÕES DE AGREGAÇÃO DE MEDIDAS ESPACIAIS
Quando definimos uma medida, seja ela convencional ou espacial, devemos especificar qual
função de agregação será aplicada sobre ela. O resultado da aplicação destas funções irá produzir
as diferentes visões dos dados, de acordo com os diferentes nı́veis de agregação definidos nas
hierarquias contidas nas dimensões do cubo de dados. Esta relação intrı́nseca entre medida e
funções de agregação nos faz lembrar a definição de tipo de dados, utilizados em linguagens
de programação, que diz que a definição de um tipo de dado envolve desde a especificação
dos valores que são manipulados até as restrições e operações relacionadas com estes valores
[33]. Em um DW convencional, é consenso que as funções de agregação são divididas em
distributivas, algébricas e holı́sticas [135, 144]. Esta classificação também tem sido utilizada no
contexto de medidas espaciais e Data Warehouse Geográfico [256, 179, 223, 276]. Entretanto,
não temos conhecimento sobre a existência de um conjunto de funções de agregação de medidas
espaciais, para cada grupo dessa classificação (i.e distributivas, algébricas e holisticas). Uma das
poucas funções de agregação espacial referenciada por vários trabalhos é a união de geometrias
[251, 179, 17, 18, 256]. Por sua vez, em [85], devido à falta de um conjunto padrão de funções de
49
Figura 4.4 Classificação das Funções de Agregação
agregação, na proposição do seu modelo de DWG, os autores decidem por não fazer a definição
ou relacionar quais funções podem ser utilizadas. Apenas declaram que seu modelo considera
que, uma vez definida uma medida espacial, deverá ser especificada uma função de agregação
para a mesma.
Neste contexto, em nossa abordagem temos a proposição de um conjunto de funções que
leva em consideração classificações já consolidadas de funções e operações presentes nos dois
ambientes envolvidos (i.e. OLAP e SIG). Do lado OLAP, consideramos a classificação de funções
que é consenso na literatura de banco de dados: Distributiva, Algébrica e Holı́stica [256, 179,
223, 276, 135, 144]. Do lado SIG, consideramos a classificação de operações dada em [246], que
distribui as funções em grupos, levando em consideração o número de parâmetros e o tipo de
retorno da função (i.e. Unária Booleana, Unária Escalar, Unária Espacial, Binária Booleana,
Binária Escalar, Binária Espacial e N-ária Espacial ). Dessa forma, temos como resultado do
produto cartesiano realizado entre estes dois grupos, um conjunto de 21 classes de funções de
agregação, conforme pode ser observado na Figura 4.4.
Como todas as funções resultantes, quando aplicadas a um conjunto de medidas espaciais,
geram um resultado que pode ser apenas escalar ou espacial, re-agrupamos estas funções em um
nı́vel mais alto de abstração, considerando somente o tipo da primeira classe (i.e. Distributiva,
Algébrica ou Holı́stica) e o tipo de retorno (i.e. escalar ou espacial ). Isto resultou em seis
grupos: i) Distributiva Escalar, ii)Distributiva Espacial, iii)Algébrica Escalar, iv)Distributiva
50
Espacial, v)Holı́stica Escalar; e vi)Holı́stica Espacial. Exemplos de cada uma destas classes são
apresentadas nas próximas seções.
4.3.1
Distributiva Escalar
Esta categoria engloba todas aquelas funções que, quando aplicadas a um conjunto de medidas
geográficas, retornam um valor escalar. Como exemplos de funções deste grupo, podemos listar
aquelas originadas da combinação de operações distributivas como Min, Max e Count com os
operadores espaciais da categoria binário booleano, como os topológicos [94, 45] e cardinais [132]
(e.g. touches, disjoint, intersects, At North Of, At South Of ver Capı́tulo 2). Na Tabela 4.1,
são apresentados alguns exemplos deste tipo de função, entretanto, a combinação das funções
distributivas com os operadores topológicos e cardinais podem resultar em inúmeras outras
funções que são listadas no Apêndice B.
Tabela 4.1 Funções Distributivas com Resultado Escalar
Função
Descrição
CountTouches()
Dado um conjunto de medidas geográficas, esta função realiza a contagem de quantos
objetos tocam a medida espacial
CountAt North Of()
Dado um conjunto de medidas geográficas, esta função realiza a contagem dos objetos
que estão ao norte da medida
MaxIntersects()
Realiza a contagem dos objetos que intersectam a medida espacial, retornando a
maior quantidade de objetos que intersectam a medida
MinAt North Of()
Para cada medida espacial, realiza a contagem dos objetos que estão ao norte dela,
retornando a menor quantidade de objetos localizados ao norte da medida
Para exemplificar a aplicação de algumas das funções definidas para este grupo, na Figura
4.5-(B) pode ser analisado o resultado da aplicação das funções CountTouches, CountDisjoint,
CountIntersects, CountAt North Of e CountAt South Of sobre o conjunto de geometrias exibidos na Figura 4.5-(A), as quais calculam para cada geometria, respectivamente, a quantidade
de objetos que tocam, que estão disjuntos, que intersectam, que estão ao norte e que estão ao
sul. Nesta categoria de funções, também podemos redefinir a função Count para ser aplicada
a um conjunto de medidas espaciais e retornar um valor escalar que representa o número total
de medidas.
Outro possı́vel conjunto de funções, é o obtido através da combinação de funções distributivas com operadores espaciais do tipo: i) unário escalar utilizados para calcular a área, o
perı́metro e o comprimento e ii) binário escalar, para calcular distâncias. Alguns exemplos
desta combinação são listados no Apêndice B.
51
Figura 4.5 Exemplos de Funções de Agregação com Resultado Escalar
4.3.2
Distributiva Espacial
Neste subgrupo estão aquelas funções de agregação que, quando aplicadas às medidas geográficas, retornam uma geometria. Em nossa abordagem, a operação distributiva Sum quando
aplicada a um conjunto de medidas espaciais, realiza a união de geometrias, retornando a geometria correspondente a esta união. Dessa forma, a combinação desta função com operadores
52
topológicos e cardinais, por exemplo, pode gerar diversas funções, tais como as apresentadas na
tabela 4.2 e outras são listadas no Apêndice B.
Tabela 4.2 Funções Distributivas com Resultado Espacial
Função
Descrição
SumTouches()
Através da operação de união espacial, uma única geometria é gerada a partir
das geometrias que tocam a medida espacial
SumAt North Of()
Utiliza a operação de união espacial para gerar uma única geometria a partir
das geometrias que estão ao norte da medida espacial
SumAt North West Of()
Gera uma única geometria a partir das geometrias que estão ao noroeste da
medida espacial
SumDisjoint()
Gera uma única geometria a partir das geometrias que estão disjuntas em
relação à medida espacial
Como exemplo da aplicação de algumas das funções que compõem este grupo, temos o conjunto de objetos geográficos listados na Figura 4.6. A geometria mostrada na Figura 4.6-(B)
corresponde à aplicação da função de agregação SumDisjoint sobre o objeto geográfico com
rótulo 57, realçado na Figura 4.6-(A). De forma semelhante, a Figura 4.6-(C) apresenta o resultado da aplicação da função SumAt North Of sobre a mesma geometria de rótulo 57. Na
seqüência, de forma semelhante, as Figuras 4.6-(D) e 4.6-(E) exibem os resultados da aplicação
das funções Sum At South Of e SumTouches que mostram, respectivamente, a união das geometrias que estão ao sul e que tocam a geometria identificada com o rótulo 57.
4.3.3
Algébrica Escalar
Nesta categoria de funções de agregação, estão as funções algébricas combinadas com operações
espaciais que retornam um resultado escalar. Na Tabela 4.3, são listadas algumas das funções
que resultantes da combinação das operações algébricas como Avg (média), Stdv (desvio
padrão), MaxN (N maiores valores) e MinN (N menores valores) com as operações espaciais do tipo unária escalar, como por exemplo, as utilizadas para calcular a área, o perı́metro e
o comprimento (i.e. AvgArea e StdvPerimeter ). Também estão nesta categoria, funções como
MinNDistance (ver Tabela 4.3), que é originada da combinação de uma função algébrica (i.e.
MinN ) com uma operação espacial do tipo binária escalar (i.e. operador de distância). Um
maior número de funções deste grupo é listado no Apêndice B.
4.3.4
Algébrica Espacial
Exemplos de funções para este grupo, são aquelas originadas a partir da combinação de funções
algébricas como, por exemplo, MinN e MaxN com os operadores espaciais da categoria binário
booleano, tais como os cardinais [132] (ver Capı́tulo 2). Com funções deste tipo, podemos
responder perguntas como:
Quais são os N objetos geográficos que estão mais ao norte de
53
Figura 4.6 Exemplos de Funções de Agregação com Resultado Espacial
Tabela 4.3 Funções Algébricas com Resultado Escalar
Função
Descrição
AvgArea()
Retorna a área média de um conjunto de medidas espaciais
StdvPerimeter()
Calcula o desvio padrão dos perı́metros de um conjunto de medidas espaciais
MaxNArea()
Retorna as N maiores áreas de um conjunto de medidas espaciais
MinNDistance()
Para cada medida de entrada, esta função retorna as N menores distâncias
entre a medida corrente e as demais medidas do conjunto
um determinada medida espacial?. Alguns exemplos deste grupo são listados na Tabela 4.4.
A implementação deste tipo de funções, envolvendo os operadores cardinais, implica na redefinição e implementação de algoritmos para verificação de posicionamentos cardinais definidos
em [132, 89, 173, 42, 260, 133].
4.3.5
Holı́stica Escalar
Para este grupo, podemos citar as funções decorrentes da combinação de funções holı́sticas como
rank, median (mediana) e mode (maior freqüência) com operadores espaciais da categoria unário
espacial ( e.g. área, perı́metro e comprimento). Na Tabela 4.5, são listados alguns exemplos
deste tipo de função.
54
Tabela 4.4 Funções Algébricas com Resultado Espacial
Função
Descrição
MaxNAt North Of()
Para cada medida espacial, retorna as geometrias dos N objetos que estão
mais ao norte dela
MaxNAt South Of()
Retorna as geometrias dos N objetos que estão mais ao sul da medida espacial
MinNAt East Of()
Retorna as geometrias dos N objetos que estão menos a leste da medida
espacial
MinNAt West Of()
Retorna as geometrias dos N objetos que estão menos a oeste da medida
espacial
Tabela 4.5 Funções Holı́sticas com Resultado Escalar
Função
Descrição
RankArea()
Ordena as medidas pelo valor decrescente da área
RankPerimeter()
Ordena as medidas pelo valor decrescente do perı́metro
RankLength()
Ordena as medidas pelo valor decrescente do comprimento
MedianArea()
Calcula a área mediana do conjunto de medidas
MedianPerimeter()
Calcula o perı́metro mediano do conjunto de medidas
MedianLength()
Calcula o comprimento mediano do conjunto de medidas
ModeArea()
Calcula o valor de área mais freqüente do conjunto de medidas
ModePerimeter()
Calcula o valor de perı́metro mais freqüente do conjunto de medidas
ModeLength()
Calcula o valor de comprimento mais freqüente do conjunto de medidas
Na Figura 4.7, algumas das funções listadas na Tabela 4.5 são dadas como exemplo. As Figuras 4.7-(B) e 4.7-(C) mostram o resultado da aplicação das funções RankArea e RankPerimeter
sobre as medidas representadas na Figura 4.7-(A). Além disso, temos na Figura 4.7-(D), o resultado da aplicação das funções ModeArea, ModePerimeter, MedianArea e MedianPerimeter
sobre o mesmo conjunto de objetos geográficos da Figura 4.7-(A). Como pode ser observado, os
valores medianos da área e do perı́metro retornam corretamente, entretanto, o valor da moda é
nulo pois neste exemplo, não existem nenhuma repetições nos valores da área e perı́metro.
4.3.6
Holı́stica Espacial
Na Tabela 4.6, apresentamos outro grupo de funções de agregação de medidas, que são as
funções holı́sticas com retorno espacial. As função NNearestNeighbor() e NDistantNeighbor()
são processadas de forma semelhante à função MinNDistance, discutida na Seção 4.3.3, com o
diferencial de retornar a geometria dos objetos geográficos relacionados. Para a implementação
da função NGeoGrouping(), pode ser utilizado o algoritmo de K-means [7], que gera N agrupamentos a partir de um conjunto de dados de entrada. Por sua vez, a função Voronoi() retorna
um conjunto de feições geográficas que formam o diagrama de Voronoi [87] a partir de um
conjunto de pontos de entrada.
Para exemplificar algumas das funções de agregação listadas na Tabela 4.6, apresentamos na
55
Figura 4.7 Exemplo de Funções Holı́sticas com Resultado Escalar
Tabela 4.6 Funções Holı́sticas com Resultado Espacial
Função
Descrição
NNearestNeighbor()
Retorna a geometria dos N vizinhos mais próximos
NDistantNeighbor()
Retorna a geometria dos N vizinhos mais distantes
NGeoGrouping()
Agrupa os objetos de entrada em N grupos e retorna suas geometrias
Voronoi()
Retorna o diagrama de Voronoi resultante do processamento dos objetos geográficos de entrada
Figura 4.8, um exemplo de aplicação das funções NNearestNeighbor(), Voronoi() e NGeoGrouping(). Na Figura 4.8-(A), temos um exemplo do resultado de uma consulta para retornar os
cinco vizinhos mais próximos de um determinado ponto. Neste caso, o ponto em questão é o
ponto que aparece no centro do cı́rculo menor. Este cı́rculo é o menor possı́vel que consegue
englobar todos os cinco vizinhos do ponto em questão. Outro exemplo é dado na Figura 4.8-(B),
no qual são retornados os polı́gonos formados a partir do conjunto de pontos de entrada. Por
sua vez, na Figura 4.8-(C), temos um exemplo do resultado da aplicação da função NGeoGrouping() sobre um conjunto de pontos, para criar três agrupamentos, os quais estão identificados
em diferentes cores.
Tendo definido este conjunto de funções de agregação, na próxima seção, detalharemos nosso
modelo formal para cubos de dados geográficos e multidimensionais. Também será apresentada
a formalização para as funções de agregação de medidas do nosso modelo.
56
4.4 O MODELO DE DADOS FORMAL GEOMDCUBE
Figura 4.8 Exemplo Funções Holı́sticas com Retorno Espacial
4.4
O MODELO DE DADOS FORMAL GEOMDCUBE
Baseado no DWG formalmente definido na Seção 4.2, vários cubos de dados podem ser instanciados. Dessa forma, a seguir, apresentamos o modelo GeoMDCube (Geographic and Multidimensional Cube) [81], o qual inclui definições formais para dimensões, hierarquias, nı́veis,
dimensões geográficas, cubo de dados e funções de agregação.
Definição 8 (Nı́vel). Dado um Data Warehouse Geográfico GDW = (DT, F T ), um nı́vel l é
um atributo de uma dt ∈ DT ou de uma f t ∈ F T .
Cada dimensão em um cubo de dados é definida por um conjunto de hierarquias sobre
um conjunto de nı́veis, atributos ou valores de geometria. Uma definição mais precisa destes
conceitos é dada a seguir.
Definição
9
(Esquema
de
Dimensão). Dado
um
Data
Warehouse
Geográfico
GDW = (DT, F T ) um esquema de dimensão DS é um conjunto parcialmente ordenado
57
(X ∪ {All}, ≤), no qual:
(i) X é um conjunto de nı́veis ou X é um conjunto de atributos ou valores de geometrias em
uma dt ∈ DT ou em uma f t ∈ F T ;
(ii) ≤ define o relacionamento de ordenação parcial entre os elementos de X;
(iii) All é um valor adicional, o qual é o maior elemento do conjunto parcialmente ordenado
(X ∪ All, ≤), i.e. x ≤ All para todo x ∈ X;
Na Figura 4.9 temos um exemplo de esquema de dimensão. A Figura 4.9-(A) mostra a tabela
dimensão convencional d tempo2 (que pode substituir a tabela d tempo no DWG de exemplo
apresentado na Figura 4.2 ). Por sua vez, a Figura 4.9-(B) exibe o esquema de dimensão para
esta tabela dimensão do DWG. Como pode ser observado, existe uma hierarquia implı́cita entre
os elementos envolvidos (i.e. dia, mes, trimestre, semetre e ano).
Figura 4.9 Exemplo de Esquema de Dimensão
Definição 10 (Membros). Dado um esquema de dimensão DS (X ∪ {All}, ≤), no qual X é
um conjunto de nı́veis. Cada nı́vel li ∈ X é um conjunto de membros (também chamados de
membros do nı́vel). Os membros de li são os valores de atributo dos atributos que definem o
nı́vel li juntamente com os membros pertencentes a todos os nı́veis lj tal que lj ∈ X e lj > li . Se
o menor nı́vel em X possuir uma geometria associada, então a geometria é adicionada a seus
membros. Neste caso, nós dizemos que os membros são geográficos, caso contrário, os membros
são chamados de convencionais. Além disso, se um membro de um nı́vel l é geográfico, então
58
todos os membros de l são geográficos e nós dizemos que l é geográfico, caso contrário l é
chamado convencional.
Exemplos para as definições de membro convencional e geográfico são dados na Figura 4.10(A) e Figura 4.11-(A), respectivamente.
Definição 11 (Hierarquia). Uma hierarquia h é uma cadeia em um esquema de dimensão
DS = (X ∪ {All}, ≤). Em outras palavras, uma hierarquia h é um subconjunto totalmente
ordenado de um DS. Se o conjunto X de DS é um conjunto de nı́veis, nós dizemos que a
hierarquia é baseada em nı́veis, caso contrário, a hierarquia será baseada em valores. Adicionalmente, se h é baseada em valores e seus elementos são do tipo TG , nós dizemos que a hierarquia
é geográfica. Se h é baseada em nı́veis, e pelo menos um nı́vel da hierarquia h for geográfico,
então dizemos que a hierarquia é geográfica.
Na Figura 4.9 exemplificamos a definição de hierarquias. Como pode ser observado, na
(Figura 4.9-(B)) é mostrado o esquema de dimensão para a tabela dimensão convencional
d tempo2 (Figura 4.9-(A)). Dessa forma, com base neste esquema de dimensão, podem ser
criadas diversas hierarquias, algumas são listadas na Figura 4.9-(C).
Definição 12 (Dimensão). Dado um esquema de dimensão DS = (X ∪ {All}, ≤) uma dimensão d é um conjunto de hierarquias em DS. Se pelo menos uma hierarquia h em d for
geográfica, nós dizemos que a dimensão é geográfica.
O valor ALL, adicionado nas hierarquias, representa a agregação sobre toda a dimensão.
Figura 4.10 Exemplos de Nı́vel Convencional
Na Figura 4.10-(A), nós apresentamos um exemplo de nı́vel convencional, definido a partir
da tabela dimensão d tempo. Neste exemplo, nós definimos os nı́veis Ano e Mês, mostrando
seus respectivos membros. Então, a Figura 4.10-(B) mostra um exemplo de hierarquia (H1)
que pode ser definida a partir dos nı́veis criados. Por sua vez, a Figura 4.10-(C) mostra a
especificação da dimensão Tempo, que é formada pela hierarquia H1.
Na Figura 4.11, nós mostramos a especificação de dois nı́veis geográficos, os quais são baseados nas tabelas cgd localizacao, pgd estado e pgd municipio. Como podemos observar, todos os
membros dos nı́veis geográficos Estado (Figura 4.11-(A)) e Municı́pio (Figura 4.11-(B)) possuem
59
Figura 4.11 Exemplos de Nı́veis Geográficos
informações geográficas vindas das tabelas geográficas primitivas pgd Estado e pgd municipio,
respectivamente. Assim, na Figura 4.11-(C)), é mostrada a hierarquia geográfica (H1), que
contém os dois nı́veis anteriormente definidos. Por fim, temos na Figura 4.11-(D), uma dimensão geográfica Localização que é composta pela hierarquia (H1).
Um dos pontos mais importantes da especificação de um cubo de dados é a definição das
funções de agregação que são utilizadas para gerar os fatos do cubo. A seguir, damos a definição
formal para as funções de agregação, as quais foram detalhadas na Seção 4.3.
Na definição de um cubo de dados, o processo de agregação é executado por uma função f , a
qual obtém um multi conjunto R construı́do a partir de colunas de uma tabela de fatos f t ∈ F T ,
produzindo um único valor. Para definir o domı́nio de f , nós não podemos utilizar uma projeção
sobre f t, uma vez que a projeção não aceita duplicatas. Por exemplo, para somar a precipitação
registrada na tabela de fatos f acompanha precipitacao ( ver Figura 4.12), a tabela de fatos
seria projetada na medida precipitacao e as duplicatas seriam retidas. Esta é a razão pela
qual nós utilizamos um multi conjunto como domı́nio de f . Além das colunas, as linhas da
tabela de fatos na qual f atua são definidas a partir dos nı́veis, valores de atributos ou valores
de geometria de um conjunto D de dimensões (é importante lembrar que a chave primária de
uma tabela de fatos é composta pelas chaves estrangeiras das tabelas dimensões). Então, para
definirmos o domı́nio de f nós primeiro introduzimos uma operação chamada Projeção de Fatos
que produz um multi conjunto P . Esta operação é semelhante a uma projeção, entretanto, ela
retorna um multi conjunto de tuplas como resultado ao invés de uma relação (i.e. um conjunto
de tuplas), permitindo assim duplicações.
Nós então definimos f como uma função parcial, na qual o domı́nio é uma tabela de fatos
60
f t ∈ F T e o domı́nio da definição é um multi conjunto de tuplas R construı́do a partir das
colunas e linhas da f t na qual f opera.
Definição 13 (Projeção de Fatos). Dada uma tabela de fatos f t : K × A1 × . . . × Am × M1 ×
. . . Mr × M G1 × . . . × M Gq , na qual K, o conjunto de atributos representando a chave primária
é S1 × S2 × . . . × Sp e n = p + m + r + q, conforme definido na Definição 6. A projeção de fatos
℘s1 ,...,sx ,a1 ...ay ,m1 ...mz ,mg1 ...mgw , na qual 0 ≤ x ≤ p, 0 ≤ y ≤ m, 0 ≤ z ≤ r e 0 ≤ w ≤ q mapeia as
n-tuplas de f t para um multi conjunto de l-tuplas, no qual l = x + y + z + w e l ≤ n.
Definição 14 (Função de Agregação). Uma função de agregação fi ∈ Fg , um conjunto
contável Fg = {f1 , f2 , . . .}, é uma função parcial fi : f t → V ∪ ⊥ na qual:
(i) f t : K × A1 × . . . × Am × M1 × . . . Mr × M G1 × . . . × M Gq é uma tabela de fatos na qual fi
opera, e K é S1 × S2 × . . . × Sp ;
(ii) V é um conjunto de valores do tipo TB ou TG ;
(iv) e o domı́nio da definição de fi é definido como segue:
(1) Sendo P = ℘s1 ,...,sx ,a1 ...ay ,m1 ...mz ,mg1 ...mgw uma projeção de fatos sobre f t, na qual 0 ≤ x ≤ p,
0 ≤ y ≤ m, 0 ≤ z ≤ r e 0 ≤ w ≤ q;
(2) Sendo D um conjunto de dimensões;
(3) R é um multi conjunto de l-tuples de P selecionadas dos nı́veis, valores de atributos ou
valores de geometrias de D.
Aqueles elementos de f t nos quais fi é indefinido são mapeados para ⊥ (bottom).
Definição 15 (Cubo de Dados). Um cubo de dados (ou simplesmente cubo) C é uma 3-tupla
< D, f t, f > onde:
(i) D é um conjunto de dimensões;
(ii) f t é uma tabela de fatos;
(iii) f : P (N ) × {f t} → V ∪ ⊥ é uma função de agregação pela qual os fatos de C são definidos;
(iv) a dimensão do cubo C é igual a |D|, i.e. a cardinalidade de D. Se |D| = n, nós usamos a
notação C n para denotar a dimensão de C.
Se D possui pelo menos uma dimensão geográfica, nós dizemos que C é um cubo geográfico,
denotado por GC.
Em um DW ou DWG, os nı́veis das dimensões guiam a geração dos fatos, por meio da
aplicação das funções de agregação. Assim, um fato pode ser gerado considerando somente
algumas dimensões do cubo. Então, considerando a utilização da função de agregação Soma,
para gerar um fato conforme mostrado no exemplo da Figura 4.12, o fato a ser gerado pode ser
Precipitação Total (Fato1). Este fato terá o valor 72, que é obtido por meio da soma de todos
os valores da coluna precipitacao da tabela de fatos f acompanha precipitacao. Como pode ser
observado, para a geração do fato Fato1, toda dimensão do DWG é considerada.
61
Figura 4.12 Exemplo de Fato Convencional
Em um cubo de dados, cada fato gerado está associado a um nı́vel de uma dimensão do DWG.
Dessa forma, o valor do fato é obtido a partir da aplicação da função de agregação sobre uma ou
mais colunas da tabela de fatos. Por exemplo, considerando o nı́vel Ano, definido no esquema da
Figura 4.10, e os valores da medida precipitacao da tabela de fatos f acompanha precipitacao
(Figura 4.12), podemos observar que um valor será gerado para cada membro do nı́vel Ano (ver
Fato na Figura 4.12). Por sua vez, o exemplo de fato Fato3 (Figura 4.12) é gerado levando em
consideração somente o membro Pernambuco do nı́vel geográfico Estado (Figura 4.11-(A)) e o
membro 2005 do nı́vel convencional Ano (Figura 4.10-(A)).
Figura 4.13 Um Exemplo de Fato Geográfico
De
forma
similar,
os
dados
geográficos
armazenados
na
tabela
de
fatos
f acompanha precipitacao, com uma função de agregação de medidas que realiza a união
de geometrias, nós podemos definir um fato para o membro 2005 do nı́vel Ano (Figura
4.10-(A)). O exemplo FatoGeo1, da Figura 4.13, mostra o fato geográfico gerado para exibir
todas as geometrias que representam as áreas alagadas no ano de 2005.
No outro exemplo (FatoGeo2 ), as áreas alagadas são agrupadas (também utilizando uma
função para união de geometrias) levando em consideração o membro 2005 do nı́vel Ano (Figura
4.10-(A)) e o membro Pernambuco do nı́vel Estado ((Figura 4.10-(A))). Ou seja, o fato geográfico FatoGeo2 mostrado na Figura 4.13 representa a união das áreas alagadas no estado de
Pernambuco no ano de 2005. Outras funções de agregação de medidas geográficas (ver Seção
62
4.3) podem ser utilizadas, dependendo das necessidades de análise.
4.5
CONSIDERAÇÕES
Este capı́tulo apresentou nosso modelo formal de DWG, que estende o arcabouço GeoDWFrame
[115] para prover suporte a medidas espaciais. Também é apresentado um conjunto de funções
para agregação de medidas espaciais, e um modelo formal para cubos de dados multidimensionais
e geográficos.
Com a formalização matemática dos modelos de DWG e do cubo de dados, juntamente com
a formalização do processo de agregação, que gera os fatos a partir das medidas armazenadas
no DWG, deixamos explı́cito, de forma consistente e não ambı́gua, o relacionamento existente
entre os elementos do DWG, cubo de dados e processo de agregação.
Um ponto importante a ser observado, é que questões de otimização como pré-agregação e
materialização espacial [223, 267] não fazem parte do escopo desta tese. Outro fato é que, neste
primeiro momento, estamos considerando apenas hierarquias bem definidas.
No próximo capı́tulo, será discutida a nossa linguagem de consulta, chamada GeoMDQL,
juntamente com sua sintaxe e seu conjunto de operadores. Esta nova linguagem multidimensional e geográfica atua sobre os cubos de dados definidos a partir do modelo de dados GeoMDCube apresentado neste capı́tulo.
CAPÍTULO 5
A LINGUAGEM DE CONSULTA GEOMDQL
5.1
INTRODUÇÃO
Este capı́tulo apresenta a linguagem GeoMDQL (Geographic and Multidimensional Query Language), uma linguagem de consulta geográfica e multidimensional especı́fica para ambientes
de DWG e SOLAP. GeoMDQL está baseada em padrões amplamente difundidos como MDX
[297], OCG [45] e SQL Espacial [269]. Com GeoMDQL, integramos a sintaxe de consulta e de
operadores multidimensionais e geográficos em uma única linguagem. A linguagem GeoMDQL
está inserida no contexto da arquitetura GOLAPA [113, 115, 79, 82, 116, 83, 120], discutida na
Seção 3.8 do Capı́tulo 3.
O restante deste capı́tulo está organizado da seguinte forma: A Seção 5.2 apresenta a sintaxe da linguagem GeoMDQL. Na seqüência, a Seção 5.3 detalha os operadores geográficos
e multidimensionais da linguagem GeoMDQL. A Seção 5.4 apresenta detalhes relacionados à
arquitetura do processador da linguagem GeoMDQL. Na Seção 5.5, são definidos os tipos de
consultas que podem ser especificadas na linguagem GeoMDQL. Por fim, na Seção 5.6, são
apresentadas algumas considerações finais sobre os assuntos discutidos neste capı́tulo.
5.2
A LINGUAGEM GEOMDQL
Nesta seção, será apresentada a linguagem de consulta GeoMDQL (Geographic and Multidimensional Query Language) [84], juntamente com sua sintaxe, operadores e arquitetura. GeoMDQL
é uma extensão da linguagem MDX [67, 297] para permitir o uso de operadores espaciais [45, 269]
e multidimensionais em uma única sintaxe. A escolha de MDX se deve ao fato da mesma ser
o padrão do mercado para consulta a dados multidimensionais, e por ser uma linguagem extensı́vel, o que facilita o reuso e minimiza o trabalho a ser desenvolvido.
5.2.1
Sintaxe da Linguagem GeoMDQL
A sintaxe da linguagem GeoMDQL foi definida utilizando a notação EBNF (Extended Backus Naur Form ) [129], por esta ser um formalismo bastante adotado em trabalhos acadêmicos e em
aplicações comerciais, para a definição da sintaxe de linguagens [183, 170, 124] e também pelo
fato de que a definição da sintaxe original da linguagem MDX utiliza formalismo semelhante.
Nesta seção, os principais elementos da gramática da linguagem GeoMDQL são discutidos. A
63
5.2 A LINGUAGEM GEOMDQL
64
especificação completa em EBNF se encontra no Apêndice A.
Figura 5.1 Principais Elementos da Gramática da Linguagem GeoMDQL
A Figura 5.1 mostra os principais elementos de uma consulta elaborada em GeoMDQL.
O principal elemento da gramática é geomdql statement, que foi definido para ser um select statement. De acordo com as regras do formalismo EBNF, o caracter ”?”indica que um
elemento é opcional, enquanto os elementos em caixa alta (e.g., WITH, SELECT, FROM,
WHERE e ON MAP ) são elementos terminais da linguagem. A Figura 5.2 mostra um exemplo
de consulta GeoMDQL. Neste exemplo, é selecionada a quantidade de nascidos vivos no ano
de 2002 para cada membro do nı́vel Estado da dimensão Localizacao, pertencente ao cubo de
dados BrSaude.
Figura 5.2 Exemplo de Consulta GeoMDQL
O elemento formula specification, exibido na Figura 5.3, mantém a definição originalmente
especificada para a linguagem MDX [297] e permite a definição de fórmulas para a criação de
conjuntos de fatos calculados, com base em valores armazenados em um cubo de dados. Por
exemplo, a instrução WITH MEMBER [Measures].[Taxa De Mortalidade] as ‘[Measures].[Obitos
Menores de Um Ano]/[Measures].[Nascidos Vivos]’ utilizada na consulta da Figura 5.4, utiliza
dois fatos de cubo de dados (i.e. [Obitos Menores de Um Ano] e [Nascidos Vivos] ) para criar
um novo fato calculado com o nome Taxa De Mortalidade, cujo valor será calculado em tempo
de execução da consulta. Dessa forma, o novo membro pode ser utilizado na cláusula SELECT,
conforme demonstrado na Figura 5.4.
65
Figura 5.3 Elemento formula specification da Gramática da Linguagem GeoMDQL
Figura 5.4 Exemplo de Definição de Fórmulas em GeoMDQL
Outro exemplo de utilização do elemento formula specification pode ser, por exemplo, para
criar uma instrução para gerar um conjunto nomeado de Top10Obitos, contendo os nomes dos
dez estados brasileiros com maior número de óbitos de crianças com idade inferior a um ano,
no ano de 2000. Esta instrução utilizaria a função TopCount, originalmente definida para a
linguagem MDX, e seria semelhante a: WITH SET Top10Obitos AS ‘TopCount( [Localizacao].[Estado].Members , 10, ([Tempo].[2000], [Obitos Menores de Um Ano]) )’.
O elemento axis specification list, cuja especificação pode ser analisada na Figura 5.5, representa a definição dos eixos de uma consulta elaborada de acordo com a sintaxe da linguagem
GeoMDQL, sendo similar à sintaxe original da linguagem MDX. Em uma especificação de eixo,
podem ser utilizados operadores multidimensionais e espaciais para navegar em uma hierarquia
de um cubo de dados e manipular membros desta hierarquia. Um exemplo de especificação de
eixos pode ser visualizado na cláusula SELECT da consulta exibida na Figura 5.2. Como pode
ser observado, nesta consulta foram utilizados 2 eixos (i.e. COLUMNS e ROWS ) para compor
66
a especificação dos eixos e organizar os dados. Entretanto, GeoMDQL possibilita a utilização
de mais de dois eixos em uma consulta, através da utilização dos elementos terminais PAGES,
SECTIONS e CHAPTERS, ou ainda através da utilização do número inteiro que indica o ı́ndice
de cada eixo.
Como pode ser observado na Figura 5.5, uma especificação de eixo (axis specification)
contém um elemento chamado geomdql expression, cuja especificação parcial é exibida na Figura
5.7. Fazem parte da especificação do elemento geomdql expression, dois outros elementos essenciais da linguagem GeoMDQL, que são geomdql function e member geometry. São estes dois
elementos, os principais responsáveis por agregar à linguagem GeoMDQL, o poder de processamento espacial, permitindo a utilização de operações espaciais sobre membros geográficos.
Como pode ser observado na consulta da Figura 5.6, está sendo utilizado uma função chamada
FILTER na especificação do eixo linha (ROWS) para recuperar somente os estados que possuem
população superior a 1 milhão de habitantes.
Figura 5.5 Elemento axis specification list da Gramática da Linguagem GeoMDQL
Figura 5.6 Exemplo de Utilização de Funções em GeoMDQL
A definição do elemento geomdql function, mostrada na Figura 5.7, possibilita a construção
de instruções em uma consulta GeoMDQL, envolvendo qualquer um dos operadores apresentados na Seção 5.3. Como pode ser observado na Figura 5.7 e também na gramática completa
exibida no Apêndice A, em nenhum momento utilizamos os nomes dos operadores multidimen-
67
sionais e geográficos disponı́veis na linguagem GeoMDQL. Ao contrário da gramática original
da linguagem MDX, detalhada em [72], que mantém o nome das operações permitidas na linguagem, optamos por especificar uma gramática mais genérica, que abstrai certos detalhes.
Estes detalhes ficam sob responsabilidade do processador da linguagem, que avalia as operações
possı́veis em uma fase de validação que é realizada após a execução do parser. Com essa abordagem, a gramática fica mais legı́vel, de fácil manutenção, melhores mensagens de erro podem
ser definidas pela aplicação, e por fim, a linguagem pode ser estendida sem a necessidade de
alterações na gramática.
Figura 5.7 Elemento geomdql expression da Gramática da Linguagem GeoMDQL
Dessa forma, tanto os operadores herdados da linguagem MDX quanto os novos operadores
definidos para a linguagem GeoMDQL, podem ser utilizados em uma consulta. Por exemplo,
o operador Filter, quando utilizado em uma especificação de eixo em GeoMDQL, retorna um
subconjunto de elementos de um outro conjunto, baseado na aplicação de uma restrição. Dessa
forma, a instrução
Filter ({[Localizacao].[Cidade].Members}, (Measures.[Populacao])> 500000 ) ON ROWS pode
ser utilizada para mostrar no eixo ROWS todos os membros do nı́vel Cidade, da dimensão
Localizacao, que possuem o fato Populacao superior a 500000.
De forma semelhante, o operador GeoFilter, definido na Seção 5.3, pode ser utilizado em
68
uma especificação de eixo para aplicar uma restrição sobre um fato geográfico. Por exemplo, a
instrução em GeoMDQL:
GeoF ilter({[Localizacao].[Bairro].M embers}, Area([M easures].[AreaLote]) > 10000) pode
ser utilizada em uma consulta para retornar, para cada membro do nı́vel Bairro, os lotes com
área superior a dez mil metros quadrados.
Figura 5.8 Elemento member geometry da Gramática da Linguagem GeoMDQL
Outro exemplo consiste na utilização do operador TopCount, o qual retorna um número
especı́fico de items do topo de um conjunto ordenado. Assim, a instrução
TopCount({[Localizacao].[Estado].Members}, 5 , Measures.[Mortes NeoNatais])
ON COLUMNS pode ser especificada para mostrar no eixo COLUMNS, os membros do nı́vel
Estado da dimensão Localizacao que estão relacionados com os cinco maiores valores da medida
Mortes NeoNatais.
Figura 5.9 Exemplo de Consulta GeoMDQL Envolvendo o Elemento Geometry
Como pode ser observado na Figura 5.7, uma geometria de um membro geográfico (member geometry) também pode fazer parte de uma expressão da linguagem GeoMDQL. Este ele-
69
5.3 OPERADORES DA LINGUAGEM GEOMDQL
mento representa os valores geométricos válidos para um membro geográfico. A especificação
do elemento member geometry pode ser visualizada na Figura 5.8. Dessa forma, uma geometria
pode ser utilizada como parâmetro de operações geográficas. A consulta exibida na Figura 5.9
demonstra a utilização de uma geometria na especificação de uma consulta através da instrução
AtN orthOf ([Localizacao].[Cidade].M embers, P OIN T (47.797231
15.78111)).
A execução
desta instrução resultaria na identificação do conjunto de cidades que estão localizadas ao norte
do local representado pelo ponto.
O aninhamento de operadores também é previsto pela gramática da linguagem GeoMDQL.
Por exemplo, a instrução seguinte pode ser utilizada na especificação de um eixo, para retornar
todos os estados localizados ao nordeste do Distrito Federal, mas que não fazem divisa com o
estado de Pernambuco:
Intersect(AtNorthEastOf([Localizacao].[Estado].Members,
[Localizacao].[Estado].[DISTRITO FEDERAL]),
Disjoint([Localizacao].[Estado].Members,
[Localizacao].[Estado].[PERNAMBUCO]))
5.3
OPERADORES DA LINGUAGEM GEOMDQL
Em nossas pesquisas, fazemos a distinção entre os termos fato e medida, de acordo com as
definições dadas no Capı́tulo 4. Medida refere-se a um valor qualquer (numérico ou geométrico),
armazenado na tabela de fatos de um DW ou DWG. Por sua vez, fato é o resultado da aplicação
de uma função de agregação sobre um conjunto de medidas armazenadas em uma tabela de fatos
de um DW, para a definição dos cubos de dados. Dessa forma, em ambientes de DW/OLAP e
DWG/SOLAP, podemos identificar quatro tipos de operações realizadas sobre os dados, desde
a definição das medidas do DW/DWG até a especificação dos cubos de dados e a construção
das diferentes visões dos dados através das consultas aos cubos de dados. São elas:
1. Operações sobre Medidas: Após uma medida ser definida, seja ela convencional ou geográfica, é preciso associar uma função de agregação a ela no momento da geração do
cubo de dados. Neste grupo de operações, estão as funções de agregação do tipo distributiva, algébrica e holı́stica (ver Capı́tulo 4). Exemplos deste tipo de operações incluem
Sum, Count, Avg, MaxArea, MinPerimeter, e SumTouches entre outras. O resultado
da aplicação destas funções consiste na geração dos fatos do cubo de dados, de acordo
com os nı́veis de agregação definidos pelas hierarquias de cada dimensão. Também estão
nesta categoria, as operações realizadas para definir os fatos calculados. Os fatos calculados têm seu valor calculado de acordo com expressões aplicadas a uma ou mais medidas
armazenadas no DW/DWG;
2. Operações sobre Fatos: Este tipo de operação é realizada sobre os fatos do cubo de
70
dados. Filtragem, classificação e ordenação são exemplos de operações sobre os fatos
de um cubo. Obviamente, pelo menos uma dimensão do cubo deverá estar presente
neste tipo de operação e, apesar da operação ser aplicada ao fato, os membros dos nı́veis
também sofrem alterações, seja na ordem ou na quantidade de elementos. Exemplos de
operações para esta categoria são: i) Considerando um DWG com dados de saúde de
cada municı́pio brasileiro, uma consulta com filtragem sobre os fatos pode ser: Mostrar a
quantidade de óbitos maternos e a quantidade de nascidos vivos para cada estado brasileiro
onde a quantidade de óbitos maternos for superior a 100 ; ii) No caso de um DWG com
dados sobre registros de lotes urbanos, com uma medida geográfica correspondente a
geometria do lote e outra correspondente ao valor venal do lote, podemos ter uma consulta
do tipo: Mostrar a área e o valor venal de todos os lotes registrados no perı́odo X que
intersectam uma área ad hoc. Nesta última consulta, uma operação de relacionamento
espacial precisará ser aplicada aos fatos para retornar o resultado correto. O operador
Filter, da linguagem MDX [201, 72], é um exemplo de operador utilizado neste tipo de
operação;
3. Operações sobre Membros: Esta também é uma operação realizada sobre o cubo de dados,
entretanto, as filtragens, ordenações e classificações são aplicadas sobre os membros dos
nı́veis de uma determinada hierarquia. Como exemplo desta classe de operações podemos
ter: i) No contexto do DWG, relativo a dados sobre saúde, considerando a existência de
um nı́vel Estado em uma hierarquia qualquer pertencente a uma dimensão Localização,
uma operação pode ser realizada para Recuperar a população do ano 2002 para todos
os estados localizados ao nordeste do Distrito Federal. Esta operação utiliza o operador
espacial ao nordeste de para filtrar os membros do nı́vel estado; ii) Outro exemplo deste
tipo de operação é: Para cada Estado da Região Norte, mostrar a quantidade de nascidos
vivos e a quantidade de óbitos maternos no ano de 2002 ;
4. Operações sobre Nı́veis: Nesta categoria, estão as operações de agregação e desagregação,
envolvendo operadores como o Drilldown e Rollup. Também fazem parte desta categoria,
os operadores utilizados para navegação na estrutura dos cubos de dados;
A primeira categoria da taxonomia de operações sobre DWG proposta neste capı́tulo, engloba operações sobre medidas, envolvendo as funções definidas no Capı́tulo 4, permitindo assim,
a definição de fatos numéricos e geográficos.
Para inserir operações espaciais na segunda categoria de operações, estendemos a especificação do operador Filter, da linguagem MDX [201, 72] com expressões para manipular fatos e
operadores geográficos. A extensão deste operador será detalhada na Seção 5.3.3. Normalmente,
as operações das categorias 2 e 3 são utilizadas em conjunto, aumentando o poder de análise dos
dados de um cubo. Um exemplo de consulta envolvendo estas duas categorias pode ser: Para
71
todos os estados que estão ao nordeste do Distrito Federal, que não fazem divisa com o estado
de Pernambuco e que possuem uma população acima de 10.000.000 de habitantes, recuperar a
população e quantidade de nascidos vivos no ano de 2002.
Por sua vez, a extensão da terceira categoria de operações, foi realizada da seguinte forma:
i) primeiramente, foram adicionados à sintaxe da linguagem, alguns dos operadores geográficos
listados no Capı́tulo 2; ii) em seguida, foi aplicada a mesma lógica de combinação de operadores,
utilizada no Capı́tulo 4 para a definição das novas funções de agregação, para propor novos
operadores para a linguagem GeoMDQL. Estes operadores serão detalhados na Seção 5.3.3.
Por fim, para a quarta categoria, que abrange operações sobre nı́veis, além dos operadores
já definidos para a linguagem MDX, foram propostas extensões para os operadores DrillupLevel
e DrillUpMember, para possibilitar a união das geometrias dos membros geográficos envolvidos
na operação (ver Seção 5.3.3).
Antes de listarmos os operadores da linguagem GeoMDQL, juntamente com sua sintaxe, é
importante darmos algumas definições utilizadas nas seções seguintes:
< M emberN ame > Representa o unique name ou nome único de um membro geográfico.
Como exemplo de um nome de membro temos:
[Localizacao].[Estado].[PERNAMBUCO] ;
< M emberSet > Representa um conjunto de membros geográficos pertencentes a uma dimensão geográfica. Exemplos de conjuntos de membros são:
i) [Localizacao].[Estado].Members (representando todos os estados do nı́vel Estado);
ii) [Localizacao].[PERNAMBUCO].Children (representando todas as meso regiões pertencentes ao estado de Pernambuco).
< M emberGeometry > Representa a geometria de um membro geográfico. Também pode se
referir a uma geometria de um objeto geográfico que não pertence às dimensões do cubo
geográfico, mas está sendo utilizado como parâmetro para a realização de alguma análise.
Um exemplo disto consiste em:
POINT(-47.7972315212149 -15.7811190610677). Além do tipo geométrico POINT dado
neste exemplo, este parâmetro também pode receber outros tipos de geometria válidos,
como por exemplo, POLYGON, LINE, MULTILINE e MULTIPOLYGON ;
< N umericExpression > Representa um valor numérico qualquer. Pode ser utilizado, por
exemplo, para informar a quantidade de membros retornados em uma determinada consulta;
< BooleanExpression > Representa um valor booleano de algum parâmetro.
5.3.1
72
Operadores Geográficos
Parte dos operadores geográficos, apresentados no Capı́tulo 2, foram adicionados à linguagem
GeoMDQL, englobando:
operadores da classe binária booleana [246], mais precisamente os operadores topológicos
definidos em [94, 45], os quais são apresentados na Seção 5.3.1.1, e operadores cardinais
[132, 133, 260, 232, 133, 42, 89] (ver Seção 5.3.1.2).
operadores do tipo unário escalar [246], para cálculo da área, comprimento e perı́metro
e também do tipo binário escalar (e.g. operador de distância). Estes operadores são
apresentados na Seção 5.3.1.3.
operadores dos tipos unário espacial, binário espacial e n-ário espacial [246], que quando
aplicados a um conjunto de geometrias, geram novas geometrias. Estes operadores são
detalhados na Seção 5.3.1.4.
5.3.1.1
Operadores Topológicos
Esta seção lista os operadores topológicos da linguagem
GeoMDQL, os quais foram definidos originalmente em [94, 45] e adaptados para manipular
membros dos nı́veis de um cubo multidimensional e geográfico. A especificação de cada um
deles é dada a seguir:
Operador 1 (Touches).
Dado um conjunto de membros geográficos, este operador retorna um subconjunto contendo
todos os membros que são tocados por um determinado membro ou geometria. O primeiro
parâmetro é um conjunto de membros geográficos. O segundo parâmetro é o nome de um
membro, sua geometria, ou ainda, um outro conjunto de membros geográficos.
Sintaxe:
Touches(< M emberSet >,
< M emberN ame > | < M emberGeometry > | < M emberSet >)
Operador 2 (GeoIntersects).
Aplica a operação topológica de intersecção, retornando um conjunto com todos os membros
geográficos que intersectam determinado membro ou geometria. O primeiro parâmetro é um
conjunto de membros geográficos. O segundo parâmetro é o nome de um membro, sua geometria,
ou ainda, um outro conjunto de membros geográficos.
Sintaxe:
GeoIntersects(< M emberSet >,
< M emberN ame > | < M emberGeometry >, < M emberSet >)
73
Também foram incluı́dos na sintaxe da linguagem GeoMDQL os seguintes operadores: i)
Disjoint - retorna um conjunto com todos os membros geográficos que estão disjuntos de um
determinado membro ou geometria; ii) Crosses - retorna um conjunto com todos os membros
geográficos que são cruzados por um determinado membro ou geometria; iii) Equals - retorna
um conjunto de todos os membros geográficos que são iguais a um determinado membro ou
geometria; iv) Within - retorna um conjunto de todos os membros geográficos que contêm um
determinado membro ou geometria; v) Contains - retorna um conjunto de todos os membros
que estão contidos em um determinado membro ou geometria e vi) Overlaps - que retorna
um conjunto com todos os membros que sobrepõem um determinado membro ou geometria.
A sintaxe destes operadores é a mesma dos operadores Touches (Operador 1) e GeoIntersects
(Operador 2).
5.3.1.2
Operadores Cardinais Esta seção exibe os operadores cardinais da linguagem
GeoMDQL, os quais são baseados nas definições apresentadas em [132, 133, 260, 232, 133, 42, 89]
e adaptados para manipular membros geográficos de um cubo multidimensional e geográfico. A
especificação de cada um deles é dada a seguir:
Operador 3 (AtNorthOf ).
Dado um conjunto de membros geográficos, este operador retorna um subconjunto contendo
todos os membros que estão localizados ao norte de um determinado membro ou geometria. O
primeiro parâmetro é um conjunto de membros geográficos. O segundo parâmetro é o nome de
um membro, uma geometria representando um membro geográfico, ou ainda, um outro conjunto
de membros.
Sintaxe:
AtNorthOf(< M emberSet >
< M emberN ame > | < M emberGeometry > | < M emberSet >)
Os demais operadores cardinais adicionados à GeoMDQL (i.e. AtSouthOf (ao sul), AtEastOf
(ao leste), AtWestOf (ao oeste), AtNorthEastOf (ao nordeste), AtNorthWestOf (ao noroeste),
AtSouthEastOf (ao sudeste) e AtSouthWestOf (ao sudoeste)) possuem a mesma sintaxe do
operador AtNorthOf (Operador 3).
5.3.1.3
Operadores Métricos
Nesta seção, são discutidos os operadores GeoMDQL, que
quando aplicados a geometrias retornam um valor escalar. Então, definimos o operador Distance, da classe binária escalar [246], juntamente com os operadores Area, Perimeter e Length,
que são da classe unária escalar [246].Todos eles estão presentes na especificação do OGC [45].
Operador 4 (Distance).
Este operador retorna, para cada membro geográfico de um dado conjunto, um valor correspondente à distância até um determinado membro ou geometria. O primeiro parâmetro é nome do
74
membro ou sua geometria. O segundo parâmetro é um conjunto de membros geográficos.
Sintaxe:
Distance(< M emberN ame > | < M emberGeometry >, < M emberSet >)
Operador 5 (Area).
Este operador, quando aplicado a um conjunto de membros geográficos, retorna, para cada
membro do conjunto, um valor escalar que corresponde a sua área geográfica. Este operador
recebe como parâmetro um conjunto de membros geográficos.
Sintaxe:
Area(< M emberSet >)
Operador 6 (Length).
membro do conjunto, um valor escalar que corresponde ao seu comprimento. Este operador
recebe como parâmetro um conjunto de membros geográficos.
Sintaxe:
Length(< M emberSet >)
Operador 7 (Perimeter ).
membro do conjunto, um valor escalar que corresponde ao seu perı́metro. Este operador recebe
como parâmetro um conjunto de membros geográficos.
Sintaxe:
Perimeter(< M emberSet >)
5.3.1.4
Operadores que Geram Novas Geometrias
.
Nesta seção, apresentamos operadores que quando aplicados a um ou mais membros geográficos, geram novas geometrias. Estes operadores estão presentes na especificação do OGC
[45], e foram adaptados para manipular membros de um cubo multidimensional e geográfico.
Operador 8 (Intersection).
Retorna a geometria que corresponde à intersecção entre duas outras. No primeiro e no segundo
parâmetro, deve ser informado o nome do membro ou uma geometria válida.
Sintaxe:
Intersection(< M emberN ame > | < M emberGeometry >,
< M emberN ame > | < M emberGeometry >)
Operador 9 (GeoUnion).
Este operador retorna a união das geometrias passadas como parâmetros. Podem ser passados
como parâmetro, o nome ou a geometria de um membro, ou ainda um conjunto de membros.
75
Sintaxe:
GeoUnion(< M emberN ame > | < M emberGeometry >,
GeoUnion(< M emberSet >)
Operador 10 (Difference).
Retorna a geometria que corresponde à diferença da intersecção de dois membros geográficos.
No primeiro e segundo parâmetros, são passados o nome ou a geometria do membro geográfico.
Sintaxe:
Difference(< M emberN ame > | < M emberGeometry >,
Operador 11 (BBox ).
Este operador retorna o mı́nimo retângulo envolvente de um membro geográfico. Pode ser
aplicado a um membro ou conjunto de membros.
Sintaxe:
BBox(< M emberN ame > | < M emberGeometry >)
BBox(< M emberSet >)
Operador 12 (Buffer ).
Retorna a geometria formada pelos pontos localizados a uma distância especı́fica e ao redor de
um membro geográfico. Pode ser aplicado a um membro, sua geometria ou a um conjunto de
membros.
Sintaxe:
Buffer(< M emberN ame > | < M emberGeometry >, < N umericExpression >)
Buffer(< M emberSet >, < N umericExpression >)
Operador 13 (ConvexHull ).
Retorna o limite exterior convexo de um membro geográfico ou conjunto de membros. Pode
receber como parâmetro o nome de um membro, sua geometria ou um conjunto de membros.
Sintaxe:
ConvexHull(< M emberN ame > | < M emberGeometry > | < M emberSet >)
Operador 14 (Clipping ).
Este operador é utilizado para recortar uma área qualquer, pertencente a um membro ou conjunto de membros geográficos. O segundo parâmetro deve ser uma geometria do tipo Polı́gono,
representando a área que será recortada. O primeiro parâmetro pode ser um membro geográfico,
sua geometria, ou ainda, um conjunto de membros.
Sintaxe:
Clipping(< M emberN ame > | < M emberGeometry >, < M emberGeometry >)
Clipping(< M emberSet >, < M emberGeometry >)
76
Operador 15 (Point).
Quando aplicado a um membro ou conjunto de membros do tipo polı́gono, este operador retorna
uma geometria do tipo Ponto, que corresponde ao ponto central da geometria. Podem ser
passados como parâmetro, o nome de um membro geográfico, sua geometria ou um conjunto de
membros.
Sintaxe:
Point(< M emberN ame > | < M emberGeometry > | < M emberSet >)
5.3.2
Operadores Multidimensionais
Como a nossa linguagem estende a linguagem MDX, todos os operadores analı́ticos e multidimensionais originalmente definidos para MDX [72, 254, 67, 201] estão diponı́veis na linguagem
GeoMDQL. Alguns destes operadores foram listados no Capı́tulo 2 e sua sintaxe permanece
conforme originalmente definida pela gramática da linguagem MDX [72, 254].
Alguns destes operadores foram sobrecarregados na linguagem GeoMDQL, para a manipulação de membros de dimensões geográficas em consultas espaciais e multidimensionais,
como é o caso de operadores como Members e Children. Os operadores MDX, que foram reimplementados para a linguagem GeoMDQL, são listados na Tabela 5.1.
5.3.3
Operadores Geográficos e Multidimensionais (SOLAP)
Para definirmos os operadores geográficos e multidimensionais da linguagem GeoMDQL,
seguimos a mesma lógica aplicada na definição das funções de agregação de medidas espaciais,
e detalhada no Capı́tulo 4. Assim, novos operadores foram definidos a partir da combinação
das operações pertencentes às classes distributiva, algébrica e holı́stica [135] com as operações
espaciais dadas em [246]. Os seguintes operadores são resultantes desta combinação:
Operador 16 (LowDistance).
Ordena um conjunto de membros em ordem crescente pela distância em relação a um determinado ponto. O terceiro parâmetro é opcional, e denota a quantidade de membros retornados na
consulta. Quando este parâmetro é omitido, todos os membros são retornados. Por Exemplo,
a instrução a seguir:
LowDistance( [Localizacao].[Estado].[Distrito Federal], 5, [Localizacao].[Estado].members), é
utilizada em uma consulta para retornar somente as cinco menores distâncias entre o Distrito
Federal e os demais membros do nı́vel Estado. < BooleanExpression > é outro parâmetro
opcional, e representa o valor booleano que indica se a distância entre os membros é ou não
retornada. Quando omitido, o valor padrão é falso, e a distância não é retornada.
Sintaxe:
LowDistance(< M emberN ame > | < M emberGeometry >
77
Tabela 5.1 Operadores GeoMDQL sobrecarregados da linguagem MDX
Operador
Descrição
DrilldownLevel
Realiza a operação de Drill-Down sobre um conjunto DrilldownLevel(<Set> | <MemberSet>)
de membros, que podem representar um nı́vel em uma
hierarquia geográfica
Sintaxe
DrilldownMember Aplica a operação de Drill-Down ao conjunto de DrilldownMember(<MemberSet>,
membros geográficos definidos no primeiro parâmetro, <MemberSet>)
que estão no conjunto representado pelo segundo
parâmetro.
DrillupLevel
Aplica a operação de Drill-Up ou Roll-Up aos mem- DrillupLevel(<MemberSet>)
bros pertencentes a um conjunto, que podem representar um nı́vel em uma hierarquia geográfica.
DrillupMember
Aplica a operação de Drill-Up ao conjunto de membros DrillupMember(<MemberSet>,
geográficos definidos no primeiro parâmetro, que estão <MemberSet>)
no conjunto representado pelo segundo parâmetro.
Ancestor
Retorna o ancestral de um membro em um deter- Ancestor(<MemberName>, <LevelName>)
minado nı́vel da hierarquia geográfica, representado Ancestor(<MemberName>,
pelo nome do nı́vel (<LevelName>) ou por um valor <NumericExpression>)
numérico (<NumericExpression>) correspondente ao
ı́ndice do nı́vel na hierarquia
Descendants
Recupera o conjunto de descendentes de um mem- Descendants(<MemberName>)
bro geográfico, em todos os nı́veis anteriores ou em Descendants(<MemberNAme>,
um determinado nı́vel da hierarquia, representado pelo <LevelName>)
nome do nı́vel (<LevelName>) ou pelo seu ı́ndice Descendants(<MemberName>,
(<NumericExpression>).
<NumericExpression>)
Ascendants
Recupera o conjunto de membros ascendentes de um Ascendants(<MemberName>)
determinado membro geográfico.
Members
Retorna o conjunto de membros pertencentes a um < LevelN ame >.Members
determinado nı́vel, representado por < LevelN ame >
Children
Retorna todos os filhos de um determinado membro <MemberName>.Children
geográfico.
Siblings
Retorna todos os irmãos de um determinado membro <MemberName>.Siblings
geográfico, pertencentes ao mesmo nı́vel, incluindo ele
próprio.
78
[, < N umericExpression >],
< M emberSet > [, < BooleanExpression >])
Operador 17 (TopDistance).
É o inverso do operador LowDistance, ou seja, ordena os membros em ordem decrescente.
Operador 18 (RankArea).
Este operador é utilizado para classificar um conjunto de membros geográficos de acordo com o
tamanho de sua área geográfica. O membro geográfico de maior área ocupa a primeira posição.
Sintaxe:
RankArea(< M emberSet >)
Operador 19 (RankPerimeter ).
É utilizado para classificar um conjunto de membros geográficos de acordo com o tamanho de
seu perı́metro. O membro geográfico de maior perı́metro ocupa a primeira posição.
Sintaxe:
RankPerimeter(< M emberSet >)
Operador 20 (RankLength).
É utilizado para classificar um conjunto de membros geográficos de acordo com o seu comprimento. O membro geográfico de maior tamanho ocupa a primeira posição.
Sintaxe:
RankLength(< M emberSet >)
Operador 21 (MaxArea).
Dado um conjunto de membros geográficos, ele retorna o membro de maior área geográfica.
Sintaxe:
MaxArea(< M emberSet >)
Operador 22 (MinArea).
É o inverso do operador MaxArea.
Operador 23 (MaxPerimeter ).
Dado um conjunto de membros geográficos, ele retorna o membro de maior perı́metro.
Sintaxe:
MaxPerimeter(< M emberSet >)
Operador 24 (MinPerimeter ).
É o inverso do operador MaxPerimeter.
Operador 25 (MaxLength).
Dado um conjunto de membros geográficos, ele retorna o membro geográfico de maior comprimento.
79
Sintaxe:
MaxLength(< M emberSet >)
Operador 26 (MinLength).
Dado um conjunto de membros geográficos, ele retorna o membro geográfico de menor comprimento.
Sintaxe:
MinLength(< M emberSet >)
Operador 27 (AvgArea).
Dado um conjunto de membros geográficos, ele retorna o valor escalar correspondente à média
das áreas geográficas dos membros.
Sintaxe:
AvgArea(< M emberSet >)
Operador 28 (AvgPerimeter ).
Retorna um valor escalar que corresponde ao valor médio dos perı́metros dos membros geográficos passados como parâmetro.
Sintaxe:
AvgPerimeter(< M emberSet >)
Operador 29 (AvgLength).
Retorna um valor escalar que corresponde ao comprimento médio de um conjunto de membros
geográficos.
Sintaxe:
AvgLength(< M emberSet >)
Operador 30 (MedianArea).
Dado um conjunto de membros geográficos, ele retorna o valor escalar correspondente ao valor
mediano das áreas geográficas destes membros.
Sintaxe:
MedianArea(< M emberSet >)
Operador 31 (MedianPerimeter ).
mediano dos perı́metros destes membros.
Sintaxe:
MedianPerimeter(< M emberSet >)
Operador 32 (MedianLength).
80
mediano dos comprimentos destes membros.
Sintaxe:
MedianLength(< M emberSet >)
Operador 33 (ModeArea).
modal (que aparece com mais freqüência) das áreas geográficas destes membros.
Sintaxe:
ModeArea(< M emberSet >)
Operador 34 (ModePerimeter ).
modal dos perı́metros destes membros.
Sintaxe:
ModePerimeter(< M emberSet >)
Operador 35 (ModeLength).
Dado um conjunto de membros geográficos, este operador retorna o valor escalar correspondente
ao valor modal dos comprimentos destes membros.
Sintaxe:
ModeLength(< M emberSet >)
Também fazem parte do conjunto de operadores multidimensionais e geográficos da linguagem GeoMDQL os operadores Drillout e Drillin, cujas definições são dadas a seguir.
Operador 36 (Drillout).
Retorna todos os membros que fazem divisa com um determinado membro geográfico, da mesma
hierarquia de uma dimensão geográfica. Quando presente na operação,o segundo parâmetro (que
pode ser true ou false) indica se as geometrias dos membros envolvidos são agrupadas ou não,
podendo transformar o resultado em um único objeto geográfico. O valor padrão para este
parâmetro é falso.
Sintaxe:
Drillout(< M emberN ame > [, < BooleanExpression >])
Operador 37 (Drillin).
Retorna todos os membros que estão dentro de um determinado membro geográfico, presente
na mesma hierarquia de uma dimensão geográfica.
Sintaxe:
Drillin(< M emberN ame >)
GeoFilter estende o operador Filter da linguagem MDX, para a utilização de medidas geográficas e operações espaciais sobre estas medidas. Assim, sua definição e sintaxe são dadas
como segue:
81
Operador 38 (GeoFilter ).
Realiza uma filtragem em um conjunto de membros, geográficos ou não, através da aplicação de
uma expressão lógica baseada em operadores espaciais (e.g. operadores topológicos e cardinais
- ver Capı́tulo 2). Dessa forma, o parâmetro < GeoLogicalExpression > pode assumir valores
como: i) Area([M easures].[AreaLote]) > 2000, que retorna somente as medidas geográficas que
possuem área superior a 2000 metros quadrados; ii)AtNortOf([Measures].[AreaLote],POINT(47.7972315212149 -15.7811190610677))), que retorna somente as medidas que estão localizadas
ao norte de determinada geometria.
Sintaxe:
GeoFilter(< M emberSet >, < GeoLogicalExpression >)
Outro operador definido para a linguagem proposta nesta tese é o NGeoGrouping, cuja
definição é dada abaixo:
Operador 39 (NGeoGrouping ).
Possui caracterı́sticas de mineração de dados, e quando aplicado a um conjunto de medidas
geográficas, ele as organiza em N agrupamentos. O primeiro parâmetro deste operador é o
nome de um membro geográfico ou conjunto de membros geográficos, que definem o contexto
do agrupamento. O segundo parâmetro informa quantos agrupamentos deverão ser criados,
enquanto o último parâmetro indica o nome da medida geográfica que terá seus valores
agrupados. Por exemplo, a instrução em GeoMDQL
NGeoGrouping([Localizacao].[Estado].[PERNAMBUCO],50,[Measures].[TotalCasos])
define
que todas os casos de dengue localizados no estado de Pernambuco devem ser organizados em
cinqüenta grupos.
Sintaxe:
NGeoGrouping(< M emberN ame > | < M emberSet >, < N umericalExpression >, <
GeoM easure >)
Para encontrar os vizinhos mais próximos de um determinado local, ou de um membro
geográfico, a linguagem GeoMDQL conta com o operador NNearestNeighbor, definido abaixo.
Operador 40 (NNNeighbors).
Este operador, quando aplicado a um conjunto de medidas geográficas, retorna as N medidas
mais próximas de um determinado local. O primeiro parâmetro deve ser o nome de um membro geográfico, ou um conjunto de membros. O segundo parâmetro, indica quantos vizinhos
são retornados, enquanto o terceiro corresponde ao nome da medida geográfica envolvida na
consulta. Por fim, o quarto parâmetro, representa a geometria de referência usada na análise.
Por exemplo, a instrução em GeoMDQL:
NNNeighbors([Localizacao].[Estado].[PERNAMBUCO], 150,
[Measures].[LocalCaso] , POINT(287747 9107940)) indica que, considerando todos os casos de
5.4 ARQUITETURA DO PROCESSADOR DA LINGUAGEM GEOMDQL
82
dengue localizados no estado de Pernambuco, serão retornados os 150 mais próximos do ponto
representado pela geometria POINT(287747 9107940).
Sintaxe:
NNNeighbors(< M emberN ame > | < M emberSet >, < N umericalExpression >,
< GeoM easure >, < M emberGeometry >)
Dois outros operadores foram definidos para serem aplicados sobre nı́veis de uma hierarquia
geográfica: GeoDrillUpLevel e GeoDrillUpMember. Eles são detalhados a seguir.
Operador 41 (GeoDrillUpLevel ).
Estende o operador DrillUpLevel, definido para a linguagem MDX, de acordo com a especificação do operador Drill-Up [134, 135], realizando a união das geometrias dos membros geográficos envolvidos na operação.
Sintaxe:
GeoDrillUpLevel(< M emberSet >)
Operador 42 (GeoDrillUpMember ).
Estende operador DrillUpMember da linguagem MDX, realizando a união das geometrias dos
membros geográficos envolvidos na operação.
Sintaxe:
GeoDrillUpMember(< M emberSet >, < M emberSet >)
5.4
ARQUITETURA DO PROCESSADOR DA LINGUAGEM GEOMDQL
Nesta seção, descrevemos a arquitetura para processamento geográfico e multidimensional denominada Golapware, na qual está inserido o processador da linguagem GeoMDQL. Esta arquitetura pode ser caracterizada como uma instância da arquitetura GOLAPA (ver Capı́tulo 3),
uma vez que esta realiza a instanciação e evolução das camadas I, II e III de GOLAPA. Estas
três camadas foram definidas para prover, respectivamente, dados, serviços e interface com o
usuário no contexto de um ambiente de suporte a decisões geográfico e multidimensional. Dessa
forma, nesta seção, descrevemos quais são os componentes lógicos pertencentes a cada camada
desta arquitetura, indicando os relacionamentos e dependências existentes entre estes componentes. Este detalhamento não é realizado na arquitetura GOLAPA por ela ter sido definida
em um nı́vel mais alto de abstração.
Na Figura 5.10 é exibida a arquitetura Golapware utilizando diagramas de componentes da
linguagem UML [205]. Este diagrama demonstra como a arquitetura está logicamente particionada em componentes de software, e como estas partes colaboram entre-si.
É importante indicar que as questões sobre integração de dados que são importantes para
a construção do DWG não são abordadas nesta tese. Dessa forma, assumimos que os dados
são disponibilizados já integrados à camada II da Figura 5.10. Entretanto, esta suposição não
83
Figura 5.10 A Arquitetura Golapware
prejudica nosso trabalho, uma vez que a carga do DWG pode ser realizada de forma semiautomática através da utilização de ferramentas de ETL (Extração, Transformação e Leitura)
convencionais [163], juntamente com scripts desenvolvidos na própria linguagem de consulta do
SGBD utilizado para a construção do DWG. A seguir, descrevemos cada uma das camadas da
arquitetura proposta e ilustrada na Figura 5.10.
5.4.1
84
Camada I - Data Warehouse Geográfico
Na Camada I, temos o Data Warehouse Geográfico (DWG), fonte integrada de dados geográficos
e multidimensionais. Os modelos de dados que guiam o desenvolvimento de um DWG diferem
dos modelos tradicionais, por terem a necessidade de representar dados geográficos, de acordo
com as definições dadas no Capı́tulo 4. Por isso, o esquema de DWG da Camada I foi definido
com base no modelo apresentado na Seção 4.2 do Capı́tulo 4.
Para escolha do Sistema Gerenciador de Banco de Dados Espaciais (SGBDE), inúmeras são
as opções disponı́veis atualmente. Porém, como desejamos que as implementações sejam abertas
e extensı́veis, temos os seguintes requisitos essenciais para esta escolha:
O SGBDE deverá ser de domı́nio público, aberto e extensı́vel e independente de
plataforma, para permitir uma melhor re-utilização e evolução da arquitetura;
O SGBDE deverá permitir a definição, o armazenamento, o gerenciamento e a manipulação de dados geográficos de acordo com as diretrizes definidas pelo OGC [51].
5.4.2
Camada II - Processamento Multidimensional e Geográfico
Para a implementação desta segunda camada da arquitetura, a nossa estratégia faz uso de um
mecanismo de processamento analı́tico e multidimensional (i.e. um servidor OLAP), acrescido
de funcionalidades para tratamento de dados geográficos e para realização de consultas espaciais.
Dessa forma, temos à disposição um servidor OLAP estendido com processamento espacial.
Novamente, para prover uma arquitetura baseada em padrões bem definidos e difundidos e que
seja aberta e extensı́vel, as principais caracterı́sticas desejáveis do processador analı́tico são:
O mecanismo de processamento utilizado deverá ser de domı́nio público, aberto e extensı́vel e independente de plataforma, para permitir uma melhor re-utilização e evolução
da arquitetura Golapware;
O mecanismo de processamento deverá ser compatı́vel com a linguagem MDX [67, 201],
uma vez que essa linguagem pode ser considerada como um padrão de fato para realização
de consultas OLAP, é extensı́vel e facilita a elaboração de consultas envolvendo mais
de duas dimensões. Isto facilita a extensão do servidor para a utilização da linguagem
GeoMDQL, uma vez que esta tem como base a linguagem MDX;
O mecanismo de processamento deverá dar suporte aos três tipos de consulta definidos
em [82];
Um requisito não funcional importante para o desenvolvimento deste módulo é possibilitar
a compactação dos resultados, para diminuir o custo de transmissão de dados, caso o
acesso seja realizado via Internet.
85
Os principais componentes desta camada são o Servidor SOLAP e o Gerenciador de Metadados, os quais são descritos a seguir.
5.4.2.1
Servidor SOLAP
Um dos componentes do Servidor SOLAP é o Processador de Consultas, o qual é composto por
um Parser, um Validador, um Verificador de Tipo e um Avaliador de Consultas. O Parser é
responsável por realizar a análise léxica e sintática de uma instrução GeoMDQL. O componente
Validador verifica se a consulta é ou não válida, o que é realizado com o auxı́lio do Gerenciador
de Metadados, para verificar, por exemplo se: i) o esquema utilizado existe; ii) o cubo é válido;
iii) as dimensões, hierarquias, nı́veis e fatos do cubo existem; iv) as funções utilizadas são válidas,
o que é realizado confrontado o tipo e a quantidade dos parâmetros reais com informações sobre
os parâmetros formais. Por sua vez, o Verificador de Tipo identifica qual tipo de consulta está
sendo executada (i.e. se é uma consulta multidimensional, uma consulta geográfica ou ainda
uma consulta geográfica e multidimensional).
O Avaliador de Consultas é responsável pela avaliação das consultas e geração do resultado
final. Para resolver uma consulta, o componente de avaliação verifica se os fatos e membros
solicitados estão em cache, o que é possı́vel através do acesso ao Gerenciador de Cache. Além
disso, é verificado se é possı́vel derivar o resultado a partir dos dados em cache. Se os dados
solicitados não estiverem em memória, o avaliador de consultas aciona o componente Gerenciador de Execução para recuperar os dados solicitados. Dessa forma, o Avaliador de Consultas
garante o uso das funções geográficas e multidimensionais implementadas pelo Servidor SOLAP.
O componente Gerenciador de Execução coordena o envio e recebimento de instruções para
recuperação de dados armazenados no DWG. Fazem parte deste componente, o Gerador SQL
Espacial e o Gerenciador de Dialetos. O componente Gerador SQL Espacial é responsável por
gerar instruções SQL para recuperar dados armazenados no DWG. Este componente utiliza as
funcionalidades do Gerenciador de Metadados para obter informações sobre os relacionamentos
existentes entre os esquemas multidimensionais (que descrevem os cubos de dados) e os esquemas
do DWG. As instruções SQL são geradas de acordo com o dialeto do SGBD espacial utilizado
para a criação do DWG. Como um operador pode ser implementado de forma diferente em
cada sistema gerenciador de banco de dados, se faz necessário a existência de um Gerenciador
de Dialetos para disponibilizar informações sobre a sintaxe de cada operador do SGBD. Este
gerenciador de dialetos possibilita então, a construção de um mapeamento entre os operadores
especificados para a linguagem GeoMDQL e suas respectivas implementações no SGBD. Assim,
a arquitetura prevê a utilização de diferentes sistemas de gerenciamento de banco de dados.
O componente Gerenciador de Cache é responsável por manter e gerenciar dados agregados
em memória. Isto é realizado com o auxı́lio do Gerenciador de Agregação. Por sua vez, o
Otimizador de Consultas tem como objetivo, determinar a melhor forma de execução de uma
86
consulta GeoMDQL. Isto envolve a avaliação dos possı́veis planos de execução de uma dada
consulta e a reescrita de consultas para a obtenção de um resultado de forma mais eficiente.
Porém, estes três componentes não foram abordados no trabalho discutido neste documento.
5.4.3
Camada III - Interface com o Usuário
Nesta camada da arquitetura Golapware, estão os componentes responsáveis pela interação
com o usuário. Alguns dos requisitos para a implementação da interface gráfica são listados em
seguida, os quais foram inspirados no estudo apresentado em [97]:
Acesso via Web: Além de uma aplicação cliente desktop, uma aplicação voltada para Web
permite maior facilidade e flexibilidade no acesso ao Servidor SOLAP. Dessa forma, com
interface gráfica acessı́vel via navegador da Internet, é necessário utilizar tecnologias que
diminuam ao máximo, o tempo de renderização dos resultados, uma vez que consultas
envolvendo dados geográficos podem resultar em uma grande quantidade de dados e a
banda de conexão às vezes, pode ser limitada;
Facilidade de uso: a interface deve ser fácil de utilizar, principalmente por usuários sem
muitos conhecimentos em Informática;
Intercâmbio de dados: a interface deve disponibilizar mecanismos para exportar/salvar
os resultados das consultas realizadas para outros formatos de dados, bem como permitir integração com outras ferramentas de análise de dados como Planilhas Eletrônicas e
Sistemas de Informações Geográficas;
Sincronismo: deve haver sincronismo entre os gráficos, mapas e tabelas presentes no
resultado de uma consulta. Assim, uma operação como por exemplo Drill-Down, realizada
em uma tabela que representa os dados multidimensionais, deve ser refletida no mapa
(quando houver alguma correspondência geográfica) e também no gráfico (se este existir);
Uso de resultados de consultas como parâmetro: a interface deve permitir que o resultado
de uma consulta seja utilizado como parâmetro na realização de outra consulta, seja ela
geográfica ou multidimensional;
Contexto dos resultados: a aplicação deve utilizar informações para contextualizar o
resultado de uma consulta. Muitas vezes essas informações não são requisitadas pelo
usuário na consulta, entretanto, são indispensáveis para a interpretação dos resultados;
Legibilidade: legendas devem ser apresentadas juntamente com os mapas, gráficos e
tabelas para possibilitar uma melhor interpretação dos dados;
87
Detalhamento de informações: a interface deve facilitar a obtenção de informações sobre
os objetos apresentados na tela, por exemplo, através de cliques de mouse sobre os objetos
geográficos;
Interatividade: no que se refere a consultas envolvendo operações espaciais, é importante
que o usuário possa interagir com um mapa previamente visualizado através de cliques
de mouse;
Utilização de metáforas visuais: metáforas visuais podem ser utilizadas para representar
as operações sobre os dados e para a formulação de consultas, desde que estas consultas
obedeçam à sintaxe definida pela linguagem GeoMDQL.
Para atender os requisitos listados acima, a camada de interface conta com três componentes principais: o Gerenciador de Consultas, o Gerenciador de Catálogos e o Gerenciador de
Resultados, os quais são descritos a seguir.
5.4.3.1
Gerenciador de Consultas
Como pode ser observado na Figura 5.10, o componente Gerenciador de Consultas é composto
por um Editor Textual, um Editor Gráfico e um Gerenciador de Templates. Este componente
tem como objetivos: i) prover a interação com o usuário, disponibilizando funcionalidades
que auxiliem na especificação de consultas (e.g. seleção de catálogos, edição de consultas,
armazenamento e recuperação de consultas e de templates de consultas); ii) interagir com o
Gerenciador de Metadados para a recuperação de metadados necessários para a especificação
de consultas; iii) interagir com o Servidor OLAP para o envio de consultas e recebimento dos
resultados do processamento das consultas e iv) interagir com o Gerenciador de Resultados para
a exibição dos resultados e posterior elaboração de novas consultas.
O componente Gerenciador de Templates é utilizado para definir, armazenar e recuperar
templates de consultas, operações e funções. Com o auxı́lio deste componente, o usuário pode
recuperar, por exemplo, informações sobre o nome, a sintaxe e os parâmetros formais das funções
implementadas pelo servidor SOLAP. Estas informações são disponibilizadas pelo componente
Descritor de Funcionalidades, pertencente ao Gerenciador de Metadados.
Com o componente Editor Manual, o usuário pode especificar consultas textuais através de
instruções expressas na sintaxe da linguagem GeoMDQL. Para auxiliar o usuário na elaboração
das consultas, este componente utiliza as funcionalidades do Gerenciador de Templates.
Por sua vez, o Editor Gráfico auxilia o usuário na especificação de consultas através da
utilização de recursos gráficos e visuais. Isto é realizado por meio da interação constante com o
Gerenciador de Metadados para recuperar informações que possibilitem a navegação visual na
estrutura dos cubos de dados, bem como na interação com o Servidor SOLAP para execução
de sub consultas para recuperar nomes de membros dos nı́veis. Isto auxilia na elaboração das
88
consultas complexas e com muitas restrições aplicadas sobre os membros de um cubo de dados.
Da mesma forma, o Editor Gráfico mantém uma interação constante com o Gerenciador de
Resultados para possibilitar a utilização dos resultados de consultas previamente executadas na
elaboração de novas consultas e também para a execução automática de consultas para permitir
a sincronização entre os mapas, tabelas e gráficos.
5.4.3.2
Gerenciador de Catálogos
Para especificar uma consulta, seja através de edição textual ou gráfica, o usuário precisa selecionar um catálogo de dados, o que é realizado através do acesso ao componente Seletor de
Catálogos, pertencente ao Gerenciador de Catálogos. Em nossa abordagem, cada catálogo é
composto por um identificador, um conjunto de informações sobre a conexão com o servidor de
dados e por um esquema que contém as definições dos cubos de dados geográficos e multidimensionais.
Os componentes Criador de Catálogos e Seletor de Catálogos possibilitam, respectivamente,
a definição e o armazenamento de catálogos de dados no Repositório de Metadados da arquitetura. Isto é realizada com o auxı́lio das funcionalidades disponibilizadas pelo Gerenciador de
Metadados.
5.4.3.3
Gerenciador de Resultados
Os resultados das consultas submetidas para processamento, através do Gerenciador de Consultas, são manipulados pelo Gerenciador de Resultados, o qual é composto pelos componentes
Gerenciador de Importação e Exportação e Visualizador de Resultados.
O Gerenciador de Importação e Exportação permite que o usuário salve os resultados para
posterior utilização, e também oferece funcionalidades para a exportação dos resultados para
diferentes formatos de dados, possibilitando a exibição dos dados em outras aplicações. A
importação de dados de outros formatos, para utilização em futuras análises e composição de
novas consultas também está prevista como funcionalidade para este componente.
Por sua vez, o componente Visualizador de Resultados é de grande importância para a camada de interface da arquitetura. Ele é composto por um Gerenciador de Exibição, um Gerenciador de Tabelas, um Gerenciador de Gráficos e um Gerenciador de Mapas. Estes componentes
permitem que o resultado de uma consulta seja visualizado de diferentes formas, dependendo
do tipo de consulta executada.
O Gerenciador de Tabelas permite a manipulação, a formatação e a visualização de dados
no formato de tabelas multidimensionais (quando for aplicável). O gerenciamento dos dados
tabulares permite que sejam realizadas operações sobre as células, colunas e linhas da tabela.
Estas operações possibilitam a recuperação de dados e metadados relacionados com o resultado
multidimensional. Estas funcionalidades do gerenciador de tabelas são utilizadas pelo compo-
89
nente Gerenciador de Consultas durante o processo de especificação das consultas utilizando
o Editor Gráfico. As operações de formatação envolvem definição de tipos de fonte, cores de
fontes e das células da tabela e outras formatações de caráter visual.
O Gerenciador de Mapas é responsável pela manipulação, formatação e exibição das geometrias relacionadas com os dados geográficos resultantes do processamento de uma consulta.
Este gerenciador prevê a disponibilização de funcionalidades comuns a ferramentas SIG, como
por exemplo sobreposição de camadas de mapas, formatação dos mapas, adição e formatação de
legendas e rótulos dos dados. As funcionalidades deste componentes são utilizadas pelo Gerenciador de Consultas durante o processo de especificação de consultas por intermédio do Editor
Gráfico.
De forma semelhante, o componente Gerenciador de Gráficos é responsável pela manipulação, formatação e exibição dos dados em forma de gráficos. Funcionalidades para criação
de diferentes tipos de gráficos estão previstas para este componente, bem como funcionalidades
para formatação de legendas, definição de cores de fundo, cores e tipos de fonte.
Gerenciador de Exibição coordena os três módulos anteriores e funciona como dispositivo
de sincronização, ou seja, quando uma operação é realizada sobre os dados de um dos componentes (i.e. gráfico, tabela ou mapa), um processamento é realizado para refletir a alteração
nos outros componentes, se estes estiverem sendo utilizados para a exibição dos resultados.
Este processamento pode envolver a utilização do Gerenciador de Consultas para submeter,
automaticamente, novas consultas ao Servidor SOLAP para recuperação de dados, ou seja, o
processamento realizado para a sincronização e atualização dos dados exibidos pelos componentes fica transparente ao usuário.
É importante salientarmos que, apesar dos requisitos desta camada terem sido levantados,
o projeto da interface foge do escopo desta tese e consiste em um trabalho em andamento [264].
5.4.4
Metadados
Outro componente importante que se aplica ao longo de todas as camadas da arquitetura Golapware, é o Gerenciador de Metadados. A principal funcionalidade do componente Gerenciador
de Metadados é fornecer a descrição dos esquemas de cubos multidimensionais e geográficos e
informar como estes esquemas são mapeados para os esquemas relacionais que definem o DWG.
Este mapeamento é guiado pelo modelo GeoMDCube, descrito no Capı́tulo 4. Este componente
também coordena o armazenamento e a recuperação dos metadados.
A partir dos metadados, é possı́vel identificar as correspondências existentes entre os dados
analı́ticos e geográficos, bem como é possı́vel obter informações que possibilitam a recuperação
destas correspondências. A fonte de metadados é indispensável para o processamento de requisições envolvendo operadores espaciais e multidimensionais, devido a esse tipo de consulta
necessitar de várias informações, tais como: saber se um determinado dado multidimensional
5.5 TIPOS DE CONSULTAS GEOMDQL
90
possui alguma correspondência geográfica, qual é este dado geográfico e como se deve proceder
para recuperá-lo.
No Gerenciador de Metadados, o componente Validador de Esquemas é responsável por verificar se os cubos que compõem um esquema são válidos. Esta verificação leva em consideração
as definições dadas pelo modelo GeoMDCube, descrito no Capı́tulo 4. Estes esquemas são criados com auxı́lio do Descritor de Esquemas, que utiliza informações do esquema do DWG para a
definição dos cubos de dados, possibilitando a criação do mapeamento entre o modelo multidimensional e o modelo do DWG. As informações sobre o esquema do DWG são disponibilizadas
pelo Gerenciador de Esquemas de DWG.
O componente Descritor de Funcionalidades é responsável por disponibilizar para a camada de interface, informações sobre as capacidades de processamento do Servidor SOLAP.
Estas informações identificam, por exemplo, quais funções e operadores são implementados
pelo servidor. Estas informações são utilizadas pelo componente Gerenciador de Templates da
camada de interface.
Finalmente, o Gerenciador de Persistência é o componente da arquitetura responsável pelo
armazenamento e recuperação dos metadados mantidos no Repositório de Metadados.
5.5
TIPOS DE CONSULTAS GEOMDQL
As consultas especificadas de acordo com a sintaxe da linguagem GeoMDQL, podem ser classificadas em três tipos (i.e. GEO, MD e GEOMD) [82, 84], os quais são detalhados a seguir:
GEO: Uma consulta do tipo GEO (Geográfica) contem apenas parâmetros geográficos para
executar a consulta espacial. Para este tipo de consulta, os usuários podem utilizar
operadores como, por exemplo, distance, intersects, contains, over e crosses para verificar
relacionamentos espaciais entre objetos geográficos. Como exemplo de aplicação prática
deste tipo de consulta, consideremos um DWG para análise do uso da terra, sobre o
qual as seguintes consultas são processadas: i) quais são as fazendas que intersectam
um determinado rio e que cultivaram arroz no ano de 2002 ou ii) quais são as fazendas
com área geográfica superior a X quilômetros quadrados, que estão localizadas dentro da
bacia hidrográfica Y. Geralmente, o resultado destas consultas é um conjunto de objetos
geográficos que são exibidas em mapas;
MD: Uma consulta do tipo MD (Multidimensional) não envolve nenhum operador geográfico,
contendo apenas parâmetros multidimensionais para a construção da consulta. Operadores que realizam cálculos sobre as medidas do cubo de dados e navegam na hierarquia
do cubo são comuns neste tipo de consulta. Exemplos comuns são operadores para filtragem e ordenação. Como exemplo prático da aplicação deste tipo de consulta, podemos
considerar um DWG com dados sobre vendas de produtos onde são executadas consultas
5.5 TIPOS DE CONSULTAS GEOMDQL
91
como i) Quais são os N produtos mais vendidos em cada categoria de produto no perı́odo
X ou ainda ii) Identificar quais são os clientes que juntos compraram X% do total geral
e para cada um destes clientes, identificar quais são os produtos responsáveis por Y% do
valor dos pedidos. Também é comum neste tipo de consultas, operadores de agregação e
desagregação amplamente difundidos na área de DW e OLAP, como drill-down, roll-up,
slice e dice [163, 229]. Os resultados destas consultas são analisados através de tabelas
multidimensionais e gráficos;
GEOMD: Uma consulta do tipo GEOMD (Geográfica Multidimensional) é resultante da combinação das duas anteriores. Adicionalmente, esta consulta é dividida em dois subtipos: i) GEOMD de Mapeamento, corresponde a uma consulta multidimensional (MD)
(i.e. não faz uso de nenhum operador espacial) acrescida da cláusula ON MAP. Dessa
forma, um processamento é realizado automaticamente pela aplicação, recuperando as
correspondências geográficas dos membros do cubo envolvidos na consulta. Assim, estas
correspondências geográficas podem ser exibidas em mapas enriquecendo a análise dos
dados. Para a realização deste mapeamento apenas a cláusula ON MAP é utilizada pelo
usuário, sem que ele tenha a necessidade de especificar operadores geográficos na consulta;
ii) GEOMD de Integração que é o tipo de consulta mais interessante no nosso entendimento. Este tipo de consulta utiliza os dois tipos de operadores (i.e. multidimensional e
geográfico) simultaneamente;
Para uma consulta do tipo GEOMD de Mapeamento, podemos citar como exemplo uma
consulta a um cubo de dados para identificar os melhores clientes, utilizando somente
operadores multidimensionais. Então, ocorre um processamento adicional, transparente
ao usuário, para que os pontos correspondentes aos endereços de cada cliente sejam exibidos no mapa que contextualizam a consulta. Neste caso, os resultados são exibidos em
tabelas e mapas. Por sua vez, no caso das consultas GEOMD de Integração, os usuários
utilizam, de forma integrada, operadores multidimensionais e geográficos para formular
consultas como:
Quais são as fazendas localizadas dentro da bacia hidrográfica X, que
fazem intersecção com algum rio e que produziram acima de Y toneladas do produto Z
nos anos A, B e C. O resultado deste tipo de consulta pode ser visualizado utilizando
mapas e/ou tabelas multidimensionais. Uma consulta de integração pode ter os dados
visualizados somente em tabelas, desde que a ausência dos dados geográficos não prejudique a interpretação dos resultados. Neste caso, os dados geográficos são utilizados
somente durante o processamento da consulta. Em GeoMDQL, isto é possı́vel omitindo
a instrução ON MAP.
É importante salientar que o resultado de uma consulta pode ser utilizado pelo usuário
como parâmetro para a realização de outra consulta. Além disso, qualquer consulta especificada
92
pode ser mapeada para uma das categorias listadas anteriormente. No próximo capı́tulo, são
apresentados exemplos de consultas de cada um destes tipos.
5.6
CONSIDERAÇÕES
Este capı́tulo apresentou a linguagem GeoMDQL, sua gramática, sintaxe e operadores. Optamos
por definir a gramática da linguagem GeoMDQL abstraindo alguns detalhes, como o nome do
operadores, por exemplo. Isto, entre outras vantagens, resulta em uma gramática de fácil
entendimento, designando parte das validações para o processador da linguagem.
Juntamente com a linguagem GeoMDQL, foi apresentada a arquitetura Golapware, uma
arquitetura que prima pela utilização de tecnologias padronizadas, a extensibilidade e pela
independência de plataforma. Para cada uma de suas camadas e componentes, Golapware
apresenta conceitos e tecnologias voltadas para um processamento geográfico e multidimensional
totalmente integrado, desde a base de dados até interface da aplicação cliente.
Também apresentamos neste capı́tulo, uma classificação dos tipos de operações que são
realizadas sobre os dados de um ambiente SOLAP, o que envolve operações sobre as medidas de
um DWG, operações sobre fatos de um cubo, operações sobre membros e operações sobre nı́veis
de uma hierarquia. Com os operadores definidos, foi verificado que uma consulta especificada
de acordo com a sintaxe da linguagem GeoDMQL pode ser de três tipos: GEO (Geográfica),
MD (Multidimensional) e GEOMD (Geográfica e Multidimensional),
Com a sintaxe integrada da linguagem GeoMDQL, e com a grande quantidade de operadores
geográficos e multidimensionais disponı́veis para a composição das consultas, é possı́vel verificar
o diferencial da nossa linguagem em relação às outras propostas presentes na literatura. Para
comprovar isto, aplicamos a sintaxe GeoMDQL a dois dos exemplos de consultas apresentadas
no Capı́tulo 3.
O primeiro exemplo, apresentado na proposta Piet [104] visa: Listar o total de unidades
vendidas e seu custo, por produto, forma de divulgação da promoção (promotion media - e.g.
rádio, tv, jornal) e lojas que estão localizadas em provı́ncias cortadas por algum rio. Esta
consulta é exibida na Figura 5.11-(A), de acordo com a sintaxe da linguagem GISOLAP-QL
[104]. A mesma consulta foi re-escrita na sintaxe GeoMDQL, conforme mostra a Figura 5.11(B). Conforme já mencionado anteriormente, no Capı́tulo 3, e pode ser confirmado na Figura
5.11-(A), a linguagem GISOLAP-QL não possui uma sintaxe integrada, e também não possui
operadores SOLAP como a linguagem GeoMDQL. Isto dificulta a elaboração de consultas mais
complexas, que combinam operadores métricos, topológicos, direcionais, de ordenação e ranking.
Outro caso para comparação com a linguagem GeoMDQL, é a linguagem SQL com extensão
espacial, utilizada pela proposta MapWarehouse [251], também descrita no Capı́tulo 3. Este
exemplo serve para comprovar o diferencial oferecido pela linguagem GeoMDQL, não somente
em relação a abordagem proposta pelo trabalho MapWarehouse, mas também em relação à
93
Figura 5.11 Comparação entre GeoMDQL e GISOLAP-QL [104]
todos os outros trabalhos que se baseiam em extensões da linguagem SQL para consultar dados
em um ambiente SOLAP. Na Figura 5.12-(A), está a instrução SQL do MapWarehouse para
a seguinte consulta: Exiba as áreas geográficas de plantação de milho e feijão e quantidades
de milho e feijão por área geográfica, dentro de uma janela retangular, para cada meso-região
e para cada micro-região do Estado da Paraı́ba, durante maio de 2003. Por sua vez, a Figura
5.12-(B) mostra como esta consulta é expressa em GeoMDQL. Como podemos observar, a
instrução GeoMDQL é consideravelmente mais simples do que a apresentada na Figura 5.12(A), e vale salientar que os exemplos dados nesta seção são consultas relativamente simples,
que podem ser formuladas em um ambiente SOLAP. Se consultas envolvendo mais operadores
forem especificadas, a complexidade da instrução SQL será aumentada consideravelmente.
Algumas consultas mais elaboradas, envolvendo um número maior de operadores GeoMDQL,
serão apresentadas no próximo capı́tulo. Além disso, no próximo capı́tulo, são dados alguns
detalhes de implementação das idéias propostas neste capı́tulo. A gramática da linguagem
GeoMDQL, discutida anteriormente, foi implementada por um parser escrito em Java, e o
servidor OLAP Mondrian [224] foi estendido para processar nossa linguagem, permitindo assim,
a realização dos três tipos de consulta definidos na Seção 5.5. Resultados obtidos com este
trabalho de implementação são mostrados no capı́tulo seguinte.
Figura 5.12 Comparação entre GeoMDQL e SQL Espacial do MapWarehouse [251]
94
CAPÍTULO 6
ASPECTOS DE IMPLEMENTAÇÃO
6.1
INTRODUÇÃO
Este capı́tulo tem como objetivo apresentar alguns detalhes relacionados com a implementação
e aplicação prática das idéias discutidas nesta tese.
Para as implementações, optamos por utilizar tecnologias de domı́nio público, abertas e extensı́veis. Isto, além de oferecer maior facilidade para a aquisição e instalação, dá possibilidades
para sua constante evolução. Questões de análise de desempenho e possı́veis limitações das
tecnologias envolvidas nas implementação não fazem parte do escopo do nosso trabalho.
O Restante deste capı́tulo está estruturado da seguinte forma: Na Seção 6.2, são listadas
algumas informações sobre a implementação dos operadores e das funções de agregação. A
Seção 6.3 exibe os detalhes de implementação de cada uma das camadas da nossa arquitetura
de processamento multidimensional e geográfico. Por sua vez, a Seção 6.4 apresenta um estudo
de caso que demonstra a aplicação prática das idéias discutidas nesta tese. Por fim, na Seção
6.5 são listadas algumas considerações finais sobre os assuntos discutidos neste capı́tulo.
6.2
IMPLEMENTAÇÃO DOS OPERADORES E FUNÇÕES
Esta seção discute detalhes sobre a implementação dos operadores e das funções, que foram
propostos nos Capı́tulos 4 e 5. Além disso, ela indica quais dos operadores (Seção 6.2.2) e das
funções (Seção 6.2.1) foram completamente ou parcialmente implementados.
6.2.1
Funções de Agregação de Medidas
Das funções de agregação de medidas propostas no Capı́tulo 5, a função Count está integrada
com a linguagem GeoMDQL e pode ser utilizada para especificação de cubos na arquitetura
Golapware. Outras funções foram implementadas (i.e. CountTouches, CountDisjoint, CountIntersects, CountAt North Of, CountAt South Of, MaxDisjoint, MaxIntersects, MaxAt North Of,
MinAt North Of, Rank Area, Rank Perimeter, Mode Area, Mode Perimeter, Median Area, Median Perimeter ), utilizando a linguagem PL/pgSQL do PostgreSQL [228] e as funções, NNearestNeighbor e NGeoGrouping, a nı́vel de aplicação, utilizando a linguagem de programação Java.
Entretanto, entendemos que uma análise mais aprofundada deve ser conduzida, no sentido criar
um mecanismo que torne as implementações independentes do SGBD e possibilite uma total
95
6.3 IMPLEMENTAÇÃO DA ARQUITETURA
96
integração das funções propostas com a arquitetura Golapware. O resultado da execução de
algumas destas funções foram apresentados na Seção 4.3 do Capı́tulo 4.
6.2.2
Operadores GeoMDQL
Dos operadores propostos no Capı́tulo 5, foram implementamos na arquitetura Golapware os
seguintes: i) Topológicos, descritos na Seção 5.3.1.1; ii) Cardinais, descritos na Seção 5.3.1.2;
iii) Métricos da Seção 5.3.1.3; e iv) Dos operadores que geram novas geometrias, apresentados
na Seção 5.3.1.4, implementamos na camada de aplicação, o operador Clipping. Entretanto, por
limitação de tempo, este operador ainda não foi totalmente integrado à sintaxe da linguagem
GeoMDQL.
Quanto aos operadores multidimensionais, listados na Seção 5.3.2, estão disponı́veis na sintaxe 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 Integração (i.e. operadores Members, Children e Siblings).
Dos operadores geográficos e multidimensionais propostos na Seção 5.3.3, estão disponı́veis
na sintaxe GeoMDQL os operadores LowDistance, TopDistance, RankArea, RankPerimeter,
RankLength, MaxArea, MinArea, MaxPerimeter, MinPerimeter, MaxLength, MinLength, AvgArea, AvgPerimeter, AvgLength, MedianArea, MedianPerimeter, MedianLength, ModeArea,
ModePerimeter e ModeLength. O Operador Drillout também foi implementado, porém, sem a
opção de união de geometrias. Além disso, o operador NGeoGrouping foi implementado para
objetos geográficos do tipo Ponto, utilizando o algoritmo de K-Means [7]. Porém, ele não
está totalmente integrado à interface da linguagem GeoDMQL. Percebemos que este operador
pode ser estendido, no sentido de permitir, por exemplo, a criação 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 também foi
implementado o operador NNNeighbors, para objetos geográficos do tipo Ponto, porém, não foi
totalmente integrado com a interface da linguagem GeoMDQL por limitações de tempo.
Alguns resultados de consultas na sintaxe GeoMDQL, envolvendo estes operadores são dados
na Seção 6.4.
6.3
IMPLEMENTAÇÃO DA ARQUITETURA
Esta seção discorre sobre os detalhes relacionados com a implementação da arquitetura Golapware (apresentada no Capı́tulo 5), na qual está inserida a linguagem GeoMDQL. A seguir, são
apresentados aspectos de implementação de cada uma das camadas da nossa arquitetura.
6.3.1
97
Camada I - Data Warehouse Geográfico
O Data Warehouse Geográfico da camada (I) foi implementado de acordo com as especificações
apresentadas no Capı́tulo 4 e em [283, 81]. Todos os esquemas de DWG discutidos na Seção
6.4, são baseados no modelo formal de DWG detalhado no Capı́tulo 4, que estende o arcabouço
GeoDWFrame [115] com a inclusão de medidas espaciais.
Para a modelagem, validação e geração dos scripts SQL para a criação dos esquemas dos
DWG implementados em nossa pesquisa, foi utilizada a ferramenta CASE GeoDWCASE [119].
Todas as modelagens dos exemplos práticos listados na Seção 6.4, foram realizadas com GeoDWCASE. Os principais pontos de GeoDWCASE são a utilização de estereótipos que facilitam
a modelagem, a validação do esquema realizada com OCL [203], e a geração automática dos
esquemas. Atualmente, os esquemas podem ser gerados para Oracle, PostgreSQL e MySQL,
obedecendo às restrições das extensões espaciais de cada um destes SGBD. Maiores detalhes
sobre a ferramenta GeoDWCASE, a especificação, a validação e a geração dos scripts SQL de
um DWG, podem ser analisados em [283, 81, 119].
Atualmente, é utilizado o SGBD PostgreSQL [228] com sua extensão para tratamento geográfico, o PostGis [154] por ser um SGBD aberto e extensı́vel. Mas qualquer outro SGBD com
extensão espacial pode ser adotado. Além disso, a extração 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 função na integração entre os processamentos geográfico e multidimensional. Na base de metadados, estão registradas informações
importantes sobre os dados geográficos e multidimensionais, tais como tipos de dados e endereço
do armazenamento. Outra funcionalidade importante é o armazenamento das definições sobre
os cubos de dados.
A especificação dos cubos de dados geográficos e multidimensionais segue as definições do
nosso modelo GeoMDCube [81], apresentado no Capı́tulo 4. Atualmente, a implementação
da fonte de metadados é baseada na tecnologia XML [294], dessa forma, os cubos de dados
geográficos e multidimensionais são 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 já utiliza XML para a manipulação de metadados. Além de servirem
para definir a estrutura do cubo de dados, as informações contidas no arquivo XML em questão
são usadas para gerar os scripts SQL que são utilizados para acessar as tabelas do DWG para
recuperar os dados geográficos e multidimensionais e gerar as devidas agregações 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,
98
com as extensões realizadas para se adequar à arquitetura Golapware. Este esquema guia a
especificação dos cubos e realiza a validação dos mesmos.
Figura 6.1 Esquema XML utilizado para validar os cubos geográficos e multidimensionais
Como podemos verificar na Figura 6.1, para o elemento Cube, foram adicionados dois atributos, chamados isGeoCube e geoCube, os quais são utilizados, respectivamente, para informar
se um cubo é geográfico e qual seu nome. De forma semelhante, para o elemento Dimension,
99
foram adicionados os elementos isGeoDimension e geoDimension, para indicar se a dimensão
do cubo é geográfica e qual é o nome da dimensão. Para o elemento Hierarchy, adicionamos
os elementos isGeoHierarchy (que indica se a hierarquia é geográfica ou não) e geoHierarchy
(que representa o nome da hierarquia geográfica). Por sua vez, o elemento Level também foi
estendido com os atributos isGeoLevel, geoLevel, geometryColumn e geoJoinColumn, os quais
são utilizados para, respectivamente: (i) indicar se um nı́vel é ou não geográfico, (ii) informar o
nome da tabela dimensão do DWG que contém os dados geográficos deste nı́vel, (iii) indicar qual
coluna da tabela dimensão é responsável por armazenar as geometrias dos membros geográficos
e (iv) representar a chave primária da tabela dimensão 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 não geográfico. Com as especificações implementadas neste esquema XML, é possı́vel
definir um esquema com um ou mais cubos de dados, e para cada cubo são definidas uma ou
mais dimensões. Cada dimensão 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 são responsáveis pela manipulação das instâncias deste esquema. Este módulo
possui grande interação com o mecanismo de processamento geográfico e multidimensional,
definido na camada (II) da arquitetura, que será detalhada na Seção 6.3.3. Na Figura 6.2, é
dado um exemplo de instância XML, que especifica um cubo de dados a partir do DWG do
estudo de caso DWG RECIFE, apresentado na Seção 6.4.3.
6.3.3
Camada II - Processamento Multidimensional e Geográfico
Na segunda camada (II) da nossa arquitetura está o mecanismo de processamento geográfico
e multidimensional, responsável por processar as consultas expressas de acordo com a sintaxe
GeoMDQL. A implementação desta camada foi realizada através da extensão do servidor OLAP
Mondrian [224] para prover suporte ao processamento de dados geográficos.
A escolha do servidor Mondrian para a criação do nosso servidor SOLAP se deve ao fato do
mesmo ser uma ferramenta de código aberto, independente de plataforma e compatı́vel com a
linguagem MDX, que serviu de base para a criação da linguagem GeoMDQL. Como o Mondrian
foi projetado para ser de código aberto, extensı́vel e independente de plataforma, a sua extensão
pôde ser realizada com maior facilidade. Além disso, a arquitetura deste servidor conta com
um módulo que permite a adição de funções definidas pelo usuário (i.e. UDF - User Defined
Functions). Dessa forma, foi possı́vel implementar funções externas e utilizar as mesmas nas
consultas GeoMDQL. No que se refere ao processamento espacial, estão utilizados os recursos
do PostGis [241], que é a extensão espacial do PostgreSQL [228]. A principal justificativa para
esta escolha, se deve a estas ferramentas serem de domı́nio público, e caso haja necessidade de
implementar alguma outra funcionalidade para processamento espacial, isso pode ser realizado
100
Figura 6.2 Exemplo de instância XML definindo um Cubo de Dados
alterando diretamente o PostgreSQL e o PostGIS, uma vez que ambos são abertos e extensı́veis.
No processador de consultas, um parser escrito em Java, implementa a gramática da linguagem GeoMDQL, apresentada no Capı́tulo 5. O parser realiza a análise léxica, traduzindo o
arquivo fonte que contém a gramática da linguagem em lexemas e tokens, o que permite que
os tokens sejam reconhecidos. Este parser também faz a análise sintática, que é responsável
por verificar quando uma sentença faz parte da gramática da linguagem. Após realizar o parsing, o processador realiza a validação sintática dos operadores da linguagem, confrontando, por
exemplo, tipo e quantidade dos parâmetros reais com os parâmetros formais. Em seguida, o
processador da consulta identifica qual é o tipo da requisição (i.e. GEO, MD, ou GEOMD de
integração ou mapeamento), os quais foram detalhados no Capı́tulo 5.
Após realizar o parsing e a classificação de uma requisição GeoMDQL, o mecanismo de
processamento faz uso do gerenciador de metadados para recuperar as informações necessárias
e finalizar o processamento e a execução da consulta. Com essas informações, são geradas instruções utilizadas pelo módulo de processador de consultas para recuperar os dados geográficos
e/ou multidimensionais solicitados na requisição. O acesso aos metadados é realizado através
de um módulo, também implementado em Java, que segue as definições do esquema XML da
Seção 6.3.2 e oferece um conjunto de classes para manipular as instâncias XML que armazenam
101
as informações sobre os cubos geográficos e multidimensionais.
Como a implementação do servidor Mondrian utiliza a tecnologia ROLAP (Relational
OLAP), as consultas GeoMDQL são transformadas em requisições SQL que, através de uma
conexão JDBC [189], são utilizadas para recuperar os dados armazenados em tabelas relacionais
no DWG. Dessa forma, ao analisarmos as implementações deste servidor, percebemos que sua
extensão poderia ser realizada, em linhas gerais, de duas formas: i) alterando sua estrutura
principal, responsável por gerar as instruções SQL para adicionar as restrições relacionadas aos
operadores geográficos ou ii) utilizar o recurso de UDF - User Defined Functions, que permite
que novas funções sejam desenvolvidas e incorporadas ao servidor, sem alterar o código fonte
original.
A primeira opção resultaria em um enorme esforço de implementação, além de modificar
consideravelmente, o código fonte original, o que poderia implicar, principalmente, na reescrita
de código para adequar a solução a uma nova versão do servidor Mondrian. Estas modificações
também implicariam em alterações no sistema de agregação e cache do Mondrian [224]. Dessa
forma, optamos por seguir a segunda opção, realizando o mı́nimo de alterações possı́veis no
código fonte do servidor, mantendo o novo código em pacotes separados e utilizando o recurso
de UDF do Mondrian como base para a extensão.
Assim, o repositório de metadados e o módulo de gerência de metadados, são os elementos
principais do nosso Servidor SOLAP e são 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 instruções SQL para recuperar os dados do DWG:
A instrução [Localizacao].[Municipio].[Recife] faz referência ao membro geográfico Recife,
do nı́vel Municipio, pertencente à dimensão Localizacao.
Estas informações estão todas
armazenadas no documento XML que define o cubo de dados, conforme pode ser observado na
especificação do cubo apresentado na Figura 6.2. Dessa forma, para recuperar este membro
geográfico e sua respectiva geometria, o processador de consultas gera uma instrução SQL
semelhante à apresentada na seqüência:
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 instruções GeoMDQL são mapeadas para SQL, que nosso mecanismo de
processamento geográfico e multidimensional (da camada (II) da arquitetura Golapware)
responde às consultas do tipo GEOMD de Mapeamento e às consultas do tipo GEO. Para
as consultas do tipo MD, foi mantido o processamento original do Mondrian, uma vez que
102
este tipo de consulta é especificada e processada da mesma forma que uma consulta MDX.
Por sua vez, as requisições do tipo GEOMD de Integração são processadas utilizando os
operadores GeoMDQL implementados, os quais foram listados na Seção 6.2.2. Atualmente, os
mapeamentos são realizados somente para o dialeto SQL espacial do SGBD PostgreSQL [228].
A implementação dos componentes para otimização, gerenciamento de cache e gerenciamento de agregação não foi realizada, mas sua especificação visa prover um mecanismo de
cache e reescrita de consultas para melhorar o desempenho dos processamentos.
6.3.4
Camada III - Interface
Na terceira camada (III) da nossa arquitetura, temos os componentes para realizar a interface
com o usuário para a especificação das consultas e visualização dos resultados. Para esta
camada, seguimos duas abordagens de implementação. A primeira, é voltada para a Web,
seguindo as tendências atuais, permitindo aos usuários, acessarem o ambiente de processamento
multidimensional e geográfico via Internet. Para esta abordagem, o cliente OLAP JPivot [239]
foi estendido para possibilitar a especificação de consultas geográficas e/ou multidimensionais
na sintaxe GeoMDQL e posterior submissão destas requisições ao mecanismo de consulta da
camada (II). Após receber a resposta da consulta, o módulo de visualização de consultas exibe
os dados graficamente, em tabelas multidimensionais, gráficos e mapas. Para a implementação,
foram utilizadas as tecnologias JSP (Java Server Pages) [191], SVG (Scalable Vector Graphics)
[291] e a tradicional HTML (HyperText Markup Language) [290]. Um exemplo desta interface
gráfica já foi apresentado anteriormente, na Seção 3.8 do Capı́tulo 3.
Na segunda abordagem, estendemos a interface proposta em [264], para criar uma aplicação
cliente desktop para a nossa arquitetura SOLAP. Esta aplicação cliente é baseada na extensão
e integração das tecnologias Java Plugin Framework (JPF) [159], OpenJUMP [207] e JRubik
[160]. Esta segunda abordagem também exibe o resultado das consultas utilizando gráficos, mapas e tabelas, entretanto, ela possui uma série de funcionalidades adicionais, como por exemplo,
formatação dos resultados, exportação de dados para outros formatos e trabalho paralelo com
múltiplas janelas, que em uma implementação para a Web apresentaria baixa performance e
demandaria um alto custo de implementação. Nesta camada de interface, uma funcionalidade
que está sendo implementada para o módulo editor de consultas, permitirá ao usuários, especificar as consultas na sintaxe GeoMDQL através de cliques de mouse sobre as tabelas, gráficos
e mapas e interagir com uma representação visual da estrutura do cubo de dados geográficos,
sobre o qual será executada a consulta. A especificação e implementação desta versão visual
de GeoMDQL consiste em um trabalho de mestrado que está em andamento no Centro de
Informática da UFPE [264].
A Figura 6.3 exibe os principais componentes da nossa interface gráfica. Como a implementação é baseada na tecnologia JPF, cada conjunto de funcionalidades é disponibilizado
103
Figura 6.3 Interface Gráfica da Arquitetura Golapware
através de um plugin. A seguir, uma breve descrição dos principais componentes é dada:
Na Figura 6.3-(A), é exibida a área na qual as consultas GeoMDQL são especificadas
atualmente com as opções para salvar e abrir consultas previamente especificadas.
A Figura 6.3-(B) exibe as tabelas multidimensionais resultantes da consulta, sendo este
plugin parte do JRubik [160].
Os mapas (ver Figura 6.3-(C)) são exibidos com o auxı́lio do plugin do OpenJump [207];
Gráficos podem ser construı́dos utilizando os recursos de outro plugin, o qual é apresentado
na Figura 6.3-(D);
Na Figura 6.3-(E), consultas, previamente armazenadas para cada DWG, podem ser
selecionadas através de cliques de mouse.
Também utilizando o mouse, o usuário pode explorar as dimensões, fatos, hierarquias,
nı́veis e membros do cubo que está sendo utilizado, através da funcionalidade exibida na
Figura 6.3-(F);
6.4 APLICAÇÃO PRÁTICA DA ABORDAGEM
104
Por fim, para navegar entre os cubos de outros catálogos registrados na interface, o usuário
pode utilizar o componente exibido na Figura 6.3-(G). Este componente também permite
que o usuário construa a estrutura inicial das consultas, através de cliques do mouse.
Vale salientar que, cada um dos componentes exibidos acima, não possui local fixo dentro
da interface. O usuário é o responsável por organizar os componentes, de acordo com as funcionalidades utilizadas em cada consulta. Ele pode assim, livremente, exibir, ocultar, reorganizar
e redimensionar os componentes da interface. Os gráficos, tabelas e mapas manipulados na
interface, podem ser exportados para outros formatos, como HTML, XML, PDF, XLS e JPG.
6.4
APLICAÇÃO PRÁTICA DA ABORDAGEM
A metodologia utilizada no desenvolvimento deste estudo de caso consiste na descrição dos
dados, modelagem do DWG, especificação do cubo de dados e execução de consultas GeoMDQL.
Para demonstrar na prática as idéias propostas em nossa pesquisa, nesta seção apresentaremos
um estudo que utiliza quatro diferentes bases de dados, todas com dados de aplicações reais. O
objetivo de apresentarmos quatro DWG em nosso estudo de caso é demonstrar a aplicação de
nossas pesquisas em diferentes situações e tipos de dados, comprovando o potencial de análise
geográfico e multidimensional disponı́vel na linguagem GeoMDQL. Assim, cada DWG listado
neste capı́tulo possui particularidades e diferem-se uns dos outros tanto na modelagem quanto
no tipo de dados armazenados. As definições dos nossos DWG e suas principais particularidades
são dadas a seguir:
DWG DATASUS: Data Warehouse Geográfico com dados do IBGE e do Datasus. Não possui
medidas geográficas. Foi modelado com dimensões geográficas com dados sobre zonas
climáticas e limites de municı́pios, estados, micro-regiões, meso-regiões e regiões de todo
o Brasil. Todas as feições geográficas utilizadas são do tipo polı́gono. Este DWG tem o
maior número de medidas, todas relacionadas com saúde pública;
DWG LAMEPE: Data Warehouse Geográfico com dados do Laboratório de Meteorologia
de Pernambuco (LAMEPE). O principal diferencial deste estudo de caso, em relação ao
anterior, está na utilização de mais de um tipo de geometria para as feições geográficas
das dimensões geográficas;
DWG RECIFE: Data Warehouse Geográfico com dados da Secretaria Estadual de Saúde do
estado de Pernambuco. Para nosso estudo de caso, restringimos o contexto dos dados
para o municı́pio de Recife. Neste DWG, são registrados os casos de dengue ocorridos em
cada um dos bairros de Recife. O diferencial principal deste DWG, em relação aos dois
anteriores, está na utilização de uma medida geográfica do tipo ponto, para representar
o local do foco de dengue;
105
DWG RPA1: Data Warehouse Geográfico com dados sobre os registros de lotes urbanos na
Região Polı́tico Administrativa 1 (RPA1), pertencente ao municı́pio de Recife. Este DWG
assemelha-se ao anterior, contendo uma medida geográfica, porém, esta medida é do tipo
polı́gono.
Na seqüência, cada um dos casos práticos listados acima é apresentado com maiores detalhes.
Cada uma das subseções seguintes é composta por: i) uma breve descrição sobre o DWG; ii)
a modelagem do DWG utilizando nossa ferramenta GeoDWCase [119], seguindo as definições
formais do nosso modelo de DWG [283], detalhado no Capı́tulo 4 e iii) a descrição dos cubos de
dados especificados a partir de cada DWG, seguindo nosso modelo GeoMDCube [81], também
discutido no Capı́tulo 4. Finalmente, alguns exemplos de consulta, todos de acordo com a
sintaxe da linguagem GeoMDQL[84], são dados para cada DWG, com seus resultados exibidos
utilizando a interface SOLAP da arquitetura Golapware.
6.4.1
DWG DATASUS
Este DWG está inserido no contexto da saúde pública. Trata-se de um Data Warehouse Geográfico com dados sobre o Sistema Único de Saúde (SUS - www.datasus.gov.br) brasileiro [83].
Os dados geográficos foram adquiridos do Instituto Brasileiro de Geografia e Estatı́stica (IBGE
- www.ibge.gov.br). Estes dados contemplam a geometria do paı́s, das regiões brasileiras, dos
estados, das meso-regiões, das micro-regiões, dos municı́pios e das áreas climáticas brasileiras.
Os dados analı́ticos utilizados para a construção do DWG, extraı́dos do site do Ministério
da Saúde, produzem informações sobre a saúde da mulher, o controle de doenças e a saúde
bucal, as taxas de mortalidade infantil, os óbitos neo natais, a taxa de mortalidade materna,
o percentual de nascidos abaixo do peso, entre outros. Estes dados foram extraı́dos do site do
DataSus
Conseqüentemente, este GDW pode ajudar autoridades nos processos de planejamento,
administração e avaliação de polı́ticas públicas de saúde, bem como pode ser um meio eficiente
de elaborar metas para melhorar os serviços de saúde pública disponı́veis para a população
brasileira, uma vez que permite a análise tanto analı́tica como geográfica com a visualização
dos dados por meio de tabelas, gráficos e mapas. O esquema deste DWG é apresentado na Figura
6.4. Como pode ser observado, utilizamos a ferramenta GeoDWCASE [119] para realizar a sua
modelagem . Obviamente, este esquema segue as definições do modelo de DWG, discutido no
Capı́tulo 4.
Como sabemos, a partir de um esquema de DW ou DWG, podemos criar inúmeros cubos
de dados. Para este estudo de caso, com base no esquema apresentado na Figura 6.4, definimos
um cubo de dados chamado BrSaude, que possui os fatos Populacao, Obitos Menores de Um
Ano, Nascidos Vivos, Nascidos Vivos Abaixo do Peso, Obitos Neonatais, Obitos Maternos e
Atendidos PSF. Estes fatos representam as medições dos valores armazenados na tabela de fatos
106
Figura 6.4 DWG para Saúde Pública
do DWG, levando em consideração os nı́veis das dimensões do cubo. Vale salientar que todos os
fatos deste cubo são convencionais e são obtidos através da função de agregação soma. O cubo
BRSaude possui uma dimensão convencional Tempo, a qual é formada por uma hierarquia que
contém um nı́vel chamado Ano. No cubo criado, a dimensão Clima também está presente e é
composta por uma hierarquia que contém o nı́vel Zona. Esta dimensão representa as diferentes
zonas climáticas existentes no DWG. A dimensão geográfica Localizacao é composta por uma
hierarquia formada pelos nı́veis Pais, Estado, Meso Regiao, Micro Regiao e Municipio.
CONSULTA 1 (Mostrar a quantidade de Óbitos Maternos, de Óbitos Menores de
Um Ano e de Óbitos Neonatais dos estados brasileiros com População superior a
3 milhões de habitantes).
SELECT [Measures].[Obitos Maternos], [Measures].[Obitos Menores de Um Ano],
[Measures].[Obitos Neonatais] ON COLUMNS,
Filter([Localizacao].[Estado].Members, ([Measures].[Populacao] > 3000000))ON ROWS
107
Figura 6.5 Consulta GeoMDQL de Mapeamento Utilizando o Operador Filter
FROM [BRSaude] WHERE [Tempo].[Todos].[2002] ON MAP
Um exemplo de requisição de mapeamento que pode ser especificada sobre o cubo BRSaude
é a apresentada na Consulta 1. Nesta consulta, utilizamos o operador Filter que é aplicado sobre
um conjunto de fatos, filtrando os mesmos de acordo com uma expressão lógica definida pelo
usuário. No caso deste exemplo, serão recuperados somente os fatos associados aos membros
do nı́vel Estado no qual a quantidade de habitantes for superior a 3 milhões. Como pode
ser observado na Figura 6.5, são adicionados gráficos sobre o mapa, para representar os fatos
requisitados na consulta (i.e. óbitos maternos, óbitos menores de um ano e óbitos neonatais).
Como pode ser observado no mapa da Figura 6.5, após obter o resultado retornado, o usuário
pode interagir com o mapa, mudando cores, adicionando legendas e até mesmo utilizando estes
resultados para realizar novas consultas. No caso desta consulta, foram adicionados ao mapa,
gráficos do tipo pizza, para representar de forma gráfica os valores dos três fatos envolvidos (i.e.
Obitos Maternos, Obitos Neonatais e Obitos Menores de Um Ano).
CONSULTA 2 (Para cada estado das Regiões Sul, Centro Oeste e Nordeste,
mostrar a população no ano de 2002, juntamente com a posição de cada estado no
ranking geral da população (que considera os 27 estados brasileiros), e também
a posição de cada estado no ranking que mede a área geográfica de cada estado.
108
Mostrar também o ranking de todos os estados, considerando sua distância até o
Distrito Federal. Os dados com correspondência geográfica devem ser exibidos no
mapa ).
WITH SET [Estados Ordenados Por Area]
AS ‘RankArea([Localizacao].[Estado].Members)’
MEMBER [Measures].[Ranking Area]
AS ‘Rank([Localizacao].CurrentMember, [Estados Ordenados Por Area])’
SET [Estados Ordenados Por Populacao]
AS ‘Order([Localizacao].[Estado].Members, [Measures].[Populacao], BDESC)’
MEMBER [Measures].[Ranking Populacao]
AS ‘Rank([Localizacao].CurrentMember, [Estados Ordenados Por Populacao])’
SET [Distancia do DF]
AS ‘LowDistance([Localizacao].[Todos].[Brasil].[Centro Oeste].[DISTRITO FEDERAL],
[Localizacao].[Estado].Members)’
MEMBER [Measures].[Ranking Distancia]
AS ‘Rank([Localizacao].CurrentMember, [Distancia do DF])’
SELECT [Measures].[Populacao], [Measures].[Ranking Area],
[Measures].[Ranking Populacao],
[Measures].[Ranking Distancia] ON COLUMNS,
[Localizacao].[Todos].[Brasil].[Nordeste].Children,
[Localizacao].[Todos].[Brasil].[Centro Oeste].Children,
[Localizacao].[Todos].[Brasil].[Sul].Children ON ROWS
FROM [BRSaude] where [Tempo].[Todos].[2002] ON MAP
Para resolver a Consulta 2, aplicamos o operador GeoMDQL RankArea para ordenar todos
os membros do nı́vel Estado, criando um conjunto com todos os Estados ordenados da maior
área para a menor (i.e. [Estados Ordenados Por Area] ), e com o uso do operador SET. Em
seguida, é utilizado o operador Rank para gerar para cada estado, a posição no ranking geral
e criar um novo membro com o operador MEMBER. De forma semelhante, usamos o operador
Order para criar um conjunto de todos os membros do nı́vel estado ordenados pela quantidade
da população. A instrução BDESC, utilizada em conjunto com o operador Order indica que a
ordenação deve ocorrer em ordem crescente e que a hierarquia original do cubo não é considerada. Assim, a partir do uso do operador MEMBER é criado um novo membro que armazena
a posição de cada estado no ranking global de população. O operador LowDistance foi usado
para criar um ranking considerando a distância de cada estado até o Distrito Federal, criando
um novo membro chamado [Measures].[Ranking Distancia]. Os fatos que representam a população de cada estado (i.e. [Measures].[Populacao] ), a posição de cada estado no ranking da
109
Figura 6.6 Ranking de Área, de População e de Distância
área (i.e. [Measures].[Ranking Area] ), a posição de cada estado no ranking da população (i.e.
[Measures].[Ranking Populacao] ) e a posição de cada estado no ranking que mede a distância
até o Distrito Federal (i.e. [Measures].[Ranking Distancia] ) são adicionados ao eixo coluna (ON
COLUMNS). Por sua vez, cada estado das regiões solicitadas (i.e. Sul, Centro Oeste e Nordeste)
são adicionados ao eixo linha (ON ROWS). Para listar os estados de cada região, foi utilizado
o operador Children, que recupera todos os filhos de um determinado membro. Por fim, para
restringir o resultado para os dados do ano 2002 é utilizada a instrução [Tempo].[Todos].[2002]
na cláusula WHERE. A instrução ON MAP indica ao processador que os dados geográficos
precisam ser retornados, os quais serão exibidos em um mapa.
Como pode ser visualizado no resultado da consulta exibido na Figura 6.6, além da população, do ranking de área e do ranking de população, é possı́vel perceber o ranking criado a
partir das medições das distâncias de cada estado até o Distrito Federal.
110
Figura 6.7 Drillout no Estado de Pernambuco
CONSULTA 3 (Mostrar a quantidade de nascidos vivos e a quantidade de óbitos
maternos do ano de 2002, para todos os estados vizinhos de Pernambuco ).
SELECT [Measures].[Nascidos Vivos], [Measures].[Obitos Maternos] ON COLUMNS,
Drillout([Localizacao].[Todos].[Brasil].[Nordeste].[PERNAMBUCO]) ON ROWS
FROM [BRSaude] WHERE [Tempo].[Ano].[2002] ON MAP
A Consulta 3 é outro exemplo de consulta de integração. Nesta consulta, é usado o operador
Drillout da linguagem GeoMDQL para recuperar todos os estados vizinhos de Pernambuco.
Para cada estado, é recuperado também os fatos correspondentes ao número de nascidos vivos
(i.e. [Measures].[Nascidos Vivos]) e óbitos maternos (i.e. [Measures].[Obitos Maternos]). Na
Figura 6.7, é exibido o resultado desta consulta. Como pode ser observado no mapa desta
figura, com as funcionalidades disponibilizadas pela interface gráfica, foram adicionados gráficos
do tipo coluna, sobre cada estado exibido no mapa, representando de forma gráfica os valores
dos nascidos vivos e dos óbitos maternos.
Na Figura 6.8, é apresentado o resultado da interação do usuário com a interface gráfica,
utilizando a resposta da Consulta 3 para especificar outra consulta. Neste exemplo, o usuário
aplica o operador Drilldown uma vez sobre o membro BAHIA, navegando até o nı́vel Meso
111
Região e duas vezes sobre os membros ALAGOAS e PARAÍBA, navegando até o nı́vel Micro
Regiao da dimensão Localizacao.
Figura 6.8 DrillDown no Resultado Exibido na (Figura 6.7)
6.4.2
DWG LAMEPE
Outro DWG especificado para este estudo de caso foi construı́do a partir dos dados do LAMEPE
(Laboratório de Meteorologia de Pernambuco). O LAMEPE é um laboratório vinculado ao
ITEP (Instituto de Tecnologia de Pernambuco) e tem como objetivo o monitoramento de
condições atmosféricas. O Laboratório conta com uma rede de PCD (Plataformas de Coleta
de Dados) meteorológicos e está permanentemente conectado à rede internacional de difusão
de imagens de satélites e a produtos de modelagem atmosférica. As atividades relacionadas ao
monitoramento de condições atmosféricas envolvem: i) monitoramento das condições do tempo
e do clima no estado; ii) desenvolvimento de estudos que objetivem melhorar o acerto das previsões e difundir o uso das informações meteorológicas para seu melhor aproveitamento pela
sociedade; iii) desenvolvimento de programas articulados de investigação cientı́fica, buscando
ampliar o conhecimento sobre a climatologia de Pernambuco, especialmente voltados às atividades agrı́colas e às pecuárias; iv) instalação, operação e manutenção de rede pluviométrica e
telemétrica, em todas as regiões do estado, destinadas à medição, em tempo real, de variáveis
112
Figura 6.9 DWG para Meteorologia
meteorológicas (precipitação pluviométrica, temperatura, umidade e outras); e v) distribuição
das informações climatológicas geradas, no próprio LAMEPE, sobre eventuais ocorrências de
estiagens, chuvas intensas e outros fenômenos de interesse à Defesa Civil e às autoridades de
planejamento.
Na Figura 6.9 é mostrado o esquema do DWG criado, com o auxı́lio da ferramenta GeoDWCASE. A partir deste DWG, especificamos um cubo de dados chamado CMeteorologiaPE
que possui um fato chamado Precipitacao, o qual foi obtido através da aplicação da função de
agregação soma. A dimensão convencional Tempo, com uma hierarquia formada pelos nı́veis
Ano, Mes e Dia, também faz parte deste cubo. Com relação à dimensão geográfica, o cubo
CMeteorologiaPE conta com: i) a dimensão BaciaHidrografica, composta por uma hierarquia
que contém um nı́vel chamado Bacia, representando as bacias hidrográficas do estado de Pernambuco; ii) a dimensão Localizacao, composta por uma hierarquia formada pelos nı́veis Estado,
Meso Região, Micro Região e Municı́pio e iii) a dimensão Estacao, que contém uma hierarquia
formada pelo nı́vel PCD, representando as plataformas de coleta de dados distribuı́das pelo
113
estado de Pernambuco.
Na Consulta 4, apresentamos um exemplo de consulta de mapeamento que pode ser especificada sobre o cubo especificado anteriormente. Nesta requisição, efetuamos a análise de Pareto
[261], e aplicamos o operador Rank para mostrar as plataformas de coleta de dados de acordo
com o valor da precipitação. O resultado da execução desta consulta pode ser visualizado na
Figura 6.10.
CONSULTA 4 (Mostar as Bacias Hidrográficas onde se concentraram 60% das
precipitações pluviométricas do ano de 2005, e para cada uma dessas bacias,
mostrar quais foram as estações de coleta de dados que juntas foram responsáveis
por coletar 50% das precipitações. Além disso, mostrar qual a posição de cada
uma das estações no ranking global que mede a precipitação).
WITH SET [PCD Ordenadas]
AS ‘Order([Estacao].[PCD].Members, [Measures].[Precipitacao], BDESC)’
MEMBER [Measures].[Ranking Precipitacao]
AS ‘Rank([Estacao].CurrentMember, [PCD Ordenadas])’
SELECT [Measures].[Precipitacao], [Measures].[Ranking Precipitacao] ON COLUMNS,
Generate(TopPercent([BaciaHidrografica].[Bacia].Members, 60.0,[Measures].[Precipitacao]),
Crossjoin([BaciaHidrografica].[Bacia].CurrentMember, [Estacao].[Todos],
TopPercent([Estacao].[PCD].Members, 50.0, [Measures].[Precipitacao]))) ON ROWS
FROM [CMeteorologiaPE]
WHERE [Tempo].[Ano].[2005] ON MAP
Na Consulta 5, temos um exemplo de requisição que integra operadores geográficos e multidimensionais e é especificada sobre o cubo CMeteorologiaPE. Como pode ser observado, para
resolver a consulta, foram utilizados os operadores MaxArea, para retornar a meso região com
maior área geográfica e o operador MinArea para retornar a meso região pernambucana de
menor área geográfica. O operador DrilldownMember foi usado para descer um nı́vel na hierarquia geográfica, recuperando assim, todas as micro regiões pertencentes às duas meso regiões
recuperadas pelos operadores MaxArea e MinArea. O resultado da execução desta consulta
pode ser visualizado na Figura 6.11.
CONSULTA 5 (Mostrar o valor total das precipitações, registradas no ano de
2005, para todas as micro regiões localizadas dentro das meso regiões de maior e
menor área geográfica).
SELECT NON EMPTY [Measures].[Precipitacao] ON COLUMNS,
NON EMPTY DrilldownMember(
114
Figura 6.10 Exemplo de Consulta de Mapeamento com Ranking
MinArea([Localizacao].[Meso Regiao].Members),
MaxArea([Localizacao].[Meso Regiao].Members),
[Localizacao].[Meso Regiao].Members) ON ROWS
FROM [CMeteorologiaPE]
WHERE [Tempo].[Todos].[2005] ON MAP
6.4.3
DWG RECIFE
Nesta seção, apresentamos o Data Warehouse Geográfico para Registro de Casos de Dengue na
cidade de Recife. Os dados contidos neste DWG foram disponibilizados pela Secretaria Estadual
de Saúde do estado de Pernambuco. O principal diferencial deste estudo de caso em relação aos
dois anteriores está na utilização de medidas geográficas. Como podemos perceber na Figura
6.12, que exibe a modelagem deste DWG, a medida geográfica m local caso é uma geometria
do tipo Ponto e representa o endereço pontual de um caso de dengue registrado pelas equipes
da Secretaria Estadual de Saúde.
Da maneira com que foi estruturado, este DWG pode ser de grande utilidade para as equipes
de epidemiologia do estado de Pernambuco para a análise dos dados relacionados com a dengue,
115
Figura 6.11 Exemplo de Consulta de Integração com DrilldownMember, MaxArea e MinArea
e utilização dos mesmos para o combate ao mosquito transmissor da doença. Para minimização
do escopo, utilizamos somente as divisões polı́tico administrativas e a localização do foco.
Com base no DWG exibido na Figura 6.12, especificamos um cubo de dados chamado
CDengue. Neste cubo, definimos um fato chamado TotalCasos, o qual é gerado através da
aplicação da função de agregação Count. A dimensão convencional Tempo, com uma hierarquia formada pelos nı́veis Ano, Mes e Dia também faz parte deste cubo. Como dimensão
geográfica, temos a dimensão Localizacao, que é formada por uma hierarquia composta pelos
nı́veis Municipio, Rpa (Região polı́tico e Administrativa), Micro Regiao e Bairro.
CONSULTA 6 (Considerando todos os casos de dengue registrados no ano de
2007, gerar 20 agrupamentos a partir do endereço pontual de cada caso ).
SELECT GeoGrouping([Localizacao].[Bairro].Members, 20 , [Measures].[LocalCaso])
FROM [CDengue]
A Consulta 6 visa recuperar dados armazenados no cubo CDengue. Nesta consulta, foi
utilizado o operador GeoGrouping da linguagem GeoMDQL para gerar os vinte agrupamentos a
partir dos endereços de casos de dengue registrados no ano de 2007. Como pode ser observado
116
Figura 6.12 DWG Dengue
no resultado da consulta, mostrado na Figura 6.13, cada agrupamento foi adicionado como uma
nova camada sobre o mapa de bairros.
Outro exemplo de consulta puramente geográfica, utilizando um operador da linguagem
GeoMDQL é a Consulta 7 que também recupera dados do cubo CDengue. Para esta consulta, foi escolhido o operador NNNeighbors, que recupera os N vizinhos mais próximos de um
determinado ponto.
CONSULTA 7 (Dentre os os casos de dengue registrados no ano de 2007, nos
bairro do municı́pio de Recife, identificar os 150 endereços de casos de dengue
mais próximos do ponto de latitude 287747 e longitude 9107940 ).
SELECT
NNNeighbors([Localizacao].[Bairro].Members,
POINT(287747 9107940))
FROM [CDengue]
150
,
[Measures].[LocalCaso]
,
117
Figura 6.13 Exemplo de Consulta Geográfica Baseada no Operador Geogrouping de GeoMDQL
A Consulta 7, usa o operador NNNeighbors para recuperar os 150 casos de dengue mais
próximos de um determinado ponto. O resultado desta consulta pode ser visualizado na Figura
6.14. Esta figura mostra o ponto de referência destacado no mapa, pois ele foi adicionado ao
resultado como uma nova camada de dados, para facilitar a análise. Também podemos perceber
na Figura 6.14 uma camada contendo os 150 pontos mais próximos e a camada que representa
o mapa de bairros.
6.4.4
DWG RPA1
Esta seção apresenta o DWG com dados do registro de lotes urbanos da cidade do Recife.
Neste estudo prático, especificamos um DWG para armazenar dados sobre os lotes urbanos
da Região Polı́tico e Administrativa 1 (RPA1), pertencente ao municı́pio de Recife. Neste
DWG também contamos com uma medida geográfica, a qual representa a geometria do lote
registrado. Adicionalmente, temos uma medida numérica que representa o valor do lote em reais.
Salientamos que, por questões éticas, o valor de cada lote foi simulado. De forma semelhante, os
118
Figura 6.14 Exemplo de Consulta Geográfica Baseada no Operador NNNeighbors de GeoMDQL
dados relacionados com o tipo de proprietário e o tipo do imóvel foram gerados aleatoriamente.
Porém, os dados que mais nos interessam para este estudo de caso, que estão relacionados com
as medidas geográficas e representam as geometrias dos lotes, são dados reais. A modelagem
deste DWG pode ser visualizada na Figura 6.15.
Com base no esquema de DWG exibido na Figura 6.15, especificamos um cubo de dados
nomeado CRpa1, que contém três fatos: i) TotalLotes, que é gerado a partir da aplicação
da função de agregação Count sobre a medida geográfica m area lote; ii) ValorVenal, gerado
através da aplicação da função de agregação Soma sobre a medida numérica m valor venal e
iii) MediaValorVenal que é gerado a partir da aplicação da função de agregação Média sobre a
medida numérica que corresponde ao valor venal dos lotes.
Quanto às dimensões que compõem o cubo, temos: i) a dimensão convencional Tempo,
contendo uma hierarquia formada pelos nı́veis Ano, Mes e Dia e ii) a dimensão geográfica
Localizacao, com uma hierarquia formada pelos nı́veis RPA, Micro Regiao e Bairro.
CONSULTA 8 (Criar um recorte de todos os lotes registrados, a partir da área
definida pelo polı́gono com a seguinte geometria :
POLYGON ((
119
Figura 6.15 DWG registro de lotes urbanos
291081.866184352 9108140.22335636, 291765.4136060198 9109747.483510012,
293289.5396137925 9107382.778916134, 291081.866184352 9108140.22335636 )) ).
SELECT Clipping([Measures].[AreaLote] ,
POLYGON((291081.866184352 9108140.22335636
291765.4136060198 9109747.483510012
293289.5396137925 9107382.778916134
291081.866184352 9108140.22335636)))
FROM [CDengue]
Por fim, na Figura 6.16 é exibido o resultado de uma operação de Clipping sobre as medidas
geográficas do DWG criado para esta aplicação prática. Este resultado foi obtido através da
utilização do operador Clipping, conforme [e mostrado na Consulta 8. Outros exemplos de
consultas, especificadas na sintaxe da linguagem GeoMDQL, juntamente com seus resultados,
120
são apresentados no apêndice C.
Figura 6.16 Exemplo de Consulta Geográfica Baseada no operador Clipping
6.5
CONSIDERAÇÕES
Como pode ser observado neste capı́tulo, grande parte das idéias propostas, nos Capı́tulos
4 e 5, foram implementadas levando em consideração tecnologias abertas e extensı́veis. Isto
contribui para o desenvolvimento de ambientes SOLAP para suporte à decisão, com baixo
custo e compatı́vel com os padrões bem estabelecidos no mercado. Além disso, para demonstrar
a aplicação prática da solução proposta, discutimos exemplos de situações do mundo real, para
demonstrar o potencial de análise oferecido por um ambiente SOLAP.
Também ficou evidente que a área de integração entre processamento geográfico e multidimensional ainda possui alguns pontos que merecem uma investigação mais aprofundada. Assim,
no próximo capı́tulo, além de explicitar as nossas principais contribuições obtidas com o trabalho discutido nesta tese e para esta área de pesquisa, apresentaremos uma lista de pontos que
podem servir de base para futuras investigações.
CAPÍTULO 7
CONCLUSÕES E TRABALHOS FUTUROS
7.1
CONSIDERAÇÕES FINAIS
Nesta tese, apresentamos algumas contribuições para a área SOLAP, incluindo a especificação
de um modelo formal para Data Warehouse Geográfico, a definição de um conjunto de funções
de agregação para medidas geográficas, a especificação de um modelo para cubo de dados,
chamado GeoMDCube [81] e uma linguagem de consulta geográfica e multidimensional denominada GeoMDQL [84, 80].
O modelo formal de DWG [283], discutido no Capı́tulo 4, estende o arcabouço GeoDWFrame
[115] para prover suporte ao uso de medidas espaciais. Dessa forma, um esquema de DWG pode
ser especificado para conter tabelas de fatos com medidas numéricas e geográficas, e as tabelas
dimensões também armazenam dados geográficos. Isto permite que um cubo de dados seja
especificado para conter tanto fatos geográficos quanto dimensões geográficas, o que incrementa
as possibilidades de representação e análise dos dados.
O conjunto de funções de agregação apresentado no Capı́tulo 4 e em [78], teve origem na
combinação de funções já definidas e consolidadas para as áreas de SIG (i.e. Unária Booleana,
Unária Escalar, Unária Espacial, Binária Booleana, Binária Escalar, Binária Espacial e Nária Espacial [246]) e OLAP (i.e. Distributiva, Algébrica e Holı́stica [135] ). Estas funções
foram classificadas em seis grupos, gerando uma nova taxonomia de funções de agregação de
medidas geográficas. Dessa forma, as novas funções possibilitam uma grande variedade de tipos
de agregação e análise de dados. As funções de agregação são utilizadas durante o processo
de especificação dos cubos de dados multidimensionais e geográficos, para a definição dos fatos
do cubo. Com este conjunto de funções, acreditamos ter contribuı́do para a área de DWG e
SOLAP, uma vez que o assunto relacionado à agregação de medidas geográficas não é consenso
na literatura. Até então, não tı́nhamos conhecimento sobre a existência de um conjunto de
funções, com inúmeras possibilidades de agregação, disponı́veis aos projetistas de DWG, como
existe na área OLAP com as funções distributivas, algébricas e holı́sticas [135].
Para guiar a definição dos cubos de dados, no Capı́tulo 4 também apresentamos o modelo
GeoMDCube [81], o qual estende o modelo de cubo multidimensional tradicional com a inclusão de geometrias associadas aos fatos e aos membros dos nı́veis do cubo. As formalizações
matemáticas dadas no Capı́tulo 4 explicitam, de forma consistente e não ambı́gua, os relacionamentos existentes entre os elementos de um DWG e de um cubo de dados, incluindo o processo
121
7.1 CONSIDERAÇÕES FINAIS
122
de agregação de medidas para geração dos fatos de um cubo multidimensional e geográfico.
No que se refere à discussão sobre qual é a melhor abordagem para modelagem de DWG
[179], incluindo a utilização de medidas geográficas ou dimensões geográficas, concluı́mos que o
ideal é dispor de um modelo que contemple as duas abordagens. Deixar a cargo do projetista
do DWG, a opção para definir, de acordo com suas necessidades de análise, qual estratégia será
adotada, é o ideal. Entretanto, acreditamos que quando um DWG é modelado com medidas
geográficas na tabela de fatos, é essencial que exista no mı́nimo, uma dimensão geográfica para
servir de contextualização para as medidas geográficas.
A linguagem de consulta geográfica e multidimensional GeoMDQL (Geographic and Multidimensional Query Language) [84], proposta no Capı́tulo 5, está baseada em padrões amplamente
difundidos como MDX [297] OCG [45] e SQL Espacial [269] e, até o presente momento, é um das
poucas linguagens de consulta para ambientes SOLAP que oferece uma sintaxe única, que integra
operadores espaciais e multidimensionais. A definição dos operadores SOLAP para a linguagem
GeoMDQL segue a mesma metodologia utilizada para a proposição das funções de agregação
de medidas geográficas, ou seja, estão baseados na extensão e combinação de operações já consolidados nas áreas de SIG [246] e OLAP [135]. Conforme pode ser observado no Capı́tulo
2, inúmeras são as propostas de linguagem de consulta e operadores multidimensionais e geográficos, entretanto, nenhuma das abordagens oferece o potencial de análise disponibilizado
por GeoMDQL e seus operadores. Esta afirmação é reforçada com a comparação realizada,
ao final do Capı́tulo 5, da sintaxe da nossa linguagem com alguns dos trabalhos discutidos no
Capı́tulo 3.
O principal diferencial do nosso trabalho em relação a outros trabalhos correlatos, além da
caracterı́stica inovadora, é o fato de nos basearmos em padrões bem estabelecidos atualmente,
sendo eles abertos e extensı́veis, conforme indicado pelos detalhes de implementação discutidos no Capı́tulo 6. Isto facilita a evolução e reutilização das idéias. Com a implementação
da arquitetura Golapware (ver Capı́tulo 6), que dispõe de um servidor SOLAP baseado na
extensão do servidor OLAP Mondrian [224], foi possı́vel desenvolver um estudo de caso com
dados de aplicações reais, aplicando na prática algumas das idéias discutidas nesta tese, principalmente no que se refere à especificação de esquemas de DWG, cubos de dados e realização de
consultas envolvendo os operadores geográficos e multidimensionais definidos para a linguagem
GeoDMQL.
Apesar do nosso trabalho ter sido desenvolvido no contexto da arquitetura GOLAPA, a qual
foi discutida no Capı́tulo 3, parte das idéias propostas são independentes desta arquitetura,
podendo assim ser aplicadas a outros trabalhos que objetivam o desenvolvimento de ambientes
SOLAP ( como por exemplo, os trabalhos discutidos no Capı́tulo 3).
123
7.2 PRINCIPAIS CONTRIBUIÇÕES
7.2
PRINCIPAIS CONTRIBUIÇÕES
Com a finalização desta tese de doutorado, após a realização de uma ampla revisão bibliográfica,
escrita de artigos, implementação de grande parte das idéias propostas, entendemos que as
nossas principais contribuições são:
Análise Comparativa sobre Abordagens para SOLAP: Foi realizado um amplo estudo
do estado da arte sobre SOLAP, envolvendo linguagens de consulta e operadores geográficos e multidimensionais, arquiteturas para processamento SOLAP e tecnologias
disponı́veis para implementação de ambientes que integram SIG e OLAP. A partir deste
estudo, uma análise crı́tica e comparativa das abordagens relacionadas com nossa pesquisa
foi feita. Parte dos resultados deste estudo comparativo pode ser encontrada em [83] e
[84] e foi detalhada em [77];
Formalização do modelo de Data Warehouse Geográfico: Foi realizada a formalização
matemática do nosso modelo de DWG, que estende GeoDWFrame [115] com suporte a
medidas espaciais. Detalhes desta contribuição, juntamente com sua aplicação prática,
podem ser encontrados em [283];
Definição das Funções de Agregação para Medidas Espaciais: No
Capı́tulo
4,
foi
definido um conjunto de funções de agregação de medidas espaciais, a partir da combinação de funções de agregação já estabelecidas na área de DW e operadores espaciais
também consolidados na área de SIG. Nossa motivação para a proposição deste conjunto
de funções, foi o nosso desconhecimento sobre a existência de um consenso sobre medidas
de agregação espacial na literatura de banco de dados. Esta contribuição também está
detalhada em [78];
Formalização do modelo GeoMDCube: A partir das definições formais dadas para nosso
modelo de DWG discutido no Capı́tulo 4, apresentamos um modelo formal para cubos
de dados multidimensionais e geográficos, chamado de GeoMDCube. Com estas formalizações, explicitamos de forma consistente e não ambı́gua, os relacionamentos existentes
entre os elementos pertencentes ao Data Warehouse Geográfico, ao cubo de dados, e ao
processo de agregação de medidas (ver [84] e [81]);
Especificação da Linguagem GeoMDQL: No Capı́tulo 5, apresentamos nossa principal
contribuição. Trata-se da linguagem de consulta para ambientes SOLAP, chamada GeoMDQL (Geographic and Multidimensional Query Language), a qual está baseada em
padrões amplamente difundidos como MDX [297], OCG [45] e SQL Espacial [269]. Fazem
parte desta contribuição a gramática definida para GeoMDQL e o seu conjunto de operadores multidimensionais e geográficos. Isto a torna uma das primeiras linguagens para
7.3 TRABALHOS FUTUROS
124
ambientes SOLAP. Aspectos importantes relacionados com a linguagem GeoMDQL podem ser encontrados em [84] e [81];
Implementação das idéias propostas: Nossas idéias foram aplicadas a estudos de casos
com dados reais, conforme foi discutido no Capı́tulo 6. Para isso, fez-se necessário um
esforço considerável para a implementação i) dos programas e algoritmos relacionados
com o parser e o processador da linguagem GeoMDQL; ii) dos operadores e das funções
de agregação; iii) esquemas do DWG e cubo de dados; iv) da interface gráfica.
7.3
TRABALHOS FUTUROS
Ao finalizar esta etapa da nossa pesquisa, percebemos alguns pontos que ainda podem ser
explorados. A seguir listamos algumas indicações de trabalhos futuros.
Interface Gráfica: Em nossas pesquisas, percebemos que a interface gráfica é muito importante em um ambiente SOLAP. Neste sentido, acreditamos que melhoramentos podem
ser realizados na interface gráfica da nossa arquitetura, proporcionando uma melhor interação com o usuário, não somente na visualização e manipulação dos resultados, mas
também na formulação de novas consultas. Um dos pontos que podem contribuir para a
evolução e melhoramento da interface gráfica é a realização de testes de usabilidade com
usuários finais, de forma semelhante aos realizados em [252]. Outro ponto que pode ser
explorado é a integração das idéias propostas em [264], com a linguagem GeoMDQL e seus
operadores. Neste mesmo contexto, a interface Web da nossa arquitetura [83] também
pode ser evoluı́da;
Otimização: Aspectos relacionados com a otimização também fazem parte dos trabalhos que
podem contribuir para o amadurecimento da tecnologia SOLAP. Em particular, para a
arquitetura Golapware (ver capitulo 5), o módulo de otimização precisa ser implementado. Estudos devem ser conduzidos para identificar a melhor estratégia para otimização
das consultas realizadas no cubo de dados. Isto pode englobar a utilização de novas estruturas de dados e técnicas de indexação. Em [104], alguns estudos neste sentido foram
conduzidos, propondo uma técnica alternativa às tradicionais, como R-Trees [140]. Adicionalmente, uma nova estrutura de dados para DWG está sendo proposta em [249]. No
que se refere à pre-agregação, que também está inserido no contexto de otimização, alguns
trabalhos que podem servir como ponto de partida para este tipo de investigação, são os
apresentados em [223] e [267];
Funções de Agregação: No Capı́tulo 4, propomos um conjunto de funções de agregação
de medidas espaciais. Entretanto, um estudo mais aprofundado precisa ser conduzido,
7.3 TRABALHOS FUTUROS
125
para verificar, por exemplo, se estas são suficientes, quais são relevantes, quais não são
aplicáveis, chegando assim a um conjunto bem definido deste tipo de funções;
Implementações: Trabalhos de implementação também precisam ser conduzidos, em especial,
no que se refere aos operadores da linguagem GeoMDQL, apresentados no Capı́tulo 5 e
às funções de agregação de medidas (ver Capı́tulo 4);
Extensões para a Linguagem GeoMDQL: A extensão da linguagem GeoMDQL com operadores temporais, incluindo definições, como as propostas em [122, 39] e também, com
operações para mineração de dados espaciais. Um ponto de partida pode ser a extensão
do mecanismo de mineração de dados do projeto de código aberto Pentaho [225].
REFERÊNCIAS BIBLIOGRÁFICAS
[1] An Architecture for Spatial and Dimensional Analysis Integration, World Multiconference
on Systemics, Cibernetics and Informatics (SCI 2001), 2001.
[2] Goal:
Geographical
information
on-line
analysis
-
official
home
page:
http://krizik.felk.cvut.cz/goal/, 2003.
[3] Alberto Abelló, José Samos, and Fèlix Saltor. Yam2 (yet another multidimensional
model): An extension of uml. In Proceedings of the 2002 International Symposium on
Database Engineering & Applications, pages 172–181. IEEE Computer Society, 2002.
[4] Alberto Abelló, José Samos, and Fèlix Saltor. Implementing operations to navigate semantic star schemas. In Proceedings of the 6th ACM international workshop on Data
warehousing and OLAP, pages 56–62. ACM Press, 2003.
[5] Rakesh Agrawal. Data mining. In Proceedings of the 13th Symposium on Principles of
Database Systems, pages 75–76, New York, NY, USA, May 1994. ACM Press.
[6] Rakesh Agrawal, Ashish Gupta, and Sunita Sarawagi.
Modeling multidimensional
databases. In Proceedings of the Thirteenth International Conference on Data Engineering, pages 232–243. IEEE Computer Society, 1997.
[7] Altova.
K-means - http://home.dei.polimi.it/ matteucc/clustering/ tutorial html/
kmeans.html, Last Visit Oct 2008.
[8] Altova. Xml spy - www.xmlspy.com, Last Visit Jul 2008.
[9] Ronnie Alves, Orlando Belo, and Joel Ribeiro. Mining top-k multidimensional gradients.
In DaWaK, pages 375–384, 2007.
[10] Marie-Aude Aufaure-Portier and Claude Trépied. A survey of query languages for geographic information systems. In Proceedings of the 3rd International Workshop on Interfaces to Databases, July 1996.
[11] MEYER B. Beyond icons : Towards new metaphors for visual query languages for spatial
information systems. In Proceedings of the first International Workshop on Interfaces to
Database Systems, pages 113–135, 1993.
126
127
[12] Thierry Badard and Étienne Dubé. Building geospatial business intelligence solutions
with free and open source components, foss4g2007, 2007, 2008.
[13] Yvan Bedard, Tim Merrett, and Jiawei Han. Geographic Data Mining and Knowledge
Discovery, chapter Fundamentals of Spatial Data Warehousing for Geographic Knowledge
Discovery, pages 53–73. Taylor and Francis, 2001. Research Monographs in GIS series
edited by Peter Fisher and Jonathan Raper.
[14] Yvan Bédard, Sonia Rivest, and Marie-Josée Proulx. Spatial On-Line Analytical Processing (SOLAP): Concepts, Architectures and Solutions from a Geomatics Engineering
Perspective, chapter 13, pages 298–319. IRM Press (Idea Group), London, UK, 2007.
[15] Ilse M. Beuren and Luciano W. Martins.
vas:
Sistema de informações executi-
Suas caracterı́sticas e reflexões sobre sua aplicação no processo de gestão,
http://www.eac.fea.usp.br/cadernos/completos/cad26/revista 26 part 1.pdf, Last Visit
Jul 2001.
[16] Sandro Bimonte and Anne Tchounikine. GeOlaPivot Table: a Visualization Paradigm
for SOLAP Solutions. In Visual Languages and Computing Workshop of the 2006 International Conference on Distributed Multimedia Systems (DMS’2006),, sep 2006.
[17] Sandro Bimonte, Anne Tchounikine, and Maryvonne Miquel. Towards a spatial multidimensional model. In DOLAP ’05: Proceedings of the 8th ACM international workshop on
Data warehousing and OLAP, pages 39–46, New York, NY, USA, 2005. ACM Press.
[18] Sandro Bimonte, Anne Tchounikine, and Maryvonne Miquel. Geocube, a multidimensional model and navigation operators handling complex measures: Application in spatial
olap. In ADVIS, pages 100–109, 2006.
[19] Sandro Bimonte, Pascal Wehrle, Anne Tchounikine, et al. GeWOlap: A Web Based Spatial OLAP Proposal. In Second International Workshop on Semantic-based Geographical
nformation Systems, pages 1596–1615, 2006.
[20] Andreas D. Blaser and Max Egenhofer. A visual tool for querying geographic databases.
In Proceedings of the Working Conference on Advanced Visual Interfaces, pages 211–216.
ACM Press, 2000.
[21] Juan Euclides Bohorquez. Aproximación metodológica de un spatial data warehouse,
http://gis.esri.com/library/userconf/latinproc00/colombia/spatial data.pdf, 2000.
[22] Christine Bonhomme, Claude Trépied, Marie-Aude Aufaure, and Robert Laurini. A visual
language for querying spatio-temporal databases. In Proceedings of the seventh ACM
128
international symposium on Advances in geographic information systems, pages 34–39.
ACM Press, 1999.
[23] Omar Boucelma, Mehdi Essid, and Zoé Lacroix. A wfs-based mediation system for gis
interoperability. In Proceedings of the tenth ACM international symposium on Advances
in geographic information systems, pages 23–28. ACM Press, 2002.
[24] Stephen Brobst and Joe Rarey.
support
evolution,
Five stages of data warehouse decision
http://dssresources.com/subscriber/password/papers/
fea-
tures/brobst&rarey01062003.html, Last Visit Jul 2003.
[25] Luca Cabibbo and Riccardo Torlone. From a procedural to a visual query language for
olap. In Proceedings of the 10th International Conference on Scientific and Statistical
Database Management, pages 74–83. IEEE Computer Society, 1998.
[26] Luca Cabibbo and Riccardo Torlone. A logical approach to multidimensional databases.
In Proceedings of the 6th International Conference on Extending Database Technology,
pages 183–197. Springer-Verlag, 1998.
[27] Luca Cabibbo and Riccardo Torlone. Querying multidimensional databases. In Proceedings of the 6th International Workshop on Database Programming Languages, pages
319–335. Springer-Verlag, 1998.
[28] Luca Cabibbo and Riccardo Torlone. The design and development of a logical system for
olap. In Proceedings of the Second International Conference on Data Warehousing and
Knowledge Discovery, pages 1–10. Springer-Verlag, 2000.
[29] Luca Cabibbo and Riccardo Torlone. Query languages for multidimensional data. Technical Report T4-R22, Dipartimento di Informatica e Automazione, Università degli Studi
Roma Tre, 2000.
[30] D. Calcinelli and Michel Mainguenaud. Cigales, a visual query language for a geographical
information system: the user interface. J. Vis. Lang. Comput., 5(2):113–132, 1994.
[31] Gilberto Câmara, Marco A. Casanova, Ubirajara Moura de Freitas, João Pedro Cerveira
Cardeiro, and Lauro Hara. A presentation language for gis cadastral data. In ACM-GIS,
pages 139–146, 1996.
[32] Gilberto
Câmara,
Marco
and C. M. B. Medeiros.
A.
Casanova,
A.
S.
Hemerly,
G.
C.
Magalhães,
Anatomia de sistemas de informação geográfica,
http://www.dpi.inpe.br/geopro/livros/anatomia.pdf, 1996.
[33] Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. ACM Computing Surveys, 17(4):471–522, 1985.
129
[34] Valéria M. B. Cavalcanti, Ulrich Schiel, and Cláudio de Souza Baptista. Querying spatiotemporal databases using a visual environment. In AVI ’06: Proceedings of the working
conference on Advanced visual interfaces, pages 412–419, New York, NY, USA, 2006.
ACM Press.
[35] J. Chae and S. Lee. Natural language query processing in korean interface for objectoriented databases. In Applications of Natural Language to Data Bases, pages 0–, 1995.
[36] Surajit Chaudhuri and Umesh Dayal. An overview of data warehousing and OLAP technology. ACM SIGMOD Record, 26(1), March 1997.
[37] Surajit Chaudhuri and Umeshwar Dayal. Decision support, data warehouse, and olap.
Tutorials of the Twenty-Second international Conf. On Very Large Data Base, 1996.
[38] Surajit Chaudhuri et al. Database technology for decision support systems. IEEE Computer, pages 48–55, December 2001.
[39] Cindy X. Chen, Jiejun Kong, and Carlo Zaniolo. Design and implementation of a temporal
extension of sql. In 19th International Conference on Data Engineering, page 689, March
2003.
[40] Cindy Xinmin Chen and Carlo Zaniolo. Sql st : A spatio-temporal data model and query
language. In International Conference on Conceptual Modeling / the Entity Relationship
Approach, pages 96–111, 2000.
[41] Nicholas Chrisman. Exploring Geographic Information Systems. John Wiley and Sons,
1996.
[42] Serafino Cicerone and Paolino Di Felice. Cardinal directions between spatial objects: the
pairwise-consistency problem. Inf. Sci. Inf. Comput. Sci., 164(1-4):165–188, 2004.
[43] Keith C. Clarke. Getting Started with Geographic Information Systems. Prentice Hall,
USA, 1997.
[44] Clipping. Clipping algorithms - http://www.cs.umbc.edu/ rheingan/435/pages/ res/gen5.clipping-single-page-0.html, Last Visit Jul 2008.
[45] Open Geospatial Consortium. OpenGIS simple features specification for SQL. Technical
report, Open Geospatial Consortium, 1997.
[46] Open Geospatial Consortium. Filter encoding implementation specification. Technical
report, Open Geospatial Consortium, 2001.
[47] Open Geospatial Consortium. Ogc geography markup language (gml) 2.0, document
number: 01-029.2001,http://www.opengis.netigml/ol-029/gml2.html, 2001.
130
[48] Open Geospatial Consortium. Open geospatial consortium open gis catalog services specification, http://www.opengis.org, 2002.
[49] Open Geospatial Consortium. Open geospatial consortium web feature service implementation specification, http://www.opengis.org, Setembro 2002.
[50] Open Geospatial Consortium. Open gis catalog services specification. Technical report,
Open Geospatial Consortium, 2002.
[51] Open Geospatial Consortium.
Open geospatial consortium official home page,
http://www.opengis.org, Agosto 2007.
[52] Open Geospatial Consortium.
a request for proposals:
Ogc request 1, open geodata model working group,
Opengis features (opengis project document number 96-
021),http://www.opengis.org/techno/request.htm, Fevereiro 2008.
[53] Open GIS Consortium. The open gis abstract specification. Technical report, Open GIS
Consortium, 1999.
[54] José Eduardo Córcoles and Pascual González. A specification of a spatial query language
over gml. In Proceedings of the ninth ACM international symposium on Advances in
geographic information systems, pages 112–117. ACM Press, 2001.
[55] IBM Corporation. Ibm informix spatial datablade module user’s guide. Technical report,
IBM Corporation, Agosto 2002.
[56] IBM Corporation.
Db2 olap server editions official home page, http://www-
306.ibm.com/software/data/db2/db2olap/, Last Visit Jul 2008.
[57] IBM
Corporation.
Db2
spatial
extender
official
home
page,
http://www-
306.ibm.com/software/data/spatial/, Last Visit Jul 2008.
[58] IBM Corporation. Db2 universal database data warehouse editions official home page,
http://www-306.ibm.com/software/data/db2/udb/dwe/, Last Visit Jul 2008.
[59] IBM Corporation. Ibm corporation official home page, http://www.ibm.com, Last Visit
Jul 2008.
[60] IBM
Corporation.
Ibm
informix
official
home
page,
http://www-
306.ibm.com/software/data/informix/, Last Visit Jul 2008.
[61] IBM Corporation.
Ibm red brick warehouse official home page, http://www-
306.ibm.com/software/data/informix/redbrick/, Last Visit Jul 2008.
131
[62] IBM
Corporation.
Ibm
red
brick
warehouse
sql
reference
guide,
http://publibfp.boulder.ibm.com/epubs/pdf/c1873960.pdf, Last Visit Jul 2008.
[63] IBM
Corporation.
Ibm
sgbd
db2
official
home
page,
http://www-
306.ibm.com/software/data/db2/, Last Visit Jul 2008.
[64] MapInfo Corporation. Mapinfo corporation official home page, http://www.mapinfo.com,
Last Visit Jul 2008.
[65] MapInfo Corporation. Mapinfo spatialware 4.8 for microsoft sql serverrelease notes. Technical report, MapInfo Corporation, 2008.
[66] Microsoft Corporation. Introduction to multidimensional expressions (mdx)comparison
of sql and mdx. analysis service documentation, 2000.
[67] Microsoft
tion,
Corporation.
MDX
Overview.
Microsoft
http://msdn.microsoft.com/library/default.asp?url=
Corpora/library/en-
us/olapdmad/agmdxbasics 90qg.asp, 2004.
[68] Microsoft Corporation. Business intelligence and data warehousing official home page,
http://www.microsoft.com/sql/ evaluation/bi/default.asp, Last Visit Jul 2008.
[69] Microsoft
Corporation.
Microsoft
odbc
official
home
page,
http://www.microsoft.com/data/odbc/default.htm, Last Visit Jul 2008.
[70] Microsoft
Corporation.
Microsoft
sql
server
official
home
page,
http://www.microsoft.com/sql/, Last Visit Jul 2008.
[71] Microsoft Corporation. Plataforma .net - http://msdn.microsoft.com/ netframework/,
[72] Microsoft
Corporation.
Multidimensional
expressions
(mdx)
reference
-
http://msdn.microsoft.com/en-us/library/ms145506.aspx, Last visit, Jul 2008.
[73] Oracle Corporation.
Oracle 10g official home page,
http://www.oracle.com/
ip/deploy/database/oracle10g, Last Visit Jul 2008.
[74] Oracle Corporation. Oracle olap official home page, http://www.oracle.com/technology/
products/bi/olap/olap.html, Last Visit Jul 2008.
[75] Oracle
Corporation.
Oracle
http://www.oracle.com/technology/products/
2008.
spatial
official
spatial/index.html,
home
Last
Visit
page,
Jul
132
[76] Joel da Silva. Integrando serviços analı́ticos e geográficos para suporte à decisão na web”,
dissertação de mestrado. Master’s thesis, Centro de Informática - Universidade Federal
de Pernambuco, 2004.
[77] Joel da Silva. Geomdql: Uma linguagem de consulta geográfica e multidimensional proposta de doutorado. Technical report, CIn-UFPE, 2006.
[78] Joel da Silva, Anjolina de Oliveira, Ana C. Salgado, Valéria Times, Robson Fidalgo,
and Clenúbio Souza. A set of aggregation functions for spatial measures. In DOLAP
’08: Proceedings of the Eleventh ACM international workshop on Data warehousing and
OLAP. ACM Press, 2008.
[79] Joel da Silva, Robson Fidalgo, Valéria Times, and Roberto de Barros. Towards a web
service for geographic and multidimensional processing. In VI Brazilian Symposium on
GeoInformatics, pages 2–17, Campos do Jordão, SP, Brasil, 2004.
[80] Joel da Silva, Robson Fidalgo, Valéria Times, and Ana Carolina Salgado. Propondo
uma linguagem de consulta geográfica multidimensional. In VI Brazilian Symposium on
GeoInformatics, pages 479–489, Campos do Jordão, SP, Brasil, 2004.
[81] Joel da Silva, Rafael Fonseca, Anjolina de Oliveira, Robson Fidalgo, Ana C. Salgado, and Valéria Times.
Modelling and querying geographical data warehouses.
http://ees.elsevier.com/is/, 2008 (Submitted to Information Systems).
[82] Joel da Silva, Valéria Times, Robson Fidalgo, and Roberto Barros. Providing geographicmultidimensional decision support over the web. In 7th Asia-Pacific Web Conference
(APWeb), pages 477–488, 2005.
[83] Joel da Silva, Valéria Times, Ana Carolina Salgado, Vivianne Medeiros, and Robson Fidalgo. An open source and web based framework for geographic and multidimensional
processing. In The 21st Annual ACM Symposium on Applied Computing, Track on Advances in Spatial and Image-based Information Systems (ACM SAC ASIIS’06), pages
63–67, 2006.
[84] Joel da Silva, Asuberto Castro Vera, Anjolina Oliveira, Robson Fidalgo, Ana Carolina
Salgado, and Valéria Times. Querying geographical datawarehouses with geomdql. In
Brazilian Symposium on Databases(SBBD), pages 223–237, 2007.
[85] Maria Luisa Damiani and Stephano Spaccapietra. Spatial Data Warehouse Modelling,
pages 21–27. Processing and Managing Complex Data for Decision Support. Idea Group
Publishing, Hershey, PA, USA, April 2006.
133
[86] Christopher J. Date and Hugh Darwen. A Guide to SQL Standard. Addison-Welsey,
fourth edition, 1997.
[87] M. de Berg, M. van Kreveld, M. Overmans, and O. Schwarzkopf. Voronoi Diagrams: The
Post Office Problem. Springer-Verlag, 2000.
[88] Michael N. Demers. Fundamentals of Geographic Information Systems. Wiley, USA, 1997.
[89] Min Deng and Zhilin Li. A discrete model for topological relationships between uncertain
spatial objects. GeoInformatica, 2007.
[90] Yves Dennebouy, Martin Andersson, Annamaria Auddino, Yann Dupont, Edi Fontana,
Massimo Gentile, and Stefano Spaccapietra.
SUPER: Visual interfaces for ob-
ject+relationship data models. Journal of Visual Languages and Computing, 6(1):73–99,
1995.
[91] R. M. Downs and D. Stea. Maps in Minds: Reflections on Cognitive Mapping. Harper &
Row, New York, 1977.
[92] Max Egenhofer and H. T. Bruns. Visual map algebra: a direct-manipulation user interface
for gis. In Proceedings of the third IFIP WG2.6 working conference on Visual database
systems 3 (VDB-3), pages 235–253, London, UK, UK, 1995. Chapman & Hall, Ltd.
[93] Max Egenhofer and Andrew Frank. Query languages for geographic information systems. Technical Report 90-12, National Center for Geographic Information and Analysis,
University of Maine, Orono, 1990.
[94] Max Egenhofer and J. Herring. Categorizing binary topological relationships between
regions, lines and points in geographic databases. Technical report, Department of Surveying Engineering, University of Maine, 1991.
[95] Max J. Egenhofer. A formal definition of binary topological relationships. In 3rd International Conference, FODO 1989 on Foundations of Data Organization and Algorithms,
pages 457–472. Springer-Verlag New York - Inc., 1989.
[96] Max J. Egenhofer. Extending sql for cartographic display. Cartography and Geographical
Information Systems, 18(4):230–245, 1991.
[97] Max J. Egenhofer. Spatial sql: A query and presentation language. IEEE Transactions
on Knowledge and Data Engineering, 6(1):86–95, 1994.
[98] Max J. Egenhofer. Query processing in spatial-query-by-sketch. Journal of Visual Languages and Computing, 8(4):403–424, 1997.
134
[99] Max J. Egenhofer and Andrew U. Frank. Towards a spatial query language: User interface
considerations. In Proceedings of the Fourteenth International Conference on Very Large
Data Bases, pages 124–133. Morgan Kaufmann Publishers Inc., 1988.
[100] Max J. Egenhofer and David M. Mark. In LOBSTER: Combining AI and Database
Techniques for GIS, volume 6, pages 919–926, 1990.
[101] Max J. Egenhofer and David M. Mark. Naive geography. In Spatial Information Theory,
pages 1–15, 1995.
[102] Andrew Eisenberg, Jim Melton, Krishna Kulkarni, Jan-Eike Michels, and Fred Zemke.
Sql:2003 has been published. SIGMOD Rec., 33(1):119–126, 2004.
[103] Ramez Elmasri and Shamkant Navathe.
Fundamentals of Database Systems.
Ben-
jamin/Cummings Publishing Company, 1989.
[104] Ariel Escribano, Leticia Gomez, Bart Kuijpers, and Alejandro A. Vaisman. Piet: a gis-olap
implementation. In DOLAP ’07: Proceedings of the ACM tenth international workshop
on Data warehousing and OLAP, pages 73–80, New York, NY, USA, 2007. ACM.
[105] ESRI. Esri mapobjects official home page, http://www.esri.com, Last Visit Jul 2008.
[106] ESRI. Esri official home page, http://www.esri.com, Last Visit Jul 2008.
[107] Huowang Chen Feng Wang, Jichang Sha and Shuqiang Yang. Geosql: A spatial query
language of object-oriented gis. In Proceedings of the 2nd International Workshop on
Computer Science and Informationn Technologies, 2000.
[108] Mary Fernandez, Jerome Simeon, and Philip Wadler. An algebra for XML query. Lecture
Notes in Computer Science, 1974, 2000.
[109] ANA CRISTINA F. FERREIRA. Um modelo para suporte à integração de analises
multidimensionais e espaciais. Master’s thesis, UFRJ, Rio de Janeiro - Brasil, 2002.
[110] Fernando Ferri, Elaheh Pourabbas, and Maurizio Rafanelli. The syntactic and semantic
correctness of pictorial configurations to query geographic databases by pql. In Proceedings
of the 2002 ACM symposium on Applied computing, pages 432–437. ACM Press, 2002.
[111] Fernando Ferri, Elaheh Pourabbas, Maurizio Rafanelli, and F. L. Ricci. Extending geographic databases for a query language to support queries involving statistical data. In
Proceedings of the 12th International Conference on Scientific and Statistical Database
Management (SSDBM’00), page 220. IEEE Computer Society, 2000.
135
[112] Fernando Ferri, Elaheh Pourabbas, Maurizio Rafanelli, and Fabrizio L. Ricci. Linking
geographic and multidimensional databases by functional attributes. In Nono Convegno
Nazionale Sistemi Evoluti per Basi di Dati (SEBD 2001), pages 185–199, 2001.
[113] Robson Fidalgo. Uma Infra-Estrutura para Integração de Modelos, Esquemas e Serviços
Multidimensionais e Geográficos, Tese de Doutorado. PhD thesis, Centro de Informática
- Universidade Federal de Pernambuco, 2005.
[114] Robson Fidalgo, Joel da Silva, Valéria Times, , Fernando Fonseca, and Roberto Barros.
Gmla: A xml schema for integration and exchange of multidimensional-geographical data.
In V Brazilian Symposium on GeoInformatics, 2003.
[115] Robson Fidalgo, Valéria Times, Joel da Silva, and Fernando Fonseca. Geodwframe: A
framework for guiding the design of geographical dimensional schemas. In Data Warehousing and Knowledge Discovery (DaWaK), pages 26–37, 2004.
[116] Robson Fidalgo, Valéria Times, Joel da Silva, Fernando Fonseca, and Ana Carolina Salgado. Providing multidimensional and geographical integration based on a gdw and metamodels. In Brazilian Symposium on Databases (SBBD), 2004.
[117] Jugurta L. Filho and Cirano Iochpe. Introdução a sistemas de informação geográfica
com ênfase em banco de dados. In XV Jornada de Atualização em Informática - XVI
Congresso da SBC, 1996.
[118] Raphael A. Finkel and Jon Louis Bentley. Quad-trees; a data structure for retrieval on
composite keys. Acta Informatica, 4:1–9, 1974.
[119] Rafael Fonseca, Robson Fidalgo, Joel da Silva, and Valéria Times. Geodwcase: Uma
ferramenta para projeto de data warehouses geográficos. In Brazilian Symposium on
Databases(SBBD), Demos Session, 2007.
[120] Rafael Fonseca, Robson Fidalgo, Joel da Silva, and Valéria Times.
Um metamod-
elo para a especificação de data warehouses geográficos. In Brazilian Symposium on
Databases(SBBD), pages 193–207, 2007.
[121] International Organization for Standardization. ISO - ANSI Working Draft - Database
Language SQL-Amendment 1: On-Line Analytical Processing (SQL/OLAP). International Organization for Standardization, Washington - USA, 1999.
[122] International Organization for Standardization.
languages-sql part 7 temporal(sql-foundation), 2001.
Information technology -database
136
[123] International Organization for Standardization. ISO-IEC WD 13249-3 Information technology - Database languages - SQL Multimedia and Application Packages Part 3 - Spatial.
International Organization for Standardization, Chantilly, VA, 3rd edition, 2003.
[124] Markus Forsberg and Aarne Ranta. Bnf converter. In Haskell ’04: Proceedings of the
2004 ACM SIGPLAN workshop on Haskell, pages 94–95, 2004.
[125] Free
Sofware
Foundation.
The
gnu
general
public
license,
http://www.fsf.org/licensing/licenses/index html#gpl, Last Visit Jul 2008.
[126] Enrico Franconi and Anand Kamble. The gmd data model for multidimensional information: a brief introduction. In 5th International Conference on Data Warehousing and
Knowledge Discovery (DaWaK’03), 2003.
[127] Enrico Franconi and Anand Kamble. A data warehouse conceptual data model. In 16th
Conf. on Scientific and Statistical Database Management (SSDBM’04), 2004.
[128] Enrico Franconi and Anand Kamble. The gmd data model and algebra for multidimensional information. In 16th International Conference on Advanced Information Systems
Engineering (CAiSE-04), 2004.
[129] Lars M. Garshol.
Bnf and ebnf:
What are they and how do they work?,
www.garshol.priv.no/ download/text/bnf.html, Last Visit Jul.
[130] Leticia Gomez, Sofie Haesevoets, Bart Kuijpers, and Alejandro A. Vaisman. Spatial
aggregation: Data model and implementation. CoRR, abs/0707.4304, 2007.
[131] Leticia I. Gómez, Bart Kuijpers, and Alejandro A. Vaisman. Aggregation languages for
moving object and places of interest. In SAC ’08: Proceedings of the 2008 ACM symposium
on Applied computing, pages 857–862, New York, NY, USA, 2008. ACM.
[132] Roop K. Goyal and Max J. Egenhofer.
tial objects.
Cardinal directions between extended spa-
IEEE Transactions on Knowledge and Data Engineering - http :
//www.spatial.maine.edu/ max/RJ36.html, 2000.
[133] Roop K. Goyal and Max J. Egenhofer. Consistent queries over cardinal directions across
different levels of detail. In DEXA Workshop, pages 876–880, 2000.
[134] Jim Gray, Adam Bosworth, Andrew Layman, and Hamid Pirahesh. Data cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-total. In ICDE ’96:
Proceedings of the Twelfth International Conference on Data Engineering, pages 152–159,
Washington, DC, USA, 1996. IEEE Computer Society.
137
[135] Jim Gray, Surajit Chaudhuri, Adam Bosworth, Andrew Layman, Don Reichart, Murali
Venkatrao, Frank Pellow, and Hamid Pirahesh. Data cube: A relational aggregation
operator generalizing group-by, cross-tab, and sub-totals. Data Mining and Knowledge
Discovery, 1(1):29–53, 1997.
[136] Ricardo Wilmar Gross and Renato Fileto and. Estudo de ferramentas de visualização
cartográfica para acoplamento com olap sobre a web. In Escola Regional de Banco de
Dados, IV Escola Regional de Banco de Dados, Florianópolis, 2008.
[137] Ralf H. Güting. Geo-relational algebra: A model and query language for geometric
database systems. In Proceedings of the International Conference on Extending Database
Technology, pages 506–527. Springer-Verlag, 1988.
[138] Ralf H. Güting.
Geo-relational algebra: a model and query language for geometric
database systems (extended abstract). In Proceedings on International Workshop on
Computational Geometry on Computational Geometry and its Applications, pages 90–96.
Springer-Verlag New York, Inc., 1988.
[139] Ralf Hartmut Güting. An introduction to spatial database systems. The VLDB Journal,
3(4):357–399, 1994.
[140] Antonin Guttman. R-trees: a dynamic index structure for spatial searching. In SIGMOD
’84: Proceedings of the 1984 ACM SIGMOD international conference on Management of
data, pages 47–57, New York, NY, USA, 1984. ACM Press.
[141] Marc Gyssens and Laks V. S. Lakshmanan. A foundation for multi-dimensional databases.
In Proceedings of the 23rd International Conference on Very Large Data Bases, pages 106–
115. Morgan Kaufmann Publishers Inc., 1997.
[142] Robert Brian Hagmann and Domenico Ferrari. Performance analysis of several back-end
database architectures. ACM Trans. Database Syst., 11(1):1–26, 1986.
[143] Jaiwei Han, Krzysztof Koperski, and Nebojsa Stefanovic. Geominer: a system prototype
for spatial data mining. volume 26, pages 553–556, New York, NY, USA, 1997. ACM.
[144] Jiawei Han. Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers Inc.,
San Francisco, CA, USA, 2005.
[145] Vera Hernández, Wolf Göhring, Angi Voss, and Cornelio Hopmann. Sustainable decision support by the use of multi-level and multi-criteria spatial analysis on the nicaragua
development gateway. In 8th International Conference on the Global Spatial Data Infrastructure (GSDI-8), Cairo, Egypt, 2005.
138
[146] Carlos A. Hurtado, Alberto O. Mendelzon, and Alejandro A. Vaisman. Maintaining data
cubes under dimension updates. In ICDE 99: Proceedings of the 15th International Conference on Data Engineering, page 346, Washington - DC - USA, 1999. IEEE Computer
Society.
[147] Byungyeon Hwang, Taekyung Byun, and Songchun Moon. Spatial query processing in
geographic database systems. In EUROMICRO 94. System Architecture and Integration.
Proceedings of the 20th EUROMICRO Conference., pages 53–60, September 1994.
[148] Hyperion.
Hyperion
essbase
http://dev.hyperion.com/techdocs/essbase/
maxl
user‘s
guide
essbase 61/docs/pdf/essmaxl.pdf,
,
Last
Visit Jul 2008.
[149] Hyperion. Hyperion official home page, http://www.hyperion.com, Last Visit Jul 2008.
[150] Hyperion.
Introducing hyperion essbase, http://dev.hyperion.com/techdocs/essbase/
essbase 70/docs/dbag/frameset.htm?/techdocs/
essbase/essbase 70/docs/
dbag/dmaxldml.htm, Last Visit Jul 2008.
[151] Hyperion. Overview of maxl and mdx, http://dev.hyperion.com/techdocs/essbase/ essbase 712 /docs/techref/ techref.htm#maxl/ dml/dmlref.htm, Last Visit Jul 2008.
[152] IBM. Ibm db2 spatial extender user‘s guide and reference, version 8, 2002.
[153] Metapa Inc. Metapa inc. official home page, http://www.metapa.net, Last Visit Jul 2008.
[154] Refractions Research Inc. Postgis official home page, http://postgis.refractions.net/, Last
Visit Jul 2008.
[155] William H. Inmon. Como construir um Data Warehouse. Editora Campus, 1997.
[156] Intergraph. Geomedia, http://www.intergraph.com/geomedia/, Last Visit Jul 2008.
[157] International Organization for Standardization. ISO- IEC 9075:1992: Information technology - Database languages - SQL.
International Organization for Standardization,
Geneva, Switzerland, 1992.
[158] Christian S. Jensen, Augustas Kligys, Torben Bach Pedersen, and Igor Timko. Multidimensional data modeling for location-based services. VLDB J., 13(1):1–21, 2004.
[159] JPF. Java plugin framework, http://jpf.sourceforge.net/, Last Visit Feb 2008.
[160] JRubik. Jrubik, http://rubik.sourceforge.net/jrubik/, Last Visit Feb 2008.
[161] JUMP. Jump, http://www.jump-project.org/, Last Visit Jul 2008.
139
[162] Peter B. Keenan. Spatial decision support systems. pages 28–39, 2003.
[163] Ralph Kimball. The Data Warehouse Toolkit. John Wiley, 2002. and other books.
[164] Zdenek Kouba, Kamil Matousek, and Petr Miksovský. On data warehouse and gis
integration. In DEXA ’00: Proceedings of the 11th International Conference on Database
and Expert Systems Applications, pages 604–613, London, UK, 2000. Springer-Verlag.
[165] Hans-Peter Kriegel, Thomas Brinkhoff, and Ralf Schneider. Efficient spatial query processing in geographic database systems. IEEE Data Eng. Bull., 16(3):10–15, 1993.
[166] Gabriel Kuper, Sridhar Ramaswamy, Kyuseok Shim, and Jianwen Su. A constrant-based
spatial extension to sql. In GIS ’98: Proceedings of the 6th ACM international symposium
on Advances in geographic information systems, pages 112–117, New York, NY, USA,
1998. ACM Press.
[167] Gabriel Kuper, Sridhar Ramaswamy, Kyuseok Shim, and Jianwen Su. A constrant-based
spatial extension to sql. In Proceedings of the sixth ACM international symposium on
Advances in geographic information systems, pages 112–117. ACM Press, 1998.
[168] Wolfgang Lehner. Modelling large scale olap scenarios. In EDBT ’98: Proceedings of the
6th International Conference on Extending Database Technology, pages 153–167, London
- UK, 1998. Springer-Verlag.
[169] Lloyd Leifer.
Spatial query server (sqs) is more than a pretty picture,
http://www.teradata.com/ t/go.aspx/ index.html?id=115221, Last Visit Jul 2008.
[170] Karen A. Lemone, Mary Ann O’Connor, Jeffrey McConnell, and Joc Wisnewski. Implementing semantics of object oriented languages using attribute grammars. In CSC ’91:
Proceedings of the 19th annual conference on Computer Science, pages 190–202, 1991.
[171] Hans-Joachim Lenz and Arie Shoshani. Summarizability in OLAP and statistical data
bases. In Statistical and Scientific Database Management, pages 132–143, 1997.
[172] Hui Lin and Bo Huang. Sql/sda: A query language for supporting spatial data analysis and
its web-based implementation. IEEE Transactions on Knowledge and Data Engineering,
13(4):671–682, July 2001.
[173] Yong-Shan Liu and Zhong-Xiao Hao. A method for composing cardinal direction relations.
Proceedings of 2005 International Conference on Machine Learning and Cybernetics, 4(14):2108 – 2112, 2005.
140
[174] Fabrizio Di Loreto, Fernando Ferri, Fernanda Massari, and Maurizio Rafanelli. A pictorial
query language for geographical databases. In Proceedings of the workshop on Advanced
visual interfaces, pages 233–244. ACM Press, 1996.
[175] Elzbieta Malinowski and Esteban Zimányi. Representing spatiality in a conceptual
multidimensional model. In GIS ’04: Proceedings of the 12th annual ACM international
workshop on Geographic information systems, pages 12–22, New York, NY, USA, 2004.
ACM Press.
[176] Elzbieta Malinowski and Esteban Zimányi. Representing spatiality in a conceptual multidimensional model. In GIS ’04: Proceedings of the 12th annual ACM international
workshop on Geographic information systems, pages 12–22, 2004.
[177] Elzbieta Malinowski and Esteban Zimányi. Spatial hierarchies and topological relationships in the spatial multidimer model. In BNCOD, pages 17–28, 2005.
[178] Elzbieta Malinowski and Esteban Zimányi. Requirements specification and conceptual
modeling for spatial data warehouses. In Proc. of the On The Move Federated Conferences
and Workshops, OTM, pages 1616–1625, 2006.
[179] Elzbieta Malinowski and Esteban Zimnyi. Advanced Data Warehouse Design: From Conventional to Spatial and Temporal Applications (Data-Centric Systems and Applications).
Springer Publishing Company, Incorporated, 2008.
[180] Nagapramod
Mandagere.
Buffer
operations
in
gis,
http://www-
users.cs.umn.edu/ npramod/enc pdf.pdf, Fevereiro 2008.
[181] Andreas Maniatis, Panos Vassiliadis, Spiros Skiadopoulos, and Yannis Vassiliou. Cpm: A
cube presentation model for olap. In 5th International Conference on Data Warehousing
and Knowledge Discovery (DaWaK 2003), September 2003.
[182] Andreas S. Maniatis, Panos Vassiliadis, Spiros Skiadopoulos, and Yannis Vassiliou. Advanced visualization for olap. In Proceedings of the 6th ACM international workshop on
Data warehousing and OLAP, pages 9–16. ACM Press, 2003.
[183] Paul B Mann. A translational bnf grammar notation. SIGPLAN, 41(4):16–23, 2006.
[184] Patrick Marcel. Modeling and querying multidimensional databases: An overview. Networking and Information Systems Journal, 2(5):515–548, 1999.
[185] Vivianne Medeiros. ”concepção e validação de algoritmos para processamento de consultas
geográfico-multidimensionais em um ambiente de data warehouse geográfico”. Master’s
thesis, Centro de Informática - Universidade Federal de Pernambuco, 2007.
141
[186] Antônio Mendes. Arquitetura de Software - Desenvolvimento Orientado para Arquitetura.
Campus, 1 edition, 2002.
[187] Microsoft.
Microsoft
mappoint
official
home
page,
http://www.microsoft.com/mappoint/default.mspx, Last Visit Jul 2008.
[188] Microsoft.
Microsoft
mappoint
olap
http://www.microsoft.com/downloads/details.aspx?
wizard
add-in,
familyid=e22fe181-1d5f-4bbd-
9e39-825a74fb1788, Last Visit Jul 2008.
[189] Sun
Microsystems.
Jdbc
technology
official
home
page,
http://java.sun.com/products/jdbc/, Last Visit Nov 2007.
[190] Sun Microsystems. Java - http://java.sun.com/, Last Visit Jul 2008.
[191] Sun Microsystems. Java server pages - http://java.sun.com/products/jsp/, Last Visit Jul
2008.
[192] Petr Miksovský and Zdenek Kouba. Golap - geographical online analytical processing. In DEXA ’01: Proceedings of the 12th International Conference on Database and
Expert Systems Applications, pages 442–449, London, UK, 2001. Springer-Verlag.
[193] Andrew J. Morris, A.I. Abdelmoty, B.A. El-Geresy, and C.B. Jones. A filter flow visual
querying language and interface for spatial databases. GeoInformatica, 8(2):107–141, June
2004.
[194] Chuck Murray. Oracle spatial user guide and reference, 10g release 1 (10.1), Dezembro
2008.
[195] MySQL. Mysql official home page, http://www.mysql.com/, Last Visit Jul 2008.
[196] MySQL.
Mysql
spatial
extension
official
http://dev.mysql.com/doc/mysql/en/spatial-extensions-in-mysql.html,
home
Last
page,
Visit
Jul 2008.
[197] C. Faloutsos N. Roussopoulos and T. Sellis. An efficient pictorial database system for
psql. IEEE Transactions on Software Engineering, 14(5):639–650, 1988.
[198] NCR. Ncr official home page, http://www.ncr.com, Last Visit Jul 2008.
[199] Nearest
Neighbor.
Nneighbor
example
-
http://
cs644/projects/perrier/ nearest.html, Last Visit Jul 2008.
cgm.cs.mcgill.ca/
soss/
142
[200] Thanh B. Nguyen, A. Min Tjoa, and Roland Wagner. Conceptual multidimensional data
model based on metacube. In ADVIS ’00: Proceedings of the First International Conference on Advances in Information Systems, pages 24–33, London - UK, 2000. SpringerVerlag.
[201] Carl Nolan. Introduction to Multidimensional Expressions (MDX). Microsoft Corporation,
August 1999.
[202] OMG. Common warehouse metamodel (cwm) specification 1.1, 2001.
[203] OMG. Object management group (2006). object constraint language (ocl) specification
2.0, http://www.omg.org/ technology/documents/formal/ocl.htm, Last Visit May 2008.
[204] OMG. Object management group official home page, http://www.omg.org/, Last Visit
May 2008.
[205] OMG. Uml 2.0 specification. http://www.omg.org/uml/, 2008.
[206] OMG. Xml metadata interchange official home page, http://www.omg.org/ technology/documents/ formal/xmi.htm, Last Visit May 2008.
[207] OpenJUMP. Openjump, http://openjump.org/, Last Visit Feb 2008.
[208] Oracle. Sql 2003 standard support in oracle database 10g. Technical report, Oracle, 2003.
[209] Oracle. Oracle olap developer´s guide to olap api, 10g release 1 (10.1.0.3), Last Visit Jul
2008.
[210] Oracle. Oracle olap dml reference, 10g release 1 (10.1.0.3), Last Visit Jul 2008.
[211] Oracle. Oracle olap reference, 10g release 1 (10.1.0.3), Last Visit Jul 2008.
[212] Oracle. Oracle warehouse builder user guide, 10g release 1 (10.1), November 2008.
[213] Dimitris Papadias, Panos Kalnis, Jun Zhang, and Yufei Tao. Efficient olap operations in
spatial data warehouses. In SSTD ’01: Proceedings of the 7th International Symposium on
Advances in Spatial and Temporal Databases, pages 443–459, London, UK, 2001. SpringerVerlag.
[214] Dimitris Papadias, Yufei Tao, Panos Kalnis, and Jun Zhang. Indexing spatio-temporal
data warehouses. In ICDE ’02: Proceedings of the 18th International Conference on Data
Engineering (ICDE’02), page 166, Washington, DC, USA, 2002. IEEE Computer Society.
[215] Dimitris Papadias and Yannis Theodoridis. Spatial relations, minimum bounding rectangles, and spatial data structures. International Journal of Geographical Information
Science, 11(2):111–138, 1997.
143
[216] Eric Pardede, J. Wenny Rahayu, and David Taniar. New sql standard for object-relational
database applications. In SIIT, pages 191–203, 2003.
[217] Dennis Pedersen, Karsten Riis, and Torben Bach Pedersen. A powerful and sql-compatible
data model and query language for olap. In Proceedings of the thirteenth Australasian
conference on Database technologies, pages 121–130. Australian Computer Society, Inc.,
2002.
[218] Dennis Pedersen, Karsten Riis, and Torben Bach Pedersen. Xml-extended olap querying. In SSDBM ’02: Proceedings of the 14th International Conference on Scientific and
Statistical Database Management, pages 195–206, Washington, DC, USA, 2002. IEEE
Computer Society.
[219] Torben Bach Pedersen. Aspects of data modeling and query processing for complex
multidimensional data, 2000.
[220] Torben Bach Pedersen and Christian S. Jensen. Multidimensional data modeling for
complex data. In Proceedings of the 15th International Conference on Data Engineering,
page 336. IEEE Computer Society, 1999.
[221] Torben Bach Pedersen and Christian S. Jensen. Multidimensional database technology.
IEEE Computer, pages 40–46, December 2001.
[222] Torben Bach Pedersen, Christian S. Jensen, and Curtis E. Dyreson. A foundation for
capturing and querying complex multidimensional data. Inf. Syst., 26(5):383–423, 2001.
[223] Torben Bach Pedersen and Nectaria Tryfona. Pre-aggregation in spatial data warehouses.
In SSTD ’01: Proceedings of the 7th International Symposium on Advances in Spatial and
Temporal Databases, pages 460–480, London, UK, 2001. Springer-Verlag.
[224] Pentaho. Mondrian, http://mondrian.pentaho.org/, Last Visit Jul 2008.
[225] Pentaho. Pentho open source business intelligence, http://www.pentaho.com/, Last Visit
Jul 2008.
[226] Eclipse Plataform. http://www.eclipse.org/. http://www.eclipse.org/., Last Visit Jul
2008.
[227] John Poole and David Mellor. Common Warehouse Metamodel: An Introduction to the
Standard for Data Warehouse Integration. John Wiley & Sons, Inc., New York, NY, USA,
2001.
[228] PostgreSQL. Postgresql official home page, http://www.postgresql.org/, Last Visit Jul
2008.
144
[229] Elaheh Pourabbas. Cooperation with geographic databases. Idea Group Publishing, 2003.
[230] Elaheh Pourabbas and Maurizio Rafanelli. Characterization of hierarchies and some operators in olap environment. In Proceedings of the 2nd ACM international workshop on
Data warehousing and OLAP, pages 54–59. ACM Press, 1999.
[231] Elaheh Pourabbas and Maurizio Rafanelli. Pql: An extended pictorial query language for
querying geographical databases using positional and olap operators. In Claudia Bauzer
Medeiros, editor, Proceedings of the 7th International Symposium on Advances in Geographic Information Systems, November 2-6, 1999, pages 165–166. ACM, November 1999.
[232] Elaheh Pourabbas and Maurizio Rafanelli. A pictorial query language for querying geographic databases using positional and olap operators. SIGMOD Record, 31(2):22–27,
2002.
[233] Daniel J. Power.
What is a decision support systems?,http://dssresources.com /pa-
pers/whatisadss/index.html, Last Visit Jul 1998.
[234] Daniel
J.
Power.
Supporting
decision-makers:
An
expanded
framework,
http://dssresources.com /papers/supportingdm/sld001.htm, Last Visit Jul 2000.
Decision support systems web tour,http:// dssresources.com/
tour/index.html, Last Visit Jul 2002.
A brief history of decision support systems,http:// dssre-
sources.com/history/ dsshistory.html, Last Visit Jul 2003.
[237] Sham Prasher and Xiaofang Zhou. Multiresolution amalgamation: dynamic spatial data
cube generation. In CRPIT ’04: Proceedings of the fifteenth conference on Australasian
database, pages 103–111, Darlinghurst, Australia, Australia, 2004. Australian Computer
Society, Inc.
[238] ProClarity. Proclarity, http://www.proclarity.com/, Last Visit Jul 2008.
[239] JPivot Project. Jpivot, http://jpivot.sourceforge.net/, Last Visit Jul 2008.
[240] Maurizio Rafanelli, editor. Multidimensional Databases: Problems and Solutions. Idea
Group, 2003.
[241] Paul Ramsey. Introduction to postgis. Technical report, Refractions Research Inc., Last
Visit Jul 2008.
[242] Fangyan Rao, Long Zhang, Xiu Lan Yu, Ying Li, and Ying Chen. Spatial hierarchy and
olap-favored search in spatial data warehouse. In DOLAP ’03: Proceedings of the 6th
145
ACM international workshop on Data warehousing and OLAP, pages 48–55, New York,
NY, USA, 2003. ACM Press.
[243] Sudhir G. Rao, Antonio Badia, and Dirk Van Gucht. Providing better support for a
class of decision support queries. In Proceedings of the 1996 ACM SIGMOD international
conference on Management of data, pages 217–227. ACM Press, 1996.
[244] The Olap Report. Market share analysis, http://www.olapreport.com/market.htm, Last
Visit Jul 2008.
[245] The Olap Report. The olap report, http://www.olapreport.com, Last Visit Jul 2008.
[246] Philippe Rigaux, Michel Scholl, and Agnes Voisard. Spatial databases with application to
GIS. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2002.
[247] Sonia Rivest, Yvan Bédard, and Pierre Marchand. Toward better support for spatial decision making: Defining the characteristics of spatial on-line analytical processing (solap).
Geomatica, 55(4):539–555, 2001.
[248] Sonia Rivest, Yvan Bédard, Marie-Josée Proulx, Martin Nadeau, Frederic Hubert, and
Julien Pastor. Solap technology: Merging business intelligence with geospatial technology for interactive spatio-temporal exploration and analysis of data. ISPRS Journal of
Photogrammetry e Remote Sensing, pages 17–33., November 2005.
[249] Thiago Rolim. Mapa de cubos - uma estrutura de agregados para data warehouse espaciais. Master’s thesis, Centro de Informática - Universidade Federal de Pernambuco,
2008.
[250] Safe.
Feature
manipulation
engine
official
home
page,
http://www.safe.com/products/fme/, Last Visit Nov 2007.
[251] Marcus Costa Sampaio, André Gomes de Sousa, and Cláudio de Souza Baptista. Towards
a logical multidimensional model for spatial data warehousing and olap. In DOLAP ’06:
Proceedings of the 9th ACM international workshop on Data warehousing and OLAP,
pages 83–90, New York, NY, USA, 2006. ACM Press.
[252] Matthew Scotch and Bambang Parmanto. Sovat: Spatial olap visualization and analysis
tool. In HICSS ’05: Proceedings of the Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS’05) - Track 6, page 142, 2005.
[253] Matthew Laurence Scotch. An OLAP-GIS System For Numerical-Spatial Problem Solving
in Community Health Assessment Analysis. PhD thesis, MA, Columbia University, 2002.
146
[254] Pentaho Analysis Services. Mdx specification - http://mondrian.pentaho.org/ documentation/mdx.php, Last visit, Jul 2008.
[255] Shashi Shekhar and Sanjay Chawla. Spatial Databases: A Tour. Prentice Hall, June 2002.
[256] Shashi Shekhar, Chang-Tien Lu, X. Tan, Sanjay Chawla, and Ranga Raju Vatsavai. Map
cube: A visualization tool for spatial data warehouse, 2000.
[257] Vitaly Shelest. Microsoft mdx grammar, http://www.antlr.org/grammar/1101743472259/,
[258] E.C.S. Silva and M.L.M. Campos. Integração de sistemas de informação geográficas e
ferramentas olap. In Congresso para Usuários de Geoprocessamento da América Latina,
1998.
[259] Dextra
Sistemas.
Banco
de
dados
-
a
hora
e
a
vez
do
postgresql
-
http://www.dextra.com.br/empresa/boletim/0211-01/01tecnologia.htm, Last Visit Jul
2008.
[260] Spiros Skiadopoulos and Manolis Koubarakis. Composing cardinal direction relations.
Artif. Intell., 152(2):143–171, 2004.
[261] Project Smart. Pareto analysis step by step,http://www.projectsmart.co.uk/ paretoanalysis- step-by-step.html, Last Visit Oct 2008.
[262] Miguel Soares, Nuno Santos, and Renato Fileto and. Uma aplicação olap com uma
aplicação olap com visualização cartográfica via web. In Escola Regional de Banco de
Dados, IV Escola Regional de Banco de Dados, Florianópolis, 2008.
[263] EBM Software. Ebm olap4all official home page, http://www.olap4all.com/, Last Visit
Jul 2008.
[264] Clenúbio Souza. Svql: Solap visual query language, dissertação de mestrado”. Master’s
thesis, Centro de Informática - Universidade Federal de Pernambuco, 2008.
[265] George Spofford. MDX Solutions: With Microsoft SQL Server Analysis Services. John
Wiley & Sons, 2001.
[266] R. H. Sprague. A framework for the development of decision support systems. In Management Information Systems Quarterly vol. 4 n 2, 1980.
[267] Nebojsa Stefanovic, Jiawei Han, and Krzysztof Koperski. Object-based selective materialization for efficient implementation of spatial data cubes. In IEEE Transaction on
Knowledge and Data Engineering, volume 12, pages 938–958, December 2000.
147
[268] NNebojsa Stefanovic. Design and implementation of on-line analytical processing (olap)
of spatial data, 1997.
[269] Knut Stolze. Sql/mm spatial - the standard to manage spatial data in a relational database
system. In 10th Conference on Database Systems for Business, Technology and Web,
February 2003.
[270] R. Sugumaran and J. Meyer. Building a web-based spatial decision support system (websdss) for environmental planning and management, http://dssresources.com/, Last Visit
Jul 2008.
[271] Sybase.
Adaptive server iq reference manual, http://download.sybase.com/ pdf-
docs/iqg1250e/iqref.pdf, Last Visit Jul 2008.
[272] Sybase. Sybase official home page, http://www.sybase.com.br, Last Visit Jul 2008.
[273] Sybase.
Transact-sql userś guide, http://manuals.sybase.com/onlinebooks/group-
as/asg1250e/sqlug/@generic bookview;pt=693;lang=pt? dwebquery=spatial, Last Visit
Jul 2008.
[274] Mission
Systems.
Mission
systems
official
home
page,
http://sismissionsystems.boeing.com, Last Visit Jul 2008.
[275] Mission
Systems.
Spatial
query
server
documenta-
tion,http://sismissionsystems.boeing.com/support/downloads/ sqs34212sunsyb12 0.tar,
[276] Yufei Tao and Dimitris Papadias. Historical spatio-temporal aggregation. ACM Trans.
Inf. Syst., 23(1):61–102, 2005.
[277] Kheops Techologies. Jmap solap - http://www.kheops-tech.com /fr/jmap/solap.jsp, Last
Visit Jul 2008.
[278] Teradata. Teradata official home page, http://www.teradata.com, Last Visit Jul 2008.
[279] Teradata.
Teradata warehouse, http://www.teradata.com/t/page/42711/index.html,
[280] Olivier Teste. Towards conceptual multidimensional design in decision support systems.
In Fifth East-European Conference on Advances in Databases and Information Systems,
September 2001.
[281] Dimitri Theodoratos and Timos Sellis. Designing data warehouses. Data and Knowledge
Engineering, 31(3):279–301, 1999.
148
[282] Erik Thomsen. OLAP solutions: building multidimensional information systems. John
Wiley & Sons, Inc., New York, NY, USA, 1997.
[283] Valéria Times, Robson Fidalgo, Rafael Fonseca, Joel da Silva, and Anjolina de Oliveira.
A metamodel for the specification of geographical datawarehouses. Annals of Information
Systems, http://www.springer.com/series/7573, 2008.
[284] Panos Vassiliadis and Timos Sellis. A survey of logical models for olap databases. ACM
SIGMOD Record, 28(4):64–69, 1999.
[285] Elizabeth Vitt, Michael Luckevich, and Stacia Misner. Business Intelligence. Microsoft,
2002.
[286] Agnès Voisard. Mapgets: A tool for visualizing and querying geographic information.
Journal of Visual Languages and Computing, 6(4):367–384, 1995.
[287] Angi Voß, Vera Hernandez, Hans Voß, and Simon Scheider. Interactive visual exploration
of multidimensional data: Requirements for commongis with olap. In DEXA Workshops,
pages 883–887, 2004.
[288] W3C. Xml path language (xpath) version 1.0, 1999. http://www.w3.org/TR/xpath.html.
[289] W3C. Xml pointer language (xpointer) version 1.0, 2001. http://www.w3.org/TR/WDxptr.
[290] W3C. Html - http://www.w3.org/tr/rec-html40/, Last Visit Jul 2008.
[291] W3C. Scalable vector graphics, http://www.w3.org/tr/svg11/, Last Visit Jul 2008.
[292] W3C. Soap official home page, http://www.w3.org/tr/soap/, Last Visit May 2008.
[293] W3C. Web services activity, http://www.w3.org/2002/ws/, Last Visit Jul 2008.
[294] W3C. Xml official home page, http://www.w3.org/xml/, Last Visit May 2008.
[295] Todd
Walter.
Using
teradata’s
olap
extensions,
http://www.teradata.com/
t/go.aspx/index.html?id=116328, Last Visit Jul 2008.
[296] Gerhard Weikum. Review - terraserver: A spatial data warehouse. ACM SIGMOD Digital
Review, 2, 2000.
[297] Mark Whitehorn, Robert Zare, and Mosha Pasumansky. Fast Track to MDX. Springer,
2005.
[298] R. Wrembel and C. Koncilia. Data Warehouses And Olap: Concepts, Architectures And
Solutions. IRM Press, 2006.
[299] XMLA. Xmla official home page, http://www.xmla.org/, Last Visit May 2008.
[300] Moshé M. Zloof. Query-by-example: A database language. pages 97–107.
149
APÊNDICE A
SINTAXE DA LINGUAGEM GEOMDQL
A.1
SINTAXE GEOMDQL ESPECIFICADA EM EBNF
A seguir, é apresentada a sintaxe da linguagem GeoMDQL, a qual foi definida utilizando a
notação EBNF (Extended Backus - Naur Form ) [129]. A gramática da linguagem GeoDMQL
estende a gramática da linguagem MDX [297, 72, 257, 254], provendo suporte para a manipulação de operações espaciais sobre membros geográficos.
geomdql statement : (select statement) EOF;
select statement : (WITH formula specification)?
SELECT axis specification list
FROM cube specification
(WHERE slicer specification)?
(cell props)?
(ON MAP)? ;
formula specification : (single formula specification)+ ;
single formula specification : member specification
| set specification ;
set specification : SET set name AS
( QUOTE geomdql expression QUOTE | geomdql expression ) ;
member specification : MEMBER member name AS
(( QUOTE value expression QUOTE | value expression)
(COMMA member property def list)? ) ;
axis specification list :
axis specification (COMMA axis specification)* ;
member property def list :
member property definition (COMMA member property definition)* ;
150
A.1 SINTAXE GEOMDQL ESPECIFICADA EM EBNF
member name : compound id ;
member property definition : identifier EQ value expression ;
set name : compound id ;
compound id : (identifier)=>(identifier (DOT identifier)*) |;
axis specification :
(NON EMPTY)? geomdql expression (dim props)? (ON axis name)? ;
axis name: ROWS
| COLUMNS
| PAGES
| SECTIONS
| CHAPTERS
| AXIS LPAREN axis index RPAREN
| axis index ;
dim props : (DIMENSION)? PROPERTIES property list ;
property list: property (COMMA property)* ;
property : compound id ;
cube specification: cube name ;
cube name : compound id ; cell props : (CELL)? PROPERTIES
cell property list ;
cell property list: cell property (COMMA cell property)* ;
cell property: mandatory cell property
| provider specific cell property ;
mandatory cell property: CELL ORDINAL
| VALUE
| FORMATTED VALUE;
provider specific cell property : identifier ;
slicer specification : geomdql expression ;
geomdql expression :
value expression (COLON value expression)*;
value expression: term5 (value xor expression |
value or expression)* ;
value xor expression: XOR term5 ;
151
value or expression : OR term5 ;
term5 : term4 (AND term4)* ;
term4 : NOT term4 | term3 ;
term3 : term2 (comp op term2)* ;
term2 : term ((CONCAT | PLUS | MINUS) term)* ;
term : factor ((SOLIDUS | ASTERISK) factor)* ;
factor : MINUS value expression primary
| PLUS value expression primary
| value expression primary ;
geomdql function :
identifier LPAREN (geomdql expression list)? RPAREN ;
value expression primary: value expression primary0
( DOT
( unquoted identifier
| quoted identifier
| amp quoted identifier
| geomdql function ) )*;
value expression primary0: geomdql function
| (LPAREN geomdql expression list RPAREN)
| (LBRACE (geomdql expression list)? RBRACE)
| case expression
| STRING
| numeric literal
| identifier
| member geometry ;
geomdql expression list :
geomdql expression (COMMA geomdql expression)* ;
case expression: CASE (value expression)?
(when list)?
(ELSE value expression)?
END ;
when list : when clause (when clause)* ;
when clause : WHEN value expression THEN value expression ;
152
comp op : EQ
| NE
| LT
| GT
| LE
| GE ;
operator : comp op
| MINUS
| PLUS
| SOLIDUS
| ASTERISK ;
identifier : unquoted identifier | quoted identifier ;
unquoted identifier : keyword | ID ;
amp quoted identifier: AMP QUOTED ID ;
quoted identifier: QUOTED ID ;
keyword : DIMENSION | PROPERTIES ;
axis index : NUMBER ;
member geometry : geometry ;
geometry : point geometry
| linestring gemetry
| polygon geometry
| multipoint geometry
| multilinestring geometry
| multipolygon geometry ;
point geometry : POINT point text ;
linestring gemetry : LINESTRING linestring text ;
polygon geometry : POLYGON polygon text ;
multipoint geometry : MULTIPOINT multipoint text ;
multilinestring geometry : MULTILINESTRING multilinestring text;
multipolygon geometry : MULTIPOLYGON multipolygon text ;
point text : LPAREN point RPAREN ;
point : x y ;
x : numeric literal;
y : numeric literal;
numeric literal : (MINUS|PLUS)? NUMBER (DOT NUMBER)? ;
153
linestring text : LPAREN point (COMMA point)+ RPAREN ;
polygon text : LPAREN linestring text ((COMMA linestring text)+)? RPAREN ;
multipoint text : LPAREN point text (COMMA point text)+ RPAREN;
multilinestring text :
LPAREN linestring text ((COMMA linestring text)+)? RPAREN ;
multipolygon text :
LPAREN polygon text ((COMMA polygon text)+)? RPAREN ;
AND = “AND”;
AS = “AS”;
CASE = “CASE”;
CELL = “CELL”;
CELL ORDINAL = “CELL ORDINAL”;
CREATE = “CREATE”;
DIMENSION = “DIMENSION”;
ELSE = “ELSE”;
EMPTY = “EMPTY”;
END = “END”;
FORMATTED VALUE = “FORMATTED VALUE”;
FROM = “FROM”;
GLOBAL = “GLOBAL”;
MEMBER = “MEMBER”;
NON = “NON”;
NOT = “NOT”;
ON = “ON”;
OR = “OR”;
PROPERTIES = “PROPERTIES”;
SELECT = “SELECT”;
SESSION = “SESSION”;
SET = “SET”;
THEN = “THEN”;
VALUE = “VALUE”;
WHEN = “WHEN”;
WHERE = “WHERE”;
XOR = “XOR”;
WITH = “WITH”;
FORMAT STRING = “FORMAT STRING”;
MAP = “MAP”;
154
ROWS = “ROWS”;
COLUMNS = “COLUMNS”;
PAGES = “PAGES”;
SECTIONS = “SECTIONS”;
CHAPTERS = “CHAPTERS”;
AXIS = “AXIS”;
POINT = “POINT”;
LINESTRING = “LINESTRING”;
POLYGON = “POLYGON”;
MULTIPOINT = “MULTIPOINT”;
MULTILINESTRING = “MULTILINESTRING”;
MULTIPOLYGON = “MULTIPOLYGON”;
QUOTE = “ ”;
ASTERISK = “*”;
COLON = “:”;
SEMICOLON = “;”;
COMMA = “,”;
CONCAT = “||”;
DOT = “.”;
EQ = “=”;
GE = “>=”;
GT = “>”;
LBRACE = “{”;
LE = “<=”;
LPAREN = “(”;
LT = “<”;
MINUS = “−”;
NE = “<>”;
PLUS = “+”;
RBRACE = “}”;
RPAREN = “)”;
SOLIDUS = “/”;
NUMBER : (‘0’..‘9’)+ ;
ID : (‘a’..‘z’|‘A’..‘Z’|’ ’|‘ ’) (‘a’..‘z’|‘A’..‘Z’|‘ ’|‘0’..‘9’|‘ ’)*
AMP QUOTED ID: “[&” (ID ((‘ ’)+ ID)* | NUMBER) ‘]’;
QUOTED ID: (‘[’ (ID ((‘ ’ )+ ID)* | NUMBER) ‘]’);
WS : ( ‘
’ )+;
155
APÊNDICE B
EXEMPLOS DE FUNÇÕES DE AGREGAÇÃO PARA
MEDIDAS ESPACIAIS
B.1
FUNÇÕES DO TIPO DISTRIBUTIVA ESPACIAL COM RETORNO ESCALAR
Esta categoria engloba todas aquelas funções que, quando aplicadas a um conjunto de medidas
geográficas, retornam um valor escalar. A Tabela B.1 apresenta algumas funções que tiveram
origem na combinação da função distributiva Count com os operadores topológicos, do tipo
binário booleano. Por sua vez, na Tabela B.2 são listadas as funções que tiveram origem na
combinação da função Count com as os operadores cardinais.
Na seqüência, as Tabelas B.3 e B.4 listam as funções que tiveram origem na combinação
das funções Max e Min com os operadores topológicos e cardinais. Por sua vez, na Tabela B.5
são apresentadas funções que tiveram origem na combinação das funções Max, Min e Sum com
operadores do tipo unário escalar. Outras duas funções, definidas a partir do cruzamento das
funções Max() e Min() com o operador de distância, são apresentadas na Tabela B.6
Tabela B.1 Funções Distributivas com resultado Escalar (Combinação da função Count com
operadores topológicos )
Função
Descrição
Count()
Realiza a contagem de medidas, retornando um valor escalar correspondente
ao número total de medidas.
CountTouches()
Dado um conjunto de medidas geográficas, esta função realiza a contagem de
quantos objetos tocam a medida espacial
CountCrosses()
Esta função realiza a contagem de quantos objetos cruzam a medida espacial
CountWithin()
Esta função realiza a contagem dos objetos que contem esta medida
CountOverlaps()
Esta função realiza a contagem dos objetos que sobrepõem a medida espacial
CountContains()
Realiza a contagem dos objetos que estão contidos na medida espacial
CountDisjoint()
Realiza a contagem dos objetos que estão disjuntos com relação à medida
espacial
CountIntersects()
Realiza a contagem dos objetos que intersectam a medida espacial
CountEquals()
Realiza a contagem dos objetos que são iguais a medida espacial
156
B.1 FUNÇÕES DO TIPO DISTRIBUTIVA ESPACIAL COM RETORNO ESCALAR
157
Tabela B.2 Funções Distributivas com resultado Escalar (Combinação da função Count com
operadores cardinais )
Função
Descrição
CountAt North Of()
Dado um conjunto de medidas geográficas, esta função realiza a contagem
dos objetos que estão ao norte da medida espacial
CountAt South Of()
Esta função realiza a contagem dos objetos que estão ao sul da medida espacial
CountAt East Of()
Esta função realiza a contagem dos objetos que estão ao leste da medida
espacial
CountAt West Of()
Realiza a contagem dos objetos que estão ao oeste da medida espacial
CountAt North East Of()
Realiza a contagem dos objetos que estão ao nordeste da medida espacial
CountAt North West Of()
Esta função realiza a contagem dos objetos que estão ao noroeste da medida
espacial
CountAt South East Of()
Esta função realiza a contagem dos objetos que estão ao sudeste da medida
espacial
CountAt South West Of()
Esta função realiza a contagem dos objetos que estão ao sudoeste da medida
espacial
Tabela B.3 Funções Distributivas com resultado Escalar (Combinação das funções Max e Min
com Operadores Topológicos)
Função
Descrição
MaxTouches()
Para cada medida de entrada, realiza a contagem dos objetos que tocam a esta
medida, retornando o maior valor obtido através da análise de todas as entradas
MaxCrosses()
Realiza a contagem dos objetos que cruzam esta medida, retornando o maior valor
obtido através da análise de todas as entradas
MaxWithin()
Realiza a contagem dos objetos nos quais esta medida está contida, retornando o
maior valor obtido através da análise de todas as entradas
MaxOverlaps()
Realiza a contagem dos objetos que sobrepõem esta medida, retornando o maior valor
obtido através da análise de todas as entradas
MaxContains()
Realiza a contagem dos objetos que estão contidos nesta medida, retornando o maior
valor obtido através da análise de todas as entradas
MaxDisjoint()
Realiza a contagem dos objetos que estão disjuntos com relação a presente medida,
retornando o maior valor obtido através da análise de todas as entradas
MaxIntersects()
Realiza a contagem dos objetos que estão intersectam a presente medida, retornando
o maior valor obtido através da análise de todas as entradas
MaxEquals()
Realiza a contagem dos objetos que são iguais a presente medida, retornando o maior
MinTouches()
Inverso do MaxTouches()
MinCrosses()
Inverso do MaxCrossess()
MinWithin()
Inverso do MaxWithin()
MinOverlaps()
Inverso do MaxOverlaps()
MinContains()
Inverso do MaxContains()
MinDisjoint()
Inverso do MaxDisjoint()
MinIntersects()
Inverso do MaxIntersects()
MinEquals()
Inverso do MaxEquals()
B.2 FUNÇÕES DO TIPO DISTRIBUTIVA ESPACIAL COM RETORNO ESPACIAL
158
Tabela B.4 Funções Distributivas com resultado Escalar (Combinação das funções Max e Min
com Operadores Cardinais)
Função
Descrição
MaxAt North Of()
Para cada medida de entrada, realiza a contagem dos objetos que estão ao
norte desta medida, retornando o maior valor obtido através da análise de
todas as entradas
MaxAt South Of()
Realiza a contagem dos objetos que estão ao sul desta medida, retornando o
maior valor obtido através da análise de todas as entradas
MaxAt East Of()
Realiza a contagem dos objetos que ao leste desta medida, retornando o maior
MaxAt West Of()
Realiza a contagem dos objetos que estão ao oeste desta medida, retornando
MaxAt North East Of()
Realiza a contagem dos objetos que estão ao nordeste desta medida, retornando o maior valor obtido através da análise de todas as entradas
MaxAt North West Of()
Realiza a contagem dos objetos que estão ao noroeste desta medida, retornando o maior valor obtido através da análise de todas as entradas
MaxAt South East Of()
Realiza a contagem dos objetos que estão ao sudeste desta medida, retornando
MaxAt South West Of()
Realiza a contagem dos objetos que estão ao sudoeste desta medida, retornando o maior valor obtido através da análise de todas as entradas
MinAt North Of()()
Inverso da MaxAt North Of()
MinAt South Of()
Inverso da MaxAt South Of()
MinAt East Of()
Inverso da MaxAt East Of()
MinAt West Of()
Inverso da MaxAt West Of()
MinAt North East Of()
Inverso da MaxAt North East Of()
MinAt North West Of()
Inverso da MaxAt North West Of()
MinAt South East Of()
Inverso da MaxAt South East Of()
MinAt South West Of()
Inverso da MaxAt South West Of()
Tabela B.5 Funções Distributivas com resultado Escalar (Combinação das funções Max, Min
e Sum com operadores do tipo unário escalar)
Função
Descrição
MaxArea()
Calcula a área de cada medida de entrada, retornando o maior valor
MaxPerimeter()
Calcula o perı́metro de cada medida de entrada, retornando o maior valor
MaxLength()
Calcula o comprimento de cada medida de entrada, retornando o maior valor
MinArea()
Inverso da MaxArea()
MinPerimeter()
Inverso da MaxPerimeter()
MinLength()
Inverso da MaxLength()
SumArea()
Realiza a soma de todas as áreas das medidas de entrada
SumPerimeter()
Realiza a soma de todos os perı́metros das medidas de entrada
SumLength()
Realiza a soma de todas os comprimentos das medidas de entrada
B.2
FUNÇÕES DO TIPO DISTRIBUTIVA ESPACIAL COM RETORNO ESPACIAL
Neste subgrupo estão aquelas funções de agregação que, quando aplicadas às medidas geográficas, retornam uma geometria. Na Tabela B.7 estão as funções de agregação que tiveram
B.3 FUNÇÕES DO TIPO ALGÉBRICA ESPACIAL COM RETORNO ESCALAR
159
Tabela B.6 Funções Distributivas com resultado Escalar (Combinação da funções Max e Min
com o operador de distância)
Função
Descrição
MaxDistance()
Retorna a o valor da maior da distância entre a medida corrente e os demais
medidas
MinDistance()
Retorna a o valor da menor da distância entre a medida corrente e os demais
medidas
origem da junção da operação de união de geometrias e os operadores topológicos. Por sua vez,
as funções de agregação com resultado espacial que foram obtidas através da combinação da
operação de união de geometrias e dos operadores cardinais e direcionais, são apresentadas na
Tabela B.8.
Tabela B.7 Funções Distributivas com resultado Espacial ( Combinação do operador Sum com
operadores topológicos)
Função
Descrição
Sum()
das geometrias de entrada
SumTouches()
Através da operação de união espacial, gera uma única geometria a partir das
geometrias que tocam a media espacial
SumCrosses()
Gera uma única geometria a partir das geometrias que cruzam a media espacial
SumWithin()
Gera uma única geometria a partir das geometrias em que a media corrente
está contida
SumOverlaps()
Gera uma única geometria a partir das geometrias que sobrepõem a medida
espacial
SumContains()
Gera uma única geometria a partir das geometrias que estão contidas na
presente medida
SumDisjoint()
Gera uma única geometria a partir das geometrias que estão disjuntas em
relação a medida corrente
SumIntersects()
Gera uma única geometria a partir das geometrias que intersectam a medida
espacial
SumEquals()
Gera uma única geometria a partir das geometrias que são iguais a presente
medida
B.3
FUNÇÕES DO TIPO ALGÉBRICA ESPACIAL COM RETORNO ESCALAR
Nesta categoria de funções de agregação, estão presentes as funções algébricas combinadas com
operações espaciais que retornam um resultado escalar. Na Tabela B.9, são listadas as que
tiveram origem do cruzamento das funções algébricas como Avg (média) e Stdv (desvio padrão)
com operações espaciais do tipo unário escalar (i.e. área, perı́metro e comprimento). Também
fazem parte desta categoria, as funções que foram definidas a partir do cruzamento das funções
Max N e Min N com as operações espaciais para cálculo da área, perı́metro e desvio padrão.
Estas funções são listadas na Tabela B.10. No mesmo contexto, a Tabela B.11 mostra as funções
B.3 FUNÇÕES DO TIPO ALGÉBRICA ESPACIAL COM RETORNO ESCALAR
160
Tabela B.8 Funções Distributivas com resultado Espacial ( Combinação do operador Sum com
operadores cardinais)
Função
Descrição
SumAt North Of()
das geometrias que estão ao norte da medida corrente
SumAt South Of()
Gera uma única geometria a partir das geometrias que estão ao sul da medida
espacial
SumAt East Of()
Gera uma única geometria a partir das geometrias que estão ao leste da
medida corrente
SumAt West Of()
Gera uma única geometria a partir das geometrias que estão ao oeste da
medida corrente
SumAt North East Of()
Gera uma única geometria a partir das geometrias que estão ao nordeste da
medida corrente
SumAt North West Of()
Gera uma única geometria a partir das geometrias que estão ao noroeste da
medida corrente
SumAt South East Of()
Gera uma única geometria a partir das geometrias que estão ao sudeste da
medida corrente
SumAt South West Of()
Gera uma única geometria a partir das geometrias que estão ao sudoeste da
medida corrente
resultantes da combinação das funções Min N e Max N com o operador de distância.
Tabela B.9 Funções Algébricas com resultado Escalar (Combinação das funções Avg e Stdv
com operadores do tipo unário escalar)
Função
Descrição
AvgArea()
Retorna a área média de um conjunto de medidas espaciais
AvgPerimeter()
Retorna o perı́metro médio de um conjunto de medidas
AvgLength()
Calcula o comprimento médio de um conjunto de medidas
StdvArea()
Calcula o desvio padrão das áreas de um conjunto de medidas espaciais
StdvPerimeter()
Calcula o desvio padrão dos perı́metros de um conjunto de medidas espaciais
StdvLength()
Calcula o desvio padrão dos comprimentos de um conjunto de medidas espaciais
Tabela B.10 Funções Algébricas com resultado Escalar (Combinação das funções Min N e
Max N com operadores do tipo unário escalar)
Função
Descrição
MaxNArea()
Retorna as N maiores áreas de um conjunto de medidas espaciais
MaxNPerimeter()
Retorna os N maiores perı́metros de um conjunto de medidas
MaxNLength()
Calcula e retorna os N maiores comprimentos de um conjunto de medidas
MinNArea()
Retorna as N menores áreas de um conjunto de medidas espaciais
MinNPerimeter()
Retorna os N menores perı́metros de um conjunto de medidas
MinNLength()
Calcula e retorna os N menores comprimentos de um conjunto de medidas
161
B.4 FUNÇÕES DO TIPO ALGÉBRICA ESPACIAL COM RETORNO ESPACIAL
Tabela B.11 Funções Algébricas com resultado Escalar (Combinação das funções Min N e
Max N com o operador de distância)
Função
Descrição
MaxNDistance()
Para cada medida de entrada, esta função retorna as N maiores distâncias
MinNDistance()
Para cada medida de entrada, esta função retorna as N menores distâncias
B.4
FUNÇÕES DO TIPO ALGÉBRICA ESPACIAL COM RETORNO ESPACIAL
As principais funções definidas para este grupo são apresentadas na Tabela B.12. Neste grupo
estão as funções que tiveram origem no cruzamento das funções MinN e MaxN com os operadores cardinais. O objetivo deste grupo de funções é responder consultas do tipo:
Quais são
os N objetos geográficos que estão mais ao norte de um dada medida espacial.
Tabela B.12 Funções Algébricas com resultado Espacial (Combinação das funções Min N e
Max N com operadores cardinais)
Função
Descrição
MaxNAt North Of()
Para cada medida de entrada, retorna a geometria dos N objetos que estão
mais ao norte da medida corrente
MaxNAt South Of()
Retorna a geometria dos N objetos que estão mais ao sul da medida corrente
MaxNAt East Of()
Retorna a geometria dos N objetos que estão mais ao leste da medida corrente
MaxNAt West Of()
Retorna a geometria dos N objetos que estão mais ao oeste da medida corrente
MaxNAt North East Of()
Retorna a geometria dos N objetos que estão mais ao nordeste da medida
corrente
MaxNAt North West Of()
Retorna a geometria dos N objetos que estão mais ao noroeste da medida
corrente
MaxNAt South East Of()
Retorna a geometria dos N objetos que estão mais ao sudeste da medida
corrente
MaxNAt South West Of()
Retorna a geometria dos N objetos que estão mais ao sudoeste da medida
corrente
MinNAt North Of()()
Inverso da MaxNAt North Of()
MinNAt South Of()
Inverso da MaxNAt South Of()
MinNAt East Of()
Inverso da MaxNAt East Of()
MinNAt West Of()
Inverso da MaxNAt West Of()
MinNAt North East Of()
Inverso da MaxNAt North East Of()
MinNAt North West Of()
Inverso da MaxNAt North West Of()
MinNAt South East Of()
Inverso da MaxNAt South East Of()
MinNAt South West Of()
Inverso da MaxNAt South West Of()
B.5 FUNÇÕES DO TIPO HOLÍSTICA ESPACIAL COM RETORNO ESCALAR
B.5
162
FUNÇÕES DO TIPO HOLÍSTICA ESPACIAL COM RETORNO ESCALAR
Nesta categoria estão as funções que, quando aplicadas a um conjunto de medidas espaciais geram um resultado escalar. Como exemplo, na Tabela B.13, listamos alguns exemplos
de funções que tiveram origem na combinação das funções holı́sticas rank, mediana e moda
com operadores espaciais do tipo unário escalar, como aqueles utilizados para cálculo da área,
perı́metro e comprimento.
Tabela B.13 Funções Holı́sticas com resultado Escalar (Combinação da função rank com operadores espaciais do tipo unário escalar)
Função
Descrição
RankArea()
Ordena as medidas pela área, da maior para a menor
RankPerimeter()
Ordena as medidas pelo perı́metro, do maior para o menor
RankLength()
Ordena as medidas pelo comprimento, do maior para o menor
MedianArea()
Calcula a área mediana do conjunto de medidas
MedianPerimeter()
Calcula o perı́metro mediana do conjunto de medidas
MedianLength()
Calcula o comprimento mediano do conjunto de medidas
ModeArea()
Calcula a área que aparece com maior freqüência no conjunto de medidas
ModePerimeter()
Calcula o perı́metro que aparece com maior freqüência no conjunto de medidas
(também chamado de moda)
ModeLength()
Calcula o comprimento que aparece com maior freqüência no conjunto de
medidas
B.6 FUNÇÕES DO TIPO HOLÍSTICA ESPACIAL COM RETORNO ESPACIAL
B.6
163
FUNÇÕES DO TIPO HOLÍSTICA ESPACIAL COM RETORNO ESPACIAL
Neste grupo de funções, estão presentes resultantes da combinação de funções holı́sticas com
operadores espaciais. Na Tabela B.14, apresentamos alguns exemplos de funções holı́sticas
com retorno espacial. As função NNearestNeighbor e NDistantNeighbor funcionam de forma
semelhante às apresentadas na Tabela B.11, com o diferencial de retornar a geometria dos
objetos geográficos relacionados. A função NGeoGrouping pode ser implementada utilizando
o algoritmo de K-means [7] para gerar N agrupamentos a partir de um conjunto de dados de
entrada. Por sua vez, a função Voronoi() retorna um conjunto de feições geográficas que formam
o diagrama de Voronoi [87] a partir de um conjunto de pontos de entrada.
Tabela B.14 Funções Holı́sticas com resultado Espacial
Função
Descrição
NNearestNeighbor()
Retorna a geometria dos N vizinhos mais próximos
NDistantNeighbor()
Retorna a geometria dos N vizinhos mais distantes
NGeoGrouping()
Agrupa os objetos de entrada em N e retorna a geometria dos mesmos
Voronoi()
Retorna o diagrama de Voronoi resultante do processamento dos objetos geográficos de entrada
APÊNDICE C
EXEMPLOS DE CONSULTA GEOMDQL
C.1
EXEMPLOS DE CONSULTA NA LINGUAGEM GEOMDQL
Com base na aplicação prática desenvolvida na nossa abordagem, a qual foi apresentada na
Seção 6.4, nas seção a seguir apresentaremos mais alguns exemplos de consultas na sintaxe
GeoMDQL, juntamente com o resultado obtido com o processamento.
C.1.1
Consultas MD
Nesta seção, serão apresentadas algumas consultas do tipo MD. Um consulta MD não inclui
nenhum operador espacial. Apenas são utilizados os operadores multidimensionais e o resultado
obtido sempre é visualizado através de tabelas, gráficos sem a utilização de mapas nem operadores espaciais. Os gráficos são sempre gerados automaticamente pelo componente de interface
gráfica, ficando a critério do usuário, exibi-lo ou não.
CONSULTA 9 (Mostrar quais são os cinco estados brasileiros com maior número
de óbitos neonatais, juntamente com o subtotal que corresponde à soma das
quantidades destes 5 estados, à soma das quantidades dos outros estados e, por
fim, o total geral de óbitos neonatais envolvendo todos os estados).
WITH SET [Os5Mais]
AS ‘TopCount([Localizacao].[Estado].Members, 5.0, [Measures].[Obitos Neonatais])’
MEMBER [Localizacao].[Sub Total] AS ‘Sum([Os5Mais])’
MEMBER [Localizacao].[Todos os Outros]
AS ‘([Localizacao].[Todos] - [Localizacao].[Sub Total])’
MEMBER [Localizacao].[Total Geral] AS ‘[Localizacao].[Todos]’
SELECT [Measures].[Obitos Neonatais] ON COLUMNS,
Hierarchize([Os5Mais], [Localizacao].[Sub Total],[Localizacao].[Todos os Outros],
[Localizacao].[Total Geral]) ON ROWS
FROM [BRSaude]
Especificamos a Consulta 9 para demonstrar um pouco do potencial de análise disponı́vel
na linguagem GeoMDQL. Como já foi dito anteriormente, todas as funcionalidades de análise
multidimensional foram herdadas da linguagem MDX por esta ser uma linguagem desenvolvida
164
C.1 EXEMPLOS DE CONSULTA NA LINGUAGEM GEOMDQL
165
Figura C.1 Exemplo de Consulta MD com TopCount e Membros Calculados
especificamente para utilização em ambientes OLAP. Na Consulta 9, utilizamos o operador
TopCount para criar um conjunto contendo os 5 estados com maior número de óbitos neonatais.
Criamos também três membros calculados para representar, respectivamente, a soma dos óbitos
neonatais dos elementos do conjunto Os5Mais ([Localizacao].[Sub Total]), a soma dos óbitos
neonatais de todos os estados que não pertencem ao conjunto Os5Mais ([Localizacao].[Todos
os Outros]) e a soma total óbitos neonatais de todos os estados brasileiros ([Localizacao].[Total
Geral]). O operador Hierarchize foi aplicado sobre os membros das linhas para garantir que a
hierarquia fosse mantida, ou seja, sem este operador, os membros seriam ordenados do maior
para o menor (considerando a quantidade de óbitos neonatais), desconsiderando a hierarquia
previamente definida. O resultado da execução da consulta 9 pode ser visualizado na Figura
C.1. O resultado é representado na forma de gráfico e de tabelas e o usuário pode utilizar este
resultado para formular novas consultas.
CONSULTA 10 (Mostrar quais são os anos que concentram 50% do total
de óbitos menores de um ano, e para cada um destes anos, mostrar quais são
os estados que juntos correspondem a 30% do total de óbitos menores de um ano ).
166
SELECT [Measures].[Obitos Menores de Um Ano] ON COLUMNS,
Generate( TopPercent([Tempo].[Ano].Members, 50.0,
[Measures].[Obitos Menores de Um Ano]),
Crossjoin( [Tempo].CurrentMember, [Localizacao].[Todos],
TopPercent( [Localizacao].[Estado].Members, 30.0,
[Measures].[Obitos Menores de Um Ano]))) ON ROWS
FROM [BRSaude]
Figura C.2 Exemplo de Consulta MD com Análise de Pareto
Para especificar a Consulta 10, foram utilizados os operadores Generate, Crossjoin e TopPercent. O operador Generate aplica um conjunto a cada membro de outro conjunto e em
seguida faz a união dos conjuntos resultantes. O operador Crossjoin é utilizado para retornar o
produto cartesiano de dois ou mais conjuntos. Por sua vez, TopPercent é utilizado para aplicar
a análise de Pareto (também conhecida como a regra dos 80-20) [261] sobre um conjunto de
dados. O resultado da Consulta 10 pode ser visualizado na figura C.2.
Como pode ser observado nesta seção, com as consultas 9 e 10, fica claro o potencial de
167
análise multidimensional disponı́vel em uma linguagem que foi desenvolvida especificamente
para ambientes de suporte à decisão e otimizada para consultas OLAP. Este poder de análise
aumenta consideravelmente com a adição de operadores espaciais, o que será demonstrado nas
consultas exibidas nas próximas seções.
C.1.2
Consultas GeoMD de Mapeamento
Nesta seção, serão apresentadas consultas do tipo GeoMD de mapeamento. O diferencial principal destas consultas, em relação às consultas MD, está na utilização da cláusula ON MAP.
Com esta cláusula, nosso mecanismo de processamento SOLAP processa a consulta e gera automaticamente as requisições para recuperar as correspondências geográficas de todos os membros
de dimensões geográficas envolvidos na consulta.
CONSULTA 11 (Mostrar quais são os anos que concentram 60% do total de óbitos
menores de um ano, e para cada um destes anos, mostrar quais são os estados que
juntos correspondem a 50% do total de óbitos menores de um ano, mostrando as
informações em tabelas, gráficos e mapas).
SELECT [Measures].[Obitos Menores de Um Ano] ON COLUMNS,
Generate(TopPercent([Tempo].[Ano].Members, 60,
[Measures].[Obitos Menores de Um Ano]),
Crossjoin([Tempo].CurrentMember, [Localizacao].[Todos],
TopPercent([Localizacao].[Estado].Members, 50,
[Measures].[Obitos Menores de Um Ano]))) ON ROWS
FROM [BRSaude] ON MAP
A Consulta 11 é nosso primeiro exemplo de consulta de mapeamento. A principal diferença
desta consulta com relação à Consulta 10, está na utilização da cláusula ON MAP, que faz com
que as geometrias de todos os membros de dimensões geográficas envolvidas na consulta sejam
recuperadas e um mapa seja exibido para incrementar a análise do resultado. O resultado da
Consulta 11 é exibido na figura C.3.
CONSULTA 12 (Mostrar a quantidade de Nascidos Vivos e a quantidade de Óbitos
Neonatais para cada região brasileira, para os anos de 2000 e 2001 ).
SELECT Crossjoin([Tempo].[Todos].[2000], [Tempo].[Todos].[2001],
[Measures].[Nascidos Vivos], [Measures].[Obitos Neonatais])ON COLUMNS,
[Localizacao].[Regiao].Members ON ROWS FROM [BRSaude] ON MAP
Temos a Consulta 12 como outro exemplo de consulta de mapeamento. Nela utilizamos o operador Crossjoin para fazer com que, para cada um dos anos (i.e. 2000 e 2001), seja recuperada
168
Figura C.3 Exemplo de Consulta GeoMD de Mapeamento com Análise de Pareto
a quantidade de nascidos vivos e a quantidade de óbitos neonatais. Como pode ser observado
na figura C.4, o resultado é exibido no formato de tabela, gráfico e mapa. Opcionalmente, com
as funcionalidade disponı́veis na interface gráfica, o usuário pode adicionar pequenos gráficos
sobre cada membro geográfico que compõe o mapa (ver mapa da figura C.4). Estes gráficos são
criados pela aplicação a partir dos fatos resultantes da consulta.
C.1.3
Consultas GeoMD de Integração
Nesta seção serão apresentadas as consultas de integração. Uma consulta de integração é aquela
que possui operadores multidimensionais e geográficos. Consideramos esta categoria de consultas a mais interessante, pois é com elas que ocorre a integração de operadores multidimensionais
e geográficos. Dessa forma, apresentaremos aqui um maior número de consultas, utilizando os
operadores que foram desenvolvidos especificamente para a linguagem GeoMDQL.
Uma consulta de integração pode ser especificada de duas formas: i) utilizando a cláusula
ON MAP, para que o resultado seja exibido em mapas (quando os dados retornados possuı́rem
alguma correspondência geográfica) ou ii) sem a utilização da cláusula ON MAP, onde o pro-
169
Figura C.4 Exemplo de Consulta GeoMDQL de Mapeamento
cessamento ocorrerá da mesma forma que na anterior, entretanto, os resultados serão exibidos
somente em tabelas, e opcionalmente em gráficos, sem a utilização de mapas.
CONSULTA 13 (Para cada estado das Regiões Sul, Centro Oeste e Nordeste,
mostrar a população no ano de 2002, juntamente com a posição de cada estado no
ranking geral da população (que considera os 27 estados brasileiros), e também a
posição de cada estado no ranking que mede a área geográfica de cada estado. Os
dados com correspondência geográfica devem ser exibidos no mapa).
WITH SET [Estados Ordenados Por Area]
AS ‘RankArea([Localizacao].[Estado].Members)’
MEMBER [Measures].[Ranking Area]
AS ‘Rank([Localizacao].CurrentMember, [Estados Ordenados Por Area])’
SET [Estados Ordenados Por Populacao]
AS ‘Order([Localizacao].[Estado].Members, [Measures].[Populacao],BDESC)’
MEMBER [Measures].[Ranking Populacao]
170
AS ‘Rank([Localizacao].CurrentMember, [Estados Ordenados Por Populacao])’
SELECT [Measures].[Populacao], [Measures].[Ranking Area],
[Measures].[Ranking Populacao] ON COLUMNS,
Union(Union([Localizacao].[Todos].[Brasil].[Nordeste].Children,
[Localizacao].[Todos].[Brasil].[Centro Oeste].Children),
[Localizacao].[Todos].[Brasil].[Sul].Children) ON ROWS FROM
[BRSaude] WHERE [Tempo].[Todos].[2002] ON MAP
Figura C.5 Ranking de Área e de População
Para resolver a consulta 13, aplicamos o operador GeoMDQL RankArea para ordenar todos
os membros do nı́vel Estado, criando um conjunto contendo todos os estados ordenados da maior
área para a menor (i.e. [Estados Ordenados Por Area] ), o que é feito com o operador SET.
Em seguida, aplicamos o operador Rank para gerar, para cada estado, a posição no ranking
geral e criar um novo membro com o operador MEMBER. De forma semelhante, utilizamos
o operador Order para criar um conjunto de todos os membros do nı́vel estado ordenados
pela quantidade da população. A instrução BDESC, utilizada em conjunto com o operador
Order indica que a ordenação será em ordem crescente e que a hierarquia original do cubo
não será considerada. Assim, utilizando o operador MEMBER é criado um novo membro que
armazena a posição de cada estado no ranking global de população. O fato que representa a
171
população de cada estado (i.e. [Measures].[Populacao] ), a posição de cada estado no ranking
da área (i.e. [Measures].[Ranking Area] ) e a posição de cada estado no ranking da população
(i.e. [Measures].[Ranking Populacao] ) são adicionados no eixo coluna (ON COLUMNS) e cada
estado das regiões solicitadas (i.e. Sul, Centro Oeste e Nordeste) são adicionados no eixo linha
(ON ROWS). Para listar os estados de cada região, foi utilizado o operador Children, que
recupera todos os filhos de um determinado membro. Por fim, para restringir o resultado para
os dados do ano 2002 utilizamos a restrição [Tempo].[Todos].[2002] na cláusula WHERE e
a instrução ON MAP indica ao processador que os dados geográficos precisam ser retornados
juntamente com o resultado da consulta e o mapa que contextualiza tal resultado, precisa ser
exibido no mapa.
Salientamos que os operadores Union, utilizados na consulta para unir os conjuntos
formados pelos estados de cada região, poderiam ser substituı́dos por um conjunto pelos caracteres { e }, sendo estruturado da seguinte forma: { {[Localizacao].[Todos].[Brasil].
[Nordeste].Children}, {[Localizacao].[Todos].[Brasil].
[Centro Oeste].Children}, { [Localiza-
cao].[Todos].[Brasil].[Sul].Children}}.
O resultado da consulta 13 pode ser visualizado na figura C.5.
CONSULTA 14 (Para o ano de 2002, mostrar a quantidade de nascidos vivos
e a quantidade de nascidos abaixo do peso, nos estados brasileiros vizinhos de
Pernambuco, em que a quantidade de habitantes for superior a 10.000.000).
SELECT [Measures].[Nascidos Vivos], [Measures].[Nascidos Vivos Abaixo do Peso],
[Measures].[Obitos Maternos], [Measures].[Obitos Neonatais] ON COLUMNS,
INTERSECT(DRILLOUT([Localizacao].[Estado].[PERNAMBUCO]),
FILTER([Localizacao].[Estado].Members, ([Measures].[Populacao] > 10000000))) ON ROWS
Dando seqüência aos exemplos de consultas de integração, temos a consulta 14. Esta consulta deixa claro a flexibilidade da linguagem GeoMDQL para a utilização simultânea de operadores multidimensionais e geográficos. Da mesma forma semelhante à realizada na consulta
3, o operador Drillout é utilizado na consulta 14 para recuperar os vizinhos do estado de Pernambuco. Entretanto, é utilizado o operador Intersect, passando como parâmetro o resultado
do operador Drillout e o resultado do operador Filter, que recupera somente os estados com
população superior a 10 milhões, para retornar a intersecção dos dois conjuntos. Dessa forma,
somente o membro que representa o estado da Bahia será retornado, como pode ser visualizado
na figura C.6. Como pode ser observado nesta figura, com as funcionalidades disponı́veis na
interface gráfica, foram adicionados ao mapa gráficos para demonstrar graficamente os valores
dos que representam o número de nascidos vivos (i.e. [Measures].[Nascidos Vivos]) e o número
de nascidos vivos abaixo do peso (i.e. [Measures].[Nascidos Vivos Abaixo do Peso]).
172
Figura C.6 Drillout Filter e Intersects
CONSULTA 15 (Para as meso regiões com população acima de 300.000 habitantes
no ano de 2002, pertencentes ao estado brasileiro de maior área geográfica, mostrar
a quantidade de nascidos vivos e a quantidade de óbitos maternos ).
SELECT [Measures].[Nascidos Vivos], [Measures].[Obitos Maternos] ON COLUMNS,
Filter(DrilldownLevel(MaxArea([Localizacao].[Estado].Members)),
([Measures].[Populacao] > 300000)) ON ROWS
Na consulta 15, o diferencial é a utilização do operador MaxArea, da linguagem GeoMDQL.
Com este operador é recuperado o estado brasileiro de maior área geográfica (i.e. Amazonas).
Em conjunto, é utilizado o operador DrilldownLevel para descer um nı́vel na hierarquia a qual
pertence o nı́vel Estado, recuperando assim o nı́vel que contem as meso regiões de cada estado.
Para filtrar o resultado, retornando somente as meso regiões com população acima de 300 mil,
utilizamos o operador Filter. A figura C.7 exibe a tabela e o mapa resultantes do processamento
da consulta.
CONSULTA 16 (Para o ano de 2002, mostrar a quantidade de nascidos vivos
e a quantidade de nascidos abaixo do peso dos estados que estão localizados
173
Figura C.7 Exemplo de Consulta com o operador MaxArea
ao nordeste do Distrito Federal mas que não têm intersecção com o estado de
Pernambuco).
SELECT [Measures].[Nascidos Vivos],
[Measures].[Nascidos Vivos Abaixo do Peso] ON COLUMNS,
Intersect(AtNorthEastOf([Localizacao].[Estado].Members,
[Localizacao].[Estado].[DISTRITO FEDERAL]),
Disjoint([Localizacao].[Estado].Members,
[Localizacao].[Estado].[PERNAMBUCO])) ON ROWS
FROM [BRSaude] WHERE [Tempo].[Ano].[2002]
Como outro exemplo de integração entre operadores multidimensionais e geográficos, temos
a consulta 16. Nesta consulta, o operador AtNorthEastOf é utilizado para recuperar todos os
estados brasileiros que estão localizados geograficamente ao nordeste do Distrito Federal. Como
complemento, o operador GeoMDQL Disjoint é utilizado para recuperar somente os estados que
não fazem divisa com o estado de Pernambuco. Dessa forma, o operador Intersect é utilizado
para fazer a intersecção dos resultados, retornando assim, somente os estados que estão ao
nordeste do Distrito Federal e não fazem divisa com Pernambuco. O Resultado desta consulta
174
pode ser conferido na figura C.8. Como podemos perceber, somente os estados do Rio Grande
do Norte e Sergipe atendem às restrições. Sobre o mapa com estes estados, foi adicionado um
pequeno gráfico do tipo pizza para representar graficamente o número de nascidos vivos e de
nascidos vivos abaixo do peso.
Figura C.8 Exemplo de consulta de integração com os operadores Intersect, Disjoint e AtNorthEastOf
175
CONSULTA 17 (Para o ano de 2002, mostrar a quantidade de nascidos vivos,
a quantidade de nascidos abaixo do peso para todos os estados que possuem
intersecção geográfica com o estado de Pernambuco).
SELECT [Measures].[Nascidos Vivos],
[Measures].[Nascidos Vivos Abaixo do Peso] ON COLUMNS,
GeoIntersects([Localizacao].[Estado].Members,
[Localizacao].[Estado].[PERNAMBUCO]) ON ROWS
Por sua vez, na consulta 17, é utilizado o operador GeoIntersects da linguagem GeoMDQL
para recuperar os estados que intersectam geograficamente a geometria correspondente ao estado
de Pernambuco. O resultado desta consulta é exibido na figura C.9.
Figura C.9 Exemplo de Consulta de integração utilizando o operador GeoIntersects

GeoMDQL - Centro de Ciências Exatas e Tecnologia

Transcrição

Documentos relacionados

Brochura - GstarCAD

Introd. Prog. Java com NetBeans

AMU - Ambiente de Multiprocessamento para Unix

Apostila de Introduç˜ao ao Microsoft Excel 2010R

- Maclinea

Aula 12 - Programa de Engenharia Elétrica

isotat - home page

Inteligência na investigação pessoal e patrimonial

imprimir mapa - buffet andreazza

Circuitos Lógicos Aula 7