數據庫設計理論及應用（5）——邏輯結構設計 作者：最后一只恐龍 發(fā)表時間：2007-6-27 ? 該系列計劃包括5部分：完整性約束理論及應用、范式理論及應用、需求分析、概念結構設計、邏輯結構設計。本文是第五部分，介紹邏輯結構設計的內容，包括E-R圖向關系模型的轉換、數據模型的優(yōu)化、用戶子模式的設計等問題。 ? 1．邏輯設計概述 概念結構是獨立于任何一種數據模型的，在實際應用中，一般所用的數據庫環(huán)境已經給定（如SQL Server或Oracel或MySql），本文討論從概念結構向邏輯結構的轉換問題。 由于目前使用的數據庫基本上都是關系數據庫，因此首先需要將E-R圖轉換為關系模型，然后根據具體DBMS的特點和限制轉換為特定的DBMS支持下的數據模型，最后進行優(yōu)化。 2．E-R圖向關系模型的轉換 2.1 一個例子 E-R圖如何轉換為關系模型呢？我們先看一個例子。圖2.1是學生和班級的E-R圖，學生與班級構成多對一的聯(lián)系。根據實際應用，我們可以做出這個簡單例子的關系模式： 學生（學號，姓名，班級） 班級（編號，名稱） “學生.班級”為外鍵，參照“班級.編號”取值。 這個例子我們是憑經驗轉換的，那么里面有什么規(guī)律呢？在2.2節(jié)，我們將這些經驗總結成一些規(guī)則，以供轉換使用。 2.2 轉換規(guī)則 (1) 一個實體型轉換為一個關系模式 一般E-R圖中的一個實體轉換為一個關系模式，實體的屬性就是關系的屬性，實體的碼就是關系的碼。 (2) 一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。圖2.2是一個一對一聯(lián)系的例子。根據規(guī)則（2），有三種轉換方式。 (i)????????????????? 聯(lián)系單獨作為一個關系模式 此時聯(lián)系本身的屬性，以及與該聯(lián)系相連的實體的碼均作為關系的屬性，可以選擇與該聯(lián)系相連的任一實體的碼屬性作為該關系的碼。結果如下： 職工（工號，姓名） 產品（產品號，產品名） 負責（工號，產品號） 其中“負責”這個關系的碼可以是工號，也可以是產品號。 (ii)??????????????? 與職工端合并 職工（工號，姓名，產品號） 產品（產品號，產品名） 其中“職工.產品號”為外碼。 (iii)?????????????? 與產品端合并 職工（工號，姓名） 產品（產品號，產品名，負責人工號） 其中“產品.負責人工號”為外碼。 (3) 一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。(i) 若單獨作為一個關系模式 此時該單獨的關系模式的屬性包括其自身的屬性，以及與該聯(lián)系相連的實體的碼。該關系的碼為n端實體的主屬性。 顧客（顧客號，姓名） 訂單（訂單號，……） 訂貨（顧客號，訂單號） (ii) 與n端合并 顧客（顧客號，姓名） 訂單（訂單號，……，顧客號） (4) 一個m:n聯(lián)系可以轉換為一個獨立的關系模式。該關系的屬性包括聯(lián)系自身的屬性，以及與聯(lián)系相連的實體的屬性。各實體的碼組成關系碼或關系碼的一部分。 教師（教師號，姓名） 學生（學號，姓名） 教授（教師號，學號） (5) 一個多元聯(lián)系可以轉換為一個獨立的關系模式。 與該多元聯(lián)系相連的各實體的碼，以及聯(lián)系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系碼的一部分。 (6) 具有相同碼的關系模式可以合并。 (7) 有些1：n的聯(lián)系，將屬性合并到n端后，該屬性也作為主碼的一部分 這類問題多出現(xiàn)在聚集類的聯(lián)系中，且部分實體的碼只能在某一個整體中作為碼，而在全部整體中不能作為碼的情況下才出現(xiàn)（其它情況本人還沒碰到，呵呵，歡迎指教）。 比如上篇文章介紹的管理信息系統(tǒng)中訂單與訂單細節(jié)的聯(lián)系。 關于什么是聚集，2.3節(jié)介紹。 2.3 數據抽象的分類 這部分本應在概念設計中介紹的，用到了才想起來，這里補充一下。 關于現(xiàn)實世界的抽象，一般分為三類： （1）??????????? 分類：即對象值與型之間的聯(lián)系，可以用“is member of”判定。如張英、王平都是學生，他們與“學生”之間構成分類關系。 （2）??????????? 聚集：定義某一類型的組成成分，是“is part of”的聯(lián)系。如學生與學號、姓名等屬性的聯(lián)系。 （3）??????????? 概括：定義類型間的一種子集聯(lián)系，是“is subset of”的聯(lián)系。如研究生和本科生都是學生，而且都是集合，因此它們之間是概括的聯(lián)系。 例：貓和動物之間是概括的聯(lián)系，《Tom and Jerry》中那只名叫Tom的貓與貓之間是分類的聯(lián)系，Tom的毛色和Tom之間是聚集的聯(lián)系。 訂單細節(jié)和訂單之間，訂單細節(jié)肯定不是一個訂單，因此不是概括或分類。訂單細節(jié)是訂單的一部分，因此是聚集。 2.4 數據模型的優(yōu)化 有了關系模型，可以進一步優(yōu)化，方法為： （1）?????? 確定數據依賴。 （2）?????? 對數據依賴進行極小化處理，消除冗余聯(lián)系（參看范式理論）。 （3）?????? 確定范式級別，根據應用環(huán)境，對某些模式進行合并或分解。 以上工作理論性比較強，主要目的是設計一個數據冗余盡量少的關系模式。下面這步則是考慮效率問題了： （4）?????? 對關系模式進行必要的分解。 如果一個關系模式的屬性特別多，就應該考慮是否可以對這個關系進行垂直分解。如果有些屬性是經常訪問的，而有些屬性是很少訪問的，則應該把它們分解為兩個關系模式。 如果一個關系的數據量特別大，就應該考慮是否可以進行水平分解。如一個論壇中，如果設計時把會員發(fā)的主貼和跟貼設計為一個關系，則在帖子量非常大的情況下，這一步就應該考慮把它們分開了。因為顯示的主貼是經常查詢的，而跟貼則是在打開某個主貼的情況下才查詢。又如手機號管理軟件，可以考慮按省份或其它方式進行水平分解。 2.5 設計用戶子模式 這部分主要是考慮使用方便性和效率問題，主要借助視圖手段實現(xiàn)，包括： （1）?????? 建立視圖，使用更符合用戶習慣的別名。 （2）?????? 對不同級別的用戶定義不同的視圖，以保證系統(tǒng)的安全性。 （3）?????? 對復雜的查詢操作，可以定義視圖，簡化用戶對系統(tǒng)的使用。

物理設計主要工作是選擇存取方法（索引），以及確定數據庫的存儲結構，這里就不說明了。

好了，可以在你的DBMS上建表了。