[发明专利]政府综合业务平台业务库和基础库的构建方法

摘要

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

主权项

政府综合业务平台业务库和基础库的构建方法，其特征在于包括以下内容：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地址，每种联系机制属于一种联系方式，邮政地址作为生产地址或者注册地址，电信号码作为办公电话或者宅电，这是一种理论模型，扩展起来比较容易，在实际的应用过程中，查找起来不是很方便，因此应考虑将多份联系机制压缩后放入到当事人基本信息中的做法，每种联系机制额外保留几份，以便做自定义扩展；人员模型：基础库中的人员模型要根据当事人模型选择的方案结果来进行调整，合并到当事人的个人模型中，在政府业务中，需要关注关键岗位从业人员的工作经历、教育经历、个人基本信息内容，在可能预见的业务规则中，一个关键岗位从业人员从一个当事人切换工作到另一个当事人，会引发原当事人的资质不足；有些人员角色是在事务处理过程中动态实例化的，包括某个事项的申请人，经办人，还有些人员角色是事务无关的，包括专家，在质监的业务处理过程中，具有某种资质的人员作为某种专家，我们不用直接建立资质和专家之间的跟踪关系，只需在必要时，将这种资质的人员过滤出来，并添加其专家角色即可，冗余信息还是要有的，是想记录发生事件时的状态；人员关系：人员关系的建设方案包括特定人员关系和通用人员关系，如果系统要管理特定的人员关系，就需要针对特定人员关系建立自己的领域对象，这就不属于基础库的范畴，如果要建立通用的人员关系，就可以理解从什么时间到什么时间，当事人以某种角色的身份跟另一种角色的当事人存在什么样的关系。