A mapping mechanism to support bitmap index and other auxiliary structures on tables stored as primary B + -trees

Abstract

Any auxiliary structure, such as a bitmap or a B + -tree index, that refers to rows of a table stored as a primary B + -tree (e.g., tables with clustered index in Microsoft SQL Server, or index-organized tables in Oracle) by their physical addresses would require updates due to inherent volatility of those addresses. To address this problem, we propose a mapping mechanism that 1) introduces a single mapping table, with each row holding one key value from the primary B + -tree, as an intermediate structure between the primary B + -tree and the associated auxiliary structures, and 2) augments the primary B + -tree structure to include in each row the physical address of the corresponding mapping table row. The mapping table row addresses can then be used in the auxiliary structures to indirectly refer to the primary B + -tree rows. The two key benefits are: 1) the mapping table shields the auxiliary structures from the volatility of the primary B + -tree row addresses, and 2) the method allows reuse of existing conventional table mechanisms for supporting auxiliary structures on primary B + - trees.This paper presents the mapping mechanism, its possible application in supporting various auxiliary structures on primary B + -trees, and a case study describing its use for supporting bitmap indexes on index-organized tables in Oracle9 i . The case study demonstrates that the proposed mapping mechanism allows us to reuse existing bitmap index technologies with minimal changes. It also includes a comparison between bitmap and non-bitmap (B + - tree) index performance on index-organized tables for both single-table queries and star queries. The analytical and experimental studies show that the method is storage efficient, and (despite the mapping table overhead) provides performance benefits that are similar to those provided by bitmap indexes implemented on conventional tables.