StarSchema的设计思路与总结
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设计思路与总结就介绍到这里了，希望本次的介绍能够对您有所收获！
本文标题：StarSchema的设计思路与总结
链接分享：http://www.hantingmc.com/qtweb/news9/364509.html
网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联