Reducing index size for multi-level grid indexes

The number of index entries in a grid index for indexing geometric shapes is reduced by establishing a pool storage area for geometric shapes, selecting a threshold number of grid cells which a geometric shape may overlap, storing the shape in the grid index if a geometric shape overlaps a number of grid cells not exceeding the threshold number, and storing the shape in the pool storage area if the geometric shape overlaps a number of grid cells which exceeds the threshold number.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to U.S. application Ser. No. 10/144,058, filed May 10, 2002, entitled “Systems, Methods, and Computer Program Products to Improve Indexing of Multidimensional Databases,” the entire contents of which are incorporated herein by reference.

The present application is also related to U.S. application Ser. No. 10/144,389, filed May 10, 2002, entitled “Systems, Methods, And Computer Program Products To Reduce Computer Processing In Grid Cell Size Determination For Indexing Of Multidimensional Databases,” the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is directed to the field of computer-based database management systems. It is more particularly directed to reducing index size when grid-indexing techniques are applied to multidimensional data stored in a database management system.

2. Description of the Background Art

Indexing techniques are used to quickly access data that has been sorted and assigned an index. Spatial data is typically information associated with geometric shapes such as lines, points, poly-lines, polygons, and surfaces. Spatial data is often very large and may have two, three, or more dimensions. Spatial data may be indexed. Indexing such data by traditional techniques, such as with a B-tree, may not be feasible due to the large amount of computer resources required to index spatial data. Further, B-tree indexing is typically associated with single-dimensional data, not multidimensional data. Therefore, sorting capabilities associated with B-tree indexing are typically not sufficient to be efficiently applied to multidimensional data. To reduce data processing time, various spatial indexing techniques have been studied and developed. Grid indexing is one of these indexing techniques associated with searching spatial multidimensional data, and is used by the product marketed under the trademark IBM DB2® Spatial Extender.

An index enables fast access to a certain subset of data contained in a larger set of data. The index can include a data structure and indicators of the techniques used to build, maintain, and search the data structure for the purpose of accessing a subset of data. For example, an index may define a data structure that is used to access a specific geometric shape included in a set of spatial data. The particular index of the present example may define a data structure that contains references to the minimum-bounding rectangles associated with various geometric shapes in a spatial data set. By accessing locator references associated with the minimum-bounding rectangles the process of accessing particular geometric shapes in a spatial data set is simplified.

A grid index is a space-partitioning. It divides space into rectangles (or squares) called grid cells, using a mathematical formula to determine the boundaries of the grid cells. One approach for such a formula is to define a grid cell size and to lay each boundary as a multiple of the grid cell size. When indexing spatial objects (geometries), the geometries are overlaid with the so defined grid. Depending on the size of the geometry and the grid cell size, a geometry might overlap with more than one grid cell, i.e. it crosses a boundary between grid cells.

When a geometry is indexed in an index maintenance operation, an index key is stored in the index for each grid cell that overlaps with the geometry. Usually, the index entry uniquely identifies the grid cell for which the overlap was noted. For example, the identifier used for the index can be any point in the grid cell, such as its lower-left corner, or its center. Alternatively, other techniques for identifying the overlapping grid cell can be used for the identifier, such as dividing the coordinates by the grid size. For example, using a grid size of 10 with the coordinate value (46,32) and performing integer arithmetic would identify the grid cell (4,3) where “4” represents the fourth grid cell in one dimension and “3” represents the third grid cell in another dimension.

Several approaches exist to improve performance of the index maintenance. As previously mentioned, the geometry itself is abstracted by its minimum-bounding rectangle (MBR). That allows for a very simple and fast way to identify the grid cells that overlap with the MBR.

As can be appreciated, a geometry, or its MBR, potentially can overlap many grid cells. Although the computation of the identifiers for all the overlapping grid cells is straightforward if the geometry is abstracted, the task to compute all those identifiers grows linearly with the number of overlaps encountered. Also, storage is needed for all the index entries, which effectively increases costs for storage, and also increases the cost of evaluation of the index because more index entries have to be processed at query time.

A conventional approach to reduce costs is to introduce multiple levels of grids, each level with a different grid size. A geometry is indexed at exactly one grid level. Accordingly, with a larger grid size, fewer index entries are produced. However, the downside of using larger grid sizes is that they do not provide as fine a resolution as smaller grid sizes.

