數(shù)據(jù)庫設計實例權限管理與設計解析課件

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)方法17八月20231數(shù)據(jù)庫系統(tǒng)概念----高級SQL6權限管理的設計與實現(xiàn)權限管理與設計探討05八月20236權限管理的設計與實現(xiàn)本章內(nèi)容6.1DMBS的權限管理6.2DMBS權限管理的概念模型設計6.3DMBS權限管理的邏輯模型設計1、E-R圖轉(zhuǎn)換為表并進行必要的合并2、優(yōu)化邏輯模型6.4DMBS權限管理的物理模型設計17八月20232數(shù)據(jù)庫系統(tǒng)概念----高級SQL6權限管理的設計與實現(xiàn)本章內(nèi)容05八月20232數(shù)據(jù)庫系17八月20233數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1DMBS的權限管理本節(jié)要點：DBMS權限的分類DBMS的身份管理授權與回收權限05八月20233數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20234數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1權限分類權限的分類系統(tǒng)權限 administrator,createtable,connect…針對關系(table/view)的權限

select,update,delete,insert…

示例：selectons針對屬性/屬性組的權限

select,update,delete,insert…

示例：select(sno,sname)

ons沒有關于元組的權限，不能基于元組授權SSnoSnameDeptS1甲計S2乙軟S3丙軟S4丁計05八月20234數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20235數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1身份標識數(shù)據(jù)庫系統(tǒng)的身份標識用戶user角色role用戶和角色的關系連接使用數(shù)據(jù)庫，必須以一個特定的用戶身份不能使用role身份直接連接使用數(shù)據(jù)庫一個用戶可同時具備多個角色一個角色可以為多個用戶擁有角色可以擁有角色角色擁有關系可以傳遞權限可以授予用戶或者角色用戶擁有授給本用戶的所有權利，以及本用戶具有的角色的所有權利每個用戶對自己模式下的對象(表,視圖…)擁有屬主權(owner)05八月20235數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20236數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1身份管理用戶管理創(chuàng)建用戶： createuserusernameidentifiedbypassword;刪除用戶：dropuser

username;角色管理創(chuàng)建角色：createrolerolename;刪除角色：droprole

rolename;用戶和角色關系的管理賦予用戶角色：grantrole1tou1;撤銷用戶角色：revokerole1fromu1;05八月20236數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20237數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1授權：grant授權grantprivilegetoidentity(user/role)示例：u1將s(sno,sname)的查詢權授予u2和role1 grantselect(sno,sname)onstou2,role1;轉(zhuǎn)授權限：withgrantoption u1:grantselectonstou2; //u2擁有了selects權,無轉(zhuǎn)授權權

u2:grantselectonstou3;//不能成功

u1:grantselectonstou4withgrantoption; //u4擁有了selects權,并有轉(zhuǎn)授權權

u4:grantselectonstou5; //成功，u5擁有了selects權05八月20237數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20238數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.1權限回收：revoke權限回收revokerevokeprivilegefromidentity(user/role);示例,u1：revokeselectonsfromu2;轉(zhuǎn)授的權力與回收轉(zhuǎn)授權人的權力被回收時，其轉(zhuǎn)授的權力隨之被回收示例： u1:grantselectonsctou2withgrantoption;

u2:grantselectonsctou3;

u1:revokeselectonscfromu2; //u2權力被回收后，u3不再具有selectsc權05八月20238數(shù)據(jù)庫系統(tǒng)概念----高級SQL6.117八月20239數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計DBMS權限管理的概念模型設計你在一個DBMS開發(fā)公司工作，負責進行DBMS權限管理子系統(tǒng)的開發(fā)工作請根據(jù)DBMS的權限管理要求，完成權限管理子系統(tǒng)概念模型的設計05八月20239數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限17八月202310數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計DBMS權限管理概念模型設計參考方案(一)思考：該方案有哪些不足？ISA角色用戶具有身份具有權限擁有對象IidpasswordpidonamepnameoidIname05八月202310數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202311數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計DBMS權限管理概念模型設計參考方案(二)grantergrantedISA角色用戶具有身份具有權限擁有對象GrantoptionIidpasswordpidonamepnameoidIname05八月202311數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202312數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計參考方案(一)vs參考方案(二)參考方案(一)沒有描述誰進行的授權參考方案(二)是一個比較理想的方案關于后續(xù)討論為了方便討論，以下我們采用方案一采用方案一，即假設我們不考慮權力由誰授予采用方案一，僅僅是為了后續(xù)討論的方便思考：如果不使用繼承，E-R會如何？(假設不考慮權力由誰授予)05八月202312數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202313數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計DBMS權限管理概念模型設計參考方案(三)一種不使用繼承的方案角色用戶具有具有權限擁有對象UIDpasswordpidonamepnameoidUnameRidRname擁有05八月202313數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202314數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計DBMS權限管理概念模型設計參考方案(四)另一種不使用繼承的方案身份具有權限擁有對象IidpasswordpidonamepnameoidInametype05八月202314數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202315數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權限管理的概念模型設計假設不考慮權力由誰授予，思考：方案一、三、四，各有什么優(yōu)缺點？哪個方案更合適？你更愿意選擇哪個方案？05八月202315數(shù)據(jù)庫系統(tǒng)概念----E-R6.2權17八月202316數(shù)據(jù)庫系統(tǒng)概念----E-R6.3權限管理的邏輯模型設計邏輯模型設計步驟6.3.1E-R圖轉(zhuǎn)換為表并進行必要的合并6.3.2邏輯模型優(yōu)化轉(zhuǎn)換、設計理解、表達現(xiàn)實世界概念模型：E-R圖邏輯模型：DBSchema05八月202316數(shù)據(jù)庫系統(tǒng)概念----E-R6.3權17八月202317數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1E-R

