1、6權限管理的設計與實現權限管理的設計與實現l權限管理與設計討論l任何Application都應有權限管理子系統lDBMS的權限管理是權限管理的典范lDBMS權限管理戰略適用于大多數App的權限管理l本章首先講述DBMS的權限管理戰略l然后討論DBMS權限管理戰略數據模型設計和實現l本章的目的l掌握DBMS的權限管理戰略l本章是一個數據庫設計與實現的綜合案例，希望經過一個完好子系統數據模型的設計和實現，了解、領會和掌握數據模型的設計和實現方法6權限管理的設計與實現權限管理的設計與實現l本章內容lDMBS的權限管理lDMBS權限管理的概念模型設計lDMBS權限管理的邏輯模型設計l1、E-R圖轉換為

2、表并進展必要的合并l2、優化邏輯模型lDMBS權限管理的物理模型設計6.1DMBS的權限管理的權限管理l本節要點：lDBMS權限的分類lDBMS的身份管理l授權與回收權限6.1權限分類權限分類l權限的分類l系統權限ladministrator,create table,connectl針對關系(table/view)的權限l select,update,delete,insertl例如：select on sl針對屬性/屬性組的權限l select,update,delete,insertl例如：select(sno,sname) on sl沒有關于元組的權限，不能基于元組授權SSnoSnam

3、eDeptS1甲計S2乙軟S3丙軟S4丁計6.1身份標識身份標識l數據庫系統的身份標識l用戶userl角色rolel用戶和角色的關系l銜接運用數據庫，必需以一個特定的用戶身份l不能運用role身份直接銜接運用數據庫l一個用戶可同時具備多個角色l一個角色可以為多個用戶擁有l角色可以擁有角色l角色擁有關系可以傳送l權限可以授予用戶或者角色l用戶擁有授給本用戶的一切權益，以及本用戶具有的角色的一切權益l每個用戶對本人方式下的對象(表,視圖)擁有屬主權(owner)6.1身份管理身份管理l用戶管理l創建用戶：lcreate user username identified by password;l刪

4、除用戶：drop user username;l角色管理l創建角色：create role rolename;l刪除角色：drop role rolename;l用戶和角色關系的管理l賦予用戶角色：grant role1 to u1;l撤銷用戶角色：revoke role1 from u1;6.1授權：授權：grantl授權lgrant privilege to identity (user/role)l例如：u1將s(sno,sname) 的查詢權授予u2和role1lgrant select(sno,sname) on s to u2,role1;l轉授權權：with grant opti

5、on lu1:grant select on s to u2;l/u2擁有了select s權,無轉授權權lu2:grant select on s to u3;/不能勝利lu1:grant select on s to u4 with grant option;l/u4擁有了select s權,并有轉授權權lu4:grant select on s to u5;l/勝利，u5擁有了select s權6.1權限回收：權限回收：revokel權限回收revoke lrevoke privilege from identity(user/role); l例如,u1：revoke select on

6、 s from u2; l轉授的權益與回收l轉授權人的權益被回收時，其轉授的權益隨之被回收l例如：lu1:grant select on sc to u2 with grant option;lu2:grant select on sc to u3; lu1:revoke select on sc from u2;l /u2權益被回收后，u3不再具有select sc權6.2權限管理的概念模型設計權限管理的概念模型設計lDBMS權限管理的概念模型設計l他在一個DBMS開發公司任務，擔任進展DBMS權限管理子系統的開發任務l請根據DBMS的權限管理要求，完成權限管理子系統概念模型的設計6.2權限

7、管理的概念模型設計權限管理的概念模型設計lDBMS權限管理概念模型設計l參考方案(一)l思索：該方案有哪些缺乏？ISA角色角色用戶用戶具有具有身份身份具有具有權限權限擁有擁有對象對象IidpasswordpidonamepnameoidIname6.2權限管理的概念模型設計權限管理的概念模型設計lDBMS權限管理概念模型設計l參考方案(二)grantergrantedISA角色角色用戶用戶具有具有身份身份具有具有權限權限擁有擁有對象對象GrantoptionIidpasswordpidonamepnameoidIname6.2權限管理的概念模型設計權限管理的概念模型設計l參考方案(一)vs參考

