大数据中心方案设计V0

1、实用标准文档数据中心方案设计文案大全Bychja、S11NHE-王如时刃!:制CTUiterLIGDLTTli人概曲鬲變虬IBM iff 55CiM一邑耳菇器:SVNM8WSSL Mi*8 ,.r, 0 降NtLw20D 亿 kJ抵珮财的歸碇B廉弄器笊 JUJX2 弭 屮（?MHF550&系统拓扑图Qb、4.5.1 设计目标建立一个集中分散、异构、可扩充、可集成、有统一数据模型、有多种角度视 图的、可交换的和安全可靠的复合数据库系统。它将成为政府各种业务系统、 政府部门之间协同工作的数据中心，是政府门户的信息中心，多媒体、文档资 料和政策法规的存储中心和预测决策所需的数据仓库中心。4.5.2

2、数据中心设计基础4.5.2.1现状分析对于一个完整的电子政务系统来说，统一的框架和相应的数据模式是十分重要 的。电子政务的构建，正经历着由以技术为中心向以数据为中心的方向转变， 没有数据也就没有信息，也就没有政府网站及电子政府。数据中心在电子政务 系统中处于中心地位，具有公共数据（信息）库、模型库、文件交换站以及发 布信息的政府门户网站的功能，各数据源将自己的数据上传给数据中心，而各 部门根据自己的需要从数据中心获取数据，实施自己的应用。按信息的应用属性，可将电子政务的数据类型分为空间数据、基础数据、政务 数据、专题数据和多媒体语音数据。整合政务信息资源，建设和改造政务数据 库，并建立人口、法

3、人机构、空间地理和自然资源、以及宏观经济四个基础数 据库，将成为我国今后数年电子政务建设的关键。由于我国政府各部门对信息化建设的深远意义认识不够，以及政务建设有一个 发展过程，造成了政府各部门、城市各行业信息化发展步调不一，从而使政务 信息化建设存在一些问题：、信息的共享、公开没有立发，信息采集、储存标准不统一，造成了互联互 通不畅，共享程度低。、信息共享机制尚未建立，各职能部门内部的信息相对封闭，产生了信息孤 岛效应，造成了信息资源的巨大浪费。、大部分单位业务应用系统还未形成一个内部资源共享、有效运行的整体， 需要在电子政务设计建设的过场中进行整合和改造。、网络建设各自为政，结构不合理，互连

4、互通十分困难。、安全性存在隐患，人门还不放心在网上共享数据。基于以上问题，需要在法律、技术、设备、管理等多方面加以考虑。政府数据资源的建设，将有助于打破各级政府和部门对信息的垄断和封闭，能 够有效整合政务信息资源，强化对信息资源的不断开发、更新和维护；从长远 来说，这项工作的开展，将有助于推动政府信息资源对社会的开放，使之发挥 巨大的社会效益和经济效益。4.522资源分类数据中心是电子政务数据资源建设的基础，它是各类信息采集、加工和整合的平 台。数据中心资源大致可分为三大类， 一是元数据库、政务叙词表和分类体系与 代码表，二是GIS平台，三是服务资源。（1）元数据库考虑到今后各职能部门的信息联

5、接与交换， 电子政务元数据库必需严格定义并向 全网开放，否则将造成今后机构间数据交换无法实现。具体内容请参见 433 和4.3.4节。（2）政务叙词表电子政务与电子商务的一个显著不同是前者是为主题所驱动的，而后者是交易驱动的。在主题驱动系统中，规范主题词（叙词）库是至关重要的，因为它是库内 资源组织、管理以及库际资源交换的基础。规范政务叙词表即是对所有入库资源 进行科学标引、描述与分类，通过叙词严格的语义内涵和位属关联， 建立所有资 源在主题层的映射关系，对各类信息产品和服务过程起到基准性、 规范性、参照 性、结构性和工具性的支持作用，以实现全库资源的有序化，并提升其可用性。如Internet

6、有因特网、互联网、网际网路等名称，仅以其中一个名称进 行全文检索、关键词检索等并不能保证文献的查全率。而严格定义的叙词表会在这些表达间建立关联，同时还会给出相关同位词，如In ternet的同位词有Intranet（即内部网、企业网、内联网、内特网等），以及Extranet（外部网、外联网、外特网）等，上位词有计算机网络、网络以及 无线互联网、移动互联网等下位词。资源库中所有的文献资源只有在标引并与叙词库建立映射后，才能使用户在主题查询时能进退自如。政务资源叙词表大致由如下分词表组成：机关公文主题词表、 宏观经济主题词表、行业主题词表、社会事业主题词表以及科学与技术主题词表 等。（3）信息分类

