3.4 數據庫邏輯結構的設計

E-R圖表示的概念模型是用戶數據要求的形式化。正如前面所述，E-R圖獨立于任何一種數據模型，它也不為任何一個DBMS所支持。邏輯結構設計的任務就是把概念模型結構轉換成某個具體的DBMS所支持的數據模型。

從理論上講，設計數據庫邏輯結構的步驟應該是：首先選擇最適合的數據模型，并按轉換規則將概念模型轉換為選定的數據模型。然后要從支持這種數據模型的各個DBMS中選出最佳的DBMS，根據選定的DBMS的特點和限制對數據模型做適當修正。但實際情況常常是先給定了計算機和DBMS，再進行數據庫邏輯模型設計。由于在實際設計時，DBMS是事先已確定的，概念模型向邏輯模型轉換時要適合給定的DBMS。

現行的DBMS一般主要支持關系、網狀或層次模型中的某一種，即使是同一種數據模型，不同的DBMS也有不同的限制，提供不同的環境和工具。

通常把概念模型向邏輯模型的轉換過程分為3步進行。

1）把概念模型轉換成一般的數據模型。

2）將一般的數據模型轉換成特定的DBMS所支持的數據模型。

3）通過優化方法將其轉化為優化的數據模型。

概念模型向邏輯模型的轉換步驟，如圖3-17所示。

3.4.1 概念模型向網狀模型轉換

1.不同型實體集及其聯系的轉換規則

概念模型中的實體集和不同型實體集間的聯系可按下列規則轉換為網狀模型中的記錄和系。

1）每個實體集轉換成一個記錄。

2）每個1：n的二元聯系轉換成一個系，系的方向由1方實體記錄指向n方實體記錄。圖3-18a所示的是一個轉換的實例。

3）每個m：n的二元聯系，在轉換時要引入一個連接記錄，并形成兩個系，系的方向由實體記錄方指向連接記錄方。圖3-18b所示的是一個m：n的二元聯系轉換實例。

4）K（≥3）個實體型之間的多元聯系，在轉換時也引入一個連接記錄，并將聯系轉換成K個實體記錄型和連接記錄型之間的K個系，系的方向均為實體型指向連接記錄，如圖3-19所示。

2.同型實體之間聯系的模型轉換規則

在現實世界中，不僅不同型實體之間有聯系，而且在同型實體（即同一實體集合）中也存在聯系。例如，部門負責人與這一部門的職工都屬于職工這個實體集合，他們都是職工這個實體集的一個子集，但他們之間又存在著領導與被領導的聯系。再如，部件與其構成成分之間的聯系，因為每個部件又是另一些部件的構成成分，因此這是同型實體之間的多對多的聯系。在向網狀模型轉換時，同型實體之間聯系的轉換規則如下。

1）對于同一實體集的一對多聯系，在向網狀模型轉換時要引入一個連接記錄，并轉換為兩個系，系的方向不同。圖3-20a為職工中領導聯系的轉換實例。

2）對于同一實體集之間的m：n聯系，轉換時也要引入一個連接記錄，所轉換的兩個系均由實體記錄方指向連接記錄方。圖3-20b為部件中構成聯系的轉換實例。

3.4.2 概念模型向關系模型的轉換

將E-R圖轉換成關系模型要解決兩個問題：一是如何將實體集和實體間的聯系轉換為關系模式；二是如何確定這些關系模式的屬性和碼。關系模型的邏輯結構是一組關系模式，而E-R圖則是由實體集、屬性以及聯系3個要素組成，將E-R圖轉換為關系模型實際上就是要將實體集、屬性以及聯系轉換為相應的關系模式。

概念模型轉換為關系模型的基本方法如下。

1.實體集的轉換規則

概念模型中的一個實體集轉換為關系模型中的一個關系，實體的屬性就是關系的屬性，實體的碼就是關系的碼，關系的結構是關系模式。

2.實體集間聯系的轉換規則

在向關系模型的轉換時，實體集間的聯系可按以下規則轉換。

（1）1：1聯系的轉換方法

