CN102663008A - 政府综合业务平台业务库和基础库的构建方法 - Google Patents

Abstract

本发明提供一种政府综合业务平台业务库和基础库的构建方法，通过对政府综合业务的分析，建立业务模型，并通过业务中数据的不同特性对模型进行划分。在传统的基础库和业务库两层结构的基础上根据相关的业务原则将基础库划分为基础库和共享库两部分，形成基础库、共享库和业务库三层结构。

Description

政府综合业务平台业务库和基础库的构建方法

技术领域

本发明涉及一种计算机应用技术领域，具体地说是一种政府综合业务平台业务库和基础库的构建方法。本发明涉及对政府综合业务平台的业务建模，根据业务数据的不同特性建立基础库，以方便数据的共享。

背景技术

我国政府部门业务管理系统经过长期的发展，记录了大量的相关部门业务的数据，这些数据是政府部门进行管理的重要依据。目前，这些数据存在信息难以共享的问题。因此，加强对这些系统的整合利用，实现信息资源的完全共享，解决信息孤岛的问题，已经成为政府部门信息系统建设的迫切要求。虽然任何预防措施也无法真正杜绝信息孤岛的产生，但是有效的防范可以避免产生不必要的孤岛，在出现信息孤岛时可以比较方便的解决。信息孤岛对策需要从现有信息孤岛的解决和未来信息孤岛的防范两方面着手。

目前解决信息孤岛的方法主要有：

1)升级替换

升级替换就是对现有失去持续维护能力和没有维护意义的系统，采用升级的办法或用全新的系统替换旧系统，将旧系统中产生的数据导入到新系统中，从而消除现有信息孤岛。这种办法可以从系统运行环境、数据库系统等统一起来，在数据整合的基础上实现系统的整合和业务的集成。条件许可的情况下，可以对企业信息化重新规划，对现有运行的系统进行全面的升级和替换。

2)建立数据交换协议和数据接口

建立数据接口是一种不彻底但有效的方法。针对一些业务上相对独立的系统，这些系统可能由不同的供应商提供，全面升级又不可能，可以采用建立数据接口方式实现系统之间的信息共享。接口协议建立后，由供应商负责自己系统的修改，遵循接口协议在规定的数据存放地点存、取所需要的数据。

3)通过集成平台实现系统应用的集成

集成平台是可以适应于不同系统之间信息共享的通用工具，就是通过企业应用集成技术将企业的业务流程、公共数据、应用软件、硬件和各种标准联合起来，在不同企业应用系统之间实现无缝集成，使它们像一个整体一样进行业务处理和信息共享。当在多个企业系统之间进行商务交易的时候，集成平台也可以为不同企业之间实现系统集成。

信息孤岛的防范方法主要有：

1)统一信息化规划

结合企业实际情况，进行信息化的统一规划，确定统一的系统运行环境、数据库系统，规定企业信息集成模式、接口标准和规范。在保证各个数据流畅通的前提下，达到消除“信息孤岛”的目的，实现各个子系统的高速、高效互联，达到信息共享和网上数据交换，提高信息传递效率。在以后实施新的系统时，可以依据总统规划要求来进行，确保在后实施的系统能接入进来，尽量避免产生新的信息孤岛。

2)理顺企业的数据流

企业信息化作为一个严密的信息系统，数据处理的准确性、及时性和可靠性是以各业务环节数据的完整和准确为基础的。信息系统的实施是建立在完善的基础数据之上的，因此，理顺企业的数据流是企业信息化建设成功的关键之一。

3)统一数据平台和集成标准

统一数据平台的基础就是以业务为核心，通过信息流将企业各部门的主要业务操作集成起来。信息系统规划和建设，需要根据企业规模确定数据的分布式数据结构或集中式数据模式，统一数据库系统和运行平台。采用分布式数据库的需要确定分布的层次、数据传递方向和标准，这样有助于减少日后消除信息孤岛的成本。

本专利中申请的政府综合业务平台业务库和基础库就通过建立数据交换协议和数据接口以及统一数据平台和集成标准来解决信息孤岛问题。

传统的业务平台分为三层，三层结构的基本思想是将用户界面同业务逻辑分离，将系统按功能划分为表示、业务库和基础库三部分。基于三层结构技术构建的系统总体框架能够很好地解决海量空间数据和属性数据的一体化管理，同时在负载平衡、分布式客户应用和信息的并发访问方面具有较好的性能。三个逻辑层中的应用单元通过一组业界标准的协议、服务和软件连接器连接起来，使各级用户处于理论上的平等地位，实际的区别仅取决于操作用户端软件的人员、单位的授权差异。由于表示层、业务层、基础层相互独立，使得各层与具体软硬件平台的关系紧密度下降，有利于未来系统用户的特殊需求，未来新增功能的开发、系统调试和修改工作都能单独进行。

