CN114428777A - 数据库扩展方法和系统 - Google Patents

Abstract

本发明公开一种数据库扩展方法和系统，其中方法包括：分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表。通过先分析确定与五种元数据的基础属性表和扩展属性表的关系，然后在数据库中增加相应的基础属性表和扩展属性表即可，扩展比较简单。

Description

数据库扩展方法和系统

技术领域

本发明属于数据库技术领域，尤其涉及一种数据库扩展方法和系统。

背景技术

现有技术中，关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。

1.存储方式：传统的关系型数据库采用表格的储存方式，数据以行和列的方式进行存储，要读取和查询都十分方便。

2.存储结构：关系型数据库按照结构化的方法存储数据，每个数据表都必须对各个字段定义好(也就是先定义好表的结构)，再根据表的结构存入数据，这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了，所以整个数据表的可靠性和稳定性都比较高，但带来的问题就是一旦存入数据后，如果需要修改数据表的结构就会十分困难。

3.存储规范：关系型数据库为了避免重复、规范化数据以及充分利用好存储空间，把数据按照最小关系表的形式进行存储，这样数据管理的就可以变得很清晰、一目了然，当然这主要是一张数据表的情况。如果是多张表情况就不一样了，由于数据涉及到多张数据表，数据表之间存在着复杂的关系，随着数据表数量的增加，数据管理会越来越复杂。

4.扩展方式：由于关系型数据库将数据存储在数据表中，数据操作的瓶颈出现在多张数据表的操作中，而且数据表越多这个问题越严重，如果要缓解这个问题，只能提高处理能力，也就是选择速度更快性能更高的计算机，这样的方法虽然可以一定的拓展空间，但这样的拓展空间一定有非常有限的，也就是关系型数据库只具备纵向扩展能力。

5.查询方式：关系型数据库采用结构化查询语言(即SQL)来对数据库进行查询，SQL早已获得了各个数据库厂商的支持，成为数据库行业的标准，它能够支持数据库的CRUD(增加，查询，更新，删除)操作，具有非常强大的功能，SQL可以采用类似索引的方法来加快查询操作。

6.规范化：在数据库的设计开发过程中开发人员通常会面对同时需要对一个或者多个数据实体(包括数组、列表和嵌套数据)进行操作，这样在关系型数据库中，一个数据实体一般首先要分割成多个部分，然后再对分割的部分进行规范化，规范化以后再分别存入到多张关系型数据表中，这是一个复杂的过程。好消息是随着软件技术的发展，相当多的软件开发平台都提供一些简单的解决方法，例如，可以利用ORM层(也就是对象关系映射)来将数据库中对象模型映射到基于SQL的关系型数据库中去以及进行不同类型系统的数据之间的转换。

7.事务性：关系型数据库强调ACID规则(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability))，可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作，而且可以充分满足数据库操作的高性能和操作稳定性的要求。并且关系型数据库十分强调数据的强一致性，对于事务的操作有很好的支持。关系型数据库可以控制事务原子性细粒度，并且一旦操作有误或者有需要，可以马上回滚事务。

8.读写性能：关系型数据库十分强调数据的一致性，并为此降低读写性能付出了巨大的代价，虽然关系型数据库存储数据和处理数据的可靠性很不错，但一旦面对海量数据的处理的时候效率就会变得很差，特别是遇到高并发读写的时候性能就会下降的非常厉害。

9.授权方式：关系型数据库常见的有Oracle，SQLServer，DB2，Mysql，除了Mysql大多数的关系型数据库如果要使用都需要支付一笔价格高昂的费用，即使是免费的Mysql性能也受到了诸多的限制。

关系型数据库设计的过程可大体分为四个时期七个阶段。

(1)用户需求分析时期，主要是了解和分析用户对数据的功能需求和应用需求，是整个设计过程的基础，事关整个数据库应用系统设计的成败。

(2)数据库设计时期，主要是将用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的数据模型，可用实体—联系模型来表示，然后将其转换为已选好的关系型数据库管理系统RDBMS所支持的一组关系模式并为其选取一个适合应用环境的物理结构，包括存储结构和存取方法。