8、方案(二)l參考方案(一) 沒有描畫誰進展的授權l參考方案(二)是一個比較理想的方案l關于后續討論l為了方便討論，以下我們采用方案一l采用方案一，即假設我們不思索權益由誰授予l采用方案一，僅僅是為了后續討論的方便l思索：l假設不運用承繼，E-R會如何？l(假設不思索權益由誰授予)6.2權限管理的概念模型設計權限管理的概念模型設計lDBMS權限管理概念模型設計l參考方案(三)l一種不運用承繼的方案角色角色用戶用戶具有具有具有具有權限權限擁有擁有對象對象UIDpasswordpidonamepnameoidUnameRidRname擁有擁有6.2權限管理的概念模型設計權限管理的概念模型設計lDBM

9、S權限管理概念模型設計l參考方案(四)l另一種不運用承繼的方案身份身份具有具有權限權限擁有擁有對象對象IidpasswordpidonamepnameoidInametype6.2權限管理的概念模型設計權限管理的概念模型設計l假設不思索權益由誰授予，思索：l方案一、三、四，各有什么優缺陷？l哪個方案更適宜？他更情愿選擇哪個方案？6.3權限管理的邏輯模型設計權限管理的邏輯模型設計l邏輯模型設計步驟l6.3.1E-R圖轉換為表并進展必要的合并l6.3.2邏輯模型優化轉換、設計轉換、設計了解、表達了解、表達現實世界現實世界概念模型：概念模型：E-R圖圖邏輯模型：邏輯模型： DBSchema6.3.1

10、 E-R 關系方式關系方式l假設DBMS權限系統概念模型設計采用方案(一)l練習：請將E-R圖，轉換邏輯模型l思索：承繼關系，如何轉換更適宜？ISA角色角色用戶用戶具有具有身份身份具有具有權限權限擁有擁有對象對象IidpasswordpidonamepnameoidIname6.3.1 E-R 關系方式關系方式l參考方案(一)l實體轉換的關系，父子分別建表lIdentity(iid,iname)lUser(iid,password)lRole(iid)lPrivilege(pid,pname)lObject(oid,oname)l聯絡轉化的關系lUR(u-iid,r-iid)lRR(iid,h

11、as-iid)lPOI(pid,oid,iid)l思索：表role(iid)可以省略嗎？6.3.1 E-R 關系方式關系方式l參考方案(二)l實體轉換的關系，只為child建表lUser(iid,iname,password)lRole(iid,iname)lPrivilege(pid,pname)lObject(oid,oname)l聯絡轉化的關系lUR(u-iid,r-iid)lRR(iid,has-iid)lPOU(pid,oid,iid)lPOR(pid,oid,iid)l思索：POU和POR能合并嗎？6.3.1 E-R 關系方式關系方式l參考方案( 三)l實體轉換的關系，只為pare

12、nt建表lIdentity(iid,iname,password,type)lPrivilege(pid,pname)lObject(oid,oname)l聯絡轉化的關系lII(iid,has-iid)lPOI(pid,oid,iid)l思索：表role(iid)可以省略嗎？6.3.1 E-R 關系方式關系方式l思索一：l邏輯模型一、二、三，哪一個更適宜？l假設他是設計人員，他更情愿選擇哪個方案？l思索二：l邏輯模型二，和概念模型三，有什么關系？l邏輯模型三，和概念模型四，有什么關系？l他能總結一下，當有承繼關系時，概念模型到邏輯模型的轉化方法嗎？6.3.1表的合并表的合并l表合并的原那么l二

