编者按：数据仓库是干什么的？数据仓库有什么好处？请看作者对数据仓库意义的困惑、探索和感悟。现在，他终于看到了成果。亲爱的读者，如果您有什么想法或建议，欢迎来稿来电，与本文编辑（MSN：bunnybunny505#hotmail.com  TEL：021-33680077*265）及更多的朋友分享您的经验。

　　【IT168 专稿】跟所有的证券公司一样，生与死是我们公司考虑的唯一问题。为获得证监会的“规范类券商资格”(获得这个牌照就如同获得了免死金牌，不但能够生存，还能获得资助，从而做大做强)，公司急需上马一套集中监控系统。

建立虚拟证券公司 把握业务逻辑关系

　　在证券行业中，所有公司的业务系统（所谓证券交易系统）有一个基本特征：每一个分支机构（所谓营业部）的交易系统都是独立的（地理上、管理上），总部没办法在技术上对数十套这样的系统的业务数据及时分析与核对。（当然这两年几乎所有公司都实现了交易系统的集中。）

　　于是，几乎所有的证券公司都上马了一套集中监控系统，通过广域网，把公司下属几十家营业部的数据实时或当天晚上采集到总部的数据库中。白天实时对资金存取、证券买卖等业务行为监控，晚上再运算一些核对功能，看资金和证券是否帐实相符，再通过WEB界面将结果展示给公司审计部门。我们公司在2006年上半年上了这个系统。

　　由于这个系统整合了公司所有业务系统的数据(30多套分布在全国各地的交易系统、30多套财务系统、集中清算系统、登记公司数据等等)，我有一个自然而然的想法：能不能搞清楚公司所有业务信息的逻辑关系，自己建个数据库，搞个数字虚拟证券公司，囊括公司每一个业务细节的信息，业务部门不管要什么，我都能很快提供出来，而不是依赖供应商。

　　在这个想法的支配下，我开始学习数据库（搞了若干年IT基础设施的我，居然在2005年底又开始学习数据库！可见中国的IT岗位有多么不清晰），向供应商请教底层数据结构，向他们请教业务逻辑关系。

　　3个月后，我居然已经能够为供应商提供的“监控功能”提供完全的功能验证，指出了无数的功能BUG，同时也具备了证券交易、结算业务逻辑的知识。于是想着手搞一套表名字段名命名规则，再搞一套表对应关系（后来知道这叫建立“数据模型”），把证券公司的业务描述得清清楚楚，但到底怎么搞，不知如何下手。

　　于是想把证券业务信息中的因果关系搞清楚。例如，统计出来的股票交易量的前提条件有很多：不同营业部、不同的委托方式、不同的交易所、不同的币种、不同的证券类别、不同的客户规模、不同的客户年龄段、不同的月份日期等等，出来的交易量结果都不一样。可以用一个表来描述，前边都是因素字段，最后是一数值型的交易量字段。

搞懂数据仓库 质疑供应商报表

　　考虑到项目招标时，供应商描述过“数据仓库”、“元数据”等等，想搞清楚到底什么是“数据仓库”。去图书城，专门到数据仓库、OLAP、多维建模书籍区域去，挨个拿过来翻。翻译这些书籍的人往往本身对这些东西不懂，误导了一批读者，十几本书里，我只对2本的描述产生强烈的共鸣。

　　①《维度建模完全指南》（该书的作者自称是“数据仓库”的鼻祖）开篇对“数据仓库项目经理”的本质做了描述：一个数据的收集者，一个数据的整理者，一个统计分析数据的发布者。与我对自己在公司里的定位完全一致！

　　作者认为，数据仓库的本质就是收集尽可能多的信息，用作公司的决策支持（中国人总认为做决策的人一定是领导，所以把“决策支持”等同于“领导查询”。其实在美国，“决策”是分散到普通员工的，通常是普通的业务人员，而且任何一项普通的业务决定也叫“决策”，并不是“战略决策”才叫决策。所以“决策支持”绝对不是什么高深的东西）。

　　经过清理的数据往往以一种特定的格式（所谓星型结构）存放在数据库中，整本书就是与读者探讨（注意是“探讨”，而不是“传授”，所有美国的这类权威书籍里都极力强调不要按书里的方法去实践，这就是美国鼓励自主创新和中国服从权威的不同文化的典型体现）这方面的经验。