(3)数据库实现时期，包括数据库结构创建阶段和应用行为设计与实现阶段，是根据数据库的物理模型创建数据库、创建表、创建索引、创建聚簇等。

(4)数据库运行与维护阶时期，最后一个阶段则是数据库应用系统经过试运行后即可投入正式运行。

在进行关系型数据库的设计过程中，要遵循以下几个原则，借此可以提高数据库的存储效率、数据完整性和可扩展性。

1.命名规范化

在概念模型设计中，对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中，指定学生Sstudent，专指本科生，相关的属性有：学号、姓名、性别、出生年月等，及每个属性的类型、长度、取值范围等都要进行确定，这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。

2.数据的一致性和完整性

在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性，用check、default、null、主键和外键约束来实现。

3.数据冗余

数据库中的数据应尽可能地减少冗余，这就意味着重复数据应该减少到最少。例如：若一个部门职员的电话存储在不同的表中，假设该职员的电话号码发生变化时，冗余数据的存在就要求对多个表进行更新操作，若某个表不幸被忽略了，那么就会造成数据不一致的情况。所以在数据库设计中一定要尽可能存在少地冗余。

4.范式理论

在关系数据库设计时，一般是通过设计满足某一范式来获得一个好的数据库模式，通常认为3NF在性能、扩展性和数据完整性方面达到了最好的平衡，因此,一般数据库设计要求达到3NF，消除数据依赖中不合理的部分，最终实现使一个关系仅描述一个实体或者实体间一种联系的目的。

发明人发现：上述数据管理模式至少存在以下缺陷：可扩展性差。当已确定的业务需求改变时，传统信息化方式在建设时会提前预留空间备用，但预留的空间总是有限的，永远也无法解决现实中无限变化的业务需求。一旦业务需求发生新的变化，对现有信息系统的改造会造成大量的混乱和错误，必须对信息系统重新设计，推倒重来才能适应新的业务需求。这导致传统信息系统的数据管理模式扩展性极差。

发明内容

本发明实施例旨在至少解决上述技术问题之一。

第一方面，本发明实施例提供一种数据库扩展方法，包括：分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

第二方面，本发明实施例提供一种数据库扩展系统，包括：分析程序模块，配置为分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；以及更新程序模块，配置为当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

第三方面，本发明实施例提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明上述任一项数据库扩展方法。

第四方面，本发明实施例提供一种存储介质，所述存储介质中存储有一个或多个包括执行指令的程序，所述执行指令能够被电子设备(包括但不限于计算机，服务器，或者网络设备等)读取并执行，以用于执行本发明上述任一项数据库扩展方法。

第五方面，本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括存储在存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述任一项数据库扩展方法。

本发明实施例根据客户的扩展需求，将其整合至五类元数据的基础属性表和扩展属性表中，由于五类元数据的框架囊括了各种待扩展的属性，可以通过元数据之间的灵活组合实现对扩展需求的建模和描述。先分析确定客户的扩展需求与五种元数据的基础属性表和扩展属性表的关系，然后在数据库中增加相应的基础属性表和扩展属性表即可，扩展比较简单，五类元数据的框架可以灵活应对各种扩展需求。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的数据库扩展方法的一实施例的流程图；

图2为本发明的数据库扩展方法的另一实施例的流程图；

图3a、图3b、图3c、图3d、图3e和3f为本发明一实施例提供的一种数据库扩展方法的各元数据示意图；

图4为本发明的数据库扩展系统的框图；

图5为本发明的电子设备的一实施例的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

在本发明中，“模块”、“装置”、“系统”等指应用于计算机的相关实体，如硬件、硬件和软件的组合、软件或执行中的软件等。详细地说，例如，元件可以、但不限于是运行于处理器的过程、处理器、对象、可执行元件、执行线程、程序和/或计算机。还有，运行于服务器上的应用程序或脚本程序、服务器都可以是元件。一个或多个元件可在执行的过程和/或线程中，并且元件可以在一台计算机上本地化和/或分布在两台或多台计算机之间，并可以由各种计算机可读介质运行。元件还可以根据具有一个或多个数据包的信号，例如，来自一个与本地系统、分布式系统中另一元件交互的，和/或在因特网的网络通过信号与其它系统交互的数据的信号通过本地和/或远程过程来进行通信。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”，不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明实施例提供一种数据库扩展方法，该方法应用于数据库。

