Towards a Logical Multidimensional Model for Spatial Data Warehousing and OLAP Marcus Costa Sampaio André Gomes de Sousa Cláudio de Souza Baptista

Transcription

1 Towards a Logical Multidimensional Model for Data Warehousing and OLAP Marcus Costa Sampaio André Gomes de Sousa Cláudio de Souza Baptista Information System Laboratory - LSI, Federal University of Campina Grande - UFCG Aprigio Veloso, 882, Bodocongó, , Campina Grande, PB, Brazil sampaio@dsc.ufcg.edu.br andre@dsc.ufcg.edu.br baptista@dsc.ufcg.edu.br ABSTRACT Decision support systems (DSS) may be enhanced qualitatively if they are able to also deal with spatial dimensions and measures. Regardless the evident importance of using data warehousing and OLAP in DSS, the incorporation of spatial dimensions and measures enables to locate more efficiently tendencies in a given application domain, by using dynamic maps with zooming, panning, aggregation and other spatial functionalities. Therefore, it is necessary to converge two relatively consolidated technologies: Data Warehousing and Geographical Information Systems. This integration gives raise to a new research area called Data Warehousing (SDW), which introduces new research challenges. This paper proposes a novel logical multidimensional model suitable for SDW, which is implemented on the top of an object-relational database system with support for spatial data. Moreover, the paper addresses query optimization techniques to enhance performance and it describes a prototype, which has been built to validate the proposed ideas. Categories and Subject Descriptors H.2.1 [Database Management]: Logical Design Data models, Schema and subschema. H.2.2 [Database Management]: Physical Design Access methods. H.2.8 [Database Management]: Database Applications databases and GIS, Statistical databases. General Terms Algorithms, Design. Keywords OLAP, Data, Data Warehousing, Multidimensional Model, Data Modeling. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DOLAP 06, November 10, 2006, Arlington, Virginia, USA. Copyright 2006 ACM /06/ $ INTRODUCTION Decision support systems aim to identify historical and localizable tendencies, behaviors and information patterns, which help the decision support process. The technologies that underpin this process, using time and space as essential elements, are Data Warehousing (DW) with OLAP interface, and Geographical Information Systems (GIS). DW/OLAP is responsible for symbolic data extraction from operational sources and its organization according to a multidimensional model. On the other side, GIS provide manipulation, storage and visualization of spatial data. DW (SDW) naturally results from the convergence of these two technologies. Research on SDW is still incipient due to two main reasons: first, although DW/OLAP and GIS technologies are consolidated, when taken into account individually, the incorporation of the spatial context in a multidimensional model is peculiar, complex and challenging; second, SDW still lacks of an expressive market [2]. More recently, some conceptual models for SDW have appeared [1, 2, 7], to the detriment of logical models. If, on one hand, conceptual models are possibly more flexible, on the other hand they are not immediately operational, and therefore lack of a concept-proof, or validation. This paper proposes a novel logical multidimensional model suitable for SDW. The reason for this choice is that SDW implementation brings interesting open problems, related to spatial multidimensional query performance. The model tightly integrates DW/OLAP and GIS, and is constructed on the top of Oracle Object-relational (OR) DBMS, using the Oracle extension. OR technology surmounts the difficulties of the relational technology by dealing with pointers and non-atomic tables [9], two essential elements of the proposed model. Oracle enables the storage, spatial aggregation, efficient retrieval and manipulation of spatial data [11]. However Oracle does not provide spatial analysis for multidimensional data. To the best of our knowledge there is no SDW commercially available. The paper has two other main contributions: (1) the proposal of a logical spatial query optimizer; and (2) a prototype, MapWarehouse, which aims to validate the proposed ideas. A case study on agricultural crops in Brazil is discussed throughout the paper. In order to have an efficient seed distribution policy to Brazilian farmers, several issues ought to be taken into account including soil and plantation types, precipitation and location. Hence, a SDW may help authorities in finding the best policy for a particular situation, based on

