数据中心方案设计V2.0.docx

数据中心方案设计
Bychj
於胡WEB 51务篓
I IBMNF55M
in
SSL
KetSwift?,il2
座月科卷!7
报告服务娑
IBM X250
内都MB .龄嚣 IBMNF5500
系统拓扑图。

b、4. 5. 1设计目标
建立一个集中分散、异构、可扩充、可集成、有统一数据模型、有多种角度视 图的、可交换的和平安可靠的复合数据库系统。它将成为政府各种业务系统、 政府部门之间协同工作的数据中心，是政府门户的信息中心，多媒体、文档资 料和政策法规的存储中心和预测决策所需的数据仓库中心。
数据中心设计基础现状分析
对于一个完整的电子政务系统来说，统一的框架和相应的数据模式是十分重要4.访问平安性
由于数据库资源可能归属不同的单位，各业务数据系统有着各自的用户权限管理 模式，访问和平安管理很不方便，不能集中、统一管理。所以既要保证能访问异 构数据源中的数据，又要保障原有数据库的权限不被侵犯，实现对原有数据源访 问权限的隔离和控制，就需要设计数据中心统一的用户平安管理模式来解决此问 题。
值得注意的是，多个数据源之间的数据集成，并不是要将全部的数据进行集成， 那么如何定义要集成的范围，就构成了集成内容的限定问题。
针对异构数据源的整合和集成需求，可以采用数据仓库技术和数据抽取工具来实 现。另外，根据国务院17号文件精神，电子政务系统需要”整合信息资源，建立 人口、法人单位、空间地理和自然资源、宏观经济四个基础数据库”。为什么选 择这四个库而不选择别的数据库呢？这是基于基础性、公益性、战略性考虑的。 由于这四个数据库对别的数据库建设来说是一种公共产品，其它数据库需要通过 它的服务，在它的基础上不断开展，而产业库可以由中介机构来做。
4. 5. 2. 5数据元标准化很多信息的描述、定义、获取、表示形式由于缺乏统一、严格的标准，致使大量 的信息数据处于分散的、部门所有的和各自为政的状态，造成数据信息资源浪费, 不利于实现全社会的数据共享。为了提高政务信息的共享和集成分析，保证为政 府的管理决策和社会各阶层提供科学准确的信息，迫切需要开发出一种统一的、 以标准数据元形式的对政务信息的表示方法，以支持政务信息的共享和交换。
数据元(Data Element)是表示概念的一类数据，其特性可由支持信息交换的一 组数据元属性来表示。或者说数据元是一组可识别和可定义的数据基本单元。一 般来说数据元由数据元的名称、属性、表示三局部组成。
数据元是用一组属性描述其定义、标示、表达和允许值的一个数据单元。组成 数据元规范的基本属性分为标示类属性、定义类属性、关系类属性、表示类属性、 管理类属性。当然还可以根据需要增加扩展属性。数据元属性应依照一种标准方 式来注册和控制，以便数据元字典中的数据元在信息交换中保持一致性，并且能 够在不同的数据管理环境中进行数据元管理。数据元的基本属性主要有以下几 类：
S标示类，适用于数据元标示的属性。包括名称、标示符、版本、注册机构、同 义名称、相关环境。
S定义类，描述数据元语义方面的属性。包括定义。
S关系类，描述数据元之间相互关联和（或）数据元与分类模式、数据元概念、 对象、实体之间关联的属性包括分类模式、关键字、相关数据参照、关系类型。
S表示类，描述数据元表示方面的属性包括表示类别、表示形式、数据元值的数 据类型、数据元值的最大长度、数据元值的最小长度、表示格式、数据元允许值。 S管理类，描述数据元管理与控制方面的属性包括主管机构、注册状态、提交机 构、备注。
在这些基本属性中名称、定义、表示类别、表示形式、数据元值的数据类型、数 据元值的最大长度、数据元值的最小长度、数据元允许值是在描述数据元时是必 选的。
数据元表示是在数据处理和信息交换过程中数据元所采用的格式。如数据的长 度、数据的类型等都要给予说明，数据元的格式受数据元的属性及应用环境限定。 数据元可分为通用数据元和应用数据元。通用数据元是独立于任何具体的应用而 存在的数据元，其功能是为应用领域的数据元设计也就是为应用数据元的设计提 供一部通用数据元字典。应用数据元是在特定领域内使用的数据元集，例如在电 子政务领域的应用。从这个意义上来讲国家标准《数据元及交换格式、信息交换、 日期和时间表示法》就应该是一部通用数据元字典。 所谓数据元的标准化就是对数据元的总那么、定义、描述、分类、表示和注册等制 定统一的标准，并加以贯彻、实施的过程。在大量繁杂的政务信息中，哪些概念 可以作为我们定义数据元的基础，数据元概念的特性中哪一个可以继承下来作为 派生的通用数据元的特性，通用数据元特性中的又有哪些可以被应用数据元所继 承。以上这些问题都是数据元标准化过程所要解决的。
随着社会的开展，信息在社会各个行业中的作用不断提高，数据元标准也越来越 引起各个行业的重视。人们认识到只要对信息按共同约定的规那么进行统一组织、 分类与表示，使用同一的概念，并用相同的表示，就能做到共识，不致产生歧义。 这种简化的概念表述，提高了数据的准确性，有利于数据的共享、交换。
各政务系统所要处理的对象主要是数据，数据元标准所要起的作用就是用一个统 一的标准来描述、定义、规范这些系统所要处理的数据，为系统间的数据共享、 数据交换提供一个公用的信息接口。这个公用的信息接口的基础是政府部门的数 据环境建设，而数据环境建设的基础就是用数据元标准来描述数据源，建立电子 政务领域的应用数据元字典。这个公用的信息接口实际上就是我们对政务领域的 信息以数据元标准进行描述，形成一个大家都广泛接受，并在政务系统的开发过 程中遵守的规那么。在此基础上，各种系统之间的数据共享、数据交换成为可能。
数据元的标准化过程起到了一个针对要处理的数据源进行规范化的作用。通过这 个过程，规范了其中的概念、定义、以及知识的描述，形成了数据元词典，根据 这个词典一方面数据库的内容的规范有了依据，另一方面数据库的结构也得到了 规范。
4.5.2. 6模型设计基础
异类软件产品、应用程序、和数据库系统想要有效地互操作，它们必须要对 彼此间的信息结构有一个共同的理解。元数据是描述数据的数据，或是与数据有 关的信息，通常由信息的结构描述组成。元数据对不同厂商提供的异类软件系统 和产品之间的集成起着不可或缺的作用。传统的四层元数据体系结构图如下：
图4-9四层元数据体系结构1数据层（0层）是用户对象层，它表示的是"目标"数据，即我们所希望描述的 信息。比方在特定关系数据库中表示为特定表的实例。例如，公民基本信息表中 某个具体公民的信息，相当于公民基本信息表中的一条记录。
CitizenNo Name Age Address张三28武汉
李四45北京1模型层（1层）包含描述目标数据的数据模型。比方在特定关系数据库中表示 为特定的表、特定表的约束（主键、外键等）、特定表的结构等。例如，公民基 本信息表的结构，即该表中包含哪些列，以及各个列的数据类型等。
Table Column AttributeCitizen CitizenNo Numeric
Name StringAge Numeric
Address String1元模型（2层）包含了定义模型层的元数据，也就是表示Ml层元数据的抽象 语言。比方在关系数据库系统中，表不为特定数据库中表的定义、列的定义、主 键的定义和外键的定义等。相当于UML元模型定义的很多元素如类，操作，属性, 关联等等。
DataStore Component File Table
ColumnAttr
1元元模型层（3层）是由定义元数据结构和语法的描述组成，也可以说它是定 义各种元数据的抽象语言。
传统的元数据集成图4-10是数据中心中一个典型的信息供应链（ISO的例如。信息从其源头（即 原始数据的提供者）流出，经过一系列精炼过程，最终产生信息产品。这些产品 可能对于高层决策者来说具有重大的战略价值。
图4T0数据中心中的信息供应链以上每个软件产品和工具，在它们能在数据层上有效集成之前，必须在元数据层 上被集成。元数据集成是有效的数据集成的一个先决条件。然而，元数据的集成 是十分困难的，因为大多数的业务产品使用千差万别的格式存储元数据。具有不 同元数据的工具，往往是通过建立复杂的元数据桥来集成的。元数据桥是一种能 将一个产品的元数据转换成另一个产品所需元数据格式的一段软件。元数据桥的 构建是一项艰巨、耗费大的过程。这样的桥需要具有它要集成的每个产品的元数 据结构和接口的详细知识；关于不同模型间如何相互映射的知识也要融入桥中。 图4-11在信息供应链中增加一个元数据库
图4-11中使用了元数据库，它突出显示了定义对全局可获得的、和广泛被理解 的元数据是有必要的。元数据库是具有特定目的的数据库，它存储、控制所处环 境中，除它自身之外的所有相关的元数据组件，并对这些元数据组件是可获得的。 从图中我们可以看到，各种软件产品从中央元数据库中提取全局数据，而不是通 过与其它产品的点到点连接。这个存储库包含了定义信息供应链（可推广至数据 中心）的所有元数据的单一定义。这个定义基于一个针对存储库产品本身的元数 据模型。每个产品必须实现它自己的存储库访问层（即另一种形式的桥），该层 理解与特定存储库相关的元数据结构（例如接口和元模型），还知道如何将这些 与存储库相关的结构映射为与产品相关的元数据结构。这种类型的配置通常称为 星型元数据体系结构。
以上这个方法虽然减轻了建立很多点到点的桥的需要，但建立桥的问题仍然没有 完全消除。我们还是需要为每一个软件组件开发一个不同的访问层（该层可以由 产品厂商、存储库厂商或者第三方顾问开发），每一个访问层仍然是与某一特定 的存储库产品相关的。基于模型的元数据集成可以有效地解决这个问题。
基于模型的元数据集成用一种形式化语言（如UML）描述的模型（图4-12）可以被用来定义描述某种信 息结构或模式的元数据。这种形式化语言可以被翻译成相应的元数据定义，后者 能被用来创立信息结构本身的真正的实例。这些各式各样的形式化模型通常是平 台无关的，它们并不显示用来配置实际的信息结构的计算机平台的物理特性，因 为形式化建模语言（如UML以及其它各种数据建模语言）的定义通常是与平台无 关的。一个SQLDDL语句集可以被看成是一个与平台相关的模型，因为它们用一 个特定计算机平台的语言定义目标信息结构（例如，一个与SQL兼容的关系数据 库引擎）。将一个形式化模型转换为SQLDDL的假定的翻译过程，称为将与平台 无关的模型映射为与平台相关的模型，该映射是基于翻译过程所实现的某些形式 化映射的规那么集。
图4-12简单关系数据表模型由上我们可以得出三个非常重要的结论：
■ 一个信息结构的任何形式化模型都是定义该信息结构的元数据（元数据本质 上是它所描述的数据的一个形式化模型）■元数据，当用一个形式化的、与平台无关的模型表示时，可以独立于任何特 定的目标平台而存在。 ■元数据，当用一个形式化的、与平台无关的模型表示时，可以被翻译成假设干 与平台相关的模型中的任何一个，每一个代表一个不同的目标平台(当然要特定 适当的映射规那么以及实现这些规那么)。
元数据集成的一个可能的方法就是开发一个元数据的外部表示，它不依赖于任何 一个特定的产品和工具。这样一个表示是基于信息结构的形式化的、与平台无关 的模型，该模型用一种恰当的语言(如UML)描述。一个产品用这样一个形式化 模型作为它自己的元数据的基础，通过调用一个恰当的导入映射(import mapping)过程将这个形式化模型翻译成它自己的、与产品相关的元数据的实例。 类似的，一个产品可以通过一个将它自己的内部元数据翻译成一个与平台无关的 形式化模型的导出映射(export mapping)过程，将它所有的元数据显示给其它 产品。
这个方案在哪些方面优于前面提到元数据桥解决方案呢？元数据桥的主要问题 是每座桥要在两个与产品相关的模型之间进行映射，桥本质上需要将元数据从一 个产品的元模型规定的格式转换成另一个与产品相关的元模型所规定格式。现 在，元模型本身被外部化(externalized),与特定的实现平台无关；并且，产 品交换的元数据也基于这个公共的、外部的元模型，这样，在各自的实现模型间 翻译的问题也就不存在了。
这种元数据级的集成和互操作方法称为模型驱动的元数据体系结构。从根本上 说，它是由软件产品之间元数据的交换构成，这里的元数据定义是以形式化的、 与平台无关的模型来表示的。参与的软件产品和工具就定义整个域的公共元模型 达成一致，这样它们就能很方便的理解该元模型的任何实例(例如可能被交换的、 任何共享的元数据)。任何产品将这个共享的元数据映射为它自己内部的元数据 表式方式。这要求元模型在它的领域有一个完整的描述。
0MG的公共仓库元模型(Common Warehouse Metamodel) CWM就是一个基于模型的元数据集成的实现典范，它是一个完整描述数据仓库和业务分析领域的元模 型。作为一个元模型，CWM提供了构建元数据（例如模型或者元模型的实例）所 需的语义和语法。
CWM实际上是由假设干互不相同但又紧密相关的元模型构成。图4-13描述了 CWM 的总体结构，每一块代表CWM的一个元模型（或包）。由CWM某个包的得到的某 特定的模型（例如，某个元模型的实例）定义了描述对应功能域中数据的元数据。 例如，由关系元模型得到的某个模型是描述某些关系数据的实例（即产品数据表 的行集合）的元数据。
管 理 层Management数据仓库处理包Warehouse Process数据仓库操作包Warehouse Operation
分 析 层Analysis转换包Transformation联机分析、处理包OLAP数据挖掘 包Data Mining信息可视化包Informationvisualization业务命名规那么包 BusinessNomenclature资源层Resource对象包Object关系包Relational记录包Record多维包
Multidimensional XML 包 XML基础层Foundation业务信息包Business Informat ion数据类型包Data Type 表达式包Expressions键和索引包Keys and Indexes软件配置包Software Deployment 类型映射包 Type Mapping
对象模型层Object Model核心包Core行为包Behavioral联系包Relationships 实例包 Instance
图4. 13 CWM元模型层次图另外，基于模型的元数据集成体系结构要求有一种形式化语言，它能够以共享的、 与平台无关的模型来表示元数据。在CWM中，这种语言是UML （事实上是UML的 一个特定子集）。
首先，最低的一层是对象层，这个UML的子层用作CWM的基本元模型。对象层由4个元模型构成：核心元模型、行为元模型、关系元模型和实例元模型。其中的 关系元模型定义了模型元素之间的基本关系（如表和列之间的关联）。
基础层为更高层次提供CWM特定的服务。例如，数据类型元模型为定义基本数据 类型和构造数据类型提供基础结构；类型映射元模型定义的新类型使我们能够在 不同类型的系统之间建立映射模型（对于确保不同软件工具和平台之间的互操作 性很显然是必不可少的）；索引元模型同样以对象层的基本模型元素为基础，定 义了唯一键和外键的抽象概念，这对于建立关系数据库的模型至关重要，同时它 对面向记录的和多维的数据库同样重要。业务信息元模型定义的元素支持对基本 业务信息的建模。
资源层定义了各种数据资源的不同类型。该层含有的元模型包，允许描述面向对 象的数据库和应用系统、关系数据库管理系统、传统的面向记录的数据源（诸如 文件和记录模型数据库管理系统），以及由联线分析处理（OLAP）工具和XML 流建立的多维数据库。数据仓库和ISC （信息供应链）中需要管理的各种数据资 源，我们可以用CWM去定义表示各种类型的数据资源的元数据。
分析层中最重要的是转换元模型，这个元模型定义的模型元素用来指定数据资源 模型（资源层元模型的实例）之间源和目标的映射及转换，同时也指定数据资源 模型和各种分析模型之间源和目标的映射及转换。分析层还提供了数据挖掘、 业务术语、信息可视化元模型，它们支持对面向分析的元数据进行建模。数据挖 掘元模型定义的模型元素用来指定与各种数据挖掘工具相关的元数据，这些工具 经常用来从各种数据资源中抽取重要的模式和趋势；业务术语元模型定义的元数 据负责定义业务术语和概念并对其分类；可视化元模型定义的模型元素能够创立 与先进的报表工具和可视化工具相关的元数据。总而言之，这些元模型提供了建 立支持ISC （信息供应链）分析阶段的那些元数据所需的语义结构。
最后，管理层元模型支持数据仓库的日常操作和管理。数据仓库过程元模型使我 们能够对某些特定的数据仓库过程进行建模，例如ETL （数据提取、转换和装载） 过程；数据仓库操作元模型定义的模型元素用来创立定义特定的周期性的常规操 作的元数据，例如预定的事件及其相互的依赖关系。这些元数据对于ETL （数据 提取，转换和装载）工具，基于时间的排序工具以及其它仓库管理工具十分有用。 由上，CWM提供了基于模型的元数据集成体系结构所需的、用于描述问题域的语 义完整的公共元模型。如果构建数据中心用到的各种软件产品、工具和数据库产 品就CWM元模型达成一致，它们就都能理解CWM元模型的实例（模型或者元数据）, 元数据很容易在各局部之间进行交换和共享。一个关于数据中心的完整的模型， 从前端的数据资源，到转换和净化，再到终端用户分析，再到数据仓库管理，都 能用CWM的元模型来建立。
公共元模型，作为基于模型的元数据集成方法的核心，必须依照一定的形式化规 那么（一种抽象语言）来建立，以确保所有的软件都能用相同的、预期的方式对其 进行解释。对CWM而言，OMG的元对象设施MOF提供了所需的形式化规那么集。MOF 是为元模型规范定义公共抽象语言的一种OMG标准。MOF本质上是一种元一元模 型，或者说是元模型的模型（有时候称为本体（ontology））,它定义了对离散 系统建模要用到的元模型中的基本元素、语法和结构。M0F是UML和CWM的公共 模型，M0F使不同的元模型（代表不同领域）可以互操作。遵循M0F规范的应用 软件一点也不了解某个模型实例与特定领域相关的接口的情况，但是它仍然能够 通过使用反射接口的通用操作对该模型进行读取和更新的操作。
M0F的语义一般定义了支持模型创立、发现、转换和更新的某些元数据库服务。
特别的，M0F定义了模型生命周期的语义。模型生命周期定义了关于元数据的创 建和发布的有效操作，特别是结合到可视化建模的时候（例如，面向UML建模的 工具）。例如，新开发的元模型可以存储在M0F存储库中，并与其它以存在的元 模型结合起来使用。一个支持M0F的存储库除了负责元数据的创立和获取，还提 供了很多重要的元数据相关服务（例如持续化、版本控制、查询等）。
总而言之，M0F试图给出建立元对象模型的统一规范，其主要活动是描述元对象 的。电子政务的构建，正经历着由以技术为中心向以数据为中心的方向转变， 没有数据也就没有信息，也就没有政府网站及电子政府。数据中心在电子政务 系统中处于中心地位，具有公共数据（信息）库、模型库、文件交换站以及发 布信息的政府门户网站的功能，各数据源将自己的数据上传给数据中心，而各 部门根据自己的需要从数据中心获取数据，实施自己的应用。
按信息的应用属性，可将电子政务的数据类型分为空间数据、基础数据、政务 数据、专题数据和多媒体语音数据。整合政务信息资源，建设和改造政务数据 库，并建立人口、法人机构、空间地理和自然资源、以及宏观经济四个基础数 据库，将成为我国今后数年电子政务建设的关键。
由于我国政府各部门对信息化建设的深远意义认识不够，以及政务建设有一个 开展过程，造成了政府各部门、城市各行业信息化开展步调不一，从而使政务 信息化建设存在一些问题：
㈠、信息的共享、公开没有立发，信息采集、储存标准不统一，造成了互联互 通不畅，共享程度低。
㈡、信息共享机制尚未建立，各职能部门内部的信息相对封闭，产生了信息孤 岛效应，造成了信息资源的巨大浪费。
㈢、大局部单位业务应用系统还未形成一个内部资源共享、有效运行的整体， 需要在电子政务设计建设的过场中进行整合和改造。
㈣、网络建设各自为政，结构不合理，互连互通十分困难。
㈤、平安性存在隐患，人门还不放心在网上共享数据。
基于以上问题，需要在法律、技术、设备、管理等多方面加以考虑。
政府数据资源的建设，将有助于打破各级政府和部门对信息的垄断和封闭，能 够有效整合政务信息资源，强化对信息资源的不断开发、更新和维护；从长远 来说，这项工作的开展，将有助于推动政府信息资源对社会的开放，使之发挥 巨大的社会效益和经济效益。
和建立元对象模型，以便通过共享元数据，到达不同操作系统的、不同应用程序、 不同数据库平台等的互操作性的目的。
基于模型的元数据集成方法还要求有一个用于交换共享元数据实例的公共交换 格式，以及访问元数据的公共程序接口。CWM使用的XML互换编码XMI是定义如 何将支持MOF的元模型（如CWM）映射到XML的一个OMG标准。XMI精确定义了 在XML文档中如何用XML标签定义CWM元模型的实例。CWM元模型用来定义以XML DTD形式表示的XML标签集。然后CWM的元数据（例如CWM元模型的实例）在XML 文档中被序列化（serialized）。每个元数据的实例都作为XML元素的内容存储 起来，而这些元素是由适当的元模型标签限定的。
XMI解决了用基于标签的语言表示对象及其关联时面临的许多难题。另外，XMI 只是使用XML的一种方法，这意味着标签和标签描述的项（元素内容）可以打包 到同一个文件，使得应用程序能够很容易的理解文档内容。内容的交流既是自描 述也是异步的，这也是基于XML和XMI的交互在分布异构环境中为什么这么重要 的原因。
对CWM元数据资源的程序访问是由从支持MOF的元模型到各种编程语言的映射标 准来定义的。MOF规范特别定义了从任何支持MOF的元模型，例如CWM,到OMG 的IDL的映射。CWM规范包含完整的IDL定义。用选定的某种语言（例如Java 或C++）定义程序接口，必须使用适当目标语言编译器将CWM IDL编译为符合目 标语言语法的接口定义。
最后，我们认为一个基于模型的元数据集成解决方案还必须提供一些扩展模型的 标准方法，这对于定义CWM没有考虑到的、与产品高度相关的元数据而言是必不 可少的。
4. 5.2. 7数据库类型按数据库所服务的业务功能，可把数据库分成如下种类（下列图）

