权限管理与设计

1、6权限管理的设计与实现,权限管理与设计探讨 任何Application都应有权限管理子系统 DBMS的权限管理是权限管理的典范 DBMS权限管理策略适用于大多数App的权限管理 本章首先讲述DBMS的权限管理策略 然后讨论DBMS权限管理策略数据模型设计和实现 本章的目标 掌握DBMS的权限管理策略 本章是一个数据库设计与实现的综合案例，希望通过一个完整子系统数据模型的设计和实现，理解、体会和掌握数据模型的设计和实现方法,2020年7月11日星期六,1,数据库系统概念-高级SQL,6权限管理的设计与实现,本章内容 DMBS的权限管理 DMBS权限管理的概念模型设计 DMBS权限管理的逻辑模型设

2、计 1、E-R图转换为表并进行必要的合并 2、优化逻辑模型 DMBS权限管理的物理模型设计,2020年7月11日星期六,2,数据库系统概念-高级SQL,2020年7月11日星期六,3,数据库系统概念-高级SQL,6.1DMBS的权限管理,本节要点： DBMS权限的分类 DBMS的身份管理 授权与回收权限,2020年7月11日星期六,4,数据库系统概念-高级SQL,6.1权限分类,权限的分类 系统权限 administrator,create table,connect 针对关系(table/view)的权限 select,update,delete,insert 示例：select on s

3、针对属性/属性组的权限 select,update,delete,insert 示例：select(sno,sname) on s 没有关于元组的权限，不能基于元组授权,2020年7月11日星期六,5,数据库系统概念-高级SQL,6.1身份标识,数据库系统的身份标识 用户user 角色role 用户和角色的关系 连接使用数据库，必须以一个特定的用户身份 不能使用role身份直接连接使用数据库 一个用户可同时具备多个角色 一个角色可以为多个用户拥有 角色可以拥有角色 角色拥有关系可以传递 权限可以授予用户或者角色 用户拥有授给本用户的所有权利，以及本用户具有的角色的所有权利 每个用户对自己模式下

4、的对象(表,视图)拥有属主权(owner),2020年7月11日星期六,6,数据库系统概念-高级SQL,6.1身份管理,用户管理 创建用户： create user username identified by password; 删除用户：drop user username; 角色管理 创建角色：create role rolename; 删除角色：drop role rolename; 用户和角色关系的管理 赋予用户角色：grant role1 to u1; 撤销用户角色：revoke role1 from u1;,2020年7月11日星期六,7,数据库系统概念-高级SQL,6.1授权：

5、grant,授权 grant privilege to identity (user/role) 示例：u1将s(sno,sname) 的查询权授予u2和role1 grant select(sno,sname) on s to u2,role1; 转授权限：with grant option u1:grant select on s to u2; /u2拥有了select s权,无转授权权 u2:grant select on s to u3;/不能成功 u1:grant select on s to u4 with grant option; /u4拥有了select s权,并有转授权权

6、u4:grant select on s to u5; /成功，u5拥有了select s权,2020年7月11日星期六,8,数据库系统概念-高级SQL,6.1权限回收：revoke,权限回收revoke revoke privilege from identity(user/role); 示例,u1：revoke select on s from u2; 转授的权力与回收 转授权人的权力被回收时，其转授的权力随之被回收 示例： u1:grant select on sc to u2 with grant option; u2:grant select on sc to u3; u1:revo

7、ke select on sc from u2; /u2权力被回收后，u3不再具有select sc权,2020年7月11日星期六,9,数据库系统概念-E-R,6.2权限管理的概念模型设计,DBMS权限管理的概念模型设计 你在一个DBMS开发公司工作，负责进行DBMS权限管理子系统的开发工作 请根据DBMS的权限管理要求，完成权限管理子系统概念模型的设计,2020年7月11日星期六,10,数据库系统概念-E-R,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计 参考方案(一) 思考：该方案有哪些不足？,ISA,角色,用户,具有,身份,具有,权限,拥有,对象,Iid,password,