2 dynamic maps, tables, graphics, reports and so on, according to different aggregation criteria. As it can be noticed, this application encompasses both spatial and symbolic dimensions, spatial and numerical measures, and time. Related work is discussed in section 2. Section 3 focuses on the logical spatial multidimensional model. Section 4 highlights the MapWarehouse s logical spatial query optimizer. Experimental results with MapWarehouse are presented in section 5. The paper ends with discussion on current achievements and further research. 2. RELATED WORK The provision of efficient OLAP operations in SDW is challenging. Three recent works on SDW [1, 2, 7] concern only conceptual models, therefore they do not discuss aspects related to model implementation; in particular, the question of efficiently implementing spatial roll up and drill down OLAP operations remains an open issue. Damiani and Spaccapietra introduce a novel spatial data multidimensional model for spatial objects [2]. The novelty of the model is the representation of spatial measures at multiple levels of geometric granularity. The model includes a set of OLAP operators supporting the navigation across dimension and measure levels. Bimonte et al. [1] define the requirements for a single spatial multidimensional data model i.e. tightly integrating spatial and numerical measures as well as a multidimensional data model which is able to support complex objects as measures and ad-hoc aggregation functions, in order to handle geographical data. However, spatial analysis operators have not been defined. Malinowski and Zimanyi [7] present a conceptual multidimensional model based on the Entity Relationship modeling paradigm. The basic representation constructs are those of fact relationship and spatial dimension. However, the model only focuses on the representation constructs. Han et al. present a seminal paper which addresses a logical multidimensional model, introducing the concepts of spatial dimension and spatial measure [5]. A prototype, GeoMiner, has been developed, in order to validate the ideas. Nevertheless, its query module is very incipient: spatial OLAP operations like spatial roll up / drill down are not provided. Materialized views can provide massive improvements in query processing time, especially for aggregation queries over large datasets. To realize these improvements, the query optimizer must know how and when to exploit materialized views. Goldstein and Larson [3] present a fast and scalable algorithm for determining whether part or all of a query can be rewritten in terms of materialized views and describe how it can be incorporated in transformation-based optimizers. Unfortunately, the algorithm only concerns numerical measures. Geometric measure management is challenging as geometric objects tend to be large. Thus it is an open problem to efficiently create geometric materialized views without causing the problem known as explosion of aggregates [6]. Zhang et al. propose an approach for enabling spatial data manipulation into OLAP systems [12]. A spatial index mechanism is employed to derive pre-aggregation and materialization of spatial hierarchies, which in turn are leveraged by OLAP system to efficiently answer OLAP queries along spatial hierarchies. A serious restriction of the underlying multidimensional model with both non spatial and spatial dimensions is that it does not support spatial measures. measure, admittedly, is the best way to introduce spatial information in decisional process, i.e., using it as analysis object or as a fact spatial measure can then be analyzed through non-spatial and spatial dimensions. 3. THE MULTIDIMENSIONAL MODEL Our data model is specified at the logical level, in particular in terms of an extended star schema, with the extensions consisting of: (1) object-relational concepts and structures; and (2) spatial components. First of all, it is pertinent to discuss the concept of spatial data and spatial aggregation, in the context of the MapWarehouse project. Data The term is used in the geographical sense: any spatial data has a coordinate system associated with it. The coordinate system is geo-referenced: longitude/latitude related to a specific location in the Earth. Aggregation Regarding the case study, crop areas are localized inside municipality areas, municipality areas are localized inside micro-region areas, and so on. Only the vector representation is used for spatial data. The spatial features are OGC Simple Features for SQL compliant [8]. data is stored and manipulated by Oracle 10g as a georeferenced object of SDO_GEOMETRY type, which supports primitive objects, such as point, polygon and linestring, or any collection of those [11]. Crop areas are represented by an object of the type SDO_GEOMETRY, indicating a collection of points, while municipality, micro-region, region and state geometries are single polygons. It is a spatial data representing a summarization of spatial data. Oracle aggregate functions aggregate the results of SQL queries involving geometry objects. Several spatial aggregate functions are supported by Oracle : center of gravity, concatenation, convex hull, minimum bounding and spatial union. For lack of space, we consider in this paper only the spatial union operation: CREATE TYPE sdoaggrtype AS OBJECT ( geometry SDO_GEOMETRY, tolerance NUMBER) SDO_AGGR_UNION( AggregateGeometry sdoaggrtype ) RETURN SDO_GEOMETRY where tolerance is used to associate a level of precision with spatial data, returns a geometry object that is the spatial union (OR operation) of the specified geometry objects. Returning to the case study, it is interesting for example to show crop areas inside a micro-region geometry as the spatial union of the crop areas of all municipalities in the micro-region geometry.

