数据仓库技术指南 (2010 年度畅销榜NO.1983 )

本书是直接对业务领导和数据仓库技术的新宇介绍数据仓库的非常好的一本书，书中清晰而深入地说明了应用数据仓库的各种好处、风险、技术和过程。在此，读者可以了解到如何将大量信息转换为知识，来减少业务中的不确定因素。本书提出了大量数据仓库应用的个案，以帮助读者在自己的企业中衡量各种关键因素，了解如何使用数据仓库来减少供应链管理的成本，使交叉销售更为有效，具有更好的客户关系、更好的品牌发展，提高产品质量等。书中还介绍了数据仓库项目的生命周期，从计划和设计，一直到部署和优化，可能出现的问题以及如何预防这些问题。另外，本书还涉及了如下内容：创建客户和产品的统一表达；数据质量-数据仓库成功的关键因素；数据仓库设计的基础；数据仓库操作的最佳惯例；基于Web的数据仓库、元数据和其他新方法。\r\n
\r\n

数据仓库引言：在不确定性与知识之间 \r\n\r\n 　1. 1　学习与不确定性共存 \r\n\r\n 　1. 2　模式转换的困扰 \r\n\r\n 　1. 3　通过知识减小不确定性 \r\n\r\n 　1. 4　数据仓库将知识作为特殊 \r\n\r\n 　1. 5　知识的种类 \r\n\r\n 　1. 5. 1　有用的知识 \r\n\r\n 　1. 5. 2　实际的知识 \r\n\r\n 　1. 6　基本的业务规则 \r\n\r\n 　1. 7　三个规则 \r\n\r\n 　1. 8　数据仓库表达业务 \r\n\r\n 　1. 9　复杂的现象, 简单的原理 \r\n\r\n 　1. 10　业务与数据仓库的组合 \r\n\r\n 　1. 11　业务的数据仓库映射 \r\n\r\n 　1. 12　不能压缩业务知识 \r\n\r\n 　1. 13　事实的单一版本 \r\n\r\n 　1. 14　知识清单：将“决策”放回“决策支持” \r\n\r\n 第一部分：　基本承诺 \r\n\r\n 第1章　数据仓库的基本特征 \r\n\r\n 　1. 1　不是软件产品, 而是体系结构 \r\n\r\n 　1. 1. 1　基本问题 \r\n\r\n 　1. 1. 2　一个问题, 一千零一个答案 \r\n\r\n 　1. 1. 3　第一个特征：事务和决策支持系统系统 \r\n\r\n 　1. 2　数据仓库的数据源 \r\n\r\n 　1. 3　维 \r\n\r\n 　1. 4　数据仓库事实 \r\n\r\n 　1. 5　数据仓库的业务模型：组合 \r\n\r\n 　1. 6　数据立方体 \r\n\r\n 　1. 7　聚合 \r\n\r\n 　1. 8　数据仓库的职业角色 \r\n\r\n 　1. 9　数据仓库过程模型 \r\n\r\n 　1. 10　小结 \r\n\r\n 第2章　数据简史 \r\n\r\n 　2. 1　写在本章前面 \r\n\r\n 　2. 2　现代导言 \r\n\r\n 　2. 3　决策支持的根本思想 \r\n\r\n 　2. 4　从大型机到PC \r\n\r\n 　2. 5　关系数据库的承诺 \r\n\r\n 　2.　6　数据的出路 \r\n\r\n 　2.　7　从客户机/服务器到瘦客户机计算 \r\n\r\n 　2. 8　为什么这次不同 \r\n\r\n 　2. 9　变化越多, 共同之处越多 \r\n\r\n 　2. 10　技术动力学模型 \r\n\r\n 　2. 11　小结 \r\n\r\n 第3章　为数据仓库辩护 \r\n\r\n 　3. 1　争夺有限资源的竞争 \r\n\r\n 　3. 2　集成的业务和技术解决方案 \r\n\r\n 　3. 3　经济价值而非商业利益 \r\n\r\n 　3. 4　出售数据仓库 \r\n\r\n 　3. 5　报告数据仓库：运行错误少 \r\n\r\n 　3. 6　供应链数据仓库 \r\n\r\n 　3. 7　交叉出售数据仓库 \r\n\r\n 　3. 8　整体质量管理数据仓库 \r\n\r\n 　3.　9　收益数据仓库 \r\n\r\n 　3. 10　媒体对数据仓库个案的简述 \r\n\r\n 　3. 11　小结 \r\n\r\n 第4章　数据仓库项目管理 \r\n\r\n 　4. 1　模拟合理的设计过程 \r\n\r\n 　4.　2　管理项目需求 \r\n\r\n 　4. 3　管理体系结构的开发 \r\n\r\n 　4.　4　管理项目进度 \r\n\r\n 　4. 5　管理项目质量 \r\n\r\n 　4.　6　管理项目风险 \r\n\r\n 　4. 7　管理项目文档 \r\n\r\n 　4. 8　管理项目开发队伍 \r\n\r\n 　4. 9　控制项目管理 \r\n\r\n 　4. 10　小结 \r\n\r\n 第二部分　设计和建造 \r\n\r\n 第5章　商业设计：客户和产品的统一表示 \r\n\r\n 　5. 1　重要途径：组合 \r\n\r\n 　5. 2　客户的统一表示 \r\n\r\n 　5. 3　数据净化 \r\n\r\n 　5. 4　交叉功能团队 \r\n\r\n 　5. 5　层次结构 \r\n\r\n 　5. 6　客户统计 \r\n\r\n 　5. 7　产品的统一表示 \r\n\r\n 　5. 8　数据市场：在原型和向后类型之间 \r\n\r\n 　5.　9　小结 \r\n\r\n 第6章　数据仓库总体质量 \r\n\r\n 　6. 1　信息产品 \r\n\r\n 　6. 2　数据完整性方面的数据质量 \r\n\r\n 　6. 2.　1　内在质量 \r\n\r\n 　6. 2.　2　二义性 \r\n\r\n 　6. 2.　3　及时性与时间的一致性 \r\n\r\n 　6. 3　安全性 \r\n\r\n 　6. 3.　1　二级质量 \r\n\r\n 　6. 3. 2　可信度 \r\n\r\n 　6. 4　质量数据, 质量报告 \r\n\r\n 　6. 5　信息质量, 系统质量 \r\n\r\n 　6. 6　性能 \r\n\r\n 　6. 7　可用性 \r\n\r\n 　6. 8　可伸缩性 \r\n\r\n 　6. 9　功能性 \r\n\r\n 　6. 10　可维护性 \r\n\r\n 　6. 11　重新诠释过去 \r\n\r\n 　6. 12　小结 \r\n\r\n 第7章　数据仓库技术设计 \r\n\r\n 　7. 1　使用个案 \r\n\r\n 　7. 2　抽象的数据类型和具体的数据维 \r\n\r\n 　7. 3　数据规范化：关联和限制 \r\n\r\n 　7. 4　维和事实 \r\n\r\n 　7.　5　主键和外部键 \r\n\r\n 　7.　6　为性能设计：技术的中间阶段 \r\n\r\n 　7. 7　小结 \r\n\r\n 第8章　数据仓库构造技术：SQL \r\n\r\n 　8.　1　关系数据库：主流设计 \r\n\r\n 　8. 2　12条原则 \r\n\r\n 　8. 3　考虑集合：声明性和过程性方法 \r\n\r\n 　8.　4　数据定义语言 \r\n\r\n 　8. 5　B树索引 \r\n\r\n 　8. 6　哈希索引 \r\n\r\n 　8. 7　位图索引 \r\n\r\n 　8. 8　索引的经验规则 \r\n\r\n 　8. 9　数据操纵语言 \r\n\r\n 　8. 10　数据控制语言 \r\n\r\n 　8. 11　存储过程 \r\n\r\n 　8. 12　用户自定义函数 \r\n\r\n 　8. 13　小结 \r\n\r\n 第9章　数据仓库构造技术：事务管理 \r\n\r\n 　9. 1　事务管理系统的个案：ACID测试 \r\n\r\n 　9. 2　工作的逻辑单元 \r\n\r\n 　9. 2　两层和三层体系结构 \r\n\r\n 　9. 3　分布式体系结构 \r\n\r\n 　9. 4　中间件：远程过程调用模型 \r\n\r\n 　9. 5　中间件：面向消息的中间件 \r\n\r\n 　9. 6　长事务 \r\n\r\n 　9. 7　小结 \r\n\r\n 第三部分　操作和转换 \r\n\r\n 第10章　数据仓库操作技术：数据管理 \r\n\r\n 　10. 1　数据库管理 \r\n\r\n 　10. 2　备份数据 \r\n\r\n 　10. 3　恢复数据库：崩溃恢复 \r\n\r\n 　10. 4　恢复数据库：版本恢复 \r\n\r\n 　10. 5　恢复数据库：前滚恢复 \r\n\r\n 　10. 6　管理大量数据：磁盘空间资产 \r\n\r\n 　10. 7　管理大量数据：系统控制的存储 \r\n\r\n 　10. 8　管理大量数据：自动化磁带机器人 \r\n\r\n 　10. 9　RAID配置 \r\n\r\n 　10. 10　小结 \r\n\r\n 第11章　数据仓库性能 \r\n\r\n 　11. 1　性能参数 \r\n\r\n 　11. 2　为性能消除规范化 \r\n\r\n 　11. 3　为性能聚合 \r\n\r\n 　11. 4　为性能缓冲 \r\n\r\n 　11. 5　为性能分区 \r\n\r\n 　11. 6　并行处理：共享内存 \r\n\r\n 　11. 7　并行处理：共享磁盘 \r\n\r\n 　11. 8　并行处理：不共享 \r\n\r\n 　11. 9　数据布置：协同定位的联接 \r\n\r\n 　11. 10　小结 \r\n\r\n 第12章　数据仓库操作：信息供应链 \r\n\r\n 　12. 1　进程而非应用 \r\n\r\n 　12. 2　大型数据链 \r\n\r\n 　12. 3　分区：分区解决 \r\n\r\n 　12. 4　确定暂时的粒度 \r\n\r\n 　12. 5　聚合到数据仓库 \r\n\r\n 　12. 6　数据仓库中的聚合 \r\n\r\n 　12. 7　关于数据仓库数据模型的争论 \r\n\r\n 　12.　8　表示层 \r\n\r\n 　12. 9　集成决策支持过程 \r\n\r\n 　12. 10　小结 \r\n\r\n 第13章　元数据与比喻 \r\n\r\n 　13. 1　比喻改变我们的观念 \r\n\r\n 　13. 2　新技术, 新比喻 \r\n\r\n 　13.　3　元数据是比喻 \r\n\r\n 　13. 4　语义 \r\n\r\n 　13. 5　数据规范化和消除规范化的形式3 \r\n\r\n 　13. 6　元数据结构 \r\n\r\n 　13. 7　元数据储存库 \r\n\r\n 　13.　8　模型与元模型 \r\n\r\n 　13. 9　元数据交换规范（MDIS） \r\n\r\n 　13. 10　元数据：计算巨大的挑战 \r\n\r\n 　13. 11　小结 \r\n\r\n 第14章　聚合 \r\n\r\n 　14.　1　在线聚合导致实时性的降低 \r\n\r\n 　14.　2　管理人员的首要原则 \r\n\r\n 　14.　3　管理面临的挑战 \r\n\r\n 　14. 4　聚合导航 \r\n\r\n 　14. 5　信息密度 \r\n\r\n 　14.　6　经典聚合 \r\n\r\n 　14. 7　小结 \r\n\r\n 　第四部分　应用与推测 \r\n\r\n 第15章　OLAP技术 \r\n\r\n 　15. 1　OLAP结构 \r\n\r\n 　15. 2　立方体. 超立方体和多立方体 \r\n\r\n 　15. 3　OLAP的特性 \r\n\r\n 　15. 4　OLAP的力量 \r\n\r\n 　15. 5　局限性 \r\n\r\n 　15. 6　小结 \r\n\r\n 第16章　数据仓库和Web \r\n\r\n 　16. 1　业务个案 \r\n\r\n 　16. 2　Web用作传送系统 \r\n\r\n 　16. 3　关键的Internet技术 \r\n\r\n 　16. 4　Web收获：Web作为最终的数据仓库 \r\n\r\n 　16. 5　业务情报门户 \r\n\r\n 　16. 6　小结 \r\n\r\n 第17章　数据采集 \r\n\r\n 　17.　1　数据采集及数据仓库 \r\n\r\n 　17.　2　数据采集驱动技术 \r\n\r\n 　17. 3　数据采集方法 \r\n\r\n 　17. 4　数据采集：管理前景 \r\n\r\n 　17. 5　小结 \r\n\r\n 第18章　崩溃：什么出了问题 \r\n\r\n 　18. 1　短列表 \r\n\r\n 　18. 2　倾斜的数据立方体 \r\n\r\n 　18. 3　数据仓库现场销售 \r\n\r\n 　18. 4　未来会像过去一样吗 \r\n\r\n 　18.　5　模型成为过时的 \r\n\r\n 　18. 6　遗漏的变量 \r\n\r\n 　18. 7　强制清理 \r\n\r\n 　18. 8　组合爆炸 \r\n\r\n 　18. 9　技术和业务的不协调 \r\n\r\n 　18. 10　成为一项商品 \r\n\r\n 　18. 11　小结 \r\n\r\n 第19章　展望未来 \r\n\r\n 　19. 1　企业服务器技巧需求很大 \r\n\r\n 　19. 2　交互虚拟. 面向对象. 交叉功能团队 \r\n\r\n 　19. 3　支配 \r\n\r\n 　19. 4　操作型数据仓库 \r\n\r\n 　19. 5　更新请求 \r\n\r\n 　19. 6　Web机遇：代理技术 \r\n\r\n 　19. 7　数据仓库的未来 \r\n\r\n 　19. 8　小结 \r\n\r\n 词汇表 \r\n\r\n 参考书目 \r\n
\r\n

