6權限管理與設計.ppt

1、6權限管理的設計與實現(xiàn),權限管理與設計探討 任何Application都應有權限管理子系統(tǒng) DBMS的權限管理是權限管理的典范 DBMS權限管理策略適用于大多數(shù)App的權限管理 本章首先講述DBMS的權限管理策略 然后討論DBMS權限管理策略數(shù)據(jù)模型設計和實現(xiàn) 本章的目標 掌握DBMS的權限管理策略 本章是一個數(shù)據(jù)庫設計與實現(xiàn)的綜合案例，希望通過一個完整子系統(tǒng)數(shù)據(jù)模型的設計和實現(xiàn)，理解、體會和掌握數(shù)據(jù)模型的設計和實現(xiàn)方法,2020年7月29日星期三,1,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6權限管理的設計與實現(xiàn),本章內(nèi)容 DMBS的權限管理 DMBS權限管理的概念模型設計 DMBS權限管理的邏輯模型設

2、計 1、E-R圖轉(zhuǎn)換為表并進行必要的合并 2、優(yōu)化邏輯模型 DMBS權限管理的物理模型設計,2020年7月29日星期三,2,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,2020年7月29日星期三,3,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6.1DMBS的權限管理,本節(jié)要點： DBMS權限的分類 DBMS的身份管理 授權與回收權限,2020年7月29日星期三,4,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6.1權限分類,權限的分類 系統(tǒng)權限 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月29日星期三,5,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6.1身份標識,數(shù)據(jù)庫系統(tǒng)的身份標識 用戶user 角色role 用戶和角色的關系 連接使用數(shù)據(jù)庫，必須以一個特定的用戶身份 不能使用role身份直接連接使用數(shù)據(jù)庫 一個用戶可同時具備多個角色 一個角色可以為多個用戶擁有 角色可以擁有角色 角色擁有關系可以傳遞 權限可以授予用戶或者角色 用戶擁有授給本用戶的所有權利，以及本用戶具有的角色的所有權利 每個用戶對自己模式下

4、的對象(表,視圖)擁有屬主權(owner),2020年7月29日星期三,6,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6.1身份管理,用戶管理 創(chuàng)建用戶： create user username identified by password; 刪除用戶：drop user username; 角色管理 創(chuàng)建角色：create role rolename; 刪除角色：drop role rolename; 用戶和角色關系的管理 賦予用戶角色：grant role1 to u1; 撤銷用戶角色：revoke role1 from u1;,2020年7月29日星期三,7,數(shù)據(jù)庫系統(tǒng)概念-高級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; 轉(zhuǎn)授權限：with grant option u1:grant select on s to u2; /u2擁有了select s權,無轉(zhuǎn)授權權 u2:grant select on s to u3;/不能成功 u1:grant select on s to u4 with grant option; /u4擁有了select s權,并有轉(zhuǎn)授權權

6、u4:grant select on s to u5; /成功，u5擁有了select s權,2020年7月29日星期三,8,數(shù)據(jù)庫系統(tǒng)概念-高級SQL,6.1權限回收：revoke,權限回收revoke revoke privilege from identity(user/role); 示例,u1：revoke select on s from u2; 轉(zhuǎn)授的權力與回收 轉(zhuǎn)授權人的權力被回收時，其轉(zhuǎn)授的權力隨之被回收 示例： 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月29日星期三,9,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,DBMS權限管理的概念模型設計 你在一個DBMS開發(fā)公司工作，負責進行DBMS權限管理子系統(tǒng)的開發(fā)工作 請根據(jù)DBMS的權限管理要求，完成權限管理子系統(tǒng)概念模型的設計,2020年7月29日星期三,10,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,DBMS權限管理概念模型設計 參考方案(一) 思考：該方案有哪些不足？,ISA,角色,用戶,具有,身份,具有,權限,擁有,對象,Iid,password,

8、pid,oname,pname,oid,Iname,2020年7月29日星期三,11,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,DBMS權限管理概念模型設計 參考方案(二),2020年7月29日星期三,12,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,參考方案(一)vs參考方案(二) 參考方案(一) 沒有描述誰進行的授權 參考方案(二)是一個比較理想的方案 關于后續(xù)討論 為了方便討論，以下我們采用方案一 采用方案一，即假設我們不考慮權力由誰授予 采用方案一，僅僅是為了后續(xù)討論的方便 思考： 如果不使用繼承，E-R會如何？ (假設不考慮權力由誰授予),2020年7月29日星

9、期三,13,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,DBMS權限管理概念模型設計 參考方案(三) 一種不使用繼承的方案,角色,用戶,具有,具有,權限,擁有,對象,UID,password,pid,oname,pname,oid,Uname,Rid,Rname,擁有,2020年7月29日星期三,14,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.2權限管理的概念模型設計,DBMS權限管理概念模型設計 參考方案(四) 另一種不使用繼承的方案,身份,具有,權限,擁有,對象,Iid,password,pid,oname,pname,oid,Iname,type,2020年7月29日星期三,15,數(shù)據(jù)庫系統(tǒng)

10、概念-E-R,6.2權限管理的概念模型設計,假設不考慮權力由誰授予，思考： 方案一、三、四，各有什么優(yōu)缺點？ 哪個方案更合適？你更愿意選擇哪個方案？,2020年7月29日星期三,16,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3權限管理的邏輯模型設計,邏輯模型設計步驟 6.3.1E-R圖轉(zhuǎn)換為表并進行必要的合并 6.3.2邏輯模型優(yōu)化,2020年7月29日星期三,17,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.1 E-R 關系模式,假設DBMS權限系統(tǒng)概念模型設計采用方案(一) 練習：請將E-R圖，轉(zhuǎn)換邏輯模型 思考：繼承關系，如何轉(zhuǎn)換更合適？,ISA,角色,用戶,具有,身份,具有,權限,擁有,對象,Iid,pass

