CN103064909A

CN103064909A - 一种基于Drools规则引擎的基站数据库核查方法

Info

Publication number: CN103064909A
Application number: CN2012105541620A
Authority: CN
Inventors: 陈浙良; 孙平; 阳许军; 胡志勇; 张重齐
Original assignee: Wuhan Hongyi Information Co Ltd
Current assignee: Wuhan Hongxin Technology Service Co Ltd
Priority date: 2012-12-19
Filing date: 2012-12-19
Publication date: 2013-04-24
Anticipated expiration: 2032-12-19
Also published as: CN103064909B

Abstract

本发明公开了一种基于Drools规则引擎的基站数据库核查方法，该方法是用Drools规则引擎将程序修改处理与业务核查逻辑进行分离，该方法包括如下步骤：1）将基站数据核查情况划分为两大场景，分别是单表核查场景和交叉核查场景；2）确定基站数据核查的领域模型；3）根据不同场景进行字段核查，由业务核查逻辑控制drools规则引擎。依据核查规则描述文件进行核查处理，并将核查结果反馈给程序修改处理进行界面呈现，供用户进行修改。本发明的基于Drools规则引擎的基站数据库核查方法，通过规则引擎将业务逻辑与编码进行分离，实现了客户直接对业务逻辑的控制管理。通过Drools规则引擎，可以高效核查待处理的基础数据。

Description

一种基于Drools规则引擎的基站数据库核查方法

技术领域

本发明有关一种数据核查方法，特别是指一种基于Drools规则引擎的基站数据库核查方法。

背景技术

数据核查在移动通信网络的运营维护中是一项重要的工作，通过数据核查可以及时并有效地发现不规范的数据，还可以修改这些数据，为移动基站正常运行减少失误和风险，同时可以为数据维护人员提供维护数据填写规范的便利。随着移动基站数据不断增加，移动基站数据的填写要求也不断发生改变，基站数据的出错几率不断增大，基站数据的维护亦愈来愈困难。如CGI填写越界、信源类型不在指定范围内、室内覆盖数据中2G LAC，2G CI不出现在GSM表里的CGI里、邻频干扰、室内覆盖数据中tdLac，tdCi不出现在TD数据的CGI里等。发现和分析这些错误信息需要采用不同的优化手段来解决。为了高速高效率的开展数据核查工作，需要对整个基站数据以及其填写规范有详细的了解，将单个数据对象和多个数据对象的关联关系进行分类处理，才能有针对性的解决基站数据维护的问题。

目前规则引擎技术主要用于对数据进行过滤和对系统进行监控，且不能对处理结果进行修改和重新处理。目前对规则引擎使用的场景，存在以下问题：

1) 通常过滤数据采用Vortex规则引擎，效率不高，局限性较大；

2) 目前对数据核查通常采用硬编码方式，存在业务逻辑修改困难，后期业务逻辑变更等其他维护性工作难度大；

3) 大多方法只是对异常业务进行监控，而不是全面分析异常情况中的数据，并对这些数据进行更改，使得系统正常；

4) 采用规则引擎对单个数据对象进行独立处理，不能反映多对象之间关联关系。

发明内容

有鉴于此，本发明的主要目的在于提供一种可高效核查待处理的基础数据，并方便维护业务逻辑转换成的规则的基于Drools规则引擎的基站数据库核查方法。

为达到上述目的，本发明提供一种基于Drools规则引擎的数据库核查方法，其特征在于，该方法是用Drools规则引擎将程序修改处理与业务核查逻辑进行分离，该方法包括如下步骤：

1）将基站数据核查情况划分为两大场景，分别是单表核查场景和交叉核查场景；此步骤由程序修改处理编码实现；

2）确定基站数据核查的领域模型；此步骤由程序修改处理编码实现；

3）根据不同场景进行字段核查，由业务核查逻辑控制drools规则引擎，依据核查规则描述文件进行核查处理，并将核查结果反馈给程序修改处理进行界面呈现，供用户进行修改。

