Spatial Data Warehouses: Some Solutions and Unresolved Problems

Transcription

1 Spatial Data Warehouses: Some Solutions and Unresolved Problems Elzbieta Malinowski and Esteban Zimányi Université Libre de Bruxelles Department of Computer & Decision Engineering Abstract Spatial Data Warehouses (SDWs) combine spatial databases and data warehouses allowing analysis of historical data represented in a space. This data can be queried using Spatial On-Line Analytical Processing (SOLAP) systems. SDW and SOLAP systems are emerging areas that raise several research issues. In this paper, we refer to different problems existing in SDWs that motivated us to propose the MultiDimER model - a conceptual multidimensional model able to express users requirements for SDW and SOLAP applications. We present also different research directions that are important to consider to provide satisfactory solutions for SDW and for SOLAP systems. 1. Introduction Data Warehouse (DW) applications are designed using a multidimensional view of data consisting of fact and dimension tables. A fact table contains numeric data called measures (e.g., quantity of sales). Dimensions may contain hierarchies and are used to explore measures from different perspectives (e.g., by product). DW data can be dynamically manipulated using On-Line Analytical Processing (OLAP) systems. The latter requires also the multidimensional view of data. In particular, hierarchies allow to establish traversing paths to obtain measures at different levels of detail using the roll-up and the drill-down operations. The former operation transforms detailed measures into summarized data while the latter does the contrary. Current DWs typically include a location dimension, e.g., store address, client address, or city name. This dimension is usually represented in an alphanumeric format. However, the advantages of using spatial data in the analysis process are well known since visualizing data in space Currently on leave from the Universidad de Costa Rica. allows to reveal patterns that are difficult to discover otherwise. Therefore, spatial databases (SDBs) can give insights about how to represent and manage spatial data in DWs. SDBs allow to store and manipulate spatial objects. The latter correspond to real-world entities for which the application needs to keep their spatial characteristics. Spatial objects consist of a thematic (or descriptive) component and a spatial component. The former is represented using traditional DBMS data types, e.g., integer, string, and date. The spatial component includes its geometry, which can be of type point, line, surface, or a collection of these types. Spatial objects can relate to each other forming topological relationships. Different topological relationships have been defined, e.g., meets, contains ([3]). They are based on the representation of a spatial extent by a set of points, composed of three subsets: the boundary, which delimits the extent, the interior, i.e., the points within the boundary, and the exterior, i.e., the points outside the boundary. For example, A meets B means that the boundaries of A and B share some common point(s), their interiors are disjoint, and their exteriors have also common points. SDBs are typically used for daily business manipulations. Examples of typical queries are where is the closest store to my house, which highways connect Brussels and Warsaw, how to get to a specific place from my current position given by a GPS. SDBs are not well suited for supporting the decision-making process ([13]), e.g., when analysis of spatial data is required to find the best location for a new store or to choose which alternative routes can be built for highways with intensive traffic. The field of spatial data warehouses (SDWs) emerged as a response to the necessity of analyzing high volumes of spatial data. SDWs combine SDB and DW technologies exploiting the capabilities of both systems. Further, Spatial On-Line Analytical Processing (SOLAP) is increasingly gaining the interest of decision-making users. SOLAP systems provide OLAP capabilities of dynamic data manipulation and aggregation referring them to spatial data. However, SDWs raise several research issues, such as the meaning of SDWs,