3 SDW is conceptually viewed as a spatial cube composed of both spatial and non-spatial measures, and with spatial and nonspatial dimensions, attributes, hierarchies and levels (figure 1). Level Level classes define geometries that represent a position in a class Hierarchy. The classes at different levels have a 1:N parentchild relationship. measures in a spatial cube are at the bottom level (or most basic level) of spatial hierarchies. Crop areas is related to Municipality; Municipality is the bottom level of the spatial hierarchy Municipality N 1 Micro-region N 1 Region N 1 State of the spatial dimension Municipality. Cube Measure Dimension Attribute Figure 1: Multidimensional Meta-model Cube classes described by the metaclass Cube in figure 1 provide a means of organizing both spatial and non-spatial measures that have the same dimensions. Indeed, the metaclass Cube extends the meta-class Nonspatial Cube with spatial measure, spatial dimension, spatial attribute, spatial hierarchy and spatial level meta-classes (gray boxes in figure 1). The case study is represented by the singleton Cube Agro-Distribution. Objects of Measure classes populate the cells of objects of Cube classes for the spatial facts collected about business operations. Objects of class Crop areas in Agro-Distribution are collections of spatial measures. Dimension classes define aggregation criteria for both spatial and non-spatial measures. Attribute and Hierarchy classes compose Dimension classes. Because measures are typically multidimensional, a measure must be qualified by each dimension to be meaningful more precisely, each object of the class Measure is associated with one and only one object of each class Dimension. Agro-Distribution has the class Municipality as its spatial dimension. Attribute classes provide additional spatial information about Dimension classes. The class Micro-region is a spatial attribute of Municipality. 3.1 Viewing Data for Analysis In viewing data, analysts use spatial hierarchies to recognize trends at one spatial level, drill down to lower spatial levels to identify reasons for these trends, and roll up to higher levels to see which effects these trends have on a larger sector of the business. Other two OLAP operations that can be performed in a spatial data cube are: slicing and dicing, each of which selects a portion of the spatial cube according to selection criteria; and pivoting, which presents the spatial measures in different crosstabular layouts. All these spatial OLAP operations can easily be simulated in terms of standard OR SQL constructions, and with the help of the Oracle aggregate functions and spatial operators (OR SQL examples of the spatial roll up / drill down operations are further presented). 3.2 OR Star Schemata cubes are implemented in MapWarehouse under the form of spatial OR star schemata. A OR Star Schema, syntactically similar to the Kimball s star schema [6], is a set of Oracle non-atomic object tables [9], where one of the object tables represents the spatial and non-spatial measures OR spatial fact table, and the other ones represent the dimensions of the spatial cube, respectively OR dimension tables, with embedded spatial hierarchies. Repeated large spatial objects in both spatial fact and dimension tables are always referenced (Oracle REF type). Without loss of generality, we show how to define an spatial OR star schema through the running example. The elements of the schema are: spatial dimension type and table Municipality, with the spatial hierarchy municipality N 1 microregion N 1 region N 1 state; non-spatial dimensions types and respective tables Time, Plantation, Soil and Precipitation, and spatial fact type and table AgroDistribution. Figure 2 is a sketch of the AgroDistribution spatial OR star schema. Hierarchy Hierarchy classes are a way to organize spatial measures at different levels of spatial aggregation.

