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