CN102354356B - 数据权限管理装置和方法 - Google Patents

Abstract

本发明提供了一种数据权限管理装置和方法，包括：生成模块，生成为所述数据定义的至少一个管理维度，所述管理维度包括至少一个层级；选择模块，在所述生成模块生成的所述管理维度中，选择需要的管理维度；设定模块，为用户设定对应的管理维度，或为所述用户设定对应于所述管理维度的层级的数据权限；以及存储模块，存储所述用户、所述管理维度与所述数据权限之间的对应关系。通过本发明的技术方案，可以使用户根据实际情况在运行时灵活配置权限管理，通过后台维度扩展和层级扩展实现对复杂的多维度人员组织关系权限的管理。

Description

数据权限管理装置和方法

技术领域

本发明涉及数据管理技术，具体而言，涉及数据权限管理装置和方法。

背景技术

在当前企业所采用的信息系统当中，不论是何种业务应用，如：财务、CRM(客户资源)、HR(人力资源)等，为了实现对其信息数据的保护，权限管理模块都是不可或缺的系统组成部分，而权限本身针对不同的用户操作又划分为功能权限和数据权限两种类型。功能权限泛指“创建”、“导入”、“停用/启用”等与当前存在业务数据无关的操作限制，而数据权限主要包括对“查询”、“修改”、“删除”依赖于具体数据内容的操作限制(如：员工A只能查询本人或者下级部门员工创建的数据)，因此数据权限控制相对来说较为复杂，而目前大部分信息系统对于数据权限的控制均采用单一的线性控制或是树状层级控制，如图1、图2所示，且控制位元素简单，多是布尔或下级权限扩散。如果针对特定公司复杂人员机构的业务场景，而在图3中，每一个员工隶属于3个维度：部门+业务+区域，且每一个维度都有其自身的数据控制权限，往往需要进行权限冗余配置或个性化权限模块开发来达到用户需求。因此不但产品本身通用性、移植性较差，而且占用了大量的开发与实施资源。

因此，需要一种新的数据权限管理技术，可以使用户根据实际情况在运行时灵活配置权限管理，通过后台维度扩展和层级扩展实现对复杂的多维度人员组织关系权限的管理。

发明内容

本发明正是基于上述问题，提出了一种新的数据权限管理技术，可以使用户根据实际情况在运行时灵活配置权限管理，通过后台维度扩展和层级扩展实现对复杂的多维度人员组织关系权限的管理。

有鉴于此，本发明提出了一种数据权限管理装置，包括：生成模块，生成为所述数据定义的至少一个管理维度，所述管理维度包括至少一个层级；选择模块，在所述生成模块生成的所述管理维度中，选择需要的管理维度；设定模块，为用户设定对应的管理维度，或为所述用户设定对应于所述管理维度的层级的数据权限；以及存储模块，存储所述用户、所述管理维度与所述数据权限之间的对应关系。在该技术方案中，首先由用户设定可能需要用到的管理维度，这里可能只是简单的单一维度，也可以是多个维度，根据用户的需要可以随意设定。在每一个维度中，可能存在一个或者多个层级，如设定了“区域”和“部门”这两个维度，而对于“区域”还可能包括“北京市”和“上海市”等第二级维度，而“北京市”又可能包括“海淀区”、“宣武区”和“丰台区”等三个第三级维度，这样，由上述共三个等级的维度，构成了一个维度下的三个层级。而对于设定好的多个维度以及某个维度下的多个层级，也可以进行进一步选择出用户需要使用的维度和层级。然后，通过用户给予每个维度或层级下的权限，便可以对多维度的权限进行管理。

在上述技术方案中，优选地，所述生成模块还用于：生成至少一个角色；所述设定模块还用于：为所述角色设定对应的管理维度，或为所述角色设定对应于所述管理维度的层级的数据权限，或将至少一个所述用户与至少一个所述角色进行对应，其中，一个所述用户对应于至少一个所述角色，或一个所述角色对应于至少一个所述用户；以及所述存储模块还用于：存储所述用户与所述角色之间的对应关系及所述角色、所述管理维度与所述数据权限之间的对应关系。在该技术方案中，通过对每个用户所述的维度和层级进行设定，使用户获取对应的权限，从而达到对每个用户的权限进行管理。也可以通过设定角色，这个角色是指拥有某些维度和层级的权限的一类人，从而再将设定好的角色与用户进行关联后，实现对用户权限的批量设定，简化操作。