请参考图1，其示出了本发明一实施例提供的一种数据库扩展方法。

如图1所示，在步骤101中，分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；

在步骤102中，当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

在本实施例中，对于步骤101，通过分析客户的功能扩展需求，将客户的功能扩展需求对应到至少一个项目和至少一个项目对应的各属性表，实现客户功能扩展需求的数据化，其中，属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据。例如，客户的功能扩展需求为新增一个客服部门，首先需要将该客服部门拆分至对应于五类元数据中至少一类元数据的项目，例如客服部门有哪些人对应自然人人元数据，客服部门组织架构对应组织元数据，客服部门办公地址或者其他地址信息对应地址元数据，客服部门需要哪些东西对应物元数据，客服部门需要处理哪些事对应事元数据，这样就可以将客户需求拆分成多个项目，然后具体地在五类元数据中增加相应表即可完成对于客服部门的扩展。其中，基础属性表通常只用于记录基础信息，例如自然人元数据的基础属性表可能只包括人名和性别，扩展属性表用于记录扩展属性信息，例如人的联系方式、职称、履历、证书，与其他人之间的关系等，每一项都可以记录至对应的扩展属性表中，本申请在此没有限制。

之后，对于步骤102，当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表。例如，数据库中自然人元数据之前并没有履历扩展属性表，本次项目中需要新增履历扩展属性表，则可以在自然人元数据下扩展出履历扩展属性表用于新项目记录人的履历信息，同理，如果数据库前没有物元数据的基础属性表和相应的各扩展属性表，而本次的新项目需要建立物元数据的基础属性表和相应的各扩展属性表，则在数据库中新增相应的基础属性表和扩展属性表即可，本申请在此没有限制。

本实施例的方法通过先分析确定客户的扩展需求对应的至少一个项目与五种元数据的基础属性表和扩展属性表的关系，然后在数据库中增加相应的基础属性表和扩展属性表即可，扩展比较简单，由于五类元数据的框架囊括了各种待扩展的属性，可以通过元数据之间的灵活组合实现对扩展需求的建模和描述，因此可以灵活应对各种扩展需求。

其中，在一些可选的实施例中，各类元数据的描述如下：

(1)自然人元数据

自然人，在任何一个信息化系统中都是重要的因素，也是各个系统数据共享时重复概率极高的因素。如何能实现人的基础信息数据共享，如何能实现人的数据信息准确、可信、高时效。同时，如何应对组织机构调整及人员调整中的快速、灵活的变化，都是应用服务系统对人的元素提出的挑战。

自然人员管理分为人员基础信息和扩展信息管理，满足机构调整人员变化是系统中人员的灵活更改。

自然人管理需要完成人员不同形式的录入，要满足不同人员各种相关属性(如：电话、称谓、职称等)录入属性的随时增减，同时还要满足复合属性(某一属性有多个对应内容，如电话、证书等)的信息录入，便于系统全面的对于人员信息的收集管理。

(2)地址元数据

地址是各个系统都要涉及到的，而且是重要的系统元素，随着系统应用的推广使用，系统中有的是结构化数据信息，有的是半结构化的非标准化信息。这些数据的应用难以满足、适应系统灵活可变的数据应用。因此，本系统设计采用地址基础信息和扩展信息进行管理。

(3)组织元数据

组织即由若干个人或群体所组成的、有共同目标和一定边界的社会实体。它包含三层意思：

1)组织必须是以人为中心，把人、财、物合理配合为一体，并保持相对稳定而形成的一个社会实体。

2)组织必须具有为本组织全体成员所认可并为之奋斗的共同目标。

3)组织必须保持一个明确的边界，以区别于其他组织和外部环境。

组织结构需要按照常用机构、部门进行设置录入，同时要满足机构改革对于组织结构的灵活增减和变更，以及临时工作机构设置要求。因此，本系统设计采用组织基础信息和扩展信息进行管理。

(4)物元数据

物是指纳入基础信息管理平台的客观事物。物的范围极其广泛，应用极其复杂。如今大数据、物联网的时代，物是信息管理的主体，既是管理的对象也是被管理的对象。物物相连，万物互联，物是核心和基础。