8、pid,oname,pname,oid,Iname,2020年7月11日星期六,11,数据库系统概念-E-R,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计 参考方案(二),2020年7月11日星期六,12,数据库系统概念-E-R,6.2权限管理的概念模型设计,参考方案(一)vs参考方案(二) 参考方案(一) 没有描述谁进行的授权 参考方案(二)是一个比较理想的方案 关于后续讨论 为了方便讨论，以下我们采用方案一 采用方案一，即假设我们不考虑权力由谁授予 采用方案一，仅仅是为了后续讨论的方便 思考： 如果不使用继承，E-R会如何？ (假设不考虑权力由谁授予),2020年7月11日星

9、期六,13,数据库系统概念-E-R,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计 参考方案(三) 一种不使用继承的方案,角色,用户,具有,具有,权限,拥有,对象,UID,password,pid,oname,pname,oid,Uname,Rid,Rname,拥有,2020年7月11日星期六,14,数据库系统概念-E-R,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计 参考方案(四) 另一种不使用继承的方案,身份,具有,权限,拥有,对象,Iid,password,pid,oname,pname,oid,Iname,type,2020年7月11日星期六,15,数据库系统

10、概念-E-R,6.2权限管理的概念模型设计,假设不考虑权力由谁授予，思考： 方案一、三、四，各有什么优缺点？ 哪个方案更合适？你更愿意选择哪个方案？,2020年7月11日星期六,16,数据库系统概念-E-R,6.3权限管理的逻辑模型设计,逻辑模型设计步骤 6.3.1E-R图转换为表并进行必要的合并 6.3.2逻辑模型优化,2020年7月11日星期六,17,数据库系统概念-E-R,6.3.1 E-R 关系模式,假设DBMS权限系统概念模型设计采用方案(一) 练习：请将E-R图，转换逻辑模型 思考：继承关系，如何转换更合适？,ISA,角色,用户,具有,身份,具有,权限,拥有,对象,Iid,pass

11、word,pid,oname,pname,oid,Iname,2020年7月11日星期六,18,数据库系统概念-E-R,6.3.1 E-R 关系模式,参考方案(一) 实体转换的关系，父子分别建表 Identity(iid,iname) User(iid,password) Role(iid) Privilege(pid,pname) Object(oid,oname) 联系转化的关系 UR(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid) 思考：表role(iid)可以省略吗？,2020年7月11日星期六,19,数据库系统概念-E-R,6.3.1 E-

12、R 关系模式,参考方案(二) 实体转换的关系，只为child建表 User(iid,iname,password) Role(iid,iname) Privilege(pid,pname) Object(oid,oname) 联系转化的关系 UR(u-iid,r-iid) RR(iid,has-iid) POU(pid,oid,iid) POR(pid,oid,iid) 思考：POU和POR能合并吗？,2020年7月11日星期六,20,数据库系统概念-E-R,6.3.1 E-R 关系模式,参考方案( 三) 实体转换的关系，只为parent建表 Identity(iid,iname,passwo

13、rd,type) Privilege(pid,pname) Object(oid,oname) 联系转化的关系 II(iid,has-iid) POI(pid,oid,iid) 思考：表role(iid)可以省略吗？,2020年7月11日星期六,21,数据库系统概念-E-R,6.3.1 E-R 关系模式,思考一： 逻辑模型一、二、三，哪一个更合适？ 如果你是设计人员，你更愿意选择哪个方案？ 思考二： 逻辑模型二，和概念模型三，有什么关系？ 逻辑模型三，和概念模型四，有什么关系？ 你能总结一下，当有继承关系时，概念模型到逻辑模型的转化方法吗？,2020年7月11日星期六,22,数据库系统概念-E