4 CREATE TABLE AgroDistribution_Objtab OF AgroDistribution_Objtyp /* Oracle does not accept reference type attributes as making part of primary keys; in this way, MapWarehouse programmatically guarantees that values for (time_ref, soil_ref, plantation_ref, precipitation_ref, municipality_ref) are unique */ Figure 2: AgroDistribution OR Star Schema elements reuse the Oracle type MDSYS.SDO_GEOMETRY. For lack of space, we restrict ourselves to the Oracle scripts for the spatial dimension and spatial measure: /* Oracle spatial type */ CREATE TYPE Geometry_Objtyp as OBJECT (geom MDSYS.SDO_GEOMETRY) /* dimension type and table, with the embedded spatial hierarchy municipality_geometry N 1 microregion_geometry N 1 region_geometry N 1 state_geometry */ CREATE TYPE Municipality_Objtyp AS OBJECT ( municipality_id NUMBER, municipality_name VARCHAR2(100), municipality_geometry Geometry_Objtyp, /* single geometry */ micro-region_name VARCHAR2(100), micro-region_geometry REF Geometry_Objtyp, /* single geometry */ region_name VARCHAR2(100), region_geometry REF Geometry_Objtyp, /* single geometry */ state_name VARCHAR2(100), state_geometry REF Geometry_Objtyp, /* single geometry */...) CREATE TABLE Municipality_Objtab OF Municipality_Objtyp (PRIMARY KEY (municipality_id)) /* fact type and table */ CREATE TYPE AgroDistribution_Objtyp AS OBJECT ( time_ref REF Time_Objtyp, soil_ref REF Soil_Objtyp, plantation_ref REF Plantation_Objtyp, precipitation_ref REF Precipitation_Objtyp, municipality_ref REF Municipality_Objtyp, crop_areas Geometry_Objtyp, /* collection of geometries */...) 3.3 OLAP with MapWarehouse Let us see, through an example, as we can define a roll up / drill down spatial OLAP function in MapWarehouse. Its generalization for any roll up / drill down function is straightforward. Suppose the following query on the spatial OR star schema AgroDistribution in section 3.2: Retrieve the corn crop areas inside a given rectangular window, for each micro-region (region) and for each region (micro-region) of the state of Paraíba, during May This query may be interpreted as a spatial roll-up (drill-down) along the subset microregion N 1 region of the spatial hierarchy municipality N 1 micro-region N 1 region N 1 state. One possible OR SQL formulation of this query follows: (Select a.municipality_ref.microregion_geometry, From AgroDistribution_Objtab a And SDO_INSIDE (a.crop_areas, SDO_GEOMETRY (2003, 8307, NULL, SDO_ELEM_INFO_ARRAY (1,1003,3), SDO_ORDINATE_ARRAY (-37.1, -6.0, -34.0, -9.0))) = 'TRUE' Group by a.municipality_ref.microregion_geometry) UNION (Select a.municipality_ref.region_geometry, From AgroDistribution_Objtab a And SDO_INSIDE (a.crop_areas, SDO_GEOMETRY (2003, 8307, NULL, SDO_ELEM_INFO_ARRAY (1,1003,3), SDO_ORDINATE_ARRAY (-37.1, -6.0, -34.0, -9.0))) = 'TRUE' Group by a.municipality_ref.region_geometry) We detail four points with regard to this query: 1. The Oracle boolean operator SDO_INSIDE(geometry1, geometry2) returns TRUE for object pairs that have the INSIDE topological relationship, and FALSE otherwise; here, geometry1 is an object crop_areas in the table AgroDistribution_Objtab while geometry2

