跨领域数据库的整合、迁移方法和系统与流程

文档序号:30065409发布日期:2022-05-18 00:49阅读:133来源:国知局
跨领域数据库的整合、迁移方法和系统与流程

1.本发明属于数据库技术领域,尤其涉及一种跨领域数据库的整合、迁移方法和系统。


背景技术:

2.现有技术中,关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。用户通过查询来检索数据库中的数据,而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型,而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。
3.1.存储方式:传统的关系型数据库采用表格的储存方式,数据以行和列的方式进行存储,要读取和查询都十分方便。
4.2.存储结构:关系型数据库按照结构化的方法存储数据,每个数据表都必须对各个字段定义好(也就是先定义好表的结构),再根据表的结构存入数据,这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了,所以整个数据表的可靠性和稳定性都比较高,但带来的问题就是一旦存入数据后,如果需要修改数据表的结构就会十分困难。
5.3.存储规范:关系型数据库为了避免重复、规范化数据以及充分利用好存储空间,把数据按照最小关系表的形式进行存储,这样数据管理的就可以变得很清晰、一目了然,当然这主要是一张数据表的情况。如果是多张表情况就不一样了,由于数据涉及到多张数据表,数据表之间存在着复杂的关系,随着数据表数量的增加,数据管理会越来越复杂。
6.4.扩展方式:由于关系型数据库将数据存储在数据表中,数据操作的瓶颈出现在多张数据表的操作中,而且数据表越多这个问题越严重,如果要缓解这个问题,只能提高处理能力,也就是选择速度更快性能更高的计算机,这样的方法虽然可以一定的拓展空间,但这样的拓展空间一定有非常有限的,也就是关系型数据库只具备纵向扩展能力。
7.5.查询方式:关系型数据库采用结构化查询语言(即sql)来对数据库进行查询,sql早已获得了各个数据库厂商的支持,成为数据库行业的标准,它能够支持数据库的crud(增加,查询,更新,删除)操作,具有非常强大的功能,sql可以采用类似索引的方法来加快查询操作。
8.6.规范化:在数据库的设计开发过程中开发人员通常会面对同时需要对一个或者多个数据实体(包括数组、列表和嵌套数据)进行操作,这样在关系型数据库中,一个数据实体一般首先要分割成多个部分,然后再对分割的部分进行规范化,规范化以后再分别存入到多张关系型数据表中,这是一个复杂的过程。好消息是随着软件技术的发展,相当多的软件开发平台都提供一些简单的解决方法,例如,可以利用orm层(也就是对象关系映射)来将数据库中对象模型映射到基于sql的关系型数据库中去以及进行不同类型系统的数据之间的转换。
9.7.事务性:关系型数据库强调acid规则(原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)),可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作,而且可以充分满足数据库操作的高性能和操作稳定性的要求。并且关系型数据库十分强调数据的强一致性,对于事务的操作有很好的支持。关系型数据库可以控制事务原子性细粒度,并且一旦操作有误或者有需要,可以马上回滚事务。
10.8.读写性能:关系型数据库十分强调数据的一致性,并为此降低读写性能付出了巨大的代价,虽然关系型数据库存储数据和处理数据的可靠性很不错,但一旦面对海量数据的处理的时候效率就会变得很差,特别是遇到高并发读写的时候性能就会下降的非常厉害。
11.9.授权方式:关系型数据库常见的有oracle,sqlserver,db2,mysql,除了mysql大多数的关系型数据库如果要使用都需要支付一笔价格高昂的费用,即使是免费的mysql性能也受到了诸多的限制。
12.关系型数据库设计的过程可大体分为四个时期七个阶段。
13.(1)用户需求分析时期,主要是了解和分析用户对数据的功能需求和应用需求,是整个设计过程的基础,事关整个数据库应用系统设计的成败。
14.(2)数据库设计时期,主要是将用户需求进行综合、归纳与抽象,形成一个独立于具体dbms的数据模型,可用实体—联系模型来表示,然后将其转换为已选好的关系型数据库管理系统rdbms所支持的一组关系模式并为其选取一个适合应用环境的物理结构,包括存储结构和存取方法。
15.(3)数据库实现时期,包括数据库结构创建阶段和应用行为设计与实现阶段,是根据数据库的物理模型创建数据库、创建表、创建索引、创建聚簇等。
16.(4)数据库运行与维护阶时期,最后一个阶段则是数据库应用系统经过试运行后即可投入正式运行。
17.在进行关系型数据库的设计过程中,要遵循以下几个原则,借此可以提高数据库的存储效率、数据完整性和可扩展性。
18.1.命名规范化
19.在概念模型设计中,对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中,指定学生sstudent,专指本科生,相关的属性有:学号、姓名、性别、出生年月等,及每个属性的类型、长度、取值范围等都要进行确定,这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。
20.2.数据的一致性和完整性
21.在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性,用check、default、null、主键和外键约束来实现。
22.3.数据冗余
23.数据库中的数据应尽可能地减少冗余,这就意味着重复数据应该减少到最少。例如:若一个部门职员的电话存储在不同的表中,假设该职员的电话号码发生变化时,冗余数据的存在就要求对多个表进行更新操作,若某个表不幸被忽略了,那么就会造成数据不一致的情况。所以在数据库设计中一定要尽可能存在少地冗余。
24.4.范式理论
25.在关系数据库设计时,一般是通过设计满足某一范式来获得一个好的数据库模式,通常认为3nf在性能、扩展性和数据完整性方面达到了最好的平衡,因此,一般数据库设计要求达到3nf,消除数据依赖中不合理的部分,最终实现使一个关系仅描述一个实体或者实体间一种联系的目的。
26.发明人发现:上述数据管理模式至少存在以下缺陷:信息资源整合共享困难。传统信息系统的数据管理模式,从一开始就未对数据共享做规划,导致跨信息系统之间的信息资源汇聚、整合、治理、应用、共享存在极大困难。由于业务需求部门的独立性,以确定的业务需求建立有独立边界的信息系统,严重制约着信息资源的有效整合,很难构建一体化的信息服务体系。因此,数据整合和共享的不充分加速了信息的碎片化、条块化和孤岛现象,进而导致信息数据重复收集、信息系统重复建设,缺少统一的数据基础。