2 multiple representations of spatial objects, use of multidimensional model that takes into account specific semantics of SDW applications facilitating SOLAP operations ([13, 14]), among others. In [7, 8], we defined a multidimensional model able to represent at the conceptual level users requirements for SDW applications. This paper collects sparse information in an unified manner identifying multidimensional elements for which spatial support should be allowed. On the other hand, in [9] we proposed the transformation of a conceptual schema based on the MultiDimER constructs to an object-relational schema. We based our mapping on the SQL:2003 and SQL/MM standards giving examples of commercial implementation using Oracle 10g with its spatial extension. We also show some examples of Oracle spatial functions, including aggregation functions required for the manipulation of spatial data. The described mappings to the object-relational model along with the examples using a commercial system show the feasibility of implementing SDWs in current commercial DBMSs. However, due to space limitation, in this paper we do not refer to implementation issues. This paper is organized as follows. Section 2 first presents some problems existing in SDWs that motivated us to define a conceptual multidimensional model with spatial elements. The model definition is included in Section 3. Section 4 mentions still existing problems in SDWs and SO- LAP.ConclusionsaregiveninSection5. 2. Motivation for defining a conceptual multidimensional model with spatial elements Currently, there is no consensus in the literature about the meaning of SDWs. The term is used in different situations, for example, when there are high volumes of spatial data, when the integration or aggregation processes for spatial data are required, or when the decision-making process uses spatial data. Even though it is important to consider all the above aspects in SDWs, what is still missing is a proposal for SDWs with clearly-distinguished spatial elements required for multidimensional modeling. Some proposals consider spatial dimensions and spatial measures ([4, 12, 15]); however, they impose restrictions on the model as we will see in the next section. Secondly, applications that include spatial data are usually complex and need to be modeled taking into account users requirements. However, the lack of a conceptual approach for DW and OLAP systems joined with the absence of a commonly-accepted conceptual model for spatial applications, make difficult the modeling task. Existing conceptual models for SDBs are not adequate for multidimensional modeling since they do not include the concepts of dimensions, hierarchies, and measures. To the best of our knowledge, very few proposals refer to conceptual modeling for SDW applications (e.g., [1, 2, 6, 16]). Some of these models include the concepts presented in [7], to which we will refer in the next section; other models extend non-spatial multidimensional models considering different aspects, e.g., imprecision ([6]), location-based data ([16]), or continuous phenomena (e.g., temperature or elevation) ([1]). Finally, a proposal for a spatially-extended conceptual multidimensional model should consider different issues not present in conventional multidimensional models, e.g., the topological relationships existing between the different elements of the multidimensional model or aggregations of spatial measures, among others. Some of these aspects are briefly mentioned in the existing literature (e.g., spatial aggregations [11]), others are neglected (e.g., the influence on aggregation procedures of the topological relationships between spatial objects forming hierarchies). 3. The spatially-extended MultiDimER model 3.1 Model definition In order to answer to the problems described above, in [7, 8] we proposed the MultiDimER model that allows to represent at the conceptual level the elements required for SDW and SOLAP applications. To describe our model, we use an example for the analysis of highway maintenance costs. Highways are divided into highways sections, which at their turn are divided into highway segments. For each segment, the information about the number of cars and repairing cost during different periods of time is available. Since the maintenance of highway segments is the responsibility of the counties through which the highway is passing, the analysis should consider the administrative division of the territory, i.e., counties and states. The analysis should also help to reveal how the different types of road coating influence the maintenance costs. The multidimensional schema that represents these requirements is shown in Figure 1. The schema contains dimensions, hierarchies, a fact relationship, and measures. A dimension is an abstract concept for grouping data that shares a common semantic meaning within the domain being modeled. It represents either a level or one or more hierarchies. A level corresponds to an entity type in the ER model and represents a set of instances called members that have common characteristics. For example, Road coating in Figure 1 is a one-level dimension. Spatial levels are levels for which the application needs to keep their spatial characteristics. This is captured by its geometry, which in our model is represented using the pictograms shown in Figure 2 a) 1. 1 They form part of the conceptual spatio-temporal model MADS [10].

