ビットマップインデックスのカーディナリティルール
Oracleドキュメント には、次のアドバイスが含まれています。
ビットマップインデックスは、1つまたは複数のファクトテーブルの各外部キー列に構築する必要があります
そのリファレンスでは、日付列にビットマップインデックスさえあります。ビットマップインデックスを使用するためのカーディナリティルールはどうなりましたか？日付列はそのルールに最も反抗しますが、customer_keyなどの他の列もビットマップインデックスの候補と見なすには少し大きすぎます。何千ものアイテムがない場合は、item_keyに1つ置くことである程度理解できます。
ビットマップインデックスでない場合、特に、時間ディメンションへの外部キーを持つ日付列の場合-典型的なもの-月、年、日など。明らかに、それは頻繁に照会されます。
数日前にStack Overflowでこの質問をしましたが、返信がないため削除します。
ビットマップインデックスは、個別の値が比較的少ない列でのみ有用であるというルールはありませんでした。これは、ビットマップインデックスが一意またはほとんど一意の列には適切ではなく、ビットマップインデックスを配置する列の多くに、異なる値が比較的少ないという事実から派生した神話でした。
Richard Foote（おそらく地球上の他のどの人よりもOracleのインデックスについてもっと知っているでしょう）が 多くの異なる値を持つビットマップインデックス に関する素晴らしい記事を掲載しています。詳細。フォローアップ記事 多くの異なる値を持つ列のビットマップとb-treeインデックスの比較 も読む価値があります。