基础信息管理平台是将万物纳入物的集合，以标识号进行识别，同时进行物的本质描述。物的管理采用基础信息和扩展信息方式进行管理。物的使用需要根据用户的业务应用进行灵活应用即可。物是不变的，应用是可变的。

(5)事元数据

事是指质量空间分布的随时变化。因为物质是质量空间分布，所以事也可定义为：物质随时间的变化。事涉及的内容比较广泛。一般指社会和自然界上的事情，事务，现象，情况等。

基础信息管理平台的事，将是根据用户的实际应用和需求，进行的信息化管理、信息化分析、信息化决策支持等一系列行为。

事同样也是进入数据库，采用基础信息和扩展信息进行管理，以标识号进行表示，以时间为序，进行可变信息管理。事是“人、地、物、组织”其它四要素的应用和延申。

请参考图2，其示出了本申请一实施例提供的另一种数据库扩展方法的流程图。该流程图主要是对图1的附加步骤进一步限定的流程图。

如图2所示，在步骤201中，当所述至少一个项目为所述数据库中的旧项目时，比较所述至少一个项目与所述旧项目的各基础属性表和对应的各扩展属性表；

在步骤202中，将所述至少一个项目中的、未包含在所述旧项目的基础属性表和/或扩展属性表增加至所述数据库中。

在本实施例中，对于步骤201，通过比较至少一个项目与旧项目的各基础属性表和各扩展属性表，然后在步骤202中，将至少一个项目中的、未包含在所述旧项目的基础属性表和/或扩展属性表增加至所述数据库中即可。例如，对于客服部门这个扩展需求，以前的项目已经建立了对应于多个元数据的基础属性表和扩展属性表，现在的项目只是在以前的基础上再增加自然人元数据的人关系扩展属性表，则只需要新增自然人元数据下的人关系扩展属性表即可。

本实施例的方法通过在对于旧项目的扩展时，比较至少一个项目与旧项目的基础属性表和扩展属性表，然后将未包含在旧项目中的基础属性表和/或扩展属性表加进来即可，从而可以很容易实现旧项目的扩展。

在一些可选的实施例中，各元数据的基础属性表和扩展属性表的具体介绍如下：

自然人基础属性信息

1.自然人基础(以下简称“人基础”)：标识号、关联号(主题)、登记出生日期(农历、阴历：年月日时分)、籍贯(关联号地址)、备注、录入人、录入时间；

2.性别：识别号、关联号(人基础)、性别(男、女、变性、双性)、起止时间；

说明：以上“识别号”均为自动生成。

自然人扩展属性信息

1.通讯：识别号、关联号(人基础)、通讯号码(电话、微信、QQ、博客、邮件、网站、视频号等)、号码说明；

2.地址：识别号、关联号(人基础)、关联号(地址中最基础单元)、地址描述、起止时间(设计时考虑2个字段)；

3.职称：识别号、关联号(人基础)、职称名称(技术员、工程师、教授、注册建造师、注册会计师…)、职称描述、职称起止时间；

4.履历：识别号、关联号(人基础)、关联号(组织基础)、履历起止时间、证明人(关联人员基础库)、履历说明；

5.证书：识别号、关联号(人基础)、关联号(档案)、证书名称、证书编号、证书描述、起止时间；

6.人关系：识别号、关联号(人基础)、关系描述(父子、岳父、夫妻、子女、叔侄、同学、牌友、狱友、同事…可选择多项)、起止时间。

地址基础属性信息

1.地址基础：标识号、关联号(主集合)、代表名称(由行政命名与称谓中的一项重复)、描述

地址扩展属性信息

2.称谓：识别号、关联号(主集合)、称谓(行政、俗称、简称等)、称谓描述、称谓起止时间；

3.上层关系：识别号、关联号(主集合)、上层关联号(地址基础)、描述；

4.省、市自治区、直辖市：识别号、关联号(地址基础)、称谓；

5.市、县：识别号、关联号(地址基础)、称谓；

6.乡镇、街道：识别号、关联号(地址基础)、称谓；

7.门牌号码：识别号、关联号(地址基础)、门牌号码；

8.企事业单位：识别号、关联号(地址基础)、名称、名称描述；