数据库建设中的难点分析：

1)信息资源标准体系尚不完善，行业代码体系尚不健全，数据接口标准不一致、致使信息资源的完整性、准确性、可比性较差，难以为管理决策提供科学依据；

2)应用系统间“信息孤岛”仍然存在。由于政府部门的业务系统之间存在有各系统的建设时间不一，开发商不同，各业务系统自成体系等原因，造成信息资源各自独立分散存储并处理，没有进行有效的抽取、清洗和集中，数据共享困难，数据的交换与共享机制有待进一步完善；

3)各应用系统已积累的大量的有价值的信息资源缺乏有效的分析、挖掘和展示，致使信息资源的价值未得到充分利用；

4)业务系统不完整。

数据库平台建设涉及很多数据标准，如信息分类与编码标准、数据采集与转换标准、数据质量控制标准、数据库及数据集文件的命名规范与标准、信息图式图符标准以及元数据标准等。

1)元数据及元数据标准。在《电子政务数据元》国家标准中，元数据定义为“关于数据的数据”。

2)分类与编码标准。通过调查现有的政府部门业务数据分类与编码标准，了解现有标准的适用情况和存在问题，对没有现成分类与编码标准的，应在现有标准的基础上进行分类与编码的扩充，制定扩充的原则。

3)数据采集与转换标准。根据数据内容的分析，确定需要进行采集的数据和采集标准；确定需要转换的数据和转换标准；同类数据在数据采集时必须遵循相同的标准。要充分考虑已运行系统与新制定标准间的转换问题。

4)数据质量控制标准。制定数据库平台中的数据质量标准，从宏观、微观和使用等3个方面来进行，微观质量标准包括位置精度、属性精度、逻辑一致性、分辨率等；宏观质量标准包括完整性、时间性等、使用质量标准包括数据的保密与公开、费用等。不同用途的数据，其数据质量标准不同。

5)数据库及数据集文件的命名规范与标准。为使系统具有统一性和可扩充性，同时便于维护，应制定数据库及数据集文件的命名规范与标准。参照其他数据库平台的命名规则，根据政府部门业务数据的特点，制定相应的数据库命名规则。在工务基础数据库建设中，笔者采用中西文对照方式来命名数据库、文件和字段，并建立相应的字典表。

数据库平台建设中的关键技术分析

在政府部门业务基础数据库平台建设中，数据组织与存储方案，数据安全与保密策略和数据维护与更新体系是系统平台建设关键技术，需要认真研究探讨，这里重点探讨基础数据库平台的数据组织与存储方案。

基础数据库平台涉及的数据量大、数据类型多、来源广泛、数据格式复杂，数据的组织与存储机制直接关系到数据的应用效率。数据组织涉及微观数据组织和宏观数据组织，微观数据组织是从微观上研究数据组织的一种方式，包括微观数据组成、数据模型、数据结构、空间关系等，宏观数据组织则在微观数据组织的基础上实现数据的高效管理，时间性、多尺度和多来源数据的分布式组织管理是解决问题的关键。在政府综合业务基础数据库平台中主要解决：不同业务部门间的数据组织；空间数据的无缝存储；海量影像、图片以及录像数据的高效存储管理；元数据的存储管理模式等。

发明内容

本发明的目的是提供一种政府综合业务平台业务库和基础库的构建方法。

本发明的目的是按以下方式实现的，包括以下内容：

1)将需要共享的数据划分为基础库和数据库两层，减少了数据的冗余，增加业务库分层，促进在数据层面共享，实现业务无缝集成；

2)建立应用于基础库的数据模型，将基础库与共享库分离，基础库中的模型包括：

当事人模型；组织模型；当事人分类模型；当事人联系机制模型；人员模型；人员关系模型；业务分类模型；产品分类模型；业务产品分类模型；

1)概念数据模型：这是面向数据库用户的实现世界的数据模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的DBMS无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。其中将其分为业务库和基础库。

2)逻辑数据模型：这是用户从数据库所看到的数据模型，是具体的DBMS所支持的数据模型，如网状数据模型、层次数据模型等等。此模型既要面向拥护，又要面向系统。

3)物理数据模型：这是描述数据在储存介质上的组织结构的数据模型，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构；

其中

1)数据结构：数据结构是所研究的对象类型的集合。这些对象是数据库的组成成分，数据结构指对象和对象间联系的表达和实现，是对系统静态特征的描述，包括两个方面：

(1)数据本身：类型、内容、性质。例如关系模型中的域、属性、关系；

(2)数据之间的联系：数据之间是如何相互关联的，例如关系模型中的主码、外码联系；

2)数据操作：对数据库中对象的实例允许执行的操作集合，主要指检索和更新，包括：插入、删除、修改两类操作，数据模型必须定义这些操作的确切含义、操作符号、操作规则以及实现操作的语言，数据操作是对系统动态特性的描述；