13、元m:1聯絡轉化成的表可以和多端實體轉化成的表進展合并l其它表之間不能機械合并l權限系統E-R圖轉換成的表的合并l本邏輯模型無表可以機械合并6.3.2邏輯模型優化邏輯模型優化l邏輯模型設計步驟l1、E-R圖轉換為表并進展必要的合并l本步可以按照機械方法完成l2、邏輯模型優化l本步無詳細可行的機械方法l主要依托設計人員的閱歷和才干l邏輯模型優化l本節針對邏輯模型方案一，進展優化轉換、設計轉換、設計了解、表達了解、表達現實世界現實世界概念模型：概念模型：E-R圖圖邏輯模型：邏輯模型： DBSchema6.3.2邏輯模型優化邏輯模型優化l思索：l針對如下邏輯模型方案一，可以如何優化？lIdentit

14、y(iid,iname)lUser(iid,password)lRole(iid)lPrivilege(pid,pname)lObject(oid,oname)lUR(u-iid,r-iid)lRR(iid,has-iid)lPOI(pid,oid,iid)6.3.2邏輯模型優化邏輯模型優化l優化思緒一：思索減少表l能去掉表Role(iid)嗎？如何去掉？lIdentity(iid,iname)lUser(iid,password)lRole(iid)lPrivilege(pid,pname)lObject(oid,oname)lUR(u-iid,r-iid)lRR(iid,has-iid)l

15、POI(pid,oid,iid)l思索：是去掉好，還是原來好？6.3.2邏輯模型優化邏輯模型優化l優化思緒一：思索減少表l去掉表Role后的邏輯方式lIdentity(iid,iname,isrole)lUser(iid,password)lPrivilege(pid,pname)lObject(oid,oname)lUR(u-iid,r-iid)lRR(iid,has-iid)lPOI(pid,oid,iid)l思索：能進一步合并User和identity嗎？l User+Identity=Identity(iid,iname,isrole,isuser)l User+Identity=Id

16、entity(iid,iname,type)l要不要進展合并？哪個合并方案更好？6.3.2邏輯模型優化邏輯模型優化l優化思緒一：思索減少表l 合并user和identity后的邏輯方式lIdentity(iid,iname,type)lPrivilege(pid,pname)lObject(oid,oname)lUR(u-iid,r-iid)lRR(iid,has-iid)lPOI(pid,oid,iid)l思索：能否應該進一步合并UR和RR？6.3.2邏輯模型優化邏輯模型優化l優化思緒一：思索減少表l進一步合并UR和RR后的邏輯方式lIdentity(iid,iname,type)lPriv

17、ilege(pid,pname)lObject(oid,oname)lII(iid,has-iid)lPOI(pid,oid,iid)l比較：l優化到如今的結果，和邏輯模型參考方案三，有什么區別？6.3.2邏輯模型優化邏輯模型優化l優化思緒二，效率優化思索：l針對減少表優化之后的邏輯方式lIdentity(iid,iname,type)lPrivilege(pid,pname)lObject(oid,oname)lII(iid,has-iid)lPOI(pid,oid,iid)l思索：l哪些操作的效率能夠存在問題？l如何處理這些問題？6.3.2邏輯模型優化邏輯模型優化l效率優化思索一：l表II

18、(iid,has-iid)存儲了給某一身份直接賦予的身份，但一身份實踐擁有哪些身份？l這個關系并沒有直接存儲l這個問題可以從II(iid,has-iid)中遞歸計算獲取答案l這個問題的運用頻率應該較高l遞歸計算效率較低l為了提高這一問題的解答速度，可以思索添加表II_all(iid,has-iid),該表存儲每一身份實踐擁有的全部身份l思索：添加該表的利與弊？他情愿添加這個表嗎？6.3.2邏輯模型優化邏輯模型優化l效率優化思索二：l表POI(pid,oid,iid)存儲了給某一身份直接賦予的權限，但一身份實踐擁有哪些權限？l這個關系并沒有直接存儲l這個問題可以從II_all(iid,has-iid)和POI中計算l這個問題的運用頻率應該較高l為了提高這一問題的解答速度，可以思索添加表POI_all(pid,oid,iid),該表存儲每一身份實踐擁有的全部權限l思索：添加該表的利與弊？他情愿添加這個表嗎？6.3.2邏輯模型優化邏輯模型優化l邏輯模型優化參考方案一：lIdentity