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

谈模型技术之代理键使用的深入理解 从第一次使用代理键技术开始，就去深入总结了很多代理键在各个方面的功能，结合Kimball资料中的介绍，就理解得更多了。首先代理键的基本理解，应该是对维度ID的一个代用Key值，一定是数字字符型，最根本不可替代的作用，就是能反映维的变化，如果你不使用代理键，那么就得用维ID结合变化时间去描述，这样在DW的ETL过程中，效率会非常慢，而且和事实表关联后，事实表就会有N多时间标志字段，到后来就是乱七八糟的模型了。所以从这个角度来看，代理键在数据库仓库模型中，是必须用的技术。其次代理键既然是代理，那么注定了它只能在DW存储中使用，在源、展现中，都和它无关，它说白了就是信息管道，变化前初始信息请走管道0通道、变化1请走管道1号通道。达到目的展现后，它的任务完成了，最终用户是感觉不到它的身影的。再数据仓库模型高级技术中，它也是重要角色，无论你想保留并跟踪维历史定义的变化，还是保留和跟踪维层次的变化，几乎所有相关变化都可以用代理键去处理。代理键升华后，你可以无限创新下去，反正多数维的数据量有限，你可以无限地跟踪各种变化，效果真是爽啊，而且这种架构会使你在变化中坚固屹立不倒，成为主动解决业务问题的模型技术典范。 在原来谈架构的时候，谈到内部架构的紧偶合，就是说这样的关系，维表和事实表息息相关。当维表有变化时，代理键必定会更新，而每个周期的事实表对应的维，也需要根据具体情况去关联ETL，他们才能完整的形成一个信息整体。适应变化的技术也得整体考虑，否则会顾前就顾不了尾。所以这才是必须先维表后事实表的根本原因，而在展现的时候，由于事实表和维表是在统一的代理键下工作的，可以放心关联使用。同时还得考虑多周期和历史信息表，相信多数大型DW项目中都会将当前事实表按照周期分开为前端服务，同时也会因为效率原因，将近时期数据和中远时期数据分开物理存储。因此在ETL过程中，这些ETL流程都要理顺，历史表也不能遗漏。而在最新的模型技术中，会有辅助模型和参考模型的高级技术，他们的初衷无非是更好地服务“变化”二字，特别是复杂的企业信息架构，不定期、不定维、不定势地变化起来，真的很恐怖，一般架构难以长期维持。这个时候代理键技术仍然是这些高级建模技术的基础，有了代理键，你可以将维表和参考模型/辅助模型关联起来，而又因为维表和事实表关联，所以整个架构就显得紧凑而坚固。在有的项目中，DW模型以雪花型为主，这样存储方便，逻辑紧凑，而数据集市为了展现可能会演变成纯星型模型，这当中的转变，一定要小心，必须也是先考虑维表，再考虑事实表，代理键也是他们的重要桥梁，不要搞乱桥梁了。大家如果好几年前就做过DW项目的话，可能做过没有代理键的模型架构，刚开始还觉得很不错，没多久维护量就猛增，有体会的，现在不防假设下你不用代理键设计DW，后果会怎样？ 还有，非专业人士不要老认为代理键==主键。维度模型中，维表的代理键一般就是主键，而事实表中，代理键的组合才能形成主键，他们同时也是维表的外键。而汇总事实表中还可能有一些非主键的代理键，他们的目的也许是为了展现方便。 同样的数据库的一个概念，在数据仓库的应用就有独特的需求和业务背景，以OLTP经验或者传统教学经验里的角度来看，这就是数据仓库领域的非专业人士，难道我说错了么？别说普通大学里学点理论皮毛，就算搞过数据仓库的人，又有多少人代理建贯穿数据仓库模型的关键，来满足客户既需要数据整合，又需要部门/分公司独立角度分析的需求，而且还要不要错过任何可爱的数据、信息结构等历史变化？ 说白了，数据仓库的应用技术都是基于数据库自身的，常见的就那么多东西，如果都可以在学院学到点概念和技术后旧能搞好设计了，那数据仓库这个概念当初提出来都是多余的了。事实上证明，物理技术是通用的，但逻辑技术却是千变万化的，就看你占什么角度去看问题。要说这里谁人不知道代理建的定义和技术呢？我可不是刚毕业的大学生，学到点东西来这里show技术，而是用我的角度另一种解释而已，不是从技术这种死板不变的去看技术问题，其他我就不多说了。 所以感觉从纯数据库技术的角度看数据仓库的问题，显得不专业了，看楼上的帖子，也不是做这方向的，但技术面非常全面，我技术不太全面，就专注于BIDW的应用。 在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。 在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（Smart Keys）。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信