3)数据完整性约束：数据完整性约束是一组完整性规则的集合，规定数据库状态及状态变化所应满足的条件，以保证数据的正确性、有效性和相容性；

概念数据模型中的基础库及其应用；包括以下内容：

词汇表

当事人：政府业务中称为行政相对人或者被管理对象；

当事人分类：或称为当事人角色或者当事人类别；

当事人模型：

当事人分成两个部分：个体或者由若干个个人形成的组织，在政府业务中，虽然被管理的主要对象是组织，但是不排除在证后监管的环节中，被管理对象涉及到个人，包括：在执法的过程中，案件当事人是个人或者组织，为了把某个当事人所有与之相关的信息关联起来，识别出唯一的当事人本体，是非常重要的；

关于当事人模型中涉及到的人的部分，包括以下内容：

1)在基础库中新建有人员模型，当事人中的个人对象和基础库上的人员因为管理目的不同而分别对待。个人作为被管理对象，我们很难获得被管理对象的学历学位、工作经历等信息；

而人员主要是在业务/系统中要成为专家或者要获得某种资质的人员，我们会对其学历、工作经历等信息有所了解。虽然一个人在某种极端的情况下，会同时作为个人和人员而出现，包括：某个有资质的人员涉及到某个案件中，成为案件当事人，但我们一般不关注这种极端的情况，因此，在建模时做简化处理；

2)从高度抽象的角度上看，我们将当事人中的个人与基础库上的人员进行合并进行统一，在这种情况下，当某个有资质的人员涉及到某个案件中，成为案件当事人时，业务/系统就会要求把这个人员作为一个本体识别成一个当事人，并且记录其违法行为及所有的获证或者注销记录，必须根据当前业务的需求及将来的业务发展从上述二者中选择其一；

第一种方式看似存在冗余，但如果当前的管理手段或者业务目标不需要非常统一的高度时，还是可以接受的。

第二种方案维护的是一个概念上非常统一的完美模型，人员也有各种各样的联系机制，这跟当事人中的联系机制模型非常吻合，但是，前面也提到过，政府业务中对个人和人员的熟悉程度是不同的，包括来办理某种资质的人员，一般必须要提交相关的信息，而作为当事人的人员，通常是很难找到其学历、工作经历等信息的，因此，第二种方式要求的管理成本要相对比较高一些，但对将来的业务发展较为有利，其主要的成本花费在如何用不太健全的信息去判断一个人员本体的唯一性上；

当事人要确保其在整个生命周期中的唯一性，即同一个当事人不应该在基础库中出现两次当事人的唯一性确定了以后，就要产生一个唯一标识符，唯一标识符的产生有两种方式：

3)采用与具体业务无意义的唯一标识符；

4)采用有业务含义的唯一标识符，如在质监中，针对有组织机构代码的组织，可以用组织机构代码作为唯一标识符；针对无组织机构代码的组织，系统会产生一个可以识别出与正规组织机构代码不同的的临时的组织机构代码作为唯一标识；针对个人，会用其身份证号作为基础输入产生一个标识个人的临时的代码作为唯一标识；

政府有的业务中，用组织机构代码来作为唯一标识是没有错的，但在大部分政府业务中，用组织机构代码作为唯一标识就不是很合适了，因为里面还牵扯到一个问题：对于是先办理出某业务中的组织机构代码，还是先办理出与自身业务有关的证照，如工商营业执照，因此，作为电子政务产品的基本库，在无法判断业务先后顺序的情况下，我们更倾向于采用第一种方式作为当事人的唯一标识符，而将各业务中产生的有业务含义的标识符作为唯一性属性进行匹配判断；

唯一性属性的匹配判断规则为：

如果是个人，可以用公民身份证号进行判断，如果唯一标识存在重复的情况；如果给定的个人的公民身份证号属性为空，就用名字或者出生日期作为第二级的判断，并人工处理；

如果当事人是组织，就会用工商执照号、组织机构代码号作为唯一标识进行匹配，如果唯一标识存在重复的情况，组织可以细分成两种类型：一种是根据当前业务的需要，获得了正式身份的组织：第二种是违法没有获得正式身份的组织；

当事人关系：

当事人关系，在金融或者其他高风险的业务中，会对当事人之间的各种可能存在的关系都非常地关注，在这种情况下，就需要把当事人关系作为一个单独的建模元素，在政府业务中，对当事人关系并不是特别的重视，因此我们就采用简化的模型；

1)所属法人？

2)相关企事业？当我们明确知道一个非正式组织申请到了一个正式的代码后，就需要建立新的组织跟原来非正式组织的关联关系；

3)上级主管机构？根据现在了解的情况，每个主管机构肯定是会申请组织机构代码证的，但是上级主管机构是从业务的组织机构模型还是从当事人模型中选择，还值得探讨；