關系模式假設DBMS權限系統(tǒng)概念模型設計采用方案(一)練習：請將E-R圖，轉(zhuǎn)換邏輯模型思考：繼承關系，如何轉(zhuǎn)換更合適？ISA角色用戶具有身份具有權限擁有對象IidpasswordpidonamepnameoidIname05八月202317數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202318數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1E-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)可以省略嗎？05八月202318數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202319數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1E-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能合并嗎？05八月202319數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202320數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1E-R

關系模式參考方案(三)實體轉(zhuǎn)換的關系，只為parent建表Identity(iid,iname,password,type)Privilege(pid,pname)Object(oid,oname)聯(lián)系轉(zhuǎn)化的關系II(iid,has-iid)POI(pid,oid,iid)05八月202320數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202321數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1E-R

關系模式思考一：邏輯模型一、二、三，哪一個更合適？如果你是設計人員，你更愿意選擇哪個方案？思考二：邏輯模型二，和概念模型三，有什么關系？邏輯模型三，和概念模型四，有什么關系？你能總結一下，當有繼承關系時，概念模型到邏輯模型的轉(zhuǎn)化方法嗎？05八月202321數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202322數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.1表的合并表合并的原則二元m:1聯(lián)系轉(zhuǎn)化成的表可以和多端實體轉(zhuǎn)化成的表進行合并其它表之間不能機械合并權限系統(tǒng)E-R圖轉(zhuǎn)換成的表的合并本邏輯模型無表可以機械合并05八月202322數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202323數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化邏輯模型設計步驟1、E-R圖轉(zhuǎn)換為表并進行必要的合并本步可以按照機械方法完成2、邏輯模型優(yōu)化本步無具體可行的機械方法主要依靠設計人員的經(jīng)驗和能力邏輯模型優(yōu)化本節(jié)針對邏輯模型方案一，進行優(yōu)化轉(zhuǎn)換、設計理解、表達現(xiàn)實世界概念模型：E-R圖邏輯模型：DBSchema05八月202323數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202324數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化思考：針對如下邏輯模型方案一，可以如何優(yōu)化？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)05八月202324數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202325數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化優(yōu)化思路一：考慮減少表能去掉表Role(iid)嗎？如何去掉？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)思考：是去掉好，還是原來好？05八月202325數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202326數(shù)據(jù)庫系統(tǒng)概念----E-R6.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+Identity=Identity(iid,iname,isrole,isuser)User+Identity=Identity(iid,iname,type)要不要進行合并？哪個合并方案更好？05八月202326數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202327數(shù)據(jù)庫系統(tǒng)概念----E-R6.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？05八月202327數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202328數(shù)據(jù)庫系統(tǒng)概念----E-R6.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ū)別？05八月202328數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202329數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化優(yōu)化思路二，效率優(yōu)化考慮：針對減少表優(yōu)化之后的邏輯模式Identity(iid,iname,type)Privilege(pid,pname)Object(oid,oname)II(iid,has-iid)POI(pid,oid,iid)思考：哪些操作的效率可能存在問題？如何解決這些問題？05八月202329數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202330數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化效率優(yōu)化考慮一：表II(iid,has-iid)存儲了給某一身份直接賦予的身份，但一身份實際擁有哪些身份？這個關系并沒有直接存儲這個問題可以從II(iid,has-iid)中遞歸計算獲取答案這個問題的使用頻率應該較高遞歸計算效率較低為了提高這一問題的解答速度，可以考慮增加表II_all(iid,has-iid),該表存儲每一身份實際擁有的全部身份思考：增加該表的利與弊？你愿意增加這個表嗎？05八月202330數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.17八月202331數(shù)據(jù)庫系統(tǒng)概念----E-R6.3.2邏輯模型優(yōu)化效率優(yōu)化考慮二：表POI(pid,oid,iid)存儲了給某一身份直接賦予的權限，但一身份實際擁有哪些權限？這個關系并沒有直接存儲這個問題可以從II_all(iid,has-iid)和POI中計算這個問題的使用頻率應該較高為了提高這一問題的解答速度，可以考慮增加表POI_all(pid,oid,iid),該表存儲每一身份實際擁有的全部權限思考：增加該表的利與弊？你愿意增加這個表嗎