Cindy Munns

Principal Systems Engineer, Informix

Early information systems revolved around data entry applications, those that automated business functions. These applications, such as spreadsheets and word processing, accessed text and numeric data, and in many cases were single user systems. RDBMS systems evolved in the 1970�s in response to the need to support many users, where there was also a need for a query environment.

Over the last twenty years, the types of data supported by applications has become more complex�it is not enough for a DBMS to support only alphanumeric data. Maps, audio, video, text, images are now commonly used in applications, especially in the Internet world. Object Databases were created to support complex data, those that needed an object infrastructure to define classes and methods for use. While Object Databases are useful for solving complex problems , and working with complex data, they suffer from two shortcomings:

1. They do not scale to large concurrent user communities.
2. They do not readily support an easy-to-use query environment.

Enter Object Relational Databases. An ORDBMS takes the ease of use/implementation/administration/scalability of a traditional RDBMS and combines it with the flexibility of an Object Model. It is essentially the ability to extend your database to support any data type or business function.

• As an example, an image Blade could define image types, with specific attributes, image functions that allow for image manipulation, and special access methods that provide for fast image retrieval. A Blade could also have a client interface, such as an image display graphical front end.

The above figures illustrate the dramatic potential for performance improvement by defining types and functions directly in the database server. If a function result can be calculated directly in the database, we don�t need to ship all the data to the client application, across a network which has a throughput speed many times slower.

SDE for Informix is a database plug-in that creates:

• spatial data types
• spatial functions
• spatial indexes
• that are managed directly by the database server
• allows you to access spatial data using: Esri tools, ODBC, SQL, Java.

How is it different from using a traditional database? Answer: With a standard RDBMS, SDE does all the work. Data types and functions are emulated by the database.

• Result: Performance!

• Height balanced
• Works by eliminating as rapidly as possible non-matches for a range of spatial predicates:
• Contains
• Within
• Overlap
• Equal

• Trees -> 2 phase locking
• Parallelism is no-brainer
• Good-worst case access
• Works for Points and Regions
• Concepts broadly applicable

Ease of Use

• Lower administration overhead
• Easier and faster setup
• Performance
• Largest database size
• Largest number of users
• Most complex queries

Lower cost of ownership

• Achieve better performance with less hardware
• Less outside consulting needed

Goals: 

Goal: To unify government land-related activities. Allow remote land validation by solicitors, surveyors, and staff . 

a) act as a data store (Geographic Data Warehouse) for multiple applications including CAD data from MicroStation which is directly stored and accessed using SDE CAD Client extension.

b) act as the central spatial data server for web-based and other Esri applications .

Developed by - USGS Energy Resources Program, Reston, VA.

Architecture - Java applet GIS browser accessing Informix UDO and the Esri SDE Datablade through JDBC.

Functionality - displays overlayed maps (vector), images (raster) and tabular data. Interactive Java interface can build a query, turn layers on and off, pan and zoom, etc.

Key points -

• This applet maps actual vector data coming from the database (vs. GIF files) by accessing spatial functions directly through SQL using JDBC.
• SQL function calls can be nested in a single query.
• Users can save maps as graphic files but also download/save coverages as vector data.
• Meeting 10 second response time goal for all queries.
• Come see the live system in our booth!

As an example of performance, one operation needed to create a multi-polygon from approx. 190,000 features (polygons). If this operation were executed by the client application, all 190,000 rows would need to be shipped down to the client. Use of a Stored Procedure that invokes the Blade functions allowed just 119 rows to be returned to the client, which resulted in response time reduction from 2 minutes to 4 seconds.