Some implementations of grid indexes (e.g., a grid index implemented in the DB2® Spatial Extender) use a fixed number that sets the maximum number of levels. Although using multiple levels reduces the problem of having many index entries for large geometries, the problem does not entirely vanish. Even at the coarsest grid level, an extremely large geometry can produce thousands of index entries. Also, the grid sizes for the multiple levels are usually tuned to work best for the common set of data and are not tuned for handling such exceptions.

To provide an example, assume two grid levels and the data set to be indexed is the street network of the United States of America. One will probably choose a very small grid size to accommodate the short streets in neighborhoods. The second grid size might be used to accommodate longer streets in cities or between cities. Consider now a road like the I-40 highway, that crosses the entire continent from west to east. Indexing this road on either of the two levels produces a vast number of index entries, whose computation is expensive and which greatly increases the number of indices. This complicates the maintenance of the indices and impacts the data processing capabilities of a database management system underlying the storage of the spatial data.

A conventional approach to handling such large geometries is not to allow such geometries to be indexed at all. If a geometry would produce more index entries than what is defined by a threshold, an error is returned in that conventional approach. In a database context such as the context in which the DB2® Spatial Extender runs, this implies that an insert or update operation would abort due to error.

The conventional approach leaves the user with a number of potentially unattractive options, e.g. to not use an index at all, to not insert the geometry, to break the geometry up into smaller pieces, or to change the index definition to use coarser grid sizes and thus reduce the number of entries produced. A problem with this last option is that changing the index impacts existing data, possibly making performance of the overall index worse.

SUMMARY OF THE INVENTION

Methods of reducing the number of index entries in the formation of a grid index are described that include establishing a pool storage area for storing a pool of geometric shapes. A threshold number of grid cells which a geometric shape may overlap is selected and it is determined how many grid cells a geometric shape overlaps. If a geometric shape overlaps a number of grid cells that does not exceed the threshold number, an index for the shape is stored in the grid index. If a geometric shape overlaps a number of grid cells exceeding the threshold number, an index for the shape is stored in the pool storage area.

Also described here are methods of querying both a grid index of first geometric shapes that includes a plurality of indexes and a pool of larger, second geometric shapes. The method includes evaluating the grid index of first shapes to produce a group of one or more candidates based on cells designated in a query that overlap respective first shapes in the index. The geometric shapes from the pool are added to the group of candidates to produce an interim group of candidates. The interim group of candidates is filtered by comparing a query area specified in the query with approximations of the candidates of the interim group to produce filtered candidate objects. Those filtered candidates that satisfy the query are determined by comparing the first and second geometric shapes corresponding to the filtered candidates with the query area. The shapes that overlap with the query area are determined to satisfy the query.

Usage of a storage pool for large geometric shapes reduces the number of entries in the index and improves maintenance and use of the index.

DESCRIPTION OF THE INVENTION

As shown inFIG. 1A, a method of indexing large geometries and using those indices can operate in a client-server computer system100configuration. Therefore, a client computer system104can communicate with a server computer system102during such operation. An index-pool module120operates in either the client104or the server102to store and use such indices. For example, information can be communicated to either the server102or the client104via a user interface117and subsequently can be used by an index-pool module120to perform a query operation regarding geometric shapes. The user interface117can include either a user input unit118and/or a batch input unit119.

Further, a multidimensional data cube106can be configured in the memory of either the client104or the server102. Alternatively, a multidimensional data cube106can be configured in computer storage such as that of a disk122. Spatial data124is a specific type of multidimensional data110that can be stored on disk122. The terms “multidimensional data cube” and “data cube” will be used interchangeably herein.

FIG. 1Bis a block diagram that illustrates the index-pool module120used to operate on the spatial data124. Spatial data124and other elements of the index pool module120are described below with reference toFIG. 1Aand elements202,204, and206of a multidimensional data cube106are described with reference toFIG. 2A. A technique for partitioning space into grids202can include ascribing different levels138to the partitioned space. The levels138can represent partitions of the space at various resolutions of the cells206of the grid202. Such levels138can be used in connection with designating indices for large geometries. The variable “N,” represents the number of grid levels142. If the number of grid cells146exceeds a user-defined limit151the next level138of information is determined. Grid index132stores geometric shape information and is used to search spatial data124.

