什么是数据仓库
目前，数据仓库一词尚没有一个统一的定义，著名的数据仓库专家W.H.Inmon在其著作《Building
the Data Warehouse》一书中给予如下描述：数据仓库（Data
Warehouse）是一个面向主题的（Subject
Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time
Variant）的数据集合，用于支持管理决策。对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
数据库是一个装数据（信息的原材料）的地方。
数据仓库是一种系统，这种系统也是用数据库装东西。
数据仓库系统（用数据库装东西）与其他基础业务系统（例如财务系统、销售系统、人力资源系统等，也是用数据库装东西）的区别是：
基础业务系统的特点是各管各的，例如财务系统生产了白菜，那么用一个数据库来装，人力资源系统生产了猪肉，再用一个数据库来装。我要做一道菜，需要分别到各个数据库去取，比较麻烦（现实的情况是大部分时候让种菜的农民伯伯送过来，但送过来的东西不一定是我想要的，而且不同的时候我想要不同的东西，经常会被农民伯伯骂，弄得双方都不开心）。另外一方面，各个数据库中放的是一些比较原始的东西，我要拿过来做菜，还需要经过很麻烦的清洗过程，一不小心里面可能就藏着一条大青虫。
那么，数据仓库系统就是建立一个大的超市，将各地农民伯伯出产的东西收集过来，清洗干净，分门别类地放好。这样，你要哪种菜的时候，直接从超市里面拿就可以了。
早期一直不理解数据仓库是什么困惑得很。
宏观一点讲，数据仓库就是堆放公司所有数据的地方，之所以把数据都堆在一起，是为了从中间找到有价值的东西。
数据仓库更多的是一个概念，不要把数据仓库想成那些号称是数据仓库的软件产品们。
数据仓库的物理上就是数据库。相对业务系统数据库叫OLTP数据库（用于业务处理），这种数据库叫OLAP数据库（用于业务分析）。
数据仓库的概念是针对以下基本需求产生的：
公司的业务系统很多，业务系统的历史数据不方便查询。不同的业务系统往往管理部门不同，地域不同。能不能将所有这些数据集中起来，再淘淘有没有有意义的业务规律。
数据仓库数据库往往很大，因为公司所有的数据集中得越多，越能淘到有价值的发现。例如随便就100G以上。
数据仓库的组成十分繁杂，既有业务系统的历史数据，又有人事、财务数据，还要自己建一些基础性的数据，例如，公共假期数据、地理信息、国家信息等等。
数据仓库概念包含从业务生产系统采集数据的程序，这个程序还不能影响业务系统的运行。（属于所谓“ETL”过程）
数据仓库包括业务系统长期的历史数据，例如5年，用来分析。（所谓“ODS”数据）
数据仓库包括针对某相业务值（例如销售量）重新打上标签的业务流水数据。（所谓“事实表”、“维度表”）。
数据仓库概念兴许还包含报表生成工具（所谓“BI”工具）。这些工具能够达到几年前所谓DSS（决策分析）的效果。
数据仓库的客户历史资量的分析，也许又与CRM系统粘点边。
总之，一点，一个公司想针对已有的历史业务数据，充分的利用它们，那么就上数据仓库项目。至于哪些吓唬人的大写字母的组合，只是达到这个目标的科学技术罢了。
牢记住数据仓库的基本需求，不要被供应商吓着。
数据仓库可以说是决策支持系统，能帮助老板了解企业的整体全貌，看到数据仓库提供的经过整理统计归纳的数据后老板凭自己的管理经验可以发现企业的问题或困难或成功因素在哪一方面，然后可以不断的追溯数据，直到确定到最具体的细节上，这样能够不断提升老板或管理层的管理水平，不断改善企业的管理。我们知道的最好的一个例子就是美国某大型超市啤酒和尿布的故事。
沃尔玛公司在美国的一位店面经理曾发现，每周，啤酒和尿布的销量都会有一次同比攀升，一时却搞不清是什么原因。后来，沃尔玛运用商业智能（Business
Intelligence，简称ＢＩ）技术发现，购买这两种产品的顾客几乎都是25岁到35岁、家中有婴儿的男性，每次购买的时间均在周末。沃尔玛在对相关数据分析后得知，这些人习惯晚上边看球赛、边喝啤酒，边照顾孩子，为了图省事而使用一次性的尿布。得到这个结果后，沃尔玛决定把这两种商品摆放在一起，结果，这两种商品的销量都有了显著增加。
数据库是数据仓库的基础。数据仓库实际上也是由数据库的很多表组成的。需要把存放大量操作性业务数据的数据库经过筛选、抽取、归纳、统计、转换到一个新的数据库中。然后再进行数据展现。老板关注的是数据展现的结果。
数据仓库(DATA WAREHOUSE/DATA
MART)的另一重要概念是数据从不同的数据库(DATABASES)
里调出经过ETL工具(如POWERCENTRE，DECISIONSTREAM, SQL SERVER
2000 DTS, SQL SERVER 2005
SSIS)过程进行清理，确证，整合并设计成多维(dimensional
framework)。以保证数据的正确、准确、完整,
这是非常重要的一点。
我们现在的项目稳定运行了6年多，一直自己开发，最近慢慢开始使用datastage。很多大型项目之所以用工具，是因为工具的本身的特点是开发快，效率相对还可以，让你更好地有精力用在业务、数据库的优化以及数据测试上，和数据质量本身并没有关系。
而数据质量关系最密切的还是从设计（架构、模型等）、业务关系的理解、项目管理（含和客户的交流，以及遵从开发流程和测试流程）等一系列项目工程的过程。这也是为什么很多项目使用了ETL工具，但是数据质量还是提高不大的主要原因。
数据仓库的作用重在数据的集中管理。集中管理的最终目的是为了分析，预测。
所谓的ETL。不过是数据仓库的构建的一个必须过程。数据的抽取转换与装载，都是为了集中管理所做的基础工作，这些数据与动作的描述，都会有有响应的元数据进行描述。
在数据仓库建模的过程，我们一般都是采用多维模型，如星形，雪花型等等，这样做最大的特点就是效率高，数据的冗余度低。所以，把OLAP与数据仓库混为一谈我认为是片面的解释。
我们也可以选择业务逻辑模型建立数据仓库，这是很早以前的做法了，特点就是效率不高，数据的冗余度高，但他能实现非常难以表达的业务逻辑设计。
基于数据仓库最重要的是分析与预测，我认为，历史现在将来是数据仓库的精华。。
基于数据仓库的DM，OLAP都是为了分析与预测。为了让使用企业单位更好的把握现在，预测将来，因此他最实效的说法我认为是给决策者与管理者进行决策管理提供分析与预测的依据。
另外，数据仓库还会起到历史数据分类归档的目的（就像图书馆一样），届时可以通过检索条件方便的查询历史信息；而同类信息在OLTP中早已被更新了。
至于它的分析功能，就象气象考古研究工作，在不同深度的冰川中保存着当时的气象信息，否则拿什么预测气候变化趋势呢！
不过，要有相当的管理及技术储备以及管理层的强力支持才可以。先有需求，并具备了必要条件才可上马，否则您的数据仓库将不是超市而是个垃圾堆，“garbage
in，then garbage out”！
所以，我认为是企业信息化建设及科学管理水平的提高催生了数据仓库的必然产生，不要赶时髦，炒概念，关键还是冷静分析自己企业的现实状况是否到了必须部署数据仓库的阶段了！
至于如何说服管理者，则需要您的努力了，不要站在您技术人员的立场阐述问题，CEO对技术问题不感兴趣，站在他们的角度考虑问题，回答诸如“我们投入如此大的资金、人力，同时面对升级系统的巨大风险，目的何在？”记住，CEO和CFO（甚至包括CIO）是更希望用数字说话的，您分析一下公司的管理决策流程，就可以向他们提出很有价值的决策支持报表，而部门经理（或类似人员）每季度也不必头大的制作相关分析报表了，节省的精力可以做更多有价值的事情，这就是企业人力资源利用率的巨大提升，可以节省多少银子，恐怕CEO不会用你提示了吧！
谈谈一年来关于数据仓库好处的困惑、探索和感悟
quote:
最初由 maltig 发布
早期一直不理解数据仓库是什么困惑得很。
宏观一点讲，数据仓库就是堆放公司所有数据的地方，之所以把数据都堆在一起，是为了从中间找到有价值的东西。
数据仓库更多的是一个概念，不要把数据仓库想成那些号称是数据仓库的软件产品们。
数据仓库的物理上就是数据库。相对业务系统数据库叫OLTP数据库（用于业务处理），这种数据库叫OLAP数据库（用于业务分析）。
数据仓库的概念是针对以下基本需求产生的：
公司的业务系统很多，业务系统的历史数据不方便查询。不同的业务系统往往管理部门不同，地域不同。能不能将所有这些数据集中起来，再淘淘有没有有意义的业务规律。
数据仓库数据库往往很大，因为公司所有的数据集中得越多，越能淘到有价值的发现。例如随便就100G以上。
数据仓库的组成十分繁杂，既有业务系统的历史数据，又有人事、财务数据，还要自己建一些基础性的数据，例如，公共假期数据、地理信息、国家信息等等。
数据仓库概念包含从业务生产系统采集数据的程序，这个程序还不能影响业务系统的运行。（属于所谓“ETL”过程）
数据仓库包括业务系统长期的历史数据，例如5年，用来分析。（所谓“ODS”数据）
数据仓库包括针对某相业务值（例如销售量）重新打上标签的业务流水数据。（所谓“事实表”、“维度表”）。
数据仓库概念兴许还包含报表生成工具（所谓“BI”工具）。这些工具能够达到几年前所谓DSS（决策分析）的效果。
数据仓库的客户历史资量的分析，也许又与CRM系统粘点边。
总之，一点，一个公司想针对已有的历史业务数据，充分的利用它们，那么就上数据仓库项目。至于哪些吓唬人的大写字母的组合，只是达到这个目标的科学技术罢了。
牢记住数据仓库的基本需求，不要被供应商吓着。
数据仓库是干什么的，到现在，我终于看到了成果。
一年半以前，我来到现在这家公司(一家证券公司)。跟所有2004年的证券公司一样，“生”与“死”是当时考虑的唯一问题。为获得证监会的“创新业务资格”(获得这个牌照就如同获得了免死金牌，不但能够生存而且能获得资助从而做大做强)，公司急需上马一套集中监控系统，我就是为了这个项目被招募到公司。
背景：
在证券行业中，所有公司的业务系统（所谓证券交易系统）有一个基本特征：每一个分支机构（所谓营业部）的交易系统都是独立的（地理上、管理上），这样总部没办法在技术上对数十套这样的系统的业务数据进行及时的分析与核对。（当然这两年几乎所有公司都实现了交易系统的集中。）于是，几乎所有的证券公司都上马了一套集中监控系统，它通过广域网，把公司下属的这几十家营业部的数据实时或当天晚上采集到总部的数据库中，白天实时的对资金存取、证券买卖等业务行为进行监控，晚上再运算一些核对功能，看资金和证券是否帐实相符，再通过WEB界面将结果展示给公司审计部门。我们公司在05年上半年上了这个系统。
由于手头上的这个系统整合了公司所有的业务系统的数据(30多套分布在全国各地的交易系统、30多套财务系统、集中清算系统、登记公司数据、等等)，所以象每个技术型IT员工一样，我有一个自然而然的想法：能不能搞清楚公司所有业务信息的逻辑关系，自己建一个数据库，搞一个数字虚拟证券公司，在我的这个数据库中包含公司每一个业务细节的信息，业务部门不管要什么，我都能很快提供出来（而不是依赖供应商）。
OK。在我这个最朴素的想法的支配下，我开始学习数据库（搞了若干年IT基础设施的我，居然在2004年底又开始学习数据库！可见中国的IT岗位有多么不清晰。），向供应商请教底层数据结构，向他们请教业务逻辑关系。3个月后，我居然已经能够对供应商提供的“监控功能”提供完全的功能验证，指出了无数的功能BUG，同时也具备了证券交易、结算业务逻辑的完全的知识。于是想着手搞一套表名字段名命名规则、再搞一套表对应关系（到后来才知道这叫建立“数据模型”），把证券公司的业务描述得清清楚楚，但到底怎么搞，朦朦浓浓的，不知如何下手。
另外，我这个人最讲究前因后果，所以十分想对证券业务信息中的因果关系搞清楚讲明白。例如：统计出来的股票交易量的前提条件有很多：不同营业部、不同的委托方式、不同的交易所、不同的币种、不同的证券类别、不同的客户规模、不同的客户年龄段、不同的月份日期，等等，出来的交易量结果都不一样。可以用一个表来描述，前边都是因素字段，最后一个是一数值型的交易量字段。蒙蒙浓浓知道这里边有逻辑关系，但总说不清道不明。
一般而言，越是本能的困惑，往往越是一门大学问。我们在现实工作中遇到的很多问题，美国人早就遇到了，并形成了文字、理论（还起了一堆足以让我们愣住的大写字母组成的名次。）我们缺乏的是对我们自己本质需求的理解，和与外国已有经验（经验经过归纳后就叫理论），的连接。
考虑到项目招标时，供应商如何描述“数据仓库”“元数据”等等，搞不清的概念，于是想搞清楚到底什么是“数据仓库”。于是去图书城，专门到数据仓库、OLAP、多维建模书籍区域去，挨个拿过来翻。注意：如果你没有这方面的困惑和经验，很难对这些书产生共鸣（或者理解），特别是翻译这些专业书籍的人往往本身对这些东西不懂，所以又误导了一批读者。所以，十几本书里，我只对2本里的一些描述产生强烈的共鸣。
1、《维度建模完全指南》（该书的作者自称是“数据仓库”的鼻祖）开篇对“数据仓库项目经理”的本质做了描述：一个数据的收集者，一个数据的整理者，一个统计分析数据的发布者。OK。完全与我的蒙蒙浓浓的对自己在公司里的定位完全一致！作者认为，数据仓库的本质就是收集尽可能多的信息，用作公司的决策支持（中国人总认为做决策的人一定是领导，所以把“决策支持”等同于“领导查询”，其实在美国，“决策”（decision）是分散到普通员工的（通常是普通的业务人员），而且任何一项普通的业务决定也叫“决策”，并不是“战略决策”才叫决策。所以“决策支持”绝对不是什么高深的东西）。经过清理的数据往往以一种特定的格式（所谓星型结构）存放在数据库中，整本书就是与读者探讨（注意是“探讨”，而不是“传授”，所有美国的这类权威书籍里都极力强调不要按书里的方法去实践，这就是美国鼓励自主创新和中国服从权威的不同文化的典型体现）这方面的经验。
2《建立多维信息系统》，以一步步深入的方式，解释了维度的概念。所谓“维度”，就是前边我理解的“因素字段”，影响谁呢？表结构中最后的那个数值型的字段。例如证券交易量字段。交易量字段就是一个“事实”、fact。营业部、委托方式、交易所、币种、证券类别、客户规模、客户年龄段、交易日期，都是因素字段，就是维度！数数有多少？8个，就是8维。当然可以更多。这就是多维的概念。在我们本能的对日常事务的分析中，就蕴含了“多维”的概念，只是我们没把这种意识写下来，出书，办研讨会等等。美国人做事就是较真，我们的朦朦浓浓的东西，到人家那里就是几万人研究几十年！
因为证券公司就靠着客户做证券交易收取手续费，所以业务部门对交易量的统计报表需求很强烈。2年前，由每个营业部发Email报报表，专门一个人汇总。现在有了集中的业务数据，业务部门就开始使用供应商提供的业务统计报表。太多了，例如：以营业部为行，证券类别为列出一张报表；以月份为单位出，以周为单位出；算公司交易量对证券交易所交易量的比例。等等。算了一下，不下30多张。还经常要变动。一觉得数据不正常，就找我，让我找找原因。于是，我就到数据库里去，这个字段加上那个字段再按某个字段某段时间来汇总，哦，怎么算出来跟供应商提供的报表的数值不对呢？于是打电话给供应商，让他们找问题。第二天给我一个升级补丁。好，报表好了。反反复复，搞死了。
总书j不是号召自主创新吗？干脆我自己搞一套。于是找出影响交易量的10个因素，建了一张表，前10个字段是（营业部、委托方式、交易所、币种、证券类别、客户规模、客户年龄段、交易性质、交易月份、交易周），最后一个是交易量。写了个SQL过程，每天生成这张表（后来才知道，这张表就叫CUBE。术语害死人呐。），再在EXECL里写了一些VBA（简直把美国人10个岗位分工干的活全包了），可以把这个表下载到EXCEL中。再用EXCEL的“数据旋转表”（正式中文译名为“数据透视表”，但我觉得一定要用上“旋转”这两个点睛的字）的功能，就可以灵活的配置与这10个因素字段相关的所有报表。（我们公司根本没人用过“数据旋转表”这个功能，甚至连“自动筛选”的功能都没用过。）自己挺得意的。但跟后面用MicroStrategy做出来的报表比起来就差得太远了！
日本母公司有一套MicroStratey，对中国区总裁说如何如何好，于是2005年初买了一套，做管理财务数据分析。由另一个同事负责。（当时我很奇怪，这种商业智能、BI、决策支持、数据仓库、OLAP、多维的工具应该由我来管理才对。）一直搁置在那里，直到05年底。业务部门提出对营业部每月新增底有效客户进行分析，才想起让我用MicroStrategy作为平台。正中下怀。于是，构建一个完全独立于供应商数据结构体系的数据仓库（这里指狭义的数据仓库，或者叫数据仓库展示区）成了一项现实的工作。
开始着手设计表结构。（设计一套完整的证券公司业务数据仓库可不是一件好玩的事情。）完全是瀑布方法进行设计，不断的尝试，修改，从头再来。几个月前曾沿用供应商的字段命名规则，维度表不使用代理键，试着做了套数据仓库模型，用MicroStrategy做做报表，还可以。到了春节，下决心完全重新设计这个数据仓库。这下可好，好多个晚上睡不好，脑子里完全是这个表应该是什么字段，时间维度如何划分层次，如何来划分事实，搞几个大的事实范畴，粒度到什么级别，那些事实是一个粒度，这些事实需要不同的事实表描述吗，维度表直接的关系，怎样设计维度最能保证将来的扩充性，如何避免雪花型。不断的返工。整个模型，越来越清晰。最终，自己觉得满意了，既能满足最基本的需求，也能保证将来对这个模型的扩充。又开始写SQL存储过程，验证数据转换的准确性，不断的修改，不断的扩充。不断的告诫自己，不要过于最求完美，告诫自己适度的缺陷是项目前进的保证。总之，有了一套完全自主知识产权的东西，并且自认为还是比较完备、复扎和严谨的，没有足够的思索是难以获得这个东西的。
开始设置MicroStrategy，从没系统的用过，什么都是摸石头过河。但在使用这个OLAP工具的时候，完全体会到它的好处。因为，我为业务部门做过太多的SQL统计，多到我自己都想要搞一套SELECT语句的自动生成工具。结果发现，MICROSTRATEGY完全就是我想要的东西！设置好什么实体、事实、度量、层系、上下级关系之类的东西，然后不断的试这做一些报表，找到自动生成的SELECT语句跟之前设置的那些东西到底是什么关系。没多久就摸熟了。（因为关于如何使用SELECT语句生成各种报表，我有太多的经验和苦闷。）
出来的效果出奇的好，灵活的实体配置，行列抬头的随意旋转，各种方向的钻取，汇总表的自动选取。从没觉得OLAP工具这么好用。有了它，我甚至再也不用去写SELECt语句，不用在不同的表直接Join来join去。3分钟就能做一张所谓的报表。
到现在，可以说，我已经完全领悟到数据仓库的好处。虽然这些好处只是冰山一角。
但是话说回来，如果甲方没有我这个“人”，没有对数据仓库的理解人，没有愿意对数据分析的人，公司没有精细化管理的意识，没有较真的社会风气，“数据仓库”这个概念还不是废物一堆，或者是外国供应商骗钱的口实？
一般人只看到数据仓库好处的表皮，其实还有一个重要作用是，数据仓库通过分析数据（包括报表、OLAP、挖掘），能把分析出来的东西找出来，就可以对症下药，采取措施。比如某品牌产品，在某代理商代理的销售中，在某地区某季度业绩很差，于是在下钻分析，分析出销售中第几步出了问题，分析出问题是质量不好，服务不好，还是其他原因。分析好了后，在即席查询中将所有条件列出，查询出具体的情况，公司相关部门负责人去处理，解决好具体环节。
这才是数据仓库解决实际具体情况的深入应用，不仅仅是给老总决策参考，而是给老总及部门负责人具体的，详细的信息，指导如何去处理。
这样讲不知道你是不是好理解一点：
数据仓库的概念是美国传进来的。讲讲在美国，数据仓库这个概念是怎么兴起的。
30年前，所有的美国的任何行业都轰轰烈烈的进行着信息化的活动。各种业务活动都由电脑处理，叫做“业务系统”。
必然的，所有业务系统里都有查询统计功能。
20年前，随着电脑化的业务系统里存储的历史数据逐渐增加，他们发现查询历史数据或者做业务统计的速度越来越慢。对业务数据统计分析的需求也越来越复杂。业务系统已经不堪重负。
于是很多公司就把，业务系统里的历史数据拿出来，放在另一个地方，专门负责对历史数据的查询统计分析。这个工作显得越来越重要，也越来越有企业肯花钱来做，也越来越有人认真的研究怎么把查询统计分析的工作做好。
10多年前，开始美国人开始有人起名字，就叫“数据仓库”。
这就是“数据仓库”这个名词的由来。当然，在这个领域术语极不规范，说白了就是专门用来查询分析统计业务数据的数据库。