9.关系表：关联号、关系说明(说明地址所属的上下级直接关联关系)。

说明：以上“识别号”均为自动生成；4、5、6可以从第3项中查询生成。

组织基础属性

1.组织基础：识别号、名称、描述、备注、录入人、录入时间；

2.称谓：识别号、关联号(组织基础)、称谓、称谓描述、称谓描述起止时间；

组织扩展属性

1.地址：识别号、关联号(所属地址的最小基本单元)、有效时间；

2.通讯：识别号、关联号(组织基础)、通讯号码、号码说明；注：通讯号码有“电话、传真、邮箱、网站、公众号、博客、视频号等”；

3.证书：识别号、关联号(组织基础)、关联号(档案基础)、证书名称、证书描述；注：机构批文、机构代码证、机构编制管理证、获奖证书、质资证书等；

4.上层关系表：识别号、关联号(组织基础)、关联号(上层组织基础)、关系说明。

5.组织分类：识别号、关联号(组织基础)、关联号(组织分类)；

6.组织描述：识别号、分类、标准(来源、依据)、描述；

说明：分类来源于国家行政各种相关指导文件、地方文件、日常约定等，行业、规模、地域，一个组织可有多个分类选择(多条分类记录)，便于检索。

物集合基础属性

1.基础：识别号、关联号(主集合)、物的名称、物的描述；

物集合扩展属性

1.规格型号：识别号、关联号(主集合)、生产日期、单价；

2.用途：识别号、关联号(主集合)、单位、数量、使用人、用途描述；

3.价值：识别号、关联号(主集合)、数量、价格、描述；

4.时间：识别号、关联号(物集合)、采购时间、售后服务时间。

事集合基础属性

1.基础：识别号、关联号(主集合)、事项名称、事项描述、备注。

事集合扩展属性

1.事项类别：识别号、关联号(主集合)、类别名称、标准(来源、依据、审批文件等)；

2.事项时间：识别号、关联号(主集合)、事项期限(开始、结束时间)、备注；

3.事项资金：识别号、关联号(主集合)、资金金额、资金来源、资金描述等；

4.事项干系人：识别号、关联号(主集合)、事项法人(自然人集合识别号)、事项干系人(自然人集合识别号)、身份证号(身份证照片)、人员描述、备注；

5.事项干系地址：识别号、关联号(主集合)、关联号(地址集合识别号)、建设地点(详细地址)、建设规模(面积)，描述等。

6.事项干系组织：识别号、关联号(主集合)、事项干系组织(组织集合识别号)、事项干系组织描述、干系组织证照(营业执照、证书等)；

7.事项干系物：识别号、关联号(主集合)、事项干系物(物集合识别号)、事项干系物描述、干系物依据(调拨单等)。

本实施例的方法通过采用趋于自然的对象数据分析，抽象出元数据的共性、自然属性，更加细粒度的细化、分析，实现了数据的灵活组合对对象的描述。既便于现实的业务应用，更便于变化状态下大数据的挖掘分析。为决策应用提供强有力的基础数据支撑。

在一些可选的实施例中，所述基础属性表和所述扩展属性表具有数据库时间戳，用于记录表中各条数据的更新时间。通过对属性表的更新时间进行记录，从而可以根据更新时间获得想要的属性表。

在一些可选的实施例中，在比较所述至少一个项目与所述旧项目的各基础属性表和对应的各扩展属性表之后，所述方法还包括：若所述至少一个项目与所述旧项目中存在彼此记录数据不同的基础属性表和/或扩展属性表，在数据库中仅保留所述至少一个项目的时间戳最新的数据对应的基础属性表和/或扩展属性表。当属性表存在彼此记录不同的同一数据的多次更新记录时，使用其中最新的更新记录进行与至少一个项目的比对，然后保留最新的。

在进一步可选的实施例中，所述分析用户的功能扩展需求包括：获取用户的功能扩展需求的文字表述，对所述文字表述进行语义分析，基于语义分析的结果确定待扩展的至少一个项目以及与所述至少一个项目对应的各属性表。通过自动化处理的手段分析用户的功能扩展需求。

下面对通过描述发明人在实现本发明的过程中遇到的一些问题和对最终确定的方案的一个具体实施例进行说明，以使本领域技术人员更好地理解本申请的方案。

