数据仓库能为你当前数据库体系的不足做些什么?(3) 性能是一个大问题。累积表、过去分析的结果集合等，都会增加维护工作。因此，你应测试各种极端的情况。从尽可能多的角度，重新审视你的计划。对于数据仓库的设计问题，不是一个人或一个小组就能回答的。元数据：关于数据的数据构筑数据仓库过程中的最重要步骤之一，就是定义和创建元数据(Metadata)。元数据有三个级别：数据源、数据仓库和用户(你还可以定义一个商业视图)。元数据能够提供一个目录，列出数据仓库中有什么，以及数据仓库输入数据的数据源。我的观点是：没有在系统中记载文档的东西，它(实际上)就不存在。用户元数据可以包含计算机、总结、和其它针对访问的对象。你应该仔细记载数据源、数据仓库结构和用户视图，如报表的格式，并用这些文档，去核定数据，从中得到信息的正确性。如果必要的话，还可以利用文档，实现跟踪某一数据项并检查其有效性的工作。元数据在数据仓库的创建和维护时，都可以发挥作用。在定义元数据时，便先完成最了解的部分。最终，你将为数据仓库里的每一对象类型定义元数据。元数据细化了数据结构及数据间的关系(从数据库视图，或是事务规则和数据流描述的结果)。你还应该记载别名、代码表、缺省值、完成途径、数值单位(美元或英镑)、算法和及它相关信息。在元数据(用于说明仓库中数据的)中，详细表述你对商业规则的理解。例如，你可以分析并记载系统中对象和数据元素的安全性存取访问。在此过程中，你必须确定最终对象(类)的表达，和数据仓库中衍生实例的过程(最终数据类型、数据转换、数据源和传输的预期时效)。关于积累数据，需要定义的细节有："哪些域是绝对需要的?"和"如不能获得数据，尝试另一个处理过程不同的数据源。"所有进入数据库的数据，必须在元数据中有所表述；甚至元数据也有针对自己的元数据。这些文档应描述你的系统中元数据如何表达。元数据服务器象所有复杂系统一样，元数据也会变化；但所幸的是，这一变化是渐进的。当业务或过程发生变化时，你必须将变化反应到元数据中。需要经常进行版本控制，这样，不同时刻生成的数据，就可以有不同的格式。我在许多大型系统的工作过程中，都曾开发过元数据服务器，用于提供对可能在结构、格式、或版本上发生改变的数据的访问。有了元数据服务器，你可以将数据与其元数据一道，作为一特定查询的结果，提供给用户。这样，如果有了元数据，就可以建立一个能显示任何格式数据的显示系统。同时，元数据服务器提供的信息，还可以帮助用户在系统中向下挖掘。更新数据你必须为数据仓库制定装载和刷新的计划。在这一过程中，元数据起关键作用。随着制定工作的进展，数据模型逐渐发展。新的模型，也必须用将要使用的内容进行测试。根据可更新的程度，可以讨论统一规格或是不统一规格。为了给出数据附加的含义，重要的是在系统中发现、寻找关系。你必须考虑数据库中每一数据项的时间和历史问题。数据已存在了多长时间?你需要为哪些数据项保留其变化的历史记录?是需要版本控制系统吗?你必须考虑变化，因为数据库会改变。你必须允许修改数据源、用户需要和数据模型的变化。文档与培训一套好的文档非常重要，前端工具的使用培训也很重要。关键是要避免直接与用户打交道。向他们提供了工具，他们就可以自己完成一些工作。工具在涉及数据时，应在一个可以理解的层次上。用户可不需知道数据库结构，但只需知道其表象，并应能通过这种方式访问系统。这一观点，应该且能够在需求分析阶段，得到广泛的体现。可能的方案运用数据仓库最可能的方案，是使用一个大型主机数据库系统，提供功能、控制、安全、性能和一致性。分布式数据库系统也很可行，Sybase 是一个非常强大的分布式系统,使用Sybase，数据源和数据的实际位置是透明的，并可以按需要从一处移到另一处；Sybase IQ是专门为决策支持系统而优化的交互式查询产品。如能形成一致意见，转型为一个(或两个)标准DBMS，并限定使用的平台、操作系统和网络，就可有助于简化问题。更好的方法，是选择一个产品套件，能同时提供DBMS、数据仓库、通讯和查询工具。用这种紧密的方案，集成可能很困难，有时甚至是代价高昂的。如选择这种方案，可以选用Oracle、Sybase、IBM、Information Builders和Hewlett-Packard。使用TP监视器的异构系统，是另一种较复杂的选择。大型客户/服务器应用，可能需要TP监视器控制数据操作。TP监视器，如Tuxedo和Encina，都有和大量应用工具的接口。在将来，TP监视器有可能嵌入开发或操作系统。事物是TP监视器处理的工作单元。在大型的分布系统中，必须有一些控制器，承担对系统中可能相互影响的事件的同步和处理工作。