A geometric shape identifier (ID)134is used during the operation to identify a geometric shape so that the information associated with the geometric shape204, as shown inFIG. 2B, can be indexed. The geometric shape ID134and the associated level138information are combined into the geometric shape ID134that is a single, unique value. That single, unique value is identified with the associated grid cell206. Information about higher level abstractions of a geometric shape, such as its minimum boundary rectangle, can be stored with the exact geometric shape or can be stored separately from it, such as in the index for the geometric shape. An SQL query that calls a “key generator” function139can be used to create index entries associated with each geometric shape204.

Storage pool158is a storage area that can, be a separate data structure or can be embedded within the same data structure as the index. If the latter approach is chosen, the separate pool can be modeled as a special grid level, that has its own identifier but no associated grid size. Those geometries that exceed a certain threshold(s)159are stored in the storage pool158. A special query function160that includes data in both the grid index132and the storage pool158is included in the index pool module120. A query box area “Qb”140is the average size of an area that is analyzed. The area covered by Qb140may be smaller than the size of the extent of data that is analyzed149. A preferred grid cell size “G”148can be determined, as disclosed in U.S. patent application Ser. No. 10/144,058, entitled “Systems, Methods, and Computer Program Products to Improve Indexing of Multidimensional Databases,” filed May 10, 2002, the entire contents of which are incorporated herein by reference.

As shown inFIG. 2Athe multidimensional data cube106can be suitably configured for operation with the geometries to be processed. The grid202represents the decomposition of data into units that may be uniform or of varying size. Grid cell206is a specific instance of a unit contained within a grid202. Specific examples of grids202include the “X” dimension grid that is shown in element208, the “Y” dimension grid that is shown in element210, and the “Z” dimension grid that is shown in element212.

FIG. 2Billustrates a two-dimensional grid202. A preferred embodiment operates on spatial data124, shown inFIG. 1A, that is information that represents geometric shape204. The two-dimensional grid202includes examples of an X dimension grid208and a Y dimension grid210. Further, the X dimension grid208includes six units and the Y dimension grid210includes five units. The two-dimensional grid202includes grid cells206that can be referenced by the units of the X dimension grid208and the Y dimension grid210. The geometric shape “A” as shown in element220, the geometric shape “B” as shown in element222, and the geometric shape “C” as shown in element226are each bounded by minimum bounding rectangles (MBRs)224a,224band224c, respectively. The variable Qb140represents a query box size and in this example Qb140overlaps two grid cells206.

Also present inFIG. 2Bare geometric shapes228and230, which are larger than the other geometric shapes. For example, in a geographical context shapes228and230could represent long roads such as transcontinental highways. A better idea of the potential size of shapes228and230may be had by referring toFIG. 2Cwhich shows a larger portion of the grid overlaid on these shapes. In actuality, shapes228and230could overlap thousands of grid cells. Here, large shapes such as228and230are excluded from the grid index and instead are stored in a storage pool.

FIG. 2Dis a block diagram that illustrates a table240relating geometric shapes204with geometric shape identifiers134.FIG. 2Dalso shows the index data structure251. An SQL statement can be used to generate the index data structure251that includes geometric shape ID's134and grid cell ID's245. For example, the geometric shape A220as shown inFIG. 2B, is associated with the Row-A geometric shape ID, as shown in element248. Also, the geometric shape B222as shown inFIG. 2B, is associated with the Row-B geometric shape ID, as shown in element250. Further, the geometric shape C226as shown inFIG. 2B, is associated with the Row-C geometric shape ID, as shown in element252.

The geometric shape ID134and the grid cell ID245can be used jointly as an index to locate a specific geometric shape204. Indexes provide quick access to data and can enforce uniqueness on the rows in the table and include index entries, such as index entry273which is an entire row in the index data structure251, and includes a grid cell ID245and a geometric shape ID134.

The index data structure251is used to associate each grid cell206that overlaps with the MBR of a geometric shape thereby enabling searches of the information associated with a geometric shape. For example, the MBR of geometric shape A, as shown in element224aofFIG. 2B, overlaps will the following grid cells206; grid cell (1,3) as shown in element253ofFIG. 2D, grid cell (2,3) as shown in element254, grid cell (3,3) as shown in element256, grid cell (1,4) as shown in element258, grid cell (2,4) as shown in element260, and grid cell (3,4) as shown in element262. Elements253,254,256,258,260, and262are therefore associated with Row-A geometric shape ID, as shown in element248.

