CN109918426B

CN109918426B - 食药监数据管理平台的搭建方法

Info

Publication number: CN109918426B
Application number: CN201811571599.9A
Authority: CN
Inventors: 谢志虎; 邴立杰; 赵宇
Original assignee: Aisino Corp
Current assignee: Aisino Corp
Priority date: 2018-12-21
Filing date: 2018-12-21
Publication date: 2021-02-26
Anticipated expiration: 2038-12-21
Also published as: CN109918426A

Abstract

本发明公开一种食药监数据管理平台的搭建方法，包括：从异构***进行数据抽取、转换和加载，形成所述数据管理平台的元数据；基于信息类型进行元数据的存储以及关系和引用映射；进行业务定义，并基于业务将元数据进行分组；在每个业务分组下建立数据规则以定义数据的归属，制定目录索引以进行寻址，并对数据标注业务标签；基于设定的主题，利用业务标签对数据进行检索，并显示检索结果。根据本发明的食药监数据管理平台的搭建方法，通过对食药监的各个业务板块的信息进行汇聚、分类、清洗、主题关联、规则建模等存储和搜索应用，可对企业、产品、事件等进行针对性查询并且可一次性查看所涉及的全面信息，实现一企一档、一品一档、一人一档。

Description

食药监数据管理平台的搭建方法

技术领域

本发明涉及数据管理技术领域，具体地，涉及一种食药监数据管理平台的搭建方法。

背景技术

目前各省食品药品监督管理局的业务***多数为孤立存在的个体，不同业务处室之间虽然有密切的业务联系，但因为其业务***数据不能进行共享，不仅使得工作效率大打折扣，也不能得到及时准确的信息。

现在市面上有基于关系数据的展现，多为基于对象数据的展现，没有成熟技术能解决结构化底层数据到主题应用的连贯处理，无法做到数据与应用的解耦，无法做到数据规则的快速灵活定义、无法做到主题应用场景化的数据支撑和定义，无法做到展现应用的快速迭代。

因此，期待开发一种能够充分利用业务***数据、统一高效的食药监数据管理平台的搭建方法。

公开于本发明背景技术部分的信息仅仅旨在加深对本发明的一般背景技术的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域技术人员所公知的现有技术。

发明内容

为了解决现有技术中遇到的上述问题，本发明提出了一种食药监数据管理平台的搭建方法。

该搭建方法包括：

从异构***进行数据抽取、转换和加载，形成所述数据管理平台的元数据；

基于信息类型进行元数据的存储以及关系和引用映射；

进行业务定义，并基于业务将元数据进行分组；

在每个业务分组下建立数据规则以定义数据的归属，制定目录索引以进行寻址，并对数据标注业务标签；

基于设定的主题，利用业务标签对数据进行检索，并显示检索结果。

优选地，在基于信息类型进行元数据的存储以及关系和引用映射中，所述信息类型包括企业信息、产品信息、用户信息、执法信息。

优选地，基于表结构对元数据进行组合存储。

优选地，在元数据的存储中，对数据库进行分块。

优选地，所述对数据库进行分块包括：将读多于写与写多于读的字段分开存储在不同的表中。

优选地，所述对数据库进行分块包括：将业务模块访问关联度高于30次的与业务模块访问关联度低于10次的字段分开存储在不同的表中。

优选地，基于业务的数据分组包括行政许可、监管检查、稽查执法、检验监测、应急管理、信用管理、风险分析、公众应用。

优选地，所述数据管理平台的软件开发过程采用UML进行建模。

优选地，所述数据管理平台采用基于J2EE标准的分布式体系结构。

优选地，采用ORACLE作为数据库管理***。

本发明具有以下有益技术效果：

根据本发明的食药监数据管理平台的搭建方法，通过对食药监的各个业务板块的信息进行汇聚、分类、清洗、主题关联、规则建模等存储和搜索应用，可对企业、产品、事件等进行针对性查询并且可一次性查看所涉及的全面信息，实现一企一档、一品一档、一人一档。

本发明的方法具有其它的特性和优点，这些特性和优点从并入本文中的附图和随后的具体实施例中将是显而易见的，或者将在并入本文中的附图和随后的具体实施例中进行详细陈述，这些附图和具体实施例共同用于解释本发明的特定原理。

附图说明

通过结合附图对本发明示例性实施例进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显，其中，在本发明示例性实施例中，相同的参考标号通常代表相同部件。

图1示出根据本发明的示例性实施方案的食药监数据管理平台的搭建方法的流程图。

具体实施方式

下面将参照附图更详细地描述本发明。虽然附图中显示了本发明的优选实施例，然而应该理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

如图1所示，该方法包括步骤S1～步骤S5。

在步骤S1中，从异构***进行数据抽取、转换、加载，形成数据管理平台的元数据。

通过对来自多个信息源的数据进行抽取、转换和加载而形成数据管理平台的元数据。

