CN101772043A - 局数据核查方法和装置 - Google Patents
局数据核查方法和装置 Download PDFInfo
- Publication number
- CN101772043A CN101772043A CN200810247037A CN200810247037A CN101772043A CN 101772043 A CN101772043 A CN 101772043A CN 200810247037 A CN200810247037 A CN 200810247037A CN 200810247037 A CN200810247037 A CN 200810247037A CN 101772043 A CN101772043 A CN 101772043A
- Authority
- CN
- China
- Prior art keywords
- data
- office
- office data
- verify
- bureau
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本发明实施例公开了一种局数据核查方法和装置，所述方法包括：设置将待核查局数据和标准局数据转换成符合预定模型的待核查局数据的转换规则；获取标准局数据集合和原始局数据集合；将原始局数据集合转换成符合标准描述方式的待核查局数据集合；分别依据对应的转换规则，将待核查局数据集合和标准局数据集合分别转换成符合预定模型的待核查局数据集合和标准局数据集合；以所述标准局数据集合为基准，对所述待核查局数据集合中的数据进行核查，生成核查结果。本发明实施例可以适应多种类型的局数据，具有较好的通用性和可扩展性。
Description
技术领域
本发明涉及网络技术领域，更具体地说涉及一种局数据核查方法和装置。
背景技术
局数据(Office Data)一般被理解为通信网络核心网域各类网络设备上面的数据，可以包括设备自身的配置数据与业务数据。局上的通信设备，如交换机、网关等，需要在配置局数据后，才能与其他局通信设备进行正常通信。因此，对局数据配置得是否正确、完整，只有通过核查才能知道，局数据核查是很有必要的。
传统的核查方法是人工核查，即：由专业人员发送指定命令到交换机查看，在局数据制作人员完成数据制作之后，通过网元的操作维护终端，发送指定命令到交换机查看数据制作情况。按照规范，数据制作和数据核查是被分开的操作流程，需要不同的操作人员进行，因此，很显然，上述方式会耗费大量的人力和物力，维护成本较高，另外，随着通信技术的发展和通信业务的增加，核心网也在逐渐演进，局数据的范畴也从话务路由、信令路由、目的码、漫游等传统电路域相关的话音业务数据，扩充到彩信、短信等分组域相关的新业务数据，海量的数据进一步增加了维护人员的工作量。
为了解决传统核查方法存在的问题，一种改进的核查方法被提出，其主要针对各种类型的局数据，编写特定的核查算法，以方便核查人员核查局数据，减轻核查人员的工作负担，并可保证核查的准确性。
但是，在实现本发明创造的过程中，发明人发现，上述核查方法至少存在以下缺点：
通用性较差，仅能对特定类型数据进行处理，无法对其他类型数据的核查。当需要对多类局数据进行核查时，需要为各类数据都编写特定算法，从而导致人力成本和开发成本增加。
发明内容
有鉴于此，本发明的目的在于提供一种局数据核查方法和装置，以解决现有技术通用性较差的问题。
本发明实施例是这样实现的：
一种局数据核查方法，包括：
预处理步骤：
设置第一类转换规则，将待核查局数据转换成符合预定模型的待核查局数据，每一种转换规则对应一种待核查局数据类型；以及，
设置第二类转换规则，将标准局数据转换成符合预定模型的标准局数据，每一种转换规则对应一种标准局数据类型；
核查步骤：
获取标准局数据集合和原始局数据集合；
将所述原始局数据集合转换成符合标准描述方式的待核查局数据集合；
依据用户输入的核查需求信息确定第一类转换规则和第二类转换规则；
按照所述确定的第二类转换规则，将所述标准局数据集合转换成符合预定模型的标准局数据集合；
按照所述确定的第一类转换规则，将所述待核查局数据集合转换成符合预定模型的待核查局数据集合；
以所述符合预定模型的标准局数据集合为基准，对所述符合预定模型的待核查局数据集合中的数据进行核查，生成核查报告。
优选的，上述方法中，所述预定模型包括键类型和值类型；所述键类型包括属性：索引、核查最大缩位位数和核查最大扩位位数；所述值类型包括参数类型，所述参数类型包括参数类型属性和真实值属性。
优选的，上述方法中，所述预定模型的键类型还可以包括属性：是否允许缩位、是否允许扩位。
优选的，上述方法中，符合所述预定模型的待核查局数据集合中每个键对象的索引，与符合所述预定模型的标准局数据集合中每个键对象的索引相对应。
优选的，上述方法中，所述符合预定模型的待核查局数据及符合预定模型的标准局数据以哈希表形式存储于缓存中。
优选的，上述方法中，所述对所述待核查局数据集合进行核查的结果类型包括以下任意一种或任意组合：
多做数据核查、少做数据核查、错做数据核查和冗余数据核查。
优选的，上述方法中，所述核查报告包括核查结果，所述核查结果包括：多做数据集合、少做数据集合、错做数据集合和冗余数据集合中的任意一种或任意组合。
优选的，上述方法中，所述以所述符合预定模型的标准局数据集合为基准，对所述符合预定模型的待核查局数据集合中的数据进行核查的过程是：
依次以所述标准局数据集合中的索引参数为基准，在待核查局数据中查找与该索引参数相应的数据，如果查找到，则将该相应数据转移到一个预先设置的临时哈希表中，在核查起始时，所述临时哈希表内容为空。
本发明实施例同时还提供一种局数据核查装置，包括：
规则存储单元，用于存储局数据转换规则，包括第一类转换规则和第二类转换规则，第一类转换规则将待核查局数据转换成符合预定模型的待核查局数据，每一种转换规则对应一种待核查局数据类型，第二类转换规则将标准局数据转换成符合预定模型的标准局数据，每一种转换规则对应一种标准局数据类型；
局数据获取单元，用于获取标准局数据集合和原始局数据集合；
规则确定单元，用于依据用户输入的核查需求信息确定待核查局数据的类型，并根据局数据类型和转换规则的对应关系确定相应的转换规则；
第一数据转换单元，用于将所述局数据获取单元得到的原始局数据集合转换成符合标准描述方式的待核查局数据集合；
第二数据转换单元，用于：按照规则存储单元中的第二类转换规则，将局数据获取单元得到的标准局数据集合，转换成符合预定模型的标准局数据集合，以及，按照规则存储单元中的第一类转换规则，将第一数据转换单元得到的待核查局数据集合，转换成符合预定模型的待核查局数据集合；
核查单元，以所述第二数据转换单元得到的标准局数据集合为基准，对所述待核查局数据集合进行核查，生成核查报告。
优选的，上述装置中，所述预定模型包括键型和值类型；所述键类型包括属性：索引、核查最大缩位位数和核查最大扩位位数；所述值类型包括参数类型，所述参数类型包括参数类型属性和真实值属性。
优选的，上述装置中，所述预定模型的键类型还可以包括属性：是否允许缩位、是否允许扩位。
优选的，上述装置中，所述符合预定模型的待核查局数据及符合预定模型的标准局数据以哈希表形式存储于缓存中。
优选的，上述装置中，所述核查单元包括：
查找单元，用于依次以所述标准局数据中的索引参数为基准，在待核查局数据中查找与该索引参数对应数据；
转移单元，用于当所述查找单元在所述待核查局数据查找到相应数据时，将该相应数据转移到一个预先设置的临时哈希表中，在所述查找单元开始工作时，所述临时哈希表内容为空。
优选的，上述装置中，所述核查报告至少包括核查结果，所述核查结果包括：多做数据集合、少做数据集合、错做数据集合和冗余数据集合中的任意一种或任意组合。
优选的，上述装置中，所述规则存储单元中的转换规则以处理类形式存储，所述第二数据转换单元通过加载相应的处理类，具有利用相应的转换规则对标准局数据和待核查局数据进行转换的功能。
通过上述技术方案可知，与现有技术相比，本发明针对局数据处理方式各异、核查主逻辑相同或相似的特点，针对各种类型的局数据设置将局数据转换成符合统一模型的转换规则，并依照相应的转换规则将获取后的局数据转换成符合统一模型的局数据，以便采用统一的核查逻辑进行数据核查。可以看出，本发明实施例可以适应多种类型的局数据，并且，在确定局数据类型后，只需要获取相应的转换规则即可以对该局数据进行核查，具有较好的通用性和可扩展性。并且，设置转换规则可以通过设置处理类的方式实现，通过加载相应的处理类即可对相应类型的局数据进行转换处理，较为方便、灵活。并且，本发明设计在核查开始之前统一读取原始局数据，并转换成符合统一模型的待核查局数据，从而避免了后续核查过程由于可能出现重复核查而引起数据库I/O次数较多的问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为局数据核查基本流程图；
图2为本发明实施例提供的一种局数据核查方法的流程图；
图3为本发明实施例中将原始局数据转换成符合预定模型的局数据的流程图；
图4为本发明实施例提供的一种局数据核查装置的结构示意图；
图5a-图5b为上述局数据核查装置的数据转换单元的两种可能的结构示意图；
图6为上述局数据核查装置的核查单元的结构示意图。
具体实施方式
本文中公开的实施例涉及通信话务交换领域中局数据的核查。
为了引用和清楚起见，本文中使用的各种技术名词或技术术语总结如下：
缩位：指将原有号码缩短位数的处理，例如，861351234缩位成86135123；
扩位：指将原有号码扩充位数的处理，例如，将861351234扩充一位为8613512340～8613512349；
合并：指将位数相等且同属于一个大号段的10、100或1000个号码段合并成一个大号码段，例如8613512340～8613512349这10个号段合并后为861351234。
为了使本领域技术人员能够清楚理解本发明的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
局数据核查基本流程是固定的，如图1所示，首先从网元获取实际局数据，以预先获取的标准局数据为基准，按照预先设定的某种核查分析方式对所述实际局数据进行核查，产生核查结果。
针对局数据核查基本流程大致相同的特点，可以设置一种通用模型，以消除各数据之间的差异性，但是，需要说明的是，虽然局数据核查基本流程相似，但是局数据的类型却是由于其所属网元的类型的不同而有所差别，因此，将不同类型局数据转换成符合同一种模型的局数据的转换规则是不同的。
基于此，本发明实施例公开的局数据核查方法主要包括两个过程：预处理过程和核查过程，其中，预处理过程也可称为数据特性内容处理过程，用于消除待核查局数据的差异性，核查过程用于完成具体核查过程。
所述预处理过程主要是：
根据待核查局数据类型设置转换规则，不同的局数据类型要应用不同的转换规则，例如爱立信的GT数据和号码分析表(也称B表)数据的特征各不相同，因此必须采用适用各自特征的转换规则才能将其转换为共同模型的局数据，例如，实际局数据类型可以包括MSC的GT数据、MSC的号码分析、MSC的国际漫游数据、GMSC的GT数据、GMSC的号码分析数据、HLR的GT数据等各种交换设备中各种局数据。
局数据类型与转换规则的对应关系可以用表格形式表示，如表1所示：
表1
| 局数据类型 | 转换规则标识 |
| 爱立信的GT数据 | EricMscGTCheck |
| 爱立信的号码分析表 | EricMscUniCheck |
| ...... | ...... |
由于需要对获取到的局数据做处理，因此，为了清楚起见，下面将初始获取到的局数据称为原始实际局数据。
核查过程如图2所示，包括以下步骤：
步骤S21、获取原始实际局数据集合和标准局数据集合。
所述标准局数据集合是由运营商或相应用户(例如移动公司)移动公司定时下发的，一般存储于数据库中，所述原始实际局数据集合可以存储于数据库，也可以存放于其他位置(如某台计算机或存储设备)。
步骤S22、将所述原始实际局数据集合转换成符合标准描述方式的实际局数据，即待核查局数据。
步骤S23、依据用户输入的核查需求信息确定实际局数据类型，进而确定相应的转换规则。
实际局数据类型可以是，爱立信的GT数据或号码分析表数据。
所述核查需求信息携带网元类型信息和实际局数据类型信息。
一般来说，实际局数据类型和标准数据类型是相同的，因此，输入信息中仅携带实际局数据类型即可。
而针对实际局数据的转换规则及针对标准局数据的转换规则有可能不同。确定局数据类型的方式有两种：一种是直接依据用户输入信息确定，也就是说，用户需要预先确定需要使用的转换规则，然后输入该转换规则的标识；另一种依据用户输入信息确定局数据类型，并依据预先确定的局数据类型与转换规则的对应关系，确定相应的局数据类型。
步骤S24、利用相应转换规则分别将实际局数据集合和标准局数据集合转换成符合预定模型的待核查局数据集合和标准局数据集合。
所述标准局数据集合和待核查局数据集合可以以哈希表形式存储，存储之后的标准局数据集合和待核查局数据集合即为标准局数据哈希表(stdHash)和待核查局数据哈希表(actHash)。
步骤S25、以所述stdHash为基准，对actHash进行核查，生成核查结果。在将不同类型的局数据进行核查时，经过上述步骤S24之后，就能够将待核查局数据和标准局数据分别转换成符合固定模型的局数据，于是，可以采用同一种核查逻辑进行核查。
上述步骤S22中，所述标准描述方式是指数据表现形式，各种局数据类型对应的标准描述方式是不同的。
标准局数据是由运营商或相应用户下发的，一般符合其对应类型的标准描述方式，而原始实际局数据由于有可能是杂乱的，有可能缺字段或存在一些不必要的字段，或者呈现的形式不同(有些是EXCEL格式，有些是XML格式)，这种情况下，不利于转换为符合预定模型的局数据。因此，需要将原始实际局数据根据其标准描述方式进行转换(例如将其他类型的数据格式转换为XML格式，补充一些必要字段，删除一些非必要字段等)，然后再转换为符合预定模型的局数据。
一般来说，不同类型局数据的标准描述方式是不同的，使用者可以根据需要自行设定，其设定的原则以有利于后续转换符合预定模型的操作为准。
本发明实施例中，所述标准局数据对应的预定模型和所述待核查局数据对应的预定模型可以相同，也可以不同但具有一定的对应关系，所述stdHash中包括多个键，每对键值对应一条数据，并按照键排序；而actHash包括多个键，每对键值对应一条数据，每个键对应所述符合所述stdHash中键模型中的索引。
下面分别对这两种预定模型进行介绍：
所述标准局数据对应的预定模型主要包括所述预定模型包括键类型和值类型；所述键类型包括属性：索引、核查最大缩位位数和核查最大扩位位数；所述值类型包括参数类型，所述参数类型包括参数类型属性和真实值属性。此外，还可以进一步包括：用于指示是否允许缩位、是否允许扩位的属性。具体如表1所示：
表1
| 属性 | 类型 | 含义 |
| 主索引(MainCol) | 字符串 | 数据中主要用来查找的内容 |
| 辅索引(SubCol) | 字符串 | 数据中辅助查找的内容 |
| 索引(StrIndex) | 字符串 | 主索引加辅索引，真正到实际数据中去查找的索引值 |
| 是否允许缩位(Bback) | 布尔 | 核查逻辑依此判断未找到索引值后的进一步处理 |
| 是否允许扩位(Bforward) | 布尔 | 核查逻辑依此判断未找到索引值后的进一步处理 |
| 缩位位数(Nback) | 整型 | 最大缩位位数 |
| 属性 | 类型 | 含义 |
| 扩位位数(Nforward) | 整型 | 最大扩位位数 |
所述值类型为一个可以装载任何对象的集合容器，该容器中至少包括两个对象：0索引和1索引，其中，0索引存放除参数外其他信息内容，1索引存放参数模型对象。另外，还可以根据网络实际运行情况或用户需要增加其他对象。
所述参数类型的结构如表2所示：
表2
| 属性 | 类型 | 含义 |
| 参数类型(Type) | 枚举 | 参数的类型。取值范围0～3分别表示：0——参数唯一值(即标准数据中此参数与实际数据此参数一对一)1——标准数据中此参数与实际数据此参数多对一，标准数据中不同参数值在MyValue中以“，”分割2——标准数据中此参数为一个范围，实际数据参数只要在此范围内就没问题，标准数据中参数范围值在MyValue中以“，”分割为最大最小3——标准数据中此参数与实际数据此参数多对多关系 |
| 真实值(MyValue) | 字符串 | 数据中辅助查找的内容 |
| 显示值(Disp) | 字符串 | 主索引加辅索引，真正到实际数据中去查找的索引值 |
| 错误时显示信息(ErrDisp) | 字符串 | 核查逻辑依此判断未找到索引值后的进一步处理 |
所述待检测局数据对应的预定模型中，每个键值或每些键值组合对应一条数据，具体来说，该预定模型具有以下几个特点：
1、键类型中，键对应为标准数据的索引，所述键一般由相关信息(指不同局数据类型中，唯一标识一条记录的字段组合)拼成字串而成，以便通过标准数据索引查找得到；
2、值类型为一个可以装载任何对象的集合容器，至少包括对象：0索引和1索引，还可以进而包括2索引、3索引等，依实际情况来定，其中，0索引存放除参数外其他信息内容(主要是键相关的，核查结果需要的信息)，从1索引开始存放参数类型对象；
3、参数类型与上述标准数据哈希表中的参数类型基本相同，一般来说，数据核查过程是：依照标准数据的参数类型对象实际数据模型对象，主要比较参数类型中的真实值(MyValue)。
本发明实施例中，对actHash进行的核查的核查结果类型可以包括以下几种核查之一或任意组合：
多做数据核查、少做数据核查、错做数据核查及冗余数据核查。
具体的核查过程是：遍历stdHash和actHash，以对每一键值对进行比较的方式对actHash中每条标准数据进行核查。其中，可以依据键的是否允许缩位(BBack)、是否允许扩位(Bforward)的属性决定是否采用缩位核查(BackChecker)、扩位核查(ForwardChecker)和键浏览(BrowseKey)操作。
下面介绍BackChecker、ForwardChecker和BrowseKey的具体实现过程：
BrowseKey操作的过程如下：
依次以所述标准局数据中的索引参数为基准，在待核查局数据中查找相应数据，如果查找到，则将该相应数据转移到一个预先设置的临时哈希表atempHash中，并进一步比较数据的值，如果未找到，则确定该数据漏做，如果找到两个以上相同数据，则确定该数据冗余。需要说明的是，本发明实施例按照不同类型值采用不同逻辑对数据进行比较或判断：
对于参数唯一性数据，直接比较其MyValue属性；
如果stdHash中某数据的参数与actHash中相应的数据的参数是多对一的，则将stdHash中该参数的MyValue属性分割成若干部分，并将actHash中相应参数的MyValue与上述分割之后的各部分进行比较；
如果stdHash中某数据的参数的数值为一个范围，则判断actHash中相应数据的参数的MyValue值是否处于所述范围内，依据判断结果确定数据是否正确；
如果stdHash中某数据的参数与actHash中相应数据的参数是多对多的，则分别将stdHash中数据的参数的MyValue值、actHash中相应数据的参数的MyValue值分割成若干部分，stdHash中数据的参数对应的各部分与actHash中相应数据的参数对应各各部分两两比较，依据比较结果确定数据是否正确。
当上述比较结果为一致时，表示数据正确，否则，则表示数据错误，当在actHash中找不到相应数据时，当然，这有可能不是最终结果，因为，有些情况下，需要进行BackChecker或ForwardChecker。
BackChecker的具体过程是：循环缩减固定位数(一般为1位)，调用上述BrowseKey操作，当需要进行冗余核查或多做核查时，每缩减一位，就要调用上述BrowseKey操作，直到缩减的位数达到预定最大值(Nback)，如果缩减的位数达到Nback时仍然查找不到相应数据，则可认为该数据被漏做，如果查找到相同数据数量多于2条，则认为该数据被重复做了(即冗余)。
ForwardChecker实际上是一个递归调用的方法，其具体过程是：循环扩展固定位数(一般为1位)，调用上述BrowseKey对扩展后的数据进行操作，由于扩展1位就增加了10个号段，所以需要BrowseKey循环10次操作。如果扩展的位数达到预定最大值(Nforward)时，仍然查找不到相应数据，则可认为该数据被漏做，如果查找到相同数据数量多于2条，则认为该数据被重复做了(即冗余)。
需要说明的是，本发明实施例中，核查之后生成的核查报告也可以符合预定信息模型，该信息模型包括：多做数据集合、漏做数据集合、错做数据集合及其他错误数据集合等属性中的任意一个或者任意组合，还可以进一步包括实际数据获取时间、实际数据存储ID、标准数据时间、表格列数和表格标题，需要说明的是，是否需要进行“多做数据核查”及报“多做数据集合”可以由“报多做判断”属性确定，是否进行其他核查种类也可以由同样的方式确定。核查报告的信息模型具体内容如表3所示：
表3
| 属性 | 类型 | 含义 |
| 核查时间(CheckTime) | 时间 | 存储核查开始的时间 |
| 实际数据获得时间(ActDataTime) | 时间 | 存储实际数据获得的时间 |
| 实际数据存储ID(ActId) | 整型 | 实际数据存储的标识，据此可以链接实际数据 |
| 标准数据时间(StdDataTime) | 哈希 | 对应多份标准数据，以名为键获得时间为值 |
| 多做数据集合(SurpResultList) | 集合容器 | 多做的核查结果 |
| 漏做数据集合(LeakResultList) | 集合容器 | 漏做的核查结果 |
| 错做数据集合(FaultResultList) | 集合容器 | 错做的核查结果 |
| 其他错误数据集合(OtherResultList) | 集合容器 | 其他的核查结果 |
| 表格列数(ColCount) | 整型 | 显示结果的列数 |
| 属性 | 类型 | 含义 |
| 表格标题(ColName) | 字符串 | 显示核查结果的标题 |
| 报多做判断(IsReportSurp) | 布尔 | 判断需要报多做的标志 |
本发明实施例针对各类局数据核查逻辑大致相同或相似的特点，分别为标准局数据和待核查局数据设置了统一模型，以便可以依照同一种核查方式进行核查，同时，针对不同局数据的数据特性，设置将各种局数据转换为符合统一模型的局数据的转换规则，因此在确定待核查局数据类型后，即可利用相应的转换规则将待核查局数据进行转换，消除了不同类型局数据之间的差异性。因此，本发明实施例可以核查多种类型的局数据，并且，只需要获取相应的转换规则即可以对相应的局数据进行核查，具有较好的通用性和可扩展性。
需要说明的是，在核查过程中，由于核查结果(如多做核查、少做核查)的不同，有可能需要重复核查，现有技术由于无法确定核查项目(一般都是技术人员随机进行)，同时，待核查局数据和标准局数据均是存储于数据库中，并且，其数据查找逻辑和核查逻辑是结合的，也就是说，其核查过程包括数据查找，查找数据是在核查过程中进行的，因此，其无法预先将待核查局数据统一读取。核查一次就需要数据库I/O一次，反复数据库I/O势必带来较大的系统开销。而本发明实施例中，在核查之前的转换过程中已经将待核查局数据和标准局数据都统一获取了，因此，可以将获取的待核查局数据和标准局数据放置于比数据库访问更快的缓存中(如设备内存)，于是，在后续核查过程中无需多次访问(甚至无需访问)数据库，大大减少了数据库的I/O次数，并加快了核查进程。
另外，需要说明的是，上述本发明实施例减少数据库I/O次数的特点显著地体现在确定多做数据核查结果的方式上，本发明实施例中，数据核查方式为：设置一个atempHash，将依据StdHash查找到的数据从actHash转移到atempHash，于是，当需要报多做结果时，直接将actHash剩余的数据作为多做数据集合即可，方便、快捷，并且不容易出错。
下面通过一个具体例子详细介绍本发明实施例中如何将原始局数据转换成符合预定模型的局数据：
假设需要进行爱立信公司网元设备的MSC(移动交换中心)用户GT(全局码)数据核查，其过程如下：
步骤S31、获取标准局数据和原始实际局数据。
所述标准局数据包括《BOSS帐户号码汇总表》、《LSTPHSTP数据汇总表》和《本省数据设置原则》等三个数据表，分别如表4、表5和表6所示。所述原始局数据取自安徽省安庆市一个爱立信MSC的GT数据，如表7所示。
表4
| 省份 | 城市 | 区号 | 万号段/千号段 | 归属二卡合一SCP名称 | 归属二卡合一SCPMSCID | 归属彩信中心名称 | 归属彩信中心ID | 启用局数据号 |
| 辽宁 | 丹东 | 415 | 1347000 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 阜新 | 418 | 1347036 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 朝阳 | 421 | 1347023 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 丹东 | 415 | 1347006 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 辽阳 | 419 | 1347039 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 丹东 | 415 | 1347009 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 抚顺 | 413 | 1347051 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 丹东 | 415 | 1347045 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 铁岭 | 410 | 1347015 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 丹东 | 415 | 1347003 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 朝阳 | 421 | 1347025 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 铁岭 | 410 | 1347012 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 朝阳 | 421 | 1347022 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 阜新 | 418 | 1347031 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 辽宁 | 盘锦 | 427 | 1347018 | 沈阳SCP2 | 13740404 | 沈阳彩信中心1 | 924000 | 527 |
| 安徽 | 六安 | 564 | 1347087 | 合肥SCP1-1 | 13740551 | 合肥彩信中心1 | 955100 | 509 |
| 安徽 | 马鞍山 | 555 | 1347095 | 合肥SCP1-1 | 13740551 | 合肥彩信中心1 | 955100 | 560 |
| 安徽 | 黄山 | 559 | 1347091 | 合肥SCP1-1 | 13740551 | 合肥彩信中心1 | 955100 | 560 |
可以看出，上述标准局数据包括：省份、城市、区号、万号段/千号段、归属二卡合一SCP名称、归属二卡合一SCP MSCID、归属彩信中心名称、归属彩信中心ID、启用局数据号等属性。
表5
| 安徽 | 合肥 | 合肥H2 | 551 | 12-255-4 | |
| 安徽 | 合肥 | 合肥H1 | 551 | 12-255-5 | |
| 安徽 | 合肥 | 合肥LSTP1 | 551 | 12-255-12 | 455 |
| 安徽 | 合肥 | 合肥LSTP2 | 551 | 12-255-13 | 455 |
| 安徽 | 合肥 | 合肥LSTP4 | 551 | 12-255-15 | 455 |
| 安徽 | 合肥 | 合肥LSTP3 | 551 | 12-255-14 | 455 |
表5是一个LSTP HSTP数据汇总表，LSTP(Low Signal transfer point)即低级信令转接点，用于实现省内信令转接；HSTP(High Signal transferpoint)即高级信令转接点，用于实现省外信令转接。LSTP HSTP数据汇总表包含省内信令转接和省外信令转换内容。
表6
| 本地区 | 同属一个LSTP的外地区 | 其它外地区 | 外省 | |
| 用户号段 | 0 | 1 | 1 | 2 |
本省数据设置原则说明：
用0表示：DPC(消息要发送目的地信号的编码)至HLR(HomeLocation register，位置归属寄存器)；
用1表示：GT至本地区所属LSTP；
用2表示：GT至HSTP；
该设置原则可以根据网络具体情况设定。
表7
表7中，TT指的是：Translation Type，即翻译类型；NP指的是：Number Plan，即编码计划；GTRC指的是GT路由码；PSP指的是：主用信令点编码；SSP指的是：备用信令点编码；PTYPE指的是寻址方式。
步骤S32、将原始局数据集合转换成符合标准描述方式的数据集合。
为了方便将原始实际局数据集合转换成符合预定模型的局数据集合，需要将原始局数据集合转换成符合标准描述方式的局数据集合，也即，将表7所包含数据转换成符合标准描述方式的数据，如表8所示：
表8
| <？xml version＝″1.0″encoding＝″gb2312″？><analys_data><C7GSP_PART><line gt_number＝″1″num_plan＝″1″gtrc＝″4″/><line gt_number＝″2″num_plan＝″1″gtrc＝″4″/><line gt_number＝″3″number_plan＝″1″gtrc＝″4″/><line gt_number＝″4″num_plan＝″1″gtrc＝″4″/><line gt_number＝″5″num_plan＝″1″gtrc＝″4″/><line gt_number＝″6″num_plan＝″1″gtrc＝″4″/><line gt_number＝″7″num_plan＝″1″gtrc＝″4″/><line gt_number＝″80″num_plan＝″1″gtrc＝″4″/><line gt_number＝″81″nun_plan＝″1″gtrc＝″4″/><line gt_number＝″82″num_plan＝″1″gtrc＝″4″/><line gt_number＝″83″num_plan＝″1″gtrc＝″4″/><line gt_number＝″84″num_plan＝″1″gtrc＝″4″/><line gt_number＝″85″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861340″num_plan＝″1″gtrc＝″4″/> |
| <line gt_number＝″861341″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861342″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861343″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861344″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861345″num_plan＝″1″gtrc＝″4″/><line gt_number＝″861346″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134700″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134701″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134702″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134703″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134704″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134705″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134706″num_plan＝″1″gtrc＝″4″/><line gt_number＝″86134707″num_plan＝″1″gtrc＝″14″/><line gt_number＝″86134708″num_plan＝″1″gtrc＝″14″/><line gt_number＝″86134709″num_plan＝″1″gtrc＝″14″/><line gt_number＝″861386556″num_plan＝″1″gtrc＝″160″/></C7GSP_PART><GTRC_PART><line gtrc＝″4″dpc＝″12-255-4″sccp_rt_ind＝″0″dpc2＝″12-255-5″/><line gtrc＝″14″dpc＝″12-255-14″sccp_rt_ind＝″0″dpc2＝″12-255-15″/><line gtrc＝″160″dpc＝″12-255-160″sccp_rt_ind＝″1″dpc2＝″″/></GTRC_PART></analys_data> |
即将数据记录的描述方式进行转换，例如：
将数据记录：“0 1 4 1 4”，转换为“<line gt_number＝″1″num_plan＝″1″gtrc＝″4″/>。
步骤S33、依据预先根据用户输入核查需求信息生成的配置文件信息确定待核查局数据类型，进而确定待核查局数据及标准局数据的转换规则。
在本实施例中，所述配置文件中包含用户输入的局数据类型及转换规则名称。
该配置文件信息可以是XML形式，如下：
<CheckType id＝″USERGT″name＝″用户GT″ignoreVendor＝″Yes″IOCClass＝″MscUserGtCheck″/>
<CheckType id＝″UNICALL″name＝″B-Number联通号码″ignoreVendor＝″No″ vendor＝″Ericsson″ vendor_id＝″1″ version＝″″IOCClass＝″EricMscUniCheck″/>
其中：
属性id代表局数据类型；
属性name用于UI(用户界面)呈现；
属性ignoreVendor用于设置该类数据核查是否忽略厂家信息，通用该类型数据所有厂家；属性IOCClass代表该类型局数据的转换规则名称；
属性vendor代表在不忽略厂家信息时，对应厂家名；
属性vendor_id代表在不忽略厂家信息时，适应厂家id(厂家名称与id一一对应)；
属性version代表该厂家此类设备的软件版本；
步骤S34、分别依据对应的转换规则将原始标准局数据集合及符合标准描述方式的数据集合转换成符合预定模型的标准局数据集合(stdHash)和待检测局数据集合(actHash)。
对于爱立信公司的R10版本的MSC的GT数据，一条记录可以用“NP(Number Plan，编码计划)+GT Number(全局码)”作为唯一标识，那么在进行转换时，将这两个字段的组合作为“键”，并且，按照爱立信公司R10版本的MSC自身处理信令路由方式(在没有长字段时寻找短号段进行路由)确定核查过程中应该对“键”进行缩位。每条记录的其他字段：TT、GTRC、SSP、PTYPE在核查时需要比对确认是否正确，所以需要将这些字段依次加载为对应的参数模型并放入“值”集合中。并且，由于GT分为两种编码计划的号段数据，都要进行核查，所以，当编码计划采用E164时确定SubCol为1，MainCol为对应这个编码计划的用户号段。
于是，转换后的标准局数据集合和待核查局数据集合如下：
一、标准局数据集合
转换之后的标准局数据集合中的数据的键对象属性如下：
属性BBack为true；
属性Bforward为true；
属性MainCol为《BOSS账户号码汇总表》或《智能网帐户号码汇总表》中“万号段/千号段”取一条861347000；
属性SubCol为1(移动集团提供号段汇总表中号段均为E164编码计划)；
属性Nback为MainCol长度减4，也就是需要缩4位核查；
属性Nforward为13减MainCol长度，也就是需要扩位到13位进行核查。
转换之后的标准数据的值对象为一个ArrayList(是List接口的一个可变长数组实现，实现所有List接口的操作，并允许存储null值)属性如下：
0位置为“辽宁，丹东，415,861347000，全球通，E164,527”；
1位置为寻址方式参数CompareParameter模型对象；
属性Type为0；
属性MyValue为0；
属性Disp为“GT寻址”；
属性ErrDisp为“寻址方式错误”；
2位置为信令点编码参数CompareParameter模型对象；
属性Type为3；
属性MyValue为安徽省HSTP信令点编码“12-255-4，12-255-5”；
属性Disp为“寻址到HSTP”；
属性ErrDisp为“指向错误”。
二、待核查局数据集合
待核查局数据键对象，为爱立信分析后数据中<C7GSP_PART>节点下<line>节点中num_plan属性加“，”加gt_number属性，即“1,86134700”
待核查局数据值对象为一个ArrayList实例：
0位置为“86134700,1”
1位置为寻址方式参数CompareParameter模型对象
属性Type为0
属性MyValue为0
属性Disp为“GT寻址”
属性ErrDisp为“”
2位置为信令点编码参数CompareParameter模型对象
属性Type为3
属性MyValue为安徽省HSTP信令点编码“12-255-4，12-255-5”
属性Disp为“12-255-4，12-255-5”
属性ErrDisp为“”。
在将原始标准局数据集合及符合标准描述方式的数据集合转换成符合预定模型的局数据集合之后，按照前文所述的核查方式对所述待核查局数据集合进行核查，并生成核查报告。
本发明实施例同时还公开了一种实现上述方法的局数据核查装置，其结构如图4所示，包括：规则存储单元41、规则确定单元42、数据获取单元43、第一数据转换单元44、第二数据转换单元45、核查单元46和结果生成单元47。
其中：
规则存储单元41，用于存储局数据转换规则，包括第一类转换规则和第二类转换规则，第一类转换规则将待核查局数据转换成符合预定模型的待核查局数据，每一种转换规则对应一种待核查局数据类型，第二类转换规则将标准局数据转换成符合预定模型的标准局数据，每一种转换规则对应一种标准局数据类型；
规则确定单元42，用于依据用户输入的核查需求信息确定待核查局数据的类型，并根据局数据类型和转换规则的对应关系确定相应的转换规则；
局数据获取单元43，用于获取标准局数据集合和原始局数据集合。
第一数据转换单元44，用于将所述原始局数据集合转换成符合标准描述方式的待核查局数据集合。
第二数据转换单元45，按照规则存储单元中的第二类转换规则，将局数据获取单元得到的标准局数据集合，转换成符合预定模型的标准局数据集合，以及，按照规则存储单元中的第一类转换规则，将第一数据转换单元得到的待核查局数据集合，转换成符合预定模型的待核查局数据集合。
所述标准局数据集合对应的第二预定模型和所述待核查局数据的第一预定模型在前文方法部分已有详细描述，在此不再赘述。
所述标准局数据集合和待核查局数据集合可以以哈希表的形式存储。
核查单元46，用于以所述标准局数据集合为基准，对所述待核查局数据进行核查，并生成核查报告。其核查的方式可以是多做数据核查、少做数据核查、错做数据核查及冗余数据核查中的任意一种或任意组合。
本实施例中，所述核查报告也可以符合某预定模型，该预定模型具体内容在前文方法部分也有详细描述，在此同样不再赘述。
本发明实施例预先为各类局数据设定相应的转换为符合统一模型的规则，在确定待核查局数据的类型后，按照相应的转换规则即可将所述待核查局数据转换为符合预定模型的待核查局数据，从而可以按照统一核查逻辑对各类局数据进行核查，具有较好的通用性。并且，只需要增加或者改变相应转换规则即可对相应类别局数据进行核查，具有较好可扩展性。
需要说明的是，本发明实施例的核查过程可通过计算机程序实现，设置转换规则可以通过设置处理类的方式实现，即：对应局数据类型设置相应处理类。针对不同类型的局数据，第二数据转换单元45通过加载相应的处理类即可具备依据相应的转换规则将局数据转换为符合统一模型的局数据的功能，这使得本实施例可以适应多种类型的局数据。在将局数据转换为符合统一模型的局数据之后，即消除了原始局数据的差异性，从而使得提供给核查单元的待核查局数据和标准数据都是固定的格式，核查单元可按照同一种核查逻辑进行核查。而所述处理类可以增加或删除或改变，从而大大提升了技术方案的可扩展性，并且，通过加载相应的处理类即可对相应类型的局数据进行转换处理，较为方便、灵活。
另外，核查单元可按照同一种核查逻辑进行核查的特点意味着该核查单元的功能可通过一次性编程实现，而无需如现有技术需要针对特定类型局数据编写相应的核查程序，从而有效减少了编程人员的工作负担。
另外，由于本发明实施例在进行核查过程之前已将待核查局数据统一获取并转换，因此，在核查过程中无需多次访问数据库，甚至无需访问数据库，从而避免了核查过程中的数据库I/O。
为了清楚地描述本发明实施例消除不同局数据类型的局数据的差异性的功能，下面结合图5a和图5b进行描述：
当需要对A类型局数据进行核查时，如图5a，数据转换单元45分别依据规则确定单元42从预先设置的多个转换规则中获取对应的转换规则(针对待核查局数据的转换规则A1和针对标准局数据的转换规则A2)，分别由第一转换子单元将已经被处理成符合标准描述方式的待核查局数据转换为符合统一模型(模型x)的待核查局数据，并且，由第二转换子单元依据该转换规则A2将标准局数据转换为符合统一模型(模型y)的标准局数据集合。当需要对B类型局数据进行核查时，如图5b，数据转换单元45分别依据规则确定单元42从预先设置的多个转换规则中获取对应的转换规则(针对待核查局数据的转换规则A1和针对标准局数据的转换规则A2)，由第一转换子单元将已经被处理成符合标准描述方式的待核查局数据转换为符合统一模型(模型x)的待核查局数据，并且，由第二转换子单元依据该转换规则A2将标准局数据转换为符合统一模型(模型y)的标准局数据集合。当然，所述模型y和模型x可以相同，也可以是不同的。
需要说明的是，核查单元46进行多做数据核查时，其结构形式可以如图6所示，包括：查找单元61和转移单元62；
查找单元61，用于依次以所述标准局数据集合中的索引参数为基准，在待核查局数据集合中查找相应数据。
转移单元62，用于当查找单元62在所述待核查局数据集合中查找到相应数据时，将该相应数据转移到一个预先设置的临时哈希表中，在所述查找单元开始工作时，所述临时哈希表内容为空。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置而言，由于其与上述方法基本相似，所以描述得比较简单，相关之处参见前文方法部分说明即可。
本领域技术人员可以理解，可以使用许多不同的工艺和技术中的任意一种来表示信息、消息和信号。例如，上述说明中提到过的消息、信息都可以表示为电压、电流、电磁波、磁场或磁性粒子、光场或以上任意组合。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (15)
1.一种局数据核查方法，其特征在于，包括：
预处理步骤：
设置第一类转换规则，将待核查局数据转换成符合预定模型的待核查局数据，每一种转换规则对应一种待核查局数据类型；以及，
设置第二类转换规则，将标准局数据转换成符合预定模型的标准局数据，每一种转换规则对应一种标准局数据类型；
核查步骤：
获取标准局数据集合和原始局数据集合；
将所述原始局数据集合转换成符合标准描述方式的待核查局数据集合；
依据用户输入的核查需求信息确定第一类转换规则和第二类转换规则；
按照所述确定的第二类转换规则，将所述标准局数据集合转换成符合预定模型的标准局数据集合；
按照所述确定的第一类转换规则，将所述待核查局数据集合转换成符合预定模型的待核查局数据集合；
以所述符合预定模型的标准局数据集合为基准，对所述符合预定模型的待核查局数据集合中的数据进行核查，生成核查报告。
2.如权利要求1所述的方法，其特征在于，所述预定模型包括键类型和值类型；所述键类型包括属性：索引、核查最大缩位位数和核查最大扩位位数；所述值类型包括参数类型，所述参数类型包括参数类型属性和真实值属性。
3.如权利要求2所述的方法，其特征在于，所述预定模型的键类型还可以包括属性：是否允许缩位、是否允许扩位。
4.如权利要求3所述的方法，其特征在于，符合所述预定模型的待核查局数据集合中每个键对象的索引，与符合所述预定模型的标准局数据集合中每个键对象的索引相对应。
5.如权利要求1至4中的任一项所述的方法，其特征在于，所述符合预定模型的待核查局数据及符合预定模型的标准局数据以哈希表形式存储于缓存中。
6.如权利要求1所述的方法，其特征在于，所述对所述待核查局数据集合进行核查的结果类型包括以下任意一种或任意组合：
多做数据核查、少做数据核查、错做数据核查和冗余数据核查。
7.如权利要求1所述的方法，其特征在于，所述核查报告包括核查结果，所述核查结果包括：多做数据集合、少做数据集合、错做数据集合和冗余数据集合中的任意一种或任意组合。
8.如权利要求7所述的方法，其特征在于，所述以所述符合预定模型的标准局数据集合为基准，对所述符合预定模型的待核查局数据集合中的数据进行核查的过程是：
依次以所述标准局数据集合中的索引参数为基准，在待核查局数据中查找与该索引参数相应的数据，如果查找到，则将该相应数据转移到一个预先设置的临时哈希表中，在核查起始时，所述临时哈希表内容为空。
9.一种局数据核查装置，其特征在于，包括：
规则存储单元，用于存储局数据转换规则，包括第一类转换规则和第二类转换规则，第一类转换规则将待核查局数据转换成符合预定模型的待核查局数据，每一种转换规则对应一种待核查局数据类型，第二类转换规则将标准局数据转换成符合预定模型的标准局数据，每一种转换规则对应一种标准局数据类型；
局数据获取单元，用于获取标准局数据集合和原始局数据集合；
规则确定单元，用于依据用户输入的核查需求信息确定待核查局数据的类型，并根据局数据类型和转换规则的对应关系确定相应的转换规则；
第一数据转换单元，用于将所述局数据获取单元得到的原始局数据集合转换成符合标准描述方式的待核查局数据集合；
第二数据转换单元，用于：按照规则存储单元中的第二类转换规则，将局数据获取单元得到的标准局数据集合，转换成符合预定模型的标准局数据集合，以及，按照规则存储单元中的第一类转换规则，将第一数据转换单元得到的待核查局数据集合，转换成符合预定模型的待核查局数据集合；
核查单元，以所述第二数据转换单元得到的标准局数据集合为基准，对所述待核查局数据集合进行核查，生成核查报告。
10.如权利要求9所述的装置，其特征在于，所述预定模型包括键型和值类型；所述键类型包括属性：索引、核查最大缩位位数和核查最大扩位位数；所述值类型包括参数类型，所述参数类型包括参数类型属性和真实值属性。
11.如权利要求10所述的方法，其特征在于，所述预定模型的键类型还可以包括属性：是否允许缩位、是否允许扩位。
12.如权利要求9至11中的任一项所述的装置，其特征在于，所述符合预定模型的待核查局数据及符合预定模型的标准局数据以哈希表形式存储于缓存中。
13.如权利要求9所述的装置，其特征在于，所述核查单元包括：
查找单元，用于依次以所述标准局数据中的索引参数为基准，在待核查局数据中查找与该索引参数对应数据；
转移单元，用于当所述查找单元在所述待核查局数据查找到相应数据时，将该相应数据转移到一个预先设置的临时哈希表中，在所述查找单元开始工作时，所述临时哈希表内容为空。
14.如权利要求9所述的装置，其特征在于，所述核查报告至少包括核查结果，所述核查结果包括：多做数据集合、少做数据集合、错做数据集合和冗余数据集合中的任意一种或任意组合。
15.如权利要求9至11中的任一项所述的装置，其特征在于，所述规则存储单元中的转换规则以处理类形式存储，所述第二数据转换单元通过加载相应的处理类，具有利用相应的转换规则对标准局数据和待核查局数据进行转换的功能。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810247037A CN101772043B (zh) | 2008-12-31 | 2008-12-31 | 局数据核查方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810247037A CN101772043B (zh) | 2008-12-31 | 2008-12-31 | 局数据核查方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101772043A true CN101772043A (zh) | 2010-07-07 |
| CN101772043B CN101772043B (zh) | 2012-09-26 |
Family
ID=42504557
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810247037A Active CN101772043B (zh) | 2008-12-31 | 2008-12-31 | 局数据核查方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101772043B (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103064909A (zh) * | 2012-12-19 | 2013-04-24 | 武汉虹翼信息有限公司 | 一种基于Drools规则引擎的基站数据库核查方法 |
| CN103188094A (zh) * | 2011-12-28 | 2013-07-03 | 中国移动通信集团贵州有限公司 | 一种资源数据核查系统和方法 |
| CN104007984A (zh) * | 2014-06-20 | 2014-08-27 | 中国银行股份有限公司 | 一种转换数据的方法及装置 |
| CN104361050A (zh) * | 2014-10-29 | 2015-02-18 | 中国建设银行股份有限公司 | 一种数据转化比对方法及装置 |
| CN108959648A (zh) * | 2018-08-02 | 2018-12-07 | 苏州神州数码捷通科技有限公司 | 海关业务申报风险核查系统 |
| CN109039710A (zh) * | 2018-07-10 | 2018-12-18 | 中国联合网络通信集团有限公司 | 路由数据稽核方法、装置、服务器及存储介质 |
| CN111639079A (zh) * | 2020-05-29 | 2020-09-08 | 杭州东方通信软件技术有限公司 | 一种面向内容计费业务的局数据核查方法及设备 |
| CN112508433A (zh) * | 2020-12-16 | 2021-03-16 | 广东电网有限责任公司惠州供电局 | 一种运维系统的数据稽查方法及装置 |
| CN113468401A (zh) * | 2020-03-31 | 2021-10-01 | 中移系统集成有限公司 | 局数据核查制作方法、装置、计算机设备和存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100502545C (zh) * | 2006-12-26 | 2009-06-17 | 北京亿阳信通软件研究院有限公司 | 一种通信网络配置参数的智能核查方法和装置 |
| CN101308495B (zh) * | 2007-10-24 | 2011-05-25 | 河北全通通信有限公司 | 局数据核查制作方法 |
| CN101197875A (zh) * | 2007-12-26 | 2008-06-11 | 华为技术有限公司 | 局数据核查方法及装置 |
-
2008
- 2008-12-31 CN CN200810247037A patent/CN101772043B/zh active Active
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103188094A (zh) * | 2011-12-28 | 2013-07-03 | 中国移动通信集团贵州有限公司 | 一种资源数据核查系统和方法 |
| CN103064909B (zh) * | 2012-12-19 | 2016-08-17 | 武汉虹翼信息有限公司 | 一种基于Drools规则引擎的基站数据库核查方法 |
| CN103064909A (zh) * | 2012-12-19 | 2013-04-24 | 武汉虹翼信息有限公司 | 一种基于Drools规则引擎的基站数据库核查方法 |
| CN104007984A (zh) * | 2014-06-20 | 2014-08-27 | 中国银行股份有限公司 | 一种转换数据的方法及装置 |
| CN104007984B (zh) * | 2014-06-20 | 2017-06-16 | 中国银行股份有限公司 | 一种转换数据的方法及装置 |
| CN104361050A (zh) * | 2014-10-29 | 2015-02-18 | 中国建设银行股份有限公司 | 一种数据转化比对方法及装置 |
| CN109039710B (zh) * | 2018-07-10 | 2021-06-01 | 中国联合网络通信集团有限公司 | 路由数据稽核方法、装置、服务器及存储介质 |
| CN109039710A (zh) * | 2018-07-10 | 2018-12-18 | 中国联合网络通信集团有限公司 | 路由数据稽核方法、装置、服务器及存储介质 |
| CN108959648A (zh) * | 2018-08-02 | 2018-12-07 | 苏州神州数码捷通科技有限公司 | 海关业务申报风险核查系统 |
| CN113468401A (zh) * | 2020-03-31 | 2021-10-01 | 中移系统集成有限公司 | 局数据核查制作方法、装置、计算机设备和存储介质 |
| CN113468401B (zh) * | 2020-03-31 | 2023-04-28 | 中移系统集成有限公司 | 局数据核查制作方法、装置、计算机设备和存储介质 |
| CN111639079A (zh) * | 2020-05-29 | 2020-09-08 | 杭州东方通信软件技术有限公司 | 一种面向内容计费业务的局数据核查方法及设备 |
| CN112508433A (zh) * | 2020-12-16 | 2021-03-16 | 广东电网有限责任公司惠州供电局 | 一种运维系统的数据稽查方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101772043B (zh) | 2012-09-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101772043B (zh) | 局数据核查方法和装置 | |
| US6915340B2 (en) | System and method for deriving future network configuration data from the current and previous network configuration data | |
| CN101192237B (zh) | 查询多方面信息的方法和系统 | |
| CN105740411B (zh) | 一种基于SOA和WebService的数据迁移方法 | |
| CN102780574B (zh) | 面向业务的局数据的配置方法、装置以及核查方法、装置 | |
| CN111459985A (zh) | 标识信息处理方法及装置 | |
| CN106407303A (zh) | 数据存储、查询方法及装置 | |
| US20120254849A1 (en) | Ontology updating apparatus, method and system | |
| CN109213758B (zh) | 数据存取方法、装置、设备及计算机可读存储介质 | |
| CN106155775B (zh) | 消息处理方法、设备及系统 | |
| CN104021123A (zh) | 用于数据迁移的方法和系统 | |
| CN104091228A (zh) | 物联网资源管理、注册、查询和语义库管理系统 | |
| CN111680489B (zh) | 目标文本的匹配方法和装置、存储介质及电子设备 | |
| US10776313B2 (en) | Converting source objects to target objects | |
| CN101963993B (zh) | 一种数据库单表记录快速查找的方法 | |
| CN101986282B (zh) | 拓扑适配方法及装置 | |
| CN106095511A (zh) | 一种服务器升级方法和装置 | |
| CN105843809A (zh) | 数据处理方法和装置 | |
| CN104750468A (zh) | 一种服务端拓扑数据转换方法和转换装置 | |
| CN109739910B (zh) | 一种开放性标签管理方法和系统 | |
| WO2020080492A1 (ja) | ネットワーク管理装置、方法およびプログラム | |
| KR101927689B1 (ko) | Cim 계통도 처리 방법 | |
| CN102651859B (zh) | 识别号码携带用户的运营商归属的方法、设备及网络 | |
| CN111737529B (zh) | 一种多源异构数据采集方法 | |
| CN105095283A (zh) | 网络社交系统中准好友的推荐方法和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: YIYANG XINTONG CO., LTD. Free format text: FORMER OWNER: BEIJING BRIGHT OCEANS INTER-TELECOM TECHNOLOGY CO., LTD. Effective date: 20120801 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| C53 | Correction of patent for invention or patent application | ||
| CB03 | Change of inventor or designer information |
Inventor after: Yuan Zhanxue Inventor after: Shi Haohua Inventor after: Chen Dan Inventor before: Yuan Zhanxue |
|
| COR | Change of bibliographic data |
Free format text: CORRECT: INVENTOR; FROM: YUAN ZHANXUE TO: YUAN ZHANXUE SHI HAOHUA CHEN DAN |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20120801 Address after: 100093, Beijing, Haidian District apricot Road, No. 99, West win government house, B seat Applicant after: Yiyang Xintong Co., Ltd. Address before: 100093, Beijing, Haidian District, apricot Road, No. 99, block B Applicant before: Beijing BOCO Inter-Telecom Technology Co., Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |