在开始喷这个主题之前，让我们先看看数据仓库的官方定义：
数据仓库(Data Warehouse)是1个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反应历史变化(Time-Variant)的数据集合，用于支持管理决策。
以上是数据仓库的官方定义。
“操作型数据库”如银行里记账系统数据库，每次业务操作（比如你存了5元钱），都会立刻记录到这个数据库中，久而久之，满肚子积累的都是零碎的数据，这类干脏活累活还不得闲的数据库就叫“操作型数据库”，面向的是业务操作。
“数据仓库”用于决策支持，面向分析型数据处理，不同于操作型数据库；另外，数据仓库是对多个异构的数据源有效集成，集成后依照主题进行了重组，并包括历史数据，而且寄存在数据仓库中的数据1般不再修改。
操作型数据库、数据仓库与数据库之间的关系，就像 C:、D: 与硬盘之间的关系1样，数据库是硬盘，操作型数据库是 C:，数据仓库是 D:，操作型数据库与数据仓库都存储在数据库里，只不过表结构的设计模式和用处不同。
那末为何要在操作型数据库和 BI 之间加这么1层“数据仓库”呢？ 1是由于操作型数据库昼夜奔忙，以快速响应业务为主要目标，根本没精力服侍 BI 这边的数据需求，而且 BI 这边的数据需求通常是汇总型的，1个 select sum(xx) group by xx 就可以让操作型数据库耗费大量资源，业务处理跟不上趟，麻烦就大了，比如你存了 5000 元钱，发现10分钟后钱还没到账，作何感想？1定是该银行的领导在看饼图？
2是由于企业中1般存在有多个利用，对应着多个操作型数据库，比如人力资源库、财务库、销售单据库、库存货品库等等，BI 为了提供全景的数据视图，就必须将这些分散的数据综合起来，例如为了实现1个融会销售和库存信息的 OLAP 分析，BI 工具必须能够高效的获得两个数据库中的数据，这时候最高效的方法就是将数据先整合到数据仓库中，而 BI 利用统1从数据仓库里取数。
将分散的操作型数据库中的数据整合到数据仓库中是1门大学问，催生了数据整合软件的市场。这类整合其实不是简单的将表叠加在1起，而是必须提取出每一个操作型数据库的维度，将共同的维度设定为共用维度，然后将包括具体度量值的数据库表依照主题统1成若干张大表（术语“事实表”，Fact Tables），依照维度-度量模型建立数据仓库表结构，然落后行数据抽取转换。后续的抽取1般是在操作性数据库负载比较小的时候（如清晨），对新数据进行增量抽取，这样数据仓库中的数据就会构成积累。
大多数 BI 利用其实不要求获得实时的数据，比如决策者，只需要在每周1看到上周的周报就能够了，95% 的 BI 利用都不要 求实时性，允许数据有 1 小时至 1 个月不等的滞后，这是决策支持系统的利用特点，这个滞后区间就是数据抽取工具工作的时间。固然，BI 利用中通常还将包括极少的对实时数据的要求，这时候仅需针对这些特殊需求，将 BI Querying 软件直接连接在业务数据库上就能够了，但是必须限制负载，制止做复杂查询。
目前的数据库产品都对数据仓库提供有专门优化，例如在安装 MySQL 的高版本时，安装成序会询问你是想让数据库实例作为 Transaction-Oriented ，还是 Decision Support ，前者就是操作型数据库，后者就是数据仓库（决策支持么，再振臂高呼1遍），针对这两种情势，数据库将提供针对性的优化。
源自：http://www.powerbibbs.com/thread⑴31⑴⑴.html