CN109391489A

CN109391489A - 一种网元配置数据的存储处理方法及装置

Info

Publication number: CN109391489A
Application number: CN201710671334.5A
Authority: CN
Inventors: 胡平; 胡一平
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2017-08-08
Filing date: 2017-08-08
Publication date: 2019-02-26
Anticipated expiration: 2037-08-08
Also published as: CN109391489B

Abstract

本发明实施例公开了一种网元配置数据的存储处理方法及装置，方法包括：获取当前网元配置数据对应的目标管理对象的存储策略；若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件；在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表；将所述当前网元配置数据存储在所述目标对象表中。本发明实施例通过判断采用共享存储策略时，将同一个父对象的子对象存储在同一个目标对象表中，扩展了OMC的存储容量，并能够合理利用现有的数据库以及系统资源进行网元配置数据的存储。

Description

一种网元配置数据的存储处理方法及装置

技术领域

本发明实施例涉及数据存储技术领域，具体涉及一种网元配置数据的存储处理方法及装置。

背景技术

在OMC(Operation and Maintenance Center，操作维护中心)网管系统中，OMC系统容量与其管理的网元个数有很大关系，OMC接入的网元数量越大，性能越稳定，OMC的容量就越大。一般OMC接入的网元数从几百到几千，甚至上万，而每个网元数据少则几千条，多则几十万条，加之网元对象的“树”状特点(即每个对象在不同的层级上，每个对象的属性个数不一，类型不一)，如何存储这些网元数据就成了首要的问题。目前主流的支持关系型数据存储结果的大型数据库Oracle是一个不错的选择，Oracle Database又名Oracle RDBMS或简称Oracle，是甲骨文公司的一款关系数据库管理系统。

但是这些网元数据如何拆分关系似乎是一个棘手的问题。按照一般数据库设计思想，所有网元会存入一张数据库表中，显然这个方法对OMC是行不通的，如此庞大的配置数据存入一张数据库表中，对数据库来说是一个致命的打击，光一条查询语句足够让数据库“崩溃”，更何况这些配置数据还在频繁变更，单从性能方面考虑，都无法满足要求，因此配置数据如何存储成为制约OMC的一个关键问题。

在实现本发明实施例的过程中，发明人发现现有的OMC容量不易扩展，且数据库以及系统资源不能合理利用。

发明内容

由于现有方法存在上述问题，本发明实施例提出一种网元配置数据的存储处理方法及装置。

第一方面，本发明实施例提出一种网元配置数据的存储处理方法，包括：

获取当前网元配置数据对应的目标管理对象的存储策略；

若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件；

在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表；

将所述当前网元配置数据存储在所述目标对象表中。

可选地，所述方法还包括：

若判断获知所述存储策略为单独存储策略，则获取空闲的对象表，并将所述当前网元配置数据存储在所述空闲的对象表中。

可选地，所述方法还包括：

将所述目标管理对象存储在总表中，并将所述目标管理对象和所述父对象的关系存储在关系表中。

可选地，所述将所述当前网元配置数据存储在所述目标对象表中，具体包括：

若判断获知所述目标对象表的主表为可存储状态，则将所述当前网元配置数据存储在所述目标对象表的主表中，否则将所述当前网元配置数据存储在所述目标对象表的备表中。

可选地，所述方法还包括：

若判断获知所述目标对象表中所有的网元配置数据被删除，则将所述目标对象表的状态修改为空闲。

可选地，所述目标对象表中各列的表头为预先设置。

第二方面，本发明实施例还提出一种网元配置数据的存储处理装置，包括：

策略获取模块，用于获取当前网元配置数据对应的目标管理对象的存储策略；

文件获取模块，用于若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件；

对象表获取模块，用于在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表；

数据存储模块，用于将所述当前网元配置数据存储在所述目标对象表中。

可选地，所述装置还包括：

单独存储模块，用于若判断获知所述存储策略为单独存储策略，则获取空闲的对象表，并将所述当前网元配置数据存储在所述空闲的对象表中。

可选地，所述装置还包括：

对象存储模块，用于将所述目标管理对象存储在总表中，并将所述目标管理对象和所述父对象的关系存储在关系表中。

可选地，所述数据存储模块具体用于若判断获知所述目标对象表的主表为可存储状态，则将所述当前网元配置数据存储在所述目标对象表的主表中，否则将所述当前网元配置数据存储在所述目标对象表的备表中。

