A Recent technology direction: Storing new data types in an RDBMS
Spatial and Aspatial Data Integrity Constraints
Integrity constraints are crucial to and ensure the reliability of data managed in
an RDBMS. Spatial and aspatial data integrity issues must be considered in an
486.extended relational database technology. Database integrity is maintained
through commit and rollback mechanisms and data integrity constraints,
including geometric integrity, entity integrity, referential integrity, and check
constraints. Geometric integrity constraints, which are specific to each supported
geometric type, ensure that every spatial entity, either in director topological
form, is validated before the entity is committed to the database. Entity integrity
ensures that each row (i.e., defining an entity) in a table is unique. This is
implemented through the use of a primary key.
Referential integrity is essential for joining tables. In a pure relational context,
referential integrity ensures that when two tables are joined by a foreign key in
the main table, which is also a primary key in the joined table, the joined table
contains a row for each foreign key occurrence in the main table. From a spatial
data perspective, referential integrity also ensures that all components of a
topological entity exist within the database and that their combined geometric
form does not produce an invalid entity. Check constraints may also be specified
to check if values chosen for a particular attribute are appropriate.
Spatial Indexing and Performance
The objective of spatial indexing is similar to indexing facilities provided by the
commercial RDBMS. In both cases, optimized retrieval occurs when
qualifications are applied during a data selection. Leading-edge extended
relational databases incorporate a high-performance spatial indexing scheme
that is applied to each entity. As a consequence, each entity stored in a
conventional RDBMS table may be assigned one or more locational keys that
are derived from its spatial position and extent. In addition, the locational keys
may be “further” indexed using standard indexing facilities provided by the host
RDBMS that handle spatial indexes in the same way as aspatial indexes.
Be aware when evaluating extended relational database performance that a
number of factors must be considered to simulate times observed by a user. The
true test of performance is the actual retrieval and display time, including time
required to search a database, retrieve selected entities, render the results,
transfer the results through the network, and display them on a screen.
Long Transaction Support
Few extended relational databases icorporate an entity version management
system or long transaction mechanism. Long transactions typically require days,
weeks, months, or longer to complete. Tools should be provided to bring
database subsets under change management control without impacting the
master database. Under version control, all proposed changes to the database
should remain private to the current job and should be made public (i.e.,
published) after approval. When proposed changes have been executed, data is
then committed or posted to the database. In some products, preposted data
487.can be removed using a cancel process. If other proposals (i.e., proposed
changes to the database) are dependent upon data contained in a proposal to
be canceled, long transaction management prevents cancellation until all
dependencies have been removed. Long transaction management controls all
creation, modification, and deletion of data, while also providing a capability to
undo changes.
Key Criteria to Differentiate Extended Relational Spatial Database Products
In summary, when searching for a superior and appropriate extended relational
spatial database management technology for your project or problem, the
following key features should be kept in mind:
- Storage of all spatial and aspatial data in a commercially available
RDBMS
- Richness of extended relational data model
- Support for a large number of spatial data primitives, including network
primitives
- Near 1 to 1 mapping with key AM/FM/GIS industry standards, such as
the Spatial Data Transfer Standard (SDTS)
- Support for geometric and topologic representations
- Extensive integrity checking capabilities
- Extensive geometric and referential integrity checking capabilities
- SQL with spatial extensions to support buffering, enclosure, intersection,
adjacency, and other spatial operations
- Standards compliance, such as SQL, ODBC, and SDTS
- Support for a clientkerver architecture
- Comprehensive version management capabilities
- Support for long transaction management
- High-performance spatial indexing
