資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地儲存資料，滿足各種使用者的應用需求（資訊要求和處理要求）。

在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

一、資料庫和資訊系統
　　(1)資料庫是資訊系統的核心和基礎，把資訊系統中大量的資料按一定的模型組織起來，提供儲存、維護、檢索資料的
　 　功能，使資訊系統可以方便、及時、準確地從資料庫中獲得所需的資訊。
　　(2)資料庫是資訊系統的各個部分能否緊密地結合在一起以及如何結合的關鍵所在。
　　(3)資料庫設計是資訊系統開發和建設的重要組成部分。
　　(4)資料庫設計人員應該具備的技術和知識：
　　　 　資料庫的基本知識和資料庫設計技術
　　　　 電腦科學的基礎知識和程式設計的方法和技巧
　　　 　軟體工程的原理和方法
　　　　 應用領域的知識

二、資料庫設計的特點
　　資料庫建設是硬體、軟體和幹件的結合
　　　三分技術，七分管理，十二分基礎資料
　　　技術與管理的介面稱之為“幹件”
　　資料庫設計應該與應用系統設計相結合
　　　結構（資料）設計：設計資料庫框架或資料庫結構
　　　行為（處理）設計：設計應用程式、事務處理等
　　結構和行為分離的設計
　　　傳統的軟體工程忽視對應用中資料語義的分析和抽象，只要有可能就儘量推遲資料結構設計的決策早期的資料庫設計致力於資料模型和建模方法研究，忽視了對行為的設計
　　如圖：

怎樣設計一個好的資料庫
三、資料庫設計方法簡述
　　手工試湊法
　　　設計質量與設計人員的經驗和水平有直接關係
　　　缺乏科學理論和工程方法的支援，工程的質量難以保證
　　　資料庫執行一段時間後常常又不同程度地發現各種問題，增加了維護代價
　　規範設計法
　　　手工設計方
　　　基本思想
　　過程迭代和逐步求精
　　規範設計法(續)
　　典型方法：
　　(1)新奧爾良（New Orleans）方法：將資料庫設計分為四個階段
　　　　S.B.Yao方法：將資料庫設計分為五個步驟
　　　　I.R.Palmer方法：把資料庫設計當成一步接一步的過程
　　(2)計算機輔助設計
　　　　ORACLE Designer 2000
　　　　SYBASE PowerDesigner

四、資料庫設計的基本步驟
　　資料庫設計的過程(六個階段)
　 1.需求分析階段
　　　準確瞭解與分析使用者需求（包括資料與處理）
　　　是整個設計過程的基礎，是最困難、最耗費時間的一步
　　2.概念結構設計階段
　　　是整個資料庫設計的關鍵
　　　通過對使用者需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
　　3.邏輯結構設計階段
　　　將概念結構轉換為某個DBMS所支援的資料模型
　　　對其進行優化
　　4.資料庫物理設計階段
　　　為邏輯資料模型選取一個最適合應用環境的物理結構（包括儲存結構和存取方法）
　　5.資料庫實施階段
　　　運用DBMS提供的資料語言、工具及宿主語言，根據邏輯設計和物理設計的結果
　　　建立資料庫，編制與除錯應用程式，組織資料入庫，並進行試執行
　　6.資料庫執行和維護階段
　　　資料庫應用系統經過試執行後即可投入正式執行。
　　　在資料庫系統執行過程中必須不斷地對其進行評價、調整與修改
　　設計特點:
　　　在設計過程中把資料庫的設計和對資料庫中資料處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

設計過程各個階段的設計描述：
　　如圖：

五、資料庫各級模式的形成過程
　　1.需求分析階段：綜合各個使用者的應用需求
　　2.概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)
　　3.邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支援的資料模型，如關係模型，形成資料庫邏輯模式；然後根據使用者處理的要求、安全性的考慮，在基本表的基礎上再建立必要的檢視(View)，形成資料的外模式
　　4.物理設計階段：根據DBMS特點和處理的需要，進行物理儲存安排，建立索引，形成資料庫內模式

六、資料庫設計技巧

1. 設計資料庫之前（需求分析階段）
　　1) 理解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
　　2) 瞭解企業業務可以在以後的開發階段節約大量的時間。
　　3) 重視輸入輸出。
　　在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和檢視（輸出）以決定為了支援這些輸出哪些是必要的表和欄位。
　　舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位裡。
　　4) 建立資料字典和ER 圖表
　　ER 圖表和資料字典可以讓任何瞭解資料庫的人都明確如何從資料庫中獲得資料。ER圖對錶明表之間關係很有用，而資料字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表示式的文件化來說這是完全必要的。
　　5) 定義標準的物件命名規範
　　資料庫各種物件的命名必須規範。

2. 表和欄位的設計（資料庫邏輯設計）
　　表設計原則
　　1) 標準化和規範化
　　資料的標準化有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但Third Normal Form（3NF）通常被認為在效能、擴充套件性和資料完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：“One Fact in One Place”即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關係通過外來鍵相連線。它具有以下特點：有一組表專門存放通過鍵連線起來的關聯資料。
　　舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何資訊，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶資訊的那一行。
　　事實上，為了效率的緣故，對錶不進行標準化有時也是必要的。
　　2) 資料驅動
　　採用資料驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴充套件性。
　　舉例，假如使用者介面要訪問外部資料來源（檔案、XML 文件、其他資料庫等），不妨把相應的連線和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流之類的任務（傳送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的資料也可以存放在資料庫裡。角色許可權管理也可以通過資料驅動來完成。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流過程。
　　3) 考慮各種變化
　　在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。
　　舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統儲存客戶資訊時，在單獨的一個數據表裡儲存姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一資料條目的變化。