在上述技术方案中，优选地，所述设定模块还用于：为所述管理维度设定对应的使用方式，所述使用方式用于对所述管理维度的层级选择进行定义。在该技术方案中，对于用户设定的多个层级，用户可以根据实际情况，选择需要使用的层级。可以通过设定对层级的选择方式，如只能使用一个层级或可以同时使用多个层级，从而方便用户的管理。

在上述技术方案中，优选地，包括：所述数据权限用于定义所述用户在所述管理维度的层级限制下对所述数据的访问过程，所述访问过程包括对所述数据的读取、添加、修改和/或删除。在该技术方案中，设定的权限可以是对于数据的操作权限，当然，对于如利用数据进行一些运算、传输等操作也显然包含于其中。

在上述技术方案中，优选地，所述数据权限包括特殊权限，所述特殊权限不受所述管理维度的所述层级限制。在该技术方案中，还可以对一些特殊的用户设定特殊权限，如超级管理员，具有该权限的用户可以不受上述设定的限制，便于及时进行管理。

根据本发明的又一方面，还提出了一种数据权限管理方法，包括：步骤402，为所述数据定义至少一个管理维度，所述管理维度包括至少一个层级；步骤404，从所述管理维度中选择需要的管理维度；步骤406，为用户设定对应的管理维度，并为所述用户设定对应于所述管理维度的层级的数据权限，以及存储所述用户、所述管理维度与所述数据权限之间的对应关系。在该技术方案中，首先由用户设定可能需要用到的管理维度，这里可能只是简单的单一维度，也可以是多个维度，根据用户的需要可以随意设定。在每一个维度中，可能存在一个或者多个层级，如设定了“区域”和“部门”这两个维度，而对于“区域”还可能包括“北京市”和“上海市”等第二级维度，而“北京市”又可能包括“海淀区”、“宣武区”和“丰台区”等三个第三级维度，这样，由上述共三个等级的维度，构成了一个维度下的三个层级。而对于设定好的多个维度以及某个维度下的多个层级，也可以进行进一步选择出用户需要使用的维度和层级。然后，通过用户给予每个维度或层级下的权限，便可以对多维度的权限进行管理。

在上述技术方案中，优选地，所述步骤406包括：定义至少一个角色，为所述角色设定对应的管理维度，并为所述角色设定对应于所述管理维度的层级的数据权限，以及将至少一个所述用户与至少一个所述角色进行对应，然后存储所述用户与所述角色之间的对应关系及所述角色、所述管理维度与所述数据权限之间的对应关系，其中，一个所述用户对应于至少一个所述角色，或一个所述角色对应于至少一个所述用户。在该技术方案中，通过对每个用户所述的维度和层级进行设定，使用户获取对应的权限，从而达到对每个用户的权限进行管理。也可以通过设定角色，这个角色是指拥有某些维度和层级的权限的一类人，从而再将设定好的角色与用户进行关联后，实现对用户权限的批量设定，简化操作。

在上述技术方案中，优选地，所述步骤404还包括：为所述管理维度设定对应的使用方式，所述使用方式用于对所述管理维度的层级选择进行定义。在该技术方案中，对于用户设定的多个层级，用户可以根据实际情况，选择需要使用的层级。可以通过设定对层级的选择方式，如只能使用一个层级或可以同时使用多个层级，从而方便用户的管理。

在上述技术方案中，优选地，所述数据权限用于定义所述用户在所述管理维度的层级限制下对所述数据的访问过程，所述访问过程包括对所述数据的读取、添加、修改和/或删除。在该技术方案中，设定的权限可以是对于数据的操作权限，当然，对于如利用数据进行一些运算、传输等操作也显然包含于其中。

