本文探讨了数据仓库（DW）的重要性及其设计和实施的基本原则。主要指出了 DW 能解决数据可信性、历史数据缺乏、报告生产效率等问题，并强调 IT 团队需满足用户需求，借助反馈循环推动 DW 的不断迭代。适当的设计模式和技术选择，如星型设计和材料化视图，将进一步提高 DW 系统的性能。

1. Data warehouse 心得
Data warehouse 心得
By jyzhang8 2004-6-17 msn：jyzhang8@hotmail.com
一、为什么要推动 data warehouse
自然演化体系会带来很多的问题：
1、 数据可信性（两个部门提供的数据是不一样的，让管理者无所适从） ；
a、 时间的基准不一；b、算法差异； （认知不一致）c、无公共的起始数据源
要靠推动 data warehouse 使各部门之间对相同元素认知、定义和算法一致或者趋于一致；
2、 报表的生产率的问题；由于 oltp 的单项系统导致数据的分散性和相同元素定义不一致所致；
3、 oltp 的系统中无法保留很久的历史数据；单项系统之间保留的历史数据时间范围不一致；
无法满足 dss 分析的需要；
4、 oltp 的单项系统中对维表的关键栏位的更改很少有记录； （如：客户的业务员的变更问题）
5、 面向应用的设计无法满足面向主题的分析的需求；oltp 和 dw 对后台设计要求的重点不同，oltp 主要在意的
是 update 和 insert，而 dw 主要在意的是 select；
6、 因为决策的需求大多是“灵光一现”的，是“前无古人”“后无来者”的，是启发式的，而非固定式的；
，
7、 分散的系统导致业务行为不可控，dw 能够对各地的业务行为进行事后的监控； （如：产品代号，折让的问
题） ；
8、 dw 能够把 user 从复杂的统计工作中解放出来，从而提升企业的管理，让 user 有时间从事对企业更有益的
事情。还可以精简企业的人员；
9、 降低企业获取信息的费用；提高企业的决策速度，加快企业对市场的反应能力；
10、没有 dw，IT 部门总是处在鞭梢的位置，总是在被动的响应状态； （因为主管感兴趣的事情总是不时的变化
的） ；
11、可以透过 dw 来观察公司的新的政策或者新的行销活动给公司带来的变化；(事件映射)
12、dw 是 EIS 和数据挖掘的基础；
二、推动以前 IT 人员要有的观念
1、 首先满足用户的需求，再在用户使用过程中去引导用户朝正确的方向走；
2、 老板看的投资回报；
3、 永远比 user 考虑的明细；因为管理是一步步精细的；
4、 dw 是反复才能建成的，所以 dw 的版本要不停的迭代开发；
5、 olap 软件可以是 dw 的组成部分，但不是必选的，大多的 olap 的软件数据库是多维的，从 dw 中把资料刷
新至多维的数据库中会比较慢，但对多维的数据库查询起来速度必二维的速度快的多；所以是要根据 user
需求来进行合理的选择；
6、 前端的展现工具一定要有向上和向下钻取的功能；
三、和老板沟通的观念
1. dw 不可能满足所有的需求，Data warehouse 项目同样需要界定边界；
2. 同样的资料，角度不同（如财务，销售，市场，管理） ，结果就不一致，所以允许差异的存在，但差异要
在可解释的范围内； 通过定义不同的规则来玩这个游戏；
3. 问题的关键不在工具的好坏，而在于资料的可信度，原始数据和业务行为的规范；
4. 业务术语的定义和解释应由专门的单位来处理，从而保证集团自上至下的对术语定义的一致性；
（如销售业务行为中“铺货率”的定义）
5. 企业高层的支持非常重要；
6. 公司内的 oltp 系统数据是动态的，总是在变的，所以 dw 中的数据也会随之变化，dw 中昨天看到的数据
和今天看到看到的不一样，不要大惊小怪；
7. dw 是用来做趋势分析、预测和提供数据挖掘的，对数据的要求不是非常精确，所以千万不要拿 dw 中的
数据来计算 sales 的奖金；
8. 集团上下对为什么要推动 dw 及 dw 的作用的认知一致是非常重要的；
9. 最终用户专业化，要花很多的时间对 end user 进行培训，提高 user 的认知，最终的目标是 user 自己设计报
第 1 页 共 4 页