7、、代码和指标体系表分类与代码对于库中信息的组织管理和服务是极其重要的，同时，随着国际经济一体化进程的加快，与国际标准信息分类体系的兼容问题也日益重要。这些分类代码体系涉及到国民经济行业分类代码、联合国及各国海关协调制度（HS分类 与代码、北美工业标准分类代码（NAICS体系）、全国行政区划分类与代码（扩 展到乡镇级）、全国工农业产品/商品分类代码、各主导行业信息分类与代码以 及文件格式及其结构描述规范代码等。此外，各种指标体系与格式化文件对于政府的宏观管理和决策分析也是极其重要的。此类数据常以表格形式出现，并在各级机关部门中流转生成，它们之间的交 换也以表格形式进行。所以，字段统一、代码统一、

8、格式统一、定义统一的表格 是主管部门从事经济分析、数据再处理和决策支持的前提。（4）GIS平台几乎所有的经济、产业与社会信息都与地理空间信息相关，近年来GIS已融入IT业的主体，并成为各类数据综合可视化的基础平台。与专业数据结合的各类 专题电子地图更是各地政府进行区域经济与社会发展规划、开展招商引资、比较本地与周边地区竞争优势不可缺少的工具。同时，政务数据库的资源只有在与GIS整合后，才能产生质变，真正为政府宏观调控起到决策支持的作用。（5）服务资源电子政务系统的服务对象有4类：政府机构、公务员、公民、企业单位。服务资 源即指直接为这4类客户提供服务的信息。其中包括政府系统办公数据、各类业 务

9、数据、国家政策指令，各种政务图像、视频，还包括电子商务、工商、税务、金融、海关、法律、卫生、医疗、教育、职业等基础设施服务信息。4.523数据特性（1）静态数据与动态数据电子政务数据中心必须满足电子政务平台进行数据交换的需要，同时还必须满足在平台上建立的各业务系统进行综合业务处理的要求，并为门户系统提供各种静态和动态的数据、信息。所谓静态信息是指对电子政务的运行中不经常变化，供 各个业务系统查询、处理的数据或信息：政策、法规、元数据、资料库、各种多 媒体数据等，它们会随着时间而逐步增大。所谓动态数据是指随着运行而增加、 修改的数据：并联审批中文件流转状态数据，反映企业、个人所处状态的数据， 国

10、民经济运行状态的数据等。动态数据同各个局委办的信息密切相关， 但又是面 向主题的，如社会保险这个主题，实际上同保险、工资、税务和银行密切相关； 个人信用使用主题，它的数据与银行、税务、个人消费、个人收入密切相关。（2）微观应用与宏观应用的数据共享政府业务中的信息应用有微观的应用与宏观应用之分， 微观数据的应用主要 是针对个案的事务处理。比如工商登记，业务申报，税务处理，个人劳保、补助、 婚丧、驾照、护照、医疗等等。微观事务处理的业务既包含对社会市场秩序的监 管，又包含对企业、对公众的服务。这类事务处理的工作主要是由基层的一线人 员来承担的，其信息共享的特点是：由来自不同方面的信息要围绕一个主体

11、来整 合起来，比如将医疗卫生、计划生育、社会保障等信息依据人的身份证号码整合 起来，这就构成了以人为主题的数据库。同样还可以建立以法人为主题的数据库 来整合法人的信息咨询。实际上，微观信息共享的核心是将不同来源的数据资源， 整合为主题数据库。微观数据的收集经常是由不同的主管部门来做的， 如公安、税务、卫生部门、 社保部门、工商部门等。要让这些部门收集的数据依据主题(主体)整合起来并不 是容易的，首先必须要解决这些部门主观上的抵制， 这是一个政务改革与利益处 置的问题。在技术上，要求有非常标准化的唯一的主体编码， 并要开放数据结构， 这样才有利于可共享的主题数据库的诞生。 进一步，我们应当尽量通

12、过一表式的 调查、登记，将尽可能多的数据集中地通过一次调查来完成，从而能尽量地节约成本。由于管理的角度不一样，我们很难通过一个主题数据来集中所有的共享数 据，也许，我们还是需要几个系统来分别处理各自的业务，但是，经过数据整合 设计之后的系统，肯定能够降低数据收集的总成本，并为微观业务提供更有效的 服务。宏观应用的数据共享，主要是为领导层服务，希望通过共享数据资源来提高政府 的决策水平。然而如何从纷繁庞杂的数据中挖掘出有用的信息进行预测分析，如何更好地管理和决策呢？我们可以选择数据仓库(Data Warehouse)作为决策支 持系统的核心。数据仓库是支持管理决策过程的、面向主题的、集成的、不可

