star schema

数据仓库这么多年来发展的成果，我认为恐怕最重要的要算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来进行数据仓库的架构设计。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24104518/viewspace-715182/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24104518/viewspace-715182/