数据中心专项方案设计V.doc

数据中心方案设计
Bychj
a、

系统拓扑图

b、
4.5.1 设计目标
建立一个集中分散、异构、可扩充、可集成、有统一数据模型、有多个角度视图、可交换和安全可靠复合数据库系统。它将成为政府多种业务系统、政府部门之间协同工作数据中心，是政府门户信息中心，多媒体、文档资料和政策法规存放中心和估计决议所需数据仓库中心。
4.5.2 数据中心设计基础
4.5.2.1 现实状况分析
对于一个完整电子政务系统来说，统一框架和对应数据模式是十分关键。电子政务构建，正经历着由以技术为中心向以数据为中心方向转变，没有数据也就没有信息，也就没有政府网站及电子政府。数据中心在电子政务系统中处于中心地位，含有公共数据（信息）库、模型库、文件交换站和公布信息政府门户网站功效，各数据源将自己数据上传给数据中心，而各部门依据自己需要从数据中心获取数据，实施自己应用。
按信息应用属性，可将电子政务数据类型分为空间数据、基础数据、政务数据、专题数据和多媒体语音数据。整合政务信息资源，建设和改造政务数据库，并建立人口、法人机构、空间地理和自然资源、和宏观经济四个基础数据库，将成为中国以后数年电子政务建设关键。
因为中国政府各部门对信息化建设深远意义认识不够，和政务建设有一个发展过程，造成了政府各部门、城市各行业信息化发展步调不一，从而使政务信息化建设存在部分问题：
㈠、信息共享、公开没有立发，信息采集、储存标准不统一，造成了互联互通不畅，共享程度低。
㈡、信息共享机制还未建立，各职能部门内部信息相对封闭，产生了信息孤岛效应，造成了信息资源巨大浪费。
㈢、大部分单位业务应用系统还未形成一个内部资源共享、有效运行整体，需要在电子政务设计建设过场中进行整合和改造。
㈣、网络建设各自为政，结构不合理，互连互通十分困难。
㈤、安全性存在隐患，人门还不放心在网上共享数据。
基于以上问题，需要在法律、技术、设备、管理等多方面加以考虑。
政府数据资源建设，将有利于打破各级政府和部门对信息垄断和封闭，能够有效整合政务信息资源，强化对信息资源不停开发、更新和维护；从长远来说，这项工作开展，将有利于推进政府信息资源对社会开放，使之发挥巨大社会效益和经济效益。 　　
4.5.2.2 资源分类
数据中心是电子政务数据资源建设基础，它是各类信息采集、加工和整合平台。数据中心资源大致可分为三大类，一是元数据库、政务叙词表和分类体系和代码表，二是GIS平台，三是服务资源。
（1） 元数据库
考虑到以后各职能部门信息联接和交换，电子政务元数据库必需严格定义并向全网开放，不然将造成以后机构间数据交换无法实现。具体内容请参见4.3.3和4.3.4节。
（2） 政务叙词表
电子政务和电子商务一个显著不一样是前者是为专题所驱动，以后者是交易驱动。在专题驱动系统中，规范专题词（叙词）库是至关关键，因为它是库内资源组织、管理和库际资源交换基础。规范政务叙词表即是对全部入库资源进行科学标引、描述和分类，经过叙词严格语义内涵和位属关联，建立全部资源在专题层映射关系，对各类信息产品和服务过程起到基准性、规范性、参考性、结构性和工具性支持作用，以实现全库资源有序化，并提升其可用性。
如"Internet"有"因特网"、"互联网"、"网际网路"等名称，仅以其中一个名称进行全文检索、关键词检索等并不能确保文件查全率。而严格定义叙词表会在这些表示间建立关联，同时还会给出相关同位词，如"Internet"同位词有"Intranet"（即"内部网"、"企业网"、"内联网"、"内特网"等），和"Extranet"（"外部网"、"外联网"、"外特网"）等，上位词有"计算机网络"、"网络"和"无线互联网"、"移动互联网"等下位词。
资源库中全部文件资源只有在标引并和叙词库建立映射后，才能使用户在专题查询时能进退自如。政务资源叙词表大致由以下分词表组成：机关公文专题词表、宏观经济专题词表、行业专题词表、社会事业专题词表和科学和技术专题词表等。
（3）信息分类、代码和指标体系表
分类和代码对于库中信息组织管理和服务是极其关键，同时，伴随国际经济一体化进程加紧，和国际标准信息分类体系兼容问题也日益关键。这些分类代码体系包含到国民经济行业分类代码、联合国及各国海关协调制度（HS）分类和代码、北美工业标准分类代码（NAICS体系）、全国行政区划分类和代码（扩展到乡镇级）、全国工农业产品/商品分类代码、各主导行业信息分类和代码和文件格式及其结构描述规范代码等。
另外，多种指标体系和格式化文件对于政府宏观管理和决议分析也是极其关键。这类数据常以表格形式出现，并在各级机关部门中流转生成，它们之间交换也以表格形式进行。所以，字段统一、代码统一、格式统一、定义统一表格是主管部门从事经济分析、数据再处理和决议支持前提。
（4）GIS平台
几乎全部经济、产业和社会信息全部和地理空间信息相关，多年来GIS已融入IT业主体，并成为各类数据综合可视化基础平台。和专业数据结合各类专题电子地图更是各地政府进行区域经济和社会发展计划、开展招商引资、比较当地和周围地域竞争优势不可缺乏工具。同时，政务数据库资源只有在和GIS整合后，才能产生质变，真正为政府宏观调控起到决议支持作用。
（5）服务资源
电子政务系统服务对象有4类：政府机构、公务员、公民、企业单位。服务资源即指直接为这4类用户提供服务信息。其中包含政府系统办公数据、各类业务数据、国家政策指令，多种政务图像、视频，还包含电子商务、工商、税务、金融、海关、法律、卫生、医疗、教育、职业等基础设施服务信息。
4.5.2.3 数据特征
（1）静态数据和动态数据
电子政务数据中心必需满足电子政务平台进行数据交换需要，同时还必需满足在平台上建立各业务系统进行综合业务处理要求，并为门户系统提供多种静态和动态数据、信息。所谓静态信息是指对电子政务运行中不常常改变，供各个业务系统查询、处理数据或信息：政策、法规、元数据、资料库、多种多媒体数据等，它们会伴随时间而逐步增大。所谓动态数据是指伴随运行而增加、修改数据：并联审批汉字件流转状态数据，反应企业、个人所处状态数据，国民经济运行状态数据等。动态数据同各个局委办信息亲密相关，但又是面向专题，如社会保险这个专题，实际上同保险、工资、税务和银行亲密相关；个人信用使用专题，它数据和银行、税务、个人消费、个人收入亲密相关。
（2）微观应用和宏观应用数据共享
　　政府业务中信息应用有微观应用和宏观应用之分，微观数据应用关键是针对个案事务处理。比如工商登记，业务申报，税务处理，个人劳保、补助、婚丧、驾照、护照、医疗等等。微观事务处理业务既包含对社会市场秩序监管，又包含对企业、对公众服务。这类事务处理工作关键是由基层一线人员来负担，其信息共享特点是：由来自不一样方面信息要围绕一个主体来整合起来，比如将医疗卫生、计划生育、社会保障等信息依据人身份证号码整合起来，这就组成了以人为专题数据库。一样还能够建立以法人为专题数据库来整正当人信息咨询。实际上，微观信息共享关键是将不一样起源数据资源，整合为专题数据库。
　　微观数据搜集常常是由不一样主管部门来做，如公安、税务、卫生部门、社保部门、工商部门等。要让这些部门搜集数据依据专题(主体)整合起来并不是轻易，首先必需要处理这些部门主观上抵制，这是一个政务改革和利益处理问题。在技术上，要求有很标准化唯一主体编码，并要开放数据结构，这么才有利于可共享专题数据库诞生。深入，我们应该尽可能经过一表式调查、登记，将尽可能多数据集中地经过一次调查来完成，从而能尽可能地节省成本。因为管理角度不一样，我们极难经过一个专题数据来集中全部共享数据，可能，我们还是需要多个系统来分别处理各自业务，不过，经过数据整合设计以后系统，肯定能够降低数据搜集总成本，并为微观业务提供更有效服务。
宏观应用数据共享，关键是为领导层服务，期望经过共享数据资源来提升政府决议水平。然而怎样从纷繁庞杂数据中挖掘出有用信息进行估计分析，怎样愈加好地管理和决议呢？我们能够选择数据仓库（Data Warehouse）作为决议支持系统关键。数据仓库是支持管理决议过程、面向专题、集成、不可更新且随时间不停改变数据集合。利用数据仓库，对源数据经过提取、转换、加载形成统一数据格式，再利用数据挖掘和OLAP分析工具为决议者提供所需信息。
数据仓库使用者关键是机关单位、市委领导等决议相关人员，为她们提供在业务办公基础数据库基础上多种层次汇总数据，帮助她们进行多种决议支持。对于数据仓库概念我们能够从两个层次给予了解，首先，数据仓库用于支持决议，面向分析型数据处理，它不一样于现有业务型数据库；其次，数据仓库是对多个异构数据源有效集成，集成后根据专题进行了重组，并包含历史数据，而且存放在数据仓库中数据通常不再修改。数据仓库关键有三方面作用：首先，数据仓库提供了标准报表和图表功效，其中数据起源于不一样多个事务处理系统，所以，数据仓库报表和图表是相关整个集成信息报表和图表；其次，数据仓库支持多维分析，多维分析是经过把一个实体多项关键属性定义为多个维度，使得用户能方便地汇总数据集，简化了数据分析处理逻辑，并能对不一样维度值数据进行比较，而维度则表示了对信息不一样了解角度。应用多维分析能够在一个查询中对不一样阶段数据进行纵向或横向比较，这在决议过程中很有用；第三，数据仓库是数据挖掘技术关键基础，数据挖掘技术要在已经有数据中识别数据模式，以帮助用户了解现有信息，并在已经有信息基础上，对未来情况作出估计。
即使数据仓库也有面向专题定义，但这些专题是较长时间，含有战略定义专题。
由以上分析可见，依据数据库操作性、数据语义，应该把数据库分为三大类：通常意义数据库即关系数据库、文本数据库（DB）；供综合业务系统和门户使用面向专题数据库（OSD）；数据仓库，它是供内门户决议者使用数据库（DW）。DB数据关键分布在各局委办，数据中心只有少许；所以它是集中分布。面向专题操作数据库（OSD）是电子政务数据中心主体，它是DB按专题映射数据库；数据仓库建立在DB和OSD之上专题数据库。
这三种数据库关系描述以下：
面向专题操作数据库是数据库体系中间层，首先包含全局一致、细节、目前或靠近目前数据；其次它是面向专题，集成数据环境，且数据量小，供各个综合业务系统查询处理使用，关键用作辅助完成日常决议数据分析处理。所以这种数据库关键特征是：
l 系统功效
表4-1
设计目标 处理类型 关键功效 需求特征
中层辅助决议和综合查询 日常管理和控制决议，事务处理和决议分析并存 联机事务处理联机分析 综合全局中层
l 数据特征
表4-2
内容 起源 组织 稳定性 综合性 特征
目前或靠近目前数据 政府系统内部 专题 较稳定许可更新 某一专题综合和具体数据 全域一致数据环境
l 数据库关键用户
该数据库是反应某一专题数据，其用户是政府工作人员和就某一专题进行综合查询人员。
（3）集中分布式数据管理
当我们微观数据规模很大时候，依靠集中数据处理会是很不方便，我们能够将数据库建设分散化，由当地来进行数据搜集、整理和数据库更新。然而，数据使用却不能是地域化，数据查询是全国范围。这么，共享数据管理和共享数据使用范围就会不一致。为了处理这一问题，能够考虑使用标准目录数据库，统一结构目录数据库将允很多层次分布式建立自己子系统，而又能自然形成一个整体，以支持统一数据库查询，这对于建立大规模专题数据库体系是很有效。数据就近管理和联合统一使用不仅会大大提升数据共享范围，而且会有效地降低数据维护管理成本。
（4）数据源异构性
数据源异构性关键表现在两方面：
s 系统异构，数据源所依靠应用系统、数据库管理系统乃至操作系统之间不一样组成了系统异构。
s 模式异构，数据源在存放模式上不一样。通常存放模式包含关系模式、对象模式、对象关系模式和文档嵌套模式等多个，其中关系模式为主流存放模式。需要注意是，即便是同一类存放模式，它们模式结构可能也存在着差异。比如Oracle所采取数据类型和SQLServer所采取数据类型并不是完全一致。
4.5.2.4 数据整合和集成需求
异构数据源数据整合和集成目标是为综合应用系统提供集成、统一、安全、快捷信息查询、数据挖掘和决议支持服务。为了满足这个需求条件，整合、集成后数据必需确保一定集成性、完整性、一致性和访问安全性。
1、集成性
多种原先孤立业务信息系统数据经过整合、集成后，应该达成查询一个综合信息无须再到各个业务系统进行分别查询和人工处理，只要在数据中心中就能够直接访问到，即整合、集成后数据是各异构业务数据有机集成和关联存放（整合、发掘出各业务数据间内在关联关系），而不是简单、孤立堆放在一个数据库系统里。
2.完整性
包含数据完整性和约束完整性两方面。
s 数据完整性是指完整提取数据本身，通常来说，这一点较轻易达成。
s 约束完整性，约束是指数据和数据之间关联关系，是唯一表征数据间逻辑特征。确保约束完整性是良好数据公布和交换前提，能够方便数据处理过程，提升效率。
3.一致性
不一样业务信息资源之间存在着语义上区分。这些语义上不一样会引发多种不完整甚至错误信息产生，从简单名字语义冲突（不一样名字代表相同概念），到复杂结构语义冲突（不一样模型表示一样信息）。语义冲突会带来数据集成结果冗余，干扰数据处理、公布和交换。
整合、集成后数据应该依据一定数据转换模式和业务规则进行统一数据结构和字段语义编码转换。
4.访问安全性
因为数据库资源可能归属不一样单位，各业务数据系统有着各自用户权限管理模式，访问和安全管理很不方便，不能集中、统一管理。所以既要确保能访问异构数据源中数据，又要保障原有数据库权限不被侵犯，实现对原有数据源访问权限隔离和控制，就需要设计数据中心统一用户安全管理模式来处理此问题。
值得注意是，多个数据源之间数据集成，并不是要将全部数据进行集成，那么怎样定义要集成范围，就组成了集成内容限定问题。
针对异构数据源整合和集成需求，能够采取数据仓库技术和数据抽取工具来实现。另外，依据国务院17号文件精神，电子政务系统需要"整合信息资源，建立人口、法人单位、空间地理和自然资源、宏观经济四个基础数据库"。为何选择这四个库而不选择别数据库呢？这是基于基础性、公益性、战略性考虑。因为这四个数据库对别数据库建设来说是一个公共产品，其它数据库需要经过它服务，在它基础上不停发展，而产业库能够由中介机构来做。
4.5.2.5 数据元标准化
很多信息描述、定义、获取、表示形式因为缺乏统一、严格标准，致使大量信息数据处于分散、部门全部和各自为政状态，造成数据信息资源浪费，不利于实现全社会数据共享。为了提升政务信息共享和集成份析，确保为政府管理决议和社会各阶层提供科学正确信息，迫切需要开发出一个统一、以标准数据元形式对政务信息表示方法，以支持政务信息共享和交换。
数据元（Data Element）是表示概念一类数据，其特征可由支持信息交换一组数据元属性来表示。或说数据元是一组可识别和可定义数据基础单元。通常来说数据元由数据元名称、属性、表示三部分组成。
数据元是用一组属性描述其定义、标示、表示和许可值一个数据单元。 组成数据元规范基础属性分为标示类属性、定义类属性、关系类属性、表示类属性、管理类属性。当然还能够依据需要增加扩展属性。数据元属性应依据一个标准方法来注册和控制，方便数据元字典中数据元在信息交换中保持一致性，而且能够在不一样数据管理环境中进行数据元管理。数据元基础属性关键有以下几类：
s 标示类，适适用于数据元标示属性。包含名称、标示符、版本、注册机构、同义名称、相关环境。
s 定义类，描述数据元语义方面属性。包含定义。
s 关系类，描述数据元之间相互关联和（或）数据元和分类模式、数据元概念、对象、实体之间关联属性包含分类模式、关键字、相关数据参考、关系类型。
s 表示类，描述数据元表示方面属性包含表示类别、表示形式、数据元值数据类型、数据元值最大长度、数据元值最小长度、表示格式、数据元许可值。
s 管理类，描述数据元管理和控制方面属性包含主管机构、注册状态、提交机构、备注。
在这些基础属性中名称、定义、表示类别、表示形式、数据元值数据类型、数据元值最大长度、数据元值最小长度、数据元许可值是在描述数据元时是必选。
数据元表示是在数据处理和信息交换过程中数据元所采取格式。如数据长度、数据类型等全部要给说明，数据元格式受数据元属性及应用环境限定。
数据元可分为通用数据元和应用数据元。通用数据元是独立于任何具体应用而存在数据元，其功效是为应用领域数据元设计也就是为应用数据元设计提供一部通用数据元字典。应用数据元是在特定领域内使用数据元集，比如在电子政务领域应用。从这个意义上来讲国家标准《数据元及交换格式、信息交换、日期和时间表示法》就应该是一部通用数据元字典。
所谓数据元标准化就是对数据元总则、定义、描述、分类、表示和注册等制订统一标准，并加以落实、实施过程。在大量繁杂政务信息中，哪些概念能够作为我们定义数据元基础，数据元概念特征中哪一个能够继承下来作为派生通用数据元特征，通用数据元特征中又有哪些能够被应用数据元所继承。以上这些问题全部是数据元标准化过程所要处理。
伴随社会发展，信息在社会各个行业中作用不停提升，数据元标准也越来越引发各个行业重视。大家认识到只要对信息按共同约定规则进行统一组织、分类和表示，使用同一概念，并用相同表示，就能做到共识，不致产生歧义。这种简化概念表述，提升了数据正确性，有利于数据共享、交换。
各政务系统所要处理对象关键是数据，数据元标准所要起作用就是用一个统一标准来描述、定义、规范这些系统所要处理数据，为系统间数据共享、数据交换提供一个公用信息接口。这个公用信息接口基础是政府部门数据环境建设，而数据环境建设基础就是用数据元标准来描述数据源，建立电子政务领域应用数据元字典。这个公用信息接口实际上就是我们对政务领域信息以数据元标准进行描述，形成一个大家全部广泛接收，并在政务系统开发过程中遵守规则。在此基础上，多种系统之间数据共享、数据交换成为可能。
数据元标准化过程起到了一个针对要处理数据源进行规范化作用。经过这个过程，规范了其中概念、定义、和知识描述，形成了数据元词典，依据这个词典首先数据库内容规范有了依据，其次数据库结构也得到了规范。
4.5.2．6 模型设计基础
　　异类软件产品、应用程序、和数据库系统想要有效地互操作，它们必需要对相互间信息结构有一个共同了解。元数据是描述数据数据，或是和数据相关信息，通常由信息结构描述组成。元数据对不一样厂商提供异类软件系统和产品之间集成起着不可或缺作用。传统四层元数据体系结构图以下：
图4-9 四层元数据体系结构
l 数据层（0层）是用户对象层，它表示是"目标"数据，即我们所期望描述信息。比如在特定关系数据库中表示为特定表实例。比如，公民基础信息表中某个具体公民信息，相当于公民基础信息表中一条统计。
CitizenNo Name Age Address
张三 28 武汉
李四 45 北京
l 模型层（1层）包含描述目标数据数据模型。比如在特定关系数据库中表示为特定表、特定表约束（主键、外键等）、特定表结构等。比如，公民基础信息表结构，即该表中包含哪些列，和各个列数据类型等。
Table Column Attribute
Citizen CitizenNo Numeric
Name String
Age Numeric
Address String
l 元模型（2层）包含了定义模型层元数据，也就是表示M1层元数据抽象语言。比如在关系数据库系统中，表示为特定数据库中表定义、列定义、主键定义和外键定义等。相当于UML元模型定义很多元素如类，操作，属性，关联等等。
DataStore Component ……
File Table
Column
Attr
l 元元模型层（3层）是由定义元数据结构和语法描述组成，也能够说它是定义多种元数据抽象语言。
传统元数据集成
图4-10是数据中心中一个经典信息供给链（ISC）示例。信息从其源头（即原始数据提供者）流出，经过一系列精炼过程，最终产生信息产品。这些产品可能对于高层决议者来说含有重大战略价值。
图4-10 数据中心中信息供给链
以上每个软件产品和工具，在它们能在数据层上有效集成之前，必需在元数据层上被集成。元数据集成是有效数据集成一个先决条件。然而，元数据集成是十分困难，因为大多数业务产品使用千差万别格式存放元数据。含有不一样元数据工具，往往是经过建立复杂元数据桥来集成。元数据桥是一个能将一个产品元数据转换成另一个产品所需元数据格式一段软件。元数据桥构建是一项艰巨、花费大过程。这么桥需要含有它要集成每个产品元数据结构和接口具体知识；相关不一样模型间怎样相互映射知识也要融入桥中。
图4-11 在信息供给链中增加一个元数据库
图4-11中使用了元数据库，它突出显示了定义对全局可取得、和广泛被了解元数据是有必需。元数据库是含有特定目标数据库，它存放、控制所处环境中，除它本身之外全部相关元数据组件，并对这些元数据组件是可取得。从图中我们能够看到，多种软件产品从中央元数据库中提取全局数据，而不是经过和其它产品点到点连接。这个存放库包含了定义信息供给链（可推广至数据中心）全部元数据单一定义。这个定义基于一个针对存放库产品本身元数据模型。每个产品必需实现它自己存放库访问层（即另一个形式桥），该层了解和特定存放库相关元数据结构（比如接口和元模型），还知道怎样将这些和存放库相关结构映射为和产品相关元数据结构。这种类型配置通常称为星型元数据体系结构。
以上这个方法即使减轻了建立很多点到点桥需要，但建立桥问题仍然没有完全消除。我们还是需要为每一个软件组件开发一个不一样访问层（该层能够由产品厂商、存放库厂商或第三方顾问开发），每一个访问层仍然是和某一特定存放库产品相关。基于模型元数据集成能够有效地处理这个问题。
基于模型元数据集成
用一个形式化语言（如UML）描述模型（图4-12）能够被用来定义描述某种信息结构或模式元数据。这种形式化语言能够被翻译成对应元数据定义，后者能被用来创建信息结构本身真正实例。这些各式各样形式化模型通常是平台无关，它们并不显示用来配置实际信息结构计算机平台物理特征，因为形式化建模语言（如UML和其它多种数据建模语言）定义通常是和平台无关。一个SQL DDL语句集能够被看成是一个和平台相关模型，因为它们用一个特定计算机平台语言定义目标信息结构（比如，一个和SQL兼容关系数据库引擎）。将一个形式化模型转换为SQL DDL假定翻译过程，称为将和平台无关模型映射为和平台相关模型，该映射是基于翻译过程所实现一些形式化映射规则集。
图4-12 简单关系数据表模型
由上我们能够得出三个很关键结论：
▅ 一个信息结构任何形式化模型全部是定义该信息结构元数据（元数据本质上是它所描述数据一个形式化模型）
▅ 元数据，当用一个形式化、和平台无关模型表示时，能够独立于任何特定目标平台而存在。
▅ 元数据，当用一个形式化、和平台无关模型表示时，能够被翻译成若干和平台相关模型中任何一个，每一个代表一个不一样目标平台（当然要特定合适映射规则和实现这些规则）。
元数据集成一个可能方法就是开发一个元数据外部表示，它不依靠于任何一个特定产品和工具。这么一个表示是基于信息结构形式化、和平台无关模型，该模型用一个合适语言（如UML）描述。一个产品用这么一个形式化模型作为它自己元数据基础，经过调用一个合适导入映射（import mapping）过程将这个形式化模型翻译成它自己、和产品相关元数据实例。类似，一个产品能够经过一个将它自己内部元数据翻译成一个和平台无关形式化模型导出映射（export mapping）过程，将它全部元数据显示给其它产品。
这个方案在哪些方面优于前面提到元数据桥处理方案呢? 元数据桥关键问题是每座桥要在两个和产品相关模型之间进行映射，桥本质上需要将元数据从一个产品元模型要求格式转换成另一个和产品相关元模型所要求格式。现在，元模型本身被外部化（externalized），和特定实现平台无关；而且，产品交换元数据也基于这个公共、外部元模型，这么，在各自实现模型间翻译问题也就不存在了。
这种元数据级集成和互操作方法称为模型驱动元数据体系结构。从根本上说，它是由软件产品之间元数据交换组成，这里元数据定义是以形式化、和平台无关模型来表示。参与软件产品和工具就定义整个域公共元模型达成一致，这么它们就能很方便了解该元模型任何实例（比如可能被交换、任何共享元数据）。任何产品将这个共享元数据映射为它自己内部元数据表式方法。这要求元模型在它领域有一个完整描述。
OMG公共仓库元模型（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 业务信息包BusinessInformation 数据类型包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）），它定义了对离散系统建模要用到元模型中基础元素、语法和结构。MOF是UML和CWM公共模型，MOF使不一样元模型（代表不一样领域）能够互操作。遵照MOF规范应用软件一点也不了解某个模型实例和特定领域相关接口情况，不过它仍然能够经过使用反射接口通用操作对该模型进行读取和更新操作。
MOF语义通常定义了支持模型创建、发觉、转换和更新一些元数据库服务。尤其，MOF定义了模型生命周期语义。模型生命周期定义了相关元数据创建和公布有效操作，尤其是结合到可视化建模时候（比如，面向UML建模工具）。比如，新开发元模型能够存放在MOF存放库中，并和其它以存在元模型结合起来使用。一个支持MOF存放库除了负责元数据创建和获取，还提供了很多关键元数据相关服务（比如连续化、版本控制、查询等）。
总而言之，MOF试图给出建立元对象模型统一规范，其关键活动是描述元对象和建立元对象模型，方便经过共享元数据，达成不一样操作系统、不一样应用程序、不一样数据库平台等互操作性目标。
基于模型元数据集成方法还要求有一个用于交换共享元数据实例公共交换格式，和访问元数据公共程序接口。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，到OMGIDL映射。CWM规范包含完整IDL定义。用选定某种语言（比如Java或C++）定义程序接口，必需使用合适目口号言编译器将CWM IDL编译为符合目口号言语法接口定义。
最终，我们认为一个基于模型元数据集成处理方案还必需提供部分扩展模型标准方法，这对于定义CWM没有考虑到、和产品高度相关元数据而言是必不可少。
4.5.2．7 数据库类型
按数据库所服务业务功效，可把数据库分成以下种类（下图仅供参考）