可选地，所述装置还包括：

状态修改模块，用于若判断获知所述目标对象表中所有的网元配置数据被删除，则将所述目标对象表的状态修改为空闲。

可选地，所述目标对象表中各列的表头为预先设置。

第三方面，本发明实施例还提出一种电子设备，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行上述方法。

第四方面，本发明实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机程序，所述计算机程序使所述计算机执行上述方法。

由上述技术方案可知，本发明实施例通过判断采用共享存储策略时，将同一个父对象的子对象存储在同一个目标对象表中，扩展了OMC的存储容量，并能够合理利用现有的数据库以及系统资源进行网元配置数据的存储。

附图说明

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

图1为本发明一实施例提供的一种网元配置数据的存储处理方法的流程示意图；

图2为本发明一实施例提供的一种管理对象的树形存储结构示意图；

图3为本发明一实施例提供的分表存储的数据对应示意图；

图4为本发明一实施例提供的一种基于共享存储策略的数据存储配置示意图；

图5为本发明一实施例提供的一种网元配置数据的存储处理装置的结构示意图；

图6为本发明一实施例提供的电子设备的逻辑框图。

具体实施方式

下面结合附图，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

图1示出了本实施例提供的一种网元配置数据的存储处理方法的流程示意图，包括：

S101、获取当前网元配置数据对应的目标管理对象的存储策略。

其中，所述网元配置数据为管理对象作为一个网元实际对应的配置数据。

所述目标管理对象为当前需要存储的网元配置数据对应的管理对象。其中，管理对象为一个独立存储的网元。

所述存储策略包括共享存储策略和单独存储策略。

所述共享存储策略是指不会为每一个新增加的管理对象都分配对象表，而是根据一定的规则，将其与其他同类管理对象存储于一张对象表中，并使用相同的备表。

所述单独存储策略是指为每个新增加的管理对象都分配一个未被使用的对象表存储数据，并分配一个未被使用的对象表作为备表。

S102、若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件。

其中，所述信息模型文件为存储各管理对象模型的文件，该文件中仅存储各管理对象的参数模型，并不存储实际数据。

S103、在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表。

其中，所述父对象为树形结构模型中，当前管理对象所对应的上层对象。

对应地，子对象为树形结构模型中，当前管理对象所对应的所有下层对象。

一般来说，一个管理对象仅有一个父对象，但是有多个子对象。

所述目标子对象为所述父对象除了所述目标管理对象之外的子对象。

所述目标对象表为所述目标子对象的对象表。

具体地，所述目标对象表中各列的表头为预先设置。即所有的管理对象的对象表中各列的表头都是根据预先设置的列表头进行设置的。通过将所有的对象表采用统一的列表头，能够方便快速添加或修改对象表中的网元配置数据。

S104、将所述当前网元配置数据存储在目标子对象的目标对象表中。

具体地，将所述当前网元配置数据存储在所述目标对象表中，无需重新打开一张新的对象表存储，大大节省存储空间。

本实施例通过判断采用共享存储策略时，将同一个父对象的子对象存储在同一个目标对象表中，扩展了OMC的存储容量，并能够合理利用现有的数据库以及系统资源进行网元配置数据的存储。

进一步地，在上述方法实施例的基础上，所述方法还包括：

S105、若判断获知所述存储策略为单独存储策略，则获取空闲的对象表，并将所述当前网元配置数据存储在所述空闲的对象表中。

其中，所述空闲的对象表为暂无进行网元配置数据存储的对象表。

根据具体的数据库使用情况和管理对象的数量，确定相应的存储策略。当应用场景中管理对象的数量不多时，为了简化存储过程，可采用单独存储策略。

进一步地，在上述方法实施例的基础上，所述方法还包括：

S106、将所述目标管理对象存储在总表中，并将所述目标管理对象和所述父对象的关系存储在关系表中。

其中，所述总表为用于存储所有管理对象的基本参数的表。

所述关系表为用于存储各管理对象在树形结构中的关系的表。

本实施例采用三张不同类型的表存储管理对象，分别为总表、关系表和对象表。