异构***可包括各个层级，例如国家局、省政府、直辖市以及其他司局，从各个层级的异构***，也即多个信息源，进行数据抽取、转换和加载，形成本发明的食药监数据管理平台的元数据。

在步骤S2中，基于信息类型进行元数据的存储以及关系和引用映射。

在该步骤中，可基于表结构对元数据进行组合存储。也即，将元数据以表格形式进行存储，各个表格中包含了多种类型信息。

元数据是对数据特征的描述，组合存储是具有完整业务表达的多个元数据的存储。例如表达数据的时间、位置、目录记载方式属于元数据，而存储一特定数据在什么时间以什么目录记载的方式存储在什么位置属于组合存储。

具体地，信息类型可以包括企业信息、产品信息、用户信息、执法信息等等，也即，可以将元数据按照企业信息、产品信息、用户信息、执法信息进行维度界定。

基于上述维度，与分散的业务表进行关系和引用映射。

元数据与分散的业务表进行关系和引用映射，元数据是数据的描述和说明，业务表存储的是业务产生的数据，两者之间通过进行关系映射，使业务数据结合元数据共同表达数据应用层面完整的含义。

在步骤S3中，进行业务定义，并基于业务将元数据进行分组。

在该步骤中，实现食药监各个业务板块的分离。

在一个示例中，将食药监的业务定义为行政许可、监管检查、稽查执法、检验监测、应急管理、信用管理、风险分析、公众应用这八大分类，将基于业务的分类将元数据进行分组。一个元数据可以属于多个业务分组，例如，企业名称既在行政许可业务分组中，也在监管检查业务分组中。

在步骤S4中，在每个业务分组下建立数据规则以定义数据的归属，制定目录索引以进行寻址，并对数据标注业务标签。

每种业务由于处理流程不同、所得到的处理结果也不同，因此针对每种业务的特征建立相应的数据该规则，以定义该业务分组下数据的归属。

按业务类主流分组为行政审批、监管检查、稽查执法、应急管理、检验监测、风险分析、信用管理、公共服务八大类，行政审批数据以企业信息、证书信息、人员信息、备案信息为主载体，数据存储规则以企业、证书、人员、备案时间流转，这样下来最后企业主体信息为主。监管检查以企业类型、检查表单、检查方式、检查结果、检查标准为主要载体，这样下来最后以企业+检查结果及过程信息为主。稽查执法则以投诉线索、企业主体、问题类别、影响程度、敏感度等信息链条为存储载体，其他类同。数据规则发挥的作用则是将八大业务板块数据通过企业、产品、人员等共同维护联系在一起。

在该步骤中，对于每个业务分组下的数据还制定目录索引以进行寻址。

目录索引是指从数据存储、业务板块划分、规则引擎的定义到最后主题应用，通过一套规则记录明确解析一个主题使用哪些规则、这条规则去哪几个业务板块寻找数据，又到哪些存储表里去寻找数据的一条完整路径。

在该步骤中，对于每个业务分组下的数据定义业务标签。

当数据属于多个业务分组时，可以标注多个业务标签，并且该多个业务标签按照优先级的顺序进行排序。

例如，行政审批中企业申请许可时会有明确的企业名称，在监管检查中会发现企业名称做过变更，按优先级行政审批中企业名称高于监管检查，但实际情况可能名称变更时没在***中及时反映。因此启动监管检查环节对企业名称的同步更新，需要记录来自监管检查模块的定义，且属于跨优先级更改。

在步骤S5中，基于设定的主题，利用业务标签对数据进行检索，并显示检索结果。

标签定义是主题应用的接口，每一个主题库则被定义为有秩序的标签，从而达到主题扩展应用的目标。

通过数据查询、分析汇总、统计报表和信息发布等方式，将检索结果展现给用户。

主题库可定义，比如根据用户需求想定义一个“非洲猪瘟”主题，则需要非洲猪瘟被定义为一个标签，定义一套规则，在行政审批板块经营范围和猪肉相关作为一个数据源，在监管检查中问题描述中带有“猪”关键字的作为一个数据源，等等。从而达到上述应用效果。

以上的各个步骤，采用微服务技术架构。一个微服务一般完成某个特定的功能，比如认证管理、标签管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。

一个微服务可以发布API给其它微服务和应用客户端使用，其它微服务完成一个Web UI，运行时，每一个实例可以是一个云VM或者是Docker容器。每一个应用功能区都使用微服务完成。

另外，Web应用会被拆分成一系列简单的Web应用(比如一个对企业，一个对局端)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。每一个后台服务开放一个REST API，服务本身也采用了其它服务提供的API。这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，因此单个服务容易开发、理解和维护。

根据本发明的食药监数据管理平台通过以下技术框架实现：

1、软件开发过程采用UML进行建模；