图4-14 数据库类型
四大基础数据库：包含人口数据库、法人单位数据库、空间地理和自然资源数据库、和宏观经济数据库。
专题操作数据库：存有常常使用业务数据，可存在数据中心，但大量是以目录形式存放，而其数据总是存在各局委办，这么既确保了数据动态更新一致性，也确保了数据安全性。但设计业务数据时，要在响应速度，冗余，一致性上作出折中。
办公数据：统计政府系统办公数据。并联审批，用户使用状态日志和进行平台管理，电子政务系统维护管理数据。该项数据依据相关平台工具和业务系统进行定义和维护其结构模型遵照关系数据库设计标准。
文本资料数据库：资料关键包含国家政策和指令，本省市资料和条文等信息，是各级工作人员办理多种业务依据，也是学习国家和省市政策和法规路径。在国家政府机构，这么资料显得额外关键，离开了它，就不能确保各项工作正常进行方向。现在机关相关资料以纸面居多，部分比较少在库中存放资料也是以扫描方法进入，因为各单位资源共享问题，并没有做到资料互通，查找资料过程可能就是一个费时费力过程。资料库关键有以下部分特点：
i. 以文档形式存放
ii. 资料共享性要求
iii.涉密资料安全存放
iv. 支持智能和模糊查询
基于上述特点，在全省（市）建设一个统一资料库。这么做得好处于于便于统一管理，尽可能提供资料共享。
多媒体资料数据库：它包含多种政务图像、视频，用于宣传报道和视频点播。
元数据库：元数据库建设目标是建立全省（市）统一政务数据字典和数据中心元数据模型。该数据库由两部分组成：
s 政务数据字典：包含政务叙词表，信息分类、代码和指标体系表。关键用于各职能部门信息联接和交换。
s 数据中心元数据：数据中心中所包含全部元数据（比如使用公共仓库元模型CWM所定义全部元数据）。具体可包含数据模型定义、数据抽取规则、映射转换规则、专题定义、资料分类和维度定义、决议模型定义等等。
数据仓库：数据仓库中存放面向分析按专题分类多层次汇总数据。数据仓库建设目标是为上层决议支持系统提供充足数据支持。数据仓库中数据根据统一数据模型进行组织和分类。各项业务数据经过提取、清洗和转换后根据数据仓库统一数据模型装载入数据仓库中。数据仓库中保留各项数据较长时间历史数据和在多个层次上汇总数据。
在数据仓库基础上结合以商业智能工具和联机分析工具可实现多个深层次数据分析应用，比如：估计报警、多维数据分析、数据挖掘、专题分析和决议支持等。
4.5.3 数据中心对平台要求
数据中心是电子政务系统关键之一，它支持门户和多种业务数据紧密耦合，支持各业务系统运行，并为查询、估计提供支持。其相互关系描述以下
由上图可见，中间件服务器经过数据中心接口可使用已经有JDBC、ODBC，而其它部分全部存在接口定义，数据库设计工具和维护工具。
① 数据中心同门户接口定义，应在门户支撑平台中给支持。
② 数据中心同各业务系统关系定义，要在数据交换中心平台中给以支持：
l 各局委办业务数据库同操作数据库中映射关系定义。
l 业务系统数据模型定义和面向专题操作数据库建立和维护。
③ 数据交换中心所需要各类数据定义和维护，该项功效在数据交换中心平台中提供支持。
④ 多媒体数据库（经过内、外门户接入）由视频会议系统和公务服务等系统提供数据存取接口。
⑤ 资料数据库由对应应用系统提供存取接口。
4.5.4 数据库安