图4-14数据库类型
四大基础数据库：包括人口数据库、法人单位数据库、空间地理和自然资源数据 库、以及宏观经济数据库。
主题操作数据库：存有经常使用的业务数据，可存在数据中心，但大量的是以目 录形式存储，而其数据总是存在各局委办，这样既保证了数据的动态更新的一致 性，也保证了数据的平安性。但设计业务数据时，要在响应速度，冗余，一致性 上作出折中。
办公数据：记录政府系统办公的数据。并联审批，用户使用状态日志以及进行平 台管理，电子政务系统维护管理的数据。该项数据根据相关平台工具和业务系统 进行定义和维护其结构模型遵循关系数据库的设计原那么。
文本资料数据库：资料主要包括国家的政策和指令，本省市的资料和条文等信息, 是各级工作人员办理各种业务的依据，也是学习国家和省市政策和法规的途径。 在国家政府机构，这样的资料显得额外重要，离开了它，就不能保证各项工作正 常进行的方向。目前机关的相关资料以纸面的居多，一些比拟少的在库中存放的 资料也是以扫描方式进入，因为各单位资源的共享问题，并没有做到资料的互通, 查找资料的过程可能就是一个费时费力的过程。资料库主要有以下一些特点：
1.以文档形式存储资料的共享性要求
ii. 涉密资料的平安存储支持智能和模糊查询
基于上述特点，在全省（市）建设一个统一的资料库。这样做得好处在于便于统 一管理，尽可能提供资料共享。
多媒体资料数据库：它包括各种政务图像、视频，用于宣传报道和视频点播。 元数据库：元数据库的建设目标是建立全省（市）统一的政务数据字典和数据中 心的元数据模型。该数据库由两局部组成：
s政务数据字典：包括政务叙词表，信息分类、代码和指标体系表。主要用于各 职能部门的信息联接与交换。
S数据中心元数据：数据中心中所包含的所有元数据（比方使用公共仓库元模型 CWM所定义的所有元数据）。具体可包括数据模型定义、数据抽取规那么、映射转 换规那么、主题定义、资料分类和维度定义、决策模型定义等等。
数据仓库：数据仓库中存储面向分析的按主题分类的多层次汇总数据。数据仓库 的建设目标是为上层的决策支持系统提供充分的数据支持。数据仓库中的数据按 照统一的数据模型进行组织和分类。各项业务数据经过提取、清洗和转换后按照 数据仓库的统一数据模型装载入数据仓库中。数据仓库中保存各项数据的较长时 间的历史数据和在多种层次上的汇总数据。
在数据仓库基础上结合以商业智能工具和联机分析工具可实现多种深层次数据 分析应用，例如：预测报警、多维数据分析、数据挖掘、专题分析和决策支持等。
4. 5. 3数据中心对平台的要求数据中心是电子政务系统的核心之一，它支持门户与各种业务数据的紧密耦合, 支持各业务系统的运行，并为查询、预测提供支持。其相互关系描述如下 由上图可见，中间件服务器通过数据中心的接口可使用已有的JDBC、ODBC,而 其它局部都存在接口定义，数据库设计工具和维护工具。
① 数据中心同门户的接口定义，应在门户支撑平台中给予支持。
② 数据中心同各业务系统的关系定义，要在数据交换中心平台中给以支持：
1各局委办业务数据库同操作数据库中的映射关系的定义。
1业务系统数据模型的定义和面向主题的操作数据库的建立和维护。
③ 数据交换中心所需要的各类数据的定义和维护，该项功能在数据交换中心平 台中提供支持。
④ 多媒体数据库（通过内、外门户接入）由视频会议系统和公务服务等系统提 供数据的存取接口。
⑤ 资料数据库由相应的应用系统提供存取接口。
4. 5.4数据库的平安设计局部存储到数据中心的加密数据由平安平台给以支持。
① 数据的备份由数据库提供商提供。
② 数据的远程备份由灾难备份设计考虑。
③ 数据库本身的平安由DBMS提供。
4. 5.5数据库的运行环境设计采用目前国际上的大型数据库系统，该数据库系统应能管理结构化数据，多媒体 数据，对象数据和空间数据，具有完备的、平安可靠的备份能力，比方ORACLE 9i, DB2 等。
数据库的运行环境建议采用LINUX、UNIX,建议采用双机均衡负载计算机系统以 及采用磁盘阵列。详细情况见有关设备选型和经费预算局部
4.522资源分类数据中心是电子政务数据资源建设的基础，它是各类信息采集、加工和整合的平 台。数据中心资源大致可分为三大类，一是元数据库、政务叙词表和分类体系与 代码表，二是GIS平台，三是服务资源。
（1）元数据库考虑到今后各职能部门的信息联接与交换，电子政务元数据库必需严格定义并向 全网开放，否那么将造成今后机构间数据交换无法实现。具体内容请参见4. 3.3 和4. 3. 4节。
（2）政务叙词表电子政务与电子商务的一个显著不同是前者是为主题所驱动的，而后者是交易驱 动的。在主题驱动系统中，规范主题词（叙词）库是至关重要的，因为它是库内 资源组织、管理以及库际资源交换的基础。规范政务叙词表即是对所有入库资源 进行科学标引、描述与分类，通过叙词严格的语义内涵和位属关联，建立所有资 源在主题层的映射关系，对各类信息产品和服务过程起到基准性、规范性、参照 性、结构性和工具性的支持作用，以实现全库资源的有序化，并提升其可用性。 如"Internet-有”因特网”、"互联网”、"网际网路”等名称，仅以其中一个名称进 行全文检索、关键词检索等并不能保证文献的查全率。而严格定义的叙词表会在 这些表达间建立关联，同时还会给出相关同位词，如"Internet"的同位词有 "Intranet”（即”内部网"、”企业网”、"内联网”、"内特网”等），以及"Extranet"
（"外部网”、"外联网”、"外特网"）等，上位词有”计算机网络"、”网络”以及" 无线互联网”、”移动互联网”等下位词。
资源库中所有的文献资源只有在标引并与叙词库建立映射后，才能使用户在主题 查询时能进退自如。政务资源叙词表大致由如下分词表组成：机关公文主题词表、 宏观经济主题词表、行业主题词表、社会事业主题词表以及科学与技术主题词表 等。
（3）信息分类、代码和指标体系表分类与代码对于库中信息的组织管理和服务是极其重要的，同时，随着国际经济 一体化进程的加快，与国际标准信息分类体系的兼容问题也日益重要。这些分类 代码体系涉及到国民经济行业分类代码、联合国及各国海关协调制度（HS）分类 与代码、北美工业标准分类代码（NAICS体系）、全国行政区划分类与代码（扩 展到乡镇级）、全国工农业产品/商品分类代码、各主导行业信息分类与代码以 及文件格式及其结构描述规范代码等。
此外，各种指标体系与格式化文件对于政府的宏观管理和决策分析也是极其重要 的。此类数据常以表格形式出现，并在各级机关部门中流转生成，它们之间的交 换也以表格形式进行。所以，字段统一、代码统一、格式统一、定义统一的表格 是主管部门从事经济分析、数据再处理和决策支持的前提。
（4）GIS平台几乎所有的经济、产业与社会信息都与地理空间信息相关，近年来GIS已融入 IT业的主体，并成为各类数据综合可视化的基础平台。与专业数据结合的各类 专题电子地图更是各地政府进行区域经济与社会开展规划、开展招商引资、比拟 本地与周边地区竞争优势不可缺少的工具。同时，政务数据库的资源只有在与 GIS整合后，才能产生质变，真正为政府宏观调控起到决策支持的作用。
（5）服务资源电子政务系统的服务对象有4类：政府机构、公务员、公民、企业单位。服务资 源即指直接为这4类客户提供服务的信息。其中包括政府系统办公数据、各类业 务数据、国家政策指令，各种政务图像、视频，还包括电子商务、工商、税务、 金融、海关、法律、卫生、医疗、教育、职业等基础设施服务信息。
数据特性
(1) 静态数据与动态数据电子政务数据中心必须满足电子政务平台进行数据交换的需要，同时还必须满足 在平台上建立的各业务系统进行综合业务处理的要求，并为门户系统提供各种静 态和动态的数据、信息。所谓静态信息是指对电子政务的运行中不经常变化，供 各个业务系统查询、处理的数据或信息：政策、法规、元数据、资料库、各种多 媒体数据等，它们会随着时间而逐步增大。所谓动态数据是指随着运行而增加、 修改的数据：并联审批中文件流转状态数据，反映企业、个人所处状态的数据， 国民经济运行状态的数据等。动态数据同各个局委办的信息密切相关，但又是面 向主题的，如社会保险这个主题，实际上同保险、工资、税务和银行密切相关； 个人信用使用主题，它的数据与银行、税务、个人消费、个人收入密切相关。
(2) 微观应用与宏观应用的数据共享
政府业务中的信息应用有微观的应用与宏观应用之分，微观数据的应用主要 是针对个案的事务处理。比方工商登记，业务申报，税务处理，个人劳保、补助、 婚丧、驾照、护照、医疗等等。微观事务处理的业务既包含对社会市场秩序的监 管，又包含对企业、对公众的服务。这类事务处理的工作主要是由基层的一线人 员来承当的，其信息共享的特点是：由来自不同方面的信息要围绕一个主体来整 合起来，比方将医疗卫生、计划生育、社会保障等信息依据人的身份证号码整合 起来，这就构成了以人为主题的数据库。同样还可以建立以法人为主题的数据库 来整合法人的信息咨询。实际上，微观信息共享的核心是将不同来源的数据资源, 整合为主题数据库。
微观数据的收集经常是由不同的主管部门来做的，如公安、税务、卫生部门、 社保部门、工商部门等。要让这些部门提供的数据依据主题(主体)整合起来并不 是容易的，首先必须要解决这些部门主观上的抵抗，这是一个政务改革与利益处 置的问题。在技术上，要求有非常标准化的唯一的主体编码，并要开放数据结构, 这样才有利于可共享的主题数据库的诞生。进一步，我们应当尽量通过一表式的 调查、登记，将尽可能多的数据集中地通过一次调查来完成，从而能尽量地节约 本钱。由于管理的角度不一样，我们很难通过一个主题数据来集中所有的共享数 据，也许，我们还是需要几个系统来分别处理各自的业务，但是，经过数据整合 设计之后的系统，肯定能够降低数据提供的总本钱，并为微观业务提供更有效的 服务。
宏观应用的数据共享，主要是为领导层服务，希望通过共享数据资源来提高政府 的决策水平。然而如何从纷繁庞杂的数据中挖掘出有用的信息进行预测分析，如 何更好地管理和决策呢？我们可以选择数据仓库(DataWarehouse)作为决策支 持系统的核心。数据仓库是支持管理决策过程的、面向主题的、集成的、不可更 新的且随时间不断变化的数据集合。利用数据仓库，对源数据经过提取、转换、 加载形成统一的数据格式，再利用数据挖掘和OLAP分析工具为决策者提供所需 的信息。
数据仓库的使用者主要是机关单位、市委领导等决策相关人员，为他们提供在业 务办公基础数据库的基础上各种层次汇总的数据，帮助他们进行各种决策支持。 对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决 策，面向分析型数据处理，它不同于现有的业务型数据库；其次，数据仓库是对 多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而 且存放在数据仓库中的数据一般不再修改。数据仓库主要有三方面的作用：首先, 数据仓库提供了标准的报表和图表功能，其中的数据来源于不同的多个事务处理 系统，因此，数据仓库的报表和图表是关于整个集成信息的报表和图表；其次， 数据仓库支持多维分析，多维分析是通过把一个实体的多项重要的属性定义为多 个维度，使得用户能方便地汇总数据集，简化了数据的分析处理逻辑，并能对不 同维度值的数据进行比拟，而维度那么表示了对信息的不同理解角度。应用多维分 析可以在一个查询中对不同阶段的数据进行纵向或横向比拟，这在决策过程中非 常有用；第三，数据仓库是数据挖掘技术的关键基础，数据挖掘技术要在已有数 据中识别数据的模式，以帮助用户理解现有的信息，并在已有信息的基础上，对 未来的状况作出预测。
虽然数据仓库也有面向主题的定义，但这些主题是较长时间的，具有战略定义的 主题。
由以上分析可见，根据数据库的操作性、数据的语义，应该把数据库分为三大类: 一般意义的数据库即关系数据库、文本数据库（DB）；供综合业务系统和门户使 用的面向主题的数据库（OSD）；数据仓库，它是供内门户决策者使用的数据库 （DW）。DB数据主要分布在各局委办，数据中心只有少量的；所以它是集中分 布的。面向主题的操作数据库（OSD）是电子政务数据中心的主体，它是DB按主 题映射的数据库；数据仓库建立在DB和OSD之上的主题数据库。
这三种数据库的关系描述如下：
面向主题的操作数据库是数据库体系的中间层，一方面包含全局一致的、细节的、 当前或接近当前的数据；另一方面它是面向主题的，集成的数据环境，且数据量 小，供各个综合业务系统查询处理使用，主要用作辅助完成日常决策的数据分析 处理。所以这种数据库的主要特征是：
1系统功能表4-1
设计目标处理类型主要功能需求特征 中层辅助决策与综合查询日常管理和控制的决策，事务处理与决策分析并存联 机事务处理联机分析综合全局中层1数据特征
表4-2内容来源组织稳定性综合性特征
当前或接近当前的数据政府系统内部主