我做过类似有权限管理的系统，表分3个：
第一个表是 权限表（tb_pope)，都有什么权限，以你的系统要求，分3个权限：管理所有学生，管理系学生，本学生。
表列名可以是： ID,popeName,里面有3条记录。
1，管理所有学生
2，管理系学生
3，本学生
第二个表是 用户表(tb_user)： ID,userName,age,等等
第三个表就是 用户权限表(tb_userpope)： ID,userID,PopeID
登录时先检查是否有该用户名，然后读取其权限值，根据权限 *** 作数据库 显示或隐藏 *** 作的部分。
大致就这样了。
授权。数据库中对访问权限的定义称为授权，外部数据库，使用SQL语句设置访问权限，权限管理是eHR系统的全局性管理模块，与各业务模块之前都存在着紧密的关联关系。设计权限管理模块时，既要考虑到能够实现对用户权限的灵活配置，又要兼顾到用户权限应用到各业务模块时，从技术实现上的数据读取效率。
在SQL Server数据库中 主要是通过角色来继承相关的权限 但是 这个权限继承很容易造成权限上的冲突 如现在有个销售员账户SALE 有一个销售部门角色DE_SALES 其中销售部门角色DE_SALES具有查询所有客户信息 即CUSTOM表的权限 但是销售员账户SALE 其由于是为试用期的员工设置的临时帐户 所以其不能够查询CUSTOM表 但是 SALE 帐户其是属于销售部门这个角色 其会继承销售部门这个角色的所有访问权限 此时 SALE 帐户所属角色的权限跟自己帐户的权限就产生了冲突 遇到这种情况 SQL Server数据库该如何处理呢
在SQLServer数据库中 授予组或者角色的权限由该组或者角色的成员所继承 虽然某个用户可能在一个级别上授予或者废除权限 但如果这些权限与更高级的权限发生冲突的话 则可能会打破数据库管理员的权限设计思路 让某个用户意外的禁止或者允许访问某个数据库对象 为了避免因为数据库权限冲突所导致的一系列问题 SQLServer数据库提出了一些解决措施 虽然通过这些措施不能够完全避免权限之间的冲突 但是 至少让数据库管理员看到了解决问题的希望
招数一 明确拒绝
应用场景 现在数据库中有用户Landy 其属于销售员SALES角色 其中 销售员角色具有查询客户信息表Customs的权限 而由于某种原因 数据库管理员限制用户Landy访问数据库对象Customs表的权利 此时就会有对象访问权限上的冲突 此时 数据库管理员该如何才能够避免这种冲突呢
第一个招数就是学会使用拒绝 *** 作 在数据库中 拒绝权限始终优先 在任何级别(无论是用户或者角色)上的拒绝权限都拒绝该对象上的权限 无论该用户现有的权限是否已授予权限还是被废除权限 这听起来比较绕口 或许根据上面的例子来讲 大家更容易明白 如上例 若要解决上面的权限冲突问题 则我们只需要在用户Landy的权限设置中 拒绝其具有数据库对象表Customs表的Select权限 由于显示的拒绝其总被优先执行 所以即使其所属的角色具有表Customs的访问权限 但是其成员Landy由于被显示的拒绝 根据拒绝优先的选择 则其最终不会有数据库表Customs的访问权限
所以笔者所传授给大家的第一个招数就是要学会使用拒绝 *** 作 各位数据库管理员要牢记 在权限管理中 拒绝 *** 作总是被优先执行 另外还有一个极端的例子 可以说明这个问题 如果数据库管理员把Public进行设置 设置为拒绝权限 此时由于拒绝权限被优先执行 则数据会禁止任何用户访问能数据库对象 故拒绝权限一般往往用在用户级别上 可以实现对个别特殊用户的权限控制 而不用给他们设置独立的组 这让数据库权限管理更加的灵活
招数二 废除权限 可以让某些帐户恢复正常
应用情景 现在数据库中有用户Landy 其属于销售员SALES角色 其中 销售员角色具有查询客户信息表Customs的权限 而由于某种原因 数据库管理员限制用户Landy访问数据库对象Customs表的权利 此时 数据库管理员给Landy用户显示的拒绝访问Customs表的权利 但是 现在这个限制其访问客户表的原因已经消除 用户Landy 可以正常访问表Customs了 此时 该如何处理呢
此时 数据库管理员可以通过废除权限 *** 作来完成需求 废除权限只删除所废除级别(如用户 角色或者组)上的已授予权限或者已拒绝权限 而在另外级别上所授予或者拒绝的同一权限仍然适用 废除权限类似于拒绝权限 因为二者都是在同一级别上删除已经授予的权限 但是 废除权限是删除已经授予的权限 并不妨碍用户 组或者角色从更高级别继承已授予的权限 为此 如果废除用户查看表的权限 并不一定能够防止用户查看该表 这跟拒绝权限 *** 作就有本质的区别
举例来说 在上面这个例子中 Landy用户刚开始其被显示的拒绝访问表Customs 虽然其所属的角色具有访问表Customs的权限 但是因为拒绝优先 所以用户Landy最终不能过访问这个表 此时 若限制原因消除 则数据库管理员可以采取废除权限 *** 作 把Landy用户上的拒绝权限废除掉 因为废除权限只删除用户Landy上已拒绝访问这个表的权限 而不影响从角色SALES中继承统一权限 为此 用户Landy最终具有访问这个表Customs的权限 这就是废除权限 *** 作的本质
在实际工作中 废除权限 *** 作与拒绝权限 *** 作往往被用来处理一些特殊的帐户 如不少企业中 试用期员工其权限往往会受到限制 出于安全起见 企业不会让一些还在试用期的员工访问所有的数据 为此 就要对他们的权限进行限制 此时 就可以在这些用户帐户级别上显示的拒绝 实现部分访问限制的需求 当他们试用期过后 若试用合格的话 就可以把这些帐户的拒绝权限废除掉 如此的话 他们就可以正常继承他们所属角色或者组的权限 可见 拒绝权限与废除权限结合 可以让数据库全县的管理更加的统一 最终要的是 可以最大程度的避免因为权限冲突而导致的数据管理上的安全漏洞
另外 在实际配置中 需要注意一个问题 虽然废除权限具有废除拒绝权限的能力 但是 他只能够在一个级别上其作用 如上面这个例子中 另外还有一个T_SALES的角色 其权限设置中 显示的拒绝访问表Customs 此时 若用户Landy同时属于SALES角色和T_SALES角色 虽然通过废除权限废除了用户Landy级别上的拒绝访问表Customs的权限 但是 用户Landy所属的T_SALES角色中的拒绝权限仍然具有优先执行的权力 所以 最终这个用户仍然不能够访问表Customs 所以 通过废除对权限的拒绝可以删除已经拒绝的权限 但是 如果用户在其他组或者角色级别有其他拒绝权限的话 在该用户访问某个对象的权限仍然会被拒绝
招数三 授权 *** 作 让用户访问权限一目了然
应用情景 现在数据库中有用户Landy 其属于销售员SALES角色 其中 销售员角色具有查询客户信息表Customs的权限 而由于某种原因 数据库管理员限制用户Landy访问数据库对象Customs表的权利 此时 数据库管理员给Landy用户显示的拒绝访问Customs表的权利 但是 现在这个限制其访问客户表的原因已经消除 用户Landy 可以正常访问表Customs了 此时 该如何处理呢
此时 除了可以通过上面的废除权限 *** 作来处理 还可以通过授权 *** 作来完成 废除权限 *** 作有一个缺陷 就是数据库管理员要判断这个用户到底是否具有某个数据库对象的访问权限时 还需要去查看其所属的角色或者组中的权限设置 这会增加一定的工作量 而授权 *** 作则可以避免这种情况 授予权限删除所授予级别伤的已经拒绝权限或者已经废除权限 而在另一级别上所拒绝权限的同一权限仍然适用 但是 虽然在另一级别上所废除的同一权限仍然适用 但他不阻止用户访问该对象 也就是说 如果Sales角色可以访问表Customs 现在数据库管理员授予了用户Landy访问Customs表的权限 则用户最终具有访问表Customs的权限 但是 如果Sales角色显示的拒绝了表Customs的查询权限 此时即使显示的授予用户Landy表Customs的访问权限 则该用户仍然不能够访问表Customs 因为拒绝权限总是被优先执行 所以说 用户最终得到的是对象上所授予 拒绝或者废除权限的全部权限的并集 其中 拒绝权限具有最优先的权利
lishixinzhi/Article/program/SQLServer/201311/22467
数据库和程序都很重要。数据库方面设计权限这一块设计三张表，（用户表、角色表、权限表），权限表关联用户表和角色表的外键，这个就两个一对多的关系代替了，多对多的关系。在hibernate中配置的时候要配置用户表和角色表的多对多关系。
怎样允许他人查看或执行查询，但不能更改数据或查询设计？
答：在安全工作组里，可以指定他人查看查询返回数据的权限。如果是 *** 作查询，还可以允许他们执行查询，即使限制他们不得查看查询的基表或基础查询。
1、在“设计”视图中打开查询。
2、在查询“设计”视图中单击设计网格与字段列表外的任何地方，以选定查询。
3、单击工具栏上的“属性”按钮 ，以显示查询的属性表。
4、将“执行权限”属性设置为“所有者的”。
设置了此属性后，应出现以下情形:
所有用户都具有查询所有者的查看或执行查询权限。
只有查询所有者才能保存更改过的查询。
只有查询所有者才能更改查询的所有权。
注释 也可以设置所有新查询的默认权限。请在“工具”菜单上单击“选项”，再单击“表/查询”选项卡，然后单击想要使用的“执行权限”选项。
问：怎样定义用户级安全？
答：
1、加入一个安全工作组或新建一个工作组信息文件。
要点 要完全确保数据库的安全，请不要使用安装 Microsoft Access
时创建的工作组信息文件所定义的默认工作组。而应该确保定义所加入的工作组的工作组信息文件是使用唯一的工作组 ID (WID) 创建的，否则应该创建一个新的工作组。
2、激活“登录”对话框。
*** 作方法：启动 Microsoft Access ，打开数据库，
单击“工具”菜单“安全”子菜单中的“用户与组帐号”命令，单击“用户”选项卡，确保在“名称”框中预定义的“管理员”用户帐号呈高亮度显示，单击“更改登录密码”选项卡，单击“新密码”框，然后键入新密码。不要在“旧密码”框中输入任何内容，
在“验证”框中再次键入密码进行确认，然后单击“确定”按钮。退出ACCESS并重新启动ACCESS，就会出现“登录”对话框。
3、创建管理员的用户帐号。
*** 作方法：
1）打开工作组管理器，按下“联接。。。”按钮，选择 使用在第1 步骤中创建的安全工作组信息文件，退出管理器，启动 Microsoft Access。
要点 如果要确保数据库是完全安全的，请不要使用安装 Microsoft Access
时创建的工作组信息文件中定义的默认工作组，并确保定义所用工作组的工作组信息文件是以唯一的工作组 ID (WID) 创建的，否则就应该重新创建一个工作组信息文件。
2）选择“工具”菜单“安全”子菜单中的“用户与组帐号”命令，单击“用户”选项卡上的“新建”按钮， 在“新用户/组”对话框中，键入管理员帐号名称和个人 ID
(PID)，然后单击“确定”按钮新建帐号。
警告 一定要记住正确的帐号名和 PID，包括字母的大小写，并其将其放在安全的地方。如果要重新创建帐号，必须提供其名称和 PID。遗忘或丢失了帐号名和 PID
将无法恢复。
3）在“可用的组”框中，单击“管理员组”，然后单击“添加”按钮。Microsoft Access
将把新的管理员帐号添加到管理员组并在“隶属于”框中显示“管理员组”。
4）单击“确定”按钮新建管理员帐号。
4、退出 Microsoft Access 并以新建的管理员身份登录。
5、删除管理员组中的管理员帐号。
*** 作方法：选择“工具”菜单“安全”子菜单中的“用户与组帐号”命令，在“用户”选项卡上的“名称”框中输入要移去的用户。在“隶属于”框中，选择要“管理员组”的组，然后单击“删除”按钮。
6、打开要设置安全的数据库。
7、单击“工具”菜单“安全”子菜单中的“用户级安全性向导”命令。
8、根据向导对话框中的指示完成各个步骤。 ]
“用户级安全性向导”将创建一个新的数据库，并将原有数据库中所有对象的副本导出到新的数据库中，然后通过取消用户组对新数据库对象的所有权限，为向导第一个对话框中的选定对象类型设置安全，然后加密新数据库。原有数据库没有进行任何更改。表之间的关系和所有的链接表在新的数据库中都将重建。
现在，只有在步骤 1
中加入的工作组管理员组成员可以访问新数据库中设置了安全的对象。“用户”组则不具备对这些对象的权限。要限制用户和/或组对这些对象的访问必须为其设置权限。
另外,你可以定义不同的试图,这样就给不同的人,不同的信息表示了
B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。
需求陈述
不同职责的人员，对于系统 *** 作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统 *** 作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行 *** 作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
关于设计
借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组” *** 作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。
我们先来分析一下数据库结构：
首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：
由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：
另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：
根据上面的分析，我们进行数据库结构设计，如下图：
点击这里查看权限管理系统数据表字段设计
为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。
一 权限映射表 如下图：
首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。
看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：
如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。
使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。
action字段相关联在数据库中的表现如下图：
通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。
或许你会问，为什么不使用actionid字段相关联呢？因为：
权限表中的id字段在经过多次的数据库 *** 作之后可能会发生更改。
权限映射表中仅仅记录着一个管理组可以执行的权限。
一旦权限表中的id更改，那么权限映射表中的记录也就更改了。
一个管理组可以执行的权限势必将出错，这是非常不希望的。
考虑到上面的情况，所以应该使用action字段相关联，因为：
在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。
权限映射表中记录的action字段也就不会变。
一个管理组可以执行的权限就不会出错了。
二 人员映射表 如下图：
我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：
看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：
如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。
使用这种关联方式，是为了查到一个管理组中的人员有谁。和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。
id字段（人员映射表中是masterid字段）关联表现在数据库中的形式如下图：
一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。所以，在人员映射表中关于administrator的记录就会是两条。
这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。
再结合上面谈到的权限表和权限映射表，就实现了需求中的“组” *** 作，如下图：
其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组” *** 作。
我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图：
两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：
如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。
现在，数据库结构已经很清晰了，分配权限的功能以及“组” *** 作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。
为什么使用这种数据库设计方式搭建起来的系统可以重用呢？
三张实体表中记录着系统中的三个决定性元素。“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。
两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行 *** 作，无需改动结构。
权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏，修改分栏还是减少分栏，也只不过是 *** 作记录而已。
综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。
总结：
此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组” *** 作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。
附录：
权限管理系统数据表的字段设计
下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：
action表：
action表中记录着系统中所有的动作，以及动作相关描述。
actioncolumn表：
actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。
actiongroup表：
actiongroup表记录着动作所在的组。
groupmanager表：
groupmanager表记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。
mastergroup表：
mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。
master表：
master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。
系统内置角色为创建数据库角色方法/步骤如下
1/6分步阅读
第一步，连接对象资源管理器，点击打开数据库book，依此找到“安全性---角色”，点击这个菜单项，如下图所示：
2/6
第二步，选中“数据库角色”鼠标右键，新建数据库角色，打开新建窗口，如下图所示：
德国Statista数据平台 - 为您提供行业专业知识及数据
StatistaGmbH广告
3/6
第三步，输入角色名称和所有者，分别为“Control”和“dbo”，注意所有者，如下图所示：
4/6
第四步，点击添加按钮，选择数据库用户或角色；单击浏览按钮，查询用户并确定，添加正确的角色用户，如下图所示：
5/6
第五步，确定完毕后，框框里选择此角色的成员就为选择的成员角色，如下图所示：
6/6
第六步，选择此角色拥有的框架，这里选择“dbo”，然后点击确定，完成 *** 作，如下图所示：
注意事项
了解创建数据库角色的过程
注意角色的方法和用法
SQL 数据库 客户端
编辑于2018-01-16，内容仅供参考并受版权保护
赞踩分享阅读全文
德国Statista数据平台 - 为您提供行业专业知识及数据
我们为您提供值得信赖的商业统计数据，报告和市场预测，让您的研究更加高效专业。立即免费注册账户，体验来自Statista以及全球25，000+知名数据点及合作伙伴的独家内容
StatistaGmbH广告
服务器京东-精品惠聚，天天特价，嗨GO不停!
Dell 定制方案 项目16
￥767 元
戴尔（DELL）服务器方案 项目8
￥19249 元
Dell 定制方案 联想X1 X270 X280 T470S充电器
￥200 元
企业级de产ll品 H3C LS-5024PV5-EI 24个千兆电口4个千兆光口 全千兆管理型
￥1550 元
京东广告
数据服务-RestCloud全新的ETL社区版，免费下载，永久使用
根据数据库相关内容为您推荐数据服务
数据集成ETL，在数据处理层面，ETL不仅提供近100+数据处理组件，更多组件不断迭代推出中，提供多租户的数据集成开发作业，使企业大规模数据集成更加轻松，更安全。
谷云科技（广州）广告
相关经验
sql server数据库文件存储位置怎么找
22万人看过
PyQt5-QLabel 如何为标签文本设置超链接
3618人看过
sql2016-买东西逛淘宝，榜单好物随心入!
淘宝
以上就是关于高分诚心求助！数据库设计如何实现不同用户进行不同 *** 作的权限管理！（数据库SQL2000+编程语言C#）全部的内容，包括:高分诚心求助！数据库设计如何实现不同用户进行不同 *** 作的权限管理！（数据库SQL2000+编程语言C#）、数据库中对访问权限的定义称、三招解决SQL Server数据库权限冲突等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）