在上述技术方案中，优选地，所述数据权限包括特殊权限，所述特殊权限不受所述管理维度的所述层级限制。在该技术方案中，还可以对一些特殊的用户设定特殊权限，如超级管理员，具有该权限的用户可以不受上述设定的限制，便于及时进行管理。

通过以上技术方案，可以使用户根据实际情况在运行时灵活配置权限管理，通过后台维度扩展和层级扩展实现对复杂的多维度人员组织关系权限的管理。

附图说明

图1示出了相关技术的权限管理的结构图；

图2示出了相关技术的权限管理的结构图；

图3示出了相关技术的权限管理的结构图；

图4示出了根据本发明的实施例的数据权限管理装置的框图；

图5示出了根据本发明的实施例的数据权限管理方法的流程图；

图6示出了根据本发明的实施例的数据权限管理方法的具体流程图；

图7示出了根据本发明的实施例的维度设定的示意图；

图8示出了根据本发明的实施例的层级设定的示意图；

图9示出了根据本发明的实施例的使用方式设定的示意图；

图10A示出了根据本发明的实施例的选择使用方式的示意图；

图10B示出了根据本发明的实施例的选择使用方式的示意图；

图11示出了根据本发明的实施例的生成角色的示意图；

图12示出了根据本发明的实施例的将用户添加进角色的示意图；

图13示出了根据本发明的实施例的多维度权限数据组织关系的结构图；以及

图14示出了根据本发明的实施例的获取数据权限的流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。

图4示出了根据本发明的实施例的数据权限管理装置的框图。

如图4所示，根据本发明的实施例的数据权限管理装置400，包括：生成模块402，生成为数据定义的至少一个管理维度，管理维度包括至少一个层级；选择模块404，在生成模块生成的管理维度中，选择需要的管理维度；设定模块406，为用户设定对应的管理维度，或为用户设定对应于管理维度的层级的数据权限；以及存储模块408，存储用户、管理维度与数据权限之间的对应关系。在该技术方案中，首先由用户设定可能需要用到的管理维度，这里可能只是简单的单一维度，也可以是多个维度，根据用户的需要可以随意设定。在每一个维度中，可能存在一个或者多个层级，如设定了“区域”和“部门”这两个维度，而对于“区域”还可能包括“北京市”和“上海市”等第二级维度，而“北京市”又可能包括“海淀区”、“宣武区”和“丰台区”等三个第三级维度，这样，由上述共三个等级的维度，构成了一个维度下的三个层级。而对于设定好的多个维度以及某个维度下的多个层级，也可以进行进一步选择出用户需要使用的维度和层级。然后，通过用户给予每个维度或层级下的权限，便可以对多维度的权限进行管理。

在上述技术方案中，生成模块402还用于：生成至少一个角色；设定模块406还用于：为角色设定对应的管理维度，或为角色设定对应于管理维度的层级的数据权限，或将至少一个用户与至少一个角色进行对应，其中，一个用户对应于至少一个角色，或一个角色对应于至少一个用户；以及存储模块408还用于：存储用户与角色之间的对应关系及角色、管理维度与数据权限之间的对应关系。在该技术方案中，通过对每个用户的维度和层级进行设定，使用户获取对应的权限，从而达到对每个用户的权限进行管理。也可以通过设定角色，这个角色是指拥有某些维度和层级的权限的一类人，从而再将设定好的角色与用户进行关联后，实现对用户权限的批量设定，简化操作。

在上述技术方案中，优选地，所述设定模块还用于：为所述管理维度设定对应的使用方式，所述使用方式用于对所述管理维度的层级选择进行定义。在该技术方案中，对于用户设定的多个层级，用户可以根据实际情况，选择需要使用的层级。可以通过设定对层级的选择方式，如只能使用一个层级或可以同时使用多个层级，从而方便用户的管理。

在上述技术方案中，包括：数据权限用于定义用户在管理维度的层级限制下对数据的访问过程，访问过程包括对数据的读取、添加、修改和/或删除。在该技术方案中，设定的权限可以是对于数据的操作权限，当然，对于如利用数据进行一些运算、传输等操作也显然包含于其中。