2. Data warehouse 心得
表；当然是在前端，而不是在“厨房”(后台)中；
10． 软件选择宜横向联合，强强联手，不是一家的软件可以搞定一切的；
四、dw 设计模式和方法
1．dw 应建立在 RDBMS(关系型数据库)中，而 dm 可以建立在一个 RDBMS 或者 MDDB(多维数据库)中；
2．dm 采用星型设计是原则，雪花模型是可选的；
3．dw 的设计模式和 oltp 的设计模式不一样的，oltp 的设计模式是以需求为驱动的，而 dw 的设计模式是以数
据为驱动（分析处理为驱动）的；
4．面向主题的设计，数据从操作型的环境流入 dw 中时，数据必须是集成的，而不仅仅是将数据扔到 dw 中；
5．一次开发一个主题的原则；
6．在 dm 中逆规范化的设计是必要的，以空间的冗余换取响应速度的加快；
7．遵循给“用户想要的东西，然后用户才能告诉你需求是什么”的发现模式来开发，成功的关键在于结构设
计人员和 dss 分析人员（user）之间的反馈循环, 迭代开发的模式；
8．开发流程：首先应建立企业数据模型（描述企业的信息需求，明确了企业主要的主题域，不一定是企业已
有的东西，不考虑任何的技术问题）→ 分解至中间层模型 → 定义记录系统（数据源的定义） → 设计
数据仓库 → 设计 oltp 与 dw 之间的接口；
9．5％的 dss 处理的需求在原子层，95％的在概要层； （查询分离的设计） ；
10．从 fact 表开始设计，然后开始设计 dimension 表；维表的设计要逆规范化，事实表的设计要 3nf；
11．弹性的设计（建立规则库，通过规则解析引擎解释规则至最小的粒度的设计）
12．资料可信度的设计；
13．规则库和规则转换设计；
14．各地的对相同的栏位定义不一致（如：有的地方用 0 和 1 表示男女，有的地方用 m 和 f 表示男女）没有关
系，但 dw 中的定义要一致，通过清洗程式转换成 dw 中的规则；
15．有限的使用的代理健；
16．有限的使用外健来保证参照完整性；可以使用 procedure 检查；
17． Slowly changing dimension（慢速变化维）表的处理：不要使用 oltp 系统中的 business key（业务健）作为
维表的 primary key（主健） ，而使用代理健，当慢速变化维的关键栏位发生变化时，不要 update 原来的记
录，而插入一条新的记录；这样能够 dw 不会出现错误而且可以跟踪维的历史；
18．字段级映射（field level mapping）一定要建立;
19．集团总部 dw 的资料可以回流至各分公司的数据库中，这样可以灵活的处理需求，一致的需求，总部处理，
特殊需求，各地处理；
20．dw 中无论是 fact table 还是 dimension table，强烈建议给每条记录加上时间戳；
五、粒度的选择
1、资料的粒度级别需要权衡，采用多重粒度的设计；在磁盘允许的情况下，建议尽可能的按最细粒度存储数
据；因为 dw 中存储的粒度越细，dw 回答问题的能力就越强； 要先估算事实表的行数（一年内的最少行数
和最多行数乘以字段长度）
2、对于不活跃的数据可以分离（至磁带或者备份的磁盘上） ；减轻 dw 刷新和管理的难度；
3、dw 的特性之一，表现为汇总数据还是细节数据是由观察者的不同角度决定的；
六、dw 的安全
1、 根据 user 的不同的权限看到的数据也不一样；
2、 数据库放在内网的是原则；
3、 通过 profile 限制并行的用户数；
4、 在 brio server 中限制帐号一个月不使用者封帐号（更改密码为当天的日期） ；
5、 装载阶段限制 ip 和 user 登陆（通过 trigger） ；
七、dw 性能增强方案和 oracle 的技术的运用
1、 可以使用的技术有：materialized view（物化视图） ，星型查询，专用大回退段, QUERY REWRITE(查询重
写),partition table，organization index table（索引组织表），PARALLEL（并行）
2、 充分的 index，建立必要的概要表（summary table） ，大表必须分区，query rewrite 和 mv 均可大大提高 dw
第 2 页 共 4 页

3. Data warehouse 心得
的性能；
3、 小技巧：加载前 drop 一些 index 以提高加载的性能，加载完毕后重建 index；还可以通过 view 来实现和简
化查询重写；
4、 oracle 优化模式 rbo 和 cbo 的选择：建议尽量使用 cbo；
5、 作为数据仓库的后台数据库，oracle 的安装方式和 init 参数的是有别于 oltp 系统的后台的数据库；
6、 加载阶段和访问阶段采用不同的参数设置来启动 db；
7、 访问阶段使 db 只读，减少 db 的本身的管理损耗；
8、 由于 dw 特性，不用在数据块上保留很多的自由空间用于以后的记录的更新和插入；
9、 修改 os 的参数，如：加大 os 的串行预读参数，异步 io，甚至修改 cpu 的时间片；
10、磁盘阵列的选择：条件允许的情况下建议 raid01；
八、规则库的定义和设计
1、业绩公式规则；
2、单位对资料可信度影响的权数的规则；
3、业绩归属的定义；
4、上级组织在不同的角度是不同的（如：财务和销售）
九、dw 运用的％
2％的 bpm、kpi 的管理；3％的数据挖掘；15％的数据分析；80％的 report；
十、让我头疼的几个问题及解决方法
1、由于是从分散的系统中抽取资料，所以各个公司相同的系统中基本资料中对基本数据定义可能会不一样；
如：A 这个产品代号在华东表示冰红茶，在华南可能表示冰绿茶；抽取至 dw 中的数据失去可比性；
我的对策：
a、如果是关键性的基本资料，在集团总部和各个公司建立一个公共系统（PUB） ，把各系统基本资料抽取
出来，并规划出哪些栏位是总部必须要控管的，然后放入 PUB 系统在集团总部控管，所有系统的基本资料的
总部控管栏位的来源只有从 PUB 系统中来，集团总部有修改和新增的权利，下属各公司只有查询的权利，下
属各公司如要新增和修改必须至总部申请；对于非总部控管的栏位各公司可以自己更改；PUB 系统的 table 资
料定期的同步至各公司的数据库中；
b、如果是非关键性的基本资料，建立对照表翻译成 dw 中的定义；只不过抽取程序设计会麻烦一点；
2、业务的术语定义集团内没有共识；
如：华东区认为销售铺货率应该这样计算，而东北区认为应该那样计算，而集团总部又是一种说法；
我的对策：请集团的高层建立或者指定相关的权威部门协调各方并给出标准的定义；不要迁就于各分公司的不
同的算法而客制出不同的报表， 那样只会让各分公司看到的报表数据失去可比性且让各方因为数据的问题吵的
不可开交；
3、由于 lotp 系统老化且分散在各分公司中，所以导致各分公司相同的系统其中的运行的逻辑会有差异，相同
的 table 相同的栏位存储的数据计算规则不一致；
我的对策：没有什么好的方法，要修改老化的系统使大家一致不太实际；因为会牵涉的系统的太多，并且老的
语言精通的人不多，如果修改不知道会发生不可预测的问题；
所以我只有请各公司了解自己的规则并填入我们规划的规则库， 我们的抽取程序依照规则库中的规则来抽
取，并且各分公司的规则更改时，也请他们更新规则库；
4、各分公司 IT 部门以前替各自分公司的开发的类似 dw 系统在使用并且数据可能会与总部的 dw 中数据不一
致，各分公司对集团总部推的 dw 系统有抗拒心理；
我的对策：首先请集团的高层向各分公司做说服，并且向集团的高层申请“上方宝剑” ，其次通过 dw 的资
料回流至各分公司数据库，使各分公司的自己开发的类似的系统的数据源来源于 dw 中，这样就把集团总部
和各分公司捆绑在一起；
5、dw 中资料刷新的问题，因为 oltp 系统的可变性，导致抽取程序在从 oltp 系统中抽取资料时不知道应该扫
描哪些资料，oltp 哪些资料自上次抽取后被更新了(变化数据捕获的问题)；
我的对策：这个应该是所有的做 dw 项目均会碰到的问题；
a、 如果抽取的 table 是比较小的 table，在不影响可以 oltp 系统性能的情况下，可以在 oltp 的系统的 table
第 3 页 共 4 页

4. Data warehouse 心得
上加入 trigger 来记录更新；抽取程序可以根据记录来只抽取更新的记录；如果加 trigger 有困难，每次把
table 的全部资料抽取回来也可；
b、 上面的方法只能解决小部分的问题，大部分是要通过时间戳的比较，或者充分理解 oltp 系统的规则，
如 oltp 系统不会更改多久以前资料，oltp 系统是否有结转的概念，如果要更改已结转的资料是不是在
什么地方有记录之类；根据具体情况具体解决；
我现在负责的这个项目的销售这一块在 oltp 系统中有结转的概念，如果要更改已结转的资料必须要进
行结转回复； 所以我们在设计抽取程序时有一个抽取记录的 table，用来记录该分公司的销售系统资料日期、
该日是否已结转、抽取的次数等等；并且要求 oltp 系统中日结的程序加入，如果做日结回复必须 update
抽取记录的 table 其中的抽取次数为 0；我们的抽取规则就是：抽取抽取次数为 0 的日期的资料，但未日结
的资料不管次数为多少均抽取；抽取完毕后 update 该 table 相关栏位；
十一、其他
1、 后台的程式执行出错时，log 记录至 table 中；并自动发出 mail 通知相关的人；
2、 执行成功，成功的记录至 succmsg 中；
<*the end*>
第 4 页 共 4 页