一种实现网络管理系统中配置数据组织与集中管理的方法
技术领域
本发明涉及网络管理系统的数据配置与管理技术,具体涉及一种实现网络管理系统中配置数据组织与集中管理的方法。
背景技术
随着网络技术的蓬勃发展,网络管理系统也应运而生。在一个网络管理系统中包含许多管理单元,网络管理系统需要对所有的管理单元的配置数据进行组织和管理。目前,由于管理单元的类型不同和生产厂家不同,决定了各种管理单元的自身数据的逻辑关系和存储方式存在极大差异。因此,目前的网络管理系统需要分析每一种类型的管理单元,找出对于网络管理系统所需的重要数据,然后定义一个统一的数据上报格式,由各个设备厂商提供这些指定格式的数据文件,以此来完成配置数据的组织和管理。
例如,网络管理系统需要移动交换中心这种类型管理单元的单板配置数据,于是在分析移动交换中心单板的属性后,定义了如下的数据格式:
[单板]
[对象编号][名称][单板编号][单板类型]
在这个示例中,斜体部分是由厂商实际提供的数据。网络管理系统通过这种数据文件的方式组织移动交换中心这种类型管理单元的单板配置数据,然后在此基础上对配置数据进行管理。这种以文件的方式组织和管理配置数据的方法存在如下缺点:
首先,在数据上报格式中没有配置数据之间关系的定义,因此不能体现配置数据之间的相互关系。而我们知道,配置数据之间经常存在着各种各样的相互关系,例如“信令链路集记录”和“信令链路记录”之间有一种包容关系,即一个信令链路集是由多条信令链路组成的,但是在目前的数据格式中体现不出这种关系,这样将切割数据之间的有机联系,使其从一种整体关系变成一个个孤立的个体,给配置数据的组织和管理带来困难,同时降低了系统的工作效率。
其次,由于目前的网络管理系统只能对每种类型的管理单元进行数据格式定义,不同类型的管理单元的数据格式可能不同,因此不能处理不同设备之间的配置数据存在的差异,进而不能实现集中的管理。例如,前述对移动交换中心单板进行了格式定义,如果此时系统要组织CBSC(码分多路访问系统的基站控制器)的单板数据,经过分析之后定义的数据格式如下:
[单板]
[对象编号][名称][单板编号][单板类型][配置类型]
和前述移动交换中心单板的数据格式相比,CBSC的单板数据格式多了[配置类型]属性,不仅如此,在实际情况中前面几个属性的顺序也可能不同,这是因为没有规则限定它们的顺序。因此,目前的网络管理系统只能实现对同类型管理单元的集中管理,而不能实现对不同类型管理单元的集中管理,同样降低了其工作效率。
第三,随着网络技术的迅速发展,今后的网络设备将越来越复杂,其数据格式也将相应变得更复杂,如果没有统一的规则限定数据格式,将使今后应用于网络管理系统的配置数据上报和解释的程序越来越复杂,不利于系统的开发和维护。
第四,在目前的数据上报格式中没有数据合法性验证规则,也就是,目前的数据上报格式的各个字段都是由字符串表示,没有数据类型限制,也没有取值范围限制,因此不容易发现错误数据,给网络管理系统的运行埋下安全隐患。
最后,目前在网络管理系统的设备侧增加一个新的设备时,网络管理系统都需要获得新设备的相关属性,并同时需要对原有的网络管理系统进行一系列的改动,降低了系统的可扩展性,同样不利于系统的开发和维护。
发明内容
有鉴于此,为了解决现有技术的上述缺点,本发明的目的是提供一种能提高系统工作效率、方便开发和维护、并保证系统运行更安全的实现网络管理系统配置数据组织与集中管理的方法。
本发明的上述目的是通过如下的技术方案予以解决的:
一种实现网络管理系统中配置数据组织与集中管理的方法,包括如下步骤:
a.建立反映网络管理系统中所有管理单元的原始配置数据之间逻辑关系的信息模型;
b.分别建立用来列举整个信息模型中管理单元类、描述管理单元类的具体属性和各个管理单元类之间关系的系统表;
c.根据每一个系统表的具体内容和各个系统表之间的关系建立由用于存储管理单元配置数据的数据表组成的数据存储系统。
在上述方法中,在步骤a中可以通过表现各个原始配置数据之间的包容关系的树形关系图的形式建立信息模型。
在上述方法中,在步骤b中建立系统表可以进一步包括:
b1.建立用来列举网络管理系统中管理单元类的类描述表;
b2.建立用来描述管理单元类的具体属性的属性描述表;和
b3.建立用来描述类描述表中各个管理单元类之间的关系的包容关系描述表。
在上述方法中,网络管理系统中管理单元类信息至少包括类标识符、类的对象数据所在的数据库表的表名信息,还可以进一步包括类名和对象相对识别标识符信息。管理单元类的具体属性至少包括属性标识符、属性所属的类的标识符、数据类型以及属性类型的大小、缺省值、最大值、最小值信息,还可以进一步包括属性名称和用于描述属性的特殊特性的自定义掩码信息。包容关系描述表至少包括父类标识符、子类标识符以及它们之间的映射关系信息,还可步包括用于描述包容关系的其它特性的自定义掩码信息。
在上述方法中,当类描述表包括表名信息、属性描述表包括属性标识符和数据类型信息时,步骤c可以进一步包括如下步骤:
c1.分析类描述表,为类描述表中包含的每一个类分别建立一个数据表,并根据类描述表中的表名信息确定每一个数据表的名称;
c2.分析属性描述表,根据属性描述表中的属性标识符和数据类型信息确定每一个数据表所包括的字段和字段属性。
通过本发明的技术方案可以看出,本发明通过将所有的管理单元设备抽象成具体的对象,实现了具体实例的对象化,并通过信息模型描述了数据之间的相互关系,这样配置数据之间不再是杂乱无章的,而是由其内部固有的物理或逻辑关系组织成了一个整体,配置数据之间的关系简单明了,便于理解。同时,信息模型中定义的类不再是针对具体某个管理单元的,而是所管理的所有管理单元,既有共有属性又有特有属性,这样可以实现真正的集中网络管理,并从而实现对配置数据高效率的组织和管理。
在本发明中,整个数据存储系统的建设过程的关键在于信息模型的建立,这样就将系统开发的重点从数据库上转移到信息模型的建设上,从而显著提高了开发效率。并且由于数据库表之间的关系是由系统表定义的,而不是具体的业务逻辑,使应用程序的开发的复杂度大大降低,而通用性则大大增加,使应用程序的开发更容易。另外,本发明的各个部分可以独立开发,通过统一的数据访问协议,数据采集和数据访问的运用开发就有了一个稳定的基础,这就允许我们开发出一个通用的客户端来访问所有的数据,而不必关心管理单元的类型和设备厂商的差异,从而大大降低了系统开发的工作量和难度。
在本发明中,数据库表之间的相互关系是由信息模型决定的,这样维护和使用就更方便。同时由于所有的数据访问都是基于统一的数据访问协议的,而该协议屏蔽了数据存储和访问的底层细节,这就使得在增加新属性和新类时不需要对原有系统进行较大改动,提高了系统的可扩展性,从而使系统的维护更容易和更简单。
除了上述能提高工作效率、方便开发和维护的特点之外,由于根据信息模型建立的系统表详细定义了对象之间的细节关系和对象的属性信息,并且这些数据类型是严格定义的,因此本发明能保证系统运行得更安全。
附图说明
图1是根据本发明的组织配置数据的方法示意图;
图2是根据本发明的信息模型的示意框图;
图3是显示根据本发明的包容关系描述表中类关系的示意图。
具体实施方式
下面结合附图和具体实施例对本发明进行详细说明。
图1是根据本发明的组织配置数据的方法示意图。如图1所示,为了解决现有技术的各种管理单元的数据格式不一致的状况,本发明首先对各个管理单元的原始数据进行组织,并对这些数据进行抽象处理,在此基础上建立信息模型,用这个建立的信息模型定义整个系统的配置数据的组织架构。然后,通过建立系统表的方式描述建立的信息模型。在建立了系统表之后,根据系统表构建整个网络管理系统的数据库或类似形式的数据存储系统来保存数据。这样就实现了对配置数据的组织和集中管理。建立了数据存储系统之后,就可以方便地通过用户协议访问数据存储系统中保存的数据,以得到用户所需的信息。通过上述简单说明可以看出,本发明主要由如下三个步骤组成:建立信息模型、建立系统表和建立数据存储系统。下面将分别对这三个方面进行详细说明。
建立信息模型:
网络管理系统需要管理整个网络的所有配置数据,而我们知道,这些配置数据之间经常存在着各种各样的或直接或间接的关系,这是因为组成网络的各个硬件设备都不是孤立的,这些硬件设备之间必然具有物理上或逻辑上的联系,从而才能在网络中协同工作。例如,网络中的一个交换机包含多个模块,一个模块包含多个机框,一个机框又包含多个单板。因此,可以将这些信息抽象出来,建立一个反映配置数据组织的逻辑关系的信息模型,图2示出了一个简单的信息模型的示例,它是一个树形关系图。
在图2所示的树形关系图中,各个节点之间体现的关系不是继承关系,而是一种包容的关系,也就是上一级节点包含下一级节点,正如前述一个机框包含多个单板一样。在图2中可以看出,一个基站控制器包含本局信令点和交换机,而一个本局信令点又包含多个目的信令点,一个目的信令点包含信令链路集和信令路由。同时,一个交换机包含多个模块,一个模块包含多个机框,一个机框包含多个单板。这样通过图2中这种系统整体和构成整体的所有局部按层次建立起来的包容关系,可以清楚地看出整个系统的框架,并且可以清楚地看出整个系统的结构以及系统的各个组成部分之间的相互关系。
通过上述过程,将系统中原来各个独立的处于分裂状态的配置数据通过建立的信息模型构成了一个完整的有机的整体,从而为实现对所有配置数据进行高效率的组织和管理打下了良好的基础。
建立系统表:
根据上述方法建立的信息模型只是对整个系统配置数据组织的图形描述,还不足以定义每一个配置数据之间的关系,因此还需要用更具体的方式来描述信息模型的具体细节,例如还需要知道每一个对象都有哪些具体的属性、属性的数据类型是什么、属性的取值范围是什么、各个父类和子类之间具有怎样的数量关系等等细节问题,这样就需要通过建立系统表的方式对信息模型进行进一步的具体描述。
系统表是用来描述信息模型的一种方式,它用来完成对整个信息模型的描述。一旦按照上述方法确定了信息模型之后,系统表在整个系统中就是固定不变的,并通过各个系统表之间的相互协作定义了信息模型的细节和具体数据表之间的关系。下面以一套可能的系统表来进行具体说明。
为了对信息模型进行具体描述,可以建立由一张类描述表、一张属性描述表和一张包容关系描述表组成的一套系统表。
类描述表用来列举系统中有哪些类,它至少包括类标识符(ID)、类的对象数据所存在的数据库表的表名等信息,还可以选择性地包含类名和对象相对识别ID等信息,其中对象相对识别ID是唯一地定义一个同类对象的顺序索引号,以区别同一类对象中各个不同的实例。下表1是一个具体的类描述表的简单示例:
类ID |
类名 |
表名 |
对象相对识别ID |
300 |
Slot |
TblSlot |
Id |
301 |
Frame |
TblFrame |
Id |
…… |
…… |
…… |
…… |
表1
属性描述表用来描述类的具体属性,它至少包括属性ID、属性所属的类ID、数据类型以及数据类型的大小、缺省值、最大值、最小值等信息,同时还可以选择性地包含属性名称和属性掩码等信息。在这些信息中,属性ID用于唯一标识一个属性,它在全系统中是唯一的;属性掩码可以自定义,它用于描述属性的一些特殊特征,例如该属性是否可以为空、是否是关键属性等等。在这个例子中都设置为0,也就是没有设置。在实际情况中掩码可以是由系统定义了具体内容的数字,例如用这个数字的第一位表示是否可以为空,第二位表示是否是相对识别ID,第三位表示是否是关键属性等。下表2是一个属性描述表的简单示例:
类ID |
属性ID |
属性名称 |
数据类型 |
大小 |
缺省值 |
最大值 |
最小值 |
掩码 |
300 |
01 |
id |
int |
4 |
0 |
65535 |
0 |
0 |
300 |
02 |
name |
string |
255 |
- |
- |
- |
0 |
300 |
03 |
type |
string |
32 |
unkown |
- |
- |
0 |
301 |
11 |
id |
int |
4 |
0 |
65535 |
0 |
0 |
301 |
12 |
name |
string |
255 |
- |
- |
- |
0 |
…… |
…… |
…… |
…… |
…… |
…… |
…… |
…… |
…… |
表2
包容关系描述表用来描述类描述表中各个类之间的关系,它一般包括父类ID、子类ID、映射关系等信息,还可以选择性地包含掩码信息。其中,映射关系表示父类和子类之间是一种1对1的关系、1对多的关系还是其他关系,换句话说,就是在一个父类中,同样的子类可以建立一个还是多个,或者不能建立这样的子类。掩码可以自定义,用于描述该类子节点是否可以被修改添加等特殊特性,它们也由数字表示,同表2中的掩码一样,各个数字的具体内容由系统定义,这里都将其设置为0,也就是没有设置。下表3是一个简单的包容关系描述表的示例:
父类ID |
子类ID |
映射关系 |
掩码 |
300 |
1000 |
1对1 |
0 |
300 |
1001 |
1对多 |
0 |
300 |
1002 |
1对0…n |
0 |
1001 |
1100 |
1对0…n |
0 |
…… |
…… |
…… |
…… |
表3
在表3中的映射关系有1对1、1对多和1对0…n这三种形式,其中1对1表示一个父类只能有一个子类,不能没有也不能有多个;1对多表示一个父类应该有多个子类,不能没有或不能只有一个;1对0…n则表示一个父类可以有任意数量的子类,例如可以是没有,也可以是只有一个,也可以有多个,没有任何限制。
为了便于理解,图3进一步用层次树的形式对表3的各种包容关系进行了更形象的展示。在图3中可以看出,父类300下只能建立一个子类1000,只能建立多个子类1001,而对建立子类1002的数量则没有限制。同样,子类1001作为类1100的父类时,它可以建立任意多个子类1100,这里的任意多个表示可以没有,可以是一个,也可以是多个。
建立数据存储系统:
在建立了一套三张系统表:类描述表、属性描述表和包容关系描述表之后,就可以根据这些系统表来建立诸如数据库的数据存储系统。建立数据存储系统是建立只包括表头而没有具体数据的数据表,其中数据表的名称由类描述表中的表名字段唯一定义,数据表有哪些字段由属性描述表中该类所包含的属性定义,在属性描述表中的每一个类的属性对应于数据表的一个字段,这些字段的具体数据类型、取值范围等特性也由属性描述表确定。包容关系描述表描述类之间的包容和数量关系,用于帮助验证存放在数据表中数据的正确性,与具体建表过程无关。数据表中具体对象的填充属于本发明的后续应用,不属于本发明的技术内容。
下面给出一个可能的建立一张数据表的情况。例如,在分析了表1和表2之后,可以据此建立一张单板数据表。从表1可以看出,单板的类ID是300,表名是tblSlot,从表2中可以看出,单板类300包括属性ID分别为01、02和03的三种属性,其属性名称分别为id、name和type。因此,建立单板数据表的过程就是根据单板类的这三种属性建立数据表的框架。例如通过如下命令建立一张单板数据表:
create table tblSlot(objectid int primary key,id int default O,namechar(255),type char(32)default′unknown′)
也就是,这张名为tblSlot的数据表应该包括四个字段:objectid、id、name和type,其中objectid是每一个具体的数据表都具有的一个字段,它表示每一个包括单板实例的所有实例各自在整个系统中的唯一识别编号。id表示实例在同一个类中的相对识别编号,例如对于每一个单板实例来说,它在整个系统中有一个编号objectid,同时在所有的单板中还有一个编号id。这里的objectid和id都是整数类型。name表示每一个单板实例的名称,它是一个最大值为255的字符串,type表示单板实例的类型,其缺省值为unkown。通过这个命令建立的一张单板数据表的简单示例见下表4:
表4
在建立了表4之后,即完成了本发明。然后可以根据具体的每一个单板实例对表4的具体内容进行填充。这属于对本发明的应用,在这里不再详述。例如下表5是根据三个实际单板的具体情况而填充到表4后形成的一个实际的数据表。
objectid |
id |
name |
type |
100 |
1 |
slot-1 |
PPU |
101 |
2 |
slot-2 |
SPU |
102 |
3 |
slot-3 |
XIE |
…… |
…… |
…… |
…… |
表5
在按照前述三个步骤对配置数据进行了组织并建立了由数据表组成的数据存储系统之后,可以通过建立统一的数据访问协议对数据进行访问和管理。这套数据访问协议可以屏蔽所有的具体数据表操作或者其他具体存储细节,也就是说,用户只需要知道他想获得什么数据并提供相关的信息就可以了,具体的数据访问细节都由协议提供者屏蔽了。例如,用户如果想知道系统中所有单板实例的属性ID,那么他只需向协议提供者发出提取属性ID的请求,并将具体的参数,在这里就是对象的类型ClassID 300,附加在该请求中,协议提供者在接收到用户发出的提取属性ID的请求后,将返回符合条件的ID列表,例如可以是{符合条件的ID的个数,ID1,ID2,ID3,…,IDn},在这里就是{3,1,2,3}。更具体的情况可以是:
协议:提取单板对象实例ID列表
命令:Get_Ids
客户发起请求:Get_Ids(单板类ID)
协议返回:{单板个数n+单板ID列表(单板1,单板2…,单板n)}
当然,这里只是作一个简单的展示,在实际数据的前面可能还有包含路由信息的帧头,至于具体的格式则由协议提供者定义。
根据系统表和数据表建立系统访问协议是一种现有技术,对于本领域的技术人员很容易实现,因此在此不做过多地描述,不过需要说明的是,系统访问可以访问根据三张系统表建立的各个数据表,也可以访问三张系统表本身。
上面通过具体实施例对本发明进行了详细说明,不过应当知道,它们只用于对本发明进行展示,而不是限制。