5 specifies a transient instance of a geometry of type SDO_GEOMETRY, in this case the window for the query; 2. The SDO_GEOMETRY type is defined in Oracle as: CREATE TYPE SDO_GEOMETRY AS OBJECT ( SDO_GTYPE NUMBER, /* =3 single geometry, =4 collection /* SDO_SRID NUMBER, /* coordinate system associated with the geometry /* SDO_POINT SDO_POINT_TYPE, /* not NULL when used to store points, in this case the arrays SDO_ELEM_INFO and SDO_ORDINATES must be NULL */ SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY, /* an array of numbers that stores semantic information about geometry elements of the array SDO_ORDINATES */ SDO_ORDINATES SDO_ORDINATE_ARRAY /* stores the coordinate values that make up the boundary of a spatial object {X1, Y1, X2, Y2,...} */ ) More details about the SDO_Geometry type can be seen in [11]. For our purposes, the interface in the query to the spatial operator SDO_INSIDE specifies a rectangle defined by two points (-37.1, -6.0) and (-34.0, -9.0); 3. With Oracle, aggregation criteria for Group by cannot be of the type SDO_GEOMETRY. Taking this into account, notice that the aggregation criteria municipality_ref.micro-region(region)_geometry in the union query are of the type REF SDO_Geometry ( SDO_Geometry); 4. REF attributes are essential for both query performance and efficient storage, specially when dealing with large objects, as it is the case of geometric ones. The MapWarehouse s graphical interface enables visualizing the outcome of this query as in figures 3 and 4. In the current version of MapWarehouse, users pose their spatial and analytical queries in a text box area, and after submitting the query, the result map is presented. Figure 4: Roll-up Operation: To Region In figures 3 and 4, crop areas are represented by geometric points, while micro-regions and regions are represented by polygons. Gray areas in the maps indicate those municipalities inside their micro-regions (regions) with corn plantations, while that blank areas indicate absence of corn plantations. Decision makers interest resides mainly in the synchronization of spatial data with non-spatial data: for instance, next to a map must be exhibited values of some of its quantitative performance metrics. While we are on the subject, notice that the model tightly integrates spatial and non-spatial multidimensional data. But in this paper, we restrict ourselves to spatial data. 4. OPTIMIZATION WITH SPATIAL AGGREGATES In the two first sub-sections, we give the reasons that have led to a novel spatial multidimensional query optimization algorithm. Next, we present the algorithm itself. 4.1 R-tree Indexing Limitations A spatial index, like any other index, provides a mechanism to limit searches, but here it is based on spatial criteria such as intersection and containment. Oracle allows to use the spatial R-tree index 1 [4]. An R-tree index approximates each geometry by a single rectangle that minimally encloses the geometry (called the minimum bounding rectangle). Although R-trees are adequate for efficiently indexing spatial data, we have observed that there are situations in which the use of such index is useless. For instance, let us consider an OLAP query, similar to the one in section 3.3 with the exception that there is no spatial window: Figure 3: Roll-up Operation: From Micro-region 1 As a matter of fact, Oracle also supports quadtree indexes, but its use is discouraged.

6 (Select a.municipality_ref.microregion_geometry, From AgroDistribution_Objtab a Group by a.municipality_ref.microregion_geometry) UNION (Select a.municipality_ref.region_geometry, From AgroDistribution_Objtab a Group by a.municipality_ref.region_geometry) Tests with and without R-tree index gave the following results: Non-indexed AgroDistribution-Objtab Indexed AgroDistribution_Objtab Response time: 2min50sec Response time: 3min05sec Notice that, although there is no topological operator in the query, such as the INSIDE one in the query presented in section 3.3, there still exists the SDO_AGGGR_UNION spatial operator, which should get benefit of the R-tree index. Nonetheless, the results have shown that it is not the case. The time difference pro non-indexing is due, in this case, to the inutile R-tree searching. 4.2 Oracle Rewrite Limitations Rewrite option of the Oracle Query Optimizer [10], together with the careful use of materialized views ([3], [10]), lets you increase the speed of OLAP queries that is, involving many aggregations on very large databases. Materialized views improve query performance by pre-calculating expensive aggregation operations on the database. The query optimizer automatically recognizes when an existing materialized view should be used to satisfy a query; it then transparently rewrites the query to use the materialized view. Unfortunately, Oracle rewrite option does not directly support the requirements of the MapWarehouse spatial model. In short, we cite two Oracle rewrite restrictions: (r1) the query cannot contain spatial data; and (r2) the query cannot contain object REFs. R-tree and Oracle rewrite limitations have led to the need for a new rewrite algorithm. 4.3 MapWarehouse Aggregate Navigator The Rationale for the Algorithm The basic concept for the algorithm is that of spatial aggregate. aggregate is defined as a spatial OR star schema in which the spatial aggregations are fed from the underlying base spatial OR star schema. It is then implicit that the granularity level of a spatial aggregate is always greater than that of the base schema. Like as for the base schema, spatial aggregates are also materialized. Consider the base schema AgroDistribution in section 3.2: in it, the crop area granularity is municipality. A spatial aggregate, with granularity level of micro-region, might be derived from the base schema, as follows (only the spatial elements): CREATE TYPE Micro-region_Objtyp AS OBJECT( micro-region_id NUMBER, micro-region_name VARCHAR2(100), micro-region_geometry Geometry_Objtyp, region_name VARCHAR2(100), region_geometry REF Geometry_Objtyp, state_name VARCHAR2(100), state_geometry REF Geometry_Objtyp,...) CREATE TABLE Micro-region_Objtab OF Microregion_Objtyp (PRIMARY KEY (micro-region_id)) CREATE TYPE Micro-region-AgroDistribution_Objtyp AS OBJECT( Time_REF REF Time_Objtyp, soil_ref REF Soil_Objtyp, plantation_ref REF Plantation_Objtyp, precipitation_ref REF Precipitation_Objtyp, municipality_ref Micro-region_Objtyp, quantity NUMBER, crop_areas Geometry_Objtyp,...) CREATE TABLE Micro-region-AgroDistribution_Objtab OF Micro-region-AgroDistribution_Objtyp Observe that the attribute names in the base schema are maintained, except for Municipality_Objtyp, that is replaced by Micro-region_Objtyp (in boldface). The importance of this spatial aggregate for the query in section 3.3 is that the query can be efficiently replaced by another equivalent query on the spatial aggregate, by simply changing AgroDistribution_Objtab by Micro-region- AgroDistribution_Objtab, with evident performance gains: (Select a.municipality_ref.micro-region_geometry, From Micro-region-AgroDistribution_Objtab a And SDO_INSIDE (a.crop_areas, SDO_GEOMETRY (2003, 8307, NULL, SDO_ELEM_INFO_ARRAY (1,1003,3), SDO_ORDINATE_ARRAY (-37.1, -6.0, -34.0, -9.0))) = 'TRUE' Group by a.municipality_ref.microregion_geometry) UNION... It is important to point out that, in MapWarehouse, spatial aggregates are completely transparent to end users and to