作为作者, 我当然希望读者从头至尾读这本书. 但如果你需要选择先读什么内容, 我希望这里提出的一些建议能对你有所帮助. “词汇表”的内容丰富而具体, 这是非常有价值的资源. 虽然本书尽量在第一次用到技术用语时便进行定义, 但如果读者在阅读时跳过某些章节, 可能会遗漏一些术语的定义, 在这种情况下, 读者可以参考词汇表. 首先, 以下几章是必读的：第1章. 第2章. 第5章. 第6章. 第12章. 第13章和第18章. 另外, 以下章节可以对执行官员. 业务领导和需要各种信息的客户等提供帮助：引言. 第3章以及第19章. 项目经理. 数据设计师以及设计人员还应当再阅读第4章. 第5章. 第7章. 第14章以及第15章. 开发人员可详细参看第8章和第9章（顺便说一句, 本书不介绍SQL或编码, 读者可查阅其他文献来获得有关的帮助信息）. 数据库管理员和信息管理人员会对第10章和第11章感兴趣. 业务分析人员. 技术专家及各个领域从事信息工作的人员可以参看第15章. 第16章和第17章.

序言的真正目的是让读者了解本书的由来. 作者写这本书的目的是什么呢？与书本身比起来, 序言更像是一道科学的分水岭, 它介于发现和证明之间. 思想或发明如何成型往往与如何证明无关. 许多读者不仅喜欢接受思想和观点的正确性, 也希望了解思想和观点的产生背景, 而且他们往往从中受益. 新事物的出现可能会由于偶然闪现的灵感, 或是集现有理论之大成, 它对原型增添新的功能以及更多的逻辑结构, 而该结构是有待于客观地进行验证并证明其是正确的. 但如果您, 亲爱的读者, 对背景介绍不感兴趣, 而是想深入了解数据仓库的具体内容, 那就请马上看第1章, 以后再回来看序言. 作者的工作毕竟是为读者服务, 您不看序言的话, 作者不会感到伤了感情, 您也不会因为没有连续阅读就不能连贯地理解本书.