具体地，如下表1是在不分表的情况下，按照传统的数据库设计，通过一张表来存储网元配置数据的结构，所有的网元数据存储在PMO表中，由于OMC接入的网元类型与网元个数不同，因此此表的数据量也不同，但是可以想象，如果将10000个基站的数据存储在这张网元数据表中，数据库会有多大的压力？

表1现有技术中PMO表的字段设计

鉴于现有的设计方法无法满足OMC容量的扩展，因此本实施例提出了网元配置数据分表策略，但是实施分表策略有一个必要前提条件，那就是数据的存储结构设计应该本着不同逻辑实体数据存储结构相同的原则，即：系统涉及到的所有网元数据以及对象数据，数据库存储结构相同，这样才能保证对象能够进行分表策略配置。

在进行数据库设计之前，先阐述下配置数据建模，因为只有理解了数据建模，才能真正明白网元数据的树型结构，以及将这种树型数据与关系进行有效存储的方法。

管理对象的模型树如图2所示：其中D和E和F可以作为subDomain内的管理对象。在这个例子中,E、F、D单独作为一个SubDomain。他们一起属于C。

模型结构定义如下：A、B、C定义在同一个模型(信息模型文件)中,D、E、F分别定义在各自模型(信息模型文件)中。

具体地，信息模型文件A.xml的内容如下：

信息模型文件D.xml的内容如下：

……

……

</class>

信息模型文件E.xml的内容如下：

……

</class>

信息模型文件F.xml的内容如下：

……

</class>

其中，newTable字段为true表示创建模型的管理对象时需要获取新的表来存放,为false则不需要。

hasSubDomain为true表示这个管理对象下面有子域对象(SubDomain)。

以下为具体的数据设计：

数据实体逻辑设计：根据模型结构和管理对象的特性,提出了Domain(域)和SubDomain(子域)这两种针对数据实体的逻辑概念。简单的说Domain与SubDomain具有相同的数据结构并且是具有从属关系的两种逻辑对象实体。SubDomain和DoMain之间存在业务方面的逻辑关系，SubDoMain是作为Domain的子对象而存在的。

上面提到Domain与SubDomain具有相同的数据存储结构，这也是下面进行分表基础和前提。

数据存储结构设计：系统中采用三类表：总表PMO表，关系表MOR表，以及MO表。

在采用分表策略的情况下，为了降低数据库存储压力，每个SubDomain里所有对象单独分配个表(MO)进行存储,而Domain和SubDomain之间的关系存储在MOR表中,Domain对象则放在总表(PMO)中。对象的数据采用横向存储,每个表中预留150个属性字段,对象的属性按照属性顺序存储。

总表PMO表设计如下表2所示：

表2本实施例提供的总表的字段设计

表2中，DN是对象从根节点开始的一个唯一标识,也是主键。

CID是某一类对象的标识ID。

hasDomain字段表示此对象下是否存在SubDomain,如果有(hasDomain＝1，反之则为0),则SubDomain的所有对象在对象表(MO)中存储,SubDomain和其父对象的关联关系则在关系表(MOR)中存在。

SLEVEL代表了该对象所在树的层次深度,它也可以作为获取对象的过滤条件。

DNLEVEL代表该对象的层次深度。

type是该网元的网元类型。

version是该网元的版本号。

A1～A150是对象属性字段默认创建150个属性字段,按顺序存储。

对象表MO表设计如下表3所示：

表3本实施例提供的对象表的字段设计

字段名称	字段类型	约束条件
			DN	VARchar2(300BYTE)	NOT NULL
CID	NUMBER	NOT NULL
			SLEVEL	NUMBER
TYPE	VARchar2(100BYTE)
			VERSION	VARchar2(100BYTE)
FLAG	NUMBER	NOT NULL
			A1	VARchar2(500BYTE)
……
			A150	VARchar2(500BYTE)

其中，DN是对象从根节点开始的一个唯一标识,也是主键。

CID是某一类对象的标识ID。

type是该网元的网元类型。

version是该网元的版本号。

FLAG字段是逻辑删除标志位,当网元同步数据时首先把该网元的数据全部设为逻辑删除(FLAG＝1),然后对同步上来的每条数据在数据库中进行修改,修改完毕后去除该条数据的逻辑删除(FLAG＝0),网元数据同步结束后再物理删除还存在逻辑删除标志位的数据。

A1～A150是对象属性字段默认创建150个属性字段,按顺序存储。

关系表MOR表的字段设计如下表4所示：

