从第一次使用代理键技术开始,就去深入总结了很多代理键在各个方面的功能,结合Kimball资料中的介绍,就理解得更多了。
首先代理键的基本理解,应该是对维度ID的一个代用Key值,一定是数字字符型,最根本不可替代的作用,就是能反映维的变化,如果你不使用代理键,那么就得用维ID结合变化时间去描述,这样在DW的ETL过程中,效率会非常慢,而且和事实表关联后,事实表就会有N多时间标志字段,到后来就是乱七八糟的模型了。所以从这个角度来看,代理键在数据库仓库模型中,是必须用的技术。
其次代理键既然是代理,那么注定了它只能在DW存储中使用,在源、展现中,都和它无关,它说白了就是信息管道,变化前初始信息请走管道0通道、变化1请走管道1号通道。达到目的展现后,它的任务完成了,最终用户是感觉不到它的身影的。
再数据仓库模型高级技术中,它也是重要角色,无论你想保留并跟踪维历史定义的变化,还是保留和跟踪维层次的变化,几乎所有相关变化都可以用代理键去处理。代理键升华后,你可以无限创新下去,反正多数维的数据量有限,你可以无限地跟踪各种变化,效果真是爽啊,而且这种架构会使你在变化中坚固屹立不倒,成为主动解决业务问题的模型技术典范。
从代理键角度讲,维表中使用代理键,和事实表关联是使用代理键吗?
在原来谈架构的时候,谈到内部架构的紧偶合,就是说这样的关系,维表和事实表息息相关。当维表有变化时,代理键必定会更新,而每个周期的事实表对应的维,也需要根据具体情况去关联ETL,他们才能完整的形成一个信息整体。
适应变化的技术也得整体考虑,否则会顾前就顾不了尾。所以这才是必须先维表后事实表的根本原因,而在展现的时候,由于事实表和维表是在统一的代理键下工作的,可以放心关联使用。
同时还得考虑多周期和历史信息表,相信多数大型DW项目中都会将当前事实表按照周期分开为前端服务,同时也会因为效率原因,将近时期数据和中远时期数据分开物理存储。因此在ETL过程中,这些ETL流程都要理顺,历史表也不能遗漏。
而在最新的模型技术中,会有辅助模型和参考模型的高级技术,他们的初衷无非是更好地服务“变化”二字,特别是复杂的企业信息架构,不定期、不定维、不定势地变化起来,真的很恐怖,一般架构难以长期维持。这个时候代理键技术仍然是这些高级建模技术的基础,有了代理键,你可以将维表和参考模型/辅助模型关联起来,而又因为维表和事实表关联,所以整个架构就显得紧凑而坚固。
大家如果好几年前就做过DW项目的话,可能做过没有代理键的模型架构,刚开始还觉得很不错,没多久维护量就猛增,有体会的,现在不防假设下你不用代理键设计DW,后果会怎样?
![](http://writeblog.csdn.net/images/smilies/default/sweat.gif)
彻底无语,真不知道现在很多项目怎么设计的,当真“所需所欲”哦。看来“标准项目”做多了,真不知道很多项目还是这样的随意设计,没有整体体系而言。讨论起来,有点对牛弹琴的感觉
代理键,能否理解为唯一标识。对于变化维的三种处理方式:
1) 对于直接覆盖性的缓慢变化维度,不要求存储历史,代理键作用变小。业务键和代理键一体了。
2)对于增进列的方式:代理键和业务键也可以一体。
3)对于增加行的方式。如果没有唯一的代理键,则需要业务键和日期或状态组合一起作为唯一标识,那样在fact表中就也同样需要这个组合。给查询和使用带来比较多的不方便。因此,使用代理键比较好
从OLTP上讲,目前代理键也是比较好的一种方式,使用于OLTP系统的建模,有很多资料论述过。
所以无论哪种方式,个人认为,使用代理键应该是一种好的建模习惯。
一般我见过后缀是ID的都是数字型,CD的都是字符型,如果所说的业务系统代理建仅仅是增加一个数字型的ID的话,那还不算代理建,代理键的根本标志还是在描述事物的对应关系和实现方式上。
而且在OLTP系统使用代理键并没有分析型系统那么大的优势,使用不当反而是累赘,而且没有这个环境,因为OLTP事务处理过程中,有的有相关参数表或者描述表,就是维表的数据源,有的则没有相关维表,比如时间维。那么OLTP是如何使用代理键的,怎么体现出这个技术优势的,真的有点纳闷。
还能体现优势的场所有:雪花模型到星型模型的轻松转换。多数数据仓库多维模型采用的还是雪花模型或者偏雪花模型,因为每个行业都会出现各种父子维等层次关系,以雪花模型存储,不但节省空间,而且逻辑清晰严谨。而在前端展现的时候,Kimball提倡用星型模型,是非常有道理的,特别是当你有越来越多BI应用在用,成千上万用户逐渐使用BI后,雪花模型的存储(哪怕前端逻辑是星型的)将是性能瓶颈的最突出地方。
参考模型的使用,这里主要指不同部门的客户,或者公司对维层次关系未清晰之前,会不断修改层次关系。如果说普通ID键也能将他们的层级关系建立起来,那么当层次不断变化、自定义维不断改定义的时候,唯有代理键能解决这个问题。比如一个财务月定义一变,整个财务月相关的维表描述信息都作废了,算法重算,老表已经作废了,这就不是变化维的问题了。组织层次的变化,例如原来是公司-世界市场大区-国家-省/市分公司,现在某国家A从世界1大区变化为属于世界2大区了,组织层次变化为公司-世界大区-分公司了,只有我有代理键,无论你层次怎么变,我总有一个唯一标示表示这个维就行了,至于你父子维怎么建立关系,那是你父子之间的事情,你们的关系变化了,告诉我一声,我把你们的这个关系的唯一标示改一改即可。提醒一句,这里的参考模型是采用变化维处理方式的,只是它不再直接存储维数据,而是存储父子维的关系,或者单一维的定义,这是该技术最绝妙的地方。