概述:位图索引在数据仓库中的作用- Oracle 数据仓库- CNOUG

关于星型模式 
  
在数据仓库的构建中, 如下图所示的星型模式几乎是最常用到的。之所以称之为星型模式，是因为该模式中的E-R图形状如星(感觉这麽说有些怪怪的)。 
   
如图所示，中心是一个大的事实表，周围是一些维表。事实表包含数据仓库的主要信息，每个维表包含该事实表的特定属性。 
  
星型查询是一个事实表和一些维表之间的连接，维表使用主键连接到事实表的外键，维表之间不进行连接。 
  
关于位图索引 
  
在数据仓库中恰当的实现位图索引会得到数据仓库查询性能的极大收益。在位图索引出现之前，处理星型查询都是使用传统的复合B*Tree索引的方式。不幸的是，B*Tree索引处理这样的查询效率很差。 
  
考虑下面这个查询：

复制内容到剪贴板

代码:

SELECT sales.time_id, customers.cust_gender, sales.amount 
FROM sales, customers 
WHERE sales.cust_id = customers.cust_id;

如果使用B*Tree索引，那么将在Where子句中的把所有的维表先进行笛卡尔积连接，然后再使用复合B*Tree和事实表的主键进行连接。这样在性能上比较差。 
  
位图索引的出现改变了这种局面。位图索引的基本原理是在索引中使用位图而不是列值。通常在事实表和维表的键之间有很低的集的势（cardinality），使用位图索引，存储更为有效，与B*Tree索引比较起来，只需要更少的存储空间，这样每次读取可以读到更多的记录，而且与B*Tree索引相比,位图索引将比较,连接和聚集都变成了位算术运算,大大减少了运行时间，从而得到性能上的极大的提升。在上面的例子中，在事实表的外键列上建立位图索引，查询首先访问事实表，然后才是维表的连接。在事实表上返回的结果将减少，而不是对所有的可能的维表属性进行笛卡尔积运算，所以极为有效。 
  
使用位图索引 
  
如何合理的使用位图索引？以下的几个事项应该考虑。 
  
*如果要使用位图索引，初始化参数STAR_TRANSFORMATION_ENABLED应该设置为 
     TRUE. 
* 优化模式应该是CBO。对于数据仓库的环境中，总是应该考虑使用CBO（COST-BASED   
     OPTIMIZER）。 
*位图索引应该建立在每一个事实表的外键列上。(这只是一个一般的规则.) 
  
此外，对于数据表中的cardinality如何客观的确定也是一个问题，一万条数据中只包含3个值的集和算是低的了，那么一亿条记录中包含3万条记录算不算低的呢？对于这样的情况，建议几行一下数据的模拟测试，一般来说，在数据仓库环境中，位图索引的性能要好于B*Tree索引。还要注意位图索引不是为OLTP数据库设计的，不应该在OLTP数据库中大量的使用它，尤其是对那些有更新操作的表 

 

今天仔细看了一下，发现文中有几处错误，如果我说得不多，大家多指教 
文中：“如果使用B*Tree索引，那么将在Where子句中的把所有的维表先进行笛卡尔积连接，然后再使用复合B*Tree和事实表的主键进行连接。这样在性能上比较差。“ 
不会进行迪卡尔积的，无论是nested loop 或者hash或者sort merge join都不会进行迪卡尔积。 
  
针对文中的查询，这样建立的索引可以避免表的动态连接操作。而不仅仅是提高速度。 
CREATE BITMAP INDEX sales_cust_gender_bjix 
   ON sales(customers.cust_gender) 
   FROM sales, customers 
   WHERE sales.cust_id = customers.cust_id; 
  
*位图索引应该建立在每一个事实表的外键列上。(这只是一个一般的规则.)  
  
这个我很赞成。 

如上文的例子：
    SELECT sales.time_id, customers.cust_gender, sales.amount 
    FROM sales, customers 
    WHERE sales.cust_id = customers.cust_id;
   位图索引应该建立在每一个事实表的外键列上。(这只是一个一般的规则.) 

我感到有一点迷茫的是：
        是否要在oracle中fact （sales）表上的维列（如：cust_id ）建立一个fk（外键）指向维表（customers )来保证资料的一致性；
       这样做的好处是不用多说的(资料的一致性，oracle cbo自动处理），但我在实际dw的项目中却不敢这样做，因为：
      1、fk大大降低了加载的性能；
      2、因为维表也需要加载，并且加载不一定成功，但如果因为维表的加载不成功，则把fact表的一部分数据挡在了外面；这样是不对的；


   不知各位大侠是如何处理的？

我的观点：
1、数据仓库中的外键等约束主要是为数据库提供元数据让优化器使用的，保证数据一致性的工作应该在ETL中完成。
2、数据装载的时候最好是把所有约束禁用，把索引去掉，完了再启用约束和重建索引，这样会快好多（加快数据加载的问题我推荐过一篇文章http://www.cnoug.org/viewthread.php?tid=26155）。
3、我不你明白，你说维表加载不成功，fact表的一部分数据也要加载吗，那不会得出错误的统计结果吗，或者因为没有维度数据fact表中的数据通过关联会被过滤掉？我的做法是如果出现加载不成功时根据情况的不同给管理员发送警告或者重新加载数据（可能需要人工干预）。