所述单表核查分为简单字段核查和记录间字段关联核查，简单字段核查是指对单个字段是否必填或填写格式的核查，记录间字段关联核查是指一个字段的填写内容必须依赖于另一个字段这种情况的核查，所述交叉核查是主表与附表之间的核查，附表中的某些字段必须以主表作为参考，附表中的这些字段的填写需要与主表中的被参考字段之间满足一定的关系。

所述领域模型包括基站、小区、室分、直放站、网元组、邻区关系、覆盖类型。

所述领域模型包括4个数据库：GSM小区数据库、TD小区数据库、室分数据库、直放站数据库，GSM小区数据库与TD小区数据库视为小区数据库。

所述小区数据库按小区配置数据、小区工程管理数据、小区外部设备、小区核查数据、小区地理位置、覆盖类型将字段分为6大类；

GSM基站数据库按GSM配置数据、GSM工程管理数据、GSM外部设备、GSM核查数据、GSM地理位置将字段分成5大类；

TD基站数据库按TD配置数据、TD工程管理数据、TD外部设备、TD核查数据、TD地理位置将字段分成5大类；

所述室分数据库按室分公共数据、2G覆盖数据、TD覆盖数据、WLAN覆盖数据将字段分为4大类；

所述直放站数据库按基本数据、工程管理数据、覆盖类数据将字段分为3大类。

所述步骤3）中的字段核查包括简单单一字段核查、同一对象的不同实例之间比较以及多对象之间信息结构交叉核查。

对数据核查的结果显示出来，并指定错误的信息位置以及允许用户修改，并接受修改的新数据，重新用规则引擎进行反复核查。

在所述多对象之间信息结构交叉核查中，将两个数据对象之间的关联关系用规则引擎描述，核查两个数据对象之间的关联性错误。

显示错误信息以及错误信息的位置，把核查规则拆分成多条，该核查规则包括：

简单字段类型核查：字符串、数字、邮件；

简单字段范围核查：上下限、包含、字符串长度；

简单字段枚举型：真假、是否。

本发明的基于Drools规则引擎的基站数据库核查方法，通过规则引擎将业务逻辑与编码进行分离，实现了客户直接对业务逻辑的控制管理。通过Drools规则引擎，可以高效核查待处理的基础数据，并且方便对将业务逻辑转换成的规则的维护，业务逻辑的变更不需要专业编码人员就可以实现系统的调整，以满足最新的系统需求。

附图说明

图1为本发明基于Drools规则引擎的基站数据库核查方法中移动基站数据库核查场景分类图；

图2为本发明基于Drools规则引擎的基站数据库核查方法中基站数据核查领域模型；

图3为本发明基于Drools规则引擎的基站数据库核查方法的步骤流程图。

具体实施方式

为便于对本发明的方法及达到的效果有进一步的了解，现结合附图并举较佳实施例详细说明如下。

本发明基于Drools规则引擎对数据进行核查，是用Drools规则引擎将程序修改处理与业务核查逻辑进行分离，如图1所示，本发明将基站数据核查情况划分为两大场景（由程序修改处理编码实现），分别是单表核查场景和交叉核查场景。其中单表核查分为简单字段核查和记录间字段关联核查，交叉核查是主表与附表之间的核查，它们是一种引用与被引用的关联关系。

单表核查由两项内容组成：简单字段核查，记录间字段关联核查。简单字段核查是指对单个字段是否必填或填写格式的核查，记录间字段关联核查是指一个字段的填写内容必须依赖于另一个字段这种情况的核查。由于这两类核查都是在一张数据表里的核查，故将这两种核查归类到单表核查。

简单字段核查对单个字段是否必填或填写格式进行核查，它保证了单个字段的正确性。记录间字段关联核查针对一个字段的填写内容必须依赖于另一个字段的情况。交叉核查即主表与附表之间的核查。具体说来，就是指附表中的某些字段必须以主表作为参考，附表中的这些字段的填写需要与主表中的被参考字段之间满足一定的关系。