Similarly, the MBR of geometric shape B, as shown in element224bofFIG. 2B, overlaps with the following grid cells206; grid cell (4,2) as shown in element264ofFIG. 2D, grid cell (5,2) as shown in element266, grid cell (4,3) as shown in element268, grid cell (5,3) as shown in element270, grid cell (4,4) as shown in element272, and grid cell (5,4) as shown in element274. Elements264,266,268,270,272, and274overlap with the MBR of geometric shape B and are therefore associated with Row-B geometric shape ID, as shown in element250.

Also, the MBR of geometric shape C as shown in element224cofFIG. 2Boverlaps with the following grid cells206; grid cell (1,5) as shown in element275ofFIG. 2D, grid cell (2,5) as shown in element276, grid cell (3,5) as shown in element277, grid cell (4,5) as shown in element278, grid cell (1,4) as shown in element279, grid cell (2,4) as shown in element280, grid cell (3,4) as shown in element281, and grid cell (4,4) as shown in element282. Elements275,276,277,278,279,280,281, and282are therefore associated with Row-C geometric shape ID, as shown in element252.

Conceptually, and optionally in practice, the storage pool is a separate and distinct storage area from the grid index. Because a filtering operation will be applied to all of the geometric shapes in the storage pool to determine if they are candidates for satisfying a query, there is no need to index those shapes in the storage pool. Accordingly, the storage pool can include a pool data structure that contains only identifiers of the geometric shapes stored in the pool. When the filtering operation occurs, all the identifiers in the storage pool are output so that those geometric shapes in the pool can be filtered. Here, the filtering is performed on the MBRs of the geometric shapes identified in the storage pool, and the MBRs of the geometric shapes in the pool can be stored in the storage pool data structure.

Alternatively, identifiers of the large geometric shapes that exceed a certain threshold, and hence are stored in the pool, can be stored in the grid index data structure along with the grid indexes.FIG. 2Eillustrates a pool data structure282that is part of the grid index data structure. As shown inFIG. 2Ethe pool data structure282includes a pool ID field283and a geometric shape ID field284. The geometric shape ID is an identifier for a geometric shape that is so large as to exceed the threshold. Because geometric shape IDs in the pool are recorded with the grid cell indexes, an identifier is needed to designate those large geometric shapes as belonging to the pool and not to the grid index. The pool ID serves that purpose and can be any identifier that is different from the grid cell IDs245, shown inFIG. 2D. An example of such a pool ID is shown inFIG. 2Ein which an unused grid level, in this instance grid level “0”, operates as an indicator that the associated geometric shape is part of the pool and not part of the grid index. InFIG. 2E, the geometric shape “D” has a geometric shape ID284aof “Row_D” and an associated pool ID283aof “Level0.” Similarly, another entry in the pool, geometric shape “E”, has a geometric shape ID284bof “Row_E” and an associated pool ID283bof “Level0.” Although the pool IDs of shapes “D” and “E” are identical, namely “Level0”, they serve to designate those shapes as part of the pool and not part of the grid index.

Similar to table240inFIG. 2D, a table285inFIG. 2Erelates a geometric shape ID286with a geometric shape288. Here, the geometric shape ID286afor shape “D” points to the area where geometric shape “D”288ais stored. Similarly the geometric shape ID286bfor shape “E” points to the area where geometric shape “E”288bis stored.

The flow diagram ofFIG. 3Aillustrates formation of the grid index and storage in a storage pool. A grid is first laid over the MBRs of a geometric shape, as depicted by operation301. A determination is then made as to whether the shape overlaps more than a threshold number of grid cells, as depicted by element302. If the threshold of grid cells is not exceeded than the geometric shape is stored in the grid index251as depicted by element303. However, if the geometric shape overlaps more than the threshold number of grid cells, an index for the geometric shape is stored in the storage pool, as depicted by element304.

In one embodiment, the threshold number of grid cells is thirty cells, it being understood that a smaller or larger number may be preferred in accordance with the specific application. Accordingly, geometries overlaying more than thirty cells will have a single index for the geometry stored in the pool280and will not have a plurality of indices stored in the index data structure251.

Instead of using a grid having a single level, it may be preferable to use a multi-level grid, which for example could have three levels of progressively increasing grid cell size. Referring toFIG. 3B, which, is a flow diagram for such a system, a grid at level1(the finest level) first would be laid over a geometric shape as depicted by element312. A determination would then be made as to whether the grid at level1overlaps more than a defined limit number of grid cells, which for example could be four grid cells, as depicted by element314. If the shape does not overlap more than four cells, then level1is used for indexing of the geometric shape, as depicted by element316. On the other hand, if the shape does overlap more than four grid cells, the next coarsest grid level is used, and the same determination is made, as depicted by elements318and320. If the grid cell overlaps more than four grid cells then progressively coarser grids are used, and the finest grid level at which not more than four grid cells are overlapped is used for grid indexing, as depicted by element322.

