數據庫邏輯結構設計

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