Download FinalPaper_Presentation

“Codd’s Rules
for
Spatial ORDBMS”
How the assumptions of the Relational Model have been
relaxed to accommodate geographic data
Spatial ORDBMS implementations with
Oracle Spatial, PostGIS, and ArcSDE
Matt Stuemky
Presentation based on Final Paper
GEOG 582 (Spring 2008)
University of Southern California
Department of Geography
May 13 2008
1

Traditional relational model is excellent for storing and
managing business and transactional data, not as wellsuited for handling spatial data

Spatial data, even simple features (geometry - points, lines,
and polygons), are more complex than business data

Going beyond storing just vector-based spatial data:
how to efficiently store complex, raster-based spatial data?

All spatial ORDBMS should incorporate SQL-99 MM Spatial /
Open Geospatial Consortium (OGC) standards and
specifications to assure interoperability & consistency

OODBMS? Why are ORDBMS products favored over true
object-oriented DBMS? “Square pegs into round holes”

Support object-oriented concepts such as objects, classes,
methods, properties, and inheritance

RDBMS vendors provide high performance, high security, scalable,
very reliable RDBMS products that IT industry has gotten very
familiar with for several decades, including for GIS usage

Easier for RDBMS vendors to incorporate basic OO concepts into
their existing products and provide support for complex data
types compared to new vendors introducing true OODBMS
solutions
Spatial ORDBMS
object-relational
database management
system
•
•
•
•
•
•
Storage
Indexing
Security
Backup
Versioning
Long transactions
Database
Some issues and challenges with storing
geographic data in a RDBMS
May 13 2008
2
ArcSDE
Middleware solutions

ESRI: ArcSDE
Spatially enables RDBMS including ESRI
file geodatabases, Oracle, IBM DB2, Informix,
and SQL Server
RDBMS
◦ MapInfo: Spatialware
Integrated server solutions
◦ Oracle: Oracle Spatial
Oracle Spatial
PostGIS
Oracle
PostgreSQL
◦ PostgreSQL: PostGIS
open-source spatial ORDBMS solution
◦ Microsoft: SQL Server Spatial
(coming, late as usual, in 2008)
Some advantages of direct integration:


All DBMS core capabilities including security,
replication, use of triggers in one place
A common DBMS interface and tools to access
both spatial and non-spatial data
Spatial ORDBMS vendor solutions
May 13 2008
3

Enhancement of Codd’s First Rule: The Information Rule

Spatial ORDBMS must be able to support the storage
of geospatial data; all subsequent “rules” are the
detailed specifications that support this first rule.
PARCEL features
Instances of a Feature class
Instances of an Object class

Spatial databases in ORDBMS
must support (at minimum):









Complex (geometry) data types
Spatial data within related tables – feature classes, feature datasets
Validation rules - subtypes and domains
Spatial metadata
Spatial reference (coordinate) systems and transformations
Topologies and methods for analyzing spatial relationships
Geometric networks
Multi-dimensional, hierarchical indexes for searching spatial data
Storage of both spatial and non-spatial data in the same database
Rule 1: Basic framework for spatial databases
May 13 2008
4

Abstract real-world spatial information into distinct, identifiable entities – objects for
representing real-world geographic features (Shekhar & Chawla, 2003)

Amendment to the relational model: support for geometry data types, including
points, lines, polygons, and aggregations of these

Conform to the Open Geospatial Consortium
(OGC) Simple Features standard

Complex (composite) objects, representing
real-world geographic features, can be
created by incorporating these spatial data
types.
Geometry object model
Examples: Roads from lines, Parcels
from polygons, etc.

Instances of these spatial objects must be
able to be stored and managed within the
logical framework of relational tables.
© 2005 John Wiley & Sons, Ltd
Rule 2: Simple features and geometry data types
May 13 2008
5

Enhancement of Codd’s Rule #5: comprehensive data sublanguage and Rule #7:
High-level insert, update, and delete

“Spatial SQL”: OGC specification, Simple Features for SQL (SFSQL)

Use of WKT (Well-Known Text) and WKB (Well-Known Binary) formats for
inputting/outputting data

