《續(xù)數(shù)據(jù)庫邏輯設計.ppt》由會員分享，可在線閱讀，更多相關《續(xù)數(shù)據(jù)庫邏輯設計.ppt（38頁珍藏版）》請在裝配圖網(wǎng)上搜索。

數(shù)據(jù)庫設計(邏輯設計),一、概念設計的回顧,根據(jù)需求分析的結果確定概念模型。,,概念模型是對現(xiàn)實世界的一個真實模型，且能滿足用戶對數(shù)據(jù)的處理要求。概念模型直觀形象、容易和用戶溝通。概念模型易于修改。概念模型與具體數(shù)據(jù)模型無關且容易向數(shù)據(jù)庫模型轉化。,,二、邏輯結構設計的任務,概念結構是各種數(shù)據(jù)模型的共同基礎。為了能夠用某一DBMS實現(xiàn)用戶需求，還必須將概念結構進一步轉化為相應的數(shù)據(jù)模型，這正是數(shù)據(jù)庫邏輯結構設計所要完成的任務。,Sqlserver2000中的表操作界面,三、邏輯結構設計的步驟,將概念結構轉化為一般的關系、網(wǎng)狀、層次模型。將轉化來的關系、網(wǎng)狀、層次模型向特定DBMS支持下的數(shù)據(jù)模型轉換。對數(shù)據(jù)模型進行優(yōu)化。,邏輯設計過程,,四、邏輯結構設計的具體實現(xiàn),1E-R圖向關系模型的轉換2向特定DBMS規(guī)定的模型進行轉換3數(shù)據(jù)模型的優(yōu)化4設計用戶子模式,1E-R圖向關系模型的轉換,轉換內容轉換原則,E-R圖向關系模型的轉換（續(xù)）,轉換內容E-R圖由實體、實體的屬性和實體之間的聯(lián)系三個要素組成。關系模型的邏輯結構是一組關系模式的集合{R(U,D,DOM,F)}。將E-R圖轉換為關系模型：將實體、實體的屬性和實體之間的聯(lián)系轉化為關系模式。,E-R圖向關系模型的轉換（續(xù)）,轉換原則(1).一個實體型轉換為一個關系模式。(2).一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。(3).一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。(4).一個m:n聯(lián)系轉換為一個關系模式。(5).三個或三個以上實體間的一個多元聯(lián)系轉換為一個關系模式。(6).同一實體集的實體間的聯(lián)系，即自聯(lián)系，也可按上述1:1、1:n和m:n三種情況分別處理。,E-R圖向關系模型的轉換（續(xù)）,轉換原則(1).一個實體型轉換為一個關系模式。關系的屬性：實體型的屬性關系的碼：實體型的碼,例，上述實體可以轉換為如下關系模式：,班主任（姓名，職稱，工資）班級（班名、人數(shù)）輔導員（姓名，年齡，性別）課程（課名，學時，學分，先修課）,,E-R圖向關系模型的轉換（續(xù)）,(2).一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。1)轉換為一個獨立的關系模式關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性。關系的候選碼：每個實體的碼均是該關系的候選碼。例如，獨立關系模式：管理（姓名，班名）,E-R圖向關系模型的轉換（續(xù)）,E-R圖向關系模型的轉換（續(xù)）,獨立的關系模式,張?zhí)烀?…,李宏偉,1,1,E-R圖向關系模型的轉換（續(xù)）,2)與某一端對應的關系模式合并合并后關系的屬性：加入對應關系的碼和聯(lián)系本身的屬性合并后關系的碼：不變,張?zhí)烀?李宏偉,…,對應的關系模式合并,E-R圖向關系模型的轉換（續(xù)）,注意：從理論上講，1:1聯(lián)系可以與任意一端對應的關系模式合并。但在一些情況下，與不同的關系模式合并效率會大不一樣。因此究竟應該與哪端的關系模式合并需要依應用的具體情況而定。由于連接操作是最費時的操作，所以一般應以盡量減少連接操作為目標。例如，如果經(jīng)常要查詢某個班級的班主任姓名，則將負責聯(lián)系與班級關系合并更好些。,E-R圖向關系模型的轉換（續(xù)）,(3).一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。1)轉換為一個獨立的關系模式關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性。關系的碼：n端實體的碼。,(3).一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。2)與n端對應的關系模式合并合并后關系的屬性：在n端關系中加入1端關系的碼和聯(lián)系本身的屬性.合并后關系的碼：不變可以減少系統(tǒng)中的關系個數(shù)，一般情況下更傾向于采用這種方法.,E-R圖向關系模型的轉換（續(xù)）,E-R圖向關系模型的轉換（續(xù)）,例，“負責”聯(lián)系為1:n聯(lián)系。將其轉換為關系模式的兩種方法：1)使其成為一個獨立的關系模式：負責（班名，輔導員姓名）,…,張?zhí)烀?2)將其與班級關系模式合并：負責（班名，人數(shù)，輔導員姓名）,張?zhí)烀?張?zhí)烀?張?zhí)烀?…,E-R圖向關系模型的轉換（續(xù)）,(4).一個m:n聯(lián)系轉換為一個關系模式。關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的碼：各實體碼的組合例，“開設”聯(lián)系是一個m:n聯(lián)系，可以將它轉換為如下關系模式，其中班名與課程名為關系的組合碼：開設（班名，課程名，開課時間）,班級與課程m:n聯(lián)系,E-R圖向關系模型的轉換（續(xù)）,(5).三個或三個以上實體間的一個多元聯(lián)系轉換為一個關系模式。關系的屬性：與該多元聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的碼：各實體碼的組合例，“講授”聯(lián)系是一個三元聯(lián)系，可以將它轉換為如下關系模式，其中課程號、職工號和書號為關系的組合碼：講授（課程號，職工號，書號）,E-R圖向關系模型的轉換（續(xù)）,(6).同一實體集的實體間的聯(lián)系，即自聯(lián)系，也可按上述1:1、1:n和m:n三種情況分別處理。例，如果教師實體集內部存在領導與被領導的1:n自聯(lián)系，我們可以將該聯(lián)系與教師實體合并，這時主碼職工號將多次出現(xiàn)，但作用不同，可用不同的屬性名加以區(qū)分：教師：｛職工號，姓名，性別，職稱，系主任｝,自聯(lián)系,五、向特定DBMS規(guī)定的模型進行轉換,一般的數(shù)據(jù)模型還需要向特定DBMS規(guī)定的模型進行轉換。轉換的主要依據(jù)是所選用的DBMS的功能及限制。沒有通用規(guī)則。對于關系模型來說，這種轉換通常都比較簡單。,六、數(shù)據(jù)模型的優(yōu)化,數(shù)據(jù)庫邏輯設計的結果不是唯一的。得到初步數(shù)據(jù)模型后，還應該適當?shù)匦薷摹⒄{整數(shù)據(jù)模型的結構，以進一步提高數(shù)據(jù)庫應用系統(tǒng)的性能，這就是數(shù)據(jù)模型的優(yōu)化。關系數(shù)據(jù)模型的優(yōu)化通常以規(guī)范化理論為指導。,數(shù)據(jù)模型的優(yōu)化（續(xù)）,優(yōu)化數(shù)據(jù)模型的方法⒈確定數(shù)據(jù)依賴按需求分析階段所得到的語義，分別寫出每個關系模式內部各屬性之間的數(shù)據(jù)依賴以及不同關系模式屬性之間數(shù)據(jù)依賴。,數(shù)據(jù)模型的優(yōu)化（續(xù)）,例:教師關系模式內部存在下列數(shù)據(jù)依賴：姓名→職稱職稱→工資,,,2依據(jù)規(guī)范化理論對數(shù)據(jù)進行規(guī)范,規(guī)范化理論的一個重要的目標就是將數(shù)據(jù)分割存儲在特定的地方來消除冗余、簡化數(shù)據(jù)庫的更新，提高數(shù)據(jù)庫完整性，并且減少存儲的要求。用范式來衡量數(shù)據(jù)規(guī)范化的程度。現(xiàn)在已定義出了第1、第2至第5范式，這些范式是嵌套的。也就是滿足第2范式時一定滿足第1范式。,關系：一個關系是一個二維表。一個表要想成為關系必須滿足下列約束。首先，表中的每一格必須是單值的，每一列的所有條目都必須是同一類型的；其次每一列都有唯一的名字，列在表中的順序并不重要；最后，表中任意兩行（元組）不能相同，行在表中的順序也不重要。第一范式（1NF）：任何符合關系定義的關系可看作第1范式。第二范式（2NF）：如果一個關系的所有非關鍵字屬性都依賴于整個關鍵字，那么該關系就屬于第2范式。所謂關鍵字是指唯一能標識一個元組的字段（屬性）或字段的集合，在職工工資檔案表中職工號就可作為關鍵字，但職工有可能同名，因此，姓名不能做為關鍵字。,第三范式：一個關系如果在第2范式，且沒有傳遞依賴，則該關系在第3范式中。隨著關系的一步步規(guī)范化，對其進行插入、刪除、更新的異常操作會逐步消除。,注意：,規(guī)范化的關系避免了更新異常，似乎更可取，但從其它理由來考慮，有時卻不值得。因為當數(shù)據(jù)必須從兩個單獨的表中組合起來時，DBMS就要做額外的關系運算。因此非規(guī)范化的表可能更易于處理，在有些情況下，數(shù)據(jù)冗余的缺點并不是很重要，往往在規(guī)范化的基礎上故意保留少量非規(guī)范化的內容，以改進性能和實現(xiàn)的復雜性。一般說來，實際操作中，第三范式已能滿足商業(yè)化數(shù)據(jù)庫的一致性和完整性約束。,第6節(jié)．系統(tǒng)安全設計,隨著Intranet/Internet的普及及電子商務活動的開展，網(wǎng)絡安全已日益成為人們所關注的話題。在一般的計算機系統(tǒng)中安全措施是逐級設置的。如圖所示,用戶標識和鑒定存取控制OS級安全控制密碼存取,圖11-4網(wǎng)絡安全級別,確定用戶角色及權限,決定系統(tǒng)中的那些用戶對這些信息單位擁有什么樣的權限（無權、查詢、修改、刪除、統(tǒng)計、全權），并據(jù)此列為表格。依次限定用戶集（每個用戶、用戶組可看成是該集的一個子集）對信息集（每個數(shù)據(jù)窗口（Datawindows）,單行編輯窗（SinglelineEdit）,多行編輯窗（MutiLineEdit）等可看成是信息集的子集）的映射（訪問權限）。見下圖,具體步驟為：,列出機構業(yè)務一覽表，在該表中行方向表示企業(yè)目前所設置的機構，列方向表示具體業(yè)務，表中內容0表示該部門無此項業(yè)務aij=1表示此項業(yè)務列入MIS1期開發(fā)計劃2表示此項業(yè)務列入MIS2期開發(fā)計劃,,,,,,列出U-C矩陣（user信息使用者，creator信息創(chuàng)造者）在該矩陣中行方向表示用戶，列方向表示信息單位，表中內容C：產(chǎn)生信息（擁有錄入、修改、刪除、統(tǒng)計、查詢權限）Ci：第I個用戶產(chǎn)生的部分信息（匯總量的第I個分量）AIJ=U1：查詢信息（擁有整個企業(yè)查詢權限）U2：查詢信息（只擁有本部門查詢權限）ū：統(tǒng)計匯總（擁有查詢，匯總權限）,,某MIS系統(tǒng)權限分配表,動態(tài)菜單設置,動態(tài)菜單系統(tǒng)設計為辨別用戶的身份，假定規(guī)定用戶口令的第1、2位代表部門編碼，3、4位代表部門內不同崗位編碼。這些編碼經(jīng)過一保密算法映射為機構業(yè)務一覽表或信息權限表的行號。根據(jù)此表對菜單、數(shù)據(jù)窗口等進行動態(tài)設置。目前MIS系統(tǒng)菜單常采用下拉式彈出菜單，對下拉式彈出菜單都有enabled和visible屬性設置。若enabled屬性設置為false則當顯示該菜單時相應項為灰色顯示，用戶也無法執(zhí)行該項下的腳本（script）。當某項菜單屬性visible設置為false時該項將不顯示。,