= 1、2......n，X和η均为大于I的整数；
[0079]S302:获取与每一条封户记录的封户类型码相关联的保护记录；
[0080]实际业务中，还可能存在某个账户被禁止几乎所有的操作，只有几个特殊的操作可以执行。考虑到整个系统中的1200多个业务操作码，配置这种封户类型同样非常繁琐，几乎不可操作。
[0081]针对这一问题，引入保护(Protect1n)的概念，以简化封户类型的配置。保护的形式与封户类似，但是业务含义完全相反。与封户相关联的业务操作码是禁止被执行的，而与保护相关联的业务操作码是允许被执行的，保护必须以某一个封户为基础。封户相当于一个“黑名单”，黑名单里的所有业务操作被禁止执行，而保护相当于一个“白名单”，是黑名单的例外列表，如果某个黑名单中的业务操作出现在白名单中，则该业务操作允许被执行。利用这一机制，无需在“封户类型与业务操作码关系表”中写入1200多条记录。可以先定义一个封户类型，使其关联通用业务操作码99999999，再定义一个保护类型，关联几个允许被执行的业务操作码，两条记录组合起来即可达到要求，即只允许该账户执行保护类型关联的几个业务操作。
[0082]S303:判断第一业务的操作码是否满足预设条件，如果是，执行S304，如果否，执行 S305 ；
[0083]其中，预设条件包括两种:第一，任一条保护记录的保护类型码与所述第一业务的操作码存在对应关系；第二，每一条保护记录的保护类型码与所述第一业务的操作码均不存在对应关系的情况下，任一条保护记录的保护类型码与预设的通用业务操作码之间存在对应关系，并且所述第一业务的分类标识与预设的分类标识相同。
[0084]S304:确定所述第一业务操作允许所述第一账户执行；
[0085]S305:依据封户记录及其与被禁止的业务操作的对应关系确定所述第一业务操作是否禁止所述第一账户执行。
[0086]S305的具体步骤可以参见上述实施例，这里不再赘述。
[0087]下面对本申请实施例所述的方法进行举例说明:本申请实施例公开的又一种业务操作方法，如图4所示，包括:
[0088]a、通过账号查询有效的封户记录，如果不存在，则说明该账户没有任何限制，可以进行当前的业务操作；
[0089]b、如果存在，则逐条检查封户记录；
[0090]C、根据每条封户记录的封户类型码，查询该封户是否关联了保护；
[0091]d、如果存在保护，则逐条检查当前的业务操作码是否在保护范围之内；
[0092]e、检查该保护类型码与当前的业务操作码是否存在关联关系，如果存在则说明该业务操作码被允许，不再受本条封户记录的限制，可继续检查下一条封户记录；
[0093]f、如果该保护类型与当前的业务操作码的关系不存在，则检查该保护类型是否关联了通配业务操作码，并且其关联关系的记账方向、现转标识是否与当前业务操作码的一致，如果存在这样的通配业务操作码，则说明该业务操作码在保护的范围之内，可继续检查下一条封户记录；
[0094]g、如果不存在保护，则检查当前业务操作码是否在封户范围之内；
[0095]h、检查该封户类型码与当前的业务操作码是否存在关联关系，如果存在则说明该业务操作被禁止执行，可返回校验失败；
[0096]1、如果该封户类型码与当前的业务操作码的关联关系不存在，则检查该封户类型码是否关联了通配业务操作码，并且其关联关系的记账方向、现转标识是否与当前业务操作码的一致，如果存在这样的通配业务操作码，则说明该业务操作码在封户的范围之内，无法执行，返回校验失败；
[0097]j、如果按照以上检查逻辑遍历完所有封户记录，当前业务操作码没有在任何一个封户的范围之内，说明没有被禁止执行，返回校验通过。
[0098]综上所述，本实施例中所述方法设计的数据表模型如图5所示，包括:
[0099]账户信息表，以账号为主键，保存客户在银行开立的账户；
[0100]业务操作码表，以业务操作码为主键，用于保存业务操作码，每个业务操作码代表一个或一类业务场景，其属性“记账方向”和“现转标识”，表明该业务场景中账户的资金进出方向，以及是否为现金操作，对于非金融类的业务场景，这两个属性没有意义。当前系统中存在1200多个业务操作码。
[0101]封户/保护类型表，以封户/保护类型码和封户/保护标识为主键，用于保存封户/保护类型；
[0102]封户/保护类型与业务操作码关系表，用来定义封户/保护类型，每个封户/保护类型即为一个或多个业务操作码的集合；
[0103]封户/保护信息表，用来保存账户上的封户/保护记录。
[0104]除了前述优点之外，本实施例所述方法还具有以下优点:
[0105]1、在业务规则频繁发生变化的情况下，因为业务执行逻辑单一，所以系统修改方式简单，能够将提高系统维护的安全性；
[0106]2、整个系统中的状态检查逻辑集中，代码的可读性比较强；
[0107]3、在一些场景中，多个同种类的会导致账户呈现异常状态的事件可以相互独立的作用于同一个账户。比如，当多个有权机关同时要求对同一个账户进行冻结，并且其中一部分有权机关要求该账户只收不付，而其余的有权机关要求账户不收不付。
[0108]使用现有技术实现上述场景中对账户的限制时，将相应的状态位设置为不收不付即可。但是，当这些有权机关逐个撤销对该账户的冻结时，问题也随之而来。每次有权机关撤销其对该账户的冻结时，程序均需检查是否仍旧存在未撤销的有权机关冻结，以此来决定是否修改状态位。首先检查是否存在不收不付的有权机关冻结，如果存在，状态位不需修改；如果不存在，则需继续检查是否存在只收不付的有权机关冻结，如果存在，需将状态位的取值修改为只收不付；如果不存在，才可以将状态位的取值改为正常状态。
[0109]而因为使用本实施例所述方法，只需更新上述数据表即可，能够简化同种事件情况下的处理过程。
[0110]与上述方法实施例相对应地，本申请实施例还公开了一种业务操作装置，如图6所示，包括:
[0111]查询模块601，用于在接收到对第一账户执行第一业务操作的指令后，查询所述第一账户的封户记录，所述第一账户的封户记录为事件Ei导致的、所述第一账户的X种受限制的状态，其中，i = 1、2......n，X和η均为大于I的整数；
[0112]确定模块602，用于通过查询预设的对应关系，确定所述第一业务操作是否禁止所述第一账户执行，所述预设的对应关系至少包括所述第一账户的封户记录与被禁止的业务操作的对应关系；
[0113]操作模块603，用于如果是，则禁止对所述第一账户执行所述第一业务操作；如果否，则对所述第一账户执行所述第一业务操作。
[0114]可选地，确定模块通过查询预设的对应关系，确定所述第一业务操作是否禁止所述第一账户执行的一种具体实现方式可以为:依据所述封户记录及其与被禁止的业务操作的对应关系确定所述第一业务操作是否禁止所述第一账户执行。
[0115]进一步地，所述依据所述封户记录及其与被禁止的业务操作的对应关系确定所述第一业务操作是否禁止所述第一账户执行的具体过程包括:
[0116]如果所述第一账户的任一条封户记录的封户类型码与所述第一业务操作的操作码存在对应关系，则确定所述第一业务操作禁止所述第一账户执行。
[0117]确定模块还可以用于如果任一条封户记录的封户类型码与所述第一业务操作的操作码均不存在对应关系，则当任一条封户记录的封户类型码与预设的通用业务操作码之间存在对应关系，并且所述第一业务的分类标识与预设的分类标识相同时，则确定所述第一业务操作禁止所述第一账户执行；
[0118]如果任一条封户记录的封户类型码与所述第一业务操作的操作码均不存在对应关系，则当全部封户记录的封户类型码与预设的通用业务操作码之间存在对应关系，并且所述第一业务的分类标识与预设的分类标识不同时，则确定所述第一业务操作允许所述第一账户执行。
[0119]可选地，确定模块通过查询预设的对应关系，确定所述第一业务操作是否禁止所述第一账户执行的另一种具体实现方式可以为:获取与每一条封户记录的封户类型码相关联的保护记录；如果第一业务的操作码满足预设条件，则确定所述第一业务操作允许所述第一账户执行，所述预设条件至少包括任一条保护记录的保护类型码与所述第一业务的操作码存在对应关系；否则，依据所述封户记录及其与被禁止的业务操作的对应关系确定所述第一业务操作是否禁止所述第一账户执行。
[0120]本实施例中，预设条件还包括:
[0121]每一条保护记录的保护类型码与所述第一业务的操作码均不存在对应关系的情