当事人分类：

一个当事人可以有多种当事人分类，每种当事人分类可以对应若干个当事人；

在申请组织机构代码时，可选择的机构类型包括企业、事业单位、社会团体、机关、民办非企业、个体、工会法人。再如：在政府业务系统中将当事人分成若干大类；

每个当事人即是生产企业又是经营类企业，每个生产类企业4品全生产或者只生产部分产品，每个经营类企业4品全经营或者只经营部分产品；

当事人联系机制：

每个当事人会有若干种联系机制，包括通讯工具号码、邮政地址、电信号码、电子邮件或者web地址，每种联系机制属于一种联系方式，如邮政地址可以作为生产地址或者注册地址，电信号码可以作为办公电话或者宅电等，这是一种理论模型，虽然扩展起来比较容易，但是在实际的应用过程中，可能查找起来不是很方便，因此可能会考虑将多份联系机制压缩后放入到当事人基本信息中的做法，每种联系机制可以额外保留几份，以便做自定义扩展；

人员模型：

基础库中的人员模型要根据当事人模型选择的方案结果来进行调整，有可能会合并到当事人的个人模型中，在政府业务中，需要关注关键岗位从业人员的工作经历、教育经历、个人基本信息内容，在可能预见的业务规则中，如果一个关键岗位从业人员从一个当事人切换工作到另一个当事人，那么就可能会引发原当事人的资质不足；

有些人员角色是在事务处理过程中动态实例化的，包括**事项的申请人，经办人，还有些人员角色是事务无关的，包括专家，在质监的业务处理过程中，具有某种资质的人员作为某种专家，但是我们不用直接建立资质和专家之间的跟踪关系，只需在必要时，将这种资质的人员过滤出来，并添加其专家角色即可，冗余信息还是要有的，主要是想记录发生事件时的状态；

人员关系：

人员关系的建设方案包括特定人员关系和通用人员关系，如果系统要管理特定的人员关系，就需要针对特定人员关系建立自己的领域对象，这就不属于基础库的范畴，如果要建立通用的人员关系，就可以理解从什么时间到什么时间，当事人以某种角色的身份跟另一种角色的当事人存在什么样的关系；

注意事项：

1)当事人的角色目前来看是可以省略的；

2)我们目前只强调了人员和当事人之间的关联关系；

业务分类模型：

业务分类在系统规划中起到了至关重要的作用，它包括了两个部分，可以再细分的节点被称为业务领域，最末级的叶子节点被称为业务，一个业务被实例化后，被称为业务事项；

关于最末级的“业务”应该是什么样的粒度，目前有两种理解：

1)按照国家**总局下发的标准中，对业务分类做了最细致的划分，一个业务分类的最末级，是***许可证申请-复查、***许可证申请-变更、***许可证申请-迁址；

2)在**政府的系统中，则是把复查、变更、迁址等理解成了业务事项类型流程也是不同的，在流程定义的时候，将其定义成一个流程，通过分支来判断环节的走向，这样做的好处是：减少了许多相似的流程定义的个数。业务分类和文书规则的关系；

产品分类模型：

以一个目录为基准产品目录，可以自定义产品目录，但自定义产品目录必须要指定基准产品目录。每个业务模块可以根据自己的需要建立业务产品目录，业务产品目录必须从基准或者自定义产品目录中进行筛选，并定义上下级关系，如图9。

业务产品分类模型：

每个业务模块可以从基准的产品目录上进行筛选，从而定制出自己业务视角的业务产品目录。

附图说明

图1，当事人模型；

图2，组织模型；

图3，当事人分类模型；

图4，当事人分类示例图；

图5，当事人联系机制模型；

图6，人员模型；

图7，人员关系模型；

图8，业务分类模型；

图9，产品分类模型；

图10，业务产品目录分类模型。

具体实施方式

参照说明书附图对本发明的方法作以下详细地说明。

模型是对现实世界的抽象。在数据库技术中，表示实体类型及实体类型间联系的模型称为“数据模型”。

数据模型是数据库管理的教学形式框架，是用来描述一组数据的概念和定义，包括三个方面：

1、概念数据模型(Conceptual Data Model)：这是面向数据库用户的实现世界的数据模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的DBMS无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。其中将其分为业务库和基础库。

2、逻辑数据模型(Logixal Data Model)：这是用户从数据库所看到的数据模型，是具体的DBMS所支持的数据模型，如网状数据模型、层次数据模型等等。此模型既要面向拥护，又要面向系统。

3、物理数据模型(Physical Data Model)：这是描述数据在储存介质上的组织结构的数据模型，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。

数据模型的三要素：

一般而言，数据模型是严格定义的一组概念的集合，这些概念精确地描述了系统的静态特征(数据结构)、动态特征(数据操作)和完整性约束条件，这就是数据模型的三要素。

1、数据结构

