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

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

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

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

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

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

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

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

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

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

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

代理键对系统开销太大
代理键个人认为只适合于普通维度，对于雪花维度和树状维度极端不适合，曾经做过一个关于树型维度的缓慢变化的实现，搞了几天也没把逻辑整清楚:(

[quote]原帖由 [i]bq_wang[/i] 于 2008-6-10 23:23 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10622784&ptid=1003280][img]http://www.itpub.net/images/common/back.gif[/img][/url]
代理键对系统开销太大
代理键个人认为只适合于普通维度，对于雪花维度和树状维度极端不适合，曾经做过一个关于树型维度的缓慢变化的实现，搞了几天也没把逻辑整清楚:( [/quote]
也可以呀，只要是维度模型，咋能没有雪花维度或树状维度这种情况呢，时间、地点、单位组织、产品品牌/品类这些基本的维都会有较复杂的需求。逻辑不要搞混，需要对ETL逻辑首先要很清晰。

要不用代理键，维经常变化、层次关系可能调整、维定义也可能变，如何描述其变化并保留历史记录并关联体现到事实表里去呢？

见过fact表设置代理键的吗？维表的常用

[quote]原帖由 [i]johnson.beijing[/i] 于 2008-6-11 22:41 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10634782&ptid=1003280][img]http://www.itpub.net/images/common/back.gif[/img][/url]
见过fact表设置代理键的吗？维表的常用 [/quote]
维表使用代理键, 事实表不用代理键, 事实表使用CD/ID这样的维字段去和维表关联?

这种设计我还真没见过. 看来很多项目使用代理键技术乱七八糟的, 我还以为早已很普及, 都理解很深了. :sweat2: :sweat2:

关于树状维度的缓慢变化维度要考虑的事情太多了，上级目录的变化下级目录的变化甚至从什么节点开始进行遍历都会导致不同的结果

我思考了整整3天，最终也没解决树状维度的问题，最后又改成普通维度的全处理方式了

我想雪花维度也面临同样的问题

[quote]原帖由 [i]innovate511[/i] 于 2008-6-11 11:05 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10626457&ptid=1003280][img]http://www.itpub.net/images/common/back.gif[/img][/url]

也可以呀，只要是维度模型，咋能没有雪花维度或树状维度这种情况呢，时间、地点、单位组织、产品品牌/品类这些基本的维都会有较复杂的需求。逻辑不要搞混，需要对ETL逻辑首先要很清晰。

要不用代理键，维经常变化、层次关系可能调整、维定义也可能变，如何描述其变化并保留历史记录并关联体现到事实表里去呢？ [/quote]

学习

[quote]原帖由 [i]bq_wang[/i] 于 2008-6-13 08:35 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10648045&ptid=1003280][img]http://www.itpub.net/images/common/back.gif[/img][/url]
关于树状维度的缓慢变化维度要考虑的事情太多了，上级目录的变化下级目录的变化甚至从什么节点开始进行遍历都会导致不同的结果

我思考了整整3天，最终也没解决树状维度的问题，最后又改成普通维度的全处理方式了

我想雪花维度也面临同样的问题

[/quote]
代理键处理的基本思路就是从最底层级的维表进行ETL产生代理键，逐渐ETL到高层级维产生代理键，然后才是对应的事实表。逻辑理清楚后，对ETL流程也设置好，应该不会有大的问题。

楼主可以用地区树型结构来做个缓慢变化维的例子，这样更有说服力，

up

关注一下

学习

楼主对代理键理解的很深刻，佩服！

学习！

re

代理鍵只是一個主鍵的形式而已，哪里稱的上技術。說大了。

楼上是非专业人士，理解不了也正常。就象我跟一个做.net/java开发的哥们说到数据仓库建模，他很惊讶，这个还需要研究么？是个搞软件的不都会建模，还需要去研究？

这里说的是建模技术，代理键只是其中重要的一个组成部分，它和其他思想组成建模技术。说到逻辑技术，往往做物理技术的觉得这不算什么技术，其实象ERP这些不也是一个逻辑技术么？ERP最核心的技术我想并不是它到底使用C++技术架构还是JAVA或其他技术架构，而是ERP体系的逻辑，这才是最核心的，ERP厂商的技术架构可能会选择换，但它的核心逻辑永远是循序渐进，不会大改大换的。

还有，非专业人士不要老认为代理键==主键。维度模型中，维表的代理键一般就是主键，而事实表中，代理键的组合才能形成主键，他们同时也是维表的外键。而汇总事实表中还可能有一些非主键的代理键，他们的目的也许是为了展现方便。

re

論壇是用來討論的，不要動輒戴別人以非專業人士的帽子。
無論中專職專或層級的計算機專業和其他信息技術有關系的，開過數據庫原理課程的人都知道所謂的代理鍵。這只是數據庫理論體系中一小點內容而已。無論應用在數據倉庫的見過過程，或者一般數據庫的建模過程。

re

我認為你對代理鍵的理解還是有一些深度的。在我所經歷的應用中，一些設計的代理鍵被展現給用戶，導致ID之類也有被修改的需求，代理鍵被異化。