一個1：1聯系可以轉換為一個獨立的關系，也可以與任意一端實體集所對應的關系合并。如果將1：1聯系轉換為一個獨立的關系，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，且每個實體的碼均是該關系的候選碼。如果將1：1聯系與某一端實體集所對應的關系合并，則需要在被合并關系中增加屬性，其新增的屬性為聯系本身的屬性和與聯系相關的另一個實體集的碼。

【例3-1】將圖3-21中含有1：1聯系的E-R圖轉換為關系模型。

該例有3種方案可供選擇（注：關系模式中標有下畫線的屬性為碼）。

方案1：聯系形成的獨立關系，關系模型為：

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

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

負責（職工號，產品號）

方案2：“負責”與“職工”兩關系合并，關系模型為：

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

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

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

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

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

將上面的3種方案進行比較，不難發現：方案1中，由于關系多，增加了系統的復雜性；方案2中，由于并不是每個職工都負責產品，就會造成產品號屬性的NULL值過多。比較起來，方案3比較合理。

（2）1：n聯系的轉換方法

在向關系模型轉換時，實體間的1：n聯系可以有兩種轉換方法：一種方法是將聯系轉換為一個獨立的關系，其關系的屬性由與該聯系相連的各實體集的碼以及聯系本身的屬性組成，而該關系的碼為n端實體集的碼；另一種方法是在n端實體集中增加新屬性，新屬性由聯系對應的1端實體集的碼和聯系自身的屬性構成，新增屬性后原關系的碼不變。

【例3-2】將圖3-22中含有1：n聯系的E-R圖轉換為關系模型。

該轉換有2種轉換方案供選擇（注意：關系模式中標有下畫線的屬性為碼）。

方案1：1：n聯系形成的關系獨立存在。

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

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

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

方案2：聯系形成的關系與n端對象合并。

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

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

比較以上兩個轉換方案可以發現：盡管方案1使用的關系多，但是對倉儲變化大的場合比較適用；相反，方案2中關系少，它適應倉儲變化較小的應用場合。

【例3-3】圖3-23中含有同實體集的1：n聯系，將它轉換為關系模型。

該例題轉換的方案如下（注：關系中標有下畫線的屬性為碼）。

方案1：轉換為兩個關系模式。

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

領導（領導工號，職工號）

方案2：轉換為一個關系模式。

職工（職工號，姓名，年齡，領導工號）

其中，由于同一關系中不能有相同的屬性名，故將領導的職工號改為領導工號。以上兩種方案相比，第2種方案的關系少，且能充分表達原有的數據聯系，所以采用第2種方案會更好些。

（3）m：n聯系的轉換方法

在向關系模型轉換時，一個m：n聯系轉換為一個關系。轉換方法為：與該聯系相連的各實體集的碼以及聯系本身的屬性均轉換為關系的屬性，新關系的碼為兩個相連實體碼的組合（該碼為多屬性構成的組合碼）。

【例3-4】將圖3-24中含有m：n二元聯系的E-R圖，轉換為關系模型。

該例題轉換的關系模型為（注：關系中標有下畫線的屬性為碼）：

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

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

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

【例3-5】將圖3-25中含有同實體集間m：n聯系的E-R圖轉換為關系模式。

轉換的關系模型為（注：關系中標有下畫線的屬性為碼）：

零件（零件號，名稱，價格）

組裝（組裝件號，零件號，數量）

其中，組裝件號為組裝后的復雜零件號。由于同一個關系中不允許存在同屬性名，因而改為組裝件號。

（4）3個或3個以上實體集間的多元聯系的轉換方法

要將3個或3個以上實體集間的多元聯系轉換為關系模式，可根據以下兩種情況采用不同的方法處理。

1）對于一對多的多元聯系，轉換為關系模型的方法是修改n端實體集對應的關系，即將與聯系相關的1端實體集的碼和聯系自身的屬性作為新屬性加入到n端實體集中。

2）對于多對多的多元聯系，轉換為關系模型的方法是新建一個獨立的關系，該關系的屬性為多元聯系相連的各實體的碼以及聯系本身的屬性，碼為各實體碼的組合。

【例3-6】將圖3-26中含有多實體集間的多對多聯系的E-R圖轉換為關系模型。

轉換后的關系模式如下：

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

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

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

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