11、word,pid,oname,pname,oid,Iname,2020年7月29日星期三,18,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.1 E-R 關系模式,參考方案(一) 實體轉(zhuǎn)換的關系，父子分別建表 Identity(iid,iname) User(iid,password) Role(iid) Privilege(pid,pname) Object(oid,oname) 聯(lián)系轉(zhuǎn)化的關系 UR(u-iid,r-iid) RR(iid,has-iid) POI(pid,oid,iid) 思考：表role(iid)可以省略嗎？,2020年7月29日星期三,19,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.1 E-

12、R 關系模式,參考方案(二) 實體轉(zhuǎn)換的關系，只為child建表 User(iid,iname,password) Role(iid,iname) Privilege(pid,pname) Object(oid,oname) 聯(lián)系轉(zhuǎn)化的關系 UR(u-iid,r-iid) RR(iid,has-iid) POU(pid,oid,iid) POR(pid,oid,iid) 思考：POU和POR能合并嗎？,2020年7月29日星期三,20,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.1 E-R 關系模式,參考方案( 三) 實體轉(zhuǎn)換的關系，只為parent建表 Identity(iid,iname,passwo

13、rd,type) Privilege(pid,pname) Object(oid,oname) 聯(lián)系轉(zhuǎn)化的關系 II(iid,has-iid) POI(pid,oid,iid) 思考：表role(iid)可以省略嗎？,2020年7月29日星期三,21,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.1 E-R 關系模式,思考一： 邏輯模型一、二、三，哪一個更合適？ 如果你是設計人員，你更愿意選擇哪個方案？ 思考二： 邏輯模型二，和概念模型三，有什么關系？ 邏輯模型三，和概念模型四，有什么關系？ 你能總結一下，當有繼承關系時，概念模型到邏輯模型的轉(zhuǎn)化方法嗎？,2020年7月29日星期三,22,數(shù)據(jù)庫系統(tǒng)概念-E

14、-R,6.3.1表的合并,表合并的原則 二元m:1聯(lián)系轉(zhuǎn)化成的表可以和多端實體轉(zhuǎn)化成的表進行合并 其它表之間不能機械合并 權限系統(tǒng)E-R圖轉(zhuǎn)換成的表的合并 本邏輯模型無表可以機械合并,2020年7月29日星期三,23,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,邏輯模型設計步驟 1、E-R圖轉(zhuǎn)換為表并進行必要的合并 本步可以按照機械方法完成 2、邏輯模型優(yōu)化 本步無具體可行的機械方法 主要依靠設計人員的經(jīng)驗和能力 邏輯模型優(yōu)化 本節(jié)針對邏輯模型方案一，進行優(yōu)化,2020年7月29日星期三,24,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,思考： 針對如下邏輯模型方案一，可以如何優(yōu)化？

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月29日星期三,25,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,優(yōu)化思路一：考慮減少表 能去掉表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月29日星期三,26,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,優(yōu)化思路一：考慮減少表 去掉表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月29日星期三,27,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,優(yōu)化思路一：考慮減少表 合并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月29日星期三,28,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,優(yōu)化思路一：考慮減少表 進一步合并UR和RR后的邏輯模式 Identity(iid,iname,type) Privilege(pid,pname) Object(oid,oname) II(iid,has-iid) POI(pid,oid,iid) 比較： 優(yōu)化到現(xiàn)在的結果，和邏輯模型參考方案三，有什么區(qū)別？,2020年7月29日星期三,29,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,優(yōu)化思路二，效率優(yōu)化考慮： 針對減少表優(yōu)化之后的邏輯模式 Identity(iid,iname,type) Privil

19、ege(pid,pname) Object(oid,oname) II(iid,has-iid) POI(pid,oid,iid) 思考： 哪些操作的效率可能存在問題？ 如何解決這些問題？,2020年7月29日星期三,30,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,效率優(yōu)化考慮一： 表II(iid,has-iid)存儲了給某一身份直接賦予的身份，但一身份實際擁有哪些身份？ 這個關系并沒有直接存儲 這個問題可以從II(iid,has-iid)中遞歸計算獲取答案 這個問題的使用頻率應該較高 遞歸計算效率較低 為了提高這一問題的解答速度，可以考慮增加表II_all(iid,has-iid),該

20、表存儲每一身份實際擁有的全部身份 思考：增加該表的利與弊？你愿意增加這個表嗎？,2020年7月29日星期三,31,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏輯模型優(yōu)化,效率優(yōu)化考慮二： 表POI(pid,oid,iid)存儲了給某一身份直接賦予的權限，但一身份實際擁有哪些權限？ 這個關系并沒有直接存儲 這個問題可以從II_all(iid,has-iid)和POI中計算 這個問題的使用頻率應該較高 為了提高這一問題的解答速度，可以考慮增加表POI_all(pid,oid,iid),該表存儲每一身份實際擁有的全部權限 思考：增加該表的利與弊？你愿意增加這個表嗎？,2020年7月29日星期三,32,數(shù)據(jù)庫系統(tǒng)概念-E-R,6.3.2邏