在上述技术方案中，数据权限包括特殊权限，该特殊权限不受管理维度的层级限制。在该技术方案中，还可以对一些特殊的用户设定特殊权限，如超级管理员，具有该权限的用户可以不受上述设定的限制，便于及时进行管理。

图5示出了根据本发明的实施例的数据权限管理方法的流程图。

如图5所示，根据本发明的实施例的数据权限管理方法，包括：步骤502，为数据定义至少一个管理维度，管理维度包括至少一个层级；步骤504，从管理维度中选择需要的管理维度；步骤506，为用户设定对应的管理维度，并为用户设定对应于管理维度的层级的数据权限，以及存储用户、管理维度与数据权限之间的对应关系。在该技术方案中，首先由用户设定可能需要用到的管理维度，这里可能只是简单的单一维度，也可以是多个维度，根据用户的需要可以随意设定。在每一个维度中，可能存在一个或者多个层级，如设定了“区域”和“部门”这两个维度，而对于“区域”还可能包括“北京市”和“上海市”等第二级维度，而“北京市”又可能包括“海淀区”、“宣武区”和“丰台区”等三个第三级维度，这样，由上述共三个等级的维度，构成了一个维度下的三个层级。而对于设定好的多个维度以及某个维度下的多个层级，也可以进行进一步选择出用户需要使用的维度和层级。然后，通过用户给予每个维度或层级下的权限，便可以对多维度的权限进行管理。

在上述技术方案中，步骤506包括：定义至少一个角色，为角色设定对应的管理维度，并为角色设定对应于管理维度的层级的数据权限，以及将至少一个用户与至少一个角色进行对应，然后存储用户与角色之间的对应关系及角色、管理维度与数据权限之间的对应关系，其中，一个用户对应于至少一个角色，或一个角色对应于至少一个用户。在该技术方案中，通过对每个用户所述的维度和层级进行设定，使用户获取对应的权限，从而达到对每个用户的权限进行管理。也可以通过设定角色，这个角色是指拥有某些维度和层级的权限的一类人，从而再将设定好的角色与用户进行关联后，实现对用户权限的批量设定，简化操作。

在上述技术方案中，步骤504还包括：为管理维度设定对应的使用方式，使用方式用于对管理维度的层级选择进行定义。在该技术方案中，对于用户设定的多个层级，用户可以根据实际情况，选择需要使用的层级。可以通过设定对层级的选择方式，如只能使用一个层级或可以同时使用多个层级，从而方便用户的管理。

在上述技术方案中，数据权限用于定义所述用户在管理维度的层级限制下对数据的访问过程，访问过程包括对数据的读取、添加、修改和/或删除。在该技术方案中，设定的权限可以是对于数据的操作权限，当然，对于如利用数据进行一些运算、传输等操作也显然包含于其中。

在上述技术方案中，数据权限包括特殊权限，特殊权限不受管理维度的层级限制。在该技术方案中，还可以对一些特殊的用户设定特殊权限，如超级管理员，具有该权限的用户可以不受上述设定的限制，便于及时进行管理。

图6示出了根据本发明的实施例的数据权限管理方法的具体流程图。

如图6所示，进行本发明的数据权限管理的方法，具体步骤如下：

步骤602，定义系统管理维度，这里是指用户出于实际情况考虑，可以对可能有的管理维度进行定义，具体如图7所示，在维度设定界面702中，用户定义了业务结构704、区域结构706，还可以定义管理维度3708、管理维度4710等更多维度，对于维度的定义数量上没有限定。同时，对于已经定义了的维度，可以在不进行删除的前提下，通过维度选择界面712进行相应的操作，选定其中用户认为需要的维度。

此外，对于每一个维度，还包括一个或多个层级，具体如图8所示，在层级设定界面802中，包括广东省804、广州806、东莞808和北京810等层级，其中，广东省804和北京810属于同一级，而广州806和东莞808属于同一级，且广州806和东莞808为广东省804的下一级。通过层级设定界面，可以由用户进行层级的设定，上述是对“区域结构”这一维度下的层级进行的定义，而显然的，对于每一个维度均可以进行相应的层级定义。而对于已经定义了的层级，可以在层级编辑界面812进行编辑，即可以继续进一步的选择、修改等。

