1.7 數據庫設計

1.7.1 數據庫設計概述

數據庫設計是建立數據庫及其應用系統的技術，是信息系統開發過程中的關鍵技術。數據庫設計的主要任務是對于一個給定的應用環境，根據用戶的各種需求，構造出最優的數據庫模式，建立數據庫及其應用系統，使之能夠有效地對數據進行管理。數據庫設計的內容主要有兩個方面，分別是結構特性設計和行為特性設計。結構特性設計是指確定數據庫的數據模型，在滿足要求的前提下盡可能地減少冗余，實現數據共享。行為特性設計是指確定數據庫應用的行為和動作，應用的行為由應用程序體現，所以行為特性的設計主要是應用程序的設計。在數據庫領域中，通常會把使用數據庫的各類系統稱為數據庫應用系統。因此，在進行數據庫設計時，要和應用系統的設計緊密聯系起來，也就是把結構特性設計和行為特性設計緊密結合起來。

針對數據庫的設計，人們不斷地研究與探索，在不同階段從不同角度提出了各種數據庫設計方法，這些方法運用軟件工程的思想，提出了各種設計準則和規程，都屬于規范設計法。依據規范設計的方法，考慮數據庫及其應用系統開發的全過程，人們將數據庫系統設計分為六個階段：需求分析、概念結構設計、邏輯結構設計、數據庫物理設計、數據庫實施、數據庫運行和維護，如圖1-16所示。

1.7.2 需求分析

需求分析就是分析用戶的各種需求。進行數據庫設計首先必須充分地了解和分析用戶需求（包括數據與處理）。作為整個設計過程的起點，需求分析是否充分和準確，決定了在其上構建數據庫的速度與質量。需求分析沒做好，會導致整個數據庫設計不合理、不實用，必須重新再設計。

需求分析的任務，就是對現實世界要處理的對象進行詳細調查，充分了解現有系統的工作情況或手工處理工作中存在的問題，盡可能多地收集數據，明確用戶的各種實際需求，然后在此基礎上確定新的系統功能，新系統還得充分考慮今后可能的擴充與改變，不能僅按當前應用需求來設計。

調查用戶實際需求通常按以下步驟進行。

（1）調查現實世界的組織機構情況。確定數據庫設計與組織機構中的哪些部門相關，了解這些部門的組成情況及職責，為分析信息流程做準備。

（2）調查相關部門的業務活動情況。要調查相關部門需要輸入和使用什么數據，這些數據該如何加工與處理，各部門需要輸出哪些信息，這些信息輸出到哪些部門，輸出信息的格式是什么，這些都是調查的重點。

（3）在熟悉了業務活動的基礎上，協助用戶明確對新系統的各種實際需求，包括信息要求、處理要求、安全性與完整性要求，這也是調查過程中非常重要的一點。

（4）確定新系統的邊界。對前面的調查結果進行初步分析，確定哪些功能現在就由計算機完成，哪些功能將來準備讓計算機完成，哪些功能由人工完成。由計算機完成的功能就是新系統應該實現的功能。

在調查過程中根據不同的問題與條件，可以采用不同的調查方法。

（1）開調查會。通過與用戶座談的方式來了解業務活動情況及用戶需求。

（2）設計調查表請用戶填寫。提前設計一個合理的針對業務活動的調查表，并將此表發給相關的用戶進行針對性調查。

（3）查閱記錄。查閱與原系統有關的數據記錄。

（4）詢問。對某些調查中的問題，可以找專人詢問。

（5）請專人介紹。請業務活動過程中的用戶或對業務熟練的專家介紹業務相關知識和活動情況，設計人員從中了解并詢問相關問題。

（6）跟班作業。通過親自參與各部門業務活動來了解用戶的具體需求，但是這種方法比較耗時。

調查過程中的重點在于“數據”與“處理”。通過調查、收集與分析，獲得用戶對數據庫的如下要求。

（1）信息需求。指用戶需要從數據庫中獲得信息的內容與實質。也就是將來要往系統中輸入什么信息及從系統中得到什么信息，由用戶對信息的要求就可以導出對數據的要求，即在數據庫中需存儲哪些數據。