现在, 对那些仍愿意读序言的读者, 我想说的是, 这本书产生于三个信念. 首先, 就模式转换而言, 数据仓库不是另一种模式转换. 其次, 借助于数据仓库系统的维与基本业务驱动力及业务规则之间的组合, 利用数据仓库可以产生知识, 而不是数据. 第三, 数据仓库系统既是一个信息产品, 又是一种创造知识的方法. 所以, 它更像望远镜上的一片透镜, 通过结合光学原理知识, 我们便能看到并从而开始了解远方的事物, 而这些是我们以前没有想过的. 有时候, 这要求有很好的洞察力.

事物之间具有错综复杂的关系, 需要透过表面才能看到事物的本质. 例如, 在文艺复兴时期, 科学家伽俐略将他的尖形无文望远镜对准月球并看到山（如同地球上的上一样）, 而不是天堂般的美景时, 由于他具有深刻的洞察力, 从而理解了包括地球. 太阳和月球在内的统一天体系统. 但是, 当时有学问的宗教学者透过这一奇怪的装置观察时, 由于受眼光所限, 他们看到的不是山, 对他们来说, 这些设计是如此陌生, 而认为是魔鬼的作品. 不要以为这是小事, 因为这件事, 可怜的伽俐略被宗教裁判所逮捕了. 尽管数据仓库设计者和数据采集者不会有这么悲惨的命运, 但他们在涉及数据质量的问题上仍应当非常小心.

