数据库

本类阅读TOP10

·SQL语句导入导出大全
·SQL Server日期计算
·SQL语句导入导出大全
·SQL to Excel 的应用
·Oracle中password file的作用及说明
·MS SQLServer OLEDB分布式事务无法启动的一般解决方案
·sqlserver2000数据库置疑的解决方法
·一个比较实用的大数据量分页存储过程
·如何在正运行 SQL Server 7.0 的服务器之间传输登录和密码
·SQL中两台服务器间使用连接服务器

分类导航
VC语言Delphi
VB语言ASP
PerlJava
Script数据库
其他语言游戏开发
文件格式网站制作
软件工程.NET开发
数据仓库能为你当前数据库体系的不足做些什么?

作者:未知 来源:月光软件站 加入时间:2005-2-28 月光软件站

        数据仓库可以提供对企业数据的便利访问和强大的分析工具,用于生成有意义的信息。数据仓库的目标,是从企业数据中获得有价值的信息,提供可以增加获利的情报,提高运作效率,指导商业决策,和发掘企业的竞争优势。这些目标的实现,一定会对业务产生积极的影响。现如今,数据仓库是在客户/服务器领域的一个热门的话题。对数据仓库的了解,对于客户/服务器开发人员来说,一定极有价值。

  本文介绍了数据仓库,并提供了许多关于如何实现其目标的技巧,包括关于数据收集、决策支持系统、联机分析处理和数据仓库等内容。我为每一概念下定义,并介绍了数据仓库的处理机制,还讨论了用于创建和维护数据仓库的媒体数据的定义。

  今天的客户/服务器

  早期的客户-服务器系统中的工作,主要是开发联机事务处理(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应用必须提供一套完整的函数,并要求使用自己的编程语言。

  总结

  在今天的大多数大型公司里,电子数据集已经是现成的。因此,人们认识到,能够(且应该)从数据集中获得有价值的信息,用于商业决策支持。数据仓库是一种结构和系统,可以从数据中获得信息。对于信息专家,数据仓库的应用和维护,将会很快成为工作的重要部分。




相关文章

相关软件