数据结构是所研究的对象类型的集合。这些对象是数据库的组成成分，数据结构指对象和对象间联系的表达和实现，是对系统静态特征的描述，包括两个方面：

(1)数据本身：类型、内容、性质。例如关系模型中的域、属性、关系等。

(2)数据之间的联系：数据之间是如何相互关联的，例如关系模型中的主码、外码联系等。

2、数据操作

对数据库中对象的实例允许执行的操作集合，主要指检索和更新(插入、删除、修改)两类操作。数据模型必须定义这些操作的确切含义、操作符号、操作规则(如优先级)以及实现操作的语言。数据操作是对系统动态特性的描述。

3、数据完整性约束

数据完整性约束是一组完整性规则的集合，规定数据库状态及状态变化所应满足的条件，以保证数据的正确性、有效性和相容性。

下面就来举例说明概念数据模型中的基础库以及其应用。

词汇表

当事人：Party，政府业务中称为行政相对人或者被管理对象。

当事人分类：PartyClassification，也可以考虑称为当事人角色或者当事人类别。

当事人模型：

当事人分成两个部分：个体(individual)或者由若干个个人形成的组织(organization)。在政府业务中，虽然被管理的主要对象是组织(企业)，但是不排除在证后监管的环节中，被管理对象涉及到个人。如：在执法的过程中，案件当事人就可以是个人或者组织。为了把某个当事人所有与之相关的信息关联起来，识别出唯一的当事人本体，是非常重要的。如图1。

关于当事人模型中涉及到的人的部分，目前有两种理解方式和处理手段：

1、在基础库中新建有人员模型。当事人中的个人对象和基础库上的人员因为管理目的不同而分别对待。个人作为被管理对象，我们很难获得被管理对象的学历学位、工作经历等信息；而人员主要是在业务/系统中要成为专家或者要获得某种资质的人员，我们会对其学历、工作经历等信息有所了解。虽然一个人在某种极端的情况下，会同时作为个人和人员而出现(如，某个有资质的人员涉及到某个案件中，成为案件当事人)，但我们一般不关注这种极端的情况，因此可以在建模时做简化处理。

2、从高度抽象的角度上看，我们可以将当事人中的个人与基础库上的人员进行合并进行统一。在这种情况下，当某个有资质的人员涉及到某个案件中，成为案件当事人时，业务/系统就会要求把这个人员作为一个本体识别成一个当事人，并且记录其违法行为及所有的获证或者注销记录。必须根据当前业务的需求及将来的业务发展从上述二者中选择其一。

第一种方式看似存在冗余，但如果当前的管理手段或者业务目标不需要非常统一的高度时，还是可以接受的。

第二种方案维护的是一个概念上非常统一的完美模型，例如人员也有各种各样的联系机制，这跟当事人中的联系机制模型非常吻合。但是，前面也提到过，政府业务中对个人和人员的熟悉程度是不同的(来办理某种资质的人员，一般必须要提交相关的信息，而作为当事人的人员，通常是很难找到其学历、工作经历等信息的)，因此，第二种方式要求的管理成本要相对比较高一些，但对将来的业务发展较为有利。其主要的成本花费在如何用不太健全的信息去判断一个人员本体的唯一性上。

当事人要确保其在整个生命周期中的唯一性，即同一个当事人不应该在基础库中出现两次。当事人的唯一性确定了以后，就要产生一个唯一标识符，唯一标识符的产生有两种方式：

5)采用与具体业务无意义的唯一标识符；

6)采用有业务含义的唯一标识符，如在质监中，针对有组织机构代码的组织，可以用组织机构代码作为唯一标识符；针对无组织机构代码的组织，系统会产生一个可以识别出与正规组织机构代码不同的的临时的组织机构代码作为唯一标识；针对个人，会用其身份证号作为基础输入产生一个标识个人的临时的代码作为唯一标识。

政府有的业务中，用组织机构代码来作为唯一标识是没有错的。但在大部分政府业务中，用组织机构代码作为唯一标识就不是很合适了。因为里面还牵扯到一个问题：对于是先办理出某业务中的组织机构代码，还是先办理出与自身业务有关的证照，如工商营业执照。因此，作为电子政务产品的基本库，在无法判断业务先后顺序的情况下，我们更倾向于采用第一种方式作为当事人的唯一标识符。而将各业务中产生的有业务含义的标识符作为唯一性属性进行匹配判断。

唯一性属性的匹配判断规则为：

如果是个人，可以用公民身份证号进行判断，如果唯一标识存在重复的情况；如果给定的个人的公民身份证号属性为空，就用名字或者出生日期作为第二级的判断，并人工处理

如果当事人是组织，就会用工商执照号、组织机构代码号作为唯一标识进行匹配，如果唯一标识存在重复的情况。组织可以细分成两种类型：一种是根据当前业务的需要，获得了正式身份的组织：第二种是违法没有获得正式身份的组织。如图2。

