分享
 
 
 

数据仓库能为你当前数据库体系的不足做些什么?

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

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

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

今天的客户/服务器

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

总结

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有