为了正确对场景进行识别，首先确定基站数据核查的领域模型（由程序修改处理编码实现），如图2所示，该领域模型包括基站、小区、室分、直放站、网元组、邻区关系、覆盖类型。

该领域模型实际有4个数据库：GSM小区、TD小区、室分、直放站。但是由于GSM小区、TD小区都拥有公共小区的属性，为了维护与管理，故将他们公共的数据信息单独视为一个数据库，即小区数据库。

小区数据库（GSM、TD公共数据）按小区配置数据、小区工程管理数据、小区外部设备、小区核查数据、小区地理位置、覆盖类型将字段分为6大类。

GSM基站数据库按GSM配置数据、GSM工程管理数据、GSM外部设备、GSM核查数据、GSM地理位置将字段分成5大类。

TD基站数据库按TD配置数据、TD工程管理数据、TD外部设备、TD核查数据、TD地理位置将字段分成5大类。

室分数据库按室分公共数据、2G覆盖数据、TD覆盖数据、WLAN覆盖数据将字段分为4大类。

直放站数据库按基本数据、工程管理数据、覆盖类数据将字段分为3大类。

确定领域模型后，根据不同场景进行字段核查，由业务核查逻辑控制drools规则引擎，依据核查规则描述文件进行核查处理，并将核查结果反馈给程序修改处理进行界面呈现，供用户进行修改。

图2所示为基站数据核查领域模型，其中连线上“+1”、“+n”表示+1一方对象和+n一方对象是一对多的关系，例如一个室内分布对象，可以对应（包含）多个直放站对象。连线+1和+m与连线上+1和+n上表达相同的关系。连线“+n”和“+m”表示+n一方对象和+m一方对象是多对多的关系，例如小区基本信息和网元组，就是表示小区基本信息对象可以归属多个网元组对象，同时一个网元组对象可以包含多个小区基本信息对象。

例如： GSM基站数据有如下数据：

在上面的数据中，各列的填写规范要求如下：

CGI：460-00-LAC-CI，LAC: 28672-29183，CI: 5位及以下数字

小区名称：不能为空

小区中文名称：不能为空

基站编码：必须是6个英文字符或者数据

基站名称：不能为空

则上述场景为单表核查场景。

根据核查场景，对CGI和小区名称的核查规则可以这样设置：

rule "check the cgi Rule"

lock-on-active true

salience 140

when

$Gsm:GSMTarget(cgi not matches "460\\-00\\-2867[2-9]\\-[0-9]{1,5}|460\\-00\\-286[8-9][0-9]\\-[0-9]{1,5}|460\\-00\\-28[7-9][0-9]{2}\\-[0-9]{1,5}|460\\-00\\-29[0-1][0-7][0-9]\\-[0-9]{1,5}|460\\-00\\-29[0-1][0-8][0-3]\\-[0-9]{1,5}")

then

$Gsm.setColumnName("cgi");

$Gsm.setMessage("CGI：必须符合:460-00-LAC-CI LAC: 28672-29183 CI: 5位及以下数字");//无效信息

update($Gsm);

GSMGlobalList.add(new ErrorInfo($Gsm.columnName,$Gsm.message));

end

rule "check the name rule"

lock-on-active true

salience 139

when

$Gsm:GSMTarget(name matches ".{0}")

then

$Gsm.setColumnName("name");

$Gsm.setMessage("小区名称：不能为空");

update($Gsm);

GSMGlobalList.add(new ErrorInfo($Gsm.columnName,$Gsm.message));

end

如下面的规则：室分表的TD Lac，TD Ci必须出现在TD表的CGI里面，TD LAC，TD CI不为空，则进行核查，否则不核查。

下面是交叉核查规则：

/*

规则:室分表的tdLac，tdCi必须出现在TD表的cgi里面

TD LAC，TD CI不为空，则进行核查，否则不核查

*/

rule "The TD-Indoor checkstrue rule"

lock-on-active true

salience 4

when