7 application designers, except for the obvious performance benefits The Algorithm We now discuss the novel MapWarehouse s rewrite algorithm, named spatial aggregate navigator (SAN). SAN is a piece of middleware that sits between the requesting client and the SDW that intercepts the client s SQL OLAP and, wherever possible, transforms base-level SQL into aggregate-aware SQL logical optimization. The transformed SQL is then normally submitted to the DBMS optimizer physical optimization. To realize the potential of spatial aggregates, SAN provides efficient solutions to three problems: (1) aggregate design: determining what spatial aggregates to materialize, including how to store and index them; (2) aggregate maintenance: efficiently updating spatial aggregates when spatial fact tables are updated; and (3) aggregate exploitation: making efficient use of spatial aggregates to speed up OLAP query processing. This paper is concerned uniquely with spatial aggregate exploitation: spatial aggregate design and spatial aggregate maintenance are the subject of two other papers, in preparation. The part of the SAN algorithm concerning the spatial aggregate exploitation is very simple. Conceptually, it consists of only three steps: 1. Sort the spatial aggregates (including the base spatial aggregate) from smallest to largest based on spatial fact table cardinality. Choose the next smallest spatial aggregate; 2. If all of the attributes in the SQL statement can be directly or indirectly found in the spatial aggregate, alter the original query by simply substituting the base fact table for the spatial aggregate fact table; else, go back to Step 1; 3. Run the altered query. Referring to the step 2, note that it is not always the case of total matching; on the contrary, partial matching is much more probable. For example, if the query demands aggregation of crop areas by region, and the spatial aggregate is by micro-region, then from the performance point of view the query on the spatial aggregate partial matching works better than the original one on the base schema (or micro-region is closer to region than municipality is). The algorithm is guaranteed to terminate successfully because eventually one arrives at the base schema, which is always guaranteed to satisfy the query. In terms of rewrite performance, note that almost no metadata is required to support general navigation, if the DBA is careful with the choice of the spatial aggregates (see section 4.3.1). 5. EXPERIMENTAL RESULTS We then present the SAN experimental results. The test plan consisted of running a temporal series query in three ways: (1) without spatial logical optimization ~SLO ; (2) with spatial logical optimization and partial matching SLO (Partial) ; and (3) with spatial logical optimization and total matching SLO (Total). Query pattern Base schema Partial matching Month-to-month crop areas by region, with spatial window Time (Day), Municipality; R-tree index aggregate: Time (Day), Micro-region; R-tree index Total matching aggregate: Time (Month), Region; R- tree index Average elapsed times of temporal series from 1999 to 2005 were computed. Consider, for instance, the point (3, 1000) of the ~SLO curve in figure 5: it represents the average of 1000 sec of the elapsed times of 3-month temporal series from January to March, for each year between 1999 and 2005; the same holds good for the other points in figure 5, that is, the point (i, avg) represents the average avg of the elapsed times of i-month temporal series, between 1999 and We measure the speedup ratio between ~SLO query processing and SLO query processing as an indicator of the performance improvement of SLO over ~SLO: speedup = elapsed time with ~SLO / elapsed time with SLO. Obviously, a speedup value greater than 1 implies that SLO performs better. Figure 6 shows the two speedup trend curves for partial and total matching respectively, generated from data in figure 5 by quadratic polynomial interpolation. Both curves make evident that the speedup is always greater than 1 and that it increases nonlinearly with the number of months, and that the results with total matching are better than the ones with partial matching. Average Elapsed Time (Sec) Speedup No. of Months ~SLO SLO (Partial) SLO (Total) Figure 5: Comparison Between Elapsed Times No. of Months Figure 6: Speedup Trend Curves SLO (Partial) SLO (Total)

