【IT168技术文档】
    前些天我一直在关注SQLServerCentrol.com网站上一个令人着迷的话题，它是由Steve Jones发表的一篇社论“Two Weeks”引起的。Steve Jones曾被邀请参加2007年5月第一届“微软商务智能大会”，大会每年举办一次。除了别的以外，对于数据库管理员是否已经准备好应对数据仓库技术的复杂性，商务智能是迎来了黄金时期还是只是作为一种候选，他都感到怀疑。
   
    从我所处的技术发展前沿这个有利情况来看，我可以告诉你，如果你想继续留在IT行业的话，你最好做好准备因为商务智能离我们已经很近。你是否拥有所有的工具或者是否受过正规的训练这都不重要，你必须做好准备并且尽可能利用你所拥有的做到最好。如果你试了，你会对你所能做的感到吃惊。

    对于我来说也没有太大区别。在1997年夏天我做了我的第一个数据仓库项目，是为一个为高等教育开发软件的软件公司做的。刚开始时，我们中的一些人甚至不知道这是一个数据仓库。我们的项目只是一个简单的应用程序，从事务系统收集学生数据，然后学校使用它来创建统计报告。那个时候，Bill Inmon刚刚引入OLAP的概念，数据仓库对大多数人来说还是陌生的；没有多少商务智能工具来帮我们做这样的工作。开发组的一些人员以前从来没听说过数据仓库。我们只是全力以赴，做了大量的研究和调查以了解我们需要做什么以及怎样去做。

在摸索中前进

    组里有12个人，其中包括一个项目经理，一个系统架构师，一个商业分析师，一个Oracle DBA和几个数据库开发人员。我认为没有一个人称得上是数据仓库方面的专家。公司有两套事务系统－一个用COBOL写的，并且使用了VSAM文件，另一个使用了Oracle Forms和Oracle 7数据库。新的产品必须和这两个事务系统配合工作。我们决定使用Oracle 8i来构建我们的数据仓库，并且学习了什么是星型模式。 

   商业分析师和事务开发者共同决定需要哪些维。主要的维有时间，学生，地理，人口统计，学院的系，课程和师资。一些维内部分层以使得用户能够向下钻取更多的细节。例如地理维有国家，行政区，郡，州，城市和邮政编码这些成员。度量有学生数，学费或者经济资助金。

    几乎每一步都是一种挑战。我们不得不通过任何可能的途径去学习。我们构建用来描述数据仓库表中每个域的元数据表。这些表包括数据仓库中特定域的有效值和事务系统中的有效值，因此我们能够把它们转换成数据仓库中唯一确定的值。自从Oracle有了Web应用服务器，开发者能够使用PL/SQL访问Oracle数据库，同时使用嵌入的HTML标签来创建网页。这样就允许用户通过网络很容易地输入和更新元数据表。

    ELT（提取，装载和转换）系统是用两种不同的语言构建的。它尤其是一种挑战，我们实在不得不临时准备。开发者使用PL/SQL从Oracle事务系统中提取数据，然后存入段表中。针对主框架事务系统，开发者写了COBOL程序来提取数据存入文本文件。然后他们使用SQL装载器把文本文件装载到Oracle段表中。所有的段表被清空并且使用元数据表中的值来转换。我们使用PL/SQL来读取包含事务值的段表，使用元数据表来清空和转换。我们有一个错误报告表明哪些记录有问题。那些无误的记录被PL/SQL装载到维表和事实表中。

    网络GUI接口是另一个特殊的挑战。不仅数据仓库那时非常新，而且网络接口也不是确切的标准特征。其中一个要求是用户能够通过选择两个维和一个度量或者一个维和两个度量来建立他们自己的查询。GUI 接口是用PL/SQL 和JAVA写的。用户从网络上查询维和度量，JAVA程序使用http把它们交给PL/SQL程序，就像打开一个网页但是在链接里带有输入值，例如http://www.abc.com?name='abc'。网页事实上就是PL/SQL程序,因为我们使用了Oracle Web应用服务器。PL/SQL 程序得到维和度量后，进行动态查询，然后把只有数据的信息发送到一个静态网站－我们有标志来区分行和列。然后JAVA程序能够读到那个网页并在用户网页上生成结果。用户可以选择把结果以表格或图表的形式显示出来。用户也可以把他们最喜欢的查询保存下来放到菜单里，这样他们就不必一次又一次地选择维和度量了。我一直认为这个模块是颇有直觉力的并且以它为骄傲。

    数据库管理员当然也要参与其中。Oracle那时刚刚发布8i的版本，所以数据库管理员能够使用时间这个维来区分数据仓库。数据库管理员也要关心创建用户安全机制以检查哪些用户有登录系统的权限。有个开发者用PL/SQL开发出来基于安全机制的角色，使得大学人事里不同级别的人有不同的安全级别，例如，校长能够看到一切数据而系主任只能看到他自己系的数据。

    如果你要问我们中的任何一个人在1997年对数据仓库是否有充分准备，我想你会得到一致的回答“一点也没有”。但是我们确实做到了，并且乐在其中，即使我们不得不拼命地工作，而且大部分时间不知道自己在做什么。关键是我们学到了我们必须学的东西，同时数据仓库已经发展起来。商务智能现在已经发展起来，我相信如果你想留在IT行业的话你迟早会学它的。