（2）處理要求。用戶要實現哪些處理功能，對數據處理響應時間有什么樣的要求及要采用什么樣的數據處理方式。

（3）安全性和完整性要求。數據的安全性措施和存取控制要求，數據自身的或數據間的約束限制。

了解了用戶的實際需求以后，還需要進一步分析和表達用戶的需求。在眾多的分析方法中，結構化分析方法（Structured Analysis，簡稱SA方法）是一種簡單實用的方法。SA方法從最上層的系統組織結構入手，采用自頂向下、逐層分解的方式分析系統。

經過需求分析階段后會形成系統需求說明書，說明書中要包含數據流圖、數據字典、各類數據的統計表格、系統功能結構圖和必要的說明。該說明書在數據庫設計的全過程中非常重要，是各階段設計所依據的文檔。

1.7.3 概念結構設計

概念結構設計是整個數據庫設計的關鍵，是將需求分析階段得到的用戶需求進行總結、歸納，并抽象成信息結構即概念模型的過程。

概念結構設計通常有四類方法：

（1）自頂向下。首先定義全局概念結構的框架，再逐步細化。

（2）自底向上。首先定義各局部應用的概念結構，再按一定規則將它們集成起來，最后得到全局概念結構。

（3）逐步擴張。首先定義最重要的核心概念結構，然后向外擴張，以滾雪球的方式逐步生成其他概念結構，直至全局概念結構。

（4）混合策略。將自頂向下和自底向上相結合，先用自頂向下方法設計一個全局概念結構的框架，然后再以它為框架集成由自底向上方法設計的各局部概念結構。

在設計過程中通常先自頂向下進行需求分析，然后再自底向上設計概念結構。其方法如圖1-17所示。

概念結構設計主要應用E-R圖（Entity Relationship Diagram，實體-聯系圖）來完成。按照圖1-17所示的自頂向下進行需求分析與自底向上進行概念結構設計的方法，概念結構的設計可以按照以下步驟進行。

1. 對數據進行抽象并設計局部E-R圖

概念結構是對現實世界的一種抽象。抽象就是對客觀的人、事、物和概念進行處理，把所需要的共同特性抽取出來而忽略非本質的內容，并把這些共同特性用概念精準地描述出來，組成模型。抽象通常有三種方法。

（1）分類（Classification）：定義某一類概念作為現實世界中一組對象的類型，這些對象具有某些共同的特性和行為。在E-R模型中，實體型就是這種抽象。例如，張三豐是學生，具有學生們共同的特性和行為。

（2）聚集（Aggregation）：定義某一類型的組成成分。在E-R模型中若干屬性的聚集組成了實體型。例如學生有學號、姓名、系別、專業、班級等屬性。有時某一類型的組成成分也可能是一個聚集，例如部門有部門名稱、位置及經理等屬性，而經理又有姓名、年齡、性別等屬性。

（3）概括（Generalization）：定義類型之間的一種子集聯系。例如學生是一個實體型，小學生、本科生也是實體型。但小學生和本科生均是學生的子集。

概念結構設計首先就是要利用上面的抽象機制對需求分析階段收集到的數據分類、組織（聚集），形成實體型、屬性和碼，確定實體型之間的聯系類型（一對一、一對多或多對多），進而設計E-R圖。在設計的過程中應該遵循這樣一個原則：現實世界中的事物能作為屬性對待的，盡量作為屬性對待。這點可以按以下兩條準則來考慮。

（1）作為屬性，不能再具有需要描述的性質，也就是屬性是不可分的數據項。

（2）屬性不能與其他實體型有聯系，即E-R圖所表示的聯系是實體型之間的聯系。

只要滿足了以上兩條準則，通常可作為屬性對待。例如，職工是一個實體型，可以包括職工號、姓名、年齡等屬性，如果職稱沒有與工資、福利掛鉤就可以將其作為該實體型的屬性，但如果不同的職稱有不同的工資和住房標準等，則職稱作為一個實體型會更合適，它的屬性可以包括職稱代碼、工資、住房標準等。

