对于传统的业务处理(OLTP)系统,我们总是按照业务应用来建立它的模型,换言之, 业务
处理系统是面向应用来设计的，更准确地说是面向交易来设计。而数据仓库则一般按照主题
(Subject)来建模, 它是面向主题的。何谓应用? 何谓主题? 让我们来看一个简单的例子。在
银行中, 一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统, 它们都是
面向相关业务应用设计的交易处理系统, 系统主要任务是完成业务交易过程中的数据处理，
数据库在设计的时候主要是围绕性能和完整性方面，而每个交易涉及的数据往往只是记录的
层面，数据库设计主要考虑并行更新方面比较多，并不需要考虑为全表范围的查询做优化，
而系统本身所支持的交易类型简单而且固定。由于历史原因, 这些系统设计的时候都是独立
进行的，所以可能运行在不同的平台上,相互之间没有什么关系,各系统之间对相同的业务信
息还存在数据上的冗余。比如每个系统中都会有客户的数据, 这种数据的零碎和冗余，使决
策者很难从这些业务系统中直接地获取全面的信息。
为了克服这个弊病，建立数据仓库应用时, 要把业务系统中的数据从中抽取出来，转换
和清洗以消除数据的不一致性和冗余，加载到数据仓库中来。这样，数据仓库中的数据就是
从整个银行的角度来看的,其数据模型不再面向个别应用,而是面向整个银行的业务主题,比
如客户、产品、渠道等。因此, 各个生产系统中与客户、产品、渠道等相关的信息将分别转
换到数据仓库中相应的主题中, 从而给银行的决策者提供一个一致的完整的信息视图。