If even at the coarsest grid level more than four grid cells are overlapped, then a determination is made if more than the threshold number of grid cells is overlapped, as depicted by element324. If fewer than the threshold number are overlapped, than the coarsest grid level is used for grid indexing, as shown by element326. However, if the threshold number is exceeded, then indices for the geometric shape are not placed in the index data structure, but rather one index for the entire geometric shape is placed in the storage pool, as depicted by element328.

As previously described, use of the pool is advantageous because it reduces the number of entries in the grid index. Computation of such index entries is expensive, and maintenance of the index is simplified by the reduction in size. Use of the present invention is effective to enhance index performance for the rest of the data in the index.

When the grid index is queried to retrieve selected geometric shapes, the storage pool must be queried as well so as to consider all shapes. A flow diagram that illustrates an embodiment of the query operation is shown inFIG. 3C. This flow diagram is to be considered in connection with the grid, associated geometric shapes and query box140shown inFIG. 2B.

Referring toFIG. 2B, the query box140defines the area of interest in which it is desired to search for certain geometric shapes. For example, the query box may be drawn on a monitor screen by an operator performing the query operation, and may represent a geographical area having geographical features with different geometric shapes.

Referring toFIG. 3C, first of the grid indices is evaluated, depicted by element340. Referring again toFIG. 2B, the grid index evaluation step determines from the index information held in the index data structure251(FIG. 2D) whether the MBR of any geometric shape is present in the grid cells overlapped by the query box, that is, whether the MBR of any shape overlaps grid cells (4,5) or (5,5). Referring to the grid index shown inFIG. 2D, a shape is determined to be present in cell (4,5) but not in cell (5,5). Therefore, cell (4,5) is retained as containing a candidate shape, while cell (5,5) is no longer considered in the evaluation. Because very large shapes are not indexed in the index data structure251, grid indexes for those shapes are not evaluated in operation340, thereby saving computational time and resources.

Next, in operation344possible shapes in both the index and pool are filtered based on the location of the MBR of the candidate shapes and the query box. It is at this step that all geometries from the pool are added to possible candidates from the index.

Referring again toFIG. 2B, it is seen that the right, vertically oriented side of the MBR of shape “C” falls within the query box140. Hence, the MBR of shape “C” overlays the query box and accordingly shape “C” survives the filtering344and remains a candidate. The grid itself is not used in the filtering344, but rather there is a positional determination of whether there is an overlap between the MBR (which can be stored in the grid index) and the query box. The positional determination can be a computation of whether the maximum X coordinate of either of the rectangles falls between the minimum and maximum X coordinates of the other rectangle, and if so, whether the maximum Y coordinate of either rectangle falls between the minimum and maximum Y coordinates of the other rectangle.

The geometries in the pool are also filtered at element344based on whether there is an overlap between their MBR's and the query box. As can be seen by referring toFIG. 2B, there would be an overlap of the MBR (not shown) for shape “D”228and the query box, so both shape “C” from the index and shape “D” from the pool survive the filtering, while shape “E”230from the pool does not.

Next, for the remaining candidate shapes that survive MBR filtering, operation346determines whether the exact geometric shape for each remaining candidate falls within the query box140. Pointers to the exact shape information are stored within the grid index or within the storage pool for large geometries. As can be seen by referring toFIG. 2B, the rightmost point of shape “C” falls within the query box, so the determination for shape “C” is that the exact shape is within the query box. Similarly, the exact shape “D” falls within the query box, so the same determination is made for that shape. Suitable algorithms for making the exact shape computation are well known to those skilled in the art. In this manner geometric shapes that intersect a query area are returned.

According to the above procedure, all geometries from the pool are added to the set of possible candidates from the grid index evaluation. This ensures that no geometry will be missed during the query process.