$indoor:IndoorCoverTarget(tdLac matches ".{0}" && tdCi matches ".{0}")

then

$indoor.setFlag(true);//正确的则设置为true

update($indoor);

end

rule "The TD-IndoorCover check rule"

lock-on-active true

salience 3

when

$Td:TdTarget($cgi:cgi)//主表 +"-"+tdCi

$indoor:IndoorCoverTarget(eval(flag==false) && eval("460-00-"+tdLac +"-"+tdCi== $Td.cgi))//室分表的tdLac，tdCi必须出现在TD表的cgi里面

then

$indoor.setFlag(true);//匹配的则设置标志位为true

update($indoor); //在workMemory里进行更新，必须更新，则不符合要求的都是false

end

rule "search for the invalid data"

salience 2

when

$indoorCover:IndoorCoverTarget(eval(flag==false))//不符合要求的false都要查找出来，都是无效的数据

then

//TDIndoorGlobalList.add($indoorCover);//用list进行添加

TDIndoorGlobalList.add(new ErrorInfo("tdLac", "TD Lac是无效数据：室分表的TD Lac，TD Ci必须出现在TD表的CGI里面"));

TDIndoorGlobalList.add(new ErrorInfo("tdCi", "TD Ci是无效数据：室分表的TD Lac，TD Ci必须出现在TD表的CGI里面"));

end

/*

规则:室分表的tdLac，tdCi必须出现在TD表的cgi里面

TD LAC，TD CI不为空，则进行核查，否则不核查

*/

rule "The TD-Indoor checkstrue rule"

lock-on-active true

salience 4

when

$indoor:IndoorCoverTarget(tdLac matches ".{0}" && tdCi matches ".{0}")

then

$indoor.setFlag(true);//正确的则设置为true

update($indoor);

end

rule "The TD-IndoorCover check rule"

lock-on-active true

salience 3

when

$Td:TdTarget($cgi:cgi)//主表 +"-"+tdCi

then

$indoor.setFlag(true);//匹配的则设置标志位为true

end

rule "search for the invalid data"

salience 2

when

then

//TDIndoorGlobalList.add($indoorCover);//用list进行添加

end

由上可知，对数据核查的结果显示出来，并可以指定错误的信息位置以及允许用户修改，并接受修改的新数据，重新用规则引擎进行反复核查。

简单字段核查

表1-1 简单单一字段核查

例如上面Excel表格有三列，每一列对数据都有相应的要求，列数据必须符合这种要求，否则这种数据就是无效的，需要更改或者移除。针对三个字段的核查规则归纳如下：

A1字段的数据需要包含460-00数据且LAC必须在28672-29183之间，CI必须是5位及以下数字，只有这样这个字段的数据才是有效的；

如果

'A1字段' 不以 "460-00"开始

或者'A1字段' 的 LAC 小于28672

或者'A1字段' 的 LAC 大于29183

或者'A1字段' 的CI 不是数字

或者'A1字段'的CI 长度大于5

那么

输出错误信息：A1字段无效

如果要显示更准确的错误信息以及错误信息的位置，可以把以上规则拆分成多条

核查规则包括：

简单字段类型核查：字符串、数字、邮件

简单字段范围核查：上下限、包含、字符串长度

简单字段枚举型：真假、是否

等等

因此规则引擎要支持上述三类规则的定义和描述。

记录间字段关联核查

表1-2 同一对象的不同实例之间比较

上面的Excel表格也是3列，每列的要求和上面的一样。我们需要对记录行规则进行检查。

规则如下：

记录之间保持一致性，当某列字段取值相同时（字段的部分信息相同），相关联的字段必须保持一致。

表1-2中 A2，A3 是A1 关联字段信息，当A1取值相同时，则A2，A3的取值也必须相同，通过上表可以发现A2字段取值不同，所以两条记录是违背规则的无效记录。

多对象之间信息结构交叉核查

表1-3 对象A的信息结构

表1-4 对象B的信息结构