其中，關系中標有下畫線的屬性為碼。

3.關系合并規則

在關系模型中，具有相同碼的關系，可根據情況合并為一個關系。

3.4.3 用戶子模式的設計

用戶子模式也稱外模式。關系數據庫管理系統中提供的視圖是根據用戶子模式設計的。設計用戶子模式時只考慮用戶對數據的使用要求、習慣及安全性要求，而不用考慮系統的時間效率、空間效率、易維護等問題。在設計用戶子模式時應注意以下問題。

1.使用更符合用戶習慣的別名

前面提到，在合并各分E-R圖時應消除命名的沖突，這在設計數據庫整體結構時是非常必要的。但命名統一后會使某些用戶感到別扭，用定義子模式的方法可以有效地解決該問題。必要時，可以對子模式中的關系和屬性名重新命名，使其與用戶習慣一致，以方便用戶的使用。

2.對不同級別的用戶可以定義不同的子模式

由于視圖能夠對表中的行和列進行限制，所以它還具有保證系統安全性的作用。對不同級別的用戶定義不同的子模式，可以保證系統的安全性。

例如，假設有關系模式：產品（產品號，產品名，規格，單價，生產車間，生產負責人，產品成本，產品合格率，質量等級）。如果在產品關系上建立以下兩個視圖。

1）為一般顧客建立視圖：

產品1（產品號，產品名，規格，單價）

2）為產品銷售部門建立視圖：

產品2（產品號，產品名，規格，單價，車間，生產負責人）

在建立視圖后，產品1視圖中包含了允許一般顧客查詢的產品屬性；產品2視圖中包含允許銷售部門查詢的產品屬性；生產領導部門則可以利用產品關系查詢產品的全部屬性數據。這樣，既方便了使用，也可以防止用戶非法訪問本來不允許他們查詢的數據，保證了系統的安全性。

3.簡化用戶對系統的使用

利用子模式可以簡化使用，方便查詢。實際中經常要使用某些很復雜的查詢，這些查詢包括多表連接、限制、分組、統計等。為了方便用戶，可以將這些復雜查詢定義為視圖，用戶每次只對定義好的視圖進行查詢，避免了每次查詢都要對其進行重復描述，大大簡化了用戶的使用。

3.4.4 數據庫邏輯結構設計的實例

假如要為某基層單位建立一個“基層單位”數據庫。通過調查得出，用戶要求數據庫中存儲下列基本信息。

部門：部門號，名稱，領導人編號

職工：職工號，姓名，性別，工資，職稱，照片，簡歷

工程：工程號，工程名，參加人數，預算，負責人

辦公室：地點，編號，電話

這些信息的關聯的語義為：

每個部門有多個職工，每個職工只能在一個部門工作。

每個部門只有一個領導人，領導人不能兼職。

每個部門可以同時承擔若干工程項目，數據庫中應記錄每個職工參加項目的日期。

一個部門可有多個辦公室。

每個辦公室只有一部電話。

數據庫中還應存放每個職工在所參加的工程項目中承擔的具體職務。

1.概念模型的設計

調查得到數據庫的信息要求和語義后，還要進行數據抽象，才能得到數據庫的概念模型。設基層單位數據庫的概念模型如圖3-27所示。為了清晰，圖中將實體的屬性略去了。該E-R圖表示的“基層單位”數據庫系統中應包括“部門”“辦公室”“職工”和“工程”4個實體集，其中：部門和辦公室間存在1：n的“辦公”聯系；部門和職工間存在著1：1的“領導”聯系和1：n的“工作”聯系；職工和工程之間存在1：n的“負責”聯系和m：n的“參加”聯系；部門和工程之間存在著1：n的“承擔”聯系。

2.關系模型的設計

圖3-26的E-R圖可按規則轉換一組關系模式。表3-2中列出了這組關系模式及相關信息。表中的一行為一個關系模式，關系的屬性根據數據字典得出。

該關系模型開始設計為10個關系，將1：n聯系和1：1聯系形成的關系模式與相應的實體形成的關系模式合并后，有5個關系優化掉了，結果為5個關系模式。這樣，該“基本單位”數據庫中應該有5個基本關系。