这里的关键是, 本书（不同于它的证明）的出发点可在3个动态术语中找到：“模式（ paradigm）”. “组合（ alignment）”和“知识（ knowledge）”. 这些变化无常的词语经常被人们所滥用. 在这里, 我们将仔细推敲这些术语, 严格定义并精心使用它们.

“模式转换”非常有趣, 1962年, 在一本介绍科学知识是如何发展的书中第一次提出这个术语, 这本书是很有争议的, 它就是托马斯·库恩所著的 The Structure of Scientific Revolution. 在无数科学知识发展的例子中, 库恩选择了从地心说到日心说的转移. 从地心说到日心说的转移是一个基本的转移. 这是模式转换的绝好例子. 实际上, 日心说是过去一千年中最伟大的发现之一 （1643年, 哥白尼的 On the Revolution of the Heavenly Bodies（天体演变））. 许多旧体系中的事实包含在新体系中. 以前许多有待澄清的新的事实, 也被包含了进来. 而且, 框架的建立（构筑）还结合了其他许多事实. 这一例子强调了, 发现是如何产

生与发现是如何被证实的关系不大（如果不是无关的话）. 哥白尼的模式转换（他的新理论）实际上是一个复杂的逻辑推测, 几乎像它要取代的体系一样混乱而且违反直觉. 例如, 哥白尼继续推论说, 行星的轨迹是一个圆而不是椭圆. 但如果不利用椭圆运动, 新理论所做的许多推论就无法成立. 物理和数学再经过两个世纪的逐步发展, 才令人满意地证实了我们现在按照严格的科学标准认为是正确的东西. 的确, 证明中的一个重要部分就是构造数据仓库, 来存放Tycho Branche和他的学生Johannes Kepler对行星的连贯一致的观察数据（出版于 1625年的 Tabulae Rudolfinae （Rudof’s Tables）, 在 Prince Rudolf之后）. 但随着之后一系列持续. 逐步的改进（包括伽俐略. 开普勒和牛顿著作中的现代科学史）, 这个新的模式终于开始看起来像是一个突破了.