今天比昨天容易多了－所以准备好吧！

    现在有很多更容易的方式来建立数据仓库。甚至有书一步一步清楚地教给你必须做些什么。你可以长时间反复讨论你的数据仓库项目用什么工具最好以及什么数据库最容易使用。

    但是不管你使用什么数据库或者给你什么样的工具，建立数据仓库的概念是一样的。你需要设计并创建维表，事实表和元数据表。用的最多的是星型模式。总是要有一个ETL过程，而这总是很困难的。清空和转换过程也必不可少，以保证数据质量。现在有如此多的ETL工具来清空和建立数据仓库，很难跟踪它们。有如此多的软件产品供选择以建立各种不同的商务智能报告－网络分析报告，计划报告，预测报告，交互报告甚至dashboard reports。但是又能如何呢！现在我不再需要这些工具来建立一个动态数据仓库和报告了，就像12年前那样。并且你也不需要！用你所拥有的开始已经足够了。

    我们12个人花了两年的时间在我们第一个数据仓库项目的开发和学习上。它也将花费你一些时间。我们都学到了很多数据仓库方面的知识，你也会的。不久以后你将拥有你的第一个数据仓库项目的机会。现在就学习关于它的所有能学的东西和与之相关的商务智能技术吧。不必为你没有工具而担心！在你获得这个机会之前，准备好吧！

注：
1 star schema:星型模式
    数据仓库这么多年来发展的成果，我认为恐怕最重要的要算star schema了，可以说它是整个数据仓库的基石。star schema主要的思想在于将我们关心的数据和用于描述数据的属性分隔开来。实际的数据存放于Fact table中，从不同角度来描述数据的属性放到不同的dimension table中。比如，一个sales数据仓库可以这样设计，每一笔销售记录，应该会包含销售的产品，销售的客户，销售的供货商，销售的时间，销售的数量和获得的收入等。当我们要分析整个公司的所有销售记录时，毫无疑问，我们最关心的是一共销售了多少？一共获得了多少收入？然后更进一步，在某个时间段内销售了多少？来自哪家供货商的产品的销售额最大？面向哪种客户的销售额最大？哪种产品的销售额最大？等等。

    从上面我们关心的这些问题我们可以看到，对于销售的数量和金额这类具体的数字型的数据，通常是我们分析的对象，而对于像时间，产品，客户，供货商，我们希望从这些不同的角度来得到数字型数据的一个统计结果。所以，我们将数字型的数据存放在fact table中，将时间，产品，客户，供货商存放在不同的dimension table中，自然，在fact table和dimension table之间存在一个主-外键的关联，各个dimension table之间则没有关系。由此我们可以得到如下的一个star schema: