谈模型技术之代理键使用的深入理解

从第一次使用代理键技术开始，就去深入总结了很多代理键在各个方面的功能，结合Kimball资料中的介绍，就理解得更多了。

首先代理键的基本理解，应该是对维度ID的一个代用Key值，一定是数字字符型，最根本不可替代的作用，就是能反映维的变化，如果你不使用代理键，那么就得用维ID结合变化时间去描述，这样在DW的ETL过程中，效率会非常慢，而且和事实表关联后，事实表就会有N多时间标志字段，到后来就是乱七八糟的模型了。所以从这个角度来看，代理键在数据库仓库模型中，是必须用的技术。

其次代理键既然是代理，那么注定了它只能在DW存储中使用，在源、展现中，都和它无关，它说白了就是信息管道，变化前初始信息请走管道0通道、变化1请走管道1号通道。达到目的展现后，它的任务完成了，最终用户是感觉不到它的身影的。

再数据仓库模型高级技术中，它也是重要角色，无论你想保留并跟踪维历史定义的变化，还是保留和跟踪维层次的变化，几乎所有相关变化都可以用代理键去处理。代理键升华后，你可以无限创新下去，反正多数维的数据量有限，你可以无限地跟踪各种变化，效果真是爽啊，而且这种架构会使你在变化中坚固屹立不倒，成为主动解决业务问题的模型技术典范。

 

从代理键角度讲，维表中使用代理键，和事实表关联是使用代理键吗？

 

在原来谈架构的时候，谈到内部架构的紧偶合，就是说这样的关系，维表和事实表息息相关。当维表有变化时，代理键必定会更新，而每个周期的事实表对应的维，也需要根据具体情况去关联ETL，他们才能完整的形成一个信息整体。

适应变化的技术也得整体考虑，否则会顾前就顾不了尾。所以这才是必须先维表后事实表的根本原因，而在展现的时候，由于事实表和维表是在统一的代理键下工作的，可以放心关联使用。

同时还得考虑多周期和历史信息表，相信多数大型DW项目中都会将当前事实表按照周期分开为前端服务，同时也会因为效率原因，将近时期数据和中远时期数据分开物理存储。因此在ETL过程中，这些ETL流程都要理顺，历史表也不能遗漏。

而在最新的模型技术中，会有辅助模型和参考模型的高级技术，他们的初衷无非是更好地服务“变化”二字，特别是复杂的企业信息架构，不定期、不定维、不定势地变化起来，真的很恐怖，一般架构难以长期维持。这个时候代理键技术仍然是这些高级建模技术的基础，有了代理键，你可以将维表和参考模型/辅助模型关联起来，而又因为维表和事实表关联，所以整个架构就显得紧凑而坚固。

大家如果好几年前就做过DW项目的话，可能做过没有代理键的模型架构，刚开始还觉得很不错，没多久维护量就猛增，有体会的，现在不防假设下你不用代理键设计DW，后果会怎样？

 

 

对了，在有的项目中，DW模型以雪花型为主，这样存储方便，逻辑紧凑，而数据集市为了展现可能会演变成纯星型模型，这当中的转变，一定要小心，必须也是先考虑维表，再考虑事实表，代理键也是他们的重要桥梁，不要搞乱桥梁了。

在ITPUB看见有人回复“见过fact表设置代理键的吗？维表的常用”

彻底无语，真不知道现在很多项目怎么设计的，当真“所需所欲”哦。看来“标准项目”做多了，真不知道很多项目还是这样的随意设计，没有整体体系而言。讨论起来，有点对牛弹琴的感觉

不知理解是否正确：从技术上讲，
代理键，能否理解为唯一标识。对于变化维的三种处理方式：
1)  对于直接覆盖性的缓慢变化维度，不要求存储历史，代理键作用变小。业务键和代理键一体了。
2）对于增进列的方式：代理键和业务键也可以一体。
3）对于增加行的方式。如果没有唯一的代理键，则需要业务键和日期或状态组合一起作为唯一标识，那样在fact表中就也同样需要这个组合。给查询和使用带来比较多的不方便。因此，使用代理键比较好

从OLTP上讲，目前代理键也是比较好的一种方式，使用于OLTP系统的建模，有很多资料论述过。

所以无论哪种方式，个人认为，使用代理键应该是一种好的建模习惯。

业务系统使用代理建倒真没见过，至少我几年前参与业务系统时没用到这个，只有ID或者CD，然后就是状态、时间作为标示，毕竟业务系统没有必要保留所有历史变化记录。

一般我见过后缀是ID的都是数字型，CD的都是字符型，如果所说的业务系统代理建仅仅是增加一个数字型的ID的话，那还不算代理建，代理键的根本标志还是在描述事物的对应关系和实现方式上。

而且在OLTP系统使用代理键并没有分析型系统那么大的优势，使用不当反而是累赘，而且没有这个环境，因为OLTP事务处理过程中，有的有相关参数表或者描述表，就是维表的数据源，有的则没有相关维表，比如时间维。那么OLTP是如何使用代理键的，怎么体现出这个技术优势的，真的有点纳闷。

在多维建模技术的不断深入进化过程中，普通变化维并不是代理键体现其技术优势的唯一场所。

还能体现优势的场所有：雪花模型到星型模型的轻松转换。多数数据仓库多维模型采用的还是雪花模型或者偏雪花模型，因为每个行业都会出现各种父子维等层次关系，以雪花模型存储，不但节省空间，而且逻辑清晰严谨。而在前端展现的时候，Kimball提倡用星型模型，是非常有道理的，特别是当你有越来越多BI应用在用，成千上万用户逐渐使用BI后，雪花模型的存储（哪怕前端逻辑是星型的）将是性能瓶颈的最突出地方。

参考模型的使用，这里主要指不同部门的客户，或者公司对维层次关系未清晰之前，会不断修改层次关系。如果说普通ID键也能将他们的层级关系建立起来，那么当层次不断变化、自定义维不断改定义的时候，唯有代理键能解决这个问题。比如一个财务月定义一变，整个财务月相关的维表描述信息都作废了，算法重算，老表已经作废了，这就不是变化维的问题了。组织层次的变化，例如原来是公司-世界市场大区-国家-省/市分公司，现在某国家A从世界1大区变化为属于世界2大区了，组织层次变化为公司-世界大区-分公司了，只有我有代理键，无论你层次怎么变，我总有一个唯一标示表示这个维就行了，至于你父子维怎么建立关系，那是你父子之间的事情，你们的关系变化了，告诉我一声，我把你们的这个关系的唯一标示改一改即可。提醒一句，这里的参考模型是采用变化维处理方式的，只是它不再直接存储维数据，而是存储父子维的关系，或者单一维的定义，这是该技术最绝妙的地方。