当事人关系：

当事人关系，在金融或者其他高风险的业务中，会对当事人之间的各种可能存在的关系都非常地关注，在这种情况下，就需要把当事人关系作为一个单独的建模元素。在政府业务中，对当事人关系并不是特别的重视，因此我们就可以采用简化的模型。

1所属法人？(连锁关系？)

2相关企事业？当我们明确知道一个非正式组织申请到了一个正式的代码后，就需要建立新的组织跟原来非正式组织的关联关系。

3上级主管机构？(根据现在了解的情况，每个主管机构肯定是会申请组织机构代码证的，但是上级主管机构是从业务的组织机构模型还是从当事人模型中选择，还值得探讨。)

当事人分类：

一个当事人可以有多种当事人分类，每种当事人分类可以对应若干个当事人。如图3。

举例：

在申请组织机构代码时，可选择的机构类型包括企业、事业单位、社会团体、机关、民办非企业、个体、工会法人。再如：在政府业务系统中将当事人分成若干大类，如图4。

每个当事人可以即是生产企业又是经营类企业，每个生产类企业可以4品全生产或者只

生产部分产品，每个经营类企业可以4品全经营或者只经营部分产品。

当事人联系机制：

每个当事人会有若干种联系机制，包括通讯工具号码、邮政地址、电信号码、电子邮件或者web地址。每种联系机制属于一种联系方式，如邮政地址可以作为生产地址或者注册地址，电信号码可以作为办公电话或者宅电等。如图5。这是一种理论模型，虽然扩展起来比较容易，但是在实际的应用过程中，可能查找起来不是很方便，因此可能会考虑将多份联系机制压缩后放入到当事人基本信息中的做法。每种联系机制可以额外保留几份，以便做自定义扩展。

人员模型：

基础库中的人员模型要根据当事人模型选择的方案结果来进行调整。有可能会合并到当事人的个人模型中。如图6。在政府业务中，需要关注关键岗位从业人员的工作经历、教育经历、个人基本信息等内容，在可能预见的业务规则中，如果一个关键岗位从业人员从一个当事人切换工作到另一个当事人，那么就可能会引发原当事人的资质不足。

有些人员角色是在事务处理过程中动态实例化的(例如，**事项的申请人，经办人等)，还有些人员角色是事务无关的。例如专家。在质监的业务处理过程中，具有某种资质的人员可以作为某种专家，但是我们不用直接建立资质和专家之间的跟踪关系，只需在必要时，将这种资质的人员过滤出来，并添加其专家角色即可。冗余信息还是要有的，主要是想记录发生事件时的状态。

人员关系：

人员关系的建设方案包括特定人员关系和通用人员关系。如果系统要管理特定的人员关系，就需要针对特定人员关系建立自己的领域对象，这就不属于基础库的范畴。如图7。如果要建立通用的人员关系，就可以理解从什么时间到什么时间，当事人以某种角色的身份跟另一种角色的当事人存在什么样的关系。

注意：

1)当事人的角色目前来看是可以省略的。

2)我们目前只强调了人员和当事人之间的关联关系。

业务分类模型：

业务分类在系统规划中起到了至关重要的作用，它包括了两个部分，可以再细分的节点被称为业务领域，最末级的叶子节点被称为业务。一个业务被实例化后，被称为业务事项。如图8。关于最末级的“业务”应该是什么样的粒度，目前有两种理解：

1)按照国家**总局下发的标准中，对业务分类做了最细致的划分。一个业务分类的最末级，

是***许可证申请-复查、***许可证申请-变更、***许可证申请-迁址等。

2)在**政府的系统中，则是把复查、变更、迁址等理解成了业务事项类型(申请类型)。

流程也是不同的。在流程定义的时候，将其定义成一个流程，通过分支来判断环节的走向。这样做的好处是：减少了许多相似的流程定义的个数。业务分类和文书规则的关系。

产品分类模型：

以一个目录为基准产品目录，可以自定义产品目录，但自定义产品目录必须要指定基准产品目录。每个业务模块可以根据自己的需要建立业务产品目录，业务产品目录必须从基准或者自定义产品目录中进行筛选，并定义上下级关系。如图9。

业务产品分类模型：

每个业务模块可以从基准的产品目录上进行筛选，从而定制出自己业务视角的业务产品目录。如图10。

Claims (1)

1.政府综合业务平台业务库和基础库的构建方法，其特征在于包括以下内容：

1)将需要共享的数据划分为基础库和数据库两层，减少了数据的冗余，增加业务库分层，促进在数据层面共享，实现业务无缝集成；

2)建立应用于基础库的数据模型，将基础库与共享库分离，基础库中的模型包括：

当事人模型；组织模型；当事人分类模型；当事人联系机制模型；人员模型；人员关系模型；业务分类模型；产品分类模型；业务产品分类模型；