13、更 新的且随时间不断变化的数据集合。利用数据仓库，对源数据经过提取、转换、 加载形成统一的数据格式，再利用数据挖掘和 OLAP分析工具为决策者提供所需 的信息。数据仓库的使用者主要是机关单位、市委领导等决策相关人员，为他们提供在业 务办公基础数据库的基础上各种层次汇总的数据，帮助他们进行各种决策支持。 对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于现有的业务型数据库；其次，数据仓库是对 多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而 且存放在数据仓库中的数据一般不再修改。 数据仓库主要有三方面的作用：首先， 数据仓

14、库提供了标准的报表和图表功能，其中的数据来源于不同的多个事务处理系统，因此，数据仓库的报表和图表是关于整个集成信息的报表和图表；其次， 数据仓库支持多维分析，多维分析是通过把一个实体的多项重要的属性定义为多 个维度，使得用户能方便地汇总数据集，简化了数据的分析处理逻辑，并能对不 同维度值的数据进行比较，而维度则表示了对信息的不同理解角度。 应用多维分 析可以在一个查询中对不同阶段的数据进行纵向或横向比较，这在决策过程中非常有用；第三，数据仓库是数据挖掘技术的关键基础， 数据挖掘技术要在已有数 据中识别数据的模式，以帮助用户理解现有的信息，并在已有信息的基础上，对 未来的状况作出预测。虽然数据仓

15、库也有面向主题的定义， 但这些主题是较长时间的，具有战略定义的 主题。由以上分析可见，根据数据库的操作性、数据的语义，应该把数据库分为三大类： 一般意义的数据库即关系数据库、文本数据库（DB ;供综合业务系统和门户使 用的面向主题的数据库（OSD ；数据仓库，它是供内门户决策者使用的数据库（DW。DB数据主要分布在各局委办，数据中心只有少量的；所以它是集中分布的。面向主题的操作数据库（OSD是电子政务数据中心的主体，它是 DB按主 题映射的数据库；数据仓库建立在 DB和OSD之上的主题数据库。这三种数据库的关系描述如下：面向主题的操作数据库是数据库体系的中间层， 一方面包含全局一致的、细节的、

16、 当前或接近当前的数据；另一方面它是面向主题的，集成的数据环境，且数据量 小，供各个综合业务系统查询处理使用，主要用作辅助完成日常决策的数据分析 处理。所以这种数据库的主要特征是：l系统功能表4-1设计目标处理类型主要功能需求特征中层辅助决策与综合查询 日常管理和控制的决策，事务处理与决策分析并存 联 机事务处理联机分析综合全局中层l数据特征表4-2内容来源组织稳定性综合性特征当前或接近当前的数据 政府系统内部 主题 较稳定允许更新 某一主题的综合 和详细数据全域一致的数据环境l数据库的主要用户该数据库是反映某一主题的数据，其用户是政府工作人员和就某一主题进行综合 查询的人员。（3）集中分布式

17、数据管理当我们的微观数据规模非常大的时候， 依靠集中的数据处理会是很不方便的， 我 们可以将数据库建设分散化，由本地来进行数据收集、整理和数据库更新。然而， 数据的使用却不能是地区化的，数据的查询是全国范围的。这样，共享数据的管 理与共享数据的使用范围就会不一致。 为了解决这一问题，可以考虑使用标准的 目录数据库，统一结构的目录数据库将允许多层次分布式的建立自己的子系统， 而又能自然形成一个整体，以支持统一的数据库查询，这对于建立大规模的主题 数据库体系是非常有效的。数据就近的管理与联合统一的使用不仅会大大提高数 据共享的范围，而且会有效地降低数据维护管理的成本。（4）数据源的异构性数据源异构

18、性主要表现在两方面：s系统异构，数据源所依赖的应用系统、数据库管理系统乃至操作系统之间的不 同构成了系统异构。s模式异构，数据源在存储模式上的不同。一般的存储模式包括关系模式、 对象 模式、对象关系模式和文档嵌套模式等几种，其中关系模式为主流存储模式。需 要注意的是，即便是同一类存储模式，它们的模式结构可能也存在着差异。 例如 Oracle所采用的数据类型与SQLServer所采用的数据类型并不是完全一致的。4.524 数据整合和集成需求异构数据源的数据整合和集成的目的是为综合应用系统提供集成的、统一的、安全的、快捷的信息查询、数据挖掘和决策支持服务。为了满足这个需求条件，整 合、集成后的数据

