1.3 關系數據庫設計

一個信息系統的各部分能否緊密地結合在一起以及如何結合，關鍵在數據庫。因此，對數據庫進行合理的邏輯設計和有效的物理設計才能開發出完善而高效的信息系統。數據庫設計是信息系統開發和信息建設的重要組成部分。

1.3.1 數據庫設計的任務、內容與步驟

1.數據庫設計的任務

數據庫設計的任務是針對一個給定的應用環境，創建一個良好的數據庫模式，建立數據庫及其應用系統，使之能有效的收集、存儲、操作和管理數據，滿足用戶的各種需求。

2.數據庫設計的內容

數據庫設計是在一個通用的DBMS支持下進行的，即利用現成的DBMS作為開發的基礎。數據庫設計的內容主要包括結構特性設計和行為特性的設計兩個方面的內容。結構特性的設計是指確定數據庫的數據模型，數據模型反映了現實世界的數據及數據之間的聯系，在滿足要求的前提下，盡可能的減少冗余，實現數據的共享。行為特性的設計是指確定數據庫應用的行為和動作，應用的行為體現在應用程序中，行為特性的設計主要是應用程序的設計。因為在數據庫工程中，數據庫模型是一個相對穩定的并為所有用戶共享的數據基礎，所以數據庫設計重點是結構特性設計，但必須與行為特性設計相結合。

3.數據庫設計的步驟

人們不斷的研究探索，提出了各種數據庫的規范設計方法，其中比較有名的是新奧爾良法（New Orleans），按照規范設計方法，考慮數據庫及其應用系統開發的全過程，將數據庫的設計分為如下六個階段：需求分析階段，概念設計階段，邏輯設計階段，物理設計階段，實施階段，運行和維護階段。各階段也不是嚴格線性的，而是采取“反復探尋、逐步求精”的方法，如圖1.9所示。

1.3.2 需求分析

需求分析就是分析用戶的需求。需求分析是設計數據庫的起點，需求分析的結構將影響到各個階段的設計，以及最后結果的合理性與實用性。

1.需求分析的任務

需求分析的任務是通過詳細調查現實世界中要處理的對象（組織、部門、企業）等，在了解現行系統工作情況，確定新系統功能的過程中，收集支持系統運行的基礎數據及其處理方法，明確用戶的各種需求。

調查的重點是“數據”和“處理”，通過調查、收集與分析，獲得用戶對數據庫的如下需求：

（1）信息需求。指用戶要從應用系統中獲得信息的內容與性質。即未來系統中要輸入的信息，從數據庫中要獲得什么信息等。由信息的要求就可以導出數據的要求，即在數據庫中存儲什么數據。

（2）處理要求。指用戶要完成什么樣的處理，對處理的響應時間有什么要求，是什么樣的處理方式。

（3）安全性與完整性要求。

確定用戶的需求是非常困難的，因為用戶往往對計算機應用不太了解，難以準確表達自己的需求。另一方面，計算機專業人員又缺乏用戶的專業知識，存在與用戶準確溝通的障礙。只有通過不斷與用戶深入地交流，才能準確地確定用戶的真正需求。

2.需求分析基本步驟

需求分析一般要進行如下幾步：

（1）需求的收集：收集數據及其發生時間、頻率，數據的約束條件、相互聯系等。

（2）需求的分析整理。

① 數據流程分析，結果描述產生數據流圖。

② 數據分析統計，對輸入、存儲、輸出的數據分別進行統計。

③ 分析數據的各種處理功能，產生系統功能結構圖。

3.階段成果

需求分析階段成果是系統需求說明書，此說明書主要包括數據流圖、數據字典、各類數據的統計表格、系統功能結構圖和必要的說明。系統需求說明書將作為數據庫設計的全過程依據的文件。

1.3.3 概念結構設計

如前所述，表達概念設計結果的工具成為概念模型。將需求分析得到的用戶需求抽象為信息世界的概念模型的過程就是概念結構設計。它是整個數據庫設計的關鍵。概念設計不依賴于具體的計算機系統和DBMS。

1.概念設計的策略和步驟

（1）設計概念結構的策略有如下幾種：

① 自頂向下：首先定義全局概念結構的框架，再做局部細化。

② 自底向上：先定義每一局部應用的概念結構，然后按一定的規則把他們集成，進而得到全局的概念結構。

③ 由里向外：首先定義核心結構，然后再擴展。

④ 混合策略：就是將自頂向下和自底向上結合起來，先用前一種方法確定框架，再用自底向上設計局部概念，然后再結合起來。

（2）常用自底向上策略的設計步驟。

① 進行局部抽象，設計局部概念。

② 將局部概念模式綜合成全局概念模式

③ 進行評審，改造。

2.采用E-R方法的數據庫概念設計步驟

采用E-R方法的數據庫概念設計步驟分三步：