步骤604，设置维度层级使用方式，每个维度下包括一个或多个层级，可以对这些层级的使用方式进行设置，具体如图9所示，在使用方式设定界面904，可以对操作对象902中的各个层级进行使用方式的设定，如不使用906、单选&不限级别908、多选&不限级别910、单选&只允许末级912和多选&只允许末级914等，设定后的效果，如对于多选&不限级别910，设定好之后，如图10A所示，在使用方式选择界面1004中，对于区域结构1006而言，可以对广东省1008、广州1010、东莞1012和北京1014进行多选，从上述描述已经说明，这里的广东省1008和北京1014为同一级，而广州1010和东莞1012为同一级且均为广东省1008的下一级，由于设定为不限级别的多选，因此可以对上述两个级别下进行任意选择，而如果设定为单选&不限级别，则如图10B所示，在使用方式选择界面10040中，只能对广东省10080、广州10100、东莞10120和北京10140中的某一个层级进行选择，而如果设定为只能选择末级，则只能对广州10100和东莞10120进行选择，而对于还有下一级的广东省10080和北京10140则无法进行选择。

步骤606，设置员工隶属维度层级，这里首先要看用户希望进行何种方式的设定，也就是步骤608。

步骤608，判断是否进行员工独立配置，若进行独立配置则进入步骤610，否则进入步骤612。

步骤610，设置员工对各个维度中系统业务对象数据控制规则，这里具体如图11所示，可以通过维度选择界面1102进行维度的选择，从而对各个维度进行设定，可以通过操作对象1104的界面观察到可进行操作的对象，也可以通过操作方式1106界面进行相应的编辑操作。具体对于每个维度下的每个操作对象而言，可以对每个可能的操作方式的权限进行设定，如设定为本级1108、本级及下级1110或全部1112，其中本级1108即只能查看在各个维度下与其级别相同的对象数据，本级及下级1110可以查看在各个维度下级别与其级别相同或低于其级别的对象数据，全部1112则可以查看所有数据。

步骤612，定义角色，这是另一种设置员工隶属维度层级的方式，这里的角色是具有相同数据权限的一类人。

步骤614，设置角色内的各个维度中系统业务对象数据控制规则，这里为定义好的角色设定其数据权限。角色可以为一个或多个，若员工的种类较多，需要定义多套数据权限，则可以定义多个角色，若全部为权限相同的员工，则仅定义一个角色即可，根据用户的实际情况进行设定。

步骤616，将员工加入到角色，这里可以看到对于角色的定义的意义，其在于，员工可能数量众多，而其中属于一个部门或区域等的一定数目的员工，其数据权限可能为相同，此时，若一个个进行定义显然费时费力，因此通过定义一个角色，并为这个角色设定与上述员工相同的数据权限，然后将这些员工添加到该角色中，即可完成对这些员工的权限设定，如图12所示，对于操作对象1202中的administrator、员工1和员工2是即将被加入到定义好的角色中的员工，而操作结果1204中的员工3则是已经被添加的员工，通过操作区域1206可以将操作对象1202中的员工移入操作结果1204中，完成设定，也可以将操作界面1204中的员工移回到操作对象1202中，从而设定为其他权限。当然，若对于单个或只有几个员工的情况下，进行单独的操作更方便，而当操作对象1202中为数十、上百或更多员工时，进行角色的定义则显得十分必要。

图13示出了根据本发明的实施例的多维度权限数据组织关系的结构图。

如图13所示，在该根据本发明的实施例的多维度权限数据组织关系中，包括：

管理维度定义数据的组织存储：

管理维度的定义存储于tc_privilege1302中，用户每定义一个类型的管理维度，就会在数据库中创建一张与之相对应的层级数据子表，用于存储在此维度下定义的层级关系，其表命名规则为tc_privilege[i]_level_info1306([i]为管理维度定义的顺序)。

