基于CWM的数据仓库体系结构设计.docx
《基于CWM的数据仓库体系结构设计.docx》由会员分享，可在线阅读，更多相关《基于CWM的数据仓库体系结构设计.docx（62页珍藏版）》请在冰点文库上搜索。
基于CWM的数据仓库体系结构设计
基于CWM的数据仓库体系结构设计
第一章：
绪论
1．1课题背景
90年代末以来，国内外掀起了一股数据仓库的热潮，数据仓库技术作为一种决策支持的手段为越来越多的企业接受。
各大数据库公司纷纷开发自己的数据仓库产品，还有很多公司开发了相关的分析工具。
这些工具给用户带来了很大的方便，但同时，由于它们都采用自己的数据格式和元数据表示方法，互相之间不能兼容，企业的很多应用就要依赖于特定厂商的产品，数据仓库的设计和实现受到很大的限制。
所以，搭建一个统一且易于扩展的数据仓库平台，并能实现其中不同工具之间的数据交换，就成为亟需解决的问题。
电信行业是我国引入竞争相对较晚的一个行业，但竞争的激烈程度丝毫不亚于其他行业。
各电信企业都积累了庞大的客户和业务资料库，并纷纷开始搭建数据仓库以增加竞争优势。
但由于电信行业数据庞杂、需求广泛且多变，单一厂家的数据仓库工具很难满足要求。
若采用多种工具，系统的体系结构设计以及不同工具之间的数据交换就成为必须解决的关键问题。
一种解决方案是利用元数据。
元数据是描述数据的数据，是数据仓库系统不可或缺的重要部分。
一般来说，数据仓库中的元数据有两个用途，首先，它能提供基于用户的信息，比如记录数据项的业务描述元数据能帮助用户去使用信息；其次，元数据能支持系统对数据的管理和维护，如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。
如果异质平台上不同的数据仓库工具之间能够实现所有这些元数据的交换，实际上也就是实现了它们所描述数据的交换，从而解决异质工具之间的互通问题。
但元数据的交换涉及到很多问题，比如元数据的表示形式以及交换机制等。
为了解决这方面的问题，OMG在2000年提出了一套关于数据仓库元数据的CWM（通用仓库元模型）规范，其主要目的就是为了方便异质分布式系统中的数据仓库工具、数据仓库平台以及元数据库之间的元数据交换。
而研究如何搭建电信领域基于CWM的数据仓库系统并实现不同工具之间的数据交换正是本论文展开研究的背景。
1．2工作内容及研究成果
为了使构筑于数据仓库基础上的企业应用不再和具体的工具绑定，本文试图提出一种可行的基于CWM的数据仓库体系结构设计方案。
结合这个目标，本论文主要做了以下几方面的工作：
调研：
包括目前一些企业已经实施的数据仓库的体系结构、现有工具产品、电信企业需求、电信企业业务数据结构等。
理论研究：
主要是对CWM、UML、MOF、XMI等规范以及体系结构理论的研究并提出基于CWM的数据仓库体系结构。
部分实现体系结构：
由于目前尚无工具支持CWM，所以只能部分实现本论文提出的体系结构，搭建一个实用的数据仓库系统，其中的接口部分作为下一步的工作。
在基本完成上述工作内容的情况下，获得的主要成果是提出一种基于CWM的数据仓库体系结构并在电信领域得到初步应用。
1．3论文结构
本论文的内容基本按照工作内容进行组织：
第二、三章作为核心内容的铺垫，主要介绍了论文的理论基础。
其中第二章首先介绍了数据仓库的相关理论（包括数据仓库的定义、特点、数据模型、建设和应用等）。
随后介绍元数据的定义、分类、建模和标准化。
最后是体系结构的概念以及几种主要的风格。
第三章介绍了CWM相关理论。
此章首先简单描述了CWM和UML、MOF、XMI等规范之间的关系，然后介绍了CWM的组成结构、特点、设计目标及其适用范围。
第四章是本论文的核心部分，提出一种基于CWM的企业数据仓库系统体系结构，并详细介绍组件的功能、地位和接口，这些组件包括数据源、ETL、数据建模、中央元数据库、本地元数据库、ODS、中央数据仓库、数据集市、数据仓库管理以及一些前端分析应用等。
第五章介绍了在电信领域基于上述体系结构设计的一个数据仓库系统，具体内容包括该系统的任务概述、开发运行环境、体系结构设计、系统部署、数据建模以及系统优缺点分析。
第六章对本文作了简单总结，并对进一步的研究工作提出了几个建议。
论文最后是致谢及参考文献列表。
第二章：
数据仓库、体系结构、元数据理论概述
2．1引言
笔者系统地学习了数据仓库的基本理论、研究了目前的数据仓库元数据的内容、特点和交换机制，最后参考目前几种典型的体系结构风格，并结合企业应用数据仓库的成功案例，提出一种基于CWM的数据仓库体系结构。
下面，本章将简单介绍数据仓库、元数据和体系结构方面的理论知识，至于CWM规范，由于内容比较多，所以单独作为一章介绍。
2．2数据仓库理论概述
2．2．1引言
随着市场竞争的日趋激烈，人们越来越深刻地认识到信息对于企业的生存和发展所起的重要作用，可以说，谁先掌握了广泛而可靠的信息，谁就把握了企业发展的先机，但信息来自何方？
近年来，很多企业都建立了较为完善的数据库系统，用于存储信息的数据也不断膨胀，但由于企业管理技术的落后，对这些积累起来的海量数据远没有充分利用，在这种背景下，数据仓库技术应运而生。
数据仓库建立在传统事务型数据库的基础之上，为企业DSS（决策支持系统）提供数据源。
2．2．2数据仓库的定义及特点
目前，大家公认的数据仓库创始人WilliamH．Inmon在他所著的《建立数据仓库》一书中对数据仓库所下的定义是：
数据仓库是在企业管理和决策中面向主题的、集成的、不可更新的、随时间不断变化的数据集合。
由这个定义可以看出数据仓库主要有以下四个特点：
Ø面向主题：
主题是在一个较高层次上将数据进行综合、归类并进行分析利用的抽象。
面向主题的数据组织方式，就是在较高层次上对分析对象的数据的完整、一致的描述，能统一地刻画各个分析对象所涉及的企业的各项数据，以及数据之间的关系；
Ø集成的：
由于各种原因，数据仓库的每个主题所对应的的数据源在原有的分散数据库中通常会有许多重复和不一致的地方，而且不同联机系统的数据都和不同的应用逻辑绑定，所以数据在进入数据仓库之前必须统一和综合，这一步是数据仓库建设中最关键、最复杂的一步；
Ø不可更新的：
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，主要供企业决策分析之用。
与面向应用的事务数据库需要对数据作频繁的插入、更新操作不同，数据仓库中的数据所涉及的操作主要是查询和新数据的导入，一般不进行修改操作；
Ø随时间不断变化的：
数据仓库系统必须不断捕捉OLTP数据库中变化的数据，并在经过统一集成后装载到数据仓库中。
同时，数据仓库中的数据也有存储期限，会随时间变化不断删去旧的数据，只是其数据时限远比操作型环境的要长，比如根据需要可保存10年内的历史数据；
2．2．3数据仓库的数据模型
数据模型是对现实世界的一种抽象，根据抽象程度的不同，也就形成了不同抽象层次上的数据模型。
类似于操作数据库的数据模型，数据仓库的数据模型也可分为三个层次：
概念模型，逻辑模型和物理模型。
概念模型是客观世界到计算机系统的一个中间层次，它最常用的表示方法是E－R法（实体－关系）。
目前数据仓库一般是建立在关系型数据库的基础之上，所以其概念模型与一般关系型数据库采用的概念模型相一致。
逻辑模型指数据的逻辑结构，如多维模型、关系模型、层次模型等。
数据仓库的逻辑模型描述了数据仓库的主题的逻辑实现，即每个主题对应的模式定义。
物理模型则是逻辑模型的具体实现，如物理存取方式、数据存储结构数据存放位置以及存储分配等。
在设计数据仓库的物理模型时，需要考虑一些提高性能的技术，如表分区，建立索引等。
目前对数据仓库模型的讨论大多集中在逻辑模型，其中最常用的是多维模型。
数据仓库的多维模型主要有如下几个概念：
Ø维：
维是人们观察数据的特定角度。
比如，企业常常关心不同销售数据随时间的变化情况，所以时间就是一个维；
Ø维的层次：
人们观察数据的某个特定角度还可以存在细节程度不同的多个描述方面，这就是维的层次。
一个维往往有多个层次，比如描述时间维时，可以从年份、季度、月份、天等不同层次来描述，那么年份、季度、月份和天就是时间维的层次；
Ø维成员：
维的一个取值称为该维的一个成员。
如果一个维是多层次的，那么该维的成员就是在不同层次取值的组合。
比如时间维有年份、月份和天这三个层次，那么分别在它们之上各取一个值组合起来就得到日期维的一个成员，即“某年某月某日”；
Ø度量：
度量描述了要分析的数值，比如销售额等；
2．2．4数据仓库的建设
企业级数据仓库的建设通常有两种途径：
一种是从建造某个部门特定的数据集市开始，逐步扩充数据仓库所包含的主题和范围，最后形成一个能够完全反映企业全貌的企业级数据仓库；另外一种则是从一开始就从企业的整体来考虑数据仓库的主题和实施。
前一种方法类似于软件工程中的“自底向上”的思想，投资少、周期短且易于见到成果，但由于该设计开始时是以特定的部门级主题为框架的，向其它的部门和主题扩充往往比较困难。
而最后一种方法恰恰相反，“自顶向下”，投资大、周期长。
在企业的实际应用中往往采用前一种方法。
“自底向上”地建设数据仓库，并不意味着不需要在设计阶段的长远规划。
采用逐步积累的方式建立数据仓库，最大的问题就是已有的框架无法把新的业务集成进来。
因此在设计阶段就必须充分考虑这一点。
例如，部门级的主题是否有助于形成企业级的主题，数据抽取模块是否能重用等。
数据仓库的长远规划，并不仅仅是技术部门的事情，应当把数据仓库的构建作为企业发展战略的一个组成部分。
在设计阶段需要不同部门的沟通和协调，技术框架和系统设计必须从整个企业的角度来考虑，即使刚开始实施的时候是面向某个部门的。
从这一点来看，建立一个企业级的数据仓库，主要的障碍不在于技术，而是不同部门之间的组织、协调问题。
2．2．5数据仓库的应用—OLAP
数据仓库作为决策支持系统的数据源，其构建工作只是基础，要想得到对决策有用的信息或对数据仓库中的数据作灵活、多角度的探察，还必须借助一些分析展示工具。
OLAP（在线分析处理）是基于数据仓库的分析展示方法之一，它建立在多维数据视图的基础上。
主要有两个特点，一是在线性，体现为用户请求的快速响应和交互式操作；二是多维分析，这也是OLAP技术的核心所在。
根据数据组织方式的不同，OLAP可分为两种：
基于多维数据库的MD-OLAP和基于关系数据库的R-OLAP。
前者响应速度快，执行效率高，但源于结构的局限，灵活性不高。
与之相比，后者由于建立在大量现有数据库的基础上，灵活性、可扩展性要高的多，并且支持大数据量和较多维数的能力也要强于前者。
因此，虽然在相应速度和执行效率上差一点，但仍然得到更广泛的应用。
OLAP对数据仓库中数据的操作是针对多维数据视图或称为立方体进行的。
其中比较典型的有：
切片、切块以及旋转等。
Ø切片指选定多维数组的一个二维子集；
Ø切块指选定多维数组的一个三维子集；
Ø旋转指改变一个立方体显示的维方向，使人们可以从不同的角度更加清晰直观地观察数据；
2．2．6国内数据仓库建设过程中的若干问题
数据仓库的建设工作在我国起步较晚，但是发展却极为迅速。
笔者在做论文之前，参与了多个电信部门数据仓库项目的设计和开发，学到了很多知识，同时也深深体会到国内的企业在数据仓库基础设施以及行政支持方面，与国外相比，仍然存在很多缺陷。
首先是基础设施，国内企业的不足主要表现在数据的积累少而不全，原有数据库系统设计比较混乱而且用户资料匮乏。
另外，由于数据仓库项目一般投资巨大，成本回收周期长，中小企业一般无力做这方面的尝试，即使是大型企业，也往往缺乏有长远战略眼光的领导，大部分企业的决策者，虽然也有建设数据仓库的实际需求，但却很难善始善终地坚持下去。
当然，数据仓库的建设在我国还处于起步和探索阶段，难免会出现一些问题。
随着国内外竞争的加剧，企业必然会愈来愈充分地认识到信息以及提高决策水平的重要性，因此，数据仓库在中国，必然会有很广阔的应用前景。
2．3元数据概述
2．3．1引言
元数据通常的定义是“关于数据的数据”，比如传统数据库中的数据字典就是一种元数据。
近年来，随着计算机技术应用的广泛化，元数据得到人们越来越多的关注，这是由多方面的需求决定的。
首先是管理数据的需求。
当系统数据量越来越大时，检索、使用这些数据的效率就会降低，通过存储关于系统和数据的内容、组织、特性等细节可以帮助有效地进行管理，从而提高效率。
第二是系统分布、互通和重用的要求。
目前信息系统一个共同的趋势就是信息共享，要实现异构系统中的信息共享，就需要描述数据语义、软件开发过程的元数据，而且这些元数据必须标准化，以充分实现分布、互通和重用。
第三是元数据重用、综合的需求。
目前，很少有单一工具能满足大型商业应用的需求，用户常常需要使用多种工具的组合，不同工具之间的数据交换的途径之一就是通过标准的元数据。
这一点正是本论文的设计基础。
2．3．2元数据的定义和分类
元数据，通常定义为描述数据的数据，旨在便利存取、管理、共享和处理大量结构化和/或非结构化的数据。
在过去的几年里，元数据的概念在现实中大量使用，有时为了支持信息检索，有时为了软件配置，有时为了不同系统之间的数据交互。
对于不同领域的专家，元数据有着不同的应用，但至少有两点是共同的：
元数据对数据进行描述；元数据的存在是为了更有效地使用数据。
对于元数据，从不同的角度来观察，可以划分为不同的类别。
1．按照与特定领域是否相关，元数据可以分类为：
Ø与特定领域相关的元数据：
描述特定领域内数据在此特定领域内的公共属性
Ø与特定领域无关的元数据：
描述所有数据的公共属性
Ø与模型相关的元数据：
描述信息和元信息建模过程的数据。
此类元数据又可分为两类：
●横向模型关联元数据：
综合现有的两个或多个信息模型，例如两个不同数据库之间的交互、从多个数据源中提取数据时，就需要这种横向模型元数据。
当不同的信息模型之间要进行互通时，需要模型各个层的关联描述，即横向模型关联元数据。
●纵向模型关联元数据：
模型信息层与元信息层之间的关联元数据。
不同的层可以采用不同的模型，上层是下层的结构描述，上下层之间的对应关联，即纵向模型关联元数据。
Ø其他元数据：
例如系统硬件、软件描述，系统配置描述等。
2．按照元数据的应用场合
Ø数据元数据，又叫做信息系统元数据。
信息系统使用元数据描述信息源，以按照用户需求检索、存取和理解源信息。
于是，元数据保证了在新的应用环境中使用信息，支持了整个信息结构的演进。
Ø过程元数据，又叫做软件结构元数据。
是关于应用系统的信息，它帮助用户查找、评估、存取和管理其数据。
大的软件结构中包括描述各个组件接口、功能和依赖关系的元数据，这些元数据保证了软件组件的灵活动态配置。
3．按照元数据的具体内容
Ø内容（CONTENT）：
识别、定义、描述基本数据元素，包括数据单元、合法值域等等。
Ø结构（STRUCTURE）：
在相关范围内定义数据元素的逻辑概念集合。
Ø表示（REPRESENTATION）：
描述每一个值域（多为技术相关的）的物理表示，以及数据元素集合的物理存储结构。
Ø文法（CONTEXT）：
提供基础数据的族系和属性评估，它包括了所有与基础数据的收集、处理和使用相关的信息。
2．3．3元数据的建模
在基于元数据的解决方案中，主要有两大方向，一是提供一个连续的整体框架，为元数据整个系统划定实现的层次结构，即元数据参考模型。
另一个方向，是进行元数据模型的描述，即元数据参考模型某一层中具体选定的模型。
以下是一个可扩展的四层元数据参考模型的例子，如图2.1所示。
图2-1元数据参考模型
其中，数据层与系统中操作的实例对应，即真实数据。
数据模型层对数据进行描述。
这一层还包括描述结构的元数据。
元模型层描述定义模型的形式方法。
在多数系统中，这一层就是最高层了。
它描述了用于表示低层信息，即数据模型层的概念。
这一层还包括描述形式方法及其规范的元数据，这些元数据可用于不同工具、方法、系统之间的互通。
最上一层，叫做元－元模型层，是模型的根层，描述定义形式方法的语言。
这一层的存在使得其他层表示一致，保证了低层模型之间的轻松互通。
2．3．4元数据的标准化
关于元数据的一般标准，从内容上，大致可分为两类。
一是元数据建模，是对将来元数据的组织进行规范定义，使得在元数据建模的标准制定之后产生的元数据都以一致的方式组织，从而保证元数据管理的一致性和简单性。
二是元数据交互，是对已有的元数据组织方式以及相互间交互格式加以规范定义，从而实现不同系统元数据的交互。
目前，主要有以下组织定义了元数据相关的规范。
1．对象管理组织OMG
OMG在1995年采用了MOF（MetaObjectFacility），并不断完善之。
1997年采用了UML，2000年，OMG又采用了CWM。
这三个标准：
UML、MOF和CWM形成了OMG建模和元数据管理、交换结构的基础，推动了元数据标准化的快速发展。
2．元数据联合会MDC
MDC建于1995年，目的是提供标准化的元数据交互。
MDC于1996年开发了MDIS（MetaDataInterchangeSpecification）并完成了MDC－OIM的技术评审，MDC－OIM基于微软的开放信息模型OIM，是一个独立于技术的、以厂商为核心的信息模型。
OIM是微软的元数据管理产品MicrosoftRepository的一部分。
由微软和其它20多家公司共同开发的，作为微软开放过程的一部分，经过了300多个公司的评审。
为了推动元数据标准化的发展，MDC和OMG在元数据标准的制定上协同工作。
1999年4月，MDC成为OMG的成员，而OMG也同时成为MDC的成员。
MDC中使用了OMG的UML，而MDC－OIM中的数据仓库部分被用来作为OMG的公共仓库元数据交互（CWMI：
CommonWarehouseMetadataInterchange）的设计参考。
在两个组织的技术力量的合作努力下，元数据标准将逐步一致化。
2．4体系结构概述
2．4．1引言
软件体系结构是软件工程研究中重要的领域之一，在软件开发过程中具有不可替代的作用。
本节将集中介绍软件体系结构的概念，几种主要的软件体系结构风格，为下一章介绍基于CWM的数据仓库系统体系结构打下基础。
2．4．2软件体系结构的概念
对于软件体系结构的研究始于DewaynePerry和AlexanderWolf，DavidGarlan和MaryShaw所做的工作。
从1992年开始，软件工程研究者提出了许多种关于软件体系结构的定义，直到1995年MaryShaw在软件体系结构国际会议上提出的定义方法可以说在某种程度上解决了软件体系结构命名中的混乱。
该会议的论文中主要观点如下：
Ø所有关于软件体系结构的结构观点都认为：
软件体系结构包括软件部件、部件间的联系以及系统构造、方式、约束、语义、分析、属性、基本原理和系统需求；
Ø框架模式观点与结构观点有一定的相似之处，但是更强调整个系统的连贯性结构，而不仅仅是系统组成。
框架结构经常针对特定领域和问题；
Ø动态模型强调系统的行为品质。
这里的“动态”可以指系统的总体配置的变化、建立或禁止预定义的通信和互联通道或计算的发展，如数据值的变化；
上述几种观点彼此并不相互排斥，也不表示软件体系结构基本问题之间的冲突。
它们只是总结了软件体系结构研究领域中的不同观点—软件体系结构的组成部分、整体、已经形成和正在形成的行为。
总的来说，这一总结形成了对软件体系结构的共同观点。
2．4．3几种主要的软件体系结构风格
可以从语言的种类、类型系统（systemoftypes）、理论（公理及推论的集合）等三个不同的途径来理解什么是风格[]。
在此只给出体系风格的一般理解：
体系结构风格是指在众多系统中所拥有的共同的结构和语义特性，指导如何将各个模块和子系统组成一个完整的系统。
目前公认的体系结构风格主要有：
Ø管道/过滤器（pipesandfilters）：
管道/过滤器风格中每一个组件有一组输入和输出，组件可以通过对输入数据流进行局部变换，采用渐进式计算方法，在未处理完所有输入数据以前就可以产生部分计算结果，并将其送到输出端口；
Ø数据抽象和面向对象的组织（dataabstractionandOO-organization）：
此风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作都封装在一个抽象数据类型或对象中；对象负责保持数据表示的完整性，对象的表示对其它对象是隐藏的。
这种结构中的部件就是对象，或者说是抽象数据类型的实例。
对象之间通过函数和过程调用发生相互作用；
Ø基于事件的隐式调用风格（event-based,implicitinvocation）：
组件不直接调用一个过程，而是触发或广播一个或多个事件。
系统中的其它组件中的过程在一个或多个事件中注册。
当该事件被激发时，系统本身就会调用所有已注册的、与该事件相关的过程；
Ø分层系统（layeredsystems）：
分层的系统组织成一个层次结构，每一层向其上层提供服务，并利用下层的服务。
在有的层次结构中，只有最外部的层次和一些经过精心选择的输出功能可以为系统外部访问，其它的内部层次完全被隐藏起来。
；
Ø仓库系统及知识库（repositories）：
仓库体系结构中有两种组件：
表示当前状态的中心数据结构和一组相互独立的中心数据处理组件。
不同的仓库系统与外部部件有不同的交互方式，控制方法的选择决定了仓库系统的类别。
比如执行哪个过程由输入数据流的事务处理类型决定，则该仓库系统就是传统的数据库系统；
Ø分布式处理中的多层结构：
分布式处理中的多层结构来源于分布式系统的“客户机/服务器”模型。
实际上，组件模型也是这种方式的一个扩展，比如CORBA，JAVABEAN等；
此外还有表格驱动的解释器、过程控制、各种专用领域软件体系结构等多种不同的结构和模型，在此不一一详述。
本论文中提出的基于CWM的数据仓库体系结构主要综合了面向对象组织、仓库系统和分布式处理（也就是其中的组件技术）等几种体系结构风格，并最大程度地满足数据仓库技术的特点，具体内容将在以后的章节中作详细阐述。
第三章：
CWM及相关理论概述
3．1引言
CWM的提出主要基于以下背景：
Ø从数据仓库开发者的角度：
单一工具很少能完全满足用户不断变化的需求，但同时又很难对各种产品进行集成；
Ø从数据仓库用户的角度：
面对的信息量太大，无法轻易找到自己真正需要的，而且把这些信息完整正确地表示出来也是个挑战；
Ø从数据仓库供应商的角度：
目前信息的共享还没有标准格式，元数据集成的代价太大；
现在有很多数据仓库产品，它们对元数据都有自己的定义和格式，因此创建、管理和共享元数据很耗时而且容易出错。
要解决上面这些问题，必须用标准的语言描述数据仓库元数据的结构和语义，并提供标准的元数据交换机制。
CWM就是满足这些条件的一个规范。
OMG在2000年发布了CWM规范，旨在推动数据仓库、智能商务和知识管理方面元数据的共享和交换。
和OMG合作提出CWM规范的公司有：
IBM，Unisys，NCR，HyperionSolutions，Oracle，UBSAG，GenesisDevelopment，DimensionEDI。
还有一些公司明确表示支持CWM，包括：
Deere&Company，Sun，HP，DataAccessTechnologies，InLineSoftware，Aonix，Hitachi,Ltd。
3．2相关理论概述
3．2．1引言
CWM主要基于以下三个工业标准：
ØUML（UnifiedModelingLanguage）：
统一建模语言，是OMG的一个建模标准；
ØMOF（MetaObjectFacility）：
元对象工具，是OMG关于元模型和元数据库的一个标准；
ØXMI（XMLMetadataInterchange），XML元数据交换，是OMG关于元数据交换的标准；
这三个标准是OMG元数据库体系结构的核心，
升级会员 