发明人在实现本申请的过程中发现现有技术中存在的缺陷主要是由以下原因导致的：由于传统信息系统的数据管理模式中，以确定的业务需求为出发点，在对物理对象的数字化过程中确定了对象边界导致的。

由于划定了对象的边界，而不同业务之间的需求不同，使得不同信息系统之间的数据相互独立，无法整合相互的数据资源；由于划定了对象的边界，使得业务需求改变时，整个信息系统需要重新设计，同时物理对象的变化过程也就无法得以记录和展现。

这些缺陷所导致的问题是该领域长期存在的问题。

本申请实施例的超融合数据库采用趋于自然的对象元数据分析方法，重新再造数据结构，通过抽象出元数据的共性、自然属性等，细分人、地、事、物、组织五类最基础的元数据，独立、简化出原来复杂的结构化数据，然后根据“事”的应用需求再组合五类基础数据集的元数据，形成对自然对象的再认识。本申请实施例不是傲慢的用信息化手段展示人类认识自然的结果，而是以信息化作为工具，推动人类逐渐认识自然的过程。最终，本申请实施例的目的是达到对自然对象“全息、全生命周期、全生态”的认知。

这一点和生物界的进化非常相似，生物界都是沿着从简单到复杂有机体的一个方向去进化。而超融合数据库，其实也是这样的一个思路，从关系数据库到各种各样的专用数据库，又到趋于自然对象元数据再造，最终发展成了一个复杂的新物种超融合基础信息数据管理平台。

随着大数据作为战略资源的地位日益凸显，人们越来越强烈地意识到制约大数据发展最大的短板就是对数据本身的再认识。趋于自然的、无边界的元数据治理以及元数据驱动应用的架构体系，实现大数据的基础数据信息管理的总体建设，提供了一种大数据治理复杂系统的新思维和新手段。

纵观软件定制开发应用的发展，虽逐步在适应大数据、互联网、物联网等技术上的适应性应用定制开发，但仍然无法真正满足实际应用需求。

为了提高软件系统的实用性、适应性、可扩展性，我们将采用“元数据驱动平台应用”的架构来实现基础信息平台的总体建设。

每个应用都可以分为元数据和元数据驱动的应用。因此，我们将从元数据出发，抽象出元数据的共性、自然属性等，进行元数据资源的建设。包括人、地、事、物、组织“智慧城市五要素”基础元数据。

元数据是多维度、空间性资源数据，用户的实际应用，是元数据驱动的不同维度、不同空间对元数据应用的、面向服务的数据应用平台。

当系统的数据应用扩展时，通过编辑元数据描述的组织结构说明，实现应用组件对数据的变更应用处理，同时增加元数据的时间戳履历；当系统的功能扩展时，通过定制元数据驱动的功能扩展插件的形式实现，使基于平台定制的系统具有较强的可扩展性。

图3a示出了本申请一实施例的平台功能规划拓扑图，图3b、图3c、图3d、图3e和图3f分别示出了自然人元数据、地址元数据、组织元数据、物元数据和事元数据的具体功能规划图。其中，所有录入信息均包括“录入人、录入时间、备注”属性。

基本要求

日志：登录、浏览、查询、增加、修改。

每条记录的识别由系统自动生成(加一)，作为该记录的唯一识别。

备注、录入人(系统自动将当前操作者记录)、录入时间(当前系统时间自动记录)为每条记录必有的标准属性、录入依据(录入数据资料或实体数据)。

交互输入时尽量采用下拉菜单或列项选择形式，选项多时可用首字母拼音索引；手工输入项尽量采用标准格式辅助输入(如时间格式)，保障输入数据的规范；根据正在录入内容提示相关已录入信息。

录入的实体数据(过程资料记录，包括照片、视频、录音等)。

主集合结构表如表1所示：

主题：识别号、名称、描述、录入依据。

自然人元数据，参见图3b。

自然人集合信息录入

1、自然人信息录入方式：录入除了现有的单个输入、批量导入以外，增加图片识别、扫描识别录入方式。

