CN101232538A - 业务数据合并的方法及装置 - Google Patents
业务数据合并的方法及装置 Download PDFInfo
- Publication number
- CN101232538A CN101232538A CNA2008100028001A CN200810002800A CN101232538A CN 101232538 A CN101232538 A CN 101232538A CN A2008100028001 A CNA2008100028001 A CN A2008100028001A CN 200810002800 A CN200810002800 A CN 200810002800A CN 101232538 A CN101232538 A CN 101232538A
- Authority
- CN
- China
- Prior art keywords
- data
- business entity
- information
- unit
- group
- 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.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
一种业务数据合并的方法及装置,其主要包括:首先,按照待合并的各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;之后,将组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。本发明实施例中,由于通过特定的数据导入、导出方式,从而可以有效地解决现有技术中可能出现的异常问题,进而可以提高数据配置的效率。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种业务数据合并技术。
背景技术
在通信系统中,为满足运营商不断变化的业务发展的需求,需要提供灵活的电信业务平台,以便电信运营商能够实现业务的推广应用,如实现更多、更复杂的灵活资费套餐等。
电信业务平台通常为基于数据驱动实现,即电信业务平台除了包含实现业务框架逻辑的应用软件,还包括实现电信业务逻辑的数据模型,相应的数据模型可以为用户、客户、帐户、产品模型等等,且数据模型是通过物理数据库的多个实体表进行表达,实体表之间通过相关的字段建立其内在的逻辑关系。在业务发展的过程中,为推广新的业务或新的资费套餐,需要进行相应的业务数据配置操作。目前,通常是通过图形化的展示界面实现相应的业务数据配置操作作,以实现新的电信业务的处理流程或新的资费套餐等。
在进行数据配置或更新过程中,为保证数据的逻辑的准确性,则需要对配置的电信业务逻辑数据进行验证。而且,为了避免相互之间的影响以及应用环境中的主机资源、数据库性能等的限制,通常需要多人在相互独立的应用环境下分别完成业务数据的配置验证工作。即相应的验证工作需要由多人分工并行完成,之后,再将多个并行完成的工作进行合并处理,从而获得完整的配置数据。
在实现本发明过程中,发明人发现现有技术中至少存在如下问题:
在合并多个业务实体表数据的过程中,经常会出现键值冲突等问题。以键值冲突问题为例,由于业务实体表之间可能存在着内在的逻辑关系,因而使得无法通过简单的方式手工修改调整发生冲突的键值。
发明内容
本发明的实施例提供了一种业务数据合并的方法及装置,从而可以有效解决针数据合并过程中可能出现的问题。
一种业务数据合并的方法,包括:
按照待合并的各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;
将组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。
一种业务数据合并的装置,包括:
导出单元,用于按照待合并各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;
导入单元,用于将所述导出单元组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。
由上述本发明的实施例提供的技术方案可以看出,其通过特定的数据导入、导出方式,从而可以有效地解决现有技术中可能出现的异常问题,进而可以提高数据配置的效率。
附图说明
图1为本发明实施例提供的方法的处理过程示意图;
图2为本发明实施例中的表字典、表字段字典及表字段依赖关系定义表示意图;
图3为本发明实施例中的树形结构表达的XML文件示意图;
图4为本发明实施例中的简化的资费模型示意图;
图5为本发明实施例提供的装置的结构示意图。
具体实施方式
本发明实施例中,为实现业务数据合并,则可以按照待合并的各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息,即一组数据组建成一个树形结构的信息;再将组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。
本发明实施例,具体可以将所述待合并的各组数据中组内数据之间的逻辑关系预先设置于字典表和表字段依赖关系定义中,所述的字典表中用于记录业务实体表的定义信息及业务实体表的字段定义信息,表字段依赖关系定义则用于记录各业务实体表字段之间的依赖关系信息。在完成需合并业务实体表的字典表的定义和实体表数据的依赖关系定义的基础上,如图1所示,本发明实施例提供的相应业务数据合并处理过程具体可以包括:
步骤1,获取需要合并的多组数据;
步骤2,将所述多组数据按照所述的业务实体表的字典表的定义和实体表数据的依赖关系定义中记录的各组数据中的数据之间的逻辑关系,生成各组数据对应的树形结构的信息,如XML文件等;
步骤3,将所述的树形结构的信息依次导入到合并的目标数据库中;
步骤4,在合并过程中,判断当前导入的数据与之前已经导入的数据之间是否存在异常,如判断是否出现键值冲突等问题,若是,则执行步骤5,否则,继续执行步骤3;
步骤5,确定当前导入的数据与之前已经导入的数据之间出现异常,则对该异常进行处理,并在处理完成后,执行步骤3,直至导入过程完成;
例如,若确定出现键值冲突时,则可以为当前导入的数据分配新的唯一键值,并调整所有引用该当前导入的数据的键值。
其中,以多个业务实体表(如电信业务表等)作为待合并数据为例,则将多组数据分别组建成对应的树形结构的信息的过程中具体可以采用的实现方案包括:将一个或多个业务实体表(即一组数据,例如,一组数据可以为一个用户需要合并的所有电信业务数据,或者,也可以为其他划分方式确定的一组信息),按照各个业务实体表中的数据之间的逻辑关系生成各自对应的扩展标记语言XML文件,以通过相应的XML文件表示各个业务实体表中的信息之间的树形关系。
本发明实施例中,相应的各组数据之间的异常信息可以为各业务实体表的数据之间的键值冲突,例如,若当前业务实体表的数据与之前已经导入的数据之间出现键值冲突时,则为当前业务实体表的数据分配新的唯一键值,并调整所有引用该当前业务实体表的数据的键值。
为便于对本发明实施例的进一步理解,下面将结合具体的应用实施例对本发明实施例做详细说明。
具体以对电信业务表进行合并为例,参照图2所示,可以将需要合并的电信业务表的定义(如表的定义、表包含的字段的定义等)通过工具或配置界面维护到表字典表和表字段字典表中;对于在合并过程中,电信业务表字段之间有依赖关系的数据,还需要通过配置界面,维护到相应的表字段依赖关系定义中。其中,表字典表中用于记录电信业务表的定义信息,表字段字典表中用于记录电信业务表的字段定义信息,表字段依赖关系定义中则记录各电信业务表字段之间的依赖关系信息。
为实现电信业务表中的业务数据的合并操作,首先需要将待合并的业务数据导出,相应的业务数据导出过程具体可以包括:按照表字典表、表字段字典表及表字段依赖关系的定义,将电信业务表中的数据按照树形结构表达其数据之间的内在逻辑关系,即在多个电信业务表中,如果某个电信业务表中的字段与其他电信业务表中的数据有内在逻辑关系(如引用等逻辑关系),则将相关联的数据展开以树形结构表述,依此类推。具体可以将各电信业务表分别通过XML格式的文档文件以树形结构表达进行描述并存储,例如,可以将电信业务表导出获得如图3所示的XML文档文件。
在完成上述针对电信业务表的导出操作后,则需要将导出的信息进行导入操作,以实现数据的合并处理。相应的导入过程包括:读入导出过程中生成的树形结构信息,如以树形结构表达的XML格式的文件,进行业务数据的合并,参照图3所示,合并过程的基本顺序可以包括:
首先,处理树形结构的最下层节点的数据,对图3中的TABLE3数据执行导入操作;
然后,处理上一层的数据,对图3中的TABLE2数据执行导入操作;
依此类推,
最后,处理最上层数据,对图3中的TABLE1的数据执行导入操作。
在执行上述导入操作过程中,还需要检测当前导入的数据与之前已经导入的数据之间是否存在异常(如是否有冲突),当发现当前导入的数据与已经导入的数据出现键值冲突等异常问题时,则根据该电信业务表的键值分配规则为其分配新的唯一的键值,并自动调整所有引用该电信业务表中的该键值的其他电信业务表中的数据,以保证与该电信业务表键值有内在逻辑关系(如引用关系等)的其他电信业务表数据的正确性。
可以看出,经过上述电信业务数据合并的处理,即使出现电信业务表的数据键值冲突也可以自动进行调整,使得原有业务数据逻辑的正确性不受影响,保证了电信业务数据合并的“高保真复原”。也就是说,通过上述导入处理,可以分别对上述XML格式的文件进行业务数据的合并,并可以实现电信业务数据合并的准确性。
下面将以一个简化的资费配置数据的合并过程为例对本发明实施例的实际应用加以说明。
假设有表1所示的电信资费信息需要由Person A(人员A)、Person B(人员B)来完成资费的配置及验证;
表1
业务类型 | 资费描述 | 配置验证责任人 |
话音业务 | 市话资费:0.20元/分钟国内长途:前3分钟5毛钱/分钟,3分钟以后,3毛钱/分钟 | Person A |
SMS业务 | 0.10元/条 | Person A |
GPRS业务 | (前200k 3分钱1kb,200k以后,2分钱1kb) | Person B |
MMS业务 | 0.5元/条 | Person B |
其中,Person A、Person B是在各自相对独立的应用环境下,通过开发商提供的资费配置界面完成上述表1所示的资费信息的配置,并生成了如图4所示的资费实体表的数据,该资费实体表仅简化示意了相应的资费模型,实际应用的资费模型会较图4所示资费模型复杂很多。
下面将Person A和Person B需要配置验证的资费规则表及费率表分别描述如下所示:
(1)Person A需要进行配置的信息如表2、表3和表4所示,其中,表2为资费规则表,表3为费率表,表4为分档计费规则表:
表2
规则ID(唯一键值) | 业务类型 | 规则条件 | 规则类型 | 计费规则ID | Applytime | Expiretime |
101 | Voice | 呼叫类型=市话 | 1(简单计费) | 1001 | 2000-1-1 | 2037-1-1 |
102 | Voice | 呼叫类型=国内长途 | 2(计费矩阵计费) | 1002 | 2000-1-1 | 2037-1-1 |
103 | SMS | 1 | 1 | 1006 | 2000-1-1 | 2037-1-1 |
在表2中,规则类型为1时,计费规则ID(标识)关联费率表的记录;规则类型为2时,计费规则ID关联分档计费规则表的规则。
表3
费率ID(唯一键值) | 费率名称 | CURRENCY | 货币单位 | 业务单位数量 | 业务单位类型 |
1001 | 话音市话资费 | 0.2 | 元 | 60 | 秒 |
1006 | SMS资费 | 0.1 | 元 | 1 | 条 |
表4
规则ID(唯一键值) | 规则名称 | 分档起始点0 | 单价 | 业务单位数量0 | 分档起始点1 | 单价 | 业务单位数量1 | 货币单位 | 业务单位类型 |
1002 | 话音长话资费 | 0 | 50 | 60 | 180 | 30 | 60 | 分 | 秒 |
在表4中,该记录表示前3分钟5毛钱一分钟,3分钟以后3毛钱一分钟。
(2)Person B需要进行配置的信息如表5、表6和表7所示,其中,表5为资费规则表,表6为费率表,表7为分档计费规则表:
表5
规则ID(唯一键值) | 业务类型 | 规则条件 | 规则类型 | 计费规则ID | Applytime | Expiretime |
201 | GPRS | 1 | 2 | 1010 | 2000-1-1 | 2037-1-1 |
202 | MMS | 1 | 1 | 1006 | 2000-1-1 | 2037-1-1 |
表6
费率ID(唯一键值) | 费率名称 | CURRENCY | 货币单位 | 业务单位数量 | 业务单位类型 |
1006 | MMS资费 | 0.5 | 元 | 1 | 条 |
表7
规则ID(唯一键值) | 规则名称 | 分档起始点0 | 单价 | 业务单位数量0 | 分档起始点1 | 单价 | 业务单位数量1 | 货币单位 | 业务单位类型 |
1010 | GPRS资费 | 0 | 3 | 1 | 200 | 2 | 1 | 分 | KB |
在表7中,该记录表示GPRS业务前200k为3分钱1k;200k以后则为2分钱1k。
为实现表2至表7中的资费规则和费率的合并,首先将上述需要合并的资费规则表和费率表的定义通过工具或配置界面维护到图2所示的表字典表、表字段字典表中;同时,还需要通过配置界面将资费规则表和费率表字段之间的依赖关系维护到表字段依赖关系定义中,具体如表8所示:
表8
数据库表名 | 字段名 | 相关对象名称 | 相关对象属性 | 约束条件 |
资费规则表 | 计费规则ID | 费率表 | 费率ID | Rule_type=1 |
资费规则表 | 计费规则ID | 分档计费规则表 | 分档计费规则表ID | Rule_type=2 |
在表8中,如果约束条件为1或者为NULL(空),则表示无条件关联,即不需要任何约束条件判断的关联操作,该应用较为普遍。
在完成上述处理,即当Person A、Person B在各自的应用环境下,完成了配置资费的正确性验证,并已经分别将相关的实体表的定义通过工具或配置界面维护到图2所示的表字典表、表字段字典表中之后,便可以根据相应的字典表及表字段依赖关系的定义,生成树形结构的信息,以表达其数据之间的内在逻辑关系,例如可以生成相应的XML格式的文档文件。
进一步地,以Person A的数据导出过程为例,相应的根据逻辑关系导出关联的全部数据的过程中,需要遍历资费规则表中新增的记录,对每一个字段,查询对表字段依赖关系表,得到其依赖类型,如果查找不到,则表示该字段没有依赖其它表,如资费规则表的rule_id字段。直接根据字段名导出xml节点,如<RULE_ID>103</RULE_ID>。对于得到依赖类型的记录,则根据存在的依赖关系进行导出操作,包括:
存在依赖关系时,需要根据判断是否满足依赖条件,例如,表2中的rule_id(规则ID)为101和103的记录,便满足表8所示的依赖关系表中的第1种依赖关系,即计费规则id关联费率表的费率id,此时,该字段导出时则嵌套导出该费率id对应的整条记录,导出后结构如表9所示:
表9
<TARIFFRULE OperateType=″I″><RULE_ID>101</RULE_ID><SERVIETYPE>VOICE</SERVIETYPE><RULETYPE>1</RULETYPE><SIMPLE_RATE><!--SIMPLE_RATE表示简单计费--><RATE_ID>1001</RATE_ID><RATENAME>VOICE_charGE</RATENAME><CURRENCY>20</CURRENCY><UNIT>60</UNIT><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>秒</UNITTYPE></SIMPLE_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE> |
再例如,表2中的rule_id为102的记录,其rule_type字段为2,根据依赖关系表的配置,得出“计费规则id,关联分段计费表的规则id,此时导出此字段时需要导出分档计费表的记录,具体如表10所示:
表10
<TARIFFRULE OperateType=″I″><RULE_ID>102</RULE_ID><SERVIETYPE>VOICE</SERVIETYPE><RULETYPE>2</RULETYPE><SEG_RATE><!--SEG_RATE表示分段计费--><RATE_ID>1002</RATE_ID><RATENAME>VOICE_LONG_charGE</RATENAME><SEG0>0</SEG0><!-分档起始点0--><CURRENCY0>50</CURRENCY0><!-第一个分档内5毛钱分钟--><UNIT0>60</UNIT0><seg1>180</SEG1><!-分段起始点1--><CURRENCY1>30</CURRENCY1><UNIT0>60</UNIT0><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>秒</UNITTYPE></SEG_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME> |
<TARIFFRULE> |
针对Person A和Person B需要配置验证的数据进行上述处理后,便可以得到Person A和Person B导出的XML示例文件,分别如表11和表12所示:
表11
<?xml version=″1.0″encoding=″UTF-8″?><TARIFFRULE OperateType=″I″><RULE_ID>102</RULE_ID><SERVIETYPE>VOICE</SERVIETYPE><RULETYPE>2</RULETYPE><SEG_RATE><!--SEG_RATE表示分段计费--><RATE_ID>1002</RATE_ID><RATENAME>VOICE_LONG_charGE</RATENAME><SEG0>0</SEG0><CURRENCY0>50</CURRENCY0><UNIT0>60</UNIT0><seg1>180</SEG1><CURRENCY1>30</CURRENCY1><UNIT0>60</UNIT0><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>秒</UNITTYPE></SEG_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE> |
<TARIFFRULE OperateType=″I″><RULE_ID>101</RULE_ID><SERVIETYPE>VOICE</SERVIETYPE><RULETYPE>1</RULETYPE><SIMPLE_RATE><!--SIMPLE_RATE表示简单计费--><RATE_ID>1001</RATE_ID><RATENAME>VOICE_charGE</RATENAME><CURRENCY>20</CURRENCY><UNIT>60</UNIT><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>秒</UNITTYPE></SIMPLE_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE><TARIFFRULE OperateType=″I″><RULE_ID>103</RULE_ID><SERVIETYPE>SMS</SERVIETYPE><RULETYPE>1</RULETYPE><SIMPLE_RATE><RATE_ID>1006</RATE_ID><RATENAME>SMS_charGE</RATENAME><CURRENCY>10</CURRENCY><UNIT>1</UNIT><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>条</UNITTYPE></SIMPLE_RATE><APPLYTIME>2000-01-21 |
00:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE> |
表12
<?xml version=″1.0″encoding=″UTF-8″?><TARIFFRULE OperateType=″I″><RULE_ID>201</RULE_ID><SERVIETYPE>GPRS</SERVIETYPE><RULETYPE>2</RULETYPE><SEG_RATE><RATE_ID>1010</RATE_ID><RATENAME>GPRS_SEG_charGE</RATENAME><SEG0>0</SEG0><CURRENCY0>3</CURRENCY0><UNIT0>1</UNIT0><seg1>200</SEG1><CURRENCY1>2</CURRENCY1><UNIT0>1</UNIT0><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>KB</UNITTYPE></SEG_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE><TARIFFRULE OperateType=″I″> |
<RULE_ID>202</RULE_ID><SERVIETYPE>MMS</SERVIETYPE><RULETYPE>1</RULETYPE><SIMPLE_RATE><RATE_ID>1006</RATE_ID><RATENAME>MMS_charGE</RATENAME><CURRENCY>50</CURRENCY><UNIT>1</UNIT><CURRENCYTYPE>分<CURRENCYTYPE><UNITTYPE>条</UNITTYPE></SIMPLE_RATE><APPLYTIME>2000-01-2100:00:00</APPLYTIME><EXPRTIME>2008-01-2100:00:00</EXPRTIME><TARIFFRULE> |
在完成上述导出操作后,在电信资费数据的合并环境中,便可以分别将上述XML文件加载到数据合并的数据库环境中。
(1)将Person A对应的导出文件合并到数据库环境中
参照表11所示,读入rule_id为102的TARIFFRULE(表规则)节点,根据“依赖关系表中”的配置,对于依赖关系表中没有配置依赖关系的字段(即普通字段),可以直接读出该节点的名和值,例如,SERVIETYPE(业务类型)字段,其值为VOICE(语音)。
读出该节点的rule_type(此节点中rule_type为2),并根据rule_type的值,确定计费规则id应该关联到分档计费表,得到依赖关系后,递归调用此导入方法,对节点“SEG_RATE(分档计费)”进行解析,因为此时分档计费表中并无规则id等于1002的记录,故需要直接将记录插入到分档计费表中,以获得规则id为1002的分档计费表。
完成上述处理后,得到的数据记录如表13和14所示:
表13
规则ID(唯一键值) | 业务类型 | 规则条件 | 规则类型 | 计费规则ID | Applytime | Expiretime |
102 | Voice | 呼叫类型=国内长途 | 2(计费矩阵计费) | 1002 | 2000-1-1 | 2037-1-1 |
表14
规则ID(唯一键值) | 规则名称 | 分档起始点0 | 单价 | 业务单位数量0 | 分档起始点1 | 单价 | 业务单位数量1 | 货币单位 | 业务单位类型 |
1002 | 话音长话资 | 0 | 50 | 60 | 180 | 30 | 60 | 分 | 秒 |
费 |
对于表11中的rule_id为101和103的记录的处理过程与rule_id为102的处理过程类似,区别仅为当rule_type为1时,根据依赖关系表得到计费规则id字段对应费率表的费率id后,不再解析“SEG_RATE”节点,而是递归解析“SIMPLE_RATE(简单费率)”节点,并将节点的数据插入到费率表。
经过上述处理后,便可以在没有失真的情况下还原了person A的数据,具体如表15至17所示,分别为资费规则表、费率表和分档计费规则表:
表15
规则ID(唯一键值) | 业务类型 | 规则条件 | 规则类型 | 计费规则ID | Applytime | Expiretime |
101 | Voice | 呼叫类型=市话 | 1(简单计费) | 1001 | 2000-1-1 | 2037-1-1 |
102 | Voice | 呼叫类型=国内长途 | 2(计费矩阵计费) | 1002 | 2000-1-1 | 2037-1-1 |
103 | SMS | 1 | 1 | 1006 | 2000-1-1 | 2037-1-1 |
表16
费率ID(唯一键值) | 费率名称 | CURRENCY | 货币单位 | 业务单位数量 | 业务单位类型 |
1001 | 话音市话资费 | 0.2 | 元 | 60 | 秒 |
1006 | SMS资费 | 0.1 | 元 | 1 | 条 |
表17
规则ID(唯一键值) | 规则名称 | 分档起始点0 | 单价 | 业务单位数量0 | 分档起始点1 | 单价 | 业务单位数量1 | 货币单位 | 业务单位类型 |
1002 | 话音长话资费 | 0 | 50 | 60 | 180 | 30 | 60 | 分 | 秒 |
完成对Person A的数据的处理后,便可以对Person B的数据进行合并导入处理。对于表12所示的Person B的数据的加载合并处理方式与针对Person A的数据的处理方式类似。同时,在加载合并rule_id为202的TARIFFRULE节点时,由于其中的SIMPLE_RATE节点的RATE_ID(费率ID)1006和Person A配置的键值冲突,故需要重新为其生成RATE_ID,例如,可以根据相应的规则生成值为1011的键值作为TARIFFRULE节点下的SIMPLE_RATE节点的RATE_ID值。
经过上述针对表11和表12的导入处理后,便可以获得PersonA、Person B需要配置验证的资费数据合并后的结果,分别为表18至20,依次为资费规则表、费率表和分档计费规则表;其中,表19中的最后一行中的斜体字即为出现键值冲突且进行了相应调整后的键值。
表18
规则ID(唯一键值) | 业务类型 | 规则条件 | 规则类型 | 计费规则ID | Applytime | Expiretime |
101 | Voice | 呼叫类型=市话 | 1(简单计费) | 1001 | 2000-1-1 | 2037-1-1 |
102 | Voice | 呼叫类型=国内长途 | 2(计费矩阵计费) | 1002 | 2000-1-1 | 2037-1-1 |
103 | SMS | 1 | 1 | 1006 | 2000-1-1 | 2037-1-1 |
201 | GPRS | 1 | 2 | 1010 | 2000-1-1 | 2037-1-1 |
202 | MMS | 1 | 1 | 1011 | 2000-1-1 | 2037-1-1 |
表19
费率ID | 费率 | CURRENC | 货币单位 | 业务单 | 业务单 |
(唯一键值) | 名称 | Y | 位数量 | 位类型 | |
1001 | 话音市话资费 | 0.2 | 元 | 60 | 秒 |
1006 | SMS资费 | 0.1 | 元 | 1 | 条 |
1011 | MMS资费 | 0.5 | 元 | 1 | 条 |
表20
规则ID(唯一键值) | 规则名称 | 分档起始点0 | 单价 | 业务单位数量0 | 分档起始点1 | 单价 | 业务单位数量1 | 货币单位 | 业务单位类型 |
1002 | 话音长话资费 | 0 | 50 | 60 | 180 | 30 | 60 | 分 | 秒 |
1010 | GPRS资费 | 0 | 3 | 1 | 200 | 2 | 1 | 分 | KB |
至此,本发明实施例提供的针对Person A、Person B需要配置验证的资费数据的导出、导入过程实现了资费数据的合并操作,实现了在电信资费数据的合并环境中的高保真数据合并操作。
需要说明的是,上述应用实施例仅是以两个简化的资费配置数据的合并过程,在实际的电信业务数据的合并场景中要复杂很多,但是,其均可以通过上述实现方案,实现准确的数据合并操作。
本发明实施例还提供了一种业务数据合并的装置,其具体实现结构如图5所示,具体可以包括以下单元:
(1)导出单元,用于按照各组待合并数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;
以业务实体表作为待合并的数据为例(一个或多个业务实体表对应一组数据),该导出单元具体可以包括以下单元:
数据获取单元,用于获取作为待合并数据的多个业务实体表;
信息处理单元,用于将所述数据获取单元获取的多个业务实体表按照各个业务实体表中的数据之间的逻辑关系生成各自对应的XML文件,一个或多个业务实体表生成一个XML文件,例如,可以将同一用户对应的多个业务实体表生成一个XML文件。
(2)导入单元,用于将所述导出单元组建获得的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息,如键值冲突等异常信息;
以键值冲突为相应异常信息为例,则该导入单元具体可以包括:
判断单元,用于判断在对所述导出单元组建获得的多个所述的树形结构的信息执行合并处理过程中是否出现键值冲突;
异常处理单元,用于确定当前业务实体表的数据(当前导入的数据)与已经导入的数据之间出现键值冲突时,为当前业务实体表的数据分配新的唯一键值,并调整所有引用该当前业务实体表的数据的键值。
可选地,在该装置中还可以包括逻辑关系存储单元,用于保存预先设置的字典表和表字段依赖关系定义,以记录待合并的各组数据中组内数据间的逻辑关系,并提供给所述导出单元,其中,字典表中用于记录各组数据包含的业务实体表的定义信息及业务实体表的字段定义信息,表字段依赖关系定义中用于记录各业务实体表字段之间的依赖关系信息。
综上所述,若采用本发明实施例提供的实现方案进行数据的导入、导出操作,则可以有效提升开发商在配置电信业务逻辑数据的合并数据环节的效率,同时,还可以保证其电信业务逻辑数据的归档或Release(发布)的“高保真”。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (8)
1.一种业务数据合并的方法,其特征在于,包括:
按照待合并的各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;
将组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。
2.根据权利要求1所述的方法,其特征在于,所述的各组数据中的每组数据包括至少一个业务实体表,且所述方法还包括:
将所述待合并的各组数据中组内数据之间的逻辑关系预先设置于字典表和表字段依赖关系定义中,所述的字典表中用于记录业务实体表的定义信息及业务实体表的字段定义信息,表字段依赖关系定义用于记录各业务实体表字段之间的依赖关系信息。
3.根据权利要求1或2所述的方法,其特征在于,所述的将多组数据分别组建成对应的树形结构的信息的步骤包括:
将作为待合并的每组数据包含的多个业务实体表,按照各个业务实体表中的数据之间的逻辑关系生成各组数据对应的扩展标记语言XML文件。
4.根据权利要求3所述的方法,其特征在于,所述的检查调整各组数据之间的异常信息的步骤包括:
若当前业务实体表的数据与已经导入的业务实体表中的数据之间出现键值冲突时,则为当前业务实体表的数据分配新的唯一键值,并调整所有引用该当前业务实体表的数据的键值。
5.一种业务数据合并的装置,其特征在于,包括:
导出单元,用于按照待合并各组数据中组内数据之间的逻辑关系,将多组数据分别组建成对应的树形结构的信息;
导入单元,用于将所述导出单元组建获得的多组数据对应的多个所述的树形结构的信息进行合并处理,并在合并处理过程中检查调整各组数据之间的异常信息。
6.根据权利要求5所述的装置,其特征在于,该装置还包括:
逻辑关系存储单元,用于保存预先设置的字典表和表字段依赖关系定义,以记录各组数据中组内数据间的逻辑关系,其中,字典表中用于记录各组数据包含的业务实体表的定义信息及业务实体表的字段定义信息,表字段依赖关系定义中用于记录各业务实体表字段之间的依赖关系信息。
7.根据权利要求5或6所述的装置,其特征在于,所述的导出单元包括:
数据获取单元,用于获取待合并的每组数据包含的多个业务实体表;
信息处理单元,用于将所述数据获取单元获取的各组数据对应的多个业务实体表按照各个业务实体表中的数据之间的逻辑关系生成各组数据对应的XML文件。
8.根据权利要求7所述的装置,其特征在于,所述的导入单元包括:
判断单元,用于判断在对所述导出单元组建获得的多个所述的树形结构的信息执行合并处理过程中是否出现键值冲突;
异常处理单元,用于确定当前业务实体表的数据与已经导入的数据之间出现键值冲突时,为当前业务实体表的数据分配新的唯一键值,并调整所有引用该当前业务实体表的数据的键值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008100028001A CN101232538A (zh) | 2007-12-28 | 2008-01-23 | 业务数据合并的方法及装置 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710305711.X | 2007-12-28 | ||
CN200710305711 | 2007-12-28 | ||
CNA2008100028001A CN101232538A (zh) | 2007-12-28 | 2008-01-23 | 业务数据合并的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101232538A true CN101232538A (zh) | 2008-07-30 |
Family
ID=39898705
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2008100028001A Pending CN101232538A (zh) | 2007-12-28 | 2008-01-23 | 业务数据合并的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101232538A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102541866A (zh) * | 2010-12-15 | 2012-07-04 | 金蝶软件(中国)有限公司 | 业务单据合并方法、生成方法及系统 |
CN106469211A (zh) * | 2016-09-05 | 2017-03-01 | 南京简睿捷软件开发有限公司 | 大数据的内存加载方法及装置 |
CN104023039B (zh) * | 2013-02-28 | 2018-02-02 | 国际商业机器公司 | 数据包传输方法和装置 |
CN110347688A (zh) * | 2019-07-10 | 2019-10-18 | 星环信息科技(上海)有限公司 | 多元信息的特征融合方法、装置、设备及存储介质 |
CN111355784A (zh) * | 2020-02-20 | 2020-06-30 | 北京字节跳动网络技术有限公司 | 一种处理请求信息的方法、装置、介质和电子设备 |
CN112241443A (zh) * | 2019-07-16 | 2021-01-19 | 中国移动通信集团浙江有限公司 | 数据质量监测方法、装置、计算设备及计算机存储介质 |
CN115292274A (zh) * | 2022-06-29 | 2022-11-04 | 江苏昆山农村商业银行股份有限公司 | 一种数据仓库主题模型构建方法和系统 |
-
2008
- 2008-01-23 CN CNA2008100028001A patent/CN101232538A/zh active Pending
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102541866A (zh) * | 2010-12-15 | 2012-07-04 | 金蝶软件(中国)有限公司 | 业务单据合并方法、生成方法及系统 |
CN104023039B (zh) * | 2013-02-28 | 2018-02-02 | 国际商业机器公司 | 数据包传输方法和装置 |
CN106469211A (zh) * | 2016-09-05 | 2017-03-01 | 南京简睿捷软件开发有限公司 | 大数据的内存加载方法及装置 |
CN106469211B (zh) * | 2016-09-05 | 2019-10-25 | 南京简睿捷软件开发有限公司 | 大数据的内存加载方法及装置 |
CN110347688A (zh) * | 2019-07-10 | 2019-10-18 | 星环信息科技(上海)有限公司 | 多元信息的特征融合方法、装置、设备及存储介质 |
CN112241443A (zh) * | 2019-07-16 | 2021-01-19 | 中国移动通信集团浙江有限公司 | 数据质量监测方法、装置、计算设备及计算机存储介质 |
CN112241443B (zh) * | 2019-07-16 | 2023-11-21 | 中国移动通信集团浙江有限公司 | 数据质量监测方法、装置、计算设备及计算机存储介质 |
CN111355784A (zh) * | 2020-02-20 | 2020-06-30 | 北京字节跳动网络技术有限公司 | 一种处理请求信息的方法、装置、介质和电子设备 |
CN115292274A (zh) * | 2022-06-29 | 2022-11-04 | 江苏昆山农村商业银行股份有限公司 | 一种数据仓库主题模型构建方法和系统 |
CN115292274B (zh) * | 2022-06-29 | 2023-12-26 | 江苏昆山农村商业银行股份有限公司 | 一种数据仓库主题模型构建方法和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101232538A (zh) | 业务数据合并的方法及装置 | |
CN110321339B (zh) | 一种数据迁移方法、装置、设备和存储介质 | |
CN101231651A (zh) | 计算计算机网络上电子文档的重要性的计算机装置和方法 | |
CN102760096B (zh) | 测试用数据的生成方法、单元测试方法以及单元测试系统 | |
CN111597177A (zh) | 用于提升数据质量的数据治理方法 | |
CN107301179A (zh) | 数据库读写分离的方法和装置 | |
CN109598631B (zh) | 基于社保政策的人力资源外包客户账单生成方法及生成系统 | |
CN112270580B (zh) | 一种发票开具方法、装置、设备及存储介质 | |
CN105721174A (zh) | 一种计费方法、计费系统和计费终端 | |
CN101582138A (zh) | 动态业务处理系统和方法 | |
CN112308727A (zh) | 保险理赔业务处理方法及装置 | |
CN102521713B (zh) | 数据处理装置和数据处理方法 | |
CN102208061A (zh) | 数据核销处理装置和数据核销处理方法 | |
CN112702178B (zh) | 实时出账计费的方法、系统和装置 | |
CN111090803A (zh) | 一种数据处理方法、装置、电子设备和存储介质 | |
CN104378362B (zh) | 用于进行报文接口转换的方法及装置 | |
JP2019144978A (ja) | 情報処理装置、情報処理方法、およびプログラム | |
CN107451875A (zh) | 发票处理方法和装置 | |
CN106649108A (zh) | 测试数据的生成方法及装置 | |
CN115809228A (zh) | 数据比对方法、装置、存储介质及电子设备 | |
CN115618825A (zh) | 财务报表合并方法、装置、计算机可读介质及终端设备 | |
CN111429125B (zh) | 账户管理方法、装置、存储介质及电子设备 | |
CN114997109A (zh) | 单据转换方法、装置、计算机设备和存储介质 | |
CN104700291A (zh) | 快递云报价系统 | |
CN109919811B (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 | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20080730 |