tc_privilege1302中的关键字段如表1所示。

表1

tc_privilege[i]_level_info1306表的关键字段如表2所示。

表2

员工关联关系：

tc_role1310表示角色，tc_user1314表示员工，员工需要建立与维度层级、角色时间均为“多对多”关系，因此我们使用表rel_user_privilege1304，rel_role_user1312进行主键关联。关键字段如表3、表4所示。

字段名	描述
		privilege_type	维度类型(业务线/区域线...)
privilege_id	维度节点Id
		user_id	员工Id

表3

字段名	描述
		role_id	角色Id
user_id	员工Id

表4

权限控制位存储：

权限控制位用于存储配置中各个维度内系统业务对象的控制规则。tc_role_scope1408和tc_user_scope1416分别对应角色和员工的维度控制规则数据，关键字段如表5所示。

表5

上述表中的每一条记录标示某一个员工在某一对象下的各个维度的控制权限规则。

权限功能的应用(前台)：

前台业务对象数据如要应用多维度权限控制，需加入对维度节点、员工信息的关联，用于标识该条业务对象数据隶属于哪些权限维度，以及哪些员工拥有该业务对象的相关负责权。由于业务对象数据与权限维度信息、员工信息均属于多对多的关联关系，所以需要用相关表rel_[obj]_privilege与rel_[obj]_user进行数据关联。表命名规则为“rel_”+对象类型名称+关联对象类型，其关键字段如表6、表7所示。

字段名	描述
		privilege_type	维度类型(业务线/区域线...)
privilege_id	维度节点Id
		[obj]_id(account_id)	对象Id(客户Id)

表6

字段名	描述
		[obj]_id(account_id)	对象Id(客户Id)
user_id	员工Id
		is_in_charge	是否为负责员工

表7

考虑到用户体验，默认情况下，业务对象维度层级数据在其创建时将当前操作员工所属维度层级自动填入。

图14示出了根据本发明的实施例的获取数据权限的流程图。

如图14所示，对于已经定义好数据权限的员工，在其进行数据的获取时，步骤如下：

步骤1402，获取当前操作员工信息，可以通过用户ID登录、指纹信息识别等方式；获取员工所述各维度节点信息，获取员工所述角色；通过上述用户信息，从而查询对应的数据权限。

步骤1404，获取当前操作业务对象信息，这里包括获取业务对象的类型、获取业务对象所属各维度节点以及获取业务对象相关员工，由于每个员工或用户的权限不同，对于各种数据是否可以进行操作也不得而知，因此需要了解其需要进行操作的业务对象的信息。

步骤1406，获取当前员工各维度业务对象权限规则，包括各维度业务对象控制位，这里就是根据步骤1402中获取的员工信息，从而查询到该员工对于各类数据的权限规则。

对于当前操作员工信息和员工各维度业务对象权限规则，在不改变系统基础数据的情况下一般不会产生变化，考虑到系统运行效率，可以根据具体的实现平台，缓存到文件或内存当中，以上信息数据结构内容如表8所示：

表8

步骤1408，遍历可用权限维度1408，根据步骤1406查询到的权限规则，通过遍历了解该员工是否具有访问该业务对象的权限。

步骤1410，判断是否遍历完成，若遍历完成，则验证成功，否则进入步骤1412。

步骤1412，获取本维度下的对象控制位，从而与员工的权限进行比较，看其是否具有该对象的权限。

步骤1414，若员工在该维度下针对当前操作对象，任何层级上无操作权限，则验证失败，否则进入步骤1416。

步骤1416，若员工在该维度下针对当前操作对象，包含所有的相应层级的操作权限，则返回步骤1408，否则进入步骤1418，也就是说该用户具备一部分维度的操作权限。

步骤1418，查询是否符合相关/负责员工控制规则，若是则进入步骤1420，否则进入步骤1422。

步骤1420，查询业务对象相关/负责员工是否包含当前操作员工，是对步骤1418之后的进一步判断，若包含，则返回步骤1408，否则验证失败。