上面有两个对象的信息结构记录，每列的要求和上面的一样，我们需要对这两个文件进行记录交叉核查，也就是表1-4中的B1列数据必须在表1-3的相关联的A1字段中出现，即表1-4中B1字段取值必须在表1-3中A1字段取值中的数据，否则表1-4中此条记录是无效的记录，需要查找出来，进行后续修改，即将两个数据对象之间的关联关系用规则引擎描述，核查两个数据对象之间的关联性错误。可以理解为对象A为主对象，对象B为辅对象，对象B必须通过相识关联和对象A发生匹配关系，其中对象B的信息结构中，信息结构B1为关联的信息结构。此处表1-4中的B1字段“460-00-28673-12347”没有在表1-3中的A1字段中出现，所以此条记录是违反规则的无效数据，需要找出并修改。

本发明的基于Drools规则引擎的基站数据库核查方法，将基站数据库核查分为单表核查和交叉核查两大类，地市通过规则引擎对单数据库进行单表核查，对多数据库进行交叉核查，检查数据引用的正确性。省端通过规则引擎进行完备性校验，检查数据的缺失、冗余等错误。通过规则引擎将业务逻辑与编码进行分离，实现了客户直接对业务逻辑的控制管理。通过Drools规则引擎，可以高效核查待处理的基础数据，并且方便对将业务逻辑转换成的规则的维护，业务逻辑的变更不需要专业编码人员就可以实现系统的调整，以满足最新的系统需求。

本发明的基于Drools规则引擎的基站数据库核查方法可实现如下效果：

1、本方法将移动基站数据核查划分为2大类，综合核查整个基站数据规范性情况，且数据核查划分基于基站数据关联性关系是基站数据的真实反映。

2、本方法能够准确快速检测出非法数据，且通过友好界面精确指出非法数据的位置。

3、本方法能够准确分析出非法数据并允许修改非法数据。

4、本方法所有核查逻辑全部以文本方式放在规则文件中，维护方便、效率高、结果准确。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims

1.一种基于Drools规则引擎的基站数据库核查方法，其特征在于，该方法是用Drools规则引擎将程序修改处理与业务核查逻辑进行分离，该方法包括如下步骤：

2.如权利要求1所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，所述单表核查分为简单字段核查和记录间字段关联核查，简单字段核查是指对单个字段是否必填或填写格式的核查，记录间字段关联核查是指一个字段的填写内容必须依赖于另一个字段这种情况的核查，所述交叉核查是主表与附表之间的核查，附表中的某些字段必须以主表作为参考，附表中的这些字段的填写需要与主表中的被参考字段之间满足一定的关系。

3.如权利要求1所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，所述领域模型包括基站、小区、室分、直放站、网元组、邻区关系、覆盖类型。

4.如权利要求3所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，所述领域模型包括4个数据库：GSM小区数据库、TD小区数据库、室分数据库、直放站数据库，GSM小区数据库与TD小区数据库视为小区数据库。

5.如权利要求4所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，所述小区数据库按小区配置数据、小区工程管理数据、小区外部设备、小区核查数据、小区地理位置、覆盖类型将字段分为6大类；

6.如权利要求2所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，所述步骤3）中的字段核查包括简单单一字段核查、同一对象的不同实例之间比较以及多对象之间信息结构交叉核查。

7.如权利要求6所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，对数据核查的结果显示出来，并指定错误的信息位置以及允许用户修改，并接受修改的新数据，重新用规则引擎进行反复核查。

8.如权利要求6所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，在所述多对象之间信息结构交叉核查中，将两个数据对象之间的关联关系用规则引擎描述，核查两个数据对象之间的关联性错误。

9.如权利要求7所述的基于Drools规则引擎的基站数据库核查方法，其特征在于，显示错误信息以及错误信息的位置，把核查规则拆分成多条，该核查规则包括：

简单字段类型核查：字符串、数字、邮件；

简单字段范围核查：上下限、包含、字符串长度；

简单字段枚举型：真假、是否。