Of course, a drawback is that a geometry from the separate pool might have been eliminated in the grid index evaluation if it were indexed in the grid index, but now it is added to the set of possible candidates due to the processing of the separate pool. However, only very few geometries should be in the separate pool. If there are many geometries, those would not be special cases but rather common cases and the grid index should be tuned for them. But if the grid index is tuned for them, these geometries would be in the grid index itself and not in the separate pool. Also, the last two operations in the query are: (a) filtering based on the MBR344, and (b) using the exact geometry to determine the result346. If a geometry would have been filtered out by the grid index evaluation but is now added by the separate pool, operation (a) will filter it out before operation (b) performs the more expensive calculation, so the impact is rather marginal.

FIG. 4is a block diagram of a computer system400, suitable for employment of the methods described here. System400can be implemented on a general-purpose microcomputer, such as one of the members of the IBM Personal Computer family, or other conventional workstation or graphics computer devices, or mainframe computers. In its preferred embodiment, system400includes a user interface417, a user input device407, a display415, a printer420, a processor455, a read only memory (ROM)450, a data storage device122, such as a hard drive, a random access memory (RAM)440, and a storage media interface435, all of which are coupled to a bus425or other communication means for communicating information. Although system400is represented herein as a standalone system, it is not limited to such, but instead can be part of a networked system. For example, the computer system400may be connected locally or remotely to fixed or removable data storage devices122and data transmission devices445. Further the computer system400, such as the server computer system102or the client computer system104shown inFIG. 1A, also could be connected to other computer systems via the data transmission devices445.

The RAM440, the data storage device122and the ROM450, are components of a memory unit458that stores data and instructions for controlling the operation of processor455, which may be configured as a single processor or as a plurality of processors. The processor455executes a program442recorded in one of the computer-readable storage media described above, to perform the methods of the present invention, as described herein.

While the program442is indicated as loaded into the RAM440, it may be configured on a storage media430for subsequent loading into the data storage device122, the ROM450, or the RAM440via an appropriate storage media interface435. Storage media430can be any conventional storage media such as a magnetic tape, an optical storage media, a compact disk, or a floppy disk. Alternatively, storage media430can be a random access memory440, or other type of electronic storage, located on a remote storage system.

Generally, the computer programs and operating systems are all tangibly embodied in a computer-readable device or media, such as the memory458, the data storage device122, or the data transmission devices445, thereby making an article of manufacture, such as a computer program product. As such, the terms “computer program product” as used herein are intended to encompass a computer program442accessible from any computer readable device or media.

Moreover, the computer programs442and operating systems are comprised of instructions which, when read and executed by the computer system400, cause the computer system400to perform the steps necessary to implement and use the methods and systems described here. Under control of the operating system, the computer programs442may be loaded from the memory458, the data storage device122, or the data transmission devices445into the memories458of the computer system400for use during actual operations. Those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope of the present invention.

The user interface417is an input device, such as a keyboard or speech recognition subsystem, for enabling a user to communicate information and command selections to the processor455. The user can observe information generated by the system400via the display415or the printer420. The user input device407is a device such as a mouse, track-ball, or joy-stick, which allows the user to manipulate a cursor on the display415for communicating additional information and command selections to the processor455.

While operating in accordance with the present invention, the system400determines which geometric shapes in the database are to be loaded into the grid index and which into the storage pool. It also operates to query both the grid index and storage pool in such manner that all geometric shapes are considered during the query operation.

The methods and systems described here are typically implemented using one or more computer programs442, each of which is executed under the control of an operating system and causes the system400to perform the desired functions as described herein. Thus, using the present specification, the invention may be implemented as a machine, process, method, system, or article of manufacture by using standard programming and engineering techniques to produce software, firmware, hardware or any combination thereof.

It should be understood that various alternatives and modifications can be devised by those skilled in the art. However, these should not be viewed as limitations upon the practice of these teachings, as those skilled in the art, when guided by the foregoing teachings, may derive other suitable characteristics of a similar or different nature. The present invention is intended to embrace all such alternatives, modifications and variances that fall within the scope of the appended claims. For example, although the embodiments are described here with reference to storage and evaluation of geometric shapes, the invention can apply to other types of data objects for which a varying number of indexes can be generated. For such other types of data objects, if a number of index entries generated for such a data object exceeds a certain threshold, the data object, or an identifier of that data object is recorded in a storage pool. If the number of index entries does not exceed the threshold than the data object, or its identifier, is recorded in an index data structure.

Trademarks

IBM is a trademark or registered trademark of International Business Machines, Corporation in the United States and other countries.

DB2 is a trademark or registered trademark of International Business Machines, Corporation in the United States and other countries.