1. An Overview of the SAND spatial Database System Claudio Esperanca Hanan Samet Presented By Gautam Shanbhag

2. What is SAND? SAND=Spatial + Nonspatial data. Spatial Data=points,lines,regions… example: rivers,city… Nonspatial Data=height,name.. example: city-name…

3. 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 1 st spatial then nonspatial querying Else if x=large 1 st non-spatial then spatial querying

4. 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

5. 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.

6. 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 Space is decomposed into blocks of uniform size Ideal for uniformly distributed data Quadtree Space is decomposed by adapting to distribution of data Ideal for arbitrarily distributed data

7. Quadtree

8. 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

9. SAND Kernel SAND adopts an extended relational model

10. 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.

11. Open Table Storage model

12. 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.

13. Table types

14. 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.

16. 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

18. 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

19. 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.

21. 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.