Spatial database services for location-aware applications
Query Language
A query language provides the means to access and manipulate data in the database. The query language should have enough constructs built into it to express a wide variety of data types. At the same time it must be intuitive and easy to use. A popular query language for relational databases is the Structured Query Language (SQL). It is known that the traditional SQL is inadequate to express typical spatial queries. This has prompted various efforts to extend the capability of SQL with spatial-friendly constructs. At the same time, the standards committee is currently working on a draft to update and make it compatible with the generic functionality offered by object-relational database management systems. The OGIS (1998) consortium led by important GIS and database companies has come out with their own proposal to include GIS capabilities in SQL. The specification is described by a standard set of Geometry Types based on the OGIS geometry model, together with functions for these types. Common spatial operators like adjacent, overlap and inside, and functions like buffer, perimeter and area have been included in the specification.
Spatial Query Processing
Spatial queries are often processed using filter and refine techniques (for a survey on different spatial query processing techniques see Gueting (1994)). In the first filter step, some approximate representation of a spatial object is used to determine a set of candidate objects which are likely to satisfy the given spatial query. Common approximations used in spatial databases are minimum orthogonal bounding box and multiple bounding boxes. Then the candidate set is further examined using the exact representations of the objects to find the actual set of objects which satisfy the given query. The approximations are chosen such that if the approximations of objects A and B do not satisfy a relationship, then that relationship cannot be satisfied between the objects A and B.
Spatial Indexing
The purpose of a spatial index is to facilitate spatial selection. That is, in response to a query, the spatial index will only search through a subset of objects embedded in the space to retrieve the query result set. A fundamental idea for spatial indexing is the use of approximations. This allows index structures to manage an object in terms of one or more spatial objects, which are much simpler geometric objects than the object itself. The prime example is the bounding box (the smallest orthogonal rectangle enclosing the object). Another method called grid approximation divides the space into cells by a regular grid, and the object is represented by the set of cells that it intersects. The use of approximations leads to a filter and refine strategy for spatial query processing: First, based on the approximations, a filtering step is executed; it returns a set of candidates that is a super set of the objects fulfilling a spatial predicate. Second, the result is refined by checking the exact geometry of each candidate geometry.
Commercial Spatial Database Systems
Object-relational database systems (ORDBMS) provide the GIS applications the ability to completely integrate the spatial data with the attribute data in the database system. The ORDBMS provides SQL extensions so that the spatial data can be accessed and managed like any other attribute data. They also provide user defined indexes and functions which lets the database understand the spatial operations during the query optimization phase. Oracle's Spatial, Informix 2D Datablade, and IBM's DB2 (Chamberlin, 1997) Spatial Extender are examples of commercial systems which provide this functionality. In this section, we review how the current commercial database systems handle spatial data and we use Oracle Spatial database as the main reference.
Oracle Spatial
Over the last few years, Oracle has extended the classical relational database in several areas. One of those extensions concerns the storage, indexing, querying and delivery of location-based information [1]. Location information is really just another data type that should be stored alongside other information, such as names, dates, etc. It has, however, specific characteristics (ordering, querying) and specific needs (spatial indexing, coordinate systems, etc.).
The Oracle database provides all those facilities. It understands and manages location data just like any other data, and allows location-based queries to be expressed in its native language, SQL. It goes above and beyond the handling of simple location (point) data: it also handles complex geographic entities like lines, curves, polygons and areas, and it provides advanced geometric operations on those entities: intersections, unions, etc. For networks (typically road networks), it supports linear referencing, a fundamental need for describing and providing directions from one location to another.
Standards are especially important when it comes to procuring location data and related geographical information such as political boundaries, transportation networks, demographics, etc. Geographical and location information has traditionally been available in a variety of formats, often proprietary. The key body that drives standardization efforts in this area is the Open GIS Consortium, of which Oracle is a principal member. The data model used for storing the spatial and location information inside the database strictly conforms to the standards defined by the Open GIS Consortium.