Star Schema的设计思路与总结

Star Schema设计思路是本文我们主要要介绍的内容，在实际工作中，遇到的数据通常是很不规则的，类似于xml，有很多一对多的关系。例如一个商品，可以有很多种税，有几个累加的折扣，每个折扣又有一些信息，例如折扣的原因，折扣率之类。在《Star Schema The Complete Reference》中提到了两种经典的做法来解决一对多的关系。

1.简单方法

用税来举例子，如果税的类型数是固定的，例如一个商品最多6种税。就把这六种税在fact table中放置6个外键，指向税的dimension table。其实如果是column database，加属性应是很快的，所以即使税的种类不定，应该也可以处理。这种方法的问题很明显，就是导致fact table的属性过多。

2. bridge方法

做一个中间表，即bridge表，只有两个属性：groupid和taxid, 一个groupid对应fact table中的一个item, 一个 taxid对应一个group中一种税。taxid对应到tax dimension table的表中的一行。如果需要加税的种类，直接在 tax dimension table里加就可以了。这样就可以应用到tax 种类数量不清楚的情况。

但bridge方法在join fact table和 tax dimension table时可能会出多次计算的错误。

现实中的情况和书本中总是有区别的，早上和老板讨论，对于海量数据而言，bridge table可能非常大，使得join 性能很低，所以bridge对于海量数据而言可用性不大。

对于实际应用中raw data 转化为数据仓库中的Star Schema，可能遇到很多书本中没有的问题。其实Peter提出的flatten table方法可以最直观，最完整，最方便的展现数据的信息。但是对数据库的NULL值优化处理要求很高。一着是对NULL的存储压缩，二者是对数据的索引优化时对NULL的处理，三者是查询性能。

而当面对很多一对N的多层关系时，N是否是定值或者是有最大值尤其重要，在行式数据库中，只有N有限制或为定值才能使用上述简单方法，而对于bridge，性能和查询的正确性又是问题。这是一个取舍的难题。

关于Star Schema设计思路与总结就介绍到这里了，希望本次的介绍能够对您有所收获！

【编辑推荐】