权限管理与设计.ppt

《权限管理与设计.ppt》由会员分享，可在线阅读，更多相关《权限管理与设计.ppt（33页珍藏版）》请在三一办公上搜索。

1、6权限管理的设计与实现,6权限管理的设计与实现,本章内容DMBS的权限管理DMBS权限管理的概念模型设计DMBS权限管理的逻辑模型设计1、E-R图转换为表并进行必要的合并2、优化逻辑模型DMBS权限管理的物理模型设计,6.1DMBS的权限管理,本节要点：DBMS权限的分类DBMS的身份管理授权与回收权限,6.1权限分类,权限的分类系统权限administrator,create table,connect针对关系(table/view)的权限 select,update,delete,insert示例：select on s针对属性/属性组的权限 select,update,delete,in

2、sert示例：select(sno,sname)on s没有关于元组的权限，不能基于元组授权,6.1身份标识,数据库系统的身份标识用户user角色role用户和角色的关系连接使用数据库，必须以一个特定的用户身份不能使用role身份直接连接使用数据库一个用户可同时具备多个角色一个角色可以为多个用户拥有角色可以拥有角色角色拥有关系可以传递权限可以授予用户或者角色用户拥有授给本用户的所有权利，以及本用户具有的角色的所有权利每个用户对自己模式下的对象(表,视图)拥有属主权(owner),6.1身份管理,用户管理创建用户：create user username identified by passwo

3、rd;删除用户：drop user username;角色管理创建角色：create role rolename;删除角色：drop role rolename;用户和角色关系的管理赋予用户角色：grant role1 to u1;撤销用户角色：revoke role1 from u1;,6.1授权：grant,授权grant privilege to identity(user/role)示例：u1将s(sno,sname)的查询权授予u2和role1grant select(sno,sname)on s to u2,role1;转授权限：with grant option u1:grant

4、 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权,并有转授权权u4:grant select on s to u5;/成功，u5拥有了select s权,6.1权限回收：revoke,权限回收revoke revoke privilege from identity(user/role);示例,u1：revoke select on s from u2;转授的权力与回收转授权人的权

5、力被回收时，其转授的权力随之被回收示例：u1:grant select on sc to u2 with grant option;u2:grant select on sc to u3;u1:revoke select on sc from u2;/u2权力被回收后，u3不再具有select sc权,6.2权限管理的概念模型设计,DBMS权限管理的概念模型设计你在一个DBMS开发公司工作，负责进行DBMS权限管理子系统的开发工作请根据DBMS的权限管理要求，完成权限管理子系统概念模型的设计,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计参考方案(一)思考：该方案有哪些不足？,IS

6、A,角色,用户,具有,身份,具有,权限,拥有,对象,Iid,password,pid,oname,pname,oid,Iname,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计参考方案(二),6.2权限管理的概念模型设计,参考方案(一)vs参考方案(二)参考方案(一)没有描述谁进行的授权参考方案(二)是一个比较理想的方案关于后续讨论为了方便讨论，以下我们采用方案一采用方案一，即假设我们不考虑权力由谁授予采用方案一，仅仅是为了后续讨论的方便思考：如果不使用继承，E-R会如何？(假设不考虑权力由谁授予),6.2权限管理的概念模型设计,DBMS权限管理概念模型设计参考方案(三)一种不使用

7、继承的方案,角色,用户,具有,具有,权限,拥有,对象,UID,password,pid,oname,pname,oid,Uname,Rid,Rname,拥有,6.2权限管理的概念模型设计,DBMS权限管理概念模型设计参考方案(四)另一种不使用继承的方案,身份,具有,权限,拥有,对象,Iid,password,pid,oname,pname,oid,Iname,type,6.2权限管理的概念模型设计,假设不考虑权力由谁授予，思考：方案一、三、四，各有什么优缺点？哪个方案更合适？你更愿意选择哪个方案？,6.3权限管理的逻辑模型设计,逻辑模型设计步骤图转换为表并进行必要的合并逻辑模型优化,6.3.1

8、 E-R 关系模式,假设DBMS权限系统概念模型设计采用方案(一)练习：请将E-R图，转换逻辑模型思考：继承关系，如何转换更合适？,ISA,角色,用户,具有,身份,具有,权限,拥有,对象,Iid,password,pid,oname,pname,oid,Iname,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

9、,iid)思考：表role(iid)可以省略吗？,6.3.1 E-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能合并吗？,6.3.1 E-R 关系模式,参考方案(三)实体转换的关系，只为parent建表Identity(iid,iname,password,type)Pr