19、必须保证一定的集成性、完整性、一致性和访问安全性。1. 集成性各种原先孤立的业务信息系统数据经过整合、集成后，应该达到查询一个综合信 息不必再到各个业务系统进行分别查询和人工处理，只要在数据中心中就可以直接访问到，即整合、集成后的数据是各异构业务数据的有机集成和关联存储（整合、发掘出各业务数据间的内在关联关系），而不是简单、孤立的堆放在一个数 据库系统里。2. 完整性包括数据完整性和约束完整性两方面。s数据完整性是指完整提取数据本身，一般来说，这一点较容易达到。s约束完整性，约束是指数据与数据之间的关联关系， 是唯一表征数据间逻辑的 特征。保证约束的完整性是良好的数据发布和交换的前提，可以方便

20、数据处理过 程，提高效率。3. 一致性不同业务信息资源之间存在着语义上的区别。 这些语义上的不同会引起各种不完 整甚至错误信息的产生，从简单的名字语义冲突（不同的名字代表相同的概念）， 到复杂的结构语义冲突（不同的模型表达同样的信息）。语义冲突会带来数据集 成结果的冗余，干扰数据处理、发布和交换。整合、集成后的数据应该根据一定的数据转换模式和业务规则进行统一数据结构和字段语义编码转换。4. 访问安全性由于数据库资源可能归属不同的单位，各业务数据系统有着各自的用户权限管理 模式，访问和安全管理很不方便，不能集中、统一管理。所以既要保证能访问异 构数据源中的数据，又要保障原有数据库的权限不被侵犯，

21、 实现对原有数据源访 问权限的隔离和控制，就需要设计数据中心统一的用户安全管理模式来解决此问 题。值得注意的是，多个数据源之间的数据集成，并不是要将全部的数据进行集成， 那么如何定义要集成的范围，就构成了集成内容的限定问题。针对异构数据源的整合和集成需求，可以采用数据仓库技术和数据抽取工具来实 现。另外，根据国务院17号文件精神，电子政务系统需要整合信息资源，建立 人口、法人单位、空间地理和自然资源、宏观经济四个基础数据库。为什么选择这四个库而不选择别的数据库呢？这是基于基础性、公益性、战略性考虑的。由于这四个数据库对别的数据库建设来说是一种公共产品，其它数据库需要通过它的服务，在它的基础上不

22、断发展，而产业库可以由中介机构来做。4.525 数据元标准化很多信息的描述、定义、获取、表示形式由于缺乏统一、严格的标准，致使大量 的信息数据处于分散的、部门所有的和各自为政的状态，造成数据信息资源浪费， 不利于实现全社会的数据共享。为了提高政务信息的共享和集成分析，保证为政 府的管理决策和社会各阶层提供科学准确的信息，迫切需要开发出一种统一的、 以标准数据元形式的对政务信息的表示方法，以支持政务信息的共享和交换。数据元(Data Element)是表示概念的一类数据，其特性可由支持信息交换的一 组数据元属性来表示。或者说数据元是一组可识别和可定义的数据基本单元。一般来说数据元由数据元的名称、

23、属性、表示三部分组成。数据元是用一组属性描述其定义、标示、表达和允许值的一个数据单元。组成数据元规范的基本属性分为标示类属性、定义类属性、关系类属性、表示类属性、管理类属性。当然还可以根据需要增加扩展属性。 数据元属性应依照一种标准方 式来注册和控制，以便数据元字典中的数据元在信息交换中保持一致性，并且能够在不同的数据管理环境中进行数据元管理。数据元的基本属性主要有以下几 类：s标示类，适用于数据元标示的属性。包括名称、标示符、版本、注册机构、同 义名称、相关环境。s定义类，描述数据元语义方面的属性。包括定义。s关系类，描述数据元之间相互关联和（或）数据元与分类模式、数据元概念、 对象、实体之