2、自然人信息属性：由“基础属性”和扩展属性组成，基本属性固定无变化；“扩展属性”，因人员情况不同，有些填写，有些不填写；填写的可能属性需要增加。因此，录入的人员信息属性需要能够实现灵活添加和删除。

3、尽可能实现下拉式选项录入，充分利用格式限制保证输入数据的规范(如日期)，支持由其他文字复制粘贴。

4、比对留档：录入后的人员信息要求把图、表上传，做资料比对和档案留存。

表2-1：自然人基础信息表

表2-2：自然人扩展属性信息表-通讯信息表

地址元数据，参见图3c。

地址信息结构一般遵循YZT0127-2006邮政地址信息数据结构，地址是位置信息，表述时优先选择位置信息(如：道路、门牌号等)，所涉及地标物、组织。

例：国、省(直辖市、自治区、州、特区)、市(地、区)、县乡、村镇、门牌。

表2-3：地址基础信息表

表2-4：地址扩展信息表-称谓信息表

组织元数据，参见图3d。

1.组织机构：建议采用树形目录方式，直观、清晰的表示出组织结构的层级关系。平台组织机构建设建议采用手动录入方式进行，工作量小且随时核查比对。

2.组织信息录入：鉴于组织机构信息较少，建议采用单个输入方式进行录入或是图片识别、扫描识别对应录入系统内表格。同时，录入后要求把图表上传，做资料比对和档案留存。

3.组织机构属性：建议分为“基础属性”，多数情况下变化不大；“扩展属性”，需要能够实现灵活添加和删除。基本属性，尽可能实现下拉式选项录入；扩展属性，支持复制粘贴。

表2-5：组织基础属性信息表

表2-6：组织扩展属性信息-称谓信息表

物元数据，参见图3e。

1、物集合信息录入方式：录入除了现有的单个输入、批量导入以外，增加图片识别、扫描识别录入方式。

2、物集合信息属性：由“基础属性”和扩展属性组成，基本属性固定无变化；“扩展属性”，因物集合情况不同，有些填写，有些不填写；填写的可能属性需要增加。因此，录入的物的信息属性需要能够实现灵活添加和删除。

3、尽可能实现下拉式选项录入，充分利用格式限制保证输入数据的规范，支持由其他文字复制粘贴。

4、比对留档：录入后物的信息要求把图、表上传，做资料比对和档案留存。

表2-7：物的基础属性信息表

表2-8：物的扩展属性信息-称谓信息表

事元数据，参见图3f。

1、平台录入事集合主要是行政事业单位的事务信息和各类工程项目信息。

2、事集合信息录入方式：录入除了现有的单个输入、批量导入以外，增加图片识别、扫描识别录入方式。

3、事集合信息属性：由“基础属性”和扩展属性组成，基本属性固定无变化；“扩展属性”，因事集合情况不同，有些填写，有些不填写；填写的可能属性需要增加。因此，录入的事集合信息属性需要能够实现灵活添加和删除。

4、尽可能实现下拉式选项录入，充分利用格式限制保证输入数据的规范，支持由其他文字复制粘贴。

5、比对留档：录入后的事集合信息要求把表格、图片上传，做资料比对和档案留存。

表2-9：事集合基础属性信息表

表2-10：事集合扩展属性信息-资金信息表

本申请实施例的数据接口执行标准参照GB/T38672—202《信息技术大数据接口基本要求》。

大一统的基础数据平台，旨在解决带有边界建设的数据资源系统，追求趋于自然属性的元数据构建的灵活可变的、开放共享的、准确高时效的、安全可信的大一统基础数据平台。为日趋复杂变化的应用服务提供底层的基础数据支撑。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作合并，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

请参考图4，其示出了本发明一实施例提供的数据库扩展系统的框图。

如图4所示，数据库扩展系统400，包括分析程序模块410、更新程序模块420。

其中，分析程序模块410，配置为分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；

更新程序模块420，配置为当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

应当理解，图4中记载的诸模块与参考图1和图2中描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征以及相应的技术效果同样适用于图4中的诸模块，在此不再赘述。

值得注意的是，本公开的实施例中的模块并不用于限制本公开的方案，例如更新程序模块，也可以描述为当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表的模块。另外，还可以通过硬件处理器来实现相关功能模块，例如更新程序模块也可以用处理器实现，在此不再赘述。