3 Highway Highway name Highway section Section number Highway structure Highway segment Segment number Road condition Speed limit Road coating Coating name Coating type Coating durability Highway maintenance Length (S) Common area No. cars Repair cost Geo location Date Event Season State State name State population State area State major activity Capital County County name County population County area Time Figure 1. An example of multidimensional schema with spatial elements. In Figure 1, we have five spatial levels: County, State, Highway segment, Highway section, and Highway. Hierarchies are required for establishing meaningful paths for the roll-up and the drill-down operations. They contain several related levels, e.g., the County and State levels in Figure 1. Hierarchies can express different structures according to an analysis criterion. We use the criterion name to differentiate them, e.g., Geo location in Figure 1. A spatial hierarchy (resp. a spatial dimension) is a hierarchy (resp. a dimension) that includes at least one spatial level (resp. one spatial hierarchy). Given two consecutive levels of a hierarchy, one is called Point Line Surface Adjacent Intersect Disjoint a) b) Point bag Line bag Surface bag Cross Within Equal Figure 2. Pictograms for a) spatial data types and b) topological relationships. child and the other parent depending on whether they include, respectively, more detailed or more general data. In Figure 1, County is a child level while State is a parent level. A level of a hierarchy that does not have a child level is called leaf (e.g., Highway segment) while a level does not have a parent level is called root (e.g., Highway). The relationships between child and parent levels are characterized by cardinalities. They indicate the minimum and the maximum numbers of members in one level that can be related to a member in another level. In Figure 1, the cardinality between the County and the State levels is manyto-one indicating that a county can belong to only one state and a state can include many counties. Different cardinalities may exist between levels leading to different types of hierarchies [8]. They are important to include in the conceptual model since they exist in real-world situations and may be required by decision-making users. In a spatial hierarchy, two consecutive spatial levels are related through a topological relationship. This is represented using the pictograms of Figure 2 b). By default we suppose the within topological relationship, which indicates that the geometry of a child member is included in the geometry of a parent member, e.g., in Figure 1 the geometry of each county is included in the geometry of its corresponding state. However, in real-world situations different topological relationships can exist between spatial levels. They are important to consider because they determine the complexity of the procedures for measure aggregation during the roll-up operations [8]. For example, in a spatial hierarchy formed by the Store and the City levels, some points referring to store locations can be on the border between two cities represented as surfaces. This situation may lead to the problem of measure aggregation when traversing from the Store to the City levels since it is not clear whether the measure (e.g., required taxes) should be distributed between two cities or considered only for one of them. Levels contain one or several key attributes (underlined in Figure 1) and may also have other descriptive attributes. Key attributes indicate how child members are grouped into parent members during the roll-up operation. For example, in Figure 1 the State name in the State level is a key attribute, thus different counties will be grouped according to the state name to which they belong. A fact relationship (e.g., Highway maintenance in Figure 1) represents an n-ary relationship between leaf levels. This fact relationship can be spatial if at least two leaf levels are spatial, e.g., the Highway segment and the County spatial levels. A spatial fact relationship may require the inclusion of a spatial predicate for the spatial join operation. For example, in the figure an intersection topological relationship indicates that users require to focus their analysis on those highway segments that intersect counties. If this topological relationship is not included, users are interested

4 in any topological relationships that may exist. A (spatial) fact relationship may include thematic or spatial measures. The former are usually numeric values that allow to perform quantitative analysis, e.g., to analyze the changes in repairing cost during different periods of time. Spatial measures can be represented by a geometry or calculated using spatial operators, e.g., distance, area. To indicate that the measure is calculated using spatial operators, we use the symbol (S). The schema in Figure 1 contains two spatial measures: Length and Common area. Length is a number representing the length of the part of a highway segment that belongs to a county. Common area represents the geometry of the common part. Measures require the specification of the function used for aggregations along the hierarchies. By default we suppose sum for the measures represented as numbers and geometric union for the measures represented as geometries. The schema in Figure 1 provides a multidimensional view of data with clearly distinguished elements: the fact relationship indicating the focus of analysis, measures used for aggregation purposes, and dimensions with hierarchies allowing to analyze measures from different perspectives and with different levels of detail. Further, our model allows to represent spatial as well as non-spatial elements in an orthogonal way, therefore it gives users different alternatives for choosing the kind of data that better fits their analysis requirements. 3.2 Different approaches for SDW modeling The MultiDimER model extends those of [15] and [13], in particular by allowing a non-spatial level (e.g., address represented as an alphanumeric data type) to roll-up to a spatial level (e.g., city represented by a surface). Further, we extend the classification for spatial dimensions allowing a dimension to be spatial even if it has only one spatial level ([7]), e.g., a State dimension that is spatial without any other geographical division. The extension also includes a classification of different kinds of spatial hierarchies existing in real-world situations ([8]) that are currently ignored in research related to SDWs. Regarding to spatial measures, we based our proposal on [12] and [15]. However, both authors refer to implementation details stating that spatial measures should be represented using pointers to spatial objects. In our model we clearly separate the conceptual and implementation aspects. Further, [12] requires the presence of spatial dimensions for including spatial measures represented by a geometry. On the contrary, in our model a spatial measure may exist independently of whether or not spatial dimensions are included (see Figure 3). For the schema in Figure 3 the user is interested in analyzing locations of accidents taking into account the dif- Insurance category Category name Insurance type Insurance Insurance number Validity period Age group Group name Min. value Max. value Age category Client Client id First name Last name Birth date Profession Salary range Address Accidents Amount paid Location / GU Date Quarter Quarter number Month Month name Calendar Time Figure 3. A multidimensional conceptual schema with a spatial measure: Location. ferent insurance categories (full coverage, partial coverage, etc.) and particular client data. The model includes a spatial measure representing the location of an accident. Since the dimensions include hierarchies, a spatial aggregation function is defined; in this case geometric union (GU). Thus, when a user rolls-up to the Insurance category level, the locations corresponding to different categories will be aggregated and represented as a set of points. Other spatial operators can be also used, e.g., center of n points. [4] does not allow spatial measures converting them in spatial dimensions. However, the resulting model corresponds to different analysis criteria and answers to different queries. For example, Figure 4 shows an alternative schema for the analysis of accidents that results from transforming the spatial measure Location of the Figure 3 into a spatial dimension Address. For the schema in Figure 4 the focus of analysis has been changed to the amount of insurance paid according to different geographical locations. Therefore, using this schema, users can compare the amount of insurance paid in different geographic zones; however, they cannot aggregate locations (e.g., using spatial union) of accidents according to some predicate (e.g., during different periods of time) as can be done for the schema in Figure 3. As can be seen, although these schemas are similar, different analysis can be done when a location is handled as a spatial measure or as a