Basic methods for creating, updating and deleting spatial data using SQL syntax
PostGIS:
Create a new table; add a spatial
column (attribute) to it
PostGIS:
Create a new instance of a Road feature
(spatial object, linestring)
CREATE TABLE roads (road_id INTEGER,
road_name VARCHAR);
SELECT AddGeometryColumn( ’roads’,
’roads_geom’, -1, ’GEOMETRY’, 3 );
INSERT INTO roads (road_id, roads_geom,
road_name)
VALUES (1,GeomFromText(’LINESTRING(191232
243118,191108 243242)’,-1),’Jeff Rd’);

Operators and methods for querying spatial data
PostGIS:
Select query

Support for spatial analysis functions
Examples: distance (between two points), length
(of a line), area (of a polygon), buffer, etc.
SELECT road_id, road_name
FROM roads
WHERE roads_geom ~=
GeomFromText(’LINESTRING(191232
243118,191108 243242)’,-1);
Rule 3: Comprehensive spatial data language
May 13 2008
6

Enhancement of Codd’s Rule #10: Integrity Independence

Spatial ORDBMS must support topologies


Store / manage shared geometry (node, edge, and face elements)
Enforce spatial data integrity rules
Examples: no gaps between parcels, no overlapping parcels, etc.

SQL operators and methods for evaluating
spatial relationships
PostGIS:
Select geometry objects based on spatial
relationship with other geometry objects
SELECT id, the_geom
FROM geotable
WHERE
the_geom && ’POLYGON((0 0, 0 10, 10 10, 10 0,
0 0))’
AND
_ST_Contains(the_geom,’POLYGON((0 0, 0 10, 10
10, 10 0, 0 0))’);
Spatial relationship methods









Equals – same geometries
Disjoint – geometries share common point
Intersects – geometries intersect
Touches – geometries intersect at common
boundary
Crosses – geometries overlap
Within– geometry within
Contains – geometry completely contains
Overlaps – geometries of same dimension
overlap
Relate – intersection between interior,
boundary or exterior
Rule 4: Topologies and evaluation of spatial
relationships
May 13 2008
7

Single-dimensional index methods such as B-trees not sufficient for indexing spatial
data; spatial ORDBMS must support multi-dimensional indexing

Common spatial access methods (SAMs): Grid, Point Quadtrees, Region Quadtrees,
R-trees, and variations of these

Oracle Spatial primarily uses R-tree indexes but supports Quadtree-based indexes;
PostGIS uses an R-tree index implemented on top of a GiST (Generalized Search
Trees) index
Region Quadtree
R-tree
© 2005 John Wiley & Sons, Ltd
Rule 5: Spatial access methods (SAMs)
May 13 2008
8

No OGC-based standards for raster-based spatial data?

More complex implementation than simple (geometry) features

Support for storing both image-based (satellite remote
sensing, airborne photos, etc.) and grid-based (digital terrain
elevation, land cover information, etc.) raster data

ORDBMS raster architecture:




Raster object type
Indexing of raster data
Raster metadata
SQL API for inserts, updates, and queries
◦
Requires a substantial amount of storage
space and numerous tables in database

Proprietary solutions:
 Oracle Spatial: GeoRaster; now available
 PostGIS: PGRaster is a very similar
implementation to Oracle’s GeoRaster;
product is still under development
◦
© 2008 Oracle Corporation
Further demonstrates how far the relational model has been relaxed to accommodate
geographic data
Rule 6: Raster-based geospatial features
May 13 2008
9

Enhancement of Codd’s Rule #11: Distribution Independence

Allow seamless storage, retrieval and exchange of data in spatially-enabled
databases (queries with both homogonous and heterogeneous databases) across
distributed systems, including network servers and the Internet for web-based
systems.

Older OGC specifications for simple features distribution between applications and
other RDBMS:



Newer OGC standards and specifications for spatial data distribution on the
Internet/World Wide Web:




OLE/COM and CORBA specifications
Define how APIs should handle the storage, retrieval, and exchange of vector-based (point,
line, polygon) spatial data
Web Feature Service (WFS) specification for simple features (vector-based) data
Web Coverage Service (WCS) standard for raster-based data
Geography Markup Language (GML) encoding standard for exchanging geospatial data
Oracle Spatial, PostGIS, and ArcSDE provide support for:


Synchronized replication of spatial data between databases over local and wide area networks
(also: version reconciliation and long transaction support)
Exchange of spatial data on the web using WFS, WCS and GML.
Rule 7: Spatial data across distributed systems
May 13 2008
10