数据仓库是干什么的，到现在，我终于看到了成果。
跟所有2004年的证券公司一样，“生”与“死”是我们公司考虑的唯一问题。为获得证监会的“规范类券商资格”(获得这个牌照就如同获得了免死金牌，不但能够生存而且能获得资助从而做大做强)，公司急需上马一套集中监控系统。
背景：
在证券行业中，所有公司的业务系统（所谓证券交易系统）有一个基本特征：每一个分支机构（所谓营业部）的交易系统都是独立的（地理上、管理上），这样总部没办法在技术上对数十套这样的系统的业务数据进行及时的分析与核对。（当然这两年几乎所有公司都实现了交易系统的集中。）于是，几乎所有的证券公司都上马了一套集中监控系统，它通过广域网，把公司下属的这几十家营业部的数据实时或当天晚上采集到总部的数据库中，白天实时的对资金存取、证券买卖等业务行为进行监控，晚上再运算一些核对功能，看资金和证券是否帐实相符，再通过WEB界面将结果展示给公司审计部门。我们公司在06年上半年上了这个系统。
由于手头上的这个系统整合了公司所有的业务系统的数据(30多套分布在全国各地的交易系统、30多套财务系统、集中清算系统、登记公司数据、等等)，所以象每个技术型IT员工一样，我有一个自然而然的想法：能不能搞清楚公司所有业务信息的逻辑关系，自己建一个数据库，搞一个数字虚拟证券公司，在我的这个数据库中包含公司每一个业务细节的信息，业务部门不管要什么，我都能很快提供出来（而不是依赖供应商）。
OK。在我这个最朴素的想法的支配下，我开始学习数据库（搞了若干年IT基础设施的我，居然在2005年底又开始学习数据库！可见中国的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的销售人员，来公司推销，说这个系统如何如何好。刚才日本回来的IT总监见识过它的威力，所以于是2006年初买了一套。于是，构建一个完全独立于供应商数据结构体系的数据仓库（这里指狭义的数据仓库，或者叫数据仓库展示区）成了一项现实的工作。有了粮食，才能提供给所谓的报表工具来做可口的饭菜。
开始着手设计表结构。（设计一套完整的证券公司业务数据仓库可不是一件好玩的事情。）完全是瀑布方法进行设计，不断的尝试，修改，从头再来。几个月前曾沿用供应商的字段命名规则，维度表不使用代理键，试着做了套数据仓库模型，用MicroStrategy做做报表，还可以。到了春节，下决心完全重新设计这个数据仓库。这下可好，好多个晚上睡不好，脑子里完全是这个表应该是什么字段，时间维度如何划分层次，如何来划分事实，搞几个大的事实范畴，粒度到什么级别，那些事实是一个粒度，这些事实需要不同的事实表描述吗，维度表直接的关系，怎样设计维度最能保证将来的扩充性，如何避免雪花型。不断的返工。整个模型，越来越清晰。最终，自己觉得满意了，既能满足最基本的需求，也能保证将来对这个模型的扩充。又开始写SQL存储过程，验证数据转换的准确性，不断的修改，不断的扩充。不断的告诫自己，不要过于最求完美，告诫自己适度的缺陷是项目前进的保证。总之，有了一套完全自主知识产权的东西，并且自认为还是比较完备、复扎和严谨的，没有足够的思索是难以获得这个东西的。
开始设置MicroStrategy，从没系统的用过，什么都是摸石头过河。但在使用这个OLAP工具的时候，完全体会到它的好处。因为，我为业务部门做过太多的SQL统计，多到我自己都想要搞一套SELECT语句的自动生成工具。结果发现，MICROSTRATEGY完全就是我想要的东西！设置好什么实体、事实、度量、层系、上下级关系之类的东西，然后不断的试这做一些报表，找到自动生成的SELECT语句跟之前设置的那些东西到底是什么关系。没多久就摸熟了。（因为关于如何使用SELECT语句生成各种报表，我有太多的经验和苦闷。）
出来的效果出奇的好，灵活的实体配置，行列抬头的随意旋转，各种方向的钻取，汇总表的自动选取。从没觉得OLAP工具这么好用。有了它，我甚至再也不用去写SELECt语句，不用在不同的表直接Join来join去。3分钟就能做一张所谓的报表。
到现在，可以说，我已经完全领悟到数据仓库的好处。虽然这些好处只是冰山一角。
但是话说回来，如果甲方没有我这个“人”，没有对数据仓库的理解人，没有愿意对数据分析的人，公司没有精细化管理的意识，没有较真的社会风气，“数据仓库”这个概念还不是废物一堆，或者是外国供应商骗钱的口实？