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

CHAPTER 11 ■ INDEXES 453
column will need to get exclusive access to two of these index key entries: the index key entry
for the old value and the index key entry for the new value. The hundreds of rows these two
entries point to will be unavailable for modification by other sessions until that UPDATE commits.
Bitmap Join Indexes
Oracle9i introduced a new index type: the bitmap join index. Normally an index is created on
a single table, using only columns from that table. A bitmap join index breaks that rule and
allows you to index a given table using columns from some other table. In effect, this allows
you to denormalize data in an index structure instead of in the tables themselves.
Consider the simple EMP and DEPT tables. EMP has a foreign key to DEPT (the DEPTNO column).
The DEPT table has the DNAME attribute (the name of the department). The end users will frequently
ask questions such as “How many people work in sales?”, “Who works in sales?”, “Can
you show me the top N performing people in sales?” Note that they do not ask, “How many
people work in DEPTNO 30?” They don’t use those key values; rather, they use the humanreadable
department name. Therefore, they end up running queries such as the following:
select count(*)
from emp, dept
where emp.deptno = dept.deptno
and dept.dname = 'SALES'
/
select emp.*
from emp, dept
where emp.deptno = dept.deptno
and dept.dname = 'SALES'
/
Those queries almost necessarily have to access the DEPT table and the EMP table using
conventional indexes. We might use an index on DEPT.DNAME to find the SALES row(s) and
retrieve the DEPTNO value for SALES, and then using an INDEX on EMP.DEPTNO find the matching
rows, but by using a bitmap join index we can avoid all of that. The bitmap join index allows us
to index the DEPT.DNAME column, but have that index point not at the DEPT table, but at the EMP
table. This is a pretty radical concept—to be able to index attributes from other tables—and it
might change the way to implement your data model in a reporting system. You can, in effect,
have your cake and eat it, too. You can keep your normalized data structures intact, yet get the
benefits of denormalization at the same time.
Here’s the index we would create for this example:
ops$tkyte@ORA10G> create bitmap index emp_bm_idx
2 on emp( d.dname )
3 from emp e, dept d
4 where e.deptno = d.deptno
5 /
Index created.
Note how the beginning of the CREATE INDEX looks “normal” and creates the index
INDEX_NAME on the table. But from there on, it deviates from “normal.” We see a reference to a