步骤1422，若员工具有本级层级的操作权限，进入步骤1424，否则进入步骤1426。

步骤1424，判断业务对象与当前操作员工是否处于该维度同一层级，若不属于，则显然验证失败，若属于，则返回步骤1408。

步骤1426，若员工具有可本级及下级层级的操作权限，则进入步骤1428，否则验证失败。

步骤1428，获取当前员工该维度节点下的所有下级节点。

步骤1430，判断业务对象是否与当前操作员工处于该维度的同一或下一层级，若是则返回步骤1408，否则显然验证失败。

以上结合附图详细说明了本发明的技术方案，考虑到目前大部分信息系统对于数据权限的控制均采用单一的线性控制或是树状层级控制，产品本身通用性、移植性较差，而且占用了大量的开发与实施资源。因此，本发明提供了一种数据权限管理装置和一种数据权限管理方法，可以使用户根据实际情况在运行时灵活配置权限管理，通过后台维度扩展和层级扩展实现对复杂的多维度人员组织关系权限的管理。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种数据权限管理装置，其特征在于，包括：

生成模块，生成为所述数据定义的至少一个管理维度，所述管理维度包括至少一个层级；

选择模块，在所述生成模块生成的所述管理维度中，选择需要的管理维度；

设定模块，为用户设定对应的管理维度，并为所述用户设定对应于所述管理维度的层级的数据权限；以及

存储模块，存储所述用户、所述管理维度与所述数据权限之间的对应关系；

所述生成模块还用于：生成至少一个角色；

所述设定模块还用于：为所述角色设定对应的管理维度，并为所述角色设定对应于所述管理维度的层级的数据权限，或将至少一个所述用户与至少一个所述角色进行对应，其中，一个所述用户对应于至少一个所述角色，或一个所述角色对应于至少一个所述用户；以及

所述存储模块还用于：存储所述用户与所述角色之间的对应关系及所述角色、所述管理维度与所述数据权限之间的对应关系；

其中，所述数据权限管理装置还包括：

用于对于已经定义好数据权限的员工，在其进行数据的获取时，通过用户ID登录、指纹信息识别的方式获取当前操作员工信息的模块；用于获取员工所属各维度节点信息的模块；用于获取员工所属角色的模块；用于通过上述员工信息，从而查询对应的数据权限的模块；

用于获取当前操作业务对象信息的模块，这里包括获取业务对象的类型、获取业务对象所属各维度节点以及获取业务对象相关员工；

用于利用所述当前操作员工信息获取当前员工各维度业务对象权限规则的模块，包括各维度业务对象控制位；

用于遍历可用权限维度，根据查询到的权限规则，通过遍历了解该员工是否具有访问该业务对象的权限的模块，若遍历完成，则验证成功；

用于当遍历未完成时，获取本维度下的对象控制位，从而与员工的权限进行比较，看其是否具有该对象的权限的模块，其中，若员工在该维度下针对当前操作对象，任何层级上无操作权限，则验证失败；

用于当员工在该维度下针对当前操作对象，包含所有的相应层级的操作权限时，继续遍历可用权限维度的模块；

用于当员工具备一部分维度的操作权限时，查询是否符合相关/负责员工控制规则的模块；

用于当查询到符合相关/负责员工控制规则时，查询业务对象相关/负责员工是否包含当前操作员工的模块，其中，若包含，则继续遍历可用权限维度，若不包含，则验证失败；

用于当查询到不符合相关/负责员工控制规则时，若员工具有本级层级的操作权限，则判断业务对象与当前操作员工是否处于该维度同一层级的模块，其中，若不属于，则显然验证失败，若属于，则继续遍历可用权限维度；

用于当查询到不符合相关/负责员工控制规则时，若员工不具有本级层级的操作权限，则判断员工是否具有本级及下级层级的操作权限的模块，若没有，则验证失败；

用于当员工具有本级及下级层级的操作权限时，获取当前员工该维度节点下的所有下级节点，并判断业务对象是否与当前操作员工处于该维度的同一或下一层级的模块，若是则继续遍历可用权限维度，否则验证失败。