2. 將各局部E-R圖進行合并，形成初步E-R圖

各局部E-R圖設計完成后，還需要對它們進行合并，集成為系統整體的E-R圖，當然，形成的這個E-R圖只是一個初步的E-R圖。局部E-R圖的集成有兩種方法。

（1）一次集成法，就是一次性地將所有局部E-R圖合并為全局E-R圖。此方法操作比較復雜，不易實現。

（2）逐步集成法，先集成兩個局部E-R圖，然后用累加的方式合并進去一個新的E-R圖，這樣一直繼續下去，直到得到全局的E-R圖。此方法降低了合并的復雜度，效率高。

無論采用哪種方法生成全局E-R圖，在這個過程中都要考慮消除各局部E-R圖之間的沖突和冗余。因為在合并過程中，各個局部應用所對應的問題不同，而且通常是由不同的設計人員進行局部E-R圖設計，這樣就會導致各局部E-R圖之間有可能存在沖突，因此合并局部E-R圖時要注意消除各局部E-R圖中的不一致，以形成一個能為全系統所有用戶共同理解和接受的統一概念模型。各局部E-R圖之間的沖突主要有三類。

（1）屬性沖突。主要包括：屬性域沖突即屬性值的類型、取值范圍或取值集合不同。例如“年齡”，有的部門用日期表示，有的部門用整數表示；屬性取值單位沖突，例如“體重”，有的以公斤為單位，有的以斤為單位。該沖突需要各部門協商解決。

（2）命名沖突。主要包括：同名異義，即不同意義的對象在不同的局部應用中具有相同的名字。例如“單位”可以表示職工所在的部門，也可以表示物品的重量或體積等屬性；異名同義（一義多名），即意義相同的對象在不同的局部應用中有不同的名字。例如“項目”，有的部門稱為項目，而有的部門稱為課題。該沖突也可以通過討論、協商來解決。

（3）結構沖突。主要包括：同一對象在不同的應用中具有不同的抽象。例如，“職稱”在某一局部應用中作為實體，在另一局部應用中作為屬性。在解決該沖突時就是把屬性變為實體或把實體變為屬性，使同一對象具有相同的抽象。

另外，同一實體在不同局部E-R圖中的屬性個數和排列順序也可能不完全一致。解決方法是使該實體的屬性取各局部E-R圖中屬性的并集，再適當調整屬性的順序。

此外，實體之間的聯系也可能在不同的局部E-R圖中呈現不同的類型。例如E1與E2在一個局部E-R圖中是一對一聯系，而在另一個局部E-R圖中是多對多聯系；又或者在一個局部E-R圖中E1與E2有聯系，而在另一個局部E-R圖中E1、E2和E3三者之間有聯系。解決方法是根據應用語義對實體聯系的類型進行整合或調整。

3. 消除不必要的冗余，形成基本E-R圖

在合并后的初步E-R圖中，可能存在冗余的數據和冗余的聯系。所謂冗余的數據是指可由基本數據導出的數據，冗余的聯系是指可由其他聯系導出的聯系。冗余的數據和聯系容易破壞數據庫的完整性，增加數據庫維護的難度，應該消除。但是，并不是所有的冗余都要消除，有時為了提高效率是可以允許冗余的存在的。因此在概念結構設計階段，哪些冗余信息要消除，哪些可以保留，需要根據用戶的整體需求來確定。消除了冗余的初步的E-R圖稱為基本E-R圖，它代表了用戶的數據要求，決定了下一步的邏輯結構設計，是成功創建數據庫的關鍵。

1.7.4 邏輯結構設計

概念結構設計階段得到的E-R圖是反映了用戶需求的模型，它獨立于任何一種數據模型，獨立于任何一個數據庫管理系統。邏輯結構設計階段的任務就是將上一階段設計好的基本E-R圖轉換為與選用的數據庫管理系統產品所支持的數據模型相符合的邏輯結構。

目前的數據庫應用系統通常采用支持關系模型的關系數據庫管理系統，所以這里只討論關系數據庫的邏輯結構設計，也就是只介紹如何將E-R圖向關系模型轉換的原則與方法。

關系模型的邏輯結構是一組關系模式的集合。概念結構設計階段得到的E-R圖是由實體、實體的屬性和實體間的聯系三個要素組成的。所以E-R圖向關系模型的轉換要解決的問題是如何將實體、實體的屬性和實體間的聯系轉換為關系模式。在轉換過程中要遵循的原則如下。

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

（2）可以將1:1聯系轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。若為前者，則與該聯系相連的各實體的碼及聯系本身的屬性均轉換為關系的屬性，且每個實體的碼均是該關系的候選碼。若為后者，則需要在某一關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。

【例1-1】將圖1-18所示的含有1:1聯系的E-R圖按上述規則轉換為關系模式。

方案1：聯系轉換為一個獨立的關系模式：

職工（職工號，姓名，年齡）；

產品（產品號，產品名，價格）；

負責（職工號，產品號）。

方案2：“負責”與“職工”關系模式合并：

職工（職工號，姓名，年齡，產品號）；

產品（產品號，產品名，價格）。

方案3：“負責”與“產品”關系模式合并：

職工（職工號，姓名，年齡）；

產品（產品號，產品名，價格，職工號）。

（3）可以將1:n聯系轉換為一個獨立的關系模式，也可以與聯系n端對應的關系模式合并。如果為前者，則與該聯系相連的各實體的碼及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼；如果為后者，可以在n端實體中增加由聯系對應的1端實體的碼和聯系的屬性構成的新屬性，新增屬性后原關系的碼不變。

【例1-2】將圖1-19所示的含有1:n聯系的E-R圖轉換為關系模式。

方案1：聯系轉換為一個獨立的關系模式：

倉庫（倉庫號，地點，面積）；

產品（產品號，產品名，價格）；

倉儲（倉庫號，產品號，數量）。

方案2：與n端對應的關系模式合并：

倉庫（倉庫號，地點，面積）；

產品（產品號，產品名，價格，倉庫號，數量）。

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

【例1-3】將圖1-20所示的含有m:n聯系的E-R圖轉換為關系模式。

轉換后的關系模式為：

學生（學號，姓名，年齡，性別）；

課程（課程號，課程名，學時數）；

選修（學號，課程號，成績）。

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

【例1-4】將圖1-21所示的含有多實體間m:n聯系的E-R圖轉換為關系模式。

供應商（供應商號，供應商名，地址）；

零件（零件號，零件名，單價）；

產品（產品號，產品名，型號）；

供應（供應商號，零件號，產品號，數量）。

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

經過以上步驟后已經將E-R圖按規則轉換成關系模式，但邏輯結構設計的結果并不是唯一的。為了進一步提高數據庫應用系統的性能，還應該根據客觀需要對結果進行規范化處理，消除異常，改善完整性、一致性，提高存儲效率。除此之外，還要從功能及性能上評價數據庫模式是否能滿足用戶的要求，可以采用增加、合并、分解關系的方法優化數據模型的結構，最后得到規范化的關系模式，形成邏輯結構設計說明書。

1.7.5 數據庫物理設計

數據庫在物理設備上的存儲結構與存取方法稱為數據庫的物理結構，它與給定的計算機系統相關。數據庫的物理設計，就是為一個給定的邏輯數據模型選取一個最適合應用要求的物理結構的過程。此階段是以邏輯結構設計階段的結果為依據，結合具體的數據庫管理系統特點與存儲設備特性進行設計，確定數據庫在物理設備上的存儲結構和存取方法。該階段分以下兩步來進行。

（1）首先確定數據庫的物理結構，在關系數據庫中主要指的是存儲結構與存取方法。

（2）從時間效率和空間效率兩個方面來對數據庫的物理結構進行評價。

如果評價結果滿足原設計要求，就能進入到數據庫實施階段，否則就要修改，甚至重新設計物理結構，如果還不能滿足要求甚至要回到邏輯結構設計階段修改數據模型。