　　②《建立多维信息系统》，以一步步深入的方式，解释了维度的概念。所谓“维度”，就是前边我理解的“因素字段”，影响谁呢？表结构中最后那个数值型的字段。例如证券交易量字段，交易量字段就是一个“事实”；营业部、委托方式、交易所、币种、证券类别、客户规模、客户年龄段、交易日期，都是因素字段，就是维度！数数有多少？8个，就是8维。

　　证券公司就靠着客户做证券交易收取手续费，所以业务部门对交易量的统计报表需求很强烈。2年前，由每个营业部发Email报报表，专门一个人汇总。现在有了集中的业务数据，业务部门就开始使用供应商提供的业务统计报表。例如：以营业部为行，证券类别为列，出一张报表；以月为单位出，以周为单位出；算公司交易量对证券交易所交易量的比例等等。

　　算了一下，不下30多张，还经常要变动。一觉得数据不正常，就找我，让我找原因。我就到数据库里去，这个字段加上那个字段，再按某个字段某段时间来汇总，怎么算出来跟供应商提供的报表数值不对呢？于是打电话给供应商，让他们找问题。第二天给我一个升级补丁。报表好了，反反复复，折腾人。

自主设计报表  3分钟解决问题

　　干脆我自己搞一套。找出影响交易量的10个因素，建了一张表，前10个字段是（营业部、委托方式、交易所、币种、证券类别、客户规模、客户年龄段、交易性质、交易月份、交易周），最后一个是交易量。

　　写了个SQL过程，每天生成这张表（后来才知道，这张表就叫CUBE。术语害死人呐），在EXECL里写了一些VBA，可以把这个表下载到EXCEL中。再用EXCEL的“数据旋转表”（中文译名为“数据透视表”，但我觉得要用上“旋转”这两个点睛的字）的功能，就可以灵活配置与这10个因素字段相关的所有报表。

　　我们公司根本没人用过“数据旋转表”这个功能，甚至连“自动筛选”的功能都没用过，自己挺得意的，但跟后面用MicroStrategy做出来的报表比，就差得太远了。

　　MicroStratey的人来公司推销，说这个系统如何如何好。才从日本回来的IT总监见识过它的威力，于2006年初买了一套。于是，构建一个完全独立于供应商数据结构体系的数据仓库（这里指狭义的数据仓库，或者叫数据仓库展示区）成了一项现实的工作。有了粮食，才能提供给所谓的报表工具来做可口的饭菜。

　　开始着手设计表结构，完全是瀑布方法设计，不断尝试、修改、从头再来。几个月前曾沿用供应商的字段命名规则，维度表不使用代理键，试着做了套数据仓库模型，用MicroStrategy做做报表，还可以。

　　到了春节，下决心重新设计这个数据仓库。这下可好，好多个晚上睡不着，脑子里全是这个表应该是什么字段，时间维度如何划分层次，如何来划分事实，粒度到什么级别，需要不同的事实表描述吗，维度表直接的关系，怎样设计维度最能保证将来的扩充性，如何避免雪花型。

　　不断返工，整个模型越来越清晰。最终，既能满足最基本的需求，也能保证将来模型的扩充。又开始写SQL存储过程，验证数据转换的准确性。不断告诫自己，不要过于最求完美，告诫自己适度的缺陷是项目前进的保证。总之，有了一套完全自主知识产权的东西。

　　开始设置MicroStrategy，但在使用OLAP工具的时候，完全体会到它的好处。因为，我为业务部门做过太多的SQL统计，多到我自己都想要搞一套SELECT语句的自动生成工具。结果发现，MICROSTRATEGY完全就是我想要的东西。

　　设置好什么实体、事实、度量、层系、上下级关系之类的东西，然后不断做一些报表，找到自动生成的SELECT语句跟之前设置的那些东西到底是什么关系。没多久就摸熟了。（因为关于如何使用SELECT语句生成各种报表，我有太多的经验和苦闷。）

　　效果出奇得好，灵活的实体配置，行列抬头的随意旋转，各种方向的钻取，汇总表的自动选取。从没觉得OLAP工具这么好用。有了它，我甚至再也不用去写SELECT语句，不用在不同的表直接Join来join去。3分钟就能做一张所谓的报表。

　　现在，可以说我已经完全领悟到数据仓库的好处。虽然这些好处只是冰山一角。话说回来，如果甲方没有我这个“人”，没有对数据仓库理解的人，没有愿意对数据分析的人，公司没有精细化管理的意识，“数据仓库”这个概念还不是废物一堆，或者是外国供应商骗钱的口实？