1)概念数据模型：这是面向数据库用户的实现世界的数据模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系，与具体的DBMS无关，概念数据模型必须换成逻辑数据模型，才能在DBMS中实现，其中将其分为业务库和基础库；

2)逻辑数据模型：这是用户从数据库所看到的数据模型，是具体的DBMS所支持的数据模型，如网状数据模型、层次数据模型，此模型既要面向拥护，又要面向系统；

3)物理数据模型：这是描述数据在储存介质上的组织结构的数据模型，它不但与具体的DBMS有关，而且还与操作系统和硬件有关，每一种逻辑数据模型在实现时都有其对应的物理数据模型，DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集特殊结构；

其中

1)数据结构：数据结构是所研究的对象类型的集合，这些对象是数据库的组成成分，数据结构指对象和对象间联系的表达和实现，是对系统静态特征的描述，包括两个方面：

(1)数据本身：类型、内容、性质，包括关系模型中的域、属性、关系；

(2)数据之间的联系：数据之间是如何相互关联的，例如关系模型中的主码、外码联系；

2)数据操作：对数据库中对象的实例允许执行的操作集合，主要指检索和更新，包括：插入、删除、修改两类操作，数据模型必须定义这些操作的确切含义、操作符号、操作规则以及实现操作的语言，数据操作是对系统动态特性的描述；

3)数据完整性约束：数据完整性约束是一组完整性规则的集合，规定数据库状态及状态变化所应满足的条件，以保证数据的正确性、有效性和相容性；

概念数据模型中的基础库及其应用；包括以下内容：

词汇表

当事人：政府业务中称为行政相对人或者被管理对象；

当事人分类：或称为当事人角色或者当事人类别；

当事人模型：

当事人分成两个部分：个体或者由若干个个人形成的组织，在政府业务中，虽然被管理的主要对象是组织，但是不排除在证后监管的环节中，被管理对象涉及到个人，包括：在执法的过程中，案件当事人是个人或者组织，为了把某个当事人所有与之相关的信息关联起来，识别出唯一的当事人本体，是非常重要的；

关于当事人模型中涉及到的人的部分，包括以下内容：

1)在基础库中新建有人员模型，当事人中的个人对象和基础库上的人员因为管理目的不同而分别对待，个人作为被管理对象，我们很难获得被管理对象的学历学位、工作经历信息；而人员主要是在业务/系统中要成为专家或者要获得某种资质的人员，我们会对其学历、工作经历信息有所了解，虽然一个人在某种极端的情况下，会同时作为个人和人员而出现，包括：某个有资质的人员涉及到某个案件中，成为案件当事人，但我们一般不关注这种极端的情况，因此，在建模时做简化处理；

2)从高度抽象的角度上看，我们将当事人中的个人与基础库上的人员进行合并进行统一，在这种情况下，当某个有资质的人员涉及到某个案件中，成为案件当事人时，业务/系统就会要求把这个人员作为一个本体识别成一个当事人，并且记录其违法行为及所有的获证或者注销记录，必须根据当前业务的需求及将来的业务发展从上述二者中选择其一；

第一种方式看似存在冗余，但如果当前的管理手段或者业务目标不需要非常统一的高度时，还是可以接受的；

第二种方案维护的是一个概念上非常统一的完美模型，人员也有各种各样的联系机制，这跟当事人中的联系机制模型非常吻合，但是，前面也提到过，政府业务中对个人和人员的熟悉程度是不同的，包括来办理某种资质的人员，一般必须要提交相关的信息，而作为当事人的人员，通常是很难找到其学历、工作经历信息的，因此，第二种方式要求的管理成本要相对比较高一些，但对将来的业务发展较为有利，其主要的成本花费在如何用不太健全的信息去判断一个人员本体的唯一性上；

当事人要确保其在整个生命周期中的唯一性，即同一个当事人不应该在基础库中出现两次，当事人的唯一性确定了以后，就要产生一个唯一标识符，唯一标识符的产生有两种方式：

1)采用与具体业务无意义的唯一标识符；

2)采用有业务含义的唯一标识符，如在质监中，针对有组织机构代码的组织，可以用组织机构代码作为唯一标识符；针对无组织机构代码的组织，系统会产生一个可以识别出与正规组织机构代码不同的的临时的组织机构代码作为唯一标识；针对个人，会用其身份证号作为基础输入产生一个标识个人的临时的代码作为唯一标识；

政府有的业务中，用组织机构代码来作为唯一标识是没有错的，但在大部分政府业务中，用组织机构代码作为唯一标识就不是很合适了，因为里面还牵扯到一个问题：对于是先办理出某业务中的组织机构代码，还是先办理出与自身业务有关的证照，如工商营业执照，因此，作为电子政务产品的基本库，在无法判断业务先后顺序的情况下，我们更倾向于采用第一种方式作为当事人的唯一标识符，而将各业务中产生的有业务含义的标识符作为唯一性属性进行匹配判断；