2.根据权利要求1所述的数据权限管理装置，其特征在于，所述设定模块还用于：为所述管理维度设定对应的使用方式，所述使用方式用于对所述管理维度的层级选择进行定义。

3.根据权利要求1或2所述的数据权限管理装置，其特征在于，包括：

所述数据权限用于定义所述用户在所述管理维度的层级限制下对所述数据的访问过程，所述访问过程包括对所述数据的读取、添加、修改和/或删除。

4.根据权利要求3所述的数据权限管理装置，其特征在于，包括：

所述数据权限包括特殊权限，所述特殊权限不受所述管理维度的所述层级限制。

5.一种数据权限管理方法，其特征在于，包括：

步骤402，为所述数据定义至少一个管理维度，所述管理维度包括至少一个层级；

步骤404，从所述管理维度中选择需要的管理维度；

步骤406，为用户设定对应的管理维度，并为所述用户设定对应于所述管理维度的层级的数据权限，以及存储所述用户、所述管理维度与所述数据权限之间的对应关系；所述步骤406还包括：定义至少一个角色，为所述角色设定对应的管理维度，并为所述角色设定对应于所述管理维度的层级的数据权限，以及将至少一个所述用户与至少一个所述角色进行对应，然后存储所述用户与所述角色之间的对应关系及所述角色、所述管理维度与所述数据权限之间的对应关系，其中，一个所述用户对应于至少一个所述角色，或一个所述角色对应于至少一个所述用户；

其中，对于已经定义好数据权限的员工，在其进行数据的获取时，步骤如下：

A、获取当前操作员工信息，可以通过用户ID登录、指纹信息识别的方式；获取员工所述各维度节点信息，获取员工所述角色；通过上述员工信息，从而查询对应的数据权限；

B、获取当前操作业务对象信息，这里包括获取业务对象的类型、获取业务对象所属各维度节点以及获取业务对象相关员工；

C、获取当前员工各维度业务对象权限规则，包括各维度业务对象控制位，这里就是根据步骤A中获取的员工信息，从而查询到该员工对于各类数据的权限规则；

D、遍历可用权限维度，根据步骤C查询到的权限规则，通过遍历了解该员工是否具有访问该业务对象的权限；

E、判断是否遍历完成，若遍历完成，则验证成功，否则进入步骤F；

F、获取本维度下的对象控制位，从而与员工的权限进行比较，看其是否具有该对象的权限；

G、若员工在该维度下针对当前操作对象，任何层级上无操作权限，则验证失败，否则进入步骤H；

H、若员工在该维度下针对当前操作对象，包含所有的相应层级的操作权限，则返回步骤D，否则进入步骤I，也就是说该员工具备一部分维度的操作权限；

I、查询是否符合相关/负责员工控制规则，若是则进入步骤J，否则进入步骤K；

J、查询业务对象相关/负责员工是否包含当前操作员工，是对步骤I之后的进一步判断，若包含，则返回步骤D，否则验证失败；

K、若员工具有本级层级的操作权限，进入步骤L，否则进入步骤M；

L、判断业务对象与当前操作员工是否处于该维度同一层级，若不属于，则显然验证失败，若属于，则返回步骤D；

M、若员工具有本级及下级层级的操作权限，则进入步骤N，否则验证失败；

N、获取当前员工该维度节点下的所有下级节点；

O、判断业务对象是否与当前操作员工处于该维度的同一或下一层级，若是则返回步骤D，否则验证失败。

6.根据权利要求5所述的数据权限管理方法，其特征在于，所述步骤404还包括：

为所述管理维度设定对应的使用方式，所述使用方式用于对所述管理维度的层级选择进行定义。

7.根据权利要求5或6所述的数据权限管理方法，其特征在于，包括：

所述数据权限用于定义所述用户在所述管理维度的层级限制下对所述数据的访问过程，所述访问过程包括对所述数据的读取、添加、修改和/或删除。

8.根据权利要求7所述的数据权限管理方法，其特征在于，包括：

所述数据权限包括特殊权限，所述特殊权限不受所述管理维度的所述层级限制。

Images