24、间关联的属性包括分类模式、关键字、相关数据参照、关系类型。s表示类，描述数据元表示方面的属性包括表示类别、表示形式、数据元值的数 据类型、数据元值的最大长度、数据元值的最小长度、表示格式、数据元允许值。 s管理类，描述数据元管理与控制方面的属性包括主管机构、注册状态、提交机 构、备注。在这些基本属性中名称、定义、表示类别、表示形式、数据元值的数据类型、数 据元值的最大长度、数据元值的最小长度、数据元允许值是在描述数据元时是必 选的。数据元表示是在数据处理和信息交换过程中数据元所采用的格式。如数据的长度、数据的类型等都要给予说明，数据元的格式受数据元的属性及应用环境限定。 数据元可分为通用数据元

25、和应用数据元。通用数据元是独立于任何具体的应用而 存在的数据元，其功能是为应用领域的数据元设计也就是为应用数据元的设计提 供一部通用数据元字典。应用数据元是在特定领域内使用的数据元集， 例如在电 子政务领域的应用。从这个意义上来讲国家标准数据元及交换格式、信息交换、 日期和时间表示法就应该是一部通用数据元字典。所谓数据元的标准化就是对数据元的总则、定义、描述、分类、表示和注册等制 定统一的标准，并加以贯彻、实施的过程。在大量繁杂的政务信息中，哪些概念 可以作为我们定义数据元的基础，数据元概念的特性中哪一个可以继承下来作为 派生的通用数据元的特性，通用数据元特性中的又有哪些可以被应用数据元所继

26、承。以上这些问题都是数据元标准化过程所要解决的。随着社会的发展，信息在社会各个行业中的作用不断提高， 数据元标准也越来越 引起各个行业的重视。人们认识到只要对信息按共同约定的规则进行统一组织、 分类与表示，使用同一的概念，并用相同的表示，就能做到共识，不致产生歧义。 这种简化的概念表述，提高了数据的准确性，有利于数据的共享、交换。各政务系统所要处理的对象主要是数据，数据元标准所要起的作用就是用一个统 一的标准来描述、定义、规范这些系统所要处理的数据，为系统间的数据共享、 数据交换提供一个公用的信息接口。这个公用的信息接口的基础是政府部门的数 据环境建设，而数据环境建设的基础就是用数据元标准来描

27、述数据源，建立电子政务领域的应用数据元字典。这个公用的信息接口实际上就是我们对政务领域的 信息以数据元标准进行描述，形成一个大家都广泛接受，并在政务系统的开发过 程中遵守的规则。在此基础上，各种系统之间的数据共享、数据交换成为可能。数据元的标准化过程起到了一个针对要处理的数据源进行规范化的作用。通过这个过程，规范了其中的概念、定义、以及知识的描述，形成了数据元词典，根据 这个词典一方面数据库的内容的规范有了依据， 另一方面数据库的结构也得到了 规范。4.5.2 . 6模型设计基础异类软件产品、应用程序、和数据库系统想要有效地互操作，它们必须要对 彼此间的信息结构有一个共同的理解。 元数据是描述

28、数据的数据，或是与数据有 关的信息，通常由信息的结构描述组成。元数据对不同厂商提供的异类软件系统和产品之间的集成起着不可或缺的作用。传统的四层元数据体系结构图如下：图4-9四层元数据体系结构l数据层（0层）是用户对象层，它表示的是目标数据，即我们所希望描述的 信息。比如在特定关系数据库中表示为特定表的实例。 例如，公民基本信息表中 某个具体公民的信息，相当于公民基本信息表中的一条记录。Citize nNo Name Age Address张三28武汉李四45北京l模型层（1层）包含描述目标数据的数据模型。比如在特定关系数据库中表示 为特定的表、特定表的约束（主键、外键等）、特定表的结构等。例如

29、，公民基 本信息表的结构，即该表中包含哪些列，以及各个列的数据类型等。Table Colum n AttributeCitizen CitizenNo NumericName Stri ngAge NumericAddress Stringl元模型（2层）包含了定义模型层的元数据，也就是表示M1层元数据的抽象语言。比如在关系数据库系统中，表示为特定数据库中表的定义、列的定义、主 键的定义和外键的定义等。相当于UML元模型定义的很多元素如类，操作，属性, 关联等等。DataStore Component File TableColu mnAttrl元元模型层（3层）是由定义元数据结构和语法的描述

30、组成，也可以说它是定 义各种兀数据的抽象语言。传统的元数据集成图4-10是数据中心中一个典型的信息供应链（ISC）的示例。信息从其源头（即 原始数据的提供者）流出，经过一系列精炼过程，最终产生信息产品。这些产品 可能对于高层决策者来说具有重大的战略价值。图4-10数据中心中的信息供应链以上每个软件产品和工具，在它们能在数据层上有效集成之前，必须在元数据层 上被集成。元数据集成是有效的数据集成的一个先决条件。然而，元数据的集成是十分困难的，因为大多数的业务产品使用千差万别的格式存储元数据。具有不同元数据的工具，往往是通过建立复杂的元数据桥来集成的。 元数据桥是一种能 将一个产品的元数据转换成另一

