User defined topological predicates in database systems

Abstract

Current database systems cannot only store standard data like $\underline{integer}$, $\underline{string}$, and $\underline{real}$ values, but also spatial data like $\underline{points}$, $\underline{lines}$, and $\underline{regions}$. The importance of topological relationships between spatial objects has been recognized a long time ago. Using the well known 9-intersection model for describing such relationships, a lot of different topological relationships can be distinguished. For the query language of a database system it is not desirable to have such a large number of topological predicates. Particularly the query language should not be extended by a lot of predicate names. It is desirable to build new relationships from existing ones, for example to coarse the granularity. This paper describes how a database system user can define and use her own topological predicates. We show algorithms for computing such predicates in an efficient way. Last, we compare these general versions with specialized implementations of topological predicates.

Appendix A: Used data sets

A.1 Database “Germany”

The database “Germany” contains cities, districts, rivers, and highways of Germany in the following relations:

$$ \begin{array}{l} {\textbf{district}} \\ (\text{DName : string, Area : real, Pop : int, Pop\_male : int, Territory : region}) \end{array} $$

where DName is the name of the district, Area is the area occupied by the region, Pop is the population in thousands, Pop_male is the amount of the male population in thousands, and Territory is a $\underline{region}$ value describing the territory of the district. The relation consists of 439 entries. The contained regions have 368 segments on average (50 minimum, 1,086 maximum). The regions within this relation form a partition of Germany, i.e. there are no overlapping regions. For this reason, we only can find equal, adjacent, or disjoint regions within the relation district.

$$ \begin{array}{l} {\textbf{river}} \\ (\text{RName : string, RNo : int, RRoute : line}) \end{array} $$

The relation contains 375 parts of rivers. The geometry is described in the attribute RRoute. The lines consist of 82 segments on average (five minimum, 471 maximum).

$$ \begin{array}{l} {\textbf{river2}} \\ (\text{RName : string, RNo : int, RRoute : line}) \end{array} $$

This relation contains the same data as the relation “river”. The difference is that here rivers are no longer divided into several parts. The relation contains 122 rivers with 251 segments on average (eight minimum, 1,010 maximum).

$$ \begin{array}{l} {\textbf{highway}} \\ (\text{HName : string, HNo : int, HRoute : line}) \end{array} $$

This relation contains 325 parts of highways of Germany. The size of the $\underline{line}$ value is 37 segments on average (one minimum, 217 maximum).

$$ \begin{array}{l} {\textbf{city}} \\ (\text{key : int, Name : string, Position : point,\ldots}) \end{array} $$

This relation comes from opengeodb [16]. It contains 17,409 cities (14,288 located in Germany). Besides the position also further but here unused attributes are stored.

Table 8 shows how many pairs of entries within the relations have intersecting bounding boxes.

Table 8 Number of intersecting bounding boxes

Furthermore, the database contains some “single” objects. This means objects stored outside a relation. In this paper we use the object “magdeburg” of type $\underline{region}$, which was extracted from the relation district.

A.2 Database “Sequoia”

The database “Sequoia” contains a subset of the Sequoia 2000 benchmark data [22]. Because we only are interested in the spatial attributes, we have also reduced the set of attributes. Within our paper, we only use the line and the polygon features of the benchmark. We have stored them in two relations with schemas:

$$ \begin{array}{l} {\textbf{SeqPoly}} \\ (\text{No : int, Reg : region}) \end{array} $$

$$ \begin{array}{l} {\textbf{SeqLines}} \\ (\text{No : int, Line : line}) \end{array} $$

The relations and attributes have the sizes described in Table 9.

Table 9 Sizes of the relations of the Sequoia database

To reduce the query time, we have created two smaller relations which are randomized subsets of the relations SeqLines and SeqPoly, each with size of 200 tuples.

Table 10 shows the numbers of overlapping bounding boxes for these relations.

Table 10 Numbers of intersecting bounding boxes