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

innovate511

同样的数据库的一个概念，在数据仓库的应用就有独特的需求和业务背景，以OLTP经验或者传统教学经验里的角度来看，这就是数据仓库领域的非专业人士，难道我说错了么？别说普通大学里学点理论皮毛，就算搞过数据仓库的人，又有多少人代理建贯穿数据仓库模型的关键，来满足客户既需要数据整合，又需要部门/分公司独立角度分析的需求，而且还要不要错过任何可爱的数据、信息结构等历史变化？

说白了，数据仓库的应用技术都是基于数据库自身的，常见的就那么多东西，如果都可以在学院学到点概念和技术后旧能搞好设计了，那数据仓库这个概念当初提出来都是多余的了。事实上证明，物理技术是通用的，但逻辑技术却是千变万化的，就看你占什么角度去看问题。要说这里谁人不知道代理建的定义和技术呢？我可不是刚毕业的大学生，学到点东西来这里show技术，而是用我的角度另一种解释而已，不是从技术这种死板不变的去看技术问题，其他我就不多说了。

所以感觉从纯数据库技术的角度看数据仓库的问题，显得不专业了，看楼上的帖子，也不是做这方向的，但技术面非常全面，我技术不太全面，就专注于BIDW的应用。

xiao888

楼主讲的应该是包含缓慢维度变化的处理方式．
如果是事实表需要保留历史变化情况．应该也是用代理链加开始日期实现的吧．

raullew

原帖由 xiao888 于 2008-7-31 15:20 发表
楼主讲的应该是包含缓慢维度变化的处理方式．
如果是事实表需要保留历史变化情况．应该也是用代理链加开始日期实现的吧．

如果是维度建模中的代理建，那么是记录代理建本身

Repou

很久以前，有个同事做了个集市模型，用了代理键，被我痛批了一顿，所有往那个模型里灌数的事，他包了

就目前的数据仓库应用来看，没有必要使用代理键

1、自增主键不算代理键。缓慢变化维表可以用自增逐渐或者干脆用组合主键得了。
2、保存历史变化用事件ID(IBM IIW)或者用单独的历史表(NCR FS-LDM)
3、Sybase IWS是必须用代理键的，但在目前的数据仓库应用模式下，我是不会用这种模型的

目前在研究的一个问题是，按照业务问题驱动的方式，将业务分析需求自动映射到数据层，类似与预定义的ad-hoc或者Cognos的Metric或者BO的语义层，但因为业务过于复杂，统计口径彼此交错，使得分解基础指标非常困难，即使能够设计出来一个类似于IBM IIW那样的对象模型，但受到数据质量的干扰，可能难以维护这样一个复杂结构的模型。

因此，正在考虑采用Sybase IWS的结构，将所有的业务问题相关数据，转换成相应的业务事件，装载到一堆字段冗余的表中，如果这样的话，为了数据更新的时候定位到记录行，就必须使用代理键，并维护一张业务键和代理键的映射表了，只是这样的更新效率会受到影响。

唉，希望有人能明白我在说什么

raullew

原帖由 Repou 于 2008-8-1 00:43 发表
很久以前，有个同事做了个集市模型，用了代理键，被我痛批了一顿，所有往那个模型里灌数的事，他包了

就目前的数据仓库应用来看，没有必要使用代理键

1、自增主键不算代理键。缓慢变化维表可以用自增逐渐或者干脆用组合主键得了。
2、保存历史变化用事件ID(IBM IIW)或者用单独的历史表(NCR FS-LDM)
3、Sybase IWS是必须用代理键的，但在目前的数据仓库应用模式下，我是不会用这种模型的

目前在研究的一个问题是，按照业务问题驱动的方式，将业务分析需求自动映射到数据层，类似与预定义的ad-hoc或者Cognos的Metric或者BO的语义层，但因为业务过于复杂，统计口径彼此交错，使得分解基础指标非常困难，即使能够设计出来一个类似于IBM IIW那样的对象模型，但受到数据质量的干扰，可能难以维护这样一个复杂结构的模型。

因此，正在考虑采用Sybase IWS的结构，将所有的业务问题相关数据，转换成相应的业务事件，装载到一堆字段冗余的表中，如果这样的话，为了数据更新的时候定位到记录行，就必须使用代理键，并维护一张业务键和代理键的映射表了，只是这样的更新效率会受到影响。

唉，希望有人能明白我在说什么

你是个明白人

zhangzongjun

关注～

yang860207

顶，下来看看...

我最近也发现一个软件,狠好用的..
他的存储安全性能也狠高..
备份中国（www.垃圾广告）的在线备份软件; 备份资料完整保障－资料传输透过安全的AES (128 bit) 加密机制。
        资料上载到服务器之前会自动地压缩和加密。它不仅减少储存位置的用量，还可增加资料的保密性。 针对企业核心资料，可能产生资料外洩的疑虑，资料在做线上备份传送前，为减低网路带宽的使用量及备份资料传输过程的安全性，我们所提供的备份软体会先将资料压缩并使用AES 128位元的国际标准加密法加密;而客户端备份资料上传至备份中国的远端数据中心之间也採用SSL(Secure Sockets Layer)加密机制,资料传输安全有保障。请注意，您在此所设立的密码将来在做备份资料恢复时将会被要求再次输入，因此在设定密码的同时，也请您记住您的密码，因为若您遗失或忘记了，即使本公司的技术服务人员或工程师也无法将之破解。也就是说您的数据存放在我们这里我们看不到内容。无法恢复用户密码也体现我们的专业级的数据安全机制
软件免费下载：
http://www.newhua.com/soft/73727.html

ｐｃ２．０版               
                        
http://www.newhua.com/soft/73726.html

服务器２.０版

info_sphere

Surrogate Key有它的好处，也有它的弊端。这东西没法说用SK就是真理，用Natual Key + Time就是错误，各有各的道理。就算你用SK，最后做FACT Table的匹配也还是需要使用Natural Key构成的AK做配合。而且SK这种东西一旦数据Fail，Recovery挺麻烦的。有时间我也总结一篇吧，我的建议还是，慎用SK，不到不得已的时候别用，增加ETL程序的复杂性。

Noteser

厉害~

zbjxm

学习了