唯一性属性的匹配判断规则为：

如果是个人，可以用公民身份证号进行判断，如果唯一标识存在重复的情况；如果给定的个人的公民身份证号属性为空，就用名字或者出生日期作为第二级的判断，并人工处理；

如果当事人是组织，就会用工商执照号、组织机构代码号作为唯一标识进行匹配，如果唯一标识存在重复的情况，组织可以细分成两种类型：一种是根据当前业务的需要，获得了正式身份的组织：第二种是违法没有获得正式身份的组织；

当事人关系：

当事人关系，在金融或者其他高风险的业务中，会对当事人之间的各种可能存在的关系都非常地关注，在这种情况下，就需要把当事人关系作为一个单独的建模元素，在政府业务中，对当事人关系并不是特别的重视，因此我们就采用简化的模型；

1)所属法人？

2)相关企事业？当我们明确知道一个非正式组织申请到了一个正式的代码后，就需要建立新的组织跟原来非正式组织的关联关系；

3)上级主管机构？根据现在了解的情况，每个主管机构肯定是会申请组织机构代码证的，但是上级主管机构是从业务的组织机构模型还是从当事人模型中选择，还值得探讨；

当事人分类：

一个当事人可以有多种当事人分类，每种当事人分类可以对应若干个当事人；

在申请组织机构代码时，可选择的机构类型包括企业、事业单位、社会团体、机关、民办非企业、个体、工会法人，再如：在政府业务系统中将当事人分成若干大类；

每个当事人即是生产企业又是经营类企业，每个生产类企业4品全生产或者只生产部分产品，每个经营类企业4品全经营或者只经营部分产品；

当事人联系机制：

每个当事人会有若干种联系机制，包括通讯工具号码、邮政地址、电信号码、电子邮件或者web地址，每种联系机制属于一种联系方式，如邮政地址可以作为生产地址或者注册地址，电信号码可以作为办公电话或者宅电，这是一种理论模型，虽然扩展起来比较容易，但是在实际的应用过程中，可能查找起来不是很方便，因此可能会考虑将多份联系机制压缩后放入到当事人基本信息中的做法，每种联系机制可以额外保留几份，以便做自定义扩展；

人员模型：

基础库中的人员模型要根据当事人模型选择的方案结果来进行调整，有可能会合并到当事人的个人模型中，在政府业务中，需要关注关键岗位从业人员的工作经历、教育经历、个人基本信息内容，在可能预见的业务规则中，如果一个关键岗位从业人员从一个当事人切换工作到另一个当事人，那么就可能会引发原当事人的资质不足；

有些人员角色是在事务处理过程中动态实例化的，包括**事项的申请人，经办人，还有些人员角色是事务无关的，包括专家，在质监的业务处理过程中，具有某种资质的人员作为某种专家，但是我们不用直接建立资质和专家之间的跟踪关系，只需在必要时，将这种资质的人员过滤出来，并添加其专家角色即可，冗余信息还是要有的，主要是想记录发生事件时的状态；

人员关系：

人员关系的建设方案包括特定人员关系和通用人员关系，如果系统要管理特定的人员关系，就需要针对特定人员关系建立自己的领域对象，这就不属于基础库的范畴，如果要建立通用的人员关系，就可以理解从什么时间到什么时间，当事人以某种角色的身份跟另一种角色的当事人存在什么样的关系；

注意事项：

1)当事人的角色目前来看是可以省略的；

2)我们目前只强调了人员和当事人之间的关联关系；

业务分类模型：

业务分类在系统规划中起到了至关重要的作用，它包括了两个部分，可以再细分的节点被称为业务领域，最末级的叶子节点被称为业务，一个业务被实例化后，被称为业务事项；

关于最末级的“业务”应该是什么样的粒度，目前有两种理解：

1)按照国家**总局下发的标准中，对业务分类做了最细致的划分，一个业务分类的最末级，是***许可证申请-复查、***许可证申请-变更、***许可证申请-迁址；

2)在**政府的系统中，则是把复查、变更、迁址理解成了业务事项类型流程也是不同的，在流程定义的时候，将其定义成一个流程，通过分支来判断环节的走向，这样做的好处是：减少了许多相似的流程定义的个数，业务分类和文书规则的关系；

产品分类模型：

以一个目录为基准产品目录，可以自定义产品目录，但自定义产品目录必须要指定基准产品目录，每个业务模块可以根据自己的需要建立业务产品目录，业务产品目录必须从基准或者自定义产品目录中进行筛选，并定义上下级关系；

业务产品分类模型：

每个业务模块可以从基准的产品目录上进行筛选，从而定制出自己业务视角的业务产品目录。

Images