表4本实施例提供的关系表的字段设计

字段名称	字段类型
		DOMIANDN	VARchar2(300 BYTE)
ROOTDN	VARchar2(300 BYTE)
		DOMIANNAME	VARchar2(100 BYTE)
TABLEA	VARchar2(100 BYTE)
		TABLEB	VARchar2(100 BYTE)
FLAG	NUMBER

其中，DomainDN是总表中存在SubDomain的内部对象DN。

RootDN是SubDomain中网元对象的根节点DN,DomainDN和RootDN一起作为主键。

TableName_A和TableName_B是存储SubDomain中对象的主备表。

flag是指示主备表的有效性。如果flag为0,则表示TalbeName_A指示的是主表,如果为1表示TableName_B指示的是主表,若为-1,则表示TableName_A和TableName_B表暂时无效,不存储当前RootDN对应的网元的配置数据。

DOMAINNAME表示域名。

具体地，在进行网页配置数据存储时，系统缺省的网元表是PMO表，这表示如果不应用任何的分表策略时所有的网元数据(Domain对象以及SubDomain对象)均会全部存储在PMO表中。

在使用了分表机制后，对于数据的加载说明如下：首先加载PMO表中的内部对象(即Domain对象)，然后根据MOR关系表中网元关联信息来加载各个对象(MO)表中数据(即SubDomain对象)。

鉴于无论是否采用分表策略，DOMIAN(主域)数据一定存储在PMO表中，MOR表一定存储关系数据，所以分表策略的讨论和阐述都只针对对象表MO表。

OMC系统默认建立500个对象表(mo1～mo500)，在系统启动时载入500个网元表数据,每次系统增加一个可管理的网元设备对象时,根据网元设备对象所属的SubDomain确认是否需要分配新表，如果需要则分配二个表进行存储,一个为主表，一个为备表,并根据网元设备对象和代表SubDomain所归属的Domain之间的关联关系在关系表MOR中增加关联数据，设置flag为0(表示TableName_A的表名位主表)。当删除网元设备对象时清空了表数据，需要回收此表,同时需要删除MOR表中的关联记录。

对于对象表的使用状态需要进行实时监控，例如：系统初始化时，预置每个表状态为空闲。当根据需要完成对象储存表的分配后，除了在MOR表中新增一条关系记录外，还需要将实时监控中将该表的状态置为使用中。当有新增时，从未使用的表中分配两个，如果删除了网元对象需要回收时，则置表状态为空闲，循环使用。

在目前的系统中，如果要使用共享存储策略，需要做如下配置：

在该对象所属的信息模型文件中，配置newTable属性的值为TRUE(newTable＝TRUE)。该属性为TRUE表示需要为该类型的对象分配表。

在该对象所属的信息模型文件中，配置subModelCount属性的值大于1(subModelCount>1)。该值大于1表示允许其他同类对象与其共享同一张对象表存储数据，并使用同一个备表。

具体配置如图4所示，做了图4所示的配置后，存储一个新增加的对象时会遵循如下规则：

判断所有MO表中是否已经存在与当前子对象同属于一个父对象的其它子对象。

A：已存在：将当前子对象存入其同类对象所在的MO表，并与其同类对象使用相同备表。

B：不存在：为该子对象重新指定存储表和备表。

采用单独存储策略需要做如下配置：

如果采用分表策略，应该采用共享存储策略。因为采用单独存储策略虽然能够解决效率问题，但是必然面临系统设计的对象表的穷尽问题。采用共享存储模式，在目前系统下，合理的设计区域以及区域下的网元，能够在性能效率和对象表数量之间取得平衡。

本实施例有利于OMC容量扩展。从数据库层面解决了OMC的性能瓶颈，使得网元个数不会成为制约数据库性能的最大障碍，从而为OMC管理更多网元提供可能。同时能够分散数据库压力，合理利用数据库的性能。众所周知，如果一个数据库表中存入的数据量很大，频繁对此表操作，这样的设计真不是好的设计，只有将这些数据想办法存储在不同表中，才能真正体现数据库的价值。此外，本实施例还统一了不同网元的存储结构与接口访问。如果不同网元的数据存储结构相同，那么从代码实现层面上看接口与实现都可以统一，从而增加代码的复用性，减少代码量。容易实现网元类型的扩展。因为只要将数据模型统一，数据存储结构自然采用现有的分表策略，使得OMC管理任何类型的网元成为可能，且比较容易实现。

