A Recent technology direction: Storing new data types in an RDBMS
Paul J. Yarka
Director of Product Management, Convergent Group
6200 South Syracuse Way, Englewood, CO 80111
Phone: 303-741-8484, Fax: 303-741-8456
Abstract
Vendors and customers are gaining experience in the implementation of
AM/FM/GIS systems that allow users to store spatial and aspatial data in a
relational database management system (RDBMS). Today’s latest commercial
AM/FM/GIS product offerings enable the storage of point, line, polygon, complex
polygon, topology, connectivity and other spatial primitives in either an extended
or object-relational database. The technology advance of efficiently storing and
retrieving spatial data from an RDBMS, along with the ANSI and ISO standards
efforts of the SQL MM and SQL 3 organizations enhances the long-term viability
and attractiveness of relational data stores that are now being used to store and
manage vector and raster data.
Introduction
Imagine calling your gas utility company because you want to install a gas
fireplace in your home and need to have a new service line installed. The
customer service representative who answers your call asks for your address
and accesses your account. Using a customer information system connected to
an AM/FM/GIS, he or she constructs and views a map of your home, a nearby
main, and the local gas distribution network. Using this information, the two of
you discuss a preferred route for the required gas line, taking into account such
things as the location of your driveway, landscape, other utility services, and the
existing gas utility easement.
The customer service representative quickly designs the new gas line on a
computer screen, provides a cost estimate, and schedules the installation with
you and the utility’s construction crew. An installment payment plan is arranged
for your monthly billing, and preliminary design plans, appropriate work orders,
and a permit request are generated.
From your perspective, with one simple telephone call you have set into motion
the installation of your gas fireplace. From the utility company’s perspective, only
one trip to your house is required, your request has been satisfactorily serviced,
a digital engineering design with required gas equipment has been stored in an
organization-wide database, and the construction crew has updated the same
database with a field-checked and modified version of required equipment in its
as-built state.
Eliminating Technology Boundaries with Extended Relational Spatial Databases
Clearly, GIS software technology has automated manual processes to help
multiple users and departments orchestrate the planning, design, construction,
and maintenance of infrastructure. However, with most competitive AM/FM/GIS
products, spatial and aspatial data are stored in different database management
technologies and, consequently, are isolated. Aspatial or tabular data are
typically stored in a commercial RDBMS, while spatial data are frequently stored
in a proprietary binary file structure.
Recent software developments now make it possible for entities with spatial and
aspatial attributes to be stored entirely in an RDBMS. Once restricted to
specialized functions, users and departments, spatial information, and
manipulation tools are now “mainstream-accessible”; in other words, they can be
seamlessly integrated with aspatial corporate data repositories. Extended
relational spatial databases are typically layered on top of commercial RDBMSS
(Fig. 1), enabling easy access and manipulation of spatial data from the same
data store used for storing and managing aspatial corporate data. Effective
spatial data management capabilities are crucial to implementing spatial
information systems, automated mapping, facilities management, geographic
information systems, and computer-aided design. With extended relational
technology, a single database management approach can be used to store and
manage data for enterprise users with diverse application interests.
Extended relational databases increasingly are clientkerver-based providing
transparent access to the underlying commercial RDBMS. In some cases,
applications may be developed using an API that is designed on key database
and software industry standards, such as Microsoft’s Open Database
Connectivity (ODBC) standard. Products in this niche also offer spatial
extensions to Structured Query Language (SQL). Using SQL with spatial
extensions, users can add various spatial operators to their SQL queries and
qualify entities using aspatial and spatial constraints. One key advantage is that
through APIs that are based on key standards and SQL with spatial extensions,
widespread enterprise access for spatial data is now possible, thereby
eliminating the required use of proprietary formats for spatial data storage.
Figure 1. Typical architecture of an extended relational spatial database
platform.
Key features to look for in extended relational spatial databases include the
following:
- Full compatibility with RDBMSS
- Use of an extended relational data model and integrated geometry processing
- Spatial data validation through geometric and referential integrity checking
- Incorporation of a broad offering of spatial data primitives
- Spatial indexing for fast data retrieval based on spatial selection
- Client/server architecture
- SQL with spatial extensions for rapid application development and ad hoc
query
- Application programming interface
- Integrated job management (long transaction) support