10、ivilege(pid,pname)Object(oid,oname)联系转化的关系II(iid,has-iid)POI(pid,oid,iid)思考：表role(iid)可以省略吗？,6.3.1 E-R 关系模式,思考一：逻辑模型一、二、三，哪一个更合适？如果你是设计人员，你更愿意选择哪个方案？思考二：逻辑模型二，和概念模型三，有什么关系？逻辑模型三，和概念模型四，有什么关系？你能总结一下，当有继承关系时，概念模型到逻辑模型的转化方法吗？,6.3.1表的合并,表合并的原则二元m:1联系转化成的表可以和多端实体转化成的表进行合并其它表之间不能机械合并权限系统E-R图转换成的表的合并本逻辑模型无

11、表可以机械合并,逻辑模型优化,逻辑模型设计步骤1、E-R图转换为表并进行必要的合并本步可以按照机械方法完成2、逻辑模型优化本步无具体可行的机械方法主要依靠设计人员的经验和能力逻辑模型优化本节针对逻辑模型方案一，进行优化,逻辑模型优化,思考：针对如下逻辑模型方案一，可以如何优化？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)

12、吗？如何去掉？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后的逻辑模式Identity(iid,iname,isrole)User(iid,password)Privilege(pid,pname)Object(oid,oname)UR(u-iid,r-iid)RR(iid,has-iid)POI(pid

13、,oid,iid)思考：能进一步合并User和identity吗？User+Identity=Identity(iid,iname,isrole,isuser)User+Identity=Identity(iid,iname,type)要不要进行合并？哪个合并方案更好？,逻辑模型优化,优化思路一：考虑减少表 合并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

14、？,逻辑模型优化,优化思路一：考虑减少表进一步合并UR和RR后的逻辑模式Identity(iid,iname,type)Privilege(pid,pname)Object(oid,oname)II(iid,has-iid)POI(pid,oid,iid)比较：优化到现在的结果，和逻辑模型参考方案三，有什么区别？,逻辑模型优化,优化思路二，效率优化考虑：针对减少表优化之后的逻辑模式Identity(iid,iname,type)Privilege(pid,pname)Object(oid,oname)II(iid,has-iid)POI(pid,oid,iid)思考：哪些操作的效率可能存在问题

15、？如何解决这些问题？,逻辑模型优化,效率优化考虑一：表II(iid,has-iid)存储了给某一身份直接赋予的身份，但一身份实际拥有哪些身份？这个关系并没有直接存储这个问题可以从II(iid,has-iid)中递归计算获取答案这个问题的使用频率应该较高递归计算效率较低为了提高这一问题的解答速度，可以考虑增加表II_all(iid,has-iid),该表存储每一身份实际拥有的全部身份思考：增加该表的利与弊？你愿意增加这个表吗？,逻辑模型优化,效率优化考虑二：表POI(pid,oid,iid)存储了给某一身份直接赋予的权限，但一身份实际拥有哪些权限？这个关系并没有直接存储这个问题可以从II_all

16、(iid,has-iid)和POI中计算这个问题的使用频率应该较高为了提高这一问题的解答速度，可以考虑增加表POI_all(pid,oid,iid),该表存储每一身份实际拥有的全部权限思考：增加该表的利与弊？你愿意增加这个表吗？,逻辑模型优化,逻辑模型优化参考方案一：Identity(iid,iname,type)Privilege(pid,pname)Object(oid,oname)II_granted(iid,has-iid)/实际方案中对II进行了重命名II_all(iid,has-iid)POI(pid,oid,iid)这是一个实际工程中最终的逻辑设计方案优化方案不是唯一的，你当然可

17、以选择其它优化方案练习：请给出该逻辑模型关系模式图、关系实例示意图,6.4物理模型设计,一个物理模型设计参考方案如下：表存储设计：采用数据库默认表存储方式，不进行存储优化设计索引设计：Identity(iid,iname,type)：uniqueindex(iid),ind(type)Privilege(pid,pname)/考虑到该表元组有限，没有设计索引Object(oid,oname)：uniqueindex(oid)II_granted(iid,has-iid):uniqueindex(iid,hasiid),ind(iid),ind(has_iid)II_all(iid,has-iid):uniqueindex(iid,hasiid),ind(iid),ind(has_iid)POI(pid,oid,iid):uniqueindex(pid,oid,iid),ind(iid)这是实际工程中采用的方案方案不是唯一的，你当然可以选择其它物理模型方案,