第一账户的封户记录为事件Ei导致的、所述第一账户的X种受限制的状态，其中，i = 1、2……n，x和η均为大于I的整数，通过查询预设的对应关系，确定所述第一业务操作是否禁止所述第一账户执行，所述预设的对应关系至少包括所述第一账户的封户记录与被禁止的业务操作的对应关系，如果是，则禁止对所述第一账户执行所述第一业务操作，如果否，则对所述第一账户执行所述第一业务操作，可见，本实施例所述的方法及装置，通过封户记录与被禁止的业务操作的对应关系，确定是否执行第一业务，因此，只要设定了对应关系，对于不同的业务，均可以通过查询对应关系确定是否执行，而不必为不同的业务设置不同的检查逻辑，所以，能够避免系统中存在多种不同逻辑而导致的维护困难。
【附图说明】
[0044]为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0045]图1为本申请实施例公开了一种业务操作方法的流程图；
[0046]图2为本申请实施例公开的又一种业务操作方法的流程图；
[0047]图3为本申请实施例公开的又一种业务操作方法的流程图；
[0048]图4为本申请实施例公开的业务操作方法一种具体实现流程的示例图；
[0049]图5为本申请实施例公开的方法及装置中的数据结构的示意图；
[0050]图6为本申请实施例公开的一种业务操作装置的结构示意图。
【具体实施方式】
[0051]本申请实施例公开了一种业务操作方法及装置，可以应用在银行系统中。目的在于为不同业务的执行设定一个通用的模式，便于系统的维护。
[0052]下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0053]本申请实施例公开了一种业务操作方法，如图1所示，包括:
[0054]SlOl:在接收到对第一账户执行第一业务操作的指令后，查询所述第一账户的封户记录；
[0055]第一账户的封户记录为事件Ei导致的、所述第一账户的X种受限制的状态，其中，i = 1、2......n，X和η均为大于I的整数；
[0056]在银行系统中，账户是指客户在银行开立的用于办理存款、贷款等业务的标识，通过账号加以区分；账户状态，是指用于控制账户能否进行某项或某几项交易的标记，比如，正常状态，通常是指没有任何限制的一种状态；有权机关全封状态，是指被有权机关强制要求的不收不付的状态；挂失止付状态，是指由于账户凭证或密码挂失时为保证账户资金安全禁止账户对外支付的状态。
[0057]封户(Block)是指对账户一种或多种操作的一种限制机制，假设有η种导致账户出现特殊状态(非正常的限制状态)的事件(Event)，分别为E1A2……En，并且这η种事件是相互独立的。每种事件会对账户带来两种或两种以上的状态，一种正常状态，以及一种或多种非正常状态，正常状态命名为NS (Normal State)，其余的m种非正常状态分别为EnSpEnS2……EnSm(其中En代表第η个事件，m不小于I)。
[0058]账户的每种非正常状态，本质上都是对账户操作的限制，将这种限制定义为一种封户。状态EiSj对应的封户类型可被命名为BE &，可以作为一条记录被保存在“封户类型表”中。
[0059]S102:通过查询预设的对应关系，确定第一业务操作是否禁止所述第一账户执行，如果是，执行S103，如果否，执行S104 ；
[0060]其中，预设的对应关系至少包括第一账户的封户记录与被禁止的业务操作的对应关系，账户在每种非正常状态下都有一个或多个操作被禁止。假设在状态EiS^下，无法进行的操作有OpO2……0t，共t种，则将封户类型和t种被禁止的业务操作码关联起来，记录在“封户类型与业务操作码关系表”中。
[0061]S103:禁止对第一账户执行第一业务操作；
[0062]S104:对第一账户执行第一业务操作。
[0063]与传统的业务操作方法相比，本实施例所述的业务操作方法，对于不同的业务的执行流程是相同的，即不论是哪种业务，通过本实施例的方法均能够确定是否允许当前账户执行，因此，无需在系统中设置不同的检查逻辑，有利于系统的维护。
[0064]除此以外，现有的使用状态位指示业务是否被限制的方式，如果当前系统中出现的事件有η种，那么状态掩码字段的长度则不能小于η。设计者需要结合业务发展的趋势，依照经验，给状态掩码字段设置一个大于η的长度m，为未来可能出现的新事件预留出掩码位。但是，如果m设置的过小，不能满足系统上线后出现的新事件的扩展要求。在这种情况下，不得不修改数据库字段的长度，在修改之前要先将历史数据导出，修改之后再将历史数据导入。对于银行系统海量的数据而言，这一变化意味着极高的代价，并且会带来巨大的风险。
[0065]为避免上述情况的出现，可以把m设置的极大，以保证足够支持因新事件出现而需要增加的状态位。但是，未来新事件是否会出现，是一个不可控因素。假设业务规则较稳定，在相当长的一段时间内，整个系统中的事件维持在η种不变，则状态掩码位字段的后m-n位将长期闲置，没有意义。同样，对于银行系统的海量数据而言，账户数量以十亿为单位，异常庞大，如果每个账户这一个字段闲置一定长度，意味着相当大的存储资源的浪费。
[0066]而本实施例所述的“封户类型表”以及“封户类型与业务操作码关系表”，避免了因使用状态位而导致的存储资源浪费的问题。
[0067]本申请实施例公开的又一种业务操作方法，如图2所示，包括:
[0068]S201:在接收到对第一账户执行第一业务操作的指令后，查询所述第一账户的封户记录，所述第一账户的封户记录为事件Ei导致的、所述第一账户的X种受限制的状态，其中，i = 1、2......n，X和η均为大于I的整数；
[0069]S202:判断第一账户的任一条封户记录的封户类型码与第一业务操作的操作码是否存在对应关系，如果是，执行S203，如果否，执行S204 ；
[0070]S203:确定第一业务操作禁止第一账户执行；
[0071]S204:判断任一条封户记录的封户类型码与预设的通用业务操作码之间是否存在对应关系，如果是，执行S205，如果否，执行S206 ；
[0072]S205:判断第一业务的分类标识与预设的分类标识是否相同，如果是，执行S203，如果否，执行S206 ；
[0073]S206:则确定第一业务操作允许第一账户执行。
[0074]在实际业务中，导致账户状态异常的事件一旦发生，大多数情况下，账户受限制的业务场景会非常多。例如，有权机关冻结导致账户不收不付，意味着该账户不能进行所有金融类交易，在整个系统中，可能导致账户资金流动的业务场景有600多个，如果定义这一封户类型，就需要给封户类型码和每个业务操作码建立关系，在“封户类型与业务操作码关系表”中需写入600多条记录，这使得维护封户类型成为一项非常繁琐的操作。
[0075]为解决上述问题，本实施例中，使用通用类型码以及预设的分类标识为两个参考量，通用类型码代表所有业务操作码的集合，编码可以为99999999，如果新建一个封户类型，关联了 99999999业务操作码，则意味着该封户类型关联了系统中所有的业务操作码。分类标识可以帮助缩小受限制业务操作码的范围，本实施例中，分类标识可以包括“记账方向”和“现转标识”，例如，在“封户类型与业务操作码关系表”中的一条记录，封户类型BEiSj关联的业务操作码为99999999，“记账方向”字段的取值为“借记”，“现转标识”字段的取值为“现金”，代表禁止所有可能导致资金流出的现金类操作。
[0076]本实施例中所述的方法，使用第一账户的封户记录与被禁止的业务操作的对应关系、通用类型码以及分类标识作为三种颗粒度不同的限制条件，能够准确定位出受限制的业务，并且，在受限制的业务的数量巨大的情况下，能够减小添加封户类型与被禁止的业务操作的对应关系的工作量。
[0077]本申请实施例公开的又一种业务操作方法，如图3所示，包括以下具体步骤:
[0078]S301:在接收到对第一账户执行第一业务操作的指令后，查询所述第一账户的封户记录，所述第一账户的封户记录为事件Ei导致的、所述第一账户的X种受限制的状态，其中，i