A relational model and SQL-like query language for spatial databases

Abstract

Spatial databases have experienced enormous growth in application environments, such as agriculture, environmental studies, geography, geology, city-planning, aerospace industry etc. More recently spatial databases have attracted attention in the database community. A considerable research has been done in physical implementation of spatial databases. This is particularly true of access methods for spatial data [238, 483, 512, 230, 231, 39, 506]. On the other hand, abstract modeling and querying of spatial data have received relatively less attention. The need for such a study becomes even more important because of diverse techniques proposed for representing spatial regions.Like [440] we favor that the logical view and the physical implementation of spatial data should be considered orthogonal issues. The users should be given a simple view of data and freed of the worry of how it is physically represented. This is even more important because physical implementation will continue to be a topic of study for quite some time to come. Conventional database techniques are inadequate in spatial databases because of the spatial structure implicit in spatial querying. We present a model and an SQL-like query language called SpaSQL (read space-Q-L) for spatial data. Without tying ourselves down to a choice of representation of spatial regions, we propose certain desirable closure properties for them to make SpaSQL seamless. Related WorksSeveral techniques of physical representation spatial regions have emerged. One way to represent a region is to lay it on a fine grid, and approximate the region by the set of grid elements covered by the region. Another technique is to describe a region by a chain of arcs, and associating a biLt with each arc to encode whether the region being specified is on the right or left of the arc. A third way is to view a region as a hyper plane in an ndimensional space, and use techniques of computational geometry to manipulate them.

A Model Comparison for Spatiotemporal Data in Ubiquitous Environments: A Case Study

“…We use their temporal data types for the interval-based data model and assume that STSQL is implemented on top of a conventional database system. ParaSQL [15,16] is a spatiotemporal query language, which uses temporal elements (or spatiotemporal elements) for domains.…”

Geometric query types for data retrieval in relational databases

“…The needs of application areas such as geography, geology, environmental studies, computer-aided design (CAD), computer vision and robotics, medical imaging and material engineering are far more complex than conventional business applications [8]. Scientific and engineering problems often require one to handle geometric data such as points, polygons, curves, surfaces, solids or even multidimensional data.…”

Object-relational spatio-temporal databases

“…First, we compare our object-relational model ORDimDB with our own relational model RelDimDB presented in Chapter 2. (RelDimDB is derived from [GC93b].) This comparison shows some pronounced differences between our two models, particularly due to type inherit ance and incorporation of oids in ORDimDB.…”

“…Gadia and Chopra [GC93b] postulate the notion of spatial elements as spatial domains of interest to a user as any subsets of the universe of space, such that spatial elements are closed under union, intersection, subtraction and complementation. In contrast to existing languages for spatial data, [GC93b] favors weakly typed regions with no hierarchy among them and value dimensioning, i.e. adding dimension literally to the most primitive values in a model.…”

“…In Figure 5 and Figure 12, we have two designs for a personnel database: first for the object-relational model ORDimDB of this thesis, and second for the relational model [GC93b]. Although, these designs capture the same information, because of type inheritance in ORDimDB, the first also captures the complex semantics, an employee is a person and a manager is an employee.…”