数据仓库可以提供对企业数据的便利访问和强大的分析工具，用于生成有意义的信息。数据仓库的目标，是从企业数据中获得有价值的信息，提供可以增加获利的情报，提高运作效率，指导商业决策，和发掘企业的竞争优势。这些目标的实现，一定会对业务产生积极的影响。现如今，数据仓库是在客户/服务器领域的一个热门的话题。对数据仓库的了解，对于客户/服务器开发人员来说，一定极有价值。
本文介绍了数据仓库，并提供了许多关于如何实现其目标的技巧，包括关于数据收集、决策支持系统、联机分析处理和数据仓库等内容。我为每一概念下定义，并介绍了数据仓库的处理机制，还讨论了用于创建和维护数据仓库的媒体数据的定义。
今天的客户/服务器
早期的客户-服务器系统中的工作，主要是开发联机事务处理(OLTP)应用。使业务操作自动化的应用，如定货记录、清单或预定系统，成为近期开发的重点。大部分的这一类应用是较简单的两层应用结构，其实质就是前端的GUI应用访问后端的数据库服务器。事务逻辑经常由客户工作站上的代码实现，也可以是服务器上的过程。
今天，大多数公司已完成了大大小小的客户-服务器工程的建立，或至少开始了最初步的系统建设。现在，将事务逻辑与GUI和数据源分离的三层系统，将成为未来开发的重点。商业上经常需要三层系统，以满足更大型且复杂的应用，涉及成千的客户机和数十个服务器。OLTP应用要求响应时间短、准确无误及100%的可用性和实时性。这些应用实现的基本商业操作，是业务高效运转所必须的。
数据收集和访问
大多数机构和公司都积累了大量数据，并已很好地进行了数据收集的自动化工作，运行良好(在积累及存储方面)。数据存储主要是在关系型数据库中，在这些系统中，大量的数据和数据模型，都是反映公司以往的措施和业绩。今天，SQL是数据访问的主流语言，它面向集合，并提供了应用与数据库间良好的交互性。事务由数据库服务器或事务处理(TP)监视器管理。较大型的应用，一般使用TP监视器，实现数据一致和高性能。大多数数据操作针对单条记录或相关的数据集合。定义合理的关系数据库操作，产生的结果是可预见的。RDBMS查询的结果，一般是动态的综合或计算。
决策支持系统
机构一旦拥有了完整的数据采集和存储过程，新的需要就产生了：怎样使用好数据库中有价值的信息。在竞争日益激烈的商业市场上，至关重要的是分析这些信息并生成报表，它们可以辅助商业决策。不久，你对自己经营情况的了解，就会转化为可以量化的经营优势或运行改善。
与OLTP系统相比，决策支持系统(DSS)主要是需要对数据库作只读访问，用于建立报表和查询结果，辅助制定重要的商业决策。这些系统不要求迅速响应，可以按自己的节奏运动，也许只是偶尔使用一次；并希望能将DSS的信息导出，供其它桌面软件工具使用。
DSS在看待企业数据时，使用根本不同的方法，这一不同十分重要，数据被看作是历史记录，分析的最初步骤需要进行分组和综合。经常需要对数据的子集(按月、年、地区、产品)进行数学运算，而后用图表等显示方式，可进一步解释数据的含义。
DSS用户一般直接使用DSS工具，并需要数据模型作向导。DSS通常在开始阶段使用的数据库与OLTP的一样，但DBA经常需要为新的功能或任务，创建总结表和视图，提供所需信息。
在有些情况下，需要使用复制来将运行系统中的数据移到DSS数据库中，在转移期间需要冻结(定格)生产数据，避免并发操作时出现问题。这对于DSS用户来说没有什么损失，因为他们并不需要快速的对数据的增删插改之类的事务处理，而只关心长期的表现、趋势、总结和摘要。这些工作要求具有分析功能，多数情况下还包括二次开发，用来访问不同地点的数据，这些数据可能具有不同格式，或者不能按某种方法直接得到。但这通常不只是对方案的修修补补。对于数据还需要统一格式，使查询更方便、灵活。
针对这类分析系统，你需要经常考虑的是提高性能和提供集中的功能。报表将处理大量的记录集合，只在极少情况下是个别记录。访问路径的可预见性比OLTP系统稍差，但仍可以预先建立系统中的大部分已知或重复数据访问的路径。
复制
分布式系统的增多、对高性能的要求、DSS系统的特殊性质等等，都促使复制的迅速发展。复制快速成为解决大型数据系统的性能、并发性、可用性和容量限制的基本技术。其缺点是，它不是真实数据，只是信息的复制品。因此，它也即将过时(但对于使用复制机制的双路系统，可以满意地完成双向变化传送)。
联机分析处理
联机分析处理(OLAP)将DSS带入更高的层次。OLAP是一个分析处理技术，它从企业的数据集合中收集信息，并运用了数学运算和数据处理技术。这些信息，可以灵活、交互式地提供统计、趋势分析和预测情况。OLAP用户希望OLAP(如企业数据系统)在保持原有优势，如快速访问、并发性和一致性的同时，还能具有DSS分析的强大功能，目标是怎样快速有效地获得企业数据。虽然OLAP很可能与OLTP处理共享数据来源，但OLAP在本质上与OLTP和DSS系统都不相同。你努力建立一个数据仓库，并按照需求，从中获取和选择(或挖掘)数据。也就是说，数据必须是可访问的，按照灵活的模式组织，并且可以修改(替换)。这些方面不是偶然出现的，它要求全企业人员的大量努力和合作。
对大型公司来讲，正在进行的最复杂的工作，可能要算是对数据仓库体系的设计和应用了。用户们新的关注焦点是：他们想显示系统中的信息，而不仅仅是访问数据。虽然有些人可能仍旧把数据仓库看作与运行数据库基本相同，但数据仓库在设计过程中，一直贯穿着访问、分析和报表的思想。因此，数据仓库在用户检索时，比DSS系统更易于优化。这样，将产品与仓库中的数据分开。但这些只能到此为止，它必须保持灵活性。这一类信息，可通过下述工具得到：Business Objects公司的Business Objects Brio Technology的BrioQuery和Cognos的PowerPlay，等等；此外，Sybase的S-Designer 6.0将具备数据仓库设计的功能。
多维数据库
OLAP系统必须是灵活的、能按非预定的方式访问数据，还必须交互地创建报表。问题的关键是如何表达以下内容：复杂数据查询、寻找(发掘)趋势、总结、评价和关系。"假如"查询，就象在使用电子表格软件时常常见到的，是一项基本技术。其它如"为什么"或"怎样"等，也同等重要。这些查询通常与另一些变量一同使用，用于限定信息的上下文。查询的例子，可以与产品类型、时间段或地点有关。
由于使用了这些分析变量，就给数据带来了多维性。在分析时，这些变量的不同取值，会产生出相关的不同对比信息。预测也是处理的一部分。在分析生成之后，用户可以向下挖掘，查看更为详细的信息，它们是整体的子集，向上移动，则可以显示分析的上一个层次。
数据仓库
数据仓库是由一个或多个应用，和一个用于分析和报表的数据库组成的系统。此数据库从其它数据源中得到数据。通常先有一个对数据库数据的载入工作，然后定期地进行数据快照或逐步更新。数据仓库创建的数据，面向主题，完全一致，将为重要的商业决策提供所需信息。
数据仓库服务器提供了对其中数据的访问。用于分析和生成报表的应用，可以定制编写，也可以购买(我推荐使用Cognos Impromptu和PowerPlay)。数据收集和积累工具也有现成产品，且这一市场将不断扩展。
构筑数据仓库
构筑数据仓库所需的开发小组成员，要求既有技术知识又有商业知识，这样就可以同时具有自上而下和自下而上的全面了解。数据仓库涉及到的方面有：数据集(包括历史)、设计(数据模型)、文档和数据库维护。数据仓库还要求定义系统的元数据(在下节中讲述)，以及考虑数据分布(开发应用及购买工具。)
如果有多个数据源，那么数据集合的维护工作将会极为困难。每个数据源，都可能有不同的格式、平台、标准、含义、历史影响和标志。在不同数据源，甚至在一个源中，也可能出现同一对象的多个实例。数据经常是不完整的，或是经过编程修补的。你必须了解并记录下所有细节。建立数据仓库的努力，通常会是一个持续数月的大工程，甚至可能几年。当你的目标还不十分清楚的时候，你最好先猜测一个方案，按照它建立模型数据仓库，然后在这个模型上运行各种工具，以检查最初的要求是否正确。对模型的测试，应既有一般情况，又有特殊情况，通过这一步骤，你就可以发现各个工作都是什么，以及在企业中它们是如何起作用的。你要访查用户，特别是那些真正了解数据及数据源的人。最终的系统，可能要求创建报表、某些特殊工具，甚至可能开发新的应用。但在任何情况下，你的职责都是为用户提供数据和工具。
从本质上讲，对数据仓库的访问，应主要是只读操作，有时也可能将某些分析存放在数据仓库中。它必须按时更新，以反应用户的要求及数据源数据的变化。因此，出现了新的维护问题：检查、重新生成和删除分析记录。生产数据需要在数据仓库中不断更新，而仓库中的数据，也需要向业务方面或部门复制。
首先，你必须定义最初数据仓库系统的范围，从理解得最好的部分开始，一定要有一个分析人员作助手。许多分析人员在部门数据库上发展数据仓库。这些数据库已被透彻理解，重新建立模型的时机也已成熟。
性能是一个大问题。累积表、过去分析的结果集合等，都会增加维护工作。因此，你应测试各种极端的情况。
从尽可能多的角度，重新审视你的计划。对于数据仓库的设计问题，不是一个人或一个小组就能回答的。
元数据：关于数据的数据
构筑数据仓库过程中的最重要步骤之一，就是定义和创建元数据(Metadata)。元数据有三个级别：数据源、数据仓库和用户(你还可以定义一个商业视图)。元数据能够提供一个目录，列出数据仓库中有什么，以及数据仓库输入数据的数据源。我的观点是：没有在系统中记载文档的东西，它(实际上)就不存在。用户元数据可以包含计算机、总结、和其它针对访问的对象。你应该仔细记载数据源、数据仓库结构和用户视图，如报表的格式，并用这些文档，去核定数据，从中得到信息的正确性。如果必要的话，还可以利用文档，实现跟踪某一数据项并检查其有效性的工作。
元数据在数据仓库的创建和维护时，都可以发挥作用。在定义元数据时，便先完成最了解的部分。最终，你将为数据仓库里的每一对象类型定义元数据。元数据细化了数据结构及数据间的关系(从数据库视图，或是事务规则和数据流描述的结果)。你还应该记载别名、代码表、缺省值、完成途径、数值单位(美元或英镑)、算法和及它相关信息。
在元数据(用于说明仓库中数据的)中，详细表述你对商业规则的理解。例如，你可以分析并记载系统中对象和数据元素的安全性存取访问。在此过程中，你必须确定最终对象(类)的表达，和数据仓库中衍生实例的过程(最终数据类型、数据转换、数据源和传输的预期时效)。关于积累数据，需要定义的细节有："哪些域是绝对需要的?"和"如不能获得数据，尝试另一个处理过程不同的数据源。"
所有进入数据库的数据，必须在元数据中有所表述；甚至元数据也有针对自己的元数据。这些文档应描述你的系统中元数据如何表达。
元数据服务器
象所有复杂系统一样，元数据也会变化；但所幸的是，这一变化是渐进的。当业务或过程发生变化时，你必须将变化反应到元数据中。需要经常进行版本控制，这样，不同时刻生成的数据，就可以有不同的格式。我在许多大型系统的工作过程中，都曾开发过元数据服务器，用于提供对可能在结构、格式、或版本上发生改变的数据的访问。有了元数据服务器，你可以将数据与其元数据一道，作为一特定查询的结果，提供给用户。这样，如果有了元数据，就可以建立一个能显示任何格式数据的显示系统。同时，元数据服务器提供的信息，还可以帮助用户在系统中向下挖掘。
更新数据
你必须为数据仓库制定装载和刷新的计划。在这一过程中，元数据起关键作用。随着制定工作的进展，数据模型逐渐发展。新的模型，也必须用将要使用的内容进行测试。根据可更新的程度，可以讨论统一规格或是不统一规格。为了给出数据附加的含义，重要的是在系统中发现、寻找关系。
你必须考虑数据库中每一数据项的时间和历史问题。数据已存在了多长时间?你需要为哪些数据项保留其变化的历史记录?是需要版本控制系统吗?你必须考虑变化，因为数据库会改变。你必须允许修改数据源、用户需要和数据模型的变化。
文档与培训
一套好的文档非常重要，前端工具的使用培训也很重要。关键是要避免直接与用户打交道。向他们提供了工具，他们就可以自己完成一些工作。工具在涉及数据时，应在一个可以理解的层次上。用户可不需知道数据库结构，但只需知道其表象，并应能通过这种方式访问系统。这一观点，应该且能够在需求分析阶段，得到广泛的体现。
可能的方案
运用数据仓库最可能的方案，是使用一个大型主机数据库系统，提供功能、控制、安全、性能和一致性。分布式数据库系统也很可行，Sybase 是一个非常强大的分布式系统,使用Sybase，数据源和数据的实际位置是透明的，并可以按需要从一处移到另一处；Sybase IQ是专门为决策支持系统而优化的交互式查询产品。
如能形成一致意见，转型为一个(或两个)标准DBMS，并限定使用的平台、操作系统和网络，就可有助于简化问题。更好的方法，是选择一个产品套件，能同时提供DBMS、数据仓库、通讯和查询工具。用这种紧密的方案，集成可能很困难，有时甚至是代价高昂的。如选择这种方案，可以选用Oracle、Sybase、IBM、Information Builders和Hewlett-Packard。
使用TP监视器的异构系统，是另一种较复杂的选择。大型客户/服务器应用，可能需要TP监视器控制数据操作。TP监视器，如Tuxedo和Encina，都有和大量应用工具的接口。在将来，TP监视器有可能嵌入开发或操作系统。事物是TP监视器处理的工作单元。在大型的分布系统中，必须有一些控制器，承担对系统中可能相互影响的事件的同步和处理工作。
还有可能出现更复杂的要求。你将看到：图形、Internet和多媒体，正变得日益重要。这些会加大需求的复杂度，并大大增加数据传输量。
OLAP数据库几乎总是非常庞大的，因此性能很成问题。解决方法有：分隔数据、分布数据、过滤数据，也可能建立并维持文件以存放常用信息。如果数据仓库主要用于DSS，那么你就可以在很大程度上，将复制工作交给一个客户/服务器系统完成。
开发OLAP应用
开发OLAP应用可能十分困难，其编写方式应是面向对象的。OLAP中的许多处理非常相似，因而可以为它们开发对象类。例如，在大多数OLAP应用中，数据访问、数据存储、分析(函数)、和报表生成的用法，都是基本一致的。使用面向对象技术，可以提高可重用性。OLAP应用还应是可扩展的，并且应设计为可扩展的系统。
系统应使用并管理元数据和数据字典。使用经解释的语言方案，可以在改动后无需重新编译。OLAP应用必须提供一套完整的函数，并要求使用自己的编程语言。
总结
在今天的大多数大型公司里，电子数据集已经是现成的。因此，人们认识到，能够(且应该)从数据集中获得有价值的信息，用于商业决策支持。数据仓库是一种结构和系统，可以从数据中获得信息。对于信息专家，数据仓库的应用和维护，将会很快成为工作的重要部分。