从而我们得到了编写本书的本质信念：数据仓库不是模式转换. 在企业数据和图形用户界面（GUI）之间－－在太阳和地球之间－－诱人而肤浅的类比自有它的扭力. 但这太有限了. 强调的重点并没有从大型机转移到表示层, 或从以数据为中心转移到以GUI为中心. 在完整的计算系统体系结构中, 开始就有这两者, 而且, 它们仍是一个完整的计算系统体系结构中不可缺少的部分. 知道这点, 也许会使一些认为“模式转换”开始代表着突破或解决方案的读者失望. 另一方面, 那些被商业出版物中的模式转换搞得疲惫不堪的读者, 在得知仍

然有可能有很大的进步时, 会感到放心. 无论哪种情况, 我们都不是指像客户机邮务器. 关系数据库. 网络计算机或基于Web的Internet解决方案. 确切地说, 数据仓库是一个系统体系结构, 它将设计和产品构造成各种形式. 但在每种形式中, 我们都要处理决策中需理解并应用的将数据（客户. 产品. 市场. 信息）作为公司资产进行管理的技术规则. 数据就是业务这一概念是有着深厚基础的. 无论是当作者于1980年第一次遇到它, 还是在60年代后期当统计方法（和其他方法）第一次运用到决策中, 这个概念始终是正确的.

促使作者编写本书的第二个思想是“组合”. 通过数据仓库产生知识而不仅是产生更多数据的主要方法, 是定义仓库的数据维与基本的业务规则及驱动力之间的组合. 这一思想指引我们用语言来描述世界. 在每一天, 语言是所有符号系统（这其中包括计算系统）中最普通的一种, 用来表达并约束世界中的各种情形.