进一步地，在上述方法实施例的基础上，S104具体包括：

其中，所述目标对象表包括主表和备表；所述主表的状态包括可存储状态和不可存储状态；当所述主表为可存储状态时，则将当前网元配置数据存储在主表中；当所述主表为不可存储状态时，则将当前网元配置数据存储在备表中。

所述可存储状态为能够直接存储网元配置数据的状态；对应地，所述不可存储状态为无法直接存储网元配置数据的状态。

通过设置备表，当主表出现问题无法存储时，可以通过备表保证网元配置数据的实时存储。

进一步地，在上述方法实施例的基础上，所述方法还包括：

S107、若判断获知所述目标对象表中所有的网元配置数据被删除，则将所述目标对象表的状态修改为空闲。

其中，所述目标对象表的状态包括空闲和使用。

当所述目标对象表的状态为空闲时，表示允许存储新的网元配置数据；当所述目标对象表的状态为使用时，表示必须采用共享存储策略且属于同一个父对象的子对象的网元配置数据才能存储。

通过删除对象表中的网元配置数据，并将对象表的状态修改为空闲，能够循环使用该对象表，节省表空间。

图5示出了本实施例提供的一种网元配置数据的存储处理装置的结构示意图，所述装置包括：策略获取模块501、文件获取模块502、对象表获取模块503和数据存储模块504，其中：

所述策略获取模块501用于获取当前网元配置数据对应的目标管理对象的存储策略；

所述文件获取模块502用于若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件；

所述对象表获取模块503用于在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表；

所述数据存储模块504用于将所述当前网元配置数据存储在所述目标对象表中。

具体地，所述策略获取模块501获取当前网元配置数据对应的目标管理对象的存储策略；所述文件获取模块502若判断获知所述存储策略为共享存储策略，则获取所述目标管理对象对应的信息模型文件；所述对象表获取模块503在所述信息模型文件中查找得到所述目标管理对象对应的父对象，若判断获知所述父对象存在所述目标管理对象之外的目标子对象，则获取所述目标子对象的目标对象表；所述数据存储模块504将所述当前网元配置数据存储在所述目标对象表中。

进一步地，在上述装置实施例的基础上，所述装置还包括：

进一步地，在上述装置实施例的基础上，所述数据存储模块504具体用于若判断获知所述目标对象表的主表为可存储状态，则将所述当前网元配置数据存储在所述目标对象表的主表中，否则将所述当前网元配置数据存储在所述目标对象表的备表中。

进一步地，在上述装置实施例的基础上，所述装置还包括：

进一步地，在上述装置实施例的基础上，所述目标对象表中各列的表头为预先设置。

本实施例所述的网元配置数据的存储处理装置可以用于执行上述方法实施例，其原理和技术效果类似，此处不再赘述。

参照图6，所述电子设备，包括：处理器(processor)601、存储器(memory)602和总线603；

其中，

所述处理器601和存储器602通过所述总线603完成相互间的通信；

所述处理器601用于调用所述存储器602中的程序指令，以执行上述各方法实施例所提供的方法。

本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

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

Claims

1.一种网元配置数据的存储处理方法，其特征在于，包括：

获取当前网元配置数据对应的目标管理对象的存储策略；

将所述当前网元配置数据存储在所述目标对象表中。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

4.根据权利要求1所述的方法，其特征在于，所述将所述当前网元配置数据存储在所述目标对象表中，具体包括：

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

6.根据权利要求1所述的方法，其特征在于，所述目标对象表中各列的表头为预先设置。

7.一种网元配置数据的存储处理装置，其特征在于，包括：

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

10.根据权利要求7所述的装置，其特征在于，所述数据存储模块具体用于若判断获知所述目标对象表的主表为可存储状态，则将所述当前网元配置数据存储在所述目标对象表的主表中，否则将所述当前网元配置数据存储在所述目标对象表的备表中。

11.根据权利要求7所述的装置，其特征在于，所述装置还包括：

12.根据权利要求7所述的装置，其特征在于，所述目标对象表中各列的表头为预先设置。

13.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求1至6任一所述的方法。

14.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机程序，所述计算机程序使所述计算机执行如权利要求1至6任一所述的方法。