欄位設計原則
　　4) 每個表中都應該新增的3 個有用的欄位
dRecordCreationDate，在VB 下預設是Now()，而在SQL Server 　　• 下預設為GETDATE()
sRecordCreator，在SQL Server 下預設為NOT NULL DEFAULT 　　• USER
nRecordVersion，記錄的版本標記；有助於準確說明記錄中出現null 資料或者丟失資料的原因 　　•
　　5) 對地址和電話採用多個欄位
　　描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的資料表，其間具有自身的型別和標記類別。
　　6) 使用角色實體定義屬於某類別的列
　　在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來建立特定的時間關聯關係，從而可以實現自我文件化。
　　舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關係的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能型別，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
　　7) 選擇數字型別和文字型別儘量充足
　　在SQL 中使用smallint 和tinyint 型別要特別小心。比如，假如想看看月銷售總額，總額欄位型別是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
　　而ID 型別的文字欄位，比如客戶ID 或定單號等等都應該設定得比一般想象更大。假設客戶ID 為10 位數長。那你應該把資料庫表字段的長度設為12 或者13 個字元長。但這額外佔據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
　　8) 增加刪除標記欄位
　　在表中包含一個“刪除標記”欄位，這樣就可以把行標記為刪除。在關係資料庫裡不要單獨刪除某一行；最好採用清除資料程式而且要仔細維護索引整體性。

3. 選擇鍵和索引（資料庫邏輯設計）
　　鍵選擇原則：
　　1) 鍵設計4 原則
為關聯欄位建立外來鍵。 　　•
所有的鍵都必須唯一。 　　•
避免使用複合鍵。 　　•
外來鍵總是關聯唯一的鍵欄位。 　　•
　　2) 使用系統生成的主鍵
　　設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對儲存資料中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
　　3) 不要用使用者的鍵(不讓主鍵具有可更新性)
　　在確定採用什麼欄位作為表的鍵的時候，可一定要小心使用者將要編輯的欄位。通常的情況下不要選擇使用者可編輯的欄位作為鍵。
　　4) 可選鍵有時可做主鍵
　　把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。

索引使用原則：
　　索引是從資料庫中獲取資料的最高效方式之一。95%的資料庫效能問題都可以採用索引技術得到解決。
　　1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為儲存過程）採用唯一的非成組索引，對任何外來鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
　　2) 大多數資料庫都索引自動建立的主鍵欄位，但是可別忘了索引外來鍵，它們也是經常使用的鍵，比如執行查詢顯示主表和所有關聯表的某條記錄就用得上。
　　3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的儲存空間。
　　4) 不要索引常用的小型表
　　不要為小型資料表設定任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

4. 資料完整性設計（資料庫邏輯設計）
　　1) 完整性實現機制：
　　實體完整性：主鍵
　　參照完整性：
　　父表中刪除資料：級聯刪除；受限刪除；置空值
　　父表中插入資料：受限插入；遞迴插入
　　父表中更新資料：級聯更新；受限更新；置空值
　　DBMS對參照完整性可以有兩種方法實現：外來鍵實現機制（約束規則）和觸發器實現機制
　　使用者定義完整性：
　　NOT NULL；CHECK；觸發器
　　2) 用約束而非商務規則強制資料完整性
　　採用資料庫系統實現資料的完整性。這不但包括通過標準化實現的完整性而且還包括資料的功能性。在寫資料的時候還可以增加觸發器來保證資料的正確性。不要依賴於商務層保證資料完整性；它不能保證表之間（外來鍵）的完整性所以不能強加於其他完整性規則之上。
　　3) 強制指示完整性
　　在有害資料進入資料庫之前將其剔除。啟用資料庫系統的指示完整性特性。這樣可以保持資料的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
　　4) 使用查詢控制資料完整性
　　控制資料完整性的最佳方式就是限制使用者的選擇。只要有可能都應該提供給使用者一個清晰的價值列表供其選擇。這樣將減少鍵入程式碼的錯誤和誤解同時提供資料的一致性。某些公共資料特別適合查詢：國家程式碼、狀態程式碼等。
　　5) 採用檢視
　　為了在資料庫和應用程式程式碼之間提供另一層抽象，可以為應用程式建立專門的檢視而不必非要應用程式直接訪問資料表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

5. 其他設計技巧
　　1) 避免使用觸發器
　　觸發器的功能通常可以用其他方式實現。在除錯程式時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文件化。
　　2) 使用常用英語（或者其他任何語言）而不要使用編碼
　　在建立下拉選單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上使用者知道的英語。
　　3) 儲存常用資訊
　　讓一個表專門存放一般資料庫資訊非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對Access）、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯絡時，這樣做對非客戶機/伺服器環境特別有用。
　　4) 包含版本機制
　　在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，使用者的需求總是會改變的。最終可能會要求修改資料庫結構。把版本資訊直接存放到資料庫中更為方便。
　　5) 編制文件
　　對所有的快捷方式、命名規範、限制和函式都要編制文件。
　　採用給表、列、觸發器等加註釋的資料庫工具。對開發、支援和跟蹤修改非常有用。
　　對資料庫文件化，或者在資料庫自身的內部或者單獨建立文件。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
　　6) 測試、測試、反覆測試
　　建立或者修訂資料庫之後，必須用使用者新輸入的資料測試資料欄位。最重要的是，讓使用者進行測試並且同用戶一道保證選擇的資料型別滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
　　7) 檢查設計
　　在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。換句話說，針對每一種最終表達資料的原型應用，保證你檢查了資料模型並且檢視如何取出資料。@TOC