技术实现要素:

27.本发明实施例旨在至少解决上述技术问题之一。
28.第一方面,本发明实施例提供一种跨领域数据库整合和迁移方法,包括:分析用户的功能扩展需求,确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表,所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据;当所述至少一个项目为新项目时,在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表,其中,所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。
29.第二方面,本发明实施例提供一种跨领域数据库整合和迁移系统,包括:分析程序模块,配置为分析用户的功能扩展需求,确定与所述功能扩展需求对应的至少一个项目以及所述至少一个项目对应的各属性表,所述属性表包括多类元数据的基础属性表和其中至少一类元数据的扩展属性表,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据;以及更新程序模块,配置为当所述至少一个项目为新项目时,在数据库中增加与所述新项目对应的所述多类元数据的基础属性表和其中至少一类元数据的扩展属性表,其中,所述数据库由各项目及对应的所述基础属性表和所述扩展属性表构成。
30.第三方面,本发明实施例提供一种电子设备,其包括:至少一个处理器,以及与所述至少一个处理器通信连接的存储器,其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行本发明上述任一项跨领域数据库整合和迁移方法。
31.第四方面,本发明实施例提供一种存储介质,所述存储介质中存储有一个或多个包括执行指令的程序,所述执行指令能够被电子设备(包括但不限于计算机,服务器,或者网络设备等)读取并执行,以用于执行本发明上述任一项跨领域数据库整合和迁移方法。
32.第五方面,本发明实施例还提供一种计算机程序产品,所述计算机程序产品包括存储在存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,使所述计算机执行上述任一项跨领域数据库整合和迁移方法。
33.本发明实施例根据客户的扩展需求,将其整合至五类元数据的基础属性表和扩展属性表中,由于五类元数据的框架囊括了各种待扩展的属性,可以通过元数据之间的灵活组合实现对扩展需求的建模和描述。先分析确定客户的扩展需求与五种元数据的基础属性表和扩展属性表的关系,然后在数据库中增加相应的基础属性表和扩展属性表即可,扩展比较简单,五类元数据的框架可以灵活应对各种扩展需求。
附图说明
34.为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
35.图1为本发明的跨领域数据库整合方法的一实施例的流程图;
36.图2为本发明的跨领域数据库整合方法的另一实施例的流程图;
37.图3为本发明的跨领域数据库整合方法的又一实施例的流程图;
38.图4为本发明的跨领域数据库迁移方法的一实施例的流程图;
39.图5a、图5b、图5c、图5d、图5e和图5f为本发明一实施例提供的一种跨领域数据库整合和迁移方法的各元数据示意图;
40.图6为本发明的一实施例的跨领域数据库整合系统的框图;
41.图7为本发明的另一实施例的跨领域数据库整合系统的框图;
42.图8为本发明的跨领域数据库迁移系统的框图;
43.图9为本发明的电子设备的一实施例的结构示意图。
具体实施方式
44.为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
45.需要说明的是,在不冲突的情况下,本技术中的实施例及实施例中的特征可以相互组合。
46.本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元件、数据结构等等。也可以在分布式计算环境中实践本发明,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
47.在本发明中,“模块”、“装置”、“系统”等指应用于计算机的相关实体,如硬件、硬件和软件的组合、软件或执行中的软件等。详细地说,例如,元件可以、但不限于是运行于处理器的过程、处理器、对象、可执行元件、执行线程、程序和/或计算机。还有,运行于服务器上的应用程序或脚本程序、服务器都可以是元件。一个或多个元件可在执行的过程和/或线程中,并且元件可以在一台计算机上本地化和/或分布在两台或多台计算机之间,并可以由各种计算机可读介质运行。元件还可以根据具有一个或多个数据包的信号,例如,来自一个与
本地系统、分布式系统中另一元件交互的,和/或在因特网的网络通过信号与其它系统交互的数据的信号通过本地和/或远程过程来进行通信。
48.最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”,不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括
……”
限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
49.本发明实施例提供一种跨领域数据库整合方法和迁移方法,用于对跨领域数据库进行整合和迁移。需要说明的是,虽然在后续实施例中都使用了第一领域和第二领域的限定,但是本领域技术人员可以理解,第一领域和第二领域泛指不同的应用领域,第一领域和第二领域并不用于限制只有两个领域,而是为了突出不同的领域之间可以相互整合和迁移,针对社会生态环境中不同的应用,还可以有多个领域。例如,对于现存的不同行业的各类应用系统,每一个应用系统都会有相应的数据库,不同应用、不同部门、不同组织等,如果需要对其进行数据整合或迁移,均可以采用本技术实施例的技术方案实现,本技术在此不再赘述。
50.请参考图1,其示出了本发明一实施例提供的一种跨领域数据库整合方法。
51.如图1所示,在步骤101中,对来自第一领域数据库的各项目,建立对应于第一领域的包含多类元数据的第一数据库,其中,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述第一数据库包括对应于所述第一领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;
52.在步骤102中,对来自第二领域数据库的各项目,建立对应于第二领域的第二数据库,其中,所述第二数据库包括对应于所述第二领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;
53.在步骤103中,整合所述第一数据库和所述第二数据库,生成统一数据库。
54.在本实施例中,第一领域例如可以是水利领域,第二领域例如可以是农垦领域,针对水利领域数据库的各个项目,先对其建立包含多类元数据的水利数据库,例如,在水利领域中可能会存在员工信息维护表,里面包括员工的姓名、年龄、性别、联系方式、家庭住址等,则先建立自然人元数据对应的基础属性表和年龄、联系方式、家庭住址各扩展属性对应的扩展属性表,然后可以将这些数据都转移至自然人元数据对应的基础属性表和各扩展属性表中,姓名和性别的数据例如可以转移至基础属性表中,其他属性的数据各转移至对应的扩展属性表中,对于其他几类元数据的表的建立和数据的转移同理可得。进一步地,对于有些项目可能同时对应多类元数据,则可以先拆分至多类元数据,然后再分别建立对应的基础属性表和扩展属性表用于数据的整合。对于第二领域如农垦领域的数据库的处理同上,通过为不同领域的数据库建立相同的数据库结构,之后将数据都整合至相同的数据库结构中,可以实现数据库的整合和统一。
55.本技术实施例的方法通过针对第一领域和第二领域的项目,都先建立对应于五类元数据的数据库,然后再进行整合,可以使得整合的效果更好,后续再进行其他处理也更便
捷。由于五类元数据囊括了所有属性,不同的项目和应用都可以使用这五类元数据灵活组合得到,不同领域的数据库都建立与五类元数据对应的基础属性表和扩展属性表,最后可以实现不同数据库的整合,便于后续对整合的数据库进行增删改查等操作。
56.其中,在一些可选的实施例中,各类元数据的描述如下:
57.(1)自然人元数据
58.自然人,在任何一个信息化系统中都是重要的因素,也是各个系统数据共享时重复概率极高的因素。如何能实现人的基础信息数据共享,如何能实现人的数据信息准确、可信、高时效。同时,如何应对组织机构调整及人员调整中的快速、灵活的变化,都是应用服务系统对人的元素提出的挑战。
59.自然人管理分为人员基础信息和扩展信息管理,满足机构调整人员变化是系统中人员的灵活更改。
60.自然人管理需要完成人员不同形式的录入,要满足不同人员各种相关属性(如:电话、称谓、职称等)录入属性的随时增减,同时还要满足复合属性(某一属性有多个对应内容,如电话、证书等)的信息录入,便于系统全面的对于人员信息的收集管理。
61.(2)地址元数据
62.地址是各个系统都要涉及到的,而且是重要的系统元素,随着系统应用的推广使用,系统中有的是结构化数据信息,有的是半结构化的非标准化信息。这些数据的应用难以满足、适应系统灵活可变的数据应用。因此,本系统设计采用地址基础信息和扩展信息进行管理。
63.(3)组织元数据
64.组织即由若干个人或群体所组成的、有共同目标和一定边界的社会实体。它包含三层意思:
65.1)组织必须是以人为中心,把人、财、物合理配合为一体,并保持相对稳定而形成的一个社会实体。
66.2)组织必须具有为本组织全体成员所认可并为之奋斗的共同目标。
67.3)组织必须保持一个明确的边界,以区别于其他组织和外部环境。
68.组织结构需要按照常用机构、部门进行设置录入,同时要满足机构改革对于组织结构的灵活增减和变更,以及临时工作机构设置要求。因此,本系统设计采用组织基础信息和扩展信息进行管理。
69.(4)物元数据
70.物是指纳入基础信息管理平台的客观事物。物的范围极其广泛,应用极其复杂。如今大数据、物联网的时代,物是信息管理的主体,既是管理的对象也是被管理的对象。物物相连,万物互联,物是核心和基础。
71.基础信息管理平台是将万物纳入物的集合,以标识号进行识别,同时进行物的本质描述。物的管理采用基础信息和扩展信息方式进行管理。物的使用需要根据用户的业务应用进行灵活应用即可。物是不变的,应用是可变的。
72.(5)事元数据
73.事是指质量空间分布的随时变化。因为物质是质量空间分布,所以事也可定义为:物质随时间的变化。事涉及的内容比较广泛。一般指社会和自然界上的事情,事务,现象,情
况等。
74.基础信息管理平台的事,将是根据用户的实际应用和需求,进行的信息化管理、信息化分析、信息化决策支持等一系列行为。
75.事同样也是进入数据库,采用基础信息和扩展信息进行管理,以标识号进行表示,以时间为序,进行可变信息管理。事是“人、地、物、组织”其它四要素的应用和延伸。
76.请参考图2,其示出了本技术一实施例提供的另一种跨领域数据库整合方法的流程图。该流程图主要是对图1的步骤103“整合所述第一数据库和所述第二数据库,生成统一数据库”进一步限定的流程图。
77.如图2所示,在步骤201中,当所述第一数据库的各项目与所述第二数据库的各项目不完全相同时,以其中一个数据库为基础数据库,基于所述多类元数据将另一个数据库的各基础属性表、以及所述另一个数据库中与所述基础数据库相同的项目对应的扩展属性表合并至所述基础数据库中对应的基础属性表和/或扩展属性表中;
78.在步骤202中,将所述另一个数据库中的、未包含在所述基础数据库中的项目对应的扩展属性表增加至所述基础数据库中,生成统一数据库。
79.例如,水利数据库与农垦数据库有很多数据是重合的,通过上述方式进行整合之后,重合的数据将只保存一次,极大地减少了整合后的数据库的重复建设和冗余,后续对数据进行更新也不会出现要更新多处数据的情况。也不会出现由于数据涉及到多张数据表,数据表之间存在着复杂的关系,随着数据表数量的增加,数据管理会越来越复杂的情况。
80.本实施例的方法通过在整合的时候以一个数据库为基础进行表的合并和增加,处理简单,整合效果好。由于都是在五类元数据的基础上进行的整合,整合的过程中只需要增加基础数据库中没有的表,如基础属性表和扩展属性表,然后把数据迁移过来就行,整合后的统一数据库没有数据资源的重复建设,减少冗余,对于数据库的各种增删改查操作也比整合之前更加方便。整合后同样的属性只会出现在一张扩展属性表中,对于数据更新更加友好。
81.在一些可选的实施例中,所述整合所述第一数据库和所述第二数据库包括:当所述第一数据库的项目与所述第二数据库的项目相同时,合并对应于各项目的基础属性表和至少一个扩展属性表,生成统一数据库。从而整合的时候对于项目相同的情况直接合并各表,处理简单,后续对统一数据库增删改查与在一个数据库中增删改查无异,并且能够极大地减少数据库的冗余,对某一属性的更新只会涉及一个扩展属性表,不会因为由于多张数据表中都存在某一数据而需要同时更新的情况,各种扩展属性表可以只和对应的元数据的基础属性表关联,极大地降低了表之间的关联关系,也不会随着数据表数量的增加,导致数据管理会越来越复杂的情况。
82.在一些可选的实施例中,所述基础属性表和所述扩展属性表中均具有时间戳,当存在两条数据时间戳不同时,将所述两条数据确定为不同的数据,合并时仅对表中完全相同的数据进行覆盖处理。从而对于仅时间戳不同而其他内容完全相同的两条数据,可以作为不同的数据同时保留,仅对完全相同的数据进行覆盖处理。例如,更新自然人元数据中某一人的联系方式,如果以前有电话、微信,现在需要更新微信,则属于完全相同的数据,直接覆盖处理即可,如果现在需要更新的是抖音号,则与之前的电话和微信不属于相同的联系方式,则可以直接将抖音号这种联系方式更新至联系方式扩展属性表中。
83.请参考图3,其示出了本技术一实施例提供的又一种跨领域数据库整合方法的流程图。
84.如图3所示,在步骤301中,对来自第一领域数据库的各项目,拆分成对应于第一领域的包含多类元数据的第一数据库,其中,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述第一数据库包括对应于所述第一领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;
85.在步骤302中,对来自第二领域数据库的各项目,拆分成对应于第二领域的第二数据库,其中,所述第二数据库包括对应于所述第二领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;
86.在步骤303中,整合所述第一数据库和所述第二数据库,生成统一数据库。
87.本技术实施例的方法针对第一领域和第二领域的项目,由于五类元数据的数据库都是更细粒度的数据库,基础属性表的每一个扩展属性表都只存储一个属性,可以都先拆分成对应于五类元数据的数据库,然后再进行整合,可以使得整合的效果更好,后续再进行其他处理也更便捷。例如,第一领域中存在一张表包含员工的名字、性别、联系方式、家庭住址、履历、证书等属性,则可以将该表对应至五类元数据的自然人元数据中,可以将员工的名字和性别都拆分至自然人元数据的基础属性表中,将员工的联系方式、家庭住址、履历、证书等属性分别拆分至通讯信息表、地址信息表、履历信息表、证书信息表等扩展属性表中,从而完成了该表对应于五类元数据的基础属性表和扩展属性表的拆分和扩展。由于第一领域和第二领域的数据库都对应五类元数据的基础属性表和扩展属性表进行拆分和数据迁移,最终两个领域的数据库都形成了对应于五类元数据的数据库,然后再将两个领域数据库进行整合就会更加便捷,整合的过程中也能最大限度地减少数据冗余。
88.由于包含五类元数据的数据库比现有的数据库更加细粒度,对事物的描述更加全面,几乎所有的数据都可以对应到这五类元数据上,因此只需要将项目先拆分再整合即可形成统一数据库。
89.进一步地,对于现有应用的数据库,可以先在原来应用系统的数据库中进行数据库的扩展,让原来的数据库的数据更接近五类元数据的属性要求,然后再进行数据库的整合,最后按照不同的新的应用进行迁移应用。
90.在一些可选的实施例中,各元数据的基础属性表和扩展属性表的具体介绍如下:
91.自然人基础属性信息
92.1.自然人基础(以下简称“人基础”):标识号、关联号(主题)、登记出生日期(农历、阴历:年月日时分)、籍贯(关联号地址)、备注、录入人、录入时间;
93.2.性别:识别号、关联号(人基础)、性别(男、女、变性、双性)、起止时间;
94.说明:以上“识别号”均为自动生成。
95.自然人扩展属性信息
96.1.通讯:识别号、关联号(人基础)、通讯号码(电话、微信、qq、博客、邮件、网站、视频号等)、号码说明;
97.2.地址:识别号、关联号(人基础)、关联号(地址中最基础单元)、地址描述、起止时间(设计时考虑2个字段);
98.3.职称:识别号、关联号(人基础)、职称名称(技术员、工程师、教授、注册建造师、注册会计师

)、职称描述、职称起止时间;
99.4.履历:识别号、关联号(人基础)、关联号(组织基础)、履历起止时间、证明人(关联人员基础库)、履历说明;
100.5.证书:识别号、关联号(人基础)、关联号(档案)、证书名称、证书编号、证书描述、起止时间;
101.6.人关系:识别号、关联号(人基础)、关系描述(父子、岳父、夫妻、子女、叔侄、同学、牌友、狱友、同事

可选择多项)、起止时间。
102.地址基础属性信息
103.1.地址基础:标识号、关联号(主集合)、代表名称(由行政命名与称谓中的一项重复)、描述
104.地址扩展属性信息
105.2.称谓:识别号、关联号(主集合)、称谓(行政、俗称、简称等)、称谓描述、称谓起止时间;
106.3.上层关系:识别号、关联号(主集合)、上层关联号(地址基础)、描述;
107.4.省、市自治区、直辖市:识别号、关联号(地址基础)、称谓;
108.5.市、县:识别号、关联号(地址基础)、称谓;
109.6.乡镇、街道:识别号、关联号(地址基础)、称谓;
110.7.门牌号码:识别号、关联号(地址基础)、门牌号码;
111.8.企事业单位:识别号、关联号(地址基础)、名称、名称描述;
112.9.关系表:关联号、关系说明(说明地址所属的上下级直接关联关系)。
113.说明:以上“识别号”均为自动生成;4、5、6可以从第3项中查询生成。
114.组织基础属性
115.1.组织基础:识别号、名称、描述、备注、录入人、录入时间;
116.2.称谓:识别号、关联号(组织基础)、称谓、称谓描述、称谓描述起止时间;
117.组织扩展属性
118.1.地址:识别号、关联号(所属地址的最小基本单元)、有效时间;
119.2.通讯:识别号、关联号(组织基础)、通讯号码、号码说明;注:通讯号码有“电话、传真、邮箱、网站、公众号、博客、视频号等”;
120.3.证书:识别号、关联号(组织基础)、关联号(档案基础)、证书名称、证书描述;注:机构批文、机构代码证、机构编制管理证、获奖证书、质资证书等;
121.4.上层关系表:识别号、关联号(组织基础)、关联号(上层组织基础)、关系说明。
122.5.组织分类:识别号、关联号(组织基础)、关联号(组织分类);
123.6.组织描述:识别号、分类、标准(来源、依据)、描述;
124.说明:分类来源于国家行政各种相关指导文件、地方文件、日常约定等,行业、规模、地域,一个组织可有多个分类选择(多条分类记录),便于检索。
125.物集合基础属性
126.1.基础:识别号、关联号(主集合)、物的名称、物的描述;
127.物集合扩展属性
128.1.规格型号:识别号、关联号(主集合)、生产日期、单价;
129.2.用途:识别号、关联号(主集合)、单位、数量、使用人、用途描述;
130.3.价值:识别号、关联号(主集合)、数量、价格、描述;
131.4.时间:识别号、关联号(物集合)、采购时间、售后服务时间。
132.事集合基础属性
133.1.基础:识别号、关联号(主集合)、事项名称、事项描述、备注。
134.事集合扩展属性
135.1.事项类别:识别号、关联号(主集合)、类别名称、标准(来源、依据、审批文件等);
136.2.事项时间:识别号、关联号(主集合)、事项期限(开始、结束时间)、备注;
137.3.事项资金:识别号、关联号(主集合)、资金金额、资金来源、资金描述等;
138.4.事项干系人:识别号、关联号(主集合)、事项法人(自然人集合识别号)、事项干系人(自然人集合识别号)、身份证号(身份证照片)、人员描述、备注;
139.5.事项干系地址:识别号、关联号(主集合)、关联号(地址集合识别号)、建设地点(详细地址)、建设规模(面积),描述等。
140.6.事项干系组织:识别号、关联号(主集合)、事项干系组织(组织集合识别号)、事项干系组织描述、干系组织证照(营业执照、证书等);
141.7.事项干系物:识别号、关联号(主集合)、事项干系物(物集合识别号)、事项干系物描述、干系物依据(调拨单等)。
142.本实施例的方法通过采用趋于自然的对象数据分析,抽象出元数据的共性、自然属性,更加细粒度的细化、分析,实现了数据的灵活组合对不同对象的描述。既便于现实的业务应用,更便于变化状态下大数据的挖掘分析。为决策应用提供强有力的基础数据支撑。
143.请参考图4,其示出了本技术一实施例提供的一种跨领域数据库迁移方法的流程图。
144.如图4所示,在步骤401中,对来自原始领域数据库的各项目,获取对应于原始领域的包含多类元数据的原始数据库,其中,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述原始数据库包括对应于所述原始领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;
145.在步骤402中,预先制备待迁移领域数据库所需的各项目及对应的多类元数据的基础属性表和至少一类元数据的扩展属性表;
146.在步骤403中,当原始数据库中存在至少一个待迁移领域数据库所需的项目时,利用所述原始数据库中已存在的项目及对应的多类元数据的基础属性表和至少一类元数据的扩展属性表,结合所述预先制备的迁移领域数据库的各项目及对应的多类元数据的基础属性表和至少一类元数据的扩展属性表,制成对应于所述待迁移领域的待迁移数据库。
147.本技术实施例的方法通过针对原始领域的各项目建立对应于五类元数据的原始数据库,对于待迁移领域的项目,预先制备对应于五类元数据的待迁移数据库,然后再进行原始数据库的迁移整合,可以使得迁移便捷,迁移效果好,后续再进行其他处理也更便捷。
148.下面对通过描述发明人在实现本发明的过程中遇到的一些问题和对最终确定的方案的一个具体实施例进行说明,以使本领域技术人员更好地理解本技术的方案。
149.发明人在实现本技术的过程中发现现有技术中存在的缺陷主要是由以下原因导致的:由于传统信息系统的数据管理模式中,以确定的业务需求为出发点,在对物理对象的数字化过程中确定了对象边界导致的。
150.由于划定了对象的边界,而不同业务之间的需求不同,使得不同信息系统之间的数据相互独立,无法整合相互的数据资源;由于划定了对象的边界,使得业务需求改变时,整个信息系统需要重新设计,同时物理对象的变化过程也就无法得以记录和展现。
151.这些缺陷所导致的问题是该领域长期存在的问题。
152.本技术实施例的超融合数据库采用趋于自然的对象元数据分析方法,重新再造数据结构,通过抽象出元数据的共性、自然属性等,细分人、地、事、物、组织五类最基础的元数据,独立、简化出原来复杂的结构化数据,然后根据“事”的应用需求再组合五类基础数据集的元数据,形成对自然对象的再认识。本技术实施例不是傲慢的用信息化手段展示人类认识自然的结果,而是以信息化作为工具,推动人类逐渐认识自然的过程。最终,本技术实施例的目的是达到对自然对象“全息、全生命周期、全生态”的认知。
153.这一点和生物界的进化非常相似,生物界都是沿着从简单到复杂有机体的一个方向去进化。而超融合数据库,其实也是这样的一个思路,从关系数据库到各种各样的专用数据库,又到趋于自然对象元数据再造,最终发展成了一个复杂的新物种超融合基础信息数据管理平台。
154.随着大数据作为战略资源的地位日益凸显,人们越来越强烈地意识到制约大数据发展最大的短板就是对数据本身的再认识。趋于自然的、无边界的元数据治理以及元数据驱动应用的架构体系,实现大数据的基础数据信息管理的总体建设,提供了一种大数据治理复杂系统的新思维和新手段。
155.纵观软件定制开发应用的发展,虽逐步在适应大数据、互联网、物联网等技术上的适应性应用定制开发,但仍然无法真正满足实际应用需求。
156.为了提高软件系统的实用性、适应性、可扩展性,我们将采用“元数据驱动平台应用”的架构来实现基础信息平台的总体建设。
157.每个应用都可以分为元数据和元数据驱动的应用。因此,我们将从元数据出发,抽象出元数据的共性、自然属性等,进行元数据资源的建设。包括人、地、事、物、组织“智慧城市五要素”基础元数据。
158.元数据是多维度、空间性资源数据,用户的实际应用,是元数据驱动的不同维度、不同空间对元数据应用的、面向服务的数据应用平台。
159.当系统的数据应用扩展时,通过编辑元数据描述的组织结构说明,实现应用组件对数据的变更应用处理,同时增加元数据的时间戳履历;当系统的功能扩展时,通过定制元数据驱动的功能扩展插件的形式实现,使基于平台定制的系统具有较强的可扩展性。
160.图5a示出了本技术一实施例的平台功能规划拓扑图,图5b、图5c、图5d、图5e和图5f分别示出了自然人元数据、地址元数据、组织元数据、物元数据和事元数据的具体功能规划图。其中,所有录入信息均包括“录入人、录入时间、备注”属性。
161.基本要求
162.日志:登录、浏览、查询、增加、修改。
163.每条记录的识别由系统自动生成(加一),作为该记录的唯一识别。
164.备注、录入人(系统自动将当前操作者记录)、录入时间(当前系统时间自动记录)为每条记录必有的标准属性、录入依据(录入数据资料或实体数据)。
165.交互输入时尽量采用下拉菜单或列项选择形式,选项多时可用首字母拼音索引;手工输入项尽量采用标准格式辅助输入(如时间格式),保障输入数据的规范;根据正在录入内容提示相关已录入信息。
166.录入的实体数据(过程资料记录,包括照片、视频、录音等)。
167.主集合结构表如表1所示:
168.169.[0170][0171]
主题:识别号、名称、描述、录入依据。
[0172]
自然人元数据,参见图5b。
[0173]
自然集合信息录入
[0174]
1、自然人信息录入方式:录入除了现有的单个输入、批量导入以外,增加图片识别、扫描识别录入方式。
[0175]
2、自然人信息属性:由“基础属性”和扩展属性组成,基本属性固定无变化;“扩展属性”,因人员情况不同,有些填写,有些不填写;填写的可能属性需要增加。因此,录入的人员信息属性需要能够实现灵活添加和删除。
[0176]
3、尽可能实现下拉式选项录入,充分利用格式限制保证输入数据的规范(如日期),支持由其他文字复制粘贴。
[0177]
4、比对留档:录入后的人员信息要求把图、表上传,做资料比对和档案留存。
[0178]
表2-1:自然人基础信息表
[0179]
[0180][0181]
表2-2:自然人扩展属性信息表-通讯信息表
[0182][0183]
地址元数据,参见图5c。
[0184]
地址信息结构一般遵循yzt0127-2006邮政地址信息数据结构,地址是位置信息,表述时优先选择位置信息(如:道路、门牌号等),所涉及地标物、组织。
[0185]
例:国、省(直辖市、自治区、州、特区)、市(地、区)、县乡、村镇、门牌。
[0186]
表2-3:地址基础信息表
[0187][0188]
表2-4:地址扩展信息表-称谓信息表
[0189][0190]
组织元数据,参见图5d。
[0191]
1.组织机构:建议采用树形目录方式,直观、清晰的表示出组织结构的层级关系。平台组织机构建设建议采用手动录入方式进行,工作量小且随时核查比对。
[0192]
2.组织信息录入:鉴于组织机构信息较少,建议采用单个输入方式进行录入或是图片识别、扫描识别对应录入系统内表格。同时,录入后要求把图表上传,做资料比对和档案留存。
[0193]
3.组织机构属性:建议分为“基础属性”,多数情况下变化不大;“扩展属性”,需要能够实现灵活添加和删除。基本属性,尽可能实现下拉式选项录入;扩展属性,支持复制粘贴。
[0194]
表2-5:组织基础属性信息表
[0195][0196][0197]
表2-6:组织扩展属性信息-称谓信息表
[0198][0199]
物元数据,参见图5e。
[0200]
1、物集合信息录入方式:录入除了现有的单个输入、批量导入以外,增加图片识别、扫描识别录入方式。
[0201]
2、物集合信息属性:由“基础属性”和扩展属性组成,基本属性固定无变化;“扩展属性”,因物集合情况不同,有些填写,有些不填写;填写的可能属性需要增加。因此,录入的物的信息属性需要能够实现灵活添加和删除。
[0202]
3、尽可能实现下拉式选项录入,充分利用格式限制保证输入数据的规范,支持由其他文字复制粘贴。
[0203]
4、比对留档:录入后物的信息要求把图、表上传,做资料比对和档案留存。
[0204]
表2-7:物的基础属性信息表
[0205]
[0206][0207]
表2-8:物的扩展属性信息-称谓信息表
[0208][0209]
事元数据,参见图5f。
[0210]
1、平台录入事集合主要是行政事业单位的事务信息和各类工程项目信息。
[0211]
2、事集合信息录入方式:录入除了现有的单个输入、批量导入以外,增加图片识别、扫描识别录入方式。
[0212]
3、事集合信息属性:由“基础属性”和扩展属性组成,基本属性固定无变化;“扩展属性”,因事集合情况不同,有些填写,有些不填写;填写的可能属性需要增加。因此,录入的事集合信息属性需要能够实现灵活添加和删除。
[0213]
4、尽可能实现下拉式选项录入,充分利用格式限制保证输入数据的规范,支持由其他文字复制粘贴。
[0214]
5、比对留档:录入后的事集合信息要求把表格、图片上传,做资料比对和档案留
存。
[0215]
表2-9:事集合基础属性信息表
[0216][0217]
表2-10:事集合扩展属性信息-资金信息表
[0218]
[0219][0220]
本技术实施例的数据接口执行标准参照gb/t38672—202《信息技术大数据接口基本要求》。
[0221]
如今,智慧城市信息化建设在逐步消灭信息孤岛,推进信息数据开放共享,关注数据、信息间的关联。但仍然避免不了的是以应用需求为导向的信息化建设,由此而产生的边界性建设,重复性建设比比皆是。
[0222]
诸如“教学系统管理平台”就是校园教学的人、地、物、组织、事的教学管理平台,建设就需要按照教学要求和需求进行建设,建成后的应用也是服务与教学;“社区综合管理信息系统”就是社区生活的人、地、物、组织、事的综合信息管理系统,建设是按照社区管理的要求进行建设的,建成后的应用是服务与社区。这两个系统的管理对象(人、物、事等)及部分数据重合。数据可能会有重合;系统数据库、操作系统也可能重复,在现有的多数系统中只能是各建设一套满足应用,彼此之间不能互通。从系统到数据都存在重复建设、重复投资。
[0223]
再如中国铁路12306,各大航空公司的系统,虽然应用了大数据、互联网等新型技术,但仍然各自独立运行、独立服务,彼此之间数据资源的重复建设,承载应用系统的重复建设皆如此。
[0224]
大一统的基础数据平台,旨在解决带有边界建设的数据资源系统,追求趋于自然属性的元数据构建的灵活可变的、开放共享的、准确高时效的、安全可信的大一统基础数据平台。为日趋复杂变化的应用服务提供底层的基础数据支撑。
[0225]
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作合并,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
[0226]
请参考图6,其示出了本发明一实施例提供的跨领域数据库整合系统的框图。
[0227]
如图6所示,跨领域数据库的整合系统600包括第一数据库建立程序模块610、第二数据库建立程序模块620和整合程序模块630。
[0228]
其中,第一数据库建立程序模块610,配置为对来自第一领域数据库的各项目,建立对应于第一领域的包含多类元数据的第一数据库,其中,所述多类元数据包括:自然人元
数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述第一数据库包括对应于所述第一领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;第二数据库建立程序模块620,配置为对来自第二领域数据库的各项目,建立对应于第二领域的第二数据库,其中,所述第二数据库包括对应于所述第二领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;以及整合程序模块630,配置为整合所述第一数据库和所述第二数据库,生成统一数据库。
[0229]
在一些可选的实施例中,所述整合程序模块包括基础兼并程序模块(图中未示出)和增加程序模块(图中未示出)。
[0230]
其中,基础兼并程序模块,配置为当所述第一数据库的各项目与所述第二数据库的各项目不完全相同时,以其中一个数据库为基础数据库,基于所述多类元数据将另一个数据库的各基础属性表、以及所述另一个数据库中与所述基础数据库相同的项目对应的扩展属性表合并至所述基础数据库中对应的基础属性表和/或扩展属性表中;以及增加程序模块,配置为将所述另一个数据库中的、未包含在所述基础数据库中的项目对应的扩展属性表增加至所述基础数据库中,生成统一数据库。
[0231]
请参考图7,其示出了本发明一实施例提供的另一种跨领域数据库整合系统的框图。
[0232]
如图7所示,跨领域数据库的整合系统700,包括第一数据库转换程序模块710、第二数据库转换程序模块720和统一程序模块730。
[0233]
其中,第一数据库转换程序模块710,配置为对来自第一领域数据库的各项目,拆分成对应于第一领域的包含多类元数据的第一数据库,其中,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述第一数据库包括对应于所述第一领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;第二数据库转换程序模块720,配置为对来自第二领域数据库的各项目,拆分成对应于第二领域的第二数据库,其中,所述第二数据库包括对应于所述第二领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;以及统一程序模块730,配置为整合所述第一数据库和所述第二数据库,生成统一数据库。
[0234]
请参考图8,其示出了本发明一实施例提供的跨领域数据库迁移系统的框图。
[0235]
如图8所示,跨领域数据库的迁移系统800包括原始数据库处理程序模块810、预先制备程序模块820和迁移数据库形成程序模块830。
[0236]
其中,原始数据库处理程序模块810,配置为对来自原始领域数据库的各项目,获取对应于原始领域的包含多类元数据的原始数据库,其中,所述多类元数据包括:自然人元数据、组织元数据、地址元数据、物元数据和事元数据,其中,所述元数据均具有对应的基础属性表,所述原始数据库包括对应于所述原始领域的各项目的所述多类元数据的基础属性表和至少一类元数据的扩展属性表;预先制备程序模块820,配置为预先制备待迁移领域数据库所需的各项目及对应的多类元数据的基础属性表和至少一类元数据的扩展属性表;以及迁移数据库形成程序模块830,配置为当原始数据库中存在至少一个待迁移领域数据库所需的项目时,利用所述原始数据库中已存在的项目及对应的多类元数据的基础属性表和至少一类元数据的扩展属性表,结合所述预先制备的迁移领域数据库的各项目及对应的多
类元数据的基础属性表和至少一类元数据的扩展属性表,制成对应于所述待迁移领域的待迁移数据库。
[0237]
应当理解,图6、图7和图8中记载的诸模块与参考图1、图2、图3和图4中描述的方法中的各个步骤相对应。由此,上文针对方法描述的操作和特征以及相应的技术效果同样适用于图1、图2、图3和图4中的诸模块,在此不再赘述。
[0238]
值得注意的是,本公开的实施例中的模块并不用于限制本公开的方案,例如第一数据库建立程序模块,也可以描述为对来自第一领域数据库的各项目,建立对应于第一领域的包含多类元数据的第一数据库的模块。另外,还可以通过硬件处理器来实现相关功能模块,例如第一数据库建立程序模块也可以用处理器实现,在此不再赘述。
[0239]
在一些实施例中,本发明实施例提供一种非易失性计算机可读存储介质,所述存储介质中存储有一个或多个包括执行指令的程序,所述执行指令能够被电子设备(包括但不限于计算机,服务器,或者网络设备等)读取并执行,以用于执行本发明上述任一项跨领域数据库整合和迁移方法。
[0240]
在一些实施例中,本发明实施例还提供一种计算机程序产品,所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,使所述计算机执行上述任一项跨领域数据库整合和迁移方法。
[0241]
在一些实施例中,本发明实施例还提供一种电子设备,其包括:至少一个处理器,以及与所述至少一个处理器通信连接的存储器,其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行跨领域数据库整合和迁移方法。
[0242]
图9是本技术另一实施例提供的执行跨领域数据库整合和迁移方法的电子设备的硬件结构示意图,如图9所示,该设备包括:
[0243]
一个或多个处理器910以及存储器920,图9中以一个处理器910为例。
[0244]
执行跨领域数据库整合和迁移方法的设备还可以包括:输入装置930和输出装置940。
[0245]
处理器910、存储器920、输入装置930和输出装置940可以通过总线或者其他方式连接,图9中以通过总线连接为例。
[0246]
存储器920作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块,如本技术实施例中的跨领域数据库整合和迁移方法对应的程序指令/模块。处理器910通过运行存储在存储器920中的非易失性软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例跨领域数据库整合和迁移方法。
[0247]
存储器920可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储根据跨领域数据库整合和迁移设备的使用所创建的数据等。此外,存储器920可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,存储器920可选包括相对于处理器910远程设置的存储器,这些远程存储器可以通过网络连接至跨领域数据库整合和迁移设备。上述网络的实例包括但不限于互联
网、企业内部网、局域网、移动通信网及其组合。
[0248]
输入装置930可接收输入的数字或字符信息,以及产生与跨领域数据库整合和迁移设备的用户设置以及功能控制有关的信号。输出装置940可包括显示屏等显示设备。
[0249]
所述一个或者多个模块存储在所述存储器920中,当被所述一个或者多个处理器910执行时,执行上述任意方法实施例中的跨领域数据库整合和迁移方法。
[0250]
上述产品可执行本技术实施例所提供的方法,具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节,可参见本技术实施例所提供的方法。
[0251]
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
[0252]
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如rom/ram、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
[0253]
最后应说明的是:以上实施例仅用以说明本技术的技术方案,而非对其限制;尽管参照前述实施例对本技术进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1