31、个产品所需元数据格式的一段软件。元数据桥的构建是一项艰巨、耗费大的过程。这样的桥需要具有它要集成的每个产品的元数 据结构和接口的详细知识；关于不同模型间如何相互映射的知识也要融入桥中。图4-11在信息供应链中增加一个元数据库图4-11中使用了元数据库，它突出显示了定义对全局可获得的、和广泛被理解的元数据是有必要的。元数据库是具有特定目的的数据库， 它存储、控制所处环 境中，除它自身之外的所有相关的元数据组件，并对这些元数据组件是可获得的。从图中我们可以看到，各种软件产品从中央元数据库中提取全局数据，而不是通过与其它产品的点到点连接。这个存储库包含了定义信息供应链（可推广至数据 中心）的所有元数

32、据的单一定义。这个定义基于一个针对存储库产品本身的元数 据模型。每个产品必须实现它自己的存储库访问层（即另一种形式的桥），该层 理解与特定存储库相关的元数据结构 （例如接口和元模型），还知道如何将这些 与存储库相关的结构映射为与产品相关的元数据结构。这种类型的配置通常称为 星型元数据体系结构。以上这个方法虽然减轻了建立很多点到点的桥的需要， 但建立桥的问题仍然没有 完全消除。我们还是需要为每一个软件组件开发一个不同的访问层 （该层可以由 产品厂商、存储库厂商或者第三方顾问开发），每一个访问层仍然是与某一特定 的存储库产品相关的。基于模型的元数据集成可以有效地解决这个问题。基于模型的元数据集成用

33、一种形式化语言（如UML描述的模型（图4-12 ）可以被用来定义描述某种信 息结构或模式的元数据。这种形式化语言可以被翻译成相应的元数据定义， 后者 能被用来创建信息结构本身的真正的实例。这些各式各样的形式化模型通常是平 台无关的，它们并不显示用来配置实际的信息结构的计算机平台的物理特性，因为形式化建模语言（如UML以及其它各种数据建模语言）的定义通常是与平台无 关的。一个SQLDDL语句集可以被看成是一个与平台相关的模型，因为它们用一 个特定计算机平台的语言定义目标信息结构 （例如，一个与SQL兼容的关系数据 库引擎）。将一个形式化模型转换为 SQLDDL的假定的翻译过程，称为将与平台 无关

34、的模型映射为与平台相关的模型，该映射是基于翻译过程所实现的某些形式 化映射的规则集。图4-12简单关系数据表模型由上我们可以得出三个非常重要的结论： 一个信息结构的任何形式化模型都是定义该信息结构的元数据（元数据本质 上是它所描述的数据的一个形式化模型）元数据，当用一个形式化的、与平台无关的模型表示时，可以独立于任何特定的目标平台而存在。元数据，当用一个形式化的、与平台无关的模型表示时，可以被翻译成若干 与平台相关的模型中的任何一个，每一个代表一个不同的目标平台(当然要特定 适当的映射规则以及实现这些规则)。元数据集成的一个可能的方法就是开发一个元数据的外部表示，它不依赖于任何一个特定的产品和