在一些实施例中，本发明实施例提供一种非易失性计算机可读存储介质，所述存储介质中存储有一个或多个包括执行指令的程序，所述执行指令能够被电子设备(包括但不限于计算机，服务器，或者网络设备等)读取并执行，以用于执行本发明上述任一项数据库扩展方法。

在一些实施例中，本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述任一项数据库扩展方法。

在一些实施例中，本发明实施例还提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行数据库扩展方法。

图5是本申请另一实施例提供的执行数据库扩展方法的电子设备的硬件结构示意图，如图5所示，该设备包括：

一个或多个处理器510以及存储器520，图5中以一个处理器510为例。

执行数据库扩展方法的设备还可以包括：输入装置530和输出装置540。

处理器510、存储器520、输入装置530和输出装置540可以通过总线或者其他方式连接，图5中以通过总线连接为例。

存储器520作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的数据库扩展方法对应的程序指令/模块。处理器510通过运行存储在存储器520中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例数据库扩展方法。

存储器520可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据数据库扩展设备的使用所创建的数据等。此外，存储器520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器520可选包括相对于处理器510远程设置的存储器，这些远程存储器可以通过网络连接至数据库扩展设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置530可接收输入的数字或字符信息，以及产生与数据库扩展设备的用户设置以及功能控制有关的信号。输出装置540可包括显示屏等显示设备。

所述一个或者多个模块存储在所述存储器520中，当被所述一个或者多个处理器510执行时，执行上述任意方法实施例中的数据库扩展方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种数据库扩展方法，包括：

分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；

当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

2.根据权利要求1所述的方法，还包括：

当所述至少一个项目为所述数据库中的旧项目时，比较所述至少一个项目与所述旧项目的各基础属性表和对应的各扩展属性表；

将所述至少一个项目中的、未包含在所述旧项目的基础属性表和/或扩展属性表增加至所述数据库中。

3.根据权利要求2所述的方法，其中，所述基础属性表和所述扩展属性表具有数据库时间戳，用于记录表中各条数据的更新时间。

4.根据权利要求3所述的方法，其中，在比较所述至少一个项目与所述旧项目的各基础属性表和对应的各扩展属性表之后，所述方法还包括：

若所述至少一个项目与所述旧项目中存在彼此记录数据不同的基础属性表和/或扩展属性表，在数据库中仅保留所述至少一个项目的时间戳最新的数据对应的基础属性表和/或扩展属性表。

5.根据权利要求1-4中任一项所述的方法，其中，所述分析用户的功能扩展需求包括：

获取用户的功能扩展需求的文字表述，对所述文字表述进行语义分析，基于语义分析的结果确定待扩展的至少一个项目以及与所述至少一个项目对应的各属性表。

6.一种数据库扩展系统，包括：

分析程序模块，配置为分析用户的功能扩展需求，确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表，所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表，所述多类元数据包括：自然人元数据、组织元数据、地址元数据、物元数据和事元数据；

更新程序模块，配置为当所述至少一个项目为新项目时，在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表，其中，所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。

7.根据权利要求6所述的系统，还包括：

比较程序模块，配置为当所述至少一个项目为所述数据库中的旧项目时，比较所述至少一个项目与所述旧项目的各基础属性表和对应的各扩展属性表；

增加程序模块，配置将所述至少一个项目中的、未包含在所述旧项目的基础属性表和/或扩展属性表增加至所述数据库中。

8.根据权利要求7所述的系统，其中，所述基础属性表和所述扩展属性表具有数据库时间戳，用于记录表中各条数据的更新时间。

9.根据权利要求8所述的系统，还包括：

时间戳处理程序模块，配置为若所述至少一个项目与所述旧项目中存在彼此记录数据不同的基础属性表和/或扩展属性表，在数据库中仅保留所述至少一个项目的时间戳最新的数据对应的基础属性表和/或扩展属性表。

10.根据权利要求6-9中任一项所述的系统，其中，所述分析程序模块进一步配置为：获取用户的功能扩展需求的文字表述，对所述文字表述进行语义分析，基于语义分析的结果确定待扩展的至少一个项目以及与所述至少一个项目对应的各属性表。

Images