UML(Unified Module Language)是一种可视化的建模语言，是面向对象分析与设计的国际标准。整个软件需求，设计，开发过程采用UML进行建模。

2、数据管理平台采用基于J2EE标准的分布式体系结构；

基于J2EE标准的分布式体系结构设计，一方面使应用***具有平***立性，可以在任何符合J2EE规范的应用服务器，提高***的可部署性，降低维护和管理成本。同时可以充分利用现有的成熟的J2EE技术平台积累，实现***设计的高度灵活性和扩展性。

J2EE(Java 2 Platform，Enterprise Edition)是SUN公司定义的一个开发分布式企业级应用的规范。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行(如Servlet组件在Servlet容器上运行)，容器间通过相关的协议进行通讯，实现组件间的相互调用。遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。

3、用ORACLE作为数据库管理***；

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。项目设计遵守标准的数据库表设计原则，制定数据库的命名标准，遵守数据库范式。

***平台按照其监管类型、行政相对人数据量、监管频次所产生的数据量的不同分成不同数据库，有助于提高数据库的性能，给平台提供良好的服务，可按照以下内容进行分离原则对数据库进行分块：

(一)读写分离

读写分离是指读多写少的字段与写多读少的字段分开存放于不同的表。按照磁盘的工作原理，磁盘是以扇区为单位存放数据的，并且有写缓冲、排队、延迟写入的特点。数据库是以记录为单位的，每次访问，总是将整行记录读入缓冲区，再依命令所需的字段从中筛选数据，组成返回的记录行。读写分离原则能显著改善磁盘和记录的缓存性能。

(二)高频与低频字段分离

高频字段是指访问较频繁的字段，低频字段是指访问频度较低的字段。不管是高频字段还是低频字段，数据库总是读取整行记录，然后筛选。命令中不访问到的字段，同样要先读入内存。高低频分开存放，能减少记录行读入的字节数(写入也一样)，减少不必要的读写。如果部署分布式数据库，按这个原则作垂直划分，其效果比单机数据库的效果更明显。

4、基于WebService，WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的平台；

5、基于XML交互；

XML是Web服务规范标准的基础。XML具有强大的的自描述能力，在各种层次、各种技术路线的***间的数据交换时发挥巨大的作用；

6、基于AJAX交互；

随着web2.的兴起，以ajax为技术核心，使用xml和动态javascript大幅度改良browser的易用性已经成为主流，基本上可以达到接近传统c/s模式或Activex模式的易用性，同时又具备高度的安全性和可维护性。Ajax技术的应用，可以使传统的web方式的应用的交互性达到接近甚至超过桌面应用。

根据本发明所提出的方法搭建的食药监数据管理***的数据架构相对于业务加构和应用架构，处于基础和核心地位。因为信息***支撑下的业务运作状况，是通过信息***中的数据反映出来的，数据信息***管理的重要资源。因此构建总体架构时，首先要考虑数据架构对当前业务的支持。理想的总体架构规划逻辑上是数据驱动的，即：首先根据业务架构分析定义数据架构；然后根据数据架构结合业务功能定义应用架构；最后根据应用架构与数据架构的定义，来设计技术架构。

本发明的总体数据架构实现了以下有益技术效果：

实现了数据***的资源整合、数据资源的共享；增强信息资源架构的稳定性；通过大数据分析，为项目业务提供信息支持；通过设定标准规范、业务管理流程，能够规范数据的定义、存储、使用、传输、交换，使得数据采集更加规范、数据传输更加准确高效，数据使用更加安全方便。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims

1.一种食药监数据管理平台的搭建方法，其特征在于，包括：

基于信息类型进行元数据的存储以及关系和引用映射；

进行业务定义，并基于业务将元数据进行分组；

基于设定的业务主题，利用业务标签对数据进行检索，并显示检索结果。

2.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，在基于信息类型进行元数据的存储以及关系和引用映射中，所述信息类型包括企业信息、产品信息、用户信息、执法信息。

3.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，基于表结构对元数据进行组合存储。

4.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，在元数据的存储中，对数据库进行分块。

5.根据权利要求4所述的食药监数据管理平台的搭建方法，其特征在于，所述对数据库进行分块包括：将读多于写与写多于读的字段分开存储在不同的表中。

6.根据权利要求4所述的食药监数据管理平台的搭建方法，其特征在于，所述对数据库进行分块包括：将业务模块访问关联度高于30次的与业务模块访问关联度低于10次的字段分开存储在不同的表中。

7.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，基于业务的数据分组包括行政许可、监管检查、稽查执法、检验监测、应急管理、信用管理、风险分析、公众应用。

8.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，所述数据管理平台的软件开发过程采用UML进行建模。

9.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，所述数据管理平台采用基于J2EE标准的分布式体系结构。

10.根据权利要求1所述的食药监数据管理平台的搭建方法，其特征在于，采用ORACLE作为数据库管理***。