（1）設計局部E-R模型，局部E-R圖的設計步驟如圖1.10所示。在設計E-R模型的過程中應遵循這樣一個原則：現實世界中的事物能作為屬性對待的，盡量作為屬性對待。什么樣的事物可以作為屬性對待？下列兩類：

? 作為屬性，不能是再具有需要描述的性質。

? 屬性不能與其他實體具有聯系。

（2）設計全局E-R模型。將所有局部的E-R圖集成為全局的E-R概念模型，一般采用兩兩集成的方法，即先將具有相同實體的E-R圖，以該相同的實體為基準進行集成，如果還有相同的實體，就再次集成，這樣一直繼續下去，直到所有具有相同實體的局部E-R圖都被集成，從而得到全局的E-R圖。在集成的過程中，要消除屬性、結構、命名三類沖突，實現合理的集成。

（3）全局E-R模型的優化。一個好的全局的E-R模型能反映用戶功能需求外，還應做到實體個數盡可能少，實體類型所含屬性盡可能少，實體類型間的聯系無冗余。全局E-R模型的優化就是要達到這三個目的。

采用以下集中方法。

① 合并相關的實體類型：把1∶1聯系的兩個實體類型合并，合并具有相同鍵的實體類型。

② 消除冗余屬性與聯系：消除冗余主要采用分析法，并不是所有的冗余必須消除，有時為了提高效率，可以保留部分冗余。

1.3.4 邏輯結構設計

概念結構是獨立于任何數據模型的信息結構。邏輯結構設計的任務就是將概念模型轉化成特定的DBMS系統所支持的數據庫的邏輯結構（數據庫的模式和外模式）。

1.邏輯結構設計的步驟

由于現在設計的數據庫應用系統都普遍采用支持關系模型的RDBMS，所以這里僅介紹關系數據庫邏輯結構的設計。關系數據庫邏輯結構設計時一般分三步：

① 將概念結構向一般的關系模型轉換。

② 將轉換來的關系模型向特定的RDBMS支持的數據模型轉換。

③ 對數據模型進行優化。

2.E-R模型向關系數據庫的轉換規則

如何將E-R模型的實體和實體間的聯系轉換成關系模式，如何確定這些關系模式的屬性和碼，這些問題是通過E-R模型向關系模式轉換的規則來解決的。E-R模型向關系數據庫的轉換規則是：

（1）一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性，實體的碼就是關系的碼。

（2）一個1∶1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式，則相連的每個實體的碼及該聯系的屬性是該關系模式的屬性，每個實體的碼均是該關系模式的候選碼。

（3）一個1∶n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。如果轉換為一個獨立的關系模式。與該聯系相連的各實體的碼及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼。

（4）一個m∶n聯系轉換為一個關系模式。與該聯系相連的各個實體的碼及聯系本身的屬性轉換為關系的屬性，而該關系的碼為各實體的碼的組合。

（5）三個以上實體間的一個多元聯系可以轉換為一個關系模式。與該多元聯系相連的各實體的碼及聯系本身的屬性轉換為關系的屬性，而該關系的碼為各實體碼的組合。

（6）具有相同碼的關系模式可以合并。

3.關系數據庫的邏輯設計

關系數據庫邏輯設計的過程如下：

（1）導出初始的關系模式：將E-R模型按規則轉換成關系模式。

（2）規范化處理：消除異常，改善完整性、一致性和存儲效率。

（3）模式評價：檢查數據庫模式是否能滿足用戶的要求，它包括功能評價和性能評價。

（4）優化模式：采用增加、合并、分解關系的方法優化數據模型的結構，提高系統性能。

（5）形成邏輯設計說明書。

1.3.5 數據庫設計案例

本節以某高校學分制選課系統的數據庫設計為例，重點介紹數據庫設計中的概念設計與邏輯設計部分。為了便于學生理解和授課，對學生選課系統做了一定的簡化和假設，并忽略了一些異常情況。

某高校學生選課系統要求：學生根據開課清單選課，系統根據教學計劃檢查應修的必修課并自動選擇；檢查是否存在未取得學分的必修課，如果存在，則要求重選；學生按選修課選課規則選學選修課（例如4組選修課中選3門）；學生可以查詢各門課程的成績、學分及平均學分績；輸出學生的個人課表，輸出學生的選課交費清單。

1.學生選課管理部分數據流圖（如圖1.11和圖1.12所示）

2.學生選課管理系統的E-R圖

（1）設計局部E-R模型。

以學生選課系統數據流圖為依據，設計局部E-R模型的步驟如下：

① 確定實體類型。學生選課系統實體類型有：學生、教學計劃、課程、教師。

② 確定聯系類型。

學生與教學計劃之間是m∶1聯系，即一個專業一年級只對應一個教學計劃，而一個專業同一個年級有多名學生，定義聯系為“學生—教學計劃”。

教學計劃和課程之間是n∶m聯系，即一個專業一個年級的教學計劃可以包含多門課程，而同一門課程被多個專業所選擇，定義聯系為“教學計劃—課程”。

