Oracle Star Schema简析

star schema主要的思想在于将我们关心的数据和用于描述数据的属性分隔开来。实际的数据存放于Fact table中，从不同角度来描述数据的属性放到不同的dimension table中。比如，一个sales数据仓库可以这样设计，每一笔销售记录，应该会包含销售的产品，销售的客户，销售的供货商，销售的时间，销售的数量和 获得的收入等。当我们要分析整个公司的所有销售记录时，毫无疑问，我们最关心的是一共销售了多少？一共获得了多少收入？然后更进一步，在某个时间段内销售 了多少？来自哪家供货商的产品的销售额最大？面向哪种客户的销售额最大？哪种产品的销售额最大？等等。

从 上面我们关心的这些问题我们可以看到，对于销售的数量和金额这类具体的数字型的数据，通常是我们分析的对象，而对于像时间，产品，客户，供货商，我们希望 从这些不同的角度来得到数字型数据的一个统计结果。所以，我们将数字型的数据存放在fact table中，将时间，产品，客户，供货商存放在不同的dimension table中，自然，在fact table和dimension table之间存在一个主-外键的关联，各个dimension table之间则没有关系。由此我们可以得到如下的一个star schema:

 

star schema之所以叫star schema，就是由于上面这个图形的形状来的，fact table处于中间的位置，dimension table围成一圈，每个dimension table和fact table关联。

fact table中除了区分每条记录的主键（fact table的主键很有可能是所有dimension table的外键组合起来的一个组合主键），连接每个dimension table的外键外，就只有我们关心的数字型数据，所以fact table中的每条记录，有个专门的术语称之为度量(measurement)，因为我们利用数据仓库做统计分析的时候，这些数据就是统计分析的一个个基 本单位，也就是度量值。

除了star schema，最出名的要算从star schema中衍生出来的snowflake schema了。雪花模型就是在星模型的基础上，对dimension table做规范化后等到的模型，由于每个dimension table由于规范化可能得到许多的小表，雪花模型比起星模型就更加复杂，查询的时候也需要关联更多的表。

oracle在文档中说，除非你有非常特别的原因，推荐此采用star schema来进行数据仓库的架构设计。

 

星型转换是一个非常强大的优化技术，它是通过对原来的SQL语句的隐式的改写来实现的，它能够很大程度减少I/O. 终端用户并不需要知道有关星型转换的任何细节。数据库优化器会在合适的时候进行星型转换。要获得星型转换的最大性能，需要遵循以下3个基本的条件： www.2cto.com  

 

1，事实表上的维度列上要有外键

2，事实表的每个外键上都有BITMAP索引。

3，star_transformation_enabled=true。   系统默认是false. 它有三个取值：（TRUE, FALSE, TEMP_DISABLE）.其中TEMP_DISABLE表示不允许用临时表来存放第一次扫描的结果集。 

 

星型查询中，维度表会被扫描两次，如果维度表很大，性能会很差，所以需要一个临时表来存放第一次扫描的维度表集合。

如果能够满足这三个条件,则查询会使用star transformation,而这是提高基于事实表的查询效率的主要的技术。

数据库进行星型查询时，会使用两个基本的阶段：

第一个阶段从事实表(或者说结果集)里获取所有必要的记录行。由于这是通过bitmap索引来检索数据，因此比较高效。 

 

第二个阶段将该结果集与维度表进行关联。这叫做semi-join(也就是exists和in写法)。

注意：只有oracle企业版才有bitmap索引。标准版不支持bitmap索引和星型转换。