Download sandpres

An Overview of the SAND spatial
Database System
Claudio Esperanca
Hanan Samet
Presented By
Gautam Shanbhag
What is SAND?
SAND=Spatial + Nonspatial data.
Spatial Data=points,lines,regions…
example: rivers,city…
Nonspatial Data=height,name..
example: city-name…
Issues
As spatial and nonspatial data are intimately connected a
number of issues exist.
One issue is how to obtain an answer to a query
Example:
Find all cities within 100 miles of mississippi river having population
greater than X
There are number of possible query plans..
If x=small 1st spatial then nonspatial querying
Else if x=large 1st non-spatial then spatial querying
Spatial Data
When Queries involve the space occupied by the data
then we need to be able to retrieve data based on
some spatial properties which are not explicitly stored
in a database.
Problem of storing spatial properties in database
Volume of information is too high
Cost of preprocessing it is too high
Type of queries is not known beforehand
It is reasonable to compute queries on the fly if the
spatial data is stored in an appropriate manner
Storing Spatial Data
In order to deal with proximity and range queries,the
data must be sorted.
Data is sorted on the space occupied by the data
Conventional DBMS use other keys such as distance
from a location to sort the data.
This is useless for spatial data.
Spatial Indexing
R-tree
Bucket the data from MBR
Grouped by hierarchy(proximity)
Stored into structure like B tree
Drawback: In worst case we have
to search entire database
R+ tree
Decompose space into disjoint
cells which are mapped to buckets
Partitioning is arbitrary
Drawback:Decomposition is data
dependent
Uniform Grid
Quadtree
Space is decomposed into blocks
Space is decomposed by
of uniform size
adapting to distribution of data
Ideal for uniformly distributed
Ideal for arbitrarily distributed
data
data
Quadtree
SAND system requirements
A database engine capable of storing and retrieving
both conventional and spatial data
Access methods suitable for indexing and sorting
conventional and spatial data
A software library for computing spatial
operations,such as distance between two points
A GUI toolkit for displaying the queries
A way of combining these into query evaluation plans
SAND Kernel
SAND adopts an extended relational model
SAND Kernel
Tables are handled as regular disk files.Once a table
is open, a memory buffer is created for holding one
tuple which is read or written to the table.This is
called the Tuple Buffer
All data pertaining to a table is stored in a single
file,except when attribute is a container attribute
Container attribute is stored in a separate file and a
summary of it’s value and an identifier with its disk
location is stored with the regular attributes.
Attributes with complex spatial features are often
stored using containers.
Open Table Storage model
Table Types
All open tables support a minimal common set of operators like
open,close,get first tuple,get next tuple.
There are 3 table types:Relations,Linear indices,Spatial Indices
Relations are tables supporting direct access by tuple id(tid)
Goto tid may be used to jump to any existing tid
Linear indices are implemented as B-trees.Tuples in a linear
index are scanned by the order determined by their contents
Spatial indices are implemented as Quadtrees.The spatial
indexing is designed to permit the full contents of the table as
soon as possible.
Table types
Attribute types
SAND implements common non-spatial types(int,float,string..)
and also 2-D geometric types(point,line,segment,polygon..)
Non-spatial attributes support the compare operator which is
used to establish a total ordering among attribute values of
same type.
Spatial values support operators such as distance,intersect etc.
Some spatial features support additional features like expand
and coarsen.
SAND Interpreter
SAND Interpreter is implemented in Tcl which provides
integration with tk a toolkit for graphical user interfaces.
Most aspects of SAND can be controlled and programmed by
means of commands to SAND interpreter
The system can be extended by writing new methods or
strategies that are stored in a library of SAND scripts
The interpreter can be viewed as the unifying element of the
SAND system
SAND Browser
SAND browser provides GUI to the facilities of SAND
Visualization is done by specifying two types of controls:scan
order in which tuples are retrieved and an arbitrary selection
predicate.
Current implementations support only selections and semi
spatial joins.
SAND browser provides prompt visual feedback due to
incremental query processing capabilities
Conclusions
SAND is an ongoing project and new features are being added.
The table and attribute classes are being redesigned so that
addition of new attribute or table does not require modification
of interpreter command interface.
A full featured query optimizer would be incorporated into SAND
in the near future.
SAND has been used as a prototype of an image database
system.
Spatial Queries
The processing of spatial queries is supported by interpreter
commands associated with spatial attributes and spatial indices.
Spatial indices support ranking wrt a given spatial object.
Ranking in SAND is performed incrementally.This means that
once the parameters for a ranking operation are given,the first
tuple is returned as soon as possible.
Having computed the first k elements,to get the (k+1)st
element we need not sort k+1 elements but we can start from
the point at which we obtain the kth element.