Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

448
CHAPTER 11 ■ INDEXES
laid out. If you can use the index to “answer the question,” then accessing a large percentage
of the rows makes sense, since you are avoiding the extra scattered I/O to read the table. If you
use the index to access the table, then you will need to ensure that you are processing a small
percentage of the total table.
You should consider the design and implementation of indexes during the design of your
application, not as an afterthought (as I so often see). With careful planning and due consideration
of how you are going to access the data, the indexes you need will be apparent in most
all cases.
Bitmap Indexes
Bitmap indexes were added to Oracle in version 7.3 of the database. They are currently available
with the Oracle Enterprise and Personal Editions, but not the Standard Edition. Bitmap
indexes are designed for data warehousing/ad hoc query environments where the full set of
queries that may be asked of the data is not totally known at system implementation time.
They are specifically not designed for OLTP systems or systems where data is frequently
updated by many concurrent sessions.
Bitmap indexes are structures that store pointers to many rows with a single index key
entry, as compared to a B*Tree structure where there is parity between the index keys and the
rows in a table. In a bitmap index, there will be a very small number of index entries, each of
which points to many rows. In a conventional B*Tree, one index entry points to a single row.
Let’s say we are creating a bitmap index on the JOB column in the EMP table as follows:
Ops$tkyte@ORA10G> create BITMAP index job_idx on emp(job);
Index created.
Oracle will store something like what is shown in Table 11-6 in the index.
Table 11-6. Representation of How Oracle Would Store the JOB-IDX Bitmap Index
Value/Row 1 2 3 4 5 6 7 8 9 10 11 12 13 14
ANALYST 0 0 0 0 0 0 0 1 0 1 0 0 1 0
CLERK 1 0 0 0 0 0 0 0 0 0 1 1 0 1
MANAGER 0 0 0 1 0 1 1 0 0 0 0 0 0 0
PRESIDENT 0 0 0 0 0 0 0 0 1 0 0 0 0 0
SALESMAN 0 1 1 0 1 0 0 0 0 0 0 0 0 0
Table 11-6 shows that rows 8, 10, and 13 have the value ANALYST, whereas rows 4, 6, and 7
have the value MANAGER. It also shows us that no rows are null (bitmap indexes store null
entries; the lack of a null entry in the index implies there are no null rows). If we wanted to
count the rows that have the value MANAGER, the bitmap index would do this very rapidly. If we
wanted to find all the rows such that the JOB was CLERK or MANAGER, we could simply combine
their bitmaps from the index, as shown in Table 11-7.