35、工具。这样一个表示是基于信息结构的形式化的、与平台无关的模型，该模型用一种恰当的语言(如 UML描述。一个产品用这样一个形式化 模型作为它自己的元数据的基础，通过调用一个恰当的导入映射(importmapping)过程将这个形式化模型翻译成它自己的、与产品相关的元数据的实例。类似的，一个产品可以通过一个将它自己的内部元数据翻译成一个与平台无关的 形式化模型的导出映射(export mapping)过程，将它所有的元数据显示给其它 产品。这个方案在哪些方面优于前面提到元数据桥解决方案呢？元数据桥的主要问题是每座桥要在两个与产品相关的模型之间进行映射，桥本质上需要将元数据从一个产品的元模型规定的格

36、式转换成另一个与产品相关的元模型所规定格式。现 在，元模型本身被外部化(externalized )，与特定的实现平台无关；并且，产 品交换的元数据也基于这个公共的、外部的元模型，这样，在各自的实现模型间翻译的问题也就不存在了。这种元数据级的集成和互操作方法称为模型驱动的元数据体系结构。从根本上 说，它是由软件产品之间元数据的交换构成，这里的元数据定义是以形式化的、 与平台无关的模型来表示的。参与的软件产品和工具就定义整个域的公共元模型 达成一致，这样它们就能很方便的理解该元模型的任何实例(例如可能被交换的、 任何共享的元数据)。任何产品将这个共享的元数据映射为它自己内部的元数据 表式方式。这

37、要求元模型在它的领域有一个完整的描述。OMG勺公共仓库元模型(Com mon Warehouse Metamodgl CW就是一个基于模型的元数据集成的实现典范，它是一个完整描述数据仓库和业务分析领域的元模 型。作为一个元模型，cwM提供了构建元数据（例如模型或者元模型的实例）所 需的语义和语法。CW实际上是由若干互不相同但又紧密相关的元模型构成。图4-13描述了 CWM的总体结构，每一块代表CW啲一个元模型（或包）。由CW某个包的得到的某 特定的模型（例如，某个元模型的实例）定义了描述对应功能域中数据的元数据。 例如，由关系元模型得到的某个模型是描述某些关系数据的实例（即产品数据表的行集合）

38、的元数据。管理层Management数据仓库处理包 Warehouse Process数据仓库操作包Warehouse Operati on分析层Analysis 转换包Transformation 联机分析、处理包 OLAP数据挖掘 包Data Mining 信息可视化包InformationVisualization业务命名规则包Busi nessNome nclature资源层Resource对象包 Object关系包Relational 记录包Record多维包Multidimensional XML 包 XML基础层Foundation业务信息包Businesslnformation

39、数据类型包Data Type表达式包Expressions 键和索引包 Keys and Indexes 软件配置包Software Deployment 类型映射包 Type Mapping对象模型层 Object Model核心包Core行为包Behavioral 联系包Relati on ships 实例包 In sta nee图4.13 CWM元模型层次图另外，基于模型的元数据集成体系结构要求有一种形式化语言，它能够以共享的、与平台无关的模型来表示元数据。在 CWM3，这种语言是UML（事实上是UML的 一个特定子集）。首先，最低的一层是对象层，这个UML的子层用作CW啲基本元模型。对

40、象层由 4个元模型构成：核心元模型、行为元模型、关系元模型和实例元模型。其中的 关系元模型定义了模型元素之间的基本关系（如表和列之间的关联）。基础层为更高层次提供CW特定的服务。例如，数据类型元模型为定义基本数据 类型和构造数据类型提供基础结构；类型映射元模型定义的新类型使我们能够在 不同类型的系统之间建立映射模型（对于确保不同软件工具和平台之间的互操作 性很显然是必不可少的）；索引元模型同样以对象层的基本模型元素为基础，定义了唯一键和外键的抽象概念，这对于建立关系数据库的模型至关重要， 同时它 对面向记录的和多维的数据库同样重要。业务信息元模型定义的元素支持对基本 业务信息的建模。资源层定义

41、了各种数据资源的不同类型。 该层含有的元模型包，允许描述面向对 象的数据库和应用系统、关系数据库管理系统、传统的面向记录的数据源（诸如 文件和记录模型数据库管理系统），以及由联线分析处理（OLAP工具和XML流建立的多维数据库。数据仓库和ISC （信息供应链）中需要管理的各种数据资 源，我们可以用CW去定义表示各种类型的数据资源的元数据。分析层中最重要的是转换元模型，这个元模型定义的模型元素用来指定数据资源 模型（资源层元模型的实例）之间源和目标的映射及转换，同时也指定数据资源 模型和各种分析模型之间源和目标的映射及转换。分析层还提供了数据挖掘、业务术语、信息可视化元模型，它们支持对面向分析的

42、元数据进行建模。数据挖 掘元模型定义的模型元素用来指定与各种数据挖掘工具相关的元数据，这些工具经常用来从各种数据资源中抽取重要的模式和趋势；业务术语元模型定义的元数据负责定义业务术语和概念并对其分类；可视化元模型定义的模型元素能够创建 与先进的报表工具和可视化工具相关的元数据。总而言之，这些元模型提供了建 立支持ISC （信息供应链）分析阶段的那些元数据所需的语义结构。最后，管理层元模型支持数据仓库的日常操作和管理。 数据仓库过程元模型使我 们能够对某些特定的数据仓库过程进行建模， 例如ETL（数据提取、转换和装载） 过程；数据仓库操作元模型定义的模型元素用来创建定义特定的周期性的常规操作的元

43、数据，例如预定的事件及其相互的依赖关系。这些元数据对于ETL（数据提取，转换和装载）工具，基于时间的排序工具以及其它仓库管理工具十分有用。 由上，CW提供了基于模型的元数据集成体系结构所需的、用于描述问题域的语 义完整的公共元模型。如果构建数据中心用到的各种软件产品、 工具和数据库产 品就CWI元模型达成一致，它们就都能理解CW元模型的实例（模型或者元数据）， 元数据很容易在各部分之间进行交换和共享。一个关于数据中心的完整的模型， 从前端的数据资源，到转换和净化，再到终端用户分析，再到数据仓库管理，都 能用CW啲元模型来建立。公共元模型，作为基于模型的元数据集成方法的核心， 必须依照一定的形式

44、化规 则（一种抽象语言）来建立，以确保所有的软件都能用相同的、预期的方式对其 进行解释。对CWM而言，OMG勺元对象设施MOf提供了所需的形式化规则集。MOF 是为元模型规范定义公共抽象语言的一种 0M（标准。MOF本质上是一种元-元模 型，或者说是元模型的模型（有时候称为本体（ontology ），它定义了对离散 系统建模要用到的元模型中的基本元素、语法和结构。MOF是 UML和CW啲公共模型，M0使不同的元模型（代表不同领域）可以互操作。遵循 MOF规范的应用 软件一点也不了解某个模型实例与特定领域相关的接口的情况，但是它仍然能够通过使用反射接口的通用操作对该模型进行读取和更新的操作。MO

45、F 勺语义一般定义了支持模型创建、发现、转换和更新的某些元数据库服务。 特别的，MOF定义了模型生命周期的语义。模型生命周期定义了关于元数据的创 建和发布的有效操作，特别是结合到可视化建模的时候 （例如，面向UML建模的 工具）。例如，新开发的元模型可以存储在 MO存储库中，并与其它以存在的元 模型结合起来使用。一个支持MOF勺存储库除了负责元数据的创建和获取， 还提 供了很多重要的元数据相关服务（例如持续化、版本控制、查询等）。总而言之，MOF式图给出建立元对象模型的统一规范，其主要活动是描述元对象和建立元对象模型，以便通过共享元数据，达到不同操作系统的、不同应用程序、 不同数据库平台等的互

46、操作性的目的。基于模型的元数据集成方法还要求有一个用于交换共享元数据实例的公共交换格式，以及访问元数据的公共程序接口。 CW使用的XML互换编码XMI是定义如 何将支持MOFI勺元模型（如CWM映射到XML勺一个OMGS准。XMI精确定义了 在XML文档中如何用XML标签定义CWI元模型的实例。CW元模型用来定义以XML DTD形式表示的XMLL标签集。然后CW啲元数据（例如CWI元模型的实例）在XML 文档中被序列化（serialized ）。每个元数据的实例都作为XML元素的内容存储 起来，而这些元素是由适当的元模型标签限定的。XMI解决了用基于标签的语言表示对象及其关联时面临的许多难题。

47、另外，XMI只是使用XML啲一种方法，这意味着标签和标签描述的项（元素内容）可以打包 到同一个文件，使得应用程序能够很容易的理解文档内容。内容的交流既是自描述也是异步的，这也是基于XML和XMI的交互在分布异构环境中为什么这么重要 的原因。对CW元数据资源的程序访问是由从支持 M0啲元模型到各种编程语言的映射标 准来定义的。M0规范特别定义了从任何支持 M0啲元模型，例如CWM到OMG 的IDL的映射。CW规范包含完整的IDL定义。用选定的某种语言（例如 Java 或C+定义程序接口，必须使用适当目标语言编译器将CWMDL编译为符合目标语言语法的接口定义。最后，我们认为一个基于模型的元数据集成解决方案还必须提供一些扩展模型的 标准方法，这对于定义CWM没有考虑到的、与产品高度相关的元数据而言是必不 可少的。4.5.2 . 7数据库类型按数据库所服务的业务功能，可把数据库分成如下种类（下图仅供参考）数中心据库各局 委办 业务 系统 数据库数据仓库元数基础数据库数局数据库局数据库办公 数据多媒体资 料数据库政务数据字典空间地理人口数据库主题操作数据库数据文本资料 数据库宏观经济J 二一局数据库C法人单位数曲库I图4-14数据库类型四大基础数据库：包括人口数据库、法人单位数据库、空间地理和自然资源数据 库、以及宏观经济数据库。主题操作数据库：存有经常使用的业务数据