5 Insurance category Category name Insurance type Insurance Insurance number Validity period Address Location id Street name Number Accident location Age group Group name Min. value Max. value Age category Client Client id First name Last name Birth date Profession Salary range Address Accidents Amount paid City City name City population City area Date Quarter Quarter number Month Month name Calendar Time State State name State population State area Figure 4. Another variant of a multidimensional schema for analysis of accidents. spatial hierarchy. It is the designer s decision to determine which of these models better represents users needs. 4. Unresolved problems SDWs raise many interesting research problems. One of them is the aggregation of spatial measures. Current OLAP systems automatically aggregate numerical measures along hierarchies using different types of functions: distributive, algebraic, and holistic [5]. For example, distributive functions, e.g., sum, min,andcount, reuse aggregates of a lower level of a hierarchy in order to calculate the aggregates for a higher level. Algebraic functions, e.g., average, variance, and standard deviation, need an additional treatment for reusing the values, e.g., the average of a higher level can be calculated taking into account already computed values of sum and count of a lower hierarchy level. On the other hand, holistic functions, e.g., median, most frequent, andrank require new calculations using the data of the leaf level. As for non-spatial data, aggregation functions for spatial data have been defined [14]. For example, spatial distributive aggregates include convex hull, geometric union, and geometric intersection. The result of these functions is represented by simple or complex geometries. Examples of spatial algebraic functions are center of n geometric points or center of gravity, while examples of spatial holistic functions are equi-partition or nearest-neighbor index [14]. Nevertheless, aggregation of spatial measures additionally requires to consider the topological relationships existing between them. For example, if the spatial measure represents the geometry of a building and the same building is used for concerts and discotheques, the aggregation of areas dedicated to entertainment will count the building area twice. This is a known problem in DWs called double counting. To our knowledge, only [11] deals with this aspect proposing the classification of topological relationships existing between spatial measures that allows to avoid the problem of double counting or incorrect aggregation. However, this is still an open research issue that requires to combine research related to topological relationships between measures [11] and between hierarchy levels [8]. Current research in SDWs refers to 2-dimensional objects. However, an interesting issue is the inclusion of 3- dimensional objects. Coping with these kinds of objects is essential in many application domains, e.g., urban planning processes, telecommunications planning, or disaster management. However, it is still necessary to determine the multidimensional requirements of applications manipulating 3-dimensional spatial objects and to consider the geometry and topological relationships between them. Another interesting research problem is the inclusion of spatial data represented as continuous (or field) view, e.g., temperature, altitude, or soil cover. Although some proposals already exist ([1]), an additional analysis is still required in different issues, e.g., spatial hierarchies formed by levels represented by field data, spatial measures representing continuous phenomena and their aggregations, fact relationships that include leaf levels with field data, among others. Another issue is to cope with multiple representations of spatial data, i.e., allowing the same real-world object to have different geometries. Multiple representations is a common practice in SDBs. It is also an important aspect in the DW context since spatial data may be integrated from different source systems that use different geometries for the same spatial object. An additional difficulty insdws arises when levels forming a hierarchy can have multiple representations and one of them must be chosen during the roll-up and the drill-down operations. Development of SDWs is a complex task since designers and implementers must deal not only with the multidimensional data representation, but also must consider when and how the spatial support should be included. Even though there are some proposals for DW design methodology, there is still lack of such proposals for SDWs. [12, 13] refer to different features that should be con-

