Btree vs Bitmap. Optimizing load process in Data Warehouse.

Question

Hi,
I'm working on fine tuning a Data Warehousing system. I understand that Bitmap indexes are very good for OLAP systems, especially if the cardinality is low and if the WHERE clause has multiple fields on which bitmap indexes exist for each field.
However, what I'm finetuning is not query, but load process. I want to minimize the total load time. If I create a bitmap index on a field with cardinality of one million, and if the table has one million rows (each row has a distinct field value), then my understanding is
The total size of the bitmap index = number of rows * (cardinality / 8) bytes
(because there are 8 bits in a byte).
Hence the size of my bitmap index will be
Million * Million / 8 bytes = 116 GB.
Also, does anyone know what would be the size of my B-tree index? I'm thinking
The total size of the B-tree index = number of rows * (field length+20) bytes
(assuming that the field length of rowid is 20 charas).
Hence the size of my b-tree index will be
Million * (10+20) bytes = 0.03 GB (assuming that my field length is 10 charas).
That means B-tree index is much lesser than the size of the Bitmap index.
Is my math correct? If so, then the disk activity will be much higher for a bitmap index than a B-tree index. Hence, creation of the bitmap index should take much longer than the B-tree index if the cardinality is high.
Please let me know your opinions.
Thanks
Sankar

Answer 1

Hi Jaffar,
Thanks to you and Jonathan. This is the kind of answer I have been looking for.
If I understand your email correctly, for the scenario from my original email, bitmap index will be 32MB where as Btree will be 23MB. Is that right?
Suppose there is an order table with 10 orders. There are four possible values for OrderType. Based on your reply, now I understand that the bitmap index is organized as shown below.
Data Table:
RowId     OrderNo     OrderType
1     23456     A
2     23457     A
3     23458     B
4     23459     C
5     23460     C
6     23461     C
7     23462     B
8     23463     B
9     23464     D
10     23465     A
Index table:
OrderType     FROM     TO
A     1     2     
B     3     3     
C     4     6     
B     7     8     
D     9     9     
A     10     10     
That means, you might have more entries in the index table than the cardinality. Is that right? That means, the size of the index table cannot be EXACTLY determined based on cardinality. In our example, the cardinality is 4 while there are 6 entries in the index table.
In an extreme example, if no two adjacent records have the same OrderType, then there will be 10 records in the index table as well, as shown in the example below.
Data Table (second example):
RowId     OrderNo     OrderType
1     23456     A
2     23457     B
3     23458     C
4     23459     D
5     23460     A
6     23461     B
7     23462     C
8     23463     D
9     23464     A
10     23465     B
Index table (second example):
OrderType     FROM     TO
A     1     1     
B     2     2     
C     3     3     
D     4     4     
A     5     5     
B     6     6     
C     7     7
D     8     8
A     9     9
B     10     10
That means, the size of the index table will be somewhere between the cardinality (minimally) and the table size (maximally).
Please let me know if I make sense.
Regards
Sankar