學生與課程之間是m∶n聯系，即一個學生可以選多門課程，一門課程可以被多個學生選學，定義聯系為“學生—課程”。

教師與課程之間是m∶n聯系，即一名教師可以講授多門課程，一門課程也可以由多名教師講授，定義聯系為“教師—課程”。

學生與教師之間是m∶n聯系，即一名教師可教多個學生，一個學生可以由多個教師教，定義聯系為“學生—教師”。

學生選學了課程，也就選擇了教師，學生與教師的聯系是通過授課聯系起來的。

③ 確定實體類型的屬性。

實體類型“教學計劃”有屬性：專業，專業學級，課程，開課學期，周學時數，學分，啟始周，結束周。

實體類型“課程”有屬性：課程號，課程名，學時數，學分。

實體類型“學生”有屬性：學號，姓名，性別，出生日期，系，專業，班級，入學時間。

實體類型“教師”有屬性：教師編號，姓名，性別，出生日期，學歷，職稱，職務，專業。

④ 確定聯系類型的屬性。

“學生—教學計劃”聯系，由于學生只是根據教學計劃的要求來進行課程的選擇，所以此聯系沒有屬性。

“教學計劃—課程”聯系，由教學計劃來決定每一學期的課程，所以教學計劃包含課程，所以“教學計劃—課程”聯系的屬性，可以歸結到教學計劃實體類型的屬性中，即將“教學計劃”實體類型的屬性課程，改為課程號即可。

“學生—課程”聯系，學生在每一學期都要進行課程的選擇，已得到該學期的學分和交費，所以此聯系的屬性有：學號（實體類型學生的碼），課程號（實體類型課程的碼），學年，學期，成績，學分（所得學分），交費。

“教師—課程”聯系，教師教課實際是在教學生，此聯系必須能夠向教師提供學生的一些情況，所以聯系的屬性有：課程號，教師編號，專業，專業學級，學年，學期，學時數，開始周，結束周。

“學生—教師”聯系，學生和老師之間的聯系實際上是通過課程建立起來的，所以它們之間的聯系屬性只是實體類型碼之間的聯系，即學號和教師編號，可以省略。

⑤ 根據實體類型和聯系類型畫出E-R圖。

在設計E-R模型的過程中應遵循這樣一個原則：現實世界中的事物能作為屬性對待的，盡量作為屬性對待。

（2）設計全局E-R模型。將所有局部的E-R圖集成為全局的E-R概念模型，如圖1.14所示，全局E-R圖中省略了班級、系部等部分實體和部分屬性。在集成的過程中，要消除屬性、結構、命名三類沖突，實現合理的集成。

（3）全局E-R模型的優化。分析圖1.14全局E-R模型，看一看能否反映用戶功能需求，盡量做到實體的個數盡可能的少，實體類型所含屬性盡可能的少，實體類型間的聯系無冗余。

3.學生選課管理關系模式

（1）將學生選課管理系統的E-R模型按規則轉換成如下關系模式：

系部（系部代碼，系部名稱，系主任）

專業（專業代碼，專業名稱，系部代碼）

班級（班級代碼，班級名稱，專業代碼，系部代碼，備注）

課程（課程號，課程名，備注）

學生（學號，姓名，性別，出生日期，入學時間，班級代碼，專業代碼，系部代碼）

教師（教師編號，姓名，性別，出生日期，學歷，職務，職稱，系部代碼）

學生—課程—教師（學號，課程號，教師編號，成績，學分）

（2）模式評價與優化。檢查數據庫模式是否能滿足用戶的要求，根據功能需求，增加關系、屬性并規范化，得到如下關系模式：

系部（系部代碼，系部名稱，系主任）

專業（專業代碼，專業名稱，系部代碼）

班級（班級代碼，班級名稱，專業代碼，系部代碼）

教師（教師編號，姓名，性別，出生日期，學歷，職務，職稱，系部代碼，專業）

學生（學號，姓名，性別，出生日期，入學時間，班級代碼）

課程（課程號，課程名稱，備注）

教學計劃（課程號，專業代碼，專業學級，課程類型，開課學期，學分，啟始周，結束周）

教師任課（教師編號，課程號，專業學級，專業代碼，學年，學期，學生數，學時數，酬金，開始周，結束周）

課程注冊（學號，教師編號，課程號，專業學級，專業代碼，選課類型，學期，學年，收費否，注冊，成績，學分）

管理員（用戶名，密碼，備注）

收費表（學號，課程號，收費，學年，學期）

系統代碼表（ID，代碼類別，編號，代碼名稱）

4.系統物理結構設計

以具體的RDDMS（如SQL Server 2008）為環境，根據邏輯設計產生的關系模式設計學生、教師、課程、班級、專業、系部、課程注冊和收費表的表結構。

5.數據庫實施與維護

在RDDMS（如SQL Server 2008）環境中，創建數據庫和數據表，組織數據入庫；根據需要創建表、視圖及其他數據對象。最后，在使用過程中對數據庫進行維護。