6 sideredforsolap;basedonthemtheydevelopedaso- LAP tool 2 that allows the roll-up and drill-down operations. However, it is necessary to extend these operations for different types of spatial hierarchies [8] existing in real-world situations. This is not an easy task since not only different from many-to-one cardinalities may exist between child and parent hierarchy levels but also different topological relationships between these levels must be considered. Another aspects for SOLAPs is how to manage the preaggregation of spatial measures represented by geometries. Preaggregation is a well-known practice in conventional OLAPs; it allows to improve the response time for complex queries accessing summarized data by the expense of disk space. This problem has already known solutions in conventional OLAPs. However, spatial data aggregation isnotaneasytask,andevennon-aggregateddatarequires substantial storage space. 5. Conclusions Over the years, spatial data has increasingly become part of operational and analytical systems in different areas, e.g., public administration, environmental systems. The management of spatial data is usually carried out by Spatial Databases (SDBs). However, the latter are not well suited for supporting the decision-making process. Therefore, a new area of Spatial Data Warehouses (SDWs) has emerged. SDWs raise many research issues to which we referred in this paper. First, recognizing that a multidimensional model is well suited for expressing the requirements of decision-making users and considering lack of multidimensional conceptual models with spatial elements, we presented the spatially-extended MultiDimER model; it includes constructs for conceptual modeling of spatial levels, spatial hierarchies, spatial fact relationship, and spatial measures. We referred to different aspects of the model, e.g., topological relationships existing between spatial hierarchy levels, consequence of transformation of spatial measures to spatial dimensions, among others. We also described different research directions that are important to consider to provide satisfactory solutions for SDW and SOLAP systems. The presented concepts aim at improving the analysis anddesignofsdwandsolapsystemsbyintegratingspatial components in a multidimensional model. In this way decision-making users can represent in an abstract manner their analysis needs without considering complex implementation issues, SOLAP tools developers can have a common vision for representing spatial data in a multidimensional model, and SDW researchers can consider different problems that still lack satisfactory solutions. 2 It is currently commercialized under the name JMap. References [1] T. Ahmed and M. Miquel. Multidimensional structures dedicated to continuos spatio-temporal phenomena. In Proc. of the 22nd British National Conference of Databases, pages 29 40, [2] S. Bimonte, A. Tchounikine, and M. Miquel. Towards a spatial multidimensional model. In Proc. of the 8th ACM Int. Workshop on Data Warehousing and OLAP, pages 39 46, [3] M. Egenhofer. A model for detailed binary topological relationships. Geomatica, 47(3&4): , [4] R. Fidalgo, V. Times, J. Silva, and F. Souza. GeoDWFrame: A framework for guiding the design of geographical dimensional schemes. In Proc. of the 6th Int Conf. on Data Warehousing and Knowledge Discovery, pages 26 37, [5] J. Gray, S. Chaudhuri, A. Basworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow, and P. H. Data cube: A relational aggregation operator generalizing group-by, crosstab, and sub-totals. Data Mining and Knowledge Discovery, 1(1):29 53, [6] C. Jensen, A. Klygis, T. Pedersen, and I. Timko. Multidimensional data modeling for location-based services. VLDB Journal, 13(1):1 21, [7] E. Malinowski and E. Zimányi. Representing spatiality in a conceptual multidimensional model. In Proc. of the 12th ACM Symposium on Advances in Geographic Information Systems, pages 12 21, [8] E. Malinowski and E. Zimányi. Spatial hierarchies and topological relationships in the Spatial MultiDimER model. In Proc. of the 22nd British Nat. Conf. on Databases, pages 17 28, [9] E. Malinowski and E. Zimányi. Logical representation of a conceptual model for spatial data warehouses. GeoInformatica, To appear. [10] C. Parent, S. Spaccapietra, and E. Zimányi. Conceptual Modeling for Traditional and Spatio-Temporal Applications: The MADS Approach. Springer, [11] T. Pedersen and N. Tryfona. Pre-aggregation in spatial data warehouses. In Proc. of the 7th Int. Symposium on Advances in Spatial and Temporal Databases, pages , [12] S.Rivest,Y.Bédard, and P. Marchand. Toward better suppport for spatial decision making: Defining thecharacteristics of spatial on-line analytical processing (SOLAP). Geomatica, 55(4): , [13] S. Rivest, Y. Bédard, M. Proulx, M. Nadeau, F. Hubert, and J. Pastor. SOLAP technology: Merging business intelligence with geospatial technology for interactive spatio-temporal exploration and analysis of data. ISPRS Journal of Photogrammetry & Remote Sensing, 60(1):17 33, [14] S. Shekhar and S. Chawla. Spatial Databases: A Tour. Prentice Hall, [15] N. Stefanovic, J. Han, and K. Koperski. Object-based selective materialization for efficient implementation of spatial data cubes. TKDE, 12(6): , [16] I. Timko and T. Pedersen. Capturing complex multidimensional data in location-based data warehouses. In Proc. of the 12th ACM Symposium on Advances in Geographic Information Systems, pages , 2004.