14、-R,6.3.1表的合并,表合并的原则 二元m:1联系转化成的表可以和多端实体转化成的表进行合并 其它表之间不能机械合并 权限系统E-R图转换成的表的合并 本逻辑模型无表可以机械合并,2020年7月11日星期六,23,数据库系统概念-E-R,6.3.2逻辑模型优化,逻辑模型设计步骤 1、E-R图转换为表并进行必要的合并 本步可以按照机械方法完成 2、逻辑模型优化 本步无具体可行的机械方法 主要依靠设计人员的经验和能力 逻辑模型优化 本节针对逻辑模型方案一，进行优化,2020年7月11日星期六,24,数据库系统概念-E-R,6.3.2逻辑模型优化,思考： 针对如下逻辑模型方案一，可以如何优化？

15、Identity(iid,iname) User(iid,password) Role(iid) Privilege(pid,pname) Object(oid,oname) UR(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid),2020年7月11日星期六,25,数据库系统概念-E-R,6.3.2逻辑模型优化,优化思路一：考虑减少表 能去掉表Role(iid)吗？如何去掉？ Identity(iid,iname) User(iid,password) Role(iid) Privilege(pid,pname) Object(oid,oname) U

16、R(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid) 思考：是去掉好，还是原来好？,2020年7月11日星期六,26,数据库系统概念-E-R,6.3.2逻辑模型优化,优化思路一：考虑减少表 去掉表Role后的逻辑模式 Identity(iid,iname,isrole) User(iid,password) Privilege(pid,pname) Object(oid,oname) UR(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid) 思考：能进一步合并User和identity吗？ User+Identi

17、ty=Identity(iid,iname,isrole,isuser) User+Identity=Identity(iid,iname,type) 要不要进行合并？哪个合并方案更好？,2020年7月11日星期六,27,数据库系统概念-E-R,6.3.2逻辑模型优化,优化思路一：考虑减少表 合并user和identity后的逻辑模式 Identity(iid,iname,type) Privilege(pid,pname) Object(oid,oname) UR(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid) 思考：是否应该进一步合并UR和RR？

18、,2020年7月11日星期六,28,数据库系统概念-E-R,6.3.2逻辑模型优化,优化思路一：考虑减少表 进一步合并UR和RR后的逻辑模式 Identity(iid,iname,type) Privilege(pid,pname) Object(oid,oname) II(iid,has-iid) POI(pid,oid,iid) 比较： 优化到现在的结果，和逻辑模型参考方案三，有什么区别？,2020年7月11日星期六,29,数据库系统概念-E-R,6.3.2逻辑模型优化,优化思路二，效率优化考虑： 针对减少表优化之后的逻辑模式 Identity(iid,iname,type) Privil

19、ege(pid,pname) Object(oid,oname) II(iid,has-iid) POI(pid,oid,iid) 思考： 哪些操作的效率可能存在问题？ 如何解决这些问题？,2020年7月11日星期六,30,数据库系统概念-E-R,6.3.2逻辑模型优化,效率优化考虑一： 表II(iid,has-iid)存储了给某一身份直接赋予的身份，但一身份实际拥有哪些身份？ 这个关系并没有直接存储 这个问题可以从II(iid,has-iid)中递归计算获取答案 这个问题的使用频率应该较高 递归计算效率较低 为了提高这一问题的解答速度，可以考虑增加表II_all(iid,has-iid),该

20、表存储每一身份实际拥有的全部身份 思考：增加该表的利与弊？你愿意增加这个表吗？,2020年7月11日星期六,31,数据库系统概念-E-R,6.3.2逻辑模型优化,效率优化考虑二： 表POI(pid,oid,iid)存储了给某一身份直接赋予的权限，但一身份实际拥有哪些权限？ 这个关系并没有直接存储 这个问题可以从II_all(iid,has-iid)和POI中计算 这个问题的使用频率应该较高 为了提高这一问题的解答速度，可以考虑增加表POI_all(pid,oid,iid),该表存储每一身份实际拥有的全部权限 思考：增加该表的利与弊？你愿意增加这个表吗？,2020年7月11日星期六,32,数据库系统概念-E-R,6.3.2逻