1.7.6 數據庫實施

在數據庫實施階段，設計人員運用關系數據庫管理系統提供的數據語言及其宿主語言，根據邏輯結構設計和物理設計的結果建立數據庫，編制和調試應用程序，組織數據入庫，并進行試運行。

1.7.7 數據庫運行和維護

數據庫應用系統經過試運行后，即可投入正式運行，在數據庫系統運行過程中必須不斷對其進行評價、調整和修改。在該階段，對數據庫經常性的維護工作是由DBA完成的，主要包括以下幾點。

（1）數據庫的轉儲和恢復，它是系統正式運行后最重要的維護工作之一。DBA要針對不同的應用要求制定不同的轉儲計劃，以保證突發故障時能盡快將數據庫恢復到某種一致的狀態，并將對數據庫的破壞降到最低。

（2）數據庫的安全性、完整性控制。數據庫在運行過程中，安全性要求也會發生變化，此時DBA要根據實際情況修改原有的安全性控制。同樣，數據庫的完整性約束條件也會發生變化，也需要DBA及時修改，以滿足用戶要求。

（3）數據庫性能的監督、分析和改造。運行過程中，監督系統運行，對監測數據進行分析，找出改進系統性能的方法是DBA的又一重要任務。DBA對這些數據要認真分析，判斷當前系統運行狀況是否需要改進以達到最佳狀態。

（4）數據庫的重組織和重構造。數據庫運行一段時間后，由于不斷的增、刪、改操作，會導致數據庫的物理存儲情況變壞，數據的存取效率降低，數據庫的性能下降，這時DBA就需要對數據庫進行部分重組織（只針對頻繁改動的表進行）。重組織，就是按原設計要求重新安排存儲位置、回收垃圾、減少指針鏈等，使系統性能得以提高。數據庫的重組織并不修改原設計的邏輯和物理結構，但數據庫的重構造需要部分修改數據庫的模式和內模式。

數據庫應用系統的設計過程就是以上步驟的不斷反復過程。

1.7.8 數據庫設計案例

本小節以學生選課管理系統的數據庫設計為例。設計時做了一定的簡化，忽略了一些異常情況的考慮，旨在重點闡述數據庫設計步驟。

1. 基本需求分析

某學校需要開發一套學生選課管理系統。為了收集數據庫需要的信息，設計人員與系統使用人員通過交談、填寫調查表等方式進行了系統的需求調研，得出系統要實現的功能有：學生可以通過該系統查看所有選修課程的相關信息，包括課程名、學時、學分，然后選擇選修的課程（一個學生可以選修多門課程，一門課程可以由多個學生選修）；學生可以通過該系統查看相關授課老師的信息，包括教師姓名、性別、學歷、職稱；老師可以通過該系統查看選修自己課程的學生的信息，包括學號、姓名、性別、出生日期、班級（假定本校一個教師可以教授多門課程，一門課程只能由一個教師任教）；在考試結束后，老師可以通過該系統錄入學生的考試成績，學生可以通過該系統查看自己的考試成績。

2. 概念結構設計

（1）通過分析，得到該系統中的實體以及實體的屬性，如圖1-22所示。

（2）根據實體間的聯系畫出局部E-R圖，如圖1-23所示。

（3）將各局部E-R圖進行合并，消除冗余后，形成基本E-R圖，如圖1-24所示。

3. 邏輯結構設計

由基本E-R圖按規則轉換、進行規范化處理并優化后的關系模式是：

學生（學號，姓名，性別，出生日期，班級）

教師（工號，姓名，性別，學歷，職稱）

課程（課程號，課程名，學時，學分，授課教師工號）

選課（學號，課程號，成績）

4. 數據庫物理設計

學生、教師、課程、選課表對應的表結構如表1-6至表1-9所示。

在數據庫系統中建立對應的表，填充一定的測試數據后就可以試運行應用程序，如無問題即可正式投入使用，后期只需做好更新和維護工作。