8 In a general way, we have noticed that by using logical query optimization based on spatial aggregates the overall response time decreases a lot. This performance gain is remarkable for large databases: we expect anywhere from a hundredfold to a thousandfold improvement in runtime by having the right spatial aggregates available. 6. CONCLUSION Data Warehousing for decision support systems may be enhanced qualitatively if they are able to also deal with spatial dimensions and measures, so characterizing a Data Warehousing. The incorporation of spatial dimension and measure enables to locate more efficiently tendencies in a given application domain, by using dynamic maps with zooming, panning, aggregation and other GIS functionalities. For instance, one may ask for the total of sales of a given product in the last month in neighborhoods of a given city. In this paper, we have presented a logical data model which enables the implementation of a spatial data warehousing. We have also addressed optimization query techniques and built a Web prototype in order to validate the model through a real case study in the agricultural domain. Nevertheless, Data Warehousing is still in its infancy and more research on this topic is due. Hence, as future work we intend to further investigate the use of spatial aggregates; in particular, the issues concerning spatial aggregate design and spatial aggregate maintenance will be addressed, as in this paper we have only focused on spatial aggregate exploitation. Furthermore, we are working on the interface in order to enhance usability and to include other OLAP and spatial query capabilities. 7. REFERENCES [1] Bimonte, S., Tchounikine, A., and Miquel, M. Towards a Multidimensional Model. In Proceedings of the Data Warehousing and OLAP Conference (DOLAP 05), 2005, [2] Damiani, M. L., and Spaccapietra S. Data Warehouse Modeling. Processing and Managing Complex Data for Decision Support, Darmont, J. & Boussaid, O. (Eds), IDEA Group Publishing, 2006, [3] Goldstein J., and Larson P. Optimizing Queries Using Materialized Views: a Practical, Scalable Solution. In Proceedings of the ACM SIGMOD, 2001, [4] Guttman, A. R-trees: A Dynamic Index Structure for Searching. In Proceedings of the ACM SIGMOD, 1984, [5] Han, J., Stefanovik, N., and Kopersky, K. Selective Materialization: An Efficient Method for Data Cube Construction. In Proceedings of Research and Development in Knowledge Discovery and Data Mining, Second Pacific- Asia Conference (PAKDD 98), 1998, [6] Kimball, R., and Ross, M. The Data Warehouse Toolkit. John Wiley & Sons, [7] Malinowski, E., and Zimanyi, E. Representing ity in a Conceptual Multidimensional Model. In Proceedings of the 12 th ACM International Symposium on Advances in Geographic Information Systems (ACM GIS 2004), 2004, [8] Open GIS Consortium (1999). OpenGIS Simple Features Specification for SQL. In URL: [9] Oracle. Oracle Database Concepts10g Release 2 (10.2), Oracle Corporation, [10] Oracle. Oracle Database Data Warehousing Guide 10g Release 2 (10.2), Oracle Corporation, [11] Oracle. Oracle Oracle User's Guide and Reference 10g Release 2 (10.2), Oracle Corporation, [12] Zhang, L., Li, Y., Rao, F., Yu, X., Chen, Y., and Liu, D. An Approach to Enabling OLAP by Aggregating on Hierarchy. In Proceedings of the Data Warehousing and Knowledge Discovery Workshop (DAWAK 03), 2003,