自然, 语言的使用不限于在实际世界里进行简单的表达（这里为避免累赘, “语言”是代表所有类型计算系统应用的符号）. 而且, 在与业务规则的组合中, 语言既可以作为一种工具, 又具有实际作用. 它是在各方之间产生关系的一种手段, 在业务过程中, 它嵌入到系统中, 起到协调和交流的作用. 从而, “组合”成了计算系统（特别是数据仓库）表现客户. 产品和市场之间业务交互的方法的“代理人”. 数据仓库表现而且（就像设计者喜欢说的那样）“揭示”目标市场. 产品和消费者之间的关系. 这些关系反过来作为一种结构, 帮助构造者和数据仓库操作人员找到并定义系统的真实世界参照物. 例如, 需求规划者的预测几乎完全是系统的人工产物. 根据它运作的世界就像是一个奇迹. 然而, 它并不完全是相对的——业务情形的准确特征确实表达出来了, 而且系统客观地参照着环境中的事情. 如果这像循环, 那么它就是确实像. 系统设计者（和构造者）是这个循环中的重要部分, 这个循环是良性的而不是恶性的. 这就暗示了为什么这个过程的本质是反复循环的——数据仓库系统与其使用环境之间的组合不仅仅是被人们发现的, 它是被构造出来的（当然, 给定的业务实践活动无论在任何情况下总是适用的. 在由自动化系统实现或支持的时候, 这些商业实践活动是经过抽象. 捕获, 有时经过了转换, 从而超出了人们的认识）. 最终得到的系统不仅表示了业务情形, 还使得人们能访问它. 设计者的艺术就是知道何时停止迭代, 因为环境的最小特征已经在系统体系结构中捕获, 剩余特征与业务规则相去甚远. 从而, 我们有了三种事物（系统. 世界和系统设计者（和建造者））的双向组合. 结果就是知识.

这将我们带到第三个意思多变的词, “知识”. 如今, 知识意味着取得专利的知识产权到咨询公司内部网上使用PowerPoint表示的内容等. 直观地说, 说某物为知识则意味着该物具有“尊严”, 知识表示“优秀”, 表示“高度的声望”. 在第6章题为“信息产品”的一节中, 揭示了这种直观性. 本书采用的方法暗示着数据仓库系统就是信息产品. 而且, 数据仓库的确是一个知识来源. 它是一个“启用者（enabler）”. 它是产品可能成为知识的条件. 但是, 它本身不是知识. 相反, 知识产生于问题的提出与答案提供者的交互中. 知识不在那

些用SQL或其他用户交互方法来形成查询的职员头脑中. 知识在问题产生者和答案提供者的相互作用中. 知识在问题与答案之间的关系中. 总之, 知识是在信息与行为的协调中产生, 这些信息与行为反映在公司承诺回答的问题中, 其中至少有一些问题还未产生. 因而, 数据仓库系统是业务过程中不可或缺的部分, 这一业务过程的结果和成果就是知识.

从技术或是业务的角度来看, 信息和知识间的关系有所不同. 从技术的角度来看, 知识与信息是连续的. 当信息的质量提高时, 它越来越接近于知识. 知识就是水平线上的一点, 信息始终朝着这个点前进. 信息就是一直处于确定的改善过程中的数据. 如果这一过程一直延续下去, 得到的结果就是知识. 从业务的观点来看, 知识与信息有着本质的不同. 无论信息的质量有多高, 都存在一个深渊, 将信息与知识分离开. 如果不加入一些特别的东西来加强信息, 即使是最好的信息也绝不会产生知识. 为了产生知识, 需要在信息中加入某种东西. 这种东西便是承诺. 当信息成为业务决策的基础时, 其中就暗含着并流动着承诺. 数据仓库系统通过提供机械而实际的知识, 提出并解答支持决策问题. 本书特别把重点放在了解客户. 了解产品品牌在市场中的行为方面. 在信息供应链中, 无用的信息得到清除, 然后产生知识, 这并不是奇迹. 但有些时候确实像一个奇迹, 因为那些特殊公司的承诺不在新闻标题或是表面上体现出来. 结果会产生应用于最终目标的有用的知识. 知识产生有助于商业利益的结果. 这进一步需要实际知识, 在这里知识成为了承诺的基础, 数据仓库协调了业务过程, 处理了基本的业务规则, 回答了基本的支持决策问题. 第二种通过承诺定义知识的方式要求我们在业务环境中理解知识. 数据仓库对知识的这一承诺在决策支持中起到了重要的作用.